From 8954361b403e9b12e28226155c7edbec027f9ecc Mon Sep 17 00:00:00 2001 From: Wes Turner <50891+westurner@users.noreply.github.com> Date: Sat, 19 Dec 2020 15:12:12 -0500 Subject: [PATCH 0001/1072] Update distributing-packages-using-setuptools.rst --- .../distributing-packages-using-setuptools.rst | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index ff7a360a3..d2fac7512 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -659,24 +659,27 @@ For example:: Working in "development mode" ============================= -Although not required, it's common to locally install your project in "editable" -or "develop" mode while you're working on it. This allows your project to be -both installed and editable in project form. +You can install a project in "editable" +or "develop" mode while you're working on it. +When installed as editable, a project can be +edited in-place without reinstallation: +changes to Python source files in projects installed as editable will be reflected the next time an interpreter process is started. -Assuming you're in the root of your project directory, then run: +To install a Python package in "editable"/"development" mode +Change directory to the root of the project directory and run ``pip install -e .``: :: pip install -e . -Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers +The pip command-line flag ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with "install_requires" and any scripts declared with "console_scripts". Dependencies will be installed in the usual, non-editable mode. -It's fairly common to also want to install some of your dependencies in editable +You may want to install some of your dependencies in editable mode as well. For example, supposing your project requires "foo" and "bar", but you want "bar" installed from VCS in editable mode, then you could construct a requirements file like so:: From a714ff7788ba96889e992ee83ac33657e6f688d6 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Mon, 12 Jul 2021 19:38:37 +0800 Subject: [PATCH 0002/1072] Add some sections --- .../deploying-python-applications.rst | 41 ++++++++++++++++++- 1 file changed, 40 insertions(+), 1 deletion(-) diff --git a/source/discussions/deploying-python-applications.rst b/source/discussions/deploying-python-applications.rst index 8734833f5..a013694c6 100644 --- a/source/discussions/deploying-python-applications.rst +++ b/source/discussions/deploying-python-applications.rst @@ -83,9 +83,48 @@ Application bundles FIXME - - py2exe/py2app/PEX - wheels kinda/sorta +Windows +------- + +py2exe +^^^^^^ + +`py2exe `__ is a distutils extension which +allows to build standalone Windows executable programs (32-bit and 64-bit) +from Python scripts. Python versions included in the official development +cycle are supported (from 3.6 to 3.9 included). py2exe can build console +executables and windows (GUI) executables. Building windows services, +and DLL/EXE COM servers might work but it is not actively supported. +The distutils extension is released under the MIT-licence and Mozilla +Public License 2.0. + +Mac OS +------ + +py2app +^^^^^^ + +`py2app `__ is a Python setuptools +command which will allow you to make standalone Mac OS X application +bundles and plugins from Python scripts. Note that py2app MUST be used +on OSX to build applications, it cannot create Mac applications on other +platforms. py2app is released under the MIT-license. + +Unix (including Linux and Mac OS X) +----------------------------------- + +pex +^^^ + +`pex `__ is a library for generating .pex +(Python EXecutable) files which are executable Python environments in the +spirit of virtualenvs. pex is an expansion upon the ideas outlined in PEP 441 +and makes the deployment of Python applications as simple as cp. pex files may +even include multiple platform-specific Python distributions, meaning that a +single pex file can be portable across Linux and OS X. pex is released under the +Apache License 2.0. Configuration management ======================== From 21b6da8ff483be7208f26d5155c8825bc7f4114a Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Mon, 12 Jul 2021 23:32:01 +0800 Subject: [PATCH 0003/1072] Add reference to pep and status of Python branches --- source/discussions/deploying-python-applications.rst | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/source/discussions/deploying-python-applications.rst b/source/discussions/deploying-python-applications.rst index a013694c6..f2bb5f756 100644 --- a/source/discussions/deploying-python-applications.rst +++ b/source/discussions/deploying-python-applications.rst @@ -94,12 +94,14 @@ py2exe `py2exe `__ is a distutils extension which allows to build standalone Windows executable programs (32-bit and 64-bit) from Python scripts. Python versions included in the official development -cycle are supported (from 3.6 to 3.9 included). py2exe can build console -executables and windows (GUI) executables. Building windows services, -and DLL/EXE COM servers might work but it is not actively supported. +cycle are supported (refers to `Status of Python branches`__). py2exe can +build console executables and windows (GUI) executables. Building windows +services, and DLL/EXE COM servers might work but it is not actively supported. The distutils extension is released under the MIT-licence and Mozilla Public License 2.0. +.. __: https://devguide.python.org/#status-of-python-branches + Mac OS ------ @@ -120,7 +122,7 @@ pex `pex `__ is a library for generating .pex (Python EXecutable) files which are executable Python environments in the -spirit of virtualenvs. pex is an expansion upon the ideas outlined in PEP 441 +spirit of virtualenvs. pex is an expansion upon the ideas outlined in :pep:`441` and makes the deployment of Python applications as simple as cp. pex files may even include multiple platform-specific Python distributions, meaning that a single pex file can be portable across Linux and OS X. pex is released under the From 8ac20c1968bc0e32825a77195f7d92c488eacee7 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Tue, 13 Jul 2021 13:21:36 +0800 Subject: [PATCH 0004/1072] Add translation.yml --- .github/workflows/translation.yml | 36 +++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 .github/workflows/translation.yml diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml new file mode 100644 index 000000000..ba648d60d --- /dev/null +++ b/.github/workflows/translation.yml @@ -0,0 +1,36 @@ +name: Translation + + on: + schedule: + - cron: '0 0 0 ? * WED,SUN *' + +jobs: + build: + runs-on: ubuntu-latest + + steps: + - uses: actions/checkout@v2 + + - name: Set up Python + uses: actions/setup-python@v2 + with: + python-version: 3.9 + + - name: Install Dependencies + run: python -m pip install --upgrade nox virtualenv + + - name: Create local changes + run: python -m nox -s translation + + - name: Commit files + run: | + git config --local user.email "github-actions[bot]@users.noreply.github.com" + git config --local user.name "github-actions[bot]" + git_hash=$(git rev-parse --short "$GITHUB_SHA") + git commit -m "Update messages.pot ${git_hash}" locales/messages.pot + if: ${{job.status == 'failure'}} + run: echo "No Changes!" + + - name: Push changes + run: | + git push --atomic main \ No newline at end of file From b5e4f1835f229fd82d407fc029b89952fa66edeb Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Tue, 13 Jul 2021 13:23:19 +0800 Subject: [PATCH 0005/1072] Update translation.yml --- .github/workflows/translation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index ba648d60d..d3b3ba8b3 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -1,6 +1,6 @@ name: Translation - on: +on: schedule: - cron: '0 0 0 ? * WED,SUN *' From b9abb50bb1e15ce593024e6d3ffe5f0d27bf3d8b Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Tue, 13 Jul 2021 13:23:59 +0800 Subject: [PATCH 0006/1072] Update translation.yml --- .github/workflows/translation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index d3b3ba8b3..b8e8ea1be 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -2,7 +2,7 @@ name: Translation on: schedule: - - cron: '0 0 0 ? * WED,SUN *' + - cron: '00 00,00 * * *' jobs: build: From d7eaa57ab540a686d0606bcaa72f94c4a4f86af0 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Tue, 13 Jul 2021 13:25:31 +0800 Subject: [PATCH 0007/1072] Update translation.yml --- .github/workflows/translation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index b8e8ea1be..c86b837a0 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -2,7 +2,7 @@ name: Translation on: schedule: - - cron: '00 00,00 * * *' + - cron: '30 13 * * *' jobs: build: From 39fabed254c10a67bf11ae8f6558f9b978a58936 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Tue, 13 Jul 2021 14:08:04 +0800 Subject: [PATCH 0008/1072] Update translation.yml --- .github/workflows/translation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index c86b837a0..2cd188f29 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -2,7 +2,7 @@ name: Translation on: schedule: - - cron: '30 13 * * *' + - cron: '10 14 * * *' jobs: build: From 0e28251d2999effe7b0267d08920166ea77b4d02 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Tue, 13 Jul 2021 14:18:22 +0800 Subject: [PATCH 0009/1072] Update cron spec --- .github/workflows/translation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index 2cd188f29..e6f6ae1ce 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -2,7 +2,7 @@ name: Translation on: schedule: - - cron: '10 14 * * *' + - cron: '00 00,00 * * sun' jobs: build: From 4780502450042337a09f00858e4e15c6019c9d33 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Tue, 13 Jul 2021 15:06:08 +0800 Subject: [PATCH 0010/1072] Update translation.yml --- .github/workflows/translation.yml | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index e6f6ae1ce..e93ceaf14 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -28,9 +28,11 @@ jobs: git config --local user.name "github-actions[bot]" git_hash=$(git rev-parse --short "$GITHUB_SHA") git commit -m "Update messages.pot ${git_hash}" locales/messages.pot - if: ${{job.status == 'failure'}} - run: echo "No Changes!" + + - name: Check on failures + if: ${{job.status == 'failure'}} + run: echo "No Changes!" - name: Push changes run: | - git push --atomic main \ No newline at end of file + git push --atomic origin test1 \ No newline at end of file From 552714ecc1f8a675440acba74d630097724189d1 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Tue, 13 Jul 2021 15:06:55 +0800 Subject: [PATCH 0011/1072] Update translation.yml --- .github/workflows/translation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index e93ceaf14..f54b41333 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -35,4 +35,4 @@ jobs: - name: Push changes run: | - git push --atomic origin test1 \ No newline at end of file + git push --atomic origin main \ No newline at end of file From 962f81e1176ccdcb57b4eaa8760d460fada64849 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Tue, 13 Jul 2021 19:12:33 +0800 Subject: [PATCH 0012/1072] Add a new line at the end of file --- .github/workflows/translation.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index f54b41333..b4c1fd35b 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -35,4 +35,5 @@ jobs: - name: Push changes run: | - git push --atomic origin main \ No newline at end of file + git push --atomic origin main + From 7e067195728a1a95d5802182f7ebec580ae32104 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Wed, 14 Jul 2021 22:56:30 +0800 Subject: [PATCH 0013/1072] Add Translation Guide --- source/contribute.rst | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/source/contribute.rst b/source/contribute.rst index 3709d341f..1d356e06b 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -11,6 +11,7 @@ including: * Reviewing new contributions * Revising existing content * Writing new content +* Translate the guide Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of @@ -67,6 +68,32 @@ an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `. +Translations +============ + +We use `Weblate`__ to manage translations of this project. +Please visit the `packaging.python.org`__ project on Weblate to contribute. + +If you are experiencing issues while you are working on translations, +please open an issue on `Github `. +please open an issue on `Github`__. + +.. __: https://weblate.org/ +.. __: https://hosted.weblate.org/projects/pypa/packaging-python-org/ +.. __: https://github.com/pypa/packaging.python.org/issues + +Adding a language +----------------- + +If your language is not listed on `Weblate`__, click the button +"Start new translation" at the bottom of the languages list and add +the language you want to translate. + +.. __: https://hosted.weblate.org/projects/pypa/packaging-python-org/ + +.. Note:: Any translations of this project should follow `RST syntax`__. + +.. __: https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html Building the guide locally From 57e8e767c722e9964c6f4d280d9bca6fda034861 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Wed, 14 Jul 2021 23:04:06 +0800 Subject: [PATCH 0014/1072] Update Translation Guideline --- source/contribute.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/source/contribute.rst b/source/contribute.rst index 1d356e06b..a2ed330bb 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -75,7 +75,6 @@ We use `Weblate`__ to manage translations of this project. Please visit the `packaging.python.org`__ project on Weblate to contribute. If you are experiencing issues while you are working on translations, -please open an issue on `Github `. please open an issue on `Github`__. .. __: https://weblate.org/ From d281ad460107810c8d97625a0c1d4037fbb6c777 Mon Sep 17 00:00:00 2001 From: Rafael Fontenelle Date: Fri, 16 Jul 2021 16:24:09 -0300 Subject: [PATCH 0015/1072] fix: easy_install URL now includes /deprecated/ --- source/discussions/pip-vs-easy-install.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/discussions/pip-vs-easy-install.rst b/source/discussions/pip-vs-easy-install.rst index 5f2d18737..4fa590cf3 100644 --- a/source/discussions/pip-vs-easy-install.rst +++ b/source/discussions/pip-vs-easy-install.rst @@ -65,7 +65,7 @@ Here's a breakdown of the important differences between pip and the deprecated e .. _deprecated: https://setuptools.readthedocs.io/en/latest/history.html#v42-0-0 -.. [1] https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher +.. [1] https://setuptools.readthedocs.io/en/latest/deprecated/easy_install.html#natural-script-launcher .. _pylauncher support: https://bitbucket.org/vinay.sajip/pylauncher From 0bde60b2006888f4d54ef89c8970d0dfa816a2ca Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 17 Jul 2021 18:09:27 +0800 Subject: [PATCH 0016/1072] Normalize command lines in code blocks (#949) * Remove prompts * Use `code-block:: console` instead of `::` * Use `code-block:: console` instead of `::` & remove prompts * Use code-block:: bash Co-authored-by: Brian Rutledge --- .../analyzing-pypi-package-downloads.rst | 4 ++-- source/guides/index-mirrors-and-caches.rst | 4 ++-- ...talling-stand-alone-command-line-tools.rst | 24 +++++++++---------- source/guides/using-testpypi.rst | 4 ++-- 4 files changed, 18 insertions(+), 18 deletions(-) diff --git a/source/guides/analyzing-pypi-package-downloads.rst b/source/guides/analyzing-pypi-package-downloads.rst index 3847f14d9..abb3cc48b 100644 --- a/source/guides/analyzing-pypi-package-downloads.rst +++ b/source/guides/analyzing-pypi-package-downloads.rst @@ -272,13 +272,13 @@ number of download for a package with the command ``pypinfo package_name``. Install `pypinfo`_ using pip. -:: +.. code-block:: bash python -m pip install pypinfo Usage: -:: +.. code-block:: console $ pypinfo requests Served from cache: False diff --git a/source/guides/index-mirrors-and-caches.rst b/source/guides/index-mirrors-and-caches.rst index b4e8ac293..e5cd45e8f 100644 --- a/source/guides/index-mirrors-and-caches.rst +++ b/source/guides/index-mirrors-and-caches.rst @@ -37,8 +37,8 @@ cached copies of :term:`packages `: the requirements using `python -m pip wheel `_:: - $ python -m pip wheel --wheel-dir=/tmp/wheelhouse SomeProject - $ python -m pip install --no-index --find-links=/tmp/wheelhouse SomeProject + python -m pip wheel --wheel-dir=/tmp/wheelhouse SomeProject + python -m pip install --no-index --find-links=/tmp/wheelhouse SomeProject Caching with devpi diff --git a/source/guides/installing-stand-alone-command-line-tools.rst b/source/guides/installing-stand-alone-command-line-tools.rst index e2e6b7d36..3108d0671 100644 --- a/source/guides/installing-stand-alone-command-line-tools.rst +++ b/source/guides/installing-stand-alone-command-line-tools.rst @@ -42,14 +42,14 @@ packages, and allows you to safely run the program from anywhere. Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere. -:: +.. code-block:: console $ pipx install PACKAGE $ ENTRYPOINT_OF_PACKAGE [ARGS] For example -:: +.. code-block:: console $ pipx install cowsay installed package cowsay 2.0, Python 3.6.2+ @@ -69,7 +69,7 @@ For example To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``. -:: +.. code-block:: console $ pipx list venvs are in /Users/user/.local/pipx/venvs @@ -89,10 +89,10 @@ To see a list of packages installed with pipx and which CLI applications are ava To upgrade or uninstall the package -:: +.. code-block:: bash - $ pipx upgrade PACKAGE - $ pipx uninstall PACKAGE + pipx upgrade PACKAGE + pipx uninstall PACKAGE ``pipx`` can be upgraded or uninstalled with pip @@ -113,21 +113,21 @@ To upgrade or uninstall the package ``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment. -:: +.. code-block:: bash - $ pipx run PACKAGE [ARGS] + pipx run PACKAGE [ARGS] For example -:: +.. code-block:: bash - $ pipx run cowsay moooo + pipx run cowsay moooo To see the full list of commands ``pipx`` offers, run -:: +.. code-block:: bash - $ pipx --help + pipx --help You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx. diff --git a/source/guides/using-testpypi.rst b/source/guides/using-testpypi.rst index e8676fc25..f4f05d719 100644 --- a/source/guides/using-testpypi.rst +++ b/source/guides/using-testpypi.rst @@ -26,9 +26,9 @@ Using TestPyPI with Twine You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag -.. code:: +.. code-block:: bash - $ twine upload --repository testpypi dist/* + twine upload --repository testpypi dist/* You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is From 63e3145fb650057087962164f679dcc7c300f7dc Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Sat, 17 Jul 2021 06:06:37 -0400 Subject: [PATCH 0017/1072] Replace :: with shell code-block:: --- source/contribute.rst | 16 +++++++++++----- .../distributing-packages-using-setuptools.rst | 14 +++++++++----- source/guides/dropping-older-python-versions.rst | 4 +++- source/guides/index-mirrors-and-caches.rst | 8 +++++--- source/guides/making-a-pypi-friendly-readme.rst | 6 ++++-- source/guides/using-manifest-in.rst | 4 +++- source/tutorials/installing-packages.rst | 10 +++++----- 7 files changed, 40 insertions(+), 22 deletions(-) diff --git a/source/contribute.rst b/source/contribute.rst index 3709d341f..5811a1d1c 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -77,7 +77,9 @@ in order to test your changes. In order to build this guide locally, you'll need: 1. `Nox `_. You can install or upgrade - nox using ``pip``:: + nox using ``pip``: + + .. code-block:: bash python -m pip install --user nox @@ -88,9 +90,11 @@ need: .. _Hitchhiker's Guide to Python installation instructions: http://docs.python-guide.org/en/latest/starting/installation/ -To build the guide, run the following bash command in the source folder:: +To build the guide, run the following bash command in the source folder: + +.. code-block:: bash - nox -s build + nox -s build After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the @@ -98,9 +102,11 @@ guide in web browser, but it's recommended to serve the guide using an HTTP server. You can build the guide and serve it via an HTTP server using the following -command:: +command: + +.. code-block:: bash - nox -s preview + nox -s preview The guide will be browsable via http://localhost:8000. diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index c6e7ebf41..7121bd6e3 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -666,9 +666,9 @@ both installed and editable in project form. Assuming you're in the root of your project directory, then run: -:: +.. code-block:: bash - python -m pip install -e . + python -m pip install -e . Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers @@ -698,7 +698,9 @@ Otherwise, the dependency will be fulfilled from PyPI, due to the installation o ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs. -Lastly, if you don't want to install any dependencies at all, you can run:: +Lastly, if you don't want to install any dependencies at all, you can run: + +.. code-block:: bash python -m pip install -e . --no-deps @@ -880,9 +882,11 @@ distribution file(s) to upload. directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on - your package files:: + your package files: + + .. code-block:: bash - twine check dist/* + twine check dist/* Create an account ----------------- diff --git a/source/guides/dropping-older-python-versions.rst b/source/guides/dropping-older-python-versions.rst index fea3068c0..080f7282b 100644 --- a/source/guides/dropping-older-python-versions.rst +++ b/source/guides/dropping-older-python-versions.rst @@ -105,7 +105,9 @@ Within a Python source package (the zip or the tar-gz file you download) is a te This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format. -You can see the contents of the generated file like this:: +You can see the contents of the generated file like this: + +.. code-block:: bash tar xfO dist/my-package-1.0.0.tar.gz my-package-1.0.0/PKG-INFO diff --git a/source/guides/index-mirrors-and-caches.rst b/source/guides/index-mirrors-and-caches.rst index e5cd45e8f..284665eb0 100644 --- a/source/guides/index-mirrors-and-caches.rst +++ b/source/guides/index-mirrors-and-caches.rst @@ -35,10 +35,12 @@ cached copies of :term:`packages `: those downloaded files instead of going to PyPI. 2. A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel - `_:: + `_: - python -m pip wheel --wheel-dir=/tmp/wheelhouse SomeProject - python -m pip install --no-index --find-links=/tmp/wheelhouse SomeProject + .. code-block:: bash + + python -m pip wheel --wheel-dir=/tmp/wheelhouse SomeProject + python -m pip install --no-index --find-links=/tmp/wheelhouse SomeProject Caching with devpi diff --git a/source/guides/making-a-pypi-friendly-readme.rst b/source/guides/making-a-pypi-friendly-readme.rst index 32e8f2f09..eea221b4a 100644 --- a/source/guides/making-a-pypi-friendly-readme.rst +++ b/source/guides/making-a-pypi-friendly-readme.rst @@ -122,9 +122,11 @@ You can check your README for markup errors before uploading as follows: 2. Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`. -3. Run ``twine check`` on the sdist and wheel:: +3. Run ``twine check`` on the sdist and wheel: - twine check dist/* + .. code-block:: bash + + twine check dist/* This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: diff --git a/source/guides/using-manifest-in.rst b/source/guides/using-manifest-in.rst index 51e779315..c8bfa8802 100644 --- a/source/guides/using-manifest-in.rst +++ b/source/guides/using-manifest-in.rst @@ -93,7 +93,9 @@ setuptools will automatically convert the slashes to the local platform's appropriate directory separator. Commands are processed in the order they appear in the :file:`MANIFEST.in` -file. For example, given the commands:: +file. For example, given the commands: + +.. code-block:: bash graft tests global-exclude *.py[cod] diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst index 296a17973..f2d522612 100644 --- a/source/tutorials/installing-packages.rst +++ b/source/tutorials/installing-packages.rst @@ -281,9 +281,9 @@ In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so: -:: +.. code-block:: bat - \Scripts\activate + \Scripts\activate @@ -618,10 +618,10 @@ create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index. -:: +.. code-block:: bash - ./s3helper --port=7777 - python -m pip install --extra-index-url http://localhost:7777 SomeProject + ./s3helper --port=7777 + python -m pip install --extra-index-url http://localhost:7777 SomeProject Installing Prereleases From 948840f7017753d8e5af2da2486f1144f442c083 Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Sat, 17 Jul 2021 06:44:03 -0400 Subject: [PATCH 0018/1072] Copy-edit pipx guide --- ...talling-stand-alone-command-line-tools.rst | 64 +++++++++---------- 1 file changed, 30 insertions(+), 34 deletions(-) diff --git a/source/guides/installing-stand-alone-command-line-tools.rst b/source/guides/installing-stand-alone-command-line-tools.rst index 3108d0671..958699d42 100644 --- a/source/guides/installing-stand-alone-command-line-tools.rst +++ b/source/guides/installing-stand-alone-command-line-tools.rst @@ -1,53 +1,55 @@ Installing stand alone command line tools ========================================= -Many packages have command line entry points. Examples of this type of application are +Many packages provide command line applications. Examples of such packages are `mypy `_, `flake8 `_, -:ref:`pipenv`,and -`black `_. +`black `_, and +:ref:`pipenv`. -Usually you want to be able to access these from anywhere, -but installing packages and their dependencies to the same global environment -can cause version conflicts and break dependencies the operating system has -on Python packages. +Usually you want to be able to access these applications from anywhere on your +system, but installing packages and their dependencies to the same global +environment can cause version conflicts and break dependencies the operating +system has on Python packages. -:ref:`pipx` solves this by creating a virtual -environment for each package, while also ensuring that package's applications -are accessible through a directory that is on your ``$PATH``. This allows each -package to be upgraded or uninstalled without causing conflicts with other -packages, and allows you to safely run the program from anywhere. +:ref:`pipx` solves this by creating a virtual environment for each package, +while also ensuring that its applications are accessible through a directory +that is on your ``$PATH``. This allows each package to be upgraded or +uninstalled without causing conflicts with other packages, and allows you to +safely run the applications from anywhere. .. note:: pipx only works with Python 3.6+. -``pipx`` is installed with ``pip``: +pipx is installed with pip: .. tab:: Unix/macOS .. code-block:: bash python3 -m pip install --user pipx - - python3 -m pipx ensurepath # ensures the path of the CLI application directory is on your $PATH + python3 -m pipx ensurepath .. tab:: Windows .. code-block:: bat py -m pip install --user pipx - py -m pipx ensurepath -.. Note:: You may need to restart your terminal for the path updates to take effect. +.. note:: + + ``ensurepath`` ensures that the application directory is on your ``$PATH``. + You may need to restart your terminal for this update to take effect. -Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere. +Now you can install packages with ``pipx install`` and run the package's +applications(s) from anywhere. .. code-block:: console $ pipx install PACKAGE - $ ENTRYPOINT_OF_PACKAGE [ARGS] + $ PACKAGE_APPLICATION [ARGS] -For example +For example: .. code-block:: console @@ -67,7 +69,8 @@ For example (__)\ )\/ ||----w | || || -To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``. +To see a list of packages installed with pipx and which applications are +available, use ``pipx list``: .. code-block:: console @@ -87,14 +90,14 @@ To see a list of packages installed with pipx and which CLI applications are ava - nox - tox-to-nox -To upgrade or uninstall the package +To upgrade or uninstall a package: .. code-block:: bash pipx upgrade PACKAGE pipx uninstall PACKAGE -``pipx`` can be upgraded or uninstalled with pip +pipx can be upgraded or uninstalled with pip: .. tab:: Unix/macOS @@ -109,25 +112,18 @@ To upgrade or uninstall the package py -m pip install -U pipx py -m pip uninstall pipx - -``pipx`` also allows you to install and run the latest version of a cli tool -in a temporary, ephemeral environment. - -.. code-block:: bash - - pipx run PACKAGE [ARGS] -For example +pipx also allows you to install and run the latest version of an application +in a temporary, ephemeral environment. For example: .. code-block:: bash pipx run cowsay moooo -To see the full list of commands ``pipx`` offers, run +To see the full list of commands pipx offers, run: .. code-block:: bash pipx --help -You can learn more about ``pipx`` at its homepage, -https://github.com/pypa/pipx. +You can learn more about pipx at https://pypa.github.io/pipx/. From 0810b46f4c53d83f2144b606fcdddf23b54a5645 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 17 Jul 2021 19:55:32 +0800 Subject: [PATCH 0019/1072] Update Translation Guide --- source/contribute.rst | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/source/contribute.rst b/source/contribute.rst index a2ed330bb..6adde7265 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -77,9 +77,12 @@ Please visit the `packaging.python.org`__ project on Weblate to contribute. If you are experiencing issues while you are working on translations, please open an issue on `Github`__. +.. Note:: Any translations of this project should follow `reStructuredText syntax`__. + .. __: https://weblate.org/ .. __: https://hosted.weblate.org/projects/pypa/packaging-python-org/ .. __: https://github.com/pypa/packaging.python.org/issues +.. __: https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html Adding a language ----------------- @@ -90,10 +93,24 @@ the language you want to translate. .. __: https://hosted.weblate.org/projects/pypa/packaging-python-org/ -.. Note:: Any translations of this project should follow `RST syntax`__. +Following reStructuredText syntax +-------------------- -.. __: https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html +If you are not familiar with reStructuredText (RST) syntax, please read `this guide`__ +before translating on Weblate. + +Example: + +Wrong: Translate the following text directly:: + + `some ref`_ -> `TRANSLATED TEXT HERE`_ + +Right: Translate the following text with your own language and add reference to the +original language:: + + `some ref`_ -> `TRANSLATED TEXT HERE `_ +.. __: https://docutils.sourceforge.io/docs/user/rst/quickref.html Building the guide locally ========================== From 9e8c75120a5263b68c6e6de0864378f4b23475c1 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 17 Jul 2021 20:29:31 +0800 Subject: [PATCH 0020/1072] Update Translation Guide --- source/contribute.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/contribute.rst b/source/contribute.rst index 6adde7265..3ab8df835 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -94,7 +94,7 @@ the language you want to translate. .. __: https://hosted.weblate.org/projects/pypa/packaging-python-org/ Following reStructuredText syntax --------------------- +--------------------------------- If you are not familiar with reStructuredText (RST) syntax, please read `this guide`__ before translating on Weblate. From f43561baeaa55ce65729f0f00db9c3839a76da1d Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sun, 18 Jul 2021 00:44:55 +0800 Subject: [PATCH 0021/1072] Update `installing-using-linux-tools` --- .../guides/installing-using-linux-tools.rst | 102 +++++++++++------- 1 file changed, 66 insertions(+), 36 deletions(-) diff --git a/source/guides/installing-using-linux-tools.rst b/source/guides/installing-using-linux-tools.rst index 2082cc72f..637baac97 100644 --- a/source/guides/installing-using-linux-tools.rst +++ b/source/guides/installing-using-linux-tools.rst @@ -4,9 +4,8 @@ Installing pip/setuptools/wheel with Linux Package Managers =========================================================== -:Page Status: Incomplete -:Last Reviewed: 2015-09-17 - +.. contents:: Contents + :local: This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers. @@ -31,32 +30,31 @@ versions. When this is known, we will make note of it below. Fedora ~~~~~~ -* Fedora 21: +* Fedora 33 & 34: - * Python 2:: + * Python 3: - sudo yum upgrade python-setuptools - sudo yum install python-pip python-wheel + .. code-block:: bash - * Python 3: ``sudo yum install python3 python3-wheel`` + sudo dnf install python3 python3-wheel -* Fedora 22: + * Python 2: - * Python 2:: + .. code-block:: bash sudo dnf upgrade python-setuptools sudo dnf install python-pip python-wheel - * Python 3: ``sudo dnf install python3 python3-wheel`` - To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions -`__, and then run:: +`__, and then run: - sudo yum|dnf upgrade python-setuptools - sudo yum|dnf install python-pip python-wheel +.. code-block:: bash + + sudo dnf upgrade python-setuptools + sudo dnf install python-pip python-wheel CentOS/RHEL @@ -70,26 +68,42 @@ To install pip and wheel for the system Python, there are two options: 1. Enable the `EPEL repository `_ using `these instructions `__. On - EPEL 6 and EPEL7, you can install pip like so:: + EPEL 6 and EPEL7, you can install pip like so: + + * Python3: + + .. code-block:: bash + + sudo yum install python3-pip + + * Python2: + + .. code-block:: bash - sudo yum install python-pip + sudo yum install python-pip - On EPEL 7 (but not EPEL 6), you can install wheel like so:: + On EPEL 7 (but not EPEL 6), you can install wheel like so: - sudo yum install python-wheel + .. code-block:: bash - Since EPEL only offers extra, non-conflicting packages, EPEL does not offer - setuptools, since it's in the core repository. + sudo yum install python-wheel + + Since EPEL only offers extra, non-conflicting packages, EPEL does not offer + setuptools, since it's in the core repository. 2. Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install - pip and wheel like so:: + pip and wheel like so: + + .. code-block:: bash sudo yum install python-pip python-wheel - To additionally upgrade setuptools, run:: + To additionally upgrade setuptools, run: + + .. code-block:: bash sudo yum upgrade python-setuptools @@ -113,7 +127,9 @@ To install pip, wheel, and setuptools, in a parallel, non-system environment Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date. - For example, for Python 3.4 on CentOS7/RHEL7:: + For example, for Python 3.4 on CentOS7/RHEL7: + + .. code-block:: bash sudo yum install python34u python34u-wheel @@ -121,29 +137,39 @@ To install pip, wheel, and setuptools, in a parallel, non-system environment openSUSE ~~~~~~~~ -* Python 2:: - - sudo zypper install python-pip python-setuptools python-wheel - +* Python 3: -* Python 3:: + .. code-block:: bash sudo zypper install python3-pip python3-setuptools python3-wheel +* Python 2: + + .. code-block:: bash + + sudo zypper install python-pip python-setuptools python-wheel Debian/Ubuntu ~~~~~~~~~~~~~ +Firstly, update and refresh repository lists by running this command: -* Python 2:: +.. code-block:: bash - sudo apt install python-pip + sudo apt update +* Python 3: -* Python 3:: + .. code-block:: bash sudo apt install python3-venv python3-pip +* Python 2: + + .. code-block:: bash + + sudo apt install python-pip + .. warning:: @@ -155,14 +181,18 @@ Debian/Ubuntu Arch Linux ~~~~~~~~~~ -* Python 2:: - - sudo pacman -S python2-pip +* Python 3: -* Python 3:: + .. code-block:: bash sudo pacman -S python-pip +* Python 2: + + .. code-block:: bash + + sudo pacman -S python2-pip + ---- .. [1] Currently, there is no "copr" yum plugin available for CentOS/RHEL, so From c94bfe3727830bc6db045235dc25c053c97706e7 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Wed, 21 Jul 2021 08:47:43 -0700 Subject: [PATCH 0022/1072] Define what a source tree is --- source/specifications/source-distribution-format.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/source/specifications/source-distribution-format.rst b/source/specifications/source-distribution-format.rst index 9a5d5dfdd..52bb856fc 100644 --- a/source/specifications/source-distribution-format.rst +++ b/source/specifications/source-distribution-format.rst @@ -20,6 +20,16 @@ specification. Source distributions are also known as *sdists* for short. +Source trees +============ + +A *source tree* is a collection of files and directories -- like a version +control system checkout -- which contains a :file:`pyproject.toml` file that +can be use to build a source distribution from the contained files and +directories. :pep:`517` and :pep:`518` specify what is required to meet the +definition of what :file:`pyproject.toml` must contain for something to be +deemed a source tree. + Source distribution file name ============================= From bf3dbfcbfaafd690a59de4d1fd77f542882989af Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sat, 24 Jul 2021 12:23:06 +0800 Subject: [PATCH 0023/1072] Update source/contribute.rst Co-authored-by: Sviatoslav Sydorenko --- source/contribute.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/source/contribute.rst b/source/contribute.rst index 3ab8df835..9b4a76c17 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -77,7 +77,9 @@ Please visit the `packaging.python.org`__ project on Weblate to contribute. If you are experiencing issues while you are working on translations, please open an issue on `Github`__. -.. Note:: Any translations of this project should follow `reStructuredText syntax`__. +.. note:: + + Any translations of this project should follow `reStructuredText syntax`__. .. __: https://weblate.org/ .. __: https://hosted.weblate.org/projects/pypa/packaging-python-org/ From 69403ff96800bdc6aca236c13b919eb4db2b116e Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 24 Jul 2021 13:45:59 +0800 Subject: [PATCH 0024/1072] Add translation guideline --- source/contribute.rst | 42 +++++++++++++++++++++++------------------- 1 file changed, 23 insertions(+), 19 deletions(-) diff --git a/source/contribute.rst b/source/contribute.rst index 9b4a76c17..afb337432 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -71,48 +71,52 @@ an agreed-upon interface for interoperability between packaging tools. Translations ============ -We use `Weblate`__ to manage translations of this project. -Please visit the `packaging.python.org`__ project on Weblate to contribute. +We use `Weblate`_ to manage translations of this project. +Please visit the `packaging.python.org`_ project on Weblate to contribute. If you are experiencing issues while you are working on translations, -please open an issue on `Github`__. +please open an issue on `Github`_. .. note:: - Any translations of this project should follow `reStructuredText syntax`__. + Any translations of this project should follow `reStructuredText syntax`_. -.. __: https://weblate.org/ -.. __: https://hosted.weblate.org/projects/pypa/packaging-python-org/ -.. __: https://github.com/pypa/packaging.python.org/issues -.. __: https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html +.. _Weblate: https://weblate.org/ +.. _packaging.python.org: https://hosted.weblate.org/projects/pypa/packaging-python-org/ +.. _Github: https://github.com/pypa/packaging.python.org/issues +.. _reStructuredText syntax: https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html Adding a language ----------------- -If your language is not listed on `Weblate`__, click the button +If your language is not listed on `packaging.python.org`_, click the button "Start new translation" at the bottom of the languages list and add the language you want to translate. -.. __: https://hosted.weblate.org/projects/pypa/packaging-python-org/ - Following reStructuredText syntax --------------------------------- -If you are not familiar with reStructuredText (RST) syntax, please read `this guide`__ +If you are not familiar with reStructuredText (RST) syntax, please read `this guide`_ before translating on Weblate. -Example: +**Do not translate the text in reference directly** + + When translating the text in reference, please do not translate them directly. + + | Wrong: Translate the following text directly: + + .. code-block:: -Wrong: Translate the following text directly:: + `some ref`_ -> `TRANSLATED TEXT HERE`_ - `some ref`_ -> `TRANSLATED TEXT HERE`_ + | Right: Translate the following text with your own language and add reference to the + original language: -Right: Translate the following text with your own language and add reference to the -original language:: + .. code-block:: - `some ref`_ -> `TRANSLATED TEXT HERE `_ + `some ref`_ -> `TRANSLATED TEXT HERE `_ -.. __: https://docutils.sourceforge.io/docs/user/rst/quickref.html +.. _this guide: https://docutils.sourceforge.io/docs/user/rst/quickref.html Building the guide locally ========================== From 91a5274e38c90c79d369fa080dc570d65a34a68b Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sat, 24 Jul 2021 15:17:29 +0800 Subject: [PATCH 0025/1072] Update source/contribute.rst Co-authored-by: Sviatoslav Sydorenko --- source/contribute.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/source/contribute.rst b/source/contribute.rst index 31761ac40..b456cb0be 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -109,8 +109,7 @@ before translating on Weblate. `some ref`_ -> `TRANSLATED TEXT HERE`_ - | Right: Translate the following text with your own language and add reference to the - original language: + | Right: Translate the following text with your own language and add the original reference: .. code-block:: From fa19a9f37f5e08280a2aa4d0c7c1b79234b22977 Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sat, 24 Jul 2021 15:22:46 +0800 Subject: [PATCH 0026/1072] Update source/contribute.rst Co-authored-by: Sviatoslav Sydorenko --- source/contribute.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/contribute.rst b/source/contribute.rst index b456cb0be..920d83fec 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -90,7 +90,7 @@ Adding a language ----------------- If your language is not listed on `packaging.python.org`_, click the button -"Start new translation" at the bottom of the languages list and add +:guilabel:`Start new translation` at the bottom of the language list and add the language you want to translate. Following reStructuredText syntax From d3bba7c692baec3a35b5cc027da3f7c9027fd0f1 Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sat, 24 Jul 2021 15:28:19 +0800 Subject: [PATCH 0027/1072] Update source/contribute.rst Co-authored-by: Sviatoslav Sydorenko --- source/contribute.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/contribute.rst b/source/contribute.rst index 920d83fec..6abd32ee0 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -77,7 +77,7 @@ Please visit the `packaging.python.org`_ project on Weblate to contribute. If you are experiencing issues while you are working on translations, please open an issue on `Github`_. -.. note:: +.. tip:: Any translations of this project should follow `reStructuredText syntax`_. From 82dc3e69b7c8c85a083639b3f0f3ecc72da18462 Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sat, 24 Jul 2021 15:28:58 +0800 Subject: [PATCH 0028/1072] Update source/contribute.rst Co-authored-by: Sviatoslav Sydorenko --- source/contribute.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/contribute.rst b/source/contribute.rst index 6abd32ee0..248973529 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -105,7 +105,7 @@ before translating on Weblate. | Wrong: Translate the following text directly: - .. code-block:: + .. code-block:: rst `some ref`_ -> `TRANSLATED TEXT HERE`_ From f0a55c9a7a10e0be86fc156a86b5945a78123179 Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sat, 24 Jul 2021 15:29:04 +0800 Subject: [PATCH 0029/1072] Update source/contribute.rst Co-authored-by: Sviatoslav Sydorenko --- source/contribute.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/contribute.rst b/source/contribute.rst index 248973529..e51fab8e2 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -111,7 +111,7 @@ before translating on Weblate. | Right: Translate the following text with your own language and add the original reference: - .. code-block:: + .. code-block:: rst `some ref`_ -> `TRANSLATED TEXT HERE `_ From 235e362e7cbecd42eba321681f2a000c3ed710c4 Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Sat, 24 Jul 2021 06:46:09 -0400 Subject: [PATCH 0030/1072] Apply suggestions from code review Co-authored-by: Sviatoslav Sydorenko --- .../guides/installing-stand-alone-command-line-tools.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/source/guides/installing-stand-alone-command-line-tools.rst b/source/guides/installing-stand-alone-command-line-tools.rst index 958699d42..c4aeb9858 100644 --- a/source/guides/installing-stand-alone-command-line-tools.rst +++ b/source/guides/installing-stand-alone-command-line-tools.rst @@ -14,7 +14,7 @@ system has on Python packages. :ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that its applications are accessible through a directory -that is on your ``$PATH``. This allows each package to be upgraded or +that is on your :envvar:`PATH`. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the applications from anywhere. @@ -38,10 +38,10 @@ pipx is installed with pip: .. note:: - ``ensurepath`` ensures that the application directory is on your ``$PATH``. + :command:`ensurepath` ensures that the application directory is on your :envvar:`PATH`. You may need to restart your terminal for this update to take effect. -Now you can install packages with ``pipx install`` and run the package's +Now you can install packages with :command:`pipx install` and run the package's applications(s) from anywhere. .. code-block:: console @@ -70,7 +70,7 @@ For example: || || To see a list of packages installed with pipx and which applications are -available, use ``pipx list``: +available, use :command:`pipx list`: .. code-block:: console From 25179048adb5fe8ce5f2dac67dea569ab9d7cd01 Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Sun, 25 Jul 2021 06:01:14 -0400 Subject: [PATCH 0031/1072] Revert less-helpful roles --- .../guides/installing-stand-alone-command-line-tools.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/source/guides/installing-stand-alone-command-line-tools.rst b/source/guides/installing-stand-alone-command-line-tools.rst index c4aeb9858..958699d42 100644 --- a/source/guides/installing-stand-alone-command-line-tools.rst +++ b/source/guides/installing-stand-alone-command-line-tools.rst @@ -14,7 +14,7 @@ system has on Python packages. :ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that its applications are accessible through a directory -that is on your :envvar:`PATH`. This allows each package to be upgraded or +that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the applications from anywhere. @@ -38,10 +38,10 @@ pipx is installed with pip: .. note:: - :command:`ensurepath` ensures that the application directory is on your :envvar:`PATH`. + ``ensurepath`` ensures that the application directory is on your ``$PATH``. You may need to restart your terminal for this update to take effect. -Now you can install packages with :command:`pipx install` and run the package's +Now you can install packages with ``pipx install`` and run the package's applications(s) from anywhere. .. code-block:: console @@ -70,7 +70,7 @@ For example: || || To see a list of packages installed with pipx and which applications are -available, use :command:`pipx list`: +available, use ``pipx list``: .. code-block:: console From f0bc57e57bd1becba26bb3bac89aba3ae2427308 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Mon, 26 Jul 2021 14:28:03 +0800 Subject: [PATCH 0032/1072] Remove Python 2 instructions --- .../guides/installing-using-linux-tools.rst | 48 +------------------ 1 file changed, 1 insertion(+), 47 deletions(-) diff --git a/source/guides/installing-using-linux-tools.rst b/source/guides/installing-using-linux-tools.rst index 637baac97..bd1eb4e15 100644 --- a/source/guides/installing-using-linux-tools.rst +++ b/source/guides/installing-using-linux-tools.rst @@ -32,20 +32,10 @@ Fedora * Fedora 33 & 34: - * Python 3: - .. code-block:: bash sudo dnf install python3 python3-wheel - * Python 2: - - .. code-block:: bash - - sudo dnf upgrade python-setuptools - sudo dnf install python-pip python-wheel - - To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions @@ -56,7 +46,6 @@ the `Copr Repo instructions sudo dnf upgrade python-setuptools sudo dnf install python-pip python-wheel - CentOS/RHEL ~~~~~~~~~~~ @@ -70,17 +59,10 @@ To install pip and wheel for the system Python, there are two options: `__. On EPEL 6 and EPEL7, you can install pip like so: - * Python3: - .. code-block:: bash sudo yum install python3-pip - * Python2: - - .. code-block:: bash - - sudo yum install python-pip On EPEL 7 (but not EPEL 6), you can install wheel like so: @@ -137,18 +119,10 @@ To install pip, wheel, and setuptools, in a parallel, non-system environment openSUSE ~~~~~~~~ -* Python 3: - .. code-block:: bash sudo zypper install python3-pip python3-setuptools python3-wheel -* Python 2: - - .. code-block:: bash - - sudo zypper install python-pip python-setuptools python-wheel - Debian/Ubuntu ~~~~~~~~~~~~~ @@ -157,19 +131,7 @@ Firstly, update and refresh repository lists by running this command: .. code-block:: bash sudo apt update - -* Python 3: - - .. code-block:: bash - - sudo apt install python3-venv python3-pip - -* Python 2: - - .. code-block:: bash - - sudo apt install python-pip - + sudo apt install python3-venv python3-pip .. warning:: @@ -181,18 +143,10 @@ Firstly, update and refresh repository lists by running this command: Arch Linux ~~~~~~~~~~ -* Python 3: - .. code-block:: bash sudo pacman -S python-pip -* Python 2: - - .. code-block:: bash - - sudo pacman -S python2-pip - ---- .. [1] Currently, there is no "copr" yum plugin available for CentOS/RHEL, so From b89e635a96978401f19cf8ec277347906a554d1e Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Mon, 26 Jul 2021 14:51:07 +0800 Subject: [PATCH 0033/1072] Update some commands --- .../guides/installing-using-linux-tools.rst | 23 ++++++------------- 1 file changed, 7 insertions(+), 16 deletions(-) diff --git a/source/guides/installing-using-linux-tools.rst b/source/guides/installing-using-linux-tools.rst index bd1eb4e15..cc2cfd8be 100644 --- a/source/guides/installing-using-linux-tools.rst +++ b/source/guides/installing-using-linux-tools.rst @@ -4,6 +4,9 @@ Installing pip/setuptools/wheel with Linux Package Managers =========================================================== +:Page Status: Incomplete +:Last Reviewed: 2021-07-26 + .. contents:: Contents :local: @@ -30,21 +33,9 @@ versions. When this is known, we will make note of it below. Fedora ~~~~~~ -* Fedora 33 & 34: - - .. code-block:: bash - - sudo dnf install python3 python3-wheel - -To get newer versions of pip, setuptools, and wheel for Python 2, you can enable -the `PyPA Copr Repo `_ using -the `Copr Repo instructions -`__, and then run: - .. code-block:: bash - sudo dnf upgrade python-setuptools - sudo dnf install python-pip python-wheel + sudo dnf install python3 python3-wheel CentOS/RHEL ~~~~~~~~~~~ @@ -68,7 +59,7 @@ To install pip and wheel for the system Python, there are two options: .. code-block:: bash - sudo yum install python-wheel + sudo yum install python3-wheel Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository. @@ -81,13 +72,13 @@ To install pip and wheel for the system Python, there are two options: .. code-block:: bash - sudo yum install python-pip python-wheel + sudo yum install python3-pip python3-wheel To additionally upgrade setuptools, run: .. code-block:: bash - sudo yum upgrade python-setuptools + sudo yum upgrade python3-setuptools To install pip, wheel, and setuptools, in a parallel, non-system environment From 14fc8538349773852fe61c99fae6be3abb70bde1 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Mon, 26 Jul 2021 14:59:51 +0800 Subject: [PATCH 0034/1072] Link the official Fedora docs --- source/guides/installing-using-linux-tools.rst | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/source/guides/installing-using-linux-tools.rst b/source/guides/installing-using-linux-tools.rst index cc2cfd8be..28d3f6aa2 100644 --- a/source/guides/installing-using-linux-tools.rst +++ b/source/guides/installing-using-linux-tools.rst @@ -37,6 +37,13 @@ Fedora sudo dnf install python3 python3-wheel +To learn more about Python in Fedora, please visit `official Fedora docs`_, +`Python Classroom`_ or `Fedora Loves Python`_. + +.. _official Fedora docs: https://developer.fedoraproject.org/tech/languages/python/python-installation.html +.. _Python Classroom: https://labs.fedoraproject.org/en/python-classroom/ +.. _Fedora Loves Python: https://fedoralovespython.org + CentOS/RHEL ~~~~~~~~~~~ From 4198f14348e01e55ba9e1ecde30e19fb62d30d6c Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Tue, 27 Jul 2021 11:46:00 +0800 Subject: [PATCH 0035/1072] Update source/guides/installing-using-linux-tools.rst Co-authored-by: Sviatoslav Sydorenko --- source/guides/installing-using-linux-tools.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/installing-using-linux-tools.rst b/source/guides/installing-using-linux-tools.rst index 28d3f6aa2..4f2ef9113 100644 --- a/source/guides/installing-using-linux-tools.rst +++ b/source/guides/installing-using-linux-tools.rst @@ -37,7 +37,7 @@ Fedora sudo dnf install python3 python3-wheel -To learn more about Python in Fedora, please visit `official Fedora docs`_, +To learn more about Python in Fedora, please visit the `official Fedora docs`_, `Python Classroom`_ or `Fedora Loves Python`_. .. _official Fedora docs: https://developer.fedoraproject.org/tech/languages/python/python-installation.html From 6150b9d6bc3ae7a605391cb3e27ed61929097b5d Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Tue, 27 Jul 2021 12:27:54 +0800 Subject: [PATCH 0036/1072] make the whitespace consistent --- source/guides/installing-using-linux-tools.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/source/guides/installing-using-linux-tools.rst b/source/guides/installing-using-linux-tools.rst index 4f2ef9113..ef85e0229 100644 --- a/source/guides/installing-using-linux-tools.rst +++ b/source/guides/installing-using-linux-tools.rst @@ -54,12 +54,12 @@ To install pip and wheel for the system Python, there are two options: 1. Enable the `EPEL repository `_ using `these instructions - `__. On - EPEL 6 and EPEL7, you can install pip like so: + `__. + On EPEL 6 and EPEL 7, you can install pip like so: - .. code-block:: bash + .. code-block:: bash - sudo yum install python3-pip + sudo yum install python3-pip On EPEL 7 (but not EPEL 6), you can install wheel like so: From e4ea4a1a5fbe901c71564f3fc3af6b56d51ee381 Mon Sep 17 00:00:00 2001 From: Henry Schreiner Date: Tue, 27 Jul 2021 02:57:05 -0700 Subject: [PATCH 0037/1072] Use packaging-problems templates (#956) * Use packaging-problems templates * Rename generic to general_issue Co-authored-by: Brian Rutledge --- source/support.rst | 2 +- source/tutorials/packaging-projects.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/source/support.rst b/source/support.rst index bf0ba7daf..7dc945eef 100644 --- a/source/support.rst +++ b/source/support.rst @@ -6,6 +6,6 @@ For support related to a specific project, see the links on the :doc:`Projects ` page. For something more general, or when you're just not sure, please -`open an issue `_ on +`open an issue `_ on the `packaging-problems `_ repository on GitHub. diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index bfc094436..15245a16d 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -11,7 +11,7 @@ to build the package, and how to upload it to the Python Package Index. and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you! -.. _open an issue: https://github.com/pypa/packaging-problems/issues/new?title=Trouble+with+packaging+tutorial +.. _open an issue: https://github.com/pypa/packaging-problems/issues/new?template=packaging_tutorial.yml&title=Trouble+with+the+packaging+tutorial&guide=https://packaging.python.org/tutorials/packaging-projects .. _packaging-problems: https://github.com/pypa/packaging-problems From 68d5dcbb2025cb6f9ee6215df234d9925992a824 Mon Sep 17 00:00:00 2001 From: Rafael Fontenelle Date: Sat, 14 Aug 2021 21:38:33 -0300 Subject: [PATCH 0038/1072] Make args names literal in distributing-packages --- ...distributing-packages-using-setuptools.rst | 81 ++++++++++--------- 1 file changed, 41 insertions(+), 40 deletions(-) diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index 7121bd6e3..bd129037d 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -160,8 +160,8 @@ taken from the `setup.py .. _`setup() name`: -name -~~~~ +``name`` +~~~~~~~~ :: @@ -186,8 +186,8 @@ declare a dependency on it using any of the following spellings:: CoOl__-.-__sTuFF -version -~~~~~~~ +``version`` +~~~~~~~~~~~ :: @@ -210,8 +210,8 @@ rather not duplicate the value, there are a few ways to manage this. See the .. _`description`: -description -~~~~~~~~~~~ +``description`` +~~~~~~~~~~~~~~~ :: @@ -241,8 +241,8 @@ to no formatting, `reStructuredText (reST) and the Github-flavored Markdown dialect of `Markdown `_ respectively. -url -~~~ +``url`` +~~~~~~~ :: @@ -252,8 +252,8 @@ url Give a homepage URL for your project. -author -~~~~~~ +``author`` +~~~~~~~~~~ :: @@ -263,8 +263,8 @@ author Provide details about the author. -license -~~~~~~~ +``license`` +~~~~~~~~~~~ :: @@ -276,15 +276,15 @@ so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses. -The "license" argument is more typically used to indicate differences +The ``license`` argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved. -classifiers -~~~~~~~~~~~ +``classifiers`` +~~~~~~~~~~~~~~~ :: @@ -323,8 +323,8 @@ Python versions a project can be installed on, use the :ref:`python_requires` argument. -keywords -~~~~~~~~ +``keywords`` +~~~~~~~~~~~~ :: @@ -333,8 +333,8 @@ keywords List keywords that describe your project. -project_urls -~~~~~~~~~~~~ +``project_urls`` +~~~~~~~~~~~~~~~~ :: @@ -351,8 +351,8 @@ bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI. -packages -~~~~~~~~ +``packages`` +~~~~~~~~~~~~ :: @@ -366,8 +366,8 @@ packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed. -py_modules -~~~~~~~~~~ +``py_modules`` +~~~~~~~~~~~~~~ :: @@ -378,8 +378,8 @@ package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them. -install_requires -~~~~~~~~~~~~~~~~ +``install_requires`` +~~~~~~~~~~~~~~~~~~~~ :: @@ -394,8 +394,8 @@ For more on using "install_requires" see :ref:`install_requires vs Requirements .. _python_requires: -python_requires -~~~~~~~~~~~~~~~ +``python_requires`` +~~~~~~~~~~~~~~~~~~~ If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier @@ -427,8 +427,8 @@ And so on. .. _`Package Data`: -package_data -~~~~~~~~~~~~ +``package_data`` +~~~~~~~~~~~~~~~~ :: @@ -453,8 +453,8 @@ For more information, see :std:doc:`Including Data Files .. _`Data Files`: -data_files -~~~~~~~~~~ +``data_files`` +~~~~~~~~~~~~~~ :: @@ -487,8 +487,8 @@ For more information see the distutils section on `Installing Additional Files then you need to pass the ``--old-and-unmanageable`` option. -scripts -~~~~~~~ +``scripts`` +~~~~~~~~~~~ Although ``setup()`` supports a `scripts `_ @@ -496,8 +496,8 @@ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below). -entry_points -~~~~~~~~~~~~ +``entry_points`` +~~~~~~~~~~~~~~~~ :: @@ -517,8 +517,8 @@ The most commonly used entry point is "console_scripts" (see below). .. _`console_scripts`: -console_scripts -*************** +``console_scripts`` +******************* :: @@ -528,7 +528,7 @@ console_scripts ], }, -Use "console_script" `entry points +Use ``console_script`` `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be @@ -674,8 +674,9 @@ Assuming you're in the root of your project directory, then run: Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any -dependencies declared with "install_requires" and any scripts declared with -"console_scripts". Dependencies will be installed in the usual, non-editable mode. +dependencies declared with ``install_requires`` and any scripts declared with +``console_scripts``. Dependencies will be installed in the usual, non-editable +mode. It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires "foo" and "bar", but From 4d05c0c9a37c71633538b941fb353b25c5e5e8b8 Mon Sep 17 00:00:00 2001 From: Rafael Fontenelle Date: Sat, 14 Aug 2021 21:41:13 -0300 Subject: [PATCH 0039/1072] Minor adjustment in paragraph --- source/guides/distributing-packages-using-setuptools.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index bd129037d..771469770 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -466,14 +466,14 @@ cases you may need to place data files *outside* of your :term:`packages It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages. -Each ``(directory, files)`` pair in the sequence specifies the installation -directory and the files to install there. The ``directory`` must be a relative +Each "(directory, files)" pair in the sequence specifies the installation +directory and the files to install there. The "directory" must be a relative path (although this may change in the future, see -`wheel Issue #92 `_). +`wheel Issue #92 `_), and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). -Each file name in ``files`` is interpreted relative to the :file:`setup.py` +Each file name in "files" is interpreted relative to the :file:`setup.py` script at the top of the project source distribution. For more information see the distutils section on `Installing Additional Files From bdeebc99262e965e0ff9d7371b393dc8b7bc2db1 Mon Sep 17 00:00:00 2001 From: Rafael Fontenelle Date: Sun, 15 Aug 2021 07:28:09 -0300 Subject: [PATCH 0040/1072] Undo inline code syntax removal --- source/guides/distributing-packages-using-setuptools.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index 771469770..e2272dd4a 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -466,14 +466,14 @@ cases you may need to place data files *outside* of your :term:`packages It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages. -Each "(directory, files)" pair in the sequence specifies the installation -directory and the files to install there. The "directory" must be a relative +Each ``(directory, files)`` pair in the sequence specifies the installation +directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_), and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). -Each file name in "files" is interpreted relative to the :file:`setup.py` +Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution. For more information see the distutils section on `Installing Additional Files From 0f0d5e19a35e51ccd4844174083ac07a8c078e9d Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Mon, 16 Aug 2021 17:11:21 +0800 Subject: [PATCH 0041/1072] Fix invalid command --- source/tutorials/installing-packages.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst index f2d522612..ccda474f0 100644 --- a/source/tutorials/installing-packages.rst +++ b/source/tutorials/installing-packages.rst @@ -653,7 +653,7 @@ Install `setuptools extras`_. python3 -m pip install SomePackage[PDF] python3 -m pip install SomePackage[PDF]==3.0 - python3 -m pip install -e .[PDF]==3.0 # editable project in current directory + python3 -m pip install -e .[PDF] # editable project in current directory .. tab:: Windows @@ -661,7 +661,7 @@ Install `setuptools extras`_. py -m pip install SomePackage[PDF] py -m pip install SomePackage[PDF]==3.0 - py -m pip install -e .[PDF]==3.0 # editable project in current directory + py -m pip install -e .[PDF] # editable project in current directory ---- From 1eabb0c6cfdd2d64cd8c9d393ee49617693444e5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20G=C3=BCttler?= Date: Thu, 19 Aug 2021 21:58:59 +0200 Subject: [PATCH 0042/1072] bento has seen to update since 2014. No update since 7 years. I think "less is more", and removed it from the list. --- source/key_projects.rst | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/source/key_projects.rst b/source/key_projects.rst index 91db7c462..d6b8b4c9c 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -323,21 +323,6 @@ libraries in a package. Non-PyPA Projects ################# -.. _bento: - -bento -===== - -`Docs `__ | -`Issues `__ | -`GitHub `__ | -`PyPI `__ - -Bento is a packaging tool solution for Python software, targeted as an -alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's -philosophy is reproducibility, extensibility and simplicity (in that -order). - .. _buildout: buildout From 7e8f97bba574e89f5cf576970ed1c75e655f09ab Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Sun, 22 Aug 2021 06:04:27 -0400 Subject: [PATCH 0043/1072] Copy-edit TestPyPI guide --- source/guides/using-testpypi.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/source/guides/using-testpypi.rst b/source/guides/using-testpypi.rst index f4f05d719..1d466e4ea 100644 --- a/source/guides/using-testpypi.rst +++ b/source/guides/using-testpypi.rst @@ -13,10 +13,10 @@ Registering your account ------------------------ Because TestPyPI has a separate database from the live PyPI, you'll need a -separate user account for specifically for TestPyPI. Go to +separate user account specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account. -.. Note:: The database for TestPyPI may be periodically pruned, so it is not +.. note:: The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted. @@ -24,7 +24,7 @@ Using TestPyPI with Twine ------------------------- You can upload your distributions to TestPyPI using :ref:`twine` by specifying -the ``--repository`` flag +the ``--repository`` flag: .. code-block:: bash @@ -38,8 +38,8 @@ your project to appear on the site. Using TestPyPI with pip ----------------------- -You can tell pip to download packages from TestPyPI instead of PyPI by -specifying the ``--index-url`` flag +You can tell :ref:`pip` to download packages from TestPyPI instead of PyPI by +specifying the ``--index-url`` flag: .. tab:: Unix/macOS @@ -53,7 +53,7 @@ specifying the ``--index-url`` flag py -m pip install --index-url https://test.pypi.org/simple/ your-package -If you want to allow pip to also pull other packages from PyPI you can +If you want to allow pip to also download packages from PyPI, you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies: @@ -61,13 +61,13 @@ you're testing has dependencies: .. code-block:: bash - python3 -m pip install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple your-package + python3 -m pip install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple/ your-package .. tab:: Windows .. code-block:: bat - py -m pip install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple your-package + py -m pip install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple/ your-package Setting up TestPyPI in :file:`.pypirc` -------------------------------------- From 519f3ef48cd7fe82d69445525ed3a58db0c6573b Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Sun, 22 Aug 2021 18:34:04 +0800 Subject: [PATCH 0044/1072] Use dnf instead of yum --- .../guides/installing-using-linux-tools.rst | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/source/guides/installing-using-linux-tools.rst b/source/guides/installing-using-linux-tools.rst index ef85e0229..fc0e50311 100644 --- a/source/guides/installing-using-linux-tools.rst +++ b/source/guides/installing-using-linux-tools.rst @@ -35,7 +35,7 @@ Fedora .. code-block:: bash - sudo dnf install python3 python3-wheel + sudo dnf install python3-pip python3-wheel To learn more about Python in Fedora, please visit the `official Fedora docs`_, `Python Classroom`_ or `Fedora Loves Python`_. @@ -55,19 +55,12 @@ To install pip and wheel for the system Python, there are two options: 1. Enable the `EPEL repository `_ using `these instructions `__. - On EPEL 6 and EPEL 7, you can install pip like so: + On EPEL 7, you can install pip and wheel like so: .. code-block:: bash - sudo yum install python3-pip - - - On EPEL 7 (but not EPEL 6), you can install wheel like so: - - .. code-block:: bash - - sudo yum install python3-wheel - + sudo dnf install python3-pip python3-wheel + Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository. @@ -79,13 +72,13 @@ To install pip and wheel for the system Python, there are two options: .. code-block:: bash - sudo yum install python3-pip python3-wheel + sudo dnf install python3-pip python3-wheel To additionally upgrade setuptools, run: .. code-block:: bash - sudo yum upgrade python3-setuptools + sudo dnf upgrade python3-setuptools To install pip, wheel, and setuptools, in a parallel, non-system environment From 1c2e0bedb1f84a21c4da8abd4c0e48889f7f3d7e Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Sun, 22 Aug 2021 18:43:10 +0800 Subject: [PATCH 0045/1072] Make the whitespace consistent --- source/guides/installing-using-linux-tools.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/source/guides/installing-using-linux-tools.rst b/source/guides/installing-using-linux-tools.rst index fc0e50311..d1c2ee732 100644 --- a/source/guides/installing-using-linux-tools.rst +++ b/source/guides/installing-using-linux-tools.rst @@ -60,9 +60,9 @@ To install pip and wheel for the system Python, there are two options: .. code-block:: bash sudo dnf install python3-pip python3-wheel - - Since EPEL only offers extra, non-conflicting packages, EPEL does not offer - setuptools, since it's in the core repository. + + Since EPEL only offers extra, non-conflicting packages, EPEL does not offer + setuptools, since it's in the core repository. 2. Enable the `PyPA Copr Repo From 2c238a3e9e7f86eb24560ce54c294f0d6c7d75f1 Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Sun, 22 Aug 2021 18:47:20 +0800 Subject: [PATCH 0046/1072] Make the whitespace consistent --- source/guides/installing-using-linux-tools.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/installing-using-linux-tools.rst b/source/guides/installing-using-linux-tools.rst index d1c2ee732..8f12a4dfe 100644 --- a/source/guides/installing-using-linux-tools.rst +++ b/source/guides/installing-using-linux-tools.rst @@ -59,7 +59,7 @@ To install pip and wheel for the system Python, there are two options: .. code-block:: bash - sudo dnf install python3-pip python3-wheel + sudo dnf install python3-pip python3-wheel Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository. From 40b7cb9b866d063413ce9c7ce617bc028663fd15 Mon Sep 17 00:00:00 2001 From: Yifei Xu Date: Mon, 23 Aug 2021 17:25:19 -0400 Subject: [PATCH 0047/1072] Fix typo ("tutoral" -> "tutorial") (#962) Pretty minor change but nice to fix typos I guess --- source/tutorials/packaging-projects.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index 15245a16d..acc854032 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -7,7 +7,7 @@ to build the package, and how to upload it to the Python Package Index. .. tip:: - If you have trouble running the commands in this tutoral, please copy the command + If you have trouble running the commands in this tutorial, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you! From fc8ffc9c8a82971f5217b88f66e285bf3940ad97 Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Tue, 24 Aug 2021 16:21:14 +0800 Subject: [PATCH 0048/1072] Fix a broken link --- source/guides/index-mirrors-and-caches.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/index-mirrors-and-caches.rst b/source/guides/index-mirrors-and-caches.rst index 284665eb0..9a1c5d41c 100644 --- a/source/guides/index-mirrors-and-caches.rst +++ b/source/guides/index-mirrors-and-caches.rst @@ -35,7 +35,7 @@ cached copies of :term:`packages `: those downloaded files instead of going to PyPI. 2. A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel - `_: + `_: .. code-block:: bash From cf22b4523589185ee3de96624e95dd67d185291b Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Tue, 24 Aug 2021 17:15:09 +0800 Subject: [PATCH 0049/1072] `Mac OS X/OS X` -> `macOS` --- source/discussions/deploying-python-applications.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/source/discussions/deploying-python-applications.rst b/source/discussions/deploying-python-applications.rst index f2bb5f756..989ca2e89 100644 --- a/source/discussions/deploying-python-applications.rst +++ b/source/discussions/deploying-python-applications.rst @@ -102,19 +102,19 @@ Public License 2.0. .. __: https://devguide.python.org/#status-of-python-branches -Mac OS ------- +macOS +----- py2app ^^^^^^ `py2app `__ is a Python setuptools -command which will allow you to make standalone Mac OS X application +command which will allow you to make standalone macOS application bundles and plugins from Python scripts. Note that py2app MUST be used -on OSX to build applications, it cannot create Mac applications on other +on macOS to build applications, it cannot create Mac applications on other platforms. py2app is released under the MIT-license. -Unix (including Linux and Mac OS X) +Unix (including Linux and macOS) ----------------------------------- pex @@ -125,7 +125,7 @@ pex spirit of virtualenvs. pex is an expansion upon the ideas outlined in :pep:`441` and makes the deployment of Python applications as simple as cp. pex files may even include multiple platform-specific Python distributions, meaning that a -single pex file can be portable across Linux and OS X. pex is released under the +single pex file can be portable across Linux and macOS. pex is released under the Apache License 2.0. Configuration management From 0b1ee1390b8b9e8506d438c89a20092b9b4ebefa Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Tue, 24 Aug 2021 17:16:03 +0800 Subject: [PATCH 0050/1072] Update reviewed date --- source/discussions/deploying-python-applications.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/discussions/deploying-python-applications.rst b/source/discussions/deploying-python-applications.rst index 989ca2e89..d1bd91c05 100644 --- a/source/discussions/deploying-python-applications.rst +++ b/source/discussions/deploying-python-applications.rst @@ -4,7 +4,7 @@ Deploying Python applications ============================= :Page Status: Incomplete -:Last Reviewed: 2014-11-11 +:Last Reviewed: 2021-8-24 .. contents:: Contents :local: From cfa58cd016cd8a1e935bf2db144a8189151bc60a Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Tue, 24 Aug 2021 17:47:06 +0800 Subject: [PATCH 0051/1072] Use intersphinx references --- source/guides/index-mirrors-and-caches.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/source/guides/index-mirrors-and-caches.rst b/source/guides/index-mirrors-and-caches.rst index 9a1c5d41c..fdfece50a 100644 --- a/source/guides/index-mirrors-and-caches.rst +++ b/source/guides/index-mirrors-and-caches.rst @@ -34,8 +34,7 @@ cached copies of :term:`packages `: by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI. 2. A variation on the above which pre-builds the installation files for - the requirements using `python -m pip wheel - `_: + the requirements using :ref:`python -m pip wheel `: .. code-block:: bash From 9c1f339af1480c6affda784ec1dd5b59446cd336 Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Tue, 24 Aug 2021 18:26:43 +0800 Subject: [PATCH 0052/1072] Add a comment for cron --- .github/workflows/translation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index b4c1fd35b..a0001e765 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -2,7 +2,7 @@ name: Translation on: schedule: - - cron: '00 00,00 * * sun' + - cron: '00 00,00 * * sun' # Runs at 00:00 UTC on Sunday jobs: build: From 622d8265dbc8a093ce13d17f3af0e6fe555fca00 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Tue, 24 Aug 2021 20:01:08 +0800 Subject: [PATCH 0053/1072] FIx a broken link --- source/tutorials/installing-packages.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst index ccda474f0..201980283 100644 --- a/source/tutorials/installing-packages.rst +++ b/source/tutorials/installing-packages.rst @@ -298,8 +298,7 @@ Use pip for Installing :ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, -which includes a complete `Reference Guide -`_. +which includes a complete :std:doc:`Reference Guide `. Installing from PyPI From 33dbcf5a5661b28348793d65c7a23b129b64f1e3 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Tue, 24 Aug 2021 20:07:57 +0800 Subject: [PATCH 0054/1072] Use intersphinx references --- source/guides/index-mirrors-and-caches.rst | 2 +- source/tutorials/installing-packages.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/source/guides/index-mirrors-and-caches.rst b/source/guides/index-mirrors-and-caches.rst index fdfece50a..e765a5d07 100644 --- a/source/guides/index-mirrors-and-caches.rst +++ b/source/guides/index-mirrors-and-caches.rst @@ -34,7 +34,7 @@ cached copies of :term:`packages `: by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI. 2. A variation on the above which pre-builds the installation files for - the requirements using :ref:`python -m pip wheel `: + the requirements using :ref:`python -m pip wheel `: .. code-block:: bash diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst index 201980283..ab5156fb5 100644 --- a/source/tutorials/installing-packages.rst +++ b/source/tutorials/installing-packages.rst @@ -298,7 +298,7 @@ Use pip for Installing :ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, -which includes a complete :std:doc:`Reference Guide `. +which includes a complete :doc:`Reference Guide `. Installing from PyPI From b24d52d370699a5854d1d2578b6586681406fb6c Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Wed, 25 Aug 2021 00:12:57 +0800 Subject: [PATCH 0055/1072] Use `failure()` Co-authored-by: Sviatoslav Sydorenko --- .github/workflows/translation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index a0001e765..025af8a66 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -30,7 +30,7 @@ jobs: git commit -m "Update messages.pot ${git_hash}" locales/messages.pot - name: Check on failures - if: ${{job.status == 'failure'}} + if: failure() run: echo "No Changes!" - name: Push changes From b7d3cdb603c97910773c6c5ad2602949ba415656 Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Wed, 25 Aug 2021 00:19:19 +0800 Subject: [PATCH 0056/1072] Update comment Co-authored-by: Sviatoslav Sydorenko --- .github/workflows/translation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index 025af8a66..1703ca48a 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -19,7 +19,7 @@ jobs: - name: Install Dependencies run: python -m pip install --upgrade nox virtualenv - - name: Create local changes + - name: Generate a fresh POT file out of RST documents run: python -m nox -s translation - name: Commit files From 88645afa6f8441fe06f593a53506f63e26e8bcaa Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Wed, 25 Aug 2021 00:19:41 +0800 Subject: [PATCH 0057/1072] Update .github/workflows/translation.yml Co-authored-by: Sviatoslav Sydorenko --- .github/workflows/translation.yml | 1 - 1 file changed, 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index 1703ca48a..c7e7d2f59 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -36,4 +36,3 @@ jobs: - name: Push changes run: | git push --atomic origin main - From 6d488423b1382a425ee5ab5b4597b9fe86a8e2dd Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Wed, 25 Aug 2021 00:19:50 +0800 Subject: [PATCH 0058/1072] Update .github/workflows/translation.yml Co-authored-by: Sviatoslav Sydorenko --- .github/workflows/translation.yml | 1 - 1 file changed, 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index c7e7d2f59..de29d3fed 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -28,7 +28,6 @@ jobs: git config --local user.name "github-actions[bot]" git_hash=$(git rev-parse --short "$GITHUB_SHA") git commit -m "Update messages.pot ${git_hash}" locales/messages.pot - - name: Check on failures if: failure() run: echo "No Changes!" From 13b6460d29e0bcf4c0c660f65d83eb29ccf4a2ba Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Wed, 25 Aug 2021 00:20:02 +0800 Subject: [PATCH 0059/1072] Update name Co-authored-by: Sviatoslav Sydorenko --- .github/workflows/translation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index de29d3fed..4aa9b8043 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -22,7 +22,7 @@ jobs: - name: Generate a fresh POT file out of RST documents run: python -m nox -s translation - - name: Commit files + - name: Commit the POT file to Git run: | git config --local user.email "github-actions[bot]@users.noreply.github.com" git config --local user.name "github-actions[bot]" From 5b8faa975efff21299d7104168a0fe6dde19b44e Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Wed, 25 Aug 2021 00:20:21 +0800 Subject: [PATCH 0060/1072] Update commit message Co-authored-by: Sviatoslav Sydorenko --- .github/workflows/translation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index 4aa9b8043..c752afa2d 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -27,7 +27,7 @@ jobs: git config --local user.email "github-actions[bot]@users.noreply.github.com" git config --local user.name "github-actions[bot]" git_hash=$(git rev-parse --short "$GITHUB_SHA") - git commit -m "Update messages.pot ${git_hash}" locales/messages.pot + git commit -m "Update messages.pot as of version ${git_hash}" locales/messages.pot - name: Check on failures if: failure() run: echo "No Changes!" From 238397a96aa25da36e83c4f28e7b9b418fa83fb5 Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Wed, 25 Aug 2021 00:22:00 +0800 Subject: [PATCH 0061/1072] Update the message Co-authored-by: Sviatoslav Sydorenko --- .github/workflows/translation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index c752afa2d..b7279a118 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -30,7 +30,7 @@ jobs: git commit -m "Update messages.pot as of version ${git_hash}" locales/messages.pot - name: Check on failures if: failure() - run: echo "No Changes!" + run: echo "There are no changes to the RST sources since the last update. Nothing to do." - name: Push changes run: | From 8b2e3a4c9c90e70504f85e89d6a07b737e0ebc0c Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Wed, 25 Aug 2021 00:22:14 +0800 Subject: [PATCH 0062/1072] Update name Co-authored-by: Sviatoslav Sydorenko --- .github/workflows/translation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index b7279a118..29d22b936 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -28,7 +28,7 @@ jobs: git config --local user.name "github-actions[bot]" git_hash=$(git rev-parse --short "$GITHUB_SHA") git commit -m "Update messages.pot as of version ${git_hash}" locales/messages.pot - - name: Check on failures + - name: Check if any sources have changed since the last update if: failure() run: echo "There are no changes to the RST sources since the last update. Nothing to do." From 28d37351386a397adfe2e26a7ba650e9de54d3da Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Wed, 25 Aug 2021 00:22:26 +0800 Subject: [PATCH 0063/1072] Update name Co-authored-by: Sviatoslav Sydorenko --- .github/workflows/translation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index 29d22b936..9b28c150f 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -16,7 +16,7 @@ jobs: with: python-version: 3.9 - - name: Install Dependencies + - name: Install Python tooling run: python -m pip install --upgrade nox virtualenv - name: Generate a fresh POT file out of RST documents From 8f3530ee4b00988b959d6093fb76d16d87b23229 Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Wed, 25 Aug 2021 00:22:56 +0800 Subject: [PATCH 0064/1072] Update .github/workflows/translation.yml Co-authored-by: Sviatoslav Sydorenko --- .github/workflows/translation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index 9b28c150f..23e4b0277 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -26,7 +26,7 @@ jobs: run: | git config --local user.email "github-actions[bot]@users.noreply.github.com" git config --local user.name "github-actions[bot]" - git_hash=$(git rev-parse --short "$GITHUB_SHA") + git_hash=$(git rev-parse --short "${GITHUB_SHA}") git commit -m "Update messages.pot as of version ${git_hash}" locales/messages.pot - name: Check if any sources have changed since the last update if: failure() From 9da5275b121e3ffe23637da7e8e9dfac0bfbae82 Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Wed, 25 Aug 2021 00:24:20 +0800 Subject: [PATCH 0065/1072] Update name Co-authored-by: Sviatoslav Sydorenko --- .github/workflows/translation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index 23e4b0277..194f9005f 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -32,6 +32,6 @@ jobs: if: failure() run: echo "There are no changes to the RST sources since the last update. Nothing to do." - - name: Push changes + - name: Push the updated POT file back to ${{ github.repository }} on GitHub run: | git push --atomic origin main From b1109a348beba9cfe1c5ed0aacc87f003ba2fefc Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Wed, 25 Aug 2021 00:25:05 +0800 Subject: [PATCH 0066/1072] Update .github/workflows/translation.yml Co-authored-by: Sviatoslav Sydorenko --- .github/workflows/translation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index 194f9005f..10240a11c 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -34,4 +34,4 @@ jobs: - name: Push the updated POT file back to ${{ github.repository }} on GitHub run: | - git push --atomic origin main + git push --atomic origin HEAD:${{ github.event.repository.default_branch }} From b7e9720b2e056cce6a839431746ed6efdf81d476 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Tue, 24 Aug 2021 18:25:43 +0200 Subject: [PATCH 0067/1072] Make the push step name more specific --- .github/workflows/translation.yml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index 10240a11c..5038e462a 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -32,6 +32,9 @@ jobs: if: failure() run: echo "There are no changes to the RST sources since the last update. Nothing to do." - - name: Push the updated POT file back to ${{ github.repository }} on GitHub + - name: >- + Push the updated POT file back to + ${{ github.repository }}@${{ github.event.repository.default_branch }} + on GitHub run: | git push --atomic origin HEAD:${{ github.event.repository.default_branch }} From 897d10adb2b1a0e72758e158d96a75f732bcc289 Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Wed, 25 Aug 2021 00:27:31 +0800 Subject: [PATCH 0068/1072] Add name Co-authored-by: Sviatoslav Sydorenko --- .github/workflows/translation.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index 5038e462a..4d28ed393 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -9,7 +9,8 @@ jobs: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v2 + - name: Grab the repo src + uses: actions/checkout@v2 - name: Set up Python uses: actions/setup-python@v2 From d5a9b5de233c65f7c766126401e0b75e6425a7a8 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Tue, 24 Aug 2021 18:36:42 +0200 Subject: [PATCH 0069/1072] Trigger the translation workflow on the test completion --- .github/workflows/translation.yml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index 4d28ed393..2237b44e0 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -1,6 +1,13 @@ name: Translation on: + workflow_run: + workflows: + - Test + branches: + - main + types: + - completed schedule: - cron: '00 00,00 * * sun' # Runs at 00:00 UTC on Sunday From f1a0b0be5d3bebbb459e1e1222d5c089c6afab7d Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Wed, 25 Aug 2021 00:38:15 +0800 Subject: [PATCH 0070/1072] Remove cron time --- .github/workflows/translation.yml | 2 -- 1 file changed, 2 deletions(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index 2237b44e0..2513c0715 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -8,8 +8,6 @@ on: - main types: - completed - schedule: - - cron: '00 00,00 * * sun' # Runs at 00:00 UTC on Sunday jobs: build: From 4010107771c2d3cfc96aa19539d22e9db7f4eb96 Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Wed, 25 Aug 2021 00:39:33 +0800 Subject: [PATCH 0071/1072] Add a space --- .github/workflows/translation.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index 2513c0715..4638e5c4e 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -34,6 +34,7 @@ jobs: git config --local user.name "github-actions[bot]" git_hash=$(git rev-parse --short "${GITHUB_SHA}") git commit -m "Update messages.pot as of version ${git_hash}" locales/messages.pot + - name: Check if any sources have changed since the last update if: failure() run: echo "There are no changes to the RST sources since the last update. Nothing to do." From f54c752e49b56e28bfddd31e40b9c9bc4006b9c8 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Thu, 26 Aug 2021 00:04:26 +0800 Subject: [PATCH 0072/1072] Use intersphinx references --- source/glossary.rst | 5 ++--- .../distributing-packages-using-setuptools.rst | 16 ++++++++-------- source/guides/index-mirrors-and-caches.rst | 3 +-- ...alling-using-pip-and-virtual-environments.rst | 6 ++---- source/guides/packaging-binary-extensions.rst | 4 ++-- source/guides/packaging-namespace-packages.rst | 5 ++--- source/guides/tool-recommendations.rst | 5 ++--- source/overview.rst | 10 +++++----- source/tutorials/installing-packages.rst | 16 ++++++++-------- source/tutorials/managing-dependencies.rst | 4 ++-- 10 files changed, 34 insertions(+), 40 deletions(-) diff --git a/source/glossary.rst b/source/glossary.rst index 55041cbd7..c4ac86c7a 100644 --- a/source/glossary.rst +++ b/source/glossary.rst @@ -42,9 +42,8 @@ Glossary Egg A :term:`Built Distribution` format introduced by :ref:`setuptools`, - which is being replaced by :term:`Wheel`. For details, see `The - Internal Structure of Python Eggs - `_ and + which is being replaced by :term:`Wheel`. For details, see ` + :doc:`The Internal Structure of Python Eggs ` and `Python Eggs `_ Extension Module diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index e2272dd4a..fecffddbd 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -509,8 +509,8 @@ points (see below). Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on. -For more information, see the section on `Advertising Behavior -`_ +For more information, see the section on +:ref:`Advertising Behavior ` from the :ref:`setuptools` docs. The most commonly used entry point is "console_scripts" (see below). @@ -528,8 +528,8 @@ The most commonly used entry point is "console_scripts" (see below). ], }, -Use ``console_script`` `entry points -`_ +Use ``console_script`` +:ref:`entry points ` to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `. For more information, see `Automatic Script Creation `_ -from the `setuptools docs `_. +from the :doc:`setuptools docs `. .. _`Choosing a versioning scheme`: @@ -706,9 +706,9 @@ Lastly, if you don't want to install any dependencies at all, you can run: python -m pip install -e . --no-deps -For more information, see the `Development Mode -`_ section -of the `setuptools docs `_. +For more information, see the +:doc:`` section +of the :doc:`setuptools docs `. .. _`Packaging your project`: diff --git a/source/guides/index-mirrors-and-caches.rst b/source/guides/index-mirrors-and-caches.rst index e765a5d07..d960e7bee 100644 --- a/source/guides/index-mirrors-and-caches.rst +++ b/source/guides/index-mirrors-and-caches.rst @@ -29,8 +29,7 @@ Caching with pip pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `: -1. `Fast & local installs - `_ +1. :ref:`Fast & local installs ` by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI. 2. A variation on the above which pre-builds the installation files for diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst index 1a369763b..16b7a2cfb 100644 --- a/source/guides/installing-using-pip-and-virtual-environments.rst +++ b/source/guides/installing-using-pip-and-virtual-environments.rst @@ -323,7 +323,8 @@ pip can install a package directly from source, for example: cd google-auth py -m pip install . -Additionally, pip can install packages from source in `development mode`_, +Additionally, pip can install packages from source in +:doc:`development mode `, meaning that changes to the source directory will immediately affect the installed package without needing to re-install: @@ -339,9 +340,6 @@ installed package without needing to re-install: py -m pip install --editable . -.. _development mode: - https://setuptools.readthedocs.io/en/latest/setuptools.html#development-mode - Installing from version control systems --------------------------------------- diff --git a/source/guides/packaging-binary-extensions.rst b/source/guides/packaging-binary-extensions.rst index f3d42fb82..001787b97 100644 --- a/source/guides/packaging-binary-extensions.rst +++ b/source/guides/packaging-binary-extensions.rst @@ -221,9 +221,9 @@ above to make the interface available as an importable Python module. Implementing binary extensions ============================== -The CPython `Extending and Embedding `_ +The CPython :doc:`Extending and Embedding ` guide includes an introduction to writing a -`custom extension module in C `_. +:doc:`custom extension module in C `. :: diff --git a/source/guides/packaging-namespace-packages.rst b/source/guides/packaging-namespace-packages.rst index aac7c2652..dd3c0f4b7 100644 --- a/source/guides/packaging-namespace-packages.rst +++ b/source/guides/packaging-namespace-packages.rst @@ -128,8 +128,8 @@ the `native namespace package example project`_. pkgutil-style namespace packages -------------------------------- -Python 2.3 introduced the `pkgutil`_ module and the -`extend_path`_ function. This can be used to declare namespace +Python 2.3 introduced the :doc:`pkgutil ` module and the +:py:func:`python:pkgutil.extend_path` function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility. @@ -160,7 +160,6 @@ additional code in :file:`__init__.py` will be inaccessible. A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_. -.. _pkgutil: https://docs.python.org/3/library/pkgutil.html .. _extend_path: https://docs.python.org/3/library/pkgutil.html#pkgutil.extend_path .. _pkgutil namespace example project: diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst index cd7996b00..54acc1e33 100644 --- a/source/guides/tool-recommendations.rst +++ b/source/guides/tool-recommendations.rst @@ -31,8 +31,8 @@ Installation tool recommendations is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_ -* Use :ref:`virtualenv`, or `venv`_ to isolate application specific - dependencies from a shared Python installation. [4]_ +* Use :ref:`virtualenv`, or :doc:`venv ` to isolate application + specific dependencies from a shared Python installation. [4]_ * If you're looking for management of fully integrated cross-platform software stacks, consider: @@ -111,4 +111,3 @@ migration, and what settings to change in your clients. choice for packaging. .. _distribute: https://pypi.org/project/distribute -.. _venv: https://docs.python.org/3/library/venv.html diff --git a/source/overview.rst b/source/overview.rst index 3ed4f2141..c4fdaaf18 100644 --- a/source/overview.rst +++ b/source/overview.rst @@ -94,8 +94,8 @@ you can use Python's native packaging tools to create a *source* Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is -pure-Python, and you only depend on other Python packages, you can `go -here to learn more `_. +pure-Python, and you only depend on other Python packages, you can +:doc:`go here to learn more `. If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of @@ -166,8 +166,8 @@ audience. Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's -library packaging, using technologies like `setuptools entry_points -`_. +library packaging, using technologies like +:doc:`setuptools entry_points `. Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies @@ -249,7 +249,7 @@ machines of developers and data scientists. Technologies which support this model: * `PEX `_ (Python EXecutable) -* `zipapp `_ (does not help manage dependencies, requires Python 3.5+) +* :doc:`zipapp ` (does not help manage dependencies, requires Python 3.5+) * `shiv `_ (requires Python 3) .. note:: Of all the approaches here, depending on a pre-installed diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst index ab5156fb5..f6bb02b79 100644 --- a/source/tutorials/installing-packages.rst +++ b/source/tutorials/installing-packages.rst @@ -178,7 +178,7 @@ Optionally, create a virtual environment ---------------------------------------- See :ref:`section below ` for details, -but here's the basic `venv`_ [3]_ command to use on a typical Linux system: +but here's the basic :doc:`venv ` [3]_ command to use on a typical Linux system: .. tab:: Unix/macOS @@ -228,7 +228,7 @@ environments. Currently, there are two common tools for creating Python virtual environments: -* `venv`_ is available by default in Python 3.3 and later, and installs +* :doc:`venv ` is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later. * :ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ @@ -238,7 +238,7 @@ Currently, there are two common tools for creating Python virtual environments: The basic usage is like so: -Using `venv`_: +Using :doc:`venv `: .. tab:: Unix/macOS @@ -270,7 +270,8 @@ Using :ref:`virtualenv`: virtualenv \Scripts\activate -For more information, see the `venv`_ docs or the `virtualenv `_ docs. +For more information, see the :doc:`venv ` docs or +the `virtualenv `_ docs. The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current @@ -297,7 +298,7 @@ Use pip for Installing ====================== :ref:`pip` is the recommended installer. Below, we'll cover the most common -usage scenarios. For more detail, see the `pip docs `_, +usage scenarios. For more detail, see the :doc:`pip docs `, which includes a complete :doc:`Reference Guide `. @@ -542,8 +543,8 @@ Installing from a local src tree ================================ -Installing from local src in `Development Mode -`_, +Installing from local src in +:doc:`Development Mode `, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree. @@ -682,5 +683,4 @@ Install `setuptools extras`_. and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0 -.. _venv: https://docs.python.org/3/library/venv.html .. _setuptools extras: https://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-extras-optional-features-with-their-own-dependencies diff --git a/source/tutorials/managing-dependencies.rst b/source/tutorials/managing-dependencies.rst index 99b889ca1..6eb94b1b6 100644 --- a/source/tutorials/managing-dependencies.rst +++ b/source/tutorials/managing-dependencies.rst @@ -53,12 +53,12 @@ Use ``pip`` to install Pipenv: .. Note:: This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, - you'll need to add the `user base`_'s binary directory to your ``PATH``. + you'll need to add the :py:data:`user base `'s + binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information. .. _npm: https://www.npmjs.com/ .. _bundler: http://bundler.io/ -.. _user base: https://docs.python.org/3/library/site.html#site.USER_BASE .. _user installation: https://pip.pypa.io/en/stable/user_guide/#user-installs Installing packages for your project From 2e80e845a6e4e380f4809212eb7fca370d0089dc Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Thu, 26 Aug 2021 21:32:05 +0800 Subject: [PATCH 0073/1072] Use Python 3.9 for the workflow --- .../github-actions-ci-cd-sample/publish-to-test-pypi.yml | 4 ++-- ...ribution-releases-using-github-actions-ci-cd-workflows.rst | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index 361203b49..c24d08091 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -9,10 +9,10 @@ jobs: steps: - uses: actions/checkout@master - - name: Set up Python 3.7 + - name: Set up Python 3.9 uses: actions/setup-python@v1 with: - python-version: 3.7 + python-version: 3.9 - name: Install pypa/build run: >- python -m diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index 4dd1969b6..bd8ea42eb 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -90,7 +90,7 @@ Then, add the following under the ``build-n-publish`` section: :end-before: Install pypa/build This will download your repository into the CI runner and then -install and activate Python 3.7. +install and activate Python 3.9. And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a @@ -107,7 +107,7 @@ So add this to the steps list: .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml - :start-after: version: 3.7 + :start-after: version: 3.9 :end-before: Actually publish to PyPI/TestPyPI From dcb3add9cd8c0237b0b4e32fadb26332e0a99c71 Mon Sep 17 00:00:00 2001 From: Wes Turner <50891+westurner@users.noreply.github.com> Date: Fri, 27 Aug 2021 07:49:42 -0400 Subject: [PATCH 0074/1072] DOC: source/guides/distributing-packages-using-setuptools.rst: remove extra pip install -e Co-authored-by: meowmeowcat --- source/guides/distributing-packages-using-setuptools.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index c6171ab70..3a27a4b90 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -665,7 +665,7 @@ edited in-place without reinstallation: changes to Python source files in projects installed as editable will be reflected the next time an interpreter process is started. To install a Python package in "editable"/"development" mode -Change directory to the root of the project directory and run ``pip install -e .``: +Change directory to the root of the project directory and run: :: From 9c8996b5cc81d9ff35944131be8bc020b990dda9 Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sat, 28 Aug 2021 17:38:19 +0800 Subject: [PATCH 0075/1072] Fix a typo (#970) --- source/guides/distributing-packages-using-setuptools.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index b16dc8f1c..a179ea130 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -710,7 +710,7 @@ Lastly, if you don't want to install any dependencies at all, you can run: For more information, see the -:doc:`` section +:doc:`Development Mode ` section of the :doc:`setuptools docs `. .. _`Packaging your project`: From 750346bb32d6ed5f7bec1353267055301b6ce3b6 Mon Sep 17 00:00:00 2001 From: Tim Hopper Date: Sat, 28 Aug 2021 05:58:17 -0400 Subject: [PATCH 0076/1072] Switch example reading Markdown to use pathlib (#969) Co-authored-by: Zachary Blackwood Co-authored-by: Zachary Blackwood Co-authored-by: Brian Rutledge --- source/guides/making-a-pypi-friendly-readme.rst | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/source/guides/making-a-pypi-friendly-readme.rst b/source/guides/making-a-pypi-friendly-readme.rst index eea221b4a..0cba44c2c 100644 --- a/source/guides/making-a-pypi-friendly-readme.rst +++ b/source/guides/making-a-pypi-friendly-readme.rst @@ -78,10 +78,9 @@ and identifies the markup as GitHub-flavored Markdown: from setuptools import setup # read the contents of your README file - from os import path - this_directory = path.abspath(path.dirname(__file__)) - with open(path.join(this_directory, 'README.md'), encoding='utf-8') as f: - long_description = f.read() + from pathlib import Path + this_directory = Path(__file__).parent + long_description = (this_directory / "README.md").read_text() setup( name='an_example_package', From f45cb58daee330c9c3f088f49ebd0a205ef00983 Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Sun, 29 Aug 2021 18:15:29 +0200 Subject: [PATCH 0077/1072] Translated using Weblate (Chinese (Simplified)) Currently translated at 8.6% (196 of 2271 strings) Translated using Weblate (Chinese (Simplified)) Currently translated at 1.3% (31 of 2271 strings) Translated using Weblate (Chinese (Traditional)) Currently translated at 1.1% (25 of 2271 strings) Added translation using Weblate (Chinese (Simplified)) Added translation using Weblate (Chinese (Traditional)) Co-authored-by: meowmeowmeowcat Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hans/ Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hant/ Translation: pypa/packaging.python.org --- locales/zh_Hans/LC_MESSAGES/messages.po | 9324 +++++++++++++++++++++++ locales/zh_Hant/LC_MESSAGES/messages.po | 9260 ++++++++++++++++++++++ 2 files changed, 18584 insertions(+) create mode 100644 locales/zh_Hans/LC_MESSAGES/messages.po create mode 100644 locales/zh_Hant/LC_MESSAGES/messages.po diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po new file mode 100644 index 000000000..84341c490 --- /dev/null +++ b/locales/zh_Hans/LC_MESSAGES/messages.po @@ -0,0 +1,9324 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2013–2020, PyPA +# This file is distributed under the same license as the Python Packaging User Guide package. +# meowmeowmeowcat , 2021. +msgid "" +msgstr "" +"Project-Id-Version: Python Packaging User Guide\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-07-06 19:32+0800\n" +"PO-Revision-Date: 2021-07-16 11:12+0000\n" +"Last-Translator: meowmeowmeowcat \n" +"Language-Team: Chinese (Simplified) \n" +"Language: zh_Hans\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=1; plural=0;\n" +"X-Generator: Weblate 4.7.2-dev\n" + +#: ../source/contribute.rst:5 +msgid "Contribute to this guide" +msgstr "为本指南做出贡献" + +#: ../source/contribute.rst:7 +msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" +msgstr "|PyPUG| 欢迎贡献者！有很多方法可以帮助我们，包括：" + +#: ../source/contribute.rst:10 +msgid "Reading the guide and giving feedback" +msgstr "阅读指南并提供反馈" + +#: ../source/contribute.rst:11 +msgid "Reviewing new contributions" +msgstr "审查新的贡献" + +#: ../source/contribute.rst:12 +msgid "Revising existing content" +msgstr "修改现有内容" + +#: ../source/contribute.rst:13 +msgid "Writing new content" +msgstr "撰写新内容" + +#: ../source/contribute.rst:15 +msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." +msgstr "" +"大部分关于 |PyPUG| 的工作都是在 `本项目的GitHub仓库`__ 进行的。要开始工作，请查看`open issues`__ 和`pull " +"requests`__ 的列表。如果你打算编写或编辑指南，请阅读 :ref:`style guide " +"`。" + +#: ../source/contribute.rst:24 +msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." +msgstr "如果您想为 |PyPUG| 作出贡献，您应该遵守 PSF 的 `行为准则 (Code of Conduct)`__ 。" + +#: ../source/contribute.rst:31 +msgid "Documentation types" +msgstr "文档类型" + +#: ../source/contribute.rst:33 +msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." +msgstr "本项目由具有特定目的的四种不同的文档类型组成。当提议对项目进行新的补充时，请选择适当的文档类型。" + +#: ../source/contribute.rst:38 +#: ../source/tutorials/index.rst:2 +msgid "Tutorials" +msgstr "教程" + +#: ../source/contribute.rst:40 +msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." +msgstr "教程的重点是通过完成一个目标来教导读者新的概念。它们是有观点的分步指南。它们不包括不相干的警告或信息。`示例教程式文件`_ 。" + +#: ../source/contribute.rst:47 +#: ../source/guides/index.rst:2 +msgid "Guides" +msgstr "指南" + +#: ../source/contribute.rst:49 +msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." +msgstr "" +"指南的重点是完成一项具体的任务，并可以假定有一定程度的前提知识。这类似于教程，但有一个狭窄和明确的重点，并可以根据需要提供大量的注意事项和附加信息。他们还" +"可以讨论完成任务的多种方法。 :doc:`示例指南式文档`。" + +#: ../source/contribute.rst:56 +#: ../source/discussions/index.rst:2 +msgid "Discussions" +msgstr "讨论" + +#: ../source/contribute.rst:58 +msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." +msgstr "" +"讨论 (Discussions) 的重点是理解和信息。这些探索一个特定的主题，没有具体的目标。 :doc:`示例讨论式文件 `。" + +#: ../source/contribute.rst:63 +msgid "Specifications" +msgstr "规格" + +#: ../source/contribute.rst:65 +msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." +msgstr "" +"规范 (Specifications) 是一种参考文件，侧重于全面记录包装工具之间互操作性的一致接口。 :doc:`范例规范式文件 <" +"specifications/core-metadata>`。" + +#: ../source/contribute.rst:73 +msgid "Building the guide locally" +msgstr "在本地构建指南" + +#: ../source/contribute.rst:75 +msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" +msgstr "虽然这不需要做出贡献，但为了测试您的改动，在本地建立本指南可能是有用的。为了在本地构建本指南，你需要：" + +#: ../source/contribute.rst:79 +msgid "`Nox `_. You can install or upgrade nox using ``pip``::" +msgstr "" +"`Nox `_ 。你可以用 ``pip`` 来安装或升级nox::" + +#: ../source/contribute.rst:84 +msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." +msgstr "" +"Python 3.6。我们的构建脚本只为 Python 3.6 而设计。请参阅 `Hitchhiker's Guide to Python " +"installation instructions`_ 以在你的操作系统上安装Python 3.6。" + +#: ../source/contribute.rst:91 +msgid "To build the guide, run the following bash command in the source folder::" +msgstr "要构建指南，在 source 文件夹中运行以下 bash 命令::" + +#: ../source/contribute.rst:95 +msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." +msgstr "" +"在该过程完成后，您可以在 ``./build/html`` 目录中找到 HTML 输出。您可以打开 ``index.html`` " +"文件，并在浏览器中查看指南，但我们建议使用 HTTP 服务器为指南服务。" + +#: ../source/contribute.rst:100 +msgid "You can build the guide and serve it via an HTTP server using the following command::" +msgstr "您可以使用以下命令建立指南并通过 HTTP 服务器为其提供服务::" + +#: ../source/contribute.rst:105 +msgid "The guide will be browsable via http://localhost:8000." +msgstr "该指南将可通过 http://localhost:8000 进行浏览。" + +#: ../source/contribute.rst:109 +msgid "Where the guide is deployed" +msgstr "指南的部署地点" + +#: ../source/contribute.rst:111 +msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." +msgstr "" +"该指南是通过ReadTheDocs部署的，配置位于 https://readthedocs.org/projects/" +"python-packaging-user-guide/ 。它由一个自定义域名提供服务，并由 Fast.ly 提供支持。" + +#: ../source/contribute.rst:117 +msgid "Style guide" +msgstr "风格指南" + +#: ../source/contribute.rst:119 +msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." +msgstr "" +"本风格指南提供了关于如何编写 |PyPUG| " +"的建议。在开始写作之前，请先查看它。通过遵循样式指南，您的贡献将有助于增加一个有凝聚力的整体，并使您的贡献更容易被项目接受。" + +#: ../source/contribute.rst:126 +msgid "Purpose" +msgstr "目的" + +#: ../source/contribute.rst:128 +msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." +msgstr "|PyPUG| 的目的是成为关于如何使用当前工具打包、发布和安装 Python 项目的权威性资源。" + +#: ../source/contribute.rst:133 +msgid "Scope" +msgstr "范围" + +#: ../source/contribute.rst:135 +msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." +msgstr "该指南旨在通过准确和有针对性的建议来回答问题和解决问题。" + +#: ../source/contribute.rst:138 +msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." +msgstr "" +"本指南并不意味着是全面的，也不意味着可以取代单个项目的文档。例如，pip 有几十个命令、选项和设置。pip 文档详细描述了它们中的每一个，" +"而本指南只描述了完成本指南中描述的特定任务所需的 pip 部分。" + +#: ../source/contribute.rst:146 +msgid "Audience" +msgstr "读者" + +#: ../source/contribute.rst:148 +msgid "The audience of this guide is anyone who uses Python with packages." +msgstr "本指南的受众是任何使用 Python 包的人。" + +#: ../source/contribute.rst:150 +msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." +msgstr "不要忘记，Python 社区是很大，而且很受欢迎的。读者可能与您的年龄、性别、教育、文化等不尽相同，但他们和您一样值得学习包装知识。" + +#: ../source/contribute.rst:154 +msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." +msgstr "特别是要记住，不是所有使用 Python 的人都把自己看作是程序员。本指南的受众包括天文学家，画家或学生以及专业的软件开发人员。" + +#: ../source/contribute.rst:160 +msgid "Voice and tone" +msgstr "声音和语气" + +#: ../source/contribute.rst:162 +msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." +msgstr "在撰写本指南时，即使您已经掌握了所有答案，也要努力以平易近人且谦逊的语气写作。" + +#: ../source/contribute.rst:165 +msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." +msgstr "" +"想象一下，您正在和一个您知道是聪明和熟练的人一起做 Python " +"项目。您喜欢和他们一起工作，他们也喜欢和您一起工作。那个人问了您一个问题，你知道答案。你怎么回答？*这* 就是你应该如何写这个指南的方式。" + +#: ../source/contribute.rst:170 +msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." +msgstr "" +"这里有一个快速检查：试着大声朗读以了解您写作的声音和语气。它听起来像您会说的话，还是听起来像您在演戏或发表演讲？随意使用缩略语，不要担心拘泥于繁琐的语法规" +"则。您在此允许用介词来结束一个句子，如果这是您想结束它的话。" + +#: ../source/contribute.rst:177 +msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." +msgstr "" +"在写指南时，根据主题的严肃性和难度调整你的语气。如果你写的是一个介绍性的教程，开个玩笑是可以的，但如果你涉及的是一个敏感的安全建议，你可能要完全避免玩笑。" + +#: ../source/contribute.rst:184 +msgid "Conventions and mechanics" +msgstr "公约和机制" + +#: ../source/contribute.rst:192 +msgid "**Write to the reader**" +msgstr "**写给读者**" + +#: ../source/contribute.rst:187 +msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." +msgstr "在提出建议或采取的步骤时，您应称呼读者为 *你* 或使用命令语气。" + +#: ../source/contribute.rst:0 +msgid "Wrong: To install it, the user runs…" +msgstr "错误：要安装它，用户运行…" + +#: ../source/contribute.rst:0 +msgid "Right: You can install it by running…" +msgstr "正确：您可以通过运行...来安装它" + +#: ../source/contribute.rst:0 +msgid "Right: To install it, run…" +msgstr "正确：要安装它，请运行…" + +#: ../source/contribute.rst:198 +msgid "**State assumptions**" +msgstr "**陈述假设**" + +#: ../source/contribute.rst:195 +msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." +msgstr "避免做出未说明的假设。在网上阅读意味着指南的任何一页都可能是读者所看到的指南的第一页。如果您要做假设，那就要说明您要做什么假设。" + +#: ../source/contribute.rst:203 +msgid "**Cross-reference generously**" +msgstr "**慷慨地交叉参考**" + +#: ../source/contribute.rst:201 +msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." +msgstr "当你第一次提到一个工具或做法时，请链接到指南中涉及它的部分，或链接到其他地方的相关文件。这样可以为读者省去搜索的麻烦。" + +#: ../source/contribute.rst:213 +msgid "**Respect naming practices**" +msgstr "**尊重命名的做法**" + +#: ../source/contribute.rst:206 +msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." +msgstr "当给工具、网站、人和其他专有名词命名时，请使用它们的首选大写字母。" + +#: ../source/contribute.rst:0 +msgid "Wrong: Pip uses…" +msgstr "错误：Pip 使用…" + +#: ../source/contribute.rst:0 +msgid "Right: pip uses…" +msgstr "正确：pip 使用…" + +#: ../source/contribute.rst:0 +msgid "Wrong: …hosted on github." +msgstr "错误：...托管在 github 上。" + +#: ../source/contribute.rst:0 +msgid "Right: …hosted on GitHub." +msgstr "正确：……托管在 GitHub 上。" + +#: ../source/contribute.rst:222 +msgid "**Use a gender-neutral style**" +msgstr "**使用中性风格**" + +#: ../source/contribute.rst:216 +msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." +msgstr "" +"通常，您会用 *you*、*your* 和 *yours* 来直接称呼读者。否则，请使用性别中立的代词 *they*、*their* 和 *theirs*" +" ，或者完全避免使用代词。" + +#: ../source/contribute.rst:0 +msgid "Wrong: A maintainer uploads the file. Then he…" +msgstr "错误：一个维护人员上传了文件。然后他…" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then they…" +msgstr "正确：一个维护人员上传了文件。然后他们…" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then the maintainer…" +msgstr "正确：A maintainer uploads the file. Then the maintainer…" + +#: ../source/contribute.rst:234 +msgid "**Headings**" +msgstr "**标题**" + +#: ../source/contribute.rst:225 +msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." +msgstr "" +"写标题时要使用读者正在搜索的词。一个好方法是让你的标题完成一个隐含的问题。例如，读者可能想知道 *How do I install " +"MyLibrary?*，所以一个好的标题可能是 *Install MyLibrary* 。" + +#: ../source/contribute.rst:230 +msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." +msgstr "在章节标题中，使用句子大小写。换句话说，要像写一个典型的句子那样写标题。" + +#: ../source/contribute.rst:0 +msgid "Wrong: Things You Should Know About Python" +msgstr "错误：Things You Should Know About Python" + +#: ../source/contribute.rst:0 +msgid "Right: Things you should know about Python" +msgstr "正确：Things you should know about Python" + +#: ../source/contribute.rst:237 +msgid "**Numbers**" +msgstr "**数字**" + +#: ../source/contribute.rst:237 +msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." +msgstr "在正文中，将数字1到9写成单词。对于其他数字或表格中的数字，使用数字。" + +#: ../source/discussions/deploying-python-applications.rst:4 +msgid "Deploying Python applications" +msgstr "部署 Python 应用程序" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Page Status" +msgstr "页面状态" + +#: ../source/discussions/deploying-python-applications.rst:6 +#: ../source/guides/index-mirrors-and-caches.rst:7 +#: ../source/guides/installing-using-linux-tools.rst:7 +#: ../source/guides/packaging-binary-extensions.rst:7 +#: ../source/guides/supporting-multiple-python-versions.rst:7 +#: ../source/guides/supporting-windows-using-appveyor.rst:5 +msgid "Incomplete" +msgstr "不完全的" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Last Reviewed" +msgstr "最后审查" + +#: ../source/discussions/deploying-python-applications.rst:7 +msgid "2014-11-11" +msgstr "2014-11-11" + +#: ../source/discussions/deploying-python-applications.rst:11 +#: ../source/discussions/install-requires-vs-requirements.rst:9 +#: ../source/guides/analyzing-pypi-package-downloads.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:22 +#: ../source/guides/index-mirrors-and-caches.rst:12 +#: ../source/guides/installing-scientific-packages.rst:9 +#: ../source/guides/packaging-binary-extensions.rst:17 +#: ../source/guides/supporting-multiple-python-versions.rst:12 +#: ../source/guides/supporting-windows-using-appveyor.rst:15 +#: ../source/overview.rst:23 +#: ../source/specifications/core-metadata.rst:38 +#: ../source/specifications/direct-url.rst:14 +#: ../source/tutorials/installing-packages.rst:23 +msgid "Contents" +msgstr "内容" + +#: ../source/discussions/deploying-python-applications.rst:14 +msgid "Overview" +msgstr "总览" + +#: ../source/discussions/deploying-python-applications.rst:18 +msgid "Supporting multiple hardware platforms" +msgstr "支持多种硬件平台" + +#: ../source/discussions/deploying-python-applications.rst:40 +msgid "OS packaging & installers" +msgstr "操作系统包装和安装程序" + +#: ../source/discussions/deploying-python-applications.rst:52 +msgid "Windows" +msgstr "Windows系统" + +#: ../source/discussions/deploying-python-applications.rst:61 +msgid "Pynsist" +msgstr "Pynsist" + +#: ../source/discussions/deploying-python-applications.rst:63 +msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." +msgstr "" +"`Pynsist `__ 是一个基于NSIS的单一安装程序，并将 Python " +"程序与 Python 解释器捆绑在一起的工具。在大多数情况下，打包 (packaging) 只需要用户选择 Python 解释器的版本并声明程序的依赖性 " +"(dependencies) 。该工具会下载用于 Windows 的 Python 解释器，并将其与所有依赖项打包成一个可在 Windows " +"执行的安装程序。" + +#: ../source/discussions/deploying-python-applications.rst:70 +msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." +msgstr "" +"安装的程序可以从安装程序添加到开始菜单的快捷方式启动。它使用一个安装在其应用程序目录中的Python解释器，与计算机上的任何其他 Python 安装无关。" + +#: ../source/discussions/deploying-python-applications.rst:74 +msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." +msgstr "" +"Pynsist 的一大优势是可以在 Linux 上构建 Windows 软件包。在`文档 `__ 中，有几个不同类型程序（控制台、GUI）的例子。该工具是在 MIT 许可下发布的。" + +#: ../source/discussions/deploying-python-applications.rst:80 +msgid "Application bundles" +msgstr "应用捆绑" + +#: ../source/discussions/deploying-python-applications.rst:91 +msgid "Configuration management" +msgstr "配置管理" + +#: ../source/discussions/index.rst:4 +msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." +msgstr "" +"**讨论 (Discussions)** 的重点是提供关于特定主题的全面信息。如果您只是想把事情做好，请看 :doc:`/guides/index` 。" + +#: ../source/discussions/install-requires-vs-requirements.rst:5 +msgid "install_requires vs requirements files" +msgstr "install_requires 与 requirements files" + +#: ../source/discussions/install-requires-vs-requirements.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:382 +msgid "install_requires" +msgstr "install_requires" + +#: ../source/discussions/install-requires-vs-requirements.rst:14 +msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" +"``install_requires`` 是一个 :ref:`setuptools` :file:`setup.py` 关键字，它应该用来指定一个项目 " +"**最小** 需要正确运行的内容。当项目由 :ref:`pip` 安装时，这就是用来安装其依赖的规范。" + +#: ../source/discussions/install-requires-vs-requirements.rst:19 +msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" +msgstr "例如，如果项目需要 A 和 B ，您的 ``install_requires`` 会是这样的：" + +#: ../source/discussions/install-requires-vs-requirements.rst:29 +msgid "Additionally, it's best practice to indicate any known lower or upper bounds." +msgstr "此外，最好的做法是指出任何已知的下限或上限。" + +#: ../source/discussions/install-requires-vs-requirements.rst:31 +msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" +msgstr "例如，您可能知道您的项目至少需要 'A' 的 v1 ，'B' 的 v2 ，所以它会是这样的：" + +#: ../source/discussions/install-requires-vs-requirements.rst:41 +msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:51 +msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:56 +msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:64 +#: ../source/tutorials/installing-packages.rst:460 +msgid "Requirements files" +msgstr "Requirements files" + +#: ../source/discussions/install-requires-vs-requirements.rst:66 +msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." +msgstr "" +":ref:`Requirements Files ` 最简单的描述，只是放在文件中的 :ref:`pip:" +"pip install` 参数列表。" + +#: ../source/discussions/install-requires-vs-requirements.rst:69 +msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:73 +msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:78 +msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:84 +msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." +msgstr "" +"在安装过程中，``install_requires`` 元数据会被 pip 自动分析，而需求文件则不会，而它只有在用户使用 ``python -m " +"pip install -r`` 专门安装时才会使用。" + +#: ../source/discussions/install-requires-vs-requirements.rst:90 +msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." +msgstr "" +"关于 \"抽象 (Abstract) \"与 \"具体 (Concrete)\"要求的更多信息，请参阅 https://caremad.io/2013/" +"07/setup-vs-requirement/ 。" + +#: ../source/discussions/pip-vs-easy-install.rst:6 +msgid "pip vs easy_install" +msgstr "pip 与 easy_install" + +#: ../source/discussions/pip-vs-easy-install.rst:9 +msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:14 +msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:22 +msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" +msgstr "下面是 pip 和被废弃的 easy_install 之间的重要区别的分类：" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**pip**" +msgstr "**pip**" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**easy_install**" +msgstr "**easy_install**" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +msgid "Installs from :term:`Wheels `" +msgstr "从 :term:`Wheels ` 安装" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Yes" +msgstr "有" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:30 +#: ../source/discussions/pip-vs-easy-install.rst:32 +#: ../source/discussions/pip-vs-easy-install.rst:35 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:51 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "No" +msgstr "没有" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Uninstall Packages" +msgstr "卸载软件包" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Yes (``python -m pip uninstall``)" +msgstr "有(``python -m pip uninstall``)" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Dependency Overrides" +msgstr "依赖性覆盖" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Yes (:ref:`Requirements Files `)" +msgstr "有(:ref:`Requirements Files `)" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "List Installed Packages" +msgstr "列出已安装的软件包" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" +msgstr "有(``python -m pip list`` and ``python -m pip freeze``)" + +#: ../source/discussions/pip-vs-easy-install.rst:38 +msgid ":pep:`438` Support" +msgstr ":pep:`438` 支持" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Installation format" +msgstr "安装格式" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "'Flat' packages with :file:`egg-info` metadata." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Encapsulated Egg format" +msgstr "封装的 Egg 格式" + +#: ../source/discussions/pip-vs-easy-install.rst:44 +msgid "sys.path modification" +msgstr "sys.path 修改" + +#: ../source/discussions/pip-vs-easy-install.rst:48 +msgid "Installs from :term:`Eggs `" +msgstr "从 :term:`Eggs ` 安装" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "`pylauncher support`_" +msgstr "`pylauncher 支持`_" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "Yes [1]_" +msgstr "有[1]_" + +#: ../source/discussions/pip-vs-easy-install.rst:54 +msgid ":ref:`Multi-version Installs`" +msgstr ":ref:`Multi-version Installs`" + +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Exclude scripts during install" +msgstr "安装时排除脚本" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "per project index" +msgstr "每个项目索引" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Only in virtualenv" +msgstr "仅在 virtualenv 中" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Yes, via setup.cfg" +msgstr "有，通过 setup.cfg" + +#: ../source/discussions/pip-vs-easy-install.rst:68 +msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" +msgstr "" +"https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" +"launcher" + +#: ../source/discussions/wheel-vs-egg.rst:5 +msgid "Wheel vs Egg" +msgstr "Wheel 与 Egg" + +#: ../source/discussions/wheel-vs-egg.rst:7 +msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." +msgstr "" +":term:`Wheel` 和 :term:`Egg` 都是打包格式，旨在支持不需要构建或编译的安装工件的使用情况，这在测试和生产工作流程中可能是昂贵的。" + +#: ../source/discussions/wheel-vs-egg.rst:11 +msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:14 +msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:17 +msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." +msgstr "下面是关于 :term: `Wheel` 和 :term: `Egg` 之间的重要区别。" + +#: ../source/discussions/wheel-vs-egg.rst:20 +msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." +msgstr ":term:`Wheel` 有一个 :pep:`official PEP <427>` 。 :term:`Egg` 没有。" + +#: ../source/discussions/wheel-vs-egg.rst:22 +msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:26 +msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:31 +msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." +msgstr "" +":term:`Wheel` 使用 :pep:`PEP376-compliant <376>```.dist-info`` 目录。 Egg 使用 " +"``.egg-info`` 。" + +#: ../source/discussions/wheel-vs-egg.rst:34 +msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:38 +msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:41 +msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:47 +msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." +msgstr "" + +#: ../source/glossary.rst:3 +msgid "Glossary" +msgstr "词汇表" + +#: ../source/glossary.rst:8 +msgid "Binary Distribution" +msgstr "" + +#: ../source/glossary.rst:11 +msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." +msgstr "" + +#: ../source/glossary.rst:14 +msgid "Built Distribution" +msgstr "" + +#: ../source/glossary.rst:17 +msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." +msgstr "" + +#: ../source/glossary.rst:26 +msgid "Distribution Package" +msgstr "分发软件包" + +#: ../source/glossary.rst:29 +msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." +msgstr "" + +#: ../source/glossary.rst:34 +msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." +msgstr "" + +#: ../source/glossary.rst:41 +msgid "Egg" +msgstr "Egg" + +#: ../source/glossary.rst:44 +msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" +msgstr "" + +#: ../source/glossary.rst:49 +msgid "Extension Module" +msgstr "扩展模块" + +#: ../source/glossary.rst:52 +msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." +msgstr "" + +#: ../source/glossary.rst:59 +msgid "Known Good Set (KGS)" +msgstr "" + +#: ../source/glossary.rst:62 +msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." +msgstr "" + +#: ../source/glossary.rst:68 +msgid "Import Package" +msgstr "导入包" + +#: ../source/glossary.rst:71 +msgid "A Python module which can contain other modules or recursively, other packages." +msgstr "" + +#: ../source/glossary.rst:74 +msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." +msgstr "" + +#: ../source/glossary.rst:78 +msgid "Module" +msgstr "模块(Module)" + +#: ../source/glossary.rst:81 +msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." +msgstr "" + +#: ../source/glossary.rst:84 +msgid "Package Index" +msgstr "包索引 (Package Index)" + +#: ../source/glossary.rst:87 +msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." +msgstr "" + +#: ../source/glossary.rst:90 +msgid "Per Project Index" +msgstr "" + +#: ../source/glossary.rst:93 +msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." +msgstr "" + +#: ../source/glossary.rst:97 +msgid "Project" +msgstr "项目 (Project)" + +#: ../source/glossary.rst:100 +msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." +msgstr "" + +#: ../source/glossary.rst:104 +msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." +msgstr "" + +#: ../source/glossary.rst:110 +msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." +msgstr "" +"Python 项目必须具有独特且唯一的名称，这些名字可以在 :term:`PyPI ` 上注册。" +"然后每个项目将包含一个或多个 :term:`发布` ，每个版本可能包括一个或多个 :term:`套件 ` 。" + +#: ../source/glossary.rst:115 +msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." +msgstr "" + +#: ../source/glossary.rst:121 +msgid "Pure Module" +msgstr "纯模块 (Pure Module)" + +#: ../source/glossary.rst:124 +msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." +msgstr "" + +#: ../source/glossary.rst:127 +msgid "Python Packaging Authority (PyPA)" +msgstr "Python 包装管理局 （PyPA）" + +#: ../source/glossary.rst:130 +msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." +msgstr "" +"PyPA 是一个工作小组，负责维护 Python 包装中的许多相关项目。他们在 https://www.pypa.io，`GitHub " +"`_ 和`Bitbucket `_ 上托管项目，" +"并在 `distutils-sig 邮件列表 `_ 和 `Python Discourse 论坛 `__ 上讨论问题。" + +#: ../source/glossary.rst:139 +msgid "Python Package Index (PyPI)" +msgstr "Python 包索引 (PyPI)" + +#: ../source/glossary.rst:142 +msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." +msgstr "" +"`PyPI `_ 是 Python 社区的默认 :term:`包索引 (Package Index)` 。所有 " +"Python 开发人员都可以使用和分发他们的发行版。" + +#: ../source/glossary.rst:145 +msgid "pypi.org" +msgstr "pypi.org" + +#: ../source/glossary.rst:148 +msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." +msgstr "" + +#: ../source/glossary.rst:152 +msgid "pyproject.toml" +msgstr "pyproject.toml" + +#: ../source/glossary.rst:155 +msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." +msgstr "" + +#: ../source/glossary.rst:157 +msgid "Release" +msgstr "" + +#: ../source/glossary.rst:160 +msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." +msgstr "" + +#: ../source/glossary.rst:163 +msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." +msgstr "" + +#: ../source/glossary.rst:168 +msgid "Requirement" +msgstr "" + +#: ../source/glossary.rst:171 +msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." +msgstr "" + +#: ../source/glossary.rst:177 +msgid "Requirement Specifier" +msgstr "" + +#: ../source/glossary.rst:180 +msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" +msgstr "" + +#: ../source/glossary.rst:187 +msgid "Requirements File" +msgstr "" + +#: ../source/glossary.rst:190 +msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." +msgstr "" + +#: ../source/glossary.rst:194 +#: ../source/guides/distributing-packages-using-setuptools.rst:56 +msgid "setup.py" +msgstr "setup.py" + +#: ../source/glossary.rst:195 +#: ../source/guides/distributing-packages-using-setuptools.rst:77 +msgid "setup.cfg" +msgstr "setup.cfg" + +#: ../source/glossary.rst:198 +msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." +msgstr "" + +#: ../source/glossary.rst:201 +msgid "Source Archive" +msgstr "" + +#: ../source/glossary.rst:204 +msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:208 +msgid "Source Distribution (or \"sdist\")" +msgstr "源代码分发（或“sdist”）" + +#: ../source/glossary.rst:211 +msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:216 +msgid "System Package" +msgstr "系统包 (System Package)" + +#: ../source/glossary.rst:219 +msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." +msgstr "" + +#: ../source/glossary.rst:222 +msgid "Version Specifier" +msgstr "版本说明符 (Version Specifier)" + +#: ../source/glossary.rst:225 +msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." +msgstr "" + +#: ../source/glossary.rst:231 +msgid "Virtual Environment" +msgstr "虚拟环境 (Virtual Environment)" + +#: ../source/glossary.rst:234 +msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/glossary.rst:238 +msgid "Wheel" +msgstr "Wheel" + +#: ../source/glossary.rst:241 +msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." +msgstr "" + +#: ../source/glossary.rst:244 +msgid "Working Set" +msgstr "工作集 (Working Set)" + +#: ../source/glossary.rst:247 +msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:3 +msgid "Analyzing PyPI package downloads" +msgstr "分析 PyPI 软件包的下载情况" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:5 +msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." +msgstr "" +"本节介绍了如何使用公共的 PyPI 下载统计数据集来了解PyPI上托管的软件包 (packages) 的下载情况。例如，您可以用它来发现用于下载软件包的 " +"Python 版本的分布。" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:15 +#: ../source/guides/supporting-windows-using-appveyor.rst:18 +msgid "Background" +msgstr "背景" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:17 +msgid "PyPI does not display download statistics for a number of reasons: [#]_" +msgstr "由于一些原因，PyPI 不显示下载统计数据。[#]_" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:19 +msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:24 +msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:27 +msgid "``pip``'s download cache (lowers download counts)" +msgstr "``pip`` 的下载缓存（降低下载次数）" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:28 +msgid "Internal or unofficial mirrors (can both raise or lower download counts)" +msgstr "内部或非官方的镜像（既可以提高也可以降低下载量）" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:29 +msgid "Packages not hosted on PyPI (for comparisons sake)" +msgstr "未在 PyPI 上托管的软件包（为了比较）" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:30 +msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:32 +msgid "Known historical data quality issues (lowers download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:34 +msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:38 +msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:43 +msgid "Public dataset" +msgstr "公共数据集" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:45 +msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:50 +msgid "Getting set up" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:52 +msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:58 +msgid "Navigate to the `BigQuery web UI`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:59 +msgid "Create a new project." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:60 +msgid "Enable the `BigQuery API `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:63 +msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:69 +msgid "Data schema" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:71 +msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +msgid "Column" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/guides/using-manifest-in.rst:67 +#: ../source/specifications/core-metadata.rst:185 +msgid "Description" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/specifications/direct-url.rst:226 +msgid "Examples" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "timestamp" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "Date and time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "``2020-03-09 00:33:03 UTC``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "file.project" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "Project name" +msgstr "项目名称" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "``pipenv``, ``nose``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "file.version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "Package version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "``0.1.6``, ``1.4.2``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "details.installer.name" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "Installer" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "pip, `bandersnatch`_" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "details.python" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "Python version" +msgstr "Python 版本" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "``2.7.12``, ``3.6.4``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:93 +msgid "Useful queries" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:95 +msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:97 +msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:102 +msgid "Counting package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:104 +msgid "The following query counts the total number of downloads for the project \"pytest\"." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:119 +#: ../source/guides/analyzing-pypi-package-downloads.rst:140 +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "num_downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:121 +msgid "26190085" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:124 +msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:142 +msgid "24334215" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:146 +msgid "Package downloads over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:148 +msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +msgid "month" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "1956741" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "2018-01-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2344692" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2017-12-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "1730398" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "2017-11-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2047310" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2017-10-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "1744443" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "2017-09-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "1916952" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "2017-08-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:184 +msgid "Python versions over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:186 +msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "python" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "3.7" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "18051328726" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "3.6" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "9635067203" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "3.8" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "7781904681" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "2.7" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "6381252241" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "null" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "2026630299" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "3.5" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "1894153540" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:221 +msgid "Caveats" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:223 +msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:231 +msgid "Additional tools" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:233 +msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:237 +msgid "``google-cloud-bigquery``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:239 +msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:267 +msgid "``pypinfo``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:269 +msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:273 +msgid "Install `pypinfo`_ using pip." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:279 +msgid "Usage:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:295 +msgid "``pandas-gbq``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:297 +msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:301 +#: ../source/specifications/binary-distribution-format.rst:459 +msgid "References" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:303 +msgid "`PyPI Download Counts deprecation email `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:304 +msgid "`PyPI BigQuery dataset announcement email `__" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:3 +msgid "Creating and discovering plugins" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:5 +msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:10 +msgid "There are three major approaches to doing automatic plugin discovery:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:12 +msgid "`Using naming convention`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:13 +msgid "`Using namespace packages`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:14 +msgid "`Using package metadata`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:18 +msgid "Using naming convention" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:20 +msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:38 +msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:48 +msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:59 +msgid "Using namespace packages" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:61 +msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:89 +msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:101 +msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:115 +msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:121 +msgid "Using package metadata" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:123 +msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:128 +msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:139 +msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:154 +msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:163 +msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:166 +msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:170 +msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:5 +msgid "Packaging and distributing projects" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:7 +msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:11 +msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:15 +msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:25 +msgid "Requirements for packaging and distributing" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:26 +msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:29 +msgid "Install \"twine\" [1]_:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:43 +msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:49 +msgid "Configuring your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:53 +msgid "Initial files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:58 +msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:63 +msgid ":file:`setup.py` serves two primary functions:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:65 +msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:71 +msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:79 +msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:86 +msgid "README.rst / README.md" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:88 +msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:95 +msgid "For an example, see `README.md `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:99 +msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:108 +msgid "MANIFEST.in" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:110 +msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:115 +msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:119 +msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:122 +msgid "LICENSE.txt" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:124 +msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:130 +msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:135 +msgid "" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:137 +msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:141 +msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:149 +msgid "setup() args" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:151 +msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:155 +msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:164 +msgid "name" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:170 +msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:174 +msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:176 +msgid "Start & end with an ASCII letter or digit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:178 +msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:190 +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "version" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:196 +msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:200 +msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:203 +msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:206 +msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:214 +msgid "description" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:222 +msgid "Give a short and long description for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:224 +msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:229 +msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:235 +msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:245 +msgid "url" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:252 +msgid "Give a homepage URL for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:256 +msgid "author" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:263 +msgid "Provide details about the author." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:267 +msgid "license" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:273 +msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:279 +msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:287 +msgid "classifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:316 +msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:319 +msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:327 +msgid "keywords" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:333 +msgid "List keywords that describe your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:337 +msgid "project_urls" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:349 +msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:355 +msgid "packages" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:361 +msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:370 +msgid "py_modules" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:376 +msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:388 +msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:392 +msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:398 +msgid "python_requires" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:400 +msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:407 +msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:412 +msgid "And so on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:416 +msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:422 +msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:431 +msgid "package_data" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:440 +msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:445 +msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:449 +msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:457 +msgid "data_files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:463 +msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:469 +msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:479 +msgid "For more information see the distutils section on `Installing Additional Files `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:484 +msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:491 +msgid "scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:493 +msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:500 +msgid "entry_points" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:509 +msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:512 +msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:516 +msgid "The most commonly used entry point is \"console_scripts\" (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:521 +msgid "console_scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:531 +msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:538 +msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:545 +msgid "Choosing a versioning scheme" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:548 +msgid "Standards compliance for interoperability" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:550 +msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:556 +msgid "Here are some examples of compliant version numbers::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:567 +msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:573 +msgid "Scheme choices" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:576 +msgid "Semantic versioning (preferred)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:578 +msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:582 +msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:585 +msgid "MAJOR version when they make incompatible API changes," +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:586 +msgid "MINOR version when they add functionality in a backwards-compatible manner, and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:587 +msgid "MAINTENANCE version when they make backwards-compatible bug fixes." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:589 +msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:594 +msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:598 +msgid "Date based versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:600 +msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:604 +msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:607 +msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:611 +msgid "Serial versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:613 +msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:616 +msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:621 +msgid "Hybrid schemes" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:623 +msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:629 +msgid "Pre-release versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:631 +msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:634 +msgid "zero or more dev releases (denoted with a \".devN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:635 +msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:636 +msgid "zero or more beta releases (denoted with a \".bN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:637 +msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:639 +msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:644 +msgid "Local version identifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:646 +msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:653 +msgid "A local version identifier takes the form ``+``. For example::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:661 +msgid "Working in \"development mode\"" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:663 +msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:667 +msgid "Assuming you're in the root of your project directory, then run:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:674 +msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:680 +msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:688 +msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:692 +msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:697 +msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:701 +msgid "Lastly, if you don't want to install any dependencies at all, you can run::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:706 +msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:713 +msgid "Packaging your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:715 +msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:720 +msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:737 +msgid "Source distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:739 +msgid "Minimally, you should create a :term:`Source Distribution `:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:755 +msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:763 +msgid "Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:765 +msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:770 +msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:773 +msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:776 +msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:785 +msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:792 +msgid "Pure Python Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:794 +msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:797 +#: ../source/guides/distributing-packages-using-setuptools.rst:826 +msgid "To build the wheel:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:811 +msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:815 +msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:821 +msgid "Platform Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:823 +msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:841 +msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:847 +msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:855 +msgid "Uploading your Project to PyPI" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:857 +msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:861 +msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:866 +msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:871 +msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:877 +msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:888 +msgid "Create an account" +msgstr "创建一个账户" + +#: ../source/guides/distributing-packages-using-setuptools.rst:890 +msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:894 +msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:897 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:901 +msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:904 +msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:913 +msgid "**Be aware that this stores your token in plaintext.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:915 +#: ../source/guides/migrating-to-pypi-org.rst:70 +#: ../source/guides/migrating-to-pypi-org.rst:109 +#: ../source/guides/using-testpypi.rst:83 +msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:921 +msgid "Upload your distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:923 +msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:926 +msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:930 +msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:937 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:944 +#: ../source/tutorials/installing-packages.rst:663 +msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:950 +msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:5 +msgid "Dropping support for older Python versions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:7 +msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:9 +msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:12 +msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:14 +msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:17 +msgid "Requirements" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:19 +msgid "This workflow requires that:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:21 +msgid "The publisher is using the latest version of :ref:`setuptools`," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:22 +msgid "The latest version of :ref:`twine` is used to upload the package," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:23 +msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:26 +msgid "Dealing with the universal wheels" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:28 +msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:36 +msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:48 +msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:53 +msgid "Defining the Python version required" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:56 +msgid "1. Download the newest version of Setuptools" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:58 +msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:60 +msgid "Steps:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:74 +msgid "`setuptools` version should be above 24.0.0." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:77 +msgid "2. Specify the version ranges for supported Python distributions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:79 +msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:81 +#: ../source/specifications/core-metadata.rst:139 +#: ../source/specifications/core-metadata.rst:463 +#: ../source/specifications/core-metadata.rst:487 +#: ../source/specifications/core-metadata.rst:527 +#: ../source/specifications/core-metadata.rst:550 +#: ../source/specifications/core-metadata.rst:583 +#: ../source/specifications/core-metadata.rst:693 +#: ../source/specifications/core-metadata.rst:722 +msgid "Examples::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:86 +msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:101 +msgid "3. Validating the Metadata before publishing" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:103 +msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:105 +msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:108 +msgid "You can see the contents of the generated file like this::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:112 +msgid "Validate that the following is in place, before publishing the package:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:114 +msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:115 +msgid "The Requires-Python field is set and matches your specification in setup.py." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:118 +msgid "4. Using Twine to publish" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:120 +msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:122 +msgid "Make sure you are using the newest version of Twine, at least 1.9." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:125 +msgid "Dropping a Python release" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:127 +msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:129 +msgid "It must be done in this order for the automated fallback to work." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:131 +msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:133 +msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:5 +msgid "Hosting your own simple repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:8 +msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:13 +msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:29 +msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:35 +msgid "\"Manual\" repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:37 +msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:51 +msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:58 +msgid "For complete documentation of the simple repository protocol, see :pep:`503`." +msgstr "" + +#: ../source/guides/index.rst:8 +#: ../source/guides/index.rst:8 +msgid "Installing Packages:" +msgstr "" + +#: ../source/guides/index.rst:20 +#: ../source/guides/index.rst:20 +msgid "Building and Publishing Projects:" +msgstr "" + +#: ../source/guides/index.rst:38 +#: ../source/guides/index.rst:38 +msgid "Miscellaneous:" +msgstr "" + +#: ../source/guides/index.rst:4 +msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:5 +msgid "Package index mirrors and caches" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:8 +#: ../source/guides/supporting-multiple-python-versions.rst:8 +msgid "2014-12-24" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:14 +msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:17 +msgid "Three options are available in this area:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:19 +msgid "pip provides local caching options," +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:20 +msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:22 +msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:27 +msgid "Caching with pip" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:29 +msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:32 +msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:36 +msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:45 +msgid "Caching with devpi" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:47 +msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:55 +msgid "Complete mirror with bandersnatch" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:57 +msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:63 +msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:5 +msgid "Installing scientific packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:11 +msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:16 +msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:22 +msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:29 +msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:35 +msgid "Building from source" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:37 +msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:45 +msgid "Linux distribution packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:47 +msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:51 +msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:57 +msgid "Windows installers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:59 +msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:64 +msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:67 +msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:73 +msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:79 +msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:86 +msgid "macOS installers and package managers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:88 +msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:92 +msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:99 +msgid "SciPy distributions" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:101 +msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:105 +msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:109 +#: ../source/key_projects.rst:596 +msgid "Spack" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:110 +msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:119 +msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:128 +msgid "The conda cross-platform package manager" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:130 +msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:136 +msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 +msgid "Installing stand alone command line tools" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 +msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 +msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 +msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 +msgid "pipx only works with Python 3.6+." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 +msgid "``pipx`` is installed with ``pip``:" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 +msgid "You may need to restart your terminal for the path updates to take effect." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 +msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 +#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 +msgid "For example" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 +msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 +msgid "To upgrade or uninstall the package" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 +msgid "``pipx`` can be upgraded or uninstalled with pip" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 +msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 +msgid "To see the full list of commands ``pipx`` offers, run" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 +msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:5 +msgid "Installing pip/setuptools/wheel with Linux Package Managers" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:8 +msgid "2015-09-17" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:11 +msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:14 +msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:18 +msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:25 +msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:32 +msgid "Fedora" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:34 +msgid "Fedora 21:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:36 +#: ../source/guides/installing-using-linux-tools.rst:45 +#: ../source/guides/installing-using-linux-tools.rst:124 +#: ../source/guides/installing-using-linux-tools.rst:138 +#: ../source/guides/installing-using-linux-tools.rst:158 +msgid "Python 2::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:41 +msgid "Python 3: ``sudo yum install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:43 +msgid "Fedora 22:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:50 +msgid "Python 3: ``sudo dnf install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:53 +msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:63 +msgid "CentOS/RHEL" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:65 +msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:68 +msgid "To install pip and wheel for the system Python, there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:70 +msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:77 +msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:81 +msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:85 +msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:92 +msgid "To additionally upgrade setuptools, run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:97 +msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:101 +msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:104 +msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:106 +msgid "For CentOS, see here: https://www.softwarecollections.org/en/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:108 +msgid "Be aware that collections may not contain the most recent versions." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:110 +msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:116 +msgid "For example, for Python 3.4 on CentOS7/RHEL7::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:122 +msgid "openSUSE" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:129 +#: ../source/guides/installing-using-linux-tools.rst:143 +#: ../source/guides/installing-using-linux-tools.rst:162 +msgid "Python 3::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:135 +msgid "Debian/Ubuntu" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:150 +msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:156 +msgid "Arch Linux" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:168 +msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 +msgid "Installing packages using pip and virtual environments" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 +msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 +msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 +msgid "Installing pip" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 +msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 +msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 +msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 +msgid "Afterwards, you should have the newest pip installed in your user site:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 +msgid "The Python installers for Windows include pip. You should be able to access pip using:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 +msgid "You can make sure that pip is up-to-date by running:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 +msgid "Installing virtualenv" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 +msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 +msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 +msgid "Creating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 +msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 +msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 +msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 +msgid "venv will create a virtual Python installation in the ``env`` folder." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 +msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 +msgid "Activating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 +msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 +msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 +msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 +msgid "Leaving the virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 +msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 +msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 +msgid "Installing packages" +msgstr "安装软件包" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 +msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 +msgid "pip should download requests and all of its dependencies and install them:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 +msgid "Installing specific versions" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 +msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 +msgid "To install the latest ``2.x`` release of requests:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 +msgid "To install pre-release versions of packages, use the ``--pre`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 +msgid "Installing extras" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 +msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 +msgid "Installing from source" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 +msgid "pip can install a package directly from source, for example:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 +msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 +msgid "Installing from version control systems" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 +msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 +msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 +#: ../source/tutorials/installing-packages.rst:569 +msgid "Installing from local archives" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 +msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 +msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 +msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 +msgid "Using other package indexes" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 +msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 +msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 +#: ../source/tutorials/installing-packages.rst:389 +msgid "Upgrading packages" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 +msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 +msgid "Using requirements files" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 +msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 +msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 +msgid "Freezing dependencies" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 +msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 +msgid "Which will output a list of package specifiers such as:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 +msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:2 +msgid "Making a PyPI-friendly README" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:4 +msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:9 +msgid "Creating a README file" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:11 +msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:13 +msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:16 +msgid "plain text" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:17 +msgid "`reStructuredText `_ (without Sphinx extensions)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:18 +msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:21 +msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:25 +msgid "Including your README in your package's metadata" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:27 +msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:33 +msgid ":ref:`description-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:34 +msgid ":ref:`description-content-type-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:36 +msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:39 +msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:45 +msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:60 +msgid "The minimum required versions of the respective tools are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:62 +msgid "``setuptools >= 38.6.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:63 +msgid "``wheel >= 0.31.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:64 +msgid "``twine >= 1.11.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:66 +msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:72 +msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:95 +msgid "Validating reStructuredText markup" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:97 +msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:100 +msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:105 +msgid "You can check your README for markup errors before uploading as follows:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:107 +msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:122 +msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:125 +msgid "Run ``twine check`` on the sdist and wheel::" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:129 +msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:4 +msgid "Migrating to PyPI.org" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:6 +msgid ":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``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:12 +msgid "Publishing releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:14 +msgid "``pypi.org`` is the default upload platform as of September 2016." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:16 +msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:22 +msgid "The default upload settings switched to ``pypi.org`` in the following versions:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:24 +msgid "``twine`` 1.8.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:25 +msgid "``setuptools`` 27.0.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:26 +msgid "Python 2.7.13 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:27 +msgid "Python 3.4.6 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:28 +msgid "Python 3.5.3 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:29 +msgid "Python 3.6.0 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:31 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:48 +msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:51 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:67 +msgid "(``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.)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:73 +msgid "Registering package names & metadata" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:75 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:79 +msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:84 +msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:89 +#: ../source/guides/using-testpypi.rst:5 +msgid "Using TestPyPI" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:91 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:113 +msgid "Registering new user accounts" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:115 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:121 +msgid "Browsing packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:123 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:130 +msgid "Downloading packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:132 +msgid "``pypi.org`` is the default host for downloading packages." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:135 +msgid "Managing published packages and releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:137 +msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:5 +msgid "Multi-version installs" +msgstr "" + +#: ../source/guides/multi-version-installs.rst:8 +msgid "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``)." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:13 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:31 +msgid "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 ``python -c ''`` to invoke the application's main entry point directly." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:38 +msgid "Refer to the `pkg_resources documentation `__ for more details." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:5 +msgid "Packaging binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:8 +msgid "2013-12-08" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:10 +msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:20 +msgid "An overview of binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:23 +msgid "Use cases" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:25 +msgid "The typical use cases for binary extensions break down into just three conventional categories:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:28 +msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:39 +msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:47 +msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:56 +msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:61 +msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:71 +msgid "Disadvantages" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:73 +msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:80 +msgid "This means that binary extensions:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:82 +msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:85 +msgid "may not be compatible with different builds of the CPython reference interpreter" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:88 +msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:91 +msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:96 +msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:101 +msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:108 +msgid "Alternatives to handcoded accelerator modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:110 +msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:115 +msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:122 +msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:132 +msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:141 +msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:150 +msgid "Alternatives to handcoded wrapper modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:152 +msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:158 +msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:162 +msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:168 +msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:175 +msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:181 +msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:185 +msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:189 +msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:203 +msgid "Alternatives for low level system access" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:205 +msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:213 +msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:222 +msgid "Implementing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:224 +msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:241 +msgid "Building binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:244 +msgid "Building extensions for multiple platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:246 +msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:256 +msgid "Binary extensions for Windows" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:258 +msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:263 +msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:269 +msgid "To set up a build environment for binary extensions, the steps are as follows:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:271 +msgid "For Python 2.7" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:273 +msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:276 +msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:278 +#: ../source/guides/packaging-binary-extensions.rst:288 +#: ../source/guides/packaging-binary-extensions.rst:295 +msgid "Done." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:280 +msgid "For Python 3.4" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:282 +msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:285 +msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:287 +msgid "Set DISTUTILS_USE_SDK=1" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:290 +msgid "For Python 3.5" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:292 +msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:297 +msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:301 +msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:305 +msgid "Binary extensions for Linux" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:307 +msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:313 +msgid "Binary extensions for macOS" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:315 +msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:325 +msgid "Publishing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:327 +msgid "For interim guidance on this topic, see the discussion in `this issue `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:343 +msgid "Additional resources" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:345 +msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:352 +msgid "Cross-platform wheel generation with scikit-build" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:354 +msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:362 +msgid "Introduction to C/C++ extension modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:364 +msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:367 +msgid "`What are (c)python extension modules? `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:368 +msgid "`Releasing the gil `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:369 +msgid "`Writing cpython extension modules using C++ `_" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:3 +msgid "Packaging namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:5 +msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:24 +msgid "And you use this package in your code like so::" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:29 +msgid "Then you can break these sub-packages into two separate distributions:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:46 +msgid "Each sub-package can now be separately installed, used, and versioned." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:48 +msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:58 +msgid "Creating a namespace package" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:60 +msgid "There are currently three different approaches to creating namespace packages:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:62 +msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:66 +msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:69 +msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:73 +msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:80 +msgid "Native namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:82 +msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:97 +msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:102 +msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:117 +msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:123 +msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:129 +msgid "pkgutil-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:131 +msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:136 +msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:148 +#: ../source/guides/packaging-namespace-packages.rst:194 +msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:155 +#: ../source/guides/packaging-namespace-packages.rst:201 +msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:160 +msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:171 +msgid "pkg_resources-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:173 +msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:182 +msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:206 +msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:216 +msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:223 +msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:237 +msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 +msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 +msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 +msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 +msgid "Saving credentials on GitHub" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 +msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 +msgid "Let's begin! 🚀" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 +msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 +msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 +msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 +msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 +msgid "Creating a workflow definition" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 +msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 +msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 +msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 +msgid "Defining a workflow job environment" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 +msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 +msgid "Checking out the project and building distributions" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 +msgid "Then, add the following under the ``build-n-publish`` section:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 +msgid "This will download your repository into the CI runner and then install and activate Python 3.7." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 +msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 +msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 +msgid "So add this to the steps list:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 +msgid "Publishing the distribution to PyPI and TestPyPI" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 +msgid "Finally, add the following steps at the end:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 +msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 +msgid "That's all, folks!" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 +msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:5 +msgid "Single-sourcing the package version" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:8 +msgid "There are many techniques to maintain a single source of truth for the version number of your project:" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:11 +msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:38 +msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:47 +msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:52 +msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:55 +msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:58 +msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:65 +msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:76 +msgid "Example using this technique: `warehouse `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:78 +msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:86 +msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:91 +msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:95 +msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:110 +msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:114 +msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:128 +msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:134 +msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:138 +msgid "Example using this technique: `setuptools `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:141 +msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:155 +msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:161 +msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:5 +msgid "Supporting multiple Python versions" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:37 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:43 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:49 +msgid "Automated testing and continuous integration" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:51 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:60 +msgid "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:" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:66 +msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:69 +msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:80 +msgid "Both `Travis CI`_ 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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:85 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:89 +msgid "Tools for single-source Python packages" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:91 +msgid "`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_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:100 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:107 +msgid "a Python 2 (by syntax) module in a Python 3 project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:108 +msgid "a Python 3 (by syntax) module in a *Python 2* project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:110 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:117 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:124 +msgid "What's in which Python?" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:126 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:3 +msgid "Supporting Windows using Appveyor" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:6 +msgid "2015-12-03" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:8 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:20 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:24 +msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:30 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:38 +msgid "Setting up" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:40 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:45 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:49 +msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:54 +msgid "Adding Appveyor support to your project" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:61 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:69 +msgid "appveyor.yml" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:75 +msgid "This file can be downloaded from `here `__." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:77 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:80 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:88 +msgid "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``)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:94 +msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:97 +msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:100 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:109 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:114 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:119 +msgid "Support script" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:121 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:126 +msgid "`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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:133 +msgid "You can simply download the batch file and include it in your project unchanged." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:137 +msgid "Access to the built wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:139 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:147 +msgid "Additional notes" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:150 +msgid "Testing with tox" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:152 +msgid "Many projects use the `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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:156 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:160 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:165 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:170 +msgid "``DISTUTILS_USE_SDK``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:171 +msgid "``MSSdk``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:172 +msgid "``INCLUDE``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:173 +msgid "``LIB``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:175 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:181 +msgid "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 Travis or 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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:188 +msgid "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``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:192 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:197 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:203 +msgid "Automatically uploading wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:205 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:210 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:216 +msgid "External dependencies" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:218 +msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:221 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:230 +msgid "Support scripts" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:232 +msgid "For reference, the SDK setup support script is listed here:" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:234 +msgid "``appveyor-sample/build.cmd``" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:5 +msgid "Tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:7 +msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:12 +msgid "Application dependency management" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:14 +msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:18 +msgid "When ``pipenv`` does not meet your use case, consider other tools like:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:20 +msgid ":ref:`pip`" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:22 +msgid "`pip-tools `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:24 +msgid "`Poetry `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:27 +msgid "Installation tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:29 +msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:34 +msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:37 +msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:40 +msgid ":ref:`buildout`: primarily focused on the web development community" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:42 +msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:47 +msgid "Packaging tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:49 +msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:52 +msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:56 +msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:61 +msgid "Publishing platform migration" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:63 +msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:67 +msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:72 +msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:77 +msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:82 +msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:88 +msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:93 +msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:102 +msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:107 +msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:5 +msgid "Including files in source distributions with ``MANIFEST.in``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:7 +msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:17 +msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:22 +msgid "How files are included in an sdist" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:24 +msgid "The following files are included in a source distribution by default:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:26 +msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:28 +msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:30 +msgid "scripts specified by the ``scripts`` ``setup()`` argument" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:31 +msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:33 +msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:35 +msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:37 +msgid "all files matching the pattern :file:`test/test*.py`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:38 +msgid ":file:`setup.py` (or whatever you called your setup script)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:39 +msgid ":file:`setup.cfg`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:40 +msgid ":file:`README`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:41 +msgid ":file:`README.txt`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:42 +msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:43 +msgid ":file:`README.md` (setuptools 36.4.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:44 +msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:45 +msgid ":file:`MANIFEST.in`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:47 +msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:52 +msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:60 +msgid ":file:`MANIFEST.in` commands" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:62 +msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:67 +msgid "Command" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid ":samp:`include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid "Add all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid ":samp:`exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid "Remove all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid ":samp:`global-include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid "Add all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid ":samp:`global-exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid "Remove all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid ":samp:`graft {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid "Add all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid ":samp:`prune {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid "Remove all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:79 +msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:87 +msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:91 +msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:95 +msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:101 +msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." +msgstr "" + +#: ../source/guides/using-testpypi.rst:7 +msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" +msgstr "" + +#: ../source/guides/using-testpypi.rst:13 +msgid "Registering your account" +msgstr "注册您的帐户" + +#: ../source/guides/using-testpypi.rst:15 +msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." +msgstr "" + +#: ../source/guides/using-testpypi.rst:19 +msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." +msgstr "" + +#: ../source/guides/using-testpypi.rst:24 +msgid "Using TestPyPI with Twine" +msgstr "" + +#: ../source/guides/using-testpypi.rst:26 +msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:33 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/using-testpypi.rst:39 +msgid "Using TestPyPI with pip" +msgstr "" + +#: ../source/guides/using-testpypi.rst:41 +msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:56 +msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" +msgstr "" + +#: ../source/guides/using-testpypi.rst:73 +msgid "Setting up TestPyPI in :file:`.pypirc`" +msgstr "在 :file:`.pypirc` 中设置 TestPyPI" + +#: ../source/guides/using-testpypi.rst:75 +msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" +msgstr "" + +#: ../source/index.rst:3 +#: ../source/key_projects.rst:181 +msgid "Python Packaging User Guide" +msgstr "Python 包装用户指南" + +#: ../source/index.rst:5 +msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." +msgstr "Python 打包用户指南 (PyPUG) 是一个打包 Python 软件的教程和指南的集合。" + +#: ../source/index.rst:5 +msgid "python, packaging, guide, tutorial" +msgstr "python, 包装, 指南, 教程" + +#: ../source/index.rst:24 +msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." +msgstr "" + +#: ../source/index.rst:28 +msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" +msgstr "" +"本指南由 `Python Packaging Authority ` 在 `GitHub`_ 上维护。我们很乐意接受任何 :doc:`贡献和反馈 " +"`。 😊" + +#: ../source/index.rst:36 +msgid "Get started" +msgstr "开始" + +#: ../source/index.rst:38 +msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" +msgstr "" + +#: ../source/index.rst:41 +msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" +msgstr "要学习如何安装软件包，请参阅 :doc:`安装软件包的教程 `" + +#: ../source/index.rst:43 +msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" +msgstr "" + +#: ../source/index.rst:45 +msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" +msgstr "要学习如何打包和发布您的项目，请参阅 :doc:`关于打包和发布的教程 `" + +#: ../source/index.rst:47 +msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" +msgstr "要获得对 Python 库和应用程序打包选项的概述，请参阅 :doc:`Python 打包概述 `" + +#: ../source/index.rst:52 +msgid "Learn more" +msgstr "了解更多" + +#: ../source/index.rst:54 +msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" +msgstr "" + +#: ../source/index.rst:56 +msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/index.rst:58 +msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." +msgstr "" + +#: ../source/index.rst:60 +msgid "The :doc:`specifications/index` section for packaging interoperability specifications." +msgstr "" + +#: ../source/index.rst:62 +msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." +msgstr "" + +#: ../source/key_projects.rst:6 +msgid "Project Summaries" +msgstr "项目摘要" + +#: ../source/key_projects.rst:8 +msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." +msgstr "" + +#: ../source/key_projects.rst:14 +msgid "PyPA Projects" +msgstr "PyPA 项目" + +#: ../source/key_projects.rst:19 +msgid "bandersnatch" +msgstr "" + +#: ../source/key_projects.rst:21 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:25 +msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." +msgstr "" + +#: ../source/key_projects.rst:35 +msgid "build" +msgstr "建造" + +#: ../source/key_projects.rst:37 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:42 +msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." +msgstr "" + +#: ../source/key_projects.rst:49 +msgid "cibuildwheel" +msgstr "" + +#: ../source/key_projects.rst:51 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" +msgstr "" + +#: ../source/key_projects.rst:58 +msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." +msgstr "" + +#: ../source/key_projects.rst:64 +msgid "distlib" +msgstr "" + +#: ../source/key_projects.rst:66 +msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:71 +msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." +msgstr "" + +#: ../source/key_projects.rst:80 +msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." +msgstr "" + +#: ../source/key_projects.rst:90 +msgid "packaging" +msgstr "" + +#: ../source/key_projects.rst:92 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:97 +msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." +msgstr "" + +#: ../source/key_projects.rst:99 +msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." +msgstr "" + +#: ../source/key_projects.rst:107 +msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." +msgstr "" + +#: ../source/key_projects.rst:119 +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "pip" +msgstr "" + +#: ../source/key_projects.rst:121 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:126 +msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." +msgstr "" + +#: ../source/key_projects.rst:129 +msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." +msgstr "" + +#: ../source/key_projects.rst:137 +msgid "Pipenv" +msgstr "" + +#: ../source/key_projects.rst:139 +msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:144 +msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." +msgstr "" + +#: ../source/key_projects.rst:148 +msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." +msgstr "" + +#: ../source/key_projects.rst:159 +msgid "Pipfile" +msgstr "" + +#: ../source/key_projects.rst:161 +msgid "`Source `__" +msgstr "" + +#: ../source/key_projects.rst:163 +msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." +msgstr "" + +#: ../source/key_projects.rst:170 +msgid "pipx" +msgstr "" + +#: ../source/key_projects.rst:172 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:176 +msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." +msgstr "" + +#: ../source/key_projects.rst:183 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:187 +msgid "This guide!" +msgstr "" + +#: ../source/key_projects.rst:192 +msgid "readme_renderer" +msgstr "" + +#: ../source/key_projects.rst:194 +msgid "`GitHub and docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:197 +msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." +msgstr "" + +#: ../source/key_projects.rst:208 +msgid "setuptools" +msgstr "" + +#: ../source/key_projects.rst:210 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:215 +msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." +msgstr "" + +#: ../source/key_projects.rst:220 +msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." +msgstr "" + +#: ../source/key_projects.rst:227 +msgid "trove-classifiers" +msgstr "" + +#: ../source/key_projects.rst:229 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:233 +msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." +msgstr "" + +#: ../source/key_projects.rst:239 +msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." +msgstr "" + +#: ../source/key_projects.rst:253 +msgid "twine" +msgstr "" + +#: ../source/key_projects.rst:255 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:260 +msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." +msgstr "" + +#: ../source/key_projects.rst:270 +#: ../source/overview.rst:415 +msgid "virtualenv" +msgstr "" + +#: ../source/key_projects.rst:272 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:277 +msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/key_projects.rst:290 +msgid "Warehouse" +msgstr "" + +#: ../source/key_projects.rst:292 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:296 +msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." +msgstr "" + +#: ../source/key_projects.rst:304 +msgid "wheel" +msgstr "" + +#: ../source/key_projects.rst:306 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:311 +msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." +msgstr "" + +#: ../source/key_projects.rst:315 +msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." +msgstr "" + +#: ../source/key_projects.rst:324 +msgid "Non-PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:329 +msgid "bento" +msgstr "" + +#: ../source/key_projects.rst:331 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:336 +msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." +msgstr "" + +#: ../source/key_projects.rst:344 +msgid "buildout" +msgstr "" + +#: ../source/key_projects.rst:346 +msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:351 +msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." +msgstr "" + +#: ../source/key_projects.rst:358 +msgid "conda" +msgstr "" + +#: ../source/key_projects.rst:360 +msgid "`Docs `__" +msgstr "" + +#: ../source/key_projects.rst:362 +msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." +msgstr "" + +#: ../source/key_projects.rst:369 +msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." +msgstr "" + +#: ../source/key_projects.rst:373 +msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." +msgstr "" + +#: ../source/key_projects.rst:386 +msgid "devpi" +msgstr "" + +#: ../source/key_projects.rst:388 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:392 +msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." +msgstr "" + +#: ../source/key_projects.rst:401 +msgid "flit" +msgstr "" + +#: ../source/key_projects.rst:403 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:407 +msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." +msgstr "" + +#: ../source/key_projects.rst:412 +msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." +msgstr "" + +#: ../source/key_projects.rst:422 +msgid "enscons" +msgstr "" + +#: ../source/key_projects.rst:424 +msgid "`Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:428 +msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." +msgstr "" + +#: ../source/key_projects.rst:443 +msgid "Hashdist" +msgstr "" + +#: ../source/key_projects.rst:445 +msgid "`Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:448 +msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." +msgstr "" + +#: ../source/key_projects.rst:460 +msgid "hatch" +msgstr "" + +#: ../source/key_projects.rst:462 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:465 +msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." +msgstr "" + +#: ../source/key_projects.rst:475 +msgid "multibuild" +msgstr "" + +#: ../source/key_projects.rst:477 +msgid "`GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:479 +msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." +msgstr "" + +#: ../source/key_projects.rst:485 +msgid "pex" +msgstr "" + +#: ../source/key_projects.rst:487 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:491 +msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." +msgstr "" + +#: ../source/key_projects.rst:500 +msgid "pip-tools" +msgstr "" + +#: ../source/key_projects.rst:502 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:505 +msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." +msgstr "" + +#: ../source/key_projects.rst:517 +msgid "piwheels" +msgstr "" + +#: ../source/key_projects.rst:519 +msgid "`Website `__ | `Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:523 +msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." +msgstr "" + +#: ../source/key_projects.rst:532 +msgid "poetry" +msgstr "" + +#: ../source/key_projects.rst:534 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:538 +msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." +msgstr "" + +#: ../source/key_projects.rst:548 +msgid "pypiserver" +msgstr "" + +#: ../source/key_projects.rst:550 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:554 +msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." +msgstr "" + +#: ../source/key_projects.rst:564 +msgid "scikit-build" +msgstr "" + +#: ../source/key_projects.rst:566 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:570 +msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." +msgstr "" + +#: ../source/key_projects.rst:582 +msgid "shiv" +msgstr "" + +#: ../source/key_projects.rst:584 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:588 +msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." +msgstr "" + +#: ../source/key_projects.rst:598 +msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" +msgstr "" + +#: ../source/key_projects.rst:603 +msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." +msgstr "" + +#: ../source/key_projects.rst:611 +msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." +msgstr "" + +#: ../source/key_projects.rst:617 +msgid "zest.releaser" +msgstr "" + +#: ../source/key_projects.rst:619 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:623 +msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." +msgstr "" + +#: ../source/key_projects.rst:630 +msgid "Standard Library Projects" +msgstr "" + +#: ../source/key_projects.rst:635 +msgid "ensurepip" +msgstr "" + +#: ../source/key_projects.rst:637 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:640 +msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." +msgstr "" + +#: ../source/key_projects.rst:649 +msgid "distutils" +msgstr "" + +#: ../source/key_projects.rst:651 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:654 +msgid "The original Python packaging system, added to the standard library in Python 2.0." +msgstr "" + +#: ../source/key_projects.rst:657 +msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." +msgstr "" + +#: ../source/key_projects.rst:670 +msgid "venv" +msgstr "" + +#: ../source/key_projects.rst:672 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:675 +msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/news.rst:2 +msgid "News" +msgstr "" + +#: ../source/news.rst:5 +msgid "September 2019" +msgstr "" + +#: ../source/news.rst:6 +msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" +msgstr "" + +#: ../source/news.rst:9 +msgid "August 2019" +msgstr "" + +#: ../source/news.rst:10 +msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" +msgstr "" + +#: ../source/news.rst:13 +msgid "July 2019" +msgstr "" + +#: ../source/news.rst:14 +msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" +msgstr "" + +#: ../source/news.rst:15 +msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" +msgstr "" + +#: ../source/news.rst:16 +msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" +msgstr "" + +#: ../source/news.rst:17 +msgid "Updated directory layout examples for consistency. (:pr:`611`)" +msgstr "" + +#: ../source/news.rst:18 +msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" +msgstr "" + +#: ../source/news.rst:21 +msgid "June 2019" +msgstr "" + +#: ../source/news.rst:22 +msgid "Fixed some typos. (:pr:`620`)" +msgstr "" + +#: ../source/news.rst:25 +msgid "May 2019" +msgstr "" + +#: ../source/news.rst:26 +msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" +msgstr "" + +#: ../source/news.rst:27 +msgid "Added a MANIFEST.in guide page. (:pr:`609`)" +msgstr "" + +#: ../source/news.rst:30 +msgid "April 2019" +msgstr "" + +#: ../source/news.rst:31 +msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" +msgstr "" + +#: ../source/news.rst:32 +msgid "Reduced emphasis on virtualenv. (:pr:`606`)" +msgstr "" + +#: ../source/news.rst:35 +msgid "March 2019" +msgstr "" + +#: ../source/news.rst:36 +msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" +msgstr "" + +#: ../source/news.rst:37 +msgid "Covered RTD details for contributing. (:pr:`600`)" +msgstr "" + +#: ../source/news.rst:40 +msgid "February 2019" +msgstr "" + +#: ../source/news.rst:41 +msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" +msgstr "" + +#: ../source/news.rst:42 +msgid "Added instructions to install Python CLI applications. (:pr:`594`)" +msgstr "" + +#: ../source/news.rst:45 +msgid "January 2019" +msgstr "" + +#: ../source/news.rst:46 +msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" +msgstr "" + +#: ../source/news.rst:47 +msgid "Updated Sphinx and Nox. (:pr:`591`)" +msgstr "" + +#: ../source/news.rst:48 +msgid "Referenced Twine from Python3. (:pr:`581`)" +msgstr "" + +#: ../source/news.rst:51 +msgid "December 2018" +msgstr "" + +#: ../source/news.rst:52 +msgid "No programmers in the office!" +msgstr "" + +#: ../source/news.rst:55 +msgid "November 2018" +msgstr "" + +#: ../source/news.rst:56 +msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" +msgstr "" + +#: ../source/news.rst:57 +msgid "Changed bumpversion to bump2version. (:pr:`572`)" +msgstr "" + +#: ../source/news.rst:58 +msgid "Added single-sourcing package version example. (:pr:`573`)" +msgstr "" + +#: ../source/news.rst:59 +msgid "Added a guide for creating documentation. (:pr:`568`)" +msgstr "" + +#: ../source/news.rst:62 +msgid "October 2018" +msgstr "" + +#: ../source/news.rst:63 +msgid "Updated Nox package name. (:pr:`566`)" +msgstr "" + +#: ../source/news.rst:64 +msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" +msgstr "" + +#: ../source/news.rst:67 +msgid "September 2018" +msgstr "" + +#: ../source/news.rst:68 +msgid "Added a section on checking RST markup. (:pr:`554`)" +msgstr "" + +#: ../source/news.rst:69 +msgid "Updated user installs page. (:pr:`558`)" +msgstr "" + +#: ../source/news.rst:70 +msgid "Updated Google BigQuery urls. (:pr:`556`)" +msgstr "" + +#: ../source/news.rst:71 +msgid "Replaced tar command with working command. (:pr:`552`)" +msgstr "" + +#: ../source/news.rst:72 +msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" +msgstr "" + +#: ../source/news.rst:75 +msgid "August 2018" +msgstr "" + +#: ../source/news.rst:76 +msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" +msgstr "" + +#: ../source/news.rst:77 +msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" +msgstr "" + +#: ../source/news.rst:78 +msgid "Updated Python version supported by virtualenv. (:pr:`538`)" +msgstr "" + +#: ../source/news.rst:79 +msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" +msgstr "" + +#: ../source/news.rst:82 +msgid "July 2018" +msgstr "" + +#: ../source/news.rst:84 +msgid "Improved binary extension docs. (:pr:`531`)" +msgstr "" + +#: ../source/news.rst:85 +msgid "Added scikit-build to key projects. (:pr:`530`)" +msgstr "" + +#: ../source/news.rst:88 +msgid "June 2018" +msgstr "" + +#: ../source/news.rst:90 +msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" +msgstr "" + +#: ../source/news.rst:91 +msgid "Updated Markdown descriptions explanation. (:pr:`522`)" +msgstr "" + +#: ../source/news.rst:94 +msgid "May 2018" +msgstr "" + +#: ../source/news.rst:96 +msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" +msgstr "" + +#: ../source/news.rst:97 +msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" +msgstr "" + +#: ../source/news.rst:98 +msgid "Simplified packaging tutorial. (:pr:`498`)" +msgstr "" + +#: ../source/news.rst:99 +msgid "Updated Windows users instructions for clarity. (:pr:`493`)" +msgstr "" + +#: ../source/news.rst:100 +msgid "Updated the license section description for completeness. (:pr:`492`)" +msgstr "" + +#: ../source/news.rst:101 +msgid "Added specification-style document to contributing section. (:pr:`489`)" +msgstr "" + +#: ../source/news.rst:102 +msgid "Added documentation types to contributing guide. (:pr:`485`)" +msgstr "" + +#: ../source/news.rst:105 +msgid "April 2018" +msgstr "" + +#: ../source/news.rst:107 +msgid "Added README guide. (:pr:`461`)" +msgstr "" + +#: ../source/news.rst:108 +msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" +msgstr "" + +#: ../source/news.rst:109 +msgid "Added instructions for Warehouse. (:pr:`471`)" +msgstr "" + +#: ../source/news.rst:110 +msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" +msgstr "" + +#: ../source/news.rst:111 +msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" +msgstr "" + +#: ../source/news.rst:112 +msgid "Added a guide for phasing out Python versions. (:pr:`459`)" +msgstr "" + +#: ../source/news.rst:113 +msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" +msgstr "" + +#: ../source/news.rst:116 +msgid "March 2018" +msgstr "" + +#: ../source/news.rst:118 +msgid "Updated \"installing scientific packages\". (:pr:`455`)" +msgstr "" + +#: ../source/news.rst:119 +msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" +msgstr "" + +#: ../source/news.rst:120 +msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" +msgstr "" + +#: ../source/news.rst:121 +msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" +msgstr "" + +#: ../source/news.rst:124 +msgid "February 2018" +msgstr "" + +#: ../source/news.rst:126 +msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" +msgstr "" + +#: ../source/news.rst:127 +msgid "Updated PyPI migration info. (:pr:`439`)" +msgstr "" + +#: ../source/news.rst:128 +msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" +msgstr "" + +#: ../source/news.rst:129 +msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" +msgstr "" + +#: ../source/news.rst:130 +msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" +msgstr "" + +#: ../source/news.rst:133 +msgid "January 2018" +msgstr "" + +#: ../source/news.rst:135 +msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" +msgstr "" + +#: ../source/news.rst:136 +msgid "Updated README.rst explanation. (:pr:`419`)" +msgstr "" + +#: ../source/news.rst:139 +msgid "December 2017" +msgstr "" + +#: ../source/news.rst:141 +msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" +msgstr "" + +#: ../source/news.rst:142 +msgid "Noted which fields can be used with environment markers. (:pr:`416`)" +msgstr "" + +#: ../source/news.rst:143 +msgid "Updated Requires-Python section. (:pr:`414`)" +msgstr "" + +#: ../source/news.rst:144 +msgid "Added news page. (:pr:`404`)" +msgstr "" + +#: ../source/news.rst:147 +msgid "November 2017" +msgstr "" + +#: ../source/news.rst:149 +msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" +msgstr "" + +#: ../source/news.rst:150 +msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" +msgstr "" + +#: ../source/news.rst:152 +msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:153 +msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" +msgstr "" + +#: ../source/news.rst:156 +msgid "October 2017" +msgstr "" + +#: ../source/news.rst:158 +msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:159 +msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" +msgstr "" + +#: ../source/news.rst:160 +msgid "Split the specifications page into multiple pages. (:pr:`386`)" +msgstr "" + +#: ../source/news.rst:163 +msgid "September 2017" +msgstr "" + +#: ../source/news.rst:165 +msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" +msgstr "" + +#: ../source/news.rst:167 +msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" +msgstr "" + +#: ../source/news.rst:170 +msgid "August 2017" +msgstr "" + +#: ../source/news.rst:172 +msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" +msgstr "" + +#: ../source/news.rst:173 +msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" +msgstr "" + +#: ../source/news.rst:174 +msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" +msgstr "" + +#: ../source/news.rst:177 +msgid "July 2017" +msgstr "" + +#: ../source/news.rst:179 +msgid "Added ``flit`` to the key projects list. (:pr:`358`)" +msgstr "" + +#: ../source/news.rst:180 +msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" +msgstr "" + +#: ../source/news.rst:181 +msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" +msgstr "" + +#: ../source/news.rst:182 +msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" +msgstr "" + +#: ../source/news.rst:183 +msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" +msgstr "" + +#: ../source/news.rst:186 +msgid "June 2017" +msgstr "" + +#: ../source/news.rst:188 +msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" +msgstr "" + +#: ../source/news.rst:189 +msgid "Added documentation for ``python_requires``. (:pr:`338`)" +msgstr "" + +#: ../source/news.rst:190 +msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" +msgstr "" + +#: ../source/news.rst:191 +msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" +msgstr "" + +#: ../source/news.rst:192 +msgid "Added a license section to the distributing guide. (:pr:`331`)" +msgstr "" + +#: ../source/news.rst:193 +msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" +msgstr "" + +#: ../source/news.rst:194 +msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" +msgstr "" + +#: ../source/news.rst:195 +msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" +msgstr "" + +#: ../source/news.rst:196 +msgid "Switched to the PyPA theme. (:pr:`305`)" +msgstr "" + +#: ../source/news.rst:197 +msgid "Re-organized the documentation into the new structure. (:pr:`318`)" +msgstr "" + +#: ../source/news.rst:200 +msgid "May 2017" +msgstr "" + +#: ../source/news.rst:202 +msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" +msgstr "" + +#: ../source/news.rst:203 +msgid "Added contributor and style guide. (:pr:`307`)" +msgstr "" + +#: ../source/news.rst:204 +msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" +msgstr "" + +#: ../source/news.rst:207 +msgid "April 2017" +msgstr "" + +#: ../source/news.rst:209 +msgid "Added travis configuration for testing pull requests. (:pr:`300`)" +msgstr "" + +#: ../source/news.rst:210 +msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" +msgstr "" + +#: ../source/news.rst:211 +msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" +msgstr "" + +#: ../source/news.rst:212 +msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" +msgstr "" + +#: ../source/news.rst:213 +msgid "Added a topic on namespace packages. (:pr:`290`)" +msgstr "" + +#: ../source/news.rst:214 +msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" +msgstr "" + +#: ../source/news.rst:215 +msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" +msgstr "" + +#: ../source/news.rst:216 +msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" +msgstr "" + +#: ../source/news.rst:217 +msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" +msgstr "" + +#: ../source/news.rst:219 +msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" +msgstr "" + +#: ../source/news.rst:223 +msgid "March 2017" +msgstr "" + +#: ../source/news.rst:225 +msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" +msgstr "" + +#: ../source/news.rst:228 +msgid "February 2017" +msgstr "" + +#: ../source/news.rst:230 +msgid "Added :pep:`518`. (:pr:`281`)" +msgstr "" + +#: ../source/overview.rst:3 +msgid "An Overview of Packaging for Python" +msgstr "" + +#: ../source/overview.rst:7 +msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." +msgstr "" + +#: ../source/overview.rst:12 +msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." +msgstr "" + +#: ../source/overview.rst:18 +msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." +msgstr "" + +#: ../source/overview.rst:26 +msgid "Thinking about deployment" +msgstr "" + +#: ../source/overview.rst:28 +msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" +msgstr "" + +#: ../source/overview.rst:32 +msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" +msgstr "" + +#: ../source/overview.rst:35 +msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" +msgstr "" + +#: ../source/overview.rst:37 +msgid "Is your software installed individually, or in large deployment batches?" +msgstr "" + +#: ../source/overview.rst:39 +msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." +msgstr "" + +#: ../source/overview.rst:46 +msgid "Packaging Python libraries and tools" +msgstr "" + +#: ../source/overview.rst:48 +msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/overview.rst:53 +msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." +msgstr "" + +#: ../source/overview.rst:59 +msgid "Python modules" +msgstr "" + +#: ../source/overview.rst:61 +msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." +msgstr "" + +#: ../source/overview.rst:66 +msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." +msgstr "" + +#: ../source/overview.rst:73 +msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." +msgstr "" + +#: ../source/overview.rst:78 +msgid "Python source distributions" +msgstr "" + +#: ../source/overview.rst:80 +msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." +msgstr "" + +#: ../source/overview.rst:84 +msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." +msgstr "" + +#: ../source/overview.rst:90 +msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." +msgstr "" + +#: ../source/overview.rst:95 +msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." +msgstr "" + +#: ../source/overview.rst:100 +msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." +msgstr "" + +#: ../source/overview.rst:107 +msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" +msgstr "" + +#: ../source/overview.rst:114 +msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." +msgstr "" + +#: ../source/overview.rst:119 +msgid "Python binary distributions" +msgstr "" + +#: ../source/overview.rst:121 +msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." +msgstr "" + +#: ../source/overview.rst:125 +msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." +msgstr "" + +#: ../source/overview.rst:132 +msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." +msgstr "" + +#: ../source/overview.rst:140 +msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." +msgstr "" + +#: ../source/overview.rst:148 +msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." +msgstr "" + +#: ../source/overview.rst:155 +msgid "Packaging Python applications" +msgstr "" + +#: ../source/overview.rst:157 +msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." +msgstr "" + +#: ../source/overview.rst:162 +msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." +msgstr "" + +#: ../source/overview.rst:166 +msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." +msgstr "" + +#: ../source/overview.rst:172 +msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." +msgstr "" + +#: ../source/overview.rst:176 +msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." +msgstr "" + +#: ../source/overview.rst:181 +msgid "Depending on a framework" +msgstr "" + +#: ../source/overview.rst:183 +msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." +msgstr "" + +#: ../source/overview.rst:189 +msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." +msgstr "" + +#: ../source/overview.rst:195 +msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." +msgstr "" + +#: ../source/overview.rst:199 +msgid "Service platforms" +msgstr "" + +#: ../source/overview.rst:201 +msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." +msgstr "" + +#: ../source/overview.rst:205 +msgid "`Heroku `_" +msgstr "" + +#: ../source/overview.rst:206 +msgid "`Google App Engine `_" +msgstr "" + +#: ../source/overview.rst:207 +msgid "`PythonAnywhere `_" +msgstr "" + +#: ../source/overview.rst:208 +msgid "`OpenShift `_" +msgstr "" + +#: ../source/overview.rst:209 +msgid "\"Serverless\" frameworks like `Zappa `_" +msgstr "" + +#: ../source/overview.rst:211 +msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." +msgstr "" + +#: ../source/overview.rst:216 +msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." +msgstr "" + +#: ../source/overview.rst:220 +msgid "Web browsers and mobile applications" +msgstr "" + +#: ../source/overview.rst:222 +msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." +msgstr "" + +#: ../source/overview.rst:227 +msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" +msgstr "" + +#: ../source/overview.rst:231 +msgid "`Kivy `_" +msgstr "" + +#: ../source/overview.rst:232 +msgid "`Beeware `_" +msgstr "" + +#: ../source/overview.rst:233 +msgid "`Brython `_" +msgstr "" + +#: ../source/overview.rst:234 +msgid "`Flexx `_" +msgstr "" + +#: ../source/overview.rst:236 +msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." +msgstr "" + +#: ../source/overview.rst:241 +msgid "Depending on a pre-installed Python" +msgstr "" + +#: ../source/overview.rst:243 +msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." +msgstr "" + +#: ../source/overview.rst:249 +msgid "Technologies which support this model:" +msgstr "" + +#: ../source/overview.rst:251 +msgid "`PEX `_ (Python EXecutable)" +msgstr "" + +#: ../source/overview.rst:252 +msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" +msgstr "" + +#: ../source/overview.rst:253 +msgid "`shiv `_ (requires Python 3)" +msgstr "" + +#: ../source/overview.rst:255 +msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." +msgstr "" + +#: ../source/overview.rst:260 +msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." +msgstr "" + +#: ../source/overview.rst:267 +msgid "Depending on a separate software distribution ecosystem" +msgstr "" + +#: ../source/overview.rst:269 +msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." +msgstr "" + +#: ../source/overview.rst:274 +msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." +msgstr "" + +#: ../source/overview.rst:284 +msgid "Instructions on building and publishing for the Anaconda ecosystem:" +msgstr "" + +#: ../source/overview.rst:286 +msgid "`Building libraries and applications with conda `_" +msgstr "" + +#: ../source/overview.rst:287 +msgid "`Transitioning a native Python package to Anaconda `_" +msgstr "" + +#: ../source/overview.rst:289 +msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" +msgstr "" + +#: ../source/overview.rst:293 +msgid "`Enthought Canopy `_" +msgstr "" + +#: ../source/overview.rst:294 +msgid "`ActiveState ActivePython `_" +msgstr "" + +#: ../source/overview.rst:295 +msgid "`WinPython `_" +msgstr "" + +#: ../source/overview.rst:300 +msgid "Bringing your own Python executable" +msgstr "" + +#: ../source/overview.rst:302 +msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." +msgstr "" + +#: ../source/overview.rst:306 +msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." +msgstr "" + +#: ../source/overview.rst:311 +msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." +msgstr "" + +#: ../source/overview.rst:315 +msgid "A selection of Python freezers:" +msgstr "" + +#: ../source/overview.rst:317 +msgid "`pyInstaller `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:318 +msgid "`cx_Freeze `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:319 +msgid "`constructor `_ - For command-line installers" +msgstr "" + +#: ../source/overview.rst:320 +msgid "`py2exe `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:321 +msgid "`py2app `_ - Mac only" +msgstr "" + +#: ../source/overview.rst:322 +msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" +msgstr "" + +#: ../source/overview.rst:323 +msgid "`osnap `_ - Windows and Mac" +msgstr "" + +#: ../source/overview.rst:324 +msgid "`pynsist `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:326 +msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." +msgstr "" + +#: ../source/overview.rst:332 +msgid "Bringing your own userspace" +msgstr "" + +#: ../source/overview.rst:334 +msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." +msgstr "" + +#: ../source/overview.rst:341 +msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." +msgstr "" + +#: ../source/overview.rst:344 +msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" +msgstr "" + +#: ../source/overview.rst:347 +msgid "`AppImage `_" +msgstr "" + +#: ../source/overview.rst:348 +msgid "`Docker `_" +msgstr "" + +#: ../source/overview.rst:349 +msgid "`Flatpak `_" +msgstr "" + +#: ../source/overview.rst:350 +msgid "`Snapcraft `_" +msgstr "" + +#: ../source/overview.rst:353 +msgid "Bringing your own kernel" +msgstr "" + +#: ../source/overview.rst:355 +msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." +msgstr "" + +#: ../source/overview.rst:360 +msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" +msgstr "" + +#: ../source/overview.rst:364 +msgid "`Vagrant `_" +msgstr "" + +#: ../source/overview.rst:365 +msgid "`VHD `_, `AMI `_, and `other formats `_" +msgstr "" + +#: ../source/overview.rst:366 +msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" +msgstr "" + +#: ../source/overview.rst:369 +msgid "Bringing your own hardware" +msgstr "" + +#: ../source/overview.rst:371 +msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." +msgstr "" + +#: ../source/overview.rst:375 +msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." +msgstr "" + +#: ../source/overview.rst:379 +msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." +msgstr "" + +#: ../source/overview.rst:389 +msgid "The simplified gamut of technologies used to package Python applications." +msgstr "" + +#: ../source/overview.rst:392 +msgid "What about..." +msgstr "" + +#: ../source/overview.rst:394 +msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." +msgstr "" + +#: ../source/overview.rst:398 +msgid "Operating system packages" +msgstr "" + +#: ../source/overview.rst:400 +msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." +msgstr "" + +#: ../source/overview.rst:411 +msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." +msgstr "" + +#: ../source/overview.rst:417 +msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." +msgstr "" + +#: ../source/overview.rst:427 +msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." +msgstr "" + +#: ../source/overview.rst:432 +msgid "Security" +msgstr "安全" + +#: ../source/overview.rst:434 +msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." +msgstr "" + +#: ../source/overview.rst:437 +msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." +msgstr "" + +#: ../source/overview.rst:446 +msgid "Wrap up" +msgstr "" + +#: ../source/overview.rst:448 +msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:6 +msgid "Binary distribution format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:8 +msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:13 +msgid "Abstract" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:15 +msgid "This PEP describes a built-package format for Python called \"wheel\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:17 +msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:27 +msgid "PEP Acceptance" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:29 +msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:34 +msgid "Rationale" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:36 +msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:43 +msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:52 +msgid "Details" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:55 +msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:57 +msgid "Wheel installation notionally consists of two phases:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:59 +msgid "Unpack." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:61 +msgid "Parse ``distribution-1.0.dist-info/WHEEL``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:62 +msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:64 +msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:66 +msgid "Else unpack archive into platlib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:68 +msgid "Spread." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:70 +msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:72 +msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:78 +msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:80 +msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:82 +msgid "Remove empty ``distribution-1.0.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:83 +msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:87 +msgid "Recommended installer features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:97 +msgid "Rewrite ``#!python``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:90 +msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:96 +msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:102 +msgid "Generate script wrappers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:100 +msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:105 +msgid "Recommended archiver features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:112 +msgid "Place ``.dist-info`` at the end of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:108 +msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:115 +msgid "File Format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:118 +msgid "File name convention" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:120 +msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "distribution" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "Distribution name, e.g. 'django', 'pyramid'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "Distribution version, e.g. 1.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:135 +msgid "build tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:130 +msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "language implementation and version tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "E.g. 'py27', 'py2', 'py3'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "abi tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "E.g. 'cp33m', 'abi3', 'none'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "platform tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "E.g. 'linux_x86_64', 'any'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:146 +msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:151 +msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:156 +msgid "Escaping and Unicode" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:158 +msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:161 +msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:164 +msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:166 +msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:169 +msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:172 +msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:176 +msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:182 +msgid "File contents" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:184 +msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:188 +msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:191 +msgid "``{distribution}-{version}.dist-info/`` contains metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:192 +msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:196 +msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:200 +msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:202 +msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:212 +msgid "``Wheel-Version`` is the version number of the Wheel specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:213 +msgid "``Generator`` is the name and optionally the version of the software that produced the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:215 +msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:218 +msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:220 +msgid "``Build`` is the build number and is omitted if there is no build number." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:221 +msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:224 +msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:226 +msgid "Wheel does not contain setup.py or setup.cfg." +msgstr "Wheel 不包含 setup.py 或 setup.cfg。" + +#: ../source/specifications/binary-distribution-format.rst:228 +msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:235 +#: ../source/specifications/recording-installed-packages.rst:35 +msgid "The .dist-info directory" +msgstr "目录 .dist-info" + +#: ../source/specifications/binary-distribution-format.rst:237 +msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:239 +msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:241 +msgid "WHEEL is the wheel metadata specific to a build of the package." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:242 +msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:248 +msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:249 +msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:251 +msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:254 +msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:261 +msgid "The .data directory" +msgstr ".data 目录" + +#: ../source/specifications/binary-distribution-format.rst:263 +msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:271 +msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:277 +msgid "Signed wheel files" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:279 +msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:290 +msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:295 +msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:302 +msgid "(The hash value is the same format used in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:304 +msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:307 +msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:312 +msgid "See" +msgstr "见" + +#: ../source/specifications/binary-distribution-format.rst:314 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" +msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" + +#: ../source/specifications/binary-distribution-format.rst:315 +msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" +msgstr "" +"http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" + +#: ../source/specifications/binary-distribution-format.rst:316 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" +msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" + +#: ../source/specifications/binary-distribution-format.rst:317 +msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" +msgstr "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" + +#: ../source/specifications/binary-distribution-format.rst:321 +msgid "Comparison to .egg" +msgstr "与 .egg 的比较" + +#: ../source/specifications/binary-distribution-format.rst:323 +msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:328 +msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:331 +msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:337 +msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:341 +msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:344 +msgid "Wheel is a reference to the other Python." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:348 +msgid "FAQ" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:352 +msgid "Wheel defines a .data directory. Should I put all my data there?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:354 +msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:363 +msgid "Why does wheel include attached signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:365 +msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:373 +msgid "Why does wheel allow JWS signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:375 +msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:381 +msgid "Why does wheel also allow S/MIME signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:383 +msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:386 +msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:391 +msgid "What's the deal with \"purelib\" vs. \"platlib\"?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:393 +msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:398 +msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:403 +msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:409 +msgid "Is it possible to import Python code directly from a wheel file?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:411 +msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:417 +msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:426 +msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:443 +msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:450 +msgid "Changes" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:452 +msgid "Since :pep:`427`, this specification has changed as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:454 +msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:461 +msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:466 +msgid "Appendix" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:468 +msgid "Example urlsafe-base64-nopad implementation::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:482 +msgid "Copyright" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:484 +msgid "This document has been placed into the public domain." +msgstr "" + +#: ../source/specifications/core-metadata.rst:5 +msgid "Core metadata specifications" +msgstr "" + +#: ../source/specifications/core-metadata.rst:7 +msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:10 +msgid "``Metadata-Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:11 +msgid "``Name``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:12 +msgid "``Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:14 +msgid "All the other fields are optional." +msgstr "" + +#: ../source/specifications/core-metadata.rst:16 +msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." +msgstr "" + +#: ../source/specifications/core-metadata.rst:25 +msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:30 +msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." +msgstr "" + +#: ../source/specifications/core-metadata.rst:41 +msgid "Metadata-Version" +msgstr "" + +#: ../source/specifications/core-metadata.rst:45 +msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." +msgstr "" + +#: ../source/specifications/core-metadata.rst:48 +msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:54 +msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." +msgstr "" + +#: ../source/specifications/core-metadata.rst:58 +#: ../source/specifications/core-metadata.rst:80 +#: ../source/specifications/core-metadata.rst:95 +#: ../source/specifications/core-metadata.rst:155 +#: ../source/specifications/core-metadata.rst:170 +#: ../source/specifications/core-metadata.rst:208 +#: ../source/specifications/core-metadata.rst:283 +#: ../source/specifications/core-metadata.rst:287 +#: ../source/specifications/core-metadata.rst:291 +#: ../source/specifications/core-metadata.rst:295 +#: ../source/specifications/core-metadata.rst:327 +#: ../source/specifications/core-metadata.rst:347 +#: ../source/specifications/core-metadata.rst:373 +#: ../source/specifications/core-metadata.rst:391 +#: ../source/specifications/core-metadata.rst:416 +#: ../source/specifications/core-metadata.rst:438 +#: ../source/specifications/core-metadata.rst:600 +#: ../source/specifications/core-metadata.rst:620 +#: ../source/specifications/core-metadata.rst:630 +msgid "Example::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:66 +msgid "Name" +msgstr "名称" + +#: ../source/specifications/core-metadata.rst:69 +msgid "Added additional restrictions on format from :pep:`508`" +msgstr "" + +#: ../source/specifications/core-metadata.rst:72 +msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:88 +msgid "Version" +msgstr "版本" + +#: ../source/specifications/core-metadata.rst:92 +msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:101 +msgid "Dynamic (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:105 +msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." +msgstr "" + +#: ../source/specifications/core-metadata.rst:108 +msgid "When found in the metadata of a source distribution, the following rules apply:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:111 +msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." +msgstr "" + +#: ../source/specifications/core-metadata.rst:115 +msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:118 +msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:122 +msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." +msgstr "" + +#: ../source/specifications/core-metadata.rst:127 +msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:131 +msgid "Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:135 +msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." +msgstr "" + +#: ../source/specifications/core-metadata.rst:146 +msgid "Supported-Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:150 +msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." +msgstr "" + +#: ../source/specifications/core-metadata.rst:164 +msgid "Summary" +msgstr "" + +#: ../source/specifications/core-metadata.rst:168 +msgid "A one-line summary of what the distribution does." +msgstr "" + +#: ../source/specifications/core-metadata.rst:188 +msgid "This field may be specified in the message body instead." +msgstr "" + +#: ../source/specifications/core-metadata.rst:191 +msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:196 +msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." +msgstr "" + +#: ../source/specifications/core-metadata.rst:202 +msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:219 +msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." +msgstr "" + +#: ../source/specifications/core-metadata.rst:223 +msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:232 +msgid "Description-Content-Type" +msgstr "" + +#: ../source/specifications/core-metadata.rst:236 +msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:239 +msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." +msgstr "" + +#: ../source/specifications/core-metadata.rst:253 +msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:259 +msgid "Format::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:263 +msgid "The ``type/subtype`` part has only a few legal values:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:265 +msgid "``text/plain``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:266 +msgid "``text/x-rst``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:267 +msgid "``text/markdown``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:269 +msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:273 +msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:278 +msgid "``GFM`` for `Github-flavored Markdown `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:280 +msgid "``CommonMark`` for `CommonMark `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:299 +msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." +msgstr "" + +#: ../source/specifications/core-metadata.rst:303 +msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:307 +msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:311 +msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." +msgstr "" + +#: ../source/specifications/core-metadata.rst:320 +msgid "Keywords" +msgstr "" + +#: ../source/specifications/core-metadata.rst:324 +msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." +msgstr "" + +#: ../source/specifications/core-metadata.rst:333 +msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." +msgstr "" + +#: ../source/specifications/core-metadata.rst:341 +msgid "Home-page" +msgstr "" + +#: ../source/specifications/core-metadata.rst:345 +msgid "A string containing the URL for the distribution's home page." +msgstr "" + +#: ../source/specifications/core-metadata.rst:353 +msgid "Download-URL" +msgstr "" + +#: ../source/specifications/core-metadata.rst:357 +msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:366 +msgid "Author" +msgstr "" + +#: ../source/specifications/core-metadata.rst:370 +msgid "A string containing the author's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:383 +msgid "Author-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:387 +msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:395 +#: ../source/specifications/core-metadata.rst:442 +msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:405 +msgid "Maintainer" +msgstr "维护者" + +#: ../source/specifications/core-metadata.rst:409 +msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:412 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:426 +msgid "Maintainer-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:430 +msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:434 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:452 +msgid "License" +msgstr "" + +#: ../source/specifications/core-metadata.rst:456 +msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." +msgstr "" + +#: ../source/specifications/core-metadata.rst:476 +msgid "Classifier (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:480 +msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:485 +#: ../source/specifications/core-metadata.rst:574 +#: ../source/specifications/core-metadata.rst:691 +#: ../source/specifications/core-metadata.rst:715 +msgid "This field may be followed by an environment marker after a semicolon." +msgstr "" + +#: ../source/specifications/core-metadata.rst:496 +msgid "Requires-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:499 +#: ../source/specifications/core-metadata.rst:561 +#: ../source/specifications/core-metadata.rst:663 +#: ../source/specifications/core-metadata.rst:704 +msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." +msgstr "" + +#: ../source/specifications/core-metadata.rst:503 +msgid "Each entry contains a string naming some other distutils project required by this distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:506 +msgid "The format of a requirement string contains from one to four parts:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:508 +msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." +msgstr "" + +#: ../source/specifications/core-metadata.rst:510 +msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." +msgstr "" + +#: ../source/specifications/core-metadata.rst:513 +msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:516 +msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." +msgstr "" + +#: ../source/specifications/core-metadata.rst:519 +msgid "See :pep:`508` for full details of the allowed format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:521 +msgid "The project names should correspond to names as found on the `Python Package Index`_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:524 +msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:538 +msgid "Requires-Python" +msgstr "" + +#: ../source/specifications/core-metadata.rst:542 +msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." +msgstr "" + +#: ../source/specifications/core-metadata.rst:546 +msgid "The value must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:548 +msgid "This field cannot be followed by an environment marker." +msgstr "" + +#: ../source/specifications/core-metadata.rst:558 +msgid "Requires-External (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:565 +msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:570 +msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:576 +msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." +msgstr "" + +#: ../source/specifications/core-metadata.rst:581 +msgid "Notice that there is no particular rule on the strings to be used." +msgstr "" + +#: ../source/specifications/core-metadata.rst:593 +msgid "Project-URL (multiple-use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:597 +msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." +msgstr "" + +#: ../source/specifications/core-metadata.rst:604 +msgid "The label is free text limited to 32 characters." +msgstr "" + +#: ../source/specifications/core-metadata.rst:612 +msgid "Provides-Extra (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:616 +msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." +msgstr "" + +#: ../source/specifications/core-metadata.rst:625 +msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:635 +msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." +msgstr "" + +#: ../source/specifications/core-metadata.rst:639 +msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:644 +msgid "Rarely Used Fields" +msgstr "" + +#: ../source/specifications/core-metadata.rst:646 +msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:651 +msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." +msgstr "" + +#: ../source/specifications/core-metadata.rst:660 +msgid "Provides-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:667 +msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:672 +msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:679 +msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:687 +msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." +msgstr "" + +#: ../source/specifications/core-metadata.rst:701 +msgid "Obsoletes-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:708 +msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." +msgstr "" + +#: ../source/specifications/core-metadata.rst:712 +msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:717 +msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:730 +msgid "reStructuredText markup: http://docutils.sourceforge.net/" +msgstr "" + +#: ../source/specifications/core-metadata.rst:735 +msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:6 +msgid "Declaring build system dependencies" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:8 +msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:5 +msgid "Declaring project metadata" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:7 +msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:12 +msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:18 +msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:27 +msgid "The only fields required to be statically defined are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:29 +#: ../source/specifications/declaring-project-metadata.rst:41 +msgid "``name``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:31 +msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:34 +#: ../source/specifications/declaring-project-metadata.rst:54 +msgid "``version``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:36 +msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:43 +#: ../source/specifications/declaring-project-metadata.rst:56 +#: ../source/specifications/declaring-project-metadata.rst:68 +#: ../source/specifications/declaring-project-metadata.rst:117 +msgid "TOML_ type: string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:44 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:47 +msgid "The name of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:49 +msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:57 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:60 +msgid "The version of the project as supported by :pep:`440`." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:62 +msgid "Users SHOULD prefer to specify already-normalized versions." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:66 +msgid "``description``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:69 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:72 +msgid "The summary description of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:76 +msgid "``readme``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:78 +msgid "TOML_ type: string or table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:79 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:83 +msgid "The full description of the project (i.e. the README)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:85 +msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:96 +msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:103 +msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:115 +msgid "``requires-python``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:118 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:121 +msgid "The Python version requirements of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:125 +msgid "``license``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:127 +msgid "TOML_ type: table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:128 +msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:131 +msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:140 +msgid "``authors``/``maintainers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:142 +msgid "TOML_ type: Array of inline tables with string keys and values" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:143 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:149 +msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:154 +msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:157 +msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:163 +msgid "Using the data to fill in :ref:`core metadata ` is as follows:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:166 +msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:169 +msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:173 +msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:177 +msgid "Multiple values should be separated by commas." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:181 +msgid "``keywords``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:183 +#: ../source/specifications/declaring-project-metadata.rst:193 +msgid "TOML_ type: array of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:184 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:187 +msgid "The keywords for the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:191 +msgid "``classifiers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:194 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:197 +msgid "Trove classifiers which apply to the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:201 +msgid "``urls``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:203 +msgid "TOML_ type: table with keys and values of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:204 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:207 +msgid "A table of URLs where the key is the URL label and the value is the URL itself." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:212 +msgid "Entry points" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:214 +msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:216 +msgid ":ref:`Entry points specification `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:218 +msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:224 +msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:228 +msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:234 +msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:242 +msgid "``dependencies``/``optional-dependencies``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:244 +msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:247 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:251 +msgid "The (optional) dependencies of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:253 +msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:258 +msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:269 +msgid "``dynamic``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:271 +msgid "TOML_ type: array of string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:272 +msgid "A corresponding :ref:`core metadata ` field does not exist" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:275 +msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:281 +msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:283 +msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:285 +msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:290 +msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:294 +msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:296 +msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:300 +msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:6 +msgid "Dependency specifiers" +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:8 +msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:11 +msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." +msgstr "" + +#: ../source/specifications/direct-url.rst:6 +msgid "Recording the Direct URL Origin of installed distributions" +msgstr "" + +#: ../source/specifications/direct-url.rst:8 +msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." +msgstr "" + +#: ../source/specifications/direct-url.rst:17 +msgid "Specification" +msgstr "" + +#: ../source/specifications/direct-url.rst:19 +msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/direct-url.rst:23 +#: ../source/specifications/recording-installed-packages.rst:206 +msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." +msgstr "" + +#: ../source/specifications/direct-url.rst:26 +msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." +msgstr "" + +#: ../source/specifications/direct-url.rst:29 +msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." +msgstr "" + +#: ../source/specifications/direct-url.rst:36 +msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." +msgstr "" + +#: ../source/specifications/direct-url.rst:39 +msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" +msgstr "" + +#: ../source/specifications/direct-url.rst:45 +msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." +msgstr "" + +#: ../source/specifications/direct-url.rst:49 +msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" +msgstr "" + +#: ../source/specifications/direct-url.rst:52 +msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." +msgstr "" + +#: ../source/specifications/direct-url.rst:58 +msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." +msgstr "" + +#: ../source/specifications/direct-url.rst:61 +msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." +msgstr "" + +#: ../source/specifications/direct-url.rst:68 +msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:71 +msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." +msgstr "" + +#: ../source/specifications/direct-url.rst:78 +msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:81 +msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." +msgstr "" + +#: ../source/specifications/direct-url.rst:84 +msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." +msgstr "" + +#: ../source/specifications/direct-url.rst:91 +msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." +msgstr "" + +#: ../source/specifications/direct-url.rst:96 +msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." +msgstr "" + +#: ../source/specifications/direct-url.rst:102 +msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." +msgstr "" + +#: ../source/specifications/direct-url.rst:110 +msgid "Registered VCS" +msgstr "" + +#: ../source/specifications/direct-url.rst:112 +msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." +msgstr "" + +#: ../source/specifications/direct-url.rst:122 +msgid "Git" +msgstr "" + +#: ../source/specifications/direct-url.rst:124 +#: ../source/specifications/direct-url.rst:156 +#: ../source/specifications/direct-url.rst:179 +#: ../source/specifications/direct-url.rst:202 +msgid "Home page" +msgstr "" + +#: ../source/specifications/direct-url.rst:126 +msgid "https://git-scm.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:128 +#: ../source/specifications/direct-url.rst:160 +#: ../source/specifications/direct-url.rst:183 +#: ../source/specifications/direct-url.rst:206 +msgid "vcs command" +msgstr "" + +#: ../source/specifications/direct-url.rst:130 +#: ../source/specifications/direct-url.rst:134 +msgid "git" +msgstr "" + +#: ../source/specifications/direct-url.rst:132 +#: ../source/specifications/direct-url.rst:164 +#: ../source/specifications/direct-url.rst:187 +#: ../source/specifications/direct-url.rst:210 +msgid "``vcs`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:136 +#: ../source/specifications/direct-url.rst:168 +#: ../source/specifications/direct-url.rst:191 +#: ../source/specifications/direct-url.rst:214 +msgid "``requested_revision`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:138 +msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." +msgstr "" + +#: ../source/specifications/direct-url.rst:141 +#: ../source/specifications/direct-url.rst:172 +#: ../source/specifications/direct-url.rst:195 +#: ../source/specifications/direct-url.rst:219 +msgid "``commit_id`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:143 +msgid "A commit hash (40 hexadecimal characters sha1)." +msgstr "" + +#: ../source/specifications/direct-url.rst:147 +msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." +msgstr "" + +#: ../source/specifications/direct-url.rst:154 +msgid "Mercurial" +msgstr "" + +#: ../source/specifications/direct-url.rst:158 +msgid "https://www.mercurial-scm.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:162 +#: ../source/specifications/direct-url.rst:166 +msgid "hg" +msgstr "" + +#: ../source/specifications/direct-url.rst:170 +msgid "A tag name, branch name, changeset ID, shortened changeset ID." +msgstr "" + +#: ../source/specifications/direct-url.rst:174 +msgid "A changeset ID (40 hexadecimal characters)." +msgstr "" + +#: ../source/specifications/direct-url.rst:177 +msgid "Bazaar" +msgstr "" + +#: ../source/specifications/direct-url.rst:181 +msgid "https://bazaar.canonical.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:185 +#: ../source/specifications/direct-url.rst:189 +msgid "bzr" +msgstr "" + +#: ../source/specifications/direct-url.rst:193 +msgid "A tag name, branch name, revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:197 +msgid "A revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:200 +msgid "Subversion" +msgstr "" + +#: ../source/specifications/direct-url.rst:204 +msgid "https://subversion.apache.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:208 +#: ../source/specifications/direct-url.rst:212 +msgid "svn" +msgstr "" + +#: ../source/specifications/direct-url.rst:216 +msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." +msgstr "" + +#: ../source/specifications/direct-url.rst:221 +msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." +msgstr "" + +#: ../source/specifications/direct-url.rst:229 +msgid "Example direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:231 +msgid "Source archive:" +msgstr "" + +#: ../source/specifications/direct-url.rst:242 +msgid "Git URL with tag and commit-hash:" +msgstr "" + +#: ../source/specifications/direct-url.rst:255 +msgid "Local directory:" +msgstr "" + +#: ../source/specifications/direct-url.rst:264 +msgid "Local directory installed in editable mode:" +msgstr "" + +#: ../source/specifications/direct-url.rst:277 +msgid "Example pip commands and their effect on direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:279 +msgid "Commands that generate a ``direct_url.json``:" +msgstr "" + +#: ../source/specifications/direct-url.rst:281 +msgid "pip install https://example.com/app-1.0.tgz" +msgstr "" + +#: ../source/specifications/direct-url.rst:282 +msgid "pip install https://example.com/app-1.0.whl" +msgstr "" + +#: ../source/specifications/direct-url.rst:283 +msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" +msgstr "" + +#: ../source/specifications/direct-url.rst:284 +msgid "pip install ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:285 +msgid "pip install file:///home/user/app" +msgstr "" + +#: ../source/specifications/direct-url.rst:286 +msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" +msgstr "" + +#: ../source/specifications/direct-url.rst:290 +msgid "pip install -e ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:292 +msgid "Commands that *do not* generate a ``direct_url.json``" +msgstr "" + +#: ../source/specifications/direct-url.rst:294 +msgid "pip install app" +msgstr "" + +#: ../source/specifications/direct-url.rst:295 +msgid "pip install app --no-index --find-links https://example.com/" +msgstr "" + +#: ../source/specifications/entry-points.rst:5 +msgid "Entry points specification" +msgstr "" + +#: ../source/specifications/entry-points.rst:7 +msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" +msgstr "" + +#: ../source/specifications/entry-points.rst:11 +msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." +msgstr "" + +#: ../source/specifications/entry-points.rst:14 +msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." +msgstr "" + +#: ../source/specifications/entry-points.rst:19 +msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." +msgstr "" + +#: ../source/specifications/entry-points.rst:28 +msgid "Data model" +msgstr "" + +#: ../source/specifications/entry-points.rst:30 +msgid "Conceptually, an entry point is defined by three required properties:" +msgstr "" + +#: ../source/specifications/entry-points.rst:32 +msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:42 +msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:51 +msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:64 +msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." +msgstr "" + +#: ../source/specifications/entry-points.rst:68 +msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." +msgstr "" + +#: ../source/specifications/entry-points.rst:73 +msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." +msgstr "" + +#: ../source/specifications/entry-points.rst:80 +msgid "File format" +msgstr "" + +#: ../source/specifications/entry-points.rst:82 +msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." +msgstr "" + +#: ../source/specifications/entry-points.rst:87 +msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:97 +msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:100 +msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." +msgstr "" + +#: ../source/specifications/entry-points.rst:104 +msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." +msgstr "" + +#: ../source/specifications/entry-points.rst:112 +msgid "For example::" +msgstr "" + +#: ../source/specifications/entry-points.rst:124 +msgid "Use for scripts" +msgstr "" + +#: ../source/specifications/entry-points.rst:126 +msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." +msgstr "" + +#: ../source/specifications/entry-points.rst:134 +msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:141 +msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." +msgstr "" + +#: ../source/specifications/entry-points.rst:149 +msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." +msgstr "" + +#: ../source/specifications/entry-points.rst:154 +msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." +msgstr "" + +#: ../source/specifications/index.rst:4 +msgid "PyPA specifications" +msgstr "" + +#: ../source/specifications/index.rst:6 +msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." +msgstr "" + +#: ../source/specifications/index.rst:13 +msgid "Package Distribution Metadata" +msgstr "" + +#: ../source/specifications/index.rst:30 +msgid "Package Distribution File Formats" +msgstr "" + +#: ../source/specifications/index.rst:40 +msgid "Package Index Interfaces" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:6 +msgid "Platform compatibility tags" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:8 +msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:12 +msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:16 +msgid "Platform tags for Windows" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:18 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:22 +msgid "Platform tags for macOS (Mac OS X)" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:24 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:28 +msgid "Platform tags for common Linux distributions" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:32 +msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:36 +msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:41 +msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:44 +msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:46 +msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:49 +msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:54 +msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:59 +msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:65 +msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:71 +msgid "Manylinux compatibility support" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:74 +msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:76 +msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:79 +msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "Tool" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux1``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2010``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2014``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux_x_y``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=8.1.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=20.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "auditwheel" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=1.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=2.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.3.0`` [#]_" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:90 +msgid "Platform tags for other \\*nix platforms" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:92 +msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:98 +msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" +msgstr "" + +#: ../source/specifications/pypirc.rst:6 +msgid "The :file:`.pypirc` file" +msgstr "" + +#: ../source/specifications/pypirc.rst:8 +msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." +msgstr "" + +#: ../source/specifications/pypirc.rst:13 +msgid "The format (originally defined by the :ref:`distutils` package) is:" +msgstr "" + +#: ../source/specifications/pypirc.rst:32 +msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:35 +msgid "Each section describing a repository defines three fields:" +msgstr "" + +#: ../source/specifications/pypirc.rst:37 +msgid "``repository``: The URL of the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:38 +msgid "``username``: The registered username on the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:39 +msgid "``password``: The password that will used to authenticate the username." +msgstr "" + +#: ../source/specifications/pypirc.rst:43 +msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." +msgstr "" + +#: ../source/specifications/pypirc.rst:47 +msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" +msgstr "" + +#: ../source/specifications/pypirc.rst:57 +msgid "Common configurations" +msgstr "" + +#: ../source/specifications/pypirc.rst:61 +msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." +msgstr "" + +#: ../source/specifications/pypirc.rst:66 +msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" +msgstr "" + +#: ../source/specifications/pypirc.rst:82 +msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." +msgstr "" + +#: ../source/specifications/pypirc.rst:86 +msgid "Using a PyPI token" +msgstr "" + +#: ../source/specifications/pypirc.rst:88 +msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" +msgstr "" + +#: ../source/specifications/pypirc.rst:97 +msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." +msgstr "" + +#: ../source/specifications/pypirc.rst:103 +msgid "Using another package index" +msgstr "" + +#: ../source/specifications/pypirc.rst:105 +msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" +msgstr "" + +#: ../source/specifications/pypirc.rst:132 +msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:5 +msgid "Recording installed projects" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:7 +msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:12 +msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:21 +msgid "History and change workflow" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:23 +msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:29 +msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:37 +msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:41 +msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:50 +msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:60 +msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:69 +msgid "This ``.dist-info`` directory can contain these files, described in detail below:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:72 +msgid "``METADATA``: contains project metadata" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:73 +msgid "``RECORD``: records the list of installed files." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:74 +msgid "``INSTALLER``: records the name of the tool used to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:76 +msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:82 +msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:87 +msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:94 +msgid "The METADATA file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:96 +msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:99 +msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:105 +msgid "The RECORD file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:107 +msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:110 +msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:113 +msgid "field delimiter: ``,`` (comma)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:114 +msgid "quoting char: ``\"`` (straight double quote)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:115 +msgid "line terminator: either ``\\r\\n`` or ``\\n``." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:117 +msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:120 +msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:125 +msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:130 +msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:133 +msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:139 +msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:146 +msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:151 +msgid "Here is an example snippet of a possible ``RECORD`` file::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:170 +msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:177 +msgid "The INSTALLER file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:179 +msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:185 +msgid "The file can be terminated by zero or more ASCII whitespace characters." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:187 +msgid "Here are examples of two possible ``INSTALLER`` files::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:195 +msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:201 +msgid "The direct_url.json file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:203 +msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:209 +msgid "Its detailed specification is at :ref:`direct-url`." +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:6 +msgid "Simple repository API" +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:8 +msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:6 +msgid "Source distribution format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:8 +msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:13 +msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:21 +msgid "Source distributions are also known as *sdists* for short." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:24 +msgid "Source distribution file name" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:26 +msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:31 +msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:35 +msgid "Source distribution file format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:37 +msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:45 +msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:48 +msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:6 +msgid "Version specifiers" +msgstr "" + +#: ../source/specifications/version-specifiers.rst:8 +msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:11 +msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." +msgstr "" + +#: ../source/support.rst:3 +msgid "How to Get Support" +msgstr "如何获得支持" + +#: ../source/support.rst:5 +msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." +msgstr "" + +#: ../source/support.rst:8 +msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." +msgstr "" +"如果您想了解更多的情况，或者只是不确定，请在 GitHub 上的 `packaging-problems ` 存储库中 `开一个新的 issue `_ 。" + +#: ../source/tutorials/creating-documentation.rst:5 +msgid "Creating Documentation" +msgstr "创建文档" + +#: ../source/tutorials/creating-documentation.rst:7 +msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:13 +msgid "Installing Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:14 +msgid "Use ``pip`` to install Sphinx:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:28 +msgid "For other installation methods, see this `installation guide`_ by Sphinx." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:33 +msgid "Getting Started With Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:35 +msgid "Create a ``docs`` directory inside your project to hold your documentation:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:42 +msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:49 +msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:51 +msgid "You can add some information about your project in ``index.rst``, then build them:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:57 +msgid "For more details on the build process, see this `guide`_ by Read The Docs." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:62 +msgid "Other Sources" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:64 +msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/index.rst:4 +msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:5 +msgid "Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:7 +msgid "This section covers the basics of how to install Python :term:`packages `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:10 +msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:28 +msgid "Requirements for Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:30 +msgid "This section describes the steps to follow before installing other Python packages." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:35 +msgid "Ensure you can run Python from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:37 +msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:53 +msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:57 +msgid "If you're a newcomer and you get an error like this:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:66 +msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:72 +msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:82 +msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:87 +msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:99 +msgid "Ensure you can run pip from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:101 +msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:116 +msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:124 +msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:139 +msgid "If that still doesn't allow you to run ``python -m pip``:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:141 +msgid "Securely Download `get-pip.py `_ [1]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:144 +msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:150 +msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:159 +msgid "Ensure pip, setuptools, and wheel are up to date" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:161 +msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:169 +msgid "Optionally, create a virtual environment" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:171 +msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:188 +msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:195 +msgid "Creating Virtual Environments" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:197 +msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:203 +msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:209 +msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:213 +msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:216 +msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:220 +msgid "Currently, there are two common tools for creating Python virtual environments:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:222 +msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:225 +msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:230 +msgid "The basic usage is like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:232 +msgid "Using `venv`_:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:248 +msgid "Using :ref:`virtualenv`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:264 +msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:266 +msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:271 +msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:281 +msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:288 +msgid "Use pip for Installing" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:290 +msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:297 +msgid "Installing from PyPI" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:299 +msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:307 +msgid "To install the latest version of \"SomeProject\":" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:321 +msgid "To install a specific version:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:335 +msgid "To install greater than or equal to one version and less than another:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:350 +msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:365 +msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:370 +msgid "Source Distributions vs Wheels" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:372 +msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:378 +msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:383 +msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:391 +msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:408 +msgid "Installing to the User Site" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:410 +msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:425 +msgid "For more information see the `User Installs `_ section from the pip docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:429 +msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:432 +msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:440 +msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:446 +msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:462 +msgid "Install a list of requirements specified in a :ref:`Requirements File `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:478 +msgid "Installing from VCS" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:480 +msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:502 +msgid "Installing from other Indexes" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:504 +msgid "Install from an alternate index" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:518 +msgid "Search an additional index during install, in addition to :term:`PyPI `" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:534 +msgid "Installing from a local src tree" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:537 +msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:554 +msgid "You can also install normally from src" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:571 +msgid "Install a particular source archive file." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:585 +msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:605 +msgid "Installing from other sources" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:607 +msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:619 +msgid "Installing Prereleases" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:621 +msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:637 +msgid "Installing Setuptools \"Extras\"" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:639 +msgid "Install `setuptools extras`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:659 +msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:668 +msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:673 +msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:4 +msgid "Managing Application Dependencies" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:6 +msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:9 +msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:13 +msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:17 +msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:24 +msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:30 +msgid "Installing Pipenv" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:32 +msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:38 +msgid "Use ``pip`` to install Pipenv:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:54 +msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:65 +msgid "Installing packages for your project" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:67 +msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:76 +msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:112 +msgid "Using installed packages" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:114 +msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:125 +msgid "Then you can run this script using ``pipenv run``:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:131 +msgid "You should get output similar to this:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:137 +msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:143 +#: ../source/tutorials/packaging-projects.rst:594 +msgid "Next steps" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:145 +msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:148 +msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:151 +msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:160 +msgid "Other Tools for Application Dependency Management" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:162 +msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:166 +msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:172 +msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:175 +msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:177 +msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:2 +msgid "Packaging Python Projects" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:4 +msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:10 +msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:18 +msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:35 +msgid "A simple project" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:37 +msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:41 +msgid "Create the following file structure locally:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:51 +msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:54 +msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:63 +msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:67 +msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:75 +msgid "Creating the package files" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:77 +msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:95 +msgid "Creating a test directory" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:97 +msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:101 +msgid "Creating pyproject.toml" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:103 +msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:117 +msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:121 +msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:127 +msgid "See :pep:`517` and :pep:`518` for background and details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:131 +msgid "Configuring metadata" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:133 +msgid "There are two types of metadata: static and dynamic." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:135 +msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:137 +msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:141 +msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:148 +msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:153 +msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:185 +msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:191 +#: ../source/tutorials/packaging-projects.rst:286 +msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:196 +msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:199 +#: ../source/tutorials/packaging-projects.rst:293 +msgid "``author`` and ``author_email`` are used to identify the author of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:201 +#: ../source/tutorials/packaging-projects.rst:295 +msgid "``description`` is a short, one-sentence summary of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:202 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:206 +#: ../source/tutorials/packaging-projects.rst:300 +msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:208 +#: ../source/tutorials/packaging-projects.rst:302 +msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:211 +#: ../source/tutorials/packaging-projects.rst:305 +msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:213 +#: ../source/tutorials/packaging-projects.rst:307 +msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:221 +msgid "In the ``options`` category, we have controls for setuptools itself:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:223 +msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:227 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:234 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:238 +#: ../source/tutorials/packaging-projects.rst:329 +msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:244 +msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:248 +msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:283 +msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:291 +msgid "``version`` is the package version. See :pep:`440` for more details on versions." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:296 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:314 +msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:319 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:325 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:333 +msgid "Creating README.md" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:335 +msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:347 +msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:354 +msgid "Creating a LICENSE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:356 +msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:387 +msgid "Including other files" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:389 +msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:393 +msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:402 +msgid "Generating distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:404 +msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:408 +msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:422 +msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:425 +msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:439 +msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:449 +msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:458 +msgid "Uploading the distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:460 +msgid "Finally, it's time to upload your package to the Python Package Index!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:462 +msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:470 +msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:477 +msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:492 +msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:506 +msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:510 +msgid "After the command completes, you should see output similar to this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:523 +msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:528 +msgid "Installing your newly uploaded package" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:530 +msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:546 +msgid "Make sure to specify your username in the package name!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:548 +msgid "pip should install the package from TestPyPI and the output should look something like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:558 +msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:565 +msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:580 +msgid "and import the package:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:588 +msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:596 +msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:599 +msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:604 +msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:608 +msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:610 +msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:613 +msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:617 +msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:619 +msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:622 +msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:624 +msgid "Read about :doc:`/guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:625 +msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." +msgstr "" diff --git a/locales/zh_Hant/LC_MESSAGES/messages.po b/locales/zh_Hant/LC_MESSAGES/messages.po new file mode 100644 index 000000000..13b3b6ab0 --- /dev/null +++ b/locales/zh_Hant/LC_MESSAGES/messages.po @@ -0,0 +1,9260 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2013–2020, PyPA +# This file is distributed under the same license as the Python Packaging User Guide package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: Python Packaging User Guide\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-07-06 19:32+0800\n" +"PO-Revision-Date: 2021-07-14 16:45+0000\n" +"Last-Translator: meowmeowmeowcat \n" +"Language-Team: Chinese (Traditional) \n" +"Language: zh_Hant\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=1; plural=0;\n" +"X-Generator: Weblate 4.7.2-dev\n" + +#: ../source/contribute.rst:5 +msgid "Contribute to this guide" +msgstr "為本指南做出貢獻" + +#: ../source/contribute.rst:7 +msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" +msgstr "|PyPUG| 歡迎貢獻者！有很多方法可以提供幫助，包括：" + +#: ../source/contribute.rst:10 +msgid "Reading the guide and giving feedback" +msgstr "閱讀本指南並提供反饋" + +#: ../source/contribute.rst:11 +msgid "Reviewing new contributions" +msgstr "審查新的貢獻" + +#: ../source/contribute.rst:12 +msgid "Revising existing content" +msgstr "修改現有內容" + +#: ../source/contribute.rst:13 +msgid "Writing new content" +msgstr "編寫新內容" + +#: ../source/contribute.rst:15 +msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." +msgstr "" + +#: ../source/contribute.rst:24 +msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." +msgstr "如果你打算為 |PyPUG| 作出貢獻，你就應該遵守 PSF 的 `行為守則`__。" + +#: ../source/contribute.rst:31 +msgid "Documentation types" +msgstr "文件類型" + +#: ../source/contribute.rst:33 +msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." +msgstr "" + +#: ../source/contribute.rst:38 +#: ../source/tutorials/index.rst:2 +msgid "Tutorials" +msgstr "教學" + +#: ../source/contribute.rst:40 +msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." +msgstr "" + +#: ../source/contribute.rst:47 +#: ../source/guides/index.rst:2 +msgid "Guides" +msgstr "指南" + +#: ../source/contribute.rst:49 +msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." +msgstr "" + +#: ../source/contribute.rst:56 +#: ../source/discussions/index.rst:2 +msgid "Discussions" +msgstr "討論" + +#: ../source/contribute.rst:58 +msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." +msgstr "" + +#: ../source/contribute.rst:63 +msgid "Specifications" +msgstr "規格" + +#: ../source/contribute.rst:65 +msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." +msgstr "" + +#: ../source/contribute.rst:73 +msgid "Building the guide locally" +msgstr "在本地構建指南" + +#: ../source/contribute.rst:75 +msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" +msgstr "" + +#: ../source/contribute.rst:79 +msgid "`Nox `_. You can install or upgrade nox using ``pip``::" +msgstr "" +"`Nox `_。您可以使用 ``pip`` 來安裝或升級 nox::" + +#: ../source/contribute.rst:84 +msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." +msgstr "" +"Python 3.6。我們的構建腳本只為 Python 3.6 而設計。請參閱 `Hitchhiker's Guide to Python " +"installation instructions`_ 以在您的操作系統上安裝Python 3.6。" + +#: ../source/contribute.rst:91 +msgid "To build the guide, run the following bash command in the source folder::" +msgstr "要構建指南，請在 source 資料夾中運行以下 bash 命令::" + +#: ../source/contribute.rst:95 +msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." +msgstr "" + +#: ../source/contribute.rst:100 +msgid "You can build the guide and serve it via an HTTP server using the following command::" +msgstr "" + +#: ../source/contribute.rst:105 +msgid "The guide will be browsable via http://localhost:8000." +msgstr "該指南將可通過 http://localhost:8000 進行瀏覽。" + +#: ../source/contribute.rst:109 +msgid "Where the guide is deployed" +msgstr "" + +#: ../source/contribute.rst:111 +msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." +msgstr "" + +#: ../source/contribute.rst:117 +msgid "Style guide" +msgstr "風格指南" + +#: ../source/contribute.rst:119 +msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." +msgstr "" + +#: ../source/contribute.rst:126 +msgid "Purpose" +msgstr "目的" + +#: ../source/contribute.rst:128 +msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." +msgstr "" + +#: ../source/contribute.rst:133 +msgid "Scope" +msgstr "範圍" + +#: ../source/contribute.rst:135 +msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." +msgstr "該指南旨在通過準確和有針對性的建議回答問題和解決問題。" + +#: ../source/contribute.rst:138 +msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." +msgstr "" + +#: ../source/contribute.rst:146 +msgid "Audience" +msgstr "觀眾" + +#: ../source/contribute.rst:148 +msgid "The audience of this guide is anyone who uses Python with packages." +msgstr "" + +#: ../source/contribute.rst:150 +msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." +msgstr "" + +#: ../source/contribute.rst:154 +msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." +msgstr "" + +#: ../source/contribute.rst:160 +msgid "Voice and tone" +msgstr "" + +#: ../source/contribute.rst:162 +msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." +msgstr "" + +#: ../source/contribute.rst:165 +msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." +msgstr "" + +#: ../source/contribute.rst:170 +msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." +msgstr "" + +#: ../source/contribute.rst:177 +msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." +msgstr "" + +#: ../source/contribute.rst:184 +msgid "Conventions and mechanics" +msgstr "" + +#: ../source/contribute.rst:192 +msgid "**Write to the reader**" +msgstr "" + +#: ../source/contribute.rst:187 +msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: To install it, the user runs…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: You can install it by running…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: To install it, run…" +msgstr "" + +#: ../source/contribute.rst:198 +msgid "**State assumptions**" +msgstr "" + +#: ../source/contribute.rst:195 +msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." +msgstr "" + +#: ../source/contribute.rst:203 +msgid "**Cross-reference generously**" +msgstr "" + +#: ../source/contribute.rst:201 +msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." +msgstr "" + +#: ../source/contribute.rst:213 +msgid "**Respect naming practices**" +msgstr "" + +#: ../source/contribute.rst:206 +msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: Pip uses…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: pip uses…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: …hosted on github." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: …hosted on GitHub." +msgstr "" + +#: ../source/contribute.rst:222 +msgid "**Use a gender-neutral style**" +msgstr "" + +#: ../source/contribute.rst:216 +msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: A maintainer uploads the file. Then he…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then they…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then the maintainer…" +msgstr "" + +#: ../source/contribute.rst:234 +msgid "**Headings**" +msgstr "" + +#: ../source/contribute.rst:225 +msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." +msgstr "" + +#: ../source/contribute.rst:230 +msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: Things You Should Know About Python" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: Things you should know about Python" +msgstr "" + +#: ../source/contribute.rst:237 +msgid "**Numbers**" +msgstr "" + +#: ../source/contribute.rst:237 +msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:4 +msgid "Deploying Python applications" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Page Status" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:6 +#: ../source/guides/index-mirrors-and-caches.rst:7 +#: ../source/guides/installing-using-linux-tools.rst:7 +#: ../source/guides/packaging-binary-extensions.rst:7 +#: ../source/guides/supporting-multiple-python-versions.rst:7 +#: ../source/guides/supporting-windows-using-appveyor.rst:5 +msgid "Incomplete" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Last Reviewed" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:7 +msgid "2014-11-11" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:11 +#: ../source/discussions/install-requires-vs-requirements.rst:9 +#: ../source/guides/analyzing-pypi-package-downloads.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:22 +#: ../source/guides/index-mirrors-and-caches.rst:12 +#: ../source/guides/installing-scientific-packages.rst:9 +#: ../source/guides/packaging-binary-extensions.rst:17 +#: ../source/guides/supporting-multiple-python-versions.rst:12 +#: ../source/guides/supporting-windows-using-appveyor.rst:15 +#: ../source/overview.rst:23 +#: ../source/specifications/core-metadata.rst:38 +#: ../source/specifications/direct-url.rst:14 +#: ../source/tutorials/installing-packages.rst:23 +msgid "Contents" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:14 +msgid "Overview" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:18 +msgid "Supporting multiple hardware platforms" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:40 +msgid "OS packaging & installers" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:52 +msgid "Windows" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:61 +msgid "Pynsist" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:63 +msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:70 +msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:74 +msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:80 +msgid "Application bundles" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:91 +msgid "Configuration management" +msgstr "" + +#: ../source/discussions/index.rst:4 +msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:5 +msgid "install_requires vs requirements files" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:382 +msgid "install_requires" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:14 +msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:19 +msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:29 +msgid "Additionally, it's best practice to indicate any known lower or upper bounds." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:31 +msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:41 +msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:51 +msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:56 +msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:64 +#: ../source/tutorials/installing-packages.rst:460 +msgid "Requirements files" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:66 +msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:69 +msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:73 +msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:78 +msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:84 +msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:90 +msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:6 +msgid "pip vs easy_install" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:9 +msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:14 +msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:22 +msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**pip**" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**easy_install**" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +msgid "Installs from :term:`Wheels `" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Yes" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:30 +#: ../source/discussions/pip-vs-easy-install.rst:32 +#: ../source/discussions/pip-vs-easy-install.rst:35 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:51 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "No" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Uninstall Packages" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Yes (``python -m pip uninstall``)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Dependency Overrides" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Yes (:ref:`Requirements Files `)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "List Installed Packages" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:38 +msgid ":pep:`438` Support" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Installation format" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "'Flat' packages with :file:`egg-info` metadata." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Encapsulated Egg format" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:44 +msgid "sys.path modification" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:48 +msgid "Installs from :term:`Eggs `" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "`pylauncher support`_" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "Yes [1]_" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:54 +msgid ":ref:`Multi-version Installs`" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Exclude scripts during install" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "per project index" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Only in virtualenv" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Yes, via setup.cfg" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:68 +msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:5 +msgid "Wheel vs Egg" +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:7 +msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:11 +msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:14 +msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:17 +msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:20 +msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:22 +msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:26 +msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:31 +msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:34 +msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:38 +msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:41 +msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:47 +msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." +msgstr "" + +#: ../source/glossary.rst:3 +msgid "Glossary" +msgstr "" + +#: ../source/glossary.rst:8 +msgid "Binary Distribution" +msgstr "" + +#: ../source/glossary.rst:11 +msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." +msgstr "" + +#: ../source/glossary.rst:14 +msgid "Built Distribution" +msgstr "" + +#: ../source/glossary.rst:17 +msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." +msgstr "" + +#: ../source/glossary.rst:26 +msgid "Distribution Package" +msgstr "" + +#: ../source/glossary.rst:29 +msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." +msgstr "" + +#: ../source/glossary.rst:34 +msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." +msgstr "" + +#: ../source/glossary.rst:41 +msgid "Egg" +msgstr "" + +#: ../source/glossary.rst:44 +msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" +msgstr "" + +#: ../source/glossary.rst:49 +msgid "Extension Module" +msgstr "" + +#: ../source/glossary.rst:52 +msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." +msgstr "" + +#: ../source/glossary.rst:59 +msgid "Known Good Set (KGS)" +msgstr "" + +#: ../source/glossary.rst:62 +msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." +msgstr "" + +#: ../source/glossary.rst:68 +msgid "Import Package" +msgstr "" + +#: ../source/glossary.rst:71 +msgid "A Python module which can contain other modules or recursively, other packages." +msgstr "" + +#: ../source/glossary.rst:74 +msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." +msgstr "" + +#: ../source/glossary.rst:78 +msgid "Module" +msgstr "" + +#: ../source/glossary.rst:81 +msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." +msgstr "" + +#: ../source/glossary.rst:84 +msgid "Package Index" +msgstr "" + +#: ../source/glossary.rst:87 +msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." +msgstr "" + +#: ../source/glossary.rst:90 +msgid "Per Project Index" +msgstr "" + +#: ../source/glossary.rst:93 +msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." +msgstr "" + +#: ../source/glossary.rst:97 +msgid "Project" +msgstr "" + +#: ../source/glossary.rst:100 +msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." +msgstr "" + +#: ../source/glossary.rst:104 +msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." +msgstr "" + +#: ../source/glossary.rst:110 +msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." +msgstr "" + +#: ../source/glossary.rst:115 +msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." +msgstr "" + +#: ../source/glossary.rst:121 +msgid "Pure Module" +msgstr "" + +#: ../source/glossary.rst:124 +msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." +msgstr "" + +#: ../source/glossary.rst:127 +msgid "Python Packaging Authority (PyPA)" +msgstr "" + +#: ../source/glossary.rst:130 +msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." +msgstr "" + +#: ../source/glossary.rst:139 +msgid "Python Package Index (PyPI)" +msgstr "" + +#: ../source/glossary.rst:142 +msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." +msgstr "" + +#: ../source/glossary.rst:145 +msgid "pypi.org" +msgstr "" + +#: ../source/glossary.rst:148 +msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." +msgstr "" + +#: ../source/glossary.rst:152 +msgid "pyproject.toml" +msgstr "" + +#: ../source/glossary.rst:155 +msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." +msgstr "" + +#: ../source/glossary.rst:157 +msgid "Release" +msgstr "" + +#: ../source/glossary.rst:160 +msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." +msgstr "" + +#: ../source/glossary.rst:163 +msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." +msgstr "" + +#: ../source/glossary.rst:168 +msgid "Requirement" +msgstr "" + +#: ../source/glossary.rst:171 +msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." +msgstr "" + +#: ../source/glossary.rst:177 +msgid "Requirement Specifier" +msgstr "" + +#: ../source/glossary.rst:180 +msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" +msgstr "" + +#: ../source/glossary.rst:187 +msgid "Requirements File" +msgstr "" + +#: ../source/glossary.rst:190 +msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." +msgstr "" + +#: ../source/glossary.rst:194 +#: ../source/guides/distributing-packages-using-setuptools.rst:56 +msgid "setup.py" +msgstr "" + +#: ../source/glossary.rst:195 +#: ../source/guides/distributing-packages-using-setuptools.rst:77 +msgid "setup.cfg" +msgstr "" + +#: ../source/glossary.rst:198 +msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." +msgstr "" + +#: ../source/glossary.rst:201 +msgid "Source Archive" +msgstr "" + +#: ../source/glossary.rst:204 +msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:208 +msgid "Source Distribution (or \"sdist\")" +msgstr "" + +#: ../source/glossary.rst:211 +msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:216 +msgid "System Package" +msgstr "" + +#: ../source/glossary.rst:219 +msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." +msgstr "" + +#: ../source/glossary.rst:222 +msgid "Version Specifier" +msgstr "" + +#: ../source/glossary.rst:225 +msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." +msgstr "" + +#: ../source/glossary.rst:231 +msgid "Virtual Environment" +msgstr "" + +#: ../source/glossary.rst:234 +msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/glossary.rst:238 +msgid "Wheel" +msgstr "" + +#: ../source/glossary.rst:241 +msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." +msgstr "" + +#: ../source/glossary.rst:244 +msgid "Working Set" +msgstr "" + +#: ../source/glossary.rst:247 +msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:3 +msgid "Analyzing PyPI package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:5 +msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:15 +#: ../source/guides/supporting-windows-using-appveyor.rst:18 +msgid "Background" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:17 +msgid "PyPI does not display download statistics for a number of reasons: [#]_" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:19 +msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:24 +msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:27 +msgid "``pip``'s download cache (lowers download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:28 +msgid "Internal or unofficial mirrors (can both raise or lower download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:29 +msgid "Packages not hosted on PyPI (for comparisons sake)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:30 +msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:32 +msgid "Known historical data quality issues (lowers download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:34 +msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:38 +msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:43 +msgid "Public dataset" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:45 +msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:50 +msgid "Getting set up" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:52 +msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:58 +msgid "Navigate to the `BigQuery web UI`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:59 +msgid "Create a new project." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:60 +msgid "Enable the `BigQuery API `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:63 +msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:69 +msgid "Data schema" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:71 +msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +msgid "Column" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/guides/using-manifest-in.rst:67 +#: ../source/specifications/core-metadata.rst:185 +msgid "Description" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/specifications/direct-url.rst:226 +msgid "Examples" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "timestamp" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "Date and time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "``2020-03-09 00:33:03 UTC``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "file.project" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "Project name" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "``pipenv``, ``nose``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "file.version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "Package version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "``0.1.6``, ``1.4.2``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "details.installer.name" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "Installer" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "pip, `bandersnatch`_" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "details.python" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "Python version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "``2.7.12``, ``3.6.4``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:93 +msgid "Useful queries" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:95 +msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:97 +msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:102 +msgid "Counting package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:104 +msgid "The following query counts the total number of downloads for the project \"pytest\"." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:119 +#: ../source/guides/analyzing-pypi-package-downloads.rst:140 +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "num_downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:121 +msgid "26190085" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:124 +msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:142 +msgid "24334215" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:146 +msgid "Package downloads over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:148 +msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +msgid "month" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "1956741" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "2018-01-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2344692" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2017-12-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "1730398" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "2017-11-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2047310" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2017-10-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "1744443" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "2017-09-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "1916952" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "2017-08-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:184 +msgid "Python versions over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:186 +msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "python" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "3.7" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "18051328726" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "3.6" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "9635067203" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "3.8" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "7781904681" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "2.7" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "6381252241" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "null" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "2026630299" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "3.5" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "1894153540" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:221 +msgid "Caveats" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:223 +msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:231 +msgid "Additional tools" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:233 +msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:237 +msgid "``google-cloud-bigquery``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:239 +msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:267 +msgid "``pypinfo``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:269 +msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:273 +msgid "Install `pypinfo`_ using pip." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:279 +msgid "Usage:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:295 +msgid "``pandas-gbq``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:297 +msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:301 +#: ../source/specifications/binary-distribution-format.rst:459 +msgid "References" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:303 +msgid "`PyPI Download Counts deprecation email `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:304 +msgid "`PyPI BigQuery dataset announcement email `__" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:3 +msgid "Creating and discovering plugins" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:5 +msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:10 +msgid "There are three major approaches to doing automatic plugin discovery:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:12 +msgid "`Using naming convention`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:13 +msgid "`Using namespace packages`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:14 +msgid "`Using package metadata`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:18 +msgid "Using naming convention" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:20 +msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:38 +msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:48 +msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:59 +msgid "Using namespace packages" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:61 +msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:89 +msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:101 +msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:115 +msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:121 +msgid "Using package metadata" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:123 +msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:128 +msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:139 +msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:154 +msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:163 +msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:166 +msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:170 +msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:5 +msgid "Packaging and distributing projects" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:7 +msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:11 +msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:15 +msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:25 +msgid "Requirements for packaging and distributing" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:26 +msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:29 +msgid "Install \"twine\" [1]_:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:43 +msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:49 +msgid "Configuring your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:53 +msgid "Initial files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:58 +msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:63 +msgid ":file:`setup.py` serves two primary functions:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:65 +msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:71 +msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:79 +msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:86 +msgid "README.rst / README.md" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:88 +msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:95 +msgid "For an example, see `README.md `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:99 +msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:108 +msgid "MANIFEST.in" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:110 +msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:115 +msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:119 +msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:122 +msgid "LICENSE.txt" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:124 +msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:130 +msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:135 +msgid "" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:137 +msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:141 +msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:149 +msgid "setup() args" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:151 +msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:155 +msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:164 +msgid "name" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:170 +msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:174 +msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:176 +msgid "Start & end with an ASCII letter or digit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:178 +msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:190 +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "version" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:196 +msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:200 +msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:203 +msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:206 +msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:214 +msgid "description" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:222 +msgid "Give a short and long description for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:224 +msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:229 +msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:235 +msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:245 +msgid "url" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:252 +msgid "Give a homepage URL for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:256 +msgid "author" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:263 +msgid "Provide details about the author." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:267 +msgid "license" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:273 +msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:279 +msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:287 +msgid "classifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:316 +msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:319 +msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:327 +msgid "keywords" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:333 +msgid "List keywords that describe your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:337 +msgid "project_urls" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:349 +msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:355 +msgid "packages" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:361 +msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:370 +msgid "py_modules" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:376 +msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:388 +msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:392 +msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:398 +msgid "python_requires" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:400 +msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:407 +msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:412 +msgid "And so on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:416 +msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:422 +msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:431 +msgid "package_data" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:440 +msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:445 +msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:449 +msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:457 +msgid "data_files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:463 +msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:469 +msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:479 +msgid "For more information see the distutils section on `Installing Additional Files `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:484 +msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:491 +msgid "scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:493 +msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:500 +msgid "entry_points" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:509 +msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:512 +msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:516 +msgid "The most commonly used entry point is \"console_scripts\" (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:521 +msgid "console_scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:531 +msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:538 +msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:545 +msgid "Choosing a versioning scheme" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:548 +msgid "Standards compliance for interoperability" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:550 +msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:556 +msgid "Here are some examples of compliant version numbers::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:567 +msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:573 +msgid "Scheme choices" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:576 +msgid "Semantic versioning (preferred)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:578 +msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:582 +msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:585 +msgid "MAJOR version when they make incompatible API changes," +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:586 +msgid "MINOR version when they add functionality in a backwards-compatible manner, and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:587 +msgid "MAINTENANCE version when they make backwards-compatible bug fixes." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:589 +msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:594 +msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:598 +msgid "Date based versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:600 +msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:604 +msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:607 +msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:611 +msgid "Serial versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:613 +msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:616 +msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:621 +msgid "Hybrid schemes" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:623 +msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:629 +msgid "Pre-release versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:631 +msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:634 +msgid "zero or more dev releases (denoted with a \".devN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:635 +msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:636 +msgid "zero or more beta releases (denoted with a \".bN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:637 +msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:639 +msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:644 +msgid "Local version identifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:646 +msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:653 +msgid "A local version identifier takes the form ``+``. For example::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:661 +msgid "Working in \"development mode\"" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:663 +msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:667 +msgid "Assuming you're in the root of your project directory, then run:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:674 +msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:680 +msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:688 +msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:692 +msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:697 +msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:701 +msgid "Lastly, if you don't want to install any dependencies at all, you can run::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:706 +msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:713 +msgid "Packaging your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:715 +msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:720 +msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:737 +msgid "Source distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:739 +msgid "Minimally, you should create a :term:`Source Distribution `:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:755 +msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:763 +msgid "Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:765 +msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:770 +msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:773 +msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:776 +msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:785 +msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:792 +msgid "Pure Python Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:794 +msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:797 +#: ../source/guides/distributing-packages-using-setuptools.rst:826 +msgid "To build the wheel:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:811 +msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:815 +msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:821 +msgid "Platform Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:823 +msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:841 +msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:847 +msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:855 +msgid "Uploading your Project to PyPI" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:857 +msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:861 +msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:866 +msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:871 +msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:877 +msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:888 +msgid "Create an account" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:890 +msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:894 +msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:897 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:901 +msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:904 +msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:913 +msgid "**Be aware that this stores your token in plaintext.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:915 +#: ../source/guides/migrating-to-pypi-org.rst:70 +#: ../source/guides/migrating-to-pypi-org.rst:109 +#: ../source/guides/using-testpypi.rst:83 +msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:921 +msgid "Upload your distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:923 +msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:926 +msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:930 +msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:937 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:944 +#: ../source/tutorials/installing-packages.rst:663 +msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:950 +msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:5 +msgid "Dropping support for older Python versions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:7 +msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:9 +msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:12 +msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:14 +msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:17 +msgid "Requirements" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:19 +msgid "This workflow requires that:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:21 +msgid "The publisher is using the latest version of :ref:`setuptools`," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:22 +msgid "The latest version of :ref:`twine` is used to upload the package," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:23 +msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:26 +msgid "Dealing with the universal wheels" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:28 +msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:36 +msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:48 +msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:53 +msgid "Defining the Python version required" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:56 +msgid "1. Download the newest version of Setuptools" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:58 +msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:60 +msgid "Steps:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:74 +msgid "`setuptools` version should be above 24.0.0." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:77 +msgid "2. Specify the version ranges for supported Python distributions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:79 +msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:81 +#: ../source/specifications/core-metadata.rst:139 +#: ../source/specifications/core-metadata.rst:463 +#: ../source/specifications/core-metadata.rst:487 +#: ../source/specifications/core-metadata.rst:527 +#: ../source/specifications/core-metadata.rst:550 +#: ../source/specifications/core-metadata.rst:583 +#: ../source/specifications/core-metadata.rst:693 +#: ../source/specifications/core-metadata.rst:722 +msgid "Examples::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:86 +msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:101 +msgid "3. Validating the Metadata before publishing" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:103 +msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:105 +msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:108 +msgid "You can see the contents of the generated file like this::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:112 +msgid "Validate that the following is in place, before publishing the package:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:114 +msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:115 +msgid "The Requires-Python field is set and matches your specification in setup.py." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:118 +msgid "4. Using Twine to publish" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:120 +msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:122 +msgid "Make sure you are using the newest version of Twine, at least 1.9." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:125 +msgid "Dropping a Python release" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:127 +msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:129 +msgid "It must be done in this order for the automated fallback to work." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:131 +msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:133 +msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:5 +msgid "Hosting your own simple repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:8 +msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:13 +msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:29 +msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:35 +msgid "\"Manual\" repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:37 +msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:51 +msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:58 +msgid "For complete documentation of the simple repository protocol, see :pep:`503`." +msgstr "" + +#: ../source/guides/index.rst:8 +#: ../source/guides/index.rst:8 +msgid "Installing Packages:" +msgstr "" + +#: ../source/guides/index.rst:20 +#: ../source/guides/index.rst:20 +msgid "Building and Publishing Projects:" +msgstr "" + +#: ../source/guides/index.rst:38 +#: ../source/guides/index.rst:38 +msgid "Miscellaneous:" +msgstr "" + +#: ../source/guides/index.rst:4 +msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:5 +msgid "Package index mirrors and caches" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:8 +#: ../source/guides/supporting-multiple-python-versions.rst:8 +msgid "2014-12-24" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:14 +msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:17 +msgid "Three options are available in this area:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:19 +msgid "pip provides local caching options," +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:20 +msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:22 +msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:27 +msgid "Caching with pip" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:29 +msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:32 +msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:36 +msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:45 +msgid "Caching with devpi" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:47 +msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:55 +msgid "Complete mirror with bandersnatch" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:57 +msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:63 +msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:5 +msgid "Installing scientific packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:11 +msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:16 +msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:22 +msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:29 +msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:35 +msgid "Building from source" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:37 +msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:45 +msgid "Linux distribution packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:47 +msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:51 +msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:57 +msgid "Windows installers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:59 +msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:64 +msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:67 +msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:73 +msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:79 +msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:86 +msgid "macOS installers and package managers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:88 +msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:92 +msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:99 +msgid "SciPy distributions" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:101 +msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:105 +msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:109 +#: ../source/key_projects.rst:596 +msgid "Spack" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:110 +msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:119 +msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:128 +msgid "The conda cross-platform package manager" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:130 +msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:136 +msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 +msgid "Installing stand alone command line tools" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 +msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 +msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 +msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 +msgid "pipx only works with Python 3.6+." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 +msgid "``pipx`` is installed with ``pip``:" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 +msgid "You may need to restart your terminal for the path updates to take effect." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 +msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 +#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 +msgid "For example" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 +msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 +msgid "To upgrade or uninstall the package" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 +msgid "``pipx`` can be upgraded or uninstalled with pip" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 +msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 +msgid "To see the full list of commands ``pipx`` offers, run" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 +msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:5 +msgid "Installing pip/setuptools/wheel with Linux Package Managers" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:8 +msgid "2015-09-17" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:11 +msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:14 +msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:18 +msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:25 +msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:32 +msgid "Fedora" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:34 +msgid "Fedora 21:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:36 +#: ../source/guides/installing-using-linux-tools.rst:45 +#: ../source/guides/installing-using-linux-tools.rst:124 +#: ../source/guides/installing-using-linux-tools.rst:138 +#: ../source/guides/installing-using-linux-tools.rst:158 +msgid "Python 2::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:41 +msgid "Python 3: ``sudo yum install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:43 +msgid "Fedora 22:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:50 +msgid "Python 3: ``sudo dnf install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:53 +msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:63 +msgid "CentOS/RHEL" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:65 +msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:68 +msgid "To install pip and wheel for the system Python, there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:70 +msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:77 +msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:81 +msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:85 +msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:92 +msgid "To additionally upgrade setuptools, run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:97 +msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:101 +msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:104 +msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:106 +msgid "For CentOS, see here: https://www.softwarecollections.org/en/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:108 +msgid "Be aware that collections may not contain the most recent versions." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:110 +msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:116 +msgid "For example, for Python 3.4 on CentOS7/RHEL7::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:122 +msgid "openSUSE" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:129 +#: ../source/guides/installing-using-linux-tools.rst:143 +#: ../source/guides/installing-using-linux-tools.rst:162 +msgid "Python 3::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:135 +msgid "Debian/Ubuntu" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:150 +msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:156 +msgid "Arch Linux" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:168 +msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 +msgid "Installing packages using pip and virtual environments" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 +msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 +msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 +msgid "Installing pip" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 +msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 +msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 +msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 +msgid "Afterwards, you should have the newest pip installed in your user site:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 +msgid "The Python installers for Windows include pip. You should be able to access pip using:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 +msgid "You can make sure that pip is up-to-date by running:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 +msgid "Installing virtualenv" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 +msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 +msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 +msgid "Creating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 +msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 +msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 +msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 +msgid "venv will create a virtual Python installation in the ``env`` folder." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 +msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 +msgid "Activating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 +msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 +msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 +msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 +msgid "Leaving the virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 +msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 +msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 +msgid "Installing packages" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 +msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 +msgid "pip should download requests and all of its dependencies and install them:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 +msgid "Installing specific versions" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 +msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 +msgid "To install the latest ``2.x`` release of requests:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 +msgid "To install pre-release versions of packages, use the ``--pre`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 +msgid "Installing extras" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 +msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 +msgid "Installing from source" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 +msgid "pip can install a package directly from source, for example:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 +msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 +msgid "Installing from version control systems" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 +msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 +msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 +#: ../source/tutorials/installing-packages.rst:569 +msgid "Installing from local archives" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 +msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 +msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 +msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 +msgid "Using other package indexes" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 +msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 +msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 +#: ../source/tutorials/installing-packages.rst:389 +msgid "Upgrading packages" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 +msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 +msgid "Using requirements files" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 +msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 +msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 +msgid "Freezing dependencies" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 +msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 +msgid "Which will output a list of package specifiers such as:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 +msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:2 +msgid "Making a PyPI-friendly README" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:4 +msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:9 +msgid "Creating a README file" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:11 +msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:13 +msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:16 +msgid "plain text" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:17 +msgid "`reStructuredText `_ (without Sphinx extensions)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:18 +msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:21 +msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:25 +msgid "Including your README in your package's metadata" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:27 +msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:33 +msgid ":ref:`description-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:34 +msgid ":ref:`description-content-type-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:36 +msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:39 +msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:45 +msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:60 +msgid "The minimum required versions of the respective tools are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:62 +msgid "``setuptools >= 38.6.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:63 +msgid "``wheel >= 0.31.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:64 +msgid "``twine >= 1.11.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:66 +msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:72 +msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:95 +msgid "Validating reStructuredText markup" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:97 +msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:100 +msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:105 +msgid "You can check your README for markup errors before uploading as follows:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:107 +msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:122 +msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:125 +msgid "Run ``twine check`` on the sdist and wheel::" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:129 +msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:4 +msgid "Migrating to PyPI.org" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:6 +msgid ":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``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:12 +msgid "Publishing releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:14 +msgid "``pypi.org`` is the default upload platform as of September 2016." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:16 +msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:22 +msgid "The default upload settings switched to ``pypi.org`` in the following versions:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:24 +msgid "``twine`` 1.8.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:25 +msgid "``setuptools`` 27.0.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:26 +msgid "Python 2.7.13 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:27 +msgid "Python 3.4.6 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:28 +msgid "Python 3.5.3 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:29 +msgid "Python 3.6.0 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:31 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:48 +msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:51 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:67 +msgid "(``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.)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:73 +msgid "Registering package names & metadata" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:75 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:79 +msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:84 +msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:89 +#: ../source/guides/using-testpypi.rst:5 +msgid "Using TestPyPI" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:91 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:113 +msgid "Registering new user accounts" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:115 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:121 +msgid "Browsing packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:123 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:130 +msgid "Downloading packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:132 +msgid "``pypi.org`` is the default host for downloading packages." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:135 +msgid "Managing published packages and releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:137 +msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:5 +msgid "Multi-version installs" +msgstr "" + +#: ../source/guides/multi-version-installs.rst:8 +msgid "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``)." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:13 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:31 +msgid "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 ``python -c ''`` to invoke the application's main entry point directly." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:38 +msgid "Refer to the `pkg_resources documentation `__ for more details." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:5 +msgid "Packaging binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:8 +msgid "2013-12-08" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:10 +msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:20 +msgid "An overview of binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:23 +msgid "Use cases" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:25 +msgid "The typical use cases for binary extensions break down into just three conventional categories:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:28 +msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:39 +msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:47 +msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:56 +msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:61 +msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:71 +msgid "Disadvantages" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:73 +msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:80 +msgid "This means that binary extensions:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:82 +msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:85 +msgid "may not be compatible with different builds of the CPython reference interpreter" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:88 +msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:91 +msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:96 +msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:101 +msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:108 +msgid "Alternatives to handcoded accelerator modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:110 +msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:115 +msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:122 +msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:132 +msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:141 +msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:150 +msgid "Alternatives to handcoded wrapper modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:152 +msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:158 +msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:162 +msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:168 +msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:175 +msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:181 +msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:185 +msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:189 +msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:203 +msgid "Alternatives for low level system access" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:205 +msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:213 +msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:222 +msgid "Implementing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:224 +msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:241 +msgid "Building binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:244 +msgid "Building extensions for multiple platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:246 +msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:256 +msgid "Binary extensions for Windows" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:258 +msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:263 +msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:269 +msgid "To set up a build environment for binary extensions, the steps are as follows:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:271 +msgid "For Python 2.7" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:273 +msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:276 +msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:278 +#: ../source/guides/packaging-binary-extensions.rst:288 +#: ../source/guides/packaging-binary-extensions.rst:295 +msgid "Done." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:280 +msgid "For Python 3.4" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:282 +msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:285 +msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:287 +msgid "Set DISTUTILS_USE_SDK=1" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:290 +msgid "For Python 3.5" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:292 +msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:297 +msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:301 +msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:305 +msgid "Binary extensions for Linux" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:307 +msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:313 +msgid "Binary extensions for macOS" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:315 +msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:325 +msgid "Publishing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:327 +msgid "For interim guidance on this topic, see the discussion in `this issue `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:343 +msgid "Additional resources" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:345 +msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:352 +msgid "Cross-platform wheel generation with scikit-build" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:354 +msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:362 +msgid "Introduction to C/C++ extension modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:364 +msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:367 +msgid "`What are (c)python extension modules? `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:368 +msgid "`Releasing the gil `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:369 +msgid "`Writing cpython extension modules using C++ `_" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:3 +msgid "Packaging namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:5 +msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:24 +msgid "And you use this package in your code like so::" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:29 +msgid "Then you can break these sub-packages into two separate distributions:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:46 +msgid "Each sub-package can now be separately installed, used, and versioned." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:48 +msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:58 +msgid "Creating a namespace package" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:60 +msgid "There are currently three different approaches to creating namespace packages:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:62 +msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:66 +msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:69 +msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:73 +msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:80 +msgid "Native namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:82 +msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:97 +msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:102 +msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:117 +msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:123 +msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:129 +msgid "pkgutil-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:131 +msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:136 +msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:148 +#: ../source/guides/packaging-namespace-packages.rst:194 +msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:155 +#: ../source/guides/packaging-namespace-packages.rst:201 +msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:160 +msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:171 +msgid "pkg_resources-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:173 +msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:182 +msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:206 +msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:216 +msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:223 +msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:237 +msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 +msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 +msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 +msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 +msgid "Saving credentials on GitHub" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 +msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 +msgid "Let's begin! 🚀" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 +msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 +msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 +msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 +msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 +msgid "Creating a workflow definition" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 +msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 +msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 +msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 +msgid "Defining a workflow job environment" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 +msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 +msgid "Checking out the project and building distributions" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 +msgid "Then, add the following under the ``build-n-publish`` section:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 +msgid "This will download your repository into the CI runner and then install and activate Python 3.7." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 +msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 +msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 +msgid "So add this to the steps list:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 +msgid "Publishing the distribution to PyPI and TestPyPI" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 +msgid "Finally, add the following steps at the end:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 +msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 +msgid "That's all, folks!" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 +msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:5 +msgid "Single-sourcing the package version" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:8 +msgid "There are many techniques to maintain a single source of truth for the version number of your project:" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:11 +msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:38 +msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:47 +msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:52 +msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:55 +msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:58 +msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:65 +msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:76 +msgid "Example using this technique: `warehouse `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:78 +msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:86 +msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:91 +msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:95 +msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:110 +msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:114 +msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:128 +msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:134 +msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:138 +msgid "Example using this technique: `setuptools `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:141 +msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:155 +msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:161 +msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:5 +msgid "Supporting multiple Python versions" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:37 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:43 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:49 +msgid "Automated testing and continuous integration" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:51 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:60 +msgid "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:" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:66 +msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:69 +msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:80 +msgid "Both `Travis CI`_ 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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:85 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:89 +msgid "Tools for single-source Python packages" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:91 +msgid "`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_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:100 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:107 +msgid "a Python 2 (by syntax) module in a Python 3 project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:108 +msgid "a Python 3 (by syntax) module in a *Python 2* project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:110 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:117 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:124 +msgid "What's in which Python?" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:126 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:3 +msgid "Supporting Windows using Appveyor" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:6 +msgid "2015-12-03" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:8 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:20 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:24 +msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:30 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:38 +msgid "Setting up" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:40 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:45 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:49 +msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:54 +msgid "Adding Appveyor support to your project" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:61 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:69 +msgid "appveyor.yml" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:75 +msgid "This file can be downloaded from `here `__." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:77 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:80 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:88 +msgid "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``)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:94 +msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:97 +msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:100 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:109 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:114 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:119 +msgid "Support script" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:121 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:126 +msgid "`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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:133 +msgid "You can simply download the batch file and include it in your project unchanged." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:137 +msgid "Access to the built wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:139 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:147 +msgid "Additional notes" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:150 +msgid "Testing with tox" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:152 +msgid "Many projects use the `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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:156 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:160 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:165 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:170 +msgid "``DISTUTILS_USE_SDK``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:171 +msgid "``MSSdk``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:172 +msgid "``INCLUDE``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:173 +msgid "``LIB``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:175 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:181 +msgid "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 Travis or 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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:188 +msgid "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``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:192 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:197 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:203 +msgid "Automatically uploading wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:205 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:210 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:216 +msgid "External dependencies" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:218 +msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:221 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:230 +msgid "Support scripts" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:232 +msgid "For reference, the SDK setup support script is listed here:" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:234 +msgid "``appveyor-sample/build.cmd``" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:5 +msgid "Tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:7 +msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:12 +msgid "Application dependency management" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:14 +msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:18 +msgid "When ``pipenv`` does not meet your use case, consider other tools like:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:20 +msgid ":ref:`pip`" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:22 +msgid "`pip-tools `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:24 +msgid "`Poetry `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:27 +msgid "Installation tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:29 +msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:34 +msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:37 +msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:40 +msgid ":ref:`buildout`: primarily focused on the web development community" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:42 +msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:47 +msgid "Packaging tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:49 +msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:52 +msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:56 +msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:61 +msgid "Publishing platform migration" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:63 +msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:67 +msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:72 +msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:77 +msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:82 +msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:88 +msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:93 +msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:102 +msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:107 +msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:5 +msgid "Including files in source distributions with ``MANIFEST.in``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:7 +msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:17 +msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:22 +msgid "How files are included in an sdist" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:24 +msgid "The following files are included in a source distribution by default:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:26 +msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:28 +msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:30 +msgid "scripts specified by the ``scripts`` ``setup()`` argument" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:31 +msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:33 +msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:35 +msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:37 +msgid "all files matching the pattern :file:`test/test*.py`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:38 +msgid ":file:`setup.py` (or whatever you called your setup script)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:39 +msgid ":file:`setup.cfg`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:40 +msgid ":file:`README`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:41 +msgid ":file:`README.txt`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:42 +msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:43 +msgid ":file:`README.md` (setuptools 36.4.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:44 +msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:45 +msgid ":file:`MANIFEST.in`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:47 +msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:52 +msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:60 +msgid ":file:`MANIFEST.in` commands" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:62 +msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:67 +msgid "Command" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid ":samp:`include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid "Add all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid ":samp:`exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid "Remove all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid ":samp:`global-include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid "Add all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid ":samp:`global-exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid "Remove all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid ":samp:`graft {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid "Add all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid ":samp:`prune {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid "Remove all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:79 +msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:87 +msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:91 +msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:95 +msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:101 +msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." +msgstr "" + +#: ../source/guides/using-testpypi.rst:7 +msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" +msgstr "" + +#: ../source/guides/using-testpypi.rst:13 +msgid "Registering your account" +msgstr "" + +#: ../source/guides/using-testpypi.rst:15 +msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." +msgstr "" + +#: ../source/guides/using-testpypi.rst:19 +msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." +msgstr "" + +#: ../source/guides/using-testpypi.rst:24 +msgid "Using TestPyPI with Twine" +msgstr "" + +#: ../source/guides/using-testpypi.rst:26 +msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:33 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/using-testpypi.rst:39 +msgid "Using TestPyPI with pip" +msgstr "" + +#: ../source/guides/using-testpypi.rst:41 +msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:56 +msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" +msgstr "" + +#: ../source/guides/using-testpypi.rst:73 +msgid "Setting up TestPyPI in :file:`.pypirc`" +msgstr "" + +#: ../source/guides/using-testpypi.rst:75 +msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" +msgstr "" + +#: ../source/index.rst:3 +#: ../source/key_projects.rst:181 +msgid "Python Packaging User Guide" +msgstr "" + +#: ../source/index.rst:5 +msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." +msgstr "" + +#: ../source/index.rst:5 +msgid "python, packaging, guide, tutorial" +msgstr "" + +#: ../source/index.rst:24 +msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." +msgstr "" + +#: ../source/index.rst:28 +msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" +msgstr "" + +#: ../source/index.rst:36 +msgid "Get started" +msgstr "" + +#: ../source/index.rst:38 +msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" +msgstr "" + +#: ../source/index.rst:41 +msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" +msgstr "" + +#: ../source/index.rst:43 +msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" +msgstr "" + +#: ../source/index.rst:45 +msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" +msgstr "" + +#: ../source/index.rst:47 +msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" +msgstr "" + +#: ../source/index.rst:52 +msgid "Learn more" +msgstr "" + +#: ../source/index.rst:54 +msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" +msgstr "" + +#: ../source/index.rst:56 +msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/index.rst:58 +msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." +msgstr "" + +#: ../source/index.rst:60 +msgid "The :doc:`specifications/index` section for packaging interoperability specifications." +msgstr "" + +#: ../source/index.rst:62 +msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." +msgstr "" + +#: ../source/key_projects.rst:6 +msgid "Project Summaries" +msgstr "" + +#: ../source/key_projects.rst:8 +msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." +msgstr "" + +#: ../source/key_projects.rst:14 +msgid "PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:19 +msgid "bandersnatch" +msgstr "" + +#: ../source/key_projects.rst:21 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:25 +msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." +msgstr "" + +#: ../source/key_projects.rst:35 +msgid "build" +msgstr "" + +#: ../source/key_projects.rst:37 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:42 +msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." +msgstr "" + +#: ../source/key_projects.rst:49 +msgid "cibuildwheel" +msgstr "" + +#: ../source/key_projects.rst:51 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" +msgstr "" + +#: ../source/key_projects.rst:58 +msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." +msgstr "" + +#: ../source/key_projects.rst:64 +msgid "distlib" +msgstr "" + +#: ../source/key_projects.rst:66 +msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:71 +msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." +msgstr "" + +#: ../source/key_projects.rst:80 +msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." +msgstr "" + +#: ../source/key_projects.rst:90 +msgid "packaging" +msgstr "" + +#: ../source/key_projects.rst:92 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:97 +msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." +msgstr "" + +#: ../source/key_projects.rst:99 +msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." +msgstr "" + +#: ../source/key_projects.rst:107 +msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." +msgstr "" + +#: ../source/key_projects.rst:119 +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "pip" +msgstr "" + +#: ../source/key_projects.rst:121 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:126 +msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." +msgstr "" + +#: ../source/key_projects.rst:129 +msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." +msgstr "" + +#: ../source/key_projects.rst:137 +msgid "Pipenv" +msgstr "" + +#: ../source/key_projects.rst:139 +msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:144 +msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." +msgstr "" + +#: ../source/key_projects.rst:148 +msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." +msgstr "" + +#: ../source/key_projects.rst:159 +msgid "Pipfile" +msgstr "" + +#: ../source/key_projects.rst:161 +msgid "`Source `__" +msgstr "" + +#: ../source/key_projects.rst:163 +msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." +msgstr "" + +#: ../source/key_projects.rst:170 +msgid "pipx" +msgstr "" + +#: ../source/key_projects.rst:172 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:176 +msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." +msgstr "" + +#: ../source/key_projects.rst:183 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:187 +msgid "This guide!" +msgstr "" + +#: ../source/key_projects.rst:192 +msgid "readme_renderer" +msgstr "" + +#: ../source/key_projects.rst:194 +msgid "`GitHub and docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:197 +msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." +msgstr "" + +#: ../source/key_projects.rst:208 +msgid "setuptools" +msgstr "" + +#: ../source/key_projects.rst:210 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:215 +msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." +msgstr "" + +#: ../source/key_projects.rst:220 +msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." +msgstr "" + +#: ../source/key_projects.rst:227 +msgid "trove-classifiers" +msgstr "" + +#: ../source/key_projects.rst:229 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:233 +msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." +msgstr "" + +#: ../source/key_projects.rst:239 +msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." +msgstr "" + +#: ../source/key_projects.rst:253 +msgid "twine" +msgstr "" + +#: ../source/key_projects.rst:255 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:260 +msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." +msgstr "" + +#: ../source/key_projects.rst:270 +#: ../source/overview.rst:415 +msgid "virtualenv" +msgstr "" + +#: ../source/key_projects.rst:272 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:277 +msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/key_projects.rst:290 +msgid "Warehouse" +msgstr "" + +#: ../source/key_projects.rst:292 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:296 +msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." +msgstr "" + +#: ../source/key_projects.rst:304 +msgid "wheel" +msgstr "" + +#: ../source/key_projects.rst:306 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:311 +msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." +msgstr "" + +#: ../source/key_projects.rst:315 +msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." +msgstr "" + +#: ../source/key_projects.rst:324 +msgid "Non-PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:329 +msgid "bento" +msgstr "" + +#: ../source/key_projects.rst:331 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:336 +msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." +msgstr "" + +#: ../source/key_projects.rst:344 +msgid "buildout" +msgstr "" + +#: ../source/key_projects.rst:346 +msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:351 +msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." +msgstr "" + +#: ../source/key_projects.rst:358 +msgid "conda" +msgstr "" + +#: ../source/key_projects.rst:360 +msgid "`Docs `__" +msgstr "" + +#: ../source/key_projects.rst:362 +msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." +msgstr "" + +#: ../source/key_projects.rst:369 +msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." +msgstr "" + +#: ../source/key_projects.rst:373 +msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." +msgstr "" + +#: ../source/key_projects.rst:386 +msgid "devpi" +msgstr "" + +#: ../source/key_projects.rst:388 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:392 +msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." +msgstr "" + +#: ../source/key_projects.rst:401 +msgid "flit" +msgstr "" + +#: ../source/key_projects.rst:403 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:407 +msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." +msgstr "" + +#: ../source/key_projects.rst:412 +msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." +msgstr "" + +#: ../source/key_projects.rst:422 +msgid "enscons" +msgstr "" + +#: ../source/key_projects.rst:424 +msgid "`Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:428 +msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." +msgstr "" + +#: ../source/key_projects.rst:443 +msgid "Hashdist" +msgstr "" + +#: ../source/key_projects.rst:445 +msgid "`Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:448 +msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." +msgstr "" + +#: ../source/key_projects.rst:460 +msgid "hatch" +msgstr "" + +#: ../source/key_projects.rst:462 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:465 +msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." +msgstr "" + +#: ../source/key_projects.rst:475 +msgid "multibuild" +msgstr "" + +#: ../source/key_projects.rst:477 +msgid "`GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:479 +msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." +msgstr "" + +#: ../source/key_projects.rst:485 +msgid "pex" +msgstr "" + +#: ../source/key_projects.rst:487 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:491 +msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." +msgstr "" + +#: ../source/key_projects.rst:500 +msgid "pip-tools" +msgstr "" + +#: ../source/key_projects.rst:502 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:505 +msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." +msgstr "" + +#: ../source/key_projects.rst:517 +msgid "piwheels" +msgstr "" + +#: ../source/key_projects.rst:519 +msgid "`Website `__ | `Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:523 +msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." +msgstr "" + +#: ../source/key_projects.rst:532 +msgid "poetry" +msgstr "" + +#: ../source/key_projects.rst:534 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:538 +msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." +msgstr "" + +#: ../source/key_projects.rst:548 +msgid "pypiserver" +msgstr "" + +#: ../source/key_projects.rst:550 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:554 +msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." +msgstr "" + +#: ../source/key_projects.rst:564 +msgid "scikit-build" +msgstr "" + +#: ../source/key_projects.rst:566 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:570 +msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." +msgstr "" + +#: ../source/key_projects.rst:582 +msgid "shiv" +msgstr "" + +#: ../source/key_projects.rst:584 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:588 +msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." +msgstr "" + +#: ../source/key_projects.rst:598 +msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" +msgstr "" + +#: ../source/key_projects.rst:603 +msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." +msgstr "" + +#: ../source/key_projects.rst:611 +msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." +msgstr "" + +#: ../source/key_projects.rst:617 +msgid "zest.releaser" +msgstr "" + +#: ../source/key_projects.rst:619 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:623 +msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." +msgstr "" + +#: ../source/key_projects.rst:630 +msgid "Standard Library Projects" +msgstr "" + +#: ../source/key_projects.rst:635 +msgid "ensurepip" +msgstr "" + +#: ../source/key_projects.rst:637 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:640 +msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." +msgstr "" + +#: ../source/key_projects.rst:649 +msgid "distutils" +msgstr "" + +#: ../source/key_projects.rst:651 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:654 +msgid "The original Python packaging system, added to the standard library in Python 2.0." +msgstr "" + +#: ../source/key_projects.rst:657 +msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." +msgstr "" + +#: ../source/key_projects.rst:670 +msgid "venv" +msgstr "" + +#: ../source/key_projects.rst:672 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:675 +msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/news.rst:2 +msgid "News" +msgstr "" + +#: ../source/news.rst:5 +msgid "September 2019" +msgstr "" + +#: ../source/news.rst:6 +msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" +msgstr "" + +#: ../source/news.rst:9 +msgid "August 2019" +msgstr "" + +#: ../source/news.rst:10 +msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" +msgstr "" + +#: ../source/news.rst:13 +msgid "July 2019" +msgstr "" + +#: ../source/news.rst:14 +msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" +msgstr "" + +#: ../source/news.rst:15 +msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" +msgstr "" + +#: ../source/news.rst:16 +msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" +msgstr "" + +#: ../source/news.rst:17 +msgid "Updated directory layout examples for consistency. (:pr:`611`)" +msgstr "" + +#: ../source/news.rst:18 +msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" +msgstr "" + +#: ../source/news.rst:21 +msgid "June 2019" +msgstr "" + +#: ../source/news.rst:22 +msgid "Fixed some typos. (:pr:`620`)" +msgstr "" + +#: ../source/news.rst:25 +msgid "May 2019" +msgstr "" + +#: ../source/news.rst:26 +msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" +msgstr "" + +#: ../source/news.rst:27 +msgid "Added a MANIFEST.in guide page. (:pr:`609`)" +msgstr "" + +#: ../source/news.rst:30 +msgid "April 2019" +msgstr "" + +#: ../source/news.rst:31 +msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" +msgstr "" + +#: ../source/news.rst:32 +msgid "Reduced emphasis on virtualenv. (:pr:`606`)" +msgstr "" + +#: ../source/news.rst:35 +msgid "March 2019" +msgstr "" + +#: ../source/news.rst:36 +msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" +msgstr "" + +#: ../source/news.rst:37 +msgid "Covered RTD details for contributing. (:pr:`600`)" +msgstr "" + +#: ../source/news.rst:40 +msgid "February 2019" +msgstr "" + +#: ../source/news.rst:41 +msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" +msgstr "" + +#: ../source/news.rst:42 +msgid "Added instructions to install Python CLI applications. (:pr:`594`)" +msgstr "" + +#: ../source/news.rst:45 +msgid "January 2019" +msgstr "" + +#: ../source/news.rst:46 +msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" +msgstr "" + +#: ../source/news.rst:47 +msgid "Updated Sphinx and Nox. (:pr:`591`)" +msgstr "" + +#: ../source/news.rst:48 +msgid "Referenced Twine from Python3. (:pr:`581`)" +msgstr "" + +#: ../source/news.rst:51 +msgid "December 2018" +msgstr "" + +#: ../source/news.rst:52 +msgid "No programmers in the office!" +msgstr "" + +#: ../source/news.rst:55 +msgid "November 2018" +msgstr "" + +#: ../source/news.rst:56 +msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" +msgstr "" + +#: ../source/news.rst:57 +msgid "Changed bumpversion to bump2version. (:pr:`572`)" +msgstr "" + +#: ../source/news.rst:58 +msgid "Added single-sourcing package version example. (:pr:`573`)" +msgstr "" + +#: ../source/news.rst:59 +msgid "Added a guide for creating documentation. (:pr:`568`)" +msgstr "" + +#: ../source/news.rst:62 +msgid "October 2018" +msgstr "" + +#: ../source/news.rst:63 +msgid "Updated Nox package name. (:pr:`566`)" +msgstr "" + +#: ../source/news.rst:64 +msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" +msgstr "" + +#: ../source/news.rst:67 +msgid "September 2018" +msgstr "" + +#: ../source/news.rst:68 +msgid "Added a section on checking RST markup. (:pr:`554`)" +msgstr "" + +#: ../source/news.rst:69 +msgid "Updated user installs page. (:pr:`558`)" +msgstr "" + +#: ../source/news.rst:70 +msgid "Updated Google BigQuery urls. (:pr:`556`)" +msgstr "" + +#: ../source/news.rst:71 +msgid "Replaced tar command with working command. (:pr:`552`)" +msgstr "" + +#: ../source/news.rst:72 +msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" +msgstr "" + +#: ../source/news.rst:75 +msgid "August 2018" +msgstr "" + +#: ../source/news.rst:76 +msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" +msgstr "" + +#: ../source/news.rst:77 +msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" +msgstr "" + +#: ../source/news.rst:78 +msgid "Updated Python version supported by virtualenv. (:pr:`538`)" +msgstr "" + +#: ../source/news.rst:79 +msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" +msgstr "" + +#: ../source/news.rst:82 +msgid "July 2018" +msgstr "" + +#: ../source/news.rst:84 +msgid "Improved binary extension docs. (:pr:`531`)" +msgstr "" + +#: ../source/news.rst:85 +msgid "Added scikit-build to key projects. (:pr:`530`)" +msgstr "" + +#: ../source/news.rst:88 +msgid "June 2018" +msgstr "" + +#: ../source/news.rst:90 +msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" +msgstr "" + +#: ../source/news.rst:91 +msgid "Updated Markdown descriptions explanation. (:pr:`522`)" +msgstr "" + +#: ../source/news.rst:94 +msgid "May 2018" +msgstr "" + +#: ../source/news.rst:96 +msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" +msgstr "" + +#: ../source/news.rst:97 +msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" +msgstr "" + +#: ../source/news.rst:98 +msgid "Simplified packaging tutorial. (:pr:`498`)" +msgstr "" + +#: ../source/news.rst:99 +msgid "Updated Windows users instructions for clarity. (:pr:`493`)" +msgstr "" + +#: ../source/news.rst:100 +msgid "Updated the license section description for completeness. (:pr:`492`)" +msgstr "" + +#: ../source/news.rst:101 +msgid "Added specification-style document to contributing section. (:pr:`489`)" +msgstr "" + +#: ../source/news.rst:102 +msgid "Added documentation types to contributing guide. (:pr:`485`)" +msgstr "" + +#: ../source/news.rst:105 +msgid "April 2018" +msgstr "" + +#: ../source/news.rst:107 +msgid "Added README guide. (:pr:`461`)" +msgstr "" + +#: ../source/news.rst:108 +msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" +msgstr "" + +#: ../source/news.rst:109 +msgid "Added instructions for Warehouse. (:pr:`471`)" +msgstr "" + +#: ../source/news.rst:110 +msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" +msgstr "" + +#: ../source/news.rst:111 +msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" +msgstr "" + +#: ../source/news.rst:112 +msgid "Added a guide for phasing out Python versions. (:pr:`459`)" +msgstr "" + +#: ../source/news.rst:113 +msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" +msgstr "" + +#: ../source/news.rst:116 +msgid "March 2018" +msgstr "" + +#: ../source/news.rst:118 +msgid "Updated \"installing scientific packages\". (:pr:`455`)" +msgstr "" + +#: ../source/news.rst:119 +msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" +msgstr "" + +#: ../source/news.rst:120 +msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" +msgstr "" + +#: ../source/news.rst:121 +msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" +msgstr "" + +#: ../source/news.rst:124 +msgid "February 2018" +msgstr "" + +#: ../source/news.rst:126 +msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" +msgstr "" + +#: ../source/news.rst:127 +msgid "Updated PyPI migration info. (:pr:`439`)" +msgstr "" + +#: ../source/news.rst:128 +msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" +msgstr "" + +#: ../source/news.rst:129 +msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" +msgstr "" + +#: ../source/news.rst:130 +msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" +msgstr "" + +#: ../source/news.rst:133 +msgid "January 2018" +msgstr "" + +#: ../source/news.rst:135 +msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" +msgstr "" + +#: ../source/news.rst:136 +msgid "Updated README.rst explanation. (:pr:`419`)" +msgstr "" + +#: ../source/news.rst:139 +msgid "December 2017" +msgstr "" + +#: ../source/news.rst:141 +msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" +msgstr "" + +#: ../source/news.rst:142 +msgid "Noted which fields can be used with environment markers. (:pr:`416`)" +msgstr "" + +#: ../source/news.rst:143 +msgid "Updated Requires-Python section. (:pr:`414`)" +msgstr "" + +#: ../source/news.rst:144 +msgid "Added news page. (:pr:`404`)" +msgstr "" + +#: ../source/news.rst:147 +msgid "November 2017" +msgstr "" + +#: ../source/news.rst:149 +msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" +msgstr "" + +#: ../source/news.rst:150 +msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" +msgstr "" + +#: ../source/news.rst:152 +msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:153 +msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" +msgstr "" + +#: ../source/news.rst:156 +msgid "October 2017" +msgstr "" + +#: ../source/news.rst:158 +msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:159 +msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" +msgstr "" + +#: ../source/news.rst:160 +msgid "Split the specifications page into multiple pages. (:pr:`386`)" +msgstr "" + +#: ../source/news.rst:163 +msgid "September 2017" +msgstr "" + +#: ../source/news.rst:165 +msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" +msgstr "" + +#: ../source/news.rst:167 +msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" +msgstr "" + +#: ../source/news.rst:170 +msgid "August 2017" +msgstr "" + +#: ../source/news.rst:172 +msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" +msgstr "" + +#: ../source/news.rst:173 +msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" +msgstr "" + +#: ../source/news.rst:174 +msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" +msgstr "" + +#: ../source/news.rst:177 +msgid "July 2017" +msgstr "" + +#: ../source/news.rst:179 +msgid "Added ``flit`` to the key projects list. (:pr:`358`)" +msgstr "" + +#: ../source/news.rst:180 +msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" +msgstr "" + +#: ../source/news.rst:181 +msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" +msgstr "" + +#: ../source/news.rst:182 +msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" +msgstr "" + +#: ../source/news.rst:183 +msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" +msgstr "" + +#: ../source/news.rst:186 +msgid "June 2017" +msgstr "" + +#: ../source/news.rst:188 +msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" +msgstr "" + +#: ../source/news.rst:189 +msgid "Added documentation for ``python_requires``. (:pr:`338`)" +msgstr "" + +#: ../source/news.rst:190 +msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" +msgstr "" + +#: ../source/news.rst:191 +msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" +msgstr "" + +#: ../source/news.rst:192 +msgid "Added a license section to the distributing guide. (:pr:`331`)" +msgstr "" + +#: ../source/news.rst:193 +msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" +msgstr "" + +#: ../source/news.rst:194 +msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" +msgstr "" + +#: ../source/news.rst:195 +msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" +msgstr "" + +#: ../source/news.rst:196 +msgid "Switched to the PyPA theme. (:pr:`305`)" +msgstr "" + +#: ../source/news.rst:197 +msgid "Re-organized the documentation into the new structure. (:pr:`318`)" +msgstr "" + +#: ../source/news.rst:200 +msgid "May 2017" +msgstr "" + +#: ../source/news.rst:202 +msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" +msgstr "" + +#: ../source/news.rst:203 +msgid "Added contributor and style guide. (:pr:`307`)" +msgstr "" + +#: ../source/news.rst:204 +msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" +msgstr "" + +#: ../source/news.rst:207 +msgid "April 2017" +msgstr "" + +#: ../source/news.rst:209 +msgid "Added travis configuration for testing pull requests. (:pr:`300`)" +msgstr "" + +#: ../source/news.rst:210 +msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" +msgstr "" + +#: ../source/news.rst:211 +msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" +msgstr "" + +#: ../source/news.rst:212 +msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" +msgstr "" + +#: ../source/news.rst:213 +msgid "Added a topic on namespace packages. (:pr:`290`)" +msgstr "" + +#: ../source/news.rst:214 +msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" +msgstr "" + +#: ../source/news.rst:215 +msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" +msgstr "" + +#: ../source/news.rst:216 +msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" +msgstr "" + +#: ../source/news.rst:217 +msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" +msgstr "" + +#: ../source/news.rst:219 +msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" +msgstr "" + +#: ../source/news.rst:223 +msgid "March 2017" +msgstr "" + +#: ../source/news.rst:225 +msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" +msgstr "" + +#: ../source/news.rst:228 +msgid "February 2017" +msgstr "" + +#: ../source/news.rst:230 +msgid "Added :pep:`518`. (:pr:`281`)" +msgstr "" + +#: ../source/overview.rst:3 +msgid "An Overview of Packaging for Python" +msgstr "" + +#: ../source/overview.rst:7 +msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." +msgstr "" + +#: ../source/overview.rst:12 +msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." +msgstr "" + +#: ../source/overview.rst:18 +msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." +msgstr "" + +#: ../source/overview.rst:26 +msgid "Thinking about deployment" +msgstr "" + +#: ../source/overview.rst:28 +msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" +msgstr "" + +#: ../source/overview.rst:32 +msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" +msgstr "" + +#: ../source/overview.rst:35 +msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" +msgstr "" + +#: ../source/overview.rst:37 +msgid "Is your software installed individually, or in large deployment batches?" +msgstr "" + +#: ../source/overview.rst:39 +msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." +msgstr "" + +#: ../source/overview.rst:46 +msgid "Packaging Python libraries and tools" +msgstr "" + +#: ../source/overview.rst:48 +msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/overview.rst:53 +msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." +msgstr "" + +#: ../source/overview.rst:59 +msgid "Python modules" +msgstr "" + +#: ../source/overview.rst:61 +msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." +msgstr "" + +#: ../source/overview.rst:66 +msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." +msgstr "" + +#: ../source/overview.rst:73 +msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." +msgstr "" + +#: ../source/overview.rst:78 +msgid "Python source distributions" +msgstr "" + +#: ../source/overview.rst:80 +msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." +msgstr "" + +#: ../source/overview.rst:84 +msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." +msgstr "" + +#: ../source/overview.rst:90 +msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." +msgstr "" + +#: ../source/overview.rst:95 +msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." +msgstr "" + +#: ../source/overview.rst:100 +msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." +msgstr "" + +#: ../source/overview.rst:107 +msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" +msgstr "" + +#: ../source/overview.rst:114 +msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." +msgstr "" + +#: ../source/overview.rst:119 +msgid "Python binary distributions" +msgstr "" + +#: ../source/overview.rst:121 +msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." +msgstr "" + +#: ../source/overview.rst:125 +msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." +msgstr "" + +#: ../source/overview.rst:132 +msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." +msgstr "" + +#: ../source/overview.rst:140 +msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." +msgstr "" + +#: ../source/overview.rst:148 +msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." +msgstr "" + +#: ../source/overview.rst:155 +msgid "Packaging Python applications" +msgstr "" + +#: ../source/overview.rst:157 +msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." +msgstr "" + +#: ../source/overview.rst:162 +msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." +msgstr "" + +#: ../source/overview.rst:166 +msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." +msgstr "" + +#: ../source/overview.rst:172 +msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." +msgstr "" + +#: ../source/overview.rst:176 +msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." +msgstr "" + +#: ../source/overview.rst:181 +msgid "Depending on a framework" +msgstr "" + +#: ../source/overview.rst:183 +msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." +msgstr "" + +#: ../source/overview.rst:189 +msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." +msgstr "" + +#: ../source/overview.rst:195 +msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." +msgstr "" + +#: ../source/overview.rst:199 +msgid "Service platforms" +msgstr "" + +#: ../source/overview.rst:201 +msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." +msgstr "" + +#: ../source/overview.rst:205 +msgid "`Heroku `_" +msgstr "" + +#: ../source/overview.rst:206 +msgid "`Google App Engine `_" +msgstr "" + +#: ../source/overview.rst:207 +msgid "`PythonAnywhere `_" +msgstr "" + +#: ../source/overview.rst:208 +msgid "`OpenShift `_" +msgstr "" + +#: ../source/overview.rst:209 +msgid "\"Serverless\" frameworks like `Zappa `_" +msgstr "" + +#: ../source/overview.rst:211 +msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." +msgstr "" + +#: ../source/overview.rst:216 +msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." +msgstr "" + +#: ../source/overview.rst:220 +msgid "Web browsers and mobile applications" +msgstr "" + +#: ../source/overview.rst:222 +msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." +msgstr "" + +#: ../source/overview.rst:227 +msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" +msgstr "" + +#: ../source/overview.rst:231 +msgid "`Kivy `_" +msgstr "" + +#: ../source/overview.rst:232 +msgid "`Beeware `_" +msgstr "" + +#: ../source/overview.rst:233 +msgid "`Brython `_" +msgstr "" + +#: ../source/overview.rst:234 +msgid "`Flexx `_" +msgstr "" + +#: ../source/overview.rst:236 +msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." +msgstr "" + +#: ../source/overview.rst:241 +msgid "Depending on a pre-installed Python" +msgstr "" + +#: ../source/overview.rst:243 +msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." +msgstr "" + +#: ../source/overview.rst:249 +msgid "Technologies which support this model:" +msgstr "" + +#: ../source/overview.rst:251 +msgid "`PEX `_ (Python EXecutable)" +msgstr "" + +#: ../source/overview.rst:252 +msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" +msgstr "" + +#: ../source/overview.rst:253 +msgid "`shiv `_ (requires Python 3)" +msgstr "" + +#: ../source/overview.rst:255 +msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." +msgstr "" + +#: ../source/overview.rst:260 +msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." +msgstr "" + +#: ../source/overview.rst:267 +msgid "Depending on a separate software distribution ecosystem" +msgstr "" + +#: ../source/overview.rst:269 +msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." +msgstr "" + +#: ../source/overview.rst:274 +msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." +msgstr "" + +#: ../source/overview.rst:284 +msgid "Instructions on building and publishing for the Anaconda ecosystem:" +msgstr "" + +#: ../source/overview.rst:286 +msgid "`Building libraries and applications with conda `_" +msgstr "" + +#: ../source/overview.rst:287 +msgid "`Transitioning a native Python package to Anaconda `_" +msgstr "" + +#: ../source/overview.rst:289 +msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" +msgstr "" + +#: ../source/overview.rst:293 +msgid "`Enthought Canopy `_" +msgstr "" + +#: ../source/overview.rst:294 +msgid "`ActiveState ActivePython `_" +msgstr "" + +#: ../source/overview.rst:295 +msgid "`WinPython `_" +msgstr "" + +#: ../source/overview.rst:300 +msgid "Bringing your own Python executable" +msgstr "" + +#: ../source/overview.rst:302 +msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." +msgstr "" + +#: ../source/overview.rst:306 +msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." +msgstr "" + +#: ../source/overview.rst:311 +msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." +msgstr "" + +#: ../source/overview.rst:315 +msgid "A selection of Python freezers:" +msgstr "" + +#: ../source/overview.rst:317 +msgid "`pyInstaller `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:318 +msgid "`cx_Freeze `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:319 +msgid "`constructor `_ - For command-line installers" +msgstr "" + +#: ../source/overview.rst:320 +msgid "`py2exe `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:321 +msgid "`py2app `_ - Mac only" +msgstr "" + +#: ../source/overview.rst:322 +msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" +msgstr "" + +#: ../source/overview.rst:323 +msgid "`osnap `_ - Windows and Mac" +msgstr "" + +#: ../source/overview.rst:324 +msgid "`pynsist `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:326 +msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." +msgstr "" + +#: ../source/overview.rst:332 +msgid "Bringing your own userspace" +msgstr "" + +#: ../source/overview.rst:334 +msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." +msgstr "" + +#: ../source/overview.rst:341 +msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." +msgstr "" + +#: ../source/overview.rst:344 +msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" +msgstr "" + +#: ../source/overview.rst:347 +msgid "`AppImage `_" +msgstr "" + +#: ../source/overview.rst:348 +msgid "`Docker `_" +msgstr "" + +#: ../source/overview.rst:349 +msgid "`Flatpak `_" +msgstr "" + +#: ../source/overview.rst:350 +msgid "`Snapcraft `_" +msgstr "" + +#: ../source/overview.rst:353 +msgid "Bringing your own kernel" +msgstr "" + +#: ../source/overview.rst:355 +msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." +msgstr "" + +#: ../source/overview.rst:360 +msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" +msgstr "" + +#: ../source/overview.rst:364 +msgid "`Vagrant `_" +msgstr "" + +#: ../source/overview.rst:365 +msgid "`VHD `_, `AMI `_, and `other formats `_" +msgstr "" + +#: ../source/overview.rst:366 +msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" +msgstr "" + +#: ../source/overview.rst:369 +msgid "Bringing your own hardware" +msgstr "" + +#: ../source/overview.rst:371 +msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." +msgstr "" + +#: ../source/overview.rst:375 +msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." +msgstr "" + +#: ../source/overview.rst:379 +msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." +msgstr "" + +#: ../source/overview.rst:389 +msgid "The simplified gamut of technologies used to package Python applications." +msgstr "" + +#: ../source/overview.rst:392 +msgid "What about..." +msgstr "" + +#: ../source/overview.rst:394 +msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." +msgstr "" + +#: ../source/overview.rst:398 +msgid "Operating system packages" +msgstr "" + +#: ../source/overview.rst:400 +msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." +msgstr "" + +#: ../source/overview.rst:411 +msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." +msgstr "" + +#: ../source/overview.rst:417 +msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." +msgstr "" + +#: ../source/overview.rst:427 +msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." +msgstr "" + +#: ../source/overview.rst:432 +msgid "Security" +msgstr "" + +#: ../source/overview.rst:434 +msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." +msgstr "" + +#: ../source/overview.rst:437 +msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." +msgstr "" + +#: ../source/overview.rst:446 +msgid "Wrap up" +msgstr "" + +#: ../source/overview.rst:448 +msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:6 +msgid "Binary distribution format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:8 +msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:13 +msgid "Abstract" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:15 +msgid "This PEP describes a built-package format for Python called \"wheel\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:17 +msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:27 +msgid "PEP Acceptance" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:29 +msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:34 +msgid "Rationale" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:36 +msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:43 +msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:52 +msgid "Details" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:55 +msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:57 +msgid "Wheel installation notionally consists of two phases:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:59 +msgid "Unpack." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:61 +msgid "Parse ``distribution-1.0.dist-info/WHEEL``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:62 +msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:64 +msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:66 +msgid "Else unpack archive into platlib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:68 +msgid "Spread." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:70 +msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:72 +msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:78 +msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:80 +msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:82 +msgid "Remove empty ``distribution-1.0.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:83 +msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:87 +msgid "Recommended installer features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:97 +msgid "Rewrite ``#!python``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:90 +msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:96 +msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:102 +msgid "Generate script wrappers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:100 +msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:105 +msgid "Recommended archiver features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:112 +msgid "Place ``.dist-info`` at the end of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:108 +msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:115 +msgid "File Format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:118 +msgid "File name convention" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:120 +msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "distribution" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "Distribution name, e.g. 'django', 'pyramid'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "Distribution version, e.g. 1.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:135 +msgid "build tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:130 +msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "language implementation and version tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "E.g. 'py27', 'py2', 'py3'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "abi tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "E.g. 'cp33m', 'abi3', 'none'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "platform tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "E.g. 'linux_x86_64', 'any'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:146 +msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:151 +msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:156 +msgid "Escaping and Unicode" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:158 +msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:161 +msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:164 +msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:166 +msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:169 +msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:172 +msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:176 +msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:182 +msgid "File contents" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:184 +msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:188 +msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:191 +msgid "``{distribution}-{version}.dist-info/`` contains metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:192 +msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:196 +msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:200 +msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:202 +msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:212 +msgid "``Wheel-Version`` is the version number of the Wheel specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:213 +msgid "``Generator`` is the name and optionally the version of the software that produced the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:215 +msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:218 +msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:220 +msgid "``Build`` is the build number and is omitted if there is no build number." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:221 +msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:224 +msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:226 +msgid "Wheel does not contain setup.py or setup.cfg." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:228 +msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:235 +#: ../source/specifications/recording-installed-packages.rst:35 +msgid "The .dist-info directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:237 +msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:239 +msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:241 +msgid "WHEEL is the wheel metadata specific to a build of the package." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:242 +msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:248 +msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:249 +msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:251 +msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:254 +msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:261 +msgid "The .data directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:263 +msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:271 +msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:277 +msgid "Signed wheel files" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:279 +msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:290 +msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:295 +msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:302 +msgid "(The hash value is the same format used in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:304 +msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:307 +msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:312 +msgid "See" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:314 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:315 +msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:316 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:317 +msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:321 +msgid "Comparison to .egg" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:323 +msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:328 +msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:331 +msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:337 +msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:341 +msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:344 +msgid "Wheel is a reference to the other Python." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:348 +msgid "FAQ" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:352 +msgid "Wheel defines a .data directory. Should I put all my data there?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:354 +msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:363 +msgid "Why does wheel include attached signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:365 +msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:373 +msgid "Why does wheel allow JWS signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:375 +msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:381 +msgid "Why does wheel also allow S/MIME signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:383 +msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:386 +msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:391 +msgid "What's the deal with \"purelib\" vs. \"platlib\"?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:393 +msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:398 +msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:403 +msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:409 +msgid "Is it possible to import Python code directly from a wheel file?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:411 +msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:417 +msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:426 +msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:443 +msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:450 +msgid "Changes" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:452 +msgid "Since :pep:`427`, this specification has changed as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:454 +msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:461 +msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:466 +msgid "Appendix" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:468 +msgid "Example urlsafe-base64-nopad implementation::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:482 +msgid "Copyright" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:484 +msgid "This document has been placed into the public domain." +msgstr "" + +#: ../source/specifications/core-metadata.rst:5 +msgid "Core metadata specifications" +msgstr "" + +#: ../source/specifications/core-metadata.rst:7 +msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:10 +msgid "``Metadata-Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:11 +msgid "``Name``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:12 +msgid "``Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:14 +msgid "All the other fields are optional." +msgstr "" + +#: ../source/specifications/core-metadata.rst:16 +msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." +msgstr "" + +#: ../source/specifications/core-metadata.rst:25 +msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:30 +msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." +msgstr "" + +#: ../source/specifications/core-metadata.rst:41 +msgid "Metadata-Version" +msgstr "" + +#: ../source/specifications/core-metadata.rst:45 +msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." +msgstr "" + +#: ../source/specifications/core-metadata.rst:48 +msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:54 +msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." +msgstr "" + +#: ../source/specifications/core-metadata.rst:58 +#: ../source/specifications/core-metadata.rst:80 +#: ../source/specifications/core-metadata.rst:95 +#: ../source/specifications/core-metadata.rst:155 +#: ../source/specifications/core-metadata.rst:170 +#: ../source/specifications/core-metadata.rst:208 +#: ../source/specifications/core-metadata.rst:283 +#: ../source/specifications/core-metadata.rst:287 +#: ../source/specifications/core-metadata.rst:291 +#: ../source/specifications/core-metadata.rst:295 +#: ../source/specifications/core-metadata.rst:327 +#: ../source/specifications/core-metadata.rst:347 +#: ../source/specifications/core-metadata.rst:373 +#: ../source/specifications/core-metadata.rst:391 +#: ../source/specifications/core-metadata.rst:416 +#: ../source/specifications/core-metadata.rst:438 +#: ../source/specifications/core-metadata.rst:600 +#: ../source/specifications/core-metadata.rst:620 +#: ../source/specifications/core-metadata.rst:630 +msgid "Example::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:66 +msgid "Name" +msgstr "" + +#: ../source/specifications/core-metadata.rst:69 +msgid "Added additional restrictions on format from :pep:`508`" +msgstr "" + +#: ../source/specifications/core-metadata.rst:72 +msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:88 +msgid "Version" +msgstr "" + +#: ../source/specifications/core-metadata.rst:92 +msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:101 +msgid "Dynamic (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:105 +msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." +msgstr "" + +#: ../source/specifications/core-metadata.rst:108 +msgid "When found in the metadata of a source distribution, the following rules apply:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:111 +msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." +msgstr "" + +#: ../source/specifications/core-metadata.rst:115 +msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:118 +msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:122 +msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." +msgstr "" + +#: ../source/specifications/core-metadata.rst:127 +msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:131 +msgid "Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:135 +msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." +msgstr "" + +#: ../source/specifications/core-metadata.rst:146 +msgid "Supported-Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:150 +msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." +msgstr "" + +#: ../source/specifications/core-metadata.rst:164 +msgid "Summary" +msgstr "" + +#: ../source/specifications/core-metadata.rst:168 +msgid "A one-line summary of what the distribution does." +msgstr "" + +#: ../source/specifications/core-metadata.rst:188 +msgid "This field may be specified in the message body instead." +msgstr "" + +#: ../source/specifications/core-metadata.rst:191 +msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:196 +msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." +msgstr "" + +#: ../source/specifications/core-metadata.rst:202 +msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:219 +msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." +msgstr "" + +#: ../source/specifications/core-metadata.rst:223 +msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:232 +msgid "Description-Content-Type" +msgstr "" + +#: ../source/specifications/core-metadata.rst:236 +msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:239 +msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." +msgstr "" + +#: ../source/specifications/core-metadata.rst:253 +msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:259 +msgid "Format::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:263 +msgid "The ``type/subtype`` part has only a few legal values:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:265 +msgid "``text/plain``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:266 +msgid "``text/x-rst``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:267 +msgid "``text/markdown``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:269 +msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:273 +msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:278 +msgid "``GFM`` for `Github-flavored Markdown `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:280 +msgid "``CommonMark`` for `CommonMark `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:299 +msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." +msgstr "" + +#: ../source/specifications/core-metadata.rst:303 +msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:307 +msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:311 +msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." +msgstr "" + +#: ../source/specifications/core-metadata.rst:320 +msgid "Keywords" +msgstr "" + +#: ../source/specifications/core-metadata.rst:324 +msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." +msgstr "" + +#: ../source/specifications/core-metadata.rst:333 +msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." +msgstr "" + +#: ../source/specifications/core-metadata.rst:341 +msgid "Home-page" +msgstr "" + +#: ../source/specifications/core-metadata.rst:345 +msgid "A string containing the URL for the distribution's home page." +msgstr "" + +#: ../source/specifications/core-metadata.rst:353 +msgid "Download-URL" +msgstr "" + +#: ../source/specifications/core-metadata.rst:357 +msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:366 +msgid "Author" +msgstr "" + +#: ../source/specifications/core-metadata.rst:370 +msgid "A string containing the author's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:383 +msgid "Author-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:387 +msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:395 +#: ../source/specifications/core-metadata.rst:442 +msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:405 +msgid "Maintainer" +msgstr "" + +#: ../source/specifications/core-metadata.rst:409 +msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:412 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:426 +msgid "Maintainer-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:430 +msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:434 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:452 +msgid "License" +msgstr "" + +#: ../source/specifications/core-metadata.rst:456 +msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." +msgstr "" + +#: ../source/specifications/core-metadata.rst:476 +msgid "Classifier (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:480 +msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:485 +#: ../source/specifications/core-metadata.rst:574 +#: ../source/specifications/core-metadata.rst:691 +#: ../source/specifications/core-metadata.rst:715 +msgid "This field may be followed by an environment marker after a semicolon." +msgstr "" + +#: ../source/specifications/core-metadata.rst:496 +msgid "Requires-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:499 +#: ../source/specifications/core-metadata.rst:561 +#: ../source/specifications/core-metadata.rst:663 +#: ../source/specifications/core-metadata.rst:704 +msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." +msgstr "" + +#: ../source/specifications/core-metadata.rst:503 +msgid "Each entry contains a string naming some other distutils project required by this distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:506 +msgid "The format of a requirement string contains from one to four parts:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:508 +msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." +msgstr "" + +#: ../source/specifications/core-metadata.rst:510 +msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." +msgstr "" + +#: ../source/specifications/core-metadata.rst:513 +msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:516 +msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." +msgstr "" + +#: ../source/specifications/core-metadata.rst:519 +msgid "See :pep:`508` for full details of the allowed format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:521 +msgid "The project names should correspond to names as found on the `Python Package Index`_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:524 +msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:538 +msgid "Requires-Python" +msgstr "" + +#: ../source/specifications/core-metadata.rst:542 +msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." +msgstr "" + +#: ../source/specifications/core-metadata.rst:546 +msgid "The value must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:548 +msgid "This field cannot be followed by an environment marker." +msgstr "" + +#: ../source/specifications/core-metadata.rst:558 +msgid "Requires-External (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:565 +msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:570 +msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:576 +msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." +msgstr "" + +#: ../source/specifications/core-metadata.rst:581 +msgid "Notice that there is no particular rule on the strings to be used." +msgstr "" + +#: ../source/specifications/core-metadata.rst:593 +msgid "Project-URL (multiple-use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:597 +msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." +msgstr "" + +#: ../source/specifications/core-metadata.rst:604 +msgid "The label is free text limited to 32 characters." +msgstr "" + +#: ../source/specifications/core-metadata.rst:612 +msgid "Provides-Extra (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:616 +msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." +msgstr "" + +#: ../source/specifications/core-metadata.rst:625 +msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:635 +msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." +msgstr "" + +#: ../source/specifications/core-metadata.rst:639 +msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:644 +msgid "Rarely Used Fields" +msgstr "" + +#: ../source/specifications/core-metadata.rst:646 +msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:651 +msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." +msgstr "" + +#: ../source/specifications/core-metadata.rst:660 +msgid "Provides-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:667 +msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:672 +msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:679 +msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:687 +msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." +msgstr "" + +#: ../source/specifications/core-metadata.rst:701 +msgid "Obsoletes-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:708 +msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." +msgstr "" + +#: ../source/specifications/core-metadata.rst:712 +msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:717 +msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:730 +msgid "reStructuredText markup: http://docutils.sourceforge.net/" +msgstr "" + +#: ../source/specifications/core-metadata.rst:735 +msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:6 +msgid "Declaring build system dependencies" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:8 +msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:5 +msgid "Declaring project metadata" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:7 +msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:12 +msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:18 +msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:27 +msgid "The only fields required to be statically defined are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:29 +#: ../source/specifications/declaring-project-metadata.rst:41 +msgid "``name``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:31 +msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:34 +#: ../source/specifications/declaring-project-metadata.rst:54 +msgid "``version``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:36 +msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:43 +#: ../source/specifications/declaring-project-metadata.rst:56 +#: ../source/specifications/declaring-project-metadata.rst:68 +#: ../source/specifications/declaring-project-metadata.rst:117 +msgid "TOML_ type: string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:44 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:47 +msgid "The name of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:49 +msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:57 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:60 +msgid "The version of the project as supported by :pep:`440`." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:62 +msgid "Users SHOULD prefer to specify already-normalized versions." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:66 +msgid "``description``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:69 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:72 +msgid "The summary description of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:76 +msgid "``readme``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:78 +msgid "TOML_ type: string or table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:79 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:83 +msgid "The full description of the project (i.e. the README)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:85 +msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:96 +msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:103 +msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:115 +msgid "``requires-python``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:118 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:121 +msgid "The Python version requirements of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:125 +msgid "``license``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:127 +msgid "TOML_ type: table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:128 +msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:131 +msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:140 +msgid "``authors``/``maintainers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:142 +msgid "TOML_ type: Array of inline tables with string keys and values" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:143 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:149 +msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:154 +msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:157 +msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:163 +msgid "Using the data to fill in :ref:`core metadata ` is as follows:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:166 +msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:169 +msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:173 +msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:177 +msgid "Multiple values should be separated by commas." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:181 +msgid "``keywords``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:183 +#: ../source/specifications/declaring-project-metadata.rst:193 +msgid "TOML_ type: array of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:184 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:187 +msgid "The keywords for the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:191 +msgid "``classifiers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:194 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:197 +msgid "Trove classifiers which apply to the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:201 +msgid "``urls``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:203 +msgid "TOML_ type: table with keys and values of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:204 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:207 +msgid "A table of URLs where the key is the URL label and the value is the URL itself." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:212 +msgid "Entry points" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:214 +msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:216 +msgid ":ref:`Entry points specification `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:218 +msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:224 +msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:228 +msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:234 +msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:242 +msgid "``dependencies``/``optional-dependencies``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:244 +msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:247 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:251 +msgid "The (optional) dependencies of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:253 +msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:258 +msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:269 +msgid "``dynamic``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:271 +msgid "TOML_ type: array of string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:272 +msgid "A corresponding :ref:`core metadata ` field does not exist" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:275 +msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:281 +msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:283 +msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:285 +msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:290 +msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:294 +msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:296 +msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:300 +msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:6 +msgid "Dependency specifiers" +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:8 +msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:11 +msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." +msgstr "" + +#: ../source/specifications/direct-url.rst:6 +msgid "Recording the Direct URL Origin of installed distributions" +msgstr "" + +#: ../source/specifications/direct-url.rst:8 +msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." +msgstr "" + +#: ../source/specifications/direct-url.rst:17 +msgid "Specification" +msgstr "" + +#: ../source/specifications/direct-url.rst:19 +msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/direct-url.rst:23 +#: ../source/specifications/recording-installed-packages.rst:206 +msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." +msgstr "" + +#: ../source/specifications/direct-url.rst:26 +msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." +msgstr "" + +#: ../source/specifications/direct-url.rst:29 +msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." +msgstr "" + +#: ../source/specifications/direct-url.rst:36 +msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." +msgstr "" + +#: ../source/specifications/direct-url.rst:39 +msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" +msgstr "" + +#: ../source/specifications/direct-url.rst:45 +msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." +msgstr "" + +#: ../source/specifications/direct-url.rst:49 +msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" +msgstr "" + +#: ../source/specifications/direct-url.rst:52 +msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." +msgstr "" + +#: ../source/specifications/direct-url.rst:58 +msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." +msgstr "" + +#: ../source/specifications/direct-url.rst:61 +msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." +msgstr "" + +#: ../source/specifications/direct-url.rst:68 +msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:71 +msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." +msgstr "" + +#: ../source/specifications/direct-url.rst:78 +msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:81 +msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." +msgstr "" + +#: ../source/specifications/direct-url.rst:84 +msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." +msgstr "" + +#: ../source/specifications/direct-url.rst:91 +msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." +msgstr "" + +#: ../source/specifications/direct-url.rst:96 +msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." +msgstr "" + +#: ../source/specifications/direct-url.rst:102 +msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." +msgstr "" + +#: ../source/specifications/direct-url.rst:110 +msgid "Registered VCS" +msgstr "" + +#: ../source/specifications/direct-url.rst:112 +msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." +msgstr "" + +#: ../source/specifications/direct-url.rst:122 +msgid "Git" +msgstr "" + +#: ../source/specifications/direct-url.rst:124 +#: ../source/specifications/direct-url.rst:156 +#: ../source/specifications/direct-url.rst:179 +#: ../source/specifications/direct-url.rst:202 +msgid "Home page" +msgstr "" + +#: ../source/specifications/direct-url.rst:126 +msgid "https://git-scm.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:128 +#: ../source/specifications/direct-url.rst:160 +#: ../source/specifications/direct-url.rst:183 +#: ../source/specifications/direct-url.rst:206 +msgid "vcs command" +msgstr "" + +#: ../source/specifications/direct-url.rst:130 +#: ../source/specifications/direct-url.rst:134 +msgid "git" +msgstr "" + +#: ../source/specifications/direct-url.rst:132 +#: ../source/specifications/direct-url.rst:164 +#: ../source/specifications/direct-url.rst:187 +#: ../source/specifications/direct-url.rst:210 +msgid "``vcs`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:136 +#: ../source/specifications/direct-url.rst:168 +#: ../source/specifications/direct-url.rst:191 +#: ../source/specifications/direct-url.rst:214 +msgid "``requested_revision`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:138 +msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." +msgstr "" + +#: ../source/specifications/direct-url.rst:141 +#: ../source/specifications/direct-url.rst:172 +#: ../source/specifications/direct-url.rst:195 +#: ../source/specifications/direct-url.rst:219 +msgid "``commit_id`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:143 +msgid "A commit hash (40 hexadecimal characters sha1)." +msgstr "" + +#: ../source/specifications/direct-url.rst:147 +msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." +msgstr "" + +#: ../source/specifications/direct-url.rst:154 +msgid "Mercurial" +msgstr "" + +#: ../source/specifications/direct-url.rst:158 +msgid "https://www.mercurial-scm.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:162 +#: ../source/specifications/direct-url.rst:166 +msgid "hg" +msgstr "" + +#: ../source/specifications/direct-url.rst:170 +msgid "A tag name, branch name, changeset ID, shortened changeset ID." +msgstr "" + +#: ../source/specifications/direct-url.rst:174 +msgid "A changeset ID (40 hexadecimal characters)." +msgstr "" + +#: ../source/specifications/direct-url.rst:177 +msgid "Bazaar" +msgstr "" + +#: ../source/specifications/direct-url.rst:181 +msgid "https://bazaar.canonical.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:185 +#: ../source/specifications/direct-url.rst:189 +msgid "bzr" +msgstr "" + +#: ../source/specifications/direct-url.rst:193 +msgid "A tag name, branch name, revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:197 +msgid "A revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:200 +msgid "Subversion" +msgstr "" + +#: ../source/specifications/direct-url.rst:204 +msgid "https://subversion.apache.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:208 +#: ../source/specifications/direct-url.rst:212 +msgid "svn" +msgstr "" + +#: ../source/specifications/direct-url.rst:216 +msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." +msgstr "" + +#: ../source/specifications/direct-url.rst:221 +msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." +msgstr "" + +#: ../source/specifications/direct-url.rst:229 +msgid "Example direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:231 +msgid "Source archive:" +msgstr "" + +#: ../source/specifications/direct-url.rst:242 +msgid "Git URL with tag and commit-hash:" +msgstr "" + +#: ../source/specifications/direct-url.rst:255 +msgid "Local directory:" +msgstr "" + +#: ../source/specifications/direct-url.rst:264 +msgid "Local directory installed in editable mode:" +msgstr "" + +#: ../source/specifications/direct-url.rst:277 +msgid "Example pip commands and their effect on direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:279 +msgid "Commands that generate a ``direct_url.json``:" +msgstr "" + +#: ../source/specifications/direct-url.rst:281 +msgid "pip install https://example.com/app-1.0.tgz" +msgstr "" + +#: ../source/specifications/direct-url.rst:282 +msgid "pip install https://example.com/app-1.0.whl" +msgstr "" + +#: ../source/specifications/direct-url.rst:283 +msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" +msgstr "" + +#: ../source/specifications/direct-url.rst:284 +msgid "pip install ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:285 +msgid "pip install file:///home/user/app" +msgstr "" + +#: ../source/specifications/direct-url.rst:286 +msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" +msgstr "" + +#: ../source/specifications/direct-url.rst:290 +msgid "pip install -e ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:292 +msgid "Commands that *do not* generate a ``direct_url.json``" +msgstr "" + +#: ../source/specifications/direct-url.rst:294 +msgid "pip install app" +msgstr "" + +#: ../source/specifications/direct-url.rst:295 +msgid "pip install app --no-index --find-links https://example.com/" +msgstr "" + +#: ../source/specifications/entry-points.rst:5 +msgid "Entry points specification" +msgstr "" + +#: ../source/specifications/entry-points.rst:7 +msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" +msgstr "" + +#: ../source/specifications/entry-points.rst:11 +msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." +msgstr "" + +#: ../source/specifications/entry-points.rst:14 +msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." +msgstr "" + +#: ../source/specifications/entry-points.rst:19 +msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." +msgstr "" + +#: ../source/specifications/entry-points.rst:28 +msgid "Data model" +msgstr "" + +#: ../source/specifications/entry-points.rst:30 +msgid "Conceptually, an entry point is defined by three required properties:" +msgstr "" + +#: ../source/specifications/entry-points.rst:32 +msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:42 +msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:51 +msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:64 +msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." +msgstr "" + +#: ../source/specifications/entry-points.rst:68 +msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." +msgstr "" + +#: ../source/specifications/entry-points.rst:73 +msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." +msgstr "" + +#: ../source/specifications/entry-points.rst:80 +msgid "File format" +msgstr "" + +#: ../source/specifications/entry-points.rst:82 +msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." +msgstr "" + +#: ../source/specifications/entry-points.rst:87 +msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:97 +msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:100 +msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." +msgstr "" + +#: ../source/specifications/entry-points.rst:104 +msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." +msgstr "" + +#: ../source/specifications/entry-points.rst:112 +msgid "For example::" +msgstr "" + +#: ../source/specifications/entry-points.rst:124 +msgid "Use for scripts" +msgstr "" + +#: ../source/specifications/entry-points.rst:126 +msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." +msgstr "" + +#: ../source/specifications/entry-points.rst:134 +msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:141 +msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." +msgstr "" + +#: ../source/specifications/entry-points.rst:149 +msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." +msgstr "" + +#: ../source/specifications/entry-points.rst:154 +msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." +msgstr "" + +#: ../source/specifications/index.rst:4 +msgid "PyPA specifications" +msgstr "" + +#: ../source/specifications/index.rst:6 +msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." +msgstr "" + +#: ../source/specifications/index.rst:13 +msgid "Package Distribution Metadata" +msgstr "" + +#: ../source/specifications/index.rst:30 +msgid "Package Distribution File Formats" +msgstr "" + +#: ../source/specifications/index.rst:40 +msgid "Package Index Interfaces" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:6 +msgid "Platform compatibility tags" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:8 +msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:12 +msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:16 +msgid "Platform tags for Windows" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:18 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:22 +msgid "Platform tags for macOS (Mac OS X)" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:24 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:28 +msgid "Platform tags for common Linux distributions" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:32 +msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:36 +msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:41 +msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:44 +msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:46 +msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:49 +msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:54 +msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:59 +msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:65 +msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:71 +msgid "Manylinux compatibility support" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:74 +msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:76 +msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:79 +msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "Tool" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux1``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2010``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2014``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux_x_y``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=8.1.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=20.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "auditwheel" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=1.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=2.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.3.0`` [#]_" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:90 +msgid "Platform tags for other \\*nix platforms" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:92 +msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:98 +msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" +msgstr "" + +#: ../source/specifications/pypirc.rst:6 +msgid "The :file:`.pypirc` file" +msgstr "" + +#: ../source/specifications/pypirc.rst:8 +msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." +msgstr "" + +#: ../source/specifications/pypirc.rst:13 +msgid "The format (originally defined by the :ref:`distutils` package) is:" +msgstr "" + +#: ../source/specifications/pypirc.rst:32 +msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:35 +msgid "Each section describing a repository defines three fields:" +msgstr "" + +#: ../source/specifications/pypirc.rst:37 +msgid "``repository``: The URL of the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:38 +msgid "``username``: The registered username on the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:39 +msgid "``password``: The password that will used to authenticate the username." +msgstr "" + +#: ../source/specifications/pypirc.rst:43 +msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." +msgstr "" + +#: ../source/specifications/pypirc.rst:47 +msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" +msgstr "" + +#: ../source/specifications/pypirc.rst:57 +msgid "Common configurations" +msgstr "" + +#: ../source/specifications/pypirc.rst:61 +msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." +msgstr "" + +#: ../source/specifications/pypirc.rst:66 +msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" +msgstr "" + +#: ../source/specifications/pypirc.rst:82 +msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." +msgstr "" + +#: ../source/specifications/pypirc.rst:86 +msgid "Using a PyPI token" +msgstr "" + +#: ../source/specifications/pypirc.rst:88 +msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" +msgstr "" + +#: ../source/specifications/pypirc.rst:97 +msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." +msgstr "" + +#: ../source/specifications/pypirc.rst:103 +msgid "Using another package index" +msgstr "" + +#: ../source/specifications/pypirc.rst:105 +msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" +msgstr "" + +#: ../source/specifications/pypirc.rst:132 +msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:5 +msgid "Recording installed projects" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:7 +msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:12 +msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:21 +msgid "History and change workflow" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:23 +msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:29 +msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:37 +msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:41 +msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:50 +msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:60 +msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:69 +msgid "This ``.dist-info`` directory can contain these files, described in detail below:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:72 +msgid "``METADATA``: contains project metadata" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:73 +msgid "``RECORD``: records the list of installed files." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:74 +msgid "``INSTALLER``: records the name of the tool used to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:76 +msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:82 +msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:87 +msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:94 +msgid "The METADATA file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:96 +msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:99 +msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:105 +msgid "The RECORD file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:107 +msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:110 +msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:113 +msgid "field delimiter: ``,`` (comma)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:114 +msgid "quoting char: ``\"`` (straight double quote)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:115 +msgid "line terminator: either ``\\r\\n`` or ``\\n``." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:117 +msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:120 +msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:125 +msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:130 +msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:133 +msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:139 +msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:146 +msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:151 +msgid "Here is an example snippet of a possible ``RECORD`` file::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:170 +msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:177 +msgid "The INSTALLER file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:179 +msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:185 +msgid "The file can be terminated by zero or more ASCII whitespace characters." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:187 +msgid "Here are examples of two possible ``INSTALLER`` files::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:195 +msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:201 +msgid "The direct_url.json file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:203 +msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:209 +msgid "Its detailed specification is at :ref:`direct-url`." +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:6 +msgid "Simple repository API" +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:8 +msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:6 +msgid "Source distribution format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:8 +msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:13 +msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:21 +msgid "Source distributions are also known as *sdists* for short." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:24 +msgid "Source distribution file name" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:26 +msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:31 +msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:35 +msgid "Source distribution file format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:37 +msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:45 +msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:48 +msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:6 +msgid "Version specifiers" +msgstr "" + +#: ../source/specifications/version-specifiers.rst:8 +msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:11 +msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." +msgstr "" + +#: ../source/support.rst:3 +msgid "How to Get Support" +msgstr "" + +#: ../source/support.rst:5 +msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." +msgstr "" + +#: ../source/support.rst:8 +msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:5 +msgid "Creating Documentation" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:7 +msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:13 +msgid "Installing Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:14 +msgid "Use ``pip`` to install Sphinx:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:28 +msgid "For other installation methods, see this `installation guide`_ by Sphinx." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:33 +msgid "Getting Started With Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:35 +msgid "Create a ``docs`` directory inside your project to hold your documentation:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:42 +msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:49 +msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:51 +msgid "You can add some information about your project in ``index.rst``, then build them:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:57 +msgid "For more details on the build process, see this `guide`_ by Read The Docs." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:62 +msgid "Other Sources" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:64 +msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/index.rst:4 +msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:5 +msgid "Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:7 +msgid "This section covers the basics of how to install Python :term:`packages `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:10 +msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:28 +msgid "Requirements for Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:30 +msgid "This section describes the steps to follow before installing other Python packages." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:35 +msgid "Ensure you can run Python from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:37 +msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:53 +msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:57 +msgid "If you're a newcomer and you get an error like this:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:66 +msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:72 +msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:82 +msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:87 +msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:99 +msgid "Ensure you can run pip from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:101 +msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:116 +msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:124 +msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:139 +msgid "If that still doesn't allow you to run ``python -m pip``:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:141 +msgid "Securely Download `get-pip.py `_ [1]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:144 +msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:150 +msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:159 +msgid "Ensure pip, setuptools, and wheel are up to date" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:161 +msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:169 +msgid "Optionally, create a virtual environment" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:171 +msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:188 +msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:195 +msgid "Creating Virtual Environments" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:197 +msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:203 +msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:209 +msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:213 +msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:216 +msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:220 +msgid "Currently, there are two common tools for creating Python virtual environments:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:222 +msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:225 +msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:230 +msgid "The basic usage is like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:232 +msgid "Using `venv`_:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:248 +msgid "Using :ref:`virtualenv`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:264 +msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:266 +msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:271 +msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:281 +msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:288 +msgid "Use pip for Installing" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:290 +msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:297 +msgid "Installing from PyPI" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:299 +msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:307 +msgid "To install the latest version of \"SomeProject\":" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:321 +msgid "To install a specific version:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:335 +msgid "To install greater than or equal to one version and less than another:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:350 +msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:365 +msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:370 +msgid "Source Distributions vs Wheels" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:372 +msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:378 +msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:383 +msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:391 +msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:408 +msgid "Installing to the User Site" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:410 +msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:425 +msgid "For more information see the `User Installs `_ section from the pip docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:429 +msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:432 +msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:440 +msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:446 +msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:462 +msgid "Install a list of requirements specified in a :ref:`Requirements File `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:478 +msgid "Installing from VCS" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:480 +msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:502 +msgid "Installing from other Indexes" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:504 +msgid "Install from an alternate index" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:518 +msgid "Search an additional index during install, in addition to :term:`PyPI `" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:534 +msgid "Installing from a local src tree" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:537 +msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:554 +msgid "You can also install normally from src" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:571 +msgid "Install a particular source archive file." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:585 +msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:605 +msgid "Installing from other sources" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:607 +msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:619 +msgid "Installing Prereleases" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:621 +msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:637 +msgid "Installing Setuptools \"Extras\"" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:639 +msgid "Install `setuptools extras`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:659 +msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:668 +msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:673 +msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:4 +msgid "Managing Application Dependencies" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:6 +msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:9 +msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:13 +msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:17 +msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:24 +msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:30 +msgid "Installing Pipenv" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:32 +msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:38 +msgid "Use ``pip`` to install Pipenv:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:54 +msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:65 +msgid "Installing packages for your project" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:67 +msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:76 +msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:112 +msgid "Using installed packages" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:114 +msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:125 +msgid "Then you can run this script using ``pipenv run``:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:131 +msgid "You should get output similar to this:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:137 +msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:143 +#: ../source/tutorials/packaging-projects.rst:594 +msgid "Next steps" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:145 +msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:148 +msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:151 +msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:160 +msgid "Other Tools for Application Dependency Management" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:162 +msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:166 +msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:172 +msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:175 +msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:177 +msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:2 +msgid "Packaging Python Projects" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:4 +msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:10 +msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:18 +msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:35 +msgid "A simple project" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:37 +msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:41 +msgid "Create the following file structure locally:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:51 +msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:54 +msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:63 +msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:67 +msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:75 +msgid "Creating the package files" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:77 +msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:95 +msgid "Creating a test directory" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:97 +msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:101 +msgid "Creating pyproject.toml" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:103 +msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:117 +msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:121 +msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:127 +msgid "See :pep:`517` and :pep:`518` for background and details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:131 +msgid "Configuring metadata" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:133 +msgid "There are two types of metadata: static and dynamic." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:135 +msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:137 +msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:141 +msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:148 +msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:153 +msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:185 +msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:191 +#: ../source/tutorials/packaging-projects.rst:286 +msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:196 +msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:199 +#: ../source/tutorials/packaging-projects.rst:293 +msgid "``author`` and ``author_email`` are used to identify the author of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:201 +#: ../source/tutorials/packaging-projects.rst:295 +msgid "``description`` is a short, one-sentence summary of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:202 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:206 +#: ../source/tutorials/packaging-projects.rst:300 +msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:208 +#: ../source/tutorials/packaging-projects.rst:302 +msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:211 +#: ../source/tutorials/packaging-projects.rst:305 +msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:213 +#: ../source/tutorials/packaging-projects.rst:307 +msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:221 +msgid "In the ``options`` category, we have controls for setuptools itself:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:223 +msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:227 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:234 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:238 +#: ../source/tutorials/packaging-projects.rst:329 +msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:244 +msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:248 +msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:283 +msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:291 +msgid "``version`` is the package version. See :pep:`440` for more details on versions." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:296 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:314 +msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:319 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:325 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:333 +msgid "Creating README.md" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:335 +msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:347 +msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:354 +msgid "Creating a LICENSE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:356 +msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:387 +msgid "Including other files" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:389 +msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:393 +msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:402 +msgid "Generating distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:404 +msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:408 +msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:422 +msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:425 +msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:439 +msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:449 +msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:458 +msgid "Uploading the distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:460 +msgid "Finally, it's time to upload your package to the Python Package Index!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:462 +msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:470 +msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:477 +msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:492 +msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:506 +msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:510 +msgid "After the command completes, you should see output similar to this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:523 +msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:528 +msgid "Installing your newly uploaded package" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:530 +msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:546 +msgid "Make sure to specify your username in the package name!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:548 +msgid "pip should install the package from TestPyPI and the output should look something like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:558 +msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:565 +msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:580 +msgid "and import the package:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:588 +msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:596 +msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:599 +msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:604 +msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:608 +msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:610 +msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:613 +msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:617 +msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." +msgstr "使用 ``python3 -m pip install [your-package]`` 以從真正的PyPI安裝您的套件。" + +#: ../source/tutorials/packaging-projects.rst:619 +msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" +msgstr "此時，如果您想閱讀有關打包 Python 庫的更多信息，您可以執行以下操作：" + +#: ../source/tutorials/packaging-projects.rst:622 +msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:624 +msgid "Read about :doc:`/guides/packaging-binary-extensions`." +msgstr "閱讀 :doc:`/guides/packaging-binary-extensions`。" + +#: ../source/tutorials/packaging-projects.rst:625 +msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." +msgstr "" From a15d8c3be65ca060091b8ec6f7455249a9ddd45a Mon Sep 17 00:00:00 2001 From: Rafael Fontenelle Date: Sun, 29 Aug 2021 18:15:30 +0200 Subject: [PATCH 0078/1072] Translated using Weblate (Portuguese (Brazil)) Currently translated at 5.0% (115 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 1.8% (42 of 2271 strings) Added translation using Weblate (Portuguese (Brazil)) Co-authored-by: Rafael Fontenelle Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/pt_BR/ Translation: pypa/packaging.python.org --- locales/pt_BR/LC_MESSAGES/messages.po | 9423 +++++++++++++++++++++++++ 1 file changed, 9423 insertions(+) create mode 100644 locales/pt_BR/LC_MESSAGES/messages.po diff --git a/locales/pt_BR/LC_MESSAGES/messages.po b/locales/pt_BR/LC_MESSAGES/messages.po new file mode 100644 index 000000000..7e281145c --- /dev/null +++ b/locales/pt_BR/LC_MESSAGES/messages.po @@ -0,0 +1,9423 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2013–2020, PyPA +# This file is distributed under the same license as the Python Packaging User Guide package. +# Rafael Fontenelle , 2021. +msgid "" +msgstr "" +"Project-Id-Version: Python Packaging User Guide\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-07-06 19:32+0800\n" +"PO-Revision-Date: 2021-07-16 11:12+0000\n" +"Last-Translator: Rafael Fontenelle \n" +"Language-Team: Portuguese (Brazil) \n" +"Language: pt_BR\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=2; plural=n > 1;\n" +"X-Generator: Weblate 4.7.2-dev\n" + +#: ../source/contribute.rst:5 +msgid "Contribute to this guide" +msgstr "Contribuir para este guia" + +#: ../source/contribute.rst:7 +msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" +msgstr "" +"O |PyPUG| dá as boas-vindas aos(às) contribuidores(as)! Existem muitas " +"maneiras de ajudar, incluindo:" + +#: ../source/contribute.rst:10 +msgid "Reading the guide and giving feedback" +msgstr "Lendo o guia e dando feedback" + +#: ../source/contribute.rst:11 +msgid "Reviewing new contributions" +msgstr "Revisando novas contribuições" + +#: ../source/contribute.rst:12 +msgid "Revising existing content" +msgstr "Revisando conteúdo existente" + +#: ../source/contribute.rst:13 +msgid "Writing new content" +msgstr "Escrevendo novo conteúdo" + +#: ../source/contribute.rst:15 +msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." +msgstr "" +"A maior parte do trabalho no |PyPUG| ocorre no `repositório GitHub do " +"projeto`__. Para começar, verifique a lista de `problemas abertos`__ e `pull " +"requests`__. Se você está planejando escrever ou editar o guia, leia o :ref:`" +"guia de estilo `." + +#: ../source/contribute.rst:24 +msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." +msgstr "" +"Ao contribuir para o |PyPUG|, espera-se que você siga o `Código de Conduta`" +"__ da PSF." + +#: ../source/contribute.rst:31 +msgid "Documentation types" +msgstr "Tipos de documentação" + +#: ../source/contribute.rst:33 +msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." +msgstr "" +"Este projeto consiste em quatro tipos de documentação distintos com " +"finalidades específicas. Ao propor novas adições ao projeto, escolha o tipo " +"de documentação apropriado." + +#: ../source/contribute.rst:38 +#: ../source/tutorials/index.rst:2 +msgid "Tutorials" +msgstr "Tutoriais" + +#: ../source/contribute.rst:40 +msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." +msgstr "" +"Os tutoriais são focados em ensinar ao leitor novos conceitos através da " +"realização de um objetivo. Eles são guias passo a passo opinativos. Eles não " +"incluem avisos ou informações estranhas. `Exemplo de documento no estilo " +"tutorial`_." + +#: ../source/contribute.rst:47 +#: ../source/guides/index.rst:2 +msgid "Guides" +msgstr "Guias" + +#: ../source/contribute.rst:49 +msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." +msgstr "" +"Os guias são focados em realizar uma tarefa específica e podem assumir algum " +"nível de conhecimento pré-requisito. Eles são semelhantes aos tutoriais, mas " +"têm um foco estreito e claro e podem fornecer muitas advertências e " +"informações adicionais, conforme necessário. Eles também podem discutir " +"várias abordagens para realizar a tarefa. :doc:`Exemplo de documento no " +"estilo guia `." + +#: ../source/contribute.rst:56 +#: ../source/discussions/index.rst:2 +msgid "Discussions" +msgstr "Discussões" + +#: ../source/contribute.rst:58 +msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." +msgstr "" +"As discussões são focadas em compreensão e informação. Eles exploram um " +"tópico específico sem um objetivo específico em mente. :doc:`Exemplo de " +"documento no estilo discussão `." + +#: ../source/contribute.rst:63 +msgid "Specifications" +msgstr "Especificações" + +#: ../source/contribute.rst:65 +msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." +msgstr "" +"As especificações são documentação de referência focada na documentação " +"abrangente de uma interface acordada para interoperabilidade entre " +"ferramentas de empacotamento. :doc:`Exemplo de documento no estilo " +"especificação `." + +#: ../source/contribute.rst:73 +msgid "Building the guide locally" +msgstr "Construindo o guia localmente" + +#: ../source/contribute.rst:75 +msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" +msgstr "" +"Embora não seja necessário contribuir, pode ser útil construir este guia " +"localmente para testar suas alterações. Para construir este guia localmente, " +"você precisará:" + +#: ../source/contribute.rst:79 +msgid "`Nox `_. You can install or upgrade nox using ``pip``::" +msgstr "" +"`Nox `_. Você pode instalar ou " +"atualizar o nox usando o ``pip``::" + +#: ../source/contribute.rst:84 +msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." +msgstr "" +"Python 3.6. Nossos scripts de construção são projetados para funcionar " +"apenas com Python 3.6. Consulte o `Guia do mochileiro para as instruções de " +"instalação do Python`_ para instalar o Python 3.6 em seu sistema operacional." + +#: ../source/contribute.rst:91 +msgid "To build the guide, run the following bash command in the source folder::" +msgstr "" +"Para construir o guia, execute o seguinte comando bash na pasta do código-" +"fonte::" + +#: ../source/contribute.rst:95 +msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." +msgstr "" +"Após a conclusão do processo, você pode encontrar a saída HTML no diretório " +"``./build/html``. Você pode abrir o arquivo ``index.html`` para ver o guia " +"no navegador web, mas é recomendado servir o guia usando um servidor HTTP." + +#: ../source/contribute.rst:100 +msgid "You can build the guide and serve it via an HTTP server using the following command::" +msgstr "" +"Você pode construir o guia e exibi-lo por meio de um servidor HTTP usando o " +"seguinte comando::" + +#: ../source/contribute.rst:105 +msgid "The guide will be browsable via http://localhost:8000." +msgstr "O guia poderá ser navegado em http://localhost:8000." + +#: ../source/contribute.rst:109 +msgid "Where the guide is deployed" +msgstr "Onde o guia é disponibilizado" + +#: ../source/contribute.rst:111 +msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." +msgstr "" +"O guia é disponibilizado via ReadTheDocs e a configuração está em " +"https://readthedocs.org/projects/python-packaging-user-guide/.. É servido a " +"partir de um domínio personalizado e guardado por Fast.ly." + +#: ../source/contribute.rst:117 +msgid "Style guide" +msgstr "Guia de estilo" + +#: ../source/contribute.rst:119 +msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." +msgstr "" +"Este guia de estilo contém recomendações de como você deve escrever o |PyPUG|" +". Antes de começar a escrever, revise-o. Seguindo o guia de estilo, suas " +"contribuições ajudarão a formar um todo coeso e tornar mais fácil para que " +"suas contribuições sejam aceitas no projeto." + +#: ../source/contribute.rst:126 +msgid "Purpose" +msgstr "Propósito" + +#: ../source/contribute.rst:128 +msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." +msgstr "" +"O objetivo do |PyPUG| é ser o recurso autorizado sobre como empacotar, " +"publicar e instalar projetos Python usando as ferramentas atuais." + +#: ../source/contribute.rst:133 +msgid "Scope" +msgstr "Escopo" + +#: ../source/contribute.rst:135 +msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." +msgstr "" +"O guia destina-se a responder a perguntas e resolver problemas com " +"recomendações precisas e focadas." + +#: ../source/contribute.rst:138 +msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." +msgstr "" +"O guia não pretende ser abrangente e não pretende substituir a documentação " +"de projetos individuais. Por exemplo, pip tem dezenas de comandos, opções e " +"configurações. A documentação do pip descreve cada um deles em detalhes, " +"enquanto este guia descreve apenas as partes do pip que são necessárias para " +"concluir as tarefas específicas descritas neste guia." + +#: ../source/contribute.rst:146 +msgid "Audience" +msgstr "Público-alvo" + +#: ../source/contribute.rst:148 +msgid "The audience of this guide is anyone who uses Python with packages." +msgstr "O público-alvo deste guia é qualquer pessoa que use Python com pacotes." + +#: ../source/contribute.rst:150 +msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." +msgstr "" +"Não se esqueça de que a comunidade Python é grande e acolhedora. Os leitores " +"podem não compartilhar sua idade, sexo, educação, cultura e muito mais, mas " +"eles merecem aprender sobre empacotamento tanto quanto você." + +#: ../source/contribute.rst:154 +msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." +msgstr "" +"Em particular, tenha em mente que nem todas as pessoas que usam Python se " +"consideram programadores. O público deste guia inclui astrônomos, pintores " +"ou estudantes, bem como desenvolvedores de software profissionais." + +#: ../source/contribute.rst:160 +msgid "Voice and tone" +msgstr "Voz e tom" + +#: ../source/contribute.rst:162 +msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." +msgstr "" +"Ao escrever este guia, esforce-se para escrever com uma voz que seja " +"acessível e humilde, mesmo que você tenha todas as respostas." + +#: ../source/contribute.rst:165 +msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." +msgstr "" +"Imagine que você está trabalhando em um projeto Python com alguém que sabe " +"ser inteligente e habilidoso. Você gosta de trabalhar com eles e eles gostam " +"de trabalhar com você. Essa pessoa fez uma pergunta e você sabe a resposta. " +"Como você responde? *É assim* que você deve escrever este guia." + +#: ../source/contribute.rst:170 +msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." +msgstr "" +"Aqui está uma verificação rápida: tente ler em voz alta para ter uma noção " +"da voz e do tom de sua escrita. Parece algo que você diria ou parece que " +"você está encenando um papel ou fazendo um discurso? Sinta-se à vontade para " +"usar contrações e não se preocupe em seguir regras gramaticais complicadas. " +"Você tem permissão para encerrar uma frase em uma preposição, se for assim " +"que deseja encerrá-la." + +#: ../source/contribute.rst:177 +msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." +msgstr "" +"Ao escrever o guia, ajuste seu tom de acordo com a seriedade e a dificuldade " +"do tópico. Se você estiver escrevendo um tutorial introdutório, não há " +"problema em fazer uma piada, mas se estiver cobrindo uma recomendação de " +"segurança sensível, convém evitar piadas completamente." + +#: ../source/contribute.rst:184 +msgid "Conventions and mechanics" +msgstr "Convenções e mecânicas" + +#: ../source/contribute.rst:192 +msgid "**Write to the reader**" +msgstr "**Escreva para o leitor**" + +#: ../source/contribute.rst:187 +msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." +msgstr "" +"Ao dar recomendações ou etapas a serem seguidas, dirija-se ao leitor como " +"*você* ou use o humor imperativo." + +#: ../source/contribute.rst:0 +msgid "Wrong: To install it, the user runs…" +msgstr "Errado: Para instalá-lo, o usuário executa…" + +#: ../source/contribute.rst:0 +msgid "Right: You can install it by running…" +msgstr "Certo: Você pode instalá-lo executando…" + +#: ../source/contribute.rst:0 +msgid "Right: To install it, run…" +msgstr "Certo: Para instalá-lo, execute…" + +#: ../source/contribute.rst:198 +msgid "**State assumptions**" +msgstr "**Assuma pressupostos**" + +#: ../source/contribute.rst:195 +msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." +msgstr "" +"Evite fazer suposições não declaradas. Ler na web significa que qualquer " +"página do guia pode ser a primeira página do guia que o leitor vê. Se você " +"vai fazer suposições, diga quais suposições você vai fazer." + +#: ../source/contribute.rst:203 +msgid "**Cross-reference generously**" +msgstr "**Faça uso generoso de referência cruzada**" + +#: ../source/contribute.rst:201 +msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." +msgstr "" +"Na primeira vez que você mencionar uma ferramenta ou prática, coloque um " +"link para a parte do guia que a cobre ou para um documento relevante em " +"outro lugar. Economize uma pesquisa ao leitor." + +#: ../source/contribute.rst:213 +msgid "**Respect naming practices**" +msgstr "**Respeite as práticas de nomenclatura**" + +#: ../source/contribute.rst:206 +msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." +msgstr "" +"Ao nomear ferramentas, sites, pessoas e outros nomes próprios, use a " +"capitalização de sua preferência." + +#: ../source/contribute.rst:0 +msgid "Wrong: Pip uses…" +msgstr "Errado: Pip usa…" + +#: ../source/contribute.rst:0 +msgid "Right: pip uses…" +msgstr "Certo: pip usa…" + +#: ../source/contribute.rst:0 +msgid "Wrong: …hosted on github." +msgstr "Errado: …hospedado no github." + +#: ../source/contribute.rst:0 +msgid "Right: …hosted on GitHub." +msgstr "Certo: …hospedado no GitHub." + +#: ../source/contribute.rst:222 +msgid "**Use a gender-neutral style**" +msgstr "**Use um estilo de gênero neutro**" + +#: ../source/contribute.rst:216 +msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." +msgstr "" +"Frequentemente, você se dirigirá ao leitor diretamente com *you*, *your* e " +"*yours*. Caso contrário, use pronomes de gênero neutro *they*, *their* e " +"*theirs* ou evite os pronomes completamente." + +#: ../source/contribute.rst:0 +msgid "Wrong: A maintainer uploads the file. Then he…" +msgstr "Errado: A maintainer uploads the file. Then he…" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then they…" +msgstr "Certo: A maintainer uploads the file. Then they…" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then the maintainer…" +msgstr "Certo: A maintainer uploads the file. Then the maintainer…" + +#: ../source/contribute.rst:234 +msgid "**Headings**" +msgstr "**Títulos**" + +#: ../source/contribute.rst:225 +msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." +msgstr "" +"Escreva títulos que usem palavras que o leitor esteja procurando. Uma boa " +"maneira de fazer isso é fazer com que o cabeçalho responda a uma pergunta " +"implícita. Por exemplo, um leitor pode querer saber *How do I install " +"MyLibrary?*, de forma que um bom título pode ser *Install MyLibrary*." + +#: ../source/contribute.rst:230 +msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." +msgstr "" +"Nos cabeçalhos das seções, use letras maiúsculas e minúsculas. Em outras " +"palavras, escreva os cabeçalhos da mesma forma que escreveria uma frase " +"típica." + +#: ../source/contribute.rst:0 +msgid "Wrong: Things You Should Know About Python" +msgstr "Errado: Things You Should Know About Python" + +#: ../source/contribute.rst:0 +msgid "Right: Things you should know about Python" +msgstr "Certo: Things you should know about Python" + +#: ../source/contribute.rst:237 +msgid "**Numbers**" +msgstr "**Números**" + +#: ../source/contribute.rst:237 +msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." +msgstr "" +"No corpo do texto, escreva os números de um a nove como palavras. Para " +"outros números ou números nas tabelas, use numerais." + +#: ../source/discussions/deploying-python-applications.rst:4 +msgid "Deploying Python applications" +msgstr "Fazendo deploy de aplicações Python" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Page Status" +msgstr "Status da página" + +#: ../source/discussions/deploying-python-applications.rst:6 +#: ../source/guides/index-mirrors-and-caches.rst:7 +#: ../source/guides/installing-using-linux-tools.rst:7 +#: ../source/guides/packaging-binary-extensions.rst:7 +#: ../source/guides/supporting-multiple-python-versions.rst:7 +#: ../source/guides/supporting-windows-using-appveyor.rst:5 +msgid "Incomplete" +msgstr "Incompleta" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Last Reviewed" +msgstr "Última revisão" + +#: ../source/discussions/deploying-python-applications.rst:7 +msgid "2014-11-11" +msgstr "2014-11-11" + +#: ../source/discussions/deploying-python-applications.rst:11 +#: ../source/discussions/install-requires-vs-requirements.rst:9 +#: ../source/guides/analyzing-pypi-package-downloads.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:22 +#: ../source/guides/index-mirrors-and-caches.rst:12 +#: ../source/guides/installing-scientific-packages.rst:9 +#: ../source/guides/packaging-binary-extensions.rst:17 +#: ../source/guides/supporting-multiple-python-versions.rst:12 +#: ../source/guides/supporting-windows-using-appveyor.rst:15 +#: ../source/overview.rst:23 +#: ../source/specifications/core-metadata.rst:38 +#: ../source/specifications/direct-url.rst:14 +#: ../source/tutorials/installing-packages.rst:23 +msgid "Contents" +msgstr "Conteúdo" + +#: ../source/discussions/deploying-python-applications.rst:14 +msgid "Overview" +msgstr "Visão geral" + +#: ../source/discussions/deploying-python-applications.rst:18 +msgid "Supporting multiple hardware platforms" +msgstr "Oferecendo suporte a várias plataformas de hardware" + +#: ../source/discussions/deploying-python-applications.rst:40 +msgid "OS packaging & installers" +msgstr "Empacotamento de sistema operacional e instaladores" + +#: ../source/discussions/deploying-python-applications.rst:52 +msgid "Windows" +msgstr "Windows" + +#: ../source/discussions/deploying-python-applications.rst:61 +msgid "Pynsist" +msgstr "Pynsist" + +#: ../source/discussions/deploying-python-applications.rst:63 +msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." +msgstr "" +"`Pynsist `__ é uma ferramenta que agrupa " +"programas Python junto com o interpretador Python em um único instalador " +"baseado em NSIS. Na maioria dos casos, o empacotamento requer apenas que o " +"usuário escolha uma versão do interpretador Python e declare as dependências " +"do programa. A ferramenta baixa o interpretador Python especificado para " +"Windows e o empacota com todas as dependências em um único instalador " +"executável do Windows." + +#: ../source/discussions/deploying-python-applications.rst:70 +msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." +msgstr "" +"O programa instalado pode ser iniciado a partir de um atalho que o " +"instalador adiciona ao menu iniciar. Ele usa um interpretador Python " +"instalado em seu diretório de aplicação, independente de qualquer outra " +"instalação Python no computador." + +#: ../source/discussions/deploying-python-applications.rst:74 +msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." +msgstr "" +"Uma grande vantagem do Pynsist é que os pacotes do Windows podem ser " +"construídos no Linux. Existem vários exemplos para diferentes tipos de " +"programas (console, GUI) na `documentação `" +"__. A ferramenta é lançada sob a licença do MIT." + +#: ../source/discussions/deploying-python-applications.rst:80 +msgid "Application bundles" +msgstr "Pacotes de aplicações" + +#: ../source/discussions/deploying-python-applications.rst:91 +msgid "Configuration management" +msgstr "Gerenciamento de configuração" + +#: ../source/discussions/index.rst:4 +msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." +msgstr "" +"**Discussões ** têm como objetivo fornecer informações abrangentes sobre um " +"tópico específico. Se você está apenas tentando fazer as coisas, veja :doc:`/" +"guides/index`." + +#: ../source/discussions/install-requires-vs-requirements.rst:5 +msgid "install_requires vs requirements files" +msgstr "install_requires vs arquivos requirements" + +#: ../source/discussions/install-requires-vs-requirements.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:382 +msgid "install_requires" +msgstr "install_requires" + +#: ../source/discussions/install-requires-vs-requirements.rst:14 +msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" +"``install_requires`` é uma palavra-chave do :file:`setup.py` do " +":ref:`setuptools` que deve ser usada para especificar o que um projeto " +"**minimamente** precisa para rodar corretamente. Quando o projeto é " +"instalado por :ref:`pip`, esta é a especificação que é usada para instalar " +"suas dependências." + +#: ../source/discussions/install-requires-vs-requirements.rst:19 +msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" +msgstr "" +"Por exemplo, se o projeto requer A e B, seu ``install_requires`` seria assim:" + +#: ../source/discussions/install-requires-vs-requirements.rst:29 +msgid "Additionally, it's best practice to indicate any known lower or upper bounds." +msgstr "" +"Além disso, é uma prática recomendada indicar qualquer limite inferior ou " +"superior conhecido." + +#: ../source/discussions/install-requires-vs-requirements.rst:31 +msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" +msgstr "" +"Por exemplo, pode-se saber que seu projeto requer pelo menos v1 de \"A\" e " +"v2 de \"B\", então seria assim:" + +#: ../source/discussions/install-requires-vs-requirements.rst:41 +msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" +msgstr "" +"Também pode ser sabido que o projeto A segue versionamento semântico, e que " +"a v2 de \"A\" irá indicar uma quebra na compatibilidade, então faz sentido " +"não permitir a v2:" + +#: ../source/discussions/install-requires-vs-requirements.rst:51 +msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." +msgstr "" +"Não é considerada a melhor prática usar ``install_requires`` para fixar " +"dependências em versões específicas, ou para especificar subdependências (ou " +"seja, dependências de suas dependências). Isso é excessivamente restritivo e " +"evita que o usuário obtenha o benefício de atualizações de dependência." + +#: ../source/discussions/install-requires-vs-requirements.rst:56 +msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" +msgstr "" +"Por último, é importante entender que ``install_requires`` é uma lista de " +"requisitos \"abstratos\", ou seja, apenas nomes e restrições de versão que " +"não determinam de onde as dependências serão preenchidas (ou seja, de qual " +"índice ou fonte). O local (ou seja, como eles devem ser feitos de \"concreto" +"\") deve ser determinado no momento da instalação usando as opções :ref:`pip`" +". [1]_" + +#: ../source/discussions/install-requires-vs-requirements.rst:64 +#: ../source/tutorials/installing-packages.rst:460 +msgid "Requirements files" +msgstr "Arquivos requirements" + +#: ../source/discussions/install-requires-vs-requirements.rst:66 +msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." +msgstr "" +":ref:`Arquivos requirements ` descritos de forma " +"mais simples, são apenas uma lista de argumentos :ref:`pip:pip install` " +"colocados em um arquivo." + +#: ../source/discussions/install-requires-vs-requirements.rst:69 +msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." +msgstr "" +"Considerando que ``install_requires`` define as dependências para um único " +"projeto, :ref:`arquivos requirements ` são " +"frequentemente usados para definir os requisitos para um ambiente Python " +"completo." + +#: ../source/discussions/install-requires-vs-requirements.rst:73 +msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." +msgstr "" +"Considerando que os requisitos de `` install_requires`` são mínimos, os " +"arquivos de requisitos frequentemente contêm uma lista exaustiva de versões " +"fixadas com o propósito de alcançar :ref:`instalações repetíveis " +"` de um ambiente completo." + +#: ../source/discussions/install-requires-vs-requirements.rst:78 +msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" +msgstr "" +"Considerando que os requisitos de ``install_requires`` são \"abstratos\", ou " +"seja, não estão associados a nenhum índice em particular, os arquivos " +"requirements geralmente contêm opções de pip como ``--index-url`` ou " +"``--find-links`` para fazer requisitos \"concreto \", isto é, associado a um " +"determinado índice ou diretório de pacotes. [1]_" + +#: ../source/discussions/install-requires-vs-requirements.rst:84 +msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." +msgstr "" +"Enquanto os metadados ``install_requires`` são automaticamente analisados " +"pelo pip durante uma instalação, os arquivos de requisitos não são, e são " +"usados apenas quando um usuário os instala especificamente usando ``python -" +"m pip install -r``." + +#: ../source/discussions/install-requires-vs-requirements.rst:90 +msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." +msgstr "" +"Para obter mais informações sobre os requisitos \"abstratos\" vs \"concretos" +"\", consulte https://caremad.io/2013/07/setup-vs-requirement/." + +#: ../source/discussions/pip-vs-easy-install.rst:6 +msgid "pip vs easy_install" +msgstr "pip vs easy_install" + +#: ../source/discussions/pip-vs-easy-install.rst:9 +msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:14 +msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:22 +msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**pip**" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**easy_install**" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +msgid "Installs from :term:`Wheels `" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Yes" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:30 +#: ../source/discussions/pip-vs-easy-install.rst:32 +#: ../source/discussions/pip-vs-easy-install.rst:35 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:51 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "No" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Uninstall Packages" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Yes (``python -m pip uninstall``)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Dependency Overrides" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Yes (:ref:`Requirements Files `)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "List Installed Packages" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:38 +msgid ":pep:`438` Support" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Installation format" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "'Flat' packages with :file:`egg-info` metadata." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Encapsulated Egg format" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:44 +msgid "sys.path modification" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:48 +msgid "Installs from :term:`Eggs `" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "`pylauncher support`_" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "Yes [1]_" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:54 +msgid ":ref:`Multi-version Installs`" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Exclude scripts during install" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "per project index" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Only in virtualenv" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Yes, via setup.cfg" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:68 +msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:5 +msgid "Wheel vs Egg" +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:7 +msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:11 +msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:14 +msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:17 +msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:20 +msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:22 +msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:26 +msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:31 +msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:34 +msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:38 +msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:41 +msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:47 +msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." +msgstr "" + +#: ../source/glossary.rst:3 +msgid "Glossary" +msgstr "" + +#: ../source/glossary.rst:8 +msgid "Binary Distribution" +msgstr "" + +#: ../source/glossary.rst:11 +msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." +msgstr "" + +#: ../source/glossary.rst:14 +msgid "Built Distribution" +msgstr "" + +#: ../source/glossary.rst:17 +msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." +msgstr "" + +#: ../source/glossary.rst:26 +msgid "Distribution Package" +msgstr "" + +#: ../source/glossary.rst:29 +msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." +msgstr "" + +#: ../source/glossary.rst:34 +msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." +msgstr "" + +#: ../source/glossary.rst:41 +msgid "Egg" +msgstr "" + +#: ../source/glossary.rst:44 +msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" +msgstr "" + +#: ../source/glossary.rst:49 +msgid "Extension Module" +msgstr "" + +#: ../source/glossary.rst:52 +msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." +msgstr "" + +#: ../source/glossary.rst:59 +msgid "Known Good Set (KGS)" +msgstr "" + +#: ../source/glossary.rst:62 +msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." +msgstr "" + +#: ../source/glossary.rst:68 +msgid "Import Package" +msgstr "" + +#: ../source/glossary.rst:71 +msgid "A Python module which can contain other modules or recursively, other packages." +msgstr "" + +#: ../source/glossary.rst:74 +msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." +msgstr "" + +#: ../source/glossary.rst:78 +msgid "Module" +msgstr "" + +#: ../source/glossary.rst:81 +msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." +msgstr "" + +#: ../source/glossary.rst:84 +msgid "Package Index" +msgstr "" + +#: ../source/glossary.rst:87 +msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." +msgstr "" + +#: ../source/glossary.rst:90 +msgid "Per Project Index" +msgstr "" + +#: ../source/glossary.rst:93 +msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." +msgstr "" + +#: ../source/glossary.rst:97 +msgid "Project" +msgstr "" + +#: ../source/glossary.rst:100 +msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." +msgstr "" + +#: ../source/glossary.rst:104 +msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." +msgstr "" + +#: ../source/glossary.rst:110 +msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." +msgstr "" + +#: ../source/glossary.rst:115 +msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." +msgstr "" + +#: ../source/glossary.rst:121 +msgid "Pure Module" +msgstr "" + +#: ../source/glossary.rst:124 +msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." +msgstr "" + +#: ../source/glossary.rst:127 +msgid "Python Packaging Authority (PyPA)" +msgstr "" + +#: ../source/glossary.rst:130 +msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." +msgstr "" + +#: ../source/glossary.rst:139 +msgid "Python Package Index (PyPI)" +msgstr "" + +#: ../source/glossary.rst:142 +msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." +msgstr "" + +#: ../source/glossary.rst:145 +msgid "pypi.org" +msgstr "" + +#: ../source/glossary.rst:148 +msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." +msgstr "" + +#: ../source/glossary.rst:152 +msgid "pyproject.toml" +msgstr "" + +#: ../source/glossary.rst:155 +msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." +msgstr "" + +#: ../source/glossary.rst:157 +msgid "Release" +msgstr "" + +#: ../source/glossary.rst:160 +msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." +msgstr "" + +#: ../source/glossary.rst:163 +msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." +msgstr "" + +#: ../source/glossary.rst:168 +msgid "Requirement" +msgstr "" + +#: ../source/glossary.rst:171 +msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." +msgstr "" + +#: ../source/glossary.rst:177 +msgid "Requirement Specifier" +msgstr "" + +#: ../source/glossary.rst:180 +msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" +msgstr "" + +#: ../source/glossary.rst:187 +msgid "Requirements File" +msgstr "" + +#: ../source/glossary.rst:190 +msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." +msgstr "" + +#: ../source/glossary.rst:194 +#: ../source/guides/distributing-packages-using-setuptools.rst:56 +msgid "setup.py" +msgstr "" + +#: ../source/glossary.rst:195 +#: ../source/guides/distributing-packages-using-setuptools.rst:77 +msgid "setup.cfg" +msgstr "" + +#: ../source/glossary.rst:198 +msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." +msgstr "" + +#: ../source/glossary.rst:201 +msgid "Source Archive" +msgstr "" + +#: ../source/glossary.rst:204 +msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:208 +msgid "Source Distribution (or \"sdist\")" +msgstr "" + +#: ../source/glossary.rst:211 +msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:216 +msgid "System Package" +msgstr "" + +#: ../source/glossary.rst:219 +msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." +msgstr "" + +#: ../source/glossary.rst:222 +msgid "Version Specifier" +msgstr "" + +#: ../source/glossary.rst:225 +msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." +msgstr "" + +#: ../source/glossary.rst:231 +msgid "Virtual Environment" +msgstr "" + +#: ../source/glossary.rst:234 +msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/glossary.rst:238 +msgid "Wheel" +msgstr "" + +#: ../source/glossary.rst:241 +msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." +msgstr "" + +#: ../source/glossary.rst:244 +msgid "Working Set" +msgstr "" + +#: ../source/glossary.rst:247 +msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:3 +msgid "Analyzing PyPI package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:5 +msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:15 +#: ../source/guides/supporting-windows-using-appveyor.rst:18 +msgid "Background" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:17 +msgid "PyPI does not display download statistics for a number of reasons: [#]_" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:19 +msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:24 +msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:27 +msgid "``pip``'s download cache (lowers download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:28 +msgid "Internal or unofficial mirrors (can both raise or lower download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:29 +msgid "Packages not hosted on PyPI (for comparisons sake)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:30 +msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:32 +msgid "Known historical data quality issues (lowers download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:34 +msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:38 +msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:43 +msgid "Public dataset" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:45 +msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:50 +msgid "Getting set up" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:52 +msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:58 +msgid "Navigate to the `BigQuery web UI`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:59 +msgid "Create a new project." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:60 +msgid "Enable the `BigQuery API `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:63 +msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:69 +msgid "Data schema" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:71 +msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +msgid "Column" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/guides/using-manifest-in.rst:67 +#: ../source/specifications/core-metadata.rst:185 +msgid "Description" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/specifications/direct-url.rst:226 +msgid "Examples" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "timestamp" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "Date and time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "``2020-03-09 00:33:03 UTC``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "file.project" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "Project name" +msgstr "Nome do projeto" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "``pipenv``, ``nose``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "file.version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "Package version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "``0.1.6``, ``1.4.2``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "details.installer.name" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "Installer" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "pip, `bandersnatch`_" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "details.python" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "Python version" +msgstr "Versão do python" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "``2.7.12``, ``3.6.4``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:93 +msgid "Useful queries" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:95 +msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:97 +msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:102 +msgid "Counting package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:104 +msgid "The following query counts the total number of downloads for the project \"pytest\"." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:119 +#: ../source/guides/analyzing-pypi-package-downloads.rst:140 +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "num_downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:121 +msgid "26190085" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:124 +msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:142 +msgid "24334215" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:146 +msgid "Package downloads over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:148 +msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +msgid "month" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "1956741" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "2018-01-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2344692" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2017-12-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "1730398" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "2017-11-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2047310" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2017-10-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "1744443" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "2017-09-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "1916952" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "2017-08-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:184 +msgid "Python versions over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:186 +msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "python" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "3.7" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "18051328726" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "3.6" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "9635067203" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "3.8" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "7781904681" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "2.7" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "6381252241" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "null" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "2026630299" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "3.5" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "1894153540" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:221 +msgid "Caveats" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:223 +msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:231 +msgid "Additional tools" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:233 +msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:237 +msgid "``google-cloud-bigquery``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:239 +msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:267 +msgid "``pypinfo``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:269 +msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:273 +msgid "Install `pypinfo`_ using pip." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:279 +msgid "Usage:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:295 +msgid "``pandas-gbq``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:297 +msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:301 +#: ../source/specifications/binary-distribution-format.rst:459 +msgid "References" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:303 +msgid "`PyPI Download Counts deprecation email `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:304 +msgid "`PyPI BigQuery dataset announcement email `__" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:3 +msgid "Creating and discovering plugins" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:5 +msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:10 +msgid "There are three major approaches to doing automatic plugin discovery:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:12 +msgid "`Using naming convention`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:13 +msgid "`Using namespace packages`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:14 +msgid "`Using package metadata`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:18 +msgid "Using naming convention" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:20 +msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:38 +msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:48 +msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:59 +msgid "Using namespace packages" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:61 +msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:89 +msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:101 +msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:115 +msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:121 +msgid "Using package metadata" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:123 +msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:128 +msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:139 +msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:154 +msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:163 +msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:166 +msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:170 +msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:5 +msgid "Packaging and distributing projects" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:7 +msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:11 +msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:15 +msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:25 +msgid "Requirements for packaging and distributing" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:26 +msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:29 +msgid "Install \"twine\" [1]_:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:43 +msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:49 +msgid "Configuring your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:53 +msgid "Initial files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:58 +msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:63 +msgid ":file:`setup.py` serves two primary functions:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:65 +msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:71 +msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:79 +msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:86 +msgid "README.rst / README.md" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:88 +msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:95 +msgid "For an example, see `README.md `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:99 +msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:108 +msgid "MANIFEST.in" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:110 +msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:115 +msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:119 +msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:122 +msgid "LICENSE.txt" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:124 +msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:130 +msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:135 +msgid "" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:137 +msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:141 +msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:149 +msgid "setup() args" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:151 +msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:155 +msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:164 +msgid "name" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:170 +msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:174 +msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:176 +msgid "Start & end with an ASCII letter or digit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:178 +msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:190 +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "version" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:196 +msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:200 +msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:203 +msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:206 +msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:214 +msgid "description" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:222 +msgid "Give a short and long description for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:224 +msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:229 +msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:235 +msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:245 +msgid "url" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:252 +msgid "Give a homepage URL for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:256 +msgid "author" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:263 +msgid "Provide details about the author." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:267 +msgid "license" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:273 +msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:279 +msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:287 +msgid "classifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:316 +msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:319 +msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:327 +msgid "keywords" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:333 +msgid "List keywords that describe your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:337 +msgid "project_urls" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:349 +msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:355 +msgid "packages" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:361 +msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:370 +msgid "py_modules" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:376 +msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:388 +msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:392 +msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:398 +msgid "python_requires" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:400 +msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:407 +msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:412 +msgid "And so on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:416 +msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:422 +msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:431 +msgid "package_data" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:440 +msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:445 +msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:449 +msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:457 +msgid "data_files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:463 +msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:469 +msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:479 +msgid "For more information see the distutils section on `Installing Additional Files `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:484 +msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:491 +msgid "scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:493 +msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:500 +msgid "entry_points" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:509 +msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:512 +msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:516 +msgid "The most commonly used entry point is \"console_scripts\" (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:521 +msgid "console_scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:531 +msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:538 +msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:545 +msgid "Choosing a versioning scheme" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:548 +msgid "Standards compliance for interoperability" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:550 +msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:556 +msgid "Here are some examples of compliant version numbers::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:567 +msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:573 +msgid "Scheme choices" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:576 +msgid "Semantic versioning (preferred)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:578 +msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:582 +msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:585 +msgid "MAJOR version when they make incompatible API changes," +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:586 +msgid "MINOR version when they add functionality in a backwards-compatible manner, and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:587 +msgid "MAINTENANCE version when they make backwards-compatible bug fixes." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:589 +msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:594 +msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:598 +msgid "Date based versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:600 +msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:604 +msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:607 +msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:611 +msgid "Serial versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:613 +msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:616 +msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:621 +msgid "Hybrid schemes" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:623 +msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:629 +msgid "Pre-release versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:631 +msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:634 +msgid "zero or more dev releases (denoted with a \".devN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:635 +msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:636 +msgid "zero or more beta releases (denoted with a \".bN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:637 +msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:639 +msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:644 +msgid "Local version identifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:646 +msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:653 +msgid "A local version identifier takes the form ``+``. For example::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:661 +msgid "Working in \"development mode\"" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:663 +msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:667 +msgid "Assuming you're in the root of your project directory, then run:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:674 +msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:680 +msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:688 +msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:692 +msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:697 +msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:701 +msgid "Lastly, if you don't want to install any dependencies at all, you can run::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:706 +msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:713 +msgid "Packaging your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:715 +msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:720 +msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:737 +msgid "Source distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:739 +msgid "Minimally, you should create a :term:`Source Distribution `:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:755 +msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:763 +msgid "Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:765 +msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:770 +msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:773 +msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:776 +msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:785 +msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:792 +msgid "Pure Python Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:794 +msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:797 +#: ../source/guides/distributing-packages-using-setuptools.rst:826 +msgid "To build the wheel:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:811 +msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:815 +msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:821 +msgid "Platform Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:823 +msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:841 +msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:847 +msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:855 +msgid "Uploading your Project to PyPI" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:857 +msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:861 +msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:866 +msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:871 +msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:877 +msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:888 +msgid "Create an account" +msgstr "Criar uma conta" + +#: ../source/guides/distributing-packages-using-setuptools.rst:890 +msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:894 +msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:897 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:901 +msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:904 +msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:913 +msgid "**Be aware that this stores your token in plaintext.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:915 +#: ../source/guides/migrating-to-pypi-org.rst:70 +#: ../source/guides/migrating-to-pypi-org.rst:109 +#: ../source/guides/using-testpypi.rst:83 +msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:921 +msgid "Upload your distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:923 +msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:926 +msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:930 +msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:937 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:944 +#: ../source/tutorials/installing-packages.rst:663 +msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:950 +msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:5 +msgid "Dropping support for older Python versions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:7 +msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:9 +msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:12 +msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:14 +msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:17 +msgid "Requirements" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:19 +msgid "This workflow requires that:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:21 +msgid "The publisher is using the latest version of :ref:`setuptools`," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:22 +msgid "The latest version of :ref:`twine` is used to upload the package," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:23 +msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:26 +msgid "Dealing with the universal wheels" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:28 +msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:36 +msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:48 +msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:53 +msgid "Defining the Python version required" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:56 +msgid "1. Download the newest version of Setuptools" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:58 +msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:60 +msgid "Steps:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:74 +msgid "`setuptools` version should be above 24.0.0." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:77 +msgid "2. Specify the version ranges for supported Python distributions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:79 +msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:81 +#: ../source/specifications/core-metadata.rst:139 +#: ../source/specifications/core-metadata.rst:463 +#: ../source/specifications/core-metadata.rst:487 +#: ../source/specifications/core-metadata.rst:527 +#: ../source/specifications/core-metadata.rst:550 +#: ../source/specifications/core-metadata.rst:583 +#: ../source/specifications/core-metadata.rst:693 +#: ../source/specifications/core-metadata.rst:722 +msgid "Examples::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:86 +msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:101 +msgid "3. Validating the Metadata before publishing" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:103 +msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:105 +msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:108 +msgid "You can see the contents of the generated file like this::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:112 +msgid "Validate that the following is in place, before publishing the package:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:114 +msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:115 +msgid "The Requires-Python field is set and matches your specification in setup.py." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:118 +msgid "4. Using Twine to publish" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:120 +msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:122 +msgid "Make sure you are using the newest version of Twine, at least 1.9." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:125 +msgid "Dropping a Python release" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:127 +msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:129 +msgid "It must be done in this order for the automated fallback to work." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:131 +msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:133 +msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:5 +msgid "Hosting your own simple repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:8 +msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:13 +msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:29 +msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:35 +msgid "\"Manual\" repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:37 +msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:51 +msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:58 +msgid "For complete documentation of the simple repository protocol, see :pep:`503`." +msgstr "" + +#: ../source/guides/index.rst:8 +#: ../source/guides/index.rst:8 +msgid "Installing Packages:" +msgstr "" + +#: ../source/guides/index.rst:20 +#: ../source/guides/index.rst:20 +msgid "Building and Publishing Projects:" +msgstr "" + +#: ../source/guides/index.rst:38 +#: ../source/guides/index.rst:38 +msgid "Miscellaneous:" +msgstr "" + +#: ../source/guides/index.rst:4 +msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:5 +msgid "Package index mirrors and caches" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:8 +#: ../source/guides/supporting-multiple-python-versions.rst:8 +msgid "2014-12-24" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:14 +msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:17 +msgid "Three options are available in this area:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:19 +msgid "pip provides local caching options," +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:20 +msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:22 +msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:27 +msgid "Caching with pip" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:29 +msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:32 +msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:36 +msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:45 +msgid "Caching with devpi" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:47 +msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:55 +msgid "Complete mirror with bandersnatch" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:57 +msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:63 +msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:5 +msgid "Installing scientific packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:11 +msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:16 +msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:22 +msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:29 +msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:35 +msgid "Building from source" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:37 +msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:45 +msgid "Linux distribution packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:47 +msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:51 +msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:57 +msgid "Windows installers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:59 +msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:64 +msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:67 +msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:73 +msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:79 +msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:86 +msgid "macOS installers and package managers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:88 +msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:92 +msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:99 +msgid "SciPy distributions" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:101 +msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:105 +msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:109 +#: ../source/key_projects.rst:596 +msgid "Spack" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:110 +msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:119 +msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:128 +msgid "The conda cross-platform package manager" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:130 +msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:136 +msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 +msgid "Installing stand alone command line tools" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 +msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 +msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 +msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 +msgid "pipx only works with Python 3.6+." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 +msgid "``pipx`` is installed with ``pip``:" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 +msgid "You may need to restart your terminal for the path updates to take effect." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 +msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 +#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 +msgid "For example" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 +msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 +msgid "To upgrade or uninstall the package" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 +msgid "``pipx`` can be upgraded or uninstalled with pip" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 +msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 +msgid "To see the full list of commands ``pipx`` offers, run" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 +msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:5 +msgid "Installing pip/setuptools/wheel with Linux Package Managers" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:8 +msgid "2015-09-17" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:11 +msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:14 +msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:18 +msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:25 +msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:32 +msgid "Fedora" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:34 +msgid "Fedora 21:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:36 +#: ../source/guides/installing-using-linux-tools.rst:45 +#: ../source/guides/installing-using-linux-tools.rst:124 +#: ../source/guides/installing-using-linux-tools.rst:138 +#: ../source/guides/installing-using-linux-tools.rst:158 +msgid "Python 2::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:41 +msgid "Python 3: ``sudo yum install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:43 +msgid "Fedora 22:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:50 +msgid "Python 3: ``sudo dnf install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:53 +msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:63 +msgid "CentOS/RHEL" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:65 +msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:68 +msgid "To install pip and wheel for the system Python, there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:70 +msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:77 +msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:81 +msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:85 +msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:92 +msgid "To additionally upgrade setuptools, run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:97 +msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:101 +msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:104 +msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:106 +msgid "For CentOS, see here: https://www.softwarecollections.org/en/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:108 +msgid "Be aware that collections may not contain the most recent versions." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:110 +msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:116 +msgid "For example, for Python 3.4 on CentOS7/RHEL7::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:122 +msgid "openSUSE" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:129 +#: ../source/guides/installing-using-linux-tools.rst:143 +#: ../source/guides/installing-using-linux-tools.rst:162 +msgid "Python 3::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:135 +msgid "Debian/Ubuntu" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:150 +msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:156 +msgid "Arch Linux" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:168 +msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 +msgid "Installing packages using pip and virtual environments" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 +msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 +msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 +msgid "Installing pip" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 +msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 +msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 +msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 +msgid "Afterwards, you should have the newest pip installed in your user site:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 +msgid "The Python installers for Windows include pip. You should be able to access pip using:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 +msgid "You can make sure that pip is up-to-date by running:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 +msgid "Installing virtualenv" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 +msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 +msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 +msgid "Creating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 +msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 +msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 +msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 +msgid "venv will create a virtual Python installation in the ``env`` folder." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 +msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 +msgid "Activating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 +msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 +msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 +msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 +msgid "Leaving the virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 +msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 +msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 +msgid "Installing packages" +msgstr "Instalando pacotes" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 +msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 +msgid "pip should download requests and all of its dependencies and install them:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 +msgid "Installing specific versions" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 +msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 +msgid "To install the latest ``2.x`` release of requests:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 +msgid "To install pre-release versions of packages, use the ``--pre`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 +msgid "Installing extras" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 +msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 +msgid "Installing from source" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 +msgid "pip can install a package directly from source, for example:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 +msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 +msgid "Installing from version control systems" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 +msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 +msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 +#: ../source/tutorials/installing-packages.rst:569 +msgid "Installing from local archives" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 +msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 +msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 +msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 +msgid "Using other package indexes" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 +msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 +msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 +#: ../source/tutorials/installing-packages.rst:389 +msgid "Upgrading packages" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 +msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 +msgid "Using requirements files" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 +msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 +msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 +msgid "Freezing dependencies" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 +msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 +msgid "Which will output a list of package specifiers such as:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 +msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:2 +msgid "Making a PyPI-friendly README" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:4 +msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:9 +msgid "Creating a README file" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:11 +msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:13 +msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:16 +msgid "plain text" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:17 +msgid "`reStructuredText `_ (without Sphinx extensions)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:18 +msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:21 +msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:25 +msgid "Including your README in your package's metadata" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:27 +msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:33 +msgid ":ref:`description-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:34 +msgid ":ref:`description-content-type-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:36 +msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:39 +msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:45 +msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:60 +msgid "The minimum required versions of the respective tools are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:62 +msgid "``setuptools >= 38.6.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:63 +msgid "``wheel >= 0.31.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:64 +msgid "``twine >= 1.11.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:66 +msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:72 +msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:95 +msgid "Validating reStructuredText markup" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:97 +msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:100 +msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:105 +msgid "You can check your README for markup errors before uploading as follows:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:107 +msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:122 +msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:125 +msgid "Run ``twine check`` on the sdist and wheel::" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:129 +msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:4 +msgid "Migrating to PyPI.org" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:6 +msgid ":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``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:12 +msgid "Publishing releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:14 +msgid "``pypi.org`` is the default upload platform as of September 2016." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:16 +msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:22 +msgid "The default upload settings switched to ``pypi.org`` in the following versions:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:24 +msgid "``twine`` 1.8.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:25 +msgid "``setuptools`` 27.0.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:26 +msgid "Python 2.7.13 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:27 +msgid "Python 3.4.6 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:28 +msgid "Python 3.5.3 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:29 +msgid "Python 3.6.0 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:31 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:48 +msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:51 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:67 +msgid "(``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.)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:73 +msgid "Registering package names & metadata" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:75 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:79 +msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:84 +msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:89 +#: ../source/guides/using-testpypi.rst:5 +msgid "Using TestPyPI" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:91 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:113 +msgid "Registering new user accounts" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:115 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:121 +msgid "Browsing packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:123 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:130 +msgid "Downloading packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:132 +msgid "``pypi.org`` is the default host for downloading packages." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:135 +msgid "Managing published packages and releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:137 +msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:5 +msgid "Multi-version installs" +msgstr "" + +#: ../source/guides/multi-version-installs.rst:8 +msgid "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``)." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:13 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:31 +msgid "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 ``python -c ''`` to invoke the application's main entry point directly." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:38 +msgid "Refer to the `pkg_resources documentation `__ for more details." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:5 +msgid "Packaging binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:8 +msgid "2013-12-08" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:10 +msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:20 +msgid "An overview of binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:23 +msgid "Use cases" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:25 +msgid "The typical use cases for binary extensions break down into just three conventional categories:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:28 +msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:39 +msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:47 +msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:56 +msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:61 +msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:71 +msgid "Disadvantages" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:73 +msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:80 +msgid "This means that binary extensions:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:82 +msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:85 +msgid "may not be compatible with different builds of the CPython reference interpreter" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:88 +msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:91 +msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:96 +msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:101 +msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:108 +msgid "Alternatives to handcoded accelerator modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:110 +msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:115 +msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:122 +msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:132 +msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:141 +msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:150 +msgid "Alternatives to handcoded wrapper modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:152 +msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:158 +msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:162 +msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:168 +msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:175 +msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:181 +msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:185 +msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:189 +msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:203 +msgid "Alternatives for low level system access" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:205 +msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:213 +msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:222 +msgid "Implementing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:224 +msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:241 +msgid "Building binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:244 +msgid "Building extensions for multiple platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:246 +msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:256 +msgid "Binary extensions for Windows" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:258 +msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:263 +msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:269 +msgid "To set up a build environment for binary extensions, the steps are as follows:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:271 +msgid "For Python 2.7" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:273 +msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:276 +msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:278 +#: ../source/guides/packaging-binary-extensions.rst:288 +#: ../source/guides/packaging-binary-extensions.rst:295 +msgid "Done." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:280 +msgid "For Python 3.4" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:282 +msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:285 +msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:287 +msgid "Set DISTUTILS_USE_SDK=1" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:290 +msgid "For Python 3.5" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:292 +msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:297 +msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:301 +msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:305 +msgid "Binary extensions for Linux" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:307 +msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:313 +msgid "Binary extensions for macOS" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:315 +msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:325 +msgid "Publishing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:327 +msgid "For interim guidance on this topic, see the discussion in `this issue `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:343 +msgid "Additional resources" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:345 +msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:352 +msgid "Cross-platform wheel generation with scikit-build" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:354 +msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:362 +msgid "Introduction to C/C++ extension modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:364 +msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:367 +msgid "`What are (c)python extension modules? `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:368 +msgid "`Releasing the gil `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:369 +msgid "`Writing cpython extension modules using C++ `_" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:3 +msgid "Packaging namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:5 +msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:24 +msgid "And you use this package in your code like so::" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:29 +msgid "Then you can break these sub-packages into two separate distributions:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:46 +msgid "Each sub-package can now be separately installed, used, and versioned." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:48 +msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:58 +msgid "Creating a namespace package" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:60 +msgid "There are currently three different approaches to creating namespace packages:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:62 +msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:66 +msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:69 +msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:73 +msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:80 +msgid "Native namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:82 +msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:97 +msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:102 +msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:117 +msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:123 +msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:129 +msgid "pkgutil-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:131 +msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:136 +msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:148 +#: ../source/guides/packaging-namespace-packages.rst:194 +msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:155 +#: ../source/guides/packaging-namespace-packages.rst:201 +msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:160 +msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:171 +msgid "pkg_resources-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:173 +msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:182 +msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:206 +msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:216 +msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:223 +msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:237 +msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 +msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 +msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 +msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 +msgid "Saving credentials on GitHub" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 +msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 +msgid "Let's begin! 🚀" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 +msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 +msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 +msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 +msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 +msgid "Creating a workflow definition" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 +msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 +msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 +msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 +msgid "Defining a workflow job environment" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 +msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 +msgid "Checking out the project and building distributions" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 +msgid "Then, add the following under the ``build-n-publish`` section:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 +msgid "This will download your repository into the CI runner and then install and activate Python 3.7." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 +msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 +msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 +msgid "So add this to the steps list:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 +msgid "Publishing the distribution to PyPI and TestPyPI" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 +msgid "Finally, add the following steps at the end:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 +msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 +msgid "That's all, folks!" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 +msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:5 +msgid "Single-sourcing the package version" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:8 +msgid "There are many techniques to maintain a single source of truth for the version number of your project:" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:11 +msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:38 +msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:47 +msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:52 +msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:55 +msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:58 +msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:65 +msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:76 +msgid "Example using this technique: `warehouse `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:78 +msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:86 +msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:91 +msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:95 +msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:110 +msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:114 +msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:128 +msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:134 +msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:138 +msgid "Example using this technique: `setuptools `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:141 +msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:155 +msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:161 +msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:5 +msgid "Supporting multiple Python versions" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:37 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:43 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:49 +msgid "Automated testing and continuous integration" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:51 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:60 +msgid "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:" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:66 +msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:69 +msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:80 +msgid "Both `Travis CI`_ 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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:85 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:89 +msgid "Tools for single-source Python packages" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:91 +msgid "`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_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:100 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:107 +msgid "a Python 2 (by syntax) module in a Python 3 project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:108 +msgid "a Python 3 (by syntax) module in a *Python 2* project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:110 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:117 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:124 +msgid "What's in which Python?" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:126 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:3 +msgid "Supporting Windows using Appveyor" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:6 +msgid "2015-12-03" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:8 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:20 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:24 +msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:30 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:38 +msgid "Setting up" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:40 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:45 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:49 +msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:54 +msgid "Adding Appveyor support to your project" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:61 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:69 +msgid "appveyor.yml" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:75 +msgid "This file can be downloaded from `here `__." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:77 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:80 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:88 +msgid "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``)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:94 +msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:97 +msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:100 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:109 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:114 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:119 +msgid "Support script" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:121 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:126 +msgid "`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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:133 +msgid "You can simply download the batch file and include it in your project unchanged." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:137 +msgid "Access to the built wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:139 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:147 +msgid "Additional notes" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:150 +msgid "Testing with tox" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:152 +msgid "Many projects use the `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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:156 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:160 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:165 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:170 +msgid "``DISTUTILS_USE_SDK``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:171 +msgid "``MSSdk``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:172 +msgid "``INCLUDE``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:173 +msgid "``LIB``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:175 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:181 +msgid "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 Travis or 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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:188 +msgid "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``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:192 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:197 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:203 +msgid "Automatically uploading wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:205 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:210 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:216 +msgid "External dependencies" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:218 +msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:221 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:230 +msgid "Support scripts" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:232 +msgid "For reference, the SDK setup support script is listed here:" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:234 +msgid "``appveyor-sample/build.cmd``" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:5 +msgid "Tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:7 +msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:12 +msgid "Application dependency management" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:14 +msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:18 +msgid "When ``pipenv`` does not meet your use case, consider other tools like:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:20 +msgid ":ref:`pip`" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:22 +msgid "`pip-tools `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:24 +msgid "`Poetry `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:27 +msgid "Installation tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:29 +msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:34 +msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:37 +msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:40 +msgid ":ref:`buildout`: primarily focused on the web development community" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:42 +msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:47 +msgid "Packaging tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:49 +msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:52 +msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:56 +msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:61 +msgid "Publishing platform migration" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:63 +msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:67 +msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:72 +msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:77 +msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:82 +msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:88 +msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:93 +msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:102 +msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:107 +msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:5 +msgid "Including files in source distributions with ``MANIFEST.in``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:7 +msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:17 +msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:22 +msgid "How files are included in an sdist" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:24 +msgid "The following files are included in a source distribution by default:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:26 +msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:28 +msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:30 +msgid "scripts specified by the ``scripts`` ``setup()`` argument" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:31 +msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:33 +msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:35 +msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:37 +msgid "all files matching the pattern :file:`test/test*.py`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:38 +msgid ":file:`setup.py` (or whatever you called your setup script)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:39 +msgid ":file:`setup.cfg`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:40 +msgid ":file:`README`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:41 +msgid ":file:`README.txt`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:42 +msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:43 +msgid ":file:`README.md` (setuptools 36.4.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:44 +msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:45 +msgid ":file:`MANIFEST.in`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:47 +msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:52 +msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:60 +msgid ":file:`MANIFEST.in` commands" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:62 +msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:67 +msgid "Command" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid ":samp:`include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid "Add all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid ":samp:`exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid "Remove all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid ":samp:`global-include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid "Add all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid ":samp:`global-exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid "Remove all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid ":samp:`graft {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid "Add all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid ":samp:`prune {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid "Remove all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:79 +msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:87 +msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:91 +msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:95 +msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:101 +msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." +msgstr "" + +#: ../source/guides/using-testpypi.rst:7 +msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" +msgstr "" + +#: ../source/guides/using-testpypi.rst:13 +msgid "Registering your account" +msgstr "" + +#: ../source/guides/using-testpypi.rst:15 +msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." +msgstr "" + +#: ../source/guides/using-testpypi.rst:19 +msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." +msgstr "" + +#: ../source/guides/using-testpypi.rst:24 +msgid "Using TestPyPI with Twine" +msgstr "" + +#: ../source/guides/using-testpypi.rst:26 +msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:33 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/using-testpypi.rst:39 +msgid "Using TestPyPI with pip" +msgstr "" + +#: ../source/guides/using-testpypi.rst:41 +msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:56 +msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" +msgstr "" + +#: ../source/guides/using-testpypi.rst:73 +msgid "Setting up TestPyPI in :file:`.pypirc`" +msgstr "" + +#: ../source/guides/using-testpypi.rst:75 +msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" +msgstr "" + +#: ../source/index.rst:3 +#: ../source/key_projects.rst:181 +msgid "Python Packaging User Guide" +msgstr "Guia de Usuário para Empacotamento de Python" + +#: ../source/index.rst:5 +msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." +msgstr "" + +#: ../source/index.rst:5 +msgid "python, packaging, guide, tutorial" +msgstr "" + +#: ../source/index.rst:24 +msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." +msgstr "" + +#: ../source/index.rst:28 +msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" +msgstr "" + +#: ../source/index.rst:36 +msgid "Get started" +msgstr "" + +#: ../source/index.rst:38 +msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" +msgstr "" + +#: ../source/index.rst:41 +msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" +msgstr "" + +#: ../source/index.rst:43 +msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" +msgstr "" + +#: ../source/index.rst:45 +msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" +msgstr "" + +#: ../source/index.rst:47 +msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" +msgstr "" + +#: ../source/index.rst:52 +msgid "Learn more" +msgstr "" + +#: ../source/index.rst:54 +msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" +msgstr "" + +#: ../source/index.rst:56 +msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/index.rst:58 +msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." +msgstr "" + +#: ../source/index.rst:60 +msgid "The :doc:`specifications/index` section for packaging interoperability specifications." +msgstr "" + +#: ../source/index.rst:62 +msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." +msgstr "" + +#: ../source/key_projects.rst:6 +msgid "Project Summaries" +msgstr "" + +#: ../source/key_projects.rst:8 +msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." +msgstr "" + +#: ../source/key_projects.rst:14 +msgid "PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:19 +msgid "bandersnatch" +msgstr "" + +#: ../source/key_projects.rst:21 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:25 +msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." +msgstr "" + +#: ../source/key_projects.rst:35 +msgid "build" +msgstr "" + +#: ../source/key_projects.rst:37 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:42 +msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." +msgstr "" + +#: ../source/key_projects.rst:49 +msgid "cibuildwheel" +msgstr "" + +#: ../source/key_projects.rst:51 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" +msgstr "" + +#: ../source/key_projects.rst:58 +msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." +msgstr "" + +#: ../source/key_projects.rst:64 +msgid "distlib" +msgstr "" + +#: ../source/key_projects.rst:66 +msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:71 +msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." +msgstr "" + +#: ../source/key_projects.rst:80 +msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." +msgstr "" + +#: ../source/key_projects.rst:90 +msgid "packaging" +msgstr "" + +#: ../source/key_projects.rst:92 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:97 +msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." +msgstr "" + +#: ../source/key_projects.rst:99 +msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." +msgstr "" + +#: ../source/key_projects.rst:107 +msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." +msgstr "" + +#: ../source/key_projects.rst:119 +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "pip" +msgstr "" + +#: ../source/key_projects.rst:121 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:126 +msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." +msgstr "" + +#: ../source/key_projects.rst:129 +msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." +msgstr "" + +#: ../source/key_projects.rst:137 +msgid "Pipenv" +msgstr "" + +#: ../source/key_projects.rst:139 +msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:144 +msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." +msgstr "" + +#: ../source/key_projects.rst:148 +msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." +msgstr "" + +#: ../source/key_projects.rst:159 +msgid "Pipfile" +msgstr "" + +#: ../source/key_projects.rst:161 +msgid "`Source `__" +msgstr "" + +#: ../source/key_projects.rst:163 +msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." +msgstr "" + +#: ../source/key_projects.rst:170 +msgid "pipx" +msgstr "" + +#: ../source/key_projects.rst:172 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:176 +msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." +msgstr "" + +#: ../source/key_projects.rst:183 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:187 +msgid "This guide!" +msgstr "" + +#: ../source/key_projects.rst:192 +msgid "readme_renderer" +msgstr "" + +#: ../source/key_projects.rst:194 +msgid "`GitHub and docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:197 +msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." +msgstr "" + +#: ../source/key_projects.rst:208 +msgid "setuptools" +msgstr "" + +#: ../source/key_projects.rst:210 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:215 +msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." +msgstr "" + +#: ../source/key_projects.rst:220 +msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." +msgstr "" + +#: ../source/key_projects.rst:227 +msgid "trove-classifiers" +msgstr "" + +#: ../source/key_projects.rst:229 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:233 +msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." +msgstr "" + +#: ../source/key_projects.rst:239 +msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." +msgstr "" + +#: ../source/key_projects.rst:253 +msgid "twine" +msgstr "" + +#: ../source/key_projects.rst:255 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:260 +msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." +msgstr "" + +#: ../source/key_projects.rst:270 +#: ../source/overview.rst:415 +msgid "virtualenv" +msgstr "" + +#: ../source/key_projects.rst:272 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:277 +msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/key_projects.rst:290 +msgid "Warehouse" +msgstr "" + +#: ../source/key_projects.rst:292 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:296 +msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." +msgstr "" + +#: ../source/key_projects.rst:304 +msgid "wheel" +msgstr "" + +#: ../source/key_projects.rst:306 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:311 +msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." +msgstr "" + +#: ../source/key_projects.rst:315 +msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." +msgstr "" + +#: ../source/key_projects.rst:324 +msgid "Non-PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:329 +msgid "bento" +msgstr "" + +#: ../source/key_projects.rst:331 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:336 +msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." +msgstr "" + +#: ../source/key_projects.rst:344 +msgid "buildout" +msgstr "" + +#: ../source/key_projects.rst:346 +msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:351 +msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." +msgstr "" + +#: ../source/key_projects.rst:358 +msgid "conda" +msgstr "" + +#: ../source/key_projects.rst:360 +msgid "`Docs `__" +msgstr "" + +#: ../source/key_projects.rst:362 +msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." +msgstr "" + +#: ../source/key_projects.rst:369 +msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." +msgstr "" + +#: ../source/key_projects.rst:373 +msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." +msgstr "" + +#: ../source/key_projects.rst:386 +msgid "devpi" +msgstr "" + +#: ../source/key_projects.rst:388 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:392 +msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." +msgstr "" + +#: ../source/key_projects.rst:401 +msgid "flit" +msgstr "" + +#: ../source/key_projects.rst:403 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:407 +msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." +msgstr "" + +#: ../source/key_projects.rst:412 +msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." +msgstr "" + +#: ../source/key_projects.rst:422 +msgid "enscons" +msgstr "" + +#: ../source/key_projects.rst:424 +msgid "`Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:428 +msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." +msgstr "" + +#: ../source/key_projects.rst:443 +msgid "Hashdist" +msgstr "" + +#: ../source/key_projects.rst:445 +msgid "`Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:448 +msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." +msgstr "" + +#: ../source/key_projects.rst:460 +msgid "hatch" +msgstr "" + +#: ../source/key_projects.rst:462 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:465 +msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." +msgstr "" + +#: ../source/key_projects.rst:475 +msgid "multibuild" +msgstr "" + +#: ../source/key_projects.rst:477 +msgid "`GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:479 +msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." +msgstr "" + +#: ../source/key_projects.rst:485 +msgid "pex" +msgstr "" + +#: ../source/key_projects.rst:487 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:491 +msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." +msgstr "" + +#: ../source/key_projects.rst:500 +msgid "pip-tools" +msgstr "" + +#: ../source/key_projects.rst:502 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:505 +msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." +msgstr "" + +#: ../source/key_projects.rst:517 +msgid "piwheels" +msgstr "" + +#: ../source/key_projects.rst:519 +msgid "`Website `__ | `Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:523 +msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." +msgstr "" + +#: ../source/key_projects.rst:532 +msgid "poetry" +msgstr "" + +#: ../source/key_projects.rst:534 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:538 +msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." +msgstr "" + +#: ../source/key_projects.rst:548 +msgid "pypiserver" +msgstr "" + +#: ../source/key_projects.rst:550 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:554 +msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." +msgstr "" + +#: ../source/key_projects.rst:564 +msgid "scikit-build" +msgstr "" + +#: ../source/key_projects.rst:566 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:570 +msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." +msgstr "" + +#: ../source/key_projects.rst:582 +msgid "shiv" +msgstr "" + +#: ../source/key_projects.rst:584 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:588 +msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." +msgstr "" + +#: ../source/key_projects.rst:598 +msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" +msgstr "" + +#: ../source/key_projects.rst:603 +msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." +msgstr "" + +#: ../source/key_projects.rst:611 +msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." +msgstr "" + +#: ../source/key_projects.rst:617 +msgid "zest.releaser" +msgstr "" + +#: ../source/key_projects.rst:619 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:623 +msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." +msgstr "" + +#: ../source/key_projects.rst:630 +msgid "Standard Library Projects" +msgstr "" + +#: ../source/key_projects.rst:635 +msgid "ensurepip" +msgstr "" + +#: ../source/key_projects.rst:637 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:640 +msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." +msgstr "" + +#: ../source/key_projects.rst:649 +msgid "distutils" +msgstr "" + +#: ../source/key_projects.rst:651 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:654 +msgid "The original Python packaging system, added to the standard library in Python 2.0." +msgstr "" + +#: ../source/key_projects.rst:657 +msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." +msgstr "" + +#: ../source/key_projects.rst:670 +msgid "venv" +msgstr "" + +#: ../source/key_projects.rst:672 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:675 +msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/news.rst:2 +msgid "News" +msgstr "" + +#: ../source/news.rst:5 +msgid "September 2019" +msgstr "" + +#: ../source/news.rst:6 +msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" +msgstr "" + +#: ../source/news.rst:9 +msgid "August 2019" +msgstr "" + +#: ../source/news.rst:10 +msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" +msgstr "" + +#: ../source/news.rst:13 +msgid "July 2019" +msgstr "" + +#: ../source/news.rst:14 +msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" +msgstr "" + +#: ../source/news.rst:15 +msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" +msgstr "" + +#: ../source/news.rst:16 +msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" +msgstr "" + +#: ../source/news.rst:17 +msgid "Updated directory layout examples for consistency. (:pr:`611`)" +msgstr "" + +#: ../source/news.rst:18 +msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" +msgstr "" + +#: ../source/news.rst:21 +msgid "June 2019" +msgstr "" + +#: ../source/news.rst:22 +msgid "Fixed some typos. (:pr:`620`)" +msgstr "" + +#: ../source/news.rst:25 +msgid "May 2019" +msgstr "" + +#: ../source/news.rst:26 +msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" +msgstr "" + +#: ../source/news.rst:27 +msgid "Added a MANIFEST.in guide page. (:pr:`609`)" +msgstr "" + +#: ../source/news.rst:30 +msgid "April 2019" +msgstr "" + +#: ../source/news.rst:31 +msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" +msgstr "" + +#: ../source/news.rst:32 +msgid "Reduced emphasis on virtualenv. (:pr:`606`)" +msgstr "" + +#: ../source/news.rst:35 +msgid "March 2019" +msgstr "" + +#: ../source/news.rst:36 +msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" +msgstr "" + +#: ../source/news.rst:37 +msgid "Covered RTD details for contributing. (:pr:`600`)" +msgstr "" + +#: ../source/news.rst:40 +msgid "February 2019" +msgstr "" + +#: ../source/news.rst:41 +msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" +msgstr "" + +#: ../source/news.rst:42 +msgid "Added instructions to install Python CLI applications. (:pr:`594`)" +msgstr "" + +#: ../source/news.rst:45 +msgid "January 2019" +msgstr "" + +#: ../source/news.rst:46 +msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" +msgstr "" + +#: ../source/news.rst:47 +msgid "Updated Sphinx and Nox. (:pr:`591`)" +msgstr "" + +#: ../source/news.rst:48 +msgid "Referenced Twine from Python3. (:pr:`581`)" +msgstr "" + +#: ../source/news.rst:51 +msgid "December 2018" +msgstr "" + +#: ../source/news.rst:52 +msgid "No programmers in the office!" +msgstr "" + +#: ../source/news.rst:55 +msgid "November 2018" +msgstr "" + +#: ../source/news.rst:56 +msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" +msgstr "" + +#: ../source/news.rst:57 +msgid "Changed bumpversion to bump2version. (:pr:`572`)" +msgstr "" + +#: ../source/news.rst:58 +msgid "Added single-sourcing package version example. (:pr:`573`)" +msgstr "" + +#: ../source/news.rst:59 +msgid "Added a guide for creating documentation. (:pr:`568`)" +msgstr "" + +#: ../source/news.rst:62 +msgid "October 2018" +msgstr "" + +#: ../source/news.rst:63 +msgid "Updated Nox package name. (:pr:`566`)" +msgstr "" + +#: ../source/news.rst:64 +msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" +msgstr "" + +#: ../source/news.rst:67 +msgid "September 2018" +msgstr "" + +#: ../source/news.rst:68 +msgid "Added a section on checking RST markup. (:pr:`554`)" +msgstr "" + +#: ../source/news.rst:69 +msgid "Updated user installs page. (:pr:`558`)" +msgstr "" + +#: ../source/news.rst:70 +msgid "Updated Google BigQuery urls. (:pr:`556`)" +msgstr "" + +#: ../source/news.rst:71 +msgid "Replaced tar command with working command. (:pr:`552`)" +msgstr "" + +#: ../source/news.rst:72 +msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" +msgstr "" + +#: ../source/news.rst:75 +msgid "August 2018" +msgstr "" + +#: ../source/news.rst:76 +msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" +msgstr "" + +#: ../source/news.rst:77 +msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" +msgstr "" + +#: ../source/news.rst:78 +msgid "Updated Python version supported by virtualenv. (:pr:`538`)" +msgstr "" + +#: ../source/news.rst:79 +msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" +msgstr "" + +#: ../source/news.rst:82 +msgid "July 2018" +msgstr "" + +#: ../source/news.rst:84 +msgid "Improved binary extension docs. (:pr:`531`)" +msgstr "" + +#: ../source/news.rst:85 +msgid "Added scikit-build to key projects. (:pr:`530`)" +msgstr "" + +#: ../source/news.rst:88 +msgid "June 2018" +msgstr "" + +#: ../source/news.rst:90 +msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" +msgstr "" + +#: ../source/news.rst:91 +msgid "Updated Markdown descriptions explanation. (:pr:`522`)" +msgstr "" + +#: ../source/news.rst:94 +msgid "May 2018" +msgstr "" + +#: ../source/news.rst:96 +msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" +msgstr "" + +#: ../source/news.rst:97 +msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" +msgstr "" + +#: ../source/news.rst:98 +msgid "Simplified packaging tutorial. (:pr:`498`)" +msgstr "" + +#: ../source/news.rst:99 +msgid "Updated Windows users instructions for clarity. (:pr:`493`)" +msgstr "" + +#: ../source/news.rst:100 +msgid "Updated the license section description for completeness. (:pr:`492`)" +msgstr "" + +#: ../source/news.rst:101 +msgid "Added specification-style document to contributing section. (:pr:`489`)" +msgstr "" + +#: ../source/news.rst:102 +msgid "Added documentation types to contributing guide. (:pr:`485`)" +msgstr "" + +#: ../source/news.rst:105 +msgid "April 2018" +msgstr "" + +#: ../source/news.rst:107 +msgid "Added README guide. (:pr:`461`)" +msgstr "" + +#: ../source/news.rst:108 +msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" +msgstr "" + +#: ../source/news.rst:109 +msgid "Added instructions for Warehouse. (:pr:`471`)" +msgstr "" + +#: ../source/news.rst:110 +msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" +msgstr "" + +#: ../source/news.rst:111 +msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" +msgstr "" + +#: ../source/news.rst:112 +msgid "Added a guide for phasing out Python versions. (:pr:`459`)" +msgstr "" + +#: ../source/news.rst:113 +msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" +msgstr "" + +#: ../source/news.rst:116 +msgid "March 2018" +msgstr "" + +#: ../source/news.rst:118 +msgid "Updated \"installing scientific packages\". (:pr:`455`)" +msgstr "" + +#: ../source/news.rst:119 +msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" +msgstr "" + +#: ../source/news.rst:120 +msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" +msgstr "" + +#: ../source/news.rst:121 +msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" +msgstr "" + +#: ../source/news.rst:124 +msgid "February 2018" +msgstr "" + +#: ../source/news.rst:126 +msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" +msgstr "" + +#: ../source/news.rst:127 +msgid "Updated PyPI migration info. (:pr:`439`)" +msgstr "" + +#: ../source/news.rst:128 +msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" +msgstr "" + +#: ../source/news.rst:129 +msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" +msgstr "" + +#: ../source/news.rst:130 +msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" +msgstr "" + +#: ../source/news.rst:133 +msgid "January 2018" +msgstr "" + +#: ../source/news.rst:135 +msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" +msgstr "" + +#: ../source/news.rst:136 +msgid "Updated README.rst explanation. (:pr:`419`)" +msgstr "" + +#: ../source/news.rst:139 +msgid "December 2017" +msgstr "" + +#: ../source/news.rst:141 +msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" +msgstr "" + +#: ../source/news.rst:142 +msgid "Noted which fields can be used with environment markers. (:pr:`416`)" +msgstr "" + +#: ../source/news.rst:143 +msgid "Updated Requires-Python section. (:pr:`414`)" +msgstr "" + +#: ../source/news.rst:144 +msgid "Added news page. (:pr:`404`)" +msgstr "" + +#: ../source/news.rst:147 +msgid "November 2017" +msgstr "" + +#: ../source/news.rst:149 +msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" +msgstr "" + +#: ../source/news.rst:150 +msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" +msgstr "" + +#: ../source/news.rst:152 +msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:153 +msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" +msgstr "" + +#: ../source/news.rst:156 +msgid "October 2017" +msgstr "" + +#: ../source/news.rst:158 +msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:159 +msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" +msgstr "" + +#: ../source/news.rst:160 +msgid "Split the specifications page into multiple pages. (:pr:`386`)" +msgstr "" + +#: ../source/news.rst:163 +msgid "September 2017" +msgstr "" + +#: ../source/news.rst:165 +msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" +msgstr "" + +#: ../source/news.rst:167 +msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" +msgstr "" + +#: ../source/news.rst:170 +msgid "August 2017" +msgstr "" + +#: ../source/news.rst:172 +msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" +msgstr "" + +#: ../source/news.rst:173 +msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" +msgstr "" + +#: ../source/news.rst:174 +msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" +msgstr "" + +#: ../source/news.rst:177 +msgid "July 2017" +msgstr "" + +#: ../source/news.rst:179 +msgid "Added ``flit`` to the key projects list. (:pr:`358`)" +msgstr "" + +#: ../source/news.rst:180 +msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" +msgstr "" + +#: ../source/news.rst:181 +msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" +msgstr "" + +#: ../source/news.rst:182 +msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" +msgstr "" + +#: ../source/news.rst:183 +msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" +msgstr "" + +#: ../source/news.rst:186 +msgid "June 2017" +msgstr "" + +#: ../source/news.rst:188 +msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" +msgstr "" + +#: ../source/news.rst:189 +msgid "Added documentation for ``python_requires``. (:pr:`338`)" +msgstr "" + +#: ../source/news.rst:190 +msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" +msgstr "" + +#: ../source/news.rst:191 +msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" +msgstr "" + +#: ../source/news.rst:192 +msgid "Added a license section to the distributing guide. (:pr:`331`)" +msgstr "" + +#: ../source/news.rst:193 +msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" +msgstr "" + +#: ../source/news.rst:194 +msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" +msgstr "" + +#: ../source/news.rst:195 +msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" +msgstr "" + +#: ../source/news.rst:196 +msgid "Switched to the PyPA theme. (:pr:`305`)" +msgstr "" + +#: ../source/news.rst:197 +msgid "Re-organized the documentation into the new structure. (:pr:`318`)" +msgstr "" + +#: ../source/news.rst:200 +msgid "May 2017" +msgstr "" + +#: ../source/news.rst:202 +msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" +msgstr "" + +#: ../source/news.rst:203 +msgid "Added contributor and style guide. (:pr:`307`)" +msgstr "" + +#: ../source/news.rst:204 +msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" +msgstr "" + +#: ../source/news.rst:207 +msgid "April 2017" +msgstr "" + +#: ../source/news.rst:209 +msgid "Added travis configuration for testing pull requests. (:pr:`300`)" +msgstr "" + +#: ../source/news.rst:210 +msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" +msgstr "" + +#: ../source/news.rst:211 +msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" +msgstr "" + +#: ../source/news.rst:212 +msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" +msgstr "" + +#: ../source/news.rst:213 +msgid "Added a topic on namespace packages. (:pr:`290`)" +msgstr "" + +#: ../source/news.rst:214 +msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" +msgstr "" + +#: ../source/news.rst:215 +msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" +msgstr "" + +#: ../source/news.rst:216 +msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" +msgstr "" + +#: ../source/news.rst:217 +msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" +msgstr "" + +#: ../source/news.rst:219 +msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" +msgstr "" + +#: ../source/news.rst:223 +msgid "March 2017" +msgstr "" + +#: ../source/news.rst:225 +msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" +msgstr "" + +#: ../source/news.rst:228 +msgid "February 2017" +msgstr "" + +#: ../source/news.rst:230 +msgid "Added :pep:`518`. (:pr:`281`)" +msgstr "" + +#: ../source/overview.rst:3 +msgid "An Overview of Packaging for Python" +msgstr "" + +#: ../source/overview.rst:7 +msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." +msgstr "" + +#: ../source/overview.rst:12 +msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." +msgstr "" + +#: ../source/overview.rst:18 +msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." +msgstr "" + +#: ../source/overview.rst:26 +msgid "Thinking about deployment" +msgstr "" + +#: ../source/overview.rst:28 +msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" +msgstr "" + +#: ../source/overview.rst:32 +msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" +msgstr "" + +#: ../source/overview.rst:35 +msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" +msgstr "" + +#: ../source/overview.rst:37 +msgid "Is your software installed individually, or in large deployment batches?" +msgstr "" + +#: ../source/overview.rst:39 +msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." +msgstr "" + +#: ../source/overview.rst:46 +msgid "Packaging Python libraries and tools" +msgstr "" + +#: ../source/overview.rst:48 +msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/overview.rst:53 +msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." +msgstr "" + +#: ../source/overview.rst:59 +msgid "Python modules" +msgstr "" + +#: ../source/overview.rst:61 +msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." +msgstr "" + +#: ../source/overview.rst:66 +msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." +msgstr "" + +#: ../source/overview.rst:73 +msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." +msgstr "" + +#: ../source/overview.rst:78 +msgid "Python source distributions" +msgstr "" + +#: ../source/overview.rst:80 +msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." +msgstr "" + +#: ../source/overview.rst:84 +msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." +msgstr "" + +#: ../source/overview.rst:90 +msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." +msgstr "" + +#: ../source/overview.rst:95 +msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." +msgstr "" + +#: ../source/overview.rst:100 +msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." +msgstr "" + +#: ../source/overview.rst:107 +msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" +msgstr "" + +#: ../source/overview.rst:114 +msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." +msgstr "" + +#: ../source/overview.rst:119 +msgid "Python binary distributions" +msgstr "" + +#: ../source/overview.rst:121 +msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." +msgstr "" + +#: ../source/overview.rst:125 +msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." +msgstr "" + +#: ../source/overview.rst:132 +msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." +msgstr "" + +#: ../source/overview.rst:140 +msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." +msgstr "" + +#: ../source/overview.rst:148 +msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." +msgstr "" + +#: ../source/overview.rst:155 +msgid "Packaging Python applications" +msgstr "" + +#: ../source/overview.rst:157 +msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." +msgstr "" + +#: ../source/overview.rst:162 +msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." +msgstr "" + +#: ../source/overview.rst:166 +msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." +msgstr "" + +#: ../source/overview.rst:172 +msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." +msgstr "" + +#: ../source/overview.rst:176 +msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." +msgstr "" + +#: ../source/overview.rst:181 +msgid "Depending on a framework" +msgstr "" + +#: ../source/overview.rst:183 +msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." +msgstr "" + +#: ../source/overview.rst:189 +msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." +msgstr "" + +#: ../source/overview.rst:195 +msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." +msgstr "" + +#: ../source/overview.rst:199 +msgid "Service platforms" +msgstr "" + +#: ../source/overview.rst:201 +msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." +msgstr "" + +#: ../source/overview.rst:205 +msgid "`Heroku `_" +msgstr "" + +#: ../source/overview.rst:206 +msgid "`Google App Engine `_" +msgstr "" + +#: ../source/overview.rst:207 +msgid "`PythonAnywhere `_" +msgstr "" + +#: ../source/overview.rst:208 +msgid "`OpenShift `_" +msgstr "" + +#: ../source/overview.rst:209 +msgid "\"Serverless\" frameworks like `Zappa `_" +msgstr "" + +#: ../source/overview.rst:211 +msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." +msgstr "" + +#: ../source/overview.rst:216 +msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." +msgstr "" + +#: ../source/overview.rst:220 +msgid "Web browsers and mobile applications" +msgstr "" + +#: ../source/overview.rst:222 +msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." +msgstr "" + +#: ../source/overview.rst:227 +msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" +msgstr "" + +#: ../source/overview.rst:231 +msgid "`Kivy `_" +msgstr "" + +#: ../source/overview.rst:232 +msgid "`Beeware `_" +msgstr "" + +#: ../source/overview.rst:233 +msgid "`Brython `_" +msgstr "" + +#: ../source/overview.rst:234 +msgid "`Flexx `_" +msgstr "" + +#: ../source/overview.rst:236 +msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." +msgstr "" + +#: ../source/overview.rst:241 +msgid "Depending on a pre-installed Python" +msgstr "" + +#: ../source/overview.rst:243 +msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." +msgstr "" + +#: ../source/overview.rst:249 +msgid "Technologies which support this model:" +msgstr "" + +#: ../source/overview.rst:251 +msgid "`PEX `_ (Python EXecutable)" +msgstr "" + +#: ../source/overview.rst:252 +msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" +msgstr "" + +#: ../source/overview.rst:253 +msgid "`shiv `_ (requires Python 3)" +msgstr "" + +#: ../source/overview.rst:255 +msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." +msgstr "" + +#: ../source/overview.rst:260 +msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." +msgstr "" + +#: ../source/overview.rst:267 +msgid "Depending on a separate software distribution ecosystem" +msgstr "" + +#: ../source/overview.rst:269 +msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." +msgstr "" + +#: ../source/overview.rst:274 +msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." +msgstr "" + +#: ../source/overview.rst:284 +msgid "Instructions on building and publishing for the Anaconda ecosystem:" +msgstr "" + +#: ../source/overview.rst:286 +msgid "`Building libraries and applications with conda `_" +msgstr "" + +#: ../source/overview.rst:287 +msgid "`Transitioning a native Python package to Anaconda `_" +msgstr "" + +#: ../source/overview.rst:289 +msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" +msgstr "" + +#: ../source/overview.rst:293 +msgid "`Enthought Canopy `_" +msgstr "" + +#: ../source/overview.rst:294 +msgid "`ActiveState ActivePython `_" +msgstr "" + +#: ../source/overview.rst:295 +msgid "`WinPython `_" +msgstr "" + +#: ../source/overview.rst:300 +msgid "Bringing your own Python executable" +msgstr "" + +#: ../source/overview.rst:302 +msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." +msgstr "" + +#: ../source/overview.rst:306 +msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." +msgstr "" + +#: ../source/overview.rst:311 +msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." +msgstr "" + +#: ../source/overview.rst:315 +msgid "A selection of Python freezers:" +msgstr "" + +#: ../source/overview.rst:317 +msgid "`pyInstaller `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:318 +msgid "`cx_Freeze `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:319 +msgid "`constructor `_ - For command-line installers" +msgstr "" + +#: ../source/overview.rst:320 +msgid "`py2exe `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:321 +msgid "`py2app `_ - Mac only" +msgstr "" + +#: ../source/overview.rst:322 +msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" +msgstr "" + +#: ../source/overview.rst:323 +msgid "`osnap `_ - Windows and Mac" +msgstr "" + +#: ../source/overview.rst:324 +msgid "`pynsist `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:326 +msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." +msgstr "" + +#: ../source/overview.rst:332 +msgid "Bringing your own userspace" +msgstr "" + +#: ../source/overview.rst:334 +msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." +msgstr "" + +#: ../source/overview.rst:341 +msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." +msgstr "" + +#: ../source/overview.rst:344 +msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" +msgstr "" + +#: ../source/overview.rst:347 +msgid "`AppImage `_" +msgstr "" + +#: ../source/overview.rst:348 +msgid "`Docker `_" +msgstr "" + +#: ../source/overview.rst:349 +msgid "`Flatpak `_" +msgstr "" + +#: ../source/overview.rst:350 +msgid "`Snapcraft `_" +msgstr "" + +#: ../source/overview.rst:353 +msgid "Bringing your own kernel" +msgstr "" + +#: ../source/overview.rst:355 +msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." +msgstr "" + +#: ../source/overview.rst:360 +msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" +msgstr "" + +#: ../source/overview.rst:364 +msgid "`Vagrant `_" +msgstr "" + +#: ../source/overview.rst:365 +msgid "`VHD `_, `AMI `_, and `other formats `_" +msgstr "" + +#: ../source/overview.rst:366 +msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" +msgstr "" + +#: ../source/overview.rst:369 +msgid "Bringing your own hardware" +msgstr "" + +#: ../source/overview.rst:371 +msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." +msgstr "" + +#: ../source/overview.rst:375 +msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." +msgstr "" + +#: ../source/overview.rst:379 +msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." +msgstr "" + +#: ../source/overview.rst:389 +msgid "The simplified gamut of technologies used to package Python applications." +msgstr "" + +#: ../source/overview.rst:392 +msgid "What about..." +msgstr "" + +#: ../source/overview.rst:394 +msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." +msgstr "" + +#: ../source/overview.rst:398 +msgid "Operating system packages" +msgstr "" + +#: ../source/overview.rst:400 +msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." +msgstr "" + +#: ../source/overview.rst:411 +msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." +msgstr "" + +#: ../source/overview.rst:417 +msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." +msgstr "" + +#: ../source/overview.rst:427 +msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." +msgstr "" + +#: ../source/overview.rst:432 +msgid "Security" +msgstr "Segurança" + +#: ../source/overview.rst:434 +msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." +msgstr "" + +#: ../source/overview.rst:437 +msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." +msgstr "" + +#: ../source/overview.rst:446 +msgid "Wrap up" +msgstr "" + +#: ../source/overview.rst:448 +msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:6 +msgid "Binary distribution format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:8 +msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:13 +msgid "Abstract" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:15 +msgid "This PEP describes a built-package format for Python called \"wheel\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:17 +msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:27 +msgid "PEP Acceptance" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:29 +msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:34 +msgid "Rationale" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:36 +msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:43 +msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:52 +msgid "Details" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:55 +msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:57 +msgid "Wheel installation notionally consists of two phases:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:59 +msgid "Unpack." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:61 +msgid "Parse ``distribution-1.0.dist-info/WHEEL``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:62 +msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:64 +msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:66 +msgid "Else unpack archive into platlib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:68 +msgid "Spread." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:70 +msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:72 +msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:78 +msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:80 +msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:82 +msgid "Remove empty ``distribution-1.0.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:83 +msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:87 +msgid "Recommended installer features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:97 +msgid "Rewrite ``#!python``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:90 +msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:96 +msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:102 +msgid "Generate script wrappers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:100 +msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:105 +msgid "Recommended archiver features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:112 +msgid "Place ``.dist-info`` at the end of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:108 +msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:115 +msgid "File Format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:118 +msgid "File name convention" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:120 +msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "distribution" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "Distribution name, e.g. 'django', 'pyramid'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "Distribution version, e.g. 1.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:135 +msgid "build tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:130 +msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "language implementation and version tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "E.g. 'py27', 'py2', 'py3'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "abi tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "E.g. 'cp33m', 'abi3', 'none'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "platform tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "E.g. 'linux_x86_64', 'any'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:146 +msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:151 +msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:156 +msgid "Escaping and Unicode" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:158 +msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:161 +msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:164 +msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:166 +msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:169 +msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:172 +msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:176 +msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:182 +msgid "File contents" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:184 +msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:188 +msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:191 +msgid "``{distribution}-{version}.dist-info/`` contains metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:192 +msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:196 +msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:200 +msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:202 +msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:212 +msgid "``Wheel-Version`` is the version number of the Wheel specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:213 +msgid "``Generator`` is the name and optionally the version of the software that produced the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:215 +msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:218 +msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:220 +msgid "``Build`` is the build number and is omitted if there is no build number." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:221 +msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:224 +msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:226 +msgid "Wheel does not contain setup.py or setup.cfg." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:228 +msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:235 +#: ../source/specifications/recording-installed-packages.rst:35 +msgid "The .dist-info directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:237 +msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:239 +msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:241 +msgid "WHEEL is the wheel metadata specific to a build of the package." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:242 +msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:248 +msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:249 +msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:251 +msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:254 +msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:261 +msgid "The .data directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:263 +msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:271 +msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:277 +msgid "Signed wheel files" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:279 +msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:290 +msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:295 +msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:302 +msgid "(The hash value is the same format used in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:304 +msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:307 +msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:312 +msgid "See" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:314 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:315 +msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:316 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:317 +msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:321 +msgid "Comparison to .egg" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:323 +msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:328 +msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:331 +msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:337 +msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:341 +msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:344 +msgid "Wheel is a reference to the other Python." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:348 +msgid "FAQ" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:352 +msgid "Wheel defines a .data directory. Should I put all my data there?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:354 +msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:363 +msgid "Why does wheel include attached signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:365 +msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:373 +msgid "Why does wheel allow JWS signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:375 +msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:381 +msgid "Why does wheel also allow S/MIME signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:383 +msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:386 +msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:391 +msgid "What's the deal with \"purelib\" vs. \"platlib\"?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:393 +msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:398 +msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:403 +msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:409 +msgid "Is it possible to import Python code directly from a wheel file?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:411 +msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:417 +msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:426 +msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:443 +msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:450 +msgid "Changes" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:452 +msgid "Since :pep:`427`, this specification has changed as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:454 +msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:461 +msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:466 +msgid "Appendix" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:468 +msgid "Example urlsafe-base64-nopad implementation::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:482 +msgid "Copyright" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:484 +msgid "This document has been placed into the public domain." +msgstr "" + +#: ../source/specifications/core-metadata.rst:5 +msgid "Core metadata specifications" +msgstr "" + +#: ../source/specifications/core-metadata.rst:7 +msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:10 +msgid "``Metadata-Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:11 +msgid "``Name``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:12 +msgid "``Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:14 +msgid "All the other fields are optional." +msgstr "" + +#: ../source/specifications/core-metadata.rst:16 +msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." +msgstr "" + +#: ../source/specifications/core-metadata.rst:25 +msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:30 +msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." +msgstr "" + +#: ../source/specifications/core-metadata.rst:41 +msgid "Metadata-Version" +msgstr "" + +#: ../source/specifications/core-metadata.rst:45 +msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." +msgstr "" + +#: ../source/specifications/core-metadata.rst:48 +msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:54 +msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." +msgstr "" + +#: ../source/specifications/core-metadata.rst:58 +#: ../source/specifications/core-metadata.rst:80 +#: ../source/specifications/core-metadata.rst:95 +#: ../source/specifications/core-metadata.rst:155 +#: ../source/specifications/core-metadata.rst:170 +#: ../source/specifications/core-metadata.rst:208 +#: ../source/specifications/core-metadata.rst:283 +#: ../source/specifications/core-metadata.rst:287 +#: ../source/specifications/core-metadata.rst:291 +#: ../source/specifications/core-metadata.rst:295 +#: ../source/specifications/core-metadata.rst:327 +#: ../source/specifications/core-metadata.rst:347 +#: ../source/specifications/core-metadata.rst:373 +#: ../source/specifications/core-metadata.rst:391 +#: ../source/specifications/core-metadata.rst:416 +#: ../source/specifications/core-metadata.rst:438 +#: ../source/specifications/core-metadata.rst:600 +#: ../source/specifications/core-metadata.rst:620 +#: ../source/specifications/core-metadata.rst:630 +msgid "Example::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:66 +msgid "Name" +msgstr "Nome" + +#: ../source/specifications/core-metadata.rst:69 +msgid "Added additional restrictions on format from :pep:`508`" +msgstr "" + +#: ../source/specifications/core-metadata.rst:72 +msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:88 +msgid "Version" +msgstr "Versão" + +#: ../source/specifications/core-metadata.rst:92 +msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:101 +msgid "Dynamic (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:105 +msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." +msgstr "" + +#: ../source/specifications/core-metadata.rst:108 +msgid "When found in the metadata of a source distribution, the following rules apply:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:111 +msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." +msgstr "" + +#: ../source/specifications/core-metadata.rst:115 +msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:118 +msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:122 +msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." +msgstr "" + +#: ../source/specifications/core-metadata.rst:127 +msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:131 +msgid "Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:135 +msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." +msgstr "" + +#: ../source/specifications/core-metadata.rst:146 +msgid "Supported-Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:150 +msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." +msgstr "" + +#: ../source/specifications/core-metadata.rst:164 +msgid "Summary" +msgstr "" + +#: ../source/specifications/core-metadata.rst:168 +msgid "A one-line summary of what the distribution does." +msgstr "" + +#: ../source/specifications/core-metadata.rst:188 +msgid "This field may be specified in the message body instead." +msgstr "" + +#: ../source/specifications/core-metadata.rst:191 +msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:196 +msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." +msgstr "" + +#: ../source/specifications/core-metadata.rst:202 +msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:219 +msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." +msgstr "" + +#: ../source/specifications/core-metadata.rst:223 +msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:232 +msgid "Description-Content-Type" +msgstr "" + +#: ../source/specifications/core-metadata.rst:236 +msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:239 +msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." +msgstr "" + +#: ../source/specifications/core-metadata.rst:253 +msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:259 +msgid "Format::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:263 +msgid "The ``type/subtype`` part has only a few legal values:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:265 +msgid "``text/plain``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:266 +msgid "``text/x-rst``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:267 +msgid "``text/markdown``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:269 +msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:273 +msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:278 +msgid "``GFM`` for `Github-flavored Markdown `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:280 +msgid "``CommonMark`` for `CommonMark `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:299 +msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." +msgstr "" + +#: ../source/specifications/core-metadata.rst:303 +msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:307 +msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:311 +msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." +msgstr "" + +#: ../source/specifications/core-metadata.rst:320 +msgid "Keywords" +msgstr "" + +#: ../source/specifications/core-metadata.rst:324 +msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." +msgstr "" + +#: ../source/specifications/core-metadata.rst:333 +msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." +msgstr "" + +#: ../source/specifications/core-metadata.rst:341 +msgid "Home-page" +msgstr "" + +#: ../source/specifications/core-metadata.rst:345 +msgid "A string containing the URL for the distribution's home page." +msgstr "" + +#: ../source/specifications/core-metadata.rst:353 +msgid "Download-URL" +msgstr "" + +#: ../source/specifications/core-metadata.rst:357 +msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:366 +msgid "Author" +msgstr "" + +#: ../source/specifications/core-metadata.rst:370 +msgid "A string containing the author's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:383 +msgid "Author-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:387 +msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:395 +#: ../source/specifications/core-metadata.rst:442 +msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:405 +msgid "Maintainer" +msgstr "Mantenedor" + +#: ../source/specifications/core-metadata.rst:409 +msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:412 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:426 +msgid "Maintainer-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:430 +msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:434 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:452 +msgid "License" +msgstr "" + +#: ../source/specifications/core-metadata.rst:456 +msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." +msgstr "" + +#: ../source/specifications/core-metadata.rst:476 +msgid "Classifier (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:480 +msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:485 +#: ../source/specifications/core-metadata.rst:574 +#: ../source/specifications/core-metadata.rst:691 +#: ../source/specifications/core-metadata.rst:715 +msgid "This field may be followed by an environment marker after a semicolon." +msgstr "" + +#: ../source/specifications/core-metadata.rst:496 +msgid "Requires-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:499 +#: ../source/specifications/core-metadata.rst:561 +#: ../source/specifications/core-metadata.rst:663 +#: ../source/specifications/core-metadata.rst:704 +msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." +msgstr "" + +#: ../source/specifications/core-metadata.rst:503 +msgid "Each entry contains a string naming some other distutils project required by this distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:506 +msgid "The format of a requirement string contains from one to four parts:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:508 +msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." +msgstr "" + +#: ../source/specifications/core-metadata.rst:510 +msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." +msgstr "" + +#: ../source/specifications/core-metadata.rst:513 +msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:516 +msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." +msgstr "" + +#: ../source/specifications/core-metadata.rst:519 +msgid "See :pep:`508` for full details of the allowed format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:521 +msgid "The project names should correspond to names as found on the `Python Package Index`_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:524 +msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:538 +msgid "Requires-Python" +msgstr "" + +#: ../source/specifications/core-metadata.rst:542 +msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." +msgstr "" + +#: ../source/specifications/core-metadata.rst:546 +msgid "The value must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:548 +msgid "This field cannot be followed by an environment marker." +msgstr "" + +#: ../source/specifications/core-metadata.rst:558 +msgid "Requires-External (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:565 +msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:570 +msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:576 +msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." +msgstr "" + +#: ../source/specifications/core-metadata.rst:581 +msgid "Notice that there is no particular rule on the strings to be used." +msgstr "" + +#: ../source/specifications/core-metadata.rst:593 +msgid "Project-URL (multiple-use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:597 +msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." +msgstr "" + +#: ../source/specifications/core-metadata.rst:604 +msgid "The label is free text limited to 32 characters." +msgstr "" + +#: ../source/specifications/core-metadata.rst:612 +msgid "Provides-Extra (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:616 +msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." +msgstr "" + +#: ../source/specifications/core-metadata.rst:625 +msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:635 +msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." +msgstr "" + +#: ../source/specifications/core-metadata.rst:639 +msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:644 +msgid "Rarely Used Fields" +msgstr "" + +#: ../source/specifications/core-metadata.rst:646 +msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:651 +msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." +msgstr "" + +#: ../source/specifications/core-metadata.rst:660 +msgid "Provides-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:667 +msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:672 +msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:679 +msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:687 +msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." +msgstr "" + +#: ../source/specifications/core-metadata.rst:701 +msgid "Obsoletes-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:708 +msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." +msgstr "" + +#: ../source/specifications/core-metadata.rst:712 +msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:717 +msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:730 +msgid "reStructuredText markup: http://docutils.sourceforge.net/" +msgstr "" + +#: ../source/specifications/core-metadata.rst:735 +msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:6 +msgid "Declaring build system dependencies" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:8 +msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:5 +msgid "Declaring project metadata" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:7 +msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:12 +msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:18 +msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:27 +msgid "The only fields required to be statically defined are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:29 +#: ../source/specifications/declaring-project-metadata.rst:41 +msgid "``name``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:31 +msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:34 +#: ../source/specifications/declaring-project-metadata.rst:54 +msgid "``version``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:36 +msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:43 +#: ../source/specifications/declaring-project-metadata.rst:56 +#: ../source/specifications/declaring-project-metadata.rst:68 +#: ../source/specifications/declaring-project-metadata.rst:117 +msgid "TOML_ type: string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:44 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:47 +msgid "The name of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:49 +msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:57 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:60 +msgid "The version of the project as supported by :pep:`440`." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:62 +msgid "Users SHOULD prefer to specify already-normalized versions." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:66 +msgid "``description``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:69 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:72 +msgid "The summary description of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:76 +msgid "``readme``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:78 +msgid "TOML_ type: string or table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:79 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:83 +msgid "The full description of the project (i.e. the README)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:85 +msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:96 +msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:103 +msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:115 +msgid "``requires-python``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:118 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:121 +msgid "The Python version requirements of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:125 +msgid "``license``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:127 +msgid "TOML_ type: table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:128 +msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:131 +msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:140 +msgid "``authors``/``maintainers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:142 +msgid "TOML_ type: Array of inline tables with string keys and values" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:143 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:149 +msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:154 +msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:157 +msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:163 +msgid "Using the data to fill in :ref:`core metadata ` is as follows:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:166 +msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:169 +msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:173 +msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:177 +msgid "Multiple values should be separated by commas." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:181 +msgid "``keywords``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:183 +#: ../source/specifications/declaring-project-metadata.rst:193 +msgid "TOML_ type: array of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:184 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:187 +msgid "The keywords for the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:191 +msgid "``classifiers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:194 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:197 +msgid "Trove classifiers which apply to the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:201 +msgid "``urls``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:203 +msgid "TOML_ type: table with keys and values of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:204 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:207 +msgid "A table of URLs where the key is the URL label and the value is the URL itself." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:212 +msgid "Entry points" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:214 +msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:216 +msgid ":ref:`Entry points specification `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:218 +msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:224 +msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:228 +msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:234 +msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:242 +msgid "``dependencies``/``optional-dependencies``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:244 +msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:247 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:251 +msgid "The (optional) dependencies of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:253 +msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:258 +msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:269 +msgid "``dynamic``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:271 +msgid "TOML_ type: array of string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:272 +msgid "A corresponding :ref:`core metadata ` field does not exist" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:275 +msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:281 +msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:283 +msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:285 +msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:290 +msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:294 +msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:296 +msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:300 +msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:6 +msgid "Dependency specifiers" +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:8 +msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:11 +msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." +msgstr "" + +#: ../source/specifications/direct-url.rst:6 +msgid "Recording the Direct URL Origin of installed distributions" +msgstr "" + +#: ../source/specifications/direct-url.rst:8 +msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." +msgstr "" + +#: ../source/specifications/direct-url.rst:17 +msgid "Specification" +msgstr "" + +#: ../source/specifications/direct-url.rst:19 +msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/direct-url.rst:23 +#: ../source/specifications/recording-installed-packages.rst:206 +msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." +msgstr "" + +#: ../source/specifications/direct-url.rst:26 +msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." +msgstr "" + +#: ../source/specifications/direct-url.rst:29 +msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." +msgstr "" + +#: ../source/specifications/direct-url.rst:36 +msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." +msgstr "" + +#: ../source/specifications/direct-url.rst:39 +msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" +msgstr "" + +#: ../source/specifications/direct-url.rst:45 +msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." +msgstr "" + +#: ../source/specifications/direct-url.rst:49 +msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" +msgstr "" + +#: ../source/specifications/direct-url.rst:52 +msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." +msgstr "" + +#: ../source/specifications/direct-url.rst:58 +msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." +msgstr "" + +#: ../source/specifications/direct-url.rst:61 +msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." +msgstr "" + +#: ../source/specifications/direct-url.rst:68 +msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:71 +msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." +msgstr "" + +#: ../source/specifications/direct-url.rst:78 +msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:81 +msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." +msgstr "" + +#: ../source/specifications/direct-url.rst:84 +msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." +msgstr "" + +#: ../source/specifications/direct-url.rst:91 +msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." +msgstr "" + +#: ../source/specifications/direct-url.rst:96 +msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." +msgstr "" + +#: ../source/specifications/direct-url.rst:102 +msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." +msgstr "" + +#: ../source/specifications/direct-url.rst:110 +msgid "Registered VCS" +msgstr "" + +#: ../source/specifications/direct-url.rst:112 +msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." +msgstr "" + +#: ../source/specifications/direct-url.rst:122 +msgid "Git" +msgstr "" + +#: ../source/specifications/direct-url.rst:124 +#: ../source/specifications/direct-url.rst:156 +#: ../source/specifications/direct-url.rst:179 +#: ../source/specifications/direct-url.rst:202 +msgid "Home page" +msgstr "" + +#: ../source/specifications/direct-url.rst:126 +msgid "https://git-scm.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:128 +#: ../source/specifications/direct-url.rst:160 +#: ../source/specifications/direct-url.rst:183 +#: ../source/specifications/direct-url.rst:206 +msgid "vcs command" +msgstr "" + +#: ../source/specifications/direct-url.rst:130 +#: ../source/specifications/direct-url.rst:134 +msgid "git" +msgstr "" + +#: ../source/specifications/direct-url.rst:132 +#: ../source/specifications/direct-url.rst:164 +#: ../source/specifications/direct-url.rst:187 +#: ../source/specifications/direct-url.rst:210 +msgid "``vcs`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:136 +#: ../source/specifications/direct-url.rst:168 +#: ../source/specifications/direct-url.rst:191 +#: ../source/specifications/direct-url.rst:214 +msgid "``requested_revision`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:138 +msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." +msgstr "" + +#: ../source/specifications/direct-url.rst:141 +#: ../source/specifications/direct-url.rst:172 +#: ../source/specifications/direct-url.rst:195 +#: ../source/specifications/direct-url.rst:219 +msgid "``commit_id`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:143 +msgid "A commit hash (40 hexadecimal characters sha1)." +msgstr "" + +#: ../source/specifications/direct-url.rst:147 +msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." +msgstr "" + +#: ../source/specifications/direct-url.rst:154 +msgid "Mercurial" +msgstr "" + +#: ../source/specifications/direct-url.rst:158 +msgid "https://www.mercurial-scm.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:162 +#: ../source/specifications/direct-url.rst:166 +msgid "hg" +msgstr "" + +#: ../source/specifications/direct-url.rst:170 +msgid "A tag name, branch name, changeset ID, shortened changeset ID." +msgstr "" + +#: ../source/specifications/direct-url.rst:174 +msgid "A changeset ID (40 hexadecimal characters)." +msgstr "" + +#: ../source/specifications/direct-url.rst:177 +msgid "Bazaar" +msgstr "" + +#: ../source/specifications/direct-url.rst:181 +msgid "https://bazaar.canonical.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:185 +#: ../source/specifications/direct-url.rst:189 +msgid "bzr" +msgstr "" + +#: ../source/specifications/direct-url.rst:193 +msgid "A tag name, branch name, revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:197 +msgid "A revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:200 +msgid "Subversion" +msgstr "" + +#: ../source/specifications/direct-url.rst:204 +msgid "https://subversion.apache.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:208 +#: ../source/specifications/direct-url.rst:212 +msgid "svn" +msgstr "" + +#: ../source/specifications/direct-url.rst:216 +msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." +msgstr "" + +#: ../source/specifications/direct-url.rst:221 +msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." +msgstr "" + +#: ../source/specifications/direct-url.rst:229 +msgid "Example direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:231 +msgid "Source archive:" +msgstr "" + +#: ../source/specifications/direct-url.rst:242 +msgid "Git URL with tag and commit-hash:" +msgstr "" + +#: ../source/specifications/direct-url.rst:255 +msgid "Local directory:" +msgstr "" + +#: ../source/specifications/direct-url.rst:264 +msgid "Local directory installed in editable mode:" +msgstr "" + +#: ../source/specifications/direct-url.rst:277 +msgid "Example pip commands and their effect on direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:279 +msgid "Commands that generate a ``direct_url.json``:" +msgstr "" + +#: ../source/specifications/direct-url.rst:281 +msgid "pip install https://example.com/app-1.0.tgz" +msgstr "" + +#: ../source/specifications/direct-url.rst:282 +msgid "pip install https://example.com/app-1.0.whl" +msgstr "" + +#: ../source/specifications/direct-url.rst:283 +msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" +msgstr "" + +#: ../source/specifications/direct-url.rst:284 +msgid "pip install ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:285 +msgid "pip install file:///home/user/app" +msgstr "" + +#: ../source/specifications/direct-url.rst:286 +msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" +msgstr "" + +#: ../source/specifications/direct-url.rst:290 +msgid "pip install -e ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:292 +msgid "Commands that *do not* generate a ``direct_url.json``" +msgstr "" + +#: ../source/specifications/direct-url.rst:294 +msgid "pip install app" +msgstr "" + +#: ../source/specifications/direct-url.rst:295 +msgid "pip install app --no-index --find-links https://example.com/" +msgstr "" + +#: ../source/specifications/entry-points.rst:5 +msgid "Entry points specification" +msgstr "" + +#: ../source/specifications/entry-points.rst:7 +msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" +msgstr "" + +#: ../source/specifications/entry-points.rst:11 +msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." +msgstr "" + +#: ../source/specifications/entry-points.rst:14 +msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." +msgstr "" + +#: ../source/specifications/entry-points.rst:19 +msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." +msgstr "" + +#: ../source/specifications/entry-points.rst:28 +msgid "Data model" +msgstr "" + +#: ../source/specifications/entry-points.rst:30 +msgid "Conceptually, an entry point is defined by three required properties:" +msgstr "" + +#: ../source/specifications/entry-points.rst:32 +msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:42 +msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:51 +msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:64 +msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." +msgstr "" + +#: ../source/specifications/entry-points.rst:68 +msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." +msgstr "" + +#: ../source/specifications/entry-points.rst:73 +msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." +msgstr "" + +#: ../source/specifications/entry-points.rst:80 +msgid "File format" +msgstr "" + +#: ../source/specifications/entry-points.rst:82 +msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." +msgstr "" + +#: ../source/specifications/entry-points.rst:87 +msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:97 +msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:100 +msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." +msgstr "" + +#: ../source/specifications/entry-points.rst:104 +msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." +msgstr "" + +#: ../source/specifications/entry-points.rst:112 +msgid "For example::" +msgstr "" + +#: ../source/specifications/entry-points.rst:124 +msgid "Use for scripts" +msgstr "" + +#: ../source/specifications/entry-points.rst:126 +msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." +msgstr "" + +#: ../source/specifications/entry-points.rst:134 +msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:141 +msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." +msgstr "" + +#: ../source/specifications/entry-points.rst:149 +msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." +msgstr "" + +#: ../source/specifications/entry-points.rst:154 +msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." +msgstr "" + +#: ../source/specifications/index.rst:4 +msgid "PyPA specifications" +msgstr "" + +#: ../source/specifications/index.rst:6 +msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." +msgstr "" + +#: ../source/specifications/index.rst:13 +msgid "Package Distribution Metadata" +msgstr "" + +#: ../source/specifications/index.rst:30 +msgid "Package Distribution File Formats" +msgstr "" + +#: ../source/specifications/index.rst:40 +msgid "Package Index Interfaces" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:6 +msgid "Platform compatibility tags" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:8 +msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:12 +msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:16 +msgid "Platform tags for Windows" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:18 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:22 +msgid "Platform tags for macOS (Mac OS X)" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:24 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:28 +msgid "Platform tags for common Linux distributions" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:32 +msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:36 +msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:41 +msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:44 +msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:46 +msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:49 +msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:54 +msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:59 +msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:65 +msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:71 +msgid "Manylinux compatibility support" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:74 +msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:76 +msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:79 +msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "Tool" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux1``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2010``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2014``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux_x_y``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=8.1.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=20.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "auditwheel" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=1.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=2.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.3.0`` [#]_" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:90 +msgid "Platform tags for other \\*nix platforms" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:92 +msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:98 +msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" +msgstr "" + +#: ../source/specifications/pypirc.rst:6 +msgid "The :file:`.pypirc` file" +msgstr "" + +#: ../source/specifications/pypirc.rst:8 +msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." +msgstr "" + +#: ../source/specifications/pypirc.rst:13 +msgid "The format (originally defined by the :ref:`distutils` package) is:" +msgstr "" + +#: ../source/specifications/pypirc.rst:32 +msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:35 +msgid "Each section describing a repository defines three fields:" +msgstr "" + +#: ../source/specifications/pypirc.rst:37 +msgid "``repository``: The URL of the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:38 +msgid "``username``: The registered username on the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:39 +msgid "``password``: The password that will used to authenticate the username." +msgstr "" + +#: ../source/specifications/pypirc.rst:43 +msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." +msgstr "" + +#: ../source/specifications/pypirc.rst:47 +msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" +msgstr "" + +#: ../source/specifications/pypirc.rst:57 +msgid "Common configurations" +msgstr "" + +#: ../source/specifications/pypirc.rst:61 +msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." +msgstr "" + +#: ../source/specifications/pypirc.rst:66 +msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" +msgstr "" + +#: ../source/specifications/pypirc.rst:82 +msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." +msgstr "" + +#: ../source/specifications/pypirc.rst:86 +msgid "Using a PyPI token" +msgstr "" + +#: ../source/specifications/pypirc.rst:88 +msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" +msgstr "" + +#: ../source/specifications/pypirc.rst:97 +msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." +msgstr "" + +#: ../source/specifications/pypirc.rst:103 +msgid "Using another package index" +msgstr "" + +#: ../source/specifications/pypirc.rst:105 +msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" +msgstr "" + +#: ../source/specifications/pypirc.rst:132 +msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:5 +msgid "Recording installed projects" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:7 +msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:12 +msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:21 +msgid "History and change workflow" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:23 +msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:29 +msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:37 +msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:41 +msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:50 +msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:60 +msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:69 +msgid "This ``.dist-info`` directory can contain these files, described in detail below:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:72 +msgid "``METADATA``: contains project metadata" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:73 +msgid "``RECORD``: records the list of installed files." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:74 +msgid "``INSTALLER``: records the name of the tool used to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:76 +msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:82 +msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:87 +msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:94 +msgid "The METADATA file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:96 +msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:99 +msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:105 +msgid "The RECORD file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:107 +msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:110 +msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:113 +msgid "field delimiter: ``,`` (comma)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:114 +msgid "quoting char: ``\"`` (straight double quote)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:115 +msgid "line terminator: either ``\\r\\n`` or ``\\n``." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:117 +msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:120 +msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:125 +msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:130 +msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:133 +msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:139 +msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:146 +msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:151 +msgid "Here is an example snippet of a possible ``RECORD`` file::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:170 +msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:177 +msgid "The INSTALLER file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:179 +msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:185 +msgid "The file can be terminated by zero or more ASCII whitespace characters." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:187 +msgid "Here are examples of two possible ``INSTALLER`` files::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:195 +msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:201 +msgid "The direct_url.json file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:203 +msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:209 +msgid "Its detailed specification is at :ref:`direct-url`." +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:6 +msgid "Simple repository API" +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:8 +msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:6 +msgid "Source distribution format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:8 +msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:13 +msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:21 +msgid "Source distributions are also known as *sdists* for short." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:24 +msgid "Source distribution file name" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:26 +msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:31 +msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:35 +msgid "Source distribution file format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:37 +msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:45 +msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:48 +msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:6 +msgid "Version specifiers" +msgstr "" + +#: ../source/specifications/version-specifiers.rst:8 +msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:11 +msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." +msgstr "" + +#: ../source/support.rst:3 +msgid "How to Get Support" +msgstr "" + +#: ../source/support.rst:5 +msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." +msgstr "" + +#: ../source/support.rst:8 +msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:5 +msgid "Creating Documentation" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:7 +msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:13 +msgid "Installing Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:14 +msgid "Use ``pip`` to install Sphinx:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:28 +msgid "For other installation methods, see this `installation guide`_ by Sphinx." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:33 +msgid "Getting Started With Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:35 +msgid "Create a ``docs`` directory inside your project to hold your documentation:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:42 +msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:49 +msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:51 +msgid "You can add some information about your project in ``index.rst``, then build them:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:57 +msgid "For more details on the build process, see this `guide`_ by Read The Docs." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:62 +msgid "Other Sources" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:64 +msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/index.rst:4 +msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:5 +msgid "Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:7 +msgid "This section covers the basics of how to install Python :term:`packages `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:10 +msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:28 +msgid "Requirements for Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:30 +msgid "This section describes the steps to follow before installing other Python packages." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:35 +msgid "Ensure you can run Python from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:37 +msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:53 +msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:57 +msgid "If you're a newcomer and you get an error like this:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:66 +msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:72 +msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:82 +msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:87 +msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:99 +msgid "Ensure you can run pip from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:101 +msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:116 +msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:124 +msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:139 +msgid "If that still doesn't allow you to run ``python -m pip``:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:141 +msgid "Securely Download `get-pip.py `_ [1]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:144 +msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:150 +msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:159 +msgid "Ensure pip, setuptools, and wheel are up to date" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:161 +msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:169 +msgid "Optionally, create a virtual environment" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:171 +msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:188 +msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:195 +msgid "Creating Virtual Environments" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:197 +msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:203 +msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:209 +msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:213 +msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:216 +msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:220 +msgid "Currently, there are two common tools for creating Python virtual environments:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:222 +msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:225 +msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:230 +msgid "The basic usage is like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:232 +msgid "Using `venv`_:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:248 +msgid "Using :ref:`virtualenv`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:264 +msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:266 +msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:271 +msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:281 +msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:288 +msgid "Use pip for Installing" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:290 +msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:297 +msgid "Installing from PyPI" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:299 +msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:307 +msgid "To install the latest version of \"SomeProject\":" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:321 +msgid "To install a specific version:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:335 +msgid "To install greater than or equal to one version and less than another:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:350 +msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:365 +msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:370 +msgid "Source Distributions vs Wheels" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:372 +msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:378 +msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:383 +msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:391 +msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:408 +msgid "Installing to the User Site" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:410 +msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:425 +msgid "For more information see the `User Installs `_ section from the pip docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:429 +msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:432 +msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:440 +msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:446 +msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:462 +msgid "Install a list of requirements specified in a :ref:`Requirements File `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:478 +msgid "Installing from VCS" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:480 +msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:502 +msgid "Installing from other Indexes" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:504 +msgid "Install from an alternate index" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:518 +msgid "Search an additional index during install, in addition to :term:`PyPI `" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:534 +msgid "Installing from a local src tree" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:537 +msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:554 +msgid "You can also install normally from src" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:571 +msgid "Install a particular source archive file." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:585 +msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:605 +msgid "Installing from other sources" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:607 +msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:619 +msgid "Installing Prereleases" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:621 +msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:637 +msgid "Installing Setuptools \"Extras\"" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:639 +msgid "Install `setuptools extras`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:659 +msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:668 +msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:673 +msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:4 +msgid "Managing Application Dependencies" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:6 +msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:9 +msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:13 +msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:17 +msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:24 +msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:30 +msgid "Installing Pipenv" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:32 +msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:38 +msgid "Use ``pip`` to install Pipenv:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:54 +msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:65 +msgid "Installing packages for your project" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:67 +msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:76 +msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:112 +msgid "Using installed packages" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:114 +msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:125 +msgid "Then you can run this script using ``pipenv run``:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:131 +msgid "You should get output similar to this:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:137 +msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:143 +#: ../source/tutorials/packaging-projects.rst:594 +msgid "Next steps" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:145 +msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:148 +msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:151 +msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:160 +msgid "Other Tools for Application Dependency Management" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:162 +msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:166 +msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:172 +msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:175 +msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:177 +msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:2 +msgid "Packaging Python Projects" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:4 +msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:10 +msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:18 +msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:35 +msgid "A simple project" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:37 +msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:41 +msgid "Create the following file structure locally:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:51 +msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:54 +msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:63 +msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:67 +msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:75 +msgid "Creating the package files" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:77 +msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:95 +msgid "Creating a test directory" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:97 +msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:101 +msgid "Creating pyproject.toml" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:103 +msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:117 +msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:121 +msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:127 +msgid "See :pep:`517` and :pep:`518` for background and details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:131 +msgid "Configuring metadata" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:133 +msgid "There are two types of metadata: static and dynamic." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:135 +msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:137 +msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:141 +msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:148 +msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:153 +msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:185 +msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:191 +#: ../source/tutorials/packaging-projects.rst:286 +msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:196 +msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:199 +#: ../source/tutorials/packaging-projects.rst:293 +msgid "``author`` and ``author_email`` are used to identify the author of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:201 +#: ../source/tutorials/packaging-projects.rst:295 +msgid "``description`` is a short, one-sentence summary of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:202 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:206 +#: ../source/tutorials/packaging-projects.rst:300 +msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:208 +#: ../source/tutorials/packaging-projects.rst:302 +msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:211 +#: ../source/tutorials/packaging-projects.rst:305 +msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:213 +#: ../source/tutorials/packaging-projects.rst:307 +msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:221 +msgid "In the ``options`` category, we have controls for setuptools itself:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:223 +msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:227 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:234 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:238 +#: ../source/tutorials/packaging-projects.rst:329 +msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:244 +msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:248 +msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:283 +msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:291 +msgid "``version`` is the package version. See :pep:`440` for more details on versions." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:296 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:314 +msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:319 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:325 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:333 +msgid "Creating README.md" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:335 +msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:347 +msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:354 +msgid "Creating a LICENSE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:356 +msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:387 +msgid "Including other files" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:389 +msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:393 +msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:402 +msgid "Generating distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:404 +msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:408 +msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:422 +msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:425 +msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:439 +msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:449 +msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:458 +msgid "Uploading the distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:460 +msgid "Finally, it's time to upload your package to the Python Package Index!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:462 +msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:470 +msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:477 +msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:492 +msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:506 +msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:510 +msgid "After the command completes, you should see output similar to this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:523 +msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:528 +msgid "Installing your newly uploaded package" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:530 +msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:546 +msgid "Make sure to specify your username in the package name!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:548 +msgid "pip should install the package from TestPyPI and the output should look something like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:558 +msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:565 +msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:580 +msgid "and import the package:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:588 +msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:596 +msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:599 +msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:604 +msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:608 +msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:610 +msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:613 +msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:617 +msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:619 +msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:622 +msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:624 +msgid "Read about :doc:`/guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:625 +msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." +msgstr "" From 831cf7c7cf57bffd1767d2c7b4ca3350565e1111 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Sun, 29 Aug 2021 18:15:31 +0200 Subject: [PATCH 0079/1072] Translated using Weblate (Ukrainian) Currently translated at 1.3% (30 of 2271 strings) Added translation using Weblate (Ukrainian) Co-authored-by: Sviatoslav Sydorenko Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/uk/ Translation: pypa/packaging.python.org --- locales/uk/LC_MESSAGES/messages.po | 9267 ++++++++++++++++++++++++++++ 1 file changed, 9267 insertions(+) create mode 100644 locales/uk/LC_MESSAGES/messages.po diff --git a/locales/uk/LC_MESSAGES/messages.po b/locales/uk/LC_MESSAGES/messages.po new file mode 100644 index 000000000..b61d64ef2 --- /dev/null +++ b/locales/uk/LC_MESSAGES/messages.po @@ -0,0 +1,9267 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2013–2020, PyPA +# This file is distributed under the same license as the Python Packaging User Guide package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: Python Packaging User Guide\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-07-06 19:32+0800\n" +"PO-Revision-Date: 2021-07-14 16:45+0000\n" +"Last-Translator: Sviatoslav Sydorenko \n" +"Language-Team: Ukrainian \n" +"Language: uk\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && n" +"%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n" +"X-Generator: Weblate 4.7.2-dev\n" + +#: ../source/contribute.rst:5 +msgid "Contribute to this guide" +msgstr "Зробіть внесок до керівництва" + +#: ../source/contribute.rst:7 +msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" +msgstr "" + +#: ../source/contribute.rst:10 +msgid "Reading the guide and giving feedback" +msgstr "" + +#: ../source/contribute.rst:11 +msgid "Reviewing new contributions" +msgstr "Оцінювання нових вкладів" + +#: ../source/contribute.rst:12 +msgid "Revising existing content" +msgstr "Вивірення існуючого вмісту" + +#: ../source/contribute.rst:13 +msgid "Writing new content" +msgstr "Написання нового вмісту" + +#: ../source/contribute.rst:15 +msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." +msgstr "" + +#: ../source/contribute.rst:24 +msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." +msgstr "" + +#: ../source/contribute.rst:31 +msgid "Documentation types" +msgstr "Типи документації" + +#: ../source/contribute.rst:33 +msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." +msgstr "" + +#: ../source/contribute.rst:38 +#: ../source/tutorials/index.rst:2 +#, fuzzy +msgid "Tutorials" +msgstr "Туторіали" + +#: ../source/contribute.rst:40 +msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." +msgstr "" + +#: ../source/contribute.rst:47 +#: ../source/guides/index.rst:2 +msgid "Guides" +msgstr "Керівництва" + +#: ../source/contribute.rst:49 +msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." +msgstr "" + +#: ../source/contribute.rst:56 +#: ../source/discussions/index.rst:2 +msgid "Discussions" +msgstr "Обговорення" + +#: ../source/contribute.rst:58 +msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." +msgstr "" + +#: ../source/contribute.rst:63 +msgid "Specifications" +msgstr "Специфікації" + +#: ../source/contribute.rst:65 +msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." +msgstr "" + +#: ../source/contribute.rst:73 +msgid "Building the guide locally" +msgstr "" + +#: ../source/contribute.rst:75 +msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" +msgstr "" + +#: ../source/contribute.rst:79 +msgid "`Nox `_. You can install or upgrade nox using ``pip``::" +msgstr "" + +#: ../source/contribute.rst:84 +msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." +msgstr "" + +#: ../source/contribute.rst:91 +msgid "To build the guide, run the following bash command in the source folder::" +msgstr "" + +#: ../source/contribute.rst:95 +msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." +msgstr "" + +#: ../source/contribute.rst:100 +msgid "You can build the guide and serve it via an HTTP server using the following command::" +msgstr "" + +#: ../source/contribute.rst:105 +msgid "The guide will be browsable via http://localhost:8000." +msgstr "" + +#: ../source/contribute.rst:109 +#, fuzzy +msgid "Where the guide is deployed" +msgstr "Куди це керівництво публікується" + +#: ../source/contribute.rst:111 +msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." +msgstr "" + +#: ../source/contribute.rst:117 +#, fuzzy +msgid "Style guide" +msgstr "Керівництво по стилю" + +#: ../source/contribute.rst:119 +msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." +msgstr "" + +#: ../source/contribute.rst:126 +msgid "Purpose" +msgstr "Призначення" + +#: ../source/contribute.rst:128 +msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." +msgstr "" + +#: ../source/contribute.rst:133 +msgid "Scope" +msgstr "" + +#: ../source/contribute.rst:135 +msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." +msgstr "" + +#: ../source/contribute.rst:138 +msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." +msgstr "" + +#: ../source/contribute.rst:146 +#, fuzzy +msgid "Audience" +msgstr "Читачі" + +#: ../source/contribute.rst:148 +msgid "The audience of this guide is anyone who uses Python with packages." +msgstr "" + +#: ../source/contribute.rst:150 +msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." +msgstr "" + +#: ../source/contribute.rst:154 +msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." +msgstr "" + +#: ../source/contribute.rst:160 +#, fuzzy +msgid "Voice and tone" +msgstr "Вираження і тон" + +#: ../source/contribute.rst:162 +msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." +msgstr "" + +#: ../source/contribute.rst:165 +msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." +msgstr "" + +#: ../source/contribute.rst:170 +msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." +msgstr "" + +#: ../source/contribute.rst:177 +msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." +msgstr "" + +#: ../source/contribute.rst:184 +#, fuzzy +msgid "Conventions and mechanics" +msgstr "Домовленості й мехініки" + +#: ../source/contribute.rst:192 +#, fuzzy +msgid "**Write to the reader**" +msgstr "**Пишіть читачеві**" + +#: ../source/contribute.rst:187 +msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: To install it, the user runs…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: You can install it by running…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: To install it, run…" +msgstr "" + +#: ../source/contribute.rst:198 +msgid "**State assumptions**" +msgstr "**Оголошуйте припущення**" + +#: ../source/contribute.rst:195 +msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." +msgstr "" + +#: ../source/contribute.rst:203 +msgid "**Cross-reference generously**" +msgstr "**Щедро додавайте перехресні посилання**" + +#: ../source/contribute.rst:201 +msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." +msgstr "" + +#: ../source/contribute.rst:213 +msgid "**Respect naming practices**" +msgstr "**Дотримуйтеся практик іменування**" + +#: ../source/contribute.rst:206 +msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." +msgstr "" +"Згадуючи інструменти, сайти, людей чи інші власні назви, використовуйте їх " +"бажане написання великих літер." + +#: ../source/contribute.rst:0 +msgid "Wrong: Pip uses…" +msgstr "Неправильно: Pip використовує…" + +#: ../source/contribute.rst:0 +msgid "Right: pip uses…" +msgstr "Правильно: pip використовує…" + +#: ../source/contribute.rst:0 +msgid "Wrong: …hosted on github." +msgstr "Неправильно: ...розміщено на github." + +#: ../source/contribute.rst:0 +msgid "Right: …hosted on GitHub." +msgstr "Правильно: ...розміщено на GitHub." + +#: ../source/contribute.rst:222 +msgid "**Use a gender-neutral style**" +msgstr "**Використовуйте ґендерно нейтральний стиль**" + +#: ../source/contribute.rst:216 +msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: A maintainer uploads the file. Then he…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then they…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then the maintainer…" +msgstr "" + +#: ../source/contribute.rst:234 +msgid "**Headings**" +msgstr "**Заголовки**" + +#: ../source/contribute.rst:225 +msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." +msgstr "" + +#: ../source/contribute.rst:230 +msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: Things You Should Know About Python" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: Things you should know about Python" +msgstr "" + +#: ../source/contribute.rst:237 +msgid "**Numbers**" +msgstr "**Числа**" + +#: ../source/contribute.rst:237 +msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:4 +msgid "Deploying Python applications" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Page Status" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:6 +#: ../source/guides/index-mirrors-and-caches.rst:7 +#: ../source/guides/installing-using-linux-tools.rst:7 +#: ../source/guides/packaging-binary-extensions.rst:7 +#: ../source/guides/supporting-multiple-python-versions.rst:7 +#: ../source/guides/supporting-windows-using-appveyor.rst:5 +msgid "Incomplete" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Last Reviewed" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:7 +msgid "2014-11-11" +msgstr "11.11.2014" + +#: ../source/discussions/deploying-python-applications.rst:11 +#: ../source/discussions/install-requires-vs-requirements.rst:9 +#: ../source/guides/analyzing-pypi-package-downloads.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:22 +#: ../source/guides/index-mirrors-and-caches.rst:12 +#: ../source/guides/installing-scientific-packages.rst:9 +#: ../source/guides/packaging-binary-extensions.rst:17 +#: ../source/guides/supporting-multiple-python-versions.rst:12 +#: ../source/guides/supporting-windows-using-appveyor.rst:15 +#: ../source/overview.rst:23 +#: ../source/specifications/core-metadata.rst:38 +#: ../source/specifications/direct-url.rst:14 +#: ../source/tutorials/installing-packages.rst:23 +msgid "Contents" +msgstr "Зміст" + +#: ../source/discussions/deploying-python-applications.rst:14 +msgid "Overview" +msgstr "Огляд" + +#: ../source/discussions/deploying-python-applications.rst:18 +msgid "Supporting multiple hardware platforms" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:40 +msgid "OS packaging & installers" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:52 +msgid "Windows" +msgstr "Windows" + +#: ../source/discussions/deploying-python-applications.rst:61 +msgid "Pynsist" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:63 +msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:70 +msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:74 +msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:80 +msgid "Application bundles" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:91 +msgid "Configuration management" +msgstr "Управління конфігурацією" + +#: ../source/discussions/index.rst:4 +msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:5 +msgid "install_requires vs requirements files" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:382 +msgid "install_requires" +msgstr "install_requires" + +#: ../source/discussions/install-requires-vs-requirements.rst:14 +msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:19 +msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:29 +msgid "Additionally, it's best practice to indicate any known lower or upper bounds." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:31 +msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:41 +msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:51 +msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:56 +msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:64 +#: ../source/tutorials/installing-packages.rst:460 +msgid "Requirements files" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:66 +msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:69 +msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:73 +msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:78 +msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:84 +msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:90 +msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:6 +msgid "pip vs easy_install" +msgstr "pip проти easy_install" + +#: ../source/discussions/pip-vs-easy-install.rst:9 +msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:14 +msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:22 +msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**pip**" +msgstr "**pip**" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**easy_install**" +msgstr "**easy_install**" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +msgid "Installs from :term:`Wheels `" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Yes" +msgstr "Так" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:30 +#: ../source/discussions/pip-vs-easy-install.rst:32 +#: ../source/discussions/pip-vs-easy-install.rst:35 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:51 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "No" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Uninstall Packages" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Yes (``python -m pip uninstall``)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Dependency Overrides" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Yes (:ref:`Requirements Files `)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "List Installed Packages" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:38 +msgid ":pep:`438` Support" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Installation format" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "'Flat' packages with :file:`egg-info` metadata." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Encapsulated Egg format" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:44 +msgid "sys.path modification" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:48 +msgid "Installs from :term:`Eggs `" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "`pylauncher support`_" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "Yes [1]_" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:54 +msgid ":ref:`Multi-version Installs`" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Exclude scripts during install" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "per project index" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Only in virtualenv" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Yes, via setup.cfg" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:68 +msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:5 +msgid "Wheel vs Egg" +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:7 +msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:11 +msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:14 +msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:17 +msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:20 +msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:22 +msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:26 +msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:31 +msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:34 +msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:38 +msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:41 +msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:47 +msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." +msgstr "" + +#: ../source/glossary.rst:3 +msgid "Glossary" +msgstr "" + +#: ../source/glossary.rst:8 +msgid "Binary Distribution" +msgstr "" + +#: ../source/glossary.rst:11 +msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." +msgstr "" + +#: ../source/glossary.rst:14 +msgid "Built Distribution" +msgstr "" + +#: ../source/glossary.rst:17 +msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." +msgstr "" + +#: ../source/glossary.rst:26 +msgid "Distribution Package" +msgstr "" + +#: ../source/glossary.rst:29 +msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." +msgstr "" + +#: ../source/glossary.rst:34 +msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." +msgstr "" + +#: ../source/glossary.rst:41 +msgid "Egg" +msgstr "" + +#: ../source/glossary.rst:44 +msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" +msgstr "" + +#: ../source/glossary.rst:49 +msgid "Extension Module" +msgstr "" + +#: ../source/glossary.rst:52 +msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." +msgstr "" + +#: ../source/glossary.rst:59 +msgid "Known Good Set (KGS)" +msgstr "" + +#: ../source/glossary.rst:62 +msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." +msgstr "" + +#: ../source/glossary.rst:68 +msgid "Import Package" +msgstr "" + +#: ../source/glossary.rst:71 +msgid "A Python module which can contain other modules or recursively, other packages." +msgstr "" + +#: ../source/glossary.rst:74 +msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." +msgstr "" + +#: ../source/glossary.rst:78 +msgid "Module" +msgstr "" + +#: ../source/glossary.rst:81 +msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." +msgstr "" + +#: ../source/glossary.rst:84 +msgid "Package Index" +msgstr "" + +#: ../source/glossary.rst:87 +msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." +msgstr "" + +#: ../source/glossary.rst:90 +msgid "Per Project Index" +msgstr "" + +#: ../source/glossary.rst:93 +msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." +msgstr "" + +#: ../source/glossary.rst:97 +msgid "Project" +msgstr "" + +#: ../source/glossary.rst:100 +msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." +msgstr "" + +#: ../source/glossary.rst:104 +msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." +msgstr "" + +#: ../source/glossary.rst:110 +msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." +msgstr "" + +#: ../source/glossary.rst:115 +msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." +msgstr "" + +#: ../source/glossary.rst:121 +msgid "Pure Module" +msgstr "" + +#: ../source/glossary.rst:124 +msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." +msgstr "" + +#: ../source/glossary.rst:127 +msgid "Python Packaging Authority (PyPA)" +msgstr "" + +#: ../source/glossary.rst:130 +msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." +msgstr "" + +#: ../source/glossary.rst:139 +msgid "Python Package Index (PyPI)" +msgstr "" + +#: ../source/glossary.rst:142 +msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." +msgstr "" + +#: ../source/glossary.rst:145 +msgid "pypi.org" +msgstr "" + +#: ../source/glossary.rst:148 +msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." +msgstr "" + +#: ../source/glossary.rst:152 +msgid "pyproject.toml" +msgstr "" + +#: ../source/glossary.rst:155 +msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." +msgstr "" + +#: ../source/glossary.rst:157 +msgid "Release" +msgstr "" + +#: ../source/glossary.rst:160 +msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." +msgstr "" + +#: ../source/glossary.rst:163 +msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." +msgstr "" + +#: ../source/glossary.rst:168 +msgid "Requirement" +msgstr "" + +#: ../source/glossary.rst:171 +msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." +msgstr "" + +#: ../source/glossary.rst:177 +msgid "Requirement Specifier" +msgstr "" + +#: ../source/glossary.rst:180 +msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" +msgstr "" + +#: ../source/glossary.rst:187 +msgid "Requirements File" +msgstr "" + +#: ../source/glossary.rst:190 +msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." +msgstr "" + +#: ../source/glossary.rst:194 +#: ../source/guides/distributing-packages-using-setuptools.rst:56 +msgid "setup.py" +msgstr "" + +#: ../source/glossary.rst:195 +#: ../source/guides/distributing-packages-using-setuptools.rst:77 +msgid "setup.cfg" +msgstr "" + +#: ../source/glossary.rst:198 +msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." +msgstr "" + +#: ../source/glossary.rst:201 +msgid "Source Archive" +msgstr "" + +#: ../source/glossary.rst:204 +msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:208 +msgid "Source Distribution (or \"sdist\")" +msgstr "" + +#: ../source/glossary.rst:211 +msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:216 +msgid "System Package" +msgstr "" + +#: ../source/glossary.rst:219 +msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." +msgstr "" + +#: ../source/glossary.rst:222 +msgid "Version Specifier" +msgstr "" + +#: ../source/glossary.rst:225 +msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." +msgstr "" + +#: ../source/glossary.rst:231 +msgid "Virtual Environment" +msgstr "" + +#: ../source/glossary.rst:234 +msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/glossary.rst:238 +msgid "Wheel" +msgstr "" + +#: ../source/glossary.rst:241 +msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." +msgstr "" + +#: ../source/glossary.rst:244 +msgid "Working Set" +msgstr "" + +#: ../source/glossary.rst:247 +msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:3 +msgid "Analyzing PyPI package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:5 +msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:15 +#: ../source/guides/supporting-windows-using-appveyor.rst:18 +msgid "Background" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:17 +msgid "PyPI does not display download statistics for a number of reasons: [#]_" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:19 +msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:24 +msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:27 +msgid "``pip``'s download cache (lowers download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:28 +msgid "Internal or unofficial mirrors (can both raise or lower download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:29 +msgid "Packages not hosted on PyPI (for comparisons sake)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:30 +msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:32 +msgid "Known historical data quality issues (lowers download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:34 +msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:38 +msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:43 +msgid "Public dataset" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:45 +msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:50 +msgid "Getting set up" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:52 +msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:58 +msgid "Navigate to the `BigQuery web UI`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:59 +msgid "Create a new project." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:60 +msgid "Enable the `BigQuery API `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:63 +msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:69 +msgid "Data schema" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:71 +msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +msgid "Column" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/guides/using-manifest-in.rst:67 +#: ../source/specifications/core-metadata.rst:185 +msgid "Description" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/specifications/direct-url.rst:226 +msgid "Examples" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "timestamp" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "Date and time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "``2020-03-09 00:33:03 UTC``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "file.project" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "Project name" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "``pipenv``, ``nose``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "file.version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "Package version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "``0.1.6``, ``1.4.2``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "details.installer.name" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "Installer" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "pip, `bandersnatch`_" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "details.python" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "Python version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "``2.7.12``, ``3.6.4``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:93 +msgid "Useful queries" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:95 +msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:97 +msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:102 +msgid "Counting package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:104 +msgid "The following query counts the total number of downloads for the project \"pytest\"." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:119 +#: ../source/guides/analyzing-pypi-package-downloads.rst:140 +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "num_downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:121 +msgid "26190085" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:124 +msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:142 +msgid "24334215" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:146 +msgid "Package downloads over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:148 +msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +msgid "month" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "1956741" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "2018-01-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2344692" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2017-12-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "1730398" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "2017-11-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2047310" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2017-10-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "1744443" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "2017-09-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "1916952" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "2017-08-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:184 +msgid "Python versions over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:186 +msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "python" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "3.7" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "18051328726" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "3.6" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "9635067203" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "3.8" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "7781904681" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "2.7" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "6381252241" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "null" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "2026630299" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "3.5" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "1894153540" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:221 +msgid "Caveats" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:223 +msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:231 +msgid "Additional tools" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:233 +msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:237 +msgid "``google-cloud-bigquery``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:239 +msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:267 +msgid "``pypinfo``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:269 +msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:273 +msgid "Install `pypinfo`_ using pip." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:279 +msgid "Usage:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:295 +msgid "``pandas-gbq``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:297 +msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:301 +#: ../source/specifications/binary-distribution-format.rst:459 +msgid "References" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:303 +msgid "`PyPI Download Counts deprecation email `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:304 +msgid "`PyPI BigQuery dataset announcement email `__" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:3 +msgid "Creating and discovering plugins" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:5 +msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:10 +msgid "There are three major approaches to doing automatic plugin discovery:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:12 +msgid "`Using naming convention`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:13 +msgid "`Using namespace packages`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:14 +msgid "`Using package metadata`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:18 +msgid "Using naming convention" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:20 +msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:38 +msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:48 +msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:59 +msgid "Using namespace packages" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:61 +msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:89 +msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:101 +msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:115 +msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:121 +msgid "Using package metadata" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:123 +msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:128 +msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:139 +msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:154 +msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:163 +msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:166 +msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:170 +msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:5 +msgid "Packaging and distributing projects" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:7 +msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:11 +msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:15 +msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:25 +msgid "Requirements for packaging and distributing" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:26 +msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:29 +msgid "Install \"twine\" [1]_:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:43 +msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:49 +msgid "Configuring your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:53 +msgid "Initial files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:58 +msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:63 +msgid ":file:`setup.py` serves two primary functions:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:65 +msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:71 +msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:79 +msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:86 +msgid "README.rst / README.md" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:88 +msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:95 +msgid "For an example, see `README.md `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:99 +msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:108 +msgid "MANIFEST.in" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:110 +msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:115 +msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:119 +msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:122 +msgid "LICENSE.txt" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:124 +msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:130 +msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:135 +msgid "" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:137 +msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:141 +msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:149 +msgid "setup() args" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:151 +msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:155 +msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:164 +msgid "name" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:170 +msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:174 +msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:176 +msgid "Start & end with an ASCII letter or digit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:178 +msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:190 +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "version" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:196 +msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:200 +msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:203 +msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:206 +msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:214 +msgid "description" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:222 +msgid "Give a short and long description for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:224 +msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:229 +msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:235 +msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:245 +msgid "url" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:252 +msgid "Give a homepage URL for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:256 +msgid "author" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:263 +msgid "Provide details about the author." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:267 +msgid "license" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:273 +msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:279 +msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:287 +msgid "classifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:316 +msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:319 +msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:327 +msgid "keywords" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:333 +msgid "List keywords that describe your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:337 +msgid "project_urls" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:349 +msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:355 +msgid "packages" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:361 +msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:370 +msgid "py_modules" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:376 +msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:388 +msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:392 +msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:398 +msgid "python_requires" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:400 +msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:407 +msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:412 +msgid "And so on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:416 +msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:422 +msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:431 +msgid "package_data" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:440 +msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:445 +msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:449 +msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:457 +msgid "data_files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:463 +msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:469 +msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:479 +msgid "For more information see the distutils section on `Installing Additional Files `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:484 +msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:491 +msgid "scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:493 +msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:500 +msgid "entry_points" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:509 +msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:512 +msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:516 +msgid "The most commonly used entry point is \"console_scripts\" (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:521 +msgid "console_scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:531 +msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:538 +msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:545 +msgid "Choosing a versioning scheme" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:548 +msgid "Standards compliance for interoperability" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:550 +msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:556 +msgid "Here are some examples of compliant version numbers::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:567 +msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:573 +msgid "Scheme choices" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:576 +msgid "Semantic versioning (preferred)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:578 +msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:582 +msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:585 +msgid "MAJOR version when they make incompatible API changes," +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:586 +msgid "MINOR version when they add functionality in a backwards-compatible manner, and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:587 +msgid "MAINTENANCE version when they make backwards-compatible bug fixes." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:589 +msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:594 +msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:598 +msgid "Date based versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:600 +msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:604 +msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:607 +msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:611 +msgid "Serial versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:613 +msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:616 +msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:621 +msgid "Hybrid schemes" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:623 +msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:629 +msgid "Pre-release versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:631 +msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:634 +msgid "zero or more dev releases (denoted with a \".devN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:635 +msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:636 +msgid "zero or more beta releases (denoted with a \".bN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:637 +msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:639 +msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:644 +msgid "Local version identifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:646 +msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:653 +msgid "A local version identifier takes the form ``+``. For example::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:661 +msgid "Working in \"development mode\"" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:663 +msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:667 +msgid "Assuming you're in the root of your project directory, then run:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:674 +msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:680 +msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:688 +msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:692 +msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:697 +msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:701 +msgid "Lastly, if you don't want to install any dependencies at all, you can run::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:706 +msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:713 +msgid "Packaging your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:715 +msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:720 +msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:737 +msgid "Source distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:739 +msgid "Minimally, you should create a :term:`Source Distribution `:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:755 +msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:763 +msgid "Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:765 +msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:770 +msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:773 +msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:776 +msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:785 +msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:792 +msgid "Pure Python Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:794 +msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:797 +#: ../source/guides/distributing-packages-using-setuptools.rst:826 +msgid "To build the wheel:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:811 +msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:815 +msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:821 +msgid "Platform Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:823 +msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:841 +msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:847 +msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:855 +msgid "Uploading your Project to PyPI" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:857 +msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:861 +msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:866 +msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:871 +msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:877 +msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:888 +msgid "Create an account" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:890 +msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:894 +msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:897 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:901 +msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:904 +msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:913 +msgid "**Be aware that this stores your token in plaintext.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:915 +#: ../source/guides/migrating-to-pypi-org.rst:70 +#: ../source/guides/migrating-to-pypi-org.rst:109 +#: ../source/guides/using-testpypi.rst:83 +msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:921 +msgid "Upload your distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:923 +msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:926 +msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:930 +msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:937 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:944 +#: ../source/tutorials/installing-packages.rst:663 +msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:950 +msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:5 +msgid "Dropping support for older Python versions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:7 +msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:9 +msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:12 +msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:14 +msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:17 +msgid "Requirements" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:19 +msgid "This workflow requires that:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:21 +msgid "The publisher is using the latest version of :ref:`setuptools`," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:22 +msgid "The latest version of :ref:`twine` is used to upload the package," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:23 +msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:26 +msgid "Dealing with the universal wheels" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:28 +msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:36 +msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:48 +msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:53 +msgid "Defining the Python version required" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:56 +msgid "1. Download the newest version of Setuptools" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:58 +msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:60 +msgid "Steps:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:74 +msgid "`setuptools` version should be above 24.0.0." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:77 +msgid "2. Specify the version ranges for supported Python distributions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:79 +msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:81 +#: ../source/specifications/core-metadata.rst:139 +#: ../source/specifications/core-metadata.rst:463 +#: ../source/specifications/core-metadata.rst:487 +#: ../source/specifications/core-metadata.rst:527 +#: ../source/specifications/core-metadata.rst:550 +#: ../source/specifications/core-metadata.rst:583 +#: ../source/specifications/core-metadata.rst:693 +#: ../source/specifications/core-metadata.rst:722 +msgid "Examples::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:86 +msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:101 +msgid "3. Validating the Metadata before publishing" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:103 +msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:105 +msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:108 +msgid "You can see the contents of the generated file like this::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:112 +msgid "Validate that the following is in place, before publishing the package:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:114 +msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:115 +msgid "The Requires-Python field is set and matches your specification in setup.py." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:118 +msgid "4. Using Twine to publish" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:120 +msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:122 +msgid "Make sure you are using the newest version of Twine, at least 1.9." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:125 +msgid "Dropping a Python release" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:127 +msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:129 +msgid "It must be done in this order for the automated fallback to work." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:131 +msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:133 +msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:5 +msgid "Hosting your own simple repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:8 +msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:13 +msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:29 +msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:35 +msgid "\"Manual\" repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:37 +msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:51 +msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:58 +msgid "For complete documentation of the simple repository protocol, see :pep:`503`." +msgstr "" + +#: ../source/guides/index.rst:8 +#: ../source/guides/index.rst:8 +msgid "Installing Packages:" +msgstr "" + +#: ../source/guides/index.rst:20 +#: ../source/guides/index.rst:20 +msgid "Building and Publishing Projects:" +msgstr "" + +#: ../source/guides/index.rst:38 +#: ../source/guides/index.rst:38 +msgid "Miscellaneous:" +msgstr "" + +#: ../source/guides/index.rst:4 +msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:5 +msgid "Package index mirrors and caches" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:8 +#: ../source/guides/supporting-multiple-python-versions.rst:8 +msgid "2014-12-24" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:14 +msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:17 +msgid "Three options are available in this area:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:19 +msgid "pip provides local caching options," +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:20 +msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:22 +msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:27 +msgid "Caching with pip" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:29 +msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:32 +msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:36 +msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:45 +msgid "Caching with devpi" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:47 +msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:55 +msgid "Complete mirror with bandersnatch" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:57 +msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:63 +msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:5 +msgid "Installing scientific packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:11 +msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:16 +msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:22 +msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:29 +msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:35 +msgid "Building from source" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:37 +msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:45 +msgid "Linux distribution packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:47 +msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:51 +msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:57 +msgid "Windows installers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:59 +msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:64 +msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:67 +msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:73 +msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:79 +msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:86 +msgid "macOS installers and package managers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:88 +msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:92 +msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:99 +msgid "SciPy distributions" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:101 +msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:105 +msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:109 +#: ../source/key_projects.rst:596 +msgid "Spack" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:110 +msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:119 +msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:128 +msgid "The conda cross-platform package manager" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:130 +msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:136 +msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 +msgid "Installing stand alone command line tools" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 +msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 +msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 +msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 +msgid "pipx only works with Python 3.6+." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 +msgid "``pipx`` is installed with ``pip``:" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 +msgid "You may need to restart your terminal for the path updates to take effect." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 +msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 +#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 +msgid "For example" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 +msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 +msgid "To upgrade or uninstall the package" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 +msgid "``pipx`` can be upgraded or uninstalled with pip" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 +msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 +msgid "To see the full list of commands ``pipx`` offers, run" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 +msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:5 +msgid "Installing pip/setuptools/wheel with Linux Package Managers" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:8 +msgid "2015-09-17" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:11 +msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:14 +msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:18 +msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:25 +msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:32 +msgid "Fedora" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:34 +msgid "Fedora 21:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:36 +#: ../source/guides/installing-using-linux-tools.rst:45 +#: ../source/guides/installing-using-linux-tools.rst:124 +#: ../source/guides/installing-using-linux-tools.rst:138 +#: ../source/guides/installing-using-linux-tools.rst:158 +msgid "Python 2::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:41 +msgid "Python 3: ``sudo yum install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:43 +msgid "Fedora 22:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:50 +msgid "Python 3: ``sudo dnf install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:53 +msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:63 +msgid "CentOS/RHEL" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:65 +msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:68 +msgid "To install pip and wheel for the system Python, there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:70 +msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:77 +msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:81 +msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:85 +msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:92 +msgid "To additionally upgrade setuptools, run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:97 +msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:101 +msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:104 +msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:106 +msgid "For CentOS, see here: https://www.softwarecollections.org/en/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:108 +msgid "Be aware that collections may not contain the most recent versions." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:110 +msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:116 +msgid "For example, for Python 3.4 on CentOS7/RHEL7::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:122 +msgid "openSUSE" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:129 +#: ../source/guides/installing-using-linux-tools.rst:143 +#: ../source/guides/installing-using-linux-tools.rst:162 +msgid "Python 3::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:135 +msgid "Debian/Ubuntu" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:150 +msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:156 +msgid "Arch Linux" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:168 +msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 +msgid "Installing packages using pip and virtual environments" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 +msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 +msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 +msgid "Installing pip" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 +msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 +msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 +msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 +msgid "Afterwards, you should have the newest pip installed in your user site:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 +msgid "The Python installers for Windows include pip. You should be able to access pip using:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 +msgid "You can make sure that pip is up-to-date by running:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 +msgid "Installing virtualenv" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 +msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 +msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 +msgid "Creating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 +msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 +msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 +msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 +msgid "venv will create a virtual Python installation in the ``env`` folder." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 +msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 +msgid "Activating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 +msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 +msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 +msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 +msgid "Leaving the virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 +msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 +msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 +msgid "Installing packages" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 +msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 +msgid "pip should download requests and all of its dependencies and install them:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 +msgid "Installing specific versions" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 +msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 +msgid "To install the latest ``2.x`` release of requests:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 +msgid "To install pre-release versions of packages, use the ``--pre`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 +msgid "Installing extras" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 +msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 +msgid "Installing from source" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 +msgid "pip can install a package directly from source, for example:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 +msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 +msgid "Installing from version control systems" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 +msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 +msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 +#: ../source/tutorials/installing-packages.rst:569 +msgid "Installing from local archives" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 +msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 +msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 +msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 +msgid "Using other package indexes" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 +msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 +msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 +#: ../source/tutorials/installing-packages.rst:389 +msgid "Upgrading packages" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 +msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 +msgid "Using requirements files" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 +msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 +msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 +msgid "Freezing dependencies" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 +msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 +msgid "Which will output a list of package specifiers such as:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 +msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:2 +msgid "Making a PyPI-friendly README" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:4 +msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:9 +msgid "Creating a README file" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:11 +msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:13 +msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:16 +msgid "plain text" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:17 +msgid "`reStructuredText `_ (without Sphinx extensions)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:18 +msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:21 +msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:25 +msgid "Including your README in your package's metadata" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:27 +msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:33 +msgid ":ref:`description-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:34 +msgid ":ref:`description-content-type-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:36 +msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:39 +msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:45 +msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:60 +msgid "The minimum required versions of the respective tools are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:62 +msgid "``setuptools >= 38.6.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:63 +msgid "``wheel >= 0.31.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:64 +msgid "``twine >= 1.11.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:66 +msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:72 +msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:95 +msgid "Validating reStructuredText markup" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:97 +msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:100 +msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:105 +msgid "You can check your README for markup errors before uploading as follows:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:107 +msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:122 +msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:125 +msgid "Run ``twine check`` on the sdist and wheel::" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:129 +msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:4 +msgid "Migrating to PyPI.org" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:6 +msgid ":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``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:12 +msgid "Publishing releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:14 +msgid "``pypi.org`` is the default upload platform as of September 2016." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:16 +msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:22 +msgid "The default upload settings switched to ``pypi.org`` in the following versions:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:24 +msgid "``twine`` 1.8.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:25 +msgid "``setuptools`` 27.0.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:26 +msgid "Python 2.7.13 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:27 +msgid "Python 3.4.6 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:28 +msgid "Python 3.5.3 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:29 +msgid "Python 3.6.0 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:31 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:48 +msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:51 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:67 +msgid "(``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.)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:73 +msgid "Registering package names & metadata" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:75 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:79 +msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:84 +msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:89 +#: ../source/guides/using-testpypi.rst:5 +msgid "Using TestPyPI" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:91 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:113 +msgid "Registering new user accounts" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:115 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:121 +msgid "Browsing packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:123 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:130 +msgid "Downloading packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:132 +msgid "``pypi.org`` is the default host for downloading packages." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:135 +msgid "Managing published packages and releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:137 +msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:5 +msgid "Multi-version installs" +msgstr "" + +#: ../source/guides/multi-version-installs.rst:8 +msgid "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``)." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:13 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:31 +msgid "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 ``python -c ''`` to invoke the application's main entry point directly." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:38 +msgid "Refer to the `pkg_resources documentation `__ for more details." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:5 +msgid "Packaging binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:8 +msgid "2013-12-08" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:10 +msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:20 +msgid "An overview of binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:23 +msgid "Use cases" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:25 +msgid "The typical use cases for binary extensions break down into just three conventional categories:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:28 +msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:39 +msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:47 +msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:56 +msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:61 +msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:71 +msgid "Disadvantages" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:73 +msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:80 +msgid "This means that binary extensions:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:82 +msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:85 +msgid "may not be compatible with different builds of the CPython reference interpreter" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:88 +msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:91 +msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:96 +msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:101 +msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:108 +msgid "Alternatives to handcoded accelerator modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:110 +msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:115 +msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:122 +msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:132 +msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:141 +msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:150 +msgid "Alternatives to handcoded wrapper modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:152 +msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:158 +msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:162 +msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:168 +msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:175 +msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:181 +msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:185 +msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:189 +msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:203 +msgid "Alternatives for low level system access" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:205 +msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:213 +msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:222 +msgid "Implementing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:224 +msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:241 +msgid "Building binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:244 +msgid "Building extensions for multiple platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:246 +msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:256 +msgid "Binary extensions for Windows" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:258 +msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:263 +msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:269 +msgid "To set up a build environment for binary extensions, the steps are as follows:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:271 +msgid "For Python 2.7" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:273 +msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:276 +msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:278 +#: ../source/guides/packaging-binary-extensions.rst:288 +#: ../source/guides/packaging-binary-extensions.rst:295 +msgid "Done." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:280 +msgid "For Python 3.4" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:282 +msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:285 +msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:287 +msgid "Set DISTUTILS_USE_SDK=1" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:290 +msgid "For Python 3.5" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:292 +msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:297 +msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:301 +msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:305 +msgid "Binary extensions for Linux" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:307 +msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:313 +msgid "Binary extensions for macOS" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:315 +msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:325 +msgid "Publishing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:327 +msgid "For interim guidance on this topic, see the discussion in `this issue `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:343 +msgid "Additional resources" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:345 +msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:352 +msgid "Cross-platform wheel generation with scikit-build" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:354 +msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:362 +msgid "Introduction to C/C++ extension modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:364 +msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:367 +msgid "`What are (c)python extension modules? `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:368 +msgid "`Releasing the gil `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:369 +msgid "`Writing cpython extension modules using C++ `_" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:3 +msgid "Packaging namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:5 +msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:24 +msgid "And you use this package in your code like so::" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:29 +msgid "Then you can break these sub-packages into two separate distributions:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:46 +msgid "Each sub-package can now be separately installed, used, and versioned." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:48 +msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:58 +msgid "Creating a namespace package" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:60 +msgid "There are currently three different approaches to creating namespace packages:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:62 +msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:66 +msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:69 +msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:73 +msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:80 +msgid "Native namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:82 +msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:97 +msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:102 +msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:117 +msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:123 +msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:129 +msgid "pkgutil-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:131 +msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:136 +msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:148 +#: ../source/guides/packaging-namespace-packages.rst:194 +msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:155 +#: ../source/guides/packaging-namespace-packages.rst:201 +msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:160 +msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:171 +msgid "pkg_resources-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:173 +msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:182 +msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:206 +msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:216 +msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:223 +msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:237 +msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 +msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 +msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 +msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 +msgid "Saving credentials on GitHub" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 +msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 +msgid "Let's begin! 🚀" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 +msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 +msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 +msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 +msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 +msgid "Creating a workflow definition" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 +msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 +msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 +msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 +msgid "Defining a workflow job environment" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 +msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 +msgid "Checking out the project and building distributions" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 +msgid "Then, add the following under the ``build-n-publish`` section:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 +msgid "This will download your repository into the CI runner and then install and activate Python 3.7." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 +msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 +msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 +msgid "So add this to the steps list:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 +msgid "Publishing the distribution to PyPI and TestPyPI" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 +msgid "Finally, add the following steps at the end:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 +msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 +msgid "That's all, folks!" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 +msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:5 +msgid "Single-sourcing the package version" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:8 +msgid "There are many techniques to maintain a single source of truth for the version number of your project:" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:11 +msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:38 +msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:47 +msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:52 +msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:55 +msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:58 +msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:65 +msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:76 +msgid "Example using this technique: `warehouse `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:78 +msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:86 +msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:91 +msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:95 +msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:110 +msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:114 +msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:128 +msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:134 +msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:138 +msgid "Example using this technique: `setuptools `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:141 +msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:155 +msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:161 +msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:5 +msgid "Supporting multiple Python versions" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:37 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:43 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:49 +msgid "Automated testing and continuous integration" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:51 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:60 +msgid "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:" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:66 +msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:69 +msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:80 +msgid "Both `Travis CI`_ 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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:85 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:89 +msgid "Tools for single-source Python packages" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:91 +msgid "`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_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:100 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:107 +msgid "a Python 2 (by syntax) module in a Python 3 project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:108 +msgid "a Python 3 (by syntax) module in a *Python 2* project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:110 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:117 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:124 +msgid "What's in which Python?" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:126 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:3 +msgid "Supporting Windows using Appveyor" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:6 +msgid "2015-12-03" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:8 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:20 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:24 +msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:30 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:38 +msgid "Setting up" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:40 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:45 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:49 +msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:54 +msgid "Adding Appveyor support to your project" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:61 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:69 +msgid "appveyor.yml" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:75 +msgid "This file can be downloaded from `here `__." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:77 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:80 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:88 +msgid "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``)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:94 +msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:97 +msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:100 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:109 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:114 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:119 +msgid "Support script" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:121 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:126 +msgid "`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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:133 +msgid "You can simply download the batch file and include it in your project unchanged." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:137 +msgid "Access to the built wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:139 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:147 +msgid "Additional notes" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:150 +msgid "Testing with tox" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:152 +msgid "Many projects use the `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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:156 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:160 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:165 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:170 +msgid "``DISTUTILS_USE_SDK``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:171 +msgid "``MSSdk``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:172 +msgid "``INCLUDE``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:173 +msgid "``LIB``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:175 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:181 +msgid "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 Travis or 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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:188 +msgid "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``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:192 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:197 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:203 +msgid "Automatically uploading wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:205 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:210 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:216 +msgid "External dependencies" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:218 +msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:221 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:230 +msgid "Support scripts" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:232 +msgid "For reference, the SDK setup support script is listed here:" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:234 +msgid "``appveyor-sample/build.cmd``" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:5 +msgid "Tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:7 +msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:12 +msgid "Application dependency management" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:14 +msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:18 +msgid "When ``pipenv`` does not meet your use case, consider other tools like:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:20 +msgid ":ref:`pip`" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:22 +msgid "`pip-tools `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:24 +msgid "`Poetry `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:27 +msgid "Installation tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:29 +msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:34 +msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:37 +msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:40 +msgid ":ref:`buildout`: primarily focused on the web development community" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:42 +msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:47 +msgid "Packaging tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:49 +msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:52 +msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:56 +msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:61 +msgid "Publishing platform migration" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:63 +msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:67 +msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:72 +msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:77 +msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:82 +msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:88 +msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:93 +msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:102 +msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:107 +msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:5 +msgid "Including files in source distributions with ``MANIFEST.in``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:7 +msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:17 +msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:22 +msgid "How files are included in an sdist" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:24 +msgid "The following files are included in a source distribution by default:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:26 +msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:28 +msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:30 +msgid "scripts specified by the ``scripts`` ``setup()`` argument" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:31 +msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:33 +msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:35 +msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:37 +msgid "all files matching the pattern :file:`test/test*.py`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:38 +msgid ":file:`setup.py` (or whatever you called your setup script)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:39 +msgid ":file:`setup.cfg`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:40 +msgid ":file:`README`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:41 +msgid ":file:`README.txt`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:42 +msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:43 +msgid ":file:`README.md` (setuptools 36.4.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:44 +msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:45 +msgid ":file:`MANIFEST.in`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:47 +msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:52 +msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:60 +msgid ":file:`MANIFEST.in` commands" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:62 +msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:67 +msgid "Command" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid ":samp:`include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid "Add all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid ":samp:`exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid "Remove all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid ":samp:`global-include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid "Add all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid ":samp:`global-exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid "Remove all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid ":samp:`graft {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid "Add all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid ":samp:`prune {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid "Remove all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:79 +msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:87 +msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:91 +msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:95 +msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:101 +msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." +msgstr "" + +#: ../source/guides/using-testpypi.rst:7 +msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" +msgstr "" + +#: ../source/guides/using-testpypi.rst:13 +msgid "Registering your account" +msgstr "" + +#: ../source/guides/using-testpypi.rst:15 +msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." +msgstr "" + +#: ../source/guides/using-testpypi.rst:19 +msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." +msgstr "" + +#: ../source/guides/using-testpypi.rst:24 +msgid "Using TestPyPI with Twine" +msgstr "" + +#: ../source/guides/using-testpypi.rst:26 +msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:33 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/using-testpypi.rst:39 +msgid "Using TestPyPI with pip" +msgstr "" + +#: ../source/guides/using-testpypi.rst:41 +msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:56 +msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" +msgstr "" + +#: ../source/guides/using-testpypi.rst:73 +msgid "Setting up TestPyPI in :file:`.pypirc`" +msgstr "" + +#: ../source/guides/using-testpypi.rst:75 +msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" +msgstr "" + +#: ../source/index.rst:3 +#: ../source/key_projects.rst:181 +msgid "Python Packaging User Guide" +msgstr "" + +#: ../source/index.rst:5 +msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." +msgstr "" + +#: ../source/index.rst:5 +msgid "python, packaging, guide, tutorial" +msgstr "" + +#: ../source/index.rst:24 +msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." +msgstr "" + +#: ../source/index.rst:28 +msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" +msgstr "" + +#: ../source/index.rst:36 +msgid "Get started" +msgstr "" + +#: ../source/index.rst:38 +msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" +msgstr "" + +#: ../source/index.rst:41 +msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" +msgstr "" + +#: ../source/index.rst:43 +msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" +msgstr "" + +#: ../source/index.rst:45 +msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" +msgstr "" + +#: ../source/index.rst:47 +msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" +msgstr "" + +#: ../source/index.rst:52 +msgid "Learn more" +msgstr "" + +#: ../source/index.rst:54 +msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" +msgstr "" + +#: ../source/index.rst:56 +msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/index.rst:58 +msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." +msgstr "" + +#: ../source/index.rst:60 +msgid "The :doc:`specifications/index` section for packaging interoperability specifications." +msgstr "" + +#: ../source/index.rst:62 +msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." +msgstr "" + +#: ../source/key_projects.rst:6 +msgid "Project Summaries" +msgstr "" + +#: ../source/key_projects.rst:8 +msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." +msgstr "" + +#: ../source/key_projects.rst:14 +msgid "PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:19 +msgid "bandersnatch" +msgstr "" + +#: ../source/key_projects.rst:21 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:25 +msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." +msgstr "" + +#: ../source/key_projects.rst:35 +msgid "build" +msgstr "" + +#: ../source/key_projects.rst:37 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:42 +msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." +msgstr "" + +#: ../source/key_projects.rst:49 +msgid "cibuildwheel" +msgstr "" + +#: ../source/key_projects.rst:51 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" +msgstr "" + +#: ../source/key_projects.rst:58 +msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." +msgstr "" + +#: ../source/key_projects.rst:64 +msgid "distlib" +msgstr "" + +#: ../source/key_projects.rst:66 +msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:71 +msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." +msgstr "" + +#: ../source/key_projects.rst:80 +msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." +msgstr "" + +#: ../source/key_projects.rst:90 +msgid "packaging" +msgstr "" + +#: ../source/key_projects.rst:92 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:97 +msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." +msgstr "" + +#: ../source/key_projects.rst:99 +msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." +msgstr "" + +#: ../source/key_projects.rst:107 +msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." +msgstr "" + +#: ../source/key_projects.rst:119 +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "pip" +msgstr "" + +#: ../source/key_projects.rst:121 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:126 +msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." +msgstr "" + +#: ../source/key_projects.rst:129 +msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." +msgstr "" + +#: ../source/key_projects.rst:137 +msgid "Pipenv" +msgstr "" + +#: ../source/key_projects.rst:139 +msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:144 +msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." +msgstr "" + +#: ../source/key_projects.rst:148 +msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." +msgstr "" + +#: ../source/key_projects.rst:159 +msgid "Pipfile" +msgstr "" + +#: ../source/key_projects.rst:161 +msgid "`Source `__" +msgstr "" + +#: ../source/key_projects.rst:163 +msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." +msgstr "" + +#: ../source/key_projects.rst:170 +msgid "pipx" +msgstr "" + +#: ../source/key_projects.rst:172 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:176 +msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." +msgstr "" + +#: ../source/key_projects.rst:183 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:187 +msgid "This guide!" +msgstr "" + +#: ../source/key_projects.rst:192 +msgid "readme_renderer" +msgstr "" + +#: ../source/key_projects.rst:194 +msgid "`GitHub and docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:197 +msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." +msgstr "" + +#: ../source/key_projects.rst:208 +msgid "setuptools" +msgstr "" + +#: ../source/key_projects.rst:210 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:215 +msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." +msgstr "" + +#: ../source/key_projects.rst:220 +msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." +msgstr "" + +#: ../source/key_projects.rst:227 +msgid "trove-classifiers" +msgstr "" + +#: ../source/key_projects.rst:229 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:233 +msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." +msgstr "" + +#: ../source/key_projects.rst:239 +msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." +msgstr "" + +#: ../source/key_projects.rst:253 +msgid "twine" +msgstr "" + +#: ../source/key_projects.rst:255 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:260 +msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." +msgstr "" + +#: ../source/key_projects.rst:270 +#: ../source/overview.rst:415 +msgid "virtualenv" +msgstr "" + +#: ../source/key_projects.rst:272 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:277 +msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/key_projects.rst:290 +msgid "Warehouse" +msgstr "" + +#: ../source/key_projects.rst:292 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:296 +msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." +msgstr "" + +#: ../source/key_projects.rst:304 +msgid "wheel" +msgstr "" + +#: ../source/key_projects.rst:306 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:311 +msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." +msgstr "" + +#: ../source/key_projects.rst:315 +msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." +msgstr "" + +#: ../source/key_projects.rst:324 +msgid "Non-PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:329 +msgid "bento" +msgstr "" + +#: ../source/key_projects.rst:331 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:336 +msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." +msgstr "" + +#: ../source/key_projects.rst:344 +msgid "buildout" +msgstr "" + +#: ../source/key_projects.rst:346 +msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:351 +msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." +msgstr "" + +#: ../source/key_projects.rst:358 +msgid "conda" +msgstr "" + +#: ../source/key_projects.rst:360 +msgid "`Docs `__" +msgstr "" + +#: ../source/key_projects.rst:362 +msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." +msgstr "" + +#: ../source/key_projects.rst:369 +msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." +msgstr "" + +#: ../source/key_projects.rst:373 +msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." +msgstr "" + +#: ../source/key_projects.rst:386 +msgid "devpi" +msgstr "" + +#: ../source/key_projects.rst:388 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:392 +msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." +msgstr "" + +#: ../source/key_projects.rst:401 +msgid "flit" +msgstr "" + +#: ../source/key_projects.rst:403 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:407 +msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." +msgstr "" + +#: ../source/key_projects.rst:412 +msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." +msgstr "" + +#: ../source/key_projects.rst:422 +msgid "enscons" +msgstr "" + +#: ../source/key_projects.rst:424 +msgid "`Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:428 +msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." +msgstr "" + +#: ../source/key_projects.rst:443 +msgid "Hashdist" +msgstr "" + +#: ../source/key_projects.rst:445 +msgid "`Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:448 +msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." +msgstr "" + +#: ../source/key_projects.rst:460 +msgid "hatch" +msgstr "" + +#: ../source/key_projects.rst:462 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:465 +msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." +msgstr "" + +#: ../source/key_projects.rst:475 +msgid "multibuild" +msgstr "" + +#: ../source/key_projects.rst:477 +msgid "`GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:479 +msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." +msgstr "" + +#: ../source/key_projects.rst:485 +msgid "pex" +msgstr "" + +#: ../source/key_projects.rst:487 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:491 +msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." +msgstr "" + +#: ../source/key_projects.rst:500 +msgid "pip-tools" +msgstr "" + +#: ../source/key_projects.rst:502 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:505 +msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." +msgstr "" + +#: ../source/key_projects.rst:517 +msgid "piwheels" +msgstr "" + +#: ../source/key_projects.rst:519 +msgid "`Website `__ | `Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:523 +msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." +msgstr "" + +#: ../source/key_projects.rst:532 +msgid "poetry" +msgstr "" + +#: ../source/key_projects.rst:534 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:538 +msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." +msgstr "" + +#: ../source/key_projects.rst:548 +msgid "pypiserver" +msgstr "" + +#: ../source/key_projects.rst:550 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:554 +msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." +msgstr "" + +#: ../source/key_projects.rst:564 +msgid "scikit-build" +msgstr "" + +#: ../source/key_projects.rst:566 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:570 +msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." +msgstr "" + +#: ../source/key_projects.rst:582 +msgid "shiv" +msgstr "" + +#: ../source/key_projects.rst:584 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:588 +msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." +msgstr "" + +#: ../source/key_projects.rst:598 +msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" +msgstr "" + +#: ../source/key_projects.rst:603 +msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." +msgstr "" + +#: ../source/key_projects.rst:611 +msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." +msgstr "" + +#: ../source/key_projects.rst:617 +msgid "zest.releaser" +msgstr "" + +#: ../source/key_projects.rst:619 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:623 +msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." +msgstr "" + +#: ../source/key_projects.rst:630 +msgid "Standard Library Projects" +msgstr "" + +#: ../source/key_projects.rst:635 +msgid "ensurepip" +msgstr "" + +#: ../source/key_projects.rst:637 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:640 +msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." +msgstr "" + +#: ../source/key_projects.rst:649 +msgid "distutils" +msgstr "" + +#: ../source/key_projects.rst:651 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:654 +msgid "The original Python packaging system, added to the standard library in Python 2.0." +msgstr "" + +#: ../source/key_projects.rst:657 +msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." +msgstr "" + +#: ../source/key_projects.rst:670 +msgid "venv" +msgstr "" + +#: ../source/key_projects.rst:672 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:675 +msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/news.rst:2 +msgid "News" +msgstr "" + +#: ../source/news.rst:5 +msgid "September 2019" +msgstr "" + +#: ../source/news.rst:6 +msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" +msgstr "" + +#: ../source/news.rst:9 +msgid "August 2019" +msgstr "" + +#: ../source/news.rst:10 +msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" +msgstr "" + +#: ../source/news.rst:13 +msgid "July 2019" +msgstr "" + +#: ../source/news.rst:14 +msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" +msgstr "" + +#: ../source/news.rst:15 +msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" +msgstr "" + +#: ../source/news.rst:16 +msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" +msgstr "" + +#: ../source/news.rst:17 +msgid "Updated directory layout examples for consistency. (:pr:`611`)" +msgstr "" + +#: ../source/news.rst:18 +msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" +msgstr "" + +#: ../source/news.rst:21 +msgid "June 2019" +msgstr "" + +#: ../source/news.rst:22 +msgid "Fixed some typos. (:pr:`620`)" +msgstr "" + +#: ../source/news.rst:25 +msgid "May 2019" +msgstr "" + +#: ../source/news.rst:26 +msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" +msgstr "" + +#: ../source/news.rst:27 +msgid "Added a MANIFEST.in guide page. (:pr:`609`)" +msgstr "" + +#: ../source/news.rst:30 +msgid "April 2019" +msgstr "" + +#: ../source/news.rst:31 +msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" +msgstr "" + +#: ../source/news.rst:32 +msgid "Reduced emphasis on virtualenv. (:pr:`606`)" +msgstr "" + +#: ../source/news.rst:35 +msgid "March 2019" +msgstr "" + +#: ../source/news.rst:36 +msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" +msgstr "" + +#: ../source/news.rst:37 +msgid "Covered RTD details for contributing. (:pr:`600`)" +msgstr "" + +#: ../source/news.rst:40 +msgid "February 2019" +msgstr "" + +#: ../source/news.rst:41 +msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" +msgstr "" + +#: ../source/news.rst:42 +msgid "Added instructions to install Python CLI applications. (:pr:`594`)" +msgstr "" + +#: ../source/news.rst:45 +msgid "January 2019" +msgstr "" + +#: ../source/news.rst:46 +msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" +msgstr "" + +#: ../source/news.rst:47 +msgid "Updated Sphinx and Nox. (:pr:`591`)" +msgstr "" + +#: ../source/news.rst:48 +msgid "Referenced Twine from Python3. (:pr:`581`)" +msgstr "" + +#: ../source/news.rst:51 +msgid "December 2018" +msgstr "" + +#: ../source/news.rst:52 +msgid "No programmers in the office!" +msgstr "" + +#: ../source/news.rst:55 +msgid "November 2018" +msgstr "" + +#: ../source/news.rst:56 +msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" +msgstr "" + +#: ../source/news.rst:57 +msgid "Changed bumpversion to bump2version. (:pr:`572`)" +msgstr "" + +#: ../source/news.rst:58 +msgid "Added single-sourcing package version example. (:pr:`573`)" +msgstr "" + +#: ../source/news.rst:59 +msgid "Added a guide for creating documentation. (:pr:`568`)" +msgstr "" + +#: ../source/news.rst:62 +msgid "October 2018" +msgstr "" + +#: ../source/news.rst:63 +msgid "Updated Nox package name. (:pr:`566`)" +msgstr "" + +#: ../source/news.rst:64 +msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" +msgstr "" + +#: ../source/news.rst:67 +msgid "September 2018" +msgstr "" + +#: ../source/news.rst:68 +msgid "Added a section on checking RST markup. (:pr:`554`)" +msgstr "" + +#: ../source/news.rst:69 +msgid "Updated user installs page. (:pr:`558`)" +msgstr "" + +#: ../source/news.rst:70 +msgid "Updated Google BigQuery urls. (:pr:`556`)" +msgstr "" + +#: ../source/news.rst:71 +msgid "Replaced tar command with working command. (:pr:`552`)" +msgstr "" + +#: ../source/news.rst:72 +msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" +msgstr "" + +#: ../source/news.rst:75 +msgid "August 2018" +msgstr "" + +#: ../source/news.rst:76 +msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" +msgstr "" + +#: ../source/news.rst:77 +msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" +msgstr "" + +#: ../source/news.rst:78 +msgid "Updated Python version supported by virtualenv. (:pr:`538`)" +msgstr "" + +#: ../source/news.rst:79 +msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" +msgstr "" + +#: ../source/news.rst:82 +msgid "July 2018" +msgstr "" + +#: ../source/news.rst:84 +msgid "Improved binary extension docs. (:pr:`531`)" +msgstr "" + +#: ../source/news.rst:85 +msgid "Added scikit-build to key projects. (:pr:`530`)" +msgstr "" + +#: ../source/news.rst:88 +msgid "June 2018" +msgstr "" + +#: ../source/news.rst:90 +msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" +msgstr "" + +#: ../source/news.rst:91 +msgid "Updated Markdown descriptions explanation. (:pr:`522`)" +msgstr "" + +#: ../source/news.rst:94 +msgid "May 2018" +msgstr "" + +#: ../source/news.rst:96 +msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" +msgstr "" + +#: ../source/news.rst:97 +msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" +msgstr "" + +#: ../source/news.rst:98 +msgid "Simplified packaging tutorial. (:pr:`498`)" +msgstr "" + +#: ../source/news.rst:99 +msgid "Updated Windows users instructions for clarity. (:pr:`493`)" +msgstr "" + +#: ../source/news.rst:100 +msgid "Updated the license section description for completeness. (:pr:`492`)" +msgstr "" + +#: ../source/news.rst:101 +msgid "Added specification-style document to contributing section. (:pr:`489`)" +msgstr "" + +#: ../source/news.rst:102 +msgid "Added documentation types to contributing guide. (:pr:`485`)" +msgstr "" + +#: ../source/news.rst:105 +msgid "April 2018" +msgstr "" + +#: ../source/news.rst:107 +msgid "Added README guide. (:pr:`461`)" +msgstr "" + +#: ../source/news.rst:108 +msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" +msgstr "" + +#: ../source/news.rst:109 +msgid "Added instructions for Warehouse. (:pr:`471`)" +msgstr "" + +#: ../source/news.rst:110 +msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" +msgstr "" + +#: ../source/news.rst:111 +msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" +msgstr "" + +#: ../source/news.rst:112 +msgid "Added a guide for phasing out Python versions. (:pr:`459`)" +msgstr "" + +#: ../source/news.rst:113 +msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" +msgstr "" + +#: ../source/news.rst:116 +msgid "March 2018" +msgstr "" + +#: ../source/news.rst:118 +msgid "Updated \"installing scientific packages\". (:pr:`455`)" +msgstr "" + +#: ../source/news.rst:119 +msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" +msgstr "" + +#: ../source/news.rst:120 +msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" +msgstr "" + +#: ../source/news.rst:121 +msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" +msgstr "" + +#: ../source/news.rst:124 +msgid "February 2018" +msgstr "" + +#: ../source/news.rst:126 +msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" +msgstr "" + +#: ../source/news.rst:127 +msgid "Updated PyPI migration info. (:pr:`439`)" +msgstr "" + +#: ../source/news.rst:128 +msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" +msgstr "" + +#: ../source/news.rst:129 +msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" +msgstr "" + +#: ../source/news.rst:130 +msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" +msgstr "" + +#: ../source/news.rst:133 +msgid "January 2018" +msgstr "" + +#: ../source/news.rst:135 +msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" +msgstr "" + +#: ../source/news.rst:136 +msgid "Updated README.rst explanation. (:pr:`419`)" +msgstr "" + +#: ../source/news.rst:139 +msgid "December 2017" +msgstr "" + +#: ../source/news.rst:141 +msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" +msgstr "" + +#: ../source/news.rst:142 +msgid "Noted which fields can be used with environment markers. (:pr:`416`)" +msgstr "" + +#: ../source/news.rst:143 +msgid "Updated Requires-Python section. (:pr:`414`)" +msgstr "" + +#: ../source/news.rst:144 +msgid "Added news page. (:pr:`404`)" +msgstr "" + +#: ../source/news.rst:147 +msgid "November 2017" +msgstr "" + +#: ../source/news.rst:149 +msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" +msgstr "" + +#: ../source/news.rst:150 +msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" +msgstr "" + +#: ../source/news.rst:152 +msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:153 +msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" +msgstr "" + +#: ../source/news.rst:156 +msgid "October 2017" +msgstr "" + +#: ../source/news.rst:158 +msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:159 +msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" +msgstr "" + +#: ../source/news.rst:160 +msgid "Split the specifications page into multiple pages. (:pr:`386`)" +msgstr "" + +#: ../source/news.rst:163 +msgid "September 2017" +msgstr "" + +#: ../source/news.rst:165 +msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" +msgstr "" + +#: ../source/news.rst:167 +msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" +msgstr "" + +#: ../source/news.rst:170 +msgid "August 2017" +msgstr "" + +#: ../source/news.rst:172 +msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" +msgstr "" + +#: ../source/news.rst:173 +msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" +msgstr "" + +#: ../source/news.rst:174 +msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" +msgstr "" + +#: ../source/news.rst:177 +msgid "July 2017" +msgstr "" + +#: ../source/news.rst:179 +msgid "Added ``flit`` to the key projects list. (:pr:`358`)" +msgstr "" + +#: ../source/news.rst:180 +msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" +msgstr "" + +#: ../source/news.rst:181 +msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" +msgstr "" + +#: ../source/news.rst:182 +msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" +msgstr "" + +#: ../source/news.rst:183 +msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" +msgstr "" + +#: ../source/news.rst:186 +msgid "June 2017" +msgstr "" + +#: ../source/news.rst:188 +msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" +msgstr "" + +#: ../source/news.rst:189 +msgid "Added documentation for ``python_requires``. (:pr:`338`)" +msgstr "" + +#: ../source/news.rst:190 +msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" +msgstr "" + +#: ../source/news.rst:191 +msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" +msgstr "" + +#: ../source/news.rst:192 +msgid "Added a license section to the distributing guide. (:pr:`331`)" +msgstr "" + +#: ../source/news.rst:193 +msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" +msgstr "" + +#: ../source/news.rst:194 +msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" +msgstr "" + +#: ../source/news.rst:195 +msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" +msgstr "" + +#: ../source/news.rst:196 +msgid "Switched to the PyPA theme. (:pr:`305`)" +msgstr "" + +#: ../source/news.rst:197 +msgid "Re-organized the documentation into the new structure. (:pr:`318`)" +msgstr "" + +#: ../source/news.rst:200 +msgid "May 2017" +msgstr "" + +#: ../source/news.rst:202 +msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" +msgstr "" + +#: ../source/news.rst:203 +msgid "Added contributor and style guide. (:pr:`307`)" +msgstr "" + +#: ../source/news.rst:204 +msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" +msgstr "" + +#: ../source/news.rst:207 +msgid "April 2017" +msgstr "" + +#: ../source/news.rst:209 +msgid "Added travis configuration for testing pull requests. (:pr:`300`)" +msgstr "" + +#: ../source/news.rst:210 +msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" +msgstr "" + +#: ../source/news.rst:211 +msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" +msgstr "" + +#: ../source/news.rst:212 +msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" +msgstr "" + +#: ../source/news.rst:213 +msgid "Added a topic on namespace packages. (:pr:`290`)" +msgstr "" + +#: ../source/news.rst:214 +msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" +msgstr "" + +#: ../source/news.rst:215 +msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" +msgstr "" + +#: ../source/news.rst:216 +msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" +msgstr "" + +#: ../source/news.rst:217 +msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" +msgstr "" + +#: ../source/news.rst:219 +msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" +msgstr "" + +#: ../source/news.rst:223 +msgid "March 2017" +msgstr "" + +#: ../source/news.rst:225 +msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" +msgstr "" + +#: ../source/news.rst:228 +msgid "February 2017" +msgstr "" + +#: ../source/news.rst:230 +msgid "Added :pep:`518`. (:pr:`281`)" +msgstr "" + +#: ../source/overview.rst:3 +msgid "An Overview of Packaging for Python" +msgstr "" + +#: ../source/overview.rst:7 +msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." +msgstr "" + +#: ../source/overview.rst:12 +msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." +msgstr "" + +#: ../source/overview.rst:18 +msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." +msgstr "" + +#: ../source/overview.rst:26 +msgid "Thinking about deployment" +msgstr "" + +#: ../source/overview.rst:28 +msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" +msgstr "" + +#: ../source/overview.rst:32 +msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" +msgstr "" + +#: ../source/overview.rst:35 +msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" +msgstr "" + +#: ../source/overview.rst:37 +msgid "Is your software installed individually, or in large deployment batches?" +msgstr "" + +#: ../source/overview.rst:39 +msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." +msgstr "" + +#: ../source/overview.rst:46 +msgid "Packaging Python libraries and tools" +msgstr "" + +#: ../source/overview.rst:48 +msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/overview.rst:53 +msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." +msgstr "" + +#: ../source/overview.rst:59 +msgid "Python modules" +msgstr "" + +#: ../source/overview.rst:61 +msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." +msgstr "" + +#: ../source/overview.rst:66 +msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." +msgstr "" + +#: ../source/overview.rst:73 +msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." +msgstr "" + +#: ../source/overview.rst:78 +msgid "Python source distributions" +msgstr "" + +#: ../source/overview.rst:80 +msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." +msgstr "" + +#: ../source/overview.rst:84 +msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." +msgstr "" + +#: ../source/overview.rst:90 +msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." +msgstr "" + +#: ../source/overview.rst:95 +msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." +msgstr "" + +#: ../source/overview.rst:100 +msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." +msgstr "" + +#: ../source/overview.rst:107 +msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" +msgstr "" + +#: ../source/overview.rst:114 +msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." +msgstr "" + +#: ../source/overview.rst:119 +msgid "Python binary distributions" +msgstr "" + +#: ../source/overview.rst:121 +msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." +msgstr "" + +#: ../source/overview.rst:125 +msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." +msgstr "" + +#: ../source/overview.rst:132 +msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." +msgstr "" + +#: ../source/overview.rst:140 +msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." +msgstr "" + +#: ../source/overview.rst:148 +msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." +msgstr "" + +#: ../source/overview.rst:155 +msgid "Packaging Python applications" +msgstr "" + +#: ../source/overview.rst:157 +msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." +msgstr "" + +#: ../source/overview.rst:162 +msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." +msgstr "" + +#: ../source/overview.rst:166 +msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." +msgstr "" + +#: ../source/overview.rst:172 +msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." +msgstr "" + +#: ../source/overview.rst:176 +msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." +msgstr "" + +#: ../source/overview.rst:181 +msgid "Depending on a framework" +msgstr "" + +#: ../source/overview.rst:183 +msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." +msgstr "" + +#: ../source/overview.rst:189 +msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." +msgstr "" + +#: ../source/overview.rst:195 +msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." +msgstr "" + +#: ../source/overview.rst:199 +msgid "Service platforms" +msgstr "" + +#: ../source/overview.rst:201 +msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." +msgstr "" + +#: ../source/overview.rst:205 +msgid "`Heroku `_" +msgstr "" + +#: ../source/overview.rst:206 +msgid "`Google App Engine `_" +msgstr "" + +#: ../source/overview.rst:207 +msgid "`PythonAnywhere `_" +msgstr "" + +#: ../source/overview.rst:208 +msgid "`OpenShift `_" +msgstr "" + +#: ../source/overview.rst:209 +msgid "\"Serverless\" frameworks like `Zappa `_" +msgstr "" + +#: ../source/overview.rst:211 +msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." +msgstr "" + +#: ../source/overview.rst:216 +msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." +msgstr "" + +#: ../source/overview.rst:220 +msgid "Web browsers and mobile applications" +msgstr "" + +#: ../source/overview.rst:222 +msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." +msgstr "" + +#: ../source/overview.rst:227 +msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" +msgstr "" + +#: ../source/overview.rst:231 +msgid "`Kivy `_" +msgstr "" + +#: ../source/overview.rst:232 +msgid "`Beeware `_" +msgstr "" + +#: ../source/overview.rst:233 +msgid "`Brython `_" +msgstr "" + +#: ../source/overview.rst:234 +msgid "`Flexx `_" +msgstr "" + +#: ../source/overview.rst:236 +msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." +msgstr "" + +#: ../source/overview.rst:241 +msgid "Depending on a pre-installed Python" +msgstr "" + +#: ../source/overview.rst:243 +msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." +msgstr "" + +#: ../source/overview.rst:249 +msgid "Technologies which support this model:" +msgstr "" + +#: ../source/overview.rst:251 +msgid "`PEX `_ (Python EXecutable)" +msgstr "" + +#: ../source/overview.rst:252 +msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" +msgstr "" + +#: ../source/overview.rst:253 +msgid "`shiv `_ (requires Python 3)" +msgstr "" + +#: ../source/overview.rst:255 +msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." +msgstr "" + +#: ../source/overview.rst:260 +msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." +msgstr "" + +#: ../source/overview.rst:267 +msgid "Depending on a separate software distribution ecosystem" +msgstr "" + +#: ../source/overview.rst:269 +msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." +msgstr "" + +#: ../source/overview.rst:274 +msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." +msgstr "" + +#: ../source/overview.rst:284 +msgid "Instructions on building and publishing for the Anaconda ecosystem:" +msgstr "" + +#: ../source/overview.rst:286 +msgid "`Building libraries and applications with conda `_" +msgstr "" + +#: ../source/overview.rst:287 +msgid "`Transitioning a native Python package to Anaconda `_" +msgstr "" + +#: ../source/overview.rst:289 +msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" +msgstr "" + +#: ../source/overview.rst:293 +msgid "`Enthought Canopy `_" +msgstr "" + +#: ../source/overview.rst:294 +msgid "`ActiveState ActivePython `_" +msgstr "" + +#: ../source/overview.rst:295 +msgid "`WinPython `_" +msgstr "" + +#: ../source/overview.rst:300 +msgid "Bringing your own Python executable" +msgstr "" + +#: ../source/overview.rst:302 +msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." +msgstr "" + +#: ../source/overview.rst:306 +msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." +msgstr "" + +#: ../source/overview.rst:311 +msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." +msgstr "" + +#: ../source/overview.rst:315 +msgid "A selection of Python freezers:" +msgstr "" + +#: ../source/overview.rst:317 +msgid "`pyInstaller `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:318 +msgid "`cx_Freeze `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:319 +msgid "`constructor `_ - For command-line installers" +msgstr "" + +#: ../source/overview.rst:320 +msgid "`py2exe `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:321 +msgid "`py2app `_ - Mac only" +msgstr "" + +#: ../source/overview.rst:322 +msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" +msgstr "" + +#: ../source/overview.rst:323 +msgid "`osnap `_ - Windows and Mac" +msgstr "" + +#: ../source/overview.rst:324 +msgid "`pynsist `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:326 +msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." +msgstr "" + +#: ../source/overview.rst:332 +msgid "Bringing your own userspace" +msgstr "" + +#: ../source/overview.rst:334 +msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." +msgstr "" + +#: ../source/overview.rst:341 +msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." +msgstr "" + +#: ../source/overview.rst:344 +msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" +msgstr "" + +#: ../source/overview.rst:347 +msgid "`AppImage `_" +msgstr "" + +#: ../source/overview.rst:348 +msgid "`Docker `_" +msgstr "" + +#: ../source/overview.rst:349 +msgid "`Flatpak `_" +msgstr "" + +#: ../source/overview.rst:350 +msgid "`Snapcraft `_" +msgstr "" + +#: ../source/overview.rst:353 +msgid "Bringing your own kernel" +msgstr "" + +#: ../source/overview.rst:355 +msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." +msgstr "" + +#: ../source/overview.rst:360 +msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" +msgstr "" + +#: ../source/overview.rst:364 +msgid "`Vagrant `_" +msgstr "" + +#: ../source/overview.rst:365 +msgid "`VHD `_, `AMI `_, and `other formats `_" +msgstr "" + +#: ../source/overview.rst:366 +msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" +msgstr "" + +#: ../source/overview.rst:369 +msgid "Bringing your own hardware" +msgstr "" + +#: ../source/overview.rst:371 +msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." +msgstr "" + +#: ../source/overview.rst:375 +msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." +msgstr "" + +#: ../source/overview.rst:379 +msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." +msgstr "" + +#: ../source/overview.rst:389 +msgid "The simplified gamut of technologies used to package Python applications." +msgstr "" + +#: ../source/overview.rst:392 +msgid "What about..." +msgstr "" + +#: ../source/overview.rst:394 +msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." +msgstr "" + +#: ../source/overview.rst:398 +msgid "Operating system packages" +msgstr "" + +#: ../source/overview.rst:400 +msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." +msgstr "" + +#: ../source/overview.rst:411 +msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." +msgstr "" + +#: ../source/overview.rst:417 +msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." +msgstr "" + +#: ../source/overview.rst:427 +msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." +msgstr "" + +#: ../source/overview.rst:432 +msgid "Security" +msgstr "" + +#: ../source/overview.rst:434 +msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." +msgstr "" + +#: ../source/overview.rst:437 +msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." +msgstr "" + +#: ../source/overview.rst:446 +msgid "Wrap up" +msgstr "" + +#: ../source/overview.rst:448 +msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:6 +msgid "Binary distribution format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:8 +msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:13 +msgid "Abstract" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:15 +msgid "This PEP describes a built-package format for Python called \"wheel\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:17 +msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:27 +msgid "PEP Acceptance" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:29 +msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:34 +msgid "Rationale" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:36 +msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:43 +msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:52 +msgid "Details" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:55 +msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:57 +msgid "Wheel installation notionally consists of two phases:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:59 +msgid "Unpack." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:61 +msgid "Parse ``distribution-1.0.dist-info/WHEEL``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:62 +msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:64 +msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:66 +msgid "Else unpack archive into platlib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:68 +msgid "Spread." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:70 +msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:72 +msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:78 +msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:80 +msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:82 +msgid "Remove empty ``distribution-1.0.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:83 +msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:87 +msgid "Recommended installer features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:97 +msgid "Rewrite ``#!python``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:90 +msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:96 +msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:102 +msgid "Generate script wrappers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:100 +msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:105 +msgid "Recommended archiver features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:112 +msgid "Place ``.dist-info`` at the end of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:108 +msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:115 +msgid "File Format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:118 +msgid "File name convention" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:120 +msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "distribution" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "Distribution name, e.g. 'django', 'pyramid'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "Distribution version, e.g. 1.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:135 +msgid "build tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:130 +msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "language implementation and version tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "E.g. 'py27', 'py2', 'py3'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "abi tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "E.g. 'cp33m', 'abi3', 'none'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "platform tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "E.g. 'linux_x86_64', 'any'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:146 +msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:151 +msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:156 +msgid "Escaping and Unicode" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:158 +msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:161 +msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:164 +msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:166 +msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:169 +msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:172 +msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:176 +msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:182 +msgid "File contents" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:184 +msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:188 +msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:191 +msgid "``{distribution}-{version}.dist-info/`` contains metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:192 +msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:196 +msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:200 +msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:202 +msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:212 +msgid "``Wheel-Version`` is the version number of the Wheel specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:213 +msgid "``Generator`` is the name and optionally the version of the software that produced the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:215 +msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:218 +msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:220 +msgid "``Build`` is the build number and is omitted if there is no build number." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:221 +msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:224 +msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:226 +msgid "Wheel does not contain setup.py or setup.cfg." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:228 +msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:235 +#: ../source/specifications/recording-installed-packages.rst:35 +msgid "The .dist-info directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:237 +msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:239 +msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:241 +msgid "WHEEL is the wheel metadata specific to a build of the package." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:242 +msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:248 +msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:249 +msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:251 +msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:254 +msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:261 +msgid "The .data directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:263 +msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:271 +msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:277 +msgid "Signed wheel files" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:279 +msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:290 +msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:295 +msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:302 +msgid "(The hash value is the same format used in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:304 +msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:307 +msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:312 +msgid "See" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:314 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:315 +msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:316 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:317 +msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:321 +msgid "Comparison to .egg" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:323 +msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:328 +msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:331 +msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:337 +msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:341 +msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:344 +msgid "Wheel is a reference to the other Python." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:348 +msgid "FAQ" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:352 +msgid "Wheel defines a .data directory. Should I put all my data there?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:354 +msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:363 +msgid "Why does wheel include attached signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:365 +msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:373 +msgid "Why does wheel allow JWS signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:375 +msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:381 +msgid "Why does wheel also allow S/MIME signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:383 +msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:386 +msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:391 +msgid "What's the deal with \"purelib\" vs. \"platlib\"?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:393 +msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:398 +msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:403 +msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:409 +msgid "Is it possible to import Python code directly from a wheel file?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:411 +msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:417 +msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:426 +msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:443 +msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:450 +msgid "Changes" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:452 +msgid "Since :pep:`427`, this specification has changed as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:454 +msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:461 +msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:466 +msgid "Appendix" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:468 +msgid "Example urlsafe-base64-nopad implementation::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:482 +msgid "Copyright" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:484 +msgid "This document has been placed into the public domain." +msgstr "" + +#: ../source/specifications/core-metadata.rst:5 +msgid "Core metadata specifications" +msgstr "" + +#: ../source/specifications/core-metadata.rst:7 +msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:10 +msgid "``Metadata-Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:11 +msgid "``Name``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:12 +msgid "``Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:14 +msgid "All the other fields are optional." +msgstr "" + +#: ../source/specifications/core-metadata.rst:16 +msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." +msgstr "" + +#: ../source/specifications/core-metadata.rst:25 +msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:30 +msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." +msgstr "" + +#: ../source/specifications/core-metadata.rst:41 +msgid "Metadata-Version" +msgstr "" + +#: ../source/specifications/core-metadata.rst:45 +msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." +msgstr "" + +#: ../source/specifications/core-metadata.rst:48 +msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:54 +msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." +msgstr "" + +#: ../source/specifications/core-metadata.rst:58 +#: ../source/specifications/core-metadata.rst:80 +#: ../source/specifications/core-metadata.rst:95 +#: ../source/specifications/core-metadata.rst:155 +#: ../source/specifications/core-metadata.rst:170 +#: ../source/specifications/core-metadata.rst:208 +#: ../source/specifications/core-metadata.rst:283 +#: ../source/specifications/core-metadata.rst:287 +#: ../source/specifications/core-metadata.rst:291 +#: ../source/specifications/core-metadata.rst:295 +#: ../source/specifications/core-metadata.rst:327 +#: ../source/specifications/core-metadata.rst:347 +#: ../source/specifications/core-metadata.rst:373 +#: ../source/specifications/core-metadata.rst:391 +#: ../source/specifications/core-metadata.rst:416 +#: ../source/specifications/core-metadata.rst:438 +#: ../source/specifications/core-metadata.rst:600 +#: ../source/specifications/core-metadata.rst:620 +#: ../source/specifications/core-metadata.rst:630 +msgid "Example::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:66 +msgid "Name" +msgstr "" + +#: ../source/specifications/core-metadata.rst:69 +msgid "Added additional restrictions on format from :pep:`508`" +msgstr "" + +#: ../source/specifications/core-metadata.rst:72 +msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:88 +msgid "Version" +msgstr "" + +#: ../source/specifications/core-metadata.rst:92 +msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:101 +msgid "Dynamic (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:105 +msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." +msgstr "" + +#: ../source/specifications/core-metadata.rst:108 +msgid "When found in the metadata of a source distribution, the following rules apply:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:111 +msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." +msgstr "" + +#: ../source/specifications/core-metadata.rst:115 +msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:118 +msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:122 +msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." +msgstr "" + +#: ../source/specifications/core-metadata.rst:127 +msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:131 +msgid "Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:135 +msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." +msgstr "" + +#: ../source/specifications/core-metadata.rst:146 +msgid "Supported-Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:150 +msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." +msgstr "" + +#: ../source/specifications/core-metadata.rst:164 +msgid "Summary" +msgstr "" + +#: ../source/specifications/core-metadata.rst:168 +msgid "A one-line summary of what the distribution does." +msgstr "" + +#: ../source/specifications/core-metadata.rst:188 +msgid "This field may be specified in the message body instead." +msgstr "" + +#: ../source/specifications/core-metadata.rst:191 +msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:196 +msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." +msgstr "" + +#: ../source/specifications/core-metadata.rst:202 +msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:219 +msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." +msgstr "" + +#: ../source/specifications/core-metadata.rst:223 +msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:232 +msgid "Description-Content-Type" +msgstr "" + +#: ../source/specifications/core-metadata.rst:236 +msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:239 +msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." +msgstr "" + +#: ../source/specifications/core-metadata.rst:253 +msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:259 +msgid "Format::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:263 +msgid "The ``type/subtype`` part has only a few legal values:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:265 +msgid "``text/plain``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:266 +msgid "``text/x-rst``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:267 +msgid "``text/markdown``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:269 +msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:273 +msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:278 +msgid "``GFM`` for `Github-flavored Markdown `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:280 +msgid "``CommonMark`` for `CommonMark `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:299 +msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." +msgstr "" + +#: ../source/specifications/core-metadata.rst:303 +msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:307 +msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:311 +msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." +msgstr "" + +#: ../source/specifications/core-metadata.rst:320 +msgid "Keywords" +msgstr "" + +#: ../source/specifications/core-metadata.rst:324 +msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." +msgstr "" + +#: ../source/specifications/core-metadata.rst:333 +msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." +msgstr "" + +#: ../source/specifications/core-metadata.rst:341 +msgid "Home-page" +msgstr "" + +#: ../source/specifications/core-metadata.rst:345 +msgid "A string containing the URL for the distribution's home page." +msgstr "" + +#: ../source/specifications/core-metadata.rst:353 +msgid "Download-URL" +msgstr "" + +#: ../source/specifications/core-metadata.rst:357 +msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:366 +msgid "Author" +msgstr "" + +#: ../source/specifications/core-metadata.rst:370 +msgid "A string containing the author's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:383 +msgid "Author-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:387 +msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:395 +#: ../source/specifications/core-metadata.rst:442 +msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:405 +msgid "Maintainer" +msgstr "" + +#: ../source/specifications/core-metadata.rst:409 +msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:412 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:426 +msgid "Maintainer-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:430 +msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:434 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:452 +msgid "License" +msgstr "" + +#: ../source/specifications/core-metadata.rst:456 +msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." +msgstr "" + +#: ../source/specifications/core-metadata.rst:476 +msgid "Classifier (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:480 +msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:485 +#: ../source/specifications/core-metadata.rst:574 +#: ../source/specifications/core-metadata.rst:691 +#: ../source/specifications/core-metadata.rst:715 +msgid "This field may be followed by an environment marker after a semicolon." +msgstr "" + +#: ../source/specifications/core-metadata.rst:496 +msgid "Requires-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:499 +#: ../source/specifications/core-metadata.rst:561 +#: ../source/specifications/core-metadata.rst:663 +#: ../source/specifications/core-metadata.rst:704 +msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." +msgstr "" + +#: ../source/specifications/core-metadata.rst:503 +msgid "Each entry contains a string naming some other distutils project required by this distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:506 +msgid "The format of a requirement string contains from one to four parts:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:508 +msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." +msgstr "" + +#: ../source/specifications/core-metadata.rst:510 +msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." +msgstr "" + +#: ../source/specifications/core-metadata.rst:513 +msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:516 +msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." +msgstr "" + +#: ../source/specifications/core-metadata.rst:519 +msgid "See :pep:`508` for full details of the allowed format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:521 +msgid "The project names should correspond to names as found on the `Python Package Index`_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:524 +msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:538 +msgid "Requires-Python" +msgstr "" + +#: ../source/specifications/core-metadata.rst:542 +msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." +msgstr "" + +#: ../source/specifications/core-metadata.rst:546 +msgid "The value must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:548 +msgid "This field cannot be followed by an environment marker." +msgstr "" + +#: ../source/specifications/core-metadata.rst:558 +msgid "Requires-External (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:565 +msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:570 +msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:576 +msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." +msgstr "" + +#: ../source/specifications/core-metadata.rst:581 +msgid "Notice that there is no particular rule on the strings to be used." +msgstr "" + +#: ../source/specifications/core-metadata.rst:593 +msgid "Project-URL (multiple-use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:597 +msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." +msgstr "" + +#: ../source/specifications/core-metadata.rst:604 +msgid "The label is free text limited to 32 characters." +msgstr "" + +#: ../source/specifications/core-metadata.rst:612 +msgid "Provides-Extra (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:616 +msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." +msgstr "" + +#: ../source/specifications/core-metadata.rst:625 +msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:635 +msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." +msgstr "" + +#: ../source/specifications/core-metadata.rst:639 +msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:644 +msgid "Rarely Used Fields" +msgstr "" + +#: ../source/specifications/core-metadata.rst:646 +msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:651 +msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." +msgstr "" + +#: ../source/specifications/core-metadata.rst:660 +msgid "Provides-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:667 +msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:672 +msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:679 +msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:687 +msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." +msgstr "" + +#: ../source/specifications/core-metadata.rst:701 +msgid "Obsoletes-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:708 +msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." +msgstr "" + +#: ../source/specifications/core-metadata.rst:712 +msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:717 +msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:730 +msgid "reStructuredText markup: http://docutils.sourceforge.net/" +msgstr "" + +#: ../source/specifications/core-metadata.rst:735 +msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:6 +msgid "Declaring build system dependencies" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:8 +msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:5 +msgid "Declaring project metadata" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:7 +msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:12 +msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:18 +msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:27 +msgid "The only fields required to be statically defined are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:29 +#: ../source/specifications/declaring-project-metadata.rst:41 +msgid "``name``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:31 +msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:34 +#: ../source/specifications/declaring-project-metadata.rst:54 +msgid "``version``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:36 +msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:43 +#: ../source/specifications/declaring-project-metadata.rst:56 +#: ../source/specifications/declaring-project-metadata.rst:68 +#: ../source/specifications/declaring-project-metadata.rst:117 +msgid "TOML_ type: string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:44 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:47 +msgid "The name of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:49 +msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:57 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:60 +msgid "The version of the project as supported by :pep:`440`." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:62 +msgid "Users SHOULD prefer to specify already-normalized versions." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:66 +msgid "``description``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:69 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:72 +msgid "The summary description of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:76 +msgid "``readme``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:78 +msgid "TOML_ type: string or table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:79 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:83 +msgid "The full description of the project (i.e. the README)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:85 +msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:96 +msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:103 +msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:115 +msgid "``requires-python``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:118 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:121 +msgid "The Python version requirements of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:125 +msgid "``license``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:127 +msgid "TOML_ type: table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:128 +msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:131 +msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:140 +msgid "``authors``/``maintainers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:142 +msgid "TOML_ type: Array of inline tables with string keys and values" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:143 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:149 +msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:154 +msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:157 +msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:163 +msgid "Using the data to fill in :ref:`core metadata ` is as follows:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:166 +msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:169 +msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:173 +msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:177 +msgid "Multiple values should be separated by commas." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:181 +msgid "``keywords``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:183 +#: ../source/specifications/declaring-project-metadata.rst:193 +msgid "TOML_ type: array of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:184 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:187 +msgid "The keywords for the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:191 +msgid "``classifiers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:194 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:197 +msgid "Trove classifiers which apply to the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:201 +msgid "``urls``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:203 +msgid "TOML_ type: table with keys and values of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:204 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:207 +msgid "A table of URLs where the key is the URL label and the value is the URL itself." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:212 +msgid "Entry points" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:214 +msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:216 +msgid ":ref:`Entry points specification `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:218 +msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:224 +msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:228 +msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:234 +msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:242 +msgid "``dependencies``/``optional-dependencies``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:244 +msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:247 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:251 +msgid "The (optional) dependencies of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:253 +msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:258 +msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:269 +msgid "``dynamic``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:271 +msgid "TOML_ type: array of string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:272 +msgid "A corresponding :ref:`core metadata ` field does not exist" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:275 +msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:281 +msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:283 +msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:285 +msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:290 +msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:294 +msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:296 +msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:300 +msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:6 +msgid "Dependency specifiers" +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:8 +msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:11 +msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." +msgstr "" + +#: ../source/specifications/direct-url.rst:6 +msgid "Recording the Direct URL Origin of installed distributions" +msgstr "" + +#: ../source/specifications/direct-url.rst:8 +msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." +msgstr "" + +#: ../source/specifications/direct-url.rst:17 +msgid "Specification" +msgstr "" + +#: ../source/specifications/direct-url.rst:19 +msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/direct-url.rst:23 +#: ../source/specifications/recording-installed-packages.rst:206 +msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." +msgstr "" + +#: ../source/specifications/direct-url.rst:26 +msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." +msgstr "" + +#: ../source/specifications/direct-url.rst:29 +msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." +msgstr "" + +#: ../source/specifications/direct-url.rst:36 +msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." +msgstr "" + +#: ../source/specifications/direct-url.rst:39 +msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" +msgstr "" + +#: ../source/specifications/direct-url.rst:45 +msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." +msgstr "" + +#: ../source/specifications/direct-url.rst:49 +msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" +msgstr "" + +#: ../source/specifications/direct-url.rst:52 +msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." +msgstr "" + +#: ../source/specifications/direct-url.rst:58 +msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." +msgstr "" + +#: ../source/specifications/direct-url.rst:61 +msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." +msgstr "" + +#: ../source/specifications/direct-url.rst:68 +msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:71 +msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." +msgstr "" + +#: ../source/specifications/direct-url.rst:78 +msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:81 +msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." +msgstr "" + +#: ../source/specifications/direct-url.rst:84 +msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." +msgstr "" + +#: ../source/specifications/direct-url.rst:91 +msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." +msgstr "" + +#: ../source/specifications/direct-url.rst:96 +msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." +msgstr "" + +#: ../source/specifications/direct-url.rst:102 +msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." +msgstr "" + +#: ../source/specifications/direct-url.rst:110 +msgid "Registered VCS" +msgstr "" + +#: ../source/specifications/direct-url.rst:112 +msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." +msgstr "" + +#: ../source/specifications/direct-url.rst:122 +msgid "Git" +msgstr "" + +#: ../source/specifications/direct-url.rst:124 +#: ../source/specifications/direct-url.rst:156 +#: ../source/specifications/direct-url.rst:179 +#: ../source/specifications/direct-url.rst:202 +msgid "Home page" +msgstr "" + +#: ../source/specifications/direct-url.rst:126 +msgid "https://git-scm.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:128 +#: ../source/specifications/direct-url.rst:160 +#: ../source/specifications/direct-url.rst:183 +#: ../source/specifications/direct-url.rst:206 +msgid "vcs command" +msgstr "" + +#: ../source/specifications/direct-url.rst:130 +#: ../source/specifications/direct-url.rst:134 +msgid "git" +msgstr "" + +#: ../source/specifications/direct-url.rst:132 +#: ../source/specifications/direct-url.rst:164 +#: ../source/specifications/direct-url.rst:187 +#: ../source/specifications/direct-url.rst:210 +msgid "``vcs`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:136 +#: ../source/specifications/direct-url.rst:168 +#: ../source/specifications/direct-url.rst:191 +#: ../source/specifications/direct-url.rst:214 +msgid "``requested_revision`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:138 +msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." +msgstr "" + +#: ../source/specifications/direct-url.rst:141 +#: ../source/specifications/direct-url.rst:172 +#: ../source/specifications/direct-url.rst:195 +#: ../source/specifications/direct-url.rst:219 +msgid "``commit_id`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:143 +msgid "A commit hash (40 hexadecimal characters sha1)." +msgstr "" + +#: ../source/specifications/direct-url.rst:147 +msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." +msgstr "" + +#: ../source/specifications/direct-url.rst:154 +msgid "Mercurial" +msgstr "" + +#: ../source/specifications/direct-url.rst:158 +msgid "https://www.mercurial-scm.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:162 +#: ../source/specifications/direct-url.rst:166 +msgid "hg" +msgstr "" + +#: ../source/specifications/direct-url.rst:170 +msgid "A tag name, branch name, changeset ID, shortened changeset ID." +msgstr "" + +#: ../source/specifications/direct-url.rst:174 +msgid "A changeset ID (40 hexadecimal characters)." +msgstr "" + +#: ../source/specifications/direct-url.rst:177 +msgid "Bazaar" +msgstr "" + +#: ../source/specifications/direct-url.rst:181 +msgid "https://bazaar.canonical.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:185 +#: ../source/specifications/direct-url.rst:189 +msgid "bzr" +msgstr "" + +#: ../source/specifications/direct-url.rst:193 +msgid "A tag name, branch name, revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:197 +msgid "A revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:200 +msgid "Subversion" +msgstr "" + +#: ../source/specifications/direct-url.rst:204 +msgid "https://subversion.apache.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:208 +#: ../source/specifications/direct-url.rst:212 +msgid "svn" +msgstr "" + +#: ../source/specifications/direct-url.rst:216 +msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." +msgstr "" + +#: ../source/specifications/direct-url.rst:221 +msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." +msgstr "" + +#: ../source/specifications/direct-url.rst:229 +msgid "Example direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:231 +msgid "Source archive:" +msgstr "" + +#: ../source/specifications/direct-url.rst:242 +msgid "Git URL with tag and commit-hash:" +msgstr "" + +#: ../source/specifications/direct-url.rst:255 +msgid "Local directory:" +msgstr "" + +#: ../source/specifications/direct-url.rst:264 +msgid "Local directory installed in editable mode:" +msgstr "" + +#: ../source/specifications/direct-url.rst:277 +msgid "Example pip commands and their effect on direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:279 +msgid "Commands that generate a ``direct_url.json``:" +msgstr "" + +#: ../source/specifications/direct-url.rst:281 +msgid "pip install https://example.com/app-1.0.tgz" +msgstr "" + +#: ../source/specifications/direct-url.rst:282 +msgid "pip install https://example.com/app-1.0.whl" +msgstr "" + +#: ../source/specifications/direct-url.rst:283 +msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" +msgstr "" + +#: ../source/specifications/direct-url.rst:284 +msgid "pip install ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:285 +msgid "pip install file:///home/user/app" +msgstr "" + +#: ../source/specifications/direct-url.rst:286 +msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" +msgstr "" + +#: ../source/specifications/direct-url.rst:290 +msgid "pip install -e ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:292 +msgid "Commands that *do not* generate a ``direct_url.json``" +msgstr "" + +#: ../source/specifications/direct-url.rst:294 +msgid "pip install app" +msgstr "" + +#: ../source/specifications/direct-url.rst:295 +msgid "pip install app --no-index --find-links https://example.com/" +msgstr "" + +#: ../source/specifications/entry-points.rst:5 +msgid "Entry points specification" +msgstr "" + +#: ../source/specifications/entry-points.rst:7 +msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" +msgstr "" + +#: ../source/specifications/entry-points.rst:11 +msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." +msgstr "" + +#: ../source/specifications/entry-points.rst:14 +msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." +msgstr "" + +#: ../source/specifications/entry-points.rst:19 +msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." +msgstr "" + +#: ../source/specifications/entry-points.rst:28 +msgid "Data model" +msgstr "" + +#: ../source/specifications/entry-points.rst:30 +msgid "Conceptually, an entry point is defined by three required properties:" +msgstr "" + +#: ../source/specifications/entry-points.rst:32 +msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:42 +msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:51 +msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:64 +msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." +msgstr "" + +#: ../source/specifications/entry-points.rst:68 +msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." +msgstr "" + +#: ../source/specifications/entry-points.rst:73 +msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." +msgstr "" + +#: ../source/specifications/entry-points.rst:80 +msgid "File format" +msgstr "" + +#: ../source/specifications/entry-points.rst:82 +msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." +msgstr "" + +#: ../source/specifications/entry-points.rst:87 +msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:97 +msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:100 +msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." +msgstr "" + +#: ../source/specifications/entry-points.rst:104 +msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." +msgstr "" + +#: ../source/specifications/entry-points.rst:112 +msgid "For example::" +msgstr "" + +#: ../source/specifications/entry-points.rst:124 +msgid "Use for scripts" +msgstr "" + +#: ../source/specifications/entry-points.rst:126 +msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." +msgstr "" + +#: ../source/specifications/entry-points.rst:134 +msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:141 +msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." +msgstr "" + +#: ../source/specifications/entry-points.rst:149 +msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." +msgstr "" + +#: ../source/specifications/entry-points.rst:154 +msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." +msgstr "" + +#: ../source/specifications/index.rst:4 +msgid "PyPA specifications" +msgstr "" + +#: ../source/specifications/index.rst:6 +msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." +msgstr "" + +#: ../source/specifications/index.rst:13 +msgid "Package Distribution Metadata" +msgstr "" + +#: ../source/specifications/index.rst:30 +msgid "Package Distribution File Formats" +msgstr "" + +#: ../source/specifications/index.rst:40 +msgid "Package Index Interfaces" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:6 +msgid "Platform compatibility tags" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:8 +msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:12 +msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:16 +msgid "Platform tags for Windows" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:18 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:22 +msgid "Platform tags for macOS (Mac OS X)" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:24 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:28 +msgid "Platform tags for common Linux distributions" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:32 +msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:36 +msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:41 +msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:44 +msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:46 +msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:49 +msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:54 +msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:59 +msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:65 +msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:71 +msgid "Manylinux compatibility support" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:74 +msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:76 +msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:79 +msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "Tool" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux1``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2010``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2014``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux_x_y``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=8.1.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=20.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "auditwheel" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=1.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=2.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.3.0`` [#]_" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:90 +msgid "Platform tags for other \\*nix platforms" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:92 +msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:98 +msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" +msgstr "" + +#: ../source/specifications/pypirc.rst:6 +msgid "The :file:`.pypirc` file" +msgstr "" + +#: ../source/specifications/pypirc.rst:8 +msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." +msgstr "" + +#: ../source/specifications/pypirc.rst:13 +msgid "The format (originally defined by the :ref:`distutils` package) is:" +msgstr "" + +#: ../source/specifications/pypirc.rst:32 +msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:35 +msgid "Each section describing a repository defines three fields:" +msgstr "" + +#: ../source/specifications/pypirc.rst:37 +msgid "``repository``: The URL of the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:38 +msgid "``username``: The registered username on the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:39 +msgid "``password``: The password that will used to authenticate the username." +msgstr "" + +#: ../source/specifications/pypirc.rst:43 +msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." +msgstr "" + +#: ../source/specifications/pypirc.rst:47 +msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" +msgstr "" + +#: ../source/specifications/pypirc.rst:57 +msgid "Common configurations" +msgstr "" + +#: ../source/specifications/pypirc.rst:61 +msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." +msgstr "" + +#: ../source/specifications/pypirc.rst:66 +msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" +msgstr "" + +#: ../source/specifications/pypirc.rst:82 +msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." +msgstr "" + +#: ../source/specifications/pypirc.rst:86 +msgid "Using a PyPI token" +msgstr "" + +#: ../source/specifications/pypirc.rst:88 +msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" +msgstr "" + +#: ../source/specifications/pypirc.rst:97 +msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." +msgstr "" + +#: ../source/specifications/pypirc.rst:103 +msgid "Using another package index" +msgstr "" + +#: ../source/specifications/pypirc.rst:105 +msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" +msgstr "" + +#: ../source/specifications/pypirc.rst:132 +msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:5 +msgid "Recording installed projects" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:7 +msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:12 +msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:21 +msgid "History and change workflow" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:23 +msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:29 +msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:37 +msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:41 +msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:50 +msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:60 +msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:69 +msgid "This ``.dist-info`` directory can contain these files, described in detail below:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:72 +msgid "``METADATA``: contains project metadata" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:73 +msgid "``RECORD``: records the list of installed files." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:74 +msgid "``INSTALLER``: records the name of the tool used to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:76 +msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:82 +msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:87 +msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:94 +msgid "The METADATA file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:96 +msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:99 +msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:105 +msgid "The RECORD file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:107 +msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:110 +msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:113 +msgid "field delimiter: ``,`` (comma)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:114 +msgid "quoting char: ``\"`` (straight double quote)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:115 +msgid "line terminator: either ``\\r\\n`` or ``\\n``." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:117 +msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:120 +msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:125 +msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:130 +msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:133 +msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:139 +msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:146 +msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:151 +msgid "Here is an example snippet of a possible ``RECORD`` file::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:170 +msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:177 +msgid "The INSTALLER file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:179 +msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:185 +msgid "The file can be terminated by zero or more ASCII whitespace characters." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:187 +msgid "Here are examples of two possible ``INSTALLER`` files::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:195 +msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:201 +msgid "The direct_url.json file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:203 +msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:209 +msgid "Its detailed specification is at :ref:`direct-url`." +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:6 +msgid "Simple repository API" +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:8 +msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:6 +msgid "Source distribution format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:8 +msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:13 +msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:21 +msgid "Source distributions are also known as *sdists* for short." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:24 +msgid "Source distribution file name" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:26 +msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:31 +msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:35 +msgid "Source distribution file format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:37 +msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:45 +msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:48 +msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:6 +msgid "Version specifiers" +msgstr "" + +#: ../source/specifications/version-specifiers.rst:8 +msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:11 +msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." +msgstr "" + +#: ../source/support.rst:3 +msgid "How to Get Support" +msgstr "" + +#: ../source/support.rst:5 +msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." +msgstr "" + +#: ../source/support.rst:8 +msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:5 +msgid "Creating Documentation" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:7 +msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:13 +msgid "Installing Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:14 +msgid "Use ``pip`` to install Sphinx:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:28 +msgid "For other installation methods, see this `installation guide`_ by Sphinx." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:33 +msgid "Getting Started With Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:35 +msgid "Create a ``docs`` directory inside your project to hold your documentation:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:42 +msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:49 +msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:51 +msgid "You can add some information about your project in ``index.rst``, then build them:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:57 +msgid "For more details on the build process, see this `guide`_ by Read The Docs." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:62 +msgid "Other Sources" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:64 +msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/index.rst:4 +msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:5 +msgid "Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:7 +msgid "This section covers the basics of how to install Python :term:`packages `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:10 +msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:28 +msgid "Requirements for Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:30 +msgid "This section describes the steps to follow before installing other Python packages." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:35 +msgid "Ensure you can run Python from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:37 +msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:53 +msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:57 +msgid "If you're a newcomer and you get an error like this:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:66 +msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:72 +msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:82 +msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:87 +msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:99 +msgid "Ensure you can run pip from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:101 +msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:116 +msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:124 +msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:139 +msgid "If that still doesn't allow you to run ``python -m pip``:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:141 +msgid "Securely Download `get-pip.py `_ [1]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:144 +msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:150 +msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:159 +msgid "Ensure pip, setuptools, and wheel are up to date" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:161 +msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:169 +msgid "Optionally, create a virtual environment" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:171 +msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:188 +msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:195 +msgid "Creating Virtual Environments" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:197 +msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:203 +msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:209 +msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:213 +msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:216 +msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:220 +msgid "Currently, there are two common tools for creating Python virtual environments:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:222 +msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:225 +msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:230 +msgid "The basic usage is like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:232 +msgid "Using `venv`_:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:248 +msgid "Using :ref:`virtualenv`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:264 +msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:266 +msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:271 +msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:281 +msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:288 +msgid "Use pip for Installing" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:290 +msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:297 +msgid "Installing from PyPI" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:299 +msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:307 +msgid "To install the latest version of \"SomeProject\":" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:321 +msgid "To install a specific version:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:335 +msgid "To install greater than or equal to one version and less than another:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:350 +msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:365 +msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:370 +msgid "Source Distributions vs Wheels" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:372 +msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:378 +msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:383 +msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:391 +msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:408 +msgid "Installing to the User Site" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:410 +msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:425 +msgid "For more information see the `User Installs `_ section from the pip docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:429 +msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:432 +msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:440 +msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:446 +msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:462 +msgid "Install a list of requirements specified in a :ref:`Requirements File `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:478 +msgid "Installing from VCS" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:480 +msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:502 +msgid "Installing from other Indexes" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:504 +msgid "Install from an alternate index" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:518 +msgid "Search an additional index during install, in addition to :term:`PyPI `" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:534 +msgid "Installing from a local src tree" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:537 +msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:554 +msgid "You can also install normally from src" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:571 +msgid "Install a particular source archive file." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:585 +msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:605 +msgid "Installing from other sources" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:607 +msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:619 +msgid "Installing Prereleases" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:621 +msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:637 +msgid "Installing Setuptools \"Extras\"" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:639 +msgid "Install `setuptools extras`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:659 +msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:668 +msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:673 +msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:4 +msgid "Managing Application Dependencies" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:6 +msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:9 +msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:13 +msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:17 +msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:24 +msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:30 +msgid "Installing Pipenv" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:32 +msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:38 +msgid "Use ``pip`` to install Pipenv:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:54 +msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:65 +msgid "Installing packages for your project" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:67 +msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:76 +msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:112 +msgid "Using installed packages" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:114 +msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:125 +msgid "Then you can run this script using ``pipenv run``:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:131 +msgid "You should get output similar to this:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:137 +msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:143 +#: ../source/tutorials/packaging-projects.rst:594 +msgid "Next steps" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:145 +msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:148 +msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:151 +msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:160 +msgid "Other Tools for Application Dependency Management" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:162 +msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:166 +msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:172 +msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:175 +msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:177 +msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:2 +msgid "Packaging Python Projects" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:4 +msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:10 +msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:18 +msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:35 +msgid "A simple project" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:37 +msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:41 +msgid "Create the following file structure locally:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:51 +msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:54 +msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:63 +msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:67 +msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:75 +msgid "Creating the package files" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:77 +msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:95 +msgid "Creating a test directory" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:97 +msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:101 +msgid "Creating pyproject.toml" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:103 +msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:117 +msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:121 +msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:127 +msgid "See :pep:`517` and :pep:`518` for background and details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:131 +msgid "Configuring metadata" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:133 +msgid "There are two types of metadata: static and dynamic." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:135 +msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:137 +msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:141 +msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:148 +msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:153 +msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:185 +msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:191 +#: ../source/tutorials/packaging-projects.rst:286 +msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:196 +msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:199 +#: ../source/tutorials/packaging-projects.rst:293 +msgid "``author`` and ``author_email`` are used to identify the author of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:201 +#: ../source/tutorials/packaging-projects.rst:295 +msgid "``description`` is a short, one-sentence summary of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:202 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:206 +#: ../source/tutorials/packaging-projects.rst:300 +msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:208 +#: ../source/tutorials/packaging-projects.rst:302 +msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:211 +#: ../source/tutorials/packaging-projects.rst:305 +msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:213 +#: ../source/tutorials/packaging-projects.rst:307 +msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:221 +msgid "In the ``options`` category, we have controls for setuptools itself:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:223 +msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:227 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:234 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:238 +#: ../source/tutorials/packaging-projects.rst:329 +msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:244 +msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:248 +msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:283 +msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:291 +msgid "``version`` is the package version. See :pep:`440` for more details on versions." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:296 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:314 +msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:319 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:325 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:333 +msgid "Creating README.md" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:335 +msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:347 +msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:354 +msgid "Creating a LICENSE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:356 +msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:387 +msgid "Including other files" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:389 +msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:393 +msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:402 +msgid "Generating distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:404 +msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:408 +msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:422 +msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:425 +msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:439 +msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:449 +msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:458 +msgid "Uploading the distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:460 +msgid "Finally, it's time to upload your package to the Python Package Index!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:462 +msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:470 +msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:477 +msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:492 +msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:506 +msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:510 +msgid "After the command completes, you should see output similar to this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:523 +msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:528 +msgid "Installing your newly uploaded package" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:530 +msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:546 +msgid "Make sure to specify your username in the package name!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:548 +msgid "pip should install the package from TestPyPI and the output should look something like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:558 +msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:565 +msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:580 +msgid "and import the package:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:588 +msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:596 +msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:599 +msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:604 +msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:608 +msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:610 +msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:613 +msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:617 +msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:619 +msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:622 +msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:624 +msgid "Read about :doc:`/guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:625 +msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." +msgstr "" From 197204d0e545556ea2ef0ab6cb17593e503cff52 Mon Sep 17 00:00:00 2001 From: phlostically Date: Sun, 29 Aug 2021 18:15:31 +0200 Subject: [PATCH 0080/1072] Translated using Weblate (Esperanto) Currently translated at 6.6% (152 of 2271 strings) Added translation using Weblate (Esperanto) Co-authored-by: phlostically Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/eo/ Translation: pypa/packaging.python.org --- locales/eo/LC_MESSAGES/messages.po | 9287 ++++++++++++++++++++++++++++ 1 file changed, 9287 insertions(+) create mode 100644 locales/eo/LC_MESSAGES/messages.po diff --git a/locales/eo/LC_MESSAGES/messages.po b/locales/eo/LC_MESSAGES/messages.po new file mode 100644 index 000000000..d29a4a6b0 --- /dev/null +++ b/locales/eo/LC_MESSAGES/messages.po @@ -0,0 +1,9287 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2013–2020, PyPA +# This file is distributed under the same license as the Python Packaging User Guide package. +# phlostically , 2021. +msgid "" +msgstr "" +"Project-Id-Version: Python Packaging User Guide\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-07-06 19:32+0800\n" +"PO-Revision-Date: 2021-07-16 11:12+0000\n" +"Last-Translator: phlostically \n" +"Language-Team: Esperanto \n" +"Language: eo\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=2; plural=n != 1;\n" +"X-Generator: Weblate 4.7.2-dev\n" + +#: ../source/contribute.rst:5 +msgid "Contribute to this guide" +msgstr "Kontribui al ĉi tiu gvidilo" + +#: ../source/contribute.rst:7 +msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" +msgstr "" + +#: ../source/contribute.rst:10 +msgid "Reading the guide and giving feedback" +msgstr "" + +#: ../source/contribute.rst:11 +msgid "Reviewing new contributions" +msgstr "Revizii novajn kontribuojn" + +#: ../source/contribute.rst:12 +msgid "Revising existing content" +msgstr "Poluri ekzistantan enhavon" + +#: ../source/contribute.rst:13 +msgid "Writing new content" +msgstr "Verki novan enhavon" + +#: ../source/contribute.rst:15 +msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." +msgstr "" + +#: ../source/contribute.rst:24 +msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." +msgstr "" + +#: ../source/contribute.rst:31 +msgid "Documentation types" +msgstr "Tipoj de dokumentaro" + +#: ../source/contribute.rst:33 +msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." +msgstr "" + +#: ../source/contribute.rst:38 +#: ../source/tutorials/index.rst:2 +msgid "Tutorials" +msgstr "Lerniloj" + +#: ../source/contribute.rst:40 +msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." +msgstr "" + +#: ../source/contribute.rst:47 +#: ../source/guides/index.rst:2 +msgid "Guides" +msgstr "Gvidiloj" + +#: ../source/contribute.rst:49 +msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." +msgstr "" + +#: ../source/contribute.rst:56 +#: ../source/discussions/index.rst:2 +msgid "Discussions" +msgstr "Diskutoj" + +#: ../source/contribute.rst:58 +msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." +msgstr "" + +#: ../source/contribute.rst:63 +msgid "Specifications" +msgstr "Specifiloj" + +#: ../source/contribute.rst:65 +msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." +msgstr "" + +#: ../source/contribute.rst:73 +msgid "Building the guide locally" +msgstr "" + +#: ../source/contribute.rst:75 +msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" +msgstr "" + +#: ../source/contribute.rst:79 +msgid "`Nox `_. You can install or upgrade nox using ``pip``::" +msgstr "" +"`Nox `_. Vi povas instali aŭ " +"ĝisdatigi nox per ``pip``::" + +#: ../source/contribute.rst:84 +msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." +msgstr "" + +#: ../source/contribute.rst:91 +msgid "To build the guide, run the following bash command in the source folder::" +msgstr "" + +#: ../source/contribute.rst:95 +msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." +msgstr "" + +#: ../source/contribute.rst:100 +msgid "You can build the guide and serve it via an HTTP server using the following command::" +msgstr "" + +#: ../source/contribute.rst:105 +msgid "The guide will be browsable via http://localhost:8000." +msgstr "" + +#: ../source/contribute.rst:109 +msgid "Where the guide is deployed" +msgstr "" + +#: ../source/contribute.rst:111 +msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." +msgstr "" + +#: ../source/contribute.rst:117 +msgid "Style guide" +msgstr "Rekomendoj pri stilo" + +#: ../source/contribute.rst:119 +msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." +msgstr "" + +#: ../source/contribute.rst:126 +msgid "Purpose" +msgstr "Celo" + +#: ../source/contribute.rst:128 +msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." +msgstr "" + +#: ../source/contribute.rst:133 +msgid "Scope" +msgstr "Amplekso" + +#: ../source/contribute.rst:135 +msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." +msgstr "" + +#: ../source/contribute.rst:138 +msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." +msgstr "" + +#: ../source/contribute.rst:146 +msgid "Audience" +msgstr "" + +#: ../source/contribute.rst:148 +msgid "The audience of this guide is anyone who uses Python with packages." +msgstr "" + +#: ../source/contribute.rst:150 +msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." +msgstr "" + +#: ../source/contribute.rst:154 +msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." +msgstr "" + +#: ../source/contribute.rst:160 +msgid "Voice and tone" +msgstr "Voĉo kaj tono" + +#: ../source/contribute.rst:162 +msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." +msgstr "" + +#: ../source/contribute.rst:165 +msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." +msgstr "" + +#: ../source/contribute.rst:170 +msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." +msgstr "" + +#: ../source/contribute.rst:177 +msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." +msgstr "" + +#: ../source/contribute.rst:184 +msgid "Conventions and mechanics" +msgstr "" + +#: ../source/contribute.rst:192 +msgid "**Write to the reader**" +msgstr "" + +#: ../source/contribute.rst:187 +msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: To install it, the user runs…" +msgstr "Netaŭga: Por instali ĝin, la uzanto rulas…" + +#: ../source/contribute.rst:0 +msgid "Right: You can install it by running…" +msgstr "Taŭga: Vi povas instali ĝin per rulado de…" + +#: ../source/contribute.rst:0 +msgid "Right: To install it, run…" +msgstr "Taŭga: Por instali ĝin, rulu…" + +#: ../source/contribute.rst:198 +msgid "**State assumptions**" +msgstr "**Klarigu supozojn**" + +#: ../source/contribute.rst:195 +msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." +msgstr "" + +#: ../source/contribute.rst:203 +msgid "**Cross-reference generously**" +msgstr "**Interreferencu ofte**" + +#: ../source/contribute.rst:201 +msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." +msgstr "" + +#: ../source/contribute.rst:213 +msgid "**Respect naming practices**" +msgstr "**Respektu nomojn**" + +#: ../source/contribute.rst:206 +msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: Pip uses…" +msgstr "Netaŭga: Pip uzas…" + +#: ../source/contribute.rst:0 +msgid "Right: pip uses…" +msgstr "Taŭga: pip uzas…" + +#: ../source/contribute.rst:0 +msgid "Wrong: …hosted on github." +msgstr "Netaŭga: …gastigata ĉe github." + +#: ../source/contribute.rst:0 +msgid "Right: …hosted on GitHub." +msgstr "Taŭga: …gastigata ĉe GitHub." + +#: ../source/contribute.rst:222 +msgid "**Use a gender-neutral style**" +msgstr "**Uzu seksneŭtralan stilon**" + +#: ../source/contribute.rst:216 +msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." +msgstr "" +"Ofte vi rekte alparolu la leganton per *vi*, *vin* aŭ *via*. Alie, uzu " +"seksneŭtralajn pronomojn *ili*, *ŝ/li* aŭ entute evitu pronomojn." + +#: ../source/contribute.rst:0 +msgid "Wrong: A maintainer uploads the file. Then he…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then they…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then the maintainer…" +msgstr "" + +#: ../source/contribute.rst:234 +msgid "**Headings**" +msgstr "**Titoloj de paragrafoj**" + +#: ../source/contribute.rst:225 +msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." +msgstr "" + +#: ../source/contribute.rst:230 +msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: Things You Should Know About Python" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: Things you should know about Python" +msgstr "" + +#: ../source/contribute.rst:237 +msgid "**Numbers**" +msgstr "**Nombroj**" + +#: ../source/contribute.rst:237 +msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:4 +msgid "Deploying Python applications" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Page Status" +msgstr "Stato de la paĝo" + +#: ../source/discussions/deploying-python-applications.rst:6 +#: ../source/guides/index-mirrors-and-caches.rst:7 +#: ../source/guides/installing-using-linux-tools.rst:7 +#: ../source/guides/packaging-binary-extensions.rst:7 +#: ../source/guides/supporting-multiple-python-versions.rst:7 +#: ../source/guides/supporting-windows-using-appveyor.rst:5 +msgid "Incomplete" +msgstr "Nekompleta" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Last Reviewed" +msgstr "Laste reviziita" + +#: ../source/discussions/deploying-python-applications.rst:7 +msgid "2014-11-11" +msgstr "2014-11-11" + +#: ../source/discussions/deploying-python-applications.rst:11 +#: ../source/discussions/install-requires-vs-requirements.rst:9 +#: ../source/guides/analyzing-pypi-package-downloads.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:22 +#: ../source/guides/index-mirrors-and-caches.rst:12 +#: ../source/guides/installing-scientific-packages.rst:9 +#: ../source/guides/packaging-binary-extensions.rst:17 +#: ../source/guides/supporting-multiple-python-versions.rst:12 +#: ../source/guides/supporting-windows-using-appveyor.rst:15 +#: ../source/overview.rst:23 +#: ../source/specifications/core-metadata.rst:38 +#: ../source/specifications/direct-url.rst:14 +#: ../source/tutorials/installing-packages.rst:23 +msgid "Contents" +msgstr "Enhavoj" + +#: ../source/discussions/deploying-python-applications.rst:14 +msgid "Overview" +msgstr "Superrigardo" + +#: ../source/discussions/deploying-python-applications.rst:18 +msgid "Supporting multiple hardware platforms" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:40 +msgid "OS packaging & installers" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:52 +msgid "Windows" +msgstr "Windows" + +#: ../source/discussions/deploying-python-applications.rst:61 +msgid "Pynsist" +msgstr "Pynsist" + +#: ../source/discussions/deploying-python-applications.rst:63 +msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:70 +msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:74 +msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:80 +msgid "Application bundles" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:91 +msgid "Configuration management" +msgstr "" + +#: ../source/discussions/index.rst:4 +msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:5 +msgid "install_requires vs requirements files" +msgstr "install_requires kontraste kun requirements.txt" + +#: ../source/discussions/install-requires-vs-requirements.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:382 +msgid "install_requires" +msgstr "install_requires" + +#: ../source/discussions/install-requires-vs-requirements.rst:14 +msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:19 +msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:29 +msgid "Additionally, it's best practice to indicate any known lower or upper bounds." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:31 +msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:41 +msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:51 +msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:56 +msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:64 +#: ../source/tutorials/installing-packages.rst:460 +msgid "Requirements files" +msgstr "Dosiero requirements.txt" + +#: ../source/discussions/install-requires-vs-requirements.rst:66 +msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:69 +msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:73 +msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:78 +msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:84 +msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:90 +msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:6 +msgid "pip vs easy_install" +msgstr "pip kontraste kun easy_install" + +#: ../source/discussions/pip-vs-easy-install.rst:9 +msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:14 +msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:22 +msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**pip**" +msgstr "**pip**" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**easy_install**" +msgstr "**easy_install**" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +msgid "Installs from :term:`Wheels `" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Yes" +msgstr "Jes" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:30 +#: ../source/discussions/pip-vs-easy-install.rst:32 +#: ../source/discussions/pip-vs-easy-install.rst:35 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:51 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "No" +msgstr "Ne" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Uninstall Packages" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Yes (``python -m pip uninstall``)" +msgstr "Jes (``python -m pip uninstall``)" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Dependency Overrides" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Yes (:ref:`Requirements Files `)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "List Installed Packages" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" +msgstr "Jes (``python -m pip list`` kaj ``python -m pip freeze``)" + +#: ../source/discussions/pip-vs-easy-install.rst:38 +msgid ":pep:`438` Support" +msgstr "Subteno de :pep:`438`" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Installation format" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "'Flat' packages with :file:`egg-info` metadata." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Encapsulated Egg format" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:44 +msgid "sys.path modification" +msgstr "modifado de sys.path" + +#: ../source/discussions/pip-vs-easy-install.rst:48 +msgid "Installs from :term:`Eggs `" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "`pylauncher support`_" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "Yes [1]_" +msgstr "Jes [1]_" + +#: ../source/discussions/pip-vs-easy-install.rst:54 +msgid ":ref:`Multi-version Installs`" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Exclude scripts during install" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "per project index" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Only in virtualenv" +msgstr "Nur en virtualenv" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Yes, via setup.cfg" +msgstr "Jes, per setup.cfg" + +#: ../source/discussions/pip-vs-easy-install.rst:68 +msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" +msgstr "" +"https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" +"launcher" + +#: ../source/discussions/wheel-vs-egg.rst:5 +msgid "Wheel vs Egg" +msgstr "Wheel kontraste kun Egg" + +#: ../source/discussions/wheel-vs-egg.rst:7 +msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:11 +msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:14 +msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:17 +msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:20 +msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:22 +msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:26 +msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:31 +msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:34 +msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:38 +msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:41 +msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:47 +msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." +msgstr "" + +#: ../source/glossary.rst:3 +msgid "Glossary" +msgstr "Terminaro" + +#: ../source/glossary.rst:8 +msgid "Binary Distribution" +msgstr "" + +#: ../source/glossary.rst:11 +msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." +msgstr "" + +#: ../source/glossary.rst:14 +msgid "Built Distribution" +msgstr "" + +#: ../source/glossary.rst:17 +msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." +msgstr "" + +#: ../source/glossary.rst:26 +msgid "Distribution Package" +msgstr "" + +#: ../source/glossary.rst:29 +msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." +msgstr "" + +#: ../source/glossary.rst:34 +msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." +msgstr "" + +#: ../source/glossary.rst:41 +msgid "Egg" +msgstr "Egg" + +#: ../source/glossary.rst:44 +msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" +msgstr "" + +#: ../source/glossary.rst:49 +msgid "Extension Module" +msgstr "" + +#: ../source/glossary.rst:52 +msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." +msgstr "" + +#: ../source/glossary.rst:59 +msgid "Known Good Set (KGS)" +msgstr "" + +#: ../source/glossary.rst:62 +msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." +msgstr "" + +#: ../source/glossary.rst:68 +msgid "Import Package" +msgstr "" + +#: ../source/glossary.rst:71 +msgid "A Python module which can contain other modules or recursively, other packages." +msgstr "" + +#: ../source/glossary.rst:74 +msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." +msgstr "" + +#: ../source/glossary.rst:78 +msgid "Module" +msgstr "Modulo" + +#: ../source/glossary.rst:81 +msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." +msgstr "" + +#: ../source/glossary.rst:84 +msgid "Package Index" +msgstr "" + +#: ../source/glossary.rst:87 +msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." +msgstr "" + +#: ../source/glossary.rst:90 +msgid "Per Project Index" +msgstr "" + +#: ../source/glossary.rst:93 +msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." +msgstr "" + +#: ../source/glossary.rst:97 +msgid "Project" +msgstr "Projekto" + +#: ../source/glossary.rst:100 +msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." +msgstr "" + +#: ../source/glossary.rst:104 +msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." +msgstr "" + +#: ../source/glossary.rst:110 +msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." +msgstr "" + +#: ../source/glossary.rst:115 +msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." +msgstr "" + +#: ../source/glossary.rst:121 +msgid "Pure Module" +msgstr "Pura Modulo" + +#: ../source/glossary.rst:124 +msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." +msgstr "" + +#: ../source/glossary.rst:127 +msgid "Python Packaging Authority (PyPA)" +msgstr "" + +#: ../source/glossary.rst:130 +msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." +msgstr "" + +#: ../source/glossary.rst:139 +msgid "Python Package Index (PyPI)" +msgstr "" + +#: ../source/glossary.rst:142 +msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." +msgstr "" + +#: ../source/glossary.rst:145 +msgid "pypi.org" +msgstr "pypi.org" + +#: ../source/glossary.rst:148 +msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." +msgstr "" + +#: ../source/glossary.rst:152 +msgid "pyproject.toml" +msgstr "pyproject.toml" + +#: ../source/glossary.rst:155 +msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." +msgstr "" + +#: ../source/glossary.rst:157 +msgid "Release" +msgstr "" + +#: ../source/glossary.rst:160 +msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." +msgstr "" + +#: ../source/glossary.rst:163 +msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." +msgstr "" + +#: ../source/glossary.rst:168 +msgid "Requirement" +msgstr "" + +#: ../source/glossary.rst:171 +msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." +msgstr "" + +#: ../source/glossary.rst:177 +msgid "Requirement Specifier" +msgstr "" + +#: ../source/glossary.rst:180 +msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" +msgstr "" + +#: ../source/glossary.rst:187 +msgid "Requirements File" +msgstr "" + +#: ../source/glossary.rst:190 +msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." +msgstr "" + +#: ../source/glossary.rst:194 +#: ../source/guides/distributing-packages-using-setuptools.rst:56 +msgid "setup.py" +msgstr "setup.py" + +#: ../source/glossary.rst:195 +#: ../source/guides/distributing-packages-using-setuptools.rst:77 +msgid "setup.cfg" +msgstr "setup.cfg" + +#: ../source/glossary.rst:198 +msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." +msgstr "" + +#: ../source/glossary.rst:201 +msgid "Source Archive" +msgstr "" + +#: ../source/glossary.rst:204 +msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:208 +msgid "Source Distribution (or \"sdist\")" +msgstr "" + +#: ../source/glossary.rst:211 +msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:216 +msgid "System Package" +msgstr "" + +#: ../source/glossary.rst:219 +msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." +msgstr "" + +#: ../source/glossary.rst:222 +msgid "Version Specifier" +msgstr "Versio-Specifilo" + +#: ../source/glossary.rst:225 +msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." +msgstr "" + +#: ../source/glossary.rst:231 +msgid "Virtual Environment" +msgstr "" + +#: ../source/glossary.rst:234 +msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/glossary.rst:238 +msgid "Wheel" +msgstr "Wheel" + +#: ../source/glossary.rst:241 +msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." +msgstr "" + +#: ../source/glossary.rst:244 +msgid "Working Set" +msgstr "" + +#: ../source/glossary.rst:247 +msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:3 +msgid "Analyzing PyPI package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:5 +msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:15 +#: ../source/guides/supporting-windows-using-appveyor.rst:18 +msgid "Background" +msgstr "Fonaj informoj" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:17 +msgid "PyPI does not display download statistics for a number of reasons: [#]_" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:19 +msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:24 +msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:27 +msgid "``pip``'s download cache (lowers download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:28 +msgid "Internal or unofficial mirrors (can both raise or lower download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:29 +msgid "Packages not hosted on PyPI (for comparisons sake)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:30 +msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:32 +msgid "Known historical data quality issues (lowers download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:34 +msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:38 +msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:43 +msgid "Public dataset" +msgstr "Publika datenaro" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:45 +msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:50 +msgid "Getting set up" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:52 +msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:58 +msgid "Navigate to the `BigQuery web UI`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:59 +msgid "Create a new project." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:60 +msgid "Enable the `BigQuery API `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:63 +msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:69 +msgid "Data schema" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:71 +msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +msgid "Column" +msgstr "Kolumno" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/guides/using-manifest-in.rst:67 +#: ../source/specifications/core-metadata.rst:185 +msgid "Description" +msgstr "Priskribo" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/specifications/direct-url.rst:226 +msgid "Examples" +msgstr "Ekzemploj" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "timestamp" +msgstr "timestamp" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "Date and time" +msgstr "Dato kaj tempo" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "``2020-03-09 00:33:03 UTC``" +msgstr "``2020-03-09 00:33:03 UTC``" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "file.project" +msgstr "file.project" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "Project name" +msgstr "Nomo de projekto" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "``pipenv``, ``nose``" +msgstr "``pipenv``, ``nose``" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "file.version" +msgstr "file.version" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "Package version" +msgstr "Versio de pako" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "``0.1.6``, ``1.4.2``" +msgstr "``0.1.6``, ``1.4.2``" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "details.installer.name" +msgstr "details.installer.name" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "Installer" +msgstr "Instalilo" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "pip, `bandersnatch`_" +msgstr "pip, `bandersnatch`_" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "details.python" +msgstr "details.python" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "Python version" +msgstr "Versio de Python" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "``2.7.12``, ``3.6.4``" +msgstr "``2.7.12``, ``3.6.4``" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:93 +msgid "Useful queries" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:95 +msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:97 +msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:102 +msgid "Counting package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:104 +msgid "The following query counts the total number of downloads for the project \"pytest\"." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:119 +#: ../source/guides/analyzing-pypi-package-downloads.rst:140 +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "num_downloads" +msgstr "num_downloads" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:121 +msgid "26190085" +msgstr "26190085" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:124 +msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:142 +msgid "24334215" +msgstr "24334215" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:146 +msgid "Package downloads over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:148 +msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +msgid "month" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "1956741" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "2018-01-01" +msgstr "2018-01-01" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2344692" +msgstr "2344692" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2017-12-01" +msgstr "2017-12-01" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "1730398" +msgstr "1730398" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "2017-11-01" +msgstr "2017-11-01" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2047310" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2017-10-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "1744443" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "2017-09-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "1916952" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "2017-08-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:184 +msgid "Python versions over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:186 +msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "python" +msgstr "python" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "3.7" +msgstr "3.7" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "18051328726" +msgstr "18051328726" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "3.6" +msgstr "3.6" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "9635067203" +msgstr "9635067203" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "3.8" +msgstr "3.8" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "7781904681" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "2.7" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "6381252241" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "null" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "2026630299" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "3.5" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "1894153540" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:221 +msgid "Caveats" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:223 +msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:231 +msgid "Additional tools" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:233 +msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:237 +msgid "``google-cloud-bigquery``" +msgstr "``google-cloud-bigquery``" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:239 +msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:267 +msgid "``pypinfo``" +msgstr "``pypinfo``" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:269 +msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:273 +msgid "Install `pypinfo`_ using pip." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:279 +msgid "Usage:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:295 +msgid "``pandas-gbq``" +msgstr "``pandas-gbq``" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:297 +msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:301 +#: ../source/specifications/binary-distribution-format.rst:459 +msgid "References" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:303 +msgid "`PyPI Download Counts deprecation email `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:304 +msgid "`PyPI BigQuery dataset announcement email `__" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:3 +msgid "Creating and discovering plugins" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:5 +msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:10 +msgid "There are three major approaches to doing automatic plugin discovery:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:12 +msgid "`Using naming convention`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:13 +msgid "`Using namespace packages`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:14 +msgid "`Using package metadata`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:18 +msgid "Using naming convention" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:20 +msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:38 +msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:48 +msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:59 +msgid "Using namespace packages" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:61 +msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:89 +msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:101 +msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:115 +msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:121 +msgid "Using package metadata" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:123 +msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:128 +msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:139 +msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:154 +msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:163 +msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:166 +msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:170 +msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:5 +msgid "Packaging and distributing projects" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:7 +msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:11 +msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:15 +msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:25 +msgid "Requirements for packaging and distributing" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:26 +msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:29 +msgid "Install \"twine\" [1]_:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:43 +msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:49 +msgid "Configuring your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:53 +msgid "Initial files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:58 +msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:63 +msgid ":file:`setup.py` serves two primary functions:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:65 +msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:71 +msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:79 +msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:86 +msgid "README.rst / README.md" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:88 +msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:95 +msgid "For an example, see `README.md `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:99 +msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:108 +msgid "MANIFEST.in" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:110 +msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:115 +msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:119 +msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:122 +msgid "LICENSE.txt" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:124 +msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:130 +msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:135 +msgid "" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:137 +msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:141 +msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:149 +msgid "setup() args" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:151 +msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:155 +msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:164 +msgid "name" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:170 +msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:174 +msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:176 +msgid "Start & end with an ASCII letter or digit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:178 +msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:190 +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "version" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:196 +msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:200 +msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:203 +msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:206 +msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:214 +msgid "description" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:222 +msgid "Give a short and long description for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:224 +msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:229 +msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:235 +msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:245 +msgid "url" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:252 +msgid "Give a homepage URL for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:256 +msgid "author" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:263 +msgid "Provide details about the author." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:267 +msgid "license" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:273 +msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:279 +msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:287 +msgid "classifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:316 +msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:319 +msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:327 +msgid "keywords" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:333 +msgid "List keywords that describe your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:337 +msgid "project_urls" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:349 +msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:355 +msgid "packages" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:361 +msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:370 +msgid "py_modules" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:376 +msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:388 +msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:392 +msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:398 +msgid "python_requires" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:400 +msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:407 +msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:412 +msgid "And so on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:416 +msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:422 +msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:431 +msgid "package_data" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:440 +msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:445 +msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:449 +msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:457 +msgid "data_files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:463 +msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:469 +msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:479 +msgid "For more information see the distutils section on `Installing Additional Files `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:484 +msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:491 +msgid "scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:493 +msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:500 +msgid "entry_points" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:509 +msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:512 +msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:516 +msgid "The most commonly used entry point is \"console_scripts\" (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:521 +msgid "console_scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:531 +msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:538 +msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:545 +msgid "Choosing a versioning scheme" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:548 +msgid "Standards compliance for interoperability" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:550 +msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:556 +msgid "Here are some examples of compliant version numbers::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:567 +msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:573 +msgid "Scheme choices" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:576 +msgid "Semantic versioning (preferred)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:578 +msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:582 +msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:585 +msgid "MAJOR version when they make incompatible API changes," +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:586 +msgid "MINOR version when they add functionality in a backwards-compatible manner, and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:587 +msgid "MAINTENANCE version when they make backwards-compatible bug fixes." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:589 +msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:594 +msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:598 +msgid "Date based versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:600 +msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:604 +msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:607 +msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:611 +msgid "Serial versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:613 +msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:616 +msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:621 +msgid "Hybrid schemes" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:623 +msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:629 +msgid "Pre-release versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:631 +msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:634 +msgid "zero or more dev releases (denoted with a \".devN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:635 +msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:636 +msgid "zero or more beta releases (denoted with a \".bN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:637 +msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:639 +msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:644 +msgid "Local version identifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:646 +msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:653 +msgid "A local version identifier takes the form ``+``. For example::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:661 +msgid "Working in \"development mode\"" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:663 +msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:667 +msgid "Assuming you're in the root of your project directory, then run:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:674 +msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:680 +msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:688 +msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:692 +msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:697 +msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:701 +msgid "Lastly, if you don't want to install any dependencies at all, you can run::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:706 +msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:713 +msgid "Packaging your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:715 +msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:720 +msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:737 +msgid "Source distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:739 +msgid "Minimally, you should create a :term:`Source Distribution `:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:755 +msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:763 +msgid "Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:765 +msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:770 +msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:773 +msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:776 +msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:785 +msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:792 +msgid "Pure Python Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:794 +msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:797 +#: ../source/guides/distributing-packages-using-setuptools.rst:826 +msgid "To build the wheel:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:811 +msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:815 +msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:821 +msgid "Platform Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:823 +msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:841 +msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:847 +msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:855 +msgid "Uploading your Project to PyPI" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:857 +msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:861 +msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:866 +msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:871 +msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:877 +msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:888 +msgid "Create an account" +msgstr "Krei konton" + +#: ../source/guides/distributing-packages-using-setuptools.rst:890 +msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:894 +msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:897 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:901 +msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:904 +msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:913 +msgid "**Be aware that this stores your token in plaintext.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:915 +#: ../source/guides/migrating-to-pypi-org.rst:70 +#: ../source/guides/migrating-to-pypi-org.rst:109 +#: ../source/guides/using-testpypi.rst:83 +msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:921 +msgid "Upload your distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:923 +msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:926 +msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:930 +msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:937 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:944 +#: ../source/tutorials/installing-packages.rst:663 +msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:950 +msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:5 +msgid "Dropping support for older Python versions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:7 +msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:9 +msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:12 +msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:14 +msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:17 +msgid "Requirements" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:19 +msgid "This workflow requires that:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:21 +msgid "The publisher is using the latest version of :ref:`setuptools`," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:22 +msgid "The latest version of :ref:`twine` is used to upload the package," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:23 +msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:26 +msgid "Dealing with the universal wheels" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:28 +msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:36 +msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:48 +msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:53 +msgid "Defining the Python version required" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:56 +msgid "1. Download the newest version of Setuptools" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:58 +msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:60 +msgid "Steps:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:74 +msgid "`setuptools` version should be above 24.0.0." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:77 +msgid "2. Specify the version ranges for supported Python distributions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:79 +msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:81 +#: ../source/specifications/core-metadata.rst:139 +#: ../source/specifications/core-metadata.rst:463 +#: ../source/specifications/core-metadata.rst:487 +#: ../source/specifications/core-metadata.rst:527 +#: ../source/specifications/core-metadata.rst:550 +#: ../source/specifications/core-metadata.rst:583 +#: ../source/specifications/core-metadata.rst:693 +#: ../source/specifications/core-metadata.rst:722 +msgid "Examples::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:86 +msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:101 +msgid "3. Validating the Metadata before publishing" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:103 +msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:105 +msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:108 +msgid "You can see the contents of the generated file like this::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:112 +msgid "Validate that the following is in place, before publishing the package:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:114 +msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:115 +msgid "The Requires-Python field is set and matches your specification in setup.py." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:118 +msgid "4. Using Twine to publish" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:120 +msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:122 +msgid "Make sure you are using the newest version of Twine, at least 1.9." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:125 +msgid "Dropping a Python release" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:127 +msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:129 +msgid "It must be done in this order for the automated fallback to work." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:131 +msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:133 +msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:5 +msgid "Hosting your own simple repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:8 +msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:13 +msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:29 +msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:35 +msgid "\"Manual\" repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:37 +msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:51 +msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:58 +msgid "For complete documentation of the simple repository protocol, see :pep:`503`." +msgstr "" + +#: ../source/guides/index.rst:8 +#: ../source/guides/index.rst:8 +msgid "Installing Packages:" +msgstr "" + +#: ../source/guides/index.rst:20 +#: ../source/guides/index.rst:20 +msgid "Building and Publishing Projects:" +msgstr "" + +#: ../source/guides/index.rst:38 +#: ../source/guides/index.rst:38 +msgid "Miscellaneous:" +msgstr "" + +#: ../source/guides/index.rst:4 +msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:5 +msgid "Package index mirrors and caches" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:8 +#: ../source/guides/supporting-multiple-python-versions.rst:8 +msgid "2014-12-24" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:14 +msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:17 +msgid "Three options are available in this area:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:19 +msgid "pip provides local caching options," +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:20 +msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:22 +msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:27 +msgid "Caching with pip" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:29 +msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:32 +msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:36 +msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:45 +msgid "Caching with devpi" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:47 +msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:55 +msgid "Complete mirror with bandersnatch" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:57 +msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:63 +msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:5 +msgid "Installing scientific packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:11 +msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:16 +msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:22 +msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:29 +msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:35 +msgid "Building from source" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:37 +msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:45 +msgid "Linux distribution packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:47 +msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:51 +msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:57 +msgid "Windows installers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:59 +msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:64 +msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:67 +msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:73 +msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:79 +msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:86 +msgid "macOS installers and package managers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:88 +msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:92 +msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:99 +msgid "SciPy distributions" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:101 +msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:105 +msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:109 +#: ../source/key_projects.rst:596 +msgid "Spack" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:110 +msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:119 +msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:128 +msgid "The conda cross-platform package manager" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:130 +msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:136 +msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 +msgid "Installing stand alone command line tools" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 +msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 +msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 +msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 +msgid "pipx only works with Python 3.6+." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 +msgid "``pipx`` is installed with ``pip``:" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 +msgid "You may need to restart your terminal for the path updates to take effect." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 +msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 +#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 +msgid "For example" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 +msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 +msgid "To upgrade or uninstall the package" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 +msgid "``pipx`` can be upgraded or uninstalled with pip" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 +msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 +msgid "To see the full list of commands ``pipx`` offers, run" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 +msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:5 +msgid "Installing pip/setuptools/wheel with Linux Package Managers" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:8 +msgid "2015-09-17" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:11 +msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:14 +msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:18 +msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:25 +msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:32 +msgid "Fedora" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:34 +msgid "Fedora 21:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:36 +#: ../source/guides/installing-using-linux-tools.rst:45 +#: ../source/guides/installing-using-linux-tools.rst:124 +#: ../source/guides/installing-using-linux-tools.rst:138 +#: ../source/guides/installing-using-linux-tools.rst:158 +msgid "Python 2::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:41 +msgid "Python 3: ``sudo yum install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:43 +msgid "Fedora 22:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:50 +msgid "Python 3: ``sudo dnf install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:53 +msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:63 +msgid "CentOS/RHEL" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:65 +msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:68 +msgid "To install pip and wheel for the system Python, there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:70 +msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:77 +msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:81 +msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:85 +msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:92 +msgid "To additionally upgrade setuptools, run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:97 +msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:101 +msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:104 +msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:106 +msgid "For CentOS, see here: https://www.softwarecollections.org/en/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:108 +msgid "Be aware that collections may not contain the most recent versions." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:110 +msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:116 +msgid "For example, for Python 3.4 on CentOS7/RHEL7::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:122 +msgid "openSUSE" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:129 +#: ../source/guides/installing-using-linux-tools.rst:143 +#: ../source/guides/installing-using-linux-tools.rst:162 +msgid "Python 3::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:135 +msgid "Debian/Ubuntu" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:150 +msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:156 +msgid "Arch Linux" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:168 +msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 +msgid "Installing packages using pip and virtual environments" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 +msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 +msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 +msgid "Installing pip" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 +msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 +msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 +msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 +msgid "Afterwards, you should have the newest pip installed in your user site:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 +msgid "The Python installers for Windows include pip. You should be able to access pip using:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 +msgid "You can make sure that pip is up-to-date by running:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 +msgid "Installing virtualenv" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 +msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 +msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 +msgid "Creating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 +msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 +msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 +msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 +msgid "venv will create a virtual Python installation in the ``env`` folder." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 +msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 +msgid "Activating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 +msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 +msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 +msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 +msgid "Leaving the virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 +msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 +msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 +msgid "Installing packages" +msgstr "Instalo de pakoj" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 +msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 +msgid "pip should download requests and all of its dependencies and install them:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 +msgid "Installing specific versions" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 +msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 +msgid "To install the latest ``2.x`` release of requests:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 +msgid "To install pre-release versions of packages, use the ``--pre`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 +msgid "Installing extras" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 +msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 +msgid "Installing from source" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 +msgid "pip can install a package directly from source, for example:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 +msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 +msgid "Installing from version control systems" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 +msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 +msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 +#: ../source/tutorials/installing-packages.rst:569 +msgid "Installing from local archives" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 +msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 +msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 +msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 +msgid "Using other package indexes" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 +msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 +msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 +#: ../source/tutorials/installing-packages.rst:389 +msgid "Upgrading packages" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 +msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 +msgid "Using requirements files" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 +msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 +msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 +msgid "Freezing dependencies" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 +msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 +msgid "Which will output a list of package specifiers such as:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 +msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:2 +msgid "Making a PyPI-friendly README" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:4 +msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:9 +msgid "Creating a README file" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:11 +msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:13 +msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:16 +msgid "plain text" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:17 +msgid "`reStructuredText `_ (without Sphinx extensions)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:18 +msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:21 +msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:25 +msgid "Including your README in your package's metadata" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:27 +msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:33 +msgid ":ref:`description-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:34 +msgid ":ref:`description-content-type-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:36 +msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:39 +msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:45 +msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:60 +msgid "The minimum required versions of the respective tools are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:62 +msgid "``setuptools >= 38.6.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:63 +msgid "``wheel >= 0.31.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:64 +msgid "``twine >= 1.11.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:66 +msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:72 +msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:95 +msgid "Validating reStructuredText markup" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:97 +msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:100 +msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:105 +msgid "You can check your README for markup errors before uploading as follows:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:107 +msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:122 +msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:125 +msgid "Run ``twine check`` on the sdist and wheel::" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:129 +msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:4 +msgid "Migrating to PyPI.org" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:6 +msgid ":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``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:12 +msgid "Publishing releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:14 +msgid "``pypi.org`` is the default upload platform as of September 2016." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:16 +msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:22 +msgid "The default upload settings switched to ``pypi.org`` in the following versions:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:24 +msgid "``twine`` 1.8.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:25 +msgid "``setuptools`` 27.0.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:26 +msgid "Python 2.7.13 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:27 +msgid "Python 3.4.6 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:28 +msgid "Python 3.5.3 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:29 +msgid "Python 3.6.0 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:31 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:48 +msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:51 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:67 +msgid "(``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.)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:73 +msgid "Registering package names & metadata" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:75 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:79 +msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:84 +msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:89 +#: ../source/guides/using-testpypi.rst:5 +msgid "Using TestPyPI" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:91 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:113 +msgid "Registering new user accounts" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:115 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:121 +msgid "Browsing packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:123 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:130 +msgid "Downloading packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:132 +msgid "``pypi.org`` is the default host for downloading packages." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:135 +msgid "Managing published packages and releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:137 +msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:5 +msgid "Multi-version installs" +msgstr "" + +#: ../source/guides/multi-version-installs.rst:8 +msgid "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``)." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:13 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:31 +msgid "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 ``python -c ''`` to invoke the application's main entry point directly." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:38 +msgid "Refer to the `pkg_resources documentation `__ for more details." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:5 +msgid "Packaging binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:8 +msgid "2013-12-08" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:10 +msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:20 +msgid "An overview of binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:23 +msgid "Use cases" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:25 +msgid "The typical use cases for binary extensions break down into just three conventional categories:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:28 +msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:39 +msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:47 +msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:56 +msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:61 +msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:71 +msgid "Disadvantages" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:73 +msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:80 +msgid "This means that binary extensions:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:82 +msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:85 +msgid "may not be compatible with different builds of the CPython reference interpreter" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:88 +msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:91 +msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:96 +msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:101 +msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:108 +msgid "Alternatives to handcoded accelerator modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:110 +msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:115 +msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:122 +msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:132 +msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:141 +msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:150 +msgid "Alternatives to handcoded wrapper modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:152 +msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:158 +msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:162 +msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:168 +msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:175 +msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:181 +msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:185 +msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:189 +msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:203 +msgid "Alternatives for low level system access" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:205 +msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:213 +msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:222 +msgid "Implementing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:224 +msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:241 +msgid "Building binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:244 +msgid "Building extensions for multiple platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:246 +msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:256 +msgid "Binary extensions for Windows" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:258 +msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:263 +msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:269 +msgid "To set up a build environment for binary extensions, the steps are as follows:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:271 +msgid "For Python 2.7" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:273 +msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:276 +msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:278 +#: ../source/guides/packaging-binary-extensions.rst:288 +#: ../source/guides/packaging-binary-extensions.rst:295 +msgid "Done." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:280 +msgid "For Python 3.4" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:282 +msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:285 +msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:287 +msgid "Set DISTUTILS_USE_SDK=1" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:290 +msgid "For Python 3.5" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:292 +msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:297 +msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:301 +msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:305 +msgid "Binary extensions for Linux" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:307 +msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:313 +msgid "Binary extensions for macOS" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:315 +msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:325 +msgid "Publishing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:327 +msgid "For interim guidance on this topic, see the discussion in `this issue `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:343 +msgid "Additional resources" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:345 +msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:352 +msgid "Cross-platform wheel generation with scikit-build" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:354 +msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:362 +msgid "Introduction to C/C++ extension modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:364 +msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:367 +msgid "`What are (c)python extension modules? `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:368 +msgid "`Releasing the gil `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:369 +msgid "`Writing cpython extension modules using C++ `_" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:3 +msgid "Packaging namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:5 +msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:24 +msgid "And you use this package in your code like so::" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:29 +msgid "Then you can break these sub-packages into two separate distributions:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:46 +msgid "Each sub-package can now be separately installed, used, and versioned." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:48 +msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:58 +msgid "Creating a namespace package" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:60 +msgid "There are currently three different approaches to creating namespace packages:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:62 +msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:66 +msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:69 +msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:73 +msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:80 +msgid "Native namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:82 +msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:97 +msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:102 +msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:117 +msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:123 +msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:129 +msgid "pkgutil-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:131 +msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:136 +msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:148 +#: ../source/guides/packaging-namespace-packages.rst:194 +msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:155 +#: ../source/guides/packaging-namespace-packages.rst:201 +msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:160 +msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:171 +msgid "pkg_resources-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:173 +msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:182 +msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:206 +msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:216 +msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:223 +msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:237 +msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 +msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 +msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 +msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 +msgid "Saving credentials on GitHub" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 +msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 +msgid "Let's begin! 🚀" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 +msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 +msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 +msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 +msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 +msgid "Creating a workflow definition" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 +msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 +msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 +msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 +msgid "Defining a workflow job environment" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 +msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 +msgid "Checking out the project and building distributions" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 +msgid "Then, add the following under the ``build-n-publish`` section:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 +msgid "This will download your repository into the CI runner and then install and activate Python 3.7." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 +msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 +msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 +msgid "So add this to the steps list:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 +msgid "Publishing the distribution to PyPI and TestPyPI" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 +msgid "Finally, add the following steps at the end:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 +msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 +msgid "That's all, folks!" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 +msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:5 +msgid "Single-sourcing the package version" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:8 +msgid "There are many techniques to maintain a single source of truth for the version number of your project:" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:11 +msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:38 +msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:47 +msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:52 +msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:55 +msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:58 +msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:65 +msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:76 +msgid "Example using this technique: `warehouse `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:78 +msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:86 +msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:91 +msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:95 +msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:110 +msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:114 +msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:128 +msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:134 +msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:138 +msgid "Example using this technique: `setuptools `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:141 +msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:155 +msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:161 +msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:5 +msgid "Supporting multiple Python versions" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:37 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:43 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:49 +msgid "Automated testing and continuous integration" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:51 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:60 +msgid "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:" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:66 +msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:69 +msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:80 +msgid "Both `Travis CI`_ 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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:85 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:89 +msgid "Tools for single-source Python packages" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:91 +msgid "`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_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:100 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:107 +msgid "a Python 2 (by syntax) module in a Python 3 project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:108 +msgid "a Python 3 (by syntax) module in a *Python 2* project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:110 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:117 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:124 +msgid "What's in which Python?" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:126 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:3 +msgid "Supporting Windows using Appveyor" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:6 +msgid "2015-12-03" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:8 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:20 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:24 +msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:30 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:38 +msgid "Setting up" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:40 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:45 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:49 +msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:54 +msgid "Adding Appveyor support to your project" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:61 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:69 +msgid "appveyor.yml" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:75 +msgid "This file can be downloaded from `here `__." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:77 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:80 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:88 +msgid "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``)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:94 +msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:97 +msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:100 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:109 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:114 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:119 +msgid "Support script" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:121 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:126 +msgid "`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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:133 +msgid "You can simply download the batch file and include it in your project unchanged." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:137 +msgid "Access to the built wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:139 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:147 +msgid "Additional notes" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:150 +msgid "Testing with tox" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:152 +msgid "Many projects use the `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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:156 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:160 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:165 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:170 +msgid "``DISTUTILS_USE_SDK``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:171 +msgid "``MSSdk``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:172 +msgid "``INCLUDE``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:173 +msgid "``LIB``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:175 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:181 +msgid "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 Travis or 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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:188 +msgid "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``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:192 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:197 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:203 +msgid "Automatically uploading wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:205 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:210 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:216 +msgid "External dependencies" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:218 +msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:221 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:230 +msgid "Support scripts" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:232 +msgid "For reference, the SDK setup support script is listed here:" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:234 +msgid "``appveyor-sample/build.cmd``" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:5 +msgid "Tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:7 +msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:12 +msgid "Application dependency management" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:14 +msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:18 +msgid "When ``pipenv`` does not meet your use case, consider other tools like:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:20 +msgid ":ref:`pip`" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:22 +msgid "`pip-tools `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:24 +msgid "`Poetry `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:27 +msgid "Installation tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:29 +msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:34 +msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:37 +msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:40 +msgid ":ref:`buildout`: primarily focused on the web development community" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:42 +msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:47 +msgid "Packaging tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:49 +msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:52 +msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:56 +msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:61 +msgid "Publishing platform migration" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:63 +msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:67 +msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:72 +msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:77 +msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:82 +msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:88 +msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:93 +msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:102 +msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:107 +msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:5 +msgid "Including files in source distributions with ``MANIFEST.in``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:7 +msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:17 +msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:22 +msgid "How files are included in an sdist" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:24 +msgid "The following files are included in a source distribution by default:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:26 +msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:28 +msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:30 +msgid "scripts specified by the ``scripts`` ``setup()`` argument" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:31 +msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:33 +msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:35 +msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:37 +msgid "all files matching the pattern :file:`test/test*.py`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:38 +msgid ":file:`setup.py` (or whatever you called your setup script)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:39 +msgid ":file:`setup.cfg`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:40 +msgid ":file:`README`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:41 +msgid ":file:`README.txt`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:42 +msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:43 +msgid ":file:`README.md` (setuptools 36.4.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:44 +msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:45 +msgid ":file:`MANIFEST.in`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:47 +msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:52 +msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:60 +msgid ":file:`MANIFEST.in` commands" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:62 +msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:67 +msgid "Command" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid ":samp:`include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid "Add all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid ":samp:`exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid "Remove all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid ":samp:`global-include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid "Add all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid ":samp:`global-exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid "Remove all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid ":samp:`graft {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid "Add all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid ":samp:`prune {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid "Remove all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:79 +msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:87 +msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:91 +msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:95 +msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:101 +msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." +msgstr "" + +#: ../source/guides/using-testpypi.rst:7 +msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" +msgstr "" + +#: ../source/guides/using-testpypi.rst:13 +msgid "Registering your account" +msgstr "" + +#: ../source/guides/using-testpypi.rst:15 +msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." +msgstr "" + +#: ../source/guides/using-testpypi.rst:19 +msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." +msgstr "" + +#: ../source/guides/using-testpypi.rst:24 +msgid "Using TestPyPI with Twine" +msgstr "" + +#: ../source/guides/using-testpypi.rst:26 +msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:33 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/using-testpypi.rst:39 +msgid "Using TestPyPI with pip" +msgstr "" + +#: ../source/guides/using-testpypi.rst:41 +msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:56 +msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" +msgstr "" + +#: ../source/guides/using-testpypi.rst:73 +msgid "Setting up TestPyPI in :file:`.pypirc`" +msgstr "" + +#: ../source/guides/using-testpypi.rst:75 +msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" +msgstr "" + +#: ../source/index.rst:3 +#: ../source/key_projects.rst:181 +msgid "Python Packaging User Guide" +msgstr "Manlibro por Python-Uzantoj pri Pakado" + +#: ../source/index.rst:5 +msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." +msgstr "" + +#: ../source/index.rst:5 +msgid "python, packaging, guide, tutorial" +msgstr "" + +#: ../source/index.rst:24 +msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." +msgstr "" + +#: ../source/index.rst:28 +msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" +msgstr "" + +#: ../source/index.rst:36 +msgid "Get started" +msgstr "Komenci" + +#: ../source/index.rst:38 +msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" +msgstr "" + +#: ../source/index.rst:41 +msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" +msgstr "" + +#: ../source/index.rst:43 +msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" +msgstr "" + +#: ../source/index.rst:45 +msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" +msgstr "" + +#: ../source/index.rst:47 +msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" +msgstr "" + +#: ../source/index.rst:52 +msgid "Learn more" +msgstr "Lerni pli" + +#: ../source/index.rst:54 +msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" +msgstr "" + +#: ../source/index.rst:56 +msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/index.rst:58 +msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." +msgstr "" + +#: ../source/index.rst:60 +msgid "The :doc:`specifications/index` section for packaging interoperability specifications." +msgstr "" + +#: ../source/index.rst:62 +msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." +msgstr "" + +#: ../source/key_projects.rst:6 +msgid "Project Summaries" +msgstr "" + +#: ../source/key_projects.rst:8 +msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." +msgstr "" + +#: ../source/key_projects.rst:14 +msgid "PyPA Projects" +msgstr "Projektoj de PyPA" + +#: ../source/key_projects.rst:19 +msgid "bandersnatch" +msgstr "bandersnatch" + +#: ../source/key_projects.rst:21 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" +"`Cimoj `__ | `GitHub " +"`__ | `PyPI `__" + +#: ../source/key_projects.rst:25 +msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." +msgstr "" + +#: ../source/key_projects.rst:35 +msgid "build" +msgstr "build" + +#: ../source/key_projects.rst:37 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" +"`Dokumentaro `__ | `Cimoj `__ | `GitHub `__ | `" +"PyPI `__" + +#: ../source/key_projects.rst:42 +msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." +msgstr "" + +#: ../source/key_projects.rst:49 +msgid "cibuildwheel" +msgstr "cibuildwheel" + +#: ../source/key_projects.rst:51 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" +msgstr "" +"`Dokumentaro `__ | `Cimoj " +"`__ | `GitHub `__ | `PyPI `__ " +"| `Diskutoj `__ | `Discord " +"#cibuildwheel `__" + +#: ../source/key_projects.rst:58 +msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." +msgstr "" + +#: ../source/key_projects.rst:64 +msgid "distlib" +msgstr "distlib" + +#: ../source/key_projects.rst:66 +msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" +msgstr "" +"`Dokumentaro `__ | `Cimoj " +"`__ | `" +"Bitbucket `__ | `PyPI `__" + +#: ../source/key_projects.rst:71 +msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." +msgstr "" + +#: ../source/key_projects.rst:80 +msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." +msgstr "" + +#: ../source/key_projects.rst:90 +msgid "packaging" +msgstr "packaging" + +#: ../source/key_projects.rst:92 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:97 +msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." +msgstr "" + +#: ../source/key_projects.rst:99 +msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." +msgstr "" + +#: ../source/key_projects.rst:107 +msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." +msgstr "" + +#: ../source/key_projects.rst:119 +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "pip" +msgstr "pip" + +#: ../source/key_projects.rst:121 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" +"`Dokumentaro `__ | `Cimoj `__ | `GitHub `__ | `PyPI " +"`__" + +#: ../source/key_projects.rst:126 +msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." +msgstr "" + +#: ../source/key_projects.rst:129 +msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." +msgstr "" + +#: ../source/key_projects.rst:137 +msgid "Pipenv" +msgstr "Pipenv" + +#: ../source/key_projects.rst:139 +msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" +msgstr "" +"`Dokumentaro `__ | `Fonto `__ | `Cimoj `__ | `PyPI " +"`__" + +#: ../source/key_projects.rst:144 +msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." +msgstr "" + +#: ../source/key_projects.rst:148 +msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." +msgstr "" + +#: ../source/key_projects.rst:159 +msgid "Pipfile" +msgstr "Pipfile" + +#: ../source/key_projects.rst:161 +msgid "`Source `__" +msgstr "`Fonto `__" + +#: ../source/key_projects.rst:163 +msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." +msgstr "" + +#: ../source/key_projects.rst:170 +msgid "pipx" +msgstr "pipx" + +#: ../source/key_projects.rst:172 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:176 +msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." +msgstr "" + +#: ../source/key_projects.rst:183 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:187 +msgid "This guide!" +msgstr "" + +#: ../source/key_projects.rst:192 +msgid "readme_renderer" +msgstr "readme_renderer" + +#: ../source/key_projects.rst:194 +msgid "`GitHub and docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:197 +msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." +msgstr "" + +#: ../source/key_projects.rst:208 +msgid "setuptools" +msgstr "setuptools" + +#: ../source/key_projects.rst:210 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" +"`Dokumentaro `__ | `Cimoj " +"`__ | `GitHub `__ | `PyPI `__" + +#: ../source/key_projects.rst:215 +msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." +msgstr "" + +#: ../source/key_projects.rst:220 +msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." +msgstr "" + +#: ../source/key_projects.rst:227 +msgid "trove-classifiers" +msgstr "" + +#: ../source/key_projects.rst:229 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:233 +msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." +msgstr "" + +#: ../source/key_projects.rst:239 +msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." +msgstr "" + +#: ../source/key_projects.rst:253 +msgid "twine" +msgstr "" + +#: ../source/key_projects.rst:255 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:260 +msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." +msgstr "" + +#: ../source/key_projects.rst:270 +#: ../source/overview.rst:415 +msgid "virtualenv" +msgstr "" + +#: ../source/key_projects.rst:272 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:277 +msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/key_projects.rst:290 +msgid "Warehouse" +msgstr "" + +#: ../source/key_projects.rst:292 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:296 +msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." +msgstr "" + +#: ../source/key_projects.rst:304 +msgid "wheel" +msgstr "" + +#: ../source/key_projects.rst:306 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:311 +msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." +msgstr "" + +#: ../source/key_projects.rst:315 +msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." +msgstr "" + +#: ../source/key_projects.rst:324 +msgid "Non-PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:329 +msgid "bento" +msgstr "" + +#: ../source/key_projects.rst:331 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:336 +msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." +msgstr "" + +#: ../source/key_projects.rst:344 +msgid "buildout" +msgstr "" + +#: ../source/key_projects.rst:346 +msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:351 +msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." +msgstr "" + +#: ../source/key_projects.rst:358 +msgid "conda" +msgstr "" + +#: ../source/key_projects.rst:360 +msgid "`Docs `__" +msgstr "" + +#: ../source/key_projects.rst:362 +msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." +msgstr "" + +#: ../source/key_projects.rst:369 +msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." +msgstr "" + +#: ../source/key_projects.rst:373 +msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." +msgstr "" + +#: ../source/key_projects.rst:386 +msgid "devpi" +msgstr "" + +#: ../source/key_projects.rst:388 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:392 +msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." +msgstr "" + +#: ../source/key_projects.rst:401 +msgid "flit" +msgstr "" + +#: ../source/key_projects.rst:403 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:407 +msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." +msgstr "" + +#: ../source/key_projects.rst:412 +msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." +msgstr "" + +#: ../source/key_projects.rst:422 +msgid "enscons" +msgstr "" + +#: ../source/key_projects.rst:424 +msgid "`Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:428 +msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." +msgstr "" + +#: ../source/key_projects.rst:443 +msgid "Hashdist" +msgstr "" + +#: ../source/key_projects.rst:445 +msgid "`Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:448 +msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." +msgstr "" + +#: ../source/key_projects.rst:460 +msgid "hatch" +msgstr "" + +#: ../source/key_projects.rst:462 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:465 +msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." +msgstr "" + +#: ../source/key_projects.rst:475 +msgid "multibuild" +msgstr "" + +#: ../source/key_projects.rst:477 +msgid "`GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:479 +msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." +msgstr "" + +#: ../source/key_projects.rst:485 +msgid "pex" +msgstr "" + +#: ../source/key_projects.rst:487 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:491 +msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." +msgstr "" + +#: ../source/key_projects.rst:500 +msgid "pip-tools" +msgstr "" + +#: ../source/key_projects.rst:502 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:505 +msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." +msgstr "" + +#: ../source/key_projects.rst:517 +msgid "piwheels" +msgstr "" + +#: ../source/key_projects.rst:519 +msgid "`Website `__ | `Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:523 +msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." +msgstr "" + +#: ../source/key_projects.rst:532 +msgid "poetry" +msgstr "" + +#: ../source/key_projects.rst:534 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:538 +msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." +msgstr "" + +#: ../source/key_projects.rst:548 +msgid "pypiserver" +msgstr "" + +#: ../source/key_projects.rst:550 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:554 +msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." +msgstr "" + +#: ../source/key_projects.rst:564 +msgid "scikit-build" +msgstr "" + +#: ../source/key_projects.rst:566 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:570 +msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." +msgstr "" + +#: ../source/key_projects.rst:582 +msgid "shiv" +msgstr "" + +#: ../source/key_projects.rst:584 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:588 +msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." +msgstr "" + +#: ../source/key_projects.rst:598 +msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" +msgstr "" + +#: ../source/key_projects.rst:603 +msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." +msgstr "" + +#: ../source/key_projects.rst:611 +msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." +msgstr "" + +#: ../source/key_projects.rst:617 +msgid "zest.releaser" +msgstr "" + +#: ../source/key_projects.rst:619 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:623 +msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." +msgstr "" + +#: ../source/key_projects.rst:630 +msgid "Standard Library Projects" +msgstr "" + +#: ../source/key_projects.rst:635 +msgid "ensurepip" +msgstr "" + +#: ../source/key_projects.rst:637 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:640 +msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." +msgstr "" + +#: ../source/key_projects.rst:649 +msgid "distutils" +msgstr "" + +#: ../source/key_projects.rst:651 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:654 +msgid "The original Python packaging system, added to the standard library in Python 2.0." +msgstr "" + +#: ../source/key_projects.rst:657 +msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." +msgstr "" + +#: ../source/key_projects.rst:670 +msgid "venv" +msgstr "" + +#: ../source/key_projects.rst:672 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:675 +msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/news.rst:2 +msgid "News" +msgstr "" + +#: ../source/news.rst:5 +msgid "September 2019" +msgstr "" + +#: ../source/news.rst:6 +msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" +msgstr "" + +#: ../source/news.rst:9 +msgid "August 2019" +msgstr "" + +#: ../source/news.rst:10 +msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" +msgstr "" + +#: ../source/news.rst:13 +msgid "July 2019" +msgstr "" + +#: ../source/news.rst:14 +msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" +msgstr "" + +#: ../source/news.rst:15 +msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" +msgstr "" + +#: ../source/news.rst:16 +msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" +msgstr "" + +#: ../source/news.rst:17 +msgid "Updated directory layout examples for consistency. (:pr:`611`)" +msgstr "" + +#: ../source/news.rst:18 +msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" +msgstr "" + +#: ../source/news.rst:21 +msgid "June 2019" +msgstr "" + +#: ../source/news.rst:22 +msgid "Fixed some typos. (:pr:`620`)" +msgstr "" + +#: ../source/news.rst:25 +msgid "May 2019" +msgstr "" + +#: ../source/news.rst:26 +msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" +msgstr "" + +#: ../source/news.rst:27 +msgid "Added a MANIFEST.in guide page. (:pr:`609`)" +msgstr "" + +#: ../source/news.rst:30 +msgid "April 2019" +msgstr "" + +#: ../source/news.rst:31 +msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" +msgstr "" + +#: ../source/news.rst:32 +msgid "Reduced emphasis on virtualenv. (:pr:`606`)" +msgstr "" + +#: ../source/news.rst:35 +msgid "March 2019" +msgstr "" + +#: ../source/news.rst:36 +msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" +msgstr "" + +#: ../source/news.rst:37 +msgid "Covered RTD details for contributing. (:pr:`600`)" +msgstr "" + +#: ../source/news.rst:40 +msgid "February 2019" +msgstr "" + +#: ../source/news.rst:41 +msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" +msgstr "" + +#: ../source/news.rst:42 +msgid "Added instructions to install Python CLI applications. (:pr:`594`)" +msgstr "" + +#: ../source/news.rst:45 +msgid "January 2019" +msgstr "" + +#: ../source/news.rst:46 +msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" +msgstr "" + +#: ../source/news.rst:47 +msgid "Updated Sphinx and Nox. (:pr:`591`)" +msgstr "" + +#: ../source/news.rst:48 +msgid "Referenced Twine from Python3. (:pr:`581`)" +msgstr "" + +#: ../source/news.rst:51 +msgid "December 2018" +msgstr "" + +#: ../source/news.rst:52 +msgid "No programmers in the office!" +msgstr "" + +#: ../source/news.rst:55 +msgid "November 2018" +msgstr "" + +#: ../source/news.rst:56 +msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" +msgstr "" + +#: ../source/news.rst:57 +msgid "Changed bumpversion to bump2version. (:pr:`572`)" +msgstr "" + +#: ../source/news.rst:58 +msgid "Added single-sourcing package version example. (:pr:`573`)" +msgstr "" + +#: ../source/news.rst:59 +msgid "Added a guide for creating documentation. (:pr:`568`)" +msgstr "" + +#: ../source/news.rst:62 +msgid "October 2018" +msgstr "" + +#: ../source/news.rst:63 +msgid "Updated Nox package name. (:pr:`566`)" +msgstr "" + +#: ../source/news.rst:64 +msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" +msgstr "" + +#: ../source/news.rst:67 +msgid "September 2018" +msgstr "" + +#: ../source/news.rst:68 +msgid "Added a section on checking RST markup. (:pr:`554`)" +msgstr "" + +#: ../source/news.rst:69 +msgid "Updated user installs page. (:pr:`558`)" +msgstr "" + +#: ../source/news.rst:70 +msgid "Updated Google BigQuery urls. (:pr:`556`)" +msgstr "" + +#: ../source/news.rst:71 +msgid "Replaced tar command with working command. (:pr:`552`)" +msgstr "" + +#: ../source/news.rst:72 +msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" +msgstr "" + +#: ../source/news.rst:75 +msgid "August 2018" +msgstr "" + +#: ../source/news.rst:76 +msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" +msgstr "" + +#: ../source/news.rst:77 +msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" +msgstr "" + +#: ../source/news.rst:78 +msgid "Updated Python version supported by virtualenv. (:pr:`538`)" +msgstr "" + +#: ../source/news.rst:79 +msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" +msgstr "" + +#: ../source/news.rst:82 +msgid "July 2018" +msgstr "" + +#: ../source/news.rst:84 +msgid "Improved binary extension docs. (:pr:`531`)" +msgstr "" + +#: ../source/news.rst:85 +msgid "Added scikit-build to key projects. (:pr:`530`)" +msgstr "" + +#: ../source/news.rst:88 +msgid "June 2018" +msgstr "" + +#: ../source/news.rst:90 +msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" +msgstr "" + +#: ../source/news.rst:91 +msgid "Updated Markdown descriptions explanation. (:pr:`522`)" +msgstr "" + +#: ../source/news.rst:94 +msgid "May 2018" +msgstr "" + +#: ../source/news.rst:96 +msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" +msgstr "" + +#: ../source/news.rst:97 +msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" +msgstr "" + +#: ../source/news.rst:98 +msgid "Simplified packaging tutorial. (:pr:`498`)" +msgstr "" + +#: ../source/news.rst:99 +msgid "Updated Windows users instructions for clarity. (:pr:`493`)" +msgstr "" + +#: ../source/news.rst:100 +msgid "Updated the license section description for completeness. (:pr:`492`)" +msgstr "" + +#: ../source/news.rst:101 +msgid "Added specification-style document to contributing section. (:pr:`489`)" +msgstr "" + +#: ../source/news.rst:102 +msgid "Added documentation types to contributing guide. (:pr:`485`)" +msgstr "" + +#: ../source/news.rst:105 +msgid "April 2018" +msgstr "" + +#: ../source/news.rst:107 +msgid "Added README guide. (:pr:`461`)" +msgstr "" + +#: ../source/news.rst:108 +msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" +msgstr "" + +#: ../source/news.rst:109 +msgid "Added instructions for Warehouse. (:pr:`471`)" +msgstr "" + +#: ../source/news.rst:110 +msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" +msgstr "" + +#: ../source/news.rst:111 +msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" +msgstr "" + +#: ../source/news.rst:112 +msgid "Added a guide for phasing out Python versions. (:pr:`459`)" +msgstr "" + +#: ../source/news.rst:113 +msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" +msgstr "" + +#: ../source/news.rst:116 +msgid "March 2018" +msgstr "" + +#: ../source/news.rst:118 +msgid "Updated \"installing scientific packages\". (:pr:`455`)" +msgstr "" + +#: ../source/news.rst:119 +msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" +msgstr "" + +#: ../source/news.rst:120 +msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" +msgstr "" + +#: ../source/news.rst:121 +msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" +msgstr "" + +#: ../source/news.rst:124 +msgid "February 2018" +msgstr "" + +#: ../source/news.rst:126 +msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" +msgstr "" + +#: ../source/news.rst:127 +msgid "Updated PyPI migration info. (:pr:`439`)" +msgstr "" + +#: ../source/news.rst:128 +msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" +msgstr "" + +#: ../source/news.rst:129 +msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" +msgstr "" + +#: ../source/news.rst:130 +msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" +msgstr "" + +#: ../source/news.rst:133 +msgid "January 2018" +msgstr "" + +#: ../source/news.rst:135 +msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" +msgstr "" + +#: ../source/news.rst:136 +msgid "Updated README.rst explanation. (:pr:`419`)" +msgstr "" + +#: ../source/news.rst:139 +msgid "December 2017" +msgstr "" + +#: ../source/news.rst:141 +msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" +msgstr "" + +#: ../source/news.rst:142 +msgid "Noted which fields can be used with environment markers. (:pr:`416`)" +msgstr "" + +#: ../source/news.rst:143 +msgid "Updated Requires-Python section. (:pr:`414`)" +msgstr "" + +#: ../source/news.rst:144 +msgid "Added news page. (:pr:`404`)" +msgstr "" + +#: ../source/news.rst:147 +msgid "November 2017" +msgstr "" + +#: ../source/news.rst:149 +msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" +msgstr "" + +#: ../source/news.rst:150 +msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" +msgstr "" + +#: ../source/news.rst:152 +msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:153 +msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" +msgstr "" + +#: ../source/news.rst:156 +msgid "October 2017" +msgstr "" + +#: ../source/news.rst:158 +msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:159 +msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" +msgstr "" + +#: ../source/news.rst:160 +msgid "Split the specifications page into multiple pages. (:pr:`386`)" +msgstr "" + +#: ../source/news.rst:163 +msgid "September 2017" +msgstr "" + +#: ../source/news.rst:165 +msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" +msgstr "" + +#: ../source/news.rst:167 +msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" +msgstr "" + +#: ../source/news.rst:170 +msgid "August 2017" +msgstr "" + +#: ../source/news.rst:172 +msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" +msgstr "" + +#: ../source/news.rst:173 +msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" +msgstr "" + +#: ../source/news.rst:174 +msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" +msgstr "" + +#: ../source/news.rst:177 +msgid "July 2017" +msgstr "" + +#: ../source/news.rst:179 +msgid "Added ``flit`` to the key projects list. (:pr:`358`)" +msgstr "" + +#: ../source/news.rst:180 +msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" +msgstr "" + +#: ../source/news.rst:181 +msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" +msgstr "" + +#: ../source/news.rst:182 +msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" +msgstr "" + +#: ../source/news.rst:183 +msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" +msgstr "" + +#: ../source/news.rst:186 +msgid "June 2017" +msgstr "" + +#: ../source/news.rst:188 +msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" +msgstr "" + +#: ../source/news.rst:189 +msgid "Added documentation for ``python_requires``. (:pr:`338`)" +msgstr "" + +#: ../source/news.rst:190 +msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" +msgstr "" + +#: ../source/news.rst:191 +msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" +msgstr "" + +#: ../source/news.rst:192 +msgid "Added a license section to the distributing guide. (:pr:`331`)" +msgstr "" + +#: ../source/news.rst:193 +msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" +msgstr "" + +#: ../source/news.rst:194 +msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" +msgstr "" + +#: ../source/news.rst:195 +msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" +msgstr "" + +#: ../source/news.rst:196 +msgid "Switched to the PyPA theme. (:pr:`305`)" +msgstr "" + +#: ../source/news.rst:197 +msgid "Re-organized the documentation into the new structure. (:pr:`318`)" +msgstr "" + +#: ../source/news.rst:200 +msgid "May 2017" +msgstr "" + +#: ../source/news.rst:202 +msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" +msgstr "" + +#: ../source/news.rst:203 +msgid "Added contributor and style guide. (:pr:`307`)" +msgstr "" + +#: ../source/news.rst:204 +msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" +msgstr "" + +#: ../source/news.rst:207 +msgid "April 2017" +msgstr "" + +#: ../source/news.rst:209 +msgid "Added travis configuration for testing pull requests. (:pr:`300`)" +msgstr "" + +#: ../source/news.rst:210 +msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" +msgstr "" + +#: ../source/news.rst:211 +msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" +msgstr "" + +#: ../source/news.rst:212 +msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" +msgstr "" + +#: ../source/news.rst:213 +msgid "Added a topic on namespace packages. (:pr:`290`)" +msgstr "" + +#: ../source/news.rst:214 +msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" +msgstr "" + +#: ../source/news.rst:215 +msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" +msgstr "" + +#: ../source/news.rst:216 +msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" +msgstr "" + +#: ../source/news.rst:217 +msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" +msgstr "" + +#: ../source/news.rst:219 +msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" +msgstr "" + +#: ../source/news.rst:223 +msgid "March 2017" +msgstr "" + +#: ../source/news.rst:225 +msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" +msgstr "" + +#: ../source/news.rst:228 +msgid "February 2017" +msgstr "" + +#: ../source/news.rst:230 +msgid "Added :pep:`518`. (:pr:`281`)" +msgstr "" + +#: ../source/overview.rst:3 +msgid "An Overview of Packaging for Python" +msgstr "" + +#: ../source/overview.rst:7 +msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." +msgstr "" + +#: ../source/overview.rst:12 +msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." +msgstr "" + +#: ../source/overview.rst:18 +msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." +msgstr "" + +#: ../source/overview.rst:26 +msgid "Thinking about deployment" +msgstr "" + +#: ../source/overview.rst:28 +msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" +msgstr "" + +#: ../source/overview.rst:32 +msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" +msgstr "" + +#: ../source/overview.rst:35 +msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" +msgstr "" + +#: ../source/overview.rst:37 +msgid "Is your software installed individually, or in large deployment batches?" +msgstr "" + +#: ../source/overview.rst:39 +msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." +msgstr "" + +#: ../source/overview.rst:46 +msgid "Packaging Python libraries and tools" +msgstr "" + +#: ../source/overview.rst:48 +msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/overview.rst:53 +msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." +msgstr "" + +#: ../source/overview.rst:59 +msgid "Python modules" +msgstr "" + +#: ../source/overview.rst:61 +msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." +msgstr "" + +#: ../source/overview.rst:66 +msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." +msgstr "" + +#: ../source/overview.rst:73 +msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." +msgstr "" + +#: ../source/overview.rst:78 +msgid "Python source distributions" +msgstr "" + +#: ../source/overview.rst:80 +msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." +msgstr "" + +#: ../source/overview.rst:84 +msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." +msgstr "" + +#: ../source/overview.rst:90 +msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." +msgstr "" + +#: ../source/overview.rst:95 +msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." +msgstr "" + +#: ../source/overview.rst:100 +msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." +msgstr "" + +#: ../source/overview.rst:107 +msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" +msgstr "" + +#: ../source/overview.rst:114 +msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." +msgstr "" + +#: ../source/overview.rst:119 +msgid "Python binary distributions" +msgstr "" + +#: ../source/overview.rst:121 +msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." +msgstr "" + +#: ../source/overview.rst:125 +msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." +msgstr "" + +#: ../source/overview.rst:132 +msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." +msgstr "" + +#: ../source/overview.rst:140 +msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." +msgstr "" + +#: ../source/overview.rst:148 +msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." +msgstr "" + +#: ../source/overview.rst:155 +msgid "Packaging Python applications" +msgstr "" + +#: ../source/overview.rst:157 +msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." +msgstr "" + +#: ../source/overview.rst:162 +msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." +msgstr "" + +#: ../source/overview.rst:166 +msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." +msgstr "" + +#: ../source/overview.rst:172 +msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." +msgstr "" + +#: ../source/overview.rst:176 +msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." +msgstr "" + +#: ../source/overview.rst:181 +msgid "Depending on a framework" +msgstr "" + +#: ../source/overview.rst:183 +msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." +msgstr "" + +#: ../source/overview.rst:189 +msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." +msgstr "" + +#: ../source/overview.rst:195 +msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." +msgstr "" + +#: ../source/overview.rst:199 +msgid "Service platforms" +msgstr "" + +#: ../source/overview.rst:201 +msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." +msgstr "" + +#: ../source/overview.rst:205 +msgid "`Heroku `_" +msgstr "" + +#: ../source/overview.rst:206 +msgid "`Google App Engine `_" +msgstr "" + +#: ../source/overview.rst:207 +msgid "`PythonAnywhere `_" +msgstr "" + +#: ../source/overview.rst:208 +msgid "`OpenShift `_" +msgstr "" + +#: ../source/overview.rst:209 +msgid "\"Serverless\" frameworks like `Zappa `_" +msgstr "" + +#: ../source/overview.rst:211 +msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." +msgstr "" + +#: ../source/overview.rst:216 +msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." +msgstr "" + +#: ../source/overview.rst:220 +msgid "Web browsers and mobile applications" +msgstr "" + +#: ../source/overview.rst:222 +msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." +msgstr "" + +#: ../source/overview.rst:227 +msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" +msgstr "" + +#: ../source/overview.rst:231 +msgid "`Kivy `_" +msgstr "" + +#: ../source/overview.rst:232 +msgid "`Beeware `_" +msgstr "" + +#: ../source/overview.rst:233 +msgid "`Brython `_" +msgstr "" + +#: ../source/overview.rst:234 +msgid "`Flexx `_" +msgstr "" + +#: ../source/overview.rst:236 +msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." +msgstr "" + +#: ../source/overview.rst:241 +msgid "Depending on a pre-installed Python" +msgstr "" + +#: ../source/overview.rst:243 +msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." +msgstr "" + +#: ../source/overview.rst:249 +msgid "Technologies which support this model:" +msgstr "" + +#: ../source/overview.rst:251 +msgid "`PEX `_ (Python EXecutable)" +msgstr "" + +#: ../source/overview.rst:252 +msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" +msgstr "" + +#: ../source/overview.rst:253 +msgid "`shiv `_ (requires Python 3)" +msgstr "" + +#: ../source/overview.rst:255 +msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." +msgstr "" + +#: ../source/overview.rst:260 +msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." +msgstr "" + +#: ../source/overview.rst:267 +msgid "Depending on a separate software distribution ecosystem" +msgstr "" + +#: ../source/overview.rst:269 +msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." +msgstr "" + +#: ../source/overview.rst:274 +msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." +msgstr "" + +#: ../source/overview.rst:284 +msgid "Instructions on building and publishing for the Anaconda ecosystem:" +msgstr "" + +#: ../source/overview.rst:286 +msgid "`Building libraries and applications with conda `_" +msgstr "" + +#: ../source/overview.rst:287 +msgid "`Transitioning a native Python package to Anaconda `_" +msgstr "" + +#: ../source/overview.rst:289 +msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" +msgstr "" + +#: ../source/overview.rst:293 +msgid "`Enthought Canopy `_" +msgstr "" + +#: ../source/overview.rst:294 +msgid "`ActiveState ActivePython `_" +msgstr "" + +#: ../source/overview.rst:295 +msgid "`WinPython `_" +msgstr "" + +#: ../source/overview.rst:300 +msgid "Bringing your own Python executable" +msgstr "" + +#: ../source/overview.rst:302 +msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." +msgstr "" + +#: ../source/overview.rst:306 +msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." +msgstr "" + +#: ../source/overview.rst:311 +msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." +msgstr "" + +#: ../source/overview.rst:315 +msgid "A selection of Python freezers:" +msgstr "" + +#: ../source/overview.rst:317 +msgid "`pyInstaller `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:318 +msgid "`cx_Freeze `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:319 +msgid "`constructor `_ - For command-line installers" +msgstr "" + +#: ../source/overview.rst:320 +msgid "`py2exe `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:321 +msgid "`py2app `_ - Mac only" +msgstr "" + +#: ../source/overview.rst:322 +msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" +msgstr "" + +#: ../source/overview.rst:323 +msgid "`osnap `_ - Windows and Mac" +msgstr "" + +#: ../source/overview.rst:324 +msgid "`pynsist `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:326 +msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." +msgstr "" + +#: ../source/overview.rst:332 +msgid "Bringing your own userspace" +msgstr "" + +#: ../source/overview.rst:334 +msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." +msgstr "" + +#: ../source/overview.rst:341 +msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." +msgstr "" + +#: ../source/overview.rst:344 +msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" +msgstr "" + +#: ../source/overview.rst:347 +msgid "`AppImage `_" +msgstr "" + +#: ../source/overview.rst:348 +msgid "`Docker `_" +msgstr "" + +#: ../source/overview.rst:349 +msgid "`Flatpak `_" +msgstr "" + +#: ../source/overview.rst:350 +msgid "`Snapcraft `_" +msgstr "" + +#: ../source/overview.rst:353 +msgid "Bringing your own kernel" +msgstr "" + +#: ../source/overview.rst:355 +msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." +msgstr "" + +#: ../source/overview.rst:360 +msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" +msgstr "" + +#: ../source/overview.rst:364 +msgid "`Vagrant `_" +msgstr "" + +#: ../source/overview.rst:365 +msgid "`VHD `_, `AMI `_, and `other formats `_" +msgstr "" + +#: ../source/overview.rst:366 +msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" +msgstr "" + +#: ../source/overview.rst:369 +msgid "Bringing your own hardware" +msgstr "" + +#: ../source/overview.rst:371 +msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." +msgstr "" + +#: ../source/overview.rst:375 +msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." +msgstr "" + +#: ../source/overview.rst:379 +msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." +msgstr "" + +#: ../source/overview.rst:389 +msgid "The simplified gamut of technologies used to package Python applications." +msgstr "" + +#: ../source/overview.rst:392 +msgid "What about..." +msgstr "" + +#: ../source/overview.rst:394 +msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." +msgstr "" + +#: ../source/overview.rst:398 +msgid "Operating system packages" +msgstr "" + +#: ../source/overview.rst:400 +msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." +msgstr "" + +#: ../source/overview.rst:411 +msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." +msgstr "" + +#: ../source/overview.rst:417 +msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." +msgstr "" + +#: ../source/overview.rst:427 +msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." +msgstr "" + +#: ../source/overview.rst:432 +msgid "Security" +msgstr "Sekureco" + +#: ../source/overview.rst:434 +msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." +msgstr "" + +#: ../source/overview.rst:437 +msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." +msgstr "" + +#: ../source/overview.rst:446 +msgid "Wrap up" +msgstr "" + +#: ../source/overview.rst:448 +msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:6 +msgid "Binary distribution format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:8 +msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:13 +msgid "Abstract" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:15 +msgid "This PEP describes a built-package format for Python called \"wheel\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:17 +msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:27 +msgid "PEP Acceptance" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:29 +msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:34 +msgid "Rationale" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:36 +msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:43 +msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:52 +msgid "Details" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:55 +msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:57 +msgid "Wheel installation notionally consists of two phases:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:59 +msgid "Unpack." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:61 +msgid "Parse ``distribution-1.0.dist-info/WHEEL``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:62 +msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:64 +msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:66 +msgid "Else unpack archive into platlib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:68 +msgid "Spread." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:70 +msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:72 +msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:78 +msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:80 +msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:82 +msgid "Remove empty ``distribution-1.0.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:83 +msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:87 +msgid "Recommended installer features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:97 +msgid "Rewrite ``#!python``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:90 +msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:96 +msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:102 +msgid "Generate script wrappers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:100 +msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:105 +msgid "Recommended archiver features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:112 +msgid "Place ``.dist-info`` at the end of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:108 +msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:115 +msgid "File Format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:118 +msgid "File name convention" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:120 +msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "distribution" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "Distribution name, e.g. 'django', 'pyramid'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "Distribution version, e.g. 1.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:135 +msgid "build tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:130 +msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "language implementation and version tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "E.g. 'py27', 'py2', 'py3'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "abi tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "E.g. 'cp33m', 'abi3', 'none'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "platform tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "E.g. 'linux_x86_64', 'any'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:146 +msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:151 +msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:156 +msgid "Escaping and Unicode" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:158 +msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:161 +msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:164 +msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:166 +msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:169 +msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:172 +msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:176 +msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:182 +msgid "File contents" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:184 +msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:188 +msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:191 +msgid "``{distribution}-{version}.dist-info/`` contains metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:192 +msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:196 +msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:200 +msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:202 +msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:212 +msgid "``Wheel-Version`` is the version number of the Wheel specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:213 +msgid "``Generator`` is the name and optionally the version of the software that produced the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:215 +msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:218 +msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:220 +msgid "``Build`` is the build number and is omitted if there is no build number." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:221 +msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:224 +msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:226 +msgid "Wheel does not contain setup.py or setup.cfg." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:228 +msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:235 +#: ../source/specifications/recording-installed-packages.rst:35 +msgid "The .dist-info directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:237 +msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:239 +msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:241 +msgid "WHEEL is the wheel metadata specific to a build of the package." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:242 +msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:248 +msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:249 +msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:251 +msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:254 +msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:261 +msgid "The .data directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:263 +msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:271 +msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:277 +msgid "Signed wheel files" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:279 +msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:290 +msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:295 +msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:302 +msgid "(The hash value is the same format used in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:304 +msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:307 +msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:312 +msgid "See" +msgstr "Vidu" + +#: ../source/specifications/binary-distribution-format.rst:314 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" +msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" + +#: ../source/specifications/binary-distribution-format.rst:315 +msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" +msgstr "" +"http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" + +#: ../source/specifications/binary-distribution-format.rst:316 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" +msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" + +#: ../source/specifications/binary-distribution-format.rst:317 +msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" +msgstr "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" + +#: ../source/specifications/binary-distribution-format.rst:321 +msgid "Comparison to .egg" +msgstr "Komparo al .egg" + +#: ../source/specifications/binary-distribution-format.rst:323 +msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:328 +msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:331 +msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:337 +msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:341 +msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:344 +msgid "Wheel is a reference to the other Python." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:348 +msgid "FAQ" +msgstr "Oftaj demandoj" + +#: ../source/specifications/binary-distribution-format.rst:352 +msgid "Wheel defines a .data directory. Should I put all my data there?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:354 +msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:363 +msgid "Why does wheel include attached signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:365 +msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:373 +msgid "Why does wheel allow JWS signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:375 +msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:381 +msgid "Why does wheel also allow S/MIME signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:383 +msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:386 +msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:391 +msgid "What's the deal with \"purelib\" vs. \"platlib\"?" +msgstr "Kio temas pri «purelib» kontraste kun «platlib»?" + +#: ../source/specifications/binary-distribution-format.rst:393 +msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:398 +msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:403 +msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:409 +msgid "Is it possible to import Python code directly from a wheel file?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:411 +msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:417 +msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:426 +msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:443 +msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:450 +msgid "Changes" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:452 +msgid "Since :pep:`427`, this specification has changed as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:454 +msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:461 +msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:466 +msgid "Appendix" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:468 +msgid "Example urlsafe-base64-nopad implementation::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:482 +msgid "Copyright" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:484 +msgid "This document has been placed into the public domain." +msgstr "" + +#: ../source/specifications/core-metadata.rst:5 +msgid "Core metadata specifications" +msgstr "" + +#: ../source/specifications/core-metadata.rst:7 +msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:10 +msgid "``Metadata-Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:11 +msgid "``Name``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:12 +msgid "``Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:14 +msgid "All the other fields are optional." +msgstr "" + +#: ../source/specifications/core-metadata.rst:16 +msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." +msgstr "" + +#: ../source/specifications/core-metadata.rst:25 +msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:30 +msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." +msgstr "" + +#: ../source/specifications/core-metadata.rst:41 +msgid "Metadata-Version" +msgstr "" + +#: ../source/specifications/core-metadata.rst:45 +msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." +msgstr "" + +#: ../source/specifications/core-metadata.rst:48 +msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:54 +msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." +msgstr "" + +#: ../source/specifications/core-metadata.rst:58 +#: ../source/specifications/core-metadata.rst:80 +#: ../source/specifications/core-metadata.rst:95 +#: ../source/specifications/core-metadata.rst:155 +#: ../source/specifications/core-metadata.rst:170 +#: ../source/specifications/core-metadata.rst:208 +#: ../source/specifications/core-metadata.rst:283 +#: ../source/specifications/core-metadata.rst:287 +#: ../source/specifications/core-metadata.rst:291 +#: ../source/specifications/core-metadata.rst:295 +#: ../source/specifications/core-metadata.rst:327 +#: ../source/specifications/core-metadata.rst:347 +#: ../source/specifications/core-metadata.rst:373 +#: ../source/specifications/core-metadata.rst:391 +#: ../source/specifications/core-metadata.rst:416 +#: ../source/specifications/core-metadata.rst:438 +#: ../source/specifications/core-metadata.rst:600 +#: ../source/specifications/core-metadata.rst:620 +#: ../source/specifications/core-metadata.rst:630 +msgid "Example::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:66 +msgid "Name" +msgstr "Nomo" + +#: ../source/specifications/core-metadata.rst:69 +msgid "Added additional restrictions on format from :pep:`508`" +msgstr "" + +#: ../source/specifications/core-metadata.rst:72 +msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:88 +msgid "Version" +msgstr "Versio" + +#: ../source/specifications/core-metadata.rst:92 +msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:101 +msgid "Dynamic (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:105 +msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." +msgstr "" + +#: ../source/specifications/core-metadata.rst:108 +msgid "When found in the metadata of a source distribution, the following rules apply:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:111 +msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." +msgstr "" + +#: ../source/specifications/core-metadata.rst:115 +msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:118 +msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:122 +msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." +msgstr "" + +#: ../source/specifications/core-metadata.rst:127 +msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:131 +msgid "Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:135 +msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." +msgstr "" + +#: ../source/specifications/core-metadata.rst:146 +msgid "Supported-Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:150 +msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." +msgstr "" + +#: ../source/specifications/core-metadata.rst:164 +msgid "Summary" +msgstr "" + +#: ../source/specifications/core-metadata.rst:168 +msgid "A one-line summary of what the distribution does." +msgstr "" + +#: ../source/specifications/core-metadata.rst:188 +msgid "This field may be specified in the message body instead." +msgstr "" + +#: ../source/specifications/core-metadata.rst:191 +msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:196 +msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." +msgstr "" + +#: ../source/specifications/core-metadata.rst:202 +msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:219 +msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." +msgstr "" + +#: ../source/specifications/core-metadata.rst:223 +msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:232 +msgid "Description-Content-Type" +msgstr "" + +#: ../source/specifications/core-metadata.rst:236 +msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:239 +msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." +msgstr "" + +#: ../source/specifications/core-metadata.rst:253 +msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:259 +msgid "Format::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:263 +msgid "The ``type/subtype`` part has only a few legal values:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:265 +msgid "``text/plain``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:266 +msgid "``text/x-rst``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:267 +msgid "``text/markdown``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:269 +msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:273 +msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:278 +msgid "``GFM`` for `Github-flavored Markdown `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:280 +msgid "``CommonMark`` for `CommonMark `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:299 +msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." +msgstr "" + +#: ../source/specifications/core-metadata.rst:303 +msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:307 +msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:311 +msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." +msgstr "" + +#: ../source/specifications/core-metadata.rst:320 +msgid "Keywords" +msgstr "" + +#: ../source/specifications/core-metadata.rst:324 +msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." +msgstr "" + +#: ../source/specifications/core-metadata.rst:333 +msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." +msgstr "" + +#: ../source/specifications/core-metadata.rst:341 +msgid "Home-page" +msgstr "" + +#: ../source/specifications/core-metadata.rst:345 +msgid "A string containing the URL for the distribution's home page." +msgstr "" + +#: ../source/specifications/core-metadata.rst:353 +msgid "Download-URL" +msgstr "" + +#: ../source/specifications/core-metadata.rst:357 +msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:366 +msgid "Author" +msgstr "" + +#: ../source/specifications/core-metadata.rst:370 +msgid "A string containing the author's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:383 +msgid "Author-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:387 +msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:395 +#: ../source/specifications/core-metadata.rst:442 +msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:405 +msgid "Maintainer" +msgstr "Prizorganto" + +#: ../source/specifications/core-metadata.rst:409 +msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:412 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:426 +msgid "Maintainer-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:430 +msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:434 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:452 +msgid "License" +msgstr "" + +#: ../source/specifications/core-metadata.rst:456 +msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." +msgstr "" + +#: ../source/specifications/core-metadata.rst:476 +msgid "Classifier (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:480 +msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:485 +#: ../source/specifications/core-metadata.rst:574 +#: ../source/specifications/core-metadata.rst:691 +#: ../source/specifications/core-metadata.rst:715 +msgid "This field may be followed by an environment marker after a semicolon." +msgstr "" + +#: ../source/specifications/core-metadata.rst:496 +msgid "Requires-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:499 +#: ../source/specifications/core-metadata.rst:561 +#: ../source/specifications/core-metadata.rst:663 +#: ../source/specifications/core-metadata.rst:704 +msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." +msgstr "" + +#: ../source/specifications/core-metadata.rst:503 +msgid "Each entry contains a string naming some other distutils project required by this distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:506 +msgid "The format of a requirement string contains from one to four parts:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:508 +msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." +msgstr "" + +#: ../source/specifications/core-metadata.rst:510 +msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." +msgstr "" + +#: ../source/specifications/core-metadata.rst:513 +msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:516 +msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." +msgstr "" + +#: ../source/specifications/core-metadata.rst:519 +msgid "See :pep:`508` for full details of the allowed format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:521 +msgid "The project names should correspond to names as found on the `Python Package Index`_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:524 +msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:538 +msgid "Requires-Python" +msgstr "" + +#: ../source/specifications/core-metadata.rst:542 +msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." +msgstr "" + +#: ../source/specifications/core-metadata.rst:546 +msgid "The value must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:548 +msgid "This field cannot be followed by an environment marker." +msgstr "" + +#: ../source/specifications/core-metadata.rst:558 +msgid "Requires-External (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:565 +msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:570 +msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:576 +msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." +msgstr "" + +#: ../source/specifications/core-metadata.rst:581 +msgid "Notice that there is no particular rule on the strings to be used." +msgstr "" + +#: ../source/specifications/core-metadata.rst:593 +msgid "Project-URL (multiple-use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:597 +msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." +msgstr "" + +#: ../source/specifications/core-metadata.rst:604 +msgid "The label is free text limited to 32 characters." +msgstr "" + +#: ../source/specifications/core-metadata.rst:612 +msgid "Provides-Extra (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:616 +msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." +msgstr "" + +#: ../source/specifications/core-metadata.rst:625 +msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:635 +msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." +msgstr "" + +#: ../source/specifications/core-metadata.rst:639 +msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:644 +msgid "Rarely Used Fields" +msgstr "" + +#: ../source/specifications/core-metadata.rst:646 +msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:651 +msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." +msgstr "" + +#: ../source/specifications/core-metadata.rst:660 +msgid "Provides-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:667 +msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:672 +msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:679 +msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:687 +msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." +msgstr "" + +#: ../source/specifications/core-metadata.rst:701 +msgid "Obsoletes-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:708 +msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." +msgstr "" + +#: ../source/specifications/core-metadata.rst:712 +msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:717 +msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:730 +msgid "reStructuredText markup: http://docutils.sourceforge.net/" +msgstr "" + +#: ../source/specifications/core-metadata.rst:735 +msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:6 +msgid "Declaring build system dependencies" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:8 +msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:5 +msgid "Declaring project metadata" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:7 +msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:12 +msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:18 +msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:27 +msgid "The only fields required to be statically defined are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:29 +#: ../source/specifications/declaring-project-metadata.rst:41 +msgid "``name``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:31 +msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:34 +#: ../source/specifications/declaring-project-metadata.rst:54 +msgid "``version``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:36 +msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:43 +#: ../source/specifications/declaring-project-metadata.rst:56 +#: ../source/specifications/declaring-project-metadata.rst:68 +#: ../source/specifications/declaring-project-metadata.rst:117 +msgid "TOML_ type: string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:44 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:47 +msgid "The name of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:49 +msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:57 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:60 +msgid "The version of the project as supported by :pep:`440`." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:62 +msgid "Users SHOULD prefer to specify already-normalized versions." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:66 +msgid "``description``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:69 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:72 +msgid "The summary description of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:76 +msgid "``readme``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:78 +msgid "TOML_ type: string or table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:79 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:83 +msgid "The full description of the project (i.e. the README)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:85 +msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:96 +msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:103 +msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:115 +msgid "``requires-python``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:118 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:121 +msgid "The Python version requirements of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:125 +msgid "``license``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:127 +msgid "TOML_ type: table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:128 +msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:131 +msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:140 +msgid "``authors``/``maintainers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:142 +msgid "TOML_ type: Array of inline tables with string keys and values" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:143 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:149 +msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:154 +msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:157 +msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:163 +msgid "Using the data to fill in :ref:`core metadata ` is as follows:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:166 +msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:169 +msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:173 +msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:177 +msgid "Multiple values should be separated by commas." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:181 +msgid "``keywords``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:183 +#: ../source/specifications/declaring-project-metadata.rst:193 +msgid "TOML_ type: array of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:184 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:187 +msgid "The keywords for the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:191 +msgid "``classifiers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:194 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:197 +msgid "Trove classifiers which apply to the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:201 +msgid "``urls``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:203 +msgid "TOML_ type: table with keys and values of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:204 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:207 +msgid "A table of URLs where the key is the URL label and the value is the URL itself." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:212 +msgid "Entry points" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:214 +msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:216 +msgid ":ref:`Entry points specification `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:218 +msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:224 +msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:228 +msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:234 +msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:242 +msgid "``dependencies``/``optional-dependencies``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:244 +msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:247 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:251 +msgid "The (optional) dependencies of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:253 +msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:258 +msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:269 +msgid "``dynamic``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:271 +msgid "TOML_ type: array of string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:272 +msgid "A corresponding :ref:`core metadata ` field does not exist" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:275 +msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:281 +msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:283 +msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:285 +msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:290 +msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:294 +msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:296 +msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:300 +msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:6 +msgid "Dependency specifiers" +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:8 +msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:11 +msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." +msgstr "" + +#: ../source/specifications/direct-url.rst:6 +msgid "Recording the Direct URL Origin of installed distributions" +msgstr "" + +#: ../source/specifications/direct-url.rst:8 +msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." +msgstr "" + +#: ../source/specifications/direct-url.rst:17 +msgid "Specification" +msgstr "" + +#: ../source/specifications/direct-url.rst:19 +msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/direct-url.rst:23 +#: ../source/specifications/recording-installed-packages.rst:206 +msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." +msgstr "" + +#: ../source/specifications/direct-url.rst:26 +msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." +msgstr "" + +#: ../source/specifications/direct-url.rst:29 +msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." +msgstr "" + +#: ../source/specifications/direct-url.rst:36 +msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." +msgstr "" + +#: ../source/specifications/direct-url.rst:39 +msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" +msgstr "" + +#: ../source/specifications/direct-url.rst:45 +msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." +msgstr "" + +#: ../source/specifications/direct-url.rst:49 +msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" +msgstr "" + +#: ../source/specifications/direct-url.rst:52 +msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." +msgstr "" + +#: ../source/specifications/direct-url.rst:58 +msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." +msgstr "" + +#: ../source/specifications/direct-url.rst:61 +msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." +msgstr "" + +#: ../source/specifications/direct-url.rst:68 +msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:71 +msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." +msgstr "" + +#: ../source/specifications/direct-url.rst:78 +msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:81 +msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." +msgstr "" + +#: ../source/specifications/direct-url.rst:84 +msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." +msgstr "" + +#: ../source/specifications/direct-url.rst:91 +msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." +msgstr "" + +#: ../source/specifications/direct-url.rst:96 +msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." +msgstr "" + +#: ../source/specifications/direct-url.rst:102 +msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." +msgstr "" + +#: ../source/specifications/direct-url.rst:110 +msgid "Registered VCS" +msgstr "" + +#: ../source/specifications/direct-url.rst:112 +msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." +msgstr "" + +#: ../source/specifications/direct-url.rst:122 +msgid "Git" +msgstr "" + +#: ../source/specifications/direct-url.rst:124 +#: ../source/specifications/direct-url.rst:156 +#: ../source/specifications/direct-url.rst:179 +#: ../source/specifications/direct-url.rst:202 +msgid "Home page" +msgstr "" + +#: ../source/specifications/direct-url.rst:126 +msgid "https://git-scm.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:128 +#: ../source/specifications/direct-url.rst:160 +#: ../source/specifications/direct-url.rst:183 +#: ../source/specifications/direct-url.rst:206 +msgid "vcs command" +msgstr "" + +#: ../source/specifications/direct-url.rst:130 +#: ../source/specifications/direct-url.rst:134 +msgid "git" +msgstr "" + +#: ../source/specifications/direct-url.rst:132 +#: ../source/specifications/direct-url.rst:164 +#: ../source/specifications/direct-url.rst:187 +#: ../source/specifications/direct-url.rst:210 +msgid "``vcs`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:136 +#: ../source/specifications/direct-url.rst:168 +#: ../source/specifications/direct-url.rst:191 +#: ../source/specifications/direct-url.rst:214 +msgid "``requested_revision`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:138 +msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." +msgstr "" + +#: ../source/specifications/direct-url.rst:141 +#: ../source/specifications/direct-url.rst:172 +#: ../source/specifications/direct-url.rst:195 +#: ../source/specifications/direct-url.rst:219 +msgid "``commit_id`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:143 +msgid "A commit hash (40 hexadecimal characters sha1)." +msgstr "" + +#: ../source/specifications/direct-url.rst:147 +msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." +msgstr "" + +#: ../source/specifications/direct-url.rst:154 +msgid "Mercurial" +msgstr "" + +#: ../source/specifications/direct-url.rst:158 +msgid "https://www.mercurial-scm.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:162 +#: ../source/specifications/direct-url.rst:166 +msgid "hg" +msgstr "" + +#: ../source/specifications/direct-url.rst:170 +msgid "A tag name, branch name, changeset ID, shortened changeset ID." +msgstr "" + +#: ../source/specifications/direct-url.rst:174 +msgid "A changeset ID (40 hexadecimal characters)." +msgstr "" + +#: ../source/specifications/direct-url.rst:177 +msgid "Bazaar" +msgstr "" + +#: ../source/specifications/direct-url.rst:181 +msgid "https://bazaar.canonical.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:185 +#: ../source/specifications/direct-url.rst:189 +msgid "bzr" +msgstr "" + +#: ../source/specifications/direct-url.rst:193 +msgid "A tag name, branch name, revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:197 +msgid "A revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:200 +msgid "Subversion" +msgstr "" + +#: ../source/specifications/direct-url.rst:204 +msgid "https://subversion.apache.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:208 +#: ../source/specifications/direct-url.rst:212 +msgid "svn" +msgstr "" + +#: ../source/specifications/direct-url.rst:216 +msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." +msgstr "" + +#: ../source/specifications/direct-url.rst:221 +msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." +msgstr "" + +#: ../source/specifications/direct-url.rst:229 +msgid "Example direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:231 +msgid "Source archive:" +msgstr "" + +#: ../source/specifications/direct-url.rst:242 +msgid "Git URL with tag and commit-hash:" +msgstr "" + +#: ../source/specifications/direct-url.rst:255 +msgid "Local directory:" +msgstr "" + +#: ../source/specifications/direct-url.rst:264 +msgid "Local directory installed in editable mode:" +msgstr "" + +#: ../source/specifications/direct-url.rst:277 +msgid "Example pip commands and their effect on direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:279 +msgid "Commands that generate a ``direct_url.json``:" +msgstr "" + +#: ../source/specifications/direct-url.rst:281 +msgid "pip install https://example.com/app-1.0.tgz" +msgstr "" + +#: ../source/specifications/direct-url.rst:282 +msgid "pip install https://example.com/app-1.0.whl" +msgstr "" + +#: ../source/specifications/direct-url.rst:283 +msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" +msgstr "" + +#: ../source/specifications/direct-url.rst:284 +msgid "pip install ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:285 +msgid "pip install file:///home/user/app" +msgstr "" + +#: ../source/specifications/direct-url.rst:286 +msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" +msgstr "" + +#: ../source/specifications/direct-url.rst:290 +msgid "pip install -e ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:292 +msgid "Commands that *do not* generate a ``direct_url.json``" +msgstr "" + +#: ../source/specifications/direct-url.rst:294 +msgid "pip install app" +msgstr "" + +#: ../source/specifications/direct-url.rst:295 +msgid "pip install app --no-index --find-links https://example.com/" +msgstr "" + +#: ../source/specifications/entry-points.rst:5 +msgid "Entry points specification" +msgstr "" + +#: ../source/specifications/entry-points.rst:7 +msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" +msgstr "" + +#: ../source/specifications/entry-points.rst:11 +msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." +msgstr "" + +#: ../source/specifications/entry-points.rst:14 +msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." +msgstr "" + +#: ../source/specifications/entry-points.rst:19 +msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." +msgstr "" + +#: ../source/specifications/entry-points.rst:28 +msgid "Data model" +msgstr "" + +#: ../source/specifications/entry-points.rst:30 +msgid "Conceptually, an entry point is defined by three required properties:" +msgstr "" + +#: ../source/specifications/entry-points.rst:32 +msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:42 +msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:51 +msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:64 +msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." +msgstr "" + +#: ../source/specifications/entry-points.rst:68 +msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." +msgstr "" + +#: ../source/specifications/entry-points.rst:73 +msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." +msgstr "" + +#: ../source/specifications/entry-points.rst:80 +msgid "File format" +msgstr "" + +#: ../source/specifications/entry-points.rst:82 +msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." +msgstr "" + +#: ../source/specifications/entry-points.rst:87 +msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:97 +msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:100 +msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." +msgstr "" + +#: ../source/specifications/entry-points.rst:104 +msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." +msgstr "" + +#: ../source/specifications/entry-points.rst:112 +msgid "For example::" +msgstr "" + +#: ../source/specifications/entry-points.rst:124 +msgid "Use for scripts" +msgstr "" + +#: ../source/specifications/entry-points.rst:126 +msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." +msgstr "" + +#: ../source/specifications/entry-points.rst:134 +msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:141 +msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." +msgstr "" + +#: ../source/specifications/entry-points.rst:149 +msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." +msgstr "" + +#: ../source/specifications/entry-points.rst:154 +msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." +msgstr "" + +#: ../source/specifications/index.rst:4 +msgid "PyPA specifications" +msgstr "" + +#: ../source/specifications/index.rst:6 +msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." +msgstr "" + +#: ../source/specifications/index.rst:13 +msgid "Package Distribution Metadata" +msgstr "" + +#: ../source/specifications/index.rst:30 +msgid "Package Distribution File Formats" +msgstr "" + +#: ../source/specifications/index.rst:40 +msgid "Package Index Interfaces" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:6 +msgid "Platform compatibility tags" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:8 +msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:12 +msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:16 +msgid "Platform tags for Windows" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:18 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:22 +msgid "Platform tags for macOS (Mac OS X)" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:24 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:28 +msgid "Platform tags for common Linux distributions" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:32 +msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:36 +msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:41 +msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:44 +msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:46 +msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:49 +msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:54 +msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:59 +msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:65 +msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:71 +msgid "Manylinux compatibility support" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:74 +msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:76 +msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:79 +msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "Tool" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux1``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2010``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2014``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux_x_y``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=8.1.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=20.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "auditwheel" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=1.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=2.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.3.0`` [#]_" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:90 +msgid "Platform tags for other \\*nix platforms" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:92 +msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:98 +msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" +msgstr "" + +#: ../source/specifications/pypirc.rst:6 +msgid "The :file:`.pypirc` file" +msgstr "" + +#: ../source/specifications/pypirc.rst:8 +msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." +msgstr "" + +#: ../source/specifications/pypirc.rst:13 +msgid "The format (originally defined by the :ref:`distutils` package) is:" +msgstr "" + +#: ../source/specifications/pypirc.rst:32 +msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:35 +msgid "Each section describing a repository defines three fields:" +msgstr "" + +#: ../source/specifications/pypirc.rst:37 +msgid "``repository``: The URL of the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:38 +msgid "``username``: The registered username on the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:39 +msgid "``password``: The password that will used to authenticate the username." +msgstr "" + +#: ../source/specifications/pypirc.rst:43 +msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." +msgstr "" + +#: ../source/specifications/pypirc.rst:47 +msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" +msgstr "" + +#: ../source/specifications/pypirc.rst:57 +msgid "Common configurations" +msgstr "" + +#: ../source/specifications/pypirc.rst:61 +msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." +msgstr "" + +#: ../source/specifications/pypirc.rst:66 +msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" +msgstr "" + +#: ../source/specifications/pypirc.rst:82 +msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." +msgstr "" + +#: ../source/specifications/pypirc.rst:86 +msgid "Using a PyPI token" +msgstr "" + +#: ../source/specifications/pypirc.rst:88 +msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" +msgstr "" + +#: ../source/specifications/pypirc.rst:97 +msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." +msgstr "" + +#: ../source/specifications/pypirc.rst:103 +msgid "Using another package index" +msgstr "" + +#: ../source/specifications/pypirc.rst:105 +msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" +msgstr "" + +#: ../source/specifications/pypirc.rst:132 +msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:5 +msgid "Recording installed projects" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:7 +msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:12 +msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:21 +msgid "History and change workflow" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:23 +msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:29 +msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:37 +msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:41 +msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:50 +msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:60 +msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:69 +msgid "This ``.dist-info`` directory can contain these files, described in detail below:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:72 +msgid "``METADATA``: contains project metadata" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:73 +msgid "``RECORD``: records the list of installed files." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:74 +msgid "``INSTALLER``: records the name of the tool used to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:76 +msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:82 +msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:87 +msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:94 +msgid "The METADATA file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:96 +msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:99 +msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:105 +msgid "The RECORD file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:107 +msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:110 +msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:113 +msgid "field delimiter: ``,`` (comma)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:114 +msgid "quoting char: ``\"`` (straight double quote)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:115 +msgid "line terminator: either ``\\r\\n`` or ``\\n``." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:117 +msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:120 +msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:125 +msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:130 +msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:133 +msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:139 +msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:146 +msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:151 +msgid "Here is an example snippet of a possible ``RECORD`` file::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:170 +msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:177 +msgid "The INSTALLER file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:179 +msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:185 +msgid "The file can be terminated by zero or more ASCII whitespace characters." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:187 +msgid "Here are examples of two possible ``INSTALLER`` files::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:195 +msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:201 +msgid "The direct_url.json file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:203 +msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:209 +msgid "Its detailed specification is at :ref:`direct-url`." +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:6 +msgid "Simple repository API" +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:8 +msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:6 +msgid "Source distribution format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:8 +msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:13 +msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:21 +msgid "Source distributions are also known as *sdists* for short." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:24 +msgid "Source distribution file name" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:26 +msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:31 +msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:35 +msgid "Source distribution file format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:37 +msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:45 +msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:48 +msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:6 +msgid "Version specifiers" +msgstr "" + +#: ../source/specifications/version-specifiers.rst:8 +msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:11 +msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." +msgstr "" + +#: ../source/support.rst:3 +msgid "How to Get Support" +msgstr "" + +#: ../source/support.rst:5 +msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." +msgstr "" + +#: ../source/support.rst:8 +msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:5 +msgid "Creating Documentation" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:7 +msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:13 +msgid "Installing Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:14 +msgid "Use ``pip`` to install Sphinx:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:28 +msgid "For other installation methods, see this `installation guide`_ by Sphinx." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:33 +msgid "Getting Started With Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:35 +msgid "Create a ``docs`` directory inside your project to hold your documentation:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:42 +msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:49 +msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:51 +msgid "You can add some information about your project in ``index.rst``, then build them:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:57 +msgid "For more details on the build process, see this `guide`_ by Read The Docs." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:62 +msgid "Other Sources" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:64 +msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/index.rst:4 +msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:5 +msgid "Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:7 +msgid "This section covers the basics of how to install Python :term:`packages `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:10 +msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:28 +msgid "Requirements for Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:30 +msgid "This section describes the steps to follow before installing other Python packages." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:35 +msgid "Ensure you can run Python from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:37 +msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:53 +msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:57 +msgid "If you're a newcomer and you get an error like this:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:66 +msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:72 +msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:82 +msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:87 +msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:99 +msgid "Ensure you can run pip from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:101 +msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:116 +msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:124 +msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:139 +msgid "If that still doesn't allow you to run ``python -m pip``:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:141 +msgid "Securely Download `get-pip.py `_ [1]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:144 +msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:150 +msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:159 +msgid "Ensure pip, setuptools, and wheel are up to date" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:161 +msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:169 +msgid "Optionally, create a virtual environment" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:171 +msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:188 +msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:195 +msgid "Creating Virtual Environments" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:197 +msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:203 +msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:209 +msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:213 +msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:216 +msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:220 +msgid "Currently, there are two common tools for creating Python virtual environments:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:222 +msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:225 +msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:230 +msgid "The basic usage is like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:232 +msgid "Using `venv`_:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:248 +msgid "Using :ref:`virtualenv`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:264 +msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:266 +msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:271 +msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:281 +msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:288 +msgid "Use pip for Installing" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:290 +msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:297 +msgid "Installing from PyPI" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:299 +msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:307 +msgid "To install the latest version of \"SomeProject\":" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:321 +msgid "To install a specific version:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:335 +msgid "To install greater than or equal to one version and less than another:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:350 +msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:365 +msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:370 +msgid "Source Distributions vs Wheels" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:372 +msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:378 +msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:383 +msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:391 +msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:408 +msgid "Installing to the User Site" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:410 +msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:425 +msgid "For more information see the `User Installs `_ section from the pip docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:429 +msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:432 +msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:440 +msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:446 +msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:462 +msgid "Install a list of requirements specified in a :ref:`Requirements File `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:478 +msgid "Installing from VCS" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:480 +msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:502 +msgid "Installing from other Indexes" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:504 +msgid "Install from an alternate index" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:518 +msgid "Search an additional index during install, in addition to :term:`PyPI `" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:534 +msgid "Installing from a local src tree" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:537 +msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:554 +msgid "You can also install normally from src" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:571 +msgid "Install a particular source archive file." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:585 +msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:605 +msgid "Installing from other sources" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:607 +msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:619 +msgid "Installing Prereleases" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:621 +msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:637 +msgid "Installing Setuptools \"Extras\"" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:639 +msgid "Install `setuptools extras`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:659 +msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:668 +msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:673 +msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:4 +msgid "Managing Application Dependencies" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:6 +msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:9 +msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:13 +msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:17 +msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:24 +msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:30 +msgid "Installing Pipenv" +msgstr "Instali Pipenv" + +#: ../source/tutorials/managing-dependencies.rst:32 +msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:38 +msgid "Use ``pip`` to install Pipenv:" +msgstr "Uzi ``pip`` por instali Pipenv:" + +#: ../source/tutorials/managing-dependencies.rst:54 +msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:65 +msgid "Installing packages for your project" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:67 +msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:76 +msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:112 +msgid "Using installed packages" +msgstr "Uzi instalitajn pakojn" + +#: ../source/tutorials/managing-dependencies.rst:114 +msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:125 +msgid "Then you can run this script using ``pipenv run``:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:131 +msgid "You should get output similar to this:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:137 +msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:143 +#: ../source/tutorials/packaging-projects.rst:594 +msgid "Next steps" +msgstr "Sekvaj paŝoj" + +#: ../source/tutorials/managing-dependencies.rst:145 +msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:148 +msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:151 +msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:160 +msgid "Other Tools for Application Dependency Management" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:162 +msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:166 +msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:172 +msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:175 +msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:177 +msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:2 +msgid "Packaging Python Projects" +msgstr "Paki projektojn de Python" + +#: ../source/tutorials/packaging-projects.rst:4 +msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:10 +msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:18 +msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:35 +msgid "A simple project" +msgstr "Simpla projekto" + +#: ../source/tutorials/packaging-projects.rst:37 +msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:41 +msgid "Create the following file structure locally:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:51 +msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:54 +msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:63 +msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:67 +msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:75 +msgid "Creating the package files" +msgstr "Krei dosierojn de la pakaĵo" + +#: ../source/tutorials/packaging-projects.rst:77 +msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:95 +msgid "Creating a test directory" +msgstr "Krei elprovan dosierujon" + +#: ../source/tutorials/packaging-projects.rst:97 +msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:101 +msgid "Creating pyproject.toml" +msgstr "Krei la dosieron pyproject.toml" + +#: ../source/tutorials/packaging-projects.rst:103 +msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:117 +msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:121 +msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:127 +msgid "See :pep:`517` and :pep:`518` for background and details." +msgstr "Vidu :pep:`517` kaj :pep:`518` por fonaj informoj kaj detaloj." + +#: ../source/tutorials/packaging-projects.rst:131 +msgid "Configuring metadata" +msgstr "Agordi metadatenojn" + +#: ../source/tutorials/packaging-projects.rst:133 +msgid "There are two types of metadata: static and dynamic." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:135 +msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:137 +msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:141 +msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:148 +msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:153 +msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:185 +msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:191 +#: ../source/tutorials/packaging-projects.rst:286 +msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:196 +msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:199 +#: ../source/tutorials/packaging-projects.rst:293 +msgid "``author`` and ``author_email`` are used to identify the author of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:201 +#: ../source/tutorials/packaging-projects.rst:295 +msgid "``description`` is a short, one-sentence summary of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:202 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:206 +#: ../source/tutorials/packaging-projects.rst:300 +msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:208 +#: ../source/tutorials/packaging-projects.rst:302 +msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:211 +#: ../source/tutorials/packaging-projects.rst:305 +msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:213 +#: ../source/tutorials/packaging-projects.rst:307 +msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:221 +msgid "In the ``options`` category, we have controls for setuptools itself:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:223 +msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:227 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:234 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:238 +#: ../source/tutorials/packaging-projects.rst:329 +msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:244 +msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:248 +msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:283 +msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:291 +msgid "``version`` is the package version. See :pep:`440` for more details on versions." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:296 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:314 +msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:319 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:325 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:333 +msgid "Creating README.md" +msgstr "Krei la dosieron README.md" + +#: ../source/tutorials/packaging-projects.rst:335 +msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:347 +msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:354 +msgid "Creating a LICENSE" +msgstr "Krei la dosieron LICENSE" + +#: ../source/tutorials/packaging-projects.rst:356 +msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:387 +msgid "Including other files" +msgstr "Inkluzivi aliajn dosierojn" + +#: ../source/tutorials/packaging-projects.rst:389 +msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:393 +msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:402 +msgid "Generating distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:404 +msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:408 +msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:422 +msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:425 +msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:439 +msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:449 +msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:458 +msgid "Uploading the distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:460 +msgid "Finally, it's time to upload your package to the Python Package Index!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:462 +msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:470 +msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:477 +msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:492 +msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:506 +msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:510 +msgid "After the command completes, you should see output similar to this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:523 +msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:528 +msgid "Installing your newly uploaded package" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:530 +msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:546 +msgid "Make sure to specify your username in the package name!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:548 +msgid "pip should install the package from TestPyPI and the output should look something like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:558 +msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:565 +msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:580 +msgid "and import the package:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:588 +msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:596 +msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:599 +msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:604 +msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:608 +msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:610 +msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:613 +msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:617 +msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:619 +msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:622 +msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:624 +msgid "Read about :doc:`/guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:625 +msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." +msgstr "" From e010a6184667b5628d191cf94819b220a28ec833 Mon Sep 17 00:00:00 2001 From: Alex Solonenko Date: Sun, 29 Aug 2021 18:15:32 +0200 Subject: [PATCH 0081/1072] Translated using Weblate (Ukrainian) Currently translated at 13.2% (302 of 2271 strings) Co-authored-by: Alex Solonenko Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/uk/ Translation: pypa/packaging.python.org --- locales/uk/LC_MESSAGES/messages.po | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/locales/uk/LC_MESSAGES/messages.po b/locales/uk/LC_MESSAGES/messages.po index b61d64ef2..2039a5f30 100644 --- a/locales/uk/LC_MESSAGES/messages.po +++ b/locales/uk/LC_MESSAGES/messages.po @@ -8,8 +8,8 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-07-14 16:45+0000\n" -"Last-Translator: Sviatoslav Sydorenko \n" +"PO-Revision-Date: 2021-07-16 10:46+0000\n" +"Last-Translator: Alex Solonenko \n" "Language-Team: Ukrainian \n" "Language: uk\n" @@ -27,10 +27,12 @@ msgstr "Зробіть внесок до керівництва" #: ../source/contribute.rst:7 msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" msgstr "" +"|PyPUG| запрошує контриб'юторів! Тут є багато способів, щоб допомогти, " +"зокрема:" #: ../source/contribute.rst:10 msgid "Reading the guide and giving feedback" -msgstr "" +msgstr "Читання гайду і надання відгуку" #: ../source/contribute.rst:11 msgid "Reviewing new contributions" @@ -9253,15 +9255,21 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:619 msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" msgstr "" +"Якшо ви хочете прочитати більше про пакування Python бібліотек, то ось, що " +"ви можете зробити:" #: ../source/tutorials/packaging-projects.rst:622 msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." msgstr "" +"Прочитайте більше про використання :ref:`setuptools` для пакування бібліотек " +"в :doc:`/guides/distributing-packages-using-setuptools`." #: ../source/tutorials/packaging-projects.rst:624 msgid "Read about :doc:`/guides/packaging-binary-extensions`." -msgstr "" +msgstr "Прочитайте про :doc:`/guides/packaging-binary-extensions`." #: ../source/tutorials/packaging-projects.rst:625 msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." msgstr "" +"Розгляньте альтернативи до :ref:`setuptools` такі як :ref:`flit`, " +":ref:`hatch`, і :ref:`poetry`." From 90842248e227fa3455eee2534ee811450a4772db Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Sun, 29 Aug 2021 18:15:32 +0200 Subject: [PATCH 0082/1072] Translated using Weblate (Ukrainian) Currently translated at 13.2% (302 of 2271 strings) Co-authored-by: Sviatoslav Sydorenko Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/uk/ Translation: pypa/packaging.python.org --- locales/uk/LC_MESSAGES/messages.po | 532 +++++++++++++++-------------- 1 file changed, 268 insertions(+), 264 deletions(-) diff --git a/locales/uk/LC_MESSAGES/messages.po b/locales/uk/LC_MESSAGES/messages.po index 2039a5f30..839467465 100644 --- a/locales/uk/LC_MESSAGES/messages.po +++ b/locales/uk/LC_MESSAGES/messages.po @@ -9,7 +9,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" "PO-Revision-Date: 2021-07-16 10:46+0000\n" -"Last-Translator: Alex Solonenko \n" +"Last-Translator: Sviatoslav Sydorenko \n" "Language-Team: Ukrainian \n" "Language: uk\n" @@ -531,7 +531,7 @@ msgstr "Так" #: ../source/discussions/pip-vs-easy-install.rst:54 #: ../source/discussions/pip-vs-easy-install.rst:57 msgid "No" -msgstr "" +msgstr "Ні" #: ../source/discussions/pip-vs-easy-install.rst:30 msgid "Uninstall Packages" @@ -539,7 +539,7 @@ msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:30 msgid "Yes (``python -m pip uninstall``)" -msgstr "" +msgstr "Так (``python -m pip uninstall``)" #: ../source/discussions/pip-vs-easy-install.rst:32 msgid "Dependency Overrides" @@ -555,11 +555,11 @@ msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:35 msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" -msgstr "" +msgstr "Так (``python -m pip list`` і ``python -m pip freeze``)" #: ../source/discussions/pip-vs-easy-install.rst:38 msgid ":pep:`438` Support" -msgstr "" +msgstr "Підтримка :pep:`438`" #: ../source/discussions/pip-vs-easy-install.rst:41 msgid "Installation format" @@ -583,11 +583,11 @@ msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:51 msgid "`pylauncher support`_" -msgstr "" +msgstr "`підтримка pylauncher `_" #: ../source/discussions/pip-vs-easy-install.rst:51 msgid "Yes [1]_" -msgstr "" +msgstr "Так [1]_" #: ../source/discussions/pip-vs-easy-install.rst:54 msgid ":ref:`Multi-version Installs`" @@ -607,7 +607,7 @@ msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:60 msgid "Yes, via setup.cfg" -msgstr "" +msgstr "Так, через setup.cfg" #: ../source/discussions/pip-vs-easy-install.rst:68 msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" @@ -615,7 +615,7 @@ msgstr "" #: ../source/discussions/wheel-vs-egg.rst:5 msgid "Wheel vs Egg" -msgstr "" +msgstr "Wheel чи Egg" #: ../source/discussions/wheel-vs-egg.rst:7 msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." @@ -667,7 +667,7 @@ msgstr "" #: ../source/glossary.rst:3 msgid "Glossary" -msgstr "" +msgstr "Голосарій" #: ../source/glossary.rst:8 msgid "Binary Distribution" @@ -735,7 +735,7 @@ msgstr "" #: ../source/glossary.rst:78 msgid "Module" -msgstr "" +msgstr "Модуль" #: ../source/glossary.rst:81 msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." @@ -759,7 +759,7 @@ msgstr "" #: ../source/glossary.rst:97 msgid "Project" -msgstr "" +msgstr "Проект" #: ../source/glossary.rst:100 msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." @@ -787,7 +787,7 @@ msgstr "" #: ../source/glossary.rst:127 msgid "Python Packaging Authority (PyPA)" -msgstr "" +msgstr "Управління з пакування Python (PyPA)" #: ../source/glossary.rst:130 msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." @@ -795,7 +795,7 @@ msgstr "" #: ../source/glossary.rst:139 msgid "Python Package Index (PyPI)" -msgstr "" +msgstr "Реєстр Python-пакунків (PyPI)" #: ../source/glossary.rst:142 msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." @@ -803,7 +803,7 @@ msgstr "" #: ../source/glossary.rst:145 msgid "pypi.org" -msgstr "" +msgstr "pypi.org" #: ../source/glossary.rst:148 msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." @@ -811,7 +811,7 @@ msgstr "" #: ../source/glossary.rst:152 msgid "pyproject.toml" -msgstr "" +msgstr "pyproject.toml" #: ../source/glossary.rst:155 msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." @@ -819,7 +819,7 @@ msgstr "" #: ../source/glossary.rst:157 msgid "Release" -msgstr "" +msgstr "Випуск" #: ../source/glossary.rst:160 msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." @@ -856,12 +856,12 @@ msgstr "" #: ../source/glossary.rst:194 #: ../source/guides/distributing-packages-using-setuptools.rst:56 msgid "setup.py" -msgstr "" +msgstr "setup.py" #: ../source/glossary.rst:195 #: ../source/guides/distributing-packages-using-setuptools.rst:77 msgid "setup.cfg" -msgstr "" +msgstr "setup.cfg" #: ../source/glossary.rst:198 msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." @@ -1018,18 +1018,18 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 msgid "Column" -msgstr "" +msgstr "Стовпець" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 #: ../source/guides/using-manifest-in.rst:67 #: ../source/specifications/core-metadata.rst:185 msgid "Description" -msgstr "" +msgstr "Опис" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 #: ../source/specifications/direct-url.rst:226 msgid "Examples" -msgstr "" +msgstr "Приклади" #: ../source/guides/analyzing-pypi-package-downloads.rst:80 msgid "timestamp" @@ -1049,7 +1049,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:82 msgid "Project name" -msgstr "" +msgstr "Назва проекту" #: ../source/guides/analyzing-pypi-package-downloads.rst:82 msgid "``pipenv``, ``nose``" @@ -1073,7 +1073,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:86 msgid "Installer" -msgstr "" +msgstr "Встановлювач" #: ../source/guides/analyzing-pypi-package-downloads.rst:86 msgid "pip, `bandersnatch`_" @@ -1085,7 +1085,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:88 msgid "Python version" -msgstr "" +msgstr "Версія Python" #: ../source/guides/analyzing-pypi-package-downloads.rst:88 msgid "``2.7.12``, ``3.6.4``" @@ -1120,7 +1120,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:121 msgid "26190085" -msgstr "" +msgstr "26190085" #: ../source/guides/analyzing-pypi-package-downloads.rst:124 msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." @@ -1128,7 +1128,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:142 msgid "24334215" -msgstr "" +msgstr "24334215" #: ../source/guides/analyzing-pypi-package-downloads.rst:146 msgid "Package downloads over time" @@ -1144,7 +1144,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:170 msgid "1956741" -msgstr "" +msgstr "1956741" #: ../source/guides/analyzing-pypi-package-downloads.rst:170 msgid "2018-01-01" @@ -1152,7 +1152,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:172 msgid "2344692" -msgstr "" +msgstr "2344692" #: ../source/guides/analyzing-pypi-package-downloads.rst:172 msgid "2017-12-01" @@ -1160,7 +1160,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:174 msgid "1730398" -msgstr "" +msgstr "1730398" #: ../source/guides/analyzing-pypi-package-downloads.rst:174 msgid "2017-11-01" @@ -1204,7 +1204,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:207 msgid "3.7" -msgstr "" +msgstr "3.7" #: ../source/guides/analyzing-pypi-package-downloads.rst:207 msgid "18051328726" @@ -1260,7 +1260,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:231 msgid "Additional tools" -msgstr "" +msgstr "Додаткові інструменти" #: ../source/guides/analyzing-pypi-package-downloads.rst:233 msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." @@ -1465,7 +1465,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:86 msgid "README.rst / README.md" -msgstr "" +msgstr "README.rst / README.md" #: ../source/guides/distributing-packages-using-setuptools.rst:88 msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." @@ -1481,7 +1481,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:108 msgid "MANIFEST.in" -msgstr "" +msgstr "MANIFEST.in" #: ../source/guides/distributing-packages-using-setuptools.rst:110 msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." @@ -1497,7 +1497,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:122 msgid "LICENSE.txt" -msgstr "" +msgstr "LICENSE.txt" #: ../source/guides/distributing-packages-using-setuptools.rst:124 msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." @@ -1770,7 +1770,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:545 msgid "Choosing a versioning scheme" -msgstr "" +msgstr "Вибір схеми версіонування" #: ../source/guides/distributing-packages-using-setuptools.rst:548 msgid "Standards compliance for interoperability" @@ -2051,7 +2051,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:888 msgid "Create an account" -msgstr "" +msgstr "Створіть обліковий запис" #: ../source/guides/distributing-packages-using-setuptools.rst:890 msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." @@ -2207,7 +2207,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:693 #: ../source/specifications/core-metadata.rst:722 msgid "Examples::" -msgstr "" +msgstr "Приклади::" #: ../source/guides/dropping-older-python-versions.rst:86 msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." @@ -2331,7 +2331,7 @@ msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:8 #: ../source/guides/supporting-multiple-python-versions.rst:8 msgid "2014-12-24" -msgstr "" +msgstr "24.12.2014" #: ../source/guides/index-mirrors-and-caches.rst:14 msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." @@ -2569,7 +2569,7 @@ msgstr "" #: ../source/guides/installing-using-linux-tools.rst:8 msgid "2015-09-17" -msgstr "" +msgstr "17.09.2015" #: ../source/guides/installing-using-linux-tools.rst:11 msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." @@ -2589,11 +2589,11 @@ msgstr "" #: ../source/guides/installing-using-linux-tools.rst:32 msgid "Fedora" -msgstr "" +msgstr "Fedora" #: ../source/guides/installing-using-linux-tools.rst:34 msgid "Fedora 21:" -msgstr "" +msgstr "Fedora 21:" #: ../source/guides/installing-using-linux-tools.rst:36 #: ../source/guides/installing-using-linux-tools.rst:45 @@ -2621,7 +2621,7 @@ msgstr "" #: ../source/guides/installing-using-linux-tools.rst:63 msgid "CentOS/RHEL" -msgstr "" +msgstr "CentOS/RHEL" #: ../source/guides/installing-using-linux-tools.rst:65 msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." @@ -2681,7 +2681,7 @@ msgstr "" #: ../source/guides/installing-using-linux-tools.rst:122 msgid "openSUSE" -msgstr "" +msgstr "openSUSE" #: ../source/guides/installing-using-linux-tools.rst:129 #: ../source/guides/installing-using-linux-tools.rst:143 @@ -2691,7 +2691,7 @@ msgstr "" #: ../source/guides/installing-using-linux-tools.rst:135 msgid "Debian/Ubuntu" -msgstr "" +msgstr "Debian/Ubuntu" #: ../source/guides/installing-using-linux-tools.rst:150 msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." @@ -2699,7 +2699,7 @@ msgstr "" #: ../source/guides/installing-using-linux-tools.rst:156 msgid "Arch Linux" -msgstr "" +msgstr "Arch Linux" #: ../source/guides/installing-using-linux-tools.rst:168 msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." @@ -2719,7 +2719,7 @@ msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 msgid "Installing pip" -msgstr "" +msgstr "Встановлення pip" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." @@ -2811,7 +2811,7 @@ msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 msgid "Installing packages" -msgstr "" +msgstr "Встановлення пакунків" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" @@ -2945,7 +2945,7 @@ msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:9 msgid "Creating a README file" -msgstr "" +msgstr "Створення файлу README" #: ../source/guides/making-a-pypi-friendly-readme.rst:11 msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." @@ -3005,15 +3005,15 @@ msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:62 msgid "``setuptools >= 38.6.0``" -msgstr "" +msgstr "``setuptools >= 38.6.0``" #: ../source/guides/making-a-pypi-friendly-readme.rst:63 msgid "``wheel >= 0.31.0``" -msgstr "" +msgstr "``wheel >= 0.31.0``" #: ../source/guides/making-a-pypi-friendly-readme.rst:64 msgid "``twine >= 1.11.0``" -msgstr "" +msgstr "``twine >= 1.11.0``" #: ../source/guides/making-a-pypi-friendly-readme.rst:66 msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" @@ -3085,27 +3085,27 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:24 msgid "``twine`` 1.8.0" -msgstr "" +msgstr "``twine`` 1.8.0" #: ../source/guides/migrating-to-pypi-org.rst:25 msgid "``setuptools`` 27.0.0" -msgstr "" +msgstr "``setuptools`` 27.0.0" #: ../source/guides/migrating-to-pypi-org.rst:26 msgid "Python 2.7.13 (``distutils`` update)" -msgstr "" +msgstr "Python 2.7.13 (оновлення ``distutils``)" #: ../source/guides/migrating-to-pypi-org.rst:27 msgid "Python 3.4.6 (``distutils`` update)" -msgstr "" +msgstr "Python 3.4.6 (оновлення ``distutils``)" #: ../source/guides/migrating-to-pypi-org.rst:28 msgid "Python 3.5.3 (``distutils`` update)" -msgstr "" +msgstr "Python 3.5.3 (оновлення ``distutils``)" #: ../source/guides/migrating-to-pypi-org.rst:29 msgid "Python 3.6.0 (``distutils`` update)" -msgstr "" +msgstr "Python 3.6.0 (оновлення ``distutils``)" #: ../source/guides/migrating-to-pypi-org.rst:31 msgid "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:" @@ -3142,7 +3142,7 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:89 #: ../source/guides/using-testpypi.rst:5 msgid "Using TestPyPI" -msgstr "" +msgstr "Використання TestPyPI" #: ../source/guides/migrating-to-pypi-org.rst:91 msgid "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:" @@ -3210,7 +3210,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:8 msgid "2013-12-08" -msgstr "" +msgstr "08.12.2013" #: ../source/guides/packaging-binary-extensions.rst:10 msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." @@ -3250,7 +3250,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:71 msgid "Disadvantages" -msgstr "" +msgstr "Недоліки" #: ../source/guides/packaging-binary-extensions.rst:73 msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." @@ -3394,7 +3394,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:271 msgid "For Python 2.7" -msgstr "" +msgstr "Для Python 2.7" #: ../source/guides/packaging-binary-extensions.rst:273 msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." @@ -3408,11 +3408,11 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:288 #: ../source/guides/packaging-binary-extensions.rst:295 msgid "Done." -msgstr "" +msgstr "Готово." #: ../source/guides/packaging-binary-extensions.rst:280 msgid "For Python 3.4" -msgstr "" +msgstr "Для Python 3.4" #: ../source/guides/packaging-binary-extensions.rst:282 msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." @@ -3428,7 +3428,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:290 msgid "For Python 3.5" -msgstr "" +msgstr "Для Python 3.5" #: ../source/guides/packaging-binary-extensions.rst:292 msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." @@ -3468,7 +3468,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:343 msgid "Additional resources" -msgstr "" +msgstr "Додаткові матеріали" #: ../source/guides/packaging-binary-extensions.rst:345 msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." @@ -3650,7 +3650,7 @@ msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 msgid "Let's begin! 🚀" -msgstr "" +msgstr "Почнімо! 🚀" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" @@ -3734,7 +3734,7 @@ msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 msgid "That's all, folks!" -msgstr "" +msgstr "Це все, панове!" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" @@ -3914,7 +3914,7 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:6 msgid "2015-12-03" -msgstr "" +msgstr "03.12.2015" #: ../source/guides/supporting-windows-using-appveyor.rst:8 msgid "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." @@ -3962,7 +3962,7 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:69 msgid "appveyor.yml" -msgstr "" +msgstr "appveyor.yml" #: ../source/guides/supporting-windows-using-appveyor.rst:75 msgid "This file can be downloaded from `here `__." @@ -4050,19 +4050,19 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:170 msgid "``DISTUTILS_USE_SDK``" -msgstr "" +msgstr "``DISTUTILS_USE_SDK``" #: ../source/guides/supporting-windows-using-appveyor.rst:171 msgid "``MSSdk``" -msgstr "" +msgstr "``MSSdk``" #: ../source/guides/supporting-windows-using-appveyor.rst:172 msgid "``INCLUDE``" -msgstr "" +msgstr "``INCLUDE``" #: ../source/guides/supporting-windows-using-appveyor.rst:173 msgid "``LIB``" -msgstr "" +msgstr "``LIB``" #: ../source/guides/supporting-windows-using-appveyor.rst:175 msgid "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." @@ -4118,7 +4118,7 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:234 msgid "``appveyor-sample/build.cmd``" -msgstr "" +msgstr "``appveyor-sample/build.cmd``" #: ../source/guides/tool-recommendations.rst:5 msgid "Tool recommendations" @@ -4142,19 +4142,19 @@ msgstr "" #: ../source/guides/tool-recommendations.rst:20 msgid ":ref:`pip`" -msgstr "" +msgstr ":ref:`pip`" #: ../source/guides/tool-recommendations.rst:22 msgid "`pip-tools `_" -msgstr "" +msgstr "`pip-tools `_" #: ../source/guides/tool-recommendations.rst:24 msgid "`Poetry `_" -msgstr "" +msgstr "`Poetry `_" #: ../source/guides/tool-recommendations.rst:27 msgid "Installation tool recommendations" -msgstr "" +msgstr "Поради щодо засобу встановлення" #: ../source/guides/tool-recommendations.rst:29 msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" @@ -4178,7 +4178,7 @@ msgstr "" #: ../source/guides/tool-recommendations.rst:47 msgid "Packaging tool recommendations" -msgstr "" +msgstr "Поради щодо засобу пакування" #: ../source/guides/tool-recommendations.rst:49 msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" @@ -4286,31 +4286,31 @@ msgstr "" #: ../source/guides/using-manifest-in.rst:39 msgid ":file:`setup.cfg`" -msgstr "" +msgstr ":file:`setup.cfg`" #: ../source/guides/using-manifest-in.rst:40 msgid ":file:`README`" -msgstr "" +msgstr ":file:`README`" #: ../source/guides/using-manifest-in.rst:41 msgid ":file:`README.txt`" -msgstr "" +msgstr ":file:`README.txt`" #: ../source/guides/using-manifest-in.rst:42 msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" -msgstr "" +msgstr ":file:`README.rst` (Python 3.7+ або setuptools 0.6.27+)" #: ../source/guides/using-manifest-in.rst:43 msgid ":file:`README.md` (setuptools 36.4.0+)" -msgstr "" +msgstr ":file:`README.md` (setuptools 36.4.0+)" #: ../source/guides/using-manifest-in.rst:44 msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" -msgstr "" +msgstr ":file:`pyproject.toml` (setuptools 43.0.0+)" #: ../source/guides/using-manifest-in.rst:45 msgid ":file:`MANIFEST.in`" -msgstr "" +msgstr ":file:`MANIFEST.in`" #: ../source/guides/using-manifest-in.rst:47 msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." @@ -4322,7 +4322,7 @@ msgstr "" #: ../source/guides/using-manifest-in.rst:60 msgid ":file:`MANIFEST.in` commands" -msgstr "" +msgstr "Команди в :file:`MANIFEST.in`" #: ../source/guides/using-manifest-in.rst:62 msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" @@ -4330,11 +4330,11 @@ msgstr "" #: ../source/guides/using-manifest-in.rst:67 msgid "Command" -msgstr "" +msgstr "Команда" #: ../source/guides/using-manifest-in.rst:69 msgid ":samp:`include {pat1} {pat2} ...`" -msgstr "" +msgstr ":samp:`include {pat1} {pat2} ...`" #: ../source/guides/using-manifest-in.rst:69 msgid "Add all files matching any of the listed patterns" @@ -4342,7 +4342,7 @@ msgstr "" #: ../source/guides/using-manifest-in.rst:70 msgid ":samp:`exclude {pat1} {pat2} ...`" -msgstr "" +msgstr ":samp:`exclude {pat1} {pat2} ...`" #: ../source/guides/using-manifest-in.rst:70 msgid "Remove all files matching any of the listed patterns" @@ -4350,7 +4350,7 @@ msgstr "" #: ../source/guides/using-manifest-in.rst:71 msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" -msgstr "" +msgstr ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" #: ../source/guides/using-manifest-in.rst:71 msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" @@ -4358,7 +4358,7 @@ msgstr "" #: ../source/guides/using-manifest-in.rst:72 msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" -msgstr "" +msgstr ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" #: ../source/guides/using-manifest-in.rst:72 msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" @@ -4366,7 +4366,7 @@ msgstr "" #: ../source/guides/using-manifest-in.rst:73 msgid ":samp:`global-include {pat1} {pat2} ...`" -msgstr "" +msgstr ":samp:`global-include {pat1} {pat2} ...`" #: ../source/guides/using-manifest-in.rst:73 msgid "Add all files anywhere in the source tree matching any of the listed patterns" @@ -4374,7 +4374,7 @@ msgstr "" #: ../source/guides/using-manifest-in.rst:74 msgid ":samp:`global-exclude {pat1} {pat2} ...`" -msgstr "" +msgstr ":samp:`global-exclude {pat1} {pat2} ...`" #: ../source/guides/using-manifest-in.rst:74 msgid "Remove all files anywhere in the source tree matching any of the listed patterns" @@ -4382,7 +4382,7 @@ msgstr "" #: ../source/guides/using-manifest-in.rst:75 msgid ":samp:`graft {dir-pattern}`" -msgstr "" +msgstr ":samp:`graft {dir-pattern}`" #: ../source/guides/using-manifest-in.rst:75 msgid "Add all files under directories matching ``dir-pattern``" @@ -4390,7 +4390,7 @@ msgstr "" #: ../source/guides/using-manifest-in.rst:76 msgid ":samp:`prune {dir-pattern}`" -msgstr "" +msgstr ":samp:`prune {dir-pattern}`" #: ../source/guides/using-manifest-in.rst:76 msgid "Remove all files under directories matching ``dir-pattern``" @@ -4467,7 +4467,7 @@ msgstr "" #: ../source/index.rst:3 #: ../source/key_projects.rst:181 msgid "Python Packaging User Guide" -msgstr "" +msgstr "Користувацьке керівництво з пакування Python" #: ../source/index.rst:5 msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." @@ -4511,7 +4511,7 @@ msgstr "" #: ../source/index.rst:52 msgid "Learn more" -msgstr "" +msgstr "Дізнатися більше" #: ../source/index.rst:54 msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" @@ -4543,11 +4543,11 @@ msgstr "" #: ../source/key_projects.rst:14 msgid "PyPA Projects" -msgstr "" +msgstr "Проекти PyPA" #: ../source/key_projects.rst:19 msgid "bandersnatch" -msgstr "" +msgstr "bandersnatch" #: ../source/key_projects.rst:21 msgid "`Issues `__ | `GitHub `__ | `PyPI `__" @@ -4559,7 +4559,7 @@ msgstr "" #: ../source/key_projects.rst:35 msgid "build" -msgstr "" +msgstr "build" #: ../source/key_projects.rst:37 msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" @@ -4571,7 +4571,7 @@ msgstr "" #: ../source/key_projects.rst:49 msgid "cibuildwheel" -msgstr "" +msgstr "cibuildwheel" #: ../source/key_projects.rst:51 msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" @@ -4583,7 +4583,7 @@ msgstr "" #: ../source/key_projects.rst:64 msgid "distlib" -msgstr "" +msgstr "distlib" #: ../source/key_projects.rst:66 msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" @@ -4599,7 +4599,7 @@ msgstr "" #: ../source/key_projects.rst:90 msgid "packaging" -msgstr "" +msgstr "packaging" #: ../source/key_projects.rst:92 msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" @@ -4620,7 +4620,7 @@ msgstr "" #: ../source/key_projects.rst:119 #: ../source/specifications/platform-compatibility-tags.rst:85 msgid "pip" -msgstr "" +msgstr "pip" #: ../source/key_projects.rst:121 msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" @@ -4636,7 +4636,7 @@ msgstr "" #: ../source/key_projects.rst:137 msgid "Pipenv" -msgstr "" +msgstr "Pipenv" #: ../source/key_projects.rst:139 msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" @@ -4652,7 +4652,7 @@ msgstr "" #: ../source/key_projects.rst:159 msgid "Pipfile" -msgstr "" +msgstr "Pipfile" #: ../source/key_projects.rst:161 msgid "`Source `__" @@ -4664,7 +4664,7 @@ msgstr "" #: ../source/key_projects.rst:170 msgid "pipx" -msgstr "" +msgstr "pipx" #: ../source/key_projects.rst:172 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" @@ -4680,11 +4680,11 @@ msgstr "" #: ../source/key_projects.rst:187 msgid "This guide!" -msgstr "" +msgstr "Це керівництво!" #: ../source/key_projects.rst:192 msgid "readme_renderer" -msgstr "" +msgstr "readme_renderer" #: ../source/key_projects.rst:194 msgid "`GitHub and docs `__ | `PyPI `__" @@ -4696,7 +4696,7 @@ msgstr "" #: ../source/key_projects.rst:208 msgid "setuptools" -msgstr "" +msgstr "setuptools" #: ../source/key_projects.rst:210 msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" @@ -4712,7 +4712,7 @@ msgstr "" #: ../source/key_projects.rst:227 msgid "trove-classifiers" -msgstr "" +msgstr "trove-classifiers" #: ../source/key_projects.rst:229 msgid "`Issues `__ | `GitHub `__ | `PyPI `__" @@ -4728,7 +4728,7 @@ msgstr "" #: ../source/key_projects.rst:253 msgid "twine" -msgstr "" +msgstr "twine" #: ../source/key_projects.rst:255 msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" @@ -4741,7 +4741,7 @@ msgstr "" #: ../source/key_projects.rst:270 #: ../source/overview.rst:415 msgid "virtualenv" -msgstr "" +msgstr "virtualenv" #: ../source/key_projects.rst:272 msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" @@ -4753,7 +4753,7 @@ msgstr "" #: ../source/key_projects.rst:290 msgid "Warehouse" -msgstr "" +msgstr "Warehouse" #: ../source/key_projects.rst:292 msgid "`Docs `__ | `Issues `__ | `GitHub `__" @@ -4765,7 +4765,7 @@ msgstr "" #: ../source/key_projects.rst:304 msgid "wheel" -msgstr "" +msgstr "wheel" #: ../source/key_projects.rst:306 msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" @@ -4785,7 +4785,7 @@ msgstr "" #: ../source/key_projects.rst:329 msgid "bento" -msgstr "" +msgstr "bento" #: ../source/key_projects.rst:331 msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" @@ -4797,7 +4797,7 @@ msgstr "" #: ../source/key_projects.rst:344 msgid "buildout" -msgstr "" +msgstr "buildout" #: ../source/key_projects.rst:346 msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" @@ -4809,7 +4809,7 @@ msgstr "" #: ../source/key_projects.rst:358 msgid "conda" -msgstr "" +msgstr "conda" #: ../source/key_projects.rst:360 msgid "`Docs `__" @@ -4829,7 +4829,7 @@ msgstr "" #: ../source/key_projects.rst:386 msgid "devpi" -msgstr "" +msgstr "devpi" #: ../source/key_projects.rst:388 msgid "`Docs `__ | `Issues `__ | `PyPI `__" @@ -4841,7 +4841,7 @@ msgstr "" #: ../source/key_projects.rst:401 msgid "flit" -msgstr "" +msgstr "flit" #: ../source/key_projects.rst:403 msgid "`Docs `__ | `Issues `__ | `PyPI `__" @@ -4857,7 +4857,7 @@ msgstr "" #: ../source/key_projects.rst:422 msgid "enscons" -msgstr "" +msgstr "enscons" #: ../source/key_projects.rst:424 msgid "`Source `__ | `Issues `__ | `PyPI `__" @@ -4869,7 +4869,7 @@ msgstr "" #: ../source/key_projects.rst:443 msgid "Hashdist" -msgstr "" +msgstr "Hashdist" #: ../source/key_projects.rst:445 msgid "`Docs `__ | `GitHub `__" @@ -4881,7 +4881,7 @@ msgstr "" #: ../source/key_projects.rst:460 msgid "hatch" -msgstr "" +msgstr "hatch" #: ../source/key_projects.rst:462 msgid "`GitHub and Docs `__ | `PyPI `__" @@ -4893,7 +4893,7 @@ msgstr "" #: ../source/key_projects.rst:475 msgid "multibuild" -msgstr "" +msgstr "multibuild" #: ../source/key_projects.rst:477 msgid "`GitHub `__" @@ -4905,7 +4905,7 @@ msgstr "" #: ../source/key_projects.rst:485 msgid "pex" -msgstr "" +msgstr "pex" #: ../source/key_projects.rst:487 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" @@ -4917,7 +4917,7 @@ msgstr "" #: ../source/key_projects.rst:500 msgid "pip-tools" -msgstr "" +msgstr "pip-tools" #: ../source/key_projects.rst:502 msgid "`GitHub and Docs `__ | `PyPI `__" @@ -4929,7 +4929,7 @@ msgstr "" #: ../source/key_projects.rst:517 msgid "piwheels" -msgstr "" +msgstr "piwheels" #: ../source/key_projects.rst:519 msgid "`Website `__ | `Docs `__ | `GitHub `__" @@ -4941,7 +4941,7 @@ msgstr "" #: ../source/key_projects.rst:532 msgid "poetry" -msgstr "" +msgstr "poetry" #: ../source/key_projects.rst:534 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" @@ -4953,7 +4953,7 @@ msgstr "" #: ../source/key_projects.rst:548 msgid "pypiserver" -msgstr "" +msgstr "pypiserver" #: ../source/key_projects.rst:550 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" @@ -4965,7 +4965,7 @@ msgstr "" #: ../source/key_projects.rst:564 msgid "scikit-build" -msgstr "" +msgstr "scikit-build" #: ../source/key_projects.rst:566 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" @@ -4977,7 +4977,7 @@ msgstr "" #: ../source/key_projects.rst:582 msgid "shiv" -msgstr "" +msgstr "shiv" #: ../source/key_projects.rst:584 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" @@ -5001,7 +5001,7 @@ msgstr "" #: ../source/key_projects.rst:617 msgid "zest.releaser" -msgstr "" +msgstr "zest.releaser" #: ../source/key_projects.rst:619 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" @@ -5017,7 +5017,7 @@ msgstr "" #: ../source/key_projects.rst:635 msgid "ensurepip" -msgstr "" +msgstr "ensurepip" #: ../source/key_projects.rst:637 msgid "`Docs `__ | `Issues `__" @@ -5029,7 +5029,7 @@ msgstr "" #: ../source/key_projects.rst:649 msgid "distutils" -msgstr "" +msgstr "distutils" #: ../source/key_projects.rst:651 msgid "`Docs `__ | `Issues `__" @@ -5045,7 +5045,7 @@ msgstr "" #: ../source/key_projects.rst:670 msgid "venv" -msgstr "" +msgstr "venv" #: ../source/key_projects.rst:672 msgid "`Docs `__ | `Issues `__" @@ -5057,11 +5057,11 @@ msgstr "" #: ../source/news.rst:2 msgid "News" -msgstr "" +msgstr "Новини" #: ../source/news.rst:5 msgid "September 2019" -msgstr "" +msgstr "вересень 2019" #: ../source/news.rst:6 msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" @@ -5069,7 +5069,7 @@ msgstr "" #: ../source/news.rst:9 msgid "August 2019" -msgstr "" +msgstr "серпень 2019" #: ../source/news.rst:10 msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" @@ -5077,7 +5077,7 @@ msgstr "" #: ../source/news.rst:13 msgid "July 2019" -msgstr "" +msgstr "липень 2019" #: ../source/news.rst:14 msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" @@ -5101,7 +5101,7 @@ msgstr "" #: ../source/news.rst:21 msgid "June 2019" -msgstr "" +msgstr "червень 2019" #: ../source/news.rst:22 msgid "Fixed some typos. (:pr:`620`)" @@ -5109,7 +5109,7 @@ msgstr "" #: ../source/news.rst:25 msgid "May 2019" -msgstr "" +msgstr "травень 2019" #: ../source/news.rst:26 msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" @@ -5121,7 +5121,7 @@ msgstr "" #: ../source/news.rst:30 msgid "April 2019" -msgstr "" +msgstr "квітень 2019" #: ../source/news.rst:31 msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" @@ -5133,7 +5133,7 @@ msgstr "" #: ../source/news.rst:35 msgid "March 2019" -msgstr "" +msgstr "березень 2019" #: ../source/news.rst:36 msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" @@ -5145,7 +5145,7 @@ msgstr "" #: ../source/news.rst:40 msgid "February 2019" -msgstr "" +msgstr "лютий 2019" #: ../source/news.rst:41 msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" @@ -5157,7 +5157,7 @@ msgstr "" #: ../source/news.rst:45 msgid "January 2019" -msgstr "" +msgstr "січень 2019" #: ../source/news.rst:46 msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" @@ -5173,7 +5173,7 @@ msgstr "" #: ../source/news.rst:51 msgid "December 2018" -msgstr "" +msgstr "грудень 2018" #: ../source/news.rst:52 msgid "No programmers in the office!" @@ -5181,7 +5181,7 @@ msgstr "" #: ../source/news.rst:55 msgid "November 2018" -msgstr "" +msgstr "листопад 2018" #: ../source/news.rst:56 msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" @@ -5201,7 +5201,7 @@ msgstr "" #: ../source/news.rst:62 msgid "October 2018" -msgstr "" +msgstr "жовтень 2018" #: ../source/news.rst:63 msgid "Updated Nox package name. (:pr:`566`)" @@ -5213,7 +5213,7 @@ msgstr "" #: ../source/news.rst:67 msgid "September 2018" -msgstr "" +msgstr "вересень 2018" #: ../source/news.rst:68 msgid "Added a section on checking RST markup. (:pr:`554`)" @@ -5237,7 +5237,7 @@ msgstr "" #: ../source/news.rst:75 msgid "August 2018" -msgstr "" +msgstr "серпень 2018" #: ../source/news.rst:76 msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" @@ -5257,7 +5257,7 @@ msgstr "" #: ../source/news.rst:82 msgid "July 2018" -msgstr "" +msgstr "липень 2018" #: ../source/news.rst:84 msgid "Improved binary extension docs. (:pr:`531`)" @@ -5269,7 +5269,7 @@ msgstr "" #: ../source/news.rst:88 msgid "June 2018" -msgstr "" +msgstr "червень 2018" #: ../source/news.rst:90 msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" @@ -5281,7 +5281,7 @@ msgstr "" #: ../source/news.rst:94 msgid "May 2018" -msgstr "" +msgstr "травень 2018" #: ../source/news.rst:96 msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" @@ -5313,7 +5313,7 @@ msgstr "" #: ../source/news.rst:105 msgid "April 2018" -msgstr "" +msgstr "квітень 2018" #: ../source/news.rst:107 msgid "Added README guide. (:pr:`461`)" @@ -5345,7 +5345,7 @@ msgstr "" #: ../source/news.rst:116 msgid "March 2018" -msgstr "" +msgstr "березень 2018" #: ../source/news.rst:118 msgid "Updated \"installing scientific packages\". (:pr:`455`)" @@ -5365,7 +5365,7 @@ msgstr "" #: ../source/news.rst:124 msgid "February 2018" -msgstr "" +msgstr "лютий 2018" #: ../source/news.rst:126 msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" @@ -5389,7 +5389,7 @@ msgstr "" #: ../source/news.rst:133 msgid "January 2018" -msgstr "" +msgstr "січень 2018" #: ../source/news.rst:135 msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" @@ -5401,7 +5401,7 @@ msgstr "" #: ../source/news.rst:139 msgid "December 2017" -msgstr "" +msgstr "грудень 2017" #: ../source/news.rst:141 msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" @@ -5421,7 +5421,7 @@ msgstr "" #: ../source/news.rst:147 msgid "November 2017" -msgstr "" +msgstr "листопад 2017" #: ../source/news.rst:149 msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" @@ -5441,7 +5441,7 @@ msgstr "" #: ../source/news.rst:156 msgid "October 2017" -msgstr "" +msgstr "жовтень 2017" #: ../source/news.rst:158 msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" @@ -5457,7 +5457,7 @@ msgstr "" #: ../source/news.rst:163 msgid "September 2017" -msgstr "" +msgstr "вересень 2017" #: ../source/news.rst:165 msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" @@ -5469,7 +5469,7 @@ msgstr "" #: ../source/news.rst:170 msgid "August 2017" -msgstr "" +msgstr "серпень 2017" #: ../source/news.rst:172 msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" @@ -5485,7 +5485,7 @@ msgstr "" #: ../source/news.rst:177 msgid "July 2017" -msgstr "" +msgstr "липень 2017" #: ../source/news.rst:179 msgid "Added ``flit`` to the key projects list. (:pr:`358`)" @@ -5509,7 +5509,7 @@ msgstr "" #: ../source/news.rst:186 msgid "June 2017" -msgstr "" +msgstr "червень 2017" #: ../source/news.rst:188 msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" @@ -5553,7 +5553,7 @@ msgstr "" #: ../source/news.rst:200 msgid "May 2017" -msgstr "" +msgstr "травень 2017" #: ../source/news.rst:202 msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" @@ -5569,7 +5569,7 @@ msgstr "" #: ../source/news.rst:207 msgid "April 2017" -msgstr "" +msgstr "квітень 2017" #: ../source/news.rst:209 msgid "Added travis configuration for testing pull requests. (:pr:`300`)" @@ -5613,7 +5613,7 @@ msgstr "" #: ../source/news.rst:223 msgid "March 2017" -msgstr "" +msgstr "березень 2017" #: ../source/news.rst:225 msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" @@ -5621,7 +5621,7 @@ msgstr "" #: ../source/news.rst:228 msgid "February 2017" -msgstr "" +msgstr "лютий 2017" #: ../source/news.rst:230 msgid "Added :pep:`518`. (:pr:`281`)" @@ -5802,18 +5802,19 @@ msgstr "" #: ../source/overview.rst:205 msgid "`Heroku `_" msgstr "" +"`Heroku `_" #: ../source/overview.rst:206 msgid "`Google App Engine `_" -msgstr "" +msgstr "`Google App Engine `_" #: ../source/overview.rst:207 msgid "`PythonAnywhere `_" -msgstr "" +msgstr "`PythonAnywhere `_" #: ../source/overview.rst:208 msgid "`OpenShift `_" -msgstr "" +msgstr "`OpenShift `_" #: ../source/overview.rst:209 msgid "\"Serverless\" frameworks like `Zappa `_" @@ -5841,19 +5842,19 @@ msgstr "" #: ../source/overview.rst:231 msgid "`Kivy `_" -msgstr "" +msgstr "`Kivy `_" #: ../source/overview.rst:232 msgid "`Beeware `_" -msgstr "" +msgstr "`Beeware `_" #: ../source/overview.rst:233 msgid "`Brython `_" -msgstr "" +msgstr "`Brython `_" #: ../source/overview.rst:234 msgid "`Flexx `_" -msgstr "" +msgstr "`Flexx `_" #: ../source/overview.rst:236 msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." @@ -5881,7 +5882,7 @@ msgstr "" #: ../source/overview.rst:253 msgid "`shiv `_ (requires Python 3)" -msgstr "" +msgstr "`shiv `_ (потребує Python 3)" #: ../source/overview.rst:255 msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." @@ -5921,15 +5922,15 @@ msgstr "" #: ../source/overview.rst:293 msgid "`Enthought Canopy `_" -msgstr "" +msgstr "`Enthought Canopy `_" #: ../source/overview.rst:294 msgid "`ActiveState ActivePython `_" -msgstr "" +msgstr "`ActiveState ActivePython `_" #: ../source/overview.rst:295 msgid "`WinPython `_" -msgstr "" +msgstr "`WinPython `_" #: ../source/overview.rst:300 msgid "Bringing your own Python executable" @@ -6005,19 +6006,19 @@ msgstr "" #: ../source/overview.rst:347 msgid "`AppImage `_" -msgstr "" +msgstr "`AppImage `_" #: ../source/overview.rst:348 msgid "`Docker `_" -msgstr "" +msgstr "`Docker `_" #: ../source/overview.rst:349 msgid "`Flatpak `_" -msgstr "" +msgstr "`Flatpak `_" #: ../source/overview.rst:350 msgid "`Snapcraft `_" -msgstr "" +msgstr "`Snapcraft `_" #: ../source/overview.rst:353 msgid "Bringing your own kernel" @@ -6033,7 +6034,7 @@ msgstr "" #: ../source/overview.rst:364 msgid "`Vagrant `_" -msgstr "" +msgstr "`Vagrant `_" #: ../source/overview.rst:365 msgid "`VHD `_, `AMI `_, and `other formats `_" @@ -6065,7 +6066,7 @@ msgstr "" #: ../source/overview.rst:392 msgid "What about..." -msgstr "" +msgstr "А як щодо..." #: ../source/overview.rst:394 msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." @@ -6093,7 +6094,7 @@ msgstr "" #: ../source/overview.rst:432 msgid "Security" -msgstr "" +msgstr "Безпека" #: ../source/overview.rst:434 msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." @@ -6105,7 +6106,7 @@ msgstr "" #: ../source/overview.rst:446 msgid "Wrap up" -msgstr "" +msgstr "Підсумок" #: ../source/overview.rst:448 msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." @@ -6141,7 +6142,7 @@ msgstr "" #: ../source/specifications/binary-distribution-format.rst:34 msgid "Rationale" -msgstr "" +msgstr "Обґрунтування" #: ../source/specifications/binary-distribution-format.rst:36 msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." @@ -6494,19 +6495,20 @@ msgstr "" #: ../source/specifications/binary-distribution-format.rst:314 msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" -msgstr "" +msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" #: ../source/specifications/binary-distribution-format.rst:315 msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" msgstr "" +"http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" #: ../source/specifications/binary-distribution-format.rst:316 msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" -msgstr "" +msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" #: ../source/specifications/binary-distribution-format.rst:317 msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" -msgstr "" +msgstr "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" #: ../source/specifications/binary-distribution-format.rst:321 msgid "Comparison to .egg" @@ -6538,7 +6540,7 @@ msgstr "" #: ../source/specifications/binary-distribution-format.rst:348 msgid "FAQ" -msgstr "" +msgstr "ЧаПи" #: ../source/specifications/binary-distribution-format.rst:352 msgid "Wheel defines a .data directory. Should I put all my data there?" @@ -6614,7 +6616,7 @@ msgstr "" #: ../source/specifications/binary-distribution-format.rst:450 msgid "Changes" -msgstr "" +msgstr "Зміни" #: ../source/specifications/binary-distribution-format.rst:452 msgid "Since :pep:`427`, this specification has changed as follows:" @@ -6630,7 +6632,7 @@ msgstr "" #: ../source/specifications/binary-distribution-format.rst:466 msgid "Appendix" -msgstr "" +msgstr "Додаток" #: ../source/specifications/binary-distribution-format.rst:468 msgid "Example urlsafe-base64-nopad implementation::" @@ -6638,11 +6640,11 @@ msgstr "" #: ../source/specifications/binary-distribution-format.rst:482 msgid "Copyright" -msgstr "" +msgstr "Авторське право" #: ../source/specifications/binary-distribution-format.rst:484 msgid "This document has been placed into the public domain." -msgstr "" +msgstr "Цей документ передано у суспільне надбання." #: ../source/specifications/core-metadata.rst:5 msgid "Core metadata specifications" @@ -6654,19 +6656,19 @@ msgstr "" #: ../source/specifications/core-metadata.rst:10 msgid "``Metadata-Version``" -msgstr "" +msgstr "``Metadata-Version``" #: ../source/specifications/core-metadata.rst:11 msgid "``Name``" -msgstr "" +msgstr "``Name``" #: ../source/specifications/core-metadata.rst:12 msgid "``Version``" -msgstr "" +msgstr "``Version``" #: ../source/specifications/core-metadata.rst:14 msgid "All the other fields are optional." -msgstr "" +msgstr "Усі інші поля необов'язкові." #: ../source/specifications/core-metadata.rst:16 msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." @@ -6716,7 +6718,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:620 #: ../source/specifications/core-metadata.rst:630 msgid "Example::" -msgstr "" +msgstr "Приклад::" #: ../source/specifications/core-metadata.rst:66 msgid "Name" @@ -6788,7 +6790,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:164 msgid "Summary" -msgstr "" +msgstr "Підсумок" #: ../source/specifications/core-metadata.rst:168 msgid "A one-line summary of what the distribution does." @@ -6836,23 +6838,23 @@ msgstr "" #: ../source/specifications/core-metadata.rst:259 msgid "Format::" -msgstr "" +msgstr "Формат::" #: ../source/specifications/core-metadata.rst:263 msgid "The ``type/subtype`` part has only a few legal values:" -msgstr "" +msgstr "Частина ``type/subtype`` може містити лише кілька прийнятних значень:" #: ../source/specifications/core-metadata.rst:265 msgid "``text/plain``" -msgstr "" +msgstr "``text/plain``" #: ../source/specifications/core-metadata.rst:266 msgid "``text/x-rst``" -msgstr "" +msgstr "``text/x-rst``" #: ../source/specifications/core-metadata.rst:267 msgid "``text/markdown``" -msgstr "" +msgstr "``text/markdown``" #: ../source/specifications/core-metadata.rst:269 msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." @@ -7184,7 +7186,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:29 #: ../source/specifications/declaring-project-metadata.rst:41 msgid "``name``" -msgstr "" +msgstr "``name``" #: ../source/specifications/declaring-project-metadata.rst:31 msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" @@ -7193,7 +7195,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:34 #: ../source/specifications/declaring-project-metadata.rst:54 msgid "``version``" -msgstr "" +msgstr "``version``" #: ../source/specifications/declaring-project-metadata.rst:36 msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." @@ -7232,7 +7234,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:66 msgid "``description``" -msgstr "" +msgstr "``description``" #: ../source/specifications/declaring-project-metadata.rst:69 msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" @@ -7244,7 +7246,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:76 msgid "``readme``" -msgstr "" +msgstr "``readme``" #: ../source/specifications/declaring-project-metadata.rst:78 msgid "TOML_ type: string or table" @@ -7272,7 +7274,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:115 msgid "``requires-python``" -msgstr "" +msgstr "``requires-python``" #: ../source/specifications/declaring-project-metadata.rst:118 msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" @@ -7284,7 +7286,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:125 msgid "``license``" -msgstr "" +msgstr "``license``" #: ../source/specifications/declaring-project-metadata.rst:127 msgid "TOML_ type: table" @@ -7300,7 +7302,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:140 msgid "``authors``/``maintainers``" -msgstr "" +msgstr "``authors``/``maintainers``" #: ../source/specifications/declaring-project-metadata.rst:142 msgid "TOML_ type: Array of inline tables with string keys and values" @@ -7344,7 +7346,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:181 msgid "``keywords``" -msgstr "" +msgstr "``keywords``" #: ../source/specifications/declaring-project-metadata.rst:183 #: ../source/specifications/declaring-project-metadata.rst:193 @@ -7361,7 +7363,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:191 msgid "``classifiers``" -msgstr "" +msgstr "``classifiers``" #: ../source/specifications/declaring-project-metadata.rst:194 msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" @@ -7373,7 +7375,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:201 msgid "``urls``" -msgstr "" +msgstr "``urls``" #: ../source/specifications/declaring-project-metadata.rst:203 msgid "TOML_ type: table with keys and values of strings" @@ -7417,7 +7419,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:242 msgid "``dependencies``/``optional-dependencies``" -msgstr "" +msgstr "``dependencies``/``optional-dependencies``" #: ../source/specifications/declaring-project-metadata.rst:244 msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" @@ -7441,7 +7443,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:269 msgid "``dynamic``" -msgstr "" +msgstr "``dynamic``" #: ../source/specifications/declaring-project-metadata.rst:271 msgid "TOML_ type: array of string" @@ -7505,7 +7507,7 @@ msgstr "" #: ../source/specifications/direct-url.rst:17 msgid "Specification" -msgstr "" +msgstr "Специфікація" #: ../source/specifications/direct-url.rst:19 msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." @@ -7594,18 +7596,18 @@ msgstr "" #: ../source/specifications/direct-url.rst:122 msgid "Git" -msgstr "" +msgstr "Git" #: ../source/specifications/direct-url.rst:124 #: ../source/specifications/direct-url.rst:156 #: ../source/specifications/direct-url.rst:179 #: ../source/specifications/direct-url.rst:202 msgid "Home page" -msgstr "" +msgstr "Домашня сторінка" #: ../source/specifications/direct-url.rst:126 msgid "https://git-scm.com/" -msgstr "" +msgstr "https://git-scm.com/" #: ../source/specifications/direct-url.rst:128 #: ../source/specifications/direct-url.rst:160 @@ -7617,7 +7619,7 @@ msgstr "" #: ../source/specifications/direct-url.rst:130 #: ../source/specifications/direct-url.rst:134 msgid "git" -msgstr "" +msgstr "git" #: ../source/specifications/direct-url.rst:132 #: ../source/specifications/direct-url.rst:164 @@ -7654,16 +7656,16 @@ msgstr "" #: ../source/specifications/direct-url.rst:154 msgid "Mercurial" -msgstr "" +msgstr "Mercurial" #: ../source/specifications/direct-url.rst:158 msgid "https://www.mercurial-scm.org/" -msgstr "" +msgstr "https://www.mercurial-scm.org/" #: ../source/specifications/direct-url.rst:162 #: ../source/specifications/direct-url.rst:166 msgid "hg" -msgstr "" +msgstr "hg" #: ../source/specifications/direct-url.rst:170 msgid "A tag name, branch name, changeset ID, shortened changeset ID." @@ -7675,16 +7677,16 @@ msgstr "" #: ../source/specifications/direct-url.rst:177 msgid "Bazaar" -msgstr "" +msgstr "Bazaar" #: ../source/specifications/direct-url.rst:181 msgid "https://bazaar.canonical.com/" -msgstr "" +msgstr "https://bazaar.canonical.com/" #: ../source/specifications/direct-url.rst:185 #: ../source/specifications/direct-url.rst:189 msgid "bzr" -msgstr "" +msgstr "bzr" #: ../source/specifications/direct-url.rst:193 msgid "A tag name, branch name, revision id." @@ -7696,16 +7698,16 @@ msgstr "" #: ../source/specifications/direct-url.rst:200 msgid "Subversion" -msgstr "" +msgstr "Subversion" #: ../source/specifications/direct-url.rst:204 msgid "https://subversion.apache.org/" -msgstr "" +msgstr "https://subversion.apache.org/" #: ../source/specifications/direct-url.rst:208 #: ../source/specifications/direct-url.rst:212 msgid "svn" -msgstr "" +msgstr "svn" #: ../source/specifications/direct-url.rst:216 msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." @@ -7745,23 +7747,25 @@ msgstr "" #: ../source/specifications/direct-url.rst:281 msgid "pip install https://example.com/app-1.0.tgz" -msgstr "" +msgstr "pip install https://example.com/app-1.0.tgz" #: ../source/specifications/direct-url.rst:282 msgid "pip install https://example.com/app-1.0.whl" -msgstr "" +msgstr "pip install https://example.com/app-1.0.whl" #: ../source/specifications/direct-url.rst:283 msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" msgstr "" +"pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=" +"setup\"" #: ../source/specifications/direct-url.rst:284 msgid "pip install ./app" -msgstr "" +msgstr "pip install ./app" #: ../source/specifications/direct-url.rst:285 msgid "pip install file:///home/user/app" -msgstr "" +msgstr "pip install file:///home/user/app" #: ../source/specifications/direct-url.rst:286 msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" @@ -7769,7 +7773,7 @@ msgstr "" #: ../source/specifications/direct-url.rst:290 msgid "pip install -e ./app" -msgstr "" +msgstr "pip install -e ./app" #: ../source/specifications/direct-url.rst:292 msgid "Commands that *do not* generate a ``direct_url.json``" @@ -7777,11 +7781,11 @@ msgstr "" #: ../source/specifications/direct-url.rst:294 msgid "pip install app" -msgstr "" +msgstr "pip install app" #: ../source/specifications/direct-url.rst:295 msgid "pip install app --no-index --find-links https://example.com/" -msgstr "" +msgstr "pip install app --no-index --find-links https://example.com/" #: ../source/specifications/entry-points.rst:5 msgid "Entry points specification" @@ -7805,7 +7809,7 @@ msgstr "" #: ../source/specifications/entry-points.rst:28 msgid "Data model" -msgstr "" +msgstr "Модель даних" #: ../source/specifications/entry-points.rst:30 msgid "Conceptually, an entry point is defined by three required properties:" @@ -7861,7 +7865,7 @@ msgstr "" #: ../source/specifications/entry-points.rst:112 msgid "For example::" -msgstr "" +msgstr "Наприклад::" #: ../source/specifications/entry-points.rst:124 msgid "Use for scripts" @@ -7889,7 +7893,7 @@ msgstr "" #: ../source/specifications/index.rst:4 msgid "PyPA specifications" -msgstr "" +msgstr "Специфікації PyPA" #: ../source/specifications/index.rst:6 msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." @@ -7993,59 +7997,59 @@ msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:83 msgid "Tool" -msgstr "" +msgstr "Інструмент" #: ../source/specifications/platform-compatibility-tags.rst:83 msgid "``manylinux1``" -msgstr "" +msgstr "``manylinux1``" #: ../source/specifications/platform-compatibility-tags.rst:83 msgid "``manylinux2010``" -msgstr "" +msgstr "``manylinux2010``" #: ../source/specifications/platform-compatibility-tags.rst:83 msgid "``manylinux2014``" -msgstr "" +msgstr "``manylinux2014``" #: ../source/specifications/platform-compatibility-tags.rst:83 msgid "``manylinux_x_y``" -msgstr "" +msgstr "``manylinux_x_y``" #: ../source/specifications/platform-compatibility-tags.rst:85 msgid "``>=8.1.0``" -msgstr "" +msgstr "``>=8.1.0``" #: ../source/specifications/platform-compatibility-tags.rst:85 msgid "``>=19.0``" -msgstr "" +msgstr "``>=19.0``" #: ../source/specifications/platform-compatibility-tags.rst:85 msgid "``>=19.3``" -msgstr "" +msgstr "``>=19.3``" #: ../source/specifications/platform-compatibility-tags.rst:85 msgid "``>=20.3``" -msgstr "" +msgstr "``>=20.3``" #: ../source/specifications/platform-compatibility-tags.rst:86 msgid "auditwheel" -msgstr "" +msgstr "auditwheel" #: ../source/specifications/platform-compatibility-tags.rst:86 msgid "``>=1.0.0``" -msgstr "" +msgstr "``>=1.0.0``" #: ../source/specifications/platform-compatibility-tags.rst:86 msgid "``>=2.0.0``" -msgstr "" +msgstr "``>=2.0.0``" #: ../source/specifications/platform-compatibility-tags.rst:86 msgid "``>=3.0.0``" -msgstr "" +msgstr "``>=3.0.0``" #: ../source/specifications/platform-compatibility-tags.rst:86 msgid "``>=3.3.0`` [#]_" -msgstr "" +msgstr "``>=3.3.0`` [#]_" #: ../source/specifications/platform-compatibility-tags.rst:90 msgid "Platform tags for other \\*nix platforms" @@ -8061,7 +8065,7 @@ msgstr "" #: ../source/specifications/pypirc.rst:6 msgid "The :file:`.pypirc` file" -msgstr "" +msgstr "Файл :file:`.pypirc`" #: ../source/specifications/pypirc.rst:8 msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." @@ -8209,7 +8213,7 @@ msgstr "" #: ../source/specifications/recording-installed-packages.rst:94 msgid "The METADATA file" -msgstr "" +msgstr "Файл METADATA" #: ../source/specifications/recording-installed-packages.rst:96 msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." @@ -8221,7 +8225,7 @@ msgstr "" #: ../source/specifications/recording-installed-packages.rst:105 msgid "The RECORD file" -msgstr "" +msgstr "Файл RECORD" #: ../source/specifications/recording-installed-packages.rst:107 msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." @@ -8281,7 +8285,7 @@ msgstr "" #: ../source/specifications/recording-installed-packages.rst:177 msgid "The INSTALLER file" -msgstr "" +msgstr "Файл INSTALLER" #: ../source/specifications/recording-installed-packages.rst:179 msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." @@ -8850,7 +8854,7 @@ msgstr "" #: ../source/tutorials/managing-dependencies.rst:143 #: ../source/tutorials/packaging-projects.rst:594 msgid "Next steps" -msgstr "" +msgstr "Наступні кроки" #: ../source/tutorials/managing-dependencies.rst:145 msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" From b939ed9fd82673a2be422f1fdc886970569dafb3 Mon Sep 17 00:00:00 2001 From: Alex Solonenko Date: Sun, 29 Aug 2021 18:15:33 +0200 Subject: [PATCH 0083/1072] Translated using Weblate (Ukrainian) Currently translated at 13.4% (305 of 2271 strings) Co-authored-by: Alex Solonenko Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/uk/ Translation: pypa/packaging.python.org --- locales/uk/LC_MESSAGES/messages.po | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/locales/uk/LC_MESSAGES/messages.po b/locales/uk/LC_MESSAGES/messages.po index 839467465..fb32b548d 100644 --- a/locales/uk/LC_MESSAGES/messages.po +++ b/locales/uk/LC_MESSAGES/messages.po @@ -1,15 +1,14 @@ # SOME DESCRIPTIVE TITLE. # Copyright (C) 2013–2020, PyPA # This file is distributed under the same license as the Python Packaging User Guide package. -# FIRST AUTHOR , YEAR. -# +# Alex Solonenko , 2021. msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-07-16 10:46+0000\n" -"Last-Translator: Sviatoslav Sydorenko \n" +"PO-Revision-Date: 2021-07-16 11:12+0000\n" +"Last-Translator: Alex Solonenko \n" "Language-Team: Ukrainian \n" "Language: uk\n" @@ -9247,14 +9246,24 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:610 msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." msgstr "" +"Зареєструйте обліковий запис на https://pypi.org - зверніть увагу, що це два " +"окремих сервери, а дані для входу з тестового сервера не поширюються з " +"основним сервером." #: ../source/tutorials/packaging-projects.rst:613 msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." msgstr "" +"Використовуйте `` dist upload upload / * '', щоб опублікувати ваш пакунок і " +"ввести ваші облікові дані для облікового запису, який ви зареєстрували на " +"реальному PyPI. Тепер, коли ви публікуєте пакунок як продакшн-версію, вам не " +"потрібно вказувати `` --repository``; пакунок буде опубліковано на " +"https://pypi.org/ за замовчуванням." #: ../source/tutorials/packaging-projects.rst:617 msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." msgstr "" +"Встановіть ваш пакунок з PyPI за допомогою``python3 -m pip install [your-" +"package]``." #: ../source/tutorials/packaging-projects.rst:619 msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" From 0b230632cc93c4c991b611d851f8b1000a310dc5 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Sun, 29 Aug 2021 18:15:34 +0200 Subject: [PATCH 0084/1072] Translated using Weblate (Ukrainian) Currently translated at 13.4% (305 of 2271 strings) Co-authored-by: Sviatoslav Sydorenko Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/uk/ Translation: pypa/packaging.python.org --- locales/uk/LC_MESSAGES/messages.po | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/locales/uk/LC_MESSAGES/messages.po b/locales/uk/LC_MESSAGES/messages.po index fb32b548d..086bb90a4 100644 --- a/locales/uk/LC_MESSAGES/messages.po +++ b/locales/uk/LC_MESSAGES/messages.po @@ -2,13 +2,14 @@ # Copyright (C) 2013–2020, PyPA # This file is distributed under the same license as the Python Packaging User Guide package. # Alex Solonenko , 2021. +# Sviatoslav Sydorenko , 2021. msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" "PO-Revision-Date: 2021-07-16 11:12+0000\n" -"Last-Translator: Alex Solonenko \n" +"Last-Translator: Sviatoslav Sydorenko \n" "Language-Team: Ukrainian \n" "Language: uk\n" @@ -31,7 +32,7 @@ msgstr "" #: ../source/contribute.rst:10 msgid "Reading the guide and giving feedback" -msgstr "Читання гайду і надання відгуку" +msgstr "Читання керівництва і надання відгуку" #: ../source/contribute.rst:11 msgid "Reviewing new contributions" @@ -9268,8 +9269,8 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:619 msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" msgstr "" -"Якшо ви хочете прочитати більше про пакування Python бібліотек, то ось, що " -"ви можете зробити:" +"На цьому етапі, якшо ви бажаєте почитати більше про пакування Python-" +"бібліотек, то ось що ви можете зробити:" #: ../source/tutorials/packaging-projects.rst:622 msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." @@ -9285,4 +9286,4 @@ msgstr "Прочитайте про :doc:`/guides/packaging-binary-extensions`." msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." msgstr "" "Розгляньте альтернативи до :ref:`setuptools` такі як :ref:`flit`, " -":ref:`hatch`, і :ref:`poetry`." +":ref:`hatch` і :ref:`poetry`." From b020b9866ee11f0db2e2709dd3dafd1bf10acdc0 Mon Sep 17 00:00:00 2001 From: Hosted Weblate Date: Sun, 29 Aug 2021 18:15:35 +0200 Subject: [PATCH 0085/1072] Update translation files Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. Co-authored-by: Hosted Weblate Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/ Translation: pypa/packaging.python.org --- locales/eo/LC_MESSAGES/messages.po | 6879 +++++++++++++++++----- locales/pt_BR/LC_MESSAGES/messages.po | 6892 +++++++++++++++++----- locales/uk/LC_MESSAGES/messages.po | 6863 +++++++++++++++++----- locales/zh_Hans/LC_MESSAGES/messages.po | 7061 ++++++++++++++++++----- locales/zh_Hant/LC_MESSAGES/messages.po | 6857 +++++++++++++++++----- 5 files changed, 28004 insertions(+), 6548 deletions(-) diff --git a/locales/eo/LC_MESSAGES/messages.po b/locales/eo/LC_MESSAGES/messages.po index d29a4a6b0..21e2d23bb 100644 --- a/locales/eo/LC_MESSAGES/messages.po +++ b/locales/eo/LC_MESSAGES/messages.po @@ -9,8 +9,8 @@ msgstr "" "POT-Creation-Date: 2021-07-06 19:32+0800\n" "PO-Revision-Date: 2021-07-16 11:12+0000\n" "Last-Translator: phlostically \n" -"Language-Team: Esperanto \n" +"Language-Team: Esperanto \n" "Language: eo\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -23,7 +23,9 @@ msgid "Contribute to this guide" msgstr "Kontribui al ĉi tiu gvidilo" #: ../source/contribute.rst:7 -msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" +msgid "" +"The |PyPUG| welcomes contributors! There are lots of ways to help out, " +"including:" msgstr "" #: ../source/contribute.rst:10 @@ -43,11 +45,17 @@ msgid "Writing new content" msgstr "Verki novan enhavon" #: ../source/contribute.rst:15 -msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." +msgid "" +"Most of the work on the |PyPUG| takes place on the `project's GitHub " +"repository`__. To get started, check out the list of `open issues`__ and " +"`pull requests`__. If you're planning to write or edit the guide, please " +"read the :ref:`style guide `." msgstr "" #: ../source/contribute.rst:24 -msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." +msgid "" +"By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of " +"Conduct`__." msgstr "" #: ../source/contribute.rst:31 @@ -55,34 +63,46 @@ msgid "Documentation types" msgstr "Tipoj de dokumentaro" #: ../source/contribute.rst:33 -msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." +msgid "" +"This project consists of four distinct documentation types with specific " +"purposes. When proposing new additions to the project please pick the " +"appropriate documentation type." msgstr "" -#: ../source/contribute.rst:38 -#: ../source/tutorials/index.rst:2 +#: ../source/contribute.rst:38 ../source/tutorials/index.rst:2 msgid "Tutorials" msgstr "Lerniloj" #: ../source/contribute.rst:40 -msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." +msgid "" +"Tutorials are focused on teaching the reader new concepts by accomplishing a " +"goal. They are opinionated step-by-step guides. They do not include " +"extraneous warnings or information. `example tutorial-style document`_." msgstr "" -#: ../source/contribute.rst:47 -#: ../source/guides/index.rst:2 +#: ../source/contribute.rst:47 ../source/guides/index.rst:2 msgid "Guides" msgstr "Gvidiloj" #: ../source/contribute.rst:49 -msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." +msgid "" +"Guides are focused on accomplishing a specific task and can assume some " +"level of pre-requisite knowledge. These are similar to tutorials, but have a " +"narrow and clear focus and can provide lots of caveats and additional " +"information as needed. They may also discuss multiple approaches to " +"accomplishing the task. :doc:`example guide-style document `." msgstr "" -#: ../source/contribute.rst:56 -#: ../source/discussions/index.rst:2 +#: ../source/contribute.rst:56 ../source/discussions/index.rst:2 msgid "Discussions" msgstr "Diskutoj" #: ../source/contribute.rst:58 -msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." +msgid "" +"Discussions are focused on understanding and information. These explore a " +"specific topic without a specific goal in mind. :doc:`example discussion-" +"style document `." msgstr "" #: ../source/contribute.rst:63 @@ -90,7 +110,11 @@ msgid "Specifications" msgstr "Specifiloj" #: ../source/contribute.rst:65 -msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." +msgid "" +"Specifications are reference documention focused on comprehensively " +"documenting an agreed-upon interface for interoperability between packaging " +"tools. :doc:`example specification-style document `." msgstr "" #: ../source/contribute.rst:73 @@ -98,29 +122,44 @@ msgid "Building the guide locally" msgstr "" #: ../source/contribute.rst:75 -msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" +msgid "" +"Though not required to contribute, it may be useful to build this guide " +"locally in order to test your changes. In order to build this guide locally, " +"you'll need:" msgstr "" #: ../source/contribute.rst:79 -msgid "`Nox `_. You can install or upgrade nox using ``pip``::" +msgid "" +"`Nox `_. You can install or upgrade " +"nox using ``pip``::" msgstr "" "`Nox `_. Vi povas instali aŭ " "ĝisdatigi nox per ``pip``::" #: ../source/contribute.rst:84 -msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." +msgid "" +"Python 3.6. Our build scripts are designed to work with Python 3.6 only. See " +"the `Hitchhiker's Guide to Python installation instructions`_ to install " +"Python 3.6 on your operating system." msgstr "" #: ../source/contribute.rst:91 -msgid "To build the guide, run the following bash command in the source folder::" +msgid "" +"To build the guide, run the following bash command in the source folder::" msgstr "" #: ../source/contribute.rst:95 -msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." +msgid "" +"After the process has completed you can find the HTML output in the ``./" +"build/html`` directory. You can open the ``index.html`` file to view the " +"guide in web browser, but it's recommended to serve the guide using an HTTP " +"server." msgstr "" #: ../source/contribute.rst:100 -msgid "You can build the guide and serve it via an HTTP server using the following command::" +msgid "" +"You can build the guide and serve it via an HTTP server using the following " +"command::" msgstr "" #: ../source/contribute.rst:105 @@ -132,7 +171,10 @@ msgid "Where the guide is deployed" msgstr "" #: ../source/contribute.rst:111 -msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." +msgid "" +"The guide is deployed via ReadTheDocs and the configuration lives at https://" +"readthedocs.org/projects/python-packaging-user-guide/. It's served from a " +"custom domain and fronted by Fast.ly." msgstr "" #: ../source/contribute.rst:117 @@ -140,7 +182,11 @@ msgid "Style guide" msgstr "Rekomendoj pri stilo" #: ../source/contribute.rst:119 -msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." +msgid "" +"This style guide has recommendations for how you should write the |PyPUG|. " +"Before you start writing, please review it. By following the style guide, " +"your contributions will help add to a cohesive whole and make it easier for " +"your contributions to be accepted into the project." msgstr "" #: ../source/contribute.rst:126 @@ -148,7 +194,9 @@ msgid "Purpose" msgstr "Celo" #: ../source/contribute.rst:128 -msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." +msgid "" +"The purpose of the |PyPUG| is to be the authoritative resource on how to " +"package, publish, and install Python projects using current tools." msgstr "" #: ../source/contribute.rst:133 @@ -156,11 +204,18 @@ msgid "Scope" msgstr "Amplekso" #: ../source/contribute.rst:135 -msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." +msgid "" +"The guide is meant to answer questions and solve problems with accurate and " +"focused recommendations." msgstr "" #: ../source/contribute.rst:138 -msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." +msgid "" +"The guide isn't meant to be comprehensive and it's not meant to replace " +"individual projects' documentation. For example, pip has dozens of commands, " +"options, and settings. The pip documentation describes each of them in " +"detail, while this guide describes only the parts of pip that are needed to " +"complete the specific tasks described in this guide." msgstr "" #: ../source/contribute.rst:146 @@ -172,11 +227,17 @@ msgid "The audience of this guide is anyone who uses Python with packages." msgstr "" #: ../source/contribute.rst:150 -msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." +msgid "" +"Don't forget that the Python community is big and welcoming. Readers may not " +"share your age, gender, education, culture, and more, but they deserve to " +"learn about packaging just as much as you do." msgstr "" #: ../source/contribute.rst:154 -msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." +msgid "" +"In particular, keep in mind that not all people who use Python see " +"themselves as programmers. The audience of this guide includes astronomers " +"or painters or students as well as professional software developers." msgstr "" #: ../source/contribute.rst:160 @@ -184,19 +245,35 @@ msgid "Voice and tone" msgstr "Voĉo kaj tono" #: ../source/contribute.rst:162 -msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." +msgid "" +"When writing this guide, strive to write with a voice that's approachable " +"and humble, even if you have all the answers." msgstr "" #: ../source/contribute.rst:165 -msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." +msgid "" +"Imagine you're working on a Python project with someone you know to be smart " +"and skilled. You like working with them and they like working with you. That " +"person has asked you a question and you know the answer. How do you respond? " +"*That* is how you should write this guide." msgstr "" #: ../source/contribute.rst:170 -msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." +msgid "" +"Here's a quick check: try reading aloud to get a sense for your writing's " +"voice and tone. Does it sound like something you would say or does it sound " +"like you're acting out a part or giving a speech? Feel free to use " +"contractions and don't worry about sticking to fussy grammar rules. You are " +"hereby granted permission to end a sentence in a preposition, if that's what " +"you want to end it with." msgstr "" #: ../source/contribute.rst:177 -msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." +msgid "" +"When writing the guide, adjust your tone for the seriousness and difficulty " +"of the topic. If you're writing an introductory tutorial, it's OK to make a " +"joke, but if you're covering a sensitive security recommendation, you might " +"want to avoid jokes altogether." msgstr "" #: ../source/contribute.rst:184 @@ -208,7 +285,9 @@ msgid "**Write to the reader**" msgstr "" #: ../source/contribute.rst:187 -msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." +msgid "" +"When giving recommendations or steps to take, address the reader as *you* or " +"use the imperative mood." msgstr "" #: ../source/contribute.rst:0 @@ -228,7 +307,11 @@ msgid "**State assumptions**" msgstr "**Klarigu supozojn**" #: ../source/contribute.rst:195 -msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." +msgid "" +"Avoid making unstated assumptions. Reading on the web means that any page of " +"the guide may be the first page of the guide that the reader ever sees. If " +"you're going to make assumptions, then say what assumptions that you're " +"going to make." msgstr "" #: ../source/contribute.rst:203 @@ -236,7 +319,10 @@ msgid "**Cross-reference generously**" msgstr "**Interreferencu ofte**" #: ../source/contribute.rst:201 -msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." +msgid "" +"The first time you mention a tool or practice, link to the part of the guide " +"that covers it, or link to a relevant document elsewhere. Save the reader a " +"search." msgstr "" #: ../source/contribute.rst:213 @@ -244,7 +330,9 @@ msgid "**Respect naming practices**" msgstr "**Respektu nomojn**" #: ../source/contribute.rst:206 -msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." +msgid "" +"When naming tools, sites, people, and other proper nouns, use their " +"preferred capitalization." msgstr "" #: ../source/contribute.rst:0 @@ -268,7 +356,10 @@ msgid "**Use a gender-neutral style**" msgstr "**Uzu seksneŭtralan stilon**" #: ../source/contribute.rst:216 -msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." +msgid "" +"Often, you'll address the reader directly with *you*, *your* and *yours*. " +"Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or " +"avoid pronouns entirely." msgstr "" "Ofte vi rekte alparolu la leganton per *vi*, *vin* aŭ *via*. Alie, uzu " "seksneŭtralajn pronomojn *ili*, *ŝ/li* aŭ entute evitu pronomojn." @@ -290,11 +381,17 @@ msgid "**Headings**" msgstr "**Titoloj de paragrafoj**" #: ../source/contribute.rst:225 -msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." +msgid "" +"Write headings that use words the reader is searching for. A good way to do " +"this is to have your heading complete an implied question. For example, a " +"reader might want to know *How do I install MyLibrary?* so a good heading " +"might be *Install MyLibrary*." msgstr "" #: ../source/contribute.rst:230 -msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." +msgid "" +"In section headings, use sentence case. In other words, write headings as " +"you would write a typical sentence." msgstr "" #: ../source/contribute.rst:0 @@ -310,7 +407,9 @@ msgid "**Numbers**" msgstr "**Nombroj**" #: ../source/contribute.rst:237 -msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." +msgid "" +"In body text, write numbers one through nine as words. For other numbers or " +"numbers in tables, use numerals." msgstr "" #: ../source/discussions/deploying-python-applications.rst:4 @@ -357,8 +456,7 @@ msgstr "2014-11-11" #: ../source/guides/packaging-binary-extensions.rst:17 #: ../source/guides/supporting-multiple-python-versions.rst:12 #: ../source/guides/supporting-windows-using-appveyor.rst:15 -#: ../source/overview.rst:23 -#: ../source/specifications/core-metadata.rst:38 +#: ../source/overview.rst:23 ../source/specifications/core-metadata.rst:38 #: ../source/specifications/direct-url.rst:14 #: ../source/tutorials/installing-packages.rst:23 msgid "Contents" @@ -385,15 +483,29 @@ msgid "Pynsist" msgstr "Pynsist" #: ../source/discussions/deploying-python-applications.rst:63 -msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." +msgid "" +"`Pynsist `__ is a tool that bundles Python " +"programs together with the Python-interpreter into a single installer based " +"on NSIS. In most cases, packaging only requires the user to choose a version " +"of the Python-interpreter and declare the dependencies of the program. The " +"tool downloads the specified Python-interpreter for Windows and packages it " +"with all the dependencies in a single Windows-executable installer." msgstr "" #: ../source/discussions/deploying-python-applications.rst:70 -msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." +msgid "" +"The installed program can be started from a shortcut that the installer adds " +"to the start-menu. It uses a Python interpreter installed within its " +"application directory, independent of any other Python installation on the " +"computer." msgstr "" #: ../source/discussions/deploying-python-applications.rst:74 -msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." +msgid "" +"A big advantage of Pynsist is that the Windows packages can be built on " +"Linux. There are several examples for different kinds of programs (console, " +"GUI) in the `documentation `__. The tool is " +"released under the MIT-licence." msgstr "" #: ../source/discussions/deploying-python-applications.rst:80 @@ -405,7 +517,10 @@ msgid "Configuration management" msgstr "" #: ../source/discussions/index.rst:4 -msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." +msgid "" +"**Discussions** are focused on providing comprehensive information about a " +"specific topic. If you're just trying to get stuff done, see :doc:`/guides/" +"index`." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:5 @@ -418,31 +533,52 @@ msgid "install_requires" msgstr "install_requires" #: ../source/discussions/install-requires-vs-requirements.rst:14 -msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgid "" +"``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that " +"should be used to specify what a project **minimally** needs to run " +"correctly. When the project is installed by :ref:`pip`, this is the " +"specification that is used to install its dependencies." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:19 -msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" +msgid "" +"For example, if the project requires A and B, your ``install_requires`` " +"would be like so:" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:29 -msgid "Additionally, it's best practice to indicate any known lower or upper bounds." +msgid "" +"Additionally, it's best practice to indicate any known lower or upper bounds." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:31 -msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" +msgid "" +"For example, it may be known, that your project requires at least v1 of 'A', " +"and v2 of 'B', so it would be like so:" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:41 -msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" +msgid "" +"It may also be known that project A follows semantic versioning, and that v2 " +"of 'A' will indicate a break in compatibility, so it makes sense to not " +"allow v2:" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:51 -msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." +msgid "" +"It is not considered best practice to use ``install_requires`` to pin " +"dependencies to specific versions, or to specify sub-dependencies (i.e. " +"dependencies of your dependencies). This is overly-restrictive, and " +"prevents the user from gaining the benefit of dependency upgrades." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:56 -msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" +msgid "" +"Lastly, it's important to understand that ``install_requires`` is a listing " +"of \"Abstract\" requirements, i.e just names and version restrictions that " +"don't determine where the dependencies will be fulfilled from (i.e. from " +"what index or source). The where (i.e. how they are to be made \"Concrete" +"\") is to be determined at install time using :ref:`pip` options. [1]_" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:64 @@ -451,27 +587,46 @@ msgid "Requirements files" msgstr "Dosiero requirements.txt" #: ../source/discussions/install-requires-vs-requirements.rst:66 -msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." +msgid "" +":ref:`Requirements Files ` described most simply, " +"are just a list of :ref:`pip:pip install` arguments placed into a file." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:69 -msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." +msgid "" +"Whereas ``install_requires`` defines the dependencies for a single project, :" +"ref:`Requirements Files ` are often used to define " +"the requirements for a complete Python environment." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:73 -msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." +msgid "" +"Whereas ``install_requires`` requirements are minimal, requirements files " +"often contain an exhaustive listing of pinned versions for the purpose of " +"achieving :ref:`repeatable installations ` of a complete " +"environment." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:78 -msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" +msgid "" +"Whereas ``install_requires`` requirements are \"Abstract\", i.e. not " +"associated with any particular index, requirements files often contain pip " +"options like ``--index-url`` or ``--find-links`` to make requirements " +"\"Concrete\", i.e. associated with a particular index or directory of " +"packages. [1]_" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:84 -msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." +msgid "" +"Whereas ``install_requires`` metadata is automatically analyzed by pip " +"during an install, requirements files are not, and only are used when a user " +"specifically installs them using ``python -m pip install -r``." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:90 -msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." +msgid "" +"For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad." +"io/2013/07/setup-vs-requirement/." msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:6 @@ -479,15 +634,29 @@ msgid "pip vs easy_install" msgstr "pip kontraste kun easy_install" #: ../source/discussions/pip-vs-easy-install.rst:9 -msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." +msgid "" +":ref:`easy_install `, now `deprecated`_, was released in 2004 " +"as part of :ref:`setuptools`. It was notable at the time for installing :" +"term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing " +"dependencies." msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:14 -msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." +msgid "" +":ref:`pip` came later in 2008, as alternative to :ref:`easy_install " +"`, although still largely built on top of :ref:`setuptools` " +"components. It was notable at the time for *not* installing packages as :" +"term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' " +"packages from :term:`sdists `), and " +"introducing the idea of :ref:`Requirements Files `, " +"which gave users the power to easily replicate environments." msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:22 -msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" +msgid "" +"Here's a breakdown of the important differences between pip and the " +"deprecated easy_install:" msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:25 @@ -601,7 +770,9 @@ msgid "Yes, via setup.cfg" msgstr "Jes, per setup.cfg" #: ../source/discussions/pip-vs-easy-install.rst:68 -msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" +msgid "" +"https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" +"launcher" msgstr "" "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" "launcher" @@ -611,19 +782,28 @@ msgid "Wheel vs Egg" msgstr "Wheel kontraste kun Egg" #: ../source/discussions/wheel-vs-egg.rst:7 -msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." +msgid "" +":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support " +"the use case of needing an install artifact that doesn't require building or " +"compilation, which can be costly in testing and production workflows." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:11 -msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." +msgid "" +"The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas " +"the :term:`Wheel` format was introduced by :pep:`427` in 2012." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:14 -msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." +msgid "" +":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:17 -msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." +msgid "" +"Here's a breakdown of the important differences between :term:`Wheel` and :" +"term:`Egg`." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:20 @@ -631,31 +811,53 @@ msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:22 -msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." +msgid "" +":term:`Wheel` is a :term:`distribution ` format, i.e a " +"packaging format. [1]_ :term:`Egg` was both a distribution format and a " +"runtime installation format (if left zipped), and was designed to be " +"importable." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:26 -msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." +msgid "" +":term:`Wheel` archives do not include .pyc files. Therefore, when the " +"distribution only contains Python files (i.e. no compiled extensions), and " +"is compatible with Python 2 and 3, it's possible for a wheel to be " +"\"universal\", similar to an :term:`sdist `." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:31 -msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." +msgid "" +":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. " +"Egg used ``.egg-info``." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:34 -msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." +msgid "" +":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single " +"wheel archive can indicate its compatibility with a number of Python " +"language versions and implementations, ABIs, and system architectures." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:38 -msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." +msgid "" +":term:`Wheel` is versioned. Every wheel file contains the version of the " +"wheel specification and the implementation that packaged it." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:41 -msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." +msgid "" +":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making " +"it easier to convert to other formats." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:47 -msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." +msgid "" +"Circumstantially, in some cases, wheels can be used as an importable runtime " +"format, although :pep:`this is not officially supported at this time <427#is-" +"it-possible-to-import-python-code-directly-from-a-wheel-file>`." msgstr "" #: ../source/glossary.rst:3 @@ -667,7 +869,9 @@ msgid "Binary Distribution" msgstr "" #: ../source/glossary.rst:11 -msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." +msgid "" +"A specific kind of :term:`Built Distribution` that contains compiled " +"extensions." msgstr "" #: ../source/glossary.rst:14 @@ -675,7 +879,14 @@ msgid "Built Distribution" msgstr "" #: ../source/glossary.rst:17 -msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." +msgid "" +"A :term:`Distribution ` format containing files and " +"metadata that only need to be moved to the correct location on the target " +"system, to be installed. :term:`Wheel` is such a format, whereas distutil's :" +"term:`Source Distribution ` is not, in " +"that it requires a build step before it can be installed. This format does " +"not imply that Python files have to be precompiled (:term:`Wheel` " +"intentionally does not include compiled Python files)." msgstr "" #: ../source/glossary.rst:26 @@ -683,11 +894,22 @@ msgid "Distribution Package" msgstr "" #: ../source/glossary.rst:29 -msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." +msgid "" +"A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used " +"to distribute a :term:`Release`. The archive file is what an end-user will " +"download from the internet and install." msgstr "" #: ../source/glossary.rst:34 -msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." +msgid "" +"A distribution package is more commonly referred to with the single words " +"\"package\" or \"distribution\", but this guide may use the expanded term " +"when more clarity is needed to prevent confusion with an :term:`Import " +"Package` (which is also commonly called a \"package\") or another kind of " +"distribution (e.g. a Linux distribution or the Python language " +"distribution), which are often referred to with the single term " +"\"distribution\"." msgstr "" #: ../source/glossary.rst:41 @@ -695,7 +917,12 @@ msgid "Egg" msgstr "Egg" #: ../source/glossary.rst:44 -msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" +msgid "" +"A :term:`Built Distribution` format introduced by :ref:`setuptools`, which " +"is being replaced by :term:`Wheel`. For details, see `The Internal " +"Structure of Python Eggs `_ and `Python Eggs `_" msgstr "" #: ../source/glossary.rst:49 @@ -703,7 +930,12 @@ msgid "Extension Module" msgstr "" #: ../source/glossary.rst:52 -msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." +msgid "" +"A :term:`Module` written in the low-level language of the Python " +"implementation: C/C++ for Python, Java for Jython. Typically contained in a " +"single dynamically loadable pre-compiled file, e.g. a shared object (.so) " +"file for Python extensions on Unix, a DLL (given the .pyd extension) for " +"Python extensions on Windows, or a Java class file for Jython extensions." msgstr "" #: ../source/glossary.rst:59 @@ -711,7 +943,12 @@ msgid "Known Good Set (KGS)" msgstr "" #: ../source/glossary.rst:62 -msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." +msgid "" +"A set of distributions at specified versions which are compatible with each " +"other. Typically a test suite will be run which passes all tests before a " +"specific set of packages is declared a known good set. This term is commonly " +"used by frameworks and toolkits which are comprised of multiple individual " +"distributions." msgstr "" #: ../source/glossary.rst:68 @@ -719,11 +956,17 @@ msgid "Import Package" msgstr "" #: ../source/glossary.rst:71 -msgid "A Python module which can contain other modules or recursively, other packages." +msgid "" +"A Python module which can contain other modules or recursively, other " +"packages." msgstr "" #: ../source/glossary.rst:74 -msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." +msgid "" +"An import package is more commonly referred to with the single word \"package" +"\", but this guide will use the expanded term when more clarity is needed to " +"prevent confusion with a :term:`Distribution Package` which is also commonly " +"called a \"package\"." msgstr "" #: ../source/glossary.rst:78 @@ -731,7 +974,9 @@ msgid "Module" msgstr "Modulo" #: ../source/glossary.rst:81 -msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." +msgid "" +"The basic unit of code reusability in Python, existing in one of two types: :" +"term:`Pure Module`, or :term:`Extension Module`." msgstr "" #: ../source/glossary.rst:84 @@ -739,7 +984,9 @@ msgid "Package Index" msgstr "" #: ../source/glossary.rst:87 -msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." +msgid "" +"A repository of distributions with a web interface to automate :term:" +"`package ` discovery and consumption." msgstr "" #: ../source/glossary.rst:90 @@ -747,7 +994,10 @@ msgid "Per Project Index" msgstr "" #: ../source/glossary.rst:93 -msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." +msgid "" +"A private or other non-canonical :term:`Package Index` indicated by a " +"specific :term:`Project` as the index preferred or required to resolve " +"dependencies of that project." msgstr "" #: ../source/glossary.rst:97 @@ -755,19 +1005,35 @@ msgid "Project" msgstr "Projekto" #: ../source/glossary.rst:100 -msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." +msgid "" +"A library, framework, script, plugin, application, or collection of data or " +"other resources, or some combination thereof that is intended to be packaged " +"into a :term:`Distribution `." msgstr "" #: ../source/glossary.rst:104 -msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." +msgid "" +"Since most projects create :term:`Distributions ` " +"using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:" +"`setuptools`, another practical way to define projects currently is " +"something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:" +"`setup.cfg` file at the root of the project source directory." msgstr "" #: ../source/glossary.rst:110 -msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." +msgid "" +"Python projects must have unique names, which are registered on :term:`PyPI " +"`. Each project will then contain one or more :" +"term:`Releases `, and each release may comprise one or more :term:" +"`distributions `." msgstr "" #: ../source/glossary.rst:115 -msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." +msgid "" +"Note that there is a strong convention to name a project after the name of " +"the package that is imported to run that project. However, this doesn't have " +"to hold true. It's possible to install a distribution from the project 'foo' " +"and have it provide a package importable only as 'bar'." msgstr "" #: ../source/glossary.rst:121 @@ -775,7 +1041,9 @@ msgid "Pure Module" msgstr "Pura Modulo" #: ../source/glossary.rst:124 -msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." +msgid "" +"A :term:`Module` written in Python and contained in a single ``.py`` file " +"(and possibly associated ``.pyc`` and/or ``.pyo`` files)." msgstr "" #: ../source/glossary.rst:127 @@ -783,7 +1051,13 @@ msgid "Python Packaging Authority (PyPA)" msgstr "" #: ../source/glossary.rst:130 -msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." +msgid "" +"PyPA is a working group that maintains many of the relevant projects in " +"Python packaging. They maintain a site at https://www.pypa.io, host projects " +"on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python " +"Discourse forum `__." msgstr "" #: ../source/glossary.rst:139 @@ -791,7 +1065,10 @@ msgid "Python Package Index (PyPI)" msgstr "" #: ../source/glossary.rst:142 -msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." +msgid "" +"`PyPI `_ is the default :term:`Package Index` for the " +"Python community. It is open to all Python developers to consume and " +"distribute their distributions." msgstr "" #: ../source/glossary.rst:145 @@ -799,7 +1076,10 @@ msgid "pypi.org" msgstr "pypi.org" #: ../source/glossary.rst:148 -msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." +msgid "" +"`pypi.org `_ is the domain name for the :term:`Python " +"Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi." +"python.org``, in 2017. It is powered by :ref:`warehouse`." msgstr "" #: ../source/glossary.rst:152 @@ -807,7 +1087,8 @@ msgid "pyproject.toml" msgstr "pyproject.toml" #: ../source/glossary.rst:155 -msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." +msgid "" +"The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." msgstr "" #: ../source/glossary.rst:157 @@ -815,11 +1096,17 @@ msgid "Release" msgstr "" #: ../source/glossary.rst:160 -msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." +msgid "" +"A snapshot of a :term:`Project` at a particular point in time, denoted by a " +"version identifier." msgstr "" #: ../source/glossary.rst:163 -msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." +msgid "" +"Making a release may entail the publishing of multiple :term:`Distributions " +"`. For example, if version 1.0 of a project was " +"released, it could be available in both a source distribution format and a " +"Windows installer distribution format." msgstr "" #: ../source/glossary.rst:168 @@ -827,7 +1114,12 @@ msgid "Requirement" msgstr "" #: ../source/glossary.rst:171 -msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." +msgid "" +"A specification for a :term:`package ` to be " +"installed. :ref:`pip`, the :term:`PYPA ` " +"recommended installer, allows various forms of specification that can all be " +"considered a \"requirement\". For more information, see the :ref:`pip:pip " +"install` reference." msgstr "" #: ../source/glossary.rst:177 @@ -835,7 +1127,13 @@ msgid "Requirement Specifier" msgstr "" #: ../source/glossary.rst:180 -msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" +msgid "" +"A format used by :ref:`pip` to install packages from a :term:`Package " +"Index`. For an EBNF diagram of the format, see the `pkg_resources." +"Requirement `_ entry in the :ref:`setuptools` docs. For " +"example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the " +"project name, and the \">=1.3\" portion is the :term:`Version Specifier`" msgstr "" #: ../source/glossary.rst:187 @@ -843,7 +1141,10 @@ msgid "Requirements File" msgstr "" #: ../source/glossary.rst:190 -msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." +msgid "" +"A file containing a list of :term:`Requirements ` that can be " +"installed using :ref:`pip`. For more information, see the :ref:`pip` docs " +"on :ref:`pip:Requirements Files`." msgstr "" #: ../source/glossary.rst:194 @@ -857,7 +1158,9 @@ msgid "setup.cfg" msgstr "setup.cfg" #: ../source/glossary.rst:198 -msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." +msgid "" +"The project specification files for :ref:`distutils` and :ref:`setuptools`. " +"See also :term:`pyproject.toml`." msgstr "" #: ../source/glossary.rst:201 @@ -865,7 +1168,10 @@ msgid "Source Archive" msgstr "" #: ../source/glossary.rst:204 -msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." +msgid "" +"An archive containing the raw source code for a :term:`Release`, prior to " +"creation of a :term:`Source Distribution ` or :term:`Built Distribution`." msgstr "" #: ../source/glossary.rst:208 @@ -873,7 +1179,11 @@ msgid "Source Distribution (or \"sdist\")" msgstr "" #: ../source/glossary.rst:211 -msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." +msgid "" +"A :term:`distribution ` format (usually generated " +"using ``python setup.py sdist``) that provides metadata and the essential " +"source files needed for installing by a tool like :ref:`pip`, or for " +"generating a :term:`Built Distribution`." msgstr "" #: ../source/glossary.rst:216 @@ -881,7 +1191,9 @@ msgid "System Package" msgstr "" #: ../source/glossary.rst:219 -msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." +msgid "" +"A package provided in a format native to the operating system, e.g. an rpm " +"or dpkg file." msgstr "" #: ../source/glossary.rst:222 @@ -889,7 +1201,12 @@ msgid "Version Specifier" msgstr "Versio-Specifilo" #: ../source/glossary.rst:225 -msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." +msgid "" +"The version component of a :term:`Requirement Specifier`. For example, the " +"\">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full " +"specification <440#version-specifiers>` of the specifiers that Python " +"packaging currently supports. Support for PEP440 was implemented in :ref:" +"`setuptools` v8.0 and :ref:`pip` v6.0." msgstr "" #: ../source/glossary.rst:231 @@ -897,7 +1214,11 @@ msgid "Virtual Environment" msgstr "" #: ../source/glossary.rst:234 -msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgid "" +"An isolated Python environment that allows packages to be installed for use " +"by a particular application, rather than being installed system wide. For " +"more information, see the section on :ref:`Creating and using Virtual " +"Environments`." msgstr "" #: ../source/glossary.rst:238 @@ -905,7 +1226,10 @@ msgid "Wheel" msgstr "Wheel" #: ../source/glossary.rst:241 -msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." +msgid "" +"A :term:`Built Distribution` format introduced by :pep:`427`, which is " +"intended to replace the :term:`Egg` format. Wheel is currently supported " +"by :ref:`pip`." msgstr "" #: ../source/glossary.rst:244 @@ -913,7 +1237,11 @@ msgid "Working Set" msgstr "" #: ../source/glossary.rst:247 -msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." +msgid "" +"A collection of :term:`distributions ` available for " +"importing. These are the distributions that are on the `sys.path` variable. " +"At most, one :term:`Distribution ` for a project is " +"possible in a working set." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:3 @@ -921,7 +1249,11 @@ msgid "Analyzing PyPI package downloads" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:5 -msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." +msgid "" +"This section covers how to use the public PyPI download statistics dataset " +"to learn more about downloads of a package (or packages) hosted on PyPI. For " +"example, you can use it to discover the distribution of Python versions used " +"to download a package." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:15 @@ -934,11 +1266,17 @@ msgid "PyPI does not display download statistics for a number of reasons: [#]_" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:19 -msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." +msgid "" +"**Inefficient to make work with a Content Distribution Network (CDN):** " +"Download statistics change constantly. Including them in project pages, " +"which are heavily cached, would require invalidating the cache more often, " +"and reduce the overall effectiveness of the cache." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:24 -msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" +msgid "" +"**Highly inaccurate:** A number of things prevent the download counts from " +"being accurate, some of which include:" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:27 @@ -946,7 +1284,8 @@ msgid "``pip``'s download cache (lowers download counts)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:28 -msgid "Internal or unofficial mirrors (can both raise or lower download counts)" +msgid "" +"Internal or unofficial mirrors (can both raise or lower download counts)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:29 @@ -954,7 +1293,9 @@ msgid "Packages not hosted on PyPI (for comparisons sake)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:30 -msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" +msgid "" +"Unofficial scripts or attempts at download count inflation (raises download " +"counts)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:32 @@ -962,11 +1303,17 @@ msgid "Known historical data quality issues (lowers download counts)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:34 -msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" +msgid "" +"**Not particularly useful:** Just because a project has been downloaded a " +"lot doesn't mean it's good; Similarly just because a project hasn't been " +"downloaded a lot doesn't mean it's bad!" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:38 -msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." +msgid "" +"In short, because it's value is low for various reasons, and the tradeoffs " +"required to make it work are high, it has been not an effective use of " +"limited resources." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:43 @@ -974,7 +1321,10 @@ msgid "Public dataset" msgstr "Publika datenaro" #: ../source/guides/analyzing-pypi-package-downloads.rst:45 -msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." +msgid "" +"As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, " +"where they are stored as a public dataset." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:50 @@ -982,7 +1332,13 @@ msgid "Getting set up" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:52 -msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" +msgid "" +"In order to use `Google BigQuery`_ to query the `public PyPI download " +"statistics dataset`_, you'll need a Google account and to enable the " +"BigQuery API on a Google Cloud Platform project. You can run the up to 1TB " +"of queries per month `using the BigQuery free tier without a credit card " +"`__" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:58 @@ -994,11 +1350,16 @@ msgid "Create a new project." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:60 -msgid "Enable the `BigQuery API `__." +msgid "" +"Enable the `BigQuery API `__." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:63 -msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." +msgid "" +"For more detailed instructions on how to get started with BigQuery, check " +"out the `BigQuery quickstart guide `__." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:69 @@ -1006,7 +1367,12 @@ msgid "Data schema" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:71 -msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" +msgid "" +"Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` " +"table for each download. The table contains information about what file was " +"downloaded and how it was downloaded. Some useful columns from the `table " +"schema `__ include:" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 @@ -1089,11 +1455,16 @@ msgid "Useful queries" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:95 -msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." +msgid "" +"Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" " +"button." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:97 -msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." +msgid "" +"Note that the rows are stored in a partitioned, which helps limit the cost " +"of queries. These example queries analyze downloads from recent history by " +"filtering on the ``timestamp`` column." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:102 @@ -1101,7 +1472,9 @@ msgid "Counting package downloads" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:104 -msgid "The following query counts the total number of downloads for the project \"pytest\"." +msgid "" +"The following query counts the total number of downloads for the project " +"\"pytest\"." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:119 @@ -1116,7 +1489,9 @@ msgid "26190085" msgstr "26190085" #: ../source/guides/analyzing-pypi-package-downloads.rst:124 -msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." +msgid "" +"To only count downloads from pip, filter on the ``details.installer.name`` " +"column." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:142 @@ -1128,7 +1503,9 @@ msgid "Package downloads over time" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:148 -msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." +msgid "" +"To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also " +"filtering by this column reduces corresponding costs." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:168 @@ -1188,7 +1565,9 @@ msgid "Python versions over time" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:186 -msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." +msgid "" +"Extract the Python version from the ``details.python`` column. Warning: This " +"query processes over 500 GB of data." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:205 @@ -1248,7 +1627,12 @@ msgid "Caveats" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:223 -msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." +msgid "" +"In addition to the caveats listed in the background above, Linehaul suffered " +"from a bug which caused it to significantly under-report download statistics " +"prior to July 26, 2018. Downloads before this date are proportionally " +"accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total " +"numbers are lower than actual by an order of magnitude." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:231 @@ -1256,7 +1640,9 @@ msgid "Additional tools" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:233 -msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." +msgid "" +"Besides using the BigQuery console, there are some additional tools which " +"may be useful when analyzing download statistics." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:237 @@ -1264,7 +1650,10 @@ msgid "``google-cloud-bigquery``" msgstr "``google-cloud-bigquery``" #: ../source/guides/analyzing-pypi-package-downloads.rst:239 -msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." +msgid "" +"You can also access the public PyPI download statistics dataset " +"programmatically via the BigQuery API and the `google-cloud-bigquery`_ " +"project, the official Python client library for BigQuery." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:267 @@ -1272,7 +1661,10 @@ msgid "``pypinfo``" msgstr "``pypinfo``" #: ../source/guides/analyzing-pypi-package-downloads.rst:269 -msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." +msgid "" +"`pypinfo`_ is a command-line tool which provides access to the dataset and " +"can generate several useful queries. For example, you can query the total " +"number of download for a package with the command ``pypinfo package_name``." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:273 @@ -1288,7 +1680,8 @@ msgid "``pandas-gbq``" msgstr "``pandas-gbq``" #: ../source/guides/analyzing-pypi-package-downloads.rst:297 -msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." +msgid "" +"The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:301 @@ -1297,11 +1690,15 @@ msgid "References" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:303 -msgid "`PyPI Download Counts deprecation email `__" +msgid "" +"`PyPI Download Counts deprecation email `__" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:304 -msgid "`PyPI BigQuery dataset announcement email `__" +msgid "" +"`PyPI BigQuery dataset announcement email `__" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:3 @@ -1309,7 +1706,11 @@ msgid "Creating and discovering plugins" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:5 -msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." +msgid "" +"Often when creating a Python application or library you'll want the ability " +"to provide customizations or extra features via **plugins**. Because Python " +"packages can be separately distributed, your application or library may want " +"to automatically **discover** all of the plugins available." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:10 @@ -1333,15 +1734,25 @@ msgid "Using naming convention" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:20 -msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" +msgid "" +"If all of the plugins for your application follow the same naming " +"convention, you can use :func:`pkgutil.iter_modules` to discover all of the " +"top-level modules that match the naming convention. For example, `Flask`_ " +"uses the naming convention ``flask_{plugin_name}``. If you wanted to " +"automatically discover all of the Flask plugins installed:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:38 -msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" +msgid "" +"If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins " +"installed then ``discovered_plugins`` would be:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:48 -msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." +msgid "" +"Using naming convention for plugins also allows you to query the Python " +"Package Index's `simple API`_ for all packages that conform to your naming " +"convention." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:59 @@ -1349,19 +1760,48 @@ msgid "Using namespace packages" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:61 -msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" +msgid "" +":doc:`Namespace packages ` can be used to " +"provide a convention for where to place plugins and also provides a way to " +"perform discovery. For example, if you make the sub-package ``myapp." +"plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once " +"installed, you can use :func:`pkgutil.iter_modules` to discover all modules " +"and packages installed under that namespace:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:89 -msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" +msgid "" +"Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` " +"causes it to only look for the modules directly under that namespace. For " +"example, if you have installed distributions that provide the modules " +"``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in " +"this case would be:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:101 -msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." +msgid "" +"This sample uses a sub-package as the namespace package (``myapp.plugins``), " +"but it's also possible to use a top-level package for this purpose (such as " +"``myapp_plugins``). How to pick the namespace to use is a matter of " +"preference, but it's not recommended to make your project's main top-level " +"package (``myapp`` in this case) a namespace package for the purpose of " +"plugins, as one bad plugin could cause the entire namespace to break which " +"would in turn make your project unimportable. For the \"namespace sub-package" +"\" approach to work, the plugin packages must omit the :file:`__init__.py` " +"for your top-level package directory (``myapp`` in this case) and include " +"the namespace-package style :file:`__init__.py` in the namespace sub-package " +"directory (``myapp/plugins``). This also means that plugins will need to " +"explicitly pass a list of packages to :func:`setup`'s ``packages`` argument " +"instead of using :func:`setuptools.find_packages`." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:115 -msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." +msgid "" +"Namespace packages are a complex feature and there are several different " +"ways to create them. It's highly recommended to read the :doc:`packaging-" +"namespace-packages` documentation and clearly document which approach is " +"preferred for plugins to your project." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:121 @@ -1369,31 +1809,50 @@ msgid "Using package metadata" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:123 -msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." +msgid "" +"`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :" +"func:`setup` in :file:`setup.py` plugins can register themselves for " +"discovery." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:128 -msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" +msgid "" +"For example if you have a package named ``myapp-plugin-a`` and it includes " +"in its :file:`setup.py`:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:139 -msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" +msgid "" +"Then you can discover and load all of the registered entry points by using :" +"func:`importlib.metadata.entry_points` (or the `backport`_ " +"``importlib_metadata >= 3.6`` for Python 3.6-3.9):" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:154 -msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" +msgid "" +"In this example, ``discovered_plugins`` would be a collection of type :class:" +"`importlib.metadata.EntryPoint`:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:163 -msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." +msgid "" +"Now the module of your choice can be imported by executing " +"``discovered_plugins['a'].load()``." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:166 -msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." +msgid "" +"The ``entry_point`` specification in :file:`setup.py` is fairly flexible and " +"has a lot of options. It's recommended to read over the entire section on :" +"doc:`entry points ` ." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:170 -msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." +msgid "" +"Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools " +"provide support for defining entry points." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:5 @@ -1401,15 +1860,25 @@ msgid "Packaging and distributing projects" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:7 -msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." +msgid "" +"This section covers the basics of how to configure, package and distribute " +"your own Python projects. It assumes that you are already familiar with the " +"contents of the :doc:`/tutorials/installing-packages` page." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:11 -msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." +msgid "" +"The section does *not* aim to cover best practices for Python project " +"development as a whole. For example, it does not provide guidance or tool " +"recommendations for version control, documentation, or testing." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:15 -msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." +msgid "" +"For more reference material, see :std:doc:`Building and Distributing " +"Packages ` in the :ref:`setuptools` docs, but note that " +"some advisory content there may be outdated. In the event of conflicts, " +"prefer the advice in the Python Packaging User Guide." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:25 @@ -1417,7 +1886,9 @@ msgid "Requirements for packaging and distributing" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:26 -msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." +msgid "" +"First, make sure you have already fulfilled the :ref:`requirements for " +"installing packages `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:29 @@ -1425,7 +1896,10 @@ msgid "Install \"twine\" [1]_:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:43 -msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." +msgid "" +"You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below " +"`)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:49 @@ -1437,7 +1911,11 @@ msgid "Initial files" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:58 -msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." +msgid "" +"The most important file is :file:`setup.py` which exists at the root of your " +"project directory. For an example, see the `setup.py `_ in the `PyPA sample project " +"`_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:63 @@ -1445,15 +1923,27 @@ msgid ":file:`setup.py` serves two primary functions:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:65 -msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." +msgid "" +"It's the file where various aspects of your project are configured. The " +"primary feature of :file:`setup.py` is that it contains a global ``setup()`` " +"function. The keyword arguments to this function are how specific details " +"of your project are defined. The most relevant arguments are explained in :" +"ref:`the section below `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:71 -msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." +msgid "" +"It's the command line interface for running various commands that relate to " +"packaging tasks. To get a listing of available commands, run ``python setup." +"py --help-commands``." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:79 -msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." +msgid "" +":file:`setup.cfg` is an ini file that contains option defaults for :file:" +"`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project " +"`_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:86 @@ -1461,15 +1951,31 @@ msgid "README.rst / README.md" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:88 -msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." +msgid "" +"All projects should contain a readme file that covers the goal of the " +"project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not " +"a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:" +"`long_description_content_type ` argument)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:95 -msgid "For an example, see `README.md `_ from the `PyPA sample project `_." +msgid "" +"For an example, see `README.md `_ from the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:99 -msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." +msgid "" +"Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:" +"`README.rst`, :file:`README.txt`, or :file:`README`) included in source " +"distributions by default. The built-in :ref:`distutils` library adopts this " +"behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ " +"will include a :file:`README.md` if found. If you are using setuptools, you " +"don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, " +"include it to be explicit." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:108 @@ -1477,15 +1983,23 @@ msgid "MANIFEST.in" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:110 -msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." +msgid "" +"A :file:`MANIFEST.in` is needed when you need to package additional files " +"that are not automatically included in a source distribution. For details " +"on writing a :file:`MANIFEST.in` file, including a list of what's included " +"by default, see \":ref:`Using MANIFEST.in`\"." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:115 -msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." +msgid "" +"For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:119 -msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." +msgid "" +":file:`MANIFEST.in` does not affect binary distributions such as wheels." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:122 @@ -1493,11 +2007,20 @@ msgid "LICENSE.txt" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:124 -msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." +msgid "" +"Every package should include a license file detailing the terms of " +"distribution. In many jurisdictions, packages without an explicit license " +"can not be legally used or distributed by anyone other than the copyright " +"holder. If you're unsure which license to choose, you can use resources such " +"as `GitHub's Choose a License `_ or consult a " +"lawyer." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:130 -msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." +msgid "" +"For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:135 @@ -1505,11 +2028,17 @@ msgid "" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:137 -msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." +msgid "" +"Although it's not required, the most common practice is to include your " +"Python modules and packages under a single top-level package that has the " +"same :ref:`name ` as your project, or something very close." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:141 -msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." +msgid "" +"For an example, see the `sample `_ package that's included in the `PyPA sample project " +"`_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:149 @@ -1517,11 +2046,18 @@ msgid "setup() args" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:151 -msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." +msgid "" +"As mentioned above, the primary feature of :file:`setup.py` is that it " +"contains a global ``setup()`` function. The keyword arguments to this " +"function are how specific details of your project are defined." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:155 -msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." +msgid "" +"The most relevant arguments are explained below. Most of the snippets given " +"are taken from the `setup.py `_ contained in the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:164 @@ -1529,11 +2065,16 @@ msgid "name" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:170 -msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" +msgid "" +"This is the name of your project, determining how your project is listed on :" +"term:`PyPI `. Per :pep:`508`, valid project " +"names must:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:174 -msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" +msgid "" +"Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), " +"and/or periods (``.``), and" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:176 @@ -1541,7 +2082,11 @@ msgid "Start & end with an ASCII letter or digit." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:178 -msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" +msgid "" +"Comparison of project names is case insensitive and treats arbitrarily-long " +"runs of underscores, hyphens, and/or periods as equal. For example, if you " +"register a project named ``cool-stuff``, users will be able to download it " +"or declare a dependency on it using any of the following spellings::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:190 @@ -1550,19 +2095,30 @@ msgid "version" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:196 -msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." +msgid "" +"This is the current version of your project, allowing your users to " +"determine whether or not they have the latest version, and to indicate which " +"specific versions they've tested their own software against." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:200 -msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." +msgid "" +"Versions are displayed on :term:`PyPI ` for " +"each release if you publish your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:203 -msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." +msgid "" +"See :ref:`Choosing a versioning scheme` for more information on ways to use " +"versions to convey compatibility information to your users." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:206 -msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." +msgid "" +"If the project code itself needs run-time access to the version, the " +"simplest way is to keep the version in both :file:`setup.py` and your code. " +"If you'd rather not duplicate the value, there are a few ways to manage " +"this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:214 @@ -1574,15 +2130,32 @@ msgid "Give a short and long description for your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:224 -msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." +msgid "" +"These values will be displayed on :term:`PyPI ` " +"if you publish your project. On ``pypi.org``, the user interface displays " +"``description`` in the grey banner and ``long_description`` in the section " +"named \"Project Description\"." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:229 -msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." +msgid "" +"``description`` is also displayed in lists of projects. For example, it's " +"visible in the search results pages such as https://pypi.org/search/?" +"q=jupyter, the front-page lists of trending projects and new releases, and " +"the list of projects you maintain within your account profile (such as " +"https://pypi.org/user/jaraco/)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:235 -msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." +msgid "" +"A `content type `_ can be specified with the " +"``long_description_content_type`` argument, which can be one of ``text/" +"plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no " +"formatting, `reStructuredText (reST) `_, and the Github-flavored " +"Markdown dialect of `Markdown `_ respectively." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:245 @@ -1606,11 +2179,21 @@ msgid "license" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:273 -msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." +msgid "" +"The ``license`` argument doesn't have to indicate the license under which " +"your package is being released, although you may optionally do so if you " +"want. If you're using a standard, well-known license, then your main " +"indication can and should be via the ``classifiers`` argument. Classifiers " +"exist for all major open-source licenses." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:279 -msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." +msgid "" +"The \"license\" argument is more typically used to indicate differences from " +"well-known licenses, or to include your own, unique license. As a general " +"rule, it's a good idea to use a standard, well-known license, both to avoid " +"confusion and because some organizations avoid software whose license is " +"unapproved." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:287 @@ -1618,11 +2201,18 @@ msgid "classifiers" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:316 -msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." +msgid "" +"Provide a list of classifiers that categorize your project. For a full " +"listing, see https://pypi.org/classifiers/." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:319 -msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." +msgid "" +"Although the list of classifiers is often used to declare what Python " +"versions a project supports, this information is only used for searching & " +"browsing projects on PyPI, not for installing projects. To actually " +"restrict what Python versions a project can be installed on, use the :ref:" +"`python_requires` argument." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:327 @@ -1638,7 +2228,11 @@ msgid "project_urls" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:349 -msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." +msgid "" +"List additional relevant URLs about your project. This is the place to link " +"to bug trackers, source repositories, or where to support package " +"development. The string of the key is the exact text that will be displayed " +"on PyPI." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:355 @@ -1646,7 +2240,13 @@ msgid "packages" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:361 -msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." +msgid "" +"Set ``packages`` to a list of all :term:`packages ` in your " +"project, including their subpackages, sub-subpackages, etc. Although the " +"packages can be listed manually, ``setuptools.find_packages()`` finds them " +"automatically. Use the ``include`` keyword argument to find only the given " +"packages. Use the ``exclude`` keyword argument to omit packages that are " +"not intended to be released and installed." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:370 @@ -1654,15 +2254,23 @@ msgid "py_modules" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:376 -msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." +msgid "" +"If your project contains any single-file Python modules that aren't part of " +"a package, set ``py_modules`` to a list of the names of the modules (minus " +"the ``.py`` extension) in order to make :ref:`setuptools` aware of them." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:388 -msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgid "" +"\"install_requires\" should be used to specify what dependencies a project " +"minimally needs to run. When the project is installed by :ref:`pip`, this is " +"the specification that is used to install its dependencies." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:392 -msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." +msgid "" +"For more on using \"install_requires\" see :ref:`install_requires vs " +"Requirements files`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:398 @@ -1670,11 +2278,17 @@ msgid "python_requires" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:400 -msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" +msgid "" +"If your project only runs on certain Python versions, setting the " +"``python_requires`` argument to the appropriate :pep:`440` version specifier " +"string will prevent :ref:`pip` from installing the project on other Python " +"versions. For example, if your package is for Python 3+ only, write::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:407 -msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" +msgid "" +"If your package is for Python 2.6, 2.7, and all versions of Python 3 " +"starting with 3.3, write::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:412 @@ -1682,11 +2296,20 @@ msgid "And so on." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:416 -msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." +msgid "" +"Support for this feature is relatively recent. Your project's source " +"distributions and wheels (see :ref:`Packaging Your Project`) must be built " +"using at least version 24.2.0 of :ref:`setuptools` in order for the " +"``python_requires`` argument to be recognized and the appropriate metadata " +"generated." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:422 -msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." +msgid "" +"In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the " +"``python_requires`` metadata. Users with earlier versions of pip will be " +"able to download & install projects on any Python version regardless of the " +"projects' ``python_requires`` values." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:431 @@ -1694,15 +2317,25 @@ msgid "package_data" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:440 -msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." +msgid "" +"Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the " +"package’s implementation, or text files containing documentation that might " +"be of interest to programmers using the package. These files are called " +"\"package data\"." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:445 -msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." +msgid "" +"The value must be a mapping from package name to a list of relative path " +"names that should be copied into the package. The paths are interpreted as " +"relative to the directory containing the package." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:449 -msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." +msgid "" +"For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:457 @@ -1710,19 +2343,39 @@ msgid "data_files" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:463 -msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." +msgid "" +"Although configuring :ref:`Package Data` is sufficient for most needs, in " +"some cases you may need to place data files *outside* of your :term:" +"`packages `. The ``data_files`` directive allows you to do " +"that. It is mostly useful if you need to install files which are used by " +"other programs, which may be unaware of Python packages." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:469 -msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." +msgid "" +"Each ``(directory, files)`` pair in the sequence specifies the installation " +"directory and the files to install there. The ``directory`` must be a " +"relative path (although this may change in the future, see `wheel Issue #92 " +"`_). and it is interpreted relative " +"to the installation prefix (Python’s ``sys.prefix`` for a default " +"installation; ``site.USER_BASE`` for a user installation). Each file name in " +"``files`` is interpreted relative to the :file:`setup.py` script at the top " +"of the project source distribution." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:479 -msgid "For more information see the distutils section on `Installing Additional Files `_." +msgid "" +"For more information see the distutils section on `Installing Additional " +"Files `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:484 -msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." +msgid "" +"When installing packages as egg, ``data_files`` is not supported. So, if " +"your project uses :ref:`setuptools`, you must use ``pip`` to install it. " +"Alternatively, if you must use ``python setup.py``, then you need to pass " +"the ``--old-and-unmanageable`` option." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:491 @@ -1730,7 +2383,11 @@ msgid "scripts" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:493 -msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." +msgid "" +"Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made " +"scripts to install, the recommended approach to achieve cross-platform " +"compatibility is to use :ref:`console_scripts` entry points (see below)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:500 @@ -1738,11 +2395,17 @@ msgid "entry_points" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:509 -msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." +msgid "" +"Use this keyword to specify any plugins that your project provides for any " +"named entry points that may be defined by your project or others that you " +"depend on." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:512 -msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." +msgid "" +"For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:516 @@ -1754,11 +2417,20 @@ msgid "console_scripts" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:531 -msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgid "" +"Use \"console_script\" `entry points `_ to " +"register your script interfaces. You can then let the toolchain handle the " +"work of turning these interfaces into actual scripts [2]_. The scripts will " +"be generated during the install of your :term:`distribution `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:538 -msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." +msgid "" +"For more information, see `Automatic Script Creation `_ from " +"the `setuptools docs `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:545 @@ -1770,7 +2442,12 @@ msgid "Standards compliance for interoperability" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:550 -msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." +msgid "" +"Different Python projects may use different versioning schemes based on the " +"needs of that particular project, but all of them are required to comply " +"with the flexible :pep:`public version scheme <440#public-version-" +"identifiers>` specified in :pep:`440` in order to be supported in tools and " +"libraries like ``pip`` and ``setuptools``." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:556 @@ -1778,7 +2455,11 @@ msgid "Here are some examples of compliant version numbers::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:567 -msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." +msgid "" +"To further accommodate historical variations in approaches to version " +"numbering, :pep:`440` also defines a comprehensive technique for :pep:" +"`version normalisation <440#normalization>` that maps variant spellings of " +"different version numbers to a standardised canonical form." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:573 @@ -1790,11 +2471,16 @@ msgid "Semantic versioning (preferred)" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:578 -msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." +msgid "" +"For new projects, the recommended versioning scheme is based on `Semantic " +"Versioning `_, but adopts a different approach to " +"handling pre-releases and build metadata." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:582 -msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" +msgid "" +"The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE " +"numbering scheme, where the project author increments:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:585 @@ -1802,7 +2488,9 @@ msgid "MAJOR version when they make incompatible API changes," msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:586 -msgid "MINOR version when they add functionality in a backwards-compatible manner, and" +msgid "" +"MINOR version when they add functionality in a backwards-compatible manner, " +"and" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:587 @@ -1810,11 +2498,17 @@ msgid "MAINTENANCE version when they make backwards-compatible bug fixes." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:589 -msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." +msgid "" +"Adopting this approach as a project author allows users to make use of :pep:`" +"\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= " +"X.Y`` requires at least release X.Y, but also allows any later release with " +"a matching MAJOR version." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:594 -msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." +msgid "" +"Python projects adopting semantic versioning should abide by clauses 1-8 of " +"the `Semantic Versioning 2.0.0 specification `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:598 @@ -1822,15 +2516,23 @@ msgid "Date based versioning" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:600 -msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." +msgid "" +"Semantic versioning is not a suitable choice for all projects, such as those " +"with a regular time based release cadence and a deprecation process that " +"provides warnings for a number of releases prior to removal of a feature." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:604 -msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." +msgid "" +"A key advantage of date based versioning is that it is straightforward to " +"tell how old the base feature set of a particular release is given just the " +"version number." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:607 -msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." +msgid "" +"Version numbers for date based projects typically take the form of YEAR." +"MONTH (for example, ``12.04``, ``15.10``)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:611 @@ -1838,11 +2540,16 @@ msgid "Serial versioning" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:613 -msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." +msgid "" +"This is the simplest possible versioning scheme, and consists of a single " +"number which is incremented every release." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:616 -msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." +msgid "" +"While serial versioning is very easy to manage as a developer, it is the " +"hardest to track as an end user, as serial version numbers convey little or " +"no information regarding API backwards compatibility." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:621 @@ -1850,7 +2557,11 @@ msgid "Hybrid schemes" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:623 -msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." +msgid "" +"Combinations of the above schemes are possible. For example, a project may " +"combine date based versioning with serial versioning to create a YEAR.SERIAL " +"numbering scheme that readily conveys the approximate age of a release, but " +"doesn't otherwise commit to a particular release cadence within the year." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:629 @@ -1858,7 +2569,9 @@ msgid "Pre-release versioning" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:631 -msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" +msgid "" +"Regardless of the base versioning scheme, pre-releases for a given final " +"release may be published as:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:634 @@ -1878,7 +2591,9 @@ msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:639 -msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." +msgid "" +"``pip`` and other modern Python package installers ignore pre-releases by " +"default when deciding which versions of dependencies to install." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:644 @@ -1886,11 +2601,19 @@ msgid "Local version identifiers" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:646 -msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." +msgid "" +"Public version identifiers are designed to support distribution via :term:" +"`PyPI `. Python's software distribution tools " +"also support the notion of a :pep:`local version identifier <440#local-" +"version-identifiers>`, which can be used to identify local development " +"builds not intended for publication, or modified variants of a release " +"maintained by a redistributor." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:653 -msgid "A local version identifier takes the form ``+``. For example::" +msgid "" +"A local version identifier takes the form ``" +"+``. For example::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:661 @@ -1898,7 +2621,10 @@ msgid "Working in \"development mode\"" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:663 -msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." +msgid "" +"Although not required, it's common to locally install your project in " +"\"editable\" or \"develop\" mode while you're working on it. This allows " +"your project to be both installed and editable in project form." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:667 @@ -1906,31 +2632,56 @@ msgid "Assuming you're in the root of your project directory, then run:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:674 -msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." +msgid "" +"Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` " +"refers to the current working directory, so together, it means to install " +"the current directory (i.e. your project) in editable mode. This will also " +"install any dependencies declared with \"install_requires\" and any scripts " +"declared with \"console_scripts\". Dependencies will be installed in the " +"usual, non-editable mode." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:680 -msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" +msgid "" +"It's fairly common to also want to install some of your dependencies in " +"editable mode as well. For example, supposing your project requires \"foo\" " +"and \"bar\", but you want \"bar\" installed from VCS in editable mode, then " +"you could construct a requirements file like so::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:688 -msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." +msgid "" +"The first line says to install your project and any dependencies. The second " +"line overrides the \"bar\" dependency, such that it's fulfilled from VCS, " +"not PyPI." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:692 -msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" +msgid "" +"If, however, you want \"bar\" installed from a local directory in editable " +"mode, the requirements file should look like this, with the local paths at " +"the top of the file::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:697 -msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." +msgid "" +"Otherwise, the dependency will be fulfilled from PyPI, due to the " +"installation order of the requirements file. For more on requirements " +"files, see the :ref:`Requirements File ` section in " +"the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:701 -msgid "Lastly, if you don't want to install any dependencies at all, you can run::" +msgid "" +"Lastly, if you don't want to install any dependencies at all, you can run::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:706 -msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." +msgid "" +"For more information, see the `Development Mode `_ section of the " +"`setuptools docs `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:713 @@ -1938,11 +2689,17 @@ msgid "Packaging your project" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:715 -msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." +msgid "" +"To have your project installable from a :term:`Package Index` like :term:" +"`PyPI `, you'll need to create a :term:" +"`Distribution ` (aka \":term:`Package `\") for your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:720 -msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" +msgid "" +"Before you can build wheels and sdists for your project, you'll need to " +"install the ``build`` package:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:737 @@ -1950,11 +2707,18 @@ msgid "Source distributions" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:739 -msgid "Minimally, you should create a :term:`Source Distribution `:" +msgid "" +"Minimally, you should create a :term:`Source Distribution `:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:755 -msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." +msgid "" +"A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built " +"Distribution`), and requires a build step when installed by pip. Even if " +"the distribution is pure Python (i.e. contains no extensions), it still " +"involves a build step to build out the installation metadata from :file:" +"`setup.py` and/or :file:`setup.cfg`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:763 @@ -1962,23 +2726,36 @@ msgid "Wheels" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:765 -msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." +msgid "" +"You should also create a wheel for your project. A wheel is a :term:`built " +"package ` that can be installed without needing to go " +"through the \"build\" process. Installing wheels is substantially faster for " +"the end user than installing from a source distribution." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:770 -msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." +msgid "" +"If your project is pure Python then you'll be creating a :ref:`\"Pure Python " +"Wheel\" (see section below) `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:773 -msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." +msgid "" +"If your project contains compiled extensions, then you'll be creating what's " +"called a :ref:`*Platform Wheel* (see section below) `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:776 -msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" +msgid "" +"If your project also supports Python 2 *and* contains no C extensions, then " +"you should create what's called a *Universal Wheel* by adding the following " +"to your :file:`setup.cfg` file:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:785 -msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." +msgid "" +"Only use this setting if your project does not have any C extensions *and* " +"supports Python 2 and 3." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:792 @@ -1986,7 +2763,9 @@ msgid "Pure Python Wheels" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:794 -msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." +msgid "" +"*Pure Python Wheels* contain no compiled extensions, and therefore only " +"require a single Python wheel." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:797 @@ -1995,11 +2774,16 @@ msgid "To build the wheel:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:811 -msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." +msgid "" +"The ``wheel`` package will detect that the code is pure Python, and build a " +"wheel that's named such that it's usable on any Python 3 installation. For " +"details on the naming of wheel files, see :pep:`425`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:815 -msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." +msgid "" +"If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both " +"files for you; this is useful when you don't need multiple wheels." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:821 @@ -2007,15 +2791,23 @@ msgid "Platform Wheels" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:823 -msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." +msgid "" +"*Platform Wheels* are wheels that are specific to a certain platform like " +"Linux, macOS, or Windows, usually due to containing compiled extensions." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:841 -msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." +msgid "" +"The ``wheel`` package will detect that the code is not pure Python, and " +"build a wheel that's named such that it's only usable on the platform that " +"it was built on. For details on the naming of wheel files, see :pep:`425`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:847 -msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." +msgid "" +":term:`PyPI ` currently supports uploads of " +"platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. " +"Details of the latter are defined in :pep:`513`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:855 @@ -2023,23 +2815,45 @@ msgid "Uploading your Project to PyPI" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:857 -msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." +msgid "" +"When you ran the command to create your distribution, a new directory ``dist/" +"`` was created under your project's root directory. That's where you'll find " +"your distribution file(s) to upload." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:861 -msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." +msgid "" +"These files are only created when you run the command to create your " +"distribution. This means that any time you change the source of your project " +"or the configuration in your :file:`setup.py` file, you will need to rebuild " +"these files again before you can distribute the changes to PyPI." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:866 -msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." +msgid "" +"Before releasing on main PyPI repo, you might prefer training with the `PyPI " +"test site `_ which is cleaned on a semi regular " +"basis. See :ref:`using-test-pypi` on how to setup your configuration in " +"order to use it." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:871 -msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." +msgid "" +"In other resources you may encounter references to using ``python setup.py " +"register`` and ``python setup.py upload``. These methods of registering and " +"uploading a package are **strongly discouraged** as it may use a plaintext " +"HTTP or unverified HTTPS connection on some Python versions, allowing your " +"username and password to be intercepted during transmission." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:877 -msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" +msgid "" +"The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to " +"ensure safety of all users, certain kinds of URLs and directives are " +"forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** " +"trying to upload your distribution, you should check to see if your brief / " +"long descriptions provided in :file:`setup.py` are valid. You can do this " +"by running :std:doc:`twine check ` on your package files::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:888 @@ -2047,23 +2861,35 @@ msgid "Create an account" msgstr "Krei konton" #: ../source/guides/distributing-packages-using-setuptools.rst:890 -msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." +msgid "" +"First, you need a :term:`PyPI ` user account. " +"You can create an account `using the form on the PyPI website `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:894 -msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." +msgid "" +"Now you'll create a PyPI `API token`_ so you will be able to securely upload " +"your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:897 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." +msgid "" +"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " +"token`_; don't limit its scope to a particular project, since you are " +"creating a new project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:901 -msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgid "" +"**Don't close the page until you have copied and saved the token — you won't " +"see that token again.**" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:904 -msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" +msgid "" +"To avoid having to copy and paste the token every time you upload, you can " +"create a :file:`$HOME/.pypirc` file:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:913 @@ -2074,7 +2900,8 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:70 #: ../source/guides/migrating-to-pypi-org.rst:109 #: ../source/guides/using-testpypi.rst:83 -msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." +msgid "" +"For more details, see the :ref:`specification ` for :file:`.pypirc`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:921 @@ -2082,28 +2909,46 @@ msgid "Upload your distributions" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:923 -msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." +msgid "" +"Once you have an account you can upload your distributions to :term:`PyPI " +"` using :ref:`twine`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:926 -msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." +msgid "" +"The process for uploading a release is the same regardless of whether or not " +"the project already exists on PyPI - if it doesn't exist yet, it will be " +"automatically created when the first release is uploaded." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:930 -msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." +msgid "" +"For the second and subsequent releases, PyPI only requires that the version " +"number of the new release differ from any previous releases." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:937 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgid "" +"You can see if your package has successfully uploaded by navigating to the " +"URL ``https://pypi.org/project/`` where ``sampleproject`` is " +"the name of your project that you uploaded. It may take a minute or two for " +"your project to appear on the site." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:944 #: ../source/tutorials/installing-packages.rst:663 -msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." +msgid "" +"Depending on your platform, this may require root or Administrator access. :" +"ref:`pip` is currently considering changing this by `making user installs " +"the default behavior `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:950 -msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." +msgid "" +"Specifically, the \"console_script\" approach generates ``.exe`` files on " +"Windows, which are necessary because the OS special-cases ``.exe`` files. " +"Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for " +"Windows <397>` allow scripts to be used in many cases, but not all." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:5 @@ -2111,19 +2956,30 @@ msgid "Dropping support for older Python versions" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:7 -msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." +msgid "" +"Dropping support for older Python versions is supported by the standard :ref:" +"`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:9 -msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." +msgid "" +"Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification " +"by matching the current Python runtime and comparing it with the required " +"version in the package metadata. If they do not match, it will attempt to " +"install the last package distribution that supported that Python runtime." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:12 -msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." +msgid "" +"This mechanism can be used to drop support for older Python versions, by " +"amending the \"Requires-Python\" attribute in the package metadata." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:14 -msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." +msgid "" +"This guide is specifically for users of :ref:`setuptools`, other packaging " +"tools such as ``flit`` may offer similar functionality but users will need " +"to consult relevant documentation." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:17 @@ -2143,7 +2999,9 @@ msgid "The latest version of :ref:`twine` is used to upload the package," msgstr "" #: ../source/guides/dropping-older-python-versions.rst:23 -msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." +msgid "" +"The user installing the package has at least Pip 9.0, or a client that " +"supports the Metadata 1.2 specification." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:26 @@ -2151,15 +3009,26 @@ msgid "Dealing with the universal wheels" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:28 -msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." +msgid "" +"Traditionally, projects providing Python code that is semantically " +"compatible with both Python 2 and Python 3, produce :term:`wheels ` " +"that have a ``py2.py3`` tag in their names. When dropping support for Python " +"2, it is important not to forget to change this tag to just ``py3``. It is " +"often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` " +"section by setting ``universal = 1`` if they use setuptools." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:36 -msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" +msgid "" +"If you use this method, either remove this option or section, or explicitly " +"set ``universal`` to ``0``:" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:48 -msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." +msgid "" +"Since it is possible to override the :file:`setup.cfg` settings via CLI " +"flags, make sure that your scripts don't have ``--universal`` in your " +"package creation scripts." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:53 @@ -2171,7 +3040,9 @@ msgid "1. Download the newest version of Setuptools" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:58 -msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." +msgid "" +"Ensure that before you generate source distributions or binary " +"distributions, you update Setuptools and install twine." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:60 @@ -2187,7 +3058,9 @@ msgid "2. Specify the version ranges for supported Python distributions" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:79 -msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." +msgid "" +"You can specify version ranges and exclusion rules, such as at least Python " +"3. Or, Python 2.7, 3.4 and beyond." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:81 @@ -2203,7 +3076,10 @@ msgid "Examples::" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:86 -msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." +msgid "" +"The way to set those values is within the call to ``setup`` within your :" +"file:`setup.py` script. This will insert the ``Requires-Python`` metadata " +"values based on the argument you provide in ``python_requires``." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:101 @@ -2211,11 +3087,16 @@ msgid "3. Validating the Metadata before publishing" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:103 -msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." +msgid "" +"Within a Python source package (the zip or the tar-gz file you download) is " +"a text file called PKG-INFO." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:105 -msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." +msgid "" +"This file is generated by Distutils or :ref:`setuptools` when it generates " +"the source package. The file contains a set of keys and values, the list of " +"keys is part of the PyPa standard metadata format." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:108 @@ -2227,11 +3108,14 @@ msgid "Validate that the following is in place, before publishing the package:" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:114 -msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." +msgid "" +"If you have upgraded correctly, the Metadata-Version value should be 1.2 or " +"higher." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:115 -msgid "The Requires-Python field is set and matches your specification in setup.py." +msgid "" +"The Requires-Python field is set and matches your specification in setup.py." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:118 @@ -2239,7 +3123,9 @@ msgid "4. Using Twine to publish" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:120 -msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." +msgid "" +"Twine has a number of advantages, apart from being faster it is now the " +"supported method for publishing packages." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:122 @@ -2251,7 +3137,9 @@ msgid "Dropping a Python release" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:127 -msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." +msgid "" +"Once you have published a package with the Requires-Python metadata, you can " +"then make a further update removing that Python runtime from support." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:129 @@ -2259,11 +3147,17 @@ msgid "It must be done in this order for the automated fallback to work." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:131 -msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." +msgid "" +"For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 " +"of your package." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:133 -msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." +msgid "" +"If you were then to update the version string to \">=3.5\", and publish a " +"new version 2.0.0 of your package, any users running Pip 9.0+ from version " +"2.7 will have version 1.0.0 of the package installed, and any >=3.5 users " +"will receive version 2.0.0." msgstr "" #: ../source/guides/hosting-your-own-index.rst:5 @@ -2271,15 +3165,25 @@ msgid "Hosting your own simple repository" msgstr "" #: ../source/guides/hosting-your-own-index.rst:8 -msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." +msgid "" +"If you wish to host your own simple repository [1]_, you can either use a " +"software package like `devpi`_ or you can use simply create the proper " +"directory structure and use any web server that can serve static files and " +"generate an autoindex." msgstr "" #: ../source/guides/hosting-your-own-index.rst:13 -msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" +msgid "" +"In either case, since you'll be hosting a repository that is likely not in " +"your user's default repositories, you should instruct them in your project's " +"description to configure their installer appropriately. For example with pip:" msgstr "" #: ../source/guides/hosting-your-own-index.rst:29 -msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." +msgid "" +"In addition, it is **highly** recommended that you serve your repository " +"with valid HTTPS. At this time, the security of your user's installations " +"depends on all repositories using a valid HTTPS setup." msgstr "" #: ../source/guides/hosting-your-own-index.rst:35 @@ -2287,34 +3191,45 @@ msgid "\"Manual\" repository" msgstr "" #: ../source/guides/hosting-your-own-index.rst:37 -msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" +msgid "" +"The directory layout is fairly simple, within a root directory you need to " +"create a directory for each project. This directory should be the normalized " +"name (as defined by :pep:`503`) of the project. Within each of these " +"directories simply place each of the downloadable files. If you have the " +"projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the " +"version 0.1) You should end up with a structure that looks like::" msgstr "" #: ../source/guides/hosting-your-own-index.rst:51 -msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." +msgid "" +"Once you have this layout, simply configure your webserver to serve the root " +"directory with autoindex enabled. For an example using the built in Web " +"server in `Twisted`_, you would simply run ``twistd -n web --path .`` and " +"then instruct users to add the URL to their installer's configuration." msgstr "" #: ../source/guides/hosting-your-own-index.rst:58 -msgid "For complete documentation of the simple repository protocol, see :pep:`503`." +msgid "" +"For complete documentation of the simple repository protocol, see :pep:`503`." msgstr "" -#: ../source/guides/index.rst:8 #: ../source/guides/index.rst:8 msgid "Installing Packages:" msgstr "" -#: ../source/guides/index.rst:20 #: ../source/guides/index.rst:20 msgid "Building and Publishing Projects:" msgstr "" -#: ../source/guides/index.rst:38 #: ../source/guides/index.rst:38 msgid "Miscellaneous:" msgstr "" #: ../source/guides/index.rst:4 -msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." +msgid "" +"**Guides** are focused on accomplishing a specific task and assume that you " +"are already familiar with the basics of Python packaging. If you're looking " +"for an introduction to packaging, see :doc:`/tutorials/index`." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:5 @@ -2327,7 +3242,10 @@ msgid "2014-12-24" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:14 -msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." +msgid "" +"Mirroring or caching of PyPI can be used to speed up local package " +"installation, allow offline work, handle corporate firewalls or just plain " +"Internet flakiness." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:17 @@ -2339,11 +3257,15 @@ msgid "pip provides local caching options," msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:20 -msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" +msgid "" +"devpi provides higher-level caching option, potentially shared amongst many " +"users or machines, and" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:22 -msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." +msgid "" +"bandersnatch provides a local complete mirror of all PyPI :term:`packages " +"`." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:27 @@ -2351,15 +3273,23 @@ msgid "Caching with pip" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:29 -msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" +msgid "" +"pip provides a number of facilities for speeding up installation by using " +"local cached copies of :term:`packages `:" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:32 -msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." +msgid "" +"`Fast & local installs `_ by downloading all the requirements for a project and " +"then pointing pip at those downloaded files instead of going to PyPI." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:36 -msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" +msgid "" +"A variation on the above which pre-builds the installation files for the " +"requirements using `python -m pip wheel `_::" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:45 @@ -2367,7 +3297,10 @@ msgid "Caching with devpi" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:47 -msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." +msgid "" +"devpi is a caching proxy server which you run on your laptop, or some other " +"machine you know will always be available to you. See the `devpi " +"documentation for getting started`__." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:55 @@ -2375,11 +3308,18 @@ msgid "Complete mirror with bandersnatch" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:57 -msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." +msgid "" +"bandersnatch will set up a complete local mirror of all PyPI :term:`packages " +"` (externally-hosted packages are not mirrored). See " +"the `bandersnatch documentation for getting that going`__." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:63 -msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." +msgid "" +"A benefit of devpi is that it will create a mirror which includes :term:" +"`packages ` that are external to PyPI, unlike " +"bandersnatch which will only cache :term:`packages ` " +"hosted on PyPI." msgstr "" #: ../source/guides/installing-scientific-packages.rst:5 @@ -2387,19 +3327,38 @@ msgid "Installing scientific packages" msgstr "" #: ../source/guides/installing-scientific-packages.rst:11 -msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." +msgid "" +"Scientific software tends to have more complex dependencies than most, and " +"it will often have multiple build options to take advantage of different " +"kinds of hardware, or to interoperate with different pieces of external " +"software." msgstr "" #: ../source/guides/installing-scientific-packages.rst:16 -msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." +msgid "" +"In particular, `NumPy `__, which provides the basis " +"for most of the software in the `scientific Python stack `__ can be configured to interoperate with " +"different FORTRAN libraries, and can take advantage of different levels of " +"vectorised instructions available in modern CPUs." msgstr "" #: ../source/guides/installing-scientific-packages.rst:22 -msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." +msgid "" +"Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built " +"32-bit and 64-bit binaries in the ``wheel`` format are available for all " +"major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, " +"that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, " +"so they may not provide optimal linear algebra performance." msgstr "" #: ../source/guides/installing-scientific-packages.rst:29 -msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." +msgid "" +"There are a number of alternative options for obtaining scientific Python " +"libraries (or any other Python libraries that require a compilation " +"environment to install from source and don't provide pre-built wheel files " +"on PyPI)." msgstr "" #: ../source/guides/installing-scientific-packages.rst:35 @@ -2407,7 +3366,12 @@ msgid "Building from source" msgstr "" #: ../source/guides/installing-scientific-packages.rst:37 -msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." +msgid "" +"The same complexity which makes it difficult to distribute NumPy (and many " +"of the projects that depend on it) as wheel files also make them difficult " +"to build from source yourself. However, for intrepid folks that are willing " +"to spend the time wrangling compilers and linkers for both C and FORTRAN, " +"building from source is always an option." msgstr "" #: ../source/guides/installing-scientific-packages.rst:45 @@ -2415,11 +3379,18 @@ msgid "Linux distribution packages" msgstr "" #: ../source/guides/installing-scientific-packages.rst:47 -msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." +msgid "" +"For Linux users, the system package manager will often have pre-compiled " +"versions of various pieces of scientific software, including NumPy and other " +"parts of the scientific Python stack." msgstr "" #: ../source/guides/installing-scientific-packages.rst:51 -msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." +msgid "" +"If using versions which may be several months old is acceptable, then this " +"is likely to be a good option (just make sure to allow access to " +"distributions installed into the system Python when using virtual " +"environments)." msgstr "" #: ../source/guides/installing-scientific-packages.rst:57 @@ -2427,23 +3398,42 @@ msgid "Windows installers" msgstr "" #: ../source/guides/installing-scientific-packages.rst:59 -msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." +msgid "" +"Many Python projects that don't (or can't) currently publish wheel files at " +"least publish Windows installers, either on PyPI or on their project " +"download page. Using these installers allows users to avoid the need to set " +"up a suitable environment to build extensions locally." msgstr "" #: ../source/guides/installing-scientific-packages.rst:64 -msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." +msgid "" +"The extensions provided in these installers are typically compatible with " +"the CPython Windows installers published on python.org." msgstr "" #: ../source/guides/installing-scientific-packages.rst:67 -msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." +msgid "" +"For projects which don't provide their own Windows installers (and even some " +"which do), Christoph Gohlke at the University of California provides a " +"`collection of Windows installers `__. Many Python users on Windows have reported a positive experience with " +"these prebuilt versions." msgstr "" #: ../source/guides/installing-scientific-packages.rst:73 -msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." +msgid "" +"As with Linux system packages, the Windows installers will only install into " +"a system Python installation - they do not support installation in virtual " +"environments. Allowing access to distributions installed into the system " +"Python when using virtual environments is a common approach to working " +"around this limitation." msgstr "" #: ../source/guides/installing-scientific-packages.rst:79 -msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." +msgid "" +"The :term:`Wheel` project also provides a :command:`wheel convert` " +"subcommand that can convert a Windows :command:`bdist_wininst` installer to " +"a wheel." msgstr "" #: ../source/guides/installing-scientific-packages.rst:86 @@ -2451,11 +3441,18 @@ msgid "macOS installers and package managers" msgstr "" #: ../source/guides/installing-scientific-packages.rst:88 -msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." +msgid "" +"Similar to the situation on Windows, many projects (including NumPy) publish " +"macOS installers that are compatible with the macOS CPython binaries " +"published on python.org." msgstr "" #: ../source/guides/installing-scientific-packages.rst:92 -msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" +msgid "" +"macOS users also have access to Linux distribution style package managers " +"such as ``MacPorts``. The SciPy site has more details on using MacPorts to " +"install the `scientific Python stack `__" msgstr "" #: ../source/guides/installing-scientific-packages.rst:99 @@ -2463,11 +3460,16 @@ msgid "SciPy distributions" msgstr "" #: ../source/guides/installing-scientific-packages.rst:101 -msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." +msgid "" +"The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use " +"and update format." msgstr "" #: ../source/guides/installing-scientific-packages.rst:105 -msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." +msgid "" +"Some of these distributions may not be compatible with the standard ``pip`` " +"and ``virtualenv`` based toolchain." msgstr "" #: ../source/guides/installing-scientific-packages.rst:109 @@ -2476,11 +3478,25 @@ msgid "Spack" msgstr "" #: ../source/guides/installing-scientific-packages.rst:110 -msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." +msgid "" +"`Spack `_ is a flexible package manager " +"designed to support multiple versions, configurations, platforms, and " +"compilers. It was built to support the needs of large supercomputing centers " +"and scientific application teams, who must often build software many " +"different ways. Spack is not limited to Python; it can install packages for " +"``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-" +"destructive; installing a new version of one package does not break existing " +"installations, so many configurations can coexist on the same system." msgstr "" #: ../source/guides/installing-scientific-packages.rst:119 -msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." +msgid "" +"Spack offers a simple but powerful syntax that allows users to specify " +"versions and configuration options concisely. Package files are written in " +"pure Python, and they are templated so that it is easy to swap compilers, " +"dependency implementations (like MPI), versions, and build options with a " +"single package file. Spack also generates *module* files so that packages " +"can be loaded and unloaded from the user's environment." msgstr "" #: ../source/guides/installing-scientific-packages.rst:128 @@ -2488,11 +3504,29 @@ msgid "The conda cross-platform package manager" msgstr "" #: ../source/guides/installing-scientific-packages.rst:130 -msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." +msgid "" +"`Anaconda `_ is a Python distribution " +"published by Anaconda, Inc. It is a stable collection of Open Source " +"packages for big data and scientific use. As of the 5.0 release of " +"Anaconda, about 200 packages are installed by default, and a total of " +"400-500 can be installed and updated from the Anaconda repository." msgstr "" #: ../source/guides/installing-scientific-packages.rst:136 -msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." +msgid "" +"``conda`` is an open source (BSD licensed) package management system and " +"environment management system included in Anaconda that allows users to " +"install multiple versions of binary software packages and their " +"dependencies, and easily switch between them. It is a cross-platform tool " +"working on Windows, macOS, and Linux. Conda can be used to package up and " +"distribute all kinds of packages, it is not limited to just Python packages. " +"It has full support for native virtual environments. Conda makes " +"environments first-class citizens, making it easy to create independent " +"environments even for C libraries. It is written in Python, but is Python-" +"agnostic. Conda manages Python itself as a package, so that :command:`conda " +"update python` is possible, in contrast to pip, which only manages Python " +"packages. Conda is available in Anaconda and Miniconda (an easy-to-install " +"download with just Python and conda)." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:2 @@ -2500,15 +3534,28 @@ msgid "Installing stand alone command line tools" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:4 -msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." +msgid "" +"Many packages have command line entry points. Examples of this type of " +"application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:10 -msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." +msgid "" +"Usually you want to be able to access these from anywhere, but installing " +"packages and their dependencies to the same global environment can cause " +"version conflicts and break dependencies the operating system has on Python " +"packages." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:15 -msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." +msgid "" +":ref:`pipx` solves this by creating a virtual environment for each package, " +"while also ensuring that package's applications are accessible through a " +"directory that is on your ``$PATH``. This allows each package to be upgraded " +"or uninstalled without causing conflicts with other packages, and allows you " +"to safely run the program from anywhere." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:21 @@ -2520,11 +3567,14 @@ msgid "``pipx`` is installed with ``pip``:" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:30 -msgid "You may need to restart your terminal for the path updates to take effect." +msgid "" +"You may need to restart your terminal for the path updates to take effect." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:32 -msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." +msgid "" +"Now you can install packages with ``pipx install`` and access the package's " +"entry point(s) from anywhere." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:39 @@ -2533,7 +3583,9 @@ msgid "For example" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:59 -msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." +msgid "" +"To see a list of packages installed with pipx and which CLI applications are " +"available, use ``pipx list``." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:79 @@ -2545,7 +3597,9 @@ msgid "``pipx`` can be upgraded or uninstalled with pip" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:93 -msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." +msgid "" +"``pipx`` also allows you to install and run the latest version of a cli tool " +"in a temporary, ephemeral environment." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:106 @@ -2553,7 +3607,9 @@ msgid "To see the full list of commands ``pipx`` offers, run" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:112 -msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." +msgid "" +"You can learn more about ``pipx`` at its homepage, https://github.com/pypa/" +"pipx." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:5 @@ -2565,19 +3621,35 @@ msgid "2015-09-17" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:11 -msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." +msgid "" +"This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:" +"`wheel` using Linux package managers." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:14 -msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." +msgid "" +"If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:" +"`installing_requirements` section instead." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:18 -msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." +msgid "" +"Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, " +"and :ref:`wheel` supported by a specific Linux Distribution to be outdated " +"by the time it's released to the public, and updates generally only occur " +"for security reasons, not for feature updates. For certain Distributions, " +"there are additional repositories that can be enabled to provide newer " +"versions. The repositories we know about are explained below." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:25 -msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." +msgid "" +"Also note that it's somewhat common for Distributions to apply patches for " +"the sake of security and normalization to their own standards. In some " +"cases, this can lead to bugs or unexpected behaviors that vary from the " +"original unpatched versions. When this is known, we will make note of it " +"below." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:32 @@ -2609,7 +3681,11 @@ msgid "Python 3: ``sudo dnf install python3 python3-wheel``" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:53 -msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" +msgid "" +"To get newer versions of pip, setuptools, and wheel for Python 2, you can " +"enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:63 @@ -2617,7 +3693,9 @@ msgid "CentOS/RHEL" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:65 -msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." +msgid "" +"CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core " +"repositories, although :ref:`setuptools` is installed by default." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:68 @@ -2625,7 +3703,11 @@ msgid "To install pip and wheel for the system Python, there are two options:" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:70 -msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" +msgid "" +"Enable the `EPEL repository `_ using " +"`these instructions `__. On EPEL 6 and EPEL7, you can " +"install pip like so::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:77 @@ -2633,11 +3715,16 @@ msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:81 -msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." +msgid "" +"Since EPEL only offers extra, non-conflicting packages, EPEL does not offer " +"setuptools, since it's in the core repository." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:85 -msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" +msgid "" +"Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:92 @@ -2645,15 +3732,21 @@ msgid "To additionally upgrade setuptools, run::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:97 -msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" +msgid "" +"To install pip, wheel, and setuptools, in a parallel, non-system environment " +"(using yum) then there are two options:" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:101 -msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." +msgid "" +"Use the \"Software Collections\" feature to enable a parallel collection " +"that includes pip, setuptools, and wheel." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:104 -msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" +msgid "" +"For Redhat, see here: http://developers.redhat.com/products/" +"softwarecollections/overview/" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:106 @@ -2665,7 +3758,11 @@ msgid "Be aware that collections may not contain the most recent versions." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:110 -msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." +msgid "" +"Enable the `IUS repository `_ and install " +"one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which " +"are kept fairly up to date." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:116 @@ -2687,7 +3784,10 @@ msgid "Debian/Ubuntu" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:150 -msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." +msgid "" +"Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" " +"`_ by default, " +"which is a significant behavior change that can be surprising to some users." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:156 @@ -2695,7 +3795,9 @@ msgid "Arch Linux" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:168 -msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." +msgid "" +"Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the " +"only option is to manually place the repo files as described." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 @@ -2703,11 +3805,18 @@ msgid "Installing packages using pip and virtual environments" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 -msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." +msgid "" +"This guide discusses how to install packages using :ref:`pip` and a virtual " +"environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` " +"for Python 2. These are the lowest-level tools for managing Python packages " +"and are recommended if higher-level tools do not suit your needs." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 -msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." +msgid "" +"This doc uses the term **package** to refer to a :term:`Distribution " +"Package` which is different from an :term:`Import Package` that which is " +"used to import modules in your Python source code." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 @@ -2715,15 +3824,24 @@ msgid "Installing pip" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 -msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." +msgid "" +":ref:`pip` is the reference Python package manager. It's used to install and " +"update packages. You'll need to make sure you have the latest version of pip " +"installed." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 -msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." +msgid "" +"Debian and most other distributions include a `python-pip`_ package, if you " +"want to use the Linux distribution-provided versions of pip see :doc:`/" +"guides/installing-using-linux-tools`." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 -msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" +msgid "" +"You can also install pip yourself to ensure you have the latest version. " +"It's recommended to use the system pip to bootstrap a user installation of " +"pip:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 @@ -2731,7 +3849,9 @@ msgid "Afterwards, you should have the newest pip installed in your user site:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 -msgid "The Python installers for Windows include pip. You should be able to access pip using:" +msgid "" +"The Python installers for Windows include pip. You should be able to access " +"pip using:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 @@ -2743,11 +3863,19 @@ msgid "Installing virtualenv" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 -msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." +msgid "" +"If you are using Python 3.3 or newer, the :mod:`venv` module is the " +"preferred way to create and manage virtual environments. venv is included in " +"the Python standard library and requires no additional installation. If you " +"are using venv, you may skip this section." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 -msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." +msgid "" +":ref:`virtualenv` is used to manage Python packages for different projects. " +"Using virtualenv allows you to avoid installing Python packages globally " +"which could break system tools or other projects. You can install virtualenv " +"using pip." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 @@ -2755,15 +3883,28 @@ msgid "Creating a virtual environment" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 -msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." +msgid "" +":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to " +"manage separate package installations for different projects. They " +"essentially allow you to create a \"virtual\" isolated Python installation " +"and install packages into that virtual installation. When you switch " +"projects, you can simply create a new virtual environment and not have to " +"worry about breaking the packages installed in the other environments. It is " +"always recommended to use a virtual environment while developing Python " +"applications." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 -msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." +msgid "" +"To create a virtual environment, go to your project's directory and run " +"venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the " +"below commands." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 -msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." +msgid "" +"The second argument is the location to create the virtual environment. " +"Generally, you can just create this in your project and call it ``env``." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 @@ -2771,7 +3912,9 @@ msgid "venv will create a virtual Python installation in the ``env`` folder." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 -msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." +msgid "" +"You should exclude your virtual environment directory from your version " +"control system using ``.gitignore`` or similar." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 @@ -2779,15 +3922,24 @@ msgid "Activating a virtual environment" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 -msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." +msgid "" +"Before you can start installing or using packages in your virtual " +"environment you'll need to *activate* it. Activating a virtual environment " +"will put the virtual environment-specific ``python`` and ``pip`` executables " +"into your shell's ``PATH``." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 -msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." +msgid "" +"You can confirm you're in the virtual environment by checking the location " +"of your Python interpreter, it should point to the ``env`` directory." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 -msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." +msgid "" +"As long as your virtual environment is activated pip will install packages " +"into that specific environment and you'll be able to import and use packages " +"in your Python application." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 @@ -2795,11 +3947,16 @@ msgid "Leaving the virtual environment" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 -msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" +msgid "" +"If you want to switch projects or otherwise leave your virtual environment, " +"simply run:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 -msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." +msgid "" +"If you want to re-enter the virtual environment just follow the same " +"instructions above about activating a virtual environment. There's no need " +"to re-create the virtual environment." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 @@ -2807,11 +3964,14 @@ msgid "Installing packages" msgstr "Instalo de pakoj" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 -msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" +msgid "" +"Now that you're in your virtual environment you can install packages. Let's " +"install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 -msgid "pip should download requests and all of its dependencies and install them:" +msgid "" +"pip should download requests and all of its dependencies and install them:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 @@ -2819,7 +3979,10 @@ msgid "Installing specific versions" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 -msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" +msgid "" +"pip allows you to specify which version of a package to install using :term:" +"`version specifiers `. For example, to install a specific " +"version of ``requests``:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 @@ -2835,7 +3998,9 @@ msgid "Installing extras" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 -msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" +msgid "" +"Some packages have optional `extras`_. You can tell pip to install these by " +"specifying the extra in brackets:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 @@ -2847,7 +4012,10 @@ msgid "pip can install a package directly from source, for example:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 -msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" +msgid "" +"Additionally, pip can install packages from source in `development mode`_, " +"meaning that changes to the source directory will immediately affect the " +"installed package without needing to re-install:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 @@ -2855,11 +4023,15 @@ msgid "Installing from version control systems" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 -msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" +msgid "" +"pip can install packages directly from their version control system. For " +"example, you can install directly from a git repository:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 -msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." +msgid "" +"For more information on supported version control systems and syntax, see " +"pip's documentation on :ref:`VCS Support `." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 @@ -2868,15 +4040,23 @@ msgid "Installing from local archives" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 -msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" +msgid "" +"If you have a local copy of a :term:`Distribution Package`'s archive (a zip, " +"wheel, or tar file) you can install it directly with pip:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 -msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" +msgid "" +"If you have a directory containing archives of multiple packages, you can " +"tell pip to look for packages there and not to use the :term:`Python Package " +"Index (PyPI)` at all:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 -msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." +msgid "" +"This is useful if you are installing packages on a system with limited " +"connectivity or if you want to strictly control the origin of distribution " +"packages." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 @@ -2884,11 +4064,16 @@ msgid "Using other package indexes" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 -msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" +msgid "" +"If you want to download packages from a different index than the :term:" +"`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 -msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" +msgid "" +"If you want to allow packages from both the :term:`Python Package Index " +"(PyPI)` and a separate index, you can use the ``--extra-index-url`` flag " +"instead:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 @@ -2897,7 +4082,9 @@ msgid "Upgrading packages" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 -msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" +msgid "" +"pip can upgrade packages in-place using the ``--upgrade`` flag. For example, " +"to install the latest version of ``requests`` and all of its dependencies:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 @@ -2905,11 +4092,16 @@ msgid "Using requirements files" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 -msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" +msgid "" +"Instead of installing packages individually, pip allows you to declare all " +"dependencies in a :ref:`Requirements File `. For " +"example you could create a :file:`requirements.txt` file containing:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 -msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" +msgid "" +"And tell pip to install all of the packages in this file using the ``-r`` " +"flag:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 @@ -2917,7 +4109,9 @@ msgid "Freezing dependencies" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 -msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" +msgid "" +"Pip can export a list of all installed packages and their versions using the " +"``freeze`` command:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 @@ -2925,7 +4119,9 @@ msgid "Which will output a list of package specifiers such as:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 -msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." +msgid "" +"This is useful for creating :ref:`pip:Requirements Files` that can re-create " +"the exact versions of all packages installed in an environment." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:2 @@ -2933,7 +4129,11 @@ msgid "Making a PyPI-friendly README" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:4 -msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." +msgid "" +"README files can help your users understand your project and can be used to " +"set your project's description on PyPI. This guide helps you create a README " +"in a PyPI-friendly format and include your README in your package so it " +"appears on PyPI." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:9 @@ -2941,11 +4141,16 @@ msgid "Creating a README file" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:11 -msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." +msgid "" +"README files for Python projects are often named ``README``, ``README.txt``, " +"``README.rst``, or ``README.md``." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:13 -msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" +msgid "" +"For your README to display properly on PyPI, choose a markup language " +"supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:16 @@ -2953,15 +4158,21 @@ msgid "plain text" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:17 -msgid "`reStructuredText `_ (without Sphinx extensions)" +msgid "" +"`reStructuredText `_ (without " +"Sphinx extensions)" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:18 -msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" +msgid "" +"Markdown (`GitHub Flavored Markdown `_ by " +"default, or `CommonMark `_)" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:21 -msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." +msgid "" +"It's customary to save your README file in the root of your project, in the " +"same directory as your :file:`setup.py` file." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:25 @@ -2969,7 +4180,10 @@ msgid "Including your README in your package's metadata" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:27 -msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." +msgid "" +"To include your README's contents as your package description, set your " +"project's ``Description`` and ``Description-Content-Type`` metadata, " +"typically in your project's :file:`setup.py` file." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:33 @@ -2981,15 +4195,23 @@ msgid ":ref:`description-content-type-optional`" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:36 -msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." +msgid "" +"For example, to set these values in a package's :file:`setup.py` file, use " +"``setup()``'s ``long_description`` and ``long_description_content_type``." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:39 -msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." +msgid "" +"Set the value of ``long_description`` to the contents (not the path) of the " +"README file itself. Set the ``long_description_content_type`` to an accepted " +"``Content-Type``-style value for your README file's markup, such as ``text/" +"plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:45 -msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" +msgid "" +"If you're using GitHub-flavored Markdown to write a project's description, " +"ensure you upgrade the following tools:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:60 @@ -3009,11 +4231,16 @@ msgid "``twine >= 1.11.0``" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:66 -msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" +msgid "" +"It's recommended that you use ``twine`` to upload the project's distribution " +"packages:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:72 -msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" +msgid "" +"For example, see this :file:`setup.py` file, which reads the contents of :" +"file:`README.md` as ``long_description`` and identifies the markup as GitHub-" +"flavored Markdown:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:95 @@ -3021,23 +4248,36 @@ msgid "Validating reStructuredText markup" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:97 -msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." +msgid "" +"If your README is written in reStructuredText, any invalid markup will " +"prevent it from rendering, causing PyPI to instead just show the README's " +"raw source." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:100 -msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." +msgid "" +"Note that Sphinx extensions used in docstrings, such as `directives and " +"roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```" +"\"), are not allowed here and will result in error messages like \"``Error: " +"Unknown interpreted text role \"py:func\".``\"." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:105 -msgid "You can check your README for markup errors before uploading as follows:" +msgid "" +"You can check your README for markup errors before uploading as follows:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:107 -msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" +msgid "" +"Install the latest version of `twine `_; " +"version 1.12.0 or higher is required:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:122 -msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." +msgid "" +"Build the sdist and wheel for your project as described under :ref:" +"`Packaging Your Project`." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:125 @@ -3045,7 +4285,10 @@ msgid "Run ``twine check`` on the sdist and wheel::" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:129 -msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." +msgid "" +"This command will report any problems rendering your README. If your markup " +"renders fine, the command will output ``Checking distribution FILENAME: " +"Passed``." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:4 @@ -3053,7 +4296,11 @@ msgid "Migrating to PyPI.org" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:6 -msgid ":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``." +msgid "" +":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``." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:12 @@ -3065,15 +4312,21 @@ msgid "``pypi.org`` is the default upload platform as of September 2016." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:16 -msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." +msgid "" +"Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. " +"As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:19 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:22 -msgid "The default upload settings switched to ``pypi.org`` in the following versions:" +msgid "" +"The default upload settings switched to ``pypi.org`` in the following " +"versions:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:24 @@ -3101,19 +4354,32 @@ msgid "Python 3.6.0 (``distutils`` update)" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:31 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:48 -msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." +msgid "" +"Then simply delete the line starting with ``repository`` and you will use " +"your upload tool's default URL." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:51 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:67 -msgid "(``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.)" +msgid "" +"(``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.)" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:73 @@ -3121,15 +4387,22 @@ msgid "Registering package names & metadata" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:75 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:79 -msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" +msgid "" +"As a result, attempting explicit registration after switching to using PyPI." +"org for uploads will give the following error message::" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:84 -msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." +msgid "" +"The solution is to skip the registration step, and proceed directly to " +"uploading artifacts." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:89 @@ -3138,7 +4411,12 @@ msgid "Using TestPyPI" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:91 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:113 @@ -3146,7 +4424,10 @@ msgid "Registering new user accounts" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:115 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:121 @@ -3154,7 +4435,11 @@ msgid "Browsing packages" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:123 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:130 @@ -3170,7 +4455,9 @@ msgid "Managing published packages and releases" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:137 -msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." +msgid "" +"``pypi.org`` provides a fully functional interface for logged in users to " +"manage their published packages and releases." msgstr "" #: ../source/guides/multi-version-installs.rst:5 @@ -3178,23 +4465,51 @@ msgid "Multi-version installs" msgstr "" #: ../source/guides/multi-version-installs.rst:8 -msgid "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``)." +msgid "" +"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``)." msgstr "" #: ../source/guides/multi-version-installs.rst:13 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/multi-version-installs.rst:19 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/multi-version-installs.rst:31 -msgid "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 ``python -c ''`` to invoke the application's main entry point directly." +msgid "" +"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 ``python -c ''`` to invoke the application's main " +"entry point directly." msgstr "" #: ../source/guides/multi-version-installs.rst:38 -msgid "Refer to the `pkg_resources documentation `__ for more details." +msgid "" +"Refer to the `pkg_resources documentation `__ for more details." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:5 @@ -3206,7 +4521,12 @@ msgid "2013-12-08" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:10 -msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." +msgid "" +"One of the features of the CPython reference interpreter is that, in " +"addition to allowing the execution of Python code, it also exposes a rich C " +"API for use by other software. One of the most common uses of this C API is " +"to create importable C extensions that allow things which aren't always easy " +"to achieve in pure Python code." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:20 @@ -3218,27 +4538,66 @@ msgid "Use cases" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:25 -msgid "The typical use cases for binary extensions break down into just three conventional categories:" +msgid "" +"The typical use cases for binary extensions break down into just three " +"conventional categories:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:28 -msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." +msgid "" +"**accelerator modules**: these modules are completely self-contained, and " +"are created solely to run faster than the equivalent pure Python code runs " +"in CPython. Ideally, accelerator modules will always have a pure Python " +"equivalent to use as a fallback if the accelerated version isn't available " +"on a given system. The CPython standard library makes extensive use of " +"accelerator modules. *Example*: When importing ``datetime``, Python falls " +"back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not " +"available." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:39 -msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." +msgid "" +"**wrapper modules**: these modules are created to expose existing C " +"interfaces to Python code. They may either expose the underlying C interface " +"directly, or else expose a more \"Pythonic\" API that makes use of Python " +"language features to make the API easier to use. The CPython standard " +"library makes extensive use of wrapper modules. *Example*: `functools.py " +"`_ is a " +"Python module wrapper for `_functoolsmodule.c `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:47 -msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." +msgid "" +"**low-level system access**: these modules are created to access lower level " +"features of the CPython runtime, the operating system, or the underlying " +"hardware. Through platform specific code, extension modules may achieve " +"things that aren't possible in pure Python code. A number of CPython " +"standard library modules are written in C in order to access interpreter " +"internals that aren't exposed at the language level. *Example*: ``sys``, " +"which comes from `sysmodule.c `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:56 -msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." +msgid "" +"One particularly notable feature of C extensions is that, when they don't " +"need to call back into the interpreter runtime, they can release CPython's " +"global interpreter lock around long-running operations (regardless of " +"whether those operations are CPU or IO bound)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:61 -msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." +msgid "" +"Not all extension modules will fit neatly into the above categories. The " +"extension modules included with NumPy, for example, span all three use cases " +"- they move inner loops to C for speed reasons, wrap external libraries " +"written in C, FORTRAN and other languages, and use low level system " +"interfaces for both CPython and the underlying operation system to support " +"concurrent execution of vectorised operations and to tightly control the " +"exact memory layout of created objects." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:71 @@ -3246,7 +4605,13 @@ msgid "Disadvantages" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:73 -msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." +msgid "" +"The main disadvantage of using binary extensions is the fact that it makes " +"subsequent distribution of the software more difficult. One of the " +"advantages of using Python is that it is largely cross platform, and the " +"languages used to write extension modules (typically C or C++, but really " +"any language that can bind to the CPython C API) typically require that " +"custom binaries be created for different platforms." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:80 @@ -3254,27 +4619,44 @@ msgid "This means that binary extensions:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:82 -msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" +msgid "" +"require that end users be able to either build them from source, or else " +"that someone publish pre-built binaries for common platforms" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:85 -msgid "may not be compatible with different builds of the CPython reference interpreter" +msgid "" +"may not be compatible with different builds of the CPython reference " +"interpreter" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:88 -msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" +msgid "" +"often will not work correctly with alternative interpreters such as PyPy, " +"IronPython or Jython" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:91 -msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." +msgid "" +"if handcoded, make maintenance more difficult by requiring that maintainers " +"be familiar not only with Python, but also with the language used to create " +"the binary extension, as well as with the details of the CPython C API." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:96 -msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." +msgid "" +"if a pure Python fallback implementation is provided, make maintenance more " +"difficult by requiring that changes be implemented in two places, and " +"introducing additional complexity in the test suite to ensure both versions " +"are always executed." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:101 -msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." +msgid "" +"Another disadvantage of relying on binary extensions is that alternative " +"import mechanisms (such as the ability to import modules directly from " +"zipfiles) often won't work for extension modules (as the dynamic loading " +"mechanisms on most platforms can only load libraries from disk)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:108 @@ -3282,23 +4664,56 @@ msgid "Alternatives to handcoded accelerator modules" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:110 -msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" +msgid "" +"When extension modules are just being used to make code run faster (after " +"profiling has identified the code where the speed increase is worth " +"additional maintenance effort), a number of other alternatives should also " +"be considered:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:115 -msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." +msgid "" +"look for existing optimised alternatives. The CPython standard library " +"includes a number of optimised data structures and algorithms (especially in " +"the builtins and the ``collections`` and ``itertools`` modules). The Python " +"Package Index also offers additional alternatives. Sometimes, the " +"appropriate choice of standard library or third party module can avoid the " +"need to create your own accelerator module." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:122 -msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." +msgid "" +"for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython " +"runtime. The main barrier to adopting PyPy is typically reliance on other " +"binary extension modules - while PyPy does emulate the CPython C API, " +"modules that rely on that cause problems for the PyPy JIT, and the emulation " +"layer can often expose latent defects in extension modules that CPython " +"currently tolerates (frequently around reference counting errors - an object " +"having one live reference instead of two often won't break anything, but no " +"references instead of one is a major problem)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:132 -msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." +msgid "" +"`Cython `__ is a mature static compiler that can compile " +"most Python code to C extension modules. The initial compilation provides " +"some speed increases (by bypassing the CPython interpreter layer), and " +"Cython's optional static typing features can offer additional opportunities " +"for speed increases. Using Cython still has the disadvantage of increasing " +"the complexity of distributing the resulting application, but has the " +"benefit of having a reduced barrier to entry for Python programmers " +"(relative to other languages like C or C++)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:141 -msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." +msgid "" +"`Numba `__ is a newer tool, created by members of " +"the scientific Python community, that aims to leverage LLVM to allow " +"selective compilation of pieces of a Python application to native machine " +"code at runtime. It requires that LLVM be available on the system where the " +"code is running, but can provide significant speed increases, especially for " +"operations that are amenable to vectorisation." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:150 @@ -3306,35 +4721,74 @@ msgid "Alternatives to handcoded wrapper modules" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:152 -msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." +msgid "" +"The C ABI (Application Binary Interface) is a common standard for sharing " +"functionality between multiple applications. One of the strengths of the " +"CPython C API (Application Programming Interface) is allowing Python users " +"to tap into that functionality. However, wrapping modules by hand is quite " +"tedious, so a number of other alternative approaches should be considered." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:158 -msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." +msgid "" +"The approaches described below don't simplify the distribution case at all, " +"but they *can* significantly reduce the maintenance burden of keeping " +"wrapper modules up to date." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:162 -msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." +msgid "" +"In addition to being useful for the creation of accelerator modules, `Cython " +"`__ is also useful for creating wrapper modules for C or " +"C++. It still involves wrapping the interfaces by hand, however, and is very " +"repetitive, so may not be a good choice for wrapping large APIs." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:168 -msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." +msgid "" +"`pybind11 `__ is a pure C++11 library that " +"provides a clean C++ interface to the CPython (and PyPy) C API. It does not " +"require a pre-processing step; it is written entirely in templated C++. " +"Helpers are included for Setuptools or CMake builds. It was based on `Boost." +"Python `__, but doesn't require the Boost libraries or BJam." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:175 -msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." +msgid "" +"`cffi `__ is a project created by some of the " +"PyPy developers to make it straightforward for developers that already know " +"both Python and C to expose their C modules to Python applications. It also " +"makes it relatively straightforward to wrap a C module based on its header " +"files, even if you don't know C yourself." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:181 -msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." +msgid "" +"One of the key advantages of ``cffi`` is that it is compatible with the PyPy " +"JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing " +"JIT optimisations." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:185 -msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." +msgid "" +"`SWIG `__ is a wrapper interface generator that allows " +"a variety of programming languages, including Python, to interface with C " +"and C++ code." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:189 -msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." +msgid "" +"The standard library's ``ctypes`` module, while useful for getting access to " +"C level interfaces when header information isn't available, suffers from the " +"fact that it operates solely at the C ABI level, and thus has no automatic " +"consistency checking between the interface actually being exported by the " +"library and the one declared in the Python code. By contrast, the above " +"alternatives are all able to operate at the C *API* level, using C header " +"files to ensure consistency between the interface exported by the library " +"being wrapped and the one expected by the Python wrapper module. While " +"``cffi`` *can* operate directly at the C ABI level, it suffers from the same " +"interface inconsistency problems as ``ctypes`` when it is used that way." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:203 @@ -3342,11 +4796,24 @@ msgid "Alternatives for low level system access" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:205 -msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." +msgid "" +"For applications that need low level system access (regardless of the " +"reason), a binary extension module often *is* the best way to go about it. " +"This is particularly true for low level access to the CPython runtime " +"itself, since some operations (like releasing the Global Interpreter Lock) " +"are simply invalid when the interpreter is running code, even if a module " +"like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API " +"interfaces." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:213 -msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." +msgid "" +"For cases where the extension module is manipulating the underlying " +"operating system or hardware (rather than the CPython runtime), it may " +"sometimes be better to just write an ordinary C library (or a library in " +"another systems programming language like C++ or Rust that can export a C " +"compatible ABI), and then use one of the wrapping techniques described above " +"to make the interface available as an importable Python module." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:222 @@ -3354,7 +4821,10 @@ msgid "Implementing binary extensions" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:224 -msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." +msgid "" +"The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in " +"C `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:241 @@ -3366,7 +4836,14 @@ msgid "Building extensions for multiple platforms" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:246 -msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." +msgid "" +"If you plan to distribute your extension, you should provide :term:`wheels " +"` for all the platforms you intend to support. For most extensions, " +"this is at least one package per Python version times the number of OS and " +"architectures you support. These are usually built on continuous " +"integration (CI) systems. There are tools to help you build highly " +"redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:" +"`multibuild`." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:256 @@ -3374,15 +4851,27 @@ msgid "Binary extensions for Windows" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:258 -msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." +msgid "" +"Before it is possible to build a binary extension, it is necessary to ensure " +"that you have a suitable compiler available. On Windows, Visual C is used to " +"build the official CPython interpreter, and should be used to build " +"compatible binary extensions." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:263 -msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." +msgid "" +"Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio " +"2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older " +"versions of Visual Studio are no longer easily available from Microsoft, so " +"for versions of Python prior to 3.5, the compilers must be obtained " +"differently if you do not already have a copy of the relevant version of " +"Visual Studio." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:269 -msgid "To set up a build environment for binary extensions, the steps are as follows:" +msgid "" +"To set up a build environment for binary extensions, the steps are as " +"follows:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:271 @@ -3390,11 +4879,16 @@ msgid "For Python 2.7" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:273 -msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." +msgid "" +"Install \"Visual C++ Compiler Package for Python 2.7\", which is available " +"from `Microsoft's website `__." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:276 -msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." +msgid "" +"Use (a recent version of) setuptools in your setup.py (pip will do this for " +"you, in any case)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:278 @@ -3408,11 +4902,16 @@ msgid "For Python 3.4" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:282 -msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." +msgid "" +"Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is " +"available from `Microsoft's website `__." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:285 -msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." +msgid "" +"Work from an SDK command prompt (with the environment variables set, and the " +"SDK on PATH)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:287 @@ -3424,15 +4923,23 @@ msgid "For Python 3.5" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:292 -msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." +msgid "" +"Install `Visual Studio 2015 Community Edition `__ (or any later version, " +"when these are released)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:297 -msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." +msgid "" +"Note that from Python 3.5 onwards, Visual Studio works in a backward " +"compatible way, which means that any future version of Visual Studio will be " +"able to build Python extensions for all Python versions from 3.5 onwards." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:301 -msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." +msgid "" +"Building with the recommended compiler on Windows ensures that a compatible " +"C library is used throughout the Python process." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:305 @@ -3440,7 +4947,11 @@ msgid "Binary extensions for Linux" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:307 -msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." +msgid "" +"Linux binaries must use a sufficiently old glibc to be compatible with older " +"distributions. The `manylinux `_ Docker " +"images provide a build environment with a glibc old enough to support most " +"current Linux distributions on common architectures." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:313 @@ -3448,7 +4959,15 @@ msgid "Binary extensions for macOS" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:315 -msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." +msgid "" +"Binary compatibility on macOS is determined by the target minimum deployment " +"system, e.g. *10.9*, which is often specified with the " +"``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries " +"on macOS. When building with setuptools / distutils, the deployment target " +"is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For " +"common deployment targets for macOS Python distributions, see the `MacPython " +"Spinning Wheels wiki `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:325 @@ -3456,7 +4975,9 @@ msgid "Publishing binary extensions" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:327 -msgid "For interim guidance on this topic, see the discussion in `this issue `_." +msgid "" +"For interim guidance on this topic, see the discussion in `this issue " +"`_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:343 @@ -3464,7 +4985,13 @@ msgid "Additional resources" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:345 -msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." +msgid "" +"Cross-platform development and distribution of extension modules is a " +"complex topic, so this guide focuses primarily on providing pointers to " +"various tools that automate dealing with the underlying technical " +"challenges. The additional resources in this section are instead intended " +"for developers looking to understand more about the underlying binary " +"interfaces that those systems rely on at runtime." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:352 @@ -3472,7 +4999,13 @@ msgid "Cross-platform wheel generation with scikit-build" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:354 -msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." +msgid "" +"The `scikit-build `_ package " +"helps abstract cross-platform build operations and provides additional " +"capabilities when creating binary extension packages. Additional " +"documentation is also available on the `C runtime, compiler, and build " +"system generator `_ for Python binary extension modules." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:362 @@ -3480,11 +5013,15 @@ msgid "Introduction to C/C++ extension modules" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:364 -msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" +msgid "" +"For a more in depth explanation of how extension modules are used by CPython " +"on a Debian system, see the following articles:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:367 -msgid "`What are (c)python extension modules? `_" +msgid "" +"`What are (c)python extension modules? `_" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:368 @@ -3492,7 +5029,9 @@ msgid "`Releasing the gil `_" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:369 -msgid "`Writing cpython extension modules using C++ `_" +msgid "" +"`Writing cpython extension modules using C++ `_" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:3 @@ -3500,7 +5039,12 @@ msgid "Packaging namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:5 -msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" +msgid "" +"Namespace packages allow you to split the sub-packages and modules within a " +"single :term:`package ` across multiple, separate :term:" +"`distribution packages ` (referred to as " +"**distributions** in this document to avoid ambiguity). For example, if you " +"have the following package structure:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:24 @@ -3516,7 +5060,14 @@ msgid "Each sub-package can now be separately installed, used, and versioned." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:48 -msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." +msgid "" +"Namespace packages can be useful for a large collection of loosely-related " +"packages (such as a large corpus of client libraries for multiple products " +"from a single company). However, namespace packages come with several " +"caveats and are not appropriate in all cases. A simple alternative is to use " +"a prefix on all of your distributions such as ``import " +"mynamespace_subpackage_a`` (you could even use ``import " +"mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:58 @@ -3524,23 +5075,39 @@ msgid "Creating a namespace package" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:60 -msgid "There are currently three different approaches to creating namespace packages:" +msgid "" +"There are currently three different approaches to creating namespace " +"packages:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:62 -msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." +msgid "" +"Use `native namespace packages`_. This type of namespace package is defined " +"in :pep:`420` and is available in Python 3.3 and later. This is recommended " +"if packages in your namespace only ever need to support Python 3 and " +"installation via ``pip``." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:66 -msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." +msgid "" +"Use `pkgutil-style namespace packages`_. This is recommended for new " +"packages that need to support Python 2 and 3 and installation via both " +"``pip`` and ``python setup.py install``." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:69 -msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." +msgid "" +"Use `pkg_resources-style namespace packages`_. This method is recommended if " +"you need compatibility with packages already using this method or if your " +"package needs to be zip-safe." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:73 -msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." +msgid "" +"While native namespace packages and pkgutil-style namespace packages are " +"largely compatible, pkg_resources-style namespace packages are not " +"compatible with the other methods. It's inadvisable to use different methods " +"in different distributions that provide packages to the same namespace." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:80 @@ -3548,23 +5115,41 @@ msgid "Native namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:82 -msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" +msgid "" +"Python 3.3 added **implicit** namespace packages from :pep:`420`. All that " +"is required to create a native namespace package is that you just omit :file:" +"`__init__.py` from the namespace package directory. An example file " +"structure:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:97 -msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." +msgid "" +"It is extremely important that every distribution that uses the namespace " +"package omits the :file:`__init__.py` or uses a pkgutil-style :file:" +"`__init__.py`. If any distribution does not, it will cause the namespace " +"logic to fail and the other sub-packages will not be importable." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:102 -msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" +msgid "" +"Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:" +"`setuptools.find_packages` won't find the sub-package. You must use :func:" +"`setuptools.find_namespace_packages` instead or explicitly list all packages " +"in your :file:`setup.py`. For example:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:117 -msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." +msgid "" +"A complete working example of two native namespace packages can be found in " +"the `native namespace package example project`_." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:123 -msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." +msgid "" +"Because native and pkgutil-style namespace packages are largely compatible, " +"you can use native namespace packages in the distributions that only support " +"Python 3 and pkgutil-style namespace packages in the distributions that need " +"to support Python 2 and 3." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:129 @@ -3572,25 +5157,39 @@ msgid "pkgutil-style namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:131 -msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." +msgid "" +"Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. " +"This can be used to declare namespace packages that need to be compatible " +"with both Python 2.3+ and Python 3. This is the recommended approach for the " +"highest level of compatibility." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:136 -msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgid "" +"To create a pkgutil-style namespace package, you need to provide an :file:" +"`__init__.py` file for the namespace package:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:148 #: ../source/guides/packaging-namespace-packages.rst:194 -msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" +msgid "" +"The :file:`__init__.py` file for the namespace package needs to contain " +"**only** the following:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:155 #: ../source/guides/packaging-namespace-packages.rst:201 -msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." +msgid "" +"**Every** distribution that uses the namespace package must include an " +"identical :file:`__init__.py`. If any distribution does not, it will cause " +"the namespace logic to fail and the other sub-packages will not be " +"importable. Any additional code in :file:`__init__.py` will be inaccessible." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:160 -msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." +msgid "" +"A complete working example of two pkgutil-style namespace packages can be " +"found in the `pkgutil namespace example project`_." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:171 @@ -3598,39 +5197,68 @@ msgid "pkg_resources-style namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:173 -msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." +msgid "" +"`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and " +"the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together " +"these can be used to declare namespace packages. While this approach is no " +"longer recommended, it is widely present in most existing namespace " +"packages. If you are creating a new distribution within an existing " +"namespace package that uses this method then it's recommended to continue " +"using this as the different methods are not cross-compatible and it's not " +"advisable to try to migrate an existing package." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:182 -msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgid "" +"To create a pkg_resources-style namespace package, you need to provide an :" +"file:`__init__.py` file for the namespace package:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:206 -msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" +msgid "" +"Some older recommendations advise the following in the namespace package :" +"file:`__init__.py`:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:216 -msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." +msgid "" +"The idea behind this was that in the rare case that setuptools isn't " +"available packages would fall-back to the pkgutil-style packages. This isn't " +"advisable because pkgutil and pkg_resources-style namespace packages are not " +"cross-compatible. If the presence of setuptools is a concern then the " +"package should just explicitly depend on setuptools via ``install_requires``." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:223 -msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" +msgid "" +"Finally, every distribution must provide the ``namespace_packages`` argument " +"to :func:`~setuptools.setup` in :file:`setup.py`. For example:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:237 -msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." +msgid "" +"A complete working example of two pkg_resources-style namespace packages can " +"be found in the `pkg_resources namespace example project`_." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 -msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" +msgid "" +"Publishing package distribution releases using GitHub Actions CI/CD workflows" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 -msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." +msgid "" +"`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an " +"event occurs on the GitHub platform. One popular choice is having a workflow " +"that's triggered by a ``push`` event. This guide shows you how to publish a " +"Python distribution whenever a tagged commit is pushed. It will use the " +"`pypa/gh-action-pypi-publish GitHub Action`_." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 -msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." +msgid "" +"This guide *assumes* that you already have a project that you know how to " +"build distributions for and *it lives on GitHub*." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 @@ -3638,7 +5266,10 @@ msgid "Saving credentials on GitHub" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 -msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." +msgid "" +"In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, " +"meaning that we'll have two separate sets of credentials. And we'll need to " +"save them in the GitHub repository settings." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 @@ -3646,23 +5277,37 @@ msgid "Let's begin! 🚀" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" +msgid "" +"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " +"token`_. If you have the project on PyPI already, limit the token scope to " +"just that project. You can call it something like ``GitHub Actions CI/CD — " +"project-org/project-repo`` in order for it to be easily distinguishable in " +"the token list. **Don't close the page just yet — you won't see that token " +"again.**" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 -msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." +msgid "" +"In a separate browser tab or window, go to the ``Settings`` tab of your " +"target repository and then click on `Secrets`_ in the left sidebar." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 -msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." +msgid "" +"Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from " +"the first step." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 -msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." +msgid "" +"Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the " +"steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 -msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." +msgid "" +"If you don't have a TestPyPI account, you'll need to create it. It's not the " +"same as a regular PyPI account." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 @@ -3670,7 +5315,9 @@ msgid "Creating a workflow definition" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 -msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." +msgid "" +"GitHub CI/CD workflows are declared in YAML files stored in the ``.github/" +"workflows/`` directory of your repository." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 @@ -3678,7 +5325,9 @@ msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 -msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" +msgid "" +"Start it with a meaningful name and define the event that should make GitHub " +"run this workflow:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 @@ -3686,7 +5335,9 @@ msgid "Defining a workflow job environment" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 -msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" +msgid "" +"Now, let's add initial setup for our job. It's a process that will execute " +"commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 @@ -3698,15 +5349,22 @@ msgid "Then, add the following under the ``build-n-publish`` section:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 -msgid "This will download your repository into the CI runner and then install and activate Python 3.7." +msgid "" +"This will download your repository into the CI runner and then install and " +"activate Python 3.7." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 -msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." +msgid "" +"And now we can build dists from source. In this example, we'll use ``build`` " +"package, assuming that your project has a ``pyproject.toml`` properly set up " +"(see :pep:`517`/:pep:`518`)." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 -msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." +msgid "" +"You can use any other method for building distributions as long as it " +"produces ready-to-upload artifacts saved into the ``dist/`` folder." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 @@ -3722,7 +5380,11 @@ msgid "Finally, add the following steps at the end:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 -msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." +msgid "" +"These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the " +"first one uploads contents of the ``dist/`` folder into TestPyPI " +"unconditionally and the second does that to PyPI, but only if the current " +"commit is tagged." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 @@ -3730,7 +5392,11 @@ msgid "That's all, folks!" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 -msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" +msgid "" +"Now, whenever you push a tagged commit to your Git repository remote on " +"GitHub, this workflow will publish it to PyPI. And it'll publish any push to " +"TestPyPI which is useful for providing test builds to your alpha users as " +"well as making sure that your release pipeline remains healthy!" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:5 @@ -3738,87 +5404,143 @@ msgid "Single-sourcing the package version" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:8 -msgid "There are many techniques to maintain a single source of truth for the version number of your project:" +msgid "" +"There are many techniques to maintain a single source of truth for the " +"version number of your project:" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:11 -msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" +msgid "" +"Read the file in :file:`setup.py` and get the version. Example (from `pip " +"setup.py `_)::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:38 -msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" +msgid "" +"As of the release of setuptools 46.4.0, one can accomplish the same thing by " +"instead placing the following in the project's ``setup.cfg`` file (replacing " +"\"package\" with the import name of the package):" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:47 -msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." +msgid "" +"Earlier versions of setuptools implemented the ``attr:`` directive by " +"importing the module, but setuptools 46.4.0 added rudimentary AST analysis " +"so that ``attr:`` can function without having to import any of the package's " +"dependencies." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:52 -msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." +msgid "" +"Also, please be aware that declarative config indicators, including the " +"``attr:`` directive, are not supported in parameters to ``setup.py``." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:55 -msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." +msgid "" +"Use an external build tool that either manages updating both locations, or " +"offers an API that both locations can use." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:58 -msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." +msgid "" +"Few tools you could use, in no particular order, and not necessarily " +"complete: `bump2version `_, `changes " +"`_, `commitizen `_, `zest.releaser `_." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:65 -msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." +msgid "" +"Set the value to a ``__version__`` global variable in a dedicated module in " +"your project (e.g. :file:`version.py`), then have :file:`setup.py` read and " +"``exec`` the value into a variable." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:76 -msgid "Example using this technique: `warehouse `_." +msgid "" +"Example using this technique: `warehouse `_." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:78 -msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." +msgid "" +"Place the value in a simple ``VERSION`` text file and have both :file:`setup." +"py` and the project code read it." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:86 -msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." +msgid "" +"An advantage with this technique is that it's not specific to Python. Any " +"tool can read the version." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:91 -msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." +msgid "" +"With this approach you must make sure that the ``VERSION`` file is included " +"in all your source and binary distributions (e.g. add ``include VERSION`` to " +"your :file:`MANIFEST.in`)." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:95 -msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" +msgid "" +"Set the value in :file:`setup.py`, and have the project code use the " +"``importlib.metadata`` API to fetch the value at runtime. (``importlib." +"metadata`` was introduced in Python 3.8 and is available to older versions " +"as the ``importlib-metadata`` project.) An installed project's version can " +"be fetched with the API as follows::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:110 -msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." +msgid "" +"Be aware that the ``importlib.metadata`` API only knows about what's in the " +"installation metadata, which is not necessarily the code that's currently " +"imported." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:114 -msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" +msgid "" +"If a project uses this method to fetch its version at runtime, then its " +"``install_requires`` value needs to be edited to install ``importlib-" +"metadata`` on pre-3.8 versions of Python like so::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:128 -msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" +msgid "" +"An older (and less efficient) alternative to ``importlib.metadata`` is the " +"``pkg_resources`` API provided by ``setuptools``::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:134 -msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." +msgid "" +"If a project uses ``pkg_resources`` to fetch its own version at runtime, " +"then ``setuptools`` must be added to the project's ``install_requires`` list." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:138 -msgid "Example using this technique: `setuptools `_." +msgid "" +"Example using this technique: `setuptools `_." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:141 -msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." +msgid "" +"Set the value to ``__version__`` in ``sample/__init__.py`` and import " +"``sample`` in :file:`setup.py`." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:155 -msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." +msgid "" +"Although this technique is common, beware that it will fail if ``sample/" +"__init__.py`` imports packages from ``install_requires`` dependencies, which " +"will very likely not be installed yet when :file:`setup.py` is run." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:161 -msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." +msgid "" +"Keep the version number in the tags of a version control system (Git, " +"Mercurial, etc) instead of in the code, and automatically extract it from " +"there using `setuptools_scm `_." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:5 @@ -3826,11 +5548,20 @@ msgid "Supporting multiple Python versions" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:37 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:43 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:49 @@ -3838,31 +5569,52 @@ msgid "Automated testing and continuous integration" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:51 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:56 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:60 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:66 -msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." +msgid "" +"`Travis CI `_ provides both a Linux and a macOS " +"environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit " +"while the macOS is 10.9.2 at the time of writing." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:69 -msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." +msgid "" +"`Appveyor `_ provides a Windows environment " +"(Windows Server 2012)." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:80 -msgid "Both `Travis CI`_ 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." +msgid "" +"Both `Travis CI`_ 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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:85 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:89 @@ -3870,11 +5622,24 @@ msgid "Tools for single-source Python packages" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:91 -msgid "`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_." +msgid "" +"`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_." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:100 -msgid "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" +msgid "" +"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" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:107 @@ -3886,11 +5651,22 @@ msgid "a Python 3 (by syntax) module in a *Python 2* project." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:110 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:117 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:124 @@ -3898,7 +5674,13 @@ msgid "What's in which Python?" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:126 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:3 @@ -3910,19 +5692,37 @@ msgid "2015-12-03" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:8 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:20 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:24 -msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." +msgid "" +"The Appveyor service is a continuous integration service, much like the " +"better-known `Travis`_ service that is commonly used for testing by projects " +"hosted on `Github`_. However, unlike Travis, the build workers on Appveyor " +"are Windows hosts and have the necessary compilers installed to build Python " +"extensions." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:30 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:38 @@ -3930,15 +5730,25 @@ msgid "Setting up" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:40 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:45 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:49 -msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." +msgid "" +"Once you have set up your Appveyor account and added your project, Appveyor " +"will automatically build your project each time a commit occurs. This " +"behaviour will be familiar to users of Travis." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:54 @@ -3946,11 +5756,22 @@ msgid "Adding Appveyor support to your project" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:56 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:61 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:69 @@ -3958,39 +5779,74 @@ msgid "appveyor.yml" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:75 -msgid "This file can be downloaded from `here `__." +msgid "" +"This file can be downloaded from `here `__." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:77 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:80 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:88 -msgid "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``)." +msgid "" +"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``)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:94 -msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." +msgid "" +"The ``build`` section simply switches off builds - there is no build step " +"needed for Python, unlike languages like ``C#``." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:97 -msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." +msgid "" +"The main sections that will need to be tailored to your project are " +"``test_script`` and ``after_test``." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:100 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:109 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:114 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:119 @@ -3998,15 +5854,29 @@ msgid "Support script" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:121 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:126 -msgid "`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." +msgid "" +"`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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:133 -msgid "You can simply download the batch file and include it in your project unchanged." +msgid "" +"You can simply download the batch file and include it in your project " +"unchanged." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:137 @@ -4014,7 +5884,14 @@ msgid "Access to the built wheels" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:139 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:147 @@ -4026,19 +5903,33 @@ msgid "Testing with tox" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:152 -msgid "Many projects use the `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." +msgid "" +"Many projects use the `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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:156 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:160 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:165 -msgid "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" +msgid "" +"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" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:170 @@ -4058,23 +5949,46 @@ msgid "``LIB``" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:175 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:181 -msgid "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 Travis or 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)." +msgid "" +"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 Travis or 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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:188 -msgid "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``." +msgid "" +"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``." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:192 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:197 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:203 @@ -4082,11 +5996,19 @@ msgid "Automatically uploading wheels" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:205 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:210 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:216 @@ -4094,11 +6016,19 @@ msgid "External dependencies" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:218 -msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." +msgid "" +"The supplied scripts will successfully build any distribution that does not " +"rely on 3rd party external libraries for the build." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:221 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:230 @@ -4118,7 +6048,9 @@ msgid "Tool recommendations" msgstr "" #: ../source/guides/tool-recommendations.rst:7 -msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." +msgid "" +"If you're familiar with Python packaging and installation, and just want to " +"know what tools are currently recommended, then here it is." msgstr "" #: ../source/guides/tool-recommendations.rst:12 @@ -4126,7 +6058,10 @@ msgid "Application dependency management" msgstr "" #: ../source/guides/tool-recommendations.rst:14 -msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." +msgid "" +"Use :ref:`pipenv` to manage library dependencies when developing Python " +"applications. See :doc:`../tutorials/managing-dependencies` for more details " +"on using ``pipenv``." msgstr "" #: ../source/guides/tool-recommendations.rst:18 @@ -4150,15 +6085,23 @@ msgid "Installation tool recommendations" msgstr "" #: ../source/guides/tool-recommendations.rst:29 -msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" +msgid "" +"Use :ref:`pip` to install Python :term:`packages ` " +"from :term:`PyPI `. [1]_ [2]_ Depending on how :" +"ref:`pip` is installed, you may need to also install :ref:`wheel` to get the " +"benefit of wheel caching. [3]_" msgstr "" #: ../source/guides/tool-recommendations.rst:34 -msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" +msgid "" +"Use :ref:`virtualenv`, or `venv`_ to isolate application specific " +"dependencies from a shared Python installation. [4]_" msgstr "" #: ../source/guides/tool-recommendations.rst:37 -msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" +msgid "" +"If you're looking for management of fully integrated cross-platform software " +"stacks, consider:" msgstr "" #: ../source/guides/tool-recommendations.rst:40 @@ -4166,7 +6109,9 @@ msgid ":ref:`buildout`: primarily focused on the web development community" msgstr "" #: ../source/guides/tool-recommendations.rst:42 -msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." +msgid "" +":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the " +"scientific community." msgstr "" #: ../source/guides/tool-recommendations.rst:47 @@ -4174,15 +6119,22 @@ msgid "Packaging tool recommendations" msgstr "" #: ../source/guides/tool-recommendations.rst:49 -msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" +msgid "" +"Use :ref:`setuptools` to define projects and create :term:`Source " +"Distributions `. [5]_ [6]_" msgstr "" #: ../source/guides/tool-recommendations.rst:52 -msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." +msgid "" +"Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:" +"`wheel project ` to create :term:`wheels `. This is " +"especially beneficial, if your project contains binary extensions." msgstr "" #: ../source/guides/tool-recommendations.rst:56 -msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." +msgid "" +"Use `twine `_ for uploading distributions " +"to :term:`PyPI `." msgstr "" #: ../source/guides/tool-recommendations.rst:61 @@ -4190,39 +6142,75 @@ msgid "Publishing platform migration" msgstr "" #: ../source/guides/tool-recommendations.rst:63 -msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." +msgid "" +"The original Python Package Index implementation (previously hosted at `pypi." +"python.org `_) has been phased out in favour of an " +"updated implementation hosted at `pypi.org `_." msgstr "" #: ../source/guides/tool-recommendations.rst:67 -msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." +msgid "" +"See :ref:`Migrating to PyPI.org` for more information on the status of the " +"migration, and what settings to change in your clients." msgstr "" #: ../source/guides/tool-recommendations.rst:72 -msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." +msgid "" +"There are some cases where you might choose to use ``easy_install`` (from :" +"ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` " +"(which pip doesn't support). For a detailed breakdown, see :ref:`pip vs " +"easy_install`." msgstr "" #: ../source/guides/tool-recommendations.rst:77 -msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." +msgid "" +"The acceptance of :pep:`453` means that :ref:`pip` will be available by " +"default in most installations of Python 3.4 or later. See the :pep:" +"`rationale section <453#rationale>` from :pep:`453` as for why pip was " +"chosen." msgstr "" #: ../source/guides/tool-recommendations.rst:82 -msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." +msgid "" +"`get-pip.py `_ and :ref:" +"`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv " +"` do not currently. Also, the common \"python-pip\" package that's " +"found in various linux distros, does not depend on \"python-wheel\" " +"currently." msgstr "" #: ../source/guides/tool-recommendations.rst:88 -msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." +msgid "" +"Beginning with Python 3.4, ``venv`` will create virtualenv environments with " +"``pip`` installed, thereby making it an equal alternative to :ref:" +"`virtualenv`. However, using :ref:`virtualenv` will still be recommended for " +"users that need cross-version consistency." msgstr "" #: ../source/guides/tool-recommendations.rst:93 -msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." +msgid "" +"Although you can use pure ``distutils`` for many projects, it does not " +"support defining dependencies on other projects and is missing several " +"convenience utilities for automatically populating distribution metadata " +"correctly that are provided by ``setuptools``. Being outside the standard " +"library, ``setuptools`` also offers a more consistent feature set across " +"different versions of Python, and (unlike ``distutils``), recent versions of " +"``setuptools`` support all of the modern metadata fields described in :ref:" +"`core-metadata`." msgstr "" #: ../source/guides/tool-recommendations.rst:102 -msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." +msgid "" +"Even for projects that do choose to use ``distutils``, when :ref:`pip` " +"installs such projects directly from source (rather than installing from a " +"prebuilt :term:`wheel ` file), it will actually build your project " +"using :ref:`setuptools` instead." msgstr "" #: ../source/guides/tool-recommendations.rst:107 -msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." +msgid "" +"`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` " +"in June 2013, thereby making setuptools the default choice for packaging." msgstr "" #: ../source/guides/using-manifest-in.rst:5 @@ -4230,11 +6218,23 @@ msgid "Including files in source distributions with ``MANIFEST.in``" msgstr "" #: ../source/guides/using-manifest-in.rst:7 -msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." +msgid "" +"When building a :term:`source distribution ` for your package, by default only a minimal set of files are " +"included. You may find yourself wanting to include extra files in the " +"source distribution, such as an authors/contributors file, a :file:`docs/` " +"directory, or a directory of data files used for testing purposes. There " +"may even be extra files that you *need* to include; for example, if your :" +"file:`setup.py` computes your project's ``long_description`` by reading from " +"both a README and a changelog file, you'll need to include both those files " +"in the sdist so that people that build or install from the sdist get the " +"correct results." msgstr "" #: ../source/guides/using-manifest-in.rst:17 -msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." +msgid "" +"Adding & removing files to & from the source distribution is done by writing " +"a :file:`MANIFEST.in` file at the project root." msgstr "" #: ../source/guides/using-manifest-in.rst:22 @@ -4246,11 +6246,15 @@ msgid "The following files are included in a source distribution by default:" msgstr "" #: ../source/guides/using-manifest-in.rst:26 -msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" +msgid "" +"all Python source files implied by the ``py_modules`` and ``packages`` " +"``setup()`` arguments" msgstr "" #: ../source/guides/using-manifest-in.rst:28 -msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" +msgid "" +"all C source files mentioned in the ``ext_modules`` or ``libraries`` " +"``setup()`` arguments" msgstr "" #: ../source/guides/using-manifest-in.rst:30 @@ -4258,15 +6262,21 @@ msgid "scripts specified by the ``scripts`` ``setup()`` argument" msgstr "" #: ../source/guides/using-manifest-in.rst:31 -msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" +msgid "" +"all files specified by the ``package_data`` and ``data_files`` ``setup()`` " +"arguments" msgstr "" #: ../source/guides/using-manifest-in.rst:33 -msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" +msgid "" +"the file specified by the ``license_file`` option in :file:`setup.cfg` " +"(setuptools 40.8.0+)" msgstr "" #: ../source/guides/using-manifest-in.rst:35 -msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" +msgid "" +"all files specified by the ``license_files`` option in :file:`setup.cfg` " +"(setuptools 42.0.0+)" msgstr "" #: ../source/guides/using-manifest-in.rst:37 @@ -4306,11 +6316,20 @@ msgid ":file:`MANIFEST.in`" msgstr "" #: ../source/guides/using-manifest-in.rst:47 -msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." +msgid "" +"After adding the above files to the sdist, the commands in :file:`MANIFEST." +"in` (if such a file exists) are executed in order to add and remove further " +"files to & from the sdist. Default files can even be removed from the sdist " +"with the appropriate :file:`MANIFEST.in` command." msgstr "" #: ../source/guides/using-manifest-in.rst:52 -msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." +msgid "" +"After processing the :file:`MANIFEST.in` file, setuptools removes the :file:" +"`build/` directory as well as any directories named :file:`RCS`, :file:" +"`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file " +"and an :file:`*.egg-info` directory. This behavior cannot be changed with :" +"file:`MANIFEST.in`." msgstr "" #: ../source/guides/using-manifest-in.rst:60 @@ -4318,7 +6337,10 @@ msgid ":file:`MANIFEST.in` commands" msgstr "" #: ../source/guides/using-manifest-in.rst:62 -msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" +msgid "" +"A :file:`MANIFEST.in` file consists of commands, one per line, instructing " +"setuptools to add or remove some set of files from the sdist. The commands " +"are:" msgstr "" #: ../source/guides/using-manifest-in.rst:67 @@ -4346,7 +6368,9 @@ msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" msgstr "" #: ../source/guides/using-manifest-in.rst:71 -msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgid "" +"Add all files under directories matching ``dir-pattern`` that match any of " +"the listed patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:72 @@ -4354,7 +6378,9 @@ msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" msgstr "" #: ../source/guides/using-manifest-in.rst:72 -msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgid "" +"Remove all files under directories matching ``dir-pattern`` that match any " +"of the listed patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:73 @@ -4362,7 +6388,8 @@ msgid ":samp:`global-include {pat1} {pat2} ...`" msgstr "" #: ../source/guides/using-manifest-in.rst:73 -msgid "Add all files anywhere in the source tree matching any of the listed patterns" +msgid "" +"Add all files anywhere in the source tree matching any of the listed patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:74 @@ -4370,7 +6397,9 @@ msgid ":samp:`global-exclude {pat1} {pat2} ...`" msgstr "" #: ../source/guides/using-manifest-in.rst:74 -msgid "Remove all files anywhere in the source tree matching any of the listed patterns" +msgid "" +"Remove all files anywhere in the source tree matching any of the listed " +"patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:75 @@ -4390,27 +6419,54 @@ msgid "Remove all files under directories matching ``dir-pattern``" msgstr "" #: ../source/guides/using-manifest-in.rst:79 -msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." +msgid "" +"The patterns here are glob-style patterns: ``*`` matches zero or more " +"regular filename characters (on Unix, everything except forward slash; on " +"Windows, everything except backslash and colon); ``?`` matches a single " +"regular filename character, and ``[chars]`` matches any one of the " +"characters between the square brackets (which may contain character ranges, " +"e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented " +"support for ``**`` matching zero or more characters including forward slash, " +"backslash, and colon." msgstr "" #: ../source/guides/using-manifest-in.rst:87 -msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." +msgid "" +"Directory patterns are relative to the root of the project directory; e.g., " +"``graft example*`` will include a directory named :file:`examples` in the " +"project root but will not include :file:`docs/examples/`." msgstr "" #: ../source/guides/using-manifest-in.rst:91 -msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." +msgid "" +"File & directory names in :file:`MANIFEST.in` should be ``/``-separated; " +"setuptools will automatically convert the slashes to the local platform's " +"appropriate directory separator." msgstr "" #: ../source/guides/using-manifest-in.rst:95 -msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" +msgid "" +"Commands are processed in the order they appear in the :file:`MANIFEST.in` " +"file. For example, given the commands::" msgstr "" #: ../source/guides/using-manifest-in.rst:101 -msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." +msgid "" +"the contents of the directory tree :file:`tests` will first be added to the " +"sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, " +"or ``.pyd`` extension will be removed from the sdist. If the commands were " +"in the opposite order, then ``*.pyc`` files etc. would be only be removed " +"from what was already in the sdist before adding :file:`tests`, and if :file:" +"`tests` happened to contain any ``*.pyc`` files, they would end up included " +"in the sdist because the exclusion happened before they were included." msgstr "" #: ../source/guides/using-testpypi.rst:7 -msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" +msgid "" +"``TestPyPI`` is a separate instance of the :term:`Python Package Index " +"(PyPI)` that allows you to try out the distribution tools and process " +"without worrying about affecting the real index. TestPyPI is hosted at `test." +"pypi.org `_" msgstr "" #: ../source/guides/using-testpypi.rst:13 @@ -4418,11 +6474,16 @@ msgid "Registering your account" msgstr "" #: ../source/guides/using-testpypi.rst:15 -msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." +msgid "" +"Because TestPyPI has a separate database from the live PyPI, you'll need a " +"separate user account for specifically for TestPyPI. Go to https://test.pypi." +"org/account/register/ to register your account." msgstr "" #: ../source/guides/using-testpypi.rst:19 -msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." +msgid "" +"The database for TestPyPI may be periodically pruned, so it is not unusual " +"for user accounts to be deleted." msgstr "" #: ../source/guides/using-testpypi.rst:24 @@ -4430,11 +6491,17 @@ msgid "Using TestPyPI with Twine" msgstr "" #: ../source/guides/using-testpypi.rst:26 -msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" +msgid "" +"You can upload your distributions to TestPyPI using :ref:`twine` by " +"specifying the ``--repository`` flag" msgstr "" #: ../source/guides/using-testpypi.rst:33 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgid "" +"You can see if your package has successfully uploaded by navigating to the " +"URL ``https://test.pypi.org/project/`` where " +"``sampleproject`` is the name of your project that you uploaded. It may take " +"a minute or two for your project to appear on the site." msgstr "" #: ../source/guides/using-testpypi.rst:39 @@ -4442,11 +6509,16 @@ msgid "Using TestPyPI with pip" msgstr "" #: ../source/guides/using-testpypi.rst:41 -msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" +msgid "" +"You can tell pip to download packages from TestPyPI instead of PyPI by " +"specifying the ``--index-url`` flag" msgstr "" #: ../source/guides/using-testpypi.rst:56 -msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" +msgid "" +"If you want to allow pip to also pull other packages from PyPI you can " +"specify ``--extra-index-url`` to point to PyPI. This is useful when the " +"package you're testing has dependencies:" msgstr "" #: ../source/guides/using-testpypi.rst:73 @@ -4454,16 +6526,19 @@ msgid "Setting up TestPyPI in :file:`.pypirc`" msgstr "" #: ../source/guides/using-testpypi.rst:75 -msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" +msgid "" +"If you want to avoid entering your username, you can configure TestPyPI in " +"your :file:`$HOME/.pypirc`:" msgstr "" -#: ../source/index.rst:3 -#: ../source/key_projects.rst:181 +#: ../source/index.rst:3 ../source/key_projects.rst:181 msgid "Python Packaging User Guide" msgstr "Manlibro por Python-Uzantoj pri Pakado" #: ../source/index.rst:5 -msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." +msgid "" +"The Python Packaging User Guide (PyPUG) is a collection of tutorials and " +"guides for packaging Python software." msgstr "" #: ../source/index.rst:5 @@ -4471,11 +6546,16 @@ msgid "python, packaging, guide, tutorial" msgstr "" #: ../source/index.rst:24 -msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." +msgid "" +"Welcome to the *Python Packaging User Guide*, a collection of tutorials and " +"references to help you distribute and install Python packages with modern " +"tools." msgstr "" #: ../source/index.rst:28 -msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" +msgid "" +"This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. " +"We happily accept any :doc:`contributions and feedback `. 😊" msgstr "" #: ../source/index.rst:36 @@ -4483,23 +6563,34 @@ msgid "Get started" msgstr "Komenci" #: ../source/index.rst:38 -msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" +msgid "" +"Essential tools and concepts for working within the Python development " +"ecosystem are covered in our :doc:`tutorials/index` section:" msgstr "" #: ../source/index.rst:41 -msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" +msgid "" +"To learn how to install packages, see the :doc:`tutorial on installing " +"packages `" msgstr "" #: ../source/index.rst:43 -msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" +msgid "" +"To learn how to manage dependencies in a version controlled project, see " +"the :doc:`tutorial on managing application dependencies `" msgstr "" #: ../source/index.rst:45 -msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" +msgid "" +"To learn how to package and distribute your projects, see the :doc:`tutorial " +"on packaging and distributing `" msgstr "" #: ../source/index.rst:47 -msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" +msgid "" +"To get an overview of packaging options for Python libraries and " +"applications, see the :doc:`Overview of Python Packaging `" msgstr "" #: ../source/index.rst:52 @@ -4507,23 +6598,33 @@ msgid "Learn more" msgstr "Lerni pli" #: ../source/index.rst:54 -msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" +msgid "" +"Beyond our :doc:`tutorials/index`, this guide has several other resources:" msgstr "" #: ../source/index.rst:56 -msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." +msgid "" +"The :doc:`guides/index` section for walk throughs, such as :doc:`guides/" +"installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." msgstr "" #: ../source/index.rst:58 -msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." +msgid "" +"The :doc:`discussions/index` section for in-depth references on topics such " +"as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-" +"vs-easy-install`." msgstr "" #: ../source/index.rst:60 -msgid "The :doc:`specifications/index` section for packaging interoperability specifications." +msgid "" +"The :doc:`specifications/index` section for packaging interoperability " +"specifications." msgstr "" #: ../source/index.rst:62 -msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." +msgid "" +"Additionally, there is a list of :doc:`other projects ` " +"maintained by members of the Python Packaging Authority." msgstr "" #: ../source/key_projects.rst:6 @@ -4531,7 +6632,9 @@ msgid "Project Summaries" msgstr "" #: ../source/key_projects.rst:8 -msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." +msgid "" +"Summaries and links for the most relevant projects in the space of Python " +"installation and packaging." msgstr "" #: ../source/key_projects.rst:14 @@ -4543,14 +6646,21 @@ msgid "bandersnatch" msgstr "bandersnatch" #: ../source/key_projects.rst:21 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" -"`Cimoj `__ | `GitHub " -"`__ | `PyPI `__ | `GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:25 -msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." +msgid "" +"``bandersnatch`` is a PyPI mirroring client designed to efficiently create a " +"complete mirror of the contents of PyPI. Organizations thus save bandwidth " +"and latency on package downloads (especially in the context of automated " +"tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." msgstr "" #: ../source/key_projects.rst:35 @@ -4558,14 +6668,19 @@ msgid "build" msgstr "build" #: ../source/key_projects.rst:37 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI " +"`__" msgstr "" -"`Dokumentaro `__ | `Cimoj `__ | `GitHub `__ | `" -"PyPI `__" +"`Dokumentaro `__ | `Cimoj `__ | `GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:42 -msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." +msgid "" +"``build`` is a :pep:`517` compatible Python package builder. It provides a " +"CLI to build packages, as well as a Python API." msgstr "" #: ../source/key_projects.rst:49 @@ -4573,16 +6688,24 @@ msgid "cibuildwheel" msgstr "cibuildwheel" #: ../source/key_projects.rst:51 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" -msgstr "" -"`Dokumentaro `__ | `Cimoj " -"`__ | `GitHub `__ | `PyPI `__ " -"| `Diskutoj `__ | `Discord " +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | " +"`Discussions `__ | " +"`Discord #cibuildwheel `__" +msgstr "" +"`Dokumentaro `__ | `Cimoj `__ | `GitHub `__ | `PyPI `__ | " +"`Diskutoj `__ | `Discord " "#cibuildwheel `__" #: ../source/key_projects.rst:58 -msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." +msgid "" +"``cibuildwheel`` is a Python package that builds :term:`wheels ` for " +"all common platforms and Python versions on most CI systems. Also see :ref:" +"`multibuild`." msgstr "" #: ../source/key_projects.rst:64 @@ -4590,19 +6713,35 @@ msgid "distlib" msgstr "distlib" #: ../source/key_projects.rst:66 -msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" msgstr "" -"`Dokumentaro `__ | `Cimoj " -"`__ | `" -"Bitbucket `__ | `PyPI `__" +"`Dokumentaro `__ | `Cimoj `__ | `Bitbucket " +"`__ | `PyPI `__" #: ../source/key_projects.rst:71 -msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." +msgid "" +"``distlib`` is a library which implements low-level functions that relate to " +"packaging and distribution of Python software. ``distlib`` implements " +"several relevant PEPs (Python Enhancement Proposal standards) and is useful " +"for developers of third-party packaging tools to make and upload binary and " +"source :term:`distributions `, achieve " +"interoperability, resolve dependencies, manage package resources, and do " +"other similar functions." msgstr "" #: ../source/key_projects.rst:80 -msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." +msgid "" +"Unlike the stricter :ref:`packaging` project (below), which specifically " +"implements modern Python packaging interoperability standards, ``distlib`` " +"also attempts to provide reasonable fallback behaviours when asked to handle " +"legacy packages and metadata that predate the modern interoperability " +"standards and fall into the subset of packages that are incompatible with " +"those standards." msgstr "" #: ../source/key_projects.rst:90 @@ -4610,19 +6749,36 @@ msgid "packaging" msgstr "packaging" #: ../source/key_projects.rst:92 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:97 -msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." +msgid "" +"Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." msgstr "" #: ../source/key_projects.rst:99 -msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." +msgid "" +"The core utilities in the packaging library handle version handling, " +"specifiers, markers, requirements, tags, and similar attributes and tasks " +"for Python packages. Most Python users rely on this library without needing " +"to explicitly call it; developers of the other Python packaging, " +"distribution, and installation tools listed here often use its functionality " +"to parse, discover, and otherwise handle dependency attributes." msgstr "" #: ../source/key_projects.rst:107 -msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." +msgid "" +"This project specifically focuses on implementing the modern Python " +"packaging interoperability standards defined at :ref:`packaging-" +"specifications`, and will report errors for sufficiently old legacy packages " +"that are incompatible with those standards. In contrast, the :ref:`distlib` " +"project is a more permissive library that attempts to provide a plausible " +"reading of ambiguous metadata in cases where :ref:`packaging` will instead " +"report on error." msgstr "" #: ../source/key_projects.rst:119 @@ -4631,18 +6787,27 @@ msgid "pip" msgstr "pip" #: ../source/key_projects.rst:121 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" "`Dokumentaro `__ | `Cimoj `__ | `GitHub `__ | `PyPI " "`__" #: ../source/key_projects.rst:126 -msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." +msgid "" +"The most popular tool for installing Python packages, and the one included " +"with modern versions of Python." msgstr "" #: ../source/key_projects.rst:129 -msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." +msgid "" +"It provides the essential core features for finding, downloading, and " +"installing packages from PyPI and other Python package indexes, and can be " +"incorporated into a wide range of development workflows via its command-line " +"interface (CLI)." msgstr "" #: ../source/key_projects.rst:137 @@ -4650,18 +6815,31 @@ msgid "Pipenv" msgstr "Pipenv" #: ../source/key_projects.rst:139 -msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Source `__ | `Issues `__ | `PyPI " +"`__" msgstr "" "`Dokumentaro `__ | `Fonto `__ | `Cimoj `__ | `PyPI " "`__" #: ../source/key_projects.rst:144 -msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." +msgid "" +"Pipenv is a project that aims to bring the best of all packaging worlds to " +"the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:" +"`virtualenv` into one single toolchain. It features very pretty terminal " +"colors." msgstr "" #: ../source/key_projects.rst:148 -msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." +msgid "" +"Pipenv aims to help users manage environments, dependencies, and imported " +"packages on the command line. It also works well on Windows (which other " +"tools often underserve), makes and checkes file hashes, to ensure compliance " +"with hash-locked dependency specifiers, and eases uninstallation of packages " +"and dependencies. It is used by Python users and system administrators, but " +"has been less maintained since late 2018." msgstr "" #: ../source/key_projects.rst:159 @@ -4673,7 +6851,10 @@ msgid "`Source `__" msgstr "`Fonto `__" #: ../source/key_projects.rst:163 -msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." +msgid "" +":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level " +"application-centric alternative to :ref:`pip`'s lower-level :file:" +"`requirements.txt` file." msgstr "" #: ../source/key_projects.rst:170 @@ -4681,15 +6862,22 @@ msgid "pipx" msgstr "pipx" #: ../source/key_projects.rst:172 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:176 -msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." +msgid "" +"pipx is a tool to install and run Python command-line applications without " +"causing dependency conflicts with other packages installed on the system." msgstr "" #: ../source/key_projects.rst:183 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:187 @@ -4701,11 +6889,18 @@ msgid "readme_renderer" msgstr "readme_renderer" #: ../source/key_projects.rst:194 -msgid "`GitHub and docs `__ | `PyPI `__" +msgid "" +"`GitHub and docs `__ | `PyPI " +"`__" msgstr "" #: ../source/key_projects.rst:197 -msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." +msgid "" +"``readme_renderer`` is a library that package developers use to render their " +"user documentation (README) files into HTML from markup languages such as " +"Markdown or reStructuredText. Developers call it on its own or via :ref:" +"`twine`, as part of their release management process, to check that their " +"package descriptions will properly display on PyPI." msgstr "" #: ../source/key_projects.rst:208 @@ -4713,18 +6908,27 @@ msgid "setuptools" msgstr "setuptools" #: ../source/key_projects.rst:210 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" "`Dokumentaro `__ | `Cimoj " "`__ | `GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:215 -msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." +msgid "" +"setuptools (which includes ``easy_install``) is a collection of enhancements " +"to the Python distutils that allow you to more easily build and distribute " +"Python :term:`distributions `, especially ones that " +"have dependencies on other packages." msgstr "" #: ../source/key_projects.rst:220 -msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." +msgid "" +"`distribute`_ was a fork of setuptools that was merged back into setuptools " +"(in v0.7), thereby making setuptools the primary choice for Python packaging." msgstr "" #: ../source/key_projects.rst:227 @@ -4732,15 +6936,32 @@ msgid "trove-classifiers" msgstr "" #: ../source/key_projects.rst:229 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Issues `__ | `GitHub " +"`__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:233 -msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." +msgid "" +"trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically " +"describe their projects `_ so that users can better find projects " +"that match their needs on the PyPI." msgstr "" #: ../source/key_projects.rst:239 -msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." +msgid "" +"The trove-classifiers package contains a list of valid classifiers and " +"deprecated classifiers (which are paired with the classifiers that replace " +"them). Use this package to validate classifiers used in packages intended " +"for uploading to PyPI. As this list of classifiers is published as code, you " +"can install and import it, giving you a more convenient workflow compared to " +"referring to the `list published on PyPI `_. " +"The `issue tracker `_ for " +"the project hosts discussions on proposed classifiers and requests for new " +"classifiers." msgstr "" #: ../source/key_projects.rst:253 @@ -4748,24 +6969,41 @@ msgid "twine" msgstr "" #: ../source/key_projects.rst:255 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:260 -msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." +msgid "" +"Twine is the primary tool developers use to upload packages to the Python " +"Package Index or other Python package indexes. It is a command-line program " +"that passes program files and metadata to a web API. Developers use it " +"because it's the official PyPI upload tool, it's fast and secure, it's " +"maintained, and it reliably works." msgstr "" -#: ../source/key_projects.rst:270 -#: ../source/overview.rst:415 +#: ../source/key_projects.rst:270 ../source/overview.rst:415 msgid "virtualenv" msgstr "" #: ../source/key_projects.rst:272 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:277 -msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgid "" +"virtualenv is a tool which uses the command-line path environment variable " +"to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional " +"functionality, compared to :ref:`venv`, by supporting Python 2.7 and by " +"providing convenient features for configuring, maintaining, duplicating, and " +"troubleshooting the virtual environments. For more information, see the " +"section on :ref:`Creating and using Virtual Environments`." msgstr "" #: ../source/key_projects.rst:290 @@ -4773,11 +7011,16 @@ msgid "Warehouse" msgstr "" #: ../source/key_projects.rst:292 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:296 -msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." +msgid "" +"The current codebase powering the :term:`Python Package Index (PyPI)`. It is " +"hosted at `pypi.org `_. The default source for :ref:`pip` " +"downloads." msgstr "" #: ../source/key_projects.rst:304 @@ -4785,15 +7028,26 @@ msgid "wheel" msgstr "" #: ../source/key_projects.rst:306 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:311 -msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." +msgid "" +"Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` " +"extension for creating :term:`wheel distributions `. Additionally, " +"it offers its own command line utility for creating and installing wheels." msgstr "" #: ../source/key_projects.rst:315 -msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." +msgid "" +"See also `auditwheel `__, a tool that " +"package developers use to check and fix Python packages they are making in " +"the binary wheel format. It provides functionality to discover dependencies, " +"check metadata for compliance, and repair the wheel and metadata to properly " +"link and include external shared libraries in a package." msgstr "" #: ../source/key_projects.rst:324 @@ -4805,11 +7059,17 @@ msgid "bento" msgstr "" #: ../source/key_projects.rst:331 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:336 -msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." +msgid "" +"Bento is a packaging tool solution for Python software, targeted as an " +"alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's " +"philosophy is reproducibility, extensibility and simplicity (in that order)." msgstr "" #: ../source/key_projects.rst:344 @@ -4817,11 +7077,18 @@ msgid "buildout" msgstr "" #: ../source/key_projects.rst:346 -msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" +msgid "" +"`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:351 -msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." +msgid "" +"Buildout is a Python-based build system for creating, assembling and " +"deploying applications from multiple parts, some of which may be non-Python-" +"based. It lets you create a buildout configuration and reproduce the same " +"software later." msgstr "" #: ../source/key_projects.rst:358 @@ -4833,15 +7100,32 @@ msgid "`Docs `__" msgstr "" #: ../source/key_projects.rst:362 -msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." +msgid "" +"conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution " +"from `Anaconda, Inc `__ specifically " +"aimed at the scientific community, and in particular on Windows where the " +"installation of binary extensions is often difficult." msgstr "" #: ../source/key_projects.rst:369 -msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." +msgid "" +"Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, " +"but provides many of their combined features in terms of package management, " +"virtual environment management and deployment of binary extensions." msgstr "" #: ../source/key_projects.rst:373 -msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." +msgid "" +"Conda does not install packages from PyPI and can install only from the " +"official Anaconda repositories, or anaconda.org (a place for user-" +"contributed *conda* packages), or a local (e.g. intranet) package server. " +"However, note that :ref:`pip` can be installed into, and work side-by-side " +"with conda for managing :term:`distributions ` from " +"PyPI. Also, `conda skeleton `__ is a tool to make " +"Python packages installable by conda by first fetching them from PyPI and " +"modifying their metadata." msgstr "" #: ../source/key_projects.rst:386 @@ -4849,11 +7133,17 @@ msgid "devpi" msgstr "" #: ../source/key_projects.rst:388 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:392 -msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." +msgid "" +"devpi features a powerful PyPI-compatible server and PyPI proxy cache with a " +"complementary command line tool to drive packaging, testing and release " +"activities with Python. devpi also provides a browsable and searchable web " +"interface." msgstr "" #: ../source/key_projects.rst:401 @@ -4861,15 +7151,25 @@ msgid "flit" msgstr "" #: ../source/key_projects.rst:403 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:407 -msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." +msgid "" +"Flit provides a simple way to upload pure Python packages and modules to " +"PyPI. It focuses on `making the easy things easy `_ for " +"packaging. Flit can generate a configuration file to quickly set up a simple " +"project, build source distributions and wheels, and upload them to PyPI." msgstr "" #: ../source/key_projects.rst:412 -msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." +msgid "" +"Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on " +"tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to " +"upload them to PyPI. Flit requires Python 3, but you can use it to " +"distribute modules for Python 2, so long as they can be imported on Python 3." msgstr "" #: ../source/key_projects.rst:422 @@ -4877,11 +7177,22 @@ msgid "enscons" msgstr "" #: ../source/key_projects.rst:424 -msgid "`Source `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Source `__ | `Issues `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:428 -msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." +msgid "" +"Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-" +"compatible source distributions and wheels without using distutils or " +"setuptools, including distributions with C extensions. Enscons has a " +"different architecture and philosophy than :ref:`distutils`. Rather than " +"adding build features to a Python packaging system, enscons adds Python " +"packaging to a general purpose build system. Enscons helps you to build " +"sdists that can be automatically built by :ref:`pip`, and wheels that are " +"independent of enscons." msgstr "" #: ../source/key_projects.rst:443 @@ -4889,11 +7200,20 @@ msgid "Hashdist" msgstr "" #: ../source/key_projects.rst:445 -msgid "`Docs `__ | `GitHub `__" +msgid "" +"`Docs `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:448 -msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." +msgid "" +"Hashdist is a library for building non-root software distributions. Hashdist " +"is trying to be “the Debian of choice for cases where Debian technology " +"doesn’t work”. The best way for Pythonistas to think about Hashdist may be a " +"more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed " +"at solving the problem of installing scientific software, and making package " +"distribution stateless, cached, and branchable. It is used by some " +"researchers but has been lacking in maintenance since 2016." msgstr "" #: ../source/key_projects.rst:460 @@ -4901,11 +7221,18 @@ msgid "hatch" msgstr "" #: ../source/key_projects.rst:462 -msgid "`GitHub and Docs `__ | `PyPI `__" +msgid "" +"`GitHub and Docs `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:465 -msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." +msgid "" +"Hatch is a unified command-line tool meant to conveniently manage " +"dependencies and environment isolation for Python developers. Python package " +"developers use Hatch to configure, version, specify dependencies for, and " +"publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload " +"packages to PyPI, and :ref:`pip` to download and install packages." msgstr "" #: ../source/key_projects.rst:475 @@ -4917,7 +7244,10 @@ msgid "`GitHub `__" msgstr "" #: ../source/key_projects.rst:479 -msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." +msgid "" +"Multibuild is a set of CI scripts for building and testing Python :term:" +"`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :" +"ref:`cibuildwheel`." msgstr "" #: ../source/key_projects.rst:485 @@ -4925,11 +7255,18 @@ msgid "pex" msgstr "" #: ../source/key_projects.rst:487 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:491 -msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." +msgid "" +"pex is both a library and tool for generating :file:`.pex` (Python " +"EXecutable) files, standalone Python environments in the spirit of :ref:" +"`virtualenv`. :file:`.pex` files are just carefully constructed zip files " +"with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are " +"designed to make deployment of Python applications as simple as ``cp``." msgstr "" #: ../source/key_projects.rst:500 @@ -4937,11 +7274,20 @@ msgid "pip-tools" msgstr "" #: ../source/key_projects.rst:502 -msgid "`GitHub and Docs `__ | `PyPI `__" +msgid "" +"`GitHub and Docs `__ | `PyPI " +"`__" msgstr "" #: ../source/key_projects.rst:505 -msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." +msgid "" +"pip-tools is a suite of tools meant for Python system administrators and " +"release managers who particularly want to keep their builds deterministic " +"yet stay up to date with new versions of their dependencies. Users can " +"specify particular release of their dependencies via hash, conveniently make " +"a properly formatted list of requirements from information in other parts of " +"their program, update all dependencies (a feature :ref:`pip` currently does " +"not provide), and create layers of constraints for the program to obey." msgstr "" #: ../source/key_projects.rst:517 @@ -4949,11 +7295,17 @@ msgid "piwheels" msgstr "" #: ../source/key_projects.rst:519 -msgid "`Website `__ | `Docs `__ | `GitHub `__" +msgid "" +"`Website `__ | `Docs `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:523 -msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." +msgid "" +"piwheels is a website, and software underpinning it, that fetches source " +"code distribution packages from PyPI and compiles them into binary wheels " +"that are optimized for installation onto Raspberry Pi computers. Raspberry " +"Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." msgstr "" #: ../source/key_projects.rst:532 @@ -4961,11 +7313,19 @@ msgid "poetry" msgstr "" #: ../source/key_projects.rst:534 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:538 -msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." +msgid "" +"poetry is a command-line tool to handle dependency installation and " +"isolation as well as building and packaging of Python packages. It uses " +"``pyproject.toml`` and, instead of depending on the resolver functionality " +"within :ref:`pip`, provides its own dependency resolver. It attempts to " +"speed users' experience of installation and dependency resolution by locally " +"caching metadata about dependencies." msgstr "" #: ../source/key_projects.rst:548 @@ -4973,11 +7333,20 @@ msgid "pypiserver" msgstr "" #: ../source/key_projects.rst:550 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | " +"`GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:554 -msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." +msgid "" +"pypiserver is a minimalist application that serves as a private Python " +"package index within organizations, implementing a simple API and browser " +"interface. You can upload private packages using standard upload tools, and " +"users can download and install them with :ref:`pip`, without publishing them " +"publicly. Organizations who use pypiserver usually download packages both " +"from pypiserver and from PyPI." msgstr "" #: ../source/key_projects.rst:564 @@ -4985,11 +7354,22 @@ msgid "scikit-build" msgstr "" #: ../source/key_projects.rst:566 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:570 -msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." +msgid "" +"Scikit-build is an improved build system generator for CPython C/C++/Fortran/" +"Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :" +"ref:`pip`. It internally uses `cmake `__ " +"(available on PyPI) to provide better support for additional compilers, " +"build systems, cross compilation, and locating dependencies and their " +"associated build requirements. To speed up and parallelize the build of " +"large projects, the user can install `ninja `__ (also available on PyPI)." msgstr "" #: ../source/key_projects.rst:582 @@ -4997,23 +7377,42 @@ msgid "shiv" msgstr "" #: ../source/key_projects.rst:584 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:588 -msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." +msgid "" +"shiv is a command line utility for building fully self contained Python " +"zipapps as outlined in :pep:`441`, but with all their dependencies included. " +"Its primary goal is making distributing Python applications and command line " +"tools fast & easy." msgstr "" #: ../source/key_projects.rst:598 -msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" +msgid "" +"`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" msgstr "" #: ../source/key_projects.rst:603 -msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." +msgid "" +"A flexible package manager designed to support multiple versions, " +"configurations, platforms, and compilers. Spack is like Homebrew, but " +"packages are written in Python and parameterized to allow easy swapping of " +"compilers, library versions, build options, etc. Arbitrarily many versions " +"of packages can coexist on the same system. Spack was designed for rapidly " +"building high performance scientific applications on clusters and " +"supercomputers." msgstr "" #: ../source/key_projects.rst:611 -msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." +msgid "" +"Spack is not in PyPI (yet), but it requires no installation and can be used " +"immediately after cloning from GitHub." msgstr "" #: ../source/key_projects.rst:617 @@ -5021,11 +7420,18 @@ msgid "zest.releaser" msgstr "" #: ../source/key_projects.rst:619 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:623 -msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." +msgid "" +"``zest.releaser`` is a Python package release tool providing an abstraction " +"layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to " +"automate incrementing package version numbers, updating changelogs, tagging " +"releases in source control, and uploading new packages to PyPI." msgstr "" #: ../source/key_projects.rst:630 @@ -5037,11 +7443,17 @@ msgid "ensurepip" msgstr "" #: ../source/key_projects.rst:637 -msgid "`Docs `__ | `Issues `__" +msgid "" +"`Docs `__ | `Issues " +"`__" msgstr "" #: ../source/key_projects.rst:640 -msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." +msgid "" +"A package in the Python Standard Library that provides support for " +"bootstrapping :ref:`pip` into an existing Python installation or virtual " +"environment. In most cases, end users won't use this module, but rather it " +"will be used during the build of the Python distribution." msgstr "" #: ../source/key_projects.rst:649 @@ -5049,15 +7461,26 @@ msgid "distutils" msgstr "" #: ../source/key_projects.rst:651 -msgid "`Docs `__ | `Issues `__" +msgid "" +"`Docs `__ | `Issues " +"`__" msgstr "" #: ../source/key_projects.rst:654 -msgid "The original Python packaging system, added to the standard library in Python 2.0." +msgid "" +"The original Python packaging system, added to the standard library in " +"Python 2.0." msgstr "" #: ../source/key_projects.rst:657 -msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." +msgid "" +"Due to the challenges of maintaining a packaging system where feature " +"updates are tightly coupled to language runtime updates, direct usage of :" +"ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being " +"the preferred replacement. :ref:`Setuptools` not only provides features that " +"plain :ref:`distutils` doesn't offer (such as dependency declarations and " +"entry point declarations), it also provides a consistent build interface and " +"feature set across all supported Python versions." msgstr "" #: ../source/key_projects.rst:670 @@ -5065,11 +7488,17 @@ msgid "venv" msgstr "" #: ../source/key_projects.rst:672 -msgid "`Docs `__ | `Issues `__" +msgid "" +"`Docs `__ | `Issues `__" msgstr "" #: ../source/key_projects.rst:675 -msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgid "" +"A package in the Python Standard Library (starting with Python 3.3) for " +"creating :term:`Virtual Environments `. For more " +"information, see the section on :ref:`Creating and using Virtual " +"Environments`." msgstr "" #: ../source/news.rst:2 @@ -5141,7 +7570,8 @@ msgid "April 2019" msgstr "" #: ../source/news.rst:31 -msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" +msgid "" +"Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" msgstr "" #: ../source/news.rst:32 @@ -5165,7 +7595,9 @@ msgid "February 2019" msgstr "" #: ../source/news.rst:41 -msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" +msgid "" +"Elaborate upon the differences between the tutorial and the real packaging " +"process. (:pr:`602`)" msgstr "" #: ../source/news.rst:42 @@ -5249,7 +7681,8 @@ msgid "Replaced tar command with working command. (:pr:`552`)" msgstr "" #: ../source/news.rst:72 -msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" +msgid "" +"Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" msgstr "" #: ../source/news.rst:75 @@ -5261,7 +7694,8 @@ msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" msgstr "" #: ../source/news.rst:77 -msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" +msgid "" +"Moved the Overview to a task based lead in along with the others. (:pr:`540`)" msgstr "" #: ../source/news.rst:78 @@ -5305,7 +7739,8 @@ msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" msgstr "" #: ../source/news.rst:97 -msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" +msgid "" +"Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" msgstr "" #: ../source/news.rst:98 @@ -5369,7 +7804,8 @@ msgid "Updated \"installing scientific packages\". (:pr:`455`)" msgstr "" #: ../source/news.rst:119 -msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" +msgid "" +"Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" msgstr "" #: ../source/news.rst:120 @@ -5385,7 +7821,9 @@ msgid "February 2018" msgstr "" #: ../source/news.rst:126 -msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" +msgid "" +"Added python3-venv and python3-pip to Debian installation instructions. (:pr:" +"`445`)" msgstr "" #: ../source/news.rst:127 @@ -5393,7 +7831,8 @@ msgid "Updated PyPI migration info. (:pr:`439`)" msgstr "" #: ../source/news.rst:128 -msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" +msgid "" +"Added a warning about managing multiple versions with pipenv. (:pr:`430`)" msgstr "" #: ../source/news.rst:129 @@ -5421,7 +7860,8 @@ msgid "December 2017" msgstr "" #: ../source/news.rst:141 -msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" +msgid "" +"Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" msgstr "" #: ../source/news.rst:142 @@ -5441,15 +7881,20 @@ msgid "November 2017" msgstr "" #: ../source/news.rst:149 -msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" +msgid "" +"Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" msgstr "" #: ../source/news.rst:150 -msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" +msgid "" +"Updated the *Single Sourcing Package Version* tutorial to reflect pip's " +"current strategy. (:pr:`400`)" msgstr "" #: ../source/news.rst:152 -msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" +msgid "" +"Added documentation about the ``py_modules`` argument to ``setup``. (:pr:" +"`398`)" msgstr "" #: ../source/news.rst:153 @@ -5461,11 +7906,14 @@ msgid "October 2017" msgstr "" #: ../source/news.rst:158 -msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" +msgid "" +"Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" msgstr "" #: ../source/news.rst:159 -msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" +msgid "" +"Created a new guide for managing packages using ``pip`` and ``virtualenv``. " +"(:pr:`385`)" msgstr "" #: ../source/news.rst:160 @@ -5477,7 +7925,9 @@ msgid "September 2017" msgstr "" #: ../source/news.rst:165 -msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" +msgid "" +"Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:" +"`379`)" msgstr "" #: ../source/news.rst:167 @@ -5489,7 +7939,9 @@ msgid "August 2017" msgstr "" #: ../source/news.rst:172 -msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" +msgid "" +"Added a new, experimental tutorial on installing packages using ``Pipenv``. " +"(:pr:`369`)" msgstr "" #: ../source/news.rst:173 @@ -5513,15 +7965,20 @@ msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" msgstr "" #: ../source/news.rst:181 -msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" +msgid "" +"Updated this guide's ``readme`` with instructions on how to build the guide " +"locally. (:pr:`356`)" msgstr "" #: ../source/news.rst:182 -msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" +msgid "" +"Made the new ``TestPyPI`` URL more visible, adding note to homepage about " +"pypi.org. (:pr:`354`)" msgstr "" #: ../source/news.rst:183 -msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" +msgid "" +"Added a note about the removal of the explicit registration API. (:pr:`347`)" msgstr "" #: ../source/news.rst:186 @@ -5537,11 +7994,14 @@ msgid "Added documentation for ``python_requires``. (:pr:`338`)" msgstr "" #: ../source/news.rst:190 -msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" +msgid "" +"Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:" +"pr:`335`)" msgstr "" #: ../source/news.rst:191 -msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" +msgid "" +"Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" msgstr "" #: ../source/news.rst:192 @@ -5573,7 +8033,8 @@ msgid "May 2017" msgstr "" #: ../source/news.rst:202 -msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" +msgid "" +"Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" msgstr "" #: ../source/news.rst:203 @@ -5581,7 +8042,9 @@ msgid "Added contributor and style guide. (:pr:`307`)" msgstr "" #: ../source/news.rst:204 -msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" +msgid "" +"Documented ``pip`` and ``easy_install``'s differences for per-project " +"indexes. (:pr:`233`)" msgstr "" #: ../source/news.rst:207 @@ -5593,11 +8056,15 @@ msgid "Added travis configuration for testing pull requests. (:pr:`300`)" msgstr "" #: ../source/news.rst:210 -msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" +msgid "" +"Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:" +"`299`)" msgstr "" #: ../source/news.rst:211 -msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" +msgid "" +"Removed the ``twine register`` reference in the *Distributing Packages* " +"tutorial. (:pr:`271`)" msgstr "" #: ../source/news.rst:212 @@ -5609,23 +8076,33 @@ msgid "Added a topic on namespace packages. (:pr:`290`)" msgstr "" #: ../source/news.rst:214 -msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" +msgid "" +"Added documentation explaining prominently how to install ``pip`` in ``/usr/" +"local``. (:pr:`230`)" msgstr "" #: ../source/news.rst:215 -msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" +msgid "" +"Updated development mode documentation to mention that order of local " +"packages matters. (:pr:`208`)" msgstr "" #: ../source/news.rst:216 -msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" +msgid "" +"Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted " +"projects (:pr:`239`)" msgstr "" #: ../source/news.rst:217 -msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" +msgid "" +"Swaped order of :file:`setup.py` arguments for the upload command, as order " +"is significant. (:pr:`260`)" msgstr "" #: ../source/news.rst:219 -msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" +msgid "" +"Explained how to install from unsupported sources using a helper " +"application. (:pr:`289`)" msgstr "" #: ../source/news.rst:223 @@ -5649,15 +8126,26 @@ msgid "An Overview of Packaging for Python" msgstr "" #: ../source/overview.rst:7 -msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." +msgid "" +"As a general-purpose programming language, Python is designed to be used in " +"many ways. You can build web sites or industrial robots or a game for your " +"friends to play, and much more, all using the same core technology." msgstr "" #: ../source/overview.rst:12 -msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." +msgid "" +"Python's flexibility is why the first step in every Python project must be " +"to think about the project's audience and the corresponding environment " +"where the project will run. It might seem strange to think about packaging " +"before writing code, but this process does wonders for avoiding future " +"headaches." msgstr "" #: ../source/overview.rst:18 -msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." +msgid "" +"This overview provides a general-purpose decision tree for reasoning about " +"Python's plethora of packaging options. Read on to choose the best " +"technology for your next project." msgstr "" #: ../source/overview.rst:26 @@ -5665,23 +8153,36 @@ msgid "Thinking about deployment" msgstr "" #: ../source/overview.rst:28 -msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" +msgid "" +"Packages exist to be installed (or *deployed*), so before you package " +"anything, you'll want to have some answers to the deployment questions below:" msgstr "" #: ../source/overview.rst:32 -msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" +msgid "" +"Who are your software's users? Will your software be installed by other " +"developers doing software development, operations people in a datacenter, or " +"a less software-savvy group?" msgstr "" #: ../source/overview.rst:35 -msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" +msgid "" +"Is your software intended to run on servers, desktops, mobile clients " +"(phones, tablets, etc.), or embedded in dedicated devices?" msgstr "" #: ../source/overview.rst:37 -msgid "Is your software installed individually, or in large deployment batches?" +msgid "" +"Is your software installed individually, or in large deployment batches?" msgstr "" #: ../source/overview.rst:39 -msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." +msgid "" +"Packaging is all about target environment and deployment experience. There " +"are many answers to the questions above and each combination of " +"circumstances has its own solutions. With this information, the following " +"overview will guide you to the packaging technologies best suited to your " +"project." msgstr "" #: ../source/overview.rst:46 @@ -5689,11 +8190,19 @@ msgid "Packaging Python libraries and tools" msgstr "" #: ../source/overview.rst:48 -msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." +msgid "" +"You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are " +"just a few of the tools Python's ecosystem provides for distributing Python " +"code to developers, which you can read about in :doc:`guides/distributing-" +"packages-using-setuptools`." msgstr "" #: ../source/overview.rst:53 -msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." +msgid "" +"The following approaches to packaging are meant for libraries and tools used " +"by technical audience in a development setting. If you're looking for ways " +"to package Python for a non-technical audience and/or a production setting, " +"skip ahead to :ref:`packaging-applications`." msgstr "" #: ../source/overview.rst:59 @@ -5701,15 +8210,27 @@ msgid "Python modules" msgstr "" #: ../source/overview.rst:61 -msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." +msgid "" +"A Python file, provided it only relies on the standard library, can be " +"redistributed and reused. You will also need to ensure it's written for the " +"right version of Python, and only relies on the standard library." msgstr "" #: ../source/overview.rst:66 -msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." +msgid "" +"This is great for sharing simple scripts and snippets between people who " +"both have compatible Python versions (such as via email, StackOverflow, or " +"GitHub gists). There are even some entire Python libraries that offer this " +"as an option, such as `bottle.py `_ and " +"`boltons `_." msgstr "" #: ../source/overview.rst:73 -msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." +msgid "" +"However, this pattern won't scale for projects that consist of multiple " +"files, need additional libraries, or need a specific version of Python, " +"hence the options below." msgstr "" #: ../source/overview.rst:78 @@ -5717,31 +8238,60 @@ msgid "Python source distributions" msgstr "" #: ../source/overview.rst:80 -msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." +msgid "" +"If your code consists of multiple Python files, it's usually organized into " +"a directory structure. Any directory containing Python files can comprise " +"an :term:`Import Package`." msgstr "" #: ../source/overview.rst:84 -msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." +msgid "" +"Because packages consist of multiple files, they are harder to distribute. " +"Most protocols support transferring only one file at a time (when was the " +"last time you clicked a link and it downloaded multiple files?). It's easier " +"to get incomplete transfers, and harder to guarantee code integrity at the " +"destination." msgstr "" #: ../source/overview.rst:90 -msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." +msgid "" +"So long as your code contains nothing but pure Python code, and you know " +"your deployment environment supports your version of Python, then you can " +"use Python's native packaging tools to create a *source* :term:`Distribution " +"Package`, or *sdist* for short." msgstr "" #: ../source/overview.rst:95 -msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." +msgid "" +"Python's *sdists* are compressed archives (``.tar.gz`` files) containing one " +"or more packages or modules. If your code is pure-Python, and you only " +"depend on other Python packages, you can `go here to learn more `_." msgstr "" #: ../source/overview.rst:100 -msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." +msgid "" +"If you rely on any non-Python code, or non-Python packages (such as `libxml2 " +"`_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next " +"section, which also has many advantages for pure-Python libraries." msgstr "" #: ../source/overview.rst:107 -msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" +msgid "" +"Python and PyPI support multiple distributions providing different " +"implementations of the same package. For instance the unmaintained-but-" +"seminal `PIL distribution `_ provides the PIL " +"package, and so does `Pillow `_, an " +"actively-maintained fork of PIL!" msgstr "" #: ../source/overview.rst:114 -msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." +msgid "" +"This Python packaging superpower makes it possible for Pillow to be a drop-" +"in replacement for PIL, just by changing your project's ``install_requires`` " +"or ``requirements.txt``." msgstr "" #: ../source/overview.rst:119 @@ -5749,23 +8299,43 @@ msgid "Python binary distributions" msgstr "" #: ../source/overview.rst:121 -msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." +msgid "" +"So much of Python's practical power comes from its ability to integrate with " +"the software ecosystem, in particular libraries written in C, C++, Fortran, " +"Rust, and other languages." msgstr "" #: ../source/overview.rst:125 -msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." +msgid "" +"Not all developers have the right tools or experiences to build these " +"components written in these compiled languages, so Python created the :term:" +"`Wheel`, a package format designed to ship libraries with compiled " +"artifacts. In fact, Python's package installer, ``pip``, always prefers " +"wheels because installation is always faster, so even pure-Python packages " +"work better with wheels." msgstr "" #: ../source/overview.rst:132 -msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." +msgid "" +"Binary distributions are best when they come with source distributions to " +"match. Even if you don't upload wheels of your code for every operating " +"system, by uploading the sdist, you're enabling users of other platforms to " +"still build it for themselves. Default to publishing both sdist and wheel " +"archives together, *unless* you're creating artifacts for a very specific " +"use case where you know the recipient only needs one or the other." msgstr "" #: ../source/overview.rst:140 -msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." +msgid "" +"Python and PyPI make it easy to upload both wheels and sdists together. Just " +"follow the :doc:`tutorials/packaging-projects` tutorial." msgstr "" #: ../source/overview.rst:148 -msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." +msgid "" +"Python's recommended built-in library and tool packaging technologies. " +"Excerpted from `The Packaging Gradient (2017) `_." msgstr "" #: ../source/overview.rst:155 @@ -5773,23 +8343,39 @@ msgid "Packaging Python applications" msgstr "" #: ../source/overview.rst:157 -msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." +msgid "" +"So far we've only discussed Python's native distribution tools. Based on our " +"introduction, you would be correct to infer these built-in approaches only " +"target environments which have Python, and an audience who knows how to " +"install Python packages." msgstr "" #: ../source/overview.rst:162 -msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." +msgid "" +"With the variety of operating systems, configurations, and people out there, " +"this assumption is only safe when targeting a developer audience." msgstr "" #: ../source/overview.rst:166 -msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." +msgid "" +"Python's native packaging is mostly built for distributing reusable code, " +"called libraries, between developers. You can piggyback **tools**, or basic " +"applications for developers, on top of Python's library packaging, using " +"technologies like `setuptools entry_points `_." msgstr "" #: ../source/overview.rst:172 -msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." +msgid "" +"Libraries are building blocks, not complete applications. For distributing " +"applications, there's a whole new world of technologies out there." msgstr "" #: ../source/overview.rst:176 -msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." +msgid "" +"The next few sections organize these application packaging options according " +"to their dependencies on the target environment, so you can choose the right " +"one for your project." msgstr "" #: ../source/overview.rst:181 @@ -5797,15 +8383,27 @@ msgid "Depending on a framework" msgstr "" #: ../source/overview.rst:183 -msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." +msgid "" +"Some types of Python applications, like web site backends and other network " +"services, are common enough that they have frameworks to enable their " +"development and packaging. Other types of applications, like dynamic web " +"frontends and mobile clients, are complex enough to target that a framework " +"becomes more than a convenience." msgstr "" #: ../source/overview.rst:189 -msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." +msgid "" +"In all these cases, it makes sense to work backwards, from the framework's " +"packaging and deployment story. Some frameworks include a deployment system " +"which wraps the technologies outlined in the rest of the guide. In these " +"cases, you'll want to defer to your framework's packaging guide for the " +"easiest and most reliable production experience." msgstr "" #: ../source/overview.rst:195 -msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." +msgid "" +"If you ever wonder how these platforms and frameworks work under the hood, " +"you can always read the sections beyond." msgstr "" #: ../source/overview.rst:199 @@ -5813,11 +8411,15 @@ msgid "Service platforms" msgstr "" #: ../source/overview.rst:201 -msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." +msgid "" +"If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku " +"or Google App Engine, you are going to want to follow their respective " +"packaging guides." msgstr "" #: ../source/overview.rst:205 -msgid "`Heroku `_" +msgid "" +"`Heroku `_" msgstr "" #: ../source/overview.rst:206 @@ -5837,11 +8439,16 @@ msgid "\"Serverless\" frameworks like `Zappa `_" msgstr "" #: ../source/overview.rst:211 -msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." +msgid "" +"In all these setups, the platform takes care of packaging and deployment, as " +"long as you follow their patterns. Most software does not fit one of these " +"templates, hence the existence of all the other options below." msgstr "" #: ../source/overview.rst:216 -msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." +msgid "" +"If you're developing software that will be deployed to machines you own, " +"users' personal computers, or any other arrangement, read on." msgstr "" #: ../source/overview.rst:220 @@ -5849,11 +8456,16 @@ msgid "Web browsers and mobile applications" msgstr "" #: ../source/overview.rst:222 -msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." +msgid "" +"Python's steady advances are leading it into new spaces. These days you can " +"write a mobile app or web application frontend in Python. While the language " +"may be familiar, the packaging and deployment practices are brand new." msgstr "" #: ../source/overview.rst:227 -msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" +msgid "" +"If you're planning on releasing to these new frontiers, you'll want to check " +"out the following frameworks, and refer to their packaging guides:" msgstr "" #: ../source/overview.rst:231 @@ -5873,7 +8485,10 @@ msgid "`Flexx `_" msgstr "" #: ../source/overview.rst:236 -msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." +msgid "" +"If you are *not* interested in using a framework or platform, or just wonder " +"about some of the technologies and techniques utilized by the frameworks " +"above, continue reading below." msgstr "" #: ../source/overview.rst:241 @@ -5881,7 +8496,12 @@ msgid "Depending on a pre-installed Python" msgstr "" #: ../source/overview.rst:243 -msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." +msgid "" +"Pick an arbitrary computer, and depending on the context, there's a very " +"good chance Python is already installed. Included by default in most Linux " +"and Mac operating systems for many years now, you can reasonably depend on " +"Python preexisting in your data centers or on the personal machines of " +"developers and data scientists." msgstr "" #: ../source/overview.rst:249 @@ -5893,7 +8513,9 @@ msgid "`PEX `_ (Python EXecutable)" msgstr "" #: ../source/overview.rst:252 -msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" +msgid "" +"`zipapp `_ (does not help " +"manage dependencies, requires Python 3.5+)" msgstr "" #: ../source/overview.rst:253 @@ -5901,11 +8523,17 @@ msgid "`shiv `_ (requires Python 3)" msgstr "" #: ../source/overview.rst:255 -msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." +msgid "" +"Of all the approaches here, depending on a pre-installed Python relies the " +"most on the target environment. Of course, this also makes for the smallest " +"package, as small as single-digit megabytes, or even kilobytes." msgstr "" #: ../source/overview.rst:260 -msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." +msgid "" +"In general, decreasing the dependency on the target system increases the " +"size of our package, so the solutions here are roughly arranged by " +"increasing size of output." msgstr "" #: ../source/overview.rst:267 @@ -5913,11 +8541,24 @@ msgid "Depending on a separate software distribution ecosystem" msgstr "" #: ../source/overview.rst:269 -msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." +msgid "" +"For a long time many operating systems, including Mac and Windows, lacked " +"built-in package management. Only recently did these OSes gain so-called " +"\"app stores\", but even those focus on consumer applications and offer " +"little for developers." msgstr "" #: ../source/overview.rst:274 -msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." +msgid "" +"Developers long sought remedies, and in this struggle, emerged with their " +"own package management solutions, such as `Homebrew `_. " +"The most relevant alternative for Python developers is a package ecosystem " +"called `Anaconda `_. Anaconda is built around Python and is " +"increasingly common in academic, analytical, and other data-oriented " +"environments, even making its way `into server-oriented environments " +"`_." msgstr "" #: ../source/overview.rst:284 @@ -5925,15 +8566,21 @@ msgid "Instructions on building and publishing for the Anaconda ecosystem:" msgstr "" #: ../source/overview.rst:286 -msgid "`Building libraries and applications with conda `_" +msgid "" +"`Building libraries and applications with conda `_" msgstr "" #: ../source/overview.rst:287 -msgid "`Transitioning a native Python package to Anaconda `_" +msgid "" +"`Transitioning a native Python package to Anaconda `_" msgstr "" #: ../source/overview.rst:289 -msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" +msgid "" +"A similar model involves installing an alternative Python distribution, but " +"does not support arbitrary operating system-level packages:" msgstr "" #: ../source/overview.rst:293 @@ -5953,15 +8600,24 @@ msgid "Bringing your own Python executable" msgstr "" #: ../source/overview.rst:302 -msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." +msgid "" +"Computing as we know it is defined by the ability to execute programs. Every " +"operating system natively supports one or more formats of program they can " +"natively execute." msgstr "" #: ../source/overview.rst:306 -msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." +msgid "" +"There are many techniques and technologies which turn your Python program " +"into one of these formats, most of which involve embedding the Python " +"interpreter and any other dependencies into a single executable file." msgstr "" #: ../source/overview.rst:311 -msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." +msgid "" +"This approach, called *freezing*, offers wide compatibility and seamless " +"user experience, though often requires multiple technologies, and a good " +"amount of effort." msgstr "" #: ../source/overview.rst:315 @@ -5973,11 +8629,14 @@ msgid "`pyInstaller `_ - Cross-platform" msgstr "" #: ../source/overview.rst:318 -msgid "`cx_Freeze `_ - Cross-platform" +msgid "" +"`cx_Freeze `_ - Cross-platform" msgstr "" #: ../source/overview.rst:319 -msgid "`constructor `_ - For command-line installers" +msgid "" +"`constructor `_ - For command-line " +"installers" msgstr "" #: ../source/overview.rst:320 @@ -5989,7 +8648,9 @@ msgid "`py2app `_ - Mac only" msgstr "" #: ../source/overview.rst:322 -msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" +msgid "" +"`bbFreeze `_ - Windows, Linux, Python 2 " +"only" msgstr "" #: ../source/overview.rst:323 @@ -6001,7 +8662,9 @@ msgid "`pynsist `_ - Windows only" msgstr "" #: ../source/overview.rst:326 -msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." +msgid "" +"Most of the above imply single-user deployments. For multi-component server " +"applications, see `Chef Omnibus `_." msgstr "" #: ../source/overview.rst:332 @@ -6009,15 +8672,24 @@ msgid "Bringing your own userspace" msgstr "" #: ../source/overview.rst:334 -msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." +msgid "" +"An increasing number of operating systems -- including Linux, Mac OS, and " +"Windows -- can be set up to run applications packaged as lightweight images, " +"using a relatively modern arrangement often referred to as `operating-system-" +"level virtualization `_, or *containerization*." msgstr "" #: ../source/overview.rst:341 -msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." +msgid "" +"These techniques are mostly Python agnostic, because they package whole OS " +"filesystems, not just Python or Python packages." msgstr "" #: ../source/overview.rst:344 -msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" +msgid "" +"Adoption is most extensive among Linux servers, where the technology " +"originated and where the technologies below work best:" msgstr "" #: ../source/overview.rst:347 @@ -6041,11 +8713,18 @@ msgid "Bringing your own kernel" msgstr "" #: ../source/overview.rst:355 -msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." +msgid "" +"Most operating systems support some form of classical virtualization, " +"running applications packaged as images containing a full operating system " +"of their own. Running these virtual machines, or VMs, is a mature approach, " +"widespread in data center environments." msgstr "" #: ../source/overview.rst:360 -msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" +msgid "" +"These techniques are mostly reserved for larger scale deployments in data " +"centers, though certain complex applications can benefit from this " +"packaging. Technologies are Python agnostic, and include:" msgstr "" #: ../source/overview.rst:364 @@ -6053,11 +8732,16 @@ msgid "`Vagrant `_" msgstr "" #: ../source/overview.rst:365 -msgid "`VHD `_, `AMI `_, and `other formats `_" +msgid "" +"`VHD `_, `AMI `_, and `other formats `_" msgstr "" #: ../source/overview.rst:366 -msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" +msgid "" +"`OpenStack `_ - A cloud " +"management system in Python, with extensive VM support" msgstr "" #: ../source/overview.rst:369 @@ -6065,19 +8749,31 @@ msgid "Bringing your own hardware" msgstr "" #: ../source/overview.rst:371 -msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." +msgid "" +"The most all-encompassing way to ship your software would be to ship it " +"already-installed on some hardware. This way, your software's user would " +"require only electricity." msgstr "" #: ../source/overview.rst:375 -msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." +msgid "" +"Whereas the virtual machines described above are primarily reserved for the " +"tech-savvy, you can find hardware appliances being used by everyone from the " +"most advanced data centers to the youngest children." msgstr "" #: ../source/overview.rst:379 -msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." +msgid "" +"Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the " +"datacenter or your users' homes. They plug and play, and you can call it a " +"day." msgstr "" #: ../source/overview.rst:389 -msgid "The simplified gamut of technologies used to package Python applications." +msgid "" +"The simplified gamut of technologies used to package Python applications." msgstr "" #: ../source/overview.rst:392 @@ -6085,7 +8781,9 @@ msgid "What about..." msgstr "" #: ../source/overview.rst:394 -msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." +msgid "" +"The sections above can only summarize so much, and you might be wondering " +"about some of the more conspicuous gaps." msgstr "" #: ../source/overview.rst:398 @@ -6093,19 +8791,40 @@ msgid "Operating system packages" msgstr "" #: ../source/overview.rst:400 -msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." +msgid "" +"As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some " +"operating systems have package managers of their own. If you're very sure of " +"the operating system you're targeting, you can depend directly on a format " +"like `deb `_ (for Debian, " +"Ubuntu, etc.) or `RPM `_ " +"(for Red Hat, Fedora, etc.), and use that built-in package manager to take " +"care of installation, and even deployment. You can even use `FPM `_ to generate both deb " +"and RPMs from the same source." msgstr "" #: ../source/overview.rst:411 -msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." +msgid "" +"In most deployment pipelines, the OS package manager is just one piece of " +"the puzzle." msgstr "" #: ../source/overview.rst:417 -msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." +msgid "" +"`Virtualenvs `_ have been an indispensable tool for multiple generations of Python " +"developer, but are slowly fading from view, as they are being wrapped by " +"higher-level tools. With packaging in particular, virtualenvs are used as a " +"primitive in `the dh-virtualenv tool `_ and `osnap `_, " +"both of which wrap virtualenvs in a self-contained way." msgstr "" #: ../source/overview.rst:427 -msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." +msgid "" +"For production deployments, do not rely on running ``python -m pip install`` " +"from the Internet into a virtualenv, as one might do in a development " +"environment. The overview above is full of much better solutions." msgstr "" #: ../source/overview.rst:432 @@ -6113,11 +8832,20 @@ msgid "Security" msgstr "Sekureco" #: ../source/overview.rst:434 -msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." +msgid "" +"The further down the gradient you come, the harder it gets to update " +"components of your package. Everything is more tightly bound together." msgstr "" #: ../source/overview.rst:437 -msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." +msgid "" +"For example, if a kernel security issue emerges, and you're deploying " +"containers, the host system's kernel can be updated without requiring a new " +"build on behalf of the application. If you deploy VM images, you'll need a " +"new build. Whether or not this dynamic makes one option more secure is still " +"a bit of an old debate, going back to the still-unsettled matter of `static " +"versus dynamic linking `_." msgstr "" #: ../source/overview.rst:446 @@ -6125,7 +8853,12 @@ msgid "Wrap up" msgstr "" #: ../source/overview.rst:448 -msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." +msgid "" +"Packaging in Python has a bit of a reputation for being a bumpy ride. This " +"impression is mostly a byproduct of Python's versatility. Once you " +"understand the natural boundaries between each packaging solution, you begin " +"to realize that the varied landscape is a small price Python programmers pay " +"for using one of the most balanced, flexible languages available." msgstr "" #: ../source/specifications/binary-distribution-format.rst:6 @@ -6133,7 +8866,9 @@ msgid "Binary distribution format" msgstr "" #: ../source/specifications/binary-distribution-format.rst:8 -msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." +msgid "" +"The binary distribution format (:term:`wheel `) was originally " +"defined in :pep:`427`. The current version of the specification is here." msgstr "" #: ../source/specifications/binary-distribution-format.rst:13 @@ -6145,7 +8880,14 @@ msgid "This PEP describes a built-package format for Python called \"wheel\"." msgstr "" #: ../source/specifications/binary-distribution-format.rst:17 -msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." +msgid "" +"A wheel is a ZIP-format archive with a specially formatted file name and the " +"``.whl`` extension. It contains a single distribution nearly as it would be " +"installed according to PEP 376 with a particular installation scheme. " +"Although a specialized installer is recommended, a wheel file may be " +"installed by simply unpacking into site-packages with the standard 'unzip' " +"tool while preserving enough information to spread its contents out onto " +"their final paths at any later time." msgstr "" #: ../source/specifications/binary-distribution-format.rst:27 @@ -6153,7 +8895,9 @@ msgid "PEP Acceptance" msgstr "" #: ../source/specifications/binary-distribution-format.rst:29 -msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" +msgid "" +"This PEP was accepted, and the defined wheel version updated to 1.0, by Nick " +"Coghlan on 16th February, 2013 [1]_" msgstr "" #: ../source/specifications/binary-distribution-format.rst:34 @@ -6161,11 +8905,22 @@ msgid "Rationale" msgstr "" #: ../source/specifications/binary-distribution-format.rst:36 -msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." +msgid "" +"Python needs a package format that is easier to install than sdist. Python's " +"sdist packages are defined by and require the distutils and setuptools build " +"systems, running arbitrary code to build-and-install, and re-compile, code " +"just so it can be installed into a new virtualenv. This system of " +"conflating build-install is slow, hard to maintain, and hinders innovation " +"in both build systems and installers." msgstr "" #: ../source/specifications/binary-distribution-format.rst:43 -msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." +msgid "" +"Wheel attempts to remedy these problems by providing a simpler interface " +"between the build system and the installer. The wheel binary package format " +"frees installers from having to know about the build system, saves time by " +"amortizing compile time over many installations, and removes the need to " +"install a build system in the target environment." msgstr "" #: ../source/specifications/binary-distribution-format.rst:52 @@ -6189,11 +8944,14 @@ msgid "Parse ``distribution-1.0.dist-info/WHEEL``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:62 -msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." +msgid "" +"Check that installer is compatible with Wheel-Version. Warn if minor " +"version is greater, abort if major version is greater." msgstr "" #: ../source/specifications/binary-distribution-format.rst:64 -msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." +msgid "" +"If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:66 @@ -6205,15 +8963,24 @@ msgid "Spread." msgstr "" #: ../source/specifications/binary-distribution-format.rst:70 -msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." +msgid "" +"Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is " +"data) ``distribution-1.0.data/``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:72 -msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." +msgid "" +"Move each subtree of ``distribution-1.0.data/`` onto its destination path. " +"Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of " +"destination directories, such as ``distribution-1.0.data/(purelib|platlib|" +"headers|scripts|data)``. The initially supported paths are taken from " +"``distutils.command.install``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:78 -msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." +msgid "" +"If applicable, update scripts starting with ``#!python`` to point to the " +"correct interpreter." msgstr "" #: ../source/specifications/binary-distribution-format.rst:80 @@ -6225,7 +8992,9 @@ msgid "Remove empty ``distribution-1.0.data`` directory." msgstr "" #: ../source/specifications/binary-distribution-format.rst:83 -msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" +msgid "" +"Compile any installed .py to .pyc. (Uninstallers should be smart enough to " +"remove .pyc even if it is not mentioned in RECORD.)" msgstr "" #: ../source/specifications/binary-distribution-format.rst:87 @@ -6237,11 +9006,17 @@ msgid "Rewrite ``#!python``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:90 -msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." +msgid "" +"In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/" +"``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!" +"python'``, rewrite to point to the correct interpreter. Unix installers may " +"need to add the +x bit to these files if the archive was created on Windows." msgstr "" #: ../source/specifications/binary-distribution-format.rst:96 -msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." +msgid "" +"The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI " +"script instead of a console script." msgstr "" #: ../source/specifications/binary-distribution-format.rst:102 @@ -6249,7 +9024,10 @@ msgid "Generate script wrappers." msgstr "" #: ../source/specifications/binary-distribution-format.rst:100 -msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." +msgid "" +"In wheel, scripts packaged on Unix systems will certainly not have " +"accompanying .exe wrappers. Windows installers may want to add them during " +"install." msgstr "" #: ../source/specifications/binary-distribution-format.rst:105 @@ -6261,7 +9039,11 @@ msgid "Place ``.dist-info`` at the end of the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:108 -msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." +msgid "" +"Archivers are encouraged to place the ``.dist-info`` files physically at the " +"end of the archive. This enables some potentially interesting ZIP tricks " +"including the ability to amend the metadata without rewriting the entire " +"archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:115 @@ -6273,7 +9055,9 @@ msgid "File name convention" msgstr "" #: ../source/specifications/binary-distribution-format.rst:120 -msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." +msgid "" +"The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-" +"{abi tag}-{platform tag}.whl``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:124 @@ -6293,7 +9077,12 @@ msgid "build tag" msgstr "" #: ../source/specifications/binary-distribution-format.rst:130 -msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." +msgid "" +"Optional build number. Must start with a digit. Acts as a tie-breaker if " +"two wheel file names are the same in all other respects (i.e. name, version, " +"and other tags). Sort as an empty tuple if unspecified, else sort as a two-" +"item tuple with the first item being the initial digits as an ``int``, and " +"the second item being the remainder of the tag as a ``str``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:138 @@ -6321,11 +9110,18 @@ msgid "E.g. 'linux_x86_64', 'any'." msgstr "" #: ../source/specifications/binary-distribution-format.rst:146 -msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." +msgid "" +"For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of " +"a package called 'distribution', and is compatible with Python 2.7 (any " +"Python 2.7 implementation), with no ABI (pure Python), on any CPU " +"architecture." msgstr "" #: ../source/specifications/binary-distribution-format.rst:151 -msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." +msgid "" +"The last three components of the filename before the extension are called " +"\"compatibility tags.\" The compatibility tags express the package's basic " +"interpreter requirements and are detailed in PEP 425." msgstr "" #: ../source/specifications/binary-distribution-format.rst:156 @@ -6333,31 +9129,50 @@ msgid "Escaping and Unicode" msgstr "" #: ../source/specifications/binary-distribution-format.rst:158 -msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" +msgid "" +"As the components of the filename are separated by a dash (``-``, HYPHEN-" +"MINUS), this character cannot appear within any component. This is handled " +"as follows:" msgstr "" #: ../source/specifications/binary-distribution-format.rst:161 -msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." +msgid "" +"In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE " +"and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent " +"to :pep:`503` normalisation followed by replacing ``-`` with ``_``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:164 -msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." +msgid "" +"Version numbers should be normalised according to :pep:`440`. Normalised " +"version numbers cannot contain ``-``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:166 -msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." +msgid "" +"The remaining components may not contain ``-`` characters, so no escaping is " +"necessary." msgstr "" #: ../source/specifications/binary-distribution-format.rst:169 -msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." +msgid "" +"Tools producing wheels should verify that the filename components do not " +"contain ``-``, as the resulting file may not be processed correctly if they " +"do." msgstr "" #: ../source/specifications/binary-distribution-format.rst:172 -msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." +msgid "" +"The archive filename is Unicode. It will be some time before the tools are " +"updated to support non-ASCII filenames, but they are supported in this " +"specification." msgstr "" #: ../source/specifications/binary-distribution-format.rst:176 -msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." +msgid "" +"The filenames *inside* the archive are encoded as UTF-8. Although some ZIP " +"clients in common use do not properly display UTF-8 filenames, the encoding " +"is supported by both the ZIP specification and Python's ``zipfile``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:182 @@ -6365,11 +9180,17 @@ msgid "File contents" msgstr "" #: ../source/specifications/binary-distribution-format.rst:184 -msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" +msgid "" +"The contents of a wheel file, where {distribution} is replaced with the name " +"of the package, e.g. ``beaglevote`` and {version} is replaced with its " +"version, e.g. ``1.0.0``, consist of:" msgstr "" #: ../source/specifications/binary-distribution-format.rst:188 -msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." +msgid "" +"``/``, the root of the archive, contains all files to be installed in " +"``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and " +"``platlib`` are usually both ``site-packages``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:191 @@ -6377,19 +9198,30 @@ msgid "``{distribution}-{version}.dist-info/`` contains metadata." msgstr "" #: ../source/specifications/binary-distribution-format.rst:192 -msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." +msgid "" +"``{distribution}-{version}.data/`` contains one subdirectory for each non-" +"empty install scheme key not already covered, where the subdirectory name is " +"an index into a dictionary of install paths (e.g. ``data``, ``scripts``, " +"``include``, ``purelib``, ``platlib``)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:196 -msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." +msgid "" +"Python scripts must appear in ``scripts`` and begin with exactly ``b'#!" +"python'`` in order to enjoy script wrapper generation and ``#!python`` " +"rewriting at install time. They may have any or no extension." msgstr "" #: ../source/specifications/binary-distribution-format.rst:200 -msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." +msgid "" +"``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or " +"greater format metadata." msgstr "" #: ../source/specifications/binary-distribution-format.rst:202 -msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" +msgid "" +"``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive " +"itself in the same basic key: value format::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:212 @@ -6397,27 +9229,40 @@ msgid "``Wheel-Version`` is the version number of the Wheel specification." msgstr "" #: ../source/specifications/binary-distribution-format.rst:213 -msgid "``Generator`` is the name and optionally the version of the software that produced the archive." +msgid "" +"``Generator`` is the name and optionally the version of the software that " +"produced the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:215 -msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." +msgid "" +"``Root-Is-Purelib`` is true if the top level directory of the archive should " +"be installed into purelib; otherwise the root should be installed into " +"platlib." msgstr "" #: ../source/specifications/binary-distribution-format.rst:218 -msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." +msgid "" +"``Tag`` is the wheel's expanded compatibility tags; in the example the " +"filename would contain ``py2.py3-none-any``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:220 -msgid "``Build`` is the build number and is omitted if there is no build number." +msgid "" +"``Build`` is the build number and is omitted if there is no build number." msgstr "" #: ../source/specifications/binary-distribution-format.rst:221 -msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." +msgid "" +"A wheel installer should warn if Wheel-Version is greater than the version " +"it supports, and must fail if Wheel-Version has a greater major version than " +"the version it supports." msgstr "" #: ../source/specifications/binary-distribution-format.rst:224 -msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." +msgid "" +"Wheel, being an installation format that is intended to work across multiple " +"versions of Python, does not generally include .pyc files." msgstr "" #: ../source/specifications/binary-distribution-format.rst:226 @@ -6425,7 +9270,11 @@ msgid "Wheel does not contain setup.py or setup.cfg." msgstr "" #: ../source/specifications/binary-distribution-format.rst:228 -msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." +msgid "" +"This version of the wheel specification is based on the distutils install " +"schemes and does not define how to install files to other locations. The " +"layout offers a superset of the functionality provided by the existing " +"wininst and egg binary formats." msgstr "" #: ../source/specifications/binary-distribution-format.rst:235 @@ -6434,11 +9283,15 @@ msgid "The .dist-info directory" msgstr "" #: ../source/specifications/binary-distribution-format.rst:237 -msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." +msgid "" +"Wheel .dist-info directories include at a minimum METADATA, WHEEL, and " +"RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:239 -msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." +msgid "" +"METADATA is the package metadata, the same format as PKG-INFO as found at " +"the root of sdists." msgstr "" #: ../source/specifications/binary-distribution-format.rst:241 @@ -6446,7 +9299,12 @@ msgid "WHEEL is the wheel metadata specific to a build of the package." msgstr "" #: ../source/specifications/binary-distribution-format.rst:242 -msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." +msgid "" +"RECORD is a list of (almost) all the files in the wheel and their secure " +"hashes. Unlike PEP 376, every file except RECORD, which cannot contain a " +"hash of itself, must include its hash. The hash algorithm must be sha256 or " +"better; specifically, md5 and sha1 are not permitted, as signed wheel files " +"rely on the strong hashes in RECORD to validate the integrity of the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:248 @@ -6454,15 +9312,22 @@ msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:249 -msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." +msgid "" +"RECORD.jws is used for digital signatures. It is not mentioned in RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:251 -msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." +msgid "" +"RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME " +"signatures to secure their wheel files. It is not mentioned in RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:254 -msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." +msgid "" +"During extraction, wheel installers verify all the hashes in RECORD against " +"the file contents. Apart from RECORD and its signatures, installation will " +"fail if any file in the archive is not both mentioned and correctly hashed " +"in RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:261 @@ -6470,11 +9335,17 @@ msgid "The .data directory" msgstr "" #: ../source/specifications/binary-distribution-format.rst:263 -msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" +msgid "" +"Any file that is not normally installed inside site-packages goes into the ." +"data directory, named as the .dist-info directory but with the .data/ " +"extension::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:271 -msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." +msgid "" +"The .data directory contains subdirectories with the scripts, headers, " +"documentation and so forth from the distribution. During installation the " +"contents of these subdirectories are moved onto their destination paths." msgstr "" #: ../source/specifications/binary-distribution-format.rst:277 @@ -6482,15 +9353,29 @@ msgid "Signed wheel files" msgstr "" #: ../source/specifications/binary-distribution-format.rst:279 -msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" +msgid "" +"Wheel files include an extended RECORD that enables digital signatures. PEP " +"376's RECORD is altered to include a secure hash " +"``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with " +"no trailing = characters) as the second column instead of an md5sum. All " +"possible entries are hashed, including any generated files such as .pyc " +"files, but not RECORD which cannot contain its own hash. For example::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:290 -msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." +msgid "" +"The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD " +"at all since they can only be added after RECORD is generated. Every other " +"file in the archive must have a correct hash in RECORD or the installation " +"will fail." msgstr "" #: ../source/specifications/binary-distribution-format.rst:295 -msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" +msgid "" +"If JSON web signatures are used, one or more JSON Web Signature JSON " +"Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to " +"RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD " +"as the signature's JSON payload::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:302 @@ -6498,11 +9383,17 @@ msgid "(The hash value is the same format used in RECORD.)" msgstr "" #: ../source/specifications/binary-distribution-format.rst:304 -msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." +msgid "" +"If RECORD.p7s is used, it must contain a detached S/MIME format signature of " +"RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:307 -msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." +msgid "" +"A wheel installer is not required to understand digital signatures but MUST " +"verify the hashes in RECORD against the extracted file contents. When the " +"installer checks file hashes against RECORD, a separate signature checker " +"only needs to establish that RECORD matches the signature." msgstr "" #: ../source/specifications/binary-distribution-format.rst:312 @@ -6514,7 +9405,8 @@ msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" #: ../source/specifications/binary-distribution-format.rst:315 -msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" +msgid "" +"http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" msgstr "" "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" @@ -6531,23 +9423,41 @@ msgid "Comparison to .egg" msgstr "Komparo al .egg" #: ../source/specifications/binary-distribution-format.rst:323 -msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." +msgid "" +"Wheel is an installation format; egg is importable. Wheel archives do not " +"need to include .pyc and are less tied to a specific Python version or " +"implementation. Wheel can install (pure Python) packages built with previous " +"versions of Python so you don't always have to wait for the packager to " +"catch up." msgstr "" #: ../source/specifications/binary-distribution-format.rst:328 -msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." +msgid "" +"Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible " +"with the new world of Python packaging and the new concepts it brings." msgstr "" #: ../source/specifications/binary-distribution-format.rst:331 -msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." +msgid "" +"Wheel has a richer file naming convention for today's multi-implementation " +"world. A single wheel archive can indicate its compatibility with a number " +"of Python language versions and implementations, ABIs, and system " +"architectures. Historically the ABI has been specific to a CPython release, " +"wheel is ready for the stable ABI." msgstr "" #: ../source/specifications/binary-distribution-format.rst:337 -msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." +msgid "" +"Wheel is lossless. The first wheel implementation bdist_wheel always " +"generates egg-info, and then converts it to a .whl. It is also possible to " +"convert existing eggs and bdist_wininst distributions." msgstr "" #: ../source/specifications/binary-distribution-format.rst:341 -msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." +msgid "" +"Wheel is versioned. Every wheel file contains the version of the wheel " +"specification and the implementation that packaged it. Hopefully the next " +"migration can simply be to Wheel 2.0." msgstr "" #: ../source/specifications/binary-distribution-format.rst:344 @@ -6563,7 +9473,13 @@ msgid "Wheel defines a .data directory. Should I put all my data there?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:354 -msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." +msgid "" +"This specification does not have an opinion on how you should organize your " +"code. The .data directory is just a place for any files that are not " +"normally installed inside ``site-packages`` or on the PYTHONPATH. In other " +"words, you may continue to use ``pkgutil.get_data(package, resource)`` even " +"though *those* files will usually not be distributed in *wheel's* ``.data`` " +"directory." msgstr "" #: ../source/specifications/binary-distribution-format.rst:363 @@ -6571,7 +9487,12 @@ msgid "Why does wheel include attached signatures?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:365 -msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." +msgid "" +"Attached signatures are more convenient than detached signatures because " +"they travel with the archive. Since only the individual files are signed, " +"the archive can be recompressed without invalidating the signature or " +"individual files can be verified without having to download the whole " +"archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:373 @@ -6579,7 +9500,10 @@ msgid "Why does wheel allow JWS signatures?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:375 -msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." +msgid "" +"The JOSE specifications of which JWS is a part are designed to be easy to " +"implement, a feature that is also one of wheel's primary design goals. JWS " +"yields a useful, concise pure-Python implementation." msgstr "" #: ../source/specifications/binary-distribution-format.rst:381 @@ -6587,11 +9511,15 @@ msgid "Why does wheel also allow S/MIME signatures?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:383 -msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." +msgid "" +"S/MIME signatures are allowed for users who need or want to use existing " +"public key infrastructure with wheel." msgstr "" #: ../source/specifications/binary-distribution-format.rst:386 -msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." +msgid "" +"Signed packages are only a basic building block in a secure package update " +"system. Wheel only provides the building block." msgstr "" #: ../source/specifications/binary-distribution-format.rst:391 @@ -6599,15 +9527,26 @@ msgid "What's the deal with \"purelib\" vs. \"platlib\"?" msgstr "Kio temas pri «purelib» kontraste kun «platlib»?" #: ../source/specifications/binary-distribution-format.rst:393 -msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." +msgid "" +"Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is " +"significant on some platforms. For example, Fedora installs pure Python " +"packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent " +"packages to '/usr/lib64/pythonX.Y/site-packages'." msgstr "" #: ../source/specifications/binary-distribution-format.rst:398 -msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." +msgid "" +"A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-" +"{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: " +"true\" with those same files in the root, and it is legal to have files in " +"both the \"purelib\" and \"platlib\" categories." msgstr "" #: ../source/specifications/binary-distribution-format.rst:403 -msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." +msgid "" +"In practice a wheel should have only one of \"purelib\" or \"platlib\" " +"depending on whether it is pure Python or not and those files should be at " +"the root with the appropriate setting given for \"Root-is-purelib\"." msgstr "" #: ../source/specifications/binary-distribution-format.rst:409 @@ -6615,19 +9554,50 @@ msgid "Is it possible to import Python code directly from a wheel file?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:411 -msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." +msgid "" +"Technically, due to the combination of supporting installation via simple " +"extraction and using an archive format that is compatible with " +"``zipimport``, a subset of wheel files *do* support being placed directly on " +"``sys.path``. However, while this behaviour is a natural consequence of the " +"format design, actually relying on it is generally discouraged." msgstr "" #: ../source/specifications/binary-distribution-format.rst:417 -msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." +msgid "" +"Firstly, wheel *is* designed primarily as a distribution format, so skipping " +"the installation step also means deliberately avoiding any reliance on " +"features that assume full installation (such as being able to use standard " +"tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in " +"a way that can be properly tracked for auditing and security update " +"purposes, or integrating fully with the standard build machinery for C " +"extensions by publishing header files in the appropriate place)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:426 -msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." +msgid "" +"Secondly, while some Python software is written to support running directly " +"from a zip archive, it is still common for code to be written assuming it " +"has been fully installed. When that assumption is broken by trying to run " +"the software from a zip archive, the failures can often be obscure and hard " +"to diagnose (especially when they occur in third party libraries). The two " +"most common sources of problems with this are the fact that importing C " +"extensions from a zip archive is *not* supported by CPython (since doing so " +"is not supported directly by the dynamic loading machinery on any platform) " +"and that when running from a zip archive the ``__file__`` attribute no " +"longer refers to an ordinary filesystem path, but to a combination path that " +"includes both the location of the zip archive on the filesystem and the " +"relative path to the module inside the archive. Even when software correctly " +"uses the abstract resource APIs internally, interfacing with external " +"components may still require the availability of an actual on-disk file." msgstr "" #: ../source/specifications/binary-distribution-format.rst:443 -msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." +msgid "" +"Like metaclasses, monkeypatching and metapath importers, if you're not " +"already sure you need to take advantage of this feature, you almost " +"certainly don't need it. If you *do* decide to use it anyway, be aware that " +"many projects will require a failure to be reproduced with a fully installed " +"package before accepting it as a genuine bug." msgstr "" #: ../source/specifications/binary-distribution-format.rst:450 @@ -6639,11 +9609,15 @@ msgid "Since :pep:`427`, this specification has changed as follows:" msgstr "" #: ../source/specifications/binary-distribution-format.rst:454 -msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." +msgid "" +"The rules on escaping in wheel filenames were revised, to bring them into " +"line with what popular tools actually do (February 2021)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:461 -msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" +msgid "" +"PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-" +"February/124103.html)" msgstr "" #: ../source/specifications/binary-distribution-format.rst:466 @@ -6667,7 +9641,9 @@ msgid "Core metadata specifications" msgstr "" #: ../source/specifications/core-metadata.rst:7 -msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" +msgid "" +"Fields defined in the following specification should be considered valid, " +"complete and not subject to change. The required fields are:" msgstr "" #: ../source/specifications/core-metadata.rst:10 @@ -6687,15 +9663,33 @@ msgid "All the other fields are optional." msgstr "" #: ../source/specifications/core-metadata.rst:16 -msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." +msgid "" +"The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats " +"have been revised several times, and exactly which email RFC applies to " +"packaging metadata is not specified. In the absence of a precise definition, " +"the practical standard is set by what the standard library :mod:`python:" +"email.parser` module can parse using the :data:`~.python:email.policy." +"compat32` policy." msgstr "" #: ../source/specifications/core-metadata.rst:25 -msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." +msgid "" +"Although :pep:`566` defined a way to transform metadata into a JSON-" +"compatible dictionary, this is not yet used as a standard interchange " +"format. The need for tools to work with years worth of existing packages " +"makes it difficult to shift to a new format." msgstr "" #: ../source/specifications/core-metadata.rst:30 -msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." +msgid "" +"*Interpreting old metadata:* In :pep:`566`, the version specifier field " +"format specification was relaxed to accept the syntax used by popular " +"publishing tools (namely to remove the requirement that version specifiers " +"must be surrounded by parentheses). Metadata consumers may want to use the " +"more relaxed formatting rules even for metadata files that are nominally " +"less than version 2.1." msgstr "" #: ../source/specifications/core-metadata.rst:41 @@ -6703,15 +9697,25 @@ msgid "Metadata-Version" msgstr "" #: ../source/specifications/core-metadata.rst:45 -msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." +msgid "" +"Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", " +"\"2.1\" and \"2.2\"." msgstr "" #: ../source/specifications/core-metadata.rst:48 -msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." +msgid "" +"Automated tools consuming metadata SHOULD warn if ``metadata_version`` is " +"greater than the highest version they support, and MUST fail if " +"``metadata_version`` has a greater major version than the highest version " +"they support (as described in :pep:`440`, the major version is the value " +"before the first dot)." msgstr "" #: ../source/specifications/core-metadata.rst:54 -msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." +msgid "" +"For broader compatibility, build tools MAY choose to produce distribution " +"metadata using the lowest metadata version that includes all of the needed " +"fields." msgstr "" #: ../source/specifications/core-metadata.rst:58 @@ -6745,7 +9749,12 @@ msgid "Added additional restrictions on format from :pep:`508`" msgstr "" #: ../source/specifications/core-metadata.rst:72 -msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" +msgid "" +"The name of the distribution. The name field is the primary identifier for a " +"distribution. A valid name consists only of ASCII letters and numbers, " +"period, underscore and hyphen. It must start and end with a letter or " +"number. Distribution names are limited to those which match the following " +"regex (run with ``re.IGNORECASE``)::" msgstr "" #: ../source/specifications/core-metadata.rst:88 @@ -6753,7 +9762,9 @@ msgid "Version" msgstr "Versio" #: ../source/specifications/core-metadata.rst:92 -msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." +msgid "" +"A string containing the distribution's version number. This field must be " +"in the format specified in :pep:`440`." msgstr "" #: ../source/specifications/core-metadata.rst:101 @@ -6761,31 +9772,49 @@ msgid "Dynamic (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:105 -msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." +msgid "" +"A string containing the name of another core metadata field. The field names " +"``Name`` and ``Version`` may not be specified in this field." msgstr "" #: ../source/specifications/core-metadata.rst:108 -msgid "When found in the metadata of a source distribution, the following rules apply:" +msgid "" +"When found in the metadata of a source distribution, the following rules " +"apply:" msgstr "" #: ../source/specifications/core-metadata.rst:111 -msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." +msgid "" +"If a field is *not* marked as ``Dynamic``, then the value of the field in " +"any wheel built from the sdist MUST match the value in the sdist. If the " +"field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT " +"be present in the wheel." msgstr "" #: ../source/specifications/core-metadata.rst:115 -msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." +msgid "" +"If a field is marked as ``Dynamic``, it may contain any valid value in a " +"wheel built from the sdist (including not being present at all)." msgstr "" #: ../source/specifications/core-metadata.rst:118 -msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." +msgid "" +"If the sdist metadata version is older than version 2.2, then all fields " +"should be treated as if they were specified with ``Dynamic`` (i.e. there are " +"no special restrictions on the metadata of wheels built from the sdist)." msgstr "" #: ../source/specifications/core-metadata.rst:122 -msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." +msgid "" +"In any context other than a source distribution, ``Dynamic`` is for " +"information only, and indicates that the field value was calculated at wheel " +"build time, and may not be the same as the value in the sdist or in other " +"wheels for the project." msgstr "" #: ../source/specifications/core-metadata.rst:127 -msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." +msgid "" +"Full details of the semantics of ``Dynamic`` are described in :pep:`643`." msgstr "" #: ../source/specifications/core-metadata.rst:131 @@ -6793,7 +9822,10 @@ msgid "Platform (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:135 -msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." +msgid "" +"A Platform specification describing an operating system supported by the " +"distribution which is not listed in the \"Operating System\" Trove " +"classifiers. See \"Classifier\" below." msgstr "" #: ../source/specifications/core-metadata.rst:146 @@ -6801,7 +9833,11 @@ msgid "Supported-Platform (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:150 -msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." +msgid "" +"Binary distributions containing a PKG-INFO file will use the Supported-" +"Platform field in their metadata to specify the OS and CPU for which the " +"binary distribution was compiled. The semantics of the Supported-Platform " +"field are not specified in this PEP." msgstr "" #: ../source/specifications/core-metadata.rst:164 @@ -6817,23 +9853,41 @@ msgid "This field may be specified in the message body instead." msgstr "" #: ../source/specifications/core-metadata.rst:191 -msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." +msgid "" +"A longer description of the distribution that can run to several " +"paragraphs. Software that deals with metadata should not assume any maximum " +"size for this field, though people shouldn't include their instruction " +"manual as the description." msgstr "" #: ../source/specifications/core-metadata.rst:196 -msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." +msgid "" +"The contents of this field can be written using reStructuredText markup " +"[1]_. For programs that work with the metadata, supporting markup is " +"optional; programs can also display the contents of the field as-is. This " +"means that authors should be conservative in the markup they use." msgstr "" #: ../source/specifications/core-metadata.rst:202 -msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." +msgid "" +"To support empty lines and lines with indentation with respect to the RFC " +"822 format, any CRLF character has to be suffixed by 7 spaces followed by a " +"pipe (\"|\") char. As a result, the Description field is encoded into a " +"folded field that can be interpreted by RFC822 parser [2]_." msgstr "" #: ../source/specifications/core-metadata.rst:219 -msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." +msgid "" +"This encoding implies that any occurrences of a CRLF followed by 7 spaces " +"and a pipe char have to be replaced by a single CRLF when the field is " +"unfolded using a RFC822 reader." msgstr "" #: ../source/specifications/core-metadata.rst:223 -msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." +msgid "" +"Alternatively, the distribution's description may instead be provided in the " +"message body (i.e., after a completely blank line following the headers, " +"with no indentation or other special formatting necessary)." msgstr "" #: ../source/specifications/core-metadata.rst:232 @@ -6841,15 +9895,34 @@ msgid "Description-Content-Type" msgstr "" #: ../source/specifications/core-metadata.rst:236 -msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." +msgid "" +"A string stating the markup syntax (if any) used in the distribution's " +"description, so that tools can intelligently render the description." msgstr "" #: ../source/specifications/core-metadata.rst:239 -msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." +msgid "" +"Historically, PyPI supported descriptions in plain text and " +"`reStructuredText (reST) `_, and could render reST into HTML. However, it is " +"common for distribution authors to write the description in `Markdown " +"`_ (`RFC 7763 `_) as many code hosting sites render Markdown " +"READMEs, and authors would reuse the file for the description. PyPI didn't " +"recognize the format and so could not render the description correctly. This " +"resulted in many packages on PyPI with poorly-rendered descriptions when " +"Markdown is left as plain text, or worse, was attempted to be rendered as " +"reST. This field allows the distribution author to specify the format of " +"their description, opening up the possibility for PyPI and other tools to be " +"able to render Markdown and other formats." msgstr "" #: ../source/specifications/core-metadata.rst:253 -msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" +msgid "" +"The format of this field is the same as the ``Content-Type`` header in HTTP " +"(i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then " +"it can optionally have a number of parameters:" msgstr "" #: ../source/specifications/core-metadata.rst:259 @@ -6873,35 +9946,58 @@ msgid "``text/markdown``" msgstr "" #: ../source/specifications/core-metadata.rst:269 -msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." +msgid "" +"The ``charset`` parameter can be used to specify the character encoding of " +"the description. The only legal value is ``UTF-8``. If omitted, it is " +"assumed to be ``UTF-8``." msgstr "" #: ../source/specifications/core-metadata.rst:273 -msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" +msgid "" +"Other parameters might be specific to the chosen subtype. For example, for " +"the ``markdown`` subtype, there is an optional ``variant`` parameter that " +"allows specifying the variant of Markdown in use (defaults to ``GFM`` if not " +"specified). Currently, two variants are recognized:" msgstr "" #: ../source/specifications/core-metadata.rst:278 -msgid "``GFM`` for `Github-flavored Markdown `_" +msgid "" +"``GFM`` for `Github-flavored Markdown `_" msgstr "" #: ../source/specifications/core-metadata.rst:280 -msgid "``CommonMark`` for `CommonMark `_" +msgid "" +"``CommonMark`` for `CommonMark `_" msgstr "" #: ../source/specifications/core-metadata.rst:299 -msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." +msgid "" +"If a ``Description-Content-Type`` is not specified, then applications should " +"attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to " +"``text/plain`` if it is not valid rst." msgstr "" #: ../source/specifications/core-metadata.rst:303 -msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." +msgid "" +"If a ``Description-Content-Type`` is an unrecognized value, then the assumed " +"content type is ``text/plain`` (Although PyPI will probably reject anything " +"with an unrecognized value)." msgstr "" #: ../source/specifications/core-metadata.rst:307 -msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." +msgid "" +"If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is " +"not specified or is set to an unrecognized value, then the assumed " +"``variant`` is ``GFM``." msgstr "" #: ../source/specifications/core-metadata.rst:311 -msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." +msgid "" +"So for the last example above, the ``charset`` defaults to ``UTF-8`` and the " +"``variant`` defaults to ``GFM`` and thus it is equivalent to the example " +"before it." msgstr "" #: ../source/specifications/core-metadata.rst:320 @@ -6909,11 +10005,17 @@ msgid "Keywords" msgstr "" #: ../source/specifications/core-metadata.rst:324 -msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." +msgid "" +"A list of additional keywords, separated by commas, to be used to assist " +"searching for the distribution in a larger catalog." msgstr "" #: ../source/specifications/core-metadata.rst:333 -msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." +msgid "" +"The specification previously showed keywords separated by spaces, but " +"distutils and setuptools implemented it with commas. These tools have been " +"very widely used for many years, so it was easier to update the " +"specification to match the de facto standard." msgstr "" #: ../source/specifications/core-metadata.rst:341 @@ -6929,7 +10031,10 @@ msgid "Download-URL" msgstr "" #: ../source/specifications/core-metadata.rst:357 -msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" +msgid "" +"A string containing the URL from which this version of the distribution can " +"be downloaded. (This means that the URL can't be something like \".../" +"BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" msgstr "" #: ../source/specifications/core-metadata.rst:366 @@ -6937,7 +10042,9 @@ msgid "Author" msgstr "" #: ../source/specifications/core-metadata.rst:370 -msgid "A string containing the author's name at a minimum; additional contact information may be provided." +msgid "" +"A string containing the author's name at a minimum; additional contact " +"information may be provided." msgstr "" #: ../source/specifications/core-metadata.rst:383 @@ -6945,12 +10052,16 @@ msgid "Author-email" msgstr "" #: ../source/specifications/core-metadata.rst:387 -msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgid "" +"A string containing the author's e-mail address. It can contain a name and " +"e-mail address in the legal forms for a RFC-822 ``From:`` header." msgstr "" #: ../source/specifications/core-metadata.rst:395 #: ../source/specifications/core-metadata.rst:442 -msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" +msgid "" +"Per RFC-822, this field may contain multiple comma-separated e-mail " +"addresses::" msgstr "" #: ../source/specifications/core-metadata.rst:405 @@ -6958,11 +10069,16 @@ msgid "Maintainer" msgstr "Prizorganto" #: ../source/specifications/core-metadata.rst:409 -msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." +msgid "" +"A string containing the maintainer's name at a minimum; additional contact " +"information may be provided." msgstr "" #: ../source/specifications/core-metadata.rst:412 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." +msgid "" +"Note that this field is intended for use when a project is being maintained " +"by someone other than the original author: it should be omitted if it is " +"identical to ``Author``." msgstr "" #: ../source/specifications/core-metadata.rst:426 @@ -6970,11 +10086,16 @@ msgid "Maintainer-email" msgstr "" #: ../source/specifications/core-metadata.rst:430 -msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgid "" +"A string containing the maintainer's e-mail address. It can contain a name " +"and e-mail address in the legal forms for a RFC-822 ``From:`` header." msgstr "" #: ../source/specifications/core-metadata.rst:434 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." +msgid "" +"Note that this field is intended for use when a project is being maintained " +"by someone other than the original author: it should be omitted if it is " +"identical to ``Author-email``." msgstr "" #: ../source/specifications/core-metadata.rst:452 @@ -6982,7 +10103,13 @@ msgid "License" msgstr "" #: ../source/specifications/core-metadata.rst:456 -msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." +msgid "" +"Text indicating the license covering the distribution where the license is " +"not a selection from the \"License\" Trove classifiers. See :ref:`" +"\"Classifier\" ` below. This field may also be used to " +"specify a particular version of a license which is named via the " +"``Classifier`` field, or to indicate a variation or exception to such a " +"license." msgstr "" #: ../source/specifications/core-metadata.rst:476 @@ -6990,7 +10117,11 @@ msgid "Classifier (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:480 -msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." +msgid "" +"Each entry is a string giving a single classification value for the " +"distribution. Classifiers are described in :pep:`301`, and the Python " +"Package Index publishes a dynamic list of `currently defined classifiers " +"`__." msgstr "" #: ../source/specifications/core-metadata.rst:485 @@ -7008,11 +10139,15 @@ msgstr "" #: ../source/specifications/core-metadata.rst:561 #: ../source/specifications/core-metadata.rst:663 #: ../source/specifications/core-metadata.rst:704 -msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." +msgid "" +"The field format specification was relaxed to accept the syntax used by " +"popular publishing tools." msgstr "" #: ../source/specifications/core-metadata.rst:503 -msgid "Each entry contains a string naming some other distutils project required by this distribution." +msgid "" +"Each entry contains a string naming some other distutils project required by " +"this distribution." msgstr "" #: ../source/specifications/core-metadata.rst:506 @@ -7020,19 +10155,27 @@ msgid "The format of a requirement string contains from one to four parts:" msgstr "" #: ../source/specifications/core-metadata.rst:508 -msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." +msgid "" +"A project name, in the same format as the ``Name:`` field. The only " +"mandatory part." msgstr "" #: ../source/specifications/core-metadata.rst:510 -msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." +msgid "" +"A comma-separated list of 'extra' names. These are defined by the required " +"project, referring to specific features which may need extra dependencies." msgstr "" #: ../source/specifications/core-metadata.rst:513 -msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." +msgid "" +"A version specifier. Tools parsing the format should accept optional " +"parentheses around this, but tools generating it should not use parentheses." msgstr "" #: ../source/specifications/core-metadata.rst:516 -msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." +msgid "" +"An environment marker after a semicolon. This means that the requirement is " +"only needed in the specified conditions." msgstr "" #: ../source/specifications/core-metadata.rst:519 @@ -7040,11 +10183,15 @@ msgid "See :pep:`508` for full details of the allowed format." msgstr "" #: ../source/specifications/core-metadata.rst:521 -msgid "The project names should correspond to names as found on the `Python Package Index`_." +msgid "" +"The project names should correspond to names as found on the `Python Package " +"Index`_." msgstr "" #: ../source/specifications/core-metadata.rst:524 -msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." +msgid "" +"Version specifiers must follow the rules described in :doc:`version-" +"specifiers`." msgstr "" #: ../source/specifications/core-metadata.rst:538 @@ -7052,7 +10199,10 @@ msgid "Requires-Python" msgstr "" #: ../source/specifications/core-metadata.rst:542 -msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." +msgid "" +"This field specifies the Python version(s) that the distribution is " +"guaranteed to be compatible with. Installation tools may look at this when " +"picking which version of a project to install." msgstr "" #: ../source/specifications/core-metadata.rst:546 @@ -7068,15 +10218,25 @@ msgid "Requires-External (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:565 -msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." +msgid "" +"Each entry contains a string describing some dependency in the system that " +"the distribution is to be used. This field is intended to serve as a hint " +"to downstream project maintainers, and has no semantics which are meaningful " +"to the ``distutils`` distribution." msgstr "" #: ../source/specifications/core-metadata.rst:570 -msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." +msgid "" +"The format of a requirement string is a name of an external dependency, " +"optionally followed by a version declaration within parentheses." msgstr "" #: ../source/specifications/core-metadata.rst:576 -msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." +msgid "" +"Because they refer to non-Python software releases, version numbers for this " +"field are **not** required to conform to the format specified in :pep:" +"`440`: they should correspond to the version scheme used by the external " +"dependency." msgstr "" #: ../source/specifications/core-metadata.rst:581 @@ -7088,7 +10248,9 @@ msgid "Project-URL (multiple-use)" msgstr "" #: ../source/specifications/core-metadata.rst:597 -msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." +msgid "" +"A string containing a browsable URL for the project and a label for it, " +"separated by a comma." msgstr "" #: ../source/specifications/core-metadata.rst:604 @@ -7100,19 +10262,31 @@ msgid "Provides-Extra (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:616 -msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." +msgid "" +"A string containing the name of an optional feature. Must be a valid Python " +"identifier. May be used to make a dependency conditional on whether the " +"optional feature has been requested." msgstr "" #: ../source/specifications/core-metadata.rst:625 -msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." +msgid "" +"A second distribution requires an optional dependency by placing it inside " +"square brackets, and can request multiple features by separating them with a " +"comma (,). The requirements are evaluated for each requested feature and " +"added to the set of requirements for the distribution." msgstr "" #: ../source/specifications/core-metadata.rst:635 -msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." +msgid "" +"Two feature names ``test`` and ``doc`` are reserved to mark dependencies " +"that are needed for running automated tests and generating documentation, " +"respectively." msgstr "" #: ../source/specifications/core-metadata.rst:639 -msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." +msgid "" +"It is legal to specify ``Provides-Extra:`` without referencing it in any " +"``Requires-Dist:``." msgstr "" #: ../source/specifications/core-metadata.rst:644 @@ -7120,11 +10294,21 @@ msgid "Rarely Used Fields" msgstr "" #: ../source/specifications/core-metadata.rst:646 -msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." +msgid "" +"The fields in this section are currently rarely used, as their design was " +"inspired by comparable mechanisms in Linux package management systems, and " +"it isn't at all clear how tools should interpret them in the context of an " +"open index server such as `PyPI `__." msgstr "" #: ../source/specifications/core-metadata.rst:651 -msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." +msgid "" +"As a result, popular installation tools ignore them completely, which in " +"turn means there is little incentive for package publishers to set them " +"appropriately. However, they're retained in the metadata specification, as " +"they're still potentially useful for informational purposes, and can also be " +"used for their originally intended purpose in combination with a curated " +"package repository." msgstr "" #: ../source/specifications/core-metadata.rst:660 @@ -7132,19 +10316,37 @@ msgid "Provides-Dist (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:667 -msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." +msgid "" +"Each entry contains a string naming a Distutils project which is contained " +"within this distribution. This field *must* include the project identified " +"in the ``Name`` field, followed by the version : Name (Version)." msgstr "" #: ../source/specifications/core-metadata.rst:672 -msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." +msgid "" +"A distribution may provide additional names, e.g. to indicate that multiple " +"projects have been bundled together. For instance, source distributions of " +"the ``ZODB`` project have historically included the ``transaction`` project, " +"which is now available as a separate distribution. Installing such a source " +"distribution satisfies requirements for both ``ZODB`` and ``transaction``." msgstr "" #: ../source/specifications/core-metadata.rst:679 -msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." +msgid "" +"A distribution may also provide a \"virtual\" project name, which does not " +"correspond to any separately-distributed project: such a name might be used " +"to indicate an abstract capability which could be supplied by one of " +"multiple projects. E.g., multiple projects might supply RDBMS bindings for " +"use by a given ORM: each project might declare that it provides ``ORM-" +"bindings``, allowing other projects to depend only on having at most one of " +"them installed." msgstr "" #: ../source/specifications/core-metadata.rst:687 -msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." +msgid "" +"A version declaration may be supplied and must follow the rules described " +"in :doc:`version-specifiers`. The distribution's version number will be " +"implied if none is specified." msgstr "" #: ../source/specifications/core-metadata.rst:701 @@ -7152,15 +10354,23 @@ msgid "Obsoletes-Dist (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:708 -msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." +msgid "" +"Each entry contains a string describing a distutils project's distribution " +"which this distribution renders obsolete, meaning that the two projects " +"should not be installed at the same time." msgstr "" #: ../source/specifications/core-metadata.rst:712 -msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." +msgid "" +"Version declarations can be supplied. Version numbers must be in the format " +"specified in :doc:`version-specifiers`." msgstr "" #: ../source/specifications/core-metadata.rst:717 -msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." +msgid "" +"The most common use of this field will be in case a project name changes, e." +"g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install " +"Torqued Python, the Gorgon distribution should be removed." msgstr "" #: ../source/specifications/core-metadata.rst:730 @@ -7176,7 +10386,11 @@ msgid "Declaring build system dependencies" msgstr "" #: ../source/specifications/declaring-build-dependencies.rst:8 -msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." +msgid "" +"`pyproject.toml` is a build system independent file format defined in :pep:" +"`518` that projects may provide in order to declare any Python level " +"dependencies that must be installed in order to run the project's build " +"system successfully." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:5 @@ -7184,15 +10398,31 @@ msgid "Declaring project metadata" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:7 -msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." +msgid "" +":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to " +"consume. It defines the following specification as the canonical source for " +"the format used." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:12 -msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." +msgid "" +"There are two kinds of metadata: *static* and *dynamic*. Static metadata is " +"specified in the ``pyproject.toml`` file directly and cannot be specified or " +"changed by a tool. Dynamic metadata is listed via the ``dynamic`` field " +"(defined later in this specification) and represents metadata that a tool " +"will later provide." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:18 -msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." +msgid "" +"The fields defined in this specification MUST be in a table named " +"``[project]`` in ``pyproject.toml``. No tools may add fields to this table " +"which are not defined by this specification. For tools wishing to store " +"their own settings in ``pyproject.toml``, they may use the ``[tool]`` table " +"as defined in the :ref:`build dependency declaration specification " +"`. The lack of a ``[project]`` table " +"implicitly means the build back-end will dynamically provide all fields." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:27 @@ -7205,7 +10435,9 @@ msgid "``name``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:31 -msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" +msgid "" +"The fields which are required but may be specified *either* statically or " +"listed as dynamic are:" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:34 @@ -7214,7 +10446,9 @@ msgid "``version``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:36 -msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." +msgid "" +"All other fields are considered optional and my be specified statically, " +"listed as dynamic, or left unspecified." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:43 @@ -7225,7 +10459,9 @@ msgid "TOML_ type: string" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:44 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Name `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:47 @@ -7233,11 +10469,15 @@ msgid "The name of the project." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:49 -msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." +msgid "" +"Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it " +"is read for internal consistency." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:57 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Version " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:60 @@ -7253,7 +10493,9 @@ msgid "``description``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:69 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Summary " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:72 @@ -7269,7 +10511,10 @@ msgid "TOML_ type: string or table" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:79 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Description " +"` and :ref:`Description-Content-Type `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:83 @@ -7277,15 +10522,38 @@ msgid "The full description of the project (i.e. the README)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:85 -msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." +msgid "" +"The field accepts either a string or a table. If it is a string then it is a " +"path relative to ``pyproject.toml`` to a text file containing the full " +"description. Tools MUST assume the file's encoding is UTF-8. If the file " +"path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the " +"content-type is ``text/markdown``. If the file path ends in a case-" +"insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-" +"rst``. If a tool recognizes more extensions than this PEP, they MAY infer " +"the content-type for the user without specifying this field as ``dynamic``. " +"For all unrecognized suffixes when a content-type is not provided, tools " +"MUST raise an error." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:96 -msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." +msgid "" +"The ``readme`` field may also take a table. The ``file`` key has a string " +"value representing a path relative to ``pyproject.toml`` to a file " +"containing the full description. The ``text`` key has a string value which " +"is the full description. These keys are mutually-exclusive, thus tools MUST " +"raise an error if the metadata specifies both keys." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:103 -msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." +msgid "" +"A table specified in the ``readme`` field also has a ``content-type`` field " +"which takes a string specifying the content-type of the full description. A " +"tool MUST raise an error if the metadata does not specify this field in the " +"table. If the metadata does not specify the ``charset`` parameter, then it " +"is assumed to be UTF-8. Tools MAY support other encodings if they choose to. " +"Tools MAY support alternative content-types which they can transform to a " +"content-type as supported by the :ref:`core metadata `. " +"Otherwise tools MUST raise an error for unsupported content-types." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:115 @@ -7293,7 +10561,9 @@ msgid "``requires-python``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:118 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Requires-" +"Python `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:121 @@ -7309,11 +10579,19 @@ msgid "TOML_ type: table" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:128 -msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`License " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:131 -msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." +msgid "" +"The table may have one of two keys. The ``file`` key has a string value that " +"is a file path relative to ``pyproject.toml`` to the file which contains the " +"license for the project. Tools MUST assume the file's encoding is UTF-8. The " +"``text`` key has a string value which is the license of the project. These " +"keys are mutually exclusive, so a tool MUST raise an error if the metadata " +"specifies both keys." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:140 @@ -7325,35 +10603,58 @@ msgid "TOML_ type: Array of inline tables with string keys and values" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:143 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:" +"`Maintainer `, and :ref:`Maintainer-email `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:149 -msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." +msgid "" +"The people or organizations considered to be the \"authors\" of the project. " +"The exact meaning is open to interpretation — it may list the original or " +"primary authors, current maintainers, or owners of the package." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:154 -msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." +msgid "" +"The \"maintainers\" field is similar to \"authors\" in that its exact " +"meaning is open to interpretation." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:157 -msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." +msgid "" +"These fields accept an array of tables with 2 keys: ``name`` and ``email``. " +"Both values must be strings. The ``name`` value MUST be a valid email name " +"(i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not " +"contain commas. The ``email`` value MUST be a valid email address. Both keys " +"are optional." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:163 -msgid "Using the data to fill in :ref:`core metadata ` is as follows:" +msgid "" +"Using the data to fill in :ref:`core metadata ` is as follows:" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:166 -msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." +msgid "" +"If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:169 -msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." +msgid "" +"If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:173 -msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." +msgid "" +"If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-" +"email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:177 @@ -7370,7 +10671,9 @@ msgid "TOML_ type: array of strings" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:184 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Keywords " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:187 @@ -7382,7 +10685,9 @@ msgid "``classifiers``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:194 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Classifier " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:197 @@ -7398,11 +10703,15 @@ msgid "TOML_ type: table with keys and values of strings" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:204 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Project-URL " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:207 -msgid "A table of URLs where the key is the URL label and the value is the URL itself." +msgid "" +"A table of URLs where the key is the URL label and the value is the URL " +"itself." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:212 @@ -7410,7 +10719,9 @@ msgid "Entry points" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:214 -msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" +msgid "" +"TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and " +"``[project.entry-points]``)" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:216 @@ -7418,19 +10729,34 @@ msgid ":ref:`Entry points specification `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:218 -msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." +msgid "" +"There are three tables related to entry points. The ``[project.scripts]`` " +"table corresponds to the ``console_scripts`` group in the :ref:`entry points " +"specification `. The key of the table is the name of the entry " +"point and the value is the object reference." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:224 -msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." +msgid "" +"The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group " +"in the :ref:`entry points specification `. Its format is the " +"same as ``[project.scripts]``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:228 -msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." +msgid "" +"The ``[project.entry-points]`` table is a collection of tables. Each sub-" +"table's name is an entry point group. The key and value semantics are the " +"same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but " +"instead keep the entry point groups to only one level deep." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:234 -msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." +msgid "" +"Build back-ends MUST raise an error if the metadata defines a ``[project." +"entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` " +"table, as they would be ambiguous in the face of ``[project.scripts]`` and " +"``[project.gui-scripts]``, respectively." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:242 @@ -7438,11 +10764,16 @@ msgid "``dependencies``/``optional-dependencies``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:244 -msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" +msgid "" +"TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with " +"values of arrays of :pep:`508` strings (``optional-dependencies``)" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:247 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Requires-" +"Dist ` and :ref:`Provides-Extra `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:251 @@ -7450,11 +10781,22 @@ msgid "The (optional) dependencies of the project." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:253 -msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." +msgid "" +"For ``dependencies``, it is a key whose value is an array of strings. Each " +"string represents a dependency of the project and MUST be formatted as a " +"valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist " +"` entry." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:258 -msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." +msgid "" +"For ``optional-dependencies``, it is a table where each key specifies an " +"extra and whose value is an array of strings. The strings of the arrays must " +"be valid :pep:`508` strings. The keys MUST be valid values for :ref:" +"`Provides-Extra `. Each value in the array " +"thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:269 @@ -7466,39 +10808,65 @@ msgid "TOML_ type: array of string" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:272 -msgid "A corresponding :ref:`core metadata ` field does not exist" +msgid "" +"A corresponding :ref:`core metadata ` field does not exist" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:275 -msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." +msgid "" +"Specifies which fields listed by this PEP were intentionally unspecified so " +"another tool can/will provide such metadata dynamically. This clearly " +"delineates which metadata is purposefully unspecified and expected to stay " +"unspecified compared to being provided via tooling later on." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:281 -msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." +msgid "" +"A build back-end MUST honour statically-specified metadata (which means the " +"metadata did not list the field in ``dynamic``)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:283 -msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." +msgid "" +"A build back-end MUST raise an error if the metadata specifies ``name`` in " +"``dynamic``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:285 -msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." +msgid "" +"If the :ref:`core metadata ` specification lists a field as " +"\"Required\", then the metadata MUST specify the field statically or list it " +"in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it " +"should not be possible for a required field to not be listed somehow in the " +"``[project]`` table)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:290 -msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." +msgid "" +"If the :ref:`core metadata ` specification lists a field as " +"\"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is " +"a build back-end will provide the data for the field later." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:294 -msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." +msgid "" +"Build back-ends MUST raise an error if the metadata specifies a field " +"statically as well as being listed in ``dynamic``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:296 -msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." +msgid "" +"If the metadata does not list a field in ``dynamic``, then a build back-end " +"CANNOT fill in the requisite metadata on behalf of the user (i.e. " +"``dynamic`` is the only way to allow a tool to fill in metadata and the user " +"must opt into the filling in)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:300 -msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." +msgid "" +"Build back-ends MUST raise an error if the metadata specifies a field in " +"``dynamic`` but the build back-end was unable to determine the data for it " +"(omitting the data, if determined to be the accurate value, is acceptable)." msgstr "" #: ../source/specifications/dependency-specifiers.rst:6 @@ -7506,11 +10874,15 @@ msgid "Dependency specifiers" msgstr "" #: ../source/specifications/dependency-specifiers.rst:8 -msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." +msgid "" +"The dependency specifier format used to declare a dependency on another " +"component is defined in :pep:`508`." msgstr "" #: ../source/specifications/dependency-specifiers.rst:11 -msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." +msgid "" +"The environment markers section in this PEP supersedes the environment " +"markers section in :pep:`345`." msgstr "" #: ../source/specifications/direct-url.rst:6 @@ -7518,7 +10890,11 @@ msgid "Recording the Direct URL Origin of installed distributions" msgstr "" #: ../source/specifications/direct-url.rst:8 -msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." +msgid "" +"This document specifies a :file:`direct_url.json` file in the :file:`*.dist-" +"info` directory of an installed distribution, to record the Direct URL " +"Origin of the distribution. The layout of this file was originally specified " +"in :pep:`610` and is formally documented here." msgstr "" #: ../source/specifications/direct-url.rst:17 @@ -7526,80 +10902,145 @@ msgid "Specification" msgstr "" #: ../source/specifications/direct-url.rst:19 -msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgid "" +"The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` " +"directory by installers when installing a distribution from a requirement " +"specifying a direct URL reference (including a VCS URL)." msgstr "" #: ../source/specifications/direct-url.rst:23 #: ../source/specifications/recording-installed-packages.rst:206 -msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." +msgid "" +"This file MUST NOT be created when installing a distribution from an other " +"type of requirement (i.e. name plus version specifier)." msgstr "" #: ../source/specifications/direct-url.rst:26 -msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." +msgid "" +"This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." msgstr "" #: ../source/specifications/direct-url.rst:29 -msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." +msgid "" +"If present, it MUST contain at least two fields. The first one is ``url``, " +"with type ``string``. Depending on what ``url`` refers to, the second field " +"MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), " +"``archive_info`` (if ``url`` is a source archives or a wheel), or " +"``dir_info`` (if ``url`` is a local directory). These info fields have a " +"(possibly empty) subdictionary as value, with the possible keys defined " +"below." msgstr "" #: ../source/specifications/direct-url.rst:36 -msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." +msgid "" +"``url`` MUST be stripped of any sensitive authentication information, for " +"security reasons." msgstr "" #: ../source/specifications/direct-url.rst:39 -msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" +msgid "" +"The user:password section of the URL MAY however be composed of environment " +"variables, matching the following regular expression::" msgstr "" #: ../source/specifications/direct-url.rst:45 -msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." +msgid "" +"Additionally, the user:password section of the URL MAY be a well-known, non " +"security sensitive string. A typical example is ``git`` in the case of an " +"URL such as ``ssh://git@gitlab.com/user/repo``." msgstr "" #: ../source/specifications/direct-url.rst:49 -msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" +msgid "" +"When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be " +"present as a dictionary with the following keys:" msgstr "" #: ../source/specifications/direct-url.rst:52 -msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." +msgid "" +"A ``vcs`` key (type ``string``) MUST be present, containing the name of the " +"VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be " +"registered by writing a PEP to amend this specification. The ``url`` value " +"MUST be compatible with the corresponding VCS, so an installer can hand it " +"off without transformation to a checkout/download command of the VCS." msgstr "" #: ../source/specifications/direct-url.rst:58 -msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." +msgid "" +"A ``requested_revision`` key (type ``string``) MAY be present naming a " +"branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to " +"install." msgstr "" #: ../source/specifications/direct-url.rst:61 -msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." +msgid "" +"A ``commit_id`` key (type ``string``) MUST be present, containing the exact " +"commit/revision number that was installed. If the VCS supports commit-hash " +"based revision identifiers, such commit-hash MUST be used as ``commit_id`` " +"in order to reference the immutable version of the source code that was " +"installed." msgstr "" #: ../source/specifications/direct-url.rst:68 -msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" +msgid "" +"When ``url`` refers to a source archive or a wheel, the ``archive_info`` key " +"MUST be present as a dictionary with the following key:" msgstr "" #: ../source/specifications/direct-url.rst:71 -msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." +msgid "" +"A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are " +"unconditionally provided by the latest version of the standard library's " +"``hashlib`` module be used for source archive hashes. At time of writing, " +"that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and " +"'sha512'." msgstr "" #: ../source/specifications/direct-url.rst:78 -msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" +msgid "" +"When ``url`` refers to a local directory, the ``dir_info`` key MUST be " +"present as a dictionary with the following key:" msgstr "" #: ../source/specifications/direct-url.rst:81 -msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." +msgid "" +"``editable`` (type: ``boolean``): ``true`` if the distribution was installed " +"in editable mode, ``false`` otherwise. If absent, default to ``false``." msgstr "" #: ../source/specifications/direct-url.rst:84 -msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." +msgid "" +"When ``url`` refers to a local directory, it MUST have the ``file`` sheme " +"and be compliant with `RFC 8089 `_. In " +"particular, the path component must be absolute. Symbolic links SHOULD be " +"preserved when making relative paths absolute." msgstr "" #: ../source/specifications/direct-url.rst:91 -msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." +msgid "" +"When the requested URL has the file:// scheme and points to a local " +"directory that happens to contain a VCS checkout, installers MUST NOT " +"attempt to infer any VCS information and therefore MUST NOT output any VCS " +"related information (such as ``vcs_info``) in :file:`direct_url.json`." msgstr "" #: ../source/specifications/direct-url.rst:96 -msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." +msgid "" +"A top-level ``subdirectory`` field MAY be present containing a directory " +"path, relative to the root of the VCS repository, source archive or local " +"directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." msgstr "" #: ../source/specifications/direct-url.rst:102 -msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." +msgid "" +"As a general rule, installers should as much as possible preserve the " +"information that was provided in the requested URL when generating :file:" +"`direct_url.json`. For example user:password environment variables should be " +"preserved and ``requested_revision`` should reflect the revision that was " +"provided in the requested URL as faithfully as possible. This information is " +"however *enriched* with more precise data, such as ``commit_id``." msgstr "" #: ../source/specifications/direct-url.rst:110 @@ -7607,7 +11048,14 @@ msgid "Registered VCS" msgstr "" #: ../source/specifications/direct-url.rst:112 -msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." +msgid "" +"This section lists the registered VCS's; expanded, VCS-specific information " +"on how to use the ``vcs``, ``requested_revision``, and other fields of " +"``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY " +"support other VCS's although it is RECOMMENDED to register them by writing a " +"PEP to amend this specification. The ``vcs`` field SHOULD be the command " +"name (lowercased). Additional fields that would be necessary to support such " +"VCS SHOULD be prefixed with the VCS command name." msgstr "" #: ../source/specifications/direct-url.rst:122 @@ -7652,7 +11100,9 @@ msgid "``requested_revision`` field" msgstr "" #: ../source/specifications/direct-url.rst:138 -msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." +msgid "" +"A tag name, branch name, Git ref, commit hash, shortened commit hash, or " +"other commit-ish." msgstr "" #: ../source/specifications/direct-url.rst:141 @@ -7667,7 +11117,11 @@ msgid "A commit hash (40 hexadecimal characters sha1)." msgstr "" #: ../source/specifications/direct-url.rst:147 -msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." +msgid "" +"Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to " +"determine if the ``requested_revision`` corresponds to a Git ref. In turn, a " +"ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning " +"with ``refs/remotes/origin/`` after cloning corresponds to a branch." msgstr "" #: ../source/specifications/direct-url.rst:154 @@ -7726,11 +11180,15 @@ msgid "svn" msgstr "" #: ../source/specifications/direct-url.rst:216 -msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." +msgid "" +"``requested_revision`` must be compatible with ``svn checkout`` ``--" +"revision`` option. In Subversion, branch or tag is part of ``url``." msgstr "" #: ../source/specifications/direct-url.rst:221 -msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." +msgid "" +"Since Subversion does not support globally unique identifiers, this field is " +"the Subversion revision number in the corresponding repository." msgstr "" #: ../source/specifications/direct-url.rst:229 @@ -7770,7 +11228,9 @@ msgid "pip install https://example.com/app-1.0.whl" msgstr "" #: ../source/specifications/direct-url.rst:283 -msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" +msgid "" +"pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup" +"\"" msgstr "" #: ../source/specifications/direct-url.rst:284 @@ -7782,7 +11242,11 @@ msgid "pip install file:///home/user/app" msgstr "" #: ../source/specifications/direct-url.rst:286 -msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" +msgid "" +"pip install --editable \"git+https://example.com/repo/app." +"git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local " +"directory where the git repository has been cloned to, and ``dir_info`` will " +"be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" msgstr "" #: ../source/specifications/direct-url.rst:290 @@ -7806,19 +11270,37 @@ msgid "Entry points specification" msgstr "" #: ../source/specifications/entry-points.rst:7 -msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" +msgid "" +"*Entry points* are a mechanism for an installed distribution to advertise " +"components it provides to be discovered and used by other code. For example:" msgstr "" #: ../source/specifications/entry-points.rst:11 -msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." +msgid "" +"Distributions can specify ``console_scripts`` entry points, each referring " +"to a function. When *pip* (or another console_scripts aware installer) " +"installs the distribution, it will create a command-line wrapper for each " +"entry point." msgstr "" #: ../source/specifications/entry-points.rst:14 -msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." +msgid "" +"Applications can use entry points to load plugins; e.g. Pygments (a syntax " +"highlighting tool) can use additional lexers and styles from separately " +"installed packages. For more about this, see :doc:`/guides/creating-and-" +"discovering-plugins`." msgstr "" #: ../source/specifications/entry-points.rst:19 -msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." +msgid "" +"The entry point file format was originally developed to allow packages built " +"with setuptools to provide integration point metadata that would be read at " +"runtime with ``importlib.metadata``. It is now defined as a PyPA " +"interoperability specification in order to allow build tools other than " +"setuptools to publish ``importlib.metadata`` compatible entry point " +"metadata, and runtime libraries other than ``importlib.metadata`` to " +"portably read published entry point metadata (potentially with different " +"caching and conflict resolution strategies)." msgstr "" #: ../source/specifications/entry-points.rst:28 @@ -7830,27 +11312,61 @@ msgid "Conceptually, an entry point is defined by three required properties:" msgstr "" #: ../source/specifications/entry-points.rst:32 -msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." +msgid "" +"The **group** that an entry point belongs to indicates what sort of object " +"it provides. For instance, the group ``console_scripts`` is for entry points " +"referring to functions which can be used as a command, while ``pygments." +"styles`` is the group for classes defining pygments styles. The consumer " +"typically defines the expected interface. To avoid clashes, consumers " +"defining a new group should use names starting with a PyPI name owned by the " +"consumer project, followed by ``.``. Group names must be one or more groups " +"of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w" +"+)*$``)." msgstr "" #: ../source/specifications/entry-points.rst:42 -msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." +msgid "" +"The **name** identifies this entry point within its group. The precise " +"meaning of this is up to the consumer. For console scripts, the name of the " +"entry point is the command that will be used to launch it. Within a " +"distribution, entry point names should be unique. If different distributions " +"provide the same name, the consumer decides how to handle such conflicts. " +"The name may contain any characters except ``=``, but it cannot start or end " +"with any whitespace character, or start with ``[``. For new entry points, it " +"is recommended to use only letters, numbers, underscores, dots and dashes " +"(regex ``[\\w.-]+``)." msgstr "" #: ../source/specifications/entry-points.rst:51 -msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" +msgid "" +"The **object reference** points to a Python object. It is either in the form " +"``importable.module``, or ``importable.module:object.attr``. Each of the " +"parts delimited by dots and the colon is a valid Python identifier. It is " +"intended to be looked up like this::" msgstr "" #: ../source/specifications/entry-points.rst:64 -msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." +msgid "" +"Some tools call this kind of object reference by itself an 'entry point', " +"for want of a better term, especially where it points to a function to " +"launch a program." msgstr "" #: ../source/specifications/entry-points.rst:68 -msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." +msgid "" +"There is also an optional property: the **extras** are a set of strings " +"identifying optional features of the distribution providing the entry point. " +"If these are specified, the entry point requires the dependencies of those " +"'extras'. See the metadata field :ref:`metadata_provides_extra`." msgstr "" #: ../source/specifications/entry-points.rst:73 -msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." +msgid "" +"Using extras for an entry point is no longer recommended. Consumers should " +"support parsing them from existing distributions, but may then ignore them. " +"New publishing tools need not support specifying extras. The functionality " +"of handling extras was tied to setuptools' model of managing 'egg' packages, " +"but newer tools such as pip and virtualenv use a different model." msgstr "" #: ../source/specifications/entry-points.rst:80 @@ -7858,23 +11374,44 @@ msgid "File format" msgstr "" #: ../source/specifications/entry-points.rst:82 -msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." +msgid "" +"Entry points are defined in a file called :file:`entry_points.txt` in the :" +"file:`*.dist-info` directory of the distribution. This is the directory " +"described in :pep:`376` for installed distributions, and in :pep:`427` for " +"wheels. The file uses the UTF-8 character encoding." msgstr "" #: ../source/specifications/entry-points.rst:87 -msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" +msgid "" +"The file contents are in INI format, as read by Python's :mod:`configparser` " +"module. However, configparser treats names as case-insensitive by default, " +"whereas entry point names are case sensitive. A case-sensitive config parser " +"can be made like this::" msgstr "" #: ../source/specifications/entry-points.rst:97 -msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." +msgid "" +"The entry points file must always use ``=`` to delimit names from values " +"(whereas configparser also allows using ``:``)." msgstr "" #: ../source/specifications/entry-points.rst:100 -msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." +msgid "" +"The sections of the config file represent entry point groups, the names are " +"names, and the values encode both the object reference and the optional " +"extras. If extras are used, they are a comma-separated list inside square " +"brackets." msgstr "" #: ../source/specifications/entry-points.rst:104 -msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." +msgid "" +"Within a value, readers must accept and ignore spaces (including multiple " +"consecutive spaces) before or after the colon, between the object reference " +"and the left square bracket, between the extra names and the square brackets " +"and colons delimiting them, and after the right square bracket. The syntax " +"for extras is formally specified as part of :pep:`508` (as ``extras``). For " +"tools writing the file, it is recommended only to insert a space between the " +"object reference and the left square bracket." msgstr "" #: ../source/specifications/entry-points.rst:112 @@ -7886,23 +11423,47 @@ msgid "Use for scripts" msgstr "" #: ../source/specifications/entry-points.rst:126 -msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." +msgid "" +"Two groups of entry points have special significance in packaging: " +"``console_scripts`` and ``gui_scripts``. In both groups, the name of the " +"entry point should be usable as a command in a system shell after the " +"package is installed. The object reference points to a function which will " +"be called with no arguments when this command is run. The function may " +"return an integer to be used as a process exit code, and returning ``None`` " +"is equivalent to returning ``0``." msgstr "" #: ../source/specifications/entry-points.rst:134 -msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" +msgid "" +"For instance, the entry point ``mycmd = mymod:main`` would create a command " +"``mycmd`` launching a script like this::" msgstr "" #: ../source/specifications/entry-points.rst:141 -msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." +msgid "" +"The difference between ``console_scripts`` and ``gui_scripts`` only affects " +"Windows systems. ``console_scripts`` are wrapped in a console executable, so " +"they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and " +"``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI " +"executable, so they can be started without a console, but cannot use " +"standard streams unless application code redirects them. Other platforms do " +"not have the same distinction." msgstr "" #: ../source/specifications/entry-points.rst:149 -msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." +msgid "" +"Install tools are expected to set up wrappers for both ``console_scripts`` " +"and ``gui_scripts`` in the scripts directory of the install scheme. They are " +"not responsible for putting this directory in the ``PATH`` environment " +"variable which defines where command-line tools are found." msgstr "" #: ../source/specifications/entry-points.rst:154 -msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." +msgid "" +"As files are created from the names, and some filesystems are case-" +"insensitive, packages should avoid using names in these groups which differ " +"only in case. The behaviour of install tools when names differ only in case " +"is undefined." msgstr "" #: ../source/specifications/index.rst:4 @@ -7910,7 +11471,11 @@ msgid "PyPA specifications" msgstr "" #: ../source/specifications/index.rst:6 -msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." +msgid "" +"This is a list of currently active interoperability specifications " +"maintained by the Python Packaging Authority. The process for updating these " +"standards, and for proposing new ones, is documented on `pypa.io `__." msgstr "" #: ../source/specifications/index.rst:13 @@ -7930,11 +11495,16 @@ msgid "Platform compatibility tags" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:8 -msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." +msgid "" +"Platform compatibility tags allow build tools to mark distributions as being " +"compatible with specific platforms, and allows installers to understand " +"which distributions are compatible with the system they are running on." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:12 -msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." +msgid "" +"The platform compatibility tagging model used for the ``wheel`` distribution " +"format is defined in :pep:`425`." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:16 @@ -7942,7 +11512,9 @@ msgid "Platform tags for Windows" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:18 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." +msgid "" +"The scheme defined in :pep:`425` covers public distribution of wheel files " +"to systems running Windows." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:22 @@ -7950,7 +11522,9 @@ msgid "Platform tags for macOS (Mac OS X)" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:24 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." +msgid "" +"The scheme defined in :pep:`425` covers public distribution of wheel files " +"to systems running macOS (previously known as Mac OS X)." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:28 @@ -7958,39 +11532,70 @@ msgid "Platform tags for common Linux distributions" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:32 -msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." +msgid "" +"The scheme defined in :pep:`425` is insufficient for public distribution of " +"wheel files (and \\*nix wheel files in general) to Linux platforms, due to " +"the large ecosystem of Linux platforms and subtle differences between them." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:36 -msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." +msgid "" +"Instead, :pep:`600` defines the ``manylinux`` standard, which represents a " +"common subset of Linux platforms, and allows building wheels tagged with the " +"``manylinux`` platform tag which can be used across most common Linux " +"distributions." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:41 -msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" +msgid "" +"There were multiple iterations of the ``manylinux`` specification, each " +"representing the common subset of Linux platforms at a given point in time:" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:44 -msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." +msgid "" +"``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, " +"and is based on a compatible Linux platform from 2007." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:46 -msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." +msgid "" +"``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` " +"architectures. and updates the previous specification to be based on a " +"compatible Linux platform from 2010 instead." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:49 -msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." +msgid "" +"``manylinux2014`` (:pep:`599`) adds support for a number of additional " +"architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and " +"``s390x``) and updates the base platform to a compatible Linux platform from " +"2014." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:54 -msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." +msgid "" +"``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a " +"future-proof standard. It defines ``x`` and ``y`` as glibc major an minor " +"versions supported (e.g. ``manylinux_2_24`` should work on any distro using " +"glibc 2.24+). Previous tags are still supported for backward compatibility." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:59 -msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." +msgid "" +"In general, distributions built for older versions of the specification are " +"forwards-compatible (meaning that ``manylinux1`` distributions should " +"continue to work on modern systems) but not backwards-compatible (meaning " +"that ``manylinux2010`` distributions are not expected to work on platforms " +"that existed before 2010)." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:65 -msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." +msgid "" +"Package maintainers should attempt to target the most compatible " +"specification possible, with the caveat that the provided build environment " +"for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning " +"that these images will no longer receive security updates." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:71 @@ -7998,15 +11603,21 @@ msgid "Manylinux compatibility support" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:74 -msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." +msgid "" +"The ``manylinux2014`` specification is relatively new and is not yet widely " +"recognised by install tools." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:76 -msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." +msgid "" +"The ``manylinux_x_y`` specification is relatively new and is not yet widely " +"recognised by install tools." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:79 -msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" +msgid "" +"The following table shows the minimum versions of relevant projects to " +"support the various ``manylinux`` standards:" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:83 @@ -8070,7 +11681,11 @@ msgid "Platform tags for other \\*nix platforms" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:92 -msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." +msgid "" +"The scheme defined in :pep:`425` is not generally sufficient for public " +"distribution of wheel files to other \\*nix platforms. Efforts are currently " +"(albeit intermittently) under way to define improved compatibility tagging " +"schemes for AIX and for Alpine Linux." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:98 @@ -8082,7 +11697,11 @@ msgid "The :file:`.pypirc` file" msgstr "" #: ../source/specifications/pypirc.rst:8 -msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." +msgid "" +"A :file:`.pypirc` file allows you to define the configuration for :term:" +"`package indexes ` (referred to here as \"repositories\"), so " +"that you don't have to enter the URL, username, or password whenever you " +"upload a package with :ref:`twine` or :ref:`flit`." msgstr "" #: ../source/specifications/pypirc.rst:13 @@ -8090,7 +11709,9 @@ msgid "The format (originally defined by the :ref:`distutils` package) is:" msgstr "" #: ../source/specifications/pypirc.rst:32 -msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." +msgid "" +"The ``distutils`` section defines an ``index-servers`` field that lists the " +"name of all sections describing a repository." msgstr "" #: ../source/specifications/pypirc.rst:35 @@ -8110,11 +11731,16 @@ msgid "``password``: The password that will used to authenticate the username." msgstr "" #: ../source/specifications/pypirc.rst:43 -msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." +msgid "" +"Be aware that this stores your password in plain text. For better security, " +"consider an alternative like `keyring`_, setting environment variables, or " +"providing the password on the command line." msgstr "" #: ../source/specifications/pypirc.rst:47 -msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" +msgid "" +"Otherwise, set the permissions on :file:`.pypirc` so that only you can view " +"or modify it. For example, on Linux or macOS, run:" msgstr "" #: ../source/specifications/pypirc.rst:57 @@ -8122,15 +11748,23 @@ msgid "Common configurations" msgstr "" #: ../source/specifications/pypirc.rst:61 -msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." +msgid "" +"These examples apply to :ref:`twine`, and projects like :ref:`hatch` that " +"use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`." +"pypirc`, but with different defaults. Please refer to each project's " +"documentation for more details and usage instructions." msgstr "" #: ../source/specifications/pypirc.rst:66 -msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" +msgid "" +"Twine's default configuration mimics a :file:`.pypirc` with repository " +"sections for PyPI and TestPyPI:" msgstr "" #: ../source/specifications/pypirc.rst:82 -msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." +msgid "" +"Twine will add additional configuration from :file:`$HOME/.pypirc`, the " +"command line, and environment variables to this default configuration." msgstr "" #: ../source/specifications/pypirc.rst:86 @@ -8138,11 +11772,15 @@ msgid "Using a PyPI token" msgstr "" #: ../source/specifications/pypirc.rst:88 -msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" +msgid "" +"To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` " +"similar to:" msgstr "" #: ../source/specifications/pypirc.rst:97 -msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." +msgid "" +"For :ref:`TestPyPI `, add a ``[testpypi]`` section, using " +"the API token from your TestPyPI account." msgstr "" #: ../source/specifications/pypirc.rst:103 @@ -8150,11 +11788,16 @@ msgid "Using another package index" msgstr "" #: ../source/specifications/pypirc.rst:105 -msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" +msgid "" +"To configure an additional repository, you'll need to redefine the ``index-" +"servers`` field to include the repository name. Here is a complete example " +"of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" msgstr "" #: ../source/specifications/pypirc.rst:132 -msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" +msgid "" +"Instead of using the ``password`` field, consider saving your API tokens and " +"passwords securely using `keyring`_ (which is installed by Twine):" msgstr "" #: ../source/specifications/recording-installed-packages.rst:5 @@ -8162,11 +11805,20 @@ msgid "Recording installed projects" msgstr "" #: ../source/specifications/recording-installed-packages.rst:7 -msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." +msgid "" +"This document specifies a common format of recording information about " +"Python :term:`projects ` installed in an environment. A common " +"metadata format allows tools to query, manage or uninstall projects, " +"regardless of how they were installed." msgstr "" #: ../source/specifications/recording-installed-packages.rst:12 -msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." +msgid "" +"Almost all information is optional. This allows tools outside the Python " +"ecosystem, such as Linux package managers, to integrate with Python tooling " +"as much as possible. For example, even if an installer cannot easily provide " +"a list of installed files in a format specific to Python tooling, it should " +"still record the name and version of the installed project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:21 @@ -8174,31 +11826,65 @@ msgid "History and change workflow" msgstr "" #: ../source/specifications/recording-installed-packages.rst:23 -msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." +msgid "" +"The metadata described here was first specified in :pep:`376`, and later " +"amended in :pep:`627`. It was formerly known as *Database of Installed " +"Python Distributions*. Further amendments (except trivial language or " +"typography fixes) must be made through the PEP process (see :pep:`1`)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:29 -msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." +msgid "" +"While this document is the normative specification, these PEPs that " +"introduce changes to it may include additional information such as " +"rationales and backwards compatibility considerations." msgstr "" #: ../source/specifications/recording-installed-packages.rst:37 -msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." +msgid "" +"Each project installed from a distribution must, in addition to files, " +"install a \"``.dist-info``\" directory located alongside importable modules " +"and packages (commonly, the ``site-packages`` directory)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:41 -msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." +msgid "" +"This directory is named as ``{name}-{version}.dist-info``, with ``name`` and " +"``version`` fields corresponding to :ref:`core-metadata`. Both fields must " +"be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 " +"<440#normalization>` for the definition of normalization for each field " +"respectively), and replace dash (``-``) characters with underscore (``_``) " +"chacaters, so the ``.dist-info`` directory always has exactly one dash (``-" +"``) character in its stem, separating the ``name`` and ``version`` fields." msgstr "" #: ../source/specifications/recording-installed-packages.rst:50 -msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." +msgid "" +"Historically, tools have failed to replace dot characters or normalize case " +"in the ``name`` field, or not perform normalization in the ``version`` " +"field. Tools consuming ``.dist-info`` directories should expect those fields " +"to be unnormalized, and treat them as equivalent to their normalized " +"counterparts. New tools that write ``.dist-info`` directories MUST normalize " +"both ``name`` and ``version`` fields using the rules described above, and " +"existing tools are encouraged to start normalizing those fields." msgstr "" #: ../source/specifications/recording-installed-packages.rst:60 -msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." +msgid "" +"The ``.dist-info`` directory's name is formatted to unambigiously represent " +"a distribution as a filesystem path. Tools presenting a distribution name to " +"a user should avoid using the normalized name, and instead present the " +"specified name (when needed prior to resolution to an installed package), or " +"read the respective fields in Core Metadata, since values listed there are " +"unescaped and accurately reflect the distribution. Libraries should provide " +"API for such tools to consume, so tools can have access to the unnormalized " +"name when displaying distrubution information." msgstr "" #: ../source/specifications/recording-installed-packages.rst:69 -msgid "This ``.dist-info`` directory can contain these files, described in detail below:" +msgid "" +"This ``.dist-info`` directory can contain these files, described in detail " +"below:" msgstr "" #: ../source/specifications/recording-installed-packages.rst:72 @@ -8210,19 +11896,31 @@ msgid "``RECORD``: records the list of installed files." msgstr "" #: ../source/specifications/recording-installed-packages.rst:74 -msgid "``INSTALLER``: records the name of the tool used to install the project." +msgid "" +"``INSTALLER``: records the name of the tool used to install the project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:76 -msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." +msgid "" +"The ``METADATA`` file is mandatory. All other files may be omitted at the " +"installing tool's discretion. Additional installer-specific files may be " +"present." msgstr "" #: ../source/specifications/recording-installed-packages.rst:82 -msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." +msgid "" +"The :ref:`binary-distribution-format` specification describes additional " +"files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. " +"Such files may be copied to the ``.dist-info`` directory of an installed " +"project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:87 -msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." +msgid "" +"The previous versions of this specification also specified a ``REQUESTED`` " +"file. This file is now considered a tool-specific extension, but may be " +"standardized again in the future. See `PEP 376 `_ for its original meaning." msgstr "" #: ../source/specifications/recording-installed-packages.rst:94 @@ -8230,11 +11928,16 @@ msgid "The METADATA file" msgstr "" #: ../source/specifications/recording-installed-packages.rst:96 -msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." +msgid "" +"The ``METADATA`` file contains metadata as described in the :ref:`core-" +"metadata` specification, version 1.1 or greater." msgstr "" #: ../source/specifications/recording-installed-packages.rst:99 -msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." +msgid "" +"The ``METADATA`` file is mandatory. If it cannot be created, or if required " +"core metadata is not available, installers must report an error and fail to " +"install the project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:105 @@ -8242,11 +11945,15 @@ msgid "The RECORD file" msgstr "" #: ../source/specifications/recording-installed-packages.rst:107 -msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." +msgid "" +"The ``RECORD`` file holds the list of installed files. It is a CSV file " +"containing one record (line) per installed file." msgstr "" #: ../source/specifications/recording-installed-packages.rst:110 -msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" +msgid "" +"The CSV dialect must be readable with the default ``reader`` of Python's " +"``csv`` module:" msgstr "" #: ../source/specifications/recording-installed-packages.rst:113 @@ -8262,31 +11969,56 @@ msgid "line terminator: either ``\\r\\n`` or ``\\n``." msgstr "" #: ../source/specifications/recording-installed-packages.rst:117 -msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." +msgid "" +"Each record is composed of three elements: the file's **path**, the **hash** " +"of the contents, and its **size**." msgstr "" #: ../source/specifications/recording-installed-packages.rst:120 -msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." +msgid "" +"The *path* may be either absolute, or relative to the directory containing " +"the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On " +"Windows, directories may be separated either by forward- or backslashes (``/" +"`` or ``\\``)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:125 -msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." +msgid "" +"The *hash* is either an empty string or the name of a hash algorithm from " +"``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` " +"and the digest of the file's contents, encoded with the urlsafe-base64-nopad " +"encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:130 -msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." +msgid "" +"The *size* is either the empty string, or file's size in bytes, as a base 10 " +"integer." msgstr "" #: ../source/specifications/recording-installed-packages.rst:133 -msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." +msgid "" +"For any file, either or both of the *hash* and *size* fields may be left " +"empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself " +"have empty *hash* and *size*. For other files, leaving the information out " +"is discouraged, as it prevents verifying the integrity of the installed " +"project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:139 -msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." +msgid "" +"If the ``RECORD`` file is present, it must list all installed files of the " +"project, except ``.pyc`` files corresponding to ``.py`` files listed in " +"``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` " +"directory (including the ``RECORD`` file itself) must be listed. Directories " +"should not be listed." msgstr "" #: ../source/specifications/recording-installed-packages.rst:146 -msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." +msgid "" +"To completely uninstall a package, a tool needs to remove all files listed " +"in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding " +"to removed ``.py`` files, and any directories emptied by the uninstallation." msgstr "" #: ../source/specifications/recording-installed-packages.rst:151 @@ -8294,7 +12026,11 @@ msgid "Here is an example snippet of a possible ``RECORD`` file::" msgstr "" #: ../source/specifications/recording-installed-packages.rst:170 -msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" +msgid "" +"If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must " +"not atempt to uninstall or upgrade the package. (This does not apply to " +"tools that rely on other sources of information, such as system package " +"managers in Linux distros.)" msgstr "" #: ../source/specifications/recording-installed-packages.rst:177 @@ -8302,7 +12038,11 @@ msgid "The INSTALLER file" msgstr "" #: ../source/specifications/recording-installed-packages.rst:179 -msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." +msgid "" +"If present, ``INSTALLER`` is a single-line text file naming the tool used to " +"install the project. If the installer is executable from the command line, " +"``INSTALLER`` should contain the command name. Otherwise, it should contain " +"a printable ASCII string." msgstr "" #: ../source/specifications/recording-installed-packages.rst:185 @@ -8314,7 +12054,11 @@ msgid "Here are examples of two possible ``INSTALLER`` files::" msgstr "" #: ../source/specifications/recording-installed-packages.rst:195 -msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." +msgid "" +"This value should be used for informational purposes only. For example, if a " +"tool is asked to uninstall a project but finds no ``RECORD`` file, it may " +"suggest that the tool named in ``INSTALLER`` may be able to do the " +"uninstallation." msgstr "" #: ../source/specifications/recording-installed-packages.rst:201 @@ -8322,7 +12066,9 @@ msgid "The direct_url.json file" msgstr "" #: ../source/specifications/recording-installed-packages.rst:203 -msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgid "" +"This file MUST be created by installers when installing a distribution from " +"a requirement specifying a direct URL reference (including a VCS URL)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:209 @@ -8334,7 +12080,12 @@ msgid "Simple repository API" msgstr "" #: ../source/specifications/simple-repository-api.rst:8 -msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." +msgid "" +"The current interface for querying available package versions and retrieving " +"packages from an index server is defined in :pep:`503`, with the addition of " +"\"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` " +"and specifying the interface version provided by an index server in :pep:" +"`629`." msgstr "" #: ../source/specifications/source-distribution-format.rst:6 @@ -8342,11 +12093,22 @@ msgid "Source distribution format" msgstr "" #: ../source/specifications/source-distribution-format.rst:8 -msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." +msgid "" +"The current standard format of source distribution format is identified by " +"the presence of a :file:`pyproject.toml` file in the distribution archive. " +"The layout of such a distribution was originally specified in :pep:`517` and " +"is formally documented here." msgstr "" #: ../source/specifications/source-distribution-format.rst:13 -msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." +msgid "" +"There is also the legacy source distribution format, implicitly defined by " +"the behaviour of ``distutils`` module in the standard library, when " +"executing :command:`setup.py sdist`. This document does not attempt to " +"standardise this format, except to note that if a legacy source distribution " +"contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it " +"MUST follow the rules applicable to source distributions defined in the " +"metadata specification." msgstr "" #: ../source/specifications/source-distribution-format.rst:21 @@ -8358,11 +12120,18 @@ msgid "Source distribution file name" msgstr "" #: ../source/specifications/source-distribution-format.rst:26 -msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." +msgid "" +"The file name of a sdist is not currently standardised, although the *de " +"facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the " +"canonicalized form of the project name (see :pep:`503` for the " +"canonicalization rules) with ``-`` characters replaced with ``_``, and " +"``{version}`` is the project version." msgstr "" #: ../source/specifications/source-distribution-format.rst:31 -msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." +msgid "" +"The name and version components of the filename MUST match the values stored " +"in the metadata contained in the file." msgstr "" #: ../source/specifications/source-distribution-format.rst:35 @@ -8370,15 +12139,27 @@ msgid "Source distribution file format" msgstr "" #: ../source/specifications/source-distribution-format.rst:37 -msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." +msgid "" +"A ``.tar.gz`` source distribution (sdist) contains a single top-level " +"directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the " +"source files of the package. The name and version MUST match the metadata " +"stored in the file. This directory must also contain a :file:`pyproject." +"toml` in the format defined in :ref:`declaring-build-dependencies`, and a " +"``PKG-INFO`` file containing metadata in the format described in the :ref:" +"`core-metadata` specification. The metadata MUST conform to at least version " +"2.2 of the metadata specification." msgstr "" #: ../source/specifications/source-distribution-format.rst:45 -msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." +msgid "" +"No other content of a sdist is required or defined. Build systems can store " +"whatever information they need in the sdist to build the project." msgstr "" #: ../source/specifications/source-distribution-format.rst:48 -msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." +msgid "" +"The tarball should use the modern POSIX.1-2001 pax tar format, which " +"specifies UTF-8 based file names." msgstr "" #: ../source/specifications/version-specifiers.rst:6 @@ -8386,11 +12167,15 @@ msgid "Version specifiers" msgstr "" #: ../source/specifications/version-specifiers.rst:8 -msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." +msgid "" +"Version numbering requirements and the semantics for specifying comparisons " +"between versions are defined in :pep:`440`." msgstr "" #: ../source/specifications/version-specifiers.rst:11 -msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." +msgid "" +"The version specifiers section in this PEP supersedes the version specifiers " +"section in :pep:`345`." msgstr "" #: ../source/support.rst:3 @@ -8398,11 +12183,17 @@ msgid "How to Get Support" msgstr "" #: ../source/support.rst:5 -msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." +msgid "" +"For support related to a specific project, see the links on the :doc:" +"`Projects ` page." msgstr "" #: ../source/support.rst:8 -msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." +msgid "" +"For something more general, or when you're just not sure, please `open an " +"issue `_ on the " +"`packaging-problems `_ " +"repository on GitHub." msgstr "" #: ../source/tutorials/creating-documentation.rst:5 @@ -8410,7 +12201,9 @@ msgid "Creating Documentation" msgstr "" #: ../source/tutorials/creating-documentation.rst:7 -msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." +msgid "" +"This section covers the basics of how to create documentation using " +"`Sphinx`_ and host the documentation for free in `Read The Docs`_." msgstr "" #: ../source/tutorials/creating-documentation.rst:13 @@ -8422,7 +12215,8 @@ msgid "Use ``pip`` to install Sphinx:" msgstr "" #: ../source/tutorials/creating-documentation.rst:28 -msgid "For other installation methods, see this `installation guide`_ by Sphinx." +msgid "" +"For other installation methods, see this `installation guide`_ by Sphinx." msgstr "" #: ../source/tutorials/creating-documentation.rst:33 @@ -8430,7 +12224,8 @@ msgid "Getting Started With Sphinx" msgstr "" #: ../source/tutorials/creating-documentation.rst:35 -msgid "Create a ``docs`` directory inside your project to hold your documentation:" +msgid "" +"Create a ``docs`` directory inside your project to hold your documentation:" msgstr "" #: ../source/tutorials/creating-documentation.rst:42 @@ -8438,15 +12233,21 @@ msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" msgstr "" #: ../source/tutorials/creating-documentation.rst:49 -msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." +msgid "" +"This sets up a source directory, walks you through some basic " +"configurations, and creates an ``index.rst`` file as well as a ``conf.py`` " +"file." msgstr "" #: ../source/tutorials/creating-documentation.rst:51 -msgid "You can add some information about your project in ``index.rst``, then build them:" +msgid "" +"You can add some information about your project in ``index.rst``, then build " +"them:" msgstr "" #: ../source/tutorials/creating-documentation.rst:57 -msgid "For more details on the build process, see this `guide`_ by Read The Docs." +msgid "" +"For more details on the build process, see this `guide`_ by Read The Docs." msgstr "" #: ../source/tutorials/creating-documentation.rst:62 @@ -8454,11 +12255,16 @@ msgid "Other Sources" msgstr "" #: ../source/tutorials/creating-documentation.rst:64 -msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." +msgid "" +"For a more detailed guide on how to use Sphinx and reStructuredText, please " +"see this `documentation tutorial`_ on Hitchhiker's Guide to Python." msgstr "" #: ../source/tutorials/index.rst:4 -msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." +msgid "" +"**Tutorials** are opinionated step-by-step guides to help you get familiar " +"with packaging concepts. For more detailed information on specific packaging " +"topics, see :doc:`/guides/index`." msgstr "" #: ../source/tutorials/installing-packages.rst:5 @@ -8466,11 +12272,22 @@ msgid "Installing Packages" msgstr "" #: ../source/tutorials/installing-packages.rst:7 -msgid "This section covers the basics of how to install Python :term:`packages `." +msgid "" +"This section covers the basics of how to install Python :term:`packages " +"`." msgstr "" #: ../source/tutorials/installing-packages.rst:10 -msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." +msgid "" +"It's important to note that the term \"package\" in this context is being " +"used to describe a bundle of software to be installed (i.e. as a synonym for " +"a :term:`distribution `). It does not to refer to the " +"kind of :term:`package ` that you import in your Python " +"source code (i.e. a container of modules). It is common in the Python " +"community to refer to a :term:`distribution ` using " +"the term \"package\". Using the term \"distribution\" is often not " +"preferred, because it can easily be confused with a Linux distribution, or " +"another larger software distribution like Python itself." msgstr "" #: ../source/tutorials/installing-packages.rst:28 @@ -8478,7 +12295,9 @@ msgid "Requirements for Installing Packages" msgstr "" #: ../source/tutorials/installing-packages.rst:30 -msgid "This section describes the steps to follow before installing other Python packages." +msgid "" +"This section describes the steps to follow before installing other Python " +"packages." msgstr "" #: ../source/tutorials/installing-packages.rst:35 @@ -8486,11 +12305,16 @@ msgid "Ensure you can run Python from the command line" msgstr "" #: ../source/tutorials/installing-packages.rst:37 -msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" +msgid "" +"Before you go any further, make sure you have Python and that the expected " +"version is available from your command line. You can check this by running:" msgstr "" #: ../source/tutorials/installing-packages.rst:53 -msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." +msgid "" +"You should get some output like ``Python 3.6.3``. If you do not have Python, " +"please install the latest 3.x version from `python.org`_ or refer to the " +"`Installing Python`_ section of the Hitchhiker's Guide to Python." msgstr "" #: ../source/tutorials/installing-packages.rst:57 @@ -8498,19 +12322,37 @@ msgid "If you're a newcomer and you get an error like this:" msgstr "" #: ../source/tutorials/installing-packages.rst:66 -msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." +msgid "" +"It's because this command and other suggested commands in this tutorial are " +"intended to be run in a *shell* (also called a *terminal* or *console*). See " +"the Python for Beginners `getting started tutorial`_ for an introduction to " +"using your operating system's shell and interacting with Python." msgstr "" #: ../source/tutorials/installing-packages.rst:72 -msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" +msgid "" +"If you're using an enhanced shell like IPython or the Jupyter notebook, you " +"can run system commands like those in this tutorial by prefacing them with a " +"``!`` character:" msgstr "" #: ../source/tutorials/installing-packages.rst:82 -msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." +msgid "" +"It's recommended to write ``{sys.executable}`` rather than plain ``python`` " +"in order to ensure that commands are run in the Python installation matching " +"the currently running notebook (which may not be the same Python " +"installation that the ``python`` command refers to)." msgstr "" #: ../source/tutorials/installing-packages.rst:87 -msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." +msgid "" +"Due to the way most Linux distributions are handling the Python 3 migration, " +"Linux users using the system Python without creating a virtual environment " +"first should replace the ``python`` command in this tutorial with " +"``python3`` and the ``python -m pip`` command with ``python3 -m pip --" +"user``. Do *not* run any of the commands in this tutorial with ``sudo``: if " +"you get a permissions error, come back to the section on creating virtual " +"environments, set one up, and then continue with the tutorial as written." msgstr "" #: ../source/tutorials/installing-packages.rst:99 @@ -8518,15 +12360,23 @@ msgid "Ensure you can run pip from the command line" msgstr "" #: ../source/tutorials/installing-packages.rst:101 -msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" +msgid "" +"Additionally, you'll need to make sure you have :ref:`pip` available. You " +"can check this by running:" msgstr "" #: ../source/tutorials/installing-packages.rst:116 -msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." +msgid "" +"If you installed Python from source, with an installer from `python.org`_, " +"or via `Homebrew`_ you should already have pip. If you're on Linux and " +"installed using your OS package manager, you may have to install pip " +"separately, see :doc:`/guides/installing-using-linux-tools`." msgstr "" #: ../source/tutorials/installing-packages.rst:124 -msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" +msgid "" +"If ``pip`` isn't already installed, then first try to bootstrap it from the " +"standard library:" msgstr "" #: ../source/tutorials/installing-packages.rst:139 @@ -8534,15 +12384,24 @@ msgid "If that still doesn't allow you to run ``python -m pip``:" msgstr "" #: ../source/tutorials/installing-packages.rst:141 -msgid "Securely Download `get-pip.py `_ [1]_" +msgid "" +"Securely Download `get-pip.py `_ [1]_" msgstr "" #: ../source/tutorials/installing-packages.rst:144 -msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." +msgid "" +"Run ``python get-pip.py``. [2]_ This will install or upgrade pip. " +"Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're " +"not installed already." msgstr "" #: ../source/tutorials/installing-packages.rst:150 -msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." +msgid "" +"Be cautious if you're using a Python install that's managed by your " +"operating system or another package manager. get-pip.py does not coordinate " +"with those tools, and may leave your system in an inconsistent state. You " +"can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/" +"local`` which is designed for locally-installed software." msgstr "" #: ../source/tutorials/installing-packages.rst:159 @@ -8550,7 +12409,10 @@ msgid "Ensure pip, setuptools, and wheel are up to date" msgstr "" #: ../source/tutorials/installing-packages.rst:161 -msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" +msgid "" +"While ``pip`` alone is sufficient to install from pre-built binary archives, " +"up to date copies of the ``setuptools`` and ``wheel`` projects are useful to " +"ensure you can also install from source archives::" msgstr "" #: ../source/tutorials/installing-packages.rst:169 @@ -8558,11 +12420,17 @@ msgid "Optionally, create a virtual environment" msgstr "" #: ../source/tutorials/installing-packages.rst:171 -msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" +msgid "" +"See :ref:`section below ` for " +"details, but here's the basic `venv`_ [3]_ command to use on a typical Linux " +"system:" msgstr "" #: ../source/tutorials/installing-packages.rst:188 -msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." +msgid "" +"This will create a new virtual environment in the ``tutorial_env`` " +"subdirectory, and configure the current shell to use it as the default " +"``python`` environment." msgstr "" #: ../source/tutorials/installing-packages.rst:195 @@ -8570,35 +12438,62 @@ msgid "Creating Virtual Environments" msgstr "" #: ../source/tutorials/installing-packages.rst:197 -msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." +msgid "" +"Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular " +"application, rather than being installed globally. If you are looking to " +"safely install global command line tools, see :doc:`/guides/installing-stand-" +"alone-command-line-tools`." msgstr "" #: ../source/tutorials/installing-packages.rst:203 -msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." +msgid "" +"Imagine you have an application that needs version 1 of LibFoo, but another " +"application requires version 2. How can you use both these applications? If " +"you install everything into /usr/lib/python3.6/site-packages (or whatever " +"your platform’s standard location is), it’s easy to end up in a situation " +"where you unintentionally upgrade an application that shouldn’t be upgraded." msgstr "" #: ../source/tutorials/installing-packages.rst:209 -msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." +msgid "" +"Or more generally, what if you want to install an application and leave it " +"be? If an application works, any change in its libraries or the versions of " +"those libraries can break the application." msgstr "" #: ../source/tutorials/installing-packages.rst:213 -msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." +msgid "" +"Also, what if you can’t install :term:`packages ` into " +"the global site-packages directory? For instance, on a shared host." msgstr "" #: ../source/tutorials/installing-packages.rst:216 -msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." +msgid "" +"In all these cases, virtual environments can help you. They have their own " +"installation directories and they don’t share libraries with other virtual " +"environments." msgstr "" #: ../source/tutorials/installing-packages.rst:220 -msgid "Currently, there are two common tools for creating Python virtual environments:" +msgid "" +"Currently, there are two common tools for creating Python virtual " +"environments:" msgstr "" #: ../source/tutorials/installing-packages.rst:222 -msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." +msgid "" +"`venv`_ is available by default in Python 3.3 and later, and installs :ref:" +"`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 " +"and later." msgstr "" #: ../source/tutorials/installing-packages.rst:225 -msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." +msgid "" +":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ " +"and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are " +"always installed into created virtual environments by default (regardless of " +"Python version)." msgstr "" #: ../source/tutorials/installing-packages.rst:230 @@ -8614,19 +12509,31 @@ msgid "Using :ref:`virtualenv`:" msgstr "" #: ../source/tutorials/installing-packages.rst:264 -msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." +msgid "" +"For more information, see the `venv`_ docs or the `virtualenv `_ docs." msgstr "" #: ../source/tutorials/installing-packages.rst:266 -msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." +msgid "" +"The use of :command:`source` under Unix shells ensures that the virtual " +"environment's variables are set within the current shell, and not in a " +"subprocess (which then disappears, having no useful effect)." msgstr "" #: ../source/tutorials/installing-packages.rst:271 -msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" +msgid "" +"In both of the above cases, Windows users should _not_ use the :command:" +"`source` command, but should rather run the :command:`activate` script " +"directly from the command shell like so:" msgstr "" #: ../source/tutorials/installing-packages.rst:281 -msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." +msgid "" +"Managing multiple virtual environments directly can become tedious, so the :" +"ref:`dependency management tutorial ` introduces a " +"higher level tool, :ref:`Pipenv`, that automatically manages a separate " +"virtual environment for each project and application that you work on." msgstr "" #: ../source/tutorials/installing-packages.rst:288 @@ -8634,7 +12541,11 @@ msgid "Use pip for Installing" msgstr "" #: ../source/tutorials/installing-packages.rst:290 -msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." +msgid "" +":ref:`pip` is the recommended installer. Below, we'll cover the most common " +"usage scenarios. For more detail, see the `pip docs `_, " +"which includes a complete `Reference Guide `_." msgstr "" #: ../source/tutorials/installing-packages.rst:297 @@ -8642,7 +12553,14 @@ msgid "Installing from PyPI" msgstr "" #: ../source/tutorials/installing-packages.rst:299 -msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." +msgid "" +"The most common usage of :ref:`pip` is to install from the :term:`Python " +"Package Index ` using a :term:`requirement " +"specifier `. Generally speaking, a requirement " +"specifier is composed of a project name followed by an optional :term:" +"`version specifier `. :pep:`440` contains a :pep:`full " +"specification <440#version-specifiers>` of the currently supported " +"specifiers. Below are some examples." msgstr "" #: ../source/tutorials/installing-packages.rst:307 @@ -8658,11 +12576,15 @@ msgid "To install greater than or equal to one version and less than another:" msgstr "" #: ../source/tutorials/installing-packages.rst:350 -msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" +msgid "" +"To install a version that's :pep:`\"compatible\" <440#compatible-release>` " +"with a certain version: [4]_" msgstr "" #: ../source/tutorials/installing-packages.rst:365 -msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." +msgid "" +"In this case, this means to install any version \"==1.4.*\" version that's " +"also \">=1.4.2\"." msgstr "" #: ../source/tutorials/installing-packages.rst:370 @@ -8670,15 +12592,27 @@ msgid "Source Distributions vs Wheels" msgstr "" #: ../source/tutorials/installing-packages.rst:372 -msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." +msgid "" +":ref:`pip` can install from either :term:`Source Distributions (sdist) " +"` or :term:`Wheels `, but if both " +"are present on PyPI, pip will prefer a compatible :term:`wheel `. You " +"can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." msgstr "" #: ../source/tutorials/installing-packages.rst:378 -msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." +msgid "" +":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source " +"Distributions (sdist) `, especially when " +"a project contains compiled extensions." msgstr "" #: ../source/tutorials/installing-packages.rst:383 -msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." +msgid "" +"If :ref:`pip` does not find a wheel to install, it will locally build a " +"wheel and cache it for future installs, instead of rebuilding the source " +"distribution in the future." msgstr "" #: ../source/tutorials/installing-packages.rst:391 @@ -8690,31 +12624,58 @@ msgid "Installing to the User Site" msgstr "" #: ../source/tutorials/installing-packages.rst:410 -msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" +msgid "" +"To install :term:`packages ` that are isolated to the " +"current user, use the ``--user`` flag:" msgstr "" #: ../source/tutorials/installing-packages.rst:425 -msgid "For more information see the `User Installs `_ section from the pip docs." +msgid "" +"For more information see the `User Installs `_ section from the pip docs." msgstr "" #: ../source/tutorials/installing-packages.rst:429 -msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." +msgid "" +"Note that the ``--user`` flag has no effect when inside a virtual " +"environment - all installation commands will affect the virtual environment." msgstr "" #: ../source/tutorials/installing-packages.rst:432 -msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" +msgid "" +"If ``SomeProject`` defines any command-line scripts or console entry points, " +"``--user`` will cause them to be installed inside the `user base`_'s binary " +"directory, which may or may not already be present in your shell's :envvar:" +"`PATH`. (Starting in version 10, pip displays a warning when installing any " +"scripts to a directory outside :envvar:`PATH`.) If the scripts are not " +"available in your shell after installation, you'll need to add the directory " +"to your :envvar:`PATH`:" msgstr "" #: ../source/tutorials/installing-packages.rst:440 -msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." +msgid "" +"On Linux and macOS you can find the user base binary directory by running " +"``python -m site --user-base`` and adding ``bin`` to the end. For example, " +"this will typically print ``~/.local`` (with ``~`` expanded to the absolute " +"path to your home directory) so you'll need to add ``~/.local/bin`` to your " +"``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." msgstr "" #: ../source/tutorials/installing-packages.rst:446 -msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." +msgid "" +"On Windows you can find the user base binary directory by running ``py -m " +"site --user-site`` and replacing ``site-packages`` with ``Scripts``. For " +"example, this could return ``C:\\Users\\Username\\AppData\\Roaming" +"\\Python36\\site-packages`` so you would need to set your ``PATH`` to " +"include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You " +"can set your user ``PATH`` permanently in the `Control Panel`_. You may need " +"to log out for the ``PATH`` changes to take effect." msgstr "" #: ../source/tutorials/installing-packages.rst:462 -msgid "Install a list of requirements specified in a :ref:`Requirements File `." +msgid "" +"Install a list of requirements specified in a :ref:`Requirements File `." msgstr "" #: ../source/tutorials/installing-packages.rst:478 @@ -8722,7 +12683,9 @@ msgid "Installing from VCS" msgstr "" #: ../source/tutorials/installing-packages.rst:480 -msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." +msgid "" +"Install a project from VCS in \"editable\" mode. For a full breakdown of " +"the syntax, see pip's section on :ref:`VCS Support `." msgstr "" #: ../source/tutorials/installing-packages.rst:502 @@ -8734,7 +12697,9 @@ msgid "Install from an alternate index" msgstr "" #: ../source/tutorials/installing-packages.rst:518 -msgid "Search an additional index during install, in addition to :term:`PyPI `" +msgid "" +"Search an additional index during install, in addition to :term:`PyPI " +"`" msgstr "" #: ../source/tutorials/installing-packages.rst:534 @@ -8742,7 +12707,11 @@ msgid "Installing from a local src tree" msgstr "" #: ../source/tutorials/installing-packages.rst:537 -msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." +msgid "" +"Installing from local src in `Development Mode `_, i.e. in such a " +"way that the project appears to be installed, but yet is still editable from " +"the src tree." msgstr "" #: ../source/tutorials/installing-packages.rst:554 @@ -8754,7 +12723,9 @@ msgid "Install a particular source archive file." msgstr "" #: ../source/tutorials/installing-packages.rst:585 -msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" +msgid "" +"Install from a local directory containing archives (and don't check :term:" +"`PyPI `)" msgstr "" #: ../source/tutorials/installing-packages.rst:605 @@ -8762,7 +12733,11 @@ msgid "Installing from other sources" msgstr "" #: ../source/tutorials/installing-packages.rst:607 -msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." +msgid "" +"To install from other data sources (for example Amazon S3 storage) you can " +"create a helper application that presents the data in a :pep:`503` compliant " +"index format, and use the ``--extra-index-url`` flag to direct pip to use " +"that index." msgstr "" #: ../source/tutorials/installing-packages.rst:619 @@ -8770,7 +12745,9 @@ msgid "Installing Prereleases" msgstr "" #: ../source/tutorials/installing-packages.rst:621 -msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." +msgid "" +"Find pre-release and development versions, in addition to stable versions. " +"By default, pip only finds stable versions." msgstr "" #: ../source/tutorials/installing-packages.rst:637 @@ -8782,15 +12759,23 @@ msgid "Install `setuptools extras`_." msgstr "" #: ../source/tutorials/installing-packages.rst:659 -msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." +msgid "" +"\"Secure\" in this context means using a modern browser or a tool like :" +"command:`curl` that verifies SSL certificates when downloading from https " +"URLs." msgstr "" #: ../source/tutorials/installing-packages.rst:668 -msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." +msgid "" +"Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:" +"`virtualenv`) will create virtualenv environments with ``pip`` pre-" +"installed, thereby making it an equal alternative to :ref:`virtualenv`." msgstr "" #: ../source/tutorials/installing-packages.rst:673 -msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" +msgid "" +"The compatible release specifier was accepted in :pep:`440` and support was " +"released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" msgstr "" #: ../source/tutorials/managing-dependencies.rst:4 @@ -8798,23 +12783,42 @@ msgid "Managing Application Dependencies" msgstr "" #: ../source/tutorials/managing-dependencies.rst:6 -msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." +msgid "" +"The :ref:`package installation tutorial ` covered the " +"basics of getting set up to install and update Python packages." msgstr "" #: ../source/tutorials/managing-dependencies.rst:9 -msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." +msgid "" +"However, running these commands interactively can get tedious even for your " +"own personal projects, and things get even more difficult when trying to set " +"up development environments automatically for projects with multiple " +"contributors." msgstr "" #: ../source/tutorials/managing-dependencies.rst:13 -msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." +msgid "" +"This tutorial walks you through the use of :ref:`Pipenv` to manage " +"dependencies for an application. It will show you how to install and use the " +"necessary tools and make strong recommendations on best practices." msgstr "" #: ../source/tutorials/managing-dependencies.rst:17 -msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." +msgid "" +"Keep in mind that Python is used for a great many different purposes, and " +"precisely how you want to manage your dependencies may change based on how " +"you decide to publish your software. The guidance presented here is most " +"directly applicable to the development and deployment of network services " +"(including web applications), but is also very well suited to managing " +"development and testing environments for any kind of project." msgstr "" #: ../source/tutorials/managing-dependencies.rst:24 -msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." +msgid "" +"Developers of Python libraries, or of applications that support distribution " +"as Python libraries, should also consider the `poetry `_ project as an alternative dependency management " +"solution." msgstr "" #: ../source/tutorials/managing-dependencies.rst:30 @@ -8822,7 +12826,12 @@ msgid "Installing Pipenv" msgstr "Instali Pipenv" #: ../source/tutorials/managing-dependencies.rst:32 -msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." +msgid "" +":ref:`Pipenv` is a dependency manager for Python projects. If you're " +"familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit " +"to those tools. While :ref:`pip` alone is often sufficient for personal use, " +"Pipenv is recommended for collaborative projects as it's a higher-level tool " +"that simplifies dependency management for common use cases." msgstr "" #: ../source/tutorials/managing-dependencies.rst:38 @@ -8830,7 +12839,11 @@ msgid "Use ``pip`` to install Pipenv:" msgstr "Uzi ``pip`` por instali Pipenv:" #: ../source/tutorials/managing-dependencies.rst:54 -msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." +msgid "" +"This does a `user installation`_ to prevent breaking any system-wide " +"packages. If ``pipenv`` isn't available in your shell after installation, " +"you'll need to add the `user base`_'s binary directory to your ``PATH``. " +"See :ref:`Installing to the User Site` for more information." msgstr "" #: ../source/tutorials/managing-dependencies.rst:65 @@ -8838,11 +12851,19 @@ msgid "Installing packages for your project" msgstr "" #: ../source/tutorials/managing-dependencies.rst:67 -msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" +msgid "" +"Pipenv manages dependencies on a per-project basis. To install packages, " +"change into your project's directory (or just an empty directory for this " +"tutorial) and run:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:76 -msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" +msgid "" +"Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you " +"in your project's directory. The :ref:`Pipfile` is used to track which " +"dependencies your project needs in case you need to re-install them, such as " +"when you share your project with others. You should get output similar to " +"this (although the exact paths shown will vary):" msgstr "" #: ../source/tutorials/managing-dependencies.rst:112 @@ -8850,7 +12871,9 @@ msgid "Using installed packages" msgstr "Uzi instalitajn pakojn" #: ../source/tutorials/managing-dependencies.rst:114 -msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" +msgid "" +"Now that Requests is installed you can create a simple :file:`main.py` file " +"to use it:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:125 @@ -8862,7 +12885,10 @@ msgid "You should get output similar to this:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:137 -msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." +msgid "" +"Using ``pipenv run`` ensures that your installed packages are available to " +"your script. It's also possible to spawn a new shell that ensures all " +"commands have access to your installed packages with ``pipenv shell``." msgstr "" #: ../source/tutorials/managing-dependencies.rst:143 @@ -8871,15 +12897,24 @@ msgid "Next steps" msgstr "Sekvaj paŝoj" #: ../source/tutorials/managing-dependencies.rst:145 -msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" +msgid "" +"Congratulations, you now know how to effectively manage dependencies and " +"development environments on a collaborative Python project! ✨ 🍰 ✨" msgstr "" #: ../source/tutorials/managing-dependencies.rst:148 -msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." +msgid "" +"If you're interested in creating and distributing your own Python packages, " +"see the :ref:`tutorial on packaging and distributing packages `." msgstr "" #: ../source/tutorials/managing-dependencies.rst:151 -msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." +msgid "" +"Note that when your application includes definitions of Python source " +"packages, they (and their dependencies) can be added to your ``pipenv`` " +"environment with ``pipenv install -e `` " +"(e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." msgstr "" #: ../source/tutorials/managing-dependencies.rst:160 @@ -8887,23 +12922,43 @@ msgid "Other Tools for Application Dependency Management" msgstr "" #: ../source/tutorials/managing-dependencies.rst:162 -msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" +msgid "" +"If you find this particular approach to managing application dependencies " +"isn't working well for you or your use case, you may want to explore these " +"other tools and techniques to see if one of them is a better fit:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:166 -msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." +msgid "" +"`poetry `__ for a tool comparable " +"in scope to ``pipenv`` that focuses more directly on use cases where the " +"repository being managed is structured as a Python project with a valid " +"``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making " +"the assumption that the application being worked on that's depending on " +"components from PyPI will itself support distribution as a ``pip``-" +"installable Python package)." msgstr "" #: ../source/tutorials/managing-dependencies.rst:172 -msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" +msgid "" +"`hatch `_ for opinionated coverage of even " +"more steps in the project management workflow (such as incrementing " +"versions, tagging releases, and creating new skeleton projects from project " +"templates)" msgstr "" #: ../source/tutorials/managing-dependencies.rst:175 -msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" +msgid "" +"`pip-tools `_ to build your own " +"custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" msgstr "" #: ../source/tutorials/managing-dependencies.rst:177 -msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." +msgid "" +"`micropipenv `_ is a " +"lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry " +"lock files or converting them to pip-tools compatible output. Designed for " +"containerized Python applications but not limited to them." msgstr "" #: ../source/tutorials/packaging-projects.rst:2 @@ -8911,15 +12966,24 @@ msgid "Packaging Python Projects" msgstr "Paki projektojn de Python" #: ../source/tutorials/packaging-projects.rst:4 -msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." +msgid "" +"This tutorial walks you through how to package a simple Python project. It " +"will show you how to add the necessary files and structure to create the " +"package, how to build the package, and how to upload it to the Python " +"Package Index." msgstr "" #: ../source/tutorials/packaging-projects.rst:10 -msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" +msgid "" +"If you have trouble running the commands in this tutoral, please copy the " +"command and its output, then `open an issue`_ on the `packaging-problems`_ " +"repository on GitHub. We'll do our best to help you!" msgstr "" #: ../source/tutorials/packaging-projects.rst:18 -msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" +msgid "" +"Some of the commands require a newer version of :ref:`pip`, so start by " +"making sure you have the latest version installed:" msgstr "" #: ../source/tutorials/packaging-projects.rst:35 @@ -8927,7 +12991,10 @@ msgid "A simple project" msgstr "Simpla projekto" #: ../source/tutorials/packaging-projects.rst:37 -msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." +msgid "" +"This tutorial uses a simple project named ``example_package``. We recommend " +"following this tutorial as-is using this project, before packaging your own " +"project." msgstr "" #: ../source/tutorials/packaging-projects.rst:41 @@ -8935,19 +13002,29 @@ msgid "Create the following file structure locally:" msgstr "" #: ../source/tutorials/packaging-projects.rst:51 -msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." +msgid "" +":file:`__init__.py` is required to import the directory as a package, and " +"should be empty." msgstr "" #: ../source/tutorials/packaging-projects.rst:54 -msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" +msgid "" +":file:`example.py` is an example of a module within the package that could " +"contain the logic (functions, classes, constants, etc.) of your package. " +"Open that file and enter the following content:" msgstr "" #: ../source/tutorials/packaging-projects.rst:63 -msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." +msgid "" +"If you are unfamiliar with Python's :term:`modules ` and :term:" +"`import packages `, take a few minutes to read over the " +"`Python documentation for packages and modules`_." msgstr "" #: ../source/tutorials/packaging-projects.rst:67 -msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." +msgid "" +"Once you create this structure, you'll want to run all of the commands in " +"this tutorial within the ``packaging_tutorial`` directory." msgstr "" #: ../source/tutorials/packaging-projects.rst:75 @@ -8955,7 +13032,9 @@ msgid "Creating the package files" msgstr "Krei dosierojn de la pakaĵo" #: ../source/tutorials/packaging-projects.rst:77 -msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" +msgid "" +"You will now add files that are used to prepare the project for " +"distribution. When you're done, the project structure will look like this:" msgstr "" #: ../source/tutorials/packaging-projects.rst:95 @@ -8971,15 +13050,26 @@ msgid "Creating pyproject.toml" msgstr "Krei la dosieron pyproject.toml" #: ../source/tutorials/packaging-projects.rst:103 -msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" +msgid "" +":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) " +"what is required to build your project. This tutorial uses :ref:" +"`setuptools`, so open :file:`pyproject.toml` and enter the following content:" msgstr "" #: ../source/tutorials/packaging-projects.rst:117 -msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." +msgid "" +"``build-system.requires`` gives a list of packages that are needed to build " +"your package. Listing something here will *only* make it available during " +"the build, not after it is installed." msgstr "" #: ../source/tutorials/packaging-projects.rst:121 -msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." +msgid "" +"``build-system.build-backend`` is the name of Python object that will be " +"used to perform the build. If you were to use a different build system, such " +"as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration " +"details would be completely different than the :ref:`setuptools` " +"configuration described below." msgstr "" #: ../source/tutorials/packaging-projects.rst:127 @@ -8995,41 +13085,74 @@ msgid "There are two types of metadata: static and dynamic." msgstr "" #: ../source/tutorials/packaging-projects.rst:135 -msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." +msgid "" +"Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. " +"This is simpler, easier to read, and avoids many common errors, like " +"encoding errors." msgstr "" #: ../source/tutorials/packaging-projects.rst:137 -msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." +msgid "" +"Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items " +"that are dynamic or determined at install-time, as well as extension modules " +"or extensions to setuptools, need to go into :file:`setup.py`." msgstr "" #: ../source/tutorials/packaging-projects.rst:141 -msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." +msgid "" +"Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:" +"file:`setup.py`) should be used only as an escape hatch when absolutely " +"necessary. :file:`setup.py` used to be required, but can be omitted with " +"newer versions of setuptools and pip." msgstr "" #: ../source/tutorials/packaging-projects.rst:148 -msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." +msgid "" +":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells " +"setuptools about your package (such as the name and version) as well as " +"which code files to include. Eventually much of this configuration may be " +"able to move to :file:`pyproject.toml`." msgstr "" #: ../source/tutorials/packaging-projects.rst:153 -msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgid "" +"Open :file:`setup.cfg` and enter the following content. Change the ``name`` " +"to include your username; this ensures that you have a unique package name " +"and that your package doesn't conflict with packages uploaded by other " +"people following this tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:185 -msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" +msgid "" +"There are a `variety of metadata and options `_ supported here. This is " +"in :doc:`configparser ` format; do not place " +"quotes around values. This example package uses a relatively minimal set of " +"``metadata``:" msgstr "" #: ../source/tutorials/packaging-projects.rst:191 #: ../source/tutorials/packaging-projects.rst:286 -msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." +msgid "" +"``name`` is the *distribution name* of your package. This can be any name as " +"long as it only contains letters, numbers, ``_`` , and ``-``. It also must " +"not already be taken on pypi.org. **Be sure to update this with your " +"username,** as this ensures you won't try to upload a package with the same " +"name as one which already exists." msgstr "" #: ../source/tutorials/packaging-projects.rst:196 -msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." +msgid "" +"``version`` is the package version. See :pep:`440` for more details on " +"versions. You can use ``file:`` or ``attr:`` directives to read from a file " +"or package attribute." msgstr "" #: ../source/tutorials/packaging-projects.rst:199 #: ../source/tutorials/packaging-projects.rst:293 -msgid "``author`` and ``author_email`` are used to identify the author of the package." +msgid "" +"``author`` and ``author_email`` are used to identify the author of the " +"package." msgstr "" #: ../source/tutorials/packaging-projects.rst:201 @@ -9038,27 +13161,45 @@ msgid "``description`` is a short, one-sentence summary of the package." msgstr "" #: ../source/tutorials/packaging-projects.rst:202 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." +msgid "" +"``long_description`` is a detailed description of the package. This is shown " +"on the package detail page on the Python Package Index. In this case, the " +"long description is loaded from :file:`README.md` (which is a common " +"pattern) using the ``file:`` directive." msgstr "" #: ../source/tutorials/packaging-projects.rst:206 #: ../source/tutorials/packaging-projects.rst:300 -msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." +msgid "" +"``long_description_content_type`` tells the index what type of markup is " +"used for the long description. In this case, it's Markdown." msgstr "" #: ../source/tutorials/packaging-projects.rst:208 #: ../source/tutorials/packaging-projects.rst:302 -msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." +msgid "" +"``url`` is the URL for the homepage of the project. For many projects, this " +"will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting " +"service." msgstr "" #: ../source/tutorials/packaging-projects.rst:211 #: ../source/tutorials/packaging-projects.rst:305 -msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." +msgid "" +"``project_urls`` lets you list any number of extra links to show on PyPI. " +"Generally this could be to documentation, issue trackers, etc." msgstr "" #: ../source/tutorials/packaging-projects.rst:213 #: ../source/tutorials/packaging-projects.rst:307 -msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." +msgid "" +"``classifiers`` gives the index and :ref:`pip` some additional metadata " +"about your package. In this case, the package is only compatible with Python " +"3, is licensed under the MIT license, and is OS-independent. You should " +"always include at least which version(s) of Python your package works on, " +"which license your package is available under, and which operating systems " +"your package will work on. For a complete list of classifiers, see https://" +"pypi.org/classifiers/." msgstr "" #: ../source/tutorials/packaging-projects.rst:221 @@ -9066,52 +13207,96 @@ msgid "In the ``options`` category, we have controls for setuptools itself:" msgstr "" #: ../source/tutorials/packaging-projects.rst:223 -msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgid "" +"``package_dir`` is a mapping of package names and directories. An empty " +"package name represents the \"root package\" --- the directory in the " +"project that contains all Python source files for the package --- so in this " +"case the ``src`` directory is designated the root package." msgstr "" #: ../source/tutorials/packaging-projects.rst:227 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgid "" +"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " +"`. Instead of listing each package manually, we can " +"use the ``find:`` directive to automatically discover all packages and " +"subpackages and ``options.packages.find`` to specify the ``package_dir`` to " +"use. In this case, the list of packages will be ``example_package`` as " +"that's the only package present." msgstr "" #: ../source/tutorials/packaging-projects.rst:234 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." +msgid "" +"``python_requires`` gives the versions of Python supported by your project. " +"Installers like :ref:`pip` will look back through older versions of packages " +"until it finds one that has a matching Python version." msgstr "" #: ../source/tutorials/packaging-projects.rst:238 #: ../source/tutorials/packaging-projects.rst:329 -msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." +msgid "" +"There are many more than the ones mentioned here. See :doc:`/guides/" +"distributing-packages-using-setuptools` for more details." msgstr "" #: ../source/tutorials/packaging-projects.rst:244 -msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." +msgid "" +":file:`setup.py` is the build script for :ref:`setuptools`. It tells " +"setuptools about your package (such as the name and version) as well as " +"which code files to include." msgstr "" #: ../source/tutorials/packaging-projects.rst:248 -msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgid "" +"Open :file:`setup.py` and enter the following content. Change the ``name`` " +"to include your username; this ensures that you have a unique package name " +"and that your package doesn't conflict with packages uploaded by other " +"people following this tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:283 -msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" +msgid "" +":func:`setup` takes several arguments. This example package uses a " +"relatively minimal set:" msgstr "" #: ../source/tutorials/packaging-projects.rst:291 -msgid "``version`` is the package version. See :pep:`440` for more details on versions." +msgid "" +"``version`` is the package version. See :pep:`440` for more details on " +"versions." msgstr "" #: ../source/tutorials/packaging-projects.rst:296 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." +msgid "" +"``long_description`` is a detailed description of the package. This is shown " +"on the package detail page on the Python Package Index. In this case, the " +"long description is loaded from :file:`README.md`, which is a common pattern." msgstr "" #: ../source/tutorials/packaging-projects.rst:314 -msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgid "" +"``package_dir`` is a dictionary with package names for keys and directories " +"for values. An empty package name represents the \"root package\" --- the " +"directory in the project that contains all Python source files for the " +"package --- so in this case the ``src`` directory is designated the root " +"package." msgstr "" #: ../source/tutorials/packaging-projects.rst:319 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgid "" +"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " +"`. Instead of listing each package manually, we can " +"use :func:`find_packages` to automatically discover all packages and " +"subpackages under ``package_dir``. In this case, the list of packages will " +"be ``example_package`` as that's the only package present." msgstr "" #: ../source/tutorials/packaging-projects.rst:325 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." +msgid "" +"``python_requires`` gives the versions of Python supported by your project. " +"Installers like :ref:`pip` will look back though older versions of packages " +"until it finds one that has a matching Python version." msgstr "" #: ../source/tutorials/packaging-projects.rst:333 @@ -9119,11 +13304,17 @@ msgid "Creating README.md" msgstr "Krei la dosieron README.md" #: ../source/tutorials/packaging-projects.rst:335 -msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." +msgid "" +"Open :file:`README.md` and enter the following content. You can customize " +"this if you'd like." msgstr "" #: ../source/tutorials/packaging-projects.rst:347 -msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." +msgid "" +"Because our configuration loads :file:`README.md` to provide a " +"``long_description``, :file:`README.md` must be included along with your " +"code when you :ref:`generate a source distribution `. " +"Newer versions of :ref:`setuptools` will do this automatically." msgstr "" #: ../source/tutorials/packaging-projects.rst:354 @@ -9131,7 +13322,12 @@ msgid "Creating a LICENSE" msgstr "Krei la dosieron LICENSE" #: ../source/tutorials/packaging-projects.rst:356 -msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" +msgid "" +"It's important for every package uploaded to the Python Package Index to " +"include a license. This tells users who install your package the terms under " +"which they can use your package. For help picking a license, see https://" +"choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` " +"and enter the license text. For example, if you had chosen the MIT license:" msgstr "" #: ../source/tutorials/packaging-projects.rst:387 @@ -9139,11 +13335,19 @@ msgid "Including other files" msgstr "Inkluzivi aliajn dosierojn" #: ../source/tutorials/packaging-projects.rst:389 -msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." +msgid "" +"The files listed above will be included automatically in your :term:`source " +"distribution `. If you want to control " +"what goes in this explicitly, see :ref:`Using MANIFEST.in`." msgstr "" #: ../source/tutorials/packaging-projects.rst:393 -msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." +msgid "" +"The final :term:`built distribution ` will have the " +"Python files in the discovered or listed Python packages. If you want to " +"control what goes here, such as to add data files, see :doc:`Including Data " +"Files ` from the :doc:`setuptools docs " +"`." msgstr "" #: ../source/tutorials/packaging-projects.rst:402 @@ -9151,7 +13355,10 @@ msgid "Generating distribution archives" msgstr "" #: ../source/tutorials/packaging-projects.rst:404 -msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." +msgid "" +"The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the " +"Python Package Index and can be installed by :ref:`pip`." msgstr "" #: ../source/tutorials/packaging-projects.rst:408 @@ -9159,19 +13366,32 @@ msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" msgstr "" #: ../source/tutorials/packaging-projects.rst:422 -msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." +msgid "" +"If you have trouble installing these, see the :doc:`installing-packages` " +"tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:425 -msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" +msgid "" +"Now run this command from the same directory where :file:`pyproject.toml` is " +"located:" msgstr "" #: ../source/tutorials/packaging-projects.rst:439 -msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" +msgid "" +"This command should output a lot of text and once completed should generate " +"two files in the :file:`dist` directory:" msgstr "" #: ../source/tutorials/packaging-projects.rst:449 -msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." +msgid "" +"The ``tar.gz`` file is a :term:`source archive ` whereas the " +"``.whl`` file is a :term:`built distribution `. Newer :" +"ref:`pip` versions preferentially install built distributions, but will fall " +"back to source archives if needed. You should always upload a source archive " +"and provide built archives for the platforms your project is compatible " +"with. In this case, our example package is compatible with Python on any " +"platform so only one built distribution is needed." msgstr "" #: ../source/tutorials/packaging-projects.rst:458 @@ -9183,23 +13403,40 @@ msgid "Finally, it's time to upload your package to the Python Package Index!" msgstr "" #: ../source/tutorials/packaging-projects.rst:462 -msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." +msgid "" +"The first thing you'll need to do is register an account on TestPyPI, which " +"is a separate instance of the package index intended for testing and " +"experimentation. It's great for things like this tutorial where we don't " +"necessarily want to upload to the real index. To register an account, go to " +"https://test.pypi.org/account/register/ and complete the steps on that page. " +"You will also need to verify your email address before you're able to upload " +"any packages. For more details, see :doc:`/guides/using-testpypi`." msgstr "" #: ../source/tutorials/packaging-projects.rst:470 -msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgid "" +"To securely upload your project, you'll need a PyPI `API token`_. Create one " +"at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" " +"to \"Entire account\". **Don't close the page until you have copied and " +"saved the token — you won't see that token again.**" msgstr "" #: ../source/tutorials/packaging-projects.rst:477 -msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" +msgid "" +"Now that you are registered, you can use :ref:`twine` to upload the " +"distribution packages. You'll need to install Twine:" msgstr "" #: ../source/tutorials/packaging-projects.rst:492 -msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" +msgid "" +"Once installed, run Twine to upload all of the archives under :file:`dist`:" msgstr "" #: ../source/tutorials/packaging-projects.rst:506 -msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." +msgid "" +"You will be prompted for a username and password. For the username, use " +"``__token__``. For the password, use the token value, including the ``pypi-" +"`` prefix." msgstr "" #: ../source/tutorials/packaging-projects.rst:510 @@ -9207,7 +13444,9 @@ msgid "After the command completes, you should see output similar to this:" msgstr "" #: ../source/tutorials/packaging-projects.rst:523 -msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" +msgid "" +"Once uploaded your package should be viewable on TestPyPI, for example, " +"https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" msgstr "" #: ../source/tutorials/packaging-projects.rst:528 @@ -9215,7 +13454,10 @@ msgid "Installing your newly uploaded package" msgstr "" #: ../source/tutorials/packaging-projects.rst:530 -msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" +msgid "" +"You can use :ref:`pip` to install your package and verify that it works. " +"Create a :ref:`virtual environment ` and install your package from TestPyPI:" msgstr "" #: ../source/tutorials/packaging-projects.rst:546 @@ -9223,15 +13465,25 @@ msgid "Make sure to specify your username in the package name!" msgstr "" #: ../source/tutorials/packaging-projects.rst:548 -msgid "pip should install the package from TestPyPI and the output should look something like this:" +msgid "" +"pip should install the package from TestPyPI and the output should look " +"something like this:" msgstr "" #: ../source/tutorials/packaging-projects.rst:558 -msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." +msgid "" +"This example uses ``--index-url`` flag to specify TestPyPI instead of live " +"PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have " +"the same packages as the live PyPI, it's possible that attempting to install " +"dependencies may fail or install something unexpected. While our example " +"package doesn't have any dependencies, it's a good practice to avoid " +"installing dependencies when using TestPyPI." msgstr "" #: ../source/tutorials/packaging-projects.rst:565 -msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" +msgid "" +"You can test that it was installed correctly by importing the package. Make " +"sure you're still in your virtual environment, then run Python:" msgstr "" #: ../source/tutorials/packaging-projects.rst:580 @@ -9239,43 +13491,70 @@ msgid "and import the package:" msgstr "" #: ../source/tutorials/packaging-projects.rst:588 -msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." +msgid "" +"Note that the :term:`import package ` is ``example_package`` " +"regardless of what ``name`` you gave your :term:`distribution package " +"` in :file:`setup.cfg` or :file:`setup.py` (in this " +"case, ``example-pkg-YOUR-USERNAME-HERE``)." msgstr "" #: ../source/tutorials/packaging-projects.rst:596 -msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" +msgid "" +"**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" msgstr "" #: ../source/tutorials/packaging-projects.rst:599 -msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." +msgid "" +"Keep in mind that this tutorial showed you how to upload your package to " +"Test PyPI, which isn't a permanent storage. The Test system occasionally " +"deletes packages and accounts. It is best to use TestPyPI for testing and " +"experiments like this tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:604 -msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" +msgid "" +"When you are ready to upload a real package to the Python Package Index you " +"can do much the same as you did in this tutorial, but with these important " +"differences:" msgstr "" #: ../source/tutorials/packaging-projects.rst:608 -msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." +msgid "" +"Choose a memorable and unique name for your package. You don't have to " +"append your username as you did in the tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:610 -msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." +msgid "" +"Register an account on https://pypi.org - note that these are two separate " +"servers and the login details from the test server are not shared with the " +"main server." msgstr "" #: ../source/tutorials/packaging-projects.rst:613 -msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." +msgid "" +"Use ``twine upload dist/*`` to upload your package and enter your " +"credentials for the account you registered on the real PyPI. Now that " +"you're uploading the package in production, you don't need to specify ``--" +"repository``; the package will upload to https://pypi.org/ by default." msgstr "" #: ../source/tutorials/packaging-projects.rst:617 -msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." +msgid "" +"Install your package from the real PyPI using ``python3 -m pip install [your-" +"package]``." msgstr "" #: ../source/tutorials/packaging-projects.rst:619 -msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" +msgid "" +"At this point if you want to read more on packaging Python libraries here " +"are some things you can do:" msgstr "" #: ../source/tutorials/packaging-projects.rst:622 -msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." +msgid "" +"Read more about using :ref:`setuptools` to package libraries in :doc:`/" +"guides/distributing-packages-using-setuptools`." msgstr "" #: ../source/tutorials/packaging-projects.rst:624 @@ -9283,5 +13562,7 @@ msgid "Read about :doc:`/guides/packaging-binary-extensions`." msgstr "" #: ../source/tutorials/packaging-projects.rst:625 -msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." +msgid "" +"Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:" +"`hatch`, and :ref:`poetry`." msgstr "" diff --git a/locales/pt_BR/LC_MESSAGES/messages.po b/locales/pt_BR/LC_MESSAGES/messages.po index 7e281145c..7af4ab446 100644 --- a/locales/pt_BR/LC_MESSAGES/messages.po +++ b/locales/pt_BR/LC_MESSAGES/messages.po @@ -23,7 +23,9 @@ msgid "Contribute to this guide" msgstr "Contribuir para este guia" #: ../source/contribute.rst:7 -msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" +msgid "" +"The |PyPUG| welcomes contributors! There are lots of ways to help out, " +"including:" msgstr "" "O |PyPUG| dá as boas-vindas aos(às) contribuidores(as)! Existem muitas " "maneiras de ajudar, incluindo:" @@ -45,50 +47,66 @@ msgid "Writing new content" msgstr "Escrevendo novo conteúdo" #: ../source/contribute.rst:15 -msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." +msgid "" +"Most of the work on the |PyPUG| takes place on the `project's GitHub " +"repository`__. To get started, check out the list of `open issues`__ and " +"`pull requests`__. If you're planning to write or edit the guide, please " +"read the :ref:`style guide `." msgstr "" "A maior parte do trabalho no |PyPUG| ocorre no `repositório GitHub do " "projeto`__. Para começar, verifique a lista de `problemas abertos`__ e `pull " -"requests`__. Se você está planejando escrever ou editar o guia, leia o :ref:`" -"guia de estilo `." +"requests`__. Se você está planejando escrever ou editar o guia, leia o :ref:" +"`guia de estilo `." #: ../source/contribute.rst:24 -msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." +msgid "" +"By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of " +"Conduct`__." msgstr "" -"Ao contribuir para o |PyPUG|, espera-se que você siga o `Código de Conduta`" -"__ da PSF." +"Ao contribuir para o |PyPUG|, espera-se que você siga o `Código de " +"Conduta`__ da PSF." #: ../source/contribute.rst:31 msgid "Documentation types" msgstr "Tipos de documentação" #: ../source/contribute.rst:33 -msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." +msgid "" +"This project consists of four distinct documentation types with specific " +"purposes. When proposing new additions to the project please pick the " +"appropriate documentation type." msgstr "" "Este projeto consiste em quatro tipos de documentação distintos com " "finalidades específicas. Ao propor novas adições ao projeto, escolha o tipo " "de documentação apropriado." -#: ../source/contribute.rst:38 -#: ../source/tutorials/index.rst:2 +#: ../source/contribute.rst:38 ../source/tutorials/index.rst:2 msgid "Tutorials" msgstr "Tutoriais" #: ../source/contribute.rst:40 -msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." +msgid "" +"Tutorials are focused on teaching the reader new concepts by accomplishing a " +"goal. They are opinionated step-by-step guides. They do not include " +"extraneous warnings or information. `example tutorial-style document`_." msgstr "" "Os tutoriais são focados em ensinar ao leitor novos conceitos através da " "realização de um objetivo. Eles são guias passo a passo opinativos. Eles não " "incluem avisos ou informações estranhas. `Exemplo de documento no estilo " "tutorial`_." -#: ../source/contribute.rst:47 -#: ../source/guides/index.rst:2 +#: ../source/contribute.rst:47 ../source/guides/index.rst:2 msgid "Guides" msgstr "Guias" #: ../source/contribute.rst:49 -msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." +msgid "" +"Guides are focused on accomplishing a specific task and can assume some " +"level of pre-requisite knowledge. These are similar to tutorials, but have a " +"narrow and clear focus and can provide lots of caveats and additional " +"information as needed. They may also discuss multiple approaches to " +"accomplishing the task. :doc:`example guide-style document `." msgstr "" "Os guias são focados em realizar uma tarefa específica e podem assumir algum " "nível de conhecimento pré-requisito. Eles são semelhantes aos tutoriais, mas " @@ -97,13 +115,15 @@ msgstr "" "várias abordagens para realizar a tarefa. :doc:`Exemplo de documento no " "estilo guia `." -#: ../source/contribute.rst:56 -#: ../source/discussions/index.rst:2 +#: ../source/contribute.rst:56 ../source/discussions/index.rst:2 msgid "Discussions" msgstr "Discussões" #: ../source/contribute.rst:58 -msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." +msgid "" +"Discussions are focused on understanding and information. These explore a " +"specific topic without a specific goal in mind. :doc:`example discussion-" +"style document `." msgstr "" "As discussões são focadas em compreensão e informação. Eles exploram um " "tópico específico sem um objetivo específico em mente. :doc:`Exemplo de " @@ -115,7 +135,11 @@ msgid "Specifications" msgstr "Especificações" #: ../source/contribute.rst:65 -msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." +msgid "" +"Specifications are reference documention focused on comprehensively " +"documenting an agreed-upon interface for interoperability between packaging " +"tools. :doc:`example specification-style document `." msgstr "" "As especificações são documentação de referência focada na documentação " "abrangente de uma interface acordada para interoperabilidade entre " @@ -127,40 +151,55 @@ msgid "Building the guide locally" msgstr "Construindo o guia localmente" #: ../source/contribute.rst:75 -msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" +msgid "" +"Though not required to contribute, it may be useful to build this guide " +"locally in order to test your changes. In order to build this guide locally, " +"you'll need:" msgstr "" "Embora não seja necessário contribuir, pode ser útil construir este guia " "localmente para testar suas alterações. Para construir este guia localmente, " "você precisará:" #: ../source/contribute.rst:79 -msgid "`Nox `_. You can install or upgrade nox using ``pip``::" +msgid "" +"`Nox `_. You can install or upgrade " +"nox using ``pip``::" msgstr "" "`Nox `_. Você pode instalar ou " "atualizar o nox usando o ``pip``::" #: ../source/contribute.rst:84 -msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." +msgid "" +"Python 3.6. Our build scripts are designed to work with Python 3.6 only. See " +"the `Hitchhiker's Guide to Python installation instructions`_ to install " +"Python 3.6 on your operating system." msgstr "" "Python 3.6. Nossos scripts de construção são projetados para funcionar " "apenas com Python 3.6. Consulte o `Guia do mochileiro para as instruções de " "instalação do Python`_ para instalar o Python 3.6 em seu sistema operacional." #: ../source/contribute.rst:91 -msgid "To build the guide, run the following bash command in the source folder::" +msgid "" +"To build the guide, run the following bash command in the source folder::" msgstr "" "Para construir o guia, execute o seguinte comando bash na pasta do código-" "fonte::" #: ../source/contribute.rst:95 -msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." +msgid "" +"After the process has completed you can find the HTML output in the ``./" +"build/html`` directory. You can open the ``index.html`` file to view the " +"guide in web browser, but it's recommended to serve the guide using an HTTP " +"server." msgstr "" "Após a conclusão do processo, você pode encontrar a saída HTML no diretório " "``./build/html``. Você pode abrir o arquivo ``index.html`` para ver o guia " "no navegador web, mas é recomendado servir o guia usando um servidor HTTP." #: ../source/contribute.rst:100 -msgid "You can build the guide and serve it via an HTTP server using the following command::" +msgid "" +"You can build the guide and serve it via an HTTP server using the following " +"command::" msgstr "" "Você pode construir o guia e exibi-lo por meio de um servidor HTTP usando o " "seguinte comando::" @@ -174,30 +213,39 @@ msgid "Where the guide is deployed" msgstr "Onde o guia é disponibilizado" #: ../source/contribute.rst:111 -msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." +msgid "" +"The guide is deployed via ReadTheDocs and the configuration lives at https://" +"readthedocs.org/projects/python-packaging-user-guide/. It's served from a " +"custom domain and fronted by Fast.ly." msgstr "" -"O guia é disponibilizado via ReadTheDocs e a configuração está em " -"https://readthedocs.org/projects/python-packaging-user-guide/.. É servido a " -"partir de um domínio personalizado e guardado por Fast.ly." +"O guia é disponibilizado via ReadTheDocs e a configuração está em https://" +"readthedocs.org/projects/python-packaging-user-guide/.. É servido a partir " +"de um domínio personalizado e guardado por Fast.ly." #: ../source/contribute.rst:117 msgid "Style guide" msgstr "Guia de estilo" #: ../source/contribute.rst:119 -msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." +msgid "" +"This style guide has recommendations for how you should write the |PyPUG|. " +"Before you start writing, please review it. By following the style guide, " +"your contributions will help add to a cohesive whole and make it easier for " +"your contributions to be accepted into the project." msgstr "" -"Este guia de estilo contém recomendações de como você deve escrever o |PyPUG|" -". Antes de começar a escrever, revise-o. Seguindo o guia de estilo, suas " -"contribuições ajudarão a formar um todo coeso e tornar mais fácil para que " -"suas contribuições sejam aceitas no projeto." +"Este guia de estilo contém recomendações de como você deve escrever o |" +"PyPUG|. Antes de começar a escrever, revise-o. Seguindo o guia de estilo, " +"suas contribuições ajudarão a formar um todo coeso e tornar mais fácil para " +"que suas contribuições sejam aceitas no projeto." #: ../source/contribute.rst:126 msgid "Purpose" msgstr "Propósito" #: ../source/contribute.rst:128 -msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." +msgid "" +"The purpose of the |PyPUG| is to be the authoritative resource on how to " +"package, publish, and install Python projects using current tools." msgstr "" "O objetivo do |PyPUG| é ser o recurso autorizado sobre como empacotar, " "publicar e instalar projetos Python usando as ferramentas atuais." @@ -207,13 +255,20 @@ msgid "Scope" msgstr "Escopo" #: ../source/contribute.rst:135 -msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." +msgid "" +"The guide is meant to answer questions and solve problems with accurate and " +"focused recommendations." msgstr "" "O guia destina-se a responder a perguntas e resolver problemas com " "recomendações precisas e focadas." #: ../source/contribute.rst:138 -msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." +msgid "" +"The guide isn't meant to be comprehensive and it's not meant to replace " +"individual projects' documentation. For example, pip has dozens of commands, " +"options, and settings. The pip documentation describes each of them in " +"detail, while this guide describes only the parts of pip that are needed to " +"complete the specific tasks described in this guide." msgstr "" "O guia não pretende ser abrangente e não pretende substituir a documentação " "de projetos individuais. Por exemplo, pip tem dezenas de comandos, opções e " @@ -227,17 +282,24 @@ msgstr "Público-alvo" #: ../source/contribute.rst:148 msgid "The audience of this guide is anyone who uses Python with packages." -msgstr "O público-alvo deste guia é qualquer pessoa que use Python com pacotes." +msgstr "" +"O público-alvo deste guia é qualquer pessoa que use Python com pacotes." #: ../source/contribute.rst:150 -msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." +msgid "" +"Don't forget that the Python community is big and welcoming. Readers may not " +"share your age, gender, education, culture, and more, but they deserve to " +"learn about packaging just as much as you do." msgstr "" "Não se esqueça de que a comunidade Python é grande e acolhedora. Os leitores " "podem não compartilhar sua idade, sexo, educação, cultura e muito mais, mas " "eles merecem aprender sobre empacotamento tanto quanto você." #: ../source/contribute.rst:154 -msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." +msgid "" +"In particular, keep in mind that not all people who use Python see " +"themselves as programmers. The audience of this guide includes astronomers " +"or painters or students as well as professional software developers." msgstr "" "Em particular, tenha em mente que nem todas as pessoas que usam Python se " "consideram programadores. O público deste guia inclui astrônomos, pintores " @@ -248,13 +310,19 @@ msgid "Voice and tone" msgstr "Voz e tom" #: ../source/contribute.rst:162 -msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." +msgid "" +"When writing this guide, strive to write with a voice that's approachable " +"and humble, even if you have all the answers." msgstr "" "Ao escrever este guia, esforce-se para escrever com uma voz que seja " "acessível e humilde, mesmo que você tenha todas as respostas." #: ../source/contribute.rst:165 -msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." +msgid "" +"Imagine you're working on a Python project with someone you know to be smart " +"and skilled. You like working with them and they like working with you. That " +"person has asked you a question and you know the answer. How do you respond? " +"*That* is how you should write this guide." msgstr "" "Imagine que você está trabalhando em um projeto Python com alguém que sabe " "ser inteligente e habilidoso. Você gosta de trabalhar com eles e eles gostam " @@ -262,7 +330,13 @@ msgstr "" "Como você responde? *É assim* que você deve escrever este guia." #: ../source/contribute.rst:170 -msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." +msgid "" +"Here's a quick check: try reading aloud to get a sense for your writing's " +"voice and tone. Does it sound like something you would say or does it sound " +"like you're acting out a part or giving a speech? Feel free to use " +"contractions and don't worry about sticking to fussy grammar rules. You are " +"hereby granted permission to end a sentence in a preposition, if that's what " +"you want to end it with." msgstr "" "Aqui está uma verificação rápida: tente ler em voz alta para ter uma noção " "da voz e do tom de sua escrita. Parece algo que você diria ou parece que " @@ -272,7 +346,11 @@ msgstr "" "que deseja encerrá-la." #: ../source/contribute.rst:177 -msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." +msgid "" +"When writing the guide, adjust your tone for the seriousness and difficulty " +"of the topic. If you're writing an introductory tutorial, it's OK to make a " +"joke, but if you're covering a sensitive security recommendation, you might " +"want to avoid jokes altogether." msgstr "" "Ao escrever o guia, ajuste seu tom de acordo com a seriedade e a dificuldade " "do tópico. Se você estiver escrevendo um tutorial introdutório, não há " @@ -288,7 +366,9 @@ msgid "**Write to the reader**" msgstr "**Escreva para o leitor**" #: ../source/contribute.rst:187 -msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." +msgid "" +"When giving recommendations or steps to take, address the reader as *you* or " +"use the imperative mood." msgstr "" "Ao dar recomendações ou etapas a serem seguidas, dirija-se ao leitor como " "*você* ou use o humor imperativo." @@ -310,7 +390,11 @@ msgid "**State assumptions**" msgstr "**Assuma pressupostos**" #: ../source/contribute.rst:195 -msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." +msgid "" +"Avoid making unstated assumptions. Reading on the web means that any page of " +"the guide may be the first page of the guide that the reader ever sees. If " +"you're going to make assumptions, then say what assumptions that you're " +"going to make." msgstr "" "Evite fazer suposições não declaradas. Ler na web significa que qualquer " "página do guia pode ser a primeira página do guia que o leitor vê. Se você " @@ -321,7 +405,10 @@ msgid "**Cross-reference generously**" msgstr "**Faça uso generoso de referência cruzada**" #: ../source/contribute.rst:201 -msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." +msgid "" +"The first time you mention a tool or practice, link to the part of the guide " +"that covers it, or link to a relevant document elsewhere. Save the reader a " +"search." msgstr "" "Na primeira vez que você mencionar uma ferramenta ou prática, coloque um " "link para a parte do guia que a cobre ou para um documento relevante em " @@ -332,7 +419,9 @@ msgid "**Respect naming practices**" msgstr "**Respeite as práticas de nomenclatura**" #: ../source/contribute.rst:206 -msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." +msgid "" +"When naming tools, sites, people, and other proper nouns, use their " +"preferred capitalization." msgstr "" "Ao nomear ferramentas, sites, pessoas e outros nomes próprios, use a " "capitalização de sua preferência." @@ -358,7 +447,10 @@ msgid "**Use a gender-neutral style**" msgstr "**Use um estilo de gênero neutro**" #: ../source/contribute.rst:216 -msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." +msgid "" +"Often, you'll address the reader directly with *you*, *your* and *yours*. " +"Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or " +"avoid pronouns entirely." msgstr "" "Frequentemente, você se dirigirá ao leitor diretamente com *you*, *your* e " "*yours*. Caso contrário, use pronomes de gênero neutro *they*, *their* e " @@ -381,7 +473,11 @@ msgid "**Headings**" msgstr "**Títulos**" #: ../source/contribute.rst:225 -msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." +msgid "" +"Write headings that use words the reader is searching for. A good way to do " +"this is to have your heading complete an implied question. For example, a " +"reader might want to know *How do I install MyLibrary?* so a good heading " +"might be *Install MyLibrary*." msgstr "" "Escreva títulos que usem palavras que o leitor esteja procurando. Uma boa " "maneira de fazer isso é fazer com que o cabeçalho responda a uma pergunta " @@ -389,7 +485,9 @@ msgstr "" "MyLibrary?*, de forma que um bom título pode ser *Install MyLibrary*." #: ../source/contribute.rst:230 -msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." +msgid "" +"In section headings, use sentence case. In other words, write headings as " +"you would write a typical sentence." msgstr "" "Nos cabeçalhos das seções, use letras maiúsculas e minúsculas. Em outras " "palavras, escreva os cabeçalhos da mesma forma que escreveria uma frase " @@ -408,7 +506,9 @@ msgid "**Numbers**" msgstr "**Números**" #: ../source/contribute.rst:237 -msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." +msgid "" +"In body text, write numbers one through nine as words. For other numbers or " +"numbers in tables, use numerals." msgstr "" "No corpo do texto, escreva os números de um a nove como palavras. Para " "outros números ou números nas tabelas, use numerais." @@ -457,8 +557,7 @@ msgstr "2014-11-11" #: ../source/guides/packaging-binary-extensions.rst:17 #: ../source/guides/supporting-multiple-python-versions.rst:12 #: ../source/guides/supporting-windows-using-appveyor.rst:15 -#: ../source/overview.rst:23 -#: ../source/specifications/core-metadata.rst:38 +#: ../source/overview.rst:23 ../source/specifications/core-metadata.rst:38 #: ../source/specifications/direct-url.rst:14 #: ../source/tutorials/installing-packages.rst:23 msgid "Contents" @@ -485,7 +584,13 @@ msgid "Pynsist" msgstr "Pynsist" #: ../source/discussions/deploying-python-applications.rst:63 -msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." +msgid "" +"`Pynsist `__ is a tool that bundles Python " +"programs together with the Python-interpreter into a single installer based " +"on NSIS. In most cases, packaging only requires the user to choose a version " +"of the Python-interpreter and declare the dependencies of the program. The " +"tool downloads the specified Python-interpreter for Windows and packages it " +"with all the dependencies in a single Windows-executable installer." msgstr "" "`Pynsist `__ é uma ferramenta que agrupa " "programas Python junto com o interpretador Python em um único instalador " @@ -496,7 +601,11 @@ msgstr "" "executável do Windows." #: ../source/discussions/deploying-python-applications.rst:70 -msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." +msgid "" +"The installed program can be started from a shortcut that the installer adds " +"to the start-menu. It uses a Python interpreter installed within its " +"application directory, independent of any other Python installation on the " +"computer." msgstr "" "O programa instalado pode ser iniciado a partir de um atalho que o " "instalador adiciona ao menu iniciar. Ele usa um interpretador Python " @@ -504,12 +613,16 @@ msgstr "" "instalação Python no computador." #: ../source/discussions/deploying-python-applications.rst:74 -msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." +msgid "" +"A big advantage of Pynsist is that the Windows packages can be built on " +"Linux. There are several examples for different kinds of programs (console, " +"GUI) in the `documentation `__. The tool is " +"released under the MIT-licence." msgstr "" "Uma grande vantagem do Pynsist é que os pacotes do Windows podem ser " "construídos no Linux. Existem vários exemplos para diferentes tipos de " -"programas (console, GUI) na `documentação `" -"__. A ferramenta é lançada sob a licença do MIT." +"programas (console, GUI) na `documentação `__. A ferramenta é lançada sob a licença do MIT." #: ../source/discussions/deploying-python-applications.rst:80 msgid "Application bundles" @@ -520,7 +633,10 @@ msgid "Configuration management" msgstr "Gerenciamento de configuração" #: ../source/discussions/index.rst:4 -msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." +msgid "" +"**Discussions** are focused on providing comprehensive information about a " +"specific topic. If you're just trying to get stuff done, see :doc:`/guides/" +"index`." msgstr "" "**Discussões ** têm como objetivo fornecer informações abrangentes sobre um " "tópico específico. Se você está apenas tentando fazer as coisas, veja :doc:`/" @@ -536,40 +652,56 @@ msgid "install_requires" msgstr "install_requires" #: ../source/discussions/install-requires-vs-requirements.rst:14 -msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgid "" +"``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that " +"should be used to specify what a project **minimally** needs to run " +"correctly. When the project is installed by :ref:`pip`, this is the " +"specification that is used to install its dependencies." msgstr "" -"``install_requires`` é uma palavra-chave do :file:`setup.py` do " -":ref:`setuptools` que deve ser usada para especificar o que um projeto " +"``install_requires`` é uma palavra-chave do :file:`setup.py` do :ref:" +"`setuptools` que deve ser usada para especificar o que um projeto " "**minimamente** precisa para rodar corretamente. Quando o projeto é " "instalado por :ref:`pip`, esta é a especificação que é usada para instalar " "suas dependências." #: ../source/discussions/install-requires-vs-requirements.rst:19 -msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" +msgid "" +"For example, if the project requires A and B, your ``install_requires`` " +"would be like so:" msgstr "" "Por exemplo, se o projeto requer A e B, seu ``install_requires`` seria assim:" #: ../source/discussions/install-requires-vs-requirements.rst:29 -msgid "Additionally, it's best practice to indicate any known lower or upper bounds." +msgid "" +"Additionally, it's best practice to indicate any known lower or upper bounds." msgstr "" "Além disso, é uma prática recomendada indicar qualquer limite inferior ou " "superior conhecido." #: ../source/discussions/install-requires-vs-requirements.rst:31 -msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" +msgid "" +"For example, it may be known, that your project requires at least v1 of 'A', " +"and v2 of 'B', so it would be like so:" msgstr "" "Por exemplo, pode-se saber que seu projeto requer pelo menos v1 de \"A\" e " "v2 de \"B\", então seria assim:" #: ../source/discussions/install-requires-vs-requirements.rst:41 -msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" +msgid "" +"It may also be known that project A follows semantic versioning, and that v2 " +"of 'A' will indicate a break in compatibility, so it makes sense to not " +"allow v2:" msgstr "" "Também pode ser sabido que o projeto A segue versionamento semântico, e que " "a v2 de \"A\" irá indicar uma quebra na compatibilidade, então faz sentido " "não permitir a v2:" #: ../source/discussions/install-requires-vs-requirements.rst:51 -msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." +msgid "" +"It is not considered best practice to use ``install_requires`` to pin " +"dependencies to specific versions, or to specify sub-dependencies (i.e. " +"dependencies of your dependencies). This is overly-restrictive, and " +"prevents the user from gaining the benefit of dependency upgrades." msgstr "" "Não é considerada a melhor prática usar ``install_requires`` para fixar " "dependências em versões específicas, ou para especificar subdependências (ou " @@ -577,14 +709,19 @@ msgstr "" "evita que o usuário obtenha o benefício de atualizações de dependência." #: ../source/discussions/install-requires-vs-requirements.rst:56 -msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" +msgid "" +"Lastly, it's important to understand that ``install_requires`` is a listing " +"of \"Abstract\" requirements, i.e just names and version restrictions that " +"don't determine where the dependencies will be fulfilled from (i.e. from " +"what index or source). The where (i.e. how they are to be made \"Concrete" +"\") is to be determined at install time using :ref:`pip` options. [1]_" msgstr "" "Por último, é importante entender que ``install_requires`` é uma lista de " "requisitos \"abstratos\", ou seja, apenas nomes e restrições de versão que " "não determinam de onde as dependências serão preenchidas (ou seja, de qual " "índice ou fonte). O local (ou seja, como eles devem ser feitos de \"concreto" -"\") deve ser determinado no momento da instalação usando as opções :ref:`pip`" -". [1]_" +"\") deve ser determinado no momento da instalação usando as opções :ref:" +"`pip`. [1]_" #: ../source/discussions/install-requires-vs-requirements.rst:64 #: ../source/tutorials/installing-packages.rst:460 @@ -592,14 +729,19 @@ msgid "Requirements files" msgstr "Arquivos requirements" #: ../source/discussions/install-requires-vs-requirements.rst:66 -msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." +msgid "" +":ref:`Requirements Files ` described most simply, " +"are just a list of :ref:`pip:pip install` arguments placed into a file." msgstr "" ":ref:`Arquivos requirements ` descritos de forma " "mais simples, são apenas uma lista de argumentos :ref:`pip:pip install` " "colocados em um arquivo." #: ../source/discussions/install-requires-vs-requirements.rst:69 -msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." +msgid "" +"Whereas ``install_requires`` defines the dependencies for a single project, :" +"ref:`Requirements Files ` are often used to define " +"the requirements for a complete Python environment." msgstr "" "Considerando que ``install_requires`` define as dependências para um único " "projeto, :ref:`arquivos requirements ` são " @@ -607,24 +749,36 @@ msgstr "" "completo." #: ../source/discussions/install-requires-vs-requirements.rst:73 -msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." +msgid "" +"Whereas ``install_requires`` requirements are minimal, requirements files " +"often contain an exhaustive listing of pinned versions for the purpose of " +"achieving :ref:`repeatable installations ` of a complete " +"environment." msgstr "" "Considerando que os requisitos de `` install_requires`` são mínimos, os " "arquivos de requisitos frequentemente contêm uma lista exaustiva de versões " -"fixadas com o propósito de alcançar :ref:`instalações repetíveis " -"` de um ambiente completo." +"fixadas com o propósito de alcançar :ref:`instalações repetíveis ` de um ambiente completo." #: ../source/discussions/install-requires-vs-requirements.rst:78 -msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" +msgid "" +"Whereas ``install_requires`` requirements are \"Abstract\", i.e. not " +"associated with any particular index, requirements files often contain pip " +"options like ``--index-url`` or ``--find-links`` to make requirements " +"\"Concrete\", i.e. associated with a particular index or directory of " +"packages. [1]_" msgstr "" "Considerando que os requisitos de ``install_requires`` são \"abstratos\", ou " "seja, não estão associados a nenhum índice em particular, os arquivos " -"requirements geralmente contêm opções de pip como ``--index-url`` ou " -"``--find-links`` para fazer requisitos \"concreto \", isto é, associado a um " +"requirements geralmente contêm opções de pip como ``--index-url`` ou ``--" +"find-links`` para fazer requisitos \"concreto \", isto é, associado a um " "determinado índice ou diretório de pacotes. [1]_" #: ../source/discussions/install-requires-vs-requirements.rst:84 -msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." +msgid "" +"Whereas ``install_requires`` metadata is automatically analyzed by pip " +"during an install, requirements files are not, and only are used when a user " +"specifically installs them using ``python -m pip install -r``." msgstr "" "Enquanto os metadados ``install_requires`` são automaticamente analisados " "pelo pip durante uma instalação, os arquivos de requisitos não são, e são " @@ -632,7 +786,9 @@ msgstr "" "m pip install -r``." #: ../source/discussions/install-requires-vs-requirements.rst:90 -msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." +msgid "" +"For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad." +"io/2013/07/setup-vs-requirement/." msgstr "" "Para obter mais informações sobre os requisitos \"abstratos\" vs \"concretos" "\", consulte https://caremad.io/2013/07/setup-vs-requirement/." @@ -642,15 +798,29 @@ msgid "pip vs easy_install" msgstr "pip vs easy_install" #: ../source/discussions/pip-vs-easy-install.rst:9 -msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." +msgid "" +":ref:`easy_install `, now `deprecated`_, was released in 2004 " +"as part of :ref:`setuptools`. It was notable at the time for installing :" +"term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing " +"dependencies." msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:14 -msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." +msgid "" +":ref:`pip` came later in 2008, as alternative to :ref:`easy_install " +"`, although still largely built on top of :ref:`setuptools` " +"components. It was notable at the time for *not* installing packages as :" +"term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' " +"packages from :term:`sdists `), and " +"introducing the idea of :ref:`Requirements Files `, " +"which gave users the power to easily replicate environments." msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:22 -msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" +msgid "" +"Here's a breakdown of the important differences between pip and the " +"deprecated easy_install:" msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:25 @@ -764,7 +934,9 @@ msgid "Yes, via setup.cfg" msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:68 -msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" +msgid "" +"https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" +"launcher" msgstr "" #: ../source/discussions/wheel-vs-egg.rst:5 @@ -772,19 +944,28 @@ msgid "Wheel vs Egg" msgstr "" #: ../source/discussions/wheel-vs-egg.rst:7 -msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." +msgid "" +":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support " +"the use case of needing an install artifact that doesn't require building or " +"compilation, which can be costly in testing and production workflows." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:11 -msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." +msgid "" +"The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas " +"the :term:`Wheel` format was introduced by :pep:`427` in 2012." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:14 -msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." +msgid "" +":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:17 -msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." +msgid "" +"Here's a breakdown of the important differences between :term:`Wheel` and :" +"term:`Egg`." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:20 @@ -792,31 +973,53 @@ msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:22 -msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." +msgid "" +":term:`Wheel` is a :term:`distribution ` format, i.e a " +"packaging format. [1]_ :term:`Egg` was both a distribution format and a " +"runtime installation format (if left zipped), and was designed to be " +"importable." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:26 -msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." +msgid "" +":term:`Wheel` archives do not include .pyc files. Therefore, when the " +"distribution only contains Python files (i.e. no compiled extensions), and " +"is compatible with Python 2 and 3, it's possible for a wheel to be " +"\"universal\", similar to an :term:`sdist `." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:31 -msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." +msgid "" +":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. " +"Egg used ``.egg-info``." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:34 -msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." +msgid "" +":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single " +"wheel archive can indicate its compatibility with a number of Python " +"language versions and implementations, ABIs, and system architectures." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:38 -msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." +msgid "" +":term:`Wheel` is versioned. Every wheel file contains the version of the " +"wheel specification and the implementation that packaged it." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:41 -msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." +msgid "" +":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making " +"it easier to convert to other formats." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:47 -msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." +msgid "" +"Circumstantially, in some cases, wheels can be used as an importable runtime " +"format, although :pep:`this is not officially supported at this time <427#is-" +"it-possible-to-import-python-code-directly-from-a-wheel-file>`." msgstr "" #: ../source/glossary.rst:3 @@ -828,7 +1031,9 @@ msgid "Binary Distribution" msgstr "" #: ../source/glossary.rst:11 -msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." +msgid "" +"A specific kind of :term:`Built Distribution` that contains compiled " +"extensions." msgstr "" #: ../source/glossary.rst:14 @@ -836,7 +1041,14 @@ msgid "Built Distribution" msgstr "" #: ../source/glossary.rst:17 -msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." +msgid "" +"A :term:`Distribution ` format containing files and " +"metadata that only need to be moved to the correct location on the target " +"system, to be installed. :term:`Wheel` is such a format, whereas distutil's :" +"term:`Source Distribution ` is not, in " +"that it requires a build step before it can be installed. This format does " +"not imply that Python files have to be precompiled (:term:`Wheel` " +"intentionally does not include compiled Python files)." msgstr "" #: ../source/glossary.rst:26 @@ -844,11 +1056,22 @@ msgid "Distribution Package" msgstr "" #: ../source/glossary.rst:29 -msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." +msgid "" +"A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used " +"to distribute a :term:`Release`. The archive file is what an end-user will " +"download from the internet and install." msgstr "" #: ../source/glossary.rst:34 -msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." +msgid "" +"A distribution package is more commonly referred to with the single words " +"\"package\" or \"distribution\", but this guide may use the expanded term " +"when more clarity is needed to prevent confusion with an :term:`Import " +"Package` (which is also commonly called a \"package\") or another kind of " +"distribution (e.g. a Linux distribution or the Python language " +"distribution), which are often referred to with the single term " +"\"distribution\"." msgstr "" #: ../source/glossary.rst:41 @@ -856,7 +1079,12 @@ msgid "Egg" msgstr "" #: ../source/glossary.rst:44 -msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" +msgid "" +"A :term:`Built Distribution` format introduced by :ref:`setuptools`, which " +"is being replaced by :term:`Wheel`. For details, see `The Internal " +"Structure of Python Eggs `_ and `Python Eggs `_" msgstr "" #: ../source/glossary.rst:49 @@ -864,7 +1092,12 @@ msgid "Extension Module" msgstr "" #: ../source/glossary.rst:52 -msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." +msgid "" +"A :term:`Module` written in the low-level language of the Python " +"implementation: C/C++ for Python, Java for Jython. Typically contained in a " +"single dynamically loadable pre-compiled file, e.g. a shared object (.so) " +"file for Python extensions on Unix, a DLL (given the .pyd extension) for " +"Python extensions on Windows, or a Java class file for Jython extensions." msgstr "" #: ../source/glossary.rst:59 @@ -872,7 +1105,12 @@ msgid "Known Good Set (KGS)" msgstr "" #: ../source/glossary.rst:62 -msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." +msgid "" +"A set of distributions at specified versions which are compatible with each " +"other. Typically a test suite will be run which passes all tests before a " +"specific set of packages is declared a known good set. This term is commonly " +"used by frameworks and toolkits which are comprised of multiple individual " +"distributions." msgstr "" #: ../source/glossary.rst:68 @@ -880,11 +1118,17 @@ msgid "Import Package" msgstr "" #: ../source/glossary.rst:71 -msgid "A Python module which can contain other modules or recursively, other packages." +msgid "" +"A Python module which can contain other modules or recursively, other " +"packages." msgstr "" #: ../source/glossary.rst:74 -msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." +msgid "" +"An import package is more commonly referred to with the single word \"package" +"\", but this guide will use the expanded term when more clarity is needed to " +"prevent confusion with a :term:`Distribution Package` which is also commonly " +"called a \"package\"." msgstr "" #: ../source/glossary.rst:78 @@ -892,7 +1136,9 @@ msgid "Module" msgstr "" #: ../source/glossary.rst:81 -msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." +msgid "" +"The basic unit of code reusability in Python, existing in one of two types: :" +"term:`Pure Module`, or :term:`Extension Module`." msgstr "" #: ../source/glossary.rst:84 @@ -900,7 +1146,9 @@ msgid "Package Index" msgstr "" #: ../source/glossary.rst:87 -msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." +msgid "" +"A repository of distributions with a web interface to automate :term:" +"`package ` discovery and consumption." msgstr "" #: ../source/glossary.rst:90 @@ -908,7 +1156,10 @@ msgid "Per Project Index" msgstr "" #: ../source/glossary.rst:93 -msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." +msgid "" +"A private or other non-canonical :term:`Package Index` indicated by a " +"specific :term:`Project` as the index preferred or required to resolve " +"dependencies of that project." msgstr "" #: ../source/glossary.rst:97 @@ -916,19 +1167,35 @@ msgid "Project" msgstr "" #: ../source/glossary.rst:100 -msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." +msgid "" +"A library, framework, script, plugin, application, or collection of data or " +"other resources, or some combination thereof that is intended to be packaged " +"into a :term:`Distribution `." msgstr "" #: ../source/glossary.rst:104 -msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." +msgid "" +"Since most projects create :term:`Distributions ` " +"using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:" +"`setuptools`, another practical way to define projects currently is " +"something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:" +"`setup.cfg` file at the root of the project source directory." msgstr "" #: ../source/glossary.rst:110 -msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." +msgid "" +"Python projects must have unique names, which are registered on :term:`PyPI " +"`. Each project will then contain one or more :" +"term:`Releases `, and each release may comprise one or more :term:" +"`distributions `." msgstr "" #: ../source/glossary.rst:115 -msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." +msgid "" +"Note that there is a strong convention to name a project after the name of " +"the package that is imported to run that project. However, this doesn't have " +"to hold true. It's possible to install a distribution from the project 'foo' " +"and have it provide a package importable only as 'bar'." msgstr "" #: ../source/glossary.rst:121 @@ -936,7 +1203,9 @@ msgid "Pure Module" msgstr "" #: ../source/glossary.rst:124 -msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." +msgid "" +"A :term:`Module` written in Python and contained in a single ``.py`` file " +"(and possibly associated ``.pyc`` and/or ``.pyo`` files)." msgstr "" #: ../source/glossary.rst:127 @@ -944,7 +1213,13 @@ msgid "Python Packaging Authority (PyPA)" msgstr "" #: ../source/glossary.rst:130 -msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." +msgid "" +"PyPA is a working group that maintains many of the relevant projects in " +"Python packaging. They maintain a site at https://www.pypa.io, host projects " +"on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python " +"Discourse forum `__." msgstr "" #: ../source/glossary.rst:139 @@ -952,7 +1227,10 @@ msgid "Python Package Index (PyPI)" msgstr "" #: ../source/glossary.rst:142 -msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." +msgid "" +"`PyPI `_ is the default :term:`Package Index` for the " +"Python community. It is open to all Python developers to consume and " +"distribute their distributions." msgstr "" #: ../source/glossary.rst:145 @@ -960,7 +1238,10 @@ msgid "pypi.org" msgstr "" #: ../source/glossary.rst:148 -msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." +msgid "" +"`pypi.org `_ is the domain name for the :term:`Python " +"Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi." +"python.org``, in 2017. It is powered by :ref:`warehouse`." msgstr "" #: ../source/glossary.rst:152 @@ -968,7 +1249,8 @@ msgid "pyproject.toml" msgstr "" #: ../source/glossary.rst:155 -msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." +msgid "" +"The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." msgstr "" #: ../source/glossary.rst:157 @@ -976,11 +1258,17 @@ msgid "Release" msgstr "" #: ../source/glossary.rst:160 -msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." +msgid "" +"A snapshot of a :term:`Project` at a particular point in time, denoted by a " +"version identifier." msgstr "" #: ../source/glossary.rst:163 -msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." +msgid "" +"Making a release may entail the publishing of multiple :term:`Distributions " +"`. For example, if version 1.0 of a project was " +"released, it could be available in both a source distribution format and a " +"Windows installer distribution format." msgstr "" #: ../source/glossary.rst:168 @@ -988,7 +1276,12 @@ msgid "Requirement" msgstr "" #: ../source/glossary.rst:171 -msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." +msgid "" +"A specification for a :term:`package ` to be " +"installed. :ref:`pip`, the :term:`PYPA ` " +"recommended installer, allows various forms of specification that can all be " +"considered a \"requirement\". For more information, see the :ref:`pip:pip " +"install` reference." msgstr "" #: ../source/glossary.rst:177 @@ -996,7 +1289,13 @@ msgid "Requirement Specifier" msgstr "" #: ../source/glossary.rst:180 -msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" +msgid "" +"A format used by :ref:`pip` to install packages from a :term:`Package " +"Index`. For an EBNF diagram of the format, see the `pkg_resources." +"Requirement `_ entry in the :ref:`setuptools` docs. For " +"example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the " +"project name, and the \">=1.3\" portion is the :term:`Version Specifier`" msgstr "" #: ../source/glossary.rst:187 @@ -1004,7 +1303,10 @@ msgid "Requirements File" msgstr "" #: ../source/glossary.rst:190 -msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." +msgid "" +"A file containing a list of :term:`Requirements ` that can be " +"installed using :ref:`pip`. For more information, see the :ref:`pip` docs " +"on :ref:`pip:Requirements Files`." msgstr "" #: ../source/glossary.rst:194 @@ -1018,7 +1320,9 @@ msgid "setup.cfg" msgstr "" #: ../source/glossary.rst:198 -msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." +msgid "" +"The project specification files for :ref:`distutils` and :ref:`setuptools`. " +"See also :term:`pyproject.toml`." msgstr "" #: ../source/glossary.rst:201 @@ -1026,7 +1330,10 @@ msgid "Source Archive" msgstr "" #: ../source/glossary.rst:204 -msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." +msgid "" +"An archive containing the raw source code for a :term:`Release`, prior to " +"creation of a :term:`Source Distribution ` or :term:`Built Distribution`." msgstr "" #: ../source/glossary.rst:208 @@ -1034,7 +1341,11 @@ msgid "Source Distribution (or \"sdist\")" msgstr "" #: ../source/glossary.rst:211 -msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." +msgid "" +"A :term:`distribution ` format (usually generated " +"using ``python setup.py sdist``) that provides metadata and the essential " +"source files needed for installing by a tool like :ref:`pip`, or for " +"generating a :term:`Built Distribution`." msgstr "" #: ../source/glossary.rst:216 @@ -1042,7 +1353,9 @@ msgid "System Package" msgstr "" #: ../source/glossary.rst:219 -msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." +msgid "" +"A package provided in a format native to the operating system, e.g. an rpm " +"or dpkg file." msgstr "" #: ../source/glossary.rst:222 @@ -1050,7 +1363,12 @@ msgid "Version Specifier" msgstr "" #: ../source/glossary.rst:225 -msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." +msgid "" +"The version component of a :term:`Requirement Specifier`. For example, the " +"\">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full " +"specification <440#version-specifiers>` of the specifiers that Python " +"packaging currently supports. Support for PEP440 was implemented in :ref:" +"`setuptools` v8.0 and :ref:`pip` v6.0." msgstr "" #: ../source/glossary.rst:231 @@ -1058,7 +1376,11 @@ msgid "Virtual Environment" msgstr "" #: ../source/glossary.rst:234 -msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgid "" +"An isolated Python environment that allows packages to be installed for use " +"by a particular application, rather than being installed system wide. For " +"more information, see the section on :ref:`Creating and using Virtual " +"Environments`." msgstr "" #: ../source/glossary.rst:238 @@ -1066,7 +1388,10 @@ msgid "Wheel" msgstr "" #: ../source/glossary.rst:241 -msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." +msgid "" +"A :term:`Built Distribution` format introduced by :pep:`427`, which is " +"intended to replace the :term:`Egg` format. Wheel is currently supported " +"by :ref:`pip`." msgstr "" #: ../source/glossary.rst:244 @@ -1074,7 +1399,11 @@ msgid "Working Set" msgstr "" #: ../source/glossary.rst:247 -msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." +msgid "" +"A collection of :term:`distributions ` available for " +"importing. These are the distributions that are on the `sys.path` variable. " +"At most, one :term:`Distribution ` for a project is " +"possible in a working set." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:3 @@ -1082,7 +1411,11 @@ msgid "Analyzing PyPI package downloads" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:5 -msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." +msgid "" +"This section covers how to use the public PyPI download statistics dataset " +"to learn more about downloads of a package (or packages) hosted on PyPI. For " +"example, you can use it to discover the distribution of Python versions used " +"to download a package." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:15 @@ -1095,11 +1428,17 @@ msgid "PyPI does not display download statistics for a number of reasons: [#]_" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:19 -msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." +msgid "" +"**Inefficient to make work with a Content Distribution Network (CDN):** " +"Download statistics change constantly. Including them in project pages, " +"which are heavily cached, would require invalidating the cache more often, " +"and reduce the overall effectiveness of the cache." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:24 -msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" +msgid "" +"**Highly inaccurate:** A number of things prevent the download counts from " +"being accurate, some of which include:" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:27 @@ -1107,7 +1446,8 @@ msgid "``pip``'s download cache (lowers download counts)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:28 -msgid "Internal or unofficial mirrors (can both raise or lower download counts)" +msgid "" +"Internal or unofficial mirrors (can both raise or lower download counts)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:29 @@ -1115,7 +1455,9 @@ msgid "Packages not hosted on PyPI (for comparisons sake)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:30 -msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" +msgid "" +"Unofficial scripts or attempts at download count inflation (raises download " +"counts)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:32 @@ -1123,11 +1465,17 @@ msgid "Known historical data quality issues (lowers download counts)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:34 -msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" +msgid "" +"**Not particularly useful:** Just because a project has been downloaded a " +"lot doesn't mean it's good; Similarly just because a project hasn't been " +"downloaded a lot doesn't mean it's bad!" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:38 -msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." +msgid "" +"In short, because it's value is low for various reasons, and the tradeoffs " +"required to make it work are high, it has been not an effective use of " +"limited resources." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:43 @@ -1135,7 +1483,10 @@ msgid "Public dataset" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:45 -msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." +msgid "" +"As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, " +"where they are stored as a public dataset." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:50 @@ -1143,7 +1494,13 @@ msgid "Getting set up" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:52 -msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" +msgid "" +"In order to use `Google BigQuery`_ to query the `public PyPI download " +"statistics dataset`_, you'll need a Google account and to enable the " +"BigQuery API on a Google Cloud Platform project. You can run the up to 1TB " +"of queries per month `using the BigQuery free tier without a credit card " +"`__" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:58 @@ -1155,11 +1512,16 @@ msgid "Create a new project." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:60 -msgid "Enable the `BigQuery API `__." +msgid "" +"Enable the `BigQuery API `__." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:63 -msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." +msgid "" +"For more detailed instructions on how to get started with BigQuery, check " +"out the `BigQuery quickstart guide `__." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:69 @@ -1167,7 +1529,12 @@ msgid "Data schema" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:71 -msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" +msgid "" +"Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` " +"table for each download. The table contains information about what file was " +"downloaded and how it was downloaded. Some useful columns from the `table " +"schema `__ include:" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 @@ -1250,11 +1617,16 @@ msgid "Useful queries" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:95 -msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." +msgid "" +"Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" " +"button." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:97 -msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." +msgid "" +"Note that the rows are stored in a partitioned, which helps limit the cost " +"of queries. These example queries analyze downloads from recent history by " +"filtering on the ``timestamp`` column." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:102 @@ -1262,7 +1634,9 @@ msgid "Counting package downloads" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:104 -msgid "The following query counts the total number of downloads for the project \"pytest\"." +msgid "" +"The following query counts the total number of downloads for the project " +"\"pytest\"." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:119 @@ -1277,7 +1651,9 @@ msgid "26190085" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:124 -msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." +msgid "" +"To only count downloads from pip, filter on the ``details.installer.name`` " +"column." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:142 @@ -1289,7 +1665,9 @@ msgid "Package downloads over time" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:148 -msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." +msgid "" +"To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also " +"filtering by this column reduces corresponding costs." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:168 @@ -1349,7 +1727,9 @@ msgid "Python versions over time" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:186 -msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." +msgid "" +"Extract the Python version from the ``details.python`` column. Warning: This " +"query processes over 500 GB of data." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:205 @@ -1409,7 +1789,12 @@ msgid "Caveats" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:223 -msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." +msgid "" +"In addition to the caveats listed in the background above, Linehaul suffered " +"from a bug which caused it to significantly under-report download statistics " +"prior to July 26, 2018. Downloads before this date are proportionally " +"accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total " +"numbers are lower than actual by an order of magnitude." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:231 @@ -1417,7 +1802,9 @@ msgid "Additional tools" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:233 -msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." +msgid "" +"Besides using the BigQuery console, there are some additional tools which " +"may be useful when analyzing download statistics." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:237 @@ -1425,7 +1812,10 @@ msgid "``google-cloud-bigquery``" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:239 -msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." +msgid "" +"You can also access the public PyPI download statistics dataset " +"programmatically via the BigQuery API and the `google-cloud-bigquery`_ " +"project, the official Python client library for BigQuery." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:267 @@ -1433,7 +1823,10 @@ msgid "``pypinfo``" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:269 -msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." +msgid "" +"`pypinfo`_ is a command-line tool which provides access to the dataset and " +"can generate several useful queries. For example, you can query the total " +"number of download for a package with the command ``pypinfo package_name``." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:273 @@ -1449,7 +1842,8 @@ msgid "``pandas-gbq``" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:297 -msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." +msgid "" +"The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:301 @@ -1458,11 +1852,15 @@ msgid "References" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:303 -msgid "`PyPI Download Counts deprecation email `__" +msgid "" +"`PyPI Download Counts deprecation email `__" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:304 -msgid "`PyPI BigQuery dataset announcement email `__" +msgid "" +"`PyPI BigQuery dataset announcement email `__" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:3 @@ -1470,7 +1868,11 @@ msgid "Creating and discovering plugins" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:5 -msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." +msgid "" +"Often when creating a Python application or library you'll want the ability " +"to provide customizations or extra features via **plugins**. Because Python " +"packages can be separately distributed, your application or library may want " +"to automatically **discover** all of the plugins available." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:10 @@ -1494,15 +1896,25 @@ msgid "Using naming convention" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:20 -msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" +msgid "" +"If all of the plugins for your application follow the same naming " +"convention, you can use :func:`pkgutil.iter_modules` to discover all of the " +"top-level modules that match the naming convention. For example, `Flask`_ " +"uses the naming convention ``flask_{plugin_name}``. If you wanted to " +"automatically discover all of the Flask plugins installed:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:38 -msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" +msgid "" +"If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins " +"installed then ``discovered_plugins`` would be:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:48 -msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." +msgid "" +"Using naming convention for plugins also allows you to query the Python " +"Package Index's `simple API`_ for all packages that conform to your naming " +"convention." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:59 @@ -1510,19 +1922,48 @@ msgid "Using namespace packages" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:61 -msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" +msgid "" +":doc:`Namespace packages ` can be used to " +"provide a convention for where to place plugins and also provides a way to " +"perform discovery. For example, if you make the sub-package ``myapp." +"plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once " +"installed, you can use :func:`pkgutil.iter_modules` to discover all modules " +"and packages installed under that namespace:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:89 -msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" +msgid "" +"Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` " +"causes it to only look for the modules directly under that namespace. For " +"example, if you have installed distributions that provide the modules " +"``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in " +"this case would be:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:101 -msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." +msgid "" +"This sample uses a sub-package as the namespace package (``myapp.plugins``), " +"but it's also possible to use a top-level package for this purpose (such as " +"``myapp_plugins``). How to pick the namespace to use is a matter of " +"preference, but it's not recommended to make your project's main top-level " +"package (``myapp`` in this case) a namespace package for the purpose of " +"plugins, as one bad plugin could cause the entire namespace to break which " +"would in turn make your project unimportable. For the \"namespace sub-package" +"\" approach to work, the plugin packages must omit the :file:`__init__.py` " +"for your top-level package directory (``myapp`` in this case) and include " +"the namespace-package style :file:`__init__.py` in the namespace sub-package " +"directory (``myapp/plugins``). This also means that plugins will need to " +"explicitly pass a list of packages to :func:`setup`'s ``packages`` argument " +"instead of using :func:`setuptools.find_packages`." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:115 -msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." +msgid "" +"Namespace packages are a complex feature and there are several different " +"ways to create them. It's highly recommended to read the :doc:`packaging-" +"namespace-packages` documentation and clearly document which approach is " +"preferred for plugins to your project." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:121 @@ -1530,31 +1971,50 @@ msgid "Using package metadata" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:123 -msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." +msgid "" +"`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :" +"func:`setup` in :file:`setup.py` plugins can register themselves for " +"discovery." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:128 -msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" +msgid "" +"For example if you have a package named ``myapp-plugin-a`` and it includes " +"in its :file:`setup.py`:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:139 -msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" +msgid "" +"Then you can discover and load all of the registered entry points by using :" +"func:`importlib.metadata.entry_points` (or the `backport`_ " +"``importlib_metadata >= 3.6`` for Python 3.6-3.9):" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:154 -msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" +msgid "" +"In this example, ``discovered_plugins`` would be a collection of type :class:" +"`importlib.metadata.EntryPoint`:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:163 -msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." +msgid "" +"Now the module of your choice can be imported by executing " +"``discovered_plugins['a'].load()``." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:166 -msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." +msgid "" +"The ``entry_point`` specification in :file:`setup.py` is fairly flexible and " +"has a lot of options. It's recommended to read over the entire section on :" +"doc:`entry points ` ." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:170 -msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." +msgid "" +"Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools " +"provide support for defining entry points." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:5 @@ -1562,15 +2022,25 @@ msgid "Packaging and distributing projects" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:7 -msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." +msgid "" +"This section covers the basics of how to configure, package and distribute " +"your own Python projects. It assumes that you are already familiar with the " +"contents of the :doc:`/tutorials/installing-packages` page." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:11 -msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." +msgid "" +"The section does *not* aim to cover best practices for Python project " +"development as a whole. For example, it does not provide guidance or tool " +"recommendations for version control, documentation, or testing." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:15 -msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." +msgid "" +"For more reference material, see :std:doc:`Building and Distributing " +"Packages ` in the :ref:`setuptools` docs, but note that " +"some advisory content there may be outdated. In the event of conflicts, " +"prefer the advice in the Python Packaging User Guide." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:25 @@ -1578,7 +2048,9 @@ msgid "Requirements for packaging and distributing" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:26 -msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." +msgid "" +"First, make sure you have already fulfilled the :ref:`requirements for " +"installing packages `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:29 @@ -1586,7 +2058,10 @@ msgid "Install \"twine\" [1]_:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:43 -msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." +msgid "" +"You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below " +"`)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:49 @@ -1598,7 +2073,11 @@ msgid "Initial files" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:58 -msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." +msgid "" +"The most important file is :file:`setup.py` which exists at the root of your " +"project directory. For an example, see the `setup.py `_ in the `PyPA sample project " +"`_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:63 @@ -1606,15 +2085,27 @@ msgid ":file:`setup.py` serves two primary functions:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:65 -msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." +msgid "" +"It's the file where various aspects of your project are configured. The " +"primary feature of :file:`setup.py` is that it contains a global ``setup()`` " +"function. The keyword arguments to this function are how specific details " +"of your project are defined. The most relevant arguments are explained in :" +"ref:`the section below `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:71 -msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." +msgid "" +"It's the command line interface for running various commands that relate to " +"packaging tasks. To get a listing of available commands, run ``python setup." +"py --help-commands``." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:79 -msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." +msgid "" +":file:`setup.cfg` is an ini file that contains option defaults for :file:" +"`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project " +"`_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:86 @@ -1622,15 +2113,31 @@ msgid "README.rst / README.md" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:88 -msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." +msgid "" +"All projects should contain a readme file that covers the goal of the " +"project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not " +"a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:" +"`long_description_content_type ` argument)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:95 -msgid "For an example, see `README.md `_ from the `PyPA sample project `_." +msgid "" +"For an example, see `README.md `_ from the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:99 -msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." +msgid "" +"Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:" +"`README.rst`, :file:`README.txt`, or :file:`README`) included in source " +"distributions by default. The built-in :ref:`distutils` library adopts this " +"behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ " +"will include a :file:`README.md` if found. If you are using setuptools, you " +"don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, " +"include it to be explicit." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:108 @@ -1638,15 +2145,23 @@ msgid "MANIFEST.in" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:110 -msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." +msgid "" +"A :file:`MANIFEST.in` is needed when you need to package additional files " +"that are not automatically included in a source distribution. For details " +"on writing a :file:`MANIFEST.in` file, including a list of what's included " +"by default, see \":ref:`Using MANIFEST.in`\"." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:115 -msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." +msgid "" +"For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:119 -msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." +msgid "" +":file:`MANIFEST.in` does not affect binary distributions such as wheels." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:122 @@ -1654,11 +2169,20 @@ msgid "LICENSE.txt" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:124 -msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." +msgid "" +"Every package should include a license file detailing the terms of " +"distribution. In many jurisdictions, packages without an explicit license " +"can not be legally used or distributed by anyone other than the copyright " +"holder. If you're unsure which license to choose, you can use resources such " +"as `GitHub's Choose a License `_ or consult a " +"lawyer." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:130 -msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." +msgid "" +"For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:135 @@ -1666,11 +2190,17 @@ msgid "" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:137 -msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." +msgid "" +"Although it's not required, the most common practice is to include your " +"Python modules and packages under a single top-level package that has the " +"same :ref:`name ` as your project, or something very close." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:141 -msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." +msgid "" +"For an example, see the `sample `_ package that's included in the `PyPA sample project " +"`_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:149 @@ -1678,11 +2208,18 @@ msgid "setup() args" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:151 -msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." +msgid "" +"As mentioned above, the primary feature of :file:`setup.py` is that it " +"contains a global ``setup()`` function. The keyword arguments to this " +"function are how specific details of your project are defined." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:155 -msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." +msgid "" +"The most relevant arguments are explained below. Most of the snippets given " +"are taken from the `setup.py `_ contained in the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:164 @@ -1690,11 +2227,16 @@ msgid "name" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:170 -msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" +msgid "" +"This is the name of your project, determining how your project is listed on :" +"term:`PyPI `. Per :pep:`508`, valid project " +"names must:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:174 -msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" +msgid "" +"Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), " +"and/or periods (``.``), and" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:176 @@ -1702,7 +2244,11 @@ msgid "Start & end with an ASCII letter or digit." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:178 -msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" +msgid "" +"Comparison of project names is case insensitive and treats arbitrarily-long " +"runs of underscores, hyphens, and/or periods as equal. For example, if you " +"register a project named ``cool-stuff``, users will be able to download it " +"or declare a dependency on it using any of the following spellings::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:190 @@ -1711,19 +2257,30 @@ msgid "version" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:196 -msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." +msgid "" +"This is the current version of your project, allowing your users to " +"determine whether or not they have the latest version, and to indicate which " +"specific versions they've tested their own software against." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:200 -msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." +msgid "" +"Versions are displayed on :term:`PyPI ` for " +"each release if you publish your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:203 -msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." +msgid "" +"See :ref:`Choosing a versioning scheme` for more information on ways to use " +"versions to convey compatibility information to your users." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:206 -msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." +msgid "" +"If the project code itself needs run-time access to the version, the " +"simplest way is to keep the version in both :file:`setup.py` and your code. " +"If you'd rather not duplicate the value, there are a few ways to manage " +"this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:214 @@ -1735,15 +2292,32 @@ msgid "Give a short and long description for your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:224 -msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." +msgid "" +"These values will be displayed on :term:`PyPI ` " +"if you publish your project. On ``pypi.org``, the user interface displays " +"``description`` in the grey banner and ``long_description`` in the section " +"named \"Project Description\"." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:229 -msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." +msgid "" +"``description`` is also displayed in lists of projects. For example, it's " +"visible in the search results pages such as https://pypi.org/search/?" +"q=jupyter, the front-page lists of trending projects and new releases, and " +"the list of projects you maintain within your account profile (such as " +"https://pypi.org/user/jaraco/)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:235 -msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." +msgid "" +"A `content type `_ can be specified with the " +"``long_description_content_type`` argument, which can be one of ``text/" +"plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no " +"formatting, `reStructuredText (reST) `_, and the Github-flavored " +"Markdown dialect of `Markdown `_ respectively." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:245 @@ -1767,11 +2341,21 @@ msgid "license" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:273 -msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." +msgid "" +"The ``license`` argument doesn't have to indicate the license under which " +"your package is being released, although you may optionally do so if you " +"want. If you're using a standard, well-known license, then your main " +"indication can and should be via the ``classifiers`` argument. Classifiers " +"exist for all major open-source licenses." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:279 -msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." +msgid "" +"The \"license\" argument is more typically used to indicate differences from " +"well-known licenses, or to include your own, unique license. As a general " +"rule, it's a good idea to use a standard, well-known license, both to avoid " +"confusion and because some organizations avoid software whose license is " +"unapproved." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:287 @@ -1779,11 +2363,18 @@ msgid "classifiers" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:316 -msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." +msgid "" +"Provide a list of classifiers that categorize your project. For a full " +"listing, see https://pypi.org/classifiers/." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:319 -msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." +msgid "" +"Although the list of classifiers is often used to declare what Python " +"versions a project supports, this information is only used for searching & " +"browsing projects on PyPI, not for installing projects. To actually " +"restrict what Python versions a project can be installed on, use the :ref:" +"`python_requires` argument." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:327 @@ -1799,7 +2390,11 @@ msgid "project_urls" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:349 -msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." +msgid "" +"List additional relevant URLs about your project. This is the place to link " +"to bug trackers, source repositories, or where to support package " +"development. The string of the key is the exact text that will be displayed " +"on PyPI." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:355 @@ -1807,7 +2402,13 @@ msgid "packages" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:361 -msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." +msgid "" +"Set ``packages`` to a list of all :term:`packages ` in your " +"project, including their subpackages, sub-subpackages, etc. Although the " +"packages can be listed manually, ``setuptools.find_packages()`` finds them " +"automatically. Use the ``include`` keyword argument to find only the given " +"packages. Use the ``exclude`` keyword argument to omit packages that are " +"not intended to be released and installed." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:370 @@ -1815,15 +2416,23 @@ msgid "py_modules" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:376 -msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." +msgid "" +"If your project contains any single-file Python modules that aren't part of " +"a package, set ``py_modules`` to a list of the names of the modules (minus " +"the ``.py`` extension) in order to make :ref:`setuptools` aware of them." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:388 -msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgid "" +"\"install_requires\" should be used to specify what dependencies a project " +"minimally needs to run. When the project is installed by :ref:`pip`, this is " +"the specification that is used to install its dependencies." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:392 -msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." +msgid "" +"For more on using \"install_requires\" see :ref:`install_requires vs " +"Requirements files`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:398 @@ -1831,11 +2440,17 @@ msgid "python_requires" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:400 -msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" +msgid "" +"If your project only runs on certain Python versions, setting the " +"``python_requires`` argument to the appropriate :pep:`440` version specifier " +"string will prevent :ref:`pip` from installing the project on other Python " +"versions. For example, if your package is for Python 3+ only, write::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:407 -msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" +msgid "" +"If your package is for Python 2.6, 2.7, and all versions of Python 3 " +"starting with 3.3, write::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:412 @@ -1843,11 +2458,20 @@ msgid "And so on." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:416 -msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." +msgid "" +"Support for this feature is relatively recent. Your project's source " +"distributions and wheels (see :ref:`Packaging Your Project`) must be built " +"using at least version 24.2.0 of :ref:`setuptools` in order for the " +"``python_requires`` argument to be recognized and the appropriate metadata " +"generated." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:422 -msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." +msgid "" +"In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the " +"``python_requires`` metadata. Users with earlier versions of pip will be " +"able to download & install projects on any Python version regardless of the " +"projects' ``python_requires`` values." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:431 @@ -1855,15 +2479,25 @@ msgid "package_data" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:440 -msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." +msgid "" +"Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the " +"package’s implementation, or text files containing documentation that might " +"be of interest to programmers using the package. These files are called " +"\"package data\"." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:445 -msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." +msgid "" +"The value must be a mapping from package name to a list of relative path " +"names that should be copied into the package. The paths are interpreted as " +"relative to the directory containing the package." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:449 -msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." +msgid "" +"For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:457 @@ -1871,19 +2505,39 @@ msgid "data_files" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:463 -msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." +msgid "" +"Although configuring :ref:`Package Data` is sufficient for most needs, in " +"some cases you may need to place data files *outside* of your :term:" +"`packages `. The ``data_files`` directive allows you to do " +"that. It is mostly useful if you need to install files which are used by " +"other programs, which may be unaware of Python packages." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:469 -msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." +msgid "" +"Each ``(directory, files)`` pair in the sequence specifies the installation " +"directory and the files to install there. The ``directory`` must be a " +"relative path (although this may change in the future, see `wheel Issue #92 " +"`_). and it is interpreted relative " +"to the installation prefix (Python’s ``sys.prefix`` for a default " +"installation; ``site.USER_BASE`` for a user installation). Each file name in " +"``files`` is interpreted relative to the :file:`setup.py` script at the top " +"of the project source distribution." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:479 -msgid "For more information see the distutils section on `Installing Additional Files `_." +msgid "" +"For more information see the distutils section on `Installing Additional " +"Files `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:484 -msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." +msgid "" +"When installing packages as egg, ``data_files`` is not supported. So, if " +"your project uses :ref:`setuptools`, you must use ``pip`` to install it. " +"Alternatively, if you must use ``python setup.py``, then you need to pass " +"the ``--old-and-unmanageable`` option." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:491 @@ -1891,7 +2545,11 @@ msgid "scripts" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:493 -msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." +msgid "" +"Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made " +"scripts to install, the recommended approach to achieve cross-platform " +"compatibility is to use :ref:`console_scripts` entry points (see below)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:500 @@ -1899,11 +2557,17 @@ msgid "entry_points" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:509 -msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." +msgid "" +"Use this keyword to specify any plugins that your project provides for any " +"named entry points that may be defined by your project or others that you " +"depend on." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:512 -msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." +msgid "" +"For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:516 @@ -1915,11 +2579,20 @@ msgid "console_scripts" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:531 -msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgid "" +"Use \"console_script\" `entry points `_ to " +"register your script interfaces. You can then let the toolchain handle the " +"work of turning these interfaces into actual scripts [2]_. The scripts will " +"be generated during the install of your :term:`distribution `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:538 -msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." +msgid "" +"For more information, see `Automatic Script Creation `_ from " +"the `setuptools docs `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:545 @@ -1931,7 +2604,12 @@ msgid "Standards compliance for interoperability" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:550 -msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." +msgid "" +"Different Python projects may use different versioning schemes based on the " +"needs of that particular project, but all of them are required to comply " +"with the flexible :pep:`public version scheme <440#public-version-" +"identifiers>` specified in :pep:`440` in order to be supported in tools and " +"libraries like ``pip`` and ``setuptools``." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:556 @@ -1939,7 +2617,11 @@ msgid "Here are some examples of compliant version numbers::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:567 -msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." +msgid "" +"To further accommodate historical variations in approaches to version " +"numbering, :pep:`440` also defines a comprehensive technique for :pep:" +"`version normalisation <440#normalization>` that maps variant spellings of " +"different version numbers to a standardised canonical form." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:573 @@ -1951,11 +2633,16 @@ msgid "Semantic versioning (preferred)" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:578 -msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." +msgid "" +"For new projects, the recommended versioning scheme is based on `Semantic " +"Versioning `_, but adopts a different approach to " +"handling pre-releases and build metadata." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:582 -msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" +msgid "" +"The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE " +"numbering scheme, where the project author increments:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:585 @@ -1963,7 +2650,9 @@ msgid "MAJOR version when they make incompatible API changes," msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:586 -msgid "MINOR version when they add functionality in a backwards-compatible manner, and" +msgid "" +"MINOR version when they add functionality in a backwards-compatible manner, " +"and" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:587 @@ -1971,11 +2660,17 @@ msgid "MAINTENANCE version when they make backwards-compatible bug fixes." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:589 -msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." +msgid "" +"Adopting this approach as a project author allows users to make use of :pep:`" +"\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= " +"X.Y`` requires at least release X.Y, but also allows any later release with " +"a matching MAJOR version." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:594 -msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." +msgid "" +"Python projects adopting semantic versioning should abide by clauses 1-8 of " +"the `Semantic Versioning 2.0.0 specification `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:598 @@ -1983,15 +2678,23 @@ msgid "Date based versioning" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:600 -msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." +msgid "" +"Semantic versioning is not a suitable choice for all projects, such as those " +"with a regular time based release cadence and a deprecation process that " +"provides warnings for a number of releases prior to removal of a feature." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:604 -msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." +msgid "" +"A key advantage of date based versioning is that it is straightforward to " +"tell how old the base feature set of a particular release is given just the " +"version number." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:607 -msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." +msgid "" +"Version numbers for date based projects typically take the form of YEAR." +"MONTH (for example, ``12.04``, ``15.10``)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:611 @@ -1999,11 +2702,16 @@ msgid "Serial versioning" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:613 -msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." +msgid "" +"This is the simplest possible versioning scheme, and consists of a single " +"number which is incremented every release." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:616 -msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." +msgid "" +"While serial versioning is very easy to manage as a developer, it is the " +"hardest to track as an end user, as serial version numbers convey little or " +"no information regarding API backwards compatibility." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:621 @@ -2011,7 +2719,11 @@ msgid "Hybrid schemes" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:623 -msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." +msgid "" +"Combinations of the above schemes are possible. For example, a project may " +"combine date based versioning with serial versioning to create a YEAR.SERIAL " +"numbering scheme that readily conveys the approximate age of a release, but " +"doesn't otherwise commit to a particular release cadence within the year." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:629 @@ -2019,7 +2731,9 @@ msgid "Pre-release versioning" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:631 -msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" +msgid "" +"Regardless of the base versioning scheme, pre-releases for a given final " +"release may be published as:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:634 @@ -2039,7 +2753,9 @@ msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:639 -msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." +msgid "" +"``pip`` and other modern Python package installers ignore pre-releases by " +"default when deciding which versions of dependencies to install." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:644 @@ -2047,11 +2763,19 @@ msgid "Local version identifiers" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:646 -msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." +msgid "" +"Public version identifiers are designed to support distribution via :term:" +"`PyPI `. Python's software distribution tools " +"also support the notion of a :pep:`local version identifier <440#local-" +"version-identifiers>`, which can be used to identify local development " +"builds not intended for publication, or modified variants of a release " +"maintained by a redistributor." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:653 -msgid "A local version identifier takes the form ``+``. For example::" +msgid "" +"A local version identifier takes the form ``" +"+``. For example::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:661 @@ -2059,7 +2783,10 @@ msgid "Working in \"development mode\"" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:663 -msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." +msgid "" +"Although not required, it's common to locally install your project in " +"\"editable\" or \"develop\" mode while you're working on it. This allows " +"your project to be both installed and editable in project form." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:667 @@ -2067,31 +2794,56 @@ msgid "Assuming you're in the root of your project directory, then run:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:674 -msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." +msgid "" +"Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` " +"refers to the current working directory, so together, it means to install " +"the current directory (i.e. your project) in editable mode. This will also " +"install any dependencies declared with \"install_requires\" and any scripts " +"declared with \"console_scripts\". Dependencies will be installed in the " +"usual, non-editable mode." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:680 -msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" +msgid "" +"It's fairly common to also want to install some of your dependencies in " +"editable mode as well. For example, supposing your project requires \"foo\" " +"and \"bar\", but you want \"bar\" installed from VCS in editable mode, then " +"you could construct a requirements file like so::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:688 -msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." +msgid "" +"The first line says to install your project and any dependencies. The second " +"line overrides the \"bar\" dependency, such that it's fulfilled from VCS, " +"not PyPI." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:692 -msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" +msgid "" +"If, however, you want \"bar\" installed from a local directory in editable " +"mode, the requirements file should look like this, with the local paths at " +"the top of the file::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:697 -msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." +msgid "" +"Otherwise, the dependency will be fulfilled from PyPI, due to the " +"installation order of the requirements file. For more on requirements " +"files, see the :ref:`Requirements File ` section in " +"the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:701 -msgid "Lastly, if you don't want to install any dependencies at all, you can run::" +msgid "" +"Lastly, if you don't want to install any dependencies at all, you can run::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:706 -msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." +msgid "" +"For more information, see the `Development Mode `_ section of the " +"`setuptools docs `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:713 @@ -2099,11 +2851,17 @@ msgid "Packaging your project" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:715 -msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." +msgid "" +"To have your project installable from a :term:`Package Index` like :term:" +"`PyPI `, you'll need to create a :term:" +"`Distribution ` (aka \":term:`Package `\") for your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:720 -msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" +msgid "" +"Before you can build wheels and sdists for your project, you'll need to " +"install the ``build`` package:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:737 @@ -2111,11 +2869,18 @@ msgid "Source distributions" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:739 -msgid "Minimally, you should create a :term:`Source Distribution `:" +msgid "" +"Minimally, you should create a :term:`Source Distribution `:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:755 -msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." +msgid "" +"A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built " +"Distribution`), and requires a build step when installed by pip. Even if " +"the distribution is pure Python (i.e. contains no extensions), it still " +"involves a build step to build out the installation metadata from :file:" +"`setup.py` and/or :file:`setup.cfg`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:763 @@ -2123,23 +2888,36 @@ msgid "Wheels" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:765 -msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." +msgid "" +"You should also create a wheel for your project. A wheel is a :term:`built " +"package ` that can be installed without needing to go " +"through the \"build\" process. Installing wheels is substantially faster for " +"the end user than installing from a source distribution." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:770 -msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." +msgid "" +"If your project is pure Python then you'll be creating a :ref:`\"Pure Python " +"Wheel\" (see section below) `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:773 -msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." +msgid "" +"If your project contains compiled extensions, then you'll be creating what's " +"called a :ref:`*Platform Wheel* (see section below) `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:776 -msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" +msgid "" +"If your project also supports Python 2 *and* contains no C extensions, then " +"you should create what's called a *Universal Wheel* by adding the following " +"to your :file:`setup.cfg` file:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:785 -msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." +msgid "" +"Only use this setting if your project does not have any C extensions *and* " +"supports Python 2 and 3." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:792 @@ -2147,7 +2925,9 @@ msgid "Pure Python Wheels" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:794 -msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." +msgid "" +"*Pure Python Wheels* contain no compiled extensions, and therefore only " +"require a single Python wheel." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:797 @@ -2156,11 +2936,16 @@ msgid "To build the wheel:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:811 -msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." +msgid "" +"The ``wheel`` package will detect that the code is pure Python, and build a " +"wheel that's named such that it's usable on any Python 3 installation. For " +"details on the naming of wheel files, see :pep:`425`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:815 -msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." +msgid "" +"If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both " +"files for you; this is useful when you don't need multiple wheels." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:821 @@ -2168,15 +2953,23 @@ msgid "Platform Wheels" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:823 -msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." +msgid "" +"*Platform Wheels* are wheels that are specific to a certain platform like " +"Linux, macOS, or Windows, usually due to containing compiled extensions." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:841 -msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." +msgid "" +"The ``wheel`` package will detect that the code is not pure Python, and " +"build a wheel that's named such that it's only usable on the platform that " +"it was built on. For details on the naming of wheel files, see :pep:`425`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:847 -msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." +msgid "" +":term:`PyPI ` currently supports uploads of " +"platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. " +"Details of the latter are defined in :pep:`513`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:855 @@ -2184,23 +2977,45 @@ msgid "Uploading your Project to PyPI" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:857 -msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." +msgid "" +"When you ran the command to create your distribution, a new directory ``dist/" +"`` was created under your project's root directory. That's where you'll find " +"your distribution file(s) to upload." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:861 -msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." +msgid "" +"These files are only created when you run the command to create your " +"distribution. This means that any time you change the source of your project " +"or the configuration in your :file:`setup.py` file, you will need to rebuild " +"these files again before you can distribute the changes to PyPI." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:866 -msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." +msgid "" +"Before releasing on main PyPI repo, you might prefer training with the `PyPI " +"test site `_ which is cleaned on a semi regular " +"basis. See :ref:`using-test-pypi` on how to setup your configuration in " +"order to use it." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:871 -msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." +msgid "" +"In other resources you may encounter references to using ``python setup.py " +"register`` and ``python setup.py upload``. These methods of registering and " +"uploading a package are **strongly discouraged** as it may use a plaintext " +"HTTP or unverified HTTPS connection on some Python versions, allowing your " +"username and password to be intercepted during transmission." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:877 -msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" +msgid "" +"The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to " +"ensure safety of all users, certain kinds of URLs and directives are " +"forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** " +"trying to upload your distribution, you should check to see if your brief / " +"long descriptions provided in :file:`setup.py` are valid. You can do this " +"by running :std:doc:`twine check ` on your package files::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:888 @@ -2208,23 +3023,35 @@ msgid "Create an account" msgstr "Criar uma conta" #: ../source/guides/distributing-packages-using-setuptools.rst:890 -msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." +msgid "" +"First, you need a :term:`PyPI ` user account. " +"You can create an account `using the form on the PyPI website `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:894 -msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." +msgid "" +"Now you'll create a PyPI `API token`_ so you will be able to securely upload " +"your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:897 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." +msgid "" +"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " +"token`_; don't limit its scope to a particular project, since you are " +"creating a new project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:901 -msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgid "" +"**Don't close the page until you have copied and saved the token — you won't " +"see that token again.**" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:904 -msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" +msgid "" +"To avoid having to copy and paste the token every time you upload, you can " +"create a :file:`$HOME/.pypirc` file:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:913 @@ -2235,7 +3062,8 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:70 #: ../source/guides/migrating-to-pypi-org.rst:109 #: ../source/guides/using-testpypi.rst:83 -msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." +msgid "" +"For more details, see the :ref:`specification ` for :file:`.pypirc`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:921 @@ -2243,28 +3071,46 @@ msgid "Upload your distributions" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:923 -msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." +msgid "" +"Once you have an account you can upload your distributions to :term:`PyPI " +"` using :ref:`twine`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:926 -msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." +msgid "" +"The process for uploading a release is the same regardless of whether or not " +"the project already exists on PyPI - if it doesn't exist yet, it will be " +"automatically created when the first release is uploaded." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:930 -msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." +msgid "" +"For the second and subsequent releases, PyPI only requires that the version " +"number of the new release differ from any previous releases." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:937 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgid "" +"You can see if your package has successfully uploaded by navigating to the " +"URL ``https://pypi.org/project/`` where ``sampleproject`` is " +"the name of your project that you uploaded. It may take a minute or two for " +"your project to appear on the site." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:944 #: ../source/tutorials/installing-packages.rst:663 -msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." +msgid "" +"Depending on your platform, this may require root or Administrator access. :" +"ref:`pip` is currently considering changing this by `making user installs " +"the default behavior `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:950 -msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." +msgid "" +"Specifically, the \"console_script\" approach generates ``.exe`` files on " +"Windows, which are necessary because the OS special-cases ``.exe`` files. " +"Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for " +"Windows <397>` allow scripts to be used in many cases, but not all." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:5 @@ -2272,19 +3118,30 @@ msgid "Dropping support for older Python versions" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:7 -msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." +msgid "" +"Dropping support for older Python versions is supported by the standard :ref:" +"`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:9 -msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." +msgid "" +"Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification " +"by matching the current Python runtime and comparing it with the required " +"version in the package metadata. If they do not match, it will attempt to " +"install the last package distribution that supported that Python runtime." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:12 -msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." +msgid "" +"This mechanism can be used to drop support for older Python versions, by " +"amending the \"Requires-Python\" attribute in the package metadata." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:14 -msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." +msgid "" +"This guide is specifically for users of :ref:`setuptools`, other packaging " +"tools such as ``flit`` may offer similar functionality but users will need " +"to consult relevant documentation." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:17 @@ -2304,7 +3161,9 @@ msgid "The latest version of :ref:`twine` is used to upload the package," msgstr "" #: ../source/guides/dropping-older-python-versions.rst:23 -msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." +msgid "" +"The user installing the package has at least Pip 9.0, or a client that " +"supports the Metadata 1.2 specification." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:26 @@ -2312,15 +3171,26 @@ msgid "Dealing with the universal wheels" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:28 -msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." +msgid "" +"Traditionally, projects providing Python code that is semantically " +"compatible with both Python 2 and Python 3, produce :term:`wheels ` " +"that have a ``py2.py3`` tag in their names. When dropping support for Python " +"2, it is important not to forget to change this tag to just ``py3``. It is " +"often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` " +"section by setting ``universal = 1`` if they use setuptools." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:36 -msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" +msgid "" +"If you use this method, either remove this option or section, or explicitly " +"set ``universal`` to ``0``:" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:48 -msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." +msgid "" +"Since it is possible to override the :file:`setup.cfg` settings via CLI " +"flags, make sure that your scripts don't have ``--universal`` in your " +"package creation scripts." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:53 @@ -2332,7 +3202,9 @@ msgid "1. Download the newest version of Setuptools" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:58 -msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." +msgid "" +"Ensure that before you generate source distributions or binary " +"distributions, you update Setuptools and install twine." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:60 @@ -2348,7 +3220,9 @@ msgid "2. Specify the version ranges for supported Python distributions" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:79 -msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." +msgid "" +"You can specify version ranges and exclusion rules, such as at least Python " +"3. Or, Python 2.7, 3.4 and beyond." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:81 @@ -2364,7 +3238,10 @@ msgid "Examples::" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:86 -msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." +msgid "" +"The way to set those values is within the call to ``setup`` within your :" +"file:`setup.py` script. This will insert the ``Requires-Python`` metadata " +"values based on the argument you provide in ``python_requires``." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:101 @@ -2372,11 +3249,16 @@ msgid "3. Validating the Metadata before publishing" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:103 -msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." +msgid "" +"Within a Python source package (the zip or the tar-gz file you download) is " +"a text file called PKG-INFO." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:105 -msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." +msgid "" +"This file is generated by Distutils or :ref:`setuptools` when it generates " +"the source package. The file contains a set of keys and values, the list of " +"keys is part of the PyPa standard metadata format." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:108 @@ -2388,11 +3270,14 @@ msgid "Validate that the following is in place, before publishing the package:" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:114 -msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." +msgid "" +"If you have upgraded correctly, the Metadata-Version value should be 1.2 or " +"higher." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:115 -msgid "The Requires-Python field is set and matches your specification in setup.py." +msgid "" +"The Requires-Python field is set and matches your specification in setup.py." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:118 @@ -2400,7 +3285,9 @@ msgid "4. Using Twine to publish" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:120 -msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." +msgid "" +"Twine has a number of advantages, apart from being faster it is now the " +"supported method for publishing packages." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:122 @@ -2412,7 +3299,9 @@ msgid "Dropping a Python release" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:127 -msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." +msgid "" +"Once you have published a package with the Requires-Python metadata, you can " +"then make a further update removing that Python runtime from support." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:129 @@ -2420,11 +3309,17 @@ msgid "It must be done in this order for the automated fallback to work." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:131 -msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." +msgid "" +"For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 " +"of your package." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:133 -msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." +msgid "" +"If you were then to update the version string to \">=3.5\", and publish a " +"new version 2.0.0 of your package, any users running Pip 9.0+ from version " +"2.7 will have version 1.0.0 of the package installed, and any >=3.5 users " +"will receive version 2.0.0." msgstr "" #: ../source/guides/hosting-your-own-index.rst:5 @@ -2432,15 +3327,25 @@ msgid "Hosting your own simple repository" msgstr "" #: ../source/guides/hosting-your-own-index.rst:8 -msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." +msgid "" +"If you wish to host your own simple repository [1]_, you can either use a " +"software package like `devpi`_ or you can use simply create the proper " +"directory structure and use any web server that can serve static files and " +"generate an autoindex." msgstr "" #: ../source/guides/hosting-your-own-index.rst:13 -msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" +msgid "" +"In either case, since you'll be hosting a repository that is likely not in " +"your user's default repositories, you should instruct them in your project's " +"description to configure their installer appropriately. For example with pip:" msgstr "" #: ../source/guides/hosting-your-own-index.rst:29 -msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." +msgid "" +"In addition, it is **highly** recommended that you serve your repository " +"with valid HTTPS. At this time, the security of your user's installations " +"depends on all repositories using a valid HTTPS setup." msgstr "" #: ../source/guides/hosting-your-own-index.rst:35 @@ -2448,34 +3353,45 @@ msgid "\"Manual\" repository" msgstr "" #: ../source/guides/hosting-your-own-index.rst:37 -msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" +msgid "" +"The directory layout is fairly simple, within a root directory you need to " +"create a directory for each project. This directory should be the normalized " +"name (as defined by :pep:`503`) of the project. Within each of these " +"directories simply place each of the downloadable files. If you have the " +"projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the " +"version 0.1) You should end up with a structure that looks like::" msgstr "" #: ../source/guides/hosting-your-own-index.rst:51 -msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." +msgid "" +"Once you have this layout, simply configure your webserver to serve the root " +"directory with autoindex enabled. For an example using the built in Web " +"server in `Twisted`_, you would simply run ``twistd -n web --path .`` and " +"then instruct users to add the URL to their installer's configuration." msgstr "" #: ../source/guides/hosting-your-own-index.rst:58 -msgid "For complete documentation of the simple repository protocol, see :pep:`503`." +msgid "" +"For complete documentation of the simple repository protocol, see :pep:`503`." msgstr "" -#: ../source/guides/index.rst:8 #: ../source/guides/index.rst:8 msgid "Installing Packages:" msgstr "" -#: ../source/guides/index.rst:20 #: ../source/guides/index.rst:20 msgid "Building and Publishing Projects:" msgstr "" -#: ../source/guides/index.rst:38 #: ../source/guides/index.rst:38 msgid "Miscellaneous:" msgstr "" #: ../source/guides/index.rst:4 -msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." +msgid "" +"**Guides** are focused on accomplishing a specific task and assume that you " +"are already familiar with the basics of Python packaging. If you're looking " +"for an introduction to packaging, see :doc:`/tutorials/index`." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:5 @@ -2488,7 +3404,10 @@ msgid "2014-12-24" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:14 -msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." +msgid "" +"Mirroring or caching of PyPI can be used to speed up local package " +"installation, allow offline work, handle corporate firewalls or just plain " +"Internet flakiness." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:17 @@ -2500,11 +3419,15 @@ msgid "pip provides local caching options," msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:20 -msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" +msgid "" +"devpi provides higher-level caching option, potentially shared amongst many " +"users or machines, and" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:22 -msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." +msgid "" +"bandersnatch provides a local complete mirror of all PyPI :term:`packages " +"`." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:27 @@ -2512,15 +3435,23 @@ msgid "Caching with pip" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:29 -msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" +msgid "" +"pip provides a number of facilities for speeding up installation by using " +"local cached copies of :term:`packages `:" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:32 -msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." +msgid "" +"`Fast & local installs `_ by downloading all the requirements for a project and " +"then pointing pip at those downloaded files instead of going to PyPI." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:36 -msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" +msgid "" +"A variation on the above which pre-builds the installation files for the " +"requirements using `python -m pip wheel `_::" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:45 @@ -2528,7 +3459,10 @@ msgid "Caching with devpi" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:47 -msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." +msgid "" +"devpi is a caching proxy server which you run on your laptop, or some other " +"machine you know will always be available to you. See the `devpi " +"documentation for getting started`__." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:55 @@ -2536,11 +3470,18 @@ msgid "Complete mirror with bandersnatch" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:57 -msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." +msgid "" +"bandersnatch will set up a complete local mirror of all PyPI :term:`packages " +"` (externally-hosted packages are not mirrored). See " +"the `bandersnatch documentation for getting that going`__." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:63 -msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." +msgid "" +"A benefit of devpi is that it will create a mirror which includes :term:" +"`packages ` that are external to PyPI, unlike " +"bandersnatch which will only cache :term:`packages ` " +"hosted on PyPI." msgstr "" #: ../source/guides/installing-scientific-packages.rst:5 @@ -2548,19 +3489,38 @@ msgid "Installing scientific packages" msgstr "" #: ../source/guides/installing-scientific-packages.rst:11 -msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." +msgid "" +"Scientific software tends to have more complex dependencies than most, and " +"it will often have multiple build options to take advantage of different " +"kinds of hardware, or to interoperate with different pieces of external " +"software." msgstr "" #: ../source/guides/installing-scientific-packages.rst:16 -msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." +msgid "" +"In particular, `NumPy `__, which provides the basis " +"for most of the software in the `scientific Python stack `__ can be configured to interoperate with " +"different FORTRAN libraries, and can take advantage of different levels of " +"vectorised instructions available in modern CPUs." msgstr "" #: ../source/guides/installing-scientific-packages.rst:22 -msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." +msgid "" +"Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built " +"32-bit and 64-bit binaries in the ``wheel`` format are available for all " +"major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, " +"that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, " +"so they may not provide optimal linear algebra performance." msgstr "" #: ../source/guides/installing-scientific-packages.rst:29 -msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." +msgid "" +"There are a number of alternative options for obtaining scientific Python " +"libraries (or any other Python libraries that require a compilation " +"environment to install from source and don't provide pre-built wheel files " +"on PyPI)." msgstr "" #: ../source/guides/installing-scientific-packages.rst:35 @@ -2568,7 +3528,12 @@ msgid "Building from source" msgstr "" #: ../source/guides/installing-scientific-packages.rst:37 -msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." +msgid "" +"The same complexity which makes it difficult to distribute NumPy (and many " +"of the projects that depend on it) as wheel files also make them difficult " +"to build from source yourself. However, for intrepid folks that are willing " +"to spend the time wrangling compilers and linkers for both C and FORTRAN, " +"building from source is always an option." msgstr "" #: ../source/guides/installing-scientific-packages.rst:45 @@ -2576,11 +3541,18 @@ msgid "Linux distribution packages" msgstr "" #: ../source/guides/installing-scientific-packages.rst:47 -msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." +msgid "" +"For Linux users, the system package manager will often have pre-compiled " +"versions of various pieces of scientific software, including NumPy and other " +"parts of the scientific Python stack." msgstr "" #: ../source/guides/installing-scientific-packages.rst:51 -msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." +msgid "" +"If using versions which may be several months old is acceptable, then this " +"is likely to be a good option (just make sure to allow access to " +"distributions installed into the system Python when using virtual " +"environments)." msgstr "" #: ../source/guides/installing-scientific-packages.rst:57 @@ -2588,23 +3560,42 @@ msgid "Windows installers" msgstr "" #: ../source/guides/installing-scientific-packages.rst:59 -msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." +msgid "" +"Many Python projects that don't (or can't) currently publish wheel files at " +"least publish Windows installers, either on PyPI or on their project " +"download page. Using these installers allows users to avoid the need to set " +"up a suitable environment to build extensions locally." msgstr "" #: ../source/guides/installing-scientific-packages.rst:64 -msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." +msgid "" +"The extensions provided in these installers are typically compatible with " +"the CPython Windows installers published on python.org." msgstr "" #: ../source/guides/installing-scientific-packages.rst:67 -msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." +msgid "" +"For projects which don't provide their own Windows installers (and even some " +"which do), Christoph Gohlke at the University of California provides a " +"`collection of Windows installers `__. Many Python users on Windows have reported a positive experience with " +"these prebuilt versions." msgstr "" #: ../source/guides/installing-scientific-packages.rst:73 -msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." +msgid "" +"As with Linux system packages, the Windows installers will only install into " +"a system Python installation - they do not support installation in virtual " +"environments. Allowing access to distributions installed into the system " +"Python when using virtual environments is a common approach to working " +"around this limitation." msgstr "" #: ../source/guides/installing-scientific-packages.rst:79 -msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." +msgid "" +"The :term:`Wheel` project also provides a :command:`wheel convert` " +"subcommand that can convert a Windows :command:`bdist_wininst` installer to " +"a wheel." msgstr "" #: ../source/guides/installing-scientific-packages.rst:86 @@ -2612,11 +3603,18 @@ msgid "macOS installers and package managers" msgstr "" #: ../source/guides/installing-scientific-packages.rst:88 -msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." +msgid "" +"Similar to the situation on Windows, many projects (including NumPy) publish " +"macOS installers that are compatible with the macOS CPython binaries " +"published on python.org." msgstr "" #: ../source/guides/installing-scientific-packages.rst:92 -msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" +msgid "" +"macOS users also have access to Linux distribution style package managers " +"such as ``MacPorts``. The SciPy site has more details on using MacPorts to " +"install the `scientific Python stack `__" msgstr "" #: ../source/guides/installing-scientific-packages.rst:99 @@ -2624,11 +3622,16 @@ msgid "SciPy distributions" msgstr "" #: ../source/guides/installing-scientific-packages.rst:101 -msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." +msgid "" +"The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use " +"and update format." msgstr "" #: ../source/guides/installing-scientific-packages.rst:105 -msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." +msgid "" +"Some of these distributions may not be compatible with the standard ``pip`` " +"and ``virtualenv`` based toolchain." msgstr "" #: ../source/guides/installing-scientific-packages.rst:109 @@ -2637,11 +3640,25 @@ msgid "Spack" msgstr "" #: ../source/guides/installing-scientific-packages.rst:110 -msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." +msgid "" +"`Spack `_ is a flexible package manager " +"designed to support multiple versions, configurations, platforms, and " +"compilers. It was built to support the needs of large supercomputing centers " +"and scientific application teams, who must often build software many " +"different ways. Spack is not limited to Python; it can install packages for " +"``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-" +"destructive; installing a new version of one package does not break existing " +"installations, so many configurations can coexist on the same system." msgstr "" #: ../source/guides/installing-scientific-packages.rst:119 -msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." +msgid "" +"Spack offers a simple but powerful syntax that allows users to specify " +"versions and configuration options concisely. Package files are written in " +"pure Python, and they are templated so that it is easy to swap compilers, " +"dependency implementations (like MPI), versions, and build options with a " +"single package file. Spack also generates *module* files so that packages " +"can be loaded and unloaded from the user's environment." msgstr "" #: ../source/guides/installing-scientific-packages.rst:128 @@ -2649,11 +3666,29 @@ msgid "The conda cross-platform package manager" msgstr "" #: ../source/guides/installing-scientific-packages.rst:130 -msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." +msgid "" +"`Anaconda `_ is a Python distribution " +"published by Anaconda, Inc. It is a stable collection of Open Source " +"packages for big data and scientific use. As of the 5.0 release of " +"Anaconda, about 200 packages are installed by default, and a total of " +"400-500 can be installed and updated from the Anaconda repository." msgstr "" #: ../source/guides/installing-scientific-packages.rst:136 -msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." +msgid "" +"``conda`` is an open source (BSD licensed) package management system and " +"environment management system included in Anaconda that allows users to " +"install multiple versions of binary software packages and their " +"dependencies, and easily switch between them. It is a cross-platform tool " +"working on Windows, macOS, and Linux. Conda can be used to package up and " +"distribute all kinds of packages, it is not limited to just Python packages. " +"It has full support for native virtual environments. Conda makes " +"environments first-class citizens, making it easy to create independent " +"environments even for C libraries. It is written in Python, but is Python-" +"agnostic. Conda manages Python itself as a package, so that :command:`conda " +"update python` is possible, in contrast to pip, which only manages Python " +"packages. Conda is available in Anaconda and Miniconda (an easy-to-install " +"download with just Python and conda)." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:2 @@ -2661,15 +3696,28 @@ msgid "Installing stand alone command line tools" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:4 -msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." +msgid "" +"Many packages have command line entry points. Examples of this type of " +"application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:10 -msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." +msgid "" +"Usually you want to be able to access these from anywhere, but installing " +"packages and their dependencies to the same global environment can cause " +"version conflicts and break dependencies the operating system has on Python " +"packages." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:15 -msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." +msgid "" +":ref:`pipx` solves this by creating a virtual environment for each package, " +"while also ensuring that package's applications are accessible through a " +"directory that is on your ``$PATH``. This allows each package to be upgraded " +"or uninstalled without causing conflicts with other packages, and allows you " +"to safely run the program from anywhere." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:21 @@ -2681,11 +3729,14 @@ msgid "``pipx`` is installed with ``pip``:" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:30 -msgid "You may need to restart your terminal for the path updates to take effect." +msgid "" +"You may need to restart your terminal for the path updates to take effect." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:32 -msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." +msgid "" +"Now you can install packages with ``pipx install`` and access the package's " +"entry point(s) from anywhere." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:39 @@ -2694,7 +3745,9 @@ msgid "For example" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:59 -msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." +msgid "" +"To see a list of packages installed with pipx and which CLI applications are " +"available, use ``pipx list``." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:79 @@ -2706,7 +3759,9 @@ msgid "``pipx`` can be upgraded or uninstalled with pip" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:93 -msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." +msgid "" +"``pipx`` also allows you to install and run the latest version of a cli tool " +"in a temporary, ephemeral environment." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:106 @@ -2714,7 +3769,9 @@ msgid "To see the full list of commands ``pipx`` offers, run" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:112 -msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." +msgid "" +"You can learn more about ``pipx`` at its homepage, https://github.com/pypa/" +"pipx." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:5 @@ -2726,19 +3783,35 @@ msgid "2015-09-17" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:11 -msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." +msgid "" +"This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:" +"`wheel` using Linux package managers." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:14 -msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." +msgid "" +"If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:" +"`installing_requirements` section instead." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:18 -msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." +msgid "" +"Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, " +"and :ref:`wheel` supported by a specific Linux Distribution to be outdated " +"by the time it's released to the public, and updates generally only occur " +"for security reasons, not for feature updates. For certain Distributions, " +"there are additional repositories that can be enabled to provide newer " +"versions. The repositories we know about are explained below." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:25 -msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." +msgid "" +"Also note that it's somewhat common for Distributions to apply patches for " +"the sake of security and normalization to their own standards. In some " +"cases, this can lead to bugs or unexpected behaviors that vary from the " +"original unpatched versions. When this is known, we will make note of it " +"below." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:32 @@ -2770,7 +3843,11 @@ msgid "Python 3: ``sudo dnf install python3 python3-wheel``" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:53 -msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" +msgid "" +"To get newer versions of pip, setuptools, and wheel for Python 2, you can " +"enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:63 @@ -2778,7 +3855,9 @@ msgid "CentOS/RHEL" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:65 -msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." +msgid "" +"CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core " +"repositories, although :ref:`setuptools` is installed by default." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:68 @@ -2786,7 +3865,11 @@ msgid "To install pip and wheel for the system Python, there are two options:" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:70 -msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" +msgid "" +"Enable the `EPEL repository `_ using " +"`these instructions `__. On EPEL 6 and EPEL7, you can " +"install pip like so::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:77 @@ -2794,11 +3877,16 @@ msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:81 -msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." +msgid "" +"Since EPEL only offers extra, non-conflicting packages, EPEL does not offer " +"setuptools, since it's in the core repository." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:85 -msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" +msgid "" +"Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:92 @@ -2806,15 +3894,21 @@ msgid "To additionally upgrade setuptools, run::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:97 -msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" +msgid "" +"To install pip, wheel, and setuptools, in a parallel, non-system environment " +"(using yum) then there are two options:" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:101 -msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." +msgid "" +"Use the \"Software Collections\" feature to enable a parallel collection " +"that includes pip, setuptools, and wheel." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:104 -msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" +msgid "" +"For Redhat, see here: http://developers.redhat.com/products/" +"softwarecollections/overview/" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:106 @@ -2826,7 +3920,11 @@ msgid "Be aware that collections may not contain the most recent versions." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:110 -msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." +msgid "" +"Enable the `IUS repository `_ and install " +"one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which " +"are kept fairly up to date." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:116 @@ -2848,7 +3946,10 @@ msgid "Debian/Ubuntu" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:150 -msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." +msgid "" +"Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" " +"`_ by default, " +"which is a significant behavior change that can be surprising to some users." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:156 @@ -2856,7 +3957,9 @@ msgid "Arch Linux" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:168 -msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." +msgid "" +"Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the " +"only option is to manually place the repo files as described." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 @@ -2864,11 +3967,18 @@ msgid "Installing packages using pip and virtual environments" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 -msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." +msgid "" +"This guide discusses how to install packages using :ref:`pip` and a virtual " +"environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` " +"for Python 2. These are the lowest-level tools for managing Python packages " +"and are recommended if higher-level tools do not suit your needs." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 -msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." +msgid "" +"This doc uses the term **package** to refer to a :term:`Distribution " +"Package` which is different from an :term:`Import Package` that which is " +"used to import modules in your Python source code." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 @@ -2876,15 +3986,24 @@ msgid "Installing pip" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 -msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." +msgid "" +":ref:`pip` is the reference Python package manager. It's used to install and " +"update packages. You'll need to make sure you have the latest version of pip " +"installed." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 -msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." +msgid "" +"Debian and most other distributions include a `python-pip`_ package, if you " +"want to use the Linux distribution-provided versions of pip see :doc:`/" +"guides/installing-using-linux-tools`." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 -msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" +msgid "" +"You can also install pip yourself to ensure you have the latest version. " +"It's recommended to use the system pip to bootstrap a user installation of " +"pip:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 @@ -2892,7 +4011,9 @@ msgid "Afterwards, you should have the newest pip installed in your user site:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 -msgid "The Python installers for Windows include pip. You should be able to access pip using:" +msgid "" +"The Python installers for Windows include pip. You should be able to access " +"pip using:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 @@ -2904,11 +4025,19 @@ msgid "Installing virtualenv" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 -msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." +msgid "" +"If you are using Python 3.3 or newer, the :mod:`venv` module is the " +"preferred way to create and manage virtual environments. venv is included in " +"the Python standard library and requires no additional installation. If you " +"are using venv, you may skip this section." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 -msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." +msgid "" +":ref:`virtualenv` is used to manage Python packages for different projects. " +"Using virtualenv allows you to avoid installing Python packages globally " +"which could break system tools or other projects. You can install virtualenv " +"using pip." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 @@ -2916,15 +4045,28 @@ msgid "Creating a virtual environment" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 -msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." +msgid "" +":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to " +"manage separate package installations for different projects. They " +"essentially allow you to create a \"virtual\" isolated Python installation " +"and install packages into that virtual installation. When you switch " +"projects, you can simply create a new virtual environment and not have to " +"worry about breaking the packages installed in the other environments. It is " +"always recommended to use a virtual environment while developing Python " +"applications." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 -msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." +msgid "" +"To create a virtual environment, go to your project's directory and run " +"venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the " +"below commands." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 -msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." +msgid "" +"The second argument is the location to create the virtual environment. " +"Generally, you can just create this in your project and call it ``env``." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 @@ -2932,7 +4074,9 @@ msgid "venv will create a virtual Python installation in the ``env`` folder." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 -msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." +msgid "" +"You should exclude your virtual environment directory from your version " +"control system using ``.gitignore`` or similar." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 @@ -2940,15 +4084,24 @@ msgid "Activating a virtual environment" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 -msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." +msgid "" +"Before you can start installing or using packages in your virtual " +"environment you'll need to *activate* it. Activating a virtual environment " +"will put the virtual environment-specific ``python`` and ``pip`` executables " +"into your shell's ``PATH``." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 -msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." +msgid "" +"You can confirm you're in the virtual environment by checking the location " +"of your Python interpreter, it should point to the ``env`` directory." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 -msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." +msgid "" +"As long as your virtual environment is activated pip will install packages " +"into that specific environment and you'll be able to import and use packages " +"in your Python application." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 @@ -2956,11 +4109,16 @@ msgid "Leaving the virtual environment" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 -msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" +msgid "" +"If you want to switch projects or otherwise leave your virtual environment, " +"simply run:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 -msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." +msgid "" +"If you want to re-enter the virtual environment just follow the same " +"instructions above about activating a virtual environment. There's no need " +"to re-create the virtual environment." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 @@ -2968,11 +4126,14 @@ msgid "Installing packages" msgstr "Instalando pacotes" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 -msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" +msgid "" +"Now that you're in your virtual environment you can install packages. Let's " +"install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 -msgid "pip should download requests and all of its dependencies and install them:" +msgid "" +"pip should download requests and all of its dependencies and install them:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 @@ -2980,7 +4141,10 @@ msgid "Installing specific versions" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 -msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" +msgid "" +"pip allows you to specify which version of a package to install using :term:" +"`version specifiers `. For example, to install a specific " +"version of ``requests``:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 @@ -2996,7 +4160,9 @@ msgid "Installing extras" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 -msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" +msgid "" +"Some packages have optional `extras`_. You can tell pip to install these by " +"specifying the extra in brackets:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 @@ -3008,7 +4174,10 @@ msgid "pip can install a package directly from source, for example:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 -msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" +msgid "" +"Additionally, pip can install packages from source in `development mode`_, " +"meaning that changes to the source directory will immediately affect the " +"installed package without needing to re-install:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 @@ -3016,11 +4185,15 @@ msgid "Installing from version control systems" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 -msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" +msgid "" +"pip can install packages directly from their version control system. For " +"example, you can install directly from a git repository:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 -msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." +msgid "" +"For more information on supported version control systems and syntax, see " +"pip's documentation on :ref:`VCS Support `." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 @@ -3029,15 +4202,23 @@ msgid "Installing from local archives" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 -msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" +msgid "" +"If you have a local copy of a :term:`Distribution Package`'s archive (a zip, " +"wheel, or tar file) you can install it directly with pip:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 -msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" +msgid "" +"If you have a directory containing archives of multiple packages, you can " +"tell pip to look for packages there and not to use the :term:`Python Package " +"Index (PyPI)` at all:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 -msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." +msgid "" +"This is useful if you are installing packages on a system with limited " +"connectivity or if you want to strictly control the origin of distribution " +"packages." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 @@ -3045,11 +4226,16 @@ msgid "Using other package indexes" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 -msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" +msgid "" +"If you want to download packages from a different index than the :term:" +"`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 -msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" +msgid "" +"If you want to allow packages from both the :term:`Python Package Index " +"(PyPI)` and a separate index, you can use the ``--extra-index-url`` flag " +"instead:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 @@ -3058,7 +4244,9 @@ msgid "Upgrading packages" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 -msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" +msgid "" +"pip can upgrade packages in-place using the ``--upgrade`` flag. For example, " +"to install the latest version of ``requests`` and all of its dependencies:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 @@ -3066,11 +4254,16 @@ msgid "Using requirements files" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 -msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" +msgid "" +"Instead of installing packages individually, pip allows you to declare all " +"dependencies in a :ref:`Requirements File `. For " +"example you could create a :file:`requirements.txt` file containing:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 -msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" +msgid "" +"And tell pip to install all of the packages in this file using the ``-r`` " +"flag:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 @@ -3078,7 +4271,9 @@ msgid "Freezing dependencies" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 -msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" +msgid "" +"Pip can export a list of all installed packages and their versions using the " +"``freeze`` command:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 @@ -3086,7 +4281,9 @@ msgid "Which will output a list of package specifiers such as:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 -msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." +msgid "" +"This is useful for creating :ref:`pip:Requirements Files` that can re-create " +"the exact versions of all packages installed in an environment." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:2 @@ -3094,7 +4291,11 @@ msgid "Making a PyPI-friendly README" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:4 -msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." +msgid "" +"README files can help your users understand your project and can be used to " +"set your project's description on PyPI. This guide helps you create a README " +"in a PyPI-friendly format and include your README in your package so it " +"appears on PyPI." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:9 @@ -3102,11 +4303,16 @@ msgid "Creating a README file" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:11 -msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." +msgid "" +"README files for Python projects are often named ``README``, ``README.txt``, " +"``README.rst``, or ``README.md``." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:13 -msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" +msgid "" +"For your README to display properly on PyPI, choose a markup language " +"supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:16 @@ -3114,15 +4320,21 @@ msgid "plain text" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:17 -msgid "`reStructuredText `_ (without Sphinx extensions)" +msgid "" +"`reStructuredText `_ (without " +"Sphinx extensions)" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:18 -msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" +msgid "" +"Markdown (`GitHub Flavored Markdown `_ by " +"default, or `CommonMark `_)" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:21 -msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." +msgid "" +"It's customary to save your README file in the root of your project, in the " +"same directory as your :file:`setup.py` file." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:25 @@ -3130,7 +4342,10 @@ msgid "Including your README in your package's metadata" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:27 -msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." +msgid "" +"To include your README's contents as your package description, set your " +"project's ``Description`` and ``Description-Content-Type`` metadata, " +"typically in your project's :file:`setup.py` file." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:33 @@ -3142,15 +4357,23 @@ msgid ":ref:`description-content-type-optional`" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:36 -msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." +msgid "" +"For example, to set these values in a package's :file:`setup.py` file, use " +"``setup()``'s ``long_description`` and ``long_description_content_type``." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:39 -msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." +msgid "" +"Set the value of ``long_description`` to the contents (not the path) of the " +"README file itself. Set the ``long_description_content_type`` to an accepted " +"``Content-Type``-style value for your README file's markup, such as ``text/" +"plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:45 -msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" +msgid "" +"If you're using GitHub-flavored Markdown to write a project's description, " +"ensure you upgrade the following tools:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:60 @@ -3170,11 +4393,16 @@ msgid "``twine >= 1.11.0``" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:66 -msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" +msgid "" +"It's recommended that you use ``twine`` to upload the project's distribution " +"packages:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:72 -msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" +msgid "" +"For example, see this :file:`setup.py` file, which reads the contents of :" +"file:`README.md` as ``long_description`` and identifies the markup as GitHub-" +"flavored Markdown:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:95 @@ -3182,23 +4410,36 @@ msgid "Validating reStructuredText markup" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:97 -msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." +msgid "" +"If your README is written in reStructuredText, any invalid markup will " +"prevent it from rendering, causing PyPI to instead just show the README's " +"raw source." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:100 -msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." +msgid "" +"Note that Sphinx extensions used in docstrings, such as `directives and " +"roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```" +"\"), are not allowed here and will result in error messages like \"``Error: " +"Unknown interpreted text role \"py:func\".``\"." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:105 -msgid "You can check your README for markup errors before uploading as follows:" +msgid "" +"You can check your README for markup errors before uploading as follows:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:107 -msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" +msgid "" +"Install the latest version of `twine `_; " +"version 1.12.0 or higher is required:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:122 -msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." +msgid "" +"Build the sdist and wheel for your project as described under :ref:" +"`Packaging Your Project`." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:125 @@ -3206,7 +4447,10 @@ msgid "Run ``twine check`` on the sdist and wheel::" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:129 -msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." +msgid "" +"This command will report any problems rendering your README. If your markup " +"renders fine, the command will output ``Checking distribution FILENAME: " +"Passed``." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:4 @@ -3214,7 +4458,11 @@ msgid "Migrating to PyPI.org" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:6 -msgid ":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``." +msgid "" +":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``." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:12 @@ -3226,15 +4474,21 @@ msgid "``pypi.org`` is the default upload platform as of September 2016." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:16 -msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." +msgid "" +"Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. " +"As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:19 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:22 -msgid "The default upload settings switched to ``pypi.org`` in the following versions:" +msgid "" +"The default upload settings switched to ``pypi.org`` in the following " +"versions:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:24 @@ -3262,19 +4516,32 @@ msgid "Python 3.6.0 (``distutils`` update)" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:31 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:48 -msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." +msgid "" +"Then simply delete the line starting with ``repository`` and you will use " +"your upload tool's default URL." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:51 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:67 -msgid "(``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.)" +msgid "" +"(``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.)" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:73 @@ -3282,15 +4549,22 @@ msgid "Registering package names & metadata" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:75 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:79 -msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" +msgid "" +"As a result, attempting explicit registration after switching to using PyPI." +"org for uploads will give the following error message::" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:84 -msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." +msgid "" +"The solution is to skip the registration step, and proceed directly to " +"uploading artifacts." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:89 @@ -3299,7 +4573,12 @@ msgid "Using TestPyPI" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:91 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:113 @@ -3307,7 +4586,10 @@ msgid "Registering new user accounts" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:115 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:121 @@ -3315,7 +4597,11 @@ msgid "Browsing packages" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:123 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:130 @@ -3331,7 +4617,9 @@ msgid "Managing published packages and releases" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:137 -msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." +msgid "" +"``pypi.org`` provides a fully functional interface for logged in users to " +"manage their published packages and releases." msgstr "" #: ../source/guides/multi-version-installs.rst:5 @@ -3339,23 +4627,51 @@ msgid "Multi-version installs" msgstr "" #: ../source/guides/multi-version-installs.rst:8 -msgid "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``)." +msgid "" +"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``)." msgstr "" #: ../source/guides/multi-version-installs.rst:13 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/multi-version-installs.rst:19 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/multi-version-installs.rst:31 -msgid "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 ``python -c ''`` to invoke the application's main entry point directly." +msgid "" +"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 ``python -c ''`` to invoke the application's main " +"entry point directly." msgstr "" #: ../source/guides/multi-version-installs.rst:38 -msgid "Refer to the `pkg_resources documentation `__ for more details." +msgid "" +"Refer to the `pkg_resources documentation `__ for more details." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:5 @@ -3367,7 +4683,12 @@ msgid "2013-12-08" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:10 -msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." +msgid "" +"One of the features of the CPython reference interpreter is that, in " +"addition to allowing the execution of Python code, it also exposes a rich C " +"API for use by other software. One of the most common uses of this C API is " +"to create importable C extensions that allow things which aren't always easy " +"to achieve in pure Python code." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:20 @@ -3379,27 +4700,66 @@ msgid "Use cases" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:25 -msgid "The typical use cases for binary extensions break down into just three conventional categories:" +msgid "" +"The typical use cases for binary extensions break down into just three " +"conventional categories:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:28 -msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." +msgid "" +"**accelerator modules**: these modules are completely self-contained, and " +"are created solely to run faster than the equivalent pure Python code runs " +"in CPython. Ideally, accelerator modules will always have a pure Python " +"equivalent to use as a fallback if the accelerated version isn't available " +"on a given system. The CPython standard library makes extensive use of " +"accelerator modules. *Example*: When importing ``datetime``, Python falls " +"back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not " +"available." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:39 -msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." +msgid "" +"**wrapper modules**: these modules are created to expose existing C " +"interfaces to Python code. They may either expose the underlying C interface " +"directly, or else expose a more \"Pythonic\" API that makes use of Python " +"language features to make the API easier to use. The CPython standard " +"library makes extensive use of wrapper modules. *Example*: `functools.py " +"`_ is a " +"Python module wrapper for `_functoolsmodule.c `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:47 -msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." +msgid "" +"**low-level system access**: these modules are created to access lower level " +"features of the CPython runtime, the operating system, or the underlying " +"hardware. Through platform specific code, extension modules may achieve " +"things that aren't possible in pure Python code. A number of CPython " +"standard library modules are written in C in order to access interpreter " +"internals that aren't exposed at the language level. *Example*: ``sys``, " +"which comes from `sysmodule.c `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:56 -msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." +msgid "" +"One particularly notable feature of C extensions is that, when they don't " +"need to call back into the interpreter runtime, they can release CPython's " +"global interpreter lock around long-running operations (regardless of " +"whether those operations are CPU or IO bound)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:61 -msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." +msgid "" +"Not all extension modules will fit neatly into the above categories. The " +"extension modules included with NumPy, for example, span all three use cases " +"- they move inner loops to C for speed reasons, wrap external libraries " +"written in C, FORTRAN and other languages, and use low level system " +"interfaces for both CPython and the underlying operation system to support " +"concurrent execution of vectorised operations and to tightly control the " +"exact memory layout of created objects." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:71 @@ -3407,7 +4767,13 @@ msgid "Disadvantages" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:73 -msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." +msgid "" +"The main disadvantage of using binary extensions is the fact that it makes " +"subsequent distribution of the software more difficult. One of the " +"advantages of using Python is that it is largely cross platform, and the " +"languages used to write extension modules (typically C or C++, but really " +"any language that can bind to the CPython C API) typically require that " +"custom binaries be created for different platforms." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:80 @@ -3415,27 +4781,44 @@ msgid "This means that binary extensions:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:82 -msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" +msgid "" +"require that end users be able to either build them from source, or else " +"that someone publish pre-built binaries for common platforms" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:85 -msgid "may not be compatible with different builds of the CPython reference interpreter" +msgid "" +"may not be compatible with different builds of the CPython reference " +"interpreter" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:88 -msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" +msgid "" +"often will not work correctly with alternative interpreters such as PyPy, " +"IronPython or Jython" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:91 -msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." +msgid "" +"if handcoded, make maintenance more difficult by requiring that maintainers " +"be familiar not only with Python, but also with the language used to create " +"the binary extension, as well as with the details of the CPython C API." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:96 -msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." +msgid "" +"if a pure Python fallback implementation is provided, make maintenance more " +"difficult by requiring that changes be implemented in two places, and " +"introducing additional complexity in the test suite to ensure both versions " +"are always executed." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:101 -msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." +msgid "" +"Another disadvantage of relying on binary extensions is that alternative " +"import mechanisms (such as the ability to import modules directly from " +"zipfiles) often won't work for extension modules (as the dynamic loading " +"mechanisms on most platforms can only load libraries from disk)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:108 @@ -3443,23 +4826,56 @@ msgid "Alternatives to handcoded accelerator modules" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:110 -msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" +msgid "" +"When extension modules are just being used to make code run faster (after " +"profiling has identified the code where the speed increase is worth " +"additional maintenance effort), a number of other alternatives should also " +"be considered:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:115 -msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." +msgid "" +"look for existing optimised alternatives. The CPython standard library " +"includes a number of optimised data structures and algorithms (especially in " +"the builtins and the ``collections`` and ``itertools`` modules). The Python " +"Package Index also offers additional alternatives. Sometimes, the " +"appropriate choice of standard library or third party module can avoid the " +"need to create your own accelerator module." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:122 -msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." +msgid "" +"for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython " +"runtime. The main barrier to adopting PyPy is typically reliance on other " +"binary extension modules - while PyPy does emulate the CPython C API, " +"modules that rely on that cause problems for the PyPy JIT, and the emulation " +"layer can often expose latent defects in extension modules that CPython " +"currently tolerates (frequently around reference counting errors - an object " +"having one live reference instead of two often won't break anything, but no " +"references instead of one is a major problem)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:132 -msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." +msgid "" +"`Cython `__ is a mature static compiler that can compile " +"most Python code to C extension modules. The initial compilation provides " +"some speed increases (by bypassing the CPython interpreter layer), and " +"Cython's optional static typing features can offer additional opportunities " +"for speed increases. Using Cython still has the disadvantage of increasing " +"the complexity of distributing the resulting application, but has the " +"benefit of having a reduced barrier to entry for Python programmers " +"(relative to other languages like C or C++)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:141 -msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." +msgid "" +"`Numba `__ is a newer tool, created by members of " +"the scientific Python community, that aims to leverage LLVM to allow " +"selective compilation of pieces of a Python application to native machine " +"code at runtime. It requires that LLVM be available on the system where the " +"code is running, but can provide significant speed increases, especially for " +"operations that are amenable to vectorisation." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:150 @@ -3467,35 +4883,74 @@ msgid "Alternatives to handcoded wrapper modules" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:152 -msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." +msgid "" +"The C ABI (Application Binary Interface) is a common standard for sharing " +"functionality between multiple applications. One of the strengths of the " +"CPython C API (Application Programming Interface) is allowing Python users " +"to tap into that functionality. However, wrapping modules by hand is quite " +"tedious, so a number of other alternative approaches should be considered." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:158 -msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." +msgid "" +"The approaches described below don't simplify the distribution case at all, " +"but they *can* significantly reduce the maintenance burden of keeping " +"wrapper modules up to date." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:162 -msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." +msgid "" +"In addition to being useful for the creation of accelerator modules, `Cython " +"`__ is also useful for creating wrapper modules for C or " +"C++. It still involves wrapping the interfaces by hand, however, and is very " +"repetitive, so may not be a good choice for wrapping large APIs." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:168 -msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." +msgid "" +"`pybind11 `__ is a pure C++11 library that " +"provides a clean C++ interface to the CPython (and PyPy) C API. It does not " +"require a pre-processing step; it is written entirely in templated C++. " +"Helpers are included for Setuptools or CMake builds. It was based on `Boost." +"Python `__, but doesn't require the Boost libraries or BJam." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:175 -msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." +msgid "" +"`cffi `__ is a project created by some of the " +"PyPy developers to make it straightforward for developers that already know " +"both Python and C to expose their C modules to Python applications. It also " +"makes it relatively straightforward to wrap a C module based on its header " +"files, even if you don't know C yourself." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:181 -msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." +msgid "" +"One of the key advantages of ``cffi`` is that it is compatible with the PyPy " +"JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing " +"JIT optimisations." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:185 -msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." +msgid "" +"`SWIG `__ is a wrapper interface generator that allows " +"a variety of programming languages, including Python, to interface with C " +"and C++ code." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:189 -msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." +msgid "" +"The standard library's ``ctypes`` module, while useful for getting access to " +"C level interfaces when header information isn't available, suffers from the " +"fact that it operates solely at the C ABI level, and thus has no automatic " +"consistency checking between the interface actually being exported by the " +"library and the one declared in the Python code. By contrast, the above " +"alternatives are all able to operate at the C *API* level, using C header " +"files to ensure consistency between the interface exported by the library " +"being wrapped and the one expected by the Python wrapper module. While " +"``cffi`` *can* operate directly at the C ABI level, it suffers from the same " +"interface inconsistency problems as ``ctypes`` when it is used that way." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:203 @@ -3503,11 +4958,24 @@ msgid "Alternatives for low level system access" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:205 -msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." +msgid "" +"For applications that need low level system access (regardless of the " +"reason), a binary extension module often *is* the best way to go about it. " +"This is particularly true for low level access to the CPython runtime " +"itself, since some operations (like releasing the Global Interpreter Lock) " +"are simply invalid when the interpreter is running code, even if a module " +"like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API " +"interfaces." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:213 -msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." +msgid "" +"For cases where the extension module is manipulating the underlying " +"operating system or hardware (rather than the CPython runtime), it may " +"sometimes be better to just write an ordinary C library (or a library in " +"another systems programming language like C++ or Rust that can export a C " +"compatible ABI), and then use one of the wrapping techniques described above " +"to make the interface available as an importable Python module." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:222 @@ -3515,7 +4983,10 @@ msgid "Implementing binary extensions" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:224 -msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." +msgid "" +"The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in " +"C `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:241 @@ -3527,7 +4998,14 @@ msgid "Building extensions for multiple platforms" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:246 -msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." +msgid "" +"If you plan to distribute your extension, you should provide :term:`wheels " +"` for all the platforms you intend to support. For most extensions, " +"this is at least one package per Python version times the number of OS and " +"architectures you support. These are usually built on continuous " +"integration (CI) systems. There are tools to help you build highly " +"redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:" +"`multibuild`." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:256 @@ -3535,15 +5013,27 @@ msgid "Binary extensions for Windows" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:258 -msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." +msgid "" +"Before it is possible to build a binary extension, it is necessary to ensure " +"that you have a suitable compiler available. On Windows, Visual C is used to " +"build the official CPython interpreter, and should be used to build " +"compatible binary extensions." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:263 -msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." +msgid "" +"Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio " +"2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older " +"versions of Visual Studio are no longer easily available from Microsoft, so " +"for versions of Python prior to 3.5, the compilers must be obtained " +"differently if you do not already have a copy of the relevant version of " +"Visual Studio." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:269 -msgid "To set up a build environment for binary extensions, the steps are as follows:" +msgid "" +"To set up a build environment for binary extensions, the steps are as " +"follows:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:271 @@ -3551,11 +5041,16 @@ msgid "For Python 2.7" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:273 -msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." +msgid "" +"Install \"Visual C++ Compiler Package for Python 2.7\", which is available " +"from `Microsoft's website `__." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:276 -msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." +msgid "" +"Use (a recent version of) setuptools in your setup.py (pip will do this for " +"you, in any case)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:278 @@ -3569,11 +5064,16 @@ msgid "For Python 3.4" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:282 -msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." +msgid "" +"Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is " +"available from `Microsoft's website `__." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:285 -msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." +msgid "" +"Work from an SDK command prompt (with the environment variables set, and the " +"SDK on PATH)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:287 @@ -3585,15 +5085,23 @@ msgid "For Python 3.5" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:292 -msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." +msgid "" +"Install `Visual Studio 2015 Community Edition `__ (or any later version, " +"when these are released)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:297 -msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." +msgid "" +"Note that from Python 3.5 onwards, Visual Studio works in a backward " +"compatible way, which means that any future version of Visual Studio will be " +"able to build Python extensions for all Python versions from 3.5 onwards." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:301 -msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." +msgid "" +"Building with the recommended compiler on Windows ensures that a compatible " +"C library is used throughout the Python process." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:305 @@ -3601,7 +5109,11 @@ msgid "Binary extensions for Linux" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:307 -msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." +msgid "" +"Linux binaries must use a sufficiently old glibc to be compatible with older " +"distributions. The `manylinux `_ Docker " +"images provide a build environment with a glibc old enough to support most " +"current Linux distributions on common architectures." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:313 @@ -3609,7 +5121,15 @@ msgid "Binary extensions for macOS" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:315 -msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." +msgid "" +"Binary compatibility on macOS is determined by the target minimum deployment " +"system, e.g. *10.9*, which is often specified with the " +"``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries " +"on macOS. When building with setuptools / distutils, the deployment target " +"is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For " +"common deployment targets for macOS Python distributions, see the `MacPython " +"Spinning Wheels wiki `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:325 @@ -3617,7 +5137,9 @@ msgid "Publishing binary extensions" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:327 -msgid "For interim guidance on this topic, see the discussion in `this issue `_." +msgid "" +"For interim guidance on this topic, see the discussion in `this issue " +"`_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:343 @@ -3625,7 +5147,13 @@ msgid "Additional resources" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:345 -msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." +msgid "" +"Cross-platform development and distribution of extension modules is a " +"complex topic, so this guide focuses primarily on providing pointers to " +"various tools that automate dealing with the underlying technical " +"challenges. The additional resources in this section are instead intended " +"for developers looking to understand more about the underlying binary " +"interfaces that those systems rely on at runtime." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:352 @@ -3633,7 +5161,13 @@ msgid "Cross-platform wheel generation with scikit-build" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:354 -msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." +msgid "" +"The `scikit-build `_ package " +"helps abstract cross-platform build operations and provides additional " +"capabilities when creating binary extension packages. Additional " +"documentation is also available on the `C runtime, compiler, and build " +"system generator `_ for Python binary extension modules." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:362 @@ -3641,11 +5175,15 @@ msgid "Introduction to C/C++ extension modules" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:364 -msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" +msgid "" +"For a more in depth explanation of how extension modules are used by CPython " +"on a Debian system, see the following articles:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:367 -msgid "`What are (c)python extension modules? `_" +msgid "" +"`What are (c)python extension modules? `_" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:368 @@ -3653,7 +5191,9 @@ msgid "`Releasing the gil `_" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:369 -msgid "`Writing cpython extension modules using C++ `_" +msgid "" +"`Writing cpython extension modules using C++ `_" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:3 @@ -3661,7 +5201,12 @@ msgid "Packaging namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:5 -msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" +msgid "" +"Namespace packages allow you to split the sub-packages and modules within a " +"single :term:`package ` across multiple, separate :term:" +"`distribution packages ` (referred to as " +"**distributions** in this document to avoid ambiguity). For example, if you " +"have the following package structure:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:24 @@ -3677,7 +5222,14 @@ msgid "Each sub-package can now be separately installed, used, and versioned." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:48 -msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." +msgid "" +"Namespace packages can be useful for a large collection of loosely-related " +"packages (such as a large corpus of client libraries for multiple products " +"from a single company). However, namespace packages come with several " +"caveats and are not appropriate in all cases. A simple alternative is to use " +"a prefix on all of your distributions such as ``import " +"mynamespace_subpackage_a`` (you could even use ``import " +"mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:58 @@ -3685,23 +5237,39 @@ msgid "Creating a namespace package" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:60 -msgid "There are currently three different approaches to creating namespace packages:" +msgid "" +"There are currently three different approaches to creating namespace " +"packages:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:62 -msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." +msgid "" +"Use `native namespace packages`_. This type of namespace package is defined " +"in :pep:`420` and is available in Python 3.3 and later. This is recommended " +"if packages in your namespace only ever need to support Python 3 and " +"installation via ``pip``." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:66 -msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." +msgid "" +"Use `pkgutil-style namespace packages`_. This is recommended for new " +"packages that need to support Python 2 and 3 and installation via both " +"``pip`` and ``python setup.py install``." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:69 -msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." +msgid "" +"Use `pkg_resources-style namespace packages`_. This method is recommended if " +"you need compatibility with packages already using this method or if your " +"package needs to be zip-safe." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:73 -msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." +msgid "" +"While native namespace packages and pkgutil-style namespace packages are " +"largely compatible, pkg_resources-style namespace packages are not " +"compatible with the other methods. It's inadvisable to use different methods " +"in different distributions that provide packages to the same namespace." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:80 @@ -3709,23 +5277,41 @@ msgid "Native namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:82 -msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" +msgid "" +"Python 3.3 added **implicit** namespace packages from :pep:`420`. All that " +"is required to create a native namespace package is that you just omit :file:" +"`__init__.py` from the namespace package directory. An example file " +"structure:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:97 -msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." +msgid "" +"It is extremely important that every distribution that uses the namespace " +"package omits the :file:`__init__.py` or uses a pkgutil-style :file:" +"`__init__.py`. If any distribution does not, it will cause the namespace " +"logic to fail and the other sub-packages will not be importable." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:102 -msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" +msgid "" +"Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:" +"`setuptools.find_packages` won't find the sub-package. You must use :func:" +"`setuptools.find_namespace_packages` instead or explicitly list all packages " +"in your :file:`setup.py`. For example:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:117 -msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." +msgid "" +"A complete working example of two native namespace packages can be found in " +"the `native namespace package example project`_." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:123 -msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." +msgid "" +"Because native and pkgutil-style namespace packages are largely compatible, " +"you can use native namespace packages in the distributions that only support " +"Python 3 and pkgutil-style namespace packages in the distributions that need " +"to support Python 2 and 3." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:129 @@ -3733,25 +5319,39 @@ msgid "pkgutil-style namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:131 -msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." +msgid "" +"Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. " +"This can be used to declare namespace packages that need to be compatible " +"with both Python 2.3+ and Python 3. This is the recommended approach for the " +"highest level of compatibility." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:136 -msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgid "" +"To create a pkgutil-style namespace package, you need to provide an :file:" +"`__init__.py` file for the namespace package:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:148 #: ../source/guides/packaging-namespace-packages.rst:194 -msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" +msgid "" +"The :file:`__init__.py` file for the namespace package needs to contain " +"**only** the following:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:155 #: ../source/guides/packaging-namespace-packages.rst:201 -msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." +msgid "" +"**Every** distribution that uses the namespace package must include an " +"identical :file:`__init__.py`. If any distribution does not, it will cause " +"the namespace logic to fail and the other sub-packages will not be " +"importable. Any additional code in :file:`__init__.py` will be inaccessible." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:160 -msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." +msgid "" +"A complete working example of two pkgutil-style namespace packages can be " +"found in the `pkgutil namespace example project`_." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:171 @@ -3759,39 +5359,68 @@ msgid "pkg_resources-style namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:173 -msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." +msgid "" +"`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and " +"the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together " +"these can be used to declare namespace packages. While this approach is no " +"longer recommended, it is widely present in most existing namespace " +"packages. If you are creating a new distribution within an existing " +"namespace package that uses this method then it's recommended to continue " +"using this as the different methods are not cross-compatible and it's not " +"advisable to try to migrate an existing package." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:182 -msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgid "" +"To create a pkg_resources-style namespace package, you need to provide an :" +"file:`__init__.py` file for the namespace package:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:206 -msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" +msgid "" +"Some older recommendations advise the following in the namespace package :" +"file:`__init__.py`:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:216 -msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." +msgid "" +"The idea behind this was that in the rare case that setuptools isn't " +"available packages would fall-back to the pkgutil-style packages. This isn't " +"advisable because pkgutil and pkg_resources-style namespace packages are not " +"cross-compatible. If the presence of setuptools is a concern then the " +"package should just explicitly depend on setuptools via ``install_requires``." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:223 -msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" +msgid "" +"Finally, every distribution must provide the ``namespace_packages`` argument " +"to :func:`~setuptools.setup` in :file:`setup.py`. For example:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:237 -msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." +msgid "" +"A complete working example of two pkg_resources-style namespace packages can " +"be found in the `pkg_resources namespace example project`_." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 -msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" +msgid "" +"Publishing package distribution releases using GitHub Actions CI/CD workflows" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 -msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." +msgid "" +"`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an " +"event occurs on the GitHub platform. One popular choice is having a workflow " +"that's triggered by a ``push`` event. This guide shows you how to publish a " +"Python distribution whenever a tagged commit is pushed. It will use the " +"`pypa/gh-action-pypi-publish GitHub Action`_." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 -msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." +msgid "" +"This guide *assumes* that you already have a project that you know how to " +"build distributions for and *it lives on GitHub*." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 @@ -3799,7 +5428,10 @@ msgid "Saving credentials on GitHub" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 -msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." +msgid "" +"In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, " +"meaning that we'll have two separate sets of credentials. And we'll need to " +"save them in the GitHub repository settings." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 @@ -3807,23 +5439,37 @@ msgid "Let's begin! 🚀" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" +msgid "" +"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " +"token`_. If you have the project on PyPI already, limit the token scope to " +"just that project. You can call it something like ``GitHub Actions CI/CD — " +"project-org/project-repo`` in order for it to be easily distinguishable in " +"the token list. **Don't close the page just yet — you won't see that token " +"again.**" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 -msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." +msgid "" +"In a separate browser tab or window, go to the ``Settings`` tab of your " +"target repository and then click on `Secrets`_ in the left sidebar." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 -msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." +msgid "" +"Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from " +"the first step." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 -msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." +msgid "" +"Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the " +"steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 -msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." +msgid "" +"If you don't have a TestPyPI account, you'll need to create it. It's not the " +"same as a regular PyPI account." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 @@ -3831,7 +5477,9 @@ msgid "Creating a workflow definition" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 -msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." +msgid "" +"GitHub CI/CD workflows are declared in YAML files stored in the ``.github/" +"workflows/`` directory of your repository." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 @@ -3839,7 +5487,9 @@ msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 -msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" +msgid "" +"Start it with a meaningful name and define the event that should make GitHub " +"run this workflow:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 @@ -3847,7 +5497,9 @@ msgid "Defining a workflow job environment" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 -msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" +msgid "" +"Now, let's add initial setup for our job. It's a process that will execute " +"commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 @@ -3859,15 +5511,22 @@ msgid "Then, add the following under the ``build-n-publish`` section:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 -msgid "This will download your repository into the CI runner and then install and activate Python 3.7." +msgid "" +"This will download your repository into the CI runner and then install and " +"activate Python 3.7." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 -msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." +msgid "" +"And now we can build dists from source. In this example, we'll use ``build`` " +"package, assuming that your project has a ``pyproject.toml`` properly set up " +"(see :pep:`517`/:pep:`518`)." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 -msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." +msgid "" +"You can use any other method for building distributions as long as it " +"produces ready-to-upload artifacts saved into the ``dist/`` folder." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 @@ -3883,7 +5542,11 @@ msgid "Finally, add the following steps at the end:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 -msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." +msgid "" +"These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the " +"first one uploads contents of the ``dist/`` folder into TestPyPI " +"unconditionally and the second does that to PyPI, but only if the current " +"commit is tagged." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 @@ -3891,7 +5554,11 @@ msgid "That's all, folks!" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 -msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" +msgid "" +"Now, whenever you push a tagged commit to your Git repository remote on " +"GitHub, this workflow will publish it to PyPI. And it'll publish any push to " +"TestPyPI which is useful for providing test builds to your alpha users as " +"well as making sure that your release pipeline remains healthy!" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:5 @@ -3899,87 +5566,143 @@ msgid "Single-sourcing the package version" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:8 -msgid "There are many techniques to maintain a single source of truth for the version number of your project:" +msgid "" +"There are many techniques to maintain a single source of truth for the " +"version number of your project:" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:11 -msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" +msgid "" +"Read the file in :file:`setup.py` and get the version. Example (from `pip " +"setup.py `_)::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:38 -msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" +msgid "" +"As of the release of setuptools 46.4.0, one can accomplish the same thing by " +"instead placing the following in the project's ``setup.cfg`` file (replacing " +"\"package\" with the import name of the package):" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:47 -msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." +msgid "" +"Earlier versions of setuptools implemented the ``attr:`` directive by " +"importing the module, but setuptools 46.4.0 added rudimentary AST analysis " +"so that ``attr:`` can function without having to import any of the package's " +"dependencies." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:52 -msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." +msgid "" +"Also, please be aware that declarative config indicators, including the " +"``attr:`` directive, are not supported in parameters to ``setup.py``." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:55 -msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." +msgid "" +"Use an external build tool that either manages updating both locations, or " +"offers an API that both locations can use." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:58 -msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." +msgid "" +"Few tools you could use, in no particular order, and not necessarily " +"complete: `bump2version `_, `changes " +"`_, `commitizen `_, `zest.releaser `_." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:65 -msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." +msgid "" +"Set the value to a ``__version__`` global variable in a dedicated module in " +"your project (e.g. :file:`version.py`), then have :file:`setup.py` read and " +"``exec`` the value into a variable." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:76 -msgid "Example using this technique: `warehouse `_." +msgid "" +"Example using this technique: `warehouse `_." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:78 -msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." +msgid "" +"Place the value in a simple ``VERSION`` text file and have both :file:`setup." +"py` and the project code read it." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:86 -msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." +msgid "" +"An advantage with this technique is that it's not specific to Python. Any " +"tool can read the version." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:91 -msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." +msgid "" +"With this approach you must make sure that the ``VERSION`` file is included " +"in all your source and binary distributions (e.g. add ``include VERSION`` to " +"your :file:`MANIFEST.in`)." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:95 -msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" +msgid "" +"Set the value in :file:`setup.py`, and have the project code use the " +"``importlib.metadata`` API to fetch the value at runtime. (``importlib." +"metadata`` was introduced in Python 3.8 and is available to older versions " +"as the ``importlib-metadata`` project.) An installed project's version can " +"be fetched with the API as follows::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:110 -msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." +msgid "" +"Be aware that the ``importlib.metadata`` API only knows about what's in the " +"installation metadata, which is not necessarily the code that's currently " +"imported." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:114 -msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" +msgid "" +"If a project uses this method to fetch its version at runtime, then its " +"``install_requires`` value needs to be edited to install ``importlib-" +"metadata`` on pre-3.8 versions of Python like so::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:128 -msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" +msgid "" +"An older (and less efficient) alternative to ``importlib.metadata`` is the " +"``pkg_resources`` API provided by ``setuptools``::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:134 -msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." +msgid "" +"If a project uses ``pkg_resources`` to fetch its own version at runtime, " +"then ``setuptools`` must be added to the project's ``install_requires`` list." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:138 -msgid "Example using this technique: `setuptools `_." +msgid "" +"Example using this technique: `setuptools `_." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:141 -msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." +msgid "" +"Set the value to ``__version__`` in ``sample/__init__.py`` and import " +"``sample`` in :file:`setup.py`." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:155 -msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." +msgid "" +"Although this technique is common, beware that it will fail if ``sample/" +"__init__.py`` imports packages from ``install_requires`` dependencies, which " +"will very likely not be installed yet when :file:`setup.py` is run." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:161 -msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." +msgid "" +"Keep the version number in the tags of a version control system (Git, " +"Mercurial, etc) instead of in the code, and automatically extract it from " +"there using `setuptools_scm `_." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:5 @@ -3987,11 +5710,20 @@ msgid "Supporting multiple Python versions" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:37 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:43 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:49 @@ -3999,31 +5731,52 @@ msgid "Automated testing and continuous integration" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:51 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:56 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:60 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:66 -msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." +msgid "" +"`Travis CI `_ provides both a Linux and a macOS " +"environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit " +"while the macOS is 10.9.2 at the time of writing." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:69 -msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." +msgid "" +"`Appveyor `_ provides a Windows environment " +"(Windows Server 2012)." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:80 -msgid "Both `Travis CI`_ 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." +msgid "" +"Both `Travis CI`_ 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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:85 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:89 @@ -4031,11 +5784,24 @@ msgid "Tools for single-source Python packages" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:91 -msgid "`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_." +msgid "" +"`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_." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:100 -msgid "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" +msgid "" +"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" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:107 @@ -4047,11 +5813,22 @@ msgid "a Python 3 (by syntax) module in a *Python 2* project." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:110 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:117 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:124 @@ -4059,7 +5836,13 @@ msgid "What's in which Python?" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:126 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:3 @@ -4071,19 +5854,37 @@ msgid "2015-12-03" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:8 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:20 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:24 -msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." +msgid "" +"The Appveyor service is a continuous integration service, much like the " +"better-known `Travis`_ service that is commonly used for testing by projects " +"hosted on `Github`_. However, unlike Travis, the build workers on Appveyor " +"are Windows hosts and have the necessary compilers installed to build Python " +"extensions." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:30 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:38 @@ -4091,15 +5892,25 @@ msgid "Setting up" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:40 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:45 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:49 -msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." +msgid "" +"Once you have set up your Appveyor account and added your project, Appveyor " +"will automatically build your project each time a commit occurs. This " +"behaviour will be familiar to users of Travis." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:54 @@ -4107,11 +5918,22 @@ msgid "Adding Appveyor support to your project" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:56 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:61 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:69 @@ -4119,39 +5941,74 @@ msgid "appveyor.yml" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:75 -msgid "This file can be downloaded from `here `__." +msgid "" +"This file can be downloaded from `here `__." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:77 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:80 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:88 -msgid "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``)." +msgid "" +"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``)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:94 -msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." +msgid "" +"The ``build`` section simply switches off builds - there is no build step " +"needed for Python, unlike languages like ``C#``." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:97 -msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." +msgid "" +"The main sections that will need to be tailored to your project are " +"``test_script`` and ``after_test``." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:100 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:109 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:114 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:119 @@ -4159,15 +6016,29 @@ msgid "Support script" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:121 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:126 -msgid "`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." +msgid "" +"`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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:133 -msgid "You can simply download the batch file and include it in your project unchanged." +msgid "" +"You can simply download the batch file and include it in your project " +"unchanged." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:137 @@ -4175,7 +6046,14 @@ msgid "Access to the built wheels" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:139 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:147 @@ -4187,19 +6065,33 @@ msgid "Testing with tox" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:152 -msgid "Many projects use the `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." +msgid "" +"Many projects use the `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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:156 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:160 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:165 -msgid "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" +msgid "" +"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" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:170 @@ -4219,23 +6111,46 @@ msgid "``LIB``" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:175 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:181 -msgid "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 Travis or 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)." +msgid "" +"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 Travis or 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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:188 -msgid "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``." +msgid "" +"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``." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:192 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:197 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:203 @@ -4243,11 +6158,19 @@ msgid "Automatically uploading wheels" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:205 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:210 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:216 @@ -4255,11 +6178,19 @@ msgid "External dependencies" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:218 -msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." +msgid "" +"The supplied scripts will successfully build any distribution that does not " +"rely on 3rd party external libraries for the build." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:221 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:230 @@ -4279,7 +6210,9 @@ msgid "Tool recommendations" msgstr "" #: ../source/guides/tool-recommendations.rst:7 -msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." +msgid "" +"If you're familiar with Python packaging and installation, and just want to " +"know what tools are currently recommended, then here it is." msgstr "" #: ../source/guides/tool-recommendations.rst:12 @@ -4287,7 +6220,10 @@ msgid "Application dependency management" msgstr "" #: ../source/guides/tool-recommendations.rst:14 -msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." +msgid "" +"Use :ref:`pipenv` to manage library dependencies when developing Python " +"applications. See :doc:`../tutorials/managing-dependencies` for more details " +"on using ``pipenv``." msgstr "" #: ../source/guides/tool-recommendations.rst:18 @@ -4311,15 +6247,23 @@ msgid "Installation tool recommendations" msgstr "" #: ../source/guides/tool-recommendations.rst:29 -msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" +msgid "" +"Use :ref:`pip` to install Python :term:`packages ` " +"from :term:`PyPI `. [1]_ [2]_ Depending on how :" +"ref:`pip` is installed, you may need to also install :ref:`wheel` to get the " +"benefit of wheel caching. [3]_" msgstr "" #: ../source/guides/tool-recommendations.rst:34 -msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" +msgid "" +"Use :ref:`virtualenv`, or `venv`_ to isolate application specific " +"dependencies from a shared Python installation. [4]_" msgstr "" #: ../source/guides/tool-recommendations.rst:37 -msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" +msgid "" +"If you're looking for management of fully integrated cross-platform software " +"stacks, consider:" msgstr "" #: ../source/guides/tool-recommendations.rst:40 @@ -4327,7 +6271,9 @@ msgid ":ref:`buildout`: primarily focused on the web development community" msgstr "" #: ../source/guides/tool-recommendations.rst:42 -msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." +msgid "" +":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the " +"scientific community." msgstr "" #: ../source/guides/tool-recommendations.rst:47 @@ -4335,15 +6281,22 @@ msgid "Packaging tool recommendations" msgstr "" #: ../source/guides/tool-recommendations.rst:49 -msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" +msgid "" +"Use :ref:`setuptools` to define projects and create :term:`Source " +"Distributions `. [5]_ [6]_" msgstr "" #: ../source/guides/tool-recommendations.rst:52 -msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." +msgid "" +"Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:" +"`wheel project ` to create :term:`wheels `. This is " +"especially beneficial, if your project contains binary extensions." msgstr "" #: ../source/guides/tool-recommendations.rst:56 -msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." +msgid "" +"Use `twine `_ for uploading distributions " +"to :term:`PyPI `." msgstr "" #: ../source/guides/tool-recommendations.rst:61 @@ -4351,39 +6304,75 @@ msgid "Publishing platform migration" msgstr "" #: ../source/guides/tool-recommendations.rst:63 -msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." +msgid "" +"The original Python Package Index implementation (previously hosted at `pypi." +"python.org `_) has been phased out in favour of an " +"updated implementation hosted at `pypi.org `_." msgstr "" #: ../source/guides/tool-recommendations.rst:67 -msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." +msgid "" +"See :ref:`Migrating to PyPI.org` for more information on the status of the " +"migration, and what settings to change in your clients." msgstr "" #: ../source/guides/tool-recommendations.rst:72 -msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." +msgid "" +"There are some cases where you might choose to use ``easy_install`` (from :" +"ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` " +"(which pip doesn't support). For a detailed breakdown, see :ref:`pip vs " +"easy_install`." msgstr "" #: ../source/guides/tool-recommendations.rst:77 -msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." +msgid "" +"The acceptance of :pep:`453` means that :ref:`pip` will be available by " +"default in most installations of Python 3.4 or later. See the :pep:" +"`rationale section <453#rationale>` from :pep:`453` as for why pip was " +"chosen." msgstr "" #: ../source/guides/tool-recommendations.rst:82 -msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." +msgid "" +"`get-pip.py `_ and :ref:" +"`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv " +"` do not currently. Also, the common \"python-pip\" package that's " +"found in various linux distros, does not depend on \"python-wheel\" " +"currently." msgstr "" #: ../source/guides/tool-recommendations.rst:88 -msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." +msgid "" +"Beginning with Python 3.4, ``venv`` will create virtualenv environments with " +"``pip`` installed, thereby making it an equal alternative to :ref:" +"`virtualenv`. However, using :ref:`virtualenv` will still be recommended for " +"users that need cross-version consistency." msgstr "" #: ../source/guides/tool-recommendations.rst:93 -msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." +msgid "" +"Although you can use pure ``distutils`` for many projects, it does not " +"support defining dependencies on other projects and is missing several " +"convenience utilities for automatically populating distribution metadata " +"correctly that are provided by ``setuptools``. Being outside the standard " +"library, ``setuptools`` also offers a more consistent feature set across " +"different versions of Python, and (unlike ``distutils``), recent versions of " +"``setuptools`` support all of the modern metadata fields described in :ref:" +"`core-metadata`." msgstr "" #: ../source/guides/tool-recommendations.rst:102 -msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." +msgid "" +"Even for projects that do choose to use ``distutils``, when :ref:`pip` " +"installs such projects directly from source (rather than installing from a " +"prebuilt :term:`wheel ` file), it will actually build your project " +"using :ref:`setuptools` instead." msgstr "" #: ../source/guides/tool-recommendations.rst:107 -msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." +msgid "" +"`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` " +"in June 2013, thereby making setuptools the default choice for packaging." msgstr "" #: ../source/guides/using-manifest-in.rst:5 @@ -4391,11 +6380,23 @@ msgid "Including files in source distributions with ``MANIFEST.in``" msgstr "" #: ../source/guides/using-manifest-in.rst:7 -msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." +msgid "" +"When building a :term:`source distribution ` for your package, by default only a minimal set of files are " +"included. You may find yourself wanting to include extra files in the " +"source distribution, such as an authors/contributors file, a :file:`docs/` " +"directory, or a directory of data files used for testing purposes. There " +"may even be extra files that you *need* to include; for example, if your :" +"file:`setup.py` computes your project's ``long_description`` by reading from " +"both a README and a changelog file, you'll need to include both those files " +"in the sdist so that people that build or install from the sdist get the " +"correct results." msgstr "" #: ../source/guides/using-manifest-in.rst:17 -msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." +msgid "" +"Adding & removing files to & from the source distribution is done by writing " +"a :file:`MANIFEST.in` file at the project root." msgstr "" #: ../source/guides/using-manifest-in.rst:22 @@ -4407,11 +6408,15 @@ msgid "The following files are included in a source distribution by default:" msgstr "" #: ../source/guides/using-manifest-in.rst:26 -msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" +msgid "" +"all Python source files implied by the ``py_modules`` and ``packages`` " +"``setup()`` arguments" msgstr "" #: ../source/guides/using-manifest-in.rst:28 -msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" +msgid "" +"all C source files mentioned in the ``ext_modules`` or ``libraries`` " +"``setup()`` arguments" msgstr "" #: ../source/guides/using-manifest-in.rst:30 @@ -4419,15 +6424,21 @@ msgid "scripts specified by the ``scripts`` ``setup()`` argument" msgstr "" #: ../source/guides/using-manifest-in.rst:31 -msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" +msgid "" +"all files specified by the ``package_data`` and ``data_files`` ``setup()`` " +"arguments" msgstr "" #: ../source/guides/using-manifest-in.rst:33 -msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" +msgid "" +"the file specified by the ``license_file`` option in :file:`setup.cfg` " +"(setuptools 40.8.0+)" msgstr "" #: ../source/guides/using-manifest-in.rst:35 -msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" +msgid "" +"all files specified by the ``license_files`` option in :file:`setup.cfg` " +"(setuptools 42.0.0+)" msgstr "" #: ../source/guides/using-manifest-in.rst:37 @@ -4467,11 +6478,20 @@ msgid ":file:`MANIFEST.in`" msgstr "" #: ../source/guides/using-manifest-in.rst:47 -msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." +msgid "" +"After adding the above files to the sdist, the commands in :file:`MANIFEST." +"in` (if such a file exists) are executed in order to add and remove further " +"files to & from the sdist. Default files can even be removed from the sdist " +"with the appropriate :file:`MANIFEST.in` command." msgstr "" #: ../source/guides/using-manifest-in.rst:52 -msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." +msgid "" +"After processing the :file:`MANIFEST.in` file, setuptools removes the :file:" +"`build/` directory as well as any directories named :file:`RCS`, :file:" +"`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file " +"and an :file:`*.egg-info` directory. This behavior cannot be changed with :" +"file:`MANIFEST.in`." msgstr "" #: ../source/guides/using-manifest-in.rst:60 @@ -4479,7 +6499,10 @@ msgid ":file:`MANIFEST.in` commands" msgstr "" #: ../source/guides/using-manifest-in.rst:62 -msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" +msgid "" +"A :file:`MANIFEST.in` file consists of commands, one per line, instructing " +"setuptools to add or remove some set of files from the sdist. The commands " +"are:" msgstr "" #: ../source/guides/using-manifest-in.rst:67 @@ -4507,7 +6530,9 @@ msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" msgstr "" #: ../source/guides/using-manifest-in.rst:71 -msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgid "" +"Add all files under directories matching ``dir-pattern`` that match any of " +"the listed patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:72 @@ -4515,7 +6540,9 @@ msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" msgstr "" #: ../source/guides/using-manifest-in.rst:72 -msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgid "" +"Remove all files under directories matching ``dir-pattern`` that match any " +"of the listed patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:73 @@ -4523,7 +6550,8 @@ msgid ":samp:`global-include {pat1} {pat2} ...`" msgstr "" #: ../source/guides/using-manifest-in.rst:73 -msgid "Add all files anywhere in the source tree matching any of the listed patterns" +msgid "" +"Add all files anywhere in the source tree matching any of the listed patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:74 @@ -4531,7 +6559,9 @@ msgid ":samp:`global-exclude {pat1} {pat2} ...`" msgstr "" #: ../source/guides/using-manifest-in.rst:74 -msgid "Remove all files anywhere in the source tree matching any of the listed patterns" +msgid "" +"Remove all files anywhere in the source tree matching any of the listed " +"patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:75 @@ -4551,27 +6581,54 @@ msgid "Remove all files under directories matching ``dir-pattern``" msgstr "" #: ../source/guides/using-manifest-in.rst:79 -msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." +msgid "" +"The patterns here are glob-style patterns: ``*`` matches zero or more " +"regular filename characters (on Unix, everything except forward slash; on " +"Windows, everything except backslash and colon); ``?`` matches a single " +"regular filename character, and ``[chars]`` matches any one of the " +"characters between the square brackets (which may contain character ranges, " +"e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented " +"support for ``**`` matching zero or more characters including forward slash, " +"backslash, and colon." msgstr "" #: ../source/guides/using-manifest-in.rst:87 -msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." +msgid "" +"Directory patterns are relative to the root of the project directory; e.g., " +"``graft example*`` will include a directory named :file:`examples` in the " +"project root but will not include :file:`docs/examples/`." msgstr "" #: ../source/guides/using-manifest-in.rst:91 -msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." +msgid "" +"File & directory names in :file:`MANIFEST.in` should be ``/``-separated; " +"setuptools will automatically convert the slashes to the local platform's " +"appropriate directory separator." msgstr "" #: ../source/guides/using-manifest-in.rst:95 -msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" +msgid "" +"Commands are processed in the order they appear in the :file:`MANIFEST.in` " +"file. For example, given the commands::" msgstr "" #: ../source/guides/using-manifest-in.rst:101 -msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." +msgid "" +"the contents of the directory tree :file:`tests` will first be added to the " +"sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, " +"or ``.pyd`` extension will be removed from the sdist. If the commands were " +"in the opposite order, then ``*.pyc`` files etc. would be only be removed " +"from what was already in the sdist before adding :file:`tests`, and if :file:" +"`tests` happened to contain any ``*.pyc`` files, they would end up included " +"in the sdist because the exclusion happened before they were included." msgstr "" #: ../source/guides/using-testpypi.rst:7 -msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" +msgid "" +"``TestPyPI`` is a separate instance of the :term:`Python Package Index " +"(PyPI)` that allows you to try out the distribution tools and process " +"without worrying about affecting the real index. TestPyPI is hosted at `test." +"pypi.org `_" msgstr "" #: ../source/guides/using-testpypi.rst:13 @@ -4579,11 +6636,16 @@ msgid "Registering your account" msgstr "" #: ../source/guides/using-testpypi.rst:15 -msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." +msgid "" +"Because TestPyPI has a separate database from the live PyPI, you'll need a " +"separate user account for specifically for TestPyPI. Go to https://test.pypi." +"org/account/register/ to register your account." msgstr "" #: ../source/guides/using-testpypi.rst:19 -msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." +msgid "" +"The database for TestPyPI may be periodically pruned, so it is not unusual " +"for user accounts to be deleted." msgstr "" #: ../source/guides/using-testpypi.rst:24 @@ -4591,11 +6653,17 @@ msgid "Using TestPyPI with Twine" msgstr "" #: ../source/guides/using-testpypi.rst:26 -msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" +msgid "" +"You can upload your distributions to TestPyPI using :ref:`twine` by " +"specifying the ``--repository`` flag" msgstr "" #: ../source/guides/using-testpypi.rst:33 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgid "" +"You can see if your package has successfully uploaded by navigating to the " +"URL ``https://test.pypi.org/project/`` where " +"``sampleproject`` is the name of your project that you uploaded. It may take " +"a minute or two for your project to appear on the site." msgstr "" #: ../source/guides/using-testpypi.rst:39 @@ -4603,11 +6671,16 @@ msgid "Using TestPyPI with pip" msgstr "" #: ../source/guides/using-testpypi.rst:41 -msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" +msgid "" +"You can tell pip to download packages from TestPyPI instead of PyPI by " +"specifying the ``--index-url`` flag" msgstr "" #: ../source/guides/using-testpypi.rst:56 -msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" +msgid "" +"If you want to allow pip to also pull other packages from PyPI you can " +"specify ``--extra-index-url`` to point to PyPI. This is useful when the " +"package you're testing has dependencies:" msgstr "" #: ../source/guides/using-testpypi.rst:73 @@ -4615,16 +6688,19 @@ msgid "Setting up TestPyPI in :file:`.pypirc`" msgstr "" #: ../source/guides/using-testpypi.rst:75 -msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" +msgid "" +"If you want to avoid entering your username, you can configure TestPyPI in " +"your :file:`$HOME/.pypirc`:" msgstr "" -#: ../source/index.rst:3 -#: ../source/key_projects.rst:181 +#: ../source/index.rst:3 ../source/key_projects.rst:181 msgid "Python Packaging User Guide" msgstr "Guia de Usuário para Empacotamento de Python" #: ../source/index.rst:5 -msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." +msgid "" +"The Python Packaging User Guide (PyPUG) is a collection of tutorials and " +"guides for packaging Python software." msgstr "" #: ../source/index.rst:5 @@ -4632,11 +6708,16 @@ msgid "python, packaging, guide, tutorial" msgstr "" #: ../source/index.rst:24 -msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." +msgid "" +"Welcome to the *Python Packaging User Guide*, a collection of tutorials and " +"references to help you distribute and install Python packages with modern " +"tools." msgstr "" #: ../source/index.rst:28 -msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" +msgid "" +"This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. " +"We happily accept any :doc:`contributions and feedback `. 😊" msgstr "" #: ../source/index.rst:36 @@ -4644,23 +6725,34 @@ msgid "Get started" msgstr "" #: ../source/index.rst:38 -msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" +msgid "" +"Essential tools and concepts for working within the Python development " +"ecosystem are covered in our :doc:`tutorials/index` section:" msgstr "" #: ../source/index.rst:41 -msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" +msgid "" +"To learn how to install packages, see the :doc:`tutorial on installing " +"packages `" msgstr "" #: ../source/index.rst:43 -msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" +msgid "" +"To learn how to manage dependencies in a version controlled project, see " +"the :doc:`tutorial on managing application dependencies `" msgstr "" #: ../source/index.rst:45 -msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" +msgid "" +"To learn how to package and distribute your projects, see the :doc:`tutorial " +"on packaging and distributing `" msgstr "" #: ../source/index.rst:47 -msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" +msgid "" +"To get an overview of packaging options for Python libraries and " +"applications, see the :doc:`Overview of Python Packaging `" msgstr "" #: ../source/index.rst:52 @@ -4668,23 +6760,33 @@ msgid "Learn more" msgstr "" #: ../source/index.rst:54 -msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" +msgid "" +"Beyond our :doc:`tutorials/index`, this guide has several other resources:" msgstr "" #: ../source/index.rst:56 -msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." +msgid "" +"The :doc:`guides/index` section for walk throughs, such as :doc:`guides/" +"installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." msgstr "" #: ../source/index.rst:58 -msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." +msgid "" +"The :doc:`discussions/index` section for in-depth references on topics such " +"as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-" +"vs-easy-install`." msgstr "" #: ../source/index.rst:60 -msgid "The :doc:`specifications/index` section for packaging interoperability specifications." +msgid "" +"The :doc:`specifications/index` section for packaging interoperability " +"specifications." msgstr "" #: ../source/index.rst:62 -msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." +msgid "" +"Additionally, there is a list of :doc:`other projects ` " +"maintained by members of the Python Packaging Authority." msgstr "" #: ../source/key_projects.rst:6 @@ -4692,7 +6794,9 @@ msgid "Project Summaries" msgstr "" #: ../source/key_projects.rst:8 -msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." +msgid "" +"Summaries and links for the most relevant projects in the space of Python " +"installation and packaging." msgstr "" #: ../source/key_projects.rst:14 @@ -4704,11 +6808,18 @@ msgid "bandersnatch" msgstr "" #: ../source/key_projects.rst:21 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:25 -msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." +msgid "" +"``bandersnatch`` is a PyPI mirroring client designed to efficiently create a " +"complete mirror of the contents of PyPI. Organizations thus save bandwidth " +"and latency on package downloads (especially in the context of automated " +"tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." msgstr "" #: ../source/key_projects.rst:35 @@ -4716,11 +6827,16 @@ msgid "build" msgstr "" #: ../source/key_projects.rst:37 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI " +"`__" msgstr "" #: ../source/key_projects.rst:42 -msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." +msgid "" +"``build`` is a :pep:`517` compatible Python package builder. It provides a " +"CLI to build packages, as well as a Python API." msgstr "" #: ../source/key_projects.rst:49 @@ -4728,11 +6844,19 @@ msgid "cibuildwheel" msgstr "" #: ../source/key_projects.rst:51 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | " +"`Discussions `__ | " +"`Discord #cibuildwheel `__" msgstr "" #: ../source/key_projects.rst:58 -msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." +msgid "" +"``cibuildwheel`` is a Python package that builds :term:`wheels ` for " +"all common platforms and Python versions on most CI systems. Also see :ref:" +"`multibuild`." msgstr "" #: ../source/key_projects.rst:64 @@ -4740,15 +6864,31 @@ msgid "distlib" msgstr "" #: ../source/key_projects.rst:66 -msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:71 -msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." +msgid "" +"``distlib`` is a library which implements low-level functions that relate to " +"packaging and distribution of Python software. ``distlib`` implements " +"several relevant PEPs (Python Enhancement Proposal standards) and is useful " +"for developers of third-party packaging tools to make and upload binary and " +"source :term:`distributions `, achieve " +"interoperability, resolve dependencies, manage package resources, and do " +"other similar functions." msgstr "" #: ../source/key_projects.rst:80 -msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." +msgid "" +"Unlike the stricter :ref:`packaging` project (below), which specifically " +"implements modern Python packaging interoperability standards, ``distlib`` " +"also attempts to provide reasonable fallback behaviours when asked to handle " +"legacy packages and metadata that predate the modern interoperability " +"standards and fall into the subset of packages that are incompatible with " +"those standards." msgstr "" #: ../source/key_projects.rst:90 @@ -4756,19 +6896,36 @@ msgid "packaging" msgstr "" #: ../source/key_projects.rst:92 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:97 -msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." +msgid "" +"Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." msgstr "" #: ../source/key_projects.rst:99 -msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." +msgid "" +"The core utilities in the packaging library handle version handling, " +"specifiers, markers, requirements, tags, and similar attributes and tasks " +"for Python packages. Most Python users rely on this library without needing " +"to explicitly call it; developers of the other Python packaging, " +"distribution, and installation tools listed here often use its functionality " +"to parse, discover, and otherwise handle dependency attributes." msgstr "" #: ../source/key_projects.rst:107 -msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." +msgid "" +"This project specifically focuses on implementing the modern Python " +"packaging interoperability standards defined at :ref:`packaging-" +"specifications`, and will report errors for sufficiently old legacy packages " +"that are incompatible with those standards. In contrast, the :ref:`distlib` " +"project is a more permissive library that attempts to provide a plausible " +"reading of ambiguous metadata in cases where :ref:`packaging` will instead " +"report on error." msgstr "" #: ../source/key_projects.rst:119 @@ -4777,15 +6934,24 @@ msgid "pip" msgstr "" #: ../source/key_projects.rst:121 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:126 -msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." +msgid "" +"The most popular tool for installing Python packages, and the one included " +"with modern versions of Python." msgstr "" #: ../source/key_projects.rst:129 -msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." +msgid "" +"It provides the essential core features for finding, downloading, and " +"installing packages from PyPI and other Python package indexes, and can be " +"incorporated into a wide range of development workflows via its command-line " +"interface (CLI)." msgstr "" #: ../source/key_projects.rst:137 @@ -4793,15 +6959,28 @@ msgid "Pipenv" msgstr "" #: ../source/key_projects.rst:139 -msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Source `__ | `Issues `__ | `PyPI " +"`__" msgstr "" #: ../source/key_projects.rst:144 -msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." +msgid "" +"Pipenv is a project that aims to bring the best of all packaging worlds to " +"the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:" +"`virtualenv` into one single toolchain. It features very pretty terminal " +"colors." msgstr "" #: ../source/key_projects.rst:148 -msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." +msgid "" +"Pipenv aims to help users manage environments, dependencies, and imported " +"packages on the command line. It also works well on Windows (which other " +"tools often underserve), makes and checkes file hashes, to ensure compliance " +"with hash-locked dependency specifiers, and eases uninstallation of packages " +"and dependencies. It is used by Python users and system administrators, but " +"has been less maintained since late 2018." msgstr "" #: ../source/key_projects.rst:159 @@ -4813,7 +6992,10 @@ msgid "`Source `__" msgstr "" #: ../source/key_projects.rst:163 -msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." +msgid "" +":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level " +"application-centric alternative to :ref:`pip`'s lower-level :file:" +"`requirements.txt` file." msgstr "" #: ../source/key_projects.rst:170 @@ -4821,15 +7003,22 @@ msgid "pipx" msgstr "" #: ../source/key_projects.rst:172 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:176 -msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." +msgid "" +"pipx is a tool to install and run Python command-line applications without " +"causing dependency conflicts with other packages installed on the system." msgstr "" #: ../source/key_projects.rst:183 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:187 @@ -4841,11 +7030,18 @@ msgid "readme_renderer" msgstr "" #: ../source/key_projects.rst:194 -msgid "`GitHub and docs `__ | `PyPI `__" +msgid "" +"`GitHub and docs `__ | `PyPI " +"`__" msgstr "" #: ../source/key_projects.rst:197 -msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." +msgid "" +"``readme_renderer`` is a library that package developers use to render their " +"user documentation (README) files into HTML from markup languages such as " +"Markdown or reStructuredText. Developers call it on its own or via :ref:" +"`twine`, as part of their release management process, to check that their " +"package descriptions will properly display on PyPI." msgstr "" #: ../source/key_projects.rst:208 @@ -4853,15 +7049,24 @@ msgid "setuptools" msgstr "" #: ../source/key_projects.rst:210 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:215 -msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." +msgid "" +"setuptools (which includes ``easy_install``) is a collection of enhancements " +"to the Python distutils that allow you to more easily build and distribute " +"Python :term:`distributions `, especially ones that " +"have dependencies on other packages." msgstr "" #: ../source/key_projects.rst:220 -msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." +msgid "" +"`distribute`_ was a fork of setuptools that was merged back into setuptools " +"(in v0.7), thereby making setuptools the primary choice for Python packaging." msgstr "" #: ../source/key_projects.rst:227 @@ -4869,15 +7074,32 @@ msgid "trove-classifiers" msgstr "" #: ../source/key_projects.rst:229 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Issues `__ | `GitHub " +"`__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:233 -msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." +msgid "" +"trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically " +"describe their projects `_ so that users can better find projects " +"that match their needs on the PyPI." msgstr "" #: ../source/key_projects.rst:239 -msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." +msgid "" +"The trove-classifiers package contains a list of valid classifiers and " +"deprecated classifiers (which are paired with the classifiers that replace " +"them). Use this package to validate classifiers used in packages intended " +"for uploading to PyPI. As this list of classifiers is published as code, you " +"can install and import it, giving you a more convenient workflow compared to " +"referring to the `list published on PyPI `_. " +"The `issue tracker `_ for " +"the project hosts discussions on proposed classifiers and requests for new " +"classifiers." msgstr "" #: ../source/key_projects.rst:253 @@ -4885,24 +7107,41 @@ msgid "twine" msgstr "" #: ../source/key_projects.rst:255 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:260 -msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." +msgid "" +"Twine is the primary tool developers use to upload packages to the Python " +"Package Index or other Python package indexes. It is a command-line program " +"that passes program files and metadata to a web API. Developers use it " +"because it's the official PyPI upload tool, it's fast and secure, it's " +"maintained, and it reliably works." msgstr "" -#: ../source/key_projects.rst:270 -#: ../source/overview.rst:415 +#: ../source/key_projects.rst:270 ../source/overview.rst:415 msgid "virtualenv" msgstr "" #: ../source/key_projects.rst:272 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:277 -msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgid "" +"virtualenv is a tool which uses the command-line path environment variable " +"to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional " +"functionality, compared to :ref:`venv`, by supporting Python 2.7 and by " +"providing convenient features for configuring, maintaining, duplicating, and " +"troubleshooting the virtual environments. For more information, see the " +"section on :ref:`Creating and using Virtual Environments`." msgstr "" #: ../source/key_projects.rst:290 @@ -4910,11 +7149,16 @@ msgid "Warehouse" msgstr "" #: ../source/key_projects.rst:292 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:296 -msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." +msgid "" +"The current codebase powering the :term:`Python Package Index (PyPI)`. It is " +"hosted at `pypi.org `_. The default source for :ref:`pip` " +"downloads." msgstr "" #: ../source/key_projects.rst:304 @@ -4922,15 +7166,26 @@ msgid "wheel" msgstr "" #: ../source/key_projects.rst:306 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:311 -msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." +msgid "" +"Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` " +"extension for creating :term:`wheel distributions `. Additionally, " +"it offers its own command line utility for creating and installing wheels." msgstr "" #: ../source/key_projects.rst:315 -msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." +msgid "" +"See also `auditwheel `__, a tool that " +"package developers use to check and fix Python packages they are making in " +"the binary wheel format. It provides functionality to discover dependencies, " +"check metadata for compliance, and repair the wheel and metadata to properly " +"link and include external shared libraries in a package." msgstr "" #: ../source/key_projects.rst:324 @@ -4942,11 +7197,17 @@ msgid "bento" msgstr "" #: ../source/key_projects.rst:331 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:336 -msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." +msgid "" +"Bento is a packaging tool solution for Python software, targeted as an " +"alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's " +"philosophy is reproducibility, extensibility and simplicity (in that order)." msgstr "" #: ../source/key_projects.rst:344 @@ -4954,11 +7215,18 @@ msgid "buildout" msgstr "" #: ../source/key_projects.rst:346 -msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" +msgid "" +"`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:351 -msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." +msgid "" +"Buildout is a Python-based build system for creating, assembling and " +"deploying applications from multiple parts, some of which may be non-Python-" +"based. It lets you create a buildout configuration and reproduce the same " +"software later." msgstr "" #: ../source/key_projects.rst:358 @@ -4970,15 +7238,32 @@ msgid "`Docs `__" msgstr "" #: ../source/key_projects.rst:362 -msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." +msgid "" +"conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution " +"from `Anaconda, Inc `__ specifically " +"aimed at the scientific community, and in particular on Windows where the " +"installation of binary extensions is often difficult." msgstr "" #: ../source/key_projects.rst:369 -msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." +msgid "" +"Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, " +"but provides many of their combined features in terms of package management, " +"virtual environment management and deployment of binary extensions." msgstr "" #: ../source/key_projects.rst:373 -msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." +msgid "" +"Conda does not install packages from PyPI and can install only from the " +"official Anaconda repositories, or anaconda.org (a place for user-" +"contributed *conda* packages), or a local (e.g. intranet) package server. " +"However, note that :ref:`pip` can be installed into, and work side-by-side " +"with conda for managing :term:`distributions ` from " +"PyPI. Also, `conda skeleton `__ is a tool to make " +"Python packages installable by conda by first fetching them from PyPI and " +"modifying their metadata." msgstr "" #: ../source/key_projects.rst:386 @@ -4986,11 +7271,17 @@ msgid "devpi" msgstr "" #: ../source/key_projects.rst:388 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:392 -msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." +msgid "" +"devpi features a powerful PyPI-compatible server and PyPI proxy cache with a " +"complementary command line tool to drive packaging, testing and release " +"activities with Python. devpi also provides a browsable and searchable web " +"interface." msgstr "" #: ../source/key_projects.rst:401 @@ -4998,15 +7289,25 @@ msgid "flit" msgstr "" #: ../source/key_projects.rst:403 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:407 -msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." +msgid "" +"Flit provides a simple way to upload pure Python packages and modules to " +"PyPI. It focuses on `making the easy things easy `_ for " +"packaging. Flit can generate a configuration file to quickly set up a simple " +"project, build source distributions and wheels, and upload them to PyPI." msgstr "" #: ../source/key_projects.rst:412 -msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." +msgid "" +"Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on " +"tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to " +"upload them to PyPI. Flit requires Python 3, but you can use it to " +"distribute modules for Python 2, so long as they can be imported on Python 3." msgstr "" #: ../source/key_projects.rst:422 @@ -5014,11 +7315,22 @@ msgid "enscons" msgstr "" #: ../source/key_projects.rst:424 -msgid "`Source `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Source `__ | `Issues `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:428 -msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." +msgid "" +"Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-" +"compatible source distributions and wheels without using distutils or " +"setuptools, including distributions with C extensions. Enscons has a " +"different architecture and philosophy than :ref:`distutils`. Rather than " +"adding build features to a Python packaging system, enscons adds Python " +"packaging to a general purpose build system. Enscons helps you to build " +"sdists that can be automatically built by :ref:`pip`, and wheels that are " +"independent of enscons." msgstr "" #: ../source/key_projects.rst:443 @@ -5026,11 +7338,20 @@ msgid "Hashdist" msgstr "" #: ../source/key_projects.rst:445 -msgid "`Docs `__ | `GitHub `__" +msgid "" +"`Docs `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:448 -msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." +msgid "" +"Hashdist is a library for building non-root software distributions. Hashdist " +"is trying to be “the Debian of choice for cases where Debian technology " +"doesn’t work”. The best way for Pythonistas to think about Hashdist may be a " +"more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed " +"at solving the problem of installing scientific software, and making package " +"distribution stateless, cached, and branchable. It is used by some " +"researchers but has been lacking in maintenance since 2016." msgstr "" #: ../source/key_projects.rst:460 @@ -5038,11 +7359,18 @@ msgid "hatch" msgstr "" #: ../source/key_projects.rst:462 -msgid "`GitHub and Docs `__ | `PyPI `__" +msgid "" +"`GitHub and Docs `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:465 -msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." +msgid "" +"Hatch is a unified command-line tool meant to conveniently manage " +"dependencies and environment isolation for Python developers. Python package " +"developers use Hatch to configure, version, specify dependencies for, and " +"publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload " +"packages to PyPI, and :ref:`pip` to download and install packages." msgstr "" #: ../source/key_projects.rst:475 @@ -5054,7 +7382,10 @@ msgid "`GitHub `__" msgstr "" #: ../source/key_projects.rst:479 -msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." +msgid "" +"Multibuild is a set of CI scripts for building and testing Python :term:" +"`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :" +"ref:`cibuildwheel`." msgstr "" #: ../source/key_projects.rst:485 @@ -5062,11 +7393,18 @@ msgid "pex" msgstr "" #: ../source/key_projects.rst:487 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:491 -msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." +msgid "" +"pex is both a library and tool for generating :file:`.pex` (Python " +"EXecutable) files, standalone Python environments in the spirit of :ref:" +"`virtualenv`. :file:`.pex` files are just carefully constructed zip files " +"with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are " +"designed to make deployment of Python applications as simple as ``cp``." msgstr "" #: ../source/key_projects.rst:500 @@ -5074,11 +7412,20 @@ msgid "pip-tools" msgstr "" #: ../source/key_projects.rst:502 -msgid "`GitHub and Docs `__ | `PyPI `__" +msgid "" +"`GitHub and Docs `__ | `PyPI " +"`__" msgstr "" #: ../source/key_projects.rst:505 -msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." +msgid "" +"pip-tools is a suite of tools meant for Python system administrators and " +"release managers who particularly want to keep their builds deterministic " +"yet stay up to date with new versions of their dependencies. Users can " +"specify particular release of their dependencies via hash, conveniently make " +"a properly formatted list of requirements from information in other parts of " +"their program, update all dependencies (a feature :ref:`pip` currently does " +"not provide), and create layers of constraints for the program to obey." msgstr "" #: ../source/key_projects.rst:517 @@ -5086,11 +7433,17 @@ msgid "piwheels" msgstr "" #: ../source/key_projects.rst:519 -msgid "`Website `__ | `Docs `__ | `GitHub `__" +msgid "" +"`Website `__ | `Docs `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:523 -msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." +msgid "" +"piwheels is a website, and software underpinning it, that fetches source " +"code distribution packages from PyPI and compiles them into binary wheels " +"that are optimized for installation onto Raspberry Pi computers. Raspberry " +"Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." msgstr "" #: ../source/key_projects.rst:532 @@ -5098,11 +7451,19 @@ msgid "poetry" msgstr "" #: ../source/key_projects.rst:534 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:538 -msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." +msgid "" +"poetry is a command-line tool to handle dependency installation and " +"isolation as well as building and packaging of Python packages. It uses " +"``pyproject.toml`` and, instead of depending on the resolver functionality " +"within :ref:`pip`, provides its own dependency resolver. It attempts to " +"speed users' experience of installation and dependency resolution by locally " +"caching metadata about dependencies." msgstr "" #: ../source/key_projects.rst:548 @@ -5110,11 +7471,20 @@ msgid "pypiserver" msgstr "" #: ../source/key_projects.rst:550 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | " +"`GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:554 -msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." +msgid "" +"pypiserver is a minimalist application that serves as a private Python " +"package index within organizations, implementing a simple API and browser " +"interface. You can upload private packages using standard upload tools, and " +"users can download and install them with :ref:`pip`, without publishing them " +"publicly. Organizations who use pypiserver usually download packages both " +"from pypiserver and from PyPI." msgstr "" #: ../source/key_projects.rst:564 @@ -5122,11 +7492,22 @@ msgid "scikit-build" msgstr "" #: ../source/key_projects.rst:566 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:570 -msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." +msgid "" +"Scikit-build is an improved build system generator for CPython C/C++/Fortran/" +"Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :" +"ref:`pip`. It internally uses `cmake `__ " +"(available on PyPI) to provide better support for additional compilers, " +"build systems, cross compilation, and locating dependencies and their " +"associated build requirements. To speed up and parallelize the build of " +"large projects, the user can install `ninja `__ (also available on PyPI)." msgstr "" #: ../source/key_projects.rst:582 @@ -5134,23 +7515,42 @@ msgid "shiv" msgstr "" #: ../source/key_projects.rst:584 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:588 -msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." +msgid "" +"shiv is a command line utility for building fully self contained Python " +"zipapps as outlined in :pep:`441`, but with all their dependencies included. " +"Its primary goal is making distributing Python applications and command line " +"tools fast & easy." msgstr "" #: ../source/key_projects.rst:598 -msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" +msgid "" +"`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" msgstr "" #: ../source/key_projects.rst:603 -msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." +msgid "" +"A flexible package manager designed to support multiple versions, " +"configurations, platforms, and compilers. Spack is like Homebrew, but " +"packages are written in Python and parameterized to allow easy swapping of " +"compilers, library versions, build options, etc. Arbitrarily many versions " +"of packages can coexist on the same system. Spack was designed for rapidly " +"building high performance scientific applications on clusters and " +"supercomputers." msgstr "" #: ../source/key_projects.rst:611 -msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." +msgid "" +"Spack is not in PyPI (yet), but it requires no installation and can be used " +"immediately after cloning from GitHub." msgstr "" #: ../source/key_projects.rst:617 @@ -5158,11 +7558,18 @@ msgid "zest.releaser" msgstr "" #: ../source/key_projects.rst:619 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:623 -msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." +msgid "" +"``zest.releaser`` is a Python package release tool providing an abstraction " +"layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to " +"automate incrementing package version numbers, updating changelogs, tagging " +"releases in source control, and uploading new packages to PyPI." msgstr "" #: ../source/key_projects.rst:630 @@ -5174,11 +7581,17 @@ msgid "ensurepip" msgstr "" #: ../source/key_projects.rst:637 -msgid "`Docs `__ | `Issues `__" +msgid "" +"`Docs `__ | `Issues " +"`__" msgstr "" #: ../source/key_projects.rst:640 -msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." +msgid "" +"A package in the Python Standard Library that provides support for " +"bootstrapping :ref:`pip` into an existing Python installation or virtual " +"environment. In most cases, end users won't use this module, but rather it " +"will be used during the build of the Python distribution." msgstr "" #: ../source/key_projects.rst:649 @@ -5186,15 +7599,26 @@ msgid "distutils" msgstr "" #: ../source/key_projects.rst:651 -msgid "`Docs `__ | `Issues `__" +msgid "" +"`Docs `__ | `Issues " +"`__" msgstr "" #: ../source/key_projects.rst:654 -msgid "The original Python packaging system, added to the standard library in Python 2.0." +msgid "" +"The original Python packaging system, added to the standard library in " +"Python 2.0." msgstr "" #: ../source/key_projects.rst:657 -msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." +msgid "" +"Due to the challenges of maintaining a packaging system where feature " +"updates are tightly coupled to language runtime updates, direct usage of :" +"ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being " +"the preferred replacement. :ref:`Setuptools` not only provides features that " +"plain :ref:`distutils` doesn't offer (such as dependency declarations and " +"entry point declarations), it also provides a consistent build interface and " +"feature set across all supported Python versions." msgstr "" #: ../source/key_projects.rst:670 @@ -5202,11 +7626,17 @@ msgid "venv" msgstr "" #: ../source/key_projects.rst:672 -msgid "`Docs `__ | `Issues `__" +msgid "" +"`Docs `__ | `Issues `__" msgstr "" #: ../source/key_projects.rst:675 -msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgid "" +"A package in the Python Standard Library (starting with Python 3.3) for " +"creating :term:`Virtual Environments `. For more " +"information, see the section on :ref:`Creating and using Virtual " +"Environments`." msgstr "" #: ../source/news.rst:2 @@ -5278,7 +7708,8 @@ msgid "April 2019" msgstr "" #: ../source/news.rst:31 -msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" +msgid "" +"Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" msgstr "" #: ../source/news.rst:32 @@ -5302,7 +7733,9 @@ msgid "February 2019" msgstr "" #: ../source/news.rst:41 -msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" +msgid "" +"Elaborate upon the differences between the tutorial and the real packaging " +"process. (:pr:`602`)" msgstr "" #: ../source/news.rst:42 @@ -5386,7 +7819,8 @@ msgid "Replaced tar command with working command. (:pr:`552`)" msgstr "" #: ../source/news.rst:72 -msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" +msgid "" +"Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" msgstr "" #: ../source/news.rst:75 @@ -5398,7 +7832,8 @@ msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" msgstr "" #: ../source/news.rst:77 -msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" +msgid "" +"Moved the Overview to a task based lead in along with the others. (:pr:`540`)" msgstr "" #: ../source/news.rst:78 @@ -5442,7 +7877,8 @@ msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" msgstr "" #: ../source/news.rst:97 -msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" +msgid "" +"Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" msgstr "" #: ../source/news.rst:98 @@ -5506,7 +7942,8 @@ msgid "Updated \"installing scientific packages\". (:pr:`455`)" msgstr "" #: ../source/news.rst:119 -msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" +msgid "" +"Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" msgstr "" #: ../source/news.rst:120 @@ -5522,7 +7959,9 @@ msgid "February 2018" msgstr "" #: ../source/news.rst:126 -msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" +msgid "" +"Added python3-venv and python3-pip to Debian installation instructions. (:pr:" +"`445`)" msgstr "" #: ../source/news.rst:127 @@ -5530,7 +7969,8 @@ msgid "Updated PyPI migration info. (:pr:`439`)" msgstr "" #: ../source/news.rst:128 -msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" +msgid "" +"Added a warning about managing multiple versions with pipenv. (:pr:`430`)" msgstr "" #: ../source/news.rst:129 @@ -5558,7 +7998,8 @@ msgid "December 2017" msgstr "" #: ../source/news.rst:141 -msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" +msgid "" +"Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" msgstr "" #: ../source/news.rst:142 @@ -5578,15 +8019,20 @@ msgid "November 2017" msgstr "" #: ../source/news.rst:149 -msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" +msgid "" +"Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" msgstr "" #: ../source/news.rst:150 -msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" +msgid "" +"Updated the *Single Sourcing Package Version* tutorial to reflect pip's " +"current strategy. (:pr:`400`)" msgstr "" #: ../source/news.rst:152 -msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" +msgid "" +"Added documentation about the ``py_modules`` argument to ``setup``. (:pr:" +"`398`)" msgstr "" #: ../source/news.rst:153 @@ -5598,11 +8044,14 @@ msgid "October 2017" msgstr "" #: ../source/news.rst:158 -msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" +msgid "" +"Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" msgstr "" #: ../source/news.rst:159 -msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" +msgid "" +"Created a new guide for managing packages using ``pip`` and ``virtualenv``. " +"(:pr:`385`)" msgstr "" #: ../source/news.rst:160 @@ -5614,7 +8063,9 @@ msgid "September 2017" msgstr "" #: ../source/news.rst:165 -msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" +msgid "" +"Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:" +"`379`)" msgstr "" #: ../source/news.rst:167 @@ -5626,7 +8077,9 @@ msgid "August 2017" msgstr "" #: ../source/news.rst:172 -msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" +msgid "" +"Added a new, experimental tutorial on installing packages using ``Pipenv``. " +"(:pr:`369`)" msgstr "" #: ../source/news.rst:173 @@ -5650,15 +8103,20 @@ msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" msgstr "" #: ../source/news.rst:181 -msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" +msgid "" +"Updated this guide's ``readme`` with instructions on how to build the guide " +"locally. (:pr:`356`)" msgstr "" #: ../source/news.rst:182 -msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" +msgid "" +"Made the new ``TestPyPI`` URL more visible, adding note to homepage about " +"pypi.org. (:pr:`354`)" msgstr "" #: ../source/news.rst:183 -msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" +msgid "" +"Added a note about the removal of the explicit registration API. (:pr:`347`)" msgstr "" #: ../source/news.rst:186 @@ -5674,11 +8132,14 @@ msgid "Added documentation for ``python_requires``. (:pr:`338`)" msgstr "" #: ../source/news.rst:190 -msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" +msgid "" +"Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:" +"pr:`335`)" msgstr "" #: ../source/news.rst:191 -msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" +msgid "" +"Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" msgstr "" #: ../source/news.rst:192 @@ -5710,7 +8171,8 @@ msgid "May 2017" msgstr "" #: ../source/news.rst:202 -msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" +msgid "" +"Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" msgstr "" #: ../source/news.rst:203 @@ -5718,7 +8180,9 @@ msgid "Added contributor and style guide. (:pr:`307`)" msgstr "" #: ../source/news.rst:204 -msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" +msgid "" +"Documented ``pip`` and ``easy_install``'s differences for per-project " +"indexes. (:pr:`233`)" msgstr "" #: ../source/news.rst:207 @@ -5730,11 +8194,15 @@ msgid "Added travis configuration for testing pull requests. (:pr:`300`)" msgstr "" #: ../source/news.rst:210 -msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" +msgid "" +"Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:" +"`299`)" msgstr "" #: ../source/news.rst:211 -msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" +msgid "" +"Removed the ``twine register`` reference in the *Distributing Packages* " +"tutorial. (:pr:`271`)" msgstr "" #: ../source/news.rst:212 @@ -5746,23 +8214,33 @@ msgid "Added a topic on namespace packages. (:pr:`290`)" msgstr "" #: ../source/news.rst:214 -msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" +msgid "" +"Added documentation explaining prominently how to install ``pip`` in ``/usr/" +"local``. (:pr:`230`)" msgstr "" #: ../source/news.rst:215 -msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" +msgid "" +"Updated development mode documentation to mention that order of local " +"packages matters. (:pr:`208`)" msgstr "" #: ../source/news.rst:216 -msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" +msgid "" +"Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted " +"projects (:pr:`239`)" msgstr "" #: ../source/news.rst:217 -msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" +msgid "" +"Swaped order of :file:`setup.py` arguments for the upload command, as order " +"is significant. (:pr:`260`)" msgstr "" #: ../source/news.rst:219 -msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" +msgid "" +"Explained how to install from unsupported sources using a helper " +"application. (:pr:`289`)" msgstr "" #: ../source/news.rst:223 @@ -5786,15 +8264,26 @@ msgid "An Overview of Packaging for Python" msgstr "" #: ../source/overview.rst:7 -msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." +msgid "" +"As a general-purpose programming language, Python is designed to be used in " +"many ways. You can build web sites or industrial robots or a game for your " +"friends to play, and much more, all using the same core technology." msgstr "" #: ../source/overview.rst:12 -msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." +msgid "" +"Python's flexibility is why the first step in every Python project must be " +"to think about the project's audience and the corresponding environment " +"where the project will run. It might seem strange to think about packaging " +"before writing code, but this process does wonders for avoiding future " +"headaches." msgstr "" #: ../source/overview.rst:18 -msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." +msgid "" +"This overview provides a general-purpose decision tree for reasoning about " +"Python's plethora of packaging options. Read on to choose the best " +"technology for your next project." msgstr "" #: ../source/overview.rst:26 @@ -5802,23 +8291,36 @@ msgid "Thinking about deployment" msgstr "" #: ../source/overview.rst:28 -msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" +msgid "" +"Packages exist to be installed (or *deployed*), so before you package " +"anything, you'll want to have some answers to the deployment questions below:" msgstr "" #: ../source/overview.rst:32 -msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" +msgid "" +"Who are your software's users? Will your software be installed by other " +"developers doing software development, operations people in a datacenter, or " +"a less software-savvy group?" msgstr "" #: ../source/overview.rst:35 -msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" +msgid "" +"Is your software intended to run on servers, desktops, mobile clients " +"(phones, tablets, etc.), or embedded in dedicated devices?" msgstr "" #: ../source/overview.rst:37 -msgid "Is your software installed individually, or in large deployment batches?" +msgid "" +"Is your software installed individually, or in large deployment batches?" msgstr "" #: ../source/overview.rst:39 -msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." +msgid "" +"Packaging is all about target environment and deployment experience. There " +"are many answers to the questions above and each combination of " +"circumstances has its own solutions. With this information, the following " +"overview will guide you to the packaging technologies best suited to your " +"project." msgstr "" #: ../source/overview.rst:46 @@ -5826,11 +8328,19 @@ msgid "Packaging Python libraries and tools" msgstr "" #: ../source/overview.rst:48 -msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." +msgid "" +"You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are " +"just a few of the tools Python's ecosystem provides for distributing Python " +"code to developers, which you can read about in :doc:`guides/distributing-" +"packages-using-setuptools`." msgstr "" #: ../source/overview.rst:53 -msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." +msgid "" +"The following approaches to packaging are meant for libraries and tools used " +"by technical audience in a development setting. If you're looking for ways " +"to package Python for a non-technical audience and/or a production setting, " +"skip ahead to :ref:`packaging-applications`." msgstr "" #: ../source/overview.rst:59 @@ -5838,15 +8348,27 @@ msgid "Python modules" msgstr "" #: ../source/overview.rst:61 -msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." +msgid "" +"A Python file, provided it only relies on the standard library, can be " +"redistributed and reused. You will also need to ensure it's written for the " +"right version of Python, and only relies on the standard library." msgstr "" #: ../source/overview.rst:66 -msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." +msgid "" +"This is great for sharing simple scripts and snippets between people who " +"both have compatible Python versions (such as via email, StackOverflow, or " +"GitHub gists). There are even some entire Python libraries that offer this " +"as an option, such as `bottle.py `_ and " +"`boltons `_." msgstr "" #: ../source/overview.rst:73 -msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." +msgid "" +"However, this pattern won't scale for projects that consist of multiple " +"files, need additional libraries, or need a specific version of Python, " +"hence the options below." msgstr "" #: ../source/overview.rst:78 @@ -5854,31 +8376,60 @@ msgid "Python source distributions" msgstr "" #: ../source/overview.rst:80 -msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." +msgid "" +"If your code consists of multiple Python files, it's usually organized into " +"a directory structure. Any directory containing Python files can comprise " +"an :term:`Import Package`." msgstr "" #: ../source/overview.rst:84 -msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." +msgid "" +"Because packages consist of multiple files, they are harder to distribute. " +"Most protocols support transferring only one file at a time (when was the " +"last time you clicked a link and it downloaded multiple files?). It's easier " +"to get incomplete transfers, and harder to guarantee code integrity at the " +"destination." msgstr "" #: ../source/overview.rst:90 -msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." +msgid "" +"So long as your code contains nothing but pure Python code, and you know " +"your deployment environment supports your version of Python, then you can " +"use Python's native packaging tools to create a *source* :term:`Distribution " +"Package`, or *sdist* for short." msgstr "" #: ../source/overview.rst:95 -msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." +msgid "" +"Python's *sdists* are compressed archives (``.tar.gz`` files) containing one " +"or more packages or modules. If your code is pure-Python, and you only " +"depend on other Python packages, you can `go here to learn more `_." msgstr "" #: ../source/overview.rst:100 -msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." +msgid "" +"If you rely on any non-Python code, or non-Python packages (such as `libxml2 " +"`_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next " +"section, which also has many advantages for pure-Python libraries." msgstr "" #: ../source/overview.rst:107 -msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" +msgid "" +"Python and PyPI support multiple distributions providing different " +"implementations of the same package. For instance the unmaintained-but-" +"seminal `PIL distribution `_ provides the PIL " +"package, and so does `Pillow `_, an " +"actively-maintained fork of PIL!" msgstr "" #: ../source/overview.rst:114 -msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." +msgid "" +"This Python packaging superpower makes it possible for Pillow to be a drop-" +"in replacement for PIL, just by changing your project's ``install_requires`` " +"or ``requirements.txt``." msgstr "" #: ../source/overview.rst:119 @@ -5886,23 +8437,43 @@ msgid "Python binary distributions" msgstr "" #: ../source/overview.rst:121 -msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." +msgid "" +"So much of Python's practical power comes from its ability to integrate with " +"the software ecosystem, in particular libraries written in C, C++, Fortran, " +"Rust, and other languages." msgstr "" #: ../source/overview.rst:125 -msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." +msgid "" +"Not all developers have the right tools or experiences to build these " +"components written in these compiled languages, so Python created the :term:" +"`Wheel`, a package format designed to ship libraries with compiled " +"artifacts. In fact, Python's package installer, ``pip``, always prefers " +"wheels because installation is always faster, so even pure-Python packages " +"work better with wheels." msgstr "" #: ../source/overview.rst:132 -msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." +msgid "" +"Binary distributions are best when they come with source distributions to " +"match. Even if you don't upload wheels of your code for every operating " +"system, by uploading the sdist, you're enabling users of other platforms to " +"still build it for themselves. Default to publishing both sdist and wheel " +"archives together, *unless* you're creating artifacts for a very specific " +"use case where you know the recipient only needs one or the other." msgstr "" #: ../source/overview.rst:140 -msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." +msgid "" +"Python and PyPI make it easy to upload both wheels and sdists together. Just " +"follow the :doc:`tutorials/packaging-projects` tutorial." msgstr "" #: ../source/overview.rst:148 -msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." +msgid "" +"Python's recommended built-in library and tool packaging technologies. " +"Excerpted from `The Packaging Gradient (2017) `_." msgstr "" #: ../source/overview.rst:155 @@ -5910,23 +8481,39 @@ msgid "Packaging Python applications" msgstr "" #: ../source/overview.rst:157 -msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." +msgid "" +"So far we've only discussed Python's native distribution tools. Based on our " +"introduction, you would be correct to infer these built-in approaches only " +"target environments which have Python, and an audience who knows how to " +"install Python packages." msgstr "" #: ../source/overview.rst:162 -msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." +msgid "" +"With the variety of operating systems, configurations, and people out there, " +"this assumption is only safe when targeting a developer audience." msgstr "" #: ../source/overview.rst:166 -msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." +msgid "" +"Python's native packaging is mostly built for distributing reusable code, " +"called libraries, between developers. You can piggyback **tools**, or basic " +"applications for developers, on top of Python's library packaging, using " +"technologies like `setuptools entry_points `_." msgstr "" #: ../source/overview.rst:172 -msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." +msgid "" +"Libraries are building blocks, not complete applications. For distributing " +"applications, there's a whole new world of technologies out there." msgstr "" #: ../source/overview.rst:176 -msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." +msgid "" +"The next few sections organize these application packaging options according " +"to their dependencies on the target environment, so you can choose the right " +"one for your project." msgstr "" #: ../source/overview.rst:181 @@ -5934,15 +8521,27 @@ msgid "Depending on a framework" msgstr "" #: ../source/overview.rst:183 -msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." +msgid "" +"Some types of Python applications, like web site backends and other network " +"services, are common enough that they have frameworks to enable their " +"development and packaging. Other types of applications, like dynamic web " +"frontends and mobile clients, are complex enough to target that a framework " +"becomes more than a convenience." msgstr "" #: ../source/overview.rst:189 -msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." +msgid "" +"In all these cases, it makes sense to work backwards, from the framework's " +"packaging and deployment story. Some frameworks include a deployment system " +"which wraps the technologies outlined in the rest of the guide. In these " +"cases, you'll want to defer to your framework's packaging guide for the " +"easiest and most reliable production experience." msgstr "" #: ../source/overview.rst:195 -msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." +msgid "" +"If you ever wonder how these platforms and frameworks work under the hood, " +"you can always read the sections beyond." msgstr "" #: ../source/overview.rst:199 @@ -5950,11 +8549,15 @@ msgid "Service platforms" msgstr "" #: ../source/overview.rst:201 -msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." +msgid "" +"If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku " +"or Google App Engine, you are going to want to follow their respective " +"packaging guides." msgstr "" #: ../source/overview.rst:205 -msgid "`Heroku `_" +msgid "" +"`Heroku `_" msgstr "" #: ../source/overview.rst:206 @@ -5974,11 +8577,16 @@ msgid "\"Serverless\" frameworks like `Zappa `_" msgstr "" #: ../source/overview.rst:211 -msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." +msgid "" +"In all these setups, the platform takes care of packaging and deployment, as " +"long as you follow their patterns. Most software does not fit one of these " +"templates, hence the existence of all the other options below." msgstr "" #: ../source/overview.rst:216 -msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." +msgid "" +"If you're developing software that will be deployed to machines you own, " +"users' personal computers, or any other arrangement, read on." msgstr "" #: ../source/overview.rst:220 @@ -5986,11 +8594,16 @@ msgid "Web browsers and mobile applications" msgstr "" #: ../source/overview.rst:222 -msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." +msgid "" +"Python's steady advances are leading it into new spaces. These days you can " +"write a mobile app or web application frontend in Python. While the language " +"may be familiar, the packaging and deployment practices are brand new." msgstr "" #: ../source/overview.rst:227 -msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" +msgid "" +"If you're planning on releasing to these new frontiers, you'll want to check " +"out the following frameworks, and refer to their packaging guides:" msgstr "" #: ../source/overview.rst:231 @@ -6010,7 +8623,10 @@ msgid "`Flexx `_" msgstr "" #: ../source/overview.rst:236 -msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." +msgid "" +"If you are *not* interested in using a framework or platform, or just wonder " +"about some of the technologies and techniques utilized by the frameworks " +"above, continue reading below." msgstr "" #: ../source/overview.rst:241 @@ -6018,7 +8634,12 @@ msgid "Depending on a pre-installed Python" msgstr "" #: ../source/overview.rst:243 -msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." +msgid "" +"Pick an arbitrary computer, and depending on the context, there's a very " +"good chance Python is already installed. Included by default in most Linux " +"and Mac operating systems for many years now, you can reasonably depend on " +"Python preexisting in your data centers or on the personal machines of " +"developers and data scientists." msgstr "" #: ../source/overview.rst:249 @@ -6030,7 +8651,9 @@ msgid "`PEX `_ (Python EXecutable)" msgstr "" #: ../source/overview.rst:252 -msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" +msgid "" +"`zipapp `_ (does not help " +"manage dependencies, requires Python 3.5+)" msgstr "" #: ../source/overview.rst:253 @@ -6038,11 +8661,17 @@ msgid "`shiv `_ (requires Python 3)" msgstr "" #: ../source/overview.rst:255 -msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." +msgid "" +"Of all the approaches here, depending on a pre-installed Python relies the " +"most on the target environment. Of course, this also makes for the smallest " +"package, as small as single-digit megabytes, or even kilobytes." msgstr "" #: ../source/overview.rst:260 -msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." +msgid "" +"In general, decreasing the dependency on the target system increases the " +"size of our package, so the solutions here are roughly arranged by " +"increasing size of output." msgstr "" #: ../source/overview.rst:267 @@ -6050,11 +8679,24 @@ msgid "Depending on a separate software distribution ecosystem" msgstr "" #: ../source/overview.rst:269 -msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." +msgid "" +"For a long time many operating systems, including Mac and Windows, lacked " +"built-in package management. Only recently did these OSes gain so-called " +"\"app stores\", but even those focus on consumer applications and offer " +"little for developers." msgstr "" #: ../source/overview.rst:274 -msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." +msgid "" +"Developers long sought remedies, and in this struggle, emerged with their " +"own package management solutions, such as `Homebrew `_. " +"The most relevant alternative for Python developers is a package ecosystem " +"called `Anaconda `_. Anaconda is built around Python and is " +"increasingly common in academic, analytical, and other data-oriented " +"environments, even making its way `into server-oriented environments " +"`_." msgstr "" #: ../source/overview.rst:284 @@ -6062,15 +8704,21 @@ msgid "Instructions on building and publishing for the Anaconda ecosystem:" msgstr "" #: ../source/overview.rst:286 -msgid "`Building libraries and applications with conda `_" +msgid "" +"`Building libraries and applications with conda `_" msgstr "" #: ../source/overview.rst:287 -msgid "`Transitioning a native Python package to Anaconda `_" +msgid "" +"`Transitioning a native Python package to Anaconda `_" msgstr "" #: ../source/overview.rst:289 -msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" +msgid "" +"A similar model involves installing an alternative Python distribution, but " +"does not support arbitrary operating system-level packages:" msgstr "" #: ../source/overview.rst:293 @@ -6090,15 +8738,24 @@ msgid "Bringing your own Python executable" msgstr "" #: ../source/overview.rst:302 -msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." +msgid "" +"Computing as we know it is defined by the ability to execute programs. Every " +"operating system natively supports one or more formats of program they can " +"natively execute." msgstr "" #: ../source/overview.rst:306 -msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." +msgid "" +"There are many techniques and technologies which turn your Python program " +"into one of these formats, most of which involve embedding the Python " +"interpreter and any other dependencies into a single executable file." msgstr "" #: ../source/overview.rst:311 -msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." +msgid "" +"This approach, called *freezing*, offers wide compatibility and seamless " +"user experience, though often requires multiple technologies, and a good " +"amount of effort." msgstr "" #: ../source/overview.rst:315 @@ -6110,11 +8767,14 @@ msgid "`pyInstaller `_ - Cross-platform" msgstr "" #: ../source/overview.rst:318 -msgid "`cx_Freeze `_ - Cross-platform" +msgid "" +"`cx_Freeze `_ - Cross-platform" msgstr "" #: ../source/overview.rst:319 -msgid "`constructor `_ - For command-line installers" +msgid "" +"`constructor `_ - For command-line " +"installers" msgstr "" #: ../source/overview.rst:320 @@ -6126,7 +8786,9 @@ msgid "`py2app `_ - Mac only" msgstr "" #: ../source/overview.rst:322 -msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" +msgid "" +"`bbFreeze `_ - Windows, Linux, Python 2 " +"only" msgstr "" #: ../source/overview.rst:323 @@ -6138,7 +8800,9 @@ msgid "`pynsist `_ - Windows only" msgstr "" #: ../source/overview.rst:326 -msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." +msgid "" +"Most of the above imply single-user deployments. For multi-component server " +"applications, see `Chef Omnibus `_." msgstr "" #: ../source/overview.rst:332 @@ -6146,15 +8810,24 @@ msgid "Bringing your own userspace" msgstr "" #: ../source/overview.rst:334 -msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." +msgid "" +"An increasing number of operating systems -- including Linux, Mac OS, and " +"Windows -- can be set up to run applications packaged as lightweight images, " +"using a relatively modern arrangement often referred to as `operating-system-" +"level virtualization `_, or *containerization*." msgstr "" #: ../source/overview.rst:341 -msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." +msgid "" +"These techniques are mostly Python agnostic, because they package whole OS " +"filesystems, not just Python or Python packages." msgstr "" #: ../source/overview.rst:344 -msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" +msgid "" +"Adoption is most extensive among Linux servers, where the technology " +"originated and where the technologies below work best:" msgstr "" #: ../source/overview.rst:347 @@ -6178,11 +8851,18 @@ msgid "Bringing your own kernel" msgstr "" #: ../source/overview.rst:355 -msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." +msgid "" +"Most operating systems support some form of classical virtualization, " +"running applications packaged as images containing a full operating system " +"of their own. Running these virtual machines, or VMs, is a mature approach, " +"widespread in data center environments." msgstr "" #: ../source/overview.rst:360 -msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" +msgid "" +"These techniques are mostly reserved for larger scale deployments in data " +"centers, though certain complex applications can benefit from this " +"packaging. Technologies are Python agnostic, and include:" msgstr "" #: ../source/overview.rst:364 @@ -6190,11 +8870,16 @@ msgid "`Vagrant `_" msgstr "" #: ../source/overview.rst:365 -msgid "`VHD `_, `AMI `_, and `other formats `_" +msgid "" +"`VHD `_, `AMI `_, and `other formats `_" msgstr "" #: ../source/overview.rst:366 -msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" +msgid "" +"`OpenStack `_ - A cloud " +"management system in Python, with extensive VM support" msgstr "" #: ../source/overview.rst:369 @@ -6202,19 +8887,31 @@ msgid "Bringing your own hardware" msgstr "" #: ../source/overview.rst:371 -msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." +msgid "" +"The most all-encompassing way to ship your software would be to ship it " +"already-installed on some hardware. This way, your software's user would " +"require only electricity." msgstr "" #: ../source/overview.rst:375 -msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." +msgid "" +"Whereas the virtual machines described above are primarily reserved for the " +"tech-savvy, you can find hardware appliances being used by everyone from the " +"most advanced data centers to the youngest children." msgstr "" #: ../source/overview.rst:379 -msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." +msgid "" +"Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the " +"datacenter or your users' homes. They plug and play, and you can call it a " +"day." msgstr "" #: ../source/overview.rst:389 -msgid "The simplified gamut of technologies used to package Python applications." +msgid "" +"The simplified gamut of technologies used to package Python applications." msgstr "" #: ../source/overview.rst:392 @@ -6222,7 +8919,9 @@ msgid "What about..." msgstr "" #: ../source/overview.rst:394 -msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." +msgid "" +"The sections above can only summarize so much, and you might be wondering " +"about some of the more conspicuous gaps." msgstr "" #: ../source/overview.rst:398 @@ -6230,19 +8929,40 @@ msgid "Operating system packages" msgstr "" #: ../source/overview.rst:400 -msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." +msgid "" +"As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some " +"operating systems have package managers of their own. If you're very sure of " +"the operating system you're targeting, you can depend directly on a format " +"like `deb `_ (for Debian, " +"Ubuntu, etc.) or `RPM `_ " +"(for Red Hat, Fedora, etc.), and use that built-in package manager to take " +"care of installation, and even deployment. You can even use `FPM `_ to generate both deb " +"and RPMs from the same source." msgstr "" #: ../source/overview.rst:411 -msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." +msgid "" +"In most deployment pipelines, the OS package manager is just one piece of " +"the puzzle." msgstr "" #: ../source/overview.rst:417 -msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." +msgid "" +"`Virtualenvs `_ have been an indispensable tool for multiple generations of Python " +"developer, but are slowly fading from view, as they are being wrapped by " +"higher-level tools. With packaging in particular, virtualenvs are used as a " +"primitive in `the dh-virtualenv tool `_ and `osnap `_, " +"both of which wrap virtualenvs in a self-contained way." msgstr "" #: ../source/overview.rst:427 -msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." +msgid "" +"For production deployments, do not rely on running ``python -m pip install`` " +"from the Internet into a virtualenv, as one might do in a development " +"environment. The overview above is full of much better solutions." msgstr "" #: ../source/overview.rst:432 @@ -6250,11 +8970,20 @@ msgid "Security" msgstr "Segurança" #: ../source/overview.rst:434 -msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." +msgid "" +"The further down the gradient you come, the harder it gets to update " +"components of your package. Everything is more tightly bound together." msgstr "" #: ../source/overview.rst:437 -msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." +msgid "" +"For example, if a kernel security issue emerges, and you're deploying " +"containers, the host system's kernel can be updated without requiring a new " +"build on behalf of the application. If you deploy VM images, you'll need a " +"new build. Whether or not this dynamic makes one option more secure is still " +"a bit of an old debate, going back to the still-unsettled matter of `static " +"versus dynamic linking `_." msgstr "" #: ../source/overview.rst:446 @@ -6262,7 +8991,12 @@ msgid "Wrap up" msgstr "" #: ../source/overview.rst:448 -msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." +msgid "" +"Packaging in Python has a bit of a reputation for being a bumpy ride. This " +"impression is mostly a byproduct of Python's versatility. Once you " +"understand the natural boundaries between each packaging solution, you begin " +"to realize that the varied landscape is a small price Python programmers pay " +"for using one of the most balanced, flexible languages available." msgstr "" #: ../source/specifications/binary-distribution-format.rst:6 @@ -6270,7 +9004,9 @@ msgid "Binary distribution format" msgstr "" #: ../source/specifications/binary-distribution-format.rst:8 -msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." +msgid "" +"The binary distribution format (:term:`wheel `) was originally " +"defined in :pep:`427`. The current version of the specification is here." msgstr "" #: ../source/specifications/binary-distribution-format.rst:13 @@ -6282,7 +9018,14 @@ msgid "This PEP describes a built-package format for Python called \"wheel\"." msgstr "" #: ../source/specifications/binary-distribution-format.rst:17 -msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." +msgid "" +"A wheel is a ZIP-format archive with a specially formatted file name and the " +"``.whl`` extension. It contains a single distribution nearly as it would be " +"installed according to PEP 376 with a particular installation scheme. " +"Although a specialized installer is recommended, a wheel file may be " +"installed by simply unpacking into site-packages with the standard 'unzip' " +"tool while preserving enough information to spread its contents out onto " +"their final paths at any later time." msgstr "" #: ../source/specifications/binary-distribution-format.rst:27 @@ -6290,7 +9033,9 @@ msgid "PEP Acceptance" msgstr "" #: ../source/specifications/binary-distribution-format.rst:29 -msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" +msgid "" +"This PEP was accepted, and the defined wheel version updated to 1.0, by Nick " +"Coghlan on 16th February, 2013 [1]_" msgstr "" #: ../source/specifications/binary-distribution-format.rst:34 @@ -6298,11 +9043,22 @@ msgid "Rationale" msgstr "" #: ../source/specifications/binary-distribution-format.rst:36 -msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." +msgid "" +"Python needs a package format that is easier to install than sdist. Python's " +"sdist packages are defined by and require the distutils and setuptools build " +"systems, running arbitrary code to build-and-install, and re-compile, code " +"just so it can be installed into a new virtualenv. This system of " +"conflating build-install is slow, hard to maintain, and hinders innovation " +"in both build systems and installers." msgstr "" #: ../source/specifications/binary-distribution-format.rst:43 -msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." +msgid "" +"Wheel attempts to remedy these problems by providing a simpler interface " +"between the build system and the installer. The wheel binary package format " +"frees installers from having to know about the build system, saves time by " +"amortizing compile time over many installations, and removes the need to " +"install a build system in the target environment." msgstr "" #: ../source/specifications/binary-distribution-format.rst:52 @@ -6326,11 +9082,14 @@ msgid "Parse ``distribution-1.0.dist-info/WHEEL``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:62 -msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." +msgid "" +"Check that installer is compatible with Wheel-Version. Warn if minor " +"version is greater, abort if major version is greater." msgstr "" #: ../source/specifications/binary-distribution-format.rst:64 -msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." +msgid "" +"If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:66 @@ -6342,15 +9101,24 @@ msgid "Spread." msgstr "" #: ../source/specifications/binary-distribution-format.rst:70 -msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." +msgid "" +"Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is " +"data) ``distribution-1.0.data/``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:72 -msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." +msgid "" +"Move each subtree of ``distribution-1.0.data/`` onto its destination path. " +"Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of " +"destination directories, such as ``distribution-1.0.data/(purelib|platlib|" +"headers|scripts|data)``. The initially supported paths are taken from " +"``distutils.command.install``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:78 -msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." +msgid "" +"If applicable, update scripts starting with ``#!python`` to point to the " +"correct interpreter." msgstr "" #: ../source/specifications/binary-distribution-format.rst:80 @@ -6362,7 +9130,9 @@ msgid "Remove empty ``distribution-1.0.data`` directory." msgstr "" #: ../source/specifications/binary-distribution-format.rst:83 -msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" +msgid "" +"Compile any installed .py to .pyc. (Uninstallers should be smart enough to " +"remove .pyc even if it is not mentioned in RECORD.)" msgstr "" #: ../source/specifications/binary-distribution-format.rst:87 @@ -6374,11 +9144,17 @@ msgid "Rewrite ``#!python``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:90 -msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." +msgid "" +"In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/" +"``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!" +"python'``, rewrite to point to the correct interpreter. Unix installers may " +"need to add the +x bit to these files if the archive was created on Windows." msgstr "" #: ../source/specifications/binary-distribution-format.rst:96 -msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." +msgid "" +"The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI " +"script instead of a console script." msgstr "" #: ../source/specifications/binary-distribution-format.rst:102 @@ -6386,7 +9162,10 @@ msgid "Generate script wrappers." msgstr "" #: ../source/specifications/binary-distribution-format.rst:100 -msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." +msgid "" +"In wheel, scripts packaged on Unix systems will certainly not have " +"accompanying .exe wrappers. Windows installers may want to add them during " +"install." msgstr "" #: ../source/specifications/binary-distribution-format.rst:105 @@ -6398,7 +9177,11 @@ msgid "Place ``.dist-info`` at the end of the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:108 -msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." +msgid "" +"Archivers are encouraged to place the ``.dist-info`` files physically at the " +"end of the archive. This enables some potentially interesting ZIP tricks " +"including the ability to amend the metadata without rewriting the entire " +"archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:115 @@ -6410,7 +9193,9 @@ msgid "File name convention" msgstr "" #: ../source/specifications/binary-distribution-format.rst:120 -msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." +msgid "" +"The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-" +"{abi tag}-{platform tag}.whl``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:124 @@ -6430,7 +9215,12 @@ msgid "build tag" msgstr "" #: ../source/specifications/binary-distribution-format.rst:130 -msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." +msgid "" +"Optional build number. Must start with a digit. Acts as a tie-breaker if " +"two wheel file names are the same in all other respects (i.e. name, version, " +"and other tags). Sort as an empty tuple if unspecified, else sort as a two-" +"item tuple with the first item being the initial digits as an ``int``, and " +"the second item being the remainder of the tag as a ``str``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:138 @@ -6458,11 +9248,18 @@ msgid "E.g. 'linux_x86_64', 'any'." msgstr "" #: ../source/specifications/binary-distribution-format.rst:146 -msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." +msgid "" +"For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of " +"a package called 'distribution', and is compatible with Python 2.7 (any " +"Python 2.7 implementation), with no ABI (pure Python), on any CPU " +"architecture." msgstr "" #: ../source/specifications/binary-distribution-format.rst:151 -msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." +msgid "" +"The last three components of the filename before the extension are called " +"\"compatibility tags.\" The compatibility tags express the package's basic " +"interpreter requirements and are detailed in PEP 425." msgstr "" #: ../source/specifications/binary-distribution-format.rst:156 @@ -6470,31 +9267,50 @@ msgid "Escaping and Unicode" msgstr "" #: ../source/specifications/binary-distribution-format.rst:158 -msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" +msgid "" +"As the components of the filename are separated by a dash (``-``, HYPHEN-" +"MINUS), this character cannot appear within any component. This is handled " +"as follows:" msgstr "" #: ../source/specifications/binary-distribution-format.rst:161 -msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." +msgid "" +"In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE " +"and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent " +"to :pep:`503` normalisation followed by replacing ``-`` with ``_``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:164 -msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." +msgid "" +"Version numbers should be normalised according to :pep:`440`. Normalised " +"version numbers cannot contain ``-``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:166 -msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." +msgid "" +"The remaining components may not contain ``-`` characters, so no escaping is " +"necessary." msgstr "" #: ../source/specifications/binary-distribution-format.rst:169 -msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." +msgid "" +"Tools producing wheels should verify that the filename components do not " +"contain ``-``, as the resulting file may not be processed correctly if they " +"do." msgstr "" #: ../source/specifications/binary-distribution-format.rst:172 -msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." +msgid "" +"The archive filename is Unicode. It will be some time before the tools are " +"updated to support non-ASCII filenames, but they are supported in this " +"specification." msgstr "" #: ../source/specifications/binary-distribution-format.rst:176 -msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." +msgid "" +"The filenames *inside* the archive are encoded as UTF-8. Although some ZIP " +"clients in common use do not properly display UTF-8 filenames, the encoding " +"is supported by both the ZIP specification and Python's ``zipfile``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:182 @@ -6502,11 +9318,17 @@ msgid "File contents" msgstr "" #: ../source/specifications/binary-distribution-format.rst:184 -msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" +msgid "" +"The contents of a wheel file, where {distribution} is replaced with the name " +"of the package, e.g. ``beaglevote`` and {version} is replaced with its " +"version, e.g. ``1.0.0``, consist of:" msgstr "" #: ../source/specifications/binary-distribution-format.rst:188 -msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." +msgid "" +"``/``, the root of the archive, contains all files to be installed in " +"``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and " +"``platlib`` are usually both ``site-packages``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:191 @@ -6514,19 +9336,30 @@ msgid "``{distribution}-{version}.dist-info/`` contains metadata." msgstr "" #: ../source/specifications/binary-distribution-format.rst:192 -msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." +msgid "" +"``{distribution}-{version}.data/`` contains one subdirectory for each non-" +"empty install scheme key not already covered, where the subdirectory name is " +"an index into a dictionary of install paths (e.g. ``data``, ``scripts``, " +"``include``, ``purelib``, ``platlib``)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:196 -msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." +msgid "" +"Python scripts must appear in ``scripts`` and begin with exactly ``b'#!" +"python'`` in order to enjoy script wrapper generation and ``#!python`` " +"rewriting at install time. They may have any or no extension." msgstr "" #: ../source/specifications/binary-distribution-format.rst:200 -msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." +msgid "" +"``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or " +"greater format metadata." msgstr "" #: ../source/specifications/binary-distribution-format.rst:202 -msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" +msgid "" +"``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive " +"itself in the same basic key: value format::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:212 @@ -6534,27 +9367,40 @@ msgid "``Wheel-Version`` is the version number of the Wheel specification." msgstr "" #: ../source/specifications/binary-distribution-format.rst:213 -msgid "``Generator`` is the name and optionally the version of the software that produced the archive." +msgid "" +"``Generator`` is the name and optionally the version of the software that " +"produced the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:215 -msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." +msgid "" +"``Root-Is-Purelib`` is true if the top level directory of the archive should " +"be installed into purelib; otherwise the root should be installed into " +"platlib." msgstr "" #: ../source/specifications/binary-distribution-format.rst:218 -msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." +msgid "" +"``Tag`` is the wheel's expanded compatibility tags; in the example the " +"filename would contain ``py2.py3-none-any``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:220 -msgid "``Build`` is the build number and is omitted if there is no build number." +msgid "" +"``Build`` is the build number and is omitted if there is no build number." msgstr "" #: ../source/specifications/binary-distribution-format.rst:221 -msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." +msgid "" +"A wheel installer should warn if Wheel-Version is greater than the version " +"it supports, and must fail if Wheel-Version has a greater major version than " +"the version it supports." msgstr "" #: ../source/specifications/binary-distribution-format.rst:224 -msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." +msgid "" +"Wheel, being an installation format that is intended to work across multiple " +"versions of Python, does not generally include .pyc files." msgstr "" #: ../source/specifications/binary-distribution-format.rst:226 @@ -6562,7 +9408,11 @@ msgid "Wheel does not contain setup.py or setup.cfg." msgstr "" #: ../source/specifications/binary-distribution-format.rst:228 -msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." +msgid "" +"This version of the wheel specification is based on the distutils install " +"schemes and does not define how to install files to other locations. The " +"layout offers a superset of the functionality provided by the existing " +"wininst and egg binary formats." msgstr "" #: ../source/specifications/binary-distribution-format.rst:235 @@ -6571,11 +9421,15 @@ msgid "The .dist-info directory" msgstr "" #: ../source/specifications/binary-distribution-format.rst:237 -msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." +msgid "" +"Wheel .dist-info directories include at a minimum METADATA, WHEEL, and " +"RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:239 -msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." +msgid "" +"METADATA is the package metadata, the same format as PKG-INFO as found at " +"the root of sdists." msgstr "" #: ../source/specifications/binary-distribution-format.rst:241 @@ -6583,7 +9437,12 @@ msgid "WHEEL is the wheel metadata specific to a build of the package." msgstr "" #: ../source/specifications/binary-distribution-format.rst:242 -msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." +msgid "" +"RECORD is a list of (almost) all the files in the wheel and their secure " +"hashes. Unlike PEP 376, every file except RECORD, which cannot contain a " +"hash of itself, must include its hash. The hash algorithm must be sha256 or " +"better; specifically, md5 and sha1 are not permitted, as signed wheel files " +"rely on the strong hashes in RECORD to validate the integrity of the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:248 @@ -6591,15 +9450,22 @@ msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:249 -msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." +msgid "" +"RECORD.jws is used for digital signatures. It is not mentioned in RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:251 -msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." +msgid "" +"RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME " +"signatures to secure their wheel files. It is not mentioned in RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:254 -msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." +msgid "" +"During extraction, wheel installers verify all the hashes in RECORD against " +"the file contents. Apart from RECORD and its signatures, installation will " +"fail if any file in the archive is not both mentioned and correctly hashed " +"in RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:261 @@ -6607,11 +9473,17 @@ msgid "The .data directory" msgstr "" #: ../source/specifications/binary-distribution-format.rst:263 -msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" +msgid "" +"Any file that is not normally installed inside site-packages goes into the ." +"data directory, named as the .dist-info directory but with the .data/ " +"extension::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:271 -msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." +msgid "" +"The .data directory contains subdirectories with the scripts, headers, " +"documentation and so forth from the distribution. During installation the " +"contents of these subdirectories are moved onto their destination paths." msgstr "" #: ../source/specifications/binary-distribution-format.rst:277 @@ -6619,15 +9491,29 @@ msgid "Signed wheel files" msgstr "" #: ../source/specifications/binary-distribution-format.rst:279 -msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" +msgid "" +"Wheel files include an extended RECORD that enables digital signatures. PEP " +"376's RECORD is altered to include a secure hash " +"``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with " +"no trailing = characters) as the second column instead of an md5sum. All " +"possible entries are hashed, including any generated files such as .pyc " +"files, but not RECORD which cannot contain its own hash. For example::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:290 -msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." +msgid "" +"The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD " +"at all since they can only be added after RECORD is generated. Every other " +"file in the archive must have a correct hash in RECORD or the installation " +"will fail." msgstr "" #: ../source/specifications/binary-distribution-format.rst:295 -msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" +msgid "" +"If JSON web signatures are used, one or more JSON Web Signature JSON " +"Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to " +"RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD " +"as the signature's JSON payload::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:302 @@ -6635,11 +9521,17 @@ msgid "(The hash value is the same format used in RECORD.)" msgstr "" #: ../source/specifications/binary-distribution-format.rst:304 -msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." +msgid "" +"If RECORD.p7s is used, it must contain a detached S/MIME format signature of " +"RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:307 -msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." +msgid "" +"A wheel installer is not required to understand digital signatures but MUST " +"verify the hashes in RECORD against the extracted file contents. When the " +"installer checks file hashes against RECORD, a separate signature checker " +"only needs to establish that RECORD matches the signature." msgstr "" #: ../source/specifications/binary-distribution-format.rst:312 @@ -6651,7 +9543,8 @@ msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" msgstr "" #: ../source/specifications/binary-distribution-format.rst:315 -msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" +msgid "" +"http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" msgstr "" #: ../source/specifications/binary-distribution-format.rst:316 @@ -6667,23 +9560,41 @@ msgid "Comparison to .egg" msgstr "" #: ../source/specifications/binary-distribution-format.rst:323 -msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." +msgid "" +"Wheel is an installation format; egg is importable. Wheel archives do not " +"need to include .pyc and are less tied to a specific Python version or " +"implementation. Wheel can install (pure Python) packages built with previous " +"versions of Python so you don't always have to wait for the packager to " +"catch up." msgstr "" #: ../source/specifications/binary-distribution-format.rst:328 -msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." +msgid "" +"Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible " +"with the new world of Python packaging and the new concepts it brings." msgstr "" #: ../source/specifications/binary-distribution-format.rst:331 -msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." +msgid "" +"Wheel has a richer file naming convention for today's multi-implementation " +"world. A single wheel archive can indicate its compatibility with a number " +"of Python language versions and implementations, ABIs, and system " +"architectures. Historically the ABI has been specific to a CPython release, " +"wheel is ready for the stable ABI." msgstr "" #: ../source/specifications/binary-distribution-format.rst:337 -msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." +msgid "" +"Wheel is lossless. The first wheel implementation bdist_wheel always " +"generates egg-info, and then converts it to a .whl. It is also possible to " +"convert existing eggs and bdist_wininst distributions." msgstr "" #: ../source/specifications/binary-distribution-format.rst:341 -msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." +msgid "" +"Wheel is versioned. Every wheel file contains the version of the wheel " +"specification and the implementation that packaged it. Hopefully the next " +"migration can simply be to Wheel 2.0." msgstr "" #: ../source/specifications/binary-distribution-format.rst:344 @@ -6699,7 +9610,13 @@ msgid "Wheel defines a .data directory. Should I put all my data there?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:354 -msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." +msgid "" +"This specification does not have an opinion on how you should organize your " +"code. The .data directory is just a place for any files that are not " +"normally installed inside ``site-packages`` or on the PYTHONPATH. In other " +"words, you may continue to use ``pkgutil.get_data(package, resource)`` even " +"though *those* files will usually not be distributed in *wheel's* ``.data`` " +"directory." msgstr "" #: ../source/specifications/binary-distribution-format.rst:363 @@ -6707,7 +9624,12 @@ msgid "Why does wheel include attached signatures?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:365 -msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." +msgid "" +"Attached signatures are more convenient than detached signatures because " +"they travel with the archive. Since only the individual files are signed, " +"the archive can be recompressed without invalidating the signature or " +"individual files can be verified without having to download the whole " +"archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:373 @@ -6715,7 +9637,10 @@ msgid "Why does wheel allow JWS signatures?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:375 -msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." +msgid "" +"The JOSE specifications of which JWS is a part are designed to be easy to " +"implement, a feature that is also one of wheel's primary design goals. JWS " +"yields a useful, concise pure-Python implementation." msgstr "" #: ../source/specifications/binary-distribution-format.rst:381 @@ -6723,11 +9648,15 @@ msgid "Why does wheel also allow S/MIME signatures?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:383 -msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." +msgid "" +"S/MIME signatures are allowed for users who need or want to use existing " +"public key infrastructure with wheel." msgstr "" #: ../source/specifications/binary-distribution-format.rst:386 -msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." +msgid "" +"Signed packages are only a basic building block in a secure package update " +"system. Wheel only provides the building block." msgstr "" #: ../source/specifications/binary-distribution-format.rst:391 @@ -6735,15 +9664,26 @@ msgid "What's the deal with \"purelib\" vs. \"platlib\"?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:393 -msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." +msgid "" +"Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is " +"significant on some platforms. For example, Fedora installs pure Python " +"packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent " +"packages to '/usr/lib64/pythonX.Y/site-packages'." msgstr "" #: ../source/specifications/binary-distribution-format.rst:398 -msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." +msgid "" +"A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-" +"{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: " +"true\" with those same files in the root, and it is legal to have files in " +"both the \"purelib\" and \"platlib\" categories." msgstr "" #: ../source/specifications/binary-distribution-format.rst:403 -msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." +msgid "" +"In practice a wheel should have only one of \"purelib\" or \"platlib\" " +"depending on whether it is pure Python or not and those files should be at " +"the root with the appropriate setting given for \"Root-is-purelib\"." msgstr "" #: ../source/specifications/binary-distribution-format.rst:409 @@ -6751,19 +9691,50 @@ msgid "Is it possible to import Python code directly from a wheel file?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:411 -msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." +msgid "" +"Technically, due to the combination of supporting installation via simple " +"extraction and using an archive format that is compatible with " +"``zipimport``, a subset of wheel files *do* support being placed directly on " +"``sys.path``. However, while this behaviour is a natural consequence of the " +"format design, actually relying on it is generally discouraged." msgstr "" #: ../source/specifications/binary-distribution-format.rst:417 -msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." +msgid "" +"Firstly, wheel *is* designed primarily as a distribution format, so skipping " +"the installation step also means deliberately avoiding any reliance on " +"features that assume full installation (such as being able to use standard " +"tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in " +"a way that can be properly tracked for auditing and security update " +"purposes, or integrating fully with the standard build machinery for C " +"extensions by publishing header files in the appropriate place)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:426 -msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." +msgid "" +"Secondly, while some Python software is written to support running directly " +"from a zip archive, it is still common for code to be written assuming it " +"has been fully installed. When that assumption is broken by trying to run " +"the software from a zip archive, the failures can often be obscure and hard " +"to diagnose (especially when they occur in third party libraries). The two " +"most common sources of problems with this are the fact that importing C " +"extensions from a zip archive is *not* supported by CPython (since doing so " +"is not supported directly by the dynamic loading machinery on any platform) " +"and that when running from a zip archive the ``__file__`` attribute no " +"longer refers to an ordinary filesystem path, but to a combination path that " +"includes both the location of the zip archive on the filesystem and the " +"relative path to the module inside the archive. Even when software correctly " +"uses the abstract resource APIs internally, interfacing with external " +"components may still require the availability of an actual on-disk file." msgstr "" #: ../source/specifications/binary-distribution-format.rst:443 -msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." +msgid "" +"Like metaclasses, monkeypatching and metapath importers, if you're not " +"already sure you need to take advantage of this feature, you almost " +"certainly don't need it. If you *do* decide to use it anyway, be aware that " +"many projects will require a failure to be reproduced with a fully installed " +"package before accepting it as a genuine bug." msgstr "" #: ../source/specifications/binary-distribution-format.rst:450 @@ -6775,11 +9746,15 @@ msgid "Since :pep:`427`, this specification has changed as follows:" msgstr "" #: ../source/specifications/binary-distribution-format.rst:454 -msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." +msgid "" +"The rules on escaping in wheel filenames were revised, to bring them into " +"line with what popular tools actually do (February 2021)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:461 -msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" +msgid "" +"PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-" +"February/124103.html)" msgstr "" #: ../source/specifications/binary-distribution-format.rst:466 @@ -6803,7 +9778,9 @@ msgid "Core metadata specifications" msgstr "" #: ../source/specifications/core-metadata.rst:7 -msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" +msgid "" +"Fields defined in the following specification should be considered valid, " +"complete and not subject to change. The required fields are:" msgstr "" #: ../source/specifications/core-metadata.rst:10 @@ -6823,15 +9800,33 @@ msgid "All the other fields are optional." msgstr "" #: ../source/specifications/core-metadata.rst:16 -msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." +msgid "" +"The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats " +"have been revised several times, and exactly which email RFC applies to " +"packaging metadata is not specified. In the absence of a precise definition, " +"the practical standard is set by what the standard library :mod:`python:" +"email.parser` module can parse using the :data:`~.python:email.policy." +"compat32` policy." msgstr "" #: ../source/specifications/core-metadata.rst:25 -msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." +msgid "" +"Although :pep:`566` defined a way to transform metadata into a JSON-" +"compatible dictionary, this is not yet used as a standard interchange " +"format. The need for tools to work with years worth of existing packages " +"makes it difficult to shift to a new format." msgstr "" #: ../source/specifications/core-metadata.rst:30 -msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." +msgid "" +"*Interpreting old metadata:* In :pep:`566`, the version specifier field " +"format specification was relaxed to accept the syntax used by popular " +"publishing tools (namely to remove the requirement that version specifiers " +"must be surrounded by parentheses). Metadata consumers may want to use the " +"more relaxed formatting rules even for metadata files that are nominally " +"less than version 2.1." msgstr "" #: ../source/specifications/core-metadata.rst:41 @@ -6839,15 +9834,25 @@ msgid "Metadata-Version" msgstr "" #: ../source/specifications/core-metadata.rst:45 -msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." +msgid "" +"Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", " +"\"2.1\" and \"2.2\"." msgstr "" #: ../source/specifications/core-metadata.rst:48 -msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." +msgid "" +"Automated tools consuming metadata SHOULD warn if ``metadata_version`` is " +"greater than the highest version they support, and MUST fail if " +"``metadata_version`` has a greater major version than the highest version " +"they support (as described in :pep:`440`, the major version is the value " +"before the first dot)." msgstr "" #: ../source/specifications/core-metadata.rst:54 -msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." +msgid "" +"For broader compatibility, build tools MAY choose to produce distribution " +"metadata using the lowest metadata version that includes all of the needed " +"fields." msgstr "" #: ../source/specifications/core-metadata.rst:58 @@ -6881,7 +9886,12 @@ msgid "Added additional restrictions on format from :pep:`508`" msgstr "" #: ../source/specifications/core-metadata.rst:72 -msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" +msgid "" +"The name of the distribution. The name field is the primary identifier for a " +"distribution. A valid name consists only of ASCII letters and numbers, " +"period, underscore and hyphen. It must start and end with a letter or " +"number. Distribution names are limited to those which match the following " +"regex (run with ``re.IGNORECASE``)::" msgstr "" #: ../source/specifications/core-metadata.rst:88 @@ -6889,7 +9899,9 @@ msgid "Version" msgstr "Versão" #: ../source/specifications/core-metadata.rst:92 -msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." +msgid "" +"A string containing the distribution's version number. This field must be " +"in the format specified in :pep:`440`." msgstr "" #: ../source/specifications/core-metadata.rst:101 @@ -6897,31 +9909,49 @@ msgid "Dynamic (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:105 -msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." +msgid "" +"A string containing the name of another core metadata field. The field names " +"``Name`` and ``Version`` may not be specified in this field." msgstr "" #: ../source/specifications/core-metadata.rst:108 -msgid "When found in the metadata of a source distribution, the following rules apply:" +msgid "" +"When found in the metadata of a source distribution, the following rules " +"apply:" msgstr "" #: ../source/specifications/core-metadata.rst:111 -msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." +msgid "" +"If a field is *not* marked as ``Dynamic``, then the value of the field in " +"any wheel built from the sdist MUST match the value in the sdist. If the " +"field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT " +"be present in the wheel." msgstr "" #: ../source/specifications/core-metadata.rst:115 -msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." +msgid "" +"If a field is marked as ``Dynamic``, it may contain any valid value in a " +"wheel built from the sdist (including not being present at all)." msgstr "" #: ../source/specifications/core-metadata.rst:118 -msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." +msgid "" +"If the sdist metadata version is older than version 2.2, then all fields " +"should be treated as if they were specified with ``Dynamic`` (i.e. there are " +"no special restrictions on the metadata of wheels built from the sdist)." msgstr "" #: ../source/specifications/core-metadata.rst:122 -msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." +msgid "" +"In any context other than a source distribution, ``Dynamic`` is for " +"information only, and indicates that the field value was calculated at wheel " +"build time, and may not be the same as the value in the sdist or in other " +"wheels for the project." msgstr "" #: ../source/specifications/core-metadata.rst:127 -msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." +msgid "" +"Full details of the semantics of ``Dynamic`` are described in :pep:`643`." msgstr "" #: ../source/specifications/core-metadata.rst:131 @@ -6929,7 +9959,10 @@ msgid "Platform (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:135 -msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." +msgid "" +"A Platform specification describing an operating system supported by the " +"distribution which is not listed in the \"Operating System\" Trove " +"classifiers. See \"Classifier\" below." msgstr "" #: ../source/specifications/core-metadata.rst:146 @@ -6937,7 +9970,11 @@ msgid "Supported-Platform (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:150 -msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." +msgid "" +"Binary distributions containing a PKG-INFO file will use the Supported-" +"Platform field in their metadata to specify the OS and CPU for which the " +"binary distribution was compiled. The semantics of the Supported-Platform " +"field are not specified in this PEP." msgstr "" #: ../source/specifications/core-metadata.rst:164 @@ -6953,23 +9990,41 @@ msgid "This field may be specified in the message body instead." msgstr "" #: ../source/specifications/core-metadata.rst:191 -msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." +msgid "" +"A longer description of the distribution that can run to several " +"paragraphs. Software that deals with metadata should not assume any maximum " +"size for this field, though people shouldn't include their instruction " +"manual as the description." msgstr "" #: ../source/specifications/core-metadata.rst:196 -msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." +msgid "" +"The contents of this field can be written using reStructuredText markup " +"[1]_. For programs that work with the metadata, supporting markup is " +"optional; programs can also display the contents of the field as-is. This " +"means that authors should be conservative in the markup they use." msgstr "" #: ../source/specifications/core-metadata.rst:202 -msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." +msgid "" +"To support empty lines and lines with indentation with respect to the RFC " +"822 format, any CRLF character has to be suffixed by 7 spaces followed by a " +"pipe (\"|\") char. As a result, the Description field is encoded into a " +"folded field that can be interpreted by RFC822 parser [2]_." msgstr "" #: ../source/specifications/core-metadata.rst:219 -msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." +msgid "" +"This encoding implies that any occurrences of a CRLF followed by 7 spaces " +"and a pipe char have to be replaced by a single CRLF when the field is " +"unfolded using a RFC822 reader." msgstr "" #: ../source/specifications/core-metadata.rst:223 -msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." +msgid "" +"Alternatively, the distribution's description may instead be provided in the " +"message body (i.e., after a completely blank line following the headers, " +"with no indentation or other special formatting necessary)." msgstr "" #: ../source/specifications/core-metadata.rst:232 @@ -6977,15 +10032,34 @@ msgid "Description-Content-Type" msgstr "" #: ../source/specifications/core-metadata.rst:236 -msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." +msgid "" +"A string stating the markup syntax (if any) used in the distribution's " +"description, so that tools can intelligently render the description." msgstr "" #: ../source/specifications/core-metadata.rst:239 -msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." +msgid "" +"Historically, PyPI supported descriptions in plain text and " +"`reStructuredText (reST) `_, and could render reST into HTML. However, it is " +"common for distribution authors to write the description in `Markdown " +"`_ (`RFC 7763 `_) as many code hosting sites render Markdown " +"READMEs, and authors would reuse the file for the description. PyPI didn't " +"recognize the format and so could not render the description correctly. This " +"resulted in many packages on PyPI with poorly-rendered descriptions when " +"Markdown is left as plain text, or worse, was attempted to be rendered as " +"reST. This field allows the distribution author to specify the format of " +"their description, opening up the possibility for PyPI and other tools to be " +"able to render Markdown and other formats." msgstr "" #: ../source/specifications/core-metadata.rst:253 -msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" +msgid "" +"The format of this field is the same as the ``Content-Type`` header in HTTP " +"(i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then " +"it can optionally have a number of parameters:" msgstr "" #: ../source/specifications/core-metadata.rst:259 @@ -7009,35 +10083,58 @@ msgid "``text/markdown``" msgstr "" #: ../source/specifications/core-metadata.rst:269 -msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." +msgid "" +"The ``charset`` parameter can be used to specify the character encoding of " +"the description. The only legal value is ``UTF-8``. If omitted, it is " +"assumed to be ``UTF-8``." msgstr "" #: ../source/specifications/core-metadata.rst:273 -msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" +msgid "" +"Other parameters might be specific to the chosen subtype. For example, for " +"the ``markdown`` subtype, there is an optional ``variant`` parameter that " +"allows specifying the variant of Markdown in use (defaults to ``GFM`` if not " +"specified). Currently, two variants are recognized:" msgstr "" #: ../source/specifications/core-metadata.rst:278 -msgid "``GFM`` for `Github-flavored Markdown `_" +msgid "" +"``GFM`` for `Github-flavored Markdown `_" msgstr "" #: ../source/specifications/core-metadata.rst:280 -msgid "``CommonMark`` for `CommonMark `_" +msgid "" +"``CommonMark`` for `CommonMark `_" msgstr "" #: ../source/specifications/core-metadata.rst:299 -msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." +msgid "" +"If a ``Description-Content-Type`` is not specified, then applications should " +"attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to " +"``text/plain`` if it is not valid rst." msgstr "" #: ../source/specifications/core-metadata.rst:303 -msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." +msgid "" +"If a ``Description-Content-Type`` is an unrecognized value, then the assumed " +"content type is ``text/plain`` (Although PyPI will probably reject anything " +"with an unrecognized value)." msgstr "" #: ../source/specifications/core-metadata.rst:307 -msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." +msgid "" +"If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is " +"not specified or is set to an unrecognized value, then the assumed " +"``variant`` is ``GFM``." msgstr "" #: ../source/specifications/core-metadata.rst:311 -msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." +msgid "" +"So for the last example above, the ``charset`` defaults to ``UTF-8`` and the " +"``variant`` defaults to ``GFM`` and thus it is equivalent to the example " +"before it." msgstr "" #: ../source/specifications/core-metadata.rst:320 @@ -7045,11 +10142,17 @@ msgid "Keywords" msgstr "" #: ../source/specifications/core-metadata.rst:324 -msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." +msgid "" +"A list of additional keywords, separated by commas, to be used to assist " +"searching for the distribution in a larger catalog." msgstr "" #: ../source/specifications/core-metadata.rst:333 -msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." +msgid "" +"The specification previously showed keywords separated by spaces, but " +"distutils and setuptools implemented it with commas. These tools have been " +"very widely used for many years, so it was easier to update the " +"specification to match the de facto standard." msgstr "" #: ../source/specifications/core-metadata.rst:341 @@ -7065,7 +10168,10 @@ msgid "Download-URL" msgstr "" #: ../source/specifications/core-metadata.rst:357 -msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" +msgid "" +"A string containing the URL from which this version of the distribution can " +"be downloaded. (This means that the URL can't be something like \".../" +"BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" msgstr "" #: ../source/specifications/core-metadata.rst:366 @@ -7073,7 +10179,9 @@ msgid "Author" msgstr "" #: ../source/specifications/core-metadata.rst:370 -msgid "A string containing the author's name at a minimum; additional contact information may be provided." +msgid "" +"A string containing the author's name at a minimum; additional contact " +"information may be provided." msgstr "" #: ../source/specifications/core-metadata.rst:383 @@ -7081,12 +10189,16 @@ msgid "Author-email" msgstr "" #: ../source/specifications/core-metadata.rst:387 -msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgid "" +"A string containing the author's e-mail address. It can contain a name and " +"e-mail address in the legal forms for a RFC-822 ``From:`` header." msgstr "" #: ../source/specifications/core-metadata.rst:395 #: ../source/specifications/core-metadata.rst:442 -msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" +msgid "" +"Per RFC-822, this field may contain multiple comma-separated e-mail " +"addresses::" msgstr "" #: ../source/specifications/core-metadata.rst:405 @@ -7094,11 +10206,16 @@ msgid "Maintainer" msgstr "Mantenedor" #: ../source/specifications/core-metadata.rst:409 -msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." +msgid "" +"A string containing the maintainer's name at a minimum; additional contact " +"information may be provided." msgstr "" #: ../source/specifications/core-metadata.rst:412 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." +msgid "" +"Note that this field is intended for use when a project is being maintained " +"by someone other than the original author: it should be omitted if it is " +"identical to ``Author``." msgstr "" #: ../source/specifications/core-metadata.rst:426 @@ -7106,11 +10223,16 @@ msgid "Maintainer-email" msgstr "" #: ../source/specifications/core-metadata.rst:430 -msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgid "" +"A string containing the maintainer's e-mail address. It can contain a name " +"and e-mail address in the legal forms for a RFC-822 ``From:`` header." msgstr "" #: ../source/specifications/core-metadata.rst:434 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." +msgid "" +"Note that this field is intended for use when a project is being maintained " +"by someone other than the original author: it should be omitted if it is " +"identical to ``Author-email``." msgstr "" #: ../source/specifications/core-metadata.rst:452 @@ -7118,7 +10240,13 @@ msgid "License" msgstr "" #: ../source/specifications/core-metadata.rst:456 -msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." +msgid "" +"Text indicating the license covering the distribution where the license is " +"not a selection from the \"License\" Trove classifiers. See :ref:`" +"\"Classifier\" ` below. This field may also be used to " +"specify a particular version of a license which is named via the " +"``Classifier`` field, or to indicate a variation or exception to such a " +"license." msgstr "" #: ../source/specifications/core-metadata.rst:476 @@ -7126,7 +10254,11 @@ msgid "Classifier (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:480 -msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." +msgid "" +"Each entry is a string giving a single classification value for the " +"distribution. Classifiers are described in :pep:`301`, and the Python " +"Package Index publishes a dynamic list of `currently defined classifiers " +"`__." msgstr "" #: ../source/specifications/core-metadata.rst:485 @@ -7144,11 +10276,15 @@ msgstr "" #: ../source/specifications/core-metadata.rst:561 #: ../source/specifications/core-metadata.rst:663 #: ../source/specifications/core-metadata.rst:704 -msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." +msgid "" +"The field format specification was relaxed to accept the syntax used by " +"popular publishing tools." msgstr "" #: ../source/specifications/core-metadata.rst:503 -msgid "Each entry contains a string naming some other distutils project required by this distribution." +msgid "" +"Each entry contains a string naming some other distutils project required by " +"this distribution." msgstr "" #: ../source/specifications/core-metadata.rst:506 @@ -7156,19 +10292,27 @@ msgid "The format of a requirement string contains from one to four parts:" msgstr "" #: ../source/specifications/core-metadata.rst:508 -msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." +msgid "" +"A project name, in the same format as the ``Name:`` field. The only " +"mandatory part." msgstr "" #: ../source/specifications/core-metadata.rst:510 -msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." +msgid "" +"A comma-separated list of 'extra' names. These are defined by the required " +"project, referring to specific features which may need extra dependencies." msgstr "" #: ../source/specifications/core-metadata.rst:513 -msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." +msgid "" +"A version specifier. Tools parsing the format should accept optional " +"parentheses around this, but tools generating it should not use parentheses." msgstr "" #: ../source/specifications/core-metadata.rst:516 -msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." +msgid "" +"An environment marker after a semicolon. This means that the requirement is " +"only needed in the specified conditions." msgstr "" #: ../source/specifications/core-metadata.rst:519 @@ -7176,11 +10320,15 @@ msgid "See :pep:`508` for full details of the allowed format." msgstr "" #: ../source/specifications/core-metadata.rst:521 -msgid "The project names should correspond to names as found on the `Python Package Index`_." +msgid "" +"The project names should correspond to names as found on the `Python Package " +"Index`_." msgstr "" #: ../source/specifications/core-metadata.rst:524 -msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." +msgid "" +"Version specifiers must follow the rules described in :doc:`version-" +"specifiers`." msgstr "" #: ../source/specifications/core-metadata.rst:538 @@ -7188,7 +10336,10 @@ msgid "Requires-Python" msgstr "" #: ../source/specifications/core-metadata.rst:542 -msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." +msgid "" +"This field specifies the Python version(s) that the distribution is " +"guaranteed to be compatible with. Installation tools may look at this when " +"picking which version of a project to install." msgstr "" #: ../source/specifications/core-metadata.rst:546 @@ -7204,15 +10355,25 @@ msgid "Requires-External (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:565 -msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." +msgid "" +"Each entry contains a string describing some dependency in the system that " +"the distribution is to be used. This field is intended to serve as a hint " +"to downstream project maintainers, and has no semantics which are meaningful " +"to the ``distutils`` distribution." msgstr "" #: ../source/specifications/core-metadata.rst:570 -msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." +msgid "" +"The format of a requirement string is a name of an external dependency, " +"optionally followed by a version declaration within parentheses." msgstr "" #: ../source/specifications/core-metadata.rst:576 -msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." +msgid "" +"Because they refer to non-Python software releases, version numbers for this " +"field are **not** required to conform to the format specified in :pep:" +"`440`: they should correspond to the version scheme used by the external " +"dependency." msgstr "" #: ../source/specifications/core-metadata.rst:581 @@ -7224,7 +10385,9 @@ msgid "Project-URL (multiple-use)" msgstr "" #: ../source/specifications/core-metadata.rst:597 -msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." +msgid "" +"A string containing a browsable URL for the project and a label for it, " +"separated by a comma." msgstr "" #: ../source/specifications/core-metadata.rst:604 @@ -7236,19 +10399,31 @@ msgid "Provides-Extra (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:616 -msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." +msgid "" +"A string containing the name of an optional feature. Must be a valid Python " +"identifier. May be used to make a dependency conditional on whether the " +"optional feature has been requested." msgstr "" #: ../source/specifications/core-metadata.rst:625 -msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." +msgid "" +"A second distribution requires an optional dependency by placing it inside " +"square brackets, and can request multiple features by separating them with a " +"comma (,). The requirements are evaluated for each requested feature and " +"added to the set of requirements for the distribution." msgstr "" #: ../source/specifications/core-metadata.rst:635 -msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." +msgid "" +"Two feature names ``test`` and ``doc`` are reserved to mark dependencies " +"that are needed for running automated tests and generating documentation, " +"respectively." msgstr "" #: ../source/specifications/core-metadata.rst:639 -msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." +msgid "" +"It is legal to specify ``Provides-Extra:`` without referencing it in any " +"``Requires-Dist:``." msgstr "" #: ../source/specifications/core-metadata.rst:644 @@ -7256,11 +10431,21 @@ msgid "Rarely Used Fields" msgstr "" #: ../source/specifications/core-metadata.rst:646 -msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." +msgid "" +"The fields in this section are currently rarely used, as their design was " +"inspired by comparable mechanisms in Linux package management systems, and " +"it isn't at all clear how tools should interpret them in the context of an " +"open index server such as `PyPI `__." msgstr "" #: ../source/specifications/core-metadata.rst:651 -msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." +msgid "" +"As a result, popular installation tools ignore them completely, which in " +"turn means there is little incentive for package publishers to set them " +"appropriately. However, they're retained in the metadata specification, as " +"they're still potentially useful for informational purposes, and can also be " +"used for their originally intended purpose in combination with a curated " +"package repository." msgstr "" #: ../source/specifications/core-metadata.rst:660 @@ -7268,19 +10453,37 @@ msgid "Provides-Dist (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:667 -msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." +msgid "" +"Each entry contains a string naming a Distutils project which is contained " +"within this distribution. This field *must* include the project identified " +"in the ``Name`` field, followed by the version : Name (Version)." msgstr "" #: ../source/specifications/core-metadata.rst:672 -msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." +msgid "" +"A distribution may provide additional names, e.g. to indicate that multiple " +"projects have been bundled together. For instance, source distributions of " +"the ``ZODB`` project have historically included the ``transaction`` project, " +"which is now available as a separate distribution. Installing such a source " +"distribution satisfies requirements for both ``ZODB`` and ``transaction``." msgstr "" #: ../source/specifications/core-metadata.rst:679 -msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." +msgid "" +"A distribution may also provide a \"virtual\" project name, which does not " +"correspond to any separately-distributed project: such a name might be used " +"to indicate an abstract capability which could be supplied by one of " +"multiple projects. E.g., multiple projects might supply RDBMS bindings for " +"use by a given ORM: each project might declare that it provides ``ORM-" +"bindings``, allowing other projects to depend only on having at most one of " +"them installed." msgstr "" #: ../source/specifications/core-metadata.rst:687 -msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." +msgid "" +"A version declaration may be supplied and must follow the rules described " +"in :doc:`version-specifiers`. The distribution's version number will be " +"implied if none is specified." msgstr "" #: ../source/specifications/core-metadata.rst:701 @@ -7288,15 +10491,23 @@ msgid "Obsoletes-Dist (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:708 -msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." +msgid "" +"Each entry contains a string describing a distutils project's distribution " +"which this distribution renders obsolete, meaning that the two projects " +"should not be installed at the same time." msgstr "" #: ../source/specifications/core-metadata.rst:712 -msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." +msgid "" +"Version declarations can be supplied. Version numbers must be in the format " +"specified in :doc:`version-specifiers`." msgstr "" #: ../source/specifications/core-metadata.rst:717 -msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." +msgid "" +"The most common use of this field will be in case a project name changes, e." +"g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install " +"Torqued Python, the Gorgon distribution should be removed." msgstr "" #: ../source/specifications/core-metadata.rst:730 @@ -7312,7 +10523,11 @@ msgid "Declaring build system dependencies" msgstr "" #: ../source/specifications/declaring-build-dependencies.rst:8 -msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." +msgid "" +"`pyproject.toml` is a build system independent file format defined in :pep:" +"`518` that projects may provide in order to declare any Python level " +"dependencies that must be installed in order to run the project's build " +"system successfully." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:5 @@ -7320,15 +10535,31 @@ msgid "Declaring project metadata" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:7 -msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." +msgid "" +":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to " +"consume. It defines the following specification as the canonical source for " +"the format used." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:12 -msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." +msgid "" +"There are two kinds of metadata: *static* and *dynamic*. Static metadata is " +"specified in the ``pyproject.toml`` file directly and cannot be specified or " +"changed by a tool. Dynamic metadata is listed via the ``dynamic`` field " +"(defined later in this specification) and represents metadata that a tool " +"will later provide." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:18 -msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." +msgid "" +"The fields defined in this specification MUST be in a table named " +"``[project]`` in ``pyproject.toml``. No tools may add fields to this table " +"which are not defined by this specification. For tools wishing to store " +"their own settings in ``pyproject.toml``, they may use the ``[tool]`` table " +"as defined in the :ref:`build dependency declaration specification " +"`. The lack of a ``[project]`` table " +"implicitly means the build back-end will dynamically provide all fields." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:27 @@ -7341,7 +10572,9 @@ msgid "``name``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:31 -msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" +msgid "" +"The fields which are required but may be specified *either* statically or " +"listed as dynamic are:" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:34 @@ -7350,7 +10583,9 @@ msgid "``version``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:36 -msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." +msgid "" +"All other fields are considered optional and my be specified statically, " +"listed as dynamic, or left unspecified." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:43 @@ -7361,7 +10596,9 @@ msgid "TOML_ type: string" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:44 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Name `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:47 @@ -7369,11 +10606,15 @@ msgid "The name of the project." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:49 -msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." +msgid "" +"Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it " +"is read for internal consistency." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:57 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Version " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:60 @@ -7389,7 +10630,9 @@ msgid "``description``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:69 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Summary " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:72 @@ -7405,7 +10648,10 @@ msgid "TOML_ type: string or table" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:79 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Description " +"` and :ref:`Description-Content-Type `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:83 @@ -7413,15 +10659,38 @@ msgid "The full description of the project (i.e. the README)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:85 -msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." +msgid "" +"The field accepts either a string or a table. If it is a string then it is a " +"path relative to ``pyproject.toml`` to a text file containing the full " +"description. Tools MUST assume the file's encoding is UTF-8. If the file " +"path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the " +"content-type is ``text/markdown``. If the file path ends in a case-" +"insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-" +"rst``. If a tool recognizes more extensions than this PEP, they MAY infer " +"the content-type for the user without specifying this field as ``dynamic``. " +"For all unrecognized suffixes when a content-type is not provided, tools " +"MUST raise an error." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:96 -msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." +msgid "" +"The ``readme`` field may also take a table. The ``file`` key has a string " +"value representing a path relative to ``pyproject.toml`` to a file " +"containing the full description. The ``text`` key has a string value which " +"is the full description. These keys are mutually-exclusive, thus tools MUST " +"raise an error if the metadata specifies both keys." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:103 -msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." +msgid "" +"A table specified in the ``readme`` field also has a ``content-type`` field " +"which takes a string specifying the content-type of the full description. A " +"tool MUST raise an error if the metadata does not specify this field in the " +"table. If the metadata does not specify the ``charset`` parameter, then it " +"is assumed to be UTF-8. Tools MAY support other encodings if they choose to. " +"Tools MAY support alternative content-types which they can transform to a " +"content-type as supported by the :ref:`core metadata `. " +"Otherwise tools MUST raise an error for unsupported content-types." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:115 @@ -7429,7 +10698,9 @@ msgid "``requires-python``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:118 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Requires-" +"Python `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:121 @@ -7445,11 +10716,19 @@ msgid "TOML_ type: table" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:128 -msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`License " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:131 -msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." +msgid "" +"The table may have one of two keys. The ``file`` key has a string value that " +"is a file path relative to ``pyproject.toml`` to the file which contains the " +"license for the project. Tools MUST assume the file's encoding is UTF-8. The " +"``text`` key has a string value which is the license of the project. These " +"keys are mutually exclusive, so a tool MUST raise an error if the metadata " +"specifies both keys." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:140 @@ -7461,35 +10740,58 @@ msgid "TOML_ type: Array of inline tables with string keys and values" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:143 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:" +"`Maintainer `, and :ref:`Maintainer-email `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:149 -msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." +msgid "" +"The people or organizations considered to be the \"authors\" of the project. " +"The exact meaning is open to interpretation — it may list the original or " +"primary authors, current maintainers, or owners of the package." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:154 -msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." +msgid "" +"The \"maintainers\" field is similar to \"authors\" in that its exact " +"meaning is open to interpretation." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:157 -msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." +msgid "" +"These fields accept an array of tables with 2 keys: ``name`` and ``email``. " +"Both values must be strings. The ``name`` value MUST be a valid email name " +"(i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not " +"contain commas. The ``email`` value MUST be a valid email address. Both keys " +"are optional." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:163 -msgid "Using the data to fill in :ref:`core metadata ` is as follows:" +msgid "" +"Using the data to fill in :ref:`core metadata ` is as follows:" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:166 -msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." +msgid "" +"If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:169 -msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." +msgid "" +"If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:173 -msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." +msgid "" +"If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-" +"email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:177 @@ -7506,7 +10808,9 @@ msgid "TOML_ type: array of strings" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:184 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Keywords " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:187 @@ -7518,7 +10822,9 @@ msgid "``classifiers``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:194 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Classifier " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:197 @@ -7534,11 +10840,15 @@ msgid "TOML_ type: table with keys and values of strings" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:204 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Project-URL " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:207 -msgid "A table of URLs where the key is the URL label and the value is the URL itself." +msgid "" +"A table of URLs where the key is the URL label and the value is the URL " +"itself." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:212 @@ -7546,7 +10856,9 @@ msgid "Entry points" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:214 -msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" +msgid "" +"TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and " +"``[project.entry-points]``)" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:216 @@ -7554,19 +10866,34 @@ msgid ":ref:`Entry points specification `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:218 -msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." +msgid "" +"There are three tables related to entry points. The ``[project.scripts]`` " +"table corresponds to the ``console_scripts`` group in the :ref:`entry points " +"specification `. The key of the table is the name of the entry " +"point and the value is the object reference." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:224 -msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." +msgid "" +"The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group " +"in the :ref:`entry points specification `. Its format is the " +"same as ``[project.scripts]``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:228 -msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." +msgid "" +"The ``[project.entry-points]`` table is a collection of tables. Each sub-" +"table's name is an entry point group. The key and value semantics are the " +"same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but " +"instead keep the entry point groups to only one level deep." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:234 -msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." +msgid "" +"Build back-ends MUST raise an error if the metadata defines a ``[project." +"entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` " +"table, as they would be ambiguous in the face of ``[project.scripts]`` and " +"``[project.gui-scripts]``, respectively." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:242 @@ -7574,11 +10901,16 @@ msgid "``dependencies``/``optional-dependencies``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:244 -msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" +msgid "" +"TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with " +"values of arrays of :pep:`508` strings (``optional-dependencies``)" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:247 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Requires-" +"Dist ` and :ref:`Provides-Extra `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:251 @@ -7586,11 +10918,22 @@ msgid "The (optional) dependencies of the project." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:253 -msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." +msgid "" +"For ``dependencies``, it is a key whose value is an array of strings. Each " +"string represents a dependency of the project and MUST be formatted as a " +"valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist " +"` entry." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:258 -msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." +msgid "" +"For ``optional-dependencies``, it is a table where each key specifies an " +"extra and whose value is an array of strings. The strings of the arrays must " +"be valid :pep:`508` strings. The keys MUST be valid values for :ref:" +"`Provides-Extra `. Each value in the array " +"thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:269 @@ -7602,39 +10945,65 @@ msgid "TOML_ type: array of string" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:272 -msgid "A corresponding :ref:`core metadata ` field does not exist" +msgid "" +"A corresponding :ref:`core metadata ` field does not exist" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:275 -msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." +msgid "" +"Specifies which fields listed by this PEP were intentionally unspecified so " +"another tool can/will provide such metadata dynamically. This clearly " +"delineates which metadata is purposefully unspecified and expected to stay " +"unspecified compared to being provided via tooling later on." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:281 -msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." +msgid "" +"A build back-end MUST honour statically-specified metadata (which means the " +"metadata did not list the field in ``dynamic``)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:283 -msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." +msgid "" +"A build back-end MUST raise an error if the metadata specifies ``name`` in " +"``dynamic``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:285 -msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." +msgid "" +"If the :ref:`core metadata ` specification lists a field as " +"\"Required\", then the metadata MUST specify the field statically or list it " +"in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it " +"should not be possible for a required field to not be listed somehow in the " +"``[project]`` table)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:290 -msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." +msgid "" +"If the :ref:`core metadata ` specification lists a field as " +"\"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is " +"a build back-end will provide the data for the field later." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:294 -msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." +msgid "" +"Build back-ends MUST raise an error if the metadata specifies a field " +"statically as well as being listed in ``dynamic``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:296 -msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." +msgid "" +"If the metadata does not list a field in ``dynamic``, then a build back-end " +"CANNOT fill in the requisite metadata on behalf of the user (i.e. " +"``dynamic`` is the only way to allow a tool to fill in metadata and the user " +"must opt into the filling in)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:300 -msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." +msgid "" +"Build back-ends MUST raise an error if the metadata specifies a field in " +"``dynamic`` but the build back-end was unable to determine the data for it " +"(omitting the data, if determined to be the accurate value, is acceptable)." msgstr "" #: ../source/specifications/dependency-specifiers.rst:6 @@ -7642,11 +11011,15 @@ msgid "Dependency specifiers" msgstr "" #: ../source/specifications/dependency-specifiers.rst:8 -msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." +msgid "" +"The dependency specifier format used to declare a dependency on another " +"component is defined in :pep:`508`." msgstr "" #: ../source/specifications/dependency-specifiers.rst:11 -msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." +msgid "" +"The environment markers section in this PEP supersedes the environment " +"markers section in :pep:`345`." msgstr "" #: ../source/specifications/direct-url.rst:6 @@ -7654,7 +11027,11 @@ msgid "Recording the Direct URL Origin of installed distributions" msgstr "" #: ../source/specifications/direct-url.rst:8 -msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." +msgid "" +"This document specifies a :file:`direct_url.json` file in the :file:`*.dist-" +"info` directory of an installed distribution, to record the Direct URL " +"Origin of the distribution. The layout of this file was originally specified " +"in :pep:`610` and is formally documented here." msgstr "" #: ../source/specifications/direct-url.rst:17 @@ -7662,80 +11039,145 @@ msgid "Specification" msgstr "" #: ../source/specifications/direct-url.rst:19 -msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgid "" +"The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` " +"directory by installers when installing a distribution from a requirement " +"specifying a direct URL reference (including a VCS URL)." msgstr "" #: ../source/specifications/direct-url.rst:23 #: ../source/specifications/recording-installed-packages.rst:206 -msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." +msgid "" +"This file MUST NOT be created when installing a distribution from an other " +"type of requirement (i.e. name plus version specifier)." msgstr "" #: ../source/specifications/direct-url.rst:26 -msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." +msgid "" +"This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." msgstr "" #: ../source/specifications/direct-url.rst:29 -msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." +msgid "" +"If present, it MUST contain at least two fields. The first one is ``url``, " +"with type ``string``. Depending on what ``url`` refers to, the second field " +"MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), " +"``archive_info`` (if ``url`` is a source archives or a wheel), or " +"``dir_info`` (if ``url`` is a local directory). These info fields have a " +"(possibly empty) subdictionary as value, with the possible keys defined " +"below." msgstr "" #: ../source/specifications/direct-url.rst:36 -msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." +msgid "" +"``url`` MUST be stripped of any sensitive authentication information, for " +"security reasons." msgstr "" #: ../source/specifications/direct-url.rst:39 -msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" +msgid "" +"The user:password section of the URL MAY however be composed of environment " +"variables, matching the following regular expression::" msgstr "" #: ../source/specifications/direct-url.rst:45 -msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." +msgid "" +"Additionally, the user:password section of the URL MAY be a well-known, non " +"security sensitive string. A typical example is ``git`` in the case of an " +"URL such as ``ssh://git@gitlab.com/user/repo``." msgstr "" #: ../source/specifications/direct-url.rst:49 -msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" +msgid "" +"When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be " +"present as a dictionary with the following keys:" msgstr "" #: ../source/specifications/direct-url.rst:52 -msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." +msgid "" +"A ``vcs`` key (type ``string``) MUST be present, containing the name of the " +"VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be " +"registered by writing a PEP to amend this specification. The ``url`` value " +"MUST be compatible with the corresponding VCS, so an installer can hand it " +"off without transformation to a checkout/download command of the VCS." msgstr "" #: ../source/specifications/direct-url.rst:58 -msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." +msgid "" +"A ``requested_revision`` key (type ``string``) MAY be present naming a " +"branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to " +"install." msgstr "" #: ../source/specifications/direct-url.rst:61 -msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." +msgid "" +"A ``commit_id`` key (type ``string``) MUST be present, containing the exact " +"commit/revision number that was installed. If the VCS supports commit-hash " +"based revision identifiers, such commit-hash MUST be used as ``commit_id`` " +"in order to reference the immutable version of the source code that was " +"installed." msgstr "" #: ../source/specifications/direct-url.rst:68 -msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" +msgid "" +"When ``url`` refers to a source archive or a wheel, the ``archive_info`` key " +"MUST be present as a dictionary with the following key:" msgstr "" #: ../source/specifications/direct-url.rst:71 -msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." +msgid "" +"A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are " +"unconditionally provided by the latest version of the standard library's " +"``hashlib`` module be used for source archive hashes. At time of writing, " +"that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and " +"'sha512'." msgstr "" #: ../source/specifications/direct-url.rst:78 -msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" +msgid "" +"When ``url`` refers to a local directory, the ``dir_info`` key MUST be " +"present as a dictionary with the following key:" msgstr "" #: ../source/specifications/direct-url.rst:81 -msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." +msgid "" +"``editable`` (type: ``boolean``): ``true`` if the distribution was installed " +"in editable mode, ``false`` otherwise. If absent, default to ``false``." msgstr "" #: ../source/specifications/direct-url.rst:84 -msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." +msgid "" +"When ``url`` refers to a local directory, it MUST have the ``file`` sheme " +"and be compliant with `RFC 8089 `_. In " +"particular, the path component must be absolute. Symbolic links SHOULD be " +"preserved when making relative paths absolute." msgstr "" #: ../source/specifications/direct-url.rst:91 -msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." +msgid "" +"When the requested URL has the file:// scheme and points to a local " +"directory that happens to contain a VCS checkout, installers MUST NOT " +"attempt to infer any VCS information and therefore MUST NOT output any VCS " +"related information (such as ``vcs_info``) in :file:`direct_url.json`." msgstr "" #: ../source/specifications/direct-url.rst:96 -msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." +msgid "" +"A top-level ``subdirectory`` field MAY be present containing a directory " +"path, relative to the root of the VCS repository, source archive or local " +"directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." msgstr "" #: ../source/specifications/direct-url.rst:102 -msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." +msgid "" +"As a general rule, installers should as much as possible preserve the " +"information that was provided in the requested URL when generating :file:" +"`direct_url.json`. For example user:password environment variables should be " +"preserved and ``requested_revision`` should reflect the revision that was " +"provided in the requested URL as faithfully as possible. This information is " +"however *enriched* with more precise data, such as ``commit_id``." msgstr "" #: ../source/specifications/direct-url.rst:110 @@ -7743,7 +11185,14 @@ msgid "Registered VCS" msgstr "" #: ../source/specifications/direct-url.rst:112 -msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." +msgid "" +"This section lists the registered VCS's; expanded, VCS-specific information " +"on how to use the ``vcs``, ``requested_revision``, and other fields of " +"``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY " +"support other VCS's although it is RECOMMENDED to register them by writing a " +"PEP to amend this specification. The ``vcs`` field SHOULD be the command " +"name (lowercased). Additional fields that would be necessary to support such " +"VCS SHOULD be prefixed with the VCS command name." msgstr "" #: ../source/specifications/direct-url.rst:122 @@ -7788,7 +11237,9 @@ msgid "``requested_revision`` field" msgstr "" #: ../source/specifications/direct-url.rst:138 -msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." +msgid "" +"A tag name, branch name, Git ref, commit hash, shortened commit hash, or " +"other commit-ish." msgstr "" #: ../source/specifications/direct-url.rst:141 @@ -7803,7 +11254,11 @@ msgid "A commit hash (40 hexadecimal characters sha1)." msgstr "" #: ../source/specifications/direct-url.rst:147 -msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." +msgid "" +"Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to " +"determine if the ``requested_revision`` corresponds to a Git ref. In turn, a " +"ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning " +"with ``refs/remotes/origin/`` after cloning corresponds to a branch." msgstr "" #: ../source/specifications/direct-url.rst:154 @@ -7862,11 +11317,15 @@ msgid "svn" msgstr "" #: ../source/specifications/direct-url.rst:216 -msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." +msgid "" +"``requested_revision`` must be compatible with ``svn checkout`` ``--" +"revision`` option. In Subversion, branch or tag is part of ``url``." msgstr "" #: ../source/specifications/direct-url.rst:221 -msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." +msgid "" +"Since Subversion does not support globally unique identifiers, this field is " +"the Subversion revision number in the corresponding repository." msgstr "" #: ../source/specifications/direct-url.rst:229 @@ -7906,7 +11365,9 @@ msgid "pip install https://example.com/app-1.0.whl" msgstr "" #: ../source/specifications/direct-url.rst:283 -msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" +msgid "" +"pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup" +"\"" msgstr "" #: ../source/specifications/direct-url.rst:284 @@ -7918,7 +11379,11 @@ msgid "pip install file:///home/user/app" msgstr "" #: ../source/specifications/direct-url.rst:286 -msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" +msgid "" +"pip install --editable \"git+https://example.com/repo/app." +"git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local " +"directory where the git repository has been cloned to, and ``dir_info`` will " +"be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" msgstr "" #: ../source/specifications/direct-url.rst:290 @@ -7942,19 +11407,37 @@ msgid "Entry points specification" msgstr "" #: ../source/specifications/entry-points.rst:7 -msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" +msgid "" +"*Entry points* are a mechanism for an installed distribution to advertise " +"components it provides to be discovered and used by other code. For example:" msgstr "" #: ../source/specifications/entry-points.rst:11 -msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." +msgid "" +"Distributions can specify ``console_scripts`` entry points, each referring " +"to a function. When *pip* (or another console_scripts aware installer) " +"installs the distribution, it will create a command-line wrapper for each " +"entry point." msgstr "" #: ../source/specifications/entry-points.rst:14 -msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." +msgid "" +"Applications can use entry points to load plugins; e.g. Pygments (a syntax " +"highlighting tool) can use additional lexers and styles from separately " +"installed packages. For more about this, see :doc:`/guides/creating-and-" +"discovering-plugins`." msgstr "" #: ../source/specifications/entry-points.rst:19 -msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." +msgid "" +"The entry point file format was originally developed to allow packages built " +"with setuptools to provide integration point metadata that would be read at " +"runtime with ``importlib.metadata``. It is now defined as a PyPA " +"interoperability specification in order to allow build tools other than " +"setuptools to publish ``importlib.metadata`` compatible entry point " +"metadata, and runtime libraries other than ``importlib.metadata`` to " +"portably read published entry point metadata (potentially with different " +"caching and conflict resolution strategies)." msgstr "" #: ../source/specifications/entry-points.rst:28 @@ -7966,27 +11449,61 @@ msgid "Conceptually, an entry point is defined by three required properties:" msgstr "" #: ../source/specifications/entry-points.rst:32 -msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." +msgid "" +"The **group** that an entry point belongs to indicates what sort of object " +"it provides. For instance, the group ``console_scripts`` is for entry points " +"referring to functions which can be used as a command, while ``pygments." +"styles`` is the group for classes defining pygments styles. The consumer " +"typically defines the expected interface. To avoid clashes, consumers " +"defining a new group should use names starting with a PyPI name owned by the " +"consumer project, followed by ``.``. Group names must be one or more groups " +"of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w" +"+)*$``)." msgstr "" #: ../source/specifications/entry-points.rst:42 -msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." +msgid "" +"The **name** identifies this entry point within its group. The precise " +"meaning of this is up to the consumer. For console scripts, the name of the " +"entry point is the command that will be used to launch it. Within a " +"distribution, entry point names should be unique. If different distributions " +"provide the same name, the consumer decides how to handle such conflicts. " +"The name may contain any characters except ``=``, but it cannot start or end " +"with any whitespace character, or start with ``[``. For new entry points, it " +"is recommended to use only letters, numbers, underscores, dots and dashes " +"(regex ``[\\w.-]+``)." msgstr "" #: ../source/specifications/entry-points.rst:51 -msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" +msgid "" +"The **object reference** points to a Python object. It is either in the form " +"``importable.module``, or ``importable.module:object.attr``. Each of the " +"parts delimited by dots and the colon is a valid Python identifier. It is " +"intended to be looked up like this::" msgstr "" #: ../source/specifications/entry-points.rst:64 -msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." +msgid "" +"Some tools call this kind of object reference by itself an 'entry point', " +"for want of a better term, especially where it points to a function to " +"launch a program." msgstr "" #: ../source/specifications/entry-points.rst:68 -msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." +msgid "" +"There is also an optional property: the **extras** are a set of strings " +"identifying optional features of the distribution providing the entry point. " +"If these are specified, the entry point requires the dependencies of those " +"'extras'. See the metadata field :ref:`metadata_provides_extra`." msgstr "" #: ../source/specifications/entry-points.rst:73 -msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." +msgid "" +"Using extras for an entry point is no longer recommended. Consumers should " +"support parsing them from existing distributions, but may then ignore them. " +"New publishing tools need not support specifying extras. The functionality " +"of handling extras was tied to setuptools' model of managing 'egg' packages, " +"but newer tools such as pip and virtualenv use a different model." msgstr "" #: ../source/specifications/entry-points.rst:80 @@ -7994,23 +11511,44 @@ msgid "File format" msgstr "" #: ../source/specifications/entry-points.rst:82 -msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." +msgid "" +"Entry points are defined in a file called :file:`entry_points.txt` in the :" +"file:`*.dist-info` directory of the distribution. This is the directory " +"described in :pep:`376` for installed distributions, and in :pep:`427` for " +"wheels. The file uses the UTF-8 character encoding." msgstr "" #: ../source/specifications/entry-points.rst:87 -msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" +msgid "" +"The file contents are in INI format, as read by Python's :mod:`configparser` " +"module. However, configparser treats names as case-insensitive by default, " +"whereas entry point names are case sensitive. A case-sensitive config parser " +"can be made like this::" msgstr "" #: ../source/specifications/entry-points.rst:97 -msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." +msgid "" +"The entry points file must always use ``=`` to delimit names from values " +"(whereas configparser also allows using ``:``)." msgstr "" #: ../source/specifications/entry-points.rst:100 -msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." +msgid "" +"The sections of the config file represent entry point groups, the names are " +"names, and the values encode both the object reference and the optional " +"extras. If extras are used, they are a comma-separated list inside square " +"brackets." msgstr "" #: ../source/specifications/entry-points.rst:104 -msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." +msgid "" +"Within a value, readers must accept and ignore spaces (including multiple " +"consecutive spaces) before or after the colon, between the object reference " +"and the left square bracket, between the extra names and the square brackets " +"and colons delimiting them, and after the right square bracket. The syntax " +"for extras is formally specified as part of :pep:`508` (as ``extras``). For " +"tools writing the file, it is recommended only to insert a space between the " +"object reference and the left square bracket." msgstr "" #: ../source/specifications/entry-points.rst:112 @@ -8022,23 +11560,47 @@ msgid "Use for scripts" msgstr "" #: ../source/specifications/entry-points.rst:126 -msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." +msgid "" +"Two groups of entry points have special significance in packaging: " +"``console_scripts`` and ``gui_scripts``. In both groups, the name of the " +"entry point should be usable as a command in a system shell after the " +"package is installed. The object reference points to a function which will " +"be called with no arguments when this command is run. The function may " +"return an integer to be used as a process exit code, and returning ``None`` " +"is equivalent to returning ``0``." msgstr "" #: ../source/specifications/entry-points.rst:134 -msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" +msgid "" +"For instance, the entry point ``mycmd = mymod:main`` would create a command " +"``mycmd`` launching a script like this::" msgstr "" #: ../source/specifications/entry-points.rst:141 -msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." +msgid "" +"The difference between ``console_scripts`` and ``gui_scripts`` only affects " +"Windows systems. ``console_scripts`` are wrapped in a console executable, so " +"they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and " +"``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI " +"executable, so they can be started without a console, but cannot use " +"standard streams unless application code redirects them. Other platforms do " +"not have the same distinction." msgstr "" #: ../source/specifications/entry-points.rst:149 -msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." +msgid "" +"Install tools are expected to set up wrappers for both ``console_scripts`` " +"and ``gui_scripts`` in the scripts directory of the install scheme. They are " +"not responsible for putting this directory in the ``PATH`` environment " +"variable which defines where command-line tools are found." msgstr "" #: ../source/specifications/entry-points.rst:154 -msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." +msgid "" +"As files are created from the names, and some filesystems are case-" +"insensitive, packages should avoid using names in these groups which differ " +"only in case. The behaviour of install tools when names differ only in case " +"is undefined." msgstr "" #: ../source/specifications/index.rst:4 @@ -8046,7 +11608,11 @@ msgid "PyPA specifications" msgstr "" #: ../source/specifications/index.rst:6 -msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." +msgid "" +"This is a list of currently active interoperability specifications " +"maintained by the Python Packaging Authority. The process for updating these " +"standards, and for proposing new ones, is documented on `pypa.io `__." msgstr "" #: ../source/specifications/index.rst:13 @@ -8066,11 +11632,16 @@ msgid "Platform compatibility tags" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:8 -msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." +msgid "" +"Platform compatibility tags allow build tools to mark distributions as being " +"compatible with specific platforms, and allows installers to understand " +"which distributions are compatible with the system they are running on." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:12 -msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." +msgid "" +"The platform compatibility tagging model used for the ``wheel`` distribution " +"format is defined in :pep:`425`." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:16 @@ -8078,7 +11649,9 @@ msgid "Platform tags for Windows" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:18 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." +msgid "" +"The scheme defined in :pep:`425` covers public distribution of wheel files " +"to systems running Windows." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:22 @@ -8086,7 +11659,9 @@ msgid "Platform tags for macOS (Mac OS X)" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:24 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." +msgid "" +"The scheme defined in :pep:`425` covers public distribution of wheel files " +"to systems running macOS (previously known as Mac OS X)." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:28 @@ -8094,39 +11669,70 @@ msgid "Platform tags for common Linux distributions" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:32 -msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." +msgid "" +"The scheme defined in :pep:`425` is insufficient for public distribution of " +"wheel files (and \\*nix wheel files in general) to Linux platforms, due to " +"the large ecosystem of Linux platforms and subtle differences between them." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:36 -msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." +msgid "" +"Instead, :pep:`600` defines the ``manylinux`` standard, which represents a " +"common subset of Linux platforms, and allows building wheels tagged with the " +"``manylinux`` platform tag which can be used across most common Linux " +"distributions." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:41 -msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" +msgid "" +"There were multiple iterations of the ``manylinux`` specification, each " +"representing the common subset of Linux platforms at a given point in time:" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:44 -msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." +msgid "" +"``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, " +"and is based on a compatible Linux platform from 2007." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:46 -msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." +msgid "" +"``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` " +"architectures. and updates the previous specification to be based on a " +"compatible Linux platform from 2010 instead." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:49 -msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." +msgid "" +"``manylinux2014`` (:pep:`599`) adds support for a number of additional " +"architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and " +"``s390x``) and updates the base platform to a compatible Linux platform from " +"2014." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:54 -msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." +msgid "" +"``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a " +"future-proof standard. It defines ``x`` and ``y`` as glibc major an minor " +"versions supported (e.g. ``manylinux_2_24`` should work on any distro using " +"glibc 2.24+). Previous tags are still supported for backward compatibility." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:59 -msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." +msgid "" +"In general, distributions built for older versions of the specification are " +"forwards-compatible (meaning that ``manylinux1`` distributions should " +"continue to work on modern systems) but not backwards-compatible (meaning " +"that ``manylinux2010`` distributions are not expected to work on platforms " +"that existed before 2010)." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:65 -msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." +msgid "" +"Package maintainers should attempt to target the most compatible " +"specification possible, with the caveat that the provided build environment " +"for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning " +"that these images will no longer receive security updates." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:71 @@ -8134,15 +11740,21 @@ msgid "Manylinux compatibility support" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:74 -msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." +msgid "" +"The ``manylinux2014`` specification is relatively new and is not yet widely " +"recognised by install tools." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:76 -msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." +msgid "" +"The ``manylinux_x_y`` specification is relatively new and is not yet widely " +"recognised by install tools." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:79 -msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" +msgid "" +"The following table shows the minimum versions of relevant projects to " +"support the various ``manylinux`` standards:" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:83 @@ -8206,7 +11818,11 @@ msgid "Platform tags for other \\*nix platforms" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:92 -msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." +msgid "" +"The scheme defined in :pep:`425` is not generally sufficient for public " +"distribution of wheel files to other \\*nix platforms. Efforts are currently " +"(albeit intermittently) under way to define improved compatibility tagging " +"schemes for AIX and for Alpine Linux." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:98 @@ -8218,7 +11834,11 @@ msgid "The :file:`.pypirc` file" msgstr "" #: ../source/specifications/pypirc.rst:8 -msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." +msgid "" +"A :file:`.pypirc` file allows you to define the configuration for :term:" +"`package indexes ` (referred to here as \"repositories\"), so " +"that you don't have to enter the URL, username, or password whenever you " +"upload a package with :ref:`twine` or :ref:`flit`." msgstr "" #: ../source/specifications/pypirc.rst:13 @@ -8226,7 +11846,9 @@ msgid "The format (originally defined by the :ref:`distutils` package) is:" msgstr "" #: ../source/specifications/pypirc.rst:32 -msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." +msgid "" +"The ``distutils`` section defines an ``index-servers`` field that lists the " +"name of all sections describing a repository." msgstr "" #: ../source/specifications/pypirc.rst:35 @@ -8246,11 +11868,16 @@ msgid "``password``: The password that will used to authenticate the username." msgstr "" #: ../source/specifications/pypirc.rst:43 -msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." +msgid "" +"Be aware that this stores your password in plain text. For better security, " +"consider an alternative like `keyring`_, setting environment variables, or " +"providing the password on the command line." msgstr "" #: ../source/specifications/pypirc.rst:47 -msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" +msgid "" +"Otherwise, set the permissions on :file:`.pypirc` so that only you can view " +"or modify it. For example, on Linux or macOS, run:" msgstr "" #: ../source/specifications/pypirc.rst:57 @@ -8258,15 +11885,23 @@ msgid "Common configurations" msgstr "" #: ../source/specifications/pypirc.rst:61 -msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." +msgid "" +"These examples apply to :ref:`twine`, and projects like :ref:`hatch` that " +"use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`." +"pypirc`, but with different defaults. Please refer to each project's " +"documentation for more details and usage instructions." msgstr "" #: ../source/specifications/pypirc.rst:66 -msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" +msgid "" +"Twine's default configuration mimics a :file:`.pypirc` with repository " +"sections for PyPI and TestPyPI:" msgstr "" #: ../source/specifications/pypirc.rst:82 -msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." +msgid "" +"Twine will add additional configuration from :file:`$HOME/.pypirc`, the " +"command line, and environment variables to this default configuration." msgstr "" #: ../source/specifications/pypirc.rst:86 @@ -8274,11 +11909,15 @@ msgid "Using a PyPI token" msgstr "" #: ../source/specifications/pypirc.rst:88 -msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" +msgid "" +"To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` " +"similar to:" msgstr "" #: ../source/specifications/pypirc.rst:97 -msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." +msgid "" +"For :ref:`TestPyPI `, add a ``[testpypi]`` section, using " +"the API token from your TestPyPI account." msgstr "" #: ../source/specifications/pypirc.rst:103 @@ -8286,11 +11925,16 @@ msgid "Using another package index" msgstr "" #: ../source/specifications/pypirc.rst:105 -msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" +msgid "" +"To configure an additional repository, you'll need to redefine the ``index-" +"servers`` field to include the repository name. Here is a complete example " +"of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" msgstr "" #: ../source/specifications/pypirc.rst:132 -msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" +msgid "" +"Instead of using the ``password`` field, consider saving your API tokens and " +"passwords securely using `keyring`_ (which is installed by Twine):" msgstr "" #: ../source/specifications/recording-installed-packages.rst:5 @@ -8298,11 +11942,20 @@ msgid "Recording installed projects" msgstr "" #: ../source/specifications/recording-installed-packages.rst:7 -msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." +msgid "" +"This document specifies a common format of recording information about " +"Python :term:`projects ` installed in an environment. A common " +"metadata format allows tools to query, manage or uninstall projects, " +"regardless of how they were installed." msgstr "" #: ../source/specifications/recording-installed-packages.rst:12 -msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." +msgid "" +"Almost all information is optional. This allows tools outside the Python " +"ecosystem, such as Linux package managers, to integrate with Python tooling " +"as much as possible. For example, even if an installer cannot easily provide " +"a list of installed files in a format specific to Python tooling, it should " +"still record the name and version of the installed project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:21 @@ -8310,31 +11963,65 @@ msgid "History and change workflow" msgstr "" #: ../source/specifications/recording-installed-packages.rst:23 -msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." +msgid "" +"The metadata described here was first specified in :pep:`376`, and later " +"amended in :pep:`627`. It was formerly known as *Database of Installed " +"Python Distributions*. Further amendments (except trivial language or " +"typography fixes) must be made through the PEP process (see :pep:`1`)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:29 -msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." +msgid "" +"While this document is the normative specification, these PEPs that " +"introduce changes to it may include additional information such as " +"rationales and backwards compatibility considerations." msgstr "" #: ../source/specifications/recording-installed-packages.rst:37 -msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." +msgid "" +"Each project installed from a distribution must, in addition to files, " +"install a \"``.dist-info``\" directory located alongside importable modules " +"and packages (commonly, the ``site-packages`` directory)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:41 -msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." +msgid "" +"This directory is named as ``{name}-{version}.dist-info``, with ``name`` and " +"``version`` fields corresponding to :ref:`core-metadata`. Both fields must " +"be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 " +"<440#normalization>` for the definition of normalization for each field " +"respectively), and replace dash (``-``) characters with underscore (``_``) " +"chacaters, so the ``.dist-info`` directory always has exactly one dash (``-" +"``) character in its stem, separating the ``name`` and ``version`` fields." msgstr "" #: ../source/specifications/recording-installed-packages.rst:50 -msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." +msgid "" +"Historically, tools have failed to replace dot characters or normalize case " +"in the ``name`` field, or not perform normalization in the ``version`` " +"field. Tools consuming ``.dist-info`` directories should expect those fields " +"to be unnormalized, and treat them as equivalent to their normalized " +"counterparts. New tools that write ``.dist-info`` directories MUST normalize " +"both ``name`` and ``version`` fields using the rules described above, and " +"existing tools are encouraged to start normalizing those fields." msgstr "" #: ../source/specifications/recording-installed-packages.rst:60 -msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." +msgid "" +"The ``.dist-info`` directory's name is formatted to unambigiously represent " +"a distribution as a filesystem path. Tools presenting a distribution name to " +"a user should avoid using the normalized name, and instead present the " +"specified name (when needed prior to resolution to an installed package), or " +"read the respective fields in Core Metadata, since values listed there are " +"unescaped and accurately reflect the distribution. Libraries should provide " +"API for such tools to consume, so tools can have access to the unnormalized " +"name when displaying distrubution information." msgstr "" #: ../source/specifications/recording-installed-packages.rst:69 -msgid "This ``.dist-info`` directory can contain these files, described in detail below:" +msgid "" +"This ``.dist-info`` directory can contain these files, described in detail " +"below:" msgstr "" #: ../source/specifications/recording-installed-packages.rst:72 @@ -8346,19 +12033,31 @@ msgid "``RECORD``: records the list of installed files." msgstr "" #: ../source/specifications/recording-installed-packages.rst:74 -msgid "``INSTALLER``: records the name of the tool used to install the project." +msgid "" +"``INSTALLER``: records the name of the tool used to install the project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:76 -msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." +msgid "" +"The ``METADATA`` file is mandatory. All other files may be omitted at the " +"installing tool's discretion. Additional installer-specific files may be " +"present." msgstr "" #: ../source/specifications/recording-installed-packages.rst:82 -msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." +msgid "" +"The :ref:`binary-distribution-format` specification describes additional " +"files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. " +"Such files may be copied to the ``.dist-info`` directory of an installed " +"project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:87 -msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." +msgid "" +"The previous versions of this specification also specified a ``REQUESTED`` " +"file. This file is now considered a tool-specific extension, but may be " +"standardized again in the future. See `PEP 376 `_ for its original meaning." msgstr "" #: ../source/specifications/recording-installed-packages.rst:94 @@ -8366,11 +12065,16 @@ msgid "The METADATA file" msgstr "" #: ../source/specifications/recording-installed-packages.rst:96 -msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." +msgid "" +"The ``METADATA`` file contains metadata as described in the :ref:`core-" +"metadata` specification, version 1.1 or greater." msgstr "" #: ../source/specifications/recording-installed-packages.rst:99 -msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." +msgid "" +"The ``METADATA`` file is mandatory. If it cannot be created, or if required " +"core metadata is not available, installers must report an error and fail to " +"install the project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:105 @@ -8378,11 +12082,15 @@ msgid "The RECORD file" msgstr "" #: ../source/specifications/recording-installed-packages.rst:107 -msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." +msgid "" +"The ``RECORD`` file holds the list of installed files. It is a CSV file " +"containing one record (line) per installed file." msgstr "" #: ../source/specifications/recording-installed-packages.rst:110 -msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" +msgid "" +"The CSV dialect must be readable with the default ``reader`` of Python's " +"``csv`` module:" msgstr "" #: ../source/specifications/recording-installed-packages.rst:113 @@ -8398,31 +12106,56 @@ msgid "line terminator: either ``\\r\\n`` or ``\\n``." msgstr "" #: ../source/specifications/recording-installed-packages.rst:117 -msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." +msgid "" +"Each record is composed of three elements: the file's **path**, the **hash** " +"of the contents, and its **size**." msgstr "" #: ../source/specifications/recording-installed-packages.rst:120 -msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." +msgid "" +"The *path* may be either absolute, or relative to the directory containing " +"the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On " +"Windows, directories may be separated either by forward- or backslashes (``/" +"`` or ``\\``)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:125 -msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." +msgid "" +"The *hash* is either an empty string or the name of a hash algorithm from " +"``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` " +"and the digest of the file's contents, encoded with the urlsafe-base64-nopad " +"encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:130 -msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." +msgid "" +"The *size* is either the empty string, or file's size in bytes, as a base 10 " +"integer." msgstr "" #: ../source/specifications/recording-installed-packages.rst:133 -msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." +msgid "" +"For any file, either or both of the *hash* and *size* fields may be left " +"empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself " +"have empty *hash* and *size*. For other files, leaving the information out " +"is discouraged, as it prevents verifying the integrity of the installed " +"project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:139 -msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." +msgid "" +"If the ``RECORD`` file is present, it must list all installed files of the " +"project, except ``.pyc`` files corresponding to ``.py`` files listed in " +"``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` " +"directory (including the ``RECORD`` file itself) must be listed. Directories " +"should not be listed." msgstr "" #: ../source/specifications/recording-installed-packages.rst:146 -msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." +msgid "" +"To completely uninstall a package, a tool needs to remove all files listed " +"in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding " +"to removed ``.py`` files, and any directories emptied by the uninstallation." msgstr "" #: ../source/specifications/recording-installed-packages.rst:151 @@ -8430,7 +12163,11 @@ msgid "Here is an example snippet of a possible ``RECORD`` file::" msgstr "" #: ../source/specifications/recording-installed-packages.rst:170 -msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" +msgid "" +"If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must " +"not atempt to uninstall or upgrade the package. (This does not apply to " +"tools that rely on other sources of information, such as system package " +"managers in Linux distros.)" msgstr "" #: ../source/specifications/recording-installed-packages.rst:177 @@ -8438,7 +12175,11 @@ msgid "The INSTALLER file" msgstr "" #: ../source/specifications/recording-installed-packages.rst:179 -msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." +msgid "" +"If present, ``INSTALLER`` is a single-line text file naming the tool used to " +"install the project. If the installer is executable from the command line, " +"``INSTALLER`` should contain the command name. Otherwise, it should contain " +"a printable ASCII string." msgstr "" #: ../source/specifications/recording-installed-packages.rst:185 @@ -8450,7 +12191,11 @@ msgid "Here are examples of two possible ``INSTALLER`` files::" msgstr "" #: ../source/specifications/recording-installed-packages.rst:195 -msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." +msgid "" +"This value should be used for informational purposes only. For example, if a " +"tool is asked to uninstall a project but finds no ``RECORD`` file, it may " +"suggest that the tool named in ``INSTALLER`` may be able to do the " +"uninstallation." msgstr "" #: ../source/specifications/recording-installed-packages.rst:201 @@ -8458,7 +12203,9 @@ msgid "The direct_url.json file" msgstr "" #: ../source/specifications/recording-installed-packages.rst:203 -msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgid "" +"This file MUST be created by installers when installing a distribution from " +"a requirement specifying a direct URL reference (including a VCS URL)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:209 @@ -8470,7 +12217,12 @@ msgid "Simple repository API" msgstr "" #: ../source/specifications/simple-repository-api.rst:8 -msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." +msgid "" +"The current interface for querying available package versions and retrieving " +"packages from an index server is defined in :pep:`503`, with the addition of " +"\"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` " +"and specifying the interface version provided by an index server in :pep:" +"`629`." msgstr "" #: ../source/specifications/source-distribution-format.rst:6 @@ -8478,11 +12230,22 @@ msgid "Source distribution format" msgstr "" #: ../source/specifications/source-distribution-format.rst:8 -msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." +msgid "" +"The current standard format of source distribution format is identified by " +"the presence of a :file:`pyproject.toml` file in the distribution archive. " +"The layout of such a distribution was originally specified in :pep:`517` and " +"is formally documented here." msgstr "" #: ../source/specifications/source-distribution-format.rst:13 -msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." +msgid "" +"There is also the legacy source distribution format, implicitly defined by " +"the behaviour of ``distutils`` module in the standard library, when " +"executing :command:`setup.py sdist`. This document does not attempt to " +"standardise this format, except to note that if a legacy source distribution " +"contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it " +"MUST follow the rules applicable to source distributions defined in the " +"metadata specification." msgstr "" #: ../source/specifications/source-distribution-format.rst:21 @@ -8494,11 +12257,18 @@ msgid "Source distribution file name" msgstr "" #: ../source/specifications/source-distribution-format.rst:26 -msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." +msgid "" +"The file name of a sdist is not currently standardised, although the *de " +"facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the " +"canonicalized form of the project name (see :pep:`503` for the " +"canonicalization rules) with ``-`` characters replaced with ``_``, and " +"``{version}`` is the project version." msgstr "" #: ../source/specifications/source-distribution-format.rst:31 -msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." +msgid "" +"The name and version components of the filename MUST match the values stored " +"in the metadata contained in the file." msgstr "" #: ../source/specifications/source-distribution-format.rst:35 @@ -8506,15 +12276,27 @@ msgid "Source distribution file format" msgstr "" #: ../source/specifications/source-distribution-format.rst:37 -msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." +msgid "" +"A ``.tar.gz`` source distribution (sdist) contains a single top-level " +"directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the " +"source files of the package. The name and version MUST match the metadata " +"stored in the file. This directory must also contain a :file:`pyproject." +"toml` in the format defined in :ref:`declaring-build-dependencies`, and a " +"``PKG-INFO`` file containing metadata in the format described in the :ref:" +"`core-metadata` specification. The metadata MUST conform to at least version " +"2.2 of the metadata specification." msgstr "" #: ../source/specifications/source-distribution-format.rst:45 -msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." +msgid "" +"No other content of a sdist is required or defined. Build systems can store " +"whatever information they need in the sdist to build the project." msgstr "" #: ../source/specifications/source-distribution-format.rst:48 -msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." +msgid "" +"The tarball should use the modern POSIX.1-2001 pax tar format, which " +"specifies UTF-8 based file names." msgstr "" #: ../source/specifications/version-specifiers.rst:6 @@ -8522,11 +12304,15 @@ msgid "Version specifiers" msgstr "" #: ../source/specifications/version-specifiers.rst:8 -msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." +msgid "" +"Version numbering requirements and the semantics for specifying comparisons " +"between versions are defined in :pep:`440`." msgstr "" #: ../source/specifications/version-specifiers.rst:11 -msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." +msgid "" +"The version specifiers section in this PEP supersedes the version specifiers " +"section in :pep:`345`." msgstr "" #: ../source/support.rst:3 @@ -8534,11 +12320,17 @@ msgid "How to Get Support" msgstr "" #: ../source/support.rst:5 -msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." +msgid "" +"For support related to a specific project, see the links on the :doc:" +"`Projects ` page." msgstr "" #: ../source/support.rst:8 -msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." +msgid "" +"For something more general, or when you're just not sure, please `open an " +"issue `_ on the " +"`packaging-problems `_ " +"repository on GitHub." msgstr "" #: ../source/tutorials/creating-documentation.rst:5 @@ -8546,7 +12338,9 @@ msgid "Creating Documentation" msgstr "" #: ../source/tutorials/creating-documentation.rst:7 -msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." +msgid "" +"This section covers the basics of how to create documentation using " +"`Sphinx`_ and host the documentation for free in `Read The Docs`_." msgstr "" #: ../source/tutorials/creating-documentation.rst:13 @@ -8558,7 +12352,8 @@ msgid "Use ``pip`` to install Sphinx:" msgstr "" #: ../source/tutorials/creating-documentation.rst:28 -msgid "For other installation methods, see this `installation guide`_ by Sphinx." +msgid "" +"For other installation methods, see this `installation guide`_ by Sphinx." msgstr "" #: ../source/tutorials/creating-documentation.rst:33 @@ -8566,7 +12361,8 @@ msgid "Getting Started With Sphinx" msgstr "" #: ../source/tutorials/creating-documentation.rst:35 -msgid "Create a ``docs`` directory inside your project to hold your documentation:" +msgid "" +"Create a ``docs`` directory inside your project to hold your documentation:" msgstr "" #: ../source/tutorials/creating-documentation.rst:42 @@ -8574,15 +12370,21 @@ msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" msgstr "" #: ../source/tutorials/creating-documentation.rst:49 -msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." +msgid "" +"This sets up a source directory, walks you through some basic " +"configurations, and creates an ``index.rst`` file as well as a ``conf.py`` " +"file." msgstr "" #: ../source/tutorials/creating-documentation.rst:51 -msgid "You can add some information about your project in ``index.rst``, then build them:" +msgid "" +"You can add some information about your project in ``index.rst``, then build " +"them:" msgstr "" #: ../source/tutorials/creating-documentation.rst:57 -msgid "For more details on the build process, see this `guide`_ by Read The Docs." +msgid "" +"For more details on the build process, see this `guide`_ by Read The Docs." msgstr "" #: ../source/tutorials/creating-documentation.rst:62 @@ -8590,11 +12392,16 @@ msgid "Other Sources" msgstr "" #: ../source/tutorials/creating-documentation.rst:64 -msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." +msgid "" +"For a more detailed guide on how to use Sphinx and reStructuredText, please " +"see this `documentation tutorial`_ on Hitchhiker's Guide to Python." msgstr "" #: ../source/tutorials/index.rst:4 -msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." +msgid "" +"**Tutorials** are opinionated step-by-step guides to help you get familiar " +"with packaging concepts. For more detailed information on specific packaging " +"topics, see :doc:`/guides/index`." msgstr "" #: ../source/tutorials/installing-packages.rst:5 @@ -8602,11 +12409,22 @@ msgid "Installing Packages" msgstr "" #: ../source/tutorials/installing-packages.rst:7 -msgid "This section covers the basics of how to install Python :term:`packages `." +msgid "" +"This section covers the basics of how to install Python :term:`packages " +"`." msgstr "" #: ../source/tutorials/installing-packages.rst:10 -msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." +msgid "" +"It's important to note that the term \"package\" in this context is being " +"used to describe a bundle of software to be installed (i.e. as a synonym for " +"a :term:`distribution `). It does not to refer to the " +"kind of :term:`package ` that you import in your Python " +"source code (i.e. a container of modules). It is common in the Python " +"community to refer to a :term:`distribution ` using " +"the term \"package\". Using the term \"distribution\" is often not " +"preferred, because it can easily be confused with a Linux distribution, or " +"another larger software distribution like Python itself." msgstr "" #: ../source/tutorials/installing-packages.rst:28 @@ -8614,7 +12432,9 @@ msgid "Requirements for Installing Packages" msgstr "" #: ../source/tutorials/installing-packages.rst:30 -msgid "This section describes the steps to follow before installing other Python packages." +msgid "" +"This section describes the steps to follow before installing other Python " +"packages." msgstr "" #: ../source/tutorials/installing-packages.rst:35 @@ -8622,11 +12442,16 @@ msgid "Ensure you can run Python from the command line" msgstr "" #: ../source/tutorials/installing-packages.rst:37 -msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" +msgid "" +"Before you go any further, make sure you have Python and that the expected " +"version is available from your command line. You can check this by running:" msgstr "" #: ../source/tutorials/installing-packages.rst:53 -msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." +msgid "" +"You should get some output like ``Python 3.6.3``. If you do not have Python, " +"please install the latest 3.x version from `python.org`_ or refer to the " +"`Installing Python`_ section of the Hitchhiker's Guide to Python." msgstr "" #: ../source/tutorials/installing-packages.rst:57 @@ -8634,19 +12459,37 @@ msgid "If you're a newcomer and you get an error like this:" msgstr "" #: ../source/tutorials/installing-packages.rst:66 -msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." +msgid "" +"It's because this command and other suggested commands in this tutorial are " +"intended to be run in a *shell* (also called a *terminal* or *console*). See " +"the Python for Beginners `getting started tutorial`_ for an introduction to " +"using your operating system's shell and interacting with Python." msgstr "" #: ../source/tutorials/installing-packages.rst:72 -msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" +msgid "" +"If you're using an enhanced shell like IPython or the Jupyter notebook, you " +"can run system commands like those in this tutorial by prefacing them with a " +"``!`` character:" msgstr "" #: ../source/tutorials/installing-packages.rst:82 -msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." +msgid "" +"It's recommended to write ``{sys.executable}`` rather than plain ``python`` " +"in order to ensure that commands are run in the Python installation matching " +"the currently running notebook (which may not be the same Python " +"installation that the ``python`` command refers to)." msgstr "" #: ../source/tutorials/installing-packages.rst:87 -msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." +msgid "" +"Due to the way most Linux distributions are handling the Python 3 migration, " +"Linux users using the system Python without creating a virtual environment " +"first should replace the ``python`` command in this tutorial with " +"``python3`` and the ``python -m pip`` command with ``python3 -m pip --" +"user``. Do *not* run any of the commands in this tutorial with ``sudo``: if " +"you get a permissions error, come back to the section on creating virtual " +"environments, set one up, and then continue with the tutorial as written." msgstr "" #: ../source/tutorials/installing-packages.rst:99 @@ -8654,15 +12497,23 @@ msgid "Ensure you can run pip from the command line" msgstr "" #: ../source/tutorials/installing-packages.rst:101 -msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" +msgid "" +"Additionally, you'll need to make sure you have :ref:`pip` available. You " +"can check this by running:" msgstr "" #: ../source/tutorials/installing-packages.rst:116 -msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." +msgid "" +"If you installed Python from source, with an installer from `python.org`_, " +"or via `Homebrew`_ you should already have pip. If you're on Linux and " +"installed using your OS package manager, you may have to install pip " +"separately, see :doc:`/guides/installing-using-linux-tools`." msgstr "" #: ../source/tutorials/installing-packages.rst:124 -msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" +msgid "" +"If ``pip`` isn't already installed, then first try to bootstrap it from the " +"standard library:" msgstr "" #: ../source/tutorials/installing-packages.rst:139 @@ -8670,15 +12521,24 @@ msgid "If that still doesn't allow you to run ``python -m pip``:" msgstr "" #: ../source/tutorials/installing-packages.rst:141 -msgid "Securely Download `get-pip.py `_ [1]_" +msgid "" +"Securely Download `get-pip.py `_ [1]_" msgstr "" #: ../source/tutorials/installing-packages.rst:144 -msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." +msgid "" +"Run ``python get-pip.py``. [2]_ This will install or upgrade pip. " +"Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're " +"not installed already." msgstr "" #: ../source/tutorials/installing-packages.rst:150 -msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." +msgid "" +"Be cautious if you're using a Python install that's managed by your " +"operating system or another package manager. get-pip.py does not coordinate " +"with those tools, and may leave your system in an inconsistent state. You " +"can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/" +"local`` which is designed for locally-installed software." msgstr "" #: ../source/tutorials/installing-packages.rst:159 @@ -8686,7 +12546,10 @@ msgid "Ensure pip, setuptools, and wheel are up to date" msgstr "" #: ../source/tutorials/installing-packages.rst:161 -msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" +msgid "" +"While ``pip`` alone is sufficient to install from pre-built binary archives, " +"up to date copies of the ``setuptools`` and ``wheel`` projects are useful to " +"ensure you can also install from source archives::" msgstr "" #: ../source/tutorials/installing-packages.rst:169 @@ -8694,11 +12557,17 @@ msgid "Optionally, create a virtual environment" msgstr "" #: ../source/tutorials/installing-packages.rst:171 -msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" +msgid "" +"See :ref:`section below ` for " +"details, but here's the basic `venv`_ [3]_ command to use on a typical Linux " +"system:" msgstr "" #: ../source/tutorials/installing-packages.rst:188 -msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." +msgid "" +"This will create a new virtual environment in the ``tutorial_env`` " +"subdirectory, and configure the current shell to use it as the default " +"``python`` environment." msgstr "" #: ../source/tutorials/installing-packages.rst:195 @@ -8706,35 +12575,62 @@ msgid "Creating Virtual Environments" msgstr "" #: ../source/tutorials/installing-packages.rst:197 -msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." +msgid "" +"Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular " +"application, rather than being installed globally. If you are looking to " +"safely install global command line tools, see :doc:`/guides/installing-stand-" +"alone-command-line-tools`." msgstr "" #: ../source/tutorials/installing-packages.rst:203 -msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." +msgid "" +"Imagine you have an application that needs version 1 of LibFoo, but another " +"application requires version 2. How can you use both these applications? If " +"you install everything into /usr/lib/python3.6/site-packages (or whatever " +"your platform’s standard location is), it’s easy to end up in a situation " +"where you unintentionally upgrade an application that shouldn’t be upgraded." msgstr "" #: ../source/tutorials/installing-packages.rst:209 -msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." +msgid "" +"Or more generally, what if you want to install an application and leave it " +"be? If an application works, any change in its libraries or the versions of " +"those libraries can break the application." msgstr "" #: ../source/tutorials/installing-packages.rst:213 -msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." +msgid "" +"Also, what if you can’t install :term:`packages ` into " +"the global site-packages directory? For instance, on a shared host." msgstr "" #: ../source/tutorials/installing-packages.rst:216 -msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." +msgid "" +"In all these cases, virtual environments can help you. They have their own " +"installation directories and they don’t share libraries with other virtual " +"environments." msgstr "" #: ../source/tutorials/installing-packages.rst:220 -msgid "Currently, there are two common tools for creating Python virtual environments:" +msgid "" +"Currently, there are two common tools for creating Python virtual " +"environments:" msgstr "" #: ../source/tutorials/installing-packages.rst:222 -msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." +msgid "" +"`venv`_ is available by default in Python 3.3 and later, and installs :ref:" +"`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 " +"and later." msgstr "" #: ../source/tutorials/installing-packages.rst:225 -msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." +msgid "" +":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ " +"and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are " +"always installed into created virtual environments by default (regardless of " +"Python version)." msgstr "" #: ../source/tutorials/installing-packages.rst:230 @@ -8750,19 +12646,31 @@ msgid "Using :ref:`virtualenv`:" msgstr "" #: ../source/tutorials/installing-packages.rst:264 -msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." +msgid "" +"For more information, see the `venv`_ docs or the `virtualenv `_ docs." msgstr "" #: ../source/tutorials/installing-packages.rst:266 -msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." +msgid "" +"The use of :command:`source` under Unix shells ensures that the virtual " +"environment's variables are set within the current shell, and not in a " +"subprocess (which then disappears, having no useful effect)." msgstr "" #: ../source/tutorials/installing-packages.rst:271 -msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" +msgid "" +"In both of the above cases, Windows users should _not_ use the :command:" +"`source` command, but should rather run the :command:`activate` script " +"directly from the command shell like so:" msgstr "" #: ../source/tutorials/installing-packages.rst:281 -msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." +msgid "" +"Managing multiple virtual environments directly can become tedious, so the :" +"ref:`dependency management tutorial ` introduces a " +"higher level tool, :ref:`Pipenv`, that automatically manages a separate " +"virtual environment for each project and application that you work on." msgstr "" #: ../source/tutorials/installing-packages.rst:288 @@ -8770,7 +12678,11 @@ msgid "Use pip for Installing" msgstr "" #: ../source/tutorials/installing-packages.rst:290 -msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." +msgid "" +":ref:`pip` is the recommended installer. Below, we'll cover the most common " +"usage scenarios. For more detail, see the `pip docs `_, " +"which includes a complete `Reference Guide `_." msgstr "" #: ../source/tutorials/installing-packages.rst:297 @@ -8778,7 +12690,14 @@ msgid "Installing from PyPI" msgstr "" #: ../source/tutorials/installing-packages.rst:299 -msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." +msgid "" +"The most common usage of :ref:`pip` is to install from the :term:`Python " +"Package Index ` using a :term:`requirement " +"specifier `. Generally speaking, a requirement " +"specifier is composed of a project name followed by an optional :term:" +"`version specifier `. :pep:`440` contains a :pep:`full " +"specification <440#version-specifiers>` of the currently supported " +"specifiers. Below are some examples." msgstr "" #: ../source/tutorials/installing-packages.rst:307 @@ -8794,11 +12713,15 @@ msgid "To install greater than or equal to one version and less than another:" msgstr "" #: ../source/tutorials/installing-packages.rst:350 -msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" +msgid "" +"To install a version that's :pep:`\"compatible\" <440#compatible-release>` " +"with a certain version: [4]_" msgstr "" #: ../source/tutorials/installing-packages.rst:365 -msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." +msgid "" +"In this case, this means to install any version \"==1.4.*\" version that's " +"also \">=1.4.2\"." msgstr "" #: ../source/tutorials/installing-packages.rst:370 @@ -8806,15 +12729,27 @@ msgid "Source Distributions vs Wheels" msgstr "" #: ../source/tutorials/installing-packages.rst:372 -msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." +msgid "" +":ref:`pip` can install from either :term:`Source Distributions (sdist) " +"` or :term:`Wheels `, but if both " +"are present on PyPI, pip will prefer a compatible :term:`wheel `. You " +"can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." msgstr "" #: ../source/tutorials/installing-packages.rst:378 -msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." +msgid "" +":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source " +"Distributions (sdist) `, especially when " +"a project contains compiled extensions." msgstr "" #: ../source/tutorials/installing-packages.rst:383 -msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." +msgid "" +"If :ref:`pip` does not find a wheel to install, it will locally build a " +"wheel and cache it for future installs, instead of rebuilding the source " +"distribution in the future." msgstr "" #: ../source/tutorials/installing-packages.rst:391 @@ -8826,31 +12761,58 @@ msgid "Installing to the User Site" msgstr "" #: ../source/tutorials/installing-packages.rst:410 -msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" +msgid "" +"To install :term:`packages ` that are isolated to the " +"current user, use the ``--user`` flag:" msgstr "" #: ../source/tutorials/installing-packages.rst:425 -msgid "For more information see the `User Installs `_ section from the pip docs." +msgid "" +"For more information see the `User Installs `_ section from the pip docs." msgstr "" #: ../source/tutorials/installing-packages.rst:429 -msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." +msgid "" +"Note that the ``--user`` flag has no effect when inside a virtual " +"environment - all installation commands will affect the virtual environment." msgstr "" #: ../source/tutorials/installing-packages.rst:432 -msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" +msgid "" +"If ``SomeProject`` defines any command-line scripts or console entry points, " +"``--user`` will cause them to be installed inside the `user base`_'s binary " +"directory, which may or may not already be present in your shell's :envvar:" +"`PATH`. (Starting in version 10, pip displays a warning when installing any " +"scripts to a directory outside :envvar:`PATH`.) If the scripts are not " +"available in your shell after installation, you'll need to add the directory " +"to your :envvar:`PATH`:" msgstr "" #: ../source/tutorials/installing-packages.rst:440 -msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." +msgid "" +"On Linux and macOS you can find the user base binary directory by running " +"``python -m site --user-base`` and adding ``bin`` to the end. For example, " +"this will typically print ``~/.local`` (with ``~`` expanded to the absolute " +"path to your home directory) so you'll need to add ``~/.local/bin`` to your " +"``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." msgstr "" #: ../source/tutorials/installing-packages.rst:446 -msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." +msgid "" +"On Windows you can find the user base binary directory by running ``py -m " +"site --user-site`` and replacing ``site-packages`` with ``Scripts``. For " +"example, this could return ``C:\\Users\\Username\\AppData\\Roaming" +"\\Python36\\site-packages`` so you would need to set your ``PATH`` to " +"include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You " +"can set your user ``PATH`` permanently in the `Control Panel`_. You may need " +"to log out for the ``PATH`` changes to take effect." msgstr "" #: ../source/tutorials/installing-packages.rst:462 -msgid "Install a list of requirements specified in a :ref:`Requirements File `." +msgid "" +"Install a list of requirements specified in a :ref:`Requirements File `." msgstr "" #: ../source/tutorials/installing-packages.rst:478 @@ -8858,7 +12820,9 @@ msgid "Installing from VCS" msgstr "" #: ../source/tutorials/installing-packages.rst:480 -msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." +msgid "" +"Install a project from VCS in \"editable\" mode. For a full breakdown of " +"the syntax, see pip's section on :ref:`VCS Support `." msgstr "" #: ../source/tutorials/installing-packages.rst:502 @@ -8870,7 +12834,9 @@ msgid "Install from an alternate index" msgstr "" #: ../source/tutorials/installing-packages.rst:518 -msgid "Search an additional index during install, in addition to :term:`PyPI `" +msgid "" +"Search an additional index during install, in addition to :term:`PyPI " +"`" msgstr "" #: ../source/tutorials/installing-packages.rst:534 @@ -8878,7 +12844,11 @@ msgid "Installing from a local src tree" msgstr "" #: ../source/tutorials/installing-packages.rst:537 -msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." +msgid "" +"Installing from local src in `Development Mode `_, i.e. in such a " +"way that the project appears to be installed, but yet is still editable from " +"the src tree." msgstr "" #: ../source/tutorials/installing-packages.rst:554 @@ -8890,7 +12860,9 @@ msgid "Install a particular source archive file." msgstr "" #: ../source/tutorials/installing-packages.rst:585 -msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" +msgid "" +"Install from a local directory containing archives (and don't check :term:" +"`PyPI `)" msgstr "" #: ../source/tutorials/installing-packages.rst:605 @@ -8898,7 +12870,11 @@ msgid "Installing from other sources" msgstr "" #: ../source/tutorials/installing-packages.rst:607 -msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." +msgid "" +"To install from other data sources (for example Amazon S3 storage) you can " +"create a helper application that presents the data in a :pep:`503` compliant " +"index format, and use the ``--extra-index-url`` flag to direct pip to use " +"that index." msgstr "" #: ../source/tutorials/installing-packages.rst:619 @@ -8906,7 +12882,9 @@ msgid "Installing Prereleases" msgstr "" #: ../source/tutorials/installing-packages.rst:621 -msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." +msgid "" +"Find pre-release and development versions, in addition to stable versions. " +"By default, pip only finds stable versions." msgstr "" #: ../source/tutorials/installing-packages.rst:637 @@ -8918,15 +12896,23 @@ msgid "Install `setuptools extras`_." msgstr "" #: ../source/tutorials/installing-packages.rst:659 -msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." +msgid "" +"\"Secure\" in this context means using a modern browser or a tool like :" +"command:`curl` that verifies SSL certificates when downloading from https " +"URLs." msgstr "" #: ../source/tutorials/installing-packages.rst:668 -msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." +msgid "" +"Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:" +"`virtualenv`) will create virtualenv environments with ``pip`` pre-" +"installed, thereby making it an equal alternative to :ref:`virtualenv`." msgstr "" #: ../source/tutorials/installing-packages.rst:673 -msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" +msgid "" +"The compatible release specifier was accepted in :pep:`440` and support was " +"released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" msgstr "" #: ../source/tutorials/managing-dependencies.rst:4 @@ -8934,23 +12920,42 @@ msgid "Managing Application Dependencies" msgstr "" #: ../source/tutorials/managing-dependencies.rst:6 -msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." +msgid "" +"The :ref:`package installation tutorial ` covered the " +"basics of getting set up to install and update Python packages." msgstr "" #: ../source/tutorials/managing-dependencies.rst:9 -msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." +msgid "" +"However, running these commands interactively can get tedious even for your " +"own personal projects, and things get even more difficult when trying to set " +"up development environments automatically for projects with multiple " +"contributors." msgstr "" #: ../source/tutorials/managing-dependencies.rst:13 -msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." +msgid "" +"This tutorial walks you through the use of :ref:`Pipenv` to manage " +"dependencies for an application. It will show you how to install and use the " +"necessary tools and make strong recommendations on best practices." msgstr "" #: ../source/tutorials/managing-dependencies.rst:17 -msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." +msgid "" +"Keep in mind that Python is used for a great many different purposes, and " +"precisely how you want to manage your dependencies may change based on how " +"you decide to publish your software. The guidance presented here is most " +"directly applicable to the development and deployment of network services " +"(including web applications), but is also very well suited to managing " +"development and testing environments for any kind of project." msgstr "" #: ../source/tutorials/managing-dependencies.rst:24 -msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." +msgid "" +"Developers of Python libraries, or of applications that support distribution " +"as Python libraries, should also consider the `poetry `_ project as an alternative dependency management " +"solution." msgstr "" #: ../source/tutorials/managing-dependencies.rst:30 @@ -8958,7 +12963,12 @@ msgid "Installing Pipenv" msgstr "" #: ../source/tutorials/managing-dependencies.rst:32 -msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." +msgid "" +":ref:`Pipenv` is a dependency manager for Python projects. If you're " +"familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit " +"to those tools. While :ref:`pip` alone is often sufficient for personal use, " +"Pipenv is recommended for collaborative projects as it's a higher-level tool " +"that simplifies dependency management for common use cases." msgstr "" #: ../source/tutorials/managing-dependencies.rst:38 @@ -8966,7 +12976,11 @@ msgid "Use ``pip`` to install Pipenv:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:54 -msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." +msgid "" +"This does a `user installation`_ to prevent breaking any system-wide " +"packages. If ``pipenv`` isn't available in your shell after installation, " +"you'll need to add the `user base`_'s binary directory to your ``PATH``. " +"See :ref:`Installing to the User Site` for more information." msgstr "" #: ../source/tutorials/managing-dependencies.rst:65 @@ -8974,11 +12988,19 @@ msgid "Installing packages for your project" msgstr "" #: ../source/tutorials/managing-dependencies.rst:67 -msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" +msgid "" +"Pipenv manages dependencies on a per-project basis. To install packages, " +"change into your project's directory (or just an empty directory for this " +"tutorial) and run:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:76 -msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" +msgid "" +"Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you " +"in your project's directory. The :ref:`Pipfile` is used to track which " +"dependencies your project needs in case you need to re-install them, such as " +"when you share your project with others. You should get output similar to " +"this (although the exact paths shown will vary):" msgstr "" #: ../source/tutorials/managing-dependencies.rst:112 @@ -8986,7 +13008,9 @@ msgid "Using installed packages" msgstr "" #: ../source/tutorials/managing-dependencies.rst:114 -msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" +msgid "" +"Now that Requests is installed you can create a simple :file:`main.py` file " +"to use it:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:125 @@ -8998,7 +13022,10 @@ msgid "You should get output similar to this:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:137 -msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." +msgid "" +"Using ``pipenv run`` ensures that your installed packages are available to " +"your script. It's also possible to spawn a new shell that ensures all " +"commands have access to your installed packages with ``pipenv shell``." msgstr "" #: ../source/tutorials/managing-dependencies.rst:143 @@ -9007,15 +13034,24 @@ msgid "Next steps" msgstr "" #: ../source/tutorials/managing-dependencies.rst:145 -msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" +msgid "" +"Congratulations, you now know how to effectively manage dependencies and " +"development environments on a collaborative Python project! ✨ 🍰 ✨" msgstr "" #: ../source/tutorials/managing-dependencies.rst:148 -msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." +msgid "" +"If you're interested in creating and distributing your own Python packages, " +"see the :ref:`tutorial on packaging and distributing packages `." msgstr "" #: ../source/tutorials/managing-dependencies.rst:151 -msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." +msgid "" +"Note that when your application includes definitions of Python source " +"packages, they (and their dependencies) can be added to your ``pipenv`` " +"environment with ``pipenv install -e `` " +"(e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." msgstr "" #: ../source/tutorials/managing-dependencies.rst:160 @@ -9023,23 +13059,43 @@ msgid "Other Tools for Application Dependency Management" msgstr "" #: ../source/tutorials/managing-dependencies.rst:162 -msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" +msgid "" +"If you find this particular approach to managing application dependencies " +"isn't working well for you or your use case, you may want to explore these " +"other tools and techniques to see if one of them is a better fit:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:166 -msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." +msgid "" +"`poetry `__ for a tool comparable " +"in scope to ``pipenv`` that focuses more directly on use cases where the " +"repository being managed is structured as a Python project with a valid " +"``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making " +"the assumption that the application being worked on that's depending on " +"components from PyPI will itself support distribution as a ``pip``-" +"installable Python package)." msgstr "" #: ../source/tutorials/managing-dependencies.rst:172 -msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" +msgid "" +"`hatch `_ for opinionated coverage of even " +"more steps in the project management workflow (such as incrementing " +"versions, tagging releases, and creating new skeleton projects from project " +"templates)" msgstr "" #: ../source/tutorials/managing-dependencies.rst:175 -msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" +msgid "" +"`pip-tools `_ to build your own " +"custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" msgstr "" #: ../source/tutorials/managing-dependencies.rst:177 -msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." +msgid "" +"`micropipenv `_ is a " +"lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry " +"lock files or converting them to pip-tools compatible output. Designed for " +"containerized Python applications but not limited to them." msgstr "" #: ../source/tutorials/packaging-projects.rst:2 @@ -9047,15 +13103,24 @@ msgid "Packaging Python Projects" msgstr "" #: ../source/tutorials/packaging-projects.rst:4 -msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." +msgid "" +"This tutorial walks you through how to package a simple Python project. It " +"will show you how to add the necessary files and structure to create the " +"package, how to build the package, and how to upload it to the Python " +"Package Index." msgstr "" #: ../source/tutorials/packaging-projects.rst:10 -msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" +msgid "" +"If you have trouble running the commands in this tutoral, please copy the " +"command and its output, then `open an issue`_ on the `packaging-problems`_ " +"repository on GitHub. We'll do our best to help you!" msgstr "" #: ../source/tutorials/packaging-projects.rst:18 -msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" +msgid "" +"Some of the commands require a newer version of :ref:`pip`, so start by " +"making sure you have the latest version installed:" msgstr "" #: ../source/tutorials/packaging-projects.rst:35 @@ -9063,7 +13128,10 @@ msgid "A simple project" msgstr "" #: ../source/tutorials/packaging-projects.rst:37 -msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." +msgid "" +"This tutorial uses a simple project named ``example_package``. We recommend " +"following this tutorial as-is using this project, before packaging your own " +"project." msgstr "" #: ../source/tutorials/packaging-projects.rst:41 @@ -9071,19 +13139,29 @@ msgid "Create the following file structure locally:" msgstr "" #: ../source/tutorials/packaging-projects.rst:51 -msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." +msgid "" +":file:`__init__.py` is required to import the directory as a package, and " +"should be empty." msgstr "" #: ../source/tutorials/packaging-projects.rst:54 -msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" +msgid "" +":file:`example.py` is an example of a module within the package that could " +"contain the logic (functions, classes, constants, etc.) of your package. " +"Open that file and enter the following content:" msgstr "" #: ../source/tutorials/packaging-projects.rst:63 -msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." +msgid "" +"If you are unfamiliar with Python's :term:`modules ` and :term:" +"`import packages `, take a few minutes to read over the " +"`Python documentation for packages and modules`_." msgstr "" #: ../source/tutorials/packaging-projects.rst:67 -msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." +msgid "" +"Once you create this structure, you'll want to run all of the commands in " +"this tutorial within the ``packaging_tutorial`` directory." msgstr "" #: ../source/tutorials/packaging-projects.rst:75 @@ -9091,7 +13169,9 @@ msgid "Creating the package files" msgstr "" #: ../source/tutorials/packaging-projects.rst:77 -msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" +msgid "" +"You will now add files that are used to prepare the project for " +"distribution. When you're done, the project structure will look like this:" msgstr "" #: ../source/tutorials/packaging-projects.rst:95 @@ -9107,15 +13187,26 @@ msgid "Creating pyproject.toml" msgstr "" #: ../source/tutorials/packaging-projects.rst:103 -msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" +msgid "" +":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) " +"what is required to build your project. This tutorial uses :ref:" +"`setuptools`, so open :file:`pyproject.toml` and enter the following content:" msgstr "" #: ../source/tutorials/packaging-projects.rst:117 -msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." +msgid "" +"``build-system.requires`` gives a list of packages that are needed to build " +"your package. Listing something here will *only* make it available during " +"the build, not after it is installed." msgstr "" #: ../source/tutorials/packaging-projects.rst:121 -msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." +msgid "" +"``build-system.build-backend`` is the name of Python object that will be " +"used to perform the build. If you were to use a different build system, such " +"as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration " +"details would be completely different than the :ref:`setuptools` " +"configuration described below." msgstr "" #: ../source/tutorials/packaging-projects.rst:127 @@ -9131,41 +13222,74 @@ msgid "There are two types of metadata: static and dynamic." msgstr "" #: ../source/tutorials/packaging-projects.rst:135 -msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." +msgid "" +"Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. " +"This is simpler, easier to read, and avoids many common errors, like " +"encoding errors." msgstr "" #: ../source/tutorials/packaging-projects.rst:137 -msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." +msgid "" +"Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items " +"that are dynamic or determined at install-time, as well as extension modules " +"or extensions to setuptools, need to go into :file:`setup.py`." msgstr "" #: ../source/tutorials/packaging-projects.rst:141 -msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." +msgid "" +"Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:" +"file:`setup.py`) should be used only as an escape hatch when absolutely " +"necessary. :file:`setup.py` used to be required, but can be omitted with " +"newer versions of setuptools and pip." msgstr "" #: ../source/tutorials/packaging-projects.rst:148 -msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." +msgid "" +":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells " +"setuptools about your package (such as the name and version) as well as " +"which code files to include. Eventually much of this configuration may be " +"able to move to :file:`pyproject.toml`." msgstr "" #: ../source/tutorials/packaging-projects.rst:153 -msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgid "" +"Open :file:`setup.cfg` and enter the following content. Change the ``name`` " +"to include your username; this ensures that you have a unique package name " +"and that your package doesn't conflict with packages uploaded by other " +"people following this tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:185 -msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" +msgid "" +"There are a `variety of metadata and options `_ supported here. This is " +"in :doc:`configparser ` format; do not place " +"quotes around values. This example package uses a relatively minimal set of " +"``metadata``:" msgstr "" #: ../source/tutorials/packaging-projects.rst:191 #: ../source/tutorials/packaging-projects.rst:286 -msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." +msgid "" +"``name`` is the *distribution name* of your package. This can be any name as " +"long as it only contains letters, numbers, ``_`` , and ``-``. It also must " +"not already be taken on pypi.org. **Be sure to update this with your " +"username,** as this ensures you won't try to upload a package with the same " +"name as one which already exists." msgstr "" #: ../source/tutorials/packaging-projects.rst:196 -msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." +msgid "" +"``version`` is the package version. See :pep:`440` for more details on " +"versions. You can use ``file:`` or ``attr:`` directives to read from a file " +"or package attribute." msgstr "" #: ../source/tutorials/packaging-projects.rst:199 #: ../source/tutorials/packaging-projects.rst:293 -msgid "``author`` and ``author_email`` are used to identify the author of the package." +msgid "" +"``author`` and ``author_email`` are used to identify the author of the " +"package." msgstr "" #: ../source/tutorials/packaging-projects.rst:201 @@ -9174,27 +13298,45 @@ msgid "``description`` is a short, one-sentence summary of the package." msgstr "" #: ../source/tutorials/packaging-projects.rst:202 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." +msgid "" +"``long_description`` is a detailed description of the package. This is shown " +"on the package detail page on the Python Package Index. In this case, the " +"long description is loaded from :file:`README.md` (which is a common " +"pattern) using the ``file:`` directive." msgstr "" #: ../source/tutorials/packaging-projects.rst:206 #: ../source/tutorials/packaging-projects.rst:300 -msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." +msgid "" +"``long_description_content_type`` tells the index what type of markup is " +"used for the long description. In this case, it's Markdown." msgstr "" #: ../source/tutorials/packaging-projects.rst:208 #: ../source/tutorials/packaging-projects.rst:302 -msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." +msgid "" +"``url`` is the URL for the homepage of the project. For many projects, this " +"will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting " +"service." msgstr "" #: ../source/tutorials/packaging-projects.rst:211 #: ../source/tutorials/packaging-projects.rst:305 -msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." +msgid "" +"``project_urls`` lets you list any number of extra links to show on PyPI. " +"Generally this could be to documentation, issue trackers, etc." msgstr "" #: ../source/tutorials/packaging-projects.rst:213 #: ../source/tutorials/packaging-projects.rst:307 -msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." +msgid "" +"``classifiers`` gives the index and :ref:`pip` some additional metadata " +"about your package. In this case, the package is only compatible with Python " +"3, is licensed under the MIT license, and is OS-independent. You should " +"always include at least which version(s) of Python your package works on, " +"which license your package is available under, and which operating systems " +"your package will work on. For a complete list of classifiers, see https://" +"pypi.org/classifiers/." msgstr "" #: ../source/tutorials/packaging-projects.rst:221 @@ -9202,52 +13344,96 @@ msgid "In the ``options`` category, we have controls for setuptools itself:" msgstr "" #: ../source/tutorials/packaging-projects.rst:223 -msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgid "" +"``package_dir`` is a mapping of package names and directories. An empty " +"package name represents the \"root package\" --- the directory in the " +"project that contains all Python source files for the package --- so in this " +"case the ``src`` directory is designated the root package." msgstr "" #: ../source/tutorials/packaging-projects.rst:227 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgid "" +"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " +"`. Instead of listing each package manually, we can " +"use the ``find:`` directive to automatically discover all packages and " +"subpackages and ``options.packages.find`` to specify the ``package_dir`` to " +"use. In this case, the list of packages will be ``example_package`` as " +"that's the only package present." msgstr "" #: ../source/tutorials/packaging-projects.rst:234 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." +msgid "" +"``python_requires`` gives the versions of Python supported by your project. " +"Installers like :ref:`pip` will look back through older versions of packages " +"until it finds one that has a matching Python version." msgstr "" #: ../source/tutorials/packaging-projects.rst:238 #: ../source/tutorials/packaging-projects.rst:329 -msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." +msgid "" +"There are many more than the ones mentioned here. See :doc:`/guides/" +"distributing-packages-using-setuptools` for more details." msgstr "" #: ../source/tutorials/packaging-projects.rst:244 -msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." +msgid "" +":file:`setup.py` is the build script for :ref:`setuptools`. It tells " +"setuptools about your package (such as the name and version) as well as " +"which code files to include." msgstr "" #: ../source/tutorials/packaging-projects.rst:248 -msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgid "" +"Open :file:`setup.py` and enter the following content. Change the ``name`` " +"to include your username; this ensures that you have a unique package name " +"and that your package doesn't conflict with packages uploaded by other " +"people following this tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:283 -msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" +msgid "" +":func:`setup` takes several arguments. This example package uses a " +"relatively minimal set:" msgstr "" #: ../source/tutorials/packaging-projects.rst:291 -msgid "``version`` is the package version. See :pep:`440` for more details on versions." +msgid "" +"``version`` is the package version. See :pep:`440` for more details on " +"versions." msgstr "" #: ../source/tutorials/packaging-projects.rst:296 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." +msgid "" +"``long_description`` is a detailed description of the package. This is shown " +"on the package detail page on the Python Package Index. In this case, the " +"long description is loaded from :file:`README.md`, which is a common pattern." msgstr "" #: ../source/tutorials/packaging-projects.rst:314 -msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgid "" +"``package_dir`` is a dictionary with package names for keys and directories " +"for values. An empty package name represents the \"root package\" --- the " +"directory in the project that contains all Python source files for the " +"package --- so in this case the ``src`` directory is designated the root " +"package." msgstr "" #: ../source/tutorials/packaging-projects.rst:319 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgid "" +"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " +"`. Instead of listing each package manually, we can " +"use :func:`find_packages` to automatically discover all packages and " +"subpackages under ``package_dir``. In this case, the list of packages will " +"be ``example_package`` as that's the only package present." msgstr "" #: ../source/tutorials/packaging-projects.rst:325 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." +msgid "" +"``python_requires`` gives the versions of Python supported by your project. " +"Installers like :ref:`pip` will look back though older versions of packages " +"until it finds one that has a matching Python version." msgstr "" #: ../source/tutorials/packaging-projects.rst:333 @@ -9255,11 +13441,17 @@ msgid "Creating README.md" msgstr "" #: ../source/tutorials/packaging-projects.rst:335 -msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." +msgid "" +"Open :file:`README.md` and enter the following content. You can customize " +"this if you'd like." msgstr "" #: ../source/tutorials/packaging-projects.rst:347 -msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." +msgid "" +"Because our configuration loads :file:`README.md` to provide a " +"``long_description``, :file:`README.md` must be included along with your " +"code when you :ref:`generate a source distribution `. " +"Newer versions of :ref:`setuptools` will do this automatically." msgstr "" #: ../source/tutorials/packaging-projects.rst:354 @@ -9267,7 +13459,12 @@ msgid "Creating a LICENSE" msgstr "" #: ../source/tutorials/packaging-projects.rst:356 -msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" +msgid "" +"It's important for every package uploaded to the Python Package Index to " +"include a license. This tells users who install your package the terms under " +"which they can use your package. For help picking a license, see https://" +"choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` " +"and enter the license text. For example, if you had chosen the MIT license:" msgstr "" #: ../source/tutorials/packaging-projects.rst:387 @@ -9275,11 +13472,19 @@ msgid "Including other files" msgstr "" #: ../source/tutorials/packaging-projects.rst:389 -msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." +msgid "" +"The files listed above will be included automatically in your :term:`source " +"distribution `. If you want to control " +"what goes in this explicitly, see :ref:`Using MANIFEST.in`." msgstr "" #: ../source/tutorials/packaging-projects.rst:393 -msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." +msgid "" +"The final :term:`built distribution ` will have the " +"Python files in the discovered or listed Python packages. If you want to " +"control what goes here, such as to add data files, see :doc:`Including Data " +"Files ` from the :doc:`setuptools docs " +"`." msgstr "" #: ../source/tutorials/packaging-projects.rst:402 @@ -9287,7 +13492,10 @@ msgid "Generating distribution archives" msgstr "" #: ../source/tutorials/packaging-projects.rst:404 -msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." +msgid "" +"The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the " +"Python Package Index and can be installed by :ref:`pip`." msgstr "" #: ../source/tutorials/packaging-projects.rst:408 @@ -9295,19 +13503,32 @@ msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" msgstr "" #: ../source/tutorials/packaging-projects.rst:422 -msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." +msgid "" +"If you have trouble installing these, see the :doc:`installing-packages` " +"tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:425 -msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" +msgid "" +"Now run this command from the same directory where :file:`pyproject.toml` is " +"located:" msgstr "" #: ../source/tutorials/packaging-projects.rst:439 -msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" +msgid "" +"This command should output a lot of text and once completed should generate " +"two files in the :file:`dist` directory:" msgstr "" #: ../source/tutorials/packaging-projects.rst:449 -msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." +msgid "" +"The ``tar.gz`` file is a :term:`source archive ` whereas the " +"``.whl`` file is a :term:`built distribution `. Newer :" +"ref:`pip` versions preferentially install built distributions, but will fall " +"back to source archives if needed. You should always upload a source archive " +"and provide built archives for the platforms your project is compatible " +"with. In this case, our example package is compatible with Python on any " +"platform so only one built distribution is needed." msgstr "" #: ../source/tutorials/packaging-projects.rst:458 @@ -9319,23 +13540,40 @@ msgid "Finally, it's time to upload your package to the Python Package Index!" msgstr "" #: ../source/tutorials/packaging-projects.rst:462 -msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." +msgid "" +"The first thing you'll need to do is register an account on TestPyPI, which " +"is a separate instance of the package index intended for testing and " +"experimentation. It's great for things like this tutorial where we don't " +"necessarily want to upload to the real index. To register an account, go to " +"https://test.pypi.org/account/register/ and complete the steps on that page. " +"You will also need to verify your email address before you're able to upload " +"any packages. For more details, see :doc:`/guides/using-testpypi`." msgstr "" #: ../source/tutorials/packaging-projects.rst:470 -msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgid "" +"To securely upload your project, you'll need a PyPI `API token`_. Create one " +"at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" " +"to \"Entire account\". **Don't close the page until you have copied and " +"saved the token — you won't see that token again.**" msgstr "" #: ../source/tutorials/packaging-projects.rst:477 -msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" +msgid "" +"Now that you are registered, you can use :ref:`twine` to upload the " +"distribution packages. You'll need to install Twine:" msgstr "" #: ../source/tutorials/packaging-projects.rst:492 -msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" +msgid "" +"Once installed, run Twine to upload all of the archives under :file:`dist`:" msgstr "" #: ../source/tutorials/packaging-projects.rst:506 -msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." +msgid "" +"You will be prompted for a username and password. For the username, use " +"``__token__``. For the password, use the token value, including the ``pypi-" +"`` prefix." msgstr "" #: ../source/tutorials/packaging-projects.rst:510 @@ -9343,7 +13581,9 @@ msgid "After the command completes, you should see output similar to this:" msgstr "" #: ../source/tutorials/packaging-projects.rst:523 -msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" +msgid "" +"Once uploaded your package should be viewable on TestPyPI, for example, " +"https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" msgstr "" #: ../source/tutorials/packaging-projects.rst:528 @@ -9351,7 +13591,10 @@ msgid "Installing your newly uploaded package" msgstr "" #: ../source/tutorials/packaging-projects.rst:530 -msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" +msgid "" +"You can use :ref:`pip` to install your package and verify that it works. " +"Create a :ref:`virtual environment ` and install your package from TestPyPI:" msgstr "" #: ../source/tutorials/packaging-projects.rst:546 @@ -9359,15 +13602,25 @@ msgid "Make sure to specify your username in the package name!" msgstr "" #: ../source/tutorials/packaging-projects.rst:548 -msgid "pip should install the package from TestPyPI and the output should look something like this:" +msgid "" +"pip should install the package from TestPyPI and the output should look " +"something like this:" msgstr "" #: ../source/tutorials/packaging-projects.rst:558 -msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." +msgid "" +"This example uses ``--index-url`` flag to specify TestPyPI instead of live " +"PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have " +"the same packages as the live PyPI, it's possible that attempting to install " +"dependencies may fail or install something unexpected. While our example " +"package doesn't have any dependencies, it's a good practice to avoid " +"installing dependencies when using TestPyPI." msgstr "" #: ../source/tutorials/packaging-projects.rst:565 -msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" +msgid "" +"You can test that it was installed correctly by importing the package. Make " +"sure you're still in your virtual environment, then run Python:" msgstr "" #: ../source/tutorials/packaging-projects.rst:580 @@ -9375,43 +13628,70 @@ msgid "and import the package:" msgstr "" #: ../source/tutorials/packaging-projects.rst:588 -msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." +msgid "" +"Note that the :term:`import package ` is ``example_package`` " +"regardless of what ``name`` you gave your :term:`distribution package " +"` in :file:`setup.cfg` or :file:`setup.py` (in this " +"case, ``example-pkg-YOUR-USERNAME-HERE``)." msgstr "" #: ../source/tutorials/packaging-projects.rst:596 -msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" +msgid "" +"**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" msgstr "" #: ../source/tutorials/packaging-projects.rst:599 -msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." +msgid "" +"Keep in mind that this tutorial showed you how to upload your package to " +"Test PyPI, which isn't a permanent storage. The Test system occasionally " +"deletes packages and accounts. It is best to use TestPyPI for testing and " +"experiments like this tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:604 -msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" +msgid "" +"When you are ready to upload a real package to the Python Package Index you " +"can do much the same as you did in this tutorial, but with these important " +"differences:" msgstr "" #: ../source/tutorials/packaging-projects.rst:608 -msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." +msgid "" +"Choose a memorable and unique name for your package. You don't have to " +"append your username as you did in the tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:610 -msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." +msgid "" +"Register an account on https://pypi.org - note that these are two separate " +"servers and the login details from the test server are not shared with the " +"main server." msgstr "" #: ../source/tutorials/packaging-projects.rst:613 -msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." +msgid "" +"Use ``twine upload dist/*`` to upload your package and enter your " +"credentials for the account you registered on the real PyPI. Now that " +"you're uploading the package in production, you don't need to specify ``--" +"repository``; the package will upload to https://pypi.org/ by default." msgstr "" #: ../source/tutorials/packaging-projects.rst:617 -msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." +msgid "" +"Install your package from the real PyPI using ``python3 -m pip install [your-" +"package]``." msgstr "" #: ../source/tutorials/packaging-projects.rst:619 -msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" +msgid "" +"At this point if you want to read more on packaging Python libraries here " +"are some things you can do:" msgstr "" #: ../source/tutorials/packaging-projects.rst:622 -msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." +msgid "" +"Read more about using :ref:`setuptools` to package libraries in :doc:`/" +"guides/distributing-packages-using-setuptools`." msgstr "" #: ../source/tutorials/packaging-projects.rst:624 @@ -9419,5 +13699,7 @@ msgid "Read about :doc:`/guides/packaging-binary-extensions`." msgstr "" #: ../source/tutorials/packaging-projects.rst:625 -msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." +msgid "" +"Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:" +"`hatch`, and :ref:`poetry`." msgstr "" diff --git a/locales/uk/LC_MESSAGES/messages.po b/locales/uk/LC_MESSAGES/messages.po index 086bb90a4..b3d1d5c96 100644 --- a/locales/uk/LC_MESSAGES/messages.po +++ b/locales/uk/LC_MESSAGES/messages.po @@ -10,8 +10,8 @@ msgstr "" "POT-Creation-Date: 2021-07-06 19:32+0800\n" "PO-Revision-Date: 2021-07-16 11:12+0000\n" "Last-Translator: Sviatoslav Sydorenko \n" -"Language-Team: Ukrainian \n" +"Language-Team: Ukrainian \n" "Language: uk\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -25,7 +25,9 @@ msgid "Contribute to this guide" msgstr "Зробіть внесок до керівництва" #: ../source/contribute.rst:7 -msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" +msgid "" +"The |PyPUG| welcomes contributors! There are lots of ways to help out, " +"including:" msgstr "" "|PyPUG| запрошує контриб'юторів! Тут є багато способів, щоб допомогти, " "зокрема:" @@ -47,11 +49,17 @@ msgid "Writing new content" msgstr "Написання нового вмісту" #: ../source/contribute.rst:15 -msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." +msgid "" +"Most of the work on the |PyPUG| takes place on the `project's GitHub " +"repository`__. To get started, check out the list of `open issues`__ and " +"`pull requests`__. If you're planning to write or edit the guide, please " +"read the :ref:`style guide `." msgstr "" #: ../source/contribute.rst:24 -msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." +msgid "" +"By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of " +"Conduct`__." msgstr "" #: ../source/contribute.rst:31 @@ -59,35 +67,47 @@ msgid "Documentation types" msgstr "Типи документації" #: ../source/contribute.rst:33 -msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." +msgid "" +"This project consists of four distinct documentation types with specific " +"purposes. When proposing new additions to the project please pick the " +"appropriate documentation type." msgstr "" -#: ../source/contribute.rst:38 -#: ../source/tutorials/index.rst:2 +#: ../source/contribute.rst:38 ../source/tutorials/index.rst:2 #, fuzzy msgid "Tutorials" msgstr "Туторіали" #: ../source/contribute.rst:40 -msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." +msgid "" +"Tutorials are focused on teaching the reader new concepts by accomplishing a " +"goal. They are opinionated step-by-step guides. They do not include " +"extraneous warnings or information. `example tutorial-style document`_." msgstr "" -#: ../source/contribute.rst:47 -#: ../source/guides/index.rst:2 +#: ../source/contribute.rst:47 ../source/guides/index.rst:2 msgid "Guides" msgstr "Керівництва" #: ../source/contribute.rst:49 -msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." +msgid "" +"Guides are focused on accomplishing a specific task and can assume some " +"level of pre-requisite knowledge. These are similar to tutorials, but have a " +"narrow and clear focus and can provide lots of caveats and additional " +"information as needed. They may also discuss multiple approaches to " +"accomplishing the task. :doc:`example guide-style document `." msgstr "" -#: ../source/contribute.rst:56 -#: ../source/discussions/index.rst:2 +#: ../source/contribute.rst:56 ../source/discussions/index.rst:2 msgid "Discussions" msgstr "Обговорення" #: ../source/contribute.rst:58 -msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." +msgid "" +"Discussions are focused on understanding and information. These explore a " +"specific topic without a specific goal in mind. :doc:`example discussion-" +"style document `." msgstr "" #: ../source/contribute.rst:63 @@ -95,7 +115,11 @@ msgid "Specifications" msgstr "Специфікації" #: ../source/contribute.rst:65 -msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." +msgid "" +"Specifications are reference documention focused on comprehensively " +"documenting an agreed-upon interface for interoperability between packaging " +"tools. :doc:`example specification-style document `." msgstr "" #: ../source/contribute.rst:73 @@ -103,27 +127,42 @@ msgid "Building the guide locally" msgstr "" #: ../source/contribute.rst:75 -msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" +msgid "" +"Though not required to contribute, it may be useful to build this guide " +"locally in order to test your changes. In order to build this guide locally, " +"you'll need:" msgstr "" #: ../source/contribute.rst:79 -msgid "`Nox `_. You can install or upgrade nox using ``pip``::" +msgid "" +"`Nox `_. You can install or upgrade " +"nox using ``pip``::" msgstr "" #: ../source/contribute.rst:84 -msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." +msgid "" +"Python 3.6. Our build scripts are designed to work with Python 3.6 only. See " +"the `Hitchhiker's Guide to Python installation instructions`_ to install " +"Python 3.6 on your operating system." msgstr "" #: ../source/contribute.rst:91 -msgid "To build the guide, run the following bash command in the source folder::" +msgid "" +"To build the guide, run the following bash command in the source folder::" msgstr "" #: ../source/contribute.rst:95 -msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." +msgid "" +"After the process has completed you can find the HTML output in the ``./" +"build/html`` directory. You can open the ``index.html`` file to view the " +"guide in web browser, but it's recommended to serve the guide using an HTTP " +"server." msgstr "" #: ../source/contribute.rst:100 -msgid "You can build the guide and serve it via an HTTP server using the following command::" +msgid "" +"You can build the guide and serve it via an HTTP server using the following " +"command::" msgstr "" #: ../source/contribute.rst:105 @@ -136,7 +175,10 @@ msgid "Where the guide is deployed" msgstr "Куди це керівництво публікується" #: ../source/contribute.rst:111 -msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." +msgid "" +"The guide is deployed via ReadTheDocs and the configuration lives at https://" +"readthedocs.org/projects/python-packaging-user-guide/. It's served from a " +"custom domain and fronted by Fast.ly." msgstr "" #: ../source/contribute.rst:117 @@ -145,7 +187,11 @@ msgid "Style guide" msgstr "Керівництво по стилю" #: ../source/contribute.rst:119 -msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." +msgid "" +"This style guide has recommendations for how you should write the |PyPUG|. " +"Before you start writing, please review it. By following the style guide, " +"your contributions will help add to a cohesive whole and make it easier for " +"your contributions to be accepted into the project." msgstr "" #: ../source/contribute.rst:126 @@ -153,7 +199,9 @@ msgid "Purpose" msgstr "Призначення" #: ../source/contribute.rst:128 -msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." +msgid "" +"The purpose of the |PyPUG| is to be the authoritative resource on how to " +"package, publish, and install Python projects using current tools." msgstr "" #: ../source/contribute.rst:133 @@ -161,11 +209,18 @@ msgid "Scope" msgstr "" #: ../source/contribute.rst:135 -msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." +msgid "" +"The guide is meant to answer questions and solve problems with accurate and " +"focused recommendations." msgstr "" #: ../source/contribute.rst:138 -msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." +msgid "" +"The guide isn't meant to be comprehensive and it's not meant to replace " +"individual projects' documentation. For example, pip has dozens of commands, " +"options, and settings. The pip documentation describes each of them in " +"detail, while this guide describes only the parts of pip that are needed to " +"complete the specific tasks described in this guide." msgstr "" #: ../source/contribute.rst:146 @@ -178,11 +233,17 @@ msgid "The audience of this guide is anyone who uses Python with packages." msgstr "" #: ../source/contribute.rst:150 -msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." +msgid "" +"Don't forget that the Python community is big and welcoming. Readers may not " +"share your age, gender, education, culture, and more, but they deserve to " +"learn about packaging just as much as you do." msgstr "" #: ../source/contribute.rst:154 -msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." +msgid "" +"In particular, keep in mind that not all people who use Python see " +"themselves as programmers. The audience of this guide includes astronomers " +"or painters or students as well as professional software developers." msgstr "" #: ../source/contribute.rst:160 @@ -191,19 +252,35 @@ msgid "Voice and tone" msgstr "Вираження і тон" #: ../source/contribute.rst:162 -msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." +msgid "" +"When writing this guide, strive to write with a voice that's approachable " +"and humble, even if you have all the answers." msgstr "" #: ../source/contribute.rst:165 -msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." +msgid "" +"Imagine you're working on a Python project with someone you know to be smart " +"and skilled. You like working with them and they like working with you. That " +"person has asked you a question and you know the answer. How do you respond? " +"*That* is how you should write this guide." msgstr "" #: ../source/contribute.rst:170 -msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." +msgid "" +"Here's a quick check: try reading aloud to get a sense for your writing's " +"voice and tone. Does it sound like something you would say or does it sound " +"like you're acting out a part or giving a speech? Feel free to use " +"contractions and don't worry about sticking to fussy grammar rules. You are " +"hereby granted permission to end a sentence in a preposition, if that's what " +"you want to end it with." msgstr "" #: ../source/contribute.rst:177 -msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." +msgid "" +"When writing the guide, adjust your tone for the seriousness and difficulty " +"of the topic. If you're writing an introductory tutorial, it's OK to make a " +"joke, but if you're covering a sensitive security recommendation, you might " +"want to avoid jokes altogether." msgstr "" #: ../source/contribute.rst:184 @@ -217,7 +294,9 @@ msgid "**Write to the reader**" msgstr "**Пишіть читачеві**" #: ../source/contribute.rst:187 -msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." +msgid "" +"When giving recommendations or steps to take, address the reader as *you* or " +"use the imperative mood." msgstr "" #: ../source/contribute.rst:0 @@ -237,7 +316,11 @@ msgid "**State assumptions**" msgstr "**Оголошуйте припущення**" #: ../source/contribute.rst:195 -msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." +msgid "" +"Avoid making unstated assumptions. Reading on the web means that any page of " +"the guide may be the first page of the guide that the reader ever sees. If " +"you're going to make assumptions, then say what assumptions that you're " +"going to make." msgstr "" #: ../source/contribute.rst:203 @@ -245,7 +328,10 @@ msgid "**Cross-reference generously**" msgstr "**Щедро додавайте перехресні посилання**" #: ../source/contribute.rst:201 -msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." +msgid "" +"The first time you mention a tool or practice, link to the part of the guide " +"that covers it, or link to a relevant document elsewhere. Save the reader a " +"search." msgstr "" #: ../source/contribute.rst:213 @@ -253,7 +339,9 @@ msgid "**Respect naming practices**" msgstr "**Дотримуйтеся практик іменування**" #: ../source/contribute.rst:206 -msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." +msgid "" +"When naming tools, sites, people, and other proper nouns, use their " +"preferred capitalization." msgstr "" "Згадуючи інструменти, сайти, людей чи інші власні назви, використовуйте їх " "бажане написання великих літер." @@ -279,7 +367,10 @@ msgid "**Use a gender-neutral style**" msgstr "**Використовуйте ґендерно нейтральний стиль**" #: ../source/contribute.rst:216 -msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." +msgid "" +"Often, you'll address the reader directly with *you*, *your* and *yours*. " +"Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or " +"avoid pronouns entirely." msgstr "" #: ../source/contribute.rst:0 @@ -299,11 +390,17 @@ msgid "**Headings**" msgstr "**Заголовки**" #: ../source/contribute.rst:225 -msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." +msgid "" +"Write headings that use words the reader is searching for. A good way to do " +"this is to have your heading complete an implied question. For example, a " +"reader might want to know *How do I install MyLibrary?* so a good heading " +"might be *Install MyLibrary*." msgstr "" #: ../source/contribute.rst:230 -msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." +msgid "" +"In section headings, use sentence case. In other words, write headings as " +"you would write a typical sentence." msgstr "" #: ../source/contribute.rst:0 @@ -319,7 +416,9 @@ msgid "**Numbers**" msgstr "**Числа**" #: ../source/contribute.rst:237 -msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." +msgid "" +"In body text, write numbers one through nine as words. For other numbers or " +"numbers in tables, use numerals." msgstr "" #: ../source/discussions/deploying-python-applications.rst:4 @@ -366,8 +465,7 @@ msgstr "11.11.2014" #: ../source/guides/packaging-binary-extensions.rst:17 #: ../source/guides/supporting-multiple-python-versions.rst:12 #: ../source/guides/supporting-windows-using-appveyor.rst:15 -#: ../source/overview.rst:23 -#: ../source/specifications/core-metadata.rst:38 +#: ../source/overview.rst:23 ../source/specifications/core-metadata.rst:38 #: ../source/specifications/direct-url.rst:14 #: ../source/tutorials/installing-packages.rst:23 msgid "Contents" @@ -394,15 +492,29 @@ msgid "Pynsist" msgstr "" #: ../source/discussions/deploying-python-applications.rst:63 -msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." +msgid "" +"`Pynsist `__ is a tool that bundles Python " +"programs together with the Python-interpreter into a single installer based " +"on NSIS. In most cases, packaging only requires the user to choose a version " +"of the Python-interpreter and declare the dependencies of the program. The " +"tool downloads the specified Python-interpreter for Windows and packages it " +"with all the dependencies in a single Windows-executable installer." msgstr "" #: ../source/discussions/deploying-python-applications.rst:70 -msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." +msgid "" +"The installed program can be started from a shortcut that the installer adds " +"to the start-menu. It uses a Python interpreter installed within its " +"application directory, independent of any other Python installation on the " +"computer." msgstr "" #: ../source/discussions/deploying-python-applications.rst:74 -msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." +msgid "" +"A big advantage of Pynsist is that the Windows packages can be built on " +"Linux. There are several examples for different kinds of programs (console, " +"GUI) in the `documentation `__. The tool is " +"released under the MIT-licence." msgstr "" #: ../source/discussions/deploying-python-applications.rst:80 @@ -414,7 +526,10 @@ msgid "Configuration management" msgstr "Управління конфігурацією" #: ../source/discussions/index.rst:4 -msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." +msgid "" +"**Discussions** are focused on providing comprehensive information about a " +"specific topic. If you're just trying to get stuff done, see :doc:`/guides/" +"index`." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:5 @@ -427,31 +542,52 @@ msgid "install_requires" msgstr "install_requires" #: ../source/discussions/install-requires-vs-requirements.rst:14 -msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgid "" +"``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that " +"should be used to specify what a project **minimally** needs to run " +"correctly. When the project is installed by :ref:`pip`, this is the " +"specification that is used to install its dependencies." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:19 -msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" +msgid "" +"For example, if the project requires A and B, your ``install_requires`` " +"would be like so:" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:29 -msgid "Additionally, it's best practice to indicate any known lower or upper bounds." +msgid "" +"Additionally, it's best practice to indicate any known lower or upper bounds." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:31 -msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" +msgid "" +"For example, it may be known, that your project requires at least v1 of 'A', " +"and v2 of 'B', so it would be like so:" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:41 -msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" +msgid "" +"It may also be known that project A follows semantic versioning, and that v2 " +"of 'A' will indicate a break in compatibility, so it makes sense to not " +"allow v2:" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:51 -msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." +msgid "" +"It is not considered best practice to use ``install_requires`` to pin " +"dependencies to specific versions, or to specify sub-dependencies (i.e. " +"dependencies of your dependencies). This is overly-restrictive, and " +"prevents the user from gaining the benefit of dependency upgrades." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:56 -msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" +msgid "" +"Lastly, it's important to understand that ``install_requires`` is a listing " +"of \"Abstract\" requirements, i.e just names and version restrictions that " +"don't determine where the dependencies will be fulfilled from (i.e. from " +"what index or source). The where (i.e. how they are to be made \"Concrete" +"\") is to be determined at install time using :ref:`pip` options. [1]_" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:64 @@ -460,27 +596,46 @@ msgid "Requirements files" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:66 -msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." +msgid "" +":ref:`Requirements Files ` described most simply, " +"are just a list of :ref:`pip:pip install` arguments placed into a file." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:69 -msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." +msgid "" +"Whereas ``install_requires`` defines the dependencies for a single project, :" +"ref:`Requirements Files ` are often used to define " +"the requirements for a complete Python environment." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:73 -msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." +msgid "" +"Whereas ``install_requires`` requirements are minimal, requirements files " +"often contain an exhaustive listing of pinned versions for the purpose of " +"achieving :ref:`repeatable installations ` of a complete " +"environment." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:78 -msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" +msgid "" +"Whereas ``install_requires`` requirements are \"Abstract\", i.e. not " +"associated with any particular index, requirements files often contain pip " +"options like ``--index-url`` or ``--find-links`` to make requirements " +"\"Concrete\", i.e. associated with a particular index or directory of " +"packages. [1]_" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:84 -msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." +msgid "" +"Whereas ``install_requires`` metadata is automatically analyzed by pip " +"during an install, requirements files are not, and only are used when a user " +"specifically installs them using ``python -m pip install -r``." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:90 -msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." +msgid "" +"For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad." +"io/2013/07/setup-vs-requirement/." msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:6 @@ -488,15 +643,29 @@ msgid "pip vs easy_install" msgstr "pip проти easy_install" #: ../source/discussions/pip-vs-easy-install.rst:9 -msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." +msgid "" +":ref:`easy_install `, now `deprecated`_, was released in 2004 " +"as part of :ref:`setuptools`. It was notable at the time for installing :" +"term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing " +"dependencies." msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:14 -msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." +msgid "" +":ref:`pip` came later in 2008, as alternative to :ref:`easy_install " +"`, although still largely built on top of :ref:`setuptools` " +"components. It was notable at the time for *not* installing packages as :" +"term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' " +"packages from :term:`sdists `), and " +"introducing the idea of :ref:`Requirements Files `, " +"which gave users the power to easily replicate environments." msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:22 -msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" +msgid "" +"Here's a breakdown of the important differences between pip and the " +"deprecated easy_install:" msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:25 @@ -610,7 +779,9 @@ msgid "Yes, via setup.cfg" msgstr "Так, через setup.cfg" #: ../source/discussions/pip-vs-easy-install.rst:68 -msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" +msgid "" +"https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" +"launcher" msgstr "" #: ../source/discussions/wheel-vs-egg.rst:5 @@ -618,19 +789,28 @@ msgid "Wheel vs Egg" msgstr "Wheel чи Egg" #: ../source/discussions/wheel-vs-egg.rst:7 -msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." +msgid "" +":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support " +"the use case of needing an install artifact that doesn't require building or " +"compilation, which can be costly in testing and production workflows." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:11 -msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." +msgid "" +"The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas " +"the :term:`Wheel` format was introduced by :pep:`427` in 2012." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:14 -msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." +msgid "" +":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:17 -msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." +msgid "" +"Here's a breakdown of the important differences between :term:`Wheel` and :" +"term:`Egg`." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:20 @@ -638,31 +818,53 @@ msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:22 -msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." +msgid "" +":term:`Wheel` is a :term:`distribution ` format, i.e a " +"packaging format. [1]_ :term:`Egg` was both a distribution format and a " +"runtime installation format (if left zipped), and was designed to be " +"importable." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:26 -msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." +msgid "" +":term:`Wheel` archives do not include .pyc files. Therefore, when the " +"distribution only contains Python files (i.e. no compiled extensions), and " +"is compatible with Python 2 and 3, it's possible for a wheel to be " +"\"universal\", similar to an :term:`sdist `." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:31 -msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." +msgid "" +":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. " +"Egg used ``.egg-info``." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:34 -msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." +msgid "" +":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single " +"wheel archive can indicate its compatibility with a number of Python " +"language versions and implementations, ABIs, and system architectures." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:38 -msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." +msgid "" +":term:`Wheel` is versioned. Every wheel file contains the version of the " +"wheel specification and the implementation that packaged it." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:41 -msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." +msgid "" +":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making " +"it easier to convert to other formats." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:47 -msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." +msgid "" +"Circumstantially, in some cases, wheels can be used as an importable runtime " +"format, although :pep:`this is not officially supported at this time <427#is-" +"it-possible-to-import-python-code-directly-from-a-wheel-file>`." msgstr "" #: ../source/glossary.rst:3 @@ -674,7 +876,9 @@ msgid "Binary Distribution" msgstr "" #: ../source/glossary.rst:11 -msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." +msgid "" +"A specific kind of :term:`Built Distribution` that contains compiled " +"extensions." msgstr "" #: ../source/glossary.rst:14 @@ -682,7 +886,14 @@ msgid "Built Distribution" msgstr "" #: ../source/glossary.rst:17 -msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." +msgid "" +"A :term:`Distribution ` format containing files and " +"metadata that only need to be moved to the correct location on the target " +"system, to be installed. :term:`Wheel` is such a format, whereas distutil's :" +"term:`Source Distribution ` is not, in " +"that it requires a build step before it can be installed. This format does " +"not imply that Python files have to be precompiled (:term:`Wheel` " +"intentionally does not include compiled Python files)." msgstr "" #: ../source/glossary.rst:26 @@ -690,11 +901,22 @@ msgid "Distribution Package" msgstr "" #: ../source/glossary.rst:29 -msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." +msgid "" +"A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used " +"to distribute a :term:`Release`. The archive file is what an end-user will " +"download from the internet and install." msgstr "" #: ../source/glossary.rst:34 -msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." +msgid "" +"A distribution package is more commonly referred to with the single words " +"\"package\" or \"distribution\", but this guide may use the expanded term " +"when more clarity is needed to prevent confusion with an :term:`Import " +"Package` (which is also commonly called a \"package\") or another kind of " +"distribution (e.g. a Linux distribution or the Python language " +"distribution), which are often referred to with the single term " +"\"distribution\"." msgstr "" #: ../source/glossary.rst:41 @@ -702,7 +924,12 @@ msgid "Egg" msgstr "" #: ../source/glossary.rst:44 -msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" +msgid "" +"A :term:`Built Distribution` format introduced by :ref:`setuptools`, which " +"is being replaced by :term:`Wheel`. For details, see `The Internal " +"Structure of Python Eggs `_ and `Python Eggs `_" msgstr "" #: ../source/glossary.rst:49 @@ -710,7 +937,12 @@ msgid "Extension Module" msgstr "" #: ../source/glossary.rst:52 -msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." +msgid "" +"A :term:`Module` written in the low-level language of the Python " +"implementation: C/C++ for Python, Java for Jython. Typically contained in a " +"single dynamically loadable pre-compiled file, e.g. a shared object (.so) " +"file for Python extensions on Unix, a DLL (given the .pyd extension) for " +"Python extensions on Windows, or a Java class file for Jython extensions." msgstr "" #: ../source/glossary.rst:59 @@ -718,7 +950,12 @@ msgid "Known Good Set (KGS)" msgstr "" #: ../source/glossary.rst:62 -msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." +msgid "" +"A set of distributions at specified versions which are compatible with each " +"other. Typically a test suite will be run which passes all tests before a " +"specific set of packages is declared a known good set. This term is commonly " +"used by frameworks and toolkits which are comprised of multiple individual " +"distributions." msgstr "" #: ../source/glossary.rst:68 @@ -726,11 +963,17 @@ msgid "Import Package" msgstr "" #: ../source/glossary.rst:71 -msgid "A Python module which can contain other modules or recursively, other packages." +msgid "" +"A Python module which can contain other modules or recursively, other " +"packages." msgstr "" #: ../source/glossary.rst:74 -msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." +msgid "" +"An import package is more commonly referred to with the single word \"package" +"\", but this guide will use the expanded term when more clarity is needed to " +"prevent confusion with a :term:`Distribution Package` which is also commonly " +"called a \"package\"." msgstr "" #: ../source/glossary.rst:78 @@ -738,7 +981,9 @@ msgid "Module" msgstr "Модуль" #: ../source/glossary.rst:81 -msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." +msgid "" +"The basic unit of code reusability in Python, existing in one of two types: :" +"term:`Pure Module`, or :term:`Extension Module`." msgstr "" #: ../source/glossary.rst:84 @@ -746,7 +991,9 @@ msgid "Package Index" msgstr "" #: ../source/glossary.rst:87 -msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." +msgid "" +"A repository of distributions with a web interface to automate :term:" +"`package ` discovery and consumption." msgstr "" #: ../source/glossary.rst:90 @@ -754,7 +1001,10 @@ msgid "Per Project Index" msgstr "" #: ../source/glossary.rst:93 -msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." +msgid "" +"A private or other non-canonical :term:`Package Index` indicated by a " +"specific :term:`Project` as the index preferred or required to resolve " +"dependencies of that project." msgstr "" #: ../source/glossary.rst:97 @@ -762,19 +1012,35 @@ msgid "Project" msgstr "Проект" #: ../source/glossary.rst:100 -msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." +msgid "" +"A library, framework, script, plugin, application, or collection of data or " +"other resources, or some combination thereof that is intended to be packaged " +"into a :term:`Distribution `." msgstr "" #: ../source/glossary.rst:104 -msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." +msgid "" +"Since most projects create :term:`Distributions ` " +"using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:" +"`setuptools`, another practical way to define projects currently is " +"something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:" +"`setup.cfg` file at the root of the project source directory." msgstr "" #: ../source/glossary.rst:110 -msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." +msgid "" +"Python projects must have unique names, which are registered on :term:`PyPI " +"`. Each project will then contain one or more :" +"term:`Releases `, and each release may comprise one or more :term:" +"`distributions `." msgstr "" #: ../source/glossary.rst:115 -msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." +msgid "" +"Note that there is a strong convention to name a project after the name of " +"the package that is imported to run that project. However, this doesn't have " +"to hold true. It's possible to install a distribution from the project 'foo' " +"and have it provide a package importable only as 'bar'." msgstr "" #: ../source/glossary.rst:121 @@ -782,7 +1048,9 @@ msgid "Pure Module" msgstr "" #: ../source/glossary.rst:124 -msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." +msgid "" +"A :term:`Module` written in Python and contained in a single ``.py`` file " +"(and possibly associated ``.pyc`` and/or ``.pyo`` files)." msgstr "" #: ../source/glossary.rst:127 @@ -790,7 +1058,13 @@ msgid "Python Packaging Authority (PyPA)" msgstr "Управління з пакування Python (PyPA)" #: ../source/glossary.rst:130 -msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." +msgid "" +"PyPA is a working group that maintains many of the relevant projects in " +"Python packaging. They maintain a site at https://www.pypa.io, host projects " +"on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python " +"Discourse forum `__." msgstr "" #: ../source/glossary.rst:139 @@ -798,7 +1072,10 @@ msgid "Python Package Index (PyPI)" msgstr "Реєстр Python-пакунків (PyPI)" #: ../source/glossary.rst:142 -msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." +msgid "" +"`PyPI `_ is the default :term:`Package Index` for the " +"Python community. It is open to all Python developers to consume and " +"distribute their distributions." msgstr "" #: ../source/glossary.rst:145 @@ -806,7 +1083,10 @@ msgid "pypi.org" msgstr "pypi.org" #: ../source/glossary.rst:148 -msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." +msgid "" +"`pypi.org `_ is the domain name for the :term:`Python " +"Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi." +"python.org``, in 2017. It is powered by :ref:`warehouse`." msgstr "" #: ../source/glossary.rst:152 @@ -814,7 +1094,8 @@ msgid "pyproject.toml" msgstr "pyproject.toml" #: ../source/glossary.rst:155 -msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." +msgid "" +"The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." msgstr "" #: ../source/glossary.rst:157 @@ -822,11 +1103,17 @@ msgid "Release" msgstr "Випуск" #: ../source/glossary.rst:160 -msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." +msgid "" +"A snapshot of a :term:`Project` at a particular point in time, denoted by a " +"version identifier." msgstr "" #: ../source/glossary.rst:163 -msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." +msgid "" +"Making a release may entail the publishing of multiple :term:`Distributions " +"`. For example, if version 1.0 of a project was " +"released, it could be available in both a source distribution format and a " +"Windows installer distribution format." msgstr "" #: ../source/glossary.rst:168 @@ -834,7 +1121,12 @@ msgid "Requirement" msgstr "" #: ../source/glossary.rst:171 -msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." +msgid "" +"A specification for a :term:`package ` to be " +"installed. :ref:`pip`, the :term:`PYPA ` " +"recommended installer, allows various forms of specification that can all be " +"considered a \"requirement\". For more information, see the :ref:`pip:pip " +"install` reference." msgstr "" #: ../source/glossary.rst:177 @@ -842,7 +1134,13 @@ msgid "Requirement Specifier" msgstr "" #: ../source/glossary.rst:180 -msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" +msgid "" +"A format used by :ref:`pip` to install packages from a :term:`Package " +"Index`. For an EBNF diagram of the format, see the `pkg_resources." +"Requirement `_ entry in the :ref:`setuptools` docs. For " +"example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the " +"project name, and the \">=1.3\" portion is the :term:`Version Specifier`" msgstr "" #: ../source/glossary.rst:187 @@ -850,7 +1148,10 @@ msgid "Requirements File" msgstr "" #: ../source/glossary.rst:190 -msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." +msgid "" +"A file containing a list of :term:`Requirements ` that can be " +"installed using :ref:`pip`. For more information, see the :ref:`pip` docs " +"on :ref:`pip:Requirements Files`." msgstr "" #: ../source/glossary.rst:194 @@ -864,7 +1165,9 @@ msgid "setup.cfg" msgstr "setup.cfg" #: ../source/glossary.rst:198 -msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." +msgid "" +"The project specification files for :ref:`distutils` and :ref:`setuptools`. " +"See also :term:`pyproject.toml`." msgstr "" #: ../source/glossary.rst:201 @@ -872,7 +1175,10 @@ msgid "Source Archive" msgstr "" #: ../source/glossary.rst:204 -msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." +msgid "" +"An archive containing the raw source code for a :term:`Release`, prior to " +"creation of a :term:`Source Distribution ` or :term:`Built Distribution`." msgstr "" #: ../source/glossary.rst:208 @@ -880,7 +1186,11 @@ msgid "Source Distribution (or \"sdist\")" msgstr "" #: ../source/glossary.rst:211 -msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." +msgid "" +"A :term:`distribution ` format (usually generated " +"using ``python setup.py sdist``) that provides metadata and the essential " +"source files needed for installing by a tool like :ref:`pip`, or for " +"generating a :term:`Built Distribution`." msgstr "" #: ../source/glossary.rst:216 @@ -888,7 +1198,9 @@ msgid "System Package" msgstr "" #: ../source/glossary.rst:219 -msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." +msgid "" +"A package provided in a format native to the operating system, e.g. an rpm " +"or dpkg file." msgstr "" #: ../source/glossary.rst:222 @@ -896,7 +1208,12 @@ msgid "Version Specifier" msgstr "" #: ../source/glossary.rst:225 -msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." +msgid "" +"The version component of a :term:`Requirement Specifier`. For example, the " +"\">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full " +"specification <440#version-specifiers>` of the specifiers that Python " +"packaging currently supports. Support for PEP440 was implemented in :ref:" +"`setuptools` v8.0 and :ref:`pip` v6.0." msgstr "" #: ../source/glossary.rst:231 @@ -904,7 +1221,11 @@ msgid "Virtual Environment" msgstr "" #: ../source/glossary.rst:234 -msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgid "" +"An isolated Python environment that allows packages to be installed for use " +"by a particular application, rather than being installed system wide. For " +"more information, see the section on :ref:`Creating and using Virtual " +"Environments`." msgstr "" #: ../source/glossary.rst:238 @@ -912,7 +1233,10 @@ msgid "Wheel" msgstr "" #: ../source/glossary.rst:241 -msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." +msgid "" +"A :term:`Built Distribution` format introduced by :pep:`427`, which is " +"intended to replace the :term:`Egg` format. Wheel is currently supported " +"by :ref:`pip`." msgstr "" #: ../source/glossary.rst:244 @@ -920,7 +1244,11 @@ msgid "Working Set" msgstr "" #: ../source/glossary.rst:247 -msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." +msgid "" +"A collection of :term:`distributions ` available for " +"importing. These are the distributions that are on the `sys.path` variable. " +"At most, one :term:`Distribution ` for a project is " +"possible in a working set." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:3 @@ -928,7 +1256,11 @@ msgid "Analyzing PyPI package downloads" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:5 -msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." +msgid "" +"This section covers how to use the public PyPI download statistics dataset " +"to learn more about downloads of a package (or packages) hosted on PyPI. For " +"example, you can use it to discover the distribution of Python versions used " +"to download a package." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:15 @@ -941,11 +1273,17 @@ msgid "PyPI does not display download statistics for a number of reasons: [#]_" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:19 -msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." +msgid "" +"**Inefficient to make work with a Content Distribution Network (CDN):** " +"Download statistics change constantly. Including them in project pages, " +"which are heavily cached, would require invalidating the cache more often, " +"and reduce the overall effectiveness of the cache." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:24 -msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" +msgid "" +"**Highly inaccurate:** A number of things prevent the download counts from " +"being accurate, some of which include:" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:27 @@ -953,7 +1291,8 @@ msgid "``pip``'s download cache (lowers download counts)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:28 -msgid "Internal or unofficial mirrors (can both raise or lower download counts)" +msgid "" +"Internal or unofficial mirrors (can both raise or lower download counts)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:29 @@ -961,7 +1300,9 @@ msgid "Packages not hosted on PyPI (for comparisons sake)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:30 -msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" +msgid "" +"Unofficial scripts or attempts at download count inflation (raises download " +"counts)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:32 @@ -969,11 +1310,17 @@ msgid "Known historical data quality issues (lowers download counts)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:34 -msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" +msgid "" +"**Not particularly useful:** Just because a project has been downloaded a " +"lot doesn't mean it's good; Similarly just because a project hasn't been " +"downloaded a lot doesn't mean it's bad!" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:38 -msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." +msgid "" +"In short, because it's value is low for various reasons, and the tradeoffs " +"required to make it work are high, it has been not an effective use of " +"limited resources." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:43 @@ -981,7 +1328,10 @@ msgid "Public dataset" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:45 -msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." +msgid "" +"As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, " +"where they are stored as a public dataset." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:50 @@ -989,7 +1339,13 @@ msgid "Getting set up" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:52 -msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" +msgid "" +"In order to use `Google BigQuery`_ to query the `public PyPI download " +"statistics dataset`_, you'll need a Google account and to enable the " +"BigQuery API on a Google Cloud Platform project. You can run the up to 1TB " +"of queries per month `using the BigQuery free tier without a credit card " +"`__" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:58 @@ -1001,11 +1357,16 @@ msgid "Create a new project." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:60 -msgid "Enable the `BigQuery API `__." +msgid "" +"Enable the `BigQuery API `__." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:63 -msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." +msgid "" +"For more detailed instructions on how to get started with BigQuery, check " +"out the `BigQuery quickstart guide `__." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:69 @@ -1013,7 +1374,12 @@ msgid "Data schema" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:71 -msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" +msgid "" +"Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` " +"table for each download. The table contains information about what file was " +"downloaded and how it was downloaded. Some useful columns from the `table " +"schema `__ include:" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 @@ -1096,11 +1462,16 @@ msgid "Useful queries" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:95 -msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." +msgid "" +"Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" " +"button." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:97 -msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." +msgid "" +"Note that the rows are stored in a partitioned, which helps limit the cost " +"of queries. These example queries analyze downloads from recent history by " +"filtering on the ``timestamp`` column." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:102 @@ -1108,7 +1479,9 @@ msgid "Counting package downloads" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:104 -msgid "The following query counts the total number of downloads for the project \"pytest\"." +msgid "" +"The following query counts the total number of downloads for the project " +"\"pytest\"." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:119 @@ -1123,7 +1496,9 @@ msgid "26190085" msgstr "26190085" #: ../source/guides/analyzing-pypi-package-downloads.rst:124 -msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." +msgid "" +"To only count downloads from pip, filter on the ``details.installer.name`` " +"column." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:142 @@ -1135,7 +1510,9 @@ msgid "Package downloads over time" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:148 -msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." +msgid "" +"To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also " +"filtering by this column reduces corresponding costs." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:168 @@ -1195,7 +1572,9 @@ msgid "Python versions over time" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:186 -msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." +msgid "" +"Extract the Python version from the ``details.python`` column. Warning: This " +"query processes over 500 GB of data." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:205 @@ -1255,7 +1634,12 @@ msgid "Caveats" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:223 -msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." +msgid "" +"In addition to the caveats listed in the background above, Linehaul suffered " +"from a bug which caused it to significantly under-report download statistics " +"prior to July 26, 2018. Downloads before this date are proportionally " +"accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total " +"numbers are lower than actual by an order of magnitude." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:231 @@ -1263,7 +1647,9 @@ msgid "Additional tools" msgstr "Додаткові інструменти" #: ../source/guides/analyzing-pypi-package-downloads.rst:233 -msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." +msgid "" +"Besides using the BigQuery console, there are some additional tools which " +"may be useful when analyzing download statistics." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:237 @@ -1271,7 +1657,10 @@ msgid "``google-cloud-bigquery``" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:239 -msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." +msgid "" +"You can also access the public PyPI download statistics dataset " +"programmatically via the BigQuery API and the `google-cloud-bigquery`_ " +"project, the official Python client library for BigQuery." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:267 @@ -1279,7 +1668,10 @@ msgid "``pypinfo``" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:269 -msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." +msgid "" +"`pypinfo`_ is a command-line tool which provides access to the dataset and " +"can generate several useful queries. For example, you can query the total " +"number of download for a package with the command ``pypinfo package_name``." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:273 @@ -1295,7 +1687,8 @@ msgid "``pandas-gbq``" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:297 -msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." +msgid "" +"The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:301 @@ -1304,11 +1697,15 @@ msgid "References" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:303 -msgid "`PyPI Download Counts deprecation email `__" +msgid "" +"`PyPI Download Counts deprecation email `__" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:304 -msgid "`PyPI BigQuery dataset announcement email `__" +msgid "" +"`PyPI BigQuery dataset announcement email `__" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:3 @@ -1316,7 +1713,11 @@ msgid "Creating and discovering plugins" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:5 -msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." +msgid "" +"Often when creating a Python application or library you'll want the ability " +"to provide customizations or extra features via **plugins**. Because Python " +"packages can be separately distributed, your application or library may want " +"to automatically **discover** all of the plugins available." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:10 @@ -1340,15 +1741,25 @@ msgid "Using naming convention" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:20 -msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" +msgid "" +"If all of the plugins for your application follow the same naming " +"convention, you can use :func:`pkgutil.iter_modules` to discover all of the " +"top-level modules that match the naming convention. For example, `Flask`_ " +"uses the naming convention ``flask_{plugin_name}``. If you wanted to " +"automatically discover all of the Flask plugins installed:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:38 -msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" +msgid "" +"If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins " +"installed then ``discovered_plugins`` would be:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:48 -msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." +msgid "" +"Using naming convention for plugins also allows you to query the Python " +"Package Index's `simple API`_ for all packages that conform to your naming " +"convention." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:59 @@ -1356,19 +1767,48 @@ msgid "Using namespace packages" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:61 -msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" +msgid "" +":doc:`Namespace packages ` can be used to " +"provide a convention for where to place plugins and also provides a way to " +"perform discovery. For example, if you make the sub-package ``myapp." +"plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once " +"installed, you can use :func:`pkgutil.iter_modules` to discover all modules " +"and packages installed under that namespace:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:89 -msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" +msgid "" +"Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` " +"causes it to only look for the modules directly under that namespace. For " +"example, if you have installed distributions that provide the modules " +"``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in " +"this case would be:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:101 -msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." +msgid "" +"This sample uses a sub-package as the namespace package (``myapp.plugins``), " +"but it's also possible to use a top-level package for this purpose (such as " +"``myapp_plugins``). How to pick the namespace to use is a matter of " +"preference, but it's not recommended to make your project's main top-level " +"package (``myapp`` in this case) a namespace package for the purpose of " +"plugins, as one bad plugin could cause the entire namespace to break which " +"would in turn make your project unimportable. For the \"namespace sub-package" +"\" approach to work, the plugin packages must omit the :file:`__init__.py` " +"for your top-level package directory (``myapp`` in this case) and include " +"the namespace-package style :file:`__init__.py` in the namespace sub-package " +"directory (``myapp/plugins``). This also means that plugins will need to " +"explicitly pass a list of packages to :func:`setup`'s ``packages`` argument " +"instead of using :func:`setuptools.find_packages`." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:115 -msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." +msgid "" +"Namespace packages are a complex feature and there are several different " +"ways to create them. It's highly recommended to read the :doc:`packaging-" +"namespace-packages` documentation and clearly document which approach is " +"preferred for plugins to your project." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:121 @@ -1376,31 +1816,50 @@ msgid "Using package metadata" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:123 -msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." +msgid "" +"`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :" +"func:`setup` in :file:`setup.py` plugins can register themselves for " +"discovery." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:128 -msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" +msgid "" +"For example if you have a package named ``myapp-plugin-a`` and it includes " +"in its :file:`setup.py`:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:139 -msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" +msgid "" +"Then you can discover and load all of the registered entry points by using :" +"func:`importlib.metadata.entry_points` (or the `backport`_ " +"``importlib_metadata >= 3.6`` for Python 3.6-3.9):" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:154 -msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" +msgid "" +"In this example, ``discovered_plugins`` would be a collection of type :class:" +"`importlib.metadata.EntryPoint`:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:163 -msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." +msgid "" +"Now the module of your choice can be imported by executing " +"``discovered_plugins['a'].load()``." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:166 -msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." +msgid "" +"The ``entry_point`` specification in :file:`setup.py` is fairly flexible and " +"has a lot of options. It's recommended to read over the entire section on :" +"doc:`entry points ` ." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:170 -msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." +msgid "" +"Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools " +"provide support for defining entry points." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:5 @@ -1408,15 +1867,25 @@ msgid "Packaging and distributing projects" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:7 -msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." +msgid "" +"This section covers the basics of how to configure, package and distribute " +"your own Python projects. It assumes that you are already familiar with the " +"contents of the :doc:`/tutorials/installing-packages` page." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:11 -msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." +msgid "" +"The section does *not* aim to cover best practices for Python project " +"development as a whole. For example, it does not provide guidance or tool " +"recommendations for version control, documentation, or testing." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:15 -msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." +msgid "" +"For more reference material, see :std:doc:`Building and Distributing " +"Packages ` in the :ref:`setuptools` docs, but note that " +"some advisory content there may be outdated. In the event of conflicts, " +"prefer the advice in the Python Packaging User Guide." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:25 @@ -1424,7 +1893,9 @@ msgid "Requirements for packaging and distributing" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:26 -msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." +msgid "" +"First, make sure you have already fulfilled the :ref:`requirements for " +"installing packages `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:29 @@ -1432,7 +1903,10 @@ msgid "Install \"twine\" [1]_:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:43 -msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." +msgid "" +"You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below " +"`)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:49 @@ -1444,7 +1918,11 @@ msgid "Initial files" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:58 -msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." +msgid "" +"The most important file is :file:`setup.py` which exists at the root of your " +"project directory. For an example, see the `setup.py `_ in the `PyPA sample project " +"`_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:63 @@ -1452,15 +1930,27 @@ msgid ":file:`setup.py` serves two primary functions:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:65 -msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." +msgid "" +"It's the file where various aspects of your project are configured. The " +"primary feature of :file:`setup.py` is that it contains a global ``setup()`` " +"function. The keyword arguments to this function are how specific details " +"of your project are defined. The most relevant arguments are explained in :" +"ref:`the section below `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:71 -msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." +msgid "" +"It's the command line interface for running various commands that relate to " +"packaging tasks. To get a listing of available commands, run ``python setup." +"py --help-commands``." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:79 -msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." +msgid "" +":file:`setup.cfg` is an ini file that contains option defaults for :file:" +"`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project " +"`_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:86 @@ -1468,15 +1958,31 @@ msgid "README.rst / README.md" msgstr "README.rst / README.md" #: ../source/guides/distributing-packages-using-setuptools.rst:88 -msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." +msgid "" +"All projects should contain a readme file that covers the goal of the " +"project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not " +"a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:" +"`long_description_content_type ` argument)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:95 -msgid "For an example, see `README.md `_ from the `PyPA sample project `_." +msgid "" +"For an example, see `README.md `_ from the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:99 -msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." +msgid "" +"Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:" +"`README.rst`, :file:`README.txt`, or :file:`README`) included in source " +"distributions by default. The built-in :ref:`distutils` library adopts this " +"behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ " +"will include a :file:`README.md` if found. If you are using setuptools, you " +"don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, " +"include it to be explicit." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:108 @@ -1484,15 +1990,23 @@ msgid "MANIFEST.in" msgstr "MANIFEST.in" #: ../source/guides/distributing-packages-using-setuptools.rst:110 -msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." +msgid "" +"A :file:`MANIFEST.in` is needed when you need to package additional files " +"that are not automatically included in a source distribution. For details " +"on writing a :file:`MANIFEST.in` file, including a list of what's included " +"by default, see \":ref:`Using MANIFEST.in`\"." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:115 -msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." +msgid "" +"For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:119 -msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." +msgid "" +":file:`MANIFEST.in` does not affect binary distributions such as wheels." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:122 @@ -1500,11 +2014,20 @@ msgid "LICENSE.txt" msgstr "LICENSE.txt" #: ../source/guides/distributing-packages-using-setuptools.rst:124 -msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." +msgid "" +"Every package should include a license file detailing the terms of " +"distribution. In many jurisdictions, packages without an explicit license " +"can not be legally used or distributed by anyone other than the copyright " +"holder. If you're unsure which license to choose, you can use resources such " +"as `GitHub's Choose a License `_ or consult a " +"lawyer." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:130 -msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." +msgid "" +"For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:135 @@ -1512,11 +2035,17 @@ msgid "" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:137 -msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." +msgid "" +"Although it's not required, the most common practice is to include your " +"Python modules and packages under a single top-level package that has the " +"same :ref:`name ` as your project, or something very close." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:141 -msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." +msgid "" +"For an example, see the `sample `_ package that's included in the `PyPA sample project " +"`_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:149 @@ -1524,11 +2053,18 @@ msgid "setup() args" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:151 -msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." +msgid "" +"As mentioned above, the primary feature of :file:`setup.py` is that it " +"contains a global ``setup()`` function. The keyword arguments to this " +"function are how specific details of your project are defined." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:155 -msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." +msgid "" +"The most relevant arguments are explained below. Most of the snippets given " +"are taken from the `setup.py `_ contained in the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:164 @@ -1536,11 +2072,16 @@ msgid "name" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:170 -msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" +msgid "" +"This is the name of your project, determining how your project is listed on :" +"term:`PyPI `. Per :pep:`508`, valid project " +"names must:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:174 -msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" +msgid "" +"Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), " +"and/or periods (``.``), and" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:176 @@ -1548,7 +2089,11 @@ msgid "Start & end with an ASCII letter or digit." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:178 -msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" +msgid "" +"Comparison of project names is case insensitive and treats arbitrarily-long " +"runs of underscores, hyphens, and/or periods as equal. For example, if you " +"register a project named ``cool-stuff``, users will be able to download it " +"or declare a dependency on it using any of the following spellings::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:190 @@ -1557,19 +2102,30 @@ msgid "version" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:196 -msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." +msgid "" +"This is the current version of your project, allowing your users to " +"determine whether or not they have the latest version, and to indicate which " +"specific versions they've tested their own software against." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:200 -msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." +msgid "" +"Versions are displayed on :term:`PyPI ` for " +"each release if you publish your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:203 -msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." +msgid "" +"See :ref:`Choosing a versioning scheme` for more information on ways to use " +"versions to convey compatibility information to your users." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:206 -msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." +msgid "" +"If the project code itself needs run-time access to the version, the " +"simplest way is to keep the version in both :file:`setup.py` and your code. " +"If you'd rather not duplicate the value, there are a few ways to manage " +"this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:214 @@ -1581,15 +2137,32 @@ msgid "Give a short and long description for your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:224 -msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." +msgid "" +"These values will be displayed on :term:`PyPI ` " +"if you publish your project. On ``pypi.org``, the user interface displays " +"``description`` in the grey banner and ``long_description`` in the section " +"named \"Project Description\"." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:229 -msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." +msgid "" +"``description`` is also displayed in lists of projects. For example, it's " +"visible in the search results pages such as https://pypi.org/search/?" +"q=jupyter, the front-page lists of trending projects and new releases, and " +"the list of projects you maintain within your account profile (such as " +"https://pypi.org/user/jaraco/)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:235 -msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." +msgid "" +"A `content type `_ can be specified with the " +"``long_description_content_type`` argument, which can be one of ``text/" +"plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no " +"formatting, `reStructuredText (reST) `_, and the Github-flavored " +"Markdown dialect of `Markdown `_ respectively." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:245 @@ -1613,11 +2186,21 @@ msgid "license" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:273 -msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." +msgid "" +"The ``license`` argument doesn't have to indicate the license under which " +"your package is being released, although you may optionally do so if you " +"want. If you're using a standard, well-known license, then your main " +"indication can and should be via the ``classifiers`` argument. Classifiers " +"exist for all major open-source licenses." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:279 -msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." +msgid "" +"The \"license\" argument is more typically used to indicate differences from " +"well-known licenses, or to include your own, unique license. As a general " +"rule, it's a good idea to use a standard, well-known license, both to avoid " +"confusion and because some organizations avoid software whose license is " +"unapproved." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:287 @@ -1625,11 +2208,18 @@ msgid "classifiers" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:316 -msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." +msgid "" +"Provide a list of classifiers that categorize your project. For a full " +"listing, see https://pypi.org/classifiers/." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:319 -msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." +msgid "" +"Although the list of classifiers is often used to declare what Python " +"versions a project supports, this information is only used for searching & " +"browsing projects on PyPI, not for installing projects. To actually " +"restrict what Python versions a project can be installed on, use the :ref:" +"`python_requires` argument." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:327 @@ -1645,7 +2235,11 @@ msgid "project_urls" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:349 -msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." +msgid "" +"List additional relevant URLs about your project. This is the place to link " +"to bug trackers, source repositories, or where to support package " +"development. The string of the key is the exact text that will be displayed " +"on PyPI." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:355 @@ -1653,7 +2247,13 @@ msgid "packages" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:361 -msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." +msgid "" +"Set ``packages`` to a list of all :term:`packages ` in your " +"project, including their subpackages, sub-subpackages, etc. Although the " +"packages can be listed manually, ``setuptools.find_packages()`` finds them " +"automatically. Use the ``include`` keyword argument to find only the given " +"packages. Use the ``exclude`` keyword argument to omit packages that are " +"not intended to be released and installed." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:370 @@ -1661,15 +2261,23 @@ msgid "py_modules" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:376 -msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." +msgid "" +"If your project contains any single-file Python modules that aren't part of " +"a package, set ``py_modules`` to a list of the names of the modules (minus " +"the ``.py`` extension) in order to make :ref:`setuptools` aware of them." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:388 -msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgid "" +"\"install_requires\" should be used to specify what dependencies a project " +"minimally needs to run. When the project is installed by :ref:`pip`, this is " +"the specification that is used to install its dependencies." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:392 -msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." +msgid "" +"For more on using \"install_requires\" see :ref:`install_requires vs " +"Requirements files`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:398 @@ -1677,11 +2285,17 @@ msgid "python_requires" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:400 -msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" +msgid "" +"If your project only runs on certain Python versions, setting the " +"``python_requires`` argument to the appropriate :pep:`440` version specifier " +"string will prevent :ref:`pip` from installing the project on other Python " +"versions. For example, if your package is for Python 3+ only, write::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:407 -msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" +msgid "" +"If your package is for Python 2.6, 2.7, and all versions of Python 3 " +"starting with 3.3, write::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:412 @@ -1689,11 +2303,20 @@ msgid "And so on." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:416 -msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." +msgid "" +"Support for this feature is relatively recent. Your project's source " +"distributions and wheels (see :ref:`Packaging Your Project`) must be built " +"using at least version 24.2.0 of :ref:`setuptools` in order for the " +"``python_requires`` argument to be recognized and the appropriate metadata " +"generated." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:422 -msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." +msgid "" +"In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the " +"``python_requires`` metadata. Users with earlier versions of pip will be " +"able to download & install projects on any Python version regardless of the " +"projects' ``python_requires`` values." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:431 @@ -1701,15 +2324,25 @@ msgid "package_data" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:440 -msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." +msgid "" +"Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the " +"package’s implementation, or text files containing documentation that might " +"be of interest to programmers using the package. These files are called " +"\"package data\"." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:445 -msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." +msgid "" +"The value must be a mapping from package name to a list of relative path " +"names that should be copied into the package. The paths are interpreted as " +"relative to the directory containing the package." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:449 -msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." +msgid "" +"For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:457 @@ -1717,19 +2350,39 @@ msgid "data_files" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:463 -msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." +msgid "" +"Although configuring :ref:`Package Data` is sufficient for most needs, in " +"some cases you may need to place data files *outside* of your :term:" +"`packages `. The ``data_files`` directive allows you to do " +"that. It is mostly useful if you need to install files which are used by " +"other programs, which may be unaware of Python packages." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:469 -msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." +msgid "" +"Each ``(directory, files)`` pair in the sequence specifies the installation " +"directory and the files to install there. The ``directory`` must be a " +"relative path (although this may change in the future, see `wheel Issue #92 " +"`_). and it is interpreted relative " +"to the installation prefix (Python’s ``sys.prefix`` for a default " +"installation; ``site.USER_BASE`` for a user installation). Each file name in " +"``files`` is interpreted relative to the :file:`setup.py` script at the top " +"of the project source distribution." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:479 -msgid "For more information see the distutils section on `Installing Additional Files `_." +msgid "" +"For more information see the distutils section on `Installing Additional " +"Files `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:484 -msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." +msgid "" +"When installing packages as egg, ``data_files`` is not supported. So, if " +"your project uses :ref:`setuptools`, you must use ``pip`` to install it. " +"Alternatively, if you must use ``python setup.py``, then you need to pass " +"the ``--old-and-unmanageable`` option." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:491 @@ -1737,7 +2390,11 @@ msgid "scripts" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:493 -msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." +msgid "" +"Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made " +"scripts to install, the recommended approach to achieve cross-platform " +"compatibility is to use :ref:`console_scripts` entry points (see below)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:500 @@ -1745,11 +2402,17 @@ msgid "entry_points" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:509 -msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." +msgid "" +"Use this keyword to specify any plugins that your project provides for any " +"named entry points that may be defined by your project or others that you " +"depend on." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:512 -msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." +msgid "" +"For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:516 @@ -1761,11 +2424,20 @@ msgid "console_scripts" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:531 -msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgid "" +"Use \"console_script\" `entry points `_ to " +"register your script interfaces. You can then let the toolchain handle the " +"work of turning these interfaces into actual scripts [2]_. The scripts will " +"be generated during the install of your :term:`distribution `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:538 -msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." +msgid "" +"For more information, see `Automatic Script Creation `_ from " +"the `setuptools docs `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:545 @@ -1777,7 +2449,12 @@ msgid "Standards compliance for interoperability" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:550 -msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." +msgid "" +"Different Python projects may use different versioning schemes based on the " +"needs of that particular project, but all of them are required to comply " +"with the flexible :pep:`public version scheme <440#public-version-" +"identifiers>` specified in :pep:`440` in order to be supported in tools and " +"libraries like ``pip`` and ``setuptools``." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:556 @@ -1785,7 +2462,11 @@ msgid "Here are some examples of compliant version numbers::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:567 -msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." +msgid "" +"To further accommodate historical variations in approaches to version " +"numbering, :pep:`440` also defines a comprehensive technique for :pep:" +"`version normalisation <440#normalization>` that maps variant spellings of " +"different version numbers to a standardised canonical form." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:573 @@ -1797,11 +2478,16 @@ msgid "Semantic versioning (preferred)" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:578 -msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." +msgid "" +"For new projects, the recommended versioning scheme is based on `Semantic " +"Versioning `_, but adopts a different approach to " +"handling pre-releases and build metadata." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:582 -msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" +msgid "" +"The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE " +"numbering scheme, where the project author increments:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:585 @@ -1809,7 +2495,9 @@ msgid "MAJOR version when they make incompatible API changes," msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:586 -msgid "MINOR version when they add functionality in a backwards-compatible manner, and" +msgid "" +"MINOR version when they add functionality in a backwards-compatible manner, " +"and" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:587 @@ -1817,11 +2505,17 @@ msgid "MAINTENANCE version when they make backwards-compatible bug fixes." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:589 -msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." +msgid "" +"Adopting this approach as a project author allows users to make use of :pep:`" +"\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= " +"X.Y`` requires at least release X.Y, but also allows any later release with " +"a matching MAJOR version." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:594 -msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." +msgid "" +"Python projects adopting semantic versioning should abide by clauses 1-8 of " +"the `Semantic Versioning 2.0.0 specification `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:598 @@ -1829,15 +2523,23 @@ msgid "Date based versioning" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:600 -msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." +msgid "" +"Semantic versioning is not a suitable choice for all projects, such as those " +"with a regular time based release cadence and a deprecation process that " +"provides warnings for a number of releases prior to removal of a feature." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:604 -msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." +msgid "" +"A key advantage of date based versioning is that it is straightforward to " +"tell how old the base feature set of a particular release is given just the " +"version number." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:607 -msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." +msgid "" +"Version numbers for date based projects typically take the form of YEAR." +"MONTH (for example, ``12.04``, ``15.10``)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:611 @@ -1845,11 +2547,16 @@ msgid "Serial versioning" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:613 -msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." +msgid "" +"This is the simplest possible versioning scheme, and consists of a single " +"number which is incremented every release." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:616 -msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." +msgid "" +"While serial versioning is very easy to manage as a developer, it is the " +"hardest to track as an end user, as serial version numbers convey little or " +"no information regarding API backwards compatibility." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:621 @@ -1857,7 +2564,11 @@ msgid "Hybrid schemes" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:623 -msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." +msgid "" +"Combinations of the above schemes are possible. For example, a project may " +"combine date based versioning with serial versioning to create a YEAR.SERIAL " +"numbering scheme that readily conveys the approximate age of a release, but " +"doesn't otherwise commit to a particular release cadence within the year." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:629 @@ -1865,7 +2576,9 @@ msgid "Pre-release versioning" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:631 -msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" +msgid "" +"Regardless of the base versioning scheme, pre-releases for a given final " +"release may be published as:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:634 @@ -1885,7 +2598,9 @@ msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:639 -msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." +msgid "" +"``pip`` and other modern Python package installers ignore pre-releases by " +"default when deciding which versions of dependencies to install." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:644 @@ -1893,11 +2608,19 @@ msgid "Local version identifiers" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:646 -msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." +msgid "" +"Public version identifiers are designed to support distribution via :term:" +"`PyPI `. Python's software distribution tools " +"also support the notion of a :pep:`local version identifier <440#local-" +"version-identifiers>`, which can be used to identify local development " +"builds not intended for publication, or modified variants of a release " +"maintained by a redistributor." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:653 -msgid "A local version identifier takes the form ``+``. For example::" +msgid "" +"A local version identifier takes the form ``" +"+``. For example::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:661 @@ -1905,7 +2628,10 @@ msgid "Working in \"development mode\"" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:663 -msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." +msgid "" +"Although not required, it's common to locally install your project in " +"\"editable\" or \"develop\" mode while you're working on it. This allows " +"your project to be both installed and editable in project form." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:667 @@ -1913,31 +2639,56 @@ msgid "Assuming you're in the root of your project directory, then run:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:674 -msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." +msgid "" +"Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` " +"refers to the current working directory, so together, it means to install " +"the current directory (i.e. your project) in editable mode. This will also " +"install any dependencies declared with \"install_requires\" and any scripts " +"declared with \"console_scripts\". Dependencies will be installed in the " +"usual, non-editable mode." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:680 -msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" +msgid "" +"It's fairly common to also want to install some of your dependencies in " +"editable mode as well. For example, supposing your project requires \"foo\" " +"and \"bar\", but you want \"bar\" installed from VCS in editable mode, then " +"you could construct a requirements file like so::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:688 -msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." +msgid "" +"The first line says to install your project and any dependencies. The second " +"line overrides the \"bar\" dependency, such that it's fulfilled from VCS, " +"not PyPI." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:692 -msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" +msgid "" +"If, however, you want \"bar\" installed from a local directory in editable " +"mode, the requirements file should look like this, with the local paths at " +"the top of the file::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:697 -msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." +msgid "" +"Otherwise, the dependency will be fulfilled from PyPI, due to the " +"installation order of the requirements file. For more on requirements " +"files, see the :ref:`Requirements File ` section in " +"the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:701 -msgid "Lastly, if you don't want to install any dependencies at all, you can run::" +msgid "" +"Lastly, if you don't want to install any dependencies at all, you can run::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:706 -msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." +msgid "" +"For more information, see the `Development Mode `_ section of the " +"`setuptools docs `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:713 @@ -1945,11 +2696,17 @@ msgid "Packaging your project" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:715 -msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." +msgid "" +"To have your project installable from a :term:`Package Index` like :term:" +"`PyPI `, you'll need to create a :term:" +"`Distribution ` (aka \":term:`Package `\") for your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:720 -msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" +msgid "" +"Before you can build wheels and sdists for your project, you'll need to " +"install the ``build`` package:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:737 @@ -1957,11 +2714,18 @@ msgid "Source distributions" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:739 -msgid "Minimally, you should create a :term:`Source Distribution `:" +msgid "" +"Minimally, you should create a :term:`Source Distribution `:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:755 -msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." +msgid "" +"A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built " +"Distribution`), and requires a build step when installed by pip. Even if " +"the distribution is pure Python (i.e. contains no extensions), it still " +"involves a build step to build out the installation metadata from :file:" +"`setup.py` and/or :file:`setup.cfg`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:763 @@ -1969,23 +2733,36 @@ msgid "Wheels" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:765 -msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." +msgid "" +"You should also create a wheel for your project. A wheel is a :term:`built " +"package ` that can be installed without needing to go " +"through the \"build\" process. Installing wheels is substantially faster for " +"the end user than installing from a source distribution." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:770 -msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." +msgid "" +"If your project is pure Python then you'll be creating a :ref:`\"Pure Python " +"Wheel\" (see section below) `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:773 -msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." +msgid "" +"If your project contains compiled extensions, then you'll be creating what's " +"called a :ref:`*Platform Wheel* (see section below) `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:776 -msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" +msgid "" +"If your project also supports Python 2 *and* contains no C extensions, then " +"you should create what's called a *Universal Wheel* by adding the following " +"to your :file:`setup.cfg` file:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:785 -msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." +msgid "" +"Only use this setting if your project does not have any C extensions *and* " +"supports Python 2 and 3." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:792 @@ -1993,7 +2770,9 @@ msgid "Pure Python Wheels" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:794 -msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." +msgid "" +"*Pure Python Wheels* contain no compiled extensions, and therefore only " +"require a single Python wheel." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:797 @@ -2002,11 +2781,16 @@ msgid "To build the wheel:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:811 -msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." +msgid "" +"The ``wheel`` package will detect that the code is pure Python, and build a " +"wheel that's named such that it's usable on any Python 3 installation. For " +"details on the naming of wheel files, see :pep:`425`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:815 -msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." +msgid "" +"If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both " +"files for you; this is useful when you don't need multiple wheels." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:821 @@ -2014,15 +2798,23 @@ msgid "Platform Wheels" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:823 -msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." +msgid "" +"*Platform Wheels* are wheels that are specific to a certain platform like " +"Linux, macOS, or Windows, usually due to containing compiled extensions." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:841 -msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." +msgid "" +"The ``wheel`` package will detect that the code is not pure Python, and " +"build a wheel that's named such that it's only usable on the platform that " +"it was built on. For details on the naming of wheel files, see :pep:`425`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:847 -msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." +msgid "" +":term:`PyPI ` currently supports uploads of " +"platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. " +"Details of the latter are defined in :pep:`513`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:855 @@ -2030,23 +2822,45 @@ msgid "Uploading your Project to PyPI" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:857 -msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." +msgid "" +"When you ran the command to create your distribution, a new directory ``dist/" +"`` was created under your project's root directory. That's where you'll find " +"your distribution file(s) to upload." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:861 -msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." +msgid "" +"These files are only created when you run the command to create your " +"distribution. This means that any time you change the source of your project " +"or the configuration in your :file:`setup.py` file, you will need to rebuild " +"these files again before you can distribute the changes to PyPI." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:866 -msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." +msgid "" +"Before releasing on main PyPI repo, you might prefer training with the `PyPI " +"test site `_ which is cleaned on a semi regular " +"basis. See :ref:`using-test-pypi` on how to setup your configuration in " +"order to use it." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:871 -msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." +msgid "" +"In other resources you may encounter references to using ``python setup.py " +"register`` and ``python setup.py upload``. These methods of registering and " +"uploading a package are **strongly discouraged** as it may use a plaintext " +"HTTP or unverified HTTPS connection on some Python versions, allowing your " +"username and password to be intercepted during transmission." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:877 -msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" +msgid "" +"The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to " +"ensure safety of all users, certain kinds of URLs and directives are " +"forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** " +"trying to upload your distribution, you should check to see if your brief / " +"long descriptions provided in :file:`setup.py` are valid. You can do this " +"by running :std:doc:`twine check ` on your package files::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:888 @@ -2054,23 +2868,35 @@ msgid "Create an account" msgstr "Створіть обліковий запис" #: ../source/guides/distributing-packages-using-setuptools.rst:890 -msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." +msgid "" +"First, you need a :term:`PyPI ` user account. " +"You can create an account `using the form on the PyPI website `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:894 -msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." +msgid "" +"Now you'll create a PyPI `API token`_ so you will be able to securely upload " +"your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:897 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." +msgid "" +"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " +"token`_; don't limit its scope to a particular project, since you are " +"creating a new project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:901 -msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgid "" +"**Don't close the page until you have copied and saved the token — you won't " +"see that token again.**" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:904 -msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" +msgid "" +"To avoid having to copy and paste the token every time you upload, you can " +"create a :file:`$HOME/.pypirc` file:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:913 @@ -2081,7 +2907,8 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:70 #: ../source/guides/migrating-to-pypi-org.rst:109 #: ../source/guides/using-testpypi.rst:83 -msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." +msgid "" +"For more details, see the :ref:`specification ` for :file:`.pypirc`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:921 @@ -2089,28 +2916,46 @@ msgid "Upload your distributions" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:923 -msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." +msgid "" +"Once you have an account you can upload your distributions to :term:`PyPI " +"` using :ref:`twine`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:926 -msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." +msgid "" +"The process for uploading a release is the same regardless of whether or not " +"the project already exists on PyPI - if it doesn't exist yet, it will be " +"automatically created when the first release is uploaded." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:930 -msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." +msgid "" +"For the second and subsequent releases, PyPI only requires that the version " +"number of the new release differ from any previous releases." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:937 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgid "" +"You can see if your package has successfully uploaded by navigating to the " +"URL ``https://pypi.org/project/`` where ``sampleproject`` is " +"the name of your project that you uploaded. It may take a minute or two for " +"your project to appear on the site." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:944 #: ../source/tutorials/installing-packages.rst:663 -msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." +msgid "" +"Depending on your platform, this may require root or Administrator access. :" +"ref:`pip` is currently considering changing this by `making user installs " +"the default behavior `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:950 -msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." +msgid "" +"Specifically, the \"console_script\" approach generates ``.exe`` files on " +"Windows, which are necessary because the OS special-cases ``.exe`` files. " +"Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for " +"Windows <397>` allow scripts to be used in many cases, but not all." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:5 @@ -2118,19 +2963,30 @@ msgid "Dropping support for older Python versions" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:7 -msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." +msgid "" +"Dropping support for older Python versions is supported by the standard :ref:" +"`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:9 -msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." +msgid "" +"Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification " +"by matching the current Python runtime and comparing it with the required " +"version in the package metadata. If they do not match, it will attempt to " +"install the last package distribution that supported that Python runtime." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:12 -msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." +msgid "" +"This mechanism can be used to drop support for older Python versions, by " +"amending the \"Requires-Python\" attribute in the package metadata." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:14 -msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." +msgid "" +"This guide is specifically for users of :ref:`setuptools`, other packaging " +"tools such as ``flit`` may offer similar functionality but users will need " +"to consult relevant documentation." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:17 @@ -2150,7 +3006,9 @@ msgid "The latest version of :ref:`twine` is used to upload the package," msgstr "" #: ../source/guides/dropping-older-python-versions.rst:23 -msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." +msgid "" +"The user installing the package has at least Pip 9.0, or a client that " +"supports the Metadata 1.2 specification." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:26 @@ -2158,15 +3016,26 @@ msgid "Dealing with the universal wheels" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:28 -msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." +msgid "" +"Traditionally, projects providing Python code that is semantically " +"compatible with both Python 2 and Python 3, produce :term:`wheels ` " +"that have a ``py2.py3`` tag in their names. When dropping support for Python " +"2, it is important not to forget to change this tag to just ``py3``. It is " +"often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` " +"section by setting ``universal = 1`` if they use setuptools." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:36 -msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" +msgid "" +"If you use this method, either remove this option or section, or explicitly " +"set ``universal`` to ``0``:" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:48 -msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." +msgid "" +"Since it is possible to override the :file:`setup.cfg` settings via CLI " +"flags, make sure that your scripts don't have ``--universal`` in your " +"package creation scripts." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:53 @@ -2178,7 +3047,9 @@ msgid "1. Download the newest version of Setuptools" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:58 -msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." +msgid "" +"Ensure that before you generate source distributions or binary " +"distributions, you update Setuptools and install twine." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:60 @@ -2194,7 +3065,9 @@ msgid "2. Specify the version ranges for supported Python distributions" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:79 -msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." +msgid "" +"You can specify version ranges and exclusion rules, such as at least Python " +"3. Or, Python 2.7, 3.4 and beyond." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:81 @@ -2210,7 +3083,10 @@ msgid "Examples::" msgstr "Приклади::" #: ../source/guides/dropping-older-python-versions.rst:86 -msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." +msgid "" +"The way to set those values is within the call to ``setup`` within your :" +"file:`setup.py` script. This will insert the ``Requires-Python`` metadata " +"values based on the argument you provide in ``python_requires``." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:101 @@ -2218,11 +3094,16 @@ msgid "3. Validating the Metadata before publishing" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:103 -msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." +msgid "" +"Within a Python source package (the zip or the tar-gz file you download) is " +"a text file called PKG-INFO." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:105 -msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." +msgid "" +"This file is generated by Distutils or :ref:`setuptools` when it generates " +"the source package. The file contains a set of keys and values, the list of " +"keys is part of the PyPa standard metadata format." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:108 @@ -2234,11 +3115,14 @@ msgid "Validate that the following is in place, before publishing the package:" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:114 -msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." +msgid "" +"If you have upgraded correctly, the Metadata-Version value should be 1.2 or " +"higher." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:115 -msgid "The Requires-Python field is set and matches your specification in setup.py." +msgid "" +"The Requires-Python field is set and matches your specification in setup.py." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:118 @@ -2246,7 +3130,9 @@ msgid "4. Using Twine to publish" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:120 -msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." +msgid "" +"Twine has a number of advantages, apart from being faster it is now the " +"supported method for publishing packages." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:122 @@ -2258,7 +3144,9 @@ msgid "Dropping a Python release" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:127 -msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." +msgid "" +"Once you have published a package with the Requires-Python metadata, you can " +"then make a further update removing that Python runtime from support." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:129 @@ -2266,11 +3154,17 @@ msgid "It must be done in this order for the automated fallback to work." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:131 -msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." +msgid "" +"For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 " +"of your package." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:133 -msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." +msgid "" +"If you were then to update the version string to \">=3.5\", and publish a " +"new version 2.0.0 of your package, any users running Pip 9.0+ from version " +"2.7 will have version 1.0.0 of the package installed, and any >=3.5 users " +"will receive version 2.0.0." msgstr "" #: ../source/guides/hosting-your-own-index.rst:5 @@ -2278,15 +3172,25 @@ msgid "Hosting your own simple repository" msgstr "" #: ../source/guides/hosting-your-own-index.rst:8 -msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." +msgid "" +"If you wish to host your own simple repository [1]_, you can either use a " +"software package like `devpi`_ or you can use simply create the proper " +"directory structure and use any web server that can serve static files and " +"generate an autoindex." msgstr "" #: ../source/guides/hosting-your-own-index.rst:13 -msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" +msgid "" +"In either case, since you'll be hosting a repository that is likely not in " +"your user's default repositories, you should instruct them in your project's " +"description to configure their installer appropriately. For example with pip:" msgstr "" #: ../source/guides/hosting-your-own-index.rst:29 -msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." +msgid "" +"In addition, it is **highly** recommended that you serve your repository " +"with valid HTTPS. At this time, the security of your user's installations " +"depends on all repositories using a valid HTTPS setup." msgstr "" #: ../source/guides/hosting-your-own-index.rst:35 @@ -2294,34 +3198,45 @@ msgid "\"Manual\" repository" msgstr "" #: ../source/guides/hosting-your-own-index.rst:37 -msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" +msgid "" +"The directory layout is fairly simple, within a root directory you need to " +"create a directory for each project. This directory should be the normalized " +"name (as defined by :pep:`503`) of the project. Within each of these " +"directories simply place each of the downloadable files. If you have the " +"projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the " +"version 0.1) You should end up with a structure that looks like::" msgstr "" #: ../source/guides/hosting-your-own-index.rst:51 -msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." +msgid "" +"Once you have this layout, simply configure your webserver to serve the root " +"directory with autoindex enabled. For an example using the built in Web " +"server in `Twisted`_, you would simply run ``twistd -n web --path .`` and " +"then instruct users to add the URL to their installer's configuration." msgstr "" #: ../source/guides/hosting-your-own-index.rst:58 -msgid "For complete documentation of the simple repository protocol, see :pep:`503`." +msgid "" +"For complete documentation of the simple repository protocol, see :pep:`503`." msgstr "" -#: ../source/guides/index.rst:8 #: ../source/guides/index.rst:8 msgid "Installing Packages:" msgstr "" -#: ../source/guides/index.rst:20 #: ../source/guides/index.rst:20 msgid "Building and Publishing Projects:" msgstr "" -#: ../source/guides/index.rst:38 #: ../source/guides/index.rst:38 msgid "Miscellaneous:" msgstr "" #: ../source/guides/index.rst:4 -msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." +msgid "" +"**Guides** are focused on accomplishing a specific task and assume that you " +"are already familiar with the basics of Python packaging. If you're looking " +"for an introduction to packaging, see :doc:`/tutorials/index`." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:5 @@ -2334,7 +3249,10 @@ msgid "2014-12-24" msgstr "24.12.2014" #: ../source/guides/index-mirrors-and-caches.rst:14 -msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." +msgid "" +"Mirroring or caching of PyPI can be used to speed up local package " +"installation, allow offline work, handle corporate firewalls or just plain " +"Internet flakiness." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:17 @@ -2346,11 +3264,15 @@ msgid "pip provides local caching options," msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:20 -msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" +msgid "" +"devpi provides higher-level caching option, potentially shared amongst many " +"users or machines, and" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:22 -msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." +msgid "" +"bandersnatch provides a local complete mirror of all PyPI :term:`packages " +"`." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:27 @@ -2358,15 +3280,23 @@ msgid "Caching with pip" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:29 -msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" +msgid "" +"pip provides a number of facilities for speeding up installation by using " +"local cached copies of :term:`packages `:" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:32 -msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." +msgid "" +"`Fast & local installs `_ by downloading all the requirements for a project and " +"then pointing pip at those downloaded files instead of going to PyPI." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:36 -msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" +msgid "" +"A variation on the above which pre-builds the installation files for the " +"requirements using `python -m pip wheel `_::" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:45 @@ -2374,7 +3304,10 @@ msgid "Caching with devpi" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:47 -msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." +msgid "" +"devpi is a caching proxy server which you run on your laptop, or some other " +"machine you know will always be available to you. See the `devpi " +"documentation for getting started`__." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:55 @@ -2382,11 +3315,18 @@ msgid "Complete mirror with bandersnatch" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:57 -msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." +msgid "" +"bandersnatch will set up a complete local mirror of all PyPI :term:`packages " +"` (externally-hosted packages are not mirrored). See " +"the `bandersnatch documentation for getting that going`__." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:63 -msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." +msgid "" +"A benefit of devpi is that it will create a mirror which includes :term:" +"`packages ` that are external to PyPI, unlike " +"bandersnatch which will only cache :term:`packages ` " +"hosted on PyPI." msgstr "" #: ../source/guides/installing-scientific-packages.rst:5 @@ -2394,19 +3334,38 @@ msgid "Installing scientific packages" msgstr "" #: ../source/guides/installing-scientific-packages.rst:11 -msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." +msgid "" +"Scientific software tends to have more complex dependencies than most, and " +"it will often have multiple build options to take advantage of different " +"kinds of hardware, or to interoperate with different pieces of external " +"software." msgstr "" #: ../source/guides/installing-scientific-packages.rst:16 -msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." +msgid "" +"In particular, `NumPy `__, which provides the basis " +"for most of the software in the `scientific Python stack `__ can be configured to interoperate with " +"different FORTRAN libraries, and can take advantage of different levels of " +"vectorised instructions available in modern CPUs." msgstr "" #: ../source/guides/installing-scientific-packages.rst:22 -msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." +msgid "" +"Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built " +"32-bit and 64-bit binaries in the ``wheel`` format are available for all " +"major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, " +"that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, " +"so they may not provide optimal linear algebra performance." msgstr "" #: ../source/guides/installing-scientific-packages.rst:29 -msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." +msgid "" +"There are a number of alternative options for obtaining scientific Python " +"libraries (or any other Python libraries that require a compilation " +"environment to install from source and don't provide pre-built wheel files " +"on PyPI)." msgstr "" #: ../source/guides/installing-scientific-packages.rst:35 @@ -2414,7 +3373,12 @@ msgid "Building from source" msgstr "" #: ../source/guides/installing-scientific-packages.rst:37 -msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." +msgid "" +"The same complexity which makes it difficult to distribute NumPy (and many " +"of the projects that depend on it) as wheel files also make them difficult " +"to build from source yourself. However, for intrepid folks that are willing " +"to spend the time wrangling compilers and linkers for both C and FORTRAN, " +"building from source is always an option." msgstr "" #: ../source/guides/installing-scientific-packages.rst:45 @@ -2422,11 +3386,18 @@ msgid "Linux distribution packages" msgstr "" #: ../source/guides/installing-scientific-packages.rst:47 -msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." +msgid "" +"For Linux users, the system package manager will often have pre-compiled " +"versions of various pieces of scientific software, including NumPy and other " +"parts of the scientific Python stack." msgstr "" #: ../source/guides/installing-scientific-packages.rst:51 -msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." +msgid "" +"If using versions which may be several months old is acceptable, then this " +"is likely to be a good option (just make sure to allow access to " +"distributions installed into the system Python when using virtual " +"environments)." msgstr "" #: ../source/guides/installing-scientific-packages.rst:57 @@ -2434,23 +3405,42 @@ msgid "Windows installers" msgstr "" #: ../source/guides/installing-scientific-packages.rst:59 -msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." +msgid "" +"Many Python projects that don't (or can't) currently publish wheel files at " +"least publish Windows installers, either on PyPI or on their project " +"download page. Using these installers allows users to avoid the need to set " +"up a suitable environment to build extensions locally." msgstr "" #: ../source/guides/installing-scientific-packages.rst:64 -msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." +msgid "" +"The extensions provided in these installers are typically compatible with " +"the CPython Windows installers published on python.org." msgstr "" #: ../source/guides/installing-scientific-packages.rst:67 -msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." +msgid "" +"For projects which don't provide their own Windows installers (and even some " +"which do), Christoph Gohlke at the University of California provides a " +"`collection of Windows installers `__. Many Python users on Windows have reported a positive experience with " +"these prebuilt versions." msgstr "" #: ../source/guides/installing-scientific-packages.rst:73 -msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." +msgid "" +"As with Linux system packages, the Windows installers will only install into " +"a system Python installation - they do not support installation in virtual " +"environments. Allowing access to distributions installed into the system " +"Python when using virtual environments is a common approach to working " +"around this limitation." msgstr "" #: ../source/guides/installing-scientific-packages.rst:79 -msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." +msgid "" +"The :term:`Wheel` project also provides a :command:`wheel convert` " +"subcommand that can convert a Windows :command:`bdist_wininst` installer to " +"a wheel." msgstr "" #: ../source/guides/installing-scientific-packages.rst:86 @@ -2458,11 +3448,18 @@ msgid "macOS installers and package managers" msgstr "" #: ../source/guides/installing-scientific-packages.rst:88 -msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." +msgid "" +"Similar to the situation on Windows, many projects (including NumPy) publish " +"macOS installers that are compatible with the macOS CPython binaries " +"published on python.org." msgstr "" #: ../source/guides/installing-scientific-packages.rst:92 -msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" +msgid "" +"macOS users also have access to Linux distribution style package managers " +"such as ``MacPorts``. The SciPy site has more details on using MacPorts to " +"install the `scientific Python stack `__" msgstr "" #: ../source/guides/installing-scientific-packages.rst:99 @@ -2470,11 +3467,16 @@ msgid "SciPy distributions" msgstr "" #: ../source/guides/installing-scientific-packages.rst:101 -msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." +msgid "" +"The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use " +"and update format." msgstr "" #: ../source/guides/installing-scientific-packages.rst:105 -msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." +msgid "" +"Some of these distributions may not be compatible with the standard ``pip`` " +"and ``virtualenv`` based toolchain." msgstr "" #: ../source/guides/installing-scientific-packages.rst:109 @@ -2483,11 +3485,25 @@ msgid "Spack" msgstr "" #: ../source/guides/installing-scientific-packages.rst:110 -msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." +msgid "" +"`Spack `_ is a flexible package manager " +"designed to support multiple versions, configurations, platforms, and " +"compilers. It was built to support the needs of large supercomputing centers " +"and scientific application teams, who must often build software many " +"different ways. Spack is not limited to Python; it can install packages for " +"``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-" +"destructive; installing a new version of one package does not break existing " +"installations, so many configurations can coexist on the same system." msgstr "" #: ../source/guides/installing-scientific-packages.rst:119 -msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." +msgid "" +"Spack offers a simple but powerful syntax that allows users to specify " +"versions and configuration options concisely. Package files are written in " +"pure Python, and they are templated so that it is easy to swap compilers, " +"dependency implementations (like MPI), versions, and build options with a " +"single package file. Spack also generates *module* files so that packages " +"can be loaded and unloaded from the user's environment." msgstr "" #: ../source/guides/installing-scientific-packages.rst:128 @@ -2495,11 +3511,29 @@ msgid "The conda cross-platform package manager" msgstr "" #: ../source/guides/installing-scientific-packages.rst:130 -msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." +msgid "" +"`Anaconda `_ is a Python distribution " +"published by Anaconda, Inc. It is a stable collection of Open Source " +"packages for big data and scientific use. As of the 5.0 release of " +"Anaconda, about 200 packages are installed by default, and a total of " +"400-500 can be installed and updated from the Anaconda repository." msgstr "" #: ../source/guides/installing-scientific-packages.rst:136 -msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." +msgid "" +"``conda`` is an open source (BSD licensed) package management system and " +"environment management system included in Anaconda that allows users to " +"install multiple versions of binary software packages and their " +"dependencies, and easily switch between them. It is a cross-platform tool " +"working on Windows, macOS, and Linux. Conda can be used to package up and " +"distribute all kinds of packages, it is not limited to just Python packages. " +"It has full support for native virtual environments. Conda makes " +"environments first-class citizens, making it easy to create independent " +"environments even for C libraries. It is written in Python, but is Python-" +"agnostic. Conda manages Python itself as a package, so that :command:`conda " +"update python` is possible, in contrast to pip, which only manages Python " +"packages. Conda is available in Anaconda and Miniconda (an easy-to-install " +"download with just Python and conda)." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:2 @@ -2507,15 +3541,28 @@ msgid "Installing stand alone command line tools" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:4 -msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." +msgid "" +"Many packages have command line entry points. Examples of this type of " +"application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:10 -msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." +msgid "" +"Usually you want to be able to access these from anywhere, but installing " +"packages and their dependencies to the same global environment can cause " +"version conflicts and break dependencies the operating system has on Python " +"packages." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:15 -msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." +msgid "" +":ref:`pipx` solves this by creating a virtual environment for each package, " +"while also ensuring that package's applications are accessible through a " +"directory that is on your ``$PATH``. This allows each package to be upgraded " +"or uninstalled without causing conflicts with other packages, and allows you " +"to safely run the program from anywhere." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:21 @@ -2527,11 +3574,14 @@ msgid "``pipx`` is installed with ``pip``:" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:30 -msgid "You may need to restart your terminal for the path updates to take effect." +msgid "" +"You may need to restart your terminal for the path updates to take effect." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:32 -msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." +msgid "" +"Now you can install packages with ``pipx install`` and access the package's " +"entry point(s) from anywhere." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:39 @@ -2540,7 +3590,9 @@ msgid "For example" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:59 -msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." +msgid "" +"To see a list of packages installed with pipx and which CLI applications are " +"available, use ``pipx list``." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:79 @@ -2552,7 +3604,9 @@ msgid "``pipx`` can be upgraded or uninstalled with pip" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:93 -msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." +msgid "" +"``pipx`` also allows you to install and run the latest version of a cli tool " +"in a temporary, ephemeral environment." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:106 @@ -2560,7 +3614,9 @@ msgid "To see the full list of commands ``pipx`` offers, run" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:112 -msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." +msgid "" +"You can learn more about ``pipx`` at its homepage, https://github.com/pypa/" +"pipx." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:5 @@ -2572,19 +3628,35 @@ msgid "2015-09-17" msgstr "17.09.2015" #: ../source/guides/installing-using-linux-tools.rst:11 -msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." +msgid "" +"This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:" +"`wheel` using Linux package managers." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:14 -msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." +msgid "" +"If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:" +"`installing_requirements` section instead." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:18 -msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." +msgid "" +"Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, " +"and :ref:`wheel` supported by a specific Linux Distribution to be outdated " +"by the time it's released to the public, and updates generally only occur " +"for security reasons, not for feature updates. For certain Distributions, " +"there are additional repositories that can be enabled to provide newer " +"versions. The repositories we know about are explained below." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:25 -msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." +msgid "" +"Also note that it's somewhat common for Distributions to apply patches for " +"the sake of security and normalization to their own standards. In some " +"cases, this can lead to bugs or unexpected behaviors that vary from the " +"original unpatched versions. When this is known, we will make note of it " +"below." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:32 @@ -2616,7 +3688,11 @@ msgid "Python 3: ``sudo dnf install python3 python3-wheel``" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:53 -msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" +msgid "" +"To get newer versions of pip, setuptools, and wheel for Python 2, you can " +"enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:63 @@ -2624,7 +3700,9 @@ msgid "CentOS/RHEL" msgstr "CentOS/RHEL" #: ../source/guides/installing-using-linux-tools.rst:65 -msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." +msgid "" +"CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core " +"repositories, although :ref:`setuptools` is installed by default." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:68 @@ -2632,7 +3710,11 @@ msgid "To install pip and wheel for the system Python, there are two options:" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:70 -msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" +msgid "" +"Enable the `EPEL repository `_ using " +"`these instructions `__. On EPEL 6 and EPEL7, you can " +"install pip like so::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:77 @@ -2640,11 +3722,16 @@ msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:81 -msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." +msgid "" +"Since EPEL only offers extra, non-conflicting packages, EPEL does not offer " +"setuptools, since it's in the core repository." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:85 -msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" +msgid "" +"Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:92 @@ -2652,15 +3739,21 @@ msgid "To additionally upgrade setuptools, run::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:97 -msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" +msgid "" +"To install pip, wheel, and setuptools, in a parallel, non-system environment " +"(using yum) then there are two options:" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:101 -msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." +msgid "" +"Use the \"Software Collections\" feature to enable a parallel collection " +"that includes pip, setuptools, and wheel." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:104 -msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" +msgid "" +"For Redhat, see here: http://developers.redhat.com/products/" +"softwarecollections/overview/" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:106 @@ -2672,7 +3765,11 @@ msgid "Be aware that collections may not contain the most recent versions." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:110 -msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." +msgid "" +"Enable the `IUS repository `_ and install " +"one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which " +"are kept fairly up to date." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:116 @@ -2694,7 +3791,10 @@ msgid "Debian/Ubuntu" msgstr "Debian/Ubuntu" #: ../source/guides/installing-using-linux-tools.rst:150 -msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." +msgid "" +"Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" " +"`_ by default, " +"which is a significant behavior change that can be surprising to some users." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:156 @@ -2702,7 +3802,9 @@ msgid "Arch Linux" msgstr "Arch Linux" #: ../source/guides/installing-using-linux-tools.rst:168 -msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." +msgid "" +"Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the " +"only option is to manually place the repo files as described." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 @@ -2710,11 +3812,18 @@ msgid "Installing packages using pip and virtual environments" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 -msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." +msgid "" +"This guide discusses how to install packages using :ref:`pip` and a virtual " +"environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` " +"for Python 2. These are the lowest-level tools for managing Python packages " +"and are recommended if higher-level tools do not suit your needs." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 -msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." +msgid "" +"This doc uses the term **package** to refer to a :term:`Distribution " +"Package` which is different from an :term:`Import Package` that which is " +"used to import modules in your Python source code." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 @@ -2722,15 +3831,24 @@ msgid "Installing pip" msgstr "Встановлення pip" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 -msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." +msgid "" +":ref:`pip` is the reference Python package manager. It's used to install and " +"update packages. You'll need to make sure you have the latest version of pip " +"installed." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 -msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." +msgid "" +"Debian and most other distributions include a `python-pip`_ package, if you " +"want to use the Linux distribution-provided versions of pip see :doc:`/" +"guides/installing-using-linux-tools`." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 -msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" +msgid "" +"You can also install pip yourself to ensure you have the latest version. " +"It's recommended to use the system pip to bootstrap a user installation of " +"pip:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 @@ -2738,7 +3856,9 @@ msgid "Afterwards, you should have the newest pip installed in your user site:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 -msgid "The Python installers for Windows include pip. You should be able to access pip using:" +msgid "" +"The Python installers for Windows include pip. You should be able to access " +"pip using:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 @@ -2750,11 +3870,19 @@ msgid "Installing virtualenv" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 -msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." +msgid "" +"If you are using Python 3.3 or newer, the :mod:`venv` module is the " +"preferred way to create and manage virtual environments. venv is included in " +"the Python standard library and requires no additional installation. If you " +"are using venv, you may skip this section." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 -msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." +msgid "" +":ref:`virtualenv` is used to manage Python packages for different projects. " +"Using virtualenv allows you to avoid installing Python packages globally " +"which could break system tools or other projects. You can install virtualenv " +"using pip." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 @@ -2762,15 +3890,28 @@ msgid "Creating a virtual environment" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 -msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." +msgid "" +":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to " +"manage separate package installations for different projects. They " +"essentially allow you to create a \"virtual\" isolated Python installation " +"and install packages into that virtual installation. When you switch " +"projects, you can simply create a new virtual environment and not have to " +"worry about breaking the packages installed in the other environments. It is " +"always recommended to use a virtual environment while developing Python " +"applications." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 -msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." +msgid "" +"To create a virtual environment, go to your project's directory and run " +"venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the " +"below commands." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 -msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." +msgid "" +"The second argument is the location to create the virtual environment. " +"Generally, you can just create this in your project and call it ``env``." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 @@ -2778,7 +3919,9 @@ msgid "venv will create a virtual Python installation in the ``env`` folder." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 -msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." +msgid "" +"You should exclude your virtual environment directory from your version " +"control system using ``.gitignore`` or similar." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 @@ -2786,15 +3929,24 @@ msgid "Activating a virtual environment" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 -msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." +msgid "" +"Before you can start installing or using packages in your virtual " +"environment you'll need to *activate* it. Activating a virtual environment " +"will put the virtual environment-specific ``python`` and ``pip`` executables " +"into your shell's ``PATH``." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 -msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." +msgid "" +"You can confirm you're in the virtual environment by checking the location " +"of your Python interpreter, it should point to the ``env`` directory." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 -msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." +msgid "" +"As long as your virtual environment is activated pip will install packages " +"into that specific environment and you'll be able to import and use packages " +"in your Python application." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 @@ -2802,11 +3954,16 @@ msgid "Leaving the virtual environment" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 -msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" +msgid "" +"If you want to switch projects or otherwise leave your virtual environment, " +"simply run:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 -msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." +msgid "" +"If you want to re-enter the virtual environment just follow the same " +"instructions above about activating a virtual environment. There's no need " +"to re-create the virtual environment." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 @@ -2814,11 +3971,14 @@ msgid "Installing packages" msgstr "Встановлення пакунків" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 -msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" +msgid "" +"Now that you're in your virtual environment you can install packages. Let's " +"install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 -msgid "pip should download requests and all of its dependencies and install them:" +msgid "" +"pip should download requests and all of its dependencies and install them:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 @@ -2826,7 +3986,10 @@ msgid "Installing specific versions" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 -msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" +msgid "" +"pip allows you to specify which version of a package to install using :term:" +"`version specifiers `. For example, to install a specific " +"version of ``requests``:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 @@ -2842,7 +4005,9 @@ msgid "Installing extras" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 -msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" +msgid "" +"Some packages have optional `extras`_. You can tell pip to install these by " +"specifying the extra in brackets:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 @@ -2854,7 +4019,10 @@ msgid "pip can install a package directly from source, for example:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 -msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" +msgid "" +"Additionally, pip can install packages from source in `development mode`_, " +"meaning that changes to the source directory will immediately affect the " +"installed package without needing to re-install:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 @@ -2862,11 +4030,15 @@ msgid "Installing from version control systems" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 -msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" +msgid "" +"pip can install packages directly from their version control system. For " +"example, you can install directly from a git repository:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 -msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." +msgid "" +"For more information on supported version control systems and syntax, see " +"pip's documentation on :ref:`VCS Support `." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 @@ -2875,15 +4047,23 @@ msgid "Installing from local archives" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 -msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" +msgid "" +"If you have a local copy of a :term:`Distribution Package`'s archive (a zip, " +"wheel, or tar file) you can install it directly with pip:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 -msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" +msgid "" +"If you have a directory containing archives of multiple packages, you can " +"tell pip to look for packages there and not to use the :term:`Python Package " +"Index (PyPI)` at all:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 -msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." +msgid "" +"This is useful if you are installing packages on a system with limited " +"connectivity or if you want to strictly control the origin of distribution " +"packages." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 @@ -2891,11 +4071,16 @@ msgid "Using other package indexes" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 -msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" +msgid "" +"If you want to download packages from a different index than the :term:" +"`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 -msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" +msgid "" +"If you want to allow packages from both the :term:`Python Package Index " +"(PyPI)` and a separate index, you can use the ``--extra-index-url`` flag " +"instead:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 @@ -2904,7 +4089,9 @@ msgid "Upgrading packages" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 -msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" +msgid "" +"pip can upgrade packages in-place using the ``--upgrade`` flag. For example, " +"to install the latest version of ``requests`` and all of its dependencies:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 @@ -2912,11 +4099,16 @@ msgid "Using requirements files" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 -msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" +msgid "" +"Instead of installing packages individually, pip allows you to declare all " +"dependencies in a :ref:`Requirements File `. For " +"example you could create a :file:`requirements.txt` file containing:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 -msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" +msgid "" +"And tell pip to install all of the packages in this file using the ``-r`` " +"flag:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 @@ -2924,7 +4116,9 @@ msgid "Freezing dependencies" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 -msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" +msgid "" +"Pip can export a list of all installed packages and their versions using the " +"``freeze`` command:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 @@ -2932,7 +4126,9 @@ msgid "Which will output a list of package specifiers such as:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 -msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." +msgid "" +"This is useful for creating :ref:`pip:Requirements Files` that can re-create " +"the exact versions of all packages installed in an environment." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:2 @@ -2940,7 +4136,11 @@ msgid "Making a PyPI-friendly README" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:4 -msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." +msgid "" +"README files can help your users understand your project and can be used to " +"set your project's description on PyPI. This guide helps you create a README " +"in a PyPI-friendly format and include your README in your package so it " +"appears on PyPI." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:9 @@ -2948,11 +4148,16 @@ msgid "Creating a README file" msgstr "Створення файлу README" #: ../source/guides/making-a-pypi-friendly-readme.rst:11 -msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." +msgid "" +"README files for Python projects are often named ``README``, ``README.txt``, " +"``README.rst``, or ``README.md``." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:13 -msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" +msgid "" +"For your README to display properly on PyPI, choose a markup language " +"supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:16 @@ -2960,15 +4165,21 @@ msgid "plain text" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:17 -msgid "`reStructuredText `_ (without Sphinx extensions)" +msgid "" +"`reStructuredText `_ (without " +"Sphinx extensions)" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:18 -msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" +msgid "" +"Markdown (`GitHub Flavored Markdown `_ by " +"default, or `CommonMark `_)" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:21 -msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." +msgid "" +"It's customary to save your README file in the root of your project, in the " +"same directory as your :file:`setup.py` file." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:25 @@ -2976,7 +4187,10 @@ msgid "Including your README in your package's metadata" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:27 -msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." +msgid "" +"To include your README's contents as your package description, set your " +"project's ``Description`` and ``Description-Content-Type`` metadata, " +"typically in your project's :file:`setup.py` file." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:33 @@ -2988,15 +4202,23 @@ msgid ":ref:`description-content-type-optional`" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:36 -msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." +msgid "" +"For example, to set these values in a package's :file:`setup.py` file, use " +"``setup()``'s ``long_description`` and ``long_description_content_type``." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:39 -msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." +msgid "" +"Set the value of ``long_description`` to the contents (not the path) of the " +"README file itself. Set the ``long_description_content_type`` to an accepted " +"``Content-Type``-style value for your README file's markup, such as ``text/" +"plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:45 -msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" +msgid "" +"If you're using GitHub-flavored Markdown to write a project's description, " +"ensure you upgrade the following tools:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:60 @@ -3016,11 +4238,16 @@ msgid "``twine >= 1.11.0``" msgstr "``twine >= 1.11.0``" #: ../source/guides/making-a-pypi-friendly-readme.rst:66 -msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" +msgid "" +"It's recommended that you use ``twine`` to upload the project's distribution " +"packages:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:72 -msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" +msgid "" +"For example, see this :file:`setup.py` file, which reads the contents of :" +"file:`README.md` as ``long_description`` and identifies the markup as GitHub-" +"flavored Markdown:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:95 @@ -3028,23 +4255,36 @@ msgid "Validating reStructuredText markup" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:97 -msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." +msgid "" +"If your README is written in reStructuredText, any invalid markup will " +"prevent it from rendering, causing PyPI to instead just show the README's " +"raw source." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:100 -msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." +msgid "" +"Note that Sphinx extensions used in docstrings, such as `directives and " +"roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```" +"\"), are not allowed here and will result in error messages like \"``Error: " +"Unknown interpreted text role \"py:func\".``\"." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:105 -msgid "You can check your README for markup errors before uploading as follows:" +msgid "" +"You can check your README for markup errors before uploading as follows:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:107 -msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" +msgid "" +"Install the latest version of `twine `_; " +"version 1.12.0 or higher is required:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:122 -msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." +msgid "" +"Build the sdist and wheel for your project as described under :ref:" +"`Packaging Your Project`." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:125 @@ -3052,7 +4292,10 @@ msgid "Run ``twine check`` on the sdist and wheel::" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:129 -msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." +msgid "" +"This command will report any problems rendering your README. If your markup " +"renders fine, the command will output ``Checking distribution FILENAME: " +"Passed``." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:4 @@ -3060,7 +4303,11 @@ msgid "Migrating to PyPI.org" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:6 -msgid ":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``." +msgid "" +":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``." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:12 @@ -3072,15 +4319,21 @@ msgid "``pypi.org`` is the default upload platform as of September 2016." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:16 -msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." +msgid "" +"Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. " +"As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:19 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:22 -msgid "The default upload settings switched to ``pypi.org`` in the following versions:" +msgid "" +"The default upload settings switched to ``pypi.org`` in the following " +"versions:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:24 @@ -3108,19 +4361,32 @@ msgid "Python 3.6.0 (``distutils`` update)" msgstr "Python 3.6.0 (оновлення ``distutils``)" #: ../source/guides/migrating-to-pypi-org.rst:31 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:48 -msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." +msgid "" +"Then simply delete the line starting with ``repository`` and you will use " +"your upload tool's default URL." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:51 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:67 -msgid "(``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.)" +msgid "" +"(``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.)" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:73 @@ -3128,15 +4394,22 @@ msgid "Registering package names & metadata" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:75 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:79 -msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" +msgid "" +"As a result, attempting explicit registration after switching to using PyPI." +"org for uploads will give the following error message::" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:84 -msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." +msgid "" +"The solution is to skip the registration step, and proceed directly to " +"uploading artifacts." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:89 @@ -3145,7 +4418,12 @@ msgid "Using TestPyPI" msgstr "Використання TestPyPI" #: ../source/guides/migrating-to-pypi-org.rst:91 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:113 @@ -3153,7 +4431,10 @@ msgid "Registering new user accounts" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:115 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:121 @@ -3161,7 +4442,11 @@ msgid "Browsing packages" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:123 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:130 @@ -3177,7 +4462,9 @@ msgid "Managing published packages and releases" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:137 -msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." +msgid "" +"``pypi.org`` provides a fully functional interface for logged in users to " +"manage their published packages and releases." msgstr "" #: ../source/guides/multi-version-installs.rst:5 @@ -3185,23 +4472,51 @@ msgid "Multi-version installs" msgstr "" #: ../source/guides/multi-version-installs.rst:8 -msgid "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``)." +msgid "" +"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``)." msgstr "" #: ../source/guides/multi-version-installs.rst:13 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/multi-version-installs.rst:19 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/multi-version-installs.rst:31 -msgid "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 ``python -c ''`` to invoke the application's main entry point directly." +msgid "" +"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 ``python -c ''`` to invoke the application's main " +"entry point directly." msgstr "" #: ../source/guides/multi-version-installs.rst:38 -msgid "Refer to the `pkg_resources documentation `__ for more details." +msgid "" +"Refer to the `pkg_resources documentation `__ for more details." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:5 @@ -3213,7 +4528,12 @@ msgid "2013-12-08" msgstr "08.12.2013" #: ../source/guides/packaging-binary-extensions.rst:10 -msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." +msgid "" +"One of the features of the CPython reference interpreter is that, in " +"addition to allowing the execution of Python code, it also exposes a rich C " +"API for use by other software. One of the most common uses of this C API is " +"to create importable C extensions that allow things which aren't always easy " +"to achieve in pure Python code." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:20 @@ -3225,27 +4545,66 @@ msgid "Use cases" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:25 -msgid "The typical use cases for binary extensions break down into just three conventional categories:" +msgid "" +"The typical use cases for binary extensions break down into just three " +"conventional categories:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:28 -msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." +msgid "" +"**accelerator modules**: these modules are completely self-contained, and " +"are created solely to run faster than the equivalent pure Python code runs " +"in CPython. Ideally, accelerator modules will always have a pure Python " +"equivalent to use as a fallback if the accelerated version isn't available " +"on a given system. The CPython standard library makes extensive use of " +"accelerator modules. *Example*: When importing ``datetime``, Python falls " +"back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not " +"available." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:39 -msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." +msgid "" +"**wrapper modules**: these modules are created to expose existing C " +"interfaces to Python code. They may either expose the underlying C interface " +"directly, or else expose a more \"Pythonic\" API that makes use of Python " +"language features to make the API easier to use. The CPython standard " +"library makes extensive use of wrapper modules. *Example*: `functools.py " +"`_ is a " +"Python module wrapper for `_functoolsmodule.c `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:47 -msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." +msgid "" +"**low-level system access**: these modules are created to access lower level " +"features of the CPython runtime, the operating system, or the underlying " +"hardware. Through platform specific code, extension modules may achieve " +"things that aren't possible in pure Python code. A number of CPython " +"standard library modules are written in C in order to access interpreter " +"internals that aren't exposed at the language level. *Example*: ``sys``, " +"which comes from `sysmodule.c `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:56 -msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." +msgid "" +"One particularly notable feature of C extensions is that, when they don't " +"need to call back into the interpreter runtime, they can release CPython's " +"global interpreter lock around long-running operations (regardless of " +"whether those operations are CPU or IO bound)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:61 -msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." +msgid "" +"Not all extension modules will fit neatly into the above categories. The " +"extension modules included with NumPy, for example, span all three use cases " +"- they move inner loops to C for speed reasons, wrap external libraries " +"written in C, FORTRAN and other languages, and use low level system " +"interfaces for both CPython and the underlying operation system to support " +"concurrent execution of vectorised operations and to tightly control the " +"exact memory layout of created objects." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:71 @@ -3253,7 +4612,13 @@ msgid "Disadvantages" msgstr "Недоліки" #: ../source/guides/packaging-binary-extensions.rst:73 -msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." +msgid "" +"The main disadvantage of using binary extensions is the fact that it makes " +"subsequent distribution of the software more difficult. One of the " +"advantages of using Python is that it is largely cross platform, and the " +"languages used to write extension modules (typically C or C++, but really " +"any language that can bind to the CPython C API) typically require that " +"custom binaries be created for different platforms." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:80 @@ -3261,27 +4626,44 @@ msgid "This means that binary extensions:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:82 -msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" +msgid "" +"require that end users be able to either build them from source, or else " +"that someone publish pre-built binaries for common platforms" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:85 -msgid "may not be compatible with different builds of the CPython reference interpreter" +msgid "" +"may not be compatible with different builds of the CPython reference " +"interpreter" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:88 -msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" +msgid "" +"often will not work correctly with alternative interpreters such as PyPy, " +"IronPython or Jython" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:91 -msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." +msgid "" +"if handcoded, make maintenance more difficult by requiring that maintainers " +"be familiar not only with Python, but also with the language used to create " +"the binary extension, as well as with the details of the CPython C API." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:96 -msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." +msgid "" +"if a pure Python fallback implementation is provided, make maintenance more " +"difficult by requiring that changes be implemented in two places, and " +"introducing additional complexity in the test suite to ensure both versions " +"are always executed." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:101 -msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." +msgid "" +"Another disadvantage of relying on binary extensions is that alternative " +"import mechanisms (such as the ability to import modules directly from " +"zipfiles) often won't work for extension modules (as the dynamic loading " +"mechanisms on most platforms can only load libraries from disk)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:108 @@ -3289,23 +4671,56 @@ msgid "Alternatives to handcoded accelerator modules" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:110 -msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" +msgid "" +"When extension modules are just being used to make code run faster (after " +"profiling has identified the code where the speed increase is worth " +"additional maintenance effort), a number of other alternatives should also " +"be considered:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:115 -msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." +msgid "" +"look for existing optimised alternatives. The CPython standard library " +"includes a number of optimised data structures and algorithms (especially in " +"the builtins and the ``collections`` and ``itertools`` modules). The Python " +"Package Index also offers additional alternatives. Sometimes, the " +"appropriate choice of standard library or third party module can avoid the " +"need to create your own accelerator module." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:122 -msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." +msgid "" +"for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython " +"runtime. The main barrier to adopting PyPy is typically reliance on other " +"binary extension modules - while PyPy does emulate the CPython C API, " +"modules that rely on that cause problems for the PyPy JIT, and the emulation " +"layer can often expose latent defects in extension modules that CPython " +"currently tolerates (frequently around reference counting errors - an object " +"having one live reference instead of two often won't break anything, but no " +"references instead of one is a major problem)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:132 -msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." +msgid "" +"`Cython `__ is a mature static compiler that can compile " +"most Python code to C extension modules. The initial compilation provides " +"some speed increases (by bypassing the CPython interpreter layer), and " +"Cython's optional static typing features can offer additional opportunities " +"for speed increases. Using Cython still has the disadvantage of increasing " +"the complexity of distributing the resulting application, but has the " +"benefit of having a reduced barrier to entry for Python programmers " +"(relative to other languages like C or C++)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:141 -msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." +msgid "" +"`Numba `__ is a newer tool, created by members of " +"the scientific Python community, that aims to leverage LLVM to allow " +"selective compilation of pieces of a Python application to native machine " +"code at runtime. It requires that LLVM be available on the system where the " +"code is running, but can provide significant speed increases, especially for " +"operations that are amenable to vectorisation." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:150 @@ -3313,35 +4728,74 @@ msgid "Alternatives to handcoded wrapper modules" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:152 -msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." +msgid "" +"The C ABI (Application Binary Interface) is a common standard for sharing " +"functionality between multiple applications. One of the strengths of the " +"CPython C API (Application Programming Interface) is allowing Python users " +"to tap into that functionality. However, wrapping modules by hand is quite " +"tedious, so a number of other alternative approaches should be considered." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:158 -msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." +msgid "" +"The approaches described below don't simplify the distribution case at all, " +"but they *can* significantly reduce the maintenance burden of keeping " +"wrapper modules up to date." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:162 -msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." +msgid "" +"In addition to being useful for the creation of accelerator modules, `Cython " +"`__ is also useful for creating wrapper modules for C or " +"C++. It still involves wrapping the interfaces by hand, however, and is very " +"repetitive, so may not be a good choice for wrapping large APIs." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:168 -msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." +msgid "" +"`pybind11 `__ is a pure C++11 library that " +"provides a clean C++ interface to the CPython (and PyPy) C API. It does not " +"require a pre-processing step; it is written entirely in templated C++. " +"Helpers are included for Setuptools or CMake builds. It was based on `Boost." +"Python `__, but doesn't require the Boost libraries or BJam." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:175 -msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." +msgid "" +"`cffi `__ is a project created by some of the " +"PyPy developers to make it straightforward for developers that already know " +"both Python and C to expose their C modules to Python applications. It also " +"makes it relatively straightforward to wrap a C module based on its header " +"files, even if you don't know C yourself." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:181 -msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." +msgid "" +"One of the key advantages of ``cffi`` is that it is compatible with the PyPy " +"JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing " +"JIT optimisations." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:185 -msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." +msgid "" +"`SWIG `__ is a wrapper interface generator that allows " +"a variety of programming languages, including Python, to interface with C " +"and C++ code." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:189 -msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." +msgid "" +"The standard library's ``ctypes`` module, while useful for getting access to " +"C level interfaces when header information isn't available, suffers from the " +"fact that it operates solely at the C ABI level, and thus has no automatic " +"consistency checking between the interface actually being exported by the " +"library and the one declared in the Python code. By contrast, the above " +"alternatives are all able to operate at the C *API* level, using C header " +"files to ensure consistency between the interface exported by the library " +"being wrapped and the one expected by the Python wrapper module. While " +"``cffi`` *can* operate directly at the C ABI level, it suffers from the same " +"interface inconsistency problems as ``ctypes`` when it is used that way." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:203 @@ -3349,11 +4803,24 @@ msgid "Alternatives for low level system access" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:205 -msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." +msgid "" +"For applications that need low level system access (regardless of the " +"reason), a binary extension module often *is* the best way to go about it. " +"This is particularly true for low level access to the CPython runtime " +"itself, since some operations (like releasing the Global Interpreter Lock) " +"are simply invalid when the interpreter is running code, even if a module " +"like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API " +"interfaces." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:213 -msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." +msgid "" +"For cases where the extension module is manipulating the underlying " +"operating system or hardware (rather than the CPython runtime), it may " +"sometimes be better to just write an ordinary C library (or a library in " +"another systems programming language like C++ or Rust that can export a C " +"compatible ABI), and then use one of the wrapping techniques described above " +"to make the interface available as an importable Python module." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:222 @@ -3361,7 +4828,10 @@ msgid "Implementing binary extensions" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:224 -msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." +msgid "" +"The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in " +"C `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:241 @@ -3373,7 +4843,14 @@ msgid "Building extensions for multiple platforms" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:246 -msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." +msgid "" +"If you plan to distribute your extension, you should provide :term:`wheels " +"` for all the platforms you intend to support. For most extensions, " +"this is at least one package per Python version times the number of OS and " +"architectures you support. These are usually built on continuous " +"integration (CI) systems. There are tools to help you build highly " +"redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:" +"`multibuild`." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:256 @@ -3381,15 +4858,27 @@ msgid "Binary extensions for Windows" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:258 -msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." +msgid "" +"Before it is possible to build a binary extension, it is necessary to ensure " +"that you have a suitable compiler available. On Windows, Visual C is used to " +"build the official CPython interpreter, and should be used to build " +"compatible binary extensions." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:263 -msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." +msgid "" +"Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio " +"2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older " +"versions of Visual Studio are no longer easily available from Microsoft, so " +"for versions of Python prior to 3.5, the compilers must be obtained " +"differently if you do not already have a copy of the relevant version of " +"Visual Studio." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:269 -msgid "To set up a build environment for binary extensions, the steps are as follows:" +msgid "" +"To set up a build environment for binary extensions, the steps are as " +"follows:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:271 @@ -3397,11 +4886,16 @@ msgid "For Python 2.7" msgstr "Для Python 2.7" #: ../source/guides/packaging-binary-extensions.rst:273 -msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." +msgid "" +"Install \"Visual C++ Compiler Package for Python 2.7\", which is available " +"from `Microsoft's website `__." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:276 -msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." +msgid "" +"Use (a recent version of) setuptools in your setup.py (pip will do this for " +"you, in any case)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:278 @@ -3415,11 +4909,16 @@ msgid "For Python 3.4" msgstr "Для Python 3.4" #: ../source/guides/packaging-binary-extensions.rst:282 -msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." +msgid "" +"Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is " +"available from `Microsoft's website `__." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:285 -msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." +msgid "" +"Work from an SDK command prompt (with the environment variables set, and the " +"SDK on PATH)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:287 @@ -3431,15 +4930,23 @@ msgid "For Python 3.5" msgstr "Для Python 3.5" #: ../source/guides/packaging-binary-extensions.rst:292 -msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." +msgid "" +"Install `Visual Studio 2015 Community Edition `__ (or any later version, " +"when these are released)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:297 -msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." +msgid "" +"Note that from Python 3.5 onwards, Visual Studio works in a backward " +"compatible way, which means that any future version of Visual Studio will be " +"able to build Python extensions for all Python versions from 3.5 onwards." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:301 -msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." +msgid "" +"Building with the recommended compiler on Windows ensures that a compatible " +"C library is used throughout the Python process." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:305 @@ -3447,7 +4954,11 @@ msgid "Binary extensions for Linux" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:307 -msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." +msgid "" +"Linux binaries must use a sufficiently old glibc to be compatible with older " +"distributions. The `manylinux `_ Docker " +"images provide a build environment with a glibc old enough to support most " +"current Linux distributions on common architectures." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:313 @@ -3455,7 +4966,15 @@ msgid "Binary extensions for macOS" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:315 -msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." +msgid "" +"Binary compatibility on macOS is determined by the target minimum deployment " +"system, e.g. *10.9*, which is often specified with the " +"``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries " +"on macOS. When building with setuptools / distutils, the deployment target " +"is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For " +"common deployment targets for macOS Python distributions, see the `MacPython " +"Spinning Wheels wiki `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:325 @@ -3463,7 +4982,9 @@ msgid "Publishing binary extensions" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:327 -msgid "For interim guidance on this topic, see the discussion in `this issue `_." +msgid "" +"For interim guidance on this topic, see the discussion in `this issue " +"`_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:343 @@ -3471,7 +4992,13 @@ msgid "Additional resources" msgstr "Додаткові матеріали" #: ../source/guides/packaging-binary-extensions.rst:345 -msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." +msgid "" +"Cross-platform development and distribution of extension modules is a " +"complex topic, so this guide focuses primarily on providing pointers to " +"various tools that automate dealing with the underlying technical " +"challenges. The additional resources in this section are instead intended " +"for developers looking to understand more about the underlying binary " +"interfaces that those systems rely on at runtime." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:352 @@ -3479,7 +5006,13 @@ msgid "Cross-platform wheel generation with scikit-build" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:354 -msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." +msgid "" +"The `scikit-build `_ package " +"helps abstract cross-platform build operations and provides additional " +"capabilities when creating binary extension packages. Additional " +"documentation is also available on the `C runtime, compiler, and build " +"system generator `_ for Python binary extension modules." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:362 @@ -3487,11 +5020,15 @@ msgid "Introduction to C/C++ extension modules" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:364 -msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" +msgid "" +"For a more in depth explanation of how extension modules are used by CPython " +"on a Debian system, see the following articles:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:367 -msgid "`What are (c)python extension modules? `_" +msgid "" +"`What are (c)python extension modules? `_" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:368 @@ -3499,7 +5036,9 @@ msgid "`Releasing the gil `_" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:369 -msgid "`Writing cpython extension modules using C++ `_" +msgid "" +"`Writing cpython extension modules using C++ `_" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:3 @@ -3507,7 +5046,12 @@ msgid "Packaging namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:5 -msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" +msgid "" +"Namespace packages allow you to split the sub-packages and modules within a " +"single :term:`package ` across multiple, separate :term:" +"`distribution packages ` (referred to as " +"**distributions** in this document to avoid ambiguity). For example, if you " +"have the following package structure:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:24 @@ -3523,7 +5067,14 @@ msgid "Each sub-package can now be separately installed, used, and versioned." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:48 -msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." +msgid "" +"Namespace packages can be useful for a large collection of loosely-related " +"packages (such as a large corpus of client libraries for multiple products " +"from a single company). However, namespace packages come with several " +"caveats and are not appropriate in all cases. A simple alternative is to use " +"a prefix on all of your distributions such as ``import " +"mynamespace_subpackage_a`` (you could even use ``import " +"mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:58 @@ -3531,23 +5082,39 @@ msgid "Creating a namespace package" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:60 -msgid "There are currently three different approaches to creating namespace packages:" +msgid "" +"There are currently three different approaches to creating namespace " +"packages:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:62 -msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." +msgid "" +"Use `native namespace packages`_. This type of namespace package is defined " +"in :pep:`420` and is available in Python 3.3 and later. This is recommended " +"if packages in your namespace only ever need to support Python 3 and " +"installation via ``pip``." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:66 -msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." +msgid "" +"Use `pkgutil-style namespace packages`_. This is recommended for new " +"packages that need to support Python 2 and 3 and installation via both " +"``pip`` and ``python setup.py install``." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:69 -msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." +msgid "" +"Use `pkg_resources-style namespace packages`_. This method is recommended if " +"you need compatibility with packages already using this method or if your " +"package needs to be zip-safe." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:73 -msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." +msgid "" +"While native namespace packages and pkgutil-style namespace packages are " +"largely compatible, pkg_resources-style namespace packages are not " +"compatible with the other methods. It's inadvisable to use different methods " +"in different distributions that provide packages to the same namespace." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:80 @@ -3555,23 +5122,41 @@ msgid "Native namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:82 -msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" +msgid "" +"Python 3.3 added **implicit** namespace packages from :pep:`420`. All that " +"is required to create a native namespace package is that you just omit :file:" +"`__init__.py` from the namespace package directory. An example file " +"structure:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:97 -msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." +msgid "" +"It is extremely important that every distribution that uses the namespace " +"package omits the :file:`__init__.py` or uses a pkgutil-style :file:" +"`__init__.py`. If any distribution does not, it will cause the namespace " +"logic to fail and the other sub-packages will not be importable." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:102 -msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" +msgid "" +"Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:" +"`setuptools.find_packages` won't find the sub-package. You must use :func:" +"`setuptools.find_namespace_packages` instead or explicitly list all packages " +"in your :file:`setup.py`. For example:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:117 -msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." +msgid "" +"A complete working example of two native namespace packages can be found in " +"the `native namespace package example project`_." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:123 -msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." +msgid "" +"Because native and pkgutil-style namespace packages are largely compatible, " +"you can use native namespace packages in the distributions that only support " +"Python 3 and pkgutil-style namespace packages in the distributions that need " +"to support Python 2 and 3." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:129 @@ -3579,25 +5164,39 @@ msgid "pkgutil-style namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:131 -msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." +msgid "" +"Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. " +"This can be used to declare namespace packages that need to be compatible " +"with both Python 2.3+ and Python 3. This is the recommended approach for the " +"highest level of compatibility." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:136 -msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgid "" +"To create a pkgutil-style namespace package, you need to provide an :file:" +"`__init__.py` file for the namespace package:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:148 #: ../source/guides/packaging-namespace-packages.rst:194 -msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" +msgid "" +"The :file:`__init__.py` file for the namespace package needs to contain " +"**only** the following:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:155 #: ../source/guides/packaging-namespace-packages.rst:201 -msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." +msgid "" +"**Every** distribution that uses the namespace package must include an " +"identical :file:`__init__.py`. If any distribution does not, it will cause " +"the namespace logic to fail and the other sub-packages will not be " +"importable. Any additional code in :file:`__init__.py` will be inaccessible." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:160 -msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." +msgid "" +"A complete working example of two pkgutil-style namespace packages can be " +"found in the `pkgutil namespace example project`_." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:171 @@ -3605,39 +5204,68 @@ msgid "pkg_resources-style namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:173 -msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." +msgid "" +"`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and " +"the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together " +"these can be used to declare namespace packages. While this approach is no " +"longer recommended, it is widely present in most existing namespace " +"packages. If you are creating a new distribution within an existing " +"namespace package that uses this method then it's recommended to continue " +"using this as the different methods are not cross-compatible and it's not " +"advisable to try to migrate an existing package." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:182 -msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgid "" +"To create a pkg_resources-style namespace package, you need to provide an :" +"file:`__init__.py` file for the namespace package:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:206 -msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" +msgid "" +"Some older recommendations advise the following in the namespace package :" +"file:`__init__.py`:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:216 -msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." +msgid "" +"The idea behind this was that in the rare case that setuptools isn't " +"available packages would fall-back to the pkgutil-style packages. This isn't " +"advisable because pkgutil and pkg_resources-style namespace packages are not " +"cross-compatible. If the presence of setuptools is a concern then the " +"package should just explicitly depend on setuptools via ``install_requires``." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:223 -msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" +msgid "" +"Finally, every distribution must provide the ``namespace_packages`` argument " +"to :func:`~setuptools.setup` in :file:`setup.py`. For example:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:237 -msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." +msgid "" +"A complete working example of two pkg_resources-style namespace packages can " +"be found in the `pkg_resources namespace example project`_." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 -msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" +msgid "" +"Publishing package distribution releases using GitHub Actions CI/CD workflows" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 -msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." +msgid "" +"`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an " +"event occurs on the GitHub platform. One popular choice is having a workflow " +"that's triggered by a ``push`` event. This guide shows you how to publish a " +"Python distribution whenever a tagged commit is pushed. It will use the " +"`pypa/gh-action-pypi-publish GitHub Action`_." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 -msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." +msgid "" +"This guide *assumes* that you already have a project that you know how to " +"build distributions for and *it lives on GitHub*." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 @@ -3645,7 +5273,10 @@ msgid "Saving credentials on GitHub" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 -msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." +msgid "" +"In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, " +"meaning that we'll have two separate sets of credentials. And we'll need to " +"save them in the GitHub repository settings." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 @@ -3653,23 +5284,37 @@ msgid "Let's begin! 🚀" msgstr "Почнімо! 🚀" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" +msgid "" +"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " +"token`_. If you have the project on PyPI already, limit the token scope to " +"just that project. You can call it something like ``GitHub Actions CI/CD — " +"project-org/project-repo`` in order for it to be easily distinguishable in " +"the token list. **Don't close the page just yet — you won't see that token " +"again.**" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 -msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." +msgid "" +"In a separate browser tab or window, go to the ``Settings`` tab of your " +"target repository and then click on `Secrets`_ in the left sidebar." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 -msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." +msgid "" +"Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from " +"the first step." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 -msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." +msgid "" +"Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the " +"steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 -msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." +msgid "" +"If you don't have a TestPyPI account, you'll need to create it. It's not the " +"same as a regular PyPI account." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 @@ -3677,7 +5322,9 @@ msgid "Creating a workflow definition" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 -msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." +msgid "" +"GitHub CI/CD workflows are declared in YAML files stored in the ``.github/" +"workflows/`` directory of your repository." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 @@ -3685,7 +5332,9 @@ msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 -msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" +msgid "" +"Start it with a meaningful name and define the event that should make GitHub " +"run this workflow:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 @@ -3693,7 +5342,9 @@ msgid "Defining a workflow job environment" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 -msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" +msgid "" +"Now, let's add initial setup for our job. It's a process that will execute " +"commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 @@ -3705,15 +5356,22 @@ msgid "Then, add the following under the ``build-n-publish`` section:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 -msgid "This will download your repository into the CI runner and then install and activate Python 3.7." +msgid "" +"This will download your repository into the CI runner and then install and " +"activate Python 3.7." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 -msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." +msgid "" +"And now we can build dists from source. In this example, we'll use ``build`` " +"package, assuming that your project has a ``pyproject.toml`` properly set up " +"(see :pep:`517`/:pep:`518`)." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 -msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." +msgid "" +"You can use any other method for building distributions as long as it " +"produces ready-to-upload artifacts saved into the ``dist/`` folder." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 @@ -3729,7 +5387,11 @@ msgid "Finally, add the following steps at the end:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 -msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." +msgid "" +"These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the " +"first one uploads contents of the ``dist/`` folder into TestPyPI " +"unconditionally and the second does that to PyPI, but only if the current " +"commit is tagged." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 @@ -3737,7 +5399,11 @@ msgid "That's all, folks!" msgstr "Це все, панове!" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 -msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" +msgid "" +"Now, whenever you push a tagged commit to your Git repository remote on " +"GitHub, this workflow will publish it to PyPI. And it'll publish any push to " +"TestPyPI which is useful for providing test builds to your alpha users as " +"well as making sure that your release pipeline remains healthy!" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:5 @@ -3745,87 +5411,143 @@ msgid "Single-sourcing the package version" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:8 -msgid "There are many techniques to maintain a single source of truth for the version number of your project:" +msgid "" +"There are many techniques to maintain a single source of truth for the " +"version number of your project:" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:11 -msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" +msgid "" +"Read the file in :file:`setup.py` and get the version. Example (from `pip " +"setup.py `_)::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:38 -msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" +msgid "" +"As of the release of setuptools 46.4.0, one can accomplish the same thing by " +"instead placing the following in the project's ``setup.cfg`` file (replacing " +"\"package\" with the import name of the package):" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:47 -msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." +msgid "" +"Earlier versions of setuptools implemented the ``attr:`` directive by " +"importing the module, but setuptools 46.4.0 added rudimentary AST analysis " +"so that ``attr:`` can function without having to import any of the package's " +"dependencies." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:52 -msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." +msgid "" +"Also, please be aware that declarative config indicators, including the " +"``attr:`` directive, are not supported in parameters to ``setup.py``." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:55 -msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." +msgid "" +"Use an external build tool that either manages updating both locations, or " +"offers an API that both locations can use." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:58 -msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." +msgid "" +"Few tools you could use, in no particular order, and not necessarily " +"complete: `bump2version `_, `changes " +"`_, `commitizen `_, `zest.releaser `_." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:65 -msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." +msgid "" +"Set the value to a ``__version__`` global variable in a dedicated module in " +"your project (e.g. :file:`version.py`), then have :file:`setup.py` read and " +"``exec`` the value into a variable." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:76 -msgid "Example using this technique: `warehouse `_." +msgid "" +"Example using this technique: `warehouse `_." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:78 -msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." +msgid "" +"Place the value in a simple ``VERSION`` text file and have both :file:`setup." +"py` and the project code read it." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:86 -msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." +msgid "" +"An advantage with this technique is that it's not specific to Python. Any " +"tool can read the version." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:91 -msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." +msgid "" +"With this approach you must make sure that the ``VERSION`` file is included " +"in all your source and binary distributions (e.g. add ``include VERSION`` to " +"your :file:`MANIFEST.in`)." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:95 -msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" +msgid "" +"Set the value in :file:`setup.py`, and have the project code use the " +"``importlib.metadata`` API to fetch the value at runtime. (``importlib." +"metadata`` was introduced in Python 3.8 and is available to older versions " +"as the ``importlib-metadata`` project.) An installed project's version can " +"be fetched with the API as follows::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:110 -msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." +msgid "" +"Be aware that the ``importlib.metadata`` API only knows about what's in the " +"installation metadata, which is not necessarily the code that's currently " +"imported." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:114 -msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" +msgid "" +"If a project uses this method to fetch its version at runtime, then its " +"``install_requires`` value needs to be edited to install ``importlib-" +"metadata`` on pre-3.8 versions of Python like so::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:128 -msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" +msgid "" +"An older (and less efficient) alternative to ``importlib.metadata`` is the " +"``pkg_resources`` API provided by ``setuptools``::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:134 -msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." +msgid "" +"If a project uses ``pkg_resources`` to fetch its own version at runtime, " +"then ``setuptools`` must be added to the project's ``install_requires`` list." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:138 -msgid "Example using this technique: `setuptools `_." +msgid "" +"Example using this technique: `setuptools `_." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:141 -msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." +msgid "" +"Set the value to ``__version__`` in ``sample/__init__.py`` and import " +"``sample`` in :file:`setup.py`." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:155 -msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." +msgid "" +"Although this technique is common, beware that it will fail if ``sample/" +"__init__.py`` imports packages from ``install_requires`` dependencies, which " +"will very likely not be installed yet when :file:`setup.py` is run." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:161 -msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." +msgid "" +"Keep the version number in the tags of a version control system (Git, " +"Mercurial, etc) instead of in the code, and automatically extract it from " +"there using `setuptools_scm `_." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:5 @@ -3833,11 +5555,20 @@ msgid "Supporting multiple Python versions" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:37 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:43 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:49 @@ -3845,31 +5576,52 @@ msgid "Automated testing and continuous integration" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:51 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:56 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:60 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:66 -msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." +msgid "" +"`Travis CI `_ provides both a Linux and a macOS " +"environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit " +"while the macOS is 10.9.2 at the time of writing." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:69 -msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." +msgid "" +"`Appveyor `_ provides a Windows environment " +"(Windows Server 2012)." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:80 -msgid "Both `Travis CI`_ 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." +msgid "" +"Both `Travis CI`_ 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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:85 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:89 @@ -3877,11 +5629,24 @@ msgid "Tools for single-source Python packages" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:91 -msgid "`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_." +msgid "" +"`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_." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:100 -msgid "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" +msgid "" +"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" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:107 @@ -3893,11 +5658,22 @@ msgid "a Python 3 (by syntax) module in a *Python 2* project." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:110 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:117 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:124 @@ -3905,7 +5681,13 @@ msgid "What's in which Python?" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:126 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:3 @@ -3917,19 +5699,37 @@ msgid "2015-12-03" msgstr "03.12.2015" #: ../source/guides/supporting-windows-using-appveyor.rst:8 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:20 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:24 -msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." +msgid "" +"The Appveyor service is a continuous integration service, much like the " +"better-known `Travis`_ service that is commonly used for testing by projects " +"hosted on `Github`_. However, unlike Travis, the build workers on Appveyor " +"are Windows hosts and have the necessary compilers installed to build Python " +"extensions." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:30 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:38 @@ -3937,15 +5737,25 @@ msgid "Setting up" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:40 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:45 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:49 -msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." +msgid "" +"Once you have set up your Appveyor account and added your project, Appveyor " +"will automatically build your project each time a commit occurs. This " +"behaviour will be familiar to users of Travis." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:54 @@ -3953,11 +5763,22 @@ msgid "Adding Appveyor support to your project" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:56 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:61 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:69 @@ -3965,39 +5786,74 @@ msgid "appveyor.yml" msgstr "appveyor.yml" #: ../source/guides/supporting-windows-using-appveyor.rst:75 -msgid "This file can be downloaded from `here `__." +msgid "" +"This file can be downloaded from `here `__." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:77 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:80 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:88 -msgid "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``)." +msgid "" +"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``)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:94 -msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." +msgid "" +"The ``build`` section simply switches off builds - there is no build step " +"needed for Python, unlike languages like ``C#``." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:97 -msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." +msgid "" +"The main sections that will need to be tailored to your project are " +"``test_script`` and ``after_test``." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:100 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:109 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:114 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:119 @@ -4005,15 +5861,29 @@ msgid "Support script" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:121 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:126 -msgid "`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." +msgid "" +"`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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:133 -msgid "You can simply download the batch file and include it in your project unchanged." +msgid "" +"You can simply download the batch file and include it in your project " +"unchanged." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:137 @@ -4021,7 +5891,14 @@ msgid "Access to the built wheels" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:139 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:147 @@ -4033,19 +5910,33 @@ msgid "Testing with tox" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:152 -msgid "Many projects use the `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." +msgid "" +"Many projects use the `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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:156 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:160 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:165 -msgid "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" +msgid "" +"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" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:170 @@ -4065,23 +5956,46 @@ msgid "``LIB``" msgstr "``LIB``" #: ../source/guides/supporting-windows-using-appveyor.rst:175 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:181 -msgid "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 Travis or 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)." +msgid "" +"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 Travis or 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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:188 -msgid "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``." +msgid "" +"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``." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:192 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:197 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:203 @@ -4089,11 +6003,19 @@ msgid "Automatically uploading wheels" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:205 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:210 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:216 @@ -4101,11 +6023,19 @@ msgid "External dependencies" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:218 -msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." +msgid "" +"The supplied scripts will successfully build any distribution that does not " +"rely on 3rd party external libraries for the build." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:221 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:230 @@ -4125,7 +6055,9 @@ msgid "Tool recommendations" msgstr "" #: ../source/guides/tool-recommendations.rst:7 -msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." +msgid "" +"If you're familiar with Python packaging and installation, and just want to " +"know what tools are currently recommended, then here it is." msgstr "" #: ../source/guides/tool-recommendations.rst:12 @@ -4133,7 +6065,10 @@ msgid "Application dependency management" msgstr "" #: ../source/guides/tool-recommendations.rst:14 -msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." +msgid "" +"Use :ref:`pipenv` to manage library dependencies when developing Python " +"applications. See :doc:`../tutorials/managing-dependencies` for more details " +"on using ``pipenv``." msgstr "" #: ../source/guides/tool-recommendations.rst:18 @@ -4157,15 +6092,23 @@ msgid "Installation tool recommendations" msgstr "Поради щодо засобу встановлення" #: ../source/guides/tool-recommendations.rst:29 -msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" +msgid "" +"Use :ref:`pip` to install Python :term:`packages ` " +"from :term:`PyPI `. [1]_ [2]_ Depending on how :" +"ref:`pip` is installed, you may need to also install :ref:`wheel` to get the " +"benefit of wheel caching. [3]_" msgstr "" #: ../source/guides/tool-recommendations.rst:34 -msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" +msgid "" +"Use :ref:`virtualenv`, or `venv`_ to isolate application specific " +"dependencies from a shared Python installation. [4]_" msgstr "" #: ../source/guides/tool-recommendations.rst:37 -msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" +msgid "" +"If you're looking for management of fully integrated cross-platform software " +"stacks, consider:" msgstr "" #: ../source/guides/tool-recommendations.rst:40 @@ -4173,7 +6116,9 @@ msgid ":ref:`buildout`: primarily focused on the web development community" msgstr "" #: ../source/guides/tool-recommendations.rst:42 -msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." +msgid "" +":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the " +"scientific community." msgstr "" #: ../source/guides/tool-recommendations.rst:47 @@ -4181,15 +6126,22 @@ msgid "Packaging tool recommendations" msgstr "Поради щодо засобу пакування" #: ../source/guides/tool-recommendations.rst:49 -msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" +msgid "" +"Use :ref:`setuptools` to define projects and create :term:`Source " +"Distributions `. [5]_ [6]_" msgstr "" #: ../source/guides/tool-recommendations.rst:52 -msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." +msgid "" +"Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:" +"`wheel project ` to create :term:`wheels `. This is " +"especially beneficial, if your project contains binary extensions." msgstr "" #: ../source/guides/tool-recommendations.rst:56 -msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." +msgid "" +"Use `twine `_ for uploading distributions " +"to :term:`PyPI `." msgstr "" #: ../source/guides/tool-recommendations.rst:61 @@ -4197,39 +6149,75 @@ msgid "Publishing platform migration" msgstr "" #: ../source/guides/tool-recommendations.rst:63 -msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." +msgid "" +"The original Python Package Index implementation (previously hosted at `pypi." +"python.org `_) has been phased out in favour of an " +"updated implementation hosted at `pypi.org `_." msgstr "" #: ../source/guides/tool-recommendations.rst:67 -msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." +msgid "" +"See :ref:`Migrating to PyPI.org` for more information on the status of the " +"migration, and what settings to change in your clients." msgstr "" #: ../source/guides/tool-recommendations.rst:72 -msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." +msgid "" +"There are some cases where you might choose to use ``easy_install`` (from :" +"ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` " +"(which pip doesn't support). For a detailed breakdown, see :ref:`pip vs " +"easy_install`." msgstr "" #: ../source/guides/tool-recommendations.rst:77 -msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." +msgid "" +"The acceptance of :pep:`453` means that :ref:`pip` will be available by " +"default in most installations of Python 3.4 or later. See the :pep:" +"`rationale section <453#rationale>` from :pep:`453` as for why pip was " +"chosen." msgstr "" #: ../source/guides/tool-recommendations.rst:82 -msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." +msgid "" +"`get-pip.py `_ and :ref:" +"`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv " +"` do not currently. Also, the common \"python-pip\" package that's " +"found in various linux distros, does not depend on \"python-wheel\" " +"currently." msgstr "" #: ../source/guides/tool-recommendations.rst:88 -msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." +msgid "" +"Beginning with Python 3.4, ``venv`` will create virtualenv environments with " +"``pip`` installed, thereby making it an equal alternative to :ref:" +"`virtualenv`. However, using :ref:`virtualenv` will still be recommended for " +"users that need cross-version consistency." msgstr "" #: ../source/guides/tool-recommendations.rst:93 -msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." +msgid "" +"Although you can use pure ``distutils`` for many projects, it does not " +"support defining dependencies on other projects and is missing several " +"convenience utilities for automatically populating distribution metadata " +"correctly that are provided by ``setuptools``. Being outside the standard " +"library, ``setuptools`` also offers a more consistent feature set across " +"different versions of Python, and (unlike ``distutils``), recent versions of " +"``setuptools`` support all of the modern metadata fields described in :ref:" +"`core-metadata`." msgstr "" #: ../source/guides/tool-recommendations.rst:102 -msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." +msgid "" +"Even for projects that do choose to use ``distutils``, when :ref:`pip` " +"installs such projects directly from source (rather than installing from a " +"prebuilt :term:`wheel ` file), it will actually build your project " +"using :ref:`setuptools` instead." msgstr "" #: ../source/guides/tool-recommendations.rst:107 -msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." +msgid "" +"`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` " +"in June 2013, thereby making setuptools the default choice for packaging." msgstr "" #: ../source/guides/using-manifest-in.rst:5 @@ -4237,11 +6225,23 @@ msgid "Including files in source distributions with ``MANIFEST.in``" msgstr "" #: ../source/guides/using-manifest-in.rst:7 -msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." +msgid "" +"When building a :term:`source distribution ` for your package, by default only a minimal set of files are " +"included. You may find yourself wanting to include extra files in the " +"source distribution, such as an authors/contributors file, a :file:`docs/` " +"directory, or a directory of data files used for testing purposes. There " +"may even be extra files that you *need* to include; for example, if your :" +"file:`setup.py` computes your project's ``long_description`` by reading from " +"both a README and a changelog file, you'll need to include both those files " +"in the sdist so that people that build or install from the sdist get the " +"correct results." msgstr "" #: ../source/guides/using-manifest-in.rst:17 -msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." +msgid "" +"Adding & removing files to & from the source distribution is done by writing " +"a :file:`MANIFEST.in` file at the project root." msgstr "" #: ../source/guides/using-manifest-in.rst:22 @@ -4253,11 +6253,15 @@ msgid "The following files are included in a source distribution by default:" msgstr "" #: ../source/guides/using-manifest-in.rst:26 -msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" +msgid "" +"all Python source files implied by the ``py_modules`` and ``packages`` " +"``setup()`` arguments" msgstr "" #: ../source/guides/using-manifest-in.rst:28 -msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" +msgid "" +"all C source files mentioned in the ``ext_modules`` or ``libraries`` " +"``setup()`` arguments" msgstr "" #: ../source/guides/using-manifest-in.rst:30 @@ -4265,15 +6269,21 @@ msgid "scripts specified by the ``scripts`` ``setup()`` argument" msgstr "" #: ../source/guides/using-manifest-in.rst:31 -msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" +msgid "" +"all files specified by the ``package_data`` and ``data_files`` ``setup()`` " +"arguments" msgstr "" #: ../source/guides/using-manifest-in.rst:33 -msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" +msgid "" +"the file specified by the ``license_file`` option in :file:`setup.cfg` " +"(setuptools 40.8.0+)" msgstr "" #: ../source/guides/using-manifest-in.rst:35 -msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" +msgid "" +"all files specified by the ``license_files`` option in :file:`setup.cfg` " +"(setuptools 42.0.0+)" msgstr "" #: ../source/guides/using-manifest-in.rst:37 @@ -4313,11 +6323,20 @@ msgid ":file:`MANIFEST.in`" msgstr ":file:`MANIFEST.in`" #: ../source/guides/using-manifest-in.rst:47 -msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." +msgid "" +"After adding the above files to the sdist, the commands in :file:`MANIFEST." +"in` (if such a file exists) are executed in order to add and remove further " +"files to & from the sdist. Default files can even be removed from the sdist " +"with the appropriate :file:`MANIFEST.in` command." msgstr "" #: ../source/guides/using-manifest-in.rst:52 -msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." +msgid "" +"After processing the :file:`MANIFEST.in` file, setuptools removes the :file:" +"`build/` directory as well as any directories named :file:`RCS`, :file:" +"`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file " +"and an :file:`*.egg-info` directory. This behavior cannot be changed with :" +"file:`MANIFEST.in`." msgstr "" #: ../source/guides/using-manifest-in.rst:60 @@ -4325,7 +6344,10 @@ msgid ":file:`MANIFEST.in` commands" msgstr "Команди в :file:`MANIFEST.in`" #: ../source/guides/using-manifest-in.rst:62 -msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" +msgid "" +"A :file:`MANIFEST.in` file consists of commands, one per line, instructing " +"setuptools to add or remove some set of files from the sdist. The commands " +"are:" msgstr "" #: ../source/guides/using-manifest-in.rst:67 @@ -4353,7 +6375,9 @@ msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" msgstr ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" #: ../source/guides/using-manifest-in.rst:71 -msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgid "" +"Add all files under directories matching ``dir-pattern`` that match any of " +"the listed patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:72 @@ -4361,7 +6385,9 @@ msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" msgstr ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" #: ../source/guides/using-manifest-in.rst:72 -msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgid "" +"Remove all files under directories matching ``dir-pattern`` that match any " +"of the listed patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:73 @@ -4369,7 +6395,8 @@ msgid ":samp:`global-include {pat1} {pat2} ...`" msgstr ":samp:`global-include {pat1} {pat2} ...`" #: ../source/guides/using-manifest-in.rst:73 -msgid "Add all files anywhere in the source tree matching any of the listed patterns" +msgid "" +"Add all files anywhere in the source tree matching any of the listed patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:74 @@ -4377,7 +6404,9 @@ msgid ":samp:`global-exclude {pat1} {pat2} ...`" msgstr ":samp:`global-exclude {pat1} {pat2} ...`" #: ../source/guides/using-manifest-in.rst:74 -msgid "Remove all files anywhere in the source tree matching any of the listed patterns" +msgid "" +"Remove all files anywhere in the source tree matching any of the listed " +"patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:75 @@ -4397,27 +6426,54 @@ msgid "Remove all files under directories matching ``dir-pattern``" msgstr "" #: ../source/guides/using-manifest-in.rst:79 -msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." +msgid "" +"The patterns here are glob-style patterns: ``*`` matches zero or more " +"regular filename characters (on Unix, everything except forward slash; on " +"Windows, everything except backslash and colon); ``?`` matches a single " +"regular filename character, and ``[chars]`` matches any one of the " +"characters between the square brackets (which may contain character ranges, " +"e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented " +"support for ``**`` matching zero or more characters including forward slash, " +"backslash, and colon." msgstr "" #: ../source/guides/using-manifest-in.rst:87 -msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." +msgid "" +"Directory patterns are relative to the root of the project directory; e.g., " +"``graft example*`` will include a directory named :file:`examples` in the " +"project root but will not include :file:`docs/examples/`." msgstr "" #: ../source/guides/using-manifest-in.rst:91 -msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." +msgid "" +"File & directory names in :file:`MANIFEST.in` should be ``/``-separated; " +"setuptools will automatically convert the slashes to the local platform's " +"appropriate directory separator." msgstr "" #: ../source/guides/using-manifest-in.rst:95 -msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" +msgid "" +"Commands are processed in the order they appear in the :file:`MANIFEST.in` " +"file. For example, given the commands::" msgstr "" #: ../source/guides/using-manifest-in.rst:101 -msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." +msgid "" +"the contents of the directory tree :file:`tests` will first be added to the " +"sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, " +"or ``.pyd`` extension will be removed from the sdist. If the commands were " +"in the opposite order, then ``*.pyc`` files etc. would be only be removed " +"from what was already in the sdist before adding :file:`tests`, and if :file:" +"`tests` happened to contain any ``*.pyc`` files, they would end up included " +"in the sdist because the exclusion happened before they were included." msgstr "" #: ../source/guides/using-testpypi.rst:7 -msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" +msgid "" +"``TestPyPI`` is a separate instance of the :term:`Python Package Index " +"(PyPI)` that allows you to try out the distribution tools and process " +"without worrying about affecting the real index. TestPyPI is hosted at `test." +"pypi.org `_" msgstr "" #: ../source/guides/using-testpypi.rst:13 @@ -4425,11 +6481,16 @@ msgid "Registering your account" msgstr "" #: ../source/guides/using-testpypi.rst:15 -msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." +msgid "" +"Because TestPyPI has a separate database from the live PyPI, you'll need a " +"separate user account for specifically for TestPyPI. Go to https://test.pypi." +"org/account/register/ to register your account." msgstr "" #: ../source/guides/using-testpypi.rst:19 -msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." +msgid "" +"The database for TestPyPI may be periodically pruned, so it is not unusual " +"for user accounts to be deleted." msgstr "" #: ../source/guides/using-testpypi.rst:24 @@ -4437,11 +6498,17 @@ msgid "Using TestPyPI with Twine" msgstr "" #: ../source/guides/using-testpypi.rst:26 -msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" +msgid "" +"You can upload your distributions to TestPyPI using :ref:`twine` by " +"specifying the ``--repository`` flag" msgstr "" #: ../source/guides/using-testpypi.rst:33 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgid "" +"You can see if your package has successfully uploaded by navigating to the " +"URL ``https://test.pypi.org/project/`` where " +"``sampleproject`` is the name of your project that you uploaded. It may take " +"a minute or two for your project to appear on the site." msgstr "" #: ../source/guides/using-testpypi.rst:39 @@ -4449,11 +6516,16 @@ msgid "Using TestPyPI with pip" msgstr "" #: ../source/guides/using-testpypi.rst:41 -msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" +msgid "" +"You can tell pip to download packages from TestPyPI instead of PyPI by " +"specifying the ``--index-url`` flag" msgstr "" #: ../source/guides/using-testpypi.rst:56 -msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" +msgid "" +"If you want to allow pip to also pull other packages from PyPI you can " +"specify ``--extra-index-url`` to point to PyPI. This is useful when the " +"package you're testing has dependencies:" msgstr "" #: ../source/guides/using-testpypi.rst:73 @@ -4461,16 +6533,19 @@ msgid "Setting up TestPyPI in :file:`.pypirc`" msgstr "" #: ../source/guides/using-testpypi.rst:75 -msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" +msgid "" +"If you want to avoid entering your username, you can configure TestPyPI in " +"your :file:`$HOME/.pypirc`:" msgstr "" -#: ../source/index.rst:3 -#: ../source/key_projects.rst:181 +#: ../source/index.rst:3 ../source/key_projects.rst:181 msgid "Python Packaging User Guide" msgstr "Користувацьке керівництво з пакування Python" #: ../source/index.rst:5 -msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." +msgid "" +"The Python Packaging User Guide (PyPUG) is a collection of tutorials and " +"guides for packaging Python software." msgstr "" #: ../source/index.rst:5 @@ -4478,11 +6553,16 @@ msgid "python, packaging, guide, tutorial" msgstr "" #: ../source/index.rst:24 -msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." +msgid "" +"Welcome to the *Python Packaging User Guide*, a collection of tutorials and " +"references to help you distribute and install Python packages with modern " +"tools." msgstr "" #: ../source/index.rst:28 -msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" +msgid "" +"This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. " +"We happily accept any :doc:`contributions and feedback `. 😊" msgstr "" #: ../source/index.rst:36 @@ -4490,23 +6570,34 @@ msgid "Get started" msgstr "" #: ../source/index.rst:38 -msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" +msgid "" +"Essential tools and concepts for working within the Python development " +"ecosystem are covered in our :doc:`tutorials/index` section:" msgstr "" #: ../source/index.rst:41 -msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" +msgid "" +"To learn how to install packages, see the :doc:`tutorial on installing " +"packages `" msgstr "" #: ../source/index.rst:43 -msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" +msgid "" +"To learn how to manage dependencies in a version controlled project, see " +"the :doc:`tutorial on managing application dependencies `" msgstr "" #: ../source/index.rst:45 -msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" +msgid "" +"To learn how to package and distribute your projects, see the :doc:`tutorial " +"on packaging and distributing `" msgstr "" #: ../source/index.rst:47 -msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" +msgid "" +"To get an overview of packaging options for Python libraries and " +"applications, see the :doc:`Overview of Python Packaging `" msgstr "" #: ../source/index.rst:52 @@ -4514,23 +6605,33 @@ msgid "Learn more" msgstr "Дізнатися більше" #: ../source/index.rst:54 -msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" +msgid "" +"Beyond our :doc:`tutorials/index`, this guide has several other resources:" msgstr "" #: ../source/index.rst:56 -msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." +msgid "" +"The :doc:`guides/index` section for walk throughs, such as :doc:`guides/" +"installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." msgstr "" #: ../source/index.rst:58 -msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." +msgid "" +"The :doc:`discussions/index` section for in-depth references on topics such " +"as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-" +"vs-easy-install`." msgstr "" #: ../source/index.rst:60 -msgid "The :doc:`specifications/index` section for packaging interoperability specifications." +msgid "" +"The :doc:`specifications/index` section for packaging interoperability " +"specifications." msgstr "" #: ../source/index.rst:62 -msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." +msgid "" +"Additionally, there is a list of :doc:`other projects ` " +"maintained by members of the Python Packaging Authority." msgstr "" #: ../source/key_projects.rst:6 @@ -4538,7 +6639,9 @@ msgid "Project Summaries" msgstr "" #: ../source/key_projects.rst:8 -msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." +msgid "" +"Summaries and links for the most relevant projects in the space of Python " +"installation and packaging." msgstr "" #: ../source/key_projects.rst:14 @@ -4550,11 +6653,18 @@ msgid "bandersnatch" msgstr "bandersnatch" #: ../source/key_projects.rst:21 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:25 -msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." +msgid "" +"``bandersnatch`` is a PyPI mirroring client designed to efficiently create a " +"complete mirror of the contents of PyPI. Organizations thus save bandwidth " +"and latency on package downloads (especially in the context of automated " +"tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." msgstr "" #: ../source/key_projects.rst:35 @@ -4562,11 +6672,16 @@ msgid "build" msgstr "build" #: ../source/key_projects.rst:37 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI " +"`__" msgstr "" #: ../source/key_projects.rst:42 -msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." +msgid "" +"``build`` is a :pep:`517` compatible Python package builder. It provides a " +"CLI to build packages, as well as a Python API." msgstr "" #: ../source/key_projects.rst:49 @@ -4574,11 +6689,19 @@ msgid "cibuildwheel" msgstr "cibuildwheel" #: ../source/key_projects.rst:51 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | " +"`Discussions `__ | " +"`Discord #cibuildwheel `__" msgstr "" #: ../source/key_projects.rst:58 -msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." +msgid "" +"``cibuildwheel`` is a Python package that builds :term:`wheels ` for " +"all common platforms and Python versions on most CI systems. Also see :ref:" +"`multibuild`." msgstr "" #: ../source/key_projects.rst:64 @@ -4586,15 +6709,31 @@ msgid "distlib" msgstr "distlib" #: ../source/key_projects.rst:66 -msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:71 -msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." +msgid "" +"``distlib`` is a library which implements low-level functions that relate to " +"packaging and distribution of Python software. ``distlib`` implements " +"several relevant PEPs (Python Enhancement Proposal standards) and is useful " +"for developers of third-party packaging tools to make and upload binary and " +"source :term:`distributions `, achieve " +"interoperability, resolve dependencies, manage package resources, and do " +"other similar functions." msgstr "" #: ../source/key_projects.rst:80 -msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." +msgid "" +"Unlike the stricter :ref:`packaging` project (below), which specifically " +"implements modern Python packaging interoperability standards, ``distlib`` " +"also attempts to provide reasonable fallback behaviours when asked to handle " +"legacy packages and metadata that predate the modern interoperability " +"standards and fall into the subset of packages that are incompatible with " +"those standards." msgstr "" #: ../source/key_projects.rst:90 @@ -4602,19 +6741,36 @@ msgid "packaging" msgstr "packaging" #: ../source/key_projects.rst:92 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:97 -msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." +msgid "" +"Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." msgstr "" #: ../source/key_projects.rst:99 -msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." +msgid "" +"The core utilities in the packaging library handle version handling, " +"specifiers, markers, requirements, tags, and similar attributes and tasks " +"for Python packages. Most Python users rely on this library without needing " +"to explicitly call it; developers of the other Python packaging, " +"distribution, and installation tools listed here often use its functionality " +"to parse, discover, and otherwise handle dependency attributes." msgstr "" #: ../source/key_projects.rst:107 -msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." +msgid "" +"This project specifically focuses on implementing the modern Python " +"packaging interoperability standards defined at :ref:`packaging-" +"specifications`, and will report errors for sufficiently old legacy packages " +"that are incompatible with those standards. In contrast, the :ref:`distlib` " +"project is a more permissive library that attempts to provide a plausible " +"reading of ambiguous metadata in cases where :ref:`packaging` will instead " +"report on error." msgstr "" #: ../source/key_projects.rst:119 @@ -4623,15 +6779,24 @@ msgid "pip" msgstr "pip" #: ../source/key_projects.rst:121 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:126 -msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." +msgid "" +"The most popular tool for installing Python packages, and the one included " +"with modern versions of Python." msgstr "" #: ../source/key_projects.rst:129 -msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." +msgid "" +"It provides the essential core features for finding, downloading, and " +"installing packages from PyPI and other Python package indexes, and can be " +"incorporated into a wide range of development workflows via its command-line " +"interface (CLI)." msgstr "" #: ../source/key_projects.rst:137 @@ -4639,15 +6804,28 @@ msgid "Pipenv" msgstr "Pipenv" #: ../source/key_projects.rst:139 -msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Source `__ | `Issues `__ | `PyPI " +"`__" msgstr "" #: ../source/key_projects.rst:144 -msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." +msgid "" +"Pipenv is a project that aims to bring the best of all packaging worlds to " +"the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:" +"`virtualenv` into one single toolchain. It features very pretty terminal " +"colors." msgstr "" #: ../source/key_projects.rst:148 -msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." +msgid "" +"Pipenv aims to help users manage environments, dependencies, and imported " +"packages on the command line. It also works well on Windows (which other " +"tools often underserve), makes and checkes file hashes, to ensure compliance " +"with hash-locked dependency specifiers, and eases uninstallation of packages " +"and dependencies. It is used by Python users and system administrators, but " +"has been less maintained since late 2018." msgstr "" #: ../source/key_projects.rst:159 @@ -4659,7 +6837,10 @@ msgid "`Source `__" msgstr "" #: ../source/key_projects.rst:163 -msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." +msgid "" +":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level " +"application-centric alternative to :ref:`pip`'s lower-level :file:" +"`requirements.txt` file." msgstr "" #: ../source/key_projects.rst:170 @@ -4667,15 +6848,22 @@ msgid "pipx" msgstr "pipx" #: ../source/key_projects.rst:172 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:176 -msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." +msgid "" +"pipx is a tool to install and run Python command-line applications without " +"causing dependency conflicts with other packages installed on the system." msgstr "" #: ../source/key_projects.rst:183 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:187 @@ -4687,11 +6875,18 @@ msgid "readme_renderer" msgstr "readme_renderer" #: ../source/key_projects.rst:194 -msgid "`GitHub and docs `__ | `PyPI `__" +msgid "" +"`GitHub and docs `__ | `PyPI " +"`__" msgstr "" #: ../source/key_projects.rst:197 -msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." +msgid "" +"``readme_renderer`` is a library that package developers use to render their " +"user documentation (README) files into HTML from markup languages such as " +"Markdown or reStructuredText. Developers call it on its own or via :ref:" +"`twine`, as part of their release management process, to check that their " +"package descriptions will properly display on PyPI." msgstr "" #: ../source/key_projects.rst:208 @@ -4699,15 +6894,24 @@ msgid "setuptools" msgstr "setuptools" #: ../source/key_projects.rst:210 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:215 -msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." +msgid "" +"setuptools (which includes ``easy_install``) is a collection of enhancements " +"to the Python distutils that allow you to more easily build and distribute " +"Python :term:`distributions `, especially ones that " +"have dependencies on other packages." msgstr "" #: ../source/key_projects.rst:220 -msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." +msgid "" +"`distribute`_ was a fork of setuptools that was merged back into setuptools " +"(in v0.7), thereby making setuptools the primary choice for Python packaging." msgstr "" #: ../source/key_projects.rst:227 @@ -4715,15 +6919,32 @@ msgid "trove-classifiers" msgstr "trove-classifiers" #: ../source/key_projects.rst:229 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Issues `__ | `GitHub " +"`__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:233 -msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." +msgid "" +"trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically " +"describe their projects `_ so that users can better find projects " +"that match their needs on the PyPI." msgstr "" #: ../source/key_projects.rst:239 -msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." +msgid "" +"The trove-classifiers package contains a list of valid classifiers and " +"deprecated classifiers (which are paired with the classifiers that replace " +"them). Use this package to validate classifiers used in packages intended " +"for uploading to PyPI. As this list of classifiers is published as code, you " +"can install and import it, giving you a more convenient workflow compared to " +"referring to the `list published on PyPI `_. " +"The `issue tracker `_ for " +"the project hosts discussions on proposed classifiers and requests for new " +"classifiers." msgstr "" #: ../source/key_projects.rst:253 @@ -4731,24 +6952,41 @@ msgid "twine" msgstr "twine" #: ../source/key_projects.rst:255 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:260 -msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." +msgid "" +"Twine is the primary tool developers use to upload packages to the Python " +"Package Index or other Python package indexes. It is a command-line program " +"that passes program files and metadata to a web API. Developers use it " +"because it's the official PyPI upload tool, it's fast and secure, it's " +"maintained, and it reliably works." msgstr "" -#: ../source/key_projects.rst:270 -#: ../source/overview.rst:415 +#: ../source/key_projects.rst:270 ../source/overview.rst:415 msgid "virtualenv" msgstr "virtualenv" #: ../source/key_projects.rst:272 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:277 -msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgid "" +"virtualenv is a tool which uses the command-line path environment variable " +"to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional " +"functionality, compared to :ref:`venv`, by supporting Python 2.7 and by " +"providing convenient features for configuring, maintaining, duplicating, and " +"troubleshooting the virtual environments. For more information, see the " +"section on :ref:`Creating and using Virtual Environments`." msgstr "" #: ../source/key_projects.rst:290 @@ -4756,11 +6994,16 @@ msgid "Warehouse" msgstr "Warehouse" #: ../source/key_projects.rst:292 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:296 -msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." +msgid "" +"The current codebase powering the :term:`Python Package Index (PyPI)`. It is " +"hosted at `pypi.org `_. The default source for :ref:`pip` " +"downloads." msgstr "" #: ../source/key_projects.rst:304 @@ -4768,15 +7011,26 @@ msgid "wheel" msgstr "wheel" #: ../source/key_projects.rst:306 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:311 -msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." +msgid "" +"Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` " +"extension for creating :term:`wheel distributions `. Additionally, " +"it offers its own command line utility for creating and installing wheels." msgstr "" #: ../source/key_projects.rst:315 -msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." +msgid "" +"See also `auditwheel `__, a tool that " +"package developers use to check and fix Python packages they are making in " +"the binary wheel format. It provides functionality to discover dependencies, " +"check metadata for compliance, and repair the wheel and metadata to properly " +"link and include external shared libraries in a package." msgstr "" #: ../source/key_projects.rst:324 @@ -4788,11 +7042,17 @@ msgid "bento" msgstr "bento" #: ../source/key_projects.rst:331 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:336 -msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." +msgid "" +"Bento is a packaging tool solution for Python software, targeted as an " +"alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's " +"philosophy is reproducibility, extensibility and simplicity (in that order)." msgstr "" #: ../source/key_projects.rst:344 @@ -4800,11 +7060,18 @@ msgid "buildout" msgstr "buildout" #: ../source/key_projects.rst:346 -msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" +msgid "" +"`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:351 -msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." +msgid "" +"Buildout is a Python-based build system for creating, assembling and " +"deploying applications from multiple parts, some of which may be non-Python-" +"based. It lets you create a buildout configuration and reproduce the same " +"software later." msgstr "" #: ../source/key_projects.rst:358 @@ -4816,15 +7083,32 @@ msgid "`Docs `__" msgstr "" #: ../source/key_projects.rst:362 -msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." +msgid "" +"conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution " +"from `Anaconda, Inc `__ specifically " +"aimed at the scientific community, and in particular on Windows where the " +"installation of binary extensions is often difficult." msgstr "" #: ../source/key_projects.rst:369 -msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." +msgid "" +"Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, " +"but provides many of their combined features in terms of package management, " +"virtual environment management and deployment of binary extensions." msgstr "" #: ../source/key_projects.rst:373 -msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." +msgid "" +"Conda does not install packages from PyPI and can install only from the " +"official Anaconda repositories, or anaconda.org (a place for user-" +"contributed *conda* packages), or a local (e.g. intranet) package server. " +"However, note that :ref:`pip` can be installed into, and work side-by-side " +"with conda for managing :term:`distributions ` from " +"PyPI. Also, `conda skeleton `__ is a tool to make " +"Python packages installable by conda by first fetching them from PyPI and " +"modifying their metadata." msgstr "" #: ../source/key_projects.rst:386 @@ -4832,11 +7116,17 @@ msgid "devpi" msgstr "devpi" #: ../source/key_projects.rst:388 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:392 -msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." +msgid "" +"devpi features a powerful PyPI-compatible server and PyPI proxy cache with a " +"complementary command line tool to drive packaging, testing and release " +"activities with Python. devpi also provides a browsable and searchable web " +"interface." msgstr "" #: ../source/key_projects.rst:401 @@ -4844,15 +7134,25 @@ msgid "flit" msgstr "flit" #: ../source/key_projects.rst:403 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:407 -msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." +msgid "" +"Flit provides a simple way to upload pure Python packages and modules to " +"PyPI. It focuses on `making the easy things easy `_ for " +"packaging. Flit can generate a configuration file to quickly set up a simple " +"project, build source distributions and wheels, and upload them to PyPI." msgstr "" #: ../source/key_projects.rst:412 -msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." +msgid "" +"Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on " +"tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to " +"upload them to PyPI. Flit requires Python 3, but you can use it to " +"distribute modules for Python 2, so long as they can be imported on Python 3." msgstr "" #: ../source/key_projects.rst:422 @@ -4860,11 +7160,22 @@ msgid "enscons" msgstr "enscons" #: ../source/key_projects.rst:424 -msgid "`Source `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Source `__ | `Issues `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:428 -msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." +msgid "" +"Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-" +"compatible source distributions and wheels without using distutils or " +"setuptools, including distributions with C extensions. Enscons has a " +"different architecture and philosophy than :ref:`distutils`. Rather than " +"adding build features to a Python packaging system, enscons adds Python " +"packaging to a general purpose build system. Enscons helps you to build " +"sdists that can be automatically built by :ref:`pip`, and wheels that are " +"independent of enscons." msgstr "" #: ../source/key_projects.rst:443 @@ -4872,11 +7183,20 @@ msgid "Hashdist" msgstr "Hashdist" #: ../source/key_projects.rst:445 -msgid "`Docs `__ | `GitHub `__" +msgid "" +"`Docs `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:448 -msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." +msgid "" +"Hashdist is a library for building non-root software distributions. Hashdist " +"is trying to be “the Debian of choice for cases where Debian technology " +"doesn’t work”. The best way for Pythonistas to think about Hashdist may be a " +"more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed " +"at solving the problem of installing scientific software, and making package " +"distribution stateless, cached, and branchable. It is used by some " +"researchers but has been lacking in maintenance since 2016." msgstr "" #: ../source/key_projects.rst:460 @@ -4884,11 +7204,18 @@ msgid "hatch" msgstr "hatch" #: ../source/key_projects.rst:462 -msgid "`GitHub and Docs `__ | `PyPI `__" +msgid "" +"`GitHub and Docs `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:465 -msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." +msgid "" +"Hatch is a unified command-line tool meant to conveniently manage " +"dependencies and environment isolation for Python developers. Python package " +"developers use Hatch to configure, version, specify dependencies for, and " +"publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload " +"packages to PyPI, and :ref:`pip` to download and install packages." msgstr "" #: ../source/key_projects.rst:475 @@ -4900,7 +7227,10 @@ msgid "`GitHub `__" msgstr "" #: ../source/key_projects.rst:479 -msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." +msgid "" +"Multibuild is a set of CI scripts for building and testing Python :term:" +"`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :" +"ref:`cibuildwheel`." msgstr "" #: ../source/key_projects.rst:485 @@ -4908,11 +7238,18 @@ msgid "pex" msgstr "pex" #: ../source/key_projects.rst:487 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:491 -msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." +msgid "" +"pex is both a library and tool for generating :file:`.pex` (Python " +"EXecutable) files, standalone Python environments in the spirit of :ref:" +"`virtualenv`. :file:`.pex` files are just carefully constructed zip files " +"with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are " +"designed to make deployment of Python applications as simple as ``cp``." msgstr "" #: ../source/key_projects.rst:500 @@ -4920,11 +7257,20 @@ msgid "pip-tools" msgstr "pip-tools" #: ../source/key_projects.rst:502 -msgid "`GitHub and Docs `__ | `PyPI `__" +msgid "" +"`GitHub and Docs `__ | `PyPI " +"`__" msgstr "" #: ../source/key_projects.rst:505 -msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." +msgid "" +"pip-tools is a suite of tools meant for Python system administrators and " +"release managers who particularly want to keep their builds deterministic " +"yet stay up to date with new versions of their dependencies. Users can " +"specify particular release of their dependencies via hash, conveniently make " +"a properly formatted list of requirements from information in other parts of " +"their program, update all dependencies (a feature :ref:`pip` currently does " +"not provide), and create layers of constraints for the program to obey." msgstr "" #: ../source/key_projects.rst:517 @@ -4932,11 +7278,17 @@ msgid "piwheels" msgstr "piwheels" #: ../source/key_projects.rst:519 -msgid "`Website `__ | `Docs `__ | `GitHub `__" +msgid "" +"`Website `__ | `Docs `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:523 -msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." +msgid "" +"piwheels is a website, and software underpinning it, that fetches source " +"code distribution packages from PyPI and compiles them into binary wheels " +"that are optimized for installation onto Raspberry Pi computers. Raspberry " +"Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." msgstr "" #: ../source/key_projects.rst:532 @@ -4944,11 +7296,19 @@ msgid "poetry" msgstr "poetry" #: ../source/key_projects.rst:534 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:538 -msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." +msgid "" +"poetry is a command-line tool to handle dependency installation and " +"isolation as well as building and packaging of Python packages. It uses " +"``pyproject.toml`` and, instead of depending on the resolver functionality " +"within :ref:`pip`, provides its own dependency resolver. It attempts to " +"speed users' experience of installation and dependency resolution by locally " +"caching metadata about dependencies." msgstr "" #: ../source/key_projects.rst:548 @@ -4956,11 +7316,20 @@ msgid "pypiserver" msgstr "pypiserver" #: ../source/key_projects.rst:550 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | " +"`GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:554 -msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." +msgid "" +"pypiserver is a minimalist application that serves as a private Python " +"package index within organizations, implementing a simple API and browser " +"interface. You can upload private packages using standard upload tools, and " +"users can download and install them with :ref:`pip`, without publishing them " +"publicly. Organizations who use pypiserver usually download packages both " +"from pypiserver and from PyPI." msgstr "" #: ../source/key_projects.rst:564 @@ -4968,11 +7337,22 @@ msgid "scikit-build" msgstr "scikit-build" #: ../source/key_projects.rst:566 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:570 -msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." +msgid "" +"Scikit-build is an improved build system generator for CPython C/C++/Fortran/" +"Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :" +"ref:`pip`. It internally uses `cmake `__ " +"(available on PyPI) to provide better support for additional compilers, " +"build systems, cross compilation, and locating dependencies and their " +"associated build requirements. To speed up and parallelize the build of " +"large projects, the user can install `ninja `__ (also available on PyPI)." msgstr "" #: ../source/key_projects.rst:582 @@ -4980,23 +7360,42 @@ msgid "shiv" msgstr "shiv" #: ../source/key_projects.rst:584 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:588 -msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." +msgid "" +"shiv is a command line utility for building fully self contained Python " +"zipapps as outlined in :pep:`441`, but with all their dependencies included. " +"Its primary goal is making distributing Python applications and command line " +"tools fast & easy." msgstr "" #: ../source/key_projects.rst:598 -msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" +msgid "" +"`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" msgstr "" #: ../source/key_projects.rst:603 -msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." +msgid "" +"A flexible package manager designed to support multiple versions, " +"configurations, platforms, and compilers. Spack is like Homebrew, but " +"packages are written in Python and parameterized to allow easy swapping of " +"compilers, library versions, build options, etc. Arbitrarily many versions " +"of packages can coexist on the same system. Spack was designed for rapidly " +"building high performance scientific applications on clusters and " +"supercomputers." msgstr "" #: ../source/key_projects.rst:611 -msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." +msgid "" +"Spack is not in PyPI (yet), but it requires no installation and can be used " +"immediately after cloning from GitHub." msgstr "" #: ../source/key_projects.rst:617 @@ -5004,11 +7403,18 @@ msgid "zest.releaser" msgstr "zest.releaser" #: ../source/key_projects.rst:619 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:623 -msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." +msgid "" +"``zest.releaser`` is a Python package release tool providing an abstraction " +"layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to " +"automate incrementing package version numbers, updating changelogs, tagging " +"releases in source control, and uploading new packages to PyPI." msgstr "" #: ../source/key_projects.rst:630 @@ -5020,11 +7426,17 @@ msgid "ensurepip" msgstr "ensurepip" #: ../source/key_projects.rst:637 -msgid "`Docs `__ | `Issues `__" +msgid "" +"`Docs `__ | `Issues " +"`__" msgstr "" #: ../source/key_projects.rst:640 -msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." +msgid "" +"A package in the Python Standard Library that provides support for " +"bootstrapping :ref:`pip` into an existing Python installation or virtual " +"environment. In most cases, end users won't use this module, but rather it " +"will be used during the build of the Python distribution." msgstr "" #: ../source/key_projects.rst:649 @@ -5032,15 +7444,26 @@ msgid "distutils" msgstr "distutils" #: ../source/key_projects.rst:651 -msgid "`Docs `__ | `Issues `__" +msgid "" +"`Docs `__ | `Issues " +"`__" msgstr "" #: ../source/key_projects.rst:654 -msgid "The original Python packaging system, added to the standard library in Python 2.0." +msgid "" +"The original Python packaging system, added to the standard library in " +"Python 2.0." msgstr "" #: ../source/key_projects.rst:657 -msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." +msgid "" +"Due to the challenges of maintaining a packaging system where feature " +"updates are tightly coupled to language runtime updates, direct usage of :" +"ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being " +"the preferred replacement. :ref:`Setuptools` not only provides features that " +"plain :ref:`distutils` doesn't offer (such as dependency declarations and " +"entry point declarations), it also provides a consistent build interface and " +"feature set across all supported Python versions." msgstr "" #: ../source/key_projects.rst:670 @@ -5048,11 +7471,17 @@ msgid "venv" msgstr "venv" #: ../source/key_projects.rst:672 -msgid "`Docs `__ | `Issues `__" +msgid "" +"`Docs `__ | `Issues `__" msgstr "" #: ../source/key_projects.rst:675 -msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgid "" +"A package in the Python Standard Library (starting with Python 3.3) for " +"creating :term:`Virtual Environments `. For more " +"information, see the section on :ref:`Creating and using Virtual " +"Environments`." msgstr "" #: ../source/news.rst:2 @@ -5124,7 +7553,8 @@ msgid "April 2019" msgstr "квітень 2019" #: ../source/news.rst:31 -msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" +msgid "" +"Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" msgstr "" #: ../source/news.rst:32 @@ -5148,7 +7578,9 @@ msgid "February 2019" msgstr "лютий 2019" #: ../source/news.rst:41 -msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" +msgid "" +"Elaborate upon the differences between the tutorial and the real packaging " +"process. (:pr:`602`)" msgstr "" #: ../source/news.rst:42 @@ -5232,7 +7664,8 @@ msgid "Replaced tar command with working command. (:pr:`552`)" msgstr "" #: ../source/news.rst:72 -msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" +msgid "" +"Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" msgstr "" #: ../source/news.rst:75 @@ -5244,7 +7677,8 @@ msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" msgstr "" #: ../source/news.rst:77 -msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" +msgid "" +"Moved the Overview to a task based lead in along with the others. (:pr:`540`)" msgstr "" #: ../source/news.rst:78 @@ -5288,7 +7722,8 @@ msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" msgstr "" #: ../source/news.rst:97 -msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" +msgid "" +"Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" msgstr "" #: ../source/news.rst:98 @@ -5352,7 +7787,8 @@ msgid "Updated \"installing scientific packages\". (:pr:`455`)" msgstr "" #: ../source/news.rst:119 -msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" +msgid "" +"Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" msgstr "" #: ../source/news.rst:120 @@ -5368,7 +7804,9 @@ msgid "February 2018" msgstr "лютий 2018" #: ../source/news.rst:126 -msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" +msgid "" +"Added python3-venv and python3-pip to Debian installation instructions. (:pr:" +"`445`)" msgstr "" #: ../source/news.rst:127 @@ -5376,7 +7814,8 @@ msgid "Updated PyPI migration info. (:pr:`439`)" msgstr "" #: ../source/news.rst:128 -msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" +msgid "" +"Added a warning about managing multiple versions with pipenv. (:pr:`430`)" msgstr "" #: ../source/news.rst:129 @@ -5404,7 +7843,8 @@ msgid "December 2017" msgstr "грудень 2017" #: ../source/news.rst:141 -msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" +msgid "" +"Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" msgstr "" #: ../source/news.rst:142 @@ -5424,15 +7864,20 @@ msgid "November 2017" msgstr "листопад 2017" #: ../source/news.rst:149 -msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" +msgid "" +"Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" msgstr "" #: ../source/news.rst:150 -msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" +msgid "" +"Updated the *Single Sourcing Package Version* tutorial to reflect pip's " +"current strategy. (:pr:`400`)" msgstr "" #: ../source/news.rst:152 -msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" +msgid "" +"Added documentation about the ``py_modules`` argument to ``setup``. (:pr:" +"`398`)" msgstr "" #: ../source/news.rst:153 @@ -5444,11 +7889,14 @@ msgid "October 2017" msgstr "жовтень 2017" #: ../source/news.rst:158 -msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" +msgid "" +"Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" msgstr "" #: ../source/news.rst:159 -msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" +msgid "" +"Created a new guide for managing packages using ``pip`` and ``virtualenv``. " +"(:pr:`385`)" msgstr "" #: ../source/news.rst:160 @@ -5460,7 +7908,9 @@ msgid "September 2017" msgstr "вересень 2017" #: ../source/news.rst:165 -msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" +msgid "" +"Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:" +"`379`)" msgstr "" #: ../source/news.rst:167 @@ -5472,7 +7922,9 @@ msgid "August 2017" msgstr "серпень 2017" #: ../source/news.rst:172 -msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" +msgid "" +"Added a new, experimental tutorial on installing packages using ``Pipenv``. " +"(:pr:`369`)" msgstr "" #: ../source/news.rst:173 @@ -5496,15 +7948,20 @@ msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" msgstr "" #: ../source/news.rst:181 -msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" +msgid "" +"Updated this guide's ``readme`` with instructions on how to build the guide " +"locally. (:pr:`356`)" msgstr "" #: ../source/news.rst:182 -msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" +msgid "" +"Made the new ``TestPyPI`` URL more visible, adding note to homepage about " +"pypi.org. (:pr:`354`)" msgstr "" #: ../source/news.rst:183 -msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" +msgid "" +"Added a note about the removal of the explicit registration API. (:pr:`347`)" msgstr "" #: ../source/news.rst:186 @@ -5520,11 +7977,14 @@ msgid "Added documentation for ``python_requires``. (:pr:`338`)" msgstr "" #: ../source/news.rst:190 -msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" +msgid "" +"Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:" +"pr:`335`)" msgstr "" #: ../source/news.rst:191 -msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" +msgid "" +"Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" msgstr "" #: ../source/news.rst:192 @@ -5556,7 +8016,8 @@ msgid "May 2017" msgstr "травень 2017" #: ../source/news.rst:202 -msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" +msgid "" +"Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" msgstr "" #: ../source/news.rst:203 @@ -5564,7 +8025,9 @@ msgid "Added contributor and style guide. (:pr:`307`)" msgstr "" #: ../source/news.rst:204 -msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" +msgid "" +"Documented ``pip`` and ``easy_install``'s differences for per-project " +"indexes. (:pr:`233`)" msgstr "" #: ../source/news.rst:207 @@ -5576,11 +8039,15 @@ msgid "Added travis configuration for testing pull requests. (:pr:`300`)" msgstr "" #: ../source/news.rst:210 -msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" +msgid "" +"Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:" +"`299`)" msgstr "" #: ../source/news.rst:211 -msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" +msgid "" +"Removed the ``twine register`` reference in the *Distributing Packages* " +"tutorial. (:pr:`271`)" msgstr "" #: ../source/news.rst:212 @@ -5592,23 +8059,33 @@ msgid "Added a topic on namespace packages. (:pr:`290`)" msgstr "" #: ../source/news.rst:214 -msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" +msgid "" +"Added documentation explaining prominently how to install ``pip`` in ``/usr/" +"local``. (:pr:`230`)" msgstr "" #: ../source/news.rst:215 -msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" +msgid "" +"Updated development mode documentation to mention that order of local " +"packages matters. (:pr:`208`)" msgstr "" #: ../source/news.rst:216 -msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" +msgid "" +"Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted " +"projects (:pr:`239`)" msgstr "" #: ../source/news.rst:217 -msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" +msgid "" +"Swaped order of :file:`setup.py` arguments for the upload command, as order " +"is significant. (:pr:`260`)" msgstr "" #: ../source/news.rst:219 -msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" +msgid "" +"Explained how to install from unsupported sources using a helper " +"application. (:pr:`289`)" msgstr "" #: ../source/news.rst:223 @@ -5632,15 +8109,26 @@ msgid "An Overview of Packaging for Python" msgstr "" #: ../source/overview.rst:7 -msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." +msgid "" +"As a general-purpose programming language, Python is designed to be used in " +"many ways. You can build web sites or industrial robots or a game for your " +"friends to play, and much more, all using the same core technology." msgstr "" #: ../source/overview.rst:12 -msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." +msgid "" +"Python's flexibility is why the first step in every Python project must be " +"to think about the project's audience and the corresponding environment " +"where the project will run. It might seem strange to think about packaging " +"before writing code, but this process does wonders for avoiding future " +"headaches." msgstr "" #: ../source/overview.rst:18 -msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." +msgid "" +"This overview provides a general-purpose decision tree for reasoning about " +"Python's plethora of packaging options. Read on to choose the best " +"technology for your next project." msgstr "" #: ../source/overview.rst:26 @@ -5648,23 +8136,36 @@ msgid "Thinking about deployment" msgstr "" #: ../source/overview.rst:28 -msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" +msgid "" +"Packages exist to be installed (or *deployed*), so before you package " +"anything, you'll want to have some answers to the deployment questions below:" msgstr "" #: ../source/overview.rst:32 -msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" +msgid "" +"Who are your software's users? Will your software be installed by other " +"developers doing software development, operations people in a datacenter, or " +"a less software-savvy group?" msgstr "" #: ../source/overview.rst:35 -msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" +msgid "" +"Is your software intended to run on servers, desktops, mobile clients " +"(phones, tablets, etc.), or embedded in dedicated devices?" msgstr "" #: ../source/overview.rst:37 -msgid "Is your software installed individually, or in large deployment batches?" +msgid "" +"Is your software installed individually, or in large deployment batches?" msgstr "" #: ../source/overview.rst:39 -msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." +msgid "" +"Packaging is all about target environment and deployment experience. There " +"are many answers to the questions above and each combination of " +"circumstances has its own solutions. With this information, the following " +"overview will guide you to the packaging technologies best suited to your " +"project." msgstr "" #: ../source/overview.rst:46 @@ -5672,11 +8173,19 @@ msgid "Packaging Python libraries and tools" msgstr "" #: ../source/overview.rst:48 -msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." +msgid "" +"You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are " +"just a few of the tools Python's ecosystem provides for distributing Python " +"code to developers, which you can read about in :doc:`guides/distributing-" +"packages-using-setuptools`." msgstr "" #: ../source/overview.rst:53 -msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." +msgid "" +"The following approaches to packaging are meant for libraries and tools used " +"by technical audience in a development setting. If you're looking for ways " +"to package Python for a non-technical audience and/or a production setting, " +"skip ahead to :ref:`packaging-applications`." msgstr "" #: ../source/overview.rst:59 @@ -5684,15 +8193,27 @@ msgid "Python modules" msgstr "" #: ../source/overview.rst:61 -msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." +msgid "" +"A Python file, provided it only relies on the standard library, can be " +"redistributed and reused. You will also need to ensure it's written for the " +"right version of Python, and only relies on the standard library." msgstr "" #: ../source/overview.rst:66 -msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." +msgid "" +"This is great for sharing simple scripts and snippets between people who " +"both have compatible Python versions (such as via email, StackOverflow, or " +"GitHub gists). There are even some entire Python libraries that offer this " +"as an option, such as `bottle.py `_ and " +"`boltons `_." msgstr "" #: ../source/overview.rst:73 -msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." +msgid "" +"However, this pattern won't scale for projects that consist of multiple " +"files, need additional libraries, or need a specific version of Python, " +"hence the options below." msgstr "" #: ../source/overview.rst:78 @@ -5700,31 +8221,60 @@ msgid "Python source distributions" msgstr "" #: ../source/overview.rst:80 -msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." +msgid "" +"If your code consists of multiple Python files, it's usually organized into " +"a directory structure. Any directory containing Python files can comprise " +"an :term:`Import Package`." msgstr "" #: ../source/overview.rst:84 -msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." +msgid "" +"Because packages consist of multiple files, they are harder to distribute. " +"Most protocols support transferring only one file at a time (when was the " +"last time you clicked a link and it downloaded multiple files?). It's easier " +"to get incomplete transfers, and harder to guarantee code integrity at the " +"destination." msgstr "" #: ../source/overview.rst:90 -msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." +msgid "" +"So long as your code contains nothing but pure Python code, and you know " +"your deployment environment supports your version of Python, then you can " +"use Python's native packaging tools to create a *source* :term:`Distribution " +"Package`, or *sdist* for short." msgstr "" #: ../source/overview.rst:95 -msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." +msgid "" +"Python's *sdists* are compressed archives (``.tar.gz`` files) containing one " +"or more packages or modules. If your code is pure-Python, and you only " +"depend on other Python packages, you can `go here to learn more `_." msgstr "" #: ../source/overview.rst:100 -msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." +msgid "" +"If you rely on any non-Python code, or non-Python packages (such as `libxml2 " +"`_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next " +"section, which also has many advantages for pure-Python libraries." msgstr "" #: ../source/overview.rst:107 -msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" +msgid "" +"Python and PyPI support multiple distributions providing different " +"implementations of the same package. For instance the unmaintained-but-" +"seminal `PIL distribution `_ provides the PIL " +"package, and so does `Pillow `_, an " +"actively-maintained fork of PIL!" msgstr "" #: ../source/overview.rst:114 -msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." +msgid "" +"This Python packaging superpower makes it possible for Pillow to be a drop-" +"in replacement for PIL, just by changing your project's ``install_requires`` " +"or ``requirements.txt``." msgstr "" #: ../source/overview.rst:119 @@ -5732,23 +8282,43 @@ msgid "Python binary distributions" msgstr "" #: ../source/overview.rst:121 -msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." +msgid "" +"So much of Python's practical power comes from its ability to integrate with " +"the software ecosystem, in particular libraries written in C, C++, Fortran, " +"Rust, and other languages." msgstr "" #: ../source/overview.rst:125 -msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." +msgid "" +"Not all developers have the right tools or experiences to build these " +"components written in these compiled languages, so Python created the :term:" +"`Wheel`, a package format designed to ship libraries with compiled " +"artifacts. In fact, Python's package installer, ``pip``, always prefers " +"wheels because installation is always faster, so even pure-Python packages " +"work better with wheels." msgstr "" #: ../source/overview.rst:132 -msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." +msgid "" +"Binary distributions are best when they come with source distributions to " +"match. Even if you don't upload wheels of your code for every operating " +"system, by uploading the sdist, you're enabling users of other platforms to " +"still build it for themselves. Default to publishing both sdist and wheel " +"archives together, *unless* you're creating artifacts for a very specific " +"use case where you know the recipient only needs one or the other." msgstr "" #: ../source/overview.rst:140 -msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." +msgid "" +"Python and PyPI make it easy to upload both wheels and sdists together. Just " +"follow the :doc:`tutorials/packaging-projects` tutorial." msgstr "" #: ../source/overview.rst:148 -msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." +msgid "" +"Python's recommended built-in library and tool packaging technologies. " +"Excerpted from `The Packaging Gradient (2017) `_." msgstr "" #: ../source/overview.rst:155 @@ -5756,23 +8326,39 @@ msgid "Packaging Python applications" msgstr "" #: ../source/overview.rst:157 -msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." +msgid "" +"So far we've only discussed Python's native distribution tools. Based on our " +"introduction, you would be correct to infer these built-in approaches only " +"target environments which have Python, and an audience who knows how to " +"install Python packages." msgstr "" #: ../source/overview.rst:162 -msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." +msgid "" +"With the variety of operating systems, configurations, and people out there, " +"this assumption is only safe when targeting a developer audience." msgstr "" #: ../source/overview.rst:166 -msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." +msgid "" +"Python's native packaging is mostly built for distributing reusable code, " +"called libraries, between developers. You can piggyback **tools**, or basic " +"applications for developers, on top of Python's library packaging, using " +"technologies like `setuptools entry_points `_." msgstr "" #: ../source/overview.rst:172 -msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." +msgid "" +"Libraries are building blocks, not complete applications. For distributing " +"applications, there's a whole new world of technologies out there." msgstr "" #: ../source/overview.rst:176 -msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." +msgid "" +"The next few sections organize these application packaging options according " +"to their dependencies on the target environment, so you can choose the right " +"one for your project." msgstr "" #: ../source/overview.rst:181 @@ -5780,15 +8366,27 @@ msgid "Depending on a framework" msgstr "" #: ../source/overview.rst:183 -msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." +msgid "" +"Some types of Python applications, like web site backends and other network " +"services, are common enough that they have frameworks to enable their " +"development and packaging. Other types of applications, like dynamic web " +"frontends and mobile clients, are complex enough to target that a framework " +"becomes more than a convenience." msgstr "" #: ../source/overview.rst:189 -msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." +msgid "" +"In all these cases, it makes sense to work backwards, from the framework's " +"packaging and deployment story. Some frameworks include a deployment system " +"which wraps the technologies outlined in the rest of the guide. In these " +"cases, you'll want to defer to your framework's packaging guide for the " +"easiest and most reliable production experience." msgstr "" #: ../source/overview.rst:195 -msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." +msgid "" +"If you ever wonder how these platforms and frameworks work under the hood, " +"you can always read the sections beyond." msgstr "" #: ../source/overview.rst:199 @@ -5796,11 +8394,15 @@ msgid "Service platforms" msgstr "" #: ../source/overview.rst:201 -msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." +msgid "" +"If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku " +"or Google App Engine, you are going to want to follow their respective " +"packaging guides." msgstr "" #: ../source/overview.rst:205 -msgid "`Heroku `_" +msgid "" +"`Heroku `_" msgstr "" "`Heroku `_" @@ -5821,11 +8423,16 @@ msgid "\"Serverless\" frameworks like `Zappa `_" msgstr "" #: ../source/overview.rst:211 -msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." +msgid "" +"In all these setups, the platform takes care of packaging and deployment, as " +"long as you follow their patterns. Most software does not fit one of these " +"templates, hence the existence of all the other options below." msgstr "" #: ../source/overview.rst:216 -msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." +msgid "" +"If you're developing software that will be deployed to machines you own, " +"users' personal computers, or any other arrangement, read on." msgstr "" #: ../source/overview.rst:220 @@ -5833,11 +8440,16 @@ msgid "Web browsers and mobile applications" msgstr "" #: ../source/overview.rst:222 -msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." +msgid "" +"Python's steady advances are leading it into new spaces. These days you can " +"write a mobile app or web application frontend in Python. While the language " +"may be familiar, the packaging and deployment practices are brand new." msgstr "" #: ../source/overview.rst:227 -msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" +msgid "" +"If you're planning on releasing to these new frontiers, you'll want to check " +"out the following frameworks, and refer to their packaging guides:" msgstr "" #: ../source/overview.rst:231 @@ -5857,7 +8469,10 @@ msgid "`Flexx `_" msgstr "`Flexx `_" #: ../source/overview.rst:236 -msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." +msgid "" +"If you are *not* interested in using a framework or platform, or just wonder " +"about some of the technologies and techniques utilized by the frameworks " +"above, continue reading below." msgstr "" #: ../source/overview.rst:241 @@ -5865,7 +8480,12 @@ msgid "Depending on a pre-installed Python" msgstr "" #: ../source/overview.rst:243 -msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." +msgid "" +"Pick an arbitrary computer, and depending on the context, there's a very " +"good chance Python is already installed. Included by default in most Linux " +"and Mac operating systems for many years now, you can reasonably depend on " +"Python preexisting in your data centers or on the personal machines of " +"developers and data scientists." msgstr "" #: ../source/overview.rst:249 @@ -5877,7 +8497,9 @@ msgid "`PEX `_ (Python EXecutable)" msgstr "" #: ../source/overview.rst:252 -msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" +msgid "" +"`zipapp `_ (does not help " +"manage dependencies, requires Python 3.5+)" msgstr "" #: ../source/overview.rst:253 @@ -5885,11 +8507,17 @@ msgid "`shiv `_ (requires Python 3)" msgstr "`shiv `_ (потребує Python 3)" #: ../source/overview.rst:255 -msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." +msgid "" +"Of all the approaches here, depending on a pre-installed Python relies the " +"most on the target environment. Of course, this also makes for the smallest " +"package, as small as single-digit megabytes, or even kilobytes." msgstr "" #: ../source/overview.rst:260 -msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." +msgid "" +"In general, decreasing the dependency on the target system increases the " +"size of our package, so the solutions here are roughly arranged by " +"increasing size of output." msgstr "" #: ../source/overview.rst:267 @@ -5897,11 +8525,24 @@ msgid "Depending on a separate software distribution ecosystem" msgstr "" #: ../source/overview.rst:269 -msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." +msgid "" +"For a long time many operating systems, including Mac and Windows, lacked " +"built-in package management. Only recently did these OSes gain so-called " +"\"app stores\", but even those focus on consumer applications and offer " +"little for developers." msgstr "" #: ../source/overview.rst:274 -msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." +msgid "" +"Developers long sought remedies, and in this struggle, emerged with their " +"own package management solutions, such as `Homebrew `_. " +"The most relevant alternative for Python developers is a package ecosystem " +"called `Anaconda `_. Anaconda is built around Python and is " +"increasingly common in academic, analytical, and other data-oriented " +"environments, even making its way `into server-oriented environments " +"`_." msgstr "" #: ../source/overview.rst:284 @@ -5909,15 +8550,21 @@ msgid "Instructions on building and publishing for the Anaconda ecosystem:" msgstr "" #: ../source/overview.rst:286 -msgid "`Building libraries and applications with conda `_" +msgid "" +"`Building libraries and applications with conda `_" msgstr "" #: ../source/overview.rst:287 -msgid "`Transitioning a native Python package to Anaconda `_" +msgid "" +"`Transitioning a native Python package to Anaconda `_" msgstr "" #: ../source/overview.rst:289 -msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" +msgid "" +"A similar model involves installing an alternative Python distribution, but " +"does not support arbitrary operating system-level packages:" msgstr "" #: ../source/overview.rst:293 @@ -5937,15 +8584,24 @@ msgid "Bringing your own Python executable" msgstr "" #: ../source/overview.rst:302 -msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." +msgid "" +"Computing as we know it is defined by the ability to execute programs. Every " +"operating system natively supports one or more formats of program they can " +"natively execute." msgstr "" #: ../source/overview.rst:306 -msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." +msgid "" +"There are many techniques and technologies which turn your Python program " +"into one of these formats, most of which involve embedding the Python " +"interpreter and any other dependencies into a single executable file." msgstr "" #: ../source/overview.rst:311 -msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." +msgid "" +"This approach, called *freezing*, offers wide compatibility and seamless " +"user experience, though often requires multiple technologies, and a good " +"amount of effort." msgstr "" #: ../source/overview.rst:315 @@ -5957,11 +8613,14 @@ msgid "`pyInstaller `_ - Cross-platform" msgstr "" #: ../source/overview.rst:318 -msgid "`cx_Freeze `_ - Cross-platform" +msgid "" +"`cx_Freeze `_ - Cross-platform" msgstr "" #: ../source/overview.rst:319 -msgid "`constructor `_ - For command-line installers" +msgid "" +"`constructor `_ - For command-line " +"installers" msgstr "" #: ../source/overview.rst:320 @@ -5973,7 +8632,9 @@ msgid "`py2app `_ - Mac only" msgstr "" #: ../source/overview.rst:322 -msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" +msgid "" +"`bbFreeze `_ - Windows, Linux, Python 2 " +"only" msgstr "" #: ../source/overview.rst:323 @@ -5985,7 +8646,9 @@ msgid "`pynsist `_ - Windows only" msgstr "" #: ../source/overview.rst:326 -msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." +msgid "" +"Most of the above imply single-user deployments. For multi-component server " +"applications, see `Chef Omnibus `_." msgstr "" #: ../source/overview.rst:332 @@ -5993,15 +8656,24 @@ msgid "Bringing your own userspace" msgstr "" #: ../source/overview.rst:334 -msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." +msgid "" +"An increasing number of operating systems -- including Linux, Mac OS, and " +"Windows -- can be set up to run applications packaged as lightweight images, " +"using a relatively modern arrangement often referred to as `operating-system-" +"level virtualization `_, or *containerization*." msgstr "" #: ../source/overview.rst:341 -msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." +msgid "" +"These techniques are mostly Python agnostic, because they package whole OS " +"filesystems, not just Python or Python packages." msgstr "" #: ../source/overview.rst:344 -msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" +msgid "" +"Adoption is most extensive among Linux servers, where the technology " +"originated and where the technologies below work best:" msgstr "" #: ../source/overview.rst:347 @@ -6025,11 +8697,18 @@ msgid "Bringing your own kernel" msgstr "" #: ../source/overview.rst:355 -msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." +msgid "" +"Most operating systems support some form of classical virtualization, " +"running applications packaged as images containing a full operating system " +"of their own. Running these virtual machines, or VMs, is a mature approach, " +"widespread in data center environments." msgstr "" #: ../source/overview.rst:360 -msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" +msgid "" +"These techniques are mostly reserved for larger scale deployments in data " +"centers, though certain complex applications can benefit from this " +"packaging. Technologies are Python agnostic, and include:" msgstr "" #: ../source/overview.rst:364 @@ -6037,11 +8716,16 @@ msgid "`Vagrant `_" msgstr "`Vagrant `_" #: ../source/overview.rst:365 -msgid "`VHD `_, `AMI `_, and `other formats `_" +msgid "" +"`VHD `_, `AMI `_, and `other formats `_" msgstr "" #: ../source/overview.rst:366 -msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" +msgid "" +"`OpenStack `_ - A cloud " +"management system in Python, with extensive VM support" msgstr "" #: ../source/overview.rst:369 @@ -6049,19 +8733,31 @@ msgid "Bringing your own hardware" msgstr "" #: ../source/overview.rst:371 -msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." +msgid "" +"The most all-encompassing way to ship your software would be to ship it " +"already-installed on some hardware. This way, your software's user would " +"require only electricity." msgstr "" #: ../source/overview.rst:375 -msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." +msgid "" +"Whereas the virtual machines described above are primarily reserved for the " +"tech-savvy, you can find hardware appliances being used by everyone from the " +"most advanced data centers to the youngest children." msgstr "" #: ../source/overview.rst:379 -msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." +msgid "" +"Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the " +"datacenter or your users' homes. They plug and play, and you can call it a " +"day." msgstr "" #: ../source/overview.rst:389 -msgid "The simplified gamut of technologies used to package Python applications." +msgid "" +"The simplified gamut of technologies used to package Python applications." msgstr "" #: ../source/overview.rst:392 @@ -6069,7 +8765,9 @@ msgid "What about..." msgstr "А як щодо..." #: ../source/overview.rst:394 -msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." +msgid "" +"The sections above can only summarize so much, and you might be wondering " +"about some of the more conspicuous gaps." msgstr "" #: ../source/overview.rst:398 @@ -6077,19 +8775,40 @@ msgid "Operating system packages" msgstr "" #: ../source/overview.rst:400 -msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." +msgid "" +"As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some " +"operating systems have package managers of their own. If you're very sure of " +"the operating system you're targeting, you can depend directly on a format " +"like `deb `_ (for Debian, " +"Ubuntu, etc.) or `RPM `_ " +"(for Red Hat, Fedora, etc.), and use that built-in package manager to take " +"care of installation, and even deployment. You can even use `FPM `_ to generate both deb " +"and RPMs from the same source." msgstr "" #: ../source/overview.rst:411 -msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." +msgid "" +"In most deployment pipelines, the OS package manager is just one piece of " +"the puzzle." msgstr "" #: ../source/overview.rst:417 -msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." +msgid "" +"`Virtualenvs `_ have been an indispensable tool for multiple generations of Python " +"developer, but are slowly fading from view, as they are being wrapped by " +"higher-level tools. With packaging in particular, virtualenvs are used as a " +"primitive in `the dh-virtualenv tool `_ and `osnap `_, " +"both of which wrap virtualenvs in a self-contained way." msgstr "" #: ../source/overview.rst:427 -msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." +msgid "" +"For production deployments, do not rely on running ``python -m pip install`` " +"from the Internet into a virtualenv, as one might do in a development " +"environment. The overview above is full of much better solutions." msgstr "" #: ../source/overview.rst:432 @@ -6097,11 +8816,20 @@ msgid "Security" msgstr "Безпека" #: ../source/overview.rst:434 -msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." +msgid "" +"The further down the gradient you come, the harder it gets to update " +"components of your package. Everything is more tightly bound together." msgstr "" #: ../source/overview.rst:437 -msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." +msgid "" +"For example, if a kernel security issue emerges, and you're deploying " +"containers, the host system's kernel can be updated without requiring a new " +"build on behalf of the application. If you deploy VM images, you'll need a " +"new build. Whether or not this dynamic makes one option more secure is still " +"a bit of an old debate, going back to the still-unsettled matter of `static " +"versus dynamic linking `_." msgstr "" #: ../source/overview.rst:446 @@ -6109,7 +8837,12 @@ msgid "Wrap up" msgstr "Підсумок" #: ../source/overview.rst:448 -msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." +msgid "" +"Packaging in Python has a bit of a reputation for being a bumpy ride. This " +"impression is mostly a byproduct of Python's versatility. Once you " +"understand the natural boundaries between each packaging solution, you begin " +"to realize that the varied landscape is a small price Python programmers pay " +"for using one of the most balanced, flexible languages available." msgstr "" #: ../source/specifications/binary-distribution-format.rst:6 @@ -6117,7 +8850,9 @@ msgid "Binary distribution format" msgstr "" #: ../source/specifications/binary-distribution-format.rst:8 -msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." +msgid "" +"The binary distribution format (:term:`wheel `) was originally " +"defined in :pep:`427`. The current version of the specification is here." msgstr "" #: ../source/specifications/binary-distribution-format.rst:13 @@ -6129,7 +8864,14 @@ msgid "This PEP describes a built-package format for Python called \"wheel\"." msgstr "" #: ../source/specifications/binary-distribution-format.rst:17 -msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." +msgid "" +"A wheel is a ZIP-format archive with a specially formatted file name and the " +"``.whl`` extension. It contains a single distribution nearly as it would be " +"installed according to PEP 376 with a particular installation scheme. " +"Although a specialized installer is recommended, a wheel file may be " +"installed by simply unpacking into site-packages with the standard 'unzip' " +"tool while preserving enough information to spread its contents out onto " +"their final paths at any later time." msgstr "" #: ../source/specifications/binary-distribution-format.rst:27 @@ -6137,7 +8879,9 @@ msgid "PEP Acceptance" msgstr "" #: ../source/specifications/binary-distribution-format.rst:29 -msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" +msgid "" +"This PEP was accepted, and the defined wheel version updated to 1.0, by Nick " +"Coghlan on 16th February, 2013 [1]_" msgstr "" #: ../source/specifications/binary-distribution-format.rst:34 @@ -6145,11 +8889,22 @@ msgid "Rationale" msgstr "Обґрунтування" #: ../source/specifications/binary-distribution-format.rst:36 -msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." +msgid "" +"Python needs a package format that is easier to install than sdist. Python's " +"sdist packages are defined by and require the distutils and setuptools build " +"systems, running arbitrary code to build-and-install, and re-compile, code " +"just so it can be installed into a new virtualenv. This system of " +"conflating build-install is slow, hard to maintain, and hinders innovation " +"in both build systems and installers." msgstr "" #: ../source/specifications/binary-distribution-format.rst:43 -msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." +msgid "" +"Wheel attempts to remedy these problems by providing a simpler interface " +"between the build system and the installer. The wheel binary package format " +"frees installers from having to know about the build system, saves time by " +"amortizing compile time over many installations, and removes the need to " +"install a build system in the target environment." msgstr "" #: ../source/specifications/binary-distribution-format.rst:52 @@ -6173,11 +8928,14 @@ msgid "Parse ``distribution-1.0.dist-info/WHEEL``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:62 -msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." +msgid "" +"Check that installer is compatible with Wheel-Version. Warn if minor " +"version is greater, abort if major version is greater." msgstr "" #: ../source/specifications/binary-distribution-format.rst:64 -msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." +msgid "" +"If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:66 @@ -6189,15 +8947,24 @@ msgid "Spread." msgstr "" #: ../source/specifications/binary-distribution-format.rst:70 -msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." +msgid "" +"Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is " +"data) ``distribution-1.0.data/``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:72 -msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." +msgid "" +"Move each subtree of ``distribution-1.0.data/`` onto its destination path. " +"Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of " +"destination directories, such as ``distribution-1.0.data/(purelib|platlib|" +"headers|scripts|data)``. The initially supported paths are taken from " +"``distutils.command.install``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:78 -msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." +msgid "" +"If applicable, update scripts starting with ``#!python`` to point to the " +"correct interpreter." msgstr "" #: ../source/specifications/binary-distribution-format.rst:80 @@ -6209,7 +8976,9 @@ msgid "Remove empty ``distribution-1.0.data`` directory." msgstr "" #: ../source/specifications/binary-distribution-format.rst:83 -msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" +msgid "" +"Compile any installed .py to .pyc. (Uninstallers should be smart enough to " +"remove .pyc even if it is not mentioned in RECORD.)" msgstr "" #: ../source/specifications/binary-distribution-format.rst:87 @@ -6221,11 +8990,17 @@ msgid "Rewrite ``#!python``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:90 -msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." +msgid "" +"In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/" +"``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!" +"python'``, rewrite to point to the correct interpreter. Unix installers may " +"need to add the +x bit to these files if the archive was created on Windows." msgstr "" #: ../source/specifications/binary-distribution-format.rst:96 -msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." +msgid "" +"The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI " +"script instead of a console script." msgstr "" #: ../source/specifications/binary-distribution-format.rst:102 @@ -6233,7 +9008,10 @@ msgid "Generate script wrappers." msgstr "" #: ../source/specifications/binary-distribution-format.rst:100 -msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." +msgid "" +"In wheel, scripts packaged on Unix systems will certainly not have " +"accompanying .exe wrappers. Windows installers may want to add them during " +"install." msgstr "" #: ../source/specifications/binary-distribution-format.rst:105 @@ -6245,7 +9023,11 @@ msgid "Place ``.dist-info`` at the end of the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:108 -msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." +msgid "" +"Archivers are encouraged to place the ``.dist-info`` files physically at the " +"end of the archive. This enables some potentially interesting ZIP tricks " +"including the ability to amend the metadata without rewriting the entire " +"archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:115 @@ -6257,7 +9039,9 @@ msgid "File name convention" msgstr "" #: ../source/specifications/binary-distribution-format.rst:120 -msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." +msgid "" +"The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-" +"{abi tag}-{platform tag}.whl``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:124 @@ -6277,7 +9061,12 @@ msgid "build tag" msgstr "" #: ../source/specifications/binary-distribution-format.rst:130 -msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." +msgid "" +"Optional build number. Must start with a digit. Acts as a tie-breaker if " +"two wheel file names are the same in all other respects (i.e. name, version, " +"and other tags). Sort as an empty tuple if unspecified, else sort as a two-" +"item tuple with the first item being the initial digits as an ``int``, and " +"the second item being the remainder of the tag as a ``str``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:138 @@ -6305,11 +9094,18 @@ msgid "E.g. 'linux_x86_64', 'any'." msgstr "" #: ../source/specifications/binary-distribution-format.rst:146 -msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." +msgid "" +"For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of " +"a package called 'distribution', and is compatible with Python 2.7 (any " +"Python 2.7 implementation), with no ABI (pure Python), on any CPU " +"architecture." msgstr "" #: ../source/specifications/binary-distribution-format.rst:151 -msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." +msgid "" +"The last three components of the filename before the extension are called " +"\"compatibility tags.\" The compatibility tags express the package's basic " +"interpreter requirements and are detailed in PEP 425." msgstr "" #: ../source/specifications/binary-distribution-format.rst:156 @@ -6317,31 +9113,50 @@ msgid "Escaping and Unicode" msgstr "" #: ../source/specifications/binary-distribution-format.rst:158 -msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" +msgid "" +"As the components of the filename are separated by a dash (``-``, HYPHEN-" +"MINUS), this character cannot appear within any component. This is handled " +"as follows:" msgstr "" #: ../source/specifications/binary-distribution-format.rst:161 -msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." +msgid "" +"In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE " +"and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent " +"to :pep:`503` normalisation followed by replacing ``-`` with ``_``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:164 -msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." +msgid "" +"Version numbers should be normalised according to :pep:`440`. Normalised " +"version numbers cannot contain ``-``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:166 -msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." +msgid "" +"The remaining components may not contain ``-`` characters, so no escaping is " +"necessary." msgstr "" #: ../source/specifications/binary-distribution-format.rst:169 -msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." +msgid "" +"Tools producing wheels should verify that the filename components do not " +"contain ``-``, as the resulting file may not be processed correctly if they " +"do." msgstr "" #: ../source/specifications/binary-distribution-format.rst:172 -msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." +msgid "" +"The archive filename is Unicode. It will be some time before the tools are " +"updated to support non-ASCII filenames, but they are supported in this " +"specification." msgstr "" #: ../source/specifications/binary-distribution-format.rst:176 -msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." +msgid "" +"The filenames *inside* the archive are encoded as UTF-8. Although some ZIP " +"clients in common use do not properly display UTF-8 filenames, the encoding " +"is supported by both the ZIP specification and Python's ``zipfile``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:182 @@ -6349,11 +9164,17 @@ msgid "File contents" msgstr "" #: ../source/specifications/binary-distribution-format.rst:184 -msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" +msgid "" +"The contents of a wheel file, where {distribution} is replaced with the name " +"of the package, e.g. ``beaglevote`` and {version} is replaced with its " +"version, e.g. ``1.0.0``, consist of:" msgstr "" #: ../source/specifications/binary-distribution-format.rst:188 -msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." +msgid "" +"``/``, the root of the archive, contains all files to be installed in " +"``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and " +"``platlib`` are usually both ``site-packages``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:191 @@ -6361,19 +9182,30 @@ msgid "``{distribution}-{version}.dist-info/`` contains metadata." msgstr "" #: ../source/specifications/binary-distribution-format.rst:192 -msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." +msgid "" +"``{distribution}-{version}.data/`` contains one subdirectory for each non-" +"empty install scheme key not already covered, where the subdirectory name is " +"an index into a dictionary of install paths (e.g. ``data``, ``scripts``, " +"``include``, ``purelib``, ``platlib``)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:196 -msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." +msgid "" +"Python scripts must appear in ``scripts`` and begin with exactly ``b'#!" +"python'`` in order to enjoy script wrapper generation and ``#!python`` " +"rewriting at install time. They may have any or no extension." msgstr "" #: ../source/specifications/binary-distribution-format.rst:200 -msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." +msgid "" +"``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or " +"greater format metadata." msgstr "" #: ../source/specifications/binary-distribution-format.rst:202 -msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" +msgid "" +"``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive " +"itself in the same basic key: value format::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:212 @@ -6381,27 +9213,40 @@ msgid "``Wheel-Version`` is the version number of the Wheel specification." msgstr "" #: ../source/specifications/binary-distribution-format.rst:213 -msgid "``Generator`` is the name and optionally the version of the software that produced the archive." +msgid "" +"``Generator`` is the name and optionally the version of the software that " +"produced the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:215 -msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." +msgid "" +"``Root-Is-Purelib`` is true if the top level directory of the archive should " +"be installed into purelib; otherwise the root should be installed into " +"platlib." msgstr "" #: ../source/specifications/binary-distribution-format.rst:218 -msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." +msgid "" +"``Tag`` is the wheel's expanded compatibility tags; in the example the " +"filename would contain ``py2.py3-none-any``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:220 -msgid "``Build`` is the build number and is omitted if there is no build number." +msgid "" +"``Build`` is the build number and is omitted if there is no build number." msgstr "" #: ../source/specifications/binary-distribution-format.rst:221 -msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." +msgid "" +"A wheel installer should warn if Wheel-Version is greater than the version " +"it supports, and must fail if Wheel-Version has a greater major version than " +"the version it supports." msgstr "" #: ../source/specifications/binary-distribution-format.rst:224 -msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." +msgid "" +"Wheel, being an installation format that is intended to work across multiple " +"versions of Python, does not generally include .pyc files." msgstr "" #: ../source/specifications/binary-distribution-format.rst:226 @@ -6409,7 +9254,11 @@ msgid "Wheel does not contain setup.py or setup.cfg." msgstr "" #: ../source/specifications/binary-distribution-format.rst:228 -msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." +msgid "" +"This version of the wheel specification is based on the distutils install " +"schemes and does not define how to install files to other locations. The " +"layout offers a superset of the functionality provided by the existing " +"wininst and egg binary formats." msgstr "" #: ../source/specifications/binary-distribution-format.rst:235 @@ -6418,11 +9267,15 @@ msgid "The .dist-info directory" msgstr "" #: ../source/specifications/binary-distribution-format.rst:237 -msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." +msgid "" +"Wheel .dist-info directories include at a minimum METADATA, WHEEL, and " +"RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:239 -msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." +msgid "" +"METADATA is the package metadata, the same format as PKG-INFO as found at " +"the root of sdists." msgstr "" #: ../source/specifications/binary-distribution-format.rst:241 @@ -6430,7 +9283,12 @@ msgid "WHEEL is the wheel metadata specific to a build of the package." msgstr "" #: ../source/specifications/binary-distribution-format.rst:242 -msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." +msgid "" +"RECORD is a list of (almost) all the files in the wheel and their secure " +"hashes. Unlike PEP 376, every file except RECORD, which cannot contain a " +"hash of itself, must include its hash. The hash algorithm must be sha256 or " +"better; specifically, md5 and sha1 are not permitted, as signed wheel files " +"rely on the strong hashes in RECORD to validate the integrity of the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:248 @@ -6438,15 +9296,22 @@ msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:249 -msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." +msgid "" +"RECORD.jws is used for digital signatures. It is not mentioned in RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:251 -msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." +msgid "" +"RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME " +"signatures to secure their wheel files. It is not mentioned in RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:254 -msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." +msgid "" +"During extraction, wheel installers verify all the hashes in RECORD against " +"the file contents. Apart from RECORD and its signatures, installation will " +"fail if any file in the archive is not both mentioned and correctly hashed " +"in RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:261 @@ -6454,11 +9319,17 @@ msgid "The .data directory" msgstr "" #: ../source/specifications/binary-distribution-format.rst:263 -msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" +msgid "" +"Any file that is not normally installed inside site-packages goes into the ." +"data directory, named as the .dist-info directory but with the .data/ " +"extension::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:271 -msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." +msgid "" +"The .data directory contains subdirectories with the scripts, headers, " +"documentation and so forth from the distribution. During installation the " +"contents of these subdirectories are moved onto their destination paths." msgstr "" #: ../source/specifications/binary-distribution-format.rst:277 @@ -6466,15 +9337,29 @@ msgid "Signed wheel files" msgstr "" #: ../source/specifications/binary-distribution-format.rst:279 -msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" +msgid "" +"Wheel files include an extended RECORD that enables digital signatures. PEP " +"376's RECORD is altered to include a secure hash " +"``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with " +"no trailing = characters) as the second column instead of an md5sum. All " +"possible entries are hashed, including any generated files such as .pyc " +"files, but not RECORD which cannot contain its own hash. For example::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:290 -msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." +msgid "" +"The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD " +"at all since they can only be added after RECORD is generated. Every other " +"file in the archive must have a correct hash in RECORD or the installation " +"will fail." msgstr "" #: ../source/specifications/binary-distribution-format.rst:295 -msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" +msgid "" +"If JSON web signatures are used, one or more JSON Web Signature JSON " +"Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to " +"RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD " +"as the signature's JSON payload::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:302 @@ -6482,11 +9367,17 @@ msgid "(The hash value is the same format used in RECORD.)" msgstr "" #: ../source/specifications/binary-distribution-format.rst:304 -msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." +msgid "" +"If RECORD.p7s is used, it must contain a detached S/MIME format signature of " +"RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:307 -msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." +msgid "" +"A wheel installer is not required to understand digital signatures but MUST " +"verify the hashes in RECORD against the extracted file contents. When the " +"installer checks file hashes against RECORD, a separate signature checker " +"only needs to establish that RECORD matches the signature." msgstr "" #: ../source/specifications/binary-distribution-format.rst:312 @@ -6498,7 +9389,8 @@ msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" #: ../source/specifications/binary-distribution-format.rst:315 -msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" +msgid "" +"http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" msgstr "" "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" @@ -6515,23 +9407,41 @@ msgid "Comparison to .egg" msgstr "" #: ../source/specifications/binary-distribution-format.rst:323 -msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." +msgid "" +"Wheel is an installation format; egg is importable. Wheel archives do not " +"need to include .pyc and are less tied to a specific Python version or " +"implementation. Wheel can install (pure Python) packages built with previous " +"versions of Python so you don't always have to wait for the packager to " +"catch up." msgstr "" #: ../source/specifications/binary-distribution-format.rst:328 -msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." +msgid "" +"Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible " +"with the new world of Python packaging and the new concepts it brings." msgstr "" #: ../source/specifications/binary-distribution-format.rst:331 -msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." +msgid "" +"Wheel has a richer file naming convention for today's multi-implementation " +"world. A single wheel archive can indicate its compatibility with a number " +"of Python language versions and implementations, ABIs, and system " +"architectures. Historically the ABI has been specific to a CPython release, " +"wheel is ready for the stable ABI." msgstr "" #: ../source/specifications/binary-distribution-format.rst:337 -msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." +msgid "" +"Wheel is lossless. The first wheel implementation bdist_wheel always " +"generates egg-info, and then converts it to a .whl. It is also possible to " +"convert existing eggs and bdist_wininst distributions." msgstr "" #: ../source/specifications/binary-distribution-format.rst:341 -msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." +msgid "" +"Wheel is versioned. Every wheel file contains the version of the wheel " +"specification and the implementation that packaged it. Hopefully the next " +"migration can simply be to Wheel 2.0." msgstr "" #: ../source/specifications/binary-distribution-format.rst:344 @@ -6547,7 +9457,13 @@ msgid "Wheel defines a .data directory. Should I put all my data there?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:354 -msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." +msgid "" +"This specification does not have an opinion on how you should organize your " +"code. The .data directory is just a place for any files that are not " +"normally installed inside ``site-packages`` or on the PYTHONPATH. In other " +"words, you may continue to use ``pkgutil.get_data(package, resource)`` even " +"though *those* files will usually not be distributed in *wheel's* ``.data`` " +"directory." msgstr "" #: ../source/specifications/binary-distribution-format.rst:363 @@ -6555,7 +9471,12 @@ msgid "Why does wheel include attached signatures?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:365 -msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." +msgid "" +"Attached signatures are more convenient than detached signatures because " +"they travel with the archive. Since only the individual files are signed, " +"the archive can be recompressed without invalidating the signature or " +"individual files can be verified without having to download the whole " +"archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:373 @@ -6563,7 +9484,10 @@ msgid "Why does wheel allow JWS signatures?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:375 -msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." +msgid "" +"The JOSE specifications of which JWS is a part are designed to be easy to " +"implement, a feature that is also one of wheel's primary design goals. JWS " +"yields a useful, concise pure-Python implementation." msgstr "" #: ../source/specifications/binary-distribution-format.rst:381 @@ -6571,11 +9495,15 @@ msgid "Why does wheel also allow S/MIME signatures?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:383 -msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." +msgid "" +"S/MIME signatures are allowed for users who need or want to use existing " +"public key infrastructure with wheel." msgstr "" #: ../source/specifications/binary-distribution-format.rst:386 -msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." +msgid "" +"Signed packages are only a basic building block in a secure package update " +"system. Wheel only provides the building block." msgstr "" #: ../source/specifications/binary-distribution-format.rst:391 @@ -6583,15 +9511,26 @@ msgid "What's the deal with \"purelib\" vs. \"platlib\"?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:393 -msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." +msgid "" +"Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is " +"significant on some platforms. For example, Fedora installs pure Python " +"packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent " +"packages to '/usr/lib64/pythonX.Y/site-packages'." msgstr "" #: ../source/specifications/binary-distribution-format.rst:398 -msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." +msgid "" +"A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-" +"{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: " +"true\" with those same files in the root, and it is legal to have files in " +"both the \"purelib\" and \"platlib\" categories." msgstr "" #: ../source/specifications/binary-distribution-format.rst:403 -msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." +msgid "" +"In practice a wheel should have only one of \"purelib\" or \"platlib\" " +"depending on whether it is pure Python or not and those files should be at " +"the root with the appropriate setting given for \"Root-is-purelib\"." msgstr "" #: ../source/specifications/binary-distribution-format.rst:409 @@ -6599,19 +9538,50 @@ msgid "Is it possible to import Python code directly from a wheel file?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:411 -msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." +msgid "" +"Technically, due to the combination of supporting installation via simple " +"extraction and using an archive format that is compatible with " +"``zipimport``, a subset of wheel files *do* support being placed directly on " +"``sys.path``. However, while this behaviour is a natural consequence of the " +"format design, actually relying on it is generally discouraged." msgstr "" #: ../source/specifications/binary-distribution-format.rst:417 -msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." +msgid "" +"Firstly, wheel *is* designed primarily as a distribution format, so skipping " +"the installation step also means deliberately avoiding any reliance on " +"features that assume full installation (such as being able to use standard " +"tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in " +"a way that can be properly tracked for auditing and security update " +"purposes, or integrating fully with the standard build machinery for C " +"extensions by publishing header files in the appropriate place)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:426 -msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." +msgid "" +"Secondly, while some Python software is written to support running directly " +"from a zip archive, it is still common for code to be written assuming it " +"has been fully installed. When that assumption is broken by trying to run " +"the software from a zip archive, the failures can often be obscure and hard " +"to diagnose (especially when they occur in third party libraries). The two " +"most common sources of problems with this are the fact that importing C " +"extensions from a zip archive is *not* supported by CPython (since doing so " +"is not supported directly by the dynamic loading machinery on any platform) " +"and that when running from a zip archive the ``__file__`` attribute no " +"longer refers to an ordinary filesystem path, but to a combination path that " +"includes both the location of the zip archive on the filesystem and the " +"relative path to the module inside the archive. Even when software correctly " +"uses the abstract resource APIs internally, interfacing with external " +"components may still require the availability of an actual on-disk file." msgstr "" #: ../source/specifications/binary-distribution-format.rst:443 -msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." +msgid "" +"Like metaclasses, monkeypatching and metapath importers, if you're not " +"already sure you need to take advantage of this feature, you almost " +"certainly don't need it. If you *do* decide to use it anyway, be aware that " +"many projects will require a failure to be reproduced with a fully installed " +"package before accepting it as a genuine bug." msgstr "" #: ../source/specifications/binary-distribution-format.rst:450 @@ -6623,11 +9593,15 @@ msgid "Since :pep:`427`, this specification has changed as follows:" msgstr "" #: ../source/specifications/binary-distribution-format.rst:454 -msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." +msgid "" +"The rules on escaping in wheel filenames were revised, to bring them into " +"line with what popular tools actually do (February 2021)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:461 -msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" +msgid "" +"PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-" +"February/124103.html)" msgstr "" #: ../source/specifications/binary-distribution-format.rst:466 @@ -6651,7 +9625,9 @@ msgid "Core metadata specifications" msgstr "" #: ../source/specifications/core-metadata.rst:7 -msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" +msgid "" +"Fields defined in the following specification should be considered valid, " +"complete and not subject to change. The required fields are:" msgstr "" #: ../source/specifications/core-metadata.rst:10 @@ -6671,15 +9647,33 @@ msgid "All the other fields are optional." msgstr "Усі інші поля необов'язкові." #: ../source/specifications/core-metadata.rst:16 -msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." +msgid "" +"The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats " +"have been revised several times, and exactly which email RFC applies to " +"packaging metadata is not specified. In the absence of a precise definition, " +"the practical standard is set by what the standard library :mod:`python:" +"email.parser` module can parse using the :data:`~.python:email.policy." +"compat32` policy." msgstr "" #: ../source/specifications/core-metadata.rst:25 -msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." +msgid "" +"Although :pep:`566` defined a way to transform metadata into a JSON-" +"compatible dictionary, this is not yet used as a standard interchange " +"format. The need for tools to work with years worth of existing packages " +"makes it difficult to shift to a new format." msgstr "" #: ../source/specifications/core-metadata.rst:30 -msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." +msgid "" +"*Interpreting old metadata:* In :pep:`566`, the version specifier field " +"format specification was relaxed to accept the syntax used by popular " +"publishing tools (namely to remove the requirement that version specifiers " +"must be surrounded by parentheses). Metadata consumers may want to use the " +"more relaxed formatting rules even for metadata files that are nominally " +"less than version 2.1." msgstr "" #: ../source/specifications/core-metadata.rst:41 @@ -6687,15 +9681,25 @@ msgid "Metadata-Version" msgstr "" #: ../source/specifications/core-metadata.rst:45 -msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." +msgid "" +"Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", " +"\"2.1\" and \"2.2\"." msgstr "" #: ../source/specifications/core-metadata.rst:48 -msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." +msgid "" +"Automated tools consuming metadata SHOULD warn if ``metadata_version`` is " +"greater than the highest version they support, and MUST fail if " +"``metadata_version`` has a greater major version than the highest version " +"they support (as described in :pep:`440`, the major version is the value " +"before the first dot)." msgstr "" #: ../source/specifications/core-metadata.rst:54 -msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." +msgid "" +"For broader compatibility, build tools MAY choose to produce distribution " +"metadata using the lowest metadata version that includes all of the needed " +"fields." msgstr "" #: ../source/specifications/core-metadata.rst:58 @@ -6729,7 +9733,12 @@ msgid "Added additional restrictions on format from :pep:`508`" msgstr "" #: ../source/specifications/core-metadata.rst:72 -msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" +msgid "" +"The name of the distribution. The name field is the primary identifier for a " +"distribution. A valid name consists only of ASCII letters and numbers, " +"period, underscore and hyphen. It must start and end with a letter or " +"number. Distribution names are limited to those which match the following " +"regex (run with ``re.IGNORECASE``)::" msgstr "" #: ../source/specifications/core-metadata.rst:88 @@ -6737,7 +9746,9 @@ msgid "Version" msgstr "" #: ../source/specifications/core-metadata.rst:92 -msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." +msgid "" +"A string containing the distribution's version number. This field must be " +"in the format specified in :pep:`440`." msgstr "" #: ../source/specifications/core-metadata.rst:101 @@ -6745,31 +9756,49 @@ msgid "Dynamic (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:105 -msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." +msgid "" +"A string containing the name of another core metadata field. The field names " +"``Name`` and ``Version`` may not be specified in this field." msgstr "" #: ../source/specifications/core-metadata.rst:108 -msgid "When found in the metadata of a source distribution, the following rules apply:" +msgid "" +"When found in the metadata of a source distribution, the following rules " +"apply:" msgstr "" #: ../source/specifications/core-metadata.rst:111 -msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." +msgid "" +"If a field is *not* marked as ``Dynamic``, then the value of the field in " +"any wheel built from the sdist MUST match the value in the sdist. If the " +"field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT " +"be present in the wheel." msgstr "" #: ../source/specifications/core-metadata.rst:115 -msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." +msgid "" +"If a field is marked as ``Dynamic``, it may contain any valid value in a " +"wheel built from the sdist (including not being present at all)." msgstr "" #: ../source/specifications/core-metadata.rst:118 -msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." +msgid "" +"If the sdist metadata version is older than version 2.2, then all fields " +"should be treated as if they were specified with ``Dynamic`` (i.e. there are " +"no special restrictions on the metadata of wheels built from the sdist)." msgstr "" #: ../source/specifications/core-metadata.rst:122 -msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." +msgid "" +"In any context other than a source distribution, ``Dynamic`` is for " +"information only, and indicates that the field value was calculated at wheel " +"build time, and may not be the same as the value in the sdist or in other " +"wheels for the project." msgstr "" #: ../source/specifications/core-metadata.rst:127 -msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." +msgid "" +"Full details of the semantics of ``Dynamic`` are described in :pep:`643`." msgstr "" #: ../source/specifications/core-metadata.rst:131 @@ -6777,7 +9806,10 @@ msgid "Platform (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:135 -msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." +msgid "" +"A Platform specification describing an operating system supported by the " +"distribution which is not listed in the \"Operating System\" Trove " +"classifiers. See \"Classifier\" below." msgstr "" #: ../source/specifications/core-metadata.rst:146 @@ -6785,7 +9817,11 @@ msgid "Supported-Platform (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:150 -msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." +msgid "" +"Binary distributions containing a PKG-INFO file will use the Supported-" +"Platform field in their metadata to specify the OS and CPU for which the " +"binary distribution was compiled. The semantics of the Supported-Platform " +"field are not specified in this PEP." msgstr "" #: ../source/specifications/core-metadata.rst:164 @@ -6801,23 +9837,41 @@ msgid "This field may be specified in the message body instead." msgstr "" #: ../source/specifications/core-metadata.rst:191 -msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." +msgid "" +"A longer description of the distribution that can run to several " +"paragraphs. Software that deals with metadata should not assume any maximum " +"size for this field, though people shouldn't include their instruction " +"manual as the description." msgstr "" #: ../source/specifications/core-metadata.rst:196 -msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." +msgid "" +"The contents of this field can be written using reStructuredText markup " +"[1]_. For programs that work with the metadata, supporting markup is " +"optional; programs can also display the contents of the field as-is. This " +"means that authors should be conservative in the markup they use." msgstr "" #: ../source/specifications/core-metadata.rst:202 -msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." +msgid "" +"To support empty lines and lines with indentation with respect to the RFC " +"822 format, any CRLF character has to be suffixed by 7 spaces followed by a " +"pipe (\"|\") char. As a result, the Description field is encoded into a " +"folded field that can be interpreted by RFC822 parser [2]_." msgstr "" #: ../source/specifications/core-metadata.rst:219 -msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." +msgid "" +"This encoding implies that any occurrences of a CRLF followed by 7 spaces " +"and a pipe char have to be replaced by a single CRLF when the field is " +"unfolded using a RFC822 reader." msgstr "" #: ../source/specifications/core-metadata.rst:223 -msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." +msgid "" +"Alternatively, the distribution's description may instead be provided in the " +"message body (i.e., after a completely blank line following the headers, " +"with no indentation or other special formatting necessary)." msgstr "" #: ../source/specifications/core-metadata.rst:232 @@ -6825,15 +9879,34 @@ msgid "Description-Content-Type" msgstr "" #: ../source/specifications/core-metadata.rst:236 -msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." +msgid "" +"A string stating the markup syntax (if any) used in the distribution's " +"description, so that tools can intelligently render the description." msgstr "" #: ../source/specifications/core-metadata.rst:239 -msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." +msgid "" +"Historically, PyPI supported descriptions in plain text and " +"`reStructuredText (reST) `_, and could render reST into HTML. However, it is " +"common for distribution authors to write the description in `Markdown " +"`_ (`RFC 7763 `_) as many code hosting sites render Markdown " +"READMEs, and authors would reuse the file for the description. PyPI didn't " +"recognize the format and so could not render the description correctly. This " +"resulted in many packages on PyPI with poorly-rendered descriptions when " +"Markdown is left as plain text, or worse, was attempted to be rendered as " +"reST. This field allows the distribution author to specify the format of " +"their description, opening up the possibility for PyPI and other tools to be " +"able to render Markdown and other formats." msgstr "" #: ../source/specifications/core-metadata.rst:253 -msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" +msgid "" +"The format of this field is the same as the ``Content-Type`` header in HTTP " +"(i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then " +"it can optionally have a number of parameters:" msgstr "" #: ../source/specifications/core-metadata.rst:259 @@ -6857,35 +9930,58 @@ msgid "``text/markdown``" msgstr "``text/markdown``" #: ../source/specifications/core-metadata.rst:269 -msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." +msgid "" +"The ``charset`` parameter can be used to specify the character encoding of " +"the description. The only legal value is ``UTF-8``. If omitted, it is " +"assumed to be ``UTF-8``." msgstr "" #: ../source/specifications/core-metadata.rst:273 -msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" +msgid "" +"Other parameters might be specific to the chosen subtype. For example, for " +"the ``markdown`` subtype, there is an optional ``variant`` parameter that " +"allows specifying the variant of Markdown in use (defaults to ``GFM`` if not " +"specified). Currently, two variants are recognized:" msgstr "" #: ../source/specifications/core-metadata.rst:278 -msgid "``GFM`` for `Github-flavored Markdown `_" +msgid "" +"``GFM`` for `Github-flavored Markdown `_" msgstr "" #: ../source/specifications/core-metadata.rst:280 -msgid "``CommonMark`` for `CommonMark `_" +msgid "" +"``CommonMark`` for `CommonMark `_" msgstr "" #: ../source/specifications/core-metadata.rst:299 -msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." +msgid "" +"If a ``Description-Content-Type`` is not specified, then applications should " +"attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to " +"``text/plain`` if it is not valid rst." msgstr "" #: ../source/specifications/core-metadata.rst:303 -msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." +msgid "" +"If a ``Description-Content-Type`` is an unrecognized value, then the assumed " +"content type is ``text/plain`` (Although PyPI will probably reject anything " +"with an unrecognized value)." msgstr "" #: ../source/specifications/core-metadata.rst:307 -msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." +msgid "" +"If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is " +"not specified or is set to an unrecognized value, then the assumed " +"``variant`` is ``GFM``." msgstr "" #: ../source/specifications/core-metadata.rst:311 -msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." +msgid "" +"So for the last example above, the ``charset`` defaults to ``UTF-8`` and the " +"``variant`` defaults to ``GFM`` and thus it is equivalent to the example " +"before it." msgstr "" #: ../source/specifications/core-metadata.rst:320 @@ -6893,11 +9989,17 @@ msgid "Keywords" msgstr "" #: ../source/specifications/core-metadata.rst:324 -msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." +msgid "" +"A list of additional keywords, separated by commas, to be used to assist " +"searching for the distribution in a larger catalog." msgstr "" #: ../source/specifications/core-metadata.rst:333 -msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." +msgid "" +"The specification previously showed keywords separated by spaces, but " +"distutils and setuptools implemented it with commas. These tools have been " +"very widely used for many years, so it was easier to update the " +"specification to match the de facto standard." msgstr "" #: ../source/specifications/core-metadata.rst:341 @@ -6913,7 +10015,10 @@ msgid "Download-URL" msgstr "" #: ../source/specifications/core-metadata.rst:357 -msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" +msgid "" +"A string containing the URL from which this version of the distribution can " +"be downloaded. (This means that the URL can't be something like \".../" +"BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" msgstr "" #: ../source/specifications/core-metadata.rst:366 @@ -6921,7 +10026,9 @@ msgid "Author" msgstr "" #: ../source/specifications/core-metadata.rst:370 -msgid "A string containing the author's name at a minimum; additional contact information may be provided." +msgid "" +"A string containing the author's name at a minimum; additional contact " +"information may be provided." msgstr "" #: ../source/specifications/core-metadata.rst:383 @@ -6929,12 +10036,16 @@ msgid "Author-email" msgstr "" #: ../source/specifications/core-metadata.rst:387 -msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgid "" +"A string containing the author's e-mail address. It can contain a name and " +"e-mail address in the legal forms for a RFC-822 ``From:`` header." msgstr "" #: ../source/specifications/core-metadata.rst:395 #: ../source/specifications/core-metadata.rst:442 -msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" +msgid "" +"Per RFC-822, this field may contain multiple comma-separated e-mail " +"addresses::" msgstr "" #: ../source/specifications/core-metadata.rst:405 @@ -6942,11 +10053,16 @@ msgid "Maintainer" msgstr "" #: ../source/specifications/core-metadata.rst:409 -msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." +msgid "" +"A string containing the maintainer's name at a minimum; additional contact " +"information may be provided." msgstr "" #: ../source/specifications/core-metadata.rst:412 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." +msgid "" +"Note that this field is intended for use when a project is being maintained " +"by someone other than the original author: it should be omitted if it is " +"identical to ``Author``." msgstr "" #: ../source/specifications/core-metadata.rst:426 @@ -6954,11 +10070,16 @@ msgid "Maintainer-email" msgstr "" #: ../source/specifications/core-metadata.rst:430 -msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgid "" +"A string containing the maintainer's e-mail address. It can contain a name " +"and e-mail address in the legal forms for a RFC-822 ``From:`` header." msgstr "" #: ../source/specifications/core-metadata.rst:434 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." +msgid "" +"Note that this field is intended for use when a project is being maintained " +"by someone other than the original author: it should be omitted if it is " +"identical to ``Author-email``." msgstr "" #: ../source/specifications/core-metadata.rst:452 @@ -6966,7 +10087,13 @@ msgid "License" msgstr "" #: ../source/specifications/core-metadata.rst:456 -msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." +msgid "" +"Text indicating the license covering the distribution where the license is " +"not a selection from the \"License\" Trove classifiers. See :ref:`" +"\"Classifier\" ` below. This field may also be used to " +"specify a particular version of a license which is named via the " +"``Classifier`` field, or to indicate a variation or exception to such a " +"license." msgstr "" #: ../source/specifications/core-metadata.rst:476 @@ -6974,7 +10101,11 @@ msgid "Classifier (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:480 -msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." +msgid "" +"Each entry is a string giving a single classification value for the " +"distribution. Classifiers are described in :pep:`301`, and the Python " +"Package Index publishes a dynamic list of `currently defined classifiers " +"`__." msgstr "" #: ../source/specifications/core-metadata.rst:485 @@ -6992,11 +10123,15 @@ msgstr "" #: ../source/specifications/core-metadata.rst:561 #: ../source/specifications/core-metadata.rst:663 #: ../source/specifications/core-metadata.rst:704 -msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." +msgid "" +"The field format specification was relaxed to accept the syntax used by " +"popular publishing tools." msgstr "" #: ../source/specifications/core-metadata.rst:503 -msgid "Each entry contains a string naming some other distutils project required by this distribution." +msgid "" +"Each entry contains a string naming some other distutils project required by " +"this distribution." msgstr "" #: ../source/specifications/core-metadata.rst:506 @@ -7004,19 +10139,27 @@ msgid "The format of a requirement string contains from one to four parts:" msgstr "" #: ../source/specifications/core-metadata.rst:508 -msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." +msgid "" +"A project name, in the same format as the ``Name:`` field. The only " +"mandatory part." msgstr "" #: ../source/specifications/core-metadata.rst:510 -msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." +msgid "" +"A comma-separated list of 'extra' names. These are defined by the required " +"project, referring to specific features which may need extra dependencies." msgstr "" #: ../source/specifications/core-metadata.rst:513 -msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." +msgid "" +"A version specifier. Tools parsing the format should accept optional " +"parentheses around this, but tools generating it should not use parentheses." msgstr "" #: ../source/specifications/core-metadata.rst:516 -msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." +msgid "" +"An environment marker after a semicolon. This means that the requirement is " +"only needed in the specified conditions." msgstr "" #: ../source/specifications/core-metadata.rst:519 @@ -7024,11 +10167,15 @@ msgid "See :pep:`508` for full details of the allowed format." msgstr "" #: ../source/specifications/core-metadata.rst:521 -msgid "The project names should correspond to names as found on the `Python Package Index`_." +msgid "" +"The project names should correspond to names as found on the `Python Package " +"Index`_." msgstr "" #: ../source/specifications/core-metadata.rst:524 -msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." +msgid "" +"Version specifiers must follow the rules described in :doc:`version-" +"specifiers`." msgstr "" #: ../source/specifications/core-metadata.rst:538 @@ -7036,7 +10183,10 @@ msgid "Requires-Python" msgstr "" #: ../source/specifications/core-metadata.rst:542 -msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." +msgid "" +"This field specifies the Python version(s) that the distribution is " +"guaranteed to be compatible with. Installation tools may look at this when " +"picking which version of a project to install." msgstr "" #: ../source/specifications/core-metadata.rst:546 @@ -7052,15 +10202,25 @@ msgid "Requires-External (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:565 -msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." +msgid "" +"Each entry contains a string describing some dependency in the system that " +"the distribution is to be used. This field is intended to serve as a hint " +"to downstream project maintainers, and has no semantics which are meaningful " +"to the ``distutils`` distribution." msgstr "" #: ../source/specifications/core-metadata.rst:570 -msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." +msgid "" +"The format of a requirement string is a name of an external dependency, " +"optionally followed by a version declaration within parentheses." msgstr "" #: ../source/specifications/core-metadata.rst:576 -msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." +msgid "" +"Because they refer to non-Python software releases, version numbers for this " +"field are **not** required to conform to the format specified in :pep:" +"`440`: they should correspond to the version scheme used by the external " +"dependency." msgstr "" #: ../source/specifications/core-metadata.rst:581 @@ -7072,7 +10232,9 @@ msgid "Project-URL (multiple-use)" msgstr "" #: ../source/specifications/core-metadata.rst:597 -msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." +msgid "" +"A string containing a browsable URL for the project and a label for it, " +"separated by a comma." msgstr "" #: ../source/specifications/core-metadata.rst:604 @@ -7084,19 +10246,31 @@ msgid "Provides-Extra (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:616 -msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." +msgid "" +"A string containing the name of an optional feature. Must be a valid Python " +"identifier. May be used to make a dependency conditional on whether the " +"optional feature has been requested." msgstr "" #: ../source/specifications/core-metadata.rst:625 -msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." +msgid "" +"A second distribution requires an optional dependency by placing it inside " +"square brackets, and can request multiple features by separating them with a " +"comma (,). The requirements are evaluated for each requested feature and " +"added to the set of requirements for the distribution." msgstr "" #: ../source/specifications/core-metadata.rst:635 -msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." +msgid "" +"Two feature names ``test`` and ``doc`` are reserved to mark dependencies " +"that are needed for running automated tests and generating documentation, " +"respectively." msgstr "" #: ../source/specifications/core-metadata.rst:639 -msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." +msgid "" +"It is legal to specify ``Provides-Extra:`` without referencing it in any " +"``Requires-Dist:``." msgstr "" #: ../source/specifications/core-metadata.rst:644 @@ -7104,11 +10278,21 @@ msgid "Rarely Used Fields" msgstr "" #: ../source/specifications/core-metadata.rst:646 -msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." +msgid "" +"The fields in this section are currently rarely used, as their design was " +"inspired by comparable mechanisms in Linux package management systems, and " +"it isn't at all clear how tools should interpret them in the context of an " +"open index server such as `PyPI `__." msgstr "" #: ../source/specifications/core-metadata.rst:651 -msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." +msgid "" +"As a result, popular installation tools ignore them completely, which in " +"turn means there is little incentive for package publishers to set them " +"appropriately. However, they're retained in the metadata specification, as " +"they're still potentially useful for informational purposes, and can also be " +"used for their originally intended purpose in combination with a curated " +"package repository." msgstr "" #: ../source/specifications/core-metadata.rst:660 @@ -7116,19 +10300,37 @@ msgid "Provides-Dist (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:667 -msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." +msgid "" +"Each entry contains a string naming a Distutils project which is contained " +"within this distribution. This field *must* include the project identified " +"in the ``Name`` field, followed by the version : Name (Version)." msgstr "" #: ../source/specifications/core-metadata.rst:672 -msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." +msgid "" +"A distribution may provide additional names, e.g. to indicate that multiple " +"projects have been bundled together. For instance, source distributions of " +"the ``ZODB`` project have historically included the ``transaction`` project, " +"which is now available as a separate distribution. Installing such a source " +"distribution satisfies requirements for both ``ZODB`` and ``transaction``." msgstr "" #: ../source/specifications/core-metadata.rst:679 -msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." +msgid "" +"A distribution may also provide a \"virtual\" project name, which does not " +"correspond to any separately-distributed project: such a name might be used " +"to indicate an abstract capability which could be supplied by one of " +"multiple projects. E.g., multiple projects might supply RDBMS bindings for " +"use by a given ORM: each project might declare that it provides ``ORM-" +"bindings``, allowing other projects to depend only on having at most one of " +"them installed." msgstr "" #: ../source/specifications/core-metadata.rst:687 -msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." +msgid "" +"A version declaration may be supplied and must follow the rules described " +"in :doc:`version-specifiers`. The distribution's version number will be " +"implied if none is specified." msgstr "" #: ../source/specifications/core-metadata.rst:701 @@ -7136,15 +10338,23 @@ msgid "Obsoletes-Dist (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:708 -msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." +msgid "" +"Each entry contains a string describing a distutils project's distribution " +"which this distribution renders obsolete, meaning that the two projects " +"should not be installed at the same time." msgstr "" #: ../source/specifications/core-metadata.rst:712 -msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." +msgid "" +"Version declarations can be supplied. Version numbers must be in the format " +"specified in :doc:`version-specifiers`." msgstr "" #: ../source/specifications/core-metadata.rst:717 -msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." +msgid "" +"The most common use of this field will be in case a project name changes, e." +"g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install " +"Torqued Python, the Gorgon distribution should be removed." msgstr "" #: ../source/specifications/core-metadata.rst:730 @@ -7160,7 +10370,11 @@ msgid "Declaring build system dependencies" msgstr "" #: ../source/specifications/declaring-build-dependencies.rst:8 -msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." +msgid "" +"`pyproject.toml` is a build system independent file format defined in :pep:" +"`518` that projects may provide in order to declare any Python level " +"dependencies that must be installed in order to run the project's build " +"system successfully." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:5 @@ -7168,15 +10382,31 @@ msgid "Declaring project metadata" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:7 -msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." +msgid "" +":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to " +"consume. It defines the following specification as the canonical source for " +"the format used." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:12 -msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." +msgid "" +"There are two kinds of metadata: *static* and *dynamic*. Static metadata is " +"specified in the ``pyproject.toml`` file directly and cannot be specified or " +"changed by a tool. Dynamic metadata is listed via the ``dynamic`` field " +"(defined later in this specification) and represents metadata that a tool " +"will later provide." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:18 -msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." +msgid "" +"The fields defined in this specification MUST be in a table named " +"``[project]`` in ``pyproject.toml``. No tools may add fields to this table " +"which are not defined by this specification. For tools wishing to store " +"their own settings in ``pyproject.toml``, they may use the ``[tool]`` table " +"as defined in the :ref:`build dependency declaration specification " +"`. The lack of a ``[project]`` table " +"implicitly means the build back-end will dynamically provide all fields." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:27 @@ -7189,7 +10419,9 @@ msgid "``name``" msgstr "``name``" #: ../source/specifications/declaring-project-metadata.rst:31 -msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" +msgid "" +"The fields which are required but may be specified *either* statically or " +"listed as dynamic are:" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:34 @@ -7198,7 +10430,9 @@ msgid "``version``" msgstr "``version``" #: ../source/specifications/declaring-project-metadata.rst:36 -msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." +msgid "" +"All other fields are considered optional and my be specified statically, " +"listed as dynamic, or left unspecified." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:43 @@ -7209,7 +10443,9 @@ msgid "TOML_ type: string" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:44 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Name `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:47 @@ -7217,11 +10453,15 @@ msgid "The name of the project." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:49 -msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." +msgid "" +"Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it " +"is read for internal consistency." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:57 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Version " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:60 @@ -7237,7 +10477,9 @@ msgid "``description``" msgstr "``description``" #: ../source/specifications/declaring-project-metadata.rst:69 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Summary " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:72 @@ -7253,7 +10495,10 @@ msgid "TOML_ type: string or table" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:79 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Description " +"` and :ref:`Description-Content-Type `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:83 @@ -7261,15 +10506,38 @@ msgid "The full description of the project (i.e. the README)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:85 -msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." +msgid "" +"The field accepts either a string or a table. If it is a string then it is a " +"path relative to ``pyproject.toml`` to a text file containing the full " +"description. Tools MUST assume the file's encoding is UTF-8. If the file " +"path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the " +"content-type is ``text/markdown``. If the file path ends in a case-" +"insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-" +"rst``. If a tool recognizes more extensions than this PEP, they MAY infer " +"the content-type for the user without specifying this field as ``dynamic``. " +"For all unrecognized suffixes when a content-type is not provided, tools " +"MUST raise an error." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:96 -msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." +msgid "" +"The ``readme`` field may also take a table. The ``file`` key has a string " +"value representing a path relative to ``pyproject.toml`` to a file " +"containing the full description. The ``text`` key has a string value which " +"is the full description. These keys are mutually-exclusive, thus tools MUST " +"raise an error if the metadata specifies both keys." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:103 -msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." +msgid "" +"A table specified in the ``readme`` field also has a ``content-type`` field " +"which takes a string specifying the content-type of the full description. A " +"tool MUST raise an error if the metadata does not specify this field in the " +"table. If the metadata does not specify the ``charset`` parameter, then it " +"is assumed to be UTF-8. Tools MAY support other encodings if they choose to. " +"Tools MAY support alternative content-types which they can transform to a " +"content-type as supported by the :ref:`core metadata `. " +"Otherwise tools MUST raise an error for unsupported content-types." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:115 @@ -7277,7 +10545,9 @@ msgid "``requires-python``" msgstr "``requires-python``" #: ../source/specifications/declaring-project-metadata.rst:118 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Requires-" +"Python `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:121 @@ -7293,11 +10563,19 @@ msgid "TOML_ type: table" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:128 -msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`License " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:131 -msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." +msgid "" +"The table may have one of two keys. The ``file`` key has a string value that " +"is a file path relative to ``pyproject.toml`` to the file which contains the " +"license for the project. Tools MUST assume the file's encoding is UTF-8. The " +"``text`` key has a string value which is the license of the project. These " +"keys are mutually exclusive, so a tool MUST raise an error if the metadata " +"specifies both keys." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:140 @@ -7309,35 +10587,58 @@ msgid "TOML_ type: Array of inline tables with string keys and values" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:143 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:" +"`Maintainer `, and :ref:`Maintainer-email `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:149 -msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." +msgid "" +"The people or organizations considered to be the \"authors\" of the project. " +"The exact meaning is open to interpretation — it may list the original or " +"primary authors, current maintainers, or owners of the package." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:154 -msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." +msgid "" +"The \"maintainers\" field is similar to \"authors\" in that its exact " +"meaning is open to interpretation." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:157 -msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." +msgid "" +"These fields accept an array of tables with 2 keys: ``name`` and ``email``. " +"Both values must be strings. The ``name`` value MUST be a valid email name " +"(i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not " +"contain commas. The ``email`` value MUST be a valid email address. Both keys " +"are optional." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:163 -msgid "Using the data to fill in :ref:`core metadata ` is as follows:" +msgid "" +"Using the data to fill in :ref:`core metadata ` is as follows:" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:166 -msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." +msgid "" +"If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:169 -msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." +msgid "" +"If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:173 -msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." +msgid "" +"If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-" +"email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:177 @@ -7354,7 +10655,9 @@ msgid "TOML_ type: array of strings" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:184 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Keywords " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:187 @@ -7366,7 +10669,9 @@ msgid "``classifiers``" msgstr "``classifiers``" #: ../source/specifications/declaring-project-metadata.rst:194 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Classifier " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:197 @@ -7382,11 +10687,15 @@ msgid "TOML_ type: table with keys and values of strings" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:204 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Project-URL " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:207 -msgid "A table of URLs where the key is the URL label and the value is the URL itself." +msgid "" +"A table of URLs where the key is the URL label and the value is the URL " +"itself." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:212 @@ -7394,7 +10703,9 @@ msgid "Entry points" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:214 -msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" +msgid "" +"TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and " +"``[project.entry-points]``)" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:216 @@ -7402,19 +10713,34 @@ msgid ":ref:`Entry points specification `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:218 -msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." +msgid "" +"There are three tables related to entry points. The ``[project.scripts]`` " +"table corresponds to the ``console_scripts`` group in the :ref:`entry points " +"specification `. The key of the table is the name of the entry " +"point and the value is the object reference." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:224 -msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." +msgid "" +"The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group " +"in the :ref:`entry points specification `. Its format is the " +"same as ``[project.scripts]``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:228 -msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." +msgid "" +"The ``[project.entry-points]`` table is a collection of tables. Each sub-" +"table's name is an entry point group. The key and value semantics are the " +"same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but " +"instead keep the entry point groups to only one level deep." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:234 -msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." +msgid "" +"Build back-ends MUST raise an error if the metadata defines a ``[project." +"entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` " +"table, as they would be ambiguous in the face of ``[project.scripts]`` and " +"``[project.gui-scripts]``, respectively." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:242 @@ -7422,11 +10748,16 @@ msgid "``dependencies``/``optional-dependencies``" msgstr "``dependencies``/``optional-dependencies``" #: ../source/specifications/declaring-project-metadata.rst:244 -msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" +msgid "" +"TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with " +"values of arrays of :pep:`508` strings (``optional-dependencies``)" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:247 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Requires-" +"Dist ` and :ref:`Provides-Extra `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:251 @@ -7434,11 +10765,22 @@ msgid "The (optional) dependencies of the project." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:253 -msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." +msgid "" +"For ``dependencies``, it is a key whose value is an array of strings. Each " +"string represents a dependency of the project and MUST be formatted as a " +"valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist " +"` entry." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:258 -msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." +msgid "" +"For ``optional-dependencies``, it is a table where each key specifies an " +"extra and whose value is an array of strings. The strings of the arrays must " +"be valid :pep:`508` strings. The keys MUST be valid values for :ref:" +"`Provides-Extra `. Each value in the array " +"thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:269 @@ -7450,39 +10792,65 @@ msgid "TOML_ type: array of string" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:272 -msgid "A corresponding :ref:`core metadata ` field does not exist" +msgid "" +"A corresponding :ref:`core metadata ` field does not exist" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:275 -msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." +msgid "" +"Specifies which fields listed by this PEP were intentionally unspecified so " +"another tool can/will provide such metadata dynamically. This clearly " +"delineates which metadata is purposefully unspecified and expected to stay " +"unspecified compared to being provided via tooling later on." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:281 -msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." +msgid "" +"A build back-end MUST honour statically-specified metadata (which means the " +"metadata did not list the field in ``dynamic``)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:283 -msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." +msgid "" +"A build back-end MUST raise an error if the metadata specifies ``name`` in " +"``dynamic``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:285 -msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." +msgid "" +"If the :ref:`core metadata ` specification lists a field as " +"\"Required\", then the metadata MUST specify the field statically or list it " +"in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it " +"should not be possible for a required field to not be listed somehow in the " +"``[project]`` table)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:290 -msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." +msgid "" +"If the :ref:`core metadata ` specification lists a field as " +"\"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is " +"a build back-end will provide the data for the field later." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:294 -msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." +msgid "" +"Build back-ends MUST raise an error if the metadata specifies a field " +"statically as well as being listed in ``dynamic``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:296 -msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." +msgid "" +"If the metadata does not list a field in ``dynamic``, then a build back-end " +"CANNOT fill in the requisite metadata on behalf of the user (i.e. " +"``dynamic`` is the only way to allow a tool to fill in metadata and the user " +"must opt into the filling in)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:300 -msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." +msgid "" +"Build back-ends MUST raise an error if the metadata specifies a field in " +"``dynamic`` but the build back-end was unable to determine the data for it " +"(omitting the data, if determined to be the accurate value, is acceptable)." msgstr "" #: ../source/specifications/dependency-specifiers.rst:6 @@ -7490,11 +10858,15 @@ msgid "Dependency specifiers" msgstr "" #: ../source/specifications/dependency-specifiers.rst:8 -msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." +msgid "" +"The dependency specifier format used to declare a dependency on another " +"component is defined in :pep:`508`." msgstr "" #: ../source/specifications/dependency-specifiers.rst:11 -msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." +msgid "" +"The environment markers section in this PEP supersedes the environment " +"markers section in :pep:`345`." msgstr "" #: ../source/specifications/direct-url.rst:6 @@ -7502,7 +10874,11 @@ msgid "Recording the Direct URL Origin of installed distributions" msgstr "" #: ../source/specifications/direct-url.rst:8 -msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." +msgid "" +"This document specifies a :file:`direct_url.json` file in the :file:`*.dist-" +"info` directory of an installed distribution, to record the Direct URL " +"Origin of the distribution. The layout of this file was originally specified " +"in :pep:`610` and is formally documented here." msgstr "" #: ../source/specifications/direct-url.rst:17 @@ -7510,80 +10886,145 @@ msgid "Specification" msgstr "Специфікація" #: ../source/specifications/direct-url.rst:19 -msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgid "" +"The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` " +"directory by installers when installing a distribution from a requirement " +"specifying a direct URL reference (including a VCS URL)." msgstr "" #: ../source/specifications/direct-url.rst:23 #: ../source/specifications/recording-installed-packages.rst:206 -msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." +msgid "" +"This file MUST NOT be created when installing a distribution from an other " +"type of requirement (i.e. name plus version specifier)." msgstr "" #: ../source/specifications/direct-url.rst:26 -msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." +msgid "" +"This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." msgstr "" #: ../source/specifications/direct-url.rst:29 -msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." +msgid "" +"If present, it MUST contain at least two fields. The first one is ``url``, " +"with type ``string``. Depending on what ``url`` refers to, the second field " +"MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), " +"``archive_info`` (if ``url`` is a source archives or a wheel), or " +"``dir_info`` (if ``url`` is a local directory). These info fields have a " +"(possibly empty) subdictionary as value, with the possible keys defined " +"below." msgstr "" #: ../source/specifications/direct-url.rst:36 -msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." +msgid "" +"``url`` MUST be stripped of any sensitive authentication information, for " +"security reasons." msgstr "" #: ../source/specifications/direct-url.rst:39 -msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" +msgid "" +"The user:password section of the URL MAY however be composed of environment " +"variables, matching the following regular expression::" msgstr "" #: ../source/specifications/direct-url.rst:45 -msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." +msgid "" +"Additionally, the user:password section of the URL MAY be a well-known, non " +"security sensitive string. A typical example is ``git`` in the case of an " +"URL such as ``ssh://git@gitlab.com/user/repo``." msgstr "" #: ../source/specifications/direct-url.rst:49 -msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" +msgid "" +"When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be " +"present as a dictionary with the following keys:" msgstr "" #: ../source/specifications/direct-url.rst:52 -msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." +msgid "" +"A ``vcs`` key (type ``string``) MUST be present, containing the name of the " +"VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be " +"registered by writing a PEP to amend this specification. The ``url`` value " +"MUST be compatible with the corresponding VCS, so an installer can hand it " +"off without transformation to a checkout/download command of the VCS." msgstr "" #: ../source/specifications/direct-url.rst:58 -msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." +msgid "" +"A ``requested_revision`` key (type ``string``) MAY be present naming a " +"branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to " +"install." msgstr "" #: ../source/specifications/direct-url.rst:61 -msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." +msgid "" +"A ``commit_id`` key (type ``string``) MUST be present, containing the exact " +"commit/revision number that was installed. If the VCS supports commit-hash " +"based revision identifiers, such commit-hash MUST be used as ``commit_id`` " +"in order to reference the immutable version of the source code that was " +"installed." msgstr "" #: ../source/specifications/direct-url.rst:68 -msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" +msgid "" +"When ``url`` refers to a source archive or a wheel, the ``archive_info`` key " +"MUST be present as a dictionary with the following key:" msgstr "" #: ../source/specifications/direct-url.rst:71 -msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." +msgid "" +"A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are " +"unconditionally provided by the latest version of the standard library's " +"``hashlib`` module be used for source archive hashes. At time of writing, " +"that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and " +"'sha512'." msgstr "" #: ../source/specifications/direct-url.rst:78 -msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" +msgid "" +"When ``url`` refers to a local directory, the ``dir_info`` key MUST be " +"present as a dictionary with the following key:" msgstr "" #: ../source/specifications/direct-url.rst:81 -msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." +msgid "" +"``editable`` (type: ``boolean``): ``true`` if the distribution was installed " +"in editable mode, ``false`` otherwise. If absent, default to ``false``." msgstr "" #: ../source/specifications/direct-url.rst:84 -msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." +msgid "" +"When ``url`` refers to a local directory, it MUST have the ``file`` sheme " +"and be compliant with `RFC 8089 `_. In " +"particular, the path component must be absolute. Symbolic links SHOULD be " +"preserved when making relative paths absolute." msgstr "" #: ../source/specifications/direct-url.rst:91 -msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." +msgid "" +"When the requested URL has the file:// scheme and points to a local " +"directory that happens to contain a VCS checkout, installers MUST NOT " +"attempt to infer any VCS information and therefore MUST NOT output any VCS " +"related information (such as ``vcs_info``) in :file:`direct_url.json`." msgstr "" #: ../source/specifications/direct-url.rst:96 -msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." +msgid "" +"A top-level ``subdirectory`` field MAY be present containing a directory " +"path, relative to the root of the VCS repository, source archive or local " +"directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." msgstr "" #: ../source/specifications/direct-url.rst:102 -msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." +msgid "" +"As a general rule, installers should as much as possible preserve the " +"information that was provided in the requested URL when generating :file:" +"`direct_url.json`. For example user:password environment variables should be " +"preserved and ``requested_revision`` should reflect the revision that was " +"provided in the requested URL as faithfully as possible. This information is " +"however *enriched* with more precise data, such as ``commit_id``." msgstr "" #: ../source/specifications/direct-url.rst:110 @@ -7591,7 +11032,14 @@ msgid "Registered VCS" msgstr "" #: ../source/specifications/direct-url.rst:112 -msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." +msgid "" +"This section lists the registered VCS's; expanded, VCS-specific information " +"on how to use the ``vcs``, ``requested_revision``, and other fields of " +"``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY " +"support other VCS's although it is RECOMMENDED to register them by writing a " +"PEP to amend this specification. The ``vcs`` field SHOULD be the command " +"name (lowercased). Additional fields that would be necessary to support such " +"VCS SHOULD be prefixed with the VCS command name." msgstr "" #: ../source/specifications/direct-url.rst:122 @@ -7636,7 +11084,9 @@ msgid "``requested_revision`` field" msgstr "" #: ../source/specifications/direct-url.rst:138 -msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." +msgid "" +"A tag name, branch name, Git ref, commit hash, shortened commit hash, or " +"other commit-ish." msgstr "" #: ../source/specifications/direct-url.rst:141 @@ -7651,7 +11101,11 @@ msgid "A commit hash (40 hexadecimal characters sha1)." msgstr "" #: ../source/specifications/direct-url.rst:147 -msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." +msgid "" +"Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to " +"determine if the ``requested_revision`` corresponds to a Git ref. In turn, a " +"ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning " +"with ``refs/remotes/origin/`` after cloning corresponds to a branch." msgstr "" #: ../source/specifications/direct-url.rst:154 @@ -7710,11 +11164,15 @@ msgid "svn" msgstr "svn" #: ../source/specifications/direct-url.rst:216 -msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." +msgid "" +"``requested_revision`` must be compatible with ``svn checkout`` ``--" +"revision`` option. In Subversion, branch or tag is part of ``url``." msgstr "" #: ../source/specifications/direct-url.rst:221 -msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." +msgid "" +"Since Subversion does not support globally unique identifiers, this field is " +"the Subversion revision number in the corresponding repository." msgstr "" #: ../source/specifications/direct-url.rst:229 @@ -7754,10 +11212,12 @@ msgid "pip install https://example.com/app-1.0.whl" msgstr "pip install https://example.com/app-1.0.whl" #: ../source/specifications/direct-url.rst:283 -msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" +msgid "" +"pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup" +"\"" msgstr "" -"pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=" -"setup\"" +"pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup" +"\"" #: ../source/specifications/direct-url.rst:284 msgid "pip install ./app" @@ -7768,7 +11228,11 @@ msgid "pip install file:///home/user/app" msgstr "pip install file:///home/user/app" #: ../source/specifications/direct-url.rst:286 -msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" +msgid "" +"pip install --editable \"git+https://example.com/repo/app." +"git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local " +"directory where the git repository has been cloned to, and ``dir_info`` will " +"be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" msgstr "" #: ../source/specifications/direct-url.rst:290 @@ -7792,19 +11256,37 @@ msgid "Entry points specification" msgstr "" #: ../source/specifications/entry-points.rst:7 -msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" +msgid "" +"*Entry points* are a mechanism for an installed distribution to advertise " +"components it provides to be discovered and used by other code. For example:" msgstr "" #: ../source/specifications/entry-points.rst:11 -msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." +msgid "" +"Distributions can specify ``console_scripts`` entry points, each referring " +"to a function. When *pip* (or another console_scripts aware installer) " +"installs the distribution, it will create a command-line wrapper for each " +"entry point." msgstr "" #: ../source/specifications/entry-points.rst:14 -msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." +msgid "" +"Applications can use entry points to load plugins; e.g. Pygments (a syntax " +"highlighting tool) can use additional lexers and styles from separately " +"installed packages. For more about this, see :doc:`/guides/creating-and-" +"discovering-plugins`." msgstr "" #: ../source/specifications/entry-points.rst:19 -msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." +msgid "" +"The entry point file format was originally developed to allow packages built " +"with setuptools to provide integration point metadata that would be read at " +"runtime with ``importlib.metadata``. It is now defined as a PyPA " +"interoperability specification in order to allow build tools other than " +"setuptools to publish ``importlib.metadata`` compatible entry point " +"metadata, and runtime libraries other than ``importlib.metadata`` to " +"portably read published entry point metadata (potentially with different " +"caching and conflict resolution strategies)." msgstr "" #: ../source/specifications/entry-points.rst:28 @@ -7816,27 +11298,61 @@ msgid "Conceptually, an entry point is defined by three required properties:" msgstr "" #: ../source/specifications/entry-points.rst:32 -msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." +msgid "" +"The **group** that an entry point belongs to indicates what sort of object " +"it provides. For instance, the group ``console_scripts`` is for entry points " +"referring to functions which can be used as a command, while ``pygments." +"styles`` is the group for classes defining pygments styles. The consumer " +"typically defines the expected interface. To avoid clashes, consumers " +"defining a new group should use names starting with a PyPI name owned by the " +"consumer project, followed by ``.``. Group names must be one or more groups " +"of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w" +"+)*$``)." msgstr "" #: ../source/specifications/entry-points.rst:42 -msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." +msgid "" +"The **name** identifies this entry point within its group. The precise " +"meaning of this is up to the consumer. For console scripts, the name of the " +"entry point is the command that will be used to launch it. Within a " +"distribution, entry point names should be unique. If different distributions " +"provide the same name, the consumer decides how to handle such conflicts. " +"The name may contain any characters except ``=``, but it cannot start or end " +"with any whitespace character, or start with ``[``. For new entry points, it " +"is recommended to use only letters, numbers, underscores, dots and dashes " +"(regex ``[\\w.-]+``)." msgstr "" #: ../source/specifications/entry-points.rst:51 -msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" +msgid "" +"The **object reference** points to a Python object. It is either in the form " +"``importable.module``, or ``importable.module:object.attr``. Each of the " +"parts delimited by dots and the colon is a valid Python identifier. It is " +"intended to be looked up like this::" msgstr "" #: ../source/specifications/entry-points.rst:64 -msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." +msgid "" +"Some tools call this kind of object reference by itself an 'entry point', " +"for want of a better term, especially where it points to a function to " +"launch a program." msgstr "" #: ../source/specifications/entry-points.rst:68 -msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." +msgid "" +"There is also an optional property: the **extras** are a set of strings " +"identifying optional features of the distribution providing the entry point. " +"If these are specified, the entry point requires the dependencies of those " +"'extras'. See the metadata field :ref:`metadata_provides_extra`." msgstr "" #: ../source/specifications/entry-points.rst:73 -msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." +msgid "" +"Using extras for an entry point is no longer recommended. Consumers should " +"support parsing them from existing distributions, but may then ignore them. " +"New publishing tools need not support specifying extras. The functionality " +"of handling extras was tied to setuptools' model of managing 'egg' packages, " +"but newer tools such as pip and virtualenv use a different model." msgstr "" #: ../source/specifications/entry-points.rst:80 @@ -7844,23 +11360,44 @@ msgid "File format" msgstr "" #: ../source/specifications/entry-points.rst:82 -msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." +msgid "" +"Entry points are defined in a file called :file:`entry_points.txt` in the :" +"file:`*.dist-info` directory of the distribution. This is the directory " +"described in :pep:`376` for installed distributions, and in :pep:`427` for " +"wheels. The file uses the UTF-8 character encoding." msgstr "" #: ../source/specifications/entry-points.rst:87 -msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" +msgid "" +"The file contents are in INI format, as read by Python's :mod:`configparser` " +"module. However, configparser treats names as case-insensitive by default, " +"whereas entry point names are case sensitive. A case-sensitive config parser " +"can be made like this::" msgstr "" #: ../source/specifications/entry-points.rst:97 -msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." +msgid "" +"The entry points file must always use ``=`` to delimit names from values " +"(whereas configparser also allows using ``:``)." msgstr "" #: ../source/specifications/entry-points.rst:100 -msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." +msgid "" +"The sections of the config file represent entry point groups, the names are " +"names, and the values encode both the object reference and the optional " +"extras. If extras are used, they are a comma-separated list inside square " +"brackets." msgstr "" #: ../source/specifications/entry-points.rst:104 -msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." +msgid "" +"Within a value, readers must accept and ignore spaces (including multiple " +"consecutive spaces) before or after the colon, between the object reference " +"and the left square bracket, between the extra names and the square brackets " +"and colons delimiting them, and after the right square bracket. The syntax " +"for extras is formally specified as part of :pep:`508` (as ``extras``). For " +"tools writing the file, it is recommended only to insert a space between the " +"object reference and the left square bracket." msgstr "" #: ../source/specifications/entry-points.rst:112 @@ -7872,23 +11409,47 @@ msgid "Use for scripts" msgstr "" #: ../source/specifications/entry-points.rst:126 -msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." +msgid "" +"Two groups of entry points have special significance in packaging: " +"``console_scripts`` and ``gui_scripts``. In both groups, the name of the " +"entry point should be usable as a command in a system shell after the " +"package is installed. The object reference points to a function which will " +"be called with no arguments when this command is run. The function may " +"return an integer to be used as a process exit code, and returning ``None`` " +"is equivalent to returning ``0``." msgstr "" #: ../source/specifications/entry-points.rst:134 -msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" +msgid "" +"For instance, the entry point ``mycmd = mymod:main`` would create a command " +"``mycmd`` launching a script like this::" msgstr "" #: ../source/specifications/entry-points.rst:141 -msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." +msgid "" +"The difference between ``console_scripts`` and ``gui_scripts`` only affects " +"Windows systems. ``console_scripts`` are wrapped in a console executable, so " +"they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and " +"``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI " +"executable, so they can be started without a console, but cannot use " +"standard streams unless application code redirects them. Other platforms do " +"not have the same distinction." msgstr "" #: ../source/specifications/entry-points.rst:149 -msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." +msgid "" +"Install tools are expected to set up wrappers for both ``console_scripts`` " +"and ``gui_scripts`` in the scripts directory of the install scheme. They are " +"not responsible for putting this directory in the ``PATH`` environment " +"variable which defines where command-line tools are found." msgstr "" #: ../source/specifications/entry-points.rst:154 -msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." +msgid "" +"As files are created from the names, and some filesystems are case-" +"insensitive, packages should avoid using names in these groups which differ " +"only in case. The behaviour of install tools when names differ only in case " +"is undefined." msgstr "" #: ../source/specifications/index.rst:4 @@ -7896,7 +11457,11 @@ msgid "PyPA specifications" msgstr "Специфікації PyPA" #: ../source/specifications/index.rst:6 -msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." +msgid "" +"This is a list of currently active interoperability specifications " +"maintained by the Python Packaging Authority. The process for updating these " +"standards, and for proposing new ones, is documented on `pypa.io `__." msgstr "" #: ../source/specifications/index.rst:13 @@ -7916,11 +11481,16 @@ msgid "Platform compatibility tags" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:8 -msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." +msgid "" +"Platform compatibility tags allow build tools to mark distributions as being " +"compatible with specific platforms, and allows installers to understand " +"which distributions are compatible with the system they are running on." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:12 -msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." +msgid "" +"The platform compatibility tagging model used for the ``wheel`` distribution " +"format is defined in :pep:`425`." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:16 @@ -7928,7 +11498,9 @@ msgid "Platform tags for Windows" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:18 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." +msgid "" +"The scheme defined in :pep:`425` covers public distribution of wheel files " +"to systems running Windows." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:22 @@ -7936,7 +11508,9 @@ msgid "Platform tags for macOS (Mac OS X)" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:24 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." +msgid "" +"The scheme defined in :pep:`425` covers public distribution of wheel files " +"to systems running macOS (previously known as Mac OS X)." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:28 @@ -7944,39 +11518,70 @@ msgid "Platform tags for common Linux distributions" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:32 -msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." +msgid "" +"The scheme defined in :pep:`425` is insufficient for public distribution of " +"wheel files (and \\*nix wheel files in general) to Linux platforms, due to " +"the large ecosystem of Linux platforms and subtle differences between them." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:36 -msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." +msgid "" +"Instead, :pep:`600` defines the ``manylinux`` standard, which represents a " +"common subset of Linux platforms, and allows building wheels tagged with the " +"``manylinux`` platform tag which can be used across most common Linux " +"distributions." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:41 -msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" +msgid "" +"There were multiple iterations of the ``manylinux`` specification, each " +"representing the common subset of Linux platforms at a given point in time:" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:44 -msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." +msgid "" +"``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, " +"and is based on a compatible Linux platform from 2007." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:46 -msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." +msgid "" +"``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` " +"architectures. and updates the previous specification to be based on a " +"compatible Linux platform from 2010 instead." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:49 -msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." +msgid "" +"``manylinux2014`` (:pep:`599`) adds support for a number of additional " +"architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and " +"``s390x``) and updates the base platform to a compatible Linux platform from " +"2014." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:54 -msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." +msgid "" +"``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a " +"future-proof standard. It defines ``x`` and ``y`` as glibc major an minor " +"versions supported (e.g. ``manylinux_2_24`` should work on any distro using " +"glibc 2.24+). Previous tags are still supported for backward compatibility." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:59 -msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." +msgid "" +"In general, distributions built for older versions of the specification are " +"forwards-compatible (meaning that ``manylinux1`` distributions should " +"continue to work on modern systems) but not backwards-compatible (meaning " +"that ``manylinux2010`` distributions are not expected to work on platforms " +"that existed before 2010)." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:65 -msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." +msgid "" +"Package maintainers should attempt to target the most compatible " +"specification possible, with the caveat that the provided build environment " +"for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning " +"that these images will no longer receive security updates." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:71 @@ -7984,15 +11589,21 @@ msgid "Manylinux compatibility support" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:74 -msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." +msgid "" +"The ``manylinux2014`` specification is relatively new and is not yet widely " +"recognised by install tools." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:76 -msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." +msgid "" +"The ``manylinux_x_y`` specification is relatively new and is not yet widely " +"recognised by install tools." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:79 -msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" +msgid "" +"The following table shows the minimum versions of relevant projects to " +"support the various ``manylinux`` standards:" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:83 @@ -8056,7 +11667,11 @@ msgid "Platform tags for other \\*nix platforms" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:92 -msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." +msgid "" +"The scheme defined in :pep:`425` is not generally sufficient for public " +"distribution of wheel files to other \\*nix platforms. Efforts are currently " +"(albeit intermittently) under way to define improved compatibility tagging " +"schemes for AIX and for Alpine Linux." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:98 @@ -8068,7 +11683,11 @@ msgid "The :file:`.pypirc` file" msgstr "Файл :file:`.pypirc`" #: ../source/specifications/pypirc.rst:8 -msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." +msgid "" +"A :file:`.pypirc` file allows you to define the configuration for :term:" +"`package indexes ` (referred to here as \"repositories\"), so " +"that you don't have to enter the URL, username, or password whenever you " +"upload a package with :ref:`twine` or :ref:`flit`." msgstr "" #: ../source/specifications/pypirc.rst:13 @@ -8076,7 +11695,9 @@ msgid "The format (originally defined by the :ref:`distutils` package) is:" msgstr "" #: ../source/specifications/pypirc.rst:32 -msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." +msgid "" +"The ``distutils`` section defines an ``index-servers`` field that lists the " +"name of all sections describing a repository." msgstr "" #: ../source/specifications/pypirc.rst:35 @@ -8096,11 +11717,16 @@ msgid "``password``: The password that will used to authenticate the username." msgstr "" #: ../source/specifications/pypirc.rst:43 -msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." +msgid "" +"Be aware that this stores your password in plain text. For better security, " +"consider an alternative like `keyring`_, setting environment variables, or " +"providing the password on the command line." msgstr "" #: ../source/specifications/pypirc.rst:47 -msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" +msgid "" +"Otherwise, set the permissions on :file:`.pypirc` so that only you can view " +"or modify it. For example, on Linux or macOS, run:" msgstr "" #: ../source/specifications/pypirc.rst:57 @@ -8108,15 +11734,23 @@ msgid "Common configurations" msgstr "" #: ../source/specifications/pypirc.rst:61 -msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." +msgid "" +"These examples apply to :ref:`twine`, and projects like :ref:`hatch` that " +"use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`." +"pypirc`, but with different defaults. Please refer to each project's " +"documentation for more details and usage instructions." msgstr "" #: ../source/specifications/pypirc.rst:66 -msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" +msgid "" +"Twine's default configuration mimics a :file:`.pypirc` with repository " +"sections for PyPI and TestPyPI:" msgstr "" #: ../source/specifications/pypirc.rst:82 -msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." +msgid "" +"Twine will add additional configuration from :file:`$HOME/.pypirc`, the " +"command line, and environment variables to this default configuration." msgstr "" #: ../source/specifications/pypirc.rst:86 @@ -8124,11 +11758,15 @@ msgid "Using a PyPI token" msgstr "" #: ../source/specifications/pypirc.rst:88 -msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" +msgid "" +"To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` " +"similar to:" msgstr "" #: ../source/specifications/pypirc.rst:97 -msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." +msgid "" +"For :ref:`TestPyPI `, add a ``[testpypi]`` section, using " +"the API token from your TestPyPI account." msgstr "" #: ../source/specifications/pypirc.rst:103 @@ -8136,11 +11774,16 @@ msgid "Using another package index" msgstr "" #: ../source/specifications/pypirc.rst:105 -msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" +msgid "" +"To configure an additional repository, you'll need to redefine the ``index-" +"servers`` field to include the repository name. Here is a complete example " +"of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" msgstr "" #: ../source/specifications/pypirc.rst:132 -msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" +msgid "" +"Instead of using the ``password`` field, consider saving your API tokens and " +"passwords securely using `keyring`_ (which is installed by Twine):" msgstr "" #: ../source/specifications/recording-installed-packages.rst:5 @@ -8148,11 +11791,20 @@ msgid "Recording installed projects" msgstr "" #: ../source/specifications/recording-installed-packages.rst:7 -msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." +msgid "" +"This document specifies a common format of recording information about " +"Python :term:`projects ` installed in an environment. A common " +"metadata format allows tools to query, manage or uninstall projects, " +"regardless of how they were installed." msgstr "" #: ../source/specifications/recording-installed-packages.rst:12 -msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." +msgid "" +"Almost all information is optional. This allows tools outside the Python " +"ecosystem, such as Linux package managers, to integrate with Python tooling " +"as much as possible. For example, even if an installer cannot easily provide " +"a list of installed files in a format specific to Python tooling, it should " +"still record the name and version of the installed project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:21 @@ -8160,31 +11812,65 @@ msgid "History and change workflow" msgstr "" #: ../source/specifications/recording-installed-packages.rst:23 -msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." +msgid "" +"The metadata described here was first specified in :pep:`376`, and later " +"amended in :pep:`627`. It was formerly known as *Database of Installed " +"Python Distributions*. Further amendments (except trivial language or " +"typography fixes) must be made through the PEP process (see :pep:`1`)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:29 -msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." +msgid "" +"While this document is the normative specification, these PEPs that " +"introduce changes to it may include additional information such as " +"rationales and backwards compatibility considerations." msgstr "" #: ../source/specifications/recording-installed-packages.rst:37 -msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." +msgid "" +"Each project installed from a distribution must, in addition to files, " +"install a \"``.dist-info``\" directory located alongside importable modules " +"and packages (commonly, the ``site-packages`` directory)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:41 -msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." +msgid "" +"This directory is named as ``{name}-{version}.dist-info``, with ``name`` and " +"``version`` fields corresponding to :ref:`core-metadata`. Both fields must " +"be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 " +"<440#normalization>` for the definition of normalization for each field " +"respectively), and replace dash (``-``) characters with underscore (``_``) " +"chacaters, so the ``.dist-info`` directory always has exactly one dash (``-" +"``) character in its stem, separating the ``name`` and ``version`` fields." msgstr "" #: ../source/specifications/recording-installed-packages.rst:50 -msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." +msgid "" +"Historically, tools have failed to replace dot characters or normalize case " +"in the ``name`` field, or not perform normalization in the ``version`` " +"field. Tools consuming ``.dist-info`` directories should expect those fields " +"to be unnormalized, and treat them as equivalent to their normalized " +"counterparts. New tools that write ``.dist-info`` directories MUST normalize " +"both ``name`` and ``version`` fields using the rules described above, and " +"existing tools are encouraged to start normalizing those fields." msgstr "" #: ../source/specifications/recording-installed-packages.rst:60 -msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." +msgid "" +"The ``.dist-info`` directory's name is formatted to unambigiously represent " +"a distribution as a filesystem path. Tools presenting a distribution name to " +"a user should avoid using the normalized name, and instead present the " +"specified name (when needed prior to resolution to an installed package), or " +"read the respective fields in Core Metadata, since values listed there are " +"unescaped and accurately reflect the distribution. Libraries should provide " +"API for such tools to consume, so tools can have access to the unnormalized " +"name when displaying distrubution information." msgstr "" #: ../source/specifications/recording-installed-packages.rst:69 -msgid "This ``.dist-info`` directory can contain these files, described in detail below:" +msgid "" +"This ``.dist-info`` directory can contain these files, described in detail " +"below:" msgstr "" #: ../source/specifications/recording-installed-packages.rst:72 @@ -8196,19 +11882,31 @@ msgid "``RECORD``: records the list of installed files." msgstr "" #: ../source/specifications/recording-installed-packages.rst:74 -msgid "``INSTALLER``: records the name of the tool used to install the project." +msgid "" +"``INSTALLER``: records the name of the tool used to install the project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:76 -msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." +msgid "" +"The ``METADATA`` file is mandatory. All other files may be omitted at the " +"installing tool's discretion. Additional installer-specific files may be " +"present." msgstr "" #: ../source/specifications/recording-installed-packages.rst:82 -msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." +msgid "" +"The :ref:`binary-distribution-format` specification describes additional " +"files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. " +"Such files may be copied to the ``.dist-info`` directory of an installed " +"project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:87 -msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." +msgid "" +"The previous versions of this specification also specified a ``REQUESTED`` " +"file. This file is now considered a tool-specific extension, but may be " +"standardized again in the future. See `PEP 376 `_ for its original meaning." msgstr "" #: ../source/specifications/recording-installed-packages.rst:94 @@ -8216,11 +11914,16 @@ msgid "The METADATA file" msgstr "Файл METADATA" #: ../source/specifications/recording-installed-packages.rst:96 -msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." +msgid "" +"The ``METADATA`` file contains metadata as described in the :ref:`core-" +"metadata` specification, version 1.1 or greater." msgstr "" #: ../source/specifications/recording-installed-packages.rst:99 -msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." +msgid "" +"The ``METADATA`` file is mandatory. If it cannot be created, or if required " +"core metadata is not available, installers must report an error and fail to " +"install the project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:105 @@ -8228,11 +11931,15 @@ msgid "The RECORD file" msgstr "Файл RECORD" #: ../source/specifications/recording-installed-packages.rst:107 -msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." +msgid "" +"The ``RECORD`` file holds the list of installed files. It is a CSV file " +"containing one record (line) per installed file." msgstr "" #: ../source/specifications/recording-installed-packages.rst:110 -msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" +msgid "" +"The CSV dialect must be readable with the default ``reader`` of Python's " +"``csv`` module:" msgstr "" #: ../source/specifications/recording-installed-packages.rst:113 @@ -8248,31 +11955,56 @@ msgid "line terminator: either ``\\r\\n`` or ``\\n``." msgstr "" #: ../source/specifications/recording-installed-packages.rst:117 -msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." +msgid "" +"Each record is composed of three elements: the file's **path**, the **hash** " +"of the contents, and its **size**." msgstr "" #: ../source/specifications/recording-installed-packages.rst:120 -msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." +msgid "" +"The *path* may be either absolute, or relative to the directory containing " +"the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On " +"Windows, directories may be separated either by forward- or backslashes (``/" +"`` or ``\\``)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:125 -msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." +msgid "" +"The *hash* is either an empty string or the name of a hash algorithm from " +"``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` " +"and the digest of the file's contents, encoded with the urlsafe-base64-nopad " +"encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:130 -msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." +msgid "" +"The *size* is either the empty string, or file's size in bytes, as a base 10 " +"integer." msgstr "" #: ../source/specifications/recording-installed-packages.rst:133 -msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." +msgid "" +"For any file, either or both of the *hash* and *size* fields may be left " +"empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself " +"have empty *hash* and *size*. For other files, leaving the information out " +"is discouraged, as it prevents verifying the integrity of the installed " +"project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:139 -msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." +msgid "" +"If the ``RECORD`` file is present, it must list all installed files of the " +"project, except ``.pyc`` files corresponding to ``.py`` files listed in " +"``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` " +"directory (including the ``RECORD`` file itself) must be listed. Directories " +"should not be listed." msgstr "" #: ../source/specifications/recording-installed-packages.rst:146 -msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." +msgid "" +"To completely uninstall a package, a tool needs to remove all files listed " +"in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding " +"to removed ``.py`` files, and any directories emptied by the uninstallation." msgstr "" #: ../source/specifications/recording-installed-packages.rst:151 @@ -8280,7 +12012,11 @@ msgid "Here is an example snippet of a possible ``RECORD`` file::" msgstr "" #: ../source/specifications/recording-installed-packages.rst:170 -msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" +msgid "" +"If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must " +"not atempt to uninstall or upgrade the package. (This does not apply to " +"tools that rely on other sources of information, such as system package " +"managers in Linux distros.)" msgstr "" #: ../source/specifications/recording-installed-packages.rst:177 @@ -8288,7 +12024,11 @@ msgid "The INSTALLER file" msgstr "Файл INSTALLER" #: ../source/specifications/recording-installed-packages.rst:179 -msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." +msgid "" +"If present, ``INSTALLER`` is a single-line text file naming the tool used to " +"install the project. If the installer is executable from the command line, " +"``INSTALLER`` should contain the command name. Otherwise, it should contain " +"a printable ASCII string." msgstr "" #: ../source/specifications/recording-installed-packages.rst:185 @@ -8300,7 +12040,11 @@ msgid "Here are examples of two possible ``INSTALLER`` files::" msgstr "" #: ../source/specifications/recording-installed-packages.rst:195 -msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." +msgid "" +"This value should be used for informational purposes only. For example, if a " +"tool is asked to uninstall a project but finds no ``RECORD`` file, it may " +"suggest that the tool named in ``INSTALLER`` may be able to do the " +"uninstallation." msgstr "" #: ../source/specifications/recording-installed-packages.rst:201 @@ -8308,7 +12052,9 @@ msgid "The direct_url.json file" msgstr "" #: ../source/specifications/recording-installed-packages.rst:203 -msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgid "" +"This file MUST be created by installers when installing a distribution from " +"a requirement specifying a direct URL reference (including a VCS URL)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:209 @@ -8320,7 +12066,12 @@ msgid "Simple repository API" msgstr "" #: ../source/specifications/simple-repository-api.rst:8 -msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." +msgid "" +"The current interface for querying available package versions and retrieving " +"packages from an index server is defined in :pep:`503`, with the addition of " +"\"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` " +"and specifying the interface version provided by an index server in :pep:" +"`629`." msgstr "" #: ../source/specifications/source-distribution-format.rst:6 @@ -8328,11 +12079,22 @@ msgid "Source distribution format" msgstr "" #: ../source/specifications/source-distribution-format.rst:8 -msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." +msgid "" +"The current standard format of source distribution format is identified by " +"the presence of a :file:`pyproject.toml` file in the distribution archive. " +"The layout of such a distribution was originally specified in :pep:`517` and " +"is formally documented here." msgstr "" #: ../source/specifications/source-distribution-format.rst:13 -msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." +msgid "" +"There is also the legacy source distribution format, implicitly defined by " +"the behaviour of ``distutils`` module in the standard library, when " +"executing :command:`setup.py sdist`. This document does not attempt to " +"standardise this format, except to note that if a legacy source distribution " +"contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it " +"MUST follow the rules applicable to source distributions defined in the " +"metadata specification." msgstr "" #: ../source/specifications/source-distribution-format.rst:21 @@ -8344,11 +12106,18 @@ msgid "Source distribution file name" msgstr "" #: ../source/specifications/source-distribution-format.rst:26 -msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." +msgid "" +"The file name of a sdist is not currently standardised, although the *de " +"facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the " +"canonicalized form of the project name (see :pep:`503` for the " +"canonicalization rules) with ``-`` characters replaced with ``_``, and " +"``{version}`` is the project version." msgstr "" #: ../source/specifications/source-distribution-format.rst:31 -msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." +msgid "" +"The name and version components of the filename MUST match the values stored " +"in the metadata contained in the file." msgstr "" #: ../source/specifications/source-distribution-format.rst:35 @@ -8356,15 +12125,27 @@ msgid "Source distribution file format" msgstr "" #: ../source/specifications/source-distribution-format.rst:37 -msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." +msgid "" +"A ``.tar.gz`` source distribution (sdist) contains a single top-level " +"directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the " +"source files of the package. The name and version MUST match the metadata " +"stored in the file. This directory must also contain a :file:`pyproject." +"toml` in the format defined in :ref:`declaring-build-dependencies`, and a " +"``PKG-INFO`` file containing metadata in the format described in the :ref:" +"`core-metadata` specification. The metadata MUST conform to at least version " +"2.2 of the metadata specification." msgstr "" #: ../source/specifications/source-distribution-format.rst:45 -msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." +msgid "" +"No other content of a sdist is required or defined. Build systems can store " +"whatever information they need in the sdist to build the project." msgstr "" #: ../source/specifications/source-distribution-format.rst:48 -msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." +msgid "" +"The tarball should use the modern POSIX.1-2001 pax tar format, which " +"specifies UTF-8 based file names." msgstr "" #: ../source/specifications/version-specifiers.rst:6 @@ -8372,11 +12153,15 @@ msgid "Version specifiers" msgstr "" #: ../source/specifications/version-specifiers.rst:8 -msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." +msgid "" +"Version numbering requirements and the semantics for specifying comparisons " +"between versions are defined in :pep:`440`." msgstr "" #: ../source/specifications/version-specifiers.rst:11 -msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." +msgid "" +"The version specifiers section in this PEP supersedes the version specifiers " +"section in :pep:`345`." msgstr "" #: ../source/support.rst:3 @@ -8384,11 +12169,17 @@ msgid "How to Get Support" msgstr "" #: ../source/support.rst:5 -msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." +msgid "" +"For support related to a specific project, see the links on the :doc:" +"`Projects ` page." msgstr "" #: ../source/support.rst:8 -msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." +msgid "" +"For something more general, or when you're just not sure, please `open an " +"issue `_ on the " +"`packaging-problems `_ " +"repository on GitHub." msgstr "" #: ../source/tutorials/creating-documentation.rst:5 @@ -8396,7 +12187,9 @@ msgid "Creating Documentation" msgstr "" #: ../source/tutorials/creating-documentation.rst:7 -msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." +msgid "" +"This section covers the basics of how to create documentation using " +"`Sphinx`_ and host the documentation for free in `Read The Docs`_." msgstr "" #: ../source/tutorials/creating-documentation.rst:13 @@ -8408,7 +12201,8 @@ msgid "Use ``pip`` to install Sphinx:" msgstr "" #: ../source/tutorials/creating-documentation.rst:28 -msgid "For other installation methods, see this `installation guide`_ by Sphinx." +msgid "" +"For other installation methods, see this `installation guide`_ by Sphinx." msgstr "" #: ../source/tutorials/creating-documentation.rst:33 @@ -8416,7 +12210,8 @@ msgid "Getting Started With Sphinx" msgstr "" #: ../source/tutorials/creating-documentation.rst:35 -msgid "Create a ``docs`` directory inside your project to hold your documentation:" +msgid "" +"Create a ``docs`` directory inside your project to hold your documentation:" msgstr "" #: ../source/tutorials/creating-documentation.rst:42 @@ -8424,15 +12219,21 @@ msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" msgstr "" #: ../source/tutorials/creating-documentation.rst:49 -msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." +msgid "" +"This sets up a source directory, walks you through some basic " +"configurations, and creates an ``index.rst`` file as well as a ``conf.py`` " +"file." msgstr "" #: ../source/tutorials/creating-documentation.rst:51 -msgid "You can add some information about your project in ``index.rst``, then build them:" +msgid "" +"You can add some information about your project in ``index.rst``, then build " +"them:" msgstr "" #: ../source/tutorials/creating-documentation.rst:57 -msgid "For more details on the build process, see this `guide`_ by Read The Docs." +msgid "" +"For more details on the build process, see this `guide`_ by Read The Docs." msgstr "" #: ../source/tutorials/creating-documentation.rst:62 @@ -8440,11 +12241,16 @@ msgid "Other Sources" msgstr "" #: ../source/tutorials/creating-documentation.rst:64 -msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." +msgid "" +"For a more detailed guide on how to use Sphinx and reStructuredText, please " +"see this `documentation tutorial`_ on Hitchhiker's Guide to Python." msgstr "" #: ../source/tutorials/index.rst:4 -msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." +msgid "" +"**Tutorials** are opinionated step-by-step guides to help you get familiar " +"with packaging concepts. For more detailed information on specific packaging " +"topics, see :doc:`/guides/index`." msgstr "" #: ../source/tutorials/installing-packages.rst:5 @@ -8452,11 +12258,22 @@ msgid "Installing Packages" msgstr "" #: ../source/tutorials/installing-packages.rst:7 -msgid "This section covers the basics of how to install Python :term:`packages `." +msgid "" +"This section covers the basics of how to install Python :term:`packages " +"`." msgstr "" #: ../source/tutorials/installing-packages.rst:10 -msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." +msgid "" +"It's important to note that the term \"package\" in this context is being " +"used to describe a bundle of software to be installed (i.e. as a synonym for " +"a :term:`distribution `). It does not to refer to the " +"kind of :term:`package ` that you import in your Python " +"source code (i.e. a container of modules). It is common in the Python " +"community to refer to a :term:`distribution ` using " +"the term \"package\". Using the term \"distribution\" is often not " +"preferred, because it can easily be confused with a Linux distribution, or " +"another larger software distribution like Python itself." msgstr "" #: ../source/tutorials/installing-packages.rst:28 @@ -8464,7 +12281,9 @@ msgid "Requirements for Installing Packages" msgstr "" #: ../source/tutorials/installing-packages.rst:30 -msgid "This section describes the steps to follow before installing other Python packages." +msgid "" +"This section describes the steps to follow before installing other Python " +"packages." msgstr "" #: ../source/tutorials/installing-packages.rst:35 @@ -8472,11 +12291,16 @@ msgid "Ensure you can run Python from the command line" msgstr "" #: ../source/tutorials/installing-packages.rst:37 -msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" +msgid "" +"Before you go any further, make sure you have Python and that the expected " +"version is available from your command line. You can check this by running:" msgstr "" #: ../source/tutorials/installing-packages.rst:53 -msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." +msgid "" +"You should get some output like ``Python 3.6.3``. If you do not have Python, " +"please install the latest 3.x version from `python.org`_ or refer to the " +"`Installing Python`_ section of the Hitchhiker's Guide to Python." msgstr "" #: ../source/tutorials/installing-packages.rst:57 @@ -8484,19 +12308,37 @@ msgid "If you're a newcomer and you get an error like this:" msgstr "" #: ../source/tutorials/installing-packages.rst:66 -msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." +msgid "" +"It's because this command and other suggested commands in this tutorial are " +"intended to be run in a *shell* (also called a *terminal* or *console*). See " +"the Python for Beginners `getting started tutorial`_ for an introduction to " +"using your operating system's shell and interacting with Python." msgstr "" #: ../source/tutorials/installing-packages.rst:72 -msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" +msgid "" +"If you're using an enhanced shell like IPython or the Jupyter notebook, you " +"can run system commands like those in this tutorial by prefacing them with a " +"``!`` character:" msgstr "" #: ../source/tutorials/installing-packages.rst:82 -msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." +msgid "" +"It's recommended to write ``{sys.executable}`` rather than plain ``python`` " +"in order to ensure that commands are run in the Python installation matching " +"the currently running notebook (which may not be the same Python " +"installation that the ``python`` command refers to)." msgstr "" #: ../source/tutorials/installing-packages.rst:87 -msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." +msgid "" +"Due to the way most Linux distributions are handling the Python 3 migration, " +"Linux users using the system Python without creating a virtual environment " +"first should replace the ``python`` command in this tutorial with " +"``python3`` and the ``python -m pip`` command with ``python3 -m pip --" +"user``. Do *not* run any of the commands in this tutorial with ``sudo``: if " +"you get a permissions error, come back to the section on creating virtual " +"environments, set one up, and then continue with the tutorial as written." msgstr "" #: ../source/tutorials/installing-packages.rst:99 @@ -8504,15 +12346,23 @@ msgid "Ensure you can run pip from the command line" msgstr "" #: ../source/tutorials/installing-packages.rst:101 -msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" +msgid "" +"Additionally, you'll need to make sure you have :ref:`pip` available. You " +"can check this by running:" msgstr "" #: ../source/tutorials/installing-packages.rst:116 -msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." +msgid "" +"If you installed Python from source, with an installer from `python.org`_, " +"or via `Homebrew`_ you should already have pip. If you're on Linux and " +"installed using your OS package manager, you may have to install pip " +"separately, see :doc:`/guides/installing-using-linux-tools`." msgstr "" #: ../source/tutorials/installing-packages.rst:124 -msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" +msgid "" +"If ``pip`` isn't already installed, then first try to bootstrap it from the " +"standard library:" msgstr "" #: ../source/tutorials/installing-packages.rst:139 @@ -8520,15 +12370,24 @@ msgid "If that still doesn't allow you to run ``python -m pip``:" msgstr "" #: ../source/tutorials/installing-packages.rst:141 -msgid "Securely Download `get-pip.py `_ [1]_" +msgid "" +"Securely Download `get-pip.py `_ [1]_" msgstr "" #: ../source/tutorials/installing-packages.rst:144 -msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." +msgid "" +"Run ``python get-pip.py``. [2]_ This will install or upgrade pip. " +"Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're " +"not installed already." msgstr "" #: ../source/tutorials/installing-packages.rst:150 -msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." +msgid "" +"Be cautious if you're using a Python install that's managed by your " +"operating system or another package manager. get-pip.py does not coordinate " +"with those tools, and may leave your system in an inconsistent state. You " +"can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/" +"local`` which is designed for locally-installed software." msgstr "" #: ../source/tutorials/installing-packages.rst:159 @@ -8536,7 +12395,10 @@ msgid "Ensure pip, setuptools, and wheel are up to date" msgstr "" #: ../source/tutorials/installing-packages.rst:161 -msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" +msgid "" +"While ``pip`` alone is sufficient to install from pre-built binary archives, " +"up to date copies of the ``setuptools`` and ``wheel`` projects are useful to " +"ensure you can also install from source archives::" msgstr "" #: ../source/tutorials/installing-packages.rst:169 @@ -8544,11 +12406,17 @@ msgid "Optionally, create a virtual environment" msgstr "" #: ../source/tutorials/installing-packages.rst:171 -msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" +msgid "" +"See :ref:`section below ` for " +"details, but here's the basic `venv`_ [3]_ command to use on a typical Linux " +"system:" msgstr "" #: ../source/tutorials/installing-packages.rst:188 -msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." +msgid "" +"This will create a new virtual environment in the ``tutorial_env`` " +"subdirectory, and configure the current shell to use it as the default " +"``python`` environment." msgstr "" #: ../source/tutorials/installing-packages.rst:195 @@ -8556,35 +12424,62 @@ msgid "Creating Virtual Environments" msgstr "" #: ../source/tutorials/installing-packages.rst:197 -msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." +msgid "" +"Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular " +"application, rather than being installed globally. If you are looking to " +"safely install global command line tools, see :doc:`/guides/installing-stand-" +"alone-command-line-tools`." msgstr "" #: ../source/tutorials/installing-packages.rst:203 -msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." +msgid "" +"Imagine you have an application that needs version 1 of LibFoo, but another " +"application requires version 2. How can you use both these applications? If " +"you install everything into /usr/lib/python3.6/site-packages (or whatever " +"your platform’s standard location is), it’s easy to end up in a situation " +"where you unintentionally upgrade an application that shouldn’t be upgraded." msgstr "" #: ../source/tutorials/installing-packages.rst:209 -msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." +msgid "" +"Or more generally, what if you want to install an application and leave it " +"be? If an application works, any change in its libraries or the versions of " +"those libraries can break the application." msgstr "" #: ../source/tutorials/installing-packages.rst:213 -msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." +msgid "" +"Also, what if you can’t install :term:`packages ` into " +"the global site-packages directory? For instance, on a shared host." msgstr "" #: ../source/tutorials/installing-packages.rst:216 -msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." +msgid "" +"In all these cases, virtual environments can help you. They have their own " +"installation directories and they don’t share libraries with other virtual " +"environments." msgstr "" #: ../source/tutorials/installing-packages.rst:220 -msgid "Currently, there are two common tools for creating Python virtual environments:" +msgid "" +"Currently, there are two common tools for creating Python virtual " +"environments:" msgstr "" #: ../source/tutorials/installing-packages.rst:222 -msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." +msgid "" +"`venv`_ is available by default in Python 3.3 and later, and installs :ref:" +"`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 " +"and later." msgstr "" #: ../source/tutorials/installing-packages.rst:225 -msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." +msgid "" +":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ " +"and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are " +"always installed into created virtual environments by default (regardless of " +"Python version)." msgstr "" #: ../source/tutorials/installing-packages.rst:230 @@ -8600,19 +12495,31 @@ msgid "Using :ref:`virtualenv`:" msgstr "" #: ../source/tutorials/installing-packages.rst:264 -msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." +msgid "" +"For more information, see the `venv`_ docs or the `virtualenv `_ docs." msgstr "" #: ../source/tutorials/installing-packages.rst:266 -msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." +msgid "" +"The use of :command:`source` under Unix shells ensures that the virtual " +"environment's variables are set within the current shell, and not in a " +"subprocess (which then disappears, having no useful effect)." msgstr "" #: ../source/tutorials/installing-packages.rst:271 -msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" +msgid "" +"In both of the above cases, Windows users should _not_ use the :command:" +"`source` command, but should rather run the :command:`activate` script " +"directly from the command shell like so:" msgstr "" #: ../source/tutorials/installing-packages.rst:281 -msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." +msgid "" +"Managing multiple virtual environments directly can become tedious, so the :" +"ref:`dependency management tutorial ` introduces a " +"higher level tool, :ref:`Pipenv`, that automatically manages a separate " +"virtual environment for each project and application that you work on." msgstr "" #: ../source/tutorials/installing-packages.rst:288 @@ -8620,7 +12527,11 @@ msgid "Use pip for Installing" msgstr "" #: ../source/tutorials/installing-packages.rst:290 -msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." +msgid "" +":ref:`pip` is the recommended installer. Below, we'll cover the most common " +"usage scenarios. For more detail, see the `pip docs `_, " +"which includes a complete `Reference Guide `_." msgstr "" #: ../source/tutorials/installing-packages.rst:297 @@ -8628,7 +12539,14 @@ msgid "Installing from PyPI" msgstr "" #: ../source/tutorials/installing-packages.rst:299 -msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." +msgid "" +"The most common usage of :ref:`pip` is to install from the :term:`Python " +"Package Index ` using a :term:`requirement " +"specifier `. Generally speaking, a requirement " +"specifier is composed of a project name followed by an optional :term:" +"`version specifier `. :pep:`440` contains a :pep:`full " +"specification <440#version-specifiers>` of the currently supported " +"specifiers. Below are some examples." msgstr "" #: ../source/tutorials/installing-packages.rst:307 @@ -8644,11 +12562,15 @@ msgid "To install greater than or equal to one version and less than another:" msgstr "" #: ../source/tutorials/installing-packages.rst:350 -msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" +msgid "" +"To install a version that's :pep:`\"compatible\" <440#compatible-release>` " +"with a certain version: [4]_" msgstr "" #: ../source/tutorials/installing-packages.rst:365 -msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." +msgid "" +"In this case, this means to install any version \"==1.4.*\" version that's " +"also \">=1.4.2\"." msgstr "" #: ../source/tutorials/installing-packages.rst:370 @@ -8656,15 +12578,27 @@ msgid "Source Distributions vs Wheels" msgstr "" #: ../source/tutorials/installing-packages.rst:372 -msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." +msgid "" +":ref:`pip` can install from either :term:`Source Distributions (sdist) " +"` or :term:`Wheels `, but if both " +"are present on PyPI, pip will prefer a compatible :term:`wheel `. You " +"can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." msgstr "" #: ../source/tutorials/installing-packages.rst:378 -msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." +msgid "" +":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source " +"Distributions (sdist) `, especially when " +"a project contains compiled extensions." msgstr "" #: ../source/tutorials/installing-packages.rst:383 -msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." +msgid "" +"If :ref:`pip` does not find a wheel to install, it will locally build a " +"wheel and cache it for future installs, instead of rebuilding the source " +"distribution in the future." msgstr "" #: ../source/tutorials/installing-packages.rst:391 @@ -8676,31 +12610,58 @@ msgid "Installing to the User Site" msgstr "" #: ../source/tutorials/installing-packages.rst:410 -msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" +msgid "" +"To install :term:`packages ` that are isolated to the " +"current user, use the ``--user`` flag:" msgstr "" #: ../source/tutorials/installing-packages.rst:425 -msgid "For more information see the `User Installs `_ section from the pip docs." +msgid "" +"For more information see the `User Installs `_ section from the pip docs." msgstr "" #: ../source/tutorials/installing-packages.rst:429 -msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." +msgid "" +"Note that the ``--user`` flag has no effect when inside a virtual " +"environment - all installation commands will affect the virtual environment." msgstr "" #: ../source/tutorials/installing-packages.rst:432 -msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" +msgid "" +"If ``SomeProject`` defines any command-line scripts or console entry points, " +"``--user`` will cause them to be installed inside the `user base`_'s binary " +"directory, which may or may not already be present in your shell's :envvar:" +"`PATH`. (Starting in version 10, pip displays a warning when installing any " +"scripts to a directory outside :envvar:`PATH`.) If the scripts are not " +"available in your shell after installation, you'll need to add the directory " +"to your :envvar:`PATH`:" msgstr "" #: ../source/tutorials/installing-packages.rst:440 -msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." +msgid "" +"On Linux and macOS you can find the user base binary directory by running " +"``python -m site --user-base`` and adding ``bin`` to the end. For example, " +"this will typically print ``~/.local`` (with ``~`` expanded to the absolute " +"path to your home directory) so you'll need to add ``~/.local/bin`` to your " +"``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." msgstr "" #: ../source/tutorials/installing-packages.rst:446 -msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." +msgid "" +"On Windows you can find the user base binary directory by running ``py -m " +"site --user-site`` and replacing ``site-packages`` with ``Scripts``. For " +"example, this could return ``C:\\Users\\Username\\AppData\\Roaming" +"\\Python36\\site-packages`` so you would need to set your ``PATH`` to " +"include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You " +"can set your user ``PATH`` permanently in the `Control Panel`_. You may need " +"to log out for the ``PATH`` changes to take effect." msgstr "" #: ../source/tutorials/installing-packages.rst:462 -msgid "Install a list of requirements specified in a :ref:`Requirements File `." +msgid "" +"Install a list of requirements specified in a :ref:`Requirements File `." msgstr "" #: ../source/tutorials/installing-packages.rst:478 @@ -8708,7 +12669,9 @@ msgid "Installing from VCS" msgstr "" #: ../source/tutorials/installing-packages.rst:480 -msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." +msgid "" +"Install a project from VCS in \"editable\" mode. For a full breakdown of " +"the syntax, see pip's section on :ref:`VCS Support `." msgstr "" #: ../source/tutorials/installing-packages.rst:502 @@ -8720,7 +12683,9 @@ msgid "Install from an alternate index" msgstr "" #: ../source/tutorials/installing-packages.rst:518 -msgid "Search an additional index during install, in addition to :term:`PyPI `" +msgid "" +"Search an additional index during install, in addition to :term:`PyPI " +"`" msgstr "" #: ../source/tutorials/installing-packages.rst:534 @@ -8728,7 +12693,11 @@ msgid "Installing from a local src tree" msgstr "" #: ../source/tutorials/installing-packages.rst:537 -msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." +msgid "" +"Installing from local src in `Development Mode `_, i.e. in such a " +"way that the project appears to be installed, but yet is still editable from " +"the src tree." msgstr "" #: ../source/tutorials/installing-packages.rst:554 @@ -8740,7 +12709,9 @@ msgid "Install a particular source archive file." msgstr "" #: ../source/tutorials/installing-packages.rst:585 -msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" +msgid "" +"Install from a local directory containing archives (and don't check :term:" +"`PyPI `)" msgstr "" #: ../source/tutorials/installing-packages.rst:605 @@ -8748,7 +12719,11 @@ msgid "Installing from other sources" msgstr "" #: ../source/tutorials/installing-packages.rst:607 -msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." +msgid "" +"To install from other data sources (for example Amazon S3 storage) you can " +"create a helper application that presents the data in a :pep:`503` compliant " +"index format, and use the ``--extra-index-url`` flag to direct pip to use " +"that index." msgstr "" #: ../source/tutorials/installing-packages.rst:619 @@ -8756,7 +12731,9 @@ msgid "Installing Prereleases" msgstr "" #: ../source/tutorials/installing-packages.rst:621 -msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." +msgid "" +"Find pre-release and development versions, in addition to stable versions. " +"By default, pip only finds stable versions." msgstr "" #: ../source/tutorials/installing-packages.rst:637 @@ -8768,15 +12745,23 @@ msgid "Install `setuptools extras`_." msgstr "" #: ../source/tutorials/installing-packages.rst:659 -msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." +msgid "" +"\"Secure\" in this context means using a modern browser or a tool like :" +"command:`curl` that verifies SSL certificates when downloading from https " +"URLs." msgstr "" #: ../source/tutorials/installing-packages.rst:668 -msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." +msgid "" +"Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:" +"`virtualenv`) will create virtualenv environments with ``pip`` pre-" +"installed, thereby making it an equal alternative to :ref:`virtualenv`." msgstr "" #: ../source/tutorials/installing-packages.rst:673 -msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" +msgid "" +"The compatible release specifier was accepted in :pep:`440` and support was " +"released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" msgstr "" #: ../source/tutorials/managing-dependencies.rst:4 @@ -8784,23 +12769,42 @@ msgid "Managing Application Dependencies" msgstr "" #: ../source/tutorials/managing-dependencies.rst:6 -msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." +msgid "" +"The :ref:`package installation tutorial ` covered the " +"basics of getting set up to install and update Python packages." msgstr "" #: ../source/tutorials/managing-dependencies.rst:9 -msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." +msgid "" +"However, running these commands interactively can get tedious even for your " +"own personal projects, and things get even more difficult when trying to set " +"up development environments automatically for projects with multiple " +"contributors." msgstr "" #: ../source/tutorials/managing-dependencies.rst:13 -msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." +msgid "" +"This tutorial walks you through the use of :ref:`Pipenv` to manage " +"dependencies for an application. It will show you how to install and use the " +"necessary tools and make strong recommendations on best practices." msgstr "" #: ../source/tutorials/managing-dependencies.rst:17 -msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." +msgid "" +"Keep in mind that Python is used for a great many different purposes, and " +"precisely how you want to manage your dependencies may change based on how " +"you decide to publish your software. The guidance presented here is most " +"directly applicable to the development and deployment of network services " +"(including web applications), but is also very well suited to managing " +"development and testing environments for any kind of project." msgstr "" #: ../source/tutorials/managing-dependencies.rst:24 -msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." +msgid "" +"Developers of Python libraries, or of applications that support distribution " +"as Python libraries, should also consider the `poetry `_ project as an alternative dependency management " +"solution." msgstr "" #: ../source/tutorials/managing-dependencies.rst:30 @@ -8808,7 +12812,12 @@ msgid "Installing Pipenv" msgstr "" #: ../source/tutorials/managing-dependencies.rst:32 -msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." +msgid "" +":ref:`Pipenv` is a dependency manager for Python projects. If you're " +"familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit " +"to those tools. While :ref:`pip` alone is often sufficient for personal use, " +"Pipenv is recommended for collaborative projects as it's a higher-level tool " +"that simplifies dependency management for common use cases." msgstr "" #: ../source/tutorials/managing-dependencies.rst:38 @@ -8816,7 +12825,11 @@ msgid "Use ``pip`` to install Pipenv:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:54 -msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." +msgid "" +"This does a `user installation`_ to prevent breaking any system-wide " +"packages. If ``pipenv`` isn't available in your shell after installation, " +"you'll need to add the `user base`_'s binary directory to your ``PATH``. " +"See :ref:`Installing to the User Site` for more information." msgstr "" #: ../source/tutorials/managing-dependencies.rst:65 @@ -8824,11 +12837,19 @@ msgid "Installing packages for your project" msgstr "" #: ../source/tutorials/managing-dependencies.rst:67 -msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" +msgid "" +"Pipenv manages dependencies on a per-project basis. To install packages, " +"change into your project's directory (or just an empty directory for this " +"tutorial) and run:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:76 -msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" +msgid "" +"Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you " +"in your project's directory. The :ref:`Pipfile` is used to track which " +"dependencies your project needs in case you need to re-install them, such as " +"when you share your project with others. You should get output similar to " +"this (although the exact paths shown will vary):" msgstr "" #: ../source/tutorials/managing-dependencies.rst:112 @@ -8836,7 +12857,9 @@ msgid "Using installed packages" msgstr "" #: ../source/tutorials/managing-dependencies.rst:114 -msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" +msgid "" +"Now that Requests is installed you can create a simple :file:`main.py` file " +"to use it:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:125 @@ -8848,7 +12871,10 @@ msgid "You should get output similar to this:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:137 -msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." +msgid "" +"Using ``pipenv run`` ensures that your installed packages are available to " +"your script. It's also possible to spawn a new shell that ensures all " +"commands have access to your installed packages with ``pipenv shell``." msgstr "" #: ../source/tutorials/managing-dependencies.rst:143 @@ -8857,15 +12883,24 @@ msgid "Next steps" msgstr "Наступні кроки" #: ../source/tutorials/managing-dependencies.rst:145 -msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" +msgid "" +"Congratulations, you now know how to effectively manage dependencies and " +"development environments on a collaborative Python project! ✨ 🍰 ✨" msgstr "" #: ../source/tutorials/managing-dependencies.rst:148 -msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." +msgid "" +"If you're interested in creating and distributing your own Python packages, " +"see the :ref:`tutorial on packaging and distributing packages `." msgstr "" #: ../source/tutorials/managing-dependencies.rst:151 -msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." +msgid "" +"Note that when your application includes definitions of Python source " +"packages, they (and their dependencies) can be added to your ``pipenv`` " +"environment with ``pipenv install -e `` " +"(e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." msgstr "" #: ../source/tutorials/managing-dependencies.rst:160 @@ -8873,23 +12908,43 @@ msgid "Other Tools for Application Dependency Management" msgstr "" #: ../source/tutorials/managing-dependencies.rst:162 -msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" +msgid "" +"If you find this particular approach to managing application dependencies " +"isn't working well for you or your use case, you may want to explore these " +"other tools and techniques to see if one of them is a better fit:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:166 -msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." +msgid "" +"`poetry `__ for a tool comparable " +"in scope to ``pipenv`` that focuses more directly on use cases where the " +"repository being managed is structured as a Python project with a valid " +"``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making " +"the assumption that the application being worked on that's depending on " +"components from PyPI will itself support distribution as a ``pip``-" +"installable Python package)." msgstr "" #: ../source/tutorials/managing-dependencies.rst:172 -msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" +msgid "" +"`hatch `_ for opinionated coverage of even " +"more steps in the project management workflow (such as incrementing " +"versions, tagging releases, and creating new skeleton projects from project " +"templates)" msgstr "" #: ../source/tutorials/managing-dependencies.rst:175 -msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" +msgid "" +"`pip-tools `_ to build your own " +"custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" msgstr "" #: ../source/tutorials/managing-dependencies.rst:177 -msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." +msgid "" +"`micropipenv `_ is a " +"lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry " +"lock files or converting them to pip-tools compatible output. Designed for " +"containerized Python applications but not limited to them." msgstr "" #: ../source/tutorials/packaging-projects.rst:2 @@ -8897,15 +12952,24 @@ msgid "Packaging Python Projects" msgstr "" #: ../source/tutorials/packaging-projects.rst:4 -msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." +msgid "" +"This tutorial walks you through how to package a simple Python project. It " +"will show you how to add the necessary files and structure to create the " +"package, how to build the package, and how to upload it to the Python " +"Package Index." msgstr "" #: ../source/tutorials/packaging-projects.rst:10 -msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" +msgid "" +"If you have trouble running the commands in this tutoral, please copy the " +"command and its output, then `open an issue`_ on the `packaging-problems`_ " +"repository on GitHub. We'll do our best to help you!" msgstr "" #: ../source/tutorials/packaging-projects.rst:18 -msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" +msgid "" +"Some of the commands require a newer version of :ref:`pip`, so start by " +"making sure you have the latest version installed:" msgstr "" #: ../source/tutorials/packaging-projects.rst:35 @@ -8913,7 +12977,10 @@ msgid "A simple project" msgstr "" #: ../source/tutorials/packaging-projects.rst:37 -msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." +msgid "" +"This tutorial uses a simple project named ``example_package``. We recommend " +"following this tutorial as-is using this project, before packaging your own " +"project." msgstr "" #: ../source/tutorials/packaging-projects.rst:41 @@ -8921,19 +12988,29 @@ msgid "Create the following file structure locally:" msgstr "" #: ../source/tutorials/packaging-projects.rst:51 -msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." +msgid "" +":file:`__init__.py` is required to import the directory as a package, and " +"should be empty." msgstr "" #: ../source/tutorials/packaging-projects.rst:54 -msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" +msgid "" +":file:`example.py` is an example of a module within the package that could " +"contain the logic (functions, classes, constants, etc.) of your package. " +"Open that file and enter the following content:" msgstr "" #: ../source/tutorials/packaging-projects.rst:63 -msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." +msgid "" +"If you are unfamiliar with Python's :term:`modules ` and :term:" +"`import packages `, take a few minutes to read over the " +"`Python documentation for packages and modules`_." msgstr "" #: ../source/tutorials/packaging-projects.rst:67 -msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." +msgid "" +"Once you create this structure, you'll want to run all of the commands in " +"this tutorial within the ``packaging_tutorial`` directory." msgstr "" #: ../source/tutorials/packaging-projects.rst:75 @@ -8941,7 +13018,9 @@ msgid "Creating the package files" msgstr "" #: ../source/tutorials/packaging-projects.rst:77 -msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" +msgid "" +"You will now add files that are used to prepare the project for " +"distribution. When you're done, the project structure will look like this:" msgstr "" #: ../source/tutorials/packaging-projects.rst:95 @@ -8957,15 +13036,26 @@ msgid "Creating pyproject.toml" msgstr "" #: ../source/tutorials/packaging-projects.rst:103 -msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" +msgid "" +":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) " +"what is required to build your project. This tutorial uses :ref:" +"`setuptools`, so open :file:`pyproject.toml` and enter the following content:" msgstr "" #: ../source/tutorials/packaging-projects.rst:117 -msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." +msgid "" +"``build-system.requires`` gives a list of packages that are needed to build " +"your package. Listing something here will *only* make it available during " +"the build, not after it is installed." msgstr "" #: ../source/tutorials/packaging-projects.rst:121 -msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." +msgid "" +"``build-system.build-backend`` is the name of Python object that will be " +"used to perform the build. If you were to use a different build system, such " +"as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration " +"details would be completely different than the :ref:`setuptools` " +"configuration described below." msgstr "" #: ../source/tutorials/packaging-projects.rst:127 @@ -8981,41 +13071,74 @@ msgid "There are two types of metadata: static and dynamic." msgstr "" #: ../source/tutorials/packaging-projects.rst:135 -msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." +msgid "" +"Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. " +"This is simpler, easier to read, and avoids many common errors, like " +"encoding errors." msgstr "" #: ../source/tutorials/packaging-projects.rst:137 -msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." +msgid "" +"Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items " +"that are dynamic or determined at install-time, as well as extension modules " +"or extensions to setuptools, need to go into :file:`setup.py`." msgstr "" #: ../source/tutorials/packaging-projects.rst:141 -msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." +msgid "" +"Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:" +"file:`setup.py`) should be used only as an escape hatch when absolutely " +"necessary. :file:`setup.py` used to be required, but can be omitted with " +"newer versions of setuptools and pip." msgstr "" #: ../source/tutorials/packaging-projects.rst:148 -msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." +msgid "" +":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells " +"setuptools about your package (such as the name and version) as well as " +"which code files to include. Eventually much of this configuration may be " +"able to move to :file:`pyproject.toml`." msgstr "" #: ../source/tutorials/packaging-projects.rst:153 -msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgid "" +"Open :file:`setup.cfg` and enter the following content. Change the ``name`` " +"to include your username; this ensures that you have a unique package name " +"and that your package doesn't conflict with packages uploaded by other " +"people following this tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:185 -msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" +msgid "" +"There are a `variety of metadata and options `_ supported here. This is " +"in :doc:`configparser ` format; do not place " +"quotes around values. This example package uses a relatively minimal set of " +"``metadata``:" msgstr "" #: ../source/tutorials/packaging-projects.rst:191 #: ../source/tutorials/packaging-projects.rst:286 -msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." +msgid "" +"``name`` is the *distribution name* of your package. This can be any name as " +"long as it only contains letters, numbers, ``_`` , and ``-``. It also must " +"not already be taken on pypi.org. **Be sure to update this with your " +"username,** as this ensures you won't try to upload a package with the same " +"name as one which already exists." msgstr "" #: ../source/tutorials/packaging-projects.rst:196 -msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." +msgid "" +"``version`` is the package version. See :pep:`440` for more details on " +"versions. You can use ``file:`` or ``attr:`` directives to read from a file " +"or package attribute." msgstr "" #: ../source/tutorials/packaging-projects.rst:199 #: ../source/tutorials/packaging-projects.rst:293 -msgid "``author`` and ``author_email`` are used to identify the author of the package." +msgid "" +"``author`` and ``author_email`` are used to identify the author of the " +"package." msgstr "" #: ../source/tutorials/packaging-projects.rst:201 @@ -9024,27 +13147,45 @@ msgid "``description`` is a short, one-sentence summary of the package." msgstr "" #: ../source/tutorials/packaging-projects.rst:202 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." +msgid "" +"``long_description`` is a detailed description of the package. This is shown " +"on the package detail page on the Python Package Index. In this case, the " +"long description is loaded from :file:`README.md` (which is a common " +"pattern) using the ``file:`` directive." msgstr "" #: ../source/tutorials/packaging-projects.rst:206 #: ../source/tutorials/packaging-projects.rst:300 -msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." +msgid "" +"``long_description_content_type`` tells the index what type of markup is " +"used for the long description. In this case, it's Markdown." msgstr "" #: ../source/tutorials/packaging-projects.rst:208 #: ../source/tutorials/packaging-projects.rst:302 -msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." +msgid "" +"``url`` is the URL for the homepage of the project. For many projects, this " +"will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting " +"service." msgstr "" #: ../source/tutorials/packaging-projects.rst:211 #: ../source/tutorials/packaging-projects.rst:305 -msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." +msgid "" +"``project_urls`` lets you list any number of extra links to show on PyPI. " +"Generally this could be to documentation, issue trackers, etc." msgstr "" #: ../source/tutorials/packaging-projects.rst:213 #: ../source/tutorials/packaging-projects.rst:307 -msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." +msgid "" +"``classifiers`` gives the index and :ref:`pip` some additional metadata " +"about your package. In this case, the package is only compatible with Python " +"3, is licensed under the MIT license, and is OS-independent. You should " +"always include at least which version(s) of Python your package works on, " +"which license your package is available under, and which operating systems " +"your package will work on. For a complete list of classifiers, see https://" +"pypi.org/classifiers/." msgstr "" #: ../source/tutorials/packaging-projects.rst:221 @@ -9052,52 +13193,96 @@ msgid "In the ``options`` category, we have controls for setuptools itself:" msgstr "" #: ../source/tutorials/packaging-projects.rst:223 -msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgid "" +"``package_dir`` is a mapping of package names and directories. An empty " +"package name represents the \"root package\" --- the directory in the " +"project that contains all Python source files for the package --- so in this " +"case the ``src`` directory is designated the root package." msgstr "" #: ../source/tutorials/packaging-projects.rst:227 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgid "" +"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " +"`. Instead of listing each package manually, we can " +"use the ``find:`` directive to automatically discover all packages and " +"subpackages and ``options.packages.find`` to specify the ``package_dir`` to " +"use. In this case, the list of packages will be ``example_package`` as " +"that's the only package present." msgstr "" #: ../source/tutorials/packaging-projects.rst:234 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." +msgid "" +"``python_requires`` gives the versions of Python supported by your project. " +"Installers like :ref:`pip` will look back through older versions of packages " +"until it finds one that has a matching Python version." msgstr "" #: ../source/tutorials/packaging-projects.rst:238 #: ../source/tutorials/packaging-projects.rst:329 -msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." +msgid "" +"There are many more than the ones mentioned here. See :doc:`/guides/" +"distributing-packages-using-setuptools` for more details." msgstr "" #: ../source/tutorials/packaging-projects.rst:244 -msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." +msgid "" +":file:`setup.py` is the build script for :ref:`setuptools`. It tells " +"setuptools about your package (such as the name and version) as well as " +"which code files to include." msgstr "" #: ../source/tutorials/packaging-projects.rst:248 -msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgid "" +"Open :file:`setup.py` and enter the following content. Change the ``name`` " +"to include your username; this ensures that you have a unique package name " +"and that your package doesn't conflict with packages uploaded by other " +"people following this tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:283 -msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" +msgid "" +":func:`setup` takes several arguments. This example package uses a " +"relatively minimal set:" msgstr "" #: ../source/tutorials/packaging-projects.rst:291 -msgid "``version`` is the package version. See :pep:`440` for more details on versions." +msgid "" +"``version`` is the package version. See :pep:`440` for more details on " +"versions." msgstr "" #: ../source/tutorials/packaging-projects.rst:296 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." +msgid "" +"``long_description`` is a detailed description of the package. This is shown " +"on the package detail page on the Python Package Index. In this case, the " +"long description is loaded from :file:`README.md`, which is a common pattern." msgstr "" #: ../source/tutorials/packaging-projects.rst:314 -msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgid "" +"``package_dir`` is a dictionary with package names for keys and directories " +"for values. An empty package name represents the \"root package\" --- the " +"directory in the project that contains all Python source files for the " +"package --- so in this case the ``src`` directory is designated the root " +"package." msgstr "" #: ../source/tutorials/packaging-projects.rst:319 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgid "" +"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " +"`. Instead of listing each package manually, we can " +"use :func:`find_packages` to automatically discover all packages and " +"subpackages under ``package_dir``. In this case, the list of packages will " +"be ``example_package`` as that's the only package present." msgstr "" #: ../source/tutorials/packaging-projects.rst:325 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." +msgid "" +"``python_requires`` gives the versions of Python supported by your project. " +"Installers like :ref:`pip` will look back though older versions of packages " +"until it finds one that has a matching Python version." msgstr "" #: ../source/tutorials/packaging-projects.rst:333 @@ -9105,11 +13290,17 @@ msgid "Creating README.md" msgstr "" #: ../source/tutorials/packaging-projects.rst:335 -msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." +msgid "" +"Open :file:`README.md` and enter the following content. You can customize " +"this if you'd like." msgstr "" #: ../source/tutorials/packaging-projects.rst:347 -msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." +msgid "" +"Because our configuration loads :file:`README.md` to provide a " +"``long_description``, :file:`README.md` must be included along with your " +"code when you :ref:`generate a source distribution `. " +"Newer versions of :ref:`setuptools` will do this automatically." msgstr "" #: ../source/tutorials/packaging-projects.rst:354 @@ -9117,7 +13308,12 @@ msgid "Creating a LICENSE" msgstr "" #: ../source/tutorials/packaging-projects.rst:356 -msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" +msgid "" +"It's important for every package uploaded to the Python Package Index to " +"include a license. This tells users who install your package the terms under " +"which they can use your package. For help picking a license, see https://" +"choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` " +"and enter the license text. For example, if you had chosen the MIT license:" msgstr "" #: ../source/tutorials/packaging-projects.rst:387 @@ -9125,11 +13321,19 @@ msgid "Including other files" msgstr "" #: ../source/tutorials/packaging-projects.rst:389 -msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." +msgid "" +"The files listed above will be included automatically in your :term:`source " +"distribution `. If you want to control " +"what goes in this explicitly, see :ref:`Using MANIFEST.in`." msgstr "" #: ../source/tutorials/packaging-projects.rst:393 -msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." +msgid "" +"The final :term:`built distribution ` will have the " +"Python files in the discovered or listed Python packages. If you want to " +"control what goes here, such as to add data files, see :doc:`Including Data " +"Files ` from the :doc:`setuptools docs " +"`." msgstr "" #: ../source/tutorials/packaging-projects.rst:402 @@ -9137,7 +13341,10 @@ msgid "Generating distribution archives" msgstr "" #: ../source/tutorials/packaging-projects.rst:404 -msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." +msgid "" +"The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the " +"Python Package Index and can be installed by :ref:`pip`." msgstr "" #: ../source/tutorials/packaging-projects.rst:408 @@ -9145,19 +13352,32 @@ msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" msgstr "" #: ../source/tutorials/packaging-projects.rst:422 -msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." +msgid "" +"If you have trouble installing these, see the :doc:`installing-packages` " +"tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:425 -msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" +msgid "" +"Now run this command from the same directory where :file:`pyproject.toml` is " +"located:" msgstr "" #: ../source/tutorials/packaging-projects.rst:439 -msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" +msgid "" +"This command should output a lot of text and once completed should generate " +"two files in the :file:`dist` directory:" msgstr "" #: ../source/tutorials/packaging-projects.rst:449 -msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." +msgid "" +"The ``tar.gz`` file is a :term:`source archive ` whereas the " +"``.whl`` file is a :term:`built distribution `. Newer :" +"ref:`pip` versions preferentially install built distributions, but will fall " +"back to source archives if needed. You should always upload a source archive " +"and provide built archives for the platforms your project is compatible " +"with. In this case, our example package is compatible with Python on any " +"platform so only one built distribution is needed." msgstr "" #: ../source/tutorials/packaging-projects.rst:458 @@ -9169,23 +13389,40 @@ msgid "Finally, it's time to upload your package to the Python Package Index!" msgstr "" #: ../source/tutorials/packaging-projects.rst:462 -msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." +msgid "" +"The first thing you'll need to do is register an account on TestPyPI, which " +"is a separate instance of the package index intended for testing and " +"experimentation. It's great for things like this tutorial where we don't " +"necessarily want to upload to the real index. To register an account, go to " +"https://test.pypi.org/account/register/ and complete the steps on that page. " +"You will also need to verify your email address before you're able to upload " +"any packages. For more details, see :doc:`/guides/using-testpypi`." msgstr "" #: ../source/tutorials/packaging-projects.rst:470 -msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgid "" +"To securely upload your project, you'll need a PyPI `API token`_. Create one " +"at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" " +"to \"Entire account\". **Don't close the page until you have copied and " +"saved the token — you won't see that token again.**" msgstr "" #: ../source/tutorials/packaging-projects.rst:477 -msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" +msgid "" +"Now that you are registered, you can use :ref:`twine` to upload the " +"distribution packages. You'll need to install Twine:" msgstr "" #: ../source/tutorials/packaging-projects.rst:492 -msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" +msgid "" +"Once installed, run Twine to upload all of the archives under :file:`dist`:" msgstr "" #: ../source/tutorials/packaging-projects.rst:506 -msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." +msgid "" +"You will be prompted for a username and password. For the username, use " +"``__token__``. For the password, use the token value, including the ``pypi-" +"`` prefix." msgstr "" #: ../source/tutorials/packaging-projects.rst:510 @@ -9193,7 +13430,9 @@ msgid "After the command completes, you should see output similar to this:" msgstr "" #: ../source/tutorials/packaging-projects.rst:523 -msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" +msgid "" +"Once uploaded your package should be viewable on TestPyPI, for example, " +"https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" msgstr "" #: ../source/tutorials/packaging-projects.rst:528 @@ -9201,7 +13440,10 @@ msgid "Installing your newly uploaded package" msgstr "" #: ../source/tutorials/packaging-projects.rst:530 -msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" +msgid "" +"You can use :ref:`pip` to install your package and verify that it works. " +"Create a :ref:`virtual environment ` and install your package from TestPyPI:" msgstr "" #: ../source/tutorials/packaging-projects.rst:546 @@ -9209,15 +13451,25 @@ msgid "Make sure to specify your username in the package name!" msgstr "" #: ../source/tutorials/packaging-projects.rst:548 -msgid "pip should install the package from TestPyPI and the output should look something like this:" +msgid "" +"pip should install the package from TestPyPI and the output should look " +"something like this:" msgstr "" #: ../source/tutorials/packaging-projects.rst:558 -msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." +msgid "" +"This example uses ``--index-url`` flag to specify TestPyPI instead of live " +"PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have " +"the same packages as the live PyPI, it's possible that attempting to install " +"dependencies may fail or install something unexpected. While our example " +"package doesn't have any dependencies, it's a good practice to avoid " +"installing dependencies when using TestPyPI." msgstr "" #: ../source/tutorials/packaging-projects.rst:565 -msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" +msgid "" +"You can test that it was installed correctly by importing the package. Make " +"sure you're still in your virtual environment, then run Python:" msgstr "" #: ../source/tutorials/packaging-projects.rst:580 @@ -9225,55 +13477,82 @@ msgid "and import the package:" msgstr "" #: ../source/tutorials/packaging-projects.rst:588 -msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." +msgid "" +"Note that the :term:`import package ` is ``example_package`` " +"regardless of what ``name`` you gave your :term:`distribution package " +"` in :file:`setup.cfg` or :file:`setup.py` (in this " +"case, ``example-pkg-YOUR-USERNAME-HERE``)." msgstr "" #: ../source/tutorials/packaging-projects.rst:596 -msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" +msgid "" +"**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" msgstr "" #: ../source/tutorials/packaging-projects.rst:599 -msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." +msgid "" +"Keep in mind that this tutorial showed you how to upload your package to " +"Test PyPI, which isn't a permanent storage. The Test system occasionally " +"deletes packages and accounts. It is best to use TestPyPI for testing and " +"experiments like this tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:604 -msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" +msgid "" +"When you are ready to upload a real package to the Python Package Index you " +"can do much the same as you did in this tutorial, but with these important " +"differences:" msgstr "" #: ../source/tutorials/packaging-projects.rst:608 -msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." +msgid "" +"Choose a memorable and unique name for your package. You don't have to " +"append your username as you did in the tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:610 -msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." +msgid "" +"Register an account on https://pypi.org - note that these are two separate " +"servers and the login details from the test server are not shared with the " +"main server." msgstr "" "Зареєструйте обліковий запис на https://pypi.org - зверніть увагу, що це два " "окремих сервери, а дані для входу з тестового сервера не поширюються з " "основним сервером." #: ../source/tutorials/packaging-projects.rst:613 -msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." +msgid "" +"Use ``twine upload dist/*`` to upload your package and enter your " +"credentials for the account you registered on the real PyPI. Now that " +"you're uploading the package in production, you don't need to specify ``--" +"repository``; the package will upload to https://pypi.org/ by default." msgstr "" "Використовуйте `` dist upload upload / * '', щоб опублікувати ваш пакунок і " "ввести ваші облікові дані для облікового запису, який ви зареєстрували на " "реальному PyPI. Тепер, коли ви публікуєте пакунок як продакшн-версію, вам не " -"потрібно вказувати `` --repository``; пакунок буде опубліковано на " -"https://pypi.org/ за замовчуванням." +"потрібно вказувати `` --repository``; пакунок буде опубліковано на https://" +"pypi.org/ за замовчуванням." #: ../source/tutorials/packaging-projects.rst:617 -msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." +msgid "" +"Install your package from the real PyPI using ``python3 -m pip install [your-" +"package]``." msgstr "" "Встановіть ваш пакунок з PyPI за допомогою``python3 -m pip install [your-" "package]``." #: ../source/tutorials/packaging-projects.rst:619 -msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" +msgid "" +"At this point if you want to read more on packaging Python libraries here " +"are some things you can do:" msgstr "" "На цьому етапі, якшо ви бажаєте почитати більше про пакування Python-" "бібліотек, то ось що ви можете зробити:" #: ../source/tutorials/packaging-projects.rst:622 -msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." +msgid "" +"Read more about using :ref:`setuptools` to package libraries in :doc:`/" +"guides/distributing-packages-using-setuptools`." msgstr "" "Прочитайте більше про використання :ref:`setuptools` для пакування бібліотек " "в :doc:`/guides/distributing-packages-using-setuptools`." @@ -9283,7 +13562,9 @@ msgid "Read about :doc:`/guides/packaging-binary-extensions`." msgstr "Прочитайте про :doc:`/guides/packaging-binary-extensions`." #: ../source/tutorials/packaging-projects.rst:625 -msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." +msgid "" +"Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:" +"`hatch`, and :ref:`poetry`." msgstr "" -"Розгляньте альтернативи до :ref:`setuptools` такі як :ref:`flit`, " -":ref:`hatch` і :ref:`poetry`." +"Розгляньте альтернативи до :ref:`setuptools` такі як :ref:`flit`, :ref:" +"`hatch` і :ref:`poetry`." diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po index 84341c490..89de76fa2 100644 --- a/locales/zh_Hans/LC_MESSAGES/messages.po +++ b/locales/zh_Hans/LC_MESSAGES/messages.po @@ -23,7 +23,9 @@ msgid "Contribute to this guide" msgstr "为本指南做出贡献" #: ../source/contribute.rst:7 -msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" +msgid "" +"The |PyPUG| welcomes contributors! There are lots of ways to help out, " +"including:" msgstr "|PyPUG| 欢迎贡献者！有很多方法可以帮助我们，包括：" #: ../source/contribute.rst:10 @@ -43,96 +45,145 @@ msgid "Writing new content" msgstr "撰写新内容" #: ../source/contribute.rst:15 -msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." +msgid "" +"Most of the work on the |PyPUG| takes place on the `project's GitHub " +"repository`__. To get started, check out the list of `open issues`__ and " +"`pull requests`__. If you're planning to write or edit the guide, please " +"read the :ref:`style guide `." msgstr "" -"大部分关于 |PyPUG| 的工作都是在 `本项目的GitHub仓库`__ 进行的。要开始工作，请查看`open issues`__ 和`pull " -"requests`__ 的列表。如果你打算编写或编辑指南，请阅读 :ref:`style guide " -"`。" +"大部分关于 |PyPUG| 的工作都是在 `本项目的GitHub仓库`__ 进行的。要开始工作，请" +"查看`open issues`__ 和`pull requests`__ 的列表。如果你打算编写或编辑指南，请" +"阅读 :ref:`style guide `。" #: ../source/contribute.rst:24 -msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." -msgstr "如果您想为 |PyPUG| 作出贡献，您应该遵守 PSF 的 `行为准则 (Code of Conduct)`__ 。" +msgid "" +"By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of " +"Conduct`__." +msgstr "" +"如果您想为 |PyPUG| 作出贡献，您应该遵守 PSF 的 `行为准则 (Code of " +"Conduct)`__ 。" #: ../source/contribute.rst:31 msgid "Documentation types" msgstr "文档类型" #: ../source/contribute.rst:33 -msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." -msgstr "本项目由具有特定目的的四种不同的文档类型组成。当提议对项目进行新的补充时，请选择适当的文档类型。" +msgid "" +"This project consists of four distinct documentation types with specific " +"purposes. When proposing new additions to the project please pick the " +"appropriate documentation type." +msgstr "" +"本项目由具有特定目的的四种不同的文档类型组成。当提议对项目进行新的补充时，请" +"选择适当的文档类型。" -#: ../source/contribute.rst:38 -#: ../source/tutorials/index.rst:2 +#: ../source/contribute.rst:38 ../source/tutorials/index.rst:2 msgid "Tutorials" msgstr "教程" #: ../source/contribute.rst:40 -msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." -msgstr "教程的重点是通过完成一个目标来教导读者新的概念。它们是有观点的分步指南。它们不包括不相干的警告或信息。`示例教程式文件`_ 。" +msgid "" +"Tutorials are focused on teaching the reader new concepts by accomplishing a " +"goal. They are opinionated step-by-step guides. They do not include " +"extraneous warnings or information. `example tutorial-style document`_." +msgstr "" +"教程的重点是通过完成一个目标来教导读者新的概念。它们是有观点的分步指南。它们" +"不包括不相干的警告或信息。`示例教程式文件`_ 。" -#: ../source/contribute.rst:47 -#: ../source/guides/index.rst:2 +#: ../source/contribute.rst:47 ../source/guides/index.rst:2 msgid "Guides" msgstr "指南" #: ../source/contribute.rst:49 -msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." -msgstr "" -"指南的重点是完成一项具体的任务，并可以假定有一定程度的前提知识。这类似于教程，但有一个狭窄和明确的重点，并可以根据需要提供大量的注意事项和附加信息。他们还" -"可以讨论完成任务的多种方法。 :doc:`示例指南式文档`。" - -#: ../source/contribute.rst:56 -#: ../source/discussions/index.rst:2 +msgid "" +"Guides are focused on accomplishing a specific task and can assume some " +"level of pre-requisite knowledge. These are similar to tutorials, but have a " +"narrow and clear focus and can provide lots of caveats and additional " +"information as needed. They may also discuss multiple approaches to " +"accomplishing the task. :doc:`example guide-style document `." +msgstr "" +"指南的重点是完成一项具体的任务，并可以假定有一定程度的前提知识。这类似于教" +"程，但有一个狭窄和明确的重点，并可以根据需要提供大量的注意事项和附加信息。他" +"们还可以讨论完成任务的多种方法。 :doc:`示例指南式文档`。" + +#: ../source/contribute.rst:56 ../source/discussions/index.rst:2 msgid "Discussions" msgstr "讨论" #: ../source/contribute.rst:58 -msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." +msgid "" +"Discussions are focused on understanding and information. These explore a " +"specific topic without a specific goal in mind. :doc:`example discussion-" +"style document `." msgstr "" -"讨论 (Discussions) 的重点是理解和信息。这些探索一个特定的主题，没有具体的目标。 :doc:`示例讨论式文件 `。" +"讨论 (Discussions) 的重点是理解和信息。这些探索一个特定的主题，没有具体的目" +"标。 :doc:`示例讨论式文件 `。" #: ../source/contribute.rst:63 msgid "Specifications" msgstr "规格" #: ../source/contribute.rst:65 -msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." +msgid "" +"Specifications are reference documention focused on comprehensively " +"documenting an agreed-upon interface for interoperability between packaging " +"tools. :doc:`example specification-style document `." msgstr "" -"规范 (Specifications) 是一种参考文件，侧重于全面记录包装工具之间互操作性的一致接口。 :doc:`范例规范式文件 <" -"specifications/core-metadata>`。" +"规范 (Specifications) 是一种参考文件，侧重于全面记录包装工具之间互操作性的一" +"致接口。 :doc:`范例规范式文件 `。" #: ../source/contribute.rst:73 msgid "Building the guide locally" msgstr "在本地构建指南" #: ../source/contribute.rst:75 -msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" -msgstr "虽然这不需要做出贡献，但为了测试您的改动，在本地建立本指南可能是有用的。为了在本地构建本指南，你需要：" +msgid "" +"Though not required to contribute, it may be useful to build this guide " +"locally in order to test your changes. In order to build this guide locally, " +"you'll need:" +msgstr "" +"虽然这不需要做出贡献，但为了测试您的改动，在本地建立本指南可能是有用的。为了" +"在本地构建本指南，你需要：" #: ../source/contribute.rst:79 -msgid "`Nox `_. You can install or upgrade nox using ``pip``::" +msgid "" +"`Nox `_. You can install or upgrade " +"nox using ``pip``::" msgstr "" -"`Nox `_ 。你可以用 ``pip`` 来安装或升级nox::" +"`Nox `_ 。你可以用 ``pip`` 来安装或升" +"级nox::" #: ../source/contribute.rst:84 -msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." +msgid "" +"Python 3.6. Our build scripts are designed to work with Python 3.6 only. See " +"the `Hitchhiker's Guide to Python installation instructions`_ to install " +"Python 3.6 on your operating system." msgstr "" -"Python 3.6。我们的构建脚本只为 Python 3.6 而设计。请参阅 `Hitchhiker's Guide to Python " -"installation instructions`_ 以在你的操作系统上安装Python 3.6。" +"Python 3.6。我们的构建脚本只为 Python 3.6 而设计。请参阅 `Hitchhiker's Guide " +"to Python installation instructions`_ 以在你的操作系统上安装Python 3.6。" #: ../source/contribute.rst:91 -msgid "To build the guide, run the following bash command in the source folder::" +msgid "" +"To build the guide, run the following bash command in the source folder::" msgstr "要构建指南，在 source 文件夹中运行以下 bash 命令::" #: ../source/contribute.rst:95 -msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." +msgid "" +"After the process has completed you can find the HTML output in the ``./" +"build/html`` directory. You can open the ``index.html`` file to view the " +"guide in web browser, but it's recommended to serve the guide using an HTTP " +"server." msgstr "" -"在该过程完成后，您可以在 ``./build/html`` 目录中找到 HTML 输出。您可以打开 ``index.html`` " -"文件，并在浏览器中查看指南，但我们建议使用 HTTP 服务器为指南服务。" +"在该过程完成后，您可以在 ``./build/html`` 目录中找到 HTML 输出。您可以打开 " +"``index.html`` 文件，并在浏览器中查看指南，但我们建议使用 HTTP 服务器为指南服" +"务。" #: ../source/contribute.rst:100 -msgid "You can build the guide and serve it via an HTTP server using the following command::" +msgid "" +"You can build the guide and serve it via an HTTP server using the following " +"command::" msgstr "您可以使用以下命令建立指南并通过 HTTP 服务器为其提供服务::" #: ../source/contribute.rst:105 @@ -144,42 +195,63 @@ msgid "Where the guide is deployed" msgstr "指南的部署地点" #: ../source/contribute.rst:111 -msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." +msgid "" +"The guide is deployed via ReadTheDocs and the configuration lives at https://" +"readthedocs.org/projects/python-packaging-user-guide/. It's served from a " +"custom domain and fronted by Fast.ly." msgstr "" "该指南是通过ReadTheDocs部署的，配置位于 https://readthedocs.org/projects/" -"python-packaging-user-guide/ 。它由一个自定义域名提供服务，并由 Fast.ly 提供支持。" +"python-packaging-user-guide/ 。它由一个自定义域名提供服务，并由 Fast.ly 提供" +"支持。" #: ../source/contribute.rst:117 msgid "Style guide" msgstr "风格指南" #: ../source/contribute.rst:119 -msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." +msgid "" +"This style guide has recommendations for how you should write the |PyPUG|. " +"Before you start writing, please review it. By following the style guide, " +"your contributions will help add to a cohesive whole and make it easier for " +"your contributions to be accepted into the project." msgstr "" -"本风格指南提供了关于如何编写 |PyPUG| " -"的建议。在开始写作之前，请先查看它。通过遵循样式指南，您的贡献将有助于增加一个有凝聚力的整体，并使您的贡献更容易被项目接受。" +"本风格指南提供了关于如何编写 |PyPUG| 的建议。在开始写作之前，请先查看它。通过" +"遵循样式指南，您的贡献将有助于增加一个有凝聚力的整体，并使您的贡献更容易被项" +"目接受。" #: ../source/contribute.rst:126 msgid "Purpose" msgstr "目的" #: ../source/contribute.rst:128 -msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." -msgstr "|PyPUG| 的目的是成为关于如何使用当前工具打包、发布和安装 Python 项目的权威性资源。" +msgid "" +"The purpose of the |PyPUG| is to be the authoritative resource on how to " +"package, publish, and install Python projects using current tools." +msgstr "" +"|PyPUG| 的目的是成为关于如何使用当前工具打包、发布和安装 Python 项目的权威性" +"资源。" #: ../source/contribute.rst:133 msgid "Scope" msgstr "范围" #: ../source/contribute.rst:135 -msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." +msgid "" +"The guide is meant to answer questions and solve problems with accurate and " +"focused recommendations." msgstr "该指南旨在通过准确和有针对性的建议来回答问题和解决问题。" #: ../source/contribute.rst:138 -msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." +msgid "" +"The guide isn't meant to be comprehensive and it's not meant to replace " +"individual projects' documentation. For example, pip has dozens of commands, " +"options, and settings. The pip documentation describes each of them in " +"detail, while this guide describes only the parts of pip that are needed to " +"complete the specific tasks described in this guide." msgstr "" -"本指南并不意味着是全面的，也不意味着可以取代单个项目的文档。例如，pip 有几十个命令、选项和设置。pip 文档详细描述了它们中的每一个，" -"而本指南只描述了完成本指南中描述的特定任务所需的 pip 部分。" +"本指南并不意味着是全面的，也不意味着可以取代单个项目的文档。例如，pip 有几十" +"个命令、选项和设置。pip 文档详细描述了它们中的每一个，而本指南只描述了完成本" +"指南中描述的特定任务所需的 pip 部分。" #: ../source/contribute.rst:146 msgid "Audience" @@ -190,37 +262,69 @@ msgid "The audience of this guide is anyone who uses Python with packages." msgstr "本指南的受众是任何使用 Python 包的人。" #: ../source/contribute.rst:150 -msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." -msgstr "不要忘记，Python 社区是很大，而且很受欢迎的。读者可能与您的年龄、性别、教育、文化等不尽相同，但他们和您一样值得学习包装知识。" +msgid "" +"Don't forget that the Python community is big and welcoming. Readers may not " +"share your age, gender, education, culture, and more, but they deserve to " +"learn about packaging just as much as you do." +msgstr "" +"不要忘记，Python 社区是很大，而且很受欢迎的。读者可能与您的年龄、性别、教育、" +"文化等不尽相同，但他们和您一样值得学习包装知识。" #: ../source/contribute.rst:154 -msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." -msgstr "特别是要记住，不是所有使用 Python 的人都把自己看作是程序员。本指南的受众包括天文学家，画家或学生以及专业的软件开发人员。" +msgid "" +"In particular, keep in mind that not all people who use Python see " +"themselves as programmers. The audience of this guide includes astronomers " +"or painters or students as well as professional software developers." +msgstr "" +"特别是要记住，不是所有使用 Python 的人都把自己看作是程序员。本指南的受众包括" +"天文学家，画家或学生以及专业的软件开发人员。" #: ../source/contribute.rst:160 msgid "Voice and tone" msgstr "声音和语气" #: ../source/contribute.rst:162 -msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." -msgstr "在撰写本指南时，即使您已经掌握了所有答案，也要努力以平易近人且谦逊的语气写作。" +msgid "" +"When writing this guide, strive to write with a voice that's approachable " +"and humble, even if you have all the answers." +msgstr "" +"在撰写本指南时，即使您已经掌握了所有答案，也要努力以平易近人且谦逊的语气写" +"作。" #: ../source/contribute.rst:165 -msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." +msgid "" +"Imagine you're working on a Python project with someone you know to be smart " +"and skilled. You like working with them and they like working with you. That " +"person has asked you a question and you know the answer. How do you respond? " +"*That* is how you should write this guide." msgstr "" -"想象一下，您正在和一个您知道是聪明和熟练的人一起做 Python " -"项目。您喜欢和他们一起工作，他们也喜欢和您一起工作。那个人问了您一个问题，你知道答案。你怎么回答？*这* 就是你应该如何写这个指南的方式。" +"想象一下，您正在和一个您知道是聪明和熟练的人一起做 Python 项目。您喜欢和他们" +"一起工作，他们也喜欢和您一起工作。那个人问了您一个问题，你知道答案。你怎么回" +"答？*这* 就是你应该如何写这个指南的方式。" #: ../source/contribute.rst:170 -msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." +msgid "" +"Here's a quick check: try reading aloud to get a sense for your writing's " +"voice and tone. Does it sound like something you would say or does it sound " +"like you're acting out a part or giving a speech? Feel free to use " +"contractions and don't worry about sticking to fussy grammar rules. You are " +"hereby granted permission to end a sentence in a preposition, if that's what " +"you want to end it with." msgstr "" -"这里有一个快速检查：试着大声朗读以了解您写作的声音和语气。它听起来像您会说的话，还是听起来像您在演戏或发表演讲？随意使用缩略语，不要担心拘泥于繁琐的语法规" -"则。您在此允许用介词来结束一个句子，如果这是您想结束它的话。" +"这里有一个快速检查：试着大声朗读以了解您写作的声音和语气。它听起来像您会说的" +"话，还是听起来像您在演戏或发表演讲？随意使用缩略语，不要担心拘泥于繁琐的语法" +"规则。您在此允许用介词来结束一个句子，如果这是您想结束它的话。" #: ../source/contribute.rst:177 -msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." +msgid "" +"When writing the guide, adjust your tone for the seriousness and difficulty " +"of the topic. If you're writing an introductory tutorial, it's OK to make a " +"joke, but if you're covering a sensitive security recommendation, you might " +"want to avoid jokes altogether." msgstr "" -"在写指南时，根据主题的严肃性和难度调整你的语气。如果你写的是一个介绍性的教程，开个玩笑是可以的，但如果你涉及的是一个敏感的安全建议，你可能要完全避免玩笑。" +"在写指南时，根据主题的严肃性和难度调整你的语气。如果你写的是一个介绍性的教" +"程，开个玩笑是可以的，但如果你涉及的是一个敏感的安全建议，你可能要完全避免玩" +"笑。" #: ../source/contribute.rst:184 msgid "Conventions and mechanics" @@ -231,7 +335,9 @@ msgid "**Write to the reader**" msgstr "**写给读者**" #: ../source/contribute.rst:187 -msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." +msgid "" +"When giving recommendations or steps to take, address the reader as *you* or " +"use the imperative mood." msgstr "在提出建议或采取的步骤时，您应称呼读者为 *你* 或使用命令语气。" #: ../source/contribute.rst:0 @@ -251,23 +357,36 @@ msgid "**State assumptions**" msgstr "**陈述假设**" #: ../source/contribute.rst:195 -msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." -msgstr "避免做出未说明的假设。在网上阅读意味着指南的任何一页都可能是读者所看到的指南的第一页。如果您要做假设，那就要说明您要做什么假设。" +msgid "" +"Avoid making unstated assumptions. Reading on the web means that any page of " +"the guide may be the first page of the guide that the reader ever sees. If " +"you're going to make assumptions, then say what assumptions that you're " +"going to make." +msgstr "" +"避免做出未说明的假设。在网上阅读意味着指南的任何一页都可能是读者所看到的指南" +"的第一页。如果您要做假设，那就要说明您要做什么假设。" #: ../source/contribute.rst:203 msgid "**Cross-reference generously**" msgstr "**慷慨地交叉参考**" #: ../source/contribute.rst:201 -msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." -msgstr "当你第一次提到一个工具或做法时，请链接到指南中涉及它的部分，或链接到其他地方的相关文件。这样可以为读者省去搜索的麻烦。" +msgid "" +"The first time you mention a tool or practice, link to the part of the guide " +"that covers it, or link to a relevant document elsewhere. Save the reader a " +"search." +msgstr "" +"当你第一次提到一个工具或做法时，请链接到指南中涉及它的部分，或链接到其他地方" +"的相关文件。这样可以为读者省去搜索的麻烦。" #: ../source/contribute.rst:213 msgid "**Respect naming practices**" msgstr "**尊重命名的做法**" #: ../source/contribute.rst:206 -msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." +msgid "" +"When naming tools, sites, people, and other proper nouns, use their " +"preferred capitalization." msgstr "当给工具、网站、人和其他专有名词命名时，请使用它们的首选大写字母。" #: ../source/contribute.rst:0 @@ -291,10 +410,13 @@ msgid "**Use a gender-neutral style**" msgstr "**使用中性风格**" #: ../source/contribute.rst:216 -msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." +msgid "" +"Often, you'll address the reader directly with *you*, *your* and *yours*. " +"Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or " +"avoid pronouns entirely." msgstr "" -"通常，您会用 *you*、*your* 和 *yours* 来直接称呼读者。否则，请使用性别中立的代词 *they*、*their* 和 *theirs*" -" ，或者完全避免使用代词。" +"通常，您会用 *you*、*your* 和 *yours* 来直接称呼读者。否则，请使用性别中立的" +"代词 *they*、*their* 和 *theirs* ，或者完全避免使用代词。" #: ../source/contribute.rst:0 msgid "Wrong: A maintainer uploads the file. Then he…" @@ -313,14 +435,22 @@ msgid "**Headings**" msgstr "**标题**" #: ../source/contribute.rst:225 -msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." +msgid "" +"Write headings that use words the reader is searching for. A good way to do " +"this is to have your heading complete an implied question. For example, a " +"reader might want to know *How do I install MyLibrary?* so a good heading " +"might be *Install MyLibrary*." msgstr "" -"写标题时要使用读者正在搜索的词。一个好方法是让你的标题完成一个隐含的问题。例如，读者可能想知道 *How do I install " -"MyLibrary?*，所以一个好的标题可能是 *Install MyLibrary* 。" +"写标题时要使用读者正在搜索的词。一个好方法是让你的标题完成一个隐含的问题。例" +"如，读者可能想知道 *How do I install MyLibrary?*，所以一个好的标题可能是 " +"*Install MyLibrary* 。" #: ../source/contribute.rst:230 -msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." -msgstr "在章节标题中，使用句子大小写。换句话说，要像写一个典型的句子那样写标题。" +msgid "" +"In section headings, use sentence case. In other words, write headings as " +"you would write a typical sentence." +msgstr "" +"在章节标题中，使用句子大小写。换句话说，要像写一个典型的句子那样写标题。" #: ../source/contribute.rst:0 msgid "Wrong: Things You Should Know About Python" @@ -335,7 +465,9 @@ msgid "**Numbers**" msgstr "**数字**" #: ../source/contribute.rst:237 -msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." +msgid "" +"In body text, write numbers one through nine as words. For other numbers or " +"numbers in tables, use numerals." msgstr "在正文中，将数字1到9写成单词。对于其他数字或表格中的数字，使用数字。" #: ../source/discussions/deploying-python-applications.rst:4 @@ -382,8 +514,7 @@ msgstr "2014-11-11" #: ../source/guides/packaging-binary-extensions.rst:17 #: ../source/guides/supporting-multiple-python-versions.rst:12 #: ../source/guides/supporting-windows-using-appveyor.rst:15 -#: ../source/overview.rst:23 -#: ../source/specifications/core-metadata.rst:38 +#: ../source/overview.rst:23 ../source/specifications/core-metadata.rst:38 #: ../source/specifications/direct-url.rst:14 #: ../source/tutorials/installing-packages.rst:23 msgid "Contents" @@ -410,23 +541,40 @@ msgid "Pynsist" msgstr "Pynsist" #: ../source/discussions/deploying-python-applications.rst:63 -msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." -msgstr "" -"`Pynsist `__ 是一个基于NSIS的单一安装程序，并将 Python " -"程序与 Python 解释器捆绑在一起的工具。在大多数情况下，打包 (packaging) 只需要用户选择 Python 解释器的版本并声明程序的依赖性 " -"(dependencies) 。该工具会下载用于 Windows 的 Python 解释器，并将其与所有依赖项打包成一个可在 Windows " -"执行的安装程序。" +msgid "" +"`Pynsist `__ is a tool that bundles Python " +"programs together with the Python-interpreter into a single installer based " +"on NSIS. In most cases, packaging only requires the user to choose a version " +"of the Python-interpreter and declare the dependencies of the program. The " +"tool downloads the specified Python-interpreter for Windows and packages it " +"with all the dependencies in a single Windows-executable installer." +msgstr "" +"`Pynsist `__ 是一个基于NSIS的单一安装程序，" +"并将 Python 程序与 Python 解释器捆绑在一起的工具。在大多数情况下，打包 " +"(packaging) 只需要用户选择 Python 解释器的版本并声明程序的依赖性 " +"(dependencies) 。该工具会下载用于 Windows 的 Python 解释器，并将其与所有依赖" +"项打包成一个可在 Windows 执行的安装程序。" #: ../source/discussions/deploying-python-applications.rst:70 -msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." +msgid "" +"The installed program can be started from a shortcut that the installer adds " +"to the start-menu. It uses a Python interpreter installed within its " +"application directory, independent of any other Python installation on the " +"computer." msgstr "" -"安装的程序可以从安装程序添加到开始菜单的快捷方式启动。它使用一个安装在其应用程序目录中的Python解释器，与计算机上的任何其他 Python 安装无关。" +"安装的程序可以从安装程序添加到开始菜单的快捷方式启动。它使用一个安装在其应用" +"程序目录中的Python解释器，与计算机上的任何其他 Python 安装无关。" #: ../source/discussions/deploying-python-applications.rst:74 -msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." +msgid "" +"A big advantage of Pynsist is that the Windows packages can be built on " +"Linux. There are several examples for different kinds of programs (console, " +"GUI) in the `documentation `__. The tool is " +"released under the MIT-licence." msgstr "" -"Pynsist 的一大优势是可以在 Linux 上构建 Windows 软件包。在`文档 `__ 中，有几个不同类型程序（控制台、GUI）的例子。该工具是在 MIT 许可下发布的。" +"Pynsist 的一大优势是可以在 Linux 上构建 Windows 软件包。在`文档 `__ 中，有几个不同类型程序（控制台、GUI）的例子。该工" +"具是在 MIT 许可下发布的。" #: ../source/discussions/deploying-python-applications.rst:80 msgid "Application bundles" @@ -437,9 +585,13 @@ msgid "Configuration management" msgstr "配置管理" #: ../source/discussions/index.rst:4 -msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." +msgid "" +"**Discussions** are focused on providing comprehensive information about a " +"specific topic. If you're just trying to get stuff done, see :doc:`/guides/" +"index`." msgstr "" -"**讨论 (Discussions)** 的重点是提供关于特定主题的全面信息。如果您只是想把事情做好，请看 :doc:`/guides/index` 。" +"**讨论 (Discussions)** 的重点是提供关于特定主题的全面信息。如果您只是想把事情" +"做好，请看 :doc:`/guides/index` 。" #: ../source/discussions/install-requires-vs-requirements.rst:5 msgid "install_requires vs requirements files" @@ -451,33 +603,56 @@ msgid "install_requires" msgstr "install_requires" #: ../source/discussions/install-requires-vs-requirements.rst:14 -msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgid "" +"``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that " +"should be used to specify what a project **minimally** needs to run " +"correctly. When the project is installed by :ref:`pip`, this is the " +"specification that is used to install its dependencies." msgstr "" -"``install_requires`` 是一个 :ref:`setuptools` :file:`setup.py` 关键字，它应该用来指定一个项目 " -"**最小** 需要正确运行的内容。当项目由 :ref:`pip` 安装时，这就是用来安装其依赖的规范。" +"``install_requires`` 是一个 :ref:`setuptools` :file:`setup.py` 关键字，它应该" +"用来指定一个项目 **最小** 需要正确运行的内容。当项目由 :ref:`pip` 安装时，这" +"就是用来安装其依赖的规范。" #: ../source/discussions/install-requires-vs-requirements.rst:19 -msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" +msgid "" +"For example, if the project requires A and B, your ``install_requires`` " +"would be like so:" msgstr "例如，如果项目需要 A 和 B ，您的 ``install_requires`` 会是这样的：" #: ../source/discussions/install-requires-vs-requirements.rst:29 -msgid "Additionally, it's best practice to indicate any known lower or upper bounds." +msgid "" +"Additionally, it's best practice to indicate any known lower or upper bounds." msgstr "此外，最好的做法是指出任何已知的下限或上限。" #: ../source/discussions/install-requires-vs-requirements.rst:31 -msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" -msgstr "例如，您可能知道您的项目至少需要 'A' 的 v1 ，'B' 的 v2 ，所以它会是这样的：" +msgid "" +"For example, it may be known, that your project requires at least v1 of 'A', " +"and v2 of 'B', so it would be like so:" +msgstr "" +"例如，您可能知道您的项目至少需要 'A' 的 v1 ，'B' 的 v2 ，所以它会是这样的：" #: ../source/discussions/install-requires-vs-requirements.rst:41 -msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" +msgid "" +"It may also be known that project A follows semantic versioning, and that v2 " +"of 'A' will indicate a break in compatibility, so it makes sense to not " +"allow v2:" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:51 -msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." +msgid "" +"It is not considered best practice to use ``install_requires`` to pin " +"dependencies to specific versions, or to specify sub-dependencies (i.e. " +"dependencies of your dependencies). This is overly-restrictive, and " +"prevents the user from gaining the benefit of dependency upgrades." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:56 -msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" +msgid "" +"Lastly, it's important to understand that ``install_requires`` is a listing " +"of \"Abstract\" requirements, i.e just names and version restrictions that " +"don't determine where the dependencies will be fulfilled from (i.e. from " +"what index or source). The where (i.e. how they are to be made \"Concrete" +"\") is to be determined at install time using :ref:`pip` options. [1]_" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:64 @@ -486,49 +661,82 @@ msgid "Requirements files" msgstr "Requirements files" #: ../source/discussions/install-requires-vs-requirements.rst:66 -msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." +msgid "" +":ref:`Requirements Files ` described most simply, " +"are just a list of :ref:`pip:pip install` arguments placed into a file." msgstr "" -":ref:`Requirements Files ` 最简单的描述，只是放在文件中的 :ref:`pip:" -"pip install` 参数列表。" +":ref:`Requirements Files ` 最简单的描述，只是放在文件" +"中的 :ref:`pip:pip install` 参数列表。" #: ../source/discussions/install-requires-vs-requirements.rst:69 -msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." +msgid "" +"Whereas ``install_requires`` defines the dependencies for a single project, :" +"ref:`Requirements Files ` are often used to define " +"the requirements for a complete Python environment." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:73 -msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." +msgid "" +"Whereas ``install_requires`` requirements are minimal, requirements files " +"often contain an exhaustive listing of pinned versions for the purpose of " +"achieving :ref:`repeatable installations ` of a complete " +"environment." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:78 -msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" +msgid "" +"Whereas ``install_requires`` requirements are \"Abstract\", i.e. not " +"associated with any particular index, requirements files often contain pip " +"options like ``--index-url`` or ``--find-links`` to make requirements " +"\"Concrete\", i.e. associated with a particular index or directory of " +"packages. [1]_" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:84 -msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." +msgid "" +"Whereas ``install_requires`` metadata is automatically analyzed by pip " +"during an install, requirements files are not, and only are used when a user " +"specifically installs them using ``python -m pip install -r``." msgstr "" -"在安装过程中，``install_requires`` 元数据会被 pip 自动分析，而需求文件则不会，而它只有在用户使用 ``python -m " -"pip install -r`` 专门安装时才会使用。" +"在安装过程中，``install_requires`` 元数据会被 pip 自动分析，而需求文件则不" +"会，而它只有在用户使用 ``python -m pip install -r`` 专门安装时才会使用。" #: ../source/discussions/install-requires-vs-requirements.rst:90 -msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." +msgid "" +"For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad." +"io/2013/07/setup-vs-requirement/." msgstr "" -"关于 \"抽象 (Abstract) \"与 \"具体 (Concrete)\"要求的更多信息，请参阅 https://caremad.io/2013/" -"07/setup-vs-requirement/ 。" +"关于 \"抽象 (Abstract) \"与 \"具体 (Concrete)\"要求的更多信息，请参阅 " +"https://caremad.io/2013/07/setup-vs-requirement/ 。" #: ../source/discussions/pip-vs-easy-install.rst:6 msgid "pip vs easy_install" msgstr "pip 与 easy_install" #: ../source/discussions/pip-vs-easy-install.rst:9 -msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." +msgid "" +":ref:`easy_install `, now `deprecated`_, was released in 2004 " +"as part of :ref:`setuptools`. It was notable at the time for installing :" +"term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing " +"dependencies." msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:14 -msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." +msgid "" +":ref:`pip` came later in 2008, as alternative to :ref:`easy_install " +"`, although still largely built on top of :ref:`setuptools` " +"components. It was notable at the time for *not* installing packages as :" +"term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' " +"packages from :term:`sdists `), and " +"introducing the idea of :ref:`Requirements Files `, " +"which gave users the power to easily replicate environments." msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:22 -msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" +msgid "" +"Here's a breakdown of the important differences between pip and the " +"deprecated easy_install:" msgstr "下面是 pip 和被废弃的 easy_install 之间的重要区别的分类：" #: ../source/discussions/pip-vs-easy-install.rst:25 @@ -642,7 +850,9 @@ msgid "Yes, via setup.cfg" msgstr "有，通过 setup.cfg" #: ../source/discussions/pip-vs-easy-install.rst:68 -msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" +msgid "" +"https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" +"launcher" msgstr "" "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" "launcher" @@ -652,20 +862,30 @@ msgid "Wheel vs Egg" msgstr "Wheel 与 Egg" #: ../source/discussions/wheel-vs-egg.rst:7 -msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." +msgid "" +":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support " +"the use case of needing an install artifact that doesn't require building or " +"compilation, which can be costly in testing and production workflows." msgstr "" -":term:`Wheel` 和 :term:`Egg` 都是打包格式，旨在支持不需要构建或编译的安装工件的使用情况，这在测试和生产工作流程中可能是昂贵的。" +":term:`Wheel` 和 :term:`Egg` 都是打包格式，旨在支持不需要构建或编译的安装工件" +"的使用情况，这在测试和生产工作流程中可能是昂贵的。" #: ../source/discussions/wheel-vs-egg.rst:11 -msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." +msgid "" +"The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas " +"the :term:`Wheel` format was introduced by :pep:`427` in 2012." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:14 -msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." +msgid "" +":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:17 -msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." +msgid "" +"Here's a breakdown of the important differences between :term:`Wheel` and :" +"term:`Egg`." msgstr "下面是关于 :term: `Wheel` 和 :term: `Egg` 之间的重要区别。" #: ../source/discussions/wheel-vs-egg.rst:20 @@ -673,33 +893,55 @@ msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." msgstr ":term:`Wheel` 有一个 :pep:`official PEP <427>` 。 :term:`Egg` 没有。" #: ../source/discussions/wheel-vs-egg.rst:22 -msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." +msgid "" +":term:`Wheel` is a :term:`distribution ` format, i.e a " +"packaging format. [1]_ :term:`Egg` was both a distribution format and a " +"runtime installation format (if left zipped), and was designed to be " +"importable." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:26 -msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." +msgid "" +":term:`Wheel` archives do not include .pyc files. Therefore, when the " +"distribution only contains Python files (i.e. no compiled extensions), and " +"is compatible with Python 2 and 3, it's possible for a wheel to be " +"\"universal\", similar to an :term:`sdist `." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:31 -msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." +msgid "" +":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. " +"Egg used ``.egg-info``." msgstr "" -":term:`Wheel` 使用 :pep:`PEP376-compliant <376>```.dist-info`` 目录。 Egg 使用 " -"``.egg-info`` 。" +":term:`Wheel` 使用 :pep:`PEP376-compliant <376>```.dist-info`` 目录。 Egg 使" +"用 ``.egg-info`` 。" #: ../source/discussions/wheel-vs-egg.rst:34 -msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." +msgid "" +":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single " +"wheel archive can indicate its compatibility with a number of Python " +"language versions and implementations, ABIs, and system architectures." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:38 -msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." +msgid "" +":term:`Wheel` is versioned. Every wheel file contains the version of the " +"wheel specification and the implementation that packaged it." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:41 -msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." +msgid "" +":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making " +"it easier to convert to other formats." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:47 -msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." +msgid "" +"Circumstantially, in some cases, wheels can be used as an importable runtime " +"format, although :pep:`this is not officially supported at this time <427#is-" +"it-possible-to-import-python-code-directly-from-a-wheel-file>`." msgstr "" #: ../source/glossary.rst:3 @@ -711,7 +953,9 @@ msgid "Binary Distribution" msgstr "" #: ../source/glossary.rst:11 -msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." +msgid "" +"A specific kind of :term:`Built Distribution` that contains compiled " +"extensions." msgstr "" #: ../source/glossary.rst:14 @@ -719,7 +963,14 @@ msgid "Built Distribution" msgstr "" #: ../source/glossary.rst:17 -msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." +msgid "" +"A :term:`Distribution ` format containing files and " +"metadata that only need to be moved to the correct location on the target " +"system, to be installed. :term:`Wheel` is such a format, whereas distutil's :" +"term:`Source Distribution ` is not, in " +"that it requires a build step before it can be installed. This format does " +"not imply that Python files have to be precompiled (:term:`Wheel` " +"intentionally does not include compiled Python files)." msgstr "" #: ../source/glossary.rst:26 @@ -727,11 +978,22 @@ msgid "Distribution Package" msgstr "分发软件包" #: ../source/glossary.rst:29 -msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." +msgid "" +"A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used " +"to distribute a :term:`Release`. The archive file is what an end-user will " +"download from the internet and install." msgstr "" #: ../source/glossary.rst:34 -msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." +msgid "" +"A distribution package is more commonly referred to with the single words " +"\"package\" or \"distribution\", but this guide may use the expanded term " +"when more clarity is needed to prevent confusion with an :term:`Import " +"Package` (which is also commonly called a \"package\") or another kind of " +"distribution (e.g. a Linux distribution or the Python language " +"distribution), which are often referred to with the single term " +"\"distribution\"." msgstr "" #: ../source/glossary.rst:41 @@ -739,7 +1001,12 @@ msgid "Egg" msgstr "Egg" #: ../source/glossary.rst:44 -msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" +msgid "" +"A :term:`Built Distribution` format introduced by :ref:`setuptools`, which " +"is being replaced by :term:`Wheel`. For details, see `The Internal " +"Structure of Python Eggs `_ and `Python Eggs `_" msgstr "" #: ../source/glossary.rst:49 @@ -747,7 +1014,12 @@ msgid "Extension Module" msgstr "扩展模块" #: ../source/glossary.rst:52 -msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." +msgid "" +"A :term:`Module` written in the low-level language of the Python " +"implementation: C/C++ for Python, Java for Jython. Typically contained in a " +"single dynamically loadable pre-compiled file, e.g. a shared object (.so) " +"file for Python extensions on Unix, a DLL (given the .pyd extension) for " +"Python extensions on Windows, or a Java class file for Jython extensions." msgstr "" #: ../source/glossary.rst:59 @@ -755,7 +1027,12 @@ msgid "Known Good Set (KGS)" msgstr "" #: ../source/glossary.rst:62 -msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." +msgid "" +"A set of distributions at specified versions which are compatible with each " +"other. Typically a test suite will be run which passes all tests before a " +"specific set of packages is declared a known good set. This term is commonly " +"used by frameworks and toolkits which are comprised of multiple individual " +"distributions." msgstr "" #: ../source/glossary.rst:68 @@ -763,11 +1040,17 @@ msgid "Import Package" msgstr "导入包" #: ../source/glossary.rst:71 -msgid "A Python module which can contain other modules or recursively, other packages." +msgid "" +"A Python module which can contain other modules or recursively, other " +"packages." msgstr "" #: ../source/glossary.rst:74 -msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." +msgid "" +"An import package is more commonly referred to with the single word \"package" +"\", but this guide will use the expanded term when more clarity is needed to " +"prevent confusion with a :term:`Distribution Package` which is also commonly " +"called a \"package\"." msgstr "" #: ../source/glossary.rst:78 @@ -775,7 +1058,9 @@ msgid "Module" msgstr "模块(Module)" #: ../source/glossary.rst:81 -msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." +msgid "" +"The basic unit of code reusability in Python, existing in one of two types: :" +"term:`Pure Module`, or :term:`Extension Module`." msgstr "" #: ../source/glossary.rst:84 @@ -783,7 +1068,9 @@ msgid "Package Index" msgstr "包索引 (Package Index)" #: ../source/glossary.rst:87 -msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." +msgid "" +"A repository of distributions with a web interface to automate :term:" +"`package ` discovery and consumption." msgstr "" #: ../source/glossary.rst:90 @@ -791,7 +1078,10 @@ msgid "Per Project Index" msgstr "" #: ../source/glossary.rst:93 -msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." +msgid "" +"A private or other non-canonical :term:`Package Index` indicated by a " +"specific :term:`Project` as the index preferred or required to resolve " +"dependencies of that project." msgstr "" #: ../source/glossary.rst:97 @@ -799,22 +1089,39 @@ msgid "Project" msgstr "项目 (Project)" #: ../source/glossary.rst:100 -msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." +msgid "" +"A library, framework, script, plugin, application, or collection of data or " +"other resources, or some combination thereof that is intended to be packaged " +"into a :term:`Distribution `." msgstr "" #: ../source/glossary.rst:104 -msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." +msgid "" +"Since most projects create :term:`Distributions ` " +"using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:" +"`setuptools`, another practical way to define projects currently is " +"something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:" +"`setup.cfg` file at the root of the project source directory." msgstr "" #: ../source/glossary.rst:110 -msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." -msgstr "" -"Python 项目必须具有独特且唯一的名称，这些名字可以在 :term:`PyPI ` 上注册。" -"然后每个项目将包含一个或多个 :term:`发布` ，每个版本可能包括一个或多个 :term:`套件 `. Each project will then contain one or more :" +"term:`Releases `, and each release may comprise one or more :term:" +"`distributions `." +msgstr "" +"Python 项目必须具有独特且唯一的名称，这些名字可以在 :term:`PyPI ` 上注册。然后每个项目将包含一个或多个 :term:`发布" +"` ，每个版本可能包括一个或多个 :term:`套件 ` 。" #: ../source/glossary.rst:115 -msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." +msgid "" +"Note that there is a strong convention to name a project after the name of " +"the package that is imported to run that project. However, this doesn't have " +"to hold true. It's possible to install a distribution from the project 'foo' " +"and have it provide a package importable only as 'bar'." msgstr "" #: ../source/glossary.rst:121 @@ -822,7 +1129,9 @@ msgid "Pure Module" msgstr "纯模块 (Pure Module)" #: ../source/glossary.rst:124 -msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." +msgid "" +"A :term:`Module` written in Python and contained in a single ``.py`` file " +"(and possibly associated ``.pyc`` and/or ``.pyo`` files)." msgstr "" #: ../source/glossary.rst:127 @@ -830,30 +1139,42 @@ msgid "Python Packaging Authority (PyPA)" msgstr "Python 包装管理局 （PyPA）" #: ../source/glossary.rst:130 -msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." -msgstr "" -"PyPA 是一个工作小组，负责维护 Python 包装中的许多相关项目。他们在 https://www.pypa.io，`GitHub " -"`_ 和`Bitbucket `_ 上托管项目，" -"并在 `distutils-sig 邮件列表 `_ 和 `Python Discourse 论坛 `__ 上讨论问题。" +msgid "" +"PyPA is a working group that maintains many of the relevant projects in " +"Python packaging. They maintain a site at https://www.pypa.io, host projects " +"on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python " +"Discourse forum `__." +msgstr "" +"PyPA 是一个工作小组，负责维护 Python 包装中的许多相关项目。他们在 https://" +"www.pypa.io，`GitHub `_ 和`Bitbucket `_ 上托管项目，并在 `distutils-sig 邮件列表 `_ 和 `Python Discourse " +"论坛 `__ 上讨论问题。" #: ../source/glossary.rst:139 msgid "Python Package Index (PyPI)" msgstr "Python 包索引 (PyPI)" #: ../source/glossary.rst:142 -msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." +msgid "" +"`PyPI `_ is the default :term:`Package Index` for the " +"Python community. It is open to all Python developers to consume and " +"distribute their distributions." msgstr "" -"`PyPI `_ 是 Python 社区的默认 :term:`包索引 (Package Index)` 。所有 " -"Python 开发人员都可以使用和分发他们的发行版。" +"`PyPI `_ 是 Python 社区的默认 :term:`包索引 (Package " +"Index)` 。所有 Python 开发人员都可以使用和分发他们的发行版。" #: ../source/glossary.rst:145 msgid "pypi.org" msgstr "pypi.org" #: ../source/glossary.rst:148 -msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." +msgid "" +"`pypi.org `_ is the domain name for the :term:`Python " +"Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi." +"python.org``, in 2017. It is powered by :ref:`warehouse`." msgstr "" #: ../source/glossary.rst:152 @@ -861,7 +1182,8 @@ msgid "pyproject.toml" msgstr "pyproject.toml" #: ../source/glossary.rst:155 -msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." +msgid "" +"The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." msgstr "" #: ../source/glossary.rst:157 @@ -869,11 +1191,17 @@ msgid "Release" msgstr "" #: ../source/glossary.rst:160 -msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." +msgid "" +"A snapshot of a :term:`Project` at a particular point in time, denoted by a " +"version identifier." msgstr "" #: ../source/glossary.rst:163 -msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." +msgid "" +"Making a release may entail the publishing of multiple :term:`Distributions " +"`. For example, if version 1.0 of a project was " +"released, it could be available in both a source distribution format and a " +"Windows installer distribution format." msgstr "" #: ../source/glossary.rst:168 @@ -881,7 +1209,12 @@ msgid "Requirement" msgstr "" #: ../source/glossary.rst:171 -msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." +msgid "" +"A specification for a :term:`package ` to be " +"installed. :ref:`pip`, the :term:`PYPA ` " +"recommended installer, allows various forms of specification that can all be " +"considered a \"requirement\". For more information, see the :ref:`pip:pip " +"install` reference." msgstr "" #: ../source/glossary.rst:177 @@ -889,7 +1222,13 @@ msgid "Requirement Specifier" msgstr "" #: ../source/glossary.rst:180 -msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" +msgid "" +"A format used by :ref:`pip` to install packages from a :term:`Package " +"Index`. For an EBNF diagram of the format, see the `pkg_resources." +"Requirement `_ entry in the :ref:`setuptools` docs. For " +"example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the " +"project name, and the \">=1.3\" portion is the :term:`Version Specifier`" msgstr "" #: ../source/glossary.rst:187 @@ -897,7 +1236,10 @@ msgid "Requirements File" msgstr "" #: ../source/glossary.rst:190 -msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." +msgid "" +"A file containing a list of :term:`Requirements ` that can be " +"installed using :ref:`pip`. For more information, see the :ref:`pip` docs " +"on :ref:`pip:Requirements Files`." msgstr "" #: ../source/glossary.rst:194 @@ -911,7 +1253,9 @@ msgid "setup.cfg" msgstr "setup.cfg" #: ../source/glossary.rst:198 -msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." +msgid "" +"The project specification files for :ref:`distutils` and :ref:`setuptools`. " +"See also :term:`pyproject.toml`." msgstr "" #: ../source/glossary.rst:201 @@ -919,7 +1263,10 @@ msgid "Source Archive" msgstr "" #: ../source/glossary.rst:204 -msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." +msgid "" +"An archive containing the raw source code for a :term:`Release`, prior to " +"creation of a :term:`Source Distribution ` or :term:`Built Distribution`." msgstr "" #: ../source/glossary.rst:208 @@ -927,7 +1274,11 @@ msgid "Source Distribution (or \"sdist\")" msgstr "源代码分发（或“sdist”）" #: ../source/glossary.rst:211 -msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." +msgid "" +"A :term:`distribution ` format (usually generated " +"using ``python setup.py sdist``) that provides metadata and the essential " +"source files needed for installing by a tool like :ref:`pip`, or for " +"generating a :term:`Built Distribution`." msgstr "" #: ../source/glossary.rst:216 @@ -935,7 +1286,9 @@ msgid "System Package" msgstr "系统包 (System Package)" #: ../source/glossary.rst:219 -msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." +msgid "" +"A package provided in a format native to the operating system, e.g. an rpm " +"or dpkg file." msgstr "" #: ../source/glossary.rst:222 @@ -943,7 +1296,12 @@ msgid "Version Specifier" msgstr "版本说明符 (Version Specifier)" #: ../source/glossary.rst:225 -msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." +msgid "" +"The version component of a :term:`Requirement Specifier`. For example, the " +"\">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full " +"specification <440#version-specifiers>` of the specifiers that Python " +"packaging currently supports. Support for PEP440 was implemented in :ref:" +"`setuptools` v8.0 and :ref:`pip` v6.0." msgstr "" #: ../source/glossary.rst:231 @@ -951,7 +1309,11 @@ msgid "Virtual Environment" msgstr "虚拟环境 (Virtual Environment)" #: ../source/glossary.rst:234 -msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgid "" +"An isolated Python environment that allows packages to be installed for use " +"by a particular application, rather than being installed system wide. For " +"more information, see the section on :ref:`Creating and using Virtual " +"Environments`." msgstr "" #: ../source/glossary.rst:238 @@ -959,7 +1321,10 @@ msgid "Wheel" msgstr "Wheel" #: ../source/glossary.rst:241 -msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." +msgid "" +"A :term:`Built Distribution` format introduced by :pep:`427`, which is " +"intended to replace the :term:`Egg` format. Wheel is currently supported " +"by :ref:`pip`." msgstr "" #: ../source/glossary.rst:244 @@ -967,7 +1332,11 @@ msgid "Working Set" msgstr "工作集 (Working Set)" #: ../source/glossary.rst:247 -msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." +msgid "" +"A collection of :term:`distributions ` available for " +"importing. These are the distributions that are on the `sys.path` variable. " +"At most, one :term:`Distribution ` for a project is " +"possible in a working set." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:3 @@ -975,10 +1344,15 @@ msgid "Analyzing PyPI package downloads" msgstr "分析 PyPI 软件包的下载情况" #: ../source/guides/analyzing-pypi-package-downloads.rst:5 -msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." +msgid "" +"This section covers how to use the public PyPI download statistics dataset " +"to learn more about downloads of a package (or packages) hosted on PyPI. For " +"example, you can use it to discover the distribution of Python versions used " +"to download a package." msgstr "" -"本节介绍了如何使用公共的 PyPI 下载统计数据集来了解PyPI上托管的软件包 (packages) 的下载情况。例如，您可以用它来发现用于下载软件包的 " -"Python 版本的分布。" +"本节介绍了如何使用公共的 PyPI 下载统计数据集来了解PyPI上托管的软件包 " +"(packages) 的下载情况。例如，您可以用它来发现用于下载软件包的 Python 版本的分" +"布。" #: ../source/guides/analyzing-pypi-package-downloads.rst:15 #: ../source/guides/supporting-windows-using-appveyor.rst:18 @@ -990,11 +1364,17 @@ msgid "PyPI does not display download statistics for a number of reasons: [#]_" msgstr "由于一些原因，PyPI 不显示下载统计数据。[#]_" #: ../source/guides/analyzing-pypi-package-downloads.rst:19 -msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." +msgid "" +"**Inefficient to make work with a Content Distribution Network (CDN):** " +"Download statistics change constantly. Including them in project pages, " +"which are heavily cached, would require invalidating the cache more often, " +"and reduce the overall effectiveness of the cache." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:24 -msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" +msgid "" +"**Highly inaccurate:** A number of things prevent the download counts from " +"being accurate, some of which include:" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:27 @@ -1002,7 +1382,8 @@ msgid "``pip``'s download cache (lowers download counts)" msgstr "``pip`` 的下载缓存（降低下载次数）" #: ../source/guides/analyzing-pypi-package-downloads.rst:28 -msgid "Internal or unofficial mirrors (can both raise or lower download counts)" +msgid "" +"Internal or unofficial mirrors (can both raise or lower download counts)" msgstr "内部或非官方的镜像（既可以提高也可以降低下载量）" #: ../source/guides/analyzing-pypi-package-downloads.rst:29 @@ -1010,7 +1391,9 @@ msgid "Packages not hosted on PyPI (for comparisons sake)" msgstr "未在 PyPI 上托管的软件包（为了比较）" #: ../source/guides/analyzing-pypi-package-downloads.rst:30 -msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" +msgid "" +"Unofficial scripts or attempts at download count inflation (raises download " +"counts)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:32 @@ -1018,11 +1401,17 @@ msgid "Known historical data quality issues (lowers download counts)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:34 -msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" +msgid "" +"**Not particularly useful:** Just because a project has been downloaded a " +"lot doesn't mean it's good; Similarly just because a project hasn't been " +"downloaded a lot doesn't mean it's bad!" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:38 -msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." +msgid "" +"In short, because it's value is low for various reasons, and the tradeoffs " +"required to make it work are high, it has been not an effective use of " +"limited resources." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:43 @@ -1030,7 +1419,10 @@ msgid "Public dataset" msgstr "公共数据集" #: ../source/guides/analyzing-pypi-package-downloads.rst:45 -msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." +msgid "" +"As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, " +"where they are stored as a public dataset." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:50 @@ -1038,7 +1430,13 @@ msgid "Getting set up" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:52 -msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" +msgid "" +"In order to use `Google BigQuery`_ to query the `public PyPI download " +"statistics dataset`_, you'll need a Google account and to enable the " +"BigQuery API on a Google Cloud Platform project. You can run the up to 1TB " +"of queries per month `using the BigQuery free tier without a credit card " +"`__" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:58 @@ -1050,11 +1448,16 @@ msgid "Create a new project." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:60 -msgid "Enable the `BigQuery API `__." +msgid "" +"Enable the `BigQuery API `__." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:63 -msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." +msgid "" +"For more detailed instructions on how to get started with BigQuery, check " +"out the `BigQuery quickstart guide `__." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:69 @@ -1062,7 +1465,12 @@ msgid "Data schema" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:71 -msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" +msgid "" +"Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` " +"table for each download. The table contains information about what file was " +"downloaded and how it was downloaded. Some useful columns from the `table " +"schema `__ include:" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 @@ -1145,11 +1553,16 @@ msgid "Useful queries" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:95 -msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." +msgid "" +"Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" " +"button." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:97 -msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." +msgid "" +"Note that the rows are stored in a partitioned, which helps limit the cost " +"of queries. These example queries analyze downloads from recent history by " +"filtering on the ``timestamp`` column." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:102 @@ -1157,7 +1570,9 @@ msgid "Counting package downloads" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:104 -msgid "The following query counts the total number of downloads for the project \"pytest\"." +msgid "" +"The following query counts the total number of downloads for the project " +"\"pytest\"." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:119 @@ -1172,7 +1587,9 @@ msgid "26190085" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:124 -msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." +msgid "" +"To only count downloads from pip, filter on the ``details.installer.name`` " +"column." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:142 @@ -1184,7 +1601,9 @@ msgid "Package downloads over time" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:148 -msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." +msgid "" +"To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also " +"filtering by this column reduces corresponding costs." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:168 @@ -1244,7 +1663,9 @@ msgid "Python versions over time" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:186 -msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." +msgid "" +"Extract the Python version from the ``details.python`` column. Warning: This " +"query processes over 500 GB of data." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:205 @@ -1304,7 +1725,12 @@ msgid "Caveats" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:223 -msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." +msgid "" +"In addition to the caveats listed in the background above, Linehaul suffered " +"from a bug which caused it to significantly under-report download statistics " +"prior to July 26, 2018. Downloads before this date are proportionally " +"accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total " +"numbers are lower than actual by an order of magnitude." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:231 @@ -1312,7 +1738,9 @@ msgid "Additional tools" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:233 -msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." +msgid "" +"Besides using the BigQuery console, there are some additional tools which " +"may be useful when analyzing download statistics." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:237 @@ -1320,7 +1748,10 @@ msgid "``google-cloud-bigquery``" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:239 -msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." +msgid "" +"You can also access the public PyPI download statistics dataset " +"programmatically via the BigQuery API and the `google-cloud-bigquery`_ " +"project, the official Python client library for BigQuery." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:267 @@ -1328,7 +1759,10 @@ msgid "``pypinfo``" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:269 -msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." +msgid "" +"`pypinfo`_ is a command-line tool which provides access to the dataset and " +"can generate several useful queries. For example, you can query the total " +"number of download for a package with the command ``pypinfo package_name``." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:273 @@ -1344,7 +1778,8 @@ msgid "``pandas-gbq``" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:297 -msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." +msgid "" +"The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:301 @@ -1353,11 +1788,15 @@ msgid "References" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:303 -msgid "`PyPI Download Counts deprecation email `__" +msgid "" +"`PyPI Download Counts deprecation email `__" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:304 -msgid "`PyPI BigQuery dataset announcement email `__" +msgid "" +"`PyPI BigQuery dataset announcement email `__" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:3 @@ -1365,7 +1804,11 @@ msgid "Creating and discovering plugins" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:5 -msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." +msgid "" +"Often when creating a Python application or library you'll want the ability " +"to provide customizations or extra features via **plugins**. Because Python " +"packages can be separately distributed, your application or library may want " +"to automatically **discover** all of the plugins available." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:10 @@ -1389,15 +1832,25 @@ msgid "Using naming convention" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:20 -msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" +msgid "" +"If all of the plugins for your application follow the same naming " +"convention, you can use :func:`pkgutil.iter_modules` to discover all of the " +"top-level modules that match the naming convention. For example, `Flask`_ " +"uses the naming convention ``flask_{plugin_name}``. If you wanted to " +"automatically discover all of the Flask plugins installed:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:38 -msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" +msgid "" +"If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins " +"installed then ``discovered_plugins`` would be:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:48 -msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." +msgid "" +"Using naming convention for plugins also allows you to query the Python " +"Package Index's `simple API`_ for all packages that conform to your naming " +"convention." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:59 @@ -1405,19 +1858,48 @@ msgid "Using namespace packages" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:61 -msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" +msgid "" +":doc:`Namespace packages ` can be used to " +"provide a convention for where to place plugins and also provides a way to " +"perform discovery. For example, if you make the sub-package ``myapp." +"plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once " +"installed, you can use :func:`pkgutil.iter_modules` to discover all modules " +"and packages installed under that namespace:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:89 -msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" +msgid "" +"Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` " +"causes it to only look for the modules directly under that namespace. For " +"example, if you have installed distributions that provide the modules " +"``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in " +"this case would be:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:101 -msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." +msgid "" +"This sample uses a sub-package as the namespace package (``myapp.plugins``), " +"but it's also possible to use a top-level package for this purpose (such as " +"``myapp_plugins``). How to pick the namespace to use is a matter of " +"preference, but it's not recommended to make your project's main top-level " +"package (``myapp`` in this case) a namespace package for the purpose of " +"plugins, as one bad plugin could cause the entire namespace to break which " +"would in turn make your project unimportable. For the \"namespace sub-package" +"\" approach to work, the plugin packages must omit the :file:`__init__.py` " +"for your top-level package directory (``myapp`` in this case) and include " +"the namespace-package style :file:`__init__.py` in the namespace sub-package " +"directory (``myapp/plugins``). This also means that plugins will need to " +"explicitly pass a list of packages to :func:`setup`'s ``packages`` argument " +"instead of using :func:`setuptools.find_packages`." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:115 -msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." +msgid "" +"Namespace packages are a complex feature and there are several different " +"ways to create them. It's highly recommended to read the :doc:`packaging-" +"namespace-packages` documentation and clearly document which approach is " +"preferred for plugins to your project." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:121 @@ -1425,31 +1907,50 @@ msgid "Using package metadata" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:123 -msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." +msgid "" +"`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :" +"func:`setup` in :file:`setup.py` plugins can register themselves for " +"discovery." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:128 -msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" +msgid "" +"For example if you have a package named ``myapp-plugin-a`` and it includes " +"in its :file:`setup.py`:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:139 -msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" +msgid "" +"Then you can discover and load all of the registered entry points by using :" +"func:`importlib.metadata.entry_points` (or the `backport`_ " +"``importlib_metadata >= 3.6`` for Python 3.6-3.9):" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:154 -msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" +msgid "" +"In this example, ``discovered_plugins`` would be a collection of type :class:" +"`importlib.metadata.EntryPoint`:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:163 -msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." +msgid "" +"Now the module of your choice can be imported by executing " +"``discovered_plugins['a'].load()``." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:166 -msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." +msgid "" +"The ``entry_point`` specification in :file:`setup.py` is fairly flexible and " +"has a lot of options. It's recommended to read over the entire section on :" +"doc:`entry points ` ." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:170 -msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." +msgid "" +"Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools " +"provide support for defining entry points." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:5 @@ -1457,15 +1958,25 @@ msgid "Packaging and distributing projects" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:7 -msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." +msgid "" +"This section covers the basics of how to configure, package and distribute " +"your own Python projects. It assumes that you are already familiar with the " +"contents of the :doc:`/tutorials/installing-packages` page." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:11 -msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." +msgid "" +"The section does *not* aim to cover best practices for Python project " +"development as a whole. For example, it does not provide guidance or tool " +"recommendations for version control, documentation, or testing." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:15 -msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." +msgid "" +"For more reference material, see :std:doc:`Building and Distributing " +"Packages ` in the :ref:`setuptools` docs, but note that " +"some advisory content there may be outdated. In the event of conflicts, " +"prefer the advice in the Python Packaging User Guide." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:25 @@ -1473,7 +1984,9 @@ msgid "Requirements for packaging and distributing" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:26 -msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." +msgid "" +"First, make sure you have already fulfilled the :ref:`requirements for " +"installing packages `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:29 @@ -1481,7 +1994,10 @@ msgid "Install \"twine\" [1]_:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:43 -msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." +msgid "" +"You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below " +"`)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:49 @@ -1493,7 +2009,11 @@ msgid "Initial files" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:58 -msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." +msgid "" +"The most important file is :file:`setup.py` which exists at the root of your " +"project directory. For an example, see the `setup.py `_ in the `PyPA sample project " +"`_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:63 @@ -1501,15 +2021,27 @@ msgid ":file:`setup.py` serves two primary functions:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:65 -msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." +msgid "" +"It's the file where various aspects of your project are configured. The " +"primary feature of :file:`setup.py` is that it contains a global ``setup()`` " +"function. The keyword arguments to this function are how specific details " +"of your project are defined. The most relevant arguments are explained in :" +"ref:`the section below `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:71 -msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." +msgid "" +"It's the command line interface for running various commands that relate to " +"packaging tasks. To get a listing of available commands, run ``python setup." +"py --help-commands``." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:79 -msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." +msgid "" +":file:`setup.cfg` is an ini file that contains option defaults for :file:" +"`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project " +"`_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:86 @@ -1517,15 +2049,31 @@ msgid "README.rst / README.md" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:88 -msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." +msgid "" +"All projects should contain a readme file that covers the goal of the " +"project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not " +"a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:" +"`long_description_content_type ` argument)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:95 -msgid "For an example, see `README.md `_ from the `PyPA sample project `_." +msgid "" +"For an example, see `README.md `_ from the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:99 -msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." +msgid "" +"Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:" +"`README.rst`, :file:`README.txt`, or :file:`README`) included in source " +"distributions by default. The built-in :ref:`distutils` library adopts this " +"behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ " +"will include a :file:`README.md` if found. If you are using setuptools, you " +"don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, " +"include it to be explicit." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:108 @@ -1533,15 +2081,23 @@ msgid "MANIFEST.in" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:110 -msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." +msgid "" +"A :file:`MANIFEST.in` is needed when you need to package additional files " +"that are not automatically included in a source distribution. For details " +"on writing a :file:`MANIFEST.in` file, including a list of what's included " +"by default, see \":ref:`Using MANIFEST.in`\"." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:115 -msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." +msgid "" +"For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:119 -msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." +msgid "" +":file:`MANIFEST.in` does not affect binary distributions such as wheels." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:122 @@ -1549,11 +2105,20 @@ msgid "LICENSE.txt" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:124 -msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." +msgid "" +"Every package should include a license file detailing the terms of " +"distribution. In many jurisdictions, packages without an explicit license " +"can not be legally used or distributed by anyone other than the copyright " +"holder. If you're unsure which license to choose, you can use resources such " +"as `GitHub's Choose a License `_ or consult a " +"lawyer." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:130 -msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." +msgid "" +"For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:135 @@ -1561,11 +2126,17 @@ msgid "" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:137 -msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." +msgid "" +"Although it's not required, the most common practice is to include your " +"Python modules and packages under a single top-level package that has the " +"same :ref:`name ` as your project, or something very close." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:141 -msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." +msgid "" +"For an example, see the `sample `_ package that's included in the `PyPA sample project " +"`_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:149 @@ -1573,11 +2144,18 @@ msgid "setup() args" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:151 -msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." +msgid "" +"As mentioned above, the primary feature of :file:`setup.py` is that it " +"contains a global ``setup()`` function. The keyword arguments to this " +"function are how specific details of your project are defined." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:155 -msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." +msgid "" +"The most relevant arguments are explained below. Most of the snippets given " +"are taken from the `setup.py `_ contained in the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:164 @@ -1585,11 +2163,16 @@ msgid "name" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:170 -msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" +msgid "" +"This is the name of your project, determining how your project is listed on :" +"term:`PyPI `. Per :pep:`508`, valid project " +"names must:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:174 -msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" +msgid "" +"Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), " +"and/or periods (``.``), and" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:176 @@ -1597,7 +2180,11 @@ msgid "Start & end with an ASCII letter or digit." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:178 -msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" +msgid "" +"Comparison of project names is case insensitive and treats arbitrarily-long " +"runs of underscores, hyphens, and/or periods as equal. For example, if you " +"register a project named ``cool-stuff``, users will be able to download it " +"or declare a dependency on it using any of the following spellings::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:190 @@ -1606,19 +2193,30 @@ msgid "version" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:196 -msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." +msgid "" +"This is the current version of your project, allowing your users to " +"determine whether or not they have the latest version, and to indicate which " +"specific versions they've tested their own software against." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:200 -msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." +msgid "" +"Versions are displayed on :term:`PyPI ` for " +"each release if you publish your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:203 -msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." +msgid "" +"See :ref:`Choosing a versioning scheme` for more information on ways to use " +"versions to convey compatibility information to your users." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:206 -msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." +msgid "" +"If the project code itself needs run-time access to the version, the " +"simplest way is to keep the version in both :file:`setup.py` and your code. " +"If you'd rather not duplicate the value, there are a few ways to manage " +"this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:214 @@ -1630,15 +2228,32 @@ msgid "Give a short and long description for your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:224 -msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." +msgid "" +"These values will be displayed on :term:`PyPI ` " +"if you publish your project. On ``pypi.org``, the user interface displays " +"``description`` in the grey banner and ``long_description`` in the section " +"named \"Project Description\"." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:229 -msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." +msgid "" +"``description`` is also displayed in lists of projects. For example, it's " +"visible in the search results pages such as https://pypi.org/search/?" +"q=jupyter, the front-page lists of trending projects and new releases, and " +"the list of projects you maintain within your account profile (such as " +"https://pypi.org/user/jaraco/)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:235 -msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." +msgid "" +"A `content type `_ can be specified with the " +"``long_description_content_type`` argument, which can be one of ``text/" +"plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no " +"formatting, `reStructuredText (reST) `_, and the Github-flavored " +"Markdown dialect of `Markdown `_ respectively." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:245 @@ -1662,11 +2277,21 @@ msgid "license" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:273 -msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." +msgid "" +"The ``license`` argument doesn't have to indicate the license under which " +"your package is being released, although you may optionally do so if you " +"want. If you're using a standard, well-known license, then your main " +"indication can and should be via the ``classifiers`` argument. Classifiers " +"exist for all major open-source licenses." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:279 -msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." +msgid "" +"The \"license\" argument is more typically used to indicate differences from " +"well-known licenses, or to include your own, unique license. As a general " +"rule, it's a good idea to use a standard, well-known license, both to avoid " +"confusion and because some organizations avoid software whose license is " +"unapproved." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:287 @@ -1674,11 +2299,18 @@ msgid "classifiers" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:316 -msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." +msgid "" +"Provide a list of classifiers that categorize your project. For a full " +"listing, see https://pypi.org/classifiers/." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:319 -msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." +msgid "" +"Although the list of classifiers is often used to declare what Python " +"versions a project supports, this information is only used for searching & " +"browsing projects on PyPI, not for installing projects. To actually " +"restrict what Python versions a project can be installed on, use the :ref:" +"`python_requires` argument." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:327 @@ -1694,7 +2326,11 @@ msgid "project_urls" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:349 -msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." +msgid "" +"List additional relevant URLs about your project. This is the place to link " +"to bug trackers, source repositories, or where to support package " +"development. The string of the key is the exact text that will be displayed " +"on PyPI." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:355 @@ -1702,7 +2338,13 @@ msgid "packages" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:361 -msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." +msgid "" +"Set ``packages`` to a list of all :term:`packages ` in your " +"project, including their subpackages, sub-subpackages, etc. Although the " +"packages can be listed manually, ``setuptools.find_packages()`` finds them " +"automatically. Use the ``include`` keyword argument to find only the given " +"packages. Use the ``exclude`` keyword argument to omit packages that are " +"not intended to be released and installed." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:370 @@ -1710,15 +2352,23 @@ msgid "py_modules" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:376 -msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." +msgid "" +"If your project contains any single-file Python modules that aren't part of " +"a package, set ``py_modules`` to a list of the names of the modules (minus " +"the ``.py`` extension) in order to make :ref:`setuptools` aware of them." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:388 -msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgid "" +"\"install_requires\" should be used to specify what dependencies a project " +"minimally needs to run. When the project is installed by :ref:`pip`, this is " +"the specification that is used to install its dependencies." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:392 -msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." +msgid "" +"For more on using \"install_requires\" see :ref:`install_requires vs " +"Requirements files`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:398 @@ -1726,11 +2376,17 @@ msgid "python_requires" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:400 -msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" +msgid "" +"If your project only runs on certain Python versions, setting the " +"``python_requires`` argument to the appropriate :pep:`440` version specifier " +"string will prevent :ref:`pip` from installing the project on other Python " +"versions. For example, if your package is for Python 3+ only, write::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:407 -msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" +msgid "" +"If your package is for Python 2.6, 2.7, and all versions of Python 3 " +"starting with 3.3, write::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:412 @@ -1738,11 +2394,20 @@ msgid "And so on." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:416 -msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." +msgid "" +"Support for this feature is relatively recent. Your project's source " +"distributions and wheels (see :ref:`Packaging Your Project`) must be built " +"using at least version 24.2.0 of :ref:`setuptools` in order for the " +"``python_requires`` argument to be recognized and the appropriate metadata " +"generated." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:422 -msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." +msgid "" +"In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the " +"``python_requires`` metadata. Users with earlier versions of pip will be " +"able to download & install projects on any Python version regardless of the " +"projects' ``python_requires`` values." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:431 @@ -1750,15 +2415,25 @@ msgid "package_data" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:440 -msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." +msgid "" +"Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the " +"package’s implementation, or text files containing documentation that might " +"be of interest to programmers using the package. These files are called " +"\"package data\"." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:445 -msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." +msgid "" +"The value must be a mapping from package name to a list of relative path " +"names that should be copied into the package. The paths are interpreted as " +"relative to the directory containing the package." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:449 -msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." +msgid "" +"For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:457 @@ -1766,19 +2441,39 @@ msgid "data_files" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:463 -msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." +msgid "" +"Although configuring :ref:`Package Data` is sufficient for most needs, in " +"some cases you may need to place data files *outside* of your :term:" +"`packages `. The ``data_files`` directive allows you to do " +"that. It is mostly useful if you need to install files which are used by " +"other programs, which may be unaware of Python packages." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:469 -msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." +msgid "" +"Each ``(directory, files)`` pair in the sequence specifies the installation " +"directory and the files to install there. The ``directory`` must be a " +"relative path (although this may change in the future, see `wheel Issue #92 " +"`_). and it is interpreted relative " +"to the installation prefix (Python’s ``sys.prefix`` for a default " +"installation; ``site.USER_BASE`` for a user installation). Each file name in " +"``files`` is interpreted relative to the :file:`setup.py` script at the top " +"of the project source distribution." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:479 -msgid "For more information see the distutils section on `Installing Additional Files `_." +msgid "" +"For more information see the distutils section on `Installing Additional " +"Files `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:484 -msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." +msgid "" +"When installing packages as egg, ``data_files`` is not supported. So, if " +"your project uses :ref:`setuptools`, you must use ``pip`` to install it. " +"Alternatively, if you must use ``python setup.py``, then you need to pass " +"the ``--old-and-unmanageable`` option." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:491 @@ -1786,7 +2481,11 @@ msgid "scripts" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:493 -msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." +msgid "" +"Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made " +"scripts to install, the recommended approach to achieve cross-platform " +"compatibility is to use :ref:`console_scripts` entry points (see below)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:500 @@ -1794,11 +2493,17 @@ msgid "entry_points" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:509 -msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." +msgid "" +"Use this keyword to specify any plugins that your project provides for any " +"named entry points that may be defined by your project or others that you " +"depend on." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:512 -msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." +msgid "" +"For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:516 @@ -1810,11 +2515,20 @@ msgid "console_scripts" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:531 -msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgid "" +"Use \"console_script\" `entry points `_ to " +"register your script interfaces. You can then let the toolchain handle the " +"work of turning these interfaces into actual scripts [2]_. The scripts will " +"be generated during the install of your :term:`distribution `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:538 -msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." +msgid "" +"For more information, see `Automatic Script Creation `_ from " +"the `setuptools docs `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:545 @@ -1826,7 +2540,12 @@ msgid "Standards compliance for interoperability" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:550 -msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." +msgid "" +"Different Python projects may use different versioning schemes based on the " +"needs of that particular project, but all of them are required to comply " +"with the flexible :pep:`public version scheme <440#public-version-" +"identifiers>` specified in :pep:`440` in order to be supported in tools and " +"libraries like ``pip`` and ``setuptools``." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:556 @@ -1834,7 +2553,11 @@ msgid "Here are some examples of compliant version numbers::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:567 -msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." +msgid "" +"To further accommodate historical variations in approaches to version " +"numbering, :pep:`440` also defines a comprehensive technique for :pep:" +"`version normalisation <440#normalization>` that maps variant spellings of " +"different version numbers to a standardised canonical form." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:573 @@ -1846,11 +2569,16 @@ msgid "Semantic versioning (preferred)" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:578 -msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." +msgid "" +"For new projects, the recommended versioning scheme is based on `Semantic " +"Versioning `_, but adopts a different approach to " +"handling pre-releases and build metadata." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:582 -msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" +msgid "" +"The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE " +"numbering scheme, where the project author increments:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:585 @@ -1858,7 +2586,9 @@ msgid "MAJOR version when they make incompatible API changes," msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:586 -msgid "MINOR version when they add functionality in a backwards-compatible manner, and" +msgid "" +"MINOR version when they add functionality in a backwards-compatible manner, " +"and" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:587 @@ -1866,11 +2596,17 @@ msgid "MAINTENANCE version when they make backwards-compatible bug fixes." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:589 -msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." +msgid "" +"Adopting this approach as a project author allows users to make use of :pep:`" +"\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= " +"X.Y`` requires at least release X.Y, but also allows any later release with " +"a matching MAJOR version." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:594 -msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." +msgid "" +"Python projects adopting semantic versioning should abide by clauses 1-8 of " +"the `Semantic Versioning 2.0.0 specification `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:598 @@ -1878,15 +2614,23 @@ msgid "Date based versioning" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:600 -msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." +msgid "" +"Semantic versioning is not a suitable choice for all projects, such as those " +"with a regular time based release cadence and a deprecation process that " +"provides warnings for a number of releases prior to removal of a feature." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:604 -msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." +msgid "" +"A key advantage of date based versioning is that it is straightforward to " +"tell how old the base feature set of a particular release is given just the " +"version number." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:607 -msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." +msgid "" +"Version numbers for date based projects typically take the form of YEAR." +"MONTH (for example, ``12.04``, ``15.10``)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:611 @@ -1894,11 +2638,16 @@ msgid "Serial versioning" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:613 -msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." +msgid "" +"This is the simplest possible versioning scheme, and consists of a single " +"number which is incremented every release." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:616 -msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." +msgid "" +"While serial versioning is very easy to manage as a developer, it is the " +"hardest to track as an end user, as serial version numbers convey little or " +"no information regarding API backwards compatibility." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:621 @@ -1906,7 +2655,11 @@ msgid "Hybrid schemes" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:623 -msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." +msgid "" +"Combinations of the above schemes are possible. For example, a project may " +"combine date based versioning with serial versioning to create a YEAR.SERIAL " +"numbering scheme that readily conveys the approximate age of a release, but " +"doesn't otherwise commit to a particular release cadence within the year." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:629 @@ -1914,7 +2667,9 @@ msgid "Pre-release versioning" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:631 -msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" +msgid "" +"Regardless of the base versioning scheme, pre-releases for a given final " +"release may be published as:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:634 @@ -1934,7 +2689,9 @@ msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:639 -msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." +msgid "" +"``pip`` and other modern Python package installers ignore pre-releases by " +"default when deciding which versions of dependencies to install." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:644 @@ -1942,11 +2699,19 @@ msgid "Local version identifiers" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:646 -msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." +msgid "" +"Public version identifiers are designed to support distribution via :term:" +"`PyPI `. Python's software distribution tools " +"also support the notion of a :pep:`local version identifier <440#local-" +"version-identifiers>`, which can be used to identify local development " +"builds not intended for publication, or modified variants of a release " +"maintained by a redistributor." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:653 -msgid "A local version identifier takes the form ``+``. For example::" +msgid "" +"A local version identifier takes the form ``" +"+``. For example::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:661 @@ -1954,7 +2719,10 @@ msgid "Working in \"development mode\"" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:663 -msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." +msgid "" +"Although not required, it's common to locally install your project in " +"\"editable\" or \"develop\" mode while you're working on it. This allows " +"your project to be both installed and editable in project form." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:667 @@ -1962,31 +2730,56 @@ msgid "Assuming you're in the root of your project directory, then run:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:674 -msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." +msgid "" +"Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` " +"refers to the current working directory, so together, it means to install " +"the current directory (i.e. your project) in editable mode. This will also " +"install any dependencies declared with \"install_requires\" and any scripts " +"declared with \"console_scripts\". Dependencies will be installed in the " +"usual, non-editable mode." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:680 -msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" +msgid "" +"It's fairly common to also want to install some of your dependencies in " +"editable mode as well. For example, supposing your project requires \"foo\" " +"and \"bar\", but you want \"bar\" installed from VCS in editable mode, then " +"you could construct a requirements file like so::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:688 -msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." +msgid "" +"The first line says to install your project and any dependencies. The second " +"line overrides the \"bar\" dependency, such that it's fulfilled from VCS, " +"not PyPI." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:692 -msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" +msgid "" +"If, however, you want \"bar\" installed from a local directory in editable " +"mode, the requirements file should look like this, with the local paths at " +"the top of the file::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:697 -msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." +msgid "" +"Otherwise, the dependency will be fulfilled from PyPI, due to the " +"installation order of the requirements file. For more on requirements " +"files, see the :ref:`Requirements File ` section in " +"the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:701 -msgid "Lastly, if you don't want to install any dependencies at all, you can run::" +msgid "" +"Lastly, if you don't want to install any dependencies at all, you can run::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:706 -msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." +msgid "" +"For more information, see the `Development Mode `_ section of the " +"`setuptools docs `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:713 @@ -1994,11 +2787,17 @@ msgid "Packaging your project" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:715 -msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." +msgid "" +"To have your project installable from a :term:`Package Index` like :term:" +"`PyPI `, you'll need to create a :term:" +"`Distribution ` (aka \":term:`Package `\") for your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:720 -msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" +msgid "" +"Before you can build wheels and sdists for your project, you'll need to " +"install the ``build`` package:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:737 @@ -2006,11 +2805,18 @@ msgid "Source distributions" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:739 -msgid "Minimally, you should create a :term:`Source Distribution `:" +msgid "" +"Minimally, you should create a :term:`Source Distribution `:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:755 -msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." +msgid "" +"A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built " +"Distribution`), and requires a build step when installed by pip. Even if " +"the distribution is pure Python (i.e. contains no extensions), it still " +"involves a build step to build out the installation metadata from :file:" +"`setup.py` and/or :file:`setup.cfg`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:763 @@ -2018,23 +2824,36 @@ msgid "Wheels" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:765 -msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." +msgid "" +"You should also create a wheel for your project. A wheel is a :term:`built " +"package ` that can be installed without needing to go " +"through the \"build\" process. Installing wheels is substantially faster for " +"the end user than installing from a source distribution." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:770 -msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." +msgid "" +"If your project is pure Python then you'll be creating a :ref:`\"Pure Python " +"Wheel\" (see section below) `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:773 -msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." +msgid "" +"If your project contains compiled extensions, then you'll be creating what's " +"called a :ref:`*Platform Wheel* (see section below) `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:776 -msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" +msgid "" +"If your project also supports Python 2 *and* contains no C extensions, then " +"you should create what's called a *Universal Wheel* by adding the following " +"to your :file:`setup.cfg` file:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:785 -msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." +msgid "" +"Only use this setting if your project does not have any C extensions *and* " +"supports Python 2 and 3." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:792 @@ -2042,7 +2861,9 @@ msgid "Pure Python Wheels" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:794 -msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." +msgid "" +"*Pure Python Wheels* contain no compiled extensions, and therefore only " +"require a single Python wheel." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:797 @@ -2051,11 +2872,16 @@ msgid "To build the wheel:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:811 -msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." +msgid "" +"The ``wheel`` package will detect that the code is pure Python, and build a " +"wheel that's named such that it's usable on any Python 3 installation. For " +"details on the naming of wheel files, see :pep:`425`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:815 -msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." +msgid "" +"If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both " +"files for you; this is useful when you don't need multiple wheels." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:821 @@ -2063,15 +2889,23 @@ msgid "Platform Wheels" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:823 -msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." +msgid "" +"*Platform Wheels* are wheels that are specific to a certain platform like " +"Linux, macOS, or Windows, usually due to containing compiled extensions." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:841 -msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." +msgid "" +"The ``wheel`` package will detect that the code is not pure Python, and " +"build a wheel that's named such that it's only usable on the platform that " +"it was built on. For details on the naming of wheel files, see :pep:`425`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:847 -msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." +msgid "" +":term:`PyPI ` currently supports uploads of " +"platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. " +"Details of the latter are defined in :pep:`513`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:855 @@ -2079,23 +2913,45 @@ msgid "Uploading your Project to PyPI" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:857 -msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." +msgid "" +"When you ran the command to create your distribution, a new directory ``dist/" +"`` was created under your project's root directory. That's where you'll find " +"your distribution file(s) to upload." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:861 -msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." +msgid "" +"These files are only created when you run the command to create your " +"distribution. This means that any time you change the source of your project " +"or the configuration in your :file:`setup.py` file, you will need to rebuild " +"these files again before you can distribute the changes to PyPI." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:866 -msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." +msgid "" +"Before releasing on main PyPI repo, you might prefer training with the `PyPI " +"test site `_ which is cleaned on a semi regular " +"basis. See :ref:`using-test-pypi` on how to setup your configuration in " +"order to use it." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:871 -msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." +msgid "" +"In other resources you may encounter references to using ``python setup.py " +"register`` and ``python setup.py upload``. These methods of registering and " +"uploading a package are **strongly discouraged** as it may use a plaintext " +"HTTP or unverified HTTPS connection on some Python versions, allowing your " +"username and password to be intercepted during transmission." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:877 -msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" +msgid "" +"The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to " +"ensure safety of all users, certain kinds of URLs and directives are " +"forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** " +"trying to upload your distribution, you should check to see if your brief / " +"long descriptions provided in :file:`setup.py` are valid. You can do this " +"by running :std:doc:`twine check ` on your package files::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:888 @@ -2103,23 +2959,35 @@ msgid "Create an account" msgstr "创建一个账户" #: ../source/guides/distributing-packages-using-setuptools.rst:890 -msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." +msgid "" +"First, you need a :term:`PyPI ` user account. " +"You can create an account `using the form on the PyPI website `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:894 -msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." +msgid "" +"Now you'll create a PyPI `API token`_ so you will be able to securely upload " +"your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:897 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." +msgid "" +"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " +"token`_; don't limit its scope to a particular project, since you are " +"creating a new project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:901 -msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgid "" +"**Don't close the page until you have copied and saved the token — you won't " +"see that token again.**" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:904 -msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" +msgid "" +"To avoid having to copy and paste the token every time you upload, you can " +"create a :file:`$HOME/.pypirc` file:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:913 @@ -2130,7 +2998,8 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:70 #: ../source/guides/migrating-to-pypi-org.rst:109 #: ../source/guides/using-testpypi.rst:83 -msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." +msgid "" +"For more details, see the :ref:`specification ` for :file:`.pypirc`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:921 @@ -2138,28 +3007,46 @@ msgid "Upload your distributions" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:923 -msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." +msgid "" +"Once you have an account you can upload your distributions to :term:`PyPI " +"` using :ref:`twine`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:926 -msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." +msgid "" +"The process for uploading a release is the same regardless of whether or not " +"the project already exists on PyPI - if it doesn't exist yet, it will be " +"automatically created when the first release is uploaded." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:930 -msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." +msgid "" +"For the second and subsequent releases, PyPI only requires that the version " +"number of the new release differ from any previous releases." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:937 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgid "" +"You can see if your package has successfully uploaded by navigating to the " +"URL ``https://pypi.org/project/`` where ``sampleproject`` is " +"the name of your project that you uploaded. It may take a minute or two for " +"your project to appear on the site." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:944 #: ../source/tutorials/installing-packages.rst:663 -msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." +msgid "" +"Depending on your platform, this may require root or Administrator access. :" +"ref:`pip` is currently considering changing this by `making user installs " +"the default behavior `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:950 -msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." +msgid "" +"Specifically, the \"console_script\" approach generates ``.exe`` files on " +"Windows, which are necessary because the OS special-cases ``.exe`` files. " +"Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for " +"Windows <397>` allow scripts to be used in many cases, but not all." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:5 @@ -2167,19 +3054,30 @@ msgid "Dropping support for older Python versions" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:7 -msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." +msgid "" +"Dropping support for older Python versions is supported by the standard :ref:" +"`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:9 -msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." +msgid "" +"Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification " +"by matching the current Python runtime and comparing it with the required " +"version in the package metadata. If they do not match, it will attempt to " +"install the last package distribution that supported that Python runtime." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:12 -msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." +msgid "" +"This mechanism can be used to drop support for older Python versions, by " +"amending the \"Requires-Python\" attribute in the package metadata." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:14 -msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." +msgid "" +"This guide is specifically for users of :ref:`setuptools`, other packaging " +"tools such as ``flit`` may offer similar functionality but users will need " +"to consult relevant documentation." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:17 @@ -2199,7 +3097,9 @@ msgid "The latest version of :ref:`twine` is used to upload the package," msgstr "" #: ../source/guides/dropping-older-python-versions.rst:23 -msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." +msgid "" +"The user installing the package has at least Pip 9.0, or a client that " +"supports the Metadata 1.2 specification." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:26 @@ -2207,15 +3107,26 @@ msgid "Dealing with the universal wheels" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:28 -msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." +msgid "" +"Traditionally, projects providing Python code that is semantically " +"compatible with both Python 2 and Python 3, produce :term:`wheels ` " +"that have a ``py2.py3`` tag in their names. When dropping support for Python " +"2, it is important not to forget to change this tag to just ``py3``. It is " +"often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` " +"section by setting ``universal = 1`` if they use setuptools." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:36 -msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" +msgid "" +"If you use this method, either remove this option or section, or explicitly " +"set ``universal`` to ``0``:" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:48 -msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." +msgid "" +"Since it is possible to override the :file:`setup.cfg` settings via CLI " +"flags, make sure that your scripts don't have ``--universal`` in your " +"package creation scripts." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:53 @@ -2227,7 +3138,9 @@ msgid "1. Download the newest version of Setuptools" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:58 -msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." +msgid "" +"Ensure that before you generate source distributions or binary " +"distributions, you update Setuptools and install twine." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:60 @@ -2243,7 +3156,9 @@ msgid "2. Specify the version ranges for supported Python distributions" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:79 -msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." +msgid "" +"You can specify version ranges and exclusion rules, such as at least Python " +"3. Or, Python 2.7, 3.4 and beyond." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:81 @@ -2259,7 +3174,10 @@ msgid "Examples::" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:86 -msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." +msgid "" +"The way to set those values is within the call to ``setup`` within your :" +"file:`setup.py` script. This will insert the ``Requires-Python`` metadata " +"values based on the argument you provide in ``python_requires``." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:101 @@ -2267,11 +3185,16 @@ msgid "3. Validating the Metadata before publishing" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:103 -msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." +msgid "" +"Within a Python source package (the zip or the tar-gz file you download) is " +"a text file called PKG-INFO." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:105 -msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." +msgid "" +"This file is generated by Distutils or :ref:`setuptools` when it generates " +"the source package. The file contains a set of keys and values, the list of " +"keys is part of the PyPa standard metadata format." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:108 @@ -2283,11 +3206,14 @@ msgid "Validate that the following is in place, before publishing the package:" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:114 -msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." +msgid "" +"If you have upgraded correctly, the Metadata-Version value should be 1.2 or " +"higher." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:115 -msgid "The Requires-Python field is set and matches your specification in setup.py." +msgid "" +"The Requires-Python field is set and matches your specification in setup.py." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:118 @@ -2295,7 +3221,9 @@ msgid "4. Using Twine to publish" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:120 -msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." +msgid "" +"Twine has a number of advantages, apart from being faster it is now the " +"supported method for publishing packages." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:122 @@ -2307,7 +3235,9 @@ msgid "Dropping a Python release" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:127 -msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." +msgid "" +"Once you have published a package with the Requires-Python metadata, you can " +"then make a further update removing that Python runtime from support." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:129 @@ -2315,11 +3245,17 @@ msgid "It must be done in this order for the automated fallback to work." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:131 -msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." +msgid "" +"For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 " +"of your package." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:133 -msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." +msgid "" +"If you were then to update the version string to \">=3.5\", and publish a " +"new version 2.0.0 of your package, any users running Pip 9.0+ from version " +"2.7 will have version 1.0.0 of the package installed, and any >=3.5 users " +"will receive version 2.0.0." msgstr "" #: ../source/guides/hosting-your-own-index.rst:5 @@ -2327,15 +3263,25 @@ msgid "Hosting your own simple repository" msgstr "" #: ../source/guides/hosting-your-own-index.rst:8 -msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." +msgid "" +"If you wish to host your own simple repository [1]_, you can either use a " +"software package like `devpi`_ or you can use simply create the proper " +"directory structure and use any web server that can serve static files and " +"generate an autoindex." msgstr "" #: ../source/guides/hosting-your-own-index.rst:13 -msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" +msgid "" +"In either case, since you'll be hosting a repository that is likely not in " +"your user's default repositories, you should instruct them in your project's " +"description to configure their installer appropriately. For example with pip:" msgstr "" #: ../source/guides/hosting-your-own-index.rst:29 -msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." +msgid "" +"In addition, it is **highly** recommended that you serve your repository " +"with valid HTTPS. At this time, the security of your user's installations " +"depends on all repositories using a valid HTTPS setup." msgstr "" #: ../source/guides/hosting-your-own-index.rst:35 @@ -2343,34 +3289,45 @@ msgid "\"Manual\" repository" msgstr "" #: ../source/guides/hosting-your-own-index.rst:37 -msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" +msgid "" +"The directory layout is fairly simple, within a root directory you need to " +"create a directory for each project. This directory should be the normalized " +"name (as defined by :pep:`503`) of the project. Within each of these " +"directories simply place each of the downloadable files. If you have the " +"projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the " +"version 0.1) You should end up with a structure that looks like::" msgstr "" #: ../source/guides/hosting-your-own-index.rst:51 -msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." +msgid "" +"Once you have this layout, simply configure your webserver to serve the root " +"directory with autoindex enabled. For an example using the built in Web " +"server in `Twisted`_, you would simply run ``twistd -n web --path .`` and " +"then instruct users to add the URL to their installer's configuration." msgstr "" #: ../source/guides/hosting-your-own-index.rst:58 -msgid "For complete documentation of the simple repository protocol, see :pep:`503`." +msgid "" +"For complete documentation of the simple repository protocol, see :pep:`503`." msgstr "" -#: ../source/guides/index.rst:8 #: ../source/guides/index.rst:8 msgid "Installing Packages:" msgstr "" -#: ../source/guides/index.rst:20 #: ../source/guides/index.rst:20 msgid "Building and Publishing Projects:" msgstr "" -#: ../source/guides/index.rst:38 #: ../source/guides/index.rst:38 msgid "Miscellaneous:" msgstr "" #: ../source/guides/index.rst:4 -msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." +msgid "" +"**Guides** are focused on accomplishing a specific task and assume that you " +"are already familiar with the basics of Python packaging. If you're looking " +"for an introduction to packaging, see :doc:`/tutorials/index`." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:5 @@ -2383,7 +3340,10 @@ msgid "2014-12-24" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:14 -msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." +msgid "" +"Mirroring or caching of PyPI can be used to speed up local package " +"installation, allow offline work, handle corporate firewalls or just plain " +"Internet flakiness." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:17 @@ -2395,11 +3355,15 @@ msgid "pip provides local caching options," msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:20 -msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" +msgid "" +"devpi provides higher-level caching option, potentially shared amongst many " +"users or machines, and" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:22 -msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." +msgid "" +"bandersnatch provides a local complete mirror of all PyPI :term:`packages " +"`." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:27 @@ -2407,15 +3371,23 @@ msgid "Caching with pip" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:29 -msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" +msgid "" +"pip provides a number of facilities for speeding up installation by using " +"local cached copies of :term:`packages `:" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:32 -msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." +msgid "" +"`Fast & local installs `_ by downloading all the requirements for a project and " +"then pointing pip at those downloaded files instead of going to PyPI." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:36 -msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" +msgid "" +"A variation on the above which pre-builds the installation files for the " +"requirements using `python -m pip wheel `_::" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:45 @@ -2423,7 +3395,10 @@ msgid "Caching with devpi" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:47 -msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." +msgid "" +"devpi is a caching proxy server which you run on your laptop, or some other " +"machine you know will always be available to you. See the `devpi " +"documentation for getting started`__." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:55 @@ -2431,11 +3406,18 @@ msgid "Complete mirror with bandersnatch" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:57 -msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." +msgid "" +"bandersnatch will set up a complete local mirror of all PyPI :term:`packages " +"` (externally-hosted packages are not mirrored). See " +"the `bandersnatch documentation for getting that going`__." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:63 -msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." +msgid "" +"A benefit of devpi is that it will create a mirror which includes :term:" +"`packages ` that are external to PyPI, unlike " +"bandersnatch which will only cache :term:`packages ` " +"hosted on PyPI." msgstr "" #: ../source/guides/installing-scientific-packages.rst:5 @@ -2443,19 +3425,38 @@ msgid "Installing scientific packages" msgstr "" #: ../source/guides/installing-scientific-packages.rst:11 -msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." +msgid "" +"Scientific software tends to have more complex dependencies than most, and " +"it will often have multiple build options to take advantage of different " +"kinds of hardware, or to interoperate with different pieces of external " +"software." msgstr "" #: ../source/guides/installing-scientific-packages.rst:16 -msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." +msgid "" +"In particular, `NumPy `__, which provides the basis " +"for most of the software in the `scientific Python stack `__ can be configured to interoperate with " +"different FORTRAN libraries, and can take advantage of different levels of " +"vectorised instructions available in modern CPUs." msgstr "" #: ../source/guides/installing-scientific-packages.rst:22 -msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." +msgid "" +"Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built " +"32-bit and 64-bit binaries in the ``wheel`` format are available for all " +"major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, " +"that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, " +"so they may not provide optimal linear algebra performance." msgstr "" #: ../source/guides/installing-scientific-packages.rst:29 -msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." +msgid "" +"There are a number of alternative options for obtaining scientific Python " +"libraries (or any other Python libraries that require a compilation " +"environment to install from source and don't provide pre-built wheel files " +"on PyPI)." msgstr "" #: ../source/guides/installing-scientific-packages.rst:35 @@ -2463,7 +3464,12 @@ msgid "Building from source" msgstr "" #: ../source/guides/installing-scientific-packages.rst:37 -msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." +msgid "" +"The same complexity which makes it difficult to distribute NumPy (and many " +"of the projects that depend on it) as wheel files also make them difficult " +"to build from source yourself. However, for intrepid folks that are willing " +"to spend the time wrangling compilers and linkers for both C and FORTRAN, " +"building from source is always an option." msgstr "" #: ../source/guides/installing-scientific-packages.rst:45 @@ -2471,11 +3477,18 @@ msgid "Linux distribution packages" msgstr "" #: ../source/guides/installing-scientific-packages.rst:47 -msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." +msgid "" +"For Linux users, the system package manager will often have pre-compiled " +"versions of various pieces of scientific software, including NumPy and other " +"parts of the scientific Python stack." msgstr "" #: ../source/guides/installing-scientific-packages.rst:51 -msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." +msgid "" +"If using versions which may be several months old is acceptable, then this " +"is likely to be a good option (just make sure to allow access to " +"distributions installed into the system Python when using virtual " +"environments)." msgstr "" #: ../source/guides/installing-scientific-packages.rst:57 @@ -2483,23 +3496,42 @@ msgid "Windows installers" msgstr "" #: ../source/guides/installing-scientific-packages.rst:59 -msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." +msgid "" +"Many Python projects that don't (or can't) currently publish wheel files at " +"least publish Windows installers, either on PyPI or on their project " +"download page. Using these installers allows users to avoid the need to set " +"up a suitable environment to build extensions locally." msgstr "" #: ../source/guides/installing-scientific-packages.rst:64 -msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." +msgid "" +"The extensions provided in these installers are typically compatible with " +"the CPython Windows installers published on python.org." msgstr "" #: ../source/guides/installing-scientific-packages.rst:67 -msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." +msgid "" +"For projects which don't provide their own Windows installers (and even some " +"which do), Christoph Gohlke at the University of California provides a " +"`collection of Windows installers `__. Many Python users on Windows have reported a positive experience with " +"these prebuilt versions." msgstr "" #: ../source/guides/installing-scientific-packages.rst:73 -msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." +msgid "" +"As with Linux system packages, the Windows installers will only install into " +"a system Python installation - they do not support installation in virtual " +"environments. Allowing access to distributions installed into the system " +"Python when using virtual environments is a common approach to working " +"around this limitation." msgstr "" #: ../source/guides/installing-scientific-packages.rst:79 -msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." +msgid "" +"The :term:`Wheel` project also provides a :command:`wheel convert` " +"subcommand that can convert a Windows :command:`bdist_wininst` installer to " +"a wheel." msgstr "" #: ../source/guides/installing-scientific-packages.rst:86 @@ -2507,11 +3539,18 @@ msgid "macOS installers and package managers" msgstr "" #: ../source/guides/installing-scientific-packages.rst:88 -msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." +msgid "" +"Similar to the situation on Windows, many projects (including NumPy) publish " +"macOS installers that are compatible with the macOS CPython binaries " +"published on python.org." msgstr "" #: ../source/guides/installing-scientific-packages.rst:92 -msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" +msgid "" +"macOS users also have access to Linux distribution style package managers " +"such as ``MacPorts``. The SciPy site has more details on using MacPorts to " +"install the `scientific Python stack `__" msgstr "" #: ../source/guides/installing-scientific-packages.rst:99 @@ -2519,11 +3558,16 @@ msgid "SciPy distributions" msgstr "" #: ../source/guides/installing-scientific-packages.rst:101 -msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." +msgid "" +"The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use " +"and update format." msgstr "" #: ../source/guides/installing-scientific-packages.rst:105 -msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." +msgid "" +"Some of these distributions may not be compatible with the standard ``pip`` " +"and ``virtualenv`` based toolchain." msgstr "" #: ../source/guides/installing-scientific-packages.rst:109 @@ -2532,11 +3576,25 @@ msgid "Spack" msgstr "" #: ../source/guides/installing-scientific-packages.rst:110 -msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." +msgid "" +"`Spack `_ is a flexible package manager " +"designed to support multiple versions, configurations, platforms, and " +"compilers. It was built to support the needs of large supercomputing centers " +"and scientific application teams, who must often build software many " +"different ways. Spack is not limited to Python; it can install packages for " +"``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-" +"destructive; installing a new version of one package does not break existing " +"installations, so many configurations can coexist on the same system." msgstr "" #: ../source/guides/installing-scientific-packages.rst:119 -msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." +msgid "" +"Spack offers a simple but powerful syntax that allows users to specify " +"versions and configuration options concisely. Package files are written in " +"pure Python, and they are templated so that it is easy to swap compilers, " +"dependency implementations (like MPI), versions, and build options with a " +"single package file. Spack also generates *module* files so that packages " +"can be loaded and unloaded from the user's environment." msgstr "" #: ../source/guides/installing-scientific-packages.rst:128 @@ -2544,11 +3602,29 @@ msgid "The conda cross-platform package manager" msgstr "" #: ../source/guides/installing-scientific-packages.rst:130 -msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." +msgid "" +"`Anaconda `_ is a Python distribution " +"published by Anaconda, Inc. It is a stable collection of Open Source " +"packages for big data and scientific use. As of the 5.0 release of " +"Anaconda, about 200 packages are installed by default, and a total of " +"400-500 can be installed and updated from the Anaconda repository." msgstr "" #: ../source/guides/installing-scientific-packages.rst:136 -msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." +msgid "" +"``conda`` is an open source (BSD licensed) package management system and " +"environment management system included in Anaconda that allows users to " +"install multiple versions of binary software packages and their " +"dependencies, and easily switch between them. It is a cross-platform tool " +"working on Windows, macOS, and Linux. Conda can be used to package up and " +"distribute all kinds of packages, it is not limited to just Python packages. " +"It has full support for native virtual environments. Conda makes " +"environments first-class citizens, making it easy to create independent " +"environments even for C libraries. It is written in Python, but is Python-" +"agnostic. Conda manages Python itself as a package, so that :command:`conda " +"update python` is possible, in contrast to pip, which only manages Python " +"packages. Conda is available in Anaconda and Miniconda (an easy-to-install " +"download with just Python and conda)." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:2 @@ -2556,15 +3632,28 @@ msgid "Installing stand alone command line tools" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:4 -msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." +msgid "" +"Many packages have command line entry points. Examples of this type of " +"application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:10 -msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." +msgid "" +"Usually you want to be able to access these from anywhere, but installing " +"packages and their dependencies to the same global environment can cause " +"version conflicts and break dependencies the operating system has on Python " +"packages." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:15 -msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." +msgid "" +":ref:`pipx` solves this by creating a virtual environment for each package, " +"while also ensuring that package's applications are accessible through a " +"directory that is on your ``$PATH``. This allows each package to be upgraded " +"or uninstalled without causing conflicts with other packages, and allows you " +"to safely run the program from anywhere." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:21 @@ -2576,11 +3665,14 @@ msgid "``pipx`` is installed with ``pip``:" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:30 -msgid "You may need to restart your terminal for the path updates to take effect." +msgid "" +"You may need to restart your terminal for the path updates to take effect." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:32 -msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." +msgid "" +"Now you can install packages with ``pipx install`` and access the package's " +"entry point(s) from anywhere." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:39 @@ -2589,7 +3681,9 @@ msgid "For example" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:59 -msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." +msgid "" +"To see a list of packages installed with pipx and which CLI applications are " +"available, use ``pipx list``." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:79 @@ -2601,7 +3695,9 @@ msgid "``pipx`` can be upgraded or uninstalled with pip" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:93 -msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." +msgid "" +"``pipx`` also allows you to install and run the latest version of a cli tool " +"in a temporary, ephemeral environment." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:106 @@ -2609,7 +3705,9 @@ msgid "To see the full list of commands ``pipx`` offers, run" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:112 -msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." +msgid "" +"You can learn more about ``pipx`` at its homepage, https://github.com/pypa/" +"pipx." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:5 @@ -2621,19 +3719,35 @@ msgid "2015-09-17" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:11 -msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." +msgid "" +"This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:" +"`wheel` using Linux package managers." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:14 -msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." +msgid "" +"If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:" +"`installing_requirements` section instead." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:18 -msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." +msgid "" +"Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, " +"and :ref:`wheel` supported by a specific Linux Distribution to be outdated " +"by the time it's released to the public, and updates generally only occur " +"for security reasons, not for feature updates. For certain Distributions, " +"there are additional repositories that can be enabled to provide newer " +"versions. The repositories we know about are explained below." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:25 -msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." +msgid "" +"Also note that it's somewhat common for Distributions to apply patches for " +"the sake of security and normalization to their own standards. In some " +"cases, this can lead to bugs or unexpected behaviors that vary from the " +"original unpatched versions. When this is known, we will make note of it " +"below." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:32 @@ -2665,7 +3779,11 @@ msgid "Python 3: ``sudo dnf install python3 python3-wheel``" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:53 -msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" +msgid "" +"To get newer versions of pip, setuptools, and wheel for Python 2, you can " +"enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:63 @@ -2673,7 +3791,9 @@ msgid "CentOS/RHEL" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:65 -msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." +msgid "" +"CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core " +"repositories, although :ref:`setuptools` is installed by default." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:68 @@ -2681,7 +3801,11 @@ msgid "To install pip and wheel for the system Python, there are two options:" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:70 -msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" +msgid "" +"Enable the `EPEL repository `_ using " +"`these instructions `__. On EPEL 6 and EPEL7, you can " +"install pip like so::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:77 @@ -2689,11 +3813,16 @@ msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:81 -msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." +msgid "" +"Since EPEL only offers extra, non-conflicting packages, EPEL does not offer " +"setuptools, since it's in the core repository." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:85 -msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" +msgid "" +"Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:92 @@ -2701,15 +3830,21 @@ msgid "To additionally upgrade setuptools, run::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:97 -msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" +msgid "" +"To install pip, wheel, and setuptools, in a parallel, non-system environment " +"(using yum) then there are two options:" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:101 -msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." +msgid "" +"Use the \"Software Collections\" feature to enable a parallel collection " +"that includes pip, setuptools, and wheel." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:104 -msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" +msgid "" +"For Redhat, see here: http://developers.redhat.com/products/" +"softwarecollections/overview/" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:106 @@ -2721,7 +3856,11 @@ msgid "Be aware that collections may not contain the most recent versions." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:110 -msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." +msgid "" +"Enable the `IUS repository `_ and install " +"one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which " +"are kept fairly up to date." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:116 @@ -2743,7 +3882,10 @@ msgid "Debian/Ubuntu" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:150 -msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." +msgid "" +"Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" " +"`_ by default, " +"which is a significant behavior change that can be surprising to some users." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:156 @@ -2751,7 +3893,9 @@ msgid "Arch Linux" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:168 -msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." +msgid "" +"Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the " +"only option is to manually place the repo files as described." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 @@ -2759,11 +3903,18 @@ msgid "Installing packages using pip and virtual environments" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 -msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." +msgid "" +"This guide discusses how to install packages using :ref:`pip` and a virtual " +"environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` " +"for Python 2. These are the lowest-level tools for managing Python packages " +"and are recommended if higher-level tools do not suit your needs." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 -msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." +msgid "" +"This doc uses the term **package** to refer to a :term:`Distribution " +"Package` which is different from an :term:`Import Package` that which is " +"used to import modules in your Python source code." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 @@ -2771,15 +3922,24 @@ msgid "Installing pip" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 -msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." +msgid "" +":ref:`pip` is the reference Python package manager. It's used to install and " +"update packages. You'll need to make sure you have the latest version of pip " +"installed." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 -msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." +msgid "" +"Debian and most other distributions include a `python-pip`_ package, if you " +"want to use the Linux distribution-provided versions of pip see :doc:`/" +"guides/installing-using-linux-tools`." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 -msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" +msgid "" +"You can also install pip yourself to ensure you have the latest version. " +"It's recommended to use the system pip to bootstrap a user installation of " +"pip:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 @@ -2787,7 +3947,9 @@ msgid "Afterwards, you should have the newest pip installed in your user site:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 -msgid "The Python installers for Windows include pip. You should be able to access pip using:" +msgid "" +"The Python installers for Windows include pip. You should be able to access " +"pip using:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 @@ -2799,11 +3961,19 @@ msgid "Installing virtualenv" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 -msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." +msgid "" +"If you are using Python 3.3 or newer, the :mod:`venv` module is the " +"preferred way to create and manage virtual environments. venv is included in " +"the Python standard library and requires no additional installation. If you " +"are using venv, you may skip this section." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 -msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." +msgid "" +":ref:`virtualenv` is used to manage Python packages for different projects. " +"Using virtualenv allows you to avoid installing Python packages globally " +"which could break system tools or other projects. You can install virtualenv " +"using pip." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 @@ -2811,15 +3981,28 @@ msgid "Creating a virtual environment" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 -msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." +msgid "" +":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to " +"manage separate package installations for different projects. They " +"essentially allow you to create a \"virtual\" isolated Python installation " +"and install packages into that virtual installation. When you switch " +"projects, you can simply create a new virtual environment and not have to " +"worry about breaking the packages installed in the other environments. It is " +"always recommended to use a virtual environment while developing Python " +"applications." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 -msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." +msgid "" +"To create a virtual environment, go to your project's directory and run " +"venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the " +"below commands." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 -msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." +msgid "" +"The second argument is the location to create the virtual environment. " +"Generally, you can just create this in your project and call it ``env``." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 @@ -2827,7 +4010,9 @@ msgid "venv will create a virtual Python installation in the ``env`` folder." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 -msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." +msgid "" +"You should exclude your virtual environment directory from your version " +"control system using ``.gitignore`` or similar." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 @@ -2835,15 +4020,24 @@ msgid "Activating a virtual environment" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 -msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." +msgid "" +"Before you can start installing or using packages in your virtual " +"environment you'll need to *activate* it. Activating a virtual environment " +"will put the virtual environment-specific ``python`` and ``pip`` executables " +"into your shell's ``PATH``." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 -msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." +msgid "" +"You can confirm you're in the virtual environment by checking the location " +"of your Python interpreter, it should point to the ``env`` directory." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 -msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." +msgid "" +"As long as your virtual environment is activated pip will install packages " +"into that specific environment and you'll be able to import and use packages " +"in your Python application." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 @@ -2851,11 +4045,16 @@ msgid "Leaving the virtual environment" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 -msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" +msgid "" +"If you want to switch projects or otherwise leave your virtual environment, " +"simply run:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 -msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." +msgid "" +"If you want to re-enter the virtual environment just follow the same " +"instructions above about activating a virtual environment. There's no need " +"to re-create the virtual environment." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 @@ -2863,11 +4062,14 @@ msgid "Installing packages" msgstr "安装软件包" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 -msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" +msgid "" +"Now that you're in your virtual environment you can install packages. Let's " +"install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 -msgid "pip should download requests and all of its dependencies and install them:" +msgid "" +"pip should download requests and all of its dependencies and install them:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 @@ -2875,7 +4077,10 @@ msgid "Installing specific versions" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 -msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" +msgid "" +"pip allows you to specify which version of a package to install using :term:" +"`version specifiers `. For example, to install a specific " +"version of ``requests``:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 @@ -2891,7 +4096,9 @@ msgid "Installing extras" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 -msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" +msgid "" +"Some packages have optional `extras`_. You can tell pip to install these by " +"specifying the extra in brackets:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 @@ -2903,7 +4110,10 @@ msgid "pip can install a package directly from source, for example:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 -msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" +msgid "" +"Additionally, pip can install packages from source in `development mode`_, " +"meaning that changes to the source directory will immediately affect the " +"installed package without needing to re-install:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 @@ -2911,11 +4121,15 @@ msgid "Installing from version control systems" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 -msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" +msgid "" +"pip can install packages directly from their version control system. For " +"example, you can install directly from a git repository:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 -msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." +msgid "" +"For more information on supported version control systems and syntax, see " +"pip's documentation on :ref:`VCS Support `." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 @@ -2924,15 +4138,23 @@ msgid "Installing from local archives" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 -msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" +msgid "" +"If you have a local copy of a :term:`Distribution Package`'s archive (a zip, " +"wheel, or tar file) you can install it directly with pip:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 -msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" +msgid "" +"If you have a directory containing archives of multiple packages, you can " +"tell pip to look for packages there and not to use the :term:`Python Package " +"Index (PyPI)` at all:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 -msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." +msgid "" +"This is useful if you are installing packages on a system with limited " +"connectivity or if you want to strictly control the origin of distribution " +"packages." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 @@ -2940,11 +4162,16 @@ msgid "Using other package indexes" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 -msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" +msgid "" +"If you want to download packages from a different index than the :term:" +"`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 -msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" +msgid "" +"If you want to allow packages from both the :term:`Python Package Index " +"(PyPI)` and a separate index, you can use the ``--extra-index-url`` flag " +"instead:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 @@ -2953,7 +4180,9 @@ msgid "Upgrading packages" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 -msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" +msgid "" +"pip can upgrade packages in-place using the ``--upgrade`` flag. For example, " +"to install the latest version of ``requests`` and all of its dependencies:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 @@ -2961,11 +4190,16 @@ msgid "Using requirements files" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 -msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" +msgid "" +"Instead of installing packages individually, pip allows you to declare all " +"dependencies in a :ref:`Requirements File `. For " +"example you could create a :file:`requirements.txt` file containing:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 -msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" +msgid "" +"And tell pip to install all of the packages in this file using the ``-r`` " +"flag:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 @@ -2973,7 +4207,9 @@ msgid "Freezing dependencies" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 -msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" +msgid "" +"Pip can export a list of all installed packages and their versions using the " +"``freeze`` command:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 @@ -2981,7 +4217,9 @@ msgid "Which will output a list of package specifiers such as:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 -msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." +msgid "" +"This is useful for creating :ref:`pip:Requirements Files` that can re-create " +"the exact versions of all packages installed in an environment." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:2 @@ -2989,7 +4227,11 @@ msgid "Making a PyPI-friendly README" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:4 -msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." +msgid "" +"README files can help your users understand your project and can be used to " +"set your project's description on PyPI. This guide helps you create a README " +"in a PyPI-friendly format and include your README in your package so it " +"appears on PyPI." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:9 @@ -2997,11 +4239,16 @@ msgid "Creating a README file" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:11 -msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." +msgid "" +"README files for Python projects are often named ``README``, ``README.txt``, " +"``README.rst``, or ``README.md``." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:13 -msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" +msgid "" +"For your README to display properly on PyPI, choose a markup language " +"supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:16 @@ -3009,15 +4256,21 @@ msgid "plain text" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:17 -msgid "`reStructuredText `_ (without Sphinx extensions)" +msgid "" +"`reStructuredText `_ (without " +"Sphinx extensions)" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:18 -msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" +msgid "" +"Markdown (`GitHub Flavored Markdown `_ by " +"default, or `CommonMark `_)" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:21 -msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." +msgid "" +"It's customary to save your README file in the root of your project, in the " +"same directory as your :file:`setup.py` file." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:25 @@ -3025,7 +4278,10 @@ msgid "Including your README in your package's metadata" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:27 -msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." +msgid "" +"To include your README's contents as your package description, set your " +"project's ``Description`` and ``Description-Content-Type`` metadata, " +"typically in your project's :file:`setup.py` file." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:33 @@ -3037,15 +4293,23 @@ msgid ":ref:`description-content-type-optional`" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:36 -msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." +msgid "" +"For example, to set these values in a package's :file:`setup.py` file, use " +"``setup()``'s ``long_description`` and ``long_description_content_type``." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:39 -msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." +msgid "" +"Set the value of ``long_description`` to the contents (not the path) of the " +"README file itself. Set the ``long_description_content_type`` to an accepted " +"``Content-Type``-style value for your README file's markup, such as ``text/" +"plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:45 -msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" +msgid "" +"If you're using GitHub-flavored Markdown to write a project's description, " +"ensure you upgrade the following tools:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:60 @@ -3065,11 +4329,16 @@ msgid "``twine >= 1.11.0``" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:66 -msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" +msgid "" +"It's recommended that you use ``twine`` to upload the project's distribution " +"packages:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:72 -msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" +msgid "" +"For example, see this :file:`setup.py` file, which reads the contents of :" +"file:`README.md` as ``long_description`` and identifies the markup as GitHub-" +"flavored Markdown:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:95 @@ -3077,23 +4346,36 @@ msgid "Validating reStructuredText markup" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:97 -msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." +msgid "" +"If your README is written in reStructuredText, any invalid markup will " +"prevent it from rendering, causing PyPI to instead just show the README's " +"raw source." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:100 -msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." +msgid "" +"Note that Sphinx extensions used in docstrings, such as `directives and " +"roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```" +"\"), are not allowed here and will result in error messages like \"``Error: " +"Unknown interpreted text role \"py:func\".``\"." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:105 -msgid "You can check your README for markup errors before uploading as follows:" +msgid "" +"You can check your README for markup errors before uploading as follows:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:107 -msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" +msgid "" +"Install the latest version of `twine `_; " +"version 1.12.0 or higher is required:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:122 -msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." +msgid "" +"Build the sdist and wheel for your project as described under :ref:" +"`Packaging Your Project`." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:125 @@ -3101,7 +4383,10 @@ msgid "Run ``twine check`` on the sdist and wheel::" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:129 -msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." +msgid "" +"This command will report any problems rendering your README. If your markup " +"renders fine, the command will output ``Checking distribution FILENAME: " +"Passed``." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:4 @@ -3109,7 +4394,11 @@ msgid "Migrating to PyPI.org" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:6 -msgid ":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``." +msgid "" +":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``." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:12 @@ -3121,15 +4410,21 @@ msgid "``pypi.org`` is the default upload platform as of September 2016." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:16 -msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." +msgid "" +"Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. " +"As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:19 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:22 -msgid "The default upload settings switched to ``pypi.org`` in the following versions:" +msgid "" +"The default upload settings switched to ``pypi.org`` in the following " +"versions:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:24 @@ -3157,19 +4452,32 @@ msgid "Python 3.6.0 (``distutils`` update)" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:31 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:48 -msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." +msgid "" +"Then simply delete the line starting with ``repository`` and you will use " +"your upload tool's default URL." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:51 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:67 -msgid "(``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.)" +msgid "" +"(``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.)" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:73 @@ -3177,15 +4485,22 @@ msgid "Registering package names & metadata" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:75 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:79 -msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" +msgid "" +"As a result, attempting explicit registration after switching to using PyPI." +"org for uploads will give the following error message::" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:84 -msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." +msgid "" +"The solution is to skip the registration step, and proceed directly to " +"uploading artifacts." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:89 @@ -3194,7 +4509,12 @@ msgid "Using TestPyPI" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:91 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:113 @@ -3202,7 +4522,10 @@ msgid "Registering new user accounts" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:115 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:121 @@ -3210,7 +4533,11 @@ msgid "Browsing packages" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:123 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:130 @@ -3226,7 +4553,9 @@ msgid "Managing published packages and releases" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:137 -msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." +msgid "" +"``pypi.org`` provides a fully functional interface for logged in users to " +"manage their published packages and releases." msgstr "" #: ../source/guides/multi-version-installs.rst:5 @@ -3234,23 +4563,51 @@ msgid "Multi-version installs" msgstr "" #: ../source/guides/multi-version-installs.rst:8 -msgid "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``)." +msgid "" +"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``)." msgstr "" #: ../source/guides/multi-version-installs.rst:13 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/multi-version-installs.rst:19 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/multi-version-installs.rst:31 -msgid "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 ``python -c ''`` to invoke the application's main entry point directly." +msgid "" +"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 ``python -c ''`` to invoke the application's main " +"entry point directly." msgstr "" #: ../source/guides/multi-version-installs.rst:38 -msgid "Refer to the `pkg_resources documentation `__ for more details." +msgid "" +"Refer to the `pkg_resources documentation `__ for more details." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:5 @@ -3262,7 +4619,12 @@ msgid "2013-12-08" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:10 -msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." +msgid "" +"One of the features of the CPython reference interpreter is that, in " +"addition to allowing the execution of Python code, it also exposes a rich C " +"API for use by other software. One of the most common uses of this C API is " +"to create importable C extensions that allow things which aren't always easy " +"to achieve in pure Python code." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:20 @@ -3274,27 +4636,66 @@ msgid "Use cases" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:25 -msgid "The typical use cases for binary extensions break down into just three conventional categories:" +msgid "" +"The typical use cases for binary extensions break down into just three " +"conventional categories:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:28 -msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." +msgid "" +"**accelerator modules**: these modules are completely self-contained, and " +"are created solely to run faster than the equivalent pure Python code runs " +"in CPython. Ideally, accelerator modules will always have a pure Python " +"equivalent to use as a fallback if the accelerated version isn't available " +"on a given system. The CPython standard library makes extensive use of " +"accelerator modules. *Example*: When importing ``datetime``, Python falls " +"back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not " +"available." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:39 -msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." +msgid "" +"**wrapper modules**: these modules are created to expose existing C " +"interfaces to Python code. They may either expose the underlying C interface " +"directly, or else expose a more \"Pythonic\" API that makes use of Python " +"language features to make the API easier to use. The CPython standard " +"library makes extensive use of wrapper modules. *Example*: `functools.py " +"`_ is a " +"Python module wrapper for `_functoolsmodule.c `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:47 -msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." +msgid "" +"**low-level system access**: these modules are created to access lower level " +"features of the CPython runtime, the operating system, or the underlying " +"hardware. Through platform specific code, extension modules may achieve " +"things that aren't possible in pure Python code. A number of CPython " +"standard library modules are written in C in order to access interpreter " +"internals that aren't exposed at the language level. *Example*: ``sys``, " +"which comes from `sysmodule.c `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:56 -msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." +msgid "" +"One particularly notable feature of C extensions is that, when they don't " +"need to call back into the interpreter runtime, they can release CPython's " +"global interpreter lock around long-running operations (regardless of " +"whether those operations are CPU or IO bound)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:61 -msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." +msgid "" +"Not all extension modules will fit neatly into the above categories. The " +"extension modules included with NumPy, for example, span all three use cases " +"- they move inner loops to C for speed reasons, wrap external libraries " +"written in C, FORTRAN and other languages, and use low level system " +"interfaces for both CPython and the underlying operation system to support " +"concurrent execution of vectorised operations and to tightly control the " +"exact memory layout of created objects." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:71 @@ -3302,7 +4703,13 @@ msgid "Disadvantages" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:73 -msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." +msgid "" +"The main disadvantage of using binary extensions is the fact that it makes " +"subsequent distribution of the software more difficult. One of the " +"advantages of using Python is that it is largely cross platform, and the " +"languages used to write extension modules (typically C or C++, but really " +"any language that can bind to the CPython C API) typically require that " +"custom binaries be created for different platforms." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:80 @@ -3310,27 +4717,44 @@ msgid "This means that binary extensions:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:82 -msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" +msgid "" +"require that end users be able to either build them from source, or else " +"that someone publish pre-built binaries for common platforms" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:85 -msgid "may not be compatible with different builds of the CPython reference interpreter" +msgid "" +"may not be compatible with different builds of the CPython reference " +"interpreter" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:88 -msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" +msgid "" +"often will not work correctly with alternative interpreters such as PyPy, " +"IronPython or Jython" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:91 -msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." +msgid "" +"if handcoded, make maintenance more difficult by requiring that maintainers " +"be familiar not only with Python, but also with the language used to create " +"the binary extension, as well as with the details of the CPython C API." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:96 -msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." +msgid "" +"if a pure Python fallback implementation is provided, make maintenance more " +"difficult by requiring that changes be implemented in two places, and " +"introducing additional complexity in the test suite to ensure both versions " +"are always executed." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:101 -msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." +msgid "" +"Another disadvantage of relying on binary extensions is that alternative " +"import mechanisms (such as the ability to import modules directly from " +"zipfiles) often won't work for extension modules (as the dynamic loading " +"mechanisms on most platforms can only load libraries from disk)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:108 @@ -3338,23 +4762,56 @@ msgid "Alternatives to handcoded accelerator modules" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:110 -msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" +msgid "" +"When extension modules are just being used to make code run faster (after " +"profiling has identified the code where the speed increase is worth " +"additional maintenance effort), a number of other alternatives should also " +"be considered:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:115 -msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." +msgid "" +"look for existing optimised alternatives. The CPython standard library " +"includes a number of optimised data structures and algorithms (especially in " +"the builtins and the ``collections`` and ``itertools`` modules). The Python " +"Package Index also offers additional alternatives. Sometimes, the " +"appropriate choice of standard library or third party module can avoid the " +"need to create your own accelerator module." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:122 -msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." +msgid "" +"for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython " +"runtime. The main barrier to adopting PyPy is typically reliance on other " +"binary extension modules - while PyPy does emulate the CPython C API, " +"modules that rely on that cause problems for the PyPy JIT, and the emulation " +"layer can often expose latent defects in extension modules that CPython " +"currently tolerates (frequently around reference counting errors - an object " +"having one live reference instead of two often won't break anything, but no " +"references instead of one is a major problem)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:132 -msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." +msgid "" +"`Cython `__ is a mature static compiler that can compile " +"most Python code to C extension modules. The initial compilation provides " +"some speed increases (by bypassing the CPython interpreter layer), and " +"Cython's optional static typing features can offer additional opportunities " +"for speed increases. Using Cython still has the disadvantage of increasing " +"the complexity of distributing the resulting application, but has the " +"benefit of having a reduced barrier to entry for Python programmers " +"(relative to other languages like C or C++)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:141 -msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." +msgid "" +"`Numba `__ is a newer tool, created by members of " +"the scientific Python community, that aims to leverage LLVM to allow " +"selective compilation of pieces of a Python application to native machine " +"code at runtime. It requires that LLVM be available on the system where the " +"code is running, but can provide significant speed increases, especially for " +"operations that are amenable to vectorisation." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:150 @@ -3362,35 +4819,74 @@ msgid "Alternatives to handcoded wrapper modules" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:152 -msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." +msgid "" +"The C ABI (Application Binary Interface) is a common standard for sharing " +"functionality between multiple applications. One of the strengths of the " +"CPython C API (Application Programming Interface) is allowing Python users " +"to tap into that functionality. However, wrapping modules by hand is quite " +"tedious, so a number of other alternative approaches should be considered." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:158 -msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." +msgid "" +"The approaches described below don't simplify the distribution case at all, " +"but they *can* significantly reduce the maintenance burden of keeping " +"wrapper modules up to date." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:162 -msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." +msgid "" +"In addition to being useful for the creation of accelerator modules, `Cython " +"`__ is also useful for creating wrapper modules for C or " +"C++. It still involves wrapping the interfaces by hand, however, and is very " +"repetitive, so may not be a good choice for wrapping large APIs." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:168 -msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." +msgid "" +"`pybind11 `__ is a pure C++11 library that " +"provides a clean C++ interface to the CPython (and PyPy) C API. It does not " +"require a pre-processing step; it is written entirely in templated C++. " +"Helpers are included for Setuptools or CMake builds. It was based on `Boost." +"Python `__, but doesn't require the Boost libraries or BJam." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:175 -msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." +msgid "" +"`cffi `__ is a project created by some of the " +"PyPy developers to make it straightforward for developers that already know " +"both Python and C to expose their C modules to Python applications. It also " +"makes it relatively straightforward to wrap a C module based on its header " +"files, even if you don't know C yourself." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:181 -msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." +msgid "" +"One of the key advantages of ``cffi`` is that it is compatible with the PyPy " +"JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing " +"JIT optimisations." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:185 -msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." +msgid "" +"`SWIG `__ is a wrapper interface generator that allows " +"a variety of programming languages, including Python, to interface with C " +"and C++ code." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:189 -msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." +msgid "" +"The standard library's ``ctypes`` module, while useful for getting access to " +"C level interfaces when header information isn't available, suffers from the " +"fact that it operates solely at the C ABI level, and thus has no automatic " +"consistency checking between the interface actually being exported by the " +"library and the one declared in the Python code. By contrast, the above " +"alternatives are all able to operate at the C *API* level, using C header " +"files to ensure consistency between the interface exported by the library " +"being wrapped and the one expected by the Python wrapper module. While " +"``cffi`` *can* operate directly at the C ABI level, it suffers from the same " +"interface inconsistency problems as ``ctypes`` when it is used that way." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:203 @@ -3398,11 +4894,24 @@ msgid "Alternatives for low level system access" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:205 -msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." +msgid "" +"For applications that need low level system access (regardless of the " +"reason), a binary extension module often *is* the best way to go about it. " +"This is particularly true for low level access to the CPython runtime " +"itself, since some operations (like releasing the Global Interpreter Lock) " +"are simply invalid when the interpreter is running code, even if a module " +"like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API " +"interfaces." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:213 -msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." +msgid "" +"For cases where the extension module is manipulating the underlying " +"operating system or hardware (rather than the CPython runtime), it may " +"sometimes be better to just write an ordinary C library (or a library in " +"another systems programming language like C++ or Rust that can export a C " +"compatible ABI), and then use one of the wrapping techniques described above " +"to make the interface available as an importable Python module." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:222 @@ -3410,7 +4919,10 @@ msgid "Implementing binary extensions" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:224 -msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." +msgid "" +"The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in " +"C `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:241 @@ -3422,7 +4934,14 @@ msgid "Building extensions for multiple platforms" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:246 -msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." +msgid "" +"If you plan to distribute your extension, you should provide :term:`wheels " +"` for all the platforms you intend to support. For most extensions, " +"this is at least one package per Python version times the number of OS and " +"architectures you support. These are usually built on continuous " +"integration (CI) systems. There are tools to help you build highly " +"redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:" +"`multibuild`." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:256 @@ -3430,15 +4949,27 @@ msgid "Binary extensions for Windows" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:258 -msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." +msgid "" +"Before it is possible to build a binary extension, it is necessary to ensure " +"that you have a suitable compiler available. On Windows, Visual C is used to " +"build the official CPython interpreter, and should be used to build " +"compatible binary extensions." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:263 -msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." +msgid "" +"Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio " +"2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older " +"versions of Visual Studio are no longer easily available from Microsoft, so " +"for versions of Python prior to 3.5, the compilers must be obtained " +"differently if you do not already have a copy of the relevant version of " +"Visual Studio." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:269 -msgid "To set up a build environment for binary extensions, the steps are as follows:" +msgid "" +"To set up a build environment for binary extensions, the steps are as " +"follows:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:271 @@ -3446,11 +4977,16 @@ msgid "For Python 2.7" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:273 -msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." +msgid "" +"Install \"Visual C++ Compiler Package for Python 2.7\", which is available " +"from `Microsoft's website `__." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:276 -msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." +msgid "" +"Use (a recent version of) setuptools in your setup.py (pip will do this for " +"you, in any case)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:278 @@ -3464,11 +5000,16 @@ msgid "For Python 3.4" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:282 -msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." +msgid "" +"Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is " +"available from `Microsoft's website `__." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:285 -msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." +msgid "" +"Work from an SDK command prompt (with the environment variables set, and the " +"SDK on PATH)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:287 @@ -3480,15 +5021,23 @@ msgid "For Python 3.5" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:292 -msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." +msgid "" +"Install `Visual Studio 2015 Community Edition `__ (or any later version, " +"when these are released)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:297 -msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." +msgid "" +"Note that from Python 3.5 onwards, Visual Studio works in a backward " +"compatible way, which means that any future version of Visual Studio will be " +"able to build Python extensions for all Python versions from 3.5 onwards." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:301 -msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." +msgid "" +"Building with the recommended compiler on Windows ensures that a compatible " +"C library is used throughout the Python process." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:305 @@ -3496,7 +5045,11 @@ msgid "Binary extensions for Linux" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:307 -msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." +msgid "" +"Linux binaries must use a sufficiently old glibc to be compatible with older " +"distributions. The `manylinux `_ Docker " +"images provide a build environment with a glibc old enough to support most " +"current Linux distributions on common architectures." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:313 @@ -3504,7 +5057,15 @@ msgid "Binary extensions for macOS" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:315 -msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." +msgid "" +"Binary compatibility on macOS is determined by the target minimum deployment " +"system, e.g. *10.9*, which is often specified with the " +"``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries " +"on macOS. When building with setuptools / distutils, the deployment target " +"is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For " +"common deployment targets for macOS Python distributions, see the `MacPython " +"Spinning Wheels wiki `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:325 @@ -3512,7 +5073,9 @@ msgid "Publishing binary extensions" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:327 -msgid "For interim guidance on this topic, see the discussion in `this issue `_." +msgid "" +"For interim guidance on this topic, see the discussion in `this issue " +"`_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:343 @@ -3520,7 +5083,13 @@ msgid "Additional resources" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:345 -msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." +msgid "" +"Cross-platform development and distribution of extension modules is a " +"complex topic, so this guide focuses primarily on providing pointers to " +"various tools that automate dealing with the underlying technical " +"challenges. The additional resources in this section are instead intended " +"for developers looking to understand more about the underlying binary " +"interfaces that those systems rely on at runtime." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:352 @@ -3528,7 +5097,13 @@ msgid "Cross-platform wheel generation with scikit-build" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:354 -msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." +msgid "" +"The `scikit-build `_ package " +"helps abstract cross-platform build operations and provides additional " +"capabilities when creating binary extension packages. Additional " +"documentation is also available on the `C runtime, compiler, and build " +"system generator `_ for Python binary extension modules." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:362 @@ -3536,11 +5111,15 @@ msgid "Introduction to C/C++ extension modules" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:364 -msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" +msgid "" +"For a more in depth explanation of how extension modules are used by CPython " +"on a Debian system, see the following articles:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:367 -msgid "`What are (c)python extension modules? `_" +msgid "" +"`What are (c)python extension modules? `_" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:368 @@ -3548,7 +5127,9 @@ msgid "`Releasing the gil `_" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:369 -msgid "`Writing cpython extension modules using C++ `_" +msgid "" +"`Writing cpython extension modules using C++ `_" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:3 @@ -3556,7 +5137,12 @@ msgid "Packaging namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:5 -msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" +msgid "" +"Namespace packages allow you to split the sub-packages and modules within a " +"single :term:`package ` across multiple, separate :term:" +"`distribution packages ` (referred to as " +"**distributions** in this document to avoid ambiguity). For example, if you " +"have the following package structure:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:24 @@ -3572,7 +5158,14 @@ msgid "Each sub-package can now be separately installed, used, and versioned." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:48 -msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." +msgid "" +"Namespace packages can be useful for a large collection of loosely-related " +"packages (such as a large corpus of client libraries for multiple products " +"from a single company). However, namespace packages come with several " +"caveats and are not appropriate in all cases. A simple alternative is to use " +"a prefix on all of your distributions such as ``import " +"mynamespace_subpackage_a`` (you could even use ``import " +"mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:58 @@ -3580,23 +5173,39 @@ msgid "Creating a namespace package" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:60 -msgid "There are currently three different approaches to creating namespace packages:" +msgid "" +"There are currently three different approaches to creating namespace " +"packages:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:62 -msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." +msgid "" +"Use `native namespace packages`_. This type of namespace package is defined " +"in :pep:`420` and is available in Python 3.3 and later. This is recommended " +"if packages in your namespace only ever need to support Python 3 and " +"installation via ``pip``." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:66 -msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." +msgid "" +"Use `pkgutil-style namespace packages`_. This is recommended for new " +"packages that need to support Python 2 and 3 and installation via both " +"``pip`` and ``python setup.py install``." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:69 -msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." +msgid "" +"Use `pkg_resources-style namespace packages`_. This method is recommended if " +"you need compatibility with packages already using this method or if your " +"package needs to be zip-safe." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:73 -msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." +msgid "" +"While native namespace packages and pkgutil-style namespace packages are " +"largely compatible, pkg_resources-style namespace packages are not " +"compatible with the other methods. It's inadvisable to use different methods " +"in different distributions that provide packages to the same namespace." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:80 @@ -3604,23 +5213,41 @@ msgid "Native namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:82 -msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" +msgid "" +"Python 3.3 added **implicit** namespace packages from :pep:`420`. All that " +"is required to create a native namespace package is that you just omit :file:" +"`__init__.py` from the namespace package directory. An example file " +"structure:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:97 -msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." +msgid "" +"It is extremely important that every distribution that uses the namespace " +"package omits the :file:`__init__.py` or uses a pkgutil-style :file:" +"`__init__.py`. If any distribution does not, it will cause the namespace " +"logic to fail and the other sub-packages will not be importable." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:102 -msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" +msgid "" +"Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:" +"`setuptools.find_packages` won't find the sub-package. You must use :func:" +"`setuptools.find_namespace_packages` instead or explicitly list all packages " +"in your :file:`setup.py`. For example:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:117 -msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." +msgid "" +"A complete working example of two native namespace packages can be found in " +"the `native namespace package example project`_." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:123 -msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." +msgid "" +"Because native and pkgutil-style namespace packages are largely compatible, " +"you can use native namespace packages in the distributions that only support " +"Python 3 and pkgutil-style namespace packages in the distributions that need " +"to support Python 2 and 3." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:129 @@ -3628,25 +5255,39 @@ msgid "pkgutil-style namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:131 -msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." +msgid "" +"Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. " +"This can be used to declare namespace packages that need to be compatible " +"with both Python 2.3+ and Python 3. This is the recommended approach for the " +"highest level of compatibility." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:136 -msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgid "" +"To create a pkgutil-style namespace package, you need to provide an :file:" +"`__init__.py` file for the namespace package:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:148 #: ../source/guides/packaging-namespace-packages.rst:194 -msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" +msgid "" +"The :file:`__init__.py` file for the namespace package needs to contain " +"**only** the following:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:155 #: ../source/guides/packaging-namespace-packages.rst:201 -msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." +msgid "" +"**Every** distribution that uses the namespace package must include an " +"identical :file:`__init__.py`. If any distribution does not, it will cause " +"the namespace logic to fail and the other sub-packages will not be " +"importable. Any additional code in :file:`__init__.py` will be inaccessible." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:160 -msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." +msgid "" +"A complete working example of two pkgutil-style namespace packages can be " +"found in the `pkgutil namespace example project`_." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:171 @@ -3654,39 +5295,68 @@ msgid "pkg_resources-style namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:173 -msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." +msgid "" +"`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and " +"the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together " +"these can be used to declare namespace packages. While this approach is no " +"longer recommended, it is widely present in most existing namespace " +"packages. If you are creating a new distribution within an existing " +"namespace package that uses this method then it's recommended to continue " +"using this as the different methods are not cross-compatible and it's not " +"advisable to try to migrate an existing package." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:182 -msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgid "" +"To create a pkg_resources-style namespace package, you need to provide an :" +"file:`__init__.py` file for the namespace package:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:206 -msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" +msgid "" +"Some older recommendations advise the following in the namespace package :" +"file:`__init__.py`:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:216 -msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." +msgid "" +"The idea behind this was that in the rare case that setuptools isn't " +"available packages would fall-back to the pkgutil-style packages. This isn't " +"advisable because pkgutil and pkg_resources-style namespace packages are not " +"cross-compatible. If the presence of setuptools is a concern then the " +"package should just explicitly depend on setuptools via ``install_requires``." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:223 -msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" +msgid "" +"Finally, every distribution must provide the ``namespace_packages`` argument " +"to :func:`~setuptools.setup` in :file:`setup.py`. For example:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:237 -msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." +msgid "" +"A complete working example of two pkg_resources-style namespace packages can " +"be found in the `pkg_resources namespace example project`_." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 -msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" +msgid "" +"Publishing package distribution releases using GitHub Actions CI/CD workflows" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 -msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." +msgid "" +"`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an " +"event occurs on the GitHub platform. One popular choice is having a workflow " +"that's triggered by a ``push`` event. This guide shows you how to publish a " +"Python distribution whenever a tagged commit is pushed. It will use the " +"`pypa/gh-action-pypi-publish GitHub Action`_." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 -msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." +msgid "" +"This guide *assumes* that you already have a project that you know how to " +"build distributions for and *it lives on GitHub*." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 @@ -3694,7 +5364,10 @@ msgid "Saving credentials on GitHub" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 -msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." +msgid "" +"In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, " +"meaning that we'll have two separate sets of credentials. And we'll need to " +"save them in the GitHub repository settings." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 @@ -3702,23 +5375,37 @@ msgid "Let's begin! 🚀" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" +msgid "" +"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " +"token`_. If you have the project on PyPI already, limit the token scope to " +"just that project. You can call it something like ``GitHub Actions CI/CD — " +"project-org/project-repo`` in order for it to be easily distinguishable in " +"the token list. **Don't close the page just yet — you won't see that token " +"again.**" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 -msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." +msgid "" +"In a separate browser tab or window, go to the ``Settings`` tab of your " +"target repository and then click on `Secrets`_ in the left sidebar." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 -msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." +msgid "" +"Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from " +"the first step." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 -msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." +msgid "" +"Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the " +"steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 -msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." +msgid "" +"If you don't have a TestPyPI account, you'll need to create it. It's not the " +"same as a regular PyPI account." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 @@ -3726,7 +5413,9 @@ msgid "Creating a workflow definition" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 -msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." +msgid "" +"GitHub CI/CD workflows are declared in YAML files stored in the ``.github/" +"workflows/`` directory of your repository." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 @@ -3734,7 +5423,9 @@ msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 -msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" +msgid "" +"Start it with a meaningful name and define the event that should make GitHub " +"run this workflow:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 @@ -3742,7 +5433,9 @@ msgid "Defining a workflow job environment" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 -msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" +msgid "" +"Now, let's add initial setup for our job. It's a process that will execute " +"commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 @@ -3754,15 +5447,22 @@ msgid "Then, add the following under the ``build-n-publish`` section:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 -msgid "This will download your repository into the CI runner and then install and activate Python 3.7." +msgid "" +"This will download your repository into the CI runner and then install and " +"activate Python 3.7." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 -msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." +msgid "" +"And now we can build dists from source. In this example, we'll use ``build`` " +"package, assuming that your project has a ``pyproject.toml`` properly set up " +"(see :pep:`517`/:pep:`518`)." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 -msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." +msgid "" +"You can use any other method for building distributions as long as it " +"produces ready-to-upload artifacts saved into the ``dist/`` folder." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 @@ -3778,7 +5478,11 @@ msgid "Finally, add the following steps at the end:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 -msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." +msgid "" +"These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the " +"first one uploads contents of the ``dist/`` folder into TestPyPI " +"unconditionally and the second does that to PyPI, but only if the current " +"commit is tagged." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 @@ -3786,7 +5490,11 @@ msgid "That's all, folks!" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 -msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" +msgid "" +"Now, whenever you push a tagged commit to your Git repository remote on " +"GitHub, this workflow will publish it to PyPI. And it'll publish any push to " +"TestPyPI which is useful for providing test builds to your alpha users as " +"well as making sure that your release pipeline remains healthy!" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:5 @@ -3794,87 +5502,143 @@ msgid "Single-sourcing the package version" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:8 -msgid "There are many techniques to maintain a single source of truth for the version number of your project:" +msgid "" +"There are many techniques to maintain a single source of truth for the " +"version number of your project:" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:11 -msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" +msgid "" +"Read the file in :file:`setup.py` and get the version. Example (from `pip " +"setup.py `_)::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:38 -msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" +msgid "" +"As of the release of setuptools 46.4.0, one can accomplish the same thing by " +"instead placing the following in the project's ``setup.cfg`` file (replacing " +"\"package\" with the import name of the package):" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:47 -msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." +msgid "" +"Earlier versions of setuptools implemented the ``attr:`` directive by " +"importing the module, but setuptools 46.4.0 added rudimentary AST analysis " +"so that ``attr:`` can function without having to import any of the package's " +"dependencies." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:52 -msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." +msgid "" +"Also, please be aware that declarative config indicators, including the " +"``attr:`` directive, are not supported in parameters to ``setup.py``." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:55 -msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." +msgid "" +"Use an external build tool that either manages updating both locations, or " +"offers an API that both locations can use." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:58 -msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." +msgid "" +"Few tools you could use, in no particular order, and not necessarily " +"complete: `bump2version `_, `changes " +"`_, `commitizen `_, `zest.releaser `_." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:65 -msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." +msgid "" +"Set the value to a ``__version__`` global variable in a dedicated module in " +"your project (e.g. :file:`version.py`), then have :file:`setup.py` read and " +"``exec`` the value into a variable." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:76 -msgid "Example using this technique: `warehouse `_." +msgid "" +"Example using this technique: `warehouse `_." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:78 -msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." +msgid "" +"Place the value in a simple ``VERSION`` text file and have both :file:`setup." +"py` and the project code read it." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:86 -msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." +msgid "" +"An advantage with this technique is that it's not specific to Python. Any " +"tool can read the version." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:91 -msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." +msgid "" +"With this approach you must make sure that the ``VERSION`` file is included " +"in all your source and binary distributions (e.g. add ``include VERSION`` to " +"your :file:`MANIFEST.in`)." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:95 -msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" +msgid "" +"Set the value in :file:`setup.py`, and have the project code use the " +"``importlib.metadata`` API to fetch the value at runtime. (``importlib." +"metadata`` was introduced in Python 3.8 and is available to older versions " +"as the ``importlib-metadata`` project.) An installed project's version can " +"be fetched with the API as follows::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:110 -msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." +msgid "" +"Be aware that the ``importlib.metadata`` API only knows about what's in the " +"installation metadata, which is not necessarily the code that's currently " +"imported." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:114 -msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" +msgid "" +"If a project uses this method to fetch its version at runtime, then its " +"``install_requires`` value needs to be edited to install ``importlib-" +"metadata`` on pre-3.8 versions of Python like so::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:128 -msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" +msgid "" +"An older (and less efficient) alternative to ``importlib.metadata`` is the " +"``pkg_resources`` API provided by ``setuptools``::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:134 -msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." +msgid "" +"If a project uses ``pkg_resources`` to fetch its own version at runtime, " +"then ``setuptools`` must be added to the project's ``install_requires`` list." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:138 -msgid "Example using this technique: `setuptools `_." +msgid "" +"Example using this technique: `setuptools `_." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:141 -msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." +msgid "" +"Set the value to ``__version__`` in ``sample/__init__.py`` and import " +"``sample`` in :file:`setup.py`." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:155 -msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." +msgid "" +"Although this technique is common, beware that it will fail if ``sample/" +"__init__.py`` imports packages from ``install_requires`` dependencies, which " +"will very likely not be installed yet when :file:`setup.py` is run." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:161 -msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." +msgid "" +"Keep the version number in the tags of a version control system (Git, " +"Mercurial, etc) instead of in the code, and automatically extract it from " +"there using `setuptools_scm `_." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:5 @@ -3882,11 +5646,20 @@ msgid "Supporting multiple Python versions" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:37 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:43 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:49 @@ -3894,31 +5667,52 @@ msgid "Automated testing and continuous integration" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:51 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:56 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:60 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:66 -msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." +msgid "" +"`Travis CI `_ provides both a Linux and a macOS " +"environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit " +"while the macOS is 10.9.2 at the time of writing." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:69 -msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." +msgid "" +"`Appveyor `_ provides a Windows environment " +"(Windows Server 2012)." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:80 -msgid "Both `Travis CI`_ 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." +msgid "" +"Both `Travis CI`_ 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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:85 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:89 @@ -3926,11 +5720,24 @@ msgid "Tools for single-source Python packages" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:91 -msgid "`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_." +msgid "" +"`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_." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:100 -msgid "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" +msgid "" +"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" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:107 @@ -3942,11 +5749,22 @@ msgid "a Python 3 (by syntax) module in a *Python 2* project." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:110 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:117 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:124 @@ -3954,7 +5772,13 @@ msgid "What's in which Python?" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:126 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:3 @@ -3966,19 +5790,37 @@ msgid "2015-12-03" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:8 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:20 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:24 -msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." +msgid "" +"The Appveyor service is a continuous integration service, much like the " +"better-known `Travis`_ service that is commonly used for testing by projects " +"hosted on `Github`_. However, unlike Travis, the build workers on Appveyor " +"are Windows hosts and have the necessary compilers installed to build Python " +"extensions." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:30 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:38 @@ -3986,15 +5828,25 @@ msgid "Setting up" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:40 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:45 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:49 -msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." +msgid "" +"Once you have set up your Appveyor account and added your project, Appveyor " +"will automatically build your project each time a commit occurs. This " +"behaviour will be familiar to users of Travis." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:54 @@ -4002,11 +5854,22 @@ msgid "Adding Appveyor support to your project" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:56 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:61 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:69 @@ -4014,39 +5877,74 @@ msgid "appveyor.yml" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:75 -msgid "This file can be downloaded from `here `__." +msgid "" +"This file can be downloaded from `here `__." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:77 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:80 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:88 -msgid "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``)." +msgid "" +"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``)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:94 -msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." +msgid "" +"The ``build`` section simply switches off builds - there is no build step " +"needed for Python, unlike languages like ``C#``." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:97 -msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." +msgid "" +"The main sections that will need to be tailored to your project are " +"``test_script`` and ``after_test``." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:100 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:109 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:114 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:119 @@ -4054,15 +5952,29 @@ msgid "Support script" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:121 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:126 -msgid "`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." +msgid "" +"`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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:133 -msgid "You can simply download the batch file and include it in your project unchanged." +msgid "" +"You can simply download the batch file and include it in your project " +"unchanged." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:137 @@ -4070,7 +5982,14 @@ msgid "Access to the built wheels" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:139 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:147 @@ -4082,19 +6001,33 @@ msgid "Testing with tox" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:152 -msgid "Many projects use the `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." +msgid "" +"Many projects use the `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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:156 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:160 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:165 -msgid "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" +msgid "" +"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" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:170 @@ -4114,23 +6047,46 @@ msgid "``LIB``" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:175 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:181 -msgid "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 Travis or 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)." +msgid "" +"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 Travis or 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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:188 -msgid "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``." +msgid "" +"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``." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:192 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:197 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:203 @@ -4138,11 +6094,19 @@ msgid "Automatically uploading wheels" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:205 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:210 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:216 @@ -4150,11 +6114,19 @@ msgid "External dependencies" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:218 -msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." +msgid "" +"The supplied scripts will successfully build any distribution that does not " +"rely on 3rd party external libraries for the build." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:221 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:230 @@ -4174,7 +6146,9 @@ msgid "Tool recommendations" msgstr "" #: ../source/guides/tool-recommendations.rst:7 -msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." +msgid "" +"If you're familiar with Python packaging and installation, and just want to " +"know what tools are currently recommended, then here it is." msgstr "" #: ../source/guides/tool-recommendations.rst:12 @@ -4182,7 +6156,10 @@ msgid "Application dependency management" msgstr "" #: ../source/guides/tool-recommendations.rst:14 -msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." +msgid "" +"Use :ref:`pipenv` to manage library dependencies when developing Python " +"applications. See :doc:`../tutorials/managing-dependencies` for more details " +"on using ``pipenv``." msgstr "" #: ../source/guides/tool-recommendations.rst:18 @@ -4206,15 +6183,23 @@ msgid "Installation tool recommendations" msgstr "" #: ../source/guides/tool-recommendations.rst:29 -msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" +msgid "" +"Use :ref:`pip` to install Python :term:`packages ` " +"from :term:`PyPI `. [1]_ [2]_ Depending on how :" +"ref:`pip` is installed, you may need to also install :ref:`wheel` to get the " +"benefit of wheel caching. [3]_" msgstr "" #: ../source/guides/tool-recommendations.rst:34 -msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" +msgid "" +"Use :ref:`virtualenv`, or `venv`_ to isolate application specific " +"dependencies from a shared Python installation. [4]_" msgstr "" #: ../source/guides/tool-recommendations.rst:37 -msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" +msgid "" +"If you're looking for management of fully integrated cross-platform software " +"stacks, consider:" msgstr "" #: ../source/guides/tool-recommendations.rst:40 @@ -4222,7 +6207,9 @@ msgid ":ref:`buildout`: primarily focused on the web development community" msgstr "" #: ../source/guides/tool-recommendations.rst:42 -msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." +msgid "" +":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the " +"scientific community." msgstr "" #: ../source/guides/tool-recommendations.rst:47 @@ -4230,15 +6217,22 @@ msgid "Packaging tool recommendations" msgstr "" #: ../source/guides/tool-recommendations.rst:49 -msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" +msgid "" +"Use :ref:`setuptools` to define projects and create :term:`Source " +"Distributions `. [5]_ [6]_" msgstr "" #: ../source/guides/tool-recommendations.rst:52 -msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." +msgid "" +"Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:" +"`wheel project ` to create :term:`wheels `. This is " +"especially beneficial, if your project contains binary extensions." msgstr "" #: ../source/guides/tool-recommendations.rst:56 -msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." +msgid "" +"Use `twine `_ for uploading distributions " +"to :term:`PyPI `." msgstr "" #: ../source/guides/tool-recommendations.rst:61 @@ -4246,39 +6240,75 @@ msgid "Publishing platform migration" msgstr "" #: ../source/guides/tool-recommendations.rst:63 -msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." +msgid "" +"The original Python Package Index implementation (previously hosted at `pypi." +"python.org `_) has been phased out in favour of an " +"updated implementation hosted at `pypi.org `_." msgstr "" #: ../source/guides/tool-recommendations.rst:67 -msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." +msgid "" +"See :ref:`Migrating to PyPI.org` for more information on the status of the " +"migration, and what settings to change in your clients." msgstr "" #: ../source/guides/tool-recommendations.rst:72 -msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." +msgid "" +"There are some cases where you might choose to use ``easy_install`` (from :" +"ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` " +"(which pip doesn't support). For a detailed breakdown, see :ref:`pip vs " +"easy_install`." msgstr "" #: ../source/guides/tool-recommendations.rst:77 -msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." +msgid "" +"The acceptance of :pep:`453` means that :ref:`pip` will be available by " +"default in most installations of Python 3.4 or later. See the :pep:" +"`rationale section <453#rationale>` from :pep:`453` as for why pip was " +"chosen." msgstr "" #: ../source/guides/tool-recommendations.rst:82 -msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." +msgid "" +"`get-pip.py `_ and :ref:" +"`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv " +"` do not currently. Also, the common \"python-pip\" package that's " +"found in various linux distros, does not depend on \"python-wheel\" " +"currently." msgstr "" #: ../source/guides/tool-recommendations.rst:88 -msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." +msgid "" +"Beginning with Python 3.4, ``venv`` will create virtualenv environments with " +"``pip`` installed, thereby making it an equal alternative to :ref:" +"`virtualenv`. However, using :ref:`virtualenv` will still be recommended for " +"users that need cross-version consistency." msgstr "" #: ../source/guides/tool-recommendations.rst:93 -msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." +msgid "" +"Although you can use pure ``distutils`` for many projects, it does not " +"support defining dependencies on other projects and is missing several " +"convenience utilities for automatically populating distribution metadata " +"correctly that are provided by ``setuptools``. Being outside the standard " +"library, ``setuptools`` also offers a more consistent feature set across " +"different versions of Python, and (unlike ``distutils``), recent versions of " +"``setuptools`` support all of the modern metadata fields described in :ref:" +"`core-metadata`." msgstr "" #: ../source/guides/tool-recommendations.rst:102 -msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." +msgid "" +"Even for projects that do choose to use ``distutils``, when :ref:`pip` " +"installs such projects directly from source (rather than installing from a " +"prebuilt :term:`wheel ` file), it will actually build your project " +"using :ref:`setuptools` instead." msgstr "" #: ../source/guides/tool-recommendations.rst:107 -msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." +msgid "" +"`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` " +"in June 2013, thereby making setuptools the default choice for packaging." msgstr "" #: ../source/guides/using-manifest-in.rst:5 @@ -4286,11 +6316,23 @@ msgid "Including files in source distributions with ``MANIFEST.in``" msgstr "" #: ../source/guides/using-manifest-in.rst:7 -msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." +msgid "" +"When building a :term:`source distribution ` for your package, by default only a minimal set of files are " +"included. You may find yourself wanting to include extra files in the " +"source distribution, such as an authors/contributors file, a :file:`docs/` " +"directory, or a directory of data files used for testing purposes. There " +"may even be extra files that you *need* to include; for example, if your :" +"file:`setup.py` computes your project's ``long_description`` by reading from " +"both a README and a changelog file, you'll need to include both those files " +"in the sdist so that people that build or install from the sdist get the " +"correct results." msgstr "" #: ../source/guides/using-manifest-in.rst:17 -msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." +msgid "" +"Adding & removing files to & from the source distribution is done by writing " +"a :file:`MANIFEST.in` file at the project root." msgstr "" #: ../source/guides/using-manifest-in.rst:22 @@ -4302,11 +6344,15 @@ msgid "The following files are included in a source distribution by default:" msgstr "" #: ../source/guides/using-manifest-in.rst:26 -msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" +msgid "" +"all Python source files implied by the ``py_modules`` and ``packages`` " +"``setup()`` arguments" msgstr "" #: ../source/guides/using-manifest-in.rst:28 -msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" +msgid "" +"all C source files mentioned in the ``ext_modules`` or ``libraries`` " +"``setup()`` arguments" msgstr "" #: ../source/guides/using-manifest-in.rst:30 @@ -4314,15 +6360,21 @@ msgid "scripts specified by the ``scripts`` ``setup()`` argument" msgstr "" #: ../source/guides/using-manifest-in.rst:31 -msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" +msgid "" +"all files specified by the ``package_data`` and ``data_files`` ``setup()`` " +"arguments" msgstr "" #: ../source/guides/using-manifest-in.rst:33 -msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" +msgid "" +"the file specified by the ``license_file`` option in :file:`setup.cfg` " +"(setuptools 40.8.0+)" msgstr "" #: ../source/guides/using-manifest-in.rst:35 -msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" +msgid "" +"all files specified by the ``license_files`` option in :file:`setup.cfg` " +"(setuptools 42.0.0+)" msgstr "" #: ../source/guides/using-manifest-in.rst:37 @@ -4362,11 +6414,20 @@ msgid ":file:`MANIFEST.in`" msgstr "" #: ../source/guides/using-manifest-in.rst:47 -msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." +msgid "" +"After adding the above files to the sdist, the commands in :file:`MANIFEST." +"in` (if such a file exists) are executed in order to add and remove further " +"files to & from the sdist. Default files can even be removed from the sdist " +"with the appropriate :file:`MANIFEST.in` command." msgstr "" #: ../source/guides/using-manifest-in.rst:52 -msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." +msgid "" +"After processing the :file:`MANIFEST.in` file, setuptools removes the :file:" +"`build/` directory as well as any directories named :file:`RCS`, :file:" +"`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file " +"and an :file:`*.egg-info` directory. This behavior cannot be changed with :" +"file:`MANIFEST.in`." msgstr "" #: ../source/guides/using-manifest-in.rst:60 @@ -4374,7 +6435,10 @@ msgid ":file:`MANIFEST.in` commands" msgstr "" #: ../source/guides/using-manifest-in.rst:62 -msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" +msgid "" +"A :file:`MANIFEST.in` file consists of commands, one per line, instructing " +"setuptools to add or remove some set of files from the sdist. The commands " +"are:" msgstr "" #: ../source/guides/using-manifest-in.rst:67 @@ -4402,7 +6466,9 @@ msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" msgstr "" #: ../source/guides/using-manifest-in.rst:71 -msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgid "" +"Add all files under directories matching ``dir-pattern`` that match any of " +"the listed patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:72 @@ -4410,7 +6476,9 @@ msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" msgstr "" #: ../source/guides/using-manifest-in.rst:72 -msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgid "" +"Remove all files under directories matching ``dir-pattern`` that match any " +"of the listed patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:73 @@ -4418,7 +6486,8 @@ msgid ":samp:`global-include {pat1} {pat2} ...`" msgstr "" #: ../source/guides/using-manifest-in.rst:73 -msgid "Add all files anywhere in the source tree matching any of the listed patterns" +msgid "" +"Add all files anywhere in the source tree matching any of the listed patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:74 @@ -4426,7 +6495,9 @@ msgid ":samp:`global-exclude {pat1} {pat2} ...`" msgstr "" #: ../source/guides/using-manifest-in.rst:74 -msgid "Remove all files anywhere in the source tree matching any of the listed patterns" +msgid "" +"Remove all files anywhere in the source tree matching any of the listed " +"patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:75 @@ -4446,27 +6517,54 @@ msgid "Remove all files under directories matching ``dir-pattern``" msgstr "" #: ../source/guides/using-manifest-in.rst:79 -msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." +msgid "" +"The patterns here are glob-style patterns: ``*`` matches zero or more " +"regular filename characters (on Unix, everything except forward slash; on " +"Windows, everything except backslash and colon); ``?`` matches a single " +"regular filename character, and ``[chars]`` matches any one of the " +"characters between the square brackets (which may contain character ranges, " +"e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented " +"support for ``**`` matching zero or more characters including forward slash, " +"backslash, and colon." msgstr "" #: ../source/guides/using-manifest-in.rst:87 -msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." +msgid "" +"Directory patterns are relative to the root of the project directory; e.g., " +"``graft example*`` will include a directory named :file:`examples` in the " +"project root but will not include :file:`docs/examples/`." msgstr "" #: ../source/guides/using-manifest-in.rst:91 -msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." +msgid "" +"File & directory names in :file:`MANIFEST.in` should be ``/``-separated; " +"setuptools will automatically convert the slashes to the local platform's " +"appropriate directory separator." msgstr "" #: ../source/guides/using-manifest-in.rst:95 -msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" +msgid "" +"Commands are processed in the order they appear in the :file:`MANIFEST.in` " +"file. For example, given the commands::" msgstr "" #: ../source/guides/using-manifest-in.rst:101 -msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." +msgid "" +"the contents of the directory tree :file:`tests` will first be added to the " +"sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, " +"or ``.pyd`` extension will be removed from the sdist. If the commands were " +"in the opposite order, then ``*.pyc`` files etc. would be only be removed " +"from what was already in the sdist before adding :file:`tests`, and if :file:" +"`tests` happened to contain any ``*.pyc`` files, they would end up included " +"in the sdist because the exclusion happened before they were included." msgstr "" #: ../source/guides/using-testpypi.rst:7 -msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" +msgid "" +"``TestPyPI`` is a separate instance of the :term:`Python Package Index " +"(PyPI)` that allows you to try out the distribution tools and process " +"without worrying about affecting the real index. TestPyPI is hosted at `test." +"pypi.org `_" msgstr "" #: ../source/guides/using-testpypi.rst:13 @@ -4474,11 +6572,16 @@ msgid "Registering your account" msgstr "注册您的帐户" #: ../source/guides/using-testpypi.rst:15 -msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." +msgid "" +"Because TestPyPI has a separate database from the live PyPI, you'll need a " +"separate user account for specifically for TestPyPI. Go to https://test.pypi." +"org/account/register/ to register your account." msgstr "" #: ../source/guides/using-testpypi.rst:19 -msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." +msgid "" +"The database for TestPyPI may be periodically pruned, so it is not unusual " +"for user accounts to be deleted." msgstr "" #: ../source/guides/using-testpypi.rst:24 @@ -4486,11 +6589,17 @@ msgid "Using TestPyPI with Twine" msgstr "" #: ../source/guides/using-testpypi.rst:26 -msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" +msgid "" +"You can upload your distributions to TestPyPI using :ref:`twine` by " +"specifying the ``--repository`` flag" msgstr "" #: ../source/guides/using-testpypi.rst:33 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgid "" +"You can see if your package has successfully uploaded by navigating to the " +"URL ``https://test.pypi.org/project/`` where " +"``sampleproject`` is the name of your project that you uploaded. It may take " +"a minute or two for your project to appear on the site." msgstr "" #: ../source/guides/using-testpypi.rst:39 @@ -4498,11 +6607,16 @@ msgid "Using TestPyPI with pip" msgstr "" #: ../source/guides/using-testpypi.rst:41 -msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" +msgid "" +"You can tell pip to download packages from TestPyPI instead of PyPI by " +"specifying the ``--index-url`` flag" msgstr "" #: ../source/guides/using-testpypi.rst:56 -msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" +msgid "" +"If you want to allow pip to also pull other packages from PyPI you can " +"specify ``--extra-index-url`` to point to PyPI. This is useful when the " +"package you're testing has dependencies:" msgstr "" #: ../source/guides/using-testpypi.rst:73 @@ -4510,16 +6624,19 @@ msgid "Setting up TestPyPI in :file:`.pypirc`" msgstr "在 :file:`.pypirc` 中设置 TestPyPI" #: ../source/guides/using-testpypi.rst:75 -msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" +msgid "" +"If you want to avoid entering your username, you can configure TestPyPI in " +"your :file:`$HOME/.pypirc`:" msgstr "" -#: ../source/index.rst:3 -#: ../source/key_projects.rst:181 +#: ../source/index.rst:3 ../source/key_projects.rst:181 msgid "Python Packaging User Guide" msgstr "Python 包装用户指南" #: ../source/index.rst:5 -msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." +msgid "" +"The Python Packaging User Guide (PyPUG) is a collection of tutorials and " +"guides for packaging Python software." msgstr "Python 打包用户指南 (PyPUG) 是一个打包 Python 软件的教程和指南的集合。" #: ../source/index.rst:5 @@ -4527,61 +6644,93 @@ msgid "python, packaging, guide, tutorial" msgstr "python, 包装, 指南, 教程" #: ../source/index.rst:24 -msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." +msgid "" +"Welcome to the *Python Packaging User Guide*, a collection of tutorials and " +"references to help you distribute and install Python packages with modern " +"tools." msgstr "" #: ../source/index.rst:28 -msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" +msgid "" +"This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. " +"We happily accept any :doc:`contributions and feedback `. 😊" msgstr "" -"本指南由 `Python Packaging Authority ` 在 `GitHub`_ 上维护。我们很乐意接受任何 :doc:`贡献和反馈 " -"`。 😊" +"本指南由 `Python Packaging Authority ` 在 `GitHub`_ 上维护。我们很乐意接受任" +"何 :doc:`贡献和反馈 `。 😊" #: ../source/index.rst:36 msgid "Get started" msgstr "开始" #: ../source/index.rst:38 -msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" +msgid "" +"Essential tools and concepts for working within the Python development " +"ecosystem are covered in our :doc:`tutorials/index` section:" msgstr "" #: ../source/index.rst:41 -msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" -msgstr "要学习如何安装软件包，请参阅 :doc:`安装软件包的教程 `" +msgid "" +"To learn how to install packages, see the :doc:`tutorial on installing " +"packages `" +msgstr "" +"要学习如何安装软件包，请参阅 :doc:`安装软件包的教程 `" #: ../source/index.rst:43 -msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" +msgid "" +"To learn how to manage dependencies in a version controlled project, see " +"the :doc:`tutorial on managing application dependencies `" msgstr "" #: ../source/index.rst:45 -msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" -msgstr "要学习如何打包和发布您的项目，请参阅 :doc:`关于打包和发布的教程 `" +msgid "" +"To learn how to package and distribute your projects, see the :doc:`tutorial " +"on packaging and distributing `" +msgstr "" +"要学习如何打包和发布您的项目，请参阅 :doc:`关于打包和发布的教程 `" #: ../source/index.rst:47 -msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" -msgstr "要获得对 Python 库和应用程序打包选项的概述，请参阅 :doc:`Python 打包概述 `" +msgid "" +"To get an overview of packaging options for Python libraries and " +"applications, see the :doc:`Overview of Python Packaging `" +msgstr "" +"要获得对 Python 库和应用程序打包选项的概述，请参阅 :doc:`Python 打包概述 " +"`" #: ../source/index.rst:52 msgid "Learn more" msgstr "了解更多" #: ../source/index.rst:54 -msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" +msgid "" +"Beyond our :doc:`tutorials/index`, this guide has several other resources:" msgstr "" #: ../source/index.rst:56 -msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." +msgid "" +"The :doc:`guides/index` section for walk throughs, such as :doc:`guides/" +"installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." msgstr "" #: ../source/index.rst:58 -msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." +msgid "" +"The :doc:`discussions/index` section for in-depth references on topics such " +"as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-" +"vs-easy-install`." msgstr "" #: ../source/index.rst:60 -msgid "The :doc:`specifications/index` section for packaging interoperability specifications." +msgid "" +"The :doc:`specifications/index` section for packaging interoperability " +"specifications." msgstr "" #: ../source/index.rst:62 -msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." +msgid "" +"Additionally, there is a list of :doc:`other projects ` " +"maintained by members of the Python Packaging Authority." msgstr "" #: ../source/key_projects.rst:6 @@ -4589,7 +6738,9 @@ msgid "Project Summaries" msgstr "项目摘要" #: ../source/key_projects.rst:8 -msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." +msgid "" +"Summaries and links for the most relevant projects in the space of Python " +"installation and packaging." msgstr "" #: ../source/key_projects.rst:14 @@ -4601,11 +6752,18 @@ msgid "bandersnatch" msgstr "" #: ../source/key_projects.rst:21 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:25 -msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." +msgid "" +"``bandersnatch`` is a PyPI mirroring client designed to efficiently create a " +"complete mirror of the contents of PyPI. Organizations thus save bandwidth " +"and latency on package downloads (especially in the context of automated " +"tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." msgstr "" #: ../source/key_projects.rst:35 @@ -4613,11 +6771,16 @@ msgid "build" msgstr "建造" #: ../source/key_projects.rst:37 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI " +"`__" msgstr "" #: ../source/key_projects.rst:42 -msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." +msgid "" +"``build`` is a :pep:`517` compatible Python package builder. It provides a " +"CLI to build packages, as well as a Python API." msgstr "" #: ../source/key_projects.rst:49 @@ -4625,11 +6788,19 @@ msgid "cibuildwheel" msgstr "" #: ../source/key_projects.rst:51 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | " +"`Discussions `__ | " +"`Discord #cibuildwheel `__" msgstr "" #: ../source/key_projects.rst:58 -msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." +msgid "" +"``cibuildwheel`` is a Python package that builds :term:`wheels ` for " +"all common platforms and Python versions on most CI systems. Also see :ref:" +"`multibuild`." msgstr "" #: ../source/key_projects.rst:64 @@ -4637,15 +6808,31 @@ msgid "distlib" msgstr "" #: ../source/key_projects.rst:66 -msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:71 -msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." +msgid "" +"``distlib`` is a library which implements low-level functions that relate to " +"packaging and distribution of Python software. ``distlib`` implements " +"several relevant PEPs (Python Enhancement Proposal standards) and is useful " +"for developers of third-party packaging tools to make and upload binary and " +"source :term:`distributions `, achieve " +"interoperability, resolve dependencies, manage package resources, and do " +"other similar functions." msgstr "" #: ../source/key_projects.rst:80 -msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." +msgid "" +"Unlike the stricter :ref:`packaging` project (below), which specifically " +"implements modern Python packaging interoperability standards, ``distlib`` " +"also attempts to provide reasonable fallback behaviours when asked to handle " +"legacy packages and metadata that predate the modern interoperability " +"standards and fall into the subset of packages that are incompatible with " +"those standards." msgstr "" #: ../source/key_projects.rst:90 @@ -4653,19 +6840,36 @@ msgid "packaging" msgstr "" #: ../source/key_projects.rst:92 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:97 -msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." +msgid "" +"Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." msgstr "" #: ../source/key_projects.rst:99 -msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." +msgid "" +"The core utilities in the packaging library handle version handling, " +"specifiers, markers, requirements, tags, and similar attributes and tasks " +"for Python packages. Most Python users rely on this library without needing " +"to explicitly call it; developers of the other Python packaging, " +"distribution, and installation tools listed here often use its functionality " +"to parse, discover, and otherwise handle dependency attributes." msgstr "" #: ../source/key_projects.rst:107 -msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." +msgid "" +"This project specifically focuses on implementing the modern Python " +"packaging interoperability standards defined at :ref:`packaging-" +"specifications`, and will report errors for sufficiently old legacy packages " +"that are incompatible with those standards. In contrast, the :ref:`distlib` " +"project is a more permissive library that attempts to provide a plausible " +"reading of ambiguous metadata in cases where :ref:`packaging` will instead " +"report on error." msgstr "" #: ../source/key_projects.rst:119 @@ -4674,15 +6878,24 @@ msgid "pip" msgstr "" #: ../source/key_projects.rst:121 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:126 -msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." +msgid "" +"The most popular tool for installing Python packages, and the one included " +"with modern versions of Python." msgstr "" #: ../source/key_projects.rst:129 -msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." +msgid "" +"It provides the essential core features for finding, downloading, and " +"installing packages from PyPI and other Python package indexes, and can be " +"incorporated into a wide range of development workflows via its command-line " +"interface (CLI)." msgstr "" #: ../source/key_projects.rst:137 @@ -4690,15 +6903,28 @@ msgid "Pipenv" msgstr "" #: ../source/key_projects.rst:139 -msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Source `__ | `Issues `__ | `PyPI " +"`__" msgstr "" #: ../source/key_projects.rst:144 -msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." +msgid "" +"Pipenv is a project that aims to bring the best of all packaging worlds to " +"the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:" +"`virtualenv` into one single toolchain. It features very pretty terminal " +"colors." msgstr "" #: ../source/key_projects.rst:148 -msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." +msgid "" +"Pipenv aims to help users manage environments, dependencies, and imported " +"packages on the command line. It also works well on Windows (which other " +"tools often underserve), makes and checkes file hashes, to ensure compliance " +"with hash-locked dependency specifiers, and eases uninstallation of packages " +"and dependencies. It is used by Python users and system administrators, but " +"has been less maintained since late 2018." msgstr "" #: ../source/key_projects.rst:159 @@ -4710,7 +6936,10 @@ msgid "`Source `__" msgstr "" #: ../source/key_projects.rst:163 -msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." +msgid "" +":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level " +"application-centric alternative to :ref:`pip`'s lower-level :file:" +"`requirements.txt` file." msgstr "" #: ../source/key_projects.rst:170 @@ -4718,15 +6947,22 @@ msgid "pipx" msgstr "" #: ../source/key_projects.rst:172 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:176 -msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." +msgid "" +"pipx is a tool to install and run Python command-line applications without " +"causing dependency conflicts with other packages installed on the system." msgstr "" #: ../source/key_projects.rst:183 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:187 @@ -4738,11 +6974,18 @@ msgid "readme_renderer" msgstr "" #: ../source/key_projects.rst:194 -msgid "`GitHub and docs `__ | `PyPI `__" +msgid "" +"`GitHub and docs `__ | `PyPI " +"`__" msgstr "" #: ../source/key_projects.rst:197 -msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." +msgid "" +"``readme_renderer`` is a library that package developers use to render their " +"user documentation (README) files into HTML from markup languages such as " +"Markdown or reStructuredText. Developers call it on its own or via :ref:" +"`twine`, as part of their release management process, to check that their " +"package descriptions will properly display on PyPI." msgstr "" #: ../source/key_projects.rst:208 @@ -4750,15 +6993,24 @@ msgid "setuptools" msgstr "" #: ../source/key_projects.rst:210 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:215 -msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." +msgid "" +"setuptools (which includes ``easy_install``) is a collection of enhancements " +"to the Python distutils that allow you to more easily build and distribute " +"Python :term:`distributions `, especially ones that " +"have dependencies on other packages." msgstr "" #: ../source/key_projects.rst:220 -msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." +msgid "" +"`distribute`_ was a fork of setuptools that was merged back into setuptools " +"(in v0.7), thereby making setuptools the primary choice for Python packaging." msgstr "" #: ../source/key_projects.rst:227 @@ -4766,15 +7018,32 @@ msgid "trove-classifiers" msgstr "" #: ../source/key_projects.rst:229 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Issues `__ | `GitHub " +"`__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:233 -msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." +msgid "" +"trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically " +"describe their projects `_ so that users can better find projects " +"that match their needs on the PyPI." msgstr "" #: ../source/key_projects.rst:239 -msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." +msgid "" +"The trove-classifiers package contains a list of valid classifiers and " +"deprecated classifiers (which are paired with the classifiers that replace " +"them). Use this package to validate classifiers used in packages intended " +"for uploading to PyPI. As this list of classifiers is published as code, you " +"can install and import it, giving you a more convenient workflow compared to " +"referring to the `list published on PyPI `_. " +"The `issue tracker `_ for " +"the project hosts discussions on proposed classifiers and requests for new " +"classifiers." msgstr "" #: ../source/key_projects.rst:253 @@ -4782,24 +7051,41 @@ msgid "twine" msgstr "" #: ../source/key_projects.rst:255 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:260 -msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." +msgid "" +"Twine is the primary tool developers use to upload packages to the Python " +"Package Index or other Python package indexes. It is a command-line program " +"that passes program files and metadata to a web API. Developers use it " +"because it's the official PyPI upload tool, it's fast and secure, it's " +"maintained, and it reliably works." msgstr "" -#: ../source/key_projects.rst:270 -#: ../source/overview.rst:415 +#: ../source/key_projects.rst:270 ../source/overview.rst:415 msgid "virtualenv" msgstr "" #: ../source/key_projects.rst:272 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:277 -msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgid "" +"virtualenv is a tool which uses the command-line path environment variable " +"to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional " +"functionality, compared to :ref:`venv`, by supporting Python 2.7 and by " +"providing convenient features for configuring, maintaining, duplicating, and " +"troubleshooting the virtual environments. For more information, see the " +"section on :ref:`Creating and using Virtual Environments`." msgstr "" #: ../source/key_projects.rst:290 @@ -4807,11 +7093,16 @@ msgid "Warehouse" msgstr "" #: ../source/key_projects.rst:292 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:296 -msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." +msgid "" +"The current codebase powering the :term:`Python Package Index (PyPI)`. It is " +"hosted at `pypi.org `_. The default source for :ref:`pip` " +"downloads." msgstr "" #: ../source/key_projects.rst:304 @@ -4819,15 +7110,26 @@ msgid "wheel" msgstr "" #: ../source/key_projects.rst:306 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:311 -msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." +msgid "" +"Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` " +"extension for creating :term:`wheel distributions `. Additionally, " +"it offers its own command line utility for creating and installing wheels." msgstr "" #: ../source/key_projects.rst:315 -msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." +msgid "" +"See also `auditwheel `__, a tool that " +"package developers use to check and fix Python packages they are making in " +"the binary wheel format. It provides functionality to discover dependencies, " +"check metadata for compliance, and repair the wheel and metadata to properly " +"link and include external shared libraries in a package." msgstr "" #: ../source/key_projects.rst:324 @@ -4839,11 +7141,17 @@ msgid "bento" msgstr "" #: ../source/key_projects.rst:331 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:336 -msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." +msgid "" +"Bento is a packaging tool solution for Python software, targeted as an " +"alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's " +"philosophy is reproducibility, extensibility and simplicity (in that order)." msgstr "" #: ../source/key_projects.rst:344 @@ -4851,11 +7159,18 @@ msgid "buildout" msgstr "" #: ../source/key_projects.rst:346 -msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" +msgid "" +"`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:351 -msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." +msgid "" +"Buildout is a Python-based build system for creating, assembling and " +"deploying applications from multiple parts, some of which may be non-Python-" +"based. It lets you create a buildout configuration and reproduce the same " +"software later." msgstr "" #: ../source/key_projects.rst:358 @@ -4867,15 +7182,32 @@ msgid "`Docs `__" msgstr "" #: ../source/key_projects.rst:362 -msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." +msgid "" +"conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution " +"from `Anaconda, Inc `__ specifically " +"aimed at the scientific community, and in particular on Windows where the " +"installation of binary extensions is often difficult." msgstr "" #: ../source/key_projects.rst:369 -msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." +msgid "" +"Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, " +"but provides many of their combined features in terms of package management, " +"virtual environment management and deployment of binary extensions." msgstr "" #: ../source/key_projects.rst:373 -msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." +msgid "" +"Conda does not install packages from PyPI and can install only from the " +"official Anaconda repositories, or anaconda.org (a place for user-" +"contributed *conda* packages), or a local (e.g. intranet) package server. " +"However, note that :ref:`pip` can be installed into, and work side-by-side " +"with conda for managing :term:`distributions ` from " +"PyPI. Also, `conda skeleton `__ is a tool to make " +"Python packages installable by conda by first fetching them from PyPI and " +"modifying their metadata." msgstr "" #: ../source/key_projects.rst:386 @@ -4883,11 +7215,17 @@ msgid "devpi" msgstr "" #: ../source/key_projects.rst:388 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:392 -msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." +msgid "" +"devpi features a powerful PyPI-compatible server and PyPI proxy cache with a " +"complementary command line tool to drive packaging, testing and release " +"activities with Python. devpi also provides a browsable and searchable web " +"interface." msgstr "" #: ../source/key_projects.rst:401 @@ -4895,15 +7233,25 @@ msgid "flit" msgstr "" #: ../source/key_projects.rst:403 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:407 -msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." +msgid "" +"Flit provides a simple way to upload pure Python packages and modules to " +"PyPI. It focuses on `making the easy things easy `_ for " +"packaging. Flit can generate a configuration file to quickly set up a simple " +"project, build source distributions and wheels, and upload them to PyPI." msgstr "" #: ../source/key_projects.rst:412 -msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." +msgid "" +"Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on " +"tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to " +"upload them to PyPI. Flit requires Python 3, but you can use it to " +"distribute modules for Python 2, so long as they can be imported on Python 3." msgstr "" #: ../source/key_projects.rst:422 @@ -4911,11 +7259,22 @@ msgid "enscons" msgstr "" #: ../source/key_projects.rst:424 -msgid "`Source `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Source `__ | `Issues `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:428 -msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." +msgid "" +"Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-" +"compatible source distributions and wheels without using distutils or " +"setuptools, including distributions with C extensions. Enscons has a " +"different architecture and philosophy than :ref:`distutils`. Rather than " +"adding build features to a Python packaging system, enscons adds Python " +"packaging to a general purpose build system. Enscons helps you to build " +"sdists that can be automatically built by :ref:`pip`, and wheels that are " +"independent of enscons." msgstr "" #: ../source/key_projects.rst:443 @@ -4923,11 +7282,20 @@ msgid "Hashdist" msgstr "" #: ../source/key_projects.rst:445 -msgid "`Docs `__ | `GitHub `__" +msgid "" +"`Docs `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:448 -msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." +msgid "" +"Hashdist is a library for building non-root software distributions. Hashdist " +"is trying to be “the Debian of choice for cases where Debian technology " +"doesn’t work”. The best way for Pythonistas to think about Hashdist may be a " +"more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed " +"at solving the problem of installing scientific software, and making package " +"distribution stateless, cached, and branchable. It is used by some " +"researchers but has been lacking in maintenance since 2016." msgstr "" #: ../source/key_projects.rst:460 @@ -4935,11 +7303,18 @@ msgid "hatch" msgstr "" #: ../source/key_projects.rst:462 -msgid "`GitHub and Docs `__ | `PyPI `__" +msgid "" +"`GitHub and Docs `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:465 -msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." +msgid "" +"Hatch is a unified command-line tool meant to conveniently manage " +"dependencies and environment isolation for Python developers. Python package " +"developers use Hatch to configure, version, specify dependencies for, and " +"publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload " +"packages to PyPI, and :ref:`pip` to download and install packages." msgstr "" #: ../source/key_projects.rst:475 @@ -4951,7 +7326,10 @@ msgid "`GitHub `__" msgstr "" #: ../source/key_projects.rst:479 -msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." +msgid "" +"Multibuild is a set of CI scripts for building and testing Python :term:" +"`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :" +"ref:`cibuildwheel`." msgstr "" #: ../source/key_projects.rst:485 @@ -4959,11 +7337,18 @@ msgid "pex" msgstr "" #: ../source/key_projects.rst:487 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:491 -msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." +msgid "" +"pex is both a library and tool for generating :file:`.pex` (Python " +"EXecutable) files, standalone Python environments in the spirit of :ref:" +"`virtualenv`. :file:`.pex` files are just carefully constructed zip files " +"with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are " +"designed to make deployment of Python applications as simple as ``cp``." msgstr "" #: ../source/key_projects.rst:500 @@ -4971,11 +7356,20 @@ msgid "pip-tools" msgstr "" #: ../source/key_projects.rst:502 -msgid "`GitHub and Docs `__ | `PyPI `__" +msgid "" +"`GitHub and Docs `__ | `PyPI " +"`__" msgstr "" #: ../source/key_projects.rst:505 -msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." +msgid "" +"pip-tools is a suite of tools meant for Python system administrators and " +"release managers who particularly want to keep their builds deterministic " +"yet stay up to date with new versions of their dependencies. Users can " +"specify particular release of their dependencies via hash, conveniently make " +"a properly formatted list of requirements from information in other parts of " +"their program, update all dependencies (a feature :ref:`pip` currently does " +"not provide), and create layers of constraints for the program to obey." msgstr "" #: ../source/key_projects.rst:517 @@ -4983,11 +7377,17 @@ msgid "piwheels" msgstr "" #: ../source/key_projects.rst:519 -msgid "`Website `__ | `Docs `__ | `GitHub `__" +msgid "" +"`Website `__ | `Docs `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:523 -msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." +msgid "" +"piwheels is a website, and software underpinning it, that fetches source " +"code distribution packages from PyPI and compiles them into binary wheels " +"that are optimized for installation onto Raspberry Pi computers. Raspberry " +"Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." msgstr "" #: ../source/key_projects.rst:532 @@ -4995,11 +7395,19 @@ msgid "poetry" msgstr "" #: ../source/key_projects.rst:534 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:538 -msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." +msgid "" +"poetry is a command-line tool to handle dependency installation and " +"isolation as well as building and packaging of Python packages. It uses " +"``pyproject.toml`` and, instead of depending on the resolver functionality " +"within :ref:`pip`, provides its own dependency resolver. It attempts to " +"speed users' experience of installation and dependency resolution by locally " +"caching metadata about dependencies." msgstr "" #: ../source/key_projects.rst:548 @@ -5007,11 +7415,20 @@ msgid "pypiserver" msgstr "" #: ../source/key_projects.rst:550 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | " +"`GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:554 -msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." +msgid "" +"pypiserver is a minimalist application that serves as a private Python " +"package index within organizations, implementing a simple API and browser " +"interface. You can upload private packages using standard upload tools, and " +"users can download and install them with :ref:`pip`, without publishing them " +"publicly. Organizations who use pypiserver usually download packages both " +"from pypiserver and from PyPI." msgstr "" #: ../source/key_projects.rst:564 @@ -5019,11 +7436,22 @@ msgid "scikit-build" msgstr "" #: ../source/key_projects.rst:566 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:570 -msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." +msgid "" +"Scikit-build is an improved build system generator for CPython C/C++/Fortran/" +"Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :" +"ref:`pip`. It internally uses `cmake `__ " +"(available on PyPI) to provide better support for additional compilers, " +"build systems, cross compilation, and locating dependencies and their " +"associated build requirements. To speed up and parallelize the build of " +"large projects, the user can install `ninja `__ (also available on PyPI)." msgstr "" #: ../source/key_projects.rst:582 @@ -5031,23 +7459,42 @@ msgid "shiv" msgstr "" #: ../source/key_projects.rst:584 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:588 -msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." +msgid "" +"shiv is a command line utility for building fully self contained Python " +"zipapps as outlined in :pep:`441`, but with all their dependencies included. " +"Its primary goal is making distributing Python applications and command line " +"tools fast & easy." msgstr "" #: ../source/key_projects.rst:598 -msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" +msgid "" +"`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" msgstr "" #: ../source/key_projects.rst:603 -msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." +msgid "" +"A flexible package manager designed to support multiple versions, " +"configurations, platforms, and compilers. Spack is like Homebrew, but " +"packages are written in Python and parameterized to allow easy swapping of " +"compilers, library versions, build options, etc. Arbitrarily many versions " +"of packages can coexist on the same system. Spack was designed for rapidly " +"building high performance scientific applications on clusters and " +"supercomputers." msgstr "" #: ../source/key_projects.rst:611 -msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." +msgid "" +"Spack is not in PyPI (yet), but it requires no installation and can be used " +"immediately after cloning from GitHub." msgstr "" #: ../source/key_projects.rst:617 @@ -5055,11 +7502,18 @@ msgid "zest.releaser" msgstr "" #: ../source/key_projects.rst:619 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:623 -msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." +msgid "" +"``zest.releaser`` is a Python package release tool providing an abstraction " +"layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to " +"automate incrementing package version numbers, updating changelogs, tagging " +"releases in source control, and uploading new packages to PyPI." msgstr "" #: ../source/key_projects.rst:630 @@ -5071,11 +7525,17 @@ msgid "ensurepip" msgstr "" #: ../source/key_projects.rst:637 -msgid "`Docs `__ | `Issues `__" +msgid "" +"`Docs `__ | `Issues " +"`__" msgstr "" #: ../source/key_projects.rst:640 -msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." +msgid "" +"A package in the Python Standard Library that provides support for " +"bootstrapping :ref:`pip` into an existing Python installation or virtual " +"environment. In most cases, end users won't use this module, but rather it " +"will be used during the build of the Python distribution." msgstr "" #: ../source/key_projects.rst:649 @@ -5083,15 +7543,26 @@ msgid "distutils" msgstr "" #: ../source/key_projects.rst:651 -msgid "`Docs `__ | `Issues `__" +msgid "" +"`Docs `__ | `Issues " +"`__" msgstr "" #: ../source/key_projects.rst:654 -msgid "The original Python packaging system, added to the standard library in Python 2.0." +msgid "" +"The original Python packaging system, added to the standard library in " +"Python 2.0." msgstr "" #: ../source/key_projects.rst:657 -msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." +msgid "" +"Due to the challenges of maintaining a packaging system where feature " +"updates are tightly coupled to language runtime updates, direct usage of :" +"ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being " +"the preferred replacement. :ref:`Setuptools` not only provides features that " +"plain :ref:`distutils` doesn't offer (such as dependency declarations and " +"entry point declarations), it also provides a consistent build interface and " +"feature set across all supported Python versions." msgstr "" #: ../source/key_projects.rst:670 @@ -5099,11 +7570,17 @@ msgid "venv" msgstr "" #: ../source/key_projects.rst:672 -msgid "`Docs `__ | `Issues `__" +msgid "" +"`Docs `__ | `Issues `__" msgstr "" #: ../source/key_projects.rst:675 -msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgid "" +"A package in the Python Standard Library (starting with Python 3.3) for " +"creating :term:`Virtual Environments `. For more " +"information, see the section on :ref:`Creating and using Virtual " +"Environments`." msgstr "" #: ../source/news.rst:2 @@ -5175,7 +7652,8 @@ msgid "April 2019" msgstr "" #: ../source/news.rst:31 -msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" +msgid "" +"Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" msgstr "" #: ../source/news.rst:32 @@ -5199,7 +7677,9 @@ msgid "February 2019" msgstr "" #: ../source/news.rst:41 -msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" +msgid "" +"Elaborate upon the differences between the tutorial and the real packaging " +"process. (:pr:`602`)" msgstr "" #: ../source/news.rst:42 @@ -5283,7 +7763,8 @@ msgid "Replaced tar command with working command. (:pr:`552`)" msgstr "" #: ../source/news.rst:72 -msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" +msgid "" +"Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" msgstr "" #: ../source/news.rst:75 @@ -5295,7 +7776,8 @@ msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" msgstr "" #: ../source/news.rst:77 -msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" +msgid "" +"Moved the Overview to a task based lead in along with the others. (:pr:`540`)" msgstr "" #: ../source/news.rst:78 @@ -5339,7 +7821,8 @@ msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" msgstr "" #: ../source/news.rst:97 -msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" +msgid "" +"Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" msgstr "" #: ../source/news.rst:98 @@ -5403,7 +7886,8 @@ msgid "Updated \"installing scientific packages\". (:pr:`455`)" msgstr "" #: ../source/news.rst:119 -msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" +msgid "" +"Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" msgstr "" #: ../source/news.rst:120 @@ -5419,7 +7903,9 @@ msgid "February 2018" msgstr "" #: ../source/news.rst:126 -msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" +msgid "" +"Added python3-venv and python3-pip to Debian installation instructions. (:pr:" +"`445`)" msgstr "" #: ../source/news.rst:127 @@ -5427,7 +7913,8 @@ msgid "Updated PyPI migration info. (:pr:`439`)" msgstr "" #: ../source/news.rst:128 -msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" +msgid "" +"Added a warning about managing multiple versions with pipenv. (:pr:`430`)" msgstr "" #: ../source/news.rst:129 @@ -5455,7 +7942,8 @@ msgid "December 2017" msgstr "" #: ../source/news.rst:141 -msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" +msgid "" +"Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" msgstr "" #: ../source/news.rst:142 @@ -5475,15 +7963,20 @@ msgid "November 2017" msgstr "" #: ../source/news.rst:149 -msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" +msgid "" +"Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" msgstr "" #: ../source/news.rst:150 -msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" +msgid "" +"Updated the *Single Sourcing Package Version* tutorial to reflect pip's " +"current strategy. (:pr:`400`)" msgstr "" #: ../source/news.rst:152 -msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" +msgid "" +"Added documentation about the ``py_modules`` argument to ``setup``. (:pr:" +"`398`)" msgstr "" #: ../source/news.rst:153 @@ -5495,11 +7988,14 @@ msgid "October 2017" msgstr "" #: ../source/news.rst:158 -msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" +msgid "" +"Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" msgstr "" #: ../source/news.rst:159 -msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" +msgid "" +"Created a new guide for managing packages using ``pip`` and ``virtualenv``. " +"(:pr:`385`)" msgstr "" #: ../source/news.rst:160 @@ -5511,7 +8007,9 @@ msgid "September 2017" msgstr "" #: ../source/news.rst:165 -msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" +msgid "" +"Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:" +"`379`)" msgstr "" #: ../source/news.rst:167 @@ -5523,7 +8021,9 @@ msgid "August 2017" msgstr "" #: ../source/news.rst:172 -msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" +msgid "" +"Added a new, experimental tutorial on installing packages using ``Pipenv``. " +"(:pr:`369`)" msgstr "" #: ../source/news.rst:173 @@ -5547,15 +8047,20 @@ msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" msgstr "" #: ../source/news.rst:181 -msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" +msgid "" +"Updated this guide's ``readme`` with instructions on how to build the guide " +"locally. (:pr:`356`)" msgstr "" #: ../source/news.rst:182 -msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" +msgid "" +"Made the new ``TestPyPI`` URL more visible, adding note to homepage about " +"pypi.org. (:pr:`354`)" msgstr "" #: ../source/news.rst:183 -msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" +msgid "" +"Added a note about the removal of the explicit registration API. (:pr:`347`)" msgstr "" #: ../source/news.rst:186 @@ -5571,11 +8076,14 @@ msgid "Added documentation for ``python_requires``. (:pr:`338`)" msgstr "" #: ../source/news.rst:190 -msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" +msgid "" +"Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:" +"pr:`335`)" msgstr "" #: ../source/news.rst:191 -msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" +msgid "" +"Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" msgstr "" #: ../source/news.rst:192 @@ -5607,7 +8115,8 @@ msgid "May 2017" msgstr "" #: ../source/news.rst:202 -msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" +msgid "" +"Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" msgstr "" #: ../source/news.rst:203 @@ -5615,7 +8124,9 @@ msgid "Added contributor and style guide. (:pr:`307`)" msgstr "" #: ../source/news.rst:204 -msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" +msgid "" +"Documented ``pip`` and ``easy_install``'s differences for per-project " +"indexes. (:pr:`233`)" msgstr "" #: ../source/news.rst:207 @@ -5627,11 +8138,15 @@ msgid "Added travis configuration for testing pull requests. (:pr:`300`)" msgstr "" #: ../source/news.rst:210 -msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" +msgid "" +"Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:" +"`299`)" msgstr "" #: ../source/news.rst:211 -msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" +msgid "" +"Removed the ``twine register`` reference in the *Distributing Packages* " +"tutorial. (:pr:`271`)" msgstr "" #: ../source/news.rst:212 @@ -5643,23 +8158,33 @@ msgid "Added a topic on namespace packages. (:pr:`290`)" msgstr "" #: ../source/news.rst:214 -msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" +msgid "" +"Added documentation explaining prominently how to install ``pip`` in ``/usr/" +"local``. (:pr:`230`)" msgstr "" #: ../source/news.rst:215 -msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" +msgid "" +"Updated development mode documentation to mention that order of local " +"packages matters. (:pr:`208`)" msgstr "" #: ../source/news.rst:216 -msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" +msgid "" +"Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted " +"projects (:pr:`239`)" msgstr "" #: ../source/news.rst:217 -msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" +msgid "" +"Swaped order of :file:`setup.py` arguments for the upload command, as order " +"is significant. (:pr:`260`)" msgstr "" #: ../source/news.rst:219 -msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" +msgid "" +"Explained how to install from unsupported sources using a helper " +"application. (:pr:`289`)" msgstr "" #: ../source/news.rst:223 @@ -5683,15 +8208,26 @@ msgid "An Overview of Packaging for Python" msgstr "" #: ../source/overview.rst:7 -msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." +msgid "" +"As a general-purpose programming language, Python is designed to be used in " +"many ways. You can build web sites or industrial robots or a game for your " +"friends to play, and much more, all using the same core technology." msgstr "" #: ../source/overview.rst:12 -msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." +msgid "" +"Python's flexibility is why the first step in every Python project must be " +"to think about the project's audience and the corresponding environment " +"where the project will run. It might seem strange to think about packaging " +"before writing code, but this process does wonders for avoiding future " +"headaches." msgstr "" #: ../source/overview.rst:18 -msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." +msgid "" +"This overview provides a general-purpose decision tree for reasoning about " +"Python's plethora of packaging options. Read on to choose the best " +"technology for your next project." msgstr "" #: ../source/overview.rst:26 @@ -5699,23 +8235,36 @@ msgid "Thinking about deployment" msgstr "" #: ../source/overview.rst:28 -msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" +msgid "" +"Packages exist to be installed (or *deployed*), so before you package " +"anything, you'll want to have some answers to the deployment questions below:" msgstr "" #: ../source/overview.rst:32 -msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" +msgid "" +"Who are your software's users? Will your software be installed by other " +"developers doing software development, operations people in a datacenter, or " +"a less software-savvy group?" msgstr "" #: ../source/overview.rst:35 -msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" +msgid "" +"Is your software intended to run on servers, desktops, mobile clients " +"(phones, tablets, etc.), or embedded in dedicated devices?" msgstr "" #: ../source/overview.rst:37 -msgid "Is your software installed individually, or in large deployment batches?" +msgid "" +"Is your software installed individually, or in large deployment batches?" msgstr "" #: ../source/overview.rst:39 -msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." +msgid "" +"Packaging is all about target environment and deployment experience. There " +"are many answers to the questions above and each combination of " +"circumstances has its own solutions. With this information, the following " +"overview will guide you to the packaging technologies best suited to your " +"project." msgstr "" #: ../source/overview.rst:46 @@ -5723,11 +8272,19 @@ msgid "Packaging Python libraries and tools" msgstr "" #: ../source/overview.rst:48 -msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." +msgid "" +"You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are " +"just a few of the tools Python's ecosystem provides for distributing Python " +"code to developers, which you can read about in :doc:`guides/distributing-" +"packages-using-setuptools`." msgstr "" #: ../source/overview.rst:53 -msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." +msgid "" +"The following approaches to packaging are meant for libraries and tools used " +"by technical audience in a development setting. If you're looking for ways " +"to package Python for a non-technical audience and/or a production setting, " +"skip ahead to :ref:`packaging-applications`." msgstr "" #: ../source/overview.rst:59 @@ -5735,15 +8292,27 @@ msgid "Python modules" msgstr "" #: ../source/overview.rst:61 -msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." +msgid "" +"A Python file, provided it only relies on the standard library, can be " +"redistributed and reused. You will also need to ensure it's written for the " +"right version of Python, and only relies on the standard library." msgstr "" #: ../source/overview.rst:66 -msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." +msgid "" +"This is great for sharing simple scripts and snippets between people who " +"both have compatible Python versions (such as via email, StackOverflow, or " +"GitHub gists). There are even some entire Python libraries that offer this " +"as an option, such as `bottle.py `_ and " +"`boltons `_." msgstr "" #: ../source/overview.rst:73 -msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." +msgid "" +"However, this pattern won't scale for projects that consist of multiple " +"files, need additional libraries, or need a specific version of Python, " +"hence the options below." msgstr "" #: ../source/overview.rst:78 @@ -5751,31 +8320,60 @@ msgid "Python source distributions" msgstr "" #: ../source/overview.rst:80 -msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." +msgid "" +"If your code consists of multiple Python files, it's usually organized into " +"a directory structure. Any directory containing Python files can comprise " +"an :term:`Import Package`." msgstr "" #: ../source/overview.rst:84 -msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." +msgid "" +"Because packages consist of multiple files, they are harder to distribute. " +"Most protocols support transferring only one file at a time (when was the " +"last time you clicked a link and it downloaded multiple files?). It's easier " +"to get incomplete transfers, and harder to guarantee code integrity at the " +"destination." msgstr "" #: ../source/overview.rst:90 -msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." +msgid "" +"So long as your code contains nothing but pure Python code, and you know " +"your deployment environment supports your version of Python, then you can " +"use Python's native packaging tools to create a *source* :term:`Distribution " +"Package`, or *sdist* for short." msgstr "" #: ../source/overview.rst:95 -msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." +msgid "" +"Python's *sdists* are compressed archives (``.tar.gz`` files) containing one " +"or more packages or modules. If your code is pure-Python, and you only " +"depend on other Python packages, you can `go here to learn more `_." msgstr "" #: ../source/overview.rst:100 -msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." +msgid "" +"If you rely on any non-Python code, or non-Python packages (such as `libxml2 " +"`_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next " +"section, which also has many advantages for pure-Python libraries." msgstr "" #: ../source/overview.rst:107 -msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" +msgid "" +"Python and PyPI support multiple distributions providing different " +"implementations of the same package. For instance the unmaintained-but-" +"seminal `PIL distribution `_ provides the PIL " +"package, and so does `Pillow `_, an " +"actively-maintained fork of PIL!" msgstr "" #: ../source/overview.rst:114 -msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." +msgid "" +"This Python packaging superpower makes it possible for Pillow to be a drop-" +"in replacement for PIL, just by changing your project's ``install_requires`` " +"or ``requirements.txt``." msgstr "" #: ../source/overview.rst:119 @@ -5783,23 +8381,43 @@ msgid "Python binary distributions" msgstr "" #: ../source/overview.rst:121 -msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." +msgid "" +"So much of Python's practical power comes from its ability to integrate with " +"the software ecosystem, in particular libraries written in C, C++, Fortran, " +"Rust, and other languages." msgstr "" #: ../source/overview.rst:125 -msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." +msgid "" +"Not all developers have the right tools or experiences to build these " +"components written in these compiled languages, so Python created the :term:" +"`Wheel`, a package format designed to ship libraries with compiled " +"artifacts. In fact, Python's package installer, ``pip``, always prefers " +"wheels because installation is always faster, so even pure-Python packages " +"work better with wheels." msgstr "" #: ../source/overview.rst:132 -msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." +msgid "" +"Binary distributions are best when they come with source distributions to " +"match. Even if you don't upload wheels of your code for every operating " +"system, by uploading the sdist, you're enabling users of other platforms to " +"still build it for themselves. Default to publishing both sdist and wheel " +"archives together, *unless* you're creating artifacts for a very specific " +"use case where you know the recipient only needs one or the other." msgstr "" #: ../source/overview.rst:140 -msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." +msgid "" +"Python and PyPI make it easy to upload both wheels and sdists together. Just " +"follow the :doc:`tutorials/packaging-projects` tutorial." msgstr "" #: ../source/overview.rst:148 -msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." +msgid "" +"Python's recommended built-in library and tool packaging technologies. " +"Excerpted from `The Packaging Gradient (2017) `_." msgstr "" #: ../source/overview.rst:155 @@ -5807,23 +8425,39 @@ msgid "Packaging Python applications" msgstr "" #: ../source/overview.rst:157 -msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." +msgid "" +"So far we've only discussed Python's native distribution tools. Based on our " +"introduction, you would be correct to infer these built-in approaches only " +"target environments which have Python, and an audience who knows how to " +"install Python packages." msgstr "" #: ../source/overview.rst:162 -msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." +msgid "" +"With the variety of operating systems, configurations, and people out there, " +"this assumption is only safe when targeting a developer audience." msgstr "" #: ../source/overview.rst:166 -msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." +msgid "" +"Python's native packaging is mostly built for distributing reusable code, " +"called libraries, between developers. You can piggyback **tools**, or basic " +"applications for developers, on top of Python's library packaging, using " +"technologies like `setuptools entry_points `_." msgstr "" #: ../source/overview.rst:172 -msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." +msgid "" +"Libraries are building blocks, not complete applications. For distributing " +"applications, there's a whole new world of technologies out there." msgstr "" #: ../source/overview.rst:176 -msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." +msgid "" +"The next few sections organize these application packaging options according " +"to their dependencies on the target environment, so you can choose the right " +"one for your project." msgstr "" #: ../source/overview.rst:181 @@ -5831,15 +8465,27 @@ msgid "Depending on a framework" msgstr "" #: ../source/overview.rst:183 -msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." +msgid "" +"Some types of Python applications, like web site backends and other network " +"services, are common enough that they have frameworks to enable their " +"development and packaging. Other types of applications, like dynamic web " +"frontends and mobile clients, are complex enough to target that a framework " +"becomes more than a convenience." msgstr "" #: ../source/overview.rst:189 -msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." +msgid "" +"In all these cases, it makes sense to work backwards, from the framework's " +"packaging and deployment story. Some frameworks include a deployment system " +"which wraps the technologies outlined in the rest of the guide. In these " +"cases, you'll want to defer to your framework's packaging guide for the " +"easiest and most reliable production experience." msgstr "" #: ../source/overview.rst:195 -msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." +msgid "" +"If you ever wonder how these platforms and frameworks work under the hood, " +"you can always read the sections beyond." msgstr "" #: ../source/overview.rst:199 @@ -5847,11 +8493,15 @@ msgid "Service platforms" msgstr "" #: ../source/overview.rst:201 -msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." +msgid "" +"If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku " +"or Google App Engine, you are going to want to follow their respective " +"packaging guides." msgstr "" #: ../source/overview.rst:205 -msgid "`Heroku `_" +msgid "" +"`Heroku `_" msgstr "" #: ../source/overview.rst:206 @@ -5871,11 +8521,16 @@ msgid "\"Serverless\" frameworks like `Zappa `_" msgstr "" #: ../source/overview.rst:211 -msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." +msgid "" +"In all these setups, the platform takes care of packaging and deployment, as " +"long as you follow their patterns. Most software does not fit one of these " +"templates, hence the existence of all the other options below." msgstr "" #: ../source/overview.rst:216 -msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." +msgid "" +"If you're developing software that will be deployed to machines you own, " +"users' personal computers, or any other arrangement, read on." msgstr "" #: ../source/overview.rst:220 @@ -5883,11 +8538,16 @@ msgid "Web browsers and mobile applications" msgstr "" #: ../source/overview.rst:222 -msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." +msgid "" +"Python's steady advances are leading it into new spaces. These days you can " +"write a mobile app or web application frontend in Python. While the language " +"may be familiar, the packaging and deployment practices are brand new." msgstr "" #: ../source/overview.rst:227 -msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" +msgid "" +"If you're planning on releasing to these new frontiers, you'll want to check " +"out the following frameworks, and refer to their packaging guides:" msgstr "" #: ../source/overview.rst:231 @@ -5907,7 +8567,10 @@ msgid "`Flexx `_" msgstr "" #: ../source/overview.rst:236 -msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." +msgid "" +"If you are *not* interested in using a framework or platform, or just wonder " +"about some of the technologies and techniques utilized by the frameworks " +"above, continue reading below." msgstr "" #: ../source/overview.rst:241 @@ -5915,7 +8578,12 @@ msgid "Depending on a pre-installed Python" msgstr "" #: ../source/overview.rst:243 -msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." +msgid "" +"Pick an arbitrary computer, and depending on the context, there's a very " +"good chance Python is already installed. Included by default in most Linux " +"and Mac operating systems for many years now, you can reasonably depend on " +"Python preexisting in your data centers or on the personal machines of " +"developers and data scientists." msgstr "" #: ../source/overview.rst:249 @@ -5927,7 +8595,9 @@ msgid "`PEX `_ (Python EXecutable)" msgstr "" #: ../source/overview.rst:252 -msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" +msgid "" +"`zipapp `_ (does not help " +"manage dependencies, requires Python 3.5+)" msgstr "" #: ../source/overview.rst:253 @@ -5935,11 +8605,17 @@ msgid "`shiv `_ (requires Python 3)" msgstr "" #: ../source/overview.rst:255 -msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." +msgid "" +"Of all the approaches here, depending on a pre-installed Python relies the " +"most on the target environment. Of course, this also makes for the smallest " +"package, as small as single-digit megabytes, or even kilobytes." msgstr "" #: ../source/overview.rst:260 -msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." +msgid "" +"In general, decreasing the dependency on the target system increases the " +"size of our package, so the solutions here are roughly arranged by " +"increasing size of output." msgstr "" #: ../source/overview.rst:267 @@ -5947,11 +8623,24 @@ msgid "Depending on a separate software distribution ecosystem" msgstr "" #: ../source/overview.rst:269 -msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." +msgid "" +"For a long time many operating systems, including Mac and Windows, lacked " +"built-in package management. Only recently did these OSes gain so-called " +"\"app stores\", but even those focus on consumer applications and offer " +"little for developers." msgstr "" #: ../source/overview.rst:274 -msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." +msgid "" +"Developers long sought remedies, and in this struggle, emerged with their " +"own package management solutions, such as `Homebrew `_. " +"The most relevant alternative for Python developers is a package ecosystem " +"called `Anaconda `_. Anaconda is built around Python and is " +"increasingly common in academic, analytical, and other data-oriented " +"environments, even making its way `into server-oriented environments " +"`_." msgstr "" #: ../source/overview.rst:284 @@ -5959,15 +8648,21 @@ msgid "Instructions on building and publishing for the Anaconda ecosystem:" msgstr "" #: ../source/overview.rst:286 -msgid "`Building libraries and applications with conda `_" +msgid "" +"`Building libraries and applications with conda `_" msgstr "" #: ../source/overview.rst:287 -msgid "`Transitioning a native Python package to Anaconda `_" +msgid "" +"`Transitioning a native Python package to Anaconda `_" msgstr "" #: ../source/overview.rst:289 -msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" +msgid "" +"A similar model involves installing an alternative Python distribution, but " +"does not support arbitrary operating system-level packages:" msgstr "" #: ../source/overview.rst:293 @@ -5987,15 +8682,24 @@ msgid "Bringing your own Python executable" msgstr "" #: ../source/overview.rst:302 -msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." +msgid "" +"Computing as we know it is defined by the ability to execute programs. Every " +"operating system natively supports one or more formats of program they can " +"natively execute." msgstr "" #: ../source/overview.rst:306 -msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." +msgid "" +"There are many techniques and technologies which turn your Python program " +"into one of these formats, most of which involve embedding the Python " +"interpreter and any other dependencies into a single executable file." msgstr "" #: ../source/overview.rst:311 -msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." +msgid "" +"This approach, called *freezing*, offers wide compatibility and seamless " +"user experience, though often requires multiple technologies, and a good " +"amount of effort." msgstr "" #: ../source/overview.rst:315 @@ -6007,11 +8711,14 @@ msgid "`pyInstaller `_ - Cross-platform" msgstr "" #: ../source/overview.rst:318 -msgid "`cx_Freeze `_ - Cross-platform" +msgid "" +"`cx_Freeze `_ - Cross-platform" msgstr "" #: ../source/overview.rst:319 -msgid "`constructor `_ - For command-line installers" +msgid "" +"`constructor `_ - For command-line " +"installers" msgstr "" #: ../source/overview.rst:320 @@ -6023,7 +8730,9 @@ msgid "`py2app `_ - Mac only" msgstr "" #: ../source/overview.rst:322 -msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" +msgid "" +"`bbFreeze `_ - Windows, Linux, Python 2 " +"only" msgstr "" #: ../source/overview.rst:323 @@ -6035,7 +8744,9 @@ msgid "`pynsist `_ - Windows only" msgstr "" #: ../source/overview.rst:326 -msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." +msgid "" +"Most of the above imply single-user deployments. For multi-component server " +"applications, see `Chef Omnibus `_." msgstr "" #: ../source/overview.rst:332 @@ -6043,15 +8754,24 @@ msgid "Bringing your own userspace" msgstr "" #: ../source/overview.rst:334 -msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." +msgid "" +"An increasing number of operating systems -- including Linux, Mac OS, and " +"Windows -- can be set up to run applications packaged as lightweight images, " +"using a relatively modern arrangement often referred to as `operating-system-" +"level virtualization `_, or *containerization*." msgstr "" #: ../source/overview.rst:341 -msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." +msgid "" +"These techniques are mostly Python agnostic, because they package whole OS " +"filesystems, not just Python or Python packages." msgstr "" #: ../source/overview.rst:344 -msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" +msgid "" +"Adoption is most extensive among Linux servers, where the technology " +"originated and where the technologies below work best:" msgstr "" #: ../source/overview.rst:347 @@ -6075,11 +8795,18 @@ msgid "Bringing your own kernel" msgstr "" #: ../source/overview.rst:355 -msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." +msgid "" +"Most operating systems support some form of classical virtualization, " +"running applications packaged as images containing a full operating system " +"of their own. Running these virtual machines, or VMs, is a mature approach, " +"widespread in data center environments." msgstr "" #: ../source/overview.rst:360 -msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" +msgid "" +"These techniques are mostly reserved for larger scale deployments in data " +"centers, though certain complex applications can benefit from this " +"packaging. Technologies are Python agnostic, and include:" msgstr "" #: ../source/overview.rst:364 @@ -6087,11 +8814,16 @@ msgid "`Vagrant `_" msgstr "" #: ../source/overview.rst:365 -msgid "`VHD `_, `AMI `_, and `other formats `_" +msgid "" +"`VHD `_, `AMI `_, and `other formats `_" msgstr "" #: ../source/overview.rst:366 -msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" +msgid "" +"`OpenStack `_ - A cloud " +"management system in Python, with extensive VM support" msgstr "" #: ../source/overview.rst:369 @@ -6099,19 +8831,31 @@ msgid "Bringing your own hardware" msgstr "" #: ../source/overview.rst:371 -msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." +msgid "" +"The most all-encompassing way to ship your software would be to ship it " +"already-installed on some hardware. This way, your software's user would " +"require only electricity." msgstr "" #: ../source/overview.rst:375 -msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." +msgid "" +"Whereas the virtual machines described above are primarily reserved for the " +"tech-savvy, you can find hardware appliances being used by everyone from the " +"most advanced data centers to the youngest children." msgstr "" #: ../source/overview.rst:379 -msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." +msgid "" +"Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the " +"datacenter or your users' homes. They plug and play, and you can call it a " +"day." msgstr "" #: ../source/overview.rst:389 -msgid "The simplified gamut of technologies used to package Python applications." +msgid "" +"The simplified gamut of technologies used to package Python applications." msgstr "" #: ../source/overview.rst:392 @@ -6119,7 +8863,9 @@ msgid "What about..." msgstr "" #: ../source/overview.rst:394 -msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." +msgid "" +"The sections above can only summarize so much, and you might be wondering " +"about some of the more conspicuous gaps." msgstr "" #: ../source/overview.rst:398 @@ -6127,19 +8873,40 @@ msgid "Operating system packages" msgstr "" #: ../source/overview.rst:400 -msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." +msgid "" +"As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some " +"operating systems have package managers of their own. If you're very sure of " +"the operating system you're targeting, you can depend directly on a format " +"like `deb `_ (for Debian, " +"Ubuntu, etc.) or `RPM `_ " +"(for Red Hat, Fedora, etc.), and use that built-in package manager to take " +"care of installation, and even deployment. You can even use `FPM `_ to generate both deb " +"and RPMs from the same source." msgstr "" #: ../source/overview.rst:411 -msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." +msgid "" +"In most deployment pipelines, the OS package manager is just one piece of " +"the puzzle." msgstr "" #: ../source/overview.rst:417 -msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." +msgid "" +"`Virtualenvs `_ have been an indispensable tool for multiple generations of Python " +"developer, but are slowly fading from view, as they are being wrapped by " +"higher-level tools. With packaging in particular, virtualenvs are used as a " +"primitive in `the dh-virtualenv tool `_ and `osnap `_, " +"both of which wrap virtualenvs in a self-contained way." msgstr "" #: ../source/overview.rst:427 -msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." +msgid "" +"For production deployments, do not rely on running ``python -m pip install`` " +"from the Internet into a virtualenv, as one might do in a development " +"environment. The overview above is full of much better solutions." msgstr "" #: ../source/overview.rst:432 @@ -6147,11 +8914,20 @@ msgid "Security" msgstr "安全" #: ../source/overview.rst:434 -msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." +msgid "" +"The further down the gradient you come, the harder it gets to update " +"components of your package. Everything is more tightly bound together." msgstr "" #: ../source/overview.rst:437 -msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." +msgid "" +"For example, if a kernel security issue emerges, and you're deploying " +"containers, the host system's kernel can be updated without requiring a new " +"build on behalf of the application. If you deploy VM images, you'll need a " +"new build. Whether or not this dynamic makes one option more secure is still " +"a bit of an old debate, going back to the still-unsettled matter of `static " +"versus dynamic linking `_." msgstr "" #: ../source/overview.rst:446 @@ -6159,7 +8935,12 @@ msgid "Wrap up" msgstr "" #: ../source/overview.rst:448 -msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." +msgid "" +"Packaging in Python has a bit of a reputation for being a bumpy ride. This " +"impression is mostly a byproduct of Python's versatility. Once you " +"understand the natural boundaries between each packaging solution, you begin " +"to realize that the varied landscape is a small price Python programmers pay " +"for using one of the most balanced, flexible languages available." msgstr "" #: ../source/specifications/binary-distribution-format.rst:6 @@ -6167,7 +8948,9 @@ msgid "Binary distribution format" msgstr "" #: ../source/specifications/binary-distribution-format.rst:8 -msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." +msgid "" +"The binary distribution format (:term:`wheel `) was originally " +"defined in :pep:`427`. The current version of the specification is here." msgstr "" #: ../source/specifications/binary-distribution-format.rst:13 @@ -6179,7 +8962,14 @@ msgid "This PEP describes a built-package format for Python called \"wheel\"." msgstr "" #: ../source/specifications/binary-distribution-format.rst:17 -msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." +msgid "" +"A wheel is a ZIP-format archive with a specially formatted file name and the " +"``.whl`` extension. It contains a single distribution nearly as it would be " +"installed according to PEP 376 with a particular installation scheme. " +"Although a specialized installer is recommended, a wheel file may be " +"installed by simply unpacking into site-packages with the standard 'unzip' " +"tool while preserving enough information to spread its contents out onto " +"their final paths at any later time." msgstr "" #: ../source/specifications/binary-distribution-format.rst:27 @@ -6187,7 +8977,9 @@ msgid "PEP Acceptance" msgstr "" #: ../source/specifications/binary-distribution-format.rst:29 -msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" +msgid "" +"This PEP was accepted, and the defined wheel version updated to 1.0, by Nick " +"Coghlan on 16th February, 2013 [1]_" msgstr "" #: ../source/specifications/binary-distribution-format.rst:34 @@ -6195,11 +8987,22 @@ msgid "Rationale" msgstr "" #: ../source/specifications/binary-distribution-format.rst:36 -msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." +msgid "" +"Python needs a package format that is easier to install than sdist. Python's " +"sdist packages are defined by and require the distutils and setuptools build " +"systems, running arbitrary code to build-and-install, and re-compile, code " +"just so it can be installed into a new virtualenv. This system of " +"conflating build-install is slow, hard to maintain, and hinders innovation " +"in both build systems and installers." msgstr "" #: ../source/specifications/binary-distribution-format.rst:43 -msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." +msgid "" +"Wheel attempts to remedy these problems by providing a simpler interface " +"between the build system and the installer. The wheel binary package format " +"frees installers from having to know about the build system, saves time by " +"amortizing compile time over many installations, and removes the need to " +"install a build system in the target environment." msgstr "" #: ../source/specifications/binary-distribution-format.rst:52 @@ -6223,11 +9026,14 @@ msgid "Parse ``distribution-1.0.dist-info/WHEEL``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:62 -msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." +msgid "" +"Check that installer is compatible with Wheel-Version. Warn if minor " +"version is greater, abort if major version is greater." msgstr "" #: ../source/specifications/binary-distribution-format.rst:64 -msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." +msgid "" +"If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:66 @@ -6239,15 +9045,24 @@ msgid "Spread." msgstr "" #: ../source/specifications/binary-distribution-format.rst:70 -msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." +msgid "" +"Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is " +"data) ``distribution-1.0.data/``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:72 -msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." +msgid "" +"Move each subtree of ``distribution-1.0.data/`` onto its destination path. " +"Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of " +"destination directories, such as ``distribution-1.0.data/(purelib|platlib|" +"headers|scripts|data)``. The initially supported paths are taken from " +"``distutils.command.install``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:78 -msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." +msgid "" +"If applicable, update scripts starting with ``#!python`` to point to the " +"correct interpreter." msgstr "" #: ../source/specifications/binary-distribution-format.rst:80 @@ -6259,7 +9074,9 @@ msgid "Remove empty ``distribution-1.0.data`` directory." msgstr "" #: ../source/specifications/binary-distribution-format.rst:83 -msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" +msgid "" +"Compile any installed .py to .pyc. (Uninstallers should be smart enough to " +"remove .pyc even if it is not mentioned in RECORD.)" msgstr "" #: ../source/specifications/binary-distribution-format.rst:87 @@ -6271,11 +9088,17 @@ msgid "Rewrite ``#!python``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:90 -msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." +msgid "" +"In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/" +"``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!" +"python'``, rewrite to point to the correct interpreter. Unix installers may " +"need to add the +x bit to these files if the archive was created on Windows." msgstr "" #: ../source/specifications/binary-distribution-format.rst:96 -msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." +msgid "" +"The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI " +"script instead of a console script." msgstr "" #: ../source/specifications/binary-distribution-format.rst:102 @@ -6283,7 +9106,10 @@ msgid "Generate script wrappers." msgstr "" #: ../source/specifications/binary-distribution-format.rst:100 -msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." +msgid "" +"In wheel, scripts packaged on Unix systems will certainly not have " +"accompanying .exe wrappers. Windows installers may want to add them during " +"install." msgstr "" #: ../source/specifications/binary-distribution-format.rst:105 @@ -6295,7 +9121,11 @@ msgid "Place ``.dist-info`` at the end of the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:108 -msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." +msgid "" +"Archivers are encouraged to place the ``.dist-info`` files physically at the " +"end of the archive. This enables some potentially interesting ZIP tricks " +"including the ability to amend the metadata without rewriting the entire " +"archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:115 @@ -6307,7 +9137,9 @@ msgid "File name convention" msgstr "" #: ../source/specifications/binary-distribution-format.rst:120 -msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." +msgid "" +"The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-" +"{abi tag}-{platform tag}.whl``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:124 @@ -6327,7 +9159,12 @@ msgid "build tag" msgstr "" #: ../source/specifications/binary-distribution-format.rst:130 -msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." +msgid "" +"Optional build number. Must start with a digit. Acts as a tie-breaker if " +"two wheel file names are the same in all other respects (i.e. name, version, " +"and other tags). Sort as an empty tuple if unspecified, else sort as a two-" +"item tuple with the first item being the initial digits as an ``int``, and " +"the second item being the remainder of the tag as a ``str``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:138 @@ -6355,11 +9192,18 @@ msgid "E.g. 'linux_x86_64', 'any'." msgstr "" #: ../source/specifications/binary-distribution-format.rst:146 -msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." +msgid "" +"For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of " +"a package called 'distribution', and is compatible with Python 2.7 (any " +"Python 2.7 implementation), with no ABI (pure Python), on any CPU " +"architecture." msgstr "" #: ../source/specifications/binary-distribution-format.rst:151 -msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." +msgid "" +"The last three components of the filename before the extension are called " +"\"compatibility tags.\" The compatibility tags express the package's basic " +"interpreter requirements and are detailed in PEP 425." msgstr "" #: ../source/specifications/binary-distribution-format.rst:156 @@ -6367,31 +9211,50 @@ msgid "Escaping and Unicode" msgstr "" #: ../source/specifications/binary-distribution-format.rst:158 -msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" +msgid "" +"As the components of the filename are separated by a dash (``-``, HYPHEN-" +"MINUS), this character cannot appear within any component. This is handled " +"as follows:" msgstr "" #: ../source/specifications/binary-distribution-format.rst:161 -msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." +msgid "" +"In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE " +"and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent " +"to :pep:`503` normalisation followed by replacing ``-`` with ``_``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:164 -msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." +msgid "" +"Version numbers should be normalised according to :pep:`440`. Normalised " +"version numbers cannot contain ``-``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:166 -msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." +msgid "" +"The remaining components may not contain ``-`` characters, so no escaping is " +"necessary." msgstr "" #: ../source/specifications/binary-distribution-format.rst:169 -msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." +msgid "" +"Tools producing wheels should verify that the filename components do not " +"contain ``-``, as the resulting file may not be processed correctly if they " +"do." msgstr "" #: ../source/specifications/binary-distribution-format.rst:172 -msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." +msgid "" +"The archive filename is Unicode. It will be some time before the tools are " +"updated to support non-ASCII filenames, but they are supported in this " +"specification." msgstr "" #: ../source/specifications/binary-distribution-format.rst:176 -msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." +msgid "" +"The filenames *inside* the archive are encoded as UTF-8. Although some ZIP " +"clients in common use do not properly display UTF-8 filenames, the encoding " +"is supported by both the ZIP specification and Python's ``zipfile``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:182 @@ -6399,11 +9262,17 @@ msgid "File contents" msgstr "" #: ../source/specifications/binary-distribution-format.rst:184 -msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" +msgid "" +"The contents of a wheel file, where {distribution} is replaced with the name " +"of the package, e.g. ``beaglevote`` and {version} is replaced with its " +"version, e.g. ``1.0.0``, consist of:" msgstr "" #: ../source/specifications/binary-distribution-format.rst:188 -msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." +msgid "" +"``/``, the root of the archive, contains all files to be installed in " +"``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and " +"``platlib`` are usually both ``site-packages``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:191 @@ -6411,19 +9280,30 @@ msgid "``{distribution}-{version}.dist-info/`` contains metadata." msgstr "" #: ../source/specifications/binary-distribution-format.rst:192 -msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." +msgid "" +"``{distribution}-{version}.data/`` contains one subdirectory for each non-" +"empty install scheme key not already covered, where the subdirectory name is " +"an index into a dictionary of install paths (e.g. ``data``, ``scripts``, " +"``include``, ``purelib``, ``platlib``)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:196 -msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." +msgid "" +"Python scripts must appear in ``scripts`` and begin with exactly ``b'#!" +"python'`` in order to enjoy script wrapper generation and ``#!python`` " +"rewriting at install time. They may have any or no extension." msgstr "" #: ../source/specifications/binary-distribution-format.rst:200 -msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." +msgid "" +"``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or " +"greater format metadata." msgstr "" #: ../source/specifications/binary-distribution-format.rst:202 -msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" +msgid "" +"``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive " +"itself in the same basic key: value format::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:212 @@ -6431,27 +9311,40 @@ msgid "``Wheel-Version`` is the version number of the Wheel specification." msgstr "" #: ../source/specifications/binary-distribution-format.rst:213 -msgid "``Generator`` is the name and optionally the version of the software that produced the archive." +msgid "" +"``Generator`` is the name and optionally the version of the software that " +"produced the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:215 -msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." +msgid "" +"``Root-Is-Purelib`` is true if the top level directory of the archive should " +"be installed into purelib; otherwise the root should be installed into " +"platlib." msgstr "" #: ../source/specifications/binary-distribution-format.rst:218 -msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." +msgid "" +"``Tag`` is the wheel's expanded compatibility tags; in the example the " +"filename would contain ``py2.py3-none-any``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:220 -msgid "``Build`` is the build number and is omitted if there is no build number." +msgid "" +"``Build`` is the build number and is omitted if there is no build number." msgstr "" #: ../source/specifications/binary-distribution-format.rst:221 -msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." +msgid "" +"A wheel installer should warn if Wheel-Version is greater than the version " +"it supports, and must fail if Wheel-Version has a greater major version than " +"the version it supports." msgstr "" #: ../source/specifications/binary-distribution-format.rst:224 -msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." +msgid "" +"Wheel, being an installation format that is intended to work across multiple " +"versions of Python, does not generally include .pyc files." msgstr "" #: ../source/specifications/binary-distribution-format.rst:226 @@ -6459,7 +9352,11 @@ msgid "Wheel does not contain setup.py or setup.cfg." msgstr "Wheel 不包含 setup.py 或 setup.cfg。" #: ../source/specifications/binary-distribution-format.rst:228 -msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." +msgid "" +"This version of the wheel specification is based on the distutils install " +"schemes and does not define how to install files to other locations. The " +"layout offers a superset of the functionality provided by the existing " +"wininst and egg binary formats." msgstr "" #: ../source/specifications/binary-distribution-format.rst:235 @@ -6468,11 +9365,15 @@ msgid "The .dist-info directory" msgstr "目录 .dist-info" #: ../source/specifications/binary-distribution-format.rst:237 -msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." +msgid "" +"Wheel .dist-info directories include at a minimum METADATA, WHEEL, and " +"RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:239 -msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." +msgid "" +"METADATA is the package metadata, the same format as PKG-INFO as found at " +"the root of sdists." msgstr "" #: ../source/specifications/binary-distribution-format.rst:241 @@ -6480,7 +9381,12 @@ msgid "WHEEL is the wheel metadata specific to a build of the package." msgstr "" #: ../source/specifications/binary-distribution-format.rst:242 -msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." +msgid "" +"RECORD is a list of (almost) all the files in the wheel and their secure " +"hashes. Unlike PEP 376, every file except RECORD, which cannot contain a " +"hash of itself, must include its hash. The hash algorithm must be sha256 or " +"better; specifically, md5 and sha1 are not permitted, as signed wheel files " +"rely on the strong hashes in RECORD to validate the integrity of the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:248 @@ -6488,15 +9394,22 @@ msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:249 -msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." +msgid "" +"RECORD.jws is used for digital signatures. It is not mentioned in RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:251 -msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." +msgid "" +"RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME " +"signatures to secure their wheel files. It is not mentioned in RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:254 -msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." +msgid "" +"During extraction, wheel installers verify all the hashes in RECORD against " +"the file contents. Apart from RECORD and its signatures, installation will " +"fail if any file in the archive is not both mentioned and correctly hashed " +"in RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:261 @@ -6504,11 +9417,17 @@ msgid "The .data directory" msgstr ".data 目录" #: ../source/specifications/binary-distribution-format.rst:263 -msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" +msgid "" +"Any file that is not normally installed inside site-packages goes into the ." +"data directory, named as the .dist-info directory but with the .data/ " +"extension::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:271 -msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." +msgid "" +"The .data directory contains subdirectories with the scripts, headers, " +"documentation and so forth from the distribution. During installation the " +"contents of these subdirectories are moved onto their destination paths." msgstr "" #: ../source/specifications/binary-distribution-format.rst:277 @@ -6516,15 +9435,29 @@ msgid "Signed wheel files" msgstr "" #: ../source/specifications/binary-distribution-format.rst:279 -msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" +msgid "" +"Wheel files include an extended RECORD that enables digital signatures. PEP " +"376's RECORD is altered to include a secure hash " +"``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with " +"no trailing = characters) as the second column instead of an md5sum. All " +"possible entries are hashed, including any generated files such as .pyc " +"files, but not RECORD which cannot contain its own hash. For example::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:290 -msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." +msgid "" +"The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD " +"at all since they can only be added after RECORD is generated. Every other " +"file in the archive must have a correct hash in RECORD or the installation " +"will fail." msgstr "" #: ../source/specifications/binary-distribution-format.rst:295 -msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" +msgid "" +"If JSON web signatures are used, one or more JSON Web Signature JSON " +"Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to " +"RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD " +"as the signature's JSON payload::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:302 @@ -6532,11 +9465,17 @@ msgid "(The hash value is the same format used in RECORD.)" msgstr "" #: ../source/specifications/binary-distribution-format.rst:304 -msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." +msgid "" +"If RECORD.p7s is used, it must contain a detached S/MIME format signature of " +"RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:307 -msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." +msgid "" +"A wheel installer is not required to understand digital signatures but MUST " +"verify the hashes in RECORD against the extracted file contents. When the " +"installer checks file hashes against RECORD, a separate signature checker " +"only needs to establish that RECORD matches the signature." msgstr "" #: ../source/specifications/binary-distribution-format.rst:312 @@ -6548,7 +9487,8 @@ msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" #: ../source/specifications/binary-distribution-format.rst:315 -msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" +msgid "" +"http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" msgstr "" "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" @@ -6565,23 +9505,41 @@ msgid "Comparison to .egg" msgstr "与 .egg 的比较" #: ../source/specifications/binary-distribution-format.rst:323 -msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." +msgid "" +"Wheel is an installation format; egg is importable. Wheel archives do not " +"need to include .pyc and are less tied to a specific Python version or " +"implementation. Wheel can install (pure Python) packages built with previous " +"versions of Python so you don't always have to wait for the packager to " +"catch up." msgstr "" #: ../source/specifications/binary-distribution-format.rst:328 -msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." +msgid "" +"Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible " +"with the new world of Python packaging and the new concepts it brings." msgstr "" #: ../source/specifications/binary-distribution-format.rst:331 -msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." +msgid "" +"Wheel has a richer file naming convention for today's multi-implementation " +"world. A single wheel archive can indicate its compatibility with a number " +"of Python language versions and implementations, ABIs, and system " +"architectures. Historically the ABI has been specific to a CPython release, " +"wheel is ready for the stable ABI." msgstr "" #: ../source/specifications/binary-distribution-format.rst:337 -msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." +msgid "" +"Wheel is lossless. The first wheel implementation bdist_wheel always " +"generates egg-info, and then converts it to a .whl. It is also possible to " +"convert existing eggs and bdist_wininst distributions." msgstr "" #: ../source/specifications/binary-distribution-format.rst:341 -msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." +msgid "" +"Wheel is versioned. Every wheel file contains the version of the wheel " +"specification and the implementation that packaged it. Hopefully the next " +"migration can simply be to Wheel 2.0." msgstr "" #: ../source/specifications/binary-distribution-format.rst:344 @@ -6597,7 +9555,13 @@ msgid "Wheel defines a .data directory. Should I put all my data there?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:354 -msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." +msgid "" +"This specification does not have an opinion on how you should organize your " +"code. The .data directory is just a place for any files that are not " +"normally installed inside ``site-packages`` or on the PYTHONPATH. In other " +"words, you may continue to use ``pkgutil.get_data(package, resource)`` even " +"though *those* files will usually not be distributed in *wheel's* ``.data`` " +"directory." msgstr "" #: ../source/specifications/binary-distribution-format.rst:363 @@ -6605,7 +9569,12 @@ msgid "Why does wheel include attached signatures?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:365 -msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." +msgid "" +"Attached signatures are more convenient than detached signatures because " +"they travel with the archive. Since only the individual files are signed, " +"the archive can be recompressed without invalidating the signature or " +"individual files can be verified without having to download the whole " +"archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:373 @@ -6613,7 +9582,10 @@ msgid "Why does wheel allow JWS signatures?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:375 -msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." +msgid "" +"The JOSE specifications of which JWS is a part are designed to be easy to " +"implement, a feature that is also one of wheel's primary design goals. JWS " +"yields a useful, concise pure-Python implementation." msgstr "" #: ../source/specifications/binary-distribution-format.rst:381 @@ -6621,11 +9593,15 @@ msgid "Why does wheel also allow S/MIME signatures?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:383 -msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." +msgid "" +"S/MIME signatures are allowed for users who need or want to use existing " +"public key infrastructure with wheel." msgstr "" #: ../source/specifications/binary-distribution-format.rst:386 -msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." +msgid "" +"Signed packages are only a basic building block in a secure package update " +"system. Wheel only provides the building block." msgstr "" #: ../source/specifications/binary-distribution-format.rst:391 @@ -6633,15 +9609,26 @@ msgid "What's the deal with \"purelib\" vs. \"platlib\"?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:393 -msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." +msgid "" +"Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is " +"significant on some platforms. For example, Fedora installs pure Python " +"packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent " +"packages to '/usr/lib64/pythonX.Y/site-packages'." msgstr "" #: ../source/specifications/binary-distribution-format.rst:398 -msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." +msgid "" +"A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-" +"{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: " +"true\" with those same files in the root, and it is legal to have files in " +"both the \"purelib\" and \"platlib\" categories." msgstr "" #: ../source/specifications/binary-distribution-format.rst:403 -msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." +msgid "" +"In practice a wheel should have only one of \"purelib\" or \"platlib\" " +"depending on whether it is pure Python or not and those files should be at " +"the root with the appropriate setting given for \"Root-is-purelib\"." msgstr "" #: ../source/specifications/binary-distribution-format.rst:409 @@ -6649,19 +9636,50 @@ msgid "Is it possible to import Python code directly from a wheel file?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:411 -msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." +msgid "" +"Technically, due to the combination of supporting installation via simple " +"extraction and using an archive format that is compatible with " +"``zipimport``, a subset of wheel files *do* support being placed directly on " +"``sys.path``. However, while this behaviour is a natural consequence of the " +"format design, actually relying on it is generally discouraged." msgstr "" #: ../source/specifications/binary-distribution-format.rst:417 -msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." +msgid "" +"Firstly, wheel *is* designed primarily as a distribution format, so skipping " +"the installation step also means deliberately avoiding any reliance on " +"features that assume full installation (such as being able to use standard " +"tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in " +"a way that can be properly tracked for auditing and security update " +"purposes, or integrating fully with the standard build machinery for C " +"extensions by publishing header files in the appropriate place)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:426 -msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." +msgid "" +"Secondly, while some Python software is written to support running directly " +"from a zip archive, it is still common for code to be written assuming it " +"has been fully installed. When that assumption is broken by trying to run " +"the software from a zip archive, the failures can often be obscure and hard " +"to diagnose (especially when they occur in third party libraries). The two " +"most common sources of problems with this are the fact that importing C " +"extensions from a zip archive is *not* supported by CPython (since doing so " +"is not supported directly by the dynamic loading machinery on any platform) " +"and that when running from a zip archive the ``__file__`` attribute no " +"longer refers to an ordinary filesystem path, but to a combination path that " +"includes both the location of the zip archive on the filesystem and the " +"relative path to the module inside the archive. Even when software correctly " +"uses the abstract resource APIs internally, interfacing with external " +"components may still require the availability of an actual on-disk file." msgstr "" #: ../source/specifications/binary-distribution-format.rst:443 -msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." +msgid "" +"Like metaclasses, monkeypatching and metapath importers, if you're not " +"already sure you need to take advantage of this feature, you almost " +"certainly don't need it. If you *do* decide to use it anyway, be aware that " +"many projects will require a failure to be reproduced with a fully installed " +"package before accepting it as a genuine bug." msgstr "" #: ../source/specifications/binary-distribution-format.rst:450 @@ -6673,11 +9691,15 @@ msgid "Since :pep:`427`, this specification has changed as follows:" msgstr "" #: ../source/specifications/binary-distribution-format.rst:454 -msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." +msgid "" +"The rules on escaping in wheel filenames were revised, to bring them into " +"line with what popular tools actually do (February 2021)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:461 -msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" +msgid "" +"PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-" +"February/124103.html)" msgstr "" #: ../source/specifications/binary-distribution-format.rst:466 @@ -6701,7 +9723,9 @@ msgid "Core metadata specifications" msgstr "" #: ../source/specifications/core-metadata.rst:7 -msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" +msgid "" +"Fields defined in the following specification should be considered valid, " +"complete and not subject to change. The required fields are:" msgstr "" #: ../source/specifications/core-metadata.rst:10 @@ -6721,15 +9745,33 @@ msgid "All the other fields are optional." msgstr "" #: ../source/specifications/core-metadata.rst:16 -msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." +msgid "" +"The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats " +"have been revised several times, and exactly which email RFC applies to " +"packaging metadata is not specified. In the absence of a precise definition, " +"the practical standard is set by what the standard library :mod:`python:" +"email.parser` module can parse using the :data:`~.python:email.policy." +"compat32` policy." msgstr "" #: ../source/specifications/core-metadata.rst:25 -msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." +msgid "" +"Although :pep:`566` defined a way to transform metadata into a JSON-" +"compatible dictionary, this is not yet used as a standard interchange " +"format. The need for tools to work with years worth of existing packages " +"makes it difficult to shift to a new format." msgstr "" #: ../source/specifications/core-metadata.rst:30 -msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." +msgid "" +"*Interpreting old metadata:* In :pep:`566`, the version specifier field " +"format specification was relaxed to accept the syntax used by popular " +"publishing tools (namely to remove the requirement that version specifiers " +"must be surrounded by parentheses). Metadata consumers may want to use the " +"more relaxed formatting rules even for metadata files that are nominally " +"less than version 2.1." msgstr "" #: ../source/specifications/core-metadata.rst:41 @@ -6737,15 +9779,25 @@ msgid "Metadata-Version" msgstr "" #: ../source/specifications/core-metadata.rst:45 -msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." +msgid "" +"Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", " +"\"2.1\" and \"2.2\"." msgstr "" #: ../source/specifications/core-metadata.rst:48 -msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." +msgid "" +"Automated tools consuming metadata SHOULD warn if ``metadata_version`` is " +"greater than the highest version they support, and MUST fail if " +"``metadata_version`` has a greater major version than the highest version " +"they support (as described in :pep:`440`, the major version is the value " +"before the first dot)." msgstr "" #: ../source/specifications/core-metadata.rst:54 -msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." +msgid "" +"For broader compatibility, build tools MAY choose to produce distribution " +"metadata using the lowest metadata version that includes all of the needed " +"fields." msgstr "" #: ../source/specifications/core-metadata.rst:58 @@ -6779,7 +9831,12 @@ msgid "Added additional restrictions on format from :pep:`508`" msgstr "" #: ../source/specifications/core-metadata.rst:72 -msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" +msgid "" +"The name of the distribution. The name field is the primary identifier for a " +"distribution. A valid name consists only of ASCII letters and numbers, " +"period, underscore and hyphen. It must start and end with a letter or " +"number. Distribution names are limited to those which match the following " +"regex (run with ``re.IGNORECASE``)::" msgstr "" #: ../source/specifications/core-metadata.rst:88 @@ -6787,7 +9844,9 @@ msgid "Version" msgstr "版本" #: ../source/specifications/core-metadata.rst:92 -msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." +msgid "" +"A string containing the distribution's version number. This field must be " +"in the format specified in :pep:`440`." msgstr "" #: ../source/specifications/core-metadata.rst:101 @@ -6795,31 +9854,49 @@ msgid "Dynamic (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:105 -msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." +msgid "" +"A string containing the name of another core metadata field. The field names " +"``Name`` and ``Version`` may not be specified in this field." msgstr "" #: ../source/specifications/core-metadata.rst:108 -msgid "When found in the metadata of a source distribution, the following rules apply:" +msgid "" +"When found in the metadata of a source distribution, the following rules " +"apply:" msgstr "" #: ../source/specifications/core-metadata.rst:111 -msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." +msgid "" +"If a field is *not* marked as ``Dynamic``, then the value of the field in " +"any wheel built from the sdist MUST match the value in the sdist. If the " +"field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT " +"be present in the wheel." msgstr "" #: ../source/specifications/core-metadata.rst:115 -msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." +msgid "" +"If a field is marked as ``Dynamic``, it may contain any valid value in a " +"wheel built from the sdist (including not being present at all)." msgstr "" #: ../source/specifications/core-metadata.rst:118 -msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." +msgid "" +"If the sdist metadata version is older than version 2.2, then all fields " +"should be treated as if they were specified with ``Dynamic`` (i.e. there are " +"no special restrictions on the metadata of wheels built from the sdist)." msgstr "" #: ../source/specifications/core-metadata.rst:122 -msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." +msgid "" +"In any context other than a source distribution, ``Dynamic`` is for " +"information only, and indicates that the field value was calculated at wheel " +"build time, and may not be the same as the value in the sdist or in other " +"wheels for the project." msgstr "" #: ../source/specifications/core-metadata.rst:127 -msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." +msgid "" +"Full details of the semantics of ``Dynamic`` are described in :pep:`643`." msgstr "" #: ../source/specifications/core-metadata.rst:131 @@ -6827,7 +9904,10 @@ msgid "Platform (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:135 -msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." +msgid "" +"A Platform specification describing an operating system supported by the " +"distribution which is not listed in the \"Operating System\" Trove " +"classifiers. See \"Classifier\" below." msgstr "" #: ../source/specifications/core-metadata.rst:146 @@ -6835,7 +9915,11 @@ msgid "Supported-Platform (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:150 -msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." +msgid "" +"Binary distributions containing a PKG-INFO file will use the Supported-" +"Platform field in their metadata to specify the OS and CPU for which the " +"binary distribution was compiled. The semantics of the Supported-Platform " +"field are not specified in this PEP." msgstr "" #: ../source/specifications/core-metadata.rst:164 @@ -6851,23 +9935,41 @@ msgid "This field may be specified in the message body instead." msgstr "" #: ../source/specifications/core-metadata.rst:191 -msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." +msgid "" +"A longer description of the distribution that can run to several " +"paragraphs. Software that deals with metadata should not assume any maximum " +"size for this field, though people shouldn't include their instruction " +"manual as the description." msgstr "" #: ../source/specifications/core-metadata.rst:196 -msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." +msgid "" +"The contents of this field can be written using reStructuredText markup " +"[1]_. For programs that work with the metadata, supporting markup is " +"optional; programs can also display the contents of the field as-is. This " +"means that authors should be conservative in the markup they use." msgstr "" #: ../source/specifications/core-metadata.rst:202 -msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." +msgid "" +"To support empty lines and lines with indentation with respect to the RFC " +"822 format, any CRLF character has to be suffixed by 7 spaces followed by a " +"pipe (\"|\") char. As a result, the Description field is encoded into a " +"folded field that can be interpreted by RFC822 parser [2]_." msgstr "" #: ../source/specifications/core-metadata.rst:219 -msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." +msgid "" +"This encoding implies that any occurrences of a CRLF followed by 7 spaces " +"and a pipe char have to be replaced by a single CRLF when the field is " +"unfolded using a RFC822 reader." msgstr "" #: ../source/specifications/core-metadata.rst:223 -msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." +msgid "" +"Alternatively, the distribution's description may instead be provided in the " +"message body (i.e., after a completely blank line following the headers, " +"with no indentation or other special formatting necessary)." msgstr "" #: ../source/specifications/core-metadata.rst:232 @@ -6875,15 +9977,34 @@ msgid "Description-Content-Type" msgstr "" #: ../source/specifications/core-metadata.rst:236 -msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." +msgid "" +"A string stating the markup syntax (if any) used in the distribution's " +"description, so that tools can intelligently render the description." msgstr "" #: ../source/specifications/core-metadata.rst:239 -msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." +msgid "" +"Historically, PyPI supported descriptions in plain text and " +"`reStructuredText (reST) `_, and could render reST into HTML. However, it is " +"common for distribution authors to write the description in `Markdown " +"`_ (`RFC 7763 `_) as many code hosting sites render Markdown " +"READMEs, and authors would reuse the file for the description. PyPI didn't " +"recognize the format and so could not render the description correctly. This " +"resulted in many packages on PyPI with poorly-rendered descriptions when " +"Markdown is left as plain text, or worse, was attempted to be rendered as " +"reST. This field allows the distribution author to specify the format of " +"their description, opening up the possibility for PyPI and other tools to be " +"able to render Markdown and other formats." msgstr "" #: ../source/specifications/core-metadata.rst:253 -msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" +msgid "" +"The format of this field is the same as the ``Content-Type`` header in HTTP " +"(i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then " +"it can optionally have a number of parameters:" msgstr "" #: ../source/specifications/core-metadata.rst:259 @@ -6907,35 +10028,58 @@ msgid "``text/markdown``" msgstr "" #: ../source/specifications/core-metadata.rst:269 -msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." +msgid "" +"The ``charset`` parameter can be used to specify the character encoding of " +"the description. The only legal value is ``UTF-8``. If omitted, it is " +"assumed to be ``UTF-8``." msgstr "" #: ../source/specifications/core-metadata.rst:273 -msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" +msgid "" +"Other parameters might be specific to the chosen subtype. For example, for " +"the ``markdown`` subtype, there is an optional ``variant`` parameter that " +"allows specifying the variant of Markdown in use (defaults to ``GFM`` if not " +"specified). Currently, two variants are recognized:" msgstr "" #: ../source/specifications/core-metadata.rst:278 -msgid "``GFM`` for `Github-flavored Markdown `_" +msgid "" +"``GFM`` for `Github-flavored Markdown `_" msgstr "" #: ../source/specifications/core-metadata.rst:280 -msgid "``CommonMark`` for `CommonMark `_" +msgid "" +"``CommonMark`` for `CommonMark `_" msgstr "" #: ../source/specifications/core-metadata.rst:299 -msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." +msgid "" +"If a ``Description-Content-Type`` is not specified, then applications should " +"attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to " +"``text/plain`` if it is not valid rst." msgstr "" #: ../source/specifications/core-metadata.rst:303 -msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." +msgid "" +"If a ``Description-Content-Type`` is an unrecognized value, then the assumed " +"content type is ``text/plain`` (Although PyPI will probably reject anything " +"with an unrecognized value)." msgstr "" #: ../source/specifications/core-metadata.rst:307 -msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." +msgid "" +"If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is " +"not specified or is set to an unrecognized value, then the assumed " +"``variant`` is ``GFM``." msgstr "" #: ../source/specifications/core-metadata.rst:311 -msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." +msgid "" +"So for the last example above, the ``charset`` defaults to ``UTF-8`` and the " +"``variant`` defaults to ``GFM`` and thus it is equivalent to the example " +"before it." msgstr "" #: ../source/specifications/core-metadata.rst:320 @@ -6943,11 +10087,17 @@ msgid "Keywords" msgstr "" #: ../source/specifications/core-metadata.rst:324 -msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." +msgid "" +"A list of additional keywords, separated by commas, to be used to assist " +"searching for the distribution in a larger catalog." msgstr "" #: ../source/specifications/core-metadata.rst:333 -msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." +msgid "" +"The specification previously showed keywords separated by spaces, but " +"distutils and setuptools implemented it with commas. These tools have been " +"very widely used for many years, so it was easier to update the " +"specification to match the de facto standard." msgstr "" #: ../source/specifications/core-metadata.rst:341 @@ -6963,7 +10113,10 @@ msgid "Download-URL" msgstr "" #: ../source/specifications/core-metadata.rst:357 -msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" +msgid "" +"A string containing the URL from which this version of the distribution can " +"be downloaded. (This means that the URL can't be something like \".../" +"BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" msgstr "" #: ../source/specifications/core-metadata.rst:366 @@ -6971,7 +10124,9 @@ msgid "Author" msgstr "" #: ../source/specifications/core-metadata.rst:370 -msgid "A string containing the author's name at a minimum; additional contact information may be provided." +msgid "" +"A string containing the author's name at a minimum; additional contact " +"information may be provided." msgstr "" #: ../source/specifications/core-metadata.rst:383 @@ -6979,12 +10134,16 @@ msgid "Author-email" msgstr "" #: ../source/specifications/core-metadata.rst:387 -msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgid "" +"A string containing the author's e-mail address. It can contain a name and " +"e-mail address in the legal forms for a RFC-822 ``From:`` header." msgstr "" #: ../source/specifications/core-metadata.rst:395 #: ../source/specifications/core-metadata.rst:442 -msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" +msgid "" +"Per RFC-822, this field may contain multiple comma-separated e-mail " +"addresses::" msgstr "" #: ../source/specifications/core-metadata.rst:405 @@ -6992,11 +10151,16 @@ msgid "Maintainer" msgstr "维护者" #: ../source/specifications/core-metadata.rst:409 -msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." +msgid "" +"A string containing the maintainer's name at a minimum; additional contact " +"information may be provided." msgstr "" #: ../source/specifications/core-metadata.rst:412 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." +msgid "" +"Note that this field is intended for use when a project is being maintained " +"by someone other than the original author: it should be omitted if it is " +"identical to ``Author``." msgstr "" #: ../source/specifications/core-metadata.rst:426 @@ -7004,11 +10168,16 @@ msgid "Maintainer-email" msgstr "" #: ../source/specifications/core-metadata.rst:430 -msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgid "" +"A string containing the maintainer's e-mail address. It can contain a name " +"and e-mail address in the legal forms for a RFC-822 ``From:`` header." msgstr "" #: ../source/specifications/core-metadata.rst:434 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." +msgid "" +"Note that this field is intended for use when a project is being maintained " +"by someone other than the original author: it should be omitted if it is " +"identical to ``Author-email``." msgstr "" #: ../source/specifications/core-metadata.rst:452 @@ -7016,7 +10185,13 @@ msgid "License" msgstr "" #: ../source/specifications/core-metadata.rst:456 -msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." +msgid "" +"Text indicating the license covering the distribution where the license is " +"not a selection from the \"License\" Trove classifiers. See :ref:`" +"\"Classifier\" ` below. This field may also be used to " +"specify a particular version of a license which is named via the " +"``Classifier`` field, or to indicate a variation or exception to such a " +"license." msgstr "" #: ../source/specifications/core-metadata.rst:476 @@ -7024,7 +10199,11 @@ msgid "Classifier (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:480 -msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." +msgid "" +"Each entry is a string giving a single classification value for the " +"distribution. Classifiers are described in :pep:`301`, and the Python " +"Package Index publishes a dynamic list of `currently defined classifiers " +"`__." msgstr "" #: ../source/specifications/core-metadata.rst:485 @@ -7042,11 +10221,15 @@ msgstr "" #: ../source/specifications/core-metadata.rst:561 #: ../source/specifications/core-metadata.rst:663 #: ../source/specifications/core-metadata.rst:704 -msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." +msgid "" +"The field format specification was relaxed to accept the syntax used by " +"popular publishing tools." msgstr "" #: ../source/specifications/core-metadata.rst:503 -msgid "Each entry contains a string naming some other distutils project required by this distribution." +msgid "" +"Each entry contains a string naming some other distutils project required by " +"this distribution." msgstr "" #: ../source/specifications/core-metadata.rst:506 @@ -7054,19 +10237,27 @@ msgid "The format of a requirement string contains from one to four parts:" msgstr "" #: ../source/specifications/core-metadata.rst:508 -msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." +msgid "" +"A project name, in the same format as the ``Name:`` field. The only " +"mandatory part." msgstr "" #: ../source/specifications/core-metadata.rst:510 -msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." +msgid "" +"A comma-separated list of 'extra' names. These are defined by the required " +"project, referring to specific features which may need extra dependencies." msgstr "" #: ../source/specifications/core-metadata.rst:513 -msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." +msgid "" +"A version specifier. Tools parsing the format should accept optional " +"parentheses around this, but tools generating it should not use parentheses." msgstr "" #: ../source/specifications/core-metadata.rst:516 -msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." +msgid "" +"An environment marker after a semicolon. This means that the requirement is " +"only needed in the specified conditions." msgstr "" #: ../source/specifications/core-metadata.rst:519 @@ -7074,11 +10265,15 @@ msgid "See :pep:`508` for full details of the allowed format." msgstr "" #: ../source/specifications/core-metadata.rst:521 -msgid "The project names should correspond to names as found on the `Python Package Index`_." +msgid "" +"The project names should correspond to names as found on the `Python Package " +"Index`_." msgstr "" #: ../source/specifications/core-metadata.rst:524 -msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." +msgid "" +"Version specifiers must follow the rules described in :doc:`version-" +"specifiers`." msgstr "" #: ../source/specifications/core-metadata.rst:538 @@ -7086,7 +10281,10 @@ msgid "Requires-Python" msgstr "" #: ../source/specifications/core-metadata.rst:542 -msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." +msgid "" +"This field specifies the Python version(s) that the distribution is " +"guaranteed to be compatible with. Installation tools may look at this when " +"picking which version of a project to install." msgstr "" #: ../source/specifications/core-metadata.rst:546 @@ -7102,15 +10300,25 @@ msgid "Requires-External (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:565 -msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." +msgid "" +"Each entry contains a string describing some dependency in the system that " +"the distribution is to be used. This field is intended to serve as a hint " +"to downstream project maintainers, and has no semantics which are meaningful " +"to the ``distutils`` distribution." msgstr "" #: ../source/specifications/core-metadata.rst:570 -msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." +msgid "" +"The format of a requirement string is a name of an external dependency, " +"optionally followed by a version declaration within parentheses." msgstr "" #: ../source/specifications/core-metadata.rst:576 -msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." +msgid "" +"Because they refer to non-Python software releases, version numbers for this " +"field are **not** required to conform to the format specified in :pep:" +"`440`: they should correspond to the version scheme used by the external " +"dependency." msgstr "" #: ../source/specifications/core-metadata.rst:581 @@ -7122,7 +10330,9 @@ msgid "Project-URL (multiple-use)" msgstr "" #: ../source/specifications/core-metadata.rst:597 -msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." +msgid "" +"A string containing a browsable URL for the project and a label for it, " +"separated by a comma." msgstr "" #: ../source/specifications/core-metadata.rst:604 @@ -7134,19 +10344,31 @@ msgid "Provides-Extra (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:616 -msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." +msgid "" +"A string containing the name of an optional feature. Must be a valid Python " +"identifier. May be used to make a dependency conditional on whether the " +"optional feature has been requested." msgstr "" #: ../source/specifications/core-metadata.rst:625 -msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." +msgid "" +"A second distribution requires an optional dependency by placing it inside " +"square brackets, and can request multiple features by separating them with a " +"comma (,). The requirements are evaluated for each requested feature and " +"added to the set of requirements for the distribution." msgstr "" #: ../source/specifications/core-metadata.rst:635 -msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." +msgid "" +"Two feature names ``test`` and ``doc`` are reserved to mark dependencies " +"that are needed for running automated tests and generating documentation, " +"respectively." msgstr "" #: ../source/specifications/core-metadata.rst:639 -msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." +msgid "" +"It is legal to specify ``Provides-Extra:`` without referencing it in any " +"``Requires-Dist:``." msgstr "" #: ../source/specifications/core-metadata.rst:644 @@ -7154,11 +10376,21 @@ msgid "Rarely Used Fields" msgstr "" #: ../source/specifications/core-metadata.rst:646 -msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." +msgid "" +"The fields in this section are currently rarely used, as their design was " +"inspired by comparable mechanisms in Linux package management systems, and " +"it isn't at all clear how tools should interpret them in the context of an " +"open index server such as `PyPI `__." msgstr "" #: ../source/specifications/core-metadata.rst:651 -msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." +msgid "" +"As a result, popular installation tools ignore them completely, which in " +"turn means there is little incentive for package publishers to set them " +"appropriately. However, they're retained in the metadata specification, as " +"they're still potentially useful for informational purposes, and can also be " +"used for their originally intended purpose in combination with a curated " +"package repository." msgstr "" #: ../source/specifications/core-metadata.rst:660 @@ -7166,19 +10398,37 @@ msgid "Provides-Dist (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:667 -msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." +msgid "" +"Each entry contains a string naming a Distutils project which is contained " +"within this distribution. This field *must* include the project identified " +"in the ``Name`` field, followed by the version : Name (Version)." msgstr "" #: ../source/specifications/core-metadata.rst:672 -msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." +msgid "" +"A distribution may provide additional names, e.g. to indicate that multiple " +"projects have been bundled together. For instance, source distributions of " +"the ``ZODB`` project have historically included the ``transaction`` project, " +"which is now available as a separate distribution. Installing such a source " +"distribution satisfies requirements for both ``ZODB`` and ``transaction``." msgstr "" #: ../source/specifications/core-metadata.rst:679 -msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." +msgid "" +"A distribution may also provide a \"virtual\" project name, which does not " +"correspond to any separately-distributed project: such a name might be used " +"to indicate an abstract capability which could be supplied by one of " +"multiple projects. E.g., multiple projects might supply RDBMS bindings for " +"use by a given ORM: each project might declare that it provides ``ORM-" +"bindings``, allowing other projects to depend only on having at most one of " +"them installed." msgstr "" #: ../source/specifications/core-metadata.rst:687 -msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." +msgid "" +"A version declaration may be supplied and must follow the rules described " +"in :doc:`version-specifiers`. The distribution's version number will be " +"implied if none is specified." msgstr "" #: ../source/specifications/core-metadata.rst:701 @@ -7186,15 +10436,23 @@ msgid "Obsoletes-Dist (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:708 -msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." +msgid "" +"Each entry contains a string describing a distutils project's distribution " +"which this distribution renders obsolete, meaning that the two projects " +"should not be installed at the same time." msgstr "" #: ../source/specifications/core-metadata.rst:712 -msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." +msgid "" +"Version declarations can be supplied. Version numbers must be in the format " +"specified in :doc:`version-specifiers`." msgstr "" #: ../source/specifications/core-metadata.rst:717 -msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." +msgid "" +"The most common use of this field will be in case a project name changes, e." +"g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install " +"Torqued Python, the Gorgon distribution should be removed." msgstr "" #: ../source/specifications/core-metadata.rst:730 @@ -7210,7 +10468,11 @@ msgid "Declaring build system dependencies" msgstr "" #: ../source/specifications/declaring-build-dependencies.rst:8 -msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." +msgid "" +"`pyproject.toml` is a build system independent file format defined in :pep:" +"`518` that projects may provide in order to declare any Python level " +"dependencies that must be installed in order to run the project's build " +"system successfully." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:5 @@ -7218,15 +10480,31 @@ msgid "Declaring project metadata" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:7 -msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." +msgid "" +":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to " +"consume. It defines the following specification as the canonical source for " +"the format used." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:12 -msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." +msgid "" +"There are two kinds of metadata: *static* and *dynamic*. Static metadata is " +"specified in the ``pyproject.toml`` file directly and cannot be specified or " +"changed by a tool. Dynamic metadata is listed via the ``dynamic`` field " +"(defined later in this specification) and represents metadata that a tool " +"will later provide." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:18 -msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." +msgid "" +"The fields defined in this specification MUST be in a table named " +"``[project]`` in ``pyproject.toml``. No tools may add fields to this table " +"which are not defined by this specification. For tools wishing to store " +"their own settings in ``pyproject.toml``, they may use the ``[tool]`` table " +"as defined in the :ref:`build dependency declaration specification " +"`. The lack of a ``[project]`` table " +"implicitly means the build back-end will dynamically provide all fields." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:27 @@ -7239,7 +10517,9 @@ msgid "``name``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:31 -msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" +msgid "" +"The fields which are required but may be specified *either* statically or " +"listed as dynamic are:" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:34 @@ -7248,7 +10528,9 @@ msgid "``version``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:36 -msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." +msgid "" +"All other fields are considered optional and my be specified statically, " +"listed as dynamic, or left unspecified." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:43 @@ -7259,7 +10541,9 @@ msgid "TOML_ type: string" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:44 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Name `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:47 @@ -7267,11 +10551,15 @@ msgid "The name of the project." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:49 -msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." +msgid "" +"Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it " +"is read for internal consistency." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:57 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Version " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:60 @@ -7287,7 +10575,9 @@ msgid "``description``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:69 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Summary " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:72 @@ -7303,7 +10593,10 @@ msgid "TOML_ type: string or table" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:79 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Description " +"` and :ref:`Description-Content-Type `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:83 @@ -7311,15 +10604,38 @@ msgid "The full description of the project (i.e. the README)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:85 -msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." +msgid "" +"The field accepts either a string or a table. If it is a string then it is a " +"path relative to ``pyproject.toml`` to a text file containing the full " +"description. Tools MUST assume the file's encoding is UTF-8. If the file " +"path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the " +"content-type is ``text/markdown``. If the file path ends in a case-" +"insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-" +"rst``. If a tool recognizes more extensions than this PEP, they MAY infer " +"the content-type for the user without specifying this field as ``dynamic``. " +"For all unrecognized suffixes when a content-type is not provided, tools " +"MUST raise an error." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:96 -msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." +msgid "" +"The ``readme`` field may also take a table. The ``file`` key has a string " +"value representing a path relative to ``pyproject.toml`` to a file " +"containing the full description. The ``text`` key has a string value which " +"is the full description. These keys are mutually-exclusive, thus tools MUST " +"raise an error if the metadata specifies both keys." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:103 -msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." +msgid "" +"A table specified in the ``readme`` field also has a ``content-type`` field " +"which takes a string specifying the content-type of the full description. A " +"tool MUST raise an error if the metadata does not specify this field in the " +"table. If the metadata does not specify the ``charset`` parameter, then it " +"is assumed to be UTF-8. Tools MAY support other encodings if they choose to. " +"Tools MAY support alternative content-types which they can transform to a " +"content-type as supported by the :ref:`core metadata `. " +"Otherwise tools MUST raise an error for unsupported content-types." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:115 @@ -7327,7 +10643,9 @@ msgid "``requires-python``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:118 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Requires-" +"Python `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:121 @@ -7343,11 +10661,19 @@ msgid "TOML_ type: table" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:128 -msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`License " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:131 -msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." +msgid "" +"The table may have one of two keys. The ``file`` key has a string value that " +"is a file path relative to ``pyproject.toml`` to the file which contains the " +"license for the project. Tools MUST assume the file's encoding is UTF-8. The " +"``text`` key has a string value which is the license of the project. These " +"keys are mutually exclusive, so a tool MUST raise an error if the metadata " +"specifies both keys." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:140 @@ -7359,35 +10685,58 @@ msgid "TOML_ type: Array of inline tables with string keys and values" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:143 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:" +"`Maintainer `, and :ref:`Maintainer-email `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:149 -msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." +msgid "" +"The people or organizations considered to be the \"authors\" of the project. " +"The exact meaning is open to interpretation — it may list the original or " +"primary authors, current maintainers, or owners of the package." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:154 -msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." +msgid "" +"The \"maintainers\" field is similar to \"authors\" in that its exact " +"meaning is open to interpretation." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:157 -msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." +msgid "" +"These fields accept an array of tables with 2 keys: ``name`` and ``email``. " +"Both values must be strings. The ``name`` value MUST be a valid email name " +"(i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not " +"contain commas. The ``email`` value MUST be a valid email address. Both keys " +"are optional." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:163 -msgid "Using the data to fill in :ref:`core metadata ` is as follows:" +msgid "" +"Using the data to fill in :ref:`core metadata ` is as follows:" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:166 -msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." +msgid "" +"If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:169 -msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." +msgid "" +"If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:173 -msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." +msgid "" +"If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-" +"email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:177 @@ -7404,7 +10753,9 @@ msgid "TOML_ type: array of strings" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:184 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Keywords " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:187 @@ -7416,7 +10767,9 @@ msgid "``classifiers``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:194 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Classifier " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:197 @@ -7432,11 +10785,15 @@ msgid "TOML_ type: table with keys and values of strings" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:204 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Project-URL " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:207 -msgid "A table of URLs where the key is the URL label and the value is the URL itself." +msgid "" +"A table of URLs where the key is the URL label and the value is the URL " +"itself." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:212 @@ -7444,7 +10801,9 @@ msgid "Entry points" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:214 -msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" +msgid "" +"TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and " +"``[project.entry-points]``)" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:216 @@ -7452,19 +10811,34 @@ msgid ":ref:`Entry points specification `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:218 -msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." +msgid "" +"There are three tables related to entry points. The ``[project.scripts]`` " +"table corresponds to the ``console_scripts`` group in the :ref:`entry points " +"specification `. The key of the table is the name of the entry " +"point and the value is the object reference." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:224 -msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." +msgid "" +"The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group " +"in the :ref:`entry points specification `. Its format is the " +"same as ``[project.scripts]``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:228 -msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." +msgid "" +"The ``[project.entry-points]`` table is a collection of tables. Each sub-" +"table's name is an entry point group. The key and value semantics are the " +"same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but " +"instead keep the entry point groups to only one level deep." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:234 -msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." +msgid "" +"Build back-ends MUST raise an error if the metadata defines a ``[project." +"entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` " +"table, as they would be ambiguous in the face of ``[project.scripts]`` and " +"``[project.gui-scripts]``, respectively." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:242 @@ -7472,11 +10846,16 @@ msgid "``dependencies``/``optional-dependencies``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:244 -msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" +msgid "" +"TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with " +"values of arrays of :pep:`508` strings (``optional-dependencies``)" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:247 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Requires-" +"Dist ` and :ref:`Provides-Extra `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:251 @@ -7484,11 +10863,22 @@ msgid "The (optional) dependencies of the project." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:253 -msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." +msgid "" +"For ``dependencies``, it is a key whose value is an array of strings. Each " +"string represents a dependency of the project and MUST be formatted as a " +"valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist " +"` entry." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:258 -msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." +msgid "" +"For ``optional-dependencies``, it is a table where each key specifies an " +"extra and whose value is an array of strings. The strings of the arrays must " +"be valid :pep:`508` strings. The keys MUST be valid values for :ref:" +"`Provides-Extra `. Each value in the array " +"thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:269 @@ -7500,39 +10890,65 @@ msgid "TOML_ type: array of string" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:272 -msgid "A corresponding :ref:`core metadata ` field does not exist" +msgid "" +"A corresponding :ref:`core metadata ` field does not exist" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:275 -msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." +msgid "" +"Specifies which fields listed by this PEP were intentionally unspecified so " +"another tool can/will provide such metadata dynamically. This clearly " +"delineates which metadata is purposefully unspecified and expected to stay " +"unspecified compared to being provided via tooling later on." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:281 -msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." +msgid "" +"A build back-end MUST honour statically-specified metadata (which means the " +"metadata did not list the field in ``dynamic``)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:283 -msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." +msgid "" +"A build back-end MUST raise an error if the metadata specifies ``name`` in " +"``dynamic``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:285 -msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." +msgid "" +"If the :ref:`core metadata ` specification lists a field as " +"\"Required\", then the metadata MUST specify the field statically or list it " +"in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it " +"should not be possible for a required field to not be listed somehow in the " +"``[project]`` table)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:290 -msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." +msgid "" +"If the :ref:`core metadata ` specification lists a field as " +"\"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is " +"a build back-end will provide the data for the field later." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:294 -msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." +msgid "" +"Build back-ends MUST raise an error if the metadata specifies a field " +"statically as well as being listed in ``dynamic``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:296 -msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." +msgid "" +"If the metadata does not list a field in ``dynamic``, then a build back-end " +"CANNOT fill in the requisite metadata on behalf of the user (i.e. " +"``dynamic`` is the only way to allow a tool to fill in metadata and the user " +"must opt into the filling in)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:300 -msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." +msgid "" +"Build back-ends MUST raise an error if the metadata specifies a field in " +"``dynamic`` but the build back-end was unable to determine the data for it " +"(omitting the data, if determined to be the accurate value, is acceptable)." msgstr "" #: ../source/specifications/dependency-specifiers.rst:6 @@ -7540,11 +10956,15 @@ msgid "Dependency specifiers" msgstr "" #: ../source/specifications/dependency-specifiers.rst:8 -msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." +msgid "" +"The dependency specifier format used to declare a dependency on another " +"component is defined in :pep:`508`." msgstr "" #: ../source/specifications/dependency-specifiers.rst:11 -msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." +msgid "" +"The environment markers section in this PEP supersedes the environment " +"markers section in :pep:`345`." msgstr "" #: ../source/specifications/direct-url.rst:6 @@ -7552,7 +10972,11 @@ msgid "Recording the Direct URL Origin of installed distributions" msgstr "" #: ../source/specifications/direct-url.rst:8 -msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." +msgid "" +"This document specifies a :file:`direct_url.json` file in the :file:`*.dist-" +"info` directory of an installed distribution, to record the Direct URL " +"Origin of the distribution. The layout of this file was originally specified " +"in :pep:`610` and is formally documented here." msgstr "" #: ../source/specifications/direct-url.rst:17 @@ -7560,80 +10984,145 @@ msgid "Specification" msgstr "" #: ../source/specifications/direct-url.rst:19 -msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgid "" +"The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` " +"directory by installers when installing a distribution from a requirement " +"specifying a direct URL reference (including a VCS URL)." msgstr "" #: ../source/specifications/direct-url.rst:23 #: ../source/specifications/recording-installed-packages.rst:206 -msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." +msgid "" +"This file MUST NOT be created when installing a distribution from an other " +"type of requirement (i.e. name plus version specifier)." msgstr "" #: ../source/specifications/direct-url.rst:26 -msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." +msgid "" +"This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." msgstr "" #: ../source/specifications/direct-url.rst:29 -msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." +msgid "" +"If present, it MUST contain at least two fields. The first one is ``url``, " +"with type ``string``. Depending on what ``url`` refers to, the second field " +"MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), " +"``archive_info`` (if ``url`` is a source archives or a wheel), or " +"``dir_info`` (if ``url`` is a local directory). These info fields have a " +"(possibly empty) subdictionary as value, with the possible keys defined " +"below." msgstr "" #: ../source/specifications/direct-url.rst:36 -msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." +msgid "" +"``url`` MUST be stripped of any sensitive authentication information, for " +"security reasons." msgstr "" #: ../source/specifications/direct-url.rst:39 -msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" +msgid "" +"The user:password section of the URL MAY however be composed of environment " +"variables, matching the following regular expression::" msgstr "" #: ../source/specifications/direct-url.rst:45 -msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." +msgid "" +"Additionally, the user:password section of the URL MAY be a well-known, non " +"security sensitive string. A typical example is ``git`` in the case of an " +"URL such as ``ssh://git@gitlab.com/user/repo``." msgstr "" #: ../source/specifications/direct-url.rst:49 -msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" +msgid "" +"When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be " +"present as a dictionary with the following keys:" msgstr "" #: ../source/specifications/direct-url.rst:52 -msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." +msgid "" +"A ``vcs`` key (type ``string``) MUST be present, containing the name of the " +"VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be " +"registered by writing a PEP to amend this specification. The ``url`` value " +"MUST be compatible with the corresponding VCS, so an installer can hand it " +"off without transformation to a checkout/download command of the VCS." msgstr "" #: ../source/specifications/direct-url.rst:58 -msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." +msgid "" +"A ``requested_revision`` key (type ``string``) MAY be present naming a " +"branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to " +"install." msgstr "" #: ../source/specifications/direct-url.rst:61 -msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." +msgid "" +"A ``commit_id`` key (type ``string``) MUST be present, containing the exact " +"commit/revision number that was installed. If the VCS supports commit-hash " +"based revision identifiers, such commit-hash MUST be used as ``commit_id`` " +"in order to reference the immutable version of the source code that was " +"installed." msgstr "" #: ../source/specifications/direct-url.rst:68 -msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" +msgid "" +"When ``url`` refers to a source archive or a wheel, the ``archive_info`` key " +"MUST be present as a dictionary with the following key:" msgstr "" #: ../source/specifications/direct-url.rst:71 -msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." +msgid "" +"A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are " +"unconditionally provided by the latest version of the standard library's " +"``hashlib`` module be used for source archive hashes. At time of writing, " +"that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and " +"'sha512'." msgstr "" #: ../source/specifications/direct-url.rst:78 -msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" +msgid "" +"When ``url`` refers to a local directory, the ``dir_info`` key MUST be " +"present as a dictionary with the following key:" msgstr "" #: ../source/specifications/direct-url.rst:81 -msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." +msgid "" +"``editable`` (type: ``boolean``): ``true`` if the distribution was installed " +"in editable mode, ``false`` otherwise. If absent, default to ``false``." msgstr "" #: ../source/specifications/direct-url.rst:84 -msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." +msgid "" +"When ``url`` refers to a local directory, it MUST have the ``file`` sheme " +"and be compliant with `RFC 8089 `_. In " +"particular, the path component must be absolute. Symbolic links SHOULD be " +"preserved when making relative paths absolute." msgstr "" #: ../source/specifications/direct-url.rst:91 -msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." +msgid "" +"When the requested URL has the file:// scheme and points to a local " +"directory that happens to contain a VCS checkout, installers MUST NOT " +"attempt to infer any VCS information and therefore MUST NOT output any VCS " +"related information (such as ``vcs_info``) in :file:`direct_url.json`." msgstr "" #: ../source/specifications/direct-url.rst:96 -msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." +msgid "" +"A top-level ``subdirectory`` field MAY be present containing a directory " +"path, relative to the root of the VCS repository, source archive or local " +"directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." msgstr "" #: ../source/specifications/direct-url.rst:102 -msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." +msgid "" +"As a general rule, installers should as much as possible preserve the " +"information that was provided in the requested URL when generating :file:" +"`direct_url.json`. For example user:password environment variables should be " +"preserved and ``requested_revision`` should reflect the revision that was " +"provided in the requested URL as faithfully as possible. This information is " +"however *enriched* with more precise data, such as ``commit_id``." msgstr "" #: ../source/specifications/direct-url.rst:110 @@ -7641,7 +11130,14 @@ msgid "Registered VCS" msgstr "" #: ../source/specifications/direct-url.rst:112 -msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." +msgid "" +"This section lists the registered VCS's; expanded, VCS-specific information " +"on how to use the ``vcs``, ``requested_revision``, and other fields of " +"``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY " +"support other VCS's although it is RECOMMENDED to register them by writing a " +"PEP to amend this specification. The ``vcs`` field SHOULD be the command " +"name (lowercased). Additional fields that would be necessary to support such " +"VCS SHOULD be prefixed with the VCS command name." msgstr "" #: ../source/specifications/direct-url.rst:122 @@ -7686,7 +11182,9 @@ msgid "``requested_revision`` field" msgstr "" #: ../source/specifications/direct-url.rst:138 -msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." +msgid "" +"A tag name, branch name, Git ref, commit hash, shortened commit hash, or " +"other commit-ish." msgstr "" #: ../source/specifications/direct-url.rst:141 @@ -7701,7 +11199,11 @@ msgid "A commit hash (40 hexadecimal characters sha1)." msgstr "" #: ../source/specifications/direct-url.rst:147 -msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." +msgid "" +"Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to " +"determine if the ``requested_revision`` corresponds to a Git ref. In turn, a " +"ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning " +"with ``refs/remotes/origin/`` after cloning corresponds to a branch." msgstr "" #: ../source/specifications/direct-url.rst:154 @@ -7760,11 +11262,15 @@ msgid "svn" msgstr "" #: ../source/specifications/direct-url.rst:216 -msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." +msgid "" +"``requested_revision`` must be compatible with ``svn checkout`` ``--" +"revision`` option. In Subversion, branch or tag is part of ``url``." msgstr "" #: ../source/specifications/direct-url.rst:221 -msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." +msgid "" +"Since Subversion does not support globally unique identifiers, this field is " +"the Subversion revision number in the corresponding repository." msgstr "" #: ../source/specifications/direct-url.rst:229 @@ -7804,7 +11310,9 @@ msgid "pip install https://example.com/app-1.0.whl" msgstr "" #: ../source/specifications/direct-url.rst:283 -msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" +msgid "" +"pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup" +"\"" msgstr "" #: ../source/specifications/direct-url.rst:284 @@ -7816,7 +11324,11 @@ msgid "pip install file:///home/user/app" msgstr "" #: ../source/specifications/direct-url.rst:286 -msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" +msgid "" +"pip install --editable \"git+https://example.com/repo/app." +"git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local " +"directory where the git repository has been cloned to, and ``dir_info`` will " +"be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" msgstr "" #: ../source/specifications/direct-url.rst:290 @@ -7840,19 +11352,37 @@ msgid "Entry points specification" msgstr "" #: ../source/specifications/entry-points.rst:7 -msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" +msgid "" +"*Entry points* are a mechanism for an installed distribution to advertise " +"components it provides to be discovered and used by other code. For example:" msgstr "" #: ../source/specifications/entry-points.rst:11 -msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." +msgid "" +"Distributions can specify ``console_scripts`` entry points, each referring " +"to a function. When *pip* (or another console_scripts aware installer) " +"installs the distribution, it will create a command-line wrapper for each " +"entry point." msgstr "" #: ../source/specifications/entry-points.rst:14 -msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." +msgid "" +"Applications can use entry points to load plugins; e.g. Pygments (a syntax " +"highlighting tool) can use additional lexers and styles from separately " +"installed packages. For more about this, see :doc:`/guides/creating-and-" +"discovering-plugins`." msgstr "" #: ../source/specifications/entry-points.rst:19 -msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." +msgid "" +"The entry point file format was originally developed to allow packages built " +"with setuptools to provide integration point metadata that would be read at " +"runtime with ``importlib.metadata``. It is now defined as a PyPA " +"interoperability specification in order to allow build tools other than " +"setuptools to publish ``importlib.metadata`` compatible entry point " +"metadata, and runtime libraries other than ``importlib.metadata`` to " +"portably read published entry point metadata (potentially with different " +"caching and conflict resolution strategies)." msgstr "" #: ../source/specifications/entry-points.rst:28 @@ -7864,27 +11394,61 @@ msgid "Conceptually, an entry point is defined by three required properties:" msgstr "" #: ../source/specifications/entry-points.rst:32 -msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." +msgid "" +"The **group** that an entry point belongs to indicates what sort of object " +"it provides. For instance, the group ``console_scripts`` is for entry points " +"referring to functions which can be used as a command, while ``pygments." +"styles`` is the group for classes defining pygments styles. The consumer " +"typically defines the expected interface. To avoid clashes, consumers " +"defining a new group should use names starting with a PyPI name owned by the " +"consumer project, followed by ``.``. Group names must be one or more groups " +"of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w" +"+)*$``)." msgstr "" #: ../source/specifications/entry-points.rst:42 -msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." +msgid "" +"The **name** identifies this entry point within its group. The precise " +"meaning of this is up to the consumer. For console scripts, the name of the " +"entry point is the command that will be used to launch it. Within a " +"distribution, entry point names should be unique. If different distributions " +"provide the same name, the consumer decides how to handle such conflicts. " +"The name may contain any characters except ``=``, but it cannot start or end " +"with any whitespace character, or start with ``[``. For new entry points, it " +"is recommended to use only letters, numbers, underscores, dots and dashes " +"(regex ``[\\w.-]+``)." msgstr "" #: ../source/specifications/entry-points.rst:51 -msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" +msgid "" +"The **object reference** points to a Python object. It is either in the form " +"``importable.module``, or ``importable.module:object.attr``. Each of the " +"parts delimited by dots and the colon is a valid Python identifier. It is " +"intended to be looked up like this::" msgstr "" #: ../source/specifications/entry-points.rst:64 -msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." +msgid "" +"Some tools call this kind of object reference by itself an 'entry point', " +"for want of a better term, especially where it points to a function to " +"launch a program." msgstr "" #: ../source/specifications/entry-points.rst:68 -msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." +msgid "" +"There is also an optional property: the **extras** are a set of strings " +"identifying optional features of the distribution providing the entry point. " +"If these are specified, the entry point requires the dependencies of those " +"'extras'. See the metadata field :ref:`metadata_provides_extra`." msgstr "" #: ../source/specifications/entry-points.rst:73 -msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." +msgid "" +"Using extras for an entry point is no longer recommended. Consumers should " +"support parsing them from existing distributions, but may then ignore them. " +"New publishing tools need not support specifying extras. The functionality " +"of handling extras was tied to setuptools' model of managing 'egg' packages, " +"but newer tools such as pip and virtualenv use a different model." msgstr "" #: ../source/specifications/entry-points.rst:80 @@ -7892,23 +11456,44 @@ msgid "File format" msgstr "" #: ../source/specifications/entry-points.rst:82 -msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." +msgid "" +"Entry points are defined in a file called :file:`entry_points.txt` in the :" +"file:`*.dist-info` directory of the distribution. This is the directory " +"described in :pep:`376` for installed distributions, and in :pep:`427` for " +"wheels. The file uses the UTF-8 character encoding." msgstr "" #: ../source/specifications/entry-points.rst:87 -msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" +msgid "" +"The file contents are in INI format, as read by Python's :mod:`configparser` " +"module. However, configparser treats names as case-insensitive by default, " +"whereas entry point names are case sensitive. A case-sensitive config parser " +"can be made like this::" msgstr "" #: ../source/specifications/entry-points.rst:97 -msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." +msgid "" +"The entry points file must always use ``=`` to delimit names from values " +"(whereas configparser also allows using ``:``)." msgstr "" #: ../source/specifications/entry-points.rst:100 -msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." +msgid "" +"The sections of the config file represent entry point groups, the names are " +"names, and the values encode both the object reference and the optional " +"extras. If extras are used, they are a comma-separated list inside square " +"brackets." msgstr "" #: ../source/specifications/entry-points.rst:104 -msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." +msgid "" +"Within a value, readers must accept and ignore spaces (including multiple " +"consecutive spaces) before or after the colon, between the object reference " +"and the left square bracket, between the extra names and the square brackets " +"and colons delimiting them, and after the right square bracket. The syntax " +"for extras is formally specified as part of :pep:`508` (as ``extras``). For " +"tools writing the file, it is recommended only to insert a space between the " +"object reference and the left square bracket." msgstr "" #: ../source/specifications/entry-points.rst:112 @@ -7920,23 +11505,47 @@ msgid "Use for scripts" msgstr "" #: ../source/specifications/entry-points.rst:126 -msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." +msgid "" +"Two groups of entry points have special significance in packaging: " +"``console_scripts`` and ``gui_scripts``. In both groups, the name of the " +"entry point should be usable as a command in a system shell after the " +"package is installed. The object reference points to a function which will " +"be called with no arguments when this command is run. The function may " +"return an integer to be used as a process exit code, and returning ``None`` " +"is equivalent to returning ``0``." msgstr "" #: ../source/specifications/entry-points.rst:134 -msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" +msgid "" +"For instance, the entry point ``mycmd = mymod:main`` would create a command " +"``mycmd`` launching a script like this::" msgstr "" #: ../source/specifications/entry-points.rst:141 -msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." +msgid "" +"The difference between ``console_scripts`` and ``gui_scripts`` only affects " +"Windows systems. ``console_scripts`` are wrapped in a console executable, so " +"they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and " +"``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI " +"executable, so they can be started without a console, but cannot use " +"standard streams unless application code redirects them. Other platforms do " +"not have the same distinction." msgstr "" #: ../source/specifications/entry-points.rst:149 -msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." +msgid "" +"Install tools are expected to set up wrappers for both ``console_scripts`` " +"and ``gui_scripts`` in the scripts directory of the install scheme. They are " +"not responsible for putting this directory in the ``PATH`` environment " +"variable which defines where command-line tools are found." msgstr "" #: ../source/specifications/entry-points.rst:154 -msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." +msgid "" +"As files are created from the names, and some filesystems are case-" +"insensitive, packages should avoid using names in these groups which differ " +"only in case. The behaviour of install tools when names differ only in case " +"is undefined." msgstr "" #: ../source/specifications/index.rst:4 @@ -7944,7 +11553,11 @@ msgid "PyPA specifications" msgstr "" #: ../source/specifications/index.rst:6 -msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." +msgid "" +"This is a list of currently active interoperability specifications " +"maintained by the Python Packaging Authority. The process for updating these " +"standards, and for proposing new ones, is documented on `pypa.io `__." msgstr "" #: ../source/specifications/index.rst:13 @@ -7964,11 +11577,16 @@ msgid "Platform compatibility tags" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:8 -msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." +msgid "" +"Platform compatibility tags allow build tools to mark distributions as being " +"compatible with specific platforms, and allows installers to understand " +"which distributions are compatible with the system they are running on." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:12 -msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." +msgid "" +"The platform compatibility tagging model used for the ``wheel`` distribution " +"format is defined in :pep:`425`." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:16 @@ -7976,7 +11594,9 @@ msgid "Platform tags for Windows" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:18 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." +msgid "" +"The scheme defined in :pep:`425` covers public distribution of wheel files " +"to systems running Windows." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:22 @@ -7984,7 +11604,9 @@ msgid "Platform tags for macOS (Mac OS X)" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:24 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." +msgid "" +"The scheme defined in :pep:`425` covers public distribution of wheel files " +"to systems running macOS (previously known as Mac OS X)." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:28 @@ -7992,39 +11614,70 @@ msgid "Platform tags for common Linux distributions" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:32 -msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." +msgid "" +"The scheme defined in :pep:`425` is insufficient for public distribution of " +"wheel files (and \\*nix wheel files in general) to Linux platforms, due to " +"the large ecosystem of Linux platforms and subtle differences between them." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:36 -msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." +msgid "" +"Instead, :pep:`600` defines the ``manylinux`` standard, which represents a " +"common subset of Linux platforms, and allows building wheels tagged with the " +"``manylinux`` platform tag which can be used across most common Linux " +"distributions." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:41 -msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" +msgid "" +"There were multiple iterations of the ``manylinux`` specification, each " +"representing the common subset of Linux platforms at a given point in time:" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:44 -msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." +msgid "" +"``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, " +"and is based on a compatible Linux platform from 2007." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:46 -msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." +msgid "" +"``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` " +"architectures. and updates the previous specification to be based on a " +"compatible Linux platform from 2010 instead." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:49 -msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." +msgid "" +"``manylinux2014`` (:pep:`599`) adds support for a number of additional " +"architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and " +"``s390x``) and updates the base platform to a compatible Linux platform from " +"2014." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:54 -msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." +msgid "" +"``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a " +"future-proof standard. It defines ``x`` and ``y`` as glibc major an minor " +"versions supported (e.g. ``manylinux_2_24`` should work on any distro using " +"glibc 2.24+). Previous tags are still supported for backward compatibility." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:59 -msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." +msgid "" +"In general, distributions built for older versions of the specification are " +"forwards-compatible (meaning that ``manylinux1`` distributions should " +"continue to work on modern systems) but not backwards-compatible (meaning " +"that ``manylinux2010`` distributions are not expected to work on platforms " +"that existed before 2010)." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:65 -msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." +msgid "" +"Package maintainers should attempt to target the most compatible " +"specification possible, with the caveat that the provided build environment " +"for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning " +"that these images will no longer receive security updates." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:71 @@ -8032,15 +11685,21 @@ msgid "Manylinux compatibility support" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:74 -msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." +msgid "" +"The ``manylinux2014`` specification is relatively new and is not yet widely " +"recognised by install tools." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:76 -msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." +msgid "" +"The ``manylinux_x_y`` specification is relatively new and is not yet widely " +"recognised by install tools." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:79 -msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" +msgid "" +"The following table shows the minimum versions of relevant projects to " +"support the various ``manylinux`` standards:" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:83 @@ -8104,7 +11763,11 @@ msgid "Platform tags for other \\*nix platforms" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:92 -msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." +msgid "" +"The scheme defined in :pep:`425` is not generally sufficient for public " +"distribution of wheel files to other \\*nix platforms. Efforts are currently " +"(albeit intermittently) under way to define improved compatibility tagging " +"schemes for AIX and for Alpine Linux." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:98 @@ -8116,7 +11779,11 @@ msgid "The :file:`.pypirc` file" msgstr "" #: ../source/specifications/pypirc.rst:8 -msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." +msgid "" +"A :file:`.pypirc` file allows you to define the configuration for :term:" +"`package indexes ` (referred to here as \"repositories\"), so " +"that you don't have to enter the URL, username, or password whenever you " +"upload a package with :ref:`twine` or :ref:`flit`." msgstr "" #: ../source/specifications/pypirc.rst:13 @@ -8124,7 +11791,9 @@ msgid "The format (originally defined by the :ref:`distutils` package) is:" msgstr "" #: ../source/specifications/pypirc.rst:32 -msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." +msgid "" +"The ``distutils`` section defines an ``index-servers`` field that lists the " +"name of all sections describing a repository." msgstr "" #: ../source/specifications/pypirc.rst:35 @@ -8144,11 +11813,16 @@ msgid "``password``: The password that will used to authenticate the username." msgstr "" #: ../source/specifications/pypirc.rst:43 -msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." +msgid "" +"Be aware that this stores your password in plain text. For better security, " +"consider an alternative like `keyring`_, setting environment variables, or " +"providing the password on the command line." msgstr "" #: ../source/specifications/pypirc.rst:47 -msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" +msgid "" +"Otherwise, set the permissions on :file:`.pypirc` so that only you can view " +"or modify it. For example, on Linux or macOS, run:" msgstr "" #: ../source/specifications/pypirc.rst:57 @@ -8156,15 +11830,23 @@ msgid "Common configurations" msgstr "" #: ../source/specifications/pypirc.rst:61 -msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." +msgid "" +"These examples apply to :ref:`twine`, and projects like :ref:`hatch` that " +"use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`." +"pypirc`, but with different defaults. Please refer to each project's " +"documentation for more details and usage instructions." msgstr "" #: ../source/specifications/pypirc.rst:66 -msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" +msgid "" +"Twine's default configuration mimics a :file:`.pypirc` with repository " +"sections for PyPI and TestPyPI:" msgstr "" #: ../source/specifications/pypirc.rst:82 -msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." +msgid "" +"Twine will add additional configuration from :file:`$HOME/.pypirc`, the " +"command line, and environment variables to this default configuration." msgstr "" #: ../source/specifications/pypirc.rst:86 @@ -8172,11 +11854,15 @@ msgid "Using a PyPI token" msgstr "" #: ../source/specifications/pypirc.rst:88 -msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" +msgid "" +"To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` " +"similar to:" msgstr "" #: ../source/specifications/pypirc.rst:97 -msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." +msgid "" +"For :ref:`TestPyPI `, add a ``[testpypi]`` section, using " +"the API token from your TestPyPI account." msgstr "" #: ../source/specifications/pypirc.rst:103 @@ -8184,11 +11870,16 @@ msgid "Using another package index" msgstr "" #: ../source/specifications/pypirc.rst:105 -msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" +msgid "" +"To configure an additional repository, you'll need to redefine the ``index-" +"servers`` field to include the repository name. Here is a complete example " +"of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" msgstr "" #: ../source/specifications/pypirc.rst:132 -msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" +msgid "" +"Instead of using the ``password`` field, consider saving your API tokens and " +"passwords securely using `keyring`_ (which is installed by Twine):" msgstr "" #: ../source/specifications/recording-installed-packages.rst:5 @@ -8196,11 +11887,20 @@ msgid "Recording installed projects" msgstr "" #: ../source/specifications/recording-installed-packages.rst:7 -msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." +msgid "" +"This document specifies a common format of recording information about " +"Python :term:`projects ` installed in an environment. A common " +"metadata format allows tools to query, manage or uninstall projects, " +"regardless of how they were installed." msgstr "" #: ../source/specifications/recording-installed-packages.rst:12 -msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." +msgid "" +"Almost all information is optional. This allows tools outside the Python " +"ecosystem, such as Linux package managers, to integrate with Python tooling " +"as much as possible. For example, even if an installer cannot easily provide " +"a list of installed files in a format specific to Python tooling, it should " +"still record the name and version of the installed project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:21 @@ -8208,31 +11908,65 @@ msgid "History and change workflow" msgstr "" #: ../source/specifications/recording-installed-packages.rst:23 -msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." +msgid "" +"The metadata described here was first specified in :pep:`376`, and later " +"amended in :pep:`627`. It was formerly known as *Database of Installed " +"Python Distributions*. Further amendments (except trivial language or " +"typography fixes) must be made through the PEP process (see :pep:`1`)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:29 -msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." +msgid "" +"While this document is the normative specification, these PEPs that " +"introduce changes to it may include additional information such as " +"rationales and backwards compatibility considerations." msgstr "" #: ../source/specifications/recording-installed-packages.rst:37 -msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." +msgid "" +"Each project installed from a distribution must, in addition to files, " +"install a \"``.dist-info``\" directory located alongside importable modules " +"and packages (commonly, the ``site-packages`` directory)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:41 -msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." +msgid "" +"This directory is named as ``{name}-{version}.dist-info``, with ``name`` and " +"``version`` fields corresponding to :ref:`core-metadata`. Both fields must " +"be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 " +"<440#normalization>` for the definition of normalization for each field " +"respectively), and replace dash (``-``) characters with underscore (``_``) " +"chacaters, so the ``.dist-info`` directory always has exactly one dash (``-" +"``) character in its stem, separating the ``name`` and ``version`` fields." msgstr "" #: ../source/specifications/recording-installed-packages.rst:50 -msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." +msgid "" +"Historically, tools have failed to replace dot characters or normalize case " +"in the ``name`` field, or not perform normalization in the ``version`` " +"field. Tools consuming ``.dist-info`` directories should expect those fields " +"to be unnormalized, and treat them as equivalent to their normalized " +"counterparts. New tools that write ``.dist-info`` directories MUST normalize " +"both ``name`` and ``version`` fields using the rules described above, and " +"existing tools are encouraged to start normalizing those fields." msgstr "" #: ../source/specifications/recording-installed-packages.rst:60 -msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." +msgid "" +"The ``.dist-info`` directory's name is formatted to unambigiously represent " +"a distribution as a filesystem path. Tools presenting a distribution name to " +"a user should avoid using the normalized name, and instead present the " +"specified name (when needed prior to resolution to an installed package), or " +"read the respective fields in Core Metadata, since values listed there are " +"unescaped and accurately reflect the distribution. Libraries should provide " +"API for such tools to consume, so tools can have access to the unnormalized " +"name when displaying distrubution information." msgstr "" #: ../source/specifications/recording-installed-packages.rst:69 -msgid "This ``.dist-info`` directory can contain these files, described in detail below:" +msgid "" +"This ``.dist-info`` directory can contain these files, described in detail " +"below:" msgstr "" #: ../source/specifications/recording-installed-packages.rst:72 @@ -8244,19 +11978,31 @@ msgid "``RECORD``: records the list of installed files." msgstr "" #: ../source/specifications/recording-installed-packages.rst:74 -msgid "``INSTALLER``: records the name of the tool used to install the project." +msgid "" +"``INSTALLER``: records the name of the tool used to install the project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:76 -msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." +msgid "" +"The ``METADATA`` file is mandatory. All other files may be omitted at the " +"installing tool's discretion. Additional installer-specific files may be " +"present." msgstr "" #: ../source/specifications/recording-installed-packages.rst:82 -msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." +msgid "" +"The :ref:`binary-distribution-format` specification describes additional " +"files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. " +"Such files may be copied to the ``.dist-info`` directory of an installed " +"project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:87 -msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." +msgid "" +"The previous versions of this specification also specified a ``REQUESTED`` " +"file. This file is now considered a tool-specific extension, but may be " +"standardized again in the future. See `PEP 376 `_ for its original meaning." msgstr "" #: ../source/specifications/recording-installed-packages.rst:94 @@ -8264,11 +12010,16 @@ msgid "The METADATA file" msgstr "" #: ../source/specifications/recording-installed-packages.rst:96 -msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." +msgid "" +"The ``METADATA`` file contains metadata as described in the :ref:`core-" +"metadata` specification, version 1.1 or greater." msgstr "" #: ../source/specifications/recording-installed-packages.rst:99 -msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." +msgid "" +"The ``METADATA`` file is mandatory. If it cannot be created, or if required " +"core metadata is not available, installers must report an error and fail to " +"install the project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:105 @@ -8276,11 +12027,15 @@ msgid "The RECORD file" msgstr "" #: ../source/specifications/recording-installed-packages.rst:107 -msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." +msgid "" +"The ``RECORD`` file holds the list of installed files. It is a CSV file " +"containing one record (line) per installed file." msgstr "" #: ../source/specifications/recording-installed-packages.rst:110 -msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" +msgid "" +"The CSV dialect must be readable with the default ``reader`` of Python's " +"``csv`` module:" msgstr "" #: ../source/specifications/recording-installed-packages.rst:113 @@ -8296,31 +12051,56 @@ msgid "line terminator: either ``\\r\\n`` or ``\\n``." msgstr "" #: ../source/specifications/recording-installed-packages.rst:117 -msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." +msgid "" +"Each record is composed of three elements: the file's **path**, the **hash** " +"of the contents, and its **size**." msgstr "" #: ../source/specifications/recording-installed-packages.rst:120 -msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." +msgid "" +"The *path* may be either absolute, or relative to the directory containing " +"the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On " +"Windows, directories may be separated either by forward- or backslashes (``/" +"`` or ``\\``)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:125 -msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." +msgid "" +"The *hash* is either an empty string or the name of a hash algorithm from " +"``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` " +"and the digest of the file's contents, encoded with the urlsafe-base64-nopad " +"encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:130 -msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." +msgid "" +"The *size* is either the empty string, or file's size in bytes, as a base 10 " +"integer." msgstr "" #: ../source/specifications/recording-installed-packages.rst:133 -msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." +msgid "" +"For any file, either or both of the *hash* and *size* fields may be left " +"empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself " +"have empty *hash* and *size*. For other files, leaving the information out " +"is discouraged, as it prevents verifying the integrity of the installed " +"project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:139 -msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." +msgid "" +"If the ``RECORD`` file is present, it must list all installed files of the " +"project, except ``.pyc`` files corresponding to ``.py`` files listed in " +"``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` " +"directory (including the ``RECORD`` file itself) must be listed. Directories " +"should not be listed." msgstr "" #: ../source/specifications/recording-installed-packages.rst:146 -msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." +msgid "" +"To completely uninstall a package, a tool needs to remove all files listed " +"in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding " +"to removed ``.py`` files, and any directories emptied by the uninstallation." msgstr "" #: ../source/specifications/recording-installed-packages.rst:151 @@ -8328,7 +12108,11 @@ msgid "Here is an example snippet of a possible ``RECORD`` file::" msgstr "" #: ../source/specifications/recording-installed-packages.rst:170 -msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" +msgid "" +"If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must " +"not atempt to uninstall or upgrade the package. (This does not apply to " +"tools that rely on other sources of information, such as system package " +"managers in Linux distros.)" msgstr "" #: ../source/specifications/recording-installed-packages.rst:177 @@ -8336,7 +12120,11 @@ msgid "The INSTALLER file" msgstr "" #: ../source/specifications/recording-installed-packages.rst:179 -msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." +msgid "" +"If present, ``INSTALLER`` is a single-line text file naming the tool used to " +"install the project. If the installer is executable from the command line, " +"``INSTALLER`` should contain the command name. Otherwise, it should contain " +"a printable ASCII string." msgstr "" #: ../source/specifications/recording-installed-packages.rst:185 @@ -8348,7 +12136,11 @@ msgid "Here are examples of two possible ``INSTALLER`` files::" msgstr "" #: ../source/specifications/recording-installed-packages.rst:195 -msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." +msgid "" +"This value should be used for informational purposes only. For example, if a " +"tool is asked to uninstall a project but finds no ``RECORD`` file, it may " +"suggest that the tool named in ``INSTALLER`` may be able to do the " +"uninstallation." msgstr "" #: ../source/specifications/recording-installed-packages.rst:201 @@ -8356,7 +12148,9 @@ msgid "The direct_url.json file" msgstr "" #: ../source/specifications/recording-installed-packages.rst:203 -msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgid "" +"This file MUST be created by installers when installing a distribution from " +"a requirement specifying a direct URL reference (including a VCS URL)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:209 @@ -8368,7 +12162,12 @@ msgid "Simple repository API" msgstr "" #: ../source/specifications/simple-repository-api.rst:8 -msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." +msgid "" +"The current interface for querying available package versions and retrieving " +"packages from an index server is defined in :pep:`503`, with the addition of " +"\"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` " +"and specifying the interface version provided by an index server in :pep:" +"`629`." msgstr "" #: ../source/specifications/source-distribution-format.rst:6 @@ -8376,11 +12175,22 @@ msgid "Source distribution format" msgstr "" #: ../source/specifications/source-distribution-format.rst:8 -msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." +msgid "" +"The current standard format of source distribution format is identified by " +"the presence of a :file:`pyproject.toml` file in the distribution archive. " +"The layout of such a distribution was originally specified in :pep:`517` and " +"is formally documented here." msgstr "" #: ../source/specifications/source-distribution-format.rst:13 -msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." +msgid "" +"There is also the legacy source distribution format, implicitly defined by " +"the behaviour of ``distutils`` module in the standard library, when " +"executing :command:`setup.py sdist`. This document does not attempt to " +"standardise this format, except to note that if a legacy source distribution " +"contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it " +"MUST follow the rules applicable to source distributions defined in the " +"metadata specification." msgstr "" #: ../source/specifications/source-distribution-format.rst:21 @@ -8392,11 +12202,18 @@ msgid "Source distribution file name" msgstr "" #: ../source/specifications/source-distribution-format.rst:26 -msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." +msgid "" +"The file name of a sdist is not currently standardised, although the *de " +"facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the " +"canonicalized form of the project name (see :pep:`503` for the " +"canonicalization rules) with ``-`` characters replaced with ``_``, and " +"``{version}`` is the project version." msgstr "" #: ../source/specifications/source-distribution-format.rst:31 -msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." +msgid "" +"The name and version components of the filename MUST match the values stored " +"in the metadata contained in the file." msgstr "" #: ../source/specifications/source-distribution-format.rst:35 @@ -8404,15 +12221,27 @@ msgid "Source distribution file format" msgstr "" #: ../source/specifications/source-distribution-format.rst:37 -msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." +msgid "" +"A ``.tar.gz`` source distribution (sdist) contains a single top-level " +"directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the " +"source files of the package. The name and version MUST match the metadata " +"stored in the file. This directory must also contain a :file:`pyproject." +"toml` in the format defined in :ref:`declaring-build-dependencies`, and a " +"``PKG-INFO`` file containing metadata in the format described in the :ref:" +"`core-metadata` specification. The metadata MUST conform to at least version " +"2.2 of the metadata specification." msgstr "" #: ../source/specifications/source-distribution-format.rst:45 -msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." +msgid "" +"No other content of a sdist is required or defined. Build systems can store " +"whatever information they need in the sdist to build the project." msgstr "" #: ../source/specifications/source-distribution-format.rst:48 -msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." +msgid "" +"The tarball should use the modern POSIX.1-2001 pax tar format, which " +"specifies UTF-8 based file names." msgstr "" #: ../source/specifications/version-specifiers.rst:6 @@ -8420,11 +12249,15 @@ msgid "Version specifiers" msgstr "" #: ../source/specifications/version-specifiers.rst:8 -msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." +msgid "" +"Version numbering requirements and the semantics for specifying comparisons " +"between versions are defined in :pep:`440`." msgstr "" #: ../source/specifications/version-specifiers.rst:11 -msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." +msgid "" +"The version specifiers section in this PEP supersedes the version specifiers " +"section in :pep:`345`." msgstr "" #: ../source/support.rst:3 @@ -8432,22 +12265,30 @@ msgid "How to Get Support" msgstr "如何获得支持" #: ../source/support.rst:5 -msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." +msgid "" +"For support related to a specific project, see the links on the :doc:" +"`Projects ` page." msgstr "" #: ../source/support.rst:8 -msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." +msgid "" +"For something more general, or when you're just not sure, please `open an " +"issue `_ on the " +"`packaging-problems `_ " +"repository on GitHub." msgstr "" -"如果您想了解更多的情况，或者只是不确定，请在 GitHub 上的 `packaging-problems ` 存储库中 `开一个新的 issue `_ 。" +"如果您想了解更多的情况，或者只是不确定，请在 GitHub 上的 `packaging-problems " +"` 存储库中 `开一个新" +"的 issue `_ 。" #: ../source/tutorials/creating-documentation.rst:5 msgid "Creating Documentation" msgstr "创建文档" #: ../source/tutorials/creating-documentation.rst:7 -msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." +msgid "" +"This section covers the basics of how to create documentation using " +"`Sphinx`_ and host the documentation for free in `Read The Docs`_." msgstr "" #: ../source/tutorials/creating-documentation.rst:13 @@ -8459,7 +12300,8 @@ msgid "Use ``pip`` to install Sphinx:" msgstr "" #: ../source/tutorials/creating-documentation.rst:28 -msgid "For other installation methods, see this `installation guide`_ by Sphinx." +msgid "" +"For other installation methods, see this `installation guide`_ by Sphinx." msgstr "" #: ../source/tutorials/creating-documentation.rst:33 @@ -8467,7 +12309,8 @@ msgid "Getting Started With Sphinx" msgstr "" #: ../source/tutorials/creating-documentation.rst:35 -msgid "Create a ``docs`` directory inside your project to hold your documentation:" +msgid "" +"Create a ``docs`` directory inside your project to hold your documentation:" msgstr "" #: ../source/tutorials/creating-documentation.rst:42 @@ -8475,15 +12318,21 @@ msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" msgstr "" #: ../source/tutorials/creating-documentation.rst:49 -msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." +msgid "" +"This sets up a source directory, walks you through some basic " +"configurations, and creates an ``index.rst`` file as well as a ``conf.py`` " +"file." msgstr "" #: ../source/tutorials/creating-documentation.rst:51 -msgid "You can add some information about your project in ``index.rst``, then build them:" +msgid "" +"You can add some information about your project in ``index.rst``, then build " +"them:" msgstr "" #: ../source/tutorials/creating-documentation.rst:57 -msgid "For more details on the build process, see this `guide`_ by Read The Docs." +msgid "" +"For more details on the build process, see this `guide`_ by Read The Docs." msgstr "" #: ../source/tutorials/creating-documentation.rst:62 @@ -8491,11 +12340,16 @@ msgid "Other Sources" msgstr "" #: ../source/tutorials/creating-documentation.rst:64 -msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." +msgid "" +"For a more detailed guide on how to use Sphinx and reStructuredText, please " +"see this `documentation tutorial`_ on Hitchhiker's Guide to Python." msgstr "" #: ../source/tutorials/index.rst:4 -msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." +msgid "" +"**Tutorials** are opinionated step-by-step guides to help you get familiar " +"with packaging concepts. For more detailed information on specific packaging " +"topics, see :doc:`/guides/index`." msgstr "" #: ../source/tutorials/installing-packages.rst:5 @@ -8503,11 +12357,22 @@ msgid "Installing Packages" msgstr "" #: ../source/tutorials/installing-packages.rst:7 -msgid "This section covers the basics of how to install Python :term:`packages `." +msgid "" +"This section covers the basics of how to install Python :term:`packages " +"`." msgstr "" #: ../source/tutorials/installing-packages.rst:10 -msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." +msgid "" +"It's important to note that the term \"package\" in this context is being " +"used to describe a bundle of software to be installed (i.e. as a synonym for " +"a :term:`distribution `). It does not to refer to the " +"kind of :term:`package ` that you import in your Python " +"source code (i.e. a container of modules). It is common in the Python " +"community to refer to a :term:`distribution ` using " +"the term \"package\". Using the term \"distribution\" is often not " +"preferred, because it can easily be confused with a Linux distribution, or " +"another larger software distribution like Python itself." msgstr "" #: ../source/tutorials/installing-packages.rst:28 @@ -8515,7 +12380,9 @@ msgid "Requirements for Installing Packages" msgstr "" #: ../source/tutorials/installing-packages.rst:30 -msgid "This section describes the steps to follow before installing other Python packages." +msgid "" +"This section describes the steps to follow before installing other Python " +"packages." msgstr "" #: ../source/tutorials/installing-packages.rst:35 @@ -8523,11 +12390,16 @@ msgid "Ensure you can run Python from the command line" msgstr "" #: ../source/tutorials/installing-packages.rst:37 -msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" +msgid "" +"Before you go any further, make sure you have Python and that the expected " +"version is available from your command line. You can check this by running:" msgstr "" #: ../source/tutorials/installing-packages.rst:53 -msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." +msgid "" +"You should get some output like ``Python 3.6.3``. If you do not have Python, " +"please install the latest 3.x version from `python.org`_ or refer to the " +"`Installing Python`_ section of the Hitchhiker's Guide to Python." msgstr "" #: ../source/tutorials/installing-packages.rst:57 @@ -8535,19 +12407,37 @@ msgid "If you're a newcomer and you get an error like this:" msgstr "" #: ../source/tutorials/installing-packages.rst:66 -msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." +msgid "" +"It's because this command and other suggested commands in this tutorial are " +"intended to be run in a *shell* (also called a *terminal* or *console*). See " +"the Python for Beginners `getting started tutorial`_ for an introduction to " +"using your operating system's shell and interacting with Python." msgstr "" #: ../source/tutorials/installing-packages.rst:72 -msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" +msgid "" +"If you're using an enhanced shell like IPython or the Jupyter notebook, you " +"can run system commands like those in this tutorial by prefacing them with a " +"``!`` character:" msgstr "" #: ../source/tutorials/installing-packages.rst:82 -msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." +msgid "" +"It's recommended to write ``{sys.executable}`` rather than plain ``python`` " +"in order to ensure that commands are run in the Python installation matching " +"the currently running notebook (which may not be the same Python " +"installation that the ``python`` command refers to)." msgstr "" #: ../source/tutorials/installing-packages.rst:87 -msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." +msgid "" +"Due to the way most Linux distributions are handling the Python 3 migration, " +"Linux users using the system Python without creating a virtual environment " +"first should replace the ``python`` command in this tutorial with " +"``python3`` and the ``python -m pip`` command with ``python3 -m pip --" +"user``. Do *not* run any of the commands in this tutorial with ``sudo``: if " +"you get a permissions error, come back to the section on creating virtual " +"environments, set one up, and then continue with the tutorial as written." msgstr "" #: ../source/tutorials/installing-packages.rst:99 @@ -8555,15 +12445,23 @@ msgid "Ensure you can run pip from the command line" msgstr "" #: ../source/tutorials/installing-packages.rst:101 -msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" +msgid "" +"Additionally, you'll need to make sure you have :ref:`pip` available. You " +"can check this by running:" msgstr "" #: ../source/tutorials/installing-packages.rst:116 -msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." +msgid "" +"If you installed Python from source, with an installer from `python.org`_, " +"or via `Homebrew`_ you should already have pip. If you're on Linux and " +"installed using your OS package manager, you may have to install pip " +"separately, see :doc:`/guides/installing-using-linux-tools`." msgstr "" #: ../source/tutorials/installing-packages.rst:124 -msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" +msgid "" +"If ``pip`` isn't already installed, then first try to bootstrap it from the " +"standard library:" msgstr "" #: ../source/tutorials/installing-packages.rst:139 @@ -8571,15 +12469,24 @@ msgid "If that still doesn't allow you to run ``python -m pip``:" msgstr "" #: ../source/tutorials/installing-packages.rst:141 -msgid "Securely Download `get-pip.py `_ [1]_" +msgid "" +"Securely Download `get-pip.py `_ [1]_" msgstr "" #: ../source/tutorials/installing-packages.rst:144 -msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." +msgid "" +"Run ``python get-pip.py``. [2]_ This will install or upgrade pip. " +"Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're " +"not installed already." msgstr "" #: ../source/tutorials/installing-packages.rst:150 -msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." +msgid "" +"Be cautious if you're using a Python install that's managed by your " +"operating system or another package manager. get-pip.py does not coordinate " +"with those tools, and may leave your system in an inconsistent state. You " +"can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/" +"local`` which is designed for locally-installed software." msgstr "" #: ../source/tutorials/installing-packages.rst:159 @@ -8587,7 +12494,10 @@ msgid "Ensure pip, setuptools, and wheel are up to date" msgstr "" #: ../source/tutorials/installing-packages.rst:161 -msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" +msgid "" +"While ``pip`` alone is sufficient to install from pre-built binary archives, " +"up to date copies of the ``setuptools`` and ``wheel`` projects are useful to " +"ensure you can also install from source archives::" msgstr "" #: ../source/tutorials/installing-packages.rst:169 @@ -8595,11 +12505,17 @@ msgid "Optionally, create a virtual environment" msgstr "" #: ../source/tutorials/installing-packages.rst:171 -msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" +msgid "" +"See :ref:`section below ` for " +"details, but here's the basic `venv`_ [3]_ command to use on a typical Linux " +"system:" msgstr "" #: ../source/tutorials/installing-packages.rst:188 -msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." +msgid "" +"This will create a new virtual environment in the ``tutorial_env`` " +"subdirectory, and configure the current shell to use it as the default " +"``python`` environment." msgstr "" #: ../source/tutorials/installing-packages.rst:195 @@ -8607,35 +12523,62 @@ msgid "Creating Virtual Environments" msgstr "" #: ../source/tutorials/installing-packages.rst:197 -msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." +msgid "" +"Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular " +"application, rather than being installed globally. If you are looking to " +"safely install global command line tools, see :doc:`/guides/installing-stand-" +"alone-command-line-tools`." msgstr "" #: ../source/tutorials/installing-packages.rst:203 -msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." +msgid "" +"Imagine you have an application that needs version 1 of LibFoo, but another " +"application requires version 2. How can you use both these applications? If " +"you install everything into /usr/lib/python3.6/site-packages (or whatever " +"your platform’s standard location is), it’s easy to end up in a situation " +"where you unintentionally upgrade an application that shouldn’t be upgraded." msgstr "" #: ../source/tutorials/installing-packages.rst:209 -msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." +msgid "" +"Or more generally, what if you want to install an application and leave it " +"be? If an application works, any change in its libraries or the versions of " +"those libraries can break the application." msgstr "" #: ../source/tutorials/installing-packages.rst:213 -msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." +msgid "" +"Also, what if you can’t install :term:`packages ` into " +"the global site-packages directory? For instance, on a shared host." msgstr "" #: ../source/tutorials/installing-packages.rst:216 -msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." +msgid "" +"In all these cases, virtual environments can help you. They have their own " +"installation directories and they don’t share libraries with other virtual " +"environments." msgstr "" #: ../source/tutorials/installing-packages.rst:220 -msgid "Currently, there are two common tools for creating Python virtual environments:" +msgid "" +"Currently, there are two common tools for creating Python virtual " +"environments:" msgstr "" #: ../source/tutorials/installing-packages.rst:222 -msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." +msgid "" +"`venv`_ is available by default in Python 3.3 and later, and installs :ref:" +"`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 " +"and later." msgstr "" #: ../source/tutorials/installing-packages.rst:225 -msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." +msgid "" +":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ " +"and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are " +"always installed into created virtual environments by default (regardless of " +"Python version)." msgstr "" #: ../source/tutorials/installing-packages.rst:230 @@ -8651,19 +12594,31 @@ msgid "Using :ref:`virtualenv`:" msgstr "" #: ../source/tutorials/installing-packages.rst:264 -msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." +msgid "" +"For more information, see the `venv`_ docs or the `virtualenv `_ docs." msgstr "" #: ../source/tutorials/installing-packages.rst:266 -msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." +msgid "" +"The use of :command:`source` under Unix shells ensures that the virtual " +"environment's variables are set within the current shell, and not in a " +"subprocess (which then disappears, having no useful effect)." msgstr "" #: ../source/tutorials/installing-packages.rst:271 -msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" +msgid "" +"In both of the above cases, Windows users should _not_ use the :command:" +"`source` command, but should rather run the :command:`activate` script " +"directly from the command shell like so:" msgstr "" #: ../source/tutorials/installing-packages.rst:281 -msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." +msgid "" +"Managing multiple virtual environments directly can become tedious, so the :" +"ref:`dependency management tutorial ` introduces a " +"higher level tool, :ref:`Pipenv`, that automatically manages a separate " +"virtual environment for each project and application that you work on." msgstr "" #: ../source/tutorials/installing-packages.rst:288 @@ -8671,7 +12626,11 @@ msgid "Use pip for Installing" msgstr "" #: ../source/tutorials/installing-packages.rst:290 -msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." +msgid "" +":ref:`pip` is the recommended installer. Below, we'll cover the most common " +"usage scenarios. For more detail, see the `pip docs `_, " +"which includes a complete `Reference Guide `_." msgstr "" #: ../source/tutorials/installing-packages.rst:297 @@ -8679,7 +12638,14 @@ msgid "Installing from PyPI" msgstr "" #: ../source/tutorials/installing-packages.rst:299 -msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." +msgid "" +"The most common usage of :ref:`pip` is to install from the :term:`Python " +"Package Index ` using a :term:`requirement " +"specifier `. Generally speaking, a requirement " +"specifier is composed of a project name followed by an optional :term:" +"`version specifier `. :pep:`440` contains a :pep:`full " +"specification <440#version-specifiers>` of the currently supported " +"specifiers. Below are some examples." msgstr "" #: ../source/tutorials/installing-packages.rst:307 @@ -8695,11 +12661,15 @@ msgid "To install greater than or equal to one version and less than another:" msgstr "" #: ../source/tutorials/installing-packages.rst:350 -msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" +msgid "" +"To install a version that's :pep:`\"compatible\" <440#compatible-release>` " +"with a certain version: [4]_" msgstr "" #: ../source/tutorials/installing-packages.rst:365 -msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." +msgid "" +"In this case, this means to install any version \"==1.4.*\" version that's " +"also \">=1.4.2\"." msgstr "" #: ../source/tutorials/installing-packages.rst:370 @@ -8707,15 +12677,27 @@ msgid "Source Distributions vs Wheels" msgstr "" #: ../source/tutorials/installing-packages.rst:372 -msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." +msgid "" +":ref:`pip` can install from either :term:`Source Distributions (sdist) " +"` or :term:`Wheels `, but if both " +"are present on PyPI, pip will prefer a compatible :term:`wheel `. You " +"can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." msgstr "" #: ../source/tutorials/installing-packages.rst:378 -msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." +msgid "" +":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source " +"Distributions (sdist) `, especially when " +"a project contains compiled extensions." msgstr "" #: ../source/tutorials/installing-packages.rst:383 -msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." +msgid "" +"If :ref:`pip` does not find a wheel to install, it will locally build a " +"wheel and cache it for future installs, instead of rebuilding the source " +"distribution in the future." msgstr "" #: ../source/tutorials/installing-packages.rst:391 @@ -8727,31 +12709,58 @@ msgid "Installing to the User Site" msgstr "" #: ../source/tutorials/installing-packages.rst:410 -msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" +msgid "" +"To install :term:`packages ` that are isolated to the " +"current user, use the ``--user`` flag:" msgstr "" #: ../source/tutorials/installing-packages.rst:425 -msgid "For more information see the `User Installs `_ section from the pip docs." +msgid "" +"For more information see the `User Installs `_ section from the pip docs." msgstr "" #: ../source/tutorials/installing-packages.rst:429 -msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." +msgid "" +"Note that the ``--user`` flag has no effect when inside a virtual " +"environment - all installation commands will affect the virtual environment." msgstr "" #: ../source/tutorials/installing-packages.rst:432 -msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" +msgid "" +"If ``SomeProject`` defines any command-line scripts or console entry points, " +"``--user`` will cause them to be installed inside the `user base`_'s binary " +"directory, which may or may not already be present in your shell's :envvar:" +"`PATH`. (Starting in version 10, pip displays a warning when installing any " +"scripts to a directory outside :envvar:`PATH`.) If the scripts are not " +"available in your shell after installation, you'll need to add the directory " +"to your :envvar:`PATH`:" msgstr "" #: ../source/tutorials/installing-packages.rst:440 -msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." +msgid "" +"On Linux and macOS you can find the user base binary directory by running " +"``python -m site --user-base`` and adding ``bin`` to the end. For example, " +"this will typically print ``~/.local`` (with ``~`` expanded to the absolute " +"path to your home directory) so you'll need to add ``~/.local/bin`` to your " +"``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." msgstr "" #: ../source/tutorials/installing-packages.rst:446 -msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." +msgid "" +"On Windows you can find the user base binary directory by running ``py -m " +"site --user-site`` and replacing ``site-packages`` with ``Scripts``. For " +"example, this could return ``C:\\Users\\Username\\AppData\\Roaming" +"\\Python36\\site-packages`` so you would need to set your ``PATH`` to " +"include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You " +"can set your user ``PATH`` permanently in the `Control Panel`_. You may need " +"to log out for the ``PATH`` changes to take effect." msgstr "" #: ../source/tutorials/installing-packages.rst:462 -msgid "Install a list of requirements specified in a :ref:`Requirements File `." +msgid "" +"Install a list of requirements specified in a :ref:`Requirements File `." msgstr "" #: ../source/tutorials/installing-packages.rst:478 @@ -8759,7 +12768,9 @@ msgid "Installing from VCS" msgstr "" #: ../source/tutorials/installing-packages.rst:480 -msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." +msgid "" +"Install a project from VCS in \"editable\" mode. For a full breakdown of " +"the syntax, see pip's section on :ref:`VCS Support `." msgstr "" #: ../source/tutorials/installing-packages.rst:502 @@ -8771,7 +12782,9 @@ msgid "Install from an alternate index" msgstr "" #: ../source/tutorials/installing-packages.rst:518 -msgid "Search an additional index during install, in addition to :term:`PyPI `" +msgid "" +"Search an additional index during install, in addition to :term:`PyPI " +"`" msgstr "" #: ../source/tutorials/installing-packages.rst:534 @@ -8779,7 +12792,11 @@ msgid "Installing from a local src tree" msgstr "" #: ../source/tutorials/installing-packages.rst:537 -msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." +msgid "" +"Installing from local src in `Development Mode `_, i.e. in such a " +"way that the project appears to be installed, but yet is still editable from " +"the src tree." msgstr "" #: ../source/tutorials/installing-packages.rst:554 @@ -8791,7 +12808,9 @@ msgid "Install a particular source archive file." msgstr "" #: ../source/tutorials/installing-packages.rst:585 -msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" +msgid "" +"Install from a local directory containing archives (and don't check :term:" +"`PyPI `)" msgstr "" #: ../source/tutorials/installing-packages.rst:605 @@ -8799,7 +12818,11 @@ msgid "Installing from other sources" msgstr "" #: ../source/tutorials/installing-packages.rst:607 -msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." +msgid "" +"To install from other data sources (for example Amazon S3 storage) you can " +"create a helper application that presents the data in a :pep:`503` compliant " +"index format, and use the ``--extra-index-url`` flag to direct pip to use " +"that index." msgstr "" #: ../source/tutorials/installing-packages.rst:619 @@ -8807,7 +12830,9 @@ msgid "Installing Prereleases" msgstr "" #: ../source/tutorials/installing-packages.rst:621 -msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." +msgid "" +"Find pre-release and development versions, in addition to stable versions. " +"By default, pip only finds stable versions." msgstr "" #: ../source/tutorials/installing-packages.rst:637 @@ -8819,15 +12844,23 @@ msgid "Install `setuptools extras`_." msgstr "" #: ../source/tutorials/installing-packages.rst:659 -msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." +msgid "" +"\"Secure\" in this context means using a modern browser or a tool like :" +"command:`curl` that verifies SSL certificates when downloading from https " +"URLs." msgstr "" #: ../source/tutorials/installing-packages.rst:668 -msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." +msgid "" +"Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:" +"`virtualenv`) will create virtualenv environments with ``pip`` pre-" +"installed, thereby making it an equal alternative to :ref:`virtualenv`." msgstr "" #: ../source/tutorials/installing-packages.rst:673 -msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" +msgid "" +"The compatible release specifier was accepted in :pep:`440` and support was " +"released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" msgstr "" #: ../source/tutorials/managing-dependencies.rst:4 @@ -8835,23 +12868,42 @@ msgid "Managing Application Dependencies" msgstr "" #: ../source/tutorials/managing-dependencies.rst:6 -msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." +msgid "" +"The :ref:`package installation tutorial ` covered the " +"basics of getting set up to install and update Python packages." msgstr "" #: ../source/tutorials/managing-dependencies.rst:9 -msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." +msgid "" +"However, running these commands interactively can get tedious even for your " +"own personal projects, and things get even more difficult when trying to set " +"up development environments automatically for projects with multiple " +"contributors." msgstr "" #: ../source/tutorials/managing-dependencies.rst:13 -msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." +msgid "" +"This tutorial walks you through the use of :ref:`Pipenv` to manage " +"dependencies for an application. It will show you how to install and use the " +"necessary tools and make strong recommendations on best practices." msgstr "" #: ../source/tutorials/managing-dependencies.rst:17 -msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." +msgid "" +"Keep in mind that Python is used for a great many different purposes, and " +"precisely how you want to manage your dependencies may change based on how " +"you decide to publish your software. The guidance presented here is most " +"directly applicable to the development and deployment of network services " +"(including web applications), but is also very well suited to managing " +"development and testing environments for any kind of project." msgstr "" #: ../source/tutorials/managing-dependencies.rst:24 -msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." +msgid "" +"Developers of Python libraries, or of applications that support distribution " +"as Python libraries, should also consider the `poetry `_ project as an alternative dependency management " +"solution." msgstr "" #: ../source/tutorials/managing-dependencies.rst:30 @@ -8859,7 +12911,12 @@ msgid "Installing Pipenv" msgstr "" #: ../source/tutorials/managing-dependencies.rst:32 -msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." +msgid "" +":ref:`Pipenv` is a dependency manager for Python projects. If you're " +"familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit " +"to those tools. While :ref:`pip` alone is often sufficient for personal use, " +"Pipenv is recommended for collaborative projects as it's a higher-level tool " +"that simplifies dependency management for common use cases." msgstr "" #: ../source/tutorials/managing-dependencies.rst:38 @@ -8867,7 +12924,11 @@ msgid "Use ``pip`` to install Pipenv:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:54 -msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." +msgid "" +"This does a `user installation`_ to prevent breaking any system-wide " +"packages. If ``pipenv`` isn't available in your shell after installation, " +"you'll need to add the `user base`_'s binary directory to your ``PATH``. " +"See :ref:`Installing to the User Site` for more information." msgstr "" #: ../source/tutorials/managing-dependencies.rst:65 @@ -8875,11 +12936,19 @@ msgid "Installing packages for your project" msgstr "" #: ../source/tutorials/managing-dependencies.rst:67 -msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" +msgid "" +"Pipenv manages dependencies on a per-project basis. To install packages, " +"change into your project's directory (or just an empty directory for this " +"tutorial) and run:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:76 -msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" +msgid "" +"Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you " +"in your project's directory. The :ref:`Pipfile` is used to track which " +"dependencies your project needs in case you need to re-install them, such as " +"when you share your project with others. You should get output similar to " +"this (although the exact paths shown will vary):" msgstr "" #: ../source/tutorials/managing-dependencies.rst:112 @@ -8887,7 +12956,9 @@ msgid "Using installed packages" msgstr "" #: ../source/tutorials/managing-dependencies.rst:114 -msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" +msgid "" +"Now that Requests is installed you can create a simple :file:`main.py` file " +"to use it:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:125 @@ -8899,7 +12970,10 @@ msgid "You should get output similar to this:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:137 -msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." +msgid "" +"Using ``pipenv run`` ensures that your installed packages are available to " +"your script. It's also possible to spawn a new shell that ensures all " +"commands have access to your installed packages with ``pipenv shell``." msgstr "" #: ../source/tutorials/managing-dependencies.rst:143 @@ -8908,15 +12982,24 @@ msgid "Next steps" msgstr "" #: ../source/tutorials/managing-dependencies.rst:145 -msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" +msgid "" +"Congratulations, you now know how to effectively manage dependencies and " +"development environments on a collaborative Python project! ✨ 🍰 ✨" msgstr "" #: ../source/tutorials/managing-dependencies.rst:148 -msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." +msgid "" +"If you're interested in creating and distributing your own Python packages, " +"see the :ref:`tutorial on packaging and distributing packages `." msgstr "" #: ../source/tutorials/managing-dependencies.rst:151 -msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." +msgid "" +"Note that when your application includes definitions of Python source " +"packages, they (and their dependencies) can be added to your ``pipenv`` " +"environment with ``pipenv install -e `` " +"(e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." msgstr "" #: ../source/tutorials/managing-dependencies.rst:160 @@ -8924,23 +13007,43 @@ msgid "Other Tools for Application Dependency Management" msgstr "" #: ../source/tutorials/managing-dependencies.rst:162 -msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" +msgid "" +"If you find this particular approach to managing application dependencies " +"isn't working well for you or your use case, you may want to explore these " +"other tools and techniques to see if one of them is a better fit:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:166 -msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." +msgid "" +"`poetry `__ for a tool comparable " +"in scope to ``pipenv`` that focuses more directly on use cases where the " +"repository being managed is structured as a Python project with a valid " +"``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making " +"the assumption that the application being worked on that's depending on " +"components from PyPI will itself support distribution as a ``pip``-" +"installable Python package)." msgstr "" #: ../source/tutorials/managing-dependencies.rst:172 -msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" +msgid "" +"`hatch `_ for opinionated coverage of even " +"more steps in the project management workflow (such as incrementing " +"versions, tagging releases, and creating new skeleton projects from project " +"templates)" msgstr "" #: ../source/tutorials/managing-dependencies.rst:175 -msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" +msgid "" +"`pip-tools `_ to build your own " +"custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" msgstr "" #: ../source/tutorials/managing-dependencies.rst:177 -msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." +msgid "" +"`micropipenv `_ is a " +"lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry " +"lock files or converting them to pip-tools compatible output. Designed for " +"containerized Python applications but not limited to them." msgstr "" #: ../source/tutorials/packaging-projects.rst:2 @@ -8948,15 +13051,24 @@ msgid "Packaging Python Projects" msgstr "" #: ../source/tutorials/packaging-projects.rst:4 -msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." +msgid "" +"This tutorial walks you through how to package a simple Python project. It " +"will show you how to add the necessary files and structure to create the " +"package, how to build the package, and how to upload it to the Python " +"Package Index." msgstr "" #: ../source/tutorials/packaging-projects.rst:10 -msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" +msgid "" +"If you have trouble running the commands in this tutoral, please copy the " +"command and its output, then `open an issue`_ on the `packaging-problems`_ " +"repository on GitHub. We'll do our best to help you!" msgstr "" #: ../source/tutorials/packaging-projects.rst:18 -msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" +msgid "" +"Some of the commands require a newer version of :ref:`pip`, so start by " +"making sure you have the latest version installed:" msgstr "" #: ../source/tutorials/packaging-projects.rst:35 @@ -8964,7 +13076,10 @@ msgid "A simple project" msgstr "" #: ../source/tutorials/packaging-projects.rst:37 -msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." +msgid "" +"This tutorial uses a simple project named ``example_package``. We recommend " +"following this tutorial as-is using this project, before packaging your own " +"project." msgstr "" #: ../source/tutorials/packaging-projects.rst:41 @@ -8972,19 +13087,29 @@ msgid "Create the following file structure locally:" msgstr "" #: ../source/tutorials/packaging-projects.rst:51 -msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." +msgid "" +":file:`__init__.py` is required to import the directory as a package, and " +"should be empty." msgstr "" #: ../source/tutorials/packaging-projects.rst:54 -msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" +msgid "" +":file:`example.py` is an example of a module within the package that could " +"contain the logic (functions, classes, constants, etc.) of your package. " +"Open that file and enter the following content:" msgstr "" #: ../source/tutorials/packaging-projects.rst:63 -msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." +msgid "" +"If you are unfamiliar with Python's :term:`modules ` and :term:" +"`import packages `, take a few minutes to read over the " +"`Python documentation for packages and modules`_." msgstr "" #: ../source/tutorials/packaging-projects.rst:67 -msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." +msgid "" +"Once you create this structure, you'll want to run all of the commands in " +"this tutorial within the ``packaging_tutorial`` directory." msgstr "" #: ../source/tutorials/packaging-projects.rst:75 @@ -8992,7 +13117,9 @@ msgid "Creating the package files" msgstr "" #: ../source/tutorials/packaging-projects.rst:77 -msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" +msgid "" +"You will now add files that are used to prepare the project for " +"distribution. When you're done, the project structure will look like this:" msgstr "" #: ../source/tutorials/packaging-projects.rst:95 @@ -9008,15 +13135,26 @@ msgid "Creating pyproject.toml" msgstr "" #: ../source/tutorials/packaging-projects.rst:103 -msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" +msgid "" +":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) " +"what is required to build your project. This tutorial uses :ref:" +"`setuptools`, so open :file:`pyproject.toml` and enter the following content:" msgstr "" #: ../source/tutorials/packaging-projects.rst:117 -msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." +msgid "" +"``build-system.requires`` gives a list of packages that are needed to build " +"your package. Listing something here will *only* make it available during " +"the build, not after it is installed." msgstr "" #: ../source/tutorials/packaging-projects.rst:121 -msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." +msgid "" +"``build-system.build-backend`` is the name of Python object that will be " +"used to perform the build. If you were to use a different build system, such " +"as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration " +"details would be completely different than the :ref:`setuptools` " +"configuration described below." msgstr "" #: ../source/tutorials/packaging-projects.rst:127 @@ -9032,41 +13170,74 @@ msgid "There are two types of metadata: static and dynamic." msgstr "" #: ../source/tutorials/packaging-projects.rst:135 -msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." +msgid "" +"Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. " +"This is simpler, easier to read, and avoids many common errors, like " +"encoding errors." msgstr "" #: ../source/tutorials/packaging-projects.rst:137 -msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." +msgid "" +"Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items " +"that are dynamic or determined at install-time, as well as extension modules " +"or extensions to setuptools, need to go into :file:`setup.py`." msgstr "" #: ../source/tutorials/packaging-projects.rst:141 -msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." +msgid "" +"Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:" +"file:`setup.py`) should be used only as an escape hatch when absolutely " +"necessary. :file:`setup.py` used to be required, but can be omitted with " +"newer versions of setuptools and pip." msgstr "" #: ../source/tutorials/packaging-projects.rst:148 -msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." +msgid "" +":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells " +"setuptools about your package (such as the name and version) as well as " +"which code files to include. Eventually much of this configuration may be " +"able to move to :file:`pyproject.toml`." msgstr "" #: ../source/tutorials/packaging-projects.rst:153 -msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgid "" +"Open :file:`setup.cfg` and enter the following content. Change the ``name`` " +"to include your username; this ensures that you have a unique package name " +"and that your package doesn't conflict with packages uploaded by other " +"people following this tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:185 -msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" +msgid "" +"There are a `variety of metadata and options `_ supported here. This is " +"in :doc:`configparser ` format; do not place " +"quotes around values. This example package uses a relatively minimal set of " +"``metadata``:" msgstr "" #: ../source/tutorials/packaging-projects.rst:191 #: ../source/tutorials/packaging-projects.rst:286 -msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." +msgid "" +"``name`` is the *distribution name* of your package. This can be any name as " +"long as it only contains letters, numbers, ``_`` , and ``-``. It also must " +"not already be taken on pypi.org. **Be sure to update this with your " +"username,** as this ensures you won't try to upload a package with the same " +"name as one which already exists." msgstr "" #: ../source/tutorials/packaging-projects.rst:196 -msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." +msgid "" +"``version`` is the package version. See :pep:`440` for more details on " +"versions. You can use ``file:`` or ``attr:`` directives to read from a file " +"or package attribute." msgstr "" #: ../source/tutorials/packaging-projects.rst:199 #: ../source/tutorials/packaging-projects.rst:293 -msgid "``author`` and ``author_email`` are used to identify the author of the package." +msgid "" +"``author`` and ``author_email`` are used to identify the author of the " +"package." msgstr "" #: ../source/tutorials/packaging-projects.rst:201 @@ -9075,27 +13246,45 @@ msgid "``description`` is a short, one-sentence summary of the package." msgstr "" #: ../source/tutorials/packaging-projects.rst:202 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." +msgid "" +"``long_description`` is a detailed description of the package. This is shown " +"on the package detail page on the Python Package Index. In this case, the " +"long description is loaded from :file:`README.md` (which is a common " +"pattern) using the ``file:`` directive." msgstr "" #: ../source/tutorials/packaging-projects.rst:206 #: ../source/tutorials/packaging-projects.rst:300 -msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." +msgid "" +"``long_description_content_type`` tells the index what type of markup is " +"used for the long description. In this case, it's Markdown." msgstr "" #: ../source/tutorials/packaging-projects.rst:208 #: ../source/tutorials/packaging-projects.rst:302 -msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." +msgid "" +"``url`` is the URL for the homepage of the project. For many projects, this " +"will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting " +"service." msgstr "" #: ../source/tutorials/packaging-projects.rst:211 #: ../source/tutorials/packaging-projects.rst:305 -msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." +msgid "" +"``project_urls`` lets you list any number of extra links to show on PyPI. " +"Generally this could be to documentation, issue trackers, etc." msgstr "" #: ../source/tutorials/packaging-projects.rst:213 #: ../source/tutorials/packaging-projects.rst:307 -msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." +msgid "" +"``classifiers`` gives the index and :ref:`pip` some additional metadata " +"about your package. In this case, the package is only compatible with Python " +"3, is licensed under the MIT license, and is OS-independent. You should " +"always include at least which version(s) of Python your package works on, " +"which license your package is available under, and which operating systems " +"your package will work on. For a complete list of classifiers, see https://" +"pypi.org/classifiers/." msgstr "" #: ../source/tutorials/packaging-projects.rst:221 @@ -9103,52 +13292,96 @@ msgid "In the ``options`` category, we have controls for setuptools itself:" msgstr "" #: ../source/tutorials/packaging-projects.rst:223 -msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgid "" +"``package_dir`` is a mapping of package names and directories. An empty " +"package name represents the \"root package\" --- the directory in the " +"project that contains all Python source files for the package --- so in this " +"case the ``src`` directory is designated the root package." msgstr "" #: ../source/tutorials/packaging-projects.rst:227 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgid "" +"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " +"`. Instead of listing each package manually, we can " +"use the ``find:`` directive to automatically discover all packages and " +"subpackages and ``options.packages.find`` to specify the ``package_dir`` to " +"use. In this case, the list of packages will be ``example_package`` as " +"that's the only package present." msgstr "" #: ../source/tutorials/packaging-projects.rst:234 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." +msgid "" +"``python_requires`` gives the versions of Python supported by your project. " +"Installers like :ref:`pip` will look back through older versions of packages " +"until it finds one that has a matching Python version." msgstr "" #: ../source/tutorials/packaging-projects.rst:238 #: ../source/tutorials/packaging-projects.rst:329 -msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." +msgid "" +"There are many more than the ones mentioned here. See :doc:`/guides/" +"distributing-packages-using-setuptools` for more details." msgstr "" #: ../source/tutorials/packaging-projects.rst:244 -msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." +msgid "" +":file:`setup.py` is the build script for :ref:`setuptools`. It tells " +"setuptools about your package (such as the name and version) as well as " +"which code files to include." msgstr "" #: ../source/tutorials/packaging-projects.rst:248 -msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgid "" +"Open :file:`setup.py` and enter the following content. Change the ``name`` " +"to include your username; this ensures that you have a unique package name " +"and that your package doesn't conflict with packages uploaded by other " +"people following this tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:283 -msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" +msgid "" +":func:`setup` takes several arguments. This example package uses a " +"relatively minimal set:" msgstr "" #: ../source/tutorials/packaging-projects.rst:291 -msgid "``version`` is the package version. See :pep:`440` for more details on versions." +msgid "" +"``version`` is the package version. See :pep:`440` for more details on " +"versions." msgstr "" #: ../source/tutorials/packaging-projects.rst:296 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." +msgid "" +"``long_description`` is a detailed description of the package. This is shown " +"on the package detail page on the Python Package Index. In this case, the " +"long description is loaded from :file:`README.md`, which is a common pattern." msgstr "" #: ../source/tutorials/packaging-projects.rst:314 -msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgid "" +"``package_dir`` is a dictionary with package names for keys and directories " +"for values. An empty package name represents the \"root package\" --- the " +"directory in the project that contains all Python source files for the " +"package --- so in this case the ``src`` directory is designated the root " +"package." msgstr "" #: ../source/tutorials/packaging-projects.rst:319 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgid "" +"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " +"`. Instead of listing each package manually, we can " +"use :func:`find_packages` to automatically discover all packages and " +"subpackages under ``package_dir``. In this case, the list of packages will " +"be ``example_package`` as that's the only package present." msgstr "" #: ../source/tutorials/packaging-projects.rst:325 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." +msgid "" +"``python_requires`` gives the versions of Python supported by your project. " +"Installers like :ref:`pip` will look back though older versions of packages " +"until it finds one that has a matching Python version." msgstr "" #: ../source/tutorials/packaging-projects.rst:333 @@ -9156,11 +13389,17 @@ msgid "Creating README.md" msgstr "" #: ../source/tutorials/packaging-projects.rst:335 -msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." +msgid "" +"Open :file:`README.md` and enter the following content. You can customize " +"this if you'd like." msgstr "" #: ../source/tutorials/packaging-projects.rst:347 -msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." +msgid "" +"Because our configuration loads :file:`README.md` to provide a " +"``long_description``, :file:`README.md` must be included along with your " +"code when you :ref:`generate a source distribution `. " +"Newer versions of :ref:`setuptools` will do this automatically." msgstr "" #: ../source/tutorials/packaging-projects.rst:354 @@ -9168,7 +13407,12 @@ msgid "Creating a LICENSE" msgstr "" #: ../source/tutorials/packaging-projects.rst:356 -msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" +msgid "" +"It's important for every package uploaded to the Python Package Index to " +"include a license. This tells users who install your package the terms under " +"which they can use your package. For help picking a license, see https://" +"choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` " +"and enter the license text. For example, if you had chosen the MIT license:" msgstr "" #: ../source/tutorials/packaging-projects.rst:387 @@ -9176,11 +13420,19 @@ msgid "Including other files" msgstr "" #: ../source/tutorials/packaging-projects.rst:389 -msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." +msgid "" +"The files listed above will be included automatically in your :term:`source " +"distribution `. If you want to control " +"what goes in this explicitly, see :ref:`Using MANIFEST.in`." msgstr "" #: ../source/tutorials/packaging-projects.rst:393 -msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." +msgid "" +"The final :term:`built distribution ` will have the " +"Python files in the discovered or listed Python packages. If you want to " +"control what goes here, such as to add data files, see :doc:`Including Data " +"Files ` from the :doc:`setuptools docs " +"`." msgstr "" #: ../source/tutorials/packaging-projects.rst:402 @@ -9188,7 +13440,10 @@ msgid "Generating distribution archives" msgstr "" #: ../source/tutorials/packaging-projects.rst:404 -msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." +msgid "" +"The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the " +"Python Package Index and can be installed by :ref:`pip`." msgstr "" #: ../source/tutorials/packaging-projects.rst:408 @@ -9196,19 +13451,32 @@ msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" msgstr "" #: ../source/tutorials/packaging-projects.rst:422 -msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." +msgid "" +"If you have trouble installing these, see the :doc:`installing-packages` " +"tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:425 -msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" +msgid "" +"Now run this command from the same directory where :file:`pyproject.toml` is " +"located:" msgstr "" #: ../source/tutorials/packaging-projects.rst:439 -msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" +msgid "" +"This command should output a lot of text and once completed should generate " +"two files in the :file:`dist` directory:" msgstr "" #: ../source/tutorials/packaging-projects.rst:449 -msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." +msgid "" +"The ``tar.gz`` file is a :term:`source archive ` whereas the " +"``.whl`` file is a :term:`built distribution `. Newer :" +"ref:`pip` versions preferentially install built distributions, but will fall " +"back to source archives if needed. You should always upload a source archive " +"and provide built archives for the platforms your project is compatible " +"with. In this case, our example package is compatible with Python on any " +"platform so only one built distribution is needed." msgstr "" #: ../source/tutorials/packaging-projects.rst:458 @@ -9220,23 +13488,40 @@ msgid "Finally, it's time to upload your package to the Python Package Index!" msgstr "" #: ../source/tutorials/packaging-projects.rst:462 -msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." +msgid "" +"The first thing you'll need to do is register an account on TestPyPI, which " +"is a separate instance of the package index intended for testing and " +"experimentation. It's great for things like this tutorial where we don't " +"necessarily want to upload to the real index. To register an account, go to " +"https://test.pypi.org/account/register/ and complete the steps on that page. " +"You will also need to verify your email address before you're able to upload " +"any packages. For more details, see :doc:`/guides/using-testpypi`." msgstr "" #: ../source/tutorials/packaging-projects.rst:470 -msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgid "" +"To securely upload your project, you'll need a PyPI `API token`_. Create one " +"at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" " +"to \"Entire account\". **Don't close the page until you have copied and " +"saved the token — you won't see that token again.**" msgstr "" #: ../source/tutorials/packaging-projects.rst:477 -msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" +msgid "" +"Now that you are registered, you can use :ref:`twine` to upload the " +"distribution packages. You'll need to install Twine:" msgstr "" #: ../source/tutorials/packaging-projects.rst:492 -msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" +msgid "" +"Once installed, run Twine to upload all of the archives under :file:`dist`:" msgstr "" #: ../source/tutorials/packaging-projects.rst:506 -msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." +msgid "" +"You will be prompted for a username and password. For the username, use " +"``__token__``. For the password, use the token value, including the ``pypi-" +"`` prefix." msgstr "" #: ../source/tutorials/packaging-projects.rst:510 @@ -9244,7 +13529,9 @@ msgid "After the command completes, you should see output similar to this:" msgstr "" #: ../source/tutorials/packaging-projects.rst:523 -msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" +msgid "" +"Once uploaded your package should be viewable on TestPyPI, for example, " +"https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" msgstr "" #: ../source/tutorials/packaging-projects.rst:528 @@ -9252,7 +13539,10 @@ msgid "Installing your newly uploaded package" msgstr "" #: ../source/tutorials/packaging-projects.rst:530 -msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" +msgid "" +"You can use :ref:`pip` to install your package and verify that it works. " +"Create a :ref:`virtual environment ` and install your package from TestPyPI:" msgstr "" #: ../source/tutorials/packaging-projects.rst:546 @@ -9260,15 +13550,25 @@ msgid "Make sure to specify your username in the package name!" msgstr "" #: ../source/tutorials/packaging-projects.rst:548 -msgid "pip should install the package from TestPyPI and the output should look something like this:" +msgid "" +"pip should install the package from TestPyPI and the output should look " +"something like this:" msgstr "" #: ../source/tutorials/packaging-projects.rst:558 -msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." +msgid "" +"This example uses ``--index-url`` flag to specify TestPyPI instead of live " +"PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have " +"the same packages as the live PyPI, it's possible that attempting to install " +"dependencies may fail or install something unexpected. While our example " +"package doesn't have any dependencies, it's a good practice to avoid " +"installing dependencies when using TestPyPI." msgstr "" #: ../source/tutorials/packaging-projects.rst:565 -msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" +msgid "" +"You can test that it was installed correctly by importing the package. Make " +"sure you're still in your virtual environment, then run Python:" msgstr "" #: ../source/tutorials/packaging-projects.rst:580 @@ -9276,43 +13576,70 @@ msgid "and import the package:" msgstr "" #: ../source/tutorials/packaging-projects.rst:588 -msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." +msgid "" +"Note that the :term:`import package ` is ``example_package`` " +"regardless of what ``name`` you gave your :term:`distribution package " +"` in :file:`setup.cfg` or :file:`setup.py` (in this " +"case, ``example-pkg-YOUR-USERNAME-HERE``)." msgstr "" #: ../source/tutorials/packaging-projects.rst:596 -msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" +msgid "" +"**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" msgstr "" #: ../source/tutorials/packaging-projects.rst:599 -msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." +msgid "" +"Keep in mind that this tutorial showed you how to upload your package to " +"Test PyPI, which isn't a permanent storage. The Test system occasionally " +"deletes packages and accounts. It is best to use TestPyPI for testing and " +"experiments like this tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:604 -msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" +msgid "" +"When you are ready to upload a real package to the Python Package Index you " +"can do much the same as you did in this tutorial, but with these important " +"differences:" msgstr "" #: ../source/tutorials/packaging-projects.rst:608 -msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." +msgid "" +"Choose a memorable and unique name for your package. You don't have to " +"append your username as you did in the tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:610 -msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." +msgid "" +"Register an account on https://pypi.org - note that these are two separate " +"servers and the login details from the test server are not shared with the " +"main server." msgstr "" #: ../source/tutorials/packaging-projects.rst:613 -msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." +msgid "" +"Use ``twine upload dist/*`` to upload your package and enter your " +"credentials for the account you registered on the real PyPI. Now that " +"you're uploading the package in production, you don't need to specify ``--" +"repository``; the package will upload to https://pypi.org/ by default." msgstr "" #: ../source/tutorials/packaging-projects.rst:617 -msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." +msgid "" +"Install your package from the real PyPI using ``python3 -m pip install [your-" +"package]``." msgstr "" #: ../source/tutorials/packaging-projects.rst:619 -msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" +msgid "" +"At this point if you want to read more on packaging Python libraries here " +"are some things you can do:" msgstr "" #: ../source/tutorials/packaging-projects.rst:622 -msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." +msgid "" +"Read more about using :ref:`setuptools` to package libraries in :doc:`/" +"guides/distributing-packages-using-setuptools`." msgstr "" #: ../source/tutorials/packaging-projects.rst:624 @@ -9320,5 +13647,7 @@ msgid "Read about :doc:`/guides/packaging-binary-extensions`." msgstr "" #: ../source/tutorials/packaging-projects.rst:625 -msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." +msgid "" +"Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:" +"`hatch`, and :ref:`poetry`." msgstr "" diff --git a/locales/zh_Hant/LC_MESSAGES/messages.po b/locales/zh_Hant/LC_MESSAGES/messages.po index 13b3b6ab0..a63941efd 100644 --- a/locales/zh_Hant/LC_MESSAGES/messages.po +++ b/locales/zh_Hant/LC_MESSAGES/messages.po @@ -24,7 +24,9 @@ msgid "Contribute to this guide" msgstr "為本指南做出貢獻" #: ../source/contribute.rst:7 -msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" +msgid "" +"The |PyPUG| welcomes contributors! There are lots of ways to help out, " +"including:" msgstr "|PyPUG| 歡迎貢獻者！有很多方法可以提供幫助，包括：" #: ../source/contribute.rst:10 @@ -44,11 +46,17 @@ msgid "Writing new content" msgstr "編寫新內容" #: ../source/contribute.rst:15 -msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." +msgid "" +"Most of the work on the |PyPUG| takes place on the `project's GitHub " +"repository`__. To get started, check out the list of `open issues`__ and " +"`pull requests`__. If you're planning to write or edit the guide, please " +"read the :ref:`style guide `." msgstr "" #: ../source/contribute.rst:24 -msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." +msgid "" +"By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of " +"Conduct`__." msgstr "如果你打算為 |PyPUG| 作出貢獻，你就應該遵守 PSF 的 `行為守則`__。" #: ../source/contribute.rst:31 @@ -56,34 +64,46 @@ msgid "Documentation types" msgstr "文件類型" #: ../source/contribute.rst:33 -msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." +msgid "" +"This project consists of four distinct documentation types with specific " +"purposes. When proposing new additions to the project please pick the " +"appropriate documentation type." msgstr "" -#: ../source/contribute.rst:38 -#: ../source/tutorials/index.rst:2 +#: ../source/contribute.rst:38 ../source/tutorials/index.rst:2 msgid "Tutorials" msgstr "教學" #: ../source/contribute.rst:40 -msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." +msgid "" +"Tutorials are focused on teaching the reader new concepts by accomplishing a " +"goal. They are opinionated step-by-step guides. They do not include " +"extraneous warnings or information. `example tutorial-style document`_." msgstr "" -#: ../source/contribute.rst:47 -#: ../source/guides/index.rst:2 +#: ../source/contribute.rst:47 ../source/guides/index.rst:2 msgid "Guides" msgstr "指南" #: ../source/contribute.rst:49 -msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." +msgid "" +"Guides are focused on accomplishing a specific task and can assume some " +"level of pre-requisite knowledge. These are similar to tutorials, but have a " +"narrow and clear focus and can provide lots of caveats and additional " +"information as needed. They may also discuss multiple approaches to " +"accomplishing the task. :doc:`example guide-style document `." msgstr "" -#: ../source/contribute.rst:56 -#: ../source/discussions/index.rst:2 +#: ../source/contribute.rst:56 ../source/discussions/index.rst:2 msgid "Discussions" msgstr "討論" #: ../source/contribute.rst:58 -msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." +msgid "" +"Discussions are focused on understanding and information. These explore a " +"specific topic without a specific goal in mind. :doc:`example discussion-" +"style document `." msgstr "" #: ../source/contribute.rst:63 @@ -91,7 +111,11 @@ msgid "Specifications" msgstr "規格" #: ../source/contribute.rst:65 -msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." +msgid "" +"Specifications are reference documention focused on comprehensively " +"documenting an agreed-upon interface for interoperability between packaging " +"tools. :doc:`example specification-style document `." msgstr "" #: ../source/contribute.rst:73 @@ -99,30 +123,46 @@ msgid "Building the guide locally" msgstr "在本地構建指南" #: ../source/contribute.rst:75 -msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" +msgid "" +"Though not required to contribute, it may be useful to build this guide " +"locally in order to test your changes. In order to build this guide locally, " +"you'll need:" msgstr "" #: ../source/contribute.rst:79 -msgid "`Nox `_. You can install or upgrade nox using ``pip``::" +msgid "" +"`Nox `_. You can install or upgrade " +"nox using ``pip``::" msgstr "" -"`Nox `_。您可以使用 ``pip`` 來安裝或升級 nox::" +"`Nox `_。您可以使用 ``pip`` 來安裝或升" +"級 nox::" #: ../source/contribute.rst:84 -msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." +msgid "" +"Python 3.6. Our build scripts are designed to work with Python 3.6 only. See " +"the `Hitchhiker's Guide to Python installation instructions`_ to install " +"Python 3.6 on your operating system." msgstr "" -"Python 3.6。我們的構建腳本只為 Python 3.6 而設計。請參閱 `Hitchhiker's Guide to Python " -"installation instructions`_ 以在您的操作系統上安裝Python 3.6。" +"Python 3.6。我們的構建腳本只為 Python 3.6 而設計。請參閱 `Hitchhiker's Guide " +"to Python installation instructions`_ 以在您的操作系統上安裝Python 3.6。" #: ../source/contribute.rst:91 -msgid "To build the guide, run the following bash command in the source folder::" +msgid "" +"To build the guide, run the following bash command in the source folder::" msgstr "要構建指南，請在 source 資料夾中運行以下 bash 命令::" #: ../source/contribute.rst:95 -msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." +msgid "" +"After the process has completed you can find the HTML output in the ``./" +"build/html`` directory. You can open the ``index.html`` file to view the " +"guide in web browser, but it's recommended to serve the guide using an HTTP " +"server." msgstr "" #: ../source/contribute.rst:100 -msgid "You can build the guide and serve it via an HTTP server using the following command::" +msgid "" +"You can build the guide and serve it via an HTTP server using the following " +"command::" msgstr "" #: ../source/contribute.rst:105 @@ -134,7 +174,10 @@ msgid "Where the guide is deployed" msgstr "" #: ../source/contribute.rst:111 -msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." +msgid "" +"The guide is deployed via ReadTheDocs and the configuration lives at https://" +"readthedocs.org/projects/python-packaging-user-guide/. It's served from a " +"custom domain and fronted by Fast.ly." msgstr "" #: ../source/contribute.rst:117 @@ -142,7 +185,11 @@ msgid "Style guide" msgstr "風格指南" #: ../source/contribute.rst:119 -msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." +msgid "" +"This style guide has recommendations for how you should write the |PyPUG|. " +"Before you start writing, please review it. By following the style guide, " +"your contributions will help add to a cohesive whole and make it easier for " +"your contributions to be accepted into the project." msgstr "" #: ../source/contribute.rst:126 @@ -150,7 +197,9 @@ msgid "Purpose" msgstr "目的" #: ../source/contribute.rst:128 -msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." +msgid "" +"The purpose of the |PyPUG| is to be the authoritative resource on how to " +"package, publish, and install Python projects using current tools." msgstr "" #: ../source/contribute.rst:133 @@ -158,11 +207,18 @@ msgid "Scope" msgstr "範圍" #: ../source/contribute.rst:135 -msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." +msgid "" +"The guide is meant to answer questions and solve problems with accurate and " +"focused recommendations." msgstr "該指南旨在通過準確和有針對性的建議回答問題和解決問題。" #: ../source/contribute.rst:138 -msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." +msgid "" +"The guide isn't meant to be comprehensive and it's not meant to replace " +"individual projects' documentation. For example, pip has dozens of commands, " +"options, and settings. The pip documentation describes each of them in " +"detail, while this guide describes only the parts of pip that are needed to " +"complete the specific tasks described in this guide." msgstr "" #: ../source/contribute.rst:146 @@ -174,11 +230,17 @@ msgid "The audience of this guide is anyone who uses Python with packages." msgstr "" #: ../source/contribute.rst:150 -msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." +msgid "" +"Don't forget that the Python community is big and welcoming. Readers may not " +"share your age, gender, education, culture, and more, but they deserve to " +"learn about packaging just as much as you do." msgstr "" #: ../source/contribute.rst:154 -msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." +msgid "" +"In particular, keep in mind that not all people who use Python see " +"themselves as programmers. The audience of this guide includes astronomers " +"or painters or students as well as professional software developers." msgstr "" #: ../source/contribute.rst:160 @@ -186,19 +248,35 @@ msgid "Voice and tone" msgstr "" #: ../source/contribute.rst:162 -msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." +msgid "" +"When writing this guide, strive to write with a voice that's approachable " +"and humble, even if you have all the answers." msgstr "" #: ../source/contribute.rst:165 -msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." +msgid "" +"Imagine you're working on a Python project with someone you know to be smart " +"and skilled. You like working with them and they like working with you. That " +"person has asked you a question and you know the answer. How do you respond? " +"*That* is how you should write this guide." msgstr "" #: ../source/contribute.rst:170 -msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." +msgid "" +"Here's a quick check: try reading aloud to get a sense for your writing's " +"voice and tone. Does it sound like something you would say or does it sound " +"like you're acting out a part or giving a speech? Feel free to use " +"contractions and don't worry about sticking to fussy grammar rules. You are " +"hereby granted permission to end a sentence in a preposition, if that's what " +"you want to end it with." msgstr "" #: ../source/contribute.rst:177 -msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." +msgid "" +"When writing the guide, adjust your tone for the seriousness and difficulty " +"of the topic. If you're writing an introductory tutorial, it's OK to make a " +"joke, but if you're covering a sensitive security recommendation, you might " +"want to avoid jokes altogether." msgstr "" #: ../source/contribute.rst:184 @@ -210,7 +288,9 @@ msgid "**Write to the reader**" msgstr "" #: ../source/contribute.rst:187 -msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." +msgid "" +"When giving recommendations or steps to take, address the reader as *you* or " +"use the imperative mood." msgstr "" #: ../source/contribute.rst:0 @@ -230,7 +310,11 @@ msgid "**State assumptions**" msgstr "" #: ../source/contribute.rst:195 -msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." +msgid "" +"Avoid making unstated assumptions. Reading on the web means that any page of " +"the guide may be the first page of the guide that the reader ever sees. If " +"you're going to make assumptions, then say what assumptions that you're " +"going to make." msgstr "" #: ../source/contribute.rst:203 @@ -238,7 +322,10 @@ msgid "**Cross-reference generously**" msgstr "" #: ../source/contribute.rst:201 -msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." +msgid "" +"The first time you mention a tool or practice, link to the part of the guide " +"that covers it, or link to a relevant document elsewhere. Save the reader a " +"search." msgstr "" #: ../source/contribute.rst:213 @@ -246,7 +333,9 @@ msgid "**Respect naming practices**" msgstr "" #: ../source/contribute.rst:206 -msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." +msgid "" +"When naming tools, sites, people, and other proper nouns, use their " +"preferred capitalization." msgstr "" #: ../source/contribute.rst:0 @@ -270,7 +359,10 @@ msgid "**Use a gender-neutral style**" msgstr "" #: ../source/contribute.rst:216 -msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." +msgid "" +"Often, you'll address the reader directly with *you*, *your* and *yours*. " +"Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or " +"avoid pronouns entirely." msgstr "" #: ../source/contribute.rst:0 @@ -290,11 +382,17 @@ msgid "**Headings**" msgstr "" #: ../source/contribute.rst:225 -msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." +msgid "" +"Write headings that use words the reader is searching for. A good way to do " +"this is to have your heading complete an implied question. For example, a " +"reader might want to know *How do I install MyLibrary?* so a good heading " +"might be *Install MyLibrary*." msgstr "" #: ../source/contribute.rst:230 -msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." +msgid "" +"In section headings, use sentence case. In other words, write headings as " +"you would write a typical sentence." msgstr "" #: ../source/contribute.rst:0 @@ -310,7 +408,9 @@ msgid "**Numbers**" msgstr "" #: ../source/contribute.rst:237 -msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." +msgid "" +"In body text, write numbers one through nine as words. For other numbers or " +"numbers in tables, use numerals." msgstr "" #: ../source/discussions/deploying-python-applications.rst:4 @@ -357,8 +457,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:17 #: ../source/guides/supporting-multiple-python-versions.rst:12 #: ../source/guides/supporting-windows-using-appveyor.rst:15 -#: ../source/overview.rst:23 -#: ../source/specifications/core-metadata.rst:38 +#: ../source/overview.rst:23 ../source/specifications/core-metadata.rst:38 #: ../source/specifications/direct-url.rst:14 #: ../source/tutorials/installing-packages.rst:23 msgid "Contents" @@ -385,15 +484,29 @@ msgid "Pynsist" msgstr "" #: ../source/discussions/deploying-python-applications.rst:63 -msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." +msgid "" +"`Pynsist `__ is a tool that bundles Python " +"programs together with the Python-interpreter into a single installer based " +"on NSIS. In most cases, packaging only requires the user to choose a version " +"of the Python-interpreter and declare the dependencies of the program. The " +"tool downloads the specified Python-interpreter for Windows and packages it " +"with all the dependencies in a single Windows-executable installer." msgstr "" #: ../source/discussions/deploying-python-applications.rst:70 -msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." +msgid "" +"The installed program can be started from a shortcut that the installer adds " +"to the start-menu. It uses a Python interpreter installed within its " +"application directory, independent of any other Python installation on the " +"computer." msgstr "" #: ../source/discussions/deploying-python-applications.rst:74 -msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." +msgid "" +"A big advantage of Pynsist is that the Windows packages can be built on " +"Linux. There are several examples for different kinds of programs (console, " +"GUI) in the `documentation `__. The tool is " +"released under the MIT-licence." msgstr "" #: ../source/discussions/deploying-python-applications.rst:80 @@ -405,7 +518,10 @@ msgid "Configuration management" msgstr "" #: ../source/discussions/index.rst:4 -msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." +msgid "" +"**Discussions** are focused on providing comprehensive information about a " +"specific topic. If you're just trying to get stuff done, see :doc:`/guides/" +"index`." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:5 @@ -418,31 +534,52 @@ msgid "install_requires" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:14 -msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgid "" +"``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that " +"should be used to specify what a project **minimally** needs to run " +"correctly. When the project is installed by :ref:`pip`, this is the " +"specification that is used to install its dependencies." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:19 -msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" +msgid "" +"For example, if the project requires A and B, your ``install_requires`` " +"would be like so:" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:29 -msgid "Additionally, it's best practice to indicate any known lower or upper bounds." +msgid "" +"Additionally, it's best practice to indicate any known lower or upper bounds." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:31 -msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" +msgid "" +"For example, it may be known, that your project requires at least v1 of 'A', " +"and v2 of 'B', so it would be like so:" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:41 -msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" +msgid "" +"It may also be known that project A follows semantic versioning, and that v2 " +"of 'A' will indicate a break in compatibility, so it makes sense to not " +"allow v2:" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:51 -msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." +msgid "" +"It is not considered best practice to use ``install_requires`` to pin " +"dependencies to specific versions, or to specify sub-dependencies (i.e. " +"dependencies of your dependencies). This is overly-restrictive, and " +"prevents the user from gaining the benefit of dependency upgrades." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:56 -msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" +msgid "" +"Lastly, it's important to understand that ``install_requires`` is a listing " +"of \"Abstract\" requirements, i.e just names and version restrictions that " +"don't determine where the dependencies will be fulfilled from (i.e. from " +"what index or source). The where (i.e. how they are to be made \"Concrete" +"\") is to be determined at install time using :ref:`pip` options. [1]_" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:64 @@ -451,27 +588,46 @@ msgid "Requirements files" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:66 -msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." +msgid "" +":ref:`Requirements Files ` described most simply, " +"are just a list of :ref:`pip:pip install` arguments placed into a file." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:69 -msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." +msgid "" +"Whereas ``install_requires`` defines the dependencies for a single project, :" +"ref:`Requirements Files ` are often used to define " +"the requirements for a complete Python environment." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:73 -msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." +msgid "" +"Whereas ``install_requires`` requirements are minimal, requirements files " +"often contain an exhaustive listing of pinned versions for the purpose of " +"achieving :ref:`repeatable installations ` of a complete " +"environment." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:78 -msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" +msgid "" +"Whereas ``install_requires`` requirements are \"Abstract\", i.e. not " +"associated with any particular index, requirements files often contain pip " +"options like ``--index-url`` or ``--find-links`` to make requirements " +"\"Concrete\", i.e. associated with a particular index or directory of " +"packages. [1]_" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:84 -msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." +msgid "" +"Whereas ``install_requires`` metadata is automatically analyzed by pip " +"during an install, requirements files are not, and only are used when a user " +"specifically installs them using ``python -m pip install -r``." msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:90 -msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." +msgid "" +"For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad." +"io/2013/07/setup-vs-requirement/." msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:6 @@ -479,15 +635,29 @@ msgid "pip vs easy_install" msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:9 -msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." +msgid "" +":ref:`easy_install `, now `deprecated`_, was released in 2004 " +"as part of :ref:`setuptools`. It was notable at the time for installing :" +"term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing " +"dependencies." msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:14 -msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." +msgid "" +":ref:`pip` came later in 2008, as alternative to :ref:`easy_install " +"`, although still largely built on top of :ref:`setuptools` " +"components. It was notable at the time for *not* installing packages as :" +"term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' " +"packages from :term:`sdists `), and " +"introducing the idea of :ref:`Requirements Files `, " +"which gave users the power to easily replicate environments." msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:22 -msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" +msgid "" +"Here's a breakdown of the important differences between pip and the " +"deprecated easy_install:" msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:25 @@ -601,7 +771,9 @@ msgid "Yes, via setup.cfg" msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:68 -msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" +msgid "" +"https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" +"launcher" msgstr "" #: ../source/discussions/wheel-vs-egg.rst:5 @@ -609,19 +781,28 @@ msgid "Wheel vs Egg" msgstr "" #: ../source/discussions/wheel-vs-egg.rst:7 -msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." +msgid "" +":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support " +"the use case of needing an install artifact that doesn't require building or " +"compilation, which can be costly in testing and production workflows." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:11 -msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." +msgid "" +"The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas " +"the :term:`Wheel` format was introduced by :pep:`427` in 2012." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:14 -msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." +msgid "" +":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:17 -msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." +msgid "" +"Here's a breakdown of the important differences between :term:`Wheel` and :" +"term:`Egg`." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:20 @@ -629,31 +810,53 @@ msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:22 -msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." +msgid "" +":term:`Wheel` is a :term:`distribution ` format, i.e a " +"packaging format. [1]_ :term:`Egg` was both a distribution format and a " +"runtime installation format (if left zipped), and was designed to be " +"importable." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:26 -msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." +msgid "" +":term:`Wheel` archives do not include .pyc files. Therefore, when the " +"distribution only contains Python files (i.e. no compiled extensions), and " +"is compatible with Python 2 and 3, it's possible for a wheel to be " +"\"universal\", similar to an :term:`sdist `." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:31 -msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." +msgid "" +":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. " +"Egg used ``.egg-info``." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:34 -msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." +msgid "" +":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single " +"wheel archive can indicate its compatibility with a number of Python " +"language versions and implementations, ABIs, and system architectures." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:38 -msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." +msgid "" +":term:`Wheel` is versioned. Every wheel file contains the version of the " +"wheel specification and the implementation that packaged it." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:41 -msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." +msgid "" +":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making " +"it easier to convert to other formats." msgstr "" #: ../source/discussions/wheel-vs-egg.rst:47 -msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." +msgid "" +"Circumstantially, in some cases, wheels can be used as an importable runtime " +"format, although :pep:`this is not officially supported at this time <427#is-" +"it-possible-to-import-python-code-directly-from-a-wheel-file>`." msgstr "" #: ../source/glossary.rst:3 @@ -665,7 +868,9 @@ msgid "Binary Distribution" msgstr "" #: ../source/glossary.rst:11 -msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." +msgid "" +"A specific kind of :term:`Built Distribution` that contains compiled " +"extensions." msgstr "" #: ../source/glossary.rst:14 @@ -673,7 +878,14 @@ msgid "Built Distribution" msgstr "" #: ../source/glossary.rst:17 -msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." +msgid "" +"A :term:`Distribution ` format containing files and " +"metadata that only need to be moved to the correct location on the target " +"system, to be installed. :term:`Wheel` is such a format, whereas distutil's :" +"term:`Source Distribution ` is not, in " +"that it requires a build step before it can be installed. This format does " +"not imply that Python files have to be precompiled (:term:`Wheel` " +"intentionally does not include compiled Python files)." msgstr "" #: ../source/glossary.rst:26 @@ -681,11 +893,22 @@ msgid "Distribution Package" msgstr "" #: ../source/glossary.rst:29 -msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." +msgid "" +"A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used " +"to distribute a :term:`Release`. The archive file is what an end-user will " +"download from the internet and install." msgstr "" #: ../source/glossary.rst:34 -msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." +msgid "" +"A distribution package is more commonly referred to with the single words " +"\"package\" or \"distribution\", but this guide may use the expanded term " +"when more clarity is needed to prevent confusion with an :term:`Import " +"Package` (which is also commonly called a \"package\") or another kind of " +"distribution (e.g. a Linux distribution or the Python language " +"distribution), which are often referred to with the single term " +"\"distribution\"." msgstr "" #: ../source/glossary.rst:41 @@ -693,7 +916,12 @@ msgid "Egg" msgstr "" #: ../source/glossary.rst:44 -msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" +msgid "" +"A :term:`Built Distribution` format introduced by :ref:`setuptools`, which " +"is being replaced by :term:`Wheel`. For details, see `The Internal " +"Structure of Python Eggs `_ and `Python Eggs `_" msgstr "" #: ../source/glossary.rst:49 @@ -701,7 +929,12 @@ msgid "Extension Module" msgstr "" #: ../source/glossary.rst:52 -msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." +msgid "" +"A :term:`Module` written in the low-level language of the Python " +"implementation: C/C++ for Python, Java for Jython. Typically contained in a " +"single dynamically loadable pre-compiled file, e.g. a shared object (.so) " +"file for Python extensions on Unix, a DLL (given the .pyd extension) for " +"Python extensions on Windows, or a Java class file for Jython extensions." msgstr "" #: ../source/glossary.rst:59 @@ -709,7 +942,12 @@ msgid "Known Good Set (KGS)" msgstr "" #: ../source/glossary.rst:62 -msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." +msgid "" +"A set of distributions at specified versions which are compatible with each " +"other. Typically a test suite will be run which passes all tests before a " +"specific set of packages is declared a known good set. This term is commonly " +"used by frameworks and toolkits which are comprised of multiple individual " +"distributions." msgstr "" #: ../source/glossary.rst:68 @@ -717,11 +955,17 @@ msgid "Import Package" msgstr "" #: ../source/glossary.rst:71 -msgid "A Python module which can contain other modules or recursively, other packages." +msgid "" +"A Python module which can contain other modules or recursively, other " +"packages." msgstr "" #: ../source/glossary.rst:74 -msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." +msgid "" +"An import package is more commonly referred to with the single word \"package" +"\", but this guide will use the expanded term when more clarity is needed to " +"prevent confusion with a :term:`Distribution Package` which is also commonly " +"called a \"package\"." msgstr "" #: ../source/glossary.rst:78 @@ -729,7 +973,9 @@ msgid "Module" msgstr "" #: ../source/glossary.rst:81 -msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." +msgid "" +"The basic unit of code reusability in Python, existing in one of two types: :" +"term:`Pure Module`, or :term:`Extension Module`." msgstr "" #: ../source/glossary.rst:84 @@ -737,7 +983,9 @@ msgid "Package Index" msgstr "" #: ../source/glossary.rst:87 -msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." +msgid "" +"A repository of distributions with a web interface to automate :term:" +"`package ` discovery and consumption." msgstr "" #: ../source/glossary.rst:90 @@ -745,7 +993,10 @@ msgid "Per Project Index" msgstr "" #: ../source/glossary.rst:93 -msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." +msgid "" +"A private or other non-canonical :term:`Package Index` indicated by a " +"specific :term:`Project` as the index preferred or required to resolve " +"dependencies of that project." msgstr "" #: ../source/glossary.rst:97 @@ -753,19 +1004,35 @@ msgid "Project" msgstr "" #: ../source/glossary.rst:100 -msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." +msgid "" +"A library, framework, script, plugin, application, or collection of data or " +"other resources, or some combination thereof that is intended to be packaged " +"into a :term:`Distribution `." msgstr "" #: ../source/glossary.rst:104 -msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." +msgid "" +"Since most projects create :term:`Distributions ` " +"using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:" +"`setuptools`, another practical way to define projects currently is " +"something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:" +"`setup.cfg` file at the root of the project source directory." msgstr "" #: ../source/glossary.rst:110 -msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." +msgid "" +"Python projects must have unique names, which are registered on :term:`PyPI " +"`. Each project will then contain one or more :" +"term:`Releases `, and each release may comprise one or more :term:" +"`distributions `." msgstr "" #: ../source/glossary.rst:115 -msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." +msgid "" +"Note that there is a strong convention to name a project after the name of " +"the package that is imported to run that project. However, this doesn't have " +"to hold true. It's possible to install a distribution from the project 'foo' " +"and have it provide a package importable only as 'bar'." msgstr "" #: ../source/glossary.rst:121 @@ -773,7 +1040,9 @@ msgid "Pure Module" msgstr "" #: ../source/glossary.rst:124 -msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." +msgid "" +"A :term:`Module` written in Python and contained in a single ``.py`` file " +"(and possibly associated ``.pyc`` and/or ``.pyo`` files)." msgstr "" #: ../source/glossary.rst:127 @@ -781,7 +1050,13 @@ msgid "Python Packaging Authority (PyPA)" msgstr "" #: ../source/glossary.rst:130 -msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." +msgid "" +"PyPA is a working group that maintains many of the relevant projects in " +"Python packaging. They maintain a site at https://www.pypa.io, host projects " +"on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python " +"Discourse forum `__." msgstr "" #: ../source/glossary.rst:139 @@ -789,7 +1064,10 @@ msgid "Python Package Index (PyPI)" msgstr "" #: ../source/glossary.rst:142 -msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." +msgid "" +"`PyPI `_ is the default :term:`Package Index` for the " +"Python community. It is open to all Python developers to consume and " +"distribute their distributions." msgstr "" #: ../source/glossary.rst:145 @@ -797,7 +1075,10 @@ msgid "pypi.org" msgstr "" #: ../source/glossary.rst:148 -msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." +msgid "" +"`pypi.org `_ is the domain name for the :term:`Python " +"Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi." +"python.org``, in 2017. It is powered by :ref:`warehouse`." msgstr "" #: ../source/glossary.rst:152 @@ -805,7 +1086,8 @@ msgid "pyproject.toml" msgstr "" #: ../source/glossary.rst:155 -msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." +msgid "" +"The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." msgstr "" #: ../source/glossary.rst:157 @@ -813,11 +1095,17 @@ msgid "Release" msgstr "" #: ../source/glossary.rst:160 -msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." +msgid "" +"A snapshot of a :term:`Project` at a particular point in time, denoted by a " +"version identifier." msgstr "" #: ../source/glossary.rst:163 -msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." +msgid "" +"Making a release may entail the publishing of multiple :term:`Distributions " +"`. For example, if version 1.0 of a project was " +"released, it could be available in both a source distribution format and a " +"Windows installer distribution format." msgstr "" #: ../source/glossary.rst:168 @@ -825,7 +1113,12 @@ msgid "Requirement" msgstr "" #: ../source/glossary.rst:171 -msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." +msgid "" +"A specification for a :term:`package ` to be " +"installed. :ref:`pip`, the :term:`PYPA ` " +"recommended installer, allows various forms of specification that can all be " +"considered a \"requirement\". For more information, see the :ref:`pip:pip " +"install` reference." msgstr "" #: ../source/glossary.rst:177 @@ -833,7 +1126,13 @@ msgid "Requirement Specifier" msgstr "" #: ../source/glossary.rst:180 -msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" +msgid "" +"A format used by :ref:`pip` to install packages from a :term:`Package " +"Index`. For an EBNF diagram of the format, see the `pkg_resources." +"Requirement `_ entry in the :ref:`setuptools` docs. For " +"example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the " +"project name, and the \">=1.3\" portion is the :term:`Version Specifier`" msgstr "" #: ../source/glossary.rst:187 @@ -841,7 +1140,10 @@ msgid "Requirements File" msgstr "" #: ../source/glossary.rst:190 -msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." +msgid "" +"A file containing a list of :term:`Requirements ` that can be " +"installed using :ref:`pip`. For more information, see the :ref:`pip` docs " +"on :ref:`pip:Requirements Files`." msgstr "" #: ../source/glossary.rst:194 @@ -855,7 +1157,9 @@ msgid "setup.cfg" msgstr "" #: ../source/glossary.rst:198 -msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." +msgid "" +"The project specification files for :ref:`distutils` and :ref:`setuptools`. " +"See also :term:`pyproject.toml`." msgstr "" #: ../source/glossary.rst:201 @@ -863,7 +1167,10 @@ msgid "Source Archive" msgstr "" #: ../source/glossary.rst:204 -msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." +msgid "" +"An archive containing the raw source code for a :term:`Release`, prior to " +"creation of a :term:`Source Distribution ` or :term:`Built Distribution`." msgstr "" #: ../source/glossary.rst:208 @@ -871,7 +1178,11 @@ msgid "Source Distribution (or \"sdist\")" msgstr "" #: ../source/glossary.rst:211 -msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." +msgid "" +"A :term:`distribution ` format (usually generated " +"using ``python setup.py sdist``) that provides metadata and the essential " +"source files needed for installing by a tool like :ref:`pip`, or for " +"generating a :term:`Built Distribution`." msgstr "" #: ../source/glossary.rst:216 @@ -879,7 +1190,9 @@ msgid "System Package" msgstr "" #: ../source/glossary.rst:219 -msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." +msgid "" +"A package provided in a format native to the operating system, e.g. an rpm " +"or dpkg file." msgstr "" #: ../source/glossary.rst:222 @@ -887,7 +1200,12 @@ msgid "Version Specifier" msgstr "" #: ../source/glossary.rst:225 -msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." +msgid "" +"The version component of a :term:`Requirement Specifier`. For example, the " +"\">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full " +"specification <440#version-specifiers>` of the specifiers that Python " +"packaging currently supports. Support for PEP440 was implemented in :ref:" +"`setuptools` v8.0 and :ref:`pip` v6.0." msgstr "" #: ../source/glossary.rst:231 @@ -895,7 +1213,11 @@ msgid "Virtual Environment" msgstr "" #: ../source/glossary.rst:234 -msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgid "" +"An isolated Python environment that allows packages to be installed for use " +"by a particular application, rather than being installed system wide. For " +"more information, see the section on :ref:`Creating and using Virtual " +"Environments`." msgstr "" #: ../source/glossary.rst:238 @@ -903,7 +1225,10 @@ msgid "Wheel" msgstr "" #: ../source/glossary.rst:241 -msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." +msgid "" +"A :term:`Built Distribution` format introduced by :pep:`427`, which is " +"intended to replace the :term:`Egg` format. Wheel is currently supported " +"by :ref:`pip`." msgstr "" #: ../source/glossary.rst:244 @@ -911,7 +1236,11 @@ msgid "Working Set" msgstr "" #: ../source/glossary.rst:247 -msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." +msgid "" +"A collection of :term:`distributions ` available for " +"importing. These are the distributions that are on the `sys.path` variable. " +"At most, one :term:`Distribution ` for a project is " +"possible in a working set." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:3 @@ -919,7 +1248,11 @@ msgid "Analyzing PyPI package downloads" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:5 -msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." +msgid "" +"This section covers how to use the public PyPI download statistics dataset " +"to learn more about downloads of a package (or packages) hosted on PyPI. For " +"example, you can use it to discover the distribution of Python versions used " +"to download a package." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:15 @@ -932,11 +1265,17 @@ msgid "PyPI does not display download statistics for a number of reasons: [#]_" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:19 -msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." +msgid "" +"**Inefficient to make work with a Content Distribution Network (CDN):** " +"Download statistics change constantly. Including them in project pages, " +"which are heavily cached, would require invalidating the cache more often, " +"and reduce the overall effectiveness of the cache." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:24 -msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" +msgid "" +"**Highly inaccurate:** A number of things prevent the download counts from " +"being accurate, some of which include:" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:27 @@ -944,7 +1283,8 @@ msgid "``pip``'s download cache (lowers download counts)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:28 -msgid "Internal or unofficial mirrors (can both raise or lower download counts)" +msgid "" +"Internal or unofficial mirrors (can both raise or lower download counts)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:29 @@ -952,7 +1292,9 @@ msgid "Packages not hosted on PyPI (for comparisons sake)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:30 -msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" +msgid "" +"Unofficial scripts or attempts at download count inflation (raises download " +"counts)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:32 @@ -960,11 +1302,17 @@ msgid "Known historical data quality issues (lowers download counts)" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:34 -msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" +msgid "" +"**Not particularly useful:** Just because a project has been downloaded a " +"lot doesn't mean it's good; Similarly just because a project hasn't been " +"downloaded a lot doesn't mean it's bad!" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:38 -msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." +msgid "" +"In short, because it's value is low for various reasons, and the tradeoffs " +"required to make it work are high, it has been not an effective use of " +"limited resources." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:43 @@ -972,7 +1320,10 @@ msgid "Public dataset" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:45 -msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." +msgid "" +"As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, " +"where they are stored as a public dataset." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:50 @@ -980,7 +1331,13 @@ msgid "Getting set up" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:52 -msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" +msgid "" +"In order to use `Google BigQuery`_ to query the `public PyPI download " +"statistics dataset`_, you'll need a Google account and to enable the " +"BigQuery API on a Google Cloud Platform project. You can run the up to 1TB " +"of queries per month `using the BigQuery free tier without a credit card " +"`__" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:58 @@ -992,11 +1349,16 @@ msgid "Create a new project." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:60 -msgid "Enable the `BigQuery API `__." +msgid "" +"Enable the `BigQuery API `__." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:63 -msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." +msgid "" +"For more detailed instructions on how to get started with BigQuery, check " +"out the `BigQuery quickstart guide `__." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:69 @@ -1004,7 +1366,12 @@ msgid "Data schema" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:71 -msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" +msgid "" +"Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` " +"table for each download. The table contains information about what file was " +"downloaded and how it was downloaded. Some useful columns from the `table " +"schema `__ include:" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 @@ -1087,11 +1454,16 @@ msgid "Useful queries" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:95 -msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." +msgid "" +"Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" " +"button." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:97 -msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." +msgid "" +"Note that the rows are stored in a partitioned, which helps limit the cost " +"of queries. These example queries analyze downloads from recent history by " +"filtering on the ``timestamp`` column." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:102 @@ -1099,7 +1471,9 @@ msgid "Counting package downloads" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:104 -msgid "The following query counts the total number of downloads for the project \"pytest\"." +msgid "" +"The following query counts the total number of downloads for the project " +"\"pytest\"." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:119 @@ -1114,7 +1488,9 @@ msgid "26190085" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:124 -msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." +msgid "" +"To only count downloads from pip, filter on the ``details.installer.name`` " +"column." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:142 @@ -1126,7 +1502,9 @@ msgid "Package downloads over time" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:148 -msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." +msgid "" +"To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also " +"filtering by this column reduces corresponding costs." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:168 @@ -1186,7 +1564,9 @@ msgid "Python versions over time" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:186 -msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." +msgid "" +"Extract the Python version from the ``details.python`` column. Warning: This " +"query processes over 500 GB of data." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:205 @@ -1246,7 +1626,12 @@ msgid "Caveats" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:223 -msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." +msgid "" +"In addition to the caveats listed in the background above, Linehaul suffered " +"from a bug which caused it to significantly under-report download statistics " +"prior to July 26, 2018. Downloads before this date are proportionally " +"accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total " +"numbers are lower than actual by an order of magnitude." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:231 @@ -1254,7 +1639,9 @@ msgid "Additional tools" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:233 -msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." +msgid "" +"Besides using the BigQuery console, there are some additional tools which " +"may be useful when analyzing download statistics." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:237 @@ -1262,7 +1649,10 @@ msgid "``google-cloud-bigquery``" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:239 -msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." +msgid "" +"You can also access the public PyPI download statistics dataset " +"programmatically via the BigQuery API and the `google-cloud-bigquery`_ " +"project, the official Python client library for BigQuery." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:267 @@ -1270,7 +1660,10 @@ msgid "``pypinfo``" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:269 -msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." +msgid "" +"`pypinfo`_ is a command-line tool which provides access to the dataset and " +"can generate several useful queries. For example, you can query the total " +"number of download for a package with the command ``pypinfo package_name``." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:273 @@ -1286,7 +1679,8 @@ msgid "``pandas-gbq``" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:297 -msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." +msgid "" +"The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:301 @@ -1295,11 +1689,15 @@ msgid "References" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:303 -msgid "`PyPI Download Counts deprecation email `__" +msgid "" +"`PyPI Download Counts deprecation email `__" msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:304 -msgid "`PyPI BigQuery dataset announcement email `__" +msgid "" +"`PyPI BigQuery dataset announcement email `__" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:3 @@ -1307,7 +1705,11 @@ msgid "Creating and discovering plugins" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:5 -msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." +msgid "" +"Often when creating a Python application or library you'll want the ability " +"to provide customizations or extra features via **plugins**. Because Python " +"packages can be separately distributed, your application or library may want " +"to automatically **discover** all of the plugins available." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:10 @@ -1331,15 +1733,25 @@ msgid "Using naming convention" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:20 -msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" +msgid "" +"If all of the plugins for your application follow the same naming " +"convention, you can use :func:`pkgutil.iter_modules` to discover all of the " +"top-level modules that match the naming convention. For example, `Flask`_ " +"uses the naming convention ``flask_{plugin_name}``. If you wanted to " +"automatically discover all of the Flask plugins installed:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:38 -msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" +msgid "" +"If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins " +"installed then ``discovered_plugins`` would be:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:48 -msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." +msgid "" +"Using naming convention for plugins also allows you to query the Python " +"Package Index's `simple API`_ for all packages that conform to your naming " +"convention." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:59 @@ -1347,19 +1759,48 @@ msgid "Using namespace packages" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:61 -msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" +msgid "" +":doc:`Namespace packages ` can be used to " +"provide a convention for where to place plugins and also provides a way to " +"perform discovery. For example, if you make the sub-package ``myapp." +"plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once " +"installed, you can use :func:`pkgutil.iter_modules` to discover all modules " +"and packages installed under that namespace:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:89 -msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" +msgid "" +"Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` " +"causes it to only look for the modules directly under that namespace. For " +"example, if you have installed distributions that provide the modules " +"``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in " +"this case would be:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:101 -msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." +msgid "" +"This sample uses a sub-package as the namespace package (``myapp.plugins``), " +"but it's also possible to use a top-level package for this purpose (such as " +"``myapp_plugins``). How to pick the namespace to use is a matter of " +"preference, but it's not recommended to make your project's main top-level " +"package (``myapp`` in this case) a namespace package for the purpose of " +"plugins, as one bad plugin could cause the entire namespace to break which " +"would in turn make your project unimportable. For the \"namespace sub-package" +"\" approach to work, the plugin packages must omit the :file:`__init__.py` " +"for your top-level package directory (``myapp`` in this case) and include " +"the namespace-package style :file:`__init__.py` in the namespace sub-package " +"directory (``myapp/plugins``). This also means that plugins will need to " +"explicitly pass a list of packages to :func:`setup`'s ``packages`` argument " +"instead of using :func:`setuptools.find_packages`." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:115 -msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." +msgid "" +"Namespace packages are a complex feature and there are several different " +"ways to create them. It's highly recommended to read the :doc:`packaging-" +"namespace-packages` documentation and clearly document which approach is " +"preferred for plugins to your project." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:121 @@ -1367,31 +1808,50 @@ msgid "Using package metadata" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:123 -msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." +msgid "" +"`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :" +"func:`setup` in :file:`setup.py` plugins can register themselves for " +"discovery." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:128 -msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" +msgid "" +"For example if you have a package named ``myapp-plugin-a`` and it includes " +"in its :file:`setup.py`:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:139 -msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" +msgid "" +"Then you can discover and load all of the registered entry points by using :" +"func:`importlib.metadata.entry_points` (or the `backport`_ " +"``importlib_metadata >= 3.6`` for Python 3.6-3.9):" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:154 -msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" +msgid "" +"In this example, ``discovered_plugins`` would be a collection of type :class:" +"`importlib.metadata.EntryPoint`:" msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:163 -msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." +msgid "" +"Now the module of your choice can be imported by executing " +"``discovered_plugins['a'].load()``." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:166 -msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." +msgid "" +"The ``entry_point`` specification in :file:`setup.py` is fairly flexible and " +"has a lot of options. It's recommended to read over the entire section on :" +"doc:`entry points ` ." msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:170 -msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." +msgid "" +"Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools " +"provide support for defining entry points." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:5 @@ -1399,15 +1859,25 @@ msgid "Packaging and distributing projects" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:7 -msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." +msgid "" +"This section covers the basics of how to configure, package and distribute " +"your own Python projects. It assumes that you are already familiar with the " +"contents of the :doc:`/tutorials/installing-packages` page." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:11 -msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." +msgid "" +"The section does *not* aim to cover best practices for Python project " +"development as a whole. For example, it does not provide guidance or tool " +"recommendations for version control, documentation, or testing." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:15 -msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." +msgid "" +"For more reference material, see :std:doc:`Building and Distributing " +"Packages ` in the :ref:`setuptools` docs, but note that " +"some advisory content there may be outdated. In the event of conflicts, " +"prefer the advice in the Python Packaging User Guide." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:25 @@ -1415,7 +1885,9 @@ msgid "Requirements for packaging and distributing" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:26 -msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." +msgid "" +"First, make sure you have already fulfilled the :ref:`requirements for " +"installing packages `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:29 @@ -1423,7 +1895,10 @@ msgid "Install \"twine\" [1]_:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:43 -msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." +msgid "" +"You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below " +"`)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:49 @@ -1435,7 +1910,11 @@ msgid "Initial files" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:58 -msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." +msgid "" +"The most important file is :file:`setup.py` which exists at the root of your " +"project directory. For an example, see the `setup.py `_ in the `PyPA sample project " +"`_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:63 @@ -1443,15 +1922,27 @@ msgid ":file:`setup.py` serves two primary functions:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:65 -msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." +msgid "" +"It's the file where various aspects of your project are configured. The " +"primary feature of :file:`setup.py` is that it contains a global ``setup()`` " +"function. The keyword arguments to this function are how specific details " +"of your project are defined. The most relevant arguments are explained in :" +"ref:`the section below `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:71 -msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." +msgid "" +"It's the command line interface for running various commands that relate to " +"packaging tasks. To get a listing of available commands, run ``python setup." +"py --help-commands``." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:79 -msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." +msgid "" +":file:`setup.cfg` is an ini file that contains option defaults for :file:" +"`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project " +"`_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:86 @@ -1459,15 +1950,31 @@ msgid "README.rst / README.md" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:88 -msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." +msgid "" +"All projects should contain a readme file that covers the goal of the " +"project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not " +"a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:" +"`long_description_content_type ` argument)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:95 -msgid "For an example, see `README.md `_ from the `PyPA sample project `_." +msgid "" +"For an example, see `README.md `_ from the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:99 -msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." +msgid "" +"Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:" +"`README.rst`, :file:`README.txt`, or :file:`README`) included in source " +"distributions by default. The built-in :ref:`distutils` library adopts this " +"behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ " +"will include a :file:`README.md` if found. If you are using setuptools, you " +"don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, " +"include it to be explicit." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:108 @@ -1475,15 +1982,23 @@ msgid "MANIFEST.in" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:110 -msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." +msgid "" +"A :file:`MANIFEST.in` is needed when you need to package additional files " +"that are not automatically included in a source distribution. For details " +"on writing a :file:`MANIFEST.in` file, including a list of what's included " +"by default, see \":ref:`Using MANIFEST.in`\"." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:115 -msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." +msgid "" +"For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:119 -msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." +msgid "" +":file:`MANIFEST.in` does not affect binary distributions such as wheels." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:122 @@ -1491,11 +2006,20 @@ msgid "LICENSE.txt" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:124 -msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." +msgid "" +"Every package should include a license file detailing the terms of " +"distribution. In many jurisdictions, packages without an explicit license " +"can not be legally used or distributed by anyone other than the copyright " +"holder. If you're unsure which license to choose, you can use resources such " +"as `GitHub's Choose a License `_ or consult a " +"lawyer." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:130 -msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." +msgid "" +"For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:135 @@ -1503,11 +2027,17 @@ msgid "" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:137 -msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." +msgid "" +"Although it's not required, the most common practice is to include your " +"Python modules and packages under a single top-level package that has the " +"same :ref:`name ` as your project, or something very close." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:141 -msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." +msgid "" +"For an example, see the `sample `_ package that's included in the `PyPA sample project " +"`_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:149 @@ -1515,11 +2045,18 @@ msgid "setup() args" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:151 -msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." +msgid "" +"As mentioned above, the primary feature of :file:`setup.py` is that it " +"contains a global ``setup()`` function. The keyword arguments to this " +"function are how specific details of your project are defined." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:155 -msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." +msgid "" +"The most relevant arguments are explained below. Most of the snippets given " +"are taken from the `setup.py `_ contained in the `PyPA sample project `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:164 @@ -1527,11 +2064,16 @@ msgid "name" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:170 -msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" +msgid "" +"This is the name of your project, determining how your project is listed on :" +"term:`PyPI `. Per :pep:`508`, valid project " +"names must:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:174 -msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" +msgid "" +"Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), " +"and/or periods (``.``), and" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:176 @@ -1539,7 +2081,11 @@ msgid "Start & end with an ASCII letter or digit." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:178 -msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" +msgid "" +"Comparison of project names is case insensitive and treats arbitrarily-long " +"runs of underscores, hyphens, and/or periods as equal. For example, if you " +"register a project named ``cool-stuff``, users will be able to download it " +"or declare a dependency on it using any of the following spellings::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:190 @@ -1548,19 +2094,30 @@ msgid "version" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:196 -msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." +msgid "" +"This is the current version of your project, allowing your users to " +"determine whether or not they have the latest version, and to indicate which " +"specific versions they've tested their own software against." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:200 -msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." +msgid "" +"Versions are displayed on :term:`PyPI ` for " +"each release if you publish your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:203 -msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." +msgid "" +"See :ref:`Choosing a versioning scheme` for more information on ways to use " +"versions to convey compatibility information to your users." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:206 -msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." +msgid "" +"If the project code itself needs run-time access to the version, the " +"simplest way is to keep the version in both :file:`setup.py` and your code. " +"If you'd rather not duplicate the value, there are a few ways to manage " +"this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:214 @@ -1572,15 +2129,32 @@ msgid "Give a short and long description for your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:224 -msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." +msgid "" +"These values will be displayed on :term:`PyPI ` " +"if you publish your project. On ``pypi.org``, the user interface displays " +"``description`` in the grey banner and ``long_description`` in the section " +"named \"Project Description\"." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:229 -msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." +msgid "" +"``description`` is also displayed in lists of projects. For example, it's " +"visible in the search results pages such as https://pypi.org/search/?" +"q=jupyter, the front-page lists of trending projects and new releases, and " +"the list of projects you maintain within your account profile (such as " +"https://pypi.org/user/jaraco/)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:235 -msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." +msgid "" +"A `content type `_ can be specified with the " +"``long_description_content_type`` argument, which can be one of ``text/" +"plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no " +"formatting, `reStructuredText (reST) `_, and the Github-flavored " +"Markdown dialect of `Markdown `_ respectively." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:245 @@ -1604,11 +2178,21 @@ msgid "license" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:273 -msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." +msgid "" +"The ``license`` argument doesn't have to indicate the license under which " +"your package is being released, although you may optionally do so if you " +"want. If you're using a standard, well-known license, then your main " +"indication can and should be via the ``classifiers`` argument. Classifiers " +"exist for all major open-source licenses." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:279 -msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." +msgid "" +"The \"license\" argument is more typically used to indicate differences from " +"well-known licenses, or to include your own, unique license. As a general " +"rule, it's a good idea to use a standard, well-known license, both to avoid " +"confusion and because some organizations avoid software whose license is " +"unapproved." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:287 @@ -1616,11 +2200,18 @@ msgid "classifiers" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:316 -msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." +msgid "" +"Provide a list of classifiers that categorize your project. For a full " +"listing, see https://pypi.org/classifiers/." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:319 -msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." +msgid "" +"Although the list of classifiers is often used to declare what Python " +"versions a project supports, this information is only used for searching & " +"browsing projects on PyPI, not for installing projects. To actually " +"restrict what Python versions a project can be installed on, use the :ref:" +"`python_requires` argument." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:327 @@ -1636,7 +2227,11 @@ msgid "project_urls" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:349 -msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." +msgid "" +"List additional relevant URLs about your project. This is the place to link " +"to bug trackers, source repositories, or where to support package " +"development. The string of the key is the exact text that will be displayed " +"on PyPI." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:355 @@ -1644,7 +2239,13 @@ msgid "packages" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:361 -msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." +msgid "" +"Set ``packages`` to a list of all :term:`packages ` in your " +"project, including their subpackages, sub-subpackages, etc. Although the " +"packages can be listed manually, ``setuptools.find_packages()`` finds them " +"automatically. Use the ``include`` keyword argument to find only the given " +"packages. Use the ``exclude`` keyword argument to omit packages that are " +"not intended to be released and installed." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:370 @@ -1652,15 +2253,23 @@ msgid "py_modules" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:376 -msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." +msgid "" +"If your project contains any single-file Python modules that aren't part of " +"a package, set ``py_modules`` to a list of the names of the modules (minus " +"the ``.py`` extension) in order to make :ref:`setuptools` aware of them." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:388 -msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgid "" +"\"install_requires\" should be used to specify what dependencies a project " +"minimally needs to run. When the project is installed by :ref:`pip`, this is " +"the specification that is used to install its dependencies." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:392 -msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." +msgid "" +"For more on using \"install_requires\" see :ref:`install_requires vs " +"Requirements files`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:398 @@ -1668,11 +2277,17 @@ msgid "python_requires" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:400 -msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" +msgid "" +"If your project only runs on certain Python versions, setting the " +"``python_requires`` argument to the appropriate :pep:`440` version specifier " +"string will prevent :ref:`pip` from installing the project on other Python " +"versions. For example, if your package is for Python 3+ only, write::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:407 -msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" +msgid "" +"If your package is for Python 2.6, 2.7, and all versions of Python 3 " +"starting with 3.3, write::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:412 @@ -1680,11 +2295,20 @@ msgid "And so on." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:416 -msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." +msgid "" +"Support for this feature is relatively recent. Your project's source " +"distributions and wheels (see :ref:`Packaging Your Project`) must be built " +"using at least version 24.2.0 of :ref:`setuptools` in order for the " +"``python_requires`` argument to be recognized and the appropriate metadata " +"generated." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:422 -msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." +msgid "" +"In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the " +"``python_requires`` metadata. Users with earlier versions of pip will be " +"able to download & install projects on any Python version regardless of the " +"projects' ``python_requires`` values." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:431 @@ -1692,15 +2316,25 @@ msgid "package_data" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:440 -msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." +msgid "" +"Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the " +"package’s implementation, or text files containing documentation that might " +"be of interest to programmers using the package. These files are called " +"\"package data\"." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:445 -msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." +msgid "" +"The value must be a mapping from package name to a list of relative path " +"names that should be copied into the package. The paths are interpreted as " +"relative to the directory containing the package." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:449 -msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." +msgid "" +"For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:457 @@ -1708,19 +2342,39 @@ msgid "data_files" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:463 -msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." +msgid "" +"Although configuring :ref:`Package Data` is sufficient for most needs, in " +"some cases you may need to place data files *outside* of your :term:" +"`packages `. The ``data_files`` directive allows you to do " +"that. It is mostly useful if you need to install files which are used by " +"other programs, which may be unaware of Python packages." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:469 -msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." +msgid "" +"Each ``(directory, files)`` pair in the sequence specifies the installation " +"directory and the files to install there. The ``directory`` must be a " +"relative path (although this may change in the future, see `wheel Issue #92 " +"`_). and it is interpreted relative " +"to the installation prefix (Python’s ``sys.prefix`` for a default " +"installation; ``site.USER_BASE`` for a user installation). Each file name in " +"``files`` is interpreted relative to the :file:`setup.py` script at the top " +"of the project source distribution." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:479 -msgid "For more information see the distutils section on `Installing Additional Files `_." +msgid "" +"For more information see the distutils section on `Installing Additional " +"Files `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:484 -msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." +msgid "" +"When installing packages as egg, ``data_files`` is not supported. So, if " +"your project uses :ref:`setuptools`, you must use ``pip`` to install it. " +"Alternatively, if you must use ``python setup.py``, then you need to pass " +"the ``--old-and-unmanageable`` option." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:491 @@ -1728,7 +2382,11 @@ msgid "scripts" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:493 -msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." +msgid "" +"Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made " +"scripts to install, the recommended approach to achieve cross-platform " +"compatibility is to use :ref:`console_scripts` entry points (see below)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:500 @@ -1736,11 +2394,17 @@ msgid "entry_points" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:509 -msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." +msgid "" +"Use this keyword to specify any plugins that your project provides for any " +"named entry points that may be defined by your project or others that you " +"depend on." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:512 -msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." +msgid "" +"For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:516 @@ -1752,11 +2416,20 @@ msgid "console_scripts" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:531 -msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgid "" +"Use \"console_script\" `entry points `_ to " +"register your script interfaces. You can then let the toolchain handle the " +"work of turning these interfaces into actual scripts [2]_. The scripts will " +"be generated during the install of your :term:`distribution `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:538 -msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." +msgid "" +"For more information, see `Automatic Script Creation `_ from " +"the `setuptools docs `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:545 @@ -1768,7 +2441,12 @@ msgid "Standards compliance for interoperability" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:550 -msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." +msgid "" +"Different Python projects may use different versioning schemes based on the " +"needs of that particular project, but all of them are required to comply " +"with the flexible :pep:`public version scheme <440#public-version-" +"identifiers>` specified in :pep:`440` in order to be supported in tools and " +"libraries like ``pip`` and ``setuptools``." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:556 @@ -1776,7 +2454,11 @@ msgid "Here are some examples of compliant version numbers::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:567 -msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." +msgid "" +"To further accommodate historical variations in approaches to version " +"numbering, :pep:`440` also defines a comprehensive technique for :pep:" +"`version normalisation <440#normalization>` that maps variant spellings of " +"different version numbers to a standardised canonical form." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:573 @@ -1788,11 +2470,16 @@ msgid "Semantic versioning (preferred)" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:578 -msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." +msgid "" +"For new projects, the recommended versioning scheme is based on `Semantic " +"Versioning `_, but adopts a different approach to " +"handling pre-releases and build metadata." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:582 -msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" +msgid "" +"The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE " +"numbering scheme, where the project author increments:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:585 @@ -1800,7 +2487,9 @@ msgid "MAJOR version when they make incompatible API changes," msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:586 -msgid "MINOR version when they add functionality in a backwards-compatible manner, and" +msgid "" +"MINOR version when they add functionality in a backwards-compatible manner, " +"and" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:587 @@ -1808,11 +2497,17 @@ msgid "MAINTENANCE version when they make backwards-compatible bug fixes." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:589 -msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." +msgid "" +"Adopting this approach as a project author allows users to make use of :pep:`" +"\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= " +"X.Y`` requires at least release X.Y, but also allows any later release with " +"a matching MAJOR version." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:594 -msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." +msgid "" +"Python projects adopting semantic versioning should abide by clauses 1-8 of " +"the `Semantic Versioning 2.0.0 specification `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:598 @@ -1820,15 +2515,23 @@ msgid "Date based versioning" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:600 -msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." +msgid "" +"Semantic versioning is not a suitable choice for all projects, such as those " +"with a regular time based release cadence and a deprecation process that " +"provides warnings for a number of releases prior to removal of a feature." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:604 -msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." +msgid "" +"A key advantage of date based versioning is that it is straightforward to " +"tell how old the base feature set of a particular release is given just the " +"version number." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:607 -msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." +msgid "" +"Version numbers for date based projects typically take the form of YEAR." +"MONTH (for example, ``12.04``, ``15.10``)." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:611 @@ -1836,11 +2539,16 @@ msgid "Serial versioning" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:613 -msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." +msgid "" +"This is the simplest possible versioning scheme, and consists of a single " +"number which is incremented every release." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:616 -msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." +msgid "" +"While serial versioning is very easy to manage as a developer, it is the " +"hardest to track as an end user, as serial version numbers convey little or " +"no information regarding API backwards compatibility." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:621 @@ -1848,7 +2556,11 @@ msgid "Hybrid schemes" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:623 -msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." +msgid "" +"Combinations of the above schemes are possible. For example, a project may " +"combine date based versioning with serial versioning to create a YEAR.SERIAL " +"numbering scheme that readily conveys the approximate age of a release, but " +"doesn't otherwise commit to a particular release cadence within the year." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:629 @@ -1856,7 +2568,9 @@ msgid "Pre-release versioning" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:631 -msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" +msgid "" +"Regardless of the base versioning scheme, pre-releases for a given final " +"release may be published as:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:634 @@ -1876,7 +2590,9 @@ msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:639 -msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." +msgid "" +"``pip`` and other modern Python package installers ignore pre-releases by " +"default when deciding which versions of dependencies to install." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:644 @@ -1884,11 +2600,19 @@ msgid "Local version identifiers" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:646 -msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." +msgid "" +"Public version identifiers are designed to support distribution via :term:" +"`PyPI `. Python's software distribution tools " +"also support the notion of a :pep:`local version identifier <440#local-" +"version-identifiers>`, which can be used to identify local development " +"builds not intended for publication, or modified variants of a release " +"maintained by a redistributor." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:653 -msgid "A local version identifier takes the form ``+``. For example::" +msgid "" +"A local version identifier takes the form ``" +"+``. For example::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:661 @@ -1896,7 +2620,10 @@ msgid "Working in \"development mode\"" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:663 -msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." +msgid "" +"Although not required, it's common to locally install your project in " +"\"editable\" or \"develop\" mode while you're working on it. This allows " +"your project to be both installed and editable in project form." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:667 @@ -1904,31 +2631,56 @@ msgid "Assuming you're in the root of your project directory, then run:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:674 -msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." +msgid "" +"Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` " +"refers to the current working directory, so together, it means to install " +"the current directory (i.e. your project) in editable mode. This will also " +"install any dependencies declared with \"install_requires\" and any scripts " +"declared with \"console_scripts\". Dependencies will be installed in the " +"usual, non-editable mode." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:680 -msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" +msgid "" +"It's fairly common to also want to install some of your dependencies in " +"editable mode as well. For example, supposing your project requires \"foo\" " +"and \"bar\", but you want \"bar\" installed from VCS in editable mode, then " +"you could construct a requirements file like so::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:688 -msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." +msgid "" +"The first line says to install your project and any dependencies. The second " +"line overrides the \"bar\" dependency, such that it's fulfilled from VCS, " +"not PyPI." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:692 -msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" +msgid "" +"If, however, you want \"bar\" installed from a local directory in editable " +"mode, the requirements file should look like this, with the local paths at " +"the top of the file::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:697 -msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." +msgid "" +"Otherwise, the dependency will be fulfilled from PyPI, due to the " +"installation order of the requirements file. For more on requirements " +"files, see the :ref:`Requirements File ` section in " +"the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:701 -msgid "Lastly, if you don't want to install any dependencies at all, you can run::" +msgid "" +"Lastly, if you don't want to install any dependencies at all, you can run::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:706 -msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." +msgid "" +"For more information, see the `Development Mode `_ section of the " +"`setuptools docs `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:713 @@ -1936,11 +2688,17 @@ msgid "Packaging your project" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:715 -msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." +msgid "" +"To have your project installable from a :term:`Package Index` like :term:" +"`PyPI `, you'll need to create a :term:" +"`Distribution ` (aka \":term:`Package `\") for your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:720 -msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" +msgid "" +"Before you can build wheels and sdists for your project, you'll need to " +"install the ``build`` package:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:737 @@ -1948,11 +2706,18 @@ msgid "Source distributions" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:739 -msgid "Minimally, you should create a :term:`Source Distribution `:" +msgid "" +"Minimally, you should create a :term:`Source Distribution `:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:755 -msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." +msgid "" +"A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built " +"Distribution`), and requires a build step when installed by pip. Even if " +"the distribution is pure Python (i.e. contains no extensions), it still " +"involves a build step to build out the installation metadata from :file:" +"`setup.py` and/or :file:`setup.cfg`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:763 @@ -1960,23 +2725,36 @@ msgid "Wheels" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:765 -msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." +msgid "" +"You should also create a wheel for your project. A wheel is a :term:`built " +"package ` that can be installed without needing to go " +"through the \"build\" process. Installing wheels is substantially faster for " +"the end user than installing from a source distribution." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:770 -msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." +msgid "" +"If your project is pure Python then you'll be creating a :ref:`\"Pure Python " +"Wheel\" (see section below) `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:773 -msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." +msgid "" +"If your project contains compiled extensions, then you'll be creating what's " +"called a :ref:`*Platform Wheel* (see section below) `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:776 -msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" +msgid "" +"If your project also supports Python 2 *and* contains no C extensions, then " +"you should create what's called a *Universal Wheel* by adding the following " +"to your :file:`setup.cfg` file:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:785 -msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." +msgid "" +"Only use this setting if your project does not have any C extensions *and* " +"supports Python 2 and 3." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:792 @@ -1984,7 +2762,9 @@ msgid "Pure Python Wheels" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:794 -msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." +msgid "" +"*Pure Python Wheels* contain no compiled extensions, and therefore only " +"require a single Python wheel." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:797 @@ -1993,11 +2773,16 @@ msgid "To build the wheel:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:811 -msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." +msgid "" +"The ``wheel`` package will detect that the code is pure Python, and build a " +"wheel that's named such that it's usable on any Python 3 installation. For " +"details on the naming of wheel files, see :pep:`425`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:815 -msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." +msgid "" +"If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both " +"files for you; this is useful when you don't need multiple wheels." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:821 @@ -2005,15 +2790,23 @@ msgid "Platform Wheels" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:823 -msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." +msgid "" +"*Platform Wheels* are wheels that are specific to a certain platform like " +"Linux, macOS, or Windows, usually due to containing compiled extensions." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:841 -msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." +msgid "" +"The ``wheel`` package will detect that the code is not pure Python, and " +"build a wheel that's named such that it's only usable on the platform that " +"it was built on. For details on the naming of wheel files, see :pep:`425`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:847 -msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." +msgid "" +":term:`PyPI ` currently supports uploads of " +"platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. " +"Details of the latter are defined in :pep:`513`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:855 @@ -2021,23 +2814,45 @@ msgid "Uploading your Project to PyPI" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:857 -msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." +msgid "" +"When you ran the command to create your distribution, a new directory ``dist/" +"`` was created under your project's root directory. That's where you'll find " +"your distribution file(s) to upload." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:861 -msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." +msgid "" +"These files are only created when you run the command to create your " +"distribution. This means that any time you change the source of your project " +"or the configuration in your :file:`setup.py` file, you will need to rebuild " +"these files again before you can distribute the changes to PyPI." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:866 -msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." +msgid "" +"Before releasing on main PyPI repo, you might prefer training with the `PyPI " +"test site `_ which is cleaned on a semi regular " +"basis. See :ref:`using-test-pypi` on how to setup your configuration in " +"order to use it." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:871 -msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." +msgid "" +"In other resources you may encounter references to using ``python setup.py " +"register`` and ``python setup.py upload``. These methods of registering and " +"uploading a package are **strongly discouraged** as it may use a plaintext " +"HTTP or unverified HTTPS connection on some Python versions, allowing your " +"username and password to be intercepted during transmission." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:877 -msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" +msgid "" +"The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to " +"ensure safety of all users, certain kinds of URLs and directives are " +"forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** " +"trying to upload your distribution, you should check to see if your brief / " +"long descriptions provided in :file:`setup.py` are valid. You can do this " +"by running :std:doc:`twine check ` on your package files::" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:888 @@ -2045,23 +2860,35 @@ msgid "Create an account" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:890 -msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." +msgid "" +"First, you need a :term:`PyPI ` user account. " +"You can create an account `using the form on the PyPI website `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:894 -msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." +msgid "" +"Now you'll create a PyPI `API token`_ so you will be able to securely upload " +"your project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:897 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." +msgid "" +"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " +"token`_; don't limit its scope to a particular project, since you are " +"creating a new project." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:901 -msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgid "" +"**Don't close the page until you have copied and saved the token — you won't " +"see that token again.**" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:904 -msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" +msgid "" +"To avoid having to copy and paste the token every time you upload, you can " +"create a :file:`$HOME/.pypirc` file:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:913 @@ -2072,7 +2899,8 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:70 #: ../source/guides/migrating-to-pypi-org.rst:109 #: ../source/guides/using-testpypi.rst:83 -msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." +msgid "" +"For more details, see the :ref:`specification ` for :file:`.pypirc`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:921 @@ -2080,28 +2908,46 @@ msgid "Upload your distributions" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:923 -msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." +msgid "" +"Once you have an account you can upload your distributions to :term:`PyPI " +"` using :ref:`twine`." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:926 -msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." +msgid "" +"The process for uploading a release is the same regardless of whether or not " +"the project already exists on PyPI - if it doesn't exist yet, it will be " +"automatically created when the first release is uploaded." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:930 -msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." +msgid "" +"For the second and subsequent releases, PyPI only requires that the version " +"number of the new release differ from any previous releases." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:937 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgid "" +"You can see if your package has successfully uploaded by navigating to the " +"URL ``https://pypi.org/project/`` where ``sampleproject`` is " +"the name of your project that you uploaded. It may take a minute or two for " +"your project to appear on the site." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:944 #: ../source/tutorials/installing-packages.rst:663 -msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." +msgid "" +"Depending on your platform, this may require root or Administrator access. :" +"ref:`pip` is currently considering changing this by `making user installs " +"the default behavior `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:950 -msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." +msgid "" +"Specifically, the \"console_script\" approach generates ``.exe`` files on " +"Windows, which are necessary because the OS special-cases ``.exe`` files. " +"Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for " +"Windows <397>` allow scripts to be used in many cases, but not all." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:5 @@ -2109,19 +2955,30 @@ msgid "Dropping support for older Python versions" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:7 -msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." +msgid "" +"Dropping support for older Python versions is supported by the standard :ref:" +"`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:9 -msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." +msgid "" +"Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification " +"by matching the current Python runtime and comparing it with the required " +"version in the package metadata. If they do not match, it will attempt to " +"install the last package distribution that supported that Python runtime." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:12 -msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." +msgid "" +"This mechanism can be used to drop support for older Python versions, by " +"amending the \"Requires-Python\" attribute in the package metadata." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:14 -msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." +msgid "" +"This guide is specifically for users of :ref:`setuptools`, other packaging " +"tools such as ``flit`` may offer similar functionality but users will need " +"to consult relevant documentation." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:17 @@ -2141,7 +2998,9 @@ msgid "The latest version of :ref:`twine` is used to upload the package," msgstr "" #: ../source/guides/dropping-older-python-versions.rst:23 -msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." +msgid "" +"The user installing the package has at least Pip 9.0, or a client that " +"supports the Metadata 1.2 specification." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:26 @@ -2149,15 +3008,26 @@ msgid "Dealing with the universal wheels" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:28 -msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." +msgid "" +"Traditionally, projects providing Python code that is semantically " +"compatible with both Python 2 and Python 3, produce :term:`wheels ` " +"that have a ``py2.py3`` tag in their names. When dropping support for Python " +"2, it is important not to forget to change this tag to just ``py3``. It is " +"often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` " +"section by setting ``universal = 1`` if they use setuptools." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:36 -msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" +msgid "" +"If you use this method, either remove this option or section, or explicitly " +"set ``universal`` to ``0``:" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:48 -msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." +msgid "" +"Since it is possible to override the :file:`setup.cfg` settings via CLI " +"flags, make sure that your scripts don't have ``--universal`` in your " +"package creation scripts." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:53 @@ -2169,7 +3039,9 @@ msgid "1. Download the newest version of Setuptools" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:58 -msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." +msgid "" +"Ensure that before you generate source distributions or binary " +"distributions, you update Setuptools and install twine." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:60 @@ -2185,7 +3057,9 @@ msgid "2. Specify the version ranges for supported Python distributions" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:79 -msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." +msgid "" +"You can specify version ranges and exclusion rules, such as at least Python " +"3. Or, Python 2.7, 3.4 and beyond." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:81 @@ -2201,7 +3075,10 @@ msgid "Examples::" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:86 -msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." +msgid "" +"The way to set those values is within the call to ``setup`` within your :" +"file:`setup.py` script. This will insert the ``Requires-Python`` metadata " +"values based on the argument you provide in ``python_requires``." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:101 @@ -2209,11 +3086,16 @@ msgid "3. Validating the Metadata before publishing" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:103 -msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." +msgid "" +"Within a Python source package (the zip or the tar-gz file you download) is " +"a text file called PKG-INFO." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:105 -msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." +msgid "" +"This file is generated by Distutils or :ref:`setuptools` when it generates " +"the source package. The file contains a set of keys and values, the list of " +"keys is part of the PyPa standard metadata format." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:108 @@ -2225,11 +3107,14 @@ msgid "Validate that the following is in place, before publishing the package:" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:114 -msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." +msgid "" +"If you have upgraded correctly, the Metadata-Version value should be 1.2 or " +"higher." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:115 -msgid "The Requires-Python field is set and matches your specification in setup.py." +msgid "" +"The Requires-Python field is set and matches your specification in setup.py." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:118 @@ -2237,7 +3122,9 @@ msgid "4. Using Twine to publish" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:120 -msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." +msgid "" +"Twine has a number of advantages, apart from being faster it is now the " +"supported method for publishing packages." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:122 @@ -2249,7 +3136,9 @@ msgid "Dropping a Python release" msgstr "" #: ../source/guides/dropping-older-python-versions.rst:127 -msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." +msgid "" +"Once you have published a package with the Requires-Python metadata, you can " +"then make a further update removing that Python runtime from support." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:129 @@ -2257,11 +3146,17 @@ msgid "It must be done in this order for the automated fallback to work." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:131 -msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." +msgid "" +"For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 " +"of your package." msgstr "" #: ../source/guides/dropping-older-python-versions.rst:133 -msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." +msgid "" +"If you were then to update the version string to \">=3.5\", and publish a " +"new version 2.0.0 of your package, any users running Pip 9.0+ from version " +"2.7 will have version 1.0.0 of the package installed, and any >=3.5 users " +"will receive version 2.0.0." msgstr "" #: ../source/guides/hosting-your-own-index.rst:5 @@ -2269,15 +3164,25 @@ msgid "Hosting your own simple repository" msgstr "" #: ../source/guides/hosting-your-own-index.rst:8 -msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." +msgid "" +"If you wish to host your own simple repository [1]_, you can either use a " +"software package like `devpi`_ or you can use simply create the proper " +"directory structure and use any web server that can serve static files and " +"generate an autoindex." msgstr "" #: ../source/guides/hosting-your-own-index.rst:13 -msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" +msgid "" +"In either case, since you'll be hosting a repository that is likely not in " +"your user's default repositories, you should instruct them in your project's " +"description to configure their installer appropriately. For example with pip:" msgstr "" #: ../source/guides/hosting-your-own-index.rst:29 -msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." +msgid "" +"In addition, it is **highly** recommended that you serve your repository " +"with valid HTTPS. At this time, the security of your user's installations " +"depends on all repositories using a valid HTTPS setup." msgstr "" #: ../source/guides/hosting-your-own-index.rst:35 @@ -2285,34 +3190,45 @@ msgid "\"Manual\" repository" msgstr "" #: ../source/guides/hosting-your-own-index.rst:37 -msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" +msgid "" +"The directory layout is fairly simple, within a root directory you need to " +"create a directory for each project. This directory should be the normalized " +"name (as defined by :pep:`503`) of the project. Within each of these " +"directories simply place each of the downloadable files. If you have the " +"projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the " +"version 0.1) You should end up with a structure that looks like::" msgstr "" #: ../source/guides/hosting-your-own-index.rst:51 -msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." +msgid "" +"Once you have this layout, simply configure your webserver to serve the root " +"directory with autoindex enabled. For an example using the built in Web " +"server in `Twisted`_, you would simply run ``twistd -n web --path .`` and " +"then instruct users to add the URL to their installer's configuration." msgstr "" #: ../source/guides/hosting-your-own-index.rst:58 -msgid "For complete documentation of the simple repository protocol, see :pep:`503`." +msgid "" +"For complete documentation of the simple repository protocol, see :pep:`503`." msgstr "" -#: ../source/guides/index.rst:8 #: ../source/guides/index.rst:8 msgid "Installing Packages:" msgstr "" -#: ../source/guides/index.rst:20 #: ../source/guides/index.rst:20 msgid "Building and Publishing Projects:" msgstr "" -#: ../source/guides/index.rst:38 #: ../source/guides/index.rst:38 msgid "Miscellaneous:" msgstr "" #: ../source/guides/index.rst:4 -msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." +msgid "" +"**Guides** are focused on accomplishing a specific task and assume that you " +"are already familiar with the basics of Python packaging. If you're looking " +"for an introduction to packaging, see :doc:`/tutorials/index`." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:5 @@ -2325,7 +3241,10 @@ msgid "2014-12-24" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:14 -msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." +msgid "" +"Mirroring or caching of PyPI can be used to speed up local package " +"installation, allow offline work, handle corporate firewalls or just plain " +"Internet flakiness." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:17 @@ -2337,11 +3256,15 @@ msgid "pip provides local caching options," msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:20 -msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" +msgid "" +"devpi provides higher-level caching option, potentially shared amongst many " +"users or machines, and" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:22 -msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." +msgid "" +"bandersnatch provides a local complete mirror of all PyPI :term:`packages " +"`." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:27 @@ -2349,15 +3272,23 @@ msgid "Caching with pip" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:29 -msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" +msgid "" +"pip provides a number of facilities for speeding up installation by using " +"local cached copies of :term:`packages `:" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:32 -msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." +msgid "" +"`Fast & local installs `_ by downloading all the requirements for a project and " +"then pointing pip at those downloaded files instead of going to PyPI." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:36 -msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" +msgid "" +"A variation on the above which pre-builds the installation files for the " +"requirements using `python -m pip wheel `_::" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:45 @@ -2365,7 +3296,10 @@ msgid "Caching with devpi" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:47 -msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." +msgid "" +"devpi is a caching proxy server which you run on your laptop, or some other " +"machine you know will always be available to you. See the `devpi " +"documentation for getting started`__." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:55 @@ -2373,11 +3307,18 @@ msgid "Complete mirror with bandersnatch" msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:57 -msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." +msgid "" +"bandersnatch will set up a complete local mirror of all PyPI :term:`packages " +"` (externally-hosted packages are not mirrored). See " +"the `bandersnatch documentation for getting that going`__." msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:63 -msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." +msgid "" +"A benefit of devpi is that it will create a mirror which includes :term:" +"`packages ` that are external to PyPI, unlike " +"bandersnatch which will only cache :term:`packages ` " +"hosted on PyPI." msgstr "" #: ../source/guides/installing-scientific-packages.rst:5 @@ -2385,19 +3326,38 @@ msgid "Installing scientific packages" msgstr "" #: ../source/guides/installing-scientific-packages.rst:11 -msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." +msgid "" +"Scientific software tends to have more complex dependencies than most, and " +"it will often have multiple build options to take advantage of different " +"kinds of hardware, or to interoperate with different pieces of external " +"software." msgstr "" #: ../source/guides/installing-scientific-packages.rst:16 -msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." +msgid "" +"In particular, `NumPy `__, which provides the basis " +"for most of the software in the `scientific Python stack `__ can be configured to interoperate with " +"different FORTRAN libraries, and can take advantage of different levels of " +"vectorised instructions available in modern CPUs." msgstr "" #: ../source/guides/installing-scientific-packages.rst:22 -msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." +msgid "" +"Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built " +"32-bit and 64-bit binaries in the ``wheel`` format are available for all " +"major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, " +"that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, " +"so they may not provide optimal linear algebra performance." msgstr "" #: ../source/guides/installing-scientific-packages.rst:29 -msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." +msgid "" +"There are a number of alternative options for obtaining scientific Python " +"libraries (or any other Python libraries that require a compilation " +"environment to install from source and don't provide pre-built wheel files " +"on PyPI)." msgstr "" #: ../source/guides/installing-scientific-packages.rst:35 @@ -2405,7 +3365,12 @@ msgid "Building from source" msgstr "" #: ../source/guides/installing-scientific-packages.rst:37 -msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." +msgid "" +"The same complexity which makes it difficult to distribute NumPy (and many " +"of the projects that depend on it) as wheel files also make them difficult " +"to build from source yourself. However, for intrepid folks that are willing " +"to spend the time wrangling compilers and linkers for both C and FORTRAN, " +"building from source is always an option." msgstr "" #: ../source/guides/installing-scientific-packages.rst:45 @@ -2413,11 +3378,18 @@ msgid "Linux distribution packages" msgstr "" #: ../source/guides/installing-scientific-packages.rst:47 -msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." +msgid "" +"For Linux users, the system package manager will often have pre-compiled " +"versions of various pieces of scientific software, including NumPy and other " +"parts of the scientific Python stack." msgstr "" #: ../source/guides/installing-scientific-packages.rst:51 -msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." +msgid "" +"If using versions which may be several months old is acceptable, then this " +"is likely to be a good option (just make sure to allow access to " +"distributions installed into the system Python when using virtual " +"environments)." msgstr "" #: ../source/guides/installing-scientific-packages.rst:57 @@ -2425,23 +3397,42 @@ msgid "Windows installers" msgstr "" #: ../source/guides/installing-scientific-packages.rst:59 -msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." +msgid "" +"Many Python projects that don't (or can't) currently publish wheel files at " +"least publish Windows installers, either on PyPI or on their project " +"download page. Using these installers allows users to avoid the need to set " +"up a suitable environment to build extensions locally." msgstr "" #: ../source/guides/installing-scientific-packages.rst:64 -msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." +msgid "" +"The extensions provided in these installers are typically compatible with " +"the CPython Windows installers published on python.org." msgstr "" #: ../source/guides/installing-scientific-packages.rst:67 -msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." +msgid "" +"For projects which don't provide their own Windows installers (and even some " +"which do), Christoph Gohlke at the University of California provides a " +"`collection of Windows installers `__. Many Python users on Windows have reported a positive experience with " +"these prebuilt versions." msgstr "" #: ../source/guides/installing-scientific-packages.rst:73 -msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." +msgid "" +"As with Linux system packages, the Windows installers will only install into " +"a system Python installation - they do not support installation in virtual " +"environments. Allowing access to distributions installed into the system " +"Python when using virtual environments is a common approach to working " +"around this limitation." msgstr "" #: ../source/guides/installing-scientific-packages.rst:79 -msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." +msgid "" +"The :term:`Wheel` project also provides a :command:`wheel convert` " +"subcommand that can convert a Windows :command:`bdist_wininst` installer to " +"a wheel." msgstr "" #: ../source/guides/installing-scientific-packages.rst:86 @@ -2449,11 +3440,18 @@ msgid "macOS installers and package managers" msgstr "" #: ../source/guides/installing-scientific-packages.rst:88 -msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." +msgid "" +"Similar to the situation on Windows, many projects (including NumPy) publish " +"macOS installers that are compatible with the macOS CPython binaries " +"published on python.org." msgstr "" #: ../source/guides/installing-scientific-packages.rst:92 -msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" +msgid "" +"macOS users also have access to Linux distribution style package managers " +"such as ``MacPorts``. The SciPy site has more details on using MacPorts to " +"install the `scientific Python stack `__" msgstr "" #: ../source/guides/installing-scientific-packages.rst:99 @@ -2461,11 +3459,16 @@ msgid "SciPy distributions" msgstr "" #: ../source/guides/installing-scientific-packages.rst:101 -msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." +msgid "" +"The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use " +"and update format." msgstr "" #: ../source/guides/installing-scientific-packages.rst:105 -msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." +msgid "" +"Some of these distributions may not be compatible with the standard ``pip`` " +"and ``virtualenv`` based toolchain." msgstr "" #: ../source/guides/installing-scientific-packages.rst:109 @@ -2474,11 +3477,25 @@ msgid "Spack" msgstr "" #: ../source/guides/installing-scientific-packages.rst:110 -msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." +msgid "" +"`Spack `_ is a flexible package manager " +"designed to support multiple versions, configurations, platforms, and " +"compilers. It was built to support the needs of large supercomputing centers " +"and scientific application teams, who must often build software many " +"different ways. Spack is not limited to Python; it can install packages for " +"``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-" +"destructive; installing a new version of one package does not break existing " +"installations, so many configurations can coexist on the same system." msgstr "" #: ../source/guides/installing-scientific-packages.rst:119 -msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." +msgid "" +"Spack offers a simple but powerful syntax that allows users to specify " +"versions and configuration options concisely. Package files are written in " +"pure Python, and they are templated so that it is easy to swap compilers, " +"dependency implementations (like MPI), versions, and build options with a " +"single package file. Spack also generates *module* files so that packages " +"can be loaded and unloaded from the user's environment." msgstr "" #: ../source/guides/installing-scientific-packages.rst:128 @@ -2486,11 +3503,29 @@ msgid "The conda cross-platform package manager" msgstr "" #: ../source/guides/installing-scientific-packages.rst:130 -msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." +msgid "" +"`Anaconda `_ is a Python distribution " +"published by Anaconda, Inc. It is a stable collection of Open Source " +"packages for big data and scientific use. As of the 5.0 release of " +"Anaconda, about 200 packages are installed by default, and a total of " +"400-500 can be installed and updated from the Anaconda repository." msgstr "" #: ../source/guides/installing-scientific-packages.rst:136 -msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." +msgid "" +"``conda`` is an open source (BSD licensed) package management system and " +"environment management system included in Anaconda that allows users to " +"install multiple versions of binary software packages and their " +"dependencies, and easily switch between them. It is a cross-platform tool " +"working on Windows, macOS, and Linux. Conda can be used to package up and " +"distribute all kinds of packages, it is not limited to just Python packages. " +"It has full support for native virtual environments. Conda makes " +"environments first-class citizens, making it easy to create independent " +"environments even for C libraries. It is written in Python, but is Python-" +"agnostic. Conda manages Python itself as a package, so that :command:`conda " +"update python` is possible, in contrast to pip, which only manages Python " +"packages. Conda is available in Anaconda and Miniconda (an easy-to-install " +"download with just Python and conda)." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:2 @@ -2498,15 +3533,28 @@ msgid "Installing stand alone command line tools" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:4 -msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." +msgid "" +"Many packages have command line entry points. Examples of this type of " +"application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:10 -msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." +msgid "" +"Usually you want to be able to access these from anywhere, but installing " +"packages and their dependencies to the same global environment can cause " +"version conflicts and break dependencies the operating system has on Python " +"packages." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:15 -msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." +msgid "" +":ref:`pipx` solves this by creating a virtual environment for each package, " +"while also ensuring that package's applications are accessible through a " +"directory that is on your ``$PATH``. This allows each package to be upgraded " +"or uninstalled without causing conflicts with other packages, and allows you " +"to safely run the program from anywhere." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:21 @@ -2518,11 +3566,14 @@ msgid "``pipx`` is installed with ``pip``:" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:30 -msgid "You may need to restart your terminal for the path updates to take effect." +msgid "" +"You may need to restart your terminal for the path updates to take effect." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:32 -msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." +msgid "" +"Now you can install packages with ``pipx install`` and access the package's " +"entry point(s) from anywhere." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:39 @@ -2531,7 +3582,9 @@ msgid "For example" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:59 -msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." +msgid "" +"To see a list of packages installed with pipx and which CLI applications are " +"available, use ``pipx list``." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:79 @@ -2543,7 +3596,9 @@ msgid "``pipx`` can be upgraded or uninstalled with pip" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:93 -msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." +msgid "" +"``pipx`` also allows you to install and run the latest version of a cli tool " +"in a temporary, ephemeral environment." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:106 @@ -2551,7 +3606,9 @@ msgid "To see the full list of commands ``pipx`` offers, run" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:112 -msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." +msgid "" +"You can learn more about ``pipx`` at its homepage, https://github.com/pypa/" +"pipx." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:5 @@ -2563,19 +3620,35 @@ msgid "2015-09-17" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:11 -msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." +msgid "" +"This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:" +"`wheel` using Linux package managers." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:14 -msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." +msgid "" +"If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:" +"`installing_requirements` section instead." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:18 -msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." +msgid "" +"Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, " +"and :ref:`wheel` supported by a specific Linux Distribution to be outdated " +"by the time it's released to the public, and updates generally only occur " +"for security reasons, not for feature updates. For certain Distributions, " +"there are additional repositories that can be enabled to provide newer " +"versions. The repositories we know about are explained below." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:25 -msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." +msgid "" +"Also note that it's somewhat common for Distributions to apply patches for " +"the sake of security and normalization to their own standards. In some " +"cases, this can lead to bugs or unexpected behaviors that vary from the " +"original unpatched versions. When this is known, we will make note of it " +"below." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:32 @@ -2607,7 +3680,11 @@ msgid "Python 3: ``sudo dnf install python3 python3-wheel``" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:53 -msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" +msgid "" +"To get newer versions of pip, setuptools, and wheel for Python 2, you can " +"enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:63 @@ -2615,7 +3692,9 @@ msgid "CentOS/RHEL" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:65 -msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." +msgid "" +"CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core " +"repositories, although :ref:`setuptools` is installed by default." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:68 @@ -2623,7 +3702,11 @@ msgid "To install pip and wheel for the system Python, there are two options:" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:70 -msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" +msgid "" +"Enable the `EPEL repository `_ using " +"`these instructions `__. On EPEL 6 and EPEL7, you can " +"install pip like so::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:77 @@ -2631,11 +3714,16 @@ msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:81 -msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." +msgid "" +"Since EPEL only offers extra, non-conflicting packages, EPEL does not offer " +"setuptools, since it's in the core repository." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:85 -msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" +msgid "" +"Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:92 @@ -2643,15 +3731,21 @@ msgid "To additionally upgrade setuptools, run::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:97 -msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" +msgid "" +"To install pip, wheel, and setuptools, in a parallel, non-system environment " +"(using yum) then there are two options:" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:101 -msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." +msgid "" +"Use the \"Software Collections\" feature to enable a parallel collection " +"that includes pip, setuptools, and wheel." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:104 -msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" +msgid "" +"For Redhat, see here: http://developers.redhat.com/products/" +"softwarecollections/overview/" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:106 @@ -2663,7 +3757,11 @@ msgid "Be aware that collections may not contain the most recent versions." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:110 -msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." +msgid "" +"Enable the `IUS repository `_ and install " +"one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which " +"are kept fairly up to date." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:116 @@ -2685,7 +3783,10 @@ msgid "Debian/Ubuntu" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:150 -msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." +msgid "" +"Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" " +"`_ by default, " +"which is a significant behavior change that can be surprising to some users." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:156 @@ -2693,7 +3794,9 @@ msgid "Arch Linux" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:168 -msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." +msgid "" +"Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the " +"only option is to manually place the repo files as described." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 @@ -2701,11 +3804,18 @@ msgid "Installing packages using pip and virtual environments" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 -msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." +msgid "" +"This guide discusses how to install packages using :ref:`pip` and a virtual " +"environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` " +"for Python 2. These are the lowest-level tools for managing Python packages " +"and are recommended if higher-level tools do not suit your needs." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 -msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." +msgid "" +"This doc uses the term **package** to refer to a :term:`Distribution " +"Package` which is different from an :term:`Import Package` that which is " +"used to import modules in your Python source code." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 @@ -2713,15 +3823,24 @@ msgid "Installing pip" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 -msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." +msgid "" +":ref:`pip` is the reference Python package manager. It's used to install and " +"update packages. You'll need to make sure you have the latest version of pip " +"installed." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 -msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." +msgid "" +"Debian and most other distributions include a `python-pip`_ package, if you " +"want to use the Linux distribution-provided versions of pip see :doc:`/" +"guides/installing-using-linux-tools`." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 -msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" +msgid "" +"You can also install pip yourself to ensure you have the latest version. " +"It's recommended to use the system pip to bootstrap a user installation of " +"pip:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 @@ -2729,7 +3848,9 @@ msgid "Afterwards, you should have the newest pip installed in your user site:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 -msgid "The Python installers for Windows include pip. You should be able to access pip using:" +msgid "" +"The Python installers for Windows include pip. You should be able to access " +"pip using:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 @@ -2741,11 +3862,19 @@ msgid "Installing virtualenv" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 -msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." +msgid "" +"If you are using Python 3.3 or newer, the :mod:`venv` module is the " +"preferred way to create and manage virtual environments. venv is included in " +"the Python standard library and requires no additional installation. If you " +"are using venv, you may skip this section." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 -msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." +msgid "" +":ref:`virtualenv` is used to manage Python packages for different projects. " +"Using virtualenv allows you to avoid installing Python packages globally " +"which could break system tools or other projects. You can install virtualenv " +"using pip." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 @@ -2753,15 +3882,28 @@ msgid "Creating a virtual environment" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 -msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." +msgid "" +":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to " +"manage separate package installations for different projects. They " +"essentially allow you to create a \"virtual\" isolated Python installation " +"and install packages into that virtual installation. When you switch " +"projects, you can simply create a new virtual environment and not have to " +"worry about breaking the packages installed in the other environments. It is " +"always recommended to use a virtual environment while developing Python " +"applications." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 -msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." +msgid "" +"To create a virtual environment, go to your project's directory and run " +"venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the " +"below commands." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 -msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." +msgid "" +"The second argument is the location to create the virtual environment. " +"Generally, you can just create this in your project and call it ``env``." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 @@ -2769,7 +3911,9 @@ msgid "venv will create a virtual Python installation in the ``env`` folder." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 -msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." +msgid "" +"You should exclude your virtual environment directory from your version " +"control system using ``.gitignore`` or similar." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 @@ -2777,15 +3921,24 @@ msgid "Activating a virtual environment" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 -msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." +msgid "" +"Before you can start installing or using packages in your virtual " +"environment you'll need to *activate* it. Activating a virtual environment " +"will put the virtual environment-specific ``python`` and ``pip`` executables " +"into your shell's ``PATH``." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 -msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." +msgid "" +"You can confirm you're in the virtual environment by checking the location " +"of your Python interpreter, it should point to the ``env`` directory." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 -msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." +msgid "" +"As long as your virtual environment is activated pip will install packages " +"into that specific environment and you'll be able to import and use packages " +"in your Python application." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 @@ -2793,11 +3946,16 @@ msgid "Leaving the virtual environment" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 -msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" +msgid "" +"If you want to switch projects or otherwise leave your virtual environment, " +"simply run:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 -msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." +msgid "" +"If you want to re-enter the virtual environment just follow the same " +"instructions above about activating a virtual environment. There's no need " +"to re-create the virtual environment." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 @@ -2805,11 +3963,14 @@ msgid "Installing packages" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 -msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" +msgid "" +"Now that you're in your virtual environment you can install packages. Let's " +"install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 -msgid "pip should download requests and all of its dependencies and install them:" +msgid "" +"pip should download requests and all of its dependencies and install them:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 @@ -2817,7 +3978,10 @@ msgid "Installing specific versions" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 -msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" +msgid "" +"pip allows you to specify which version of a package to install using :term:" +"`version specifiers `. For example, to install a specific " +"version of ``requests``:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 @@ -2833,7 +3997,9 @@ msgid "Installing extras" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 -msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" +msgid "" +"Some packages have optional `extras`_. You can tell pip to install these by " +"specifying the extra in brackets:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 @@ -2845,7 +4011,10 @@ msgid "pip can install a package directly from source, for example:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 -msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" +msgid "" +"Additionally, pip can install packages from source in `development mode`_, " +"meaning that changes to the source directory will immediately affect the " +"installed package without needing to re-install:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 @@ -2853,11 +4022,15 @@ msgid "Installing from version control systems" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 -msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" +msgid "" +"pip can install packages directly from their version control system. For " +"example, you can install directly from a git repository:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 -msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." +msgid "" +"For more information on supported version control systems and syntax, see " +"pip's documentation on :ref:`VCS Support `." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 @@ -2866,15 +4039,23 @@ msgid "Installing from local archives" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 -msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" +msgid "" +"If you have a local copy of a :term:`Distribution Package`'s archive (a zip, " +"wheel, or tar file) you can install it directly with pip:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 -msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" +msgid "" +"If you have a directory containing archives of multiple packages, you can " +"tell pip to look for packages there and not to use the :term:`Python Package " +"Index (PyPI)` at all:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 -msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." +msgid "" +"This is useful if you are installing packages on a system with limited " +"connectivity or if you want to strictly control the origin of distribution " +"packages." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 @@ -2882,11 +4063,16 @@ msgid "Using other package indexes" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 -msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" +msgid "" +"If you want to download packages from a different index than the :term:" +"`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 -msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" +msgid "" +"If you want to allow packages from both the :term:`Python Package Index " +"(PyPI)` and a separate index, you can use the ``--extra-index-url`` flag " +"instead:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 @@ -2895,7 +4081,9 @@ msgid "Upgrading packages" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 -msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" +msgid "" +"pip can upgrade packages in-place using the ``--upgrade`` flag. For example, " +"to install the latest version of ``requests`` and all of its dependencies:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 @@ -2903,11 +4091,16 @@ msgid "Using requirements files" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 -msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" +msgid "" +"Instead of installing packages individually, pip allows you to declare all " +"dependencies in a :ref:`Requirements File `. For " +"example you could create a :file:`requirements.txt` file containing:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 -msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" +msgid "" +"And tell pip to install all of the packages in this file using the ``-r`` " +"flag:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 @@ -2915,7 +4108,9 @@ msgid "Freezing dependencies" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 -msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" +msgid "" +"Pip can export a list of all installed packages and their versions using the " +"``freeze`` command:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 @@ -2923,7 +4118,9 @@ msgid "Which will output a list of package specifiers such as:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 -msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." +msgid "" +"This is useful for creating :ref:`pip:Requirements Files` that can re-create " +"the exact versions of all packages installed in an environment." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:2 @@ -2931,7 +4128,11 @@ msgid "Making a PyPI-friendly README" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:4 -msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." +msgid "" +"README files can help your users understand your project and can be used to " +"set your project's description on PyPI. This guide helps you create a README " +"in a PyPI-friendly format and include your README in your package so it " +"appears on PyPI." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:9 @@ -2939,11 +4140,16 @@ msgid "Creating a README file" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:11 -msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." +msgid "" +"README files for Python projects are often named ``README``, ``README.txt``, " +"``README.rst``, or ``README.md``." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:13 -msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" +msgid "" +"For your README to display properly on PyPI, choose a markup language " +"supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:16 @@ -2951,15 +4157,21 @@ msgid "plain text" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:17 -msgid "`reStructuredText `_ (without Sphinx extensions)" +msgid "" +"`reStructuredText `_ (without " +"Sphinx extensions)" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:18 -msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" +msgid "" +"Markdown (`GitHub Flavored Markdown `_ by " +"default, or `CommonMark `_)" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:21 -msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." +msgid "" +"It's customary to save your README file in the root of your project, in the " +"same directory as your :file:`setup.py` file." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:25 @@ -2967,7 +4179,10 @@ msgid "Including your README in your package's metadata" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:27 -msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." +msgid "" +"To include your README's contents as your package description, set your " +"project's ``Description`` and ``Description-Content-Type`` metadata, " +"typically in your project's :file:`setup.py` file." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:33 @@ -2979,15 +4194,23 @@ msgid ":ref:`description-content-type-optional`" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:36 -msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." +msgid "" +"For example, to set these values in a package's :file:`setup.py` file, use " +"``setup()``'s ``long_description`` and ``long_description_content_type``." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:39 -msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." +msgid "" +"Set the value of ``long_description`` to the contents (not the path) of the " +"README file itself. Set the ``long_description_content_type`` to an accepted " +"``Content-Type``-style value for your README file's markup, such as ``text/" +"plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:45 -msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" +msgid "" +"If you're using GitHub-flavored Markdown to write a project's description, " +"ensure you upgrade the following tools:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:60 @@ -3007,11 +4230,16 @@ msgid "``twine >= 1.11.0``" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:66 -msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" +msgid "" +"It's recommended that you use ``twine`` to upload the project's distribution " +"packages:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:72 -msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" +msgid "" +"For example, see this :file:`setup.py` file, which reads the contents of :" +"file:`README.md` as ``long_description`` and identifies the markup as GitHub-" +"flavored Markdown:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:95 @@ -3019,23 +4247,36 @@ msgid "Validating reStructuredText markup" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:97 -msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." +msgid "" +"If your README is written in reStructuredText, any invalid markup will " +"prevent it from rendering, causing PyPI to instead just show the README's " +"raw source." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:100 -msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." +msgid "" +"Note that Sphinx extensions used in docstrings, such as `directives and " +"roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```" +"\"), are not allowed here and will result in error messages like \"``Error: " +"Unknown interpreted text role \"py:func\".``\"." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:105 -msgid "You can check your README for markup errors before uploading as follows:" +msgid "" +"You can check your README for markup errors before uploading as follows:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:107 -msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" +msgid "" +"Install the latest version of `twine `_; " +"version 1.12.0 or higher is required:" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:122 -msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." +msgid "" +"Build the sdist and wheel for your project as described under :ref:" +"`Packaging Your Project`." msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:125 @@ -3043,7 +4284,10 @@ msgid "Run ``twine check`` on the sdist and wheel::" msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:129 -msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." +msgid "" +"This command will report any problems rendering your README. If your markup " +"renders fine, the command will output ``Checking distribution FILENAME: " +"Passed``." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:4 @@ -3051,7 +4295,11 @@ msgid "Migrating to PyPI.org" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:6 -msgid ":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``." +msgid "" +":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``." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:12 @@ -3063,15 +4311,21 @@ msgid "``pypi.org`` is the default upload platform as of September 2016." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:16 -msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." +msgid "" +"Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. " +"As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:19 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:22 -msgid "The default upload settings switched to ``pypi.org`` in the following versions:" +msgid "" +"The default upload settings switched to ``pypi.org`` in the following " +"versions:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:24 @@ -3099,19 +4353,32 @@ msgid "Python 3.6.0 (``distutils`` update)" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:31 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:48 -msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." +msgid "" +"Then simply delete the line starting with ``repository`` and you will use " +"your upload tool's default URL." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:51 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:67 -msgid "(``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.)" +msgid "" +"(``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.)" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:73 @@ -3119,15 +4386,22 @@ msgid "Registering package names & metadata" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:75 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:79 -msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" +msgid "" +"As a result, attempting explicit registration after switching to using PyPI." +"org for uploads will give the following error message::" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:84 -msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." +msgid "" +"The solution is to skip the registration step, and proceed directly to " +"uploading artifacts." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:89 @@ -3136,7 +4410,12 @@ msgid "Using TestPyPI" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:91 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:113 @@ -3144,7 +4423,10 @@ msgid "Registering new user accounts" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:115 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:121 @@ -3152,7 +4434,11 @@ msgid "Browsing packages" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:123 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:130 @@ -3168,7 +4454,9 @@ msgid "Managing published packages and releases" msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:137 -msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." +msgid "" +"``pypi.org`` provides a fully functional interface for logged in users to " +"manage their published packages and releases." msgstr "" #: ../source/guides/multi-version-installs.rst:5 @@ -3176,23 +4464,51 @@ msgid "Multi-version installs" msgstr "" #: ../source/guides/multi-version-installs.rst:8 -msgid "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``)." +msgid "" +"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``)." msgstr "" #: ../source/guides/multi-version-installs.rst:13 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/multi-version-installs.rst:19 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/multi-version-installs.rst:31 -msgid "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 ``python -c ''`` to invoke the application's main entry point directly." +msgid "" +"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 ``python -c ''`` to invoke the application's main " +"entry point directly." msgstr "" #: ../source/guides/multi-version-installs.rst:38 -msgid "Refer to the `pkg_resources documentation `__ for more details." +msgid "" +"Refer to the `pkg_resources documentation `__ for more details." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:5 @@ -3204,7 +4520,12 @@ msgid "2013-12-08" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:10 -msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." +msgid "" +"One of the features of the CPython reference interpreter is that, in " +"addition to allowing the execution of Python code, it also exposes a rich C " +"API for use by other software. One of the most common uses of this C API is " +"to create importable C extensions that allow things which aren't always easy " +"to achieve in pure Python code." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:20 @@ -3216,27 +4537,66 @@ msgid "Use cases" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:25 -msgid "The typical use cases for binary extensions break down into just three conventional categories:" +msgid "" +"The typical use cases for binary extensions break down into just three " +"conventional categories:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:28 -msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." +msgid "" +"**accelerator modules**: these modules are completely self-contained, and " +"are created solely to run faster than the equivalent pure Python code runs " +"in CPython. Ideally, accelerator modules will always have a pure Python " +"equivalent to use as a fallback if the accelerated version isn't available " +"on a given system. The CPython standard library makes extensive use of " +"accelerator modules. *Example*: When importing ``datetime``, Python falls " +"back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not " +"available." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:39 -msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." +msgid "" +"**wrapper modules**: these modules are created to expose existing C " +"interfaces to Python code. They may either expose the underlying C interface " +"directly, or else expose a more \"Pythonic\" API that makes use of Python " +"language features to make the API easier to use. The CPython standard " +"library makes extensive use of wrapper modules. *Example*: `functools.py " +"`_ is a " +"Python module wrapper for `_functoolsmodule.c `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:47 -msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." +msgid "" +"**low-level system access**: these modules are created to access lower level " +"features of the CPython runtime, the operating system, or the underlying " +"hardware. Through platform specific code, extension modules may achieve " +"things that aren't possible in pure Python code. A number of CPython " +"standard library modules are written in C in order to access interpreter " +"internals that aren't exposed at the language level. *Example*: ``sys``, " +"which comes from `sysmodule.c `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:56 -msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." +msgid "" +"One particularly notable feature of C extensions is that, when they don't " +"need to call back into the interpreter runtime, they can release CPython's " +"global interpreter lock around long-running operations (regardless of " +"whether those operations are CPU or IO bound)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:61 -msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." +msgid "" +"Not all extension modules will fit neatly into the above categories. The " +"extension modules included with NumPy, for example, span all three use cases " +"- they move inner loops to C for speed reasons, wrap external libraries " +"written in C, FORTRAN and other languages, and use low level system " +"interfaces for both CPython and the underlying operation system to support " +"concurrent execution of vectorised operations and to tightly control the " +"exact memory layout of created objects." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:71 @@ -3244,7 +4604,13 @@ msgid "Disadvantages" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:73 -msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." +msgid "" +"The main disadvantage of using binary extensions is the fact that it makes " +"subsequent distribution of the software more difficult. One of the " +"advantages of using Python is that it is largely cross platform, and the " +"languages used to write extension modules (typically C or C++, but really " +"any language that can bind to the CPython C API) typically require that " +"custom binaries be created for different platforms." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:80 @@ -3252,27 +4618,44 @@ msgid "This means that binary extensions:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:82 -msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" +msgid "" +"require that end users be able to either build them from source, or else " +"that someone publish pre-built binaries for common platforms" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:85 -msgid "may not be compatible with different builds of the CPython reference interpreter" +msgid "" +"may not be compatible with different builds of the CPython reference " +"interpreter" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:88 -msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" +msgid "" +"often will not work correctly with alternative interpreters such as PyPy, " +"IronPython or Jython" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:91 -msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." +msgid "" +"if handcoded, make maintenance more difficult by requiring that maintainers " +"be familiar not only with Python, but also with the language used to create " +"the binary extension, as well as with the details of the CPython C API." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:96 -msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." +msgid "" +"if a pure Python fallback implementation is provided, make maintenance more " +"difficult by requiring that changes be implemented in two places, and " +"introducing additional complexity in the test suite to ensure both versions " +"are always executed." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:101 -msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." +msgid "" +"Another disadvantage of relying on binary extensions is that alternative " +"import mechanisms (such as the ability to import modules directly from " +"zipfiles) often won't work for extension modules (as the dynamic loading " +"mechanisms on most platforms can only load libraries from disk)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:108 @@ -3280,23 +4663,56 @@ msgid "Alternatives to handcoded accelerator modules" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:110 -msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" +msgid "" +"When extension modules are just being used to make code run faster (after " +"profiling has identified the code where the speed increase is worth " +"additional maintenance effort), a number of other alternatives should also " +"be considered:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:115 -msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." +msgid "" +"look for existing optimised alternatives. The CPython standard library " +"includes a number of optimised data structures and algorithms (especially in " +"the builtins and the ``collections`` and ``itertools`` modules). The Python " +"Package Index also offers additional alternatives. Sometimes, the " +"appropriate choice of standard library or third party module can avoid the " +"need to create your own accelerator module." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:122 -msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." +msgid "" +"for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython " +"runtime. The main barrier to adopting PyPy is typically reliance on other " +"binary extension modules - while PyPy does emulate the CPython C API, " +"modules that rely on that cause problems for the PyPy JIT, and the emulation " +"layer can often expose latent defects in extension modules that CPython " +"currently tolerates (frequently around reference counting errors - an object " +"having one live reference instead of two often won't break anything, but no " +"references instead of one is a major problem)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:132 -msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." +msgid "" +"`Cython `__ is a mature static compiler that can compile " +"most Python code to C extension modules. The initial compilation provides " +"some speed increases (by bypassing the CPython interpreter layer), and " +"Cython's optional static typing features can offer additional opportunities " +"for speed increases. Using Cython still has the disadvantage of increasing " +"the complexity of distributing the resulting application, but has the " +"benefit of having a reduced barrier to entry for Python programmers " +"(relative to other languages like C or C++)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:141 -msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." +msgid "" +"`Numba `__ is a newer tool, created by members of " +"the scientific Python community, that aims to leverage LLVM to allow " +"selective compilation of pieces of a Python application to native machine " +"code at runtime. It requires that LLVM be available on the system where the " +"code is running, but can provide significant speed increases, especially for " +"operations that are amenable to vectorisation." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:150 @@ -3304,35 +4720,74 @@ msgid "Alternatives to handcoded wrapper modules" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:152 -msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." +msgid "" +"The C ABI (Application Binary Interface) is a common standard for sharing " +"functionality between multiple applications. One of the strengths of the " +"CPython C API (Application Programming Interface) is allowing Python users " +"to tap into that functionality. However, wrapping modules by hand is quite " +"tedious, so a number of other alternative approaches should be considered." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:158 -msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." +msgid "" +"The approaches described below don't simplify the distribution case at all, " +"but they *can* significantly reduce the maintenance burden of keeping " +"wrapper modules up to date." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:162 -msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." +msgid "" +"In addition to being useful for the creation of accelerator modules, `Cython " +"`__ is also useful for creating wrapper modules for C or " +"C++. It still involves wrapping the interfaces by hand, however, and is very " +"repetitive, so may not be a good choice for wrapping large APIs." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:168 -msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." +msgid "" +"`pybind11 `__ is a pure C++11 library that " +"provides a clean C++ interface to the CPython (and PyPy) C API. It does not " +"require a pre-processing step; it is written entirely in templated C++. " +"Helpers are included for Setuptools or CMake builds. It was based on `Boost." +"Python `__, but doesn't require the Boost libraries or BJam." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:175 -msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." +msgid "" +"`cffi `__ is a project created by some of the " +"PyPy developers to make it straightforward for developers that already know " +"both Python and C to expose their C modules to Python applications. It also " +"makes it relatively straightforward to wrap a C module based on its header " +"files, even if you don't know C yourself." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:181 -msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." +msgid "" +"One of the key advantages of ``cffi`` is that it is compatible with the PyPy " +"JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing " +"JIT optimisations." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:185 -msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." +msgid "" +"`SWIG `__ is a wrapper interface generator that allows " +"a variety of programming languages, including Python, to interface with C " +"and C++ code." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:189 -msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." +msgid "" +"The standard library's ``ctypes`` module, while useful for getting access to " +"C level interfaces when header information isn't available, suffers from the " +"fact that it operates solely at the C ABI level, and thus has no automatic " +"consistency checking between the interface actually being exported by the " +"library and the one declared in the Python code. By contrast, the above " +"alternatives are all able to operate at the C *API* level, using C header " +"files to ensure consistency between the interface exported by the library " +"being wrapped and the one expected by the Python wrapper module. While " +"``cffi`` *can* operate directly at the C ABI level, it suffers from the same " +"interface inconsistency problems as ``ctypes`` when it is used that way." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:203 @@ -3340,11 +4795,24 @@ msgid "Alternatives for low level system access" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:205 -msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." +msgid "" +"For applications that need low level system access (regardless of the " +"reason), a binary extension module often *is* the best way to go about it. " +"This is particularly true for low level access to the CPython runtime " +"itself, since some operations (like releasing the Global Interpreter Lock) " +"are simply invalid when the interpreter is running code, even if a module " +"like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API " +"interfaces." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:213 -msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." +msgid "" +"For cases where the extension module is manipulating the underlying " +"operating system or hardware (rather than the CPython runtime), it may " +"sometimes be better to just write an ordinary C library (or a library in " +"another systems programming language like C++ or Rust that can export a C " +"compatible ABI), and then use one of the wrapping techniques described above " +"to make the interface available as an importable Python module." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:222 @@ -3352,7 +4820,10 @@ msgid "Implementing binary extensions" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:224 -msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." +msgid "" +"The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in " +"C `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:241 @@ -3364,7 +4835,14 @@ msgid "Building extensions for multiple platforms" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:246 -msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." +msgid "" +"If you plan to distribute your extension, you should provide :term:`wheels " +"` for all the platforms you intend to support. For most extensions, " +"this is at least one package per Python version times the number of OS and " +"architectures you support. These are usually built on continuous " +"integration (CI) systems. There are tools to help you build highly " +"redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:" +"`multibuild`." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:256 @@ -3372,15 +4850,27 @@ msgid "Binary extensions for Windows" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:258 -msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." +msgid "" +"Before it is possible to build a binary extension, it is necessary to ensure " +"that you have a suitable compiler available. On Windows, Visual C is used to " +"build the official CPython interpreter, and should be used to build " +"compatible binary extensions." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:263 -msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." +msgid "" +"Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio " +"2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older " +"versions of Visual Studio are no longer easily available from Microsoft, so " +"for versions of Python prior to 3.5, the compilers must be obtained " +"differently if you do not already have a copy of the relevant version of " +"Visual Studio." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:269 -msgid "To set up a build environment for binary extensions, the steps are as follows:" +msgid "" +"To set up a build environment for binary extensions, the steps are as " +"follows:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:271 @@ -3388,11 +4878,16 @@ msgid "For Python 2.7" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:273 -msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." +msgid "" +"Install \"Visual C++ Compiler Package for Python 2.7\", which is available " +"from `Microsoft's website `__." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:276 -msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." +msgid "" +"Use (a recent version of) setuptools in your setup.py (pip will do this for " +"you, in any case)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:278 @@ -3406,11 +4901,16 @@ msgid "For Python 3.4" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:282 -msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." +msgid "" +"Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is " +"available from `Microsoft's website `__." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:285 -msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." +msgid "" +"Work from an SDK command prompt (with the environment variables set, and the " +"SDK on PATH)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:287 @@ -3422,15 +4922,23 @@ msgid "For Python 3.5" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:292 -msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." +msgid "" +"Install `Visual Studio 2015 Community Edition `__ (or any later version, " +"when these are released)." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:297 -msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." +msgid "" +"Note that from Python 3.5 onwards, Visual Studio works in a backward " +"compatible way, which means that any future version of Visual Studio will be " +"able to build Python extensions for all Python versions from 3.5 onwards." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:301 -msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." +msgid "" +"Building with the recommended compiler on Windows ensures that a compatible " +"C library is used throughout the Python process." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:305 @@ -3438,7 +4946,11 @@ msgid "Binary extensions for Linux" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:307 -msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." +msgid "" +"Linux binaries must use a sufficiently old glibc to be compatible with older " +"distributions. The `manylinux `_ Docker " +"images provide a build environment with a glibc old enough to support most " +"current Linux distributions on common architectures." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:313 @@ -3446,7 +4958,15 @@ msgid "Binary extensions for macOS" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:315 -msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." +msgid "" +"Binary compatibility on macOS is determined by the target minimum deployment " +"system, e.g. *10.9*, which is often specified with the " +"``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries " +"on macOS. When building with setuptools / distutils, the deployment target " +"is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For " +"common deployment targets for macOS Python distributions, see the `MacPython " +"Spinning Wheels wiki `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:325 @@ -3454,7 +4974,9 @@ msgid "Publishing binary extensions" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:327 -msgid "For interim guidance on this topic, see the discussion in `this issue `_." +msgid "" +"For interim guidance on this topic, see the discussion in `this issue " +"`_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:343 @@ -3462,7 +4984,13 @@ msgid "Additional resources" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:345 -msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." +msgid "" +"Cross-platform development and distribution of extension modules is a " +"complex topic, so this guide focuses primarily on providing pointers to " +"various tools that automate dealing with the underlying technical " +"challenges. The additional resources in this section are instead intended " +"for developers looking to understand more about the underlying binary " +"interfaces that those systems rely on at runtime." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:352 @@ -3470,7 +4998,13 @@ msgid "Cross-platform wheel generation with scikit-build" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:354 -msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." +msgid "" +"The `scikit-build `_ package " +"helps abstract cross-platform build operations and provides additional " +"capabilities when creating binary extension packages. Additional " +"documentation is also available on the `C runtime, compiler, and build " +"system generator `_ for Python binary extension modules." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:362 @@ -3478,11 +5012,15 @@ msgid "Introduction to C/C++ extension modules" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:364 -msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" +msgid "" +"For a more in depth explanation of how extension modules are used by CPython " +"on a Debian system, see the following articles:" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:367 -msgid "`What are (c)python extension modules? `_" +msgid "" +"`What are (c)python extension modules? `_" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:368 @@ -3490,7 +5028,9 @@ msgid "`Releasing the gil `_" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:369 -msgid "`Writing cpython extension modules using C++ `_" +msgid "" +"`Writing cpython extension modules using C++ `_" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:3 @@ -3498,7 +5038,12 @@ msgid "Packaging namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:5 -msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" +msgid "" +"Namespace packages allow you to split the sub-packages and modules within a " +"single :term:`package ` across multiple, separate :term:" +"`distribution packages ` (referred to as " +"**distributions** in this document to avoid ambiguity). For example, if you " +"have the following package structure:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:24 @@ -3514,7 +5059,14 @@ msgid "Each sub-package can now be separately installed, used, and versioned." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:48 -msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." +msgid "" +"Namespace packages can be useful for a large collection of loosely-related " +"packages (such as a large corpus of client libraries for multiple products " +"from a single company). However, namespace packages come with several " +"caveats and are not appropriate in all cases. A simple alternative is to use " +"a prefix on all of your distributions such as ``import " +"mynamespace_subpackage_a`` (you could even use ``import " +"mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:58 @@ -3522,23 +5074,39 @@ msgid "Creating a namespace package" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:60 -msgid "There are currently three different approaches to creating namespace packages:" +msgid "" +"There are currently three different approaches to creating namespace " +"packages:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:62 -msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." +msgid "" +"Use `native namespace packages`_. This type of namespace package is defined " +"in :pep:`420` and is available in Python 3.3 and later. This is recommended " +"if packages in your namespace only ever need to support Python 3 and " +"installation via ``pip``." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:66 -msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." +msgid "" +"Use `pkgutil-style namespace packages`_. This is recommended for new " +"packages that need to support Python 2 and 3 and installation via both " +"``pip`` and ``python setup.py install``." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:69 -msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." +msgid "" +"Use `pkg_resources-style namespace packages`_. This method is recommended if " +"you need compatibility with packages already using this method or if your " +"package needs to be zip-safe." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:73 -msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." +msgid "" +"While native namespace packages and pkgutil-style namespace packages are " +"largely compatible, pkg_resources-style namespace packages are not " +"compatible with the other methods. It's inadvisable to use different methods " +"in different distributions that provide packages to the same namespace." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:80 @@ -3546,23 +5114,41 @@ msgid "Native namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:82 -msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" +msgid "" +"Python 3.3 added **implicit** namespace packages from :pep:`420`. All that " +"is required to create a native namespace package is that you just omit :file:" +"`__init__.py` from the namespace package directory. An example file " +"structure:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:97 -msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." +msgid "" +"It is extremely important that every distribution that uses the namespace " +"package omits the :file:`__init__.py` or uses a pkgutil-style :file:" +"`__init__.py`. If any distribution does not, it will cause the namespace " +"logic to fail and the other sub-packages will not be importable." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:102 -msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" +msgid "" +"Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:" +"`setuptools.find_packages` won't find the sub-package. You must use :func:" +"`setuptools.find_namespace_packages` instead or explicitly list all packages " +"in your :file:`setup.py`. For example:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:117 -msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." +msgid "" +"A complete working example of two native namespace packages can be found in " +"the `native namespace package example project`_." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:123 -msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." +msgid "" +"Because native and pkgutil-style namespace packages are largely compatible, " +"you can use native namespace packages in the distributions that only support " +"Python 3 and pkgutil-style namespace packages in the distributions that need " +"to support Python 2 and 3." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:129 @@ -3570,25 +5156,39 @@ msgid "pkgutil-style namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:131 -msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." +msgid "" +"Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. " +"This can be used to declare namespace packages that need to be compatible " +"with both Python 2.3+ and Python 3. This is the recommended approach for the " +"highest level of compatibility." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:136 -msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgid "" +"To create a pkgutil-style namespace package, you need to provide an :file:" +"`__init__.py` file for the namespace package:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:148 #: ../source/guides/packaging-namespace-packages.rst:194 -msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" +msgid "" +"The :file:`__init__.py` file for the namespace package needs to contain " +"**only** the following:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:155 #: ../source/guides/packaging-namespace-packages.rst:201 -msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." +msgid "" +"**Every** distribution that uses the namespace package must include an " +"identical :file:`__init__.py`. If any distribution does not, it will cause " +"the namespace logic to fail and the other sub-packages will not be " +"importable. Any additional code in :file:`__init__.py` will be inaccessible." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:160 -msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." +msgid "" +"A complete working example of two pkgutil-style namespace packages can be " +"found in the `pkgutil namespace example project`_." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:171 @@ -3596,39 +5196,68 @@ msgid "pkg_resources-style namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:173 -msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." +msgid "" +"`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and " +"the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together " +"these can be used to declare namespace packages. While this approach is no " +"longer recommended, it is widely present in most existing namespace " +"packages. If you are creating a new distribution within an existing " +"namespace package that uses this method then it's recommended to continue " +"using this as the different methods are not cross-compatible and it's not " +"advisable to try to migrate an existing package." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:182 -msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgid "" +"To create a pkg_resources-style namespace package, you need to provide an :" +"file:`__init__.py` file for the namespace package:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:206 -msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" +msgid "" +"Some older recommendations advise the following in the namespace package :" +"file:`__init__.py`:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:216 -msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." +msgid "" +"The idea behind this was that in the rare case that setuptools isn't " +"available packages would fall-back to the pkgutil-style packages. This isn't " +"advisable because pkgutil and pkg_resources-style namespace packages are not " +"cross-compatible. If the presence of setuptools is a concern then the " +"package should just explicitly depend on setuptools via ``install_requires``." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:223 -msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" +msgid "" +"Finally, every distribution must provide the ``namespace_packages`` argument " +"to :func:`~setuptools.setup` in :file:`setup.py`. For example:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:237 -msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." +msgid "" +"A complete working example of two pkg_resources-style namespace packages can " +"be found in the `pkg_resources namespace example project`_." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 -msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" +msgid "" +"Publishing package distribution releases using GitHub Actions CI/CD workflows" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 -msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." +msgid "" +"`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an " +"event occurs on the GitHub platform. One popular choice is having a workflow " +"that's triggered by a ``push`` event. This guide shows you how to publish a " +"Python distribution whenever a tagged commit is pushed. It will use the " +"`pypa/gh-action-pypi-publish GitHub Action`_." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 -msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." +msgid "" +"This guide *assumes* that you already have a project that you know how to " +"build distributions for and *it lives on GitHub*." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 @@ -3636,7 +5265,10 @@ msgid "Saving credentials on GitHub" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 -msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." +msgid "" +"In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, " +"meaning that we'll have two separate sets of credentials. And we'll need to " +"save them in the GitHub repository settings." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 @@ -3644,23 +5276,37 @@ msgid "Let's begin! 🚀" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" +msgid "" +"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " +"token`_. If you have the project on PyPI already, limit the token scope to " +"just that project. You can call it something like ``GitHub Actions CI/CD — " +"project-org/project-repo`` in order for it to be easily distinguishable in " +"the token list. **Don't close the page just yet — you won't see that token " +"again.**" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 -msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." +msgid "" +"In a separate browser tab or window, go to the ``Settings`` tab of your " +"target repository and then click on `Secrets`_ in the left sidebar." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 -msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." +msgid "" +"Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from " +"the first step." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 -msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." +msgid "" +"Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the " +"steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 -msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." +msgid "" +"If you don't have a TestPyPI account, you'll need to create it. It's not the " +"same as a regular PyPI account." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 @@ -3668,7 +5314,9 @@ msgid "Creating a workflow definition" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 -msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." +msgid "" +"GitHub CI/CD workflows are declared in YAML files stored in the ``.github/" +"workflows/`` directory of your repository." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 @@ -3676,7 +5324,9 @@ msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 -msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" +msgid "" +"Start it with a meaningful name and define the event that should make GitHub " +"run this workflow:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 @@ -3684,7 +5334,9 @@ msgid "Defining a workflow job environment" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 -msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" +msgid "" +"Now, let's add initial setup for our job. It's a process that will execute " +"commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 @@ -3696,15 +5348,22 @@ msgid "Then, add the following under the ``build-n-publish`` section:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 -msgid "This will download your repository into the CI runner and then install and activate Python 3.7." +msgid "" +"This will download your repository into the CI runner and then install and " +"activate Python 3.7." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 -msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." +msgid "" +"And now we can build dists from source. In this example, we'll use ``build`` " +"package, assuming that your project has a ``pyproject.toml`` properly set up " +"(see :pep:`517`/:pep:`518`)." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 -msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." +msgid "" +"You can use any other method for building distributions as long as it " +"produces ready-to-upload artifacts saved into the ``dist/`` folder." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 @@ -3720,7 +5379,11 @@ msgid "Finally, add the following steps at the end:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 -msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." +msgid "" +"These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the " +"first one uploads contents of the ``dist/`` folder into TestPyPI " +"unconditionally and the second does that to PyPI, but only if the current " +"commit is tagged." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 @@ -3728,7 +5391,11 @@ msgid "That's all, folks!" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 -msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" +msgid "" +"Now, whenever you push a tagged commit to your Git repository remote on " +"GitHub, this workflow will publish it to PyPI. And it'll publish any push to " +"TestPyPI which is useful for providing test builds to your alpha users as " +"well as making sure that your release pipeline remains healthy!" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:5 @@ -3736,87 +5403,143 @@ msgid "Single-sourcing the package version" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:8 -msgid "There are many techniques to maintain a single source of truth for the version number of your project:" +msgid "" +"There are many techniques to maintain a single source of truth for the " +"version number of your project:" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:11 -msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" +msgid "" +"Read the file in :file:`setup.py` and get the version. Example (from `pip " +"setup.py `_)::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:38 -msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" +msgid "" +"As of the release of setuptools 46.4.0, one can accomplish the same thing by " +"instead placing the following in the project's ``setup.cfg`` file (replacing " +"\"package\" with the import name of the package):" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:47 -msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." +msgid "" +"Earlier versions of setuptools implemented the ``attr:`` directive by " +"importing the module, but setuptools 46.4.0 added rudimentary AST analysis " +"so that ``attr:`` can function without having to import any of the package's " +"dependencies." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:52 -msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." +msgid "" +"Also, please be aware that declarative config indicators, including the " +"``attr:`` directive, are not supported in parameters to ``setup.py``." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:55 -msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." +msgid "" +"Use an external build tool that either manages updating both locations, or " +"offers an API that both locations can use." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:58 -msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." +msgid "" +"Few tools you could use, in no particular order, and not necessarily " +"complete: `bump2version `_, `changes " +"`_, `commitizen `_, `zest.releaser `_." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:65 -msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." +msgid "" +"Set the value to a ``__version__`` global variable in a dedicated module in " +"your project (e.g. :file:`version.py`), then have :file:`setup.py` read and " +"``exec`` the value into a variable." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:76 -msgid "Example using this technique: `warehouse `_." +msgid "" +"Example using this technique: `warehouse `_." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:78 -msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." +msgid "" +"Place the value in a simple ``VERSION`` text file and have both :file:`setup." +"py` and the project code read it." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:86 -msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." +msgid "" +"An advantage with this technique is that it's not specific to Python. Any " +"tool can read the version." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:91 -msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." +msgid "" +"With this approach you must make sure that the ``VERSION`` file is included " +"in all your source and binary distributions (e.g. add ``include VERSION`` to " +"your :file:`MANIFEST.in`)." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:95 -msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" +msgid "" +"Set the value in :file:`setup.py`, and have the project code use the " +"``importlib.metadata`` API to fetch the value at runtime. (``importlib." +"metadata`` was introduced in Python 3.8 and is available to older versions " +"as the ``importlib-metadata`` project.) An installed project's version can " +"be fetched with the API as follows::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:110 -msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." +msgid "" +"Be aware that the ``importlib.metadata`` API only knows about what's in the " +"installation metadata, which is not necessarily the code that's currently " +"imported." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:114 -msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" +msgid "" +"If a project uses this method to fetch its version at runtime, then its " +"``install_requires`` value needs to be edited to install ``importlib-" +"metadata`` on pre-3.8 versions of Python like so::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:128 -msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" +msgid "" +"An older (and less efficient) alternative to ``importlib.metadata`` is the " +"``pkg_resources`` API provided by ``setuptools``::" msgstr "" #: ../source/guides/single-sourcing-package-version.rst:134 -msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." +msgid "" +"If a project uses ``pkg_resources`` to fetch its own version at runtime, " +"then ``setuptools`` must be added to the project's ``install_requires`` list." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:138 -msgid "Example using this technique: `setuptools `_." +msgid "" +"Example using this technique: `setuptools `_." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:141 -msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." +msgid "" +"Set the value to ``__version__`` in ``sample/__init__.py`` and import " +"``sample`` in :file:`setup.py`." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:155 -msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." +msgid "" +"Although this technique is common, beware that it will fail if ``sample/" +"__init__.py`` imports packages from ``install_requires`` dependencies, which " +"will very likely not be installed yet when :file:`setup.py` is run." msgstr "" #: ../source/guides/single-sourcing-package-version.rst:161 -msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." +msgid "" +"Keep the version number in the tags of a version control system (Git, " +"Mercurial, etc) instead of in the code, and automatically extract it from " +"there using `setuptools_scm `_." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:5 @@ -3824,11 +5547,20 @@ msgid "Supporting multiple Python versions" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:37 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:43 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:49 @@ -3836,31 +5568,52 @@ msgid "Automated testing and continuous integration" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:51 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:56 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:60 -msgid "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:" +msgid "" +"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:" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:66 -msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." +msgid "" +"`Travis CI `_ provides both a Linux and a macOS " +"environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit " +"while the macOS is 10.9.2 at the time of writing." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:69 -msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." +msgid "" +"`Appveyor `_ provides a Windows environment " +"(Windows Server 2012)." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:80 -msgid "Both `Travis CI`_ 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." +msgid "" +"Both `Travis CI`_ 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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:85 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:89 @@ -3868,11 +5621,24 @@ msgid "Tools for single-source Python packages" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:91 -msgid "`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_." +msgid "" +"`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_." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:100 -msgid "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" +msgid "" +"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" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:107 @@ -3884,11 +5650,22 @@ msgid "a Python 3 (by syntax) module in a *Python 2* project." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:110 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:117 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:124 @@ -3896,7 +5673,13 @@ msgid "What's in which Python?" msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:126 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:3 @@ -3908,19 +5691,37 @@ msgid "2015-12-03" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:8 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:20 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:24 -msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." +msgid "" +"The Appveyor service is a continuous integration service, much like the " +"better-known `Travis`_ service that is commonly used for testing by projects " +"hosted on `Github`_. However, unlike Travis, the build workers on Appveyor " +"are Windows hosts and have the necessary compilers installed to build Python " +"extensions." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:30 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:38 @@ -3928,15 +5729,25 @@ msgid "Setting up" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:40 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:45 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:49 -msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." +msgid "" +"Once you have set up your Appveyor account and added your project, Appveyor " +"will automatically build your project each time a commit occurs. This " +"behaviour will be familiar to users of Travis." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:54 @@ -3944,11 +5755,22 @@ msgid "Adding Appveyor support to your project" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:56 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:61 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:69 @@ -3956,39 +5778,74 @@ msgid "appveyor.yml" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:75 -msgid "This file can be downloaded from `here `__." +msgid "" +"This file can be downloaded from `here `__." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:77 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:80 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:88 -msgid "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``)." +msgid "" +"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``)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:94 -msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." +msgid "" +"The ``build`` section simply switches off builds - there is no build step " +"needed for Python, unlike languages like ``C#``." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:97 -msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." +msgid "" +"The main sections that will need to be tailored to your project are " +"``test_script`` and ``after_test``." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:100 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:109 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:114 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:119 @@ -3996,15 +5853,29 @@ msgid "Support script" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:121 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:126 -msgid "`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." +msgid "" +"`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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:133 -msgid "You can simply download the batch file and include it in your project unchanged." +msgid "" +"You can simply download the batch file and include it in your project " +"unchanged." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:137 @@ -4012,7 +5883,14 @@ msgid "Access to the built wheels" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:139 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:147 @@ -4024,19 +5902,33 @@ msgid "Testing with tox" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:152 -msgid "Many projects use the `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." +msgid "" +"Many projects use the `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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:156 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:160 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:165 -msgid "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" +msgid "" +"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" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:170 @@ -4056,23 +5948,46 @@ msgid "``LIB``" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:175 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:181 -msgid "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 Travis or 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)." +msgid "" +"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 Travis or 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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:188 -msgid "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``." +msgid "" +"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``." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:192 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:197 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:203 @@ -4080,11 +5995,19 @@ msgid "Automatically uploading wheels" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:205 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:210 -msgid "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)." +msgid "" +"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)." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:216 @@ -4092,11 +6015,19 @@ msgid "External dependencies" msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:218 -msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." +msgid "" +"The supplied scripts will successfully build any distribution that does not " +"rely on 3rd party external libraries for the build." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:221 -msgid "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." +msgid "" +"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." msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:230 @@ -4116,7 +6047,9 @@ msgid "Tool recommendations" msgstr "" #: ../source/guides/tool-recommendations.rst:7 -msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." +msgid "" +"If you're familiar with Python packaging and installation, and just want to " +"know what tools are currently recommended, then here it is." msgstr "" #: ../source/guides/tool-recommendations.rst:12 @@ -4124,7 +6057,10 @@ msgid "Application dependency management" msgstr "" #: ../source/guides/tool-recommendations.rst:14 -msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." +msgid "" +"Use :ref:`pipenv` to manage library dependencies when developing Python " +"applications. See :doc:`../tutorials/managing-dependencies` for more details " +"on using ``pipenv``." msgstr "" #: ../source/guides/tool-recommendations.rst:18 @@ -4148,15 +6084,23 @@ msgid "Installation tool recommendations" msgstr "" #: ../source/guides/tool-recommendations.rst:29 -msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" +msgid "" +"Use :ref:`pip` to install Python :term:`packages ` " +"from :term:`PyPI `. [1]_ [2]_ Depending on how :" +"ref:`pip` is installed, you may need to also install :ref:`wheel` to get the " +"benefit of wheel caching. [3]_" msgstr "" #: ../source/guides/tool-recommendations.rst:34 -msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" +msgid "" +"Use :ref:`virtualenv`, or `venv`_ to isolate application specific " +"dependencies from a shared Python installation. [4]_" msgstr "" #: ../source/guides/tool-recommendations.rst:37 -msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" +msgid "" +"If you're looking for management of fully integrated cross-platform software " +"stacks, consider:" msgstr "" #: ../source/guides/tool-recommendations.rst:40 @@ -4164,7 +6108,9 @@ msgid ":ref:`buildout`: primarily focused on the web development community" msgstr "" #: ../source/guides/tool-recommendations.rst:42 -msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." +msgid "" +":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the " +"scientific community." msgstr "" #: ../source/guides/tool-recommendations.rst:47 @@ -4172,15 +6118,22 @@ msgid "Packaging tool recommendations" msgstr "" #: ../source/guides/tool-recommendations.rst:49 -msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" +msgid "" +"Use :ref:`setuptools` to define projects and create :term:`Source " +"Distributions `. [5]_ [6]_" msgstr "" #: ../source/guides/tool-recommendations.rst:52 -msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." +msgid "" +"Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:" +"`wheel project ` to create :term:`wheels `. This is " +"especially beneficial, if your project contains binary extensions." msgstr "" #: ../source/guides/tool-recommendations.rst:56 -msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." +msgid "" +"Use `twine `_ for uploading distributions " +"to :term:`PyPI `." msgstr "" #: ../source/guides/tool-recommendations.rst:61 @@ -4188,39 +6141,75 @@ msgid "Publishing platform migration" msgstr "" #: ../source/guides/tool-recommendations.rst:63 -msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." +msgid "" +"The original Python Package Index implementation (previously hosted at `pypi." +"python.org `_) has been phased out in favour of an " +"updated implementation hosted at `pypi.org `_." msgstr "" #: ../source/guides/tool-recommendations.rst:67 -msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." +msgid "" +"See :ref:`Migrating to PyPI.org` for more information on the status of the " +"migration, and what settings to change in your clients." msgstr "" #: ../source/guides/tool-recommendations.rst:72 -msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." +msgid "" +"There are some cases where you might choose to use ``easy_install`` (from :" +"ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` " +"(which pip doesn't support). For a detailed breakdown, see :ref:`pip vs " +"easy_install`." msgstr "" #: ../source/guides/tool-recommendations.rst:77 -msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." +msgid "" +"The acceptance of :pep:`453` means that :ref:`pip` will be available by " +"default in most installations of Python 3.4 or later. See the :pep:" +"`rationale section <453#rationale>` from :pep:`453` as for why pip was " +"chosen." msgstr "" #: ../source/guides/tool-recommendations.rst:82 -msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." +msgid "" +"`get-pip.py `_ and :ref:" +"`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv " +"` do not currently. Also, the common \"python-pip\" package that's " +"found in various linux distros, does not depend on \"python-wheel\" " +"currently." msgstr "" #: ../source/guides/tool-recommendations.rst:88 -msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." +msgid "" +"Beginning with Python 3.4, ``venv`` will create virtualenv environments with " +"``pip`` installed, thereby making it an equal alternative to :ref:" +"`virtualenv`. However, using :ref:`virtualenv` will still be recommended for " +"users that need cross-version consistency." msgstr "" #: ../source/guides/tool-recommendations.rst:93 -msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." +msgid "" +"Although you can use pure ``distutils`` for many projects, it does not " +"support defining dependencies on other projects and is missing several " +"convenience utilities for automatically populating distribution metadata " +"correctly that are provided by ``setuptools``. Being outside the standard " +"library, ``setuptools`` also offers a more consistent feature set across " +"different versions of Python, and (unlike ``distutils``), recent versions of " +"``setuptools`` support all of the modern metadata fields described in :ref:" +"`core-metadata`." msgstr "" #: ../source/guides/tool-recommendations.rst:102 -msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." +msgid "" +"Even for projects that do choose to use ``distutils``, when :ref:`pip` " +"installs such projects directly from source (rather than installing from a " +"prebuilt :term:`wheel ` file), it will actually build your project " +"using :ref:`setuptools` instead." msgstr "" #: ../source/guides/tool-recommendations.rst:107 -msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." +msgid "" +"`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` " +"in June 2013, thereby making setuptools the default choice for packaging." msgstr "" #: ../source/guides/using-manifest-in.rst:5 @@ -4228,11 +6217,23 @@ msgid "Including files in source distributions with ``MANIFEST.in``" msgstr "" #: ../source/guides/using-manifest-in.rst:7 -msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." +msgid "" +"When building a :term:`source distribution ` for your package, by default only a minimal set of files are " +"included. You may find yourself wanting to include extra files in the " +"source distribution, such as an authors/contributors file, a :file:`docs/` " +"directory, or a directory of data files used for testing purposes. There " +"may even be extra files that you *need* to include; for example, if your :" +"file:`setup.py` computes your project's ``long_description`` by reading from " +"both a README and a changelog file, you'll need to include both those files " +"in the sdist so that people that build or install from the sdist get the " +"correct results." msgstr "" #: ../source/guides/using-manifest-in.rst:17 -msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." +msgid "" +"Adding & removing files to & from the source distribution is done by writing " +"a :file:`MANIFEST.in` file at the project root." msgstr "" #: ../source/guides/using-manifest-in.rst:22 @@ -4244,11 +6245,15 @@ msgid "The following files are included in a source distribution by default:" msgstr "" #: ../source/guides/using-manifest-in.rst:26 -msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" +msgid "" +"all Python source files implied by the ``py_modules`` and ``packages`` " +"``setup()`` arguments" msgstr "" #: ../source/guides/using-manifest-in.rst:28 -msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" +msgid "" +"all C source files mentioned in the ``ext_modules`` or ``libraries`` " +"``setup()`` arguments" msgstr "" #: ../source/guides/using-manifest-in.rst:30 @@ -4256,15 +6261,21 @@ msgid "scripts specified by the ``scripts`` ``setup()`` argument" msgstr "" #: ../source/guides/using-manifest-in.rst:31 -msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" +msgid "" +"all files specified by the ``package_data`` and ``data_files`` ``setup()`` " +"arguments" msgstr "" #: ../source/guides/using-manifest-in.rst:33 -msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" +msgid "" +"the file specified by the ``license_file`` option in :file:`setup.cfg` " +"(setuptools 40.8.0+)" msgstr "" #: ../source/guides/using-manifest-in.rst:35 -msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" +msgid "" +"all files specified by the ``license_files`` option in :file:`setup.cfg` " +"(setuptools 42.0.0+)" msgstr "" #: ../source/guides/using-manifest-in.rst:37 @@ -4304,11 +6315,20 @@ msgid ":file:`MANIFEST.in`" msgstr "" #: ../source/guides/using-manifest-in.rst:47 -msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." +msgid "" +"After adding the above files to the sdist, the commands in :file:`MANIFEST." +"in` (if such a file exists) are executed in order to add and remove further " +"files to & from the sdist. Default files can even be removed from the sdist " +"with the appropriate :file:`MANIFEST.in` command." msgstr "" #: ../source/guides/using-manifest-in.rst:52 -msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." +msgid "" +"After processing the :file:`MANIFEST.in` file, setuptools removes the :file:" +"`build/` directory as well as any directories named :file:`RCS`, :file:" +"`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file " +"and an :file:`*.egg-info` directory. This behavior cannot be changed with :" +"file:`MANIFEST.in`." msgstr "" #: ../source/guides/using-manifest-in.rst:60 @@ -4316,7 +6336,10 @@ msgid ":file:`MANIFEST.in` commands" msgstr "" #: ../source/guides/using-manifest-in.rst:62 -msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" +msgid "" +"A :file:`MANIFEST.in` file consists of commands, one per line, instructing " +"setuptools to add or remove some set of files from the sdist. The commands " +"are:" msgstr "" #: ../source/guides/using-manifest-in.rst:67 @@ -4344,7 +6367,9 @@ msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" msgstr "" #: ../source/guides/using-manifest-in.rst:71 -msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgid "" +"Add all files under directories matching ``dir-pattern`` that match any of " +"the listed patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:72 @@ -4352,7 +6377,9 @@ msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" msgstr "" #: ../source/guides/using-manifest-in.rst:72 -msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgid "" +"Remove all files under directories matching ``dir-pattern`` that match any " +"of the listed patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:73 @@ -4360,7 +6387,8 @@ msgid ":samp:`global-include {pat1} {pat2} ...`" msgstr "" #: ../source/guides/using-manifest-in.rst:73 -msgid "Add all files anywhere in the source tree matching any of the listed patterns" +msgid "" +"Add all files anywhere in the source tree matching any of the listed patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:74 @@ -4368,7 +6396,9 @@ msgid ":samp:`global-exclude {pat1} {pat2} ...`" msgstr "" #: ../source/guides/using-manifest-in.rst:74 -msgid "Remove all files anywhere in the source tree matching any of the listed patterns" +msgid "" +"Remove all files anywhere in the source tree matching any of the listed " +"patterns" msgstr "" #: ../source/guides/using-manifest-in.rst:75 @@ -4388,27 +6418,54 @@ msgid "Remove all files under directories matching ``dir-pattern``" msgstr "" #: ../source/guides/using-manifest-in.rst:79 -msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." +msgid "" +"The patterns here are glob-style patterns: ``*`` matches zero or more " +"regular filename characters (on Unix, everything except forward slash; on " +"Windows, everything except backslash and colon); ``?`` matches a single " +"regular filename character, and ``[chars]`` matches any one of the " +"characters between the square brackets (which may contain character ranges, " +"e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented " +"support for ``**`` matching zero or more characters including forward slash, " +"backslash, and colon." msgstr "" #: ../source/guides/using-manifest-in.rst:87 -msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." +msgid "" +"Directory patterns are relative to the root of the project directory; e.g., " +"``graft example*`` will include a directory named :file:`examples` in the " +"project root but will not include :file:`docs/examples/`." msgstr "" #: ../source/guides/using-manifest-in.rst:91 -msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." +msgid "" +"File & directory names in :file:`MANIFEST.in` should be ``/``-separated; " +"setuptools will automatically convert the slashes to the local platform's " +"appropriate directory separator." msgstr "" #: ../source/guides/using-manifest-in.rst:95 -msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" +msgid "" +"Commands are processed in the order they appear in the :file:`MANIFEST.in` " +"file. For example, given the commands::" msgstr "" #: ../source/guides/using-manifest-in.rst:101 -msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." +msgid "" +"the contents of the directory tree :file:`tests` will first be added to the " +"sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, " +"or ``.pyd`` extension will be removed from the sdist. If the commands were " +"in the opposite order, then ``*.pyc`` files etc. would be only be removed " +"from what was already in the sdist before adding :file:`tests`, and if :file:" +"`tests` happened to contain any ``*.pyc`` files, they would end up included " +"in the sdist because the exclusion happened before they were included." msgstr "" #: ../source/guides/using-testpypi.rst:7 -msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" +msgid "" +"``TestPyPI`` is a separate instance of the :term:`Python Package Index " +"(PyPI)` that allows you to try out the distribution tools and process " +"without worrying about affecting the real index. TestPyPI is hosted at `test." +"pypi.org `_" msgstr "" #: ../source/guides/using-testpypi.rst:13 @@ -4416,11 +6473,16 @@ msgid "Registering your account" msgstr "" #: ../source/guides/using-testpypi.rst:15 -msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." +msgid "" +"Because TestPyPI has a separate database from the live PyPI, you'll need a " +"separate user account for specifically for TestPyPI. Go to https://test.pypi." +"org/account/register/ to register your account." msgstr "" #: ../source/guides/using-testpypi.rst:19 -msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." +msgid "" +"The database for TestPyPI may be periodically pruned, so it is not unusual " +"for user accounts to be deleted." msgstr "" #: ../source/guides/using-testpypi.rst:24 @@ -4428,11 +6490,17 @@ msgid "Using TestPyPI with Twine" msgstr "" #: ../source/guides/using-testpypi.rst:26 -msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" +msgid "" +"You can upload your distributions to TestPyPI using :ref:`twine` by " +"specifying the ``--repository`` flag" msgstr "" #: ../source/guides/using-testpypi.rst:33 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgid "" +"You can see if your package has successfully uploaded by navigating to the " +"URL ``https://test.pypi.org/project/`` where " +"``sampleproject`` is the name of your project that you uploaded. It may take " +"a minute or two for your project to appear on the site." msgstr "" #: ../source/guides/using-testpypi.rst:39 @@ -4440,11 +6508,16 @@ msgid "Using TestPyPI with pip" msgstr "" #: ../source/guides/using-testpypi.rst:41 -msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" +msgid "" +"You can tell pip to download packages from TestPyPI instead of PyPI by " +"specifying the ``--index-url`` flag" msgstr "" #: ../source/guides/using-testpypi.rst:56 -msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" +msgid "" +"If you want to allow pip to also pull other packages from PyPI you can " +"specify ``--extra-index-url`` to point to PyPI. This is useful when the " +"package you're testing has dependencies:" msgstr "" #: ../source/guides/using-testpypi.rst:73 @@ -4452,16 +6525,19 @@ msgid "Setting up TestPyPI in :file:`.pypirc`" msgstr "" #: ../source/guides/using-testpypi.rst:75 -msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" +msgid "" +"If you want to avoid entering your username, you can configure TestPyPI in " +"your :file:`$HOME/.pypirc`:" msgstr "" -#: ../source/index.rst:3 -#: ../source/key_projects.rst:181 +#: ../source/index.rst:3 ../source/key_projects.rst:181 msgid "Python Packaging User Guide" msgstr "" #: ../source/index.rst:5 -msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." +msgid "" +"The Python Packaging User Guide (PyPUG) is a collection of tutorials and " +"guides for packaging Python software." msgstr "" #: ../source/index.rst:5 @@ -4469,11 +6545,16 @@ msgid "python, packaging, guide, tutorial" msgstr "" #: ../source/index.rst:24 -msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." +msgid "" +"Welcome to the *Python Packaging User Guide*, a collection of tutorials and " +"references to help you distribute and install Python packages with modern " +"tools." msgstr "" #: ../source/index.rst:28 -msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" +msgid "" +"This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. " +"We happily accept any :doc:`contributions and feedback `. 😊" msgstr "" #: ../source/index.rst:36 @@ -4481,23 +6562,34 @@ msgid "Get started" msgstr "" #: ../source/index.rst:38 -msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" +msgid "" +"Essential tools and concepts for working within the Python development " +"ecosystem are covered in our :doc:`tutorials/index` section:" msgstr "" #: ../source/index.rst:41 -msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" +msgid "" +"To learn how to install packages, see the :doc:`tutorial on installing " +"packages `" msgstr "" #: ../source/index.rst:43 -msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" +msgid "" +"To learn how to manage dependencies in a version controlled project, see " +"the :doc:`tutorial on managing application dependencies `" msgstr "" #: ../source/index.rst:45 -msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" +msgid "" +"To learn how to package and distribute your projects, see the :doc:`tutorial " +"on packaging and distributing `" msgstr "" #: ../source/index.rst:47 -msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" +msgid "" +"To get an overview of packaging options for Python libraries and " +"applications, see the :doc:`Overview of Python Packaging `" msgstr "" #: ../source/index.rst:52 @@ -4505,23 +6597,33 @@ msgid "Learn more" msgstr "" #: ../source/index.rst:54 -msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" +msgid "" +"Beyond our :doc:`tutorials/index`, this guide has several other resources:" msgstr "" #: ../source/index.rst:56 -msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." +msgid "" +"The :doc:`guides/index` section for walk throughs, such as :doc:`guides/" +"installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." msgstr "" #: ../source/index.rst:58 -msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." +msgid "" +"The :doc:`discussions/index` section for in-depth references on topics such " +"as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-" +"vs-easy-install`." msgstr "" #: ../source/index.rst:60 -msgid "The :doc:`specifications/index` section for packaging interoperability specifications." +msgid "" +"The :doc:`specifications/index` section for packaging interoperability " +"specifications." msgstr "" #: ../source/index.rst:62 -msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." +msgid "" +"Additionally, there is a list of :doc:`other projects ` " +"maintained by members of the Python Packaging Authority." msgstr "" #: ../source/key_projects.rst:6 @@ -4529,7 +6631,9 @@ msgid "Project Summaries" msgstr "" #: ../source/key_projects.rst:8 -msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." +msgid "" +"Summaries and links for the most relevant projects in the space of Python " +"installation and packaging." msgstr "" #: ../source/key_projects.rst:14 @@ -4541,11 +6645,18 @@ msgid "bandersnatch" msgstr "" #: ../source/key_projects.rst:21 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:25 -msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." +msgid "" +"``bandersnatch`` is a PyPI mirroring client designed to efficiently create a " +"complete mirror of the contents of PyPI. Organizations thus save bandwidth " +"and latency on package downloads (especially in the context of automated " +"tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." msgstr "" #: ../source/key_projects.rst:35 @@ -4553,11 +6664,16 @@ msgid "build" msgstr "" #: ../source/key_projects.rst:37 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI " +"`__" msgstr "" #: ../source/key_projects.rst:42 -msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." +msgid "" +"``build`` is a :pep:`517` compatible Python package builder. It provides a " +"CLI to build packages, as well as a Python API." msgstr "" #: ../source/key_projects.rst:49 @@ -4565,11 +6681,19 @@ msgid "cibuildwheel" msgstr "" #: ../source/key_projects.rst:51 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | " +"`Discussions `__ | " +"`Discord #cibuildwheel `__" msgstr "" #: ../source/key_projects.rst:58 -msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." +msgid "" +"``cibuildwheel`` is a Python package that builds :term:`wheels ` for " +"all common platforms and Python versions on most CI systems. Also see :ref:" +"`multibuild`." msgstr "" #: ../source/key_projects.rst:64 @@ -4577,15 +6701,31 @@ msgid "distlib" msgstr "" #: ../source/key_projects.rst:66 -msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:71 -msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." +msgid "" +"``distlib`` is a library which implements low-level functions that relate to " +"packaging and distribution of Python software. ``distlib`` implements " +"several relevant PEPs (Python Enhancement Proposal standards) and is useful " +"for developers of third-party packaging tools to make and upload binary and " +"source :term:`distributions `, achieve " +"interoperability, resolve dependencies, manage package resources, and do " +"other similar functions." msgstr "" #: ../source/key_projects.rst:80 -msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." +msgid "" +"Unlike the stricter :ref:`packaging` project (below), which specifically " +"implements modern Python packaging interoperability standards, ``distlib`` " +"also attempts to provide reasonable fallback behaviours when asked to handle " +"legacy packages and metadata that predate the modern interoperability " +"standards and fall into the subset of packages that are incompatible with " +"those standards." msgstr "" #: ../source/key_projects.rst:90 @@ -4593,19 +6733,36 @@ msgid "packaging" msgstr "" #: ../source/key_projects.rst:92 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:97 -msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." +msgid "" +"Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." msgstr "" #: ../source/key_projects.rst:99 -msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." +msgid "" +"The core utilities in the packaging library handle version handling, " +"specifiers, markers, requirements, tags, and similar attributes and tasks " +"for Python packages. Most Python users rely on this library without needing " +"to explicitly call it; developers of the other Python packaging, " +"distribution, and installation tools listed here often use its functionality " +"to parse, discover, and otherwise handle dependency attributes." msgstr "" #: ../source/key_projects.rst:107 -msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." +msgid "" +"This project specifically focuses on implementing the modern Python " +"packaging interoperability standards defined at :ref:`packaging-" +"specifications`, and will report errors for sufficiently old legacy packages " +"that are incompatible with those standards. In contrast, the :ref:`distlib` " +"project is a more permissive library that attempts to provide a plausible " +"reading of ambiguous metadata in cases where :ref:`packaging` will instead " +"report on error." msgstr "" #: ../source/key_projects.rst:119 @@ -4614,15 +6771,24 @@ msgid "pip" msgstr "" #: ../source/key_projects.rst:121 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:126 -msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." +msgid "" +"The most popular tool for installing Python packages, and the one included " +"with modern versions of Python." msgstr "" #: ../source/key_projects.rst:129 -msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." +msgid "" +"It provides the essential core features for finding, downloading, and " +"installing packages from PyPI and other Python package indexes, and can be " +"incorporated into a wide range of development workflows via its command-line " +"interface (CLI)." msgstr "" #: ../source/key_projects.rst:137 @@ -4630,15 +6796,28 @@ msgid "Pipenv" msgstr "" #: ../source/key_projects.rst:139 -msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Source `__ | `Issues `__ | `PyPI " +"`__" msgstr "" #: ../source/key_projects.rst:144 -msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." +msgid "" +"Pipenv is a project that aims to bring the best of all packaging worlds to " +"the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:" +"`virtualenv` into one single toolchain. It features very pretty terminal " +"colors." msgstr "" #: ../source/key_projects.rst:148 -msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." +msgid "" +"Pipenv aims to help users manage environments, dependencies, and imported " +"packages on the command line. It also works well on Windows (which other " +"tools often underserve), makes and checkes file hashes, to ensure compliance " +"with hash-locked dependency specifiers, and eases uninstallation of packages " +"and dependencies. It is used by Python users and system administrators, but " +"has been less maintained since late 2018." msgstr "" #: ../source/key_projects.rst:159 @@ -4650,7 +6829,10 @@ msgid "`Source `__" msgstr "" #: ../source/key_projects.rst:163 -msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." +msgid "" +":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level " +"application-centric alternative to :ref:`pip`'s lower-level :file:" +"`requirements.txt` file." msgstr "" #: ../source/key_projects.rst:170 @@ -4658,15 +6840,22 @@ msgid "pipx" msgstr "" #: ../source/key_projects.rst:172 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:176 -msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." +msgid "" +"pipx is a tool to install and run Python command-line applications without " +"causing dependency conflicts with other packages installed on the system." msgstr "" #: ../source/key_projects.rst:183 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:187 @@ -4678,11 +6867,18 @@ msgid "readme_renderer" msgstr "" #: ../source/key_projects.rst:194 -msgid "`GitHub and docs `__ | `PyPI `__" +msgid "" +"`GitHub and docs `__ | `PyPI " +"`__" msgstr "" #: ../source/key_projects.rst:197 -msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." +msgid "" +"``readme_renderer`` is a library that package developers use to render their " +"user documentation (README) files into HTML from markup languages such as " +"Markdown or reStructuredText. Developers call it on its own or via :ref:" +"`twine`, as part of their release management process, to check that their " +"package descriptions will properly display on PyPI." msgstr "" #: ../source/key_projects.rst:208 @@ -4690,15 +6886,24 @@ msgid "setuptools" msgstr "" #: ../source/key_projects.rst:210 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:215 -msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." +msgid "" +"setuptools (which includes ``easy_install``) is a collection of enhancements " +"to the Python distutils that allow you to more easily build and distribute " +"Python :term:`distributions `, especially ones that " +"have dependencies on other packages." msgstr "" #: ../source/key_projects.rst:220 -msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." +msgid "" +"`distribute`_ was a fork of setuptools that was merged back into setuptools " +"(in v0.7), thereby making setuptools the primary choice for Python packaging." msgstr "" #: ../source/key_projects.rst:227 @@ -4706,15 +6911,32 @@ msgid "trove-classifiers" msgstr "" #: ../source/key_projects.rst:229 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Issues `__ | `GitHub " +"`__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:233 -msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." +msgid "" +"trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically " +"describe their projects `_ so that users can better find projects " +"that match their needs on the PyPI." msgstr "" #: ../source/key_projects.rst:239 -msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." +msgid "" +"The trove-classifiers package contains a list of valid classifiers and " +"deprecated classifiers (which are paired with the classifiers that replace " +"them). Use this package to validate classifiers used in packages intended " +"for uploading to PyPI. As this list of classifiers is published as code, you " +"can install and import it, giving you a more convenient workflow compared to " +"referring to the `list published on PyPI `_. " +"The `issue tracker `_ for " +"the project hosts discussions on proposed classifiers and requests for new " +"classifiers." msgstr "" #: ../source/key_projects.rst:253 @@ -4722,24 +6944,41 @@ msgid "twine" msgstr "" #: ../source/key_projects.rst:255 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:260 -msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." +msgid "" +"Twine is the primary tool developers use to upload packages to the Python " +"Package Index or other Python package indexes. It is a command-line program " +"that passes program files and metadata to a web API. Developers use it " +"because it's the official PyPI upload tool, it's fast and secure, it's " +"maintained, and it reliably works." msgstr "" -#: ../source/key_projects.rst:270 -#: ../source/overview.rst:415 +#: ../source/key_projects.rst:270 ../source/overview.rst:415 msgid "virtualenv" msgstr "" #: ../source/key_projects.rst:272 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:277 -msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgid "" +"virtualenv is a tool which uses the command-line path environment variable " +"to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional " +"functionality, compared to :ref:`venv`, by supporting Python 2.7 and by " +"providing convenient features for configuring, maintaining, duplicating, and " +"troubleshooting the virtual environments. For more information, see the " +"section on :ref:`Creating and using Virtual Environments`." msgstr "" #: ../source/key_projects.rst:290 @@ -4747,11 +6986,16 @@ msgid "Warehouse" msgstr "" #: ../source/key_projects.rst:292 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:296 -msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." +msgid "" +"The current codebase powering the :term:`Python Package Index (PyPI)`. It is " +"hosted at `pypi.org `_. The default source for :ref:`pip` " +"downloads." msgstr "" #: ../source/key_projects.rst:304 @@ -4759,15 +7003,26 @@ msgid "wheel" msgstr "" #: ../source/key_projects.rst:306 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:311 -msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." +msgid "" +"Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` " +"extension for creating :term:`wheel distributions `. Additionally, " +"it offers its own command line utility for creating and installing wheels." msgstr "" #: ../source/key_projects.rst:315 -msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." +msgid "" +"See also `auditwheel `__, a tool that " +"package developers use to check and fix Python packages they are making in " +"the binary wheel format. It provides functionality to discover dependencies, " +"check metadata for compliance, and repair the wheel and metadata to properly " +"link and include external shared libraries in a package." msgstr "" #: ../source/key_projects.rst:324 @@ -4779,11 +7034,17 @@ msgid "bento" msgstr "" #: ../source/key_projects.rst:331 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" msgstr "" #: ../source/key_projects.rst:336 -msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." +msgid "" +"Bento is a packaging tool solution for Python software, targeted as an " +"alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's " +"philosophy is reproducibility, extensibility and simplicity (in that order)." msgstr "" #: ../source/key_projects.rst:344 @@ -4791,11 +7052,18 @@ msgid "buildout" msgstr "" #: ../source/key_projects.rst:346 -msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" +msgid "" +"`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:351 -msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." +msgid "" +"Buildout is a Python-based build system for creating, assembling and " +"deploying applications from multiple parts, some of which may be non-Python-" +"based. It lets you create a buildout configuration and reproduce the same " +"software later." msgstr "" #: ../source/key_projects.rst:358 @@ -4807,15 +7075,32 @@ msgid "`Docs `__" msgstr "" #: ../source/key_projects.rst:362 -msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." +msgid "" +"conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution " +"from `Anaconda, Inc `__ specifically " +"aimed at the scientific community, and in particular on Windows where the " +"installation of binary extensions is often difficult." msgstr "" #: ../source/key_projects.rst:369 -msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." +msgid "" +"Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, " +"but provides many of their combined features in terms of package management, " +"virtual environment management and deployment of binary extensions." msgstr "" #: ../source/key_projects.rst:373 -msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." +msgid "" +"Conda does not install packages from PyPI and can install only from the " +"official Anaconda repositories, or anaconda.org (a place for user-" +"contributed *conda* packages), or a local (e.g. intranet) package server. " +"However, note that :ref:`pip` can be installed into, and work side-by-side " +"with conda for managing :term:`distributions ` from " +"PyPI. Also, `conda skeleton `__ is a tool to make " +"Python packages installable by conda by first fetching them from PyPI and " +"modifying their metadata." msgstr "" #: ../source/key_projects.rst:386 @@ -4823,11 +7108,17 @@ msgid "devpi" msgstr "" #: ../source/key_projects.rst:388 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:392 -msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." +msgid "" +"devpi features a powerful PyPI-compatible server and PyPI proxy cache with a " +"complementary command line tool to drive packaging, testing and release " +"activities with Python. devpi also provides a browsable and searchable web " +"interface." msgstr "" #: ../source/key_projects.rst:401 @@ -4835,15 +7126,25 @@ msgid "flit" msgstr "" #: ../source/key_projects.rst:403 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Docs `__ | `Issues `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:407 -msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." +msgid "" +"Flit provides a simple way to upload pure Python packages and modules to " +"PyPI. It focuses on `making the easy things easy `_ for " +"packaging. Flit can generate a configuration file to quickly set up a simple " +"project, build source distributions and wheels, and upload them to PyPI." msgstr "" #: ../source/key_projects.rst:412 -msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." +msgid "" +"Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on " +"tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to " +"upload them to PyPI. Flit requires Python 3, but you can use it to " +"distribute modules for Python 2, so long as they can be imported on Python 3." msgstr "" #: ../source/key_projects.rst:422 @@ -4851,11 +7152,22 @@ msgid "enscons" msgstr "" #: ../source/key_projects.rst:424 -msgid "`Source `__ | `Issues `__ | `PyPI `__" +msgid "" +"`Source `__ | `Issues `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:428 -msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." +msgid "" +"Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-" +"compatible source distributions and wheels without using distutils or " +"setuptools, including distributions with C extensions. Enscons has a " +"different architecture and philosophy than :ref:`distutils`. Rather than " +"adding build features to a Python packaging system, enscons adds Python " +"packaging to a general purpose build system. Enscons helps you to build " +"sdists that can be automatically built by :ref:`pip`, and wheels that are " +"independent of enscons." msgstr "" #: ../source/key_projects.rst:443 @@ -4863,11 +7175,20 @@ msgid "Hashdist" msgstr "" #: ../source/key_projects.rst:445 -msgid "`Docs `__ | `GitHub `__" +msgid "" +"`Docs `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:448 -msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." +msgid "" +"Hashdist is a library for building non-root software distributions. Hashdist " +"is trying to be “the Debian of choice for cases where Debian technology " +"doesn’t work”. The best way for Pythonistas to think about Hashdist may be a " +"more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed " +"at solving the problem of installing scientific software, and making package " +"distribution stateless, cached, and branchable. It is used by some " +"researchers but has been lacking in maintenance since 2016." msgstr "" #: ../source/key_projects.rst:460 @@ -4875,11 +7196,18 @@ msgid "hatch" msgstr "" #: ../source/key_projects.rst:462 -msgid "`GitHub and Docs `__ | `PyPI `__" +msgid "" +"`GitHub and Docs `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:465 -msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." +msgid "" +"Hatch is a unified command-line tool meant to conveniently manage " +"dependencies and environment isolation for Python developers. Python package " +"developers use Hatch to configure, version, specify dependencies for, and " +"publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload " +"packages to PyPI, and :ref:`pip` to download and install packages." msgstr "" #: ../source/key_projects.rst:475 @@ -4891,7 +7219,10 @@ msgid "`GitHub `__" msgstr "" #: ../source/key_projects.rst:479 -msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." +msgid "" +"Multibuild is a set of CI scripts for building and testing Python :term:" +"`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :" +"ref:`cibuildwheel`." msgstr "" #: ../source/key_projects.rst:485 @@ -4899,11 +7230,18 @@ msgid "pex" msgstr "" #: ../source/key_projects.rst:487 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:491 -msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." +msgid "" +"pex is both a library and tool for generating :file:`.pex` (Python " +"EXecutable) files, standalone Python environments in the spirit of :ref:" +"`virtualenv`. :file:`.pex` files are just carefully constructed zip files " +"with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are " +"designed to make deployment of Python applications as simple as ``cp``." msgstr "" #: ../source/key_projects.rst:500 @@ -4911,11 +7249,20 @@ msgid "pip-tools" msgstr "" #: ../source/key_projects.rst:502 -msgid "`GitHub and Docs `__ | `PyPI `__" +msgid "" +"`GitHub and Docs `__ | `PyPI " +"`__" msgstr "" #: ../source/key_projects.rst:505 -msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." +msgid "" +"pip-tools is a suite of tools meant for Python system administrators and " +"release managers who particularly want to keep their builds deterministic " +"yet stay up to date with new versions of their dependencies. Users can " +"specify particular release of their dependencies via hash, conveniently make " +"a properly formatted list of requirements from information in other parts of " +"their program, update all dependencies (a feature :ref:`pip` currently does " +"not provide), and create layers of constraints for the program to obey." msgstr "" #: ../source/key_projects.rst:517 @@ -4923,11 +7270,17 @@ msgid "piwheels" msgstr "" #: ../source/key_projects.rst:519 -msgid "`Website `__ | `Docs `__ | `GitHub `__" +msgid "" +"`Website `__ | `Docs `__ | `GitHub `__" msgstr "" #: ../source/key_projects.rst:523 -msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." +msgid "" +"piwheels is a website, and software underpinning it, that fetches source " +"code distribution packages from PyPI and compiles them into binary wheels " +"that are optimized for installation onto Raspberry Pi computers. Raspberry " +"Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." msgstr "" #: ../source/key_projects.rst:532 @@ -4935,11 +7288,19 @@ msgid "poetry" msgstr "" #: ../source/key_projects.rst:534 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:538 -msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." +msgid "" +"poetry is a command-line tool to handle dependency installation and " +"isolation as well as building and packaging of Python packages. It uses " +"``pyproject.toml`` and, instead of depending on the resolver functionality " +"within :ref:`pip`, provides its own dependency resolver. It attempts to " +"speed users' experience of installation and dependency resolution by locally " +"caching metadata about dependencies." msgstr "" #: ../source/key_projects.rst:548 @@ -4947,11 +7308,20 @@ msgid "pypiserver" msgstr "" #: ../source/key_projects.rst:550 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | " +"`GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:554 -msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." +msgid "" +"pypiserver is a minimalist application that serves as a private Python " +"package index within organizations, implementing a simple API and browser " +"interface. You can upload private packages using standard upload tools, and " +"users can download and install them with :ref:`pip`, without publishing them " +"publicly. Organizations who use pypiserver usually download packages both " +"from pypiserver and from PyPI." msgstr "" #: ../source/key_projects.rst:564 @@ -4959,11 +7329,22 @@ msgid "scikit-build" msgstr "" #: ../source/key_projects.rst:566 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:570 -msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." +msgid "" +"Scikit-build is an improved build system generator for CPython C/C++/Fortran/" +"Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :" +"ref:`pip`. It internally uses `cmake `__ " +"(available on PyPI) to provide better support for additional compilers, " +"build systems, cross compilation, and locating dependencies and their " +"associated build requirements. To speed up and parallelize the build of " +"large projects, the user can install `ninja `__ (also available on PyPI)." msgstr "" #: ../source/key_projects.rst:582 @@ -4971,23 +7352,42 @@ msgid "shiv" msgstr "" #: ../source/key_projects.rst:584 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:588 -msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." +msgid "" +"shiv is a command line utility for building fully self contained Python " +"zipapps as outlined in :pep:`441`, but with all their dependencies included. " +"Its primary goal is making distributing Python applications and command line " +"tools fast & easy." msgstr "" #: ../source/key_projects.rst:598 -msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" +msgid "" +"`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" msgstr "" #: ../source/key_projects.rst:603 -msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." +msgid "" +"A flexible package manager designed to support multiple versions, " +"configurations, platforms, and compilers. Spack is like Homebrew, but " +"packages are written in Python and parameterized to allow easy swapping of " +"compilers, library versions, build options, etc. Arbitrarily many versions " +"of packages can coexist on the same system. Spack was designed for rapidly " +"building high performance scientific applications on clusters and " +"supercomputers." msgstr "" #: ../source/key_projects.rst:611 -msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." +msgid "" +"Spack is not in PyPI (yet), but it requires no installation and can be used " +"immediately after cloning from GitHub." msgstr "" #: ../source/key_projects.rst:617 @@ -4995,11 +7395,18 @@ msgid "zest.releaser" msgstr "" #: ../source/key_projects.rst:619 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgid "" +"`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:623 -msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." +msgid "" +"``zest.releaser`` is a Python package release tool providing an abstraction " +"layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to " +"automate incrementing package version numbers, updating changelogs, tagging " +"releases in source control, and uploading new packages to PyPI." msgstr "" #: ../source/key_projects.rst:630 @@ -5011,11 +7418,17 @@ msgid "ensurepip" msgstr "" #: ../source/key_projects.rst:637 -msgid "`Docs `__ | `Issues `__" +msgid "" +"`Docs `__ | `Issues " +"`__" msgstr "" #: ../source/key_projects.rst:640 -msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." +msgid "" +"A package in the Python Standard Library that provides support for " +"bootstrapping :ref:`pip` into an existing Python installation or virtual " +"environment. In most cases, end users won't use this module, but rather it " +"will be used during the build of the Python distribution." msgstr "" #: ../source/key_projects.rst:649 @@ -5023,15 +7436,26 @@ msgid "distutils" msgstr "" #: ../source/key_projects.rst:651 -msgid "`Docs `__ | `Issues `__" +msgid "" +"`Docs `__ | `Issues " +"`__" msgstr "" #: ../source/key_projects.rst:654 -msgid "The original Python packaging system, added to the standard library in Python 2.0." +msgid "" +"The original Python packaging system, added to the standard library in " +"Python 2.0." msgstr "" #: ../source/key_projects.rst:657 -msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." +msgid "" +"Due to the challenges of maintaining a packaging system where feature " +"updates are tightly coupled to language runtime updates, direct usage of :" +"ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being " +"the preferred replacement. :ref:`Setuptools` not only provides features that " +"plain :ref:`distutils` doesn't offer (such as dependency declarations and " +"entry point declarations), it also provides a consistent build interface and " +"feature set across all supported Python versions." msgstr "" #: ../source/key_projects.rst:670 @@ -5039,11 +7463,17 @@ msgid "venv" msgstr "" #: ../source/key_projects.rst:672 -msgid "`Docs `__ | `Issues `__" +msgid "" +"`Docs `__ | `Issues `__" msgstr "" #: ../source/key_projects.rst:675 -msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgid "" +"A package in the Python Standard Library (starting with Python 3.3) for " +"creating :term:`Virtual Environments `. For more " +"information, see the section on :ref:`Creating and using Virtual " +"Environments`." msgstr "" #: ../source/news.rst:2 @@ -5115,7 +7545,8 @@ msgid "April 2019" msgstr "" #: ../source/news.rst:31 -msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" +msgid "" +"Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" msgstr "" #: ../source/news.rst:32 @@ -5139,7 +7570,9 @@ msgid "February 2019" msgstr "" #: ../source/news.rst:41 -msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" +msgid "" +"Elaborate upon the differences between the tutorial and the real packaging " +"process. (:pr:`602`)" msgstr "" #: ../source/news.rst:42 @@ -5223,7 +7656,8 @@ msgid "Replaced tar command with working command. (:pr:`552`)" msgstr "" #: ../source/news.rst:72 -msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" +msgid "" +"Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" msgstr "" #: ../source/news.rst:75 @@ -5235,7 +7669,8 @@ msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" msgstr "" #: ../source/news.rst:77 -msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" +msgid "" +"Moved the Overview to a task based lead in along with the others. (:pr:`540`)" msgstr "" #: ../source/news.rst:78 @@ -5279,7 +7714,8 @@ msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" msgstr "" #: ../source/news.rst:97 -msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" +msgid "" +"Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" msgstr "" #: ../source/news.rst:98 @@ -5343,7 +7779,8 @@ msgid "Updated \"installing scientific packages\". (:pr:`455`)" msgstr "" #: ../source/news.rst:119 -msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" +msgid "" +"Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" msgstr "" #: ../source/news.rst:120 @@ -5359,7 +7796,9 @@ msgid "February 2018" msgstr "" #: ../source/news.rst:126 -msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" +msgid "" +"Added python3-venv and python3-pip to Debian installation instructions. (:pr:" +"`445`)" msgstr "" #: ../source/news.rst:127 @@ -5367,7 +7806,8 @@ msgid "Updated PyPI migration info. (:pr:`439`)" msgstr "" #: ../source/news.rst:128 -msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" +msgid "" +"Added a warning about managing multiple versions with pipenv. (:pr:`430`)" msgstr "" #: ../source/news.rst:129 @@ -5395,7 +7835,8 @@ msgid "December 2017" msgstr "" #: ../source/news.rst:141 -msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" +msgid "" +"Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" msgstr "" #: ../source/news.rst:142 @@ -5415,15 +7856,20 @@ msgid "November 2017" msgstr "" #: ../source/news.rst:149 -msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" +msgid "" +"Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" msgstr "" #: ../source/news.rst:150 -msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" +msgid "" +"Updated the *Single Sourcing Package Version* tutorial to reflect pip's " +"current strategy. (:pr:`400`)" msgstr "" #: ../source/news.rst:152 -msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" +msgid "" +"Added documentation about the ``py_modules`` argument to ``setup``. (:pr:" +"`398`)" msgstr "" #: ../source/news.rst:153 @@ -5435,11 +7881,14 @@ msgid "October 2017" msgstr "" #: ../source/news.rst:158 -msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" +msgid "" +"Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" msgstr "" #: ../source/news.rst:159 -msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" +msgid "" +"Created a new guide for managing packages using ``pip`` and ``virtualenv``. " +"(:pr:`385`)" msgstr "" #: ../source/news.rst:160 @@ -5451,7 +7900,9 @@ msgid "September 2017" msgstr "" #: ../source/news.rst:165 -msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" +msgid "" +"Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:" +"`379`)" msgstr "" #: ../source/news.rst:167 @@ -5463,7 +7914,9 @@ msgid "August 2017" msgstr "" #: ../source/news.rst:172 -msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" +msgid "" +"Added a new, experimental tutorial on installing packages using ``Pipenv``. " +"(:pr:`369`)" msgstr "" #: ../source/news.rst:173 @@ -5487,15 +7940,20 @@ msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" msgstr "" #: ../source/news.rst:181 -msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" +msgid "" +"Updated this guide's ``readme`` with instructions on how to build the guide " +"locally. (:pr:`356`)" msgstr "" #: ../source/news.rst:182 -msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" +msgid "" +"Made the new ``TestPyPI`` URL more visible, adding note to homepage about " +"pypi.org. (:pr:`354`)" msgstr "" #: ../source/news.rst:183 -msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" +msgid "" +"Added a note about the removal of the explicit registration API. (:pr:`347`)" msgstr "" #: ../source/news.rst:186 @@ -5511,11 +7969,14 @@ msgid "Added documentation for ``python_requires``. (:pr:`338`)" msgstr "" #: ../source/news.rst:190 -msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" +msgid "" +"Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:" +"pr:`335`)" msgstr "" #: ../source/news.rst:191 -msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" +msgid "" +"Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" msgstr "" #: ../source/news.rst:192 @@ -5547,7 +8008,8 @@ msgid "May 2017" msgstr "" #: ../source/news.rst:202 -msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" +msgid "" +"Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" msgstr "" #: ../source/news.rst:203 @@ -5555,7 +8017,9 @@ msgid "Added contributor and style guide. (:pr:`307`)" msgstr "" #: ../source/news.rst:204 -msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" +msgid "" +"Documented ``pip`` and ``easy_install``'s differences for per-project " +"indexes. (:pr:`233`)" msgstr "" #: ../source/news.rst:207 @@ -5567,11 +8031,15 @@ msgid "Added travis configuration for testing pull requests. (:pr:`300`)" msgstr "" #: ../source/news.rst:210 -msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" +msgid "" +"Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:" +"`299`)" msgstr "" #: ../source/news.rst:211 -msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" +msgid "" +"Removed the ``twine register`` reference in the *Distributing Packages* " +"tutorial. (:pr:`271`)" msgstr "" #: ../source/news.rst:212 @@ -5583,23 +8051,33 @@ msgid "Added a topic on namespace packages. (:pr:`290`)" msgstr "" #: ../source/news.rst:214 -msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" +msgid "" +"Added documentation explaining prominently how to install ``pip`` in ``/usr/" +"local``. (:pr:`230`)" msgstr "" #: ../source/news.rst:215 -msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" +msgid "" +"Updated development mode documentation to mention that order of local " +"packages matters. (:pr:`208`)" msgstr "" #: ../source/news.rst:216 -msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" +msgid "" +"Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted " +"projects (:pr:`239`)" msgstr "" #: ../source/news.rst:217 -msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" +msgid "" +"Swaped order of :file:`setup.py` arguments for the upload command, as order " +"is significant. (:pr:`260`)" msgstr "" #: ../source/news.rst:219 -msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" +msgid "" +"Explained how to install from unsupported sources using a helper " +"application. (:pr:`289`)" msgstr "" #: ../source/news.rst:223 @@ -5623,15 +8101,26 @@ msgid "An Overview of Packaging for Python" msgstr "" #: ../source/overview.rst:7 -msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." +msgid "" +"As a general-purpose programming language, Python is designed to be used in " +"many ways. You can build web sites or industrial robots or a game for your " +"friends to play, and much more, all using the same core technology." msgstr "" #: ../source/overview.rst:12 -msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." +msgid "" +"Python's flexibility is why the first step in every Python project must be " +"to think about the project's audience and the corresponding environment " +"where the project will run. It might seem strange to think about packaging " +"before writing code, but this process does wonders for avoiding future " +"headaches." msgstr "" #: ../source/overview.rst:18 -msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." +msgid "" +"This overview provides a general-purpose decision tree for reasoning about " +"Python's plethora of packaging options. Read on to choose the best " +"technology for your next project." msgstr "" #: ../source/overview.rst:26 @@ -5639,23 +8128,36 @@ msgid "Thinking about deployment" msgstr "" #: ../source/overview.rst:28 -msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" +msgid "" +"Packages exist to be installed (or *deployed*), so before you package " +"anything, you'll want to have some answers to the deployment questions below:" msgstr "" #: ../source/overview.rst:32 -msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" +msgid "" +"Who are your software's users? Will your software be installed by other " +"developers doing software development, operations people in a datacenter, or " +"a less software-savvy group?" msgstr "" #: ../source/overview.rst:35 -msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" +msgid "" +"Is your software intended to run on servers, desktops, mobile clients " +"(phones, tablets, etc.), or embedded in dedicated devices?" msgstr "" #: ../source/overview.rst:37 -msgid "Is your software installed individually, or in large deployment batches?" +msgid "" +"Is your software installed individually, or in large deployment batches?" msgstr "" #: ../source/overview.rst:39 -msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." +msgid "" +"Packaging is all about target environment and deployment experience. There " +"are many answers to the questions above and each combination of " +"circumstances has its own solutions. With this information, the following " +"overview will guide you to the packaging technologies best suited to your " +"project." msgstr "" #: ../source/overview.rst:46 @@ -5663,11 +8165,19 @@ msgid "Packaging Python libraries and tools" msgstr "" #: ../source/overview.rst:48 -msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." +msgid "" +"You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are " +"just a few of the tools Python's ecosystem provides for distributing Python " +"code to developers, which you can read about in :doc:`guides/distributing-" +"packages-using-setuptools`." msgstr "" #: ../source/overview.rst:53 -msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." +msgid "" +"The following approaches to packaging are meant for libraries and tools used " +"by technical audience in a development setting. If you're looking for ways " +"to package Python for a non-technical audience and/or a production setting, " +"skip ahead to :ref:`packaging-applications`." msgstr "" #: ../source/overview.rst:59 @@ -5675,15 +8185,27 @@ msgid "Python modules" msgstr "" #: ../source/overview.rst:61 -msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." +msgid "" +"A Python file, provided it only relies on the standard library, can be " +"redistributed and reused. You will also need to ensure it's written for the " +"right version of Python, and only relies on the standard library." msgstr "" #: ../source/overview.rst:66 -msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." +msgid "" +"This is great for sharing simple scripts and snippets between people who " +"both have compatible Python versions (such as via email, StackOverflow, or " +"GitHub gists). There are even some entire Python libraries that offer this " +"as an option, such as `bottle.py `_ and " +"`boltons `_." msgstr "" #: ../source/overview.rst:73 -msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." +msgid "" +"However, this pattern won't scale for projects that consist of multiple " +"files, need additional libraries, or need a specific version of Python, " +"hence the options below." msgstr "" #: ../source/overview.rst:78 @@ -5691,31 +8213,60 @@ msgid "Python source distributions" msgstr "" #: ../source/overview.rst:80 -msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." +msgid "" +"If your code consists of multiple Python files, it's usually organized into " +"a directory structure. Any directory containing Python files can comprise " +"an :term:`Import Package`." msgstr "" #: ../source/overview.rst:84 -msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." +msgid "" +"Because packages consist of multiple files, they are harder to distribute. " +"Most protocols support transferring only one file at a time (when was the " +"last time you clicked a link and it downloaded multiple files?). It's easier " +"to get incomplete transfers, and harder to guarantee code integrity at the " +"destination." msgstr "" #: ../source/overview.rst:90 -msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." +msgid "" +"So long as your code contains nothing but pure Python code, and you know " +"your deployment environment supports your version of Python, then you can " +"use Python's native packaging tools to create a *source* :term:`Distribution " +"Package`, or *sdist* for short." msgstr "" #: ../source/overview.rst:95 -msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." +msgid "" +"Python's *sdists* are compressed archives (``.tar.gz`` files) containing one " +"or more packages or modules. If your code is pure-Python, and you only " +"depend on other Python packages, you can `go here to learn more `_." msgstr "" #: ../source/overview.rst:100 -msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." +msgid "" +"If you rely on any non-Python code, or non-Python packages (such as `libxml2 " +"`_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next " +"section, which also has many advantages for pure-Python libraries." msgstr "" #: ../source/overview.rst:107 -msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" +msgid "" +"Python and PyPI support multiple distributions providing different " +"implementations of the same package. For instance the unmaintained-but-" +"seminal `PIL distribution `_ provides the PIL " +"package, and so does `Pillow `_, an " +"actively-maintained fork of PIL!" msgstr "" #: ../source/overview.rst:114 -msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." +msgid "" +"This Python packaging superpower makes it possible for Pillow to be a drop-" +"in replacement for PIL, just by changing your project's ``install_requires`` " +"or ``requirements.txt``." msgstr "" #: ../source/overview.rst:119 @@ -5723,23 +8274,43 @@ msgid "Python binary distributions" msgstr "" #: ../source/overview.rst:121 -msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." +msgid "" +"So much of Python's practical power comes from its ability to integrate with " +"the software ecosystem, in particular libraries written in C, C++, Fortran, " +"Rust, and other languages." msgstr "" #: ../source/overview.rst:125 -msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." +msgid "" +"Not all developers have the right tools or experiences to build these " +"components written in these compiled languages, so Python created the :term:" +"`Wheel`, a package format designed to ship libraries with compiled " +"artifacts. In fact, Python's package installer, ``pip``, always prefers " +"wheels because installation is always faster, so even pure-Python packages " +"work better with wheels." msgstr "" #: ../source/overview.rst:132 -msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." +msgid "" +"Binary distributions are best when they come with source distributions to " +"match. Even if you don't upload wheels of your code for every operating " +"system, by uploading the sdist, you're enabling users of other platforms to " +"still build it for themselves. Default to publishing both sdist and wheel " +"archives together, *unless* you're creating artifacts for a very specific " +"use case where you know the recipient only needs one or the other." msgstr "" #: ../source/overview.rst:140 -msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." +msgid "" +"Python and PyPI make it easy to upload both wheels and sdists together. Just " +"follow the :doc:`tutorials/packaging-projects` tutorial." msgstr "" #: ../source/overview.rst:148 -msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." +msgid "" +"Python's recommended built-in library and tool packaging technologies. " +"Excerpted from `The Packaging Gradient (2017) `_." msgstr "" #: ../source/overview.rst:155 @@ -5747,23 +8318,39 @@ msgid "Packaging Python applications" msgstr "" #: ../source/overview.rst:157 -msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." +msgid "" +"So far we've only discussed Python's native distribution tools. Based on our " +"introduction, you would be correct to infer these built-in approaches only " +"target environments which have Python, and an audience who knows how to " +"install Python packages." msgstr "" #: ../source/overview.rst:162 -msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." +msgid "" +"With the variety of operating systems, configurations, and people out there, " +"this assumption is only safe when targeting a developer audience." msgstr "" #: ../source/overview.rst:166 -msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." +msgid "" +"Python's native packaging is mostly built for distributing reusable code, " +"called libraries, between developers. You can piggyback **tools**, or basic " +"applications for developers, on top of Python's library packaging, using " +"technologies like `setuptools entry_points `_." msgstr "" #: ../source/overview.rst:172 -msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." +msgid "" +"Libraries are building blocks, not complete applications. For distributing " +"applications, there's a whole new world of technologies out there." msgstr "" #: ../source/overview.rst:176 -msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." +msgid "" +"The next few sections organize these application packaging options according " +"to their dependencies on the target environment, so you can choose the right " +"one for your project." msgstr "" #: ../source/overview.rst:181 @@ -5771,15 +8358,27 @@ msgid "Depending on a framework" msgstr "" #: ../source/overview.rst:183 -msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." +msgid "" +"Some types of Python applications, like web site backends and other network " +"services, are common enough that they have frameworks to enable their " +"development and packaging. Other types of applications, like dynamic web " +"frontends and mobile clients, are complex enough to target that a framework " +"becomes more than a convenience." msgstr "" #: ../source/overview.rst:189 -msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." +msgid "" +"In all these cases, it makes sense to work backwards, from the framework's " +"packaging and deployment story. Some frameworks include a deployment system " +"which wraps the technologies outlined in the rest of the guide. In these " +"cases, you'll want to defer to your framework's packaging guide for the " +"easiest and most reliable production experience." msgstr "" #: ../source/overview.rst:195 -msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." +msgid "" +"If you ever wonder how these platforms and frameworks work under the hood, " +"you can always read the sections beyond." msgstr "" #: ../source/overview.rst:199 @@ -5787,11 +8386,15 @@ msgid "Service platforms" msgstr "" #: ../source/overview.rst:201 -msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." +msgid "" +"If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku " +"or Google App Engine, you are going to want to follow their respective " +"packaging guides." msgstr "" #: ../source/overview.rst:205 -msgid "`Heroku `_" +msgid "" +"`Heroku `_" msgstr "" #: ../source/overview.rst:206 @@ -5811,11 +8414,16 @@ msgid "\"Serverless\" frameworks like `Zappa `_" msgstr "" #: ../source/overview.rst:211 -msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." +msgid "" +"In all these setups, the platform takes care of packaging and deployment, as " +"long as you follow their patterns. Most software does not fit one of these " +"templates, hence the existence of all the other options below." msgstr "" #: ../source/overview.rst:216 -msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." +msgid "" +"If you're developing software that will be deployed to machines you own, " +"users' personal computers, or any other arrangement, read on." msgstr "" #: ../source/overview.rst:220 @@ -5823,11 +8431,16 @@ msgid "Web browsers and mobile applications" msgstr "" #: ../source/overview.rst:222 -msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." +msgid "" +"Python's steady advances are leading it into new spaces. These days you can " +"write a mobile app or web application frontend in Python. While the language " +"may be familiar, the packaging and deployment practices are brand new." msgstr "" #: ../source/overview.rst:227 -msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" +msgid "" +"If you're planning on releasing to these new frontiers, you'll want to check " +"out the following frameworks, and refer to their packaging guides:" msgstr "" #: ../source/overview.rst:231 @@ -5847,7 +8460,10 @@ msgid "`Flexx `_" msgstr "" #: ../source/overview.rst:236 -msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." +msgid "" +"If you are *not* interested in using a framework or platform, or just wonder " +"about some of the technologies and techniques utilized by the frameworks " +"above, continue reading below." msgstr "" #: ../source/overview.rst:241 @@ -5855,7 +8471,12 @@ msgid "Depending on a pre-installed Python" msgstr "" #: ../source/overview.rst:243 -msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." +msgid "" +"Pick an arbitrary computer, and depending on the context, there's a very " +"good chance Python is already installed. Included by default in most Linux " +"and Mac operating systems for many years now, you can reasonably depend on " +"Python preexisting in your data centers or on the personal machines of " +"developers and data scientists." msgstr "" #: ../source/overview.rst:249 @@ -5867,7 +8488,9 @@ msgid "`PEX `_ (Python EXecutable)" msgstr "" #: ../source/overview.rst:252 -msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" +msgid "" +"`zipapp `_ (does not help " +"manage dependencies, requires Python 3.5+)" msgstr "" #: ../source/overview.rst:253 @@ -5875,11 +8498,17 @@ msgid "`shiv `_ (requires Python 3)" msgstr "" #: ../source/overview.rst:255 -msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." +msgid "" +"Of all the approaches here, depending on a pre-installed Python relies the " +"most on the target environment. Of course, this also makes for the smallest " +"package, as small as single-digit megabytes, or even kilobytes." msgstr "" #: ../source/overview.rst:260 -msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." +msgid "" +"In general, decreasing the dependency on the target system increases the " +"size of our package, so the solutions here are roughly arranged by " +"increasing size of output." msgstr "" #: ../source/overview.rst:267 @@ -5887,11 +8516,24 @@ msgid "Depending on a separate software distribution ecosystem" msgstr "" #: ../source/overview.rst:269 -msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." +msgid "" +"For a long time many operating systems, including Mac and Windows, lacked " +"built-in package management. Only recently did these OSes gain so-called " +"\"app stores\", but even those focus on consumer applications and offer " +"little for developers." msgstr "" #: ../source/overview.rst:274 -msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." +msgid "" +"Developers long sought remedies, and in this struggle, emerged with their " +"own package management solutions, such as `Homebrew `_. " +"The most relevant alternative for Python developers is a package ecosystem " +"called `Anaconda `_. Anaconda is built around Python and is " +"increasingly common in academic, analytical, and other data-oriented " +"environments, even making its way `into server-oriented environments " +"`_." msgstr "" #: ../source/overview.rst:284 @@ -5899,15 +8541,21 @@ msgid "Instructions on building and publishing for the Anaconda ecosystem:" msgstr "" #: ../source/overview.rst:286 -msgid "`Building libraries and applications with conda `_" +msgid "" +"`Building libraries and applications with conda `_" msgstr "" #: ../source/overview.rst:287 -msgid "`Transitioning a native Python package to Anaconda `_" +msgid "" +"`Transitioning a native Python package to Anaconda `_" msgstr "" #: ../source/overview.rst:289 -msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" +msgid "" +"A similar model involves installing an alternative Python distribution, but " +"does not support arbitrary operating system-level packages:" msgstr "" #: ../source/overview.rst:293 @@ -5927,15 +8575,24 @@ msgid "Bringing your own Python executable" msgstr "" #: ../source/overview.rst:302 -msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." +msgid "" +"Computing as we know it is defined by the ability to execute programs. Every " +"operating system natively supports one or more formats of program they can " +"natively execute." msgstr "" #: ../source/overview.rst:306 -msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." +msgid "" +"There are many techniques and technologies which turn your Python program " +"into one of these formats, most of which involve embedding the Python " +"interpreter and any other dependencies into a single executable file." msgstr "" #: ../source/overview.rst:311 -msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." +msgid "" +"This approach, called *freezing*, offers wide compatibility and seamless " +"user experience, though often requires multiple technologies, and a good " +"amount of effort." msgstr "" #: ../source/overview.rst:315 @@ -5947,11 +8604,14 @@ msgid "`pyInstaller `_ - Cross-platform" msgstr "" #: ../source/overview.rst:318 -msgid "`cx_Freeze `_ - Cross-platform" +msgid "" +"`cx_Freeze `_ - Cross-platform" msgstr "" #: ../source/overview.rst:319 -msgid "`constructor `_ - For command-line installers" +msgid "" +"`constructor `_ - For command-line " +"installers" msgstr "" #: ../source/overview.rst:320 @@ -5963,7 +8623,9 @@ msgid "`py2app `_ - Mac only" msgstr "" #: ../source/overview.rst:322 -msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" +msgid "" +"`bbFreeze `_ - Windows, Linux, Python 2 " +"only" msgstr "" #: ../source/overview.rst:323 @@ -5975,7 +8637,9 @@ msgid "`pynsist `_ - Windows only" msgstr "" #: ../source/overview.rst:326 -msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." +msgid "" +"Most of the above imply single-user deployments. For multi-component server " +"applications, see `Chef Omnibus `_." msgstr "" #: ../source/overview.rst:332 @@ -5983,15 +8647,24 @@ msgid "Bringing your own userspace" msgstr "" #: ../source/overview.rst:334 -msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." +msgid "" +"An increasing number of operating systems -- including Linux, Mac OS, and " +"Windows -- can be set up to run applications packaged as lightweight images, " +"using a relatively modern arrangement often referred to as `operating-system-" +"level virtualization `_, or *containerization*." msgstr "" #: ../source/overview.rst:341 -msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." +msgid "" +"These techniques are mostly Python agnostic, because they package whole OS " +"filesystems, not just Python or Python packages." msgstr "" #: ../source/overview.rst:344 -msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" +msgid "" +"Adoption is most extensive among Linux servers, where the technology " +"originated and where the technologies below work best:" msgstr "" #: ../source/overview.rst:347 @@ -6015,11 +8688,18 @@ msgid "Bringing your own kernel" msgstr "" #: ../source/overview.rst:355 -msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." +msgid "" +"Most operating systems support some form of classical virtualization, " +"running applications packaged as images containing a full operating system " +"of their own. Running these virtual machines, or VMs, is a mature approach, " +"widespread in data center environments." msgstr "" #: ../source/overview.rst:360 -msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" +msgid "" +"These techniques are mostly reserved for larger scale deployments in data " +"centers, though certain complex applications can benefit from this " +"packaging. Technologies are Python agnostic, and include:" msgstr "" #: ../source/overview.rst:364 @@ -6027,11 +8707,16 @@ msgid "`Vagrant `_" msgstr "" #: ../source/overview.rst:365 -msgid "`VHD `_, `AMI `_, and `other formats `_" +msgid "" +"`VHD `_, `AMI `_, and `other formats `_" msgstr "" #: ../source/overview.rst:366 -msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" +msgid "" +"`OpenStack `_ - A cloud " +"management system in Python, with extensive VM support" msgstr "" #: ../source/overview.rst:369 @@ -6039,19 +8724,31 @@ msgid "Bringing your own hardware" msgstr "" #: ../source/overview.rst:371 -msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." +msgid "" +"The most all-encompassing way to ship your software would be to ship it " +"already-installed on some hardware. This way, your software's user would " +"require only electricity." msgstr "" #: ../source/overview.rst:375 -msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." +msgid "" +"Whereas the virtual machines described above are primarily reserved for the " +"tech-savvy, you can find hardware appliances being used by everyone from the " +"most advanced data centers to the youngest children." msgstr "" #: ../source/overview.rst:379 -msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." +msgid "" +"Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the " +"datacenter or your users' homes. They plug and play, and you can call it a " +"day." msgstr "" #: ../source/overview.rst:389 -msgid "The simplified gamut of technologies used to package Python applications." +msgid "" +"The simplified gamut of technologies used to package Python applications." msgstr "" #: ../source/overview.rst:392 @@ -6059,7 +8756,9 @@ msgid "What about..." msgstr "" #: ../source/overview.rst:394 -msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." +msgid "" +"The sections above can only summarize so much, and you might be wondering " +"about some of the more conspicuous gaps." msgstr "" #: ../source/overview.rst:398 @@ -6067,19 +8766,40 @@ msgid "Operating system packages" msgstr "" #: ../source/overview.rst:400 -msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." +msgid "" +"As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some " +"operating systems have package managers of their own. If you're very sure of " +"the operating system you're targeting, you can depend directly on a format " +"like `deb `_ (for Debian, " +"Ubuntu, etc.) or `RPM `_ " +"(for Red Hat, Fedora, etc.), and use that built-in package manager to take " +"care of installation, and even deployment. You can even use `FPM `_ to generate both deb " +"and RPMs from the same source." msgstr "" #: ../source/overview.rst:411 -msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." +msgid "" +"In most deployment pipelines, the OS package manager is just one piece of " +"the puzzle." msgstr "" #: ../source/overview.rst:417 -msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." +msgid "" +"`Virtualenvs `_ have been an indispensable tool for multiple generations of Python " +"developer, but are slowly fading from view, as they are being wrapped by " +"higher-level tools. With packaging in particular, virtualenvs are used as a " +"primitive in `the dh-virtualenv tool `_ and `osnap `_, " +"both of which wrap virtualenvs in a self-contained way." msgstr "" #: ../source/overview.rst:427 -msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." +msgid "" +"For production deployments, do not rely on running ``python -m pip install`` " +"from the Internet into a virtualenv, as one might do in a development " +"environment. The overview above is full of much better solutions." msgstr "" #: ../source/overview.rst:432 @@ -6087,11 +8807,20 @@ msgid "Security" msgstr "" #: ../source/overview.rst:434 -msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." +msgid "" +"The further down the gradient you come, the harder it gets to update " +"components of your package. Everything is more tightly bound together." msgstr "" #: ../source/overview.rst:437 -msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." +msgid "" +"For example, if a kernel security issue emerges, and you're deploying " +"containers, the host system's kernel can be updated without requiring a new " +"build on behalf of the application. If you deploy VM images, you'll need a " +"new build. Whether or not this dynamic makes one option more secure is still " +"a bit of an old debate, going back to the still-unsettled matter of `static " +"versus dynamic linking `_." msgstr "" #: ../source/overview.rst:446 @@ -6099,7 +8828,12 @@ msgid "Wrap up" msgstr "" #: ../source/overview.rst:448 -msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." +msgid "" +"Packaging in Python has a bit of a reputation for being a bumpy ride. This " +"impression is mostly a byproduct of Python's versatility. Once you " +"understand the natural boundaries between each packaging solution, you begin " +"to realize that the varied landscape is a small price Python programmers pay " +"for using one of the most balanced, flexible languages available." msgstr "" #: ../source/specifications/binary-distribution-format.rst:6 @@ -6107,7 +8841,9 @@ msgid "Binary distribution format" msgstr "" #: ../source/specifications/binary-distribution-format.rst:8 -msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." +msgid "" +"The binary distribution format (:term:`wheel `) was originally " +"defined in :pep:`427`. The current version of the specification is here." msgstr "" #: ../source/specifications/binary-distribution-format.rst:13 @@ -6119,7 +8855,14 @@ msgid "This PEP describes a built-package format for Python called \"wheel\"." msgstr "" #: ../source/specifications/binary-distribution-format.rst:17 -msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." +msgid "" +"A wheel is a ZIP-format archive with a specially formatted file name and the " +"``.whl`` extension. It contains a single distribution nearly as it would be " +"installed according to PEP 376 with a particular installation scheme. " +"Although a specialized installer is recommended, a wheel file may be " +"installed by simply unpacking into site-packages with the standard 'unzip' " +"tool while preserving enough information to spread its contents out onto " +"their final paths at any later time." msgstr "" #: ../source/specifications/binary-distribution-format.rst:27 @@ -6127,7 +8870,9 @@ msgid "PEP Acceptance" msgstr "" #: ../source/specifications/binary-distribution-format.rst:29 -msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" +msgid "" +"This PEP was accepted, and the defined wheel version updated to 1.0, by Nick " +"Coghlan on 16th February, 2013 [1]_" msgstr "" #: ../source/specifications/binary-distribution-format.rst:34 @@ -6135,11 +8880,22 @@ msgid "Rationale" msgstr "" #: ../source/specifications/binary-distribution-format.rst:36 -msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." +msgid "" +"Python needs a package format that is easier to install than sdist. Python's " +"sdist packages are defined by and require the distutils and setuptools build " +"systems, running arbitrary code to build-and-install, and re-compile, code " +"just so it can be installed into a new virtualenv. This system of " +"conflating build-install is slow, hard to maintain, and hinders innovation " +"in both build systems and installers." msgstr "" #: ../source/specifications/binary-distribution-format.rst:43 -msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." +msgid "" +"Wheel attempts to remedy these problems by providing a simpler interface " +"between the build system and the installer. The wheel binary package format " +"frees installers from having to know about the build system, saves time by " +"amortizing compile time over many installations, and removes the need to " +"install a build system in the target environment." msgstr "" #: ../source/specifications/binary-distribution-format.rst:52 @@ -6163,11 +8919,14 @@ msgid "Parse ``distribution-1.0.dist-info/WHEEL``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:62 -msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." +msgid "" +"Check that installer is compatible with Wheel-Version. Warn if minor " +"version is greater, abort if major version is greater." msgstr "" #: ../source/specifications/binary-distribution-format.rst:64 -msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." +msgid "" +"If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:66 @@ -6179,15 +8938,24 @@ msgid "Spread." msgstr "" #: ../source/specifications/binary-distribution-format.rst:70 -msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." +msgid "" +"Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is " +"data) ``distribution-1.0.data/``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:72 -msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." +msgid "" +"Move each subtree of ``distribution-1.0.data/`` onto its destination path. " +"Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of " +"destination directories, such as ``distribution-1.0.data/(purelib|platlib|" +"headers|scripts|data)``. The initially supported paths are taken from " +"``distutils.command.install``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:78 -msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." +msgid "" +"If applicable, update scripts starting with ``#!python`` to point to the " +"correct interpreter." msgstr "" #: ../source/specifications/binary-distribution-format.rst:80 @@ -6199,7 +8967,9 @@ msgid "Remove empty ``distribution-1.0.data`` directory." msgstr "" #: ../source/specifications/binary-distribution-format.rst:83 -msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" +msgid "" +"Compile any installed .py to .pyc. (Uninstallers should be smart enough to " +"remove .pyc even if it is not mentioned in RECORD.)" msgstr "" #: ../source/specifications/binary-distribution-format.rst:87 @@ -6211,11 +8981,17 @@ msgid "Rewrite ``#!python``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:90 -msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." +msgid "" +"In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/" +"``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!" +"python'``, rewrite to point to the correct interpreter. Unix installers may " +"need to add the +x bit to these files if the archive was created on Windows." msgstr "" #: ../source/specifications/binary-distribution-format.rst:96 -msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." +msgid "" +"The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI " +"script instead of a console script." msgstr "" #: ../source/specifications/binary-distribution-format.rst:102 @@ -6223,7 +8999,10 @@ msgid "Generate script wrappers." msgstr "" #: ../source/specifications/binary-distribution-format.rst:100 -msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." +msgid "" +"In wheel, scripts packaged on Unix systems will certainly not have " +"accompanying .exe wrappers. Windows installers may want to add them during " +"install." msgstr "" #: ../source/specifications/binary-distribution-format.rst:105 @@ -6235,7 +9014,11 @@ msgid "Place ``.dist-info`` at the end of the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:108 -msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." +msgid "" +"Archivers are encouraged to place the ``.dist-info`` files physically at the " +"end of the archive. This enables some potentially interesting ZIP tricks " +"including the ability to amend the metadata without rewriting the entire " +"archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:115 @@ -6247,7 +9030,9 @@ msgid "File name convention" msgstr "" #: ../source/specifications/binary-distribution-format.rst:120 -msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." +msgid "" +"The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-" +"{abi tag}-{platform tag}.whl``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:124 @@ -6267,7 +9052,12 @@ msgid "build tag" msgstr "" #: ../source/specifications/binary-distribution-format.rst:130 -msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." +msgid "" +"Optional build number. Must start with a digit. Acts as a tie-breaker if " +"two wheel file names are the same in all other respects (i.e. name, version, " +"and other tags). Sort as an empty tuple if unspecified, else sort as a two-" +"item tuple with the first item being the initial digits as an ``int``, and " +"the second item being the remainder of the tag as a ``str``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:138 @@ -6295,11 +9085,18 @@ msgid "E.g. 'linux_x86_64', 'any'." msgstr "" #: ../source/specifications/binary-distribution-format.rst:146 -msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." +msgid "" +"For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of " +"a package called 'distribution', and is compatible with Python 2.7 (any " +"Python 2.7 implementation), with no ABI (pure Python), on any CPU " +"architecture." msgstr "" #: ../source/specifications/binary-distribution-format.rst:151 -msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." +msgid "" +"The last three components of the filename before the extension are called " +"\"compatibility tags.\" The compatibility tags express the package's basic " +"interpreter requirements and are detailed in PEP 425." msgstr "" #: ../source/specifications/binary-distribution-format.rst:156 @@ -6307,31 +9104,50 @@ msgid "Escaping and Unicode" msgstr "" #: ../source/specifications/binary-distribution-format.rst:158 -msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" +msgid "" +"As the components of the filename are separated by a dash (``-``, HYPHEN-" +"MINUS), this character cannot appear within any component. This is handled " +"as follows:" msgstr "" #: ../source/specifications/binary-distribution-format.rst:161 -msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." +msgid "" +"In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE " +"and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent " +"to :pep:`503` normalisation followed by replacing ``-`` with ``_``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:164 -msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." +msgid "" +"Version numbers should be normalised according to :pep:`440`. Normalised " +"version numbers cannot contain ``-``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:166 -msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." +msgid "" +"The remaining components may not contain ``-`` characters, so no escaping is " +"necessary." msgstr "" #: ../source/specifications/binary-distribution-format.rst:169 -msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." +msgid "" +"Tools producing wheels should verify that the filename components do not " +"contain ``-``, as the resulting file may not be processed correctly if they " +"do." msgstr "" #: ../source/specifications/binary-distribution-format.rst:172 -msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." +msgid "" +"The archive filename is Unicode. It will be some time before the tools are " +"updated to support non-ASCII filenames, but they are supported in this " +"specification." msgstr "" #: ../source/specifications/binary-distribution-format.rst:176 -msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." +msgid "" +"The filenames *inside* the archive are encoded as UTF-8. Although some ZIP " +"clients in common use do not properly display UTF-8 filenames, the encoding " +"is supported by both the ZIP specification and Python's ``zipfile``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:182 @@ -6339,11 +9155,17 @@ msgid "File contents" msgstr "" #: ../source/specifications/binary-distribution-format.rst:184 -msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" +msgid "" +"The contents of a wheel file, where {distribution} is replaced with the name " +"of the package, e.g. ``beaglevote`` and {version} is replaced with its " +"version, e.g. ``1.0.0``, consist of:" msgstr "" #: ../source/specifications/binary-distribution-format.rst:188 -msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." +msgid "" +"``/``, the root of the archive, contains all files to be installed in " +"``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and " +"``platlib`` are usually both ``site-packages``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:191 @@ -6351,19 +9173,30 @@ msgid "``{distribution}-{version}.dist-info/`` contains metadata." msgstr "" #: ../source/specifications/binary-distribution-format.rst:192 -msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." +msgid "" +"``{distribution}-{version}.data/`` contains one subdirectory for each non-" +"empty install scheme key not already covered, where the subdirectory name is " +"an index into a dictionary of install paths (e.g. ``data``, ``scripts``, " +"``include``, ``purelib``, ``platlib``)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:196 -msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." +msgid "" +"Python scripts must appear in ``scripts`` and begin with exactly ``b'#!" +"python'`` in order to enjoy script wrapper generation and ``#!python`` " +"rewriting at install time. They may have any or no extension." msgstr "" #: ../source/specifications/binary-distribution-format.rst:200 -msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." +msgid "" +"``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or " +"greater format metadata." msgstr "" #: ../source/specifications/binary-distribution-format.rst:202 -msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" +msgid "" +"``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive " +"itself in the same basic key: value format::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:212 @@ -6371,27 +9204,40 @@ msgid "``Wheel-Version`` is the version number of the Wheel specification." msgstr "" #: ../source/specifications/binary-distribution-format.rst:213 -msgid "``Generator`` is the name and optionally the version of the software that produced the archive." +msgid "" +"``Generator`` is the name and optionally the version of the software that " +"produced the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:215 -msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." +msgid "" +"``Root-Is-Purelib`` is true if the top level directory of the archive should " +"be installed into purelib; otherwise the root should be installed into " +"platlib." msgstr "" #: ../source/specifications/binary-distribution-format.rst:218 -msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." +msgid "" +"``Tag`` is the wheel's expanded compatibility tags; in the example the " +"filename would contain ``py2.py3-none-any``." msgstr "" #: ../source/specifications/binary-distribution-format.rst:220 -msgid "``Build`` is the build number and is omitted if there is no build number." +msgid "" +"``Build`` is the build number and is omitted if there is no build number." msgstr "" #: ../source/specifications/binary-distribution-format.rst:221 -msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." +msgid "" +"A wheel installer should warn if Wheel-Version is greater than the version " +"it supports, and must fail if Wheel-Version has a greater major version than " +"the version it supports." msgstr "" #: ../source/specifications/binary-distribution-format.rst:224 -msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." +msgid "" +"Wheel, being an installation format that is intended to work across multiple " +"versions of Python, does not generally include .pyc files." msgstr "" #: ../source/specifications/binary-distribution-format.rst:226 @@ -6399,7 +9245,11 @@ msgid "Wheel does not contain setup.py or setup.cfg." msgstr "" #: ../source/specifications/binary-distribution-format.rst:228 -msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." +msgid "" +"This version of the wheel specification is based on the distutils install " +"schemes and does not define how to install files to other locations. The " +"layout offers a superset of the functionality provided by the existing " +"wininst and egg binary formats." msgstr "" #: ../source/specifications/binary-distribution-format.rst:235 @@ -6408,11 +9258,15 @@ msgid "The .dist-info directory" msgstr "" #: ../source/specifications/binary-distribution-format.rst:237 -msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." +msgid "" +"Wheel .dist-info directories include at a minimum METADATA, WHEEL, and " +"RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:239 -msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." +msgid "" +"METADATA is the package metadata, the same format as PKG-INFO as found at " +"the root of sdists." msgstr "" #: ../source/specifications/binary-distribution-format.rst:241 @@ -6420,7 +9274,12 @@ msgid "WHEEL is the wheel metadata specific to a build of the package." msgstr "" #: ../source/specifications/binary-distribution-format.rst:242 -msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." +msgid "" +"RECORD is a list of (almost) all the files in the wheel and their secure " +"hashes. Unlike PEP 376, every file except RECORD, which cannot contain a " +"hash of itself, must include its hash. The hash algorithm must be sha256 or " +"better; specifically, md5 and sha1 are not permitted, as signed wheel files " +"rely on the strong hashes in RECORD to validate the integrity of the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:248 @@ -6428,15 +9287,22 @@ msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:249 -msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." +msgid "" +"RECORD.jws is used for digital signatures. It is not mentioned in RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:251 -msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." +msgid "" +"RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME " +"signatures to secure their wheel files. It is not mentioned in RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:254 -msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." +msgid "" +"During extraction, wheel installers verify all the hashes in RECORD against " +"the file contents. Apart from RECORD and its signatures, installation will " +"fail if any file in the archive is not both mentioned and correctly hashed " +"in RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:261 @@ -6444,11 +9310,17 @@ msgid "The .data directory" msgstr "" #: ../source/specifications/binary-distribution-format.rst:263 -msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" +msgid "" +"Any file that is not normally installed inside site-packages goes into the ." +"data directory, named as the .dist-info directory but with the .data/ " +"extension::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:271 -msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." +msgid "" +"The .data directory contains subdirectories with the scripts, headers, " +"documentation and so forth from the distribution. During installation the " +"contents of these subdirectories are moved onto their destination paths." msgstr "" #: ../source/specifications/binary-distribution-format.rst:277 @@ -6456,15 +9328,29 @@ msgid "Signed wheel files" msgstr "" #: ../source/specifications/binary-distribution-format.rst:279 -msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" +msgid "" +"Wheel files include an extended RECORD that enables digital signatures. PEP " +"376's RECORD is altered to include a secure hash " +"``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with " +"no trailing = characters) as the second column instead of an md5sum. All " +"possible entries are hashed, including any generated files such as .pyc " +"files, but not RECORD which cannot contain its own hash. For example::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:290 -msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." +msgid "" +"The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD " +"at all since they can only be added after RECORD is generated. Every other " +"file in the archive must have a correct hash in RECORD or the installation " +"will fail." msgstr "" #: ../source/specifications/binary-distribution-format.rst:295 -msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" +msgid "" +"If JSON web signatures are used, one or more JSON Web Signature JSON " +"Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to " +"RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD " +"as the signature's JSON payload::" msgstr "" #: ../source/specifications/binary-distribution-format.rst:302 @@ -6472,11 +9358,17 @@ msgid "(The hash value is the same format used in RECORD.)" msgstr "" #: ../source/specifications/binary-distribution-format.rst:304 -msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." +msgid "" +"If RECORD.p7s is used, it must contain a detached S/MIME format signature of " +"RECORD." msgstr "" #: ../source/specifications/binary-distribution-format.rst:307 -msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." +msgid "" +"A wheel installer is not required to understand digital signatures but MUST " +"verify the hashes in RECORD against the extracted file contents. When the " +"installer checks file hashes against RECORD, a separate signature checker " +"only needs to establish that RECORD matches the signature." msgstr "" #: ../source/specifications/binary-distribution-format.rst:312 @@ -6488,7 +9380,8 @@ msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" msgstr "" #: ../source/specifications/binary-distribution-format.rst:315 -msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" +msgid "" +"http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" msgstr "" #: ../source/specifications/binary-distribution-format.rst:316 @@ -6504,23 +9397,41 @@ msgid "Comparison to .egg" msgstr "" #: ../source/specifications/binary-distribution-format.rst:323 -msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." +msgid "" +"Wheel is an installation format; egg is importable. Wheel archives do not " +"need to include .pyc and are less tied to a specific Python version or " +"implementation. Wheel can install (pure Python) packages built with previous " +"versions of Python so you don't always have to wait for the packager to " +"catch up." msgstr "" #: ../source/specifications/binary-distribution-format.rst:328 -msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." +msgid "" +"Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible " +"with the new world of Python packaging and the new concepts it brings." msgstr "" #: ../source/specifications/binary-distribution-format.rst:331 -msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." +msgid "" +"Wheel has a richer file naming convention for today's multi-implementation " +"world. A single wheel archive can indicate its compatibility with a number " +"of Python language versions and implementations, ABIs, and system " +"architectures. Historically the ABI has been specific to a CPython release, " +"wheel is ready for the stable ABI." msgstr "" #: ../source/specifications/binary-distribution-format.rst:337 -msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." +msgid "" +"Wheel is lossless. The first wheel implementation bdist_wheel always " +"generates egg-info, and then converts it to a .whl. It is also possible to " +"convert existing eggs and bdist_wininst distributions." msgstr "" #: ../source/specifications/binary-distribution-format.rst:341 -msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." +msgid "" +"Wheel is versioned. Every wheel file contains the version of the wheel " +"specification and the implementation that packaged it. Hopefully the next " +"migration can simply be to Wheel 2.0." msgstr "" #: ../source/specifications/binary-distribution-format.rst:344 @@ -6536,7 +9447,13 @@ msgid "Wheel defines a .data directory. Should I put all my data there?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:354 -msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." +msgid "" +"This specification does not have an opinion on how you should organize your " +"code. The .data directory is just a place for any files that are not " +"normally installed inside ``site-packages`` or on the PYTHONPATH. In other " +"words, you may continue to use ``pkgutil.get_data(package, resource)`` even " +"though *those* files will usually not be distributed in *wheel's* ``.data`` " +"directory." msgstr "" #: ../source/specifications/binary-distribution-format.rst:363 @@ -6544,7 +9461,12 @@ msgid "Why does wheel include attached signatures?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:365 -msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." +msgid "" +"Attached signatures are more convenient than detached signatures because " +"they travel with the archive. Since only the individual files are signed, " +"the archive can be recompressed without invalidating the signature or " +"individual files can be verified without having to download the whole " +"archive." msgstr "" #: ../source/specifications/binary-distribution-format.rst:373 @@ -6552,7 +9474,10 @@ msgid "Why does wheel allow JWS signatures?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:375 -msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." +msgid "" +"The JOSE specifications of which JWS is a part are designed to be easy to " +"implement, a feature that is also one of wheel's primary design goals. JWS " +"yields a useful, concise pure-Python implementation." msgstr "" #: ../source/specifications/binary-distribution-format.rst:381 @@ -6560,11 +9485,15 @@ msgid "Why does wheel also allow S/MIME signatures?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:383 -msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." +msgid "" +"S/MIME signatures are allowed for users who need or want to use existing " +"public key infrastructure with wheel." msgstr "" #: ../source/specifications/binary-distribution-format.rst:386 -msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." +msgid "" +"Signed packages are only a basic building block in a secure package update " +"system. Wheel only provides the building block." msgstr "" #: ../source/specifications/binary-distribution-format.rst:391 @@ -6572,15 +9501,26 @@ msgid "What's the deal with \"purelib\" vs. \"platlib\"?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:393 -msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." +msgid "" +"Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is " +"significant on some platforms. For example, Fedora installs pure Python " +"packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent " +"packages to '/usr/lib64/pythonX.Y/site-packages'." msgstr "" #: ../source/specifications/binary-distribution-format.rst:398 -msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." +msgid "" +"A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-" +"{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: " +"true\" with those same files in the root, and it is legal to have files in " +"both the \"purelib\" and \"platlib\" categories." msgstr "" #: ../source/specifications/binary-distribution-format.rst:403 -msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." +msgid "" +"In practice a wheel should have only one of \"purelib\" or \"platlib\" " +"depending on whether it is pure Python or not and those files should be at " +"the root with the appropriate setting given for \"Root-is-purelib\"." msgstr "" #: ../source/specifications/binary-distribution-format.rst:409 @@ -6588,19 +9528,50 @@ msgid "Is it possible to import Python code directly from a wheel file?" msgstr "" #: ../source/specifications/binary-distribution-format.rst:411 -msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." +msgid "" +"Technically, due to the combination of supporting installation via simple " +"extraction and using an archive format that is compatible with " +"``zipimport``, a subset of wheel files *do* support being placed directly on " +"``sys.path``. However, while this behaviour is a natural consequence of the " +"format design, actually relying on it is generally discouraged." msgstr "" #: ../source/specifications/binary-distribution-format.rst:417 -msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." +msgid "" +"Firstly, wheel *is* designed primarily as a distribution format, so skipping " +"the installation step also means deliberately avoiding any reliance on " +"features that assume full installation (such as being able to use standard " +"tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in " +"a way that can be properly tracked for auditing and security update " +"purposes, or integrating fully with the standard build machinery for C " +"extensions by publishing header files in the appropriate place)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:426 -msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." +msgid "" +"Secondly, while some Python software is written to support running directly " +"from a zip archive, it is still common for code to be written assuming it " +"has been fully installed. When that assumption is broken by trying to run " +"the software from a zip archive, the failures can often be obscure and hard " +"to diagnose (especially when they occur in third party libraries). The two " +"most common sources of problems with this are the fact that importing C " +"extensions from a zip archive is *not* supported by CPython (since doing so " +"is not supported directly by the dynamic loading machinery on any platform) " +"and that when running from a zip archive the ``__file__`` attribute no " +"longer refers to an ordinary filesystem path, but to a combination path that " +"includes both the location of the zip archive on the filesystem and the " +"relative path to the module inside the archive. Even when software correctly " +"uses the abstract resource APIs internally, interfacing with external " +"components may still require the availability of an actual on-disk file." msgstr "" #: ../source/specifications/binary-distribution-format.rst:443 -msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." +msgid "" +"Like metaclasses, monkeypatching and metapath importers, if you're not " +"already sure you need to take advantage of this feature, you almost " +"certainly don't need it. If you *do* decide to use it anyway, be aware that " +"many projects will require a failure to be reproduced with a fully installed " +"package before accepting it as a genuine bug." msgstr "" #: ../source/specifications/binary-distribution-format.rst:450 @@ -6612,11 +9583,15 @@ msgid "Since :pep:`427`, this specification has changed as follows:" msgstr "" #: ../source/specifications/binary-distribution-format.rst:454 -msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." +msgid "" +"The rules on escaping in wheel filenames were revised, to bring them into " +"line with what popular tools actually do (February 2021)." msgstr "" #: ../source/specifications/binary-distribution-format.rst:461 -msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" +msgid "" +"PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-" +"February/124103.html)" msgstr "" #: ../source/specifications/binary-distribution-format.rst:466 @@ -6640,7 +9615,9 @@ msgid "Core metadata specifications" msgstr "" #: ../source/specifications/core-metadata.rst:7 -msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" +msgid "" +"Fields defined in the following specification should be considered valid, " +"complete and not subject to change. The required fields are:" msgstr "" #: ../source/specifications/core-metadata.rst:10 @@ -6660,15 +9637,33 @@ msgid "All the other fields are optional." msgstr "" #: ../source/specifications/core-metadata.rst:16 -msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." +msgid "" +"The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats " +"have been revised several times, and exactly which email RFC applies to " +"packaging metadata is not specified. In the absence of a precise definition, " +"the practical standard is set by what the standard library :mod:`python:" +"email.parser` module can parse using the :data:`~.python:email.policy." +"compat32` policy." msgstr "" #: ../source/specifications/core-metadata.rst:25 -msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." +msgid "" +"Although :pep:`566` defined a way to transform metadata into a JSON-" +"compatible dictionary, this is not yet used as a standard interchange " +"format. The need for tools to work with years worth of existing packages " +"makes it difficult to shift to a new format." msgstr "" #: ../source/specifications/core-metadata.rst:30 -msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." +msgid "" +"*Interpreting old metadata:* In :pep:`566`, the version specifier field " +"format specification was relaxed to accept the syntax used by popular " +"publishing tools (namely to remove the requirement that version specifiers " +"must be surrounded by parentheses). Metadata consumers may want to use the " +"more relaxed formatting rules even for metadata files that are nominally " +"less than version 2.1." msgstr "" #: ../source/specifications/core-metadata.rst:41 @@ -6676,15 +9671,25 @@ msgid "Metadata-Version" msgstr "" #: ../source/specifications/core-metadata.rst:45 -msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." +msgid "" +"Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", " +"\"2.1\" and \"2.2\"." msgstr "" #: ../source/specifications/core-metadata.rst:48 -msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." +msgid "" +"Automated tools consuming metadata SHOULD warn if ``metadata_version`` is " +"greater than the highest version they support, and MUST fail if " +"``metadata_version`` has a greater major version than the highest version " +"they support (as described in :pep:`440`, the major version is the value " +"before the first dot)." msgstr "" #: ../source/specifications/core-metadata.rst:54 -msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." +msgid "" +"For broader compatibility, build tools MAY choose to produce distribution " +"metadata using the lowest metadata version that includes all of the needed " +"fields." msgstr "" #: ../source/specifications/core-metadata.rst:58 @@ -6718,7 +9723,12 @@ msgid "Added additional restrictions on format from :pep:`508`" msgstr "" #: ../source/specifications/core-metadata.rst:72 -msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" +msgid "" +"The name of the distribution. The name field is the primary identifier for a " +"distribution. A valid name consists only of ASCII letters and numbers, " +"period, underscore and hyphen. It must start and end with a letter or " +"number. Distribution names are limited to those which match the following " +"regex (run with ``re.IGNORECASE``)::" msgstr "" #: ../source/specifications/core-metadata.rst:88 @@ -6726,7 +9736,9 @@ msgid "Version" msgstr "" #: ../source/specifications/core-metadata.rst:92 -msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." +msgid "" +"A string containing the distribution's version number. This field must be " +"in the format specified in :pep:`440`." msgstr "" #: ../source/specifications/core-metadata.rst:101 @@ -6734,31 +9746,49 @@ msgid "Dynamic (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:105 -msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." +msgid "" +"A string containing the name of another core metadata field. The field names " +"``Name`` and ``Version`` may not be specified in this field." msgstr "" #: ../source/specifications/core-metadata.rst:108 -msgid "When found in the metadata of a source distribution, the following rules apply:" +msgid "" +"When found in the metadata of a source distribution, the following rules " +"apply:" msgstr "" #: ../source/specifications/core-metadata.rst:111 -msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." +msgid "" +"If a field is *not* marked as ``Dynamic``, then the value of the field in " +"any wheel built from the sdist MUST match the value in the sdist. If the " +"field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT " +"be present in the wheel." msgstr "" #: ../source/specifications/core-metadata.rst:115 -msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." +msgid "" +"If a field is marked as ``Dynamic``, it may contain any valid value in a " +"wheel built from the sdist (including not being present at all)." msgstr "" #: ../source/specifications/core-metadata.rst:118 -msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." +msgid "" +"If the sdist metadata version is older than version 2.2, then all fields " +"should be treated as if they were specified with ``Dynamic`` (i.e. there are " +"no special restrictions on the metadata of wheels built from the sdist)." msgstr "" #: ../source/specifications/core-metadata.rst:122 -msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." +msgid "" +"In any context other than a source distribution, ``Dynamic`` is for " +"information only, and indicates that the field value was calculated at wheel " +"build time, and may not be the same as the value in the sdist or in other " +"wheels for the project." msgstr "" #: ../source/specifications/core-metadata.rst:127 -msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." +msgid "" +"Full details of the semantics of ``Dynamic`` are described in :pep:`643`." msgstr "" #: ../source/specifications/core-metadata.rst:131 @@ -6766,7 +9796,10 @@ msgid "Platform (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:135 -msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." +msgid "" +"A Platform specification describing an operating system supported by the " +"distribution which is not listed in the \"Operating System\" Trove " +"classifiers. See \"Classifier\" below." msgstr "" #: ../source/specifications/core-metadata.rst:146 @@ -6774,7 +9807,11 @@ msgid "Supported-Platform (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:150 -msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." +msgid "" +"Binary distributions containing a PKG-INFO file will use the Supported-" +"Platform field in their metadata to specify the OS and CPU for which the " +"binary distribution was compiled. The semantics of the Supported-Platform " +"field are not specified in this PEP." msgstr "" #: ../source/specifications/core-metadata.rst:164 @@ -6790,23 +9827,41 @@ msgid "This field may be specified in the message body instead." msgstr "" #: ../source/specifications/core-metadata.rst:191 -msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." +msgid "" +"A longer description of the distribution that can run to several " +"paragraphs. Software that deals with metadata should not assume any maximum " +"size for this field, though people shouldn't include their instruction " +"manual as the description." msgstr "" #: ../source/specifications/core-metadata.rst:196 -msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." +msgid "" +"The contents of this field can be written using reStructuredText markup " +"[1]_. For programs that work with the metadata, supporting markup is " +"optional; programs can also display the contents of the field as-is. This " +"means that authors should be conservative in the markup they use." msgstr "" #: ../source/specifications/core-metadata.rst:202 -msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." +msgid "" +"To support empty lines and lines with indentation with respect to the RFC " +"822 format, any CRLF character has to be suffixed by 7 spaces followed by a " +"pipe (\"|\") char. As a result, the Description field is encoded into a " +"folded field that can be interpreted by RFC822 parser [2]_." msgstr "" #: ../source/specifications/core-metadata.rst:219 -msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." +msgid "" +"This encoding implies that any occurrences of a CRLF followed by 7 spaces " +"and a pipe char have to be replaced by a single CRLF when the field is " +"unfolded using a RFC822 reader." msgstr "" #: ../source/specifications/core-metadata.rst:223 -msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." +msgid "" +"Alternatively, the distribution's description may instead be provided in the " +"message body (i.e., after a completely blank line following the headers, " +"with no indentation or other special formatting necessary)." msgstr "" #: ../source/specifications/core-metadata.rst:232 @@ -6814,15 +9869,34 @@ msgid "Description-Content-Type" msgstr "" #: ../source/specifications/core-metadata.rst:236 -msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." +msgid "" +"A string stating the markup syntax (if any) used in the distribution's " +"description, so that tools can intelligently render the description." msgstr "" #: ../source/specifications/core-metadata.rst:239 -msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." +msgid "" +"Historically, PyPI supported descriptions in plain text and " +"`reStructuredText (reST) `_, and could render reST into HTML. However, it is " +"common for distribution authors to write the description in `Markdown " +"`_ (`RFC 7763 `_) as many code hosting sites render Markdown " +"READMEs, and authors would reuse the file for the description. PyPI didn't " +"recognize the format and so could not render the description correctly. This " +"resulted in many packages on PyPI with poorly-rendered descriptions when " +"Markdown is left as plain text, or worse, was attempted to be rendered as " +"reST. This field allows the distribution author to specify the format of " +"their description, opening up the possibility for PyPI and other tools to be " +"able to render Markdown and other formats." msgstr "" #: ../source/specifications/core-metadata.rst:253 -msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" +msgid "" +"The format of this field is the same as the ``Content-Type`` header in HTTP " +"(i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then " +"it can optionally have a number of parameters:" msgstr "" #: ../source/specifications/core-metadata.rst:259 @@ -6846,35 +9920,58 @@ msgid "``text/markdown``" msgstr "" #: ../source/specifications/core-metadata.rst:269 -msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." +msgid "" +"The ``charset`` parameter can be used to specify the character encoding of " +"the description. The only legal value is ``UTF-8``. If omitted, it is " +"assumed to be ``UTF-8``." msgstr "" #: ../source/specifications/core-metadata.rst:273 -msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" +msgid "" +"Other parameters might be specific to the chosen subtype. For example, for " +"the ``markdown`` subtype, there is an optional ``variant`` parameter that " +"allows specifying the variant of Markdown in use (defaults to ``GFM`` if not " +"specified). Currently, two variants are recognized:" msgstr "" #: ../source/specifications/core-metadata.rst:278 -msgid "``GFM`` for `Github-flavored Markdown `_" +msgid "" +"``GFM`` for `Github-flavored Markdown `_" msgstr "" #: ../source/specifications/core-metadata.rst:280 -msgid "``CommonMark`` for `CommonMark `_" +msgid "" +"``CommonMark`` for `CommonMark `_" msgstr "" #: ../source/specifications/core-metadata.rst:299 -msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." +msgid "" +"If a ``Description-Content-Type`` is not specified, then applications should " +"attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to " +"``text/plain`` if it is not valid rst." msgstr "" #: ../source/specifications/core-metadata.rst:303 -msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." +msgid "" +"If a ``Description-Content-Type`` is an unrecognized value, then the assumed " +"content type is ``text/plain`` (Although PyPI will probably reject anything " +"with an unrecognized value)." msgstr "" #: ../source/specifications/core-metadata.rst:307 -msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." +msgid "" +"If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is " +"not specified or is set to an unrecognized value, then the assumed " +"``variant`` is ``GFM``." msgstr "" #: ../source/specifications/core-metadata.rst:311 -msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." +msgid "" +"So for the last example above, the ``charset`` defaults to ``UTF-8`` and the " +"``variant`` defaults to ``GFM`` and thus it is equivalent to the example " +"before it." msgstr "" #: ../source/specifications/core-metadata.rst:320 @@ -6882,11 +9979,17 @@ msgid "Keywords" msgstr "" #: ../source/specifications/core-metadata.rst:324 -msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." +msgid "" +"A list of additional keywords, separated by commas, to be used to assist " +"searching for the distribution in a larger catalog." msgstr "" #: ../source/specifications/core-metadata.rst:333 -msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." +msgid "" +"The specification previously showed keywords separated by spaces, but " +"distutils and setuptools implemented it with commas. These tools have been " +"very widely used for many years, so it was easier to update the " +"specification to match the de facto standard." msgstr "" #: ../source/specifications/core-metadata.rst:341 @@ -6902,7 +10005,10 @@ msgid "Download-URL" msgstr "" #: ../source/specifications/core-metadata.rst:357 -msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" +msgid "" +"A string containing the URL from which this version of the distribution can " +"be downloaded. (This means that the URL can't be something like \".../" +"BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" msgstr "" #: ../source/specifications/core-metadata.rst:366 @@ -6910,7 +10016,9 @@ msgid "Author" msgstr "" #: ../source/specifications/core-metadata.rst:370 -msgid "A string containing the author's name at a minimum; additional contact information may be provided." +msgid "" +"A string containing the author's name at a minimum; additional contact " +"information may be provided." msgstr "" #: ../source/specifications/core-metadata.rst:383 @@ -6918,12 +10026,16 @@ msgid "Author-email" msgstr "" #: ../source/specifications/core-metadata.rst:387 -msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgid "" +"A string containing the author's e-mail address. It can contain a name and " +"e-mail address in the legal forms for a RFC-822 ``From:`` header." msgstr "" #: ../source/specifications/core-metadata.rst:395 #: ../source/specifications/core-metadata.rst:442 -msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" +msgid "" +"Per RFC-822, this field may contain multiple comma-separated e-mail " +"addresses::" msgstr "" #: ../source/specifications/core-metadata.rst:405 @@ -6931,11 +10043,16 @@ msgid "Maintainer" msgstr "" #: ../source/specifications/core-metadata.rst:409 -msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." +msgid "" +"A string containing the maintainer's name at a minimum; additional contact " +"information may be provided." msgstr "" #: ../source/specifications/core-metadata.rst:412 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." +msgid "" +"Note that this field is intended for use when a project is being maintained " +"by someone other than the original author: it should be omitted if it is " +"identical to ``Author``." msgstr "" #: ../source/specifications/core-metadata.rst:426 @@ -6943,11 +10060,16 @@ msgid "Maintainer-email" msgstr "" #: ../source/specifications/core-metadata.rst:430 -msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgid "" +"A string containing the maintainer's e-mail address. It can contain a name " +"and e-mail address in the legal forms for a RFC-822 ``From:`` header." msgstr "" #: ../source/specifications/core-metadata.rst:434 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." +msgid "" +"Note that this field is intended for use when a project is being maintained " +"by someone other than the original author: it should be omitted if it is " +"identical to ``Author-email``." msgstr "" #: ../source/specifications/core-metadata.rst:452 @@ -6955,7 +10077,13 @@ msgid "License" msgstr "" #: ../source/specifications/core-metadata.rst:456 -msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." +msgid "" +"Text indicating the license covering the distribution where the license is " +"not a selection from the \"License\" Trove classifiers. See :ref:`" +"\"Classifier\" ` below. This field may also be used to " +"specify a particular version of a license which is named via the " +"``Classifier`` field, or to indicate a variation or exception to such a " +"license." msgstr "" #: ../source/specifications/core-metadata.rst:476 @@ -6963,7 +10091,11 @@ msgid "Classifier (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:480 -msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." +msgid "" +"Each entry is a string giving a single classification value for the " +"distribution. Classifiers are described in :pep:`301`, and the Python " +"Package Index publishes a dynamic list of `currently defined classifiers " +"`__." msgstr "" #: ../source/specifications/core-metadata.rst:485 @@ -6981,11 +10113,15 @@ msgstr "" #: ../source/specifications/core-metadata.rst:561 #: ../source/specifications/core-metadata.rst:663 #: ../source/specifications/core-metadata.rst:704 -msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." +msgid "" +"The field format specification was relaxed to accept the syntax used by " +"popular publishing tools." msgstr "" #: ../source/specifications/core-metadata.rst:503 -msgid "Each entry contains a string naming some other distutils project required by this distribution." +msgid "" +"Each entry contains a string naming some other distutils project required by " +"this distribution." msgstr "" #: ../source/specifications/core-metadata.rst:506 @@ -6993,19 +10129,27 @@ msgid "The format of a requirement string contains from one to four parts:" msgstr "" #: ../source/specifications/core-metadata.rst:508 -msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." +msgid "" +"A project name, in the same format as the ``Name:`` field. The only " +"mandatory part." msgstr "" #: ../source/specifications/core-metadata.rst:510 -msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." +msgid "" +"A comma-separated list of 'extra' names. These are defined by the required " +"project, referring to specific features which may need extra dependencies." msgstr "" #: ../source/specifications/core-metadata.rst:513 -msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." +msgid "" +"A version specifier. Tools parsing the format should accept optional " +"parentheses around this, but tools generating it should not use parentheses." msgstr "" #: ../source/specifications/core-metadata.rst:516 -msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." +msgid "" +"An environment marker after a semicolon. This means that the requirement is " +"only needed in the specified conditions." msgstr "" #: ../source/specifications/core-metadata.rst:519 @@ -7013,11 +10157,15 @@ msgid "See :pep:`508` for full details of the allowed format." msgstr "" #: ../source/specifications/core-metadata.rst:521 -msgid "The project names should correspond to names as found on the `Python Package Index`_." +msgid "" +"The project names should correspond to names as found on the `Python Package " +"Index`_." msgstr "" #: ../source/specifications/core-metadata.rst:524 -msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." +msgid "" +"Version specifiers must follow the rules described in :doc:`version-" +"specifiers`." msgstr "" #: ../source/specifications/core-metadata.rst:538 @@ -7025,7 +10173,10 @@ msgid "Requires-Python" msgstr "" #: ../source/specifications/core-metadata.rst:542 -msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." +msgid "" +"This field specifies the Python version(s) that the distribution is " +"guaranteed to be compatible with. Installation tools may look at this when " +"picking which version of a project to install." msgstr "" #: ../source/specifications/core-metadata.rst:546 @@ -7041,15 +10192,25 @@ msgid "Requires-External (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:565 -msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." +msgid "" +"Each entry contains a string describing some dependency in the system that " +"the distribution is to be used. This field is intended to serve as a hint " +"to downstream project maintainers, and has no semantics which are meaningful " +"to the ``distutils`` distribution." msgstr "" #: ../source/specifications/core-metadata.rst:570 -msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." +msgid "" +"The format of a requirement string is a name of an external dependency, " +"optionally followed by a version declaration within parentheses." msgstr "" #: ../source/specifications/core-metadata.rst:576 -msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." +msgid "" +"Because they refer to non-Python software releases, version numbers for this " +"field are **not** required to conform to the format specified in :pep:" +"`440`: they should correspond to the version scheme used by the external " +"dependency." msgstr "" #: ../source/specifications/core-metadata.rst:581 @@ -7061,7 +10222,9 @@ msgid "Project-URL (multiple-use)" msgstr "" #: ../source/specifications/core-metadata.rst:597 -msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." +msgid "" +"A string containing a browsable URL for the project and a label for it, " +"separated by a comma." msgstr "" #: ../source/specifications/core-metadata.rst:604 @@ -7073,19 +10236,31 @@ msgid "Provides-Extra (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:616 -msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." +msgid "" +"A string containing the name of an optional feature. Must be a valid Python " +"identifier. May be used to make a dependency conditional on whether the " +"optional feature has been requested." msgstr "" #: ../source/specifications/core-metadata.rst:625 -msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." +msgid "" +"A second distribution requires an optional dependency by placing it inside " +"square brackets, and can request multiple features by separating them with a " +"comma (,). The requirements are evaluated for each requested feature and " +"added to the set of requirements for the distribution." msgstr "" #: ../source/specifications/core-metadata.rst:635 -msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." +msgid "" +"Two feature names ``test`` and ``doc`` are reserved to mark dependencies " +"that are needed for running automated tests and generating documentation, " +"respectively." msgstr "" #: ../source/specifications/core-metadata.rst:639 -msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." +msgid "" +"It is legal to specify ``Provides-Extra:`` without referencing it in any " +"``Requires-Dist:``." msgstr "" #: ../source/specifications/core-metadata.rst:644 @@ -7093,11 +10268,21 @@ msgid "Rarely Used Fields" msgstr "" #: ../source/specifications/core-metadata.rst:646 -msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." +msgid "" +"The fields in this section are currently rarely used, as their design was " +"inspired by comparable mechanisms in Linux package management systems, and " +"it isn't at all clear how tools should interpret them in the context of an " +"open index server such as `PyPI `__." msgstr "" #: ../source/specifications/core-metadata.rst:651 -msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." +msgid "" +"As a result, popular installation tools ignore them completely, which in " +"turn means there is little incentive for package publishers to set them " +"appropriately. However, they're retained in the metadata specification, as " +"they're still potentially useful for informational purposes, and can also be " +"used for their originally intended purpose in combination with a curated " +"package repository." msgstr "" #: ../source/specifications/core-metadata.rst:660 @@ -7105,19 +10290,37 @@ msgid "Provides-Dist (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:667 -msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." +msgid "" +"Each entry contains a string naming a Distutils project which is contained " +"within this distribution. This field *must* include the project identified " +"in the ``Name`` field, followed by the version : Name (Version)." msgstr "" #: ../source/specifications/core-metadata.rst:672 -msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." +msgid "" +"A distribution may provide additional names, e.g. to indicate that multiple " +"projects have been bundled together. For instance, source distributions of " +"the ``ZODB`` project have historically included the ``transaction`` project, " +"which is now available as a separate distribution. Installing such a source " +"distribution satisfies requirements for both ``ZODB`` and ``transaction``." msgstr "" #: ../source/specifications/core-metadata.rst:679 -msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." +msgid "" +"A distribution may also provide a \"virtual\" project name, which does not " +"correspond to any separately-distributed project: such a name might be used " +"to indicate an abstract capability which could be supplied by one of " +"multiple projects. E.g., multiple projects might supply RDBMS bindings for " +"use by a given ORM: each project might declare that it provides ``ORM-" +"bindings``, allowing other projects to depend only on having at most one of " +"them installed." msgstr "" #: ../source/specifications/core-metadata.rst:687 -msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." +msgid "" +"A version declaration may be supplied and must follow the rules described " +"in :doc:`version-specifiers`. The distribution's version number will be " +"implied if none is specified." msgstr "" #: ../source/specifications/core-metadata.rst:701 @@ -7125,15 +10328,23 @@ msgid "Obsoletes-Dist (multiple use)" msgstr "" #: ../source/specifications/core-metadata.rst:708 -msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." +msgid "" +"Each entry contains a string describing a distutils project's distribution " +"which this distribution renders obsolete, meaning that the two projects " +"should not be installed at the same time." msgstr "" #: ../source/specifications/core-metadata.rst:712 -msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." +msgid "" +"Version declarations can be supplied. Version numbers must be in the format " +"specified in :doc:`version-specifiers`." msgstr "" #: ../source/specifications/core-metadata.rst:717 -msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." +msgid "" +"The most common use of this field will be in case a project name changes, e." +"g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install " +"Torqued Python, the Gorgon distribution should be removed." msgstr "" #: ../source/specifications/core-metadata.rst:730 @@ -7149,7 +10360,11 @@ msgid "Declaring build system dependencies" msgstr "" #: ../source/specifications/declaring-build-dependencies.rst:8 -msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." +msgid "" +"`pyproject.toml` is a build system independent file format defined in :pep:" +"`518` that projects may provide in order to declare any Python level " +"dependencies that must be installed in order to run the project's build " +"system successfully." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:5 @@ -7157,15 +10372,31 @@ msgid "Declaring project metadata" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:7 -msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." +msgid "" +":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to " +"consume. It defines the following specification as the canonical source for " +"the format used." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:12 -msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." +msgid "" +"There are two kinds of metadata: *static* and *dynamic*. Static metadata is " +"specified in the ``pyproject.toml`` file directly and cannot be specified or " +"changed by a tool. Dynamic metadata is listed via the ``dynamic`` field " +"(defined later in this specification) and represents metadata that a tool " +"will later provide." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:18 -msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." +msgid "" +"The fields defined in this specification MUST be in a table named " +"``[project]`` in ``pyproject.toml``. No tools may add fields to this table " +"which are not defined by this specification. For tools wishing to store " +"their own settings in ``pyproject.toml``, they may use the ``[tool]`` table " +"as defined in the :ref:`build dependency declaration specification " +"`. The lack of a ``[project]`` table " +"implicitly means the build back-end will dynamically provide all fields." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:27 @@ -7178,7 +10409,9 @@ msgid "``name``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:31 -msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" +msgid "" +"The fields which are required but may be specified *either* statically or " +"listed as dynamic are:" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:34 @@ -7187,7 +10420,9 @@ msgid "``version``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:36 -msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." +msgid "" +"All other fields are considered optional and my be specified statically, " +"listed as dynamic, or left unspecified." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:43 @@ -7198,7 +10433,9 @@ msgid "TOML_ type: string" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:44 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Name `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:47 @@ -7206,11 +10443,15 @@ msgid "The name of the project." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:49 -msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." +msgid "" +"Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it " +"is read for internal consistency." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:57 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Version " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:60 @@ -7226,7 +10467,9 @@ msgid "``description``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:69 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Summary " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:72 @@ -7242,7 +10485,10 @@ msgid "TOML_ type: string or table" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:79 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Description " +"` and :ref:`Description-Content-Type `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:83 @@ -7250,15 +10496,38 @@ msgid "The full description of the project (i.e. the README)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:85 -msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." +msgid "" +"The field accepts either a string or a table. If it is a string then it is a " +"path relative to ``pyproject.toml`` to a text file containing the full " +"description. Tools MUST assume the file's encoding is UTF-8. If the file " +"path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the " +"content-type is ``text/markdown``. If the file path ends in a case-" +"insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-" +"rst``. If a tool recognizes more extensions than this PEP, they MAY infer " +"the content-type for the user without specifying this field as ``dynamic``. " +"For all unrecognized suffixes when a content-type is not provided, tools " +"MUST raise an error." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:96 -msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." +msgid "" +"The ``readme`` field may also take a table. The ``file`` key has a string " +"value representing a path relative to ``pyproject.toml`` to a file " +"containing the full description. The ``text`` key has a string value which " +"is the full description. These keys are mutually-exclusive, thus tools MUST " +"raise an error if the metadata specifies both keys." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:103 -msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." +msgid "" +"A table specified in the ``readme`` field also has a ``content-type`` field " +"which takes a string specifying the content-type of the full description. A " +"tool MUST raise an error if the metadata does not specify this field in the " +"table. If the metadata does not specify the ``charset`` parameter, then it " +"is assumed to be UTF-8. Tools MAY support other encodings if they choose to. " +"Tools MAY support alternative content-types which they can transform to a " +"content-type as supported by the :ref:`core metadata `. " +"Otherwise tools MUST raise an error for unsupported content-types." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:115 @@ -7266,7 +10535,9 @@ msgid "``requires-python``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:118 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Requires-" +"Python `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:121 @@ -7282,11 +10553,19 @@ msgid "TOML_ type: table" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:128 -msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`License " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:131 -msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." +msgid "" +"The table may have one of two keys. The ``file`` key has a string value that " +"is a file path relative to ``pyproject.toml`` to the file which contains the " +"license for the project. Tools MUST assume the file's encoding is UTF-8. The " +"``text`` key has a string value which is the license of the project. These " +"keys are mutually exclusive, so a tool MUST raise an error if the metadata " +"specifies both keys." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:140 @@ -7298,35 +10577,58 @@ msgid "TOML_ type: Array of inline tables with string keys and values" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:143 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:" +"`Maintainer `, and :ref:`Maintainer-email `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:149 -msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." +msgid "" +"The people or organizations considered to be the \"authors\" of the project. " +"The exact meaning is open to interpretation — it may list the original or " +"primary authors, current maintainers, or owners of the package." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:154 -msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." +msgid "" +"The \"maintainers\" field is similar to \"authors\" in that its exact " +"meaning is open to interpretation." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:157 -msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." +msgid "" +"These fields accept an array of tables with 2 keys: ``name`` and ``email``. " +"Both values must be strings. The ``name`` value MUST be a valid email name " +"(i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not " +"contain commas. The ``email`` value MUST be a valid email address. Both keys " +"are optional." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:163 -msgid "Using the data to fill in :ref:`core metadata ` is as follows:" +msgid "" +"Using the data to fill in :ref:`core metadata ` is as follows:" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:166 -msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." +msgid "" +"If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:169 -msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." +msgid "" +"If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:173 -msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." +msgid "" +"If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-" +"email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:177 @@ -7343,7 +10645,9 @@ msgid "TOML_ type: array of strings" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:184 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Keywords " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:187 @@ -7355,7 +10659,9 @@ msgid "``classifiers``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:194 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Classifier " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:197 @@ -7371,11 +10677,15 @@ msgid "TOML_ type: table with keys and values of strings" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:204 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Project-URL " +"`" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:207 -msgid "A table of URLs where the key is the URL label and the value is the URL itself." +msgid "" +"A table of URLs where the key is the URL label and the value is the URL " +"itself." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:212 @@ -7383,7 +10693,9 @@ msgid "Entry points" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:214 -msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" +msgid "" +"TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and " +"``[project.entry-points]``)" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:216 @@ -7391,19 +10703,34 @@ msgid ":ref:`Entry points specification `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:218 -msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." +msgid "" +"There are three tables related to entry points. The ``[project.scripts]`` " +"table corresponds to the ``console_scripts`` group in the :ref:`entry points " +"specification `. The key of the table is the name of the entry " +"point and the value is the object reference." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:224 -msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." +msgid "" +"The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group " +"in the :ref:`entry points specification `. Its format is the " +"same as ``[project.scripts]``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:228 -msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." +msgid "" +"The ``[project.entry-points]`` table is a collection of tables. Each sub-" +"table's name is an entry point group. The key and value semantics are the " +"same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but " +"instead keep the entry point groups to only one level deep." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:234 -msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." +msgid "" +"Build back-ends MUST raise an error if the metadata defines a ``[project." +"entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` " +"table, as they would be ambiguous in the face of ``[project.scripts]`` and " +"``[project.gui-scripts]``, respectively." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:242 @@ -7411,11 +10738,16 @@ msgid "``dependencies``/``optional-dependencies``" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:244 -msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" +msgid "" +"TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with " +"values of arrays of :pep:`508` strings (``optional-dependencies``)" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:247 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" +msgid "" +"Corresponding :ref:`core metadata ` field: :ref:`Requires-" +"Dist ` and :ref:`Provides-Extra `" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:251 @@ -7423,11 +10755,22 @@ msgid "The (optional) dependencies of the project." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:253 -msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." +msgid "" +"For ``dependencies``, it is a key whose value is an array of strings. Each " +"string represents a dependency of the project and MUST be formatted as a " +"valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist " +"` entry." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:258 -msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." +msgid "" +"For ``optional-dependencies``, it is a table where each key specifies an " +"extra and whose value is an array of strings. The strings of the arrays must " +"be valid :pep:`508` strings. The keys MUST be valid values for :ref:" +"`Provides-Extra `. Each value in the array " +"thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:269 @@ -7439,39 +10782,65 @@ msgid "TOML_ type: array of string" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:272 -msgid "A corresponding :ref:`core metadata ` field does not exist" +msgid "" +"A corresponding :ref:`core metadata ` field does not exist" msgstr "" #: ../source/specifications/declaring-project-metadata.rst:275 -msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." +msgid "" +"Specifies which fields listed by this PEP were intentionally unspecified so " +"another tool can/will provide such metadata dynamically. This clearly " +"delineates which metadata is purposefully unspecified and expected to stay " +"unspecified compared to being provided via tooling later on." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:281 -msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." +msgid "" +"A build back-end MUST honour statically-specified metadata (which means the " +"metadata did not list the field in ``dynamic``)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:283 -msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." +msgid "" +"A build back-end MUST raise an error if the metadata specifies ``name`` in " +"``dynamic``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:285 -msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." +msgid "" +"If the :ref:`core metadata ` specification lists a field as " +"\"Required\", then the metadata MUST specify the field statically or list it " +"in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it " +"should not be possible for a required field to not be listed somehow in the " +"``[project]`` table)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:290 -msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." +msgid "" +"If the :ref:`core metadata ` specification lists a field as " +"\"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is " +"a build back-end will provide the data for the field later." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:294 -msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." +msgid "" +"Build back-ends MUST raise an error if the metadata specifies a field " +"statically as well as being listed in ``dynamic``." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:296 -msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." +msgid "" +"If the metadata does not list a field in ``dynamic``, then a build back-end " +"CANNOT fill in the requisite metadata on behalf of the user (i.e. " +"``dynamic`` is the only way to allow a tool to fill in metadata and the user " +"must opt into the filling in)." msgstr "" #: ../source/specifications/declaring-project-metadata.rst:300 -msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." +msgid "" +"Build back-ends MUST raise an error if the metadata specifies a field in " +"``dynamic`` but the build back-end was unable to determine the data for it " +"(omitting the data, if determined to be the accurate value, is acceptable)." msgstr "" #: ../source/specifications/dependency-specifiers.rst:6 @@ -7479,11 +10848,15 @@ msgid "Dependency specifiers" msgstr "" #: ../source/specifications/dependency-specifiers.rst:8 -msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." +msgid "" +"The dependency specifier format used to declare a dependency on another " +"component is defined in :pep:`508`." msgstr "" #: ../source/specifications/dependency-specifiers.rst:11 -msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." +msgid "" +"The environment markers section in this PEP supersedes the environment " +"markers section in :pep:`345`." msgstr "" #: ../source/specifications/direct-url.rst:6 @@ -7491,7 +10864,11 @@ msgid "Recording the Direct URL Origin of installed distributions" msgstr "" #: ../source/specifications/direct-url.rst:8 -msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." +msgid "" +"This document specifies a :file:`direct_url.json` file in the :file:`*.dist-" +"info` directory of an installed distribution, to record the Direct URL " +"Origin of the distribution. The layout of this file was originally specified " +"in :pep:`610` and is formally documented here." msgstr "" #: ../source/specifications/direct-url.rst:17 @@ -7499,80 +10876,145 @@ msgid "Specification" msgstr "" #: ../source/specifications/direct-url.rst:19 -msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgid "" +"The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` " +"directory by installers when installing a distribution from a requirement " +"specifying a direct URL reference (including a VCS URL)." msgstr "" #: ../source/specifications/direct-url.rst:23 #: ../source/specifications/recording-installed-packages.rst:206 -msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." +msgid "" +"This file MUST NOT be created when installing a distribution from an other " +"type of requirement (i.e. name plus version specifier)." msgstr "" #: ../source/specifications/direct-url.rst:26 -msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." +msgid "" +"This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." msgstr "" #: ../source/specifications/direct-url.rst:29 -msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." +msgid "" +"If present, it MUST contain at least two fields. The first one is ``url``, " +"with type ``string``. Depending on what ``url`` refers to, the second field " +"MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), " +"``archive_info`` (if ``url`` is a source archives or a wheel), or " +"``dir_info`` (if ``url`` is a local directory). These info fields have a " +"(possibly empty) subdictionary as value, with the possible keys defined " +"below." msgstr "" #: ../source/specifications/direct-url.rst:36 -msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." +msgid "" +"``url`` MUST be stripped of any sensitive authentication information, for " +"security reasons." msgstr "" #: ../source/specifications/direct-url.rst:39 -msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" +msgid "" +"The user:password section of the URL MAY however be composed of environment " +"variables, matching the following regular expression::" msgstr "" #: ../source/specifications/direct-url.rst:45 -msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." +msgid "" +"Additionally, the user:password section of the URL MAY be a well-known, non " +"security sensitive string. A typical example is ``git`` in the case of an " +"URL such as ``ssh://git@gitlab.com/user/repo``." msgstr "" #: ../source/specifications/direct-url.rst:49 -msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" +msgid "" +"When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be " +"present as a dictionary with the following keys:" msgstr "" #: ../source/specifications/direct-url.rst:52 -msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." +msgid "" +"A ``vcs`` key (type ``string``) MUST be present, containing the name of the " +"VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be " +"registered by writing a PEP to amend this specification. The ``url`` value " +"MUST be compatible with the corresponding VCS, so an installer can hand it " +"off without transformation to a checkout/download command of the VCS." msgstr "" #: ../source/specifications/direct-url.rst:58 -msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." +msgid "" +"A ``requested_revision`` key (type ``string``) MAY be present naming a " +"branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to " +"install." msgstr "" #: ../source/specifications/direct-url.rst:61 -msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." +msgid "" +"A ``commit_id`` key (type ``string``) MUST be present, containing the exact " +"commit/revision number that was installed. If the VCS supports commit-hash " +"based revision identifiers, such commit-hash MUST be used as ``commit_id`` " +"in order to reference the immutable version of the source code that was " +"installed." msgstr "" #: ../source/specifications/direct-url.rst:68 -msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" +msgid "" +"When ``url`` refers to a source archive or a wheel, the ``archive_info`` key " +"MUST be present as a dictionary with the following key:" msgstr "" #: ../source/specifications/direct-url.rst:71 -msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." +msgid "" +"A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are " +"unconditionally provided by the latest version of the standard library's " +"``hashlib`` module be used for source archive hashes. At time of writing, " +"that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and " +"'sha512'." msgstr "" #: ../source/specifications/direct-url.rst:78 -msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" +msgid "" +"When ``url`` refers to a local directory, the ``dir_info`` key MUST be " +"present as a dictionary with the following key:" msgstr "" #: ../source/specifications/direct-url.rst:81 -msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." +msgid "" +"``editable`` (type: ``boolean``): ``true`` if the distribution was installed " +"in editable mode, ``false`` otherwise. If absent, default to ``false``." msgstr "" #: ../source/specifications/direct-url.rst:84 -msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." +msgid "" +"When ``url`` refers to a local directory, it MUST have the ``file`` sheme " +"and be compliant with `RFC 8089 `_. In " +"particular, the path component must be absolute. Symbolic links SHOULD be " +"preserved when making relative paths absolute." msgstr "" #: ../source/specifications/direct-url.rst:91 -msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." +msgid "" +"When the requested URL has the file:// scheme and points to a local " +"directory that happens to contain a VCS checkout, installers MUST NOT " +"attempt to infer any VCS information and therefore MUST NOT output any VCS " +"related information (such as ``vcs_info``) in :file:`direct_url.json`." msgstr "" #: ../source/specifications/direct-url.rst:96 -msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." +msgid "" +"A top-level ``subdirectory`` field MAY be present containing a directory " +"path, relative to the root of the VCS repository, source archive or local " +"directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." msgstr "" #: ../source/specifications/direct-url.rst:102 -msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." +msgid "" +"As a general rule, installers should as much as possible preserve the " +"information that was provided in the requested URL when generating :file:" +"`direct_url.json`. For example user:password environment variables should be " +"preserved and ``requested_revision`` should reflect the revision that was " +"provided in the requested URL as faithfully as possible. This information is " +"however *enriched* with more precise data, such as ``commit_id``." msgstr "" #: ../source/specifications/direct-url.rst:110 @@ -7580,7 +11022,14 @@ msgid "Registered VCS" msgstr "" #: ../source/specifications/direct-url.rst:112 -msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." +msgid "" +"This section lists the registered VCS's; expanded, VCS-specific information " +"on how to use the ``vcs``, ``requested_revision``, and other fields of " +"``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY " +"support other VCS's although it is RECOMMENDED to register them by writing a " +"PEP to amend this specification. The ``vcs`` field SHOULD be the command " +"name (lowercased). Additional fields that would be necessary to support such " +"VCS SHOULD be prefixed with the VCS command name." msgstr "" #: ../source/specifications/direct-url.rst:122 @@ -7625,7 +11074,9 @@ msgid "``requested_revision`` field" msgstr "" #: ../source/specifications/direct-url.rst:138 -msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." +msgid "" +"A tag name, branch name, Git ref, commit hash, shortened commit hash, or " +"other commit-ish." msgstr "" #: ../source/specifications/direct-url.rst:141 @@ -7640,7 +11091,11 @@ msgid "A commit hash (40 hexadecimal characters sha1)." msgstr "" #: ../source/specifications/direct-url.rst:147 -msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." +msgid "" +"Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to " +"determine if the ``requested_revision`` corresponds to a Git ref. In turn, a " +"ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning " +"with ``refs/remotes/origin/`` after cloning corresponds to a branch." msgstr "" #: ../source/specifications/direct-url.rst:154 @@ -7699,11 +11154,15 @@ msgid "svn" msgstr "" #: ../source/specifications/direct-url.rst:216 -msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." +msgid "" +"``requested_revision`` must be compatible with ``svn checkout`` ``--" +"revision`` option. In Subversion, branch or tag is part of ``url``." msgstr "" #: ../source/specifications/direct-url.rst:221 -msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." +msgid "" +"Since Subversion does not support globally unique identifiers, this field is " +"the Subversion revision number in the corresponding repository." msgstr "" #: ../source/specifications/direct-url.rst:229 @@ -7743,7 +11202,9 @@ msgid "pip install https://example.com/app-1.0.whl" msgstr "" #: ../source/specifications/direct-url.rst:283 -msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" +msgid "" +"pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup" +"\"" msgstr "" #: ../source/specifications/direct-url.rst:284 @@ -7755,7 +11216,11 @@ msgid "pip install file:///home/user/app" msgstr "" #: ../source/specifications/direct-url.rst:286 -msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" +msgid "" +"pip install --editable \"git+https://example.com/repo/app." +"git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local " +"directory where the git repository has been cloned to, and ``dir_info`` will " +"be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" msgstr "" #: ../source/specifications/direct-url.rst:290 @@ -7779,19 +11244,37 @@ msgid "Entry points specification" msgstr "" #: ../source/specifications/entry-points.rst:7 -msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" +msgid "" +"*Entry points* are a mechanism for an installed distribution to advertise " +"components it provides to be discovered and used by other code. For example:" msgstr "" #: ../source/specifications/entry-points.rst:11 -msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." +msgid "" +"Distributions can specify ``console_scripts`` entry points, each referring " +"to a function. When *pip* (or another console_scripts aware installer) " +"installs the distribution, it will create a command-line wrapper for each " +"entry point." msgstr "" #: ../source/specifications/entry-points.rst:14 -msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." +msgid "" +"Applications can use entry points to load plugins; e.g. Pygments (a syntax " +"highlighting tool) can use additional lexers and styles from separately " +"installed packages. For more about this, see :doc:`/guides/creating-and-" +"discovering-plugins`." msgstr "" #: ../source/specifications/entry-points.rst:19 -msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." +msgid "" +"The entry point file format was originally developed to allow packages built " +"with setuptools to provide integration point metadata that would be read at " +"runtime with ``importlib.metadata``. It is now defined as a PyPA " +"interoperability specification in order to allow build tools other than " +"setuptools to publish ``importlib.metadata`` compatible entry point " +"metadata, and runtime libraries other than ``importlib.metadata`` to " +"portably read published entry point metadata (potentially with different " +"caching and conflict resolution strategies)." msgstr "" #: ../source/specifications/entry-points.rst:28 @@ -7803,27 +11286,61 @@ msgid "Conceptually, an entry point is defined by three required properties:" msgstr "" #: ../source/specifications/entry-points.rst:32 -msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." +msgid "" +"The **group** that an entry point belongs to indicates what sort of object " +"it provides. For instance, the group ``console_scripts`` is for entry points " +"referring to functions which can be used as a command, while ``pygments." +"styles`` is the group for classes defining pygments styles. The consumer " +"typically defines the expected interface. To avoid clashes, consumers " +"defining a new group should use names starting with a PyPI name owned by the " +"consumer project, followed by ``.``. Group names must be one or more groups " +"of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w" +"+)*$``)." msgstr "" #: ../source/specifications/entry-points.rst:42 -msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." +msgid "" +"The **name** identifies this entry point within its group. The precise " +"meaning of this is up to the consumer. For console scripts, the name of the " +"entry point is the command that will be used to launch it. Within a " +"distribution, entry point names should be unique. If different distributions " +"provide the same name, the consumer decides how to handle such conflicts. " +"The name may contain any characters except ``=``, but it cannot start or end " +"with any whitespace character, or start with ``[``. For new entry points, it " +"is recommended to use only letters, numbers, underscores, dots and dashes " +"(regex ``[\\w.-]+``)." msgstr "" #: ../source/specifications/entry-points.rst:51 -msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" +msgid "" +"The **object reference** points to a Python object. It is either in the form " +"``importable.module``, or ``importable.module:object.attr``. Each of the " +"parts delimited by dots and the colon is a valid Python identifier. It is " +"intended to be looked up like this::" msgstr "" #: ../source/specifications/entry-points.rst:64 -msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." +msgid "" +"Some tools call this kind of object reference by itself an 'entry point', " +"for want of a better term, especially where it points to a function to " +"launch a program." msgstr "" #: ../source/specifications/entry-points.rst:68 -msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." +msgid "" +"There is also an optional property: the **extras** are a set of strings " +"identifying optional features of the distribution providing the entry point. " +"If these are specified, the entry point requires the dependencies of those " +"'extras'. See the metadata field :ref:`metadata_provides_extra`." msgstr "" #: ../source/specifications/entry-points.rst:73 -msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." +msgid "" +"Using extras for an entry point is no longer recommended. Consumers should " +"support parsing them from existing distributions, but may then ignore them. " +"New publishing tools need not support specifying extras. The functionality " +"of handling extras was tied to setuptools' model of managing 'egg' packages, " +"but newer tools such as pip and virtualenv use a different model." msgstr "" #: ../source/specifications/entry-points.rst:80 @@ -7831,23 +11348,44 @@ msgid "File format" msgstr "" #: ../source/specifications/entry-points.rst:82 -msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." +msgid "" +"Entry points are defined in a file called :file:`entry_points.txt` in the :" +"file:`*.dist-info` directory of the distribution. This is the directory " +"described in :pep:`376` for installed distributions, and in :pep:`427` for " +"wheels. The file uses the UTF-8 character encoding." msgstr "" #: ../source/specifications/entry-points.rst:87 -msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" +msgid "" +"The file contents are in INI format, as read by Python's :mod:`configparser` " +"module. However, configparser treats names as case-insensitive by default, " +"whereas entry point names are case sensitive. A case-sensitive config parser " +"can be made like this::" msgstr "" #: ../source/specifications/entry-points.rst:97 -msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." +msgid "" +"The entry points file must always use ``=`` to delimit names from values " +"(whereas configparser also allows using ``:``)." msgstr "" #: ../source/specifications/entry-points.rst:100 -msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." +msgid "" +"The sections of the config file represent entry point groups, the names are " +"names, and the values encode both the object reference and the optional " +"extras. If extras are used, they are a comma-separated list inside square " +"brackets." msgstr "" #: ../source/specifications/entry-points.rst:104 -msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." +msgid "" +"Within a value, readers must accept and ignore spaces (including multiple " +"consecutive spaces) before or after the colon, between the object reference " +"and the left square bracket, between the extra names and the square brackets " +"and colons delimiting them, and after the right square bracket. The syntax " +"for extras is formally specified as part of :pep:`508` (as ``extras``). For " +"tools writing the file, it is recommended only to insert a space between the " +"object reference and the left square bracket." msgstr "" #: ../source/specifications/entry-points.rst:112 @@ -7859,23 +11397,47 @@ msgid "Use for scripts" msgstr "" #: ../source/specifications/entry-points.rst:126 -msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." +msgid "" +"Two groups of entry points have special significance in packaging: " +"``console_scripts`` and ``gui_scripts``. In both groups, the name of the " +"entry point should be usable as a command in a system shell after the " +"package is installed. The object reference points to a function which will " +"be called with no arguments when this command is run. The function may " +"return an integer to be used as a process exit code, and returning ``None`` " +"is equivalent to returning ``0``." msgstr "" #: ../source/specifications/entry-points.rst:134 -msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" +msgid "" +"For instance, the entry point ``mycmd = mymod:main`` would create a command " +"``mycmd`` launching a script like this::" msgstr "" #: ../source/specifications/entry-points.rst:141 -msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." +msgid "" +"The difference between ``console_scripts`` and ``gui_scripts`` only affects " +"Windows systems. ``console_scripts`` are wrapped in a console executable, so " +"they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and " +"``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI " +"executable, so they can be started without a console, but cannot use " +"standard streams unless application code redirects them. Other platforms do " +"not have the same distinction." msgstr "" #: ../source/specifications/entry-points.rst:149 -msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." +msgid "" +"Install tools are expected to set up wrappers for both ``console_scripts`` " +"and ``gui_scripts`` in the scripts directory of the install scheme. They are " +"not responsible for putting this directory in the ``PATH`` environment " +"variable which defines where command-line tools are found." msgstr "" #: ../source/specifications/entry-points.rst:154 -msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." +msgid "" +"As files are created from the names, and some filesystems are case-" +"insensitive, packages should avoid using names in these groups which differ " +"only in case. The behaviour of install tools when names differ only in case " +"is undefined." msgstr "" #: ../source/specifications/index.rst:4 @@ -7883,7 +11445,11 @@ msgid "PyPA specifications" msgstr "" #: ../source/specifications/index.rst:6 -msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." +msgid "" +"This is a list of currently active interoperability specifications " +"maintained by the Python Packaging Authority. The process for updating these " +"standards, and for proposing new ones, is documented on `pypa.io `__." msgstr "" #: ../source/specifications/index.rst:13 @@ -7903,11 +11469,16 @@ msgid "Platform compatibility tags" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:8 -msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." +msgid "" +"Platform compatibility tags allow build tools to mark distributions as being " +"compatible with specific platforms, and allows installers to understand " +"which distributions are compatible with the system they are running on." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:12 -msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." +msgid "" +"The platform compatibility tagging model used for the ``wheel`` distribution " +"format is defined in :pep:`425`." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:16 @@ -7915,7 +11486,9 @@ msgid "Platform tags for Windows" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:18 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." +msgid "" +"The scheme defined in :pep:`425` covers public distribution of wheel files " +"to systems running Windows." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:22 @@ -7923,7 +11496,9 @@ msgid "Platform tags for macOS (Mac OS X)" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:24 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." +msgid "" +"The scheme defined in :pep:`425` covers public distribution of wheel files " +"to systems running macOS (previously known as Mac OS X)." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:28 @@ -7931,39 +11506,70 @@ msgid "Platform tags for common Linux distributions" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:32 -msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." +msgid "" +"The scheme defined in :pep:`425` is insufficient for public distribution of " +"wheel files (and \\*nix wheel files in general) to Linux platforms, due to " +"the large ecosystem of Linux platforms and subtle differences between them." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:36 -msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." +msgid "" +"Instead, :pep:`600` defines the ``manylinux`` standard, which represents a " +"common subset of Linux platforms, and allows building wheels tagged with the " +"``manylinux`` platform tag which can be used across most common Linux " +"distributions." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:41 -msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" +msgid "" +"There were multiple iterations of the ``manylinux`` specification, each " +"representing the common subset of Linux platforms at a given point in time:" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:44 -msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." +msgid "" +"``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, " +"and is based on a compatible Linux platform from 2007." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:46 -msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." +msgid "" +"``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` " +"architectures. and updates the previous specification to be based on a " +"compatible Linux platform from 2010 instead." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:49 -msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." +msgid "" +"``manylinux2014`` (:pep:`599`) adds support for a number of additional " +"architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and " +"``s390x``) and updates the base platform to a compatible Linux platform from " +"2014." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:54 -msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." +msgid "" +"``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a " +"future-proof standard. It defines ``x`` and ``y`` as glibc major an minor " +"versions supported (e.g. ``manylinux_2_24`` should work on any distro using " +"glibc 2.24+). Previous tags are still supported for backward compatibility." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:59 -msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." +msgid "" +"In general, distributions built for older versions of the specification are " +"forwards-compatible (meaning that ``manylinux1`` distributions should " +"continue to work on modern systems) but not backwards-compatible (meaning " +"that ``manylinux2010`` distributions are not expected to work on platforms " +"that existed before 2010)." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:65 -msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." +msgid "" +"Package maintainers should attempt to target the most compatible " +"specification possible, with the caveat that the provided build environment " +"for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning " +"that these images will no longer receive security updates." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:71 @@ -7971,15 +11577,21 @@ msgid "Manylinux compatibility support" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:74 -msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." +msgid "" +"The ``manylinux2014`` specification is relatively new and is not yet widely " +"recognised by install tools." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:76 -msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." +msgid "" +"The ``manylinux_x_y`` specification is relatively new and is not yet widely " +"recognised by install tools." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:79 -msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" +msgid "" +"The following table shows the minimum versions of relevant projects to " +"support the various ``manylinux`` standards:" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:83 @@ -8043,7 +11655,11 @@ msgid "Platform tags for other \\*nix platforms" msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:92 -msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." +msgid "" +"The scheme defined in :pep:`425` is not generally sufficient for public " +"distribution of wheel files to other \\*nix platforms. Efforts are currently " +"(albeit intermittently) under way to define improved compatibility tagging " +"schemes for AIX and for Alpine Linux." msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:98 @@ -8055,7 +11671,11 @@ msgid "The :file:`.pypirc` file" msgstr "" #: ../source/specifications/pypirc.rst:8 -msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." +msgid "" +"A :file:`.pypirc` file allows you to define the configuration for :term:" +"`package indexes ` (referred to here as \"repositories\"), so " +"that you don't have to enter the URL, username, or password whenever you " +"upload a package with :ref:`twine` or :ref:`flit`." msgstr "" #: ../source/specifications/pypirc.rst:13 @@ -8063,7 +11683,9 @@ msgid "The format (originally defined by the :ref:`distutils` package) is:" msgstr "" #: ../source/specifications/pypirc.rst:32 -msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." +msgid "" +"The ``distutils`` section defines an ``index-servers`` field that lists the " +"name of all sections describing a repository." msgstr "" #: ../source/specifications/pypirc.rst:35 @@ -8083,11 +11705,16 @@ msgid "``password``: The password that will used to authenticate the username." msgstr "" #: ../source/specifications/pypirc.rst:43 -msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." +msgid "" +"Be aware that this stores your password in plain text. For better security, " +"consider an alternative like `keyring`_, setting environment variables, or " +"providing the password on the command line." msgstr "" #: ../source/specifications/pypirc.rst:47 -msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" +msgid "" +"Otherwise, set the permissions on :file:`.pypirc` so that only you can view " +"or modify it. For example, on Linux or macOS, run:" msgstr "" #: ../source/specifications/pypirc.rst:57 @@ -8095,15 +11722,23 @@ msgid "Common configurations" msgstr "" #: ../source/specifications/pypirc.rst:61 -msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." +msgid "" +"These examples apply to :ref:`twine`, and projects like :ref:`hatch` that " +"use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`." +"pypirc`, but with different defaults. Please refer to each project's " +"documentation for more details and usage instructions." msgstr "" #: ../source/specifications/pypirc.rst:66 -msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" +msgid "" +"Twine's default configuration mimics a :file:`.pypirc` with repository " +"sections for PyPI and TestPyPI:" msgstr "" #: ../source/specifications/pypirc.rst:82 -msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." +msgid "" +"Twine will add additional configuration from :file:`$HOME/.pypirc`, the " +"command line, and environment variables to this default configuration." msgstr "" #: ../source/specifications/pypirc.rst:86 @@ -8111,11 +11746,15 @@ msgid "Using a PyPI token" msgstr "" #: ../source/specifications/pypirc.rst:88 -msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" +msgid "" +"To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` " +"similar to:" msgstr "" #: ../source/specifications/pypirc.rst:97 -msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." +msgid "" +"For :ref:`TestPyPI `, add a ``[testpypi]`` section, using " +"the API token from your TestPyPI account." msgstr "" #: ../source/specifications/pypirc.rst:103 @@ -8123,11 +11762,16 @@ msgid "Using another package index" msgstr "" #: ../source/specifications/pypirc.rst:105 -msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" +msgid "" +"To configure an additional repository, you'll need to redefine the ``index-" +"servers`` field to include the repository name. Here is a complete example " +"of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" msgstr "" #: ../source/specifications/pypirc.rst:132 -msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" +msgid "" +"Instead of using the ``password`` field, consider saving your API tokens and " +"passwords securely using `keyring`_ (which is installed by Twine):" msgstr "" #: ../source/specifications/recording-installed-packages.rst:5 @@ -8135,11 +11779,20 @@ msgid "Recording installed projects" msgstr "" #: ../source/specifications/recording-installed-packages.rst:7 -msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." +msgid "" +"This document specifies a common format of recording information about " +"Python :term:`projects ` installed in an environment. A common " +"metadata format allows tools to query, manage or uninstall projects, " +"regardless of how they were installed." msgstr "" #: ../source/specifications/recording-installed-packages.rst:12 -msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." +msgid "" +"Almost all information is optional. This allows tools outside the Python " +"ecosystem, such as Linux package managers, to integrate with Python tooling " +"as much as possible. For example, even if an installer cannot easily provide " +"a list of installed files in a format specific to Python tooling, it should " +"still record the name and version of the installed project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:21 @@ -8147,31 +11800,65 @@ msgid "History and change workflow" msgstr "" #: ../source/specifications/recording-installed-packages.rst:23 -msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." +msgid "" +"The metadata described here was first specified in :pep:`376`, and later " +"amended in :pep:`627`. It was formerly known as *Database of Installed " +"Python Distributions*. Further amendments (except trivial language or " +"typography fixes) must be made through the PEP process (see :pep:`1`)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:29 -msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." +msgid "" +"While this document is the normative specification, these PEPs that " +"introduce changes to it may include additional information such as " +"rationales and backwards compatibility considerations." msgstr "" #: ../source/specifications/recording-installed-packages.rst:37 -msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." +msgid "" +"Each project installed from a distribution must, in addition to files, " +"install a \"``.dist-info``\" directory located alongside importable modules " +"and packages (commonly, the ``site-packages`` directory)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:41 -msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." +msgid "" +"This directory is named as ``{name}-{version}.dist-info``, with ``name`` and " +"``version`` fields corresponding to :ref:`core-metadata`. Both fields must " +"be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 " +"<440#normalization>` for the definition of normalization for each field " +"respectively), and replace dash (``-``) characters with underscore (``_``) " +"chacaters, so the ``.dist-info`` directory always has exactly one dash (``-" +"``) character in its stem, separating the ``name`` and ``version`` fields." msgstr "" #: ../source/specifications/recording-installed-packages.rst:50 -msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." +msgid "" +"Historically, tools have failed to replace dot characters or normalize case " +"in the ``name`` field, or not perform normalization in the ``version`` " +"field. Tools consuming ``.dist-info`` directories should expect those fields " +"to be unnormalized, and treat them as equivalent to their normalized " +"counterparts. New tools that write ``.dist-info`` directories MUST normalize " +"both ``name`` and ``version`` fields using the rules described above, and " +"existing tools are encouraged to start normalizing those fields." msgstr "" #: ../source/specifications/recording-installed-packages.rst:60 -msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." +msgid "" +"The ``.dist-info`` directory's name is formatted to unambigiously represent " +"a distribution as a filesystem path. Tools presenting a distribution name to " +"a user should avoid using the normalized name, and instead present the " +"specified name (when needed prior to resolution to an installed package), or " +"read the respective fields in Core Metadata, since values listed there are " +"unescaped and accurately reflect the distribution. Libraries should provide " +"API for such tools to consume, so tools can have access to the unnormalized " +"name when displaying distrubution information." msgstr "" #: ../source/specifications/recording-installed-packages.rst:69 -msgid "This ``.dist-info`` directory can contain these files, described in detail below:" +msgid "" +"This ``.dist-info`` directory can contain these files, described in detail " +"below:" msgstr "" #: ../source/specifications/recording-installed-packages.rst:72 @@ -8183,19 +11870,31 @@ msgid "``RECORD``: records the list of installed files." msgstr "" #: ../source/specifications/recording-installed-packages.rst:74 -msgid "``INSTALLER``: records the name of the tool used to install the project." +msgid "" +"``INSTALLER``: records the name of the tool used to install the project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:76 -msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." +msgid "" +"The ``METADATA`` file is mandatory. All other files may be omitted at the " +"installing tool's discretion. Additional installer-specific files may be " +"present." msgstr "" #: ../source/specifications/recording-installed-packages.rst:82 -msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." +msgid "" +"The :ref:`binary-distribution-format` specification describes additional " +"files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. " +"Such files may be copied to the ``.dist-info`` directory of an installed " +"project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:87 -msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." +msgid "" +"The previous versions of this specification also specified a ``REQUESTED`` " +"file. This file is now considered a tool-specific extension, but may be " +"standardized again in the future. See `PEP 376 `_ for its original meaning." msgstr "" #: ../source/specifications/recording-installed-packages.rst:94 @@ -8203,11 +11902,16 @@ msgid "The METADATA file" msgstr "" #: ../source/specifications/recording-installed-packages.rst:96 -msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." +msgid "" +"The ``METADATA`` file contains metadata as described in the :ref:`core-" +"metadata` specification, version 1.1 or greater." msgstr "" #: ../source/specifications/recording-installed-packages.rst:99 -msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." +msgid "" +"The ``METADATA`` file is mandatory. If it cannot be created, or if required " +"core metadata is not available, installers must report an error and fail to " +"install the project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:105 @@ -8215,11 +11919,15 @@ msgid "The RECORD file" msgstr "" #: ../source/specifications/recording-installed-packages.rst:107 -msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." +msgid "" +"The ``RECORD`` file holds the list of installed files. It is a CSV file " +"containing one record (line) per installed file." msgstr "" #: ../source/specifications/recording-installed-packages.rst:110 -msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" +msgid "" +"The CSV dialect must be readable with the default ``reader`` of Python's " +"``csv`` module:" msgstr "" #: ../source/specifications/recording-installed-packages.rst:113 @@ -8235,31 +11943,56 @@ msgid "line terminator: either ``\\r\\n`` or ``\\n``." msgstr "" #: ../source/specifications/recording-installed-packages.rst:117 -msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." +msgid "" +"Each record is composed of three elements: the file's **path**, the **hash** " +"of the contents, and its **size**." msgstr "" #: ../source/specifications/recording-installed-packages.rst:120 -msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." +msgid "" +"The *path* may be either absolute, or relative to the directory containing " +"the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On " +"Windows, directories may be separated either by forward- or backslashes (``/" +"`` or ``\\``)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:125 -msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." +msgid "" +"The *hash* is either an empty string or the name of a hash algorithm from " +"``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` " +"and the digest of the file's contents, encoded with the urlsafe-base64-nopad " +"encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:130 -msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." +msgid "" +"The *size* is either the empty string, or file's size in bytes, as a base 10 " +"integer." msgstr "" #: ../source/specifications/recording-installed-packages.rst:133 -msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." +msgid "" +"For any file, either or both of the *hash* and *size* fields may be left " +"empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself " +"have empty *hash* and *size*. For other files, leaving the information out " +"is discouraged, as it prevents verifying the integrity of the installed " +"project." msgstr "" #: ../source/specifications/recording-installed-packages.rst:139 -msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." +msgid "" +"If the ``RECORD`` file is present, it must list all installed files of the " +"project, except ``.pyc`` files corresponding to ``.py`` files listed in " +"``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` " +"directory (including the ``RECORD`` file itself) must be listed. Directories " +"should not be listed." msgstr "" #: ../source/specifications/recording-installed-packages.rst:146 -msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." +msgid "" +"To completely uninstall a package, a tool needs to remove all files listed " +"in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding " +"to removed ``.py`` files, and any directories emptied by the uninstallation." msgstr "" #: ../source/specifications/recording-installed-packages.rst:151 @@ -8267,7 +12000,11 @@ msgid "Here is an example snippet of a possible ``RECORD`` file::" msgstr "" #: ../source/specifications/recording-installed-packages.rst:170 -msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" +msgid "" +"If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must " +"not atempt to uninstall or upgrade the package. (This does not apply to " +"tools that rely on other sources of information, such as system package " +"managers in Linux distros.)" msgstr "" #: ../source/specifications/recording-installed-packages.rst:177 @@ -8275,7 +12012,11 @@ msgid "The INSTALLER file" msgstr "" #: ../source/specifications/recording-installed-packages.rst:179 -msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." +msgid "" +"If present, ``INSTALLER`` is a single-line text file naming the tool used to " +"install the project. If the installer is executable from the command line, " +"``INSTALLER`` should contain the command name. Otherwise, it should contain " +"a printable ASCII string." msgstr "" #: ../source/specifications/recording-installed-packages.rst:185 @@ -8287,7 +12028,11 @@ msgid "Here are examples of two possible ``INSTALLER`` files::" msgstr "" #: ../source/specifications/recording-installed-packages.rst:195 -msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." +msgid "" +"This value should be used for informational purposes only. For example, if a " +"tool is asked to uninstall a project but finds no ``RECORD`` file, it may " +"suggest that the tool named in ``INSTALLER`` may be able to do the " +"uninstallation." msgstr "" #: ../source/specifications/recording-installed-packages.rst:201 @@ -8295,7 +12040,9 @@ msgid "The direct_url.json file" msgstr "" #: ../source/specifications/recording-installed-packages.rst:203 -msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgid "" +"This file MUST be created by installers when installing a distribution from " +"a requirement specifying a direct URL reference (including a VCS URL)." msgstr "" #: ../source/specifications/recording-installed-packages.rst:209 @@ -8307,7 +12054,12 @@ msgid "Simple repository API" msgstr "" #: ../source/specifications/simple-repository-api.rst:8 -msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." +msgid "" +"The current interface for querying available package versions and retrieving " +"packages from an index server is defined in :pep:`503`, with the addition of " +"\"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` " +"and specifying the interface version provided by an index server in :pep:" +"`629`." msgstr "" #: ../source/specifications/source-distribution-format.rst:6 @@ -8315,11 +12067,22 @@ msgid "Source distribution format" msgstr "" #: ../source/specifications/source-distribution-format.rst:8 -msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." +msgid "" +"The current standard format of source distribution format is identified by " +"the presence of a :file:`pyproject.toml` file in the distribution archive. " +"The layout of such a distribution was originally specified in :pep:`517` and " +"is formally documented here." msgstr "" #: ../source/specifications/source-distribution-format.rst:13 -msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." +msgid "" +"There is also the legacy source distribution format, implicitly defined by " +"the behaviour of ``distutils`` module in the standard library, when " +"executing :command:`setup.py sdist`. This document does not attempt to " +"standardise this format, except to note that if a legacy source distribution " +"contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it " +"MUST follow the rules applicable to source distributions defined in the " +"metadata specification." msgstr "" #: ../source/specifications/source-distribution-format.rst:21 @@ -8331,11 +12094,18 @@ msgid "Source distribution file name" msgstr "" #: ../source/specifications/source-distribution-format.rst:26 -msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." +msgid "" +"The file name of a sdist is not currently standardised, although the *de " +"facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the " +"canonicalized form of the project name (see :pep:`503` for the " +"canonicalization rules) with ``-`` characters replaced with ``_``, and " +"``{version}`` is the project version." msgstr "" #: ../source/specifications/source-distribution-format.rst:31 -msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." +msgid "" +"The name and version components of the filename MUST match the values stored " +"in the metadata contained in the file." msgstr "" #: ../source/specifications/source-distribution-format.rst:35 @@ -8343,15 +12113,27 @@ msgid "Source distribution file format" msgstr "" #: ../source/specifications/source-distribution-format.rst:37 -msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." +msgid "" +"A ``.tar.gz`` source distribution (sdist) contains a single top-level " +"directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the " +"source files of the package. The name and version MUST match the metadata " +"stored in the file. This directory must also contain a :file:`pyproject." +"toml` in the format defined in :ref:`declaring-build-dependencies`, and a " +"``PKG-INFO`` file containing metadata in the format described in the :ref:" +"`core-metadata` specification. The metadata MUST conform to at least version " +"2.2 of the metadata specification." msgstr "" #: ../source/specifications/source-distribution-format.rst:45 -msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." +msgid "" +"No other content of a sdist is required or defined. Build systems can store " +"whatever information they need in the sdist to build the project." msgstr "" #: ../source/specifications/source-distribution-format.rst:48 -msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." +msgid "" +"The tarball should use the modern POSIX.1-2001 pax tar format, which " +"specifies UTF-8 based file names." msgstr "" #: ../source/specifications/version-specifiers.rst:6 @@ -8359,11 +12141,15 @@ msgid "Version specifiers" msgstr "" #: ../source/specifications/version-specifiers.rst:8 -msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." +msgid "" +"Version numbering requirements and the semantics for specifying comparisons " +"between versions are defined in :pep:`440`." msgstr "" #: ../source/specifications/version-specifiers.rst:11 -msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." +msgid "" +"The version specifiers section in this PEP supersedes the version specifiers " +"section in :pep:`345`." msgstr "" #: ../source/support.rst:3 @@ -8371,11 +12157,17 @@ msgid "How to Get Support" msgstr "" #: ../source/support.rst:5 -msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." +msgid "" +"For support related to a specific project, see the links on the :doc:" +"`Projects ` page." msgstr "" #: ../source/support.rst:8 -msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." +msgid "" +"For something more general, or when you're just not sure, please `open an " +"issue `_ on the " +"`packaging-problems `_ " +"repository on GitHub." msgstr "" #: ../source/tutorials/creating-documentation.rst:5 @@ -8383,7 +12175,9 @@ msgid "Creating Documentation" msgstr "" #: ../source/tutorials/creating-documentation.rst:7 -msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." +msgid "" +"This section covers the basics of how to create documentation using " +"`Sphinx`_ and host the documentation for free in `Read The Docs`_." msgstr "" #: ../source/tutorials/creating-documentation.rst:13 @@ -8395,7 +12189,8 @@ msgid "Use ``pip`` to install Sphinx:" msgstr "" #: ../source/tutorials/creating-documentation.rst:28 -msgid "For other installation methods, see this `installation guide`_ by Sphinx." +msgid "" +"For other installation methods, see this `installation guide`_ by Sphinx." msgstr "" #: ../source/tutorials/creating-documentation.rst:33 @@ -8403,7 +12198,8 @@ msgid "Getting Started With Sphinx" msgstr "" #: ../source/tutorials/creating-documentation.rst:35 -msgid "Create a ``docs`` directory inside your project to hold your documentation:" +msgid "" +"Create a ``docs`` directory inside your project to hold your documentation:" msgstr "" #: ../source/tutorials/creating-documentation.rst:42 @@ -8411,15 +12207,21 @@ msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" msgstr "" #: ../source/tutorials/creating-documentation.rst:49 -msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." +msgid "" +"This sets up a source directory, walks you through some basic " +"configurations, and creates an ``index.rst`` file as well as a ``conf.py`` " +"file." msgstr "" #: ../source/tutorials/creating-documentation.rst:51 -msgid "You can add some information about your project in ``index.rst``, then build them:" +msgid "" +"You can add some information about your project in ``index.rst``, then build " +"them:" msgstr "" #: ../source/tutorials/creating-documentation.rst:57 -msgid "For more details on the build process, see this `guide`_ by Read The Docs." +msgid "" +"For more details on the build process, see this `guide`_ by Read The Docs." msgstr "" #: ../source/tutorials/creating-documentation.rst:62 @@ -8427,11 +12229,16 @@ msgid "Other Sources" msgstr "" #: ../source/tutorials/creating-documentation.rst:64 -msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." +msgid "" +"For a more detailed guide on how to use Sphinx and reStructuredText, please " +"see this `documentation tutorial`_ on Hitchhiker's Guide to Python." msgstr "" #: ../source/tutorials/index.rst:4 -msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." +msgid "" +"**Tutorials** are opinionated step-by-step guides to help you get familiar " +"with packaging concepts. For more detailed information on specific packaging " +"topics, see :doc:`/guides/index`." msgstr "" #: ../source/tutorials/installing-packages.rst:5 @@ -8439,11 +12246,22 @@ msgid "Installing Packages" msgstr "" #: ../source/tutorials/installing-packages.rst:7 -msgid "This section covers the basics of how to install Python :term:`packages `." +msgid "" +"This section covers the basics of how to install Python :term:`packages " +"`." msgstr "" #: ../source/tutorials/installing-packages.rst:10 -msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." +msgid "" +"It's important to note that the term \"package\" in this context is being " +"used to describe a bundle of software to be installed (i.e. as a synonym for " +"a :term:`distribution `). It does not to refer to the " +"kind of :term:`package ` that you import in your Python " +"source code (i.e. a container of modules). It is common in the Python " +"community to refer to a :term:`distribution ` using " +"the term \"package\". Using the term \"distribution\" is often not " +"preferred, because it can easily be confused with a Linux distribution, or " +"another larger software distribution like Python itself." msgstr "" #: ../source/tutorials/installing-packages.rst:28 @@ -8451,7 +12269,9 @@ msgid "Requirements for Installing Packages" msgstr "" #: ../source/tutorials/installing-packages.rst:30 -msgid "This section describes the steps to follow before installing other Python packages." +msgid "" +"This section describes the steps to follow before installing other Python " +"packages." msgstr "" #: ../source/tutorials/installing-packages.rst:35 @@ -8459,11 +12279,16 @@ msgid "Ensure you can run Python from the command line" msgstr "" #: ../source/tutorials/installing-packages.rst:37 -msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" +msgid "" +"Before you go any further, make sure you have Python and that the expected " +"version is available from your command line. You can check this by running:" msgstr "" #: ../source/tutorials/installing-packages.rst:53 -msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." +msgid "" +"You should get some output like ``Python 3.6.3``. If you do not have Python, " +"please install the latest 3.x version from `python.org`_ or refer to the " +"`Installing Python`_ section of the Hitchhiker's Guide to Python." msgstr "" #: ../source/tutorials/installing-packages.rst:57 @@ -8471,19 +12296,37 @@ msgid "If you're a newcomer and you get an error like this:" msgstr "" #: ../source/tutorials/installing-packages.rst:66 -msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." +msgid "" +"It's because this command and other suggested commands in this tutorial are " +"intended to be run in a *shell* (also called a *terminal* or *console*). See " +"the Python for Beginners `getting started tutorial`_ for an introduction to " +"using your operating system's shell and interacting with Python." msgstr "" #: ../source/tutorials/installing-packages.rst:72 -msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" +msgid "" +"If you're using an enhanced shell like IPython or the Jupyter notebook, you " +"can run system commands like those in this tutorial by prefacing them with a " +"``!`` character:" msgstr "" #: ../source/tutorials/installing-packages.rst:82 -msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." +msgid "" +"It's recommended to write ``{sys.executable}`` rather than plain ``python`` " +"in order to ensure that commands are run in the Python installation matching " +"the currently running notebook (which may not be the same Python " +"installation that the ``python`` command refers to)." msgstr "" #: ../source/tutorials/installing-packages.rst:87 -msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." +msgid "" +"Due to the way most Linux distributions are handling the Python 3 migration, " +"Linux users using the system Python without creating a virtual environment " +"first should replace the ``python`` command in this tutorial with " +"``python3`` and the ``python -m pip`` command with ``python3 -m pip --" +"user``. Do *not* run any of the commands in this tutorial with ``sudo``: if " +"you get a permissions error, come back to the section on creating virtual " +"environments, set one up, and then continue with the tutorial as written." msgstr "" #: ../source/tutorials/installing-packages.rst:99 @@ -8491,15 +12334,23 @@ msgid "Ensure you can run pip from the command line" msgstr "" #: ../source/tutorials/installing-packages.rst:101 -msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" +msgid "" +"Additionally, you'll need to make sure you have :ref:`pip` available. You " +"can check this by running:" msgstr "" #: ../source/tutorials/installing-packages.rst:116 -msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." +msgid "" +"If you installed Python from source, with an installer from `python.org`_, " +"or via `Homebrew`_ you should already have pip. If you're on Linux and " +"installed using your OS package manager, you may have to install pip " +"separately, see :doc:`/guides/installing-using-linux-tools`." msgstr "" #: ../source/tutorials/installing-packages.rst:124 -msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" +msgid "" +"If ``pip`` isn't already installed, then first try to bootstrap it from the " +"standard library:" msgstr "" #: ../source/tutorials/installing-packages.rst:139 @@ -8507,15 +12358,24 @@ msgid "If that still doesn't allow you to run ``python -m pip``:" msgstr "" #: ../source/tutorials/installing-packages.rst:141 -msgid "Securely Download `get-pip.py `_ [1]_" +msgid "" +"Securely Download `get-pip.py `_ [1]_" msgstr "" #: ../source/tutorials/installing-packages.rst:144 -msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." +msgid "" +"Run ``python get-pip.py``. [2]_ This will install or upgrade pip. " +"Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're " +"not installed already." msgstr "" #: ../source/tutorials/installing-packages.rst:150 -msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." +msgid "" +"Be cautious if you're using a Python install that's managed by your " +"operating system or another package manager. get-pip.py does not coordinate " +"with those tools, and may leave your system in an inconsistent state. You " +"can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/" +"local`` which is designed for locally-installed software." msgstr "" #: ../source/tutorials/installing-packages.rst:159 @@ -8523,7 +12383,10 @@ msgid "Ensure pip, setuptools, and wheel are up to date" msgstr "" #: ../source/tutorials/installing-packages.rst:161 -msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" +msgid "" +"While ``pip`` alone is sufficient to install from pre-built binary archives, " +"up to date copies of the ``setuptools`` and ``wheel`` projects are useful to " +"ensure you can also install from source archives::" msgstr "" #: ../source/tutorials/installing-packages.rst:169 @@ -8531,11 +12394,17 @@ msgid "Optionally, create a virtual environment" msgstr "" #: ../source/tutorials/installing-packages.rst:171 -msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" +msgid "" +"See :ref:`section below ` for " +"details, but here's the basic `venv`_ [3]_ command to use on a typical Linux " +"system:" msgstr "" #: ../source/tutorials/installing-packages.rst:188 -msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." +msgid "" +"This will create a new virtual environment in the ``tutorial_env`` " +"subdirectory, and configure the current shell to use it as the default " +"``python`` environment." msgstr "" #: ../source/tutorials/installing-packages.rst:195 @@ -8543,35 +12412,62 @@ msgid "Creating Virtual Environments" msgstr "" #: ../source/tutorials/installing-packages.rst:197 -msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." +msgid "" +"Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular " +"application, rather than being installed globally. If you are looking to " +"safely install global command line tools, see :doc:`/guides/installing-stand-" +"alone-command-line-tools`." msgstr "" #: ../source/tutorials/installing-packages.rst:203 -msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." +msgid "" +"Imagine you have an application that needs version 1 of LibFoo, but another " +"application requires version 2. How can you use both these applications? If " +"you install everything into /usr/lib/python3.6/site-packages (or whatever " +"your platform’s standard location is), it’s easy to end up in a situation " +"where you unintentionally upgrade an application that shouldn’t be upgraded." msgstr "" #: ../source/tutorials/installing-packages.rst:209 -msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." +msgid "" +"Or more generally, what if you want to install an application and leave it " +"be? If an application works, any change in its libraries or the versions of " +"those libraries can break the application." msgstr "" #: ../source/tutorials/installing-packages.rst:213 -msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." +msgid "" +"Also, what if you can’t install :term:`packages ` into " +"the global site-packages directory? For instance, on a shared host." msgstr "" #: ../source/tutorials/installing-packages.rst:216 -msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." +msgid "" +"In all these cases, virtual environments can help you. They have their own " +"installation directories and they don’t share libraries with other virtual " +"environments." msgstr "" #: ../source/tutorials/installing-packages.rst:220 -msgid "Currently, there are two common tools for creating Python virtual environments:" +msgid "" +"Currently, there are two common tools for creating Python virtual " +"environments:" msgstr "" #: ../source/tutorials/installing-packages.rst:222 -msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." +msgid "" +"`venv`_ is available by default in Python 3.3 and later, and installs :ref:" +"`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 " +"and later." msgstr "" #: ../source/tutorials/installing-packages.rst:225 -msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." +msgid "" +":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ " +"and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are " +"always installed into created virtual environments by default (regardless of " +"Python version)." msgstr "" #: ../source/tutorials/installing-packages.rst:230 @@ -8587,19 +12483,31 @@ msgid "Using :ref:`virtualenv`:" msgstr "" #: ../source/tutorials/installing-packages.rst:264 -msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." +msgid "" +"For more information, see the `venv`_ docs or the `virtualenv `_ docs." msgstr "" #: ../source/tutorials/installing-packages.rst:266 -msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." +msgid "" +"The use of :command:`source` under Unix shells ensures that the virtual " +"environment's variables are set within the current shell, and not in a " +"subprocess (which then disappears, having no useful effect)." msgstr "" #: ../source/tutorials/installing-packages.rst:271 -msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" +msgid "" +"In both of the above cases, Windows users should _not_ use the :command:" +"`source` command, but should rather run the :command:`activate` script " +"directly from the command shell like so:" msgstr "" #: ../source/tutorials/installing-packages.rst:281 -msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." +msgid "" +"Managing multiple virtual environments directly can become tedious, so the :" +"ref:`dependency management tutorial ` introduces a " +"higher level tool, :ref:`Pipenv`, that automatically manages a separate " +"virtual environment for each project and application that you work on." msgstr "" #: ../source/tutorials/installing-packages.rst:288 @@ -8607,7 +12515,11 @@ msgid "Use pip for Installing" msgstr "" #: ../source/tutorials/installing-packages.rst:290 -msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." +msgid "" +":ref:`pip` is the recommended installer. Below, we'll cover the most common " +"usage scenarios. For more detail, see the `pip docs `_, " +"which includes a complete `Reference Guide `_." msgstr "" #: ../source/tutorials/installing-packages.rst:297 @@ -8615,7 +12527,14 @@ msgid "Installing from PyPI" msgstr "" #: ../source/tutorials/installing-packages.rst:299 -msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." +msgid "" +"The most common usage of :ref:`pip` is to install from the :term:`Python " +"Package Index ` using a :term:`requirement " +"specifier `. Generally speaking, a requirement " +"specifier is composed of a project name followed by an optional :term:" +"`version specifier `. :pep:`440` contains a :pep:`full " +"specification <440#version-specifiers>` of the currently supported " +"specifiers. Below are some examples." msgstr "" #: ../source/tutorials/installing-packages.rst:307 @@ -8631,11 +12550,15 @@ msgid "To install greater than or equal to one version and less than another:" msgstr "" #: ../source/tutorials/installing-packages.rst:350 -msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" +msgid "" +"To install a version that's :pep:`\"compatible\" <440#compatible-release>` " +"with a certain version: [4]_" msgstr "" #: ../source/tutorials/installing-packages.rst:365 -msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." +msgid "" +"In this case, this means to install any version \"==1.4.*\" version that's " +"also \">=1.4.2\"." msgstr "" #: ../source/tutorials/installing-packages.rst:370 @@ -8643,15 +12566,27 @@ msgid "Source Distributions vs Wheels" msgstr "" #: ../source/tutorials/installing-packages.rst:372 -msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." +msgid "" +":ref:`pip` can install from either :term:`Source Distributions (sdist) " +"` or :term:`Wheels `, but if both " +"are present on PyPI, pip will prefer a compatible :term:`wheel `. You " +"can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." msgstr "" #: ../source/tutorials/installing-packages.rst:378 -msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." +msgid "" +":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source " +"Distributions (sdist) `, especially when " +"a project contains compiled extensions." msgstr "" #: ../source/tutorials/installing-packages.rst:383 -msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." +msgid "" +"If :ref:`pip` does not find a wheel to install, it will locally build a " +"wheel and cache it for future installs, instead of rebuilding the source " +"distribution in the future." msgstr "" #: ../source/tutorials/installing-packages.rst:391 @@ -8663,31 +12598,58 @@ msgid "Installing to the User Site" msgstr "" #: ../source/tutorials/installing-packages.rst:410 -msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" +msgid "" +"To install :term:`packages ` that are isolated to the " +"current user, use the ``--user`` flag:" msgstr "" #: ../source/tutorials/installing-packages.rst:425 -msgid "For more information see the `User Installs `_ section from the pip docs." +msgid "" +"For more information see the `User Installs `_ section from the pip docs." msgstr "" #: ../source/tutorials/installing-packages.rst:429 -msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." +msgid "" +"Note that the ``--user`` flag has no effect when inside a virtual " +"environment - all installation commands will affect the virtual environment." msgstr "" #: ../source/tutorials/installing-packages.rst:432 -msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" +msgid "" +"If ``SomeProject`` defines any command-line scripts or console entry points, " +"``--user`` will cause them to be installed inside the `user base`_'s binary " +"directory, which may or may not already be present in your shell's :envvar:" +"`PATH`. (Starting in version 10, pip displays a warning when installing any " +"scripts to a directory outside :envvar:`PATH`.) If the scripts are not " +"available in your shell after installation, you'll need to add the directory " +"to your :envvar:`PATH`:" msgstr "" #: ../source/tutorials/installing-packages.rst:440 -msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." +msgid "" +"On Linux and macOS you can find the user base binary directory by running " +"``python -m site --user-base`` and adding ``bin`` to the end. For example, " +"this will typically print ``~/.local`` (with ``~`` expanded to the absolute " +"path to your home directory) so you'll need to add ``~/.local/bin`` to your " +"``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." msgstr "" #: ../source/tutorials/installing-packages.rst:446 -msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." +msgid "" +"On Windows you can find the user base binary directory by running ``py -m " +"site --user-site`` and replacing ``site-packages`` with ``Scripts``. For " +"example, this could return ``C:\\Users\\Username\\AppData\\Roaming" +"\\Python36\\site-packages`` so you would need to set your ``PATH`` to " +"include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You " +"can set your user ``PATH`` permanently in the `Control Panel`_. You may need " +"to log out for the ``PATH`` changes to take effect." msgstr "" #: ../source/tutorials/installing-packages.rst:462 -msgid "Install a list of requirements specified in a :ref:`Requirements File `." +msgid "" +"Install a list of requirements specified in a :ref:`Requirements File `." msgstr "" #: ../source/tutorials/installing-packages.rst:478 @@ -8695,7 +12657,9 @@ msgid "Installing from VCS" msgstr "" #: ../source/tutorials/installing-packages.rst:480 -msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." +msgid "" +"Install a project from VCS in \"editable\" mode. For a full breakdown of " +"the syntax, see pip's section on :ref:`VCS Support `." msgstr "" #: ../source/tutorials/installing-packages.rst:502 @@ -8707,7 +12671,9 @@ msgid "Install from an alternate index" msgstr "" #: ../source/tutorials/installing-packages.rst:518 -msgid "Search an additional index during install, in addition to :term:`PyPI `" +msgid "" +"Search an additional index during install, in addition to :term:`PyPI " +"`" msgstr "" #: ../source/tutorials/installing-packages.rst:534 @@ -8715,7 +12681,11 @@ msgid "Installing from a local src tree" msgstr "" #: ../source/tutorials/installing-packages.rst:537 -msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." +msgid "" +"Installing from local src in `Development Mode `_, i.e. in such a " +"way that the project appears to be installed, but yet is still editable from " +"the src tree." msgstr "" #: ../source/tutorials/installing-packages.rst:554 @@ -8727,7 +12697,9 @@ msgid "Install a particular source archive file." msgstr "" #: ../source/tutorials/installing-packages.rst:585 -msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" +msgid "" +"Install from a local directory containing archives (and don't check :term:" +"`PyPI `)" msgstr "" #: ../source/tutorials/installing-packages.rst:605 @@ -8735,7 +12707,11 @@ msgid "Installing from other sources" msgstr "" #: ../source/tutorials/installing-packages.rst:607 -msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." +msgid "" +"To install from other data sources (for example Amazon S3 storage) you can " +"create a helper application that presents the data in a :pep:`503` compliant " +"index format, and use the ``--extra-index-url`` flag to direct pip to use " +"that index." msgstr "" #: ../source/tutorials/installing-packages.rst:619 @@ -8743,7 +12719,9 @@ msgid "Installing Prereleases" msgstr "" #: ../source/tutorials/installing-packages.rst:621 -msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." +msgid "" +"Find pre-release and development versions, in addition to stable versions. " +"By default, pip only finds stable versions." msgstr "" #: ../source/tutorials/installing-packages.rst:637 @@ -8755,15 +12733,23 @@ msgid "Install `setuptools extras`_." msgstr "" #: ../source/tutorials/installing-packages.rst:659 -msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." +msgid "" +"\"Secure\" in this context means using a modern browser or a tool like :" +"command:`curl` that verifies SSL certificates when downloading from https " +"URLs." msgstr "" #: ../source/tutorials/installing-packages.rst:668 -msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." +msgid "" +"Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:" +"`virtualenv`) will create virtualenv environments with ``pip`` pre-" +"installed, thereby making it an equal alternative to :ref:`virtualenv`." msgstr "" #: ../source/tutorials/installing-packages.rst:673 -msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" +msgid "" +"The compatible release specifier was accepted in :pep:`440` and support was " +"released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" msgstr "" #: ../source/tutorials/managing-dependencies.rst:4 @@ -8771,23 +12757,42 @@ msgid "Managing Application Dependencies" msgstr "" #: ../source/tutorials/managing-dependencies.rst:6 -msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." +msgid "" +"The :ref:`package installation tutorial ` covered the " +"basics of getting set up to install and update Python packages." msgstr "" #: ../source/tutorials/managing-dependencies.rst:9 -msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." +msgid "" +"However, running these commands interactively can get tedious even for your " +"own personal projects, and things get even more difficult when trying to set " +"up development environments automatically for projects with multiple " +"contributors." msgstr "" #: ../source/tutorials/managing-dependencies.rst:13 -msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." +msgid "" +"This tutorial walks you through the use of :ref:`Pipenv` to manage " +"dependencies for an application. It will show you how to install and use the " +"necessary tools and make strong recommendations on best practices." msgstr "" #: ../source/tutorials/managing-dependencies.rst:17 -msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." +msgid "" +"Keep in mind that Python is used for a great many different purposes, and " +"precisely how you want to manage your dependencies may change based on how " +"you decide to publish your software. The guidance presented here is most " +"directly applicable to the development and deployment of network services " +"(including web applications), but is also very well suited to managing " +"development and testing environments for any kind of project." msgstr "" #: ../source/tutorials/managing-dependencies.rst:24 -msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." +msgid "" +"Developers of Python libraries, or of applications that support distribution " +"as Python libraries, should also consider the `poetry `_ project as an alternative dependency management " +"solution." msgstr "" #: ../source/tutorials/managing-dependencies.rst:30 @@ -8795,7 +12800,12 @@ msgid "Installing Pipenv" msgstr "" #: ../source/tutorials/managing-dependencies.rst:32 -msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." +msgid "" +":ref:`Pipenv` is a dependency manager for Python projects. If you're " +"familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit " +"to those tools. While :ref:`pip` alone is often sufficient for personal use, " +"Pipenv is recommended for collaborative projects as it's a higher-level tool " +"that simplifies dependency management for common use cases." msgstr "" #: ../source/tutorials/managing-dependencies.rst:38 @@ -8803,7 +12813,11 @@ msgid "Use ``pip`` to install Pipenv:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:54 -msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." +msgid "" +"This does a `user installation`_ to prevent breaking any system-wide " +"packages. If ``pipenv`` isn't available in your shell after installation, " +"you'll need to add the `user base`_'s binary directory to your ``PATH``. " +"See :ref:`Installing to the User Site` for more information." msgstr "" #: ../source/tutorials/managing-dependencies.rst:65 @@ -8811,11 +12825,19 @@ msgid "Installing packages for your project" msgstr "" #: ../source/tutorials/managing-dependencies.rst:67 -msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" +msgid "" +"Pipenv manages dependencies on a per-project basis. To install packages, " +"change into your project's directory (or just an empty directory for this " +"tutorial) and run:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:76 -msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" +msgid "" +"Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you " +"in your project's directory. The :ref:`Pipfile` is used to track which " +"dependencies your project needs in case you need to re-install them, such as " +"when you share your project with others. You should get output similar to " +"this (although the exact paths shown will vary):" msgstr "" #: ../source/tutorials/managing-dependencies.rst:112 @@ -8823,7 +12845,9 @@ msgid "Using installed packages" msgstr "" #: ../source/tutorials/managing-dependencies.rst:114 -msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" +msgid "" +"Now that Requests is installed you can create a simple :file:`main.py` file " +"to use it:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:125 @@ -8835,7 +12859,10 @@ msgid "You should get output similar to this:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:137 -msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." +msgid "" +"Using ``pipenv run`` ensures that your installed packages are available to " +"your script. It's also possible to spawn a new shell that ensures all " +"commands have access to your installed packages with ``pipenv shell``." msgstr "" #: ../source/tutorials/managing-dependencies.rst:143 @@ -8844,15 +12871,24 @@ msgid "Next steps" msgstr "" #: ../source/tutorials/managing-dependencies.rst:145 -msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" +msgid "" +"Congratulations, you now know how to effectively manage dependencies and " +"development environments on a collaborative Python project! ✨ 🍰 ✨" msgstr "" #: ../source/tutorials/managing-dependencies.rst:148 -msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." +msgid "" +"If you're interested in creating and distributing your own Python packages, " +"see the :ref:`tutorial on packaging and distributing packages `." msgstr "" #: ../source/tutorials/managing-dependencies.rst:151 -msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." +msgid "" +"Note that when your application includes definitions of Python source " +"packages, they (and their dependencies) can be added to your ``pipenv`` " +"environment with ``pipenv install -e `` " +"(e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." msgstr "" #: ../source/tutorials/managing-dependencies.rst:160 @@ -8860,23 +12896,43 @@ msgid "Other Tools for Application Dependency Management" msgstr "" #: ../source/tutorials/managing-dependencies.rst:162 -msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" +msgid "" +"If you find this particular approach to managing application dependencies " +"isn't working well for you or your use case, you may want to explore these " +"other tools and techniques to see if one of them is a better fit:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:166 -msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." +msgid "" +"`poetry `__ for a tool comparable " +"in scope to ``pipenv`` that focuses more directly on use cases where the " +"repository being managed is structured as a Python project with a valid " +"``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making " +"the assumption that the application being worked on that's depending on " +"components from PyPI will itself support distribution as a ``pip``-" +"installable Python package)." msgstr "" #: ../source/tutorials/managing-dependencies.rst:172 -msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" +msgid "" +"`hatch `_ for opinionated coverage of even " +"more steps in the project management workflow (such as incrementing " +"versions, tagging releases, and creating new skeleton projects from project " +"templates)" msgstr "" #: ../source/tutorials/managing-dependencies.rst:175 -msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" +msgid "" +"`pip-tools `_ to build your own " +"custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" msgstr "" #: ../source/tutorials/managing-dependencies.rst:177 -msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." +msgid "" +"`micropipenv `_ is a " +"lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry " +"lock files or converting them to pip-tools compatible output. Designed for " +"containerized Python applications but not limited to them." msgstr "" #: ../source/tutorials/packaging-projects.rst:2 @@ -8884,15 +12940,24 @@ msgid "Packaging Python Projects" msgstr "" #: ../source/tutorials/packaging-projects.rst:4 -msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." +msgid "" +"This tutorial walks you through how to package a simple Python project. It " +"will show you how to add the necessary files and structure to create the " +"package, how to build the package, and how to upload it to the Python " +"Package Index." msgstr "" #: ../source/tutorials/packaging-projects.rst:10 -msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" +msgid "" +"If you have trouble running the commands in this tutoral, please copy the " +"command and its output, then `open an issue`_ on the `packaging-problems`_ " +"repository on GitHub. We'll do our best to help you!" msgstr "" #: ../source/tutorials/packaging-projects.rst:18 -msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" +msgid "" +"Some of the commands require a newer version of :ref:`pip`, so start by " +"making sure you have the latest version installed:" msgstr "" #: ../source/tutorials/packaging-projects.rst:35 @@ -8900,7 +12965,10 @@ msgid "A simple project" msgstr "" #: ../source/tutorials/packaging-projects.rst:37 -msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." +msgid "" +"This tutorial uses a simple project named ``example_package``. We recommend " +"following this tutorial as-is using this project, before packaging your own " +"project." msgstr "" #: ../source/tutorials/packaging-projects.rst:41 @@ -8908,19 +12976,29 @@ msgid "Create the following file structure locally:" msgstr "" #: ../source/tutorials/packaging-projects.rst:51 -msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." +msgid "" +":file:`__init__.py` is required to import the directory as a package, and " +"should be empty." msgstr "" #: ../source/tutorials/packaging-projects.rst:54 -msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" +msgid "" +":file:`example.py` is an example of a module within the package that could " +"contain the logic (functions, classes, constants, etc.) of your package. " +"Open that file and enter the following content:" msgstr "" #: ../source/tutorials/packaging-projects.rst:63 -msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." +msgid "" +"If you are unfamiliar with Python's :term:`modules ` and :term:" +"`import packages `, take a few minutes to read over the " +"`Python documentation for packages and modules`_." msgstr "" #: ../source/tutorials/packaging-projects.rst:67 -msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." +msgid "" +"Once you create this structure, you'll want to run all of the commands in " +"this tutorial within the ``packaging_tutorial`` directory." msgstr "" #: ../source/tutorials/packaging-projects.rst:75 @@ -8928,7 +13006,9 @@ msgid "Creating the package files" msgstr "" #: ../source/tutorials/packaging-projects.rst:77 -msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" +msgid "" +"You will now add files that are used to prepare the project for " +"distribution. When you're done, the project structure will look like this:" msgstr "" #: ../source/tutorials/packaging-projects.rst:95 @@ -8944,15 +13024,26 @@ msgid "Creating pyproject.toml" msgstr "" #: ../source/tutorials/packaging-projects.rst:103 -msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" +msgid "" +":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) " +"what is required to build your project. This tutorial uses :ref:" +"`setuptools`, so open :file:`pyproject.toml` and enter the following content:" msgstr "" #: ../source/tutorials/packaging-projects.rst:117 -msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." +msgid "" +"``build-system.requires`` gives a list of packages that are needed to build " +"your package. Listing something here will *only* make it available during " +"the build, not after it is installed." msgstr "" #: ../source/tutorials/packaging-projects.rst:121 -msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." +msgid "" +"``build-system.build-backend`` is the name of Python object that will be " +"used to perform the build. If you were to use a different build system, such " +"as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration " +"details would be completely different than the :ref:`setuptools` " +"configuration described below." msgstr "" #: ../source/tutorials/packaging-projects.rst:127 @@ -8968,41 +13059,74 @@ msgid "There are two types of metadata: static and dynamic." msgstr "" #: ../source/tutorials/packaging-projects.rst:135 -msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." +msgid "" +"Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. " +"This is simpler, easier to read, and avoids many common errors, like " +"encoding errors." msgstr "" #: ../source/tutorials/packaging-projects.rst:137 -msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." +msgid "" +"Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items " +"that are dynamic or determined at install-time, as well as extension modules " +"or extensions to setuptools, need to go into :file:`setup.py`." msgstr "" #: ../source/tutorials/packaging-projects.rst:141 -msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." +msgid "" +"Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:" +"file:`setup.py`) should be used only as an escape hatch when absolutely " +"necessary. :file:`setup.py` used to be required, but can be omitted with " +"newer versions of setuptools and pip." msgstr "" #: ../source/tutorials/packaging-projects.rst:148 -msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." +msgid "" +":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells " +"setuptools about your package (such as the name and version) as well as " +"which code files to include. Eventually much of this configuration may be " +"able to move to :file:`pyproject.toml`." msgstr "" #: ../source/tutorials/packaging-projects.rst:153 -msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgid "" +"Open :file:`setup.cfg` and enter the following content. Change the ``name`` " +"to include your username; this ensures that you have a unique package name " +"and that your package doesn't conflict with packages uploaded by other " +"people following this tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:185 -msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" +msgid "" +"There are a `variety of metadata and options `_ supported here. This is " +"in :doc:`configparser ` format; do not place " +"quotes around values. This example package uses a relatively minimal set of " +"``metadata``:" msgstr "" #: ../source/tutorials/packaging-projects.rst:191 #: ../source/tutorials/packaging-projects.rst:286 -msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." +msgid "" +"``name`` is the *distribution name* of your package. This can be any name as " +"long as it only contains letters, numbers, ``_`` , and ``-``. It also must " +"not already be taken on pypi.org. **Be sure to update this with your " +"username,** as this ensures you won't try to upload a package with the same " +"name as one which already exists." msgstr "" #: ../source/tutorials/packaging-projects.rst:196 -msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." +msgid "" +"``version`` is the package version. See :pep:`440` for more details on " +"versions. You can use ``file:`` or ``attr:`` directives to read from a file " +"or package attribute." msgstr "" #: ../source/tutorials/packaging-projects.rst:199 #: ../source/tutorials/packaging-projects.rst:293 -msgid "``author`` and ``author_email`` are used to identify the author of the package." +msgid "" +"``author`` and ``author_email`` are used to identify the author of the " +"package." msgstr "" #: ../source/tutorials/packaging-projects.rst:201 @@ -9011,27 +13135,45 @@ msgid "``description`` is a short, one-sentence summary of the package." msgstr "" #: ../source/tutorials/packaging-projects.rst:202 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." +msgid "" +"``long_description`` is a detailed description of the package. This is shown " +"on the package detail page on the Python Package Index. In this case, the " +"long description is loaded from :file:`README.md` (which is a common " +"pattern) using the ``file:`` directive." msgstr "" #: ../source/tutorials/packaging-projects.rst:206 #: ../source/tutorials/packaging-projects.rst:300 -msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." +msgid "" +"``long_description_content_type`` tells the index what type of markup is " +"used for the long description. In this case, it's Markdown." msgstr "" #: ../source/tutorials/packaging-projects.rst:208 #: ../source/tutorials/packaging-projects.rst:302 -msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." +msgid "" +"``url`` is the URL for the homepage of the project. For many projects, this " +"will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting " +"service." msgstr "" #: ../source/tutorials/packaging-projects.rst:211 #: ../source/tutorials/packaging-projects.rst:305 -msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." +msgid "" +"``project_urls`` lets you list any number of extra links to show on PyPI. " +"Generally this could be to documentation, issue trackers, etc." msgstr "" #: ../source/tutorials/packaging-projects.rst:213 #: ../source/tutorials/packaging-projects.rst:307 -msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." +msgid "" +"``classifiers`` gives the index and :ref:`pip` some additional metadata " +"about your package. In this case, the package is only compatible with Python " +"3, is licensed under the MIT license, and is OS-independent. You should " +"always include at least which version(s) of Python your package works on, " +"which license your package is available under, and which operating systems " +"your package will work on. For a complete list of classifiers, see https://" +"pypi.org/classifiers/." msgstr "" #: ../source/tutorials/packaging-projects.rst:221 @@ -9039,52 +13181,96 @@ msgid "In the ``options`` category, we have controls for setuptools itself:" msgstr "" #: ../source/tutorials/packaging-projects.rst:223 -msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgid "" +"``package_dir`` is a mapping of package names and directories. An empty " +"package name represents the \"root package\" --- the directory in the " +"project that contains all Python source files for the package --- so in this " +"case the ``src`` directory is designated the root package." msgstr "" #: ../source/tutorials/packaging-projects.rst:227 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgid "" +"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " +"`. Instead of listing each package manually, we can " +"use the ``find:`` directive to automatically discover all packages and " +"subpackages and ``options.packages.find`` to specify the ``package_dir`` to " +"use. In this case, the list of packages will be ``example_package`` as " +"that's the only package present." msgstr "" #: ../source/tutorials/packaging-projects.rst:234 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." +msgid "" +"``python_requires`` gives the versions of Python supported by your project. " +"Installers like :ref:`pip` will look back through older versions of packages " +"until it finds one that has a matching Python version." msgstr "" #: ../source/tutorials/packaging-projects.rst:238 #: ../source/tutorials/packaging-projects.rst:329 -msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." +msgid "" +"There are many more than the ones mentioned here. See :doc:`/guides/" +"distributing-packages-using-setuptools` for more details." msgstr "" #: ../source/tutorials/packaging-projects.rst:244 -msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." +msgid "" +":file:`setup.py` is the build script for :ref:`setuptools`. It tells " +"setuptools about your package (such as the name and version) as well as " +"which code files to include." msgstr "" #: ../source/tutorials/packaging-projects.rst:248 -msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgid "" +"Open :file:`setup.py` and enter the following content. Change the ``name`` " +"to include your username; this ensures that you have a unique package name " +"and that your package doesn't conflict with packages uploaded by other " +"people following this tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:283 -msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" +msgid "" +":func:`setup` takes several arguments. This example package uses a " +"relatively minimal set:" msgstr "" #: ../source/tutorials/packaging-projects.rst:291 -msgid "``version`` is the package version. See :pep:`440` for more details on versions." +msgid "" +"``version`` is the package version. See :pep:`440` for more details on " +"versions." msgstr "" #: ../source/tutorials/packaging-projects.rst:296 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." +msgid "" +"``long_description`` is a detailed description of the package. This is shown " +"on the package detail page on the Python Package Index. In this case, the " +"long description is loaded from :file:`README.md`, which is a common pattern." msgstr "" #: ../source/tutorials/packaging-projects.rst:314 -msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgid "" +"``package_dir`` is a dictionary with package names for keys and directories " +"for values. An empty package name represents the \"root package\" --- the " +"directory in the project that contains all Python source files for the " +"package --- so in this case the ``src`` directory is designated the root " +"package." msgstr "" #: ../source/tutorials/packaging-projects.rst:319 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgid "" +"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " +"`. Instead of listing each package manually, we can " +"use :func:`find_packages` to automatically discover all packages and " +"subpackages under ``package_dir``. In this case, the list of packages will " +"be ``example_package`` as that's the only package present." msgstr "" #: ../source/tutorials/packaging-projects.rst:325 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." +msgid "" +"``python_requires`` gives the versions of Python supported by your project. " +"Installers like :ref:`pip` will look back though older versions of packages " +"until it finds one that has a matching Python version." msgstr "" #: ../source/tutorials/packaging-projects.rst:333 @@ -9092,11 +13278,17 @@ msgid "Creating README.md" msgstr "" #: ../source/tutorials/packaging-projects.rst:335 -msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." +msgid "" +"Open :file:`README.md` and enter the following content. You can customize " +"this if you'd like." msgstr "" #: ../source/tutorials/packaging-projects.rst:347 -msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." +msgid "" +"Because our configuration loads :file:`README.md` to provide a " +"``long_description``, :file:`README.md` must be included along with your " +"code when you :ref:`generate a source distribution `. " +"Newer versions of :ref:`setuptools` will do this automatically." msgstr "" #: ../source/tutorials/packaging-projects.rst:354 @@ -9104,7 +13296,12 @@ msgid "Creating a LICENSE" msgstr "" #: ../source/tutorials/packaging-projects.rst:356 -msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" +msgid "" +"It's important for every package uploaded to the Python Package Index to " +"include a license. This tells users who install your package the terms under " +"which they can use your package. For help picking a license, see https://" +"choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` " +"and enter the license text. For example, if you had chosen the MIT license:" msgstr "" #: ../source/tutorials/packaging-projects.rst:387 @@ -9112,11 +13309,19 @@ msgid "Including other files" msgstr "" #: ../source/tutorials/packaging-projects.rst:389 -msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." +msgid "" +"The files listed above will be included automatically in your :term:`source " +"distribution `. If you want to control " +"what goes in this explicitly, see :ref:`Using MANIFEST.in`." msgstr "" #: ../source/tutorials/packaging-projects.rst:393 -msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." +msgid "" +"The final :term:`built distribution ` will have the " +"Python files in the discovered or listed Python packages. If you want to " +"control what goes here, such as to add data files, see :doc:`Including Data " +"Files ` from the :doc:`setuptools docs " +"`." msgstr "" #: ../source/tutorials/packaging-projects.rst:402 @@ -9124,7 +13329,10 @@ msgid "Generating distribution archives" msgstr "" #: ../source/tutorials/packaging-projects.rst:404 -msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." +msgid "" +"The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the " +"Python Package Index and can be installed by :ref:`pip`." msgstr "" #: ../source/tutorials/packaging-projects.rst:408 @@ -9132,19 +13340,32 @@ msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" msgstr "" #: ../source/tutorials/packaging-projects.rst:422 -msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." +msgid "" +"If you have trouble installing these, see the :doc:`installing-packages` " +"tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:425 -msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" +msgid "" +"Now run this command from the same directory where :file:`pyproject.toml` is " +"located:" msgstr "" #: ../source/tutorials/packaging-projects.rst:439 -msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" +msgid "" +"This command should output a lot of text and once completed should generate " +"two files in the :file:`dist` directory:" msgstr "" #: ../source/tutorials/packaging-projects.rst:449 -msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." +msgid "" +"The ``tar.gz`` file is a :term:`source archive ` whereas the " +"``.whl`` file is a :term:`built distribution `. Newer :" +"ref:`pip` versions preferentially install built distributions, but will fall " +"back to source archives if needed. You should always upload a source archive " +"and provide built archives for the platforms your project is compatible " +"with. In this case, our example package is compatible with Python on any " +"platform so only one built distribution is needed." msgstr "" #: ../source/tutorials/packaging-projects.rst:458 @@ -9156,23 +13377,40 @@ msgid "Finally, it's time to upload your package to the Python Package Index!" msgstr "" #: ../source/tutorials/packaging-projects.rst:462 -msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." +msgid "" +"The first thing you'll need to do is register an account on TestPyPI, which " +"is a separate instance of the package index intended for testing and " +"experimentation. It's great for things like this tutorial where we don't " +"necessarily want to upload to the real index. To register an account, go to " +"https://test.pypi.org/account/register/ and complete the steps on that page. " +"You will also need to verify your email address before you're able to upload " +"any packages. For more details, see :doc:`/guides/using-testpypi`." msgstr "" #: ../source/tutorials/packaging-projects.rst:470 -msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgid "" +"To securely upload your project, you'll need a PyPI `API token`_. Create one " +"at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" " +"to \"Entire account\". **Don't close the page until you have copied and " +"saved the token — you won't see that token again.**" msgstr "" #: ../source/tutorials/packaging-projects.rst:477 -msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" +msgid "" +"Now that you are registered, you can use :ref:`twine` to upload the " +"distribution packages. You'll need to install Twine:" msgstr "" #: ../source/tutorials/packaging-projects.rst:492 -msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" +msgid "" +"Once installed, run Twine to upload all of the archives under :file:`dist`:" msgstr "" #: ../source/tutorials/packaging-projects.rst:506 -msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." +msgid "" +"You will be prompted for a username and password. For the username, use " +"``__token__``. For the password, use the token value, including the ``pypi-" +"`` prefix." msgstr "" #: ../source/tutorials/packaging-projects.rst:510 @@ -9180,7 +13418,9 @@ msgid "After the command completes, you should see output similar to this:" msgstr "" #: ../source/tutorials/packaging-projects.rst:523 -msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" +msgid "" +"Once uploaded your package should be viewable on TestPyPI, for example, " +"https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" msgstr "" #: ../source/tutorials/packaging-projects.rst:528 @@ -9188,7 +13428,10 @@ msgid "Installing your newly uploaded package" msgstr "" #: ../source/tutorials/packaging-projects.rst:530 -msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" +msgid "" +"You can use :ref:`pip` to install your package and verify that it works. " +"Create a :ref:`virtual environment ` and install your package from TestPyPI:" msgstr "" #: ../source/tutorials/packaging-projects.rst:546 @@ -9196,15 +13439,25 @@ msgid "Make sure to specify your username in the package name!" msgstr "" #: ../source/tutorials/packaging-projects.rst:548 -msgid "pip should install the package from TestPyPI and the output should look something like this:" +msgid "" +"pip should install the package from TestPyPI and the output should look " +"something like this:" msgstr "" #: ../source/tutorials/packaging-projects.rst:558 -msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." +msgid "" +"This example uses ``--index-url`` flag to specify TestPyPI instead of live " +"PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have " +"the same packages as the live PyPI, it's possible that attempting to install " +"dependencies may fail or install something unexpected. While our example " +"package doesn't have any dependencies, it's a good practice to avoid " +"installing dependencies when using TestPyPI." msgstr "" #: ../source/tutorials/packaging-projects.rst:565 -msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" +msgid "" +"You can test that it was installed correctly by importing the package. Make " +"sure you're still in your virtual environment, then run Python:" msgstr "" #: ../source/tutorials/packaging-projects.rst:580 @@ -9212,43 +13465,71 @@ msgid "and import the package:" msgstr "" #: ../source/tutorials/packaging-projects.rst:588 -msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." +msgid "" +"Note that the :term:`import package ` is ``example_package`` " +"regardless of what ``name`` you gave your :term:`distribution package " +"` in :file:`setup.cfg` or :file:`setup.py` (in this " +"case, ``example-pkg-YOUR-USERNAME-HERE``)." msgstr "" #: ../source/tutorials/packaging-projects.rst:596 -msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" +msgid "" +"**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" msgstr "" #: ../source/tutorials/packaging-projects.rst:599 -msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." +msgid "" +"Keep in mind that this tutorial showed you how to upload your package to " +"Test PyPI, which isn't a permanent storage. The Test system occasionally " +"deletes packages and accounts. It is best to use TestPyPI for testing and " +"experiments like this tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:604 -msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" +msgid "" +"When you are ready to upload a real package to the Python Package Index you " +"can do much the same as you did in this tutorial, but with these important " +"differences:" msgstr "" #: ../source/tutorials/packaging-projects.rst:608 -msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." +msgid "" +"Choose a memorable and unique name for your package. You don't have to " +"append your username as you did in the tutorial." msgstr "" #: ../source/tutorials/packaging-projects.rst:610 -msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." +msgid "" +"Register an account on https://pypi.org - note that these are two separate " +"servers and the login details from the test server are not shared with the " +"main server." msgstr "" #: ../source/tutorials/packaging-projects.rst:613 -msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." +msgid "" +"Use ``twine upload dist/*`` to upload your package and enter your " +"credentials for the account you registered on the real PyPI. Now that " +"you're uploading the package in production, you don't need to specify ``--" +"repository``; the package will upload to https://pypi.org/ by default." msgstr "" #: ../source/tutorials/packaging-projects.rst:617 -msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." -msgstr "使用 ``python3 -m pip install [your-package]`` 以從真正的PyPI安裝您的套件。" +msgid "" +"Install your package from the real PyPI using ``python3 -m pip install [your-" +"package]``." +msgstr "" +"使用 ``python3 -m pip install [your-package]`` 以從真正的PyPI安裝您的套件。" #: ../source/tutorials/packaging-projects.rst:619 -msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" +msgid "" +"At this point if you want to read more on packaging Python libraries here " +"are some things you can do:" msgstr "此時，如果您想閱讀有關打包 Python 庫的更多信息，您可以執行以下操作：" #: ../source/tutorials/packaging-projects.rst:622 -msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." +msgid "" +"Read more about using :ref:`setuptools` to package libraries in :doc:`/" +"guides/distributing-packages-using-setuptools`." msgstr "" #: ../source/tutorials/packaging-projects.rst:624 @@ -9256,5 +13537,7 @@ msgid "Read about :doc:`/guides/packaging-binary-extensions`." msgstr "閱讀 :doc:`/guides/packaging-binary-extensions`。" #: ../source/tutorials/packaging-projects.rst:625 -msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." +msgid "" +"Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:" +"`hatch`, and :ref:`poetry`." msgstr "" From b8db7ba38c0b621266cb29bf816911211bd758bc Mon Sep 17 00:00:00 2001 From: Alex Solonenko Date: Sun, 29 Aug 2021 18:15:35 +0200 Subject: [PATCH 0086/1072] Translated using Weblate (Ukrainian) Currently translated at 13.6% (309 of 2271 strings) Co-authored-by: Alex Solonenko Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/uk/ Translation: pypa/packaging.python.org --- locales/uk/LC_MESSAGES/messages.mo | Bin 0 -> 25026 bytes locales/uk/LC_MESSAGES/messages.po | 29 +++++++++++++++++++---------- 2 files changed, 19 insertions(+), 10 deletions(-) create mode 100644 locales/uk/LC_MESSAGES/messages.mo diff --git a/locales/uk/LC_MESSAGES/messages.mo b/locales/uk/LC_MESSAGES/messages.mo new file mode 100644 index 0000000000000000000000000000000000000000..b7a278f7f7a625897c6e2ccfa2a00b711d1eb2dc GIT binary patch literal 25026 zcmeI2d7NBTnfEW7K-iH@7P%3~Myh(t(rF0LBu&zg&2)!FLHc&p?d~GgRYfh`=@6Wd z$fhwU#;7Q}12~Qv+JuCV1V+Y%nQ^RU9QAb++;PBh9Jkl~eZRkR&aI`>5t%>ckNHra zoP6&&_w466&-0wq_k|M={h-Hh&Ox4cCj6%(J?~+j*S%4xo_ECQp4SDBgl~q|!K2|i zcoe)7s@wi-|1+Ia($B%a`SrsGr?lHLq8zaMt|xZ^hX z2GaMq__I*+^A$J@zYgi5xBP6IFAep+08fKA!5+8;sz1MS>3@POy?3f_=VdZHg?I~8 zKQD*Jz*UY3#~Y#g`ByIf9vA-z)VlmNJPbYwRsYja?LG%p@AFXW_-&~Azw7v)j(>z2 z?@=s@@}CH`j%PW}bi4qn{N+&fUk#0XxOfOvPsYVdQ2lu)yc*sC`R9Gtr60ngssG17 zwKo|`?i(HFLzTbWvD@(-jsuQ)$93@cvg^3Qvg|LBVMW5=VAP4FQ&3e~?=Q*FK1!8Z{ff!fy}aOsagjqh_%?fj$THy!^SY8=0D z@i$Df^LH{loOBhGQKt?(H*8=g4buJ2-aDDiIirh`21 z8mRshX4vs=fa=F4sCm8zUI!nA55vRGxBdBq?L-+_m~KS1dxZ>F8^ zHh2WlYoYRo@G`gtYQ3I@r~>c%5K;9GiFw{!I0aq|-vPC5_rWIk3{?4_!=-RuoVkLx z!*=)>WQn|&VGBH=!OBMmWU9RzAVc%+hDX7@a1wmZ@vAQVMHhd?#eWT@Uk`4y<=zNo zf6jLC*--1&4v&PLPpK;y zeIM%mOgIZ(0##oLE`aZW>hD*e+W(e|zXT5>{!7Q-LG@FMB)K^fs@yS9`A&EAq2_f8 z)V#)Byw$}ofs*gbq3T%i6%V`g16oP3<1*cp{Wso&ryTNq7Prftt_vzzg9=q2&4-@O=0?$0=;) zHxge7RevAU_;OI~mf#!UJ6-%%sD5pRTE~w-weuL%eC~p(=krkIzXFy28&LIrAFBU9 zhU(`}pyuyS?){-`M&&;eD*YsQ3_KnF@F4UP93*}$n_ly|4xR$P0M(yw!%N^#U<}6E ztbg}*sCoSi)cQW-_$9|OH2rk^zT;0Ff9rVY1-ATgP~$t*(T5t>bg21^!Si4{lz!-k zRN-xgC&K5T`ui=Y^>_tpK2Bw^Bp=hE`m+dX-B!YBu;_R%JcIZb-23mj_@VQyKJ*>m z2Gx%(a5~%#5k>C@Q0YZ9z#hgf4k!sR}v1ujOCpn($I16gL3!(aZ1=PA- z={VrH7HU6kf*S9G@DR8Ss-5jn{rVzQdoRGV;Y+Xx4@Y?*65cu}J-Q2O{l?&#@b^&d zp4MSG!|_7LWsW^i^OJYH&G8=i(n0tmQ0umJk!}AWsD6JAD*fy5WcYo@-#Q+**w%ZV z<2=WuQ2RfC(g&*@*FeeZt?*FzAXL4NIPQV!=kty~f|}poK~$A@7@J-5egQljUJ6zJ z^JmYd3zXEFi-2_|Vqi`Ag4pco2SJ-+Nz|)Dp z4Kf8@3GRk_;bm~m5^NRo`7~6&zO&TI?SDW_k9Q`Ow!r0Z4%`Tjg}b5V;W@__9e)M2 z?nf=RJQq$PJ|9Z17en>u8uz{kC0Fl-l8Xo6ac~so;pgC;aP|t%Z z7(C-(<`rt6yravm<9euhcsD#2-UpwBpMp~u?~UDdJwCk3_Ui#SllPB9RJHd4l-@h# zO1pkdd^WNfk5mb7oi?4F= z9;kImyZFuUWa4+a`2A3F`$>2t{4CTy+Y66?&qLMwZ%}gk64ZV2()E7Ur@9~wDu9CiGAsP?`FB~LHHH^P_UY4A@_{XX?tTRsL=-^Gs0pz>b_ zC0{o})prY2f8OohZ-ujn{|%fCUxZh{ldrS=4WQc3xcCS>jQDMio1p5w8y*5b3N_CA z-TS|F9EFgR1x^Y>x*{ywPu54-eF!()hVhX+CZ{+@7r6yaI>w@4@vo+n6d z^jkwf{JaM8J_I`n|3EmM_#!B|e6y?P9-eO|ypy1xWI%ci^<{qQ!!hLje^BFipGmbc zcoOM7F0Q%!jC&q{DT3tn3oh+h_(t-7%Ei9}-{YQzUlHEG``h4b7$=;`^E86=V2lta zJVw|+C=>ob_!&XJ6UmPXGcxsSlY&iy3BvIN?a7M?cM!C$h@;m?nJ>b91g%Yy@GgRW zzqK&`%O30{Y$fa4MS$H#CI}2RAiTDdV|H;MwFO;5mlyDC3&Vw%!wh^Zo-koS3=aM(f7v^|0|y75Tf5pJUksmcz*<;k@$Z`Y4C2sZwP6ZHj6wr@w|@k z*Mv6_<`X89z6}1Ja4DgIpx;rXFN7Tg*~xD!k>B4E{zy2N@Daj!yc_>JjkM2^xRLNx z!g~qZ3Hm)rXm({T;(0wGM*J+o5}v0J^xI=${-4gf!wAwNN5db~ywl@l|BL z*@NK|N}DlbK{nH$4~nI9P)ubrg_-_HwlsAp^m9RCb6pXx0Y757(+ z6bG^yKbOzm5GIO~XUy=w_p!(PpWXl7ZF*3h`D~#O%ZGhoKFlOSzdy```E03>9+@$N z*Nej-nacDROk`PUus6)x=ape0M~!|a800+-1c_oQ5!#ns#h@7aL7`9@%$cs5;;Raz zsexpek7dGAF(0J;LUAM=n%7}a7`Z-`DHMZr+9c#sIoLF}rLkpRtJgGd_MEx1n!M)5 zrj}S!bF8sdkF#P;P5g6@&9UZLdYm0=oEK}FYaf-j#cOVvHEYhiX0LfxOUtb0rrBQe zoThn=jjgl2miSz+tuK`h+j^F^FYCOlqpLff%JfW><|nd)gG_QEdbzTrec{rM_+YZf zpH>KqrCc$aO&9!@Iq_NX#`C9-%a$(`$>)}YX3zJtdB3JuV|-4$dG3D2iff9M-q;2! z(cFkz*?2KKn6B@{td@9VZ6{1a@kC!grE_7ft!GwCYmeVm%H^{8qSuB9wDmCMye$NS zybjkS(xqhR-;@iAO*b1f-|WZZ@k);VbhbB0$Nu7ssm!a^m=F4j{!PhLK1Qp>FrT@( z(%P$+&gDxP`a5Cie3&TZ3#p;7+TGfGe`b``l9e93TFLfgG9|f3zVl%rTgtOByqZKK zC0=_v?H30^Kg)l4zb_T0lLbG>lVCPYkdAxpxg6UiwT6d$D(xfMbE}W7)yH{Wdp-eWj{ znIN03R6t%-Ft9yMrjmXtW2U%RDrWO3&8TTtBM$r_bQz1JNFgy04u;->Y`Qd<0cMxO zOkb+MgvuqG&&Ef|4l)+KD5TJ0evp=o@_vXZqdRsNRkw7HUnsFIbjZHxOQ(uGGhJjL zC?*DoY20r6Wy4~Aq=#N+GesI=ns~6z71}uFtOnVE%-c*ojSk+7R60t-m&2AU7HrC3!LL#3s0_iPG6@ugt zg2X%&6ibu}nn9kkiIQf<&Qx(Er}x=R8238XpiI!MZP8Pq@<7^U?Qiui3w!gWAU|ST zuZ^|Vy_-iYiKsaE%}ta?M4ae0qsD8ZE%90P(b*;%R=Pvp!JtSV7Nv^bqBK^JK6r~X zxdm@=P#BOQ^%hI|bBx#Pw3ew(BK^L6cF+hIGoGd=D?0sBK{MaelQWjL#g7g8XjKH! z7&iayl4z8hvDnx3u-2|(H+9$#_NeR(8{ecAq8wp9dQuCnippD)mdbgT2bpL#TWcfp zyvs{zH_6cx8C;s)qC1U(iJtV=p`_g*3@2Pe+bM}}!B3}F z8*RsKuBeP9oeMgab#=tC!`_lG$TJJ*Paca?)k1$NGZ~NSp7mah``|4Nq>#;gRvufc zsq=Vri{T#h(xmVz%ww!jSKiWWvc%3^77iEqZ;j?A%<-7z-%!n-t&O#M%M-#K&w156v*WK`&zyMUtJGsBA@n=( zNY}_QThUqRM|FbQOLQ!sDvp>O?Gxm{vCaENb3~(Xrp0sqA&#Hl;8&bQ?yRhL5PB=87pqfTBWnU^+EJ)MIn+M znRd2ueOp=%V`S8v%U_6@I%74q%r+}MBd^8u(`>r_)Q}SU!Z6v3SkbwDDr8EkCP~i5 zK(UxBv^6x~v!>$Ne7_&_Gg%Cm(P6bxaH=?9`a2j<($=Seq&aSA`n4O>`%E~Dckhg?v1xi|ba}Xj z;V6&Zqb0nRvb$|Yt)o~9-&_Akl*Hpema!)_U<}LRQg7VrlIw~5@Q_1|Rd!}ww6*^2 zJg=*E57oyCURS9%60xol&I*>R8>NgsLO0IDb4sr+OeQJx-N`1dS93TY4emd;O z7!C#LQdnp+omj`#TD54MKOCm9Y$)x@OlR|j$fDuJeBa1RBwCXI7v4nZI5v(}qZN*K9`~EW7 zNm)|rn#%ZXgOW4Td+Q;{=5oYKmN;E!Gv>taJm3u5P5rdGc7&nCIL4!qQ<%?@o}LTp zsu@mk*la6u3{q%a3v6WSE;*3<8TZl7KW^I!SCqr zS0oc%2AJc`OrM^FTvFu1EDoS`bL~-w0bz03{Uu#uP_eq2!p}F?5ZbkgAeZ7EAhp&g zO4C%vOetM4N0^bCB?|1cMvBfYzq2PR+&o$xFaN|IVEjQj=9+0vyZav*kg&)BnCWww zQqd!HHZ`adv(8h=RG+&yLC~+lHOgYAugV8GrW$evtkEpe99QMJ!fErds~Wb^94@I& zbM&LMq&cn$3kou0)}4&J$uxqBm`WbUzv|0};aaxl^odJyz_Olbl;iD9*IloyGyS1d zfP&-_Lze_zPdg$v6xypC`|PIl!bp0Chlk_3_TliO3!gZ9yTQh7Z!hY(o@#Qr&OzKc zzfz1dTS_T10u3h5rC~U%m91pSjj*L_-si1zP5dH6y@WpZ7X%s3RP{BmX7;Tq>o#Ho5=2hh?qyuY<$~4K zVtqED+WE`U;hHt}J=U*Ju{e4liR{stLOhji2r~_oVis+ki?Z2%&cn={-;u%K)l5tx zoh>Ef{U(E*ZykV@r$LorT;)aCY8G>mx4KmASuz|-Fd&WIys_o;T-&9?LPLL8l(@#2 zusjAVCc_!4S;s388E$&D3^y zg*pCKi`#dxoJp=u=n6B&_RPqzu^W}vwB)u(;NF=QP3O8YK`vn~mnzu{QIb}`WV$lo zdX;Tm$)XyEY@&7r;%)M=(`_GYPF58oVq1>8ts7O@bJ6@JUBmVCcs+WaSNquFQk!dX zG&jbhWOIM#vb4mBvE$!<4!cz~wZ^H}yjuBlQhmW{HP6+`Qf(3My#Y6EH5MXcDljRyEZj7! zT@zgs(+#nS8n1+!o8nE;IvY=gN}J-Xrp{7c=O@ZKPtZKGC9ug9M2uWPZXaUCB3I?w z38@77hG6a5UhGIiC7TiP+(1t=!&Mxp89~KaF>=C@On{GSs_1o68vEU`LjiE zB9noKR?DS4d2XC=49&^XLoUcr5KH()+>Ge*&12{uUJQ*4^m{U7?A}6{?u(`PYekr} z7R9L2q|`+$6&CwqH*n64-B8G8V#8r?3<)&$q`L=FW`65|2B z*nqX)l`_($gVDu?DJ}EwIdA0pNL0K*Tu{5po-9WfO3kyb9oEUqg=;*mB>~qMTZLQu z7P@nOr+ERgKTL7j$wYk4op-9O~zzgiv4Tr zYWs6}hX>LoFJ61?-`kXCm4u!&#b%2YJZpQs=*(^&>>*l@_FBmN?a8wWlXcWS=Bl!g zNUcUp>?W?dmG&t&;#C!;Cw<`+hB96;&#hLh#&CE>>3KuCj2cSii=`l~N4x*m;xOS! znUj1zx|@o1CL^QP=C4|vN5OK_?N6h(!SqQhk%)XTwzSZnO2#fN^%r8@**1UDisdnT z+GkU6OCGlQ*L1Y6j4fRrTiEU|Uf#B}^Zd6hU)C{cNl+-py73VTxNF&bn}6A=B}@Ee z?MplS3p_r^`A+_+p& za|L95i~)j@;1M;deYL)r5)8FBM_4o*n5gtH)r%Vt~#+j#?oBiC%6=0;^(jG zzAV;S&8HD@kco9<5?OP`_FH>X#YrpD{Ouzh(@lAy&Cldav@pNr0?yicGe2`)Q{(*k zP5zWAz8)JV&u?n-FZLUKaudI3eslEd!uhlGIL&0cu&L2sx6T$JPvdmTG*PDcf=O4$ z7U>Vrc6P6_Q{&Hy&y6?ZB@9jCFVf|^$F`1bC~q6vQr=VEH`6bVmUsE(o#k!irwO~q zHj=Qd{1l1G<&Ui|@8j*${69K&%h=}f_VO59lYBycB}dSmh#@QtxDWCc8h6cTX`=@cbUItmp??&&r-!x>PmTc zd6!Low7iSlPnEaX=oSiZptfD*Jq*P(L$~juRuVP74ZPazk8Nf2JE+_ax2Bo)u+4Ftvlb5*hkrcs$NO0>bruEUjq{W`+iPrbsr=dg zHUAyId=I1A!`$uF+9NN~omkCvJ%41jUjS6@XzTx${ulp2pJpCsrmD&fN9=#-kNV~N z5sK}R@UW`e{OaHNJ@*I3*Z;mB6vutV@Zb3Rewke=RltT}^PpJR^+=d>!q|FN!RQ}v zf?T}YtL;Lrjcx<8pS|+KByQEF-pj7FDun&SuGfy+Cy^?TP93`oMdsRz*VewTyxZdi z-B1sxW0U>E)Bb6#6XdJ=cA$K(bmndBZT8IAMxOzpMbR8vXZp0id+ZMB0i$vsC;bWO zVKr*C-tA}+sb^<}dHRqM@qZPBdtllO& zl07U5?XpJB)@-EJt;{;>Z?q%n=xK7vcxXN8%P9TD3{>Z0uZ&jQFW*hEJ!ZxA&R79T zKTh>zuCYBDsjFygOSOR-EpCm%*zM(QcG2vDjoqexy6G||5LL)vHc}x5fVR}_tw@%P z0;@N+o@T~wWiIy^y=jJzoHBqqyW^D~R27U&<`CKO>QwGF#M@b~QM15y;f*Bk9eWq` zeU?68+$g#gY1-_SAE36K%o0Do*;Qxg8+f!6rk$l#AJt;Bi0nACCO)IETV8K=F@g=`VZ`raH`-}M zdX?$^Da=))0ov-YFAm(aH(^(p#%WPHkOPukI}V_nZbu9dX<-+fM^vC7XwQns0$ z^`y4MM1oTJ(8L%E*^oQz0vl({ltn*CqVASJnq@TxCz3}B)T$CAm^&F4U!q8a?0U%i zmD*(8#x_TPF!&2TO<}S%G*(C|2Nf()F!h=}@VE?wyy{B77_<}7aUIr*XlIPwzTb0T=ftD*Xm%?qt|G`%>h&q}kOL!?l{}J^`V`4ZeabvfwKD3_YTa`uNTa>| z^3meQm@RiWKuP&l6=SAkKV`$Dg%R8Fde^9YEwtJ9qtY~3gGhbvL+Ca}D#BJN@%Lp; zn5idgr>>%!$bqWjf3sJO&5>BxI?djZGV`$^#@vuoRY`4NhA4QeDY(m=81`VF9;&I1 zfpNkywaYpX#n_D9B5A+}bul9y)Fx%bX0r|1BbsEI?jtuC_-J5iPtK1$%TarI7tP)y z0aPb6Clei3BvqP>=H>L#3?%Z||@`9R~> zN;b0go1pR*itc3MOh1^EyXu@DG#R_-cDA+7Z2KnoR)`6Z!0n)tT2Y-K6>*&)6_K@P zvU-u-FAb61FRk`#BWpvLFKmc(odjo>1i~mjtv2tT)i6hYQJJK7G)o;a)`F7e5bY< z;%~-c(#JMNhQ}_bQ83cTHrbU%+Sp3%Uim>IM7J?Y`7vx?YwYaXs&O%&JuzrpIa;jf zNWbn&sLF>$?h~ljkl%a`^&0YCOms3DuiK)@+W(s_r`{?HQR%hS zI(3IAbmqAJ{>9&Vm31*?4ZA!}Er@YP>Kt8p&#bB(gs8*T1jwhCn8=yN1**ys$<931 z>3#IflQo*(R9d+=k8Yp&Vhk0DlA}VD5Noz6GO#p4lrZ4%4Vsk ztzZ{dhsHgk;~IrE8uVUvZ@X;QP8q22CbX^&%FBeZ6#MYob}>Jj<(P6}F-8D6l?!Nh zePmZ_x`27X6V_=e>6n~!-2puxclG`t?0=#*dK<6@R@7c0C_G^sJz-?8FRJR$a zb0^JFonp;4cG^wH5OZOts_lntCZ*;KN!d|q*`klzj1-S6!v{dLs$-h!wzrCGP5C^F z+;?x~_tPs~y`ov=!P$z%D^z~dd#eO~Kv6JwPjRMn1Pnmai3yW+oAB=j9n)_QEXb!; zQ`=alcew$a@u!+&lsSi%M<@H`hsd+Rc!av#`7GVWd(^g(fa}yN%_S#EM}fz+XJpvj z*+K(kB6kvxHr+PPY|OH@wzAe73pL@|i#lAIiDx6z5be{L8?D(|R=KDy3m?aP*QQ88yOd)>{#BDYZ`9S$$Kl zc&V;LXSE~_ zriiJs?vz2rs6V?itifjm?QM$ln6z}d5!@RyLtf9!ZynoAt?I}Dud<}VIOf>?N@#F{ z#(%m<{~|9#jUspE(n8Z%(??=ziEV3#9R1-lvKI|zlI$#M&ySAX?q&No@?C6bXAkWorAZ6gqSCCjcc8$!3(Z3vVCcN-v2XQlCBv4yMXJcK-a4b|s zri>99`HH9xWZIcoSwEGK`mXJ@QPxhP$37%O;cjP{9F|a<$lT|c*)rxF1*?UZL@7Jh zJ6i3r^=zSV%Ay_E%BAeaNCIwaj<=AR^81)Doq-7xMTYA-;Iw2oU#4z~|f#r8mc zr5&WM)em&rYpk}&>v+#NRdy!%0OkISS>_`M^HFK} zAsWN{865D_QWiM6D2hHht$ta0pt5xzm%2>m`%?SN0@*7Q+=AD?G_8I}rB7pC|I$<+ zu9|PpUjNec^)F3d|I(D*V7}VAOgX0WVC@%V{|mlM{r{{i B;BNo` literal 0 HcmV?d00001 diff --git a/locales/uk/LC_MESSAGES/messages.po b/locales/uk/LC_MESSAGES/messages.po index b3d1d5c96..dbb3dd5b8 100644 --- a/locales/uk/LC_MESSAGES/messages.po +++ b/locales/uk/LC_MESSAGES/messages.po @@ -8,10 +8,10 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-07-16 11:12+0000\n" -"Last-Translator: Sviatoslav Sydorenko \n" -"Language-Team: Ukrainian \n" +"PO-Revision-Date: 2021-07-16 11:37+0000\n" +"Last-Translator: Alex Solonenko \n" +"Language-Team: Ukrainian \n" "Language: uk\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -13487,7 +13487,7 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:596 msgid "" "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" -msgstr "" +msgstr "**Вітаємо, ви запакували та розповсюдили Python-проект!** ✨ 🍰 ✨" #: ../source/tutorials/packaging-projects.rst:599 msgid "" @@ -13496,6 +13496,10 @@ msgid "" "deletes packages and accounts. It is best to use TestPyPI for testing and " "experiments like this tutorial." msgstr "" +"Майте на увазі, що цей туторіал показав вам, як опублікувати свій пакунок до " +"тестового PyPI, який не є постійним сховищем. Тестова система час від часу " +"видаляє пакунки та облікові записи. Краще використовувати TestPyPI для " +"тестування та експериментів, як у цьому туторіалі." #: ../source/tutorials/packaging-projects.rst:604 msgid "" @@ -13503,12 +13507,17 @@ msgid "" "can do much the same as you did in this tutorial, but with these important " "differences:" msgstr "" +"Коли ви будете готові завантажити реальний пакунок в Реєстр Python-пакунків, " +"ви можете зробити те ж саме, що і в цьому туторіалі, але з цими важливими " +"відмінностями:" #: ../source/tutorials/packaging-projects.rst:608 msgid "" "Choose a memorable and unique name for your package. You don't have to " "append your username as you did in the tutorial." msgstr "" +"Оберіть пам'ятне та унікальне ім'я для свого пакунку. Вам не потрібно " +"додавати своє ім'я користувача, як ви це робили в туторіалі." #: ../source/tutorials/packaging-projects.rst:610 msgid "" @@ -13527,11 +13536,11 @@ msgid "" "you're uploading the package in production, you don't need to specify ``--" "repository``; the package will upload to https://pypi.org/ by default." msgstr "" -"Використовуйте `` dist upload upload / * '', щоб опублікувати ваш пакунок і " -"ввести ваші облікові дані для облікового запису, який ви зареєстрували на " -"реальному PyPI. Тепер, коли ви публікуєте пакунок як продакшн-версію, вам не " -"потрібно вказувати `` --repository``; пакунок буде опубліковано на https://" -"pypi.org/ за замовчуванням." +"Використовуйте ``twine upload dist/*`` щоб опублікувати ваш пакунок і ввести " +"ваші облікові дані для облікового запису, який ви зареєстрували на реальному " +"PyPI. Тепер, коли ви публікуєте пакунок як продакшн-версію, вам не потрібно " +"вказувати ``--repository``; пакунок буде опубліковано на https://pypi.org/ " +"за замовчуванням." #: ../source/tutorials/packaging-projects.rst:617 msgid "" From 6b3d45340d54cea962b4d6939c3268ab15dce247 Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Sun, 29 Aug 2021 18:15:36 +0200 Subject: [PATCH 0087/1072] Translated using Weblate (Chinese (Simplified)) Currently translated at 15.5% (353 of 2271 strings) Translated using Weblate (Chinese (Simplified)) Currently translated at 14.8% (337 of 2271 strings) Translated using Weblate (Chinese (Traditional)) Currently translated at 1.3% (31 of 2271 strings) Translated using Weblate (Chinese (Simplified)) Currently translated at 11.8% (268 of 2271 strings) Translated using Weblate (Chinese (Traditional)) Currently translated at 1.1% (26 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 4.8% (111 of 2271 strings) Co-authored-by: meowmeowmeowcat Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/pt_BR/ Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hans/ Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hant/ Translation: pypa/packaging.python.org --- locales/pt_BR/LC_MESSAGES/messages.mo | Bin 0 -> 25213 bytes locales/pt_BR/LC_MESSAGES/messages.po | 17 +- locales/zh_Hans/LC_MESSAGES/messages.mo | Bin 0 -> 55353 bytes locales/zh_Hans/LC_MESSAGES/messages.po | 372 ++++++++++++++---------- locales/zh_Hant/LC_MESSAGES/messages.mo | Bin 0 -> 4208 bytes locales/zh_Hant/LC_MESSAGES/messages.po | 18 +- 6 files changed, 237 insertions(+), 170 deletions(-) create mode 100644 locales/pt_BR/LC_MESSAGES/messages.mo create mode 100644 locales/zh_Hans/LC_MESSAGES/messages.mo create mode 100644 locales/zh_Hant/LC_MESSAGES/messages.mo diff --git a/locales/pt_BR/LC_MESSAGES/messages.mo b/locales/pt_BR/LC_MESSAGES/messages.mo new file mode 100644 index 0000000000000000000000000000000000000000..7e9d050e3f69273b8c57ef47d4f4c863f4a4f52d GIT binary patch literal 25213 zcmbW9Ymg+_b=MOl%hp)Z+Ok#%c_pVtkDY0CRqw83wA=e~&rZ+7nn!ycyIMWGon4jP zoikOHwV7Gn(}TdqfQ@hfCa?k9LTE8U)&^@E)+T}t2O&iZ1%V^@Ac7zqfWl!L8x+Fw z7Xku<#qWR4y;)V=J@T$Pw)RwIW!`)4x##ge=boCcyz$jPlkhj@bq}vkzA8y{;ht~j zfBcPKn&aLhpw5p}PMz^v^(l7RrCgKjVLY8~W?e zZ$K~c@I_Gu`(5ZKq2B}jORrCo?|}Xc^beq)g1!~{H{OsWZ-M?IRNsFgeEzr4Kg;Le zfqpmi|3Tjdz3VRLuLJ!upC5v1{MUU~l6(=GLZ62IS7;4=oQJoeFG61fz2}Ya@~4vI zozTAy{R|I(H}pOhIpF(KZ}xG289LtBZI{>Q&JNnQ>8K`57!%h2bc1yt*N6T+38-v*W3PeQdde=g9+pxm0AfwJ^u1Nv_0 zvrt%1{$BY0d8o$!67&)1Z$Te`z71h5K-ZvLO8z|bUg+P4>iN$@HU7VcejD`bQ1SIY zp_=cHp}!4%J)15*{}B2f=>LU20e$E9CCR6uThL#Jen*OqK>s!LqsU?59jt}VKXE)s zeh>Pupg#%y%sZ3hhoJYrD@lF{`j??^;{FF%+;emX~_*#YL z&}-0-L0^Ktis#>QB1v}ne9uW=*H1%#gU`PL{WA392;)86clo_Z@-;s1Ec&>;4!XtX zn^5g<(M1=ae*r2v{Ss7i`~p<#{~AxS1`9XjF!G~N=*P#E2>pu)-i<9N$Bw-7a4?$lG zy#>|yKNjdGp?C55UqIQS8L5 zpM-uJ^i7W?$qVrLR_Ldp|K{-|S%elVN%9x@{_mbjlHY{hjgtLC=+~iI=ifT*`|)$o z2f6_KrI$!DRG*T00`4gHT$$?boH>#zSox4-v7+1g|qx&ZxosP^qkP*gAZ zDpcdW`Gf9HPe5P8=d;jb&`VJ1&C|NhdTv19z~^T#Bnc{#{3w(ulV5{=0s0N-zk_}O zp>INe>Jq-4=l&NIRY|tjuxaS0pr3&LG{&cWdHan@LvLiM>19YIIX8_@p(eLK&edooG>3ZJ*0@^yU;`a697&JQKY|ABrT`VsE? z>eF0>JA03EN=n(H`H&>m)D9H|3>2hOrKkMcr&5?q1pAtswF@_LZh-Mr%8_wfd`N)_u*TtMyGKiQN1q(`skb)MJv^IGTi8eaPA zIcfj@Zr(}XQ0wFec>QT!=0BjAl>Ke+|2({xuD(j|7Z#qV%DV1U`DR|_qh6kF<)geR zC-q=&VS%qt7jmA}7|YrZBOWkU@+ zuCiWJ^m705YLhj2n$`7WI2Mn7^?J=UEx(^vol!n%s%!uwdxP9Yf2t~Y2>zPwJgt~F zuekoeefPh=bN~JPmn)(#daSaLf~IciJyDO^2HFCIi-*4gJ`vvSFQ`=pp5Dz;2$se*Pp} z+QjSZsvRHi72JI%S7Clpk(O!CURPK(_LAlFltY|VG^9KE8 zIgGa1gh^Nys#K@j8L~q02YCY%XtPOflOc_lbJs3jNKyVV`X5)k-d&Pd`%Bx+aIlUB zpewzmtoFL;)8YAYoCoo&Gg5x58*bH}isPLk-?j108Z`25zL9QJY++t4vTMwyr800i zL^=BK#$$YmWop0uxk)X8?2knO;#rTLIO=zcFF=(&Dh^9 zWR4DM-7|L7O|Q5?N^3NgI2-2KC}>-TjK@I}r<@G4J*k^6Y!;RF=g=*!uDao+(my$d zde)C@mEwz~!r`2GFKX;jS~JhClzxU|zTrY}L~{dllT+F#8?qJJpzKMRk|)a1X0bJ? zTu{So1jn*NebLDD?G2_qi9Q2$HM#4H9qy3ZLHdX@?`>zJqQ@gFPJRiW+3TTnO>#OP z4@&ckYkSSMoauCX>SV?>&%QtCq|G?kD-_)}Tu!2O&t_0KzWf$5$+{2t>2$YX;&}(Y zRbu+69iFw{4X!zO0`xhCi;lTYe7Ku<`pEPvd2n-JgdOvib!SH*XzDp1!@HlJa}Lek z7*#x7j_z&bZ4@M0r3k{2x=%($vnStRo)7Wv<^!&?a@S4b1M0Dtj!N9^w!#^EU!`o{ zVsQP7Y2Kf>1uUk$$)K53d}lj_fZV=Nr#(4uH>onk4OKDHxfhkF-GwvXq_>UEnSdu$|#lGhjxA|MhvK3=Wdod673bi8)I^0rKtfRK{CrRn`WnS-X_JjPe}c zZG7z6Rx)cDEex$1GzFnYKA|eJ-Zo(v{^kWCpV}aSgJx>3=#Yil)q1Jb;11{s90joG z__e&2VV(m95MQzsd+ps!nYnj!Spbf0HaM1MgK}a)M`nsk0Tv23R<6vuASrfUGo8C5u4IYK7dW*2BE9O;vn#m6szI;5dADaO47e7@+&DaaMt1s&uQ^X>|ji z`*?aLM*%h~;3aYc(h|!@roF9i27uyjcFT&jIgYJCkrw`VWD{JxmkQtv+3{*Ztn?@@ zl@V6jux|+n{S+WEEDT0#GJ>*;g;;?A@TD0xnU70UkjaBr$P~pbVA;|Eaq(FhB7V7> zoF8Ue#mJnPkTjecbBYu|JqsDp*7bmCK9V+9Bu&?VIEb1Buu*VT-z)~GzpummN*vRk zN1ukiU-E#5zlTxjEAE5^*RUaog#HD1B$WYxu|yk0%W^JIQ$PZ+tDByKtA1%5Rw!RN z>OYLku=Ox* zYZT;V0*sQ5k7zDa+L>L-QersRl8M7mn$6rcF@m=i;AEoF*(B#JQIQZa%^D9{p-6`y zyiE7V0Eu#s*^Yh=qDB9#~E;2uEDWm8Rr<`_yJ%tkz0r)Jqea@5XcO|n8k~D%x)+oSj;l_5|&I<3VR^PZR>Ww-bd~5%J_j@%WNh4 zR^ZYV6ABXEoD4|5aErcIt_`+r=AA7|lL`^Gs$T9|5C`>}<+d1}D1y1U&js}4GZ2ZS z*y16@uaOS2CS#07cjc%NACaFGs#7?sNt1Y$t6N}a`|eoB}wl+ zaVWGtxlA%koI!=}m1pSp5t8d<$gn&y9gs08ZY*%)!lIFiDiDD}SE#jg)61-@+AV7I zTZVX`eu74h2{z*5bm0$ zCRSUixg?%6_=t4ekb|;4{HA|r*>!%4T8r+{_pB(nQfzHE%Yge~yHgnUpv`2Etox-5)21g1phkd_z4Q!muPcW&$Goav z7VaG1wgA|s6PRgMY-JDZkA2v;J7VV$hL**`{ixozh$%3UDyh6Vu(iW+)3l5%mK*i zv8V$!EZgeE?>f!NULD|)T^L{^hz-D$+g9>y(f!OLMWg& z_|k5U=4d&w6f2hBnRJS-XN4OffR$I31DFy@v#3*BHBeq{`N8|{yU!mBt`U_$oWk<4 znvPGcq$!3Q(DZF=y+>iqc-BhdlZ3*)!hzeHJ%-O1kyruzlrM$)e

)T8;#4Ven$$sXoR#PmS1+WJ(KTtJ{YS=Ab}{KLR*&^5tkDt)kr!nF$LQ+ zxNiZSLfyPBTXoXSx7D#ABJ}?$#dC&Kevfw-V2D+pcAw*nq>1EL7rSO_)Cb{B++kPSG~1kTc>+<4QHnw3<8Xr($9-rOqpq&~=?P-;XN63(3NsEx(b zcscxJK9)sc1tB&$D3nk<$H(D?EWxI1IRdLPNjP`FqyYG0$xdci4H9)(hH^hMfKcs- ziHUTA0jjY~g?dD#^gbCWMh?`)D zKA3B1^`kTvaVG?F)$ZpkgR#Y4WjaAxRw;csLb6p$z{Er6Vlkf=mvmWQIK~ z%YN5q0ganJ$TrCpsm(yV_TjeeUPc${lP2fk{bmRM?~h|p&v))?tQ8lY=Au)CrA3xUVc3V#M+-;bv0xPfGg^zS0&uMIE$=bTm=S5FFrEo? z$oHCNeceH9+8NsHF?e>Wb@JMqL1SW)}8VoSl0%(& z4iE9C!P|p&*?*e}dD-NZi3t~13^U;A99zoV1rwx6K7xFFnezgK&}>l_)G`G!3<*VuNK__tQ2qp^fJX0&}?&57R?iIvq$U?>yr*Si2Gi|QzSzR&&MbbhX71lN3^Unn7zj}+bRa_ZI@Ia89UgtEbtCY7#zua zoEUjjoePcOv9K&Z1G2?qv!iL9FvJCzK4O&$ud$~~lSOYQWpHc|Lj2s!IO$e0;pt9( z3)nK}bOc0>4EBnP!ByG$z2#@?>9YLd^15B>j`!9%BioaQ@y!gUco->iwD|1{i+wr~ z9Ha{i!Rx9k(XxAUHrNR61;p5ED7>WjamUC3Q%HB>CR==-7S7cT5quV^(uP?(_cA@> z%g9sIYbDgPBI_pMo3<(A&;_+Y91atSq9Naq=Rsr&`J$n7xna+dL`?NxG ziq0wrjh5f14{j9Av9$puwn68NDyqxrXlx(rM;~~YR9D|TI!Yf)?|=B%hdO7~4(lR% z%2$=Xzx#pi0~`?U9HZ&HhN^ITD7e$!!Y0v)#1&zXn!7 zk(>SJsSlOIGA%c5?sTf1az&{&N8Td;|j2=>xui@w3|u&XrzS)EVAwC%=K=Qd&5wzxLYx z3(aIuhW^_9mpEq*AFgOp9lkTvxY~bCa9HMn%Lh*5-RPV0HLs}8*7_TGLkXk_BV0$T zSp;kr0~6X70%Ls4o8H^fU6!iPsz6zfYP(&jIHB1o4_Mou)OialVi}pk zAT?cND}*AaU+@0{p~8hH_J!Uu-5gtPd9-yW^G&(EQgwqqH&D)Gg_-l#O|CNz(F(|% zhL&8_l5yeQle_;p;i8o1@YtnxnlGaxAD4YbQ%(T7B;%Xxzn~dLW$eyf)mam_?Cd{B z>dV}>a+YF)Av^M4vN%&8x`wz44-Jm06LQO&Mkq;e7g*xq4#``ZSE^&$ao^2^}vu?HTGN&7gL`zE! zH_`oLnQ4Y_GZ53o3lgwW2TYB@Nm1tecf0A6W@|PCHcAl#t?~WlW=n8l|E}pU@PIo& zY4nVt=^TJ;p(&LbWf#%FT4I>4+`D#dPB=LU$~&GFaE;Xf!Ac`e_Zk?lzLO z{gM2X-sJcMu4&Gzh9gG+~eSXGS?PSFfj4dMjElq5uDd!P6_MK~=>Z+|) zR-xo33fQW5QpP+vE9J)->y!B!HrtPkOuhAVlkdOOFYTTBc2$m&)4@Gi;Um*G)JlTH za`o-*|0DW#vzo@;0=<#;GHjD2XYjG&1F*osl{t->O$m@Kw(QEiCo34Fcg~u(H%;Z} zN1GuhqPhhKmm|AwYA=svtasB@C7#~D%W1>WVF7)yui7v(6EZY`Nhuy}uDa(C-_Z-G z$D{Ssfl+ydSK8BiE&84~urDIHBn2cM;1*5vjIPuNk{uHsQniK zz?s5@dj^oq=h|jqz?9jR&4>ZzsE|d_jG03pZ~;`1+cqS}xG-jhQVFRrx6(XO=b;66 zQZSz4r#X4WqjF6w<{;)H=z-($eI`Gl6rF4;c3F%M?4f!ailaV-StPA9jsrBu2I&^? zoiiA7Xsx_B={IS;OtUvH{|Nu*)N}^MTe}q&FyA7)0veOQ0D#IZvPugfW@ssBaf}fP zzavhJ7V`kNl($vx4p>iWrzc0HKSMay4f05&`hW&>9$U5p+y>)cV<~DS9&E|_A_OLK zV>o~VR<5t7-#Bl?1kkZuHCs0Z?a>fEu{ad2nKWr+eLTHN9U+sc?SC3hcn=3APhxU7 zpOP;VuxFEkJHu1(BZje@1V)VPXcNwHUg$C~$x6szPI)N(=*A+i;|T#d;EY;^HIz*x zWu_*mTt`*hUD%4*FkyUue*d}7AnUe`!v`e-0@}!==g0&eBo-a2 zq03%q5VK}N(l|XV&m#wg?l$?LuoMLeY+D-*2o)ppC2fKH4M4{!BsJi_MK33Ii|y_F zJ?=--)w)JIgxvUnTYlU010ikkOBtED-R1nKj!5e;6L!-llwSFFb`jT2L-GD6TtEvm zI-xdL(PX z%shauwGUg8hAaol$*4T251GWX-~eV-x*03(6fW}7HtP*R+xQ>xsVM~(_|GL&+ZQP3 zFzy^<$_uNDmWynw=^(LFN0^rZYYr7zMqD|23T!SIw5j%gmBg-uH)_}9V5m9VbLXUQ zK9NH(c(6rF-9|fVY_YM;RH=)58&g$odK=M%Gv1lUxfYL##71Vr^8MzerX`Rf4 z2(@>BY_z534G`VWwLE3Y>Ge10GkY4wY@JW4rA1%JhlH9DC{TI}zjFrUp z&|2v z$`FaWGWorDFeFT~G5`1p?vllWo~_Fx4(mQssh@g3!d1Fe&tp+SRrxK2mSV@Cj5Ta< zuxLdI=YcW@D;VMSWyiCi#QDIrrIDQv?quRj$}YJ1+fLK^=wfa${tfWQ7(gS#ztlbfC2Q7 z4lxlU!hrd0^Sg?m8hAO`|2ckV!$@j=kTW&_w*QhY!UAGzo0^dlKG2|{RO`q+=YFx( zRuhhfPqxv%g`otYs)|$}!(&sXf;BxMLTEzcJ~j_y;>ev}Pp};awp=2&sG^jDVHp5 zGAMb2OO@mkUM$Nu6SFWTvr!C!wQ?Mm+m>6_+jeKkTW$syO&{>;92AEE_3qFB&k*=L z!%_oe=oMF`-5Bv1!{Cf#DNrm4;46h4woIS0Sa|YEKrj!MexNOyqb41EsVVx243lE@ z_)S$~+?U~UeH-CyzSecHI~pdvPgis zW=yfKnzAX)X316jC*?+>YqHt~j3C?5&1Yf zc(eX$@?%mEDWppTaNl-X%NNUUl1WdChvq%z66=?lq|7Y|1%0GlqIKpUZorOuk6Wb* z&Cen%$(QF*fsBStMFH6``l%l5%xcBPU+m3Jrr62KY^=WpP`LZHW*LyHJhkxM44w{v z0-%YAV)1MTgsXcUy5gP8e+BeEEwiGB5o#z)9F#WxkO)K1w#nPX&O%rd8HfjQg+moD z^tAQ_+#2^&RSECeW?vjz;r}LE83+HX7$QHWzU>>#f=Khgn3%g%iexC z#PNsz*@F4zZAq5lW~y+4lZ0<3jYWcQt#iAZg6;`5Dv&Y>3sf{Wtz?x$0vj-eh`{d? z4W@9HN_@21i%)ia+R7c4qaCH#sq`rT6 z_H^>XoT0+kO3mSi+IbbW6)b10D#Ujl4_{BHwiJzW%0tG;)4|v405mjslS=47QNBe7 z148n2Oe5`nPPr0>cnVhKbc8fx)U~Xk-6epz`ahzwc==AMrNI!Bj%#>A#x9-m>`re0 z&vbj@0!N`ZHZ_v=v4C}CYU~+!CyXnVwmf)R{P25BgOs8u-3{f8;MeRp%oe2{Zxvf; zMZ*eY0R5}9`gcTsH-;Xvrr@kyU&3C|7DO2bmJg^LPJ@iVY&o`ia2Fhh z@{Y_01(`6W29TN27Kfvk1kH(R&+U=mGg<&6URCg$IiY}=_5|P;*km0+gjR3C@Toge zG8)5E*v2qCs7&~RgMZkRtlFwEi;KJi>7$~1mB7C`>z0anxr5k0&KOMmmc~4R9#Qvx2lX5CRWMG5= zyc1b{@*QbB91C?flw1cCrt;YhQdrpYTo>hECRm~M>RK5_${73-(K$G|v6};}ex&K_R7Z_!53HtUWhH}q0A0nn2As*m{sO>8jPakuEwy+TaTM?0c;U;s`-XRVe8&jiE7)X2j zFLGv9b}VO`wucvW1nsnktBy($H9-$i{X_bpjHAgIkqts1=404mj7;ZoRdK@uVVf11 zGA)=kS-K*0LnGjXe-%W@F=9~>fzw!FRDOU&Uw?~V7_w~>S7A?KF_y`=S1Hf_i(n#! zB#n!B+SYJ{&8BMCs01TMM)jhGO%+u&s3o1YY8BTOPqcVFXSh^apsF1!r8CjcD4#el zSG%}n-Am)}+gxgQ%Zy83P7w9rfa)XVC3eh@3DJSJ{X zuF*jPYm7q+qM2domRTbXt8URf4{2Ovn6=I3O=kYPLgt4T~^*) zASd{Y!+0@yBGxJ;T1|RnJtg#ev&7jFlK}{epZhNnR9klto6N%r{mbqaG4R2^6apI< zpL+m8l^QTiP{suygwHbt9s3HUpxVX1pM{jCkYAf2uN}b<4|<2WhCFhi#=^Ao+<8#% zIat#8&>^3JFr|D<<|){;q5`DDpktd1qMzZ^y(89y4mi>Zs|$!skj)i*TKkKwb+g6D zRx-N#o42MP+TMBD!QY+5Fmup2Qz^4Wpv@Lp@FfPu#G0pp)HH!R>uU>}`E4<%AUMpeihWD)J8N zusvHZi%Y;m&qKbLL3%&?%aJV}O1d$aJ7<>YEI+bJ|Ey%@_2qymMDa-Fyt2u!MXl={ zN9qM!t7WU!9lQ~SFZAM7DD%Yw8kr4cc$qI?+<+O>{Z3VWC+D~QC$0$s)0$B zVE-g%DSt&^X^%EAHv6Y+bU+{}#k|oP;#D`dGtAlKjMaFzn*$RDtiUFI&i_qY;Z^mY zIpAQN4Hyc`o}!#1yW(9)R>}jJIzIBYm{m?5fyOVZ+~&>k@rku*)hb?kIoEZ%>xBodxym>xMi8n32rT%&JQW`gfT&A4-LkN?xskfa1w*OGT4GvQs z5h+&%(jLq`F&N|$!fKm{dJDaBKfd=SdTLpm+L00pmV!X2h=bv#8KFFD+X2(Y8JSHR zW56Gl0g3;3(7_Z(^M%@bPyHb*z$2Kkty8s&8A)tpcqC>#dc?MNr~#ygu@_TJ#>Cdp zV+(KQLCBqC+gtFXO*y0}{v@y#1aDpU@%$nEA;$+MXBz>gTir05nx5SV wW|FFK$1E3)<;92AJLR*r4NE2G#M@2$%V`KZbU{t_E##RE?unxJ!4CZY4}at*F8}}l literal 0 HcmV?d00001 diff --git a/locales/pt_BR/LC_MESSAGES/messages.po b/locales/pt_BR/LC_MESSAGES/messages.po index 7af4ab446..964012ebf 100644 --- a/locales/pt_BR/LC_MESSAGES/messages.po +++ b/locales/pt_BR/LC_MESSAGES/messages.po @@ -2,13 +2,14 @@ # Copyright (C) 2013–2020, PyPA # This file is distributed under the same license as the Python Packaging User Guide package. # Rafael Fontenelle , 2021. +# meowmeowmeowcat , 2021. msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-07-16 11:12+0000\n" -"Last-Translator: Rafael Fontenelle \n" +"PO-Revision-Date: 2021-07-16 18:53+0000\n" +"Last-Translator: meowmeowmeowcat \n" "Language-Team: Portuguese (Brazil) \n" "Language: pt_BR\n" @@ -47,6 +48,7 @@ msgid "Writing new content" msgstr "Escrevendo novo conteúdo" #: ../source/contribute.rst:15 +#, fuzzy msgid "" "Most of the work on the |PyPUG| takes place on the `project's GitHub " "repository`__. To get started, check out the list of `open issues`__ and " @@ -55,16 +57,17 @@ msgid "" msgstr "" "A maior parte do trabalho no |PyPUG| ocorre no `repositório GitHub do " "projeto`__. Para começar, verifique a lista de `problemas abertos`__ e `pull " -"requests`__. Se você está planejando escrever ou editar o guia, leia o :ref:" -"`guia de estilo `." +"requests`__. Se você está planejando escrever ou editar o guia, leia o :ref:`" +"guia de estilo `." #: ../source/contribute.rst:24 +#, fuzzy msgid "" "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of " "Conduct`__." msgstr "" -"Ao contribuir para o |PyPUG|, espera-se que você siga o `Código de " -"Conduta`__ da PSF." +"Ao contribuir para o |PyPUG|, espera-se que você siga o `Código de Conduta`" +"__ da PSF." #: ../source/contribute.rst:31 msgid "Documentation types" @@ -85,6 +88,7 @@ msgid "Tutorials" msgstr "Tutoriais" #: ../source/contribute.rst:40 +#, fuzzy msgid "" "Tutorials are focused on teaching the reader new concepts by accomplishing a " "goal. They are opinionated step-by-step guides. They do not include " @@ -169,6 +173,7 @@ msgstr "" "atualizar o nox usando o ``pip``::" #: ../source/contribute.rst:84 +#, fuzzy msgid "" "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See " "the `Hitchhiker's Guide to Python installation instructions`_ to install " diff --git a/locales/zh_Hans/LC_MESSAGES/messages.mo b/locales/zh_Hans/LC_MESSAGES/messages.mo new file mode 100644 index 0000000000000000000000000000000000000000..047fa98e9bc492b26a1ca3f24a79a481f51c5334 GIT binary patch literal 55353 zcmeIb33y#sb@zQ33N%0%N`Nx;!~tTPNU~)o9tZ))b`pc_nAjl%8ho#%Ygw_RD|970 z3Q%M_p6A5#5Zj6EIEkka$Ajd7LTBjkLC3c(EuecPb)v&d+qVmg0dIP36#W^$Z+)wtM$!3qN6~wL7l8YL ze+YaXa0w478m$28yUoDsfX9LS7k!0)-Uj?O@QuL#1AH~`nxAv{<^bOTR6Qer*8r=- z^GN|t0ltFgGs62>0e&*Tx&T`O>S17`x6x@bOdEAR_IegB5*qlo{acks`j z0dECP1HNlS6x9Q>z`KFJ0{j8+tv5u`1i|#y}+B^7exnO7DaD* ze-y>sf9b|3`WfIifiD32fFA+wAL--%7VvNM9H@T%{-`MW9Prz~j{+YU&0GMF0p9^! z^?@k*B=8VW>-R6fR{>vjlh5nxfg1O9z_$ZO1~>(%dHz(muLJ%p_n!x<-W@>U(R090 z1Ai6xCg2TKj2U<{5LAk00%PD};Ol`K0^9?93-`x>n(s?M_3w|v`@V4hec(5E{xTLx z<$o8b`56HI67b){^RLu69{d5Yh39_^6kdOH47d+m09?X6mw+1A1GV12g+Sr`N}%Rt z2T=36Kfq%^h88^!ycYQ9z^8!U1D*oz92Z4bfOn4f{=fR>D7v5fp8*zt&A@ZOZvz(r zci%$afiDL+G~T}gs@{JFwgX>1F^Z@%`aDqmJPquk-xq-D-{i?rw2b>Hz)x`h)elC| z&ja6aYZR^H`BLDUxqta>QPc#y4)`XXF9)ifZ6A)J^}r{AdSCOAC_2pheZX&UKjn7% z41CK}pNHkZ*K@xScpY#rQ0w&^Q0ws90e%-qSE7Fc#=vpYq6id^<^k^lb^@=Xov#2N z=l&0;JAYbwhtIUy__YhF{xSCG968Jdq2H=yxmjizlsCIq>_!#g{fU3WBMie~*TnE&A-uzKtkGp{C z=f{C>0L}-33Q-=Y^?U;OYT!wr>OBj59q`wHn*ZMef`U;mQ01@tn3umEsCq{MzeK+$ z0O@-47c>2R?JOVXWMDVXrvpK`D4Ol?X5c%yeGqs(a8;Imhci34A;E7l0b~H-M_Q2-Lj1?Bno0;5&gD_a}j)f$M?q0-gol2>d2c z-~TI6-(P!A6#W!%H1IXRF~C;*KFcFgs8`$eGE z@i&3`{_lV)|Mq#_?v22o;eIku`2}=%;}X0RIr! z0DLp>BlS`A0pMJq=-`V$;o~acn}C~unwNt>&DR;A*5#|fD&VgJg|Ghv%mH7?KXf^I z5crChfycn5+<$$cuj{l1=NlQI+8MXV*XM&k@rgTu{|?Ln)oxv*wyP>uK|7qsCvEz{4(%cK$bE(usDi9+35Sgj{@(2 z*|9XyR^U9w@z+4n(d{6?0pPy_S(0df-uv-yz~kKCz#exUAKfZ~_yfUgA}1ZsYc1AiKL2B`VD3>01ciJnvMKLWKb(UK?{3wQ(Y zEx;+jF~Cm%Zvd_aA_Agkfm)9eQ0;t%oAJO0folH%@YjJa0RJ5L#fKa(GM&Ee4Zzp& zycwwP9|o$QtHSe50qzCf#`9yqX}~_3sCE~1*q}v1`1z~0Y?B&0oAW>05xBK22}Y0pvLw0;rVMm?|AZNp!)q*;92JJ zJ;0yk{`bD%{Ox~aX{hk2gCah2l&wd?+q{$;Nk$61h_1~4FT>9@Cl&$b0WYOfSQ*}0sab5 z?f!Ov-wf~%0{mm3`uk@A{zZV_2O8dWxxVuTpw{hHpzw4ya5bu;B&z1 zmpLE(Ca{6~pIh$ttAXF){+qxlz_TlSUH=()JNG~Jh@pCP7x0_hUjeRp8N7O>>ksdu zQQ^T9;5p!I;D>>)TI2X~2k^_>&kFa~u64e79dI_!R{<{re-9|U*|yI4+A~0{-y7Ha ze7y@O{ELC&CpQAs?&NTPXL$c9;M;kg1-=3JFz}tgbpaj)eun$609DWR8@!(JK$V*U zR6ia7{v5Cn-aiIZeFuT>0GK#f#1T8hra?;y-OZ*zVHR$BJRHlRQX%CvChE10Dd1>*zV;UcX<1)Kv-4u1>iW~ zKLURmIC^IkHPY|#K-K^FE@UnDM}T*5|L?nzoxo{(m}{PI1!^6>x!3Ws1bi3IXYcd+ z7VpO<=6wec(H8yGi;s}8-bg`{eb|F1J%w2;7H)F1K$Sxd*G{p z*F5dxc@uCK{eCy_R-T`I#`)hr0EL(T3j7lARnNNIyAa^t09D@&$G!g_1gf782vXlt z;On{H3NpSGcmSyRJPQOBqi+D!k3}aPfARq?4{&>c$AGs{t_P_8{R{9W;Dl2?|MkEs z?$-j<&N<-wfxiV*{ofDp-+-^+{uLmd-oF|+8dwdy0eC-9<-Y(t1AGKH7C7lSpXbFu z@r{RoZwEdW?vDdC?q3DI4)|^0n}B}<+z8a<{Q_VU@B!fKpLe;w7Y0N)Q2`v&kF z@UMaEdZOqa;6oQF1N<6rDlm7+?a`-!4|4yu%kJ-34*UZ5{{hsxeV)!~es%%>0C)iS z2H?^!`+BSf>i!H+<$ejMdHou21n_%6y?^sBx?VH_IEwp`z}Exs0e%{o0oDO80{ejR zSKuAM*L>CK;unCLr)|J%f%AUJ@vsh9%l+qo`tBr9?d?E`oCG`y6n^|UQ26stz#D<@ z{T1)$OyDcHZv{>OwgV>uj{{?15%_B0tA5q%xfXbo`}YCo0>2K-0^?tExw{;w_5Nkx zCtgMyzwY+V!@uGB@B|j~Gra!;;QN8MeBJ5n0bmRFZ~RS{BVPobS!@O*QC`+&Fc{Au7cU_WpwuOhMSo@|Hbfo15opo z{Hd?w!p&UZyD57J_|foe4)@>T_g`@pxnAJf#HBykLqEj@i!j^y=YY3zufMTC`L*;{ z>md3Ra0b^7t~YW0HP?G6^JU-u-#_CL z?abmm%V>YE<6rSd@r)nX6LkFmn*$Vhmh0y$?)CE~>N!&J>>lpl$Njgs{+&yHBK=+A z%JTc;z;|)o%9Z@d2k_BQPS1qxP_gvrSih2H7;1;e$T%Qczy|&`}$vhv) z^%<@@uG@Ln1$-OuNuX%;+gv?do4G_g`n#F;2Y??0imt}%A%Bl>Nza+imHd4@{20Nr z+xY!CuK&%oH9UVG&tD&Y|4o3Cc{YaYZ@CwpeVpH)=6WNS{5{oNPw`wduD@UBdL@^5 z*Xww98aNv`3b>0a`5VVG{k@y(@9dZV^R@8%LdCNJzgKhpLU^_WxQFX^x&DFc8(h<< z?>4Td`Ms1&e~&wez6V^ub&=}I)08zyysq^{?2l}mEYe4z90Az zF6qvF+^^&s#c%!n5!W`ZU)2qNU*ejo^1$(-3_nc|TEPAP(M@>%Nq*kN?-t-YD#}WS zsH(Wn=^Os8;kw0s`9EI;JQ(iZN%=?lJuBP`e30u}p4W2S&Gk#%|1nnw*KDq%T*tWT zx!%g9znu>3-zWI@9b7-dwU+C4F8xXOc?)p6-C>gePjdZUxUU2+qihooBxj!sFM5H$ z%ynGPxqgFd0@s~ff5N4|-{gQU_bu-s%sN<)AHNfQWEBsi`bx(Lu3UDH2euv-h z1wIVCi|Y@DFzi$EF&-Ds^KgRV8*F5fj3wTDqx$fkC4Ddd# znCk@BOs>6L@8?>`wVz9Wd9ICIqq!#V-LC;Z&o!0nC z3v+F`mbzTrkZZ}c#TYjzW9f-qxvl+VgavJub9&EL<4Z=UZ|&#f4lho?M@=o1Cd>=xD6Z6>1t= z>T?fes_ETbxvZL}YuwE4XkL(O^WXR6)Lwhsl5JMCt!>%5_QtxLznt5iZO_HoLZPF% zRekiQ_ZE1j;n(Nds#o{HLEcSB;reHP#AD;BD0yd&Cdra z%0I`Je^Qy1)i?gL_Lf`5jj5e9iF(IR7&mrIR6B0`_**8`Mz!O|jT>J(_U5Sema&t@ zjG1_IG_G3LEnE}0CPuf6n>e=i=Gt1iJ7K~^3XQ*I;@D`?E#qz;bIXLYn_}K zKW<_sp4-vdnr~~5CWD@nGqXCH+8e8uu*AZv89wC&>bJM|nHVgpYinEp7B}ZXzCvSjYg6Ymm8SI9OqoW_>ArjGht{JGX_``9lSsQp4*U0qFy_FP-@ zk$hR+wTeEeGvkgLKr!D4hQ5M2#Y!*@$e5MRJq0YE2 z%Rh9#C6_b$%(f(br^fcig^+`PU!TtvT5fCyqiy=)1s#n|_C>zUh`O=K$oQss>7vHE zMbz68FQ9s6t*MhLRjeU{x3twzS8$a?1*5GS&4g zVU<`>h6M*T>e};djk!W~%*4jV!YGt$Xb5Ghqbc#6&h|y%Rx{&h%2f=xF5l9gWwb0r zt}VPS#7q&jc7TsdazY<}>kCCY)VH9KnWmrGaFkv9;%M#(KalKtB`{Vn6}(QAeS&5lwgPpjfc0#i>Z*_E!2WEv}KzM z@kjAxzRTGRBNy7N+>v<_!YFR8KozppI#*KxPwCb8*!H5J1 zx;h>?xwQ?due~`lO5Zh#88AXMRj7ENX>M$%k_F&h%GOmmV{WW7zTVOqFK)>%ZHd7@ zy2aE$9Q;5KF)!AwP`zr?iXySV%CuuHZNh4{aQ!b(vaBB>CICJcdd?bL=;Gz?hCh^*LM^JdMA z5u&ZgQBj;$E>m4&lv=Z>y}79ZzdNhr`@{G7)?8AUnsN_ShoWLpny@8}xusT_NmbRn zG`ApL&;}~z+HQgo(3)l%6wf!q>$H~QG-BQr-*pt6{Nuak&70$I+Zbe1ld#XHuCOTI z(Nxb6ortnjnXPX|ldztMi`C`D*1gs|%O0jN)ZkcWoLXIhBAf+k)iQ0lx$SLmosPC# z{k+^mFaV)3SS;jjZ)_@57xEo#bvZt1$W^!G+H2Yh?KT%6biA|?)(Srw!NU>IQ@b>n zd<&wWi3RIuSVW&_h5ukfph#eoV*MYCnUrJL zun-os042ftkjzaD($7lQs5eI2&dEhM1y+Q49NCo5FOHd|OvYsB$WfUL>*A8BDc{mC z-^H2fGV?Xd^lpB8XKOCLwc-spn@FuuED+Sy`LLEwRGIJ|RIa5hP5Ep+G}j74g`gyB z7eF|$nP`gfZl)&J*20@5@DsyE7*uXiwj*8g^3WTY-;M>&V0Us8NR)-;o}{-woWGL(>FXYU*bq)OY5CJYw&iTvTWSi zv4Eb(_1Siq6S8B96g`bJ=$nCt+VZR@h{n^l1Xoiz;f$drZtG~798Kw{Zxlx(%$-Ld zHD_V4ND%1)BG?K=vO2!UHBzx{O^ryZIhSooq&2*$HHZSecG7Fkc1oz~0Z1agHmr!r zdKD1qz&<1ZAT~*}vLfA(SHGAwdN@eGwPk9F3$(M;l!mhEORHd3n3+KpR7bbNz8bIv zTI!?Qa|Nm1h)rvPjwCB0vUbrz_Y(P(hq|*vxOfn!VX(;Gg&+*eh>4KmVu}fxTI6IS zl83fC^RPlKlXK?w4oUKCQ(_5dcu=TMrkH6WADxA_<(vbcTi(u-I5V#;yM*#nXNcse z8B||F8*TFw@`lhe_fLWACcI?n(xug%+2*EdmXTwJgY>d){Olo1Byan}-lgrrY8qRcodfHa2v$c^g4Xpb1$zxq2ol(cRRv z&qhJ7o8WL=t!bMpNIJGz4P-oB?ypv$m4*{UqPghkELnxsB#390@1}w z(--PnB|++i*jd4TSockMl^0wumQcc`SgYBbt6P+90dsiM!EMA%vED``PR;=)@(thA@kXuUkpAQ z2h*)nGcQ}qb%XA8b?TV6rtVFvRKv=Tv#A!1y@EDiN=wCSnn%So(P@Kh>cBiGMAKXe zLRdF8=b~x3I#W$z?8gb*p%m1^%R1w`;UI0IX+3PpoAn*kmTZ~z>#a;BlPwX>fK;31 zP1!Y2`P=w$g_FRPL+Ba(jInCcD%=Am+A&o?ye2p}3zA~H`3X!w4{;zgNJD^$!_(_A z7m)LlGeHx!32}Etm6`4=xvRK{!g6=8xC;STdG*$jg8-{UR7uTKh1UQdl}zI*cWhR+$4#0AiizOoz)0sXk(hQZWjPqy!iV zKpQs&f5c634vI6nzbURm?LgZ>N1>`_X3do~8ts%}>-t$fMmKLu+%HZ5ntwNMX|Dro z4!%W8%n_pvg5NO72V00Rl%nY^*#%M<8B!+Y`H(?b#@D$3sIEsSHKBE)&NrCUHnE>= zZ7d-67qnsK*DwK}l^Cyj5UvnPsenpKC8(ykx@>Eqqsb(z3^ix9(ey$=M4p%gf%p*0 zt>T}sTUngyyfnHX;lmPyeu>Y-=(2@Q2(sC*)My9dru>Ub7o>?X@X671NJjEohB!u; zYqg1GFY^Jr2V6FhP@ls%K-)nci!Wf}n|25irbvYl0Es099_)ZkV!jv?yD4b_^^dU_ z^0yd)U@Nz$t%&^#VNe{Jat&hgZqu427#d+{*e0}qBQ02`NEFvh#JSoU8y2<4i}FpV z6qSkustpJh1a>kkczE5Se7*p>32D^6JPoOI#RuUimASLA{jQD$NQ|jg9-^KZrY1Ep zy{2ra+Ym(xFr61Rf#7`9lwI0MzoO~E%H@YUQJf*6H!^KZa3E%02kkwcW%he?2c~OV zHh{Qx?Bw)kEk7I4I?U-)?`D?EJ5?x#jixJNhBLL)Q<#ngY?6mgw+ufp9d}U%cUN_D zeVH^SH{Phg;aiI5YJOk+w@f;rCws~)Kh)cei|Xq zoH2F!?77pc+Y@_9X39(NZN=yRJ^c++kfP5I?dE4>Q*476(u zz~<$@V7>!V*xaWG(&%o1u=0tTS%{|?AG_Tsstp|@pz{1gE}>;CHQQNK-iT6P$U8EY zYi>8u!F%(0NQ-oRzHHMZl?kKeuxXE%jFlR957T>9v>q`%(zZu26Agru5Pg$8AF5#Vz+KF^0=)%D6Q!-*EQuk>MMmw zB0pr@7i!8MR{pNS=BnywWVr(cSikAvh$#!`GM>*7@sdJ30=-cRUT#FP91;)(C+5Tx zR);Wd&er4os*zW|X3T^dGr@=G3pGw^1QCtVnd>ZvHN0-KP`%~(PDqELe>D;$@)Enz*p;Ez(NYHG{1<_nG3 zTAix&PUGs;(VZ5bu@%;DQ?Qv7oNSR7!LX{CIxSUR;iQH)xcg+HBWumHl9a@3a=SeU zY}{Ht+?v#XTvO@XO3n3h&*+aLPUwyJ*N_^hL~@A)55K9crXH9^73hy|nh1KKkVJP9 z&&kKhT;rl>l!*uPkY!R6H1(Pr&{3*Px0eG1t-sPv$VeHom$2MmjpNb_PO^mLnLu;2 zWSeBc<6dZLY=+XbQf@S$$m6h~Gae2T6(`+IU3#)bM4x3uGp3LU5;vX_EKOg4?{sZT zs;JVSLUky*t#XM=>1mTMLE4kLl9w(4E;gb{NKXNgI~vhPrT&El@~$d2QXLZ;G{qMp z1${LTb6Z&VJHZDvFGXRgl~NSXSd&+gZNPO}O`Pmb3+V+g)O67N%dcNBqN=nFvIRV1 zS_ufo{4ZjSI31d#g9=TEM!H510y}SnY2g5r7oF}3C5ieF-M~->2NI8htJ1c5*oN6Q zyrJHXv}tCF&}Z5%^GWoRHuLWJt7FZx{8YaxoF5g|judW1WH8p%58TFR{rEBRiQQ6m zDPn`Q<+HF%JVykU22F$^4Kpy*_%V}znB8Mf3pHhSKunbAC{Zg6S5svRGI#F6d4ovI z;sMTO-GRw8swskFkd|UANr(ZjHMr8gG>5S}IJ~2=SA?&A{Av|#Q)TKvJt|X9zWsWk zXBustT<)_;0v9lo6-tJ6W!>DA1knsCstf|Tf)2tPKUj)K9xP|rIQEErTZ8Dz)tKZA z(I^e`H4(iDcXzCoOIsc_DpL?`NNLK5*DLG{H*yOWZwMa8wz#2ji5?n0&0|?FKmBR|) zEuIvDbeJLt47qjr67ANf1=X1efXwlq2JT7`f-S-UQ5B$K1A2a=kHzsvccJ3-v@1XmMTsM5e%8(}arq@qbq3J1{Pm`&klTdo1~Q2IE0 zH*o0cXhw4u?}u5=n)k#SWR%%Na}WH_)e>0u zK5y?ZvRZMveK;PiDo4wgAbm@p1v6BrEDoFaK{X>H+thP0Lo-pxfrIi7g)mRto?T$- z39gjd4Y|mBY7go8?rz%m=t3vmxa!9c%>t9vyXYir-ph`WEqOL^}cWlJBl_mJNIG0nh zg}L|`I8-D)Anm6$mzOcTbdfJ+Fv?xKKo`z6DYFEWf!K{7${QtF8)rihM>AI@6B;p} zg1%{Q%eTN4aK?dWt>`C=&VG}PgwIrxJw)WZ{)NPDAz)lmh5W+yrLN_sE-(!#c#dGf zCXE7W%8_N1ahP{EKkTG`9y7s%-sxhQpw8kNNkRVLsi0ZQ;v;Br%y9dd6gnDAKH*mLhhWJ&m0?K+#y>JwvC^SR z=24o8``1O6JWHL~3U7leU;tf6Uv%O#TTnIVqmhl(;KZOuAS@VwmQhjpsOlK3hS~F< zV&_erXuIHTGE1`lMS75}$>hv7_RiRaB-dZtn`2{5VErb)$L|Qw3#8yZLPcn$$ z-UU-p6BmQiVs?1F6w7d(^SamcLgD4Kf0NTt+ z=wqg$Z^?YbAQkgt`7Y6{DYIwXF@5g5>c*C677JpTByIe}?lf{z47)(?4UEWjbX(Gp zaZ`wbhjW&)*NmaL$|Iqobq#SnB%)@|Qq+=HnXq!`R>52^i*mV4;(3FdI78hwvi;Pe zyDQxDz-QJwBqvKNcN4RO@K4QQX=HSw#qlm5BtDd2Vn`h}BL&a5`$D9>+c-SO!6P|V zB)-*D;}FK2Z*S(?8`&^}GXw*f7NXhcj{LKvu|cX2Sfm!q!3@Rd?Ai3b`&k%W9pB9?wJn8fxX?f8AXiOs1-7TI%xTLYIy(8O{YgrO0C@G?i z0tqo6WG~9GboS5Z`~8Y=*&Zsh6lkZH%FMj#KhqP&^{0wbS zVX`GKQI92p0yU<%mXnjhPg1QRK6r{H_{B-E%hgL}NEwIVo2*Tz;qrG(DTEczHD4Pn z?yko6xakSKij892 zWaMX|1EaORWno%FtGyf-2UumgVJ0*DqfQnhY4$()Xb^vhM`~4|aqoq{Q}@!WODi$u zDkbifT4Xbme4Wxkv$iFe+k*H#B29Y1C?|g{dP%eV z`}R(L=*ELc2);yi(p(&Nkw{E6w$){#xwyeCRFA-fKMCtRP%jZMnb*qljR&FhNS1yC zi52Abj*8}1X6O}$+*&|@eIyXG{GbV9%0E|;%4DRK>~d0+B;c>sTY-oMT)6dB9k}Wk z0E~fc7A9o;&e*0~H>vkL71<1lO!uK4{ltDWCOyovKj>|trVazA3LkY={u+@n>JART z_nVW~v_1MbW$x4&Go;SaJ@J_OMj~!1%04Hj;wboUHK;Vhc`!#{_B=~@P#H3p>dgy+ zNHjkd#XQ$0u$E{ZdJU2YKh8}|Yt!Pw^*qYO)#@-k@huvi;TfxDJ2Qs7@O&@hH%b0y z>SqzDFU>Zw*}xr$aO)%~WyoiyFVp)f^Lnsl0UrhS9ZQhWtPCoht`WX1LPDKYX_|O} zN!9?$-iwUb4ek=Uq4WY=O5|-Ju%Ve?%V-x=Xb2>)9W!RUL<)Gv2g2!4mpM3oSZ%&b zs&;|}@-TpFy(@zRkCvw_;Y|MAdnemJq;b|^wtHfesg_9q%=9{+UE`eT;Nwtp;_LF} zGOh6ZY@w=Q!Dmq$g6z}+%OjxWfS<}uMn~iiRA5HgJp^1Dv9;&e$FjUMi!bJ(qqm;H z6r6sAq$`Hg-a$DlREK9=D)Z4;pF;ZPV>j~B$|gGj6@c|!DVlWo9up1QMVYDKVOxT@ zBA+H7CWGo3gI+r;fWL*TOHe~IAyLZPX=F9n z0;o?2kcw>ICfqu_D{JtoonrK$;F@-@2gtLRE*4^Yj^b=+w03KPjcPf92Ec#c*Y4J06r*PmHY|t1`jK!i_1nw#Gb~ zkfzZ{d?`XxpMMxvlTd-?%vNXVeUqrGTWA*&@4>08&k`K4YFSp_Sy&)ciDKqfo77s~ zD09a2M_6sy%CGoD>bo%k;iL6J4HznB(KkJGEa9iQfQPFZq+k$iczX(qg;?H$kktgL z*^E}MpgAR&Qi}pvbV5id+mJLcOBt8oo;-2Pm@)oYkp7?qt17>`=>&?GNyP9tppqqF z;Og)`t8>YhaDsYiJc;1uGh|f@K{9-dQXD|Uz+p^u;=GiEND~|?pLE_Gn(l_nzFcoUfl){j+JJK3Bg6P;c*q9T)&3yc}3p8GPLe!?Oo zYaKe6Y%GCCpn!?9NExy+(*Id!Birx!&I7CJI7qGl3}SqsZ^i)h^>Q)N|%w8YgODBF%LhO zoJl(=r@!;OU=US!Fmo~m|MtMHb>6LHvG`VdM2-FzqSb=qGAY=xJDAm2_PKM{lm zgFT@@*am&2aM5#_EKs2BAxOzEX)(B6i782SVmg(4f)OcxJ-kh=3zL@ww}Oxis}3n! z6}ISgEVH>wd{bGacSI^5*egU)YK`{XY8~ycfW(_(Gk`zUJ>apl`9#`}GN%=c2Ygc- zL)bZ{oN*}i28)G8m_zHRbxsqSn88Bwz<7eaD`cc*eU!L$(oQ5}FRRNYHiif?(|lee zK%YA2tK-|XDbW=bIq$q=`*N8SQ0T1>4`g;PAFj}FE;lWV71(q`kyP%^(JEEmNnpA&Mqa znh)Ed#4FRB0J#&wpvjGIuq|~JuV1W=)WIYZd0mw^u0UXfs$Ak1~LQGtl``;$W}9`Z9OB zHEEE*D!p*J40N6F?Sue_R-9zei6BE+bv7v;-QlaWCKZhJJgK4jIqLNIkE2}u=` zZ(=FC1g%dxmWNR?8C1H5uq6uZgc{XUh_=eYz|rV)V~7!2jpik`S^1aMoM_Puwq44m zh9-mxc1Lhh`3@N*8ssajF-@k_HmVRPkoe?OmKKB+lt)?{8z8C{bmDLz4a2lY*LUUd zun=s>nn0T&O|2!zaWNRYZE^|0v!%7U6-<5AaVDrdX_Dm-KZcZ!d((l>3E|G@-d02e zeW`FhYLgfNQdxBAfdOMDabUo`1)@8XqfdB{J%RCDSB!IQ(I-5_6i;s<*pzRPSr~m{ zP|9Cq2DksqC?Tbg3!um>=-_9UXmI|!Zec@pC`~fCHcFYm4c^b8@<5;2rjm9TC-EqB zq2ZA^%nu94872fViZW`xc9?c^KF=OcYXwiVEw;2I2$9$hz%yf9%kqR0331r0#pxXT zK#xX|j~rb}aHu1(nS*N@ANEQ0+Cx^P;gT)Bdh2Pu(ni|lSC*hK=0yq;tKXs^qtls= z^uWST16IS1`$?)dr=mMZEX6z_Ua@kVM0bBo64-Y#6JFJv*^vb4u|X!zH4QSb(U?pR zMJX}IB19lIOEQLy%$POVMB47OG%;N*E~%R7dQ*EIri(5aW;p3&S#~hb=nSj_z4A01 zcd3QcQ5k7+ZH2U5GpaNpi-`Y-_LYjEWJ+l!o(oCrS2O4qG|Db33mNKBVgX~yxsSl# zfge}hA(FWK%&!BlXlBUD6o=$(V>Rmx`J1Wg8>VdLjR)iH9p>jY-U9LmOp-||{$M)M zQc3HqeuL17KUFOSzJ+F~yhu+ag4KCIrizRL`y$Teq(KCV+NXw6Az8Jm6lf)jx!tR5YHN3Rg!lIl!^WlRztOhe@&ie2O zm0ryIe$aESZ*2USvSO#0Lhfot^7XvI@d9D2Aq479WsQT}|H1Bz?#~r;aoh_$h$EsZ zvF{Gs5%QvkHjVNRhhmjWQe!?tUn%wR;amm*VNDKwol4uJgi_;F^d|GkrF=fpq}WCS zW$H@{4jC0M)y9DjTP|Wsm-4n~+6Lu=id*PmCL~f?K4zLuS@y1mg96f{lbpuLy_Mk{ zHrg70PHL}C2axEp35!va<_nbetWJUO700*)I##F3Ds0eRQB;#@8D_sR(danj4dbqq zzh)6xmD(FZra?GiXs8=P<-MEI;gei&oC+4fFyh2XgV0l2V-P*$iY-EUl9u2GEpj!^ zaRyQy@r=xraHfNMRd8!5;{on$2R(%C#&Tw92M26BJ%ouYlte>_M-> za&$^&n%uOhOQnuvB+Lw0W3Fjvyiz#>@#o{r4BMeq{$}X-E9(f`xsp%sv~5=}?bGBN zk3lDsZRu(i8-QvmTT4EfR^A=|(%MqaMRGD=WhK~E@eP$Nl&jMhytduGjm&d<&JKmq z*Fz^&c_UReuRrdT+Q&cQT-rCuVE&UyOv^_9>FO?k&QML!T=jtebvoa4=d zS~O2%c@V=`MK}u1P>)GQY+-Y-4siBxC{!}pLCA>}yC&@>vKH2tgJ3Q^JoW2qsW4qy zbh=Z(G*~PS5|k}0+Szkw%(Zk#KlY2qGI3HztVK$K?&{cMDu|XjIddR*^AacaRXQQ@ zSD&+esR02ivbQ~Qlf*mBQ1-zm9xiV-Xu)*)Dh)_fB{D>f1&iMHin;X=jDRF?Q70b` z+HX2D;cG(9${;nXBAqPIG(E|vyo4C!q@q;SHHz{?U8#_>Vvhagd7B-KiYkGM@8IFs~LVYNBQL%K38anCeN@wbBOk z*n+dnZZNSJ#l7yKcB2+D4afP&F_6iOsUBN>ONL~pOlEBL`0CnBhKIFdYB}h194DW~ zW5!G#H*WHnaq+$LrrNt{Gv>~_cixPdbLZbXcl!Lf(>`WTXUv{D^WJIG?f1+Xw;P-_ zcW(V+`;{mLRUS9-v-PU$n(OWD)fF=JBdkT`etn~o;j#WFElLnarebq(9Iq555u6;V@Hb5QI*#QGzJJYi@)?~<(55060T#u) zrlt_(Q=87B=0@gxn)E4DVLDwU#%h@=@&Gh3s#=HCCB%aM%wARtT{5vD`shUbA4t zc^D&!MTsX0)$9mtg&>l1DKQv;k);#{()XJn3!@O?XPex@D%-ok z(H6Al$7$5JWfziim1|#E^&kXjXEfPi8n7x;8h*^rm9tFVeOvA&SMne(#zI9W2t_I+ zRQ02Dq_U2sR7UP~739apxWwD3^H6O_I{e10eGfZVX4Y`qO*aMwFGTikR$z7ZBY}@((9jk0*(~-C$IublbDX)G^RHBBFr~QHID4}Eh zaLG}PU$BW=QEUJe`V>2Vl^u>S2(gC9=40e2Tz?G(zp2LM9e%ZTMr3|hn+1+W3xB6MjdTUQG#`IybDz`>Z?BCF8aywRQydkh+*Vh^RTfis(w^FlI~_lU2_iy zRFEDrtI*I`Uv+y&L!oM3esX-xoV%+$&6bs%20BcR@1H*9o~l`QS52D|-*xxoSu;NH zsk>)SzebzCs?dyD3gjW?+a||%+&gn-JbTKl>1-{WHD$)kk4%|1?Vjm#=iWw9&bWXR zSIy%f(iiDeYO;7TYc<=2s5fVZO_*FxSD@qNtpe;2(>zzn=ze(7{JZE%O}Vkjad>vk ztQoVWm#1WG^_Xj>de(5&JWiJ5Bm?3rHN-p`TRwYT(IDrGpo}hE==!dUp4p>gn%VX%8xC(H=mL!2db%KjX2wtDN{> z+P9X)??1ZCejM&S|4eb+f&LXN?4HW={!80Vl{PF3$L9~;%s0bb;y>PT|D}CheJ8t$ z8@Gc2rOlgJb}%X++qTQaeaA{WR`>RtW$7sp^a~bs@R9#uzwm0!&i+HkgmJEhQ0zxP zMvzRWFEauIyGNFRbrBwVhV`wjJp0eoBQe?JK>o ztnb)*#$4QdiltBob}jEe^8%IF@Z@k!|F;CTZe6U~i=W&tG8{Cj(w7eL+3>o&i$DDQ zev}?*Gx!Yb`2N1VCyST1s{tJe87iPmEFu{X1=)Pxba3VP=b4 zo-M9C+uO6lUonXTU5^$oJqmxTe9Le3IXS6cb9%n3c=)N_i@S>Jt}so^mnz(MESS>0 z=hykNq_%$lB}$z2iYS)>y-J6ktW>kj?=r*>XHFK@Lu=4^5E>F;(e<2?WGU0kb9US3~3v4x)ZpE|+<7h&CWl}>Ubf82la zyn20peR1>F;`tR}iA(2tit7&ccCYezD{WX^+_Du#0zX}G%_=pz`x!#k|^T`+CFac(QjqUzP%y*)j>m$nzreW~xj5%u`|`hneB zSOzALADZ;EivBCRDp1Z+>U`}64qX5lhMmT*#*8v)zHi%ei8eGRbr_|Ydy-M5HCu{X zclGt0DXlxKW|<~tt^dkuP4USMdc9?n1|pG^EH>yi_{@DrO3910my2so6FHeRGw#3q z7$c?9^jnej#V(Y4vwTc%#C&v)LmR~lXKB9l!sh;`)-d0yj@j9_UQ@PF_}hDFRcX!E z-k#$Se*ejn0r@RVQ`)z&xbBdB)$Qf|iB09&E@sfD3;t5<-X_E_DhSJc_JzK^JG=lx zL3}bZD5Z8Zzjsf=*w~dun5G^RC`Yk3m*J z#i%%CU$_#)!H;y#zKaUz(vWM-s?y_IoUBsDK*gYc|D{XLsUwyL-J`T|RbS8621ns=aJ%-oxMGq zydUs>k@{7R!qMsau~uQwn_e;)z|w<=|(xqfc?=@#4zokcg#? zCkOVfvXPoD1>*N@I?eY&YktEzjAor&xGf#LFtFknZS*~I7CP&{vZepf25ADWV?_hY zt`t{pl;*d(yR`3_{!?d4yEgHit7UK z%HCyR5-Lj)Q=Kn`#q|-#g&%%ee(Zchv+Zh@qqpfKJoL%zf9jF`4J*>g_Z19!%i-tx z&m7T&7%wh8*#(D$nYmFhuySMHrIV`1IB&@iU9%zd+jkt{9&{#K=_p-WtPF5DJt+g4 z1Ks-19O~O}QWFH{H;y^5?1kdVH8CgP8#Bm&s(e;ly{foocYN!R6Y))gtL@5D@sUdr z_D65e;i&igCOZe;WYDQ?{g+onq5CHf^=(-dZYqf;Dy~{tJb8gHA%(DJP8r_S2r}&J zKFaEp_I0BaM4(9D$(_Ub%)si+QE|;)WQZ?WX@}6?Dbr@F;vKA9Q8t(hjuKqJ;oQg^(jv&S;%b5GtZWvm9|CytuHRnQaTs0chwNyQo$#`LH zc*hV?Uf?XH&5xp7MJ#k_-vJGL=h=asXD~(Ov6Bl=PKZ&FoQK5=XU5i+_N|F}FYoVv zVFz|y|It+ly$Jr(cj-%smf+0S)vL(ugQ)LfH)br;DLXfS!RD?OF*SBsz5b`3q&KNi zD*@KMx3uYrzB5nwlsmp^TFed>mYIf(s)hjKxl3WDD^PCV;cm1#?*cY~Q_o92$evRj zedbp&Zz)1VKH;uWf>s;F!mjM8$6RK8;4*KQG2g{C&+5na-TlkIq#rw07dPzaJApO0QF4Coc|;tqf!E9amy(fVfkE_ z|67OD+pL~mrvAWWWso?7i~dv23);cadwbUR^=w2mz@btUyx1k|-gcnWwXE;?9(X+z zq_>YfI~&E!tta$ozFvEIan(JYm1J4}R z(hhVjmp7_g8k>b#bnrYAibKu$g2?jJIaE!wpwj*${i~nJNV%H=<y=LsidK+idPuPsu+mGB)7cFt7;=HeyILtv?=PEwe@c*y&*Uc`Q z;jl69MYZ=q>r(ULC)p<$dDIc}=yK4($;T(u)iV-b;TQ4k64lO}k?KQ(6Ii3Y7x%#K z5m_J)-4y-_-K|!>a|RFh9a#35SL2QJuYSIGdTVHkD-D~}B9Jmwm188?O> za2ft@BrowadBYL!Z9Jm1?o$7AhvJdRnewCJ5z_8PxG;}L;>eedlp8ey0b6=*c{&DH z5WM$JylGbCOFeDgJCg89DYD(tK75YUP~!ayjLf|1DN7AaBYQ$>A%+wm#f0#~|6w#e zS-w1XL)pjhvSx0YiCFA@3>u9yET&5!*EI>s|6~W-3*{X_0>E*P>K}z+*rDgC?ua%g z1%^@DY4a}NBvYR}?bamI;HItHwUm_N0YmPVDh8Qc^(gwp=d<4E52d`q!1aKK4;goJ z-+>d*-oW-NS`l+P>zn>l8%xiv#)Ta9Um-YhBwc)LcT3r+@!Wu`o;|NVSLo?sUMmlv z7iu^gpl2GrdGlCddEI(8n?PRW#7kuuv>2|EBKQeRSEsL-Va2^?aLCEWXpS*2PbE~Y zYTXQ5w~qNMZhjVXgxLy<@S~hSPX}NMy_c`3pMEU7`|z|(CkY|p4#%dEzBhVwapfB6 z7bvSMpC8zHLWceRCpcoB{_q^OQe3sMbo`JT_85n_v(Rbn)5sY?0E{rz+TGX3iZQ}e z3r9=AsivvMwsG&@vel>}nmZi9C-<14aFlwAYd5mysZt92M6K?fc#>3MUe`<_6T!#+uFW|*_u_kC3aHSPQ>2*2{&cqSMlVm)gi zYO`2h5(8jAOOF4cvE)zX`6#^?)?=>u*tMKmVr+zpYGPt4`b<8j?gPb(a#s%ufX7#@ zL*p~AwWJqof$u7vc^3=rIp8(H5ZpzWHsS{Rc4EZ{5uJ&G->Y`x4N!GYo*p>xyn1r# zMCtT4Iw_3ba=ibAb0}QJ6`O^8s!hY`KeeBAls|=u7+glY<>I!|n$6O6rGe|V|Kyjx zck#f$p3PcQ^AYu3e7bKt295#%j_alMD~nfFl-BPmJx}*G^<7xjw`Gg9b%GVdWr7oe zUOB1DcfN8N8n4vG9s)ia=_DFvX+O4v41wb2BSZ*B% zJN9A2sxmV$duC^GGo2Mqxxi7^5?4bIeTl@ITR!pKE8rvd(c%gz zuI?$GJKB5sss76sN(aS{;ta=lg=5~WXQ25B9M-G7Ib@2*;m6`?odi)Stg>-CcuC>n zsS6-<2*+8pUb+f|aquEvYbf^6rczOPzf~)ErkL`eB3{LT4bq!?@Cg(Ub5TnI4)>tq zvgZE}?N$;8r`8^oWP{kNGdHn~S#TU?k3{ahq}Vp(F5Y7ysxYX;_hj^oBZCwWOxohP=Md?z zV~V?jj=-HJEpdi2JNTq}FYbgQaCsCDKP?~AiKE4nXKANzTMs|Pc268t>>C?o^Sa*i z=%->p!E<4*7l_$w7FqQ@d$51qa%cc*c4YQWItP{9IK3H!RzEgA!9#dILV)%p&{pVG zAk3BLi^Of!MX_GkhTK|Eg4OKUyb&dYd>9Jh=-iL>&1U_s$U#!Bw{>O_acfrdT?ZEbZOqHV9JDEZSS<$6Hd!l=OJFt6W@1;#nxhOzH z(+G@-7ocrk#e|g#YhGTo5Iktbz1^s4T1!hkqCt73_Tdv-CrU97kGLykPLQW0_ppCR zkBS?ghbZ}^^7)Wkx#M~3a=nq z$#RpkshhgEadlt!Q+!1ny?9uj*2w1t2b&8P7iie`3Q%0e$#()*IfLUHAE>XaaI$NI z{#S2qo7cv?Wvaw#k(w(nO4068OW=8FhvgoatCN1{r@6es%AA&_lWesK$)>7mo$e_l!5@>bVJ zgjA=_dGIxa$16^wsW{+>^!dR@wA<=ngxJ&t{-MNyr%p?+>0k4V@+ivQ9HP7!dVSkB zU|-yt?#A--+Eb^U#ZV$xi}Xq8!Gg_^hoIHd1nU$+vpkA)DcteuT-SXGnogtKz`s#p z);=YVxqT?{A=Fk>N|jhpj~|{mqRF$6qfe5{jezj*CTCsACK?^%E-ETL29w+89)FK< zutWiEE!_t{@E#H{7>KmYi+jZX?34(iDdE(1EowNmJ(kM9_Y8?TOlfiJMUT&@XIqY9 zEBL|%)?>jLDO=ABIN;K{&h#6t(XeRgictN^5tC5G#ln7VTPK z$zrII4DJu;TX&ZD2{)D_G&1BJj|vY;TX#V#;U>Yl!C4Fv{@$?0o!U22-i!s9^(M-X z`npd!!Ep9qc+mh2-Cuun6CpfuXJPNzejJ!(bA`~_iuiUn# zAi0~2wEb^6xV@4AV3>_cdf+%8B<^!vu$ncZ8_{;?V<=(zl(X36jU%NeiYf1rgc!`> zwHFk!-X^kxj-1{_a2A*6mJD%MG)432jwbC<4h;@sPxd-}Prw=;4#CP9?mi%PFeHB(0y=iWMwCH**@zQREl$^XyKPLT2A z5PdDng{AO$()Y;~Lg-WH+-EST#?-5T{(yesC912d<+w~fE>|go(&hM|O1R-a=lr6Q zpo}swErtgQWMyK%Mx=f)hqW*&cFAjrowFkMIgYuP}+@xZ-NwaXEL5?;a=w6?nj-ECT3Ds|7s~%xYd}1kf}q%#7n&g6`4AN zw$lzfpj~qayLQA02eZSJN;q!U>~M!yQ0y@_%#W)td}m5vfbN(L9A+@hr>_`!-=X6Y z%NL#}XFN)kO{Qwl@$BeeWH%an1Zg!x7k49=$jZ4s@*~`(YaW^(ejIyDs`Q#2gUgqLkHZgS*A$g~6?~lJ zEGsK~__l1YT1T*B$fA>ig-8lIDU&%=5~3J`t0|woZr_isO}|(3VI6!shuiD}c`uTJJx31%1c; zhr*%9_o;}m3ctOj?pY) zBig0`k+umLctPnb+sG6-)SwJOD9MLuN%sjWZPVODuKA`MRMr_TH1ijsNx6N~w{KZ- zQ%`BjK1>T$+uhT*;;4G8IG{Dm@O*aeDIc^>>*N4Zo(^~xX744jgH)%k+y|ISVo6x>DgEKFwI~r9yox~;WE~<^l2BVE4&PctjFQ4?SdNIf7=V> zLm>B5xlteo>HUwc!N=sB$+riHzgvXC)m(}xFL4zyQ-vl5Ek2FQd6i~QD}X0X=u?8f zsq$@5l{S;4_at6?1v@;e8*DYPPt|G4h{TB`?COKXjms$NmNHf)Sy_ChPFd)lZ>*?Q z;K>~xDTn`nB5)ozf=t2cq9S2cS2=rGTevK;ZskFvEh%OT)$A3caTlORLGd}`Bj=$- z865)$O*Jx!u?AWS`=tjTi5|Q!9&FLKE>P8wnd|{Od+-!!YnDGud=00arT1^%=iAYU zOqMpD1J@B71PF@jl*z5J8yyDfa)C_%Y~|U?T-78QL3W}OENeZmdL8auCW>?vPX;D4 z7>P|8r*J2*gy(o4aYABWYAm?#kcy}nly|Cwc7~sTF5D#+O1=li2JD^Ch@*pv27PNu z{u)a~o(eeOBNC?IcC|!s*XgvfNj6)^5Bo_H*-Z7s94woNLrmbB!HHH2n(_aY^DZ6u6tUF_7jh5zoE%R6A%0Q*0@(4N&n`~{n4nw9fuP6N^Y*a}|mfFy_ zJmf4|hACHWW%0&1N7VkmSI(=8hjDtGaAVI*i}gBDYfiZ37OL|Gqaf!cuYx|#C zPF4tY!h0~>o%qu-;^D!CwNWbk1u5G7gypxcqnl~cT1GC`%j<)^Q{Lk8pBx#UNakU~ zCG@d_!zxzA6&^1&Y-$mm3wxLC&~Ts5l1WjKSMZfN@a+@E(qW;}` zO6w2wZ8}wa0*Av@4j0Fi9-KR-6P$BR{x8BrlY@_tja1=WaV90)aLS5S)yh+HlbtOt z7J<1%P}3N-?4{MKi<`Aw(48hO@j!DSPetel4ik@ti;R{P9aIzxTcs&&GV3_s!c`WO z6=H6E&yw1(OinD=g6)_mWkL*l%SK{EAgv6U#Ka4g8fMU)furoIU#k>}RlD7pq0vaJ zkoMrVn0@Jaj_HXYz2}egFJFNQM3V!1E)yy5KfS_)!a=QHntx}?B;%nrjXepfxCnPU z$dL(>L6BiG^lf^&@Ay_qx~9ZeBEn0nTrZ_6w@52%D{Ut!?*LC=N0>xD=k}F0ooJ7X zJaEd|@CcYU5yn}1^t6VWFmazJG76X{Esv++ZrV`VdZ%mQv(+csOoi`jtIi1$iSgh=G&VL49^k`Q&)l~s|73U$R%eM;1WS)Fh@9JnLKG8 zvCQH<93Jqj79+8^Q#H?<2$}#%m$siG{-MW&Gr!Lv7J6+)wlMsc!jxUuX*qeTE%vJ= zcJqxzG}kkzhNipr$2vt^-wnmfmvo5u)jk|_hByW62yr0m7F-C<;&pZwB4Yty=y8#r!_W?{v1X)>?jIkM(||W`4p&~;(VS;Z%z!c{X;LXmTo>t!)M2#XO9Q{ zhD}LKK^k*P;@m^6c+-W-y@oftzKo)SCg2Vg8mFqho;6IKMsw*(|2ej{YEO~$8}?jo zchBmSmvUx!u&7LDN)LQ-Re@_wJXJN@G5Ox=UFmklpUHM z15^8Pjt&ogB0D2Q9rC?1+g`BDW98-iSS|jS937r2>g;645j2~_z12g-5xN{T-0^_e zM6Te{NtVDL%M1#>hSbCDXXT(8Pz8HERGl51!u0b{1_&-vv|4kvF*T-1>43GwCx`zN zTYK{}E-+jR!E|A}`LMRA+|5FD&NmR6r=RC(%5IFxSw22|l(32LllMt_ttS%sj_yQC z@cpp1(kYPT#gPi0BX0@H2>0M>k@s1~4Jaw)D5=kr6*Uz`Za#U2k1yq*@YGl6b%#`O zFg@J+dEPGSsMHS$_gm3nlG>P_51yV*#oXz1aKdX04oiYAm#rjXKReHcv%=GPR(*bI zxb@yOkzjbPIE6wT-})klh9|Cp|Nk8vp3=xw!qme~4@X%V*me>FTj+xIWoOk0hwmucl6FME+J@LeKZlR0W2TV1-0RN;MEr%H;ss3)un$K06mb^Jf zH6g3vD7ASSge_cUusS^!yzB|@yZ9I(B-EzLTz`d@x8rSG8=3rg(L=$@a)vI(LtJ3~ zt&Rfsj;69GP=@EQ%M9>cw_Y%C(Bwc1#^S;ReU%_u7*Y8PoGX31dq{O6n2kt3zI-fl z*8EUahau33AxC!y&%4Od_HdOBz`4r@wy5H+9!ERJd#yZv4q|=rNI&%(7e`O`K-a;+ z=YD%|TSCXro+j66RHTHQ|2Y7>#t$<8|M&sm(rK=80(i+%K?4&u#WfOpQ|ZcchxL#! z1KP{bV`7w4Y&QEkS6PHm2{G%(4>=AT<%oQRn_~AT0&Np}WF8ET0w+)p;rQ)~90ut+U\n" "Language-Team: Chinese (Simplified) \n" @@ -51,17 +51,15 @@ msgid "" "`pull requests`__. If you're planning to write or edit the guide, please " "read the :ref:`style guide `." msgstr "" -"大部分关于 |PyPUG| 的工作都是在 `本项目的GitHub仓库`__ 进行的。要开始工作，请" -"查看`open issues`__ 和`pull requests`__ 的列表。如果你打算编写或编辑指南，请" -"阅读 :ref:`style guide `。" +"大部分关于 |PyPUG| 的工作都是在 `项目的GitHub存储库 `__ " +"进行的。要开始工作，请查看 `open issues`__ 和 `pull requests`__ 的列表。如果你打算编写或编辑指南，请阅读 :ref:`" +"style guide `。" #: ../source/contribute.rst:24 msgid "" "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of " "Conduct`__." -msgstr "" -"如果您想为 |PyPUG| 作出贡献，您应该遵守 PSF 的 `行为准则 (Code of " -"Conduct)`__ 。" +msgstr "如果您想为 |PyPUG| 作出贡献，您应该遵守 PSF 的 `行为准则 `__ 。" #: ../source/contribute.rst:31 msgid "Documentation types" @@ -86,8 +84,8 @@ msgid "" "goal. They are opinionated step-by-step guides. They do not include " "extraneous warnings or information. `example tutorial-style document`_." msgstr "" -"教程的重点是通过完成一个目标来教导读者新的概念。它们是有观点的分步指南。它们" -"不包括不相干的警告或信息。`示例教程式文件`_ 。" +"教程的重点是通过完成一个目标来教导读者新的概念。它们是有观点的分步指南。它们不包括不相干的警告或信息。`示例教程式文件 `_ 。" #: ../source/contribute.rst:47 ../source/guides/index.rst:2 msgid "Guides" @@ -102,10 +100,8 @@ msgid "" "accomplishing the task. :doc:`example guide-style document `." msgstr "" -"指南的重点是完成一项具体的任务，并可以假定有一定程度的前提知识。这类似于教" -"程，但有一个狭窄和明确的重点，并可以根据需要提供大量的注意事项和附加信息。他" -"们还可以讨论完成任务的多种方法。 :doc:`示例指南式文档`。" +"指南的重点是完成一项具体的任务，并可以假定有一定程度的前提知识。这类似于教程，但有一个狭窄和明确的重点，并可以根据需要提供大量的注意事项和附加信息。他们还" +"可以讨论完成任务的多种方法。 :doc:`示例指南式文档 `。" #: ../source/contribute.rst:56 ../source/discussions/index.rst:2 msgid "Discussions" @@ -534,7 +530,7 @@ msgstr "操作系统包装和安装程序" #: ../source/discussions/deploying-python-applications.rst:52 msgid "Windows" -msgstr "Windows系统" +msgstr "Windows 系统" #: ../source/discussions/deploying-python-applications.rst:61 msgid "Pynsist" @@ -636,7 +632,7 @@ msgid "" "It may also be known that project A follows semantic versioning, and that v2 " "of 'A' will indicate a break in compatibility, so it makes sense to not " "allow v2:" -msgstr "" +msgstr "也可能知道项目 A 遵循语义上的版本管理，而 'A' 的 v2 版将表明兼容性的中断，所以不允许v2版是有意义的：" #: ../source/discussions/install-requires-vs-requirements.rst:51 msgid "" @@ -645,6 +641,8 @@ msgid "" "dependencies of your dependencies). This is overly-restrictive, and " "prevents the user from gaining the benefit of dependency upgrades." msgstr "" +"使用 ``install_requires`` 将依赖关系固定在特定的版本上，或者指定子依赖关系（即您的依赖关系的依赖关系），都不是最佳做法。 " +"这是对用户的过度限制，使用户无法获得依赖性升级的好处。" #: ../source/discussions/install-requires-vs-requirements.rst:56 msgid "" @@ -823,7 +821,7 @@ msgstr "从 :term:`Eggs ` 安装" #: ../source/discussions/pip-vs-easy-install.rst:51 msgid "`pylauncher support`_" -msgstr "`pylauncher 支持`_" +msgstr "`pylauncher 支持 `_" #: ../source/discussions/pip-vs-easy-install.rst:51 msgid "Yes [1]_" @@ -875,6 +873,8 @@ msgid "" "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas " "the :term:`Wheel` format was introduced by :pep:`427` in 2012." msgstr "" +":term:`Egg` 格式是由 :ref:`setuptools` 在2004年引入的，而 :term:`Wheel` 格式是由 :pep:`427` " +"在2012年引入。" #: ../source/discussions/wheel-vs-egg.rst:14 msgid "" @@ -886,7 +886,7 @@ msgstr "" msgid "" "Here's a breakdown of the important differences between :term:`Wheel` and :" "term:`Egg`." -msgstr "下面是关于 :term: `Wheel` 和 :term: `Egg` 之间的重要区别。" +msgstr "下面是关于 :term:`Wheel` 和 :term:`Egg` 之间的重要区别。" #: ../source/discussions/wheel-vs-egg.rst:20 msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." @@ -1043,7 +1043,7 @@ msgstr "导入包" msgid "" "A Python module which can contain other modules or recursively, other " "packages." -msgstr "" +msgstr "一个Python模块，可以包含其他模块或递归地包含其他包。" #: ../source/glossary.rst:74 msgid "" @@ -1111,9 +1111,8 @@ msgid "" "term:`Releases `, and each release may comprise one or more :term:" "`distributions `." msgstr "" -"Python 项目必须具有独特且唯一的名称，这些名字可以在 :term:`PyPI ` 上注册。然后每个项目将包含一个或多个 :term:`发布" -"` ，每个版本可能包括一个或多个 :term:`套件 ` 上注册。" +"然后每个项目将包含一个或多个 :term:`发布 ` ，每个版本可能包括一个或多个 :term:`套件 ` 。" #: ../source/glossary.rst:115 @@ -1163,8 +1162,8 @@ msgid "" "Python community. It is open to all Python developers to consume and " "distribute their distributions." msgstr "" -"`PyPI `_ 是 Python 社区的默认 :term:`包索引 (Package " -"Index)` 。所有 Python 开发人员都可以使用和分发他们的发行版。" +"`PyPI `_ 是 Python 社区的默认 :term:`包索引 (Package Index) " +"` 。所有 Python 开发人员都可以使用和分发他们的发行版。" #: ../source/glossary.rst:145 msgid "pypi.org" @@ -1176,6 +1175,8 @@ msgid "" "Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi." "python.org``, in 2017. It is powered by :ref:`warehouse`." msgstr "" +"`pypi.org `_ 是 :term:`Python Package Index (PyPI)` " +"的域名。它在2017年取代了旧的索引域名， ``pypi.python.org`` ，并由 :ref:`warehouse` 提供支持。" #: ../source/glossary.rst:152 msgid "pyproject.toml" @@ -1424,10 +1425,12 @@ msgid "" "linehaul>`__ streams download logs from PyPI to `Google BigQuery`_ [#]_, " "where they are stored as a public dataset." msgstr "" +"作为替代方案，`Linehaul 项目`_ 将下载日志从 PyPI 流向 `" +"Google BigQuery`_ [#]_ ，在那里它们被存储为一个公共数据集。" #: ../source/guides/analyzing-pypi-package-downloads.rst:50 msgid "Getting set up" -msgstr "" +msgstr "开始设置" #: ../source/guides/analyzing-pypi-package-downloads.rst:52 msgid "" @@ -1438,20 +1441,27 @@ msgid "" "`__" msgstr "" +"为了使用 `Google BigQuery`_ 来查询 `公共PyPI下载统计数据集 `_ ，您需要一个 Google 账户，并在 Google Cloud Platform 上启用 BigQuery API 。" +"您可以每月运行高达 1TB 的查询 `使用 BigQuery 免费套餐，无需信用卡`__" #: ../source/guides/analyzing-pypi-package-downloads.rst:58 msgid "Navigate to the `BigQuery web UI`_." -msgstr "" +msgstr "导航到 `BigQuery 网页界面`_ 。" #: ../source/guides/analyzing-pypi-package-downloads.rst:59 msgid "Create a new project." -msgstr "" +msgstr "创建一个新的项目。" #: ../source/guides/analyzing-pypi-package-downloads.rst:60 msgid "" "Enable the `BigQuery API `__." msgstr "" +"启用`BigQuery API `__。" #: ../source/guides/analyzing-pypi-package-downloads.rst:63 msgid "" @@ -1459,6 +1469,8 @@ msgid "" "out the `BigQuery quickstart guide `__." msgstr "" +"关于如何开始使用 BigQuery 的更多详细说明，请查看`BigQuery 快速入门指南 `__ 。" #: ../source/guides/analyzing-pypi-package-downloads.rst:69 msgid "Data schema" @@ -1475,34 +1487,34 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 msgid "Column" -msgstr "" +msgstr "列" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 #: ../source/guides/using-manifest-in.rst:67 #: ../source/specifications/core-metadata.rst:185 msgid "Description" -msgstr "" +msgstr "描述" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 #: ../source/specifications/direct-url.rst:226 msgid "Examples" -msgstr "" +msgstr "例子" #: ../source/guides/analyzing-pypi-package-downloads.rst:80 msgid "timestamp" -msgstr "" +msgstr "时间戳 (timestamp)" #: ../source/guides/analyzing-pypi-package-downloads.rst:80 msgid "Date and time" -msgstr "" +msgstr "日期和时间 (Date and time)" #: ../source/guides/analyzing-pypi-package-downloads.rst:80 msgid "``2020-03-09 00:33:03 UTC``" -msgstr "" +msgstr "``2020-03-09 00:33:03 UTC``" #: ../source/guides/analyzing-pypi-package-downloads.rst:82 msgid "file.project" -msgstr "" +msgstr "file.project" #: ../source/guides/analyzing-pypi-package-downloads.rst:82 msgid "Project name" @@ -1510,19 +1522,19 @@ msgstr "项目名称" #: ../source/guides/analyzing-pypi-package-downloads.rst:82 msgid "``pipenv``, ``nose``" -msgstr "" +msgstr "``pipenv``, ``nose``" #: ../source/guides/analyzing-pypi-package-downloads.rst:84 msgid "file.version" -msgstr "" +msgstr "file.version" #: ../source/guides/analyzing-pypi-package-downloads.rst:84 msgid "Package version" -msgstr "" +msgstr "包版本" #: ../source/guides/analyzing-pypi-package-downloads.rst:84 msgid "``0.1.6``, ``1.4.2``" -msgstr "" +msgstr "``0.1.6``, ``1.4.2``" #: ../source/guides/analyzing-pypi-package-downloads.rst:86 msgid "details.installer.name" @@ -1567,7 +1579,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:102 msgid "Counting package downloads" -msgstr "" +msgstr "计算软件包的下载量" #: ../source/guides/analyzing-pypi-package-downloads.rst:104 msgid "" @@ -1584,7 +1596,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:121 msgid "26190085" -msgstr "" +msgstr "26190085" #: ../source/guides/analyzing-pypi-package-downloads.rst:124 msgid "" @@ -1594,7 +1606,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:142 msgid "24334215" -msgstr "" +msgstr "24334215" #: ../source/guides/analyzing-pypi-package-downloads.rst:146 msgid "Package downloads over time" @@ -1612,51 +1624,51 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:170 msgid "1956741" -msgstr "" +msgstr "1956741" #: ../source/guides/analyzing-pypi-package-downloads.rst:170 msgid "2018-01-01" -msgstr "" +msgstr "2018-01-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:172 msgid "2344692" -msgstr "" +msgstr "2344692" #: ../source/guides/analyzing-pypi-package-downloads.rst:172 msgid "2017-12-01" -msgstr "" +msgstr "2017-12-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:174 msgid "1730398" -msgstr "" +msgstr "1730398" #: ../source/guides/analyzing-pypi-package-downloads.rst:174 msgid "2017-11-01" -msgstr "" +msgstr "2017-11-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:176 msgid "2047310" -msgstr "" +msgstr "2047310" #: ../source/guides/analyzing-pypi-package-downloads.rst:176 msgid "2017-10-01" -msgstr "" +msgstr "2017-10-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:178 msgid "1744443" -msgstr "" +msgstr "1744443" #: ../source/guides/analyzing-pypi-package-downloads.rst:178 msgid "2017-09-01" -msgstr "" +msgstr "2017-09-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:180 msgid "1916952" -msgstr "" +msgstr "1916952" #: ../source/guides/analyzing-pypi-package-downloads.rst:180 msgid "2017-08-01" -msgstr "" +msgstr "2017-08-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:184 msgid "Python versions over time" @@ -1670,39 +1682,39 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:205 msgid "python" -msgstr "" +msgstr "python" #: ../source/guides/analyzing-pypi-package-downloads.rst:207 msgid "3.7" -msgstr "" +msgstr "3.7" #: ../source/guides/analyzing-pypi-package-downloads.rst:207 msgid "18051328726" -msgstr "" +msgstr "18051328726" #: ../source/guides/analyzing-pypi-package-downloads.rst:209 msgid "3.6" -msgstr "" +msgstr "3.6" #: ../source/guides/analyzing-pypi-package-downloads.rst:209 msgid "9635067203" -msgstr "" +msgstr "9635067203" #: ../source/guides/analyzing-pypi-package-downloads.rst:211 msgid "3.8" -msgstr "" +msgstr "3.8" #: ../source/guides/analyzing-pypi-package-downloads.rst:211 msgid "7781904681" -msgstr "" +msgstr "7781904681" #: ../source/guides/analyzing-pypi-package-downloads.rst:213 msgid "2.7" -msgstr "" +msgstr "2.7" #: ../source/guides/analyzing-pypi-package-downloads.rst:213 msgid "6381252241" -msgstr "" +msgstr "6381252241" #: ../source/guides/analyzing-pypi-package-downloads.rst:215 msgid "null" @@ -1710,15 +1722,15 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:215 msgid "2026630299" -msgstr "" +msgstr "2026630299" #: ../source/guides/analyzing-pypi-package-downloads.rst:217 msgid "3.5" -msgstr "" +msgstr "3.5" #: ../source/guides/analyzing-pypi-package-downloads.rst:217 msgid "1894153540" -msgstr "" +msgstr "1894153540" #: ../source/guides/analyzing-pypi-package-downloads.rst:221 msgid "Caveats" @@ -1735,17 +1747,17 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:231 msgid "Additional tools" -msgstr "" +msgstr "附加工具" #: ../source/guides/analyzing-pypi-package-downloads.rst:233 msgid "" "Besides using the BigQuery console, there are some additional tools which " "may be useful when analyzing download statistics." -msgstr "" +msgstr "除了使用 BigQuery 控制台，还有一些额外的工具，在分析下载统计数据时可能很有用。" #: ../source/guides/analyzing-pypi-package-downloads.rst:237 msgid "``google-cloud-bigquery``" -msgstr "" +msgstr "``google-cloud-bigquery``" #: ../source/guides/analyzing-pypi-package-downloads.rst:239 msgid "" @@ -1753,10 +1765,12 @@ msgid "" "programmatically via the BigQuery API and the `google-cloud-bigquery`_ " "project, the official Python client library for BigQuery." msgstr "" +"您也可以通过 BigQuery API 和 BigQuery 的官方 Python 客户端库 `google-cloud-bigquery`_ 项目，" +"以编程方式访问公共 PyPI 下载统计数据集。" #: ../source/guides/analyzing-pypi-package-downloads.rst:267 msgid "``pypinfo``" -msgstr "" +msgstr "``pypinfo``" #: ../source/guides/analyzing-pypi-package-downloads.rst:269 msgid "" @@ -1764,44 +1778,50 @@ msgid "" "can generate several useful queries. For example, you can query the total " "number of download for a package with the command ``pypinfo package_name``." msgstr "" +"`pypinfo`_ 是一个命令行工具，它提供对数据集的访问，并可以生成一些有用的查询。例如，你可以用 ``pypinfo package_name`` " +"命令来查询某个软件包的总下载次数。" #: ../source/guides/analyzing-pypi-package-downloads.rst:273 msgid "Install `pypinfo`_ using pip." -msgstr "" +msgstr "使用 pip 安装 `pypinfo`_ 。" #: ../source/guides/analyzing-pypi-package-downloads.rst:279 msgid "Usage:" -msgstr "" +msgstr "使用方法：" #: ../source/guides/analyzing-pypi-package-downloads.rst:295 msgid "``pandas-gbq``" -msgstr "" +msgstr "``pandas-gbq``" #: ../source/guides/analyzing-pypi-package-downloads.rst:297 msgid "" "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." -msgstr "" +msgstr "`pandas-gbq`_ 项目允许通过 `Pandas`_ 来访问查询结果。" #: ../source/guides/analyzing-pypi-package-downloads.rst:301 #: ../source/specifications/binary-distribution-format.rst:459 msgid "References" -msgstr "" +msgstr "参考" #: ../source/guides/analyzing-pypi-package-downloads.rst:303 msgid "" "`PyPI Download Counts deprecation email `__" msgstr "" +"`PyPI 下载计数的废弃电子邮件 `__" #: ../source/guides/analyzing-pypi-package-downloads.rst:304 msgid "" "`PyPI BigQuery dataset announcement email `__" msgstr "" +"`PyPI BigQuery 数据集公告邮件 `__" #: ../source/guides/creating-and-discovering-plugins.rst:3 msgid "Creating and discovering plugins" -msgstr "" +msgstr "创建和发现插件" #: ../source/guides/creating-and-discovering-plugins.rst:5 msgid "" @@ -1817,7 +1837,7 @@ msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:12 msgid "`Using naming convention`_." -msgstr "" +msgstr "`使用命名惯例 `_ 。" #: ../source/guides/creating-and-discovering-plugins.rst:13 msgid "`Using namespace packages`_." @@ -1991,7 +2011,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:29 msgid "Install \"twine\" [1]_:" -msgstr "" +msgstr "安装 \"twine\" [1]_:" #: ../source/guides/distributing-packages-using-setuptools.rst:43 msgid "" @@ -2002,11 +2022,11 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:49 msgid "Configuring your project" -msgstr "" +msgstr "配置您的项目" #: ../source/guides/distributing-packages-using-setuptools.rst:53 msgid "Initial files" -msgstr "" +msgstr "初始文件" #: ../source/guides/distributing-packages-using-setuptools.rst:58 msgid "" @@ -2015,10 +2035,13 @@ msgid "" "pypa/sampleproject/blob/master/setup.py>`_ in the `PyPA sample project " "`_." msgstr "" +"最重要的文件是 :file:`setup.py` ，它存在于您项目目录的根部。如果您想有一个例子作为参考，请参阅 `PyPA 样本项目 " +"`_ 的 `setup.py `_ 。" #: ../source/guides/distributing-packages-using-setuptools.rst:63 msgid ":file:`setup.py` serves two primary functions:" -msgstr "" +msgstr ":file:`setup.py` 有主要有两个功能：" #: ../source/guides/distributing-packages-using-setuptools.rst:65 msgid "" @@ -2046,7 +2069,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:86 msgid "README.rst / README.md" -msgstr "" +msgstr "README.rst / README.md" #: ../source/guides/distributing-packages-using-setuptools.rst:88 msgid "" @@ -2057,6 +2080,10 @@ msgid "" "projects/markdown/>`_ are supported as well (look at ``setup()``'s :ref:" "`long_description_content_type ` argument)." msgstr "" +"所有项目都应该包含一个涵盖项目目标的 readme 文件。最常见的格式是带有 \"rst \" 扩展名的 `reStructuredText " +"`_ ，尽管这不是必须的；同时也支持 `Markdown " +"`_ 的多种变体（请看 ``setup()`` 的 " +":ref:`long_description_content_type ` 参数）。" #: ../source/guides/distributing-packages-using-setuptools.rst:95 msgid "" @@ -2064,6 +2091,8 @@ msgid "" "master/README.md>`_ from the `PyPA sample project `_." msgstr "" +"有关示例，请参阅来自` PyPA样本项目 `_ 的 `README.md " +"`_ 。" #: ../source/guides/distributing-packages-using-setuptools.rst:99 msgid "" @@ -2078,7 +2107,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:108 msgid "MANIFEST.in" -msgstr "" +msgstr "MANIFEST.in" #: ../source/guides/distributing-packages-using-setuptools.rst:110 msgid "" @@ -2102,7 +2131,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:122 msgid "LICENSE.txt" -msgstr "" +msgstr "LICENSE.txt" #: ../source/guides/distributing-packages-using-setuptools.rst:124 msgid "" @@ -2113,6 +2142,8 @@ msgid "" "as `GitHub's Choose a License `_ or consult a " "lawyer." msgstr "" +"每个软件包都应该包括一个详细说明发行条款的许可证文件。在许多司法管辖区，没有明确许可证的软件包不能被版权持有人以外的任何人合法使用或分发。如果您不确定选择" +"哪种许可证，你可以使用诸如 `GitHub 的选择许可证 `_ 等资源，或者咨询律师。" #: ../source/guides/distributing-packages-using-setuptools.rst:130 msgid "" @@ -2120,6 +2151,9 @@ msgid "" "blob/master/LICENSE.txt>`_ from the `PyPA sample project `_." msgstr "" +"有关示例，请参阅 `PyPA 示例项目 `_ 中的 `" +"LICENSE.txt `" +"_ 。" #: ../source/guides/distributing-packages-using-setuptools.rst:135 msgid "" @@ -2138,10 +2172,12 @@ msgid "" "master/src/sample>`_ package that's included in the `PyPA sample project " "`_." msgstr "" +"有关示例，请参阅 `PyPA 示例项目 `_ 中包含的 `sample " +"`_ 。" #: ../source/guides/distributing-packages-using-setuptools.rst:149 msgid "setup() args" -msgstr "" +msgstr "setup() 参数" #: ../source/guides/distributing-packages-using-setuptools.rst:151 msgid "" @@ -2177,7 +2213,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:176 msgid "Start & end with an ASCII letter or digit." -msgstr "" +msgstr "以一个 ASCII 字母或数字开始和结束。" #: ../source/guides/distributing-packages-using-setuptools.rst:178 msgid "" @@ -2190,7 +2226,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:190 #: ../source/specifications/binary-distribution-format.rst:127 msgid "version" -msgstr "" +msgstr "版本" #: ../source/guides/distributing-packages-using-setuptools.rst:196 msgid "" @@ -2221,11 +2257,11 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:214 msgid "description" -msgstr "" +msgstr "描述 (description)" #: ../source/guides/distributing-packages-using-setuptools.rst:222 msgid "Give a short and long description for your project." -msgstr "" +msgstr "为您的项目提供一个简短和长的描述。" #: ../source/guides/distributing-packages-using-setuptools.rst:224 msgid "" @@ -2258,7 +2294,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:245 msgid "url" -msgstr "" +msgstr "网址 (url)" #: ../source/guides/distributing-packages-using-setuptools.rst:252 msgid "Give a homepage URL for your project." @@ -2266,7 +2302,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:256 msgid "author" -msgstr "" +msgstr "作者 (author)" #: ../source/guides/distributing-packages-using-setuptools.rst:263 msgid "Provide details about the author." @@ -2696,7 +2732,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:644 msgid "Local version identifiers" -msgstr "" +msgstr "本地版本标识符" #: ../source/guides/distributing-packages-using-setuptools.rst:646 msgid "" @@ -2716,7 +2752,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:661 msgid "Working in \"development mode\"" -msgstr "" +msgstr "在 「开发模式」(development mode) 下工作" #: ../source/guides/distributing-packages-using-setuptools.rst:663 msgid "" @@ -2727,7 +2763,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:667 msgid "Assuming you're in the root of your project directory, then run:" -msgstr "" +msgstr "假设您现在在您的项目目录的根部，然后运行：" #: ../source/guides/distributing-packages-using-setuptools.rst:674 msgid "" @@ -3658,16 +3694,16 @@ msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:21 msgid "pipx only works with Python 3.6+." -msgstr "" +msgstr "pipx 只适用于 Python 3.6 以上版本。" #: ../source/guides/installing-stand-alone-command-line-tools.rst:23 msgid "``pipx`` is installed with ``pip``:" -msgstr "" +msgstr "``pipx`` 是用 ``pip`` 安装的：" #: ../source/guides/installing-stand-alone-command-line-tools.rst:30 msgid "" "You may need to restart your terminal for the path updates to take effect." -msgstr "" +msgstr "您可能需要重新启动您的终端以使路径更新生效。" #: ../source/guides/installing-stand-alone-command-line-tools.rst:32 msgid "" @@ -3678,21 +3714,21 @@ msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:39 #: ../source/guides/installing-stand-alone-command-line-tools.rst:100 msgid "For example" -msgstr "" +msgstr "例如" #: ../source/guides/installing-stand-alone-command-line-tools.rst:59 msgid "" "To see a list of packages installed with pipx and which CLI applications are " "available, use ``pipx list``." -msgstr "" +msgstr "要查看用 pipx 安装的软件包列表，以及哪些命令行界面 (CLI) 应用程序可用，请使用``pipx list``。" #: ../source/guides/installing-stand-alone-command-line-tools.rst:79 msgid "To upgrade or uninstall the package" -msgstr "" +msgstr "要升级或卸载软件包" #: ../source/guides/installing-stand-alone-command-line-tools.rst:86 msgid "``pipx`` can be upgraded or uninstalled with pip" -msgstr "" +msgstr "``pipx`` 可以用 pip 升级或卸载" #: ../source/guides/installing-stand-alone-command-line-tools.rst:93 msgid "" @@ -3708,15 +3744,15 @@ msgstr "" msgid "" "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/" "pipx." -msgstr "" +msgstr "您可以在其主页上了解更多关于 ``pipx `` 的信息，https://github.com/pypa/pipx 。" #: ../source/guides/installing-using-linux-tools.rst:5 msgid "Installing pip/setuptools/wheel with Linux Package Managers" -msgstr "" +msgstr "用 Linux 软件包管理器安装 pip/setuptools/wheel" #: ../source/guides/installing-using-linux-tools.rst:8 msgid "2015-09-17" -msgstr "" +msgstr "2015-09-17" #: ../source/guides/installing-using-linux-tools.rst:11 msgid "" @@ -3752,11 +3788,11 @@ msgstr "" #: ../source/guides/installing-using-linux-tools.rst:32 msgid "Fedora" -msgstr "" +msgstr "Fedora" #: ../source/guides/installing-using-linux-tools.rst:34 msgid "Fedora 21:" -msgstr "" +msgstr "Fedora 21:" #: ../source/guides/installing-using-linux-tools.rst:36 #: ../source/guides/installing-using-linux-tools.rst:45 @@ -3764,19 +3800,19 @@ msgstr "" #: ../source/guides/installing-using-linux-tools.rst:138 #: ../source/guides/installing-using-linux-tools.rst:158 msgid "Python 2::" -msgstr "" +msgstr "Python 2::" #: ../source/guides/installing-using-linux-tools.rst:41 msgid "Python 3: ``sudo yum install python3 python3-wheel``" -msgstr "" +msgstr "Python 3: ``sudo yum install python3 python3-wheel``" #: ../source/guides/installing-using-linux-tools.rst:43 msgid "Fedora 22:" -msgstr "" +msgstr "Fedora 22:" #: ../source/guides/installing-using-linux-tools.rst:50 msgid "Python 3: ``sudo dnf install python3 python3-wheel``" -msgstr "" +msgstr "Python 3: ``sudo dnf install python3 python3-wheel``" #: ../source/guides/installing-using-linux-tools.rst:53 msgid "" @@ -3788,7 +3824,7 @@ msgstr "" #: ../source/guides/installing-using-linux-tools.rst:63 msgid "CentOS/RHEL" -msgstr "" +msgstr "CentOS/RHEL" #: ../source/guides/installing-using-linux-tools.rst:65 msgid "" @@ -4542,25 +4578,25 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:130 msgid "Downloading packages" -msgstr "" +msgstr "下载软件包" #: ../source/guides/migrating-to-pypi-org.rst:132 msgid "``pypi.org`` is the default host for downloading packages." -msgstr "" +msgstr "``pypi.org`` 是下载软件包的默认主机。" #: ../source/guides/migrating-to-pypi-org.rst:135 msgid "Managing published packages and releases" -msgstr "" +msgstr "管理已发布的软件包和版本" #: ../source/guides/migrating-to-pypi-org.rst:137 msgid "" "``pypi.org`` provides a fully functional interface for logged in users to " "manage their published packages and releases." -msgstr "" +msgstr "``pypi.org`` 为登录用户提供了一个全功能的界面来管理他们发布的软件包和版本。" #: ../source/guides/multi-version-installs.rst:5 msgid "Multi-version installs" -msgstr "" +msgstr "多版本安装" #: ../source/guides/multi-version-installs.rst:8 msgid "" @@ -4609,6 +4645,8 @@ msgid "" "Refer to the `pkg_resources documentation `__ for more details." msgstr "" +"有关更多详细信息，请参阅 `pkg_resources 文档 `__ 。" #: ../source/guides/packaging-binary-extensions.rst:5 msgid "Packaging binary extensions" @@ -4616,7 +4654,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:8 msgid "2013-12-08" -msgstr "" +msgstr "2013-12-08" #: ../source/guides/packaging-binary-extensions.rst:10 msgid "" @@ -4700,7 +4738,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:71 msgid "Disadvantages" -msgstr "" +msgstr "缺点" #: ../source/guides/packaging-binary-extensions.rst:73 msgid "" @@ -4974,7 +5012,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:271 msgid "For Python 2.7" -msgstr "" +msgstr "适用于 Python 2.7" #: ../source/guides/packaging-binary-extensions.rst:273 msgid "" @@ -5372,7 +5410,7 @@ msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 msgid "Let's begin! 🚀" -msgstr "" +msgstr "让我们开始吧！🚀" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 msgid "" @@ -5383,18 +5421,21 @@ msgid "" "the token list. **Don't close the page just yet — you won't see that token " "again.**" msgstr "" +"进入 https://pypi.org/manage/account/#api-tokens ，创建一个新的 `API token`_ 。如果您在 " +"PyPI 上已经有了项目，那么请将令牌的范围限制在该项目上。您可以把它叫做 ``GitHub Actions CI/CD — project-org/" +"project-repo``，以便在 token 列表中容易区分。**先不要关闭页面—您不会再次看到该标记。**" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 msgid "" "In a separate browser tab or window, go to the ``Settings`` tab of your " "target repository and then click on `Secrets`_ in the left sidebar." -msgstr "" +msgstr "在一个单独的浏览器标签或窗口中，进入你的目标存储库的 ``Settings`` 标签，然后点击左侧边栏的 `Secrets`_ 。" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 msgid "" "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from " "the first step." -msgstr "" +msgstr "创建一个名为 ``PYPI_API_TOKEN`` 的新 secret ，并复制粘贴第一步中的令牌。" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 msgid "" @@ -5406,21 +5447,21 @@ msgstr "" msgid "" "If you don't have a TestPyPI account, you'll need to create it. It's not the " "same as a regular PyPI account." -msgstr "" +msgstr "如果您没有 TestPyPI 账户，那么您就需要创建它。这和普通的 PyPI 账户不一样。" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 msgid "Creating a workflow definition" -msgstr "" +msgstr "创建一个工作流定义" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 msgid "" "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/" "workflows/`` directory of your repository." -msgstr "" +msgstr "GitHub CI/CD工作流程是在 YAML 文件中声明的，它们存储在您仓库的 ``.github/workflows/`` 目录下。" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." -msgstr "" +msgstr "让我们创建一个 ``.github/workflows/publish-to-test-pypi.yml`` 文件。" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 msgid "" @@ -5436,7 +5477,7 @@ msgstr "" msgid "" "Now, let's add initial setup for our job. It's a process that will execute " "commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" -msgstr "" +msgstr "现在，让我们为我们的工作添加初始设置。这是一个将执行我们以后定义的命令的过程。在本指南中，我们将使用 Ubuntu 18.04：" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 msgid "Checking out the project and building distributions" @@ -5450,7 +5491,7 @@ msgstr "" msgid "" "This will download your repository into the CI runner and then install and " "activate Python 3.7." -msgstr "" +msgstr "这将把您的仓库下载到 CI runner 中，然后安装并激活 Python 3.7。" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 msgid "" @@ -5467,15 +5508,15 @@ msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 msgid "So add this to the steps list:" -msgstr "" +msgstr "因此，将此加入到步骤列表中：" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 msgid "Publishing the distribution to PyPI and TestPyPI" -msgstr "" +msgstr "在 PyPI 和 TestPyPI 上发布发行版" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 msgid "Finally, add the following steps at the end:" -msgstr "" +msgstr "最后，在结尾添加以下步骤：" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 msgid "" @@ -5487,7 +5528,7 @@ msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 msgid "That's all, folks!" -msgstr "" +msgstr "就这些了，伙计们!" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 msgid "" @@ -5643,7 +5684,7 @@ msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:5 msgid "Supporting multiple Python versions" -msgstr "" +msgstr "支持多个 Python 版本" #: ../source/guides/supporting-multiple-python-versions.rst:37 msgid "" @@ -5695,12 +5736,15 @@ msgid "" "environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit " "while the macOS is 10.9.2 at the time of writing." msgstr "" +"`Travis CI `_ 提供了一个 Linux 和一个 macOS 环境。Linux 环境是 " +"Ubuntu 12.04 LTS 服务器版 64 位，而在撰写本文时 macOS 的版本是 10.9.2。" #: ../source/guides/supporting-multiple-python-versions.rst:69 msgid "" "`Appveyor `_ provides a Windows environment " "(Windows Server 2012)." msgstr "" +"`Appveyor `_ 提供一个 Windows 环境（Windows Server 2012）。" #: ../source/guides/supporting-multiple-python-versions.rst:80 msgid "" @@ -5708,6 +5752,8 @@ msgid "" "formatted file as specification for the instructions for testing. If any " "tests fail, the output log for that specific configuration can be inspected." msgstr "" +"`Travis CI`_ 和 Appveyor_ 都需要一个 `YAML `_ " +"格式的文件作为测试的说明规范。如果任何测试失败，可以检查该特定配置的输出日志。" #: ../source/guides/supporting-multiple-python-versions.rst:85 msgid "" @@ -6032,19 +6078,19 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:170 msgid "``DISTUTILS_USE_SDK``" -msgstr "" +msgstr "``DISTUTILS_USE_SDK``" #: ../source/guides/supporting-windows-using-appveyor.rst:171 msgid "``MSSdk``" -msgstr "" +msgstr "``MSSdk``" #: ../source/guides/supporting-windows-using-appveyor.rst:172 msgid "``INCLUDE``" -msgstr "" +msgstr "``INCLUDE``" #: ../source/guides/supporting-windows-using-appveyor.rst:173 msgid "``LIB``" -msgstr "" +msgstr "``LIB``" #: ../source/guides/supporting-windows-using-appveyor.rst:175 msgid "" @@ -6139,7 +6185,7 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:234 msgid "``appveyor-sample/build.cmd``" -msgstr "" +msgstr "``appveyor-sample/build.cmd``" #: ../source/guides/tool-recommendations.rst:5 msgid "Tool recommendations" @@ -6168,15 +6214,15 @@ msgstr "" #: ../source/guides/tool-recommendations.rst:20 msgid ":ref:`pip`" -msgstr "" +msgstr ":ref:`pip`" #: ../source/guides/tool-recommendations.rst:22 msgid "`pip-tools `_" -msgstr "" +msgstr "`pip-tools `_" #: ../source/guides/tool-recommendations.rst:24 msgid "`Poetry `_" -msgstr "" +msgstr "`Poetry `_" #: ../source/guides/tool-recommendations.rst:27 msgid "Installation tool recommendations" @@ -6391,7 +6437,7 @@ msgstr "" #: ../source/guides/using-manifest-in.rst:40 msgid ":file:`README`" -msgstr "" +msgstr ":file:`README`" #: ../source/guides/using-manifest-in.rst:41 msgid ":file:`README.txt`" @@ -6443,11 +6489,11 @@ msgstr "" #: ../source/guides/using-manifest-in.rst:67 msgid "Command" -msgstr "" +msgstr "命令" #: ../source/guides/using-manifest-in.rst:69 msgid ":samp:`include {pat1} {pat2} ...`" -msgstr "" +msgstr ":samp:`include {pat1} {pat2} ...`" #: ../source/guides/using-manifest-in.rst:69 msgid "Add all files matching any of the listed patterns" @@ -6655,8 +6701,8 @@ msgid "" "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. " "We happily accept any :doc:`contributions and feedback `. 😊" msgstr "" -"本指南由 `Python Packaging Authority ` 在 `GitHub`_ 上维护。我们很乐意接受任" -"何 :doc:`贡献和反馈 `。 😊" +"本指南由 `Python Packaging Authority`_ 在 `GitHub`_ 上维护。我们很乐意接受任何 :doc:`贡献和反馈 " +"`。 😊" #: ../source/index.rst:36 msgid "Get started" @@ -6666,7 +6712,7 @@ msgstr "开始" msgid "" "Essential tools and concepts for working within the Python development " "ecosystem are covered in our :doc:`tutorials/index` section:" -msgstr "" +msgstr "我们的 :doc:`tutorials/index` 部分介绍了在 Python 开发生态系统中工作的基本工具和概念：" #: ../source/index.rst:41 msgid "" @@ -6706,13 +6752,15 @@ msgstr "了解更多" #: ../source/index.rst:54 msgid "" "Beyond our :doc:`tutorials/index`, this guide has several other resources:" -msgstr "" +msgstr "除了我们的 :doc:`tutorials/index` ，本指南还有其他一些资源：" #: ../source/index.rst:56 msgid "" "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/" "installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." msgstr "" +":doc:`guides/index ` 部分用于排练，例如 :doc:`guides/installing-using-linux-tools ` 或 " +":doc:`guides/packaging-binary-extensions`。" #: ../source/index.rst:58 msgid "" @@ -6732,6 +6780,7 @@ msgid "" "Additionally, there is a list of :doc:`other projects ` " "maintained by members of the Python Packaging Authority." msgstr "" +"此外，还有一个 :doc:`其他项目 ` 的列表，由 Python Packaging Authority 的成员维护。" #: ../source/key_projects.rst:6 msgid "Project Summaries" @@ -6757,6 +6806,9 @@ msgid "" "github.com/pypa/bandersnatch>`__ | `PyPI `__" msgstr "" +"`Issues `__ | `GitHub " +"`__ | `PyPI `__" #: ../source/key_projects.rst:25 msgid "" @@ -6776,6 +6828,9 @@ msgid "" "pypa/build/issues>`__ | `GitHub `__ | `PyPI " "`__" msgstr "" +"`文档 `__ | `Issues `__ | `GitHub `__ | `PyPI " +"`__" #: ../source/key_projects.rst:42 msgid "" @@ -6785,7 +6840,7 @@ msgstr "" #: ../source/key_projects.rst:49 msgid "cibuildwheel" -msgstr "" +msgstr "cibuildwheel" #: ../source/key_projects.rst:51 msgid "" @@ -6795,6 +6850,11 @@ msgid "" "`Discussions `__ | " "`Discord #cibuildwheel `__" msgstr "" +"`文档 `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `" +"Discussions `__ | `Discord " +"#cibuildwheel `__" #: ../source/key_projects.rst:58 msgid "" @@ -6805,7 +6865,7 @@ msgstr "" #: ../source/key_projects.rst:64 msgid "distlib" -msgstr "" +msgstr "distlib" #: ../source/key_projects.rst:66 msgid "" @@ -7134,7 +7194,7 @@ msgstr "" #: ../source/key_projects.rst:324 msgid "Non-PyPA Projects" -msgstr "" +msgstr "非 PyPA 项目" #: ../source/key_projects.rst:329 msgid "bento" @@ -7927,19 +7987,19 @@ msgstr "" #: ../source/news.rst:133 msgid "January 2018" -msgstr "" +msgstr "2018年1月" #: ../source/news.rst:135 msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" -msgstr "" +msgstr "添加了一个指向 PyPI 分类器列表的链接。(:pr:`425`)" #: ../source/news.rst:136 msgid "Updated README.rst explanation. (:pr:`419`)" -msgstr "" +msgstr "更新了 README.rst 的解释。(:pr:`419`)" #: ../source/news.rst:139 msgid "December 2017" -msgstr "" +msgstr "2017年12月" #: ../source/news.rst:141 msgid "" @@ -12277,9 +12337,9 @@ msgid "" "`packaging-problems `_ " "repository on GitHub." msgstr "" -"如果您想了解更多的情况，或者只是不确定，请在 GitHub 上的 `packaging-problems " -"` 存储库中 `开一个新" -"的 issue `_ 。" +"如果您想了解更多的情况，或者只是不确定，请在 GitHub 上的 `packaging-problems `_ 存储库中 `开一个新的 issue `_ 。" #: ../source/tutorials/creating-documentation.rst:5 msgid "Creating Documentation" diff --git a/locales/zh_Hant/LC_MESSAGES/messages.mo b/locales/zh_Hant/LC_MESSAGES/messages.mo new file mode 100644 index 0000000000000000000000000000000000000000..9bcfaf222cc8cf133a68273e984f75539edf1de2 GIT binary patch literal 4208 zcmbtVTW}j!89qR{8Azc}u7#dHFlnb=*-1kQ%4Kk3C-F?2nAo8Wms%_7SXv_Os(V(J z1s%pt;@Gb3xM>raIIa^Xz9=}p#A%7+TX%J8od5s7|NH;{&yPKFnc>6neS*FpVeDDLkK!LbzXw(T{{R%gcYvP)20zBw*MSFt zF9Kfz((`-3uL6Gy{0#6^t=y9@xSh`r-7fvdcj{m z0G`77cm8vZmrufu0;KZ|Acc5n1}*@90^9|B6v2H9SPOg%81b91$-&*#4UXgj;psX zyDR+LS-oSIvSSDSSdGQ4xF&hZ&~%GytvqX_c}B%=%iyL^qdaMtf*U$dsgcuaOw(h$ zF>A%~Afbg#)zpOKae*x=zS2kvx=)Wu_o9fZ^QaMIHR-4(^oU>w(pn-)cUW=3V`(ia zc*2ONiA0ti$nuDxTc#FHTka0S-SkRhw(;cQS1Reg?JyzQQzBxCDEZfFBoao(-PYK2 zXuIU0g9dIiTKPdkkESD5sHG*q@Y@o)CEXwH_3)7{N7$|ltX7kew3M2mOIB+{(n)Mr zEiAc}O$o^klcSQ=>(YX&|;*2K5CZ(7{L`$0})+C(UVHD+}QKY_0Lo(nu5;Kz}OFiDEbh^eJ4>8cR9 z(qg(N5tqP>X2sW4i*q0}kqz)BL0ScQM>H!Ek87ueN&LB@gg$&be%3rW(87eSNGYKf zQqg)+H@%{Cxe5W9CXPW0GAk{S46qYaPimNG4@QkhFjVD6DXTVWO9^YbYGxJD4#~QL z1Os%;B^l1T2i(NOv^IL!DnvAl(!?&(4?WUFW=koNsOg<6O3@AqX%8_Dm9wS@++hw3!>$45O-FzMd-A%LYP$BUwX-OydSr4^{d!xPYP|Hs@;}|?L zbT#n|e>#;-sn1lLK+7>Lr9sBDsB$13lS;D@ zBgcac_0Rt3__4YQYJv*x)g_!Z%pgB>^5{{1tfrxk@2zX7sXzMtn%deEbxlqCu~mgY zhWduOO;UCQsw?~%qcme)1i6LstwL|q^gZabswsuF?_~2KW%uSjinCRiN}V1tT-os5 zVa=*&OhD-g<&a?}WsvJBcPaPn*n=)gZ}wI1sd!O2EOcruMA8dhRD4(9yMdibRJ2uW zo$k)exO3&q!0XvFD#!|v}|FI#(Qx;T8!x%!qp zK3sS(=5)^CC=S_!bA{yz``W$ISU-Lg7WO{Db5ZR&n#_BF&wwMmr4saiUZ5Af<5;99jCjubZep9`L;dV z!!go1+~FZu#YsG}d%H1!{?c)V+2_0L+4~HSVbwEccMfk{$V&MOrRf}Va@~dH-;~Ej z?a@Bw`&3wcP`s4?@Z*_N=xd|Jk!#M(P5472-k$9(-Fy?wU~Nwf!3H^1SbWvFJ!a3{ za;`5jdwi;VHgETwCzf+78*$T#dlQJhe0J6O)f{-^q4M>v;?-G-)t}yWM=x^0_kO@w z-yh=Tjs>D-_#BLvCOgZyJ{#n_mxIyLbf0r=qBzpW-#gar*Zbc;)`@DnXQ(um$8GP; z+r7L!H|_M~iudxRl{t?{&x9u?f2NmjUin&T(mnb!XZyg zrLMcAt-)WDezpwSQb&I&KU2#0Q2f(<_TX7~^M8zUN;G8bX4MmT@$Pc*?K{Y;m+(#7 z6v2AvA9|8+9@-FXVR6zKe66r{)gBxuPxLVo&$S6BH;>@G+F*qTv(Baa#lbaHtlc%` z%6{&gJu<*blY^j}ZDpNp+)U{l971VAWQFDB!s=yT_6oHxmzPR2^Y+!z;>;!c@?d$aAA3quH=R36-tymW zwCB6gKD-)}c#QLxs7?&Rd|J9jU8eaR>A z{6q;+Ihd9^yKV;?&4d+G>>8UUk21$IsgCw literal 0 HcmV?d00001 diff --git a/locales/zh_Hant/LC_MESSAGES/messages.po b/locales/zh_Hant/LC_MESSAGES/messages.po index a63941efd..a9f702612 100644 --- a/locales/zh_Hant/LC_MESSAGES/messages.po +++ b/locales/zh_Hant/LC_MESSAGES/messages.po @@ -1,14 +1,13 @@ # SOME DESCRIPTIVE TITLE. # Copyright (C) 2013–2020, PyPA # This file is distributed under the same license as the Python Packaging User Guide package. -# FIRST AUTHOR , YEAR. -# +# meowmeowmeowcat , 2021. msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-07-14 16:45+0000\n" +"PO-Revision-Date: 2021-07-20 10:34+0000\n" "Last-Translator: meowmeowmeowcat \n" "Language-Team: Chinese (Traditional) \n" @@ -52,6 +51,9 @@ msgid "" "`pull requests`__. If you're planning to write or edit the guide, please " "read the :ref:`style guide `." msgstr "" +"大部分關於 |PyPUG| 的工作都是在 `項目的 GitHub 倉庫 ` 進行的。要開始工作，" +"請查看 `open issues`__ 和 `pull requests`__ 的列表。如果你打算編寫或編輯指南，請閱讀 :ref:`風格指南 " +"`。" #: ../source/contribute.rst:24 msgid "" @@ -227,7 +229,7 @@ msgstr "觀眾" #: ../source/contribute.rst:148 msgid "The audience of this guide is anyone who uses Python with packages." -msgstr "" +msgstr "本指南的受眾是任何使用 Python 包的人。" #: ../source/contribute.rst:150 msgid "" @@ -442,11 +444,11 @@ msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:0 #: ../source/guides/supporting-windows-using-appveyor.rst:0 msgid "Last Reviewed" -msgstr "" +msgstr "上次審核" #: ../source/discussions/deploying-python-applications.rst:7 msgid "2014-11-11" -msgstr "" +msgstr "2014-11-11" #: ../source/discussions/deploying-python-applications.rst:11 #: ../source/discussions/install-requires-vs-requirements.rst:9 @@ -461,7 +463,7 @@ msgstr "" #: ../source/specifications/direct-url.rst:14 #: ../source/tutorials/installing-packages.rst:23 msgid "Contents" -msgstr "" +msgstr "内容" #: ../source/discussions/deploying-python-applications.rst:14 msgid "Overview" @@ -481,7 +483,7 @@ msgstr "" #: ../source/discussions/deploying-python-applications.rst:61 msgid "Pynsist" -msgstr "" +msgstr "Pynsist" #: ../source/discussions/deploying-python-applications.rst:63 msgid "" From e4755400e49642158eff7cbd29ad4921773ebab4 Mon Sep 17 00:00:00 2001 From: Rafael Fontenelle Date: Sun, 29 Aug 2021 18:15:37 +0200 Subject: [PATCH 0088/1072] Translated using Weblate (Portuguese (Brazil)) Currently translated at 17.5% (398 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 17.2% (392 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 9.5% (217 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 9.4% (215 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 7.0% (160 of 2271 strings) Co-authored-by: Rafael Fontenelle Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/pt_BR/ Translation: pypa/packaging.python.org --- locales/pt_BR/LC_MESSAGES/messages.mo | Bin 25213 -> 97978 bytes locales/pt_BR/LC_MESSAGES/messages.po | 827 ++++++++++++++++++++------ 2 files changed, 644 insertions(+), 183 deletions(-) diff --git a/locales/pt_BR/LC_MESSAGES/messages.mo b/locales/pt_BR/LC_MESSAGES/messages.mo index 7e9d050e3f69273b8c57ef47d4f4c863f4a4f52d..416058d85676c57187b6978c35fdcab16573f551 100644 GIT binary patch literal 97978 zcmdSC37i~Pb?;x}Kp?gu20~Z@q&x;|B&&Nitz+4s)s~TDp~c1+Q1?vt%(T_h-Si@9 z3~@|iAnarzKwb1;F<_*4zCM@Sz<48Bp!~2k>FQ zA9-AoTm;+*ydUt20QUxX5U6&J1J4Im!}(@_ec%sp{#oJoTLXMyfWH{v9Ra>I!1o6D zp#VPx)bl?V;GYBU&+*>|_%A>`=j#D}JHYcU_47XnRR7Ko@Sy>wz%PN9%Yaww_c7Y# z_$aW<@l)3)$%BC}1U?%0YT(ZTe-pTg>ke&5lCJ@O`Z93G`F<%$QjU*t^B-|MU~={V zubD`azXrY(_)49hOp*@(A2^jH&jEfCSOXrJ<{a?7zzb;SBf!^i{0Ezo@WMk$^7p{|()kqlHQ+;l z58`3E?r}itC-D9pzv)Tf0r+;H=JmBlpmE?^fVywp(Ij~!@N(dTf!6^wz6MZq^daEq zfu8{WAn^6axQBke1^94||M0lOuL2i2zVCJZ+!j#3p9YErUk223?gTy*_&dM{0lxrD zf&T~;e?0Jd_z(C<;Ew>ufTE`>fcpK$02hFNz;O?#>-N# zWDb}z=`@+#2J8X91bi>>NX7ATe%0x;2Nd1@V-!uQL7KLmVzIQ}(Y%JGMQ zj|F}ics20;UGC?(PXfN0;{}j(7w`xB$PmuI3#fU#KS;j<_-LTbH&D-C05-X906YQw z%hNueyO#OR?@s})2VQZr-?so%|9e33-7P@j_otr;UO0XM@ID;B>RIqG$FBxn!trZ= z0$c(=4E#;tM}d#x_uFoPHaNcHC!L;?TNx+k9|^pZ^Orx{`R6M@&F6mu)$j9u3f>1^ z1pHy(M&J~12T;#z12xW{2R;b+8ld>@?Z69x?+5-d&-n-t)Frpyh71EUsYOd<5_zF9a9B z5>R-#3Ah1xJMdA!j{(;K{~D-v9`GW+KLsA-cn9#lz!w1T4}2MrAttW^-obb-eldIr zJo^$K|D#{#Z)lm(wrKmwz!yp2+dDUI7mQKL&)9k_%r6jR9W(JOaGzRZeHO0Bamy{!8!} z_rDgnh2wAiuO#^jaMLe?XU_lF?XCwdfr*-&f7ENxxxnWGKLdQ|Ym?*v@GHPwTt9sW zbIb9mUxAi@9|P_M{?zM|iS0e$|^98}Q|K!k@I) zcnf&t_?EXO$$nsZ7qSd^6Hw#%d*BZNub{Ed0j~mT-cp3;QQ$OCeE2+|;Su<7j&BD( z4EP=(LrZ=SD7ssEo72~Azz1>sB48KzYT!eF4|=<|^ElvrIo<@k5I6&@1Fr%;4R{yu z2k8F=??5MU{KM~bI(i=PcR79?@DG6PcQMagx9iPx-@A2nf_g<%irvtym`I~@x z{^I+f5#Y0c8s}X=(amoIMKAvV6umzfb~k;&JAl0)zK4QvkJgAh_Z;Qt0b132{o?xX*&2mUF?_1|(n+V$Jsj}yR0 za{ie>$=hE9ieKLXR6jomd<5`|z#pQW{{(8DMn04zlfa9Bx^EZo0^s#P-9HEXIB*&G z=fK@(eV!ltVZZLO0Jj1)ue*V2_bEWlS0lhvK#ljOffoTk4-_8%9w_`g=y!ZR9tqTZ zj{@%l91E}nd;rH&KwbX?;Ddnsfts%yf$D!7sOR1WJRkV8KwbaKK=tblK+);DfV%EC zfTHV<0d?IU05$F}g!BIb)ck$}ct7BGfRe-a`v^48@!cOq#sU8c2x%ve`k1%-N#JRY zKM&l>^-ltcpXB)YpYY$WgE-f7JO_Lj@WsGOfNub5o<0r~p1us!bN@ZSZw7cD8oPk= z7XmfThXZxpB>`RrRKKUg?^^@h72v@DpB&&^fUN+R1H28Wc3&FcD}ch&YXW=|P|taL zfbS0Q{Q-UesQ!I0z)uGFC%|>*A)A4F`ThJ)g9q?*7&y-H;%9t5UkSXN`*@K0P%ejE63&hPu2+d(Hj@AC9M|HtLq zXMsyxfBXwRFK2-juKx`1ZJeL{qT6ME34AF1o%u7@lZXGp_0X4r(ihM9GCly;|HfY- zgE+qEul>2{SCH8pZ~q(TqxA2vkvaZ*AYDq{_7Cs~@cCcG9svFu@cF<`{9}^5g6od` zlhe^x8ProbU;CQdRUZWEIS>6;=ex)K8~x_@9l*Z@-VS^dzd!fi{W;_RH%aC>zW;x^ z-f90A^uzIW|BYM&&VJqPx)*=L>G2)FPtndNfL{W>@|(_or@!TX%yWREgX*_kFW&?d z9seuv(ZKV+sPXLv{t)mkAYD%03ltyTnT#Y0Jpb*$ALsZHOy;Q+q`)N}p|D1QA>l)w)IHv%66+yT4@cq34J(gdo1XMm3bzAT)7PkJ|L}cBOdfv>sNZLPa3uM4`hNr{e4K~#toAPeN*+xDo4|d* zp8&oS_%5AC2)_^bl>lFZk@gvmpUkAxfa@ObV4AgqjIlujqk)*@|GTk~ zD`L6>J zHOY5?peFf0mj9UjqCv*L`8q`~TXh5z|xe1_~b^0$vLIEKvII zo50I~51bw`{c#OY=Uc#s0B;4VpT7VUfBZ7=zR0n+0!2sffQZC*mv0#{JK;v)g&dy- zYP`1r@1|cb1xij|1Jc#r%YaNl@=D;3as2-6K0luYmN@=TAS9POZpQnwh2YJ_oWB|< zI=Ts{d3`qU<-pef_1w(_TZHdjK=J({pxS>jQ1sFV>i!o1%fLH;>i=heYVT{n9l!@( z;q&)I;0BIw0bT-pGw?Ftr+~uKe*+~iF1T{U?2`>Z$)#I?8vpZvp9cOMP<%f7c<2fE z;GItICwDpj?cMF;I|>wi4Sk*(b|m=^;Ol^zpI04*9)Nc~X(Tzr`L`W`FM#Whj#xbEoxm2yuRiAOJm9$V z^DWnnB$$NBSAa)>Z@zvc`3Ue^z&8Ou43gdfT)JT-*#~2!PXYftXW{8176*Ib3HVLN z73beut0U%Tlx9aPzIZF}823MT&gozQC_m*HK=HwIYa!T7-{67iY3S0tS415Fd{=km{)y`*t{{Z|lQ1buN z2=U(qj(0~)KYs%#eP8dP4}jDC5%ag-3;aC&d;Gx1^@!6W$xeR%Ht-3+C!F!;J{u@~ z_kN)G^!I?`+rI*8T*)&1r=3RvAIRY~H;*J&0&f87zE=V-0Nw@M2z)>A&wyV6V#*{R zd8YH_-OuvtJ{aJqfRYEF2ddq#0X1LW3Gl+7a5?)3pyu~xpya^|fx^#wfRbmw1r!~9 zG{8>=`1?TV*FOg8`o987uKr_yBe!_}9}3iSHvlC!wgPqiE};7LM4;r#Q-H!x6(~A8 z4b*kd1`1Cv2}=Vx=xdOm-{cm2JTkLU-svibfejwMfuf3N1?8+;_k zmiYV;p8+5JiI+7$(#@N7g1;;H{xf|3lJCF4=eSPt_ijEf=KLf0=-fB!k8BJ5iKh{%_P5@F#gl%RbJv7p0mPgAP4WLB zzDri@;`0zbl8>S_{goV;&Iw;LAo_uPjQ*a=_lNQQg}~Q@D}Em+9xVPH;9w`8Z}PdB z&lCB)h>vvH^Z4A!_c!s;-=!QE|Gpg#p38aZApK!Jm^?xJ*xz&c|1!QW0)GG~-8aJL z`F!Hvzw_l~@gTr1@bAO-1>i^cq}=l~KEKU(*@l122lh0(mak?H2uiN$?;U&|5T5g3 zo#6Xjg8bcw?~+T!zyBQ${vp8k0lyl)j{!f==P{u@olf;1e-oU0PB?#MfEROqFP~fZ z{2rf=@xg?%Kj{bk{S@#8e4fGgCxmm-Df;X4`Ex!u@!8IA&jx;$kN$pvk7Nz1+;VD? zztep5_Z2>f-sFowM7`Mgm^`7y4)0eCl`xAS=xAN_6ObCrEVPXT|1&uD179nSwnfZKtu<8xg& zzCFOBKuk6Jdk_B~3Ewe;l2>p%!RP6G?*Xp|J}&(JG>$Lk`@?`g0^ABb!spX`p33q6 z1^zgn3;F(JKD+r;`8^AmjT&$SQaa{=G~gU>cTr#OBsP=9aZa{BRprZe-6W__koUsxzLTJ!Bnx>WC1Yt??WoNU;zyW8&dO5OT=y<2b1 z)zgJ~tKMx7dd=kx8~Axoqc=C`^&0I~Z^MSP+O4PaZBEo{X}gtny6sbqTBEg)&b601 z-TGp^)oYxpr+P|vsoLkRv^v`!^wVnE>(u8O^NqQ*-|jT#%IW_3bh$lPM}s#Fdi}KD zT~<5&HXZ1vz5ZZ+KCQJ|^^Iw-UQcIg?YWuC_`;x3tM|qmty=v|MV-I8Ue)92nhqKZ zi_K*oUY(m8bgTXP3_aeNwgyYH^={gpPy36ymR{FS)muDrvCbn-x0>y0jR6c={a!lX zZ7-#>b#*1SLJ!(Yb=`k@u`#zu`*Y1ftv0sE24W4z<;lF8v=g zt6d%snamHG8sasY;@SFKl~d3{?D%4}$Ju%-n+C|Lnl@>t)~@$j>-tb?wUsvd>w4)z zyIs3HJ=$1mc;iMjYc{F-?rE#D)!N1Cy3vS}(UH1HwV$@COF~emTV=>|b^q}wQ^W{* zy}?pPv*~A#+o<52TD@Cp)dzjB1r0AZ>qeN@cN^RUX$zNKNVeX!^Yvuao)Lsqj_z_}8f|Tc#(bwr{7gOX#TeoiG zqD@=2O(xs7OmCjpvUO@=I&qdhR9ynyRp=}eSv&k2xGymU{%a}zdSwNAYcahdu9|S_ zGDuVfvxu)HbPzwV0}{=yXj=Qt!2-B8(ylgp*^Qh@Pgj@i!g^P7E3F~(MDj4*J{qc@ zsV;SzNTP;`EN62~Wp6MWJC;@|OUu$AK=jYl9}DT|64m;>1-oqIHaw(`zNo19eFVAZ-nIV!@gDK?{M} zIk|vLYL+3-?upQDMQue4q~iKDADA_q4n*~gtoZbqB9 z125F+#O$Ea1f|e-yR#-{#c3U^IEV>e`yN={0Qxr+2bLk3P6t%(UBH0b!T+F)i78^a z_|q7+R*DHILF-hhfv=k%HjayT_audA`e=L5MQ#qs;W3^xY8Q+$RqK5^pwupscuq4Q zV!<-4<~Uf*F6U;WXt^y^nGmFN7oMiUPW!avYCDCHWz2Q!ohFlyB~fpkYINHzV;m-& z*+h|CFL?<^p%rpmiNosYEE*@M3iVbxuF6TszYa;!Dbr?#P*dQtkmsB2 z(<12M@pb1GA>1Cy#8gSJ#?x|VdCtTJgmz4tpHZT+(IPH=i%JHH<>8si2#hIZ(o4r0 z<$9TxL+6no^)r~n<^aW+$2@0bj7ze@Jgm^flnrAVOF@HFCQr0G8l50ROanOxsqrV(ooZPz#IB4Ry3~)%&pkdrlk!GliV2v7(Xghc9 z4|1)yjLKYsteDt7hWDUrVr*#EZBXFGbXwbdE-dWBdk?1!VygyGr1@H-CfZnu8QBf- zx*>8nrwlhnVK&R=w3s!PGf+9baq?*=VuMJZis=wzw(5{k6FAO@qndVcG^JRA1UH1l zE5NwC#+>~foJ#f2`Z18!2Mgf%*b%#`Ml{%Us@s;$P& zbZmARV`~|UyEWgy-9l)m{pC*G%`U7iT>l>2E#+C}uJNhyW@EOCwKJaGRbK2bH7_Y5 z6uZ2?*u!qxsDZmQkm0T_Hu@$~UAP)QU>AT^x66ZcT%-4apzF1Ax|i>;fbolQ7tOf+ zDajo!l>F48Ul!vZKHtKuejDZsPGNckwTCgZii8o(s6yich<|$PmXesV*&sxa?%F0B$_{*kZhY>Q$M8~mWLEzQ1IEHAGWlT3o~zv=TL$C2My#sQ#ISFrr}3jT zfpD>!$CNF47di#6W>J#d_&g0(k;g$*7{vwuz@tl}ZUP-Q6RgFdes~SgCbn4ZUmSb0*U(i=7WfqDmn2HYUa`erjQ;6k@C#%L$tPR62%0&^6-)i94P zFBWA2`_Sdlnf(ar##Rho%;a(gO_De2fmyRtn3-CnKWln@fmIG#1O;`CJfS5GF!Vxm z877$fT{1D#*hWZ9d~R5tmeVm^7tFh5Jd0j?t|9N!ubNZvr&Sxr>a)Ar;kMrQ=!2*L zleg3)JS`t9*ik`?gdPqnjG1)z`0mRtGkxwCY)r4Ip2C6V;n%p%Oph%Sa5ts9_Rwm} zvJL$T#lp=62K}a643REc>*WOm0J3@!r-JzZtOcLP%Dwh_M~faBx|tizqVMCa#u>b( zbkBhU>DYqe$42sCv|wJ-$hq#n9y=6YV53~Vst<6k3EK0=`dACLdSSYYO67ZT_t>B} zFjQF@#OBmJ^Gc=T{=0{EI?Jh9=#|QPC*u&E>*babR4!^&MA(&_lX}pl8gpP5 zi4=^XDh$wO{u?9{a%bMgu8Tv*ba7_QuA!SW{xBCFzYDrZ4p<logv|v(+rw0E!p7)g^p12GDCu+h28j|9Y{h9$Z0>STM=O zY8F}REL$g6XdC4J3G0Mon-OFoqZrVvrw8{RE8%l1FQ)O&wVS9G7utlh+%70m*SQ0@ z@FbqF{6(8^v)-9P>w%I7h)<1SxUtN73MxWoa#@CLB|TN`Hq81@cakK*n`XXRnK`kC zNy+j}-^IIufZmtUcIFssP|>?= zcbUi0Kv1LN<kfbBoqeLI}y5*1zGxaka7)mV@?Qjd!A5APu?kG0}j*>kZ zGJMdTVV)bQhK*q~YPL*E1vYm{kp*I%YKP)eI|@g5 z5Jq-^YcowA0+hKx^4y5cK_T7iHlYTYUx|h$qsb&>r`Cujs>DFz=@QLYO(S<^v z1UZtW41ze`a}PwHNG;qh>`=l0kDJg71egcMg_Cv%^<<7`G|rvFTWPlgO?A^66K^bM z4R;%-6r|0D*=n~+a8tV_6Dw+sVQS^!9%nO`3kxgON`yfj_C!BsrOy(VlRH4l1;N0x z0zH`I6=Ith(#6Dp)4rk$-j=$GpV#g+2o4aA85UxpaD<>`ebx})CE{zAdB{R!swU#` zTv`U%=DAe!+N8Kc=3E_s=2t(NK8Eo#DmGthuJChR!vWmcxqWu zf@w&1b4(g@U8X;X*VvS19K$1J7GmI?R7iDrRNaQv)y$_$O3@K8HM)R2F-eCM2~ly7 z*Q$1Ui)2%oyIcxpl%krOycz@L4*!VA6?@#sNKj$kw`xSPQWzMj^No7f+K)sSwOk;^ zHH^)mGGYu&Gh}{4?gbPZboK__dAGk86|M4y3%bD~d>LQeK#p}d)h7M7b3hcq>;xs; zb}Hd!?j>^BdEZhS^)3ResjP$9R}?{+sxad-l0}qFP^na;2nfOwU57X;wn9NRkKSW7 zIh+_Z){b^(U;@!yh|QaRcRd}E9*l}GNg37d7&dj3G7XnRyMKqf!}>+EIV_t^ti@Cj z{9y#mY-A>jSSB=h#B;9b-eXA3p{~Lc3c^VtgYgorP@f^D%<8X9nM>MA%y(M|26ZOr ze5fanELzUCa6-O{CUZ5=Gu=zmno;}#Sdm*&UkkD*t}NNxzV7pRip ztW->fTSzNL73lG)M*Xz4?*=d}O90PyAxROZ>|+~hk$AbyDgg@jxyuT&uReC{u>UHS z2H!#Y6FnlIOZ+C-h)kk_aY}b9z7Z%(bmy(M5kSFsiu%JQ+0ymOE2CGS!nYSc#uVv>ABUl$;P@o z7oFxIsfdAoR}NOYCq-(xJx3Y@!7xvBd=?(IK1AG5#Nk(uTd)zT&!ewU#pybD9Ba1Q zCsijZV5Dx*bP;M6gNY0-M#|)YJGZDgMz5J}cS5`=ieQ_2QNPHXYL#fo%Y00C zguz;AlRDq?CkE7IhMZMeO0STDYPNgwp5xfmY;;B}h+_)J)T_HYnTT;^>w+Ulx6B;K z9oH~71c#g|3Zrd|xYU_Sx*<-xJQP)9sHUVZYL3#Uco6}xW29*b zaYHrA$;;6unrqVS+?`zIP02i_TZZJ|=6Ikx%y=&+3~+~@iAmW!`Yc3ttEXdBX|9dO zJfu{kJjOcjHW&_MG6$E(_(dkSzu)*UO`h8%uwE0a#Jz~bCkyJ{g$r`GdsS?}v`56? z|448k4ra)MIP6{}v0|_NmB~o$U}oU04iNajF~BW&7)YW}vB8u}5xSX?u_beZ8IgP2 znn;b#;(-M-Zpgn11uitG2%E?>Z@^s@lx&T1hJCblZcn`zV_MNe-)&SvbCMjcORj5l zMe^z1Lg|TIc2a%IH|xn(;}m5`)at!tXYLQ8y;?O&ERvlvf+fsj6_QK03IUV)B2{~l zBXeQBvhc1Mu2c|@6a?KRDi|M141FO42dq<|wsKXwEorx_vGAk;LJ1H2#!H^2QZf0M zVnV{MlJodNva;x4+8N9e`b*`qBJ>!lLc5lA&=s?!biCVH=^dO!>4MbFs(M4oXwAAZ zB+*{0rVA7dg3^Kp$?EqcW?=7=^<~^_nSHTLj=`9ii-msH?L}(fqJ4^GAM&MEtV&il z6p3qmWIe%Ljlm3R6s^zIlbxs96ibA}_&_yfGIt8~&E@on*Vs!uO615OQB`&rl1wYr zpGWf`kK94ex*ioPvuxERh7euA?5TiML0|;5($x9VfCao3TNGfW^@VO3?px?5W#Pq7 zc}2FP8bzqJ1w###lU=a$0;?NZwPY6s6=>o>-|9%D4$YB=mpMxtMj2WHP)Ki^5gLSo z!judacBR@~Bn5G2e34P5P)lrr;(ofZx`-l?TV;h)>WX7gDMGZ2{WQFYAlc>hOCIEP z6zRTaLGj10dX^RYYWN67n41}eZsv(zLnylJ@X>u3E0x_+8PMzQc8fx`z9QnuZZdEb zhb6lkU83nK7*XoNY;4diET}XLZOb^R&yCT22Jd`BB*}!n#kymu3(|~=vw{KVIr5?z z7mIpOss(E+goCYKMwLF7GktU>0ml7neJb0$;dOxj_7lMw9`tnxTimv`$6kO{nyn>gx} za*K0>4NA5&rh>Bu$}!JlXv6T$ENAqFtl^;{VnJhBFo<9elhhA{FaBlxq6#MvF&x6A ziHu$7&CGx&)#YeCjlzVKO~c6&gxL?e!OYHpL;YY`A+x<`d*{*J`}b4UM6Ok}thEN> z99TeBI##KiAeELOO(#lrVg>RzUykSXAeq$=D_@KiWY97erl06D{_9($ys_MIL zhK7j0Bzt1X?s9r9a<3~%q?66It%3?xLqXZ=SC6$a3kfDlT$EM(Zj!37Jj*exny=W) zLZm*Xo)8hu6_GDnp#^2h+d{PFx@AFrAWkU@V^onqn3`2(zBbiAw~<>{-#Zh<9xhO&F|q`*mAYkiO|s+`Ca zO2D3MG^+uT-D#;yu#fY`dC=i{O&lcgEsNjM+D^%k_(mmK(MuasErT-R-$*@9Q##%Q zB{Ha@S&IF@45}Vq1W4(57c#MhZ%$sqzgNWbys*Flo&iVYgld#zZ_D`?F05o~Xs4>i zW7*7{>!fl`#Q};)_sXn@!loa8Klx{+}g{yRduC%l#kDDWQ$SN(V z2A(ezBA}DK=CMVN2qA)4VXJy7QlS{779(&wLj#lSfVDBfV0Pv@n>(#plf+nN>_}Qd z+>#-%et3eUSD-Piz)nn~!0o0`?r%Zjz`br$OJ#l3jvbWB>%27&|6@H67h(wQEz z(+RCkvl$3fA3S7FjtLEwO0Wn+4JFYgk}_z(a(X>vO8YY&yf&JVyi@!OC8!lp>E?-v z^r~Gpv9?}xpRBo!G8h#V0fnMstJN)!4})>Kb--?qr$qO~|84KAaF9buT9 zBpEj>5%zHpk53)89fBTE{zwb^6 z*m3o2saAI`EaXy8qwJG1fxoko(HP_XAE1w@FoV74%#%Gh+IqH{u;gjgQWd6^?SOO) zJyO>=B;qJxJmWz~RjADv4Q7nOLqvbkyp38n-D&OZGD)X0wZMCk@p?Sa7Y$4LsuHQ! zUfD8rC+_%IDohR;ept~EjL}O>FQhuPiT(7{q(sTOo$FkMo|>}5T^tfrVRUOh(?S<6 z#Skm%s)|gdN@U8)`$cs7vT+utaEV2bqaHQY0R*gQM-`FdBFX0-O1`Wt4NCN9OJsjOROP3MUqv+w53u6XQzOdY(za4e7SE$lo#z z!-&xQ2?Hy=0VAPRj)0x*jk}Nqk83XQE+%ZZvz_js1RF#Tw;A7#tIf< z|Fm`y2+`>46`62>8O~th;#PdW&1%J}CRiQ7izfGGb~6GkTfIM%H*T`QMb3 z(TrqDlvFrXZc1a=7&(Tu4Gf!z9OP~f#HuZ`J%l0>VlDi+D2ypMH$s&8g)C5H zQesCD5HC?d)|2EF4VYTCke>}*3tz&$QXjYzlFQn2T&FV`I>5K7*yBPdc!(sc4Y$ z58|Y7{uo|jkFLo444YJBSl44)^5Mcn)oUlhH3bXJrpEA+&rMj4CgS@iEv(OS)U8=Hqhk2V4WwACH+o~Fe6o+oMpA@h{0-6dbTs;X(7A#}y z3H7~`=A*i3G6OfZY4_7{N=vzpFUu}-hkmDBsZ9(XMPg)xDreL?2|?(Q)f8tMsi^+Z zNZt!jMCODNlyZ7CyhsDA`WGU@A?=Y?c9uNvtgG)??2l_=MG=URXOjSO^gk+qcKu5AdjUsM^R0 zkwUQEVvLwK)|)K&jLe8T8D+WWYX)3CwPhn45ln8ATJxQkveG*noh(CRRHieOrds3& ziDFwih3aaJ1k4kT%9kP#Nn(=&EbMY5iD?iV99>Y&or^5TuBBSjHpzWsMXjbKx-?VWSfAm6r01!zQ7b%>$TKB2z13 zA*^*MNL!&+O+#)}b{!#cr+R7QEFu{lsZ;?;W4Un4ZnJ0(6Gl}0Fe-+;+DYY>>e~SE z-cBcvSsY1SW-+R!4{_0AwQt2!%(^mrlv^NFBIY4N6)&*76g!)Y=y&ndNdJ!Gu9Y-k zIZs>1Cnm??Cnbxdp{gakqw4H(zg}w3mpq7CivC?Gbg!hU(vtPBB#D64#Esqqs(HIL zd3lO(QT^W#K_@e)Jv#P?PvhWK=o!iDZDH9 z0Cnw&S{H?p{UI9*6zU#!p=crP2xMdZb*ffAXWvN_sh-o?wVEYwe;&<@V1f^N)Z3Vt zEyR>Hq*xEYE@Da?1k%h5GiAoicXOgPDv#_CZ_!vJzT7l*R-q!-t8+6O&!`*;*M*(p zPF_~}WNKStPzg)L3suaea!mXIq%A!PvKa%LH%JmDD2>r4Ub#BeTTP(f(-!%&6@?pv(O%TDl|m&g?|l zD|jvHy8Y_8J25Fi{&23|jo<9*5CDkhLIFkYKgC^F*1o`8E-o>6Wrd62G0_-vH)zG& zE{uT}3#E=(JrwkVGYZt`tGhE72&khoH;`Sv^Ot#E@L^G|j)31SGz zO2mjoIN9RU$hmOqh@OXCY!<4%s90ifmJRmip;jJ|wT`OoAR9cnBPdX)|WZ$Zw%t*54-Nrg@|4sPY)a$3=dCYfv*fjAmTY-^|^XNOC5AKhXto_e9_ zGr|;!D$F3M=%GG0LUkS_<*VyrGaK~)vt7+BK=HAA7>hPbrNw%)qm`}d7-3E!GxXNd zTGR?4FJiB%q7)CQ*jz{SN~S1UrNp=*SrXO%e=G#@G9#-i)$&Iz?L=P2Vk3=GX*np< z4M?}sHM3Di%#w^eotK4juVrwbXsaVI6Kc3s{dDY!R~=oS_(^P71-P^pMj9Fu2KUDn z@b$2nRalF8T&U)XlAw?RNe(EMe59^w>3YqMvLf(2LIm;T32-N?HRIf{>JTv%qP4{| z6zZcKwl#B?M}!^ZhqQ$=xq>7{!5$?cXss9r)bDg9)MXqkxf07a@~oK|-!5+KtHnC3 zSX?s7>!w}I#76yM3xmf(HpY%zAb`w5uiY`+jN?V;?3b)xgj|$Ua2;a4yBlLZ)3%G4 z@2CgoX}g;w^A=30gF038hsA7F7%nrU+#WS6494p;%3`k*QNSy~;Crn}7}ye?_>*&! z{|JxywkkuBOG~U9UYunyHsa0Dspdt7-MqAW?Kzzn(>@C#{2 z70ng~Q7_y1=;FaU8M_kHW)=)3MG++|x*pQl!iFQ1CNx?njRx@Tl#)0JuSurcrf1oD zFeuYBVj$Xld$150fQGFKL5T~WE|I^>Vm*$!MWZ#oVl*j1jmzYG5ec4v2Ax`FzVImI zw3L15q2w`gQP^P6HEoc-<)n~aOb#NQL?iVsUo8r$wG6iVpT)H4B1^A%I9O0grw8y+ z8rdSNVC3wHMFo~vI>&mpHHx;P445oWm@bNbkWpXg3EOW%j)*drT)>#QzCyo-4Wq&w zfS0U(LZ&Ykn^AN%TUZ~s6}w@LYr&0eZUKOf7^TK-W-w^h_fR1S^GSg_U4)-10l%n2 zFK_^lae<(6T2b{PERq6obL8-G@@D3G2C)^f5 zHo2=Hksw!39k!eS2_c_R)fm|65Hhk#BfBKsAz={Ab(I!Yw7ism8Bf`t0p;^TUSvRZ*m+dcY#qqMNaM|QQ*?rpNPXrNM zY7-Qgi!uKl0|8VNQbVqKu^13Cy+@h_)&-$57bvi$vV;vJh#g4GI4xHy(pZq=QU`Ss zs#=CS&-9sohpAMk35kTjzFDmhg@zI|!0awNW7wVs{|_S=18iSk+ck!Yj9qQ!Gxi5PP|fwcYDn$!W73aLq54 z{L2EjF-@i=vQ~tNf?PLS?XJ`0dIhitYBfe95bB`2cEwA^+ zb=7rGD{IpjEr2Q~*B&hx?3czdp<|M3wXwLYARG#Djixb+-4;_akZ)LMuC6IgrR0U7 zpz1z|uocHlrjlJz8#kMWYhe#GO;=HV<7BdFjcU4KLtuyv8_MafunT#J!G!6}3YmMP zib*GEchgL~hTW4XK`N|fDD+c_ZSUmD{K|$6G-4SRZJy6qf<%rCnkfQM=R2>5F{A0R zDWwIo0{K|gY!R_^0~c=CXrN2eNC}>Iv98V6r!Ga0H67}pT z=WWY2Sq*HwGU(5Et$X{6$d24LNXI1AB&EG#8_yH>4%{9(=toIBE6$Gxac#ir?8HQQOL=PRWnTD({P9f{CFPMDGW76cLh>rq znNc;TmACqBrV`Fk3&uGHHguW|g@Q3?G5a;l0wU%rH?<9}-TKn9Q|q7b%}|)KV|l%fc{tjg zvd|>OIq{L91T)y_@R;(j1U|W9Xqgd*Xslqu@f`&LIjSbnw3rMz5x17GC}oP~SqkQ_ z>X`FV{>(cF15h3}&ag{7nlai@;fEX0h+`{Iq0v}{bo%sZ`EFIpkSNWUI?vie1&1=& z+*Mjpbf@&heopiq~a5)yxD&*dxJ>K-Id4?qDe&W$0h={<*xQ zMcy2gGyKw1*-CU(QN=fl5gI#=$~u=NpRF9*XvbC%HOG z$J49^IyvI09y2%Gn-b%O;-GnUc~#n&tMD;I0AiEjO_MU;#Aznu$Xv>=*nh3C+vghF zCIvyq-GyC~sMC%(4)V0@T~fVJkFSPOpe2HAjZ)!zdenpd#0d&#{T&CxXH0>wIK_iA zxoJWzpP1GH*UI)00c*)n?uWw2_M0j&P(-dc?01Z*#yF+o0ki>5Es&0kkD_jy1*(VJcQ(g6k9)*^Lm3E9qvw{of~LC4nvd% zXk6@)5Z5nUr}8;sZoR@OzUBs=#~PSQoT=y&qOFX^c7+AIw(3;wsU9&$ji{HKL574k z@mAm@-MT!gG=CrIpB!cRM?E>J4GoDd^ChlDuq7Lsk8Ix?9az+_Zaey}S}83R6f1@p zNDTUV1V9d@voMq&{F7p^5^ga|f*Z-{(hsYs2~j--L2(&ei{To`LkQx-sSQJN)dnt7 zI4GW2TBlrTmogPe^rh+_4LT1on7wpkXbIrtS+**is^yW(jegdlM*x zzG-uda9%R`~?NqQ7{81-@eRP(ynQT3_V8 z;@wkLX@>1@-kXU7+h|AQl3a-Og;^}bGJMYGmX%|S=*)dwo>gn$gG$$#VVLoGAy|;5 z>>@oBAGC5TaV5^m^RpVALb!$PUS++;iXvN#forbUO_;plNp^Ww z|3q09&kFq$J_c;9Cu)#B5Y~c7)G`7|3FTyzT7=W=jWu8kvt*UX=68Gdlsph}3EUvc z3T<8Qixke?n!mn_w+MJMlT+T6N(IxgyL`eV6GS(}m%20rNKDS*quT4z=Bo|m59Y~n z*uIHEk5#N{!HC3emgBXs^orfZ6xZ_Apz6Pe0kZ-C#7|fUUJ#g}Ai&Ip8CgE&Q(*FE zJ!f4}98bVIW64NTp0i4lW86F=M0Fs}le4}%cWw_koofQ)dkoAYAXCL=GyeW6Ndoy? zK42L)crI4c;!;9kT+9th-MLbw#;(S{7ah{CV3f&9XBv!gB++Fd3*DiR7sEplX^n&Z z9GYxf;@e*pMqf^M=jYvPFx4dEaH)C|5QLoIG;4pg`D@bdRJxpFXY&Rmx z#;O`@-bK1hiKGh~tb>iXiP}bp%Jbryn4&G>&alS@6}pycGJ`1I;K^nyoQaA&WnYxK zu{`k>d!Yf1iit1;wZKJtd4&#IjaEJzUh87i(Jz!L3mJI?UDIgY42ISyb`eQ1-c_P8 zdxv2G%1qcz0?{OTlYh^zd$bX=s8RPzTIL&jG^tPHw>UoULAIIt~Gs8-m zHDS9smYl;wUJH)b8!t>%kX^ML4I?n#(Bt{R)}tUb_fg7IR#IW8^V(p@OaQNz7qMD7 zz4zXCw}rY%aIx!vE6!LTZtZJv93996nalm*he*I=&w($83@*cxX(hQ1*<~ce?bR(} zaBN4sqsU~vb;BW$6-J1hU`gCs`(|q9G@(2W|Eeav>2H$t=qGYp(dAJ7tJ@-3xvfl` z&tAF6CNc_1iB05o!8INev2YibxtZBc4EZgYejx zR$Evm8{%aIdU&s;_o6XH9w3lwuR<0aruQOk+=i$24fCw=|lP)WC&D#5CVC@YklX?20# zr>L?#ew_iG>rU;jpviN~_!hxqE!`J&{u$4)VtGhZD`D+8fRCqJlrU@0xgu+UmVxESjHiyY_$EHmamxQjB!cSO0nC`B1qVFNA$aF}Y zu`K$MN21~`t@I)|uZDGAV#h<=nUcm)(B3(2715`swozc0^8=cT*Pv`E2MrSI+I)j2 z#Jx>qgK#hl4lYiSI>-vii?~ESMs!uRq(#w%FzSqq5r4y-%y%MlVUaA%sPKHTlB1AP zGWW(eTDKH^sHF8*ZLf}2mF;?WO3}re%~CiB@JR)(_kKXl~;ZLvfS$b;w zXoNht2Orgo0h`p>O1a_~x=wD*TR6bm55BZ zSQi@1-4iER@YJVTLP09csC8pC?lK!Uqn_1RL@>v=;}GFx6zN+MuJz<#-K{x3L?Ux; z^`~(L$8*X>mzkV2vXzS{s>g#4S9qB~ENF^lNCcep?hz(lGR4Tv!&b(VAvkU(yY`c> z5YU-BNd=qMOJw0ONi~bf&4=(*@iq&(4d>`A90JKjBh0j!uQ3lCAf)+%4K#|Cu6QkO zu~H>0AQt7T9vRxPZ6j^vK^~oefATt1>9jb2^;SRx=O9G&j1>+tlW#ts@uRu^nc7w7 zlpTw85JFnedqF43@N}Mx9mzWpg%$H?@i>p-s7(t_nUD>(E^^mbbYbl}+Rfg`o*jz9 zq-3J06M`a;0&b>lLX7EQRGVmpKq05ZgYIiZlUJhUQ5B- zh|^sJk+YbUT5-Oz06^GFEVH}7c39tJCKkF!q@!Ycb`p}eVFtWmIIhyrGmCZ^n0crfGRII4HRo4=9a%@_-3fC%n1gS0=x0TaMT-Xp9 zcts9XarNWe3X>7ZKOE#br?TbIaobN?mNBxV0ijPKas#e;C^oZX*_f@K&KJM=1-u~tZq=S~9o-)89murtgxiSG_IY(}znWZ!{{eO)%w6Vq z2Bbmd)ONsTx`*n! zl|mhCiCoQGQ0xnvaP?XN%tTutAR>*1A!ePu#}3K6M4q+mPYHN6tAS!6_C6pY?b}tj zFBXeVR8c@!g_Q%Dbiv`u*B!B=Fkz%-$gzgjrEWBBB8H$Osx{jP*(Q}rEi13J-|-u@ z$3siY9^~dL>D+ZQ;y( zjx5P%29f%y^bEe21;enGtadCn`;F_oT7Ahj7S0xZSUy=T)AeS*&0duFyQ^>z6%2UB zn33-q7rc22BW(R9`iD!RX>IXyA!LyvVI|A8eSj+K#cq}%7550ko-9E)LqAY>hIBbN zF&*T;K_6?bh4xY+Suik2VP6AhQpm&h#0m;GRxTCdQ(jI<(Ha_HjhB4tjX@H@wiYNe z*(@$*kL>29n;~6^90-|+AWI5wQVHWc*I1%JF!!!ll?I+{#hGR8l>iCbEE^S>bf(mC zs3*3fLp?_)1g?9`H)OhZE z$te%|GAu*CcW6R&G?ug<>QJ}V8ZYBlG*>Yp>`vR-f0|#OgsA(Okqo#F5Dplg**&oB_oiva7&COvkS9 z;ru0X@W8NiwDRH&io#H8u|K2tgUbgRv%E!P`SBZ6fDx*H;$yuD?EMYxoNW#PbR(-L>p^E2_e@kwt_w-?{7}bC*3oFW;eI|3xDM#1)jVon|2v(5-w8hGw zw4>I|nA_*LldzBDIbLDAJ8(!Xo?39y@W(()wx^o$6U^kr{6iLDj2~w)1uWHbuIms( z-V4igObgPSl)| z8JNB=5xVD0uHwkfR6t9`=pkDULY}grY7)yQM>E3~GG+q}ftUSKG#(ce%Hzc16swwu zS85V(L1d{EN@$V^6t2m4Gt&=fGux6`vzsB^Y$L4K?1W|kTv%r#rNmc%K?gE>=PWsu zvYQgSNn``kQE??0N|WkoP7W_N(>`=tN(ZaU;}cWcwr|@K-*tH+JabR*pVQqu39k>^ z3%lRFyzl>s)8UB|+cs|=dZMKl@g{8cPfBw}W$Qm8-`V$`%U8Igam9oPc-+}nKF9az6U zEtFSavZ$G`yCL5@%grj{SPA7oRp|DY{ij=G;9TN*ubs7k~t&K>d(&}i7GiH}~tJ8<-_OUY=D;SJJ z4Wc)g81k?bFhCA_M%m^4?q4+uRl0qwkXjpzdYCvn?TAg} zyOje``#})=NnE?0^W3>D8uAU<7XGFnFCi|>KEu3ak0Q%XzZ5AgS;^n4PAGJ@+Ph5R zc2-HK(@rc_pNLkH7P|@X-%`FQS`t-7qF`Ibv!b#DM$$8iUDi1$ZkD+w=1JG*7GZ^O z+XG(BAV8 zP(oZf#ybUi#Kqg)nRMUr0|(MWI}h$nckDg5bN_)S?A){G$ljwzujJC!!hqO#=@_q! zUAs@2Y3D0c%WRB9v-OoV(4A_&=0CoCQu{x2`X_cB8PA_IliHc{50Zw-k-=VJ=kNCP zU+EaHvg1t=q!`F86L`5CW2VZ!1N|$GAKO>jmS3k4vH-ip+uN7|`MTTKM&bO!O{3U- zM9bMWpoPBG4$@alT`rx@*DG4-mFeW==Rdi0mCFL5=z1Sjx~aU4jZROU&o(J@Z2H98 zY3Kt|cT|iVV(PWFq6OwzGG(Fhtnw zXK*ud`3)PmdXMkyaQ59i2c^|Ndna|i?Ikivvp3ZVxab|F-4^>kWto+;Z?uc6_;KXi zuq3shk!psN4H^1p-$^)_ovNj)&fWz{wpAEO5OwbCot*8Ty@MDk`&gqGxfLd%{p!s$ z&Y8J(qgR!0TfYePs^qZNIjH zos&O{S<2Q#VGK&*!5GBzG*R519^t{lK3KL?c?0CV&gR1??d;u*e{A=jL+jP;ok$Ww zll`-IseVz<=HBRpEDdU^z{V#6YviHyY+2>>>Fiy|M7HSR(>Z$w+sEiu+m4ADWRnn$ zyQjwz1`p_};tx^u4iWH76?UV#ZN0}r1I%F~HCk2|1u0p7G3L!gFai`Zh+I5l5Xecy zRU6zK?i6Ou-XStu(6;I7iQOyGJfz0XzF9a6kx!q!vv;%VP$)Qh_MH^#b=702$wVRs z)O@=^xk`g?v(?5Kw$0&n@MY+OC77+O^Rf+De*|Ifr zFPrZU8cP@3VD4s%??8!1MDcnbfF_}P_Ks`FWG7HVz{#!C6Vuzb0XOkC zolI_<*gQEswQcLv7QS!aG`V?t^QMVpa{J_#?VG27o40J;G?`$9Cm2VYN|TfP)7Pz~ ziEX8c_;q{sbrQQgoaNf=>s0uvd;IIvmMzm0Q`@)G*ru)1lM~6*^rlT)wofHfo2I8X zO-*i2rnXFOpTI3nrpx+l;j@*`wq(onw#li@Q&V(o>(*^tv}wz>$z=PM>CF>cwoXk< zCoU_Zw1jJz3@Fz{q$YseNAy?M*xrvoZ-;l6EI~cW%t2qwp>cJTe3~%#Y%>1k-4HUY zRF;rAYAMEGb!qnOo0p={G$Fu}66zrJwqF>)n2}EImw!o8)p6(uNLP zT+XxQ5q_9<`qbV5+W&7=sh+Wk|CWziPtvdvV~7cH3bnLdC^OjAF~lNiB)NZ%Eldn6 zaU=wg&%U!J$;&9cHvvmkxE0n5IM1G4PLG4NQ}vsXB}%v$+xozSZ6TUMOfSS;d)=|k zfupHQV5r~L#PDy8j%1H8T|{3%;>r%qB*70Z?o;K0q&km*n?;@?T4o!qOp%}vNhq<1 ztQ=c$Bg~fFBhld8Dq>6elDvk=BM7E1QfPMqnmg56SCe7mVjKulDZtfhO&|!7Uwc-? zkCF+IG$j5>zLKqrOGtQr?p@v6H6+|DN32C_QPhfv{Aol{*y1X)yuNGOw6X#(svks4 zk;a4UnB<58YFg$Ryb+xkr#`?}icZI#4*ul-Ij;U-&7Ei=}M^&l8%l!94{ z2J~zm8{GT7JAE2Vdz$f2>KGiKGiq;)Na})X7`$lTWW^<9 zcBuz5+}6Oe&a%dC0wvexxM%G_y`f|$v&R}W(Xt_A8{6UvBiKKB0|HhpCQigl5$mhx zpuRM#Nx%iD@jnC+3@9_ix|m*!#jRiFn1}dM5e9TGkdE-*AVY+g3_0DSP=e)e-458L z2n90ceA3b+g5=VR(KNm-Mj)?W$in{b{f%A^t?oFRz8zCbkQgd(yjPMXt_-wVw>uUIpysi!GacunwS45#Vj1KEX z@LTe0h#btB%^^?1`~%~&VFk!Iq5=yJTlS2=;A0F$_O>h*=_njJm(XE+_!jHwKgv-j zo@IB@!rucPwqxl28?bCk_mcQv*Ydsw$wP>1rO>Hm-VYo)3_k@JY ziM)EGT3QJdBPAuF?mCDe6TbFo1j|L^U04q&a0#RLC8RqxO>JhY6>OdK?A(@0P6bONQ*-9h`r<25ip(@55CKPvl|&qFOn2_uFDkL8 z_Q^rW%;V8ot3r~B@w#YUbF{4Vg7k4@anl&cRt+Rvk4&jJ5uq)zwr_H!VA+n5UR2ZpETe z^7atkyU=hv&8fr_kwc`Bu2G5a79mT9bwUI67}F!{MZ$0ZBBaBwOb|6|IWpkD zb(E=4l#1arI9wjqiUU9nWx|}-iCN5wK4p5#^roo|**B|fE?HF)nJah?DKLkN*jQ+n z<`qUA@?w-hXzFdnZY(i;*?@{>FvYNRl$vXdOsN{8TxM_-%x~A5M#vTe6X{~E1SXTk z7ks7g?$G0Icov+$bcg3P3#YEEj8elqBw+%jMeYg_yxj`K8KYK}VhuJ?=tJ;l*e56i z-y~pEwFXtnndfVNfJd7dCq*I0X0l2VqAD3%L6*2_Vsc0v>h>1S2INub@b}YOv)l^q zfp?k?6Rf55mO;fno4G4253%2x6J3~q$}w_K`=JPX``A(2xK>*#=Szkld@Rs=lO@W% zps@GJ3HYTK3o4M3m0+dhO(V0Y?mJm#ANe};7iw1cHom8RYPZB-cieB%J;ek5# z+b!xOSTg83TFA6`(E1RPMMQ%5R8&affmWd-7o;mjwNJgjCkB=LOUVIk8|U`I**8nJ zBTj<#E0%@%JLV;bDaAHs3d@W$W5sQK)2!|QNr>;ofQbU%Tb59k%_ZbXDn*+&%rxj; z#FjVIN^f+}zFF@Slc_DNjt$YQsXvd_2VI@p%8gY`=gm-^CHd<}JLnOybcb&aF72!w zC3s~zLa!7g#CZozCN)=Di3oZ^C9E{Zq{j%x(hc3oMrT*daY=m~tI3YqDkt=UVn%ik zyM*w`tw%^mp>)W~&2E(8N|opRpGkL*?@lkf%n8lUZA`C`jxy4_#tne>jaU3qiAYdYD-|hZbKEx~x_r|j3^#W1~j}Q1+Ta<`#w16_` zlyixaF-xSlp{B2lHAGQV*kC0R9*pE&dgcjHE^2H5zsn>j$ekg^aW!qCL1{r)wqQWS z;BFKv&a#sI!l2%3WAkL*Oi>$|ZEvKZuKLw$%b0=+#fDwO)-_fO!QRMD;%;-OOunK* z-7w5T!b}b#l`Z0l@dP>wmxPdt8YMMF?h-oERyU*q2~(>2(kt)~mO;RTJM?3mdp+8P zb(CagAVFORh|irtYH7!0h=W02{f44lY#BR&uedS+s4!;`=@M7uR6Ye zy~1*pY@NTOKU0yR7;r@u1v-mr(4EEEVKgB+h~?3qh2X8|K^bC(b#VVN#|Mdwx<3M} zgy||$=Xc8za2-)E$q^{XX5RfHH=Rw8D<&nITfS+5=GCfjEmMPE8L-~*=)#~9Ya6hO z58)e}z2i({356%>TbrKF#Xi<0I5vj3L5W1I3qBXhApRz5Jk2wVQ5K^B2IzU zIHTe%wHqvYe=Lhe>Ni_*v%s`LCR3k5^iz6=oi~M8^#}w6v>ndUMf=T<4KB{=J*~$y zH!-2bfb+3Z48eO04P9|`>oq)MH8!<(-*I@X6qX=7vQ&oVam5A3LTYB!FG%WKcezBz zKUeoW#Al`kY~?Z%dzNKu()k)VbLD{<$LGo!uxXCo2Pku+O})#)`~h#pc&2^t+Vjx* z>PRjbayu-F>4L59nH`(Muuv7YgAYR0gSay6CgSXv-zxhdJ6dBM*RUUef?$5kR5$Zp zjzVD0l`&>GJ|~W|FIJ$+LYz(~*yViDb_X8Gm!EoAE;;wq8tixsC8T?I9oi>(k{Os* z!hv$dF_M}celJ0}fW3QX^{??(0!=-hw`RWZS^~+E6_})Zj=qAYV^PqYCi9J%#NP}s z4-k;0kQA_|Sxg%}Ck>)oMs>9;bP~-%x(cmi1475h9#}i>0cDp3YT8>&fT-!~l;C<@ zyJGrjmMvi$c>8liSCJ0gfdYGkKdk}|)2KP1%!48oGl-p1;F}>Sj(r0MM5dHEF16T( z(!^m_-6H-Vj1&ZbE?3C}z&I;<8RoQNP{()`Lo}&*FXeDip1NU@8^wWcm^G_7GKro0 zJ6h#R#9!}6Ketub?ZE0}MIaG-Qb6-Ppl2owV}VgcT)DSFq2}3lSwz=kx0+eAelj^4 z=6T0qudFlkKP!6@ZslK{y~`PjdJmUMdQ8F2a;78&*5-ZlqA~J}wV3R}%_BG&2+D>< zHiWH%JkGRIElHh9;z@W}bkAPwtd|HHLSyFaW^{w)6s`CGGL_jeptBHRz?y3;SbtB@ zdX^0easUY+bGE26i-KIekO36)wFMqR)nzi9j)t57R)ge(V%AdinIEBOKb16MPj;8o z1i_KTr-l@XNnhL{#Eq7w8`Z1445f;bXvUT-^71r|Iu6&WhibMAL65T;EZ(L) za;d_S0jDCPbZmofw{2TwBUU!BvC&@Xa#uA&Dl-?z^Rk?^FAw8RPkOm_!DL&3BP$S6 zCu4?SC9XxC#0^xUX7fVLX@`n+wkRmdb)!*)Qju8AD2TgkX~39qT!JxcVRE+HtCJ)4 zA1p{mvJY35gaPMF9NHwmu5HgXt-k`Xft(^0tra`d)JW|rI9u?WL>_Y7t2QX6HWQaF z?Tn%ewxCbpxd;|Xydt`gX;MOTakZe03NfjQElE!a^Du(LH>egO_>#^CTJ5mYUKpk~ zWh=kElN>1m3bRdxU~#@owwa~BatubeLkvNv5Uut^ z%!I-`F?7`aLv;x@VY$&0xD`vWI2$Wvfm@3)uaC5IbYw55$b7IY9HM-2@V>He27QW} zC>I9C9GQ<4oMI!n(1`<9;ULa~gu_dPWQklGLp82~1E0q{GTWV?Gt!2nh*b_kwAB!a z$+jlDD4U!$@z^3%xJXr~o5R zTPVm;RdU(CGhK^RKM>_gc6QFblP8J=h+>;HD@N?Lm2Kvkg@P%{2;md?)KGJkP;8Z@ zkOvQlU-R690z~7sigJ9h&#Obg(REgPYn}x)yB2niQ?E5LRA*S&l$eq+m9!A0!voU# zwA`wmVp)aQ9X;aS3TVhjj+WL-CbL^YU;_HJ^SV*%HMKWQ5X?cFi6c%Sur(&0$PKYm zR5e!FCfI3lKuU@3WW~si9NAZz{Af4iu9zmN(ybqjLFU>qgi0}IWv_D~Qlxi>a69`p zwd(zGUIm%Oj+s=tgUIoWHe4~v&$w!#7DUA0CW7e;dY*CW<@l+0Q=LSa2-~;g%Z3mq z3AKaO?nxE%<_2$#-&+gphh8VE-?VNRZg@fF_)@rf9G5wv%fVW z8n{i?T%VAJ*K!HWrW1zaR{wOwyEN3RmVm22@4pw^)J0V_}Y!dCP;& z7=~N_EaadqtaI$D+{O9~W5LUHX0ud$=y{2z^sCb{IEOL?mNg59EzHG13rXH$b_F

z86ax-&?*)LeMoWrYXCvx%)s$TzG=D=dv69JNEp4Ji0kG05cwbFQdO>rE zL*X@_oSr@>%exBkQA_{uvwtLw!zhR~Q>!UqBnW-YT?;_s?CLM-Nr61}YLHO&?0Fq7 zz6v#D{h&)o66PYJz$`SGwHjvFOa!IWbLltPY0}z}YmCxMidO9L+hRKuFOAl6KW6Dl{bLwXsxcJ{gNM-W_@Tny9ceY+gwS@129}R+Fnw<(Fk= zPwsgw5vxPdIwPr?bxOkvpqhcyXqRJqI6B#_i~FJX#99n^2#$fc5XevRgFiU9Fgs#n zJbL`G?oP#AIC;Gfvmc)y(65FZDdp#RiWYs^H)_|Eo(h)dlqD#*?UbyFjseR;=8bmh zHIXj&Efkj{E*jjq&XK)hx_q%uIaOFPnsH^$CISGASV@2W_MqJ z5m7@4P@~wp;gOVWT+$=J<(kT!6sg#8okdtd6YiMOJq6@UeEqcw(K)ShSmPjFBqD$H z>c<(GKD@bEo|14qM944jSE{BaAp9+svpj;vZ9SO`yfc+_MIV??6pLi@;t<)jgY2~% z8!vW=%ZS7;ov70vq+YQn(|ASgax;yBUA`y}*>UwJw2!v1+fVh1=E6ZDH*H_}WTt3! zzrTDo_h)*~#gS?x{gWf*$$bL%%)t6fWb7Ju#9KJH`tLHYq%E_+v~-%+f3|PkIzh1; zAA5C5$xf0L6bMD=(Cm=Yw{lSbftaG1*bBk$&RGC_URN`81#=AK6PY2S_sM_I1UHCihsy@N34uRAa*Ca}44f zno5z04SxvWD7OQYZn{S~3*66Zk+>qw4duEVwExsR?oQ|F1r|gk7!h6BUF>D4kk+4Z zE8~Y8kBb;{qDHlL`8uGBiG4)1er6>v=@`xGM8Vlc#!^GqUx+k*+8 z{vL=%9eHC8|x5P-)e{<~snFN!M1;#T8-VQ`hGf|4q5R8-i;S!6HI3RlRmG2Kp6^g@V519r|{X$+$0t3Ms^Sb#EvDm($XN*6e_ zqC{!FGcsG{X{dAXrOZcZZ=ZL-9xM&-mF#48T1l)k=1T_obo5f7r(!J)}68YDq#j4z~^zWf{9q1 zP9F*ky|aJ#`c%*z)DvuqywW|*#~DUsO^_-Q7MC<#s1P@m*2YTq3IpR&${nK^0szC@!t~eqnmN$mnkTL0JU_UUZ^InB!ZEFTdEk z_t9s2^OuLisjPZiaTA9%%fZF=GrSQ{J=E6uc6(T-#`!K%{b+vJW~u^~@Aa<5ms5se z%WRasb<&?cxWD)C@!tHR5YZ(mvF|?Z?(x5Q;sDnws?1$^*NJxt+JDP_caQ(;PCSTB z$GWI-TgtH}2iwjjwO}=idqD2TZUj z(Z6TlE=|c9%rZEQC`E09EwHY-0WB&sM9~@x`$1cGsqq|~-B9L%$AT84TiDf)XUdG& ztlm#fFAsZ-UP|2MINN~72jAi{a*<^B^9(Fuc6rPhkLAQV95$4)c5?K_K6We~lp4^` z?C1t^oVpGD+AXAV_sQqQAU>QQpQ^p$o$Z}pZ#&;+#l+iAf#oS+W9Uq26_QzW5x%TO zFw2X>ur}|b-O7FM%tG1HkHV^--ldaPUTo~h7U6;QOrW(ips>)0b*IIc9(H*j)=~S? zWN8#iohkmkba@8d)iDs9rC2qiY|+=4YVv=`iX+p{vea4?C(8j{Q%-YvL z7xwUfF|P*KEVM1VMgj=5$eN*a8E8)MJ)M5}#ixpG7VHBECDcGf)bYT4@(KMLmM##Q z=*3Ibj*0*?Ka*P>v=(u1>r^3YgymA|YM>*!`pCi!LkmW{d?`;*8ATPwVLhx-G0re) zo%G#EDjgBKD0mxL&?$5W<51R>a*^Xq+>VHGnHcU2r!O0fcN4i$nQYDhA4l6ji;A!w zv3xKaDv74|g2c1?Exc>`m4k#K=ki|fOir)x?^veY7kRuD*53y!IgB!n?*!4%8 zkz12-jw}dizhl`8l>VECg(GNp05&9U;K-{>L0?qAyE;CH<0O)RcS7Fnt1efz=n2ON z`Mo~#v_z6PvA#o7=*z-v^D`3xIds3BJ_c4X;&=7W48hOLz+_-iuZ=Kz6_`Z& z6cPhC$%J679654%0QjM>pt2~{G6;-Q&L*b4)JeterGgzqfp^hNevu{%a2j9*DMe5L z-x5{un#7m?2L?2sL*bz>trIyYHA#x+g)r^UCy&9%T72HQg=s!ZcywVH0ZP23S}U>6 z>#C*Kot>Z7>V^H?6e4zYl&`^ITAamOX0(FUEj|V+{1$_X6JtSdc@Q&%%Uzb=KK+k^ zA@dfy|0M5*Z43HQ&=$Hi4>-l5a_zF1Wqo)3_Hw%rxwJzO7iE}KbX`sX3tJxRP}SW` zl#Wmk{>tZ@5M2{T^U@Trul7UMwb>dXf|T%^%o7K)p({pQwbx)Vkw8wXTQT!dVhi50 zDDsf5+K{X;f7*tf;_9xV{5c7$QVK($J^^h4k}1~>uT_3%h2U6bVpGU#sx**l(o0#& z84=zLqe>P;>MZqYxO3p4&hAhYPR%d%M^GnMcD4hP%dXT)#taLVyEl9!v&Vn<^xg^G z&|bcQHZa`d(q)V5W4R;)}6r@caYo~)nX%1F3w05P!MJJq{ zgfekma?0C`C=&An zq-8Bs#H=aL*V|20JImSt`H*$|m@ zlZ&0%kASXa0w;tveb7~6R2U7tFg9c$K@<%iFr->z;7>0T8u$|<6;oDpYQRFD8_0y?QI+mBrGjz(~K2Kb0(6a;vIY{a$!n6>h?I(0+dSE`pZLZ?t3Vk{9IKl%C;bs32Xbj zFc-Ra#Foko0rP~&q>7!xp-I|9jB2ztDR#X5?4FkpHL4_%Y3MRb*ic!!em0%N4S{xx zbi_tNd-#m}((08Wtj^Rp)oV^M0{Iz_rW2MzTnB=f1R`I1sU-el)8e6hl#b#(u)efR znPy%25*5DWme}2P0lR#kM7F3ZX&eB_*T+YQDO!BfH zU%ghfg2xs?wA-DL>0hJMRjMJnehBj%K=NpBlk=|#69wGqc_jsKYFGB$mq?hKPrAZbcMC`t|qLk-U?lYJtt;|Lw%;y zI~5(zmcnqZ)`>h~0}PXgKDma_U2k=Gt)TLm&&2pn&fj&upHIa9uCW! zM_fUEvDlqFAkkPTE%DELRbwB3!ts(nB4)6$Zd`nap1(2Gl{9)JKE(oofM`T)yE@ns z50U)p3?;F&G@v5Z5D&7x^BlvxZ1Cf#US{o{4y;-;WD~S{K-<;3xBT61E*$~)$jmV1 z$%r@?=4XkF#Tv;BC=3)4&+og46KTWW56RqqCFjhiY@Iaj6?|**P}&U|X$*%EDyN8d zDGxK+zXt5L5yP}Z|C*LV@)`PqALzlxtQ|*{Jh(_j^uomal*6%hpB0LHHhz3)$u<6* z72+Smfc?uTR(T*tf^{5y@8)J%GA$#AxLhROakHI5YoSLgPr=a2IRYGJeF40Lq=~}hB6Peq3|$Tl{G8yD{)WO z8UV~@y4hEaFEm2{^SRcc#9f?JQXQPHR}+A7JXF{I z0SuLms`d1m;|NuWW-!CWCI8>0=PA_Rr2^VF=Co+8Y)jS~5Z8m-@q{k}H6C14{24XS z;4I@hmu%B7m`)dyy^@V{2t;r(z4`Axd3+1x_LRIRnXT+clz*5Kz|SnGDFFxFC`cbWR(^6yNXs z$G-Y?+64tHn}jK;9@VYgBV9}1mmC>nLHX%=p&70fpV=TcX|75s=rWq-DyxOd{A5G) zVh$?9wy!Enq@;UKA=^IB20Fu+;R#f%{K6`0OtJ@64 zDd(~X<;o40Q}9 zUi8m(-TH^V#8C!xnz6f+Pvsw@C7s|^2ZZp-KM*3ZL@pj5;sCiJodgspfV&C<&}IGd zIeOa4H*9P~ru>pAMk&y`Y!{Q1d~FnUU!kjxb(Sa4rKx*UqtRwiXRriX%r)pB#X%rh z9510)+)hu)J}OE;$vI*s@yL(-j*bgLm2WrCb#q!}I?rMZJ;GZJNJN}AHSc`V#mXn2 zNfvU!=IOa})|||E(iP%ai6c+~`a{tMu|_TwFKDrnw9Y=t)SHqB*Hss){zdda%-tn4S^&$8Q*QvD01(8)3k3F!D1+r|J&3A`(bq)blLOFUg( zyg`~d_$9shkX0xmSuE_w+{s^u9$LkknKMcU34tV61w|~#fD@GkoxM~sfRqc5xF6c? zFwTKm%;1<|)X2hXcVaLi?~lq~MWG~6N4+?BHUiPikB}S-*l?ME@*vuCK#>G0ZRBNE zScMIVR?vnf3xg!Iup`JhRZTMz&8K_rYuTFeB>miB7~%s zIawoA?CTylVE2JeFWuJ4-$&sWm?t(GEFK-KEECY>6Ie&2W)nVB%-Y>XGHm;$y?{LJ z;=6w{b7_$&?=8iakfcaRuPg2%79X_c-Qh&iJknQmBF(b*0pwGT^fN`IBQ}*n7-7sv zGIyntrY@z!N28$>8xgNt5k1|EqMt}ria?N_nZz1G>6Lig!Y_d1m~He+O4Excs8@Zq ze}03ouKUMhwPc$*P9dYD@Y~oBeI_@UpQdHTbPVMuLMf0T)Idj3Ulazk_d32ky4o7 zxHb;s3}PfPm6ticmlb)RlnlTeNNmNpZtf_9He3ai*Ps%jnu;0Q@mpJ!*uAxt_&$O% z2xM6(w02GWY2{)`7MY|==VfGfh)7?$b~)a8*y)^6wzi~+ML1mKvfAB#J#IK?Gy!a@ zo0*{s={9P1?Gm%Uk@$dNEUA(hEj85uM~%Ps_K5A)Fe2cRTZL)pVa7aI`2X~rj> zX6H;(MG#mZ-fHx2{WsVT`ZZ<4a`G4uo&sp3Wai?u**}8R9!1bg&Y)`8t?@d6RG+IN z#G-F4RcX4zrI@#W{r7QES6c7RT6fKSwV1w{{&=REQol~2$@nv}Kz)zE=u=8DT3R82 z4}^Fxs^mLx{Nq|)A*A_Q*{dDb2IxkaE^2Ofp@Cd{Pw&b@f;F-T>}fDSB|2FVD$9l) zt*FnOD;n=*%1)I*t#8X6t_q#+{C&*cgpZ9dS{li^N*+|=gG>ZGHCQS<+4{`y@~#s& zS{nEZhePU^3;&J~@<_O`$q+_ir7)KvSbVo3ZO^WyuF9*Dc=%>}m`G$eHqQ}HS7}z))@)=g3bV~{kt--5xDXv; zmy!F%PLD-1W`}Dm^f;H;F+T6(ykAZ$Iq|#izLOKZPj(_TNWuFp5bdz)Vl~%(B|RFm z3h}o1-SNe<%Y$#hcABe8Jz0DdmlE<8zKcU51|pEfELa;xw0KCd`gX4VdnEQW7MW2# zI1G(LF}lxMzq3hqsN}#-A75(C`qU8AlgP>9$b)V~D&CaC$_yPQDe9CM*9R(n0a$+yWt!eHB_iQc-|6#GyWps&N#5qCC^bw+3})lx3=y-VlLxeC&S;vsExR0nA$62 ziN&hru2}Ip3}R$Cn5N+Pl;|dOtu8spr2Mcz-}MC+J*>W%k9ylaT9}@jzKFt-L*X-K6C^HUk=f&?ffHtD&b;_s#NGF-W`bDnl2$ru&2+o8>Fs4W;KgG38tgp1d{HwV(r%?LgR{>|aKC z#(iSQ>Kpg5nYkidlH&XgZs;Cb2UGkpAwB$gJXknM7rfdk)E_C1(-1IzgOXQce|PVz z=1p=gus|fMepxC}Pd$K4HzwgtNcR8)VN5eQ)eQC-PU*pk?637%H^;MoAmm%|ZYc!k5C3z47SEan-{tt7T`@ewDj=wh{? zlDgmx4k(dba>!Nj$<=9hhStD#i7xTjzovX3;ST|ZOnkl^h-Usr(R{bD^ z!I~$dXc`2m1Byl-l}!LKI?od-ZIkV;2f?Cl>F$zy(GR8hCq;InYsNJv#kY1BRw&qh z;Su(q`GQLfRx;H{OuJoQChIO_7Zis)X}2B3Bs@UKXmZ>%6kMYwuXSGFlSC z|885Njo)o1azrmbrLA7z5J?#nNt`1hTthfd+#m;#o29pRr^F9L(|N z&YyDA{UvVRLitsa&J7=h2uYa&CU4TEg))V-bCse9n;zUWaFk@X@CkE+M#cvCndpq5wH?-~Hit z`{#w2>7&Pxy)qbZ1P6hC0~0`X=L7*erFZlgVebOdZBYi^VNCxGe>gZkars5QAgSVdWUb}Ww8HIF|is4IVZOQ_!NblW7(v9VmX;WhG%~NjmAwLj%pkZ8t+F(V`2#2#humthAyj?*hDpi$N zsSys0K!&4Wo6=iR$yNUm844L~Tb0I{aAQ%vI~06&lf)v_z79mXSR|E-u^ik=D6cZc zx)ZX5K&+5fBG)|Z3pQoA4y)`6wmn)Vg`BXRMeL(bc#rA{2Z@BcMC9Un;PG7uRNN5L z4y`)mWkuwhw-D|VrYM?;;6`tu(SInRL_j{mI5c@MUn^EQLKw{hL*8+AWg};@h&h0o z>~Ix(!14Ny14fdC_=gMN1d8d!dkM$&U3cUPVidY}9i%e#EP3 zkIW|zCG@hLoBAC}@;&_ptw?jt@lL_f`PE}qLHQJwkfzN@@{tHbqM1L(kj1N8_(}D7L-Y4TVGqPh&Btd|Fwl}s7 zmn2q7mZWgC(AIQCe>7cj*Fhkdi`@@)c6Rg>yXtxkb`>q^)~S}}8X$7-*GUd@P32fx z#HfXRCAKLZim15E0nTAr@(3`5Bogc`=*%Ha;*tTI4=-n~QhuGc2a85P+bktqB2v3i zyHadSBV}>;uQ`;zT*CtrK?i5P%z@~U6m%pd2XYfNa2gKLo>8>H!q74U#uF;F!5w9T ztgpk9U&*N+%=#2bjtbQ11G2gj@5#n1rumgFKJ}~seipV!zR*^r3&FDAxrq;>upxg{ zPO_{eiBz#o4`oo~@?5|UiZz@Q;VOmMBd|i{GUHmoPhCAb8aed;4|lcv>5!V3NMK0)IV}WE@J&A-wVAJ6J!nx(C{5^+oQQp5 zGKk)+H=${n2DUWzseR5gNI7cB1s!CQoCX)lpg?*I>YLLi{Xuyh_jqM+&Xz>?manO| zmPUi}OjMd6$Ew!Ef=y}_kr&ljT{3CxR*PGBx<~-wk#Gsz-&|g#YM94CIPeH%Y@p;Z z7wm&(w)2S)42Zp-zYj#@aPGFRf#R|NN|eW`bPOfEPU+8p}jm6FcO*^(S_uT8^Qo_%CP@h50AE}WV^ z4lv{B9B5;_lVxYs)lZB++%6@KP1oy}I}547Rv!@`ukM59ta>aut^RW7XPPsn;w)#$ zZ|;Jh`e`La0B$i1TrxN_kO%+2-BzxY`9cMJklaqq>%tS&`z2IF_2`B*4x7IIfYjV# zJ#_10`ubOMtF~gKL-ZlEi%U+!N3;h&)A8lz)juz9c?%qtb8f@U{pGEH)7+A5>XLw{ zX>MO>h;Uj2`e3Bp$zI?n<%zN1(*Dk?Vp_l^zyo+40m35>vze=iE-*f5`?+8}i^pWo zM4;9o$hjU$j~FaU&>zB2@jQI43p4`t6jo>8mQM@+n*Q4lr$oC8-bzWpC$l^A-`rve z>4#B`NnLAYijs&_9v&`-4JclpRXGf7C60h#YuHrT2TDUGs3VLHu{K0qOx|Tj*^-km z03`~eBcUFN*MLw28-`Udq;QUAU-Pp}4RMSlV@yacLmq#1j2hb%AO(s(J38B4yuTv^ zzh%Is24YR>z!N?!x0!gqab{CL$<&Z*om(K^$u6UW*@{3Ew1`OtVKV)=x5gQbW1|zn zVeKc!o+5N{P&LVvv6t_~7Isuk`oM*s>#q~~Bs9(4Aw9$FJDApCiz;b4s;y2TB6guI z(bfO5uN>P!zupm!yHJN;frzPYo$1{2V0nRaJ%<5T`?{FKIXmy;S!50AZdB%xZyHci z>U{27`$ia1YI<#cvXgkFp-4DE5DRn(ZG^)gN!ZnLO!GEf^UbF0V3uGxet65gTig0E zbE)mIH%M^rfa>0o!Wl+en|5$I285_3`8n&9^`LR$Db39JSW|%viP)JCY|c7PBU`US1Z77oIb{SwDo&~2 zRu^}pilTX|WU)0=w@{wZ-9Q=PYt@BMpW+H#kcp%~mG@^9kJ3JcuH&aws=DqFB&fpC z6Y01{VKmO_)XOm$%?10v_mq%aZ(DsMi0y{UumRwdlo14`GqWsBy#ZX5qI5nMZW)d{zPrknT-#!v^Z2$KSabiby&@^SX z2B2h~_2bSbUP%??t!(&p>0_;3fzqXDC*c)DXGbfVFumEC4mYw5mn0ySoU6Z8xqdJN zC#B(5thLT+;0`Vohs65^69Q!`<6yX~TjonkBVgdcuGe2YTi4Td!p>@Jb&ps94FV!> zT&oc(f}}%r1c0SpO66LhRog6_e#(m?EFuaiGdN}v&c3_zMeRqdQB89t`+h`Pyaf4# z#qG&RYWS_uaJ|c4&PeTccIG>2?Yo7JH6ltCZD2MIR@FXb*)~Z!xD8%q%*l9lB0Q4d zX)vPfpy%2Wmp370>U%1*BM*r78$#20uiU8wHQNM~BEe~B8g+E?TEcu33n4TWE%6~) zU>=+Twz1D4{^VD4K36{;9G}FQO4Mx}Q(~14MhDcBN`*i`aUN{U>V;YZ*c3bDsmX7w zf((i)d7rEYwY!AFr3}5b!*vxgov@o?MpQCUbrCz9g8A)3RBm$uhu~E-R8_2Qcq}$l z5V*Rr2s1I}AUVSU+T0@S^Fm%0(g*>-A&k<)xn{saa#8RlOko`}a4ZsQ$qq+_0cUYZ zU{A-gSUh>~+1}$P_da{{^vM@rKD@6m#po_RzU=xSUEVIeB}u}RTqQ(*mCGNbS6rK< zW5b3|`pr$#Nc!J!N8Zb!t>G%#-R| zDHx}#NC%0epFH!Q?XJG*`N+W`l8jkdVECgsXlfj1@G0HRd;iC$1yfkkC;r zl23wvPie$K*8|4RZ`!P}vSZKO&eW0Camo|>NH!D|V)N-@@9o|FOCU_|Qiv-5uvV?R zEvV~jCa$rqkB(S3heXsd#q#7axi)7PX>YZL9EJvPG?_YUf|a8;2O8FdxmE!`y_wBB zSUH=x_IE1ezoZBG{GnZ4KyI8xm5z$n7W-}05< z)KcK3;VT>_ff8bnArvc-DdqnD)vE7q{Gg^v!WtpY^?I06Kd=~8*sYag+Esdogg!LH z(eoY&y(pNH+(#v0^}S^U-0&596`pLkJ9&(iDBERrBxv##zyz;U=1WtQ2HQb#b&sy` z`@(Rf;@_S&9NV~-@Jr+*wYR%kaTuLv2$EL!lI4Y5lds%26lZzjzz*GK z3a+XvND{V(y|h(iP{>V%D)zXy_~wT^P9|V|V!$}a zK&+<3At@yjg?d=Is!k+H-iA6<`FFmO-5EDTvhy`k$4ILtB=9(t%Mht!+5Sj1o2W_0 zv_zTVz{o*6!!;!rL*5vB2kpic3xacEV2MVisdC*=8O&aX5*eoa$PFledVR!&;i79L z!(}puN0zu9*PzMxUv1DQKN?P<2QPClXSMHWhcr)hp|we%j8;dsEAfHTCKnL@Cho5s z*qk66#h37?$Vn9~(NIvqIwC4%!r*?c#5pa%+}%q%pz${L>~Ibn2PV-;CRDph-1Fx^ zvZrKPCzX_#ff&o%Av2p+amQ!79pJf~eoT6_;6^ht4cC|lIyF6yxO&QOs#H2OTQ^=! zqAt-Zv6ZI*OYF5g7NOkA8T#zv=>0MlER0cNKr~64ab>gYJA%neYOtjEcK9df-3cBobvfw@(BpmS^8r~+HL z%&LWRnV;6gQEH*H8H{@L{p|9bJBXE8ppTSVJX0=$`uLj`g5x_1XS zRZSj2#Jn5a$DVebUwRk3paAR`cVGD_o9n>7o8w)-Gb^l6yCaedXB-;|X^TxGIotH1 zdVom~NS@ebD7=d=?VpfZPoi7peGQ~5ABHv%&$xxs?NKji4WZYtRgKdI z7R#0uqPOOeKglK)XmLqFY!hd3cPCdwrvoHZ-& zE&+Q@B#zlxPzbg$PKCN@EdoOtBGY}&3|n1T!JP7vpB2xYC1!cEy(h$ximC%A*!n#c z7Ldq;#%Q0t`Sh5kVCQdsOS!VAk*Yq&+Uf zFDN97Mo_@Kr-$)h7=J1(d^XWROKpXXMsxXm={AOAX5fAHIKU<{n6`MW|{+ zVUr>Kok|+RcXi7mBP66`L0RoR$gv+vf1tZW2om^UIkK&dU$yyJ4q&z_YbkDH7omxG z*S&e%^&G!&#vf&e;7)oLgqGE+0fCivdxN6_cDSybj(2rdd5qQ4UA@o$g6$tyod->3 zhKx$kteI&f)-~!8vjgzayUFM62r{53R4X;kWzrI{fPU^JV+myE8Q51P+ zS3`kQ3^HsV^h~64!LBW06_sCB_0-7Wr;2~H#cpuj?mh}6cKSdXlP4-M*;_8hY~}ho z{COjIk#PwbHHQzpa@3o(ryvoFZ|WF>h;9qnL7V6n_HAzl^5wKVRM20PZ77mvh!svM zveaM4JD}(LVq!Lm1W-O4*DI^H?yqK_?Z4UHx&6U!KKPXj6*-Hi{TvL##@!NW>|15p z*B`g${7Lh;lk?d5;QjZzd1SrvKu2}B+h%dng3h9%S<}{GOX&{|oz+XgUy=#V@@lyl zv7Mp)H)dp^cx9;R#_&;&7pR-dtoZxG#}6LQrw_;VOsX4DvRwm@Wr!+=MH+H2V&!iP zY9gbCn!ha+VNQB0xZ-N27({dg1Ohs?=4tRqtrO6$-w6Zaym9l0&1TjBQfFzXpf`qP z*ivfF)7ZtiZm&Z9MVlPPZY{eOk6T3$xC*v_n=VAsc_l)GB~L1NGIkalbryk4~rpu>NAw9R) znZKueiCiYhe8)?Th|?v1H&hce7(26J9+KvBr8DjQsMJe=nC2BUUFfc!W|S`W9?$`2kmM zZP8*fJMtgV1tn^W(+~SB0EU)b1@-% z_~vAvb`RX5iL*2O%okX!ZqT0iIpuP%%W3``I#|GM%r|qjb%e@n*+qT3Z^WZs6=%l+ zRY-tl6VkuoHbo7PE&RMG7SlcsS7YLW z{?yd*i*%cwFJo;;6usU&gcGoc>8x{`Ycd13Sr`TTY4yB?D5tOppS4Q9o~e28BL@ zQrHaUfA9hx%3XR2XtSIQcggT0jb~vk{Sa2RQ)c;9OhavK7JnNq@^0R|HSxdp&f=%D eHxtTXoSm3P96a@AIakf+q_y>%@a{<+(EkPZV4?K@ delta 3467 zcmZwJ3vg7`8Nl)H5S}3>AqJ7ro%YzLiMU@E>S4@XPOlvn@f-YsR?p5g58-gBSl z`@VC-p&LDJbgA~!Y29BCS`$5ozCA%i59IXXht||bWDqvvtN1J?VR52JUz~{gx;dDM zb*Rr@i+AHTEf%1KTkj*Y^|YjW6IO+<^n}>12^Cd>!@i zj`;p>aRB=t<6U?Ib1@~wdBGw)$^LlM_fJX{=|UG)^L+V)jW7dKxVizO*b{Toco`*< zhfm>duD%OPn5K{8)B8I&-iLnnH!xj2(=Sm!=o)5nehP2BgZ-hrC3BH3^f7)C6M4Q& z$rkC3^H9%ZA?`&l>X~K`UmfaP)S)jxot&Q$({bIAwz{U759>N5!&l)bWhW(rZ;;(1+e1XVu+>a;m+k|5nCoU`$ zxxjwwNax0$A_|QCM$|d>7E=%S80tv9g*uWQs3ULz_5IUFi7dfUxB|a}N4fvGb~gI3 zvAa}+I+T6nLtl6l^#eY`pK|;f@=V!(FX!NC)U~kXKF3#(cbC_Zx|5Sg@Z>z|oF^0B zL>!KLaSWz#-}cjN)G}~stjOoMaGZ04apRq8t-wDqz5+?JOqd`-8f6*kkbevH12)9n zjw$RPM6x8uP}jr-{0y(6e!;U7MLyE&|0)~v8Texv1%i2#L^k4P?134RMc(912jWir z%@mQ5=$$6Aj^i&*7x@q~skGPdGU}N=Gt)`Q%Q%kn-^4c<|8$lUX>+#7CPn^##D>10 zc&@Vy$Kx3GCu0|eP=|VKx$}XUiF$@rsIOavy|5W|irSD*i0nZfv7cckoz#*1o1^4VXGy7<~3<{N?AFb$7mA)ZDSm?X01bm%AGBe)#BcxVOj|BxHy zGdc=y);ggqUg<2SDQK^A!wBt{cI#!#*6DpZ$f^ zg*%O|o1fmU3vD2s$jU;xZq$eU{qK)%JwQvM-(zn%KSbV+Oa@lP$8(T~+eO?RgYj{) zXD?;y(*B(5)uP)Zz5b~o;hSLRk)Eq~`^nbU(Y*1UWJU);dw=S+OVx7GrfA!Z+7ahed zQ|aC4_ICtXSaw^f2i*0B-v~rZf7RsFkl~IP zE_cA?_IQFV43;f*nGH+Nm^I5jFrR$nl$q|XjUHL~oQftGPpD}1>NI7Z_64I~1*WPT zPtf1wGa`nR2f`7z&*u%)yPDjdMjjB3R)h|!XnpIWDrLUg8;H=2kSuWf4f9sJ%bdD? zPf4p0YV{gxq=NHZl@WKOB`g)8;A+DYaRoS0Dq2EK!7#Q3!rpMitk{^}i;Kd{!;Ebz zNNsNMhU}??U8}r4p85BuW~<~%Pq4|5O2g9<@a>nqwgOvl^HsiVJ3B4vDQAOhMG6K(k-=4Wkh=&dqedeTRgg` z&S*_EFaG+Hx$OAnp?9QjLdaM(p>|q`nY0GOu8?tiO6K}MWSfKEYmKIUlB%L*U(ZwK zfooajnj06*ez&r%0o_!db)=grOXihBt`@)BzM>K-0DnFUt1@-t1H%)B-LRi zUQ4qIla()acdF`Cv8`$9ITiC~sUl_NWvlks&Rn%t<(3EH`EJl}}`fI6rXL^-4-1)l_lHd^bd zl-CMWt60oet1`M}FLvs{>(l`+K^?4h8PtG3Hlki7B=r5SG{qLLR$r()N3C+7I;&jf zuGVzxOrz>yP4lZ$dx`?8n{}dD)lxepR$*98icvrx*u`UwYE%6!PrgdGmbIy`bR88Z N-SM38i|bV8zW`(Mk3Rqa diff --git a/locales/pt_BR/LC_MESSAGES/messages.po b/locales/pt_BR/LC_MESSAGES/messages.po index 964012ebf..71954ce7d 100644 --- a/locales/pt_BR/LC_MESSAGES/messages.po +++ b/locales/pt_BR/LC_MESSAGES/messages.po @@ -8,8 +8,8 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-07-16 18:53+0000\n" -"Last-Translator: meowmeowmeowcat \n" +"PO-Revision-Date: 2021-08-06 05:45+0000\n" +"Last-Translator: Rafael Fontenelle \n" "Language-Team: Portuguese (Brazil) \n" "Language: pt_BR\n" @@ -17,7 +17,7 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=n > 1;\n" -"X-Generator: Weblate 4.7.2-dev\n" +"X-Generator: Weblate 4.8-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -48,7 +48,6 @@ msgid "Writing new content" msgstr "Escrevendo novo conteúdo" #: ../source/contribute.rst:15 -#, fuzzy msgid "" "Most of the work on the |PyPUG| takes place on the `project's GitHub " "repository`__. To get started, check out the list of `open issues`__ and " @@ -56,18 +55,18 @@ msgid "" "read the :ref:`style guide `." msgstr "" "A maior parte do trabalho no |PyPUG| ocorre no `repositório GitHub do " -"projeto`__. Para começar, verifique a lista de `problemas abertos`__ e `pull " -"requests`__. Se você está planejando escrever ou editar o guia, leia o :ref:`" -"guia de estilo `." +"projeto `__. Para começar, verifique a lista de " +"`problemas abertos `__ e `pull requests`__. Se você está " +"planejando escrever ou editar o guia, leia o :ref:`guia de estilo " +"`." #: ../source/contribute.rst:24 -#, fuzzy msgid "" "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of " "Conduct`__." msgstr "" -"Ao contribuir para o |PyPUG|, espera-se que você siga o `Código de Conduta`" -"__ da PSF." +"Ao contribuir para o |PyPUG|, espera-se que você siga o `Código de Conduta " +"`__ da PSF." #: ../source/contribute.rst:31 msgid "Documentation types" @@ -88,7 +87,6 @@ msgid "Tutorials" msgstr "Tutoriais" #: ../source/contribute.rst:40 -#, fuzzy msgid "" "Tutorials are focused on teaching the reader new concepts by accomplishing a " "goal. They are opinionated step-by-step guides. They do not include " @@ -97,7 +95,7 @@ msgstr "" "Os tutoriais são focados em ensinar ao leitor novos conceitos através da " "realização de um objetivo. Eles são guias passo a passo opinativos. Eles não " "incluem avisos ou informações estranhas. `Exemplo de documento no estilo " -"tutorial`_." +"tutorial `_." #: ../source/contribute.rst:47 ../source/guides/index.rst:2 msgid "Guides" @@ -173,7 +171,6 @@ msgstr "" "atualizar o nox usando o ``pip``::" #: ../source/contribute.rst:84 -#, fuzzy msgid "" "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See " "the `Hitchhiker's Guide to Python installation instructions`_ to install " @@ -181,7 +178,8 @@ msgid "" msgstr "" "Python 3.6. Nossos scripts de construção são projetados para funcionar " "apenas com Python 3.6. Consulte o `Guia do mochileiro para as instruções de " -"instalação do Python`_ para instalar o Python 3.6 em seu sistema operacional." +"instalação do Python `_ para instalar o Python 3.6 em seu sistema operacional." #: ../source/contribute.rst:91 msgid "" @@ -649,7 +647,7 @@ msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:5 msgid "install_requires vs requirements files" -msgstr "install_requires vs arquivos requirements" +msgstr "install_requires vs arquivos de requisitos" #: ../source/discussions/install-requires-vs-requirements.rst:12 #: ../source/guides/distributing-packages-using-setuptools.rst:382 @@ -663,8 +661,8 @@ msgid "" "correctly. When the project is installed by :ref:`pip`, this is the " "specification that is used to install its dependencies." msgstr "" -"``install_requires`` é uma palavra-chave do :file:`setup.py` do :ref:" -"`setuptools` que deve ser usada para especificar o que um projeto " +"``install_requires`` é uma palavra-chave de :file:`setup.py` do " +":ref:`setuptools` que deve ser usada para especificar o que um projeto " "**minimamente** precisa para rodar corretamente. Quando o projeto é " "instalado por :ref:`pip`, esta é a especificação que é usada para instalar " "suas dependências." @@ -731,14 +729,14 @@ msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:64 #: ../source/tutorials/installing-packages.rst:460 msgid "Requirements files" -msgstr "Arquivos requirements" +msgstr "Arquivos de requisitos" #: ../source/discussions/install-requires-vs-requirements.rst:66 msgid "" ":ref:`Requirements Files ` described most simply, " "are just a list of :ref:`pip:pip install` arguments placed into a file." msgstr "" -":ref:`Arquivos requirements ` descritos de forma " +":ref:`Arquivos de requisitos ` descritos de forma " "mais simples, são apenas uma lista de argumentos :ref:`pip:pip install` " "colocados em um arquivo." @@ -749,7 +747,7 @@ msgid "" "the requirements for a complete Python environment." msgstr "" "Considerando que ``install_requires`` define as dependências para um único " -"projeto, :ref:`arquivos requirements ` são " +"projeto, :ref:`arquivos de requisitos ` são " "frequentemente usados para definir os requisitos para um ambiente Python " "completo." @@ -760,10 +758,10 @@ msgid "" "achieving :ref:`repeatable installations ` of a complete " "environment." msgstr "" -"Considerando que os requisitos de `` install_requires`` são mínimos, os " +"Considerando que os requisitos de ``install_requires`` são mínimos, os " "arquivos de requisitos frequentemente contêm uma lista exaustiva de versões " -"fixadas com o propósito de alcançar :ref:`instalações repetíveis ` de um ambiente completo." +"fixadas com o propósito de alcançar :ref:`instalações repetíveis " +"` de um ambiente completo." #: ../source/discussions/install-requires-vs-requirements.rst:78 msgid "" @@ -774,9 +772,9 @@ msgid "" "packages. [1]_" msgstr "" "Considerando que os requisitos de ``install_requires`` são \"abstratos\", ou " -"seja, não estão associados a nenhum índice em particular, os arquivos " -"requirements geralmente contêm opções de pip como ``--index-url`` ou ``--" -"find-links`` para fazer requisitos \"concreto \", isto é, associado a um " +"seja, não estão associados a nenhum índice em particular, os arquivos de " +"requisitos geralmente contêm opções de pip como ``--index-url`` ou ``--find-" +"links`` para fazer requisitos \"concreto \", isto é, associado a um " "determinado índice ou diretório de pacotes. [1]_" #: ../source/discussions/install-requires-vs-requirements.rst:84 @@ -810,6 +808,11 @@ msgid "" "Index (PyPI)>` using requirement specifiers, and automatically installing " "dependencies." msgstr "" +":ref:`easy_install `, agora `descontinuado `_, foi " +"lançado em 2004 como parte do :ref:`setuptools`. Era notável na época para " +"instalar :term:`pacotes ` do :term:`PyPI ` usando especificadores de requisitos e instalando " +"dependências automaticamente." #: ../source/discussions/pip-vs-easy-install.rst:14 msgid "" @@ -821,24 +824,33 @@ msgid "" "introducing the idea of :ref:`Requirements Files `, " "which gave users the power to easily replicate environments." msgstr "" +"O :ref:`pip` veio mais tarde em 2008, como alternativa ao :ref:`easy_install " +"`, embora ainda amplamente construído sobre os componentes " +":ref:`setuptools`. Era notável na época por *não* instalar pacotes como " +":term:`Eggs ` ou de :term:`Eggs ` (mas simplesmente como pacotes " +"\"planos\" de :term:`sdists `), e " +"introduzindo a ideia de :ref:`Arquivos de Requisitos `, que deu aos usuários o poder de replicar ambientes facilmente." #: ../source/discussions/pip-vs-easy-install.rst:22 msgid "" "Here's a breakdown of the important differences between pip and the " "deprecated easy_install:" msgstr "" +"Aqui está uma análise das diferenças importantes entre o pip e o " +"descontinuado easy_install:" #: ../source/discussions/pip-vs-easy-install.rst:25 msgid "**pip**" -msgstr "" +msgstr "**pip**" #: ../source/discussions/pip-vs-easy-install.rst:25 msgid "**easy_install**" -msgstr "" +msgstr "**easy_install**" #: ../source/discussions/pip-vs-easy-install.rst:27 msgid "Installs from :term:`Wheels `" -msgstr "" +msgstr "Instala de :term:`Wheels `" #: ../source/discussions/pip-vs-easy-install.rst:27 #: ../source/discussions/pip-vs-easy-install.rst:38 @@ -847,7 +859,7 @@ msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:54 #: ../source/discussions/pip-vs-easy-install.rst:57 msgid "Yes" -msgstr "" +msgstr "Sim" #: ../source/discussions/pip-vs-easy-install.rst:27 #: ../source/discussions/pip-vs-easy-install.rst:30 @@ -860,93 +872,95 @@ msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:54 #: ../source/discussions/pip-vs-easy-install.rst:57 msgid "No" -msgstr "" +msgstr "Não" #: ../source/discussions/pip-vs-easy-install.rst:30 msgid "Uninstall Packages" -msgstr "" +msgstr "Desinstala pacotes" #: ../source/discussions/pip-vs-easy-install.rst:30 msgid "Yes (``python -m pip uninstall``)" -msgstr "" +msgstr "Sim (``python -m pip uninstall``)" #: ../source/discussions/pip-vs-easy-install.rst:32 msgid "Dependency Overrides" -msgstr "" +msgstr "Substitui dependências" #: ../source/discussions/pip-vs-easy-install.rst:32 msgid "Yes (:ref:`Requirements Files `)" -msgstr "" +msgstr "Sim (:ref:`Arquivo de Requisitos `)" #: ../source/discussions/pip-vs-easy-install.rst:35 msgid "List Installed Packages" -msgstr "" +msgstr "Lista pacotes instalados" #: ../source/discussions/pip-vs-easy-install.rst:35 msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" -msgstr "" +msgstr "Sim (``python -m pip list`` e ``python -m pip freeze``)" #: ../source/discussions/pip-vs-easy-install.rst:38 msgid ":pep:`438` Support" -msgstr "" +msgstr "Suporte a :pep:`438`" #: ../source/discussions/pip-vs-easy-install.rst:41 msgid "Installation format" -msgstr "" +msgstr "Formato de instalação" #: ../source/discussions/pip-vs-easy-install.rst:41 msgid "'Flat' packages with :file:`egg-info` metadata." -msgstr "" +msgstr "Pacotes \"planos\" com metadados de :file:`egg-info`." #: ../source/discussions/pip-vs-easy-install.rst:41 msgid "Encapsulated Egg format" -msgstr "" +msgstr "Formato Egg encapsulado" #: ../source/discussions/pip-vs-easy-install.rst:44 msgid "sys.path modification" -msgstr "" +msgstr "Modificação de sys.path" #: ../source/discussions/pip-vs-easy-install.rst:48 msgid "Installs from :term:`Eggs `" -msgstr "" +msgstr "Instala de :term:`Eggs `" #: ../source/discussions/pip-vs-easy-install.rst:51 msgid "`pylauncher support`_" -msgstr "" +msgstr "`suporte a pylauncher `_" #: ../source/discussions/pip-vs-easy-install.rst:51 msgid "Yes [1]_" -msgstr "" +msgstr "Sim [1]_" #: ../source/discussions/pip-vs-easy-install.rst:54 msgid ":ref:`Multi-version Installs`" -msgstr "" +msgstr ":ref:`Instalações multiversões `" #: ../source/discussions/pip-vs-easy-install.rst:57 msgid "Exclude scripts during install" -msgstr "" +msgstr "Exclui scripts durante a instalação" #: ../source/discussions/pip-vs-easy-install.rst:60 msgid "per project index" -msgstr "" +msgstr "índice por projeto" #: ../source/discussions/pip-vs-easy-install.rst:60 msgid "Only in virtualenv" -msgstr "" +msgstr "Apenas em virtualenv" #: ../source/discussions/pip-vs-easy-install.rst:60 msgid "Yes, via setup.cfg" -msgstr "" +msgstr "Sim, via setup.cfg" #: ../source/discussions/pip-vs-easy-install.rst:68 msgid "" "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" "launcher" msgstr "" +"https://setuptools.readthedocs.io/en/latest/deprecated/easy_install.html" +"#natural-script-launcher" #: ../source/discussions/wheel-vs-egg.rst:5 msgid "Wheel vs Egg" -msgstr "" +msgstr "Wheel vs Egg" #: ../source/discussions/wheel-vs-egg.rst:7 msgid "" @@ -954,28 +968,39 @@ msgid "" "the use case of needing an install artifact that doesn't require building or " "compilation, which can be costly in testing and production workflows." msgstr "" +":term:`Wheel` e :term:`Egg` são formatos de empacotamento que visam oferecer " +"suporte ao caso de uso de necessidade de um artefato de instalação que não " +"requer construção ou compilação, o que pode ser caro em testes e fluxos de " +"trabalho de produção." #: ../source/discussions/wheel-vs-egg.rst:11 msgid "" "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas " "the :term:`Wheel` format was introduced by :pep:`427` in 2012." msgstr "" +"O formato :term:`Egg` foi introduzido por :ref:`setuptools` em 2004, " +"enquanto o formato :term:`Wheel` foi introduzido pela :pep:`427` em 2012." #: ../source/discussions/wheel-vs-egg.rst:14 msgid "" ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." msgstr "" +":term:`Wheel` é atualmente considerado o padrão para o empacotamento :term:`" +"contruído ` e :term:`binário ` para " +"Python." #: ../source/discussions/wheel-vs-egg.rst:17 msgid "" "Here's a breakdown of the important differences between :term:`Wheel` and :" "term:`Egg`." msgstr "" +"Aqui está uma análise das diferenças importantes entre :term:`Wheel` e " +":term:`Egg`." #: ../source/discussions/wheel-vs-egg.rst:20 msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." -msgstr "" +msgstr ":term:`Wheel` tem uma :pep:`PEP oficial <427>`. :term:`Egg` não tinha." #: ../source/discussions/wheel-vs-egg.rst:22 msgid "" @@ -984,6 +1009,10 @@ msgid "" "runtime installation format (if left zipped), and was designed to be " "importable." msgstr "" +":term:`Wheel` é um formato de :term:`distribuição `, " +"ou seja, um formato de empacotamento. [1]_ :term:`Egg` era um formato de " +"distribuição e um formato de instalação em tempo de execução (se deixado " +"compactado), e foi projetado para ser importável." #: ../source/discussions/wheel-vs-egg.rst:26 msgid "" @@ -993,12 +1022,19 @@ msgid "" "\"universal\", similar to an :term:`sdist `." msgstr "" +"Os arquivos :term:`Wheel` não incluem arquivos .pyc. Portanto, quando a " +"distribuição contém apenas arquivos Python (ou seja, sem extensões " +"compiladas) e é compatível com Python 2 e 3, é possível que um wheel seja " +"\"universal\", semelhante a um :term:`sdist `." #: ../source/discussions/wheel-vs-egg.rst:31 msgid "" ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. " "Egg used ``.egg-info``." msgstr "" +":term:`Wheel` usa diretórios ``.dist-info`` :pep:`compatíveis com a PEP376 " +"<376>`. Egg usava ``.egg-info``." #: ../source/discussions/wheel-vs-egg.rst:34 msgid "" @@ -1006,12 +1042,18 @@ msgid "" "wheel archive can indicate its compatibility with a number of Python " "language versions and implementations, ABIs, and system architectures." msgstr "" +": term: `Wheel` tem uma :pep:`convenção de nomenclatura de arquivo mais rica " +"<425>`. Um único arquivo de wheel pode indicar sua compatibilidade com " +"várias versões e implementações da linguagem Python, ABIs e arquiteturas de " +"sistema." #: ../source/discussions/wheel-vs-egg.rst:38 msgid "" ":term:`Wheel` is versioned. Every wheel file contains the version of the " "wheel specification and the implementation that packaged it." msgstr "" +":term:`Wheel` é versionado. Cada arquivo wheel contém a versão da " +"especificação wheel e a implementação que a empacotou." #: ../source/discussions/wheel-vs-egg.rst:41 msgid "" @@ -1019,6 +1061,9 @@ msgid "" "python.org/2/library/sysconfig.html#installation-paths>`_, therefore making " "it easier to convert to other formats." msgstr "" +": term: `Wheel` é internamente organizado pelo `tipo de caminho sysconfig " +"`_, " +"portanto tornando mais fácil converter para outros formatos." #: ../source/discussions/wheel-vs-egg.rst:47 msgid "" @@ -1026,24 +1071,30 @@ msgid "" "format, although :pep:`this is not officially supported at this time <427#is-" "it-possible-to-import-python-code-directly-from-a-wheel-file>`." msgstr "" +"Circunstancialmente, em alguns casos, wheels podem ser usados como um " +"formato de tempo de execução importável, embora :pep:`não haja suporte " +"oficial a isso no momento <427#is-it-possible-to-import-python-code-directly-" +"from-a-wheel-file>`." #: ../source/glossary.rst:3 msgid "Glossary" -msgstr "" +msgstr "Glossário" #: ../source/glossary.rst:8 msgid "Binary Distribution" -msgstr "" +msgstr "Distribuição Binária" #: ../source/glossary.rst:11 msgid "" "A specific kind of :term:`Built Distribution` that contains compiled " "extensions." msgstr "" +"Um tipo específico de :term:`Distribuição Construída` que contém extensões " +"compiladas." #: ../source/glossary.rst:14 msgid "Built Distribution" -msgstr "" +msgstr "Distribuição Construída" #: ../source/glossary.rst:17 msgid "" @@ -1055,10 +1106,18 @@ msgid "" "not imply that Python files have to be precompiled (:term:`Wheel` " "intentionally does not include compiled Python files)." msgstr "" +"Um formato de :term:`Distribuição ` contendo arquivos " +"e metadados que só precisam ser movidos para o local correto no sistema de " +"destino, para serem instalados. :term:`Wheel` é esse formato, enquanto o " +":term:`Distribuição Fonte ` do distutil " +"não é, pois requer uma etapa de construção antes de poder ser instalado. " +"Este formato não implica que os arquivos Python tenham que ser pré-" +"compilados (:term:`Wheel` intencionalmente não inclui arquivos Python " +"compilados)." #: ../source/glossary.rst:26 msgid "Distribution Package" -msgstr "" +msgstr "Pacote de Distribuição" #: ../source/glossary.rst:29 msgid "" @@ -1067,6 +1126,10 @@ msgid "" "to distribute a :term:`Release`. The archive file is what an end-user will " "download from the internet and install." msgstr "" +"Um arquivo com versão que contém :term:`pacotes ` Python, " +":term:`módulos `, e outros arquivos de recursos que são usados para " +"distribuir um :term:`Lançamento `. O arquivo é o que um usuário " +"final irá baixar da Internet e instalar." #: ../source/glossary.rst:34 msgid "" @@ -1078,10 +1141,17 @@ msgid "" "distribution), which are often referred to with the single term " "\"distribution\"." msgstr "" +"Um pacote de distribuição é mais comumente referido com as palavras \"pacote" +"\" ou \"distribuição\", mas este guia pode usar o termo expandido quando " +"mais clareza for necessária para evitar confusão com um :term:`Pacote de " +"Importação ` (que também é comumente chamado de \"pacote\") " +"ou outro tipo de distribuição (por exemplo, uma distribuição Linux ou a " +"distribuição da linguagem Python), que são frequentemente referidos com o " +"único termo \"distribuição\"." #: ../source/glossary.rst:41 msgid "Egg" -msgstr "" +msgstr "Egg" #: ../source/glossary.rst:44 msgid "" @@ -1091,10 +1161,15 @@ msgid "" "deprecated/python_eggs.html>`_ and `Python Eggs `_" msgstr "" +"Um formato :term:`Distribuição Construída` introduzido por :ref:`setuptools`" +", que está sendo substituído por :term:`Wheel`. Para obter detalhes, " +"consulte `The Internal Structure of Python Eggs `_ e `Python Eggs " +"`_" #: ../source/glossary.rst:49 msgid "Extension Module" -msgstr "" +msgstr "Módulo de Extensão" #: ../source/glossary.rst:52 msgid "" @@ -1104,10 +1179,16 @@ msgid "" "file for Python extensions on Unix, a DLL (given the .pyd extension) for " "Python extensions on Windows, or a Java class file for Jython extensions." msgstr "" +"Um :term:`Módulo ` escrito na linguagem de baixo nível da " +"implementação Python: C/C ++ para Python, Java para Jython. Normalmente " +"contido em um único arquivo pré-compilado carregável dinamicamente, por " +"exemplo, um arquivo de objeto compartilhado (.so) para extensões Python no " +"Unix, uma DLL (dada a extensão .pyd) para extensões Python no Windows ou um " +"arquivo de classe Java para extensões Jython." #: ../source/glossary.rst:59 msgid "Known Good Set (KGS)" -msgstr "" +msgstr "Known Good Set (KGS)" #: ../source/glossary.rst:62 msgid "" @@ -1117,16 +1198,24 @@ msgid "" "used by frameworks and toolkits which are comprised of multiple individual " "distributions." msgstr "" +"Um conjunto de distribuições em versões especificadas que são compatíveis " +"entre si. Normalmente, será executado um conjunto de testes que passa em " +"todos os testes antes que um conjunto específico de pacotes seja declarado " +"como um conjunto sabidamente bom (*known good set*). Este termo é comumente " +"usado por frameworks e kits de ferramentas que são compostos de várias " +"distribuições individuais." #: ../source/glossary.rst:68 msgid "Import Package" -msgstr "" +msgstr "Pacote de Importação" #: ../source/glossary.rst:71 msgid "" "A Python module which can contain other modules or recursively, other " "packages." msgstr "" +"Um módulo Python que pode conter outros módulos ou recursivamente, outros " +"pacotes." #: ../source/glossary.rst:74 msgid "" @@ -1135,30 +1224,39 @@ msgid "" "prevent confusion with a :term:`Distribution Package` which is also commonly " "called a \"package\"." msgstr "" +"Um pacote de importação é mais comumente referido com a única palavra " +"\"pacote\", mas este guia usará o termo expandido quando mais clareza for " +"necessária para evitar confusão com um :term:`Pacote de Distribuição` que " +"também é comumente chamado de \"pacote\" ." #: ../source/glossary.rst:78 msgid "Module" -msgstr "" +msgstr "Módulo" #: ../source/glossary.rst:81 msgid "" "The basic unit of code reusability in Python, existing in one of two types: :" "term:`Pure Module`, or :term:`Extension Module`." msgstr "" +"A unidade básica de reutilização de código em Python, existindo em um dos " +"dois tipos: :term:`Módulo Puro ` ou :term:`Módulo de Extensão " +"`." #: ../source/glossary.rst:84 msgid "Package Index" -msgstr "" +msgstr "Índice de Pacotes" #: ../source/glossary.rst:87 msgid "" "A repository of distributions with a web interface to automate :term:" "`package ` discovery and consumption." msgstr "" +"Um repositório de distribuições com uma interface web para automatizar " +"descoberta e consumo de :term:`pacotes `." #: ../source/glossary.rst:90 msgid "Per Project Index" -msgstr "" +msgstr "Índice Por Projeto" #: ../source/glossary.rst:93 msgid "" @@ -1166,10 +1264,13 @@ msgid "" "specific :term:`Project` as the index preferred or required to resolve " "dependencies of that project." msgstr "" +"Um :term:`Índice de Pacotes ` privado ou outro não canônico " +"indicado por um :term:`Projeto ` específico como o índice preferido " +"ou necessário para resolver dependências desse projeto." #: ../source/glossary.rst:97 msgid "Project" -msgstr "" +msgstr "Projeto" #: ../source/glossary.rst:100 msgid "" @@ -1177,6 +1278,9 @@ msgid "" "other resources, or some combination thereof that is intended to be packaged " "into a :term:`Distribution `." msgstr "" +"Uma biblioteca, estrutura, script, plugin, aplicação ou coleção de dados ou " +"outros recursos, ou alguma combinação dos mesmos que se destina a ser " +"empacotado em uma :term:`Distribuição `." #: ../source/glossary.rst:104 msgid "" @@ -1186,6 +1290,11 @@ msgid "" "something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:" "`setup.cfg` file at the root of the project source directory." msgstr "" +"Como a maioria dos projetos cria :term:`Distribuições `" +" usando ``build-system`` da :pep:`518`, :ref:`distutils` ou :ref:`setuptools`" +", outra maneira prática de definir projetos atualmente é algo que contém um " +"arquivo :term:`pyproject.toml`, :term:`setup.py` ou :term:`setup.cfg` na " +"raiz do diretório fonte do projeto." #: ../source/glossary.rst:110 msgid "" @@ -1194,6 +1303,10 @@ msgid "" "term:`Releases `, and each release may comprise one or more :term:" "`distributions `." msgstr "" +"Projetos Python devem ter nomes únicos, que são registrados no :term:`PyPI " +"`. Cada projeto conterá então um ou mais :term:`" +"Lançamentos `, e cada lançamento pode incluir uma ou mais :term:`" +"distribuições `." #: ../source/glossary.rst:115 msgid "" @@ -1202,20 +1315,26 @@ msgid "" "to hold true. It's possible to install a distribution from the project 'foo' " "and have it provide a package importable only as 'bar'." msgstr "" +"Observe que há uma forte convenção para dar o nome do projeto ao pacote que " +"é importado para executar esse projeto. No entanto, isso não é obrigatório. " +"É possível instalar uma distribuição do projeto \"foo\" e fazer com que ele " +"forneça um pacote importável apenas como \"bar\"." #: ../source/glossary.rst:121 msgid "Pure Module" -msgstr "" +msgstr "Módulo Puro" #: ../source/glossary.rst:124 msgid "" "A :term:`Module` written in Python and contained in a single ``.py`` file " "(and possibly associated ``.pyc`` and/or ``.pyo`` files)." msgstr "" +"Um :term:`Módulo ` escrito em Python e contido em um único arquivo ``" +".py`` (e possivelmente arquivos ``.pyc`` e/ou ``.pyo`` associados)." #: ../source/glossary.rst:127 msgid "Python Packaging Authority (PyPA)" -msgstr "" +msgstr "Python Packaging Authority (PyPA)" #: ../source/glossary.rst:130 msgid "" @@ -1226,10 +1345,17 @@ msgid "" "python.org/mailman3/lists/distutils-sig.python.org/>`_ and `the Python " "Discourse forum `__." msgstr "" +"PyPA é um grupo de trabalho que mantém muitos dos projetos relevantes em " +"pacotes Python. Eles mantêm um site em https://www.pypa.io, hospedam " +"projetos no `GitHub `_ e `Bitbucket " +"`_, e discutem questões na `lista de discussão " +"distutils-sig `_ e `o fórum Discourse do Python `__." #: ../source/glossary.rst:139 msgid "Python Package Index (PyPI)" -msgstr "" +msgstr "Python Package Index (PyPI)" #: ../source/glossary.rst:142 msgid "" @@ -1237,10 +1363,13 @@ msgid "" "Python community. It is open to all Python developers to consume and " "distribute their distributions." msgstr "" +"`PyPI ` _ é o :term:`Índice de Pacotes ` " +"padrão para a comunidade Python. Está aberto a todos os desenvolvedores " +"Python para consumir e distribuir suas distribuições." #: ../source/glossary.rst:145 msgid "pypi.org" -msgstr "" +msgstr "pypi.org" #: ../source/glossary.rst:148 msgid "" @@ -1248,25 +1377,32 @@ msgid "" "Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi." "python.org``, in 2017. It is powered by :ref:`warehouse`." msgstr "" +"`pypi.org `_ é o nome de domínio do :term:`Python Package " +"Index (PyPI)`. Ele substituiu o nome de domínio do índice legado, ``pypi." +"python.org``, em 2017. Ele é tornado possível pelo :ref:`warehouse`." #: ../source/glossary.rst:152 msgid "pyproject.toml" -msgstr "" +msgstr "pyproject.toml" #: ../source/glossary.rst:155 msgid "" "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." msgstr "" +"O arquivo de especificação agnóstica de ferramenta para :term:`Projetos " +"`. Definido na :pep:`518`." #: ../source/glossary.rst:157 msgid "Release" -msgstr "" +msgstr "Lançamento" #: ../source/glossary.rst:160 msgid "" "A snapshot of a :term:`Project` at a particular point in time, denoted by a " "version identifier." msgstr "" +"Um snapshot de um :term:`Projeto ` em um determinado ponto no " +"tempo, denotado por um identificador de versão." #: ../source/glossary.rst:163 msgid "" @@ -1275,10 +1411,14 @@ msgid "" "released, it could be available in both a source distribution format and a " "Windows installer distribution format." msgstr "" +"Fazer um lançamento pode implicar na publicação de várias :term:`" +"Distribuições `. Por exemplo, se a versão 1.0 de um " +"projeto foi lançada, ele pode estar disponível em um formato de distribuição " +"fonte e um formato de distribuição de instalador do Windows." #: ../source/glossary.rst:168 msgid "Requirement" -msgstr "" +msgstr "Requisito" #: ../source/glossary.rst:171 msgid "" @@ -1288,10 +1428,15 @@ msgid "" "considered a \"requirement\". For more information, see the :ref:`pip:pip " "install` reference." msgstr "" +"Uma especificação para uma :term:`pacote ` a ser " +"instalado. :ref:`pip`, o instalador recomendado do :term:`PYPA `, permite várias formas de especificação que " +"podem ser consideradas um \"requisito\". Para obter mais informações, " +"consulte a referência de :ref:`pip:pip install`." #: ../source/glossary.rst:177 msgid "Requirement Specifier" -msgstr "" +msgstr "Especificador de Requisitos" #: ../source/glossary.rst:180 msgid "" @@ -1302,10 +1447,17 @@ msgid "" "example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the " "project name, and the \">=1.3\" portion is the :term:`Version Specifier`" msgstr "" +"Um formato usado por :ref:`pip` para instalar pacotes de um :term:`Índice de " +"Pacotes `. Para um diagrama EBNF do formato, veja a entrada `" +"pkg_resources.Requirement `_ na documentação do " +":ref:`setuptools`. Por exemplo, \"foo>=1.3\" é um especificador de " +"requisitos, onde \"foo\" é o nome do projeto e a parte \">=1.3\" é o :term:`" +"Especificador de Versão`" #: ../source/glossary.rst:187 msgid "Requirements File" -msgstr "" +msgstr "Arquivo de Requisitos" #: ../source/glossary.rst:190 msgid "" @@ -1313,26 +1465,31 @@ msgid "" "installed using :ref:`pip`. For more information, see the :ref:`pip` docs " "on :ref:`pip:Requirements Files`." msgstr "" +"Um arquivo contendo uma lista de :term:`Requisitos ` que podem " +"ser instalados usando :ref:`pip`. Para mais informações, veja a documentação " +":ref:`pip` em :ref:`pip:Requirements Files`." #: ../source/glossary.rst:194 #: ../source/guides/distributing-packages-using-setuptools.rst:56 msgid "setup.py" -msgstr "" +msgstr "setup.py" #: ../source/glossary.rst:195 #: ../source/guides/distributing-packages-using-setuptools.rst:77 msgid "setup.cfg" -msgstr "" +msgstr "setup.cfg" #: ../source/glossary.rst:198 msgid "" "The project specification files for :ref:`distutils` and :ref:`setuptools`. " "See also :term:`pyproject.toml`." msgstr "" +"Os arquivos de especificação do projeto para :ref:`distutils` e " +":ref:`setuptools`. Veja também:term:`pyproject.toml`." #: ../source/glossary.rst:201 msgid "Source Archive" -msgstr "" +msgstr "Arquivo Fonte" #: ../source/glossary.rst:204 msgid "" @@ -1340,10 +1497,13 @@ msgid "" "creation of a :term:`Source Distribution ` or :term:`Built Distribution`." msgstr "" +"Um arquivo contendo o código-fonte bruto para um :term:`Lançamento `" +", antes da criação de uma :term:`Distribuição Fonte ` ou :term:`Distribuição Construída `." #: ../source/glossary.rst:208 msgid "Source Distribution (or \"sdist\")" -msgstr "" +msgstr "Distribuição Fonte (ou \"sdist\")" #: ../source/glossary.rst:211 msgid "" @@ -1352,20 +1512,26 @@ msgid "" "source files needed for installing by a tool like :ref:`pip`, or for " "generating a :term:`Built Distribution`." msgstr "" +"Um formato de :term:`distribuição ` (geralmente gerado " +"usando ``python setup.py sdist``) que fornece metadados e os arquivos-fonte " +"essenciais necessários para a instalação por uma ferramenta como :ref:`pip`, " +"ou para gerar uma :term:`Distribuição Construída `." #: ../source/glossary.rst:216 msgid "System Package" -msgstr "" +msgstr "Pacote de Sistemas" #: ../source/glossary.rst:219 msgid "" "A package provided in a format native to the operating system, e.g. an rpm " "or dpkg file." msgstr "" +"Um pacote fornecido em um formato nativo para o sistema operacional, por " +"exemplo, um arquivo rpm ou dpkg." #: ../source/glossary.rst:222 msgid "Version Specifier" -msgstr "" +msgstr "Especificador de Versão" #: ../source/glossary.rst:225 msgid "" @@ -1375,10 +1541,15 @@ msgid "" "packaging currently supports. Support for PEP440 was implemented in :ref:" "`setuptools` v8.0 and :ref:`pip` v6.0." msgstr "" +"O componente de versão de um :term:`Especificador de Requisitos `. Por exemplo, a parte \">=1.3\" de \"foo>=1.3\". A :pep:`440` " +"contém uma :pep:`especificação completa <440#version-specifiers>` dos " +"especificadores que o pacote Python oferece suporte atualmente. O suporte " +"para PEP440 foi implementado em :ref:`setuptools` v8.0 e :ref:`pip` v6.0." #: ../source/glossary.rst:231 msgid "Virtual Environment" -msgstr "" +msgstr "Ambiente Virtual" #: ../source/glossary.rst:234 msgid "" @@ -1387,10 +1558,14 @@ msgid "" "more information, see the section on :ref:`Creating and using Virtual " "Environments`." msgstr "" +"Um ambiente Python isolado que permite que os pacotes sejam instalados para " +"uso por um aplicativo específico, em vez de serem instalados em todo o " +"sistema. Para obter mais informações, consulte a seção sobre :ref:`Criando e " +"usando ambientes virtuais `." #: ../source/glossary.rst:238 msgid "Wheel" -msgstr "" +msgstr "Wheel" #: ../source/glossary.rst:241 msgid "" @@ -1398,10 +1573,13 @@ msgid "" "intended to replace the :term:`Egg` format. Wheel is currently supported " "by :ref:`pip`." msgstr "" +"Um formato de :term:`Distribuição Construída` introduzido por :pep:`427`, " +"que se destina a substituir o formato :term:`Egg`. O Wheel é atualmente " +"suportado pelo :ref:`pip`." #: ../source/glossary.rst:244 msgid "Working Set" -msgstr "" +msgstr "Conjunto de Trabalho" #: ../source/glossary.rst:247 msgid "" @@ -1410,10 +1588,14 @@ msgid "" "At most, one :term:`Distribution ` for a project is " "possible in a working set." msgstr "" +"Uma coleção de :term:`distribuições ` disponíveis para " +"importação. Estas são as distribuições que estão na variável `sys.path`. No " +"máximo, uma :term:`Distribuição ` para um projeto é " +"possível em um conjunto de trabalho." #: ../source/guides/analyzing-pypi-package-downloads.rst:3 msgid "Analyzing PyPI package downloads" -msgstr "" +msgstr "Analisando downloads de pacotes PyPI" #: ../source/guides/analyzing-pypi-package-downloads.rst:5 msgid "" @@ -1422,15 +1604,19 @@ msgid "" "example, you can use it to discover the distribution of Python versions used " "to download a package." msgstr "" +"Esta seção cobre como usar o conjunto de dados de estatísticas de download " +"público do PyPI para saber mais sobre os downloads de um pacote (ou pacotes) " +"hospedado no PyPI. Por exemplo, você pode usá-lo para descobrir a " +"distribuição das versões do Python usadas para baixar um pacote." #: ../source/guides/analyzing-pypi-package-downloads.rst:15 #: ../source/guides/supporting-windows-using-appveyor.rst:18 msgid "Background" -msgstr "" +msgstr "Contexto" #: ../source/guides/analyzing-pypi-package-downloads.rst:17 msgid "PyPI does not display download statistics for a number of reasons: [#]_" -msgstr "" +msgstr "O PyPI não exibe estatísticas de download por vários motivos: [#]_" #: ../source/guides/analyzing-pypi-package-downloads.rst:19 msgid "" @@ -1439,35 +1625,48 @@ msgid "" "which are heavily cached, would require invalidating the cache more often, " "and reduce the overall effectiveness of the cache." msgstr "" +"**Ineficiente para fazer funcionar com uma Rede de Distribuição de Conteúdo " +"(CDN):** As estatísticas de download mudam constantemente. Incluí-las nas " +"páginas do projeto, que são altamente armazenadas em cache, exigiria a " +"invalidação do cache com mais frequência e reduziria a eficácia geral do " +"cache." #: ../source/guides/analyzing-pypi-package-downloads.rst:24 msgid "" "**Highly inaccurate:** A number of things prevent the download counts from " "being accurate, some of which include:" msgstr "" +"**Altamente imprecisa:** Várias coisas impedem que as contagens de download " +"sejam precisas, algumas das quais incluem:" #: ../source/guides/analyzing-pypi-package-downloads.rst:27 msgid "``pip``'s download cache (lowers download counts)" -msgstr "" +msgstr "Cache de download do ``pip`` (diminui a contagem de downloads)" #: ../source/guides/analyzing-pypi-package-downloads.rst:28 msgid "" "Internal or unofficial mirrors (can both raise or lower download counts)" msgstr "" +"Espelhos internos ou não oficiais (pode aumentar ou diminuir as contagens de " +"download)" #: ../source/guides/analyzing-pypi-package-downloads.rst:29 msgid "Packages not hosted on PyPI (for comparisons sake)" -msgstr "" +msgstr "Pacotes não hospedados no PyPI (para fins de comparação)" #: ../source/guides/analyzing-pypi-package-downloads.rst:30 msgid "" "Unofficial scripts or attempts at download count inflation (raises download " "counts)" msgstr "" +"Scripts não oficiais ou tentativas de aumento da contagem de download (" +"aumenta a contagem de downloads)" #: ../source/guides/analyzing-pypi-package-downloads.rst:32 msgid "Known historical data quality issues (lowers download counts)" msgstr "" +"Problemas conhecidos de qualidade de dados históricos (diminui a contagem de " +"downloads)" #: ../source/guides/analyzing-pypi-package-downloads.rst:34 msgid "" @@ -1475,6 +1674,9 @@ msgid "" "lot doesn't mean it's good; Similarly just because a project hasn't been " "downloaded a lot doesn't mean it's bad!" msgstr "" +"**Não é particularmente útil:** Só porque um projeto foi muito baixado, não " +"significa que ele seja bom; Da mesma forma, só porque um projeto não foi " +"muito baixado, não significa que ele seja ruim!" #: ../source/guides/analyzing-pypi-package-downloads.rst:38 msgid "" @@ -1482,10 +1684,13 @@ msgid "" "required to make it work are high, it has been not an effective use of " "limited resources." msgstr "" +"Resumindo, como seu valor é baixo por vários motivos e as compensações " +"necessárias para fazê-lo funcionar são altas, não tem sido um uso eficaz de " +"recursos limitados." #: ../source/guides/analyzing-pypi-package-downloads.rst:43 msgid "Public dataset" -msgstr "" +msgstr "Conjunto de dados públicos" #: ../source/guides/analyzing-pypi-package-downloads.rst:45 msgid "" @@ -1493,10 +1698,13 @@ msgid "" "linehaul>`__ streams download logs from PyPI to `Google BigQuery`_ [#]_, " "where they are stored as a public dataset." msgstr "" +"Como alternativa, o `projeto Linehaul `__ " +"transmite registros de download do PyPI para o `Google BigQuery`_ [#]_, onde " +"são armazenados como um conjunto de dados público." #: ../source/guides/analyzing-pypi-package-downloads.rst:50 msgid "Getting set up" -msgstr "" +msgstr "Preparando-se" #: ../source/guides/analyzing-pypi-package-downloads.rst:52 msgid "" @@ -1507,20 +1715,29 @@ msgid "" "`__" msgstr "" +"Para usar o `Google BigQuery`_ para consultar o `conjunto de dados de " +"estatísticas de download PyPI público `_, você precisará de uma conta do Google e habilitar a API do " +"BigQuery em um projeto do Google Cloud Platform. Você pode executar até 1 TB " +"de consultas por mês `usando o free tier do BigQuery sem um cartão de " +"crédito `__" #: ../source/guides/analyzing-pypi-package-downloads.rst:58 msgid "Navigate to the `BigQuery web UI`_." -msgstr "" +msgstr "Acesse a `interface web do BigQuery `_." #: ../source/guides/analyzing-pypi-package-downloads.rst:59 msgid "Create a new project." -msgstr "" +msgstr "Crie um novo projeto." #: ../source/guides/analyzing-pypi-package-downloads.rst:60 msgid "" "Enable the `BigQuery API `__." msgstr "" +"Habilite a `API do BigQuery `__." #: ../source/guides/analyzing-pypi-package-downloads.rst:63 msgid "" @@ -1528,10 +1745,13 @@ msgid "" "out the `BigQuery quickstart guide `__." msgstr "" +"Para obter instruções mais detalhadas sobre como começar a usar o BigQuery, " +"consulte o `guia de início rápido do BigQuery `__." #: ../source/guides/analyzing-pypi-package-downloads.rst:69 msgid "Data schema" -msgstr "" +msgstr "Esquema de dados" #: ../source/guides/analyzing-pypi-package-downloads.rst:71 msgid "" @@ -1541,37 +1761,42 @@ msgid "" "schema `__ include:" msgstr "" +"Linehaul escreve uma entrada em uma tabela ``bigquery-public-data.pypi." +"file_downloads`` para cada download. A tabela contém informações sobre qual " +"arquivo foi baixado e como foi baixado. Algumas colunas úteis do `esquema da " +"tabela `__ inclui:" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 msgid "Column" -msgstr "" +msgstr "Coluna" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 #: ../source/guides/using-manifest-in.rst:67 #: ../source/specifications/core-metadata.rst:185 msgid "Description" -msgstr "" +msgstr "Descrição" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 #: ../source/specifications/direct-url.rst:226 msgid "Examples" -msgstr "" +msgstr "Exemplos" #: ../source/guides/analyzing-pypi-package-downloads.rst:80 msgid "timestamp" -msgstr "" +msgstr "timestamp" #: ../source/guides/analyzing-pypi-package-downloads.rst:80 msgid "Date and time" -msgstr "" +msgstr "Data e hora" #: ../source/guides/analyzing-pypi-package-downloads.rst:80 msgid "``2020-03-09 00:33:03 UTC``" -msgstr "" +msgstr "``2020-03-09 00:33:03 UTC``" #: ../source/guides/analyzing-pypi-package-downloads.rst:82 msgid "file.project" -msgstr "" +msgstr "file.project" #: ../source/guides/analyzing-pypi-package-downloads.rst:82 msgid "Project name" @@ -1579,35 +1804,35 @@ msgstr "Nome do projeto" #: ../source/guides/analyzing-pypi-package-downloads.rst:82 msgid "``pipenv``, ``nose``" -msgstr "" +msgstr "``pipenv``, ``nose``" #: ../source/guides/analyzing-pypi-package-downloads.rst:84 msgid "file.version" -msgstr "" +msgstr "file.version" #: ../source/guides/analyzing-pypi-package-downloads.rst:84 msgid "Package version" -msgstr "" +msgstr "Versão do pacote" #: ../source/guides/analyzing-pypi-package-downloads.rst:84 msgid "``0.1.6``, ``1.4.2``" -msgstr "" +msgstr "``0.1.6``, ``1.4.2``" #: ../source/guides/analyzing-pypi-package-downloads.rst:86 msgid "details.installer.name" -msgstr "" +msgstr "details.installer.name" #: ../source/guides/analyzing-pypi-package-downloads.rst:86 msgid "Installer" -msgstr "" +msgstr "Instalador" #: ../source/guides/analyzing-pypi-package-downloads.rst:86 msgid "pip, `bandersnatch`_" -msgstr "" +msgstr "pip, `bandersnatch`_" #: ../source/guides/analyzing-pypi-package-downloads.rst:88 msgid "details.python" -msgstr "" +msgstr "details.python" #: ../source/guides/analyzing-pypi-package-downloads.rst:88 msgid "Python version" @@ -1615,17 +1840,19 @@ msgstr "Versão do python" #: ../source/guides/analyzing-pypi-package-downloads.rst:88 msgid "``2.7.12``, ``3.6.4``" -msgstr "" +msgstr "``2.7.12``, ``3.6.4``" #: ../source/guides/analyzing-pypi-package-downloads.rst:93 msgid "Useful queries" -msgstr "" +msgstr "Consultas úteis" #: ../source/guides/analyzing-pypi-package-downloads.rst:95 msgid "" "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" " "button." msgstr "" +"Executa consultas na `interface web do BigQuery`_ clicando no botão \"Compose" +" query\"." #: ../source/guides/analyzing-pypi-package-downloads.rst:97 msgid "" @@ -1633,165 +1860,175 @@ msgid "" "of queries. These example queries analyze downloads from recent history by " "filtering on the ``timestamp`` column." msgstr "" +"Observe que as linhas são armazenadas em uma partição particionada, o que " +"ajuda a limitar o custo das consultas. Essas consultas de exemplo analisam " +"downloads do histórico recente filtrando na coluna ``timestamp``." #: ../source/guides/analyzing-pypi-package-downloads.rst:102 msgid "Counting package downloads" -msgstr "" +msgstr "Contando downloads de pacotes" #: ../source/guides/analyzing-pypi-package-downloads.rst:104 msgid "" "The following query counts the total number of downloads for the project " "\"pytest\"." msgstr "" +"A consulta a seguir conta o número total de downloads do projeto \"pytest\"." #: ../source/guides/analyzing-pypi-package-downloads.rst:119 #: ../source/guides/analyzing-pypi-package-downloads.rst:140 #: ../source/guides/analyzing-pypi-package-downloads.rst:168 #: ../source/guides/analyzing-pypi-package-downloads.rst:205 msgid "num_downloads" -msgstr "" +msgstr "num_downloads" #: ../source/guides/analyzing-pypi-package-downloads.rst:121 msgid "26190085" -msgstr "" +msgstr "26190085" #: ../source/guides/analyzing-pypi-package-downloads.rst:124 msgid "" "To only count downloads from pip, filter on the ``details.installer.name`` " "column." msgstr "" +"Para contar apenas os downloads do pip, filtre na coluna ``details.installer." +"name``." #: ../source/guides/analyzing-pypi-package-downloads.rst:142 msgid "24334215" -msgstr "" +msgstr "24334215" #: ../source/guides/analyzing-pypi-package-downloads.rst:146 msgid "Package downloads over time" -msgstr "" +msgstr "Downloads de pacotes ao longo do tempo" #: ../source/guides/analyzing-pypi-package-downloads.rst:148 msgid "" "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also " "filtering by this column reduces corresponding costs." msgstr "" +"Para agrupar por downloads mensais, use a função ``TIMESTAMP_TRUNC``. Além " +"disso, a filtragem por esta coluna reduz os custos correspondentes." #: ../source/guides/analyzing-pypi-package-downloads.rst:168 msgid "month" -msgstr "" +msgstr "mês" #: ../source/guides/analyzing-pypi-package-downloads.rst:170 msgid "1956741" -msgstr "" +msgstr "1956741" #: ../source/guides/analyzing-pypi-package-downloads.rst:170 msgid "2018-01-01" -msgstr "" +msgstr "2018-01-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:172 msgid "2344692" -msgstr "" +msgstr "2344692" #: ../source/guides/analyzing-pypi-package-downloads.rst:172 msgid "2017-12-01" -msgstr "" +msgstr "2017-12-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:174 msgid "1730398" -msgstr "" +msgstr "1730398" #: ../source/guides/analyzing-pypi-package-downloads.rst:174 msgid "2017-11-01" -msgstr "" +msgstr "2017-11-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:176 msgid "2047310" -msgstr "" +msgstr "2047310" #: ../source/guides/analyzing-pypi-package-downloads.rst:176 msgid "2017-10-01" -msgstr "" +msgstr "2017-10-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:178 msgid "1744443" -msgstr "" +msgstr "1744443" #: ../source/guides/analyzing-pypi-package-downloads.rst:178 msgid "2017-09-01" -msgstr "" +msgstr "2017-09-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:180 msgid "1916952" -msgstr "" +msgstr "1916952" #: ../source/guides/analyzing-pypi-package-downloads.rst:180 msgid "2017-08-01" -msgstr "" +msgstr "2017-08-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:184 msgid "Python versions over time" -msgstr "" +msgstr "Versões Python ao longo do tempo" #: ../source/guides/analyzing-pypi-package-downloads.rst:186 msgid "" "Extract the Python version from the ``details.python`` column. Warning: This " "query processes over 500 GB of data." msgstr "" +"Extrai a versão Python da coluna ``details.python``. Aviso: esta consulta " +"processa mais de 500 GB de dados." #: ../source/guides/analyzing-pypi-package-downloads.rst:205 msgid "python" -msgstr "" +msgstr "python" #: ../source/guides/analyzing-pypi-package-downloads.rst:207 msgid "3.7" -msgstr "" +msgstr "3.7" #: ../source/guides/analyzing-pypi-package-downloads.rst:207 msgid "18051328726" -msgstr "" +msgstr "18051328726" #: ../source/guides/analyzing-pypi-package-downloads.rst:209 msgid "3.6" -msgstr "" +msgstr "3.6" #: ../source/guides/analyzing-pypi-package-downloads.rst:209 msgid "9635067203" -msgstr "" +msgstr "9635067203" #: ../source/guides/analyzing-pypi-package-downloads.rst:211 msgid "3.8" -msgstr "" +msgstr "3.8" #: ../source/guides/analyzing-pypi-package-downloads.rst:211 msgid "7781904681" -msgstr "" +msgstr "7781904681" #: ../source/guides/analyzing-pypi-package-downloads.rst:213 msgid "2.7" -msgstr "" +msgstr "2.7" #: ../source/guides/analyzing-pypi-package-downloads.rst:213 msgid "6381252241" -msgstr "" +msgstr "6381252241" #: ../source/guides/analyzing-pypi-package-downloads.rst:215 msgid "null" -msgstr "" +msgstr "null" #: ../source/guides/analyzing-pypi-package-downloads.rst:215 msgid "2026630299" -msgstr "" +msgstr "2026630299" #: ../source/guides/analyzing-pypi-package-downloads.rst:217 msgid "3.5" -msgstr "" +msgstr "3.5" #: ../source/guides/analyzing-pypi-package-downloads.rst:217 msgid "1894153540" -msgstr "" +msgstr "1894153540" #: ../source/guides/analyzing-pypi-package-downloads.rst:221 msgid "Caveats" -msgstr "" +msgstr "Ressalvas" #: ../source/guides/analyzing-pypi-package-downloads.rst:223 msgid "" @@ -1801,20 +2038,27 @@ msgid "" "accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total " "numbers are lower than actual by an order of magnitude." msgstr "" +"Além das advertências listadas no histórico acima, Linehaul sofreu de um bug " +"que causou um subestimamento das estatísticas de download antes de 26 de " +"julho de 2018. Downloads antes dessa data são proporcionalmente precisos (" +"por exemplo, a porcentagem de Python 2 vs. Python 3 downloads), mas os " +"números totais são menores do que o real em uma ordem de magnitude." #: ../source/guides/analyzing-pypi-package-downloads.rst:231 msgid "Additional tools" -msgstr "" +msgstr "Ferramentas adicionais" #: ../source/guides/analyzing-pypi-package-downloads.rst:233 msgid "" "Besides using the BigQuery console, there are some additional tools which " "may be useful when analyzing download statistics." msgstr "" +"Além de usar o console do BigQuery, existem algumas ferramentas adicionais " +"que podem ser úteis ao analisar estatísticas de download." #: ../source/guides/analyzing-pypi-package-downloads.rst:237 msgid "``google-cloud-bigquery``" -msgstr "" +msgstr "``google-cloud-bigquery``" #: ../source/guides/analyzing-pypi-package-downloads.rst:239 msgid "" @@ -1822,10 +2066,14 @@ msgid "" "programmatically via the BigQuery API and the `google-cloud-bigquery`_ " "project, the official Python client library for BigQuery." msgstr "" +"Você também pode acessar o conjunto de dados público de estatísticas de " +"download PyPI de maneira programática por meio da API do BigQuery e do " +"projeto `google-cloud-bigquery`_, a biblioteca cliente oficial do Python " +"para BigQuery." #: ../source/guides/analyzing-pypi-package-downloads.rst:267 msgid "``pypinfo``" -msgstr "" +msgstr "``pypinfo``" #: ../source/guides/analyzing-pypi-package-downloads.rst:269 msgid "" @@ -1833,44 +2081,53 @@ msgid "" "can generate several useful queries. For example, you can query the total " "number of download for a package with the command ``pypinfo package_name``." msgstr "" +"`pypinfo`_ é uma ferramenta de linha de comando que fornece acesso ao " +"conjunto de dados e pode gerar várias consultas úteis. Por exemplo, você " +"pode consultar o número total de downloads de um pacote com o comando ``" +"pypinfo package_name``." #: ../source/guides/analyzing-pypi-package-downloads.rst:273 msgid "Install `pypinfo`_ using pip." -msgstr "" +msgstr "Instale `pypinfo`_ usando o pip." #: ../source/guides/analyzing-pypi-package-downloads.rst:279 msgid "Usage:" -msgstr "" +msgstr "Uso:" #: ../source/guides/analyzing-pypi-package-downloads.rst:295 msgid "``pandas-gbq``" -msgstr "" +msgstr "``pandas-gbq``" #: ../source/guides/analyzing-pypi-package-downloads.rst:297 msgid "" "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." msgstr "" +"O projeto `pandas-gbq`_ permite acessar resultados de pesquisa com `Pandas`_." #: ../source/guides/analyzing-pypi-package-downloads.rst:301 #: ../source/specifications/binary-distribution-format.rst:459 msgid "References" -msgstr "" +msgstr "Referências" #: ../source/guides/analyzing-pypi-package-downloads.rst:303 msgid "" "`PyPI Download Counts deprecation email `__" msgstr "" +"`E-mail de descontinuação das contagens de download do PyPI `__" #: ../source/guides/analyzing-pypi-package-downloads.rst:304 msgid "" "`PyPI BigQuery dataset announcement email `__" msgstr "" +"`E-mail de anúncio do conjunto de dados BigQuery do PyPI `__" #: ../source/guides/creating-and-discovering-plugins.rst:3 msgid "Creating and discovering plugins" -msgstr "" +msgstr "Criando e descobrindo plug-ins" #: ../source/guides/creating-and-discovering-plugins.rst:5 msgid "" @@ -1879,26 +2136,33 @@ msgid "" "packages can be separately distributed, your application or library may want " "to automatically **discover** all of the plugins available." msgstr "" +"Frequentemente, ao criar um aplicativo ou biblioteca Python, você desejará " +"ter a capacidade de fornecer personalizações ou recursos extras por meio de " +"**plug-ins**. Como os pacotes Python podem ser distribuídos separadamente, " +"seu aplicativo ou biblioteca pode querer **descobrir** automaticamente todos " +"os plugins disponíveis." #: ../source/guides/creating-and-discovering-plugins.rst:10 msgid "There are three major approaches to doing automatic plugin discovery:" msgstr "" +"Existem três abordagens principais para fazer a descoberta automática de " +"plugins:" #: ../source/guides/creating-and-discovering-plugins.rst:12 msgid "`Using naming convention`_." -msgstr "" +msgstr "`Usando convenção de nomenclatura `_." #: ../source/guides/creating-and-discovering-plugins.rst:13 msgid "`Using namespace packages`_." -msgstr "" +msgstr "`Usando pacotes de espaço de nomes `_." #: ../source/guides/creating-and-discovering-plugins.rst:14 msgid "`Using package metadata`_." -msgstr "" +msgstr "`Usando metadados de pacote `_." #: ../source/guides/creating-and-discovering-plugins.rst:18 msgid "Using naming convention" -msgstr "" +msgstr "Usando convenção de nomenclatura" #: ../source/guides/creating-and-discovering-plugins.rst:20 msgid "" @@ -1908,12 +2172,20 @@ msgid "" "uses the naming convention ``flask_{plugin_name}``. If you wanted to " "automatically discover all of the Flask plugins installed:" msgstr "" +"Se todos os plugins para seu aplicativo seguem a mesma convenção de " +"nomenclatura, você pode usar :func:`pkgutil.iter_modules` para descobrir " +"todos os módulos de nível superior que correspondem à convenção de " +"nomenclatura. Por exemplo, `Flask`_ usa a convenção de nomenclatura " +"``flask_{nome_plugin}``. Se você quiser descobrir automaticamente todos os " +"plugins Flask instalados:" #: ../source/guides/creating-and-discovering-plugins.rst:38 msgid "" "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins " "installed then ``discovered_plugins`` would be:" msgstr "" +"Se você tivesse os plugins `Flask-SQLAlchemy`_ e `Flask-Talisman`_ " +"instalados, então ``discover_plugins`` seria:" #: ../source/guides/creating-and-discovering-plugins.rst:48 msgid "" @@ -1921,10 +2193,14 @@ msgid "" "Package Index's `simple API`_ for all packages that conform to your naming " "convention." msgstr "" +"Usar a convenção de nomenclatura para plugins também permite que você " +"consulte a `API simples `_ do Índice de Pacotes Python para " +"todos os pacotes que estão em conformidade com a sua convenção de " +"nomenclatura." #: ../source/guides/creating-and-discovering-plugins.rst:59 msgid "Using namespace packages" -msgstr "" +msgstr "Usando pacotes de espaço de nomes" #: ../source/guides/creating-and-discovering-plugins.rst:61 msgid "" @@ -1936,6 +2212,14 @@ msgid "" "installed, you can use :func:`pkgutil.iter_modules` to discover all modules " "and packages installed under that namespace:" msgstr "" +":doc:`Pacotes de espaços de nome ` podem ser " +"usados para fornecer uma convenção de onde colocar plugins e também fornece " +"uma maneira de realizar a descoberta. Por exemplo, se você fizer do " +"subpacote ``myapp.plugins`` um pacote de espaço de nomes, então outras " +":term:`distribuições ` pode fornecer módulos e pacotes " +"para aquele espaço de nomes. Uma vez instalado, você pode usar :func:`pkgutil" +".iter_modules` para descobrir todos os módulos e pacotes instalados sob esse " +"espaço de nomes:" #: ../source/guides/creating-and-discovering-plugins.rst:89 msgid "" @@ -1945,6 +2229,11 @@ msgid "" "``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in " "this case would be:" msgstr "" +"Especificar ``myapp.plugins.__path__`` para :func:`~pkgutil.iter_modules` " +"faz com que ele procure apenas os módulos diretamente sob aquele espaço de " +"nomes. Por exemplo, se você instalou distribuições que fornecem os módulos " +"``myapp.plugins.a`` e ``myapp.plugins.b``, então ``found_plugins`` neste " +"caso seria:" #: ../source/guides/creating-and-discovering-plugins.rst:101 msgid "" @@ -1962,6 +2251,21 @@ msgid "" "explicitly pass a list of packages to :func:`setup`'s ``packages`` argument " "instead of using :func:`setuptools.find_packages`." msgstr "" +"Este exemplo usa um subpacote como o pacote de espaço de nomes (``myapp." +"plugins``), mas também é possível usar um pacote de nível superior para este " +"propósito (como ``myapp_plugins``). Como escolher o espaço de nomes a ser " +"usado é uma questão de preferência, mas não é recomendado fazer do pacote de " +"nível superior principal do seu projeto (``myapp``, neste caso) um pacote de " +"espaço de nomes para fins de plugins, como um plugin ruim poderia fazer com " +"que todo o espaço de nomes seja interrompido, o que, por sua vez, tornaria " +"seu projeto não importável. Para que a abordagem de \"subpacote de espaço de " +"nomes\" funcione, os pacotes de plugin devem omitir o :file:`__init__.py` " +"para o diretório de pacote de nível superior (``myapp``, neste caso) e " +"incluir o estilo de pacote de espaço de nomes :file:`__init__.py` no " +"diretório do subpacote de espaço de nomes (``myapp/plugins``). Isso também " +"significa que os plugins precisarão passar explicitamente uma lista de " +"pacotes para o argumento ``packages`` de :func:`setup` ao invés de usar " +":func:`setuptools.find_packages`." #: ../source/guides/creating-and-discovering-plugins.rst:115 msgid "" @@ -1970,10 +2274,14 @@ msgid "" "namespace-packages` documentation and clearly document which approach is " "preferred for plugins to your project." msgstr "" +"Os pacotes de espaço de nomes são um recurso complexo e existem várias " +"maneiras diferentes de criá-los. É altamente recomendado ler a documentação " +"de :doc:`packaging-namespace-packages` e documentar claramente qual " +"abordagem é preferida para plugins em seu projeto." #: ../source/guides/creating-and-discovering-plugins.rst:121 msgid "Using package metadata" -msgstr "" +msgstr "Usando metadados de pacote" #: ../source/guides/creating-and-discovering-plugins.rst:123 msgid "" @@ -1982,12 +2290,18 @@ msgid "" "func:`setup` in :file:`setup.py` plugins can register themselves for " "discovery." msgstr "" +"`Setuptools`_ fornece :doc:`suporte especial ` para plugins. Fornecendo o argumento ``entry_points`` para " +":func:`setup` em :file:`setup.py`, os plugins podem se registrar para serem " +"descobertos." #: ../source/guides/creating-and-discovering-plugins.rst:128 msgid "" "For example if you have a package named ``myapp-plugin-a`` and it includes " "in its :file:`setup.py`:" msgstr "" +"Por exemplo, se você tem um pacote chamado ``myapp-plugin-a`` e ele inclui " +"em seu :file:`setup.py`:" #: ../source/guides/creating-and-discovering-plugins.rst:139 msgid "" @@ -1995,18 +2309,25 @@ msgid "" "func:`importlib.metadata.entry_points` (or the `backport`_ " "``importlib_metadata >= 3.6`` for Python 3.6-3.9):" msgstr "" +"Então você pode descobrir e carregar todos os pontos de entrada registrados " +"usando :func:`importlib.metadata.entry_points` (ou o `backport`_ ``" +"importlib_metadata >= 3.6`` para Python 3.6-3.9):" #: ../source/guides/creating-and-discovering-plugins.rst:154 msgid "" "In this example, ``discovered_plugins`` would be a collection of type :class:" "`importlib.metadata.EntryPoint`:" msgstr "" +"Neste exemplo, ``discover_plugins`` seria uma coleção do tipo " +":class:`importlib.metadata.EntryPoint`:" #: ../source/guides/creating-and-discovering-plugins.rst:163 msgid "" "Now the module of your choice can be imported by executing " "``discovered_plugins['a'].load()``." msgstr "" +"Agora o módulo de sua escolha pode ser importado executando " +"``discovered_plugins['a'].Load()``." #: ../source/guides/creating-and-discovering-plugins.rst:166 msgid "" @@ -2014,6 +2335,9 @@ msgid "" "has a lot of options. It's recommended to read over the entire section on :" "doc:`entry points ` ." msgstr "" +"A especificação ``entry_point`` em :file:`setup.py` é bastante flexível e " +"tem muitas opções. É recomendado ler toda a seção sobre :doc:`pontos de " +"entrada ` ." #: ../source/guides/creating-and-discovering-plugins.rst:170 msgid "" @@ -2021,10 +2345,13 @@ msgid "" "library/importlib.metadata>`, most packaging tools other than setuptools " "provide support for defining entry points." msgstr "" +"Visto que esta especificação é parte da :doc:`biblioteca padrão `, a maioria das ferramentas de empacotamento, " +"exceto setuptools, fornecem suporte para definir pontos de entrada." #: ../source/guides/distributing-packages-using-setuptools.rst:5 msgid "Packaging and distributing projects" -msgstr "" +msgstr "Empacotando e distribuindo projetos" #: ../source/guides/distributing-packages-using-setuptools.rst:7 msgid "" @@ -2032,6 +2359,9 @@ msgid "" "your own Python projects. It assumes that you are already familiar with the " "contents of the :doc:`/tutorials/installing-packages` page." msgstr "" +"Esta seção cobre os fundamentos de como configurar, empacotar e distribuir " +"seus próprios projetos Python. Ele assume que você já está familiarizado com " +"o conteúdo da página :doc:`/tutorials/installing-packages`." #: ../source/guides/distributing-packages-using-setuptools.rst:11 msgid "" @@ -2039,6 +2369,9 @@ msgid "" "development as a whole. For example, it does not provide guidance or tool " "recommendations for version control, documentation, or testing." msgstr "" +"A seção *não* visa cobrir as melhores práticas para o desenvolvimento de " +"projetos Python como um todo. Por exemplo, ele não fornece orientação ou " +"recomendações de ferramentas para controle de versão, documentação ou teste." #: ../source/guides/distributing-packages-using-setuptools.rst:15 msgid "" @@ -2047,20 +2380,26 @@ msgid "" "some advisory content there may be outdated. In the event of conflicts, " "prefer the advice in the Python Packaging User Guide." msgstr "" +"Para mais material de referência, veja :std:doc:`Construindo e Distribuindo " +"Pacotes ` na documentação :ref:`setuptools`, mas note que " +"alguns conteúdos de aviso podem estar desatualizados. No caso de conflitos, " +"dê preferência ao conselho do Guia de Usuário para Empacotamento de Python." #: ../source/guides/distributing-packages-using-setuptools.rst:25 msgid "Requirements for packaging and distributing" -msgstr "" +msgstr "Requisitos para empacotamento e distribuição" #: ../source/guides/distributing-packages-using-setuptools.rst:26 msgid "" "First, make sure you have already fulfilled the :ref:`requirements for " "installing packages `." msgstr "" +"Primeiro, certifique-se de que você já cumpriu os :ref:`requisitos para " +"instalação de pacotes `." #: ../source/guides/distributing-packages-using-setuptools.rst:29 msgid "Install \"twine\" [1]_:" -msgstr "" +msgstr "Instale \"twine\" [1]_:" #: ../source/guides/distributing-packages-using-setuptools.rst:43 msgid "" @@ -2068,14 +2407,17 @@ msgid "" "Package>` to :term:`PyPI ` (see :ref:`below " "`)." msgstr "" +"Você precisará disso para enviar as :term:`distribuições `do seu projeto para o :term:`PyPI ` (" +"veja :ref:`abaixo `)." #: ../source/guides/distributing-packages-using-setuptools.rst:49 msgid "Configuring your project" -msgstr "" +msgstr "Configurando seu projeto" #: ../source/guides/distributing-packages-using-setuptools.rst:53 msgid "Initial files" -msgstr "" +msgstr "Arquivos iniciais" #: ../source/guides/distributing-packages-using-setuptools.rst:58 msgid "" @@ -2084,10 +2426,14 @@ msgid "" "pypa/sampleproject/blob/master/setup.py>`_ in the `PyPA sample project " "`_." msgstr "" +"O arquivo mais importante é :file:`setup.py` que existe na raiz do diretório " +"do seu projeto. Para obter um exemplo, consulte o `setup.py `_ no `projeto de exemplo PyPA " +"`_." #: ../source/guides/distributing-packages-using-setuptools.rst:63 msgid ":file:`setup.py` serves two primary functions:" -msgstr "" +msgstr ":file:`setup.py` tem duas funções principais:" #: ../source/guides/distributing-packages-using-setuptools.rst:65 msgid "" @@ -2097,6 +2443,11 @@ msgid "" "of your project are defined. The most relevant arguments are explained in :" "ref:`the section below `." msgstr "" +"É o arquivo onde vários aspectos do seu projeto são configurados. A " +"principal característica do :file:`setup.py` é que ele contém uma função " +"global ``setup()``. Os argumentos nomeados para esta função são como os " +"detalhes específicos do seu projeto são definidos. Os argumentos mais " +"relevantes são explicados em :ref:`a seção abaixo de `." #: ../source/guides/distributing-packages-using-setuptools.rst:71 msgid "" @@ -2104,6 +2455,9 @@ msgid "" "packaging tasks. To get a listing of available commands, run ``python setup." "py --help-commands``." msgstr "" +"É a interface de linha de comando para executar vários comandos relacionados " +"a tarefas de empacotamento. Para obter uma lista dos comandos disponíveis, " +"execute ``python setup.py --help-commands``." #: ../source/guides/distributing-packages-using-setuptools.rst:79 msgid "" @@ -2112,10 +2466,14 @@ msgid "" "pypa/sampleproject/blob/master/setup.cfg>`_ in the `PyPA sample project " "`_." msgstr "" +":file:`setup.cfg` é um arquivo ini que contém opções padrão para os comandos " +":file:`setup.py`. Para obter um exemplo, consulte o `setup.cfg " +"`_ no `projeto " +"de exemplo PyPA `_." #: ../source/guides/distributing-packages-using-setuptools.rst:86 msgid "README.rst / README.md" -msgstr "" +msgstr "README.rst / README.md" #: ../source/guides/distributing-packages-using-setuptools.rst:88 msgid "" @@ -2126,6 +2484,12 @@ msgid "" "projects/markdown/>`_ are supported as well (look at ``setup()``'s :ref:" "`long_description_content_type ` argument)." msgstr "" +"Todos os projetos devem conter um arquivo leia-me que cubra o objetivo do " +"projeto. O formato mais comum é `reStructuredText `_ com uma extensão \"rst\", embora isso não seja " +"um requisito; múltiplas variantes do `Markdown `_ também são suportadas (veja o argumento :ref:`" +"long_description_content_type ` do ``setup()``)." #: ../source/guides/distributing-packages-using-setuptools.rst:95 msgid "" @@ -2133,6 +2497,9 @@ msgid "" "master/README.md>`_ from the `PyPA sample project `_." msgstr "" +"Para obter um exemplo, consulte o `README.md `_ do `projeto de exemplo PyPA " +"`_." #: ../source/guides/distributing-packages-using-setuptools.rst:99 msgid "" @@ -2144,10 +2511,18 @@ msgid "" "don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, " "include it to be explicit." msgstr "" +"Projetos usando :ref:`setuptools` 0.6.27+ têm arquivos leia-me padrão " +"(:file:`README.rst`, :file:`README.txt` ou :file:`README`) incluídos nas " +"distribuições de código-fonte por padrão. A biblioteca interna " +":ref:`distutils` adota este comportamento a partir do Python 3.7. " +"Adicionalmente, :ref:`setuptools` 36.4.0+ incluirá um :file:`README.md` se " +"encontrado. Se você estiver usando setuptools, você não precisa listar seu " +"arquivo leia-me em :file:`MANIFEST.in`. Caso contrário, inclua para ser " +"explícito." #: ../source/guides/distributing-packages-using-setuptools.rst:108 msgid "MANIFEST.in" -msgstr "" +msgstr "MANIFEST.in" #: ../source/guides/distributing-packages-using-setuptools.rst:110 msgid "" @@ -2156,6 +2531,11 @@ msgid "" "on writing a :file:`MANIFEST.in` file, including a list of what's included " "by default, see \":ref:`Using MANIFEST.in`\"." msgstr "" +"Um :file:`MANIFEST.in` é necessário quando você precisa empacotar arquivos " +"adicionais que não são incluídos automaticamente em uma distribuição de " +"código-fonte. Para obter detalhes sobre como escrever um arquivo " +":file:`MANIFEST.in`, incluindo uma lista do que é incluído por padrão, " +"consulte \":ref:`Usando MANIFEST.in `\"." #: ../source/guides/distributing-packages-using-setuptools.rst:115 msgid "" @@ -2163,15 +2543,18 @@ msgid "" "blob/master/MANIFEST.in>`_ from the `PyPA sample project `_." msgstr "" +"Para obter um exemplo, consulte o `MANIFEST.in `_ do `projeto de exemplo PyPA " +"`_." #: ../source/guides/distributing-packages-using-setuptools.rst:119 msgid "" ":file:`MANIFEST.in` does not affect binary distributions such as wheels." -msgstr "" +msgstr ":file:`MANIFEST.in` não afeta distribuições binárias como wheels." #: ../source/guides/distributing-packages-using-setuptools.rst:122 msgid "LICENSE.txt" -msgstr "" +msgstr "LICENSE.txt" #: ../source/guides/distributing-packages-using-setuptools.rst:124 msgid "" @@ -2182,6 +2565,12 @@ msgid "" "as `GitHub's Choose a License `_ or consult a " "lawyer." msgstr "" +"Cada pacote deve incluir um arquivo de licença detalhando os termos de " +"distribuição. Em muitas jurisdições, os pacotes sem uma licença explícita " +"não podem ser legalmente usados ou distribuídos por ninguém que não seja o " +"detentor dos direitos autorais. Se não tiver certeza de qual licença " +"escolher, você pode usar recursos como `Escolha uma licença do GitHub " +"`_ ou consultar um advogado." #: ../source/guides/distributing-packages-using-setuptools.rst:130 msgid "" @@ -2189,10 +2578,13 @@ msgid "" "blob/master/LICENSE.txt>`_ from the `PyPA sample project `_." msgstr "" +"Para obter um exemplo, consulte o `LICENSE.txt `_ do `projeto de exemplo PyPA " +"`_." #: ../source/guides/distributing-packages-using-setuptools.rst:135 msgid "" -msgstr "" +msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:137 msgid "" @@ -2200,6 +2592,9 @@ msgid "" "Python modules and packages under a single top-level package that has the " "same :ref:`name ` as your project, or something very close." msgstr "" +"Embora não seja obrigatório, a prática mais comum é incluir seus módulos e " +"pacotes Python em um único pacote de nível superior que tem o mesmo :ref:`" +"name ` do seu projeto, ou algo muito próximo." #: ../source/guides/distributing-packages-using-setuptools.rst:141 msgid "" @@ -2207,10 +2602,13 @@ msgid "" "master/src/sample>`_ package that's included in the `PyPA sample project " "`_." msgstr "" +"Para obter um exemplo, consulte o pacote de `exemplo `_ que está incluído no `projeto " +"de exemplo PyPA `_." #: ../source/guides/distributing-packages-using-setuptools.rst:149 msgid "setup() args" -msgstr "" +msgstr "Argumentos de setup()" #: ../source/guides/distributing-packages-using-setuptools.rst:151 msgid "" @@ -2218,6 +2616,9 @@ msgid "" "contains a global ``setup()`` function. The keyword arguments to this " "function are how specific details of your project are defined." msgstr "" +"Como mencionado acima, o principal recurso do :file:`setup.py` é que ele " +"contém uma função global ``setup()``. Os argumentos nomeados para esta " +"função são como os detalhes específicos do seu projeto são definidos." #: ../source/guides/distributing-packages-using-setuptools.rst:155 msgid "" @@ -2226,10 +2627,14 @@ msgid "" "master/setup.py>`_ contained in the `PyPA sample project `_." msgstr "" +"Os argumentos mais relevantes são explicados a seguir. A maioria dos " +"fragmentos fornecidos são retirados do `setup.py `_ contido no `projeto de exemplo PyPA " +"`_." #: ../source/guides/distributing-packages-using-setuptools.rst:164 msgid "name" -msgstr "" +msgstr "name" #: ../source/guides/distributing-packages-using-setuptools.rst:170 msgid "" @@ -2237,16 +2642,21 @@ msgid "" "term:`PyPI `. Per :pep:`508`, valid project " "names must:" msgstr "" +"Este é o nome do seu projeto, determinando como ele está listado no :term:`" +"PyPI `. Conforme :pep:`508`, nomes de projetos " +"válidos devem:" #: ../source/guides/distributing-packages-using-setuptools.rst:174 msgid "" "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), " "and/or periods (``.``), and" msgstr "" +"Consistir apenas em letras ASCII, dígitos, sublinhados (``_``), hífenes " +"(``-``) e/ou pontos (``.``) e" #: ../source/guides/distributing-packages-using-setuptools.rst:176 msgid "Start & end with an ASCII letter or digit." -msgstr "" +msgstr "Comecar e terminar com uma letra ou dígito ASCII." #: ../source/guides/distributing-packages-using-setuptools.rst:178 msgid "" @@ -2255,11 +2665,16 @@ msgid "" "register a project named ``cool-stuff``, users will be able to download it " "or declare a dependency on it using any of the following spellings::" msgstr "" +"A comparação de nomes de projetos não diferencia maiúsculas de minúsculas e " +"trata sequências arbitrariamente longas de sublinhados, hífenes e/ou pontos " +"como iguais. Por exemplo, se você registrar um projeto chamado ``cool-stuff``" +", os usuários poderão baixá-lo ou declarar uma dependência dele usando " +"qualquer uma das seguintes formas de escrever::" #: ../source/guides/distributing-packages-using-setuptools.rst:190 #: ../source/specifications/binary-distribution-format.rst:127 msgid "version" -msgstr "" +msgstr "version" #: ../source/guides/distributing-packages-using-setuptools.rst:196 msgid "" @@ -2267,18 +2682,26 @@ msgid "" "determine whether or not they have the latest version, and to indicate which " "specific versions they've tested their own software against." msgstr "" +"Esta é a versão atual do seu projeto, permitindo que seus usuários " +"determinem se têm ou não a versão mais recente e indiquem em quais versões " +"específicas eles testaram seu próprio software." #: ../source/guides/distributing-packages-using-setuptools.rst:200 msgid "" "Versions are displayed on :term:`PyPI ` for " "each release if you publish your project." msgstr "" +"As versões são exibidas em :term:`PyPI ` para " +"cada lançamento se você publicar seu projeto." #: ../source/guides/distributing-packages-using-setuptools.rst:203 msgid "" "See :ref:`Choosing a versioning scheme` for more information on ways to use " "versions to convey compatibility information to your users." msgstr "" +"Veja :ref:`Escolhendo um esquema de versionamento ` para mais informações sobre maneiras de usar versões para " +"transmitir informações de compatibilidade para seus usuários." #: ../source/guides/distributing-packages-using-setuptools.rst:206 msgid "" @@ -2287,10 +2710,15 @@ msgid "" "If you'd rather not duplicate the value, there are a few ways to manage " "this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." msgstr "" +"Se o código do projeto em si precisa de acesso em tempo de execução para a " +"versão, a maneira mais simples é manter a versão em :file:`setup.py` e seu " +"código. Se você preferir não duplicar o valor, existem algumas maneiras de " +"gerenciar isso. Consulte a seção de tópicos avançados \":ref:`Fonte única da " +"versão `\"." #: ../source/guides/distributing-packages-using-setuptools.rst:214 msgid "description" -msgstr "" +msgstr "description" #: ../source/guides/distributing-packages-using-setuptools.rst:222 msgid "Give a short and long description for your project." @@ -2327,23 +2755,23 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:245 msgid "url" -msgstr "" +msgstr "url" #: ../source/guides/distributing-packages-using-setuptools.rst:252 msgid "Give a homepage URL for your project." -msgstr "" +msgstr "Fornece o URL da página inicial do seu projeto." #: ../source/guides/distributing-packages-using-setuptools.rst:256 msgid "author" -msgstr "" +msgstr "author" #: ../source/guides/distributing-packages-using-setuptools.rst:263 msgid "Provide details about the author." -msgstr "" +msgstr "Fornece detalhes sobre o autor." #: ../source/guides/distributing-packages-using-setuptools.rst:267 msgid "license" -msgstr "" +msgstr "license" #: ../source/guides/distributing-packages-using-setuptools.rst:273 msgid "" @@ -2353,6 +2781,11 @@ msgid "" "indication can and should be via the ``classifiers`` argument. Classifiers " "exist for all major open-source licenses." msgstr "" +"O argumento ``license`` não precisa indicar a licença sob a qual seu pacote " +"está sendo lançado, embora você possa opcionalmente fazer isso se desejar. " +"Se você estiver usando uma licença padrão bem conhecida, sua indicação " +"principal pode e deve ser por meio do argumento ``classifiers``. Existem " +"classificadores para todas as principais licenças de código aberto." #: ../source/guides/distributing-packages-using-setuptools.rst:279 msgid "" @@ -2362,16 +2795,23 @@ msgid "" "confusion and because some organizations avoid software whose license is " "unapproved." msgstr "" +"O argumento \"license\" é mais comumente usado para indicar diferenças de " +"licenças conhecidas ou para incluir sua própria licença exclusiva. Como " +"regra geral, é uma boa ideia usar uma licença padrão bem conhecida, tanto " +"para evitar confusão quanto porque algumas organizações evitam software cuja " +"licença não é aprovada." #: ../source/guides/distributing-packages-using-setuptools.rst:287 msgid "classifiers" -msgstr "" +msgstr "classifiers" #: ../source/guides/distributing-packages-using-setuptools.rst:316 msgid "" "Provide a list of classifiers that categorize your project. For a full " "listing, see https://pypi.org/classifiers/." msgstr "" +"Fornece uma lista de classificadores que categorizam seu projeto. Para obter " +"uma lista completa, consulte https://pypi.org/classifiers/." #: ../source/guides/distributing-packages-using-setuptools.rst:319 msgid "" @@ -2381,18 +2821,23 @@ msgid "" "restrict what Python versions a project can be installed on, use the :ref:" "`python_requires` argument." msgstr "" +"Embora a lista de classificadores seja frequentemente usada para declarar " +"quais versões do Python um projeto suporta, essas informações são usadas " +"apenas para pesquisar e navegar por projetos no PyPI, não para instalar " +"projetos. Para realmente restringir em quais versões do Python um projeto " +"pode ser instalado, use o argumento :ref:`python_requires`." #: ../source/guides/distributing-packages-using-setuptools.rst:327 msgid "keywords" -msgstr "" +msgstr "keywords" #: ../source/guides/distributing-packages-using-setuptools.rst:333 msgid "List keywords that describe your project." -msgstr "" +msgstr "Lista as palavras-chave que descrevem seu projeto." #: ../source/guides/distributing-packages-using-setuptools.rst:337 msgid "project_urls" -msgstr "" +msgstr "project_urls" #: ../source/guides/distributing-packages-using-setuptools.rst:349 msgid "" @@ -2401,10 +2846,14 @@ msgid "" "development. The string of the key is the exact text that will be displayed " "on PyPI." msgstr "" +"Lista URLs relevantes adicionais sobre seu projeto. Este é o lugar para se " +"conectar a rastreadores de bugs, repositórios fontes ou onde oferecer " +"suporte ao desenvolvimento de pacotes. A string da chave é o texto exato que " +"será exibido no PyPI." #: ../source/guides/distributing-packages-using-setuptools.rst:355 msgid "packages" -msgstr "" +msgstr "packages" #: ../source/guides/distributing-packages-using-setuptools.rst:361 msgid "" @@ -2415,10 +2864,16 @@ msgid "" "packages. Use the ``exclude`` keyword argument to omit packages that are " "not intended to be released and installed." msgstr "" +"Defina ``packages`` para uma lista de todos :term:`pacotes ` " +"em seu projeto, incluindo seus subpacotes, sub-subpacotes, etc. Embora os " +"pacotes possam ser listados manualmente, ``setuptools.find_packages()`` " +"encontra-os automaticamente. Use o argumento nomeado ``include`` para " +"encontrar apenas os pacotes fornecidos. Use o argumento nomeado ``exclude`` " +"para omitir pacotes que não devem ser lançados e instalados." #: ../source/guides/distributing-packages-using-setuptools.rst:370 msgid "py_modules" -msgstr "" +msgstr "py_modules" #: ../source/guides/distributing-packages-using-setuptools.rst:376 msgid "" @@ -2426,6 +2881,10 @@ msgid "" "a package, set ``py_modules`` to a list of the names of the modules (minus " "the ``.py`` extension) in order to make :ref:`setuptools` aware of them." msgstr "" +"Se o seu projeto contém qualquer módulo Python de arquivo único que não faz " +"parte de um pacote, defina ``py_modules`` para uma lista dos nomes dos " +"módulos (menos a extensão ``.py``) para fazer o :ref:`setuptools` ficar " +"ciente deles." #: ../source/guides/distributing-packages-using-setuptools.rst:388 msgid "" @@ -4678,6 +5137,8 @@ msgid "" "Refer to the `pkg_resources documentation `__ for more details." msgstr "" +"Confira a `documentação de pkg_resources `__ para mais detalhes." #: ../source/guides/packaging-binary-extensions.rst:5 msgid "Packaging binary extensions" From 62ed26595b44109e77874f2c0a247947b7c0e30d Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Sun, 29 Aug 2021 18:15:37 +0200 Subject: [PATCH 0089/1072] Translated using Weblate (Ukrainian) Currently translated at 14.2% (323 of 2271 strings) Co-authored-by: Sviatoslav Sydorenko Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/uk/ Translation: pypa/packaging.python.org --- locales/uk/LC_MESSAGES/messages.mo | Bin 25026 -> 25766 bytes locales/uk/LC_MESSAGES/messages.po | 56 +++++++++++++---------------- 2 files changed, 25 insertions(+), 31 deletions(-) diff --git a/locales/uk/LC_MESSAGES/messages.mo b/locales/uk/LC_MESSAGES/messages.mo index b7a278f7f7a625897c6e2ccfa2a00b711d1eb2dc..4cd8e4935a6f423f236d38e6779ccf82930cb1d1 100644 GIT binary patch delta 7926 zcmb8zdwf*ooyYMrJ3HNZzkU$6|gnQ&p0ttc;BtU?ci$pR?5CSGa!KwoW0lO5? zfuJnbO0i}^#)>w<$e!g>lyq4YVKl{A=<^4R*Ip?{b zli=|ao?pG?@n2{bz0o1%c^s!b4r%B(yU5RIp<2iBwsV|G*a z#8asIKE&4e4@|(;+*BXa&0em4X8;-cbaKqG<`lEooR4bYL2Q72b2Ua$eiEDGM&v)| zC4Qvgo0yH)uo-sl;5be2Hq3DRjx&l(A{FJR8&;qOv(wd7&*ym%jwLbi*-hgC}t|euV0H1k+UgSWLnajKfD!E4Lb3 z;bzoCc41>YWS%mAkD9ovyOHq5h!VH*OQP1y6@w*)yr9us#M0NNMs-gF+{0G#4F5@)(0-1y}I@PV8hnheo zs>9W&t=MF4Lp{ICtTo^8TjsQR&ioi}@W3_H3SH^!&gg5@k~>}8Eo+9l-WE0EG}K}1 zZRHVWfjJE|!8xXXzGW6;WKU5uUyaeY&fI|N;2Erk+fYmRqPZ6};}d2G)zNw6;5(n7 z+Kowb2OjV0cUq9qgYE4?H&nyDQA;`;nY1$rSqx{1xy3w&di^e;w#4b`mQzq$F${G$ z3s4g*L46O(@BzL5FOXqyPWyD;bsT~9@iMC6Yp7En*UkMtq@wDxF$O1M1DuBHu-IH= z`cV^FYvnDdEqfUw@Be->>hL(~19S@Yx}CRj9cs_xx;su&Y=@db1{UJo*dOG! zb>B{m!go+##1Lw08fLjGm5I8)e-`UMip*##w72V!kCzif-Z1C4cpKK?aLnrIHdKba zDX&L8e;f-it{2}9oQk=)1UVMYLF|hkq0UlE9%k2_LA}|3R>!%U3N78wupvHUZnOGV ztz2v6H!*?x&RF?l)Nj8ptQ^zFU8zLW3MZj{7o?)j$^cYpF9XUtzhMk9X&^vX3P&om0`rD$~Nk+Y6sgBsLG522RuUAul3b^kf5zl4n`e}5NTcSXkyc0a+@r~$o# zIe2I=>)(US_f$;643u0T8=O?32WV7L}<4^-xiQRAq@@6@|Lk*x|jyvEavxk|B8bA>q!P%(2PR@1j&opz) z$*42qpG!tJF0_h=QSWsXs=;-56*nVaPiN%_cWd^e26Pg8;`{h0)*tCUw-PzG&Xbsl zZ=qJI4zsXDUgT5kcSe$FO~qW)AzFsolC|bm)FIu6Iul2+6^5`Aeu{c7F5kW0+Du1n z-9Xgy<4|uwk?D)*=U+5rv=on{X1oTqx0}qD%v#j@`=6+pU&JW<64lYysDU*Y<#w2i z$&}M^J&s1sxpNNNV9VRtV)}Qo$h604sE!w#tITK2m(9bd6*_HxY<`31JZ#@+cMC7` zHPZmTL=8Og4)<+HLv3*u`ZeQ0WVE#T*b=9h^UcRl9X@UDFpr@=Bxg})=mJLLRV!ad zo%-*sK54Amen+$4Sl)j%dt&nHepHS{8?;aY5qXOPu(uHixK&&_P3a~+$r z zVgg=64e$rl{Yewu4*Fms<$TnspNi#pFFt`EAYEBsk6;-HHz7F+TZ9;9y^BDO8q8dJm9q?^zhgVR095c%uSW8qn2X+4hjK>*P zE=6tGV)W~ftRN$+&F!cT526m+3DjP{i*4{C>d@XmJ(qZw+hD5M2X%igY9K|Z_I#)T zmD%-&?qdD>QL&Z^z3(S*EPjg`asF&~025K=nHYof%tfe%A3%MI{iyq@Q1`7jt5GYv z1+}uR z#@1#wYVV6sD|!!V;P?Bi8>+MgMnJ5mn-jEFN_@TBABjLoI1Gs-cmn1`1F!nS#++j8S+G zYM}E_EBG)*<724%S6Tg2*jVrX(_}nc=td|#?&9R*+r%@(2yV!;dTql`h=&Qr9!Xuf z{v5e(*b$QmZHJfg=cpCzO#V756%+j_pQZmu;#=a}OMFG>pUSO?KSr*&U&FzaZ%sof zth0(*Tx5A|!F|MhVm2|0V1AK5aC|tDP}0_9(PnQyKlEMhhg!Z*h)IMJueI|#;tS#s z@e~mtHW2%XCkdtQJUg7wwkh=>&&Skhfqk(bp||UMVg)gtP&z~SzvM>)Zfr;_C!dD9 zPe$`$P`Wh3j`oLWl5mLh0wks7Q{3h&sSZ=^py;?dF}|n_@Ci zMDWWj^4kg`X(c~b5kqVs8Tbn2M~DZBKNI@UBoIpP5?3NQe!-#sFMA)%#$Vx!^zUpZ zl-3eM2)$;TiT@%t5zC0F#6;p%;sK%_4cw0(5jRtN>TV`J6OrGROK>Ui5D_N+Lfo3v zf8_m?|4w*`PJ~h~VhnKy@k^pDp)`_?I$39bqTI*w^~nD~BwKk4`F|stS(&W!tbSOU zp!Z*Co>k~iDW#W)4&+BfN_=|BA0U5;*k*PAVbo1$zh!`t>i@5|}vdAADs!k@(D?_?WBy#_! zxRq$4XNe2sza}E{e**^-or%N5|4v=4VlI|ieg~c-{$}M{X-?rAq9+|aZx`0%XGA07 zE#hZHG}ryT_%W738$69lg~Tt2AaR7KByzc~bew2J{uH*gI@K$kAU-4pP=6I$;&&K_ zo?Gty19c|}l0Wi?gmN>8cHGp;ZtQE`puUcXC3IT$5W9&%T>mNFPACl`hT1a&&0kZO zu8X8ciGM_L?r&CQ6Fign_Z*pxc3}aQ5etcTh?j|rgwi;d$iE9dCLeF*Z1V+tlNcU| zX?v;p)bi3wpSNqFmsbiPsxr;03E-ZIk zdiWL;m(CB?cAVvDUG{*ltg>`rS%tT_ti-#(H)n2fS?QdLU@Py&sGj3W=lIGhd`>~` z_%WmMCr!>OEprNrOUo(=U->Orx5dD|)H~}HF9_D_{907>oP~>gf!DegHLP4Z-{-w| zacPM!*djgO(|GdY%7x{n#q%qiq6%MNR$)?baks{v`cr)66^tXeyn8oK+qu4SX2p~u z&v{ELyd}Ox^A|4ll?1nE#5L^@dM;EGULCFuKNeo&4X>i`SZF8i4ebtB2X_ow9vvTg z@n&tfI*>Vh=)YQmz}(@3Q^Qr>&;f6_Ds(tp9Xc4=8LADhAy4gL3j1lXD)`3mFFoBh zgpPy`5xYaRbaXg$B)pvdtMxSXd&7@&d!&uv?%a9x0_{g74cO1+@bb{n@G`FL4(;Rm z8d?a3j(8_5oiN5r^E(;>kSs>{mBzO*;i2+96M@_=l{JC7jLhQ9$&n` z7kqGZR7}hsrnD~blY;K)%y19mJi^a)k+oCbUd=@FVTAh05CRtp&L{pna_3Q-?O~cY zFn&c^Xfsn?Mnk%}CcKiB->o*708^z@LvL$?L+-3!uk+S$6%|J!x3jLH8YlD=*AJ?S zXLa|^z_h~TSXO6Os3!18VOy51P2iQnxDu>6zycpCqY+XLQFNlik(U_KinTe&P;75L-i14BcbISqS4HQw;b c&|WY7{_6>IlMRe%ZqRbl%DUjDqKx=|0)7Utk^lez delta 7203 zcmZwM34D!L8prW-vmio3gs2FYh6rM5%2chfl_;@!{SZY7Lwlh6&gR$6^gE#zb6%y6=9hi>0XR_F*kNj#cqj z)1`a)YFOR5fUD&tT)NrZY;Sf!Rd5+r!vb?8#*&|aYU@N)LuO)gT!9_298>T|Ov0*M z)C%iiZJzIXlF$W(NQ>Nc*aVBP1ui$skviNLc0MM<%V%OI%6pi%VJi78s1ewYP4OdC z2hO6NQ-xuw&huSuC9t8Hg%inNgc{-p%ty^lScUSPmfwpSp||kw_&(A`SJ2qIZW8MJ zEm$9K$MLuv18UJvcH$f|{VvU~pT$zbZaJf#&j4)B}!~-`KSks#ONBa{6the zlPy2JNx*B-YzjtlVj=S9j_{$D#xim0K~2;Ho1j*IJF_e5x_qcmr4zRlcYzKQDD2j&s;B&s2&Q9V41aTu5B)t`VdI-)cbr8Z^gRJog?W=@DVIUHE?*A_gap{3&_tzz1~49 z-+=1i9!%2v|9UjR`)PiO>dCK`uhPOB!n#Q+ORF<4jb87vT`x zjU6y0+neHk7{~KnA&Coo&W%F#{FatpkLRHpQi2-lRX7$O$MqQB%4^UQ=4RB;Z$~xo zP1J^U7-R7d)JEl6dn0}+M&JK2By__>?29u{bG8fF65LT_!MfNS=l+7tu{(}KP2C!7 zkGoO#|9}IrQyWGL@4`IXh|H2ZiMd$2E#t36(x6}}JiCB)+aliSFl^?SF zDa-$i+G=CkdH2;peHk^jdY9g{E%Yhy>VpE(-!yh*5zO%IUJoXtTkrsb%XKZCV#FRH?K&10zR zPoo-E^&+prG*kopsPnDyV(fvcZ#wqEC8!3!g=#?H6Dv55@f7@MobeG|A2qbiQA69t@|Re?2gXsJkE*8tb^kDALkhT2B)U;B27BXbR7($If6SyCnv%(= zIV(YJOzX_uSd082RFA$xHT-u}gW`DS^xz~j1+_TqVXEH$Ye>|lU?yrvmtYrMjauCw zU@JUhHs__TLw+dg0oS5>I0g0K=~xA4TmDW|!X2x~)?oUQ_FwOLLX8hH&Yzj1_IoJ&I zP#eW{NF8n|rr>^5gFit{$tl!`q%mJwBiX11U51*vq1XbanGaz)`B&`xXI&V76~uM* zwno1>8r6{Hn2kG-_2`bF8c?4Vs|IJ8oy`JN1FpsjoNVPe-M#Dc%;BgtazlWG-rFgt z8;kKI-i7QjuBeAM1?y1{-hyp$FV4o(sQZfYysdc_W{}^CZSZZ(#F(Cp5@w;+Mt4*P z0s}2E0i&xIHRrQYi{u_`f*Vjb?z8jnna5F6^DFB9MBZJk?o>0=ycpHv-lzr-K&CF> zMtBK#y?Gm^azP2I$LlZ_H=!Q11=X-uQ4c(bjqx~6!>Vi|EDKkR+EL3;Qy9U9_&aLN z)bAq$?Ca44@4Pw49FH2JB6ESc3Xl8vfr6U46_0Q&dG$7v zJl}P)f`O=gU;=8Zy~&(`TBLVk9IiuEyusXwYUly;3)B#wLG~;c&r7eN?~GNkC#wE@ z3|v6s3KAO9si=w;q88DEs71H~wdhWn>G@uM0O~co9WTMhaS$Fx)zfx>S8p$DKz=kb z2yQy=!14i%e_s+aF6WzzA>D;)+2MiS>irt|9&!z-H5Uu8BhJSp+<_X2{pKO_C)C_0 z7I?^#*IS`wYzZq5Uz1STC`$(w8)kb>1;aZ|97=w(y zTaSMH9`i6|l(#h(VlMgHQ4M(xv+x~kiGQFPmNnWN`dqUcs=U9K54ho0Fdj8GlPo_A z>ylq&`G--f_bE)k5bAX+$7*;0Rq@BD#d{p}*2G`wO=S~Q!`fSZ3?}ORpF~27Zbr0# z*9T2zOy4xYsNcn;O@v@zcOIjH)&n}bl-kHuuY|5Hh*!nvp( zEVc_);Kk&h#141}2VmW?UV|r~8Zg=NGclh00<#2F?=pZ0DcGfNm%yp`k59 z4ef5rzh?OZsEy|nR7FQn_kE5mdUp!>qI2J1Z_F9z{e&w*whZ??W}v&uo3cjOh-~gv zjK2~?DbU}@23;7(>;=U1EVToCW z>Ew@%4|or76TBW)M?E+hwPn_~d}CC@TA=1K7qvh1L=EXsR70;q-G2k>`XbcG%|dlx z9;%@WP$T$2z%E#Wx?#PYcou7t--15W@e)z1GDBML@ibyOae&a;(J_Ny4Z5~m`v__Z zULzWi*Y>N$*~sb%tRgdum`&)=I?xWsMixEPh?-pdFH}$Njh1=~F_rT1me+7TXX)$l z211MW6)W3|b-4Z+%OA!i`u?vxej-tY3l?ApY(q38-Gb1Lm_xK7HWKrQF!2ZR9ibzI z>)Feq>*?oc3EyydHBpPutJ$4cNN8%u5$$|D|5Xwdgy!cO;toQ`ZywQ4eK(X7D~PRx z<}i)8ji}3m&p%4ZoFv{pukaH~@5ZMHElwTxYpAXwVyR>zUQ1j@d`v7Sbae7?E$u06>>aHoFy`el|(bn{r6FyvON^eC*C3MCbkgKu55>k?51v{=MXvM zGlNA&aWd^RDzu(G@G3^7dO|GpKz zYl{1bEFzi8^nW3eRLIfP!}Y_Z#6FdAz8>+YovUODiK#>paiX#iTX607c$6rp+-$~> zX~>DnqaKMTiP~271nF#|jJSlTJiZ|jB%USGxb`MH5l4C^=~T-v#@8*KfIkp1M26;H z$IBkkudoYAS0f%K{y}_3+(MjxoVH9derf4T@hxH`kwpXg;?0DPH;4y_7YQHdbZjQN zzQ;!<1#2-vR35`gj39Pc!B{ibZjQm{gBj_^g6q3vg?cnx92c1rd1OU+M|e~Cg-A)bT;(gmJF_D9gg(ss-WU3%*R?VA z!=>R(k%j*7F0R_4JHi#=9scmP;Jtk_LeKU+;Y*>et&zEWR&Z@aI25i3t?F0e`%?qw z=GP70m_Il4U4BfwZ(Hz}f|i}a6_JJEvdEmsQvRD4DWQscsMk;V+~`wE`78_X^po8h znM2+BtO)N6_8L=x3oFot^XN4niiSwA3Sq#|2Cl$ mh3$MH|A_X!rsrQ#7T*3p16k@1p1wRY_|O&WLd7Fn*7!Gp@VEB> diff --git a/locales/uk/LC_MESSAGES/messages.po b/locales/uk/LC_MESSAGES/messages.po index dbb3dd5b8..5d698f156 100644 --- a/locales/uk/LC_MESSAGES/messages.po +++ b/locales/uk/LC_MESSAGES/messages.po @@ -8,8 +8,8 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-07-16 11:37+0000\n" -"Last-Translator: Alex Solonenko \n" +"PO-Revision-Date: 2021-07-17 10:09+0000\n" +"Last-Translator: Sviatoslav Sydorenko \n" "Language-Team: Ukrainian \n" "Language: uk\n" @@ -74,7 +74,6 @@ msgid "" msgstr "" #: ../source/contribute.rst:38 ../source/tutorials/index.rst:2 -#, fuzzy msgid "Tutorials" msgstr "Туторіали" @@ -170,7 +169,6 @@ msgid "The guide will be browsable via http://localhost:8000." msgstr "" #: ../source/contribute.rst:109 -#, fuzzy msgid "Where the guide is deployed" msgstr "Куди це керівництво публікується" @@ -182,7 +180,6 @@ msgid "" msgstr "" #: ../source/contribute.rst:117 -#, fuzzy msgid "Style guide" msgstr "Керівництво по стилю" @@ -206,7 +203,7 @@ msgstr "" #: ../source/contribute.rst:133 msgid "Scope" -msgstr "" +msgstr "Охоплення" #: ../source/contribute.rst:135 msgid "" @@ -224,7 +221,6 @@ msgid "" msgstr "" #: ../source/contribute.rst:146 -#, fuzzy msgid "Audience" msgstr "Читачі" @@ -284,12 +280,10 @@ msgid "" msgstr "" #: ../source/contribute.rst:184 -#, fuzzy msgid "Conventions and mechanics" -msgstr "Домовленості й мехініки" +msgstr "Домовленості й механіка" #: ../source/contribute.rst:192 -#, fuzzy msgid "**Write to the reader**" msgstr "**Пишіть читачеві**" @@ -9726,7 +9720,7 @@ msgstr "Приклад::" #: ../source/specifications/core-metadata.rst:66 msgid "Name" -msgstr "" +msgstr "Name" #: ../source/specifications/core-metadata.rst:69 msgid "Added additional restrictions on format from :pep:`508`" @@ -9743,7 +9737,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:88 msgid "Version" -msgstr "" +msgstr "Version" #: ../source/specifications/core-metadata.rst:92 msgid "" @@ -10023,7 +10017,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:366 msgid "Author" -msgstr "" +msgstr "Author" #: ../source/specifications/core-metadata.rst:370 msgid "" @@ -10033,7 +10027,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:383 msgid "Author-email" -msgstr "" +msgstr "Author-email" #: ../source/specifications/core-metadata.rst:387 msgid "" @@ -10050,7 +10044,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:405 msgid "Maintainer" -msgstr "" +msgstr "Maintainer" #: ../source/specifications/core-metadata.rst:409 msgid "" @@ -10067,7 +10061,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:426 msgid "Maintainer-email" -msgstr "" +msgstr "Maintainer-email" #: ../source/specifications/core-metadata.rst:430 msgid "" @@ -10084,7 +10078,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:452 msgid "License" -msgstr "" +msgstr "License" #: ../source/specifications/core-metadata.rst:456 msgid "" @@ -13497,7 +13491,7 @@ msgid "" "experiments like this tutorial." msgstr "" "Майте на увазі, що цей туторіал показав вам, як опублікувати свій пакунок до " -"тестового PyPI, який не є постійним сховищем. Тестова система час від часу " +"Test PyPI, який не є постійним сховищем. Тестова система час від часу " "видаляє пакунки та облікові записи. Краще використовувати TestPyPI для " "тестування та експериментів, як у цьому туторіалі." @@ -13507,16 +13501,16 @@ msgid "" "can do much the same as you did in this tutorial, but with these important " "differences:" msgstr "" -"Коли ви будете готові завантажити реальний пакунок в Реєстр Python-пакунків, " -"ви можете зробити те ж саме, що і в цьому туторіалі, але з цими важливими " -"відмінностями:" +"Коли ви будете готові завантажити справжній пакунок до Реєстру Python-" +"пакунків, ви можете зробити те ж саме, що і в цьому туторіалі, але з цими " +"важливими відмінностями:" #: ../source/tutorials/packaging-projects.rst:608 msgid "" "Choose a memorable and unique name for your package. You don't have to " "append your username as you did in the tutorial." msgstr "" -"Оберіть пам'ятне та унікальне ім'я для свого пакунку. Вам не потрібно " +"Оберіть пам'ятну й унікальну назву для свого пакунку. Вам не потрібно " "додавати своє ім'я користувача, як ви це робили в туторіалі." #: ../source/tutorials/packaging-projects.rst:610 @@ -13526,8 +13520,8 @@ msgid "" "main server." msgstr "" "Зареєструйте обліковий запис на https://pypi.org - зверніть увагу, що це два " -"окремих сервери, а дані для входу з тестового сервера не поширюються з " -"основним сервером." +"окремих сервери, а дані для входу для тестового сервера не підходять до " +"основного." #: ../source/tutorials/packaging-projects.rst:613 msgid "" @@ -13536,19 +13530,19 @@ msgid "" "you're uploading the package in production, you don't need to specify ``--" "repository``; the package will upload to https://pypi.org/ by default." msgstr "" -"Використовуйте ``twine upload dist/*`` щоб опублікувати ваш пакунок і ввести " -"ваші облікові дані для облікового запису, який ви зареєстрували на реальному " -"PyPI. Тепер, коли ви публікуєте пакунок як продакшн-версію, вам не потрібно " -"вказувати ``--repository``; пакунок буде опубліковано на https://pypi.org/ " -"за замовчуванням." +"Використайте ``twine upload dist/*`` аби опублікувати свій пакунок і введіть " +"облікові дані запису, який ви зареєстрували на справжньому PyPI. Тепер, " +"коли ви публікуєте пакунок як продакшн-версію, вам не потрібно вказувати " +"``--repository``; пакунок буде опубліковано на https://pypi.org/ за " +"замовчуванням." #: ../source/tutorials/packaging-projects.rst:617 msgid "" "Install your package from the real PyPI using ``python3 -m pip install [your-" "package]``." msgstr "" -"Встановіть ваш пакунок з PyPI за допомогою``python3 -m pip install [your-" -"package]``." +"Встановіть свій пакунок зі справжнього PyPI за допомогою ``python3 -m pip " +"install [your-package]``." #: ../source/tutorials/packaging-projects.rst:619 msgid "" From 313dddb01c1c85769068da9a5fdf1250b6865d9a Mon Sep 17 00:00:00 2001 From: phlostically Date: Sun, 29 Aug 2021 18:15:38 +0200 Subject: [PATCH 0090/1072] Translated using Weblate (Esperanto) Currently translated at 9.3% (212 of 2271 strings) Co-authored-by: phlostically Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/eo/ Translation: pypa/packaging.python.org --- locales/eo/LC_MESSAGES/messages.mo | Bin 0 -> 18024 bytes locales/eo/LC_MESSAGES/messages.po | 127 +++++++++++++++-------------- 2 files changed, 67 insertions(+), 60 deletions(-) create mode 100644 locales/eo/LC_MESSAGES/messages.mo diff --git a/locales/eo/LC_MESSAGES/messages.mo b/locales/eo/LC_MESSAGES/messages.mo new file mode 100644 index 0000000000000000000000000000000000000000..bcc13fa9890f0d0244a853ce9e2191845afe716b GIT binary patch literal 18024 zcmeI23y>s7dFN9IB(Va7c!Mz1t^|ul+dZ#+wzQH)yR)ldU!$E_2_dBIn(msOny&6@ zRdvnmtYll*#vmhvk&SH-i%wYPcvu)=^VETiyfPg286Q3oK5-&+jtefh@Yxs>4kGNh zxZgi3tGjo0rCkw(BkZ7Kzxh>FJ}UFeFTc#nZ@>GJ=f2hoH)T8NM7o0hR9u@Rjg_mm2e8xE`Jhw>n-8RsLGI z2F^Mjc3gDKpvv6=&x7xBd>=fU`wu#P*zqG!^?el51oIHo`;SBZnaBB~^zTEuY<>il z@1NnT;EP^n4FAk}{^)&IKs}#?7s6Yh@^|3R!C!Xw_rq6n|3^^${tNgT_&q3y8 z3tS8Jo}=*j@NTGn{0^jP<`Yo;c*OBZsQmv7-v}?DGnc^4Q2n?G>OCRkpXs{$yWke? ze;cY@--OSF--gQn9rzshJt#eWAASO!jdG>WPeJwjtMCH&4XAuiK=u1aQ1$Ae?BQI; z3!v=rmGDLI5~%#+F8wN~cJFrghu}rr-wc(11?v6pf}7#J@D1==?)i_Q@}JLOa%tAX zAvghL_YqtV?}V!7A*lSv;q%~AQ2qKI)Hwe=+y?&8kk$D1E-r%k_C7T+96)D1En}$}hq1!aLzC{%wIw z4{`tHb;f)K#upp&CAbbF|10<;ybnHv5!?c=RhfwV}59P{UFM(?3 zMt6T0Y8+!IySWXj-|u(NKLXXxPeJMN^HBBwsZ0M3T*LkUhSJ9mq4J;ero7$@AXCU( z1Xb@ilzy*v_q(9RYX++RMR+b;ap`Y&yc=H0^Lyb=_ypVmUw^4FQ?LdP!3UxI=-G6V zuA7%Z+3n@<`EUwqJZ7NUdjnK|noxe=4tO4X2UL6RhUdUzQ1jsdC_R1`s=mL2%Ku}y z2A*|UuJ;!}rLTkcGM*ct?Dp#nlG^`cD7|dQ=%n{U@O&6Uwd*#hcD)y3%H{zm`+XFu zf8T-9)89J&2&(+QK(*t%a?Y1JzRvMdsB#;j+I@xNB$QtEJ05hr9;&{#LfKOQ)&JYv z{k!3dxW6B&-cLiNe*vn0Ux(_?Q!f2SkST5c1**NTMk%-$^9HE=S3~vlEsnQBrjYqH zsB)ixFM?l#((kvS`tcN$zP=CDkN*cZ!RN48Dc@G8a@Rm!ZLWiA?;S4vT~PJh1J#~; zq5Azf$kaDqh4M#FLG@>BG_Q9TRK3&i0(cl|JY%T-+zDR{?}tof^BL&D$D#876IA=o z8Oz`MVko^_2Dig4Q1+KW+2`%>h4AfA>(qN8reyAccfm*Cg>dh9KHqMEYF`toT}PqP ze-oxeGfW*4yrwmK>3B^a6LSm#Y6hM z3~Kx~!I#0S;l=Qf;|i2Mj=@Xd=i$rY|A4Q6KZJDAJbz2xuI*6cc^ImmWq2vP7w&_P zLH?PSZq4WG9!Qf+2-WWUp!D`JD0}`ARR5lUYRBI}*~59;^7p?AYJ7&F^tu^p9Ct%h zX0C_wqwj{Vgztk|r#=pSctIr}pIf2cvjWw>_dpN+E|i{+L)qm&Ld~03T%P;6*FcTO zEL8iK;7i~y!v6*Dfj69m9mua{!LKx;!3Fcrd;|hkl{4Hj40o`k&ht9kzYf89#OlyNQRKz{3@cK z-t$@HX5=8E-zCTj^002)?~9IKcl=NAAw>Ha%*p%#@_WeD$ZsH;&-zI({}E{;e}a4h z(eHP2nCs#DkPo^0n;d`N@hFt-eH{7E$R8q)A-{tB7vxSvwk^FZA~mG=&2zES-N?Q- zA|WDM(7byUvIY6C$Q*JzQv6EA1;h-^VPwcX`%}l?fj@_wjZ~2hNPz4^o{u~S89_E7 zpG3ZedxxND_ zBh!d}x8^XoJ@Y~27UV6+SCPL$ei8Wq@@eEYWbmhX{4w|7mtYG?kO|}l}xkc%7L%>(eaiUjy_cbz(32G=34clXyieiUv)E=4|!ybaNB82N9=m~IAt z>vu(dcfHr~YfZlqq~3DaUGOUNVH8xVL8DO$+w*bNYXx1u?sxsN85-IVw;PGy%_tYf z?R0~;5@+j|f})DL=eO%#JxsevIG1$;?!D=i?n2!5I!U}3)VgbjhP=P|(8s(V-1nYO z>q2!VahjHrU_MBKb}jH4K|4s|ER9x%hDg3P@ati_k=mR6S!*sx^6P^^+M!0T?YBth z1%9m?)`C27rt5bD&rj2=)v-;r#Sf)C(+lcBQfdcTH}NAc?XEqn7&&2ixM zM~cfacexeX%khmHH*XtbUpGF!acp#x8QVO%ZDeHYCNo~%jBG)+nr)lMH;ruGGBz@9 zDxIKHscszKTJ>hKPA5*fX2MIuRwrTva{Zc#PA3X$c6hwGtX+?S)Lg>=H&AK2Zg#{` z)@p-R$4|nPfuXx)2AfCi`LK~Ox{R#X^4pk1D`eb22JHA?ae1~%MMi34U)E$ z5~}uI`U%akncW15nBCJ;UY6=5)oRC1^>MG%l2)k1&KU0|l`lEf-(0Phi;8oN&c{j1 z?-tL3q_|R@(_trQFAYAiuh&~odYE_8>cw{6zFd{qB6(^`OK=f`WnH^YcxF4?4wj=8 zHzIg4m#-+A=G9ivSgTUKLF1izS6E(IHG6$*^I)(P2Fnc0-oQ_oQgITPz4%7Y>77d5 zXr^YLA7Wu4o{!6B;91jR;(8VZWymkFeKzJqc2*vFHBW{6Y_QZ5To^LmNCH8M20M zFVms2cR(h#9Hzkr%)vVGK_APEY~uq`Z-{Iwsse@y7n&{kO*-VoiRUlHA<8cDGw+z; z(Ms7IXwwQhj(?D+kXam93KFTWiM};TEg0scy?wMX+>)f z;wR`E8S37yFo^1@ImqJU`EzmB^(ytaR;dnKrDo)o||Cr(6H0G&{kABXmr8l+M7I zgJEN#Tk&QWc$msWy>ubYqPo{?$IGtyxgL61g6-v%-DJA7Ty!@QZu6+hFcbA z5A54}*wZRfVSPya6)&D=rY3aJJVRP~LgFd%=Z`dly8ay2JXn`|f>F%*Db}2&ngy)X zQ7BgvSIlhBV3tE1!5lf0csW%~OgP_L=yp4m;o&H*`H>V|**Y>ZQntmK!OC)+)bWRU zH}x=gwbRQ}t-GR!Cnc~kYhk}03ste|N)spLbCYCM8aq2&q}>8B=2(f_8f_e57N|3~ zGb<16zTI06B9=S$wmqAUlXNX6%VyKA&r#e>Rr#{Ng5!(5g&^v9%sUq5V)?Y{aoM}e z><+aBP?=&kRM8U5-ZQtD75W_3Xhz@Gedou?;`&3K{bY5T9kuo|1KnLWL&Ke4Sx5ei zZBFP%sX4@a$X8b9_jrWMW&I61)v7wtOSc}bVv{v%G(>Lkk-Z(V)4IaeyHf4D)vEH7 z>{XX=vem=It*aD$=T3-a^m^xS9X&S-Sj4W6*@|0zbmMklZdl+$BVSnR0oy#gnyl;K zO`~vb9rLK{t?Qry-Cad)R@3~irkFNcJZgK+k+I{8TX-*=vK*9b-Y#|Od6&hLMdjp$ z41=+&mvZAgtf8@U4z%Cp1Ev+n^>Y3e4IjOCySbE40ycG>AZE{$FIV|i0yC$yXP32n z&0`otwr%!HCP7U#zZ3Gw5FWMdq;_^yOe&+#485UnwQ{95u;4W++VAvSn|tKEtDNIZ z?p^oDyH41}!FksrYk%bBU1e5uHIWOo&eCN&!C5x==99C$k>NzVHx=8sViyjvvn?4G$?n{SvZTWmH@&dKDv$lRTmGP2BQNuXQ)ir5v(zFbicXwHd8+$qT8w+`HM*$H z?K66owR-rdj$%db)l=crxmWe=^bK}zI7!JUxMYp@C$(E!cvW*wXRx+R(c#myy_a`& z)B7LjtDBCs=Zp1#W%USam)(Wr+nP$nRL@{;=u1w`H`VG$d9=K_ zTHV01HCou4s~f z`=zCPm9@!P66IZUn@=8UwP$z431hw^&kvm{W^l-joor^%b(`XIsn{zfWi`6@IDe^e z3%b!@mEGq;e&bqT+*TkBqWO|t-s)xbW?1Xwa6R$oyQMJb&X*SHZfTKY%+hi&S3+~; zg)V1)KUwiKY%p`!lb&%Ui|lRFfkt$aaEX2Vvuem-9m`av&ai1?r(bLwdtK7*q3;r& zesT?-SKGc^Z2N_Y=HFVS$j{m}K7ouIr^AI=ob*8ZZJ>)x&yt#1uOxUAPZNdu;1WB?)G_NmkRS)Ms_5#YbZ^>r{#_QVb&N z>H|GL+2aGJ5tQ3Oci7}cPtW8M>8e$n-EQVrot6BN-RGNhB`tS+!XK@;&ScLI(2dT8 z*-ErJ#i3AXs$Oy*I~8w|!@0z7^VRVtZ9Ohsb1=}1DeX%eVZC%s)<{dUam8CReV~+| zp)j&LF^`IO^N{gZ2SXjq!1#*_sqPAcB6Lwomn`zQ8I zdRI*Do0!^r^~BDd2PbD{t|V)_k?|2v*c-ZDq^8W;!C+5S4au{F_$1cE{eP+s7{V^2_aQZ|!z(^zt=tDeYEB zDA&mid564>IPx)E?$R1FO%HuON}I9Q%s6Mw<5fXBUiA2ATpiC+7;CqUVa1$$E`=({ zQApEY>;P*EGfcP8Rr4rJc=|McH@Y5vx*U8@mbI2<3$@b z+8?(#R>`kz^s3p-Sm|2vV%w(giHONGI7Q1k@zLVpp`$zqnrS_Nq=I3VK`E{gLa z7-KW@Fgp$qyeMeM9Bo~L)6YI&w!we(nAJ=+$5|l}kmBG?;VUzvpcP}L8IO92T5%M` z9m;Ak5c7W8j2F$WxXq0me}az89vi!gp@LVj$2o$HTus#ZVAr{vU$^h^8+0&>4Ws_Xs z%3o}I`+|DNsGVG-2wvF&oG&Hu5~G;cnBo6VF0slP+JdeHya-)Nd4AJB{@GYjEDRq- zbpuvxJXM%BIlU!;3l5DI&1~4o?Xey=^H5e2+Yr`{An9Uo8$6Byt&8rjF1AMdjq1q- zrrz;mVakb%zi1|#M|l$_uJD1TO+d6z3MZyDPY5HQRSDBDMZ1q3!$IqVpBOMxlyG1k zHCn52)Hce@5<<~oc5HU%1F&eO+RZ3C%DFYUL+Q5Hc|se_JbvYqiij?2@y=casy%vCB|gn#h$-aEeonGmcvo#$e5|Xar_cG-o=GD-^f9Q}5~}+t$)4 zPoXN>sooCsLn-sJz2dpGX{oMw;I!F}Ik$59?H1Y{tZOhfbz*2r(e0)1Xvpyt!KtK; z6O2Nm*i_gE(VuM&Lz@p7CXG=YWqpu$F@r|K0HN)$$w=D~PW>qB%A>XAdQr8m`}P{U zC{;{Usugn@-&~@%9sjXobZ$SP6ik{qEMs zkWYxR0Y6CV8Q!6#Q1K>0AVjPldr((C@v4a^RH$mTb5)lWdy-G~hQi2}eeBpU7q&EK zb^N~u5AET)dpXNyKLJ~M+&@J%MCe%_!iJA8atEbSga%UmMCH!;$+`o#;1DX%Y%V7F z@nhu8tqJs_RC1Zppsld*p*B?2#5h^+?Q9}I<>$dF4H^bIUA!@W;q-)=cG0SRew!0E ze5!Qq*1khWHQcB_3B7z^2D*{wAyye_-9wM^3=A9|Xc3cQ5mT{e6T6~NsKIkixNWVV z9%Gv^Uovv6wo2R(5qay2PuQ52yGIB}FToir|_y2a?!`ZU>9#GVqJ4_n}`jj!*14DzMaACwVpcO3?i0!R-aZDX|lTR zFWQh-=y6zI(bBHzk$Uxv9g*8L3~Z=fqzf;T@0S%TY4ShA2ImG}Mf{fq=2zYWY8^~f zH=|(DPSIW#_43hA4#c}2eV9?v!X!Jx$rSSrKcvZg=xC^A+lISj;=N?+D+yTP)-}5Z z(s+h4*o2-U+LfpD!(G(wY8+ex*=iGKcRsM>LS2~J^_aEWfU$6xJt0vjc0{RlSC4+u z1-Tx5c-7n@h3^);?xPQ%81XuB3M%-uC-hrd>F|bB%X;Ug9eXLPVcyp_u60}Zq*Jbg zP5xH_3SJ5yeV81S(YnV-^a5aUyWD#VM$22IdAT_LpU|ScTFBQ#jXUFE_Xb435?$oW zWxkrSWaer5|9m(xlC!j_%K8B?G|BoWC*60#`*BIR8)l{JxyAm|LFdeFq*yQe83v6k zch7VX_lkp)qt4xIKl@3J)}5uAHxmd$o;DCB1r%GxB1YB^gq^bF34t)>uz@fx6jvm8 zssB7y1j2e7^!y-|6QBGf9|F+^}Cw*6F33ul)`e0YE%$;OtOQcZQ z>F3GMB4t07NSU?+L7R;x=Ka#{ uV3JiI27@Q}O8&_LXZwhg@!8Z^V)wf$hW1krp4pgLe!k%qfwY0x+5ZQe1aH{@ literal 0 HcmV?d00001 diff --git a/locales/eo/LC_MESSAGES/messages.po b/locales/eo/LC_MESSAGES/messages.po index 21e2d23bb..bfd12de9e 100644 --- a/locales/eo/LC_MESSAGES/messages.po +++ b/locales/eo/LC_MESSAGES/messages.po @@ -7,10 +7,10 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-07-16 11:12+0000\n" +"PO-Revision-Date: 2021-07-17 10:09+0000\n" "Last-Translator: phlostically \n" -"Language-Team: Esperanto \n" +"Language-Team: Esperanto \n" "Language: eo\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -27,10 +27,11 @@ msgid "" "The |PyPUG| welcomes contributors! There are lots of ways to help out, " "including:" msgstr "" +"La |PyPUG| bonvenigas kontribuantojn! Jen kelke el multaj manieroj helpi nin:" #: ../source/contribute.rst:10 msgid "Reading the guide and giving feedback" -msgstr "" +msgstr "Legi la gvidilon kaj doni opiniojn pri ĝi" #: ../source/contribute.rst:11 msgid "Reviewing new contributions" @@ -164,7 +165,7 @@ msgstr "" #: ../source/contribute.rst:105 msgid "The guide will be browsable via http://localhost:8000." -msgstr "" +msgstr "La gvidilo estos legebla ĉe http://localhost:8000." #: ../source/contribute.rst:109 msgid "Where the guide is deployed" @@ -282,13 +283,15 @@ msgstr "" #: ../source/contribute.rst:192 msgid "**Write to the reader**" -msgstr "" +msgstr "**Verku por la leganto**" #: ../source/contribute.rst:187 msgid "" "When giving recommendations or steps to take, address the reader as *you* or " "use the imperative mood." msgstr "" +"Kiam vi donas rekomendojn aŭ farendaĵojn, alparolu la leganton kiel «vi», aŭ " +"uzu la imperativon." #: ../source/contribute.rst:0 msgid "Wrong: To install it, the user runs…" @@ -334,6 +337,8 @@ msgid "" "When naming tools, sites, people, and other proper nouns, use their " "preferred capitalization." msgstr "" +"Kiam vi nomas ilojn, retejojn, homojn kaj aliajn proprajn nomojn, uzu iliajn " +"preferatajn usklojn." #: ../source/contribute.rst:0 msgid "Wrong: Pip uses…" @@ -396,11 +401,11 @@ msgstr "" #: ../source/contribute.rst:0 msgid "Wrong: Things You Should Know About Python" -msgstr "" +msgstr "Netaŭga: Sciindaĵoj Pri Python" #: ../source/contribute.rst:0 msgid "Right: Things you should know about Python" -msgstr "" +msgstr "Taŭga: Sciindaĵoj pri Python" #: ../source/contribute.rst:237 msgid "**Numbers**" @@ -472,7 +477,7 @@ msgstr "" #: ../source/discussions/deploying-python-applications.rst:40 msgid "OS packaging & installers" -msgstr "" +msgstr "Pakado kaj instaliloj por mastrumaj sistemoj" #: ../source/discussions/deploying-python-applications.rst:52 msgid "Windows" @@ -510,11 +515,11 @@ msgstr "" #: ../source/discussions/deploying-python-applications.rst:80 msgid "Application bundles" -msgstr "" +msgstr "Aplikprogramaj faskoj" #: ../source/discussions/deploying-python-applications.rst:91 msgid "Configuration management" -msgstr "" +msgstr "Administrado de agordoj" #: ../source/discussions/index.rst:4 msgid "" @@ -669,7 +674,7 @@ msgstr "**easy_install**" #: ../source/discussions/pip-vs-easy-install.rst:27 msgid "Installs from :term:`Wheels `" -msgstr "" +msgstr "Instali el :term:`Wheel `" #: ../source/discussions/pip-vs-easy-install.rst:27 #: ../source/discussions/pip-vs-easy-install.rst:38 @@ -695,7 +700,7 @@ msgstr "Ne" #: ../source/discussions/pip-vs-easy-install.rst:30 msgid "Uninstall Packages" -msgstr "" +msgstr "Malinstali Pakojn" #: ../source/discussions/pip-vs-easy-install.rst:30 msgid "Yes (``python -m pip uninstall``)" @@ -711,7 +716,7 @@ msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:35 msgid "List Installed Packages" -msgstr "" +msgstr "Listigi instalitajn pakojn" #: ../source/discussions/pip-vs-easy-install.rst:35 msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" @@ -723,11 +728,11 @@ msgstr "Subteno de :pep:`438`" #: ../source/discussions/pip-vs-easy-install.rst:41 msgid "Installation format" -msgstr "" +msgstr "Instala dosierformo" #: ../source/discussions/pip-vs-easy-install.rst:41 msgid "'Flat' packages with :file:`egg-info` metadata." -msgstr "" +msgstr "Plata pako kun metadatenoj en :file:`egg-info`." #: ../source/discussions/pip-vs-easy-install.rst:41 msgid "Encapsulated Egg format" @@ -6746,7 +6751,7 @@ msgstr "" #: ../source/key_projects.rst:90 msgid "packaging" -msgstr "packaging" +msgstr "pakado" #: ../source/key_projects.rst:92 msgid "" @@ -10291,7 +10296,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:644 msgid "Rarely Used Fields" -msgstr "" +msgstr "Malofte uzataj kampoj" #: ../source/specifications/core-metadata.rst:646 msgid "" @@ -10375,7 +10380,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:730 msgid "reStructuredText markup: http://docutils.sourceforge.net/" -msgstr "" +msgstr "Marklingvo reStructuredText: http://docutils.sourceforge.net/" #: ../source/specifications/core-metadata.rst:735 msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" @@ -10432,7 +10437,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:29 #: ../source/specifications/declaring-project-metadata.rst:41 msgid "``name``" -msgstr "" +msgstr "``name``" #: ../source/specifications/declaring-project-metadata.rst:31 msgid "" @@ -10443,7 +10448,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:34 #: ../source/specifications/declaring-project-metadata.rst:54 msgid "``version``" -msgstr "" +msgstr "``version``" #: ../source/specifications/declaring-project-metadata.rst:36 msgid "" @@ -10456,7 +10461,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:68 #: ../source/specifications/declaring-project-metadata.rst:117 msgid "TOML_ type: string" -msgstr "" +msgstr "Tipo de TOML_: signoĉeno" #: ../source/specifications/declaring-project-metadata.rst:44 msgid "" @@ -10466,7 +10471,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:47 msgid "The name of the project." -msgstr "" +msgstr "La nomo de la projekto." #: ../source/specifications/declaring-project-metadata.rst:49 msgid "" @@ -10482,7 +10487,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:60 msgid "The version of the project as supported by :pep:`440`." -msgstr "" +msgstr "La versio de la projekto laŭ :pep:`440`." #: ../source/specifications/declaring-project-metadata.rst:62 msgid "Users SHOULD prefer to specify already-normalized versions." @@ -10490,7 +10495,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:66 msgid "``description``" -msgstr "" +msgstr "``description``" #: ../source/specifications/declaring-project-metadata.rst:69 msgid "" @@ -10500,15 +10505,15 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:72 msgid "The summary description of the project." -msgstr "" +msgstr "La resuma priskribo de la projekto." #: ../source/specifications/declaring-project-metadata.rst:76 msgid "``readme``" -msgstr "" +msgstr "``readme``" #: ../source/specifications/declaring-project-metadata.rst:78 msgid "TOML_ type: string or table" -msgstr "" +msgstr "Tipo de TOML_: signoĉeno aŭ tabelo" #: ../source/specifications/declaring-project-metadata.rst:79 msgid "" @@ -10558,7 +10563,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:115 msgid "``requires-python``" -msgstr "" +msgstr "``requires-python``" #: ../source/specifications/declaring-project-metadata.rst:118 msgid "" @@ -10572,11 +10577,11 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:125 msgid "``license``" -msgstr "" +msgstr "``license``" #: ../source/specifications/declaring-project-metadata.rst:127 msgid "TOML_ type: table" -msgstr "" +msgstr "Tipo de TOML_: tabelo" #: ../source/specifications/declaring-project-metadata.rst:128 msgid "" @@ -10663,12 +10668,12 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:181 msgid "``keywords``" -msgstr "" +msgstr "``keywords``" #: ../source/specifications/declaring-project-metadata.rst:183 #: ../source/specifications/declaring-project-metadata.rst:193 msgid "TOML_ type: array of strings" -msgstr "" +msgstr "Tipo de TOML_: listo de signoĉenoj" #: ../source/specifications/declaring-project-metadata.rst:184 msgid "" @@ -10678,11 +10683,11 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:187 msgid "The keywords for the project." -msgstr "" +msgstr "La ŝlosilvortoj pri la projekto." #: ../source/specifications/declaring-project-metadata.rst:191 msgid "``classifiers``" -msgstr "" +msgstr "``classifiers``" #: ../source/specifications/declaring-project-metadata.rst:194 msgid "" @@ -10696,7 +10701,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:201 msgid "``urls``" -msgstr "" +msgstr "``urls``" #: ../source/specifications/declaring-project-metadata.rst:203 msgid "TOML_ type: table with keys and values of strings" @@ -10761,7 +10766,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:242 msgid "``dependencies``/``optional-dependencies``" -msgstr "" +msgstr "``dependencies``/``optional-dependencies``" #: ../source/specifications/declaring-project-metadata.rst:244 msgid "" @@ -10801,11 +10806,11 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:269 msgid "``dynamic``" -msgstr "" +msgstr "``dynamic``" #: ../source/specifications/declaring-project-metadata.rst:271 msgid "TOML_ type: array of string" -msgstr "" +msgstr "Tipo de TOML_: listo de signoĉenoj" #: ../source/specifications/declaring-project-metadata.rst:272 msgid "" @@ -10899,7 +10904,7 @@ msgstr "" #: ../source/specifications/direct-url.rst:17 msgid "Specification" -msgstr "" +msgstr "Specifado" #: ../source/specifications/direct-url.rst:19 msgid "" @@ -12406,7 +12411,7 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:159 msgid "Ensure pip, setuptools, and wheel are up to date" -msgstr "" +msgstr "Certigu, ke pip, setuptools kaj wheel estas ĝisdataj" #: ../source/tutorials/installing-packages.rst:161 msgid "" @@ -12435,7 +12440,7 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:195 msgid "Creating Virtual Environments" -msgstr "" +msgstr "Krei Virtualajn Mediojn" #: ../source/tutorials/installing-packages.rst:197 msgid "" @@ -12498,15 +12503,15 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:230 msgid "The basic usage is like so:" -msgstr "" +msgstr "Jen la baza uzmaniero:" #: ../source/tutorials/installing-packages.rst:232 msgid "Using `venv`_:" -msgstr "" +msgstr "Uzante `venv`_:" #: ../source/tutorials/installing-packages.rst:248 msgid "Using :ref:`virtualenv`:" -msgstr "" +msgstr "Uzante :ref:`virtualenv`:" #: ../source/tutorials/installing-packages.rst:264 msgid "" @@ -12538,7 +12543,7 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:288 msgid "Use pip for Installing" -msgstr "" +msgstr "Uzu pip por instali" #: ../source/tutorials/installing-packages.rst:290 msgid "" @@ -12550,7 +12555,7 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:297 msgid "Installing from PyPI" -msgstr "" +msgstr "Instali el PyPI" #: ../source/tutorials/installing-packages.rst:299 msgid "" @@ -12565,11 +12570,11 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:307 msgid "To install the latest version of \"SomeProject\":" -msgstr "" +msgstr "Por instali la plej novan version de «SomeProject»:" #: ../source/tutorials/installing-packages.rst:321 msgid "To install a specific version:" -msgstr "" +msgstr "Por instali specifan version:" #: ../source/tutorials/installing-packages.rst:335 msgid "To install greater than or equal to one version and less than another:" @@ -12589,7 +12594,7 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:370 msgid "Source Distributions vs Wheels" -msgstr "" +msgstr "Fonto-Distribuoj kontraste kun Wheel-oj" #: ../source/tutorials/installing-packages.rst:372 msgid "" @@ -12690,11 +12695,11 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:502 msgid "Installing from other Indexes" -msgstr "" +msgstr "Instali el aliaj Indeksoj" #: ../source/tutorials/installing-packages.rst:504 msgid "Install from an alternate index" -msgstr "" +msgstr "Instali el alternativa indekso" #: ../source/tutorials/installing-packages.rst:518 msgid "" @@ -12730,7 +12735,7 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:605 msgid "Installing from other sources" -msgstr "" +msgstr "Instali el aliaj fontoj" #: ../source/tutorials/installing-packages.rst:607 msgid "" @@ -13082,7 +13087,7 @@ msgstr "Agordi metadatenojn" #: ../source/tutorials/packaging-projects.rst:133 msgid "There are two types of metadata: static and dynamic." -msgstr "" +msgstr "Ekzistas du tipoj de metadatenoj: statika kaj dinamika." #: ../source/tutorials/packaging-projects.rst:135 msgid "" @@ -13400,7 +13405,7 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:460 msgid "Finally, it's time to upload your package to the Python Package Index!" -msgstr "" +msgstr "Finfine, vi pretas alŝuti vian pakon al PyPI!" #: ../source/tutorials/packaging-projects.rst:462 msgid "" @@ -13451,7 +13456,7 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:528 msgid "Installing your newly uploaded package" -msgstr "" +msgstr "Instali vian nove alŝutitan pakon" #: ../source/tutorials/packaging-projects.rst:530 msgid "" @@ -13462,7 +13467,7 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:546 msgid "Make sure to specify your username in the package name!" -msgstr "" +msgstr "Certigu, ke vi indikas vian salutnomon en la nomo de la pako!" #: ../source/tutorials/packaging-projects.rst:548 msgid "" @@ -13488,7 +13493,7 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:580 msgid "and import the package:" -msgstr "" +msgstr "kaj enportu la pakon:" #: ../source/tutorials/packaging-projects.rst:588 msgid "" @@ -13501,7 +13506,7 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:596 msgid "" "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" -msgstr "" +msgstr "**Gratulon, vi pakis kaj distribuis Python-projekton!** ✨ 🍰 ✨" #: ../source/tutorials/packaging-projects.rst:599 msgid "" @@ -13544,6 +13549,8 @@ msgid "" "Install your package from the real PyPI using ``python3 -m pip install [your-" "package]``." msgstr "" +"Instalu vian pakon el la vera PyPI per ``python3 -m pip install [your-" +"package]``." #: ../source/tutorials/packaging-projects.rst:619 msgid "" @@ -13559,7 +13566,7 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:624 msgid "Read about :doc:`/guides/packaging-binary-extensions`." -msgstr "" +msgstr "Legu pri :doc:`/guides/packaging-binary-extensions`." #: ../source/tutorials/packaging-projects.rst:625 msgid "" From 3f9148b1b7ff4a16b0cfa6f1c030dadbce1be2f9 Mon Sep 17 00:00:00 2001 From: HelaBasa Date: Sun, 29 Aug 2021 18:15:38 +0200 Subject: [PATCH 0091/1072] Added translation using Weblate (Sinhala) Co-authored-by: HelaBasa --- locales/si/LC_MESSAGES/messages.mo | Bin 0 -> 464 bytes locales/si/LC_MESSAGES/messages.po | 9253 ++++++++++++++++++++++++++++ 2 files changed, 9253 insertions(+) create mode 100644 locales/si/LC_MESSAGES/messages.mo create mode 100644 locales/si/LC_MESSAGES/messages.po diff --git a/locales/si/LC_MESSAGES/messages.mo b/locales/si/LC_MESSAGES/messages.mo new file mode 100644 index 0000000000000000000000000000000000000000..fe53fa45de4a71512624f6f3cecc033acd839b00 GIT binary patch literal 464 zcmYL_%TB{E5Jf?-%91q;FIa$J5?Ucq+=mD>g-T6Zr75qS+YE^zwJqB%^h4nD_!b;0 z(UFd9%Xh~2`sZN(Ysb~DZkD-$R8r!NN08u(S1r(G7Abj-!UW?bTA;pFpfwoio^ckI_!3nXfo+IsmPZsM@W$^wmw>gwaU;SD5SBN z`5!oQqtKT+57frL2`aCFV)J*FbCH8u+rk;EB!&mu(UchO#r-(i#;y71-mMfCh4Z;q zE{MfX8>o_T(IoSNX@j;sO?%MT>Z&}is38(_nYjlkY0S9w#^qA85_(cE3?)MS9ZkF5 hB%5tpkPfLey(hRsfqL^HkDEN?!oT$Ekm1VP`31dfixU6< literal 0 HcmV?d00001 diff --git a/locales/si/LC_MESSAGES/messages.po b/locales/si/LC_MESSAGES/messages.po new file mode 100644 index 000000000..e35f7229a --- /dev/null +++ b/locales/si/LC_MESSAGES/messages.po @@ -0,0 +1,9253 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2013–2020, PyPA +# This file is distributed under the same license as the Python Packaging User Guide package. +# HelaBasa , 2021. +msgid "" +msgstr "" +"Project-Id-Version: Python Packaging User Guide\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-07-06 19:32+0800\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Automatically generated\n" +"Language-Team: none\n" +"Language: si\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: ../source/contribute.rst:5 +msgid "Contribute to this guide" +msgstr "" + +#: ../source/contribute.rst:7 +msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" +msgstr "" + +#: ../source/contribute.rst:10 +msgid "Reading the guide and giving feedback" +msgstr "" + +#: ../source/contribute.rst:11 +msgid "Reviewing new contributions" +msgstr "" + +#: ../source/contribute.rst:12 +msgid "Revising existing content" +msgstr "" + +#: ../source/contribute.rst:13 +msgid "Writing new content" +msgstr "" + +#: ../source/contribute.rst:15 +msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." +msgstr "" + +#: ../source/contribute.rst:24 +msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." +msgstr "" + +#: ../source/contribute.rst:31 +msgid "Documentation types" +msgstr "" + +#: ../source/contribute.rst:33 +msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." +msgstr "" + +#: ../source/contribute.rst:38 +#: ../source/tutorials/index.rst:2 +msgid "Tutorials" +msgstr "" + +#: ../source/contribute.rst:40 +msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." +msgstr "" + +#: ../source/contribute.rst:47 +#: ../source/guides/index.rst:2 +msgid "Guides" +msgstr "" + +#: ../source/contribute.rst:49 +msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." +msgstr "" + +#: ../source/contribute.rst:56 +#: ../source/discussions/index.rst:2 +msgid "Discussions" +msgstr "" + +#: ../source/contribute.rst:58 +msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." +msgstr "" + +#: ../source/contribute.rst:63 +msgid "Specifications" +msgstr "" + +#: ../source/contribute.rst:65 +msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." +msgstr "" + +#: ../source/contribute.rst:73 +msgid "Building the guide locally" +msgstr "" + +#: ../source/contribute.rst:75 +msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" +msgstr "" + +#: ../source/contribute.rst:79 +msgid "`Nox `_. You can install or upgrade nox using ``pip``::" +msgstr "" + +#: ../source/contribute.rst:84 +msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." +msgstr "" + +#: ../source/contribute.rst:91 +msgid "To build the guide, run the following bash command in the source folder::" +msgstr "" + +#: ../source/contribute.rst:95 +msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." +msgstr "" + +#: ../source/contribute.rst:100 +msgid "You can build the guide and serve it via an HTTP server using the following command::" +msgstr "" + +#: ../source/contribute.rst:105 +msgid "The guide will be browsable via http://localhost:8000." +msgstr "" + +#: ../source/contribute.rst:109 +msgid "Where the guide is deployed" +msgstr "" + +#: ../source/contribute.rst:111 +msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." +msgstr "" + +#: ../source/contribute.rst:117 +msgid "Style guide" +msgstr "" + +#: ../source/contribute.rst:119 +msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." +msgstr "" + +#: ../source/contribute.rst:126 +msgid "Purpose" +msgstr "" + +#: ../source/contribute.rst:128 +msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." +msgstr "" + +#: ../source/contribute.rst:133 +msgid "Scope" +msgstr "" + +#: ../source/contribute.rst:135 +msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." +msgstr "" + +#: ../source/contribute.rst:138 +msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." +msgstr "" + +#: ../source/contribute.rst:146 +msgid "Audience" +msgstr "" + +#: ../source/contribute.rst:148 +msgid "The audience of this guide is anyone who uses Python with packages." +msgstr "" + +#: ../source/contribute.rst:150 +msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." +msgstr "" + +#: ../source/contribute.rst:154 +msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." +msgstr "" + +#: ../source/contribute.rst:160 +msgid "Voice and tone" +msgstr "" + +#: ../source/contribute.rst:162 +msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." +msgstr "" + +#: ../source/contribute.rst:165 +msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." +msgstr "" + +#: ../source/contribute.rst:170 +msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." +msgstr "" + +#: ../source/contribute.rst:177 +msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." +msgstr "" + +#: ../source/contribute.rst:184 +msgid "Conventions and mechanics" +msgstr "" + +#: ../source/contribute.rst:192 +msgid "**Write to the reader**" +msgstr "" + +#: ../source/contribute.rst:187 +msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: To install it, the user runs…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: You can install it by running…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: To install it, run…" +msgstr "" + +#: ../source/contribute.rst:198 +msgid "**State assumptions**" +msgstr "" + +#: ../source/contribute.rst:195 +msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." +msgstr "" + +#: ../source/contribute.rst:203 +msgid "**Cross-reference generously**" +msgstr "" + +#: ../source/contribute.rst:201 +msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." +msgstr "" + +#: ../source/contribute.rst:213 +msgid "**Respect naming practices**" +msgstr "" + +#: ../source/contribute.rst:206 +msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: Pip uses…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: pip uses…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: …hosted on github." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: …hosted on GitHub." +msgstr "" + +#: ../source/contribute.rst:222 +msgid "**Use a gender-neutral style**" +msgstr "" + +#: ../source/contribute.rst:216 +msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: A maintainer uploads the file. Then he…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then they…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then the maintainer…" +msgstr "" + +#: ../source/contribute.rst:234 +msgid "**Headings**" +msgstr "" + +#: ../source/contribute.rst:225 +msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." +msgstr "" + +#: ../source/contribute.rst:230 +msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: Things You Should Know About Python" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: Things you should know about Python" +msgstr "" + +#: ../source/contribute.rst:237 +msgid "**Numbers**" +msgstr "" + +#: ../source/contribute.rst:237 +msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:4 +msgid "Deploying Python applications" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Page Status" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:6 +#: ../source/guides/index-mirrors-and-caches.rst:7 +#: ../source/guides/installing-using-linux-tools.rst:7 +#: ../source/guides/packaging-binary-extensions.rst:7 +#: ../source/guides/supporting-multiple-python-versions.rst:7 +#: ../source/guides/supporting-windows-using-appveyor.rst:5 +msgid "Incomplete" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Last Reviewed" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:7 +msgid "2014-11-11" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:11 +#: ../source/discussions/install-requires-vs-requirements.rst:9 +#: ../source/guides/analyzing-pypi-package-downloads.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:22 +#: ../source/guides/index-mirrors-and-caches.rst:12 +#: ../source/guides/installing-scientific-packages.rst:9 +#: ../source/guides/packaging-binary-extensions.rst:17 +#: ../source/guides/supporting-multiple-python-versions.rst:12 +#: ../source/guides/supporting-windows-using-appveyor.rst:15 +#: ../source/overview.rst:23 +#: ../source/specifications/core-metadata.rst:38 +#: ../source/specifications/direct-url.rst:14 +#: ../source/tutorials/installing-packages.rst:23 +msgid "Contents" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:14 +msgid "Overview" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:18 +msgid "Supporting multiple hardware platforms" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:40 +msgid "OS packaging & installers" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:52 +msgid "Windows" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:61 +msgid "Pynsist" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:63 +msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:70 +msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:74 +msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:80 +msgid "Application bundles" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:91 +msgid "Configuration management" +msgstr "" + +#: ../source/discussions/index.rst:4 +msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:5 +msgid "install_requires vs requirements files" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:382 +msgid "install_requires" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:14 +msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:19 +msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:29 +msgid "Additionally, it's best practice to indicate any known lower or upper bounds." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:31 +msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:41 +msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:51 +msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:56 +msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:64 +#: ../source/tutorials/installing-packages.rst:460 +msgid "Requirements files" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:66 +msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:69 +msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:73 +msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:78 +msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:84 +msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:90 +msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:6 +msgid "pip vs easy_install" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:9 +msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:14 +msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:22 +msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**pip**" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**easy_install**" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +msgid "Installs from :term:`Wheels `" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Yes" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:30 +#: ../source/discussions/pip-vs-easy-install.rst:32 +#: ../source/discussions/pip-vs-easy-install.rst:35 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:51 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "No" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Uninstall Packages" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Yes (``python -m pip uninstall``)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Dependency Overrides" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Yes (:ref:`Requirements Files `)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "List Installed Packages" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:38 +msgid ":pep:`438` Support" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Installation format" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "'Flat' packages with :file:`egg-info` metadata." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Encapsulated Egg format" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:44 +msgid "sys.path modification" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:48 +msgid "Installs from :term:`Eggs `" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "`pylauncher support`_" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "Yes [1]_" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:54 +msgid ":ref:`Multi-version Installs`" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Exclude scripts during install" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "per project index" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Only in virtualenv" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Yes, via setup.cfg" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:68 +msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:5 +msgid "Wheel vs Egg" +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:7 +msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:11 +msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:14 +msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:17 +msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:20 +msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:22 +msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:26 +msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:31 +msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:34 +msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:38 +msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:41 +msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:47 +msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." +msgstr "" + +#: ../source/glossary.rst:3 +msgid "Glossary" +msgstr "" + +#: ../source/glossary.rst:8 +msgid "Binary Distribution" +msgstr "" + +#: ../source/glossary.rst:11 +msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." +msgstr "" + +#: ../source/glossary.rst:14 +msgid "Built Distribution" +msgstr "" + +#: ../source/glossary.rst:17 +msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." +msgstr "" + +#: ../source/glossary.rst:26 +msgid "Distribution Package" +msgstr "" + +#: ../source/glossary.rst:29 +msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." +msgstr "" + +#: ../source/glossary.rst:34 +msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." +msgstr "" + +#: ../source/glossary.rst:41 +msgid "Egg" +msgstr "" + +#: ../source/glossary.rst:44 +msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" +msgstr "" + +#: ../source/glossary.rst:49 +msgid "Extension Module" +msgstr "" + +#: ../source/glossary.rst:52 +msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." +msgstr "" + +#: ../source/glossary.rst:59 +msgid "Known Good Set (KGS)" +msgstr "" + +#: ../source/glossary.rst:62 +msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." +msgstr "" + +#: ../source/glossary.rst:68 +msgid "Import Package" +msgstr "" + +#: ../source/glossary.rst:71 +msgid "A Python module which can contain other modules or recursively, other packages." +msgstr "" + +#: ../source/glossary.rst:74 +msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." +msgstr "" + +#: ../source/glossary.rst:78 +msgid "Module" +msgstr "" + +#: ../source/glossary.rst:81 +msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." +msgstr "" + +#: ../source/glossary.rst:84 +msgid "Package Index" +msgstr "" + +#: ../source/glossary.rst:87 +msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." +msgstr "" + +#: ../source/glossary.rst:90 +msgid "Per Project Index" +msgstr "" + +#: ../source/glossary.rst:93 +msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." +msgstr "" + +#: ../source/glossary.rst:97 +msgid "Project" +msgstr "" + +#: ../source/glossary.rst:100 +msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." +msgstr "" + +#: ../source/glossary.rst:104 +msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." +msgstr "" + +#: ../source/glossary.rst:110 +msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." +msgstr "" + +#: ../source/glossary.rst:115 +msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." +msgstr "" + +#: ../source/glossary.rst:121 +msgid "Pure Module" +msgstr "" + +#: ../source/glossary.rst:124 +msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." +msgstr "" + +#: ../source/glossary.rst:127 +msgid "Python Packaging Authority (PyPA)" +msgstr "" + +#: ../source/glossary.rst:130 +msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." +msgstr "" + +#: ../source/glossary.rst:139 +msgid "Python Package Index (PyPI)" +msgstr "" + +#: ../source/glossary.rst:142 +msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." +msgstr "" + +#: ../source/glossary.rst:145 +msgid "pypi.org" +msgstr "" + +#: ../source/glossary.rst:148 +msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." +msgstr "" + +#: ../source/glossary.rst:152 +msgid "pyproject.toml" +msgstr "" + +#: ../source/glossary.rst:155 +msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." +msgstr "" + +#: ../source/glossary.rst:157 +msgid "Release" +msgstr "" + +#: ../source/glossary.rst:160 +msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." +msgstr "" + +#: ../source/glossary.rst:163 +msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." +msgstr "" + +#: ../source/glossary.rst:168 +msgid "Requirement" +msgstr "" + +#: ../source/glossary.rst:171 +msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." +msgstr "" + +#: ../source/glossary.rst:177 +msgid "Requirement Specifier" +msgstr "" + +#: ../source/glossary.rst:180 +msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" +msgstr "" + +#: ../source/glossary.rst:187 +msgid "Requirements File" +msgstr "" + +#: ../source/glossary.rst:190 +msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." +msgstr "" + +#: ../source/glossary.rst:194 +#: ../source/guides/distributing-packages-using-setuptools.rst:56 +msgid "setup.py" +msgstr "" + +#: ../source/glossary.rst:195 +#: ../source/guides/distributing-packages-using-setuptools.rst:77 +msgid "setup.cfg" +msgstr "" + +#: ../source/glossary.rst:198 +msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." +msgstr "" + +#: ../source/glossary.rst:201 +msgid "Source Archive" +msgstr "" + +#: ../source/glossary.rst:204 +msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:208 +msgid "Source Distribution (or \"sdist\")" +msgstr "" + +#: ../source/glossary.rst:211 +msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:216 +msgid "System Package" +msgstr "" + +#: ../source/glossary.rst:219 +msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." +msgstr "" + +#: ../source/glossary.rst:222 +msgid "Version Specifier" +msgstr "" + +#: ../source/glossary.rst:225 +msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." +msgstr "" + +#: ../source/glossary.rst:231 +msgid "Virtual Environment" +msgstr "" + +#: ../source/glossary.rst:234 +msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/glossary.rst:238 +msgid "Wheel" +msgstr "" + +#: ../source/glossary.rst:241 +msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." +msgstr "" + +#: ../source/glossary.rst:244 +msgid "Working Set" +msgstr "" + +#: ../source/glossary.rst:247 +msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:3 +msgid "Analyzing PyPI package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:5 +msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:15 +#: ../source/guides/supporting-windows-using-appveyor.rst:18 +msgid "Background" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:17 +msgid "PyPI does not display download statistics for a number of reasons: [#]_" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:19 +msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:24 +msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:27 +msgid "``pip``'s download cache (lowers download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:28 +msgid "Internal or unofficial mirrors (can both raise or lower download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:29 +msgid "Packages not hosted on PyPI (for comparisons sake)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:30 +msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:32 +msgid "Known historical data quality issues (lowers download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:34 +msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:38 +msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:43 +msgid "Public dataset" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:45 +msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:50 +msgid "Getting set up" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:52 +msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:58 +msgid "Navigate to the `BigQuery web UI`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:59 +msgid "Create a new project." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:60 +msgid "Enable the `BigQuery API `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:63 +msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:69 +msgid "Data schema" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:71 +msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +msgid "Column" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/guides/using-manifest-in.rst:67 +#: ../source/specifications/core-metadata.rst:185 +msgid "Description" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/specifications/direct-url.rst:226 +msgid "Examples" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "timestamp" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "Date and time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "``2020-03-09 00:33:03 UTC``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "file.project" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "Project name" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "``pipenv``, ``nose``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "file.version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "Package version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "``0.1.6``, ``1.4.2``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "details.installer.name" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "Installer" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "pip, `bandersnatch`_" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "details.python" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "Python version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "``2.7.12``, ``3.6.4``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:93 +msgid "Useful queries" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:95 +msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:97 +msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:102 +msgid "Counting package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:104 +msgid "The following query counts the total number of downloads for the project \"pytest\"." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:119 +#: ../source/guides/analyzing-pypi-package-downloads.rst:140 +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "num_downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:121 +msgid "26190085" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:124 +msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:142 +msgid "24334215" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:146 +msgid "Package downloads over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:148 +msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +msgid "month" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "1956741" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "2018-01-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2344692" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2017-12-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "1730398" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "2017-11-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2047310" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2017-10-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "1744443" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "2017-09-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "1916952" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "2017-08-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:184 +msgid "Python versions over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:186 +msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "python" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "3.7" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "18051328726" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "3.6" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "9635067203" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "3.8" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "7781904681" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "2.7" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "6381252241" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "null" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "2026630299" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "3.5" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "1894153540" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:221 +msgid "Caveats" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:223 +msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:231 +msgid "Additional tools" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:233 +msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:237 +msgid "``google-cloud-bigquery``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:239 +msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:267 +msgid "``pypinfo``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:269 +msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:273 +msgid "Install `pypinfo`_ using pip." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:279 +msgid "Usage:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:295 +msgid "``pandas-gbq``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:297 +msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:301 +#: ../source/specifications/binary-distribution-format.rst:459 +msgid "References" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:303 +msgid "`PyPI Download Counts deprecation email `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:304 +msgid "`PyPI BigQuery dataset announcement email `__" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:3 +msgid "Creating and discovering plugins" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:5 +msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:10 +msgid "There are three major approaches to doing automatic plugin discovery:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:12 +msgid "`Using naming convention`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:13 +msgid "`Using namespace packages`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:14 +msgid "`Using package metadata`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:18 +msgid "Using naming convention" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:20 +msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:38 +msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:48 +msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:59 +msgid "Using namespace packages" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:61 +msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:89 +msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:101 +msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:115 +msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:121 +msgid "Using package metadata" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:123 +msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:128 +msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:139 +msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:154 +msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:163 +msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:166 +msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:170 +msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:5 +msgid "Packaging and distributing projects" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:7 +msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:11 +msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:15 +msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:25 +msgid "Requirements for packaging and distributing" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:26 +msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:29 +msgid "Install \"twine\" [1]_:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:43 +msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:49 +msgid "Configuring your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:53 +msgid "Initial files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:58 +msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:63 +msgid ":file:`setup.py` serves two primary functions:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:65 +msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:71 +msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:79 +msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:86 +msgid "README.rst / README.md" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:88 +msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:95 +msgid "For an example, see `README.md `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:99 +msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:108 +msgid "MANIFEST.in" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:110 +msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:115 +msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:119 +msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:122 +msgid "LICENSE.txt" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:124 +msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:130 +msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:135 +msgid "" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:137 +msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:141 +msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:149 +msgid "setup() args" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:151 +msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:155 +msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:164 +msgid "name" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:170 +msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:174 +msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:176 +msgid "Start & end with an ASCII letter or digit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:178 +msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:190 +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "version" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:196 +msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:200 +msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:203 +msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:206 +msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:214 +msgid "description" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:222 +msgid "Give a short and long description for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:224 +msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:229 +msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:235 +msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:245 +msgid "url" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:252 +msgid "Give a homepage URL for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:256 +msgid "author" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:263 +msgid "Provide details about the author." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:267 +msgid "license" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:273 +msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:279 +msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:287 +msgid "classifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:316 +msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:319 +msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:327 +msgid "keywords" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:333 +msgid "List keywords that describe your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:337 +msgid "project_urls" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:349 +msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:355 +msgid "packages" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:361 +msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:370 +msgid "py_modules" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:376 +msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:388 +msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:392 +msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:398 +msgid "python_requires" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:400 +msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:407 +msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:412 +msgid "And so on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:416 +msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:422 +msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:431 +msgid "package_data" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:440 +msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:445 +msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:449 +msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:457 +msgid "data_files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:463 +msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:469 +msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:479 +msgid "For more information see the distutils section on `Installing Additional Files `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:484 +msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:491 +msgid "scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:493 +msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:500 +msgid "entry_points" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:509 +msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:512 +msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:516 +msgid "The most commonly used entry point is \"console_scripts\" (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:521 +msgid "console_scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:531 +msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:538 +msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:545 +msgid "Choosing a versioning scheme" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:548 +msgid "Standards compliance for interoperability" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:550 +msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:556 +msgid "Here are some examples of compliant version numbers::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:567 +msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:573 +msgid "Scheme choices" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:576 +msgid "Semantic versioning (preferred)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:578 +msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:582 +msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:585 +msgid "MAJOR version when they make incompatible API changes," +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:586 +msgid "MINOR version when they add functionality in a backwards-compatible manner, and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:587 +msgid "MAINTENANCE version when they make backwards-compatible bug fixes." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:589 +msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:594 +msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:598 +msgid "Date based versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:600 +msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:604 +msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:607 +msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:611 +msgid "Serial versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:613 +msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:616 +msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:621 +msgid "Hybrid schemes" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:623 +msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:629 +msgid "Pre-release versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:631 +msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:634 +msgid "zero or more dev releases (denoted with a \".devN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:635 +msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:636 +msgid "zero or more beta releases (denoted with a \".bN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:637 +msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:639 +msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:644 +msgid "Local version identifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:646 +msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:653 +msgid "A local version identifier takes the form ``+``. For example::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:661 +msgid "Working in \"development mode\"" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:663 +msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:667 +msgid "Assuming you're in the root of your project directory, then run:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:674 +msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:680 +msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:688 +msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:692 +msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:697 +msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:701 +msgid "Lastly, if you don't want to install any dependencies at all, you can run::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:706 +msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:713 +msgid "Packaging your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:715 +msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:720 +msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:737 +msgid "Source distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:739 +msgid "Minimally, you should create a :term:`Source Distribution `:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:755 +msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:763 +msgid "Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:765 +msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:770 +msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:773 +msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:776 +msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:785 +msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:792 +msgid "Pure Python Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:794 +msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:797 +#: ../source/guides/distributing-packages-using-setuptools.rst:826 +msgid "To build the wheel:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:811 +msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:815 +msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:821 +msgid "Platform Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:823 +msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:841 +msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:847 +msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:855 +msgid "Uploading your Project to PyPI" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:857 +msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:861 +msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:866 +msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:871 +msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:877 +msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:888 +msgid "Create an account" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:890 +msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:894 +msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:897 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:901 +msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:904 +msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:913 +msgid "**Be aware that this stores your token in plaintext.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:915 +#: ../source/guides/migrating-to-pypi-org.rst:70 +#: ../source/guides/migrating-to-pypi-org.rst:109 +#: ../source/guides/using-testpypi.rst:83 +msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:921 +msgid "Upload your distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:923 +msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:926 +msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:930 +msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:937 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:944 +#: ../source/tutorials/installing-packages.rst:663 +msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:950 +msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:5 +msgid "Dropping support for older Python versions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:7 +msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:9 +msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:12 +msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:14 +msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:17 +msgid "Requirements" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:19 +msgid "This workflow requires that:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:21 +msgid "The publisher is using the latest version of :ref:`setuptools`," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:22 +msgid "The latest version of :ref:`twine` is used to upload the package," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:23 +msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:26 +msgid "Dealing with the universal wheels" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:28 +msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:36 +msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:48 +msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:53 +msgid "Defining the Python version required" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:56 +msgid "1. Download the newest version of Setuptools" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:58 +msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:60 +msgid "Steps:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:74 +msgid "`setuptools` version should be above 24.0.0." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:77 +msgid "2. Specify the version ranges for supported Python distributions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:79 +msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:81 +#: ../source/specifications/core-metadata.rst:139 +#: ../source/specifications/core-metadata.rst:463 +#: ../source/specifications/core-metadata.rst:487 +#: ../source/specifications/core-metadata.rst:527 +#: ../source/specifications/core-metadata.rst:550 +#: ../source/specifications/core-metadata.rst:583 +#: ../source/specifications/core-metadata.rst:693 +#: ../source/specifications/core-metadata.rst:722 +msgid "Examples::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:86 +msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:101 +msgid "3. Validating the Metadata before publishing" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:103 +msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:105 +msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:108 +msgid "You can see the contents of the generated file like this::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:112 +msgid "Validate that the following is in place, before publishing the package:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:114 +msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:115 +msgid "The Requires-Python field is set and matches your specification in setup.py." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:118 +msgid "4. Using Twine to publish" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:120 +msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:122 +msgid "Make sure you are using the newest version of Twine, at least 1.9." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:125 +msgid "Dropping a Python release" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:127 +msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:129 +msgid "It must be done in this order for the automated fallback to work." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:131 +msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:133 +msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:5 +msgid "Hosting your own simple repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:8 +msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:13 +msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:29 +msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:35 +msgid "\"Manual\" repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:37 +msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:51 +msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:58 +msgid "For complete documentation of the simple repository protocol, see :pep:`503`." +msgstr "" + +#: ../source/guides/index.rst:8 +#: ../source/guides/index.rst:8 +msgid "Installing Packages:" +msgstr "" + +#: ../source/guides/index.rst:20 +#: ../source/guides/index.rst:20 +msgid "Building and Publishing Projects:" +msgstr "" + +#: ../source/guides/index.rst:38 +#: ../source/guides/index.rst:38 +msgid "Miscellaneous:" +msgstr "" + +#: ../source/guides/index.rst:4 +msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:5 +msgid "Package index mirrors and caches" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:8 +#: ../source/guides/supporting-multiple-python-versions.rst:8 +msgid "2014-12-24" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:14 +msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:17 +msgid "Three options are available in this area:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:19 +msgid "pip provides local caching options," +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:20 +msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:22 +msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:27 +msgid "Caching with pip" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:29 +msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:32 +msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:36 +msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:45 +msgid "Caching with devpi" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:47 +msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:55 +msgid "Complete mirror with bandersnatch" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:57 +msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:63 +msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:5 +msgid "Installing scientific packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:11 +msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:16 +msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:22 +msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:29 +msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:35 +msgid "Building from source" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:37 +msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:45 +msgid "Linux distribution packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:47 +msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:51 +msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:57 +msgid "Windows installers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:59 +msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:64 +msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:67 +msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:73 +msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:79 +msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:86 +msgid "macOS installers and package managers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:88 +msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:92 +msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:99 +msgid "SciPy distributions" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:101 +msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:105 +msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:109 +#: ../source/key_projects.rst:596 +msgid "Spack" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:110 +msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:119 +msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:128 +msgid "The conda cross-platform package manager" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:130 +msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:136 +msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 +msgid "Installing stand alone command line tools" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 +msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 +msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 +msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 +msgid "pipx only works with Python 3.6+." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 +msgid "``pipx`` is installed with ``pip``:" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 +msgid "You may need to restart your terminal for the path updates to take effect." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 +msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 +#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 +msgid "For example" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 +msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 +msgid "To upgrade or uninstall the package" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 +msgid "``pipx`` can be upgraded or uninstalled with pip" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 +msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 +msgid "To see the full list of commands ``pipx`` offers, run" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 +msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:5 +msgid "Installing pip/setuptools/wheel with Linux Package Managers" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:8 +msgid "2015-09-17" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:11 +msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:14 +msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:18 +msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:25 +msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:32 +msgid "Fedora" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:34 +msgid "Fedora 21:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:36 +#: ../source/guides/installing-using-linux-tools.rst:45 +#: ../source/guides/installing-using-linux-tools.rst:124 +#: ../source/guides/installing-using-linux-tools.rst:138 +#: ../source/guides/installing-using-linux-tools.rst:158 +msgid "Python 2::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:41 +msgid "Python 3: ``sudo yum install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:43 +msgid "Fedora 22:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:50 +msgid "Python 3: ``sudo dnf install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:53 +msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:63 +msgid "CentOS/RHEL" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:65 +msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:68 +msgid "To install pip and wheel for the system Python, there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:70 +msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:77 +msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:81 +msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:85 +msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:92 +msgid "To additionally upgrade setuptools, run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:97 +msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:101 +msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:104 +msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:106 +msgid "For CentOS, see here: https://www.softwarecollections.org/en/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:108 +msgid "Be aware that collections may not contain the most recent versions." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:110 +msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:116 +msgid "For example, for Python 3.4 on CentOS7/RHEL7::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:122 +msgid "openSUSE" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:129 +#: ../source/guides/installing-using-linux-tools.rst:143 +#: ../source/guides/installing-using-linux-tools.rst:162 +msgid "Python 3::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:135 +msgid "Debian/Ubuntu" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:150 +msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:156 +msgid "Arch Linux" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:168 +msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 +msgid "Installing packages using pip and virtual environments" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 +msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 +msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 +msgid "Installing pip" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 +msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 +msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 +msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 +msgid "Afterwards, you should have the newest pip installed in your user site:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 +msgid "The Python installers for Windows include pip. You should be able to access pip using:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 +msgid "You can make sure that pip is up-to-date by running:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 +msgid "Installing virtualenv" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 +msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 +msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 +msgid "Creating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 +msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 +msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 +msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 +msgid "venv will create a virtual Python installation in the ``env`` folder." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 +msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 +msgid "Activating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 +msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 +msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 +msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 +msgid "Leaving the virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 +msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 +msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 +msgid "Installing packages" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 +msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 +msgid "pip should download requests and all of its dependencies and install them:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 +msgid "Installing specific versions" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 +msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 +msgid "To install the latest ``2.x`` release of requests:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 +msgid "To install pre-release versions of packages, use the ``--pre`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 +msgid "Installing extras" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 +msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 +msgid "Installing from source" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 +msgid "pip can install a package directly from source, for example:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 +msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 +msgid "Installing from version control systems" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 +msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 +msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 +#: ../source/tutorials/installing-packages.rst:569 +msgid "Installing from local archives" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 +msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 +msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 +msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 +msgid "Using other package indexes" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 +msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 +msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 +#: ../source/tutorials/installing-packages.rst:389 +msgid "Upgrading packages" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 +msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 +msgid "Using requirements files" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 +msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 +msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 +msgid "Freezing dependencies" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 +msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 +msgid "Which will output a list of package specifiers such as:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 +msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:2 +msgid "Making a PyPI-friendly README" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:4 +msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:9 +msgid "Creating a README file" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:11 +msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:13 +msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:16 +msgid "plain text" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:17 +msgid "`reStructuredText `_ (without Sphinx extensions)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:18 +msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:21 +msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:25 +msgid "Including your README in your package's metadata" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:27 +msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:33 +msgid ":ref:`description-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:34 +msgid ":ref:`description-content-type-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:36 +msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:39 +msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:45 +msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:60 +msgid "The minimum required versions of the respective tools are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:62 +msgid "``setuptools >= 38.6.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:63 +msgid "``wheel >= 0.31.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:64 +msgid "``twine >= 1.11.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:66 +msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:72 +msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:95 +msgid "Validating reStructuredText markup" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:97 +msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:100 +msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:105 +msgid "You can check your README for markup errors before uploading as follows:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:107 +msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:122 +msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:125 +msgid "Run ``twine check`` on the sdist and wheel::" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:129 +msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:4 +msgid "Migrating to PyPI.org" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:6 +msgid ":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``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:12 +msgid "Publishing releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:14 +msgid "``pypi.org`` is the default upload platform as of September 2016." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:16 +msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:22 +msgid "The default upload settings switched to ``pypi.org`` in the following versions:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:24 +msgid "``twine`` 1.8.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:25 +msgid "``setuptools`` 27.0.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:26 +msgid "Python 2.7.13 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:27 +msgid "Python 3.4.6 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:28 +msgid "Python 3.5.3 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:29 +msgid "Python 3.6.0 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:31 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:48 +msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:51 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:67 +msgid "(``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.)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:73 +msgid "Registering package names & metadata" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:75 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:79 +msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:84 +msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:89 +#: ../source/guides/using-testpypi.rst:5 +msgid "Using TestPyPI" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:91 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:113 +msgid "Registering new user accounts" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:115 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:121 +msgid "Browsing packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:123 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:130 +msgid "Downloading packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:132 +msgid "``pypi.org`` is the default host for downloading packages." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:135 +msgid "Managing published packages and releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:137 +msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:5 +msgid "Multi-version installs" +msgstr "" + +#: ../source/guides/multi-version-installs.rst:8 +msgid "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``)." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:13 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:31 +msgid "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 ``python -c ''`` to invoke the application's main entry point directly." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:38 +msgid "Refer to the `pkg_resources documentation `__ for more details." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:5 +msgid "Packaging binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:8 +msgid "2013-12-08" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:10 +msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:20 +msgid "An overview of binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:23 +msgid "Use cases" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:25 +msgid "The typical use cases for binary extensions break down into just three conventional categories:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:28 +msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:39 +msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:47 +msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:56 +msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:61 +msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:71 +msgid "Disadvantages" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:73 +msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:80 +msgid "This means that binary extensions:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:82 +msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:85 +msgid "may not be compatible with different builds of the CPython reference interpreter" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:88 +msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:91 +msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:96 +msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:101 +msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:108 +msgid "Alternatives to handcoded accelerator modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:110 +msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:115 +msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:122 +msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:132 +msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:141 +msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:150 +msgid "Alternatives to handcoded wrapper modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:152 +msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:158 +msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:162 +msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:168 +msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:175 +msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:181 +msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:185 +msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:189 +msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:203 +msgid "Alternatives for low level system access" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:205 +msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:213 +msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:222 +msgid "Implementing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:224 +msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:241 +msgid "Building binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:244 +msgid "Building extensions for multiple platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:246 +msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:256 +msgid "Binary extensions for Windows" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:258 +msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:263 +msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:269 +msgid "To set up a build environment for binary extensions, the steps are as follows:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:271 +msgid "For Python 2.7" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:273 +msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:276 +msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:278 +#: ../source/guides/packaging-binary-extensions.rst:288 +#: ../source/guides/packaging-binary-extensions.rst:295 +msgid "Done." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:280 +msgid "For Python 3.4" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:282 +msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:285 +msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:287 +msgid "Set DISTUTILS_USE_SDK=1" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:290 +msgid "For Python 3.5" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:292 +msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:297 +msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:301 +msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:305 +msgid "Binary extensions for Linux" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:307 +msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:313 +msgid "Binary extensions for macOS" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:315 +msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:325 +msgid "Publishing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:327 +msgid "For interim guidance on this topic, see the discussion in `this issue `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:343 +msgid "Additional resources" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:345 +msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:352 +msgid "Cross-platform wheel generation with scikit-build" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:354 +msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:362 +msgid "Introduction to C/C++ extension modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:364 +msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:367 +msgid "`What are (c)python extension modules? `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:368 +msgid "`Releasing the gil `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:369 +msgid "`Writing cpython extension modules using C++ `_" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:3 +msgid "Packaging namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:5 +msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:24 +msgid "And you use this package in your code like so::" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:29 +msgid "Then you can break these sub-packages into two separate distributions:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:46 +msgid "Each sub-package can now be separately installed, used, and versioned." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:48 +msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:58 +msgid "Creating a namespace package" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:60 +msgid "There are currently three different approaches to creating namespace packages:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:62 +msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:66 +msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:69 +msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:73 +msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:80 +msgid "Native namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:82 +msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:97 +msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:102 +msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:117 +msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:123 +msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:129 +msgid "pkgutil-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:131 +msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:136 +msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:148 +#: ../source/guides/packaging-namespace-packages.rst:194 +msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:155 +#: ../source/guides/packaging-namespace-packages.rst:201 +msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:160 +msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:171 +msgid "pkg_resources-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:173 +msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:182 +msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:206 +msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:216 +msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:223 +msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:237 +msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 +msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 +msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 +msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 +msgid "Saving credentials on GitHub" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 +msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 +msgid "Let's begin! 🚀" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 +msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 +msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 +msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 +msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 +msgid "Creating a workflow definition" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 +msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 +msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 +msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 +msgid "Defining a workflow job environment" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 +msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 +msgid "Checking out the project and building distributions" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 +msgid "Then, add the following under the ``build-n-publish`` section:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 +msgid "This will download your repository into the CI runner and then install and activate Python 3.7." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 +msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 +msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 +msgid "So add this to the steps list:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 +msgid "Publishing the distribution to PyPI and TestPyPI" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 +msgid "Finally, add the following steps at the end:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 +msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 +msgid "That's all, folks!" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 +msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:5 +msgid "Single-sourcing the package version" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:8 +msgid "There are many techniques to maintain a single source of truth for the version number of your project:" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:11 +msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:38 +msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:47 +msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:52 +msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:55 +msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:58 +msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:65 +msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:76 +msgid "Example using this technique: `warehouse `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:78 +msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:86 +msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:91 +msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:95 +msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:110 +msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:114 +msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:128 +msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:134 +msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:138 +msgid "Example using this technique: `setuptools `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:141 +msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:155 +msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:161 +msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:5 +msgid "Supporting multiple Python versions" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:37 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:43 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:49 +msgid "Automated testing and continuous integration" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:51 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:60 +msgid "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:" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:66 +msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:69 +msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:80 +msgid "Both `Travis CI`_ 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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:85 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:89 +msgid "Tools for single-source Python packages" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:91 +msgid "`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_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:100 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:107 +msgid "a Python 2 (by syntax) module in a Python 3 project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:108 +msgid "a Python 3 (by syntax) module in a *Python 2* project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:110 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:117 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:124 +msgid "What's in which Python?" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:126 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:3 +msgid "Supporting Windows using Appveyor" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:6 +msgid "2015-12-03" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:8 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:20 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:24 +msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:30 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:38 +msgid "Setting up" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:40 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:45 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:49 +msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:54 +msgid "Adding Appveyor support to your project" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:61 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:69 +msgid "appveyor.yml" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:75 +msgid "This file can be downloaded from `here `__." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:77 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:80 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:88 +msgid "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``)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:94 +msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:97 +msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:100 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:109 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:114 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:119 +msgid "Support script" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:121 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:126 +msgid "`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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:133 +msgid "You can simply download the batch file and include it in your project unchanged." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:137 +msgid "Access to the built wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:139 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:147 +msgid "Additional notes" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:150 +msgid "Testing with tox" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:152 +msgid "Many projects use the `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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:156 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:160 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:165 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:170 +msgid "``DISTUTILS_USE_SDK``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:171 +msgid "``MSSdk``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:172 +msgid "``INCLUDE``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:173 +msgid "``LIB``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:175 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:181 +msgid "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 Travis or 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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:188 +msgid "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``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:192 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:197 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:203 +msgid "Automatically uploading wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:205 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:210 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:216 +msgid "External dependencies" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:218 +msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:221 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:230 +msgid "Support scripts" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:232 +msgid "For reference, the SDK setup support script is listed here:" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:234 +msgid "``appveyor-sample/build.cmd``" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:5 +msgid "Tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:7 +msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:12 +msgid "Application dependency management" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:14 +msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:18 +msgid "When ``pipenv`` does not meet your use case, consider other tools like:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:20 +msgid ":ref:`pip`" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:22 +msgid "`pip-tools `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:24 +msgid "`Poetry `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:27 +msgid "Installation tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:29 +msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:34 +msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:37 +msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:40 +msgid ":ref:`buildout`: primarily focused on the web development community" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:42 +msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:47 +msgid "Packaging tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:49 +msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:52 +msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:56 +msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:61 +msgid "Publishing platform migration" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:63 +msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:67 +msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:72 +msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:77 +msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:82 +msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:88 +msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:93 +msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:102 +msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:107 +msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:5 +msgid "Including files in source distributions with ``MANIFEST.in``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:7 +msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:17 +msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:22 +msgid "How files are included in an sdist" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:24 +msgid "The following files are included in a source distribution by default:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:26 +msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:28 +msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:30 +msgid "scripts specified by the ``scripts`` ``setup()`` argument" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:31 +msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:33 +msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:35 +msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:37 +msgid "all files matching the pattern :file:`test/test*.py`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:38 +msgid ":file:`setup.py` (or whatever you called your setup script)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:39 +msgid ":file:`setup.cfg`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:40 +msgid ":file:`README`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:41 +msgid ":file:`README.txt`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:42 +msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:43 +msgid ":file:`README.md` (setuptools 36.4.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:44 +msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:45 +msgid ":file:`MANIFEST.in`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:47 +msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:52 +msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:60 +msgid ":file:`MANIFEST.in` commands" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:62 +msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:67 +msgid "Command" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid ":samp:`include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid "Add all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid ":samp:`exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid "Remove all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid ":samp:`global-include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid "Add all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid ":samp:`global-exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid "Remove all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid ":samp:`graft {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid "Add all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid ":samp:`prune {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid "Remove all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:79 +msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:87 +msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:91 +msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:95 +msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:101 +msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." +msgstr "" + +#: ../source/guides/using-testpypi.rst:7 +msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" +msgstr "" + +#: ../source/guides/using-testpypi.rst:13 +msgid "Registering your account" +msgstr "" + +#: ../source/guides/using-testpypi.rst:15 +msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." +msgstr "" + +#: ../source/guides/using-testpypi.rst:19 +msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." +msgstr "" + +#: ../source/guides/using-testpypi.rst:24 +msgid "Using TestPyPI with Twine" +msgstr "" + +#: ../source/guides/using-testpypi.rst:26 +msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:33 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/using-testpypi.rst:39 +msgid "Using TestPyPI with pip" +msgstr "" + +#: ../source/guides/using-testpypi.rst:41 +msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:56 +msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" +msgstr "" + +#: ../source/guides/using-testpypi.rst:73 +msgid "Setting up TestPyPI in :file:`.pypirc`" +msgstr "" + +#: ../source/guides/using-testpypi.rst:75 +msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" +msgstr "" + +#: ../source/index.rst:3 +#: ../source/key_projects.rst:181 +msgid "Python Packaging User Guide" +msgstr "" + +#: ../source/index.rst:5 +msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." +msgstr "" + +#: ../source/index.rst:5 +msgid "python, packaging, guide, tutorial" +msgstr "" + +#: ../source/index.rst:24 +msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." +msgstr "" + +#: ../source/index.rst:28 +msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" +msgstr "" + +#: ../source/index.rst:36 +msgid "Get started" +msgstr "" + +#: ../source/index.rst:38 +msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" +msgstr "" + +#: ../source/index.rst:41 +msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" +msgstr "" + +#: ../source/index.rst:43 +msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" +msgstr "" + +#: ../source/index.rst:45 +msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" +msgstr "" + +#: ../source/index.rst:47 +msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" +msgstr "" + +#: ../source/index.rst:52 +msgid "Learn more" +msgstr "" + +#: ../source/index.rst:54 +msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" +msgstr "" + +#: ../source/index.rst:56 +msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/index.rst:58 +msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." +msgstr "" + +#: ../source/index.rst:60 +msgid "The :doc:`specifications/index` section for packaging interoperability specifications." +msgstr "" + +#: ../source/index.rst:62 +msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." +msgstr "" + +#: ../source/key_projects.rst:6 +msgid "Project Summaries" +msgstr "" + +#: ../source/key_projects.rst:8 +msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." +msgstr "" + +#: ../source/key_projects.rst:14 +msgid "PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:19 +msgid "bandersnatch" +msgstr "" + +#: ../source/key_projects.rst:21 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:25 +msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." +msgstr "" + +#: ../source/key_projects.rst:35 +msgid "build" +msgstr "" + +#: ../source/key_projects.rst:37 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:42 +msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." +msgstr "" + +#: ../source/key_projects.rst:49 +msgid "cibuildwheel" +msgstr "" + +#: ../source/key_projects.rst:51 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" +msgstr "" + +#: ../source/key_projects.rst:58 +msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." +msgstr "" + +#: ../source/key_projects.rst:64 +msgid "distlib" +msgstr "" + +#: ../source/key_projects.rst:66 +msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:71 +msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." +msgstr "" + +#: ../source/key_projects.rst:80 +msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." +msgstr "" + +#: ../source/key_projects.rst:90 +msgid "packaging" +msgstr "" + +#: ../source/key_projects.rst:92 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:97 +msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." +msgstr "" + +#: ../source/key_projects.rst:99 +msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." +msgstr "" + +#: ../source/key_projects.rst:107 +msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." +msgstr "" + +#: ../source/key_projects.rst:119 +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "pip" +msgstr "" + +#: ../source/key_projects.rst:121 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:126 +msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." +msgstr "" + +#: ../source/key_projects.rst:129 +msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." +msgstr "" + +#: ../source/key_projects.rst:137 +msgid "Pipenv" +msgstr "" + +#: ../source/key_projects.rst:139 +msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:144 +msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." +msgstr "" + +#: ../source/key_projects.rst:148 +msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." +msgstr "" + +#: ../source/key_projects.rst:159 +msgid "Pipfile" +msgstr "" + +#: ../source/key_projects.rst:161 +msgid "`Source `__" +msgstr "" + +#: ../source/key_projects.rst:163 +msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." +msgstr "" + +#: ../source/key_projects.rst:170 +msgid "pipx" +msgstr "" + +#: ../source/key_projects.rst:172 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:176 +msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." +msgstr "" + +#: ../source/key_projects.rst:183 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:187 +msgid "This guide!" +msgstr "" + +#: ../source/key_projects.rst:192 +msgid "readme_renderer" +msgstr "" + +#: ../source/key_projects.rst:194 +msgid "`GitHub and docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:197 +msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." +msgstr "" + +#: ../source/key_projects.rst:208 +msgid "setuptools" +msgstr "" + +#: ../source/key_projects.rst:210 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:215 +msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." +msgstr "" + +#: ../source/key_projects.rst:220 +msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." +msgstr "" + +#: ../source/key_projects.rst:227 +msgid "trove-classifiers" +msgstr "" + +#: ../source/key_projects.rst:229 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:233 +msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." +msgstr "" + +#: ../source/key_projects.rst:239 +msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." +msgstr "" + +#: ../source/key_projects.rst:253 +msgid "twine" +msgstr "" + +#: ../source/key_projects.rst:255 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:260 +msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." +msgstr "" + +#: ../source/key_projects.rst:270 +#: ../source/overview.rst:415 +msgid "virtualenv" +msgstr "" + +#: ../source/key_projects.rst:272 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:277 +msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/key_projects.rst:290 +msgid "Warehouse" +msgstr "" + +#: ../source/key_projects.rst:292 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:296 +msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." +msgstr "" + +#: ../source/key_projects.rst:304 +msgid "wheel" +msgstr "" + +#: ../source/key_projects.rst:306 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:311 +msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." +msgstr "" + +#: ../source/key_projects.rst:315 +msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." +msgstr "" + +#: ../source/key_projects.rst:324 +msgid "Non-PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:329 +msgid "bento" +msgstr "" + +#: ../source/key_projects.rst:331 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:336 +msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." +msgstr "" + +#: ../source/key_projects.rst:344 +msgid "buildout" +msgstr "" + +#: ../source/key_projects.rst:346 +msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:351 +msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." +msgstr "" + +#: ../source/key_projects.rst:358 +msgid "conda" +msgstr "" + +#: ../source/key_projects.rst:360 +msgid "`Docs `__" +msgstr "" + +#: ../source/key_projects.rst:362 +msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." +msgstr "" + +#: ../source/key_projects.rst:369 +msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." +msgstr "" + +#: ../source/key_projects.rst:373 +msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." +msgstr "" + +#: ../source/key_projects.rst:386 +msgid "devpi" +msgstr "" + +#: ../source/key_projects.rst:388 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:392 +msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." +msgstr "" + +#: ../source/key_projects.rst:401 +msgid "flit" +msgstr "" + +#: ../source/key_projects.rst:403 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:407 +msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." +msgstr "" + +#: ../source/key_projects.rst:412 +msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." +msgstr "" + +#: ../source/key_projects.rst:422 +msgid "enscons" +msgstr "" + +#: ../source/key_projects.rst:424 +msgid "`Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:428 +msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." +msgstr "" + +#: ../source/key_projects.rst:443 +msgid "Hashdist" +msgstr "" + +#: ../source/key_projects.rst:445 +msgid "`Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:448 +msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." +msgstr "" + +#: ../source/key_projects.rst:460 +msgid "hatch" +msgstr "" + +#: ../source/key_projects.rst:462 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:465 +msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." +msgstr "" + +#: ../source/key_projects.rst:475 +msgid "multibuild" +msgstr "" + +#: ../source/key_projects.rst:477 +msgid "`GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:479 +msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." +msgstr "" + +#: ../source/key_projects.rst:485 +msgid "pex" +msgstr "" + +#: ../source/key_projects.rst:487 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:491 +msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." +msgstr "" + +#: ../source/key_projects.rst:500 +msgid "pip-tools" +msgstr "" + +#: ../source/key_projects.rst:502 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:505 +msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." +msgstr "" + +#: ../source/key_projects.rst:517 +msgid "piwheels" +msgstr "" + +#: ../source/key_projects.rst:519 +msgid "`Website `__ | `Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:523 +msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." +msgstr "" + +#: ../source/key_projects.rst:532 +msgid "poetry" +msgstr "" + +#: ../source/key_projects.rst:534 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:538 +msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." +msgstr "" + +#: ../source/key_projects.rst:548 +msgid "pypiserver" +msgstr "" + +#: ../source/key_projects.rst:550 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:554 +msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." +msgstr "" + +#: ../source/key_projects.rst:564 +msgid "scikit-build" +msgstr "" + +#: ../source/key_projects.rst:566 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:570 +msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." +msgstr "" + +#: ../source/key_projects.rst:582 +msgid "shiv" +msgstr "" + +#: ../source/key_projects.rst:584 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:588 +msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." +msgstr "" + +#: ../source/key_projects.rst:598 +msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" +msgstr "" + +#: ../source/key_projects.rst:603 +msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." +msgstr "" + +#: ../source/key_projects.rst:611 +msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." +msgstr "" + +#: ../source/key_projects.rst:617 +msgid "zest.releaser" +msgstr "" + +#: ../source/key_projects.rst:619 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:623 +msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." +msgstr "" + +#: ../source/key_projects.rst:630 +msgid "Standard Library Projects" +msgstr "" + +#: ../source/key_projects.rst:635 +msgid "ensurepip" +msgstr "" + +#: ../source/key_projects.rst:637 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:640 +msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." +msgstr "" + +#: ../source/key_projects.rst:649 +msgid "distutils" +msgstr "" + +#: ../source/key_projects.rst:651 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:654 +msgid "The original Python packaging system, added to the standard library in Python 2.0." +msgstr "" + +#: ../source/key_projects.rst:657 +msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." +msgstr "" + +#: ../source/key_projects.rst:670 +msgid "venv" +msgstr "" + +#: ../source/key_projects.rst:672 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:675 +msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/news.rst:2 +msgid "News" +msgstr "" + +#: ../source/news.rst:5 +msgid "September 2019" +msgstr "" + +#: ../source/news.rst:6 +msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" +msgstr "" + +#: ../source/news.rst:9 +msgid "August 2019" +msgstr "" + +#: ../source/news.rst:10 +msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" +msgstr "" + +#: ../source/news.rst:13 +msgid "July 2019" +msgstr "" + +#: ../source/news.rst:14 +msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" +msgstr "" + +#: ../source/news.rst:15 +msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" +msgstr "" + +#: ../source/news.rst:16 +msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" +msgstr "" + +#: ../source/news.rst:17 +msgid "Updated directory layout examples for consistency. (:pr:`611`)" +msgstr "" + +#: ../source/news.rst:18 +msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" +msgstr "" + +#: ../source/news.rst:21 +msgid "June 2019" +msgstr "" + +#: ../source/news.rst:22 +msgid "Fixed some typos. (:pr:`620`)" +msgstr "" + +#: ../source/news.rst:25 +msgid "May 2019" +msgstr "" + +#: ../source/news.rst:26 +msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" +msgstr "" + +#: ../source/news.rst:27 +msgid "Added a MANIFEST.in guide page. (:pr:`609`)" +msgstr "" + +#: ../source/news.rst:30 +msgid "April 2019" +msgstr "" + +#: ../source/news.rst:31 +msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" +msgstr "" + +#: ../source/news.rst:32 +msgid "Reduced emphasis on virtualenv. (:pr:`606`)" +msgstr "" + +#: ../source/news.rst:35 +msgid "March 2019" +msgstr "" + +#: ../source/news.rst:36 +msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" +msgstr "" + +#: ../source/news.rst:37 +msgid "Covered RTD details for contributing. (:pr:`600`)" +msgstr "" + +#: ../source/news.rst:40 +msgid "February 2019" +msgstr "" + +#: ../source/news.rst:41 +msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" +msgstr "" + +#: ../source/news.rst:42 +msgid "Added instructions to install Python CLI applications. (:pr:`594`)" +msgstr "" + +#: ../source/news.rst:45 +msgid "January 2019" +msgstr "" + +#: ../source/news.rst:46 +msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" +msgstr "" + +#: ../source/news.rst:47 +msgid "Updated Sphinx and Nox. (:pr:`591`)" +msgstr "" + +#: ../source/news.rst:48 +msgid "Referenced Twine from Python3. (:pr:`581`)" +msgstr "" + +#: ../source/news.rst:51 +msgid "December 2018" +msgstr "" + +#: ../source/news.rst:52 +msgid "No programmers in the office!" +msgstr "" + +#: ../source/news.rst:55 +msgid "November 2018" +msgstr "" + +#: ../source/news.rst:56 +msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" +msgstr "" + +#: ../source/news.rst:57 +msgid "Changed bumpversion to bump2version. (:pr:`572`)" +msgstr "" + +#: ../source/news.rst:58 +msgid "Added single-sourcing package version example. (:pr:`573`)" +msgstr "" + +#: ../source/news.rst:59 +msgid "Added a guide for creating documentation. (:pr:`568`)" +msgstr "" + +#: ../source/news.rst:62 +msgid "October 2018" +msgstr "" + +#: ../source/news.rst:63 +msgid "Updated Nox package name. (:pr:`566`)" +msgstr "" + +#: ../source/news.rst:64 +msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" +msgstr "" + +#: ../source/news.rst:67 +msgid "September 2018" +msgstr "" + +#: ../source/news.rst:68 +msgid "Added a section on checking RST markup. (:pr:`554`)" +msgstr "" + +#: ../source/news.rst:69 +msgid "Updated user installs page. (:pr:`558`)" +msgstr "" + +#: ../source/news.rst:70 +msgid "Updated Google BigQuery urls. (:pr:`556`)" +msgstr "" + +#: ../source/news.rst:71 +msgid "Replaced tar command with working command. (:pr:`552`)" +msgstr "" + +#: ../source/news.rst:72 +msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" +msgstr "" + +#: ../source/news.rst:75 +msgid "August 2018" +msgstr "" + +#: ../source/news.rst:76 +msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" +msgstr "" + +#: ../source/news.rst:77 +msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" +msgstr "" + +#: ../source/news.rst:78 +msgid "Updated Python version supported by virtualenv. (:pr:`538`)" +msgstr "" + +#: ../source/news.rst:79 +msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" +msgstr "" + +#: ../source/news.rst:82 +msgid "July 2018" +msgstr "" + +#: ../source/news.rst:84 +msgid "Improved binary extension docs. (:pr:`531`)" +msgstr "" + +#: ../source/news.rst:85 +msgid "Added scikit-build to key projects. (:pr:`530`)" +msgstr "" + +#: ../source/news.rst:88 +msgid "June 2018" +msgstr "" + +#: ../source/news.rst:90 +msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" +msgstr "" + +#: ../source/news.rst:91 +msgid "Updated Markdown descriptions explanation. (:pr:`522`)" +msgstr "" + +#: ../source/news.rst:94 +msgid "May 2018" +msgstr "" + +#: ../source/news.rst:96 +msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" +msgstr "" + +#: ../source/news.rst:97 +msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" +msgstr "" + +#: ../source/news.rst:98 +msgid "Simplified packaging tutorial. (:pr:`498`)" +msgstr "" + +#: ../source/news.rst:99 +msgid "Updated Windows users instructions for clarity. (:pr:`493`)" +msgstr "" + +#: ../source/news.rst:100 +msgid "Updated the license section description for completeness. (:pr:`492`)" +msgstr "" + +#: ../source/news.rst:101 +msgid "Added specification-style document to contributing section. (:pr:`489`)" +msgstr "" + +#: ../source/news.rst:102 +msgid "Added documentation types to contributing guide. (:pr:`485`)" +msgstr "" + +#: ../source/news.rst:105 +msgid "April 2018" +msgstr "" + +#: ../source/news.rst:107 +msgid "Added README guide. (:pr:`461`)" +msgstr "" + +#: ../source/news.rst:108 +msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" +msgstr "" + +#: ../source/news.rst:109 +msgid "Added instructions for Warehouse. (:pr:`471`)" +msgstr "" + +#: ../source/news.rst:110 +msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" +msgstr "" + +#: ../source/news.rst:111 +msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" +msgstr "" + +#: ../source/news.rst:112 +msgid "Added a guide for phasing out Python versions. (:pr:`459`)" +msgstr "" + +#: ../source/news.rst:113 +msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" +msgstr "" + +#: ../source/news.rst:116 +msgid "March 2018" +msgstr "" + +#: ../source/news.rst:118 +msgid "Updated \"installing scientific packages\". (:pr:`455`)" +msgstr "" + +#: ../source/news.rst:119 +msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" +msgstr "" + +#: ../source/news.rst:120 +msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" +msgstr "" + +#: ../source/news.rst:121 +msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" +msgstr "" + +#: ../source/news.rst:124 +msgid "February 2018" +msgstr "" + +#: ../source/news.rst:126 +msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" +msgstr "" + +#: ../source/news.rst:127 +msgid "Updated PyPI migration info. (:pr:`439`)" +msgstr "" + +#: ../source/news.rst:128 +msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" +msgstr "" + +#: ../source/news.rst:129 +msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" +msgstr "" + +#: ../source/news.rst:130 +msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" +msgstr "" + +#: ../source/news.rst:133 +msgid "January 2018" +msgstr "" + +#: ../source/news.rst:135 +msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" +msgstr "" + +#: ../source/news.rst:136 +msgid "Updated README.rst explanation. (:pr:`419`)" +msgstr "" + +#: ../source/news.rst:139 +msgid "December 2017" +msgstr "" + +#: ../source/news.rst:141 +msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" +msgstr "" + +#: ../source/news.rst:142 +msgid "Noted which fields can be used with environment markers. (:pr:`416`)" +msgstr "" + +#: ../source/news.rst:143 +msgid "Updated Requires-Python section. (:pr:`414`)" +msgstr "" + +#: ../source/news.rst:144 +msgid "Added news page. (:pr:`404`)" +msgstr "" + +#: ../source/news.rst:147 +msgid "November 2017" +msgstr "" + +#: ../source/news.rst:149 +msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" +msgstr "" + +#: ../source/news.rst:150 +msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" +msgstr "" + +#: ../source/news.rst:152 +msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:153 +msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" +msgstr "" + +#: ../source/news.rst:156 +msgid "October 2017" +msgstr "" + +#: ../source/news.rst:158 +msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:159 +msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" +msgstr "" + +#: ../source/news.rst:160 +msgid "Split the specifications page into multiple pages. (:pr:`386`)" +msgstr "" + +#: ../source/news.rst:163 +msgid "September 2017" +msgstr "" + +#: ../source/news.rst:165 +msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" +msgstr "" + +#: ../source/news.rst:167 +msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" +msgstr "" + +#: ../source/news.rst:170 +msgid "August 2017" +msgstr "" + +#: ../source/news.rst:172 +msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" +msgstr "" + +#: ../source/news.rst:173 +msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" +msgstr "" + +#: ../source/news.rst:174 +msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" +msgstr "" + +#: ../source/news.rst:177 +msgid "July 2017" +msgstr "" + +#: ../source/news.rst:179 +msgid "Added ``flit`` to the key projects list. (:pr:`358`)" +msgstr "" + +#: ../source/news.rst:180 +msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" +msgstr "" + +#: ../source/news.rst:181 +msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" +msgstr "" + +#: ../source/news.rst:182 +msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" +msgstr "" + +#: ../source/news.rst:183 +msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" +msgstr "" + +#: ../source/news.rst:186 +msgid "June 2017" +msgstr "" + +#: ../source/news.rst:188 +msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" +msgstr "" + +#: ../source/news.rst:189 +msgid "Added documentation for ``python_requires``. (:pr:`338`)" +msgstr "" + +#: ../source/news.rst:190 +msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" +msgstr "" + +#: ../source/news.rst:191 +msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" +msgstr "" + +#: ../source/news.rst:192 +msgid "Added a license section to the distributing guide. (:pr:`331`)" +msgstr "" + +#: ../source/news.rst:193 +msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" +msgstr "" + +#: ../source/news.rst:194 +msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" +msgstr "" + +#: ../source/news.rst:195 +msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" +msgstr "" + +#: ../source/news.rst:196 +msgid "Switched to the PyPA theme. (:pr:`305`)" +msgstr "" + +#: ../source/news.rst:197 +msgid "Re-organized the documentation into the new structure. (:pr:`318`)" +msgstr "" + +#: ../source/news.rst:200 +msgid "May 2017" +msgstr "" + +#: ../source/news.rst:202 +msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" +msgstr "" + +#: ../source/news.rst:203 +msgid "Added contributor and style guide. (:pr:`307`)" +msgstr "" + +#: ../source/news.rst:204 +msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" +msgstr "" + +#: ../source/news.rst:207 +msgid "April 2017" +msgstr "" + +#: ../source/news.rst:209 +msgid "Added travis configuration for testing pull requests. (:pr:`300`)" +msgstr "" + +#: ../source/news.rst:210 +msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" +msgstr "" + +#: ../source/news.rst:211 +msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" +msgstr "" + +#: ../source/news.rst:212 +msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" +msgstr "" + +#: ../source/news.rst:213 +msgid "Added a topic on namespace packages. (:pr:`290`)" +msgstr "" + +#: ../source/news.rst:214 +msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" +msgstr "" + +#: ../source/news.rst:215 +msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" +msgstr "" + +#: ../source/news.rst:216 +msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" +msgstr "" + +#: ../source/news.rst:217 +msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" +msgstr "" + +#: ../source/news.rst:219 +msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" +msgstr "" + +#: ../source/news.rst:223 +msgid "March 2017" +msgstr "" + +#: ../source/news.rst:225 +msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" +msgstr "" + +#: ../source/news.rst:228 +msgid "February 2017" +msgstr "" + +#: ../source/news.rst:230 +msgid "Added :pep:`518`. (:pr:`281`)" +msgstr "" + +#: ../source/overview.rst:3 +msgid "An Overview of Packaging for Python" +msgstr "" + +#: ../source/overview.rst:7 +msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." +msgstr "" + +#: ../source/overview.rst:12 +msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." +msgstr "" + +#: ../source/overview.rst:18 +msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." +msgstr "" + +#: ../source/overview.rst:26 +msgid "Thinking about deployment" +msgstr "" + +#: ../source/overview.rst:28 +msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" +msgstr "" + +#: ../source/overview.rst:32 +msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" +msgstr "" + +#: ../source/overview.rst:35 +msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" +msgstr "" + +#: ../source/overview.rst:37 +msgid "Is your software installed individually, or in large deployment batches?" +msgstr "" + +#: ../source/overview.rst:39 +msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." +msgstr "" + +#: ../source/overview.rst:46 +msgid "Packaging Python libraries and tools" +msgstr "" + +#: ../source/overview.rst:48 +msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/overview.rst:53 +msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." +msgstr "" + +#: ../source/overview.rst:59 +msgid "Python modules" +msgstr "" + +#: ../source/overview.rst:61 +msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." +msgstr "" + +#: ../source/overview.rst:66 +msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." +msgstr "" + +#: ../source/overview.rst:73 +msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." +msgstr "" + +#: ../source/overview.rst:78 +msgid "Python source distributions" +msgstr "" + +#: ../source/overview.rst:80 +msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." +msgstr "" + +#: ../source/overview.rst:84 +msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." +msgstr "" + +#: ../source/overview.rst:90 +msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." +msgstr "" + +#: ../source/overview.rst:95 +msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." +msgstr "" + +#: ../source/overview.rst:100 +msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." +msgstr "" + +#: ../source/overview.rst:107 +msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" +msgstr "" + +#: ../source/overview.rst:114 +msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." +msgstr "" + +#: ../source/overview.rst:119 +msgid "Python binary distributions" +msgstr "" + +#: ../source/overview.rst:121 +msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." +msgstr "" + +#: ../source/overview.rst:125 +msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." +msgstr "" + +#: ../source/overview.rst:132 +msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." +msgstr "" + +#: ../source/overview.rst:140 +msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." +msgstr "" + +#: ../source/overview.rst:148 +msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." +msgstr "" + +#: ../source/overview.rst:155 +msgid "Packaging Python applications" +msgstr "" + +#: ../source/overview.rst:157 +msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." +msgstr "" + +#: ../source/overview.rst:162 +msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." +msgstr "" + +#: ../source/overview.rst:166 +msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." +msgstr "" + +#: ../source/overview.rst:172 +msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." +msgstr "" + +#: ../source/overview.rst:176 +msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." +msgstr "" + +#: ../source/overview.rst:181 +msgid "Depending on a framework" +msgstr "" + +#: ../source/overview.rst:183 +msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." +msgstr "" + +#: ../source/overview.rst:189 +msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." +msgstr "" + +#: ../source/overview.rst:195 +msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." +msgstr "" + +#: ../source/overview.rst:199 +msgid "Service platforms" +msgstr "" + +#: ../source/overview.rst:201 +msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." +msgstr "" + +#: ../source/overview.rst:205 +msgid "`Heroku `_" +msgstr "" + +#: ../source/overview.rst:206 +msgid "`Google App Engine `_" +msgstr "" + +#: ../source/overview.rst:207 +msgid "`PythonAnywhere `_" +msgstr "" + +#: ../source/overview.rst:208 +msgid "`OpenShift `_" +msgstr "" + +#: ../source/overview.rst:209 +msgid "\"Serverless\" frameworks like `Zappa `_" +msgstr "" + +#: ../source/overview.rst:211 +msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." +msgstr "" + +#: ../source/overview.rst:216 +msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." +msgstr "" + +#: ../source/overview.rst:220 +msgid "Web browsers and mobile applications" +msgstr "" + +#: ../source/overview.rst:222 +msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." +msgstr "" + +#: ../source/overview.rst:227 +msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" +msgstr "" + +#: ../source/overview.rst:231 +msgid "`Kivy `_" +msgstr "" + +#: ../source/overview.rst:232 +msgid "`Beeware `_" +msgstr "" + +#: ../source/overview.rst:233 +msgid "`Brython `_" +msgstr "" + +#: ../source/overview.rst:234 +msgid "`Flexx `_" +msgstr "" + +#: ../source/overview.rst:236 +msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." +msgstr "" + +#: ../source/overview.rst:241 +msgid "Depending on a pre-installed Python" +msgstr "" + +#: ../source/overview.rst:243 +msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." +msgstr "" + +#: ../source/overview.rst:249 +msgid "Technologies which support this model:" +msgstr "" + +#: ../source/overview.rst:251 +msgid "`PEX `_ (Python EXecutable)" +msgstr "" + +#: ../source/overview.rst:252 +msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" +msgstr "" + +#: ../source/overview.rst:253 +msgid "`shiv `_ (requires Python 3)" +msgstr "" + +#: ../source/overview.rst:255 +msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." +msgstr "" + +#: ../source/overview.rst:260 +msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." +msgstr "" + +#: ../source/overview.rst:267 +msgid "Depending on a separate software distribution ecosystem" +msgstr "" + +#: ../source/overview.rst:269 +msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." +msgstr "" + +#: ../source/overview.rst:274 +msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." +msgstr "" + +#: ../source/overview.rst:284 +msgid "Instructions on building and publishing for the Anaconda ecosystem:" +msgstr "" + +#: ../source/overview.rst:286 +msgid "`Building libraries and applications with conda `_" +msgstr "" + +#: ../source/overview.rst:287 +msgid "`Transitioning a native Python package to Anaconda `_" +msgstr "" + +#: ../source/overview.rst:289 +msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" +msgstr "" + +#: ../source/overview.rst:293 +msgid "`Enthought Canopy `_" +msgstr "" + +#: ../source/overview.rst:294 +msgid "`ActiveState ActivePython `_" +msgstr "" + +#: ../source/overview.rst:295 +msgid "`WinPython `_" +msgstr "" + +#: ../source/overview.rst:300 +msgid "Bringing your own Python executable" +msgstr "" + +#: ../source/overview.rst:302 +msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." +msgstr "" + +#: ../source/overview.rst:306 +msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." +msgstr "" + +#: ../source/overview.rst:311 +msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." +msgstr "" + +#: ../source/overview.rst:315 +msgid "A selection of Python freezers:" +msgstr "" + +#: ../source/overview.rst:317 +msgid "`pyInstaller `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:318 +msgid "`cx_Freeze `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:319 +msgid "`constructor `_ - For command-line installers" +msgstr "" + +#: ../source/overview.rst:320 +msgid "`py2exe `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:321 +msgid "`py2app `_ - Mac only" +msgstr "" + +#: ../source/overview.rst:322 +msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" +msgstr "" + +#: ../source/overview.rst:323 +msgid "`osnap `_ - Windows and Mac" +msgstr "" + +#: ../source/overview.rst:324 +msgid "`pynsist `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:326 +msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." +msgstr "" + +#: ../source/overview.rst:332 +msgid "Bringing your own userspace" +msgstr "" + +#: ../source/overview.rst:334 +msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." +msgstr "" + +#: ../source/overview.rst:341 +msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." +msgstr "" + +#: ../source/overview.rst:344 +msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" +msgstr "" + +#: ../source/overview.rst:347 +msgid "`AppImage `_" +msgstr "" + +#: ../source/overview.rst:348 +msgid "`Docker `_" +msgstr "" + +#: ../source/overview.rst:349 +msgid "`Flatpak `_" +msgstr "" + +#: ../source/overview.rst:350 +msgid "`Snapcraft `_" +msgstr "" + +#: ../source/overview.rst:353 +msgid "Bringing your own kernel" +msgstr "" + +#: ../source/overview.rst:355 +msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." +msgstr "" + +#: ../source/overview.rst:360 +msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" +msgstr "" + +#: ../source/overview.rst:364 +msgid "`Vagrant `_" +msgstr "" + +#: ../source/overview.rst:365 +msgid "`VHD `_, `AMI `_, and `other formats `_" +msgstr "" + +#: ../source/overview.rst:366 +msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" +msgstr "" + +#: ../source/overview.rst:369 +msgid "Bringing your own hardware" +msgstr "" + +#: ../source/overview.rst:371 +msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." +msgstr "" + +#: ../source/overview.rst:375 +msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." +msgstr "" + +#: ../source/overview.rst:379 +msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." +msgstr "" + +#: ../source/overview.rst:389 +msgid "The simplified gamut of technologies used to package Python applications." +msgstr "" + +#: ../source/overview.rst:392 +msgid "What about..." +msgstr "" + +#: ../source/overview.rst:394 +msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." +msgstr "" + +#: ../source/overview.rst:398 +msgid "Operating system packages" +msgstr "" + +#: ../source/overview.rst:400 +msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." +msgstr "" + +#: ../source/overview.rst:411 +msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." +msgstr "" + +#: ../source/overview.rst:417 +msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." +msgstr "" + +#: ../source/overview.rst:427 +msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." +msgstr "" + +#: ../source/overview.rst:432 +msgid "Security" +msgstr "" + +#: ../source/overview.rst:434 +msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." +msgstr "" + +#: ../source/overview.rst:437 +msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." +msgstr "" + +#: ../source/overview.rst:446 +msgid "Wrap up" +msgstr "" + +#: ../source/overview.rst:448 +msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:6 +msgid "Binary distribution format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:8 +msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:13 +msgid "Abstract" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:15 +msgid "This PEP describes a built-package format for Python called \"wheel\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:17 +msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:27 +msgid "PEP Acceptance" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:29 +msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:34 +msgid "Rationale" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:36 +msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:43 +msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:52 +msgid "Details" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:55 +msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:57 +msgid "Wheel installation notionally consists of two phases:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:59 +msgid "Unpack." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:61 +msgid "Parse ``distribution-1.0.dist-info/WHEEL``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:62 +msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:64 +msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:66 +msgid "Else unpack archive into platlib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:68 +msgid "Spread." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:70 +msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:72 +msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:78 +msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:80 +msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:82 +msgid "Remove empty ``distribution-1.0.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:83 +msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:87 +msgid "Recommended installer features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:97 +msgid "Rewrite ``#!python``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:90 +msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:96 +msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:102 +msgid "Generate script wrappers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:100 +msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:105 +msgid "Recommended archiver features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:112 +msgid "Place ``.dist-info`` at the end of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:108 +msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:115 +msgid "File Format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:118 +msgid "File name convention" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:120 +msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "distribution" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "Distribution name, e.g. 'django', 'pyramid'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "Distribution version, e.g. 1.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:135 +msgid "build tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:130 +msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "language implementation and version tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "E.g. 'py27', 'py2', 'py3'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "abi tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "E.g. 'cp33m', 'abi3', 'none'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "platform tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "E.g. 'linux_x86_64', 'any'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:146 +msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:151 +msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:156 +msgid "Escaping and Unicode" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:158 +msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:161 +msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:164 +msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:166 +msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:169 +msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:172 +msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:176 +msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:182 +msgid "File contents" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:184 +msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:188 +msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:191 +msgid "``{distribution}-{version}.dist-info/`` contains metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:192 +msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:196 +msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:200 +msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:202 +msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:212 +msgid "``Wheel-Version`` is the version number of the Wheel specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:213 +msgid "``Generator`` is the name and optionally the version of the software that produced the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:215 +msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:218 +msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:220 +msgid "``Build`` is the build number and is omitted if there is no build number." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:221 +msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:224 +msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:226 +msgid "Wheel does not contain setup.py or setup.cfg." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:228 +msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:235 +#: ../source/specifications/recording-installed-packages.rst:35 +msgid "The .dist-info directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:237 +msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:239 +msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:241 +msgid "WHEEL is the wheel metadata specific to a build of the package." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:242 +msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:248 +msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:249 +msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:251 +msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:254 +msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:261 +msgid "The .data directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:263 +msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:271 +msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:277 +msgid "Signed wheel files" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:279 +msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:290 +msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:295 +msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:302 +msgid "(The hash value is the same format used in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:304 +msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:307 +msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:312 +msgid "See" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:314 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:315 +msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:316 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:317 +msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:321 +msgid "Comparison to .egg" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:323 +msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:328 +msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:331 +msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:337 +msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:341 +msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:344 +msgid "Wheel is a reference to the other Python." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:348 +msgid "FAQ" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:352 +msgid "Wheel defines a .data directory. Should I put all my data there?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:354 +msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:363 +msgid "Why does wheel include attached signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:365 +msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:373 +msgid "Why does wheel allow JWS signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:375 +msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:381 +msgid "Why does wheel also allow S/MIME signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:383 +msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:386 +msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:391 +msgid "What's the deal with \"purelib\" vs. \"platlib\"?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:393 +msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:398 +msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:403 +msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:409 +msgid "Is it possible to import Python code directly from a wheel file?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:411 +msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:417 +msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:426 +msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:443 +msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:450 +msgid "Changes" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:452 +msgid "Since :pep:`427`, this specification has changed as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:454 +msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:461 +msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:466 +msgid "Appendix" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:468 +msgid "Example urlsafe-base64-nopad implementation::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:482 +msgid "Copyright" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:484 +msgid "This document has been placed into the public domain." +msgstr "" + +#: ../source/specifications/core-metadata.rst:5 +msgid "Core metadata specifications" +msgstr "" + +#: ../source/specifications/core-metadata.rst:7 +msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:10 +msgid "``Metadata-Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:11 +msgid "``Name``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:12 +msgid "``Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:14 +msgid "All the other fields are optional." +msgstr "" + +#: ../source/specifications/core-metadata.rst:16 +msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." +msgstr "" + +#: ../source/specifications/core-metadata.rst:25 +msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:30 +msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." +msgstr "" + +#: ../source/specifications/core-metadata.rst:41 +msgid "Metadata-Version" +msgstr "" + +#: ../source/specifications/core-metadata.rst:45 +msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." +msgstr "" + +#: ../source/specifications/core-metadata.rst:48 +msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:54 +msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." +msgstr "" + +#: ../source/specifications/core-metadata.rst:58 +#: ../source/specifications/core-metadata.rst:80 +#: ../source/specifications/core-metadata.rst:95 +#: ../source/specifications/core-metadata.rst:155 +#: ../source/specifications/core-metadata.rst:170 +#: ../source/specifications/core-metadata.rst:208 +#: ../source/specifications/core-metadata.rst:283 +#: ../source/specifications/core-metadata.rst:287 +#: ../source/specifications/core-metadata.rst:291 +#: ../source/specifications/core-metadata.rst:295 +#: ../source/specifications/core-metadata.rst:327 +#: ../source/specifications/core-metadata.rst:347 +#: ../source/specifications/core-metadata.rst:373 +#: ../source/specifications/core-metadata.rst:391 +#: ../source/specifications/core-metadata.rst:416 +#: ../source/specifications/core-metadata.rst:438 +#: ../source/specifications/core-metadata.rst:600 +#: ../source/specifications/core-metadata.rst:620 +#: ../source/specifications/core-metadata.rst:630 +msgid "Example::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:66 +msgid "Name" +msgstr "" + +#: ../source/specifications/core-metadata.rst:69 +msgid "Added additional restrictions on format from :pep:`508`" +msgstr "" + +#: ../source/specifications/core-metadata.rst:72 +msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:88 +msgid "Version" +msgstr "" + +#: ../source/specifications/core-metadata.rst:92 +msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:101 +msgid "Dynamic (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:105 +msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." +msgstr "" + +#: ../source/specifications/core-metadata.rst:108 +msgid "When found in the metadata of a source distribution, the following rules apply:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:111 +msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." +msgstr "" + +#: ../source/specifications/core-metadata.rst:115 +msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:118 +msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:122 +msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." +msgstr "" + +#: ../source/specifications/core-metadata.rst:127 +msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:131 +msgid "Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:135 +msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." +msgstr "" + +#: ../source/specifications/core-metadata.rst:146 +msgid "Supported-Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:150 +msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." +msgstr "" + +#: ../source/specifications/core-metadata.rst:164 +msgid "Summary" +msgstr "" + +#: ../source/specifications/core-metadata.rst:168 +msgid "A one-line summary of what the distribution does." +msgstr "" + +#: ../source/specifications/core-metadata.rst:188 +msgid "This field may be specified in the message body instead." +msgstr "" + +#: ../source/specifications/core-metadata.rst:191 +msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:196 +msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." +msgstr "" + +#: ../source/specifications/core-metadata.rst:202 +msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:219 +msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." +msgstr "" + +#: ../source/specifications/core-metadata.rst:223 +msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:232 +msgid "Description-Content-Type" +msgstr "" + +#: ../source/specifications/core-metadata.rst:236 +msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:239 +msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." +msgstr "" + +#: ../source/specifications/core-metadata.rst:253 +msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:259 +msgid "Format::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:263 +msgid "The ``type/subtype`` part has only a few legal values:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:265 +msgid "``text/plain``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:266 +msgid "``text/x-rst``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:267 +msgid "``text/markdown``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:269 +msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:273 +msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:278 +msgid "``GFM`` for `Github-flavored Markdown `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:280 +msgid "``CommonMark`` for `CommonMark `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:299 +msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." +msgstr "" + +#: ../source/specifications/core-metadata.rst:303 +msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:307 +msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:311 +msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." +msgstr "" + +#: ../source/specifications/core-metadata.rst:320 +msgid "Keywords" +msgstr "" + +#: ../source/specifications/core-metadata.rst:324 +msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." +msgstr "" + +#: ../source/specifications/core-metadata.rst:333 +msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." +msgstr "" + +#: ../source/specifications/core-metadata.rst:341 +msgid "Home-page" +msgstr "" + +#: ../source/specifications/core-metadata.rst:345 +msgid "A string containing the URL for the distribution's home page." +msgstr "" + +#: ../source/specifications/core-metadata.rst:353 +msgid "Download-URL" +msgstr "" + +#: ../source/specifications/core-metadata.rst:357 +msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:366 +msgid "Author" +msgstr "" + +#: ../source/specifications/core-metadata.rst:370 +msgid "A string containing the author's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:383 +msgid "Author-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:387 +msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:395 +#: ../source/specifications/core-metadata.rst:442 +msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:405 +msgid "Maintainer" +msgstr "" + +#: ../source/specifications/core-metadata.rst:409 +msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:412 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:426 +msgid "Maintainer-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:430 +msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:434 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:452 +msgid "License" +msgstr "" + +#: ../source/specifications/core-metadata.rst:456 +msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." +msgstr "" + +#: ../source/specifications/core-metadata.rst:476 +msgid "Classifier (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:480 +msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:485 +#: ../source/specifications/core-metadata.rst:574 +#: ../source/specifications/core-metadata.rst:691 +#: ../source/specifications/core-metadata.rst:715 +msgid "This field may be followed by an environment marker after a semicolon." +msgstr "" + +#: ../source/specifications/core-metadata.rst:496 +msgid "Requires-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:499 +#: ../source/specifications/core-metadata.rst:561 +#: ../source/specifications/core-metadata.rst:663 +#: ../source/specifications/core-metadata.rst:704 +msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." +msgstr "" + +#: ../source/specifications/core-metadata.rst:503 +msgid "Each entry contains a string naming some other distutils project required by this distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:506 +msgid "The format of a requirement string contains from one to four parts:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:508 +msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." +msgstr "" + +#: ../source/specifications/core-metadata.rst:510 +msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." +msgstr "" + +#: ../source/specifications/core-metadata.rst:513 +msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:516 +msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." +msgstr "" + +#: ../source/specifications/core-metadata.rst:519 +msgid "See :pep:`508` for full details of the allowed format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:521 +msgid "The project names should correspond to names as found on the `Python Package Index`_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:524 +msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:538 +msgid "Requires-Python" +msgstr "" + +#: ../source/specifications/core-metadata.rst:542 +msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." +msgstr "" + +#: ../source/specifications/core-metadata.rst:546 +msgid "The value must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:548 +msgid "This field cannot be followed by an environment marker." +msgstr "" + +#: ../source/specifications/core-metadata.rst:558 +msgid "Requires-External (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:565 +msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:570 +msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:576 +msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." +msgstr "" + +#: ../source/specifications/core-metadata.rst:581 +msgid "Notice that there is no particular rule on the strings to be used." +msgstr "" + +#: ../source/specifications/core-metadata.rst:593 +msgid "Project-URL (multiple-use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:597 +msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." +msgstr "" + +#: ../source/specifications/core-metadata.rst:604 +msgid "The label is free text limited to 32 characters." +msgstr "" + +#: ../source/specifications/core-metadata.rst:612 +msgid "Provides-Extra (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:616 +msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." +msgstr "" + +#: ../source/specifications/core-metadata.rst:625 +msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:635 +msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." +msgstr "" + +#: ../source/specifications/core-metadata.rst:639 +msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:644 +msgid "Rarely Used Fields" +msgstr "" + +#: ../source/specifications/core-metadata.rst:646 +msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:651 +msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." +msgstr "" + +#: ../source/specifications/core-metadata.rst:660 +msgid "Provides-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:667 +msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:672 +msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:679 +msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:687 +msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." +msgstr "" + +#: ../source/specifications/core-metadata.rst:701 +msgid "Obsoletes-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:708 +msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." +msgstr "" + +#: ../source/specifications/core-metadata.rst:712 +msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:717 +msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:730 +msgid "reStructuredText markup: http://docutils.sourceforge.net/" +msgstr "" + +#: ../source/specifications/core-metadata.rst:735 +msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:6 +msgid "Declaring build system dependencies" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:8 +msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:5 +msgid "Declaring project metadata" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:7 +msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:12 +msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:18 +msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:27 +msgid "The only fields required to be statically defined are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:29 +#: ../source/specifications/declaring-project-metadata.rst:41 +msgid "``name``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:31 +msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:34 +#: ../source/specifications/declaring-project-metadata.rst:54 +msgid "``version``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:36 +msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:43 +#: ../source/specifications/declaring-project-metadata.rst:56 +#: ../source/specifications/declaring-project-metadata.rst:68 +#: ../source/specifications/declaring-project-metadata.rst:117 +msgid "TOML_ type: string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:44 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:47 +msgid "The name of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:49 +msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:57 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:60 +msgid "The version of the project as supported by :pep:`440`." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:62 +msgid "Users SHOULD prefer to specify already-normalized versions." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:66 +msgid "``description``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:69 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:72 +msgid "The summary description of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:76 +msgid "``readme``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:78 +msgid "TOML_ type: string or table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:79 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:83 +msgid "The full description of the project (i.e. the README)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:85 +msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:96 +msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:103 +msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:115 +msgid "``requires-python``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:118 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:121 +msgid "The Python version requirements of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:125 +msgid "``license``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:127 +msgid "TOML_ type: table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:128 +msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:131 +msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:140 +msgid "``authors``/``maintainers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:142 +msgid "TOML_ type: Array of inline tables with string keys and values" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:143 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:149 +msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:154 +msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:157 +msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:163 +msgid "Using the data to fill in :ref:`core metadata ` is as follows:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:166 +msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:169 +msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:173 +msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:177 +msgid "Multiple values should be separated by commas." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:181 +msgid "``keywords``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:183 +#: ../source/specifications/declaring-project-metadata.rst:193 +msgid "TOML_ type: array of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:184 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:187 +msgid "The keywords for the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:191 +msgid "``classifiers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:194 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:197 +msgid "Trove classifiers which apply to the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:201 +msgid "``urls``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:203 +msgid "TOML_ type: table with keys and values of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:204 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:207 +msgid "A table of URLs where the key is the URL label and the value is the URL itself." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:212 +msgid "Entry points" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:214 +msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:216 +msgid ":ref:`Entry points specification `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:218 +msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:224 +msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:228 +msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:234 +msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:242 +msgid "``dependencies``/``optional-dependencies``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:244 +msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:247 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:251 +msgid "The (optional) dependencies of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:253 +msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:258 +msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:269 +msgid "``dynamic``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:271 +msgid "TOML_ type: array of string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:272 +msgid "A corresponding :ref:`core metadata ` field does not exist" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:275 +msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:281 +msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:283 +msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:285 +msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:290 +msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:294 +msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:296 +msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:300 +msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:6 +msgid "Dependency specifiers" +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:8 +msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:11 +msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." +msgstr "" + +#: ../source/specifications/direct-url.rst:6 +msgid "Recording the Direct URL Origin of installed distributions" +msgstr "" + +#: ../source/specifications/direct-url.rst:8 +msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." +msgstr "" + +#: ../source/specifications/direct-url.rst:17 +msgid "Specification" +msgstr "" + +#: ../source/specifications/direct-url.rst:19 +msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/direct-url.rst:23 +#: ../source/specifications/recording-installed-packages.rst:206 +msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." +msgstr "" + +#: ../source/specifications/direct-url.rst:26 +msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." +msgstr "" + +#: ../source/specifications/direct-url.rst:29 +msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." +msgstr "" + +#: ../source/specifications/direct-url.rst:36 +msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." +msgstr "" + +#: ../source/specifications/direct-url.rst:39 +msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" +msgstr "" + +#: ../source/specifications/direct-url.rst:45 +msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." +msgstr "" + +#: ../source/specifications/direct-url.rst:49 +msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" +msgstr "" + +#: ../source/specifications/direct-url.rst:52 +msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." +msgstr "" + +#: ../source/specifications/direct-url.rst:58 +msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." +msgstr "" + +#: ../source/specifications/direct-url.rst:61 +msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." +msgstr "" + +#: ../source/specifications/direct-url.rst:68 +msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:71 +msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." +msgstr "" + +#: ../source/specifications/direct-url.rst:78 +msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:81 +msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." +msgstr "" + +#: ../source/specifications/direct-url.rst:84 +msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." +msgstr "" + +#: ../source/specifications/direct-url.rst:91 +msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." +msgstr "" + +#: ../source/specifications/direct-url.rst:96 +msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." +msgstr "" + +#: ../source/specifications/direct-url.rst:102 +msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." +msgstr "" + +#: ../source/specifications/direct-url.rst:110 +msgid "Registered VCS" +msgstr "" + +#: ../source/specifications/direct-url.rst:112 +msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." +msgstr "" + +#: ../source/specifications/direct-url.rst:122 +msgid "Git" +msgstr "" + +#: ../source/specifications/direct-url.rst:124 +#: ../source/specifications/direct-url.rst:156 +#: ../source/specifications/direct-url.rst:179 +#: ../source/specifications/direct-url.rst:202 +msgid "Home page" +msgstr "" + +#: ../source/specifications/direct-url.rst:126 +msgid "https://git-scm.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:128 +#: ../source/specifications/direct-url.rst:160 +#: ../source/specifications/direct-url.rst:183 +#: ../source/specifications/direct-url.rst:206 +msgid "vcs command" +msgstr "" + +#: ../source/specifications/direct-url.rst:130 +#: ../source/specifications/direct-url.rst:134 +msgid "git" +msgstr "" + +#: ../source/specifications/direct-url.rst:132 +#: ../source/specifications/direct-url.rst:164 +#: ../source/specifications/direct-url.rst:187 +#: ../source/specifications/direct-url.rst:210 +msgid "``vcs`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:136 +#: ../source/specifications/direct-url.rst:168 +#: ../source/specifications/direct-url.rst:191 +#: ../source/specifications/direct-url.rst:214 +msgid "``requested_revision`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:138 +msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." +msgstr "" + +#: ../source/specifications/direct-url.rst:141 +#: ../source/specifications/direct-url.rst:172 +#: ../source/specifications/direct-url.rst:195 +#: ../source/specifications/direct-url.rst:219 +msgid "``commit_id`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:143 +msgid "A commit hash (40 hexadecimal characters sha1)." +msgstr "" + +#: ../source/specifications/direct-url.rst:147 +msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." +msgstr "" + +#: ../source/specifications/direct-url.rst:154 +msgid "Mercurial" +msgstr "" + +#: ../source/specifications/direct-url.rst:158 +msgid "https://www.mercurial-scm.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:162 +#: ../source/specifications/direct-url.rst:166 +msgid "hg" +msgstr "" + +#: ../source/specifications/direct-url.rst:170 +msgid "A tag name, branch name, changeset ID, shortened changeset ID." +msgstr "" + +#: ../source/specifications/direct-url.rst:174 +msgid "A changeset ID (40 hexadecimal characters)." +msgstr "" + +#: ../source/specifications/direct-url.rst:177 +msgid "Bazaar" +msgstr "" + +#: ../source/specifications/direct-url.rst:181 +msgid "https://bazaar.canonical.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:185 +#: ../source/specifications/direct-url.rst:189 +msgid "bzr" +msgstr "" + +#: ../source/specifications/direct-url.rst:193 +msgid "A tag name, branch name, revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:197 +msgid "A revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:200 +msgid "Subversion" +msgstr "" + +#: ../source/specifications/direct-url.rst:204 +msgid "https://subversion.apache.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:208 +#: ../source/specifications/direct-url.rst:212 +msgid "svn" +msgstr "" + +#: ../source/specifications/direct-url.rst:216 +msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." +msgstr "" + +#: ../source/specifications/direct-url.rst:221 +msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." +msgstr "" + +#: ../source/specifications/direct-url.rst:229 +msgid "Example direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:231 +msgid "Source archive:" +msgstr "" + +#: ../source/specifications/direct-url.rst:242 +msgid "Git URL with tag and commit-hash:" +msgstr "" + +#: ../source/specifications/direct-url.rst:255 +msgid "Local directory:" +msgstr "" + +#: ../source/specifications/direct-url.rst:264 +msgid "Local directory installed in editable mode:" +msgstr "" + +#: ../source/specifications/direct-url.rst:277 +msgid "Example pip commands and their effect on direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:279 +msgid "Commands that generate a ``direct_url.json``:" +msgstr "" + +#: ../source/specifications/direct-url.rst:281 +msgid "pip install https://example.com/app-1.0.tgz" +msgstr "" + +#: ../source/specifications/direct-url.rst:282 +msgid "pip install https://example.com/app-1.0.whl" +msgstr "" + +#: ../source/specifications/direct-url.rst:283 +msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" +msgstr "" + +#: ../source/specifications/direct-url.rst:284 +msgid "pip install ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:285 +msgid "pip install file:///home/user/app" +msgstr "" + +#: ../source/specifications/direct-url.rst:286 +msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" +msgstr "" + +#: ../source/specifications/direct-url.rst:290 +msgid "pip install -e ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:292 +msgid "Commands that *do not* generate a ``direct_url.json``" +msgstr "" + +#: ../source/specifications/direct-url.rst:294 +msgid "pip install app" +msgstr "" + +#: ../source/specifications/direct-url.rst:295 +msgid "pip install app --no-index --find-links https://example.com/" +msgstr "" + +#: ../source/specifications/entry-points.rst:5 +msgid "Entry points specification" +msgstr "" + +#: ../source/specifications/entry-points.rst:7 +msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" +msgstr "" + +#: ../source/specifications/entry-points.rst:11 +msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." +msgstr "" + +#: ../source/specifications/entry-points.rst:14 +msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." +msgstr "" + +#: ../source/specifications/entry-points.rst:19 +msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." +msgstr "" + +#: ../source/specifications/entry-points.rst:28 +msgid "Data model" +msgstr "" + +#: ../source/specifications/entry-points.rst:30 +msgid "Conceptually, an entry point is defined by three required properties:" +msgstr "" + +#: ../source/specifications/entry-points.rst:32 +msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:42 +msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:51 +msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:64 +msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." +msgstr "" + +#: ../source/specifications/entry-points.rst:68 +msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." +msgstr "" + +#: ../source/specifications/entry-points.rst:73 +msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." +msgstr "" + +#: ../source/specifications/entry-points.rst:80 +msgid "File format" +msgstr "" + +#: ../source/specifications/entry-points.rst:82 +msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." +msgstr "" + +#: ../source/specifications/entry-points.rst:87 +msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:97 +msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:100 +msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." +msgstr "" + +#: ../source/specifications/entry-points.rst:104 +msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." +msgstr "" + +#: ../source/specifications/entry-points.rst:112 +msgid "For example::" +msgstr "" + +#: ../source/specifications/entry-points.rst:124 +msgid "Use for scripts" +msgstr "" + +#: ../source/specifications/entry-points.rst:126 +msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." +msgstr "" + +#: ../source/specifications/entry-points.rst:134 +msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:141 +msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." +msgstr "" + +#: ../source/specifications/entry-points.rst:149 +msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." +msgstr "" + +#: ../source/specifications/entry-points.rst:154 +msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." +msgstr "" + +#: ../source/specifications/index.rst:4 +msgid "PyPA specifications" +msgstr "" + +#: ../source/specifications/index.rst:6 +msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." +msgstr "" + +#: ../source/specifications/index.rst:13 +msgid "Package Distribution Metadata" +msgstr "" + +#: ../source/specifications/index.rst:30 +msgid "Package Distribution File Formats" +msgstr "" + +#: ../source/specifications/index.rst:40 +msgid "Package Index Interfaces" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:6 +msgid "Platform compatibility tags" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:8 +msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:12 +msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:16 +msgid "Platform tags for Windows" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:18 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:22 +msgid "Platform tags for macOS (Mac OS X)" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:24 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:28 +msgid "Platform tags for common Linux distributions" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:32 +msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:36 +msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:41 +msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:44 +msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:46 +msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:49 +msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:54 +msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:59 +msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:65 +msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:71 +msgid "Manylinux compatibility support" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:74 +msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:76 +msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:79 +msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "Tool" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux1``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2010``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2014``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux_x_y``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=8.1.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=20.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "auditwheel" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=1.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=2.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.3.0`` [#]_" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:90 +msgid "Platform tags for other \\*nix platforms" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:92 +msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:98 +msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" +msgstr "" + +#: ../source/specifications/pypirc.rst:6 +msgid "The :file:`.pypirc` file" +msgstr "" + +#: ../source/specifications/pypirc.rst:8 +msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." +msgstr "" + +#: ../source/specifications/pypirc.rst:13 +msgid "The format (originally defined by the :ref:`distutils` package) is:" +msgstr "" + +#: ../source/specifications/pypirc.rst:32 +msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:35 +msgid "Each section describing a repository defines three fields:" +msgstr "" + +#: ../source/specifications/pypirc.rst:37 +msgid "``repository``: The URL of the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:38 +msgid "``username``: The registered username on the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:39 +msgid "``password``: The password that will used to authenticate the username." +msgstr "" + +#: ../source/specifications/pypirc.rst:43 +msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." +msgstr "" + +#: ../source/specifications/pypirc.rst:47 +msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" +msgstr "" + +#: ../source/specifications/pypirc.rst:57 +msgid "Common configurations" +msgstr "" + +#: ../source/specifications/pypirc.rst:61 +msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." +msgstr "" + +#: ../source/specifications/pypirc.rst:66 +msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" +msgstr "" + +#: ../source/specifications/pypirc.rst:82 +msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." +msgstr "" + +#: ../source/specifications/pypirc.rst:86 +msgid "Using a PyPI token" +msgstr "" + +#: ../source/specifications/pypirc.rst:88 +msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" +msgstr "" + +#: ../source/specifications/pypirc.rst:97 +msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." +msgstr "" + +#: ../source/specifications/pypirc.rst:103 +msgid "Using another package index" +msgstr "" + +#: ../source/specifications/pypirc.rst:105 +msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" +msgstr "" + +#: ../source/specifications/pypirc.rst:132 +msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:5 +msgid "Recording installed projects" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:7 +msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:12 +msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:21 +msgid "History and change workflow" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:23 +msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:29 +msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:37 +msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:41 +msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:50 +msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:60 +msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:69 +msgid "This ``.dist-info`` directory can contain these files, described in detail below:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:72 +msgid "``METADATA``: contains project metadata" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:73 +msgid "``RECORD``: records the list of installed files." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:74 +msgid "``INSTALLER``: records the name of the tool used to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:76 +msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:82 +msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:87 +msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:94 +msgid "The METADATA file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:96 +msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:99 +msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:105 +msgid "The RECORD file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:107 +msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:110 +msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:113 +msgid "field delimiter: ``,`` (comma)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:114 +msgid "quoting char: ``\"`` (straight double quote)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:115 +msgid "line terminator: either ``\\r\\n`` or ``\\n``." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:117 +msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:120 +msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:125 +msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:130 +msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:133 +msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:139 +msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:146 +msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:151 +msgid "Here is an example snippet of a possible ``RECORD`` file::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:170 +msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:177 +msgid "The INSTALLER file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:179 +msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:185 +msgid "The file can be terminated by zero or more ASCII whitespace characters." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:187 +msgid "Here are examples of two possible ``INSTALLER`` files::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:195 +msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:201 +msgid "The direct_url.json file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:203 +msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:209 +msgid "Its detailed specification is at :ref:`direct-url`." +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:6 +msgid "Simple repository API" +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:8 +msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:6 +msgid "Source distribution format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:8 +msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:13 +msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:21 +msgid "Source distributions are also known as *sdists* for short." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:24 +msgid "Source distribution file name" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:26 +msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:31 +msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:35 +msgid "Source distribution file format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:37 +msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:45 +msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:48 +msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:6 +msgid "Version specifiers" +msgstr "" + +#: ../source/specifications/version-specifiers.rst:8 +msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:11 +msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." +msgstr "" + +#: ../source/support.rst:3 +msgid "How to Get Support" +msgstr "" + +#: ../source/support.rst:5 +msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." +msgstr "" + +#: ../source/support.rst:8 +msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:5 +msgid "Creating Documentation" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:7 +msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:13 +msgid "Installing Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:14 +msgid "Use ``pip`` to install Sphinx:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:28 +msgid "For other installation methods, see this `installation guide`_ by Sphinx." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:33 +msgid "Getting Started With Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:35 +msgid "Create a ``docs`` directory inside your project to hold your documentation:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:42 +msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:49 +msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:51 +msgid "You can add some information about your project in ``index.rst``, then build them:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:57 +msgid "For more details on the build process, see this `guide`_ by Read The Docs." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:62 +msgid "Other Sources" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:64 +msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/index.rst:4 +msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:5 +msgid "Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:7 +msgid "This section covers the basics of how to install Python :term:`packages `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:10 +msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:28 +msgid "Requirements for Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:30 +msgid "This section describes the steps to follow before installing other Python packages." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:35 +msgid "Ensure you can run Python from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:37 +msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:53 +msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:57 +msgid "If you're a newcomer and you get an error like this:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:66 +msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:72 +msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:82 +msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:87 +msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:99 +msgid "Ensure you can run pip from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:101 +msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:116 +msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:124 +msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:139 +msgid "If that still doesn't allow you to run ``python -m pip``:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:141 +msgid "Securely Download `get-pip.py `_ [1]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:144 +msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:150 +msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:159 +msgid "Ensure pip, setuptools, and wheel are up to date" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:161 +msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:169 +msgid "Optionally, create a virtual environment" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:171 +msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:188 +msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:195 +msgid "Creating Virtual Environments" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:197 +msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:203 +msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:209 +msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:213 +msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:216 +msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:220 +msgid "Currently, there are two common tools for creating Python virtual environments:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:222 +msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:225 +msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:230 +msgid "The basic usage is like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:232 +msgid "Using `venv`_:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:248 +msgid "Using :ref:`virtualenv`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:264 +msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:266 +msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:271 +msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:281 +msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:288 +msgid "Use pip for Installing" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:290 +msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:297 +msgid "Installing from PyPI" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:299 +msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:307 +msgid "To install the latest version of \"SomeProject\":" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:321 +msgid "To install a specific version:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:335 +msgid "To install greater than or equal to one version and less than another:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:350 +msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:365 +msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:370 +msgid "Source Distributions vs Wheels" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:372 +msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:378 +msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:383 +msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:391 +msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:408 +msgid "Installing to the User Site" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:410 +msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:425 +msgid "For more information see the `User Installs `_ section from the pip docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:429 +msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:432 +msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:440 +msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:446 +msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:462 +msgid "Install a list of requirements specified in a :ref:`Requirements File `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:478 +msgid "Installing from VCS" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:480 +msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:502 +msgid "Installing from other Indexes" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:504 +msgid "Install from an alternate index" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:518 +msgid "Search an additional index during install, in addition to :term:`PyPI `" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:534 +msgid "Installing from a local src tree" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:537 +msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:554 +msgid "You can also install normally from src" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:571 +msgid "Install a particular source archive file." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:585 +msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:605 +msgid "Installing from other sources" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:607 +msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:619 +msgid "Installing Prereleases" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:621 +msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:637 +msgid "Installing Setuptools \"Extras\"" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:639 +msgid "Install `setuptools extras`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:659 +msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:668 +msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:673 +msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:4 +msgid "Managing Application Dependencies" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:6 +msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:9 +msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:13 +msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:17 +msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:24 +msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:30 +msgid "Installing Pipenv" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:32 +msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:38 +msgid "Use ``pip`` to install Pipenv:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:54 +msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:65 +msgid "Installing packages for your project" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:67 +msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:76 +msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:112 +msgid "Using installed packages" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:114 +msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:125 +msgid "Then you can run this script using ``pipenv run``:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:131 +msgid "You should get output similar to this:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:137 +msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:143 +#: ../source/tutorials/packaging-projects.rst:594 +msgid "Next steps" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:145 +msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:148 +msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:151 +msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:160 +msgid "Other Tools for Application Dependency Management" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:162 +msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:166 +msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:172 +msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:175 +msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:177 +msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:2 +msgid "Packaging Python Projects" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:4 +msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:10 +msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:18 +msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:35 +msgid "A simple project" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:37 +msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:41 +msgid "Create the following file structure locally:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:51 +msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:54 +msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:63 +msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:67 +msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:75 +msgid "Creating the package files" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:77 +msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:95 +msgid "Creating a test directory" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:97 +msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:101 +msgid "Creating pyproject.toml" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:103 +msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:117 +msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:121 +msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:127 +msgid "See :pep:`517` and :pep:`518` for background and details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:131 +msgid "Configuring metadata" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:133 +msgid "There are two types of metadata: static and dynamic." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:135 +msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:137 +msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:141 +msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:148 +msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:153 +msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:185 +msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:191 +#: ../source/tutorials/packaging-projects.rst:286 +msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:196 +msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:199 +#: ../source/tutorials/packaging-projects.rst:293 +msgid "``author`` and ``author_email`` are used to identify the author of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:201 +#: ../source/tutorials/packaging-projects.rst:295 +msgid "``description`` is a short, one-sentence summary of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:202 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:206 +#: ../source/tutorials/packaging-projects.rst:300 +msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:208 +#: ../source/tutorials/packaging-projects.rst:302 +msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:211 +#: ../source/tutorials/packaging-projects.rst:305 +msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:213 +#: ../source/tutorials/packaging-projects.rst:307 +msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:221 +msgid "In the ``options`` category, we have controls for setuptools itself:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:223 +msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:227 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:234 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:238 +#: ../source/tutorials/packaging-projects.rst:329 +msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:244 +msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:248 +msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:283 +msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:291 +msgid "``version`` is the package version. See :pep:`440` for more details on versions." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:296 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:314 +msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:319 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:325 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:333 +msgid "Creating README.md" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:335 +msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:347 +msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:354 +msgid "Creating a LICENSE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:356 +msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:387 +msgid "Including other files" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:389 +msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:393 +msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:402 +msgid "Generating distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:404 +msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:408 +msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:422 +msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:425 +msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:439 +msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:449 +msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:458 +msgid "Uploading the distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:460 +msgid "Finally, it's time to upload your package to the Python Package Index!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:462 +msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:470 +msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:477 +msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:492 +msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:506 +msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:510 +msgid "After the command completes, you should see output similar to this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:523 +msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:528 +msgid "Installing your newly uploaded package" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:530 +msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:546 +msgid "Make sure to specify your username in the package name!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:548 +msgid "pip should install the package from TestPyPI and the output should look something like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:558 +msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:565 +msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:580 +msgid "and import the package:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:588 +msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:596 +msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:599 +msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:604 +msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:608 +msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:610 +msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:613 +msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:617 +msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:619 +msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:622 +msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:624 +msgid "Read about :doc:`/guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:625 +msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." +msgstr "" From d54b69a1eeb714d470670ea1800115753e243cc3 Mon Sep 17 00:00:00 2001 From: Zuorong Zhang Date: Sun, 29 Aug 2021 18:15:39 +0200 Subject: [PATCH 0092/1072] Translated using Weblate (Chinese (Simplified)) Currently translated at 15.8% (360 of 2271 strings) Co-authored-by: Zuorong Zhang Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hans/ Translation: pypa/packaging.python.org --- locales/zh_Hans/LC_MESSAGES/messages.mo | Bin 55353 -> 59167 bytes locales/zh_Hans/LC_MESSAGES/messages.po | 22 +++++++++++++++++++--- 2 files changed, 19 insertions(+), 3 deletions(-) diff --git a/locales/zh_Hans/LC_MESSAGES/messages.mo b/locales/zh_Hans/LC_MESSAGES/messages.mo index 047fa98e9bc492b26a1ca3f24a79a481f51c5334..73898b505ca7c00de69b668cfecf43f330ab8871 100644 GIT binary patch delta 11119 zcma)>34ByV(!d*$`@WGw9v~#a5Kg%TIYbZ@fd)vsT7byao0mr!`5 z_KtUI`!BY8aAc<9T){K zz?QIaSEV|`F7Qd_SGS`KB;@Cy40L06rT&544AP`j52Zc<-QYNQLr>BK?}C%zL3kDZ z1P2Slbf^c0D|IjSo$v{m1IuB{2&JB3{O_UPqG9u`O0|N8@J0AGyaT31>PVb{Ur9R@ z2TOVrE%+L|8;)gp7hpE*0G$-fLvS^elzs~9!Y`mi`dcWGxY9@YReO}CeN~8Ius-%3 z#-0do!k!Cd;3ZIsYZIIWpNB1AgMLa$y>^6Bbp4?P?}tsG$1oMP#?FS4f?fTHzj*kv z>F_ob`#daz6;K{1>aQbo4xYjO97_AX0lGFyp$q$EDAnF~Akl*p-~vMZ7L8P|3S%k^ki=Wi*71S1J+y2qh8;cj?@D zq2zoSl$>pXt>BA>Z$Nxk7oY`inxNDza2VvDn!}GaII<5ujeT;WKDcI6xs8}#%|nqQ zSpc1MTmc(me=|uJ*G~|qRnvQPZl^*i%6U*ixdKZ6bub)mgA%bbuqor6g>A7vzL%{H zzk%K1Kj96`uR7ePC+ZAyu=_xn;56J1FF*-x`edD&ZBQKE4V%HEka|>qgyPU;SP#~k zVs-~?jNK77h2gL-91Q*PKmv+9;Da*o5_lBP*Fd7GZl9{}uY|JFELa3LLke3>o2Ho# zJ7Sl@uJ9vcUx5u7uibR*K(`q>BK>9%e-1S@frh7`3(5qws4zJf8pD>b2b6(_K#9zB zNL?xy><fbi2gnI%!4IH> z?0a|#)_q7%R0Sn+tsmC8w4gjc4od&|P$qsHwt`tu7L*5bU=dsc@AJ>p2ggTn5)Bh( z>0(_*WtOq}WE#PO6$oSQ_C=#-Ij9Le_g}q@XC{=qm#3%J2WYMY=*2eRW z^OahN-NmVMy9u7f&WB~tpGZpRH`T?92Rp^B9f)H!jj&y?v+V!JQT|QCW+=JZ_?X@v z`=PAlJnRL(f<56)9zEe5P-^E9I0Qz+p>PZA3g3nG;bqto{tQpS7G9zY%it8|SK*w$ zcf%A&y44vt9nY;~z0HyrkOtcOvRu-w{shI5K8tww!v`Q^soE(@;iFmzPw{*ed| zV(oC!68+N3gdJ(mgZ?%sr6>}TccJ9y6W9P&z|Qa+coS^4ly(M=fReHSPbk$7j)ASA z5B7x_P)@ia$oocJgp#V8Sgp(>Up)h1uAlge17$S40W0CB@Mx+onw(|2Cbq)Hv_Au7 zfajq&T4>r|Hhc$;r2RY`2Rkg+yJ-%bh`kF+=)Z)`;n*}Llu%Aj(^a_`N)2Set}qWu z4o^c_@msJiJP*6UOHdrEvqDF#C6xZ1pe(G1X&(-2W8VqI@rm$wEw-p1MM6=3l@9Uk z@G0yEVMF*g!^`HrTCF|r0NZl^R%4GboCfRB9&6|{^g)T-5-8)Qn|6PWQMN(xaF^-u ztl?3^Qp48`-!;5wSY`N~;Z?(i>Dr+-hMl2AsE4LsMWM*VgAIopjxrnz#pAmSry9PIs4I8UtMmk;a=*j4ub^h~8*pyL8K35I7W6%Tz- z?7zZG(w?oRSE1z8zEMZ;F(}U`!HtB&DKp7|lO23Uzs{1JH0$(@xE1`^c8FqkmHfx70 z!!W}rSj7F?HWPn&;2$)|1Zs;?1)vF(_E(|Q#s_dd{1~=|3Rp$I^W zj-}?tMJOrwI~)wJK-pFU2vb*hKb!!)@Cqz};y}S6U6d0DqZH?K*ce8`FdRxW_6EGV zN#6fEQKZUCpcGdl_M#M57?c5ShqA(nP`1-F*c2{;vaeUeX4uai)sZZO;_xYB{|n0f zt8g!Dmai9Z93GMV{~?M@m~l)Gumj?m+6zOWg_65Bp{(R**c>)`QQMsiBcMz)2!_M) zupM+mN%3kZ3(AI@aeONr!Tf5#34KH+L8;P35NA~y90&)oC4}=~JNOKg6cj*l^kX3d zeg~UiH!afdhE7l-Isk5flc6{gfGyz{&@akW)6lY5-{=8H(mn)^fD2(HJO(8NpTXX+ zZi${~Anb`f3CaW>!xSjnH`Ux<0efK|fZgE-CB$DI_>l&ps%n+$4~pYZLR|?vz{{{b zY<^PP5l~h>4obgAVGB4PX2GTK3E1c*{mr-rj>WEox53C$`pBPqiulu}TE9%C!uO#3 zvKaA4{Y&Mj)B2-wF>FcuU1#*C*34J*Z$|IHOrC4|D!)6xU9b!ee2tF`SnqYVGQ148 zzzJ_?M=rrc?4JHN_2=|@xR{2ka4B4TR_E>qC=qJ&mQsI#ouCxicQ6v(__ntDLFqRd zN@yp*ZqRA&uZ4B6cfbg^2R4EJb11V=F2EQ#^c}wYU@lCCE6?fOaRu(cZt*7_u@~SC zMC7qQ>yJzy%a(09>|I@?6JdXB8_itOvh<45Yq;dtsvwI3wUuXoGbL+ZdPtXTt;V0UU4eq5Nh={-ZzA zE9?BRe(ROOo^_@qPBGr5aN~qd=szdp2*ay4uXL{ffP#n7-$~IgC`@vi|51xZE z(XdPUyciE9*NdSzx(AXq74x}H#lUjnFGVvBr7@fYTf>K-c$#S1lMR={k+iRc!YlsL5e3E)`hw7X1Lq5pN0~$ zGARB33Z<9=P(pke$^se@zPhkItOcbGqENQOI}lm@ZP*uHi3tc*Tm*JhD@T< zeTW=B^N~^L197_0pP|cFOaY8X-b1=z{{-b%?&0o{{S!vH%&29qH#sEptO|*1U$-G|+#pVV_0!BC8O)d44+j z3eK==@B4dalT(JiFrH55AmiP7!;&;hcQ9z$q&zedle(4%VDGmYMWev8n1 zz-90rWDt5ISd7>Zxtb%FkWY{f+?VUBM(9s(o6+mb{$GtUjt(!wTag4rzErEPg(#86 zkVEQqB#5ET0}0tywRRUen2|&fD=we z-ay1T4MT;WtQa z^bg^qNI4?cRNCa~5Bq5~^m7+Khaq<&d7&2l;j+)@f(MX;$X}3WkQRu(SYj?(G;&(E zg#P4yyP3>1h0u&P`5%oJu;$db(bnj*;Rr;&inhREuq!ebk?VWp1TqWzAy|RfCB#)o z0Fi4ZH%DqU^mpA9^hro1G8B>D`HsTsYoHli>=L9E@*uJf30>xXkum>f_-8|ZI2}eC zLq3bXGWrehZKF4X|3(fNyBcxyzZH3whPzGUo!C3kyF>Ys?ued^^g(Vzwjr}=mn&a4 zp@ofi+I(SFk}YPwE#B_67CL+h*04B-(>^TP9v|P^;fixdTZwj`E!O6(-Ez0pzDL|^DBm)mEX>$F=opXE!iTRumk-5MU} z_Ap9ldWS3C8s@Wm5{E@!Tf>NP4zJJSn49c#xLwv1y|j_hR-DJ3m~-l2q(9j!k9q8m zB|AL!M7zspd6VohjyQ+iK>~kmDe2y4am{M~t)@66a+FdaYyEjT{zmptE z(KS>n#)gxG)h=GjT8A*G*RnZjaWSZW0Sj@PMc0hp^|9oc1b1?Lg5~u&h_%z^iMQj> z++>H7z_}PE>38F2#kdob+%A^pjk10l%gCC+lvws6%Drl?@>(cu-ki_!TGyjbD0t}p zaN=rtY-Gb@c^!#KxWnSY;(lF6(!Dw{-dOVCwMI;HCwpS-)~~V?&d}XL9lAw~jE>OJ zces2WcWiQuWJ$8_h_&0QmzlH7iW*5pB{*UdtauxtO!kttP`@PiLYyMB1l56G9($6L z6#DFz-L=5sal0hf-l&|PQ~TxL-E~Hf2%FdEOo_A{zA&%FQrsS&jbdPcWOD4Gz$gV@ z0^!Q(^XE2x2RXEytVR5yYP*e|OP$$beBEl+5*6f#vRm_#y*|rDCGZfVEMPdPMvq-e zGe#;?d}ioaw=0aFb}3?q%g)N|9_oW-*Q_-*rk?_sYq#Q(oor7h8z~gya3+h=>OvXL zf#-`XqUsGrJA(92XDmIc?wr5|Wqk4`6S-y3L|d%g>NeKxit*q`w+M^1>O0pQi|r$u zuzJ^rHlp4~zia}_ofKMFlr^j0>^b?l<3F|f#M%VZ0{tGd!9YU z7ir}zwFcZHe!1g(c9-Oq47dq}j1r1Ujcx0-^dM5~PW-l}q_ACFHM1R+GbjH299w)R z|F52t8GcD$C}U9^Ts}(K>yB~AxuuUnn=2)BN;zVZ*?c;>k-ti}C5NTg_#5MP`D|=@ zj)dx9P%-oER7DFxMn_AAqG@7TvAvxR*L*K+EHu$Z=U=({OID1V*SUC| zgEDw5M_Y`~?MabJWj{9xo$op`#N_7d<3aT~5^c`^VRbe_yePp&g*(`PHFiXj!{s7! zrr33Qq>_`8JxOk_B-OITBslB~9InZn+o4mRO={=WB8R*wE{;gq9U}0L_A4P>tT zJau{gdrN!%_jlUYC7Bi3M*`dT1x_5T+<72Sl2);PU-TTB%S*SH7ZjP5)Odec%u`;F zT9vjhkiM$CC|ker0)@u{Yo81hq%mutG$**}cp$YTaB@>Hf8Q;^6>E7WxcP8s)R&l` zYI|z%h2@opj|DepR~+11UYs3zc?Aw-RPI_?eYRdZssEps9-{>ck5{hVA6T&<=y}~3A!EG;<7w-z> zEE8vrlvW(dD=*HfSaH0(pty4Hvf$Gz0>woH_xGY$yrR7LczNL;$_v(*m_^kH+O?SV zDlf?D6*#i0vh**EBAzsumQ5{wESTH2Dx=8t-Mq+8caV?nN}Luy`!?UIGB4f zusbV|e!L?4aA2oYME=jI9lHC2+fxJUvU#d%br#XlHGxuIw5syiUDU4GBy-Fm;iZmQ z3pc9YMl?uRUs%qwf%Hw4dHckNto*>*{d5eh%c^+xNZ_f=ij4H&_JdVh*5QNppCDHH z(@HDy4h0TvrQ8BJ`>R%G28;75kLT;E39QVo$S)><3`d9Z;?(lO^onCUS-FmJuxK6O zkW{f*LWN4@=*64#%Eyvbm6|~T>WQRhXrj=t5&40=%gakQ@Qj45_#g|bel4*uJ-B|o zwA;P3i@cY6h_{6q1c+>w7wngjx5-AoR_QD+l$HKfsapdD1!RH>*G~lwWd=7KtA26l zT=1w4AnVAn(a+_;tJqXL$iJDrPwq8HLQJBUQ1jfH+nzTTeGLz{b^- zt#(d|cin-?!v(~FN#&*CH*XEebo$0n<1eob8rdHeFBIc7vDJ~Kl!I&6v0e4}zm1_( z1FkU@57l&y;R#&;f2(~Y1Xg2tn=8F@^_P$i59_8{%S*GRh>G?y7Aq<*U1jcGx2V9j uA_+pM?j**C_cG?S3e`E23O)3+oVKCFTuX?l9{sWi`ybyH`BTnRwfYYlXI1b3 delta 7748 zcmYk=33yFMAII^DkSJLsB-EOPAog8|C8DHCT3c%iv8%KMtzB;g(W*VR){=CgL23&L z)s~`EY3ogju9mi_w(9Mo`nJ^j{oR>7k9qRHpZU)@_nbL1bI!dt*`N3x*yZcF5L$Y* zp^We`raCq(Z_GvN@!@JUW`7N1YT^Ohh@WEsPNk7u%{1$E zKbEUy4YhhqRVq4A6qdurZihH$0{YVau-o3tIlwv6Il(!@Ip4X=`HFM1a~Jv>k1+?m z6=RNKSx$7y`5EfO-#9NjuQ;!xI()}ANurb!aQ0$2eo*9NKa1NI9PzjDS zhCfr4mx~yWU9ozUF{5xeK8nZj9)?F7(?-^|Lz|4f$cN!`_!fST4eJ<_<6}%nj4=`9 zd+Hif5sPsjUPDi3DjVzBE5CrhXanlX&eb<&7GB04m=eoqU@lh0%m&5`z*kXI_&55Y zUqd^`fv77F!zx(MnSdJUK@AyyZ5TONG2@JvLMqD+vLe`V%i4mBF zfwaY0FJ<^4E0sim8CSd9UOyN{R>bdvj#P?8=bixDqNh&#~{3fZ{khdiECRJa|pY) zv{&HY%9w%V6>$najfHp_$KlJZ={%NVf#`~VMjiJrdjTwSfa6M|ycB7`^Q|EU`U(9Wcz!qJNVWFFTn1nMhj1wKf zP2`_HWFJ)1y4jJKk2=qC)D&#O5Z(VJ1&R9wwn5PQoBg zI32Yp7t)K;xCx{2bu5J^P>c5?%)+lx$4`IQm~EWjETW{17z-XOVSizDMmJ_K4j-5_R1AxQC9nK@XibKlZdcH1B1vv>m=p z`$NdOGbY*E3agQh$4Ja{c`laYfX6V1_D>(RBXR+G2ANy9601FCkG}(}kRN!A@z<3X z(VzogK@E*hZ=Ql!4Rz%MFcx3J>R5nvu^9FKe^Boa>SIh9jK#9p6n!xcW3U6(#8DW5 z^ZGFU>hT*ie2e+06RqiMhwgpUTz-r?z^|zNtMs!cu8S4P+o7%~8MAOKF2a9s0%rC% zhS4^+P-`uLTPp__c&NNXCFTkHtp5&&FqBCHjA>2#W^VSY_%-^|esqw%y-p2gebD~I z5IT!naR+uz;iPyIE3yAiLs>uMCY8suK$e>+HJp>9rze$kDn+OsCyro#@e|aQ$Bi`R z0ZhTqaV&;n=TXKqz`m%v!Gl_qnHYjgQ6rOs8nL~osX2;`@FcQmJ?1u*(KM9ig-)CC z=YTwfaMV_R&5aX1DeF$c@y5!8WB;bFXhOsC0CGlq3*Zeb7X#$%7!F)Oei7jgr2 zH+5klWaC|AR?NnUbcFMpJ5=&8nt7OlXK)gB<>fF3D8LWMr?FA1yu&m0!)hQZpMZLD zF2eGdgBqbcd;s^NM(91%-SxHFIqsk6(cGA+#x#Rqtb_^J6d%WET!?%enC+-3xr#c` zP?DB79@T+tJc;}85_+cFwUIi*&iz;np#5po`)AHz{MFM;w_&MsJ$9r$7rWv$OvHvW z?dnZO4gK3#0V~Y1a~g>u8vm(@xT|~X% zI_k=PbM0kk+qDvk>UcO7FqAd%LGrV6?33;$mLt!2&bkD(eI2U9doUc2dR)Vo&Yw^R zzT+%S2bBk)hO83mz!9#!fwKi_5w~~SJ2`te`#V#eX->~nSDEWv>|E=74b_3SocmBC z^RDwa>cpQqi=F44U!gjD(fOnE7BUsQK5xGP1*7IJ9<^GNaUnj1I=~;Oxx9zFF>&@-Ux?q57h?hz%(GMb7j_{pGvB-3O%fLC{D-K#;KOr!f&D^JowI5!Bw!&X zV<+@`!7iF^c$mDG%Y$CDPtY(-racqi!?UQhvucrjz->cKVTG6Mh*d{F&Tk^9=)qDK zb>em|@2(xl2VoT)j=?w+tKlN&792``1a+Lq#r8NYQTrvJI+B95aEjZWg&rL+he}o4 zg*xFWXOZ&@e4F-5sQuS3u_xG$`^opC+9xfwS2h>Z$QPiVC%@t(^jk(dBRw5;p6{14 z{_5FJ%k2SuR@enjX5 z?JH1IQM}$R&Z}6R_T&xrcxfB?#mx3+JyiIhGi5e$1?-T9yU45M*sss0F@QYoRckl& zjsQl`KF+njh{5D*unlfO-9;BL67OIV)_l!=KNySZfM?|Ec2)lFyoWkr`8TXpP*1Kp zn2eoJi)txq>b7BdJd7Ht(^wnNVG#af4X4}DrTkHtNBOUdaMAtA2bp;v7pIOO^ zdLH+t9g)GP69(kk14N-ZRv&fZMAVe^LS4XI)T4H(%d?$%sPi1adb|7+DwTojY2GBklb)w1Wj|*M< zGUo>DNc&doia%f?Hacg&B~QZs{9{_ht|D(!)8n{t)5L@;fdK9z1nCvVMu33XM|jeQ!BRB`W5r~Vz`d4`vH zgo^%Qpps$nz83O&kI2C#9Yp_q;9q25>&@6x)d*_vNZKnl}G4Uqty4O`s5~T?} z!~)p13zM-vt|LlH3);NbUxSukOIq=is~@OfI7lr*52603Qb2@LFUA<`Oz121HSz^Sed;P- z5UYq2N+^4XMD33)-9A*k-;73R{{N@UZ5Ti`iTVVrdf(3aQqkzXe6-#}DMz&S*6hns z(6e8q8vC!rUf#^Uw1*(tn-h-`$8`N)5zi9I#1n6XB)SkP z`ZiPvS9>#ltl$pftjq7mhkc)-L7%#w-EPbG_yLip4a7%88=^b$HKB5jm_htNq!F!% zvK*ugHo=l|gvv`qAJ=fz*_M6IP_KaB4g;Y&S> z*hcgt{{;7{PIM=4icb&`#9Ks9Vm%QDigK-mQaZ$+VI8?aW;`ilp+#nQ)x!z z6Z*}kl1fApQA9KmMhqu%h*cK<`^^#JP%6{S!QJ3~1ZrjJ?e-ne0$Hpd3o;YPnqsgPk$^Y$<3lUixo-WKEoBnE8euvCDc4OAP+RgIkFTNg?zk1i~T3Nf# M9L{f7e5K<50Y@k!ssI20 diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po index d75ffd0d2..4b276796c 100644 --- a/locales/zh_Hans/LC_MESSAGES/messages.po +++ b/locales/zh_Hans/LC_MESSAGES/messages.po @@ -2,13 +2,14 @@ # Copyright (C) 2013–2020, PyPA # This file is distributed under the same license as the Python Packaging User Guide package. # meowmeowmeowcat , 2021. +# Zuorong Zhang , 2021. msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-07-25 15:28+0000\n" -"Last-Translator: meowmeowmeowcat \n" +"PO-Revision-Date: 2021-07-27 01:33+0000\n" +"Last-Translator: Zuorong Zhang \n" "Language-Team: Chinese (Simplified) \n" "Language: zh_Hans\n" @@ -652,6 +653,8 @@ msgid "" "what index or source). The where (i.e. how they are to be made \"Concrete" "\") is to be determined at install time using :ref:`pip` options. [1]_" msgstr "" +"最后，重要的是要了解“install_requires”是“Abstract”要求的列表，即只是名称和版本限制，并不能确定从哪里满足依赖关系（即从什么索引" +"或来源）。在安装时使用 :ref:`pip` 选项确定在哪里（即如何使它们“Concrete”）。 [1]_" #: ../source/discussions/install-requires-vs-requirements.rst:64 #: ../source/tutorials/installing-packages.rst:460 @@ -672,6 +675,8 @@ msgid "" "ref:`Requirements Files ` are often used to define " "the requirements for a complete Python environment." msgstr "" +"``install_requires`` 定义了单个项目的依赖项， :ref:`Requirements Files ` 通常用于定义完整 Python 环境的要求。" #: ../source/discussions/install-requires-vs-requirements.rst:73 msgid "" @@ -680,6 +685,8 @@ msgid "" "achieving :ref:`repeatable installations ` of a complete " "environment." msgstr "" +"尽管 ``install_requires`` 要求是最低限度的，但要求文件通常包含固定版本的详尽列表，目的是实现完整环境的 :ref:`" +"repeatable installations `。" #: ../source/discussions/install-requires-vs-requirements.rst:78 msgid "" @@ -689,6 +696,8 @@ msgid "" "\"Concrete\", i.e. associated with a particular index or directory of " "packages. [1]_" msgstr "" +"而“install_requires”需求是“Abstract”，即不与任何特定索引相关联，需求文件通常包含诸如“--index-url”或" +"“--find-links”之类的pip选项来提出需求“Concrete”，即与包的特定索引或目录相关联。 [1]_" #: ../source/discussions/install-requires-vs-requirements.rst:84 msgid "" @@ -719,6 +728,9 @@ msgid "" "Index (PyPI)>` using requirement specifiers, and automatically installing " "dependencies." msgstr "" +":ref:`easy_install `，现在已被弃用`_，作为 :ref:`setuptools` 的一部分于 2004 " +"年发布。当时值得注意的是，使用需求说明符从 :term:`PyPI ` 安装 :term:`" +"packages `，并自动安装依赖项。" #: ../source/discussions/pip-vs-easy-install.rst:14 msgid "" @@ -730,6 +742,10 @@ msgid "" "introducing the idea of :ref:`Requirements Files `, " "which gave users the power to easily replicate environments." msgstr "" +":ref:`pip` 于 2008 年晚些时候出现，作为 :ref:`easy_install ` 的替代品，" +"尽管仍然主要构建在 :ref:`setuptools` 组件之上。当时值得注意的是*不*将软件包安装为 :term:`Eggs ` 或来自 " +":term:`Eggs `（而是简单地作为来自 :term:`sdists `），并引入 :ref:`Requirements Files ` 的想法，它使用户能够轻松复制环境。" #: ../source/discussions/pip-vs-easy-install.rst:22 msgid "" @@ -805,7 +821,7 @@ msgstr "安装格式" #: ../source/discussions/pip-vs-easy-install.rst:41 msgid "'Flat' packages with :file:`egg-info` metadata." -msgstr "" +msgstr "带有 :file:`egg-info` 元数据的“Flat”包。" #: ../source/discussions/pip-vs-easy-install.rst:41 msgid "Encapsulated Egg format" From 24ce664bb992194283863b03ee2c67306019a0f4 Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Sun, 29 Aug 2021 18:15:40 +0200 Subject: [PATCH 0093/1072] Translated using Weblate (Ukrainian) Currently translated at 14.2% (324 of 2271 strings) Translated using Weblate (Chinese (Simplified)) Currently translated at 15.8% (361 of 2271 strings) Co-authored-by: meowmeowmeowcat Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/uk/ Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hans/ Translation: pypa/packaging.python.org --- locales/uk/LC_MESSAGES/messages.mo | Bin 25766 -> 25808 bytes locales/uk/LC_MESSAGES/messages.po | 9 +++++---- locales/zh_Hans/LC_MESSAGES/messages.mo | Bin 59167 -> 59467 bytes locales/zh_Hans/LC_MESSAGES/messages.po | 8 +++++--- 4 files changed, 10 insertions(+), 7 deletions(-) diff --git a/locales/uk/LC_MESSAGES/messages.mo b/locales/uk/LC_MESSAGES/messages.mo index 4cd8e4935a6f423f236d38e6779ccf82930cb1d1..87bcbed49ea9bd268bd50195917e008d26108f73 100644 GIT binary patch delta 7010 zcmYk=3w+P@9>?+TpKZp>%x!GOuoq|mhHFsIZN!>*0CnGajKT;mR>efDfEi{7 zU(akUC5}T0&}2wmpKlHbA1YG#>Y`hf5yCQ2E{oSLVZ=#7DZV(9(8{bYUSGC1k6EC zOSGPh9{dt@!$GW#$FT^nqB<^QnyMdxbwRedajG3qoa!~{5j%v6cYOe>Qo*!n8H9gdXW~1((hgEQqxyszw(DNJE zNrgH%fNJ=-m48Gvbl%Fpp$6m{Id>aWLMG#eq3WMRO<)eH!zHM#SZi)Z-M7=+?^))k zdCI(GUc*0lAT-`zp`ZkRMpaQu9)sGl6x0f~w(Gg5!`8#fh2}`}0n~)OM=dkmoQoRa z0@TcxU=Xe_-$pIzIxL5qQCqOpEJe-uuz4EQ(PiWXaDm2tyK%_CJ(uWbTnp5LZLFM+ zYPbh#N$)@w!QGE6iYqqPn+H*^<8{=Q#3cIVEYw!qjyjwpQ4{nqUGM)4GUKV(f(+8N zY2w^sEW`@vn)(feqE3B0>I0H(^#vGAc@%1<51=}nY|b=F+P=9;yBF3 zV&qu3udpRvMV+P8G}fPOcem0CtLCO)7`}m(aGkl?>OZ&gek&its@!+h%GXf81uNa; zw-bk2;bhbbw?h3c$VQ!&z8)EMI1u^0;zpvDZW>15V${IaTKN#_{A-Mi4|dW^zJ32L*}7IJ|ES@?q4#E}$AL*UBGI80vZy z@}EoMhuSN`JRFZ2@CMWXKK09<+e=2T&k^$^s^Qb9!*dDs;AOiW%n{f9VW_2zL@jL{ zD>t%o66(X%8r4oa)N|RW4_7{B>;3OcCZCFFsFCi#t{B0)r7gJ~Yv2Ub7i^aKCTj0L zN6qLUYT!Sh26PV9@fGt=)Zq+plGR=>jHG{eCmAj2cx;c;P^Wtv@~XO%W@LuH#962g z3Q#i~fakejatH= z?D{#>{g)(OQS5%~6EvDZW^HD1> zAGO3APvw6h~%JQ#An9-OLP$zuJLNvA?H%|V^wJWRm;s1L^! zWD;&ER>LEx8C*bZQ6Sr2p%jdzoP!!zA!;Hcu?aqHmY`nq?>xKVvQ{0Hi>>?`>Vxw- zs=*RGjhm3Ks9Vv|-=c%40iD4X_y<0UNxV{eZUu6V-8-0!XOWfiTr}@qb1E`09`C{^ zoP|0}OHo_0*4&QTvID5IaU5&mC2W9Uo&4ugP}eif9;mG=L_I$SBlP}HD$DT8#9V+{ ziRGw~uST8z56myjBdGWI7u3u{ZuZYmO;ks9Pyv@v{pKmum*X1hw1jr|zZf-99hl>K|cOP>Wl=hu=^$)QgvmsW=dI3}>4g&9j(9eQZxo z9CpQ9@Nv|D_MqB5iP3n~Bg1ODDDK*TgOUAm(Y<(pB_D#7DL>TPKgN$Ezmwe>Y>6i@ z9cvf(r=l0?vVZ70h66DYM`Hv& zhU4&AoPj}o`S%t+gF0nLP-o;SR>R1Cyu3^-9(kWU7xy=R3p%3qyc<@>eyEv@#BDeM zlX)<+zjJ&R-N@Vg=aykr%BwILH>17;XHehN_}l%x9*q1Ra3e4t7h{-S&`-%|r29}y ze;ylQn>+kdJ^&k1egxI1JV9;(4Pr~%El>r1f}<@ZqU`&sOcjf(sM zk46n(a*^j(Os684ih1TjRKu@fd0dW~>07A#HkeybOS>Jlw7abQjg^mL5cQ`}?VLkB ze-X>!6^~3dnXAZe7?(MOR}H6PSNs^YB~^y{dzOs#DCe3*sJ-`4Gn$JU_)Dk(Ek$*_ z%3O;&obRH}fEP5(U+OxjB~8Nin28N=A|~NNb35v6TtIbD8P#DMfKAgSy9gwkx@gVPz_8#Junr6a3+?=xu`QS54D8LFbG$o?q6f|A7VJ=tr);& zgwiyhvR8B``GrJYfc@`e7jkeiF@@mSvebkYUL)5G>ti&bgXg{;Gf@iAzK@^|gtkH<9f1o>Qi8n+UAh<6F4*NF$!er@wJ=m%*5@ePqnH0FAd zBqE7V2&F|t=dzr0e@7i)rKa3}lb?0pn&MW1-(#*nkwW};{?o}nMP%7P^qX!Kny&Mtb!|1`8~IudnB7*o`Zws7F4}Zpb0Of&5A0pH}xT z^L_k?_>zd{z96D1QGsYggcH5F_AAkdxQn=vUL-Ss7)Ttvv6~ST#uG~Ih_=KBDv(lW zEQ1L4i|%*qNQ4s^Ru_kdE&l^nTco@eC2n^)#XfdHs2>6qWiA{~*>8n~8^r zj$BvTMpP!h17oaC^-3QT$8_-9a^VbxTKFec!g9oobcoDnR;XnbVqNZuvin+@SE>Jv z2qC5t?+_(KCf8?T7eXnM$S!-vV{7c;H>qr@t0b!ZUmI|X@}x-a+l4QbmG~1ejwZ$s zUl1#ar3K*iLwjFi+g{(CN~Wy$io$@KymCEv7b lR_=cn)@HQ}uUa~?b=?8n}l&&jXy=Qt!ez&2~e*u2g>UIDC delta 6965 zcmYk=3w+P@9>?+TFl>fxF2lyynAvP>nEPyOa?d4~atWbAl2YoZpCXrY3bjy;3WJ1jUF zTWOgi6@)pLfL$V;+em&?ZPhy0INrG-*aRElOpL;(uo|vLUH2;1!9A#U$1o0m$7qbB zQ58%zTYCf7feiO_d1ha8m^sdzit6A#tcroT5GzuC0&C$iMmtW5o7)Ye?Jazta_J{q-h33wki zMXk^(40PeUWYl0g*27&m7QaT_xI5ESeP67P6EFfFLap3FtcxpA6WNH>ajUt<`~o$B z(^mej3G1&4t&8?93d6B6>INyO0klSS+!3|c1*jYJGKZNHP!pPgYJWd!ujiRX<{H%X z8%cHYR0AJe$;s+k(4P0$9x-h{$ zXo2cD3$>)(kV(5C$YQuz<|=bL>hU{?+7j2?my=Lik&8N<{ZSK~fO;QH!+Z7ozd(k; zxr9`nb?lB+@D!@!GSsP$XyM-v$*B4q49CG(6-S_MIL@4I2B--ww(=^}mc4?Z=YJC! z-Ear$1+)kCxE--_Icm=%(wwV_@u(T3;~*T5?eHyB$LCO6SB?>Q1?z_~*mOU@#FqYk znHZ=+4jGLw52J7Zj>eJrJid#X@#qYH;r-^rs4ZHA8u+uQc5h%s{0Q|%+>hFt$V|Ud zEm7^;WwQP~$@HQ^d%FaAdAVZb33H!fdo0IpnAysAG!3&TFGXFy1N&n{Yu+6=9P@D& zaxB~yY=d8;&QcvNX4hS(EcTz(apS4b(mjrm_>8&M>R-2ViIsO^H0=&p`2_0Q?}C-X zv;9iNpjNm(>boErbyhl{?w22s;rqn(M=jkHtceRy16yI`9jFTqptk6!mCs`h%0FTZ zR%V*Ao|%TaVHecI3b7UrM4ho<0vV0`LDYpss19E+-@;myOHl*+9M$0&)POExExd|t zF`7T>uMm6SNYsFzLk(bql{XQ%27-Eo0Y5b z2&f#5I{gh${Uo9u(`3|(s|Ds_ODxdyKZT4&`UdvKA5dG8%QIFRN1@(ecbQ93d;dCW zM%z&X{}45RgQy!HHIJhX=V?@bZ8_0e>E2kA`@4~3y5JPlW3mp@agSM!TH>S*{suXy z8RnsGT!@u%fR%@$1~vw@mA9j|ZWd}q7orBb3E*ar2&xDgq=n}e}f zf*Sc=)Ycq9txNdXYUkx|1ttztInxt@#aa0#Br zmB`!E&F}8FW)o^ayRa30jt^m#9{#%d$hmb-U`yPMTB&l(#M%X+S8?Eakcp$>Hq;@S zgW8hC<{H!?eFt?Wwqae|k4^9l>bi(R|9PC5irTu4sO$Too`Rv~#E=31q9LQDcoa3` z$54B_!d!2bpq}54Q8Pb|74Z`4Mwd|otJ>4wFcA|er{YrVg`9JD80%r3>)7H1GMQxL z2-J;dnhS~^t{xv~E%s3(PnbXA;V?F;m*1>Yytj0#OQ<2n^zr9D1+|%(sHt^AtzjY7 z!C~f9^AXg2o;El1;Q>{}b}IDBIEXqeN3jx~xAH~Q`To`F>-Y6HXk@lU_0z{3gOQYH zAg^2ZAXdg=tb$um_u0{x4bqRVeN3_BY7J7|MmH^F17A z;H|g_zeL93CJgbX>}}K;Ie@Wv2Cp!&Ur^6e`B1+F^@fGEJaCQ4)Z&9Q)Va^aQtXc{ zxiDt9bG!~+?g)S3Y}A0~VM|I-@& znPe)e-{enu7A8?1gzESn?1mdqGx!Fxu*OKgb$Q5kx&_!64`Du*qn5hED8F?#qXtrh z&2clPaesG=j7C;%wBM6BGYM6nVdaiiEp{9#&DcGHt?D0RH);7Q7_#9)o?DV;Zk!sYH3%YmUgX`U$gQ%s2A6ER6ie}uHTIn za3AL40W83nV4VMTI1GDJu@bcN) zoR6XU`x3R%7f>r2gx%tQ9mZf2Dh6OWPB&Mf&c-g(4NjtF_$}(j-=iM4t5&W!!4E77 zbvEKqH%dXRXb!5M9?129>rX~A8HSZ`99G0hsF6-aE#YjegpZ)wFR=P2u{!0aF$`M} zN{@P6A$~|aLv*J>fz@jp{=)s;Y%&Z!l$z7vIdUzq5!NTP9gQh}i(0~_FCE#8X7Di9b&eN@-l&jnKX+Wsv7>>S|*f zY)k0z`jwbR3?P&a5SNImw2LGjCZB>EQCpQv=z0HhN~3T{``?I$O4ac-pLK7T+prh$ zn3dl#%P@n;BwAUWHh(VpJY0nTCiW9=6W7w+WKxJKwDF1cUufB<@pB@NXhwsZC80z3 zKB4pvqGu?_K}0%zVDQ+N!5`341zN{dW=JR&}(Iv2vq~ohpJV@L}d_(9( z6HO@XCC-L&e8Zvse|k3N;EVVYv5rt$Omrdin5`uKORON~5W|VV#OuVpM8^tra2J`c ziEAl=x@(E|MCj{s7T!-hKzu@cSM*6-eDHU2jfp0NQfs0&(T8}RXh10SpvNZG>;EZd zTfPGM--tvjuOk09BG$@e-Lv{*X`ngT%dbakxSooJvrg zc$oM}EkZx^f27ok&Q@ECrFf30M(idYCo1uIYoagtdbkgj1`+=xii!7#dx(5KSK2{T zBfke5Se@#XN{M57&^z$Kc?xy#Dn?+~pBjHf-7Z3@j>nC{c-qvpc5Tcn)Rz;L32nk# z#G6DXKL0CTM<{h7x`wWyRY$w{WhztkDd{2N_fXD%PbwQtyN_|1)!%{Bh&zdoh*yZ? zgi=3G=tuqu@=;dKF<-!)M7QFM_>p17MG2!DRcxP`U3{riT7{ybgskG>U8__t%5RoX KJg3jV27dr0Y})?- diff --git a/locales/uk/LC_MESSAGES/messages.po b/locales/uk/LC_MESSAGES/messages.po index 5d698f156..131e6dc5d 100644 --- a/locales/uk/LC_MESSAGES/messages.po +++ b/locales/uk/LC_MESSAGES/messages.po @@ -3,13 +3,14 @@ # This file is distributed under the same license as the Python Packaging User Guide package. # Alex Solonenko , 2021. # Sviatoslav Sydorenko , 2021. +# meowmeowmeowcat , 2021. msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-07-17 10:09+0000\n" -"Last-Translator: Sviatoslav Sydorenko \n" +"PO-Revision-Date: 2021-08-05 16:02+0000\n" +"Last-Translator: meowmeowmeowcat \n" "Language-Team: Ukrainian \n" "Language: uk\n" @@ -18,7 +19,7 @@ msgstr "" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && n" "%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n" -"X-Generator: Weblate 4.7.2-dev\n" +"X-Generator: Weblate 4.8-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -1519,7 +1520,7 @@ msgstr "1956741" #: ../source/guides/analyzing-pypi-package-downloads.rst:170 msgid "2018-01-01" -msgstr "" +msgstr "2018-01-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:172 msgid "2344692" diff --git a/locales/zh_Hans/LC_MESSAGES/messages.mo b/locales/zh_Hans/LC_MESSAGES/messages.mo index 73898b505ca7c00de69b668cfecf43f330ab8871..888f61a1cfb0582f984dce4602476cfbeb7899f4 100644 GIT binary patch delta 8054 zcmaLc33!di8o==(Bq6p$h=_0^B$n8h5J3{Ev9?6io;`#}G>fIdv7||DB~tqq8cS8J zRYa|&q%@XR(UvN)tCri=t@ZxjGZT;JKF_`1)7Nj_`L_9H=9_bJy1K~j@}HW?KPzz~R={p`l;RW>hH`!cR>Mgs$1gxP z+>TYS5FPMGtyNt!6?aiC^a#u23sYatqEB!}JL=t0_Inx|7+V=T8M_<%8zYRPjOjM5 zN=>C8Et+l2MMv`G#(b0;e`efn+-2O0(xCmu6UOhb67^TGDgK5oSj&sXV>8U*{;D^H z)}@sC1?57n-b(#JUI(dCRqC@3TVhvq@lk3CzJsy&2fl^jzDm8sb?7fP&|Q8Rdy_xF zDHzyLsbbuR);w;M*GMS~6~TT=RmEuBh2t;?{hH_=8G{d`9;KmiJXQvd#U6McFQY#b zrY2Tv&iujVC__6F?QtPWkFRL1thO%6r=kWGyNzd1hTx9LAE7(BQwx3J`Y4ku2#4SR zbjBSh^Y$ppk$6lZAB8gOFX0S)h~wz#^fvmz?zhzq{L4zA3J16{VA3`9QM%U8=#Pwo z3c*U4j2mzYZbhGVN*%->P#$1WdtOysi>dewcjMRqrAA_d4)iMKpd4?_2-FwO#xyDx zArGaTI_j2o#;LSC6s3WMos^nJeg+4S_X|>LD1L&osJ9Q+vpgq+wS@Y7bf(_9i@uLH zGk7-jEs_0Jb$~)X2Q+>|clDWWN{!)wkKfci;T)>RtQN|cH$oY*AgqeRjVZ`OsVubM z5v+&Tk^huqch2WNeQ_1}2xe>r?yu~7>aM7YGD+%SA_q1>8H#1S^yFHHJcQbfZuk`4 zv1)I9eiM}A+hYUliqd0auoBlxLz$d2`Y2Tfm!UWJSF0(M#;?#Bzs6j=h;oBOUhYkp zg)Z3QZ9Ozyu_AeItc*jDd8$UE6Rtve%{HN2cL!F$qgV;gqP01Ns}$q}=f3&`Pm~MS z#~rl16*3y?WVXylUj}=!Mfwo{#0Z-XW9*oD8S`rAvMc z=Vtg27oZz6OS*Cs%DS)%<;jasF8nJ>&pb!wt8#lsKY4#_M4pYca0mM0X_WIHqnuxU zpi*VgXCVFWNWqT^J8XkK*dAp8i9`!pQCggb*KjM!jTQ{jJ+~jd$qP}={|)7M*TMS6 z-dL5qE!Myun2Rx13bQCY#w46RL@DN-dWbUFI`VGi;WYdb>kiXv{x3L`uIxITi&DQP zg5kl7=s^9!Nd1}}k7CAC9~RB4jq7j=2F5Uf(Rz=9D<|BF<+GcLXK`E%hsG<#o1$Le z`xrWcMFfjb8r*p#s~moV^5kt2lq!dV@FK>bba@~LHO9Bl9y8DZr=zpH|FbAa*Q`M4 zvTZ11a}b;0F_c;RFQjcuZ>4y66_0i_{3wnmKar@%HfRhJi+m`a!v=J#563;l`{Z?b z3TZ&)cV*}pe>V!Upm^hR3`S{C=M+AbdYalp*_h3X2lnLs#_Vsif!R(^ck13%KQR7dEHhINNoDk7e{GZ@?1?gIhasJzGSG{jwwtA|Q-3y#S1HE7IRzQx zr*rr#1wH5LCHOQlD$3(SzARuK_C&{d`ZJ(E29x{G*JD2sL&&pm92Vkt7?i`C#Eo4U z&wAu5bM^5@a5wi?rzv#C?2q)MI*y0Pi%dRmp5VE z4oXk1M0;F=vhZv~nWXznegds>z)uuv;5C#l5>HXq1*auiUmQ-}1?56(Q7*L0>_39i zkSkaR|1|qum+I?zVNL2=pxm#QF>ER0FBOBSD8ML`2Gm-nZ{UY}$lIgTKSFu3(#vfh z1Iiv<$y4xM%$9n(`X7|*#;w#1OGIh#bd>seD06AiO8Q?4YpC$W%_tZA9zVl7xD^+# z(!RM`U*Iu@Q~v@-V*fmS{C;F!s?lqd`V0R=x#8Wlx&aSy0{IJUh2yOs>jmReOrYhv zP)?|`j=%57eXtw(l=XBQ9>ZYjT{h^U=)X}<&JkFP`qNmB*Hru{_D{F5aQ@WXw{3nZXCVLHm|WW`FDkMe%+ z#LDF7cj}(JfzsgnCa?Fo-rpG4bAQ!=f;_=Bq%Eq#r`OHs4*O+A<@_XQ_u~Uqg;0@n1NQ09h)|RsjlhMNfwuSGnQxXZRMapwHg+=hMfo_5 z#X$TR{qQQv5LDc+zpAyw>g18=gX2-2bd_-(%Imw??BBMZ{%=IZ1uDF;G|QTt;Dd~Y zYJx5B8cNr?9@Gno7uFyTGN@3t( zz4m{I9IJwk@J^%pin%~nhGPfP(MR={%MIv4eJbCpQmN1STK|Rg1m}>49OqjTp2l++ zd4j(QuvH;{F{9TvN-f1SD+OsurIY%v-hMcW{19ef<5Rp^xB)$|{B%wZjcHgHmze$guq?UtB!z|)&SFJ;ibJs6X}-5%9Nxl0OvmkK^xNTk zR(~1oh|*)1u{1rhlEPttU3N&Q@u>m5QGYE>K0>#xguP$thK^uuyL z=q0%=$`cGnJDiU4K4)P&Jb)H_j1E|XZmEtIT#x=3hF35OTVB*3(;wk5dH*j^7(mP0 zT+)AH&G}J3S@)mxr`{d(;l$9N^=p`nN#u1e>kpkA+`{>GSNIK(`W?UM^u*oQ|VLrCN zLXEFsQ-95#f#KxeViok}X?(FYy5P`T^uOF7nF<;6OmxKUC{J8~_E?Cu@r(C+=fUoFkQNj|pF57?DntCCU&bo0FA;Wv!NN5%CqV zp7@QBt%v5-zfURsLsaIRenfN1gYgU8Lhx3pzT^k+Fd=3(v5Q8fr=mhJx-?8TA9dBQ^dbL3Oqwvv2EIhryn zneCTCPyCzMP003)$RlcUjBLG82J4|M<7FkELHQ#>excYPs|Bl&8c1Tn9$2znq0pTC zO{|FWUdhjn?_x)D9PhDhdxL-F@9N_?T36Xt2w9$Fvm@jKzN|Sf1S1JAd7EUVXwS}e zxfR_#8U|6?MwD!g%qc7Zw!d_{k~bkr=k|4Xvj&zNW_Jr{WJ)%DGHuZlYYqo83 z=iffmwZTE?iX(_Rl)Z@8w*Yea<{E42Wg%Ejv?u@JwF7fyOq#w{F~pSR7r}{?{~jA^8s7h`f&3??xU>v?C@_7mBiV#<3{tDPOZ}Kaq7Y`|2C1w*77^%4T(ZZ3iDB zs;SAR*mmkS$ZA{=n^~T*8Htf^j4l8fD7fl+RE;MjRw!h;NCxgd5SFa3ET9Tt9q7l%ae{ z`ago?1|eG*m9n+M7P@HrH=lny5Z#Eiwi^BS^e3h)yhD6O@X>AiwbB_&wpA3Oh@+`2&g%rfkNb%_{4wto|Q2>Bg$5Z)%@iMzy2 zLbf67>#U2)dW*t)L@(kF5kPoyz)mdL+L((=zMrT{3?y<0*-DxH`*f=A8P6FTvOmO> z36D={xNvR33aVc@Jmb8&^mejPUq}ZsGSWA3ziX|W|E@ezW zWORB$Vwxo|#75VI)U=d@==8LN2V9laAII^7sG#6N1QAeh0Pcl*3n@5ruiRQBYMOgqXO0vr+=?Sdj%;YT62;t^ zT3F`Dkqx!1fBn-;vHX9&_Zn52@%RK;ZEpP9f*1}?`ytX;|&-eM9^?{AOAa472d85oM|u`upK zKm5$K{6NqKxsSJ|Aj-0cUY%8D|w|J!hh`y|brtuvd>UBPggv zlbkcrpZs;_V$_8*oa>#NoLf;1+Tq;mJc0$OKZ{lHDh6R-v@wxb3g6`VrV)jBy8ImK zM7hft^E-JVq{^6b#$1Qen25Pz7$$6q?eSfFf{(F|jI~`IA7@Nk^5<|WrsEG7RNk0% zoc{rOqNrG2(U_vR4?o5;*c4}0vORGWe^WiGfd?wnTX+InVFI^z71OW;4rRi0$2q7W zy@7f0E~=;hMD;{YRpT+mDHN<`yvCwGc~h4sV;K1W)QKmfCf73Tg*&ha=BsXu=4&`= z($&By?0^OERp&GeCQm~R!G`Mezgl?M9dHJfU%_m=g?hvO8n%bd;ZgGMQT1DD+PRU5 z!^sb$W_z`GdJmIuEM5IM>c$dk+XlA5!sMwQ3hJ84sIHyqOhbCxtiXbJ9N)pO@qL`a zKp(=&b!~%x#UA7jaTIo{XUrZvfhp*zZ_FLMjk>|?2KKz3YZOLP@hj4JGoYbu=~A3V z%h#eB7}eOA>EyB4m3(UxV_rZ_l=;;6#vsz$%@}{o!6MYBG`AO;n81pnejaLnF=p~c zAI5(Mg={KfTNpD8AEA08rKKIaQK&JWjvBLNSQI~Yom&b6UtWsQ zkS(}|{9v+uaP?;925@~dgn}l?SRBfMvoJsTAFb`=dWvSO_1IA?$oWoV2>IoHn@fHq8UBHJK zrsqN+24OkWiR+?zrZX}x&2X%N+pz*(!wAgRjroKzsQ0%+y}v)^!71pEGrQ6Mz7!Tv z5rc1_9w2)#3NN6#>;c}yyxr}E?x1=uxQ89fDAfBCQOBpEE<6#7;zHC7t;clSkMpse zr>A{zT*B5=B=xeBZ85GRzlaBL0&8s$*6z)+qbpZoZSueS81oZW?aL5RAJWe*vy%OJ z`cc0Pm*Qi557P&*G_m`31 z_RbezKJpLnBJM}sdHT!7RK(4g7qih1FJTe<4(S<>`ICaW%#X9?!4RyB5vW<)3Tcz+ zhTOEtL|$lU~x564KY|A`d- zp<+2|td@?n%VQhrPOe}D{0(C;>{WZgrl`5|0@lTTSPxfVG@eI)ypKWnFJ@tpQS>fm zuK_8qPyK;r1h+H|82@sKU5gT}R(~;xWTR|EmGnRGh-wcmsD%vy&!$x}6g% zF_8Los1xi!HFTe=KkPhwm?i7uMjg@ot4bYeTIaI@wakmdk)I&jC;s2WL z;zsxuc{j|DKRfTc{br7Bc?k?*e?^x!cXmQQ>IXT8I!B{=ZZhh;b6veB-4#}$TDZX- z@Q!n*Gt+s}dER-=dB=Ir`NWxju5C~;XC$hJ%2_?83I$!bji&fcgY zNx@1u4vXMM)TG^ww84CZ(RB3-^Xz%1&gaJm`8C7drZ&p#r z!naj{0~gyz?htH8egzL=g(Y@U-9bGOpPT%WU+wn4kHx9q zjh;dj&QZ_<;kq*i`;dn&vnLvhI?+7TaZ6FNdncB{lWzZQ)cNjX3Cy$HHYmy&>#TzN z*j4f8$CtWX0rK``N?!4Y=+pwmn^L0gU zkD}(#5a$?-C7-sM{?`e&P_Y9u@qJ9qu!gU(Cpe8=sL#d}j9Y7ue-oKsrpY?)8c(7w zcyPUKz%d+8o{crJ_1pG2;X(c4o~MG|@aG2BJQa_y1$oC!#!h$#+wXWx2A@Z#|ZBOn)H8{)Vf1~z4!Od7`m%V}A_<`2{ zMGCs$ypQY&)*>x4o6*~~sImJDbtnH~VGQ`#<`K^Fs0-D`IBbET_zG%>=b&yV4VTmK zmDrH$o0@y#Tlj~Ik^(WAl>R}u7y-BAu3Q(qSw;yA2?AEAceJFJX(57-OEV+?s~)CFF3PCzZ+ zX>R{4tU$gU%ix6r^uONlhzfeu_+;8I6uVJfeH%;QeJqZJ58Avu>dq5U$MwM?n2HN= z3Qomo%Nf<Qdx+|xVxJrH4Mw0Q**&a;xzE_VI_kJ)sIE=I(m2%ZUxazc*J63xgay!ZjzTXA zS8*WLJInVz%)l`?`tb;wVF203PcpCliE^;Ds4>x1L1)dSO z6Z>Ocx~(~;U~k-xU1@l}i~427`1iYH?=14N{nX3E7!HiMVwYh84k!N$N8;db`6Xjj3ORiFg(hu;`EW>vcEmLcSgg;{%LE|DWu0r5ft|38*3O{uBN0 zPhmC{nmlQk7c;OVZgllWP+gXdI{sVKWcm@+#rIJ+5J30k#p39Lng>-Vtj4ByaDQO2-?ElN?N`Dv{?n&aXP~tmk^nGP7zC?UQ zlp=qO`jK4#7ZUv`^91wGf=Iki>?XA35Nip2RB3C28m!;F8S9XI2IX|3DCNx>9iBqo z??q9V?A}Px`{(AWW-t`O#zHFcq&$4;H}$guG8O(?xjJl)E>x9|w?{su@OuSEEy_YVv8GC8&s6ku z<$N4Co^m;yj%|qAl<92q3DKX>R+zX+TqjDfU)vLl_ity*DeGY{he%}qVXR1`5c;O6 z>wC9xyjF5$J!MW3ecTDdu>yH1w?BluDN%=*L|seN))-$wJx})$vxw$yUs)$rW~*M@ z=J9)G#}z6oyL^f};1aeYjuHPQdJ%ctG1XCj1ZqiLenQ)DVlMGLv53&7Poy=(Ln4yn zhhlr;lS z9pXnqTTk{iwngusUMEm)P2ARut4Be<%XYd0M7%q>$_I#|L^t9M!n?Ws`(668^GjzO z`\n" +"PO-Revision-Date: 2021-07-31 19:50+0000\n" +"Last-Translator: meowmeowmeowcat \n" "Language-Team: Chinese (Simplified) \n" "Language: zh_Hans\n" @@ -17,7 +17,7 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=1; plural=0;\n" -"X-Generator: Weblate 4.7.2-dev\n" +"X-Generator: Weblate 4.8-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -897,6 +897,8 @@ msgid "" ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." msgstr "" +":term:`Wheel`目前被认为是 :term:`built `和 :term:`binary " +"`打包 Python 的标准。" #: ../source/discussions/wheel-vs-egg.rst:17 msgid "" From fbade86d8747be43303f2c68aeafd1b2e25f1440 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Sun, 29 Aug 2021 18:15:40 +0200 Subject: [PATCH 0094/1072] Translated using Weblate (Ukrainian) Currently translated at 14.3% (325 of 2271 strings) Translated using Weblate (Ukrainian) Currently translated at 14.2% (324 of 2271 strings) Co-authored-by: Sviatoslav Sydorenko Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/uk/ Translation: pypa/packaging.python.org --- locales/uk/LC_MESSAGES/messages.mo | Bin 25808 -> 25870 bytes locales/uk/LC_MESSAGES/messages.po | 10 +++++----- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/locales/uk/LC_MESSAGES/messages.mo b/locales/uk/LC_MESSAGES/messages.mo index 87bcbed49ea9bd268bd50195917e008d26108f73..275db5ba35d910d84969e5932ab4f8f91844f1e7 100644 GIT binary patch delta 7087 zcmYk=37kk(8^`f8V-_Xg%xW2CVHOO=SO<|Mjm)Slp|YeGiKghLR8pZP%93Pz zQ;B%XQpsB(Tg6+XqEcS6WGf}%{r%@Y^M2e<&wQVA?!D)nd(OFcCSU9bn7K2+I~*M} z$8mHGaIPNq40mol`Q#YYI#*KHxgs2Z3AhTY;%=;h2T}JO#hMsMLD$7$EzHA6?1P~= z#2n%4xv?bl=^ij2GiRFf%w^_ka}%n;tymfNnESC3>0UpId?;ILb^w^^=ag2(CGXFfLa_qLJTf z4nVdvfnf~1g z60O-K)RYFN`5i{0I*3EPhUr!=M6G!-R>zU32Pnn9xCUEbV7lLKE7Z~zViUd2jSr>Xx% zOh7G7NmJ%uQ}rMfy5TYGigQtGdk7OTpc$V^OvXGc#P&ED)zJHxjfYY9M`k(K3yU!c zmt#lVhHMj8nTvC=SvK>p%`}V(mfcN9X3wp`D)=pi<1zER)nBo4SdM>P3`TNYl9jVj zzYPnlT!fmb!KfL&8}++joJXP=cmmboEadl#TY#FnjaVJOLJjPwl_MFxu1`WOQHGUU zV+7?c7=``JyUYhr{mno5*LA5jfnFaw+W*GHiS))3WT3)Fzx z+4&yGe{K*z)Lt2O#+9f6pGF4YxxcI;m@TWN1)mngX(7-2I~EvMAD9m2eA-0qDFcZyJIKbEiK727=y2)zF;4khf!;P z1vRA+>`)E7HflgAsE#wtEY#*~jxqG_9wpIKzlfUBmDmo;{ z(@;-16V-7UhTuXgFGUUPP1I7ZNAT|FfcYKNK8$+L zkD?kphbQrG8=ck-92Hm{Hdl!nc)H9m|ZQTH83_O<6OkYrGi&bz0nD#4~W5gXug ztc5#Ko9YPa3D25AUHqksL+z1d)aJ^;WbBT*Z?v5+HD_S?-~S6pwDxbIUW@hScJlyg zCXS&-{wr#2FPT-k`sH}k_n{f;$qTU(7NPb?F=}9=Q2kBCM2}H=AFYCr}-_8+~KU#;ET~Tht!via}Up<&qm&f9>)+?Zi}62Tzy_Q4Oy( zw_!NtZ;-FEJBlG#x2Hew6jVoPSR3tGvX72GYj313E5)0On$dZzpptV(&^P5$QIg8U|TXFQTz zl9ayw-*Ej=o8?)Iz{RK;S#54Lzr{G}&za#j`yZzIs2S>kk$4MgfOny;pNi2qAEVG) zMN*yQLmZEv<5SqF$T`O5cB3|5d_RAWw83b~eeg0*HWc-m4eIYN!6T?OpN^WT=TQ%` z0zbxgFoXL_i}~wF@BfMt|HhwDBR+*0cm?@DxU>QOr*CsD8GAE+t5 zhA|j6$p4@upgK&&c+ADR*cY|LV^9N|V&&J+(+wL)v^zgRmG`37>=0^`oHDPPk%RpX zQ&3Nqj#}%M7>7Mj10ROEzZBKp)8>5C^(zN6{~Fl`R8+=2r~&M^3yxrO$`?`Zd-{;_ zZ;ZPGHQ-gK0c^7JRt%=R&-@zI?qSrY_!#QGlc?+d9OC)ORVp;KL3j95TNPD~wQ>UL z%hedwP$sH@Yz)LaY=>>I5KFN$ZpQ8yIMiQ~o~R`og$d|+mMlW8{RgNg`V2MlgQ&GW zg6jB`c^0)fe?v9cX_!CN#i$t_iEXhIlkr_l$FI$x;r`z6vPjfHPYlBTsE%*L5FBph z(WrqR>S!ivN*AHpc>{I-JE-e7V-W7ZO86OSPwYcx&~rbN1W|DUb;B9|g!>Dt zQPw|s1wfvD*l`p)Ql5zItbRE;Z>pO^JVN}7(A4W8bbL){%5^mOe_O1-{#RH>CG28( zXR`zKb;(nRedN*jGL9lf6TcIQgbqF3zEjaS-)>+ito7(jeP9*^(fJ;WILclQ!I ziC2k^#4Mr?7u6@UwuMB+v6&>6c!-#+O0Ibj^6?m+R~?7`Irn~ii(tv!JmNHQfT%_2 zxI%b;^5YMc?D!S0Ruu38v5feP2%^!KFa&k9BSsQs#Bao2BA9rE(9w*@BC?4p+>?xt z5uXr05YK4+b$m)BbHQb7O|Yrm2Sjh8;%LeFYZSDrw-UqcL^}1_h&rl~HzHmm=kxC7 z5`Pg75IT+%>xrj{7F^dX!0+FELB(03AEBcyCv_|$-Yw7ke|ojFoLjCdM3C<$ej)Z- z{d?G-C?JZht^^xe+X>S8ci|LPQ4Y0}i8z6BC!(>{k-9eI)0A**_bLBbho2{jHN=PI zHGFiq_ABx?2)#*Nt^ONRczyVB__~TA zTt_bX^+%c&F5=rn3!){FM=T*Kjz~*ZVq3)?2(y!eupW^`C+&$B$fpxe5%I*6 zgpS!nDG|msja0$$t&iJ#7VP*+b}v@^Nd; zP53hr!-YDUV<3K4UgDn@u&U+V@IK3H;@w0x*LNw~TdPLd54D24Ez~R~bj&0QIQ#GN z5`VCeM-V#B`M5J?Uu;9HB=U)aM0;WcQJIM4zEr%4m_fWwR2)SlKN2|s41C49%(?>u zLh~}Sb278C%W4<2E1Oafx^7p!K1nsRvYTe-G|kD%&U2*vN7}0Fxq7+liVI3p{|C`C B;7|Yn delta 6994 zcmYk=3w+P@9>?+T*k-n|8^&fCHp4cTFqhe8Hn~j<9hHqqq>EfCm!h9KMM9~m&_#!x z$|bo}N-d&vLWok4TdYo4gie$=ulIf*k4N7}AJ6ai`}_XBzwhn$`^!_?1NM9#;2n+* ze9n=21UT0a^Fy6mOa7iZs&%eSymN!FEnbI@V>p&!7_LR#SB`b@0IJ7-nEdf^*TB zgSDOK+(0s^RE)qVoM#P|pa!-M8)G>($0KG4(`1saE$VtdE04p@l;@bAq89TiY9;D4 za;^y`V+hZ8y~yZ6g=Ud?hdB{PaeX>!#>Y`hf7-lg1|~WeOnoG3i(;*ugleCPTDgum z8FSFn5^W%(8^1y|IEeM}IF{gL)Pswers_vy1N5*aE<&x`GOUO1peD2vYvDI$g?Sz| zpnxWUQlSSNKy`fF%0HnxI&048#@YTc{;{8>`_a)D~Bc*gS=L&_(10Z~@KyeiM;_doIP#xYno} zJ6bs()o}r8NpD3K!QG22iYqlYm<5kp_#HaY>EYw!qf;yaIP!sepL+}4=GLxv- zj11CsZ0_7rEXEq>TKFA>piX@f>I0H(^@SKjc`RzC_n{s*&75N{MonnBl{a7*&v)C% zXi4{?9(V}#fC|*>cG1dFE&V-D!U*a!FavMELY$5ra5w5K1f}|07lkz`*TV(@&LyG- z*d>is&;xsuQG-I%2!~=g-igIH376qls3o3~?hkZ<`4Vc2%1{G;57ll5R>z-EU&K?W ztx0a>uT;-gtiNs;K*bF>61BH0kdK<%g}ia@7wm{pt@&zUZ&XLKu`RAd-G2!CVNx4r zi4!pwOOa#YzQ%TV8FiN0v}OI-c6SrKuxf5PhT$6+if@~ntbV(d_gncGM$)d*%2!ao zf}z*@{UoARI1RPJ?NPr4*{HKJ$Rnc%79qbYZVYPaW?}>`MGb77l@FoXSE9D)l9hv* zR&C1B7=?|^c4iOM1Baj{R)R6;-AzV^%tMWQA*zGbs17%qyD^6HVbs9Rp*pPA-XBmH z>Uu2lpG)Nr^;d#>9=9fLUmyBMYBW4Av<5Q@^a{+bZMY|rv5m);#)Y3+w zmbQVFn_4*)_2KG(>Zc3pzHHQoD<8A<{`Vx4PsL2sNOxdwjNskUmfV7Ma5Cx(HrHH< z+WYOO8689o{72M)&Y&KA$@~j-I0HDz>aRaW@qBkX87=7~?20o{r+X{%s=5j@s*}IO zS*QmTqGmW0_23c=#yhP%9yPG3sI7bq^_)`FiY`M>9jzgw4mP50*ox|S7itFkP-o&B z)Dr$|*UzBZU$FYCSc`HHFZ=NT28&}U|K7!4(NUTHC-^PYfVO3_{@uuYO+`A^WBP+I zAGHDtQA@lLwbwh$eda;b0FIl#n3v4JEdP3h8Heg888zYbEY@F{3@S9!9Mmb!!(<$S z`fyA~CgI938jql6a1OOa0oncvrDFo+9Mr&yQ4<-1&GAWdJ?b_8-m?Z5ts*YR|5Rp} z<52@yfh}+k^5(fePy=Yy&CY~bXpTY+U@CrukD>NFFV}BB!1Qjn%oNn&nTu*zYUNi^ zADq`w9j?by_!06Ibt}62TXYaLpwrkI|HOwel~+pltw7GPdk5375?LwF#qsX7qM{Qf z;T;%@b5Vz>47DZe%x$PGJAgVH$FUw>z{VKX!@n;bbv@H8Ky6(y>i+Q8dw_YfqB>n3vfQ(gPAAN9v-=ai~+DV)c1_S${pC7Zq|C zs^k03Coq)qOUPH*y^g_n2y5U8RL7@Le>J;=TJo3zzn_+<*D)L0U=iwY&NIskSbtSi zQjv-Y{Wyr&8*ju%Q3LuC)o}&J;bmmCT`Y|@;&5aaU0i?Kv*aT%obm$${KNey@=NX3 zVmmy68Cc&d^bbpa)FHYJwGtD|S?0^AGqT>?iOncipjIe+pucsor~x)dwa>$7EW#)p zhY|P)PDJk+GPB794&tw2_!R2!9YGzE%NUJOgL$W!SrY0sOZI45-UnlFFlr)W za4Sy6H15kB;v64KH|A#lzSl5P@BeBtXW5f)q?PZ*NWK3LTE!gH-oIewH&Lhjebf?v zjM|bNs1M3f)Jpt}3HTevW6Usrk6WV#mSg3+Q0*T?9nP8PsiKsO_G}62kgPU0n|o0Y zJb{{7C2FrPVtouB?hiZ}b$=$RzkX&Bs{P%l!{?#;dwMwQuK_Hy24&cu@_VTFy%PIk z(-MEg<4^;bX60EJM0tU^7}fEsSRI$6X8ITc>dDvvWjm}OMMgr@g%CF zGpG*EV>P^l*?1ZAF>?g38qUDp_z7xDYTxE>SsGqPIoB*fPQUX!GMdqR)W}~%4WJD5 z;ML|j)Zu&=bp`@Q`b*sawWO)o6*I9hPQg@MY;HrHjdQ5}Yv1lq(5p{I4^F^fY-Z(j z)W9-Odzp)R&;ZnumY_Nsi@JX@s{ITM#5q_U=cCTV0@Mn=hJm;WY45qUcHu*;#f2>x zfGr87nLbso=uYyBi98zgu=*UFMocHTwJJ5|`m5wxVk3+rwET@JpFzE4$>e|K`BjNk zbs1EA?H3*22sehfK*UjBpEychNngXRl>eS|7Uo;Uhd9CVX?PDYmKZ?{Cq@x^Yep0K z_WY_ZS!+7Ip16+-9Z<{n6ET=j8b*9WoF&SMQepw|9Pu9UETNRjz1;|Hn^G(Cd>ma} zY>#@gGKedL_c(v_CzSRP=ZKm#3?m*TpMvX9dz(ZwApV|o$o3PBXs1*g-}19=t+^TX zR?M^V2J;u~zdj7Di8fXlKnIVJ&&4Nk3-KlKE}`@~aX*nlgxEvLR{e;{MZ~v6F42tZ zC6dq~{FG2yLiDW4vHt%gqZ6#uf*Y>)v+g@n+(ht0=7tdI#I-bw%o9YG4Me|mt0_NB zOd%?X8id|;rQO8Is+|ANdObXDXh%gyY=v(S%dNrFm__I{dy)8_SV%lV+)NB2))144 z>fApOe;}@<1nRD(k!18ino2xKJVfjz0?wCy92esSl2v+%XiPLwfz+1hL+B%1M(7iw zluy@9toxrSx3hdT@>hvOE5A&BE}_2@T}!WA%V43O_uSo9S;rc#pnM(qJgd(kzma?e z@o%g9kNG}+OngNo(JqjPBx(>%iCV+}uKh+dCGH@ur5DHy)mNa1%t5P-z)6K(na{0I&n(7SzRuRVurG7qD{|9=4ymm&ZqmO$HKO?%WzbU>rV10SR`H7_)8)mJ4E^BJa{{b|) B+p_=w diff --git a/locales/uk/LC_MESSAGES/messages.po b/locales/uk/LC_MESSAGES/messages.po index 131e6dc5d..d5a423b2a 100644 --- a/locales/uk/LC_MESSAGES/messages.po +++ b/locales/uk/LC_MESSAGES/messages.po @@ -9,8 +9,8 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-08-05 16:02+0000\n" -"Last-Translator: meowmeowmeowcat \n" +"PO-Revision-Date: 2021-08-05 16:12+0000\n" +"Last-Translator: Sviatoslav Sydorenko \n" "Language-Team: Ukrainian \n" "Language: uk\n" @@ -1520,7 +1520,7 @@ msgstr "1956741" #: ../source/guides/analyzing-pypi-package-downloads.rst:170 msgid "2018-01-01" -msgstr "2018-01-01" +msgstr "01.01.2018" #: ../source/guides/analyzing-pypi-package-downloads.rst:172 msgid "2344692" @@ -1528,7 +1528,7 @@ msgstr "2344692" #: ../source/guides/analyzing-pypi-package-downloads.rst:172 msgid "2017-12-01" -msgstr "" +msgstr "01.12.2017" #: ../source/guides/analyzing-pypi-package-downloads.rst:174 msgid "1730398" @@ -10045,7 +10045,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:405 msgid "Maintainer" -msgstr "Maintainer" +msgstr "Доглядач" #: ../source/specifications/core-metadata.rst:409 msgid "" From 886c76008b47b6fb4ac04202b5fc25a7d6137b2c Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Sun, 29 Aug 2021 18:15:41 +0200 Subject: [PATCH 0095/1072] Translated using Weblate (Chinese (Simplified)) Currently translated at 20.4% (465 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 17.5% (399 of 2271 strings) Translated using Weblate (Chinese (Traditional)) Currently translated at 2.8% (64 of 2271 strings) Translated using Weblate (Chinese (Simplified)) Currently translated at 17.9% (407 of 2271 strings) Translated using Weblate (Chinese (Simplified)) Currently translated at 17.3% (394 of 2271 strings) Translated using Weblate (Chinese (Traditional)) Currently translated at 2.5% (58 of 2271 strings) Translated using Weblate (Esperanto) Currently translated at 9.6% (220 of 2271 strings) Translated using Weblate (Chinese (Simplified)) Currently translated at 17.3% (393 of 2271 strings) Translated using Weblate (Chinese (Traditional)) Currently translated at 2.4% (55 of 2271 strings) Translated using Weblate (Ukrainian) Currently translated at 14.2% (324 of 2271 strings) Co-authored-by: meowmeowmeowcat Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/eo/ Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/pt_BR/ Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/uk/ Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hans/ Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hant/ Translation: pypa/packaging.python.org --- locales/eo/LC_MESSAGES/messages.mo | Bin 18024 -> 18402 bytes locales/eo/LC_MESSAGES/messages.po | 21 +-- locales/pt_BR/LC_MESSAGES/messages.mo | Bin 97978 -> 98038 bytes locales/pt_BR/LC_MESSAGES/messages.po | 6 +- locales/uk/LC_MESSAGES/messages.mo | Bin 25870 -> 25808 bytes locales/uk/LC_MESSAGES/messages.po | 6 +- locales/zh_Hans/LC_MESSAGES/messages.mo | Bin 59467 -> 79427 bytes locales/zh_Hans/LC_MESSAGES/messages.po | 223 +++++++++++++++--------- locales/zh_Hant/LC_MESSAGES/messages.mo | Bin 4208 -> 6020 bytes locales/zh_Hant/LC_MESSAGES/messages.po | 68 ++++---- 10 files changed, 189 insertions(+), 135 deletions(-) diff --git a/locales/eo/LC_MESSAGES/messages.mo b/locales/eo/LC_MESSAGES/messages.mo index bcc13fa9890f0d0244a853ce9e2191845afe716b..8bed3f0e5d9095d1c181a3e322c3f063c8065226 100644 GIT binary patch delta 5061 zcmb8ydsvp`0mt#1fdZZo&^)3bDj-J_51^?WHx!r(%*@F_1uZQQF~w%@vV*ClC|FUH z^AL)rmM|@Jrl_0CtW;dZoO!vfUDmc{U1M!&weRnJZnpm1o~z&cx$ozApPmQ1S>rW>x;23u0@^q zJodw**c;zNZ@lj4GB+vc2Dh*q-m!Z3aq0oqAk>B7=!0?A1oWhyY)!XLL)|YMX|tJQ z>q}7$S&4zhWz5s|Kt0lVvj=s-LF|vGkpE0OKYH-r?EZhEKXre)tMfxK2*=raE)Jl+ z2sHwa;XtfI4Q?}b=lP~p1$-CjylF@E=yQz2FHsK;z027jh3VAeP}i+Q9e*6vfhyz@ zQ-d0TMjVRGcrUi0o)b;0T)q^ND5xjXQ9Yf9>Pfk^8g;=z9Eq(s96v?%q!+`a2MtDc znJ`i?tQCIN!!z_yOwtKiT77q8k470LEVz`YpqaKvXk9(x-{tDDoR@?ecR0mF=rnCbYToXt|4Rl3O&lxt8Uvl}&{Cs8AM21D>$)Q|^L(e)8{P4E9C3b`I! zJj|HaIZzgA%wZhH5^upPcp0ll7_%K0^0a*PV*K>r1sH`JP;bvs)a&;SszEnw{ae%& z_6c`76pX$+--J`p>b@J*qhwou5Ou*C)FNAt8lhcw|7++&{WxmK&!QU8hPv)k?1mkv z*VjZi=l4M!4?>sT*9Z!_aT0dHY+KJo&216t0jtm(*V*Hnt@SvW{f(H4H!%gH=}iVM z!#q5O`tin+Ek4C}|H8lfK$K#?He?2gf9d)dM$*9%-Axl#|@riN1Xj!N!D8}ySLN#zB zs)5^)7sfQB-hxZ0p8gp%Vt1@w++5f9KsBhp%N9bdG1dgsg{i0>WLoo34bHdDx0ax8 z_yDShD{Oru`cZ$@?r*?e)Q_X??>bMxkHTftTKFTXXSY!&`0*ErZ-(iIYI!{Jkuy_K z=g&p;c)7I-hf;q9b=_Ii18<;){0mfvZX+Y-GG3#d9u2^;90)?4n1i}-9x{4nDXKv) z+T*)WH#&f7&=J%KTtvPx<|@v_+o%p@-R<1B2zB2j=%@F8H3iM>22_uBV{bf;d=ktB z48~iik@6qo+$aR~;7HWSq~kp}3$-Y#QH%CD)FQ7({juAJEHiTetMvZ2Q}D+{@y=^l ziE80fsD^Dr9Y2J+@hQ|uoI{Pk`=|zgWc>`)pxdYhcr&cJz6a{MA*c`6NObAKEDC)w zAGyX<;3#ZF&21a1r+>Bj@CQRf9EyBAO)_eV7GfaQU@-1MHSnDEBC0{{sPDzc;~4)i z3PZ*_Lz<47!x`8I=VB<9S!+=v@&*paOV}5`!n?5N1pe`g!%+>p7yIFA)P1&M1RlXG zygq^P=UNk!;Jm*jNGHt`sFt^&hVC?KRbN5%umcC6Z=$m%LQxGEgPNjgsF9tCn#%d8 zkzI!R!Zx59_Nt3QF@-Z&grg=pb5wCcij07w7D0SCoOoR$Mrxrf-N6?J}tJ$?w)&||3kUc@eX|F78{pP=UO3)BOA(wvs}LtQY` z8iiWD3CO8t71DO|E6hNTbmy<#bkrKyfqYEOVbpiv26n|;=*jcVR}_ZeZB&m2{?K_% zVo^PaM>Xgk)PM&0i%d%O)jsb52ufO&wp9^P$Tp&$cWytTu!fu_yGR>3LIx6^WqwR9lHZa8M5CueY+O%uD1+(nL;>mE;#>Hc29D$yB1} zySI(}Y6?2HGZbDVi%A^$DS4iBZYwB^AmL;usUh0lB;(vA=X()GIhyDd%q79(EEz`J zn|;2SPpz74a(27_0cwk86$Q=rcDrM)^-+A;miJrtT7}li&&Y%1aiZ-FavzCQh0S%p zqx*Aci*9PaSIMV5&(?p9(?~M8YWKa53&<>655gU!h&)5I81;>Lm-Hvv4if&Ly4)X! zE>wO)o*?g$5K>6Az2)Hk-SWM1G3Dvx65*rf{y$rAzY*P4u-g@UsI!6xRs0~3khHP|86zk z_<6f3ZM_}GlTvb-3@6(5Ihb->M$&BkI6h34kQlo!4_6Z(a?b9Hux8_6Tkd3z(?C97 z?D?JD`yB4JAt zk~EV9qAi`g>Ml7y{io5M8$Mz6Ivhy- z4OGuR#zA-$HK;y@M;#8A+~37e;GQl4)ssm$1~XANUTgbHa3=M~P#0*n*w5J9EQ5jChUQg=&2{qQ=oC~AgU)#W;^N!-{b8VPIuxl9o3Vis2ij!ne+|_&b{xb2##cjn7}fJL7>*ZE=e41Fegk!3 z?bMnGHp5YivOo65c+~mh?06=s;j^rsKalZ{VaGCd=m#aJ25iH0ticg@(e~d&ogd1C zQgjKJgws%~e+?#J8R|L>sPmh#J9eNtb`>?%UwITJQur42xTJ8lS~v&Qpe3jttVBMp zm@nOE2i_Vf+kXZ%mF-sl3e|y7PS%u8M+VK^k7{5E>bO@&A&nxA%6(<`}KGQ%W#3ub8ZD^ zHL&AUoO4I9Xt;AHF^;AFDYj!RHn0#1Fps;A#3QJurXBUzT}L$}gz?p)jYl;!&FY1y zsVqXRol*?r{%)ro*o$iEVboB*g}T96JAN5^QvU~PM6RRG54yvD;c(#ssDm_mu2u*IyzsqC-88Q6x|I5g3@TznAo@et~j8bCMcyo*LH-bvU4 zb5T<=AJyPRs1B`0y$?1gG5;YHwz5Mls>C4Nje08TQA2qJb-^!D=ikJh=u7qweHiL^ z9MEkgCE4Etam@li_^S?tiFep{`W&Zn6(9k5~6wE*^!eZ1a zeH44)7Svy@?WpI!3M;S)BXG_*|6^BxYT#;A!#1IgKZCmNKGaAY!Vo?GZ&FZ;Pn#{M z26dns@Hy%N-=KaNkmi5fLQ%gP)LPeILTA?iXKFcE9;Zu|iGxTp#K$96W-CbtsR@LJT!?ME%@lc)~1 zp&Ih#1jb*BB4nb!0RvETG#WLu>8QD!g^Ze8hP97~ z4nB>s_%dpwn^BANTaSVspMI14Z@fXMDOrH(!Fr5D5C4u;xX8yyOlJ6~x3FU6lg!7v zn3>7{f#|ZF+XHQ=hLucXdhjx8YJ#Wx8|DqB5W|jC)JV)lEuI3am!THpE*yxjU>G*p z{*O=%{R}lye?{HkYdhXO+rK6vP$M!Jb^aLSx}KXzK|_>-y6{re5U;TM!>F}Uin>7+ z>M5wR;|I)Rs73ic&cJSbQFOB~7t1jpTTxS+oTI-H%>QHxdcN17=6(|f;1(Q$TTwl# z$3Q%R>cMGLgU+FTcM0|WXh)4?%uIVKQ0I?FJsnd~*UQy$?(YgHFs1GZq7%!>UeZjS zB99TZ{1H-2INkk*Xw!|}B+JM=qAi}3khfK_?Sy&Wd;Nqo5YYj@)6M!FpFs89i;yMe|wK&i&Y2V zT~>Yrw~*CgSobOX)t-t!e?+QwRB-8f1ghga4`6+ptbZ)yTM08eiC}=fLsm_at z@}9HZ3ox6EwfcHYC-bc?x|1*xO+F!=o8A_6mi(4fk=0#Sg=Xkp zqOG1hd#mLC>TBg+n#mYPhFbkjb01D5iDVDCk7yfB{zOt$>9RHMk8JieZixOOvbsE> wxcY4NzZ(-1BLW(yj;!_tWQ, 2021. +# meowmeowmeowcat , 2021. msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-07-17 10:09+0000\n" -"Last-Translator: phlostically \n" +"PO-Revision-Date: 2021-08-06 05:45+0000\n" +"Last-Translator: meowmeowmeowcat \n" "Language-Team: Esperanto \n" "Language: eo\n" @@ -16,7 +17,7 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=n != 1;\n" -"X-Generator: Weblate 4.7.2-dev\n" +"X-Generator: Weblate 4.8-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -2165,7 +2166,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:245 msgid "url" -msgstr "" +msgstr "url" #: ../source/guides/distributing-packages-using-setuptools.rst:252 msgid "Give a homepage URL for your project." @@ -5939,19 +5940,19 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:170 msgid "``DISTUTILS_USE_SDK``" -msgstr "" +msgstr "``DISTUTILS_USE_SDK``" #: ../source/guides/supporting-windows-using-appveyor.rst:171 msgid "``MSSdk``" -msgstr "" +msgstr "``MSSdk``" #: ../source/guides/supporting-windows-using-appveyor.rst:172 msgid "``INCLUDE``" -msgstr "" +msgstr "``INCLUDE``" #: ../source/guides/supporting-windows-using-appveyor.rst:173 msgid "``LIB``" -msgstr "" +msgstr "``LIB``" #: ../source/guides/supporting-windows-using-appveyor.rst:175 msgid "" @@ -6075,7 +6076,7 @@ msgstr "" #: ../source/guides/tool-recommendations.rst:20 msgid ":ref:`pip`" -msgstr "" +msgstr ":ref:`pip`" #: ../source/guides/tool-recommendations.rst:22 msgid "`pip-tools `_" @@ -6083,7 +6084,7 @@ msgstr "" #: ../source/guides/tool-recommendations.rst:24 msgid "`Poetry `_" -msgstr "" +msgstr "`Poetry `_" #: ../source/guides/tool-recommendations.rst:27 msgid "Installation tool recommendations" diff --git a/locales/pt_BR/LC_MESSAGES/messages.mo b/locales/pt_BR/LC_MESSAGES/messages.mo index 416058d85676c57187b6978c35fdcab16573f551..43a06d1d2f6efd71ad76e11deea9b66e78cef4b6 100644 GIT binary patch delta 6785 zcmZwLd3+An8o=@AAV^RVYh-(qh$V^;TWjBGibfjgrU@msRAP--@>*+G4ArWwx2mj9r$ zYUUGLAp z)n+!njZcVgHzzOoZnO~DLi}DU<_dAw)-;CrRvVF5a9dlEwOFnl<3E9eFWWKxWNbk* zQi;cO5P1pDVpGyC|JcuhfpVvj?9C5b<+mP57MK%+slld`* zb`!aY6{)=kt|>`ArDYX;n>Cs3DF`&UJVU}vn1TX7UE zIEvas9bdQWxjP0D55b}6#ZmY>eu@L$5ZQo%y{xWraf|4`#1<|Vb?MC!fezQOh#RPb5Xn4 z8B5O)FTrBOYsQHf;?FUfc;k4HBKQM-iKj4>^9yt71>#M#Iv4{dF#aA+#7?jqLc&D5 zj2@wmssAKf^B@c%_F!3Tjt%fd)B?SzE&UkF;Re*@w+Bn(Av{SrCy~yRyeTYs^h~8D zI+@x|wKqsay|5R4!3F)W6LFPkHa!iu6AwVGQ1oHmKEt+jF;*hp zgfVy!7vNnl2inCGXW9a0qqbxr>SS4o+M+EOga@%Uod#?$;)%Jo2kOkTExdsq^8M+? zRp#5dR0A84KY(UxMOr(yVS}+caW>LJURln8X3RqxC07@+x!{mRRE+eN@3FlS&t5Fj z4o@TVNkZSJlDGtWV6zYGWSfh9i4&Hv?zw&=HYP5!ROAOKfq%cvyxuHN7$AN+I=LFNc_&fME;GZu>&snm`z7xBuQ4UVkKagPbj=7h2Rt7 zHEZZS{A4Z5l>6nZqh~2!=B_6*#^q^$Fm|Xd`WyYRD|b7MDX3!?$3B{b?NFEFVx%i& zIaa|u)MdRNb)UG1I{C(Lv~z4B>YQ4N-eDYk&Ov#M++=Um2>poLV`+Q=`(X<9!kt)@ z7KD7kI1)$X+sU*T4-@C(ar722*5vE4nRf%?oGrEj>09kw7_yc27II?m89{H7BPCa(piezF{(q~}>T#dSHcc51Edkn@q z=+Avh?6EyuZZ9i}bdQ$f+8~BawswP;1gx2VXov|2pb4|iB#IK-sZ9102Ow^&9h}w`v zs0FXZ0Nje2e=lmq4x>)mvq(O#T;V`x`CZhEk5PNT?6>KaQO7zGwSqCITXP+ZC%$}u zW2|t{zF4$Ht-yWE#;4eX{MmHlx5OL%W6zIcrqJ4#Q`Rim&T7tB3o$8;AqBR+xauZ3f9>OX9_nPS^3=X$#-VOd-B24i5dHB4QfKjA z;Gj4M$HYi~DsT!Th+8qBRWKF%<7m_iFQcxGo36!p5QGtjqb}R#SQdL=IQGFnoQS$w z7NAyeImYPv-{PJ)?|K6nCiw%k0_S=2)C(S>Zoy^zjBmEz#G%A@QO~CpH?n~Sj7IH| zntWqZfYe9bm{KqUGjKef!2+FqDQwK!NGQ#VoB9nN!(7ItFLp0&d~Zkvs6A1HpE(ZU zAe@d3c@@?dn4MUL_yH3l4o#r(ExQKjN8AGS>$n~EB>tU`j8w{(&Oyfa_4*l3CPNqA z4&K7=c-bGu`TDF$=AW!WU0x1rsS@$-V0wV~6y_3l2{BSgd=Ob-vOmoDKI>P88{Z2_ z>j>L`-%$616ps7(#a82-N+0wMq_Wx;~QDWzHBWce_~B+ zfF72JUYLYhu~ei?8H6Q>XV*5qA21f8KD>_6UHU2aBQ_Kb9ok(jz(W+@q@ zp7E{Qh&bbWs7$~YNiV>CoHh+?3-)7a;&Z4yas#X56V#rJil+kD5Th{*HGLtL$JMA6 z-Hy6S_If$+V@ErVI+;#0lXUs@Zftxn5ED@gT!z}>wYZ&%ZN?77S^PYrH{61ZhU~%+ z;!DrjA$o#!h{K*|8FD@WwL)+3J5MBfhj5^iX&&m>eu|6m8`Oed=XV+H@&Type*|g) zxu|ny3F`G5u`V7!ZNMYc`&DXTd>gW4oKK&@FsOS^H@$7JG{ zP&cU6s6CK}M{yhKdY|5kNrg?@*jYcntzCwL+u0W8pw6)mk*z`2BW;uX_F5s<-)|j^ z@69BtqmhPWtdBaj>8Nuc2j>#+?_}g4CU-WzUqHgU*nMHq3&!{Qeib)zzD|OXJ$Mll za3wc6g10dpcXYL@BB~qvhOU37yOD=@2z89UdWkuK#}bWf^QPTXrtYLH&|hjM`)C`x@VmSYM$ozncAQ*Vn-) z;+C$x@fz`zeyo3eIt@y~WYdx))TiC(OyhfB zUx3=ueW;W66xPF{S$5XPV^QKH)O{cYo1lY{co<9K9n||g@^WyC1AjL1RD6hsF?pEr zJ+C8&8{hMP7EUJp)e*+`S$+Y}P{Dp9ZOd9^8)?J&YNL&`#&pzzKSh1|T|!;1f1obk zfE?Q}Z*>mpaiiAw3@5V27-@-K)C+fEDLjFCgG=}acep30ld5R0wWMnq)W>cRYJLyu zR$I%p1!_YQQ43B--A9IFNnN119B9p^p>8zqp|*4x>ZHp@z41=exv<|&zl=K8H&H8i z*YOYTWM(^w{6EL}AUM@ba{dbLZ)P~Xt5!C1ot&!CX1uek>N?|fx`ZT{>CU2%8WpF} z_qr?SKlXIr;0|@Z4~Z}{o!>(``EhfZ;A zH7Un12s@$g-vpfJEDK98Bb;Bu;!UO#79MX#JBi^T!4o;RfLx*c4d!nYG4C0Y<4g^Y z@MF5mFlSA8Co|6ZJv_qyU1IIbkxp>L*dlKm=e>xvCd+B#$u!x{CQmanHUEw$`=bhJ o!~2aGnKdFaGh=vKnx{dNx^Z>m^84(4W!wKfvvu1TQ>57c0DI|1&Hw-a delta 6726 zcmXZg30M}@8o=@QkSGcoXrv(Er%0)U8|DV4;g%AnqPUf~qbT5(EAgSCCa(3RX*U#0 z%O%P!xAK}~?h9F#X4;}znUyU!b3yO_oijX-{^mV%X3lM&VX0!ZIYQWY-g!fHSeG5&0GO65ojy3B;ZC?R`rz zl=vIe`}_}Uig@Lr7?EHS9>Yr5&b6~^3hIseVig?frjK)-j1Q2W>z>bdUFf>Pb*<|= zuDcw)BBgG^Nz@9QbNvI19@i(MaS5&WWY_NS_=h;vw$SSmbl!=NX?)*uAO954aRp zYI-w~eORrz$Xq;uBd~WoX}Al$f!yd22Wv<;(?TSHc;e$Czu~(rDU|f0)*_k2b=!#C zCtlQ65m(dL^h%6$oS`T@J>gO zL^8(FjCA76<bW7`7(8b{CNf*r%(VD+B1q6wQZMa5olnzNj085I>P@8xsDs$os@; zWd0X}dWc*@e`@c+8_#$}YH$!jX__$xotk0*@rGXX1a3tg+v48Lbli-3-J_`@;h2Ec zF%7kaV^HT(DW1n;SP|Ft;TkHs8EX-L=Iv__uH$GD{L^f~*{B(&qOQbcs0D4pQ2Yc# z@B(`9SJYKftslz}!|@?(fI6qzp`IV)nt^ACy^}c5j9sX94b6ZDF$Z7*E9?vL;p-$Q07=FNIV_Kk?$h^tt0N9WxMcqx`#t4%^@9|j<@ky z)H&0U?$9CWfjV^0q7KPKtU>v*jDyO!P80B5^k6C0$IJK>22A7z6x<6}6KBv(C0KDX zn+fSVP=_*res717=!`jP1u}3P`JTsg{C+CEsAHNmod5@7Lu@z0UYLQ}f=Q^$FAueg z=gg#Mhzqd-@v2M)di#^1w<@O--=B+RnQ z=ql=%-a@Up-)!~(48{lXF>H>Bs0HSrw$z6qxCV9kZN(tmgI`e2A*A!9sDRB3gXdBc zolMQyAN2-LqF$JS+qj@Fb|ns&Z_|6?UgG|!6{_)~y-^d?xEEI8x-8WDPFrAGIv*b< zUW+lf8(+ptUJkU2CluNOa#1T%fI3;0p|NUFb=h6GO-aB zVFVt*NAU;L`&3q^;{q(h&|;CN@hT>9LHt_Amw3t>Oej2popJV?A}2LQl4Qj?mN2$iFS6wU-XHJ| z@v4n94wr9YnR34|o9#-Fymv&pal%ug{lVCww&)sG#&+E89Ck$=I}iJ4D#oKO$N5NC z$`Y)FMX1YqC(<@Kg*y4Nw%9pVfFZ<-&^wWX)g08okgfJcG3Za+0)wzEj>N9`9G2h% zv>k*!ENhLb)Mb?aS$x@eQu%-l_?czhQVGA^ui-AAI(~~CKel6C|Deqm>)Hx+Y&)Xfcp&PK zjd7iV+TuAFjOS5%@)~Lnc|$(2V-k)!=Jl`wHgJu@s>IDvFX(_F*bQ~a2B9_}2ese= ztb#A0=6@ZvV(U>S>kia>A0U(4D@QocjAu|=e!-rQKTyZ`4pzeZs9SQSL(F{Qy@%QD z@Hb?FOT-a-;}fWp@;tU8e=oZ61o47n_Iw&Mv?1|utf}j5F$d8ktVbQIqo`eV8MWZQ zUGKV9;BJAW2cfpK7HYm|*I3kw$GhiSxhA=$xb|0dy$^R2vR$XU7NFjEsq3q#J+;Pl z18PBAUEg=zxWvuXNx=&VB`19Q3_l z$L3=k!Ubixh4f|@?Yr9d7)p)Xeq$e-J-@RLrOT+#j=7ilHX#28SJ;e*gMY9Ed#J&S zwV=>H?edHHi;8nT5r4uW+`##Hf7^nZ{39}oIN+vz2<80C93oEh-eQO2VAyT@uDAG( z-MhEpNp5ruFX76&b{S4Bw_iAOQRl+Yd-gG%i8YD;#7L}i-)>9|P#f40D`N>#XW50i z9KD;wNCp+yigic`V?b+R8_dAos2A=E3u6a5*O5!f)uIB!NvP?1F-gv!m8T{VI;cG}4dragmPosv9Zxa$+_Ib1<5> zg5mgfsBzv>16h;IKgmN~URkUq-RoZqqX&q$VjgjHZ6oExZy+m7iX)BlIX@%HI4>gM zb!-EUqE@V#$2ePfB6@Y~dT`*u5vW}{7d2xM>f>_*>R5k(b@4p*!#k*-=c#p#^YmO) z&&XlY+e8}~Pr9jZhhSoialVS@qt1nIQRl|>7{0$2kg=SEp*Wv!V;%dS8yLBXehrQD zHhUZO!Z?ceXj-KC#!?_q1=193L}HnR7~eWY{btH$*I z5E5=RG0sC}U{fPcb7Bb|B>h4&+k)ce#(8SJkJ=-p_z0dweHz}y1gsWsoM%aQ)bwnu zf%&KveFb%uypH~CXzzGA(8;uonWW1vp`~$N90p+!@l@0n7vNqhwiI>C?oPk!4VNLK zASBnR46w@^2Zz$c9J z#?lCNhssCof%$kEUq)T;!`d^cu=%3(LbZkRhO)jKQq`3!GS( z&a%^lA$A?-4>isQNZc^v{1BOseaKgRxSb0bs9!J>P*=me5ytuPY8C48^BZZqz7p0W zuH~A5Jeg%M>RWTCQLKNR#p$E$y3fE|;(XMxD@UDt)p$brV=dIl8HL&tv6zXkVH6ee zA8n+7xc(SBmp0-R;v>idR!TCB^GEOScpXR-dZ0>RmKo!3G(Er~;Y+V##c&U^Ye z)RwMBX02?+CU_Bb)>j>GA5L+o`#>{ng;`h^*JA)4M!ioN{(_gi9Het_nhpIpHkoLg z=k*=b=l{q_JR2~6vT;7gcj0*|*#3FjvaqQ}p5**J?0_An*@9=GKK=HfF4t42%l8Uu z!(=)Q;6C1P4yqA%pJC()9DsV^N({sjd<^&CH+U6!xsgLN?eg54Yx5m&J&C$6oJYOy z4b&mK?;7-i-EqT^A@<4)4s>H!h}uOvQHNwd>SQ|XdcyTn)W_`?sQIs;Zn3|*nmpTp zP}G7Oq3$28Q1d6DRxBAS>R=7zK)Yxt>SUXWnsF9tR~5SH>rh`n-bJn8HeXm+SF_MJ zl>Zm`Hio5}S-#5Q8RkXbgz%bXv2Q_mw8{0Agl{%^z5%t9&3xbb+K-0LqtkUa&_DKa zXHduczN=lwEby6#uKu(_=J-+~=9sy@Pb1>}XA>9tDo3VPW}xIES55SdjBFLcFbF%K z^T#BXrM{BLWHZTkD>B|>`{JVF%~apesM=xqoO_vE5&Rp=Kjw||BjPmQ@~ArgSws_j zd!o9UnLbmePUR)U+L@Dm4eQM0`Q&@6&L)%N>*dKYQ+x+J38r9sxo7Iy?S-XjyWjq2 HhNM?fbp diff --git a/locales/pt_BR/LC_MESSAGES/messages.po b/locales/pt_BR/LC_MESSAGES/messages.po index 71954ce7d..73b43d178 100644 --- a/locales/pt_BR/LC_MESSAGES/messages.po +++ b/locales/pt_BR/LC_MESSAGES/messages.po @@ -8,8 +8,8 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-08-06 05:45+0000\n" -"Last-Translator: Rafael Fontenelle \n" +"PO-Revision-Date: 2021-08-13 22:32+0000\n" +"Last-Translator: meowmeowmeowcat \n" "Language-Team: Portuguese (Brazil) \n" "Language: pt_BR\n" @@ -4961,7 +4961,7 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:25 msgid "``setuptools`` 27.0.0" -msgstr "" +msgstr "``setuptools`` 27.0.0" #: ../source/guides/migrating-to-pypi-org.rst:26 msgid "Python 2.7.13 (``distutils`` update)" diff --git a/locales/uk/LC_MESSAGES/messages.mo b/locales/uk/LC_MESSAGES/messages.mo index 275db5ba35d910d84969e5932ab4f8f91844f1e7..fc76dea47295dcb9635150adea0bc0acd100e2b5 100644 GIT binary patch delta 6994 zcmYk=3w+P@9>?+T*k%l~jbXD4n_-)~4P!H#+$M&OiZO|FkxS)L^pjI0l$r`%bZ{z{ zgjGr{qI5!tQjuG;I$;qyO^Ne*@Aui`(f85E^ZWh&zQ6D9d;9(V^3?8t1D^+Y$0Gut zbEIAY&NafE8qRGZe{WsYI@dPFxgppNZ@|Z~Ca%U%+=RNX80+B?RJ#jUAH%p<2NSUx zb~bzXdae%{p6Lde!_9H#WOJrD57p7L7=p{qRalksdW^)4$baq={%DS;Fcm{$or}Os ztnEDK29rsmVl;;1B5SY$HL%Ut1dFi+o-jk0CX;mSP}c`oc_Mb9yukbvwV2mYD^a(x zb4@V;LwLUHLq-qEGe?+rnp1Er*Jq(-T!LEqb7r|280TCt^>t8NRNu<+sP;*yl}p2E zn2Da2XbTzL_!X+bQEY%ESb$ei56)+rsvn09(ZlMv47GBrFbdy6O=vIH!f(t{^Ac)6 z0ZmzdHK@gUs3HcncZnE;>8J-}p$5<&)$vf&UXMcEKgOJFdZ-C4LbYFlwQ+^H!7Og- z`5o+~LJv5C>bS(pKcPChVCCOY19Hury9H_>lW}8E^^c<_@HFayt5939+1!R|x7R%E zS>~j9#=LA^!#}wpB;H@4zyyCrbx=zlgW9qb)CzX8>shG7mTTpFbG&&!YQo+lmYHWR zMvZV8YUZmj5Z9V-p_cS*tb*H6Td>1CfSU1f^DOE?<;V-*0-F2%#vuduT%wS#5M^Ufib<~!`B>LsHtMDt-5>HR@2fD<33AIJ5Q3HPu)ou?~#h*}L#IvZa zNoeh_RPWZTzit>r#f>-ywYO`LkDA+uym9UqOvCUte6_GIs-yYX4%eaXKZXM^zAdxF zDVT+Y$gyx=V+Xv7I!kTavHonkyO~~CH8%@G@eQnjZ=2h!ez%nmTlo~$pj_os17!uI^1sV$4JV@Q3Jb(>aa>je?XzA z>-CZUToQk%zXHt0si*;OMGfFHzwEh#Wc2!+FiTM#pG6&>%cvX6?RpSLTPpS<&i)d2 zM?D}9HN)Yk2Nz&4-eu)UsDaHuZRKOA=MOdslx&$EN$A;I~i%+Lg}w_aO5%6)70S^oL*$ zY6X^}mUt^_ulJaT%%i9Ql$gJmSIoff{`D|38r4q%YQibqS$}0xsnAR_QKvW?6L1*n z!!Zk)gjNIM$naMv1!E~^q6U_an#g!;flr!6sMq{^&l;3lMRcbBsZ2E| zp$4)RTjBxa&2xXC2GF{Poe49~9E%#j4EzWmL+yEXmfwDm>D^(O>8QiA5Y@2I%CDk6 zIIp8REW)$+5%LvvYkT@zbQCq9bJzy|#78iRS4#J-Mb5E%2a~Z3St-v&^X|2#qBF+h zomd|iq7Kt))Rt^EccHfI2ASjZCyU<{z(|7_kTu3h947i z8EPfgphmtCb^1Rrzc5dr-s4|UGY`JeKST9U4{C@SSTgE?+1MC!aWUSD={(>4MWz9E z>Fw|FU~EKrChEb<%ynk5x!*j6TA@p3wLX412EPknJ5XC#y`MjTdZ>YS!iwMjeq_{O zFlxz0niH`e<=N)*=6civcbJFGGpO&$HPjgj>F<9>>Y>Wfs8gS4_1XPde?6cN6>=o1 z;|I(qum0R>RY%j?ba~YIX&+gOyb0%^2J|JW<5G;qtH^4*`ZU^#qmW&6(F1AEl8?rklph@AAMQEGFSXl* z9q=@!VgoPFKP&@Lhv;_HN=!EAnJ=TxNRhc0n^P`Dtx(Ou{?^q;4X_2OeKtnm2n@%G z7>1AH6!e}UGoMW05dIp5PoWOq3DhCEiV+w-ly{n$#iL%cxPSOt&=a-i{V)=Tq9!sP zcj7cm=Dze{&hfEy<8SfrdkyR8{og<)nG4%cABc0PPi_3I{$7tlejeO7jK`H2il3nd zdI+`j7qA(o-R7V2;nE2=!Av}inn2WW{oRrM?@UG=+>LCj+k|m=9kVcQgum3c zV+YFfQ3EN)MEn6;VU2u$V4YA~l4a&v{V*$!vGRRbNALebRVt9;wGuyLEdGWu7&+44<2I;)Wm@@eRQrcehjT7^swgC*JzIe~Bpb}_=0Vg0 zPorj5hT7|LY=AXK`2$Zt-Jg!?Z-6-h)&3sT;qy@aJw1x`*8rAUgVorP@_VTFy$t(f zvjTs_6Hx=0Y2|qsM0tt19M$owSQXcxX8IdDvvx;v~OMMap@eHb? z^QaCkVHLcB8F&?QFnu(y8qUVP_z7xDYTxc}Su);0Im;|SPQUX!GMdq1)W}~%4PZ6u z!5hrYsKfa#>I?*q@t3+GYDtr@8>V9uoQ_Gj+}wpa8y8Xi*S^D_px1zm9vq9o*xbq~ zsDY)T_A(3gph2i5EkJcN0d@a0RQuT&hzqbPE=HY+C8!mA4FhpK(%y5M?81jwiwiq2 z09z4CbA2ja(Y@rC6WKKAW%ZdjlbA(tYej0o^;gNY!p0a)X!)B^K973K63G9`^D7do z>Qbrr+Ali35pFzjnTV#o0dbPNlD>xBDE~d_EG)K)4{@^Plkr|+0x_BxMT{l%){G-^ z?D-X6vNm+up17Y2olwj76ET!f8cBRZTp)^xLShN=9Pu9UETNRdy*&tRn^J4?d>map z?1*}^Qi*GX_c(tHB$N&j7m4aL3?=4}PsGiry^SXt5`RxRWQU2yv{R~$Z~0lb$=r^5 zD;8OKi}{Q8zcqz6L|dy2po7QAXW^5$gZPqom#9n+kVzy$?4hckuRlo3h;NB3qB++K zB%wq2DWSB2=v|Rx{r^cuCs?T^H?;S&?mJW5Oz=bIh7l=5WtvCk38K3VM89+!C_h3> zC(4Lwgx+MGM1GWsCRARZzfCJqt-mkK|Qj`RY_D!oKBA)2Z{YDe@V^buZ7=o6xp zL)T5M`=2RyuzVHr*NHeQzf681p}!MVrdKL6nCIs`caK%pwT5dc-#|Xw>NCl2C0|PX z+v@&fzKRY>x=2hx{ zCxVID#5+V0kKu?p`&M2i3k;H4nXGD*pn`6cW6zyvCY+T`|joKGI*L_Cf{{eo} B+s6O^ delta 7067 zcmYk=3w+2`AII^t*~W(1X3bo7bs5{R3x=7?43SHkY`P#Mm-HafivE;Js!@w_NpgEq ziFnGTlBYs$6;F|hN_og7w^9QzJczpQDBgg96x1#jYheyXU>~fE zgUu1Xo*PSsG2MgaV`iy2&s=7%HaDR<+=^9jkGUT!QT`rl;!ntb?hk%6!ss~XT463m zInTNAWWuR<9MkXxjKnSF4V>GDn&44P!n4>Iqj*f2i#)s=hPpo0%1f{f<;~`ws71|6 z@K>Z8CNsV(CZi{K7&XvzbCx;ZT#k2heGRI8OrpO931*s^gCWkj&Zw>GVdWy!mJLL$ z+$i)Wkr_`$OLPKtV`Uyg4Z<-NV{kAwM-4pN>gQo?%4;zcccWHrKgQs3)B|0^>KK;n z8*4U7X8kpz7FN*_Rql=2yW21r??VkR0X2a~P#r&s+Uw_01I#s-nQKuGv<20EJ8G-< znLld%RdJRIb#M(eK=t~5$1$jK9aKm4t(=OQP&O809`cZGuGMcqJ-|n({`aG{;;4BZ zb^kTbGNBFpikfDenPO(*Wp2nttx!%w|A{)Imb^EXzh0>8BkcMF)a&P2dA7O0^j473 z6TWS3GC#)hJw-kFehk7x<`LAA9>YL9k6OXs%}R~@Cyq4ZQRAc`FM?} zGl!s-YLt~Hp*r?ZOZqIb2<}y6@!U4^gc+XVzm8d`E$MCLv8b(h26Z?WV5r{zwPadR z@jgz(3&=ybQH`Bjg0rzQW;gLW&PAR2B8lA!aB|T zFJe4uYl@q({#vSssL&0MVON}s+S@~zfC0_38p^HzVw%Ar|)yJ(D{U80pU zQNIoItXzm%sX?d}z6bTYV4O!rEARwrz*)%e7qApqrPAtnuk$) ze+9Lq;ha!Syf$h=$*6(T%?#AxY=O~??;a(irG62$q${x`l~Gu1Aft4LvRCelqIlCsYTgQ8!#fbsWH-F?xa!)I`Hj zOIQzeJsH(L#p<)LI_1{*Qvk0dj-i~I>#yib7(@9;F6*xuU815RR^hRmVs|XWNvIXr zg<9g%sJ*^whUEF>aMT21%p^12%rW!LUS@F~>#q)nQlTdwZB9Tv@f6fjPs4^d2lWAY z58L7qjKVk$kRBuhwN)KZD>WM9a0+UI3s4WV0vqF}o@LIV-uF5k{06O1-CU7rm!VjCX%%!LatjEpx5o+tbX`TEVO3fwayQo976V-69l@Fud z^P{K^&*4e@8~M7rif_f_2dOu2@6qYqzE;!QK<2zVS-0yCYjmzI`Sg8+;0A- zcoJ%lXJb9wgc|sO`HOkktbU_^Jpr{snPwMr03HnBRYYxJw;rs20+~WGn)&@$8E2px z%tkHgLUR?~KzXzIrFjB1pu5R8+H8#auCzm)p{^K&g;p-UiT&3pzuPWMLk;kRxe(Ry zT5}tQQT_(`I=iD7f^~cP6Hi7Bl!~=62essVQT>cSow3QN!#ckw>#x(fiwb$!OzY*p z$G0ONLH8u~#x1ChYEV$e^|21NMRvj6ikt9dWH()LAKJ6zuV6LG>u&ZB_ZH+gxjW;L z$tIKB*Z&)?KkBeNi{ZE!wIZv{t>(8FOZ_=B>=ysSR3EiMJum`qMNM!xs{J&K!uc49 z-YPOR$b5+7@pF6%^9!A0Zf-Z~@Wu7>&q!O0qTB~B^JGI%ui3!<{uWF{?fDGUNMdD@4e$r7iov(} z6OBYIeKV|&51felvPf!h18tb7vndj5f0 z;%gX^L8%)$2977MThJL6{Tj)6n`E$NBcvQZe1o@bdwsJ;IH^+cbcW_}R0 z*GEtTpEA#)4(D&E4)cflOI?Io(UI5=OE3xF#Weid3>xO24KIU?2Iz@F*dI0U?HGc? ztUMYuu?eWX^iTtpqLy?Ks-HJd_rHT`zZrvY2Ufz*P-kKvvVxxbnM@EBCr~$>@h`Z) zusUV^lUD%b=!d1F*opE)Y;X0;$@8YVImA@rUxb!k525rmp(R&p@c+KpfBmnpQYGwS z`OaoX>g$qECian!!k2LrF`D?DNFbE-bdQ(k{BOLnO=y1?*1!PbBl2d>e@p}j32D$-^$F~q~fWL47UA;`sJcwTiR{d4XE_!hyIyLrTE;s8;L zP`W~RfAZrGl`Q>=S1Ss5fmlX-Mg-C6OBjMm?TL{@8Sxvjmk1_aA(WaE8AK*gm3xx# zG2#>A2jUs+ztX2f5)Ce68-hdaJ|KD%6{!{1uTjvc-bxI!3u)BrASzWS--vjPJfC+r zm-vf#kWe~KtS6o(TGFn0fIq(bf{L?5KSHS;7nK$f@0REMe|oiSIk#R{2q(Xr_=VVS z_3vSSB9ADtx?*f-eaA~1--S_FMY*zFOuz}0^NGe*N7l6^KV2EpcAxT}b@+LbSVMeR zUc*O+wqKEdgV3AQ)#|@7h1Z84hp(#`O#V6IeXDDXPY{W8)&z%JeM4+u`T1rW+B`~r z3h@Y`hwDMa5=!-nXUlW^RYhBp=TgZmwaR2%NHnERpWn__UyJgM zNkVBhQ9^{$rjaU0-}<;+c!-!pY$Wt2==Es>g?|$IL#%xK0y68!{(~4xj3X`)1Bf6Z zpX;|^6cI*Lq!VN!xpouwB&HEx64j`C6P210S;P(%NdF<~5-$=Fw5vLp%pO81(#Nee zH{s7jG!2znU?6^1UgDn@u$tw&;r*7s0q-F)Y2T%6Z>^eTKhz5HwotQ}P%0(zxccw% z5`VCe4=0q)`M5J?Uu;XPByx#^L\n" +"PO-Revision-Date: 2021-08-05 16:13+0000\n" +"Last-Translator: meowmeowmeowcat \n" "Language-Team: Ukrainian \n" "Language: uk\n" @@ -1520,7 +1520,7 @@ msgstr "1956741" #: ../source/guides/analyzing-pypi-package-downloads.rst:170 msgid "2018-01-01" -msgstr "01.01.2018" +msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:172 msgid "2344692" diff --git a/locales/zh_Hans/LC_MESSAGES/messages.mo b/locales/zh_Hans/LC_MESSAGES/messages.mo index 888f61a1cfb0582f984dce4602476cfbeb7899f4..8156b7fb3c20c939b5b4edaaaa84b685f107d802 100644 GIT binary patch delta 27268 zcmb`O34D~r-T0qycp`$L2#P+Ua%i&Q7Q>-j3JQpFs6}O$WRt9Hc9-1^AzHiPNC=Q{ zxZH=_hYAU>oH?M@YHh7&_0_hvwwm1}*0;9R*S2r1{eOQmv&*8k|M%Jtlkdzt&oj@= zZ+`Qe-^??-@Jo5=ZO3^lyNa6FWP zrofBf!zRDL&=1>^Ut+F5VOU|f+Hi~EKEor1jfxS=df8Pk0g6dl~jO91an(br*E-erpDi%V0Sasc(R*;c+;KZW(`zF6hZj z#7DXkJ^)J{mUTV%y-ELk06&8^`9JGtS#Oj6yuW3Qg+Cr(S#j8LAZ1HFY=qT=kbgOm zdj?xp9()u29S)(Rx4}WTTGlWMd>bwz-RU;Vx)-j2|A0;KL17Lrh9ibq7PnfDLi*NP z2PeUO@O$t-;20Pl&NJ}jaQc5cFW5T5vOXqbk)8v)!wF*}TJ(9yNm^0@rO)4hqI~bc z^I((7{~eUB`V3wL&l{(C9dwc&3PndYn*5!x8|iu|FMJ2eX!rx13D1k%X<40#%!XIO zFqC1k-0)dwlm0Qh1b%Gz7ubdLd3R}@xf)7^Z-a8*IFp_V-y%H=%KZbzYsuUNe@Hqq zlSq3a_5^)HFNoe*!(dyO4}I`4DC73$a1s0?oR?u)#mHM){K-AK;{O4q@4HOYlDi2? z7iAjW3NuNMhO{AK`H9GIIBxi&;oEQ@`5(brxExJ71BXr4E&UsOi1hhrWC*(8Quq!$ z0cTCIEFQJG-e*~bFb}rESD{Gi#QpMK`u_zYVKUx=H^IB6qA;)sO3QY@GFtj9+(Y`7 z>AGca!Ug2N2WOD~od+;d@Gx9Pen%AQGSVBVr57H6yu#}C9m@(rFYFxQ#t(>y1pbId zEQeBxJWvI9bN#RIEz(avN~Pf3S(e2Rw?2R(+D=a0=T}3KSYLP;z6nLy7P+(pH^LsI zC(PF66u`*kWV}Pkncg{uJ@Fv(7x}X%e9QJ}cpbcM!H^NqkI$0g_xQ~iI z0G}pZiZ9Uo$b%ZFsbtk+Yu7G{uA=nCk?xFvmB=W*zx@Dv0=)QdbcBDd&LK&7t z^hZ0m7~TMv!Zz?AlnNe#^WhI5Wn07OrzqS5rGmHl&>uJz-UGjai{af7zh!-w$m{Sj zI5D7=ZWa{D6v9j4JU9SWz>DE2C@+2yo)6zO=?`EB(tm_O_!X3v&z-AvEDEn7y%Y9> zkuyZ3z&}7K=u0RsZpYI{kicb7MEGJzU%!N*A|k#5);f)*bCkV#YE4C zHe3%8l64YF%WiqxvOa`4P+r{Q30?8=P;_S+lyc_7j=bO6Mnqat17+Af53hpnKvAOK z!)0(Gih|x)m!PpT;CG=Y)6bxcj_baswL2GXCtU>_U=}Z7Bw8QChv|ZQ%d{(ZU;+J~ z;KD~lM!}yfMAY2SVUadOT~N{c$lngv!9T$oxU}4|{sxCuVCT7i&=Slo=?Rru#LvJT zq+f#QwN<#3Yw$hDqgGE^gI-$ummz;?S-0g(FmN{<3@@$Hq8bM;B<+Fk!4MQlO{_-D za2D(am&5bm9{4Cc0HrG~UZHiTJM2ulCzP%l1Vz&ORv?m&MC!?qzW)i#f^WbM@GIzs z7q7IeN8nu8mKMJb(KG93tF-Riv)Zy=Azc99f&-tTkGbzW`tK9cS!+y1)@oho344(5 zh!FWZk%>@hbT@LAarr2emac?1!<|r+=2dt#{2YpMc3Mw2z%KAMI0;@4mq1bCXP}gG z1b!dB2&cn}4S3ct@;(t6zgZipEj6AE?DDkcs?8nMOW^GBHAgi8}vy&6|RIGNk6sUviidvu#1fUpAnIo zwLlU5!_R2ttA;tG55rOL6IcQr&*~TNg;$Y20;NK)z)Rt8p-A+PCcoEnxNoF~!{5O3 z5XX05GwjOytHF7VCwNmW{V#nqgvbT(5hw-cL#c=lwu51K2`q)3;S%^T+z3T!zkprfMTfNV zT?eINqo9;K8A`<;fak${*b^2VLjH2&Dl#sFTcJF#4~j?+nf#ZaX!{#*9DEx}MY|u? z73&F)(#QRvh(3NqcU||G)`97e5o!71gRsp}J;%&Eiu^AkBcBXWmbtJKTn?{V-scTC^k0ZIe9K)HUE;SCWJaTwlaIM(o9!|xcn4FiTx z7*;^3*lNR#P$ap-@L4Doh#8(RjMSUR87MV-!SFT1pF`=pCYT97gQ5fWaXriiz$K)o z!0YLP_n?&XpC_=Uq}!ilh{88cY29dBubtDI;6Knm>s=zJdEi~9s(awNMuraj5HjCb zZ*!6EwjMg8U8{?}&&VJhhOff+;gj&$=NV4CsLv1dta--^y1cjHhg`RRs28JcU)00) zJ~&Fo|6@c%2@k;0@D!W}zl6hK=p}3fJOnFw!Qvn3)$1h;>Kn=b6O`w>{zNZ4ZiKg! zejkdqU-ODKy*EHfH^Bh>9h}Vjt%rZAz1ioW7?gJme-A}6=hMt9;7d?m_&#*QjMwyw z3*g11!%+IT49bfZL$UqKVF&oMNk0c4C4Cx3lfb$FC{$!UIQmVF}aUHd7uJH zfpI7W{sl^f+rOdjyB11CbKrGw3Y7Z-@KX3B><+7;ym$W_$X_D0CgV7)Bi#t)f%$Lh z0xBVTWUV#n$#3cFGoelX94IZXf^*<1*adzG=fckP-yFJb5tR3R`nIm<7jGkfsbPnA z^o4FvwAVJg1@)8WYyM4h?7O<$&*60P{{{=;eeWR! zSQjB8503x2UL1Y_D@jlI1=}U?Ehsg9`Iow)ufzGI--mtS^!N2*H3Bar9fKZP+6Wnm zR_|Zy=YI`l&nOP>B!9$j^y)aWn8+wDya_Mk!sUz=8D72MBX9-Gho8V}xNqu5`bB{z zoD=dNhoX!Z#c46u1Mm=OyIC({--Hg*BU^L>iVPozJ7oMXA+n1b`nGD(z6uYM{t()5 z&BvCN3y(qRs&2p2>;oH?!Rj#`V3x7de-kX=Rm1I3G7Wv7n}5fPqpMuL778-3Maz^l!^@ggVv$@pj5aN zO1UfHg);s(6Bz{ez#RAsC^f#~k9xchf^?hp5Uhkl|D<2|JnTsNZ78PqBX}w4_MhuM zzXFOxt}*FpP_EB}(q(gC#6#pwB75O5G)_eGAv^@zeW889V^Cgf{Tbr|mO^RCMSsyR zvZ1uRH@pyzf&<|_P$U+CePI>s1dp5iAN>XS%MEXnF%SM0iiLaduezpBLU~a&>;ref zuJET&Mnw}8QT`5YKmvb;!%46Do1P6{g)*Gqfk)tP;2;?NQuF06k-rr9cQT~qSNvVK zH8B!Vytu7_8`7hx~>K9qvnW@ugn+mh}Kr2<-(p+_?%~2PHiec7s!)+*brU!^dGYtb*Tz-P>g- z`>_$uApK`J22O6Dp_X`0K_nirUM6yw3m?NXa0{!DY4BlIqOyr}7!D)-qYE!nLF)Hd8v_IIw9@qhlM z8P-NF+yIMUBb1un(n+WN@G;WAf=|Hloimif@k1!Xbu_gQop=(8NH@ZF;dUs)ZT{uD zODmx$^D!v-uRz&ofQw=`T=yF)R(;wKBZ|2ax^< zN`Y5itt;{syp426CI(T?@h}t4g1uoCl!hFIZQ*P@q(6t$s3syoIEgwUSq}BJj4CS(Qx3vyD0&k@uZ^B2oeqm3Pk8}ZSAbt7< z-SQ`H%uo)^)i<&KI*JRA-=v320~AB?5%j@zEaK+4odC?NXD3k_lgVN#}DEA#Vd;!vx z5$g>iW4UnYKt1fH!3m@{!0GTqD3iv}L0YLMzzayvg;Mb2P?T$-VFi@Yunb-XH^7PT zIVckRi{T}MMOhhtJ&8!o?uAnD!%%AOhSI_?ycRxT@;5>0yJw)>AA=&w1}LKaDU=F* z2=9amC>6~bqANBSqDpGFMc%J|lgJT`m0>v9ee+P9TFua_EdgV=?|MTRZEjBHzic8tct7C^uJ0i<5&zI!lW{qT(20B|6ZLg@Ka}4e zHPqi>{JoTX_5NBCeF;yhOZd@T7-Qn%0?i>U(_1whNs!+`cnxe1zYFh%Yv52qfFPDh z#^Ch?nF1f-I(~s#c}#(B0>6lOu-0dUzY&&^*#c|fTqwVp#HZ<~T6;_MuO__=iXk{o zIA-!*gKwGmD4ucS`D2M!2+ci$7s$KZ zq@RXyLWsN>jH$~9e?jUDspRiA;`7qdZZ77 z;g^I<(n?~oQ$8Nf zFD5>faD*_QYtO@n2q%ck?3cH1Uoq2QL`bkoPL#8NyJ)&4lEyJMo_;6L68a_PAjrk4PqAJQuqVUM1X2=uGHE z{#S4nVFzIx=@oD#A)7FSko;Z8HTfMPtR;RAVFY0{=~M71;YQ+%2=c2W^p|fxrChKG z=M$F56@IxIY6&ILn+UxKy$O8?@;gQN2jM$}ENyKJHqsg=!|Oz4;t;ZT_vud+YT4H!u;`s>`>Sr zbcgIxe{s+b`{%fQw#R1&ye^L~?4BQX+4%@k2e@LEn+W}XB+b;Hn zJzjazE_BUv+qwRL$DL=pe0g?=be_6V6&c+*vUl{(>;7>5psfA_vIY!_=2reR_LY5k zyGYQTpW_U80`r}A$nTv;MO39`m)f~Ow=3-N71%C&o+lVCc6n{LkC@+AtCWAOCd#RY}DFV7Qn=OUI;{X9bQ`?P?Z&KswUnl|3)blB5GcrLHkUlKZ}A_y@$GGe>@ z#mLK59Fl6}`hEGlI2^J|JmEsyj|79siia|l#7s#d%&;H%<-5J5cCgq-6_9q&Ul4Q^ z+4(_#5qFoC@VqjzDRyosUF9QdMq8U`j}I zuoRi+35A26*~KCYn#aqiWSCwL*;7ixg=DIS?LHod+d;`(E(%awo{d%@UlC#7Oxq{D zjUePIauqqMCYmw^sJ0Evv^`MKI*@_RO?Ho+6Le zCF;oIc23wGEXr|)q{dNa)s4|ky{?GZIRSSd#~JkGiYTS3RHewsdL9ZQ%^E&vz~GT| z)hJ5z6-d?88;!{59ntkXQ3y8`JlhD5*Ap()?Qq$?;-cBS!k?d%i`V5VxT9F~Un;Cs zNrX@o@VZ4cwR&aRqef3KeH$tbh2375ZhJpHPOsCSVo zjNBZkv{4mloz8dIGy6X>EBW-ef&!;q;tJWbQ7omtXEu%FT0!JOw@((5kO!sXrKY(bv)Gy`G8C`(i7CK1wXL z{lNm4&+|ApGlreCTy)=4Koh82xHRClhZly!ft>8@Jb!KoEfrmJ@KpAIY_Df_&=oAr zPCex)3>SHCNUv>{loJ~1oRukBELx2Tv5Q=DL^z%>BQfNmx2P!ZrGGGTely;*Btj0$ zDAWU@3{FvA(~s^vhdqusU9a>+X;o@e$e=MdiZV!2-8RGy1>Cuwd}CLX(B$H|`oR4d zTw{q)mT>gu2n&@Y! zI3U_f0qAE=a{8e%|DrAzq$<;Srk$5onb~epyHqboiP~6c-E!FWomjd&H+I#FEeN^Y zwi8*}6U=zAr-p;Y${wWI7n%@?-Z8@w$#VyohcHfg*?O4Fa&t+I2?l`b0K}bGG4={CUM*H>O0ZU4&tceyH-L zv&~3Aa^$;`CY7l$Q0hcLVuJf9rO;Ns)OLkJ{#=jL-&S|!avL{fBNCPNo5wHc`(LB!TkYukPNy+Tii_B?I>{YPCFPV z!ZO);fjO8^YRU_9c~al}tqz7YDoszDPyzT)}+@* zi)x+UE7dX`ZYGXc-k=U`BM5_;()dJbKBl{i175!?PkWh04U%eY%9x@ZU5rPbd;ay7 zSQc|-faBKmk3xTuTP-xE-#<~wR4r041dpMiu?t5$pAnrf zV)Be(_`b3_@!~cz+2P3Hbl_+p)pG`mc~JaIX|Rl7nbOi08qB+5XQX&X?B$Vnw_}Es z+tl(V%<@3|TjP#Mf77-QPPG^S)l6KP9Ov2VI4f#x5^~z%V%8HLm)BuUP(}9U#d;*& z$vQ{3q&UC| zfk|KLk?)sfiK?JX)j6?FW7@UPVp$+rN{0838#Q*)IO$O>Qe97qFJi9BbA?^ePUCNg z%fi>1cacl?91NUoKsToIHBJF3y+TXJ?qlasr8jK9hZ<$J>yC(+v;Q88f+@&aJo;d3`(|Vw@G}a^3 zSf%J?lLkfRFh|R{m+C5;TB>itLtquA)_1DkOjBiL?7rTbT+qi=RDF8V0M zqK)=!=HEOPCP`N$$C`v1xeBB~qt0%p*kj!RHxrXD*F*n}nRLrTqH9U}m)svp>p?tG z1Rn4+53xfrP9`SyD)h=qW+7QAvdl_zaFnrj7L`Wtc&XbJ;+19>l?F;ty-eGQ^_=4# z8a=%2ioR1y$J{q6TW6??WbQhp8tbbXJNSUR9PRgs0Ng;iY zA=NPs`yqdE?{k)GYG=TnCc`?%n(Qyp}9i%)6WQbt=Y{H!Fv^2Lb&(rbj#*H{)(QQ2kbV%>g zX!exvb`q~rTLW9Ug3)KD^o{7n5&n)>EC~ZA*UR#YT?w|RwCc!0vH&0C@vm7FTO3K3 zonMS#AWX%i++orP3qF}aWEA07JOV-W_g zOe%W2Q;ie5PpLc1gwB4Z>;jqTMs7*!6T^y5R*N{gfxc(B$fjM9J5QFV%n+`8nHSmO z_K9s%vy!#}4r^+<=NgLDJa|{z`;GIHR9D0-E>Y6+NN&S2Hq;nPQ#z$^j7>8}xI=q_ zInh7NTzey{>^v7fDU0YVHh01lT9h1d>~mpx-N9Jd!(-Zw_@?1bR}~SEYT~(8z*ywW z*lFkX_T9NhT%vru#j`RKLz5GonZGxJN9xHF)m5{XY^enh69zQk!uY7J)?Wr7W5g<-K93T*l$;hA?bA*t=t2d^K$W?*wE-m`Bd4STkH`BI_UQ?&NH*59Q8rNcwjdBu_DX>iw;kyP}d{1INAKz@{1y3_1XGNdIM^Qk?Kj$ z2eQKcEF5{YWq=(OozAfyGE;@fR2P5ND$0H$OJv#46H%vmOw49Jbf6$LGszfdN!AwW zN9WG#78#C9#O!Sm-y9a)6ZX%EPyc;VDpR3dgH0F)QH-}lOob?vsvSwufLC|N591zOY`iM z3DEcHo>N<3LBBV-nW7hP>}BBsutCo9jV4k(vkT;~oTGd$26TiGo$?xF#ltXG<6Qaj zveZ$l2JsvakSn>aI(Np_YJk4b9lF>&S0*z+ZgPv4EjhI*Pc6Od{pl^7eEZ&jJL0pa zD$hD;NVKh*&9=O(_0*6K;kfZ}fNg9s8|++;GR~OW9*j4iR7yJS?8~*qAJDJg*>c4> zNt#4eRq=zSv+HcWaxts%qOOrWY*UB!4o2Elrs>;5~@!Z$x_v*VM|?g3Oj#%ed3Zk zh#Seiqu6ILV=~!GiD{jg?m&m#t|H!9Qs}3a%1w~33)Brj3!c=#{J$ll_$EXGtM7 zp3M&C9Jar-f0KMZ*&lo{R*j~gZcghc)uLR#dMag7WO=3cQls~M_sdQWHWCKtb_{e3 zaSV#x_2lOnkExH)W=|IbB7!niRt-&l*8S!T&dl%ia62}JsmEpW*^sXlEKS+#2^8{q zG05Oa+dXzf`$wK0Xsl}T`;NAsDJ_#dPvkPy9iTM%l*x|6km&a#OGY@;X1b9h?14jR zK|iO{!fvOgKrGsTTOIuz{m9kp3MVW4p^kphxgU*=Eh#&e5ncY&?F0MBS6}h}rUnW< zzWM1Ni7n|{{moDfWz#u1(P0a(zA??Gw9>Y=h^ucV_z2;`*sO&wX0Yhht7D4~=?rbR z#qud!X!)3{_)|11X+}d9!y+}QurcJGZ^@)>?0>Q!WI!d=L|GZ}|Hb`RJtS9?Tl#vF zf3(-{pTijiHppmT0b_tUNgRM2Rr)+R1Q04^*Fp^d$wT93({#opUn$sLo)w+2_{NL% zTs5mW=nX{=HTQ`|7rUy|BC&2sym4o|VP*W_hWNt$iG}-{ zH!W_e-`%{l>Z7uS9P{|7;?Ruvmi_VF)$z*X@u#Yq&TQpYeMi%&>?Vj|aS1oxrdGsTeTe&g)*hg#G zrj|2HnoiawYF9R$e72>rwyFMjysA82xj9~6*L1Q>GB<8YEZ^3=qBg#BQDWY< z0fxyO>S#K-jN6+x*Tfsww$z-VY$PKxEML%4bMosIL{!yFn(Ou@D%ZuUPqs8R%KMcV znoh2WmmhDcUze&yQ{BGiHQVA9N1C5qKxGHUPaQXfF5HjIo9gSE8rR0R97?P^6|Y$u zFDLU*%b8UzJF0ZGsYmqEoBBt$?ClgCR=p#V*s&|Iqms8Fsl@UF`m_fG^UwUn~7GQRRz5$mewlJ14R{nLiZcy%msWJhAl(&mPBEw!r=L1O7M@xyCB zZCEO0oT620Xj1aI0d{=iQ&sjrJ6_%puQ^4lxeJGnvmBIxfLj(dCN|XCAC*-hW+eYn zSv6&HQ}f~ariO;5x)sUKq^UC<5o&$zcX^7^oo`NhBsL#yI(aBwTP4*~4UMmEjIXM0 zuG<^0*<_A-P>OyiUcHtGw~8k!6;txko!_!!Kf@tjvxqj)t?}KP>?wEX&zvo_2V3@+ zA*{rf1B`(9i9PZ16Caf=;3$WU+Qe5bYmU`7*KbQaeLV5>Vv08+DBBl(rTUQ`v|8S} zuR7VjbPrCQ>qu;GU<4ux6g7V6aO#1?(x~*Lx=JIye!3&EerM`d-J$6Pr7mfWp+lr* zHA`D|nG&Us_byC4y(O!8ErVuxe8uwShG%$Ts)t*4KG#xnx}|0Z0}(03Ya8O_d!k)e ztdEFAs3>n;gv@H2*Bnki($R9FHhy|Bof?07d1_zle|M_GZmwV4T)%|+i{_!mk%PPG zc~P?s(U!&oiRztFLp8Wk()ya>Y^W7gR((i0NK+5oq$VicXCQZAeY3tL+VWnT9;JED>f2mtT2=4!lWfD*EQAeYO1Sf zYS@nYq;4RydHaHRU6fj)kkXNLbxrjL5?i(rYhv42N=>w0^*K8!KaDcYmVwoDUh zHtdO0WcSoIu<7JM8QjX|ww&1@iof|J6SOEz>dXao&t{TpDJ$1`a_%B&{Fh2EP;Ttv zm6;h4@f4!fO^sWOnZpV)Cn>9xSh=d{^k&LU&1uxE>GX08i#lDw3-s{{U9uFLI8&B5 zTCXdeK80I}6ZP?B+hsVY1|_PN#8<6m$VBg5^`~L08}S_CHC2hqRq<6TMAeug>(+=z z(XdH-7kVB+`4ihuNR3WM<4fv3ZP*mMef6VlBD&DlO>3I>){7iW&ujNV#HnU;Z68yO zq2Wq-p&P;~U>^#vWYyV+E?ymiN^ z=&JSioYzvesAc2o=%M9Z#xhxNK7*M{tUHCnBGN}+^giXcp1_cCrY{Hd2@E6~{l)tJ z8ClVbH@wgxU23uCH}r2aLTd`Tq!oENepsqgt;Cws@rFh5TAY-97|oO_P%CAEVi}u% z)+UnJQf4#_Q@;Lqyli7)*)r`Lri#Kf#CGG^Cd-(@4grf)y#mB)=2s1sHL9fM;nTYuSRu=Z=4PS)esN|&8HN}Xhg)Ha->RZe}Q zc7UV59o9X%^pUH3oO2q(Mn5T{rDlIiO`Qm`VS8=#iTdjuXSI@vkMV8)>%$lYJ8o%n zvD9eCG1>RCW1(FKGTI`H=%f)@Z4piMcf0J|Pa8HfJXjzgJ!WX;)A;72ts7T~h9+%S zYJj0C%nUp#DzSMxlX_DlPOI4RbkASUtomje5W9BI;kFU&%ZORvX65GSd9dl^mX!b=L|6g*5GPsgH!L zMX=twc3erUT-kEwkba?Fg-9LM8bNFw76#W#xs+n7UfcgkI|nUDsTd{1%NHfq9!gXr zn1kBtYc;g>d5!3)ga55V86w-7McV6as>e5opRVC`yr{Wxb@Ou@&u*Fht791Fo@j`C z{TPPbvf@Pi^m-Y7x-%*4+H$aOmn~&7LXy7j*<%@xsMg7bGNTgbk5Q?QWyrmi>zJ!r zpWBdp(>_FQt#)Cz=a(|eVSy1Zp zW6AF{Ne8E?u^Ma4-T)J4>Jd>@_P~b5PaW-_*ivatoG@nGqV9^qIjDxa#2?1!wWX{oK2PPzX`R)m>f5C8PhElbsXH2t8M@|sP0 zTr*iDDo=3fdh4vgP!ZxukXKlNydEqIVfX>O1PVbpWG0WozS8=mBdC@if zR@wKxTaydDh>*E)a!4&WOCkHUtGgz29gTd%%t(WCaVo`a#;uyx${$Cx+ z;N7VH*Un-%)PF_LhcVL6Vo>#^R?C?M&HL*0q_0n{$95fgIwK-x{lt;x`jvP-@ro)n z`71Y7Z7!L4d0GEfoKViyL{)=yU2HY zz2d<$`RK_nxn)KJWwWM!Mf!G<-p5LHJc_{rF4ftwoTE=^s|Z}}GN#_H{dnCfT4?J%*9c2xp3rkN z59w6}k>m-4|IyJ4T@xxm{pg{Vqk9=@x=QT4m`PEsu=^Mt)!W;$VX6jrYUj-K9PZAx zp0`8~AFJrAcNB~TILf9fdu5eVzJ4%6{No|VGb4KGBwnbJhJFm!UF>CL1%pjGMMdHp z@qX5`K_%M3_$-e}r>s4yGpW2@RJ3j=PaRA7*3%hk9GTaakB(siS<|up<3%ioo9io@ z&d4f7Mq9l6K)n30_BvWOS6F(Q`PxDuHurd4`++HeFgPmj*XIP)Fu~8O!PtRnkb`QsrL;iUKFCSLT%Sorw!u2n*9;lvr0SR+iPB2#<_d62?LKGEbHr{x{Z5|rgD;Ku8)p*>g^BJlA12(tWP1I9Qx?XFO6T9)%oQ#OBt{N>VrL%NzYN?B< z(Iyhv=>r?GD}w6iyTr3flPEW#NoPN5$>sIiSrp;yv++*T=|EdPV4SRB@Lv~Sz()!B zyueeUK8!_rM7n9)o|f93QSWP+!&B>o*W=$>eQ>x5c%xv%!Y2JvZhtqkILtJOolOc@v8nFm+tPh6+?P^7ouS{ftrQIvY6CQG(e z&h9d?#7iynb*C^+IC6m(us~vR>cYfR2QN&Tvlrrz>m{D~`jsY3rCEHJh-|2B-THL% z_M`EwD_K#f#_&%0!le5FB_cDmT%j4VS*z}6Sd00@#ZmWbDe!qxuSj%1m|2JI9JNxD zj#A&*Fav01{9wk0Sj`6=Grn=!B6`=8+ha3++b<)+=Jz=tRMo)JduO~FK{RhWnAo(C zxZVd&*I)D5?A-YxwKfuGheH|61h!t?A`~k%t?8OKN2@=4q8C~zM=MxX-o~=B<(TYE z>w%{Yq*k@)pFjNW|L){PZ0<*&s#6!)ee`$R|_tJ~L-ugmHS9-HQ=fg#?(toTj; z)e{%B8PRdgUB7wiLKe);&(wYG$i+7uVmSe!-6okxp(kqV{)v5Lu~6WU{m?>;46pXT3~ SrGA>3R+W`r{?=0#*8c+t)Mjk} delta 8724 zcmY+}34Be*9>DQAH;H`Ivc5s?rQ(j>NOU5%~wHbkj^a4klPp}Na|z|Q3NaV$2g zuGBT$hn^LjXhjXB+*Cw`D^&vf<4zobtuVZ%?vYfyFZC!5P2{r1U>bJBd-wxJGGWSL z$vVs*tb;PNQ!o$CN9pk;b(F{3C2OcCLq(49G|CX%Hu*y=OJ1<9K5#XZN!AK`;hX4> zJ5c8BQIyGd3ElV<3uE~RZFLMFkBp%IWh^>TAuSwiHW*>@33!(J*(f_C)YCmQ3XhUc zN2%{xU(b;w97;YIW!7KB@%R8o(9^>k=nK2oP&e?Ahe9zn2w=dZYpS7iZMZQK83olE zi{LO^k7IEw1~*dbAbyK-0Sg*)tKurmz`rmD)0!wX2t%9Ft2hT`d(W6=`oNPhlZpk% zMX7?#bxT{~I9eW!(!diflzN~1G`>mxMk}Ry<3~7^`aDs3md|O;vxNFJ=uf?W8-1Q2 zX7DuXBarnTb%4SeHVAt~clGIZN~N;F>h`)P{G;`lRX`c@8Yn~73QJ&LV>)tCY7)Bf zFjmE%k$);*2lnSYU2z%tKxS+q&ad*ks=J~D$|R|bDQs91WhfSP(vxc~auF&AOXD*v zizPbi{cECZ-xx!&ElQ82ViAs)i849IcTvh07hw?RSIa55@Cf?jXK3REloOA7AEhEMX?t$Pt_1Ch|5rJvyCXn-GPPhC>Fsp=&3{D3I*B0zpLJ%BFcfQ z;SO3}4;c-0;|;yOR*b&VhPapdC}e`Gzl?ReajTIhVIXFid<_=hc!y9L@I@^BFJ1Co zEGNSUI2TJZv!p9GqC6LNqFnh&lmq{S(ldV}^Hr68OJ8|6tU*2*E8q?c!BZ&vKStTV zKzF75Ft|JYpN~Q~6+YMigRwEn1Ee3i(Sy?B6?hf5qMT@M58ZRQ7({*oW&dALwh!p3 zPaK3L$QxoA?1(ldcqmMz@EC_;RxhQPcj^JkWNXg7wF2MA{aB@se&+v(z3IxfeK{!g zE8`d*ynuPBKiE&-W}nA1c3P`Wjk?VjO1 z@+w?~G@$6)GIWf8X$tZ{3BtcI3Z+3U)A{7W7?dlSfHg21gYhuRWV($$=$D~XBg~JD zu{8$byC`#P85YO&cnJ4mEaz8aGL_;ERA;awRvE58)l#t=EkA*KsjtLkF2{?=u&dFd zbVDxSCh~ufW2#M~mEszd`yEci{&VpddCa@I!DZjmA6gC2BUjLoLP<=*g7_{<7kz*- zrn9jkF2b_7Tk1LRS(G9Bek>0qyo&)?k*kuPlTTNf8wuD1C!-A2VU+VU8At!ur_gSk zZon8kK|TksV6XS}q-mC==R_NnxzGXS0B@o+w7;nzY#fO#sGop*yr?7C2J?;Ale!be zk}nufONvprM}>^(-{_B3Cz$&c1Iat0jA07O6%R+5%@eQ+PD5$f7L*>_hqC=Kl%73l z>aU>>`F)gzKlD)egsyyw(i2-J=`Oy8bIG4$0h}{gy98wj)}u81Q!IsNO@7<>6!TJF z@B?iLV|kRG3qm=rr?y$q#Mm08g&oZXU5q`91B}Cr?-(Z!*~a!#rKU*jJ{L!kQBvm)>lFq!dFoyZ6BmF)EEq;r+udC<5Zi* z!^>j)>rjv}em0$NDOhoaegvOFMn#pM$;$$+z*jNfEd3eK4Wq~-XX~*ajjhQi;Rrl| zUt_B|+)11`fbpzKzSP#+AI2QcuTD{DiIeB)N%c7%B0p*JS@ZRycL8>xJ}(dQ1NbJ& z<_>CzoO#T#54F*?=-h_nG`SdSru36w2ULloyF-D9?q0A8JFeFL@i3 z1Fb?i&`z`dFiJx%V`co^tPfbIj~9sLsIQB1zD~xNg^a&c^rT`h#-lW#!XkZwaNJGa z7^VIp%9Xhmdp`zL9t!3pR5vUIrNLP!^|Mgs(t@S*zZ6zd5rUgg z4)_gj#@o0RvzKYxFV_cnjIq=|$3fU_h2B0FnU`wFN~Ip*?@|Ll-X1_V^|wuZfh~FnN@FDTAy^UPFc9Cv zXk3oZ@D@q~uF-umDKj~%I1c4}(=o(i{1=*vPr3KXvf?Cm!CP1!BX{UAj6pd-GRhSW zN4cFmSOnLg+}{osB|qorp1h9I;Cm*o`iWj2hU+-LYDz(_;40D<<-1d#a3{)8e1X!i zv*_(wl(G8*emw8W*D+*TI6EU+tyvAuaz5n~}#c<@4ea zl*zdUxhS<2>tp{t+H8~qeu;7c*RU++*^3;{jfKgZ?9-nS(I`C{hx2g^dhdUK-Ykn# zQN|c%Y+>w*@^Lx8dC!g4M6;pJE$f z0Qn%4hP{V!8?M2+cmib(JwrKB($D&Nk&ZId>rond20aX?nsrT2nts>yq)Ed<)Q?0t z(FByPU1;i88n<8z>i1z=e2Q(bZ_@vAf?-t1m`}ib zxEbzYwx?)cp7FGfGd0qU`eqQHOF*+=W{R?kd%l`~ZGR$Wnql z66>P;5EV*!Dp82CX8?s}6#5Xd%q3(@*AhPvvb;wmvR=ka7U}vIO9cuYSXYK%zIp#2 zVGj->&Jk|v|3*IRz0a4Kl>1ZW`6j;~db~6K50V^0mcNJ)BU&4?u9}f*?=QQecXH-?X~p-{)iU{5?-u+}icDGc8S!tTH<8C|6M?Zr zG<5|CS%wi)h-<`bLY8!5Iq{UJ#P+H9Iw7wjY8;V4$TC5re#7mi{DSi@3dTVkXs{^< zQ9e!i7;%tDAig4I5T%I@L|&pk+r5Dg319gtaFIeBah;GQh7Dw?hjn$)`*#h0n-cAa zRo)u?jr${07TzK@6Bme;gg^0OSw1_H z!iQ}ZVNaOvuu{!Hpo3ebx{MD2_E(#}2QWT#Pn@s+Kf$R`YY@p&* zQ`wGuHRY;UiYQNc7EzmMNGu`xQZLIV8a@x&rNn23xYObjhQtp{%y5rPw!=c)c2-EP zy)N{=v%LBxU*~M?qLzI=BHH$=zrg;n!CTI}#$7EZu4!eDTXvVUQTBzjkix_J zrz9u12gGN_XC!7i2i|_*=bRpyV%gnBCpk6WiSe<|zc<^NJ+_6fQ*8WVKl}IxtDQ?z zB3(}O^tP5?1|8JIE<3Y=vtj0x0(R=6_SyNXSi#PgCGC8&bE{cV&d3!_eC*%XK5=~3 z-?!|kbGCId z$<934(XM!^j@{+d5vRuKs;;8fc2B#Nn|mvF>$QEmu1}xnOgsCvE8zCHtef*TT-!VI z<?HXkSE=exdk>a8mOKU(&k>V7NsU*A8=j=tN$ zxqP>z%Za<+)3U$(b)r4`w{W}ugKEw<50_d_)T2zxF7RiTz3b1gqSq&Gx;}CHjrrSd z%-C{!@g!%}lf8bEfU#m{;t=Z>Fs-6tnc0n6o=UA3sSFej{- zRnC<&uDI3EDw2DU=HFPb=Y})?*ZqsKy9HR`IrjrBSAlG|+iIS};HCTIFmQu?a@vGh z`7PUL{i2+|!mT=1_L^E&R(7A-))4#Q##TA)>sXtu?1TubYQT+Ivu+*S<_`VuSPmOn zJ!f--b<_&Ev31t9-5YPO+;emBmYbify1swDcPy{%p80=+nH|``s?BHyXOC}S#Rc5V YopXKZICtpq^pxuA=9CX^@RQJg0LWC!OaK4? diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po index 6a789dd1d..fe67dca4c 100644 --- a/locales/zh_Hans/LC_MESSAGES/messages.po +++ b/locales/zh_Hans/LC_MESSAGES/messages.po @@ -8,7 +8,7 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-07-31 19:50+0000\n" +"PO-Revision-Date: 2021-08-13 22:32+0000\n" "Last-Translator: meowmeowmeowcat \n" "Language-Team: Chinese (Simplified) \n" @@ -917,6 +917,8 @@ msgid "" "runtime installation format (if left zipped), and was designed to be " "importable." msgstr "" +":term:`Wheel`是一种 :term:`distribution `格式，也就是一种打包格式。[1]" +"_ :term:`Egg`既是一种发行格式，也是一种运行时的安装格式（如果留下压缩包），并被设计为可导入。" #: ../source/discussions/wheel-vs-egg.rst:26 msgid "" @@ -926,6 +928,8 @@ msgid "" "\"universal\", similar to an :term:`sdist `." msgstr "" +":term:`Wheel`档案不包括 .pyc 文件。因此，当发行版只包含 Python 文件（即没有编译的扩展），并且与 Python 2 和 3 " +"兼容时，wheel 有可能是 「通用」的，类似于 :term:`sdist `。" #: ../source/discussions/wheel-vs-egg.rst:31 msgid "" @@ -941,12 +945,14 @@ msgid "" "wheel archive can indicate its compatibility with a number of Python " "language versions and implementations, ABIs, and system architectures." msgstr "" +":term:`Wheel`有一个 :pep:`更丰富的文件命名约定 <425>`。一个单一的 wheel 档案可以表明它与许多 Python " +"语言版本和工具、ABI 以及系统架构的兼容性。" #: ../source/discussions/wheel-vs-egg.rst:38 msgid "" ":term:`Wheel` is versioned. Every wheel file contains the version of the " "wheel specification and the implementation that packaged it." -msgstr "" +msgstr ":term:`Wheel`是有版本的。每个 wheel 文件都包含 wheel 规范的版本和包装它的工具。" #: ../source/discussions/wheel-vs-egg.rst:41 msgid "" @@ -954,6 +960,8 @@ msgid "" "python.org/2/library/sysconfig.html#installation-paths>`_, therefore making " "it easier to convert to other formats." msgstr "" +":term:`Wheel` 在内部是由 `sysconfig 路径类型 `_ 组织的，因此更容易转换为其他格式。" #: ../source/discussions/wheel-vs-egg.rst:47 msgid "" @@ -968,7 +976,7 @@ msgstr "词汇表" #: ../source/glossary.rst:8 msgid "Binary Distribution" -msgstr "" +msgstr "二进制分布 （Binary Distribution）" #: ../source/glossary.rst:11 msgid "" @@ -978,7 +986,7 @@ msgstr "" #: ../source/glossary.rst:14 msgid "Built Distribution" -msgstr "" +msgstr "构建分布（Built Distribution）" #: ../source/glossary.rst:17 msgid "" @@ -1026,6 +1034,10 @@ msgid "" "deprecated/python_eggs.html>`_ and `Python Eggs `_" msgstr "" +":term:`Built Distribution`格式由 :ref:`setuptools`引入，并正在被 :term:`Wheel`取代。 详见`" +"Python Eggs 的内部结构`_ 和 `Python Eggs `_" #: ../source/glossary.rst:49 msgid "Extension Module" @@ -1093,7 +1105,7 @@ msgstr "" #: ../source/glossary.rst:90 msgid "Per Project Index" -msgstr "" +msgstr "每个项目索引（Per Project Index）" #: ../source/glossary.rst:93 msgid "" @@ -1150,6 +1162,8 @@ msgid "" "A :term:`Module` written in Python and contained in a single ``.py`` file " "(and possibly associated ``.pyc`` and/or ``.pyo`` files)." msgstr "" +"一个用Python编写的 :term:`模块 `，包含在一个\".py \"文件中（可能还有相关的 ``.pyc`` 和/或者 ``." +"pyo`` 文件）。" #: ../source/glossary.rst:127 msgid "Python Packaging Authority (PyPA)" @@ -1207,7 +1221,7 @@ msgstr "" #: ../source/glossary.rst:157 msgid "Release" -msgstr "" +msgstr "发行版 （Release）" #: ../source/glossary.rst:160 msgid "" @@ -1225,7 +1239,7 @@ msgstr "" #: ../source/glossary.rst:168 msgid "Requirement" -msgstr "" +msgstr "要求 (Requirement)" #: ../source/glossary.rst:171 msgid "" @@ -1308,7 +1322,7 @@ msgstr "系统包 (System Package)" msgid "" "A package provided in a format native to the operating system, e.g. an rpm " "or dpkg file." -msgstr "" +msgstr "以操作系统本地格式提供的软件包，例如 rpm 或 dpkg 文件。" #: ../source/glossary.rst:222 msgid "Version Specifier" @@ -1334,6 +1348,8 @@ msgid "" "more information, see the section on :ref:`Creating and using Virtual " "Environments`." msgstr "" +"一个隔离的 Python 环境，允许安装软件包以供特定的应用程序使用，而不是在系统中安装。更多信息，请参见 :ref:`" +"创建和使用虚拟环境`一节。" #: ../source/glossary.rst:238 msgid "Wheel" @@ -1345,6 +1361,8 @@ msgid "" "intended to replace the :term:`Egg` format. Wheel is currently supported " "by :ref:`pip`." msgstr "" +":term:`Built Distribution`格式由 :pep:`427`引入，旨在取代 :term:`Egg`格式。 Wheel 目前由 " +":ref:`pip`支持。" #: ../source/glossary.rst:244 msgid "Working Set" @@ -1560,15 +1578,15 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:86 msgid "Installer" -msgstr "" +msgstr "安装程序" #: ../source/guides/analyzing-pypi-package-downloads.rst:86 msgid "pip, `bandersnatch`_" -msgstr "" +msgstr "pip, `bandersnatch`_" #: ../source/guides/analyzing-pypi-package-downloads.rst:88 msgid "details.python" -msgstr "" +msgstr "details.python" #: ../source/guides/analyzing-pypi-package-downloads.rst:88 msgid "Python version" @@ -1576,11 +1594,11 @@ msgstr "Python 版本" #: ../source/guides/analyzing-pypi-package-downloads.rst:88 msgid "``2.7.12``, ``3.6.4``" -msgstr "" +msgstr "``2.7.12``, ``3.6.4``" #: ../source/guides/analyzing-pypi-package-downloads.rst:93 msgid "Useful queries" -msgstr "" +msgstr "有用的查询" #: ../source/guides/analyzing-pypi-package-downloads.rst:95 msgid "" @@ -1597,7 +1615,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:102 msgid "Counting package downloads" -msgstr "计算软件包的下载量" +msgstr "-计算软件包的下载量" #: ../source/guides/analyzing-pypi-package-downloads.rst:104 msgid "" @@ -1610,7 +1628,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:168 #: ../source/guides/analyzing-pypi-package-downloads.rst:205 msgid "num_downloads" -msgstr "" +msgstr "num_downloads" #: ../source/guides/analyzing-pypi-package-downloads.rst:121 msgid "26190085" @@ -1638,7 +1656,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:168 msgid "month" -msgstr "" +msgstr "月" #: ../source/guides/analyzing-pypi-package-downloads.rst:170 msgid "1956741" @@ -1736,7 +1754,7 @@ msgstr "6381252241" #: ../source/guides/analyzing-pypi-package-downloads.rst:215 msgid "null" -msgstr "" +msgstr "空" #: ../source/guides/analyzing-pypi-package-downloads.rst:215 msgid "2026630299" @@ -1752,7 +1770,7 @@ msgstr "1894153540" #: ../source/guides/analyzing-pypi-package-downloads.rst:221 msgid "Caveats" -msgstr "" +msgstr "注意事项" #: ../source/guides/analyzing-pypi-package-downloads.rst:223 msgid "" @@ -2244,7 +2262,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:190 #: ../source/specifications/binary-distribution-format.rst:127 msgid "version" -msgstr "版本" +msgstr "version" #: ../source/guides/distributing-packages-using-setuptools.rst:196 msgid "" @@ -2257,7 +2275,7 @@ msgstr "" msgid "" "Versions are displayed on :term:`PyPI ` for " "each release if you publish your project." -msgstr "" +msgstr "如果您发布了您的项目，每个版本都会显示在 :term:`PyPI `上。" #: ../source/guides/distributing-packages-using-setuptools.rst:203 msgid "" @@ -2275,7 +2293,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:214 msgid "description" -msgstr "描述 (description)" +msgstr "description" #: ../source/guides/distributing-packages-using-setuptools.rst:222 msgid "Give a short and long description for your project." @@ -2312,11 +2330,11 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:245 msgid "url" -msgstr "网址 (url)" +msgstr "url" #: ../source/guides/distributing-packages-using-setuptools.rst:252 msgid "Give a homepage URL for your project." -msgstr "" +msgstr "为您的项目提供一个主页 URL 。" #: ../source/guides/distributing-packages-using-setuptools.rst:256 msgid "author" @@ -2324,11 +2342,11 @@ msgstr "作者 (author)" #: ../source/guides/distributing-packages-using-setuptools.rst:263 msgid "Provide details about the author." -msgstr "" +msgstr "提供关于作者的详细信息。" #: ../source/guides/distributing-packages-using-setuptools.rst:267 msgid "license" -msgstr "" +msgstr "license" #: ../source/guides/distributing-packages-using-setuptools.rst:273 msgid "" @@ -2350,13 +2368,13 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:287 msgid "classifiers" -msgstr "" +msgstr "classifiers" #: ../source/guides/distributing-packages-using-setuptools.rst:316 msgid "" "Provide a list of classifiers that categorize your project. For a full " "listing, see https://pypi.org/classifiers/." -msgstr "" +msgstr "提供对您的项目进行分类的分类器列表。有关完整列表，请参阅 https://pypi.org/classifiers/ 。" #: ../source/guides/distributing-packages-using-setuptools.rst:319 msgid "" @@ -2369,15 +2387,15 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:327 msgid "keywords" -msgstr "" +msgstr "keywords" #: ../source/guides/distributing-packages-using-setuptools.rst:333 msgid "List keywords that describe your project." -msgstr "" +msgstr "列出描述你的项目的关键词。" #: ../source/guides/distributing-packages-using-setuptools.rst:337 msgid "project_urls" -msgstr "" +msgstr "project_urls" #: ../source/guides/distributing-packages-using-setuptools.rst:349 msgid "" @@ -3031,22 +3049,24 @@ msgid "" "token`_; don't limit its scope to a particular project, since you are " "creating a new project." msgstr "" +"到 https://pypi.org/manage/account/#api-tokens 上创建一个新的 `API token`_ " +"；不要把其范围限制在一个特定的项目上，因为你正在创建一个新的项目。" #: ../source/guides/distributing-packages-using-setuptools.rst:901 msgid "" "**Don't close the page until you have copied and saved the token — you won't " "see that token again.**" -msgstr "" +msgstr "**在复制和保存令牌之前不要关闭页面──您不会再看到该令牌。**" #: ../source/guides/distributing-packages-using-setuptools.rst:904 msgid "" "To avoid having to copy and paste the token every time you upload, you can " "create a :file:`$HOME/.pypirc` file:" -msgstr "" +msgstr "为了避免每次上传时都要复制和粘贴令牌，您可以创建一个 :file:`$HOME/.pypirc`文件：" #: ../source/guides/distributing-packages-using-setuptools.rst:913 msgid "**Be aware that this stores your token in plaintext.**" -msgstr "" +msgstr "**请注意，这将以明文形式存储您的令牌。**" #: ../source/guides/distributing-packages-using-setuptools.rst:915 #: ../source/guides/migrating-to-pypi-org.rst:70 @@ -3054,17 +3074,19 @@ msgstr "" #: ../source/guides/using-testpypi.rst:83 msgid "" "For more details, see the :ref:`specification ` for :file:`.pypirc`." -msgstr "" +msgstr "有关更多详细信息，请参见 :ref:`规格 ` for :file:`.pypirc`。" #: ../source/guides/distributing-packages-using-setuptools.rst:921 msgid "Upload your distributions" -msgstr "" +msgstr "上传您的发行版" #: ../source/guides/distributing-packages-using-setuptools.rst:923 msgid "" "Once you have an account you can upload your distributions to :term:`PyPI " "` using :ref:`twine`." msgstr "" +"一旦您有了账户，您就可以使用 :ref:`twine`将你的发行版上传到 :term:`PyPI `。" #: ../source/guides/distributing-packages-using-setuptools.rst:926 msgid "" @@ -3086,6 +3108,8 @@ msgid "" "the name of your project that you uploaded. It may take a minute or two for " "your project to appear on the site." msgstr "" +"您可以通过浏览 URL ``https://pypi.org/project/`` 来了解您的软件包是否已经成功上传，其中 " +"``sampleproject`` 是您上传项目的名称。您的项目可能需要一两分钟才能出现在网站上。" #: ../source/guides/distributing-packages-using-setuptools.rst:944 #: ../source/tutorials/installing-packages.rst:663 @@ -3105,7 +3129,7 @@ msgstr "" #: ../source/guides/dropping-older-python-versions.rst:5 msgid "Dropping support for older Python versions" -msgstr "" +msgstr "放弃对旧版 Python 的支持" #: ../source/guides/dropping-older-python-versions.rst:7 msgid "" @@ -3136,11 +3160,11 @@ msgstr "" #: ../source/guides/dropping-older-python-versions.rst:17 msgid "Requirements" -msgstr "" +msgstr "要求" #: ../source/guides/dropping-older-python-versions.rst:19 msgid "This workflow requires that:" -msgstr "" +msgstr "这个工作流程要求：" #: ../source/guides/dropping-older-python-versions.rst:21 msgid "The publisher is using the latest version of :ref:`setuptools`," @@ -3148,7 +3172,7 @@ msgstr "" #: ../source/guides/dropping-older-python-versions.rst:22 msgid "The latest version of :ref:`twine` is used to upload the package," -msgstr "" +msgstr ":ref:`twine`的最新版本被用来上传软件包，" #: ../source/guides/dropping-older-python-versions.rst:23 msgid "" @@ -3391,7 +3415,7 @@ msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:8 #: ../source/guides/supporting-multiple-python-versions.rst:8 msgid "2014-12-24" -msgstr "" +msgstr "2014-12-24" #: ../source/guides/index-mirrors-and-caches.rst:14 msgid "" @@ -3640,6 +3664,10 @@ msgid "" "destructive; installing a new version of one package does not break existing " "installations, so many configurations can coexist on the same system." msgstr "" +"`Spack `_ 是一个灵活的软件包管理器，旨在支持多个版本、配置、平台和编译器。它是为" +"了支持大型超级计算中心和科学应用团队的需要而建立的，因为他们必须经常以多种不同的方式构建软件。Spack 不限于 Python；它可以安装 ``C`` 、" +" ``C++`` 、 ``Fortran`` 、 ``R`` 和其他语言的软件包。 " +"它是非破坏性的；安装一个包的新版本不会破坏现有的安装，因此许多配置可以在同一个系统上共存。" #: ../source/guides/installing-scientific-packages.rst:119 msgid "" @@ -3653,7 +3681,7 @@ msgstr "" #: ../source/guides/installing-scientific-packages.rst:128 msgid "The conda cross-platform package manager" -msgstr "" +msgstr "conda 跨平台软件包管理器" #: ../source/guides/installing-scientific-packages.rst:130 msgid "" @@ -3663,6 +3691,9 @@ msgid "" "Anaconda, about 200 packages are installed by default, and a total of " "400-500 can be installed and updated from the Anaconda repository." msgstr "" +"`Anaconda `_ 是由 Anaconda 公司发布的 Python " +"发行版。它是一个稳定的开源软件包集合，用于大数据和科学用途。 在 Anaconda 的5.0版本中，默认安装了大约200个包，总共有400-" +"500个包可以从 Anaconda 仓库中安装和更新。" #: ../source/guides/installing-scientific-packages.rst:136 msgid "" @@ -3683,7 +3714,7 @@ msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:2 msgid "Installing stand alone command line tools" -msgstr "" +msgstr "安装独立命令行工具" #: ../source/guides/installing-stand-alone-command-line-tools.rst:4 msgid "" @@ -3692,6 +3723,9 @@ msgid "" "github.com/PyCQA/flake8>`_, :ref:`pipenv`,and `black `_." msgstr "" +"许多软件包都有命令行入口点。这类应用的例子有`mypy `_ ，`flake8 " +"`_ ， :ref:`pipenv`， 和`black `_ 。" #: ../source/guides/installing-stand-alone-command-line-tools.rst:10 msgid "" @@ -3709,6 +3743,8 @@ msgid "" "or uninstalled without causing conflicts with other packages, and allows you " "to safely run the program from anywhere." msgstr "" +":ref:`pipx`通过为每个软件包创建一个虚拟环境来解决这个问题，同时也确保软件包的应用程序可以通过您的 " +"``$PATH``上的目录访问。这允许每个软件包在升级或卸载时不会与其他软件包产生冲突，并允许您在任何地方安全地运行程序。" #: ../source/guides/installing-stand-alone-command-line-tools.rst:21 msgid "pipx only works with Python 3.6+." @@ -3727,7 +3763,7 @@ msgstr "您可能需要重新启动您的终端以使路径更新生效。" msgid "" "Now you can install packages with ``pipx install`` and access the package's " "entry point(s) from anywhere." -msgstr "" +msgstr "现在您可以用 ``pipx install`` 来安装软件包，并从任何地方访问软件包的入口点。" #: ../source/guides/installing-stand-alone-command-line-tools.rst:39 #: ../source/guides/installing-stand-alone-command-line-tools.rst:100 @@ -3752,11 +3788,11 @@ msgstr "``pipx`` 可以用 pip 升级或卸载" msgid "" "``pipx`` also allows you to install and run the latest version of a cli tool " "in a temporary, ephemeral environment." -msgstr "" +msgstr "``pipx`` 还允许您在一个临时的、短暂的环境中安装和运行最新版本的命令行 （cli） 工具。" #: ../source/guides/installing-stand-alone-command-line-tools.rst:106 msgid "To see the full list of commands ``pipx`` offers, run" -msgstr "" +msgstr "要查看 ``pipx`` 提供的全部命令列表，请运行" #: ../source/guides/installing-stand-alone-command-line-tools.rst:112 msgid "" @@ -4004,15 +4040,15 @@ msgstr "" msgid "" "The Python installers for Windows include pip. You should be able to access " "pip using:" -msgstr "" +msgstr "Windows 的 Python 安装程序包括 pip。您应该可以用以下方法访问pip：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 msgid "You can make sure that pip is up-to-date by running:" -msgstr "" +msgstr "您可以通过运行以下命令来确保 pip 是最新的：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 msgid "Installing virtualenv" -msgstr "" +msgstr "安装 virtualenv" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 msgid "" @@ -4032,7 +4068,7 @@ msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 msgid "Creating a virtual environment" -msgstr "" +msgstr "创建一个虚拟环境" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 msgid "" @@ -4061,17 +4097,17 @@ msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 msgid "venv will create a virtual Python installation in the ``env`` folder." -msgstr "" +msgstr "venv 将在 ``env`` 文件夹中创建一个虚拟的 Python 安装。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 msgid "" "You should exclude your virtual environment directory from your version " "control system using ``.gitignore`` or similar." -msgstr "" +msgstr "您应该使用 ``.gitignore`` 或类似的方法将您的虚拟环境目录从你的版本控制系统中排除。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 msgid "Activating a virtual environment" -msgstr "" +msgstr "激活一个虚拟环境" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 msgid "" @@ -4096,7 +4132,7 @@ msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 msgid "Leaving the virtual environment" -msgstr "" +msgstr "离开虚拟环境" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 msgid "" @@ -4314,22 +4350,25 @@ msgid "" "`reStructuredText `_ (without " "Sphinx extensions)" msgstr "" +"`reStructuredText `_ (没有 Sphinx 扩展)" #: ../source/guides/making-a-pypi-friendly-readme.rst:18 msgid "" "Markdown (`GitHub Flavored Markdown `_ by " "default, or `CommonMark `_)" msgstr "" +"Markdown（默认情况下 `GitHub Flavored Markdown `_ " +"，或`CommonMark `_ ）" #: ../source/guides/making-a-pypi-friendly-readme.rst:21 msgid "" "It's customary to save your README file in the root of your project, in the " "same directory as your :file:`setup.py` file." -msgstr "" +msgstr "通常将 README 文件保存在项目的根目录中，与 :file:`setup.py` 文件位于同一目录中。" #: ../source/guides/making-a-pypi-friendly-readme.rst:25 msgid "Including your README in your package's metadata" -msgstr "" +msgstr "在软件包的元数据中包含您的 README" #: ../source/guides/making-a-pypi-friendly-readme.rst:27 msgid "" @@ -4364,7 +4403,7 @@ msgstr "" msgid "" "If you're using GitHub-flavored Markdown to write a project's description, " "ensure you upgrade the following tools:" -msgstr "" +msgstr "如果您使用 GitHub 风格的 Markdown 来写项目的描述，请确保您升级了以下工具：" #: ../source/guides/making-a-pypi-friendly-readme.rst:60 msgid "The minimum required versions of the respective tools are:" @@ -4372,7 +4411,7 @@ msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:62 msgid "``setuptools >= 38.6.0``" -msgstr "" +msgstr "``setuptools >= 38.6.0``" #: ../source/guides/making-a-pypi-friendly-readme.rst:63 msgid "``wheel >= 0.31.0``" @@ -4424,7 +4463,7 @@ msgstr "" msgid "" "Install the latest version of `twine `_; " "version 1.12.0 or higher is required:" -msgstr "" +msgstr "安装最新版本的 `twine `_ ；需要1.12.0版或更高版本：" #: ../source/guides/making-a-pypi-friendly-readme.rst:122 msgid "" @@ -4445,7 +4484,7 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:4 msgid "Migrating to PyPI.org" -msgstr "" +msgstr "迁移到 PyPI.org" #: ../source/guides/migrating-to-pypi-org.rst:6 msgid "" @@ -4454,6 +4493,8 @@ msgid "" "expected to use. These are the tools and processes that people will need to " "interact with ``PyPI.org``." msgstr "" +":term:`pypi.org` 是新的、重写的 PyPI 版本，取代了传统的 PyPI 代码库。它是人们期望使用的 PyPI 的默认版本。这些是人们与 " +"``PyPI.org`` 互动所需的工具和流程。" #: ../source/guides/migrating-to-pypi-org.rst:12 msgid "Publishing releases" @@ -4461,7 +4502,7 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:14 msgid "``pypi.org`` is the default upload platform as of September 2016." -msgstr "" +msgstr "``pypi.org`` 是2016年9月起的默认上传平台。" #: ../source/guides/migrating-to-pypi-org.rst:16 msgid "" @@ -4483,11 +4524,11 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:24 msgid "``twine`` 1.8.0" -msgstr "" +msgstr "``twine`` 1.8.0" #: ../source/guides/migrating-to-pypi-org.rst:25 msgid "``setuptools`` 27.0.0" -msgstr "" +msgstr "``setuptools`` 27.0.0" #: ../source/guides/migrating-to-pypi-org.rst:26 msgid "Python 2.7.13 (``distutils`` update)" @@ -5038,22 +5079,24 @@ msgid "" "from `Microsoft's website `__." msgstr "" +"安装 \"Visual C++ Compiler Package for Python 2.7\"，它可以从 `微软的网站 `__ 获得。" #: ../source/guides/packaging-binary-extensions.rst:276 msgid "" "Use (a recent version of) setuptools in your setup.py (pip will do this for " "you, in any case)." -msgstr "" +msgstr "在您的 setup.py 中使用（最新版本的）setuptools（无论如何，pip 会帮你做这个）。" #: ../source/guides/packaging-binary-extensions.rst:278 #: ../source/guides/packaging-binary-extensions.rst:288 #: ../source/guides/packaging-binary-extensions.rst:295 msgid "Done." -msgstr "" +msgstr "完成了。" #: ../source/guides/packaging-binary-extensions.rst:280 msgid "For Python 3.4" -msgstr "" +msgstr "适用于Python 3.4" #: ../source/guides/packaging-binary-extensions.rst:282 msgid "" @@ -5061,6 +5104,9 @@ msgid "" "available from `Microsoft's website `__." msgstr "" +"安装 \"Windows SDK for Windows 7 and .NET Framework 4\"（v7." +"1），可从`微软网站`__ " +"获得。" #: ../source/guides/packaging-binary-extensions.rst:285 msgid "" @@ -5070,11 +5116,11 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:287 msgid "Set DISTUTILS_USE_SDK=1" -msgstr "" +msgstr "Set DISTUTILS_USE_SDK=1" #: ../source/guides/packaging-binary-extensions.rst:290 msgid "For Python 3.5" -msgstr "" +msgstr "适用于 Python 3.5" #: ../source/guides/packaging-binary-extensions.rst:292 msgid "" @@ -5082,6 +5128,8 @@ msgid "" "en-us/downloads/download-visual-studio-vs.aspx>`__ (or any later version, " "when these are released)." msgstr "" +"安装`Visual Studio 2015 社区版 `__ （或任何后来的版本，当这些版本发布时）。" #: ../source/guides/packaging-binary-extensions.rst:297 msgid "" @@ -5098,7 +5146,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:305 msgid "Binary extensions for Linux" -msgstr "" +msgstr "Linux 的二进制扩展" #: ../source/guides/packaging-binary-extensions.rst:307 msgid "" @@ -5110,7 +5158,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:313 msgid "Binary extensions for macOS" -msgstr "" +msgstr "macOS 的二进制扩展" #: ../source/guides/packaging-binary-extensions.rst:315 msgid "" @@ -5126,13 +5174,15 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:325 msgid "Publishing binary extensions" -msgstr "" +msgstr "发布二进制扩展" #: ../source/guides/packaging-binary-extensions.rst:327 msgid "" "For interim guidance on this topic, see the discussion in `this issue " "`_." msgstr "" +"关于这个主题的临时指导，请参见 `这个问题`_ 中的讨论。" #: ../source/guides/packaging-binary-extensions.rst:343 msgid "Additional resources" @@ -7573,11 +7623,11 @@ msgstr "" msgid "" "Spack is not in PyPI (yet), but it requires no installation and can be used " "immediately after cloning from GitHub." -msgstr "" +msgstr "Spack 不在 PyPI 中（目前），但它不需要安装，从 GitHub 克隆后可以立即使用。" #: ../source/key_projects.rst:617 msgid "zest.releaser" -msgstr "" +msgstr "zest.releaser" #: ../source/key_projects.rst:619 msgid "" @@ -8592,7 +8642,7 @@ msgstr "" #: ../source/overview.rst:208 msgid "`OpenShift `_" -msgstr "" +msgstr "`OpenShift `_" #: ../source/overview.rst:209 msgid "\"Serverless\" frameworks like `Zappa `_" @@ -12893,7 +12943,7 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:605 msgid "Installing from other sources" -msgstr "" +msgstr "从其他来源安装" #: ../source/tutorials/installing-packages.rst:607 msgid "" @@ -12943,7 +12993,7 @@ msgstr "" #: ../source/tutorials/managing-dependencies.rst:4 msgid "Managing Application Dependencies" -msgstr "" +msgstr "管理应用程序的依赖性" #: ../source/tutorials/managing-dependencies.rst:6 msgid "" @@ -13526,13 +13576,13 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:408 msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" -msgstr "" +msgstr "确保您安装了最新版本的 PyPA 的 :ref:`build`：" #: ../source/tutorials/packaging-projects.rst:422 msgid "" "If you have trouble installing these, see the :doc:`installing-packages` " "tutorial." -msgstr "" +msgstr "如果您在安装这些东西时遇到困难，请查看 :doc:`installing-packages`教程。" #: ../source/tutorials/packaging-projects.rst:425 msgid "" @@ -13563,7 +13613,7 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:460 msgid "Finally, it's time to upload your package to the Python Package Index!" -msgstr "" +msgstr "最后，是时候把您的软件包上传到 Python Package Index 了！" #: ../source/tutorials/packaging-projects.rst:462 msgid "" @@ -13588,12 +13638,12 @@ msgstr "" msgid "" "Now that you are registered, you can use :ref:`twine` to upload the " "distribution packages. You'll need to install Twine:" -msgstr "" +msgstr "现在您已经注册了，您可以使用 :ref:`twine` 来上传发行包。您需要安装 Twine：" #: ../source/tutorials/packaging-projects.rst:492 msgid "" "Once installed, run Twine to upload all of the archives under :file:`dist`:" -msgstr "" +msgstr "安装完毕后，运行 Twine 以上传 :file:`dist`下的所有档案：" #: ../source/tutorials/packaging-projects.rst:506 msgid "" @@ -13604,17 +13654,19 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:510 msgid "After the command completes, you should see output similar to this:" -msgstr "" +msgstr "命令完成后，您应该会看到类似这样的输出：" #: ../source/tutorials/packaging-projects.rst:523 msgid "" "Once uploaded your package should be viewable on TestPyPI, for example, " "https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" msgstr "" +"一旦上传，您的软件包应该可以在 TestPyPI 上查看，例如，https://test.pypi.org/project/example-pkg-" +"YOUR-USERNAME-HERE" #: ../source/tutorials/packaging-projects.rst:528 msgid "Installing your newly uploaded package" -msgstr "" +msgstr "安装您新上传的软件包" #: ../source/tutorials/packaging-projects.rst:530 msgid "" @@ -13625,13 +13677,13 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:546 msgid "Make sure to specify your username in the package name!" -msgstr "" +msgstr "请确保在软件包名称中指定您的用户名!" #: ../source/tutorials/packaging-projects.rst:548 msgid "" "pip should install the package from TestPyPI and the output should look " "something like this:" -msgstr "" +msgstr "pip应该会安装 TestPyPI 的软件包，输出结果应该是这样的：" #: ../source/tutorials/packaging-projects.rst:558 msgid "" @@ -13651,7 +13703,7 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:580 msgid "and import the package:" -msgstr "" +msgstr "并导入该软件包：" #: ../source/tutorials/packaging-projects.rst:588 msgid "" @@ -13729,3 +13781,4 @@ msgid "" "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:" "`hatch`, and :ref:`poetry`." msgstr "" +"考虑 :ref:`setuptools` 的替代方案，如 :ref:`flit`, :ref:`hatch`, 和 :ref:`poetry`。" diff --git a/locales/zh_Hant/LC_MESSAGES/messages.mo b/locales/zh_Hant/LC_MESSAGES/messages.mo index 9bcfaf222cc8cf133a68273e984f75539edf1de2..b16da9fb29741db5a3a8adcb7a71b019008a0905 100644 GIT binary patch delta 2606 zcmd_qUuYaf90%}e8{3$+Nt>FcHP&v8jpoem?cVPFOPW8}R0&?idJVQOW-qzD{shuQzlQYORY)r@LAvh`NGq?wD#=DzY(vnBfM)bGq?9c{+{-?NbI8CY zNN3<=mG^>IxUX|BaOb!eA=bn`;(p1!%3b9CT!sA8jlc7ba=gV&HMb7ZgzC9XknRt{ zUf2P#-E0cd3eQ2>$^}SgVEbn8dJ}Zd0B^@2Eik?r`KJMNbkM2q=NI0C_o4kc+=&eQ z3hBPB$Qw;?2b_Vsp$5N!cf*Z$crR|^wnKXEaqeMAFV@8g1NGLQJ0I1pq@7<{R-;+s8LkI}qf#0r)IF%Q1-BMT^-k0WP#gIL%4P?u%G!)8@`oUm6pOLT&J?X6NBr+MF4;{I54k}?)R-+N9p{PuWDxqjF0E3~hrm%plXriLv zkHWAhM?`r!jQ$lW^371;VS89q0z9UNyig0Pip&D4riG#b7SL2x3n)Pr2q{rnjs#h= zWu%&Q%uOHvYISMTP%dGmZ8Ix4rXU&p{o`|MrW<2v+Yyc!g}iAcZNV8xI6~5}`>b@Y zAr#DEOUPN~pwZ_@v#GMNvZDT&X*gCv*fZcbIlI~K&lQ{jGb`rYZppOz{cU;=)Ai1- z_`&XjU9osicYI$@yz>!VM{n1odt=?5``kFz^`PticszN;jcmgi&N-%;v4yr)L5)Zu zNnUxOXzRKV2urdgV>Bn9&Kh*9A}I>LH9ue&8S0ZI)$5~~VxqQ@Nr`FO9yXFvI-4^6 zNwd%PC#^)v5z~f~5(iD&5C@STF>myWNQpGy3}x7g$76s0{GgdN>{|xNS?Q64W855M zIl+u)vuD`K*t0*BPp>LQ#H2A&@n0M&_e?c=C-5H~s_BX=)k|Z?-NPg-P97`0d1mRI zXU9*hf30C`;`;IV(y3ER@4i(UeFN8Sy!zbYOBX1Zc=^W3x38a{`0nWFY}1C$|NWWT J|8Jft_9q{>-ZB6H delta 784 zcmYk)JuE{}6u|L=N9&`d^-a-53|h3lfX8j ze;fO7gs)q19UJik>oJAAB58DD1~u>phVUCBIKbpO&k0WB6HXFe+E{im18b-&-N1R= z#~T**iJF0Pnng??b4oQ)s?meGqaf<|9%=>-t^Ng;(N9?YTMW~`*Ky*Dm!~ZR@}o{L zMP4)$Gnl|R?7?!j*NkK6#wE)r>UX=A2dDv$u@}!!cbvf?^p%TD;3~$(xw+y-C&(g~ z{L(C-vqFS*2}f>@x1eUCiJDt@&0LrU^;!>DvvAaAW_75Fs@c_lhK-wrP0X4p)Zn?L zmX7|6ngu;uJ!gIoaZ&Z`HN9HckonWqm_3?cSD?oq2yn%_i{9ft+hx+Q?-\n" "Language-Team: Chinese (Traditional) \n" @@ -16,7 +16,7 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=1; plural=0;\n" -"X-Generator: Weblate 4.7.2-dev\n" +"X-Generator: Weblate 4.8-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -664,11 +664,11 @@ msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:25 msgid "**pip**" -msgstr "" +msgstr "**pip**" #: ../source/discussions/pip-vs-easy-install.rst:25 msgid "**easy_install**" -msgstr "" +msgstr "**easy_install**" #: ../source/discussions/pip-vs-easy-install.rst:27 msgid "Installs from :term:`Wheels `" @@ -1487,7 +1487,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:121 msgid "26190085" -msgstr "" +msgstr "26190085" #: ../source/guides/analyzing-pypi-package-downloads.rst:124 msgid "" @@ -1497,7 +1497,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:142 msgid "24334215" -msgstr "" +msgstr "24334215" #: ../source/guides/analyzing-pypi-package-downloads.rst:146 msgid "Package downloads over time" @@ -1515,51 +1515,51 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:170 msgid "1956741" -msgstr "" +msgstr "1956741" #: ../source/guides/analyzing-pypi-package-downloads.rst:170 msgid "2018-01-01" -msgstr "" +msgstr "2018-01-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:172 msgid "2344692" -msgstr "" +msgstr "2344692" #: ../source/guides/analyzing-pypi-package-downloads.rst:172 msgid "2017-12-01" -msgstr "" +msgstr "2017-12-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:174 msgid "1730398" -msgstr "" +msgstr "1730398" #: ../source/guides/analyzing-pypi-package-downloads.rst:174 msgid "2017-11-01" -msgstr "" +msgstr "2017-11-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:176 msgid "2047310" -msgstr "" +msgstr "2047310" #: ../source/guides/analyzing-pypi-package-downloads.rst:176 msgid "2017-10-01" -msgstr "" +msgstr "2017-10-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:178 msgid "1744443" -msgstr "" +msgstr "1744443" #: ../source/guides/analyzing-pypi-package-downloads.rst:178 msgid "2017-09-01" -msgstr "" +msgstr "2017-09-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:180 msgid "1916952" -msgstr "" +msgstr "1916952" #: ../source/guides/analyzing-pypi-package-downloads.rst:180 msgid "2017-08-01" -msgstr "" +msgstr "2017-08-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:184 msgid "Python versions over time" @@ -2218,15 +2218,15 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:327 msgid "keywords" -msgstr "" +msgstr "keywords" #: ../source/guides/distributing-packages-using-setuptools.rst:333 msgid "List keywords that describe your project." -msgstr "" +msgstr "列出描述您的項目的關鍵字。" #: ../source/guides/distributing-packages-using-setuptools.rst:337 msgid "project_urls" -msgstr "" +msgstr "project_urls" #: ../source/guides/distributing-packages-using-setuptools.rst:349 msgid "" @@ -4221,15 +4221,15 @@ msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:62 msgid "``setuptools >= 38.6.0``" -msgstr "" +msgstr "``setuptools >= 38.6.0``" #: ../source/guides/making-a-pypi-friendly-readme.rst:63 msgid "``wheel >= 0.31.0``" -msgstr "" +msgstr "``wheel >= 0.31.0``" #: ../source/guides/making-a-pypi-friendly-readme.rst:64 msgid "``twine >= 1.11.0``" -msgstr "" +msgstr "``twine >= 1.11.0``" #: ../source/guides/making-a-pypi-friendly-readme.rst:66 msgid "" @@ -4336,7 +4336,7 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:25 msgid "``setuptools`` 27.0.0" -msgstr "" +msgstr "``setuptools`` 27.0.0" #: ../source/guides/migrating-to-pypi-org.rst:26 msgid "Python 2.7.13 (``distutils`` update)" @@ -5935,19 +5935,19 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:170 msgid "``DISTUTILS_USE_SDK``" -msgstr "" +msgstr "``DISTUTILS_USE_SDK``" #: ../source/guides/supporting-windows-using-appveyor.rst:171 msgid "``MSSdk``" -msgstr "" +msgstr "``MSSdk``" #: ../source/guides/supporting-windows-using-appveyor.rst:172 msgid "``INCLUDE``" -msgstr "" +msgstr "``INCLUDE``" #: ../source/guides/supporting-windows-using-appveyor.rst:173 msgid "``LIB``" -msgstr "" +msgstr "``LIB``" #: ../source/guides/supporting-windows-using-appveyor.rst:175 msgid "" @@ -6071,7 +6071,7 @@ msgstr "" #: ../source/guides/tool-recommendations.rst:20 msgid ":ref:`pip`" -msgstr "" +msgstr ":ref:`pip`" #: ../source/guides/tool-recommendations.rst:22 msgid "`pip-tools `_" @@ -6079,7 +6079,7 @@ msgstr "" #: ../source/guides/tool-recommendations.rst:24 msgid "`Poetry `_" -msgstr "" +msgstr "`Poetry `_" #: ../source/guides/tool-recommendations.rst:27 msgid "Installation tool recommendations" @@ -9388,15 +9388,15 @@ msgstr "" #: ../source/specifications/binary-distribution-format.rst:316 msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" -msgstr "" +msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" #: ../source/specifications/binary-distribution-format.rst:317 msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" -msgstr "" +msgstr "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" #: ../source/specifications/binary-distribution-format.rst:321 msgid "Comparison to .egg" -msgstr "" +msgstr "與 .egg 的比較" #: ../source/specifications/binary-distribution-format.rst:323 msgid "" From dbb47997a706943574934e7d7ecc3c7d32ce1a19 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Sun, 29 Aug 2021 18:15:42 +0200 Subject: [PATCH 0096/1072] Translated using Weblate (Ukrainian) Currently translated at 15.0% (341 of 2271 strings) Translated using Weblate (Ukrainian) Currently translated at 14.3% (325 of 2271 strings) Co-authored-by: Sviatoslav Sydorenko Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/uk/ Translation: pypa/packaging.python.org --- locales/uk/LC_MESSAGES/messages.mo | Bin 25808 -> 26470 bytes locales/uk/LC_MESSAGES/messages.po | 40 ++++++++++++++--------------- 2 files changed, 20 insertions(+), 20 deletions(-) diff --git a/locales/uk/LC_MESSAGES/messages.mo b/locales/uk/LC_MESSAGES/messages.mo index fc76dea47295dcb9635150adea0bc0acd100e2b5..465996b0736cb23002db7c2a8b445de3042e6c36 100644 GIT binary patch delta 7759 zcmciGcX$^?9>?)XBMA^%0-*##2t9=4mmWwcCO~K+O+b_?9f4C~u(5im0p(5+6&3X; zf{G;^IRrfm8V-fSC?ZWnJW!gbhyqg7dw;TDP9LA=p6C9$dHnufGqbxhvoo{1!4J0v z9jOfRKC2h{h$CGcAX|M&SqM0rM-=fX-Vv ztfl8yM7Q+UE*`@;Asy90E@}V;sD}Gt2o6JaFw&f2mY{Cv9@O~@QER=#Ty3sLUBB5Q zqYgeoHN4--2T=_jv+}p70sV->F}Rh#_9IdCcc3<3DXPPzsHIqAZa|&4*{n3Zy_Pv- zo;1(mMJ~`5)|6dB-BCmvf6Aj#YuXBRJQ;O77q!_6tvu8mV@^Ze@XfxS^Q>Y%YJ`hW zcfJ%uafSITs)H9X7&oA%@HO*2)E)0O52HFdg*<`oJgVJ>ZT*4ASIPRfA)^aZ>_8r> z;X>4u4nk(#O+@yMyWcD`ccLE0bI60>qTBi9Ow>{gL~YJ77>OmQ_rYCwGyS`bWSDK2 z(w@7;p%{)oq8fHd{;rQhy&tkr^}R6+Ctw6lLv=XYoM%3Sx}oJ(F2fp>-^8lte;XNf zxC_<60n}r7%F2-){56lm+SGSM-9Z-|h{c$R?_v%73AJ>Q$^ISJ!bU-~i5g&9N58-B z9eMsWCB3Q82nSh)xe_w;$U83#b8wuoHE> zHZm5Mi1l$e7T^rjfY+f0@RpUgVVJ)Ed#W<*dQ`)QQJd!^>cUfY{3kPn4WX%xL``j7 zD>t!nB5L<1quNPBJ*HWx7grv3!LC?H|86cBjkE%LV|b3gBm*&q@=Vkl>~3=Y1H}WtUkE2|2~Pp!$G`$@dl1x;I1^olk@#o^16KHUnAN|MK|1w$=HYm z8jQVAGq4mjynq^bFfR`cu$o!djPoqh#!NHw%_4KKIm(=3 z&PEML?Z{Hp3_f5!h8nwTDoJX>o20G=P>kIozCzdVk!Gy7NUCg3C}HJ%bw928_T;jK@9rAf78?{dqLqd>+b%xEZy^2T=b& z2=C)}+|tZ4i_B}x>8Kf+Yd&PI#(hEjjfh&phx_>hScV$-rhd$SIGJ5k=!65PDLrmp zKz&SV^!H6Lvr!%PH^-XA7)kvCtci;;6qi|f6|(EyI;*er$f$#z=5bWRznIZi`b*FT z`QW)U)Y42w4SXi5qY`X{ccZ5KX;eGwQIF$R)Mh=3+MEps_6L)W4jo`sFE6xly+1-^zSkbUb`4di^L{3L2%dX093DCCbHmxt*%6SMUEuOy?* z@(I?$uTe8{$*ecTFSkYQkuK&iY)yFvh+2Unm5SdKcs64m}u)F!@wwXx<<=We8b z7e{6R6%Qac;Tm1-Z@#G*L%9^yz>|29J1avyW-ko)m*9QWn(xABJczoH@38`dNASFJ z-4^8Y;=aGezb-J60qgnCCDQ@>pk5Fq*a^!}YkdMc<9Dd{L-Mu$W*vljN=Bik{x(d+ zcTkVn5p03guJhY%hg~U;Mcu%1^a5lm$f$uc$i8!Vqx`>O@5AntUqDUu*O-nmqy2#t zVH?UfV0(N7^%QMFEy;FskJTTt@;6pKKbra1nuU$=FKmGIDYvk44r-SdqNcbXYDum} zy-=p1I-HG7@lI@lPoviOHPpbiS@{g={IIe9=Bzu`^DCNBp*3rd+9bJVU-LRthci)k zHV3uV^ROWiR9H_V$`bQRkmU4XpY&zrDsD8I33rbwUbeU;$?09PEoPqaLRV zr~!nJ_sjJ#jB>o$3N_Fq48aW4bvdZ>dYFAtGwTf`qp2NX72~Zu4fWQ);J9@_4jkAa$ zR(=ZCt85orwW~%smqG>(z#r{^o~X9eX~QWsC7(c~l3z~rAb%w`3}XJDAd^pYA-WQJ zj_Yv38<1Wd#6YV%g#~urA$?feQE>%v zrB&X$ct>pX;?HA4y=K&e5T`j>3(wJ*x3vNF zdbY+AN)Hlxi#$eLAfh;)jGMGH50JT>`g1^k1>8Z*CA4r#oqekQMKFkSl=cyNBPcyX z#8Ll8?1Qi2ejw~ZC2ULPJ0g?(H-2r^Zw|lj z5aF6XFOA$(Vj7|EM=wID8&~BL|0I6}-h^KgaYS>Ds=Xh^Ih@(86FK2`s0Uq!wn?cI!z5KYJ{ zwIL1?gDL+NUm-RSf6?khlBrA7=3oRdl)O>{;%nkxDv5>PFIatF z$}yH7KwfDfkxc$iRVDxDPH07JCI%7JIUa=_oEzuHkVztz5#JK;6894$h-(O?0z!Wo zUxg15i-~c>U_z-g$J+Z@_XDmZRug|vU3qeoxS-bA8KiU<$Vtr%q^IR%r)9Z7ZXhc+ zGYvDdvNHnw-{$Pa1LE=vQ*)A2DWwLolT&m5lMST)nhpG#O|z`7@v|A(>4DV6i{hHL z&vNMW~FDQW@V?Prk9t+B{z>hp0hOcf4zl6c{#oP!T?+TpKWHt%v{G9Hp4bHmknbxo7^Ubj>^VdqsXP)ihk-838kh&7ag4B zlCVlC5v5avC>6PdI=MvBiHUgQ2+8T!G~&ufr(Zfc)n^;*TbH64Nj=#<^;k zg;kvATt702R1C#PTwo2Bp$4`I8{$@MipR}RrpY8-D(ZS~E04$al;@crqZacfY9*>S zaIO)?V<^ve-O1=d`DTH6mpKVXa(yOh#-~tAf8M-m2E{rTLVZ=#7S*zH9IAaHYUR># zDrTXlCE83zH-3p~a0F}PDJ;V4s0SA^P1TRWI_P0VT!LD;6<8DBLQQB7R>rT*Gv=?T z0R3ygN&M@bhOHmVAZRO1v&hyU%Lb-QZi$maf@$6*BZX_$t$U_Q>owzv;<7J?J~t&7Bplxt$0fOD~^ z0d`1Y74*O!WYi!ZHNrty3CCa|PQexUC2EPMCHn(iWWI>nqLrwDzk_PG8_VO5s4wC< z)Yine@K>r^3)WvZ^rhk!9FE%CHONQJ?M2==_cNwrWJ|tU*aOwkTujBasQZs%Z;VS} zmN*Hsu^2fP?kjAK*HLFFC6)DO+ud#S!m7EM7>=)D7`|z4v-;1he8|ctu`2B@SosF( zS1_!V-%l)Rg_BS#+y?bqkcm1g{XH^zU;*;G;zpyEZZ<~Xa@4>!S@|fc{RPw(U9)ls z)2c$b8b)G6v$fe3^}vCsi4|cKdiRjgA@fipUySNtJ*va)=01#~d<-?P%cu^^webfO zj=Ek8`OhWthx#kR9Grq0@D|hnKJm+*J3vOS&vEk%s^fF0!*d07<5jyJ%n?`naMaR9 zqL#Lfl^a_*5%u9}i|VHX>b^|WhbtE|_5ODwlS{>H)JS(@4~*d5(w5wT)p0873pU?e zi`x6oP%}D$8u$;W0bN8r_?r1A>Tm`)$?C5UM)G_&f{d1Q3U8P!I6!n~9)QYY^PaSO_qYk#9ZrF+HcrR)O2T^C@ zYt$0{WY;gE+F!Byn^>80FfaS50E5MGlz;Ewujt4O{}cQMYCyX(SpUvszM>)-Ycl=* zn2TD0#i%9Tg4*ld=0WoaY5=FqpUrD#P$&O-gc*(MCmuE7ICs18f;9Daa&MctY%{uUiU4d^_!#Q)+$n8+)o`_>@m*u8~GcmY`{&qed@wV7^Nd zOw1*yl~|1$`3BVKf6x5fJdS#ge?iSW^CW78el;s}_sezh+W^~v+QN!G{Q=ZK4ZJOu{{HtQ zqXzv@OE%aXk2NUIGM_Wop&q!yJY=3leNS$n&QNGC|2t9xRgOlT`UI=b>Bai%0o|#P zgHavdZ$6G;lwU-?%5D{g;8CoAr%@fBNB!088fwX-^89|9qh7~MOu+)w;ap&D&13yl zae<0NjOoom#2$DnK7tz17pRWUU^HGwR@>F0(H0zn?4pbALwlBdC|068xvzh?A3=Vp z-9~JUr!fs{d-?uh>4Q2%!%!D)sZXt`=&5O;PQ0uo@O% zB#y@jd>AL8_cWQgWP4#{<_hLHn!rNSh~o4*BJPXb8)N#N{wW`XjVM2e>i1>L!b7MD)EuP0JF@@n$f$$6k!^JwF&1xPHpUkC zOFax*Q=W?&$W~0i@3A?C75W2fi`tTGGtcS=T6wsY@5QQm{~xf5d8oaA-pa3|PWij2 zCH@e#CA(1{loP0x_z7e1H>`_MgZ({ji5ggzmG4Hie*kqjXQQWzVlvvZWvD~4-rQ~; zKt1p@YGxNudwmsaW2GVfz~fQ(XQ2A)Z5E)~--9}Q9;&~mhOqt`z+!8#65CLI2lc*R zz+Tw6$RF`|)Bt8!c@73sUSuvsb^HpJ$JMBrzK&|Q#oUfs*INwH{fuQ03QrAH(X(D#S3~Y$gFcFuUyHIE2GOGV7Bm4<^waMtgF&KhP ztelJ*SQ=_Cvr!M~i(1kmR7c}b_fJK&pM^m<56k01)R|a>TESN_2-hL)J-5*=ypNT+ zumc0woKTwWQ~HYTA-|N!p+Q%x&%znROoCfWQ&X25cZg>Qr9|%SOlaGbT9D`C z=xSga)SHz?+#tNi_@fV@bdb1ARHR`z@d)_@+=SZOIHC^m*Q7&sh-g4Nr7HM_pLH9} z?Wnh6ft5F#KWqP6P-sb{SY?0?9wncRPv8#X3*v2}EZt8gfe5vSs(!BiAT1%jA+m`k zTrZM@4&ldy(lVl3X^!>(I~ko|rDojF%FnuQO>rB+51AWCBok$64w=V^PBswz(ygcb z5HXFoKvW>~t}E>$&X(rj*9$Guf3nHuZBGHg&qyj0G=t<}!ypqr- zL@Af98(H^1QEqMda^!Cku~vSG{Cq-xCn`%Xmt`>D&wK73tE_Gf*HErcKF8{_$ZsKk zhWMw|{mXn8KP0{+;%FB{R3$19jfu)cU#|T|G$!sM%F^>>2I(tMK<0?mM&K07cfj_< zdsa@Svvx$VmH)slL}j9#)y3j5%m0AYX#a0qK}3)bA&!&(523WH5`T0g;)xHmAu&zK zDUBiSF3s^PhKGr3rCU~=+*Kll&X%Ln)5JLsp=al|CX)>cwr(h4U0@;-46X<%qI$l+34AsA(2rJ=)Z=c5Te- z)c;O|5VMH4h!P@$>+`TXp_D;nmfpjbb+DV)QrS#bNmTnkA8@Pkq)6KB#pg;({0lOU zCngY|6YGdmgi>#x(*FZJO->a{mM5C-9sA diff --git a/locales/uk/LC_MESSAGES/messages.po b/locales/uk/LC_MESSAGES/messages.po index b3903d316..490283676 100644 --- a/locales/uk/LC_MESSAGES/messages.po +++ b/locales/uk/LC_MESSAGES/messages.po @@ -9,8 +9,8 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-08-05 16:13+0000\n" -"Last-Translator: meowmeowmeowcat \n" +"PO-Revision-Date: 2021-08-06 05:45+0000\n" +"Last-Translator: Sviatoslav Sydorenko \n" "Language-Team: Ukrainian \n" "Language: uk\n" @@ -1512,7 +1512,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:168 msgid "month" -msgstr "" +msgstr "month" #: ../source/guides/analyzing-pypi-package-downloads.rst:170 msgid "1956741" @@ -1520,7 +1520,7 @@ msgstr "1956741" #: ../source/guides/analyzing-pypi-package-downloads.rst:170 msgid "2018-01-01" -msgstr "" +msgstr "2018-01-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:172 msgid "2344692" @@ -1528,7 +1528,7 @@ msgstr "2344692" #: ../source/guides/analyzing-pypi-package-downloads.rst:172 msgid "2017-12-01" -msgstr "01.12.2017" +msgstr "2017-12-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:174 msgid "1730398" @@ -1536,31 +1536,31 @@ msgstr "1730398" #: ../source/guides/analyzing-pypi-package-downloads.rst:174 msgid "2017-11-01" -msgstr "" +msgstr "2017-11-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:176 msgid "2047310" -msgstr "" +msgstr "2047310" #: ../source/guides/analyzing-pypi-package-downloads.rst:176 msgid "2017-10-01" -msgstr "" +msgstr "2017-10-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:178 msgid "1744443" -msgstr "" +msgstr "1744443" #: ../source/guides/analyzing-pypi-package-downloads.rst:178 msgid "2017-09-01" -msgstr "" +msgstr "2017-09-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:180 msgid "1916952" -msgstr "" +msgstr "1916952" #: ../source/guides/analyzing-pypi-package-downloads.rst:180 msgid "2017-08-01" -msgstr "" +msgstr "2017-08-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:184 msgid "Python versions over time" @@ -1582,35 +1582,35 @@ msgstr "3.7" #: ../source/guides/analyzing-pypi-package-downloads.rst:207 msgid "18051328726" -msgstr "" +msgstr "18051328726" #: ../source/guides/analyzing-pypi-package-downloads.rst:209 msgid "3.6" -msgstr "" +msgstr "3.6" #: ../source/guides/analyzing-pypi-package-downloads.rst:209 msgid "9635067203" -msgstr "" +msgstr "9635067203" #: ../source/guides/analyzing-pypi-package-downloads.rst:211 msgid "3.8" -msgstr "" +msgstr "3.8" #: ../source/guides/analyzing-pypi-package-downloads.rst:211 msgid "7781904681" -msgstr "" +msgstr "7781904681" #: ../source/guides/analyzing-pypi-package-downloads.rst:213 msgid "2.7" -msgstr "" +msgstr "2.7" #: ../source/guides/analyzing-pypi-package-downloads.rst:213 msgid "6381252241" -msgstr "" +msgstr "6381252241" #: ../source/guides/analyzing-pypi-package-downloads.rst:215 msgid "null" -msgstr "" +msgstr "null" #: ../source/guides/analyzing-pypi-package-downloads.rst:215 msgid "2026630299" From 7c36136cb3fe5f4284f47896576d24b282b98747 Mon Sep 17 00:00:00 2001 From: Adolfo Jayme Barrientos Date: Sun, 29 Aug 2021 18:15:42 +0200 Subject: [PATCH 0097/1072] Translated using Weblate (Spanish) Currently translated at 5.3% (122 of 2271 strings) Added translation using Weblate (Spanish) Co-authored-by: Adolfo Jayme Barrientos Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/es/ Translation: pypa/packaging.python.org --- locales/es/LC_MESSAGES/messages.mo | Bin 0 -> 10362 bytes locales/es/LC_MESSAGES/messages.po | 9268 ++++++++++++++++++++++++++++ 2 files changed, 9268 insertions(+) create mode 100644 locales/es/LC_MESSAGES/messages.mo create mode 100644 locales/es/LC_MESSAGES/messages.po diff --git a/locales/es/LC_MESSAGES/messages.mo b/locales/es/LC_MESSAGES/messages.mo new file mode 100644 index 0000000000000000000000000000000000000000..650480cfe77d5931ca19931f50bb573bc4a1b16a GIT binary patch literal 10362 zcmbW6dyHJyUB_=8q^(H`HZ6fd(pwz$yeQAH(?+CKm_L=i}BBq*V=A_x#f2?#BsQq@KvME@vF{-}sRC@K%NO;tg~ z=X=h%GqY0ehh?_;5WecgTDi6|5rTzJt#ij@c0%e zzTd^>8h0yr3wX%mqW_+PKgaivgFg>`4rFTZD!2#yI;eeb_>my^0Jsyp9=sjY_ru_| z;1O^)cofw93_J)v2}D-sB`!(C^_%sP$jQ@pyY8EsP8Rs3haYF13n8P zvfvd^`tv1Fs`D?P`22TJ^RGh~kRH4r6o1p8T@T#Ldmq&NXTT4Fe*#L*uYsEXAK+o| zMn3)!I0uT42SKg742s?^2n#_5il2{x{0pAp4@(4}2i5-ycm(_k_#tp7#GVF^gDvn` z@K*4fpyYcKho|$~#h-V99|YBZ5M+s95fq(W(C!OL4$pw1?=#>r@I}yoZ~6X@qMU3I z7*OjBLCNEjpw9ngQ0u-9Vw%DC{P*vJ$9caE5m{z_*bCx`^%v8=D$El3jW9AE)K`?32L2#9#4a^yT|?eCqa#S0hC?-DflS(DyV%L z3~qo;P<*U`+V@xd`ycrCzXc_)H$koQEpQgRkx4V)X%Lo!-vlM6=Ruw0UwHho$FGCZ z_cuXE2)+m23BCvAx(oaWC_DZ*2&=)bf#Ux;a6fnn)c&ve{%?bbFnBjcBD@Whz1+i} zyTM05$^U6k=k=GM)_nt%y?!6mdG1D8q<<|?=VU(k&q@HtR)y$Xu2e*|U6Z-83o zUqSJ;i^DhyhM@Fj71Vma3~K)uK-uL#fIka<2h_gr3*A0bpzQA<@WbGfpw8!IP;z|( zRR4ED$>kQDg!tJFiq08OY^Dg@UuS^9YksPBhB@pTkD20jGd1AYeVfvC8o^Y^;7B6xO*#`LskducPYchKaELRyC=zoO^8G>+ZIH`zi)TcYix$;K2%HfZ~3dT?zvhOL8Z zw4*fX^20PeAEkZB{&Ig#0tsz__5jV$q?7m2?x#ubraK`=*R~Q5oqYiy%;Qc~GY}Wy zY8CfPa0Ev97=`V2FY6ZVcG!z^XwRT5hOC|mhY((~B=*;`q~|^|qw2H1C80T5D-EM= zH>=XJ{vv^`WJ!`;6m=^xA}Y$f>Xub*!X)cPNiy`)HDGpfS+|BhM`3A-a!lX2XE5{< zpDwe0GXAc82T}Jzw95YMS_HFk(X9$A?O@9`VL2SoKbIDw36{fdl!keghKs{;4RNpJ zS>K*~7x71FFHGXpTxmS2aJ9jlbS`D+nSn`rC_&7YM39e6m@vKhFvnRGVT%4aAW;cZ-Y%Ho#Vqd?s9=N**hA@Twaw{ZA&N0Z^fKpX8m&rFGlM}Acb#l!C-v@R)HlIN zybrc$21Rf(3r^W%mNia=-P$p%$9Y+yw8%TovsCsToU+1dd5`Aama{BzF6@e14ns?l zar4(rF75(dcHlka2{`$uSD{)uEVN|v)@JMlhuO- zU?pY6?<6W^dN|Ym02y`SBrbCGPHIn*_~c%>fs1PHgj8wWM!!NfX&xSWz({l-(jS9d<_o$Yu;*coa}%K8)I6t2_|wAN^33ea z^33?l(%g|#OS9v57ZAeTSsr7?GD(bn1=H?HIO4!19#XcdjFX~WdyhR~Tr};*me%lM zjO)c!baHez>cGQ#Oe`qNL396p8+;|g=HUYe4oowR%%I(#*0PN_UCFj21PX~#0$hwp zD120%8u_ChBIbnw+LCxLLRhgNqmX6SeoJmlIRJh~al_>X%z$eJ1*<92IOle~_6~d; zfXcBtMI$o^y>_!Dp2+?o>yl*>Ypws|oGKEVI7*5Dz<1uO}e#xgc>i- z(|^IF^{3R)mqg=uOX?#NWf)ufrX-8k2KWD-sP`h zRD^rkZm&jbM;!|}tWj1;&d|@Y-gHp=Jte@}iKsR51?LC}tIcq6!Z!UU?;d2`E$1E{ zlzW(&bPx5=@d3y^hzN+u`(azGeU&V<^01`f#IX)^|`_E^l5ct0eP<=H{RGP3~Xj6jwTtN*%oa=JTW-*k%+G z%sHzQ5OI1OoMffI+6&qz6}3@hwx2X2?q#+-RaH8SV2;`@ zBD`*1qHN6#9)PL76pb@hNwYqIu$Q6UzEVXNCK<7QH+4m_c?k*d10oI8_2y^8qQblS zGSw2~3e7z1R;paxUWwh_Ris1|%4!5neFE*&dYqxFQr*-MTU*z)W#_1GJN1xRnN9@v zc;3;dD-^DyJ_#+#yKC_}Kd^32=kZGA)GX^z2?xtDxu8hgPKU|02(I2Tz@%_cnI0^1 zDN&IM`Q(hLg$@ViHZP?Hbu%H;khBi*|6Bwg^tLOEiw!gjYg6egAxJpGt7N7C;HfX`G8TsN^KDSE;b8kvaWInYoDJrfywFtT_d#YtgZq5uL}? z^7!+XlKBecOw`U-=!ICzUEeB>f?!VEgbbgDp+r|@G-GU0^ZNGVP@WZ8>h|T{j^A1k z5-sLjjeNvbidaH@PHIXAe?5t<g=CQCFaI*cw4Y)12i8b7gENS&B)L>cYPl^{o3KD<~sde{ml;Id5_-ns*tp}@3~yK&PltX#)o$Q$=)bv2d`J&PjPQt`y`u45_?!#zQQH|?rK4L zOe&CLfF)Vyk*q*FomEk`Vm)%CUE+~-G=9VJcpDz-{gQ0ThdHBbf{9T?z`C@I@+7N+ zA*t2YfeLFXsN*N1tsT65kY*cYZH^_#ZY*Gi*?KcsVU84eM@?%}hOn!5P zi@sP(AhXa*me>Q)MCq)jWXx<3v~#pTen$b5ybnLM zzWKc6{B&UTszo%EA? zirNvmDK>R=nS~Zxi-uM+3(ks=9Vsm7Tx#{BL|0&|m0n#=U#DFbGa9EX!p2FN5mCZ) zH!tZbuNfR4`)K9xT-kGbF*epo7e2bqz>~B#FXii87ii1+Uc-9$(U#+@4eJd>0XwdF zqvDqQj5U1ALLHj5TFp#w##u!zpixK7Jw?jMH3Vm~CrFmK>_A&%N0GbgAVkTA&R3GR zf-@H%h8tUHzA47H9XKMlpYA;r$|gD2uzn`n343T0o@0xgGH6pW=+0k9H6;z&yma16 zXfL~)-d^@c5hM2>a$Jff_CLO&Fmrp8hT*OH87e=z6UoNcA+Ab84aWW~tql2^QoY)n zk$TmP$em1fIY)OIwIZYEO4>TQneC2la>nJZP8Stblv5!2, 2021. +msgid "" +msgstr "" +"Project-Id-Version: Python Packaging User Guide\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-07-06 19:32+0800\n" +"PO-Revision-Date: 2021-08-09 18:25+0000\n" +"Last-Translator: Adolfo Jayme Barrientos \n" +"Language-Team: Spanish \n" +"Language: es\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=2; plural=n != 1;\n" +"X-Generator: Weblate 4.8-dev\n" + +#: ../source/contribute.rst:5 +msgid "Contribute to this guide" +msgstr "Contribuya a esta guía" + +#: ../source/contribute.rst:7 +msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" +msgstr "" + +#: ../source/contribute.rst:10 +msgid "Reading the guide and giving feedback" +msgstr "" + +#: ../source/contribute.rst:11 +msgid "Reviewing new contributions" +msgstr "" + +#: ../source/contribute.rst:12 +msgid "Revising existing content" +msgstr "Revisar el contenido existente" + +#: ../source/contribute.rst:13 +msgid "Writing new content" +msgstr "Escribir contenido nuevo" + +#: ../source/contribute.rst:15 +msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." +msgstr "" + +#: ../source/contribute.rst:24 +msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." +msgstr "" + +#: ../source/contribute.rst:31 +msgid "Documentation types" +msgstr "Tipos de documentación" + +#: ../source/contribute.rst:33 +msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." +msgstr "" + +#: ../source/contribute.rst:38 +#: ../source/tutorials/index.rst:2 +msgid "Tutorials" +msgstr "Tutoriales" + +#: ../source/contribute.rst:40 +msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." +msgstr "" + +#: ../source/contribute.rst:47 +#: ../source/guides/index.rst:2 +msgid "Guides" +msgstr "Guías" + +#: ../source/contribute.rst:49 +msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." +msgstr "" + +#: ../source/contribute.rst:56 +#: ../source/discussions/index.rst:2 +msgid "Discussions" +msgstr "Debates" + +#: ../source/contribute.rst:58 +msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." +msgstr "" + +#: ../source/contribute.rst:63 +msgid "Specifications" +msgstr "Especificaciones" + +#: ../source/contribute.rst:65 +msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." +msgstr "" + +#: ../source/contribute.rst:73 +msgid "Building the guide locally" +msgstr "" + +#: ../source/contribute.rst:75 +msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" +msgstr "" + +#: ../source/contribute.rst:79 +msgid "`Nox `_. You can install or upgrade nox using ``pip``::" +msgstr "" + +#: ../source/contribute.rst:84 +msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." +msgstr "" + +#: ../source/contribute.rst:91 +msgid "To build the guide, run the following bash command in the source folder::" +msgstr "" + +#: ../source/contribute.rst:95 +msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." +msgstr "" + +#: ../source/contribute.rst:100 +msgid "You can build the guide and serve it via an HTTP server using the following command::" +msgstr "" + +#: ../source/contribute.rst:105 +msgid "The guide will be browsable via http://localhost:8000." +msgstr "Podrá explorar la guía a través de http://localhost:8000." + +#: ../source/contribute.rst:109 +msgid "Where the guide is deployed" +msgstr "" + +#: ../source/contribute.rst:111 +msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." +msgstr "" + +#: ../source/contribute.rst:117 +msgid "Style guide" +msgstr "Guía de estilo" + +#: ../source/contribute.rst:119 +msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." +msgstr "" + +#: ../source/contribute.rst:126 +msgid "Purpose" +msgstr "Propósito" + +#: ../source/contribute.rst:128 +msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." +msgstr "" + +#: ../source/contribute.rst:133 +msgid "Scope" +msgstr "Alcance" + +#: ../source/contribute.rst:135 +msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." +msgstr "" + +#: ../source/contribute.rst:138 +msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." +msgstr "" + +#: ../source/contribute.rst:146 +msgid "Audience" +msgstr "Audiencia" + +#: ../source/contribute.rst:148 +msgid "The audience of this guide is anyone who uses Python with packages." +msgstr "" + +#: ../source/contribute.rst:150 +msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." +msgstr "" + +#: ../source/contribute.rst:154 +msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." +msgstr "" + +#: ../source/contribute.rst:160 +msgid "Voice and tone" +msgstr "Voz y tono" + +#: ../source/contribute.rst:162 +msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." +msgstr "" + +#: ../source/contribute.rst:165 +msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." +msgstr "" + +#: ../source/contribute.rst:170 +msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." +msgstr "" + +#: ../source/contribute.rst:177 +msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." +msgstr "" + +#: ../source/contribute.rst:184 +msgid "Conventions and mechanics" +msgstr "" + +#: ../source/contribute.rst:192 +msgid "**Write to the reader**" +msgstr "**Escriba dirigiéndose a quien lee**" + +#: ../source/contribute.rst:187 +msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." +msgstr "" +"Al dar recomendaciones o pasos que seguir, diríjase de *usted* a la " +"audiencia lectora o utilice el modo imperativo." + +#: ../source/contribute.rst:0 +msgid "Wrong: To install it, the user runs…" +msgstr "Incorrecto: Para instalarlo, el usuario ejecuta…" + +#: ../source/contribute.rst:0 +msgid "Right: You can install it by running…" +msgstr "Correcto: Puede instalarlo ejecutando…" + +#: ../source/contribute.rst:0 +msgid "Right: To install it, run…" +msgstr "Correcto: Para instalarlo, ejecute…" + +#: ../source/contribute.rst:198 +msgid "**State assumptions**" +msgstr "" + +#: ../source/contribute.rst:195 +msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." +msgstr "" + +#: ../source/contribute.rst:203 +msgid "**Cross-reference generously**" +msgstr "" + +#: ../source/contribute.rst:201 +msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." +msgstr "" + +#: ../source/contribute.rst:213 +msgid "**Respect naming practices**" +msgstr "" + +#: ../source/contribute.rst:206 +msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: Pip uses…" +msgstr "Incorrecto: Pip utiliza…" + +#: ../source/contribute.rst:0 +msgid "Right: pip uses…" +msgstr "Correcto: pip utiliza…" + +#: ../source/contribute.rst:0 +msgid "Wrong: …hosted on github." +msgstr "Incorrecto: … se aloja en github." + +#: ../source/contribute.rst:0 +msgid "Right: …hosted on GitHub." +msgstr "Correcto: … se aloja en GitHub." + +#: ../source/contribute.rst:222 +msgid "**Use a gender-neutral style**" +msgstr "" + +#: ../source/contribute.rst:216 +msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: A maintainer uploads the file. Then he…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then they…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then the maintainer…" +msgstr "" + +#: ../source/contribute.rst:234 +msgid "**Headings**" +msgstr "**Títulos**" + +#: ../source/contribute.rst:225 +msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." +msgstr "" + +#: ../source/contribute.rst:230 +msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: Things You Should Know About Python" +msgstr "Incorrecto: Cosas Que Debe Saber Acerca de Python" + +#: ../source/contribute.rst:0 +msgid "Right: Things you should know about Python" +msgstr "Correcto: Cosas que debe saber acerca de Python" + +#: ../source/contribute.rst:237 +msgid "**Numbers**" +msgstr "**Números**" + +#: ../source/contribute.rst:237 +msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:4 +msgid "Deploying Python applications" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Page Status" +msgstr "Estado de página" + +#: ../source/discussions/deploying-python-applications.rst:6 +#: ../source/guides/index-mirrors-and-caches.rst:7 +#: ../source/guides/installing-using-linux-tools.rst:7 +#: ../source/guides/packaging-binary-extensions.rst:7 +#: ../source/guides/supporting-multiple-python-versions.rst:7 +#: ../source/guides/supporting-windows-using-appveyor.rst:5 +msgid "Incomplete" +msgstr "Incompleta" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Last Reviewed" +msgstr "Última revisión" + +#: ../source/discussions/deploying-python-applications.rst:7 +msgid "2014-11-11" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:11 +#: ../source/discussions/install-requires-vs-requirements.rst:9 +#: ../source/guides/analyzing-pypi-package-downloads.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:22 +#: ../source/guides/index-mirrors-and-caches.rst:12 +#: ../source/guides/installing-scientific-packages.rst:9 +#: ../source/guides/packaging-binary-extensions.rst:17 +#: ../source/guides/supporting-multiple-python-versions.rst:12 +#: ../source/guides/supporting-windows-using-appveyor.rst:15 +#: ../source/overview.rst:23 +#: ../source/specifications/core-metadata.rst:38 +#: ../source/specifications/direct-url.rst:14 +#: ../source/tutorials/installing-packages.rst:23 +msgid "Contents" +msgstr "Contenido" + +#: ../source/discussions/deploying-python-applications.rst:14 +msgid "Overview" +msgstr "Visión de conjunto" + +#: ../source/discussions/deploying-python-applications.rst:18 +msgid "Supporting multiple hardware platforms" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:40 +msgid "OS packaging & installers" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:52 +msgid "Windows" +msgstr "Windows" + +#: ../source/discussions/deploying-python-applications.rst:61 +msgid "Pynsist" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:63 +msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:70 +msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:74 +msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:80 +msgid "Application bundles" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:91 +msgid "Configuration management" +msgstr "" + +#: ../source/discussions/index.rst:4 +msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:5 +msgid "install_requires vs requirements files" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:382 +msgid "install_requires" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:14 +msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:19 +msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:29 +msgid "Additionally, it's best practice to indicate any known lower or upper bounds." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:31 +msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:41 +msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:51 +msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:56 +msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:64 +#: ../source/tutorials/installing-packages.rst:460 +msgid "Requirements files" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:66 +msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:69 +msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:73 +msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:78 +msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:84 +msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:90 +msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:6 +msgid "pip vs easy_install" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:9 +msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:14 +msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:22 +msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**pip**" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**easy_install**" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +msgid "Installs from :term:`Wheels `" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Yes" +msgstr "Sí" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:30 +#: ../source/discussions/pip-vs-easy-install.rst:32 +#: ../source/discussions/pip-vs-easy-install.rst:35 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:51 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "No" +msgstr "No" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Uninstall Packages" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Yes (``python -m pip uninstall``)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Dependency Overrides" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Yes (:ref:`Requirements Files `)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "List Installed Packages" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:38 +msgid ":pep:`438` Support" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Installation format" +msgstr "Formato de instalación" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "'Flat' packages with :file:`egg-info` metadata." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Encapsulated Egg format" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:44 +msgid "sys.path modification" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:48 +msgid "Installs from :term:`Eggs `" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "`pylauncher support`_" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "Yes [1]_" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:54 +msgid ":ref:`Multi-version Installs`" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Exclude scripts during install" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "per project index" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Only in virtualenv" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Yes, via setup.cfg" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:68 +msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:5 +msgid "Wheel vs Egg" +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:7 +msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:11 +msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:14 +msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:17 +msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:20 +msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:22 +msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:26 +msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:31 +msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:34 +msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:38 +msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:41 +msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:47 +msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." +msgstr "" + +#: ../source/glossary.rst:3 +msgid "Glossary" +msgstr "" + +#: ../source/glossary.rst:8 +msgid "Binary Distribution" +msgstr "" + +#: ../source/glossary.rst:11 +msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." +msgstr "" + +#: ../source/glossary.rst:14 +msgid "Built Distribution" +msgstr "" + +#: ../source/glossary.rst:17 +msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." +msgstr "" + +#: ../source/glossary.rst:26 +msgid "Distribution Package" +msgstr "" + +#: ../source/glossary.rst:29 +msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." +msgstr "" + +#: ../source/glossary.rst:34 +msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." +msgstr "" + +#: ../source/glossary.rst:41 +msgid "Egg" +msgstr "" + +#: ../source/glossary.rst:44 +msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" +msgstr "" + +#: ../source/glossary.rst:49 +msgid "Extension Module" +msgstr "" + +#: ../source/glossary.rst:52 +msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." +msgstr "" + +#: ../source/glossary.rst:59 +msgid "Known Good Set (KGS)" +msgstr "" + +#: ../source/glossary.rst:62 +msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." +msgstr "" + +#: ../source/glossary.rst:68 +msgid "Import Package" +msgstr "" + +#: ../source/glossary.rst:71 +msgid "A Python module which can contain other modules or recursively, other packages." +msgstr "" + +#: ../source/glossary.rst:74 +msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." +msgstr "" + +#: ../source/glossary.rst:78 +msgid "Module" +msgstr "" + +#: ../source/glossary.rst:81 +msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." +msgstr "" + +#: ../source/glossary.rst:84 +msgid "Package Index" +msgstr "" + +#: ../source/glossary.rst:87 +msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." +msgstr "" + +#: ../source/glossary.rst:90 +msgid "Per Project Index" +msgstr "" + +#: ../source/glossary.rst:93 +msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." +msgstr "" + +#: ../source/glossary.rst:97 +msgid "Project" +msgstr "" + +#: ../source/glossary.rst:100 +msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." +msgstr "" + +#: ../source/glossary.rst:104 +msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." +msgstr "" + +#: ../source/glossary.rst:110 +msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." +msgstr "" + +#: ../source/glossary.rst:115 +msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." +msgstr "" + +#: ../source/glossary.rst:121 +msgid "Pure Module" +msgstr "" + +#: ../source/glossary.rst:124 +msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." +msgstr "" + +#: ../source/glossary.rst:127 +msgid "Python Packaging Authority (PyPA)" +msgstr "" + +#: ../source/glossary.rst:130 +msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." +msgstr "" + +#: ../source/glossary.rst:139 +msgid "Python Package Index (PyPI)" +msgstr "" + +#: ../source/glossary.rst:142 +msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." +msgstr "" + +#: ../source/glossary.rst:145 +msgid "pypi.org" +msgstr "" + +#: ../source/glossary.rst:148 +msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." +msgstr "" + +#: ../source/glossary.rst:152 +msgid "pyproject.toml" +msgstr "" + +#: ../source/glossary.rst:155 +msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." +msgstr "" + +#: ../source/glossary.rst:157 +msgid "Release" +msgstr "" + +#: ../source/glossary.rst:160 +msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." +msgstr "" + +#: ../source/glossary.rst:163 +msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." +msgstr "" + +#: ../source/glossary.rst:168 +msgid "Requirement" +msgstr "" + +#: ../source/glossary.rst:171 +msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." +msgstr "" + +#: ../source/glossary.rst:177 +msgid "Requirement Specifier" +msgstr "" + +#: ../source/glossary.rst:180 +msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" +msgstr "" + +#: ../source/glossary.rst:187 +msgid "Requirements File" +msgstr "" + +#: ../source/glossary.rst:190 +msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." +msgstr "" + +#: ../source/glossary.rst:194 +#: ../source/guides/distributing-packages-using-setuptools.rst:56 +msgid "setup.py" +msgstr "" + +#: ../source/glossary.rst:195 +#: ../source/guides/distributing-packages-using-setuptools.rst:77 +msgid "setup.cfg" +msgstr "" + +#: ../source/glossary.rst:198 +msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." +msgstr "" + +#: ../source/glossary.rst:201 +msgid "Source Archive" +msgstr "" + +#: ../source/glossary.rst:204 +msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:208 +msgid "Source Distribution (or \"sdist\")" +msgstr "" + +#: ../source/glossary.rst:211 +msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:216 +msgid "System Package" +msgstr "" + +#: ../source/glossary.rst:219 +msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." +msgstr "" + +#: ../source/glossary.rst:222 +msgid "Version Specifier" +msgstr "" + +#: ../source/glossary.rst:225 +msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." +msgstr "" + +#: ../source/glossary.rst:231 +msgid "Virtual Environment" +msgstr "" + +#: ../source/glossary.rst:234 +msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/glossary.rst:238 +msgid "Wheel" +msgstr "" + +#: ../source/glossary.rst:241 +msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." +msgstr "" + +#: ../source/glossary.rst:244 +msgid "Working Set" +msgstr "" + +#: ../source/glossary.rst:247 +msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:3 +msgid "Analyzing PyPI package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:5 +msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:15 +#: ../source/guides/supporting-windows-using-appveyor.rst:18 +msgid "Background" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:17 +msgid "PyPI does not display download statistics for a number of reasons: [#]_" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:19 +msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:24 +msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:27 +msgid "``pip``'s download cache (lowers download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:28 +msgid "Internal or unofficial mirrors (can both raise or lower download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:29 +msgid "Packages not hosted on PyPI (for comparisons sake)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:30 +msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:32 +msgid "Known historical data quality issues (lowers download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:34 +msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:38 +msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:43 +msgid "Public dataset" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:45 +msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:50 +msgid "Getting set up" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:52 +msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:58 +msgid "Navigate to the `BigQuery web UI`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:59 +msgid "Create a new project." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:60 +msgid "Enable the `BigQuery API `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:63 +msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:69 +msgid "Data schema" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:71 +msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +msgid "Column" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/guides/using-manifest-in.rst:67 +#: ../source/specifications/core-metadata.rst:185 +msgid "Description" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/specifications/direct-url.rst:226 +msgid "Examples" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "timestamp" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "Date and time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "``2020-03-09 00:33:03 UTC``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "file.project" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "Project name" +msgstr "Nombre de proyecto" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "``pipenv``, ``nose``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "file.version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "Package version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "``0.1.6``, ``1.4.2``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "details.installer.name" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "Installer" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "pip, `bandersnatch`_" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "details.python" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "Python version" +msgstr "Versión de Python" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "``2.7.12``, ``3.6.4``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:93 +msgid "Useful queries" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:95 +msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:97 +msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:102 +msgid "Counting package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:104 +msgid "The following query counts the total number of downloads for the project \"pytest\"." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:119 +#: ../source/guides/analyzing-pypi-package-downloads.rst:140 +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "num_downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:121 +msgid "26190085" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:124 +msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:142 +msgid "24334215" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:146 +msgid "Package downloads over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:148 +msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +msgid "month" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "1956741" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "2018-01-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2344692" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2017-12-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "1730398" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "2017-11-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2047310" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2017-10-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "1744443" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "2017-09-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "1916952" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "2017-08-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:184 +msgid "Python versions over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:186 +msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "python" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "3.7" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "18051328726" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "3.6" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "9635067203" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "3.8" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "7781904681" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "2.7" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "6381252241" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "null" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "2026630299" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "3.5" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "1894153540" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:221 +msgid "Caveats" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:223 +msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:231 +msgid "Additional tools" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:233 +msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:237 +msgid "``google-cloud-bigquery``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:239 +msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:267 +msgid "``pypinfo``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:269 +msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:273 +msgid "Install `pypinfo`_ using pip." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:279 +msgid "Usage:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:295 +msgid "``pandas-gbq``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:297 +msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:301 +#: ../source/specifications/binary-distribution-format.rst:459 +msgid "References" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:303 +msgid "`PyPI Download Counts deprecation email `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:304 +msgid "`PyPI BigQuery dataset announcement email `__" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:3 +msgid "Creating and discovering plugins" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:5 +msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:10 +msgid "There are three major approaches to doing automatic plugin discovery:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:12 +msgid "`Using naming convention`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:13 +msgid "`Using namespace packages`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:14 +msgid "`Using package metadata`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:18 +msgid "Using naming convention" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:20 +msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:38 +msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:48 +msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:59 +msgid "Using namespace packages" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:61 +msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:89 +msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:101 +msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:115 +msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:121 +msgid "Using package metadata" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:123 +msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:128 +msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:139 +msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:154 +msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:163 +msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:166 +msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:170 +msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:5 +msgid "Packaging and distributing projects" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:7 +msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:11 +msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:15 +msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:25 +msgid "Requirements for packaging and distributing" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:26 +msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:29 +msgid "Install \"twine\" [1]_:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:43 +msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:49 +msgid "Configuring your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:53 +msgid "Initial files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:58 +msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:63 +msgid ":file:`setup.py` serves two primary functions:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:65 +msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:71 +msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:79 +msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:86 +msgid "README.rst / README.md" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:88 +msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:95 +msgid "For an example, see `README.md `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:99 +msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:108 +msgid "MANIFEST.in" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:110 +msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:115 +msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:119 +msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:122 +msgid "LICENSE.txt" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:124 +msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:130 +msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:135 +msgid "" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:137 +msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:141 +msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:149 +msgid "setup() args" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:151 +msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:155 +msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:164 +msgid "name" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:170 +msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:174 +msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:176 +msgid "Start & end with an ASCII letter or digit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:178 +msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:190 +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "version" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:196 +msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:200 +msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:203 +msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:206 +msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:214 +msgid "description" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:222 +msgid "Give a short and long description for your project." +msgstr "Brinde una descripción breve y una larga del proyecto." + +#: ../source/guides/distributing-packages-using-setuptools.rst:224 +msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:229 +msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:235 +msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:245 +msgid "url" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:252 +msgid "Give a homepage URL for your project." +msgstr "Proporcione un URL de página principal del proyecto." + +#: ../source/guides/distributing-packages-using-setuptools.rst:256 +msgid "author" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:263 +msgid "Provide details about the author." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:267 +msgid "license" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:273 +msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:279 +msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:287 +msgid "classifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:316 +msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:319 +msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:327 +msgid "keywords" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:333 +msgid "List keywords that describe your project." +msgstr "Añada palabras clave que describan su proyecto." + +#: ../source/guides/distributing-packages-using-setuptools.rst:337 +msgid "project_urls" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:349 +msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:355 +msgid "packages" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:361 +msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:370 +msgid "py_modules" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:376 +msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:388 +msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:392 +msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:398 +msgid "python_requires" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:400 +msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:407 +msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:412 +msgid "And so on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:416 +msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:422 +msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:431 +msgid "package_data" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:440 +msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:445 +msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:449 +msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:457 +msgid "data_files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:463 +msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:469 +msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:479 +msgid "For more information see the distutils section on `Installing Additional Files `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:484 +msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:491 +msgid "scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:493 +msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:500 +msgid "entry_points" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:509 +msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:512 +msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:516 +msgid "The most commonly used entry point is \"console_scripts\" (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:521 +msgid "console_scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:531 +msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:538 +msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:545 +msgid "Choosing a versioning scheme" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:548 +msgid "Standards compliance for interoperability" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:550 +msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:556 +msgid "Here are some examples of compliant version numbers::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:567 +msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:573 +msgid "Scheme choices" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:576 +msgid "Semantic versioning (preferred)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:578 +msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:582 +msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:585 +msgid "MAJOR version when they make incompatible API changes," +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:586 +msgid "MINOR version when they add functionality in a backwards-compatible manner, and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:587 +msgid "MAINTENANCE version when they make backwards-compatible bug fixes." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:589 +msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:594 +msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:598 +msgid "Date based versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:600 +msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:604 +msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:607 +msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:611 +msgid "Serial versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:613 +msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:616 +msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:621 +msgid "Hybrid schemes" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:623 +msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:629 +msgid "Pre-release versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:631 +msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:634 +msgid "zero or more dev releases (denoted with a \".devN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:635 +msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:636 +msgid "zero or more beta releases (denoted with a \".bN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:637 +msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:639 +msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:644 +msgid "Local version identifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:646 +msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:653 +msgid "A local version identifier takes the form ``+``. For example::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:661 +msgid "Working in \"development mode\"" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:663 +msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:667 +msgid "Assuming you're in the root of your project directory, then run:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:674 +msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:680 +msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:688 +msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:692 +msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:697 +msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:701 +msgid "Lastly, if you don't want to install any dependencies at all, you can run::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:706 +msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:713 +msgid "Packaging your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:715 +msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:720 +msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:737 +msgid "Source distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:739 +msgid "Minimally, you should create a :term:`Source Distribution `:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:755 +msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:763 +msgid "Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:765 +msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:770 +msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:773 +msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:776 +msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:785 +msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:792 +msgid "Pure Python Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:794 +msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:797 +#: ../source/guides/distributing-packages-using-setuptools.rst:826 +msgid "To build the wheel:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:811 +msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:815 +msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:821 +msgid "Platform Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:823 +msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:841 +msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:847 +msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:855 +msgid "Uploading your Project to PyPI" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:857 +msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:861 +msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:866 +msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:871 +msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:877 +msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:888 +msgid "Create an account" +msgstr "Crear cuenta" + +#: ../source/guides/distributing-packages-using-setuptools.rst:890 +msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:894 +msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:897 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:901 +msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:904 +msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:913 +msgid "**Be aware that this stores your token in plaintext.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:915 +#: ../source/guides/migrating-to-pypi-org.rst:70 +#: ../source/guides/migrating-to-pypi-org.rst:109 +#: ../source/guides/using-testpypi.rst:83 +msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:921 +msgid "Upload your distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:923 +msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:926 +msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:930 +msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:937 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:944 +#: ../source/tutorials/installing-packages.rst:663 +msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:950 +msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:5 +msgid "Dropping support for older Python versions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:7 +msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:9 +msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:12 +msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:14 +msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:17 +msgid "Requirements" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:19 +msgid "This workflow requires that:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:21 +msgid "The publisher is using the latest version of :ref:`setuptools`," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:22 +msgid "The latest version of :ref:`twine` is used to upload the package," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:23 +msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:26 +msgid "Dealing with the universal wheels" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:28 +msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:36 +msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:48 +msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:53 +msgid "Defining the Python version required" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:56 +msgid "1. Download the newest version of Setuptools" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:58 +msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:60 +msgid "Steps:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:74 +msgid "`setuptools` version should be above 24.0.0." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:77 +msgid "2. Specify the version ranges for supported Python distributions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:79 +msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:81 +#: ../source/specifications/core-metadata.rst:139 +#: ../source/specifications/core-metadata.rst:463 +#: ../source/specifications/core-metadata.rst:487 +#: ../source/specifications/core-metadata.rst:527 +#: ../source/specifications/core-metadata.rst:550 +#: ../source/specifications/core-metadata.rst:583 +#: ../source/specifications/core-metadata.rst:693 +#: ../source/specifications/core-metadata.rst:722 +msgid "Examples::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:86 +msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:101 +msgid "3. Validating the Metadata before publishing" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:103 +msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:105 +msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:108 +msgid "You can see the contents of the generated file like this::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:112 +msgid "Validate that the following is in place, before publishing the package:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:114 +msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:115 +msgid "The Requires-Python field is set and matches your specification in setup.py." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:118 +msgid "4. Using Twine to publish" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:120 +msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:122 +msgid "Make sure you are using the newest version of Twine, at least 1.9." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:125 +msgid "Dropping a Python release" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:127 +msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:129 +msgid "It must be done in this order for the automated fallback to work." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:131 +msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:133 +msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:5 +msgid "Hosting your own simple repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:8 +msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:13 +msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:29 +msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:35 +msgid "\"Manual\" repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:37 +msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:51 +msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:58 +msgid "For complete documentation of the simple repository protocol, see :pep:`503`." +msgstr "" + +#: ../source/guides/index.rst:8 +#: ../source/guides/index.rst:8 +msgid "Installing Packages:" +msgstr "" + +#: ../source/guides/index.rst:20 +#: ../source/guides/index.rst:20 +msgid "Building and Publishing Projects:" +msgstr "" + +#: ../source/guides/index.rst:38 +#: ../source/guides/index.rst:38 +msgid "Miscellaneous:" +msgstr "" + +#: ../source/guides/index.rst:4 +msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:5 +msgid "Package index mirrors and caches" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:8 +#: ../source/guides/supporting-multiple-python-versions.rst:8 +msgid "2014-12-24" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:14 +msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:17 +msgid "Three options are available in this area:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:19 +msgid "pip provides local caching options," +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:20 +msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:22 +msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:27 +msgid "Caching with pip" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:29 +msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:32 +msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:36 +msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:45 +msgid "Caching with devpi" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:47 +msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:55 +msgid "Complete mirror with bandersnatch" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:57 +msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:63 +msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:5 +msgid "Installing scientific packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:11 +msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:16 +msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:22 +msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:29 +msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:35 +msgid "Building from source" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:37 +msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:45 +msgid "Linux distribution packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:47 +msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:51 +msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:57 +msgid "Windows installers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:59 +msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:64 +msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:67 +msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:73 +msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:79 +msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:86 +msgid "macOS installers and package managers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:88 +msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:92 +msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:99 +msgid "SciPy distributions" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:101 +msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:105 +msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:109 +#: ../source/key_projects.rst:596 +msgid "Spack" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:110 +msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:119 +msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:128 +msgid "The conda cross-platform package manager" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:130 +msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:136 +msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 +msgid "Installing stand alone command line tools" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 +msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 +msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 +msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 +msgid "pipx only works with Python 3.6+." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 +msgid "``pipx`` is installed with ``pip``:" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 +msgid "You may need to restart your terminal for the path updates to take effect." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 +msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 +#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 +msgid "For example" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 +msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 +msgid "To upgrade or uninstall the package" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 +msgid "``pipx`` can be upgraded or uninstalled with pip" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 +msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 +msgid "To see the full list of commands ``pipx`` offers, run" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 +msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:5 +msgid "Installing pip/setuptools/wheel with Linux Package Managers" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:8 +msgid "2015-09-17" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:11 +msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:14 +msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:18 +msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:25 +msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:32 +msgid "Fedora" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:34 +msgid "Fedora 21:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:36 +#: ../source/guides/installing-using-linux-tools.rst:45 +#: ../source/guides/installing-using-linux-tools.rst:124 +#: ../source/guides/installing-using-linux-tools.rst:138 +#: ../source/guides/installing-using-linux-tools.rst:158 +msgid "Python 2::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:41 +msgid "Python 3: ``sudo yum install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:43 +msgid "Fedora 22:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:50 +msgid "Python 3: ``sudo dnf install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:53 +msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:63 +msgid "CentOS/RHEL" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:65 +msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:68 +msgid "To install pip and wheel for the system Python, there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:70 +msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:77 +msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:81 +msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:85 +msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:92 +msgid "To additionally upgrade setuptools, run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:97 +msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:101 +msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:104 +msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:106 +msgid "For CentOS, see here: https://www.softwarecollections.org/en/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:108 +msgid "Be aware that collections may not contain the most recent versions." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:110 +msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:116 +msgid "For example, for Python 3.4 on CentOS7/RHEL7::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:122 +msgid "openSUSE" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:129 +#: ../source/guides/installing-using-linux-tools.rst:143 +#: ../source/guides/installing-using-linux-tools.rst:162 +msgid "Python 3::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:135 +msgid "Debian/Ubuntu" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:150 +msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:156 +msgid "Arch Linux" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:168 +msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 +msgid "Installing packages using pip and virtual environments" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 +msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 +msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 +msgid "Installing pip" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 +msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 +msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 +msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 +msgid "Afterwards, you should have the newest pip installed in your user site:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 +msgid "The Python installers for Windows include pip. You should be able to access pip using:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 +msgid "You can make sure that pip is up-to-date by running:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 +msgid "Installing virtualenv" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 +msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 +msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 +msgid "Creating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 +msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 +msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 +msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 +msgid "venv will create a virtual Python installation in the ``env`` folder." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 +msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 +msgid "Activating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 +msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 +msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 +msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 +msgid "Leaving the virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 +msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 +msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 +msgid "Installing packages" +msgstr "Instalación de paquetes" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 +msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 +msgid "pip should download requests and all of its dependencies and install them:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 +msgid "Installing specific versions" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 +msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 +msgid "To install the latest ``2.x`` release of requests:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 +msgid "To install pre-release versions of packages, use the ``--pre`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 +msgid "Installing extras" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 +msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 +msgid "Installing from source" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 +msgid "pip can install a package directly from source, for example:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 +msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 +msgid "Installing from version control systems" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 +msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 +msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 +#: ../source/tutorials/installing-packages.rst:569 +msgid "Installing from local archives" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 +msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 +msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 +msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 +msgid "Using other package indexes" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 +msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 +msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 +#: ../source/tutorials/installing-packages.rst:389 +msgid "Upgrading packages" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 +msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 +msgid "Using requirements files" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 +msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 +msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 +msgid "Freezing dependencies" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 +msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 +msgid "Which will output a list of package specifiers such as:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 +msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:2 +msgid "Making a PyPI-friendly README" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:4 +msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:9 +msgid "Creating a README file" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:11 +msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:13 +msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:16 +msgid "plain text" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:17 +msgid "`reStructuredText `_ (without Sphinx extensions)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:18 +msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:21 +msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:25 +msgid "Including your README in your package's metadata" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:27 +msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:33 +msgid ":ref:`description-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:34 +msgid ":ref:`description-content-type-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:36 +msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:39 +msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:45 +msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:60 +msgid "The minimum required versions of the respective tools are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:62 +msgid "``setuptools >= 38.6.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:63 +msgid "``wheel >= 0.31.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:64 +msgid "``twine >= 1.11.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:66 +msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:72 +msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:95 +msgid "Validating reStructuredText markup" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:97 +msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:100 +msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:105 +msgid "You can check your README for markup errors before uploading as follows:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:107 +msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:122 +msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:125 +msgid "Run ``twine check`` on the sdist and wheel::" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:129 +msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:4 +msgid "Migrating to PyPI.org" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:6 +msgid ":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``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:12 +msgid "Publishing releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:14 +msgid "``pypi.org`` is the default upload platform as of September 2016." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:16 +msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:22 +msgid "The default upload settings switched to ``pypi.org`` in the following versions:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:24 +msgid "``twine`` 1.8.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:25 +msgid "``setuptools`` 27.0.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:26 +msgid "Python 2.7.13 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:27 +msgid "Python 3.4.6 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:28 +msgid "Python 3.5.3 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:29 +msgid "Python 3.6.0 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:31 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:48 +msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:51 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:67 +msgid "(``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.)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:73 +msgid "Registering package names & metadata" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:75 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:79 +msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:84 +msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:89 +#: ../source/guides/using-testpypi.rst:5 +msgid "Using TestPyPI" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:91 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:113 +msgid "Registering new user accounts" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:115 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:121 +msgid "Browsing packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:123 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:130 +msgid "Downloading packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:132 +msgid "``pypi.org`` is the default host for downloading packages." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:135 +msgid "Managing published packages and releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:137 +msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:5 +msgid "Multi-version installs" +msgstr "" + +#: ../source/guides/multi-version-installs.rst:8 +msgid "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``)." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:13 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:31 +msgid "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 ``python -c ''`` to invoke the application's main entry point directly." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:38 +msgid "Refer to the `pkg_resources documentation `__ for more details." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:5 +msgid "Packaging binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:8 +msgid "2013-12-08" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:10 +msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:20 +msgid "An overview of binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:23 +msgid "Use cases" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:25 +msgid "The typical use cases for binary extensions break down into just three conventional categories:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:28 +msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:39 +msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:47 +msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:56 +msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:61 +msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:71 +msgid "Disadvantages" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:73 +msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:80 +msgid "This means that binary extensions:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:82 +msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:85 +msgid "may not be compatible with different builds of the CPython reference interpreter" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:88 +msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:91 +msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:96 +msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:101 +msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:108 +msgid "Alternatives to handcoded accelerator modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:110 +msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:115 +msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:122 +msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:132 +msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:141 +msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:150 +msgid "Alternatives to handcoded wrapper modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:152 +msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:158 +msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:162 +msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:168 +msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:175 +msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:181 +msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:185 +msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:189 +msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:203 +msgid "Alternatives for low level system access" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:205 +msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:213 +msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:222 +msgid "Implementing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:224 +msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:241 +msgid "Building binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:244 +msgid "Building extensions for multiple platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:246 +msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:256 +msgid "Binary extensions for Windows" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:258 +msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:263 +msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:269 +msgid "To set up a build environment for binary extensions, the steps are as follows:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:271 +msgid "For Python 2.7" +msgstr "Para Python 2.7" + +#: ../source/guides/packaging-binary-extensions.rst:273 +msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:276 +msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:278 +#: ../source/guides/packaging-binary-extensions.rst:288 +#: ../source/guides/packaging-binary-extensions.rst:295 +msgid "Done." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:280 +msgid "For Python 3.4" +msgstr "Para Python 3.4" + +#: ../source/guides/packaging-binary-extensions.rst:282 +msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:285 +msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:287 +msgid "Set DISTUTILS_USE_SDK=1" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:290 +msgid "For Python 3.5" +msgstr "Para Python 3.5" + +#: ../source/guides/packaging-binary-extensions.rst:292 +msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:297 +msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:301 +msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:305 +msgid "Binary extensions for Linux" +msgstr "Extensiones binarias para Linux" + +#: ../source/guides/packaging-binary-extensions.rst:307 +msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:313 +msgid "Binary extensions for macOS" +msgstr "Extensiones binarias para macOS" + +#: ../source/guides/packaging-binary-extensions.rst:315 +msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:325 +msgid "Publishing binary extensions" +msgstr "Publicación de extensiones binarias" + +#: ../source/guides/packaging-binary-extensions.rst:327 +msgid "For interim guidance on this topic, see the discussion in `this issue `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:343 +msgid "Additional resources" +msgstr "Recursos adicionales" + +#: ../source/guides/packaging-binary-extensions.rst:345 +msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:352 +msgid "Cross-platform wheel generation with scikit-build" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:354 +msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:362 +msgid "Introduction to C/C++ extension modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:364 +msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:367 +msgid "`What are (c)python extension modules? `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:368 +msgid "`Releasing the gil `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:369 +msgid "`Writing cpython extension modules using C++ `_" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:3 +msgid "Packaging namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:5 +msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:24 +msgid "And you use this package in your code like so::" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:29 +msgid "Then you can break these sub-packages into two separate distributions:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:46 +msgid "Each sub-package can now be separately installed, used, and versioned." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:48 +msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:58 +msgid "Creating a namespace package" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:60 +msgid "There are currently three different approaches to creating namespace packages:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:62 +msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:66 +msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:69 +msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:73 +msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:80 +msgid "Native namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:82 +msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:97 +msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:102 +msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:117 +msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:123 +msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:129 +msgid "pkgutil-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:131 +msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:136 +msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:148 +#: ../source/guides/packaging-namespace-packages.rst:194 +msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:155 +#: ../source/guides/packaging-namespace-packages.rst:201 +msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:160 +msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:171 +msgid "pkg_resources-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:173 +msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:182 +msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:206 +msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:216 +msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:223 +msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:237 +msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 +msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 +msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 +msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 +msgid "Saving credentials on GitHub" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 +msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 +msgid "Let's begin! 🚀" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 +msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 +msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 +msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 +msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 +msgid "Creating a workflow definition" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 +msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 +msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 +msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 +msgid "Defining a workflow job environment" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 +msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 +msgid "Checking out the project and building distributions" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 +msgid "Then, add the following under the ``build-n-publish`` section:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 +msgid "This will download your repository into the CI runner and then install and activate Python 3.7." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 +msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 +msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 +msgid "So add this to the steps list:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 +msgid "Publishing the distribution to PyPI and TestPyPI" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 +msgid "Finally, add the following steps at the end:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 +msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 +msgid "That's all, folks!" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 +msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:5 +msgid "Single-sourcing the package version" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:8 +msgid "There are many techniques to maintain a single source of truth for the version number of your project:" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:11 +msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:38 +msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:47 +msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:52 +msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:55 +msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:58 +msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:65 +msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:76 +msgid "Example using this technique: `warehouse `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:78 +msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:86 +msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:91 +msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:95 +msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:110 +msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:114 +msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:128 +msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:134 +msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:138 +msgid "Example using this technique: `setuptools `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:141 +msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:155 +msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:161 +msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:5 +msgid "Supporting multiple Python versions" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:37 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:43 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:49 +msgid "Automated testing and continuous integration" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:51 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:60 +msgid "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:" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:66 +msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:69 +msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:80 +msgid "Both `Travis CI`_ 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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:85 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:89 +msgid "Tools for single-source Python packages" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:91 +msgid "`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_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:100 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:107 +msgid "a Python 2 (by syntax) module in a Python 3 project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:108 +msgid "a Python 3 (by syntax) module in a *Python 2* project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:110 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:117 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:124 +msgid "What's in which Python?" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:126 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:3 +msgid "Supporting Windows using Appveyor" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:6 +msgid "2015-12-03" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:8 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:20 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:24 +msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:30 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:38 +msgid "Setting up" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:40 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:45 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:49 +msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:54 +msgid "Adding Appveyor support to your project" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:61 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:69 +msgid "appveyor.yml" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:75 +msgid "This file can be downloaded from `here `__." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:77 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:80 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:88 +msgid "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``)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:94 +msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:97 +msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:100 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:109 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:114 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:119 +msgid "Support script" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:121 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:126 +msgid "`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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:133 +msgid "You can simply download the batch file and include it in your project unchanged." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:137 +msgid "Access to the built wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:139 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:147 +msgid "Additional notes" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:150 +msgid "Testing with tox" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:152 +msgid "Many projects use the `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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:156 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:160 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:165 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:170 +msgid "``DISTUTILS_USE_SDK``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:171 +msgid "``MSSdk``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:172 +msgid "``INCLUDE``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:173 +msgid "``LIB``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:175 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:181 +msgid "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 Travis or 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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:188 +msgid "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``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:192 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:197 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:203 +msgid "Automatically uploading wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:205 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:210 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:216 +msgid "External dependencies" +msgstr "Dependencias externas" + +#: ../source/guides/supporting-windows-using-appveyor.rst:218 +msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:221 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:230 +msgid "Support scripts" +msgstr "Secuencias de apoyo" + +#: ../source/guides/supporting-windows-using-appveyor.rst:232 +msgid "For reference, the SDK setup support script is listed here:" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:234 +msgid "``appveyor-sample/build.cmd``" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:5 +msgid "Tool recommendations" +msgstr "Recomendaciones de herramientas" + +#: ../source/guides/tool-recommendations.rst:7 +msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:12 +msgid "Application dependency management" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:14 +msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:18 +msgid "When ``pipenv`` does not meet your use case, consider other tools like:" +msgstr "" +"Si ``pipenv`` no se ajusta a sus necesidades, considere utilizar otras " +"herramientas, como:" + +#: ../source/guides/tool-recommendations.rst:20 +msgid ":ref:`pip`" +msgstr ":ref:`pip`" + +#: ../source/guides/tool-recommendations.rst:22 +msgid "`pip-tools `_" +msgstr "`pip-tools `_" + +#: ../source/guides/tool-recommendations.rst:24 +msgid "`Poetry `_" +msgstr "`Poetry `_" + +#: ../source/guides/tool-recommendations.rst:27 +msgid "Installation tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:29 +msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:34 +msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:37 +msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:40 +msgid ":ref:`buildout`: primarily focused on the web development community" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:42 +msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:47 +msgid "Packaging tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:49 +msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:52 +msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:56 +msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:61 +msgid "Publishing platform migration" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:63 +msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:67 +msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:72 +msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:77 +msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:82 +msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:88 +msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:93 +msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:102 +msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:107 +msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:5 +msgid "Including files in source distributions with ``MANIFEST.in``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:7 +msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:17 +msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:22 +msgid "How files are included in an sdist" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:24 +msgid "The following files are included in a source distribution by default:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:26 +msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:28 +msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:30 +msgid "scripts specified by the ``scripts`` ``setup()`` argument" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:31 +msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:33 +msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:35 +msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:37 +msgid "all files matching the pattern :file:`test/test*.py`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:38 +msgid ":file:`setup.py` (or whatever you called your setup script)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:39 +msgid ":file:`setup.cfg`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:40 +msgid ":file:`README`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:41 +msgid ":file:`README.txt`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:42 +msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:43 +msgid ":file:`README.md` (setuptools 36.4.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:44 +msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:45 +msgid ":file:`MANIFEST.in`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:47 +msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:52 +msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:60 +msgid ":file:`MANIFEST.in` commands" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:62 +msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:67 +msgid "Command" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid ":samp:`include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid "Add all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid ":samp:`exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid "Remove all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid ":samp:`global-include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid "Add all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid ":samp:`global-exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid "Remove all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid ":samp:`graft {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid "Add all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid ":samp:`prune {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid "Remove all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:79 +msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:87 +msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:91 +msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:95 +msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:101 +msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." +msgstr "" + +#: ../source/guides/using-testpypi.rst:7 +msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" +msgstr "" + +#: ../source/guides/using-testpypi.rst:13 +msgid "Registering your account" +msgstr "" + +#: ../source/guides/using-testpypi.rst:15 +msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." +msgstr "" + +#: ../source/guides/using-testpypi.rst:19 +msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." +msgstr "" + +#: ../source/guides/using-testpypi.rst:24 +msgid "Using TestPyPI with Twine" +msgstr "" + +#: ../source/guides/using-testpypi.rst:26 +msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:33 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/using-testpypi.rst:39 +msgid "Using TestPyPI with pip" +msgstr "" + +#: ../source/guides/using-testpypi.rst:41 +msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:56 +msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" +msgstr "" + +#: ../source/guides/using-testpypi.rst:73 +msgid "Setting up TestPyPI in :file:`.pypirc`" +msgstr "" + +#: ../source/guides/using-testpypi.rst:75 +msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" +msgstr "" + +#: ../source/index.rst:3 +#: ../source/key_projects.rst:181 +msgid "Python Packaging User Guide" +msgstr "Manual de uso del empaquetamiento de Python" + +#: ../source/index.rst:5 +msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." +msgstr "" + +#: ../source/index.rst:5 +msgid "python, packaging, guide, tutorial" +msgstr "" + +#: ../source/index.rst:24 +msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." +msgstr "" + +#: ../source/index.rst:28 +msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" +msgstr "" + +#: ../source/index.rst:36 +msgid "Get started" +msgstr "" + +#: ../source/index.rst:38 +msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" +msgstr "" + +#: ../source/index.rst:41 +msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" +msgstr "" + +#: ../source/index.rst:43 +msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" +msgstr "" + +#: ../source/index.rst:45 +msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" +msgstr "" + +#: ../source/index.rst:47 +msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" +msgstr "" + +#: ../source/index.rst:52 +msgid "Learn more" +msgstr "" + +#: ../source/index.rst:54 +msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" +msgstr "" + +#: ../source/index.rst:56 +msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/index.rst:58 +msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." +msgstr "" + +#: ../source/index.rst:60 +msgid "The :doc:`specifications/index` section for packaging interoperability specifications." +msgstr "" + +#: ../source/index.rst:62 +msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." +msgstr "" + +#: ../source/key_projects.rst:6 +msgid "Project Summaries" +msgstr "" + +#: ../source/key_projects.rst:8 +msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." +msgstr "" + +#: ../source/key_projects.rst:14 +msgid "PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:19 +msgid "bandersnatch" +msgstr "" + +#: ../source/key_projects.rst:21 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:25 +msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." +msgstr "" + +#: ../source/key_projects.rst:35 +msgid "build" +msgstr "" + +#: ../source/key_projects.rst:37 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:42 +msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." +msgstr "" + +#: ../source/key_projects.rst:49 +msgid "cibuildwheel" +msgstr "" + +#: ../source/key_projects.rst:51 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" +msgstr "" + +#: ../source/key_projects.rst:58 +msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." +msgstr "" + +#: ../source/key_projects.rst:64 +msgid "distlib" +msgstr "" + +#: ../source/key_projects.rst:66 +msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:71 +msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." +msgstr "" + +#: ../source/key_projects.rst:80 +msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." +msgstr "" + +#: ../source/key_projects.rst:90 +msgid "packaging" +msgstr "" + +#: ../source/key_projects.rst:92 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:97 +msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." +msgstr "" + +#: ../source/key_projects.rst:99 +msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." +msgstr "" + +#: ../source/key_projects.rst:107 +msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." +msgstr "" + +#: ../source/key_projects.rst:119 +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "pip" +msgstr "" + +#: ../source/key_projects.rst:121 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:126 +msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." +msgstr "" + +#: ../source/key_projects.rst:129 +msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." +msgstr "" + +#: ../source/key_projects.rst:137 +msgid "Pipenv" +msgstr "" + +#: ../source/key_projects.rst:139 +msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:144 +msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." +msgstr "" + +#: ../source/key_projects.rst:148 +msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." +msgstr "" + +#: ../source/key_projects.rst:159 +msgid "Pipfile" +msgstr "" + +#: ../source/key_projects.rst:161 +msgid "`Source `__" +msgstr "" + +#: ../source/key_projects.rst:163 +msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." +msgstr "" + +#: ../source/key_projects.rst:170 +msgid "pipx" +msgstr "" + +#: ../source/key_projects.rst:172 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:176 +msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." +msgstr "" + +#: ../source/key_projects.rst:183 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:187 +msgid "This guide!" +msgstr "" + +#: ../source/key_projects.rst:192 +msgid "readme_renderer" +msgstr "" + +#: ../source/key_projects.rst:194 +msgid "`GitHub and docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:197 +msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." +msgstr "" + +#: ../source/key_projects.rst:208 +msgid "setuptools" +msgstr "" + +#: ../source/key_projects.rst:210 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:215 +msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." +msgstr "" + +#: ../source/key_projects.rst:220 +msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." +msgstr "" + +#: ../source/key_projects.rst:227 +msgid "trove-classifiers" +msgstr "" + +#: ../source/key_projects.rst:229 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:233 +msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." +msgstr "" + +#: ../source/key_projects.rst:239 +msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." +msgstr "" + +#: ../source/key_projects.rst:253 +msgid "twine" +msgstr "" + +#: ../source/key_projects.rst:255 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:260 +msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." +msgstr "" + +#: ../source/key_projects.rst:270 +#: ../source/overview.rst:415 +msgid "virtualenv" +msgstr "" + +#: ../source/key_projects.rst:272 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:277 +msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/key_projects.rst:290 +msgid "Warehouse" +msgstr "" + +#: ../source/key_projects.rst:292 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:296 +msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." +msgstr "" + +#: ../source/key_projects.rst:304 +msgid "wheel" +msgstr "" + +#: ../source/key_projects.rst:306 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:311 +msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." +msgstr "" + +#: ../source/key_projects.rst:315 +msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." +msgstr "" + +#: ../source/key_projects.rst:324 +msgid "Non-PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:329 +msgid "bento" +msgstr "" + +#: ../source/key_projects.rst:331 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:336 +msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." +msgstr "" + +#: ../source/key_projects.rst:344 +msgid "buildout" +msgstr "" + +#: ../source/key_projects.rst:346 +msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:351 +msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." +msgstr "" + +#: ../source/key_projects.rst:358 +msgid "conda" +msgstr "" + +#: ../source/key_projects.rst:360 +msgid "`Docs `__" +msgstr "" + +#: ../source/key_projects.rst:362 +msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." +msgstr "" + +#: ../source/key_projects.rst:369 +msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." +msgstr "" + +#: ../source/key_projects.rst:373 +msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." +msgstr "" + +#: ../source/key_projects.rst:386 +msgid "devpi" +msgstr "" + +#: ../source/key_projects.rst:388 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:392 +msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." +msgstr "" + +#: ../source/key_projects.rst:401 +msgid "flit" +msgstr "" + +#: ../source/key_projects.rst:403 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:407 +msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." +msgstr "" + +#: ../source/key_projects.rst:412 +msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." +msgstr "" + +#: ../source/key_projects.rst:422 +msgid "enscons" +msgstr "" + +#: ../source/key_projects.rst:424 +msgid "`Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:428 +msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." +msgstr "" + +#: ../source/key_projects.rst:443 +msgid "Hashdist" +msgstr "" + +#: ../source/key_projects.rst:445 +msgid "`Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:448 +msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." +msgstr "" + +#: ../source/key_projects.rst:460 +msgid "hatch" +msgstr "" + +#: ../source/key_projects.rst:462 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:465 +msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." +msgstr "" + +#: ../source/key_projects.rst:475 +msgid "multibuild" +msgstr "" + +#: ../source/key_projects.rst:477 +msgid "`GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:479 +msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." +msgstr "" + +#: ../source/key_projects.rst:485 +msgid "pex" +msgstr "" + +#: ../source/key_projects.rst:487 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:491 +msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." +msgstr "" + +#: ../source/key_projects.rst:500 +msgid "pip-tools" +msgstr "" + +#: ../source/key_projects.rst:502 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:505 +msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." +msgstr "" + +#: ../source/key_projects.rst:517 +msgid "piwheels" +msgstr "" + +#: ../source/key_projects.rst:519 +msgid "`Website `__ | `Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:523 +msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." +msgstr "" + +#: ../source/key_projects.rst:532 +msgid "poetry" +msgstr "" + +#: ../source/key_projects.rst:534 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:538 +msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." +msgstr "" + +#: ../source/key_projects.rst:548 +msgid "pypiserver" +msgstr "" + +#: ../source/key_projects.rst:550 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:554 +msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." +msgstr "" + +#: ../source/key_projects.rst:564 +msgid "scikit-build" +msgstr "" + +#: ../source/key_projects.rst:566 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:570 +msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." +msgstr "" + +#: ../source/key_projects.rst:582 +msgid "shiv" +msgstr "" + +#: ../source/key_projects.rst:584 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:588 +msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." +msgstr "" + +#: ../source/key_projects.rst:598 +msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" +msgstr "" + +#: ../source/key_projects.rst:603 +msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." +msgstr "" + +#: ../source/key_projects.rst:611 +msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." +msgstr "" + +#: ../source/key_projects.rst:617 +msgid "zest.releaser" +msgstr "" + +#: ../source/key_projects.rst:619 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:623 +msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." +msgstr "" + +#: ../source/key_projects.rst:630 +msgid "Standard Library Projects" +msgstr "" + +#: ../source/key_projects.rst:635 +msgid "ensurepip" +msgstr "" + +#: ../source/key_projects.rst:637 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:640 +msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." +msgstr "" + +#: ../source/key_projects.rst:649 +msgid "distutils" +msgstr "" + +#: ../source/key_projects.rst:651 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:654 +msgid "The original Python packaging system, added to the standard library in Python 2.0." +msgstr "" + +#: ../source/key_projects.rst:657 +msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." +msgstr "" + +#: ../source/key_projects.rst:670 +msgid "venv" +msgstr "" + +#: ../source/key_projects.rst:672 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:675 +msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/news.rst:2 +msgid "News" +msgstr "" + +#: ../source/news.rst:5 +msgid "September 2019" +msgstr "" + +#: ../source/news.rst:6 +msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" +msgstr "" + +#: ../source/news.rst:9 +msgid "August 2019" +msgstr "" + +#: ../source/news.rst:10 +msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" +msgstr "" + +#: ../source/news.rst:13 +msgid "July 2019" +msgstr "" + +#: ../source/news.rst:14 +msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" +msgstr "" + +#: ../source/news.rst:15 +msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" +msgstr "" + +#: ../source/news.rst:16 +msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" +msgstr "" + +#: ../source/news.rst:17 +msgid "Updated directory layout examples for consistency. (:pr:`611`)" +msgstr "" + +#: ../source/news.rst:18 +msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" +msgstr "" + +#: ../source/news.rst:21 +msgid "June 2019" +msgstr "" + +#: ../source/news.rst:22 +msgid "Fixed some typos. (:pr:`620`)" +msgstr "" + +#: ../source/news.rst:25 +msgid "May 2019" +msgstr "" + +#: ../source/news.rst:26 +msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" +msgstr "" + +#: ../source/news.rst:27 +msgid "Added a MANIFEST.in guide page. (:pr:`609`)" +msgstr "" + +#: ../source/news.rst:30 +msgid "April 2019" +msgstr "" + +#: ../source/news.rst:31 +msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" +msgstr "" + +#: ../source/news.rst:32 +msgid "Reduced emphasis on virtualenv. (:pr:`606`)" +msgstr "" + +#: ../source/news.rst:35 +msgid "March 2019" +msgstr "" + +#: ../source/news.rst:36 +msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" +msgstr "" + +#: ../source/news.rst:37 +msgid "Covered RTD details for contributing. (:pr:`600`)" +msgstr "" + +#: ../source/news.rst:40 +msgid "February 2019" +msgstr "" + +#: ../source/news.rst:41 +msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" +msgstr "" + +#: ../source/news.rst:42 +msgid "Added instructions to install Python CLI applications. (:pr:`594`)" +msgstr "" + +#: ../source/news.rst:45 +msgid "January 2019" +msgstr "" + +#: ../source/news.rst:46 +msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" +msgstr "" + +#: ../source/news.rst:47 +msgid "Updated Sphinx and Nox. (:pr:`591`)" +msgstr "" + +#: ../source/news.rst:48 +msgid "Referenced Twine from Python3. (:pr:`581`)" +msgstr "" + +#: ../source/news.rst:51 +msgid "December 2018" +msgstr "" + +#: ../source/news.rst:52 +msgid "No programmers in the office!" +msgstr "" + +#: ../source/news.rst:55 +msgid "November 2018" +msgstr "" + +#: ../source/news.rst:56 +msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" +msgstr "" + +#: ../source/news.rst:57 +msgid "Changed bumpversion to bump2version. (:pr:`572`)" +msgstr "" + +#: ../source/news.rst:58 +msgid "Added single-sourcing package version example. (:pr:`573`)" +msgstr "" + +#: ../source/news.rst:59 +msgid "Added a guide for creating documentation. (:pr:`568`)" +msgstr "" + +#: ../source/news.rst:62 +msgid "October 2018" +msgstr "" + +#: ../source/news.rst:63 +msgid "Updated Nox package name. (:pr:`566`)" +msgstr "" + +#: ../source/news.rst:64 +msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" +msgstr "" + +#: ../source/news.rst:67 +msgid "September 2018" +msgstr "" + +#: ../source/news.rst:68 +msgid "Added a section on checking RST markup. (:pr:`554`)" +msgstr "" + +#: ../source/news.rst:69 +msgid "Updated user installs page. (:pr:`558`)" +msgstr "" + +#: ../source/news.rst:70 +msgid "Updated Google BigQuery urls. (:pr:`556`)" +msgstr "" + +#: ../source/news.rst:71 +msgid "Replaced tar command with working command. (:pr:`552`)" +msgstr "" + +#: ../source/news.rst:72 +msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" +msgstr "" + +#: ../source/news.rst:75 +msgid "August 2018" +msgstr "" + +#: ../source/news.rst:76 +msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" +msgstr "" + +#: ../source/news.rst:77 +msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" +msgstr "" + +#: ../source/news.rst:78 +msgid "Updated Python version supported by virtualenv. (:pr:`538`)" +msgstr "" + +#: ../source/news.rst:79 +msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" +msgstr "" + +#: ../source/news.rst:82 +msgid "July 2018" +msgstr "" + +#: ../source/news.rst:84 +msgid "Improved binary extension docs. (:pr:`531`)" +msgstr "" + +#: ../source/news.rst:85 +msgid "Added scikit-build to key projects. (:pr:`530`)" +msgstr "" + +#: ../source/news.rst:88 +msgid "June 2018" +msgstr "" + +#: ../source/news.rst:90 +msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" +msgstr "" + +#: ../source/news.rst:91 +msgid "Updated Markdown descriptions explanation. (:pr:`522`)" +msgstr "" + +#: ../source/news.rst:94 +msgid "May 2018" +msgstr "" + +#: ../source/news.rst:96 +msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" +msgstr "" + +#: ../source/news.rst:97 +msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" +msgstr "" + +#: ../source/news.rst:98 +msgid "Simplified packaging tutorial. (:pr:`498`)" +msgstr "" + +#: ../source/news.rst:99 +msgid "Updated Windows users instructions for clarity. (:pr:`493`)" +msgstr "" + +#: ../source/news.rst:100 +msgid "Updated the license section description for completeness. (:pr:`492`)" +msgstr "" + +#: ../source/news.rst:101 +msgid "Added specification-style document to contributing section. (:pr:`489`)" +msgstr "" + +#: ../source/news.rst:102 +msgid "Added documentation types to contributing guide. (:pr:`485`)" +msgstr "" + +#: ../source/news.rst:105 +msgid "April 2018" +msgstr "" + +#: ../source/news.rst:107 +msgid "Added README guide. (:pr:`461`)" +msgstr "" + +#: ../source/news.rst:108 +msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" +msgstr "" + +#: ../source/news.rst:109 +msgid "Added instructions for Warehouse. (:pr:`471`)" +msgstr "" + +#: ../source/news.rst:110 +msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" +msgstr "" + +#: ../source/news.rst:111 +msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" +msgstr "" + +#: ../source/news.rst:112 +msgid "Added a guide for phasing out Python versions. (:pr:`459`)" +msgstr "" + +#: ../source/news.rst:113 +msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" +msgstr "" + +#: ../source/news.rst:116 +msgid "March 2018" +msgstr "" + +#: ../source/news.rst:118 +msgid "Updated \"installing scientific packages\". (:pr:`455`)" +msgstr "" + +#: ../source/news.rst:119 +msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" +msgstr "" + +#: ../source/news.rst:120 +msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" +msgstr "" + +#: ../source/news.rst:121 +msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" +msgstr "" + +#: ../source/news.rst:124 +msgid "February 2018" +msgstr "" + +#: ../source/news.rst:126 +msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" +msgstr "" + +#: ../source/news.rst:127 +msgid "Updated PyPI migration info. (:pr:`439`)" +msgstr "" + +#: ../source/news.rst:128 +msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" +msgstr "" + +#: ../source/news.rst:129 +msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" +msgstr "" + +#: ../source/news.rst:130 +msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" +msgstr "" + +#: ../source/news.rst:133 +msgid "January 2018" +msgstr "" + +#: ../source/news.rst:135 +msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" +msgstr "" + +#: ../source/news.rst:136 +msgid "Updated README.rst explanation. (:pr:`419`)" +msgstr "" + +#: ../source/news.rst:139 +msgid "December 2017" +msgstr "" + +#: ../source/news.rst:141 +msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" +msgstr "" + +#: ../source/news.rst:142 +msgid "Noted which fields can be used with environment markers. (:pr:`416`)" +msgstr "" + +#: ../source/news.rst:143 +msgid "Updated Requires-Python section. (:pr:`414`)" +msgstr "" + +#: ../source/news.rst:144 +msgid "Added news page. (:pr:`404`)" +msgstr "" + +#: ../source/news.rst:147 +msgid "November 2017" +msgstr "" + +#: ../source/news.rst:149 +msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" +msgstr "" + +#: ../source/news.rst:150 +msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" +msgstr "" + +#: ../source/news.rst:152 +msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:153 +msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" +msgstr "" + +#: ../source/news.rst:156 +msgid "October 2017" +msgstr "" + +#: ../source/news.rst:158 +msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:159 +msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" +msgstr "" + +#: ../source/news.rst:160 +msgid "Split the specifications page into multiple pages. (:pr:`386`)" +msgstr "" + +#: ../source/news.rst:163 +msgid "September 2017" +msgstr "" + +#: ../source/news.rst:165 +msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" +msgstr "" + +#: ../source/news.rst:167 +msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" +msgstr "" + +#: ../source/news.rst:170 +msgid "August 2017" +msgstr "" + +#: ../source/news.rst:172 +msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" +msgstr "" + +#: ../source/news.rst:173 +msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" +msgstr "" + +#: ../source/news.rst:174 +msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" +msgstr "" + +#: ../source/news.rst:177 +msgid "July 2017" +msgstr "" + +#: ../source/news.rst:179 +msgid "Added ``flit`` to the key projects list. (:pr:`358`)" +msgstr "" + +#: ../source/news.rst:180 +msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" +msgstr "" + +#: ../source/news.rst:181 +msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" +msgstr "" + +#: ../source/news.rst:182 +msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" +msgstr "" + +#: ../source/news.rst:183 +msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" +msgstr "" + +#: ../source/news.rst:186 +msgid "June 2017" +msgstr "" + +#: ../source/news.rst:188 +msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" +msgstr "" + +#: ../source/news.rst:189 +msgid "Added documentation for ``python_requires``. (:pr:`338`)" +msgstr "" + +#: ../source/news.rst:190 +msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" +msgstr "" + +#: ../source/news.rst:191 +msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" +msgstr "" + +#: ../source/news.rst:192 +msgid "Added a license section to the distributing guide. (:pr:`331`)" +msgstr "" + +#: ../source/news.rst:193 +msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" +msgstr "" + +#: ../source/news.rst:194 +msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" +msgstr "" + +#: ../source/news.rst:195 +msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" +msgstr "" + +#: ../source/news.rst:196 +msgid "Switched to the PyPA theme. (:pr:`305`)" +msgstr "" + +#: ../source/news.rst:197 +msgid "Re-organized the documentation into the new structure. (:pr:`318`)" +msgstr "" + +#: ../source/news.rst:200 +msgid "May 2017" +msgstr "" + +#: ../source/news.rst:202 +msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" +msgstr "" + +#: ../source/news.rst:203 +msgid "Added contributor and style guide. (:pr:`307`)" +msgstr "" + +#: ../source/news.rst:204 +msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" +msgstr "" + +#: ../source/news.rst:207 +msgid "April 2017" +msgstr "" + +#: ../source/news.rst:209 +msgid "Added travis configuration for testing pull requests. (:pr:`300`)" +msgstr "" + +#: ../source/news.rst:210 +msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" +msgstr "" + +#: ../source/news.rst:211 +msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" +msgstr "" + +#: ../source/news.rst:212 +msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" +msgstr "" + +#: ../source/news.rst:213 +msgid "Added a topic on namespace packages. (:pr:`290`)" +msgstr "" + +#: ../source/news.rst:214 +msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" +msgstr "" + +#: ../source/news.rst:215 +msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" +msgstr "" + +#: ../source/news.rst:216 +msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" +msgstr "" + +#: ../source/news.rst:217 +msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" +msgstr "" + +#: ../source/news.rst:219 +msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" +msgstr "" + +#: ../source/news.rst:223 +msgid "March 2017" +msgstr "" + +#: ../source/news.rst:225 +msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" +msgstr "" + +#: ../source/news.rst:228 +msgid "February 2017" +msgstr "" + +#: ../source/news.rst:230 +msgid "Added :pep:`518`. (:pr:`281`)" +msgstr "" + +#: ../source/overview.rst:3 +msgid "An Overview of Packaging for Python" +msgstr "" + +#: ../source/overview.rst:7 +msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." +msgstr "" + +#: ../source/overview.rst:12 +msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." +msgstr "" + +#: ../source/overview.rst:18 +msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." +msgstr "" + +#: ../source/overview.rst:26 +msgid "Thinking about deployment" +msgstr "" + +#: ../source/overview.rst:28 +msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" +msgstr "" + +#: ../source/overview.rst:32 +msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" +msgstr "" + +#: ../source/overview.rst:35 +msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" +msgstr "" + +#: ../source/overview.rst:37 +msgid "Is your software installed individually, or in large deployment batches?" +msgstr "" + +#: ../source/overview.rst:39 +msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." +msgstr "" + +#: ../source/overview.rst:46 +msgid "Packaging Python libraries and tools" +msgstr "" + +#: ../source/overview.rst:48 +msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/overview.rst:53 +msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." +msgstr "" + +#: ../source/overview.rst:59 +msgid "Python modules" +msgstr "" + +#: ../source/overview.rst:61 +msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." +msgstr "" + +#: ../source/overview.rst:66 +msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." +msgstr "" + +#: ../source/overview.rst:73 +msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." +msgstr "" + +#: ../source/overview.rst:78 +msgid "Python source distributions" +msgstr "" + +#: ../source/overview.rst:80 +msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." +msgstr "" + +#: ../source/overview.rst:84 +msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." +msgstr "" + +#: ../source/overview.rst:90 +msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." +msgstr "" + +#: ../source/overview.rst:95 +msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." +msgstr "" + +#: ../source/overview.rst:100 +msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." +msgstr "" + +#: ../source/overview.rst:107 +msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" +msgstr "" + +#: ../source/overview.rst:114 +msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." +msgstr "" + +#: ../source/overview.rst:119 +msgid "Python binary distributions" +msgstr "" + +#: ../source/overview.rst:121 +msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." +msgstr "" + +#: ../source/overview.rst:125 +msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." +msgstr "" + +#: ../source/overview.rst:132 +msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." +msgstr "" + +#: ../source/overview.rst:140 +msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." +msgstr "" + +#: ../source/overview.rst:148 +msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." +msgstr "" + +#: ../source/overview.rst:155 +msgid "Packaging Python applications" +msgstr "" + +#: ../source/overview.rst:157 +msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." +msgstr "" + +#: ../source/overview.rst:162 +msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." +msgstr "" + +#: ../source/overview.rst:166 +msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." +msgstr "" + +#: ../source/overview.rst:172 +msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." +msgstr "" + +#: ../source/overview.rst:176 +msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." +msgstr "" + +#: ../source/overview.rst:181 +msgid "Depending on a framework" +msgstr "" + +#: ../source/overview.rst:183 +msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." +msgstr "" + +#: ../source/overview.rst:189 +msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." +msgstr "" + +#: ../source/overview.rst:195 +msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." +msgstr "" + +#: ../source/overview.rst:199 +msgid "Service platforms" +msgstr "" + +#: ../source/overview.rst:201 +msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." +msgstr "" + +#: ../source/overview.rst:205 +msgid "`Heroku `_" +msgstr "" + +#: ../source/overview.rst:206 +msgid "`Google App Engine `_" +msgstr "" + +#: ../source/overview.rst:207 +msgid "`PythonAnywhere `_" +msgstr "" + +#: ../source/overview.rst:208 +msgid "`OpenShift `_" +msgstr "" + +#: ../source/overview.rst:209 +msgid "\"Serverless\" frameworks like `Zappa `_" +msgstr "" + +#: ../source/overview.rst:211 +msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." +msgstr "" + +#: ../source/overview.rst:216 +msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." +msgstr "" + +#: ../source/overview.rst:220 +msgid "Web browsers and mobile applications" +msgstr "" + +#: ../source/overview.rst:222 +msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." +msgstr "" + +#: ../source/overview.rst:227 +msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" +msgstr "" + +#: ../source/overview.rst:231 +msgid "`Kivy `_" +msgstr "" + +#: ../source/overview.rst:232 +msgid "`Beeware `_" +msgstr "" + +#: ../source/overview.rst:233 +msgid "`Brython `_" +msgstr "" + +#: ../source/overview.rst:234 +msgid "`Flexx `_" +msgstr "" + +#: ../source/overview.rst:236 +msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." +msgstr "" + +#: ../source/overview.rst:241 +msgid "Depending on a pre-installed Python" +msgstr "" + +#: ../source/overview.rst:243 +msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." +msgstr "" + +#: ../source/overview.rst:249 +msgid "Technologies which support this model:" +msgstr "" + +#: ../source/overview.rst:251 +msgid "`PEX `_ (Python EXecutable)" +msgstr "" + +#: ../source/overview.rst:252 +msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" +msgstr "" + +#: ../source/overview.rst:253 +msgid "`shiv `_ (requires Python 3)" +msgstr "" + +#: ../source/overview.rst:255 +msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." +msgstr "" + +#: ../source/overview.rst:260 +msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." +msgstr "" + +#: ../source/overview.rst:267 +msgid "Depending on a separate software distribution ecosystem" +msgstr "" + +#: ../source/overview.rst:269 +msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." +msgstr "" + +#: ../source/overview.rst:274 +msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." +msgstr "" + +#: ../source/overview.rst:284 +msgid "Instructions on building and publishing for the Anaconda ecosystem:" +msgstr "" + +#: ../source/overview.rst:286 +msgid "`Building libraries and applications with conda `_" +msgstr "" + +#: ../source/overview.rst:287 +msgid "`Transitioning a native Python package to Anaconda `_" +msgstr "" + +#: ../source/overview.rst:289 +msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" +msgstr "" + +#: ../source/overview.rst:293 +msgid "`Enthought Canopy `_" +msgstr "" + +#: ../source/overview.rst:294 +msgid "`ActiveState ActivePython `_" +msgstr "" + +#: ../source/overview.rst:295 +msgid "`WinPython `_" +msgstr "" + +#: ../source/overview.rst:300 +msgid "Bringing your own Python executable" +msgstr "" + +#: ../source/overview.rst:302 +msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." +msgstr "" + +#: ../source/overview.rst:306 +msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." +msgstr "" + +#: ../source/overview.rst:311 +msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." +msgstr "" + +#: ../source/overview.rst:315 +msgid "A selection of Python freezers:" +msgstr "" + +#: ../source/overview.rst:317 +msgid "`pyInstaller `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:318 +msgid "`cx_Freeze `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:319 +msgid "`constructor `_ - For command-line installers" +msgstr "" + +#: ../source/overview.rst:320 +msgid "`py2exe `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:321 +msgid "`py2app `_ - Mac only" +msgstr "" + +#: ../source/overview.rst:322 +msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" +msgstr "" + +#: ../source/overview.rst:323 +msgid "`osnap `_ - Windows and Mac" +msgstr "" + +#: ../source/overview.rst:324 +msgid "`pynsist `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:326 +msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." +msgstr "" + +#: ../source/overview.rst:332 +msgid "Bringing your own userspace" +msgstr "" + +#: ../source/overview.rst:334 +msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." +msgstr "" + +#: ../source/overview.rst:341 +msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." +msgstr "" + +#: ../source/overview.rst:344 +msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" +msgstr "" + +#: ../source/overview.rst:347 +msgid "`AppImage `_" +msgstr "" + +#: ../source/overview.rst:348 +msgid "`Docker `_" +msgstr "" + +#: ../source/overview.rst:349 +msgid "`Flatpak `_" +msgstr "" + +#: ../source/overview.rst:350 +msgid "`Snapcraft `_" +msgstr "" + +#: ../source/overview.rst:353 +msgid "Bringing your own kernel" +msgstr "" + +#: ../source/overview.rst:355 +msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." +msgstr "" + +#: ../source/overview.rst:360 +msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" +msgstr "" + +#: ../source/overview.rst:364 +msgid "`Vagrant `_" +msgstr "" + +#: ../source/overview.rst:365 +msgid "`VHD `_, `AMI `_, and `other formats `_" +msgstr "" + +#: ../source/overview.rst:366 +msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" +msgstr "" + +#: ../source/overview.rst:369 +msgid "Bringing your own hardware" +msgstr "" + +#: ../source/overview.rst:371 +msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." +msgstr "" + +#: ../source/overview.rst:375 +msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." +msgstr "" + +#: ../source/overview.rst:379 +msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." +msgstr "" + +#: ../source/overview.rst:389 +msgid "The simplified gamut of technologies used to package Python applications." +msgstr "" + +#: ../source/overview.rst:392 +msgid "What about..." +msgstr "" + +#: ../source/overview.rst:394 +msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." +msgstr "" + +#: ../source/overview.rst:398 +msgid "Operating system packages" +msgstr "" + +#: ../source/overview.rst:400 +msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." +msgstr "" + +#: ../source/overview.rst:411 +msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." +msgstr "" + +#: ../source/overview.rst:417 +msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." +msgstr "" + +#: ../source/overview.rst:427 +msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." +msgstr "" + +#: ../source/overview.rst:432 +msgid "Security" +msgstr "Seguridad" + +#: ../source/overview.rst:434 +msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." +msgstr "" + +#: ../source/overview.rst:437 +msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." +msgstr "" + +#: ../source/overview.rst:446 +msgid "Wrap up" +msgstr "" + +#: ../source/overview.rst:448 +msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:6 +msgid "Binary distribution format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:8 +msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:13 +msgid "Abstract" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:15 +msgid "This PEP describes a built-package format for Python called \"wheel\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:17 +msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:27 +msgid "PEP Acceptance" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:29 +msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:34 +msgid "Rationale" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:36 +msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:43 +msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:52 +msgid "Details" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:55 +msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:57 +msgid "Wheel installation notionally consists of two phases:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:59 +msgid "Unpack." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:61 +msgid "Parse ``distribution-1.0.dist-info/WHEEL``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:62 +msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:64 +msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:66 +msgid "Else unpack archive into platlib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:68 +msgid "Spread." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:70 +msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:72 +msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:78 +msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:80 +msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:82 +msgid "Remove empty ``distribution-1.0.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:83 +msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:87 +msgid "Recommended installer features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:97 +msgid "Rewrite ``#!python``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:90 +msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:96 +msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:102 +msgid "Generate script wrappers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:100 +msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:105 +msgid "Recommended archiver features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:112 +msgid "Place ``.dist-info`` at the end of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:108 +msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:115 +msgid "File Format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:118 +msgid "File name convention" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:120 +msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "distribution" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "Distribution name, e.g. 'django', 'pyramid'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "Distribution version, e.g. 1.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:135 +msgid "build tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:130 +msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "language implementation and version tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "E.g. 'py27', 'py2', 'py3'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "abi tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "E.g. 'cp33m', 'abi3', 'none'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "platform tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "E.g. 'linux_x86_64', 'any'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:146 +msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:151 +msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:156 +msgid "Escaping and Unicode" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:158 +msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:161 +msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:164 +msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:166 +msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:169 +msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:172 +msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:176 +msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:182 +msgid "File contents" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:184 +msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:188 +msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:191 +msgid "``{distribution}-{version}.dist-info/`` contains metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:192 +msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:196 +msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:200 +msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:202 +msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:212 +msgid "``Wheel-Version`` is the version number of the Wheel specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:213 +msgid "``Generator`` is the name and optionally the version of the software that produced the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:215 +msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:218 +msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:220 +msgid "``Build`` is the build number and is omitted if there is no build number." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:221 +msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:224 +msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:226 +msgid "Wheel does not contain setup.py or setup.cfg." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:228 +msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:235 +#: ../source/specifications/recording-installed-packages.rst:35 +msgid "The .dist-info directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:237 +msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:239 +msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:241 +msgid "WHEEL is the wheel metadata specific to a build of the package." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:242 +msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:248 +msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:249 +msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:251 +msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:254 +msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:261 +msgid "The .data directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:263 +msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:271 +msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:277 +msgid "Signed wheel files" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:279 +msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:290 +msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:295 +msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:302 +msgid "(The hash value is the same format used in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:304 +msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:307 +msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:312 +msgid "See" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:314 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:315 +msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:316 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:317 +msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:321 +msgid "Comparison to .egg" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:323 +msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:328 +msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:331 +msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:337 +msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:341 +msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:344 +msgid "Wheel is a reference to the other Python." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:348 +msgid "FAQ" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:352 +msgid "Wheel defines a .data directory. Should I put all my data there?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:354 +msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:363 +msgid "Why does wheel include attached signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:365 +msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:373 +msgid "Why does wheel allow JWS signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:375 +msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:381 +msgid "Why does wheel also allow S/MIME signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:383 +msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:386 +msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:391 +msgid "What's the deal with \"purelib\" vs. \"platlib\"?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:393 +msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:398 +msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:403 +msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:409 +msgid "Is it possible to import Python code directly from a wheel file?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:411 +msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:417 +msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:426 +msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:443 +msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:450 +msgid "Changes" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:452 +msgid "Since :pep:`427`, this specification has changed as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:454 +msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:461 +msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:466 +msgid "Appendix" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:468 +msgid "Example urlsafe-base64-nopad implementation::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:482 +msgid "Copyright" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:484 +msgid "This document has been placed into the public domain." +msgstr "" + +#: ../source/specifications/core-metadata.rst:5 +msgid "Core metadata specifications" +msgstr "" + +#: ../source/specifications/core-metadata.rst:7 +msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:10 +msgid "``Metadata-Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:11 +msgid "``Name``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:12 +msgid "``Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:14 +msgid "All the other fields are optional." +msgstr "" + +#: ../source/specifications/core-metadata.rst:16 +msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." +msgstr "" + +#: ../source/specifications/core-metadata.rst:25 +msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:30 +msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." +msgstr "" + +#: ../source/specifications/core-metadata.rst:41 +msgid "Metadata-Version" +msgstr "" + +#: ../source/specifications/core-metadata.rst:45 +msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." +msgstr "" + +#: ../source/specifications/core-metadata.rst:48 +msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:54 +msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." +msgstr "" + +#: ../source/specifications/core-metadata.rst:58 +#: ../source/specifications/core-metadata.rst:80 +#: ../source/specifications/core-metadata.rst:95 +#: ../source/specifications/core-metadata.rst:155 +#: ../source/specifications/core-metadata.rst:170 +#: ../source/specifications/core-metadata.rst:208 +#: ../source/specifications/core-metadata.rst:283 +#: ../source/specifications/core-metadata.rst:287 +#: ../source/specifications/core-metadata.rst:291 +#: ../source/specifications/core-metadata.rst:295 +#: ../source/specifications/core-metadata.rst:327 +#: ../source/specifications/core-metadata.rst:347 +#: ../source/specifications/core-metadata.rst:373 +#: ../source/specifications/core-metadata.rst:391 +#: ../source/specifications/core-metadata.rst:416 +#: ../source/specifications/core-metadata.rst:438 +#: ../source/specifications/core-metadata.rst:600 +#: ../source/specifications/core-metadata.rst:620 +#: ../source/specifications/core-metadata.rst:630 +msgid "Example::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:66 +msgid "Name" +msgstr "Nombre" + +#: ../source/specifications/core-metadata.rst:69 +msgid "Added additional restrictions on format from :pep:`508`" +msgstr "" + +#: ../source/specifications/core-metadata.rst:72 +msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:88 +msgid "Version" +msgstr "Versión" + +#: ../source/specifications/core-metadata.rst:92 +msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:101 +msgid "Dynamic (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:105 +msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." +msgstr "" + +#: ../source/specifications/core-metadata.rst:108 +msgid "When found in the metadata of a source distribution, the following rules apply:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:111 +msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." +msgstr "" + +#: ../source/specifications/core-metadata.rst:115 +msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:118 +msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:122 +msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." +msgstr "" + +#: ../source/specifications/core-metadata.rst:127 +msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:131 +msgid "Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:135 +msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." +msgstr "" + +#: ../source/specifications/core-metadata.rst:146 +msgid "Supported-Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:150 +msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." +msgstr "" + +#: ../source/specifications/core-metadata.rst:164 +msgid "Summary" +msgstr "" + +#: ../source/specifications/core-metadata.rst:168 +msgid "A one-line summary of what the distribution does." +msgstr "" + +#: ../source/specifications/core-metadata.rst:188 +msgid "This field may be specified in the message body instead." +msgstr "" + +#: ../source/specifications/core-metadata.rst:191 +msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:196 +msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." +msgstr "" + +#: ../source/specifications/core-metadata.rst:202 +msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:219 +msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." +msgstr "" + +#: ../source/specifications/core-metadata.rst:223 +msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:232 +msgid "Description-Content-Type" +msgstr "" + +#: ../source/specifications/core-metadata.rst:236 +msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:239 +msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." +msgstr "" + +#: ../source/specifications/core-metadata.rst:253 +msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:259 +msgid "Format::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:263 +msgid "The ``type/subtype`` part has only a few legal values:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:265 +msgid "``text/plain``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:266 +msgid "``text/x-rst``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:267 +msgid "``text/markdown``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:269 +msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:273 +msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:278 +msgid "``GFM`` for `Github-flavored Markdown `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:280 +msgid "``CommonMark`` for `CommonMark `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:299 +msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." +msgstr "" + +#: ../source/specifications/core-metadata.rst:303 +msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:307 +msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:311 +msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." +msgstr "" + +#: ../source/specifications/core-metadata.rst:320 +msgid "Keywords" +msgstr "" + +#: ../source/specifications/core-metadata.rst:324 +msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." +msgstr "" + +#: ../source/specifications/core-metadata.rst:333 +msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." +msgstr "" + +#: ../source/specifications/core-metadata.rst:341 +msgid "Home-page" +msgstr "" + +#: ../source/specifications/core-metadata.rst:345 +msgid "A string containing the URL for the distribution's home page." +msgstr "" + +#: ../source/specifications/core-metadata.rst:353 +msgid "Download-URL" +msgstr "" + +#: ../source/specifications/core-metadata.rst:357 +msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:366 +msgid "Author" +msgstr "" + +#: ../source/specifications/core-metadata.rst:370 +msgid "A string containing the author's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:383 +msgid "Author-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:387 +msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:395 +#: ../source/specifications/core-metadata.rst:442 +msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:405 +msgid "Maintainer" +msgstr "Responsable" + +#: ../source/specifications/core-metadata.rst:409 +msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:412 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:426 +msgid "Maintainer-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:430 +msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:434 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:452 +msgid "License" +msgstr "" + +#: ../source/specifications/core-metadata.rst:456 +msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." +msgstr "" + +#: ../source/specifications/core-metadata.rst:476 +msgid "Classifier (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:480 +msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:485 +#: ../source/specifications/core-metadata.rst:574 +#: ../source/specifications/core-metadata.rst:691 +#: ../source/specifications/core-metadata.rst:715 +msgid "This field may be followed by an environment marker after a semicolon." +msgstr "" + +#: ../source/specifications/core-metadata.rst:496 +msgid "Requires-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:499 +#: ../source/specifications/core-metadata.rst:561 +#: ../source/specifications/core-metadata.rst:663 +#: ../source/specifications/core-metadata.rst:704 +msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." +msgstr "" + +#: ../source/specifications/core-metadata.rst:503 +msgid "Each entry contains a string naming some other distutils project required by this distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:506 +msgid "The format of a requirement string contains from one to four parts:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:508 +msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." +msgstr "" + +#: ../source/specifications/core-metadata.rst:510 +msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." +msgstr "" + +#: ../source/specifications/core-metadata.rst:513 +msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:516 +msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." +msgstr "" + +#: ../source/specifications/core-metadata.rst:519 +msgid "See :pep:`508` for full details of the allowed format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:521 +msgid "The project names should correspond to names as found on the `Python Package Index`_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:524 +msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:538 +msgid "Requires-Python" +msgstr "" + +#: ../source/specifications/core-metadata.rst:542 +msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." +msgstr "" + +#: ../source/specifications/core-metadata.rst:546 +msgid "The value must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:548 +msgid "This field cannot be followed by an environment marker." +msgstr "" + +#: ../source/specifications/core-metadata.rst:558 +msgid "Requires-External (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:565 +msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:570 +msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:576 +msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." +msgstr "" + +#: ../source/specifications/core-metadata.rst:581 +msgid "Notice that there is no particular rule on the strings to be used." +msgstr "" + +#: ../source/specifications/core-metadata.rst:593 +msgid "Project-URL (multiple-use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:597 +msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." +msgstr "" + +#: ../source/specifications/core-metadata.rst:604 +msgid "The label is free text limited to 32 characters." +msgstr "" + +#: ../source/specifications/core-metadata.rst:612 +msgid "Provides-Extra (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:616 +msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." +msgstr "" + +#: ../source/specifications/core-metadata.rst:625 +msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:635 +msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." +msgstr "" + +#: ../source/specifications/core-metadata.rst:639 +msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:644 +msgid "Rarely Used Fields" +msgstr "" + +#: ../source/specifications/core-metadata.rst:646 +msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:651 +msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." +msgstr "" + +#: ../source/specifications/core-metadata.rst:660 +msgid "Provides-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:667 +msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:672 +msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:679 +msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:687 +msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." +msgstr "" + +#: ../source/specifications/core-metadata.rst:701 +msgid "Obsoletes-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:708 +msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." +msgstr "" + +#: ../source/specifications/core-metadata.rst:712 +msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:717 +msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:730 +msgid "reStructuredText markup: http://docutils.sourceforge.net/" +msgstr "" + +#: ../source/specifications/core-metadata.rst:735 +msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:6 +msgid "Declaring build system dependencies" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:8 +msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:5 +msgid "Declaring project metadata" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:7 +msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:12 +msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:18 +msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:27 +msgid "The only fields required to be statically defined are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:29 +#: ../source/specifications/declaring-project-metadata.rst:41 +msgid "``name``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:31 +msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:34 +#: ../source/specifications/declaring-project-metadata.rst:54 +msgid "``version``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:36 +msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:43 +#: ../source/specifications/declaring-project-metadata.rst:56 +#: ../source/specifications/declaring-project-metadata.rst:68 +#: ../source/specifications/declaring-project-metadata.rst:117 +msgid "TOML_ type: string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:44 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:47 +msgid "The name of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:49 +msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:57 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:60 +msgid "The version of the project as supported by :pep:`440`." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:62 +msgid "Users SHOULD prefer to specify already-normalized versions." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:66 +msgid "``description``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:69 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:72 +msgid "The summary description of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:76 +msgid "``readme``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:78 +msgid "TOML_ type: string or table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:79 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:83 +msgid "The full description of the project (i.e. the README)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:85 +msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:96 +msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:103 +msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:115 +msgid "``requires-python``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:118 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:121 +msgid "The Python version requirements of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:125 +msgid "``license``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:127 +msgid "TOML_ type: table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:128 +msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:131 +msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:140 +msgid "``authors``/``maintainers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:142 +msgid "TOML_ type: Array of inline tables with string keys and values" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:143 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:149 +msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:154 +msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:157 +msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:163 +msgid "Using the data to fill in :ref:`core metadata ` is as follows:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:166 +msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:169 +msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:173 +msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:177 +msgid "Multiple values should be separated by commas." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:181 +msgid "``keywords``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:183 +#: ../source/specifications/declaring-project-metadata.rst:193 +msgid "TOML_ type: array of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:184 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:187 +msgid "The keywords for the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:191 +msgid "``classifiers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:194 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:197 +msgid "Trove classifiers which apply to the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:201 +msgid "``urls``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:203 +msgid "TOML_ type: table with keys and values of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:204 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:207 +msgid "A table of URLs where the key is the URL label and the value is the URL itself." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:212 +msgid "Entry points" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:214 +msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:216 +msgid ":ref:`Entry points specification `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:218 +msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:224 +msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:228 +msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:234 +msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:242 +msgid "``dependencies``/``optional-dependencies``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:244 +msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:247 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:251 +msgid "The (optional) dependencies of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:253 +msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:258 +msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:269 +msgid "``dynamic``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:271 +msgid "TOML_ type: array of string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:272 +msgid "A corresponding :ref:`core metadata ` field does not exist" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:275 +msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:281 +msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:283 +msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:285 +msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:290 +msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:294 +msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:296 +msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:300 +msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:6 +msgid "Dependency specifiers" +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:8 +msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:11 +msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." +msgstr "" + +#: ../source/specifications/direct-url.rst:6 +msgid "Recording the Direct URL Origin of installed distributions" +msgstr "" + +#: ../source/specifications/direct-url.rst:8 +msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." +msgstr "" + +#: ../source/specifications/direct-url.rst:17 +msgid "Specification" +msgstr "" + +#: ../source/specifications/direct-url.rst:19 +msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/direct-url.rst:23 +#: ../source/specifications/recording-installed-packages.rst:206 +msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." +msgstr "" + +#: ../source/specifications/direct-url.rst:26 +msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." +msgstr "" + +#: ../source/specifications/direct-url.rst:29 +msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." +msgstr "" + +#: ../source/specifications/direct-url.rst:36 +msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." +msgstr "" + +#: ../source/specifications/direct-url.rst:39 +msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" +msgstr "" + +#: ../source/specifications/direct-url.rst:45 +msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." +msgstr "" + +#: ../source/specifications/direct-url.rst:49 +msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" +msgstr "" + +#: ../source/specifications/direct-url.rst:52 +msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." +msgstr "" + +#: ../source/specifications/direct-url.rst:58 +msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." +msgstr "" + +#: ../source/specifications/direct-url.rst:61 +msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." +msgstr "" + +#: ../source/specifications/direct-url.rst:68 +msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:71 +msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." +msgstr "" + +#: ../source/specifications/direct-url.rst:78 +msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:81 +msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." +msgstr "" + +#: ../source/specifications/direct-url.rst:84 +msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." +msgstr "" + +#: ../source/specifications/direct-url.rst:91 +msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." +msgstr "" + +#: ../source/specifications/direct-url.rst:96 +msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." +msgstr "" + +#: ../source/specifications/direct-url.rst:102 +msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." +msgstr "" + +#: ../source/specifications/direct-url.rst:110 +msgid "Registered VCS" +msgstr "" + +#: ../source/specifications/direct-url.rst:112 +msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." +msgstr "" + +#: ../source/specifications/direct-url.rst:122 +msgid "Git" +msgstr "" + +#: ../source/specifications/direct-url.rst:124 +#: ../source/specifications/direct-url.rst:156 +#: ../source/specifications/direct-url.rst:179 +#: ../source/specifications/direct-url.rst:202 +msgid "Home page" +msgstr "" + +#: ../source/specifications/direct-url.rst:126 +msgid "https://git-scm.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:128 +#: ../source/specifications/direct-url.rst:160 +#: ../source/specifications/direct-url.rst:183 +#: ../source/specifications/direct-url.rst:206 +msgid "vcs command" +msgstr "" + +#: ../source/specifications/direct-url.rst:130 +#: ../source/specifications/direct-url.rst:134 +msgid "git" +msgstr "" + +#: ../source/specifications/direct-url.rst:132 +#: ../source/specifications/direct-url.rst:164 +#: ../source/specifications/direct-url.rst:187 +#: ../source/specifications/direct-url.rst:210 +msgid "``vcs`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:136 +#: ../source/specifications/direct-url.rst:168 +#: ../source/specifications/direct-url.rst:191 +#: ../source/specifications/direct-url.rst:214 +msgid "``requested_revision`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:138 +msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." +msgstr "" + +#: ../source/specifications/direct-url.rst:141 +#: ../source/specifications/direct-url.rst:172 +#: ../source/specifications/direct-url.rst:195 +#: ../source/specifications/direct-url.rst:219 +msgid "``commit_id`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:143 +msgid "A commit hash (40 hexadecimal characters sha1)." +msgstr "" + +#: ../source/specifications/direct-url.rst:147 +msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." +msgstr "" + +#: ../source/specifications/direct-url.rst:154 +msgid "Mercurial" +msgstr "" + +#: ../source/specifications/direct-url.rst:158 +msgid "https://www.mercurial-scm.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:162 +#: ../source/specifications/direct-url.rst:166 +msgid "hg" +msgstr "" + +#: ../source/specifications/direct-url.rst:170 +msgid "A tag name, branch name, changeset ID, shortened changeset ID." +msgstr "" + +#: ../source/specifications/direct-url.rst:174 +msgid "A changeset ID (40 hexadecimal characters)." +msgstr "" + +#: ../source/specifications/direct-url.rst:177 +msgid "Bazaar" +msgstr "" + +#: ../source/specifications/direct-url.rst:181 +msgid "https://bazaar.canonical.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:185 +#: ../source/specifications/direct-url.rst:189 +msgid "bzr" +msgstr "" + +#: ../source/specifications/direct-url.rst:193 +msgid "A tag name, branch name, revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:197 +msgid "A revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:200 +msgid "Subversion" +msgstr "" + +#: ../source/specifications/direct-url.rst:204 +msgid "https://subversion.apache.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:208 +#: ../source/specifications/direct-url.rst:212 +msgid "svn" +msgstr "" + +#: ../source/specifications/direct-url.rst:216 +msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." +msgstr "" + +#: ../source/specifications/direct-url.rst:221 +msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." +msgstr "" + +#: ../source/specifications/direct-url.rst:229 +msgid "Example direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:231 +msgid "Source archive:" +msgstr "" + +#: ../source/specifications/direct-url.rst:242 +msgid "Git URL with tag and commit-hash:" +msgstr "" + +#: ../source/specifications/direct-url.rst:255 +msgid "Local directory:" +msgstr "" + +#: ../source/specifications/direct-url.rst:264 +msgid "Local directory installed in editable mode:" +msgstr "" + +#: ../source/specifications/direct-url.rst:277 +msgid "Example pip commands and their effect on direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:279 +msgid "Commands that generate a ``direct_url.json``:" +msgstr "" + +#: ../source/specifications/direct-url.rst:281 +msgid "pip install https://example.com/app-1.0.tgz" +msgstr "" + +#: ../source/specifications/direct-url.rst:282 +msgid "pip install https://example.com/app-1.0.whl" +msgstr "" + +#: ../source/specifications/direct-url.rst:283 +msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" +msgstr "" + +#: ../source/specifications/direct-url.rst:284 +msgid "pip install ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:285 +msgid "pip install file:///home/user/app" +msgstr "" + +#: ../source/specifications/direct-url.rst:286 +msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" +msgstr "" + +#: ../source/specifications/direct-url.rst:290 +msgid "pip install -e ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:292 +msgid "Commands that *do not* generate a ``direct_url.json``" +msgstr "" + +#: ../source/specifications/direct-url.rst:294 +msgid "pip install app" +msgstr "" + +#: ../source/specifications/direct-url.rst:295 +msgid "pip install app --no-index --find-links https://example.com/" +msgstr "" + +#: ../source/specifications/entry-points.rst:5 +msgid "Entry points specification" +msgstr "" + +#: ../source/specifications/entry-points.rst:7 +msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" +msgstr "" + +#: ../source/specifications/entry-points.rst:11 +msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." +msgstr "" + +#: ../source/specifications/entry-points.rst:14 +msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." +msgstr "" + +#: ../source/specifications/entry-points.rst:19 +msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." +msgstr "" + +#: ../source/specifications/entry-points.rst:28 +msgid "Data model" +msgstr "" + +#: ../source/specifications/entry-points.rst:30 +msgid "Conceptually, an entry point is defined by three required properties:" +msgstr "" + +#: ../source/specifications/entry-points.rst:32 +msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:42 +msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:51 +msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:64 +msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." +msgstr "" + +#: ../source/specifications/entry-points.rst:68 +msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." +msgstr "" + +#: ../source/specifications/entry-points.rst:73 +msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." +msgstr "" + +#: ../source/specifications/entry-points.rst:80 +msgid "File format" +msgstr "Formato de archivo" + +#: ../source/specifications/entry-points.rst:82 +msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." +msgstr "" + +#: ../source/specifications/entry-points.rst:87 +msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:97 +msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:100 +msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." +msgstr "" + +#: ../source/specifications/entry-points.rst:104 +msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." +msgstr "" + +#: ../source/specifications/entry-points.rst:112 +msgid "For example::" +msgstr "Por ejemplo::" + +#: ../source/specifications/entry-points.rst:124 +msgid "Use for scripts" +msgstr "" + +#: ../source/specifications/entry-points.rst:126 +msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." +msgstr "" + +#: ../source/specifications/entry-points.rst:134 +msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:141 +msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." +msgstr "" + +#: ../source/specifications/entry-points.rst:149 +msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." +msgstr "" + +#: ../source/specifications/entry-points.rst:154 +msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." +msgstr "" + +#: ../source/specifications/index.rst:4 +msgid "PyPA specifications" +msgstr "Especificaciones de PyPA" + +#: ../source/specifications/index.rst:6 +msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." +msgstr "" + +#: ../source/specifications/index.rst:13 +msgid "Package Distribution Metadata" +msgstr "Metadatos de distribución de paquetes" + +#: ../source/specifications/index.rst:30 +msgid "Package Distribution File Formats" +msgstr "Formatos de archivo de distribución de paquetes" + +#: ../source/specifications/index.rst:40 +msgid "Package Index Interfaces" +msgstr "Interfaces del Índice de paquetes" + +#: ../source/specifications/platform-compatibility-tags.rst:6 +msgid "Platform compatibility tags" +msgstr "Etiquetas de compatibilidad con plataformas" + +#: ../source/specifications/platform-compatibility-tags.rst:8 +msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:12 +msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:16 +msgid "Platform tags for Windows" +msgstr "Etiquetas de plataforma para Windows" + +#: ../source/specifications/platform-compatibility-tags.rst:18 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:22 +msgid "Platform tags for macOS (Mac OS X)" +msgstr "Etiquetas de plataforma para macOS (Mac OS X)" + +#: ../source/specifications/platform-compatibility-tags.rst:24 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:28 +msgid "Platform tags for common Linux distributions" +msgstr "Etiquetas de plataforma para distribuciones Linux comunes" + +#: ../source/specifications/platform-compatibility-tags.rst:32 +msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:36 +msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:41 +msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:44 +msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:46 +msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:49 +msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:54 +msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:59 +msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:65 +msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:71 +msgid "Manylinux compatibility support" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:74 +msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:76 +msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:79 +msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "Tool" +msgstr "Herramienta" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux1``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2010``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2014``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux_x_y``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=8.1.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=20.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "auditwheel" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=1.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=2.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.3.0`` [#]_" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:90 +msgid "Platform tags for other \\*nix platforms" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:92 +msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:98 +msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" +msgstr "" + +#: ../source/specifications/pypirc.rst:6 +msgid "The :file:`.pypirc` file" +msgstr "El archivo :file:`.pypirc`" + +#: ../source/specifications/pypirc.rst:8 +msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." +msgstr "" + +#: ../source/specifications/pypirc.rst:13 +msgid "The format (originally defined by the :ref:`distutils` package) is:" +msgstr "El formato (definido originalmente por el paquete :ref:`distutils`) es:" + +#: ../source/specifications/pypirc.rst:32 +msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:35 +msgid "Each section describing a repository defines three fields:" +msgstr "" + +#: ../source/specifications/pypirc.rst:37 +msgid "``repository``: The URL of the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:38 +msgid "``username``: The registered username on the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:39 +msgid "``password``: The password that will used to authenticate the username." +msgstr "" + +#: ../source/specifications/pypirc.rst:43 +msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." +msgstr "" + +#: ../source/specifications/pypirc.rst:47 +msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" +msgstr "" + +#: ../source/specifications/pypirc.rst:57 +msgid "Common configurations" +msgstr "Configuraciones habituales" + +#: ../source/specifications/pypirc.rst:61 +msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." +msgstr "" + +#: ../source/specifications/pypirc.rst:66 +msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" +msgstr "" + +#: ../source/specifications/pypirc.rst:82 +msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." +msgstr "" + +#: ../source/specifications/pypirc.rst:86 +msgid "Using a PyPI token" +msgstr "Uso de una ficha de PyPI" + +#: ../source/specifications/pypirc.rst:88 +msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" +msgstr "" + +#: ../source/specifications/pypirc.rst:97 +msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." +msgstr "" + +#: ../source/specifications/pypirc.rst:103 +msgid "Using another package index" +msgstr "Uso de otro índice de paquetes" + +#: ../source/specifications/pypirc.rst:105 +msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" +msgstr "" + +#: ../source/specifications/pypirc.rst:132 +msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:5 +msgid "Recording installed projects" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:7 +msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:12 +msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:21 +msgid "History and change workflow" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:23 +msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:29 +msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:37 +msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:41 +msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:50 +msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:60 +msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:69 +msgid "This ``.dist-info`` directory can contain these files, described in detail below:" +msgstr "" +"El directorio ``.dist-info`` puede contener los archivos que se describen a " +"detalle a continuación:" + +#: ../source/specifications/recording-installed-packages.rst:72 +msgid "``METADATA``: contains project metadata" +msgstr "``METADATA``: contiene metadatos sobre el proyecto" + +#: ../source/specifications/recording-installed-packages.rst:73 +msgid "``RECORD``: records the list of installed files." +msgstr "``RECORD``: registra la lista de archivos instalados." + +#: ../source/specifications/recording-installed-packages.rst:74 +msgid "``INSTALLER``: records the name of the tool used to install the project." +msgstr "" +"``INSTALLER``: registra el nombre de la herramienta utilizada para instalar " +"el proyecto." + +#: ../source/specifications/recording-installed-packages.rst:76 +msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:82 +msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:87 +msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:94 +msgid "The METADATA file" +msgstr "El archivo METADATA" + +#: ../source/specifications/recording-installed-packages.rst:96 +msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:99 +msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:105 +msgid "The RECORD file" +msgstr "El archivo RECORD" + +#: ../source/specifications/recording-installed-packages.rst:107 +msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:110 +msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:113 +msgid "field delimiter: ``,`` (comma)," +msgstr "delimitador de campos: ``,`` (coma)," + +#: ../source/specifications/recording-installed-packages.rst:114 +msgid "quoting char: ``\"`` (straight double quote)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:115 +msgid "line terminator: either ``\\r\\n`` or ``\\n``." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:117 +msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:120 +msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:125 +msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:130 +msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:133 +msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:139 +msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:146 +msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:151 +msgid "Here is an example snippet of a possible ``RECORD`` file::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:170 +msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:177 +msgid "The INSTALLER file" +msgstr "El archivo INSTALLER" + +#: ../source/specifications/recording-installed-packages.rst:179 +msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:185 +msgid "The file can be terminated by zero or more ASCII whitespace characters." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:187 +msgid "Here are examples of two possible ``INSTALLER`` files::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:195 +msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:201 +msgid "The direct_url.json file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:203 +msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:209 +msgid "Its detailed specification is at :ref:`direct-url`." +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:6 +msgid "Simple repository API" +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:8 +msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:6 +msgid "Source distribution format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:8 +msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:13 +msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:21 +msgid "Source distributions are also known as *sdists* for short." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:24 +msgid "Source distribution file name" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:26 +msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:31 +msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:35 +msgid "Source distribution file format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:37 +msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:45 +msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:48 +msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:6 +msgid "Version specifiers" +msgstr "" + +#: ../source/specifications/version-specifiers.rst:8 +msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:11 +msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." +msgstr "" + +#: ../source/support.rst:3 +msgid "How to Get Support" +msgstr "Cómo obtener asistencia" + +#: ../source/support.rst:5 +msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." +msgstr "" + +#: ../source/support.rst:8 +msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:5 +msgid "Creating Documentation" +msgstr "Creación de documentación" + +#: ../source/tutorials/creating-documentation.rst:7 +msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:13 +msgid "Installing Sphinx" +msgstr "Instalación de Sphinx" + +#: ../source/tutorials/creating-documentation.rst:14 +msgid "Use ``pip`` to install Sphinx:" +msgstr "Sírvase de ``pip`` para instalar Sphinx:" + +#: ../source/tutorials/creating-documentation.rst:28 +msgid "For other installation methods, see this `installation guide`_ by Sphinx." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:33 +msgid "Getting Started With Sphinx" +msgstr "Primeros pasos con Sphinx" + +#: ../source/tutorials/creating-documentation.rst:35 +msgid "Create a ``docs`` directory inside your project to hold your documentation:" +msgstr "" +"Cree un directorio denominado ``docs`` en el proyecto; allí se almacenará su " +"documentación:" + +#: ../source/tutorials/creating-documentation.rst:42 +msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" +msgstr "Ejecute ``sphinx-quickstart`` dentro del directorio ``docs``:" + +#: ../source/tutorials/creating-documentation.rst:49 +msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:51 +msgid "You can add some information about your project in ``index.rst``, then build them:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:57 +msgid "For more details on the build process, see this `guide`_ by Read The Docs." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:62 +msgid "Other Sources" +msgstr "Otras fuentes" + +#: ../source/tutorials/creating-documentation.rst:64 +msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/index.rst:4 +msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:5 +msgid "Installing Packages" +msgstr "Instalación de paquetes" + +#: ../source/tutorials/installing-packages.rst:7 +msgid "This section covers the basics of how to install Python :term:`packages `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:10 +msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:28 +msgid "Requirements for Installing Packages" +msgstr "Requisitos para instalar paquetes" + +#: ../source/tutorials/installing-packages.rst:30 +msgid "This section describes the steps to follow before installing other Python packages." +msgstr "" +"Esta sección describe los pasos que hay que seguir antes de instalar otros " +"paquetes de Python." + +#: ../source/tutorials/installing-packages.rst:35 +msgid "Ensure you can run Python from the command line" +msgstr "Cerciórese de que pueda ejecutar Python desde la línea de órdenes" + +#: ../source/tutorials/installing-packages.rst:37 +msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:53 +msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:57 +msgid "If you're a newcomer and you get an error like this:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:66 +msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:72 +msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:82 +msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:87 +msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:99 +msgid "Ensure you can run pip from the command line" +msgstr "Cerciórese de que pueda ejecutar pip desde la línea de órdenes" + +#: ../source/tutorials/installing-packages.rst:101 +msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:116 +msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:124 +msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:139 +msgid "If that still doesn't allow you to run ``python -m pip``:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:141 +msgid "Securely Download `get-pip.py `_ [1]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:144 +msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:150 +msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:159 +msgid "Ensure pip, setuptools, and wheel are up to date" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:161 +msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:169 +msgid "Optionally, create a virtual environment" +msgstr "Facultativamente, cree un entorno virtual" + +#: ../source/tutorials/installing-packages.rst:171 +msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:188 +msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:195 +msgid "Creating Virtual Environments" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:197 +msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:203 +msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:209 +msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:213 +msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:216 +msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:220 +msgid "Currently, there are two common tools for creating Python virtual environments:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:222 +msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:225 +msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:230 +msgid "The basic usage is like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:232 +msgid "Using `venv`_:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:248 +msgid "Using :ref:`virtualenv`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:264 +msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:266 +msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:271 +msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:281 +msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:288 +msgid "Use pip for Installing" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:290 +msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:297 +msgid "Installing from PyPI" +msgstr "Instalación a partir de PyPI" + +#: ../source/tutorials/installing-packages.rst:299 +msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:307 +msgid "To install the latest version of \"SomeProject\":" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:321 +msgid "To install a specific version:" +msgstr "Para instalar una versión específica:" + +#: ../source/tutorials/installing-packages.rst:335 +msgid "To install greater than or equal to one version and less than another:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:350 +msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:365 +msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:370 +msgid "Source Distributions vs Wheels" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:372 +msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:378 +msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:383 +msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:391 +msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:408 +msgid "Installing to the User Site" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:410 +msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:425 +msgid "For more information see the `User Installs `_ section from the pip docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:429 +msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:432 +msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:440 +msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:446 +msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:462 +msgid "Install a list of requirements specified in a :ref:`Requirements File `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:478 +msgid "Installing from VCS" +msgstr "Instalación a partir de un sistema de control de versiones" + +#: ../source/tutorials/installing-packages.rst:480 +msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:502 +msgid "Installing from other Indexes" +msgstr "Instalación a partir de otros índices" + +#: ../source/tutorials/installing-packages.rst:504 +msgid "Install from an alternate index" +msgstr "Instalación a partir de un índice alternativo" + +#: ../source/tutorials/installing-packages.rst:518 +msgid "Search an additional index during install, in addition to :term:`PyPI `" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:534 +msgid "Installing from a local src tree" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:537 +msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:554 +msgid "You can also install normally from src" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:571 +msgid "Install a particular source archive file." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:585 +msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:605 +msgid "Installing from other sources" +msgstr "Instalación a partir de otras fuentes" + +#: ../source/tutorials/installing-packages.rst:607 +msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:619 +msgid "Installing Prereleases" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:621 +msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:637 +msgid "Installing Setuptools \"Extras\"" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:639 +msgid "Install `setuptools extras`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:659 +msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:668 +msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:673 +msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:4 +msgid "Managing Application Dependencies" +msgstr "Gestión de las dependencias de aplicación" + +#: ../source/tutorials/managing-dependencies.rst:6 +msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:9 +msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:13 +msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:17 +msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:24 +msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:30 +msgid "Installing Pipenv" +msgstr "Instalación de Pipenv" + +#: ../source/tutorials/managing-dependencies.rst:32 +msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:38 +msgid "Use ``pip`` to install Pipenv:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:54 +msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:65 +msgid "Installing packages for your project" +msgstr "Instalación de paquetes para su proyecto" + +#: ../source/tutorials/managing-dependencies.rst:67 +msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:76 +msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:112 +msgid "Using installed packages" +msgstr "Utilización de paquetes instalados" + +#: ../source/tutorials/managing-dependencies.rst:114 +msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:125 +msgid "Then you can run this script using ``pipenv run``:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:131 +msgid "You should get output similar to this:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:137 +msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:143 +#: ../source/tutorials/packaging-projects.rst:594 +msgid "Next steps" +msgstr "Próximos pasos" + +#: ../source/tutorials/managing-dependencies.rst:145 +msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:148 +msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:151 +msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:160 +msgid "Other Tools for Application Dependency Management" +msgstr "Otras herramientas para la gestión de las dependencias de aplicación" + +#: ../source/tutorials/managing-dependencies.rst:162 +msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:166 +msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:172 +msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:175 +msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:177 +msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:2 +msgid "Packaging Python Projects" +msgstr "Empaquetamiento de proyectos Python" + +#: ../source/tutorials/packaging-projects.rst:4 +msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:10 +msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:18 +msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:35 +msgid "A simple project" +msgstr "Un proyecto sencillo" + +#: ../source/tutorials/packaging-projects.rst:37 +msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:41 +msgid "Create the following file structure locally:" +msgstr "Cree la estructura siguiente de manera local:" + +#: ../source/tutorials/packaging-projects.rst:51 +msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:54 +msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:63 +msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:67 +msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:75 +msgid "Creating the package files" +msgstr "Creación de los archivos del paquete" + +#: ../source/tutorials/packaging-projects.rst:77 +msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:95 +msgid "Creating a test directory" +msgstr "Creación de un directorio de pruebas" + +#: ../source/tutorials/packaging-projects.rst:97 +msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:101 +msgid "Creating pyproject.toml" +msgstr "Creación de pyproject.toml" + +#: ../source/tutorials/packaging-projects.rst:103 +msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:117 +msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:121 +msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:127 +msgid "See :pep:`517` and :pep:`518` for background and details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:131 +msgid "Configuring metadata" +msgstr "Configuración de los metadatos" + +#: ../source/tutorials/packaging-projects.rst:133 +msgid "There are two types of metadata: static and dynamic." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:135 +msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:137 +msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:141 +msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:148 +msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:153 +msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:185 +msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:191 +#: ../source/tutorials/packaging-projects.rst:286 +msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:196 +msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:199 +#: ../source/tutorials/packaging-projects.rst:293 +msgid "``author`` and ``author_email`` are used to identify the author of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:201 +#: ../source/tutorials/packaging-projects.rst:295 +msgid "``description`` is a short, one-sentence summary of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:202 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:206 +#: ../source/tutorials/packaging-projects.rst:300 +msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:208 +#: ../source/tutorials/packaging-projects.rst:302 +msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:211 +#: ../source/tutorials/packaging-projects.rst:305 +msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:213 +#: ../source/tutorials/packaging-projects.rst:307 +msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:221 +msgid "In the ``options`` category, we have controls for setuptools itself:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:223 +msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:227 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:234 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:238 +#: ../source/tutorials/packaging-projects.rst:329 +msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:244 +msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:248 +msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:283 +msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:291 +msgid "``version`` is the package version. See :pep:`440` for more details on versions." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:296 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:314 +msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:319 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:325 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:333 +msgid "Creating README.md" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:335 +msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:347 +msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:354 +msgid "Creating a LICENSE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:356 +msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:387 +msgid "Including other files" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:389 +msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:393 +msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:402 +msgid "Generating distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:404 +msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:408 +msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:422 +msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:425 +msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:439 +msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:449 +msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:458 +msgid "Uploading the distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:460 +msgid "Finally, it's time to upload your package to the Python Package Index!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:462 +msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:470 +msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:477 +msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:492 +msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:506 +msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:510 +msgid "After the command completes, you should see output similar to this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:523 +msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:528 +msgid "Installing your newly uploaded package" +msgstr "Instalación de su paquete recién cargado" + +#: ../source/tutorials/packaging-projects.rst:530 +msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:546 +msgid "Make sure to specify your username in the package name!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:548 +msgid "pip should install the package from TestPyPI and the output should look something like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:558 +msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:565 +msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:580 +msgid "and import the package:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:588 +msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:596 +msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:599 +msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:604 +msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:608 +msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:610 +msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:613 +msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:617 +msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:619 +msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:622 +msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:624 +msgid "Read about :doc:`/guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:625 +msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." +msgstr "" From 1688177f924da576aa058af5dc2e516faa81a45b Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Sun, 29 Aug 2021 18:15:43 +0200 Subject: [PATCH 0098/1072] Translated using Weblate (Chinese (Simplified)) Currently translated at 24.7% (563 of 2271 strings) Translated using Weblate (Chinese (Simplified)) Currently translated at 24.3% (554 of 2271 strings) Translated using Weblate (Chinese (Simplified)) Currently translated at 24.0% (547 of 2271 strings) Translated using Weblate (Chinese (Simplified)) Currently translated at 20.6% (468 of 2271 strings) Translated using Weblate (Spanish) Currently translated at 5.4% (124 of 2271 strings) Co-authored-by: meowmeowmeowcat Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/es/ Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hans/ Translation: pypa/packaging.python.org --- locales/es/LC_MESSAGES/messages.mo | Bin 10362 -> 10456 bytes locales/es/LC_MESSAGES/messages.po | 9 +- locales/zh_Hans/LC_MESSAGES/messages.mo | Bin 79427 -> 99446 bytes locales/zh_Hans/LC_MESSAGES/messages.po | 200 +++++++++++++++++------- 4 files changed, 149 insertions(+), 60 deletions(-) diff --git a/locales/es/LC_MESSAGES/messages.mo b/locales/es/LC_MESSAGES/messages.mo index 650480cfe77d5931ca19931f50bb573bc4a1b16a..d5075fc17fa18a3cd4a29ce418b69d0a7ac6fd15 100644 GIT binary patch delta 2730 zcmZ|QdrX&A9LMo5atA}@CTJiaD9Y`}Pxx_D#0vsi3aMFK3`q(L1OhC?dN$WuHRc~N zul*yonOkLTeva|@D<)zPy;4V#aTWTITULiL*o1l5 zjoCPiYWN$}b9XU{_HD*rF`IXdddQ4FOX8rOXJH0b;U?_B5FEy6yoLCz2Ik5M*^8hO+_jy)upJE9YAHI*}Z-WvpGM9X*h-? z(WX#q>37sJTF&q_paj(Kvym}a^$PN@5gy`#8ajm=@f_*}qqrU?QK=5$pcf=!F&1Jl z9!CwN7xm(oQ5_yc#$*>z1G%IEKl%l8IA_ zeW*Ds;}DLusQdM(2KrGQ9YlY_s7#EaI`|b<;edFS>%t$PLsQ z_zCsmP__a))z+e}ug7ZKi^|w}^x#e8CpLox7{Zp(A}zzS0nC2`70uZ!-INbdt38tW zP)hSrtGg8Gt5v$zqek9|dSSooMbviu#62HJJvWEit`G1q#`6&EIo3xdhYP1sBl`%| zf!pr+Z|->%HuW9mrs-=>8TYyY{$i2l8jHawx+qs41C5O;rdBMZe3z4YY5& zsA!J6P^;|Sthm{wMbjt z>nBkIJA+kt88_oEcoZ|z9U7C8I`Ij!JP2s-r#b{Xyhi_C9L2 z+(AA6J=Wu0?8U9*T?6?T_506I9sbUtl22s@y_iNX_>CRJKpa4BnS)Q@Rn&9ys731~ zeOmQxsQvv4YHCI>05!N;LT#iFS|5w$5h{+pM#04M#0g>(QAwz%K@~Nm=}@U4G-9m_ zeJ>V^M)fSwzjy%;xpj3&rF;SFbY(-V@~>2#Ga%bdv=G%q`%r3FOr>U1d8i?@hBXPA z!8Sq@rDUrp$)N-b=HC+J*1SWbVKGeyIa}ghIf~B_Jp`W#e`)0S7@=%-`>*hi&Q(*T z^5g>k|5chLl~&@2T5uYuy+CM1YA&?YRkU?V{WZQ;s4cRc2qTIKc7;7n=%b>dj|tP~ z-|JevUBrGOn$V)u%0EeD6DoX<^d)rcMJmULDqO!#?OB_7XdYX9z8_ zt;9CMN8}O%guY-e5!!Zjg!XY0(MLQ=sDu;8HBEblDkBQRyuSPrkEghBq(5Tc(%9yn q*51CZ-pL;W{Jntxo}EqbEc?G_8~y=P()dFF delta 2652 zcmX}te@vBC9LMo57eXY^?o}f#@Me-ESMdUhqLnDZRmvdLzyeFSX(fy3rdju@qjxP|y7)$BM9%-}+aWtwH-X1pGEU=Hp^{_J@!H{cL3fNlog^fQif`;#|XCJB0P#D&4y8X z=nQK6{EC|CAE@7_k`Bgh3sDnX9%TLf4ry3QLmR4tK3swyqf$MJ>fldYjaf8ahnr9{ zsX=wT4K?5vWDeGWnvjS5Ssxd=uoI~7hePClBb9SBtim9}t-~1B<5A4ROQ;lQvw&K| z5SN*_1oeFs^?+K`KwHp%Fe(#$r~w|sYCMT?ob=ocO>9w~VR2MPU8sy4M(u$iRL5h; z3AHKLehp)M&gY0IW9_&Cd$ANxqc-P1cqE1Fa&)v*A2K@WeL+RL{48qo{Edvs{&j{} zAAhE(j-t*w)bZQzJ|9NiH-I{xpI|eNpdPf0o0nlZY9f1)=X&;%Yj{7|VBerpHje7( zGFD<1zpB7GWYX4y%G7(PwfxL^)_D=N>&KBX*c7hBxoog9+=A&m-wsk?vi1rp1N~Tp zAD{*>>b}2%WYK1ERAfHt)U4yO7I&hSpcl1dpQHLsppNY|)RGpkVYCVBaRtw}I2G;M zUM$3Z)Qe^WHM1X3=Q)Au=r`2NLaav>hEaQG4{GgSKn-93bv(bv+i(K);0592b0X;J z95zr{gWae#8bYNuf%^U`Dl@sfEHtA6)Icjx_q8E^_97R?X8ouPeu>&!f1zGPIgCcX zUymA4<0A5ZCzWm*wC1N!o9HX#onhxt85l#&@Dj2eEWod|Npn%{#i*H8VKp}3Iy{E0 zIEuS)1GCW*^`kO=X0eyt)#qu@3@1=2PGQ&@X(5s|t3>*+R@4jUWz_wz;ZA%L58xzf zBKyd{et!Tp;8!t&Z+b>k3f*Zz(=&tdY&7;QVIU^CH0 zXx%kX9kuCFLq+@KKH_oW8A5$l5-JZ6%s<(&(xq}YL6-g3tWq>xbP^t&{@~o{8#xVSJ&h=6ORzp#1jPNe*e1Nzb4mG*@zL^Kupp{%*%i7G;SwvkY2B3Aje, 2021. +# meowmeowmeowcat , 2021. msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-08-09 18:25+0000\n" -"Last-Translator: Adolfo Jayme Barrientos \n" +"PO-Revision-Date: 2021-08-13 22:32+0000\n" +"Last-Translator: meowmeowmeowcat \n" "Language-Team: Spanish \n" "Language: es\n" @@ -1109,7 +1110,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:121 msgid "26190085" -msgstr "" +msgstr "26190085" #: ../source/guides/analyzing-pypi-package-downloads.rst:124 msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." @@ -3078,7 +3079,7 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:25 msgid "``setuptools`` 27.0.0" -msgstr "" +msgstr "``setuptools`` 27.0.0" #: ../source/guides/migrating-to-pypi-org.rst:26 msgid "Python 2.7.13 (``distutils`` update)" diff --git a/locales/zh_Hans/LC_MESSAGES/messages.mo b/locales/zh_Hans/LC_MESSAGES/messages.mo index 8156b7fb3c20c939b5b4edaaaa84b685f107d802..20692a04030c24143d26d767a9de6b4974e04212 100644 GIT binary patch delta 25691 zcmc(l2Y6J)8nDlyBT|))a0ne!06~$W(o|Fg5yeh6$tGFZWaI9JfNewXb%D^UR3!l; z5C}y@z4qSk6Nnqf(>U=(t?%d537l+J zYlXotv4&x^gA1A(#&`ICiIZ5vcs0>5lHhCbVrUX*5BtOQa6C+h-@$X?9lZ>r0dzqr zFBdk4%b?`j30uOy!6t?gFh0anmxzDDc=)3o?$TSwCqOB%A3O&RvE#3^IS$q&{to+l zvdxJ$C)u28bAinQ#eiXKu_N}_EU|gQ=F3nT_@2#=VLif?Hou0_fYUaAvstr`j;{-) z;SFrIu-OqdqJASD57IRT!e;PpcmaF>E`@7hU(+xWF46_1^hH{Pv*37m7vs{AbO$am zj1S?v&?3I1zhS&d_`ORFV>m1vU>G6z4O}Jh1CjqxJl;WuF%$M0Y#3?q0Q@&>dzoQu zgsm^9aTIt6eg(g~!Z4;2UpCY*M#IcuhVdILfwu^$Z47KWf`-5pNSlo5un8=Mqu`4p z82<IW$**IiHe@Q$}m17oH|k$bp17kaUNk0+z+S2E8wNq>LIxoekJkn z9O%8yFz$m7K$03iLCHUy+S|fgMg_FTPs9gAEP+j7_VqLh=0h2hwNQFi2t^m_(rr=7 z#_&DZ7S@5^LHYg*lzg=iLo3+QW-pjbcq9}Z+8wYz6vNg;ya=V@FqCOy-e4HF!0qCUn7*a-f^=I1tlhC7I_ zf16GvRiNsvQ?d{_hr!Y!}|JPDh_dUT^JY!59s0*W@L!>i$Z*qnyH2{#b_jB)!4&PDE1 z;N)DrIDHLeh<}69fd-S1znhG$QAz39tUSZ$0GGnS#P5Sm37?v*4U|b~EeVf+(!e`m zYd9N9!JDC!vj<)ROW;-TpRgnBf3IP5hqu8>I6Z*p0X$jv>7ITLMZ3-W87mr454IrO zl0>y&BJ2b&vcuzH4Z?RoY3Kw?rd; zX`0r`8(=#=B*R|t0Vov|LMiYtlreh}K5DWtfg;-Jv|hfy07dj~z{Bt)>oxTO;_oj?u3PeAA_f1>S|Us3Y@S;OUA!e57C=&GvEIOJutYAH67Mm zuXj?TpbYIB5Tj?@xIs(eDJUHqy-_!CO8`$lA{uVeA|3|o6V8C|!h4{I_!?@v5Z(zz ziRMBXqOI^QxEnTt^|xrYf})h&piIvs=!HYzdGIkP=>yN=kqX~|qFf)t1XvEwh0V7b zh7-oYJK-Ey(?skrkML&?Y2{4W#uOy{AbcHOvmIR_-32=g;|s#WcN)geu=g(Au=w3d z;sK*Co(uSJ1^hR>3rY*`cv#zk94Hdl412=IU|0AdYzyl=qGv%I>`%BWycAA=9pP$N z50*kH=PCF&d*==+%FvvIQeN$6 z^bYD#cn{&Oe?wA8WEEs07`Hx${NwTb_#C~jfk8lSu@{RfM6deT7MZ7rM?o1ZjFI5YqBMt2F!tt2rqjjfJWlk{EDvN4d^3W0eita zUe(ibAsj$>9~=U|fTI10ujz`n!&ZbJh0?$mU}N|(6rK8)9pCkJ!=SImAovli6JVfj z!&44L5<}nAHrxa25S|Td!$mfiL(%3n@LaeRO3(M&-;dbgC!zH4WhfH)0E$FHcKDPX z4*Y;e3Nqi)Yy@i&ZVRPi3tk4h!r{;fhr!)&B>W2A1pB|Ox9N+Z=)guO4Sfbm173kr z-aGId_yMGzfKh>`ArW7~rtmbZ2^+qnr%6+I9^q_wKAZ-nCk0R%x*0Bq+hIpI@LgT; zolqp04wo?ISx`Fq>wEfpgZHH&jQ{y~mXV+X6p=mpcb)MG7)SV7C}a6KlmbrMtoIMy zkmgW&+5t+>xA2=2D&gVKQeZRXpYVRH_YdKY|*{KZpXM{I$j1AAaRJOV{2E1?*Y z({MIy{RzruqI^*DpZFA;Pxxin2d)ljWqdKLP4`#uH_~k?H;iM#3cUlG5U9jB5b-da z0oQ-VT!wL<>;3y1FoW>mFSPC61|J~o`;u{_qJP2Tu>L8%<$CU)y5Ku0l(reW;3&A@ zYrR{3AGRVK_l-7Wfq{5Ls~>~4K+%D&|JDuZ37Zk_4JG|>6=wWzz;hQ7X|N7F0i_|& zL#g;v*baUJ+rlQl>h$qY3Y-t6zztCHJq#t?Q&8srN3a9@9!k0vC_*>b30^?`#UR2%ONw<=+$0#EWU$Q+9ObuFV8Y%4G9>ZYL9UWN<&V=ZuGcbM;-1Jr$sp!4kCUG zlvQkDCsPcFu>(rOzK5c0%{uE241iQ%jDaHIJ78a!4hO)su)VDRZ{rbz@*O-0+jP-N z^b?dZoYvJ;Yr+ahn~aB`Nah(@Da!dayaaw=hnsiT@$I0b>jY&;FM=+(8g7R*dr%(r z8@uty*uDs_fe-Z54R{vj6Taa>-J{o`R9FE;0;iz#tbV*!-t(YH@G95?j)Ri^L0A{g zgiYW=DCsu9fOsCpBR0PTiX@T}bj!y<(S6>vI~ zhP1xORHoO0GGv!RDfc=k+Mfm`-4y$KzRlo8%zw$SorufeAt*ig5yr!QeYHeVU;^RU zP#Uryc7-oODfkN+E5zO6iWIYuqPY?JHh(`ctkliLMf>B#ilw7o(p>u zegfVBzkxE=V=mEScN>&7A_K~zGtCaKg(ATNP=@wZDAV-=C>HY+d=Ng+UmK*rFL-Vy z;FQ{4k>gBKIN z=Q1SB_npu|xb$*e-UU~fa?%PIui&|g55tCN(a(nq2tNy@2R98hjU_Mzz7D^EU&3dG zX`BDpaIF({N0`QH;yb}CcoYtU7hb8u9w;{d19&&Q`6`pQA?Du`c*HgjzS>k#LfDQ6Iru^$GrWd3L1 ziGy!JDd0yaV_ok$Q|X`l`lm=yAZ>r<^3@Ag^ zd9-QNU?|Gq(}c^%F#o^8v*!kF;nt1S+WIi;L;MLS1%D5vVJB}i)z!*ZP-a2*aasbG z!)}D#PbPSZ;K zBz&0gXs2ns1y94p@U?VZo+FT9svF8qnOe)gfl|>7m#Hoyue@7}?mL)GeBwmCRa*}y z5&ji!gt>0LV``qIJMuIfLVV|JZFth*ql6biDd!50-s%O4@Dw7Fjya~flX>+XJ*FNn z+FyfrJ9v}~C4RlgOv*LYh3W|lSgkosgPSNvvER>3mLa~g` zL75GoKsCEyU&8h7m08978;nPKm;qmfUGCGH&F^6X;p^_#1>Fm!fFP_5w?diEyP)g^ z_d+pPhoCgz87S#qx5Mv3>0lWYiF^a=%ltoWN7Q~mi>M)#f?C?_3~LeY4W+<~q0EXw za5%gV4ug-wk+9Z-x&zlkS??c$GClW0Y3K(~8W4s7Dex;ivQB>sW#0Y<#n9AbcF5}3 z6iR$&cpdBxWoUA3&Vw?x8=*9G7n~0ZVLTj=uPe@gBC#BZ?J@H5ng7z$XQ%1}Z$W9u zNytnwDxrvM^mLu^F4&&16UtD`fRcYXlysY+G-NN7o*sr$-U%oTdl^c;H=yXmr_*Vn zNZ=`4(qs4M!tgz$S z$p?P9IJS$%+cN%?Vf<_-C@0(ncZ%>=@LAkvxYLAbs}ko4h{_lpi8q*{Y2Z`BYvDdv zhq%8(`6c15#)*Qp&ro5#D8gzrp4|h{F^_e?Qs& zd}7|f72Dzca3k&(;#yLc{IGS#RXA*$dX^@IKW``(j?C+zPKp=%c7kVSp zrU9%V)91L6gbzV>QR>DklIMHEwQweBE8$>19K^k8CzuJb>&AI}zk~0X67?Hr^PlkV zI?8B){ZZb3^S3)09KD>|%2Vaf@)@;aG*0J?S8Gx&U_!_bwl9!o7x*-;Fqn8oTpt4DJZ-VfCfz zPuTW8%s2Thhd1GZIG2u6`vlu-ur*ZwrYsT;{A~L|e2D#RC6JAK%Z{u?Ly|~SZl@b< z$A4c_|pVd!{_Y0vUYrcYaru)Es;wIyk~zrmx_84KA-S;@DrT; zY7iff`;qu|P=2d%Yj7KJEr@%_E`y-)g6+Q)e=7c+a2EUu_X+MP!ZqceL2M!L8cu#C zxJ&Wh1&6}LcKqXnf5lli`OUQBOYv{Qxp9%-g?Red-z6>+R}Ytm3lsk&?xo0g(f>CI z9EM%#!Cm%;9KyfY{?GB(#C?c+04KjaxZ%pD?{URDhx8xe=HkB{cd?yc7O=56+4acp z3F1%UI#XYukuAz*HjDW1w4G5UR$0(&;;z8eB0K<&#~sHF!O3qDoT0tyaD_jVBz(;WM>wvow_aWhrso$uLrw@D|w+|B zGwu~!YZ`GKaWCQKem87}n~VPlT#xIA{|hL;E7V_X z0F8Nz`1=UA!T&cXJ8JdY&fizG*YMeK-w;l>{R?b91E<;kO*R|Dx)k^_>8IeI2;Z^G zieMg|FZp&I?i|u~!^tnOj6Y3@Y!36G{IcNVxCA@VFT`Dd|3>2EOqc+d6PE(zHygff z`z8FS?ca?*8UHwmp15a-8@CcF@LJ%0Hu!k+=3 zQ6a3GonC?i?KnXeZUpWc3B>#^$L};R)G>R>JQ?>a?n<16dxTHF*%?+5jxTQBExyKu ziPmsWUbfrgNVEKzPAl7)=k)olNlvfN<;k`@>DG--e{PQ7<8k|nFYobwV{>@WJk}{- zrF*?-0R_*XRyctfv<(uO3JG0{LoUUx2-{E#U(-H?-1N=^J)_~;k znNFuW*>d?TUv6rq<*?foZ{=k=y-tVEN^|-Axqg?sn=g_jxbMjM!M#W51G%z2{&>qJ zb<$Fo-|{-|$#r?9A681P%bjLXe-5ptyH5F@>d2NpRJFvi#${5DEsit~St-+UW#!Oo zRqB{2{!B!v#gplnOnWaS{XG^_hr{mJ$_vqc_scZyY2YIdqSH%+8wXNxVn zM`Cf~OOt9evwS(uR9Cty)tcyHFc`w%?kC#B>BiXO<*O>fIhm?tuzke?2R5$X#OulP z$#CX4QYShxoW9`I!`BB~-qhSIgio8KMM`8oPZlk4_?$i^ZKs<;wRCcQ^a$A#LJl6U z-;v^WTHai8lSPXv-g3B+OKwJ{H6X{CGa%V7V$>r-n`yqPiDAvj@!ab5ONoB^KnhjL zpuT-B>E!Yyxcmt@9-q%e4GDfvg03$iN69=P)syB-NMk%x{q89V>0VD(f+GRVaJmy@ zI4(<0EdF$Oml}a|t-%f}&*Pn#?)KzacY9JSXZ9qQ*OQ&aNEpMNb{bJyTk4TXV(UyA ziE^CTY0m7_Db{E{dR=KwpB*U@MG2;Oa=liL+u;`>pw`lzEJyDt5xuj#9+b!9wT7f+ z(I%hY>+lnDq^3H3zC>$)*O@*bImeZ=tZ&Q9rO4DwM|OsIR7ojQtmG^Qqn=?g1m1|2 zA~71B=1h0wy8UP`I_UCvgZGSW+su`d1`G&(du{K)h{?zTLs5hVubM$O&1S=ou!c!yVv)BrtO@5y!2%p9*r#LA4tB6+QTy?R+!4VC#Kwky%N(wXM* zI&1{HzSX37=ykbu0$0*cX@rl-%k&a^=gUp;VK-+Q38>{QTiau1ct-u@S~Q>*kVqz(-_crjH6z@ zR6s_teUg}^Dqge7aKcJByJ^34u+2LL&nyi zOus+JHy|nLjA-V%l9bbtmS~Mk*OQdYmvaF@32rFv-cWjXJY;gENvOLKM#B&paz>v|CAT zr^qQOIXPZd6w5hTnTr9%!!z%$RnwX0D}KZsU#p=D)tY3Capg#}i{H+9zD^TqmQqZt zs)seHcv;>q^V}Tv88R19-%E@8Pia;o&EZu$0@Vlydm4urkn~))mF-{^6D7f<%DBqh zMGH^>HNkzXYHS=Z#7^rfm;dVA6j}QChOLjRF9VDl*;n`m6km1UXEj@-d)%x!A{T9# zRI_}+C68RtMk~A2z|6Q?c1m&BHpVxu_`<-KwE|fl#wW*( zRYQ=A9ncm&IazH16S5O>a#P$cUnVMv)tA*S_|F*|>SW|%2|5K5+`W z+iZWP+Oui1gguctDP2xZ9yfB-h#SWZ88v3YxUn}~KaBFybF)=}iPjLe&m)^eY=me6 zMJbKZ3mAP!%SHNP2(f@UtUQt^mC^SxI-cO}dH)`*Hrh&eqDGO?lEsl71G7YxEfUs^ ziL8~jvN*koqS&;_UNeig&d;mS=q9xpjLhm_>qU>&#bl%6zT#&W-B>4($-IhKbiL}@ ztA*OxOkw|Qj}=l76KY`!S&LM&B6fJp5E{$|lPRPQ0r8g8pDMefs$EN!?Uc!$65XT* z>|LrTU+lV)$U;wUl!GeIv@aRxpe(d{Ux?0nbOLOpo*h|^DWY7gt721G-r4A?J*PS+ zuny(QGL&eHXUQmTzv8vJ!!WM08E{~o)ZT%jlIW2y2`f9nNFI(?n_-nO*PHFgaVBP9 z-EvbBU7n<&bUc{6p-UqMPkmD{o?yp~J5mV`;5%Urj#bCp&uTJiGHd! zpI)P|Yq7&0t9Lzujoyn3cHh_?wrv^hnmxCq>Kx}}5scK@xe=#TpVBpnPLh_#gsX46+Gs=zkxE24Z&U{*Icn8b34)E+cW+1; zC_&6f)zLA*z8jv1tFjfUKhmfwLqWR9Nz%FQwZto3YOLa_Iu#tWsYAi*ab{dInL(V5 zoqnc{h8{c}Qm!k4 zY>>=xRbQ*J#6_WCU<-BR682#JZaC6?zMG@+HD_M`>D9<>g34p z&vm$EmR73~=Ts$79f}E3ZbDVC+J@!XYo}8cUa%z2jISS!lkzTzhN^2^K_Jd-9^Baf z91(5svh{rnex-yi>PDlw^!Ks?*t;KZRFG{Y*5^t0OI1k{NQ|UWljOWJqg1)U8`igr zXQRcEoR^T|b^85DSzIP?_UDdF*KBWfWnYXAi@9kLZ1Qk3Qvw2}_uH#ZOe^)S;TMBO5MD~nX&Iw+*Zt-HcL>+z~d1}M<;CCCWrhX2U z&V*FAgL|TM7gw7i>1tvrq}lJ%CKWH<*r`@+J(2(6ZPhF-)5FabcEZP+?@RJ|Q<>GR zWRY!t)+c?nB5ga*POW=XWfjiR2NQ`dF523y<`v_eDLxk$CDB8hEW|l3HNrl%9!gp< zEoT`DJ4x`jb*&2Ci8I?ZwcLknGh$?GsGU$Su&47C(FNPEyD!x1t0CvHMEek+1NNne zAUiJ?BbaT~NrSq?Bv#{5d~(+z2~*_HZEZDe4Hw1~+=e$hkUt z86#I2T(fZCm9o?YXQUL>7z~3mD~CkVf3Ba|G|LIw*Nt;q4(AzisLK-js8J<|vkO#L ziE{Rldjq-pPIaVaO53AP3MeO|7R~2!a{jT^XhN)Z4zHQUX>*L~g)TRh-Gy zBZ-`zvh=w=c1R;?Z=YzT4wX=aQ{7V%t=hqln=K5G4V@|kHy|hv|&{^ph zs1s*&gQ;4jj(c*Ql^DEv?|^n^nQtR@4-s6vH?C21(_pB@zG!d9Mry@2a=mUtw$Q;h z_Kt2+wb&ZU3>A0Wcg(Dj*t__{M}IRrCYF`VuQ+-%ye>bya&P(EIpKAWl&_f)a|O+N zR(G?w)`6i7o9oA<;c^dZ-)CEctl*em&ktCaC0pT5M?yyyhZf8XEqOS!cz5Nx{EF>U z%XgH9=Isp4*;~H0FuZAYd2wlZ>Bh2>dEq@<%QqL69bH&{w2=D3D`%IL9tbU45SlqX zykc*7Vd1GG3qlKvLyL<-g>x&m&ipign*H`;jhB}Ri~3d-RUBU(-gL06q-%cpj)l5@ z@>S$7P?zg+3bLd#k(~0TRf87qI}#VL%1Rbef>g71Q(4L3P~mjl;kAz^ASKOM99mjjzCJ&6d}ih5(#kC}%8#t9C|Vks z9lC#~j?9TPrEjzsD`t|JA`o17{v$e@G}^Y!k(_gpK=I`#n$;Li1F5}y?x9fO8WG*P zqKcwDr;e;i9;%+=Vuz=jbWaUPwA}FAU7>v|ibp*?rC#Ik{>2qL=2RRl64@`98GQPs zBY|~0!yA{B9bOxrJ~K3HKgvN7;YB+_a}JcRUBz&em2N9vzO(G;IvJXxBcYkwXhX&E zB^8?&gbNNt#~`%#XnEmgTBTmC82k`IJiaRY=;rXcxePv<5?)>uUN99|(jlGC8q{}q z^t~!eP8a_Vk5wY4z{|gy0mM^wXs#a4(7|mqIlO;r`Of*YR|m@%6@|7;H*~u2+hm8+M~wwR?uOGSjSZf8aQ^orF>EA!V>9G{(BcJw$h4$nELbq=)= zGZtAOeW#Ah4bNGE&Q_MLswjL2$>R^+v!Qi&mU;WY6nUw#!t1w%mmdl(UZn+HKJAbQ zXu+#9Yb47AJieaF%a?DY!0_QE<(sC47B8hh>HM6PWryk6T82IvS$1eX11T!8_A%^5 zjG3^Q2)eoYol0tH@|#*d5-ut)gg4=%E>iw&K7{Bqpy?JW4Sn+IW!X%!etf zPwxRLra0-XHFW|-hsq8wDu3h=I>=lPEuM!~hn6fNzpj%Gs#gWf7&a`tZ(6Kv)JZ~% zu{(<--`s`dD=RH6JGw%DlF7VefwUoXBtNuczKx2)V;DPwJ$><-PY$2^`wvj?hJxqgetQCSzXqoQy# z8Xb8_vf`}D&4)1A1t)u(Ee@`$V?IzTAiJjhQ^j7=Vx__n+ZA0@<;%fsp_vC|SPpGu z`jju)i%w`$!PiI*79e}6j^q#v5-!+OQFvI_EK_gEcII+<>Eh6yRiSl(oieM{d}B)` z6_m_FvqkSqrc(i>V;ouXDyJVMvsz~l68TB~a{kx)$n0fZ7B!a=(eVY9)3%l!nuA}L zCT3D?iK4}_&dZP#PHz_4JF8;L!xgi4t3BRYc1#7$8<>w@T0Y|d=2Q}`6a7ORPq1i`S4P@diQCpJ*bM+D!-n1C0gi9aN)&!Fq+Pk!TZAs|xauL{Lhfqin zJ(fSTXM5S9O$Fg5<|nsKXRY6jPLvlGu%^;yc`p)M8*P{LS8b4VuOn;R?_Q47S~pL( zfr<{EXlgF2(b%>tkvF7*ap#*a*Na?)9kiO8>uLuoRv$&QNc60^$+Rph6)T0Yl<9PM zQPlYIYQz>Yym>1vtqdLuFGARRbX~N!?C7ksHi42%Z7a%GEMP*QHj(N)-arNw(c-ge zm;JCTqZ>CeYte2|og-^1XD?*RhL$YFDo3A=upVN{bxTPXUbkB|DC{`dau*y3<*!Dc z$~iXZA&|Et{-Kqnj}6Ab7uuM+>W=u6cO>0ieK+*qcu7i(c}Y5}Y;M{T|1aN?`o_E^ zomJX@|23(Fnt5CWocWq`Fg?z6ng5eFq}VRW)jSgV5ARe?{m-YEM1S+35cF=sy} zot-m!g%-Qi|HtQ~*40=4Cl5-A(Fdj9)&5tXlrE8@&3~x8`bQ;wocW87N(F~HnJ2pF z)(xtM8;x;_`v~>2!{^{e=B{7dnXJ@XuvQjTVzk6`}tRa&rEqUKevOtNpO?v?3`KGOJPcKeq>vH5}=}+FAf^Tkr?%*%+=JmA`&UkpTZyOFTuPE9k`%3-b#CDH;+&uPT z1ta^IJ^QLHioyQ7GJn(mkH@DBv*5PAX7^xrQJt7qsDhb&&2BZElM8nDHSY`j?kP$i zNo41!PyfrfZIXM$$cacD@8x<+cIL}>a*hcdUd;Y9dY?Bvbbf z(Sum<@xyhRMQ`&$vmPzqJyqn_v7eb#{ZmyzVsEppI-athRtN5??2#5%u328bUG8J# zP`-FxwCU<5Lti4xT$vl>Y)5Ue`XZ!hrp6*^}9})2WIb zTf-ZcgjVm2-i&bDjUe?6jGV*{?ju>Wq0#iZ@`|Drp|!{K1qzoep>=!9j|4gS>GWI# zi5Nw6_APvPeeZ1?(JJ#dG60<6J1bB@I&7MUT`_QZo>GqLVRU6eDs?)uX%^q`)%Tt0pp)k(2Yzn7y z&G`t~7#qft%%Pc&*cVbI(`kyW16A8PIY;V_Gd7`;l5oKmxk`&kz}-Rga!uD4Z65{7 zD_)E;8Nu|ujSHstGh6=QBT~WYe*6QVGhdMkO8c4J&U!{F2=z0^bf{WY^*fSr#=n3t F{tt0{M}`0Z delta 10725 zcma*scYKZK-@x(f&J-eq7zvRO61zr>Se4X@t*8~$NKjj1H$ApkEslykYp-x{YNV=W zYX#BLrrO$6TT0Pijpy^duPd*ouixwW!DPGP^nd_c$89aVKCOlcr1mJa3!wBBy3n-DS!M7^Wkok<7HwI{2pb$ zM_3FCR8Xp*QVtbG!Iz4<#>U1LCw%!ruoRzunUf_s#IyVyGZ~1gikP>`pean$|iqWU8yGcbq%F% zV?a%gE%lg*^P*}0=@eSkQmQ{*#8+6Gj$Vz?b(E^l0kd%`dBGT^+TkL6gSW7&SdSB9 z!}?0Gsp^IFty+w2a1(xnf8jfr(tv&N^9J<)8cwjXp;8a1X!N!|P=&@y6((+@C zPX)#5rtgfuOFibrHgQT##ID#9vr+aB<7_3crm-FVNIn=tFusXHH+_HFN$zAUN}p$; z48E)AgSSlmuP9yh1dF3jQ*9W&PhJ;gj4UoA!75XuR!pv;Cx*aLkW&6EnH&=-qh z3d%H@W88}2Zcd|-TmLF7Ko^_VGva=|eu+chY>Z2zn;V}FFW!_%HsrVSjSW1niz2%M{w$c~=7fRm;wbm_H4yB7K8|z?Y z@;Kxk9BMcPnGXAnCyd#+iTazk3+FJBj$r+^`cD7BZsfj<$Ykt;v+xSKv3Gl=*i{wl zpwvL@kN5E$N=v!lmGjd7$0(#waS6*|^NtJ{9Ex&hYjF~Hx)nE&SL&?q>>^I4{wlsl zefKUrq;NORrapiHRfv2kS2+Z?Bd1Wo-IW@JLom?6hCfk|7I@5vn1gZ@*e_wUIL}XD&TIsh%(rw_R%f46hq15`|9HiKu2LJu2As9 z`zRYcL8%YyM{{F2tblz`4mbxRaV>`9X)KHPk>R8Q`m-Gu-UU~Y4^8A@h5kwUGhzlx z7dVq>e;KW-sTjfzJ5cT@gboYCau|qB@g3}fG6QF_y;+ypPug(f_Fwj(wo-EOxN&+b$Tu1@%IimP6?eFPw%EI14>+2g(Iz;5hsW zIku`#KRIy&$_2&@WBg!8Y=y6J8n$!{SL#Cw7qAev9-#+aZ+>^Jq=}2*K@7)e{J~gow0`6^MLBUFlTXFG9B(zsVBb2%Zdr#qKtZNm7B0kRC?}XT zRzF%7p3zV%Fl>>4?jd1OqWq+N7zStboawGzuZ~y96n(1GpvOL z=IW+uihksS@G2&wv{dVPG&A0`F@q5mF| zS6O5(C*GKjaJ9A^)Hi6^i#&RD{mH9B%A$o#Fcl&j^6`(jJ-LCf?V?!_L|S6;5)SkhK7 zg2`{;LAHxorQa2wqBQ-Y)p{&FLAl^sYv>M4z-07WODke3ereJFe^7|yS(>q)t7FBJ z4f+lbY}79#SFi~64^Zx0KH?-ViTSVw`eGxLvC<5sY1?Bk4wHH=I1K~H7j9OnIZjX7cW_*c7u-E;MAfzOXX5 zmp-nB()73Y=&lQK=`qk5nUQKZc14f9`ZK1-UfMq|6-iXcU>S)8aSj&66()BXkE5LU zit$I|ZIrJ14dr-$n|iN(dV7DA8wf&KU)&hsFomkd7-JJ-J7afaqH%k#;qt9;4-?6jzgw!1m(((8P6N9q4eD?tc*`k#z6RfJXnDAS1(mH$eAYBoNmkC%-%SRZ~|e;M^Wp{H#JjFtKS0Rl>YXbpGjSo`aeV1LcbGca)a#44{yFH6 zt4zKPdy#*E4%smDf27MSXxYWE`naP2TpBUf%=5sUM7T=W}r| z&c`5pi6b$P{u@l!O+`81AKCgspJmhja)tg^^on4V(Hm~8gi++RF&=xN9C$Mp#!Qo6 z#2w^!a2GE6R@>w|ecY$mnfiZlAa=M)E8sx~1=+F1HT~uA8K#lPf6vb)cnRf-Pye7V z^a73}&%p}VIY)n4b)X-)3kPwhnaE63QP=hU*HL~mx{b}KZ}_wRcI=o&A(j;vu@EZ? zGgoAKMPg6<7?bcJmSnq*H}#1|+~Vbg`Uxn5G4E~enDrwtgFO7M{t|l;tCBamr*B}W zaRRQD`9G7wdN!zVUpMVJ+)aK1!*S6ArTXDMl&%W?RU3&#$ZMjEm3XX!-B1SY0u00* zSPG9|C|<|X_!3*l{4e!Tzs(Lnxubr+=|S`a^O5)dT{{@%0>)w#cRJ1F+yBrlcL3!x zyaKq9Z)WKJj!uDK|h)Q%PBzuV?yQa39Kv z)pH&$Fbm~Q^1jd~3P-u~DD=Zvtck5qTFikJa4r_a{igoZ3)){c$fjZp{(|y^>-x98 z(o~ca&BOAz9*f~wlv!~Lr73^KCA7eEY(PH$AN^@~4rMxD!9DmhMx*nk_Vi2IUk><+ z3c2$luk@YN5jkK7%uoH`*ZO^6JeDAzkDuaplnaS_qq`&?<#-7ggefTNXPNc$jq8p3 z9TXa|!Ph8Po<~{s$81xSmKcRqFdd8H35>)XlmmNO+PvsV9*A-QMNqb@f)%k7MxX5}Idf?j;xDUM+%d0h;~jwss=#Xy{Z^KdSHgdtv*{rp&p z?~y;pcd)IuWq-w6h_tvvou;sx6%X(TuHaipCrsd*sQieu8|#yw%46AIu{?R1uT6dd z3$fmZUlo$cgY#MT4;AxpF8LLlkA3|u`zzTKWJar#`7QfrxV`+oQ$psyZvjg!Wkm!I z#Y~hdtyECw!|?<1A8{hK2(;`Mj^ilPHIA#0F_DVWq)YKTT!S**#ue6Gnuao%_o39E zLHYej{a`AZ@?BaE&>5w#5>PH^5|+W=QFaWZS-i0{%Cw5Y{MZ3|U~lY)hmfbQ3M*=< z(df(Tkz7D3u0|(1q{(X*w-nv2p5O`cXAFILupAE2gXs*`Ais%nz@jDeg}lZX@&G;< zWN@~?%GevDa4yP?>_tz!ighpt>tax-q!8DZF z@&I{AstRG2{mK>+uE#)6tiz35#Gb78E5qO;AApC+zlhLxKC!H2ztEH@$M3JPte8+v zPnW|e4~m;O3>Whyek6MHz~9M%#$pK%J{>Dq_J5(oRkG|SovLiv^F11+iQ`emL~oN% zM0rpxKwn&m@}%70pb$!77s|9chtkA%QM%wl70dqbx9cbmlz^(1{UtO4BgvPeJSVXW=HT_deF8^GOECr9tR2dM6Hu-^ z5#V{FyrrZJNq8xNJ<=mx{DfgvfvMINu>?Gub(jCjGFKpILAeZGM@|nbT%8tWk z<=4273I?`HA%+q^k;}ZlNXYUYkx9KQam0^yN&jrKnDSDy?rX|CtyK~+n&?9?lmD;9 zVfT@fmGX#{?HY(vPSTIMn{)P8fOXfI>F`nMl>nb=I8h5d-Hi28&qJX`FAZnb|x%S*P=)V-kGm$H0L zbjRNImh?S-Onx01fA&M}D&=0%|J|rqK*(T|MMkeI?Wh}s7f`-R%Tn6Nq)|M5?PWNB zFB3c>?2l-vd`0vouY{wC&ncfl9(?w4g};X=%lYl4X>I|3B|am*FdOHtI&BKW@Li$^ z>o*X$DBm#aWU96y3R2JKi~S$Yn^Bg>8vAd3{uYqm|76)kR3K6%VVTAb@93iaRy3Gg zKJn&ZBXh7FSduz#{198>BCJb{Amm{s)3P)npNc(M&#Qv{Wu!eO688N+hbP28#B3_> z;VzWtzAQZ`chW`s>$nvEHu-FnXTyGCpQ$^KmrOa9eG@1jCuUI2UG`C4PckdF{TrG! z@0*QyjN9LMzoNbgh@XirW_=$i6SasRi2VQBj}J%tosicFdwHL~Lv_)9d)_Mj|BB?b zOeFRb19|_j-%2mxA8arO|GkVg`9LaDDSKdTQ}-pFBwuTC+3zMXo!Cm8B4i0<{W4ut z&CRy|F}Y&^6&FYX%!&rMk-Qp_KzW;~m+g;JcHwfOE9G>eCefJuZA?K~rchpq=W#l* zkZ4PErEWORC%&P)UHZQr1>QUD7ek8n(we`=h||;`BpOjpBDN8-454l(J|*6w{18uI z?lRYuOHk2)7-d#$!e(Y&Asos3r~Q)gyV;H~f9P5r^H^MFbFUv{1gKJFgZ;YmH66I0EZpvZagl z_!ou})hNr7PJCj@0d@^<&A5}gbHo;+F5#%ipWG#c^4Z)3rwnkWhqaUtyt2C>eP)V z6yZzEloc%fH1=06DV8H5i728xAinx5oLh+&_0o+DCDqYvQ;%{KWiO($>s-~!9)U_U?CgwZh` zuE*mBc)5C}R`hZ$o_yNJ^*aj0ILBFd$uif0 zC86HVQ>*ej`>p!JwPAI#hcjy3Zr6=mY5tw}#Q)T-hd zeBzO3`l?Y@c~`q{UV5b08DpJttvtWM+c`WtJaqJ+A^laqL4C!s0}~U6sD4BGBqt9_ z8k9IH*?Ba(tkb#@lKy3?72)okY7MZQ8Q)fM-upJvS?IeoXQQj(&NtVJJNNxi+nFb) zv@<3r%yaapAZMiS))y=9 z?OS|j(x!VGXWU)BcwYx=x`(@tr*+#(kMg!6oUOWry0g43r;q!rzm?+Ujt{hAyxngX zvr_Z8$A(+iEcd(!YnGQgw7k{F%RR5MwamxexTbZ&atGG3ZdmT_b*v4Z?nd>kRIl_4 zjjhA!r(>=8?!-82qE~vi=GHy;>K4{KkMstutaI+dt*vF=?iKG^pZmI3CRjcGw+-F2 zVLmVS%28H;r<=Ab;*&n%L#smA?L!CePg?W;Z@Nz`&pRv9(qDgMMWt78SmVVQ t)+>=dbgES>eeF~$B0YPmRZbc)-FKSRK43y(a!S=vi9-_mBqxqi{{!$ieG&iw diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po index fe67dca4c..5cec4fa65 100644 --- a/locales/zh_Hans/LC_MESSAGES/messages.po +++ b/locales/zh_Hans/LC_MESSAGES/messages.po @@ -8,7 +8,7 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-08-13 22:32+0000\n" +"PO-Revision-Date: 2021-08-22 15:34+0000\n" "Last-Translator: meowmeowmeowcat \n" "Language-Team: Chinese (Simplified) \n" @@ -17,7 +17,7 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=1; plural=0;\n" -"X-Generator: Weblate 4.8-dev\n" +"X-Generator: Weblate 4.8.1-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -1621,7 +1621,7 @@ msgstr "-计算软件包的下载量" msgid "" "The following query counts the total number of downloads for the project " "\"pytest\"." -msgstr "" +msgstr "下面的查询统计了 \"pytest \" 项目的总下载次数。" #: ../source/guides/analyzing-pypi-package-downloads.rst:119 #: ../source/guides/analyzing-pypi-package-downloads.rst:140 @@ -1638,7 +1638,7 @@ msgstr "26190085" msgid "" "To only count downloads from pip, filter on the ``details.installer.name`` " "column." -msgstr "" +msgstr "要想只计算来自 pip 的下载量，可以在 ``details.installer.name`` 列上过滤。" #: ../source/guides/analyzing-pypi-package-downloads.rst:142 msgid "24334215" @@ -1652,11 +1652,11 @@ msgstr "" msgid "" "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also " "filtering by this column reduces corresponding costs." -msgstr "" +msgstr "要按月下载量分组，请使用 ``TIMESTAMP_TRUNC`` 函数。同时按这一栏过滤可以减少相应的费用。" #: ../source/guides/analyzing-pypi-package-downloads.rst:168 msgid "month" -msgstr "月" +msgstr "month" #: ../source/guides/analyzing-pypi-package-downloads.rst:170 msgid "1956741" @@ -1714,7 +1714,7 @@ msgstr "" msgid "" "Extract the Python version from the ``details.python`` column. Warning: This " "query processes over 500 GB of data." -msgstr "" +msgstr "从 ``details.python`` 列中提取 Python 版本。警告：这个查询处理超过 500GB 的数据。" #: ../source/guides/analyzing-pypi-package-downloads.rst:205 msgid "python" @@ -3093,13 +3093,13 @@ msgid "" "The process for uploading a release is the same regardless of whether or not " "the project already exists on PyPI - if it doesn't exist yet, it will be " "automatically created when the first release is uploaded." -msgstr "" +msgstr "无论项目是否已经存在于 PyPI 上，上传发布版的过程都是一样的——如果它还不存在，那么在上传第一个发布版时，它将被自动创建。" #: ../source/guides/distributing-packages-using-setuptools.rst:930 msgid "" "For the second and subsequent releases, PyPI only requires that the version " "number of the new release differ from any previous releases." -msgstr "" +msgstr "对于第二个及以后的版本，PyPI 只要求新版本的版本号与以前的任何版本不同。" #: ../source/guides/distributing-packages-using-setuptools.rst:937 msgid "" @@ -3118,6 +3118,8 @@ msgid "" "ref:`pip` is currently considering changing this by `making user installs " "the default behavior `_." msgstr "" +"根据你的平台，这可能需要 root 或管理员权限。 :ref:`pip`目前正在考虑通过`使用户安装（user " +"installs）成为默认行为`_ 来改变这一点。" #: ../source/guides/distributing-packages-using-setuptools.rst:950 msgid "" @@ -3209,25 +3211,25 @@ msgstr "" #: ../source/guides/dropping-older-python-versions.rst:53 msgid "Defining the Python version required" -msgstr "" +msgstr "定义所需的 Python 版本" #: ../source/guides/dropping-older-python-versions.rst:56 msgid "1. Download the newest version of Setuptools" -msgstr "" +msgstr "1.下载最新版本的 Setuptools" #: ../source/guides/dropping-older-python-versions.rst:58 msgid "" "Ensure that before you generate source distributions or binary " "distributions, you update Setuptools and install twine." -msgstr "" +msgstr "确保在生成源码发行版或二进制发行版之前，更新 Setuptools 并安装 twine。" #: ../source/guides/dropping-older-python-versions.rst:60 msgid "Steps:" -msgstr "" +msgstr "步骤：" #: ../source/guides/dropping-older-python-versions.rst:74 msgid "`setuptools` version should be above 24.0.0." -msgstr "" +msgstr "`setuptools` 版本应该在 24.0.0 以上。" #: ../source/guides/dropping-older-python-versions.rst:77 msgid "2. Specify the version ranges for supported Python distributions" @@ -3249,7 +3251,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:693 #: ../source/specifications/core-metadata.rst:722 msgid "Examples::" -msgstr "" +msgstr "例子：:" #: ../source/guides/dropping-older-python-versions.rst:86 msgid "" @@ -4601,7 +4603,7 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:89 #: ../source/guides/using-testpypi.rst:5 msgid "Using TestPyPI" -msgstr "" +msgstr "使用 TestPyPI" #: ../source/guides/migrating-to-pypi-org.rst:91 msgid "" @@ -4611,10 +4613,14 @@ msgid "" "``https://testpypi.python.org/pypi`` with ``https://test.pypi.org/legacy/``, " "for example:" msgstr "" +"传统的 TestPyPI (testpypi.python.org) 不再可用；请使用 `test.pypi.org `_ 代替。如果您使用 TestPyPI ，您必须更新您的 :file:`$HOME/.pypirc` 以处理 TestPyPI " +"的新位置，例如，用 ``https://test.pypi.org/legacy/`` 替换 ``https://testpypi.python.org/" +"pypi`` ：" #: ../source/guides/migrating-to-pypi-org.rst:113 msgid "Registering new user accounts" -msgstr "" +msgstr "注册新的用户账户" #: ../source/guides/migrating-to-pypi-org.rst:115 msgid "" @@ -4622,10 +4628,12 @@ msgid "" "through ``pypi.python.org`` was *switched off* on **February 20, 2018**. New " "user registrations at ``pypi.org`` are open." msgstr "" +"为了帮助减轻针对 PyPI 的垃圾邮件攻击，通过 ``pypi.python.org`` 的新用户注册已于 **2018年2月20日** " +"**关闭**。在``pypi.org``的新用户注册是开放的。" #: ../source/guides/migrating-to-pypi-org.rst:121 msgid "Browsing packages" -msgstr "" +msgstr "浏览软件包" #: ../source/guides/migrating-to-pypi-org.rst:123 msgid "" @@ -4634,6 +4642,8 @@ msgid "" "org``. The domain pypi.python.org now redirects to pypi.org, and may be " "disabled sometime in the future." msgstr "" +"虽然 ``pypi.python.org`` 仍可能用于其他 PyPA 文档的链接中使用，但浏览软件包的默认界面是 ``pypi.org`` 。" +"pypi.python.org 这个域名现在会重定向到 pypi.org ，并可能在未来某个时候被禁用。" #: ../source/guides/migrating-to-pypi-org.rst:130 msgid "Downloading packages" @@ -5535,11 +5545,11 @@ msgstr "让我们创建一个 ``.github/workflows/publish-to-test-pypi.yml`` 文 msgid "" "Start it with a meaningful name and define the event that should make GitHub " "run this workflow:" -msgstr "" +msgstr "用一个有意义的名字开始，并定义让 GitHub 运行这个工作流程的事件：" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 msgid "Defining a workflow job environment" -msgstr "" +msgstr "定义一个工作流程的工作环境" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 msgid "" @@ -5553,7 +5563,7 @@ msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 msgid "Then, add the following under the ``build-n-publish`` section:" -msgstr "" +msgstr "然后，在 ``build-n-publish`` 部分添加以下内容：" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 msgid "" @@ -7011,12 +7021,15 @@ msgid "" "pip/issues>`__ | `GitHub `__ | `PyPI `__" msgstr "" +"`文档 `__ | `Issues `__ | `GitHub `__ | `PyPI " +"`__" #: ../source/key_projects.rst:126 msgid "" "The most popular tool for installing Python packages, and the one included " "with modern versions of Python." -msgstr "" +msgstr "最流行的安装 Python 软件包的工具，也是现代版本的 Python 所包含的工具。" #: ../source/key_projects.rst:129 msgid "" @@ -7025,10 +7038,11 @@ msgid "" "incorporated into a wide range of development workflows via its command-line " "interface (CLI)." msgstr "" +"它提供了从 PyPI 和其他 Python 包索引中查找、下载和安装包的基本核心功能，并且可以通过其命令行界面 (CLI) 合并到广泛的开发工作流程中。" #: ../source/key_projects.rst:137 msgid "Pipenv" -msgstr "" +msgstr "Pipenv" #: ../source/key_projects.rst:139 msgid "" @@ -7036,6 +7050,9 @@ msgid "" "pipenv>`__ | `Issues `__ | `PyPI " "`__" msgstr "" +"`文档 `__ | `源码 `__ | " +"`Issues `__ | `PyPI `__" #: ../source/key_projects.rst:144 msgid "" @@ -7057,11 +7074,11 @@ msgstr "" #: ../source/key_projects.rst:159 msgid "Pipfile" -msgstr "" +msgstr "Pipfile" #: ../source/key_projects.rst:161 msgid "`Source `__" -msgstr "" +msgstr "`源码 `__" #: ../source/key_projects.rst:163 msgid "" @@ -7072,19 +7089,21 @@ msgstr "" #: ../source/key_projects.rst:170 msgid "pipx" -msgstr "" +msgstr "pipx" #: ../source/key_projects.rst:172 msgid "" "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" +"`文档< `__ | `GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:176 msgid "" "pipx is a tool to install and run Python command-line applications without " "causing dependency conflicts with other packages installed on the system." -msgstr "" +msgstr "pipx 是一个安装和运行 Python 命令行应用程序的工具，它不会与系统上安装的其他软件包产生依赖性冲突。" #: ../source/key_projects.rst:183 msgid "" @@ -7092,20 +7111,25 @@ msgid "" "com/pypa/python-packaging-user-guide/issues>`__ | `GitHub `__" msgstr "" +"`文档 `__ | `Issues `__ | `GitHub `__" #: ../source/key_projects.rst:187 msgid "This guide!" -msgstr "" +msgstr "本指南！" #: ../source/key_projects.rst:192 msgid "readme_renderer" -msgstr "" +msgstr "readme_renderer" #: ../source/key_projects.rst:194 msgid "" "`GitHub and docs `__ | `PyPI " "`__" msgstr "" +"`GitHub 和文档 `__ | `PyPI " +"`__" #: ../source/key_projects.rst:197 msgid "" @@ -7118,7 +7142,7 @@ msgstr "" #: ../source/key_projects.rst:208 msgid "setuptools" -msgstr "" +msgstr "setuptools" #: ../source/key_projects.rst:210 msgid "" @@ -7126,6 +7150,9 @@ msgid "" "github.com/pypa/setuptools/issues>`__ | `GitHub `__ | `PyPI `__" msgstr "" +"`文档 `__ | `Issues " +"`__ | `GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:215 msgid "" @@ -7151,6 +7178,9 @@ msgid "" "`__ | `PyPI `__" msgstr "" +"`Issues `__ | `GitHub " +"`__ | `PyPI `__" #: ../source/key_projects.rst:233 msgid "" @@ -7176,7 +7206,7 @@ msgstr "" #: ../source/key_projects.rst:253 msgid "twine" -msgstr "" +msgstr "twine" #: ../source/key_projects.rst:255 msgid "" @@ -7184,6 +7214,9 @@ msgid "" "com/pypa/twine/issues>`__ | `GitHub `__ | " "`PyPI `__" msgstr "" +"`文档 `__ | `Issues `__ | `GitHub `__ | `" +"PyPI `__" #: ../source/key_projects.rst:260 msgid "" @@ -7196,7 +7229,7 @@ msgstr "" #: ../source/key_projects.rst:270 ../source/overview.rst:415 msgid "virtualenv" -msgstr "" +msgstr "virtualenv" #: ../source/key_projects.rst:272 msgid "" @@ -7204,6 +7237,9 @@ msgid "" "com/pypa/virtualenv/issues>`__ | `GitHub `__ | `PyPI `__" msgstr "" +"`文档 `__ | `Issues `__ | `GitHub `__ " +"| `PyPI `__" #: ../source/key_projects.rst:277 msgid "" @@ -7218,13 +7254,15 @@ msgstr "" #: ../source/key_projects.rst:290 msgid "Warehouse" -msgstr "" +msgstr "Warehouse" #: ../source/key_projects.rst:292 msgid "" "`Docs `__ | `Issues `__ | `GitHub `__" msgstr "" +"`文档 `__ | `Issues `__ | `GitHub `__" #: ../source/key_projects.rst:296 msgid "" @@ -7235,7 +7273,7 @@ msgstr "" #: ../source/key_projects.rst:304 msgid "wheel" -msgstr "" +msgstr "wheel" #: ../source/key_projects.rst:306 msgid "" @@ -7243,6 +7281,9 @@ msgid "" "com/pypa/wheel/issues>`__ | `GitHub `__ | " "`PyPI `__" msgstr "" +"`文档 `__ | `Issues `__ | `GitHub `__ | `" +"PyPI `__" #: ../source/key_projects.rst:311 msgid "" @@ -7266,7 +7307,7 @@ msgstr "非 PyPA 项目" #: ../source/key_projects.rst:329 msgid "bento" -msgstr "" +msgstr "bento" #: ../source/key_projects.rst:331 msgid "" @@ -7274,6 +7315,9 @@ msgid "" "cournape/Bento/issues>`__ | `GitHub `__ | " "`PyPI `__" msgstr "" +"`文档 `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" #: ../source/key_projects.rst:336 msgid "" @@ -7284,7 +7328,7 @@ msgstr "" #: ../source/key_projects.rst:344 msgid "buildout" -msgstr "" +msgstr "buildout" #: ../source/key_projects.rst:346 msgid "" @@ -7292,6 +7336,9 @@ msgid "" "launchpad.net/zc.buildout>`__ | `PyPI `__ | `GitHub `__" msgstr "" +"`文档 `__ | `Issues `__ | `PyPI `__ | `" +"GitHub `__" #: ../source/key_projects.rst:351 msgid "" @@ -7303,11 +7350,11 @@ msgstr "" #: ../source/key_projects.rst:358 msgid "conda" -msgstr "" +msgstr "conda" #: ../source/key_projects.rst:360 msgid "`Docs `__" -msgstr "" +msgstr "`文档 `__" #: ../source/key_projects.rst:362 msgid "" @@ -7347,6 +7394,8 @@ msgid "" "`Docs `__ | `Issues `__ | `PyPI `__" msgstr "" +"`文档 `__ | `Issues `__ | `PyPI `__" #: ../source/key_projects.rst:392 msgid "" @@ -7358,13 +7407,15 @@ msgstr "" #: ../source/key_projects.rst:401 msgid "flit" -msgstr "" +msgstr "flit" #: ../source/key_projects.rst:403 msgid "" "`Docs `__ | `Issues `__ | `PyPI `__" msgstr "" +"`文档`__ | `Issues `__ | `PyPI `__" #: ../source/key_projects.rst:407 msgid "" @@ -7384,7 +7435,7 @@ msgstr "" #: ../source/key_projects.rst:422 msgid "enscons" -msgstr "" +msgstr "enscons" #: ../source/key_projects.rst:424 msgid "" @@ -7392,6 +7443,9 @@ msgid "" "bitbucket.org/dholth/enscons/issues>`__ | `PyPI `__" msgstr "" +"`源码 `__ | `Issues " +"`__ | `PyPI `__" #: ../source/key_projects.rst:428 msgid "" @@ -7407,13 +7461,15 @@ msgstr "" #: ../source/key_projects.rst:443 msgid "Hashdist" -msgstr "" +msgstr "Hashdist" #: ../source/key_projects.rst:445 msgid "" "`Docs `__ | `GitHub `__" msgstr "" +"`文档 `__ | `GitHub `__" #: ../source/key_projects.rst:448 msgid "" @@ -7428,13 +7484,15 @@ msgstr "" #: ../source/key_projects.rst:460 msgid "hatch" -msgstr "" +msgstr "hatch" #: ../source/key_projects.rst:462 msgid "" "`GitHub and Docs `__ | `PyPI `__" msgstr "" +"`GitHub 和文档 `__ | `PyPI `__" #: ../source/key_projects.rst:465 msgid "" @@ -7447,11 +7505,11 @@ msgstr "" #: ../source/key_projects.rst:475 msgid "multibuild" -msgstr "" +msgstr "multibuild" #: ../source/key_projects.rst:477 msgid "`GitHub `__" -msgstr "" +msgstr "`GitHub `__" #: ../source/key_projects.rst:479 msgid "" @@ -7462,13 +7520,15 @@ msgstr "" #: ../source/key_projects.rst:485 msgid "pex" -msgstr "" +msgstr "pex" #: ../source/key_projects.rst:487 msgid "" "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" +"`文档 `__ | `GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:491 msgid "" @@ -7481,13 +7541,15 @@ msgstr "" #: ../source/key_projects.rst:500 msgid "pip-tools" -msgstr "" +msgstr "pip-tools" #: ../source/key_projects.rst:502 msgid "" "`GitHub and Docs `__ | `PyPI " "`__" msgstr "" +"`GitHub 和文档 `__ | `PyPI `__" #: ../source/key_projects.rst:505 msgid "" @@ -7502,13 +7564,15 @@ msgstr "" #: ../source/key_projects.rst:517 msgid "piwheels" -msgstr "" +msgstr "piwheels" #: ../source/key_projects.rst:519 msgid "" "`Website `__ | `Docs `__ | `GitHub `__" msgstr "" +"`网站 `__ | `文档 `" +"__ | `GitHub `__" #: ../source/key_projects.rst:523 msgid "" @@ -7520,13 +7584,15 @@ msgstr "" #: ../source/key_projects.rst:532 msgid "poetry" -msgstr "" +msgstr "poetry" #: ../source/key_projects.rst:534 msgid "" "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" +"`文档 `__ | `GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:538 msgid "" @@ -7537,10 +7603,12 @@ msgid "" "speed users' experience of installation and dependency resolution by locally " "caching metadata about dependencies." msgstr "" +"poetry是一个命令行工具，用于处理依赖性安装和隔离，以及 Python 包的构建和打包。它使用 ``pyproject.toml`` ，并且不依赖 " +":ref:`pip`中的解析器功能，而是提供自己的依赖性解析器。它试图通过本地缓存依赖关系的元数据来加速用户的安装和依赖关系的解决。" #: ../source/key_projects.rst:548 msgid "pypiserver" -msgstr "" +msgstr "pypiserver" #: ../source/key_projects.rst:550 msgid "" @@ -7548,6 +7616,9 @@ msgid "" "`GitHub `__ | `PyPI `__" msgstr "" +"`文档 `__ | `" +"GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:554 msgid "" @@ -7558,10 +7629,13 @@ msgid "" "publicly. Organizations who use pypiserver usually download packages both " "from pypiserver and from PyPI." msgstr "" +"pypiserver 是一个简约的应用程序，作为组织内的私有 Python 包索引，实现了一个简单的 API " +"和浏览器界面。您可以使用标准的上传工具上传私有软件包，用户可以使用 :ref:`pip` 下载和安装它们，而不用公开发布。使用 pypiserver " +"的组织通常既从 pypiserver 也从 PyPI 下载软件包。" #: ../source/key_projects.rst:564 msgid "scikit-build" -msgstr "" +msgstr "scikit-build" #: ../source/key_projects.rst:566 msgid "" @@ -7569,6 +7643,9 @@ msgid "" "github.com/scikit-build/scikit-build/>`__ | `PyPI `__" msgstr "" +"`文档 `__ | `GitHub " +"`__ | `PyPI `__" #: ../source/key_projects.rst:570 msgid "" @@ -7584,13 +7661,15 @@ msgstr "" #: ../source/key_projects.rst:582 msgid "shiv" -msgstr "" +msgstr "shiv" #: ../source/key_projects.rst:584 msgid "" "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" +"`文档 `__ | `GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:588 msgid "" @@ -7635,6 +7714,9 @@ msgid "" "github.com/zestsoftware/zest.releaser/>`__ | `PyPI `__" msgstr "" +"`文档 `__ | `GitHub " +"`__ | `PyPI `__" #: ../source/key_projects.rst:623 msgid "" @@ -7650,13 +7732,15 @@ msgstr "" #: ../source/key_projects.rst:635 msgid "ensurepip" -msgstr "" +msgstr "ensurepip" #: ../source/key_projects.rst:637 msgid "" "`Docs `__ | `Issues " "`__" msgstr "" +"`文档 `__ | `Issues " +"`__" #: ../source/key_projects.rst:640 msgid "" @@ -7668,13 +7752,15 @@ msgstr "" #: ../source/key_projects.rst:649 msgid "distutils" -msgstr "" +msgstr "distutils" #: ../source/key_projects.rst:651 msgid "" "`Docs `__ | `Issues " "`__" msgstr "" +"`文档 `__ | `Issues " +"`__" #: ../source/key_projects.rst:654 msgid "" @@ -7695,13 +7781,15 @@ msgstr "" #: ../source/key_projects.rst:670 msgid "venv" -msgstr "" +msgstr "venv" #: ../source/key_projects.rst:672 msgid "" "`Docs `__ | `Issues `__" msgstr "" +"`文档 `__ | `Issues `__" #: ../source/key_projects.rst:675 msgid "" @@ -7713,11 +7801,11 @@ msgstr "" #: ../source/news.rst:2 msgid "News" -msgstr "" +msgstr "新闻" #: ../source/news.rst:5 msgid "September 2019" -msgstr "" +msgstr "2019年9月" #: ../source/news.rst:6 msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" From 92987ecd8bba0a3d169c1490455c610f74b014e9 Mon Sep 17 00:00:00 2001 From: Rafael Fontenelle Date: Sun, 29 Aug 2021 18:15:43 +0200 Subject: [PATCH 0099/1072] Translated using Weblate (Portuguese (Brazil)) Currently translated at 18.8% (429 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 18.6% (423 of 2271 strings) Co-authored-by: Rafael Fontenelle Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/pt_BR/ Translation: pypa/packaging.python.org --- locales/pt_BR/LC_MESSAGES/messages.mo | Bin 98038 -> 110880 bytes locales/pt_BR/LC_MESSAGES/messages.po | 115 +++++++++++++++++++++++--- 2 files changed, 105 insertions(+), 10 deletions(-) diff --git a/locales/pt_BR/LC_MESSAGES/messages.mo b/locales/pt_BR/LC_MESSAGES/messages.mo index 43a06d1d2f6efd71ad76e11deea9b66e78cef4b6..c2c1b4fad93572ba177fae803b0adcb80a1eba80 100644 GIT binary patch delta 19898 zcmb`N37AyH)v)WbDhMjF2!dXR9cFr9K-3YCK^9REkWE2C-|4|7sxQ2(i&7PBl=^2MspT1<)U&{WrSN%pIBYvmsr9f3 z9snPL%ivS63w<3wNU3`%&ls#!XSm-G(|>o^gYrm7KRGp(OfM>`;6d$yL zho)Q3vYcyq8k7N^VOedNhOe_S=fD%?_u=%LqvB>VAu8@DR;n9(4fcZ{!ga7~iBh9! zw*h_#|3KrN)bALfluP-RkxIQl`LQykCc*1QDfJF~6J90tqm_C9hL2L}B6#>1rK0dA znCnVr|D#!2Iyw~IKzYD1N*zb}5%>XA*JJ~DICv=Av2-l zP5qb(rM{tl%tWQO(7x;hrG7>E4Mw+~a>Hb$enKN*?upPW(x{;a283>xRX%fEoTt>6@IAN-zA>Mrg-ASfvH~%dsD81@}bLN5BPI<^_uh2;$R z9OcuYv?~sq8CAeXD9?k#+50}8(TXV%r4rPi1be}IU>y^A7RrE6^o{+P4N>=;N|9N{ z59h%;_zBzumsTltC+t>j_%QqpTO8o>r1fPL( z;zmpQ*P0dl5-#BT%44`9{rAAGG<-Cv)Ij(G90k9IGV)N$Y|YW|Jlc3cL(X&gc zSDJ03J_8rP?-`W{--0Xx%kO71I~GxW40pm)m$N0J|79!KBRHqt48UK>3@K+|Tlmsh zN-=o#>e=Wl`;&LnPvrK?Q&1t>x|@jSD~GoZ-AA}CwD42n>$g}MF7 z+-NJdK$r4%H~_u{PlO%MrvnESgx6E9x&Xa~?Js1|)HgzrjgA*9H4gTLB0~#d7gz=3 zw9CLH@Xbq%Y*egf{okU&>8q6*3djD)yjTTg25BgIeh%zF`TR>+A`l4}_Jl45p!c_+}_GegcZR{Q-7_@4*A$Kj4de=bsSqP|sh1Er3&USDHPq zfzrWpC@)?B@8*R|;Z(}wuQK%)!+R;Ofij?JSDTJ}DCJ9FC*HdeiZI`CjhXQSuqWj| zLJ{r{Aahl@?$?^7-UQ{tcS9M-y-`i$Z919~*R%Qbn z2A_w0;dgK_JZ!z`=LC3|=>L2&Gx#A5+rx*TsM`*B348`_WJU{+ywl-VH<%Tev(e13 z>(7kP_JcCx@$fA;10F^D5f}p*NYzbdV(Z{A>es_TqW_QIY+n2alo!5($eS9y$rz5` zz!}u9y;Z4`sekP@rA~lDZ$~g;E!+U#ho{2Jer|+sCyY|QZZr0Q_nj@s8s#6{q13zZ z3OI@HtF!N9>1nVXeo6U>tw!G;zKi{*Tza=szlZn1>F}~fj1>G6oXC4O{6eYOl;8R# zMhuSrl~R-82k<*7V-}x+qkgRvi=rGF@ojYz%x!Ip4&Q6e>vj*aU;H3;wmTia05?+n z>qG1>ymY&47}5=8rt==gcYwFTm*Cy78@#lMKH>FH)b?X|HvN4CZ=hVq=w+*V?x4Fv z$qd|K48nNGHmmtir1dk{5gzcE5yI{;O?ePJ1YQlLqb;yKydR3XJq&&L3~a-Pk9u6G z#gvbE!dTQRA=X!2^IN8a6sm4da@NBT|2zl3hJ$$VsoyE}H_D%~ejVYPPa7fnEBu!7 zXHW+6$ukHV?8rXJ3LFE6!IR-2SO?`h>tS1X4?G4wkRx*}na|;oaKy7l`cH+@(IWT| zOu%`tl+np4cM<#n9LIibhS$LWPJ6+erVqe}m_X?tP+jUje9@@kQ-3rA*#-MhpXt=Wn#}kk)5}oytfOA)_ei?6LoTSnkDN5|@%_Gm@}ZgdWumT2D1>1h{0saeyp`V{I>=Ec z!dN#)T?_9%M1MD@PQkORqGE7QM#u|m*avaPvkY6#>GOI!+8N#4$IjG!A}eeAIogl73d(!#;g0r#kAZ#UIGayKX1)yW4_|?7mwE?w zfG-{4sA>kX6COc%>X9rdtcKNa6_oe>0!4d1wmhK7d}t8tLH#5s_Fy4A94>_i@qM+L zjHuH!P)2wQ90(t@^>15#2;ZarpHK$yc7N0UTPQZZ2e*v~d;c*Mt(ZU9(KoAwQ2PBH zypxH%4P|A1I@D1)`OtbYV%eHt9KHn4fs=a3rGsd&;|@csTc!INF7C zLuN%1@CoW)gpF`RsiUQT?g+ERUqM;nH%2-+^+PhxmpSS>c*ZD4yI^0zE|g30$40<$ zunZ=k=<`O{9&UybV7MF3ryM@o(O0Z(a0B(d2o_ube|;<~1IH58NYie^SY!?!GA`%n zd;7|9j$#rjHr~;C+;F^+=0_&5gw($Rhrk&V9d#}*)}7#}Zz+EUIS|z+lO65ZJT=A9 zu2t<+vl4v~c^UA9P|lLIP-I~vbm6uf8QGhcpfvmtc7xx*ez5B_M;!@^;R1LHWK!xD zxS8_KlN|LJyzFF0rKq1f-E8HfGaMaYco~XpjXDKkgU7?ww3`Jzn0tAq5vH-T9rXnb z=0REN8K;^TS3w!rWe~wu4X`8Sdr*E>Q*DQGoPIl(8B%UDj{#EdKHt>OfVc?iRER>U zk_E;-Oh3($+jUNDA;X~6oA3-6TIlG&!ljGMOlDCjrvYZiZr_AB6qk z*S7xf#g0Cn0sesC4ut@>eeK%@;{}PI&?Blb=qW>ewTmff7ndv)F z_UvOQhUGgbAJ`8wDZ(=VN(bdI1ZP7rOsk;C%mz3XJ_uzizk$PGsM@U1>2NsZb6`$J zb{iS7NcX{c@MS2LZ$yn*furFwlqW(lAl+gJ7kqfBk^aNtMqNLHvI1>ujj#=b9cVWO zimZ%Fm;u!%jVa%pME}_absrU@d9gRTCVPAe6q)eg8p?O19rZXI7dSeY)FERG&N*2} zUre5aa$5GNbJTXY1D*_jxZF`s!xy0F`;9A%mUODe&QLyUCHnsvnY&h+7dD+`_Useb zo&mHw$5AWzz0n621&Mp;hQY zN9};c7jY`WPjY1LCUf1zj+%lV&Afy?;=@;7YEH3xFEi)&l|MH6e&-rTU%k#)>*(0< zolwsGip!0xTnXjswgJjY{&Jn8arA9^43vT7Udo%jy5XmeDxzYm<@4|z z%AZ5ID7<=wk@_#796sN}v*Dpvn)k1OBCNMSG0j_{2=lL?tW*;`gn^YcIBF^7DOYKG zkW+V&xsZzAUu}eN-ZhSn;b!31)SrH>u?usrLm27cuJvXh_g`=9!y}LbPyGqX@%!Bk zj=q>2y1}f#Nl>JHF)W3vp=irJu&wC-pU8*-c?}*7dv7#SJR8a}89-Uev*G)2EnEW6 z`kABejIY2L_6|`O!^|s(`oO>Zl2PU;T}Ye7NK` zGb100p09+W_m{)@bg&u94BP&knNaQryHcL9*-_)+8BmV#Yhh=&6-qz%!(#Xx+zG#j z_@Qd&7W7~A{P{b~3ok=4k?%sWe4pET=T2jAxc<J+Jy{g;t`Pm%!~Px>k8Fn;t%t~BC_ z8fbq`?8OA?kA$L1;yF#Edm%Tmr0k@A;Fawfk!u ze%PX`%s*2o53%K2$luuNx1W)3BE3pFg5Tzm={s zcgXjLUEsl_2J+XFuZ*!o0Zv^?9Nv@Rt$Ui4ikY@+!TGFwU z&m)zR7EuxbT3Js&kXb*pd}l#P;&9lHMY{PO7DDIh5yi^2fmA;63nJspP4mJQR+He}g}fN}gXE=)ZVNHc7gV z^tcr4v!a#!>Az4H)5)czi*18L$;*NC8`8<7Z*Bb&>g6dWT}*z2E^#%7(@E>7!ynPl zB6tv~n$ne|1>_Hd8(~EDBShwW(l_MeBzgK#J_44Lwvd-+wdK>~$CF+p-AYQ6c_Vgvn{Ks_sHKsI*oKc z=_=AN(w|8`Yt_dF@{>s2ssD;}WUJpoB9AvwDbER{Uy_cY!Ix5DpIP>WqbcJ%YWKS@ z{E_|rcb21UyZvAf>K57hvnU@#{x(~#h4V@0Qa@Vu|4K6FQE?J1C*5Tmo=W~!Qi3GU zW&?dMuvs0vc#pz?w$16}7m%*D4N{huTK?5iu!%HQEZQMt-jN#n45uz`I~)iT)E_|V zOzKU!EomzG=SdmzC&3=D@O({XlP&+u%0 zT?K3d3(w^?vzfY5@&iZ%No}RRD3%B^UOc`e?Jvv5(tc2spS9gBiTWu&5%m+1m>;;F zn@T5_`jL!V8%xA$X*UE&ernjVt08>EK*Z=C7JNu zWR)8ZXZ#hJ(p21wCBot2LU~0=I><;lnJ!e-dg(Kx$>q9LB$;MKQprS=vCCu=Nw+GQ zuJtk*D(EHc&&i~-k%KbXv>%x-3G#Lp>(|%Pc-++O%)D2}Qp_)u> zyg$GCX;#@UNqDt>z*LJ}FA>!l=3+S9{7Zh3%nO&m`?flC|tj zlv#KwWXX%<*uA9dMQUPxo$p4{$sj0Ub275JF0E5uCRQ1X$1?S9Om~2haW|&B)uWRE*u}PAH{$Q5eQ6zaE9>1Pijpo9C9Y0;wLw8cWDY1*HsLLo z){J$Q)=t-`s~th4MQ)pn@tZZcu#P9M!OZ`QBXlw{<7sIYLX)#6Bo7x-9hmi=M)o}2a&9K@gR zV-$vXg-y@Y$igwnNR5}MmT&7JRAog8iy0xCvAo9j$-dSjG>{n=|>;B@-*=Om1$^zREglyRF+YyvedJvV5*s5}9i_ zT#zxA;opt9T-uczn}LB2ce9G@df0LHER#&-J73;Af93_98YiCqX2;2~gs7?6Ls>;> z)ND;ySLB)9<-hPWGe}XpifA+@^Nu<{fe8XjA8&koNU5yd|8q=fy6Bze8Q zBw1BL^SW5X4@x*|FuPffW;uKGpz;$c`sRCk!65c8t3S23i@>M~);NFAqumcV)%Xr_ z{07Dxgd5NECONKXrRN4UoIqNE;z@?y>cnrntMZKw^Q&{^Ho5bH@BOyD!NEHWY`2E)s5pwZt1J ze6P^E7zTa3YcUCjjmOgL9-)K(Ory3LG&KH>Ptk`(6d9vd1F8liWpCRUBQ*kip`7T+jrre=g3hT?OZvvaqx zN6;lkS5%m;n8%{VY3Ci)?Px7H`q-?(u5n6=FcpqCJ+%m9XRA-w0%tA-gM++xLC=Na zw(5h^`d~(E%o@s!^eeN>E8(Hd$9H8m#>r>K%_QT#$E>W_xMib5WuX!IyN311F=d?e zC^99&EyA!b5ooQN>~yod;&)oFy0x;_`Wa7V?^gQ>KaKiELu!ukmu1AYoXIiv%dPR! zjcf9^>|ZW!tX3H9S+Nuazf;z!Xb;D+qa)NK@HL23@0l-hy_A+?nEwr0P>K zx%SCrOM0|E44PM^z2{hf`(G~(Qmf+uV{4tZ>a>ru>Lu7Gy_Mmx93@L^+cI%1S{fHT z5Lqe&-3pyMspY0w6l(nAjlb=D#Gad0)+v6qiRl|F%xn`XgxqvmoXTVw5`e1{=B>HJ+IigO`_d1nj=df^_(m&}D+ z{C6&3#*Z+fspncayI>v8i8+^~so9v;D{bDgHxm5eSc0A7>Qd;ZNQWQLe0>PYT>|;% zN1O=>RB()i8rR=BuuZPj@o6;*(GOg|TCVH6U%i-0B8e6mjYs+2IZ5t%d-x0pYGBX6 z7D+&e<>UGeLIaU+4)Cy>$+g_ZVi-y;pnf`m5tqw(q3_*ZGdC{Xv-sXdI}*Bg39)Dc z?{Nak#)QKqCCPYHdu`c7t(U;QdzEpY51U{~NHsoiSJ{ENJyeJlh;xO*1r#0AcET0o zqR&;kNyy<8me*h5$q~g+GlK)S4quc0kqG_$fMcCo1_1{wV}M<$W@&;fRjhDxtfxMe z)0$3LL7JByziiynET^@fHkyyMOJqvq<(5HY2!d$Wy)YWBK4m&osV|IxF1?ct>;tAIDY@o1ae zKK$yaL_-(~=FuYpkYYft4(|~4ig;;vS=K{pjm$UQPIQii&(<1Ki#lT2Be8&kMThCc z&k#R=KBP;3g&)as;3Y%u>@17f@Lj#rr!A3^hCVBu`HgQpc3QtOH_VBLq{xZF%T4z( zi2oeLJLSKO;-!)jB$A=nKwd;9$)W0EvuyY-*&NX;X0{B!@D9`D?SCJ~bJ0oLV&7pr zq)Z&XgrBI%))KDK*I2J|oJ8{uY>wt}cCiDEqu&{F@R-&CJsi&(HZ&_Ps$8yQ9x0C?VcIL=N; z<9u3TJffalt*rRiz+NidbX!T4SD8i_qe-y<$d<9V9@;Hu9aCeGWnU{?W|&JyQFJ6! zS|%&y7^FoZx<@--hws>DVmO}OkHBrZP2^vKjGSg7?z#=Gnzh4wXk*wNQs*!A_?#D8 zkwkkZ*Rr&ph;UU-qJDH`ywOQ|)bz*EkYx478u!!$0ml<8m2QXwnlPZ%9r4q+Xvc`t zplu1CGn?QZBgZB&GcR5(7fM2d47Dy9X}aCWtkK2cd^?hiCq;R^G!gbXGa*?a0)pf%H(|!HH4Sq+JH7T5 zUt|hMy>{fpJs1692GXgSp{I>I(ZszcKV*-XBCpOW#BtFAu@Ac~R*K7UnvL9NfKlt| zUa!z)Hpn(@WbFwx>OD+IJRHHbt1hE$2{``ysm#Q0G~u&7BagDQL>rkS%7%lIj&VIS z3&0Q}O^wl5b+V*NjwV@E?Ez$x+y2ttiS3u~_;Hu~%y0H9Ziz(7n5O9nB*&c`F$DpM zqToa#V>$>~@xKZ}&cd+eOTXzcOq-yVsG^QW5Jdtf|6p`n!}jQ zH~;2&x451EA~w0}qaptxHaWkgkN+Yz$#}y5ei+8tbMqs|^ltCQlHuGQ}h$y#&KnZvG*xRO!cDZ$wlh)QA$q=j# z%aG;d+2@Lc+*$f+;&U~@=yJ4iw_xfmtL$+Jn{C-604gV+jF!JG>G+YHFU)Bl;iwQHQDZgn57@_% z&719E!CF4RvM?#J$(%wdZ>4;eKVss|G_0TF^a}Ge9RE1yu!*Qj!)9^es>UBF%wOv> zI<_dbk)8MAW&-;hnr>p(KG-((Fz2^DbNjH5Y>&QC;I8uRRtG9W!Xa-7oN8}s@3`sY zKyJ^?9aj@&i<@hS_B)Ih#Hq*sR8X7K*A+SPv=GZ2nl`vC5z}USX!jjozqw zWTryT=8d9l-;Z=gbsy90sB6*GA7n+dXDx+`cDQ#yVJ}nshveS*M3@y)-;tv!Y#23%{PJ-f%>fSgT(+j^zL25bve1S;lUN z*CVk7ZO^2E-dO7vHpfaCs!YB0BBn5kRO@9iUCxzVoGF(A?NbsY5tVK2-D!i+;%uTL zh%A5Jwhpd*LPS~2RbiCdM$U6SZPQN_s-WA}X!tAmeWSEi9#TX+Vc9b6}+Tv%~GOEY#e_Y^3&XwXhBbL+#G$)r47Pc>BYHL zh=odfi9la*B?1!c{!LLyd&}mp#9ZS{)D|I<>Vs3n+w5)|O=%dvpL1wOkzqDBKjP`` z`RiZmW23bEVQ9~ofHgmbW7|fO5Hma!8@CmiYb7WW9FfbeSu7oRGR^n8l#8xt4Oljf zE+k-M%!~0ev}$mCx9%F#ZLgW~s|jkE3#~oLLfeXcr=d;$+2?!al64ZB+5IN0FQQlj z69(bqSZKXF+B<0dDa@L6K3ZI0f~NwbFOJ)Nt}Lh8c+@$!!>qV ze_|i+?;Xjt0%O`1Vsj~?xrhhRkd#q`e;w83e_%?w+nTB!|KL4Bx_H)=VjEZjtNh|X zY3rrMw{WuW;W=>&mRAVtHf+~bxc85wlc@5(+aPN zl$r%4{;lmJ1_^JCyOeZ~Dr>{(xkL0NV6QRnE6}@*K<|_P!yxa}{5P+6Zn*3m=UNl( UZ8+jw=iGl4?rpg4Txa3`16H%nYybcN delta 8922 zcmYk>37k&V|G@F@8N)0HW0z$XV;{y&3}Yv|F(%2*SQ~409zvFo3{A<_KPk&(dGLq` zSyPCzBwG>*iOBCK`F+0koc!I_>pSoBJ@-C$Irp4%@AJ%xpRzr8oYi+BB6yLo%r_!M zaY+u5VnLJ(Yc2IrB9-uMERK6{DPBT0l}XVe!|+YaX+$35cJk~c2|R$h-xHW0e@ER< z)>x5(B0eceAvYCuF$7yXlbu~rchncdahR*0;GBk8sGsB3&v(A>T;<&8{M>oa)5n>) ziu0%^aNT(aL&+aHO(}bzaOZQ*2xkG*6D;D4b;jcbTBZ&**Y#!CFL`gQ$nj-xS&;~Q zAB*9q_%?ox)!49GIgvY9M#wrqDjL1ZiWJN4-+jlPP@Oi2Kim30y{Z z@^MW>+Tjmai~90SMS`(UGuu}N(2lKjJNy|B;R@Dgwh%c--lnC!kaDd=wveZ?@k1=y zM&t(O=jY9?_%u_Z=eD(V%E zMeR!`@GSm-*>H15kVy-ku+?M1u=l5 zxPoJ-E!4D&9nWnsH+dQkLm!U9Kk#Gh|BA?Z%-z+x8^2&P8QP7Zz>0WoJo}V|I0A2D z0DJYYEmNc?SHOX%qW0dmdWpp1GSm~;i zHouD6XOd_Ry(QgHZ{1+jTk<;Q<@mCKLKtq=3fzT}cmhk}J#3DJhO+|>+!L3PkEWS2 zvA{?ULj69}TUm&9Prx|z?m6lSjK;xiHyyj<-O;qa-qQ|a8T&X8%VO(s_JgBQuV5y zvYilGPO-!20qQ*sd)=OS1U^q5iMg;YR>4-N2lSy{>4%sH*P{-pMvTQnxBzeaC}I4p;mSQO7-X}piRpJH?D=Y8=MT2s*qv*Kb5#TCd!%4+<8E2=z~;fW{b*%pYK zZ?Et=MzY;sE-&=9?MtPxI@^bHnR+6L>Gr|~VJY&_NDKL783o-i6S*k4vXIFI(-v`J z)Yp55>6Ls=hDakkgY+jU`YtDli?IXNdCzvXdDw@%NA1+UzM>mm=zV4^A>~e;c<*zL95^cY{&;1eIU}F{Ehz;`3%os6I}2ilaA&{m8@FH zNWc~!aqui01Rs&FUQO%aM{5|S>~HK^T9)I>ymf4h@tN8l+&k1O`Y(oIYxZ^qQ&8_+ zJo9K0HbNba8AwygGAx9dsKfdI>O64)wewBfVEfoY)IPNYeZwhyN+B;sZL~Y8j#!gtW#IwS4fA;MjdsL$=g=O_*%Z@7~Was`|5NAlOcu*0dtZhIm_un6^U zVm@4jI&62Kp6It&7;j-1`w7`&TR6{NMiljtJ_`E54wxPLq3&RWa~2*ZUyhe>z?b%( zzqrqC-`?33^&SsE?F*ApZ{1tYC8$@v8gt_l)E4#S-fx?#CWcUvh*_~Y24fp%66Pd- z3AJfcF%J$wy>(MiFJuwwf!AO-22i)(i+W;5P&@4p$aX%tOhJ43ZPX1PqPBoJVCxH_ z-s>pT6O2Wjn&Yr4`K5!DG2bEkV$l%w1n%N!e1bLEel*SaHTn9l?D`4x)UrC>W>F}} z3O~l+5!8G3J8Dyf@hLrU5offs9A>A!3hI^CbM-Bp?NLv>vs>TQ+21)r)$u;bRm^fO zbS`(UK|O&j&Yc)azTbHi^+2bc=bRUvS5Qyzn)9ynG5Sgev9oXNOcsBPmY}IdVI@8= z@3_6EyRZ)VNnDG$zGcEw}4J8hqyCC@N1Q9l@0Qa}By zong!UK>KS8Jo>@DGL1iH@6E5+gAY8w4XjT&Z{OKMFVHtQ;T{+5<8#zy`)~^T$v#8Y zUJ>cY_LqO=B>8-etM2T(M?K_|Uk?oXckh>#ykc*dHf7@ZW^s)V>vlg{4%=pJXuIHn6=0Z>G zOJ+Rk1l0!h0ta9io&R`AKT%KMN8UX31NTv<;G9{F z*V}L4F!I}|>w9D~vYrbVgW4ix_>Rp1q%!Knl!AkCFiym?xLJE&3KR1-Dsu4RrtZh% zIEnkx2ixW_-W$?p)RqY1XO6=-5NBdFUWN4qW+&z(zek6NN0Zxl!>$TuB~L*8cH9U% zk^jM$jP4v?nnxJ#+v_Jdl?__(cF-HY;bng~>nk%R>3^~kb$F#SmI{#XE=&uMpTnEVhj!sI|P<9)4PQQUYhB#9;L1^kXWAEZPY@#!4ii-O*}kr;`yQJZuv>V{vU zK1PqC-s{U4g-2BGiF!h>@HTV-(6$aS!#(O4PFxM`cVVZ-+WTtwL>qOgx6$P{;es`gAI+)xh@pw;S4F zIH-}m!m+4*?0sZvkaftliNCR)5aaLnCdPX+iEe778XHzdy|<~TePArkBR|m0$RSK_ zZoFSWinp-y!lDr;eQndnVKjL?XHUFJKCLg~U!P6`Q*AGvjymq=;sjiU zdhcR*GHK_lhB}qjL+zZ6QCp%t4#eG9oD(YF-^eub7YEqBbPRtczl}U#<>Wx)eK$Nh zi18n;A9&TCK#epz&g&tQmL#D*?Zyl--uwCj)GOVG+G$T?CCoC^_WG)rg**v$9!SBO zn2u3+1Vix_>V6*hDEvktjETHE-p3=DJluHC>!=aNd;Y(PQ>pJf(s*CX&*NE6u<22W9^0cN>Ql9juP=XRtz0yq#pWEKe!9C z<4M#VT*L}^A1`9`cq6>zNYDg3Odp_b|JWHe(asO~QTJZ~_14v~`lLC99#kZw-s`QX z6U0H(rn-wd!#zUnR9PljL!CKMAG;B#+ee~KwPl?Ns29>6^}wm9^T-Gc)$u=xf}Yt7 z)QRRD)GJ+z+UfkLJKl-f7Y?}kOQ`qy2I>jkMjFyv+B@HNDt!r^5p~i1)gYSF|DG;I zD5sOn!G`!UL5KF13;g|q(DD8366V&AdbZM)=dw;m*Ik0S$@?~>s}AZP7JZxY>9~AP zGnS?n`4YSE0livnfqkxCUqts4pAp)-UuT=L#5KygyhUhVVw8E$gxlmgzdXAvBY8yV z#P+Jr|KCw~jnGBMw%#LsW>?n=mITVPh@U9$Ad5DC^wO zkjP7Pq)t1WF8V0eB^&kL!ttLj+KIG3XeWGy;C0XYL29|%;#<_7{Or<-qyh0aF^*_S z%pvp%H88tG^?W``9y68-&%O)bHTNj}flrvS9V9GjC zJ-h63$#2eWc+-{3;8~)$+n-iP+Uw^>Co11?E9yC;*q{k9i8x9eB6!X77JX*uG8Nw> zhEYy*b^4&uWh8Nl7)aD+-4y(u&}AW^b547`-_t4RoLrUA9?-{@U zd;k5cXhvl__u>5H7wu=fSFto#?#%i-uB`Bo^Oo5b?=LSm-mfEN@GT-QwLGQ0C4s*c zD1U{#+t~3}8NHVX{CBBH;kZlM;HSj%e4sOKCpHoj2wkcX&Abxd8*nBOtvhEKLhx=Q zm%YsXO8Oz?PA>N?b%iAC?LM@XatBu)gc;=VL^sMKkoQW7b?dv5M^P?_`LHH-AdV5Q zkUzi@L=MU?5siqRL{TDGuYV;gdyteSbQy{-VIh|fpuCE>M?4{ZB|aby6S_2DyKeX& z;xzFQv7Tr_OeS>snwUt0vh8z3cFOmOT6+I^bCMM#x@;h_lYfD|w1TA_F_5~sc$FAT zG$q$%x-%E$BVG+1&{>Oh?^7O66mZ+Eqg4{^D^uG z5W%^6Z%D4%`yW5A{_+B`n9A3Qs+9dFN_H#auhn2cE`M~=kzoJBl$bDov)&g%(oNa` z|K7CP#$RdZ*V)p$j6UPq)DdtX4pyG5BnlrF`p?N1L(BfUwH&6Q7vvC=7+nA6*?X@QJ T|4-*;M(qt|RK~##rt|**ex(h~ diff --git a/locales/pt_BR/LC_MESSAGES/messages.po b/locales/pt_BR/LC_MESSAGES/messages.po index 73b43d178..35eade143 100644 --- a/locales/pt_BR/LC_MESSAGES/messages.po +++ b/locales/pt_BR/LC_MESSAGES/messages.po @@ -8,8 +8,8 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-08-13 22:32+0000\n" -"Last-Translator: meowmeowmeowcat \n" +"PO-Revision-Date: 2021-08-15 14:53+0000\n" +"Last-Translator: Rafael Fontenelle \n" "Language-Team: Portuguese (Brazil) \n" "Language: pt_BR\n" @@ -2722,7 +2722,7 @@ msgstr "description" #: ../source/guides/distributing-packages-using-setuptools.rst:222 msgid "Give a short and long description for your project." -msgstr "" +msgstr "Da uma descrição curta e longa para seu projeto." #: ../source/guides/distributing-packages-using-setuptools.rst:224 msgid "" @@ -2731,6 +2731,10 @@ msgid "" "``description`` in the grey banner and ``long_description`` in the section " "named \"Project Description\"." msgstr "" +"Esses valores serão exibidos no :term:`PyPI ` " +"se você publicar seu projeto. No ``pypi.org``, a interface do usuário exibe " +"``description`` no banner cinza e ``long_description`` na seção chamada " +"\"Descrição do Projeto\"." #: ../source/guides/distributing-packages-using-setuptools.rst:229 msgid "" @@ -2740,6 +2744,11 @@ msgid "" "the list of projects you maintain within your account profile (such as " "https://pypi.org/user/jaraco/)." msgstr "" +"``description`` também é exibido em listas de projetos. Por exemplo, ele é " +"visível nas páginas de resultados de pesquisa, como https://pypi.org/search/" +"?q=jupyter, nas listas da página inicial de projetos populares e novos " +"lançamentos e na lista de projetos que você mantém no perfil de sua conta (" +"como https://pypi.org/user/jaraco/)." #: ../source/guides/distributing-packages-using-setuptools.rst:235 msgid "" @@ -2752,6 +2761,14 @@ msgid "" "Markdown dialect of `Markdown `_ respectively." msgstr "" +"Um `tipo de conteúdo `_ pode ser especificado " +"com o argumento ``long_description_content_type``, que pode ser um de ``text/" +"plain``, ``text/x-rst`` ou ``text/markdown``, correspondendo a nenhuma " +"formatação, `reStructuredText (reST) `_, e o dialeto Markdown com " +"sabor do GitHub de `Markdown `" +"_ respectivamente." #: ../source/guides/distributing-packages-using-setuptools.rst:245 msgid "url" @@ -2892,16 +2909,23 @@ msgid "" "minimally needs to run. When the project is installed by :ref:`pip`, this is " "the specification that is used to install its dependencies." msgstr "" +"\"install_requires\" deve ser usado para especificar quais dependências um " +"projeto precisa minimamente para ser executado. Quando o projeto é instalado " +"pelo :ref:`pip`, esta é a especificação que é usada para instalar suas " +"dependências." #: ../source/guides/distributing-packages-using-setuptools.rst:392 msgid "" "For more on using \"install_requires\" see :ref:`install_requires vs " "Requirements files`." msgstr "" +"Para mais informações sobre como usar \"install_requires\", veja :ref:`" +"install_requires vs Arquivos de requisitos `." #: ../source/guides/distributing-packages-using-setuptools.rst:398 msgid "python_requires" -msgstr "" +msgstr "python_requires" #: ../source/guides/distributing-packages-using-setuptools.rst:400 msgid "" @@ -2910,16 +2934,23 @@ msgid "" "string will prevent :ref:`pip` from installing the project on other Python " "versions. For example, if your package is for Python 3+ only, write::" msgstr "" +"Se o seu projeto só funciona em certas versões do Python, definir o " +"argumento ``python_requires`` para a string apropriada especificadora de " +"versão da :pep:`440` impedirá :ref:`pip` de instalar o projeto em outras " +"versões do Python. Por exemplo, se seu pacote for apenas para Python 3+, " +"escreva::" #: ../source/guides/distributing-packages-using-setuptools.rst:407 msgid "" "If your package is for Python 2.6, 2.7, and all versions of Python 3 " "starting with 3.3, write::" msgstr "" +"Se o seu pacote for para Python 2.6, 2.7 e todas as versões do Python 3 " +"começando com 3.3, escreva::" #: ../source/guides/distributing-packages-using-setuptools.rst:412 msgid "And so on." -msgstr "" +msgstr "E por aí vai." #: ../source/guides/distributing-packages-using-setuptools.rst:416 msgid "" @@ -2929,6 +2960,11 @@ msgid "" "``python_requires`` argument to be recognized and the appropriate metadata " "generated." msgstr "" +"O suporte para esse recurso é relativamente recente. As distribuições de " +"código-fonte e wheels do seu projeto (veja :ref:`Empacotando seu projeto " +"`) devem ser construídas usando pelo menos a versão " +"24.2.0 do :ref:`setuptools` para que o argumento ``python_requires`` seja " +"reconhecido e os metadados apropriados gerados." #: ../source/guides/distributing-packages-using-setuptools.rst:422 msgid "" @@ -2937,10 +2973,14 @@ msgid "" "able to download & install projects on any Python version regardless of the " "projects' ``python_requires`` values." msgstr "" +"Além disso, apenas as versões 9.0.0 e superiores do :ref:`pip` reconhecem os " +"metadados de ``python_requires``. Usuários com versões anteriores do pip " +"serão capazes de baixar e instalar projetos em qualquer versão do Python, " +"independentemente dos valores de ``python_requires`` dos projetos." #: ../source/guides/distributing-packages-using-setuptools.rst:431 msgid "package_data" -msgstr "" +msgstr "package_data" #: ../source/guides/distributing-packages-using-setuptools.rst:440 msgid "" @@ -2950,6 +2990,11 @@ msgid "" "be of interest to programmers using the package. These files are called " "\"package data\"." msgstr "" +"Frequentemente, arquivos adicionais precisam ser instalados em um :term:`" +"pacote `. Esses arquivos geralmente são dados intimamente " +"relacionados à implementação do pacote ou arquivos de texto contendo " +"documentação que pode ser do interesse dos programadores que usam o pacote. " +"Esses arquivos são chamados de \"dados do pacote\"." #: ../source/guides/distributing-packages-using-setuptools.rst:445 msgid "" @@ -2957,16 +3002,22 @@ msgid "" "names that should be copied into the package. The paths are interpreted as " "relative to the directory containing the package." msgstr "" +"O valor deve ser um mapeamento do nome do pacote para uma lista de nomes de " +"caminhos relativos que devem ser copiados para o pacote. Os caminhos são " +"interpretados como relativos ao diretório que contém o pacote." #: ../source/guides/distributing-packages-using-setuptools.rst:449 msgid "" "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." msgstr "" +"Para mais informações, veja :std:doc:`Incluindo arquivos de dados " +"` da :std:doc:`documentação do setuptools " +"`." #: ../source/guides/distributing-packages-using-setuptools.rst:457 msgid "data_files" -msgstr "" +msgstr "data_files" #: ../source/guides/distributing-packages-using-setuptools.rst:463 msgid "" @@ -2976,6 +3027,12 @@ msgid "" "that. It is mostly useful if you need to install files which are used by " "other programs, which may be unaware of Python packages." msgstr "" +"Embora configurar :ref:`Dados de pacote ` seja suficiente para " +"a maioria das necessidades, em alguns casos você pode precisar colocar " +"arquivos de dados *fora* de seus :term:`pacotes `. A " +"diretiva ``data_files`` permite que você faça isso. É mais útil se você " +"precisar instalar arquivos que são usados por outros programas, que podem " +"não ter conhecimento dos pacotes Python." #: ../source/guides/distributing-packages-using-setuptools.rst:469 msgid "" @@ -2988,6 +3045,14 @@ msgid "" "``files`` is interpreted relative to the :file:`setup.py` script at the top " "of the project source distribution." msgstr "" +"Cada par ``(directory, files)`` na sequência especifica o diretório de " +"instalação e os arquivos a serem instalados nele. O ``directory`` deve ser " +"um caminho relativo (embora isso possa mudar no futuro, consulte `relatório " +"de problema #92 do wheel `_) e é " +"interpretado em relação ao prefixo de instalação (``sys.prefix`` do Python " +"para uma instalação padrão; ``site.USER_BASE`` para uma instalação do " +"usuário). Cada nome de arquivo em ``files`` é interpretado em relação ao " +"script :file:`setup.py` no topo da distribuição do código-fonte do projeto." #: ../source/guides/distributing-packages-using-setuptools.rst:479 msgid "" @@ -2995,6 +3060,9 @@ msgid "" "Files `_." msgstr "" +"Para obter mais informações, consulte a seção distutils em `Instalando " +"arquivos adicionais `_." #: ../source/guides/distributing-packages-using-setuptools.rst:484 msgid "" @@ -3003,10 +3071,14 @@ msgid "" "Alternatively, if you must use ``python setup.py``, then you need to pass " "the ``--old-and-unmanageable`` option." msgstr "" +"Ao instalar pacotes como ovo, ``data_files`` não é suportado. Então, se seu " +"projeto usa :ref:`setuptools`, você deve usar ``pip`` para instalá-lo. " +"Alternativamente, se você deve usar ``python setup.py``, então você precisa " +"passar a opção ``--old-and-unmanageable``." #: ../source/guides/distributing-packages-using-setuptools.rst:491 msgid "scripts" -msgstr "" +msgstr "scripts" #: ../source/guides/distributing-packages-using-setuptools.rst:493 msgid "" @@ -3015,10 +3087,15 @@ msgid "" "scripts to install, the recommended approach to achieve cross-platform " "compatibility is to use :ref:`console_scripts` entry points (see below)." msgstr "" +"Embora ``setup()`` tenha suporte a uma palavra-chave `scripts `_ para apontar " +"para scripts pré-fabricados para instalar, o recomendado A abordagem para " +"obter compatibilidade entre plataformas é usar pontos de entrada " +":ref:`console_scripts` (veja abaixo)." #: ../source/guides/distributing-packages-using-setuptools.rst:500 msgid "entry_points" -msgstr "" +msgstr "entry_points" #: ../source/guides/distributing-packages-using-setuptools.rst:509 msgid "" @@ -3026,6 +3103,9 @@ msgid "" "named entry points that may be defined by your project or others that you " "depend on." msgstr "" +"Use esta palavra-chave para especificar quaisquer plugins que seu projeto " +"fornece para quaisquer pontos de entrada nomeados que podem ser definidos " +"por seu projeto ou outros dos quais você depende." #: ../source/guides/distributing-packages-using-setuptools.rst:512 msgid "" @@ -3033,14 +3113,19 @@ msgid "" "setuptools.readthedocs.io/en/latest/userguide/entry_point.html#dynamic-" "discovery-of-services-and-plugins>`_ from the :ref:`setuptools` docs." msgstr "" +"Para obter mais informações, consulte a seção sobre `Comportamento de " +"Publicidade `_ da " +"documentação do :ref:`setuptools`." #: ../source/guides/distributing-packages-using-setuptools.rst:516 msgid "The most commonly used entry point is \"console_scripts\" (see below)." msgstr "" +"O ponto de entrada mais comumente usado é \"console_scripts\" (veja abaixo)." #: ../source/guides/distributing-packages-using-setuptools.rst:521 msgid "console_scripts" -msgstr "" +msgstr "console_scripts" #: ../source/guides/distributing-packages-using-setuptools.rst:531 msgid "" @@ -3051,6 +3136,12 @@ msgid "" "be generated during the install of your :term:`distribution `." msgstr "" +"Use `pontos de entrada `_ \"console_script" +"\" para registrar suas interfaces de script. Você pode então deixar o " +"conjunto de ferramentas lidar com o trabalho de transformar essas interfaces " +"em scripts reais [2]_. Os scripts serão gerados durante a instalação do seu " +":term:`distribuição `." #: ../source/guides/distributing-packages-using-setuptools.rst:538 msgid "" @@ -3058,6 +3149,10 @@ msgid "" "readthedocs.io/en/latest/setuptools.html#automatic-script-creation>`_ from " "the `setuptools docs `_." msgstr "" +"Para obter mais informações, consulte `Automatic Script Creation " +"`_ da `documentação do setuptools `_." #: ../source/guides/distributing-packages-using-setuptools.rst:545 msgid "Choosing a versioning scheme" From 225a5cf8de79b8987c6b838810817bf4087a325a Mon Sep 17 00:00:00 2001 From: Tymofii Lytvynenko Date: Sun, 29 Aug 2021 18:15:44 +0200 Subject: [PATCH 0100/1072] Translated using Weblate (Ukrainian) Currently translated at 15.8% (360 of 2271 strings) Co-authored-by: Tymofii Lytvynenko Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/uk/ Translation: pypa/packaging.python.org --- locales/uk/LC_MESSAGES/messages.mo | Bin 26470 -> 26590 bytes locales/uk/LC_MESSAGES/messages.po | 13 +++++++------ 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/locales/uk/LC_MESSAGES/messages.mo b/locales/uk/LC_MESSAGES/messages.mo index 465996b0736cb23002db7c2a8b445de3042e6c36..65b4bfafc9fe3411aa969d3c52aad8f886218ac5 100644 GIT binary patch delta 7479 zcmYk=3w+P@9>?+DY%ZJ2uwgTsVQeXdz`ey6Yo-o(lnOk-J$Hsj1>)OA{0 zo)P7^zK-2!@aI4;48r@(A?6tKNpqID(0tKcZEiAmnjfJCblg0R<;c%RxnAWv8Z>~P z&70;e)PRc3pxRzu4MS*;M$JfbY=AwmB~HYuxDhMiK1{&lSOxFc@nARFyI@_c!+}JM z!yI!WMv%XXI=&l~pTjnI%WT2HQ1Y>;C76YE@p;sf?m#`rUh}Z&erc5pIE)V0P$%Sa zw$|zabA&ko%g{a@wKwKiUTDXcp{9BbK7kuiGZb6TJ1+xuyeoz|tbZ<*d>S4`-S~)i zz&VNGRc(k4I5AIANYQi%>Ih2h~5IzPHxFW|WzTIzJV4{rgbY%~j6*ojz1_p?vEw95tXv z@P3?xtcr8O+J8koK{0A`g|PFq6m`uc)cL7qrrF)>YYs(M9mi0)g%eRzHX+t~qUosJ zIuEsGFQJaFMm_On)Mndd`4RJ!c@g!*KbSX7?Qq>UFpl{zLnVZU0IX@&M%^F=OJNdf z3Y(f8P*0p~_QP`IBak=M8Hc*=A}otb%oV8f)>ytZj``PxchR6JJ%lW$a~9cmj(efmnq49{i4vV{$wj7uVoQJmON(2p>uCE<6#n>kCmI zkPX(p7fX|Wh2`)f>V{X%TV_xr?}5Tm$78WPwnWWnI_iE|sO!6VRCo`a5!NsRwdREw zjIX1fU_17}YuEzYCwdot47GGKP*40chWjz~r~#~N?A`EP)bYJo5kJ8SdjC&T=}*HY zT!k4)-b`FUjWi(HvjS>~LQx}+LoG!L>UHXa`Xcs2EzR?&nR*A+e-CEj3DnZoY~nbz z_5P<(;Unb?z*aZ|+vB^a3;mA#&xvU2T_6jy$O|zVFJMRXZ|405bVB~;Jj_4ZORr!o zeu%8La}Bj5Va-_*z5g+)U=r#;Tgx*o?}3$R?{E1S)X(oE%NL<$YB_3(U&Bz`fSQ5* zsOug^exaRHsF}NguGY9J3#yUTMdewj6Z#`-V_Yq9_Sc` z;2G2&E5d46jt!;rqgpcmx?nO5vOVgAY}7yoqb@ieHK56Md=4^rXBp~($M7D!gc@)> z>!<;=LgneGw{}5{G&!J}6{gFy46~DILZcoDm@_chXYDspWZg3cN$rHDdZCjmL%by`r-32CSccR@WtHfp3jQBOY9j*mq3A8YNC zP#=`(c+t;s7T{>|@$I}R{u-;3$FmL^P)F>5-7!(`|6(e+G<<-1-$Qu$HRUZ(YoBRm zo4rw+ae(C`&GD##PeKiFnmN}jG*_7Gq)W$b*09I?#5`%9H?N`wbki(GEkW51o|RDp z2sb0mI;a8FH`sbR%&B>@uyD-D`I=)~Ht59pZ4t2rp_&x4Lem9);oxHtq7B!$EOu|2K z8aCz^M(3?ZUUg>&Hp1(unTqU8A56g*9O+W2L1iIo7q3Ar$u{#KYK^}_ZOTii-Fy=@ zm6h)G&PzrePcw5+OP7!3@KMxjIK`ZAy347Q;lNv{k#9k*?fd32^8)Gv@(b$81G{*e zEev&|TBv~~VL8mi+L(ija4hm>^5?JjTabzk_5SBk(SIPgs2eXgH<)|O&&+R7GjziY z>gwfDc-oJ@5wSeSEAZLV0K!lMZ;fR!3w1mXE9?Cqe6JWiB;0qHg%1dD^^& zfwcQ&dwZxn29SqY9*NrZ@z$P+x_(!45QcDn=LuDC9tPnGY=P@gOY=2q-^3*-KcOaXEtgepQA2(1#4n4vfrGV zJsjsf9E@yeC$cB~new5iflbWycK2*-O1>4F;bm-z5xu;<(i1C@59`JJYf2{2AfGW` z!7%de=22`weg!o{!Fk?puZbF90;+!|YBLT*?WOS;jI(e&7UEni+net{F7D0zYx7;8 zAry;I7YOacSBfW#MZISA{^2b_C)Ao}VF>m?J;^BCkCU(w=cV;^9DaA4QT@F0)?#Jy z&8Y9eKGgT2$feSjO6&vPS`Wq)@`q3#h}EdwdI)RbNz~N;jPe{Yu$z`EqqP#1m` z+v91}1B4Io{)kOMoj)4czmB_=N;H*H1HHdu>!GH47;5e2qXx1EWAR&z$BOyhz*?i0 zB*V{!>w#bFSqtpq6YUR?+*v*;irx%r8(kyo`FX>!`K9h1z7ngT2ifhuUOm zs0(&C2cr6qL2bU7sOvq48qhL3z6P6fe`hC^7I+=IVuK;xh{vM_;9C9+mL^|fzJ$8) zD)h&0ynS}-o`X6#tcjw>ire_ z6m}v17_}r-hIvbtgi+)f<`C4{&&1MLfO@c{!H%Ix?U9vO8n@c<_fY*maP7b$tVqK#^h1?IVg~UF zF@{j#u=AU*=KWKL&Nr!EBHB?eXD92cIF7hYY$x6!b`UBx=+lLGmAYHVKhLX`Qs2Y* z8ub)>W1K^T$~q6JllY7%DO%OXEh*308>s95|4`w_#8*0# z*S7jftWW-iXW}Q~JwhML`-r!RUkSa*DGZ@G!SAWBuuhIYc@F9$nn%4S9wzD# zb%}a}N^6d7#tK+U4ccZ`RiRWRf;sRXU&fniK5Ui{K%XAOIU4j)E-7Vc`@@n>)Kyv% zeTft$lv6}=UyTnteS-8e^Di2v64MCMze)zRu5@bpR||iPk(aeR*=~|#c^hm)TSa0G z^%t#OUyr-XyOu;r-7uc`frzsU=3o=zL)so98WArMm1*l>eahfy+Dgh(R+)pPIQBow z8(RO*$^S{rB?c0$h$xP^Ur~v)PE>t=gB-*_C3lsb)C1`kO6;ZnU!sbg_Z{^f#5E$E zxJan9ChjHlr)U~6oq9>hBJX(jgjeUtJYqiaEK!vXTW|$2fLKqc)bQ~ADyW)E^rmk+ zOe5M8zY{9I5Z#D-h!#XAqNMyxWlzb1HzE1Nj*Ktqfdy7?jKRb(;z8mCVhNGRja3$T zIPJ+-QNK>yNBvX0-;VXiSnFTS+WKkzGidxj-fIW-cdAMyd=r-w`_w>r-^2IsYgWI7 zuiw>vlzO)14RI*(7?Ek$ZD2OTD(a_yMyR4v;1?0%CUEEg$tEI*`WZ|oRK6#=6Z@4= zjuBz>sf5djjYLUlMSDqENF|H-sH6eoIUYkqSX(k4*QF*>d6M{+SiNOwtsT*&ju&pp WZ5Lk!3*7ALVo7$4T6br!4f_*#rUzpH delta 7361 zcmZA53w+P@9>?+TZnj}&Ha2YLGB#$$*xY7}VeZW>5|I!J6-}q|uh1yx(2sClm*O> z@$C$7?vd)wpO(fuH-OwStb>=ZGR7o0R|)GORW1#6N>9{rBQX|zSQQszD6TfwnZ>B< zY_;<41n2V~_yrX~G<<~>@f-83dD#r0H?>zbW6kbTw3z8B-zGVU;$ku>~_ z>UdBCe}fx=H7OTjI4(d<-4d*UZ=>#L2S(s$<`MHOYCu=59FpXfqftwjh#~avT9Q!* zZBYa0g1T^T48mJc9Sk$an}w)5nvFVs9%`)@o2$%?sPlKAuKzjex`$P!e|MCOE_BKc z_z^XrUvLNpHuTnh7^?nJ)EyL|I$VNUiZ$jY)Nwn^GV`E$%shua9eA0{b<`Htl-)qx zQCPA!<ZMHls4>CuZ6H#~kpy@N`p!!{q%>3)lmrxOm%gxtO9lV8s zxCu3do6V0=cf8*`j_T+<@&vl8sO!e1cmq!~lTqiTTRA(0`PYT>sL+)5M`qoPMfQz* z+FWbyMLmvJkO#pTs$#(_DzUp=DNHih?s!VNcj7$rS=17}j2ihm)Nv)K$LT2Qjd&cjGzrbUnd*o-J|DZ`Fx1j6 z$3#8BL?un+rSe1>y%aRTPz)7S_<#g_OpYA>Zw zU_ZJ($SS*OsF_=e74`hTr3`MehV51^v+^OVO8a+KzKr_(2Db7p6o*>VB-9i)#Td*& z?Ui1r4hJG1Qa2Jcb2HEvN#-Ro8rd3Dc^~S8?~pZeKUw)VtU|dW8z2g6nyF?7REPag zH#7vJaWra=6=HRqk2-%WVLY=T5HIOr?3tmGFD2Sb?_DEzbt^roZA=m{c zp$5DjHGmJTybJa8959cdu6sO-`Pb$-X9u3Q1AaAw*bti9aMaXBS-G~A8=!W78tOV3 zsE)EwFRpCN!H$@RGf)F9!5$duYvZj+0me`<8TAI6Wv)Q2{dUxa_oD9X5US&EQFn40 zHNXp~f!r|lNNBSLqpsf{HTC0AGwgeaOg5RhsNG(Qsd&naY3EIOCsYRmQ5}y!bvzpN zs=dd`51`-P#rywTAEd;>uf;I_qi=(bV4cW!h2A6upc$jFHv`X&e|`aj=y5{ zf$hB)N*Epw;Ps35(teG*(iGp_!FwgIM-6BvcEW?0rsuyV3p9X=?x-19f|~LzsI@OM z_nTj%Hsc8^Uofws1|G=ELj$Z}Mw#(uvY8=$9N57s^34I}2y?tS6*VBAS%g}GXUrE+ z16XFRG~YlC=xwvuEJ2?hr!q1P@fhk27S_o*X4j=-HJpH&x<^raV;*X0iZKCqp*lE) zn!$^hg4J_9b5Jjwaj5p0R$iIQ{Ik#8HY((G)Ic&j^NSaUVN0Bi8o+y~0e@_MWu8Y3 zAh-)(I*deZwldW5hs__&Af82S+SojwcVHc>NJXt}2I_)2cousgp9h!O)!Q3mQ3EQ( zbbJzL;Jc{vGP`--l1|u^@^sWpt;A+nf=PJ6M<$j`YN;LsDW?AP~3-VKY~^1-<|encwwMECY5+!%6evNREK@cQRXxZ zr+zM0#zh#6ORc;Twd>bgeHrSyd(G1rP5MGp?U!zBwIJsb7uy{@)WFyi?J#$M-6ZT>i9BL2PaXR_!>rH}`@F z)CFF~>)hE|)MNJM5N`=SMXmWhjK-s=JGqD@7&w&Yo%2eO?~A*5n|EG|Vcvk-VpHmS zB0m9Kp^r>EGHX$5eFod(PpB6}+U?$M?T;Gh2-MU+j16!*>M=Wk^|8Wm@4}6-Bjr)3 z8(4-dumpAfC1l$Wg&IHuRC_wMqJP(gOeRjpUic2`ak_>YKf|KI-;$>_~B4TJD+s0+-%K%9j+ScG|4ie0eMUEWWu zeyAmR5w&ESunz7v&!X18;u!C`wNW=#Zw&JvOr|Lnx|0^D5w^o1%ro;*yR|o}gO^ZK zzZNyc+b|pVU_God)_cP>H*ZJnl{u*EzlQ4fow3ZnI^IA<1$-Y>EV+0jLFaS3Y!DL#hK+@>5 z$hRXxi7zM*!XzvqdJ;-+6ZNV8YdS??Jds5G$9TgULnv$i{h1yomrm>@_WW7vWqyOz zL^V!&9v2h;Ar=s8iCc-UiE`p*>dvuB9}vR`{eOW{Rgf-u_}qRnQ;30Hg?j}zs%$4) zwW~n6ErnLt4}Y-+JyI#uX~QWckgrEHC%=s7O1>|~;Y-+o$RRos)ph?>Y1l%cCGjOO zop^{CL3~Oi)7}V`c6<2$7ErI$-26BB-wCa226g$U)R6p#Ue<+^A52`NtbH=K6@Q+x z##?B(+wx`j4x!KM|EJ-Lw#E5>IQSdhx8_cGkO;G~c$MJ8;7@$X+%DoD#7uvU_fdY! z^5QGYe~Uf-(sLsDHdb!t9h2qOktrg!5d~hQJC9xLz+>ba6P<~^R`=wh1+meKmc|DA z>QECzT%ffIUd7AAd&JGu$j<6v71b$sBVP$C;OoS4VlttxX$|W2l#L>k<`a5tyg*zd zB4|&;t=jj`khz)q(4f!$qr?n?UExpd&9m5_W0VdNdIc!GM#NM91op(uc$f$ve;4vP za$||vL^^dHh>k?2hWibbl_{hW{)8!Hej+l-|KQd7|F+@pb|O^s=gS~BftX0>gVCK( z>cm-XiBHIP#s}~_BA%#Ac?sT3pOMiUN~soY2fVERZ=~h#z*x&Cn4>j2xtwsCiZ#Ru zYY^Ja(ZqjMAYCU~5OKtMBAZZ}K98sIRQZjLr7(n@7_%5-D_@_QS z;bfwSNE*Y4LFAQc5Z@F3Q-PFC+Z-$;o>c{D9P#3!`{JX0t!e$0QcWU{=t?x9?j-g` zr6WW!@rDY2NuQGs`NI+YpsdTsN?MNKJzOj7so+n)SE9L9TH, 2021. # Sviatoslav Sydorenko , 2021. # meowmeowmeowcat , 2021. +# Tymofii Lytvynenko , 2021. msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-08-06 05:45+0000\n" -"Last-Translator: Sviatoslav Sydorenko \n" +"PO-Revision-Date: 2021-08-17 04:58+0000\n" +"Last-Translator: Tymofii Lytvynenko \n" "Language-Team: Ukrainian \n" "Language: uk\n" @@ -1004,7 +1005,7 @@ msgstr "" #: ../source/glossary.rst:97 msgid "Project" -msgstr "Проект" +msgstr "Проєкт" #: ../source/glossary.rst:100 msgid "" @@ -1410,7 +1411,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:82 msgid "Project name" -msgstr "Назва проекту" +msgstr "Назва проєкту" #: ../source/guides/analyzing-pypi-package-downloads.rst:82 msgid "``pipenv``, ``nose``" @@ -6641,7 +6642,7 @@ msgstr "" #: ../source/key_projects.rst:14 msgid "PyPA Projects" -msgstr "Проекти PyPA" +msgstr "Проєкти PyPA" #: ../source/key_projects.rst:19 msgid "bandersnatch" @@ -13482,7 +13483,7 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:596 msgid "" "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" -msgstr "**Вітаємо, ви запакували та розповсюдили Python-проект!** ✨ 🍰 ✨" +msgstr "**Вітаємо, ви запакували та розповсюдили Python-проєкт!** ✨ 🍰 ✨" #: ../source/tutorials/packaging-projects.rst:599 msgid "" From 3c7b93e4b2413b5fe655b705489a0aab2036e6f7 Mon Sep 17 00:00:00 2001 From: GUILHERME FERNANDES NETO Date: Sun, 29 Aug 2021 18:15:44 +0200 Subject: [PATCH 0101/1072] Translated using Weblate (Romanian) Currently translated at 1.4% (32 of 2271 strings) Added translation using Weblate (Romanian) Co-authored-by: GUILHERME FERNANDES NETO Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/ro/ Translation: pypa/packaging.python.org --- locales/ro/LC_MESSAGES/messages.mo | Bin 0 -> 845 bytes locales/ro/LC_MESSAGES/messages.po | 9257 ++++++++++++++++++++++++++++ 2 files changed, 9257 insertions(+) create mode 100644 locales/ro/LC_MESSAGES/messages.mo create mode 100644 locales/ro/LC_MESSAGES/messages.po diff --git a/locales/ro/LC_MESSAGES/messages.mo b/locales/ro/LC_MESSAGES/messages.mo new file mode 100644 index 0000000000000000000000000000000000000000..0a3a18e1afc826a59cc09f1f2c6b6b0fb416ec03 GIT binary patch literal 845 zcmcIi&2G~`5MH1c%n76-kT}eRs!`e4DF`AbDTKy>NO5C1DSzU!wWrR4vuoDt(n!7W z44il!BzOv*g>hY}9JnDy`t;4%-|qbE{JORAm62@_?h*O~m++oY+npW@PDOKXeLcip8fEvD_yctm$$Tbs-+nvP4i zF4iqX@=;_`WxQD1B~?~SjCL>Y_Q7Z;oP@z;!=1M0>}zFdG<>lxs1u8))-7@&RS%M- zFeTc-;bP3Ym%6&4V>CQaiB2h@58WeaohYx2$oW{CRq2B&&ckx>um_DhP=i4So`MHH zY?JT7*%>+aJDvx7^mS_snxGH6UaLjQ4k>qg&Kv#$6`E#*ubTnDqjs04c;c`Kn, 2021. +msgid "" +msgstr "" +"Project-Id-Version: Python Packaging User Guide\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-07-06 19:32+0800\n" +"PO-Revision-Date: 2021-08-20 01:32+0000\n" +"Last-Translator: GUILHERME FERNANDES NETO \n" +"Language-Team: Romanian \n" +"Language: ro\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=3; plural=n==1 ? 0 : (n==0 || (n%100 > 0 && n%100 < " +"20)) ? 1 : 2;\n" +"X-Generator: Weblate 4.8-dev\n" + +#: ../source/contribute.rst:5 +msgid "Contribute to this guide" +msgstr "" + +#: ../source/contribute.rst:7 +msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" +msgstr "" + +#: ../source/contribute.rst:10 +msgid "Reading the guide and giving feedback" +msgstr "" + +#: ../source/contribute.rst:11 +msgid "Reviewing new contributions" +msgstr "" + +#: ../source/contribute.rst:12 +msgid "Revising existing content" +msgstr "" + +#: ../source/contribute.rst:13 +msgid "Writing new content" +msgstr "" + +#: ../source/contribute.rst:15 +msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." +msgstr "" + +#: ../source/contribute.rst:24 +msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." +msgstr "" + +#: ../source/contribute.rst:31 +msgid "Documentation types" +msgstr "" + +#: ../source/contribute.rst:33 +msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." +msgstr "" + +#: ../source/contribute.rst:38 +#: ../source/tutorials/index.rst:2 +msgid "Tutorials" +msgstr "" + +#: ../source/contribute.rst:40 +msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." +msgstr "" + +#: ../source/contribute.rst:47 +#: ../source/guides/index.rst:2 +msgid "Guides" +msgstr "" + +#: ../source/contribute.rst:49 +msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." +msgstr "" + +#: ../source/contribute.rst:56 +#: ../source/discussions/index.rst:2 +msgid "Discussions" +msgstr "" + +#: ../source/contribute.rst:58 +msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." +msgstr "" + +#: ../source/contribute.rst:63 +msgid "Specifications" +msgstr "" + +#: ../source/contribute.rst:65 +msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." +msgstr "" + +#: ../source/contribute.rst:73 +msgid "Building the guide locally" +msgstr "" + +#: ../source/contribute.rst:75 +msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" +msgstr "" + +#: ../source/contribute.rst:79 +msgid "`Nox `_. You can install or upgrade nox using ``pip``::" +msgstr "" + +#: ../source/contribute.rst:84 +msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." +msgstr "" + +#: ../source/contribute.rst:91 +msgid "To build the guide, run the following bash command in the source folder::" +msgstr "" + +#: ../source/contribute.rst:95 +msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." +msgstr "" + +#: ../source/contribute.rst:100 +msgid "You can build the guide and serve it via an HTTP server using the following command::" +msgstr "" + +#: ../source/contribute.rst:105 +msgid "The guide will be browsable via http://localhost:8000." +msgstr "" + +#: ../source/contribute.rst:109 +msgid "Where the guide is deployed" +msgstr "" + +#: ../source/contribute.rst:111 +msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." +msgstr "" + +#: ../source/contribute.rst:117 +msgid "Style guide" +msgstr "" + +#: ../source/contribute.rst:119 +msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." +msgstr "" + +#: ../source/contribute.rst:126 +msgid "Purpose" +msgstr "" + +#: ../source/contribute.rst:128 +msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." +msgstr "" + +#: ../source/contribute.rst:133 +msgid "Scope" +msgstr "" + +#: ../source/contribute.rst:135 +msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." +msgstr "" + +#: ../source/contribute.rst:138 +msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." +msgstr "" + +#: ../source/contribute.rst:146 +msgid "Audience" +msgstr "" + +#: ../source/contribute.rst:148 +msgid "The audience of this guide is anyone who uses Python with packages." +msgstr "" + +#: ../source/contribute.rst:150 +msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." +msgstr "" + +#: ../source/contribute.rst:154 +msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." +msgstr "" + +#: ../source/contribute.rst:160 +msgid "Voice and tone" +msgstr "" + +#: ../source/contribute.rst:162 +msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." +msgstr "" + +#: ../source/contribute.rst:165 +msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." +msgstr "" + +#: ../source/contribute.rst:170 +msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." +msgstr "" + +#: ../source/contribute.rst:177 +msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." +msgstr "" + +#: ../source/contribute.rst:184 +msgid "Conventions and mechanics" +msgstr "" + +#: ../source/contribute.rst:192 +msgid "**Write to the reader**" +msgstr "" + +#: ../source/contribute.rst:187 +msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: To install it, the user runs…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: You can install it by running…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: To install it, run…" +msgstr "" + +#: ../source/contribute.rst:198 +msgid "**State assumptions**" +msgstr "" + +#: ../source/contribute.rst:195 +msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." +msgstr "" + +#: ../source/contribute.rst:203 +msgid "**Cross-reference generously**" +msgstr "" + +#: ../source/contribute.rst:201 +msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." +msgstr "" + +#: ../source/contribute.rst:213 +msgid "**Respect naming practices**" +msgstr "" + +#: ../source/contribute.rst:206 +msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: Pip uses…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: pip uses…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: …hosted on github." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: …hosted on GitHub." +msgstr "" + +#: ../source/contribute.rst:222 +msgid "**Use a gender-neutral style**" +msgstr "" + +#: ../source/contribute.rst:216 +msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: A maintainer uploads the file. Then he…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then they…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then the maintainer…" +msgstr "" + +#: ../source/contribute.rst:234 +msgid "**Headings**" +msgstr "" + +#: ../source/contribute.rst:225 +msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." +msgstr "" + +#: ../source/contribute.rst:230 +msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: Things You Should Know About Python" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: Things you should know about Python" +msgstr "" + +#: ../source/contribute.rst:237 +msgid "**Numbers**" +msgstr "" + +#: ../source/contribute.rst:237 +msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:4 +msgid "Deploying Python applications" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Page Status" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:6 +#: ../source/guides/index-mirrors-and-caches.rst:7 +#: ../source/guides/installing-using-linux-tools.rst:7 +#: ../source/guides/packaging-binary-extensions.rst:7 +#: ../source/guides/supporting-multiple-python-versions.rst:7 +#: ../source/guides/supporting-windows-using-appveyor.rst:5 +msgid "Incomplete" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Last Reviewed" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:7 +msgid "2014-11-11" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:11 +#: ../source/discussions/install-requires-vs-requirements.rst:9 +#: ../source/guides/analyzing-pypi-package-downloads.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:22 +#: ../source/guides/index-mirrors-and-caches.rst:12 +#: ../source/guides/installing-scientific-packages.rst:9 +#: ../source/guides/packaging-binary-extensions.rst:17 +#: ../source/guides/supporting-multiple-python-versions.rst:12 +#: ../source/guides/supporting-windows-using-appveyor.rst:15 +#: ../source/overview.rst:23 +#: ../source/specifications/core-metadata.rst:38 +#: ../source/specifications/direct-url.rst:14 +#: ../source/tutorials/installing-packages.rst:23 +msgid "Contents" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:14 +msgid "Overview" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:18 +msgid "Supporting multiple hardware platforms" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:40 +msgid "OS packaging & installers" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:52 +msgid "Windows" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:61 +msgid "Pynsist" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:63 +msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:70 +msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:74 +msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:80 +msgid "Application bundles" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:91 +msgid "Configuration management" +msgstr "" + +#: ../source/discussions/index.rst:4 +msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:5 +msgid "install_requires vs requirements files" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:382 +msgid "install_requires" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:14 +msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:19 +msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:29 +msgid "Additionally, it's best practice to indicate any known lower or upper bounds." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:31 +msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:41 +msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:51 +msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:56 +msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:64 +#: ../source/tutorials/installing-packages.rst:460 +msgid "Requirements files" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:66 +msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:69 +msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:73 +msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:78 +msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:84 +msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:90 +msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:6 +msgid "pip vs easy_install" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:9 +msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:14 +msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:22 +msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**pip**" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**easy_install**" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +msgid "Installs from :term:`Wheels `" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Yes" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:30 +#: ../source/discussions/pip-vs-easy-install.rst:32 +#: ../source/discussions/pip-vs-easy-install.rst:35 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:51 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "No" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Uninstall Packages" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Yes (``python -m pip uninstall``)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Dependency Overrides" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Yes (:ref:`Requirements Files `)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "List Installed Packages" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:38 +msgid ":pep:`438` Support" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Installation format" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "'Flat' packages with :file:`egg-info` metadata." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Encapsulated Egg format" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:44 +msgid "sys.path modification" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:48 +msgid "Installs from :term:`Eggs `" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "`pylauncher support`_" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "Yes [1]_" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:54 +msgid ":ref:`Multi-version Installs`" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Exclude scripts during install" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "per project index" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Only in virtualenv" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Yes, via setup.cfg" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:68 +msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:5 +msgid "Wheel vs Egg" +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:7 +msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:11 +msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:14 +msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:17 +msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:20 +msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:22 +msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:26 +msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:31 +msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:34 +msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:38 +msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:41 +msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:47 +msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." +msgstr "" + +#: ../source/glossary.rst:3 +msgid "Glossary" +msgstr "" + +#: ../source/glossary.rst:8 +msgid "Binary Distribution" +msgstr "" + +#: ../source/glossary.rst:11 +msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." +msgstr "" + +#: ../source/glossary.rst:14 +msgid "Built Distribution" +msgstr "" + +#: ../source/glossary.rst:17 +msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." +msgstr "" + +#: ../source/glossary.rst:26 +msgid "Distribution Package" +msgstr "" + +#: ../source/glossary.rst:29 +msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." +msgstr "" + +#: ../source/glossary.rst:34 +msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." +msgstr "" + +#: ../source/glossary.rst:41 +msgid "Egg" +msgstr "" + +#: ../source/glossary.rst:44 +msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" +msgstr "" + +#: ../source/glossary.rst:49 +msgid "Extension Module" +msgstr "" + +#: ../source/glossary.rst:52 +msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." +msgstr "" + +#: ../source/glossary.rst:59 +msgid "Known Good Set (KGS)" +msgstr "" + +#: ../source/glossary.rst:62 +msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." +msgstr "" + +#: ../source/glossary.rst:68 +msgid "Import Package" +msgstr "" + +#: ../source/glossary.rst:71 +msgid "A Python module which can contain other modules or recursively, other packages." +msgstr "" + +#: ../source/glossary.rst:74 +msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." +msgstr "" + +#: ../source/glossary.rst:78 +msgid "Module" +msgstr "" + +#: ../source/glossary.rst:81 +msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." +msgstr "" + +#: ../source/glossary.rst:84 +msgid "Package Index" +msgstr "" + +#: ../source/glossary.rst:87 +msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." +msgstr "" + +#: ../source/glossary.rst:90 +msgid "Per Project Index" +msgstr "Pe Indexul Proiectului" + +#: ../source/glossary.rst:93 +msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." +msgstr "" + +#: ../source/glossary.rst:97 +msgid "Project" +msgstr "" + +#: ../source/glossary.rst:100 +msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." +msgstr "" + +#: ../source/glossary.rst:104 +msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." +msgstr "" + +#: ../source/glossary.rst:110 +msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." +msgstr "" + +#: ../source/glossary.rst:115 +msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." +msgstr "" + +#: ../source/glossary.rst:121 +msgid "Pure Module" +msgstr "Modul Pur" + +#: ../source/glossary.rst:124 +msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." +msgstr "" + +#: ../source/glossary.rst:127 +msgid "Python Packaging Authority (PyPA)" +msgstr "" + +#: ../source/glossary.rst:130 +msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." +msgstr "" + +#: ../source/glossary.rst:139 +msgid "Python Package Index (PyPI)" +msgstr "" + +#: ../source/glossary.rst:142 +msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." +msgstr "" + +#: ../source/glossary.rst:145 +msgid "pypi.org" +msgstr "" + +#: ../source/glossary.rst:148 +msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." +msgstr "" + +#: ../source/glossary.rst:152 +msgid "pyproject.toml" +msgstr "" + +#: ../source/glossary.rst:155 +msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." +msgstr "" + +#: ../source/glossary.rst:157 +msgid "Release" +msgstr "" + +#: ../source/glossary.rst:160 +msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." +msgstr "" + +#: ../source/glossary.rst:163 +msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." +msgstr "" + +#: ../source/glossary.rst:168 +msgid "Requirement" +msgstr "" + +#: ../source/glossary.rst:171 +msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." +msgstr "" + +#: ../source/glossary.rst:177 +msgid "Requirement Specifier" +msgstr "Specificator Cerință" + +#: ../source/glossary.rst:180 +msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" +msgstr "" + +#: ../source/glossary.rst:187 +msgid "Requirements File" +msgstr "" + +#: ../source/glossary.rst:190 +msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." +msgstr "" + +#: ../source/glossary.rst:194 +#: ../source/guides/distributing-packages-using-setuptools.rst:56 +msgid "setup.py" +msgstr "" + +#: ../source/glossary.rst:195 +#: ../source/guides/distributing-packages-using-setuptools.rst:77 +msgid "setup.cfg" +msgstr "" + +#: ../source/glossary.rst:198 +msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." +msgstr "" + +#: ../source/glossary.rst:201 +msgid "Source Archive" +msgstr "" + +#: ../source/glossary.rst:204 +msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:208 +msgid "Source Distribution (or \"sdist\")" +msgstr "" + +#: ../source/glossary.rst:211 +msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:216 +msgid "System Package" +msgstr "" + +#: ../source/glossary.rst:219 +msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." +msgstr "" + +#: ../source/glossary.rst:222 +msgid "Version Specifier" +msgstr "" + +#: ../source/glossary.rst:225 +msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." +msgstr "" + +#: ../source/glossary.rst:231 +msgid "Virtual Environment" +msgstr "" + +#: ../source/glossary.rst:234 +msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/glossary.rst:238 +msgid "Wheel" +msgstr "" + +#: ../source/glossary.rst:241 +msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." +msgstr "" + +#: ../source/glossary.rst:244 +msgid "Working Set" +msgstr "" + +#: ../source/glossary.rst:247 +msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:3 +msgid "Analyzing PyPI package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:5 +msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:15 +#: ../source/guides/supporting-windows-using-appveyor.rst:18 +msgid "Background" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:17 +msgid "PyPI does not display download statistics for a number of reasons: [#]_" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:19 +msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:24 +msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:27 +msgid "``pip``'s download cache (lowers download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:28 +msgid "Internal or unofficial mirrors (can both raise or lower download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:29 +msgid "Packages not hosted on PyPI (for comparisons sake)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:30 +msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:32 +msgid "Known historical data quality issues (lowers download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:34 +msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:38 +msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:43 +msgid "Public dataset" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:45 +msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:50 +msgid "Getting set up" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:52 +msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:58 +msgid "Navigate to the `BigQuery web UI`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:59 +msgid "Create a new project." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:60 +msgid "Enable the `BigQuery API `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:63 +msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:69 +msgid "Data schema" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:71 +msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +msgid "Column" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/guides/using-manifest-in.rst:67 +#: ../source/specifications/core-metadata.rst:185 +msgid "Description" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/specifications/direct-url.rst:226 +msgid "Examples" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "timestamp" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "Date and time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "``2020-03-09 00:33:03 UTC``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "file.project" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "Project name" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "``pipenv``, ``nose``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "file.version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "Package version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "``0.1.6``, ``1.4.2``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "details.installer.name" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "Installer" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "pip, `bandersnatch`_" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "details.python" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "Python version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "``2.7.12``, ``3.6.4``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:93 +msgid "Useful queries" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:95 +msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:97 +msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:102 +msgid "Counting package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:104 +msgid "The following query counts the total number of downloads for the project \"pytest\"." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:119 +#: ../source/guides/analyzing-pypi-package-downloads.rst:140 +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "num_downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:121 +msgid "26190085" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:124 +msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:142 +msgid "24334215" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:146 +msgid "Package downloads over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:148 +msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +msgid "month" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "1956741" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "2018-01-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2344692" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2017-12-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "1730398" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "2017-11-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2047310" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2017-10-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "1744443" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "2017-09-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "1916952" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "2017-08-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:184 +msgid "Python versions over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:186 +msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "python" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "3.7" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "18051328726" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "3.6" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "9635067203" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "3.8" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "7781904681" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "2.7" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "6381252241" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "null" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "2026630299" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "3.5" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "1894153540" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:221 +msgid "Caveats" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:223 +msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:231 +msgid "Additional tools" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:233 +msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:237 +msgid "``google-cloud-bigquery``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:239 +msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:267 +msgid "``pypinfo``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:269 +msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:273 +msgid "Install `pypinfo`_ using pip." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:279 +msgid "Usage:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:295 +msgid "``pandas-gbq``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:297 +msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:301 +#: ../source/specifications/binary-distribution-format.rst:459 +msgid "References" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:303 +msgid "`PyPI Download Counts deprecation email `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:304 +msgid "`PyPI BigQuery dataset announcement email `__" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:3 +msgid "Creating and discovering plugins" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:5 +msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:10 +msgid "There are three major approaches to doing automatic plugin discovery:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:12 +msgid "`Using naming convention`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:13 +msgid "`Using namespace packages`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:14 +msgid "`Using package metadata`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:18 +msgid "Using naming convention" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:20 +msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:38 +msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:48 +msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:59 +msgid "Using namespace packages" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:61 +msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:89 +msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:101 +msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:115 +msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:121 +msgid "Using package metadata" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:123 +msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:128 +msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:139 +msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:154 +msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:163 +msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:166 +msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:170 +msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:5 +msgid "Packaging and distributing projects" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:7 +msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:11 +msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:15 +msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:25 +msgid "Requirements for packaging and distributing" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:26 +msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:29 +msgid "Install \"twine\" [1]_:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:43 +msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:49 +msgid "Configuring your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:53 +msgid "Initial files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:58 +msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:63 +msgid ":file:`setup.py` serves two primary functions:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:65 +msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:71 +msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:79 +msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:86 +msgid "README.rst / README.md" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:88 +msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:95 +msgid "For an example, see `README.md `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:99 +msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:108 +msgid "MANIFEST.in" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:110 +msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:115 +msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:119 +msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:122 +msgid "LICENSE.txt" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:124 +msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:130 +msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:135 +msgid "" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:137 +msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:141 +msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:149 +msgid "setup() args" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:151 +msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:155 +msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:164 +msgid "name" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:170 +msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:174 +msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:176 +msgid "Start & end with an ASCII letter or digit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:178 +msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:190 +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "version" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:196 +msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:200 +msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:203 +msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:206 +msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:214 +msgid "description" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:222 +msgid "Give a short and long description for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:224 +msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:229 +msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:235 +msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:245 +msgid "url" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:252 +msgid "Give a homepage URL for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:256 +msgid "author" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:263 +msgid "Provide details about the author." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:267 +msgid "license" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:273 +msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:279 +msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:287 +msgid "classifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:316 +msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:319 +msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:327 +msgid "keywords" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:333 +msgid "List keywords that describe your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:337 +msgid "project_urls" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:349 +msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:355 +msgid "packages" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:361 +msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:370 +msgid "py_modules" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:376 +msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:388 +msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:392 +msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:398 +msgid "python_requires" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:400 +msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:407 +msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:412 +msgid "And so on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:416 +msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:422 +msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:431 +msgid "package_data" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:440 +msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:445 +msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:449 +msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:457 +msgid "data_files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:463 +msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:469 +msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:479 +msgid "For more information see the distutils section on `Installing Additional Files `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:484 +msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:491 +msgid "scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:493 +msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:500 +msgid "entry_points" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:509 +msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:512 +msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:516 +msgid "The most commonly used entry point is \"console_scripts\" (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:521 +msgid "console_scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:531 +msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:538 +msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:545 +msgid "Choosing a versioning scheme" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:548 +msgid "Standards compliance for interoperability" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:550 +msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:556 +msgid "Here are some examples of compliant version numbers::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:567 +msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:573 +msgid "Scheme choices" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:576 +msgid "Semantic versioning (preferred)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:578 +msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:582 +msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:585 +msgid "MAJOR version when they make incompatible API changes," +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:586 +msgid "MINOR version when they add functionality in a backwards-compatible manner, and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:587 +msgid "MAINTENANCE version when they make backwards-compatible bug fixes." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:589 +msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:594 +msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:598 +msgid "Date based versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:600 +msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:604 +msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:607 +msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:611 +msgid "Serial versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:613 +msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:616 +msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:621 +msgid "Hybrid schemes" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:623 +msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:629 +msgid "Pre-release versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:631 +msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:634 +msgid "zero or more dev releases (denoted with a \".devN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:635 +msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:636 +msgid "zero or more beta releases (denoted with a \".bN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:637 +msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:639 +msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:644 +msgid "Local version identifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:646 +msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:653 +msgid "A local version identifier takes the form ``+``. For example::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:661 +msgid "Working in \"development mode\"" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:663 +msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:667 +msgid "Assuming you're in the root of your project directory, then run:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:674 +msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:680 +msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:688 +msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:692 +msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:697 +msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:701 +msgid "Lastly, if you don't want to install any dependencies at all, you can run::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:706 +msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:713 +msgid "Packaging your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:715 +msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:720 +msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:737 +msgid "Source distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:739 +msgid "Minimally, you should create a :term:`Source Distribution `:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:755 +msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:763 +msgid "Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:765 +msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:770 +msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:773 +msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:776 +msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:785 +msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:792 +msgid "Pure Python Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:794 +msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:797 +#: ../source/guides/distributing-packages-using-setuptools.rst:826 +msgid "To build the wheel:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:811 +msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:815 +msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:821 +msgid "Platform Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:823 +msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:841 +msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:847 +msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:855 +msgid "Uploading your Project to PyPI" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:857 +msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:861 +msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:866 +msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:871 +msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:877 +msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:888 +msgid "Create an account" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:890 +msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:894 +msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:897 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:901 +msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:904 +msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:913 +msgid "**Be aware that this stores your token in plaintext.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:915 +#: ../source/guides/migrating-to-pypi-org.rst:70 +#: ../source/guides/migrating-to-pypi-org.rst:109 +#: ../source/guides/using-testpypi.rst:83 +msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:921 +msgid "Upload your distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:923 +msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:926 +msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:930 +msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:937 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:944 +#: ../source/tutorials/installing-packages.rst:663 +msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:950 +msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:5 +msgid "Dropping support for older Python versions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:7 +msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:9 +msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:12 +msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:14 +msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:17 +msgid "Requirements" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:19 +msgid "This workflow requires that:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:21 +msgid "The publisher is using the latest version of :ref:`setuptools`," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:22 +msgid "The latest version of :ref:`twine` is used to upload the package," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:23 +msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:26 +msgid "Dealing with the universal wheels" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:28 +msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:36 +msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:48 +msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:53 +msgid "Defining the Python version required" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:56 +msgid "1. Download the newest version of Setuptools" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:58 +msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:60 +msgid "Steps:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:74 +msgid "`setuptools` version should be above 24.0.0." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:77 +msgid "2. Specify the version ranges for supported Python distributions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:79 +msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:81 +#: ../source/specifications/core-metadata.rst:139 +#: ../source/specifications/core-metadata.rst:463 +#: ../source/specifications/core-metadata.rst:487 +#: ../source/specifications/core-metadata.rst:527 +#: ../source/specifications/core-metadata.rst:550 +#: ../source/specifications/core-metadata.rst:583 +#: ../source/specifications/core-metadata.rst:693 +#: ../source/specifications/core-metadata.rst:722 +msgid "Examples::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:86 +msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:101 +msgid "3. Validating the Metadata before publishing" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:103 +msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:105 +msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:108 +msgid "You can see the contents of the generated file like this::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:112 +msgid "Validate that the following is in place, before publishing the package:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:114 +msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:115 +msgid "The Requires-Python field is set and matches your specification in setup.py." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:118 +msgid "4. Using Twine to publish" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:120 +msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:122 +msgid "Make sure you are using the newest version of Twine, at least 1.9." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:125 +msgid "Dropping a Python release" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:127 +msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:129 +msgid "It must be done in this order for the automated fallback to work." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:131 +msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:133 +msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:5 +msgid "Hosting your own simple repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:8 +msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:13 +msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:29 +msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:35 +msgid "\"Manual\" repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:37 +msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:51 +msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:58 +msgid "For complete documentation of the simple repository protocol, see :pep:`503`." +msgstr "" + +#: ../source/guides/index.rst:8 +#: ../source/guides/index.rst:8 +msgid "Installing Packages:" +msgstr "" + +#: ../source/guides/index.rst:20 +#: ../source/guides/index.rst:20 +msgid "Building and Publishing Projects:" +msgstr "" + +#: ../source/guides/index.rst:38 +#: ../source/guides/index.rst:38 +msgid "Miscellaneous:" +msgstr "" + +#: ../source/guides/index.rst:4 +msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:5 +msgid "Package index mirrors and caches" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:8 +#: ../source/guides/supporting-multiple-python-versions.rst:8 +msgid "2014-12-24" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:14 +msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:17 +msgid "Three options are available in this area:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:19 +msgid "pip provides local caching options," +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:20 +msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:22 +msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:27 +msgid "Caching with pip" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:29 +msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:32 +msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:36 +msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:45 +msgid "Caching with devpi" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:47 +msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:55 +msgid "Complete mirror with bandersnatch" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:57 +msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:63 +msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:5 +msgid "Installing scientific packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:11 +msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:16 +msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:22 +msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:29 +msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:35 +msgid "Building from source" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:37 +msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:45 +msgid "Linux distribution packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:47 +msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:51 +msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:57 +msgid "Windows installers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:59 +msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:64 +msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:67 +msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:73 +msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:79 +msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:86 +msgid "macOS installers and package managers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:88 +msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:92 +msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:99 +msgid "SciPy distributions" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:101 +msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:105 +msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:109 +#: ../source/key_projects.rst:596 +msgid "Spack" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:110 +msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:119 +msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:128 +msgid "The conda cross-platform package manager" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:130 +msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:136 +msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 +msgid "Installing stand alone command line tools" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 +msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 +msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 +msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 +msgid "pipx only works with Python 3.6+." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 +msgid "``pipx`` is installed with ``pip``:" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 +msgid "You may need to restart your terminal for the path updates to take effect." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 +msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 +#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 +msgid "For example" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 +msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 +msgid "To upgrade or uninstall the package" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 +msgid "``pipx`` can be upgraded or uninstalled with pip" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 +msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 +msgid "To see the full list of commands ``pipx`` offers, run" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 +msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:5 +msgid "Installing pip/setuptools/wheel with Linux Package Managers" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:8 +msgid "2015-09-17" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:11 +msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:14 +msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:18 +msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:25 +msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:32 +msgid "Fedora" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:34 +msgid "Fedora 21:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:36 +#: ../source/guides/installing-using-linux-tools.rst:45 +#: ../source/guides/installing-using-linux-tools.rst:124 +#: ../source/guides/installing-using-linux-tools.rst:138 +#: ../source/guides/installing-using-linux-tools.rst:158 +msgid "Python 2::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:41 +msgid "Python 3: ``sudo yum install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:43 +msgid "Fedora 22:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:50 +msgid "Python 3: ``sudo dnf install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:53 +msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:63 +msgid "CentOS/RHEL" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:65 +msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:68 +msgid "To install pip and wheel for the system Python, there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:70 +msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:77 +msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:81 +msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:85 +msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:92 +msgid "To additionally upgrade setuptools, run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:97 +msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:101 +msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:104 +msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:106 +msgid "For CentOS, see here: https://www.softwarecollections.org/en/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:108 +msgid "Be aware that collections may not contain the most recent versions." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:110 +msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:116 +msgid "For example, for Python 3.4 on CentOS7/RHEL7::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:122 +msgid "openSUSE" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:129 +#: ../source/guides/installing-using-linux-tools.rst:143 +#: ../source/guides/installing-using-linux-tools.rst:162 +msgid "Python 3::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:135 +msgid "Debian/Ubuntu" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:150 +msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:156 +msgid "Arch Linux" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:168 +msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 +msgid "Installing packages using pip and virtual environments" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 +msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 +msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 +msgid "Installing pip" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 +msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 +msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 +msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 +msgid "Afterwards, you should have the newest pip installed in your user site:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 +msgid "The Python installers for Windows include pip. You should be able to access pip using:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 +msgid "You can make sure that pip is up-to-date by running:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 +msgid "Installing virtualenv" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 +msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 +msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 +msgid "Creating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 +msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 +msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 +msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 +msgid "venv will create a virtual Python installation in the ``env`` folder." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 +msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 +msgid "Activating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 +msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 +msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 +msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 +msgid "Leaving the virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 +msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 +msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 +msgid "Installing packages" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 +msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 +msgid "pip should download requests and all of its dependencies and install them:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 +msgid "Installing specific versions" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 +msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 +msgid "To install the latest ``2.x`` release of requests:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 +msgid "To install pre-release versions of packages, use the ``--pre`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 +msgid "Installing extras" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 +msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 +msgid "Installing from source" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 +msgid "pip can install a package directly from source, for example:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 +msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 +msgid "Installing from version control systems" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 +msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 +msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 +#: ../source/tutorials/installing-packages.rst:569 +msgid "Installing from local archives" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 +msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 +msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 +msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 +msgid "Using other package indexes" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 +msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 +msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 +#: ../source/tutorials/installing-packages.rst:389 +msgid "Upgrading packages" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 +msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 +msgid "Using requirements files" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 +msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 +msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 +msgid "Freezing dependencies" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 +msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 +msgid "Which will output a list of package specifiers such as:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 +msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:2 +msgid "Making a PyPI-friendly README" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:4 +msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:9 +msgid "Creating a README file" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:11 +msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:13 +msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:16 +msgid "plain text" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:17 +msgid "`reStructuredText `_ (without Sphinx extensions)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:18 +msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:21 +msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:25 +msgid "Including your README in your package's metadata" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:27 +msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:33 +msgid ":ref:`description-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:34 +msgid ":ref:`description-content-type-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:36 +msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:39 +msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:45 +msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:60 +msgid "The minimum required versions of the respective tools are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:62 +msgid "``setuptools >= 38.6.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:63 +msgid "``wheel >= 0.31.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:64 +msgid "``twine >= 1.11.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:66 +msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:72 +msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:95 +msgid "Validating reStructuredText markup" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:97 +msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:100 +msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:105 +msgid "You can check your README for markup errors before uploading as follows:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:107 +msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:122 +msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:125 +msgid "Run ``twine check`` on the sdist and wheel::" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:129 +msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:4 +msgid "Migrating to PyPI.org" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:6 +msgid ":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``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:12 +msgid "Publishing releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:14 +msgid "``pypi.org`` is the default upload platform as of September 2016." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:16 +msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:22 +msgid "The default upload settings switched to ``pypi.org`` in the following versions:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:24 +msgid "``twine`` 1.8.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:25 +msgid "``setuptools`` 27.0.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:26 +msgid "Python 2.7.13 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:27 +msgid "Python 3.4.6 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:28 +msgid "Python 3.5.3 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:29 +msgid "Python 3.6.0 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:31 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:48 +msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:51 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:67 +msgid "(``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.)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:73 +msgid "Registering package names & metadata" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:75 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:79 +msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:84 +msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:89 +#: ../source/guides/using-testpypi.rst:5 +msgid "Using TestPyPI" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:91 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:113 +msgid "Registering new user accounts" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:115 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:121 +msgid "Browsing packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:123 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:130 +msgid "Downloading packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:132 +msgid "``pypi.org`` is the default host for downloading packages." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:135 +msgid "Managing published packages and releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:137 +msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:5 +msgid "Multi-version installs" +msgstr "" + +#: ../source/guides/multi-version-installs.rst:8 +msgid "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``)." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:13 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:31 +msgid "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 ``python -c ''`` to invoke the application's main entry point directly." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:38 +msgid "Refer to the `pkg_resources documentation `__ for more details." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:5 +msgid "Packaging binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:8 +msgid "2013-12-08" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:10 +msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:20 +msgid "An overview of binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:23 +msgid "Use cases" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:25 +msgid "The typical use cases for binary extensions break down into just three conventional categories:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:28 +msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:39 +msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:47 +msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:56 +msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:61 +msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:71 +msgid "Disadvantages" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:73 +msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:80 +msgid "This means that binary extensions:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:82 +msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:85 +msgid "may not be compatible with different builds of the CPython reference interpreter" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:88 +msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:91 +msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:96 +msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:101 +msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:108 +msgid "Alternatives to handcoded accelerator modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:110 +msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:115 +msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:122 +msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:132 +msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:141 +msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:150 +msgid "Alternatives to handcoded wrapper modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:152 +msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:158 +msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:162 +msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:168 +msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:175 +msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:181 +msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:185 +msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:189 +msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:203 +msgid "Alternatives for low level system access" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:205 +msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:213 +msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:222 +msgid "Implementing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:224 +msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:241 +msgid "Building binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:244 +msgid "Building extensions for multiple platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:246 +msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:256 +msgid "Binary extensions for Windows" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:258 +msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:263 +msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:269 +msgid "To set up a build environment for binary extensions, the steps are as follows:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:271 +msgid "For Python 2.7" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:273 +msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:276 +msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:278 +#: ../source/guides/packaging-binary-extensions.rst:288 +#: ../source/guides/packaging-binary-extensions.rst:295 +msgid "Done." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:280 +msgid "For Python 3.4" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:282 +msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:285 +msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:287 +msgid "Set DISTUTILS_USE_SDK=1" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:290 +msgid "For Python 3.5" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:292 +msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:297 +msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:301 +msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:305 +msgid "Binary extensions for Linux" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:307 +msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:313 +msgid "Binary extensions for macOS" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:315 +msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:325 +msgid "Publishing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:327 +msgid "For interim guidance on this topic, see the discussion in `this issue `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:343 +msgid "Additional resources" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:345 +msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:352 +msgid "Cross-platform wheel generation with scikit-build" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:354 +msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:362 +msgid "Introduction to C/C++ extension modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:364 +msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:367 +msgid "`What are (c)python extension modules? `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:368 +msgid "`Releasing the gil `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:369 +msgid "`Writing cpython extension modules using C++ `_" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:3 +msgid "Packaging namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:5 +msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:24 +msgid "And you use this package in your code like so::" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:29 +msgid "Then you can break these sub-packages into two separate distributions:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:46 +msgid "Each sub-package can now be separately installed, used, and versioned." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:48 +msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:58 +msgid "Creating a namespace package" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:60 +msgid "There are currently three different approaches to creating namespace packages:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:62 +msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:66 +msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:69 +msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:73 +msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:80 +msgid "Native namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:82 +msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:97 +msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:102 +msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:117 +msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:123 +msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:129 +msgid "pkgutil-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:131 +msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:136 +msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:148 +#: ../source/guides/packaging-namespace-packages.rst:194 +msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:155 +#: ../source/guides/packaging-namespace-packages.rst:201 +msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:160 +msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:171 +msgid "pkg_resources-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:173 +msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:182 +msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:206 +msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:216 +msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:223 +msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:237 +msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 +msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 +msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 +msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 +msgid "Saving credentials on GitHub" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 +msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 +msgid "Let's begin! 🚀" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 +msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 +msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 +msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 +msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 +msgid "Creating a workflow definition" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 +msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 +msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 +msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 +msgid "Defining a workflow job environment" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 +msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 +msgid "Checking out the project and building distributions" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 +msgid "Then, add the following under the ``build-n-publish`` section:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 +msgid "This will download your repository into the CI runner and then install and activate Python 3.7." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 +msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 +msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 +msgid "So add this to the steps list:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 +msgid "Publishing the distribution to PyPI and TestPyPI" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 +msgid "Finally, add the following steps at the end:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 +msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 +msgid "That's all, folks!" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 +msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:5 +msgid "Single-sourcing the package version" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:8 +msgid "There are many techniques to maintain a single source of truth for the version number of your project:" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:11 +msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:38 +msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:47 +msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:52 +msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:55 +msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:58 +msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:65 +msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:76 +msgid "Example using this technique: `warehouse `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:78 +msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:86 +msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:91 +msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:95 +msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:110 +msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:114 +msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:128 +msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:134 +msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:138 +msgid "Example using this technique: `setuptools `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:141 +msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:155 +msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:161 +msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:5 +msgid "Supporting multiple Python versions" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:37 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:43 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:49 +msgid "Automated testing and continuous integration" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:51 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:60 +msgid "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:" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:66 +msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:69 +msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:80 +msgid "Both `Travis CI`_ 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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:85 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:89 +msgid "Tools for single-source Python packages" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:91 +msgid "`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_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:100 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:107 +msgid "a Python 2 (by syntax) module in a Python 3 project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:108 +msgid "a Python 3 (by syntax) module in a *Python 2* project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:110 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:117 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:124 +msgid "What's in which Python?" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:126 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:3 +msgid "Supporting Windows using Appveyor" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:6 +msgid "2015-12-03" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:8 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:20 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:24 +msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:30 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:38 +msgid "Setting up" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:40 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:45 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:49 +msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:54 +msgid "Adding Appveyor support to your project" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:61 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:69 +msgid "appveyor.yml" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:75 +msgid "This file can be downloaded from `here `__." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:77 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:80 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:88 +msgid "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``)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:94 +msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:97 +msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:100 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:109 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:114 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:119 +msgid "Support script" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:121 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:126 +msgid "`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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:133 +msgid "You can simply download the batch file and include it in your project unchanged." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:137 +msgid "Access to the built wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:139 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:147 +msgid "Additional notes" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:150 +msgid "Testing with tox" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:152 +msgid "Many projects use the `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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:156 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:160 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:165 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:170 +msgid "``DISTUTILS_USE_SDK``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:171 +msgid "``MSSdk``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:172 +msgid "``INCLUDE``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:173 +msgid "``LIB``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:175 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:181 +msgid "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 Travis or 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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:188 +msgid "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``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:192 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:197 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:203 +msgid "Automatically uploading wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:205 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:210 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:216 +msgid "External dependencies" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:218 +msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:221 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:230 +msgid "Support scripts" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:232 +msgid "For reference, the SDK setup support script is listed here:" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:234 +msgid "``appveyor-sample/build.cmd``" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:5 +msgid "Tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:7 +msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:12 +msgid "Application dependency management" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:14 +msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:18 +msgid "When ``pipenv`` does not meet your use case, consider other tools like:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:20 +msgid ":ref:`pip`" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:22 +msgid "`pip-tools `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:24 +msgid "`Poetry `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:27 +msgid "Installation tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:29 +msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:34 +msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:37 +msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:40 +msgid ":ref:`buildout`: primarily focused on the web development community" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:42 +msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:47 +msgid "Packaging tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:49 +msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:52 +msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:56 +msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:61 +msgid "Publishing platform migration" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:63 +msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:67 +msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:72 +msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:77 +msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:82 +msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:88 +msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:93 +msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:102 +msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:107 +msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:5 +msgid "Including files in source distributions with ``MANIFEST.in``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:7 +msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:17 +msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:22 +msgid "How files are included in an sdist" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:24 +msgid "The following files are included in a source distribution by default:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:26 +msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:28 +msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:30 +msgid "scripts specified by the ``scripts`` ``setup()`` argument" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:31 +msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:33 +msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:35 +msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:37 +msgid "all files matching the pattern :file:`test/test*.py`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:38 +msgid ":file:`setup.py` (or whatever you called your setup script)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:39 +msgid ":file:`setup.cfg`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:40 +msgid ":file:`README`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:41 +msgid ":file:`README.txt`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:42 +msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:43 +msgid ":file:`README.md` (setuptools 36.4.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:44 +msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:45 +msgid ":file:`MANIFEST.in`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:47 +msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:52 +msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:60 +msgid ":file:`MANIFEST.in` commands" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:62 +msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:67 +msgid "Command" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid ":samp:`include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid "Add all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid ":samp:`exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid "Remove all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid ":samp:`global-include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid "Add all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid ":samp:`global-exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid "Remove all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid ":samp:`graft {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid "Add all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid ":samp:`prune {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid "Remove all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:79 +msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:87 +msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:91 +msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:95 +msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:101 +msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." +msgstr "" + +#: ../source/guides/using-testpypi.rst:7 +msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" +msgstr "" + +#: ../source/guides/using-testpypi.rst:13 +msgid "Registering your account" +msgstr "" + +#: ../source/guides/using-testpypi.rst:15 +msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." +msgstr "" + +#: ../source/guides/using-testpypi.rst:19 +msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." +msgstr "" + +#: ../source/guides/using-testpypi.rst:24 +msgid "Using TestPyPI with Twine" +msgstr "" + +#: ../source/guides/using-testpypi.rst:26 +msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:33 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/using-testpypi.rst:39 +msgid "Using TestPyPI with pip" +msgstr "" + +#: ../source/guides/using-testpypi.rst:41 +msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:56 +msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" +msgstr "" + +#: ../source/guides/using-testpypi.rst:73 +msgid "Setting up TestPyPI in :file:`.pypirc`" +msgstr "" + +#: ../source/guides/using-testpypi.rst:75 +msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" +msgstr "" + +#: ../source/index.rst:3 +#: ../source/key_projects.rst:181 +msgid "Python Packaging User Guide" +msgstr "" + +#: ../source/index.rst:5 +msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." +msgstr "" + +#: ../source/index.rst:5 +msgid "python, packaging, guide, tutorial" +msgstr "" + +#: ../source/index.rst:24 +msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." +msgstr "" + +#: ../source/index.rst:28 +msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" +msgstr "" + +#: ../source/index.rst:36 +msgid "Get started" +msgstr "" + +#: ../source/index.rst:38 +msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" +msgstr "" + +#: ../source/index.rst:41 +msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" +msgstr "" + +#: ../source/index.rst:43 +msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" +msgstr "" + +#: ../source/index.rst:45 +msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" +msgstr "" + +#: ../source/index.rst:47 +msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" +msgstr "" + +#: ../source/index.rst:52 +msgid "Learn more" +msgstr "" + +#: ../source/index.rst:54 +msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" +msgstr "" + +#: ../source/index.rst:56 +msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/index.rst:58 +msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." +msgstr "" + +#: ../source/index.rst:60 +msgid "The :doc:`specifications/index` section for packaging interoperability specifications." +msgstr "" + +#: ../source/index.rst:62 +msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." +msgstr "" + +#: ../source/key_projects.rst:6 +msgid "Project Summaries" +msgstr "" + +#: ../source/key_projects.rst:8 +msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." +msgstr "" + +#: ../source/key_projects.rst:14 +msgid "PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:19 +msgid "bandersnatch" +msgstr "" + +#: ../source/key_projects.rst:21 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:25 +msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." +msgstr "" + +#: ../source/key_projects.rst:35 +msgid "build" +msgstr "" + +#: ../source/key_projects.rst:37 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:42 +msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." +msgstr "" + +#: ../source/key_projects.rst:49 +msgid "cibuildwheel" +msgstr "" + +#: ../source/key_projects.rst:51 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" +msgstr "" + +#: ../source/key_projects.rst:58 +msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." +msgstr "" + +#: ../source/key_projects.rst:64 +msgid "distlib" +msgstr "" + +#: ../source/key_projects.rst:66 +msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:71 +msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." +msgstr "" + +#: ../source/key_projects.rst:80 +msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." +msgstr "" + +#: ../source/key_projects.rst:90 +msgid "packaging" +msgstr "" + +#: ../source/key_projects.rst:92 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:97 +msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." +msgstr "" + +#: ../source/key_projects.rst:99 +msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." +msgstr "" + +#: ../source/key_projects.rst:107 +msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." +msgstr "" + +#: ../source/key_projects.rst:119 +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "pip" +msgstr "" + +#: ../source/key_projects.rst:121 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:126 +msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." +msgstr "" + +#: ../source/key_projects.rst:129 +msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." +msgstr "" + +#: ../source/key_projects.rst:137 +msgid "Pipenv" +msgstr "" + +#: ../source/key_projects.rst:139 +msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:144 +msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." +msgstr "" + +#: ../source/key_projects.rst:148 +msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." +msgstr "" + +#: ../source/key_projects.rst:159 +msgid "Pipfile" +msgstr "" + +#: ../source/key_projects.rst:161 +msgid "`Source `__" +msgstr "" + +#: ../source/key_projects.rst:163 +msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." +msgstr "" + +#: ../source/key_projects.rst:170 +msgid "pipx" +msgstr "" + +#: ../source/key_projects.rst:172 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:176 +msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." +msgstr "" + +#: ../source/key_projects.rst:183 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:187 +msgid "This guide!" +msgstr "" + +#: ../source/key_projects.rst:192 +msgid "readme_renderer" +msgstr "" + +#: ../source/key_projects.rst:194 +msgid "`GitHub and docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:197 +msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." +msgstr "" + +#: ../source/key_projects.rst:208 +msgid "setuptools" +msgstr "" + +#: ../source/key_projects.rst:210 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:215 +msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." +msgstr "" + +#: ../source/key_projects.rst:220 +msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." +msgstr "" + +#: ../source/key_projects.rst:227 +msgid "trove-classifiers" +msgstr "" + +#: ../source/key_projects.rst:229 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:233 +msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." +msgstr "" + +#: ../source/key_projects.rst:239 +msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." +msgstr "" + +#: ../source/key_projects.rst:253 +msgid "twine" +msgstr "" + +#: ../source/key_projects.rst:255 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:260 +msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." +msgstr "" + +#: ../source/key_projects.rst:270 +#: ../source/overview.rst:415 +msgid "virtualenv" +msgstr "" + +#: ../source/key_projects.rst:272 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:277 +msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/key_projects.rst:290 +msgid "Warehouse" +msgstr "" + +#: ../source/key_projects.rst:292 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:296 +msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." +msgstr "" + +#: ../source/key_projects.rst:304 +msgid "wheel" +msgstr "" + +#: ../source/key_projects.rst:306 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:311 +msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." +msgstr "" + +#: ../source/key_projects.rst:315 +msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." +msgstr "" + +#: ../source/key_projects.rst:324 +msgid "Non-PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:329 +msgid "bento" +msgstr "" + +#: ../source/key_projects.rst:331 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:336 +msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." +msgstr "" + +#: ../source/key_projects.rst:344 +msgid "buildout" +msgstr "" + +#: ../source/key_projects.rst:346 +msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:351 +msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." +msgstr "" + +#: ../source/key_projects.rst:358 +msgid "conda" +msgstr "" + +#: ../source/key_projects.rst:360 +msgid "`Docs `__" +msgstr "" + +#: ../source/key_projects.rst:362 +msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." +msgstr "" + +#: ../source/key_projects.rst:369 +msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." +msgstr "" + +#: ../source/key_projects.rst:373 +msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." +msgstr "" + +#: ../source/key_projects.rst:386 +msgid "devpi" +msgstr "" + +#: ../source/key_projects.rst:388 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:392 +msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." +msgstr "" + +#: ../source/key_projects.rst:401 +msgid "flit" +msgstr "" + +#: ../source/key_projects.rst:403 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:407 +msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." +msgstr "" + +#: ../source/key_projects.rst:412 +msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." +msgstr "" + +#: ../source/key_projects.rst:422 +msgid "enscons" +msgstr "" + +#: ../source/key_projects.rst:424 +msgid "`Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:428 +msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." +msgstr "" + +#: ../source/key_projects.rst:443 +msgid "Hashdist" +msgstr "" + +#: ../source/key_projects.rst:445 +msgid "`Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:448 +msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." +msgstr "" + +#: ../source/key_projects.rst:460 +msgid "hatch" +msgstr "" + +#: ../source/key_projects.rst:462 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:465 +msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." +msgstr "" + +#: ../source/key_projects.rst:475 +msgid "multibuild" +msgstr "" + +#: ../source/key_projects.rst:477 +msgid "`GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:479 +msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." +msgstr "" + +#: ../source/key_projects.rst:485 +msgid "pex" +msgstr "" + +#: ../source/key_projects.rst:487 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:491 +msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." +msgstr "" + +#: ../source/key_projects.rst:500 +msgid "pip-tools" +msgstr "" + +#: ../source/key_projects.rst:502 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:505 +msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." +msgstr "" + +#: ../source/key_projects.rst:517 +msgid "piwheels" +msgstr "" + +#: ../source/key_projects.rst:519 +msgid "`Website `__ | `Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:523 +msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." +msgstr "" + +#: ../source/key_projects.rst:532 +msgid "poetry" +msgstr "" + +#: ../source/key_projects.rst:534 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:538 +msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." +msgstr "" + +#: ../source/key_projects.rst:548 +msgid "pypiserver" +msgstr "" + +#: ../source/key_projects.rst:550 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:554 +msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." +msgstr "" + +#: ../source/key_projects.rst:564 +msgid "scikit-build" +msgstr "" + +#: ../source/key_projects.rst:566 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:570 +msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." +msgstr "" + +#: ../source/key_projects.rst:582 +msgid "shiv" +msgstr "" + +#: ../source/key_projects.rst:584 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:588 +msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." +msgstr "" + +#: ../source/key_projects.rst:598 +msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" +msgstr "" + +#: ../source/key_projects.rst:603 +msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." +msgstr "" + +#: ../source/key_projects.rst:611 +msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." +msgstr "" + +#: ../source/key_projects.rst:617 +msgid "zest.releaser" +msgstr "" + +#: ../source/key_projects.rst:619 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:623 +msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." +msgstr "" + +#: ../source/key_projects.rst:630 +msgid "Standard Library Projects" +msgstr "" + +#: ../source/key_projects.rst:635 +msgid "ensurepip" +msgstr "" + +#: ../source/key_projects.rst:637 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:640 +msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." +msgstr "" + +#: ../source/key_projects.rst:649 +msgid "distutils" +msgstr "" + +#: ../source/key_projects.rst:651 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:654 +msgid "The original Python packaging system, added to the standard library in Python 2.0." +msgstr "" + +#: ../source/key_projects.rst:657 +msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." +msgstr "" + +#: ../source/key_projects.rst:670 +msgid "venv" +msgstr "" + +#: ../source/key_projects.rst:672 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:675 +msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/news.rst:2 +msgid "News" +msgstr "" + +#: ../source/news.rst:5 +msgid "September 2019" +msgstr "" + +#: ../source/news.rst:6 +msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" +msgstr "" + +#: ../source/news.rst:9 +msgid "August 2019" +msgstr "" + +#: ../source/news.rst:10 +msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" +msgstr "" + +#: ../source/news.rst:13 +msgid "July 2019" +msgstr "" + +#: ../source/news.rst:14 +msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" +msgstr "" + +#: ../source/news.rst:15 +msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" +msgstr "" + +#: ../source/news.rst:16 +msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" +msgstr "" + +#: ../source/news.rst:17 +msgid "Updated directory layout examples for consistency. (:pr:`611`)" +msgstr "" + +#: ../source/news.rst:18 +msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" +msgstr "" + +#: ../source/news.rst:21 +msgid "June 2019" +msgstr "" + +#: ../source/news.rst:22 +msgid "Fixed some typos. (:pr:`620`)" +msgstr "" + +#: ../source/news.rst:25 +msgid "May 2019" +msgstr "" + +#: ../source/news.rst:26 +msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" +msgstr "" + +#: ../source/news.rst:27 +msgid "Added a MANIFEST.in guide page. (:pr:`609`)" +msgstr "" + +#: ../source/news.rst:30 +msgid "April 2019" +msgstr "" + +#: ../source/news.rst:31 +msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" +msgstr "" + +#: ../source/news.rst:32 +msgid "Reduced emphasis on virtualenv. (:pr:`606`)" +msgstr "" + +#: ../source/news.rst:35 +msgid "March 2019" +msgstr "" + +#: ../source/news.rst:36 +msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" +msgstr "" + +#: ../source/news.rst:37 +msgid "Covered RTD details for contributing. (:pr:`600`)" +msgstr "" + +#: ../source/news.rst:40 +msgid "February 2019" +msgstr "" + +#: ../source/news.rst:41 +msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" +msgstr "" + +#: ../source/news.rst:42 +msgid "Added instructions to install Python CLI applications. (:pr:`594`)" +msgstr "" + +#: ../source/news.rst:45 +msgid "January 2019" +msgstr "" + +#: ../source/news.rst:46 +msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" +msgstr "" + +#: ../source/news.rst:47 +msgid "Updated Sphinx and Nox. (:pr:`591`)" +msgstr "" + +#: ../source/news.rst:48 +msgid "Referenced Twine from Python3. (:pr:`581`)" +msgstr "" + +#: ../source/news.rst:51 +msgid "December 2018" +msgstr "" + +#: ../source/news.rst:52 +msgid "No programmers in the office!" +msgstr "" + +#: ../source/news.rst:55 +msgid "November 2018" +msgstr "" + +#: ../source/news.rst:56 +msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" +msgstr "" + +#: ../source/news.rst:57 +msgid "Changed bumpversion to bump2version. (:pr:`572`)" +msgstr "" + +#: ../source/news.rst:58 +msgid "Added single-sourcing package version example. (:pr:`573`)" +msgstr "" + +#: ../source/news.rst:59 +msgid "Added a guide for creating documentation. (:pr:`568`)" +msgstr "" + +#: ../source/news.rst:62 +msgid "October 2018" +msgstr "" + +#: ../source/news.rst:63 +msgid "Updated Nox package name. (:pr:`566`)" +msgstr "" + +#: ../source/news.rst:64 +msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" +msgstr "" + +#: ../source/news.rst:67 +msgid "September 2018" +msgstr "" + +#: ../source/news.rst:68 +msgid "Added a section on checking RST markup. (:pr:`554`)" +msgstr "" + +#: ../source/news.rst:69 +msgid "Updated user installs page. (:pr:`558`)" +msgstr "" + +#: ../source/news.rst:70 +msgid "Updated Google BigQuery urls. (:pr:`556`)" +msgstr "" + +#: ../source/news.rst:71 +msgid "Replaced tar command with working command. (:pr:`552`)" +msgstr "" + +#: ../source/news.rst:72 +msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" +msgstr "" + +#: ../source/news.rst:75 +msgid "August 2018" +msgstr "" + +#: ../source/news.rst:76 +msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" +msgstr "" + +#: ../source/news.rst:77 +msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" +msgstr "" + +#: ../source/news.rst:78 +msgid "Updated Python version supported by virtualenv. (:pr:`538`)" +msgstr "" + +#: ../source/news.rst:79 +msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" +msgstr "" + +#: ../source/news.rst:82 +msgid "July 2018" +msgstr "" + +#: ../source/news.rst:84 +msgid "Improved binary extension docs. (:pr:`531`)" +msgstr "" + +#: ../source/news.rst:85 +msgid "Added scikit-build to key projects. (:pr:`530`)" +msgstr "" + +#: ../source/news.rst:88 +msgid "June 2018" +msgstr "" + +#: ../source/news.rst:90 +msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" +msgstr "" + +#: ../source/news.rst:91 +msgid "Updated Markdown descriptions explanation. (:pr:`522`)" +msgstr "" + +#: ../source/news.rst:94 +msgid "May 2018" +msgstr "" + +#: ../source/news.rst:96 +msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" +msgstr "" + +#: ../source/news.rst:97 +msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" +msgstr "" + +#: ../source/news.rst:98 +msgid "Simplified packaging tutorial. (:pr:`498`)" +msgstr "" + +#: ../source/news.rst:99 +msgid "Updated Windows users instructions for clarity. (:pr:`493`)" +msgstr "" + +#: ../source/news.rst:100 +msgid "Updated the license section description for completeness. (:pr:`492`)" +msgstr "" + +#: ../source/news.rst:101 +msgid "Added specification-style document to contributing section. (:pr:`489`)" +msgstr "" + +#: ../source/news.rst:102 +msgid "Added documentation types to contributing guide. (:pr:`485`)" +msgstr "" + +#: ../source/news.rst:105 +msgid "April 2018" +msgstr "" + +#: ../source/news.rst:107 +msgid "Added README guide. (:pr:`461`)" +msgstr "" + +#: ../source/news.rst:108 +msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" +msgstr "" + +#: ../source/news.rst:109 +msgid "Added instructions for Warehouse. (:pr:`471`)" +msgstr "" + +#: ../source/news.rst:110 +msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" +msgstr "" + +#: ../source/news.rst:111 +msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" +msgstr "" + +#: ../source/news.rst:112 +msgid "Added a guide for phasing out Python versions. (:pr:`459`)" +msgstr "" + +#: ../source/news.rst:113 +msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" +msgstr "" + +#: ../source/news.rst:116 +msgid "March 2018" +msgstr "" + +#: ../source/news.rst:118 +msgid "Updated \"installing scientific packages\". (:pr:`455`)" +msgstr "" + +#: ../source/news.rst:119 +msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" +msgstr "" + +#: ../source/news.rst:120 +msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" +msgstr "" + +#: ../source/news.rst:121 +msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" +msgstr "" + +#: ../source/news.rst:124 +msgid "February 2018" +msgstr "" + +#: ../source/news.rst:126 +msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" +msgstr "" + +#: ../source/news.rst:127 +msgid "Updated PyPI migration info. (:pr:`439`)" +msgstr "" + +#: ../source/news.rst:128 +msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" +msgstr "" + +#: ../source/news.rst:129 +msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" +msgstr "" + +#: ../source/news.rst:130 +msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" +msgstr "" + +#: ../source/news.rst:133 +msgid "January 2018" +msgstr "" + +#: ../source/news.rst:135 +msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" +msgstr "" + +#: ../source/news.rst:136 +msgid "Updated README.rst explanation. (:pr:`419`)" +msgstr "" + +#: ../source/news.rst:139 +msgid "December 2017" +msgstr "" + +#: ../source/news.rst:141 +msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" +msgstr "" + +#: ../source/news.rst:142 +msgid "Noted which fields can be used with environment markers. (:pr:`416`)" +msgstr "" + +#: ../source/news.rst:143 +msgid "Updated Requires-Python section. (:pr:`414`)" +msgstr "" + +#: ../source/news.rst:144 +msgid "Added news page. (:pr:`404`)" +msgstr "" + +#: ../source/news.rst:147 +msgid "November 2017" +msgstr "" + +#: ../source/news.rst:149 +msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" +msgstr "" + +#: ../source/news.rst:150 +msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" +msgstr "" + +#: ../source/news.rst:152 +msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:153 +msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" +msgstr "" + +#: ../source/news.rst:156 +msgid "October 2017" +msgstr "" + +#: ../source/news.rst:158 +msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:159 +msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" +msgstr "" + +#: ../source/news.rst:160 +msgid "Split the specifications page into multiple pages. (:pr:`386`)" +msgstr "" + +#: ../source/news.rst:163 +msgid "September 2017" +msgstr "" + +#: ../source/news.rst:165 +msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" +msgstr "" + +#: ../source/news.rst:167 +msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" +msgstr "" + +#: ../source/news.rst:170 +msgid "August 2017" +msgstr "" + +#: ../source/news.rst:172 +msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" +msgstr "" + +#: ../source/news.rst:173 +msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" +msgstr "" + +#: ../source/news.rst:174 +msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" +msgstr "" + +#: ../source/news.rst:177 +msgid "July 2017" +msgstr "" + +#: ../source/news.rst:179 +msgid "Added ``flit`` to the key projects list. (:pr:`358`)" +msgstr "" + +#: ../source/news.rst:180 +msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" +msgstr "" + +#: ../source/news.rst:181 +msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" +msgstr "" + +#: ../source/news.rst:182 +msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" +msgstr "" + +#: ../source/news.rst:183 +msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" +msgstr "" + +#: ../source/news.rst:186 +msgid "June 2017" +msgstr "" + +#: ../source/news.rst:188 +msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" +msgstr "" + +#: ../source/news.rst:189 +msgid "Added documentation for ``python_requires``. (:pr:`338`)" +msgstr "" + +#: ../source/news.rst:190 +msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" +msgstr "" + +#: ../source/news.rst:191 +msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" +msgstr "" + +#: ../source/news.rst:192 +msgid "Added a license section to the distributing guide. (:pr:`331`)" +msgstr "" + +#: ../source/news.rst:193 +msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" +msgstr "" + +#: ../source/news.rst:194 +msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" +msgstr "" + +#: ../source/news.rst:195 +msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" +msgstr "" + +#: ../source/news.rst:196 +msgid "Switched to the PyPA theme. (:pr:`305`)" +msgstr "" + +#: ../source/news.rst:197 +msgid "Re-organized the documentation into the new structure. (:pr:`318`)" +msgstr "" + +#: ../source/news.rst:200 +msgid "May 2017" +msgstr "" + +#: ../source/news.rst:202 +msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" +msgstr "" + +#: ../source/news.rst:203 +msgid "Added contributor and style guide. (:pr:`307`)" +msgstr "" + +#: ../source/news.rst:204 +msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" +msgstr "" + +#: ../source/news.rst:207 +msgid "April 2017" +msgstr "" + +#: ../source/news.rst:209 +msgid "Added travis configuration for testing pull requests. (:pr:`300`)" +msgstr "" + +#: ../source/news.rst:210 +msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" +msgstr "" + +#: ../source/news.rst:211 +msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" +msgstr "" + +#: ../source/news.rst:212 +msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" +msgstr "" + +#: ../source/news.rst:213 +msgid "Added a topic on namespace packages. (:pr:`290`)" +msgstr "" + +#: ../source/news.rst:214 +msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" +msgstr "" + +#: ../source/news.rst:215 +msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" +msgstr "" + +#: ../source/news.rst:216 +msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" +msgstr "" + +#: ../source/news.rst:217 +msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" +msgstr "" + +#: ../source/news.rst:219 +msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" +msgstr "" + +#: ../source/news.rst:223 +msgid "March 2017" +msgstr "" + +#: ../source/news.rst:225 +msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" +msgstr "" + +#: ../source/news.rst:228 +msgid "February 2017" +msgstr "" + +#: ../source/news.rst:230 +msgid "Added :pep:`518`. (:pr:`281`)" +msgstr "" + +#: ../source/overview.rst:3 +msgid "An Overview of Packaging for Python" +msgstr "" + +#: ../source/overview.rst:7 +msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." +msgstr "" + +#: ../source/overview.rst:12 +msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." +msgstr "" + +#: ../source/overview.rst:18 +msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." +msgstr "" + +#: ../source/overview.rst:26 +msgid "Thinking about deployment" +msgstr "" + +#: ../source/overview.rst:28 +msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" +msgstr "" + +#: ../source/overview.rst:32 +msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" +msgstr "" + +#: ../source/overview.rst:35 +msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" +msgstr "" + +#: ../source/overview.rst:37 +msgid "Is your software installed individually, or in large deployment batches?" +msgstr "" + +#: ../source/overview.rst:39 +msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." +msgstr "" + +#: ../source/overview.rst:46 +msgid "Packaging Python libraries and tools" +msgstr "" + +#: ../source/overview.rst:48 +msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/overview.rst:53 +msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." +msgstr "" + +#: ../source/overview.rst:59 +msgid "Python modules" +msgstr "" + +#: ../source/overview.rst:61 +msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." +msgstr "" + +#: ../source/overview.rst:66 +msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." +msgstr "" + +#: ../source/overview.rst:73 +msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." +msgstr "" + +#: ../source/overview.rst:78 +msgid "Python source distributions" +msgstr "" + +#: ../source/overview.rst:80 +msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." +msgstr "" + +#: ../source/overview.rst:84 +msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." +msgstr "" + +#: ../source/overview.rst:90 +msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." +msgstr "" + +#: ../source/overview.rst:95 +msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." +msgstr "" + +#: ../source/overview.rst:100 +msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." +msgstr "" + +#: ../source/overview.rst:107 +msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" +msgstr "" + +#: ../source/overview.rst:114 +msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." +msgstr "" + +#: ../source/overview.rst:119 +msgid "Python binary distributions" +msgstr "" + +#: ../source/overview.rst:121 +msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." +msgstr "" + +#: ../source/overview.rst:125 +msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." +msgstr "" + +#: ../source/overview.rst:132 +msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." +msgstr "" + +#: ../source/overview.rst:140 +msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." +msgstr "" + +#: ../source/overview.rst:148 +msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." +msgstr "" + +#: ../source/overview.rst:155 +msgid "Packaging Python applications" +msgstr "" + +#: ../source/overview.rst:157 +msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." +msgstr "" + +#: ../source/overview.rst:162 +msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." +msgstr "" + +#: ../source/overview.rst:166 +msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." +msgstr "" + +#: ../source/overview.rst:172 +msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." +msgstr "" + +#: ../source/overview.rst:176 +msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." +msgstr "" + +#: ../source/overview.rst:181 +msgid "Depending on a framework" +msgstr "" + +#: ../source/overview.rst:183 +msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." +msgstr "" + +#: ../source/overview.rst:189 +msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." +msgstr "" + +#: ../source/overview.rst:195 +msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." +msgstr "" + +#: ../source/overview.rst:199 +msgid "Service platforms" +msgstr "" + +#: ../source/overview.rst:201 +msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." +msgstr "" + +#: ../source/overview.rst:205 +msgid "`Heroku `_" +msgstr "" + +#: ../source/overview.rst:206 +msgid "`Google App Engine `_" +msgstr "" + +#: ../source/overview.rst:207 +msgid "`PythonAnywhere `_" +msgstr "" + +#: ../source/overview.rst:208 +msgid "`OpenShift `_" +msgstr "" + +#: ../source/overview.rst:209 +msgid "\"Serverless\" frameworks like `Zappa `_" +msgstr "" + +#: ../source/overview.rst:211 +msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." +msgstr "" + +#: ../source/overview.rst:216 +msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." +msgstr "" + +#: ../source/overview.rst:220 +msgid "Web browsers and mobile applications" +msgstr "" + +#: ../source/overview.rst:222 +msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." +msgstr "" + +#: ../source/overview.rst:227 +msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" +msgstr "" + +#: ../source/overview.rst:231 +msgid "`Kivy `_" +msgstr "" + +#: ../source/overview.rst:232 +msgid "`Beeware `_" +msgstr "" + +#: ../source/overview.rst:233 +msgid "`Brython `_" +msgstr "" + +#: ../source/overview.rst:234 +msgid "`Flexx `_" +msgstr "" + +#: ../source/overview.rst:236 +msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." +msgstr "" + +#: ../source/overview.rst:241 +msgid "Depending on a pre-installed Python" +msgstr "" + +#: ../source/overview.rst:243 +msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." +msgstr "" + +#: ../source/overview.rst:249 +msgid "Technologies which support this model:" +msgstr "" + +#: ../source/overview.rst:251 +msgid "`PEX `_ (Python EXecutable)" +msgstr "" + +#: ../source/overview.rst:252 +msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" +msgstr "" + +#: ../source/overview.rst:253 +msgid "`shiv `_ (requires Python 3)" +msgstr "" + +#: ../source/overview.rst:255 +msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." +msgstr "" + +#: ../source/overview.rst:260 +msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." +msgstr "" + +#: ../source/overview.rst:267 +msgid "Depending on a separate software distribution ecosystem" +msgstr "" + +#: ../source/overview.rst:269 +msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." +msgstr "" + +#: ../source/overview.rst:274 +msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." +msgstr "" + +#: ../source/overview.rst:284 +msgid "Instructions on building and publishing for the Anaconda ecosystem:" +msgstr "" + +#: ../source/overview.rst:286 +msgid "`Building libraries and applications with conda `_" +msgstr "" + +#: ../source/overview.rst:287 +msgid "`Transitioning a native Python package to Anaconda `_" +msgstr "" + +#: ../source/overview.rst:289 +msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" +msgstr "" + +#: ../source/overview.rst:293 +msgid "`Enthought Canopy `_" +msgstr "" + +#: ../source/overview.rst:294 +msgid "`ActiveState ActivePython `_" +msgstr "" + +#: ../source/overview.rst:295 +msgid "`WinPython `_" +msgstr "" + +#: ../source/overview.rst:300 +msgid "Bringing your own Python executable" +msgstr "" + +#: ../source/overview.rst:302 +msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." +msgstr "" + +#: ../source/overview.rst:306 +msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." +msgstr "" + +#: ../source/overview.rst:311 +msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." +msgstr "" + +#: ../source/overview.rst:315 +msgid "A selection of Python freezers:" +msgstr "" + +#: ../source/overview.rst:317 +msgid "`pyInstaller `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:318 +msgid "`cx_Freeze `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:319 +msgid "`constructor `_ - For command-line installers" +msgstr "" + +#: ../source/overview.rst:320 +msgid "`py2exe `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:321 +msgid "`py2app `_ - Mac only" +msgstr "" + +#: ../source/overview.rst:322 +msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" +msgstr "" + +#: ../source/overview.rst:323 +msgid "`osnap `_ - Windows and Mac" +msgstr "" + +#: ../source/overview.rst:324 +msgid "`pynsist `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:326 +msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." +msgstr "" + +#: ../source/overview.rst:332 +msgid "Bringing your own userspace" +msgstr "" + +#: ../source/overview.rst:334 +msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." +msgstr "" + +#: ../source/overview.rst:341 +msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." +msgstr "" + +#: ../source/overview.rst:344 +msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" +msgstr "" + +#: ../source/overview.rst:347 +msgid "`AppImage `_" +msgstr "" + +#: ../source/overview.rst:348 +msgid "`Docker `_" +msgstr "" + +#: ../source/overview.rst:349 +msgid "`Flatpak `_" +msgstr "" + +#: ../source/overview.rst:350 +msgid "`Snapcraft `_" +msgstr "" + +#: ../source/overview.rst:353 +msgid "Bringing your own kernel" +msgstr "" + +#: ../source/overview.rst:355 +msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." +msgstr "" + +#: ../source/overview.rst:360 +msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" +msgstr "" + +#: ../source/overview.rst:364 +msgid "`Vagrant `_" +msgstr "" + +#: ../source/overview.rst:365 +msgid "`VHD `_, `AMI `_, and `other formats `_" +msgstr "" + +#: ../source/overview.rst:366 +msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" +msgstr "" + +#: ../source/overview.rst:369 +msgid "Bringing your own hardware" +msgstr "" + +#: ../source/overview.rst:371 +msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." +msgstr "" + +#: ../source/overview.rst:375 +msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." +msgstr "" + +#: ../source/overview.rst:379 +msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." +msgstr "" + +#: ../source/overview.rst:389 +msgid "The simplified gamut of technologies used to package Python applications." +msgstr "" + +#: ../source/overview.rst:392 +msgid "What about..." +msgstr "" + +#: ../source/overview.rst:394 +msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." +msgstr "" + +#: ../source/overview.rst:398 +msgid "Operating system packages" +msgstr "" + +#: ../source/overview.rst:400 +msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." +msgstr "" + +#: ../source/overview.rst:411 +msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." +msgstr "" + +#: ../source/overview.rst:417 +msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." +msgstr "" + +#: ../source/overview.rst:427 +msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." +msgstr "" + +#: ../source/overview.rst:432 +msgid "Security" +msgstr "" + +#: ../source/overview.rst:434 +msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." +msgstr "" + +#: ../source/overview.rst:437 +msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." +msgstr "" + +#: ../source/overview.rst:446 +msgid "Wrap up" +msgstr "" + +#: ../source/overview.rst:448 +msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:6 +msgid "Binary distribution format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:8 +msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:13 +msgid "Abstract" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:15 +msgid "This PEP describes a built-package format for Python called \"wheel\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:17 +msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:27 +msgid "PEP Acceptance" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:29 +msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:34 +msgid "Rationale" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:36 +msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:43 +msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:52 +msgid "Details" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:55 +msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:57 +msgid "Wheel installation notionally consists of two phases:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:59 +msgid "Unpack." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:61 +msgid "Parse ``distribution-1.0.dist-info/WHEEL``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:62 +msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:64 +msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:66 +msgid "Else unpack archive into platlib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:68 +msgid "Spread." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:70 +msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:72 +msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:78 +msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:80 +msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:82 +msgid "Remove empty ``distribution-1.0.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:83 +msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:87 +msgid "Recommended installer features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:97 +msgid "Rewrite ``#!python``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:90 +msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:96 +msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:102 +msgid "Generate script wrappers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:100 +msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:105 +msgid "Recommended archiver features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:112 +msgid "Place ``.dist-info`` at the end of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:108 +msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:115 +msgid "File Format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:118 +msgid "File name convention" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:120 +msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "distribution" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "Distribution name, e.g. 'django', 'pyramid'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "Distribution version, e.g. 1.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:135 +msgid "build tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:130 +msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "language implementation and version tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "E.g. 'py27', 'py2', 'py3'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "abi tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "E.g. 'cp33m', 'abi3', 'none'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "platform tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "E.g. 'linux_x86_64', 'any'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:146 +msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:151 +msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:156 +msgid "Escaping and Unicode" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:158 +msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:161 +msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:164 +msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:166 +msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:169 +msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:172 +msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:176 +msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:182 +msgid "File contents" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:184 +msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:188 +msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:191 +msgid "``{distribution}-{version}.dist-info/`` contains metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:192 +msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:196 +msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:200 +msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:202 +msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:212 +msgid "``Wheel-Version`` is the version number of the Wheel specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:213 +msgid "``Generator`` is the name and optionally the version of the software that produced the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:215 +msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:218 +msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:220 +msgid "``Build`` is the build number and is omitted if there is no build number." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:221 +msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:224 +msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:226 +msgid "Wheel does not contain setup.py or setup.cfg." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:228 +msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:235 +#: ../source/specifications/recording-installed-packages.rst:35 +msgid "The .dist-info directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:237 +msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:239 +msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:241 +msgid "WHEEL is the wheel metadata specific to a build of the package." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:242 +msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:248 +msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:249 +msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:251 +msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:254 +msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:261 +msgid "The .data directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:263 +msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:271 +msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:277 +msgid "Signed wheel files" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:279 +msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:290 +msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:295 +msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:302 +msgid "(The hash value is the same format used in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:304 +msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:307 +msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:312 +msgid "See" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:314 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:315 +msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:316 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:317 +msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:321 +msgid "Comparison to .egg" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:323 +msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:328 +msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:331 +msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:337 +msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:341 +msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:344 +msgid "Wheel is a reference to the other Python." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:348 +msgid "FAQ" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:352 +msgid "Wheel defines a .data directory. Should I put all my data there?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:354 +msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:363 +msgid "Why does wheel include attached signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:365 +msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:373 +msgid "Why does wheel allow JWS signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:375 +msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:381 +msgid "Why does wheel also allow S/MIME signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:383 +msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:386 +msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:391 +msgid "What's the deal with \"purelib\" vs. \"platlib\"?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:393 +msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:398 +msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:403 +msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:409 +msgid "Is it possible to import Python code directly from a wheel file?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:411 +msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:417 +msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:426 +msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:443 +msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:450 +msgid "Changes" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:452 +msgid "Since :pep:`427`, this specification has changed as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:454 +msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:461 +msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:466 +msgid "Appendix" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:468 +msgid "Example urlsafe-base64-nopad implementation::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:482 +msgid "Copyright" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:484 +msgid "This document has been placed into the public domain." +msgstr "" + +#: ../source/specifications/core-metadata.rst:5 +msgid "Core metadata specifications" +msgstr "" + +#: ../source/specifications/core-metadata.rst:7 +msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:10 +msgid "``Metadata-Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:11 +msgid "``Name``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:12 +msgid "``Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:14 +msgid "All the other fields are optional." +msgstr "" + +#: ../source/specifications/core-metadata.rst:16 +msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." +msgstr "" + +#: ../source/specifications/core-metadata.rst:25 +msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:30 +msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." +msgstr "" + +#: ../source/specifications/core-metadata.rst:41 +msgid "Metadata-Version" +msgstr "" + +#: ../source/specifications/core-metadata.rst:45 +msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." +msgstr "" + +#: ../source/specifications/core-metadata.rst:48 +msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:54 +msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." +msgstr "" + +#: ../source/specifications/core-metadata.rst:58 +#: ../source/specifications/core-metadata.rst:80 +#: ../source/specifications/core-metadata.rst:95 +#: ../source/specifications/core-metadata.rst:155 +#: ../source/specifications/core-metadata.rst:170 +#: ../source/specifications/core-metadata.rst:208 +#: ../source/specifications/core-metadata.rst:283 +#: ../source/specifications/core-metadata.rst:287 +#: ../source/specifications/core-metadata.rst:291 +#: ../source/specifications/core-metadata.rst:295 +#: ../source/specifications/core-metadata.rst:327 +#: ../source/specifications/core-metadata.rst:347 +#: ../source/specifications/core-metadata.rst:373 +#: ../source/specifications/core-metadata.rst:391 +#: ../source/specifications/core-metadata.rst:416 +#: ../source/specifications/core-metadata.rst:438 +#: ../source/specifications/core-metadata.rst:600 +#: ../source/specifications/core-metadata.rst:620 +#: ../source/specifications/core-metadata.rst:630 +msgid "Example::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:66 +msgid "Name" +msgstr "" + +#: ../source/specifications/core-metadata.rst:69 +msgid "Added additional restrictions on format from :pep:`508`" +msgstr "" + +#: ../source/specifications/core-metadata.rst:72 +msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:88 +msgid "Version" +msgstr "" + +#: ../source/specifications/core-metadata.rst:92 +msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:101 +msgid "Dynamic (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:105 +msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." +msgstr "" + +#: ../source/specifications/core-metadata.rst:108 +msgid "When found in the metadata of a source distribution, the following rules apply:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:111 +msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." +msgstr "" + +#: ../source/specifications/core-metadata.rst:115 +msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:118 +msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:122 +msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." +msgstr "" + +#: ../source/specifications/core-metadata.rst:127 +msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:131 +msgid "Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:135 +msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." +msgstr "" + +#: ../source/specifications/core-metadata.rst:146 +msgid "Supported-Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:150 +msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." +msgstr "" + +#: ../source/specifications/core-metadata.rst:164 +msgid "Summary" +msgstr "" + +#: ../source/specifications/core-metadata.rst:168 +msgid "A one-line summary of what the distribution does." +msgstr "" + +#: ../source/specifications/core-metadata.rst:188 +msgid "This field may be specified in the message body instead." +msgstr "" + +#: ../source/specifications/core-metadata.rst:191 +msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:196 +msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." +msgstr "" + +#: ../source/specifications/core-metadata.rst:202 +msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:219 +msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." +msgstr "" + +#: ../source/specifications/core-metadata.rst:223 +msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:232 +msgid "Description-Content-Type" +msgstr "" + +#: ../source/specifications/core-metadata.rst:236 +msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:239 +msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." +msgstr "" + +#: ../source/specifications/core-metadata.rst:253 +msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:259 +msgid "Format::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:263 +msgid "The ``type/subtype`` part has only a few legal values:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:265 +msgid "``text/plain``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:266 +msgid "``text/x-rst``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:267 +msgid "``text/markdown``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:269 +msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:273 +msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:278 +msgid "``GFM`` for `Github-flavored Markdown `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:280 +msgid "``CommonMark`` for `CommonMark `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:299 +msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." +msgstr "" + +#: ../source/specifications/core-metadata.rst:303 +msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:307 +msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:311 +msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." +msgstr "" + +#: ../source/specifications/core-metadata.rst:320 +msgid "Keywords" +msgstr "" + +#: ../source/specifications/core-metadata.rst:324 +msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." +msgstr "" + +#: ../source/specifications/core-metadata.rst:333 +msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." +msgstr "" + +#: ../source/specifications/core-metadata.rst:341 +msgid "Home-page" +msgstr "" + +#: ../source/specifications/core-metadata.rst:345 +msgid "A string containing the URL for the distribution's home page." +msgstr "" + +#: ../source/specifications/core-metadata.rst:353 +msgid "Download-URL" +msgstr "" + +#: ../source/specifications/core-metadata.rst:357 +msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:366 +msgid "Author" +msgstr "" + +#: ../source/specifications/core-metadata.rst:370 +msgid "A string containing the author's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:383 +msgid "Author-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:387 +msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:395 +#: ../source/specifications/core-metadata.rst:442 +msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:405 +msgid "Maintainer" +msgstr "" + +#: ../source/specifications/core-metadata.rst:409 +msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:412 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:426 +msgid "Maintainer-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:430 +msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:434 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:452 +msgid "License" +msgstr "" + +#: ../source/specifications/core-metadata.rst:456 +msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." +msgstr "" + +#: ../source/specifications/core-metadata.rst:476 +msgid "Classifier (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:480 +msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:485 +#: ../source/specifications/core-metadata.rst:574 +#: ../source/specifications/core-metadata.rst:691 +#: ../source/specifications/core-metadata.rst:715 +msgid "This field may be followed by an environment marker after a semicolon." +msgstr "" + +#: ../source/specifications/core-metadata.rst:496 +msgid "Requires-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:499 +#: ../source/specifications/core-metadata.rst:561 +#: ../source/specifications/core-metadata.rst:663 +#: ../source/specifications/core-metadata.rst:704 +msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." +msgstr "" + +#: ../source/specifications/core-metadata.rst:503 +msgid "Each entry contains a string naming some other distutils project required by this distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:506 +msgid "The format of a requirement string contains from one to four parts:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:508 +msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." +msgstr "" + +#: ../source/specifications/core-metadata.rst:510 +msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." +msgstr "" + +#: ../source/specifications/core-metadata.rst:513 +msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:516 +msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." +msgstr "" + +#: ../source/specifications/core-metadata.rst:519 +msgid "See :pep:`508` for full details of the allowed format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:521 +msgid "The project names should correspond to names as found on the `Python Package Index`_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:524 +msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:538 +msgid "Requires-Python" +msgstr "" + +#: ../source/specifications/core-metadata.rst:542 +msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." +msgstr "" + +#: ../source/specifications/core-metadata.rst:546 +msgid "The value must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:548 +msgid "This field cannot be followed by an environment marker." +msgstr "" + +#: ../source/specifications/core-metadata.rst:558 +msgid "Requires-External (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:565 +msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:570 +msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:576 +msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." +msgstr "" + +#: ../source/specifications/core-metadata.rst:581 +msgid "Notice that there is no particular rule on the strings to be used." +msgstr "" + +#: ../source/specifications/core-metadata.rst:593 +msgid "Project-URL (multiple-use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:597 +msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." +msgstr "" + +#: ../source/specifications/core-metadata.rst:604 +msgid "The label is free text limited to 32 characters." +msgstr "" + +#: ../source/specifications/core-metadata.rst:612 +msgid "Provides-Extra (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:616 +msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." +msgstr "" + +#: ../source/specifications/core-metadata.rst:625 +msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:635 +msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." +msgstr "" + +#: ../source/specifications/core-metadata.rst:639 +msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:644 +msgid "Rarely Used Fields" +msgstr "" + +#: ../source/specifications/core-metadata.rst:646 +msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:651 +msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." +msgstr "" + +#: ../source/specifications/core-metadata.rst:660 +msgid "Provides-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:667 +msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:672 +msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:679 +msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:687 +msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." +msgstr "" + +#: ../source/specifications/core-metadata.rst:701 +msgid "Obsoletes-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:708 +msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." +msgstr "" + +#: ../source/specifications/core-metadata.rst:712 +msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:717 +msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:730 +msgid "reStructuredText markup: http://docutils.sourceforge.net/" +msgstr "" + +#: ../source/specifications/core-metadata.rst:735 +msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:6 +msgid "Declaring build system dependencies" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:8 +msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:5 +msgid "Declaring project metadata" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:7 +msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:12 +msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:18 +msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:27 +msgid "The only fields required to be statically defined are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:29 +#: ../source/specifications/declaring-project-metadata.rst:41 +msgid "``name``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:31 +msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:34 +#: ../source/specifications/declaring-project-metadata.rst:54 +msgid "``version``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:36 +msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:43 +#: ../source/specifications/declaring-project-metadata.rst:56 +#: ../source/specifications/declaring-project-metadata.rst:68 +#: ../source/specifications/declaring-project-metadata.rst:117 +msgid "TOML_ type: string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:44 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:47 +msgid "The name of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:49 +msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:57 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:60 +msgid "The version of the project as supported by :pep:`440`." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:62 +msgid "Users SHOULD prefer to specify already-normalized versions." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:66 +msgid "``description``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:69 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:72 +msgid "The summary description of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:76 +msgid "``readme``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:78 +msgid "TOML_ type: string or table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:79 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:83 +msgid "The full description of the project (i.e. the README)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:85 +msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:96 +msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:103 +msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:115 +msgid "``requires-python``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:118 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:121 +msgid "The Python version requirements of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:125 +msgid "``license``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:127 +msgid "TOML_ type: table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:128 +msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:131 +msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:140 +msgid "``authors``/``maintainers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:142 +msgid "TOML_ type: Array of inline tables with string keys and values" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:143 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:149 +msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:154 +msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:157 +msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:163 +msgid "Using the data to fill in :ref:`core metadata ` is as follows:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:166 +msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:169 +msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:173 +msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:177 +msgid "Multiple values should be separated by commas." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:181 +msgid "``keywords``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:183 +#: ../source/specifications/declaring-project-metadata.rst:193 +msgid "TOML_ type: array of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:184 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:187 +msgid "The keywords for the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:191 +msgid "``classifiers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:194 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:197 +msgid "Trove classifiers which apply to the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:201 +msgid "``urls``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:203 +msgid "TOML_ type: table with keys and values of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:204 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:207 +msgid "A table of URLs where the key is the URL label and the value is the URL itself." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:212 +msgid "Entry points" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:214 +msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:216 +msgid ":ref:`Entry points specification `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:218 +msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:224 +msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:228 +msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:234 +msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:242 +msgid "``dependencies``/``optional-dependencies``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:244 +msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:247 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:251 +msgid "The (optional) dependencies of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:253 +msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:258 +msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:269 +msgid "``dynamic``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:271 +msgid "TOML_ type: array of string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:272 +msgid "A corresponding :ref:`core metadata ` field does not exist" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:275 +msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:281 +msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:283 +msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:285 +msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:290 +msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:294 +msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:296 +msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:300 +msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:6 +msgid "Dependency specifiers" +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:8 +msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:11 +msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." +msgstr "" + +#: ../source/specifications/direct-url.rst:6 +msgid "Recording the Direct URL Origin of installed distributions" +msgstr "" + +#: ../source/specifications/direct-url.rst:8 +msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." +msgstr "" + +#: ../source/specifications/direct-url.rst:17 +msgid "Specification" +msgstr "" + +#: ../source/specifications/direct-url.rst:19 +msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/direct-url.rst:23 +#: ../source/specifications/recording-installed-packages.rst:206 +msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." +msgstr "" + +#: ../source/specifications/direct-url.rst:26 +msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." +msgstr "" + +#: ../source/specifications/direct-url.rst:29 +msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." +msgstr "" + +#: ../source/specifications/direct-url.rst:36 +msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." +msgstr "" + +#: ../source/specifications/direct-url.rst:39 +msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" +msgstr "" + +#: ../source/specifications/direct-url.rst:45 +msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." +msgstr "" + +#: ../source/specifications/direct-url.rst:49 +msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" +msgstr "" + +#: ../source/specifications/direct-url.rst:52 +msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." +msgstr "" + +#: ../source/specifications/direct-url.rst:58 +msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." +msgstr "" + +#: ../source/specifications/direct-url.rst:61 +msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." +msgstr "" + +#: ../source/specifications/direct-url.rst:68 +msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:71 +msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." +msgstr "" + +#: ../source/specifications/direct-url.rst:78 +msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:81 +msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." +msgstr "" + +#: ../source/specifications/direct-url.rst:84 +msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." +msgstr "" + +#: ../source/specifications/direct-url.rst:91 +msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." +msgstr "" + +#: ../source/specifications/direct-url.rst:96 +msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." +msgstr "" + +#: ../source/specifications/direct-url.rst:102 +msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." +msgstr "" + +#: ../source/specifications/direct-url.rst:110 +msgid "Registered VCS" +msgstr "" + +#: ../source/specifications/direct-url.rst:112 +msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." +msgstr "" + +#: ../source/specifications/direct-url.rst:122 +msgid "Git" +msgstr "" + +#: ../source/specifications/direct-url.rst:124 +#: ../source/specifications/direct-url.rst:156 +#: ../source/specifications/direct-url.rst:179 +#: ../source/specifications/direct-url.rst:202 +msgid "Home page" +msgstr "" + +#: ../source/specifications/direct-url.rst:126 +msgid "https://git-scm.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:128 +#: ../source/specifications/direct-url.rst:160 +#: ../source/specifications/direct-url.rst:183 +#: ../source/specifications/direct-url.rst:206 +msgid "vcs command" +msgstr "" + +#: ../source/specifications/direct-url.rst:130 +#: ../source/specifications/direct-url.rst:134 +msgid "git" +msgstr "" + +#: ../source/specifications/direct-url.rst:132 +#: ../source/specifications/direct-url.rst:164 +#: ../source/specifications/direct-url.rst:187 +#: ../source/specifications/direct-url.rst:210 +msgid "``vcs`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:136 +#: ../source/specifications/direct-url.rst:168 +#: ../source/specifications/direct-url.rst:191 +#: ../source/specifications/direct-url.rst:214 +msgid "``requested_revision`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:138 +msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." +msgstr "" + +#: ../source/specifications/direct-url.rst:141 +#: ../source/specifications/direct-url.rst:172 +#: ../source/specifications/direct-url.rst:195 +#: ../source/specifications/direct-url.rst:219 +msgid "``commit_id`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:143 +msgid "A commit hash (40 hexadecimal characters sha1)." +msgstr "" + +#: ../source/specifications/direct-url.rst:147 +msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." +msgstr "" + +#: ../source/specifications/direct-url.rst:154 +msgid "Mercurial" +msgstr "" + +#: ../source/specifications/direct-url.rst:158 +msgid "https://www.mercurial-scm.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:162 +#: ../source/specifications/direct-url.rst:166 +msgid "hg" +msgstr "" + +#: ../source/specifications/direct-url.rst:170 +msgid "A tag name, branch name, changeset ID, shortened changeset ID." +msgstr "" + +#: ../source/specifications/direct-url.rst:174 +msgid "A changeset ID (40 hexadecimal characters)." +msgstr "" + +#: ../source/specifications/direct-url.rst:177 +msgid "Bazaar" +msgstr "" + +#: ../source/specifications/direct-url.rst:181 +msgid "https://bazaar.canonical.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:185 +#: ../source/specifications/direct-url.rst:189 +msgid "bzr" +msgstr "" + +#: ../source/specifications/direct-url.rst:193 +msgid "A tag name, branch name, revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:197 +msgid "A revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:200 +msgid "Subversion" +msgstr "" + +#: ../source/specifications/direct-url.rst:204 +msgid "https://subversion.apache.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:208 +#: ../source/specifications/direct-url.rst:212 +msgid "svn" +msgstr "" + +#: ../source/specifications/direct-url.rst:216 +msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." +msgstr "" + +#: ../source/specifications/direct-url.rst:221 +msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." +msgstr "" + +#: ../source/specifications/direct-url.rst:229 +msgid "Example direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:231 +msgid "Source archive:" +msgstr "" + +#: ../source/specifications/direct-url.rst:242 +msgid "Git URL with tag and commit-hash:" +msgstr "" + +#: ../source/specifications/direct-url.rst:255 +msgid "Local directory:" +msgstr "" + +#: ../source/specifications/direct-url.rst:264 +msgid "Local directory installed in editable mode:" +msgstr "" + +#: ../source/specifications/direct-url.rst:277 +msgid "Example pip commands and their effect on direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:279 +msgid "Commands that generate a ``direct_url.json``:" +msgstr "" + +#: ../source/specifications/direct-url.rst:281 +msgid "pip install https://example.com/app-1.0.tgz" +msgstr "" + +#: ../source/specifications/direct-url.rst:282 +msgid "pip install https://example.com/app-1.0.whl" +msgstr "" + +#: ../source/specifications/direct-url.rst:283 +msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" +msgstr "" + +#: ../source/specifications/direct-url.rst:284 +msgid "pip install ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:285 +msgid "pip install file:///home/user/app" +msgstr "" + +#: ../source/specifications/direct-url.rst:286 +msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" +msgstr "" + +#: ../source/specifications/direct-url.rst:290 +msgid "pip install -e ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:292 +msgid "Commands that *do not* generate a ``direct_url.json``" +msgstr "" + +#: ../source/specifications/direct-url.rst:294 +msgid "pip install app" +msgstr "" + +#: ../source/specifications/direct-url.rst:295 +msgid "pip install app --no-index --find-links https://example.com/" +msgstr "" + +#: ../source/specifications/entry-points.rst:5 +msgid "Entry points specification" +msgstr "" + +#: ../source/specifications/entry-points.rst:7 +msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" +msgstr "" + +#: ../source/specifications/entry-points.rst:11 +msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." +msgstr "" + +#: ../source/specifications/entry-points.rst:14 +msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." +msgstr "" + +#: ../source/specifications/entry-points.rst:19 +msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." +msgstr "" + +#: ../source/specifications/entry-points.rst:28 +msgid "Data model" +msgstr "" + +#: ../source/specifications/entry-points.rst:30 +msgid "Conceptually, an entry point is defined by three required properties:" +msgstr "" + +#: ../source/specifications/entry-points.rst:32 +msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:42 +msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:51 +msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:64 +msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." +msgstr "" + +#: ../source/specifications/entry-points.rst:68 +msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." +msgstr "" + +#: ../source/specifications/entry-points.rst:73 +msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." +msgstr "" + +#: ../source/specifications/entry-points.rst:80 +msgid "File format" +msgstr "" + +#: ../source/specifications/entry-points.rst:82 +msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." +msgstr "" + +#: ../source/specifications/entry-points.rst:87 +msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:97 +msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:100 +msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." +msgstr "" + +#: ../source/specifications/entry-points.rst:104 +msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." +msgstr "" + +#: ../source/specifications/entry-points.rst:112 +msgid "For example::" +msgstr "" + +#: ../source/specifications/entry-points.rst:124 +msgid "Use for scripts" +msgstr "" + +#: ../source/specifications/entry-points.rst:126 +msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." +msgstr "" + +#: ../source/specifications/entry-points.rst:134 +msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:141 +msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." +msgstr "" + +#: ../source/specifications/entry-points.rst:149 +msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." +msgstr "" + +#: ../source/specifications/entry-points.rst:154 +msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." +msgstr "" + +#: ../source/specifications/index.rst:4 +msgid "PyPA specifications" +msgstr "" + +#: ../source/specifications/index.rst:6 +msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." +msgstr "" + +#: ../source/specifications/index.rst:13 +msgid "Package Distribution Metadata" +msgstr "" + +#: ../source/specifications/index.rst:30 +msgid "Package Distribution File Formats" +msgstr "" + +#: ../source/specifications/index.rst:40 +msgid "Package Index Interfaces" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:6 +msgid "Platform compatibility tags" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:8 +msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:12 +msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:16 +msgid "Platform tags for Windows" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:18 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:22 +msgid "Platform tags for macOS (Mac OS X)" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:24 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:28 +msgid "Platform tags for common Linux distributions" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:32 +msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:36 +msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:41 +msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:44 +msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:46 +msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:49 +msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:54 +msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:59 +msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:65 +msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:71 +msgid "Manylinux compatibility support" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:74 +msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:76 +msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:79 +msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "Tool" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux1``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2010``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2014``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux_x_y``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=8.1.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=20.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "auditwheel" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=1.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=2.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.3.0`` [#]_" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:90 +msgid "Platform tags for other \\*nix platforms" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:92 +msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:98 +msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" +msgstr "" + +#: ../source/specifications/pypirc.rst:6 +msgid "The :file:`.pypirc` file" +msgstr "" + +#: ../source/specifications/pypirc.rst:8 +msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." +msgstr "" + +#: ../source/specifications/pypirc.rst:13 +msgid "The format (originally defined by the :ref:`distutils` package) is:" +msgstr "" + +#: ../source/specifications/pypirc.rst:32 +msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:35 +msgid "Each section describing a repository defines three fields:" +msgstr "" + +#: ../source/specifications/pypirc.rst:37 +msgid "``repository``: The URL of the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:38 +msgid "``username``: The registered username on the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:39 +msgid "``password``: The password that will used to authenticate the username." +msgstr "" + +#: ../source/specifications/pypirc.rst:43 +msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." +msgstr "" + +#: ../source/specifications/pypirc.rst:47 +msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" +msgstr "" + +#: ../source/specifications/pypirc.rst:57 +msgid "Common configurations" +msgstr "" + +#: ../source/specifications/pypirc.rst:61 +msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." +msgstr "" + +#: ../source/specifications/pypirc.rst:66 +msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" +msgstr "" + +#: ../source/specifications/pypirc.rst:82 +msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." +msgstr "" + +#: ../source/specifications/pypirc.rst:86 +msgid "Using a PyPI token" +msgstr "" + +#: ../source/specifications/pypirc.rst:88 +msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" +msgstr "" + +#: ../source/specifications/pypirc.rst:97 +msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." +msgstr "" + +#: ../source/specifications/pypirc.rst:103 +msgid "Using another package index" +msgstr "" + +#: ../source/specifications/pypirc.rst:105 +msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" +msgstr "" + +#: ../source/specifications/pypirc.rst:132 +msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:5 +msgid "Recording installed projects" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:7 +msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:12 +msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:21 +msgid "History and change workflow" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:23 +msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:29 +msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:37 +msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:41 +msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:50 +msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:60 +msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:69 +msgid "This ``.dist-info`` directory can contain these files, described in detail below:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:72 +msgid "``METADATA``: contains project metadata" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:73 +msgid "``RECORD``: records the list of installed files." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:74 +msgid "``INSTALLER``: records the name of the tool used to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:76 +msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:82 +msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:87 +msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:94 +msgid "The METADATA file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:96 +msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:99 +msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:105 +msgid "The RECORD file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:107 +msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:110 +msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:113 +msgid "field delimiter: ``,`` (comma)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:114 +msgid "quoting char: ``\"`` (straight double quote)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:115 +msgid "line terminator: either ``\\r\\n`` or ``\\n``." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:117 +msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:120 +msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:125 +msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:130 +msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:133 +msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:139 +msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:146 +msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:151 +msgid "Here is an example snippet of a possible ``RECORD`` file::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:170 +msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:177 +msgid "The INSTALLER file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:179 +msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:185 +msgid "The file can be terminated by zero or more ASCII whitespace characters." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:187 +msgid "Here are examples of two possible ``INSTALLER`` files::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:195 +msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:201 +msgid "The direct_url.json file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:203 +msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:209 +msgid "Its detailed specification is at :ref:`direct-url`." +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:6 +msgid "Simple repository API" +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:8 +msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:6 +msgid "Source distribution format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:8 +msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:13 +msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:21 +msgid "Source distributions are also known as *sdists* for short." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:24 +msgid "Source distribution file name" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:26 +msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:31 +msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:35 +msgid "Source distribution file format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:37 +msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:45 +msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:48 +msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:6 +msgid "Version specifiers" +msgstr "" + +#: ../source/specifications/version-specifiers.rst:8 +msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:11 +msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." +msgstr "" + +#: ../source/support.rst:3 +msgid "How to Get Support" +msgstr "" + +#: ../source/support.rst:5 +msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." +msgstr "" + +#: ../source/support.rst:8 +msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:5 +msgid "Creating Documentation" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:7 +msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:13 +msgid "Installing Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:14 +msgid "Use ``pip`` to install Sphinx:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:28 +msgid "For other installation methods, see this `installation guide`_ by Sphinx." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:33 +msgid "Getting Started With Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:35 +msgid "Create a ``docs`` directory inside your project to hold your documentation:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:42 +msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:49 +msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:51 +msgid "You can add some information about your project in ``index.rst``, then build them:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:57 +msgid "For more details on the build process, see this `guide`_ by Read The Docs." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:62 +msgid "Other Sources" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:64 +msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/index.rst:4 +msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:5 +msgid "Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:7 +msgid "This section covers the basics of how to install Python :term:`packages `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:10 +msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:28 +msgid "Requirements for Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:30 +msgid "This section describes the steps to follow before installing other Python packages." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:35 +msgid "Ensure you can run Python from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:37 +msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:53 +msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:57 +msgid "If you're a newcomer and you get an error like this:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:66 +msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:72 +msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:82 +msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:87 +msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:99 +msgid "Ensure you can run pip from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:101 +msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:116 +msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:124 +msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:139 +msgid "If that still doesn't allow you to run ``python -m pip``:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:141 +msgid "Securely Download `get-pip.py `_ [1]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:144 +msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:150 +msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:159 +msgid "Ensure pip, setuptools, and wheel are up to date" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:161 +msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:169 +msgid "Optionally, create a virtual environment" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:171 +msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:188 +msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:195 +msgid "Creating Virtual Environments" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:197 +msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:203 +msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:209 +msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:213 +msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:216 +msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:220 +msgid "Currently, there are two common tools for creating Python virtual environments:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:222 +msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:225 +msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:230 +msgid "The basic usage is like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:232 +msgid "Using `venv`_:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:248 +msgid "Using :ref:`virtualenv`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:264 +msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:266 +msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:271 +msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:281 +msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:288 +msgid "Use pip for Installing" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:290 +msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:297 +msgid "Installing from PyPI" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:299 +msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:307 +msgid "To install the latest version of \"SomeProject\":" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:321 +msgid "To install a specific version:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:335 +msgid "To install greater than or equal to one version and less than another:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:350 +msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:365 +msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:370 +msgid "Source Distributions vs Wheels" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:372 +msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:378 +msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:383 +msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:391 +msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:408 +msgid "Installing to the User Site" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:410 +msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:425 +msgid "For more information see the `User Installs `_ section from the pip docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:429 +msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:432 +msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:440 +msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:446 +msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:462 +msgid "Install a list of requirements specified in a :ref:`Requirements File `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:478 +msgid "Installing from VCS" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:480 +msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:502 +msgid "Installing from other Indexes" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:504 +msgid "Install from an alternate index" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:518 +msgid "Search an additional index during install, in addition to :term:`PyPI `" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:534 +msgid "Installing from a local src tree" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:537 +msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:554 +msgid "You can also install normally from src" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:571 +msgid "Install a particular source archive file." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:585 +msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:605 +msgid "Installing from other sources" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:607 +msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:619 +msgid "Installing Prereleases" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:621 +msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:637 +msgid "Installing Setuptools \"Extras\"" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:639 +msgid "Install `setuptools extras`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:659 +msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:668 +msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:673 +msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:4 +msgid "Managing Application Dependencies" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:6 +msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:9 +msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:13 +msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:17 +msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:24 +msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:30 +msgid "Installing Pipenv" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:32 +msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:38 +msgid "Use ``pip`` to install Pipenv:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:54 +msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:65 +msgid "Installing packages for your project" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:67 +msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:76 +msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:112 +msgid "Using installed packages" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:114 +msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:125 +msgid "Then you can run this script using ``pipenv run``:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:131 +msgid "You should get output similar to this:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:137 +msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:143 +#: ../source/tutorials/packaging-projects.rst:594 +msgid "Next steps" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:145 +msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:148 +msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:151 +msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:160 +msgid "Other Tools for Application Dependency Management" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:162 +msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:166 +msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:172 +msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:175 +msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:177 +msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:2 +msgid "Packaging Python Projects" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:4 +msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:10 +msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:18 +msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:35 +msgid "A simple project" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:37 +msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:41 +msgid "Create the following file structure locally:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:51 +msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:54 +msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:63 +msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:67 +msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:75 +msgid "Creating the package files" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:77 +msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:95 +msgid "Creating a test directory" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:97 +msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:101 +msgid "Creating pyproject.toml" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:103 +msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:117 +msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:121 +msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:127 +msgid "See :pep:`517` and :pep:`518` for background and details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:131 +msgid "Configuring metadata" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:133 +msgid "There are two types of metadata: static and dynamic." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:135 +msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:137 +msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:141 +msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:148 +msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:153 +msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:185 +msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:191 +#: ../source/tutorials/packaging-projects.rst:286 +msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:196 +msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:199 +#: ../source/tutorials/packaging-projects.rst:293 +msgid "``author`` and ``author_email`` are used to identify the author of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:201 +#: ../source/tutorials/packaging-projects.rst:295 +msgid "``description`` is a short, one-sentence summary of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:202 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:206 +#: ../source/tutorials/packaging-projects.rst:300 +msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:208 +#: ../source/tutorials/packaging-projects.rst:302 +msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:211 +#: ../source/tutorials/packaging-projects.rst:305 +msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:213 +#: ../source/tutorials/packaging-projects.rst:307 +msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:221 +msgid "In the ``options`` category, we have controls for setuptools itself:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:223 +msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:227 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:234 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:238 +#: ../source/tutorials/packaging-projects.rst:329 +msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:244 +msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:248 +msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:283 +msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:291 +msgid "``version`` is the package version. See :pep:`440` for more details on versions." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:296 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:314 +msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:319 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:325 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:333 +msgid "Creating README.md" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:335 +msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:347 +msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:354 +msgid "Creating a LICENSE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:356 +msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:387 +msgid "Including other files" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:389 +msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:393 +msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:402 +msgid "Generating distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:404 +msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:408 +msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:422 +msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:425 +msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:439 +msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:449 +msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:458 +msgid "Uploading the distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:460 +msgid "Finally, it's time to upload your package to the Python Package Index!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:462 +msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:470 +msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:477 +msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:492 +msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:506 +msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:510 +msgid "After the command completes, you should see output similar to this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:523 +msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:528 +msgid "Installing your newly uploaded package" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:530 +msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:546 +msgid "Make sure to specify your username in the package name!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:548 +msgid "pip should install the package from TestPyPI and the output should look something like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:558 +msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:565 +msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:580 +msgid "and import the package:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:588 +msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:596 +msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:599 +msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:604 +msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:608 +msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:610 +msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:613 +msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:617 +msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:619 +msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:622 +msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:624 +msgid "Read about :doc:`/guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:625 +msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." +msgstr "" From 7ed0959d8f4f5b5c2fbe13ab210fb642d11c7b61 Mon Sep 17 00:00:00 2001 From: bluewindde <13548563428@139.com> Date: Sun, 29 Aug 2021 18:15:45 +0200 Subject: [PATCH 0102/1072] Translated using Weblate (Chinese (Simplified)) Currently translated at 24.7% (563 of 2271 strings) Co-authored-by: bluewindde <13548563428@139.com> Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hans/ Translation: pypa/packaging.python.org --- locales/zh_Hans/LC_MESSAGES/messages.po | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po index 5cec4fa65..65b87a626 100644 --- a/locales/zh_Hans/LC_MESSAGES/messages.po +++ b/locales/zh_Hans/LC_MESSAGES/messages.po @@ -3,13 +3,14 @@ # This file is distributed under the same license as the Python Packaging User Guide package. # meowmeowmeowcat , 2021. # Zuorong Zhang , 2021. +# bluewindde <13548563428@139.com>, 2021. msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" "PO-Revision-Date: 2021-08-22 15:34+0000\n" -"Last-Translator: meowmeowmeowcat \n" +"Last-Translator: bluewindde <13548563428@139.com>\n" "Language-Team: Chinese (Simplified) \n" "Language: zh_Hans\n" @@ -969,6 +970,8 @@ msgid "" "format, although :pep:`this is not officially supported at this time <427#is-" "it-possible-to-import-python-code-directly-from-a-wheel-file>`." msgstr "" +"在某些情况下，控制盘可以用作可导入的运行时格式，尽管：pep:`目前还没有正式支持这一格式 <427#is-it-mable-to-import-" +"python-code-directly-from-a-wheel-file>`。" #: ../source/glossary.rst:3 msgid "Glossary" @@ -982,7 +985,7 @@ msgstr "二进制分布 （Binary Distribution）" msgid "" "A specific kind of :term:`Built Distribution` that contains compiled " "extensions." -msgstr "" +msgstr "一种特定的术语：`Build Distribution'，包含编译的扩展。" #: ../source/glossary.rst:14 msgid "Built Distribution" @@ -998,6 +1001,11 @@ msgid "" "not imply that Python files have to be precompiled (:term:`Wheel` " "intentionally does not include compiled Python files)." msgstr "" +"一个term:`Distribution < Distribution Package >` " +"格式包含只需要移动到目标系统上正确位置的文件和元数据，即可安装。:term:` Wheel ` 是这样一种格式，而 distutil 的 :term:` " +"Source Distribution < Source Distribution (or \"sdist\")>` " +"不是，因为它需要一个构建步骤才能安装。 这种格式并不意味着必须预编译 Python 文件（:term:` Wheel ` 故意不包括编译的 " +"Python 文件）。" #: ../source/glossary.rst:26 msgid "Distribution Package" From 3de836860a35ebb7e88485cd13dfc6b6a844986e Mon Sep 17 00:00:00 2001 From: Adolfo Jayme Barrientos Date: Sun, 29 Aug 2021 18:15:45 +0200 Subject: [PATCH 0103/1072] Translated using Weblate (Spanish) Currently translated at 8.0% (183 of 2271 strings) Co-authored-by: Adolfo Jayme Barrientos Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/es/ Translation: pypa/packaging.python.org --- locales/es/LC_MESSAGES/messages.mo | Bin 10456 -> 15012 bytes locales/es/LC_MESSAGES/messages.po | 78 +++++++++++++++++++---------- 2 files changed, 51 insertions(+), 27 deletions(-) diff --git a/locales/es/LC_MESSAGES/messages.mo b/locales/es/LC_MESSAGES/messages.mo index d5075fc17fa18a3cd4a29ce418b69d0a7ac6fd15..9be893d89836f8ff008517ffc8087c59d20c36c3 100644 GIT binary patch literal 15012 zcmb`Nd5|1eeaG9zT*AgkCLHE!+r*ZZ-H|NWMvMp1_R6zw&0g4ckP@yn5#QA*R zdp$F&T{)Fhy7cs&?tcA_-~Ic&{l=E_KHzbEl=foUc~AAc$HDJElmEE>{sPZCAN(r# zEb!alOTiz4&j&X@+w-0QZUZ-gJHcDP>%r%M9|WHZeggEtFM#U*bx{4k4ZaBccZU~T zXusbEK8@#Z0e=pB2dHs=3)J_Y1786C5%@yzZ^4Vfe*62DPpj)Vu|#@9zQG zn)e}xA9wf=sCm8wYX6VA=RW{{p8KDHyTHqsRCG8B^2oa#d=$JB6#b?k%FDn*AdkER z6zksV?%xHnRPU6-2SNUMf69OA|26O>;13+0&*Jrb4176w19&;u0JYwCg4@6kgPQ*l z@DlJZ!Sld>bEo&Y89&t{URgRcO!?_J;w zI0I_D_kimE04TmZ42qur0E!k-VAEI`#`PhG^l=m4DJEH0?vaMF`4d{ zz-z!yg0BU?>2Mc|{51D(0~f%nV1o4gZcu#v1Sq-r6e#)nqI>^kQ0x32sCE1VWJvFP zKGyoSf}-yvDEjUP)&Dk7bdJFg{2aInUW_oS|NB7ozYo;7p9V$GFM^WC?}M7>A|IIm zw}X1V3)~034ivqA2iyUE8AKGl{{*iBw;*f`;mv>_I>+-`pycBTghhD%W!NzAg`oI; z6ck_H2ukkX4laZDf}+b$9bSkq?BxFCpy+heVE}5r;|}ium$-ib)PA=x39Rxi2G#Fs zP~RU05moOF5E1cKK_9#qydC_kd%u~@Yu($x3GfA9weUfa?EUhd%WlQ4ff_zaAyDi5CaC>>7nGfQ z4Aedz2Q}U%2JQuqgOcaZf*SYFK&|7)pzPC2D|UaApycUJkbmCW`47?Z9s;$l zuYy{~KZA&l_k4)*D)2gxp}ZAP{P-9sdHMrT{T>BHuOEZj_qi2pU-`Ieig@Q;Y3X`7h{}3XAVYc$P~W{DgvH+HLCy0mQ0spjls>%-<#;-H z8~98x1fK&Y;Dz8_py>2oa0~b`(Ch;gT^>EQ2YA{ z_zdtR2!Zx-IjHZi0ky74Fb6*ZcEHWMEgkLxHQwEz_IV0~RNfarw&wi+6kRWY$xi`i zK*`O`;4NSZs^6DE>C=CK;@eeKYv*nP#s4>f=Yaa=%uD;w^+8(8{IWdU!tWQ-B)__( z{~KLz=i!2TF$`<^myOSn9y`RR?%pL&4OQ9~&kL`H(>1O28{*Ji& zn?T9sYutSaAK*tulMI|k6AjAiE`B_}ym2TRi_gC_@?7#UdOejJ@%SAh4_Do9>B8AA z*#}+XpHDkP`v^_fk_Gese*S-#yFcdeR~(K)j~nTXu9zly(2=^X_6mZziz?&KhOUk9l6)fi)kMkd6w{7GFD!D_;G`~k?!bv5AD6Qx6<~}bRD)} z?Ah)7zK14VEZpw(Q&QTqX&2C@XkFUt zXun4LFzr`q(!KJ!ksoiMO}hs*@GAFPAUk>+?NZv)X)mGas?$(k?_L_}Zmts!rL)hY z-AY@eJ(u=QTAQ|;c7S$1?X|RL(sbQy!FwC{G}?A|FSv;Ii?l#D?m7y-fc8e(W?D$w zLDThm3&a1%#`c9lGwQUmu`zFK>|oKZhpGL2I1By2Z-t#^m`-%UB2RIdBkAO6R4>dX9DUxv)Q4x@ zFz)w~;)*n6+%D^d5WHVX;y76~WSm>rdqw8g_9V^FPnP^WNvByf^4cADRJ=V&T(mnt zyPb42$5PZPL@CzBQ+umTw!=JV26>=|EIv1H?SdSUqs(s=ut7am=wY@ObeeqHSPnW- zL!T5pXS9-YLu&1T*DyZtYqe(5$Z9pe8KrC{fm{)^V(Dx$6|cn;?Ql7XoAx1J6m6z7 z>#ll(u{z;u`2kyXGaw_4h89vjk)&B_X=#!Hf&HjZS9A(Br_* z!z>@JdibW>bBnIzNjn}s*SsYmG;8Kf84^IUJZgvDRG2l=s4GHxQ&H9^G9xnHng#fI zud6SU&K0?YsTD$-W#nI@&-LcwG@LhpLQJG)hp z>R17x0_H0k%R*-In@Po+?qnjlZX43fqEqf*DNWjDM=ZIm)yGjM+^9d6!9Ppq6M>XE z^QKY0RJz;@yRt%^M#R&-V!JgR-d=Rlk#1+@m7}-2Dp#$&z1rM{cI;}^n+bCx;0t+> zN)eAn`Le&zU5+{@2JbRhRCK)=nWq3LZiii2vBUERv;a%@Qew(p*>aLXGwnQqf{?fr zjg7vM8fM-;sej_LB!8jkb{W9i-+>Kj9>KmK9ruriVOK^IF+k=dHDW*V?svmP7I1Yr z@e2&Lqed2@>&sy~3*(hA6YE%KD-GIhtb4^@MC1Zz^<-%B<C6c9lRifDpSHf5(J*%)KWP-KkAwRQRi#Gy* z00pt(G-ieUg(u4QMubaVyKlm@d@BK+vyLTO^DIJIRz{yVwz?7YotaqfV6>Zgcx2DQ zx@QTbO#S^@8r(W_82h&LHY0DH$yoD6`D~pqj1FrQ8j~3J5I^}S)U=Ro?vWoQjZuCYLm<5@b1#dSb)kd97^x|)w z4H`b2zJ;|q_uY{w%oTM6#aCE?O|-Werm}^TIwMZvW!gopAqInOHRg^R{>Zv z!MezNv8HZ}Co8Fqu%Yo8M$c|7@H-|Pm4!mCM98ZD`pa&+gK>BOmy$BMtE5KKt07i1a&CA z5)sAZdAGWKyNQ;?=<4nrJ9gNqU6SGgPLy;Yy-Au~;==+wdO(X4v;?JG4SH;r_&$ug zK9S=%;-KgOA=5&LDQdNf7CI4imXbA@g2F}(k4Ms`h+K@0jk|!U&USgz#9~L<1PPKG zv7{OwXN+vtv7~%M^DsSTWi;%!Q8%=Jccn4%yVgVz2pwGx3AEA#izRiG$_6fnG&>vR z6QK*%&+j7rh7UnkAEuE~f%S8Wq!1t@1;Selwq=FGcvVr(<$m=LbE4qKI90901{F^7 zMucvt^}%pI&elO8ys7yQdnxlz)NEp?%v&r-(4rvDJf-zDlbF}Eg3?6T7^$k)OGWHU zo)v8$HgpNl0W5c(91lC?BP_V0BDXfiQQ&5~yD^7ROXeMMUh{~H3#Lcnf+I=PK(G|q zqIaI*iCH1RgM_B^7wwP$*~CWJEE125T*in2r3Xi_+=LTxbUduuah#z)gB%KI2Rz8} z&7?=oCM5&Q9-NJaB)T1Ax-s?Ej1mUw4W>RpM$k@@X2s63iggp$hH><`GE-O9&|A!j zL@@AI%w`qBlj$1~3P`%8og%<84liakgv}j4S~3~da-j4BUDo_TCtEeqbm{k1hABl? z3MFrHl!&WU_2)*cyL;pujQqobbuc%}!AzRG&pDW~>rgi2U^F>INaaP0zi{2w_=^^M zl)tz&%)HuM66V;%>tt~iQ>*1J}#8o9NhY)E0KZOR~; zT8!2FreadctX?>KP+_3b=4%{hTTI?#$`FIHNUdf)!I`tg*bf=Cq3{}uq=AWfimnkY z#Bt{NG#@HIoS4m8QFG$PqLoc7CRKma+@T3Y9*RsS zRGg^#w@y#aPs|>gn40wW9jeamf5qz#9h}~z^kHH#MU03t6IQVI@PPyV!O7Wa|GMef z$^8djGdVRiKfSPU16@00s-ih7A ze%j9xRmy2nOyhn0-SsHnG#67LizoIHOcObFy5=^!e&@Bm{ds-IzvO!V%4;{>GBFd9 z8Ci-PwHxxUs_d>@IY9=yiNfe&|8!o&iK~+KA0{n!H-~Y;vR{Nqc=0GsWIKs(Dbl3+ z)#~5R&`E}1bwZL1QUc@}MKx8_X~jGBK-DPxJzbl`&X@^;EG$4As@Fy})x)X}Fg%6@ zqQiJhIUleHr4DSwmQ@o88&y(_T|4kyZFMCX_YopLJQk9VbHi6b+E|WO)ZL$-oAu3) z$+^Xfr-{;}rve|&j1mmRN`hPhx{N&$TQ?B7K;@drPX822gwtb?7~`o-G)P8rsPThVzP^f0Z60*SAA7gXyf-Lhw&!kLEI8y!&!+x zsJ=qlkSHJx(*7x}lJXW7MO+fmo68ZeFtt=*`wupwmZ1WcL`B$uDy-d@PnDJ;rK!i7 zDyyx;iViFpTOKL%g&>G=`Kte*LI6VqXNVH>o~=aeSpu(;agW(0MU>r({%JEfj=+uF zQ+>97iu!C|zYWrLWTqZuX{_RgNi#jflONBC8p`{E|pFT%j_k+AXPXfq=7otpWP8BU_~z^t ztuGDAvab1xn>tpGKq?|u++c+V6F-S{xM9SJO=Ht35J9RLpOq@OEpcC>2>#@eR;%%nr2+ zESq6+JIdM;0%9SGg%Wxz{>WT6HK#n(?dpV~&;!F@kJ$Y6@0oIH#|>1)!y9DFj6I+OR4Y6cy}p3n1raT5ziGyPa!RK9-)!%#;6)y zl|faJm}PYPrP{)6x|sbfb%1*|gk%oBJEhLd^H#Jux}@3m5+c;X#`#XCqRJFW68HaxR3A$N8X z*>g0LVI+63i>osT0-4BQsG5u^!ERUl1IUmqCzD~aouLWC>yZ)m7z7)D<=|uL8zfOk zl|-E*HdT|O0F#i7Yh77_3uU?>O*t6T4AO`+p}Oomjb%?5y7=^v%j`KY2eSVMzx3%;BDFza=3=WvqN52AQB? z?TQ#e?=006>?`CUl|#UBgZ=wr&eH;(E0RT8yvhD&ILzdOIH)6Oej`>gBnfr`iJ*>5 zMx_e>PGvv|l{bTEX%tb&#v|o15+m^}Fx79vODf!LR1PKXKX@XNj2eYk;d^?mDRdjO z5f#-3mk#npnZH|+_4Wob#H8OVHrzACapN;(QBx${)yS!fYilLR?H#E#`X%GbD??LE zYU_Wop(B=p+9!f?j8oKsfZNRv13pzw6n(6hYF9C5a}0C#Zo>*X{bIlWE~{I7Q;LQ0 zrDZHQaJO2SlowX41f7%ED3aU=-;>ySf#uzxJGL6mBbG7~WFK9*LlM5Lx*IxKhZ&^X z)^SejaZ*_p^}K0L*b z?KC8+i5_jSo>>d|%P0Mk@Qh0RNX6cYu-QtfdwU$`4f{w65T*XZD&;4xq(8Jw@}Xyj z)yAjwAIu_TXS%GO@rhX~B*R)w60aMl5sCLM1ROmZtWP-?En3D3l?ELSuZj$NY*>KPQu0u15Ksjmbh) z^+$RUt_@67ijQ@X8#&k7j*7ulStbft`+~b~-SvA42;$_J2`I|*0m3qZK-CpDIwR0o zF_EZvI1;y)DM*!!jcPD|ezOqr7cGjI*9n^qcf@g7KoU@$D40OU+OlraL!zBmp_lWL z-ZV$kj>Tsj9*n*k6re^Qmc^veXSQ&}5$su`9c+^XUfDZxVdJV{SVg?yqAFuZoY+(} zAP+LRi!}+-N}=O>2@H}UkF2Oo#|msw{?8gzWA*4$+BW}@2fF4&;gLV&FEu!1cR}%1 zbB-XPE6)~eJZMS*10%cccwrkfClFRja!P-<6ch4|s1|=slLjmO`wb(`a=5_$%Cm)l zRD<}`ng*Bk4h_nXb~$Mlf{ftUtl60ngwF+(91k-IYnM1_fx$0U9s>7vax;Jub$q+;y~ zpmx%YaBv8MstTM&luq7m-IZmO+lVO3oW@$>kfpN%tzE;G#)T@oO@`>?URi;z*gR^` zPicz@O69^wwpjJ{4FemMk@))(?D9|oM&q8rp+(4XVE;5`+b|6)gNdScVFZ6LWqE+H z$7zz1hW;r|UsNtRY+)=57WV310ZtD$)83Xw-#u~7t;NRl2oUyMjnJRI2>$+Ac!>aIXAjzFTA-#z{H zA2}b9Jf|#pZ~c|SbUC23)Ot`;cp}Sa4E!g#S4lTHu+dl6wZ4{>Q_tZqE{toPJkzy~ zezD%U>KvjV*co`xGbdT^C(CmYr1<}QF49tzZbD>|Xq9Q85sVv=h;q{=VHybu#K6*U zY;;bd3Q_rIqZoog5vcsetJOx2Ox!}4TSq2Fm7J4RGR_kv?PTKrkLM0zyd1-D zgLAzeLpa}tIoOK&{YfmubLdydQofXchoY9X80OVBI@^EWDI6u4Efgx*Kk1%9mHHbj(Wj0%*Gy6s>3d9qvNLWKN<6bRPLL*EsM>bIU{i^*}Ed=Hj2|!*aS?jXQBAUdI$1 z&BQ6iKGYme;}D6fqN{iFf=|ny93)H1)uXNL%Iz>P2T! z8M%mB13#f&9Klv#r-OHmm+fs^qH@)OgKB^b_@(ITCO$6U<+dMcW;`*c$d zpjP_`=0hnhM6K>}q_1YaV=Zdrt*94vI-Wvp$4k!nE!1-lP}_9?>o9?bXwPptsN{3u z5Nc!}qdIWIIseT$cXLx2DnY$yI?lsYI2%u)MtT>Ox%;T84Pzn6ILA!XE-1ky?f*Gc zO1ZEBr{HU-{rwGU?!H51pbrc14^#)T*ebd|1Iezbaomplnddo7!?UO<=|N3ZI15F; z%g2edZx&F|9JirX<(sIv`w+E?doU0CP#sGk-x^UeYJcaWz6X<0Bdf&)*o<0BAEDlN z9o2ycsO>s7jr?a&nMp+rH=r77M{Uc~SccuGDSCuTZ9X3h-JgZZOcQEEZK&TLMm={C z`7>W}pzo#+mBC0_*A$nflm8qlo4BACyo~D58JvOLs5uYiq88Bzc`D`XMZA!h0QXWCDeEut8PEFbSzu1Au@QtfE4{@$F;#Oie!51W0HgH@) zDA7BESNI?3s9985H%Rc`m?luAiKw^tBV+yRsqG@PST#-B1uEKA<-r;sGSu#wLkuUT z5^NZ=nb7w}Mc)}_HuxFP!fqp05*|Y9Rhwcz;U!e~ROut>H+!kH5S2tOQA?=Q5mSP- z!NW4xPAnzn5?ctZzY1bD;Ugvy2MB%K_7U2V)r7YAMxujwoKT4*c4*EP+uNg3ZLHgC zPr9=rIvQJ=c5H64{q8b*IBKaK8NJeWM89S8Vp46CXOrFQ*=Gkl9d<$7yuj;mtuC9K zaMLas{h5tT^x30{c{U;`JFqAz$7P=zv%+p2+i6S3t+r*!0sBw#GFzAOMZl&uhT4be z>2_VlbUTodJ$$gqmU_E2bG99mRc8ZP_0~J#vJJ^jv#y+%?9rSu_PyL%o9K-R zq~+ap1&Z_CuE51fAujuUL6zM#xx$7O<_4A&u65Z@i)!qp;uq|(l4jdo+H0@+wpibk LyMbq?W`_I=dp9%{ diff --git a/locales/es/LC_MESSAGES/messages.po b/locales/es/LC_MESSAGES/messages.po index 2aaba49da..8086e8a58 100644 --- a/locales/es/LC_MESSAGES/messages.po +++ b/locales/es/LC_MESSAGES/messages.po @@ -8,8 +8,8 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-08-13 22:32+0000\n" -"Last-Translator: meowmeowmeowcat \n" +"PO-Revision-Date: 2021-08-26 12:32+0000\n" +"Last-Translator: Adolfo Jayme Barrientos \n" "Language-Team: Spanish \n" "Language: es\n" @@ -17,7 +17,7 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=n != 1;\n" -"X-Generator: Weblate 4.8-dev\n" +"X-Generator: Weblate 4.8.1-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -26,14 +26,16 @@ msgstr "Contribuya a esta guía" #: ../source/contribute.rst:7 msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" msgstr "" +"La |PyPUG| aprecia las contribuciones de cualquier tipo, entre los cuales se " +"incluyen:" #: ../source/contribute.rst:10 msgid "Reading the guide and giving feedback" -msgstr "" +msgstr "Leer la guía y brindar observaciones" #: ../source/contribute.rst:11 msgid "Reviewing new contributions" -msgstr "" +msgstr "Revisar contribuciones nuevas" #: ../source/contribute.rst:12 msgid "Revising existing content" @@ -50,6 +52,8 @@ msgstr "" #: ../source/contribute.rst:24 msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." msgstr "" +"Al contribuir a la |PyPUG|, se esperará de usted que se adhiera al `Código " +"de conducta`__ de la PSF." #: ../source/contribute.rst:31 msgid "Documentation types" @@ -58,6 +62,9 @@ msgstr "Tipos de documentación" #: ../source/contribute.rst:33 msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." msgstr "" +"Este proyecto se compone de cuatro tipos de documentación diferentes, cada " +"uno con finalidades específicas. Al proponer adiciones nuevas al proyecto, " +"seleccione el tipo de documentación apropiado." #: ../source/contribute.rst:38 #: ../source/tutorials/index.rst:2 @@ -169,14 +176,23 @@ msgstr "Audiencia" #: ../source/contribute.rst:148 msgid "The audience of this guide is anyone who uses Python with packages." msgstr "" +"La audiencia de esta guía es cualquier persona que utilice Python con " +"paquetes." #: ../source/contribute.rst:150 msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." msgstr "" +"No olvide que la comunidad de Python es grande y hospitalaria. Sus lectores " +"podrían no compartir su edad, su género, su formación o su cultura, pero " +"tienen el mismo derecho que usted a aprender sobre el empaquetamiento." #: ../source/contribute.rst:154 msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." msgstr "" +"Sobre todo, tenga en mente que no todas las personas que utilizan Python se " +"autodescriben como programadoras. La audiencia de esta guía incluye " +"astrónomos y pintores y estudiantes, no solo desarrolladores profesionales " +"de programas informáticos." #: ../source/contribute.rst:160 msgid "Voice and tone" @@ -185,6 +201,8 @@ msgstr "Voz y tono" #: ../source/contribute.rst:162 msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." msgstr "" +"Aunque posea todas las respuestas, al escribir esta guía procure utilizar un " +"tono de voz humilde y accesible." #: ../source/contribute.rst:165 msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." @@ -200,7 +218,7 @@ msgstr "" #: ../source/contribute.rst:184 msgid "Conventions and mechanics" -msgstr "" +msgstr "Convenciones y mecánicas" #: ../source/contribute.rst:192 msgid "**Write to the reader**" @@ -266,7 +284,7 @@ msgstr "Correcto: … se aloja en GitHub." #: ../source/contribute.rst:222 msgid "**Use a gender-neutral style**" -msgstr "" +msgstr "**Utilice un estilo que no marque géneros innecesariamente**" #: ../source/contribute.rst:216 msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." @@ -373,7 +391,7 @@ msgstr "" #: ../source/discussions/deploying-python-applications.rst:40 msgid "OS packaging & installers" -msgstr "" +msgstr "Empaquetamiento para sistemas operativos e instaladores" #: ../source/discussions/deploying-python-applications.rst:52 msgid "Windows" @@ -447,7 +465,7 @@ msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:64 #: ../source/tutorials/installing-packages.rst:460 msgid "Requirements files" -msgstr "" +msgstr "Archivos de requisitos" #: ../source/discussions/install-requires-vs-requirements.rst:66 msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." @@ -837,7 +855,7 @@ msgstr "" #: ../source/glossary.rst:187 msgid "Requirements File" -msgstr "" +msgstr "Archivo de requisitos" #: ../source/glossary.rst:190 msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." @@ -875,11 +893,13 @@ msgstr "" #: ../source/glossary.rst:216 msgid "System Package" -msgstr "" +msgstr "Paquete de sistema" #: ../source/glossary.rst:219 msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." msgstr "" +"Un paquete provisto en un formato nativo del sistema operativo, por ejemplo, " +"un archivo de RPM o de APT." #: ../source/glossary.rst:222 msgid "Version Specifier" @@ -891,7 +911,7 @@ msgstr "" #: ../source/glossary.rst:231 msgid "Virtual Environment" -msgstr "" +msgstr "Entorno virtual" #: ../source/glossary.rst:234 msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." @@ -915,7 +935,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:3 msgid "Analyzing PyPI package downloads" -msgstr "" +msgstr "Análisis de las descargas de los paquetes de PyPI" #: ../source/guides/analyzing-pypi-package-downloads.rst:5 msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." @@ -924,11 +944,13 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:15 #: ../source/guides/supporting-windows-using-appveyor.rst:18 msgid "Background" -msgstr "" +msgstr "Trasfondo" #: ../source/guides/analyzing-pypi-package-downloads.rst:17 msgid "PyPI does not display download statistics for a number of reasons: [#]_" msgstr "" +"Existen varias razones por las cuales PyPI no muestra estadísticas de " +"descargas: [#]_" #: ../source/guides/analyzing-pypi-package-downloads.rst:19 msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." @@ -948,7 +970,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:29 msgid "Packages not hosted on PyPI (for comparisons sake)" -msgstr "" +msgstr "Paquetes no hospedados en PyPI (para comparar)" #: ../source/guides/analyzing-pypi-package-downloads.rst:30 msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" @@ -968,7 +990,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:43 msgid "Public dataset" -msgstr "" +msgstr "Conjunto de datos público" #: ../source/guides/analyzing-pypi-package-downloads.rst:45 msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." @@ -976,7 +998,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:50 msgid "Getting set up" -msgstr "" +msgstr "Puesta en marcha" #: ../source/guides/analyzing-pypi-package-downloads.rst:52 msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" @@ -988,7 +1010,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:59 msgid "Create a new project." -msgstr "" +msgstr "Cree un proyecto nuevo." #: ../source/guides/analyzing-pypi-package-downloads.rst:60 msgid "Enable the `BigQuery API `__." @@ -1008,18 +1030,18 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 msgid "Column" -msgstr "" +msgstr "Columna" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 #: ../source/guides/using-manifest-in.rst:67 #: ../source/specifications/core-metadata.rst:185 msgid "Description" -msgstr "" +msgstr "Descripción" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 #: ../source/specifications/direct-url.rst:226 msgid "Examples" -msgstr "" +msgstr "Ejemplos" #: ../source/guides/analyzing-pypi-package-downloads.rst:80 msgid "timestamp" @@ -1027,7 +1049,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:80 msgid "Date and time" -msgstr "" +msgstr "Fecha y hora" #: ../source/guides/analyzing-pypi-package-downloads.rst:80 msgid "``2020-03-09 00:33:03 UTC``" @@ -1051,7 +1073,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:84 msgid "Package version" -msgstr "" +msgstr "Versión del paquete" #: ../source/guides/analyzing-pypi-package-downloads.rst:84 msgid "``0.1.6``, ``1.4.2``" @@ -1063,7 +1085,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:86 msgid "Installer" -msgstr "" +msgstr "Instalador" #: ../source/guides/analyzing-pypi-package-downloads.rst:86 msgid "pip, `bandersnatch`_" @@ -1083,7 +1105,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:93 msgid "Useful queries" -msgstr "" +msgstr "Consultas prácticas" #: ../source/guides/analyzing-pypi-package-downloads.rst:95 msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." @@ -1095,11 +1117,13 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:102 msgid "Counting package downloads" -msgstr "" +msgstr "Contar las descargas del paquete" #: ../source/guides/analyzing-pypi-package-downloads.rst:104 msgid "The following query counts the total number of downloads for the project \"pytest\"." msgstr "" +"La consulta siguiente devuelve el recuento total de descargas para el " +"proyecto «pytest»." #: ../source/guides/analyzing-pypi-package-downloads.rst:119 #: ../source/guides/analyzing-pypi-package-downloads.rst:140 @@ -1122,7 +1146,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:146 msgid "Package downloads over time" -msgstr "" +msgstr "Descargas del paquete conforme avanza el tiempo" #: ../source/guides/analyzing-pypi-package-downloads.rst:148 msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." From 496365af42473086ffd9de6d8ccd0ed57bf83d89 Mon Sep 17 00:00:00 2001 From: Cube Kassaki <2524737581@qq.com> Date: Sun, 29 Aug 2021 18:15:46 +0200 Subject: [PATCH 0104/1072] Translated using Weblate (Chinese (Simplified)) Currently translated at 24.8% (565 of 2271 strings) Co-authored-by: Cube Kassaki <2524737581@qq.com> Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hans/ Translation: pypa/packaging.python.org --- locales/zh_Hans/LC_MESSAGES/messages.mo | Bin 99446 -> 100719 bytes locales/zh_Hans/LC_MESSAGES/messages.po | 10 ++++++++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/locales/zh_Hans/LC_MESSAGES/messages.mo b/locales/zh_Hans/LC_MESSAGES/messages.mo index 20692a04030c24143d26d767a9de6b4974e04212..7136caf1ec6cff05c6626eab191d706601659334 100644 GIT binary patch delta 13273 zcmZwN2Y405+Q9KydM}~(6CiW~A{`Xz2@r}j5s{oECvYG+38{v5LMISHFH)pPC{jYN zp@{{=0u~SfX*o$i%Ef|RzyG^4c>TWT+vg6yd1rTLXJ=+-H^=*QZjr}Jig>^EE3{m( zwJe}iOe}dZh3a-OsjKoSUl`4gku_UIU)VCZf;Xah} z&S4eI!*WV_)!$@_Qc&(WrJ7+?l(?rc1f{~ESOT48&?=N8h08G z+j^CH*A#qW{MvZe_z0yzzZ$JpN);n6ZuCQGKn-IZV?AR-l!iAowl#LeGF)HvBSY`1 zk?4o>uokYv#dsWBTS|pIuPd6~nqeVcfWvVrPzBZJ1Ery zKkcZL4=Z$1YL%3u_XL?Got2t}17A=o0x#pA*y%;3)?!Z|t;->v{MU^?J0&zP$h<))TwEF8I>V}V`9AyYP(#lEL6RAp_8Q|3w zl%jbxC~z1%;|=0huspUMq*QebLK&iPlsim9nH!&>OwucO74KpZJn^#L{~pSDA7fR# zY5c`YCX|BmgLRAJP!5=c)o>Zgg?FPoM(1%P-o*0QX^2vlF$CrDiZISV2k|B>jc1LQ zupaSEtdHJ;LzSvXrV(Dj7qAvq8m8~)d6Wvem^cJKCmw-vUbEr42fN~X#6z(#R;PPp zzXO|K8!U*S=)nlABG3O9WRfWO4rgH42x7)M7mE>(;&x^1B2n&e0+z!?H~}}JbajQ- z^l{aV0VwN9OJx43QCJ2y8~58X{_m36%8pBzg(;(yI)#m2*FA6#X^Z*^<8i=fRyRD0 zhcP6SM;Hq`l^TmL<2^i%b1^ea*Ap178_*FGC=bQ}uCGp#c^-36?zn1%QmOQSKV}kd za_Kt^id1SEPl{Y=F7wz|x6&HV0x5 z@nEb(!`I?l#QT_Fk8n^j!;3Gypt>NP`8rn6X#_%cdQ-Ndr^5L@A&D0keFljXvlQ5xPKi{en@D6`*% zrR4cfCd0f?GtnP^Mwyh=X6X-zMktf5C&~qqP%4~`(vW$$&*F`S(zSi(=>1Dkx_%8F z!!6hvopZG-um;yx7s$wk^Xvj9Vj3q>VE{@)TF%p5-US1Qhv5>Oj3uz_d_8HaV^!kz zSQH0gNgRRPsdAwo#$gSdh1Iye+DN7|9!KfQU$6-_P1ijz3>y;1qg1d4rGnj97(c>d zco7TYRg{L`K$)BmP@a}T3-k)w6dlBU&>Kf)JQ+FRTfBo0Q5tYDgGB;=M;XhJ3-uj^ zVLf6GO2tc1&OeIMz;h^%?=_Sjd5kjYiY;Qea4mYU;bQt8#gZ7ihHl2m_&YXT%Ug{K8?Mtm)A=nuL~C&)`;TG_j$F_Bju()5 zsVZ%dsm{=0EY{#)>4|hN8M(76n{*4uVH@JFP`bF}+j?befnO7MKtJ@`Ok*$rWx*MQ zGDPF?b&Nw9l1s*0D3kIr%H#Pn#-X=(rXH)wC?_n!;*$j zNk@eZ?uDPD-*)B-$NBI9aj6|j{U)9AD;a6ok2`gj|ADoLi|x`M zp$$+bQ+>vvCALTD0XNDdos11|E6P*xDHg>0*d8BY2W*(7A9E+l(=r47WKhz{oTgws z4#m(t`fK$N%7RgJFI`K^J7XW>?)&teX5dK5i|p5*WMK#Nq&u zGPkOtJT+}E(O<=Bz(5MhQ1I&Kd`6)gE8-fI7Vp89Sf75ZheNR=reIe*fHM1^qFmVX zrC#|aqBL+Rmc{MZ8jqUtM_w}YhAQ-xQn&C^d=;}U>z*iaMX%xQun6S?urLlYzJ|q! z!>|;NM`^$tX8%kR&qKMv6(~KDiN(>o%M=_o1*cFdI&Zv;g^2H>TsR+J#7Eczo3ko) z$2bheLpT)W&!BQJ3}p_CL1}0PN&{9R^?B8LG9@U;M7hu&ER6@TJf6jZ_!Y`iauq9J z+i&y`^+CCl(J1G;aT$8h9}8a77Y;z_!9ZNZkhj57^1OU-T_5lTN<*&W5)Q~i>9UF6 z>J!tjF7YCivD}Z+Q)i7AQ5tdsiZ8$!+uAZ3-UL*99J0&bA9C?BX`&U<-jJ` z6I-BkRU%47Q&5IrE=mt&;2|2i7G+WmzO5(aT&zZX7MI`+d}z6=F$rbTO+{(wJX5~hxDE?ao{6%5yYawX`dNys_T<{QW1H@AMZ? z!w3A-MjVeb(e;og0`H?6*F54;!orVPPB9v%V5k4EPH>^4cnU93$x_M}|G-xealntd z{!u^aPrU6I!hUc1Q$9G!e1pC5i=Xw%RfEE=#H~?gc@lQR8JL70U}t>cSN(FCh;zA6 z|KIdaHdlVvf0AYYq0hgKhdKTccEK%w+E0~N<&rr~!9!i3cK@Y6kq%;i${Wy6jWH3c z;(Fr|l%BhU@;EM1mi>5b!1~08(1q7fZlJ4W*^{(CzDN8j7L@0|P65ka80w)PJDQ-J z@Pdi^;OoSrP!^DEl!lx|x$t$Yi4U*_7Uy$Fjt@YoZzf88D^bqdjB?xwti<)zRWfz( zG0K5u3t9H}eod@J+ymu8VfZ!1VRh_VST`ur7;Q|zW9*-Va$Z}$UZmb$cmxNVxD=np zUOAu|83#5-c})7?c53S?2dBW zPL$*J8&8(7y!M@*ry!UePf#w{sibAE@dHuf2;7A!n1u~XX|JGEJg2l}zjQKCE|`N0 zFoZvu<-BY7GNzTa?4M+=BM*RbmGkNoM)G@zRP-K7%P-&?_%+Jp8{}u%KhaFW;>20# zrU#DVA>w-cQ6T4kgYuK?ZIlJ5LuJeU@u?g3BTmDv?7xgMH>!H8TK4nY6h~386eIBo z*5trfs_6?RR=3nb%DpJFx@-;0{!1tkvpB952g^EfrgXG4VeE_> zIW8FAmioRUBVD}EVc8#*o6$i$%->Ssn2gdR*NpinWBe1!+$mYtvVYmAfikNHqpXlI zSR1FIOyUjbk0&t*Zy`&BS2eDu?<}Ccp0x*2CSPoTeqOH|^HCb|BR1rYtp+-7Odws^ z7Ujq0V3e2I>_(Qoer!N#*kf#nB^&D-cpgj2^B+t`#&jsQ#?jajm!aIjXDAEGBm5RC zG|`jjdz1@LYHHc=2V*oQc&g>JwZOeOBqQs2=9lu39Sr3dm+Zmhs_dh(V+>A{zqE{wuP7>`wOElRxyP`(R}<0^XQL+nf(+FD<4 zU2C3ySr9TQ*oS*ih9JC+b`?s6pP=-F59Q8^wnZxR$I`@|c*Rx5V3e^A#pO5|r6GRp z_0n4nWyo5g)Z4SYSI_=Y6v%;b=71Dqx^X?e$o_pOckl$8VPFT{BO|dnaVknfc4Gs4 zAEn+0#vf2t*xyik<}WW9X-SEW`h>dJgg6-MVFJqBScOv2Uw8lu^WS5h!(;dwK0q1k zU>*S(y1^*#h)|T5&Lk5rL+QaRl;gbT$;k718D+`L$Elda&z-U${e;7C@QarHo&OHD zA%281B=x)Kb)y$b5B-9tu-!|R8iGG#C5EbBSIhn>H>{gw|1R(rww339TzAHV12&?Q z6Atvy6;|$P*?)SSL-{c2+)H=;OiU*}gK`J`dt1Ew`4b#J#|QWjPX*~Ue^;=c6RMA; z-lV)HM&lvuF3*4czPey6%9?)}$Kil}mi-@#j-m8K+YrnC)LMqJKKS+56^EbnX`tQ_fKpK#l(FxO($Y|r&+boADtLl2*47}) z{(GP#%JW zsAd0bzGawR;g%2AlXWw;Vt+PD#g9=McI6ez{;4Gokb?I35FOayRlPv;MyY53Zox<#jHO5Fx#C2bbZ3zdUsd2W%l=6H0pp3=j$-NM zhTcIL!aJ|)r|YHBmU@?X{AjP9^?{+5`j~=jXM+A>Difz~PNFFd1Bmf+ba6?I6^-+J3{H$754(XxM{IiIA*bZj!SzX1PzA5U=n-W2_kiJ55G zzk0om6)A5qNl&&OC`0e|1X$= zODK1E1EohEp!CR(CjQIBMW*YD${A~6A&zT;a^V&zPemK-feF|hk76+Xi9@mX44!{^ z->)Mh&*yHGmR?3_z)h42^H5&X4^f`mUr-jBKTuw$C1&dKTG)@+A7yAf#u+F#vI?c4 zn{YmEoyqgxjLh@1^o2uFy3CC%aw-<3%g)T!`#(i#$Q5+4{|-uz1IBhmxXpTtZLyEorQ=CJaoya11AB>ITg;eISe*$tG<+k$`kkYxRrZM)g=1CAnn zs*BYv>_vP4pOE~ipoc257yUQqU#SoocEkn|x*p7Rl;T+&M%caiin=_itG8Kg$! zKPTNM{|;Wml_Xv@YU#3oirzZ}&$b9M4QahRCZ+K{2R$V9B|eUPUD^NdhiAwCLR^GY zkYm5Y7ua!>blDs*2W1(r#QxXW&!TB>!;Ig{>U=|&sj8;%Z{jALAe+3DekD~V4v_-0 z9a%c6K^^b&<_vp%BfpHa&6JJA3Y=9R<$FlBvc&RMkZmie82jY=xjN+mq!) zy=4-_lCGG-A~fVVj=5)!8)V9T#^NlW_RIAx3gqqnZ2N}tKMB_01#_~z5pI%76NiwN zkiTa3m61Cpu1s73b4aokqCAlF8|Af8wl$=+q>UtRRSLJ5N{H1bCf|X)i~KvtT5bRT z<#O-?;=-J>nfw+;B+s+)mz_;Xt<3=vk0Z$| zCWVww`Fo_#{4rx9G zqe$(^%T|;$gw$FBwzHJqA~oQGuJhTT(Ojr=o02$va4U$=5d*mh$S9-6Rbl-wI_LOY-BGD)@l1 zFG)2>MTp-d$@VeHn@eGW9qNDHB9<*kWB=Gz%9Q<$^Gx|>Tt$ketQi-|!ZT*yTJl#( zb%}o@jV51`W4=Q9IB1Dx(x_B#9DnVD{O&cG8S2bDhCb`XC_ zP=&IRvU9x6P1#SxV@*E8cn)Wp{3iJ@lC3-i#i{Tj`AOuX z@v7|j*OpHHG5h+HN^xvsl5ERJ6)3BO(^0kW{jzFA5J8FL<%C+CGBRvg|e;2!2O>DuB*5-w_9~@ z!dRChDkiyklq<;<<%n{6#w0q&xEwK&4%ss>C1Grg$Kj5SjdDf1JPFPOcZ{c_qkD_) zO`AF*W8%yK%^ZE4Nlv?K*g)5LfOtsd%eztM~{d-Ut)Xf(#1)gXM|R(Bd0h$8ff4TbggAFtqV!q3!0arDWOu??hs(*17zQEk-<|1nB)HeLY9AQSZf?&d{iiP;?ugf|i*<&NXQbmD?s!Lpi~Ew^ zbvnj-Vv;?MF)=X_av+x;%l-scT(lfV8>3@9jA>##2ZyCNBIBIVuH=}w@!X#$!jTXY z6E)tQ&@tXL=h=P5x#f7eBswuF!OdJ^Dnz)G+!2Y+sQ=wf`^)z1ztfwyY}>P`=iB{O zUdEoh)iZNWWaJ&&nxC~Re_Lu^_6pzZHz{;zlVB|HKLEzqe^7*UHaY zoV#L9&hbMzM|M$N&dK?{Ez|Ak<;XcQ?^#Q8)3*EeF6SiQti3tMcKEW6=I`BTCaOOD zZt65MrT*XZWTHOKo||{P?VG;cs~z?{)s;TZPRpIU!eM6HKNr$dGH>s3UH$$MPi9%( z<1_Qt9LYJh#5XJ3xBDo~$xWX_b$MxXbJy;a)-7C|zcHPVZgA*+;GTSYX6K(;#EzUJ zsdPo|!TI@F%YB(ExoP(1XJzUKJTqEtMR7!Q}v+_6X@V&h!cU4Btkz+pZ;eC1Q zGxO83e3>Wit(l#3biOZb0hh@?H77SMHFs^Au39cmt+{Kn7*X8{20iCkM&7c$zRjy; zG!`t+o4@m))^g3HqOp{>yU3ry62Q0hxcH%NGn#7`RO zP-#x(|9bDt{eQoGJU%?-|6qo)#w^A3<>(v@?!u?|vb-^4sJ~Oun7Y`tk}>abCpMKFEe1oX z&=G8p^vR6Dl(+|Lt$imjNQiW8^<-$mUv zUOi)4U>K@npI}-Xhq|2>JNIBX`4votvChQxjmbtHhS{++ropy&5d#A$WTH^Jfjy%h zs0IeRd>o!7pNZPBV?#THpWzYmsh9xkH?r%SVs7$Y7=-h&H!j97Ow!nxL6{B4=>A`* z3a)kLCU!{XGS0eoU!u-%EvCfd*bgtGhPq}myIp-}E7bF&D>8k|TuhF?IUhOS;cDs= zH#cSz$2XfP?5Cm~UF?sP59FG$*7Qe%Bt&CwFndsIW3@70Oe2x?FY8%^5 z=eD*3{c!;Gqc8`)!orxb9Vg83O$>#Rj6gH|n*2(8dxj%BuoLy;QIjQcCu0~alM3mJ z>4uY7e+*NR*Xv?TPwa?XRdWXWV|IEO!gljeBeJ%eF_Up82DC%v?)F-4#+7V1sE57g z8G3OYS^t!O3Sdhvq%O@=)Et?Q8p>6;8SC`1lh*Xr&@xd`bL$wYojaHs>vJ6wW9NR1 zzc%Pgg;q?%(zqNy!fP0c!JI}UX2x)=f||{p@nf8fp>+H_eo6k2>-H2UGVY(@rvvTF z=`YkJevdkVB!d|Lp6r;ODXBC2e6TTDa3)4mzZpZwpM7c{P#&#?kyk-=uob4q@u-HE zq1xGi#c?NA!#^+rOAIk47dFQSI3_@0IE7wA?U_D8&2DcP*NP4VV_NbsHj0n=FdG(j zc@vCB-V)W(Hb`GhKkSANaW*y_VLN&s*OABL#A{+;1BI~^-Xg~`BSzZE6pO*+$w%3t z3d0oSIj|5GMV)b1)PV<}I{rB(!l}-=Zv7HWO8q9}Dw(|)q5D7oXge$GVMbQ8#R51S zb%2ei26v;b*&*EG@nM1*+A;KA>wiWK{W;u?*RTjK7-v0+8OVb^x0fOdX3+g#fx-tg z*b0-gLD%ti$OmH%@@Y5=x1kPDZGxTE^)VfJUrdA(Q5~L%I@2YX3fG|yybsgkWh{fw zu@J{M1t!`@W(U*=Ov9YG9@W4(R0DT00mhqTFHJB8k%yo<9*UZr*)bB!U}o%q;W!#K z^ea%?r=86B-=dI%LT(J6!UV#?m=I^9&S)WO(yc-@{1d8yKT#btQ|;}W8Z{z0QIoDb zax8Nmdt;kv_5pShYm(=f&iGfN&~LiEEwT&fpXjJzI4 zxr-C90`{51rC|ML>`uOGt}&-D`xo|!_X6vYkDO;rSv)(B@u$v&%(rK{1~-y#!&vOF zfVUbAwpnOLX22qQiO%CP*8hopaQ0%}=@_)ceo56vUD|WVL(eq$(vHLt)QQzyYCE_* zK%poV$-c5fTnQ7Ccfm{84>iO!I9eWTg_=YYQI}{1w#Ids91}0MrbA82oT%F~KlaB8 zm>RdCwhtVqpaWh+O|F}m7w=(G3|(PNC(MeiZ~_K-3_A`cf4I_4&h}q(3zCn(vshyl zbA|0Ptv2Q{dF3_6yu*TPZO5Y4`6C`MMJQxqMS1)OTcdi|a=m>H^hJ%pGR%$JFcPn0 z22A*ky$iBp3GzrRiES_f7ho{%LA7%P58y>?q>D6vgZ)~4ih5v_V*(_k=L4_?`Or=F zOpjp;>dSs>Kgkwuwv+Z1s=+K<>?FH^Kauy`%43)9i*MuGf_%z$>r-q=9<#%kIhrIJ zD6oyG_??{;uW>(l`n5aa(~ifRo^WaQ*hzK@Cz03XR$+9_6+DMy_xX3G zY5Kiw?=JpA{VE!th64_;zYY|1&=^L;97YXc-$V9&y%yV$haKkcI2?>i@d+{*X6g|; z`J#{7+ix-I(p*Eem*ANFg4%-p$RmGXq!^L;$c?SOFiSW`Djj_Q0z!9r+ei2Y<#CcoQ|J{&e+`XN}=p zO&Pp_2?JcH<`nLsMxx?*`wZ`c3CYJ}0-WZYgPP3?F)6M#1uH_?C1F_EF-)u)h zQD>S3b!NFx9V?8XSOV4II;at7iaNp87@y;t_7tjM7t~N~KsB@-wZj3_2pz*6bo4wH zA)kEBPRawQ*&U0sF!Z|pV|5Lx9q)!UDQdegOo;_Ckd{J4SJBMb9o3Pcs1X?B@>R}_ zs7bd2b$~;t?SFAzK%L=L)cTvw$IjQzcsCh;ZIJAy-7uXqn=_xYq_eWKF6w~Io$XPV zpu6)ER0oDRM>@wkC!mfyYWMVy3#@E0tDm0#GG$taw_ff~KEKha!!W&Z>_{Mzn+AHQS!msk!rys>xD6Fflv z!sXlF+ApHLSV#AN-gov-sbQ#|t#a;14b>&o?Kdyh-cGAAJNZ8Bgtt&9@bTYvQZ~XP z&|J!-onsQdp0X2Dme?b0$4a$+{j#PLl{3OZ0Xyo8_OhgjcueusKF2RMh~Zq|=R z?HBENe#5nKCwX(1r;caWhhsSP1yCbW4|`xE45XoOkV0Gh75iavKJa>Qt=FPPBs78N z&+?3@Gs=lNlW6RUHBj4aMcoa%okvk;dK#vpW^kT z0nh(CzG*Vg|4n8zCT7JB?8XQjz#ZhdQ`iP>qJDC{kHOTJ=XaH=SRHHO46MNVtEjn= zCAH_@zJ;(A`9kcBZ!jaewsPWJ{IZog>Mk0S++w+E~xzG`F;SdbN6{v>y zpoaJm&Szv!Vj1!-`RxH$qMire;1>K2bqTr`ur4jY{jUbkQxSoWQD>ICAkttiOh#Uj zcWPRUL0#)EI2XsDI+DJy=RbPGQJ1VFs@+d1DC#1p87pF7{79K-mfep%=$Ihj(kr!+g_&fp8nDbm{Sz0v7%B1JM@!r3i)x=88oWsnHks~&*F1@ zg2yV^Xa2Uzc1|R!;+X~1XTx5&4=Z7wsy6R~dgfon?%24R$A25*{yRuP&*tclJ^#~c z5$XYvzPfF=A?nif#fvx?bzj%5VdqF2)Lk+KRlgi{pKoz_#+tT13e`>-)U~gKy>$O~ zp^z0Xpc;6Cy4Jz9JpcPY73zLYhsm%aw!j$dfZyOfOj+CW|4e^_>QL`Gp8x0iSkxuU zUe`16xDJ9770asO)wYqs|M zZ@^8c2TSrc_PxIndy=zRXi9H-%=cAnXa>D$}e^%vYrKDvX)XBl6>9qlAOgzL%c zcJj;xjK%4Arn7CYU7(BS|3aCqtDWV~Q3o2^&GUbVtlHfU-An9EeZC&{Q*8+jBL5ec z;=rEviz&31J&~hWf%@#d?SrQ?ZXutFYNvc3`>7Y$L}4RC64BT5f0H@g&tB6${h9so z`0sYOj~#XnurHZG13mvg9<4(?T8j;`ldUG|(cI4E!%^>s*_a5Iq9*lf)c3+>9@r5qXY@b^ph@iUh;$5G6x36z0s1@yQFK8Z3soE6QMH9Ez3j z09MENBkT#(LA~!+qHfRasE%Gmb>J=r)ZkMJdQZPV-M8;i51JtE4!s>iQ1#id7Un`- znt{$qsB60v)zP&$88>1SmKtdf+yymaeUWF689b8vUuSxJl-=M0sw3BsJHcVJC z3(q=Jjo{hl|7TgM0_IKnUl z_-yn)=U!kiG23mwoAQ^0mSMyzzr@ct>ba+tu0p&e^l~{$=ss^k+)LJqpFdn5_oXX{5qb@E-vCzJp4R^0Zl$m0_p z+djZ(R(waCcN>gD9^xi7>szv(=Z3#DbpD}7^M7oeN$V>AA8vGoe61RvWFkBF}ap%7E_M=16TJCPH^?h@e85{b-6jv2Hfw~Eu?&r$V&bf(TZ|nwmF9>$n&9F z?Da29Hkiu4i0>({z^V8VenV)UOA<<5V#*1y9=>rK45S=J{7Ie?q017;`JvWht6mw1=E zy65DbU3rT07>;)3ulVZrcS%7-A{snN_8H|Kc+p?;-+v}ie8Rd~#0PAflh87Y2%#<% zN1~Qqc!0?3w)va7Oq3f?r$6QL;vDMQ$Gus`Q}HViw`_6cbyT#a+|aF9iOK$FJ5`S% zepi8I8Ii%QAMQ*`-2kF4`Bb6~Wi8VvcS%a&n4j_pn>{sOSoL0HRfrm{HjZ)>I=Lpl y#ZQUjL{%c3_=ffG-Ny6DqqaWDw, 2021. # Zuorong Zhang , 2021. # bluewindde <13548563428@139.com>, 2021. +# Cube Kassaki <2524737581@qq.com>, 2021. msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-08-22 15:34+0000\n" -"Last-Translator: bluewindde <13548563428@139.com>\n" +"PO-Revision-Date: 2021-08-27 07:33+0000\n" +"Last-Translator: Cube Kassaki <2524737581@qq.com>\n" "Language-Team: Chinese (Simplified) \n" "Language: zh_Hans\n" @@ -1059,6 +1060,9 @@ msgid "" "file for Python extensions on Unix, a DLL (given the .pyd extension) for " "Python extensions on Windows, or a Java class file for Jython extensions." msgstr "" +"用 Python 实现的低级语言编写的 :term:`Module` ：C/C++ for Python，Java for " +"Jython。通常包含在单个可动态加载的预编译文件中，例如 Unix 上 Python 扩展的共享对象 (.so) 文件、Windows 上 " +"Python 扩展的 DLL（给定 .pyd 扩展）或 Jython 扩展的 Java 类文件。" #: ../source/glossary.rst:59 msgid "Known Good Set (KGS)" @@ -1072,6 +1076,8 @@ msgid "" "used by frameworks and toolkits which are comprised of multiple individual " "distributions." msgstr "" +"一组相互兼容的指定版本的发行版。 通常，将运行一个测试套件，该套件在一组特定的包被声明为已知良好集之前通过所有测试。 " +"该术语通常用于由多个单独发行版组成的框架和工具包。" #: ../source/glossary.rst:68 msgid "Import Package" From e31a15b08ea089a7f65d980ed20c599934483e9b Mon Sep 17 00:00:00 2001 From: Mingun Date: Sun, 29 Aug 2021 18:15:46 +0200 Subject: [PATCH 0105/1072] Translated using Weblate (Russian) Currently translated at 1.7% (40 of 2271 strings) Added translation using Weblate (Russian) Co-authored-by: Mingun Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/ru/ Translation: pypa/packaging.python.org --- locales/ru/LC_MESSAGES/messages.mo | Bin 0 -> 1486 bytes locales/ru/LC_MESSAGES/messages.po | 9257 ++++++++++++++++++++++++++++ 2 files changed, 9257 insertions(+) create mode 100644 locales/ru/LC_MESSAGES/messages.mo create mode 100644 locales/ru/LC_MESSAGES/messages.po diff --git a/locales/ru/LC_MESSAGES/messages.mo b/locales/ru/LC_MESSAGES/messages.mo new file mode 100644 index 0000000000000000000000000000000000000000..d983c38df69ae5c631e282a5e3c5c0b58a6be145 GIT binary patch literal 1486 zcmbV~U27Cq7{`xo?8_*H)*C^g$BRm&J^K;`!(=CQbvL?@O~PhlZ0{zsr<<{xnQ`V! zY#KE|7H~K#_$?l3sp${B>&vVZ6KJ)h% z12+j|H_m>XWt+31_XFE?$h75poJ?~o^lh<3PH$b$!cu__KTj>!5gcu7m0+bB+j7%sB@6-^ ztqyuio_R>CaL@GxD+hJE#*T;efK^?cYEzS}!WV5-kQFeTPQNSWE37=p3VC{JQZJXj z{(f?zsEwO}U{&9Af`%zvU#DX;uE1pQIJ->rjt!#M&`vEVaml1)4kL>^+T;(Di?d> zW>XpMM6wQ6UGgx9;6I79*T9z;q1L?V2V594)iE~Q^HcNuzqKyiE21sWiy76r3VjErDhHo*)08*W+=R2j~YYUPdVd=QU_zV zTsA|Omy;0qWDX%Fi7~@y8^)olRClkEDiESytnV8j-)qj$D_IWK%wuZP}vH z#pqIWExG`+BR44CnsQUNqgB}^^4Dk;FUqweAIK-NN%7W%(!w>al60HVO8nlDk5%Gm zExL@<8${lc&!VeD-bKhd;-;)>8zrH*_WT|uaNYQnb# z`)d3^(O=&j(Hc#D`j;!W5z&r*ey7pv=y^p=g$!L^RsEj)O+H0>Od4IG7@#FLwwi!1 qk=JmcTEO54$0ia_BKtBXGbU^6PMIvNBOj_^o+SfdQ*G=4^~f9ATJTl? literal 0 HcmV?d00001 diff --git a/locales/ru/LC_MESSAGES/messages.po b/locales/ru/LC_MESSAGES/messages.po new file mode 100644 index 000000000..f4ad54187 --- /dev/null +++ b/locales/ru/LC_MESSAGES/messages.po @@ -0,0 +1,9257 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2013–2020, PyPA +# This file is distributed under the same license as the Python Packaging User Guide package. +# Mingun , 2021. +msgid "" +msgstr "" +"Project-Id-Version: Python Packaging User Guide\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-07-06 19:32+0800\n" +"PO-Revision-Date: 2021-08-29 16:15+0000\n" +"Last-Translator: Mingun \n" +"Language-Team: Russian \n" +"Language: ru\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && n" +"%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n" +"X-Generator: Weblate 4.8.1-dev\n" + +#: ../source/contribute.rst:5 +msgid "Contribute to this guide" +msgstr "" + +#: ../source/contribute.rst:7 +msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" +msgstr "" + +#: ../source/contribute.rst:10 +msgid "Reading the guide and giving feedback" +msgstr "" + +#: ../source/contribute.rst:11 +msgid "Reviewing new contributions" +msgstr "" + +#: ../source/contribute.rst:12 +msgid "Revising existing content" +msgstr "" + +#: ../source/contribute.rst:13 +msgid "Writing new content" +msgstr "Написание нового материала" + +#: ../source/contribute.rst:15 +msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." +msgstr "" + +#: ../source/contribute.rst:24 +msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." +msgstr "" + +#: ../source/contribute.rst:31 +msgid "Documentation types" +msgstr "" + +#: ../source/contribute.rst:33 +msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." +msgstr "" + +#: ../source/contribute.rst:38 +#: ../source/tutorials/index.rst:2 +msgid "Tutorials" +msgstr "" + +#: ../source/contribute.rst:40 +msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." +msgstr "" + +#: ../source/contribute.rst:47 +#: ../source/guides/index.rst:2 +msgid "Guides" +msgstr "" + +#: ../source/contribute.rst:49 +msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." +msgstr "" + +#: ../source/contribute.rst:56 +#: ../source/discussions/index.rst:2 +msgid "Discussions" +msgstr "" + +#: ../source/contribute.rst:58 +msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." +msgstr "" + +#: ../source/contribute.rst:63 +msgid "Specifications" +msgstr "" + +#: ../source/contribute.rst:65 +msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." +msgstr "" + +#: ../source/contribute.rst:73 +msgid "Building the guide locally" +msgstr "" + +#: ../source/contribute.rst:75 +msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" +msgstr "" + +#: ../source/contribute.rst:79 +msgid "`Nox `_. You can install or upgrade nox using ``pip``::" +msgstr "" + +#: ../source/contribute.rst:84 +msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." +msgstr "" + +#: ../source/contribute.rst:91 +msgid "To build the guide, run the following bash command in the source folder::" +msgstr "" + +#: ../source/contribute.rst:95 +msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." +msgstr "" + +#: ../source/contribute.rst:100 +msgid "You can build the guide and serve it via an HTTP server using the following command::" +msgstr "" + +#: ../source/contribute.rst:105 +msgid "The guide will be browsable via http://localhost:8000." +msgstr "" + +#: ../source/contribute.rst:109 +msgid "Where the guide is deployed" +msgstr "" + +#: ../source/contribute.rst:111 +msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." +msgstr "" + +#: ../source/contribute.rst:117 +msgid "Style guide" +msgstr "" + +#: ../source/contribute.rst:119 +msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." +msgstr "" + +#: ../source/contribute.rst:126 +msgid "Purpose" +msgstr "" + +#: ../source/contribute.rst:128 +msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." +msgstr "" + +#: ../source/contribute.rst:133 +msgid "Scope" +msgstr "Область действия" + +#: ../source/contribute.rst:135 +msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." +msgstr "" + +#: ../source/contribute.rst:138 +msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." +msgstr "" + +#: ../source/contribute.rst:146 +msgid "Audience" +msgstr "" + +#: ../source/contribute.rst:148 +msgid "The audience of this guide is anyone who uses Python with packages." +msgstr "" + +#: ../source/contribute.rst:150 +msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." +msgstr "" + +#: ../source/contribute.rst:154 +msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." +msgstr "" + +#: ../source/contribute.rst:160 +msgid "Voice and tone" +msgstr "" + +#: ../source/contribute.rst:162 +msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." +msgstr "" + +#: ../source/contribute.rst:165 +msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." +msgstr "" + +#: ../source/contribute.rst:170 +msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." +msgstr "" + +#: ../source/contribute.rst:177 +msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." +msgstr "" + +#: ../source/contribute.rst:184 +msgid "Conventions and mechanics" +msgstr "" + +#: ../source/contribute.rst:192 +msgid "**Write to the reader**" +msgstr "" + +#: ../source/contribute.rst:187 +msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: To install it, the user runs…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: You can install it by running…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: To install it, run…" +msgstr "" + +#: ../source/contribute.rst:198 +msgid "**State assumptions**" +msgstr "" + +#: ../source/contribute.rst:195 +msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." +msgstr "" + +#: ../source/contribute.rst:203 +msgid "**Cross-reference generously**" +msgstr "" + +#: ../source/contribute.rst:201 +msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." +msgstr "" + +#: ../source/contribute.rst:213 +msgid "**Respect naming practices**" +msgstr "" + +#: ../source/contribute.rst:206 +msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: Pip uses…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: pip uses…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: …hosted on github." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: …hosted on GitHub." +msgstr "" + +#: ../source/contribute.rst:222 +msgid "**Use a gender-neutral style**" +msgstr "" + +#: ../source/contribute.rst:216 +msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: A maintainer uploads the file. Then he…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then they…" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then the maintainer…" +msgstr "" + +#: ../source/contribute.rst:234 +msgid "**Headings**" +msgstr "" + +#: ../source/contribute.rst:225 +msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." +msgstr "" + +#: ../source/contribute.rst:230 +msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: Things You Should Know About Python" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: Things you should know about Python" +msgstr "" + +#: ../source/contribute.rst:237 +msgid "**Numbers**" +msgstr "" + +#: ../source/contribute.rst:237 +msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:4 +msgid "Deploying Python applications" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Page Status" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:6 +#: ../source/guides/index-mirrors-and-caches.rst:7 +#: ../source/guides/installing-using-linux-tools.rst:7 +#: ../source/guides/packaging-binary-extensions.rst:7 +#: ../source/guides/supporting-multiple-python-versions.rst:7 +#: ../source/guides/supporting-windows-using-appveyor.rst:5 +msgid "Incomplete" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Last Reviewed" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:7 +msgid "2014-11-11" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:11 +#: ../source/discussions/install-requires-vs-requirements.rst:9 +#: ../source/guides/analyzing-pypi-package-downloads.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:22 +#: ../source/guides/index-mirrors-and-caches.rst:12 +#: ../source/guides/installing-scientific-packages.rst:9 +#: ../source/guides/packaging-binary-extensions.rst:17 +#: ../source/guides/supporting-multiple-python-versions.rst:12 +#: ../source/guides/supporting-windows-using-appveyor.rst:15 +#: ../source/overview.rst:23 +#: ../source/specifications/core-metadata.rst:38 +#: ../source/specifications/direct-url.rst:14 +#: ../source/tutorials/installing-packages.rst:23 +msgid "Contents" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:14 +msgid "Overview" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:18 +msgid "Supporting multiple hardware platforms" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:40 +msgid "OS packaging & installers" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:52 +msgid "Windows" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:61 +msgid "Pynsist" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:63 +msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:70 +msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:74 +msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:80 +msgid "Application bundles" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:91 +msgid "Configuration management" +msgstr "" + +#: ../source/discussions/index.rst:4 +msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:5 +msgid "install_requires vs requirements files" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:382 +msgid "install_requires" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:14 +msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:19 +msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:29 +msgid "Additionally, it's best practice to indicate any known lower or upper bounds." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:31 +msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:41 +msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:51 +msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:56 +msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:64 +#: ../source/tutorials/installing-packages.rst:460 +msgid "Requirements files" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:66 +msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:69 +msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:73 +msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:78 +msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:84 +msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:90 +msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:6 +msgid "pip vs easy_install" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:9 +msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:14 +msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:22 +msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**pip**" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**easy_install**" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +msgid "Installs from :term:`Wheels `" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Yes" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:30 +#: ../source/discussions/pip-vs-easy-install.rst:32 +#: ../source/discussions/pip-vs-easy-install.rst:35 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:51 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "No" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Uninstall Packages" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Yes (``python -m pip uninstall``)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Dependency Overrides" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Yes (:ref:`Requirements Files `)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "List Installed Packages" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:38 +msgid ":pep:`438` Support" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Installation format" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "'Flat' packages with :file:`egg-info` metadata." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Encapsulated Egg format" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:44 +msgid "sys.path modification" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:48 +msgid "Installs from :term:`Eggs `" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "`pylauncher support`_" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "Yes [1]_" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:54 +msgid ":ref:`Multi-version Installs`" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Exclude scripts during install" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "per project index" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Only in virtualenv" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Yes, via setup.cfg" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:68 +msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:5 +msgid "Wheel vs Egg" +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:7 +msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:11 +msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:14 +msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:17 +msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:20 +msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:22 +msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:26 +msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:31 +msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:34 +msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:38 +msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:41 +msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:47 +msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." +msgstr "" + +#: ../source/glossary.rst:3 +msgid "Glossary" +msgstr "" + +#: ../source/glossary.rst:8 +msgid "Binary Distribution" +msgstr "" + +#: ../source/glossary.rst:11 +msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." +msgstr "" + +#: ../source/glossary.rst:14 +msgid "Built Distribution" +msgstr "" + +#: ../source/glossary.rst:17 +msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." +msgstr "" + +#: ../source/glossary.rst:26 +msgid "Distribution Package" +msgstr "" + +#: ../source/glossary.rst:29 +msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." +msgstr "" + +#: ../source/glossary.rst:34 +msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." +msgstr "" + +#: ../source/glossary.rst:41 +msgid "Egg" +msgstr "" + +#: ../source/glossary.rst:44 +msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" +msgstr "" + +#: ../source/glossary.rst:49 +msgid "Extension Module" +msgstr "" + +#: ../source/glossary.rst:52 +msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." +msgstr "" + +#: ../source/glossary.rst:59 +msgid "Known Good Set (KGS)" +msgstr "" + +#: ../source/glossary.rst:62 +msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." +msgstr "" + +#: ../source/glossary.rst:68 +msgid "Import Package" +msgstr "" + +#: ../source/glossary.rst:71 +msgid "A Python module which can contain other modules or recursively, other packages." +msgstr "" + +#: ../source/glossary.rst:74 +msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." +msgstr "" + +#: ../source/glossary.rst:78 +msgid "Module" +msgstr "" + +#: ../source/glossary.rst:81 +msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." +msgstr "" + +#: ../source/glossary.rst:84 +msgid "Package Index" +msgstr "" + +#: ../source/glossary.rst:87 +msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." +msgstr "" + +#: ../source/glossary.rst:90 +msgid "Per Project Index" +msgstr "" + +#: ../source/glossary.rst:93 +msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." +msgstr "" + +#: ../source/glossary.rst:97 +msgid "Project" +msgstr "" + +#: ../source/glossary.rst:100 +msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." +msgstr "" + +#: ../source/glossary.rst:104 +msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." +msgstr "" + +#: ../source/glossary.rst:110 +msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." +msgstr "" + +#: ../source/glossary.rst:115 +msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." +msgstr "" + +#: ../source/glossary.rst:121 +msgid "Pure Module" +msgstr "" + +#: ../source/glossary.rst:124 +msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." +msgstr "" + +#: ../source/glossary.rst:127 +msgid "Python Packaging Authority (PyPA)" +msgstr "" + +#: ../source/glossary.rst:130 +msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." +msgstr "" + +#: ../source/glossary.rst:139 +msgid "Python Package Index (PyPI)" +msgstr "" + +#: ../source/glossary.rst:142 +msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." +msgstr "" + +#: ../source/glossary.rst:145 +msgid "pypi.org" +msgstr "" + +#: ../source/glossary.rst:148 +msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." +msgstr "" + +#: ../source/glossary.rst:152 +msgid "pyproject.toml" +msgstr "" + +#: ../source/glossary.rst:155 +msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." +msgstr "" + +#: ../source/glossary.rst:157 +msgid "Release" +msgstr "" + +#: ../source/glossary.rst:160 +msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." +msgstr "" + +#: ../source/glossary.rst:163 +msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." +msgstr "" + +#: ../source/glossary.rst:168 +msgid "Requirement" +msgstr "" + +#: ../source/glossary.rst:171 +msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." +msgstr "" + +#: ../source/glossary.rst:177 +msgid "Requirement Specifier" +msgstr "" + +#: ../source/glossary.rst:180 +msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" +msgstr "" + +#: ../source/glossary.rst:187 +msgid "Requirements File" +msgstr "" + +#: ../source/glossary.rst:190 +msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." +msgstr "" + +#: ../source/glossary.rst:194 +#: ../source/guides/distributing-packages-using-setuptools.rst:56 +msgid "setup.py" +msgstr "" + +#: ../source/glossary.rst:195 +#: ../source/guides/distributing-packages-using-setuptools.rst:77 +msgid "setup.cfg" +msgstr "" + +#: ../source/glossary.rst:198 +msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." +msgstr "" + +#: ../source/glossary.rst:201 +msgid "Source Archive" +msgstr "" + +#: ../source/glossary.rst:204 +msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:208 +msgid "Source Distribution (or \"sdist\")" +msgstr "" + +#: ../source/glossary.rst:211 +msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:216 +msgid "System Package" +msgstr "" + +#: ../source/glossary.rst:219 +msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." +msgstr "" + +#: ../source/glossary.rst:222 +msgid "Version Specifier" +msgstr "" + +#: ../source/glossary.rst:225 +msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." +msgstr "" + +#: ../source/glossary.rst:231 +msgid "Virtual Environment" +msgstr "" + +#: ../source/glossary.rst:234 +msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/glossary.rst:238 +msgid "Wheel" +msgstr "" + +#: ../source/glossary.rst:241 +msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." +msgstr "" + +#: ../source/glossary.rst:244 +msgid "Working Set" +msgstr "" + +#: ../source/glossary.rst:247 +msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:3 +msgid "Analyzing PyPI package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:5 +msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:15 +#: ../source/guides/supporting-windows-using-appveyor.rst:18 +msgid "Background" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:17 +msgid "PyPI does not display download statistics for a number of reasons: [#]_" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:19 +msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:24 +msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:27 +msgid "``pip``'s download cache (lowers download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:28 +msgid "Internal or unofficial mirrors (can both raise or lower download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:29 +msgid "Packages not hosted on PyPI (for comparisons sake)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:30 +msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:32 +msgid "Known historical data quality issues (lowers download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:34 +msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:38 +msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:43 +msgid "Public dataset" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:45 +msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:50 +msgid "Getting set up" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:52 +msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:58 +msgid "Navigate to the `BigQuery web UI`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:59 +msgid "Create a new project." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:60 +msgid "Enable the `BigQuery API `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:63 +msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:69 +msgid "Data schema" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:71 +msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +msgid "Column" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/guides/using-manifest-in.rst:67 +#: ../source/specifications/core-metadata.rst:185 +msgid "Description" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/specifications/direct-url.rst:226 +msgid "Examples" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "timestamp" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "Date and time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "``2020-03-09 00:33:03 UTC``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "file.project" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "Project name" +msgstr "Название проекта" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "``pipenv``, ``nose``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "file.version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "Package version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "``0.1.6``, ``1.4.2``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "details.installer.name" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "Installer" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "pip, `bandersnatch`_" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "details.python" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "Python version" +msgstr "Версия Python’а" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "``2.7.12``, ``3.6.4``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:93 +msgid "Useful queries" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:95 +msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:97 +msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:102 +msgid "Counting package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:104 +msgid "The following query counts the total number of downloads for the project \"pytest\"." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:119 +#: ../source/guides/analyzing-pypi-package-downloads.rst:140 +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "num_downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:121 +msgid "26190085" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:124 +msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:142 +msgid "24334215" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:146 +msgid "Package downloads over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:148 +msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +msgid "month" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "1956741" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "2018-01-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2344692" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2017-12-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "1730398" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "2017-11-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2047310" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2017-10-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "1744443" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "2017-09-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "1916952" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "2017-08-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:184 +msgid "Python versions over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:186 +msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "python" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "3.7" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "18051328726" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "3.6" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "9635067203" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "3.8" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "7781904681" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "2.7" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "6381252241" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "null" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "2026630299" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "3.5" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "1894153540" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:221 +msgid "Caveats" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:223 +msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:231 +msgid "Additional tools" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:233 +msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:237 +msgid "``google-cloud-bigquery``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:239 +msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:267 +msgid "``pypinfo``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:269 +msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:273 +msgid "Install `pypinfo`_ using pip." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:279 +msgid "Usage:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:295 +msgid "``pandas-gbq``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:297 +msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:301 +#: ../source/specifications/binary-distribution-format.rst:459 +msgid "References" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:303 +msgid "`PyPI Download Counts deprecation email `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:304 +msgid "`PyPI BigQuery dataset announcement email `__" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:3 +msgid "Creating and discovering plugins" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:5 +msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:10 +msgid "There are three major approaches to doing automatic plugin discovery:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:12 +msgid "`Using naming convention`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:13 +msgid "`Using namespace packages`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:14 +msgid "`Using package metadata`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:18 +msgid "Using naming convention" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:20 +msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:38 +msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:48 +msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:59 +msgid "Using namespace packages" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:61 +msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:89 +msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:101 +msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:115 +msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:121 +msgid "Using package metadata" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:123 +msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:128 +msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:139 +msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:154 +msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:163 +msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:166 +msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:170 +msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:5 +msgid "Packaging and distributing projects" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:7 +msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:11 +msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:15 +msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:25 +msgid "Requirements for packaging and distributing" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:26 +msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:29 +msgid "Install \"twine\" [1]_:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:43 +msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:49 +msgid "Configuring your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:53 +msgid "Initial files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:58 +msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:63 +msgid ":file:`setup.py` serves two primary functions:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:65 +msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:71 +msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:79 +msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:86 +msgid "README.rst / README.md" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:88 +msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:95 +msgid "For an example, see `README.md `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:99 +msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:108 +msgid "MANIFEST.in" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:110 +msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:115 +msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:119 +msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:122 +msgid "LICENSE.txt" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:124 +msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:130 +msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:135 +msgid "" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:137 +msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:141 +msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:149 +msgid "setup() args" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:151 +msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:155 +msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:164 +msgid "name" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:170 +msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:174 +msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:176 +msgid "Start & end with an ASCII letter or digit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:178 +msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:190 +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "version" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:196 +msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:200 +msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:203 +msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:206 +msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:214 +msgid "description" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:222 +msgid "Give a short and long description for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:224 +msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:229 +msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:235 +msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:245 +msgid "url" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:252 +msgid "Give a homepage URL for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:256 +msgid "author" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:263 +msgid "Provide details about the author." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:267 +msgid "license" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:273 +msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:279 +msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:287 +msgid "classifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:316 +msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:319 +msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:327 +msgid "keywords" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:333 +msgid "List keywords that describe your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:337 +msgid "project_urls" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:349 +msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:355 +msgid "packages" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:361 +msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:370 +msgid "py_modules" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:376 +msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:388 +msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:392 +msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:398 +msgid "python_requires" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:400 +msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:407 +msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:412 +msgid "And so on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:416 +msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:422 +msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:431 +msgid "package_data" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:440 +msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:445 +msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:449 +msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:457 +msgid "data_files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:463 +msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:469 +msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:479 +msgid "For more information see the distutils section on `Installing Additional Files `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:484 +msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:491 +msgid "scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:493 +msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:500 +msgid "entry_points" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:509 +msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:512 +msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:516 +msgid "The most commonly used entry point is \"console_scripts\" (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:521 +msgid "console_scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:531 +msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:538 +msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:545 +msgid "Choosing a versioning scheme" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:548 +msgid "Standards compliance for interoperability" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:550 +msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:556 +msgid "Here are some examples of compliant version numbers::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:567 +msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:573 +msgid "Scheme choices" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:576 +msgid "Semantic versioning (preferred)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:578 +msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:582 +msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:585 +msgid "MAJOR version when they make incompatible API changes," +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:586 +msgid "MINOR version when they add functionality in a backwards-compatible manner, and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:587 +msgid "MAINTENANCE version when they make backwards-compatible bug fixes." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:589 +msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:594 +msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:598 +msgid "Date based versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:600 +msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:604 +msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:607 +msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:611 +msgid "Serial versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:613 +msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:616 +msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:621 +msgid "Hybrid schemes" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:623 +msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:629 +msgid "Pre-release versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:631 +msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:634 +msgid "zero or more dev releases (denoted with a \".devN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:635 +msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:636 +msgid "zero or more beta releases (denoted with a \".bN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:637 +msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:639 +msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:644 +msgid "Local version identifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:646 +msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:653 +msgid "A local version identifier takes the form ``+``. For example::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:661 +msgid "Working in \"development mode\"" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:663 +msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:667 +msgid "Assuming you're in the root of your project directory, then run:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:674 +msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:680 +msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:688 +msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:692 +msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:697 +msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:701 +msgid "Lastly, if you don't want to install any dependencies at all, you can run::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:706 +msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:713 +msgid "Packaging your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:715 +msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:720 +msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:737 +msgid "Source distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:739 +msgid "Minimally, you should create a :term:`Source Distribution `:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:755 +msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:763 +msgid "Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:765 +msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:770 +msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:773 +msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:776 +msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:785 +msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:792 +msgid "Pure Python Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:794 +msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:797 +#: ../source/guides/distributing-packages-using-setuptools.rst:826 +msgid "To build the wheel:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:811 +msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:815 +msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:821 +msgid "Platform Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:823 +msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:841 +msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:847 +msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:855 +msgid "Uploading your Project to PyPI" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:857 +msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:861 +msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:866 +msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:871 +msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:877 +msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:888 +msgid "Create an account" +msgstr "Создание учётной записи" + +#: ../source/guides/distributing-packages-using-setuptools.rst:890 +msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:894 +msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:897 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:901 +msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:904 +msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:913 +msgid "**Be aware that this stores your token in plaintext.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:915 +#: ../source/guides/migrating-to-pypi-org.rst:70 +#: ../source/guides/migrating-to-pypi-org.rst:109 +#: ../source/guides/using-testpypi.rst:83 +msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:921 +msgid "Upload your distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:923 +msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:926 +msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:930 +msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:937 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:944 +#: ../source/tutorials/installing-packages.rst:663 +msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:950 +msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:5 +msgid "Dropping support for older Python versions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:7 +msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:9 +msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:12 +msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:14 +msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:17 +msgid "Requirements" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:19 +msgid "This workflow requires that:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:21 +msgid "The publisher is using the latest version of :ref:`setuptools`," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:22 +msgid "The latest version of :ref:`twine` is used to upload the package," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:23 +msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:26 +msgid "Dealing with the universal wheels" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:28 +msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:36 +msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:48 +msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:53 +msgid "Defining the Python version required" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:56 +msgid "1. Download the newest version of Setuptools" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:58 +msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:60 +msgid "Steps:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:74 +msgid "`setuptools` version should be above 24.0.0." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:77 +msgid "2. Specify the version ranges for supported Python distributions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:79 +msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:81 +#: ../source/specifications/core-metadata.rst:139 +#: ../source/specifications/core-metadata.rst:463 +#: ../source/specifications/core-metadata.rst:487 +#: ../source/specifications/core-metadata.rst:527 +#: ../source/specifications/core-metadata.rst:550 +#: ../source/specifications/core-metadata.rst:583 +#: ../source/specifications/core-metadata.rst:693 +#: ../source/specifications/core-metadata.rst:722 +msgid "Examples::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:86 +msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:101 +msgid "3. Validating the Metadata before publishing" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:103 +msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:105 +msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:108 +msgid "You can see the contents of the generated file like this::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:112 +msgid "Validate that the following is in place, before publishing the package:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:114 +msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:115 +msgid "The Requires-Python field is set and matches your specification in setup.py." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:118 +msgid "4. Using Twine to publish" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:120 +msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:122 +msgid "Make sure you are using the newest version of Twine, at least 1.9." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:125 +msgid "Dropping a Python release" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:127 +msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:129 +msgid "It must be done in this order for the automated fallback to work." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:131 +msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:133 +msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:5 +msgid "Hosting your own simple repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:8 +msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:13 +msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:29 +msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:35 +msgid "\"Manual\" repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:37 +msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:51 +msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:58 +msgid "For complete documentation of the simple repository protocol, see :pep:`503`." +msgstr "" + +#: ../source/guides/index.rst:8 +#: ../source/guides/index.rst:8 +msgid "Installing Packages:" +msgstr "" + +#: ../source/guides/index.rst:20 +#: ../source/guides/index.rst:20 +msgid "Building and Publishing Projects:" +msgstr "" + +#: ../source/guides/index.rst:38 +#: ../source/guides/index.rst:38 +msgid "Miscellaneous:" +msgstr "" + +#: ../source/guides/index.rst:4 +msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:5 +msgid "Package index mirrors and caches" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:8 +#: ../source/guides/supporting-multiple-python-versions.rst:8 +msgid "2014-12-24" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:14 +msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:17 +msgid "Three options are available in this area:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:19 +msgid "pip provides local caching options," +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:20 +msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:22 +msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:27 +msgid "Caching with pip" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:29 +msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:32 +msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:36 +msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:45 +msgid "Caching with devpi" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:47 +msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:55 +msgid "Complete mirror with bandersnatch" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:57 +msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:63 +msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:5 +msgid "Installing scientific packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:11 +msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:16 +msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:22 +msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:29 +msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:35 +msgid "Building from source" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:37 +msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:45 +msgid "Linux distribution packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:47 +msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:51 +msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:57 +msgid "Windows installers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:59 +msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:64 +msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:67 +msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:73 +msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:79 +msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:86 +msgid "macOS installers and package managers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:88 +msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:92 +msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:99 +msgid "SciPy distributions" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:101 +msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:105 +msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:109 +#: ../source/key_projects.rst:596 +msgid "Spack" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:110 +msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:119 +msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:128 +msgid "The conda cross-platform package manager" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:130 +msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:136 +msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 +msgid "Installing stand alone command line tools" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 +msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 +msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 +msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 +msgid "pipx only works with Python 3.6+." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 +msgid "``pipx`` is installed with ``pip``:" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 +msgid "You may need to restart your terminal for the path updates to take effect." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 +msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 +#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 +msgid "For example" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 +msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 +msgid "To upgrade or uninstall the package" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 +msgid "``pipx`` can be upgraded or uninstalled with pip" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 +msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 +msgid "To see the full list of commands ``pipx`` offers, run" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 +msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:5 +msgid "Installing pip/setuptools/wheel with Linux Package Managers" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:8 +msgid "2015-09-17" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:11 +msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:14 +msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:18 +msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:25 +msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:32 +msgid "Fedora" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:34 +msgid "Fedora 21:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:36 +#: ../source/guides/installing-using-linux-tools.rst:45 +#: ../source/guides/installing-using-linux-tools.rst:124 +#: ../source/guides/installing-using-linux-tools.rst:138 +#: ../source/guides/installing-using-linux-tools.rst:158 +msgid "Python 2::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:41 +msgid "Python 3: ``sudo yum install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:43 +msgid "Fedora 22:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:50 +msgid "Python 3: ``sudo dnf install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:53 +msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:63 +msgid "CentOS/RHEL" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:65 +msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:68 +msgid "To install pip and wheel for the system Python, there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:70 +msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:77 +msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:81 +msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:85 +msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:92 +msgid "To additionally upgrade setuptools, run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:97 +msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:101 +msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:104 +msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:106 +msgid "For CentOS, see here: https://www.softwarecollections.org/en/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:108 +msgid "Be aware that collections may not contain the most recent versions." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:110 +msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:116 +msgid "For example, for Python 3.4 on CentOS7/RHEL7::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:122 +msgid "openSUSE" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:129 +#: ../source/guides/installing-using-linux-tools.rst:143 +#: ../source/guides/installing-using-linux-tools.rst:162 +msgid "Python 3::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:135 +msgid "Debian/Ubuntu" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:150 +msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:156 +msgid "Arch Linux" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:168 +msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 +msgid "Installing packages using pip and virtual environments" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 +msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 +msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 +msgid "Installing pip" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 +msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 +msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 +msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 +msgid "Afterwards, you should have the newest pip installed in your user site:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 +msgid "The Python installers for Windows include pip. You should be able to access pip using:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 +msgid "You can make sure that pip is up-to-date by running:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 +msgid "Installing virtualenv" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 +msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 +msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 +msgid "Creating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 +msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 +msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 +msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 +msgid "venv will create a virtual Python installation in the ``env`` folder." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 +msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 +msgid "Activating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 +msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 +msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 +msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 +msgid "Leaving the virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 +msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 +msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 +msgid "Installing packages" +msgstr "Установка пакетов" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 +msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 +msgid "pip should download requests and all of its dependencies and install them:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 +msgid "Installing specific versions" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 +msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 +msgid "To install the latest ``2.x`` release of requests:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 +msgid "To install pre-release versions of packages, use the ``--pre`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 +msgid "Installing extras" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 +msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 +msgid "Installing from source" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 +msgid "pip can install a package directly from source, for example:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 +msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 +msgid "Installing from version control systems" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 +msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 +msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 +#: ../source/tutorials/installing-packages.rst:569 +msgid "Installing from local archives" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 +msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 +msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 +msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 +msgid "Using other package indexes" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 +msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 +msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 +#: ../source/tutorials/installing-packages.rst:389 +msgid "Upgrading packages" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 +msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 +msgid "Using requirements files" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 +msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 +msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 +msgid "Freezing dependencies" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 +msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 +msgid "Which will output a list of package specifiers such as:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 +msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:2 +msgid "Making a PyPI-friendly README" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:4 +msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:9 +msgid "Creating a README file" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:11 +msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:13 +msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:16 +msgid "plain text" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:17 +msgid "`reStructuredText `_ (without Sphinx extensions)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:18 +msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:21 +msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:25 +msgid "Including your README in your package's metadata" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:27 +msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:33 +msgid ":ref:`description-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:34 +msgid ":ref:`description-content-type-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:36 +msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:39 +msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:45 +msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:60 +msgid "The minimum required versions of the respective tools are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:62 +msgid "``setuptools >= 38.6.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:63 +msgid "``wheel >= 0.31.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:64 +msgid "``twine >= 1.11.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:66 +msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:72 +msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:95 +msgid "Validating reStructuredText markup" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:97 +msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:100 +msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:105 +msgid "You can check your README for markup errors before uploading as follows:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:107 +msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:122 +msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:125 +msgid "Run ``twine check`` on the sdist and wheel::" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:129 +msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:4 +msgid "Migrating to PyPI.org" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:6 +msgid ":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``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:12 +msgid "Publishing releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:14 +msgid "``pypi.org`` is the default upload platform as of September 2016." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:16 +msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:22 +msgid "The default upload settings switched to ``pypi.org`` in the following versions:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:24 +msgid "``twine`` 1.8.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:25 +msgid "``setuptools`` 27.0.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:26 +msgid "Python 2.7.13 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:27 +msgid "Python 3.4.6 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:28 +msgid "Python 3.5.3 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:29 +msgid "Python 3.6.0 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:31 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:48 +msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:51 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:67 +msgid "(``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.)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:73 +msgid "Registering package names & metadata" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:75 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:79 +msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:84 +msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:89 +#: ../source/guides/using-testpypi.rst:5 +msgid "Using TestPyPI" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:91 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:113 +msgid "Registering new user accounts" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:115 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:121 +msgid "Browsing packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:123 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:130 +msgid "Downloading packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:132 +msgid "``pypi.org`` is the default host for downloading packages." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:135 +msgid "Managing published packages and releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:137 +msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:5 +msgid "Multi-version installs" +msgstr "" + +#: ../source/guides/multi-version-installs.rst:8 +msgid "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``)." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:13 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:31 +msgid "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 ``python -c ''`` to invoke the application's main entry point directly." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:38 +msgid "Refer to the `pkg_resources documentation `__ for more details." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:5 +msgid "Packaging binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:8 +msgid "2013-12-08" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:10 +msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:20 +msgid "An overview of binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:23 +msgid "Use cases" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:25 +msgid "The typical use cases for binary extensions break down into just three conventional categories:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:28 +msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:39 +msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:47 +msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:56 +msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:61 +msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:71 +msgid "Disadvantages" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:73 +msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:80 +msgid "This means that binary extensions:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:82 +msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:85 +msgid "may not be compatible with different builds of the CPython reference interpreter" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:88 +msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:91 +msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:96 +msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:101 +msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:108 +msgid "Alternatives to handcoded accelerator modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:110 +msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:115 +msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:122 +msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:132 +msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:141 +msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:150 +msgid "Alternatives to handcoded wrapper modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:152 +msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:158 +msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:162 +msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:168 +msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:175 +msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:181 +msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:185 +msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:189 +msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:203 +msgid "Alternatives for low level system access" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:205 +msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:213 +msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:222 +msgid "Implementing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:224 +msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:241 +msgid "Building binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:244 +msgid "Building extensions for multiple platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:246 +msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:256 +msgid "Binary extensions for Windows" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:258 +msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:263 +msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:269 +msgid "To set up a build environment for binary extensions, the steps are as follows:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:271 +msgid "For Python 2.7" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:273 +msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:276 +msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:278 +#: ../source/guides/packaging-binary-extensions.rst:288 +#: ../source/guides/packaging-binary-extensions.rst:295 +msgid "Done." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:280 +msgid "For Python 3.4" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:282 +msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:285 +msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:287 +msgid "Set DISTUTILS_USE_SDK=1" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:290 +msgid "For Python 3.5" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:292 +msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:297 +msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:301 +msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:305 +msgid "Binary extensions for Linux" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:307 +msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:313 +msgid "Binary extensions for macOS" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:315 +msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:325 +msgid "Publishing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:327 +msgid "For interim guidance on this topic, see the discussion in `this issue `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:343 +msgid "Additional resources" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:345 +msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:352 +msgid "Cross-platform wheel generation with scikit-build" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:354 +msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:362 +msgid "Introduction to C/C++ extension modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:364 +msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:367 +msgid "`What are (c)python extension modules? `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:368 +msgid "`Releasing the gil `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:369 +msgid "`Writing cpython extension modules using C++ `_" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:3 +msgid "Packaging namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:5 +msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:24 +msgid "And you use this package in your code like so::" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:29 +msgid "Then you can break these sub-packages into two separate distributions:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:46 +msgid "Each sub-package can now be separately installed, used, and versioned." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:48 +msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:58 +msgid "Creating a namespace package" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:60 +msgid "There are currently three different approaches to creating namespace packages:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:62 +msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:66 +msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:69 +msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:73 +msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:80 +msgid "Native namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:82 +msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:97 +msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:102 +msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:117 +msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:123 +msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:129 +msgid "pkgutil-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:131 +msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:136 +msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:148 +#: ../source/guides/packaging-namespace-packages.rst:194 +msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:155 +#: ../source/guides/packaging-namespace-packages.rst:201 +msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:160 +msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:171 +msgid "pkg_resources-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:173 +msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:182 +msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:206 +msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:216 +msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:223 +msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:237 +msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 +msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 +msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 +msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 +msgid "Saving credentials on GitHub" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 +msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 +msgid "Let's begin! 🚀" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 +msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 +msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 +msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 +msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 +msgid "Creating a workflow definition" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 +msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 +msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 +msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 +msgid "Defining a workflow job environment" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 +msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 +msgid "Checking out the project and building distributions" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 +msgid "Then, add the following under the ``build-n-publish`` section:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 +msgid "This will download your repository into the CI runner and then install and activate Python 3.7." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 +msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 +msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 +msgid "So add this to the steps list:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 +msgid "Publishing the distribution to PyPI and TestPyPI" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 +msgid "Finally, add the following steps at the end:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 +msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 +msgid "That's all, folks!" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 +msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:5 +msgid "Single-sourcing the package version" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:8 +msgid "There are many techniques to maintain a single source of truth for the version number of your project:" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:11 +msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:38 +msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:47 +msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:52 +msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:55 +msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:58 +msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:65 +msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:76 +msgid "Example using this technique: `warehouse `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:78 +msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:86 +msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:91 +msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:95 +msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:110 +msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:114 +msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:128 +msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:134 +msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:138 +msgid "Example using this technique: `setuptools `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:141 +msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:155 +msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:161 +msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:5 +msgid "Supporting multiple Python versions" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:37 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:43 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:49 +msgid "Automated testing and continuous integration" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:51 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:60 +msgid "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:" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:66 +msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:69 +msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:80 +msgid "Both `Travis CI`_ 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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:85 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:89 +msgid "Tools for single-source Python packages" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:91 +msgid "`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_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:100 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:107 +msgid "a Python 2 (by syntax) module in a Python 3 project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:108 +msgid "a Python 3 (by syntax) module in a *Python 2* project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:110 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:117 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:124 +msgid "What's in which Python?" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:126 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:3 +msgid "Supporting Windows using Appveyor" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:6 +msgid "2015-12-03" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:8 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:20 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:24 +msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:30 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:38 +msgid "Setting up" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:40 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:45 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:49 +msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:54 +msgid "Adding Appveyor support to your project" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:61 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:69 +msgid "appveyor.yml" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:75 +msgid "This file can be downloaded from `here `__." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:77 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:80 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:88 +msgid "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``)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:94 +msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:97 +msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:100 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:109 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:114 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:119 +msgid "Support script" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:121 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:126 +msgid "`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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:133 +msgid "You can simply download the batch file and include it in your project unchanged." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:137 +msgid "Access to the built wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:139 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:147 +msgid "Additional notes" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:150 +msgid "Testing with tox" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:152 +msgid "Many projects use the `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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:156 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:160 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:165 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:170 +msgid "``DISTUTILS_USE_SDK``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:171 +msgid "``MSSdk``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:172 +msgid "``INCLUDE``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:173 +msgid "``LIB``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:175 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:181 +msgid "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 Travis or 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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:188 +msgid "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``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:192 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:197 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:203 +msgid "Automatically uploading wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:205 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:210 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:216 +msgid "External dependencies" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:218 +msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:221 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:230 +msgid "Support scripts" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:232 +msgid "For reference, the SDK setup support script is listed here:" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:234 +msgid "``appveyor-sample/build.cmd``" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:5 +msgid "Tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:7 +msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:12 +msgid "Application dependency management" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:14 +msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:18 +msgid "When ``pipenv`` does not meet your use case, consider other tools like:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:20 +msgid ":ref:`pip`" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:22 +msgid "`pip-tools `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:24 +msgid "`Poetry `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:27 +msgid "Installation tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:29 +msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:34 +msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:37 +msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:40 +msgid ":ref:`buildout`: primarily focused on the web development community" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:42 +msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:47 +msgid "Packaging tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:49 +msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:52 +msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:56 +msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:61 +msgid "Publishing platform migration" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:63 +msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:67 +msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:72 +msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:77 +msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:82 +msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:88 +msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:93 +msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:102 +msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:107 +msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:5 +msgid "Including files in source distributions with ``MANIFEST.in``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:7 +msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:17 +msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:22 +msgid "How files are included in an sdist" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:24 +msgid "The following files are included in a source distribution by default:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:26 +msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:28 +msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:30 +msgid "scripts specified by the ``scripts`` ``setup()`` argument" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:31 +msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:33 +msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:35 +msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:37 +msgid "all files matching the pattern :file:`test/test*.py`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:38 +msgid ":file:`setup.py` (or whatever you called your setup script)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:39 +msgid ":file:`setup.cfg`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:40 +msgid ":file:`README`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:41 +msgid ":file:`README.txt`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:42 +msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:43 +msgid ":file:`README.md` (setuptools 36.4.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:44 +msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:45 +msgid ":file:`MANIFEST.in`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:47 +msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:52 +msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:60 +msgid ":file:`MANIFEST.in` commands" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:62 +msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:67 +msgid "Command" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid ":samp:`include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid "Add all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid ":samp:`exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid "Remove all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid ":samp:`global-include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid "Add all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid ":samp:`global-exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid "Remove all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid ":samp:`graft {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid "Add all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid ":samp:`prune {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid "Remove all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:79 +msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:87 +msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:91 +msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:95 +msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:101 +msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." +msgstr "" + +#: ../source/guides/using-testpypi.rst:7 +msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" +msgstr "" + +#: ../source/guides/using-testpypi.rst:13 +msgid "Registering your account" +msgstr "" + +#: ../source/guides/using-testpypi.rst:15 +msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." +msgstr "" + +#: ../source/guides/using-testpypi.rst:19 +msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." +msgstr "" + +#: ../source/guides/using-testpypi.rst:24 +msgid "Using TestPyPI with Twine" +msgstr "" + +#: ../source/guides/using-testpypi.rst:26 +msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:33 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/using-testpypi.rst:39 +msgid "Using TestPyPI with pip" +msgstr "" + +#: ../source/guides/using-testpypi.rst:41 +msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:56 +msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" +msgstr "" + +#: ../source/guides/using-testpypi.rst:73 +msgid "Setting up TestPyPI in :file:`.pypirc`" +msgstr "" + +#: ../source/guides/using-testpypi.rst:75 +msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" +msgstr "" + +#: ../source/index.rst:3 +#: ../source/key_projects.rst:181 +msgid "Python Packaging User Guide" +msgstr "Руководство пользователя по созданию Python’ьих пакетов" + +#: ../source/index.rst:5 +msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." +msgstr "" + +#: ../source/index.rst:5 +msgid "python, packaging, guide, tutorial" +msgstr "" + +#: ../source/index.rst:24 +msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." +msgstr "" + +#: ../source/index.rst:28 +msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" +msgstr "" + +#: ../source/index.rst:36 +msgid "Get started" +msgstr "" + +#: ../source/index.rst:38 +msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" +msgstr "" + +#: ../source/index.rst:41 +msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" +msgstr "" + +#: ../source/index.rst:43 +msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" +msgstr "" + +#: ../source/index.rst:45 +msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" +msgstr "" + +#: ../source/index.rst:47 +msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" +msgstr "" + +#: ../source/index.rst:52 +msgid "Learn more" +msgstr "" + +#: ../source/index.rst:54 +msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" +msgstr "" + +#: ../source/index.rst:56 +msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/index.rst:58 +msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." +msgstr "" + +#: ../source/index.rst:60 +msgid "The :doc:`specifications/index` section for packaging interoperability specifications." +msgstr "" + +#: ../source/index.rst:62 +msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." +msgstr "" + +#: ../source/key_projects.rst:6 +msgid "Project Summaries" +msgstr "" + +#: ../source/key_projects.rst:8 +msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." +msgstr "" + +#: ../source/key_projects.rst:14 +msgid "PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:19 +msgid "bandersnatch" +msgstr "" + +#: ../source/key_projects.rst:21 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:25 +msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." +msgstr "" + +#: ../source/key_projects.rst:35 +msgid "build" +msgstr "" + +#: ../source/key_projects.rst:37 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:42 +msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." +msgstr "" + +#: ../source/key_projects.rst:49 +msgid "cibuildwheel" +msgstr "" + +#: ../source/key_projects.rst:51 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" +msgstr "" + +#: ../source/key_projects.rst:58 +msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." +msgstr "" + +#: ../source/key_projects.rst:64 +msgid "distlib" +msgstr "" + +#: ../source/key_projects.rst:66 +msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:71 +msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." +msgstr "" + +#: ../source/key_projects.rst:80 +msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." +msgstr "" + +#: ../source/key_projects.rst:90 +msgid "packaging" +msgstr "" + +#: ../source/key_projects.rst:92 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:97 +msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." +msgstr "" + +#: ../source/key_projects.rst:99 +msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." +msgstr "" + +#: ../source/key_projects.rst:107 +msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." +msgstr "" + +#: ../source/key_projects.rst:119 +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "pip" +msgstr "" + +#: ../source/key_projects.rst:121 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:126 +msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." +msgstr "" + +#: ../source/key_projects.rst:129 +msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." +msgstr "" + +#: ../source/key_projects.rst:137 +msgid "Pipenv" +msgstr "" + +#: ../source/key_projects.rst:139 +msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:144 +msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." +msgstr "" + +#: ../source/key_projects.rst:148 +msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." +msgstr "" + +#: ../source/key_projects.rst:159 +msgid "Pipfile" +msgstr "" + +#: ../source/key_projects.rst:161 +msgid "`Source `__" +msgstr "" + +#: ../source/key_projects.rst:163 +msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." +msgstr "" + +#: ../source/key_projects.rst:170 +msgid "pipx" +msgstr "" + +#: ../source/key_projects.rst:172 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:176 +msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." +msgstr "" + +#: ../source/key_projects.rst:183 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:187 +msgid "This guide!" +msgstr "" + +#: ../source/key_projects.rst:192 +msgid "readme_renderer" +msgstr "" + +#: ../source/key_projects.rst:194 +msgid "`GitHub and docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:197 +msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." +msgstr "" + +#: ../source/key_projects.rst:208 +msgid "setuptools" +msgstr "" + +#: ../source/key_projects.rst:210 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:215 +msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." +msgstr "" + +#: ../source/key_projects.rst:220 +msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." +msgstr "" + +#: ../source/key_projects.rst:227 +msgid "trove-classifiers" +msgstr "" + +#: ../source/key_projects.rst:229 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:233 +msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." +msgstr "" + +#: ../source/key_projects.rst:239 +msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." +msgstr "" + +#: ../source/key_projects.rst:253 +msgid "twine" +msgstr "" + +#: ../source/key_projects.rst:255 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:260 +msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." +msgstr "" + +#: ../source/key_projects.rst:270 +#: ../source/overview.rst:415 +msgid "virtualenv" +msgstr "" + +#: ../source/key_projects.rst:272 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:277 +msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/key_projects.rst:290 +msgid "Warehouse" +msgstr "" + +#: ../source/key_projects.rst:292 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:296 +msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." +msgstr "" + +#: ../source/key_projects.rst:304 +msgid "wheel" +msgstr "" + +#: ../source/key_projects.rst:306 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:311 +msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." +msgstr "" + +#: ../source/key_projects.rst:315 +msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." +msgstr "" + +#: ../source/key_projects.rst:324 +msgid "Non-PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:329 +msgid "bento" +msgstr "" + +#: ../source/key_projects.rst:331 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:336 +msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." +msgstr "" + +#: ../source/key_projects.rst:344 +msgid "buildout" +msgstr "" + +#: ../source/key_projects.rst:346 +msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:351 +msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." +msgstr "" + +#: ../source/key_projects.rst:358 +msgid "conda" +msgstr "" + +#: ../source/key_projects.rst:360 +msgid "`Docs `__" +msgstr "" + +#: ../source/key_projects.rst:362 +msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." +msgstr "" + +#: ../source/key_projects.rst:369 +msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." +msgstr "" + +#: ../source/key_projects.rst:373 +msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." +msgstr "" + +#: ../source/key_projects.rst:386 +msgid "devpi" +msgstr "" + +#: ../source/key_projects.rst:388 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:392 +msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." +msgstr "" + +#: ../source/key_projects.rst:401 +msgid "flit" +msgstr "" + +#: ../source/key_projects.rst:403 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:407 +msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." +msgstr "" + +#: ../source/key_projects.rst:412 +msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." +msgstr "" + +#: ../source/key_projects.rst:422 +msgid "enscons" +msgstr "" + +#: ../source/key_projects.rst:424 +msgid "`Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:428 +msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." +msgstr "" + +#: ../source/key_projects.rst:443 +msgid "Hashdist" +msgstr "" + +#: ../source/key_projects.rst:445 +msgid "`Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:448 +msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." +msgstr "" + +#: ../source/key_projects.rst:460 +msgid "hatch" +msgstr "" + +#: ../source/key_projects.rst:462 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:465 +msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." +msgstr "" + +#: ../source/key_projects.rst:475 +msgid "multibuild" +msgstr "" + +#: ../source/key_projects.rst:477 +msgid "`GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:479 +msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." +msgstr "" + +#: ../source/key_projects.rst:485 +msgid "pex" +msgstr "" + +#: ../source/key_projects.rst:487 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:491 +msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." +msgstr "" + +#: ../source/key_projects.rst:500 +msgid "pip-tools" +msgstr "" + +#: ../source/key_projects.rst:502 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:505 +msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." +msgstr "" + +#: ../source/key_projects.rst:517 +msgid "piwheels" +msgstr "" + +#: ../source/key_projects.rst:519 +msgid "`Website `__ | `Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:523 +msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." +msgstr "" + +#: ../source/key_projects.rst:532 +msgid "poetry" +msgstr "" + +#: ../source/key_projects.rst:534 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:538 +msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." +msgstr "" + +#: ../source/key_projects.rst:548 +msgid "pypiserver" +msgstr "" + +#: ../source/key_projects.rst:550 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:554 +msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." +msgstr "" + +#: ../source/key_projects.rst:564 +msgid "scikit-build" +msgstr "" + +#: ../source/key_projects.rst:566 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:570 +msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." +msgstr "" + +#: ../source/key_projects.rst:582 +msgid "shiv" +msgstr "" + +#: ../source/key_projects.rst:584 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:588 +msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." +msgstr "" + +#: ../source/key_projects.rst:598 +msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" +msgstr "" + +#: ../source/key_projects.rst:603 +msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." +msgstr "" + +#: ../source/key_projects.rst:611 +msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." +msgstr "" + +#: ../source/key_projects.rst:617 +msgid "zest.releaser" +msgstr "" + +#: ../source/key_projects.rst:619 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:623 +msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." +msgstr "" + +#: ../source/key_projects.rst:630 +msgid "Standard Library Projects" +msgstr "" + +#: ../source/key_projects.rst:635 +msgid "ensurepip" +msgstr "" + +#: ../source/key_projects.rst:637 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:640 +msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." +msgstr "" + +#: ../source/key_projects.rst:649 +msgid "distutils" +msgstr "" + +#: ../source/key_projects.rst:651 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:654 +msgid "The original Python packaging system, added to the standard library in Python 2.0." +msgstr "" + +#: ../source/key_projects.rst:657 +msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." +msgstr "" + +#: ../source/key_projects.rst:670 +msgid "venv" +msgstr "" + +#: ../source/key_projects.rst:672 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:675 +msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/news.rst:2 +msgid "News" +msgstr "" + +#: ../source/news.rst:5 +msgid "September 2019" +msgstr "" + +#: ../source/news.rst:6 +msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" +msgstr "" + +#: ../source/news.rst:9 +msgid "August 2019" +msgstr "" + +#: ../source/news.rst:10 +msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" +msgstr "" + +#: ../source/news.rst:13 +msgid "July 2019" +msgstr "" + +#: ../source/news.rst:14 +msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" +msgstr "" + +#: ../source/news.rst:15 +msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" +msgstr "" + +#: ../source/news.rst:16 +msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" +msgstr "" + +#: ../source/news.rst:17 +msgid "Updated directory layout examples for consistency. (:pr:`611`)" +msgstr "" + +#: ../source/news.rst:18 +msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" +msgstr "" + +#: ../source/news.rst:21 +msgid "June 2019" +msgstr "" + +#: ../source/news.rst:22 +msgid "Fixed some typos. (:pr:`620`)" +msgstr "" + +#: ../source/news.rst:25 +msgid "May 2019" +msgstr "" + +#: ../source/news.rst:26 +msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" +msgstr "" + +#: ../source/news.rst:27 +msgid "Added a MANIFEST.in guide page. (:pr:`609`)" +msgstr "" + +#: ../source/news.rst:30 +msgid "April 2019" +msgstr "" + +#: ../source/news.rst:31 +msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" +msgstr "" + +#: ../source/news.rst:32 +msgid "Reduced emphasis on virtualenv. (:pr:`606`)" +msgstr "" + +#: ../source/news.rst:35 +msgid "March 2019" +msgstr "" + +#: ../source/news.rst:36 +msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" +msgstr "" + +#: ../source/news.rst:37 +msgid "Covered RTD details for contributing. (:pr:`600`)" +msgstr "" + +#: ../source/news.rst:40 +msgid "February 2019" +msgstr "" + +#: ../source/news.rst:41 +msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" +msgstr "" + +#: ../source/news.rst:42 +msgid "Added instructions to install Python CLI applications. (:pr:`594`)" +msgstr "" + +#: ../source/news.rst:45 +msgid "January 2019" +msgstr "" + +#: ../source/news.rst:46 +msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" +msgstr "" + +#: ../source/news.rst:47 +msgid "Updated Sphinx and Nox. (:pr:`591`)" +msgstr "" + +#: ../source/news.rst:48 +msgid "Referenced Twine from Python3. (:pr:`581`)" +msgstr "" + +#: ../source/news.rst:51 +msgid "December 2018" +msgstr "" + +#: ../source/news.rst:52 +msgid "No programmers in the office!" +msgstr "" + +#: ../source/news.rst:55 +msgid "November 2018" +msgstr "" + +#: ../source/news.rst:56 +msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" +msgstr "" + +#: ../source/news.rst:57 +msgid "Changed bumpversion to bump2version. (:pr:`572`)" +msgstr "" + +#: ../source/news.rst:58 +msgid "Added single-sourcing package version example. (:pr:`573`)" +msgstr "" + +#: ../source/news.rst:59 +msgid "Added a guide for creating documentation. (:pr:`568`)" +msgstr "" + +#: ../source/news.rst:62 +msgid "October 2018" +msgstr "" + +#: ../source/news.rst:63 +msgid "Updated Nox package name. (:pr:`566`)" +msgstr "" + +#: ../source/news.rst:64 +msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" +msgstr "" + +#: ../source/news.rst:67 +msgid "September 2018" +msgstr "" + +#: ../source/news.rst:68 +msgid "Added a section on checking RST markup. (:pr:`554`)" +msgstr "" + +#: ../source/news.rst:69 +msgid "Updated user installs page. (:pr:`558`)" +msgstr "" + +#: ../source/news.rst:70 +msgid "Updated Google BigQuery urls. (:pr:`556`)" +msgstr "" + +#: ../source/news.rst:71 +msgid "Replaced tar command with working command. (:pr:`552`)" +msgstr "" + +#: ../source/news.rst:72 +msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" +msgstr "" + +#: ../source/news.rst:75 +msgid "August 2018" +msgstr "" + +#: ../source/news.rst:76 +msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" +msgstr "" + +#: ../source/news.rst:77 +msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" +msgstr "" + +#: ../source/news.rst:78 +msgid "Updated Python version supported by virtualenv. (:pr:`538`)" +msgstr "" + +#: ../source/news.rst:79 +msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" +msgstr "" + +#: ../source/news.rst:82 +msgid "July 2018" +msgstr "" + +#: ../source/news.rst:84 +msgid "Improved binary extension docs. (:pr:`531`)" +msgstr "" + +#: ../source/news.rst:85 +msgid "Added scikit-build to key projects. (:pr:`530`)" +msgstr "" + +#: ../source/news.rst:88 +msgid "June 2018" +msgstr "" + +#: ../source/news.rst:90 +msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" +msgstr "" + +#: ../source/news.rst:91 +msgid "Updated Markdown descriptions explanation. (:pr:`522`)" +msgstr "" + +#: ../source/news.rst:94 +msgid "May 2018" +msgstr "" + +#: ../source/news.rst:96 +msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" +msgstr "" + +#: ../source/news.rst:97 +msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" +msgstr "" + +#: ../source/news.rst:98 +msgid "Simplified packaging tutorial. (:pr:`498`)" +msgstr "" + +#: ../source/news.rst:99 +msgid "Updated Windows users instructions for clarity. (:pr:`493`)" +msgstr "" + +#: ../source/news.rst:100 +msgid "Updated the license section description for completeness. (:pr:`492`)" +msgstr "" + +#: ../source/news.rst:101 +msgid "Added specification-style document to contributing section. (:pr:`489`)" +msgstr "" + +#: ../source/news.rst:102 +msgid "Added documentation types to contributing guide. (:pr:`485`)" +msgstr "" + +#: ../source/news.rst:105 +msgid "April 2018" +msgstr "" + +#: ../source/news.rst:107 +msgid "Added README guide. (:pr:`461`)" +msgstr "" + +#: ../source/news.rst:108 +msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" +msgstr "" + +#: ../source/news.rst:109 +msgid "Added instructions for Warehouse. (:pr:`471`)" +msgstr "" + +#: ../source/news.rst:110 +msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" +msgstr "" + +#: ../source/news.rst:111 +msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" +msgstr "" + +#: ../source/news.rst:112 +msgid "Added a guide for phasing out Python versions. (:pr:`459`)" +msgstr "" + +#: ../source/news.rst:113 +msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" +msgstr "" + +#: ../source/news.rst:116 +msgid "March 2018" +msgstr "" + +#: ../source/news.rst:118 +msgid "Updated \"installing scientific packages\". (:pr:`455`)" +msgstr "" + +#: ../source/news.rst:119 +msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" +msgstr "" + +#: ../source/news.rst:120 +msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" +msgstr "" + +#: ../source/news.rst:121 +msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" +msgstr "" + +#: ../source/news.rst:124 +msgid "February 2018" +msgstr "" + +#: ../source/news.rst:126 +msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" +msgstr "" + +#: ../source/news.rst:127 +msgid "Updated PyPI migration info. (:pr:`439`)" +msgstr "" + +#: ../source/news.rst:128 +msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" +msgstr "" + +#: ../source/news.rst:129 +msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" +msgstr "" + +#: ../source/news.rst:130 +msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" +msgstr "" + +#: ../source/news.rst:133 +msgid "January 2018" +msgstr "" + +#: ../source/news.rst:135 +msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" +msgstr "" + +#: ../source/news.rst:136 +msgid "Updated README.rst explanation. (:pr:`419`)" +msgstr "" + +#: ../source/news.rst:139 +msgid "December 2017" +msgstr "" + +#: ../source/news.rst:141 +msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" +msgstr "" + +#: ../source/news.rst:142 +msgid "Noted which fields can be used with environment markers. (:pr:`416`)" +msgstr "" + +#: ../source/news.rst:143 +msgid "Updated Requires-Python section. (:pr:`414`)" +msgstr "" + +#: ../source/news.rst:144 +msgid "Added news page. (:pr:`404`)" +msgstr "" + +#: ../source/news.rst:147 +msgid "November 2017" +msgstr "" + +#: ../source/news.rst:149 +msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" +msgstr "" + +#: ../source/news.rst:150 +msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" +msgstr "" + +#: ../source/news.rst:152 +msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:153 +msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" +msgstr "" + +#: ../source/news.rst:156 +msgid "October 2017" +msgstr "" + +#: ../source/news.rst:158 +msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:159 +msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" +msgstr "" + +#: ../source/news.rst:160 +msgid "Split the specifications page into multiple pages. (:pr:`386`)" +msgstr "" + +#: ../source/news.rst:163 +msgid "September 2017" +msgstr "" + +#: ../source/news.rst:165 +msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" +msgstr "" + +#: ../source/news.rst:167 +msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" +msgstr "" + +#: ../source/news.rst:170 +msgid "August 2017" +msgstr "" + +#: ../source/news.rst:172 +msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" +msgstr "" + +#: ../source/news.rst:173 +msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" +msgstr "" + +#: ../source/news.rst:174 +msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" +msgstr "" + +#: ../source/news.rst:177 +msgid "July 2017" +msgstr "" + +#: ../source/news.rst:179 +msgid "Added ``flit`` to the key projects list. (:pr:`358`)" +msgstr "" + +#: ../source/news.rst:180 +msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" +msgstr "" + +#: ../source/news.rst:181 +msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" +msgstr "" + +#: ../source/news.rst:182 +msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" +msgstr "" + +#: ../source/news.rst:183 +msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" +msgstr "" + +#: ../source/news.rst:186 +msgid "June 2017" +msgstr "" + +#: ../source/news.rst:188 +msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" +msgstr "" + +#: ../source/news.rst:189 +msgid "Added documentation for ``python_requires``. (:pr:`338`)" +msgstr "" + +#: ../source/news.rst:190 +msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" +msgstr "" + +#: ../source/news.rst:191 +msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" +msgstr "" + +#: ../source/news.rst:192 +msgid "Added a license section to the distributing guide. (:pr:`331`)" +msgstr "" + +#: ../source/news.rst:193 +msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" +msgstr "" + +#: ../source/news.rst:194 +msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" +msgstr "" + +#: ../source/news.rst:195 +msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" +msgstr "" + +#: ../source/news.rst:196 +msgid "Switched to the PyPA theme. (:pr:`305`)" +msgstr "" + +#: ../source/news.rst:197 +msgid "Re-organized the documentation into the new structure. (:pr:`318`)" +msgstr "" + +#: ../source/news.rst:200 +msgid "May 2017" +msgstr "" + +#: ../source/news.rst:202 +msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" +msgstr "" + +#: ../source/news.rst:203 +msgid "Added contributor and style guide. (:pr:`307`)" +msgstr "" + +#: ../source/news.rst:204 +msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" +msgstr "" + +#: ../source/news.rst:207 +msgid "April 2017" +msgstr "" + +#: ../source/news.rst:209 +msgid "Added travis configuration for testing pull requests. (:pr:`300`)" +msgstr "" + +#: ../source/news.rst:210 +msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" +msgstr "" + +#: ../source/news.rst:211 +msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" +msgstr "" + +#: ../source/news.rst:212 +msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" +msgstr "" + +#: ../source/news.rst:213 +msgid "Added a topic on namespace packages. (:pr:`290`)" +msgstr "" + +#: ../source/news.rst:214 +msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" +msgstr "" + +#: ../source/news.rst:215 +msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" +msgstr "" + +#: ../source/news.rst:216 +msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" +msgstr "" + +#: ../source/news.rst:217 +msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" +msgstr "" + +#: ../source/news.rst:219 +msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" +msgstr "" + +#: ../source/news.rst:223 +msgid "March 2017" +msgstr "" + +#: ../source/news.rst:225 +msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" +msgstr "" + +#: ../source/news.rst:228 +msgid "February 2017" +msgstr "" + +#: ../source/news.rst:230 +msgid "Added :pep:`518`. (:pr:`281`)" +msgstr "" + +#: ../source/overview.rst:3 +msgid "An Overview of Packaging for Python" +msgstr "" + +#: ../source/overview.rst:7 +msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." +msgstr "" + +#: ../source/overview.rst:12 +msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." +msgstr "" + +#: ../source/overview.rst:18 +msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." +msgstr "" + +#: ../source/overview.rst:26 +msgid "Thinking about deployment" +msgstr "" + +#: ../source/overview.rst:28 +msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" +msgstr "" + +#: ../source/overview.rst:32 +msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" +msgstr "" + +#: ../source/overview.rst:35 +msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" +msgstr "" + +#: ../source/overview.rst:37 +msgid "Is your software installed individually, or in large deployment batches?" +msgstr "" + +#: ../source/overview.rst:39 +msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." +msgstr "" + +#: ../source/overview.rst:46 +msgid "Packaging Python libraries and tools" +msgstr "" + +#: ../source/overview.rst:48 +msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/overview.rst:53 +msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." +msgstr "" + +#: ../source/overview.rst:59 +msgid "Python modules" +msgstr "" + +#: ../source/overview.rst:61 +msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." +msgstr "" + +#: ../source/overview.rst:66 +msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." +msgstr "" + +#: ../source/overview.rst:73 +msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." +msgstr "" + +#: ../source/overview.rst:78 +msgid "Python source distributions" +msgstr "" + +#: ../source/overview.rst:80 +msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." +msgstr "" + +#: ../source/overview.rst:84 +msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." +msgstr "" + +#: ../source/overview.rst:90 +msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." +msgstr "" + +#: ../source/overview.rst:95 +msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." +msgstr "" + +#: ../source/overview.rst:100 +msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." +msgstr "" + +#: ../source/overview.rst:107 +msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" +msgstr "" + +#: ../source/overview.rst:114 +msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." +msgstr "" + +#: ../source/overview.rst:119 +msgid "Python binary distributions" +msgstr "" + +#: ../source/overview.rst:121 +msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." +msgstr "" + +#: ../source/overview.rst:125 +msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." +msgstr "" + +#: ../source/overview.rst:132 +msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." +msgstr "" + +#: ../source/overview.rst:140 +msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." +msgstr "" + +#: ../source/overview.rst:148 +msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." +msgstr "" + +#: ../source/overview.rst:155 +msgid "Packaging Python applications" +msgstr "" + +#: ../source/overview.rst:157 +msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." +msgstr "" + +#: ../source/overview.rst:162 +msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." +msgstr "" + +#: ../source/overview.rst:166 +msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." +msgstr "" + +#: ../source/overview.rst:172 +msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." +msgstr "" + +#: ../source/overview.rst:176 +msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." +msgstr "" + +#: ../source/overview.rst:181 +msgid "Depending on a framework" +msgstr "" + +#: ../source/overview.rst:183 +msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." +msgstr "" + +#: ../source/overview.rst:189 +msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." +msgstr "" + +#: ../source/overview.rst:195 +msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." +msgstr "" + +#: ../source/overview.rst:199 +msgid "Service platforms" +msgstr "" + +#: ../source/overview.rst:201 +msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." +msgstr "" + +#: ../source/overview.rst:205 +msgid "`Heroku `_" +msgstr "" + +#: ../source/overview.rst:206 +msgid "`Google App Engine `_" +msgstr "" + +#: ../source/overview.rst:207 +msgid "`PythonAnywhere `_" +msgstr "" + +#: ../source/overview.rst:208 +msgid "`OpenShift `_" +msgstr "" + +#: ../source/overview.rst:209 +msgid "\"Serverless\" frameworks like `Zappa `_" +msgstr "" + +#: ../source/overview.rst:211 +msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." +msgstr "" + +#: ../source/overview.rst:216 +msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." +msgstr "" + +#: ../source/overview.rst:220 +msgid "Web browsers and mobile applications" +msgstr "" + +#: ../source/overview.rst:222 +msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." +msgstr "" + +#: ../source/overview.rst:227 +msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" +msgstr "" + +#: ../source/overview.rst:231 +msgid "`Kivy `_" +msgstr "" + +#: ../source/overview.rst:232 +msgid "`Beeware `_" +msgstr "" + +#: ../source/overview.rst:233 +msgid "`Brython `_" +msgstr "" + +#: ../source/overview.rst:234 +msgid "`Flexx `_" +msgstr "" + +#: ../source/overview.rst:236 +msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." +msgstr "" + +#: ../source/overview.rst:241 +msgid "Depending on a pre-installed Python" +msgstr "" + +#: ../source/overview.rst:243 +msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." +msgstr "" + +#: ../source/overview.rst:249 +msgid "Technologies which support this model:" +msgstr "" + +#: ../source/overview.rst:251 +msgid "`PEX `_ (Python EXecutable)" +msgstr "" + +#: ../source/overview.rst:252 +msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" +msgstr "" + +#: ../source/overview.rst:253 +msgid "`shiv `_ (requires Python 3)" +msgstr "" + +#: ../source/overview.rst:255 +msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." +msgstr "" + +#: ../source/overview.rst:260 +msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." +msgstr "" + +#: ../source/overview.rst:267 +msgid "Depending on a separate software distribution ecosystem" +msgstr "" + +#: ../source/overview.rst:269 +msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." +msgstr "" + +#: ../source/overview.rst:274 +msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." +msgstr "" + +#: ../source/overview.rst:284 +msgid "Instructions on building and publishing for the Anaconda ecosystem:" +msgstr "" + +#: ../source/overview.rst:286 +msgid "`Building libraries and applications with conda `_" +msgstr "" + +#: ../source/overview.rst:287 +msgid "`Transitioning a native Python package to Anaconda `_" +msgstr "" + +#: ../source/overview.rst:289 +msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" +msgstr "" + +#: ../source/overview.rst:293 +msgid "`Enthought Canopy `_" +msgstr "" + +#: ../source/overview.rst:294 +msgid "`ActiveState ActivePython `_" +msgstr "" + +#: ../source/overview.rst:295 +msgid "`WinPython `_" +msgstr "" + +#: ../source/overview.rst:300 +msgid "Bringing your own Python executable" +msgstr "" + +#: ../source/overview.rst:302 +msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." +msgstr "" + +#: ../source/overview.rst:306 +msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." +msgstr "" + +#: ../source/overview.rst:311 +msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." +msgstr "" + +#: ../source/overview.rst:315 +msgid "A selection of Python freezers:" +msgstr "" + +#: ../source/overview.rst:317 +msgid "`pyInstaller `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:318 +msgid "`cx_Freeze `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:319 +msgid "`constructor `_ - For command-line installers" +msgstr "" + +#: ../source/overview.rst:320 +msgid "`py2exe `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:321 +msgid "`py2app `_ - Mac only" +msgstr "" + +#: ../source/overview.rst:322 +msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" +msgstr "" + +#: ../source/overview.rst:323 +msgid "`osnap `_ - Windows and Mac" +msgstr "" + +#: ../source/overview.rst:324 +msgid "`pynsist `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:326 +msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." +msgstr "" + +#: ../source/overview.rst:332 +msgid "Bringing your own userspace" +msgstr "" + +#: ../source/overview.rst:334 +msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." +msgstr "" + +#: ../source/overview.rst:341 +msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." +msgstr "" + +#: ../source/overview.rst:344 +msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" +msgstr "" + +#: ../source/overview.rst:347 +msgid "`AppImage `_" +msgstr "" + +#: ../source/overview.rst:348 +msgid "`Docker `_" +msgstr "" + +#: ../source/overview.rst:349 +msgid "`Flatpak `_" +msgstr "" + +#: ../source/overview.rst:350 +msgid "`Snapcraft `_" +msgstr "" + +#: ../source/overview.rst:353 +msgid "Bringing your own kernel" +msgstr "" + +#: ../source/overview.rst:355 +msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." +msgstr "" + +#: ../source/overview.rst:360 +msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" +msgstr "" + +#: ../source/overview.rst:364 +msgid "`Vagrant `_" +msgstr "" + +#: ../source/overview.rst:365 +msgid "`VHD `_, `AMI `_, and `other formats `_" +msgstr "" + +#: ../source/overview.rst:366 +msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" +msgstr "" + +#: ../source/overview.rst:369 +msgid "Bringing your own hardware" +msgstr "" + +#: ../source/overview.rst:371 +msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." +msgstr "" + +#: ../source/overview.rst:375 +msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." +msgstr "" + +#: ../source/overview.rst:379 +msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." +msgstr "" + +#: ../source/overview.rst:389 +msgid "The simplified gamut of technologies used to package Python applications." +msgstr "" + +#: ../source/overview.rst:392 +msgid "What about..." +msgstr "" + +#: ../source/overview.rst:394 +msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." +msgstr "" + +#: ../source/overview.rst:398 +msgid "Operating system packages" +msgstr "" + +#: ../source/overview.rst:400 +msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." +msgstr "" + +#: ../source/overview.rst:411 +msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." +msgstr "" + +#: ../source/overview.rst:417 +msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." +msgstr "" + +#: ../source/overview.rst:427 +msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." +msgstr "" + +#: ../source/overview.rst:432 +msgid "Security" +msgstr "Безопасность" + +#: ../source/overview.rst:434 +msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." +msgstr "" + +#: ../source/overview.rst:437 +msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." +msgstr "" + +#: ../source/overview.rst:446 +msgid "Wrap up" +msgstr "" + +#: ../source/overview.rst:448 +msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:6 +msgid "Binary distribution format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:8 +msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:13 +msgid "Abstract" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:15 +msgid "This PEP describes a built-package format for Python called \"wheel\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:17 +msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:27 +msgid "PEP Acceptance" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:29 +msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:34 +msgid "Rationale" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:36 +msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:43 +msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:52 +msgid "Details" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:55 +msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:57 +msgid "Wheel installation notionally consists of two phases:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:59 +msgid "Unpack." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:61 +msgid "Parse ``distribution-1.0.dist-info/WHEEL``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:62 +msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:64 +msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:66 +msgid "Else unpack archive into platlib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:68 +msgid "Spread." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:70 +msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:72 +msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:78 +msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:80 +msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:82 +msgid "Remove empty ``distribution-1.0.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:83 +msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:87 +msgid "Recommended installer features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:97 +msgid "Rewrite ``#!python``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:90 +msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:96 +msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:102 +msgid "Generate script wrappers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:100 +msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:105 +msgid "Recommended archiver features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:112 +msgid "Place ``.dist-info`` at the end of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:108 +msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:115 +msgid "File Format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:118 +msgid "File name convention" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:120 +msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "distribution" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "Distribution name, e.g. 'django', 'pyramid'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "Distribution version, e.g. 1.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:135 +msgid "build tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:130 +msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "language implementation and version tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "E.g. 'py27', 'py2', 'py3'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "abi tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "E.g. 'cp33m', 'abi3', 'none'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "platform tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "E.g. 'linux_x86_64', 'any'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:146 +msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:151 +msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:156 +msgid "Escaping and Unicode" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:158 +msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:161 +msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:164 +msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:166 +msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:169 +msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:172 +msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:176 +msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:182 +msgid "File contents" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:184 +msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:188 +msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:191 +msgid "``{distribution}-{version}.dist-info/`` contains metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:192 +msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:196 +msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:200 +msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:202 +msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:212 +msgid "``Wheel-Version`` is the version number of the Wheel specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:213 +msgid "``Generator`` is the name and optionally the version of the software that produced the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:215 +msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:218 +msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:220 +msgid "``Build`` is the build number and is omitted if there is no build number." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:221 +msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:224 +msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:226 +msgid "Wheel does not contain setup.py or setup.cfg." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:228 +msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:235 +#: ../source/specifications/recording-installed-packages.rst:35 +msgid "The .dist-info directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:237 +msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:239 +msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:241 +msgid "WHEEL is the wheel metadata specific to a build of the package." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:242 +msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:248 +msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:249 +msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:251 +msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:254 +msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:261 +msgid "The .data directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:263 +msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:271 +msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:277 +msgid "Signed wheel files" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:279 +msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:290 +msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:295 +msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:302 +msgid "(The hash value is the same format used in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:304 +msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:307 +msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:312 +msgid "See" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:314 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:315 +msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:316 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:317 +msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:321 +msgid "Comparison to .egg" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:323 +msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:328 +msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:331 +msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:337 +msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:341 +msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:344 +msgid "Wheel is a reference to the other Python." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:348 +msgid "FAQ" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:352 +msgid "Wheel defines a .data directory. Should I put all my data there?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:354 +msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:363 +msgid "Why does wheel include attached signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:365 +msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:373 +msgid "Why does wheel allow JWS signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:375 +msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:381 +msgid "Why does wheel also allow S/MIME signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:383 +msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:386 +msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:391 +msgid "What's the deal with \"purelib\" vs. \"platlib\"?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:393 +msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:398 +msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:403 +msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:409 +msgid "Is it possible to import Python code directly from a wheel file?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:411 +msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:417 +msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:426 +msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:443 +msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:450 +msgid "Changes" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:452 +msgid "Since :pep:`427`, this specification has changed as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:454 +msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:461 +msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:466 +msgid "Appendix" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:468 +msgid "Example urlsafe-base64-nopad implementation::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:482 +msgid "Copyright" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:484 +msgid "This document has been placed into the public domain." +msgstr "" + +#: ../source/specifications/core-metadata.rst:5 +msgid "Core metadata specifications" +msgstr "" + +#: ../source/specifications/core-metadata.rst:7 +msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:10 +msgid "``Metadata-Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:11 +msgid "``Name``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:12 +msgid "``Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:14 +msgid "All the other fields are optional." +msgstr "" + +#: ../source/specifications/core-metadata.rst:16 +msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." +msgstr "" + +#: ../source/specifications/core-metadata.rst:25 +msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:30 +msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." +msgstr "" + +#: ../source/specifications/core-metadata.rst:41 +msgid "Metadata-Version" +msgstr "" + +#: ../source/specifications/core-metadata.rst:45 +msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." +msgstr "" + +#: ../source/specifications/core-metadata.rst:48 +msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:54 +msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." +msgstr "" + +#: ../source/specifications/core-metadata.rst:58 +#: ../source/specifications/core-metadata.rst:80 +#: ../source/specifications/core-metadata.rst:95 +#: ../source/specifications/core-metadata.rst:155 +#: ../source/specifications/core-metadata.rst:170 +#: ../source/specifications/core-metadata.rst:208 +#: ../source/specifications/core-metadata.rst:283 +#: ../source/specifications/core-metadata.rst:287 +#: ../source/specifications/core-metadata.rst:291 +#: ../source/specifications/core-metadata.rst:295 +#: ../source/specifications/core-metadata.rst:327 +#: ../source/specifications/core-metadata.rst:347 +#: ../source/specifications/core-metadata.rst:373 +#: ../source/specifications/core-metadata.rst:391 +#: ../source/specifications/core-metadata.rst:416 +#: ../source/specifications/core-metadata.rst:438 +#: ../source/specifications/core-metadata.rst:600 +#: ../source/specifications/core-metadata.rst:620 +#: ../source/specifications/core-metadata.rst:630 +msgid "Example::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:66 +msgid "Name" +msgstr "Имя" + +#: ../source/specifications/core-metadata.rst:69 +msgid "Added additional restrictions on format from :pep:`508`" +msgstr "" + +#: ../source/specifications/core-metadata.rst:72 +msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:88 +msgid "Version" +msgstr "Версия" + +#: ../source/specifications/core-metadata.rst:92 +msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:101 +msgid "Dynamic (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:105 +msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." +msgstr "" + +#: ../source/specifications/core-metadata.rst:108 +msgid "When found in the metadata of a source distribution, the following rules apply:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:111 +msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." +msgstr "" + +#: ../source/specifications/core-metadata.rst:115 +msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:118 +msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:122 +msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." +msgstr "" + +#: ../source/specifications/core-metadata.rst:127 +msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:131 +msgid "Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:135 +msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." +msgstr "" + +#: ../source/specifications/core-metadata.rst:146 +msgid "Supported-Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:150 +msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." +msgstr "" + +#: ../source/specifications/core-metadata.rst:164 +msgid "Summary" +msgstr "" + +#: ../source/specifications/core-metadata.rst:168 +msgid "A one-line summary of what the distribution does." +msgstr "" + +#: ../source/specifications/core-metadata.rst:188 +msgid "This field may be specified in the message body instead." +msgstr "" + +#: ../source/specifications/core-metadata.rst:191 +msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:196 +msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." +msgstr "" + +#: ../source/specifications/core-metadata.rst:202 +msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:219 +msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." +msgstr "" + +#: ../source/specifications/core-metadata.rst:223 +msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:232 +msgid "Description-Content-Type" +msgstr "" + +#: ../source/specifications/core-metadata.rst:236 +msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:239 +msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." +msgstr "" + +#: ../source/specifications/core-metadata.rst:253 +msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:259 +msgid "Format::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:263 +msgid "The ``type/subtype`` part has only a few legal values:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:265 +msgid "``text/plain``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:266 +msgid "``text/x-rst``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:267 +msgid "``text/markdown``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:269 +msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:273 +msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:278 +msgid "``GFM`` for `Github-flavored Markdown `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:280 +msgid "``CommonMark`` for `CommonMark `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:299 +msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." +msgstr "" + +#: ../source/specifications/core-metadata.rst:303 +msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:307 +msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:311 +msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." +msgstr "" + +#: ../source/specifications/core-metadata.rst:320 +msgid "Keywords" +msgstr "" + +#: ../source/specifications/core-metadata.rst:324 +msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." +msgstr "" + +#: ../source/specifications/core-metadata.rst:333 +msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." +msgstr "" + +#: ../source/specifications/core-metadata.rst:341 +msgid "Home-page" +msgstr "" + +#: ../source/specifications/core-metadata.rst:345 +msgid "A string containing the URL for the distribution's home page." +msgstr "" + +#: ../source/specifications/core-metadata.rst:353 +msgid "Download-URL" +msgstr "" + +#: ../source/specifications/core-metadata.rst:357 +msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:366 +msgid "Author" +msgstr "" + +#: ../source/specifications/core-metadata.rst:370 +msgid "A string containing the author's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:383 +msgid "Author-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:387 +msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:395 +#: ../source/specifications/core-metadata.rst:442 +msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:405 +msgid "Maintainer" +msgstr "Сопровождающий" + +#: ../source/specifications/core-metadata.rst:409 +msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:412 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:426 +msgid "Maintainer-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:430 +msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:434 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:452 +msgid "License" +msgstr "" + +#: ../source/specifications/core-metadata.rst:456 +msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." +msgstr "" + +#: ../source/specifications/core-metadata.rst:476 +msgid "Classifier (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:480 +msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:485 +#: ../source/specifications/core-metadata.rst:574 +#: ../source/specifications/core-metadata.rst:691 +#: ../source/specifications/core-metadata.rst:715 +msgid "This field may be followed by an environment marker after a semicolon." +msgstr "" + +#: ../source/specifications/core-metadata.rst:496 +msgid "Requires-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:499 +#: ../source/specifications/core-metadata.rst:561 +#: ../source/specifications/core-metadata.rst:663 +#: ../source/specifications/core-metadata.rst:704 +msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." +msgstr "" + +#: ../source/specifications/core-metadata.rst:503 +msgid "Each entry contains a string naming some other distutils project required by this distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:506 +msgid "The format of a requirement string contains from one to four parts:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:508 +msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." +msgstr "" + +#: ../source/specifications/core-metadata.rst:510 +msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." +msgstr "" + +#: ../source/specifications/core-metadata.rst:513 +msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:516 +msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." +msgstr "" + +#: ../source/specifications/core-metadata.rst:519 +msgid "See :pep:`508` for full details of the allowed format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:521 +msgid "The project names should correspond to names as found on the `Python Package Index`_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:524 +msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:538 +msgid "Requires-Python" +msgstr "" + +#: ../source/specifications/core-metadata.rst:542 +msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." +msgstr "" + +#: ../source/specifications/core-metadata.rst:546 +msgid "The value must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:548 +msgid "This field cannot be followed by an environment marker." +msgstr "" + +#: ../source/specifications/core-metadata.rst:558 +msgid "Requires-External (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:565 +msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:570 +msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:576 +msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." +msgstr "" + +#: ../source/specifications/core-metadata.rst:581 +msgid "Notice that there is no particular rule on the strings to be used." +msgstr "" + +#: ../source/specifications/core-metadata.rst:593 +msgid "Project-URL (multiple-use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:597 +msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." +msgstr "" + +#: ../source/specifications/core-metadata.rst:604 +msgid "The label is free text limited to 32 characters." +msgstr "" + +#: ../source/specifications/core-metadata.rst:612 +msgid "Provides-Extra (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:616 +msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." +msgstr "" + +#: ../source/specifications/core-metadata.rst:625 +msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:635 +msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." +msgstr "" + +#: ../source/specifications/core-metadata.rst:639 +msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:644 +msgid "Rarely Used Fields" +msgstr "" + +#: ../source/specifications/core-metadata.rst:646 +msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:651 +msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." +msgstr "" + +#: ../source/specifications/core-metadata.rst:660 +msgid "Provides-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:667 +msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:672 +msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:679 +msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:687 +msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." +msgstr "" + +#: ../source/specifications/core-metadata.rst:701 +msgid "Obsoletes-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:708 +msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." +msgstr "" + +#: ../source/specifications/core-metadata.rst:712 +msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:717 +msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:730 +msgid "reStructuredText markup: http://docutils.sourceforge.net/" +msgstr "" + +#: ../source/specifications/core-metadata.rst:735 +msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:6 +msgid "Declaring build system dependencies" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:8 +msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:5 +msgid "Declaring project metadata" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:7 +msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:12 +msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:18 +msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:27 +msgid "The only fields required to be statically defined are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:29 +#: ../source/specifications/declaring-project-metadata.rst:41 +msgid "``name``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:31 +msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:34 +#: ../source/specifications/declaring-project-metadata.rst:54 +msgid "``version``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:36 +msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:43 +#: ../source/specifications/declaring-project-metadata.rst:56 +#: ../source/specifications/declaring-project-metadata.rst:68 +#: ../source/specifications/declaring-project-metadata.rst:117 +msgid "TOML_ type: string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:44 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:47 +msgid "The name of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:49 +msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:57 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:60 +msgid "The version of the project as supported by :pep:`440`." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:62 +msgid "Users SHOULD prefer to specify already-normalized versions." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:66 +msgid "``description``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:69 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:72 +msgid "The summary description of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:76 +msgid "``readme``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:78 +msgid "TOML_ type: string or table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:79 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:83 +msgid "The full description of the project (i.e. the README)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:85 +msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:96 +msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:103 +msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:115 +msgid "``requires-python``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:118 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:121 +msgid "The Python version requirements of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:125 +msgid "``license``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:127 +msgid "TOML_ type: table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:128 +msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:131 +msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:140 +msgid "``authors``/``maintainers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:142 +msgid "TOML_ type: Array of inline tables with string keys and values" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:143 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:149 +msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:154 +msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:157 +msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:163 +msgid "Using the data to fill in :ref:`core metadata ` is as follows:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:166 +msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:169 +msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:173 +msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:177 +msgid "Multiple values should be separated by commas." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:181 +msgid "``keywords``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:183 +#: ../source/specifications/declaring-project-metadata.rst:193 +msgid "TOML_ type: array of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:184 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:187 +msgid "The keywords for the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:191 +msgid "``classifiers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:194 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:197 +msgid "Trove classifiers which apply to the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:201 +msgid "``urls``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:203 +msgid "TOML_ type: table with keys and values of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:204 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:207 +msgid "A table of URLs where the key is the URL label and the value is the URL itself." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:212 +msgid "Entry points" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:214 +msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:216 +msgid ":ref:`Entry points specification `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:218 +msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:224 +msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:228 +msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:234 +msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:242 +msgid "``dependencies``/``optional-dependencies``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:244 +msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:247 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:251 +msgid "The (optional) dependencies of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:253 +msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:258 +msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:269 +msgid "``dynamic``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:271 +msgid "TOML_ type: array of string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:272 +msgid "A corresponding :ref:`core metadata ` field does not exist" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:275 +msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:281 +msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:283 +msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:285 +msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:290 +msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:294 +msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:296 +msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:300 +msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:6 +msgid "Dependency specifiers" +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:8 +msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:11 +msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." +msgstr "" + +#: ../source/specifications/direct-url.rst:6 +msgid "Recording the Direct URL Origin of installed distributions" +msgstr "" + +#: ../source/specifications/direct-url.rst:8 +msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." +msgstr "" + +#: ../source/specifications/direct-url.rst:17 +msgid "Specification" +msgstr "" + +#: ../source/specifications/direct-url.rst:19 +msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/direct-url.rst:23 +#: ../source/specifications/recording-installed-packages.rst:206 +msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." +msgstr "" + +#: ../source/specifications/direct-url.rst:26 +msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." +msgstr "" + +#: ../source/specifications/direct-url.rst:29 +msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." +msgstr "" + +#: ../source/specifications/direct-url.rst:36 +msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." +msgstr "" + +#: ../source/specifications/direct-url.rst:39 +msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" +msgstr "" + +#: ../source/specifications/direct-url.rst:45 +msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." +msgstr "" + +#: ../source/specifications/direct-url.rst:49 +msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" +msgstr "" + +#: ../source/specifications/direct-url.rst:52 +msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." +msgstr "" + +#: ../source/specifications/direct-url.rst:58 +msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." +msgstr "" + +#: ../source/specifications/direct-url.rst:61 +msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." +msgstr "" + +#: ../source/specifications/direct-url.rst:68 +msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:71 +msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." +msgstr "" + +#: ../source/specifications/direct-url.rst:78 +msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:81 +msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." +msgstr "" + +#: ../source/specifications/direct-url.rst:84 +msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." +msgstr "" + +#: ../source/specifications/direct-url.rst:91 +msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." +msgstr "" + +#: ../source/specifications/direct-url.rst:96 +msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." +msgstr "" + +#: ../source/specifications/direct-url.rst:102 +msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." +msgstr "" + +#: ../source/specifications/direct-url.rst:110 +msgid "Registered VCS" +msgstr "" + +#: ../source/specifications/direct-url.rst:112 +msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." +msgstr "" + +#: ../source/specifications/direct-url.rst:122 +msgid "Git" +msgstr "" + +#: ../source/specifications/direct-url.rst:124 +#: ../source/specifications/direct-url.rst:156 +#: ../source/specifications/direct-url.rst:179 +#: ../source/specifications/direct-url.rst:202 +msgid "Home page" +msgstr "" + +#: ../source/specifications/direct-url.rst:126 +msgid "https://git-scm.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:128 +#: ../source/specifications/direct-url.rst:160 +#: ../source/specifications/direct-url.rst:183 +#: ../source/specifications/direct-url.rst:206 +msgid "vcs command" +msgstr "" + +#: ../source/specifications/direct-url.rst:130 +#: ../source/specifications/direct-url.rst:134 +msgid "git" +msgstr "" + +#: ../source/specifications/direct-url.rst:132 +#: ../source/specifications/direct-url.rst:164 +#: ../source/specifications/direct-url.rst:187 +#: ../source/specifications/direct-url.rst:210 +msgid "``vcs`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:136 +#: ../source/specifications/direct-url.rst:168 +#: ../source/specifications/direct-url.rst:191 +#: ../source/specifications/direct-url.rst:214 +msgid "``requested_revision`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:138 +msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." +msgstr "" + +#: ../source/specifications/direct-url.rst:141 +#: ../source/specifications/direct-url.rst:172 +#: ../source/specifications/direct-url.rst:195 +#: ../source/specifications/direct-url.rst:219 +msgid "``commit_id`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:143 +msgid "A commit hash (40 hexadecimal characters sha1)." +msgstr "" + +#: ../source/specifications/direct-url.rst:147 +msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." +msgstr "" + +#: ../source/specifications/direct-url.rst:154 +msgid "Mercurial" +msgstr "" + +#: ../source/specifications/direct-url.rst:158 +msgid "https://www.mercurial-scm.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:162 +#: ../source/specifications/direct-url.rst:166 +msgid "hg" +msgstr "" + +#: ../source/specifications/direct-url.rst:170 +msgid "A tag name, branch name, changeset ID, shortened changeset ID." +msgstr "" + +#: ../source/specifications/direct-url.rst:174 +msgid "A changeset ID (40 hexadecimal characters)." +msgstr "" + +#: ../source/specifications/direct-url.rst:177 +msgid "Bazaar" +msgstr "" + +#: ../source/specifications/direct-url.rst:181 +msgid "https://bazaar.canonical.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:185 +#: ../source/specifications/direct-url.rst:189 +msgid "bzr" +msgstr "" + +#: ../source/specifications/direct-url.rst:193 +msgid "A tag name, branch name, revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:197 +msgid "A revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:200 +msgid "Subversion" +msgstr "" + +#: ../source/specifications/direct-url.rst:204 +msgid "https://subversion.apache.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:208 +#: ../source/specifications/direct-url.rst:212 +msgid "svn" +msgstr "" + +#: ../source/specifications/direct-url.rst:216 +msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." +msgstr "" + +#: ../source/specifications/direct-url.rst:221 +msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." +msgstr "" + +#: ../source/specifications/direct-url.rst:229 +msgid "Example direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:231 +msgid "Source archive:" +msgstr "" + +#: ../source/specifications/direct-url.rst:242 +msgid "Git URL with tag and commit-hash:" +msgstr "" + +#: ../source/specifications/direct-url.rst:255 +msgid "Local directory:" +msgstr "" + +#: ../source/specifications/direct-url.rst:264 +msgid "Local directory installed in editable mode:" +msgstr "" + +#: ../source/specifications/direct-url.rst:277 +msgid "Example pip commands and their effect on direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:279 +msgid "Commands that generate a ``direct_url.json``:" +msgstr "" + +#: ../source/specifications/direct-url.rst:281 +msgid "pip install https://example.com/app-1.0.tgz" +msgstr "" + +#: ../source/specifications/direct-url.rst:282 +msgid "pip install https://example.com/app-1.0.whl" +msgstr "" + +#: ../source/specifications/direct-url.rst:283 +msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" +msgstr "" + +#: ../source/specifications/direct-url.rst:284 +msgid "pip install ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:285 +msgid "pip install file:///home/user/app" +msgstr "" + +#: ../source/specifications/direct-url.rst:286 +msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" +msgstr "" + +#: ../source/specifications/direct-url.rst:290 +msgid "pip install -e ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:292 +msgid "Commands that *do not* generate a ``direct_url.json``" +msgstr "" + +#: ../source/specifications/direct-url.rst:294 +msgid "pip install app" +msgstr "" + +#: ../source/specifications/direct-url.rst:295 +msgid "pip install app --no-index --find-links https://example.com/" +msgstr "" + +#: ../source/specifications/entry-points.rst:5 +msgid "Entry points specification" +msgstr "" + +#: ../source/specifications/entry-points.rst:7 +msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" +msgstr "" + +#: ../source/specifications/entry-points.rst:11 +msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." +msgstr "" + +#: ../source/specifications/entry-points.rst:14 +msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." +msgstr "" + +#: ../source/specifications/entry-points.rst:19 +msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." +msgstr "" + +#: ../source/specifications/entry-points.rst:28 +msgid "Data model" +msgstr "" + +#: ../source/specifications/entry-points.rst:30 +msgid "Conceptually, an entry point is defined by three required properties:" +msgstr "" + +#: ../source/specifications/entry-points.rst:32 +msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:42 +msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:51 +msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:64 +msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." +msgstr "" + +#: ../source/specifications/entry-points.rst:68 +msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." +msgstr "" + +#: ../source/specifications/entry-points.rst:73 +msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." +msgstr "" + +#: ../source/specifications/entry-points.rst:80 +msgid "File format" +msgstr "" + +#: ../source/specifications/entry-points.rst:82 +msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." +msgstr "" + +#: ../source/specifications/entry-points.rst:87 +msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:97 +msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:100 +msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." +msgstr "" + +#: ../source/specifications/entry-points.rst:104 +msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." +msgstr "" + +#: ../source/specifications/entry-points.rst:112 +msgid "For example::" +msgstr "" + +#: ../source/specifications/entry-points.rst:124 +msgid "Use for scripts" +msgstr "" + +#: ../source/specifications/entry-points.rst:126 +msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." +msgstr "" + +#: ../source/specifications/entry-points.rst:134 +msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:141 +msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." +msgstr "" + +#: ../source/specifications/entry-points.rst:149 +msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." +msgstr "" + +#: ../source/specifications/entry-points.rst:154 +msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." +msgstr "" + +#: ../source/specifications/index.rst:4 +msgid "PyPA specifications" +msgstr "" + +#: ../source/specifications/index.rst:6 +msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." +msgstr "" + +#: ../source/specifications/index.rst:13 +msgid "Package Distribution Metadata" +msgstr "" + +#: ../source/specifications/index.rst:30 +msgid "Package Distribution File Formats" +msgstr "" + +#: ../source/specifications/index.rst:40 +msgid "Package Index Interfaces" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:6 +msgid "Platform compatibility tags" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:8 +msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:12 +msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:16 +msgid "Platform tags for Windows" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:18 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:22 +msgid "Platform tags for macOS (Mac OS X)" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:24 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:28 +msgid "Platform tags for common Linux distributions" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:32 +msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:36 +msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:41 +msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:44 +msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:46 +msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:49 +msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:54 +msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:59 +msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:65 +msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:71 +msgid "Manylinux compatibility support" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:74 +msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:76 +msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:79 +msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "Tool" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux1``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2010``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2014``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux_x_y``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=8.1.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=20.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "auditwheel" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=1.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=2.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.3.0`` [#]_" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:90 +msgid "Platform tags for other \\*nix platforms" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:92 +msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:98 +msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" +msgstr "" + +#: ../source/specifications/pypirc.rst:6 +msgid "The :file:`.pypirc` file" +msgstr "" + +#: ../source/specifications/pypirc.rst:8 +msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." +msgstr "" + +#: ../source/specifications/pypirc.rst:13 +msgid "The format (originally defined by the :ref:`distutils` package) is:" +msgstr "" + +#: ../source/specifications/pypirc.rst:32 +msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:35 +msgid "Each section describing a repository defines three fields:" +msgstr "" + +#: ../source/specifications/pypirc.rst:37 +msgid "``repository``: The URL of the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:38 +msgid "``username``: The registered username on the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:39 +msgid "``password``: The password that will used to authenticate the username." +msgstr "" + +#: ../source/specifications/pypirc.rst:43 +msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." +msgstr "" + +#: ../source/specifications/pypirc.rst:47 +msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" +msgstr "" + +#: ../source/specifications/pypirc.rst:57 +msgid "Common configurations" +msgstr "" + +#: ../source/specifications/pypirc.rst:61 +msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." +msgstr "" + +#: ../source/specifications/pypirc.rst:66 +msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" +msgstr "" + +#: ../source/specifications/pypirc.rst:82 +msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." +msgstr "" + +#: ../source/specifications/pypirc.rst:86 +msgid "Using a PyPI token" +msgstr "" + +#: ../source/specifications/pypirc.rst:88 +msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" +msgstr "" + +#: ../source/specifications/pypirc.rst:97 +msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." +msgstr "" + +#: ../source/specifications/pypirc.rst:103 +msgid "Using another package index" +msgstr "" + +#: ../source/specifications/pypirc.rst:105 +msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" +msgstr "" + +#: ../source/specifications/pypirc.rst:132 +msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:5 +msgid "Recording installed projects" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:7 +msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:12 +msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:21 +msgid "History and change workflow" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:23 +msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:29 +msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:37 +msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:41 +msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:50 +msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:60 +msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:69 +msgid "This ``.dist-info`` directory can contain these files, described in detail below:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:72 +msgid "``METADATA``: contains project metadata" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:73 +msgid "``RECORD``: records the list of installed files." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:74 +msgid "``INSTALLER``: records the name of the tool used to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:76 +msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:82 +msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:87 +msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:94 +msgid "The METADATA file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:96 +msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:99 +msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:105 +msgid "The RECORD file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:107 +msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:110 +msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:113 +msgid "field delimiter: ``,`` (comma)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:114 +msgid "quoting char: ``\"`` (straight double quote)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:115 +msgid "line terminator: either ``\\r\\n`` or ``\\n``." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:117 +msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:120 +msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:125 +msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:130 +msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:133 +msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:139 +msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:146 +msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:151 +msgid "Here is an example snippet of a possible ``RECORD`` file::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:170 +msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:177 +msgid "The INSTALLER file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:179 +msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:185 +msgid "The file can be terminated by zero or more ASCII whitespace characters." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:187 +msgid "Here are examples of two possible ``INSTALLER`` files::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:195 +msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:201 +msgid "The direct_url.json file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:203 +msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:209 +msgid "Its detailed specification is at :ref:`direct-url`." +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:6 +msgid "Simple repository API" +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:8 +msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:6 +msgid "Source distribution format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:8 +msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:13 +msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:21 +msgid "Source distributions are also known as *sdists* for short." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:24 +msgid "Source distribution file name" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:26 +msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:31 +msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:35 +msgid "Source distribution file format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:37 +msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:45 +msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:48 +msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:6 +msgid "Version specifiers" +msgstr "" + +#: ../source/specifications/version-specifiers.rst:8 +msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:11 +msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." +msgstr "" + +#: ../source/support.rst:3 +msgid "How to Get Support" +msgstr "" + +#: ../source/support.rst:5 +msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." +msgstr "" + +#: ../source/support.rst:8 +msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:5 +msgid "Creating Documentation" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:7 +msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:13 +msgid "Installing Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:14 +msgid "Use ``pip`` to install Sphinx:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:28 +msgid "For other installation methods, see this `installation guide`_ by Sphinx." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:33 +msgid "Getting Started With Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:35 +msgid "Create a ``docs`` directory inside your project to hold your documentation:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:42 +msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:49 +msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:51 +msgid "You can add some information about your project in ``index.rst``, then build them:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:57 +msgid "For more details on the build process, see this `guide`_ by Read The Docs." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:62 +msgid "Other Sources" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:64 +msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/index.rst:4 +msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:5 +msgid "Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:7 +msgid "This section covers the basics of how to install Python :term:`packages `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:10 +msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:28 +msgid "Requirements for Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:30 +msgid "This section describes the steps to follow before installing other Python packages." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:35 +msgid "Ensure you can run Python from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:37 +msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:53 +msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:57 +msgid "If you're a newcomer and you get an error like this:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:66 +msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:72 +msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:82 +msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:87 +msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:99 +msgid "Ensure you can run pip from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:101 +msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:116 +msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:124 +msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:139 +msgid "If that still doesn't allow you to run ``python -m pip``:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:141 +msgid "Securely Download `get-pip.py `_ [1]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:144 +msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:150 +msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:159 +msgid "Ensure pip, setuptools, and wheel are up to date" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:161 +msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:169 +msgid "Optionally, create a virtual environment" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:171 +msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:188 +msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:195 +msgid "Creating Virtual Environments" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:197 +msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:203 +msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:209 +msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:213 +msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:216 +msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:220 +msgid "Currently, there are two common tools for creating Python virtual environments:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:222 +msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:225 +msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:230 +msgid "The basic usage is like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:232 +msgid "Using `venv`_:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:248 +msgid "Using :ref:`virtualenv`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:264 +msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:266 +msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:271 +msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:281 +msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:288 +msgid "Use pip for Installing" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:290 +msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:297 +msgid "Installing from PyPI" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:299 +msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:307 +msgid "To install the latest version of \"SomeProject\":" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:321 +msgid "To install a specific version:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:335 +msgid "To install greater than or equal to one version and less than another:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:350 +msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:365 +msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:370 +msgid "Source Distributions vs Wheels" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:372 +msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:378 +msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:383 +msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:391 +msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:408 +msgid "Installing to the User Site" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:410 +msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:425 +msgid "For more information see the `User Installs `_ section from the pip docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:429 +msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:432 +msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:440 +msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:446 +msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:462 +msgid "Install a list of requirements specified in a :ref:`Requirements File `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:478 +msgid "Installing from VCS" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:480 +msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:502 +msgid "Installing from other Indexes" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:504 +msgid "Install from an alternate index" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:518 +msgid "Search an additional index during install, in addition to :term:`PyPI `" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:534 +msgid "Installing from a local src tree" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:537 +msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:554 +msgid "You can also install normally from src" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:571 +msgid "Install a particular source archive file." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:585 +msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:605 +msgid "Installing from other sources" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:607 +msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:619 +msgid "Installing Prereleases" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:621 +msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:637 +msgid "Installing Setuptools \"Extras\"" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:639 +msgid "Install `setuptools extras`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:659 +msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:668 +msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:673 +msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:4 +msgid "Managing Application Dependencies" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:6 +msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:9 +msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:13 +msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:17 +msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:24 +msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:30 +msgid "Installing Pipenv" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:32 +msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:38 +msgid "Use ``pip`` to install Pipenv:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:54 +msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:65 +msgid "Installing packages for your project" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:67 +msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:76 +msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:112 +msgid "Using installed packages" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:114 +msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:125 +msgid "Then you can run this script using ``pipenv run``:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:131 +msgid "You should get output similar to this:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:137 +msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:143 +#: ../source/tutorials/packaging-projects.rst:594 +msgid "Next steps" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:145 +msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:148 +msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:151 +msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:160 +msgid "Other Tools for Application Dependency Management" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:162 +msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:166 +msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:172 +msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:175 +msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:177 +msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:2 +msgid "Packaging Python Projects" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:4 +msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:10 +msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:18 +msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:35 +msgid "A simple project" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:37 +msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:41 +msgid "Create the following file structure locally:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:51 +msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:54 +msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:63 +msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:67 +msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:75 +msgid "Creating the package files" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:77 +msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:95 +msgid "Creating a test directory" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:97 +msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:101 +msgid "Creating pyproject.toml" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:103 +msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:117 +msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:121 +msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:127 +msgid "See :pep:`517` and :pep:`518` for background and details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:131 +msgid "Configuring metadata" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:133 +msgid "There are two types of metadata: static and dynamic." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:135 +msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:137 +msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:141 +msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:148 +msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:153 +msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:185 +msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:191 +#: ../source/tutorials/packaging-projects.rst:286 +msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:196 +msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:199 +#: ../source/tutorials/packaging-projects.rst:293 +msgid "``author`` and ``author_email`` are used to identify the author of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:201 +#: ../source/tutorials/packaging-projects.rst:295 +msgid "``description`` is a short, one-sentence summary of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:202 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:206 +#: ../source/tutorials/packaging-projects.rst:300 +msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:208 +#: ../source/tutorials/packaging-projects.rst:302 +msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:211 +#: ../source/tutorials/packaging-projects.rst:305 +msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:213 +#: ../source/tutorials/packaging-projects.rst:307 +msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:221 +msgid "In the ``options`` category, we have controls for setuptools itself:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:223 +msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:227 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:234 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:238 +#: ../source/tutorials/packaging-projects.rst:329 +msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:244 +msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:248 +msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:283 +msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:291 +msgid "``version`` is the package version. See :pep:`440` for more details on versions." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:296 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:314 +msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:319 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:325 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:333 +msgid "Creating README.md" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:335 +msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:347 +msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:354 +msgid "Creating a LICENSE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:356 +msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:387 +msgid "Including other files" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:389 +msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:393 +msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:402 +msgid "Generating distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:404 +msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:408 +msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:422 +msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:425 +msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:439 +msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:449 +msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:458 +msgid "Uploading the distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:460 +msgid "Finally, it's time to upload your package to the Python Package Index!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:462 +msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:470 +msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:477 +msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:492 +msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:506 +msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:510 +msgid "After the command completes, you should see output similar to this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:523 +msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:528 +msgid "Installing your newly uploaded package" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:530 +msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:546 +msgid "Make sure to specify your username in the package name!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:548 +msgid "pip should install the package from TestPyPI and the output should look something like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:558 +msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:565 +msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:580 +msgid "and import the package:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:588 +msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:596 +msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:599 +msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:604 +msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:608 +msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:610 +msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:613 +msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:617 +msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:619 +msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:622 +msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:624 +msgid "Read about :doc:`/guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:625 +msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." +msgstr "" From 1eb79aab473046cdbbb1a713b53b6451c8d8b77e Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Tue, 31 Aug 2021 18:43:26 +0800 Subject: [PATCH 0106/1072] Integrate sphinx's linkcheck (#968) Co-authored-by: Sviatoslav Sydorenko Co-authored-by: Sviatoslav Sydorenko --- .github/workflows/test.yml | 10 ++++++++-- noxfile.py | 13 +++++++++++++ source/conf.py | 4 ++++ 3 files changed, 25 insertions(+), 2 deletions(-) diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index bab4c032d..8c7151432 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -4,7 +4,13 @@ on: [push, pull_request] jobs: build: + name: ${{ matrix.noxenv }} runs-on: ubuntu-latest + strategy: + matrix: + noxenv: + - build + - linkcheck steps: - uses: actions/checkout@v2 @@ -27,6 +33,6 @@ jobs: run: | python -m pip install --upgrade nox virtualenv - - name: Nox build + - name: Nox ${{ matrix.noxenv }} run: | - python -m nox -s build + python -m nox -s ${{ matrix.noxenv }} diff --git a/noxfile.py b/noxfile.py index c8d7b6e0f..0a47e123e 100644 --- a/noxfile.py +++ b/noxfile.py @@ -52,3 +52,16 @@ def build(session, autobuild=False): def preview(session): session.install("sphinx-autobuild") build(session, autobuild=True) + + +@nox.session(py="3") +def linkcheck(session): + session.install("-r", "requirements.txt") + session.run( + "sphinx-build", + "-b", "linkcheck", # use linkcheck builder + "--color", + "-n", "-W", "--keep-going", # be strict + "source", # where the rst files are located + "build", # where to put the check output + ) diff --git a/source/conf.py b/source/conf.py index 5c6c4fc58..8213f988e 100644 --- a/source/conf.py +++ b/source/conf.py @@ -381,6 +381,10 @@ 'user': (f'{github_sponsors_url}/%s', '@'), # noqa: WPS323 } +linkcheck_ignore = [ + "http://localhost:\d+", +] + # Example configuration for intersphinx: refer to the Python standard library. intersphinx_mapping = { 'python': ('https://docs.python.org/3', None), From 8fcb4a5528bc5f8d4b1f9116c61499c81dafd3ca Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Wed, 1 Sep 2021 22:29:40 +0200 Subject: [PATCH 0107/1072] Translated using Weblate (Ukrainian) Currently translated at 16.2% (369 of 2271 strings) Co-authored-by: Sviatoslav Sydorenko Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/uk/ Translation: pypa/packaging.python.org --- locales/uk/LC_MESSAGES/messages.mo | Bin 26590 -> 27857 bytes locales/uk/LC_MESSAGES/messages.po | 24 +++++++++++++----------- 2 files changed, 13 insertions(+), 11 deletions(-) diff --git a/locales/uk/LC_MESSAGES/messages.mo b/locales/uk/LC_MESSAGES/messages.mo index 65b4bfafc9fe3411aa969d3c52aad8f886218ac5..abb572ebbd9c38f21bbad70edf31369bdb307b2f 100644 GIT binary patch delta 8820 zcmaLb2Y6If-pBD95<=)Cl#tMd8cGrfy?22Cp@yzNNCpx&1(N_O>PQR71{4B_qM!o0 zvQi{8skU7fU11`^iUnB^EUfMV!V9df@Ao(NA2#nk@3Z&eKc92XJ@@oG6Fq+_sN`Ib z?|ekaT8C>|kmJd0vv_~%r{mSp41@mP<%&+c!q{1NO%`8l&@6IPLY5^5`E zApe{^K75+-Iuhz=lex{@Yrc(M?th4?pU~9ZvhL;}a}0)Ze=6#XcrBl6_a8x>fh9N( zS2Sh)wN&Msxeqo$RcM8EF#)IJP*lgixAHw0MgAkKh~J=A@EYpe1~+#n6pcER&9N%> zFcZxQ%~^jPKCcx#gv$F+d-+=|kDE{(ZAA@aCu+qGU@*Ri>fpF}#=L}Dk!z^>w^4f^ z%)yWmK1(!4HP8;#L2p#UgDpP{L&+ywehPLXpN1OP^EeT=AlvTzV&#ou+=;Y8b=V67 zudnHwL_!VBG-sQSnv2bq=6d`m^~O)jGFmsa}$Q?{eOc* zb#ClMzJr`UpgQ;(HIu8TLv_RQm0G(EMWF6CLUj~_Iy0S+bLb=@2i?gwSDX7#ukB~p zSnvNWE2!JX-J_1E4hLXGoQ(PcNyE9g0XaubL@e8YT~P!19M$k8)YAWo`aX$@bIW6~ zJozE06&``UMkFSX(BYV87MN>Md%6Xy;yx>XA1jkTjg{~#)BwImb$A{1`j(G(^9@n$ zB%oG$0BS;G<5~aFB$iX4)BFXh;fS`5laCEidt8KCiS-y2#H_Iz`NQqpjz2`*KaExK zORR!d@d3Pzn{j-CyApR%1FqAa^;e={dw1_zpk~k=wUkMy*DwS1m70ZmyugFj(Etj+SYzzN8+ z&J(CZwi{#cFUT=+enqWdYt~m=)7k8YDj#n7iI(@JlBmIr94mMdYm+au{41yx+JRc) zeOL?MMy{KU&|TRxXU`R>x+jfpxU}G*tZ@WQ%;xd@ERn+S4@{j+@QB=5bVq z=TI}dh&AyC)L{$i>JB^_^?W;2d;QJPsQS}U1Ix$2`@fikMzq2zJcq2hvmLb(7jXdI zMjfi290Uy@5tUCyy;dpaEYv`=P-kZ@s@|h^f2p|wD{%gtA`)8K4JyE`mfwy#{rgc3 z9Y%HZHtHMhkJuYe;6M!P?hZ5w6UnbaZOP}TExUvIf~(fUH4c5+`{5+i@B^rsrJ_2{ zM$IG-HNeME11T_I-ExUJi1cmoSTb0WYzZ_$RD`z5BWY8i)LI()ftOtvD7>qgEh>cUdc* zh}!DOK1<9nA4DC-T+2UU7NADH5;efp=8NX<%wqGXdBXg}{L1{^^xd?C)88FYWwRz~ z3G127Py>iF6U^6nUTi24Vkuk?26dEYv_Y zphmvUJZgT78o(7iiq}wwZr32U{t>gpyo{mTzk{mh40iKXQCnOKE78B>A#oMkAU{-2 z}YldKWdYGpGUo4RuCtVj~?yhK_La(ReP1<;Kd~4;$qUpcZNZ9kBu?qE7v2 zRJ}s1f$M#icpdd)bI|mgS5O`QY}Od<=9^(f%DZ9}?2jQh((=iuw;{#KA4j#n&|Hsd z*SEtG@1pkPEb76(Vki6swPzj1xHIXFeaZJnb-W0p@EO#WY(q8t4(c$T!FG59b%>jd zbxn5lIg3fO;l>{17uLCetfmu{>^78+YWOjX#v*7iC8*D+|ndGiu z4Avmq9yQOkiQ@G1+yM?s*j)sd;+y4SFkC@&2Zm}(b$CiL#TGw%wYZdkoYqNjj>9q z``2(hs)6aq8|S=+9=wVDuuhu0O&2r7-R5LY>oQA78+O^)Zy-8_P6pRFY6!p zCbEJw)C$bD`~s{^eud>Xqu%G8s3qQyweTI(7tvW%hhL#i|5eo6RB@*Jjo2JDuuhhr z?jxZGW}{B+W0rpkwP$Nlhh>Yo&-@dr!_QC?xP;p4A5n*`+$?wC^-#|zpxPT?jzQJ; zrI65f^&C`#OHcz^X%(Kwj^uY>C%lBiFe=?0uopFeT+2U><;gEMpTRKl>o6EMp(eT+ zspoTcxd~?Ks9t3)zNoY4*!n5@j4E~gbequ;klSd{vc{g zLLPLttO+*M``;yy;13Pd-p@fbT!59Z5Y_Rs7=|xkMcj%S$WF5uby)YK&P4g&xJw_6 zTH#pii9Jz={SgfO|Gy1NP;eY|SZ<&?sGjL|9EIw*A%Rpu`7Wrv?T_kcG*-bB zR6E(I=O0GZUx1oWA^J3fRU~vs)}m(qnpN12dSJJeAHk~R-@_o(GT%q2lQ)RcD~X%6 zRDtVbq7LcV_%9XM^#OjX{cmFxAHWAG?2C)AAMq0LDxphD+nIYCa4PE3GV9VwUKdEY z|0COyfmc`Qp;lk%v7`%>2wd#{ua?xWldg7F`4iIma#>BRCH4~ixHlgA<2lrIn)ou1 zazDm%?Ohzjg(I4{ZvY|QoRwUEWHbRb8iTdPI^8O zLzE-`0G3|6N&G@IFD<}9mcD^oiDo=A25VpB<8fjdp~3u(2rpU{S<@Fvm9E5O;vGs$ zuSw*`k@=ZuOZp4UAYLZ230>b2I?8`nhKuj_z_o|Z%a*>6XFHOfXL)hh(j9^rOam&s zZ3Xp6S0$p!@3*p(IF2&?>gyV8zCe03F^A|y*>t=~=z5gsL)kxY2XUJydyTTpH(HDd z*5EJ-i|xi=u>~=cc!Zcm=;hK^kbcv2B@&B?t3*R$q_tBXYg>8?<+`SjA8uu>P`|Tb z%4;(=5ib&rh{p(B$=n=3^dx7w5IHPe2UQZzKg?`iIYR55iN;75W1cuh7t>j zN<6z0|4CFQeE@w8NqC4eWLl!G9>fyj5YdgYkFY*|j-^)=iNQoudq(90i1y^8h*884 z6>`1ja_{r^mO88Xccfx8kxAii?M6KLvR5-Qw}`t|SP5gOGn(*_)-OUIqA$^ym`Idf z`WvY1^%pWBlzolKTL0^I_ce2yw1-Ma*0u7_uoY3C;BPpmi`CgjT30yvr|}tL714_* zz1ovFXqoDGf(WAi5&94OXXY_{g3uLD}4YaX;xl z5mm}`HIeimt&Uhm{Mqu|+}Du*$zTPc_#@HA@*<*4V+o{tl*vEK{X${|v684mByztR zQG@72d`MX*B7x8~g;)?s>96pSe0`9aOuRxoOmyd=OV|i2V^7po5#ul`kmJvCe9qEE zW^QqKgUH~>q&b=S8F6#Hxp^5m*`CDgy!@2R%)IHvjXg0TwNmoEo*5~5-ZYO@$jF{m zJg8ZlppM>LuP24b%gOS3ybq^j&Cc}Zd2(iYQgcXVq-5upKH|xqlQo0pyLT_nY2LY9 z)bO0tl+1fKGt#`-`57}as8F;e=5$4G>7An4EfZ>a<8r;3UItKFs{S{&92MLkiyksk z%M^QB&d&AD^ycPz(^?f>ZPT`fH#g(o{ph*6u@46M(lhcr{L4>g=ox`Q=X+-7a86b5mdar|J{&o{?+%MJ<79-Xls}M2&tz%{x?bP z4>Yf$y&gVxdHj0q8}l{)4J;tmH}m0g{J!d=EEvd#JR? zf4F2_$pV@)vXw5`diagW~K=B1e&V<-n1!x4QJ{hHXk=;VkdeeP9ZF#j?2V-y|J_~>B|H`i&< zbj9QrF$>Lickz!SmX=R`nHq<+W`Th&r3)77-=q1@mRnMRWnnIBN*0zBvND0;xjkv^ z+0#}vW8I}(8f+?4o5vDOWBwOs%sB3 w_Wk}hSvU?#$ugF)>;kyEs!8tCYWv^PF_GPBAjge&x#unKr5h9f=T|^#{r5SldDUv8# ze_K)6s>c>m;_*Z%R75E%hd8<&T>_PQAiRJJX7RN{$BQVCS z4l{^t^VU{@oqsU)J9sdB8pT%Z)+ib+a(&S@MOE3eg;Ud(7Zbwf~vYU!LWPW9y z$6>TzMV*k%*;=Xx&Ee*F%uoAN)ZUn7d9EE_idy^C_!MqH%}`u*=3ghKSNA(~#Pa0X zI1nF2-T1JzpTG*_*RUWKtl`gGDJ)A~6ZIgeSQOitJtfs%#k!EEx5p{m5M@2X2fVyzD<-JfB z8ff{$r~y5Oy>TM4D(<+o|Au;id#KG-D%M|$YGxAZ{8Tf;^txE3k2%yFjkh^r0&0fF z$N5h*6}4ICpw{#i)bUlQC*FkGY&$JKY@RePpdR=qU(emL25s@+nqq!Bl)^BqXjVbp zpa$l{B-9kvH(R1MUuUx~79byvys2(1>beUs0v88m{g+eGiL33vX4HjuqNel!vYhS= zvhQ4IZQnSvBkJ`VgIba~majuC#eUT0Jc$MI8tQxS2R_ODU2;4-7gys7Jd7IQV+sC+ zC!ltHF6#TR-r9F#IQiFD0570!c*VSJ7OLYvPzBWSI4q2fG5G$srlK2WqHfRw^%@Sh zd>U%ab1@R%L_NV)?21>h5w=M5FZ={*>87Ec_&KZ)!qlS%u(qy$zxV3${;R`o8j9jU zEP|)7A6~?jn4aX%#AVb#!;*cApq8jKYT&g{OOb+ln|h(Xh<#B@vj{a)+fe;?B{TmS zRF2c2wXImsxhj~3e571|Y=YCU1-^&6&>zS@7ggUsKNB;_b1??bV=D}8;QtP2i~Mts z@yNX(q@(pd5n@Onl=9Xtz-W7|}-p}&Us9(PmEnk3|sb#1cegjM6 zdejW;MP1iBM1^0`?j&mJZlcz>Bnzs6RYT>Os1y33mgo`7pTuJ1)3F3DG*_BiP&fP( z3*k{Lg{P4{=DBNB%Fs}N9i-T?Fu)?lKUAQl5^9)6G9B#*-Fejm=b{cAGXIq|Q`BK#GUxm8P zTGVU09`)hcjA^(H)49L9Nkt<~Y3f{i^iWH(A4}sU)EDfI8O4^?+BZjCxFhPxx}t9U zAnHK|p$0etHIVV<1k`4ojGk_AfQqL6ENY5>##9Vx?(gBKv zb>q{hPwlss|A-pkuc)QHhq_O(6y{%3Tsg(RPy*@#jZi0~p)TAW^#q+!1MP--@}YKo z1gifSYoCbvo=n9HAsNEB=VPkzX5bU0Z)|oIwrf z8Ybai_zc$N7mUtZhrH=-JJ!ML7|s1%bUQj>3f908SPti-cJXS|l58>eqt^Iq)TX?M z+Re96Gg<6@|GZ?>@ia3FwR8iq06vbM-owdMD3(Xvs1j;mNmu|gunK130vywx_2<>(&tLx!j#R8o+5`0;2p;Oj%gpuWF7tEq zTht8QGz)d~^U8QCgufB7Fvp8z`U5DB8hF!8=0Ac;CJpM)12tuX%yFn+CeNBn%nhg; zer%pHuVO*kLpu9=s4#|+m$y6`+4U~o+A};Vx@DeuG`ybWa-z?p*7zc)-W@Nni zy!jfIr+uq=1Y^lBqh=_whre_cQ3Fgs_0K?U#sR3kG!7$i29D$YE|`O84R;#goOMUbE^C_)E|hwdR>v3VWd*WF+pziCBm8()u{Z?;SU?uYcYe zEUx!|6BT_B_Mkox*RVOpJ?O9XU`!!@1oeGbh1#qKuo9j?P5lk5j?Me|ySzVEBYy^U z-Pf@NogxWY5$&`32OM>neugFQ^OL#C&)M)9@aqW7<&v zkJx9iJ^81oB`Gn?U$P{uOrCBIL6+Wg)2W1WAP4niOE3)IKt0JC)BxYbP~2(mLT%Q4 zs6A2gA%E)QP*dCtQ?Wf(#pf^q-!i|zD82vgVgCk|P&bZ6-8cdBV?)bRPyk0b?UjqA~jNK`nYdU zPr*0F9UxTJ`UHPA=iDvSjuRgd9}wCHd4+8fEM@3dpXfwTyx<3=HOUCFkwh!%uVPuh zgF8<>uSC%nOH$2_C1JMJ)u$!VotQ~{OPnLBaQtV~cSc1^b1zua*OTvRFH5@7@hR#d z*oLS?JWt*QPodWMIbu99hUk$qwo)nYF>2F^&xyRE#e33{!koRHy8i!%3cpN(r5$+{ ztFOSCqDvt1ntA*Le|RP^CJ4iC+aXe(9Ltxx<#6`MWXruI(iMl(BSLA&LVZ$uQ16C^h^j<2 zqB^0{lw+H)2~*sf0P~63(~JNv77q;G*>0;#2;wrN?au>5ElrQ zro{b({xVG?rc%!J!+tQ=%b&Wd&833_@>px5u&r@ zwQ(r%1d(AEjx`&YB{(*m$SV`6Od=**LjwKwQQt@uqJA1%=e;XGl5`>V5-LZD@^mVO zONk9cUTI=CR6d``BtB7MC7$Coh$zdG@fb0Ic$)Z*SVaU&;8b*EXdr*pn6N-<&DtS> zrLhh3<$Pc3^PGdV;{!$FGedKpPOKBymN+~lkel>FWMFEGKh?cmNT6KXKf?l<9oB>d nI&}&U3(W1(GbHD)u5AM|y3GvF8PL0R;7ITG`2siko+\n" +"PO-Revision-Date: 2021-08-30 17:33+0000\n" +"Last-Translator: Sviatoslav Sydorenko \n" "Language-Team: Ukrainian \n" "Language: uk\n" @@ -20,7 +20,7 @@ msgstr "" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && n" "%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n" -"X-Generator: Weblate 4.8-dev\n" +"X-Generator: Weblate 4.8.1-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -756,7 +756,7 @@ msgstr "Так [1]_" #: ../source/discussions/pip-vs-easy-install.rst:54 msgid ":ref:`Multi-version Installs`" -msgstr "" +msgstr ":ref:`Багатоверсійні встановлення `" #: ../source/discussions/pip-vs-easy-install.rst:57 msgid "Exclude scripts during install" @@ -1423,7 +1423,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:84 msgid "Package version" -msgstr "" +msgstr "Версія пакунку" #: ../source/guides/analyzing-pypi-package-downloads.rst:84 msgid "``0.1.6``, ``1.4.2``" @@ -2455,7 +2455,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:556 msgid "Here are some examples of compliant version numbers::" -msgstr "" +msgstr "Ось кілька прикладів сумісних номерів версій::" #: ../source/guides/distributing-packages-using-setuptools.rst:567 msgid "" @@ -2471,7 +2471,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:576 msgid "Semantic versioning (preferred)" -msgstr "" +msgstr "Семантичне версіонування (надається перевага)" #: ../source/guides/distributing-packages-using-setuptools.rst:578 msgid "" @@ -2516,7 +2516,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:598 msgid "Date based versioning" -msgstr "" +msgstr "Версіонування базоване на датах" #: ../source/guides/distributing-packages-using-setuptools.rst:600 msgid "" @@ -2540,13 +2540,15 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:611 msgid "Serial versioning" -msgstr "" +msgstr "Порядкове версіонування" #: ../source/guides/distributing-packages-using-setuptools.rst:613 msgid "" "This is the simplest possible versioning scheme, and consists of a single " "number which is incremented every release." msgstr "" +"Це найпростіша з можливих схем версіонування, яка складається з єдиного " +"числа, яке збільшується при кожній публікації." #: ../source/guides/distributing-packages-using-setuptools.rst:616 msgid "" @@ -2569,7 +2571,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:629 msgid "Pre-release versioning" -msgstr "" +msgstr "Версіонування попередніх випусків" #: ../source/guides/distributing-packages-using-setuptools.rst:631 msgid "" @@ -2601,7 +2603,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:644 msgid "Local version identifiers" -msgstr "" +msgstr "Ідентифікатори місцевих версій" #: ../source/guides/distributing-packages-using-setuptools.rst:646 msgid "" From a9678f94d145f6921d7d42a9a054358fc09edda3 Mon Sep 17 00:00:00 2001 From: Mingun Date: Wed, 1 Sep 2021 22:29:40 +0200 Subject: [PATCH 0108/1072] Translated using Weblate (Russian) Currently translated at 21.8% (496 of 2271 strings) Co-authored-by: Mingun Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/ru/ Translation: pypa/packaging.python.org --- locales/ru/LC_MESSAGES/messages.mo | Bin 1486 -> 44338 bytes locales/ru/LC_MESSAGES/messages.po | 899 +++++++++++++++-------------- 2 files changed, 470 insertions(+), 429 deletions(-) diff --git a/locales/ru/LC_MESSAGES/messages.mo b/locales/ru/LC_MESSAGES/messages.mo index d983c38df69ae5c631e282a5e3c5c0b58a6be145..a18f4a67ffabc727ee9e8c0999e51fd1e32bf73b 100644 GIT binary patch literal 44338 zcmeI537lM2mH(fJED;ezHrXDVBq7zE?oJ?Sl1NB83nU??6E?wgb$4~AOm$UJOOnPd z5Hif3G?}KXRr{K}x(UXFp1?&J{0rr9#N);qa@J{d;a2Lo>gKvOs;J<+C|Iw3! z;8oycQ02P76Tm)DUw05pM<6?g}skz7eFU;6vca z;8(y9{GG?67|aCXGr_~a`QVA*MLzuskJos-2|R%N?*m^7-UsdnZUqkl9|!ptJk1}? z*RMd;e+ZpXzGJ|1!IMCZdk7SLt_L;#`+WRUp!)kAQ2F+O$VY+4fy#ddcqq66R6qJb z%~KH+-8O)lpIbq-`!P`EKko5M9)AQX--{sff#5Nq%AX3V-E+Xh!OK9kR|YlD*MREp zZ9e{S@Cf2x09F2gIhWD0-{~Rqs0RW#Ek-ZwEE*2f_UnL0!4pC8#r>eh_b{mW-wCSU-vD0>{v1?4e(f=s=H};M zP~{Hy7=jwd>7d#>6FeAv*yC=GUj$X(w?MW3V^Hn=8dUiMrn`1u3F`h)p!nfLAD;;F zFKFYB=6}%R<=`ubzY$csn?a4|4ji?x4 z2Rs%%UIB{kSA!bQJ3!6LJ)q|8VNi721&U8U2dW=m0*?g$6+9Yzai=SH9H{)0z(c@k zpy<#Aik^MoMDQ9=`5yMT6MQrAr$P1S9Ec!14^;nGf~xQJpvGSS#V6N*qU(*|zTmx} z`tzWVe+pDPp93|2Uj{XAP<*=H8mv@_zeTU9- z^ga?)J*R@|=QMBHu(D+L5*t*cp`Y0$4`PM6aQ!M)!_c~-MCsn#V-K0PTmZj z0d58-f}ip6pM#JfIF-p_ih@C~06qY|7Cdr+>sJ=kd~5*F_p8uz{6@!)Qc-v&jOKY-$k35#6(WKj9rLD6}MPwxkn zuk7(gfB$|^e6Sl7Uw+fy|0TFT@dN3+`gJI%_D%uS-wsgyoDFJS^n&8UBDf#;W-tR@ z4PFNR1XO*C&UN)I2gTogpwh1dMW46%`*(noiEjm84Sow$KleG$>A&MaM0ju#cmVi1 zQ2p!&wI0`lkUV$@)cpS&D84*$iL)!u1kWUX2{;kF1x$laf|}>!mO4JV3~VF*R#5dl z0`f2T5B`MUf@O|B20>Ui_z>6u{uC5_!tpZx3h+?yQc(TOdn|#65nl(Y{M*40d<0a#zYMCre*pIb ze+X(^KLclie*)FcnHRWm%?A}<0;=7ML6z?VRbLKN`|H8O!8d}U*Ug~D`yNpF-tW^N z0AEJ@qu_U61RsM(5WnLhH{Xweoy0#4ihutMo(L|v*wG~qir#MpXMxxG_|qQ0=<%x_ zzYUhj_kB?PxabmxeID~3hdo{ms{Sn=-vcfoeiwKa_*0N63MRhJ@%5WQSS)xSI1&6g zcno;trEVTNK$3!mpwjOJ+rXzl<^L53$%9uRe6$XVAgmZ{0~dn(z25CZmw~4fe+$?F zei&4~?|`epcK&b~+yX+f;8)-b@Z26}CvO6$5q}KSJpC9v4g61VK6qN%@l(#@TR_q4 zCh!&D`+WMtKK&D*_~IF`AN&TW_Gb4wzFOz;&ES2cUkxJKf=PYO&Z>gy&x1bx58#Ew z523Piz%^hy_z_U@`8(hV;Cv#IGyS0YRRqrhH-YDZPl1vf69ydJjs{zZF9y~A22gZ= z8axjC88`=g>7bJj=Yo@nZw9A;JHQn91F#c3Y>k_TW#DAuSAeep?+4Y7ANceWvyLuH zz@tfj1e6?q1{D9l_zjLf4h0tzKNUP1EP%?l71TWc$m6kV-FjFK-b(tNp!z*6=hj6T zJc{_$psgqHmBb(O_yzDp;@<()elX-o3Z{xqPIQBZ5x>-95!{dX)!+p129NIsk0gFK_#n6wlzi*G z++oGzwV>wxHc;(<1Uwyl0u-Hp2)-B$N^V^Hf}+PM-~r%SAWI{d4~ic5fd_)01t)_w zP<-(RP~$(k?Ch@af!!E zK+$;(sBv8mz7%{6JQ@51_zLj*;344eK#k*oH@f_@z*)rK3aZ>LP;~h`sQf<3_SC#ZXVAA&mjH=Q2c&3D7riZ9u58iTn-+% z(babeD0;jd)couL=YfY_>FQYp&Lw^$C^|d~P63a&%FW|EQ0prV?hmd3wJwXG=5;5i ze*P5Hc+cA8#DfBe;suZKXb?*~0T3u?aq9n`r01ghObuW{o& z8WcTG@p!RM-wgJX{$5ag`e*Pc@bGJ0yailMybIL$?)T|m_US(cFCl&Lb7yKBgasD2BEx71y&K|lQlsxz_csBSoa0z(C+g-js z@B-r7LGi&sH@I=m0uLvCIe0vH9jJCc2x@$v1qZ=@1eI^$jZS}D2A)d%4sas)X;ACr zr{KBZe}c2YbKl|YtLs74x7p(ZpzePHTm=3ZJP2I4*|onCJdt<>6koj?lsx${I0rmo zi=)Hq!5PFK0vCcm09(M+O_T*M1=XJsunHb~v)gCh0%|_?xdq=9co}#**#1s8p1%b} zkKcmlfQP@!>HCYoyNGWEXMxLab@TQPQ0wL%@DT8upy>D$umha%ZYNLXfYXTgg3A9M z@NDo|Q2Af}9;d%s!IOz!25SDV1kVJY^y&Ww&L@84ZI1sh1+~r|1Vx9Rfa+iSdmR=) z(f1+nG;k;QO7Oejf#7dJjZ;K80+Q2D+Iiavh?XMxi`0L{S5!PkKQ2A&9Z-0keyRp0{R*MUpHXTcCW_8v#a*emCH+Wjo3{?xz;;5R|F|9$WT@JFENc)&;9cn=1Z?=Vp5 z$Ad2ePXS*9>Ks({>-SIg*Xg54y6Jz2gy4AMe*<0yGL+y^!o`U^Cv*K8!skd|OVDpB z@uLaf<@yFoakAh|q-`MRx6VQEH1W-ZvX2jf;>))ZR{6a9f?8YaLCNmF0T&Z`xE=sjf0DR z>${S)*<5Rm_4_Q>QwZhRZ^&v{DZC*FCrT`|`lyU2Gv*PFnF;9BrR ze^2l(!p8~sD8lcTgq`FmSqy#6^&JHLK26v__;=y5vuZhtNK6#0h;(QlEzIFhth zt|t*@aD7IU0bHNBmL5(1ensRg(%wc`%ykODL2-gxnoFF-wA-sk#f%LZ$N`waprxWzM3fv6-ny`hC^XX@MdC*^D5%hc9r%Q%KzvceoN8r=``pe+CDx{sHU--|g>D1aG&y*a_fAh(AlXoPd}P zP6VT03l~oip7aSX65fA3l1Um|?P-xoYc zc&)$xp+x$TT)%wCdN3HK4MC+tVs-w{qDoJ?3j+F^vJxYn;gSVK6S za2Mef+r-MR2XZ_jVHY^@(pJ z?VW@^;_oL6`*gt)(#wS3aoz3HPXI&GUP-u`px-W!pXIupFom#{px=dr?Sz*QzDLk+ zyU+g!*H3Xh7n}n=M7WjkBtgG4VWGcX39j?kZ}IpY?*D*r2jQ!P=yxFZ|1*k!uOfap z;Tt~f5MO>G@lLM$ef-bFk0xA7{A1uF;Gy6=@KfL}LLb*{1pPkb(IS&4FUq9*v-!a? zkDyJSysSFZn<=^L6`67|(^m=e=^^fi#ZtPjlI_d5o2$y1FdYtN^8J}oDxaxVO6go! zt_WW{Y53OE|xjMi zvp!RtV zCG4i-*@0oJE2^ZF&JSkF;Xt7jmaD~Lp;XEAhs%d6YiOW9TdtI{z10e>m4o)FZ5^q$ z_SDoFx}273YvZ54Y)`dM)8+Kk)S0QaGu@@~c5pfE%#OCHL3_uvX=luA4?0@H3(~o4 zf4U;_i4aROl{C?G*qfmnnXp*x&1K7LxE)Mu30IYsZ{_-I-YDm92Au=hT&A<9ECRF? zhkL?urnHWMRMr=mlk8BsG#n08^UMu>?+iMNnPO+pw2m1)VYeG*&{@h1boMN*<|^4# zM2*F64$3|LZhxlSSIQPuNvf}quVnI-RAsoBNfj(Dookk{es9)rp;`)y>Atn;!OWas zZdk}?QaO#JTphA5GKcHeq$@^;B)P->LZ;k8iE?(Rn1d#z!W-baU~V6*#wZ;N^;WaF z3Ke8BFu>gYex}Y1bb8y2o|bT8XR*}T(>|lEXOh3WqHFH_rCs4*HQS$w?oT_Tejg4i z)8E1R&8gGk!sWi~+H57IM&ZXoxHdB!^{X6JHoar2%dbhBTP&{24A(hJg&akq(e(Fc zMOzk0zEH{77@~wyrVQ~It-2m1I#!>X%NfB6a8D^5$Yyf=()s?rf+(pBxlActq4ZFpznW85lGQfkUSCQV zi}WVWnGes0tJY;R>$Omq8xM#m>Wo`o!CcmGB2RBNFRsmOfX%ePX%5N^U!hXVhnFvo z7zy5RLO~h&!*T((V#LK_F5Ab5S-8E`e7|)!k=CCnN-X93hQpzBo+%!JnJHDu=0aBP znf1#V!Q4{cns7-rU)>PQt@dXrl;L8qituq+tH_5ENrF^nD4oqIQW#20dN7f;wxMLG zMMFJ>YB|iZd*g|Qry#N5;woa4ycu-cdu`X1e?&w$OA zBZMzD>fVL4URYlqr{qw&@BHrIoDxIR=#2N7yGXufHe~v$m2__|({O;Bji@KHs^Wbu%K3FJNu5_eSRHWRu2IdIn z<Ak{7j7 zQ^{n^1`G(MD4LnXO$H8E_DLq#P;yn+CeemM(zFt9(m<`z(bZtn>6oYL3qEl&oxoSTYF)Ohg_E&9n_`^V%&BlRWBWZB${^Wq*=YnFl67_g&7 z{aQb*94kE)(C{)9+R0-RvmTrtSnT#K;YqfXP6}VwcG>Dq^4N|t>?sZ-D+UTZtI^*! z%~{?EitY}S3RuI)R&U#8SP)oL(S0YKSYwh5zKoYxEJZ{*U4lBSZxd=hN2V0zReQ^` zNcMFNDJ5pm1QrB#-Bd>Fi)`I7i5JZ49+Q^Fs>gy1%cZ`s0z-|-;BKd}X0;C(bK9AQ zi#6JD??#)D(VcYZW2%fa9m1(nf;>*2G&CK{@I;kSnyp7S`+kd*%#_N$t!&&^D(-ReI%y6OYWy4v9mI*TUS4{+Koz82Wclzn|EmFMQ zIyaq<#OaJ65t$jBTV;n~QZ~9GLzOMKPjgo@g7Y%ND3Shha9&;}`ocn?U-~MXc;3S9 zNr5-;S}GeV!ICulpcNTy?T}MTGU-yDeqgCD!4H&21v~mD)nJ{ryQ!N51%S2E|KjwJ{AR_8__!ReQq) zx%4{7(jUgRX054IisjDM)OChfs zLMu&S2^?&2l3EI-L6w?B>wc2`1^vmC`q0Md99Pc2l)AuKxxvz`?L#3393^V0o?xl% z@qo34Ptn?_FUbV>Q$O{ z+6<8L4VFi{uThg2r#qPzEN6q_*H9!^p%Tf?v*!^jM4mw{$S6gFh$7k%)VU>P+i~)( zlX=vXmExP&qNQ}bsN2aek6o=}>=oLt-;CG(a+#TaPZW)-S}GQhdX4P9d>9`VmYUDo zj``&;J37Ojo^rLn5ccN>U~Ffj6pf8KLXWBSQUpCcV+##ehn|0-xY7Ewn%**dGO9ar z+4=rOtHQehFtNi{FGb}OSg~MUIHSEiTvC7?bxMF5TwpH9&QRhF0kwYp`j!Fg5$!Tf zM9o{=)k?Wm%C(-^vZgW=tiX6>S<{(*Uz#LYP$Eho{G6a(&alMz8fKZ*#u(6_r!*9&6O{i!-=sr8db$H6&u0eHI^W z=$;wInGKLsd34_fE!R_LxKgJPW!qns*A%L`{%|c;LYVF?R5AUHb%PZ?YawROEIO=I z&3|v>2cw%8vq9^_){eM7%LaQ`dE_xk`^$k#Ay4E6PSP7E2lH-cFtWr=@NzK} zpW1XxozC`hB~H|QAy*ibc3rjE5F2Sw<(;*5jMN z!xZ+)TP;60Mov1CqPBSx%XiM0I(2G`6_cw9dFs?Mi_UdU?SAF zKgDW@j9a)tnMG^SaJ-7^8>}8z-lVKwzER<5fFchrGi_^;3M}E7EmO^kg(Nv`xM+&| zeiAsvqv6On4cl7U8=YQm#BXADS1o)~xIUA^?qwol$yF$oPYfZt_k`pMxWaUtm>#zC z!8Ms&5x*89C>yyMG)LLI+a;Lf!uf)m)1*6h{OQSw$_2yVQ5(>yS;@(LbvIq1ib9x< z59DBlY7t{vF0lA0+JqkZo}B)yka60C+Z`MBKp{unA|MXvHCm`}hq>ZJ6t}r%&B|># zx+b#>RC^(3f5w<_E2E>KU=?E3nHS5Weby@TL>h~97oo-m2!BQkhvV+Bw4=R)m9xsm zq~7_dEt6!&@TMgj1+2TH%yu)f+WgicSj8g&Jv|6?77=N2hs=oV)NPz};pJ5XEfUps1QW0rM2_=a44zBeqH`arFrCWf;s!3}i; zF7yXBz9#2OiB^JnkmBJ)snOw$FX9=?3<_^UT;O+T9-{@JZSVzBaekAK&jc5yOBpmV zcISneUME1vW%q{)hz7matr{8BDKoI2jI@tlad=*qp9KxYsE$5?0M{Kh*g%f^c+LW-E zDd5?oW|n~`rs*m+Wz{_QeU(|BCy2B)rbIEzGb7n6%ygu7e;OI-plEs_--X^m&PMX2 zq)S{%;H2O}POn+XAYMhLH!_iA0$s>~*I=i~Gx}gAiBFO=!77qb)9tJx`A)*QNvkNz zTIYOOMOx%kR+8zHtg*q!@!o;pVi<|Q3biLTykY0qM(%JtN-%im*z`FpWfhb+R2NfB zy_leC=^Gdf)Nxs3bqBi1XDT!0P)t<{DLc2Q+i0CZ&s>~Q>oVF4W!n1YAV}1vy579uAo}F0MCXdy{G|N6-4!y6#y2@J^FYdy`yL4!Zgcjj45>vVjz#brs^2x>Gs>}JPHtbVhSAaLHu%G>c*fW}Lffc~)#01Mp2g)d#zWjtZ*{OtJ9_#^ z?YI`Y^2Dpy;o-b=p5x%g!N8*Kt_`E;yoIeyD>)qr@IzIKY41N$CkI?Yoz4q#nGGA_ zP7Em4qE!u>+JLeJy5H(-1Xm~S!9ipUlgODcezn9j_T>uI{+2<@;HI7jLoAO`r_~M5 zRl_+(VQsZOAXX+WM6A>n^g4H3`4aXzY~DKP4C)kfrz4V-EVh)Z&gSgA?79ST))KQJ zp1cOb!7|`C%6G5H4pizb_F^BlU=!zg;ELUaN=^upIsM44?0W=dR*Gv{4k0f+a=~*ai(i3?eAG{tmEDJbg{3LPIkN;CABa+ zE|c42#1$sHH(X4&!h3SqkQcU%wb>|7UeD^5#LY%km$)}trP-|u(wIV6d2tUkq;)Ql zr_@AS>nP&c6DC?(Tg=5dLf zCyBK%X|NO}%)QUnKgtttR-_cMNgFnmXF%Yd3a-*txp3t&wmL0^O=UI_-H^ijqPxAl zc3_y`79D9BceCR4WL#@+uUsxyXnMm`vp$M_Nowx=MDY+BnJ+0uoU<;FtThMz&DKJLVUmX{$_Kz6^(!;CW$uAnC zm<_ZeLD3rWxGs;KAkbAx=+rJ(JYKQdJzfzE;Qt8L3v#E$l;#wsXhoZw7YgC3p;8`wu+MqlpLH4?*XmZOS-PMiLDexkB zwTR;*h;P0@B8%B%1e-4%Y@?h4#F~QYOpYKZt{tQYZvR+%5yNG-)QPl>S+h@Ynm%%2iyuNc&Kp@HqZgDbFV z;RidsFU98)i~FPFwa##bo^Zmhp2*PClP0Xl=n09`((+)oKXnckUTS5bGn}ye{FL*% za#S`SGr2RoxNGi;)Y9`)^XG<(&hK2h`1DK8U)D82$E~TADAqCtSfSJzE?Bi>Nw{q8 z(k@Ptm(E?hTBc5zmw5E6)8@U^blF+>X455zKYP{61*sYJ zd>Riv*A&lSL3nMjX7pw&6PD*}?VxCe%AH}pXwmZQjT-rXZN)OLm=SJEDhjNIsIyNimiC#Vx6*V)BZMaZ$)awM0$B_Ikw z-nXdT&G5ETXlpbG*IPAv{m7<~%^~BVJM?!4k?z>(^?csHsNJi|YajPrt35`iw=(Xn zwZ|DdV@Xubu#6&)kxRp;5G`+I5W7Zh7`Y}?VU3$xJ8F;6Gf`lhDC=#V(`s7-9&z|D zdS#<_m-T|_)wFJ^J;IdkFj8F$LLE2TVh>U0Mx(uEn~SaVRkN+h+OAhRYR#wH{8t*- zlOtQ2wX!3q-A6?`Yfpw_-u|dvi$E*OEettIN8s&npL zd)K8&tx(0SB`1}xg-jx(sAdg_!F>&SA;xMjE`35W1v+mR18P}H=ItR0T~uDgZ5RM& zO!cR+eVz8wOp{)*uxwb=QRmJbayq!zYE*s11@&ef&HP$$qJ~a7SxJ45YXX>Ri8zzM zd(Th3+abXwiM){;_MVp|vD?v+88S(ae4@-POov;Dwnh@2v0jQnw}=x)wm{3Ps9}q! zzg>jm1|6oDgtr^RuG$W0b(7*sr-Nd06MvGRUVJb#O2T#Ox@N*^6wAQ+HY?UsI979Q zJZpSUL-c(7`o(>=uJ#~^H#K88$pUM5qmAcnOaXkcidN=CMb^s3wV$vwn2I;G+Lr`k4 zY4Rn@w}rDty@EBTCmeZ)Ix?PwX5`XA-kOnyW|W>BTHI6%TNo2P%E+#v9;1-S9yN)s zrpu%nIdvPhG%`ghPb4&M5wS+Iv6ecG$RwdMiLwNnYeL4bxvNEj-rPtptVnbi^McwL zO6!d=&4sas6r|~Fr%}Z%*fb1M%E<(o_}zrvnju>=woW~h*nmyJia4s<=^JH@4HQv8H%Ez}hWFoU zx6y(rsEAvnq;7CSmML(JD2W(i_-ZeH>BO=w0p7}*c>PvQg{uEA~(*bka2(?mE^#x^=)z+2$njj*cQ9*)uNG@oQ;#>(nq z57qeEB|3vO%0#n^q6KGUVA_qm9g*YrOte60ao8y9hobU{Nc_NwUXWesgqs$eY(32u zn|VUrk}|P@j%O;I9)W?~c3z{|(Wpm6Ia%nt4!2sXTm{1CsrIKbS+Vt(3*Sifx6)+sSOIHA^tlgct%fwSZy!n ziY*{#*)f=1R+Y(Ytq}=nkxn~J1gRA92k7|Y*qvtln~~^btQV)FjAt|H;z4aU9uSAv z=;0(7Fg^ine38`*LuqoiR-Iu26Wu{q*xVYE$-4EN^#}=C%i=BH(|cf_r`+C5(kk8? zx}_(Ee5VmnvVG5}w_ly_(d2`+a}qRkIbp@!OG|DiAqB(W%@d@lwd{#$9FtSayK!sn z2ZPNm(OPHzoiXKLuA~i0lcuQ|pN1_}BSJZ2K4K-->`t^8Meo&A(x&+)DRE=n38UGy zHL0cBpjG5K9pBrhNkqSDBwjB{=gI4UU=$OuP{vrod#Micv9e4oYaFhIx}TFerR5}9 zqIKi4*pY#$#L-LKwkg`~$RUMT(-gT5LyiM&Zn!YpLR? z$R==`edvay6bmV*3>D?2;#dMoH7nEO^{ixxM4HAMJB?fw^vT&VyL>@tXtHvg&risW zNZsb(rt3I88lpVIXim?%yT~!CnAD0rCGu#-SOKDsIAIrhY80t$jX9(3dabVUGyqHL z0fu`^ZI9Sh&MA#v%F3ydF=@~7)^P*RqfY(SLfQ_GsAFAofWgml4v)j*;w|o@=rzXJ zVe6U9`9&iwBy!M>i4f*~EF~o8$PkNyy}q-ILe)0TNrOfj_gXDoWYxcQt<-q`#h_s& z5lqg!*iaiS&L}^7; zWI|HeDA9_f9@`gf5@Sa%uYDsUZ($-Mzp)nt@tTSp))EGqjD{VKEgYMJXg?=HyIiJ` zBU?!`=SN_Yr>-GHVBeU;)V+LVu1KlP-4kGyFnp7e-bDwkMi+}m*k^2MnF z4?*#&FGp&8D_~SnQ{d(>G->3ST(Z{ux5j~H^N8yuai4(yMyXt8C#ii*B#KS6HcVkq zFy1uU95qoXkd3)&Qd0vxWcbUe+K@;?_*C3GfKBe0ypa53bwU)=^pd=hb~d@EmaW6M zp~hA&ZbwwfUpmfBgvIT(TgJaFNkTVWyIdPhp{LCf9SiqjH9XH+oygG6?Hc+kp)~$j z8oYYsuFvfYC}p$m&a}J>a{Qi-ZxfAMMuN_oKq`a?2MNvR@cT5Iod%WEw6TU95+HVv zByJhcOEZ=USX|BOCVA{90TQdzuMcr2I+&@$Tx#r&_j8VIkvZE6*G5MIjm4Vv1%?m_ z)s}pCcmU!RU`?A|X<87$Cq1Dx6MN09jvH;!ppIkwSvqE8 z*zkFVnmljTdlQJ-1aIX?Q(9yvpD2jF-QYjiV7ZgtLoX(^G&Kd{qlBmb2~!EN@B`lSgLhUr{qenmbQ|G^38M5JS^Vac7?hgUT=QM)H5mp0NoHeVP1JW0-kL@dj& zL-M-Kt1}qwfgaLEyH69R<8H@SKT*|kYN(RYi+QDWp$I#4%n93nbK#O?|4aGG;IM5( z)FTs;J|Y5}__Kqmk+($(R5L8P^G7Fp`a%a%MkWL^=qwfqS6Uv~GU+T^*48~uvKg-S z5bA00lY0n2{6T*IxXSa&KU#En7n`aKk?m~fY{MqEsH}1l^$)25^D*q${U`qPUB}!? z^b%G>8YL3MuU>JQlu9TEH&)~O=Nbx)$xMB&=NiT|-8jFaJK#lia!LKAyOD-5HzUH{ zjKsSkH)0bT4F)tyLqM^?wQTeJb_E#q$&$Zz1>VI}tJO$w;|*$1JZK7d)rl~B_$$Hu z%!T?V26TGG+*wjiG9%0c;~4apiwoL3~ZL|g@y^mBZeMs7@rTQk$l9?)#iH!VyY0o--UfWPre2KHL$-alDW zlUUOuq>Nvdc1#0$p0LlYF}D)sf;Z=7wC3bTod&sW7U{5OA^~~ty?w_ z$OxH;s@!z7GeHoU>Z2YW@&Zuj1RA>a!fbcsqd%c{ro4#aeE&K%tq;m*WM(MzvPbsD zsoEP-rsT%>>twJssE_e_Snrk%$>u74aNriX$|cz4i@L|;Bc9{BC~J}^tMERC#uGrS zDd}AXku0>cX`$!kXx~doKUl|KOx51C_Q>YZ-}w0}McWGh!d2pt-Wx&;^st9V4ra*dm6T3mbz2jPYL+{DmWgM*%dMN;{>e{l?eWw6xdpbis zOFMFN{nSwE4Eu67E6Ll@kHhTJ$avf9huGVjSEkjd)udAy6K=8?GCjQ?UMtdUXJ;@kv@a93 zV1%%wboyd*;-B`?5l19B67N(%9s915lW8({BwQe`99uh$Y$6y7?q(9?v0}wL$>(wg zwY#~&{4!1QFvwf(wsou!<0PWZ9~YSzOG2crc{t?sa?%!Q0;&_MmOSAK0HB}Oes>y(!}(0e55xA3Q( zdb|-{Y-nX`^rkk0b$yVmd>fDUZ;sz{XjV#d+R(;m-$>Gs8rx{|;<5y^cD->Cxe6P0 zIO>dvb;)|fB^ztUvX$uW=!B?xEl{wCpS}J>0ef+1f~Vd&#Trdf|C$ zy<{MP>fGozauBO}Y{KcNSV3&&*kv>Y^);^=4+1DV604_2Y*Krw)ivrOyu(kLToVZF zkTe-^{$cFVL}t<@Ld+Ji(*EGs>70lZJLzNm5FSl6&`%P|EK|gn^M}aJv(pImK5~UH zF5a}~V`8l6CRQRH(PL`jR+!t{i6lHF@ekiRah(3#EbF4nY2sV;!aDg$h z&Z>;@ZFSfl?!>TmH=R!yV3rmB(4wrn-E9lUyfS?{tPn36eK52%+hV8d^yrr4yw(fn zh4JA7y#Ia#hbEqJN0JW*;ONKn5Z517X%t>F20zi?)|!+Kld(c0wnx#r*SQG;ma|d3 zY|DXhN0ytp?CUc|Ktf)b3@{>aWc(=S?0$ zOvpTEW4gJpb;XQhH6Y;lpSRV&Ru?H2eXI_}a%Vh$i82kcw9#vA(~rVs!f}VH`le=Y zV<9<@DKOqCwNroYp@rM1Iu?r%(LF^UeFTr@jCtykN1P`Xa$ZVi;4U{s@Se9f9TSS} z?Ipy92FP32fljI>T>hHRWOo{J$Dh-C9(go)?Ixso?To`-SAIUVk15G^W^d)H+W4(JtQK@o9OG_$Y--8(y&M&&lsX$8js(JSmHp{ShOa12DiyA zFu_KKYg@jtI|4*Hw=t+=wJgh=2b`e|?90fU(%7B&grVxJJ(5Cb%kV7gU~$U! z)2_k$z$FgGoZpVH`Mh29u~o>tnTtzbIB(HiG8 zNlK-uz;i0yda7l|sE%J4*-qMJHL4r6(q9 z+D&g#X%h)zNsv`}d~x^0Jv5R1BJYdN6eOXMn~eT0`T)JBxd%p7z4 zj8i6ZkvZcBj~SI>x!nO5co*4wH2=0Es@)my6Su41O*@gWqDF~b2rj0M++?xNv%y9j zPKMZqvWa?*{*UXt@?W@;n+h4mAIt#zA}0Qmy?J`~_IXUJ#=eiKD_M^cJ&cG)IdxPR z{U28OTqcL-c+H$Zs(bg~8F8jj0tVBTLL9m$G@qSBm)B4uJOSn`8RH9yHP)RtI^HBv z6G;iVi5!VZC$^W^8fybW)TH_M-{lLPOjz>=lcSFc+WvW*uXgUe@L%#JPyZx*;=>a0 zr|ACYtDgU#f7LTgrBVqwjm;H3vd4zr@8M!WyY>I%H$Y|DB{q?W6A6dMntmqGeeo;# zQP8~@hDfS}{rTLsvV9PAFZChEo`=2sT(vx>t^42UyQH4osp)4q+&+-`0&b%eO{1C?ISg4NcWK%cC_(_Q2#G{)RZ;mt+n{GrqZ;wGl0we z0^^fzf9dy4wTPQ-&b_gyEm2a}nr4^B&U;ueCu#bHeFn8YCgg`cW=aiz(T7l}sDT)M zAaRY)^=Z^`%6o!auU^2%QbkFfzQ|uO-h1fmns!oelOvJ(msS6QFRH5PdlFpX3E>CA zo`}6>w0{kI>aISH0p#0%(u`!53JyeP-Lf&$mi{mQ?y9jz?4gX<^soE+D!iwSFddd5 z`6w%xMX5y_Z6a_nx$bLqyR%E}WHccD&$xplX1kd$VS2=0nS3S7u&JBI_mZDwouJ|*rvEMP- zeos&G8;}hT2HRn%U%O(EW}YzZki|)CNpP-&4PT9w`_h{Ve_2)f+H2scr8evtCwWU4 z>&R7S@c~))MP)9Ueo(fit-O2mL2u=6<*T`kUzm-b`g(z%mgQSm8}-QFW0KJWi~|KGpg$)ok&wf53#+a)MB;zL%EF!GFu zy0H+_0&k%QK0zn^fHwFE#q1aCfNm=x&9EEVVF)_lAZ&nRP`nd?WeZ7@1U`Du7{zM= zxB$f>9M;1k?1blV20p-cIDpqhe-esw28u{P8fKJ54OWB6C$Ql(rqT`W{t zwWdWH#WaulZU2c~?CAW2B`o`rH(-EqXh&)G0 zR8!Mb(ItihpC0N8E>UeUr7{vz)Oku`RLN*5JxAg{?J1m6EGaRXl@yifl?HFff-ds0IW\n" "Language-Team: Russian \n" @@ -21,23 +21,25 @@ msgstr "" #: ../source/contribute.rst:5 msgid "Contribute to this guide" -msgstr "" +msgstr "Внесение своего вклада в это руководство" #: ../source/contribute.rst:7 msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" msgstr "" +"|PyPUG| приветствует участников! Существует множество способов нам помочь, в " +"том числе:" #: ../source/contribute.rst:10 msgid "Reading the guide and giving feedback" -msgstr "" +msgstr "Чтение руководства и предоставление обратной связи" #: ../source/contribute.rst:11 msgid "Reviewing new contributions" -msgstr "" +msgstr "Проверка новых вкладов" #: ../source/contribute.rst:12 msgid "Revising existing content" -msgstr "" +msgstr "Пересмотр существующего материала" #: ../source/contribute.rst:13 msgid "Writing new content" @@ -53,7 +55,7 @@ msgstr "" #: ../source/contribute.rst:31 msgid "Documentation types" -msgstr "" +msgstr "Типы документации" #: ../source/contribute.rst:33 msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." @@ -62,7 +64,7 @@ msgstr "" #: ../source/contribute.rst:38 #: ../source/tutorials/index.rst:2 msgid "Tutorials" -msgstr "" +msgstr "Учебники" #: ../source/contribute.rst:40 msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." @@ -71,7 +73,7 @@ msgstr "" #: ../source/contribute.rst:47 #: ../source/guides/index.rst:2 msgid "Guides" -msgstr "" +msgstr "Руководства" #: ../source/contribute.rst:49 msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." @@ -80,7 +82,7 @@ msgstr "" #: ../source/contribute.rst:56 #: ../source/discussions/index.rst:2 msgid "Discussions" -msgstr "" +msgstr "Обсуждения" #: ../source/contribute.rst:58 msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." @@ -88,7 +90,7 @@ msgstr "" #: ../source/contribute.rst:63 msgid "Specifications" -msgstr "" +msgstr "Спецификации" #: ../source/contribute.rst:65 msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." @@ -113,6 +115,8 @@ msgstr "" #: ../source/contribute.rst:91 msgid "To build the guide, run the following bash command in the source folder::" msgstr "" +"Для сборки руководства выполните в каталоге с исходными файлами следующую " +"bash-команду::" #: ../source/contribute.rst:95 msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." @@ -125,6 +129,7 @@ msgstr "" #: ../source/contribute.rst:105 msgid "The guide will be browsable via http://localhost:8000." msgstr "" +"Руководство будет доступно для просмотра по адресу http://localhost:8000." #: ../source/contribute.rst:109 msgid "Where the guide is deployed" @@ -144,7 +149,7 @@ msgstr "" #: ../source/contribute.rst:126 msgid "Purpose" -msgstr "" +msgstr "Цель" #: ../source/contribute.rst:128 msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." @@ -164,7 +169,7 @@ msgstr "" #: ../source/contribute.rst:146 msgid "Audience" -msgstr "" +msgstr "Аудитория" #: ../source/contribute.rst:148 msgid "The audience of this guide is anyone who uses Python with packages." @@ -180,7 +185,7 @@ msgstr "" #: ../source/contribute.rst:160 msgid "Voice and tone" -msgstr "" +msgstr "Голос и тон" #: ../source/contribute.rst:162 msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." @@ -200,27 +205,29 @@ msgstr "" #: ../source/contribute.rst:184 msgid "Conventions and mechanics" -msgstr "" +msgstr "Соглашения и механики" #: ../source/contribute.rst:192 msgid "**Write to the reader**" -msgstr "" +msgstr "**Пишите читателю**" #: ../source/contribute.rst:187 msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." msgstr "" +"Давая рекомендации или расписывая шаги, обращайтесь к читателю на *вы* или " +"используйте повелительное наклонение." #: ../source/contribute.rst:0 msgid "Wrong: To install it, the user runs…" -msgstr "" +msgstr "Неправильно: Чтобы установить его, пользователь запускает…" #: ../source/contribute.rst:0 msgid "Right: You can install it by running…" -msgstr "" +msgstr "Правильно: Вы можете установить его, запустив…" #: ../source/contribute.rst:0 msgid "Right: To install it, run…" -msgstr "" +msgstr "Правильно: Чтобы установить его, запустите…" #: ../source/contribute.rst:198 msgid "**State assumptions**" @@ -240,31 +247,33 @@ msgstr "" #: ../source/contribute.rst:213 msgid "**Respect naming practices**" -msgstr "" +msgstr "**Следуйте правилам именования**" #: ../source/contribute.rst:206 msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." msgstr "" +"При указании названий инструментов, сайтов, имён людей и других собственных " +"существительных используйте их предпочтительную капитализацию." #: ../source/contribute.rst:0 msgid "Wrong: Pip uses…" -msgstr "" +msgstr "Неправильно: Pip использует…" #: ../source/contribute.rst:0 msgid "Right: pip uses…" -msgstr "" +msgstr "Правильно: pip использует…" #: ../source/contribute.rst:0 msgid "Wrong: …hosted on github." -msgstr "" +msgstr "Неправильно: …размещён на github." #: ../source/contribute.rst:0 msgid "Right: …hosted on GitHub." -msgstr "" +msgstr "Правильно: …размещён на GitHub." #: ../source/contribute.rst:222 msgid "**Use a gender-neutral style**" -msgstr "" +msgstr "**Используйте гендерно-нейтральный стиль**" #: ../source/contribute.rst:216 msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." @@ -284,7 +293,7 @@ msgstr "" #: ../source/contribute.rst:234 msgid "**Headings**" -msgstr "" +msgstr "**Заголовки**" #: ../source/contribute.rst:225 msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." @@ -296,15 +305,15 @@ msgstr "" #: ../source/contribute.rst:0 msgid "Wrong: Things You Should Know About Python" -msgstr "" +msgstr "Неправильно: Всё, Что Вам Нужно Знать О Python'е" #: ../source/contribute.rst:0 msgid "Right: Things you should know about Python" -msgstr "" +msgstr "Правильно: Всё, что вам нужно знать о Python'е" #: ../source/contribute.rst:237 msgid "**Numbers**" -msgstr "" +msgstr "**Числа**" #: ../source/contribute.rst:237 msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." @@ -312,7 +321,7 @@ msgstr "" #: ../source/discussions/deploying-python-applications.rst:4 msgid "Deploying Python applications" -msgstr "" +msgstr "Развёртывание приложений на Python'е" #: ../source/discussions/deploying-python-applications.rst:0 #: ../source/guides/index-mirrors-and-caches.rst:0 @@ -321,7 +330,7 @@ msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:0 #: ../source/guides/supporting-windows-using-appveyor.rst:0 msgid "Page Status" -msgstr "" +msgstr "Статус страницы" #: ../source/discussions/deploying-python-applications.rst:6 #: ../source/guides/index-mirrors-and-caches.rst:7 @@ -330,7 +339,7 @@ msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:7 #: ../source/guides/supporting-windows-using-appveyor.rst:5 msgid "Incomplete" -msgstr "" +msgstr "Не завершена" #: ../source/discussions/deploying-python-applications.rst:0 #: ../source/guides/index-mirrors-and-caches.rst:0 @@ -339,11 +348,11 @@ msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:0 #: ../source/guides/supporting-windows-using-appveyor.rst:0 msgid "Last Reviewed" -msgstr "" +msgstr "Последняя проверка" #: ../source/discussions/deploying-python-applications.rst:7 msgid "2014-11-11" -msgstr "" +msgstr "2014-11-11" #: ../source/discussions/deploying-python-applications.rst:11 #: ../source/discussions/install-requires-vs-requirements.rst:9 @@ -363,11 +372,11 @@ msgstr "" #: ../source/discussions/deploying-python-applications.rst:14 msgid "Overview" -msgstr "" +msgstr "Обзор" #: ../source/discussions/deploying-python-applications.rst:18 msgid "Supporting multiple hardware platforms" -msgstr "" +msgstr "Поддержка нескольких аппаратных платформ" #: ../source/discussions/deploying-python-applications.rst:40 msgid "OS packaging & installers" @@ -375,11 +384,11 @@ msgstr "" #: ../source/discussions/deploying-python-applications.rst:52 msgid "Windows" -msgstr "" +msgstr "Windows" #: ../source/discussions/deploying-python-applications.rst:61 msgid "Pynsist" -msgstr "" +msgstr "Pynsist" #: ../source/discussions/deploying-python-applications.rst:63 msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." @@ -395,11 +404,11 @@ msgstr "" #: ../source/discussions/deploying-python-applications.rst:80 msgid "Application bundles" -msgstr "" +msgstr "Комплекты приложений" #: ../source/discussions/deploying-python-applications.rst:91 msgid "Configuration management" -msgstr "" +msgstr "Управление конфигурацией" #: ../source/discussions/index.rst:4 msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." @@ -407,12 +416,12 @@ msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:5 msgid "install_requires vs requirements files" -msgstr "" +msgstr "Файл :file:`install_requires` против файла :file:`requirements`" #: ../source/discussions/install-requires-vs-requirements.rst:12 #: ../source/guides/distributing-packages-using-setuptools.rst:382 msgid "install_requires" -msgstr "" +msgstr "install_requires" #: ../source/discussions/install-requires-vs-requirements.rst:14 msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." @@ -445,7 +454,7 @@ msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:64 #: ../source/tutorials/installing-packages.rst:460 msgid "Requirements files" -msgstr "" +msgstr "Файлы требований" #: ../source/discussions/install-requires-vs-requirements.rst:66 msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." @@ -473,7 +482,7 @@ msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:6 msgid "pip vs easy_install" -msgstr "" +msgstr "``pip`` против ``easy_install``" #: ../source/discussions/pip-vs-easy-install.rst:9 msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." @@ -489,15 +498,15 @@ msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:25 msgid "**pip**" -msgstr "" +msgstr "**pip**" #: ../source/discussions/pip-vs-easy-install.rst:25 msgid "**easy_install**" -msgstr "" +msgstr "**easy_install**" #: ../source/discussions/pip-vs-easy-install.rst:27 msgid "Installs from :term:`Wheels `" -msgstr "" +msgstr "Установка из :term:`колёс `" #: ../source/discussions/pip-vs-easy-install.rst:27 #: ../source/discussions/pip-vs-easy-install.rst:38 @@ -506,7 +515,7 @@ msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:54 #: ../source/discussions/pip-vs-easy-install.rst:57 msgid "Yes" -msgstr "" +msgstr "Да" #: ../source/discussions/pip-vs-easy-install.rst:27 #: ../source/discussions/pip-vs-easy-install.rst:30 @@ -523,7 +532,7 @@ msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:30 msgid "Uninstall Packages" -msgstr "" +msgstr "Удаление пакетов" #: ../source/discussions/pip-vs-easy-install.rst:30 msgid "Yes (``python -m pip uninstall``)" @@ -531,15 +540,15 @@ msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:32 msgid "Dependency Overrides" -msgstr "" +msgstr "Переопределение зависимостей" #: ../source/discussions/pip-vs-easy-install.rst:32 msgid "Yes (:ref:`Requirements Files `)" -msgstr "" +msgstr "Да (:ref:`Файлы требований `)" #: ../source/discussions/pip-vs-easy-install.rst:35 msgid "List Installed Packages" -msgstr "" +msgstr "Перечисление установленных пакетов" #: ../source/discussions/pip-vs-easy-install.rst:35 msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" @@ -547,11 +556,11 @@ msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:38 msgid ":pep:`438` Support" -msgstr "" +msgstr "Поддержка :pep:`438`" #: ../source/discussions/pip-vs-easy-install.rst:41 msgid "Installation format" -msgstr "" +msgstr "Формат установки" #: ../source/discussions/pip-vs-easy-install.rst:41 msgid "'Flat' packages with :file:`egg-info` metadata." @@ -559,51 +568,53 @@ msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:41 msgid "Encapsulated Egg format" -msgstr "" +msgstr "Формат инкапсулированного яйца" #: ../source/discussions/pip-vs-easy-install.rst:44 msgid "sys.path modification" -msgstr "" +msgstr "Изменение ``sys.path``" #: ../source/discussions/pip-vs-easy-install.rst:48 msgid "Installs from :term:`Eggs `" -msgstr "" +msgstr "Установка из :term:`яиц `" #: ../source/discussions/pip-vs-easy-install.rst:51 msgid "`pylauncher support`_" -msgstr "" +msgstr "`Поддержка pylauncher`_" #: ../source/discussions/pip-vs-easy-install.rst:51 msgid "Yes [1]_" -msgstr "" +msgstr "Да [1]_" #: ../source/discussions/pip-vs-easy-install.rst:54 msgid ":ref:`Multi-version Installs`" -msgstr "" +msgstr ":ref:`Много-версионные установки `" #: ../source/discussions/pip-vs-easy-install.rst:57 msgid "Exclude scripts during install" -msgstr "" +msgstr "Исключение скриптов во время установки" #: ../source/discussions/pip-vs-easy-install.rst:60 msgid "per project index" -msgstr "" +msgstr "Индекс по проектам" #: ../source/discussions/pip-vs-easy-install.rst:60 msgid "Only in virtualenv" -msgstr "" +msgstr "Только в ``virtualenv``" #: ../source/discussions/pip-vs-easy-install.rst:60 msgid "Yes, via setup.cfg" -msgstr "" +msgstr "Да, через :file:`setup.cfg`" #: ../source/discussions/pip-vs-easy-install.rst:68 msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" msgstr "" +"https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" +"launcher" #: ../source/discussions/wheel-vs-egg.rst:5 msgid "Wheel vs Egg" -msgstr "" +msgstr "Колеса против яиц" #: ../source/discussions/wheel-vs-egg.rst:7 msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." @@ -655,7 +666,7 @@ msgstr "" #: ../source/glossary.rst:3 msgid "Glossary" -msgstr "" +msgstr "Словарь терминов" #: ../source/glossary.rst:8 msgid "Binary Distribution" @@ -703,7 +714,7 @@ msgstr "" #: ../source/glossary.rst:59 msgid "Known Good Set (KGS)" -msgstr "" +msgstr "Known Good Set (KGS, Известный хороший набор)" #: ../source/glossary.rst:62 msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." @@ -711,7 +722,7 @@ msgstr "" #: ../source/glossary.rst:68 msgid "Import Package" -msgstr "" +msgstr "Import Package (Импортируемый пакет)" #: ../source/glossary.rst:71 msgid "A Python module which can contain other modules or recursively, other packages." @@ -723,7 +734,7 @@ msgstr "" #: ../source/glossary.rst:78 msgid "Module" -msgstr "" +msgstr "Модуль" #: ../source/glossary.rst:81 msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." @@ -747,7 +758,7 @@ msgstr "" #: ../source/glossary.rst:97 msgid "Project" -msgstr "" +msgstr "Проект" #: ../source/glossary.rst:100 msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." @@ -791,7 +802,7 @@ msgstr "" #: ../source/glossary.rst:145 msgid "pypi.org" -msgstr "" +msgstr "pypi.org" #: ../source/glossary.rst:148 msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." @@ -807,7 +818,7 @@ msgstr "" #: ../source/glossary.rst:157 msgid "Release" -msgstr "" +msgstr "Выпуск" #: ../source/glossary.rst:160 msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." @@ -819,7 +830,7 @@ msgstr "" #: ../source/glossary.rst:168 msgid "Requirement" -msgstr "" +msgstr "Требование" #: ../source/glossary.rst:171 msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." @@ -844,12 +855,12 @@ msgstr "" #: ../source/glossary.rst:194 #: ../source/guides/distributing-packages-using-setuptools.rst:56 msgid "setup.py" -msgstr "" +msgstr "setup.py" #: ../source/glossary.rst:195 #: ../source/guides/distributing-packages-using-setuptools.rst:77 msgid "setup.cfg" -msgstr "" +msgstr "setup.cfg" #: ../source/glossary.rst:198 msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." @@ -913,7 +924,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:3 msgid "Analyzing PyPI package downloads" -msgstr "" +msgstr "Анализ загрузок пакетов с PyPI" #: ../source/guides/analyzing-pypi-package-downloads.rst:5 msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." @@ -922,7 +933,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:15 #: ../source/guides/supporting-windows-using-appveyor.rst:18 msgid "Background" -msgstr "" +msgstr "Фон" #: ../source/guides/analyzing-pypi-package-downloads.rst:17 msgid "PyPI does not display download statistics for a number of reasons: [#]_" @@ -946,7 +957,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:29 msgid "Packages not hosted on PyPI (for comparisons sake)" -msgstr "" +msgstr "Пакеты, размещённые не на PyPI (для сравнения);" #: ../source/guides/analyzing-pypi-package-downloads.rst:30 msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" @@ -986,7 +997,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:59 msgid "Create a new project." -msgstr "" +msgstr "Создайте новый проект." #: ../source/guides/analyzing-pypi-package-downloads.rst:60 msgid "Enable the `BigQuery API `__." @@ -1006,18 +1017,18 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 msgid "Column" -msgstr "" +msgstr "Колонка" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 #: ../source/guides/using-manifest-in.rst:67 #: ../source/specifications/core-metadata.rst:185 msgid "Description" -msgstr "" +msgstr "Описание" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 #: ../source/specifications/direct-url.rst:226 msgid "Examples" -msgstr "" +msgstr "Примеры" #: ../source/guides/analyzing-pypi-package-downloads.rst:80 msgid "timestamp" @@ -1041,7 +1052,7 @@ msgstr "Название проекта" #: ../source/guides/analyzing-pypi-package-downloads.rst:82 msgid "``pipenv``, ``nose``" -msgstr "" +msgstr "``pipenv``, ``nose``" #: ../source/guides/analyzing-pypi-package-downloads.rst:84 msgid "file.version" @@ -1049,11 +1060,11 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:84 msgid "Package version" -msgstr "" +msgstr "Версия пакета" #: ../source/guides/analyzing-pypi-package-downloads.rst:84 msgid "``0.1.6``, ``1.4.2``" -msgstr "" +msgstr "``0.1.6``, ``1.4.2``" #: ../source/guides/analyzing-pypi-package-downloads.rst:86 msgid "details.installer.name" @@ -1061,7 +1072,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:86 msgid "Installer" -msgstr "" +msgstr "Установщик" #: ../source/guides/analyzing-pypi-package-downloads.rst:86 msgid "pip, `bandersnatch`_" @@ -1081,7 +1092,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:93 msgid "Useful queries" -msgstr "" +msgstr "Полезные запросы" #: ../source/guides/analyzing-pypi-package-downloads.rst:95 msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." @@ -1093,7 +1104,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:102 msgid "Counting package downloads" -msgstr "" +msgstr "Подсчёт количества загрузок пакетов" #: ../source/guides/analyzing-pypi-package-downloads.rst:104 msgid "The following query counts the total number of downloads for the project \"pytest\"." @@ -1120,7 +1131,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:146 msgid "Package downloads over time" -msgstr "" +msgstr "Загрузки пакетов с течением времени" #: ../source/guides/analyzing-pypi-package-downloads.rst:148 msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." @@ -1132,7 +1143,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:170 msgid "1956741" -msgstr "" +msgstr "1956741" #: ../source/guides/analyzing-pypi-package-downloads.rst:170 msgid "2018-01-01" @@ -1140,7 +1151,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:172 msgid "2344692" -msgstr "" +msgstr "2344692" #: ../source/guides/analyzing-pypi-package-downloads.rst:172 msgid "2017-12-01" @@ -1148,7 +1159,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:174 msgid "1730398" -msgstr "" +msgstr "1730398" #: ../source/guides/analyzing-pypi-package-downloads.rst:174 msgid "2017-11-01" @@ -1156,7 +1167,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:176 msgid "2047310" -msgstr "" +msgstr "2047310" #: ../source/guides/analyzing-pypi-package-downloads.rst:176 msgid "2017-10-01" @@ -1164,7 +1175,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:178 msgid "1744443" -msgstr "" +msgstr "1744443" #: ../source/guides/analyzing-pypi-package-downloads.rst:178 msgid "2017-09-01" @@ -1172,7 +1183,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:180 msgid "1916952" -msgstr "" +msgstr "1916952" #: ../source/guides/analyzing-pypi-package-downloads.rst:180 msgid "2017-08-01" @@ -1188,7 +1199,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:205 msgid "python" -msgstr "" +msgstr "python" #: ../source/guides/analyzing-pypi-package-downloads.rst:207 msgid "3.7" @@ -1248,7 +1259,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:231 msgid "Additional tools" -msgstr "" +msgstr "Дополнительные инструменты" #: ../source/guides/analyzing-pypi-package-downloads.rst:233 msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." @@ -1272,7 +1283,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:273 msgid "Install `pypinfo`_ using pip." -msgstr "" +msgstr "Установите `pypinfo`_ через :program:`pip`." #: ../source/guides/analyzing-pypi-package-downloads.rst:279 msgid "Usage:" @@ -1301,7 +1312,7 @@ msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:3 msgid "Creating and discovering plugins" -msgstr "" +msgstr "Создание и обнаружение плагинов" #: ../source/guides/creating-and-discovering-plugins.rst:5 msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." @@ -1313,19 +1324,19 @@ msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:12 msgid "`Using naming convention`_." -msgstr "" +msgstr "`Использование соглашения об именах`_." #: ../source/guides/creating-and-discovering-plugins.rst:13 msgid "`Using namespace packages`_." -msgstr "" +msgstr "`Использование пакетов пространства имён`_." #: ../source/guides/creating-and-discovering-plugins.rst:14 msgid "`Using package metadata`_." -msgstr "" +msgstr "`Использование метаданных пакета`_." #: ../source/guides/creating-and-discovering-plugins.rst:18 msgid "Using naming convention" -msgstr "" +msgstr "Использование соглашения об именах" #: ../source/guides/creating-and-discovering-plugins.rst:20 msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" @@ -1341,7 +1352,7 @@ msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:59 msgid "Using namespace packages" -msgstr "" +msgstr "Использование пакетов пространства имён" #: ../source/guides/creating-and-discovering-plugins.rst:61 msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" @@ -1361,7 +1372,7 @@ msgstr "" #: ../source/guides/creating-and-discovering-plugins.rst:121 msgid "Using package metadata" -msgstr "" +msgstr "Использование метаданных пакета" #: ../source/guides/creating-and-discovering-plugins.rst:123 msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." @@ -1393,7 +1404,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:5 msgid "Packaging and distributing projects" -msgstr "" +msgstr "Упаковка и распространение проектов" #: ../source/guides/distributing-packages-using-setuptools.rst:7 msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." @@ -1409,15 +1420,17 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:25 msgid "Requirements for packaging and distributing" -msgstr "" +msgstr "Требования к упаковке и распространению" #: ../source/guides/distributing-packages-using-setuptools.rst:26 msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." msgstr "" +"Во-первых, убедитесь, что вы уже выполнили :ref:`требования к установке " +"пакетов `." #: ../source/guides/distributing-packages-using-setuptools.rst:29 msgid "Install \"twine\" [1]_:" -msgstr "" +msgstr "Установите «twine» [1]_:" #: ../source/guides/distributing-packages-using-setuptools.rst:43 msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." @@ -1425,11 +1438,11 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:49 msgid "Configuring your project" -msgstr "" +msgstr "Настройка вашего проекта" #: ../source/guides/distributing-packages-using-setuptools.rst:53 msgid "Initial files" -msgstr "" +msgstr "Исходные файлы" #: ../source/guides/distributing-packages-using-setuptools.rst:58 msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." @@ -1437,7 +1450,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:63 msgid ":file:`setup.py` serves two primary functions:" -msgstr "" +msgstr "Файл :file:`setup.py` выполняет две основные функции:" #: ../source/guides/distributing-packages-using-setuptools.rst:65 msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." @@ -1453,7 +1466,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:86 msgid "README.rst / README.md" -msgstr "" +msgstr "README.rst / README.md" #: ../source/guides/distributing-packages-using-setuptools.rst:88 msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." @@ -1469,7 +1482,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:108 msgid "MANIFEST.in" -msgstr "" +msgstr "MANIFEST.in" #: ../source/guides/distributing-packages-using-setuptools.rst:110 msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." @@ -1485,7 +1498,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:122 msgid "LICENSE.txt" -msgstr "" +msgstr "LICENSE.txt" #: ../source/guides/distributing-packages-using-setuptools.rst:124 msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." @@ -1497,7 +1510,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:135 msgid "" -msgstr "" +msgstr "<ваш пакет>" #: ../source/guides/distributing-packages-using-setuptools.rst:137 msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." @@ -1509,7 +1522,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:149 msgid "setup() args" -msgstr "" +msgstr "Аргументы ``setup()``" #: ../source/guides/distributing-packages-using-setuptools.rst:151 msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." @@ -1662,7 +1675,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:398 msgid "python_requires" -msgstr "" +msgstr "python_requires" #: ../source/guides/distributing-packages-using-setuptools.rst:400 msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" @@ -1674,7 +1687,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:412 msgid "And so on." -msgstr "" +msgstr "И так далее." #: ../source/guides/distributing-packages-using-setuptools.rst:416 msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." @@ -1686,7 +1699,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:431 msgid "package_data" -msgstr "" +msgstr "package_data" #: ../source/guides/distributing-packages-using-setuptools.rst:440 msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." @@ -1702,7 +1715,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:457 msgid "data_files" -msgstr "" +msgstr "data_files" #: ../source/guides/distributing-packages-using-setuptools.rst:463 msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." @@ -1722,7 +1735,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:491 msgid "scripts" -msgstr "" +msgstr "scripts" #: ../source/guides/distributing-packages-using-setuptools.rst:493 msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." @@ -1730,7 +1743,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:500 msgid "entry_points" -msgstr "" +msgstr "entry_points" #: ../source/guides/distributing-packages-using-setuptools.rst:509 msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." @@ -1746,7 +1759,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:521 msgid "console_scripts" -msgstr "" +msgstr "console_scripts" #: ../source/guides/distributing-packages-using-setuptools.rst:531 msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." @@ -1758,11 +1771,11 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:545 msgid "Choosing a versioning scheme" -msgstr "" +msgstr "Выбор схемы управления версиями" #: ../source/guides/distributing-packages-using-setuptools.rst:548 msgid "Standards compliance for interoperability" -msgstr "" +msgstr "Соответствие стандартам совместимости" #: ../source/guides/distributing-packages-using-setuptools.rst:550 msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." @@ -1770,7 +1783,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:556 msgid "Here are some examples of compliant version numbers::" -msgstr "" +msgstr "Вот несколько примеров совместимых номеров версий::" #: ../source/guides/distributing-packages-using-setuptools.rst:567 msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." @@ -1778,11 +1791,11 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:573 msgid "Scheme choices" -msgstr "" +msgstr "Выбор схемы" #: ../source/guides/distributing-packages-using-setuptools.rst:576 msgid "Semantic versioning (preferred)" -msgstr "" +msgstr "Семантическое версионирование (предпочитаемый вариант)" #: ../source/guides/distributing-packages-using-setuptools.rst:578 msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." @@ -1814,7 +1827,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:598 msgid "Date based versioning" -msgstr "" +msgstr "Версионирование на основе дат" #: ../source/guides/distributing-packages-using-setuptools.rst:600 msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." @@ -1830,7 +1843,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:611 msgid "Serial versioning" -msgstr "" +msgstr "Последовательное версионирование" #: ../source/guides/distributing-packages-using-setuptools.rst:613 msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." @@ -1842,7 +1855,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:621 msgid "Hybrid schemes" -msgstr "" +msgstr "Гибридные схемы" #: ../source/guides/distributing-packages-using-setuptools.rst:623 msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." @@ -1850,7 +1863,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:629 msgid "Pre-release versioning" -msgstr "" +msgstr "Версионирование предварительных выпусков" #: ../source/guides/distributing-packages-using-setuptools.rst:631 msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" @@ -1878,7 +1891,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:644 msgid "Local version identifiers" -msgstr "" +msgstr "Идентификаторы локальных версий" #: ../source/guides/distributing-packages-using-setuptools.rst:646 msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." @@ -1890,7 +1903,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:661 msgid "Working in \"development mode\"" -msgstr "" +msgstr "Работа в «режиме разработки»" #: ../source/guides/distributing-packages-using-setuptools.rst:663 msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." @@ -1930,7 +1943,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:713 msgid "Packaging your project" -msgstr "" +msgstr "Упаковка вашего проекта" #: ../source/guides/distributing-packages-using-setuptools.rst:715 msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." @@ -1942,7 +1955,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:737 msgid "Source distributions" -msgstr "" +msgstr "Распространение в исходных кодах" #: ../source/guides/distributing-packages-using-setuptools.rst:739 msgid "Minimally, you should create a :term:`Source Distribution `:" @@ -1954,7 +1967,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:763 msgid "Wheels" -msgstr "" +msgstr "Колёса" #: ../source/guides/distributing-packages-using-setuptools.rst:765 msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." @@ -1978,7 +1991,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:792 msgid "Pure Python Wheels" -msgstr "" +msgstr "Колёса чистого Python'а" #: ../source/guides/distributing-packages-using-setuptools.rst:794 msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." @@ -1987,7 +2000,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:797 #: ../source/guides/distributing-packages-using-setuptools.rst:826 msgid "To build the wheel:" -msgstr "" +msgstr "Для построения колеса выполните:" #: ../source/guides/distributing-packages-using-setuptools.rst:811 msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." @@ -1999,7 +2012,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:821 msgid "Platform Wheels" -msgstr "" +msgstr "Платформо-зависимые колёса" #: ../source/guides/distributing-packages-using-setuptools.rst:823 msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." @@ -2015,7 +2028,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:855 msgid "Uploading your Project to PyPI" -msgstr "" +msgstr "Загрузка вашего проекта на PyPI" #: ../source/guides/distributing-packages-using-setuptools.rst:857 msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." @@ -2074,7 +2087,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:921 msgid "Upload your distributions" -msgstr "" +msgstr "Загрузите свои дистрибутивы" #: ../source/guides/distributing-packages-using-setuptools.rst:923 msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." @@ -2103,7 +2116,7 @@ msgstr "" #: ../source/guides/dropping-older-python-versions.rst:5 msgid "Dropping support for older Python versions" -msgstr "" +msgstr "Удаление поддержки старых версий Python'а" #: ../source/guides/dropping-older-python-versions.rst:7 msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." @@ -2123,23 +2136,25 @@ msgstr "" #: ../source/guides/dropping-older-python-versions.rst:17 msgid "Requirements" -msgstr "" +msgstr "Требования" #: ../source/guides/dropping-older-python-versions.rst:19 msgid "This workflow requires that:" -msgstr "" +msgstr "Этот рабочий процесс требует, чтобы:" #: ../source/guides/dropping-older-python-versions.rst:21 msgid "The publisher is using the latest version of :ref:`setuptools`," -msgstr "" +msgstr "Издатель использовал последнюю версию :ref:`setuptools`," #: ../source/guides/dropping-older-python-versions.rst:22 msgid "The latest version of :ref:`twine` is used to upload the package," -msgstr "" +msgstr "Для загрузки пакета использовалась последняя версия :ref:`twine`," #: ../source/guides/dropping-older-python-versions.rst:23 msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." msgstr "" +"У пользователя, устанавливающего пакет, был установлен хотя бы Pip 9.0 или " +"клиент, поддерживающий спецификацию Metadata 1.2." #: ../source/guides/dropping-older-python-versions.rst:26 msgid "Dealing with the universal wheels" @@ -2159,15 +2174,17 @@ msgstr "" #: ../source/guides/dropping-older-python-versions.rst:53 msgid "Defining the Python version required" -msgstr "" +msgstr "Определение требуемой версии Python'а" #: ../source/guides/dropping-older-python-versions.rst:56 msgid "1. Download the newest version of Setuptools" -msgstr "" +msgstr "1. Скачайте новейшую версию Setuptools" #: ../source/guides/dropping-older-python-versions.rst:58 msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." msgstr "" +"Убедитесь, что перед созданием дистрибутивов исходных кодов или двоичных " +"дистрибутивов вы обновили Setuptools и установили twine." #: ../source/guides/dropping-older-python-versions.rst:60 msgid "Steps:" @@ -2175,11 +2192,11 @@ msgstr "" #: ../source/guides/dropping-older-python-versions.rst:74 msgid "`setuptools` version should be above 24.0.0." -msgstr "" +msgstr "Версия `setuptools` должна быть выше 24.0.0." #: ../source/guides/dropping-older-python-versions.rst:77 msgid "2. Specify the version ranges for supported Python distributions" -msgstr "" +msgstr "2. Укажите диапазоны версий поддерживаемых дистрибутивов Python'а" #: ../source/guides/dropping-older-python-versions.rst:79 msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." @@ -2195,7 +2212,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:693 #: ../source/specifications/core-metadata.rst:722 msgid "Examples::" -msgstr "" +msgstr "Примеры::" #: ../source/guides/dropping-older-python-versions.rst:86 msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." @@ -2203,7 +2220,7 @@ msgstr "" #: ../source/guides/dropping-older-python-versions.rst:101 msgid "3. Validating the Metadata before publishing" -msgstr "" +msgstr "3. Перед публикацией проверьте метаданные" #: ../source/guides/dropping-older-python-versions.rst:103 msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." @@ -2231,7 +2248,7 @@ msgstr "" #: ../source/guides/dropping-older-python-versions.rst:118 msgid "4. Using Twine to publish" -msgstr "" +msgstr "4. Используйте Twine для публикации" #: ../source/guides/dropping-older-python-versions.rst:120 msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." @@ -2243,7 +2260,7 @@ msgstr "" #: ../source/guides/dropping-older-python-versions.rst:125 msgid "Dropping a Python release" -msgstr "" +msgstr "Удаление выпуска Python'а" #: ../source/guides/dropping-older-python-versions.rst:127 msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." @@ -2319,7 +2336,7 @@ msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:8 #: ../source/guides/supporting-multiple-python-versions.rst:8 msgid "2014-12-24" -msgstr "" +msgstr "2014-12-24" #: ../source/guides/index-mirrors-and-caches.rst:14 msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." @@ -2379,7 +2396,7 @@ msgstr "" #: ../source/guides/installing-scientific-packages.rst:5 msgid "Installing scientific packages" -msgstr "" +msgstr "Установка научных пакетов" #: ../source/guides/installing-scientific-packages.rst:11 msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." @@ -2407,7 +2424,7 @@ msgstr "" #: ../source/guides/installing-scientific-packages.rst:45 msgid "Linux distribution packages" -msgstr "" +msgstr "Распространяемые пакеты Linux" #: ../source/guides/installing-scientific-packages.rst:47 msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." @@ -2419,7 +2436,7 @@ msgstr "" #: ../source/guides/installing-scientific-packages.rst:57 msgid "Windows installers" -msgstr "" +msgstr "Установщики Windows" #: ../source/guides/installing-scientific-packages.rst:59 msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." @@ -2455,7 +2472,7 @@ msgstr "" #: ../source/guides/installing-scientific-packages.rst:99 msgid "SciPy distributions" -msgstr "" +msgstr "Дистрибутивы SciPy" #: ../source/guides/installing-scientific-packages.rst:101 msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." @@ -2468,7 +2485,7 @@ msgstr "" #: ../source/guides/installing-scientific-packages.rst:109 #: ../source/key_projects.rst:596 msgid "Spack" -msgstr "" +msgstr "Spack" #: ../source/guides/installing-scientific-packages.rst:110 msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." @@ -2480,7 +2497,7 @@ msgstr "" #: ../source/guides/installing-scientific-packages.rst:128 msgid "The conda cross-platform package manager" -msgstr "" +msgstr "Кроссплатформенный менеджер пакетов conda" #: ../source/guides/installing-scientific-packages.rst:130 msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." @@ -2553,11 +2570,11 @@ msgstr "" #: ../source/guides/installing-using-linux-tools.rst:5 msgid "Installing pip/setuptools/wheel with Linux Package Managers" -msgstr "" +msgstr "Установка pip/setuptools/wheel через менеджеры пакетов Linux" #: ../source/guides/installing-using-linux-tools.rst:8 msgid "2015-09-17" -msgstr "" +msgstr "2015-09-17" #: ../source/guides/installing-using-linux-tools.rst:11 msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." @@ -2577,11 +2594,11 @@ msgstr "" #: ../source/guides/installing-using-linux-tools.rst:32 msgid "Fedora" -msgstr "" +msgstr "Fedora" #: ../source/guides/installing-using-linux-tools.rst:34 msgid "Fedora 21:" -msgstr "" +msgstr "Fedora 21:" #: ../source/guides/installing-using-linux-tools.rst:36 #: ../source/guides/installing-using-linux-tools.rst:45 @@ -2589,19 +2606,19 @@ msgstr "" #: ../source/guides/installing-using-linux-tools.rst:138 #: ../source/guides/installing-using-linux-tools.rst:158 msgid "Python 2::" -msgstr "" +msgstr "Python 2::" #: ../source/guides/installing-using-linux-tools.rst:41 msgid "Python 3: ``sudo yum install python3 python3-wheel``" -msgstr "" +msgstr "Python 3: ``sudo yum install python3 python3-wheel``" #: ../source/guides/installing-using-linux-tools.rst:43 msgid "Fedora 22:" -msgstr "" +msgstr "Fedora 22:" #: ../source/guides/installing-using-linux-tools.rst:50 msgid "Python 3: ``sudo dnf install python3 python3-wheel``" -msgstr "" +msgstr "Python 3: ``sudo dnf install python3 python3-wheel``" #: ../source/guides/installing-using-linux-tools.rst:53 msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" @@ -2609,7 +2626,7 @@ msgstr "" #: ../source/guides/installing-using-linux-tools.rst:63 msgid "CentOS/RHEL" -msgstr "" +msgstr "CentOS/RHEL" #: ../source/guides/installing-using-linux-tools.rst:65 msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." @@ -2637,7 +2654,7 @@ msgstr "" #: ../source/guides/installing-using-linux-tools.rst:92 msgid "To additionally upgrade setuptools, run::" -msgstr "" +msgstr "Чтобы дополнительно обновить setuptools, запустите::" #: ../source/guides/installing-using-linux-tools.rst:97 msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" @@ -2669,17 +2686,17 @@ msgstr "" #: ../source/guides/installing-using-linux-tools.rst:122 msgid "openSUSE" -msgstr "" +msgstr "openSUSE" #: ../source/guides/installing-using-linux-tools.rst:129 #: ../source/guides/installing-using-linux-tools.rst:143 #: ../source/guides/installing-using-linux-tools.rst:162 msgid "Python 3::" -msgstr "" +msgstr "Python 3::" #: ../source/guides/installing-using-linux-tools.rst:135 msgid "Debian/Ubuntu" -msgstr "" +msgstr "Debian/Ubuntu" #: ../source/guides/installing-using-linux-tools.rst:150 msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." @@ -2687,7 +2704,7 @@ msgstr "" #: ../source/guides/installing-using-linux-tools.rst:156 msgid "Arch Linux" -msgstr "" +msgstr "Arch Linux" #: ../source/guides/installing-using-linux-tools.rst:168 msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." @@ -2707,7 +2724,7 @@ msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 msgid "Installing pip" -msgstr "" +msgstr "Установка pip" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." @@ -2732,10 +2749,12 @@ msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 msgid "You can make sure that pip is up-to-date by running:" msgstr "" +"Вы можете убедиться, что pip обновлён до самой последней версии, запустив " +"следующую команду:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 msgid "Installing virtualenv" -msgstr "" +msgstr "Установка virtualenv" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." @@ -2811,7 +2830,7 @@ msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 msgid "Installing specific versions" -msgstr "" +msgstr "Установка определённых версий" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" @@ -2835,7 +2854,7 @@ msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 msgid "Installing from source" -msgstr "" +msgstr "Установка из исходных кодов" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 msgid "pip can install a package directly from source, for example:" @@ -2847,7 +2866,7 @@ msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 msgid "Installing from version control systems" -msgstr "" +msgstr "Установка из систем управления версиями" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" @@ -2860,7 +2879,7 @@ msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 #: ../source/tutorials/installing-packages.rst:569 msgid "Installing from local archives" -msgstr "" +msgstr "Установка из локальных архивов" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" @@ -2876,7 +2895,7 @@ msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 msgid "Using other package indexes" -msgstr "" +msgstr "Использование других индексов пакетов" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" @@ -2889,7 +2908,7 @@ msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 #: ../source/tutorials/installing-packages.rst:389 msgid "Upgrading packages" -msgstr "" +msgstr "Обновление пакетов" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" @@ -2897,7 +2916,7 @@ msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 msgid "Using requirements files" -msgstr "" +msgstr "Использование файлов требований" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" @@ -2909,7 +2928,7 @@ msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 msgid "Freezing dependencies" -msgstr "" +msgstr "Заморозка зависимостей" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" @@ -2925,7 +2944,7 @@ msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:2 msgid "Making a PyPI-friendly README" -msgstr "" +msgstr "Создание дружественного к PyPI файла README" #: ../source/guides/making-a-pypi-friendly-readme.rst:4 msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." @@ -2933,7 +2952,7 @@ msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:9 msgid "Creating a README file" -msgstr "" +msgstr "Создание файла :file:`README`" #: ../source/guides/making-a-pypi-friendly-readme.rst:11 msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." @@ -2945,7 +2964,7 @@ msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:16 msgid "plain text" -msgstr "" +msgstr "простой текст;" #: ../source/guides/making-a-pypi-friendly-readme.rst:17 msgid "`reStructuredText `_ (without Sphinx extensions)" @@ -2954,6 +2973,8 @@ msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:18 msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" msgstr "" +"текст в формате Markdown (`GitHub Flavored Markdown `_ по умолчанию или `CommonMark `_)." #: ../source/guides/making-a-pypi-friendly-readme.rst:21 msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." @@ -2961,7 +2982,7 @@ msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:25 msgid "Including your README in your package's metadata" -msgstr "" +msgstr "Включение файла README в метаданные вашего пакета" #: ../source/guides/making-a-pypi-friendly-readme.rst:27 msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." @@ -2969,11 +2990,11 @@ msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:33 msgid ":ref:`description-optional`" -msgstr "" +msgstr ":ref:`description-optional`" #: ../source/guides/making-a-pypi-friendly-readme.rst:34 msgid ":ref:`description-content-type-optional`" -msgstr "" +msgstr ":ref:`description-content-type-optional`" #: ../source/guides/making-a-pypi-friendly-readme.rst:36 msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." @@ -3045,7 +3066,7 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:4 msgid "Migrating to PyPI.org" -msgstr "" +msgstr "Переход на PyPI.org" #: ../source/guides/migrating-to-pypi-org.rst:6 msgid ":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``." @@ -3053,11 +3074,12 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:12 msgid "Publishing releases" -msgstr "" +msgstr "Публикация выпусков" #: ../source/guides/migrating-to-pypi-org.rst:14 msgid "``pypi.org`` is the default upload platform as of September 2016." msgstr "" +"С сентября 2016 года платформой загрузки по умолчанию является ``pypi.org``." #: ../source/guides/migrating-to-pypi-org.rst:16 msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." @@ -3113,7 +3135,7 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:73 msgid "Registering package names & metadata" -msgstr "" +msgstr "Регистрация имён и метаданных пакетов" #: ../source/guides/migrating-to-pypi-org.rst:75 msgid "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." @@ -3130,7 +3152,7 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:89 #: ../source/guides/using-testpypi.rst:5 msgid "Using TestPyPI" -msgstr "" +msgstr "Использование TestPyPI" #: ../source/guides/migrating-to-pypi-org.rst:91 msgid "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:" @@ -3138,7 +3160,7 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:113 msgid "Registering new user accounts" -msgstr "" +msgstr "Регистрация новых учётных записей пользователей" #: ../source/guides/migrating-to-pypi-org.rst:115 msgid "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." @@ -3146,7 +3168,7 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:121 msgid "Browsing packages" -msgstr "" +msgstr "Просмотр пакетов" #: ../source/guides/migrating-to-pypi-org.rst:123 msgid "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." @@ -3154,7 +3176,7 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:130 msgid "Downloading packages" -msgstr "" +msgstr "Загрузка пакетов" #: ../source/guides/migrating-to-pypi-org.rst:132 msgid "``pypi.org`` is the default host for downloading packages." @@ -3162,7 +3184,7 @@ msgstr "" #: ../source/guides/migrating-to-pypi-org.rst:135 msgid "Managing published packages and releases" -msgstr "" +msgstr "Управление опубликованными пакетами и выпусками" #: ../source/guides/migrating-to-pypi-org.rst:137 msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." @@ -3170,7 +3192,7 @@ msgstr "" #: ../source/guides/multi-version-installs.rst:5 msgid "Multi-version installs" -msgstr "" +msgstr "Установка нескольких версий" #: ../source/guides/multi-version-installs.rst:8 msgid "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``)." @@ -3194,11 +3216,11 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:5 msgid "Packaging binary extensions" -msgstr "" +msgstr "Упаковка двоичных расширений" #: ../source/guides/packaging-binary-extensions.rst:8 msgid "2013-12-08" -msgstr "" +msgstr "2013-12-08" #: ../source/guides/packaging-binary-extensions.rst:10 msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." @@ -3206,7 +3228,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:20 msgid "An overview of binary extensions" -msgstr "" +msgstr "Обзор двоичных расширений" #: ../source/guides/packaging-binary-extensions.rst:23 msgid "Use cases" @@ -3238,7 +3260,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:71 msgid "Disadvantages" -msgstr "" +msgstr "Недостатки" #: ../source/guides/packaging-binary-extensions.rst:73 msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." @@ -3274,7 +3296,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:108 msgid "Alternatives to handcoded accelerator modules" -msgstr "" +msgstr "Альтернативы ручному написанию ускоряющих модулей" #: ../source/guides/packaging-binary-extensions.rst:110 msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" @@ -3298,7 +3320,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:150 msgid "Alternatives to handcoded wrapper modules" -msgstr "" +msgstr "Альтернативы ручному написанию модулей-обёрток" #: ../source/guides/packaging-binary-extensions.rst:152 msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." @@ -3334,7 +3356,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:203 msgid "Alternatives for low level system access" -msgstr "" +msgstr "Альтернативы для низкоуровневого доступа к системе" #: ../source/guides/packaging-binary-extensions.rst:205 msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." @@ -3346,7 +3368,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:222 msgid "Implementing binary extensions" -msgstr "" +msgstr "Реализация двоичных расширений" #: ../source/guides/packaging-binary-extensions.rst:224 msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." @@ -3366,7 +3388,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:256 msgid "Binary extensions for Windows" -msgstr "" +msgstr "Двоичные расширения для Windows" #: ../source/guides/packaging-binary-extensions.rst:258 msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." @@ -3382,7 +3404,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:271 msgid "For Python 2.7" -msgstr "" +msgstr "Для Python 2.7" #: ../source/guides/packaging-binary-extensions.rst:273 msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." @@ -3396,11 +3418,11 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:288 #: ../source/guides/packaging-binary-extensions.rst:295 msgid "Done." -msgstr "" +msgstr "Готово." #: ../source/guides/packaging-binary-extensions.rst:280 msgid "For Python 3.4" -msgstr "" +msgstr "Для Python 3.4" #: ../source/guides/packaging-binary-extensions.rst:282 msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." @@ -3412,11 +3434,11 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:287 msgid "Set DISTUTILS_USE_SDK=1" -msgstr "" +msgstr "Установите DISTUTILS_USE_SDK=1" #: ../source/guides/packaging-binary-extensions.rst:290 msgid "For Python 3.5" -msgstr "" +msgstr "Для Python 3.5" #: ../source/guides/packaging-binary-extensions.rst:292 msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." @@ -3432,7 +3454,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:305 msgid "Binary extensions for Linux" -msgstr "" +msgstr "Двоичные расширения для Linux" #: ../source/guides/packaging-binary-extensions.rst:307 msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." @@ -3440,7 +3462,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:313 msgid "Binary extensions for macOS" -msgstr "" +msgstr "Двоичные расширения для macOS" #: ../source/guides/packaging-binary-extensions.rst:315 msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." @@ -3448,7 +3470,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:325 msgid "Publishing binary extensions" -msgstr "" +msgstr "Публикация двоичных расширений" #: ../source/guides/packaging-binary-extensions.rst:327 msgid "For interim guidance on this topic, see the discussion in `this issue `_." @@ -3456,7 +3478,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:343 msgid "Additional resources" -msgstr "" +msgstr "Дополнительные ресурсы" #: ../source/guides/packaging-binary-extensions.rst:345 msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." @@ -3464,7 +3486,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:352 msgid "Cross-platform wheel generation with scikit-build" -msgstr "" +msgstr "Кросс-платформенная генерация колёс при помощи scikit-build" #: ../source/guides/packaging-binary-extensions.rst:354 msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." @@ -3472,7 +3494,7 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:362 msgid "Introduction to C/C++ extension modules" -msgstr "" +msgstr "Введение в модули расширения на C/C++" #: ../source/guides/packaging-binary-extensions.rst:364 msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" @@ -3492,7 +3514,7 @@ msgstr "" #: ../source/guides/packaging-namespace-packages.rst:3 msgid "Packaging namespace packages" -msgstr "" +msgstr "Упаковка пакетов пространства имён" #: ../source/guides/packaging-namespace-packages.rst:5 msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" @@ -3516,7 +3538,7 @@ msgstr "" #: ../source/guides/packaging-namespace-packages.rst:58 msgid "Creating a namespace package" -msgstr "" +msgstr "Создание пакета пространства имён" #: ../source/guides/packaging-namespace-packages.rst:60 msgid "There are currently three different approaches to creating namespace packages:" @@ -3540,7 +3562,7 @@ msgstr "" #: ../source/guides/packaging-namespace-packages.rst:80 msgid "Native namespace packages" -msgstr "" +msgstr "Родные пакеты пространства имён" #: ../source/guides/packaging-namespace-packages.rst:82 msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" @@ -3564,7 +3586,7 @@ msgstr "" #: ../source/guides/packaging-namespace-packages.rst:129 msgid "pkgutil-style namespace packages" -msgstr "" +msgstr "Пакеты пространства имён в стиле pkgutil" #: ../source/guides/packaging-namespace-packages.rst:131 msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." @@ -3590,7 +3612,7 @@ msgstr "" #: ../source/guides/packaging-namespace-packages.rst:171 msgid "pkg_resources-style namespace packages" -msgstr "" +msgstr "Пакеты пространства имён в стиле pkg_resources" #: ../source/guides/packaging-namespace-packages.rst:173 msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." @@ -3818,7 +3840,7 @@ msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:5 msgid "Supporting multiple Python versions" -msgstr "" +msgstr "Поддержка нескольких версий Python'а" #: ../source/guides/supporting-multiple-python-versions.rst:37 msgid "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." @@ -3830,7 +3852,7 @@ msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:49 msgid "Automated testing and continuous integration" -msgstr "" +msgstr "Автоматическое тестирование и непрерывная интеграция" #: ../source/guides/supporting-multiple-python-versions.rst:51 msgid "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." @@ -3898,11 +3920,11 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:3 msgid "Supporting Windows using Appveyor" -msgstr "" +msgstr "Поддержка Windows с помощью Appveyor" #: ../source/guides/supporting-windows-using-appveyor.rst:6 msgid "2015-12-03" -msgstr "" +msgstr "2015-12-03" #: ../source/guides/supporting-windows-using-appveyor.rst:8 msgid "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." @@ -3922,7 +3944,7 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:38 msgid "Setting up" -msgstr "" +msgstr "Настройка" #: ../source/guides/supporting-windows-using-appveyor.rst:40 msgid "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." @@ -3938,7 +3960,7 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:54 msgid "Adding Appveyor support to your project" -msgstr "" +msgstr "Добавление поддержки Appveyor в ваш проект" #: ../source/guides/supporting-windows-using-appveyor.rst:56 msgid "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." @@ -3950,7 +3972,7 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:69 msgid "appveyor.yml" -msgstr "" +msgstr ":file:`appveyor.yml`" #: ../source/guides/supporting-windows-using-appveyor.rst:75 msgid "This file can be downloaded from `here `__." @@ -3990,7 +4012,7 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:119 msgid "Support script" -msgstr "" +msgstr "Скрипт поддержки" #: ../source/guides/supporting-windows-using-appveyor.rst:121 msgid "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." @@ -4006,7 +4028,7 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:137 msgid "Access to the built wheels" -msgstr "" +msgstr "Доступ к собранным колёсам" #: ../source/guides/supporting-windows-using-appveyor.rst:139 msgid "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." @@ -4014,11 +4036,11 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:147 msgid "Additional notes" -msgstr "" +msgstr "Дополнительные замечания" #: ../source/guides/supporting-windows-using-appveyor.rst:150 msgid "Testing with tox" -msgstr "" +msgstr "Тестирование с помощью tox" #: ../source/guides/supporting-windows-using-appveyor.rst:152 msgid "Many projects use the `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." @@ -4038,19 +4060,19 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:170 msgid "``DISTUTILS_USE_SDK``" -msgstr "" +msgstr "``DISTUTILS_USE_SDK``" #: ../source/guides/supporting-windows-using-appveyor.rst:171 msgid "``MSSdk``" -msgstr "" +msgstr "``MSSdk``" #: ../source/guides/supporting-windows-using-appveyor.rst:172 msgid "``INCLUDE``" -msgstr "" +msgstr "``INCLUDE``" #: ../source/guides/supporting-windows-using-appveyor.rst:173 msgid "``LIB``" -msgstr "" +msgstr "``LIB``" #: ../source/guides/supporting-windows-using-appveyor.rst:175 msgid "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." @@ -4074,7 +4096,7 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:203 msgid "Automatically uploading wheels" -msgstr "" +msgstr "Автоматическая загрузка колёс" #: ../source/guides/supporting-windows-using-appveyor.rst:205 msgid "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." @@ -4086,7 +4108,7 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:216 msgid "External dependencies" -msgstr "" +msgstr "Внешние зависимости" #: ../source/guides/supporting-windows-using-appveyor.rst:218 msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." @@ -4098,7 +4120,7 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:230 msgid "Support scripts" -msgstr "" +msgstr "Скрипты поддержки" #: ../source/guides/supporting-windows-using-appveyor.rst:232 msgid "For reference, the SDK setup support script is listed here:" @@ -4106,11 +4128,11 @@ msgstr "" #: ../source/guides/supporting-windows-using-appveyor.rst:234 msgid "``appveyor-sample/build.cmd``" -msgstr "" +msgstr "``appveyor-sample/build.cmd``" #: ../source/guides/tool-recommendations.rst:5 msgid "Tool recommendations" -msgstr "" +msgstr "Рекомендации по инструментам" #: ../source/guides/tool-recommendations.rst:7 msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." @@ -4118,7 +4140,7 @@ msgstr "" #: ../source/guides/tool-recommendations.rst:12 msgid "Application dependency management" -msgstr "" +msgstr "Управление зависимостями приложения" #: ../source/guides/tool-recommendations.rst:14 msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." @@ -4142,7 +4164,7 @@ msgstr "" #: ../source/guides/tool-recommendations.rst:27 msgid "Installation tool recommendations" -msgstr "" +msgstr "Рекомендации по инструментам установки" #: ../source/guides/tool-recommendations.rst:29 msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" @@ -4166,7 +4188,7 @@ msgstr "" #: ../source/guides/tool-recommendations.rst:47 msgid "Packaging tool recommendations" -msgstr "" +msgstr "Рекомендации по инструментам упаковки" #: ../source/guides/tool-recommendations.rst:49 msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" @@ -4410,7 +4432,7 @@ msgstr "" #: ../source/guides/using-testpypi.rst:13 msgid "Registering your account" -msgstr "" +msgstr "Регистрация учётной записи" #: ../source/guides/using-testpypi.rst:15 msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." @@ -4422,7 +4444,7 @@ msgstr "" #: ../source/guides/using-testpypi.rst:24 msgid "Using TestPyPI with Twine" -msgstr "" +msgstr "Использование TestPyPI вместе с Twine" #: ../source/guides/using-testpypi.rst:26 msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" @@ -4434,7 +4456,7 @@ msgstr "" #: ../source/guides/using-testpypi.rst:39 msgid "Using TestPyPI with pip" -msgstr "" +msgstr "Использование TestPyPI вместе с pip" #: ../source/guides/using-testpypi.rst:41 msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" @@ -4475,11 +4497,13 @@ msgstr "" #: ../source/index.rst:36 msgid "Get started" -msgstr "" +msgstr "Начало работы" #: ../source/index.rst:38 msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" msgstr "" +"Основные инструменты и концепции для работы в экосистеме разработки Python " +"описаны в нашем разделе :doc:`tutorials/index`:" #: ../source/index.rst:41 msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" @@ -4499,11 +4523,13 @@ msgstr "" #: ../source/index.rst:52 msgid "Learn more" -msgstr "" +msgstr "Подробнее" #: ../source/index.rst:54 msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" msgstr "" +"Помимо наших :doc:`учебников ` это руководство содержит " +"несколько других ресурсов:" #: ../source/index.rst:56 msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." @@ -4523,7 +4549,7 @@ msgstr "" #: ../source/key_projects.rst:6 msgid "Project Summaries" -msgstr "" +msgstr "Обзор проектов" #: ../source/key_projects.rst:8 msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." @@ -4531,11 +4557,11 @@ msgstr "" #: ../source/key_projects.rst:14 msgid "PyPA Projects" -msgstr "" +msgstr "Проекты PyPA" #: ../source/key_projects.rst:19 msgid "bandersnatch" -msgstr "" +msgstr "bandersnatch" #: ../source/key_projects.rst:21 msgid "`Issues `__ | `GitHub `__ | `PyPI `__" @@ -4571,7 +4597,7 @@ msgstr "" #: ../source/key_projects.rst:64 msgid "distlib" -msgstr "" +msgstr "distlib" #: ../source/key_projects.rst:66 msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" @@ -4587,7 +4613,7 @@ msgstr "" #: ../source/key_projects.rst:90 msgid "packaging" -msgstr "" +msgstr "packaging" #: ../source/key_projects.rst:92 msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" @@ -4608,7 +4634,7 @@ msgstr "" #: ../source/key_projects.rst:119 #: ../source/specifications/platform-compatibility-tags.rst:85 msgid "pip" -msgstr "" +msgstr "pip" #: ../source/key_projects.rst:121 msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" @@ -4624,7 +4650,7 @@ msgstr "" #: ../source/key_projects.rst:137 msgid "Pipenv" -msgstr "" +msgstr "Pipenv" #: ../source/key_projects.rst:139 msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" @@ -4640,11 +4666,11 @@ msgstr "" #: ../source/key_projects.rst:159 msgid "Pipfile" -msgstr "" +msgstr "Pipfile" #: ../source/key_projects.rst:161 msgid "`Source `__" -msgstr "" +msgstr "`Исходный код `__" #: ../source/key_projects.rst:163 msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." @@ -4668,7 +4694,7 @@ msgstr "" #: ../source/key_projects.rst:187 msgid "This guide!" -msgstr "" +msgstr "Это руководство!" #: ../source/key_projects.rst:192 msgid "readme_renderer" @@ -4684,7 +4710,7 @@ msgstr "" #: ../source/key_projects.rst:208 msgid "setuptools" -msgstr "" +msgstr "setuptools" #: ../source/key_projects.rst:210 msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" @@ -4716,7 +4742,7 @@ msgstr "" #: ../source/key_projects.rst:253 msgid "twine" -msgstr "" +msgstr "twine" #: ../source/key_projects.rst:255 msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" @@ -4729,7 +4755,7 @@ msgstr "" #: ../source/key_projects.rst:270 #: ../source/overview.rst:415 msgid "virtualenv" -msgstr "" +msgstr "virtualenv" #: ../source/key_projects.rst:272 msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" @@ -4741,7 +4767,7 @@ msgstr "" #: ../source/key_projects.rst:290 msgid "Warehouse" -msgstr "" +msgstr "Warehouse" #: ../source/key_projects.rst:292 msgid "`Docs `__ | `Issues `__ | `GitHub `__" @@ -4753,7 +4779,7 @@ msgstr "" #: ../source/key_projects.rst:304 msgid "wheel" -msgstr "" +msgstr "wheel" #: ../source/key_projects.rst:306 msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" @@ -4769,11 +4795,11 @@ msgstr "" #: ../source/key_projects.rst:324 msgid "Non-PyPA Projects" -msgstr "" +msgstr "Проекты, не связанные с PyPA" #: ../source/key_projects.rst:329 msgid "bento" -msgstr "" +msgstr "bento" #: ../source/key_projects.rst:331 msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" @@ -4785,7 +4811,7 @@ msgstr "" #: ../source/key_projects.rst:344 msgid "buildout" -msgstr "" +msgstr "buildout" #: ../source/key_projects.rst:346 msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" @@ -4797,11 +4823,11 @@ msgstr "" #: ../source/key_projects.rst:358 msgid "conda" -msgstr "" +msgstr "conda" #: ../source/key_projects.rst:360 msgid "`Docs `__" -msgstr "" +msgstr "`Документация `__" #: ../source/key_projects.rst:362 msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." @@ -4817,7 +4843,7 @@ msgstr "" #: ../source/key_projects.rst:386 msgid "devpi" -msgstr "" +msgstr "devpi" #: ../source/key_projects.rst:388 msgid "`Docs `__ | `Issues `__ | `PyPI `__" @@ -4829,7 +4855,7 @@ msgstr "" #: ../source/key_projects.rst:401 msgid "flit" -msgstr "" +msgstr "flit" #: ../source/key_projects.rst:403 msgid "`Docs `__ | `Issues `__ | `PyPI `__" @@ -4845,7 +4871,7 @@ msgstr "" #: ../source/key_projects.rst:422 msgid "enscons" -msgstr "" +msgstr "enscons" #: ../source/key_projects.rst:424 msgid "`Source `__ | `Issues `__ | `PyPI `__" @@ -4857,7 +4883,7 @@ msgstr "" #: ../source/key_projects.rst:443 msgid "Hashdist" -msgstr "" +msgstr "Hashdist" #: ../source/key_projects.rst:445 msgid "`Docs `__ | `GitHub `__" @@ -4893,7 +4919,7 @@ msgstr "" #: ../source/key_projects.rst:485 msgid "pex" -msgstr "" +msgstr "pex" #: ../source/key_projects.rst:487 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" @@ -4953,7 +4979,7 @@ msgstr "" #: ../source/key_projects.rst:564 msgid "scikit-build" -msgstr "" +msgstr "scikit-build" #: ../source/key_projects.rst:566 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" @@ -4989,7 +5015,7 @@ msgstr "" #: ../source/key_projects.rst:617 msgid "zest.releaser" -msgstr "" +msgstr "zest.releaser" #: ../source/key_projects.rst:619 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" @@ -5001,15 +5027,17 @@ msgstr "" #: ../source/key_projects.rst:630 msgid "Standard Library Projects" -msgstr "" +msgstr "Проекты в стандартное библиотеке" #: ../source/key_projects.rst:635 msgid "ensurepip" -msgstr "" +msgstr "ensurepip" #: ../source/key_projects.rst:637 msgid "`Docs `__ | `Issues `__" msgstr "" +"`Документация `__ | `" +"Замечания `__" #: ../source/key_projects.rst:640 msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." @@ -5017,7 +5045,7 @@ msgstr "" #: ../source/key_projects.rst:649 msgid "distutils" -msgstr "" +msgstr "distutils" #: ../source/key_projects.rst:651 msgid "`Docs `__ | `Issues `__" @@ -5033,7 +5061,7 @@ msgstr "" #: ../source/key_projects.rst:670 msgid "venv" -msgstr "" +msgstr "venv" #: ../source/key_projects.rst:672 msgid "`Docs `__ | `Issues `__" @@ -5045,7 +5073,7 @@ msgstr "" #: ../source/news.rst:2 msgid "News" -msgstr "" +msgstr "Новости" #: ../source/news.rst:5 msgid "September 2019" @@ -5145,7 +5173,7 @@ msgstr "" #: ../source/news.rst:45 msgid "January 2019" -msgstr "" +msgstr "Январь 2019" #: ../source/news.rst:46 msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" @@ -5245,19 +5273,19 @@ msgstr "" #: ../source/news.rst:82 msgid "July 2018" -msgstr "" +msgstr "Июль 2018" #: ../source/news.rst:84 msgid "Improved binary extension docs. (:pr:`531`)" -msgstr "" +msgstr "Улучшена документация по двоичным расширениям (:pr:`531`)." #: ../source/news.rst:85 msgid "Added scikit-build to key projects. (:pr:`530`)" -msgstr "" +msgstr "Для ключевых проектов добавлен scikit-build (:pr:`530`)." #: ../source/news.rst:88 msgid "June 2018" -msgstr "" +msgstr "Июнь 2018" #: ../source/news.rst:90 msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" @@ -5269,7 +5297,7 @@ msgstr "" #: ../source/news.rst:94 msgid "May 2018" -msgstr "" +msgstr "Май 2018" #: ../source/news.rst:96 msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" @@ -5301,11 +5329,11 @@ msgstr "" #: ../source/news.rst:105 msgid "April 2018" -msgstr "" +msgstr "Апрель 2018" #: ../source/news.rst:107 msgid "Added README guide. (:pr:`461`)" -msgstr "" +msgstr "Добавлено руководство по написанию README (:pr:`461`)." #: ../source/news.rst:108 msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" @@ -5333,7 +5361,7 @@ msgstr "" #: ../source/news.rst:116 msgid "March 2018" -msgstr "" +msgstr "Март 2018" #: ../source/news.rst:118 msgid "Updated \"installing scientific packages\". (:pr:`455`)" @@ -5353,7 +5381,7 @@ msgstr "" #: ../source/news.rst:124 msgid "February 2018" -msgstr "" +msgstr "Февраль 2018" #: ../source/news.rst:126 msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" @@ -5377,7 +5405,7 @@ msgstr "" #: ../source/news.rst:133 msgid "January 2018" -msgstr "" +msgstr "Январь 2018" #: ../source/news.rst:135 msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" @@ -5389,7 +5417,7 @@ msgstr "" #: ../source/news.rst:139 msgid "December 2017" -msgstr "" +msgstr "Декабрь 2017" #: ../source/news.rst:141 msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" @@ -5405,11 +5433,11 @@ msgstr "" #: ../source/news.rst:144 msgid "Added news page. (:pr:`404`)" -msgstr "" +msgstr "Добавлена страница новостей (:pr:`404`)." #: ../source/news.rst:147 msgid "November 2017" -msgstr "" +msgstr "Ноябрь 2017" #: ../source/news.rst:149 msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" @@ -5429,7 +5457,7 @@ msgstr "" #: ../source/news.rst:156 msgid "October 2017" -msgstr "" +msgstr "Октябрь 2017" #: ../source/news.rst:158 msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" @@ -5445,7 +5473,7 @@ msgstr "" #: ../source/news.rst:163 msgid "September 2017" -msgstr "" +msgstr "Сентябрь 2017" #: ../source/news.rst:165 msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" @@ -5457,7 +5485,7 @@ msgstr "" #: ../source/news.rst:170 msgid "August 2017" -msgstr "" +msgstr "Август 2017" #: ../source/news.rst:172 msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" @@ -5473,7 +5501,7 @@ msgstr "" #: ../source/news.rst:177 msgid "July 2017" -msgstr "" +msgstr "Июль 2017" #: ../source/news.rst:179 msgid "Added ``flit`` to the key projects list. (:pr:`358`)" @@ -5497,7 +5525,7 @@ msgstr "" #: ../source/news.rst:186 msgid "June 2017" -msgstr "" +msgstr "Июнь 2017" #: ../source/news.rst:188 msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" @@ -5529,11 +5557,11 @@ msgstr "" #: ../source/news.rst:195 msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" -msgstr "" +msgstr "Обновление до Sphinx 1.6.2 (:pr:`323`)." #: ../source/news.rst:196 msgid "Switched to the PyPA theme. (:pr:`305`)" -msgstr "" +msgstr "Переключение на тему PyPA (:pr:`305`)." #: ../source/news.rst:197 msgid "Re-organized the documentation into the new structure. (:pr:`318`)" @@ -5541,7 +5569,7 @@ msgstr "" #: ../source/news.rst:200 msgid "May 2017" -msgstr "" +msgstr "Май 2017" #: ../source/news.rst:202 msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" @@ -5557,7 +5585,7 @@ msgstr "" #: ../source/news.rst:207 msgid "April 2017" -msgstr "" +msgstr "Апрель 2017" #: ../source/news.rst:209 msgid "Added travis configuration for testing pull requests. (:pr:`300`)" @@ -5601,7 +5629,7 @@ msgstr "" #: ../source/news.rst:223 msgid "March 2017" -msgstr "" +msgstr "Март 2017" #: ../source/news.rst:225 msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" @@ -5609,15 +5637,15 @@ msgstr "" #: ../source/news.rst:228 msgid "February 2017" -msgstr "" +msgstr "Февраль 2017" #: ../source/news.rst:230 msgid "Added :pep:`518`. (:pr:`281`)" -msgstr "" +msgstr "Добавлен :pep:`518` (:pr:`281`)." #: ../source/overview.rst:3 msgid "An Overview of Packaging for Python" -msgstr "" +msgstr "Обзор создания Python'ьих пакетов" #: ../source/overview.rst:7 msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." @@ -5633,7 +5661,7 @@ msgstr "" #: ../source/overview.rst:26 msgid "Thinking about deployment" -msgstr "" +msgstr "Мысли о развёртывании" #: ../source/overview.rst:28 msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" @@ -5657,7 +5685,7 @@ msgstr "" #: ../source/overview.rst:46 msgid "Packaging Python libraries and tools" -msgstr "" +msgstr "Python'ьи библиотеки и инструменты для упаковки" #: ../source/overview.rst:48 msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." @@ -5669,7 +5697,7 @@ msgstr "" #: ../source/overview.rst:59 msgid "Python modules" -msgstr "" +msgstr "Модули Python'а" #: ../source/overview.rst:61 msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." @@ -5741,7 +5769,7 @@ msgstr "" #: ../source/overview.rst:155 msgid "Packaging Python applications" -msgstr "" +msgstr "Упаковка Python'ьих приложений" #: ../source/overview.rst:157 msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." @@ -5765,7 +5793,7 @@ msgstr "" #: ../source/overview.rst:181 msgid "Depending on a framework" -msgstr "" +msgstr "В зависимости от фреймворка" #: ../source/overview.rst:183 msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." @@ -5781,7 +5809,7 @@ msgstr "" #: ../source/overview.rst:199 msgid "Service platforms" -msgstr "" +msgstr "Сервисные платформы" #: ../source/overview.rst:201 msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." @@ -5790,18 +5818,19 @@ msgstr "" #: ../source/overview.rst:205 msgid "`Heroku `_" msgstr "" +"`Heroku `_" #: ../source/overview.rst:206 msgid "`Google App Engine `_" -msgstr "" +msgstr "`Google App Engine `_" #: ../source/overview.rst:207 msgid "`PythonAnywhere `_" -msgstr "" +msgstr "`PythonAnywhere `_" #: ../source/overview.rst:208 msgid "`OpenShift `_" -msgstr "" +msgstr "`OpenShift `_" #: ../source/overview.rst:209 msgid "\"Serverless\" frameworks like `Zappa `_" @@ -5817,7 +5846,7 @@ msgstr "" #: ../source/overview.rst:220 msgid "Web browsers and mobile applications" -msgstr "" +msgstr "Веб-браузеры и мобильные приложения" #: ../source/overview.rst:222 msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." @@ -5829,19 +5858,19 @@ msgstr "" #: ../source/overview.rst:231 msgid "`Kivy `_" -msgstr "" +msgstr "`Kivy `_" #: ../source/overview.rst:232 msgid "`Beeware `_" -msgstr "" +msgstr "`Beeware `_" #: ../source/overview.rst:233 msgid "`Brython `_" -msgstr "" +msgstr "`Brython `_" #: ../source/overview.rst:234 msgid "`Flexx `_" -msgstr "" +msgstr "`Flexx `_" #: ../source/overview.rst:236 msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." @@ -5849,7 +5878,7 @@ msgstr "" #: ../source/overview.rst:241 msgid "Depending on a pre-installed Python" -msgstr "" +msgstr "В зависимости от предустановленного Python'а" #: ../source/overview.rst:243 msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." @@ -5857,19 +5886,23 @@ msgstr "" #: ../source/overview.rst:249 msgid "Technologies which support this model:" -msgstr "" +msgstr "Технологии, поддерживающие эту модель:" #: ../source/overview.rst:251 msgid "`PEX `_ (Python EXecutable)" msgstr "" +"`PEX `_ (Python EXecutable --- " +"исполняемый файл Python'а)" #: ../source/overview.rst:252 msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" msgstr "" +"`zipapp `_ (не помогает " +"управлять зависимостями, требует Python 3.5+)" #: ../source/overview.rst:253 msgid "`shiv `_ (requires Python 3)" -msgstr "" +msgstr "`shiv `_ (требует Python 3)" #: ../source/overview.rst:255 msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." @@ -5882,6 +5915,8 @@ msgstr "" #: ../source/overview.rst:267 msgid "Depending on a separate software distribution ecosystem" msgstr "" +"В зависимости от отдельной экосистемы распространения программного " +"обеспечения" #: ../source/overview.rst:269 msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." @@ -5909,19 +5944,19 @@ msgstr "" #: ../source/overview.rst:293 msgid "`Enthought Canopy `_" -msgstr "" +msgstr "`Enthought Canopy `_" #: ../source/overview.rst:294 msgid "`ActiveState ActivePython `_" -msgstr "" +msgstr "`ActiveState ActivePython `_" #: ../source/overview.rst:295 msgid "`WinPython `_" -msgstr "" +msgstr "`WinPython `_" #: ../source/overview.rst:300 msgid "Bringing your own Python executable" -msgstr "" +msgstr "Поставка собственного исполняемого файла Python'а" #: ../source/overview.rst:302 msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." @@ -5941,7 +5976,7 @@ msgstr "" #: ../source/overview.rst:317 msgid "`pyInstaller `_ - Cross-platform" -msgstr "" +msgstr "`pyInstaller `_ --- кросс-платформенный;" #: ../source/overview.rst:318 msgid "`cx_Freeze `_ - Cross-platform" @@ -5950,26 +5985,31 @@ msgstr "" #: ../source/overview.rst:319 msgid "`constructor `_ - For command-line installers" msgstr "" +"`constructor `_ --- для установщиков " +"командной строки;" #: ../source/overview.rst:320 msgid "`py2exe `_ - Windows only" -msgstr "" +msgstr "`py2exe `_ --- только для Windows;" #: ../source/overview.rst:321 msgid "`py2app `_ - Mac only" msgstr "" +"`py2app `_ --- только для Mac;" #: ../source/overview.rst:322 msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" msgstr "" +"`bbFreeze `_ --- Windows, Linux, только " +"Python 2;" #: ../source/overview.rst:323 msgid "`osnap `_ - Windows and Mac" -msgstr "" +msgstr "`osnap `_ --- Windows и Mac;" #: ../source/overview.rst:324 msgid "`pynsist `_ - Windows only" -msgstr "" +msgstr "`pynsist `_ --- Только для Windows." #: ../source/overview.rst:326 msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." @@ -5977,7 +6017,7 @@ msgstr "" #: ../source/overview.rst:332 msgid "Bringing your own userspace" -msgstr "" +msgstr "Поставка собственного пользовательского пространства" #: ../source/overview.rst:334 msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." @@ -5993,23 +6033,23 @@ msgstr "" #: ../source/overview.rst:347 msgid "`AppImage `_" -msgstr "" +msgstr "`AppImage `_" #: ../source/overview.rst:348 msgid "`Docker `_" -msgstr "" +msgstr "`Docker `_" #: ../source/overview.rst:349 msgid "`Flatpak `_" -msgstr "" +msgstr "`Flatpak `_" #: ../source/overview.rst:350 msgid "`Snapcraft `_" -msgstr "" +msgstr "`Snapcraft `_" #: ../source/overview.rst:353 msgid "Bringing your own kernel" -msgstr "" +msgstr "Поставка собственного ядра" #: ../source/overview.rst:355 msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." @@ -6021,7 +6061,7 @@ msgstr "" #: ../source/overview.rst:364 msgid "`Vagrant `_" -msgstr "" +msgstr "`Vagrant `_" #: ../source/overview.rst:365 msgid "`VHD `_, `AMI `_, and `other formats `_" @@ -6033,7 +6073,7 @@ msgstr "" #: ../source/overview.rst:369 msgid "Bringing your own hardware" -msgstr "" +msgstr "Поставка собственного оборудования" #: ../source/overview.rst:371 msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." @@ -6053,7 +6093,7 @@ msgstr "" #: ../source/overview.rst:392 msgid "What about..." -msgstr "" +msgstr "Как насчёт..." #: ../source/overview.rst:394 msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." @@ -6061,7 +6101,7 @@ msgstr "" #: ../source/overview.rst:398 msgid "Operating system packages" -msgstr "" +msgstr "Пакетов операционной системы" #: ../source/overview.rst:400 msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." @@ -6093,7 +6133,7 @@ msgstr "" #: ../source/overview.rst:446 msgid "Wrap up" -msgstr "" +msgstr "Заключение" #: ../source/overview.rst:448 msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." @@ -6101,7 +6141,7 @@ msgstr "" #: ../source/specifications/binary-distribution-format.rst:6 msgid "Binary distribution format" -msgstr "" +msgstr "Формат распространения двоичных пакетов" #: ../source/specifications/binary-distribution-format.rst:8 msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." @@ -6129,7 +6169,7 @@ msgstr "" #: ../source/specifications/binary-distribution-format.rst:34 msgid "Rationale" -msgstr "" +msgstr "Обоснование" #: ../source/specifications/binary-distribution-format.rst:36 msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." @@ -6141,7 +6181,7 @@ msgstr "" #: ../source/specifications/binary-distribution-format.rst:52 msgid "Details" -msgstr "" +msgstr "Подробности" #: ../source/specifications/binary-distribution-format.rst:55 msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" @@ -6237,7 +6277,7 @@ msgstr "" #: ../source/specifications/binary-distribution-format.rst:115 msgid "File Format" -msgstr "" +msgstr "Формат файла" #: ../source/specifications/binary-distribution-format.rst:118 msgid "File name convention" @@ -6526,7 +6566,7 @@ msgstr "" #: ../source/specifications/binary-distribution-format.rst:348 msgid "FAQ" -msgstr "" +msgstr "ЧаВо" #: ../source/specifications/binary-distribution-format.rst:352 msgid "Wheel defines a .data directory. Should I put all my data there?" @@ -6602,7 +6642,7 @@ msgstr "" #: ../source/specifications/binary-distribution-format.rst:450 msgid "Changes" -msgstr "" +msgstr "Изменения" #: ../source/specifications/binary-distribution-format.rst:452 msgid "Since :pep:`427`, this specification has changed as follows:" @@ -6626,7 +6666,7 @@ msgstr "" #: ../source/specifications/binary-distribution-format.rst:482 msgid "Copyright" -msgstr "" +msgstr "Авторские права" #: ../source/specifications/binary-distribution-format.rst:484 msgid "This document has been placed into the public domain." @@ -6634,7 +6674,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:5 msgid "Core metadata specifications" -msgstr "" +msgstr "Спецификации основных метаданных" #: ../source/specifications/core-metadata.rst:7 msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" @@ -6654,7 +6694,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:14 msgid "All the other fields are optional." -msgstr "" +msgstr "Все остальные поля являются необязательными." #: ../source/specifications/core-metadata.rst:16 msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." @@ -6670,7 +6710,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:41 msgid "Metadata-Version" -msgstr "" +msgstr "Metadata-Version" #: ../source/specifications/core-metadata.rst:45 msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." @@ -6760,7 +6800,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:131 msgid "Platform (multiple use)" -msgstr "" +msgstr "Platform (можно использовать несколько раз)" #: ../source/specifications/core-metadata.rst:135 msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." @@ -6768,7 +6808,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:146 msgid "Supported-Platform (multiple use)" -msgstr "" +msgstr "Supported-Platform (можно использовать несколько раз)" #: ../source/specifications/core-metadata.rst:150 msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." @@ -6776,11 +6816,11 @@ msgstr "" #: ../source/specifications/core-metadata.rst:164 msgid "Summary" -msgstr "" +msgstr "Сводка" #: ../source/specifications/core-metadata.rst:168 msgid "A one-line summary of what the distribution does." -msgstr "" +msgstr "Однострочная сводка того, что делает дистрибутив." #: ../source/specifications/core-metadata.rst:188 msgid "This field may be specified in the message body instead." @@ -6808,7 +6848,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:232 msgid "Description-Content-Type" -msgstr "" +msgstr "Description-Content-Type" #: ../source/specifications/core-metadata.rst:236 msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." @@ -6824,23 +6864,23 @@ msgstr "" #: ../source/specifications/core-metadata.rst:259 msgid "Format::" -msgstr "" +msgstr "Формат::" #: ../source/specifications/core-metadata.rst:263 msgid "The ``type/subtype`` part has only a few legal values:" -msgstr "" +msgstr "Часть ``тип/подтип`` имеет только несколько допустимых значений:" #: ../source/specifications/core-metadata.rst:265 msgid "``text/plain``" -msgstr "" +msgstr "``text/plain``" #: ../source/specifications/core-metadata.rst:266 msgid "``text/x-rst``" -msgstr "" +msgstr "``text/x-rst``" #: ../source/specifications/core-metadata.rst:267 msgid "``text/markdown``" -msgstr "" +msgstr "``text/markdown``" #: ../source/specifications/core-metadata.rst:269 msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." @@ -6876,7 +6916,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:320 msgid "Keywords" -msgstr "" +msgstr "Keywords" #: ../source/specifications/core-metadata.rst:324 msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." @@ -6888,7 +6928,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:341 msgid "Home-page" -msgstr "" +msgstr "Home-page" #: ../source/specifications/core-metadata.rst:345 msgid "A string containing the URL for the distribution's home page." @@ -6896,7 +6936,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:353 msgid "Download-URL" -msgstr "" +msgstr "Download-URL" #: ../source/specifications/core-metadata.rst:357 msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" @@ -6904,7 +6944,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:366 msgid "Author" -msgstr "" +msgstr "Автор" #: ../source/specifications/core-metadata.rst:370 msgid "A string containing the author's name at a minimum; additional contact information may be provided." @@ -6912,7 +6952,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:383 msgid "Author-email" -msgstr "" +msgstr "Author-email" #: ../source/specifications/core-metadata.rst:387 msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." @@ -6937,7 +6977,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:426 msgid "Maintainer-email" -msgstr "" +msgstr "Maintainer-email" #: ../source/specifications/core-metadata.rst:430 msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." @@ -6949,7 +6989,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:452 msgid "License" -msgstr "" +msgstr "Лицензия" #: ../source/specifications/core-metadata.rst:456 msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." @@ -6957,7 +6997,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:476 msgid "Classifier (multiple use)" -msgstr "" +msgstr "Classifier (можно использовать несколько раз)" #: ../source/specifications/core-metadata.rst:480 msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." @@ -6972,7 +7012,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:496 msgid "Requires-Dist (multiple use)" -msgstr "" +msgstr "Requires-Dist (можно использовать несколько раз)" #: ../source/specifications/core-metadata.rst:499 #: ../source/specifications/core-metadata.rst:561 @@ -7019,7 +7059,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:538 msgid "Requires-Python" -msgstr "" +msgstr "Requires-Python" #: ../source/specifications/core-metadata.rst:542 msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." @@ -7035,7 +7075,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:558 msgid "Requires-External (multiple use)" -msgstr "" +msgstr "Requires-External (можно использовать несколько раз)" #: ../source/specifications/core-metadata.rst:565 msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." @@ -7055,7 +7095,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:593 msgid "Project-URL (multiple-use)" -msgstr "" +msgstr "Project-URL (можно использовать несколько раз)" #: ../source/specifications/core-metadata.rst:597 msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." @@ -7067,7 +7107,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:612 msgid "Provides-Extra (multiple use)" -msgstr "" +msgstr "Provides-Extra (можно использовать несколько раз)" #: ../source/specifications/core-metadata.rst:616 msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." @@ -7087,7 +7127,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:644 msgid "Rarely Used Fields" -msgstr "" +msgstr "Редко используемые поля" #: ../source/specifications/core-metadata.rst:646 msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." @@ -7099,7 +7139,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:660 msgid "Provides-Dist (multiple use)" -msgstr "" +msgstr "Provides-Dist (можно использовать несколько раз)" #: ../source/specifications/core-metadata.rst:667 msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." @@ -7119,7 +7159,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:701 msgid "Obsoletes-Dist (multiple use)" -msgstr "" +msgstr "Obsoletes-Dist (можно использовать несколько раз)" #: ../source/specifications/core-metadata.rst:708 msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." @@ -7135,15 +7175,16 @@ msgstr "" #: ../source/specifications/core-metadata.rst:730 msgid "reStructuredText markup: http://docutils.sourceforge.net/" -msgstr "" +msgstr "Разметка reStructuredText: http://docutils.sourceforge.net/" #: ../source/specifications/core-metadata.rst:735 msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" msgstr "" +"RFC 822 Длинные поля заголовков: http://www.freesoft.org/CIE/RFC/822/7.htm" #: ../source/specifications/declaring-build-dependencies.rst:6 msgid "Declaring build system dependencies" -msgstr "" +msgstr "Объявление зависимостей системы сборки" #: ../source/specifications/declaring-build-dependencies.rst:8 msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." @@ -7172,7 +7213,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:29 #: ../source/specifications/declaring-project-metadata.rst:41 msgid "``name``" -msgstr "" +msgstr "``name``" #: ../source/specifications/declaring-project-metadata.rst:31 msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" @@ -7220,7 +7261,7 @@ msgstr "" #: ../source/specifications/declaring-project-metadata.rst:66 msgid "``description``" -msgstr "" +msgstr "``description``" #: ../source/specifications/declaring-project-metadata.rst:69 msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" @@ -7473,7 +7514,7 @@ msgstr "" #: ../source/specifications/dependency-specifiers.rst:6 msgid "Dependency specifiers" -msgstr "" +msgstr "Спецификаторы зависимостей" #: ../source/specifications/dependency-specifiers.rst:8 msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." @@ -7493,7 +7534,7 @@ msgstr "" #: ../source/specifications/direct-url.rst:17 msgid "Specification" -msgstr "" +msgstr "Спецификация" #: ../source/specifications/direct-url.rst:19 msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." @@ -7582,18 +7623,18 @@ msgstr "" #: ../source/specifications/direct-url.rst:122 msgid "Git" -msgstr "" +msgstr "Git" #: ../source/specifications/direct-url.rst:124 #: ../source/specifications/direct-url.rst:156 #: ../source/specifications/direct-url.rst:179 #: ../source/specifications/direct-url.rst:202 msgid "Home page" -msgstr "" +msgstr "Домашняя страница" #: ../source/specifications/direct-url.rst:126 msgid "https://git-scm.com/" -msgstr "" +msgstr "https://git-scm.com/" #: ../source/specifications/direct-url.rst:128 #: ../source/specifications/direct-url.rst:160 @@ -7642,16 +7683,16 @@ msgstr "" #: ../source/specifications/direct-url.rst:154 msgid "Mercurial" -msgstr "" +msgstr "Mercurial" #: ../source/specifications/direct-url.rst:158 msgid "https://www.mercurial-scm.org/" -msgstr "" +msgstr "https://www.mercurial-scm.org/" #: ../source/specifications/direct-url.rst:162 #: ../source/specifications/direct-url.rst:166 msgid "hg" -msgstr "" +msgstr "hg" #: ../source/specifications/direct-url.rst:170 msgid "A tag name, branch name, changeset ID, shortened changeset ID." @@ -7663,7 +7704,7 @@ msgstr "" #: ../source/specifications/direct-url.rst:177 msgid "Bazaar" -msgstr "" +msgstr "Bazaar" #: ../source/specifications/direct-url.rst:181 msgid "https://bazaar.canonical.com/" @@ -7672,7 +7713,7 @@ msgstr "" #: ../source/specifications/direct-url.rst:185 #: ../source/specifications/direct-url.rst:189 msgid "bzr" -msgstr "" +msgstr "bzr" #: ../source/specifications/direct-url.rst:193 msgid "A tag name, branch name, revision id." @@ -7693,7 +7734,7 @@ msgstr "" #: ../source/specifications/direct-url.rst:208 #: ../source/specifications/direct-url.rst:212 msgid "svn" -msgstr "" +msgstr "svn" #: ../source/specifications/direct-url.rst:216 msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." @@ -7773,7 +7814,7 @@ msgstr "" #: ../source/specifications/entry-points.rst:5 msgid "Entry points specification" -msgstr "" +msgstr "Спецификация точек входа" #: ../source/specifications/entry-points.rst:7 msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" @@ -7793,7 +7834,7 @@ msgstr "" #: ../source/specifications/entry-points.rst:28 msgid "Data model" -msgstr "" +msgstr "Модель данных" #: ../source/specifications/entry-points.rst:30 msgid "Conceptually, an entry point is defined by three required properties:" @@ -7849,7 +7890,7 @@ msgstr "" #: ../source/specifications/entry-points.rst:112 msgid "For example::" -msgstr "" +msgstr "Например::" #: ../source/specifications/entry-points.rst:124 msgid "Use for scripts" @@ -7981,7 +8022,7 @@ msgstr "" #: ../source/specifications/platform-compatibility-tags.rst:83 msgid "Tool" -msgstr "" +msgstr "Инструмент" #: ../source/specifications/platform-compatibility-tags.rst:83 msgid "``manylinux1``" @@ -8309,7 +8350,7 @@ msgstr "" #: ../source/specifications/source-distribution-format.rst:6 msgid "Source distribution format" -msgstr "" +msgstr "Формат распространения в исходных кодах" #: ../source/specifications/source-distribution-format.rst:8 msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." @@ -8353,7 +8394,7 @@ msgstr "" #: ../source/specifications/version-specifiers.rst:6 msgid "Version specifiers" -msgstr "" +msgstr "Спецификаторы версии" #: ../source/specifications/version-specifiers.rst:8 msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." @@ -8365,7 +8406,7 @@ msgstr "" #: ../source/support.rst:3 msgid "How to Get Support" -msgstr "" +msgstr "Как получить поддержку" #: ../source/support.rst:5 msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." @@ -8445,7 +8486,7 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:28 msgid "Requirements for Installing Packages" -msgstr "" +msgstr "Требования к установке пакетов" #: ../source/tutorials/installing-packages.rst:30 msgid "This section describes the steps to follow before installing other Python packages." @@ -8537,7 +8578,7 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:195 msgid "Creating Virtual Environments" -msgstr "" +msgstr "Создание виртуальных окружений" #: ../source/tutorials/installing-packages.rst:197 msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." @@ -8577,11 +8618,11 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:232 msgid "Using `venv`_:" -msgstr "" +msgstr "Использование `venv`_:" #: ../source/tutorials/installing-packages.rst:248 msgid "Using :ref:`virtualenv`:" -msgstr "" +msgstr "Использование :ref:`virtualenv`:" #: ../source/tutorials/installing-packages.rst:264 msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." @@ -8609,7 +8650,7 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:297 msgid "Installing from PyPI" -msgstr "" +msgstr "Установка из PyPI" #: ../source/tutorials/installing-packages.rst:299 msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." @@ -8657,7 +8698,7 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:408 msgid "Installing to the User Site" -msgstr "" +msgstr "Установка в пользовательский каталог :file:`site`" #: ../source/tutorials/installing-packages.rst:410 msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" @@ -8689,7 +8730,7 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:478 msgid "Installing from VCS" -msgstr "" +msgstr "Установка из СКВ" #: ../source/tutorials/installing-packages.rst:480 msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." @@ -8697,11 +8738,11 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:502 msgid "Installing from other Indexes" -msgstr "" +msgstr "Установка из других индексов" #: ../source/tutorials/installing-packages.rst:504 msgid "Install from an alternate index" -msgstr "" +msgstr "Установка из альтернативного индекса" #: ../source/tutorials/installing-packages.rst:518 msgid "Search an additional index during install, in addition to :term:`PyPI `" @@ -8709,7 +8750,7 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:534 msgid "Installing from a local src tree" -msgstr "" +msgstr "Установка из локального дерева исходных кодов" #: ../source/tutorials/installing-packages.rst:537 msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." @@ -8729,7 +8770,7 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:605 msgid "Installing from other sources" -msgstr "" +msgstr "Установка из других источников" #: ../source/tutorials/installing-packages.rst:607 msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." @@ -8737,7 +8778,7 @@ msgstr "" #: ../source/tutorials/installing-packages.rst:619 msgid "Installing Prereleases" -msgstr "" +msgstr "Установка предварительных выпусков" #: ../source/tutorials/installing-packages.rst:621 msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." @@ -8765,7 +8806,7 @@ msgstr "" #: ../source/tutorials/managing-dependencies.rst:4 msgid "Managing Application Dependencies" -msgstr "" +msgstr "Управление зависимостями приложений" #: ../source/tutorials/managing-dependencies.rst:6 msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." @@ -8789,7 +8830,7 @@ msgstr "" #: ../source/tutorials/managing-dependencies.rst:30 msgid "Installing Pipenv" -msgstr "" +msgstr "Установка Pipenv" #: ../source/tutorials/managing-dependencies.rst:32 msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." @@ -8797,7 +8838,7 @@ msgstr "" #: ../source/tutorials/managing-dependencies.rst:38 msgid "Use ``pip`` to install Pipenv:" -msgstr "" +msgstr "Используйте ``pip`` для установки Pipenv:" #: ../source/tutorials/managing-dependencies.rst:54 msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." @@ -8805,7 +8846,7 @@ msgstr "" #: ../source/tutorials/managing-dependencies.rst:65 msgid "Installing packages for your project" -msgstr "" +msgstr "Установка пакетов для вашего проекта" #: ../source/tutorials/managing-dependencies.rst:67 msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" @@ -8817,7 +8858,7 @@ msgstr "" #: ../source/tutorials/managing-dependencies.rst:112 msgid "Using installed packages" -msgstr "" +msgstr "Использование установленных пакетов" #: ../source/tutorials/managing-dependencies.rst:114 msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" @@ -8838,7 +8879,7 @@ msgstr "" #: ../source/tutorials/managing-dependencies.rst:143 #: ../source/tutorials/packaging-projects.rst:594 msgid "Next steps" -msgstr "" +msgstr "Следующие шаги" #: ../source/tutorials/managing-dependencies.rst:145 msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" @@ -8878,7 +8919,7 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:2 msgid "Packaging Python Projects" -msgstr "" +msgstr "Упаковка Python'ьих проектов" #: ../source/tutorials/packaging-projects.rst:4 msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." @@ -8894,7 +8935,7 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:35 msgid "A simple project" -msgstr "" +msgstr "Простой проект" #: ../source/tutorials/packaging-projects.rst:37 msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." @@ -8922,7 +8963,7 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:75 msgid "Creating the package files" -msgstr "" +msgstr "Создание файлов пакета" #: ../source/tutorials/packaging-projects.rst:77 msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" @@ -9086,7 +9127,7 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:333 msgid "Creating README.md" -msgstr "" +msgstr "Создание файла :file:`README.md`" #: ../source/tutorials/packaging-projects.rst:335 msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." @@ -9098,7 +9139,7 @@ msgstr "" #: ../source/tutorials/packaging-projects.rst:354 msgid "Creating a LICENSE" -msgstr "" +msgstr "Создание файла :file:`LICENSE`" #: ../source/tutorials/packaging-projects.rst:356 msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" From d5c98288e01771116b41992db39c7058b87e67a6 Mon Sep 17 00:00:00 2001 From: Olexandr Date: Wed, 1 Sep 2021 22:29:41 +0200 Subject: [PATCH 0109/1072] Translated using Weblate (Ukrainian) Currently translated at 17.4% (397 of 2271 strings) Co-authored-by: Olexandr Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/uk/ Translation: pypa/packaging.python.org --- locales/uk/LC_MESSAGES/messages.mo | Bin 27857 -> 39294 bytes locales/uk/LC_MESSAGES/messages.po | 34 +++++++++++++++++++++++------ 2 files changed, 27 insertions(+), 7 deletions(-) diff --git a/locales/uk/LC_MESSAGES/messages.mo b/locales/uk/LC_MESSAGES/messages.mo index abb572ebbd9c38f21bbad70edf31369bdb307b2f..0a801d8382511d8aa847d86beeae4a1a1bfec136 100644 GIT binary patch literal 39294 zcmeI537A|}nfEWC0uhi+1QEGmPe@g7Svny>nxsR5Nr>rYN7L2ax4Vl}R~5B%rvoSu z1Q{_P#>7EoQxL~dLkJ`+NoE|}^|M-K9A(rI9rw}E8OMG6e*gEJTT6Eb(C>S`=lSNL z<>Y_Qxo3UPyPfymTYl@vm%KaR@9O=6;5FcXzB~v{*gpuq@G6xC!8u_Nbb%e44HXQ1ZuTaWvl6a)v6KiK1upvFJm1Tw{- z2%Z7H+v6Vac=A8+_YXM5$mx15)_kRo?Oa7N&5BPG3p?PFLm6yTez)j%6;Dey(x*a?Qd>p;z~3~C*30kscnl8(PV0_y%3L9Op=;9=lTK<(r2JRaEO>K*OzwI0v#*y?ei z$ED!!X}=nLIk=+Pt@9F4`_l&=2$n(Z-?gCXZ3RV-4}gb*AM^RW9zW;tX;Ad|7mq*k z_)Adh`8_DQytIY&K$k zcYu=14}pka@Dz9?_)}2z{sc-6j-Th~GaWpU{7g{uIN#%?9*02f|0t;S-{Q-+g3pqF z02CkG((d->-Js@m4|p2*AgJ-b1Re`M>+`<{)$d^_LG4QjGPR%?Tnr9^_kbS(p9EJd zaQ6>B3)v%o4k&rK1JwAR0ZZUl!H-0nu$dZFLa5^{)ijQvt)$Tpuh2TfPrQm)LOMJHs)IMgwlfYX+ zwkG&E$P$7dfa>q`CCnLI4yygt;7aflU#^D6x!^&R zcY|8j8$s>k5Ga1W2GqRY4XXV|K=I9Pk6!>){~1v8`Z;(I_$N^FISA&|{i8udJvakY ze{TfYvY-fRzB@sU|CG;v34AH}fA;t+sD6J49svFVRJ&jK`}?2o>K_CiNcmyl!Qe4I zANu?m;7cfP1=Y_yP~)5h?hkf=h)S>ogk^$_pyv4*kfDM@UhnqfB2fEP0;O+n@%SL9 zeg8D5e*X!a27U|FxIY55j-P>=->*T2BSoH1$)&HfS#_a<&?hyDg@G75Q4{CnbgWA_yL5=fX@DT7Lp!(Sbs{JQG z)&D%Ge*Y2F{GS0e&u@cT_b>eYUxTXu2VZ{RDyL@-1^;zFcp4n${(h?+eRJS33vn$JxhH-Vzx7LRv>qT7QW|JLI+Q1jX0aj(bEf!f!n z!BfE>fv175=)!je=YmIqSAnA2jiC7AUEmSmUQl{u9F%_jIjC_uyB!@@gJ+O0cziD? zee;yR|1UnjKaHioU+eJ_Q1iJ1oB{3v|C)V$7HlJb&Bbm$+rXp9@AdcVMhe_dWg&6#pJ}sjK%&Q2CQU$>|L60dN@9z8`&=>puj4LjFv!8GO~{ zj&GKMqSvKh6F3CE8GH|@dA;fiXJ<|VXOX`Q6di8{li>Z}Dd1PZSAo9;&jOFYXdVi# z1htOKJ?231!A4Mgdn+h@e?M4&ZaYBn_33NfS$H|9em>db>VL)K_dxCUuR!&8P|C^e z5gw;|Yym}|4p8e^28tiLJVqWz!J{d^1r$B*0>z&n1vSn?pyv4$_*!l}18Usg^*eq# zAaeHkQt;0GIB$ZtbN}c;N00l#W66I96rcPKd<}TYkeg43$1abN$5D^BfTH7jJ$~Hd zKY(9nysv@U?}x5*^Vkh)J>LWm1b+!iPJRcf-kf!go*f?7fUl&y&*PZK+dz$bzsJWs zei4*j{0=BR`4jLW49IUl>BS4OuDlyOo_q>a`L&?NxxwRmK=uDIkDmaik^e{V1n@hc z+W!fh10J7q`}qb?>$(Iy2kZegk9)!6z>k62ug`$$|J$JY`wvjtPXI1X$gf4;{J z;C;~ZZ+w1b!Re7}!FK9>7+eKD3##9iq8q0Zd^Pzi!1KUS@NsZ2xD?z_qCWlpJ*as; zU3T*GEZ9o^h>;+8J-7r!6$H0~ZQu{Vx!`L?9UpdqhmjuuF9gfrE5Xlu{Eo+8gR&Qg zu6KNQmd9=|!#sw;)42bQF-PzHHaLDb1YAz}3E->2LGW1c2JlGmy`bdhW8f>mzXKsf zPyufP7hfF&{q+A8unBCx7M`Mf2&Hlh_yuq^c+p$@IR^X&`KQ3wQUC7ikWKL0*E{;P zZFGG6Gf?9na3ek*_m2U85AJu9(-(id+3o9zZ*%>g4vIgQfJcF=K+&xid=|V4{0Fd` zNzJ04WB)1$7Lo6KyX$8ocsTjDgVKBN1LuLC1ykUDw>o+11EpW?0?z{P2TuXN1HK%5 z**n~Pjs!nTz6lgR{1!YJJZF=W*M9IM@;8DS=R@G@z;A=o!4n~F3)lgweGyy&8FzWf(H|3{xc=nhAh zqd~Ph6%_xq`22aG1H>t<3RN{1JwLmLES$aoDHr4=YThZuLpO7n(x8ycHy~WA< zn?UWygW%ENr@+^O&v^VDcsTjvwz__2f}(3PsBzB%wT^SZBf;gM=5d9`9#H(+532v| zpy>W-Q2YLMa3T03Q2c({dz{`~=CK5dPwoM={wG0=`zcW4ejbz@e%0rn0X4txf!f!f zgBs_*LDBcHzjpl`532pCpz0?<^*bNb{Lcn8&vQZ1v)kXl3{?HKzWhq?Q1W?jKd?{# z@V7tsd+>7br6lo&?7sfa@pX;>UrBlsWh1^!zR)koYtIhm`i-QIa;?8R9aR7Q6;~}j zC!KK)sl(?5$NB3X`p{n+>HVbpNFN}DB-BiBE$L$F%ptv(>z9Maf?7A~HFz887Sbxp zk0ix^sG#5xpP3E*z+a1QWByujo^SJ~x-wlNY8I=}wP>&Xct#oj_fwBMJc>`|)s63q zgP(Kp63P?cqofP`jo16SgXG17A0k~s*_GfZX&Tp`1c$&=z!B1!q<-tWN0B>4mS`#R}sq>?iH zEv9@4=~blnk^d~|zewLA>F*xWy`)c&-b9_1B>kNZeg|AedW^J!)JECgg8F->gWzn+ ze#vzUIMrXum$!nakS?RrTS#a4@&S)(+pT~2>!s{(z!Sl@TM1`-@Kh2i&tiGL*!0^^ z$jqQ_nWVq7z?tBQr2j?gC&hnBU+1e79K>}Nl+SW8`0u2dFtHUi>%YFOH$CxvqT7UoYYQ4@uHd z`n!mfud6qo>j&%(@mH?@it82r{^z*zUwXzHVG)Iu|FAPWA== z0KUUtFQD$Fq}}A___F=M(@9?@&E?*|`EtQp^7^|1+^!4ogTV2mw~~san@C?IZ6R$X zq2?{F0#yIj)9x5@uOdC+OD_kHqx?7EE5O6S)u8^qsIN4A=FITf_dOW?``z!@rVI61$Q6r;LNpK+qHJFj z4o2CikSiB6V>4%Rds&p~PiF^eZfl#}+A=3-o!c_Mxw(B#(3YG_nn!96=C-xB zw9aX5W!CfNwNqjC-1e4W{@k`X&2#6qHn#-}2GW^mLC?yLRm+!lc6BGy*`BG&!oJ+_ zF#J%AZ?5U=ShBJ+Io#h9o>7cS<$NiZ%M`=5xyjkd<}+tZs8%SJsOPzdxt$s23SnKd z=H%RD>%2+LO6yD2*|-6#+5DJi!el8ooN1iI?6zcc{UmIlWZ%Fbt@BZSLC@^A_MWh- zoX_V9rCpM<8rWTUgv(-Tn8wlizD&743a`$mN-ftKv|bw~ zlgVn0!A!097+|%fcZ=$ zHH4Z9`%>9(AdP;KbT8{(xgyM!OZjpsOlPgArzhFeTTW;Cn}$lTM-O_8`Id5pv1E9u zZ=cIYabcNrV)~NIDv|&IZeA_M4tZqu#K$kQ*&Vg;^mwF-(_EFR~N~hx8EB z$-&kIl&I$A+LepaXv}w6clT;{w~!1vG8wCrqhf)jM4A3#m?}hJ&Qx3~LzO%e>`$-f zqL9vnQXRF+_S)tAprgA(biw=W2^Ig&Mgsxjr=WSa9wbTb^~c$7(oDe$DE!)fb+3jWbrvGFmUY z;V3_l%VctH%T{+SWoLR8=h(R1K!~a9FZY#t)~-zki=%Amg07}D%Q{yCi-%I#L3nWS zP%dZYWH^F6sa_aB#;=@BUsaA|l%j9|jRofwV)N+us6UrIy##-1$8%xIcFa{P!w1$7 z-WA98r~6~(ER|uzw6@sB)#_5AS3SxU`-Y<7C|I1!l!vo`X3T_4Vb-nz%~b z>Ya8+4l+@&BvnemrTtMxmr>Z8Dzd*d`UFd&-gGM4bYU-@l*#o)awHrR*5}%}SL`dK zO`?J&>0+vX1WAByMdkX+MJfA+YvcNX9Jd$}GMD9D;42`9+9ha{&cX@9wh76wdnkf! z;K7W9Diz9!Ne`s^pnjfzN7HaVYNGDOU=HPnD#6X^PlgNnbA7TX7#3I#U(3%aVSY@= z-LkegTv)qRZ1T_hs_EjUfZ+9T>-C(6~U%eEzFH)iKp)^DJO zHs0XkymTozFM~789D?&?K#CqFvY4cS?N1k_X6sp{lq#+>+R50N_Zx+#kTcOpl#yD? z7b3UwMftkxvboVr)IS)-e5oBOrias+6y_B5>D3ONzHFB%trW_wfJJlTXe&^3Fky9E zOz?=TUnW;7YREoRU5ZQXX{u(<>!d=vmW?8;q0M8=SSFPz=3@S4Pw}T3iVp*yF7`{M5n}TRg7d- zqv2wdk*SYkjpZm0@IdN!ruGqVhR5gMWB8W z;f(Kp09VR6U&Y)&X;j?NFHXV_Vo;W3XQBop7Y-D1!=@%s)fr~LdO6DwpZ4_R?JU?9 zCWb@YVx6a9_&VR6S^6>&_cc}!MTjB7-N_(~(h`_@pF&IjkGvaw*d*JtJj z=a(~H-s3AO_%hwa2{tDxzS3P+Ha~d%q#ZP($1;Py%Z*|Zq=vYXIF(WQxKpMA{ajVt z9ig~Hs99`!8grX2%0)=Q37Cznw0RNp4->h4w)(}fVksI9bA5d&w?!-j`-i&=XL$Z~ zBIiseJhB|`4o$7mG#PkHJ=qSS;zL?G(~6wRM=GSvHiVhBogF6oa~RWUw*?OOn{u z+NJmZR;J{#+HO=Y+o|SD=X2?|(qHJNm2fL6aAv`O3RdR&%Qy@xa}dGA1VPIc*2!>7 zeRy9HHL^~0%%Bb8TRq5|LKrL%O}(t#3s2^As8LP`@)E=D941X$g_KAA7_*_MkB-rs z>KScqBlg%CB28o>D$>lhs3%`WJYCg$r6(vG?N?+VE$Jg?+InMqg{qSy*e0W&2m5`hryvZxpPG)@un-p35Bnjnp|x z^||)o0?tNNAF3|H9n_#sLcwashv9Oam8vrSn_nPfawzP$3^z=yOmrLnPk%M44 z-;Yx{Bd&x+PtJYbI&+fG-_P7+cmc-)J9Xm1%k4x1o02W22ea;oV(clmF!YloSOZUH zIF@!fn-KOaOXG!%FLBr-NlCyewm4xn|I(8>LIgzT-F-46Far@kw;?ZLU@&P5B?XW4VMwfy$ zw$c<*E)UeZiOy|qnq>5Q(|9vuL^3$8m}`$TSTj5GIv3NKugOOvi03se(j6a!anu{f z5+_+Wl;y@ou9&bs6LkkIH>^nm+QQ~(x?wOqqQU{(qh7>`$qmvWB&nT>q@jjNrF?Ng zQxie1bP|6(OvvY!-gZtq%0Y}(8dbCbKSZY_^QZ9zu>7IE7(R!AnI=YWl2-fK6w?Nu7 z=FD_yR!BVR+3OyNZ(i!-F|`_D@0jXHQP$Oymw}xt))jF%gz|T1HK)jvL02EF9&{O#~%gZp`GZ&mp&L=CwQ`c3{<&S*Er;WMdgsc&~ z78{RGcSx^uy4^B#8Yo0V;$WOJ`~ZKH)4atdg9W%JQO?uKT)qLBHJN7M7)dq(AVSQ1G=$%RabY% ziWQw}YDFtMyE~S2ba&KB)^skuV9kR~D8pCo3}sOu&_ zn#S+yC0?Wmt;O)P1kDRoYGFm`iUsY>&CRY^>>s)?2QFe&tK|yC=^+b8$x6}2hu_iE zn4MIIqD)@C;4EZL$1zqTRuT2$h>b$ly(WBeI~6vHx3t`wK^eJKX&$t)`HSPZ=0EK` z=XTsccn066m{vft<|p|8p$n`qXE{A~b|uclRH*BYtknaErdhCHAv58~M_5Fxk}48P zu|fSNi2&8k1{Ca+y`yoBqnzVm0VQWJV*L>2ou9_hU!8 zHHRR#g?2Rw+jA&xx;(>#2sdw4c(N`?S&E3Es8e;~rP~|nK8zcTh;o|{ zWl|i{4xrqE!wFYr6&sLr>A;Za9m5h3)G*d`AqklxBfO76aIWN;Yc}HXZiqUUwYE@1 zT`VXWR)d@IadU!!=^-MIQ%F3agmb}`xl^_Hu4yJJnr)ftpe=2H4rSlmeqqU_QVBDe zDKt)UM`hEu1@C9EI<&4QlZ$60!*G>7G(d;Zmkw!ez?h)1SI8#8w0evHp={5ghmQ8z zcFogC!Wc_Q5S6Q*CVS4Z0po5=OZg?yC{~-XtJkE>>W>Ce#K=S$%_2V72N$9B89cZs z$3fhAdf1=fVs;R*z)8DU4x;(FJdY$75holehMj|h%49?De^#GZnPl0fX|tVha#%*Q z^!F24cB&}07sYTU1ez(6!&tT`l$0GRc>FP(%k|rk+4v#8IUBQ3Nyrt4S__0Zo#h^S zNkg!KS)K)O-*=fNlok7C1RL{dp3|o{*gSpj%)vWSss6D#{*d{@a>sOrw%TWZ5L#V- zcr}(#P!)c*__8YUa2JwJcvd52?B&k|P0h4Zo%OSJ9v_>vO%M3@9q<^SGc2SYomHZX z*rWy*6ZFS61s4}mxUzYW$Dv+BN`uK`z8D)fxFF=DTy=JRQFo>sx*5Ne zB@mxVrSX2iuhqtD9oex_(=^r5#8IvZ#}d0|Bih=#vZ;KZy+cy1UW|*9Y_L_j zh@+*{S+$CK9C3x^e62IIn45#E2{p0YZserbH*uFeXD@2eyEr{PL65HI*I%~z($=~f zt~H04=g{M6bt9phJY0*UdyM%dSswMs`_q z1?jmZ*%I%wxrcPxl5Dp=%LRpVY0Gg&PLW;1_INxrgpGVd1TUgd9lNGmL&`uuN0;OI;+=QE4D? zCE@qPmBm~(!3$6cIMB?~U)Wr+a9%nkBB9rz$W?X$MZjlM@Ne#UvqA;mO4TY0SCe|PyCKB0P z!d|N5Qt#;{BqF?6<^$XHb8G0{-bQU|YLeA%l6O040#kLtkO|qD5?`Oz)8o17jt*t4 zF2|$#SAtdM^o6cOVw1LF;LLCkpVREZyw`#*-GeK87d3FYlP#4<^YF9SmtF_Qxb3XD z#qKIU7SwcRAk`5RN3sFW_IV|<&V~f0{{r5!8VN?yg;JSEB3wFEumRT$pUomVh4|@N zVtIdT-xh=yt}CExd25Q$_gFqPW7--xqEJe#EDomo6X%u(i;3>sf^gdE3lc7vk9_Fm zs|DeuogHfuD=$ba=?Iryuwdo#GcUVfRp+!7gx?a~xC=!b!(3rOxb(smE5cPBD?7u5 zohv(*uQ;b;$&xjlU0r8WH9J_wolbN|sp0yWRQ(JW!cU@H=ZmIy`7hTxBG|^tG zrxkIQOLS)Yau(JL+k4ZcX{$55cb7@%?VjR-Fq^k*aZ%e@Jge26McGqZninl<2~RsM z)MfMZMJ+Ai>%!)c+T_n()EeJfxM;R6&#-C>Tbjdbu5nGM(>#MVEwpJpYuY7=^Yre# zqwd9yG~sNFUkeVy$TVK2uiP=dW&DQ9w(-rCCo6kqg_Z4GAQ66l|+J zL7{4en z_5T>1KN8aIBiwsr{H^xy^_AV@TU5Ab{CXQ@TV*#zx7iE#m8~>=m@b~sR4R{GcDdpY zRd!MPiOM#Y-Av;f=xtZ!NtR;6Fzwsul|rrW25vnbj&EW0kI=bWZrw0<#e2oFIDRu3?bgjS-9Em>YSe2UD?sOff9}T!&2U9)62Fe`7R+Umi^rD% zzH~MnCY$H0!knPF&6o1U!2b^)BUJ8WE1qP-cZ*?R^7x@p-K!?N3vY&_r~2Hu@q>UD z{8a+OJjC|aG%}9l|D!JxDtE)lJ7SK96}N@8j}-#aWF+K z?(NprQEQ{uWvI5Ga<>$X)cJPn;cb3HH#sG?XZ$9LuOHtSD}HQ10&QyCv8VEQzzygq!qdmC?nSuC zW$jbcYxvru@_rG^krOK!GD~TIy`mH2KR*68(b)WghbVs(IzS?4ulH0fl9A>imLmp% z%{+r?T{S<#Or<}`CMv4^5cRi+&Me|_#=~Zc?AOcK-BKO5fp>O7MA1i@a?~aKc9|gc{a{eDBiuWeZb&l3o$2pmG-!Fe%fRZdad#J(&q!Q-~s9X#6#X^h;K$ z^v6yX!le^r=DD4jcno9o6r zB!pGJ%MlkMIt6ED^#Og}eL@Gx_Lw`jTr(b^PL?xDAx zUfChq^bSpouDYZygym`%Lpp`zzqYCQ96jc*Ls?V|GVJe9@v#mB^f%q%l(%u*wu@7^ zWH5xy`=5+Afn6cHafRKf>RzX*B(<>*;Z!DS?lD;cTzr<}*(IplE_G~sfZVG`r#!UV z$c>1ry@nec?@9PYN3)O+fiB&F1*f~Nx^w_z+*UO%u%Ywqg39}tngj#k6mLmlc8$MP zJFnGDvBx1}ikGz_)n4alzj~C+vaZ<4;pktDFL)~D*MP4^a+rpg^R#cDg2)5A1%Az|Fx7tXt?9q*)HrwPl za;wQEJnwmpUQE|i9))c;xh>IFNRAmDa!4Zp$c=dxMlJQ`b)FHV%}j`Nz~Xo(%_wR~A)4uyAe%tLwi0hGUW_uCRDbq&P?h`WkX@QIVoaa_6AD9! z2_IrU;t)G(qJ3n;{Mi_~VN=C&kV+Ph@7=H4EZqbjGJ?Ey&00rOBwO50#cfc(&cb;= zN=i$t%Wzt*+cxa9qoOPagkg9Q15IHrkMkqrx}ugi#>R2`1v@hyb9n^*an6ph1MZ1r zOr(}^m&QaEaiS!^kD78NV-1yYoT7nsvc4Wb5g2uhb2hpysqv1iqH{H6>R1i4Mm<_2 zL6%^G``}f&D24VzTfNJOX>vmDZlj*(5uT|v7F3X{h8lPf=0a@4Q|8_iVrZ!UnD?d{ z^6eAuPxaXsE}9%xx8NS%F6f5B{h&Nb_W9RK?7c-qS zLdQE%K`u-`KQ5bFd9231PEDC?;kKaS+$l%gjQ?aZiA}}9wNMR;QerWFy*ls~m!d}} z(ZcCvloEYZJve7m9yapC0>VJ9uG8SG9m$iTgC^W_CU4L9R=11^idr?%LyDNyIZqJj zPNOoX9l0rJM5a5X-EN#W{3tiXd%mf1VD0Qj=Hnj z1jc#cx?MV|PPb1z|Ap>Vv$|lfo<=^$H++@5=oBimsiv8wgc~K18@P%1&oYzbO?E1XzPIx~cWiUUnl*4JHb$`>#w*e2S{z+STknEp zSb+`<)uWY&P`8a!lfO{~NJ#6A2^`D_Hm0MVTZz0Rg$5uji&5D|29^-pbZR!FPV<{_ zz)#V62KjZhokOF4b!f28++M=-ZjH8U@V`?u&;a(9&#rK)u_^}S4o?P6(HX~EWyNGu z5yjXX=`JU>otmZWx=6TPi>O8=>?=AcG$+4OPg0PKKE8=CNB)I=`KS<%b+5>!{0WiE z7Qn!A&E@vg&)H~htC_GE;~&}Bn8QU=AYLo@qO}!wn=YY;tc3R&Z@GK;IU= zKw7l=?ViNa@U<}1#NE-!y#6E8%4V9HC!l#SBtBzZ{K-O}&__NhayQ}Q)5=ZIM?Qy| z>IlxRb8U;n2%0VwlV~S!IAFtAyElBDYI@$sBesN2 zEnfM_1!_}flLDKFF; z5_~(M4{kLBBat0e9*14z)@et~W#){GvVg7SU5ISzSHsk4 zMvK$>r$SS97#ld+=|~NUcps?x?c$W*40Dt*1*Un~xkig)QhOzd^0Tyqs3GnVua)Ar z)uUaR+K%|xHMtb=cvL+zl{!I~Tt>aSFtQfy4=VRSrp-2k>q5A`ss=?lOq&r=77KQ% zS#~^nr#&Qh&tY}r7Lp=oZ&x>dpXOGj} zA(3dRq}A=HmD^;gw#zHSsxQMDYOP@$eN7uw?zK^Gg21ubQ`B**yStB%pEY~Yp521> zO!hV$7`-m$zlW}Vqw7C}{xj;^N6~*qeLj%ZVc8y;h`(*&d&Qr!U=xD$&N1^U#}=Sd zqxS+T4>>X_$hD~|UB-}ld;$G;#>aTRuV&bLVcVJ&^l}7mL5!)zQPFG^Ha#9;{m{4wFot z5m`QOb>8l<)~yjaBO>~yF+43yo}Ctx|&+MTI;ZPXZU&cQyuIoAV|FTd0FR$fk> zHx$d|1bu8GJ>g67>YI9rslH10@;#xSIv>dE32kPh3+MIK6i*G%cZy$4K?3s-8Xnit z?}YhEC%m99+bbVpPh^aoHknd>aBndfvXwG{zM|Phvxlaox5A~^x*B;Vpdx`z&h#&5%cOX;YDBPw zCbK+n)Rbc)x)$EE^+7s`n`;Y+MN?myj2>9J2mWq`bmgN3vF(w2YOgG5G7G}WhnWoO zwNaBfH6!;0MdUe>`d*RhgM4G?iG8sgAC`hH82=aC?RG`!2(eGyFUQyFEMg6zU0|h~ z_tl2);ixKiQ|ou{exWf~gLhk@{#~}kduygL;Ds9>XMoL#{oG5I!y81!YT=dH2HSR{ zr6xUGM3s6GfXUf->X>*s&q15|aAn(!0D@YHxQCwOw*jUo#X*{)biVg^IHmGlh6rJl zR;N?VN~@4Do9IW}wyzso_j$t}f;gvEaUdt)ZU!bnlCtVE9>iVl%588EdY!AyMn+9n z+->5*KQJC-&{IoKUiDnpO}#pnt~0)7;TCjtIcJ`An7B@HCiIFuLa&blnpO8lX9k4j zB}7x`&KDl!q&ed_Z`(zdrXcdxaAEwxwEOmQ@((IZ`BVT_HNPVsU{n2XEg*YRF}6Mt zOTwrEoho%$hjpcMbb5;;rF-P9=p-W@tdoq6A{2@Fb(-7ep}ms*p28CR!(9+@6g zK1fdQ{Y?0ghT4tlk2KVZ;vZ?KmAD^i2(T&^Vr0VNg-Jivpg=%{J&sTKl0WktbqcX} zR%(l5wX(=q4miwSb8w4u5eIX!$8ROl`+z5hu^{AtwKy`+t>aH*)mbmEI;T2jx#xf= z9>gCz<72yZ&ZcSKSoXc2Rqv-*P?^Q)X&4TVd|1Z5~fH9SZV}9o1)*Mj( z5Y@Se;uPEcx9VSnO>6L$6&8Zo^#VnmJ;7G%Opmx#H$YD0l&g(RsnetqJ}2|rEL0^0 zi%N~dsEqAir>s2c6s@mZYo>?I%&$SdnT6EECgWI^pw~Vhv6BOPFYUdt?sZ-!ZN7-T zV1xYWMPC;V;;=0rz40l_CWvedJ=Nmy>fN#w=Dm)#dOQoIU6c|t(C}**(jC%tlivb? zZ61Zjri8`Hv9nVDP352Q!x)NFNw2W7_?@*Xg^jG*U~z@FFDx53SVUEM^|2HD!``Ua zaf@xZGekQ>&XZa?RxKeD#96-j^BVioMot_}ZCl(zk{O?gYf&{xXdMAX3cjD2_*)$D z?{GLbPgBuGilrQdogRCLI8Q8_mF?5R%6;0QP}S<6Y{B4;&Am={EGw5rix=-%D4(7b zf6`kaI*6KCmr9Via8>JUPHkykA?TPTeXGGBxO*=E3P2Br(R9q`eNJ{mgBmZY&10sp zyir2p(O_(%qp{-axLjywMzlAYq#O2O+*z%j&RVp&_6WDe9dtXsnJG%kI<;mZWUt-( zwkBrPlZf`A%3DsYx^2<(68BgI&Wz*H@mnWVLfXm5EYA%Mnp+M!Z;ogepgv6EUT}d$ zwNy+JG9+in9wa^Y8ypgJR^=b?vNC()%Nc+=jZbH{=@zQwZU%6y5Ie`{T(fJE>X=RJ zeJQt(R_KgMH3$mxOc}7#=|!94UwCr*u}MUo_ma2w=MAzMU`O5*#Bpgx)XwN`-CXV^FI~THyZGhXL0tYYKK|9w$Hdhd&t0g za%X`Pi&WU&Q>E^if;FI`-izAm)VVagHpQPic+vx1VE|XvRzJ12#)>sejrGZsWPBG= z);?;vUNIuvo89?%QmpCusbJ?%i95adjn!K9ih+pjLj3Njgqcn$8R-DM?QFmF;tZWQ z+hXV}UmRku0+_aj+wGpyBt}K)KGWBFD18&`tHBj-^5#CMm;!WNX@@GiT%57)tqIAG z%wXKqg{qA5@&w$N-gg%7n?ASoi22Bx1Xhi#^pf-c%vp5WnJq#u*ux+Uut;pjDE5Kb zGjjb)DZJ2!ai`7}c3j#|R*m*v)-;8wHXAX3tdg1dC301SU@$;JRwEJTDAAL*J3uzb zOHF*@t)0G^TFo|k$2Sg@)!xA~9W|vR!FzQ*P8r4$Hc6IcAa0xG;R|j5Rd(NnokY$lFH&c%2&N4a4+vR2L)iKCIW24)iLZ_QON#_vvOQAm^? zB5bN@4;Qq7u#&dwOUzQGJY24$*W{o1nLs#aA2gW;l9O{MUir$bJN6IbU{;e+%8^pa z7M5|NnmA&^rrdiMW1I9#LE;i4syiOr8!cv2k&n9H4XWJkUNu&rOk!L6^&t3lm;HXw zgwu%x$dOumYCB?j$s|h-JW9rU|5eh(djo|T<{?f?oKPI!RG%%Gm2&%1ec&Y}V)7-Q z!TbAS7;WlI@z%_`u^NR!M6^;?n-e@cY3vJZ@K8r zNS&$VLb^A5?4<PG{JV@T-WXHWz z=^r^d7EllId#9$nkVSF*_;sw|P8L^_4ey&fnb5&Tk1|YTC8@@T6lpNgmDx86;S}mX z>=9P(sh49PxS#Y0z%8}vGPp@Jd;-GJQ!9K_PUwG5tegMiAF^N-rkaHjHVlSsLfLnX|SI>D~o89b` z4eMkZ5D<=37DnC22+t8p<>v+L=cX$6L4n8dPz3w@(J2f@{4!Pib5yn8oZ460hM%4C zmF$v=^RV{M{>lN#n)ez2bMj zviN~P&;RY;y^_Z;K~fr3i8mCob+Bf99FXzQ?_$XVbiQySYrptQSr+oW0CQ{9heEv&otKcr(BiqE!jz($1sfwJ8h0%6?yR&wfI4<7k^QUpXSl; qas5TVs8v0*yF)oA~w*EKAKjvEi delta 7909 zcmYk=34D!L8prW-lZc2|l8{KENh}dt(j>Oni4+kjA%tjylG09zhQ_qi?V_p%Q!bqp zt+tp>O-skMbXq#qnlY-a>B5w5hSJ4!Iw(Vz>HPlpeKH^KC(r$!=e)}~?>Xmv@8!Qc z!rndZ^M4u_vDUFo_Bq!YTQqj=BITF_)jId#b^Gi>^`!@w$=!)%#Nb?Si!EowZU^KQe+nL#BZ?n)GWmcF~<{Wc@ zxdana&+=}Wz(A;Cbg6hzp%s0)W7*G94)QEhC9WXZCxt^GhaafH_ z@d51Or?84bEbc=ca0D4`cM8>zYZLl&jjxVRiFDt-jww*hnizBlKqvaHBx1HjqSf1wFVx- z`M9DToz>YyP;&%qRhZ1 z*w-vF%QF~%ExszNxD%E8QFHk#Y=9e44Q)YnWIJlaUczvE1J%Gm^Qd_mH6rIx$6rCs zeK-q4#`&$#26cfPR09K07anGLF-DS?Sw0DSkWWW-Y#mO(&B(O7pR7JD)4P#Qs0RCE z=Q2s~7S%<|qdR*SibL&BLp79%S~ES6b?Azah3;mXtIgf0$Myua z(er=VDq3~%=BPWW!6DcPD^M?x=~#>Fk#*$ax-t!zkLt)rs0*J)4gJrk_eoNgSKk#I zkPkM&oCw4t$Mj@B-@bZIJEdsi^DZ zqDFcM>W0QYivrsH^*!EFlzt%*aSbp z7(9nJ;}zV5<8!@{_#V~aggnMyh15K6?mD3Epbu&&OHhyDZKzl3EY#!mENTc3VI01P zL-7o1&bxMFUEpZsrRnBiFAU&7JdCe~an(9S+8p3{M9vN6vMN zP>XB_X5!zGW#oQFjbLZSS5wo|9E_?TY54@p{nIEkXGgVF+=ng6ms|b}YJ|3-hIlu& zz}HYCa1?dnPf=f5U!z7Yira05?NJ@;Zuw-?@zux_`P~AmSc;m{H5iMV%w6U|RD;J+ zcXkTn@f*})^W}RTPez@egSuXUS&BM-3aVrCF!cN{rl20Jumc`PM%}%D8i`Xl1h1eL zRX-MjI#7hl%TSNiRC5NZqq9(JrxtbGJ+}X0a|JeJ{kZ@I4efeW;11B-9N|L3MO`f5u;TUTX&| zM4fOys(v}@g|ZsY_?&wRXOS=AA=VIohY2`fkk_Gc$e)|eM;30uvG_h}1TuM+HR466 zsjl!_;TH3D)MBi$e37{X)$^684z4zzFn?zT%~#Ds<_G3y=GUhGk`-Km*Q3T}JZcD2 z%=V}bWSO~U4^)SGn}y~m)YMjB2F^ykz}6t^(7l4ZIsNW31wE&YhIosk6>4q@@j4uj z<8U6Tp*OJ&9>tFMA2XdtAcedLwZF>phmi-wZ8ASWbtv%${RUzF`%~yf#SBzO)}wm9 z)qK@_57mLQ_$r=9ExH$nddKfG-!;!*B>S(Tj&sAjya{TGTVOQpyL1ZYunY1<0(ECi@F5;y3|m)YEXx_J3|(LVXKH7JKI>p&rY&W}aDq8j&#=jT4I*|Il+t zg{(D~qFyNLP$RG%!|_#AL$9Mcb`;g&f1=jNB}~KOkhm!M3orslSzd;E8m3zPy{PLyVAi3o>)&RD z*HLqF40Yl^um}ExnzL?WygTWGgUAa|4L^uU_$X>hwxTY)AGH{dVh&zJE#mfLJ!K!jLseTDnb|7~Xy%EgB=A?P3 z4i7;cUx{%zA7gPDHq-OJfkF*FkB?wl1>acs9BP$*k0&s3lDDWXpf1$#CjKeL9Veq6 z&xA^EityrJ8=W5=bN!B?!sPp3j1L4RBtVe z!@lG^DLISnFzXiYsVK#^53w`qe=XFpE~v%b%Pg?^k}AeO^d_>3>8KHy zWBL8ql6-~bn^4d5cGM8>!4|k5^&&ckYVb4E>OY5ini}2ey%94|9qVEF6h8%>FbB12 z7h3)ZYR=Z87RzRHxA|98gC|foa2hq&|3WRcuo+&*Q&8vUqOLc@9D_REKb3;s)pwyT z_zwOIF{)yccS23s4P}Vhm12U1v7x{9mGu zzaMo&%h9hpSVcjLWG(8>pS1&CK%KC|>i1z2@;A_j8s-}aHS#=Bzm>4Fg$`hQk4T_A z2mh-I+up=4HUC}gz?<=QDhJ_%IGA{f_${GLL)(*m>#-8GX_&QXB|jD_dH<1Z#n7Xx z@(4R#<*}5Ps1Vwi|DUa>ZzpXzcJK$3^>SHFtR;34gV{G83-CB+b}EA%D~nr5|nB92)3MI6As;lxbJ3y4f2jQnP- z-*!;=iO8t0z@b*Yh+ByEoHGVnp5o(PVltu5{F8_c_)_BiksOjwR1o{At=}e+k0be! zxSsOIcpLFFF`Ll#6``g4tr9lg@1bocpJ%Lm1Lt<9Jl}G$*UH^|bmlq^c+DzOC^sRJ z$@f^@J2;Lyed}u*W^SNdO58>Cr)~;fBDCE@45aSgxQ)0%T)U07Z(xm~cB%AoD| z2X-KCCGI9>5PG=u3etC)wjyFNagInOM%i^5U`s1+re515@{v~83H3c2rCgJ-k$8eg zBNh_c%Gf!C=tub^5kq`Pbf)fWe1y<;z{Bw}an;0hq9gHVLfd`B2;u=Ensc|~4@5J{ zFQGq`LOOAjq$6tUOFTrpLiDEYZETGnVf~gwVHnZQ&QbjkB9AFf)i9tjgVggaW={L}|+uund zsQVntH2xQC@3ZDsX(zo)v6a=Iz)nPKg5PkimmRa4vbI?AU*n_1DxyD8zvWSQ*^*{> zi12azKH3lcGxJZlh|rcz%nOygk5(Mmfyf}Vt?>wbM)3JJ%QxX4iRXv{s~cnIv^C?X zZ%ecz$_amCc6>vj5a(k37EWGC(%dTajWD);r`Z{=TDh3x@1)$*a`C#A58`J;IMIgV zuGzv|PUtoCyKCwaIiw-6j=EZ+f$dv{H&TBV6N#q83xu{$JwpGsxQX&#iI{7enn3w4 zc8pj`yk&WB?=j>*8LT1_|3!4MT*O^-v0Tc1ugQPI{^i69VkMD46tTZ4(VXZ(9Hy=Z zkxOWsMBE=L=~p--JBp-&c!u~T(T9^xV;VNbeyFVxX5p+*#?Nwm+{yv7Mh5$*Z;S}; z&uHKa_Q{M73#4~W2>j6bkAa?9#lf=dm%;)md6NT6^Hv5@yVd$~0(W*x3s!d@7#6tL zb7x>#ern)I{)S*--$-AR>gqdO*rVU+sZ472 diff --git a/locales/uk/LC_MESSAGES/messages.po b/locales/uk/LC_MESSAGES/messages.po index 6d549ff82..a173b1341 100644 --- a/locales/uk/LC_MESSAGES/messages.po +++ b/locales/uk/LC_MESSAGES/messages.po @@ -5,13 +5,14 @@ # Sviatoslav Sydorenko , 2021. # meowmeowmeowcat , 2021. # Tymofii Lytvynenko , 2021. +# Olexandr , 2021. msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-08-30 17:33+0000\n" -"Last-Translator: Sviatoslav Sydorenko \n" +"PO-Revision-Date: 2021-08-31 10:43+0000\n" +"Last-Translator: Olexandr \n" "Language-Team: Ukrainian \n" "Language: uk\n" @@ -229,6 +230,8 @@ msgstr "Читачі" #: ../source/contribute.rst:148 msgid "The audience of this guide is anyone who uses Python with packages." msgstr "" +"Цільова аудиторія даного керівництва — усі, хто користуються Python з " +"пакунками." #: ../source/contribute.rst:150 msgid "" @@ -236,6 +239,9 @@ msgid "" "share your age, gender, education, culture, and more, but they deserve to " "learn about packaging just as much as you do." msgstr "" +"Не забувайте, що Python-спільнота — велика і привітна. Читачі можуть бути " +"іншого віку, статі, мати іншу освіту та належати іншій культурі, ніж ви, але " +"вони так само заслуговують дізнаватися про пакування, як і ви." #: ../source/contribute.rst:154 msgid "" @@ -243,6 +249,10 @@ msgid "" "themselves as programmers. The audience of this guide includes astronomers " "or painters or students as well as professional software developers." msgstr "" +"Зокрема, пам'ятайте, що не усі люди, хто використовують Python, вважають " +"себе програмістами. До читачів цього керівництва можуть належати астрономи, " +"художники, учні так само, як і професійні розробники програмного " +"забезпечення." #: ../source/contribute.rst:160 #, fuzzy @@ -256,12 +266,17 @@ msgid "" msgstr "" #: ../source/contribute.rst:165 +#, fuzzy msgid "" "Imagine you're working on a Python project with someone you know to be smart " "and skilled. You like working with them and they like working with you. That " "person has asked you a question and you know the answer. How do you respond? " "*That* is how you should write this guide." msgstr "" +"Уявіть, що ви працюєте над Python-проєктом з кимось, кого знаєте як розумну " +"людину з потужними навичками. Вам подобається працювати з тією людиною, як і " +"їй подобається працювати із вами. Та людина спитала вас і ви знаєте " +"відповідь. Як би ви відповідали? *Ось як* варто писати дане керівництво." #: ../source/contribute.rst:170 msgid "" @@ -294,18 +309,20 @@ msgid "" "When giving recommendations or steps to take, address the reader as *you* or " "use the imperative mood." msgstr "" +"Коли ви даєте рекомендації або вказуєте необхідні кроки, звертайтеся до " +"читача як *ви* або використовуйте наказовий спосіб." #: ../source/contribute.rst:0 msgid "Wrong: To install it, the user runs…" -msgstr "" +msgstr "Неправильно: Для встановлення користувач запускає …" #: ../source/contribute.rst:0 msgid "Right: You can install it by running…" -msgstr "" +msgstr "Правильно: Ви можете встановити це, виконавши …" #: ../source/contribute.rst:0 msgid "Right: To install it, run…" -msgstr "" +msgstr "Правильно: Щоб встановити це, виконайте…" #: ../source/contribute.rst:198 msgid "**State assumptions**" @@ -329,6 +346,9 @@ msgid "" "that covers it, or link to a relevant document elsewhere. Save the reader a " "search." msgstr "" +"Коли ви вперше згадуєте інструмент або підхід, дайте посилання на ту частину " +"керівництва, що розповідає про нього, або ж на відповідну документацію " +"деінде. Не змушуйте читачів шукати інформацію." #: ../source/contribute.rst:213 msgid "**Respect naming practices**" @@ -473,7 +493,7 @@ msgstr "Огляд" #: ../source/discussions/deploying-python-applications.rst:18 msgid "Supporting multiple hardware platforms" -msgstr "" +msgstr "Підтримка декількох апаратних платформ" #: ../source/discussions/deploying-python-applications.rst:40 msgid "OS packaging & installers" @@ -485,7 +505,7 @@ msgstr "Windows" #: ../source/discussions/deploying-python-applications.rst:61 msgid "Pynsist" -msgstr "" +msgstr "Pynsist" #: ../source/discussions/deploying-python-applications.rst:63 msgid "" From 02171143af8e3a4f31c4d25573bf6149c9b84e98 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Wed, 1 Sep 2021 22:29:41 +0200 Subject: [PATCH 0110/1072] Translated using Weblate (Ukrainian) Currently translated at 20.5% (467 of 2271 strings) Translated using Weblate (Ukrainian) Currently translated at 17.9% (408 of 2271 strings) Translated using Weblate (Ukrainian) Currently translated at 17.4% (397 of 2271 strings) Co-authored-by: Sviatoslav Sydorenko Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/uk/ Translation: pypa/packaging.python.org --- locales/uk/LC_MESSAGES/messages.mo | Bin 39294 -> 63748 bytes locales/uk/LC_MESSAGES/messages.po | 260 +++++++++++++++++++++++------ 2 files changed, 212 insertions(+), 48 deletions(-) diff --git a/locales/uk/LC_MESSAGES/messages.mo b/locales/uk/LC_MESSAGES/messages.mo index 0a801d8382511d8aa847d86beeae4a1a1bfec136..f930fae16986974a6a2e6c758ce6a6e9a3a60639 100644 GIT binary patch literal 63748 zcmeFa37A}EnfHBE6h%QmMO@HBkS(ODyR#>TK*$1-B*b(Af=jx(ySlqbbyZtSIvrpP zAd8Bi7~yqc5fry~lqHZrNKhPS9B1q1opDCz9mjEI9A_MLKF8779N*vnzMpgIRChJY zT;KOy*LPiCUpe`o^;z!c-k;~x`R?&Yd^Fqj z3;bQM7yLKy4dBMpqUa8=489CJ>hvgjDfnto<(vY(3OpCo{TG9;2Aklq;0M7Y!8-%q z7w}7<%6TLlKN;|w;0rka6nGT)t$=?O@E-&IGT`&i@cWJqcw)d)0_FoQ3%CY6l5#H! zcnSDoj<*LK0agFI12zLrfNIZG0dEZW5%3k9zY`Qa9t0s(^he-g@E73mVD8K)g5=S; z;91~B;Bnv;pss%qJPEuT{4jVJT*z2$p6m5q$3y?b@rS^ZxqfvniYPj|H{kDs8p?kG zb^W-!A1?rxaePt0_kq9W_-o)Rg$%mJ>CeE8;NOFP11{-~qB-E}dz?P!fa>Q3py=?9 zfWrZ60j~m!T)z=~G58Zu35HGZD~$HCtOMfXz|dU@x8y1pJf5qvAy2VM@UJ--*u|1tO)j(-fk1Uzz)*LNH! zex3&&2c8F>0B!}6b3z^{Ps=lV%2yg#2i8+vp6AXw)5Z>@BC^qdn#qZ}V`uD7=azK!Fn zK+)-2p!oeCK+)x8tNi>4p!zizjKO8#o50J!S3NI^-UHsr@kh^d{#&@(aTTa?HU)fJ z!2W>cfI9>30sn*h-w$dWuV3SIx)m%_&)uNteDpf!rxQW(=UhQ*TAe{d?_$H4306Yc!S-=zC5=D=3yd2c|e*s?yzUD&b zk42!4F9F3Dbx`$R1HJ_O7>LM4_kugY?|_)V=&c)~=pJw!RJ&ih(fd6IRC$X)(dn%q ztQ_qCQDM>Nz`5X`gVIkg+7v~ngQtL^+l8Q>e-|kE-VKV5d%!n>?*oqkKOgWwz~2F- zm%ara4gN5k{{{Gcj$e3@)BA_uQ5^pqRJ(r-o(3Md+3U}PCvv2**KfzBfcJn;ft5b!%>Anh_*NW`^n1PA1{~iB{)+QOP<%ZA@w&lrQ0@O5D84xe zYP@~`s-B~1)C<5f!KGjhTm}w-Cxdr`;-4o$mGgTbB#*uet^*eixm;WUiofmx=YUUu zOTh1g=YX#r_VO+RdpN!lTnBy$gq5Rz0b_9W2)qjpf~&x~)`#%Ee`OkyLfCmG96V(0R2GzbFgDUS= zpxX7Ks$V}IT*&chpvrqYxEg#nsP;Y#s{SX#@gIOM$ESfuaK0NZbb?{{H`E~c(-xP2&sPVZHR6QR8)&Gx!s{bzVMd0Vc@s~lh z^8k1Z_%%@VJOzs0-v?FBPeDEZZ=mjfe#6T>8dUp_2Q|(ofNJkNP;^)cs{S>go?9Qz zZv~I$_%iTs;o}i-6UUo&x?gn%DEhw?Mn2R_29W2e-zAt-vWEVBPN_K zZv!%HOl%K`U;>dzCP+WWPDe;DxF0ski8PXqpYz!&cJ=Z+2d zx`3wz>;cuD6#>_PqU(l$+d$R-u7Ldkhd{OG@_@~Nd%#z4{sZ8t;9a2j@ay1m@E^hB z!PBpBx-AFK;&?r%acY9nJ2!yaz|Vkx0{#d1W9UA0rPuq!Zx9C|Fy92lcaL7}ao(Q? zJmMPHTRBkI*N5XB;4+SH2>4a-`sYzTsPWIq-|%Q{czA{u|f1o<8vgZ}$dJ z_TlZI`g=vdTLRt-iaz_n!{C#k`1k4?{r;N+-V^WK}~WR4&IFfhF zQ02dNuj`Rh0xk%+8Wi1oL5`25?V=&KyR8axL4 zHYj=dA*gozBX|P%Yw!(RIN^40&!Uezf3F0`xV{(s#`DoppK!kV!#gOCTBr4}%)NJ>cuXFM!?P?|_TJe+7R^ zxm};3jU2!6v)=zVe$KHc;Oc&j8h)l>xT|90Fg$ z`Q6~l!1sa|(~b{=M{xYZ`~Ccn!Pjy8@1V|~@PL>5x_~|4`J6u=R6Vx@ycg`HzxzRr z^GhFcKAHncE^?sCy%1ak4uh`&?*PSj`$6^pFnBKb+o0Ncw^z~i#dJ*l-&FRJO+HpA(xXAL5+JQ;Clmp9L#b4e(*%_y8(X*Dz9)X%J($RU-g8K z%csF(IsP)Z9{dXUTJWf^`17ZNs(&ST9Qao7<=_CQ{?x&bfIk3-D1Y}?u@4;o)sxVf z<14;KZieG8{uW~epS|nr-v3Yk4(GZ4;%^|M;KAP|cICdWev=#lc;WB4e0~!A4#$sz z=WyTN-$$2&fBXl|XTR}BJ|0g^LSydx;FQbJNl$sZ=Y#*i{cFKfxZeH8*fx&0g5tx? z-*SCg2E{)&gRci~10^R9f#Qclpy)pZejofENY|pT{VDsDcf+4?jpGp-JCEb#e~!-Q zc=&&#cRBtH_#5EQ{=)OI@BT|@!EygzdA(nyP>sXyg7UY%1J2|4D}O_d8T>K01l;(y z9uHp!_H+EF;Bs*J4_tnl;JF-M3BDOT1ilIUH}Iw48~)DwHy4ED(fQyy@VFm3eclGX zk>e}DIp8Nj)%yf^4){y(WN^vfyZyWr)bk$zH-b-rF&O`Y>)}=4DxC*U17G+e{ax@V@J|AMFP#5TIR0fge*RCLe#d}%?v0@24a3Qz}Tm)VVUI;!4s=Y7#xz~R@sN<8s7lLyGc7rN+G57-T z98mYI4%asayciUH-vNrggWuC7f1!%g5>;Fkh^2NeIj=wF>4b3oNU4^;g<;ETZJ z;dm9OcD@DFIBx@0&mbszH$c(#YEaLA0Mz|^L6v(KsP=yvl>B}U6yJOU6dk?;>b~!R zdhTz-`F{eB=J*%j^FY*;{e4OY{M`qh&h}6^o)132`CZ^!*d(+2KM{hfpT|9$@dY`E`M_VZz17eB>z58Kjk?hyNn*gnse{QZw`?V|yuSMN+N zf@|1h`)>zN0GF}d%>Mty*6HtcT>ml``q{d|4dS)z-#YI39Gm_o*e+-L3ESSS+i+ffM)LQXu=BsbQ#gMHSPAF85b#mXKgj+@@E^g4*&bor z&n92;GPax8pZ<3@CvxHBH^95NZw;INP6{X)(%)LPAK9M&hq~zaSLeABS59MVvR%aS zC2U`1e+<;0{2IxW{*DgkR)doF=Yb8of^QvAZ~~j;TC#Z}_iSa8e(7Pmh;1&%zYpr~ z0`~QHA^2OqYjX?oAKu8eC7hcASF*i5+`j;njvQjUm;HYOf0HfwJDzh}Ik+P^0UqGo z`@j#d?O{8c;}5Xu?@a;y$m6YH4tBH27s&n{$HD*P{y)f^{Ap(YD`Ees%(*Mszl!ZQ z*zOK>{U!SkvAsH}8{E#Z{yxM0k>UJX!JT3M5B+j<8TdiAH?zHsYuAPAXL4L%|7!3F zHvL`9HpuoE+jVUBu~oR|v*1K{j@{_XVSi5M+{ZcpXS$gAJA&(TIj*sNBAkB(cpKYd zwj;wif&AV@Y;R@%_t;*_c7SaMTbXT?YqzqU&A$HL#dd`4x$b|QYdvi5=G^&g7qG2o zJC7~Tb}8Ec+xxiZMz;5}ufGj!huLDbKVdtUZ5P{_+>>MbAlo6fZ*p!0nEXA;&YQ#W zCidmeJ|BEhICn?D!GL=1=WNT_e!+GZoBo!t?dF~ru${&JRp5`ogWy}h7|j0N!oh-Y z;;3+~7H~f}&bEx}f5i4Hw!dQ2oaHF^$86cZ^_;(yO@9q=TiEwA8&esCq*BWxwMv)EqC`2yPr+a``b1ilhX{%&CB?QFjr zPW%IS1J_>_js-=IF9G*}pJ4l)aBZ0Vli9u$j-Lci4EtL+ufOvGYJUaWN7>Hj+|R&& zW&3cr{+r;3IetBOIosc`e;l|O{5sojv+ZTm-zPc$ezsq-e>K=-E3*H3T?~K!ne2c^ zhyBIecN1Ik_Y(I1i-U{7KL>AQ`y$(_aL>osPyW8Zxle|JRp9Y#|C4Qi^T&e!&h|Do z{VnI*{cP8;e=Xa5woh}smM!~tF2~z5=e`#%-psi<>^}y+0DMn4KM(v6=l%lxbvP$@ z4d-6V)*a5B0=|juRJM0;{vh};ct7|8RV2*>Z?+FrIR*rL2%U9*>tABk}T~Qn|Ri zuQ)uMD^-T7eer0qQ5Y;V3i)X6+||{}aIMg2@?5D}sn3fis?F1P7Ly_d<3eRH9xT-x zwNihxQRFz@Jkc1bR^qW*_449C?=QYO`LRm^+utYfANjX1%WJc(zb0#zR$3P_~!4vou($495f2(Xm=_q*$q!XpdT6 z8?{Eph5l-@K||_e#evdLX&`P?$4UeFc>R#Io&qm#)*Er7HlcDFRT|KU>y75nP&`A1u~#m146|E0k%-M7d~}FR7Jyi1sx` zigAs4i#0o6EYv5qmn!u}pgA6&F}$-Aj#1q&B0UN%3Pzi`2Vh4XtBMe`T; zEbH!Gx+q$ZU(B|IZE3W4!P1`ji{{U#)k~Hv<%Wfem-a-<7B5)Ty?Dv|?gdfc-;Jv_ ztzWmccWb^>>Fab(3^NM1){~1{)~;H!aczEdurEHNUTieS8r5pK9xqs&UzqPc>&$7l z)#?rI3%pI+&Wfuw7$tqIJHI$Tf60u;8oL^4YrMkraBL!oNWM`WEw?vf;evd3wh>lQ zeqd;rr^kw8%lj5CSlSo&Hpj-QwMMiYSz6w=u~}}Eay#KiL?>SF{88rtySk`f;UyoP7H_K<9U)dMK@&gDoA~#w^QtGAAvGT+`lSLDqLR?1V|1D)kdMejIbf~$Wo&;Dy33O+ADco-YC{a zm-nTraRq9~m71uz*)=Al8LCxBlbbhBY+fI)2s{yPf$*pbamwcPXL5hDuF`8Q>L+T6 zae|^~&q9;&M{^Az&J)=t(R-sNVPdUf&wa)%amCgF4CUS1q3<$QYR<{Dj zs^het0b*!M5W7|!E5iq9{bFTjsaCC+3^Dfg!YD#t+%-^c4i@7p#tMy|s|@B}73cGL zSi!f^6^%<4t2s-FQRcV+r?cBk+iDx%3x{8oSR0xg97WS4PB2THCm6)7{IZq zmT@!A-?sitNv&9`4|l^frn@jJMjDN=`tq)>F>hpE=AZkxtDY}aSN3h+ZjFFgrlU%HPv}$m$B*%l6){1o#fO__%*}lvPsrypn^g5k~M2RyaR;5GE zqJ_#tyaP2|iOa^u^c#Cb<+xvTnmUK1mee~sk0(@*N03nYZRMg|MO;brR|TVh7SwGQ zY~8pa#&;V-vJ<-W<-4SU2D?TY7)eYMMr@!_txe?POT+V3)T9%!kCKYJ^5Iq)8?|_6 zsW@)e&6!ilXjKip zVQd$zlKEn=$Es+ixMc1u_Kkg-D-OY2t7e>U<6r5mV4cdP{#v1iA&Fa@Tg7xx9?on! z6ob{}(W>TPNle4eu>53iTe?r<(tTRj#A?(6JZ16hgd)H5!Hka5?!!U@Gb(6_CCd~{x6ccD;=&J&kf$tlN_t7g-q^CsYW zY>7goP`A2uB|gHo^RM)nigJs)6hJuh4OPoXl^PUp?p+6S_N}g>`B5Z9WSFFeG(fZ( zt9wyz*Om*`ZeUSmp+ZatR;w0Qj27VrcYBbpW~KD*W>L|JyFT=#mZ&)wC1Rh`8;Gd8 z3-O>RllYKBx}r10(pH(dufsIa&eC1qUlb zrQs&lTcUth&S1;b=|UYVTgy5yFh%0QWZjN>6S<&4?%NENOAWk6KVYl|MmUmp6&%!R zk#LUyjtUxbRcyy&RuykzWn!)iJGp~~A;%OjS{#6~r2#!MHc=}LvkGoC8qP-2<*Z2D zI9@4N3j`OdVLgRni@`Nq*2;%=mPuvqq8qhCS$lqofd z>*`1S<_5P&9jz($mkO1xZD^K8lcRy6f>RgY?9o!L1;=tCzK8;93UPI^T(yWes0=tD z(N?;uh`>}@gyWPNQm(YZ_3Xasz)aw7b_rF0A{39%l}yNPwhX340?N{0(_?o_R7?x% zhpX5!xR7XjFdxG8V1$*B2q}b|h0~0WTi19+>yn~+3s*=*SZq|!?NnN#6(_BPVb-+S z<;KLANM(|Op;zJ{)j5G|vLOgt16LmFDW`+Jju*?Er{}Kvk zR>3b=TNx;f)s@~s@8Dj`eIXc$*19{he0j20Pj~E`yN%8h^?0yZQ&oYU(YjS{jn)pSH7vvYVA1<=PFz&c4L#CC2++h=a zVB=Lry7Nrc*5bat(9-S64LBC#)n<862BuuXEYvZCs<%~g!$yqj=JUu_xJ5vVdZw#Y z8y6I%HsYN<(%7f3I^BnE=X^UnkHb2S6tU^k)d`)|g2bfHS=CQKN>XV~yt5w9K}`+R zaHHlV)mo_FxvRu^9DuV%3xha}T^R8NUENE%OoLA2^RB!qV$`Ye{8A%2zf69Pp^MJ9 z{0xd;`Cs(S=gJ_f3LVbskTfUvyP?1w%D(1NCzHrgytgZx?=vgif4i^(GAbB97 zD-nX4ZVo1fa9OUJ87S0ip@swJ^@#C3Nto8ln2;x=&MFZfV=#bOE3hjGDztpzj1H15 zsT7Mif7Xr(8}34xfeI=E2_nIQ?;4{SYt;gl%}i4}A!M-|P++=BGUGBs8`;@qDq{bWN zYSTPwsY_HlDcg(>GESD0yJ#P7BVoB!DBTpVsnQmtgm8sM1hFJJZ44(h=HerN4LKQ{ zc{lgSUsEC$7IpjK$)Z|3T-urPEf)TqcwG_Z9IBD}#UH@qahFZcCZ2#hNaNKSeRC~K zs${^tTpk%BXFU-s#v6qjYfYSc_p8Lta=QEND(=T%Oq4WQvJ|%}BRFuf;F&-GY+3=G zQXH!y9#kH*8i{)n_Ce{SUca7|A|a6vn}{joI7jP83&SNM??3_CY|X^knx3EcIRMEg zG&k=~@~CE^>gsfbA)}7^4w6C=jZ2}s4MkF>%^|=cqY0}_bhu7CBvmLzx?ZOliUg4o zXu%~Kg>MQm)jlfIDQ^XgM^r$PBp+Wus|KrfjR_=o{lKh-cb~q@f3CF31qTGzpcMVb(LGt}2Wwo(5eQD-bb;eP%jHDoPj9%OZ{N z@`nh}834^dREHYl;@UweY@%x_RhQ~SCmNy=58gtr5ohPy0UT1|EOZNPuQ>q|N+*w~ zE)A1Qu8%??#;a2HQ<}kwQf+2juy5>|lcvYgfW?!7QcEbbGQI+NSP#$p`o?VfX+fMD zHT@MVef)MkpD5LL_Mucm!5)JQx!cor&T=bhQo!!3Cr=e?$)2=GqO04^mBx}ol0uoR zaVCk``G!kIP(|b^4OjL>B(WJ_vCKdSj}V&~c^PqFN5=+H9)tO^*<^`#Iy)BZ1;YuW zq!%XQdb2;*_RtxnJOkWz3NvEkl0A7QY2d9&Q}C}!;pGX8y>jVr&(7e)qTUo_Dc<*d zs8eXTP(uDZ+1k&n;1H^fD$>#?$S@%X_`D3CJ7i{|6R*sLEAhux;S(r|uESWwn22Ly z8>z!RGIQdBTej+SbRpuMndwqp(LaU<(^OD4pLqb>^5B*E{q>1@13h0IK-5iD&=De4q%@N; zl>!ezuF@{XyT+_)43tvMCa{Pc+8C`b_mPK`{-_b&iY?5-v~?{XZCJm0?WW$fd8X8& z4f3wH6qVU44%$(guxzJwUO3G9~fw6oD5b~qoVj?GK6Mkmfz z%HeVrjH}#R7=$?3dd6>DK7jFi%Fas18Oy=HL(MYzN=&Rvg3Fqz4YT={*pz^J?$%{2 zDb#Pa0ar*U)lJ_i6z9K~2^GjTo5#wPv|S7qLlktZO^mrB4S5sIF?lAF!F+qqJGVz0 zEXq_=!mekCaWzh6g8$=tq7BM7*SVs^dQhfxX>;&pqYcW4B~qyQ6r_@zX{{b*rf;K- zsDTC>O18Bdl8YM)%7>bOq`OPGEu3A(Zji39ql zBp(?vb69stxJ_Xum->Qs!5Je~x}e#Q2{KQOl(c8%ll25R0L4LqcR9r7d`j0P^QL{4 zw8jU-@8L1yrM|Hy>PIYxROoCrYe^$2t{bbtdx05>B=wD@%=*uxrTFH)R=`gCAbJYK z9fTE_kTemw-L7o6D+)6<5qw0OisNC>H zUPPKcO+aN1c!r6Ail;s0ehdyGJ#Gp@-qw@+Xcu!X=c2sk&Wi;#7KETGY_~o)A73O_ zW4u(ytVp*^TS~!DRfrwx@my}3P!V9M#*P(Y2lcsWhTWF1+IqAnRG~xf<_3(qDn_UVl%2W?j<$etVf$mhB zp$w%_45w{DO@fxnjW#!Ha39Z1Y+eOxO{81$i=XkHMfqngXE9@i|7KG;B!!hqMC+Q5SuYJ&&=F`X6G0pD z&`8#SAa{&I-0LoJ+;>5V-0lb|nwlg~2?{+K?hks*T{<1q$dqHL5GLJ~sJXV%-89O} z4cfWS{2QD zbj9hym1v9g6t;}EX!gg0()N{0W64ZVuD?XiWP-_7gwIx2A@TN@WtjZgtnSYy+aaD8 zBn_6#Bq0{vmvl_8hT^0P#gS}Lb|Mlnp`9(BaT6l`UUEst3v_aoCu9&)r& za)~&bRlz572@ILQcAY;X+t_Xqx(4v!a>-&(+5cWGJ#>MLdYk=;^670Vr3LkUxtSWD zrb3y#7_?jg{z*eYbUji|2Hi}0W1a%A9rcqr#ezz)?()98#I`oTLMoX$U0A=Vck8MR z8`f@Vo!Yo|>#8-Ywi3W4H*HzF`l2msTE~5Tnu_TnMipYYly9-DlI#Wk{18G{E)Hve z3uPRt#A*OXE6gW|+*FGd3Y@ILC|h1`|CHyD&?L zknSuMVp$I;!W3Ccv!ci{Q@dp%ey%YxVLgi)Of?8XUAnsqmrJXJNr9VN608Po$84}D z*6Qt27zsz25)biFfk`m})KNsr6tWaM(Go&LYGfi_M|_x<|3>qY)EHA>EHSXP5}s2` zlaAhc7UeMYO@mk|$T}SxdCZPxsg;GKd`3b`52vMs+AC2Moz_F3)usZh7+Y&1%aY!v zWnYqfWgeKdz|T}Oj4r3AI>VHbCnVEJDXCFqQU|NMvFRF6szXH%Dw*R8josJ9`pV3N z~*)D`(SD8We1#WeK#JMtL1)hSnn{amG8yptV937+1;?nbOG;@rIU!5^oVp!Euxq@JOw5fJCXBu##WL$lo2Wt0VN@NelLxp_szB{XxJQ|u`=AjW$yL-KL$eUI8~_TU#0xvBds&ie3v9av&CMnW zMCfTs&g_F&MJ8|BBul!IDIcF##0T(cBoh`(RnXu}YQk3Il^WbTA@_j%tU6@l({ew; zM19IUis7IQ*#hGex-OZ-2vqU+#nISp#zN#I4B2AK>kim@&GrZCc_#qYQQzHrJ1+`VnT0} zFWN$#WG>HEMw&5^MnyPUwFMhz-nfynMOc;zjnH?q3TlKA+J&E+Xb|(mlw>;G90gb; ztYvcbh%U#EV-YyS4C;rRfk#gHMA6mqN{Qlz4cJ02$cIXZwk9+8tv!?d#E_~u*_(s` zf;SW5B@GP%k25!IrGZxdggJU?5?=19Fs5)f)0CvFa{Uu{zRb9popO^W*V_{Gu3R*A z&RU8}k++VRO06k6LE5Fb<-?jl=HtG^t4`AE(;VtPR^V;pQPa<@9OpIyP~2148piPK zyF|WgF64njIwj=Ax6&jDs}jt}t7LA&_}7Fu1i+HNS_q8ka2OFN=hI-!y=+qAU$HQ^ zYWmwNOlX{h@vs8Cu9bw)&NvGa$$1fTshzHbCg@6zY*d=!?0d7ZP*RM^WattPC2n34 zn|Epa28%-lmQFw{7ZZ7B?ET zBtbhmZIk>Gyw{q+$}GxRt~Sy*mFNyQMI_OfUxSA`&Tk=q=py%l5?@pA6d5C>{!Ora z$r{?WjMh5B@TYrU%+#=w`jQ>f9$u%lHkePJ*c0!{Y==M~5Ha(%i;V^Jo~18Ix>yXuQUe>h*}Bx$Dp9gE|A;th%3Z-C3+bu@a^XTM($~l*YfLa)%t3VQ zA&WWahx`^LE=8FT8Turv)Vn>LYu5CB1>>VrdMAUoM=CosE0E}dwwBIWovc6%t(?(9 zOL_Pj7;m2nPa_}cs320?WsKywXFClK6nBjjNEk?mXbMh4 zrus`2O+AD#pk-_`5tZB%GP&IElWCYj7806@36|f~cPbrz)z%5<{k5Six3{x76lQHg zbV;p1E_4jklBIN^j9GA5B3p{3b6~d%59acm3AeRJiWC&zb$=hDu5(*w#2q{^)QnI&Hj9JX|b*?KErusOIF`J zgAP5@ADpg7#H>i5%=`39TC2DlpL>=kS%dC$PVO)fqjmEvcW3i4dZRcJQDn1{up_ZA zs?$<#3Urid;hxN^PeJjCKCNgY1RBH?eXDG_Pp`fB?)yR6r|-6nkB{fIzLFH7?#lCU zmmiN=GLX02C}wO-iy4b?`WR*&xo2UD@`rZMdBvjTpwnB%CddHt%UtxD83Lb@_78`$B^vGx%^bDzCoW>v4PkXK>dU?W~#sPKMBdkJu{U$tk0 zzug6~xzp>_4>F7ucC;ST`>UL2HGW;WxNDbRC(SjaqiJsgb`>jKJOvfK%=4>NB`ly^ zytZP?K+}#7Xen+Ux#R|?w_fwnJzexH$-;Uu7x1GDJDRPQu^N!Y9m+c4h;YT9mjy!O zcHzNEfC-T-wU(1Vlgo_bg{7St;_Tqax_HV6YZQ%=o2sFgdhM}NefmzeUj9pz52huo z4Z~dSYFT9#u=I%?FQT8lBPHHtO^MOZEMOily}}aqp@wy5dM~^KPLIv@4pHlIzm^-b z)2;DJUMo$jNn@elVUg;#j1axvZf*=}nu!Bb_~EU<#JS`Nr7fk%-9v6oLvHqbd3)9o zeV_VsfiN(&zbQndxT$x2ucaF7t$wZ7ROphMJ4X^lg+VKVYJWN;CCVpJ8i0thN0O>(4XX*xNg}!}r23$mBvyZzr|7$abh zk34IQ3)-F?%5>1x-*ODcFmCT#Q6$IPblxR=QPh<&* z81#kiIJNCX^16>76HF6?2F+bPMzQpeMS0FL*)t2<@7ca<`-GkGd?D2++7677=$>FV z?7kMos#R{-9%&+mYFk%}!+?CVMx!571 zRaD76`JRO1Ep5fzMAEm@+B$P`G$AUAXM6&V| zqvc5R-VJMVq&ARgBVRf&60yj-QH{*=^Z%KFiTZcfq5aSBss zaHC1)CYe6{Jb`sdo=(5LJ)W0O$V#A#=3peU1s~2Q72M)TZc{G?AxhncNa@a0 zJK2)RF_uM&AK20$aSmNND@hZF1iN)lIp!{yRwnM0;_&dFHO3M}F zydG*hIrGf)J2;MWxk}YDAMCc$9dW0&wH2=n0|VD3&$UY)(u@XlDuOC=GS!XY-EE~k z-M!-@WxJPw$-Z-^bFOH#ClZ^O)+2XCqr~B~9gE;<+VvF$_G43#D_xA7bV0Ee)dxyD zU^O3Lw`d9teQ#{ScTBfM(m7FmXC-2xWS*BIMo5m6r_^tPD0@#*nO}6t80W~;X+#Qk zXOvk*>zZXZK?~80&70Pem94q;gNfs?Jl?jWhU(_Ub{2X~j1|s2Y72Z)YveZ8hf9OG z^P0o;+}7&y_^8bn<+S2XGYC1oEx$azbnU7wxs4a))~t#zxM=yt^=Dmn(WbRW>CJ)M zR{XF!Ayc)sJYKhL!-ja%s*P*;&7qB})^9j>)tWV1*7o+USn4qU{~Gg z&P_g{J1Fe2scSm?dg0{fCm){Nr(0s4Jj`}K72ZGjD1|?)zC6seho`Qy|F51rG4@^F!W^kEjl1pm4?ze&{{}EkMF^6cq{3Ds_~8yT;|y39!^9!j3N)=B&TO}J+2TE=5P6{<5dm@_x|k1t4Y?9gHty_rUR3Y#`YkL zFm;o6;Vyb~qmw0O91l?J{Tfe-zRm8)Dtn7 zq#78T#OVL~zx+6P7o5D$SW5cvF|pQ04G0810|@&p5jJ0?zYKCgR(I86QLwl z2NU*=S9JdENZvgSrGA=HALW4q?H=N+zaWXwA4VTYPOhE0S&WUcL|9N|h(OS=E?y|? zsq3XVDShh3j0#0aZbN$M%bv-Hc-Ce38csea&3h0Xlm@+RzdmUiN6KHyLY+M@bzLm2 z^j_};zo%zEiJ29xnZJh!1s|45o7xli$(T6lpyzFBDWbfBfSK?d!#_w2Mx_tXNOXy7 z#+Lp#th(*DDyMFdHo75{bwC;^bfLvg{Ai`@+2kQFkFLs4J#H2*s1SMr6+%Ii2SRrr zgus+<0?>JwCm&CKVv#aai)-|p?bj~3xIcMFi!`3;*Dhtbu}E!dGH6_C*T_TA>lu*u zQZfuIHZ_vcPd$hIo_q*}&8VXR#ltdTsBx$!rbW+lW5@2@>?U7K{fO?hn^3{YXrnh1 zcGfO;pANlLsmjBiJ)zE;jS?67m@PF^CL0QuYV>Fqx?8*fR|d;RAxPr0VX5nA7Q?SD z*a%azszMOb(WV9T*m^rfmo)J5Ms9Y?(ef0;fx49kY14j@Ovd%AVgGNSLS( zqiS2A{4{D%|$`|GG^>+p-C$uhvUUncGJi=&gb8%w70Xa)f?YaH<% zVUA?JXKJs)i-&{gWHqdY+wE1Dc?g4yX|%z`ZrB(~iZLQ`UCp(ZLfRK^@LwFAycaX1 z!BwCXOd(9;-hCR7hN-1#6NH$j?J?~WD@uJy^Co`oW0E9O0uQ3=xGn`GgDEZw=iOdo zgw?di5msrML$DmavwOBv*CF6`U7Fq07iI94`sDSxk$&!JHCxm$^~@;+EvCx6vy^w6 zyaCQajH$iQm!C1sN0YevJS9`0x{(agP>1qxZlhTUOsBiJHlzMfvnQEbk-=HMlL!<-|tcr70!CmSSPAIl-zw-^n%0+v>38Pfhc-LpIVPBG(ty6 zKkSF-X2BB23_D`KyNbaxa>7wDYnIx6b(L|vbw<&$Vf(E0idrZ>xK})FkzDdKtlT7D z4FbD{dPs+G7WG{Z_kc#I&I9t(1dYKf(ju1>34z9yHEc9!-AM_H5vzFb1$wizGA8E$wh$ z=bx*cyjLs-QPUibMo%_WsfJddWb!^OIWTn-q7fPwdM>|6N{@cf35pVz(%)3MpaO!C zFs*_ncG*@cVjm9>FIaZL6q{0F+|ijkQ7%R^(^FIkW4lT*QPY@8Nj%C;(sI*Emew4}Kw3G^Uiw~f& z2>*z9eCj5Inhu!DC%IDehNc1)dRbK43xX5fOgK|qE1g7?9p{fR5 zjdI&|IHC+W$&b<=v~Cj4N>QM9b+48LAc=3XA7q&}&)3<&Lk z$#lD4rc5=mkNU+7QVVEyjgM5k7-_|{-vKt;&QAol{}?b$CUT%OjH0rPrrT7f#uuWZ zlpw$2Pt-qEW58Nn)>-ipX*=z@`lg-ojg4;E=6s)3_2~LI$tB&dLy<1?h&7i|6u^>|Xuml5cr}tL zM9FCk3*n6~>`H2L-HVcDNisxkD$!v?oMPSUXk1{JX!1ic!x}*9lw%pBRn7{Ma~D)n zuKa%T;mYruu(-NY8S18Iw*zB_Spc4T(8tCC-lPY59;&Gw9uHcMo=$5N+wK&nNUY3R z^e0rSrGzrK%Y@Jjq%im{@Vh4nqsdQFnIsS`pkb0>!vfgDHt1xRHT=@fnX7wka5;xq zS)xZgDJpm1z7V=wr&K(ollD__q70R_|D>}VY^bP4wS0jY=kNvYGCngK1}lo+lu`Dc zasp=L5U-VCgHhOjw8gd>NexT88RsFpRS(!ajgQcs2}SRq5DB`|JSZI*G#izqa@R#O zPRoK&aA@?j`3~b@rE0hV5?Q;D3n>G+vaaPUT!P|q#HP)Bn0nGAg$o;{n7W;Ogu%Pn zHKLdVJ4>1JKBN?lDELWcj~Et(8X=2mBjgGkiIC%e1CIxD(pHY2PJW>w*uY?`Oz_Pn zP!y%WN~Y5^9GV?4hoQsd&~yL&>dAX35Wb&LBVDrKF~T>bi((5UFy+G8ObQBERz6IM zK{rKc!6ed3KIXM&uapWBLJjg#)M~f%?y^EEsGo7<nrI#Fhk^>XAZevGz6g)*I?oepTQpR=KvHm_!cS?wCBFdv5hdjG+^)Ku^X0 z^3fDiDYXae3p$L(`e4vJHAw2i^h3nx-jBMWqJyFc1w0yJl(yrg)2?^=(QiV0g-*_I zv3~cv{fvJ4d-|D0VqTFeLk1_Yd#E-HQ)VSJ7#<1|O)`Fad20gEJrMJw;G*%=jTX1s zin{FLKaEqc=B}5`eKYoxb8L(PQ9CpPtufs@H^-2(T%nmE_EFW=g~PM8RCgM8KPvl+ zx=`%JZ;PAIw&`*hi(ebJX7MYOv)rKHA2+6hdBfbxteu>-f8wOi)2s(jEQt(=0i6Fk z1c_vAKLq6wYDP<9AysSB|1&I-#KVV<0+sIlxb;8P&@#kN9;6c?Y;lE^uH1R{KYKp; zX?S9fsrPH>(D^J`lSIPc(k@Iq(KBqLJAsG=gOKr)I-VBIXEkQBks=Tb)v{&gq-5+5 z^_w{nS(wz}|KOuQ6=SJHf40XyDeX~%QuYs9bSZ(fZb(tfYcQVKZ^epp9+H^rG*9t> z_mI4n>ogw7+D}!e!N#-K5YZV|x(_lC=HVKBNQB7_+d!kmEU_{9XiLeuF*OUI`SV9K zifSdS#)wLz^UQ7VxSd7kad_?2)hZy!8>b$bK?}Lo^42iOlq!i9^U&6GKGgcIb_Gu( z^*pf;Axcr*lrFDjmW33eY^qC~7L$h|(#MU;B%`Fw89$oa(Y zzLQi~*Inl2(LCO^<}R%enoC)d_>`DgqJ=?_BeF-Qmdj}{-DTcXvM5LmNwk%Z@`GX$ zS2S)4q)E*_h<}rNJad6CiY{o*n~*JMu|ujz{)*`e3v6%~kS%w)#OrcXOhf81O|eTO znAy>Qc&(zDq(r63^Kf14E|JzbKqPx~dU0kK;Bk3TaBnDvU<5i^7RX(61y5>&T~B+A z{}yfvq>@^rwdcg4$4z2^X!2ee0vHZ2%y_9YQQ)`d|8aG+G6 zNGqGC+@87;Oq6Wzp8X=9NnrK0g=9yY`(%z67HEFvY>i^*(cvkTEDCZ_<4V2h#4y zglQ3kt@DB}P$6o|)yA$ikRGo)XI8=b3+Z%Zw$9Or2KXWlx+P?Cv~r&+F*HdVi zz09f%Q!v3%M5Ad13fhG3-A=pAvxJApI?@$d;Vo;AgyA@-i6z7c-c$n3N|fyZ<1BrP+xhZ&UQ#YCf)%9GnlM zr25ueTTRr+(S!i%TZRj#F|{euY(uy|*g&I%#$RUC)KZWwv7^~xxJ?c+i}1ujX$z?P z7J7My^@lZjGU^=sE%eK^fcXFl3 z+`4IUD0!#+S$r-d8!MScXtj=x2GgtDqs%mRK@?ToYT|D06$hB%r+K!m%O+w{jyFuB zMXNR!Rwsju9694@MI`N#r#JgW9!*!dWmYB4{y^(?$-Ekb3Qxb+flATf$f9bUQXq}^ zMNUfa95UXlc*GJ=8aM9IxRaAb_-08-h>aL!`5FI>6$Qwyac)MKjWJbTVjWD>EWxUi zrZFrM$<1skoOg!0#@L!+nb8-iOO@i9d}aaatG;J|`$V_Qr?5Cc;;Ld{R}>e#uKtDu zq*=4zd{eLnVV~2&ybL(d97TV~gwIwVW)-w`3tHbIF7n_}6+FZyZ9s`8d6@z1+;k+k zL+oeTSN%znoWW3=@G%1NDH%CC{0;#_#AJa z72`{1oLLq@Mx~+CdzQ>Nqa0!TJQ6s$hMTO9 zt;kr=OEkFI0)~UyB=M9d`+zB;EDQKy2ZoW6$LYIA8b+;Dg{sWsAY%*p267>t!@`m2 zSxQs-h_tH4JxNB(%XjPL;$>Y?$r4oc+0B>yX&9TLZFy=(=1jYv{D_-aL|I&#Y7GuV z4}6K*iRln?+SH+emEjdjSkBprBdr&_8!c4fQrqaT0-^0gFqQ^zGkHk-D&wkg)%r0X z@Q|p!gO0gsb(6|M6dTzjU4Vrdla4>B722QXo2dFZh zKK^1e%4KBQlslEmQW_7t^JetkYy2y94JV>GrHM7Vni;y^H2dwDmSl{Dcfxs|C#lln z#$*;oIxl$8#{4d6ozlV5*iRljQzM$CLtE_kET%Jz{X4lywCf24ipZ@`)@ucM_|dA# zy&{UyUfS6VN+$j79+5fGwDRz@@8qOYwI+lT;f&K4OpoOsGQvxBI6BuuW)mIiY+FpP z5%35?av&vQ(NM}cZC~24TtHZm2eEIM`Mn*v<~El5t-53hT8FbJ@D68D;-2ttSK>3y zp~PpL%YL!P=i^~jJOI(u8ztQ=W=5~1G;gKKB+$f)5@r{qeaSbsgR(T4!V@d52;;KGN=!^g2vG3 zpoY zA#yz3-aHtuX#3(&XebE=cTeCQNko#Iww#3Xx0F&_0>QYJ0lbD*xDqhcV}z6m()&B9 zse~`(rHLck=Tww5cWrbN5jNzpoFpeb##F>FRo^n|rZrt6I~Pd%QDG)jN@_zQeySk- zMoGu-9}$m9{Ye`guz5YBmaSBlwp6M>?t!jN-DWi-Oldxr9(7PY zXU+Jk6z;*$$WhVIamHLlhJp(0Jz2)V#f{~OiYsT;lXF#%rJA&d%g-m8CU1@DUXsW$ z${J0ep@Mlkk@d^fwdAczym6UwO=j%@59jy~pDkz#iv>h98Ljq|=>Za8!Hm!x(R1$9 z?NitBsWHOW{{$40twv8|-ezaqf)4Kv~nucGZ%YxadO zf1$yyhBqss){+4GViirD9+|a$#47!;Quun+bGYBWWc3{G=c`tl`M1U2MkaNfB@}In z)BDfxxEh0jHTNz4Q$!b{5v7i#<+LcL^;VA}BIh>wU4agK6pLy<1+!)*L|iGFB=>Qp zgKkwuo_I!8JEw#J*Z4{FC8H<{_$SQShCHg>>^^g5&p9KV%jyG z8MUN%eE10-F{b7CxfEG&Fg779^ z_L{uchl*CoZ3~**to1bEOu7+1_@#9Wk`1G?8${)C8LnCEA*xNI)45dAQyE?2ZH{L7 zP?#10KlNc7TU%`A%$JqRX~xwo?zH#w)1P|j_$jd<-_y!Ty)yOD3#IP%JcpP|#&G63 zSTw()$qpnicdzZm0+?i4d!O~^$S{=dS%jhNBtJymSQH>SUDhf5WJ zrU6mns>lsZ!)$sF8+)JyE4Uw-{0vO;+bw+5%(SZ+KGd;I{dz!4b(k@m3N%k@p9WKM zA=kuKJj*3?lWq3iSGdW-o5InKQT4&Ft^oOJkJ?Q+g#a&G4z*acnO&5?3=UZz3cxEs zv2cS~R{kejj=j9qG@==ih!nC6HA=1RHFC}6E4X5DeTy$ul}ZZXOXf8-FB8&RcYVk> z(Bgc5*W6pqvtc47u}R8|%L~+RF&thVPmg^PPr~)GY-($bDDxZEaun}}OkdJ#d-aHR zTjvw=4+r3)>BneI9{wMwl1|6~9+eiAlmQ5x6LN00-;dY4VXt;Ya+sLYSwLt0?#7IVEP#Fd89-nRpZ3CK*?x zZpr5}Blhf!L>QhK3`%vl3kMea~eW=L;bu6ji=IrBx zU5$qPP+!q4PZED$F})0!bOQ=Tr~EzpYap8(7v65UFG#IPzNq6``r(sP<(~XRQ}Us| z)`j##f2~u=hyGe;{6l}O*i~^jIgII_`%^A$k}*zlUC>#yR@xxsQd^y)x6*T3R)d?- z>RggAH7R3(*L{H;fnV>3KbXbje&BJ&Sn`-vHBHKcvbfp!Rvi`pVvO$)2S|rsOL&lE4O&?Y?nDZ81&Tr>@^2zi zYaP8bkY2IA0}5y%s)AM7Y`x8*{We$anuLrJ5iQ9y3*)YwhQjj^q7${~0F;EvKa#tb zaV%80yG`!jigr^WfMzCP%)Y(&(%OX>}|lIY}Wok zDp+5`t@G*fTd|6tc1|{CG_%Oy#|C4eG@lCVBHzY}3RHthZBzwiZ@UPHVE?OXBSjvtdE8YS0j0lX1y3 ztSW{>$Jo1UYL>K{w>vY7EU!QmzJ*~EgGzg}-)#MXZ1PdPWB52$wsm(_(Q1z%JX#A( zN#jh~X1r@*zE|+GMLlC`{CKext#hWM6C6nKwB}JnXy*qddT*4z2?C-;ZZMIl!l1^u z!+Zr_u&WRYR!=;6E0wyj=Ne*hIh2vUg0VzVew#wWf&L>EY|EC+Md>V5YGSLf#F{X0 zsV1aX^g4uKRA6uVyK1FcD4v8@kibOFdM}O&hZd*NB5PZs8l;jD6sM6IU{8rxq=?<{ z*qi$unyrM#?2PXVx*)ct*2Pqb%h{UvG1b`89MS>&#Od^JYIa&(BRacKJY)=QZFJ+@ zk}F2WWQ|Uvg1w%{B*?e$3^cZ%1xRPc+hYx_v_o@F@oIXaB^YIPB^*+tH^*~ua4f={ z1MA!>UYDtCPckIhT35wARIFx;lcaW##*nN@2G+d;TY1lLz}S+xkc{%ViI90xVQ{An zq;*r$=}99kjTD1O`=|4+K?|i*9sc7Y8BaBR6%G%LN2O@+!;Dt7F>xe$ot&3EM;dgqJ4zJUc})GqOlze{sS6<_wnAH4_YpfNtGP55U}#dJ$e(WA`S^9x#49tLB)qhTPBYAmEeRMLqLq=(gMu zy*DC@CjpXjkN`qj%NpU=&{C0F4Adc9q_+}Om`{^)@*3Oixukk8=cN7vPb(#8>w&|w z=CY-UL5)KyUe?NBHKfFSts~Nup?-0uArAv65a77JjAP&798tHG73vE-C-5oa`S zEbW0wfbSqbwN4upI7n9Kb_}d~6<$r^W;6V%c*ZP;E}?_&;+nI9+_Ln|Ve@cXY!cR3 z&iP6 z3bw8Bl;pUBZ#I?&v}c{N^Tk0ciBi^;8>J_qGHOg^Kbx6x(@zwzS7U5Lp&-CWP0Jbl zXN=WURi>AwUwkTuwj*rD;DIX=sa8hNeVj19?z5R$OSqm$47QQJmuE&PHmV}0f=@M# znMhT9ozX~kAp~AYwp-kT5ZN*VM(Q(85{i}aW^7FpXn^Hd5qV?l%u@&u+e&Bs#pn-w>~)-r}*#Zkk1Wl;ZHRB#hw4h_n|m_fYQ zA$pW+BnL3KzZ}}fcy(HN1=$3f36%4nXc?}gi>EA6ZB$e#QcjO&-n#XOUewXLeR)Wt z5|jw}54Cez#Oa!5zq_v<3)$KsVpTe_hhjV_ph2Rx^jA?xzs&Z*U)Zz5FT6#QW;(?T zjG=s=13qD#c~exfAzw@kp{mm#zk-Vzw3&sGNJ$3|Ll^zL=TFQXO`5-hn`V9bzPD$z+Lf`kiQTnGxJ1 zLS<{Lc>?*$d^MU0J99{q$ffn|Xekf>9gUB-4TuCVq*P5ubI~GAu}SakgHlZSp^qgIQ+w!xO=E~qRNe8} zjtZJqnXR-Yd!i{Zb3tP`&p12NDJmmgvPGFxE@4O8nkSb8JajubPuqgi|7FBdv+|;W zB+%@z+Rhof+t(0cE!69*B}5lzN5d_lL^_j4krB|#K6_|Rs`R);j)4unad}$2!j96>ZQ)8Ts8kNrviU-}PtT@A?%wzbjACXYBV^^Wsy<}koGFyIH#bYqPWRT7hC$#w zct~tY2kShQBAT&$$wms2`|w!`m3kqH%wed{xb+cN0w@L4fjHVamqb)D zYT`k)-7Jg^Erpx8r$ogmAx0Kwr1=FZrgkTi`}z>r$d6Irr-?8N@Q1~ePv`2-Fqh71 z(d50Z`x!!45T-*rzr7(XmCXJj8&3W-L1%4ZOgxmDO5!@tW|(W0MrX;_(v$Te^stuw z=mE(z)qag)^wy5Cn!9Uc(5TAeFhN7v-h2izyy~}Tha(ruDcvyo4LT%w1c2_xL5DUB~+g#1}>4R7`_O$Gb|jFZ|PY!<1Uy; z;S*+>kvmBCb^7<|De8coY<;q=ug~?AQn2m%tRux{e}Sl-HkLnD+sqk|DzluE)Ur4X z3-7_9=rf%ZVrP_{n_0=H$)DWwR&b(OVrJFsv)unT47le{C{xDIr=qn6>^Y1`$Y#h= zI-|CJoSjjZpCIuj*)M5mV+Ji1NrMq-A1S4vfjULn;gt>fG-2K$UHWHE-!v(rX3drd zWjaX7E%!W$TP#Ly>r98+?c+O(tl z92+M#l=^Fh+Qd0}J43n&|3iLcLMqGRDbJa7+q~7*bf&)lmbDqvik*vJY5h{O=wApk z+`c%|z(0vr;w_9jV7DZaf12f@PC-)(MnjPWUvQR%qI8{cvDJvPl)w3zRx!@<+@zd8 zTkk1)%Oc!LFCp5ej79gwgnnUIVxO1@4&u}GG^`KKk~L$Br2xbwB70&514BUsv8{uL7b?DcQ;G5qJO+}ojzW=vXAAIp@8WY zx6FrZ`N%H>n|@`eRxIx3Q^&JE+pL7Isb+3+J#Lkm)VRjn?_Ubb>uZ`ySj=$0vng%} z$5Swh^jVT%boX2Ien{LaF$*+zxnn4N7@jbxN6Ibtgt$m{lU7`?b?atnEghStw()A| ziI!>;v*;G|w|vaQWCAtbW>&Q9O1~l6w`!nK+F9&v@bRnI_kEJK_03{^g|=XK@spZ- z8&jXP^xGs0SPvNt&HiFK3+kIl-i}d~Ck;gRpx_P>aMA6{%Fq zrkRDa0F7g_wU`VqhI~dml?1(>{%*6cnFTqh3h0kou@OL(Zt7j%%kbSR>#VsHeI~^9 zlky`pUG6Wd(z)1ab+z9UvNsAMEygqbLs#1DjcT^&&GKuMtQWl@mWq%PRaX4=Bo*>B z{U&iw)7(ABO{cxj6j|F`W{b#lm)WA=^r~75LrjNCU0=hVy9PAOGqfH^-~rA$8p%jN zDp}&>vr%fP+&1~3dsMPW)cUDE2F~h-etutjtY}#lw-M>^y8jc(*Mx#4B51Y+)i$g$ zB-0$XlmqmQu|DUTRh0=o>73Qm(y}fTg>cPe%Je~Rr7$+2&%U?Bk1x{useGyGI_l!W zFkdy!+@cb9`pM>4t1y}$IM;*>4KrSm%IVeSJ}%_LpUM7lgC( zGk47I&L^iAWKJ*0bAlbXH{+I;$lsowYGiihGdbkMIhF-f(0Utd>W-zcBWZm{vNUCVru+m88qrM~`M87LL~f$EsvK;UE1?N{jD zV6i?>E7@g#bb_CJEe+WI^v}ve6#HR#)RWCLC^%y-HTi8doRSXTyv!wTGaMei(`p|q zgntyD5e#vOvKl3Um9?eR6$qgFu@gQhWhNQ>dltO_q@c=HV@p z#Gh51tMv?fW4k`@6;I0Py<1tX^v@6CzU3vrl%I$ zReVaYjC!GQZ3=~Z__$_Y-;UzMc(pd@TvjgOM%0~eN0IxozFya3oRS{$Gfpmm*)t2< z@7ca<`-Gj*j|p>Jr zP!SAZu2HR)>n-IM)Rdg$%L}`A_ZKRIUFmJ6F)`TizVWA$>sXR_Y@%FfRtC_z#6PY5 zdUI^7T9ZE!_2J6w>{tuqvZKg%;=6RmDf*B5c~M$ZhFKX1igm%6QKEVB6Qkv*&>So^ ztZR|lN`EVb#=uC_j}KXm`kSTlp#NWOHlqIBwP>JZC;btAgJZA|;c||ZBE6(rF7+EW z8>MnRf`7QduvsfYg-D;ii6BulVwH>xM`3|-y;vT~+3%eU{-4gSH8)`x2Ky)#llEsy za{^AW6NHkLbZt{5rHo!;ci9Q|*=eB#G;RBVWb$wvW4_pVCU>7tE9gBBEXvvbO;tWx zRYe?EIN6HZFwdf*at=|4EP~j}w@2XQBWA(z?RbGE7Q`ITuP)v1rzb@wl5THa9rqeMrI8r4Em}jSYA@6KzUuA4*NP zz<-wjKn3i`4$RB62yFOkH5pG0?qfMnbFBMhA=Dx;BX+}IF@BObjJ%m6VIwe{fML^y zT8tKqv-8py2Lto6hqRow(4k4{><6(W;gd~*XB#NvW!}9oZEF$5!05b&xwG@|WXp03 z`WZ^vV{)PBeK>CgQ#LDZ%4RuNS|#46+?K%iOsUo@c`^~?by_=nB-@I;ylAeq<}gbi zVH9@)JYs<+6+1zFIj*?XpVV=fSfQlCWEh_ z(7g9Rlmzd1d4tge*|Bi%FxCVm$r<1|ltgvsL!lO delta 8936 zcmZA5349LM{>Slo5=%l7*(?!REU^{|Vs9k`v8O14DkT+)1hEBuY^|$R)L6RQwzQ@0 zRk}P{troRZ_bbur=BiRltGl-Lw)gYR{L;VIe_pR&-oJC^%$zf4&Y6TI7lQwMDaik2 zbcMAJ$6TM|)WP4XI!;26<9tw4wT_dK>^Ork6BBVQhT#sRsk0At-G^8m&!gHobsa~y zNWw^Lhm|qg%<=R)!$@?a(RN~zS%ksV&%-LXz9}9 zu8>4wN`0?EJ4~S58`V)hGDc@QHpaE)9*n1a&dvun@X9IJf%;5yF2+)R8TBgO!_#;S z{q*g;nc_Y9*QgG^H!qn%JcjDSF%N5@X6hc)t6OTi=95^7`mLz7@{*PJVr|NYa2TF! z$o%UD9UFOzqX*8S+#fZChp-ZUZRgKpEy@>gG*)FgG>}QC`WYC9D=-wdpl0?Ztbqqn z4{{8(SkE?Q{=-SGQz5G~@vMa!SVJqfvT_C50Qi)5sEw^@w3!7@|_>rpq}VC82}_t}OEeQZ;!Z`<5) z(y8x)8sH4ngZTX9vbB6V1kEE3>oN1Fvy? z4pzm!sbvq!{wL8p8jF>22I?KoM>SlJnvth561Q7>DM9sheb0n(633h%OR-?QC^#xpo>hO8ggS~=U zgnO)f6vMRtk6XogREHN(Q}49)E{sLCs#6Eq>Q1Jahr1{*vvO7&Z~y0`z86cZyczWh z_oD_-ikgvc(62Ak1(KQAgcZV;cQ)WtcnCG}2{h7&W-98{Jc!z!&mud~If&8tJ*wSb zsNE3X&YPjSm_)fLY9PJM+;+^rD)On&8kmKefo0ZUJ)WYx8MPLcwfA1pTGYTcU_;!3 z8o*(!g{Q214RzlLK8JcW$;jB8RP2W1J23wnNVZb(2KMdfH3;p*7Nnek+BU0E19%6E z@MGMLy*fM2M!bx@@X?#SwR9Ra#oyv*_$$V-=svi`n}M@kya)K*Pof$419d@IhBpH> zP>Zbr=3yG%j_dJh{2k-*kxcJKFPpnDhWfWqGx9lVhQ3F&kLl`tFIpnc?D$)g)FqjW zTFom_7e0));a2Q{KITh{FB_9^64t}z$lGzAN1nkshq_;*EC!9eP}k4Jez+f#F|xbk zjG})hjfBBDt5737f-Gp~3O2yzT&+bm5c#S)#i&=Y3AJ5cG~clLx2^nXQ@I$msGdX(?0GAHfogvq^$IUq zIXK&U)zwgoGEvgMlWG-RF@*A9)RWzgdYAdARXqccKPx(8`CgBIW;@r%*Tk27~bz)OEkx`Jmoj z`w*;5eFTPL4J#*Gxp8mizXB&(QK1{PLv_>%gD?}>F-{h;Zk)xafxd(E<%IR|Uda&D zD=R{MdY747Q1AY2)O|n0D)=R;-*5Xc|9X-isn7^7p$6jX>sb-CYC};S3`I@-B-9k& zgKT|g1!~p5kInE0GmeWj<=s*D&qZ}S7S(UQpQIAWRI8Yc8sS3JyIqdz=rIh#t*9Hl zin_smRQvZ)H~s|m0LM@RJ%M`iU+nxPRQu~z@2}k7`{0D*86PVfC)2=}<4th^)}Z_v zYCt8JfhVvzCg1A)`=CE+2A;x5JcxStN6q8r8LUeE4_?{tT(J|rf!@eNQ6mgDYnk=U z7G?)C%N$@1H}lLwb1rH?_n9j&MEieTS;9U>P2CprIr9b7fOeRB&G%66_9&*{x7ZM? z4dM@4Y>Ux26*Y59P;0}*DBOz)+W(~_`qch}>Zto*Zz^-JG39CIW2g_$K|BAIm4mog z-||Fr7-~SPu?fD4kML?wVQb3shI#{f0sS#l>?M&OndeXgxrTeN(lBrFy@hIb#5`+W zMJ?ipT(4bqRJk5%yEehiI2rZsV~2b9Pae+ve@8_#DpIlL2ygLZqoynuTVg)mgAbzy zR&%8HOQ#;*M0q&s)4UX0;3jN3H|m!nqw z<2a3}+ksl$jqdRNrQ8d3qqjzT?LRV4qu%-NsQZPC@wRW2S=UTM%}}PFL{F5BS`>rK zJaZPtQojr}BTt|f={8hHFQNu|5ED6Z4At?~ao(B=&hvg<=i;M2{xOQHI3GLSn-Tve zl3G-pL@k!9SO**AdjrZe2bp>1EOQxZ1|Kt@HxJs<2%-75hQD4ZDs4wPsID}s&mr-BH0aLvC!5FXo zKZZmn=A$}VWIl}QV7s{=t5E&~6YwO)<6oGL@de&Hy%l*fXBcMSXw*P9VjONqy|Q;O zhW?!sB)Z|Rs0*VCz1cNbP4_zLji)GGrVnd3R_W*n&~)wFbnx4IIFNVeuHhX&Ma>+4#Eh^ zcj0X~1FPfv=1KDs>UT%@Z028!uhVRA5e~*l3}iAkr2dOJ-jw@_y)_Yry{J#X+BhC{ z{UVIU$56XyJ66Ltk;!mMa3yw|>p0`M|3}yo+s|kI$8sW{ugfz00CR8%_1Xo`;um-j zyKupi3)rG~Vxc#MtrvT%`A5_Mf|u}jALnb}HT2!*eK-DC>b=^ee|Yz8gj%Foev%lH z{-~+D6Hnn(Jb;54)lJ-}*8PriGv)3NcsE*%k(3`meF6W8?eJY3gTCe7t{RK_&^&>i za1%DblUNn~l^*m)6pimv(Gs;Lu3&x4SmEv4aafP?5>!XeVi!Dtbuo$gO~Xvo_0zE* z?!sgYS>=6rnqa2tv7z?=brLP6`VV;{8;Xr6&%>tp3~Ho@QQPmBdDiNGvGN~Q4q5HZ zOf2fU6x1S2vvN<=E*pfQ+W#X+^hL_U5G+PrxEQr9S7JPF!)o|0YG9vRxq|DpkHs+R zldaqwBPe&kD9kp8o0Bkv{+)YB^khph23Mn2^=8z__o8la6m`RM=0%L5Tyc#zusGBM zG(kN;E7bX0uni8xbX(GTJ3rVQj+)xh zsMVcs%4tG3iV31U@RWOL_B6* z#YoC=>%9kPikjI}RL7lA50Zh=*lRuWuaS(TLXJkQ+Ht53UP4X%+o*T{Id;ZxQLDb; z!`>%2+blw@l?|vFcmvh(AymijqqgJ6RzBt@(FjkY-tAAQj{ZbVal|9ujp9)^NI|u4 zfx2-A)WB~+4YVt2MhDyZ;i&d^Sp7r{r(B3W^pDj~jv%~-Bd{W&1)?vYjtpxPh1H2s z)XlUy{dM#UWxcjg^4p1RFi2tJ%nf9j)&@`G=Y^RgA%;5qGo9h$m1WtsP*r(N{d z4RuP{ab^FXqg>OkS8_}RJH9t}m|83CZWw@7J3oKU$rbdqb|&f5|Gg;D3pm2(8dMT-+an zu>{{Fx)VK!o_LnD{)f4;ilL{ z*2ejoq=48_+JC10A0epAtnXaCDOKblk&U7MdC|B#|B~}v7Z=4n|?&u zcd-%4Nz!cMHKH%kn!4vu$3q^@E!15gPxHAa>%?fejiE+ID{MdvC-=J#C6xVD=L{}8 z$FFqG{F^)pAF#TGm_qPLdd5e zf2a7%{!IIs!V|!epWf`4wUnQJc8&$mD$Q8!Emaf6~g^ zZ>SHWopyEEk?-Nupfa`WgjX@g@+^wq5c(kL7(x`@(5?gd=CU*VZ!G!!MflK^=!Z z%6|5?x@fEW3McCQceWEDq0a|h!oD>jgyExB9#ax%8!;Ln}~X}n?)=r zKVep;ZtUN6?)f@Z{Q5(?4N;5G@f*>Q`~{qgx8YPf*N$ArV9K4m)R{njGZCPiVC`m; z*C&r9!ihhv?Hl+Gae|2P>io{zBz5h=_IQYL0&$usraT7Aj|h@^#2%~g*>#igZp(G5 znAk@=PwXPfkE538pHTjIlto`c!6 zoq^S@uAD)Z{AzZMi-}u_KZxmE_afdy+(xb=)T8WY zDL?g3pfEg3v?uN$t`h~;p46!j%MbT*%FIAmqgR6}6iz4{9azvj%jX_!*)Y&PHQMKn zN-GT{w*JlMc1v&Ty6Ig472AI5t22Ad(?m|-v6m!H)!Aicj@4?K(isQ_}q)bzIW4yp9{1c5$_A+j%2Lo zM!k_fVam7y{_Q+;+L*%R8HG5ZXu_27$y4%XC66tbQj|BPh`NF)<2xqjOrXW|yy>SF zY*sFDiww-o+Yuc2dE#|nAo0RozQD+W;vn~rsm%fhFZS@c3#P9N+*DLA$bEd~ z>w#&rR|c2QS2v%#XvwVs|Gme3fq6^s^aXa@-!sUK+*v(tSIM4|-K9%P*OdfH7nd$5 zd7<>a(siY4N>>D$Jy^}>Zd@_Rx7yveyp}t3Wo{sDRZg(`h@0-luUV}L{A}IsVE6Fj z$?owD85Qp>T~xBiJ@I8ipv%S%K6l2`5BZ*Sqy7`?&JRSm1D=^3NZK+#$hXE#UYFo@ z-j)$?n*FyMvd}Tgv|3zRm9FowWn&547;Pd*1FH*!Ny+aKL}KT2LVI zNX?)??#GvXJVDN@H3Rp45*!rhbZnx}-FK?CyYF\n" +"PO-Revision-Date: 2021-09-01 20:29+0000\n" +"Last-Translator: Sviatoslav Sydorenko \n" "Language-Team: Ukrainian \n" "Language: uk\n" @@ -58,12 +58,20 @@ msgid "" "`pull requests`__. If you're planning to write or edit the guide, please " "read the :ref:`style guide `." msgstr "" +"Переважна більшість роботи над |PyPUG| відбувається у `репозиторії проекту " +"на GitHub `__. Аби розпочати, ознайомтеся з " +"переліком `відкритих іш'ю `__ та `пул реквестів `" +"__. Якщо ви збираєтеся написати статтю чи відредагувати це керівництво, будь " +"ласка, прочитайте наше :ref:`керівництво зі стилю " +"`." #: ../source/contribute.rst:24 msgid "" "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of " "Conduct`__." msgstr "" +"Здійснюючи внесок до |PyPUG|, від вас очікуватиметься слідування `кодексу " +"честі `__ PSF." #: ../source/contribute.rst:31 msgid "Documentation types" @@ -75,6 +83,9 @@ msgid "" "purposes. When proposing new additions to the project please pick the " "appropriate documentation type." msgstr "" +"Цей проект містить чотири ясно виражені типи документації із чіткими " +"призначеннями. Пропонуючи нові доповнення до проекту, будь ласка, оберіть " +"відповідний вид документації." #: ../source/contribute.rst:38 ../source/tutorials/index.rst:2 msgid "Tutorials" @@ -86,6 +97,10 @@ msgid "" "goal. They are opinionated step-by-step guides. They do not include " "extraneous warnings or information. `example tutorial-style document`_." msgstr "" +"Навчальні інструкції зосереджені на навчанні читача нових концептів шляхом " +"досягнення цілі. Це упевнені керівництва у вигляді крок-за-кроком. Вони не " +"містять додаткових попереджень чи інформації. `приклад документу у стилі " +"навчальної інструкції `_." #: ../source/contribute.rst:47 ../source/guides/index.rst:2 msgid "Guides" @@ -100,6 +115,13 @@ msgid "" "accomplishing the task. :doc:`example guide-style document `." msgstr "" +"Керівництва зосереджені на досягненні конкретного завдання і можуть " +"покладатися на деякий рівень заздалегідь наявних знань. Вони подібні до " +"навчальних інструкцій, але мають вужчий та чіткіший фокус, а також можуть " +"перелічувати багато застережень й додаткової інформації де потрібно. Крім " +"того, керівництва можуть розбирати багато підходів до вирішення цього " +"завдання. :doc:`приклад документу у стилі керівництва `." #: ../source/contribute.rst:56 ../source/discussions/index.rst:2 msgid "Discussions" @@ -111,6 +133,10 @@ msgid "" "specific topic without a specific goal in mind. :doc:`example discussion-" "style document `." msgstr "" +"Обговорення зосереджені на роз'ясненні розумінні й інформації. Вони " +"досліджують конкретну тему, не маючи на меті нічого конкретного. :doc:`" +"приклад документу в стилі обговорення `." #: ../source/contribute.rst:63 msgid "Specifications" @@ -123,10 +149,13 @@ msgid "" "tools. :doc:`example specification-style document `." msgstr "" +"Специфікації — це довідкова документація, орієнтована на всебічне " +"документування погодженого інтерфейсу сумісності засобів пакування. :doc:`" +"приклад документу в стилі специфікації `." #: ../source/contribute.rst:73 msgid "Building the guide locally" -msgstr "" +msgstr "Збирання цього керівництва локально" #: ../source/contribute.rst:75 msgid "" @@ -134,12 +163,17 @@ msgid "" "locally in order to test your changes. In order to build this guide locally, " "you'll need:" msgstr "" +"Хоча це й не вимагається для внесення вкладів, збирання цього керівництва " +"локально може бути корисним аби протестувати свої зміни. Щоб зібрати це " +"керівництво локально, вам знадобиться:" #: ../source/contribute.rst:79 msgid "" "`Nox `_. You can install or upgrade " "nox using ``pip``::" msgstr "" +"`Nox `_. Ви можете встановити чи " +"оновити nox за допомогою ``pip``::" #: ../source/contribute.rst:84 msgid "" @@ -147,11 +181,17 @@ msgid "" "the `Hitchhiker's Guide to Python installation instructions`_ to install " "Python 3.6 on your operating system." msgstr "" +"Python 3.6. Наші скрипти збирання спроектовані, щоб працювати лише із Python " +"3.6. Скористайтеся `керівництвом автостопера по інструкціях встановлення " +"Python `_, аби " +"встановити Python 3.6 у вашій операційній системі." #: ../source/contribute.rst:91 msgid "" "To build the guide, run the following bash command in the source folder::" msgstr "" +"Для збирання цього керівництва запустіть нижченаведену команду bash у " +"директорії із джерельним кодом::" #: ../source/contribute.rst:95 msgid "" @@ -160,16 +200,22 @@ msgid "" "guide in web browser, but it's recommended to serve the guide using an HTTP " "server." msgstr "" +"По завершенню процесу, ви можете знайти результуючий HTML у теці ``./build/" +"html``. Ви можете відкрити файл ``index.html`` для перегляду цього " +"керівництва у веб-оглядачі, втім рекомендується отримувати доступ до " +"керівництва через HTTP сервер." #: ../source/contribute.rst:100 msgid "" "You can build the guide and serve it via an HTTP server using the following " "command::" msgstr "" +"Ви можете зібрати керівництво і організувати доступ до нього через HTTP " +"сервер за допомогою наведеної команди::" #: ../source/contribute.rst:105 msgid "The guide will be browsable via http://localhost:8000." -msgstr "" +msgstr "Керівництво можна буде переглядати через http://localhost:8000." #: ../source/contribute.rst:109 msgid "Where the guide is deployed" @@ -181,6 +227,9 @@ msgid "" "readthedocs.org/projects/python-packaging-user-guide/. It's served from a " "custom domain and fronted by Fast.ly." msgstr "" +"Це керівництво розгорнуте через ReadTheDocs і конфігурація живе на " +"https://readthedocs.org/projects/python-packaging-user-guide/. Доступ до " +"нього надається із додаткового домену через фронт-енд Fast.ly." #: ../source/contribute.rst:117 msgid "Style guide" @@ -193,6 +242,10 @@ msgid "" "your contributions will help add to a cohesive whole and make it easier for " "your contributions to be accepted into the project." msgstr "" +"Це керівництво зі стилю містить поради щодо того, як вам слід писати |PyPUG|" +". Перш, ніж почати, ознайомтеся з ним. Дотримуючись цього керівництва по " +"стилю, ваші внески допоможуть доповнити єдине ціле і спростять їх схвалення " +"для проєкту." #: ../source/contribute.rst:126 msgid "Purpose" @@ -203,6 +256,9 @@ msgid "" "The purpose of the |PyPUG| is to be the authoritative resource on how to " "package, publish, and install Python projects using current tools." msgstr "" +"|PyPUG| має на меті бути авторитетним ресурсом щодо того як пакувати, " +"публікувати та встановлювати проекти на Python, використовуючи сучасні " +"засоби." #: ../source/contribute.rst:133 msgid "Scope" @@ -213,6 +269,8 @@ msgid "" "The guide is meant to answer questions and solve problems with accurate and " "focused recommendations." msgstr "" +"Керівництво має відповісти на запитання і вирішити проблеми за допомогою " +"точних і влучних порад." #: ../source/contribute.rst:138 msgid "" @@ -222,6 +280,11 @@ msgid "" "detail, while this guide describes only the parts of pip that are needed to " "complete the specific tasks described in this guide." msgstr "" +"Керівництво не має бути всеосяжним і не має на меті замінити документацію " +"окремих проєктів. Наприклад, pip містить дюжини команд, опцій та " +"налаштувань. Документація pip ретельно описує кожну з них, тоді як це " +"керівництво описує лише частини pip, що необхідні для виконання конкретних " +"завдань, описаних у цьому керівництві." #: ../source/contribute.rst:146 msgid "Audience" @@ -230,7 +293,7 @@ msgstr "Читачі" #: ../source/contribute.rst:148 msgid "The audience of this guide is anyone who uses Python with packages." msgstr "" -"Цільова аудиторія даного керівництва — усі, хто користуються Python з " +"Цільова аудиторія цього керівництва — усі, хто користується Pythonом із " "пакунками." #: ../source/contribute.rst:150 @@ -249,13 +312,12 @@ msgid "" "themselves as programmers. The audience of this guide includes astronomers " "or painters or students as well as professional software developers." msgstr "" -"Зокрема, пам'ятайте, що не усі люди, хто використовують Python, вважають " +"Зокрема, пам'ятайте, що не усі люди, які використовують Python, вважають " "себе програмістами. До читачів цього керівництва можуть належати астрономи, " "художники, учні так само, як і професійні розробники програмного " "забезпечення." #: ../source/contribute.rst:160 -#, fuzzy msgid "Voice and tone" msgstr "Вираження і тон" @@ -264,9 +326,10 @@ msgid "" "When writing this guide, strive to write with a voice that's approachable " "and humble, even if you have all the answers." msgstr "" +"Під час написання цього керівництва, намагайтеся виражатися доступно й " +"скромно, навіть якщо у вас є усі відповіді." #: ../source/contribute.rst:165 -#, fuzzy msgid "" "Imagine you're working on a Python project with someone you know to be smart " "and skilled. You like working with them and they like working with you. That " @@ -274,9 +337,9 @@ msgid "" "*That* is how you should write this guide." msgstr "" "Уявіть, що ви працюєте над Python-проєктом з кимось, кого знаєте як розумну " -"людину з потужними навичками. Вам подобається працювати з тією людиною, як і " -"їй подобається працювати із вами. Та людина спитала вас і ви знаєте " -"відповідь. Як би ви відповідали? *Ось як* варто писати дане керівництво." +"людину з потужними навичками. Вам подобається працювати з цією людиною, як і " +"їй подобається працювати із вами. Ця людина спитала вас і ви знаєте " +"відповідь. Як би ви відповідали? *Саме так* і варто писати це керівництво." #: ../source/contribute.rst:170 msgid "" @@ -287,6 +350,12 @@ msgid "" "hereby granted permission to end a sentence in a preposition, if that's what " "you want to end it with." msgstr "" +"Ось швидка перевірка: спробуйте прочитати вголос, щоб відчути виразність і " +"тон свого письма. Чи звучить це як щось, що ви б сказали, або ж це звучить " +"так, ніби ви граєте роль чи виголошуєте промову? Не соромтеся скористатися " +"скороченнями і не турбуйтеся про дотримання вимогливих граматичних правил. " +"Цим вам дозволено закінчити речення прийменником, якщо саме так ви бажаєте " +"його закінчити." #: ../source/contribute.rst:177 msgid "" @@ -295,6 +364,10 @@ msgid "" "joke, but if you're covering a sensitive security recommendation, you might " "want to avoid jokes altogether." msgstr "" +"Під час написання керівництва, підлаштуйте свій тон на серйозність і " +"складність теми. Якщо ви пишете вступну навчальну інструкцію, можна " +"пожартувати, однак якщо ви покриваєте делікатну рекомендацію щодо безпеки, " +"можливо, вам захочеться взагалі уникнути жартів." #: ../source/contribute.rst:184 msgid "Conventions and mechanics" @@ -314,7 +387,7 @@ msgstr "" #: ../source/contribute.rst:0 msgid "Wrong: To install it, the user runs…" -msgstr "Неправильно: Для встановлення користувач запускає …" +msgstr "Неправильно: Для встановлення, користувач запускає …" #: ../source/contribute.rst:0 msgid "Right: You can install it by running…" @@ -335,6 +408,10 @@ msgid "" "you're going to make assumptions, then say what assumptions that you're " "going to make." msgstr "" +"Уникайте невисловлених припущень. Читання в Інтернеті означає, що яка " +"завгодно сторінка керівництва може бути найпершою його сторінкою, яку читач " +"побачить узагалі. Якщо ж ви збираєтеся робити припущення, то скажіть, на які " +"саме припущення ви покладаєтесь." #: ../source/contribute.rst:203 msgid "**Cross-reference generously**" @@ -347,7 +424,7 @@ msgid "" "search." msgstr "" "Коли ви вперше згадуєте інструмент або підхід, дайте посилання на ту частину " -"керівництва, що розповідає про нього, або ж на відповідну документацію " +"керівництва, яка розповідає про нього, або ж на відповідну документацію " "деінде. Не змушуйте читачів шукати інформацію." #: ../source/contribute.rst:213 @@ -388,18 +465,21 @@ msgid "" "Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or " "avoid pronouns entirely." msgstr "" +"Часто ви звертатиметеся до читача безпосередньо за допомогою *ви* і *ваш*. В " +"інших випадках використовуйте гендерно-нейтральні займенники *вони* та *їх*, " +"чи повністю уникайте займенників." #: ../source/contribute.rst:0 msgid "Wrong: A maintainer uploads the file. Then he…" -msgstr "" +msgstr "Неправильно: Доглядач завантажує файл. А потім він…" #: ../source/contribute.rst:0 msgid "Right: A maintainer uploads the file. Then they…" -msgstr "" +msgstr "Правильно: Доглядачі завантажують файл. А потім вони…" #: ../source/contribute.rst:0 msgid "Right: A maintainer uploads the file. Then the maintainer…" -msgstr "" +msgstr "Правильно: Доглядачі завантажують файл. А потім ці доглядачі…" #: ../source/contribute.rst:234 msgid "**Headings**" @@ -412,20 +492,26 @@ msgid "" "reader might want to know *How do I install MyLibrary?* so a good heading " "might be *Install MyLibrary*." msgstr "" +"Пишіть заголовки за допомогою слів, які читачі шукатимуть. Хороший спосіб це " +"зробити — скласти заголовок так, щоб він доповнював неявне запитання. " +"Наприклад, читачі можуть хотіти дізнатися *Як я можу встановити MyLibrary?*, " +"тож хорошим заголовком буде *Встановити MyLibrary*." #: ../source/contribute.rst:230 msgid "" "In section headings, use sentence case. In other words, write headings as " "you would write a typical sentence." msgstr "" +"У заголовках розділів, дотримуйтеся регістру речень. Іншими словами, пишіть " +"заголовки так, як ви б написали звичайне речення." #: ../source/contribute.rst:0 msgid "Wrong: Things You Should Know About Python" -msgstr "" +msgstr "Неправильно: Речі, Які Вам Слід Знати Про Python" #: ../source/contribute.rst:0 msgid "Right: Things you should know about Python" -msgstr "" +msgstr "Правильно: Речі, які вам слід знати про Python" #: ../source/contribute.rst:237 msgid "**Numbers**" @@ -436,10 +522,12 @@ msgid "" "In body text, write numbers one through nine as words. For other numbers or " "numbers in tables, use numerals." msgstr "" +"У всередині тексту, пишіть числа від одного до дев'яти словами. Для інших " +"чисел або чисел у таблицях використовуйте цифри." #: ../source/discussions/deploying-python-applications.rst:4 msgid "Deploying Python applications" -msgstr "" +msgstr "Розгортання Python-застосунків" #: ../source/discussions/deploying-python-applications.rst:0 #: ../source/guides/index-mirrors-and-caches.rst:0 @@ -448,7 +536,7 @@ msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:0 #: ../source/guides/supporting-windows-using-appveyor.rst:0 msgid "Page Status" -msgstr "" +msgstr "Стан сторінки" #: ../source/discussions/deploying-python-applications.rst:6 #: ../source/guides/index-mirrors-and-caches.rst:7 @@ -457,7 +545,7 @@ msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:7 #: ../source/guides/supporting-windows-using-appveyor.rst:5 msgid "Incomplete" -msgstr "" +msgstr "Незавершено" #: ../source/discussions/deploying-python-applications.rst:0 #: ../source/guides/index-mirrors-and-caches.rst:0 @@ -466,7 +554,7 @@ msgstr "" #: ../source/guides/supporting-multiple-python-versions.rst:0 #: ../source/guides/supporting-windows-using-appveyor.rst:0 msgid "Last Reviewed" -msgstr "" +msgstr "Останнє рецензування" #: ../source/discussions/deploying-python-applications.rst:7 msgid "2014-11-11" @@ -497,7 +585,7 @@ msgstr "Підтримка декількох апаратних платфор #: ../source/discussions/deploying-python-applications.rst:40 msgid "OS packaging & installers" -msgstr "" +msgstr "Пакування на рівні ОС та встановлювачі" #: ../source/discussions/deploying-python-applications.rst:52 msgid "Windows" @@ -516,6 +604,12 @@ msgid "" "tool downloads the specified Python-interpreter for Windows and packages it " "with all the dependencies in a single Windows-executable installer." msgstr "" +"`Pynsist `__ — це інструмент, який укладає " +"Python-програми разом із інтерпретатором Python у єдиний встановлювач на " +"основі NSIS. У більшості випадків пакування вимагає від користувача лише " +"вибору версії Python-інтерпретатора і оголошення залежностей програми. Цей " +"засіб завантажує вказаний інтерпретатор Python для Windows і загортає його з " +"усіма залежностями до єдиного Windows-виконуваного встановлювача." #: ../source/discussions/deploying-python-applications.rst:70 msgid "" @@ -524,6 +618,10 @@ msgid "" "application directory, independent of any other Python installation on the " "computer." msgstr "" +"Встановлену програму можна запустити черкз ярлик, який встановлювач додає до " +"меню \"Пуск\". Він використовує інтерпретатор Python, що знаходиться у " +"власній теці застосунку, незалежно від будь-якого іншого екземпляра Python " +"на тому ж комп’ютері." #: ../source/discussions/deploying-python-applications.rst:74 msgid "" @@ -532,14 +630,18 @@ msgid "" "GUI) in the `documentation `__. The tool is " "released under the MIT-licence." msgstr "" +"Значною перевагою Pynsist є те, що пакунки для Windows можуть бути зібрані " +"під Linux. У `документації `__ є кілька " +"прикладів різних видів програм (консольних, графічних). Інструмент доступний " +"під ліцензією MIT." #: ../source/discussions/deploying-python-applications.rst:80 msgid "Application bundles" -msgstr "" +msgstr "Колекції програм" #: ../source/discussions/deploying-python-applications.rst:91 msgid "Configuration management" -msgstr "Управління конфігурацією" +msgstr "Керування конфігуруванням" #: ../source/discussions/index.rst:4 msgid "" @@ -547,10 +649,13 @@ msgid "" "specific topic. If you're just trying to get stuff done, see :doc:`/guides/" "index`." msgstr "" +"**Обговорення** зосереджені на наданні вичерпної інформації щодо певної " +"теми. Якщо ви просто намагаєтеся виконати певну роботу, зверніться до :doc:`/" +"guides/index`." #: ../source/discussions/install-requires-vs-requirements.rst:5 msgid "install_requires vs requirements files" -msgstr "" +msgstr "install_requires проти файлів requirements" #: ../source/discussions/install-requires-vs-requirements.rst:12 #: ../source/guides/distributing-packages-using-setuptools.rst:382 @@ -564,23 +669,34 @@ msgid "" "correctly. When the project is installed by :ref:`pip`, this is the " "specification that is used to install its dependencies." msgstr "" +"``install_requires`` — ключове слово у :ref:`setuptools`-файлі :file:`setup." +"py`, яке слід використовувати для зазначення того, що проєкт потребує " +"**мінімально**, аби запускатися коректно. Коли проект інстальовано за " +"допомогою :ref:`pip`, це специфікація, яка використовується для встановлення " +"його залежностей." #: ../source/discussions/install-requires-vs-requirements.rst:19 msgid "" "For example, if the project requires A and B, your ``install_requires`` " "would be like so:" msgstr "" +"Наприклад, якщо проєкт потребує A чи B, ваш ``install_requires`` виглядатиме " +"ось так:" #: ../source/discussions/install-requires-vs-requirements.rst:29 msgid "" "Additionally, it's best practice to indicate any known lower or upper bounds." msgstr "" +"До того ж, позначення будь-яких відомих нижніх чи верхніх меж вважається " +"найкращою практикою." #: ../source/discussions/install-requires-vs-requirements.rst:31 msgid "" "For example, it may be known, that your project requires at least v1 of 'A', " "and v2 of 'B', so it would be like so:" msgstr "" +"Наприклад, може бути відомо, що ваш проєкт потребує щонайменше v1 залежності " +"'A' та v2 залежності 'B', тоді це виглядатиме отак:" #: ../source/discussions/install-requires-vs-requirements.rst:41 msgid "" @@ -588,6 +704,9 @@ msgid "" "of 'A' will indicate a break in compatibility, so it makes sense to not " "allow v2:" msgstr "" +"Крім того, може бути відомо, що проєкт A використовує семантичне " +"версіонування і що 'A' v2 означає несумісну зміну, тож має сенс не дозволяти " +"v2:" #: ../source/discussions/install-requires-vs-requirements.rst:51 msgid "" @@ -596,6 +715,10 @@ msgid "" "dependencies of your dependencies). This is overly-restrictive, and " "prevents the user from gaining the benefit of dependency upgrades." msgstr "" +"Закріплення точних версій залежностей у ``install_requires`` не вважається " +"найкращою практикою, так само, не варто вказувати під-залежності (тобто " +"залежності ваших залежностей). Це надміру обмежувально і перешкоджає " +"користувачам скористатися перевагами оновлення залежностей." #: ../source/discussions/install-requires-vs-requirements.rst:56 msgid "" @@ -605,17 +728,24 @@ msgid "" "what index or source). The where (i.e. how they are to be made \"Concrete" "\") is to be determined at install time using :ref:`pip` options. [1]_" msgstr "" +"Наостанок, важливо розуміти, що ``install_requires`` перелічує «Абстрактні» " +"залежності, тобто лише обмеження назв і версій, які не визначають звідки ті " +"залежності будуть заповнені (тобто, із якого реєстру чи джерела). Звідки (" +"тобто, яким чином вони мають стати «Конкретними») визначається під час " +"встановлення за допомогою опцій :ref:`pip`. [1]_" #: ../source/discussions/install-requires-vs-requirements.rst:64 #: ../source/tutorials/installing-packages.rst:460 msgid "Requirements files" -msgstr "" +msgstr "Файли requirements" #: ../source/discussions/install-requires-vs-requirements.rst:66 msgid "" ":ref:`Requirements Files ` described most simply, " "are just a list of :ref:`pip:pip install` arguments placed into a file." msgstr "" +":ref:`Файли requirements `, описуючи дуже спрощено, " +"це лише перелік аргументів для :ref:`pip:pip install`, записаних у файл." #: ../source/discussions/install-requires-vs-requirements.rst:69 msgid "" @@ -623,6 +753,9 @@ msgid "" "ref:`Requirements Files ` are often used to define " "the requirements for a complete Python environment." msgstr "" +"У той час як ``install_requires`` визначає залежності для єдиного проєкту, " +":ref:`файли requirements ` часто використовуються " +"для визначення залежностей для певного середовища Python environment." #: ../source/discussions/install-requires-vs-requirements.rst:73 msgid "" @@ -631,6 +764,10 @@ msgid "" "achieving :ref:`repeatable installations ` of a complete " "environment." msgstr "" +"У той час як залежності в ``install_requires`` мінімальні, файли " +"requirements часто містіть вичерпний перелік конкретних версій задля " +"досягнення :ref:`повторюваних встановлень ` повного " +"середовища." #: ../source/discussions/install-requires-vs-requirements.rst:78 msgid "" @@ -640,6 +777,11 @@ msgid "" "\"Concrete\", i.e. associated with a particular index or directory of " "packages. [1]_" msgstr "" +"У той час як залежності в ``install_requires`` «Абстрактні», тобто не " +"пов'язані із жодним конкретним реєстром, файли requirements часто містять " +"опції pip на кшталт ``--index-url`` чи ``--find-links``, щоб зробити " +"залежності «Конкретними», тобто асоційованими із певним реєстром чи " +"каталогом пакунків. [1]_" #: ../source/discussions/install-requires-vs-requirements.rst:84 msgid "" @@ -647,12 +789,18 @@ msgid "" "during an install, requirements files are not, and only are used when a user " "specifically installs them using ``python -m pip install -r``." msgstr "" +"У той час як pip автоматично аналізує метадані з ``install_requires`` під " +"час встановлення, цього не відбувається із файлами requirements, вони лиш " +"використовуються коли користувачі явно встановлюють їх через ``python -m pip " +"install -r``." #: ../source/discussions/install-requires-vs-requirements.rst:90 msgid "" "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad." "io/2013/07/setup-vs-requirement/." msgstr "" +"Щоб дізнатися більше про «Абстрактні» залежності проти «Конкретних», читайте " +"https://caremad.io/2013/07/setup-vs-requirement/." #: ../source/discussions/pip-vs-easy-install.rst:6 msgid "pip vs easy_install" @@ -666,6 +814,11 @@ msgid "" "Index (PyPI)>` using requirement specifiers, and automatically installing " "dependencies." msgstr "" +":ref:`easy_install `, тепер `застарілий `_, було " +"випущено у 2004 як частину :ref:`setuptools`. Він був помітний у ті часи, " +"завдяки встановленням :term:`пакунків ` із :term:`PyPI " +"` з використанням специфікаторів вимог і " +"автоматичному встановленню залежностей." #: ../source/discussions/pip-vs-easy-install.rst:14 msgid "" @@ -677,12 +830,19 @@ msgid "" "introducing the idea of :ref:`Requirements Files `, " "which gave users the power to easily replicate environments." msgstr "" +":ref:`pip` з'явився пізніше у 2008 році, як альтернатива :ref:`easy_install " +"`, хоча він все ще був значною мірою створений на базі " +"компонентів :ref:`setuptools`. Він виділявся тим, що *не* встановлював " +"пакунки ні як :term:`Eggs `, ні із :term:`Eggs ` (але натомість як " +"прості «пласкі» пакунки із :term:`sdists `), вводячи ідею :ref:`файлів requirements `, які " +"надавали користувачам можливість легко повторювати середовища." #: ../source/discussions/pip-vs-easy-install.rst:22 msgid "" "Here's a breakdown of the important differences between pip and the " "deprecated easy_install:" -msgstr "" +msgstr "Ось аналіз важливих розбіжностей між pip та застарілим easy_install:" #: ../source/discussions/pip-vs-easy-install.rst:25 msgid "**pip**" @@ -694,7 +854,7 @@ msgstr "**easy_install**" #: ../source/discussions/pip-vs-easy-install.rst:27 msgid "Installs from :term:`Wheels `" -msgstr "" +msgstr "Встановлення з :term:`колес `" #: ../source/discussions/pip-vs-easy-install.rst:27 #: ../source/discussions/pip-vs-easy-install.rst:38 @@ -720,7 +880,7 @@ msgstr "Ні" #: ../source/discussions/pip-vs-easy-install.rst:30 msgid "Uninstall Packages" -msgstr "" +msgstr "Видалення пакунків" #: ../source/discussions/pip-vs-easy-install.rst:30 msgid "Yes (``python -m pip uninstall``)" @@ -728,15 +888,15 @@ msgstr "Так (``python -m pip uninstall``)" #: ../source/discussions/pip-vs-easy-install.rst:32 msgid "Dependency Overrides" -msgstr "" +msgstr "Перевизначення залежностей" #: ../source/discussions/pip-vs-easy-install.rst:32 msgid "Yes (:ref:`Requirements Files `)" -msgstr "" +msgstr "Так (:ref:`Файли requirements `)" #: ../source/discussions/pip-vs-easy-install.rst:35 msgid "List Installed Packages" -msgstr "" +msgstr "Перелік встановлених пакунків" #: ../source/discussions/pip-vs-easy-install.rst:35 msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" @@ -748,23 +908,23 @@ msgstr "Підтримка :pep:`438`" #: ../source/discussions/pip-vs-easy-install.rst:41 msgid "Installation format" -msgstr "" +msgstr "Формат встановлення" #: ../source/discussions/pip-vs-easy-install.rst:41 msgid "'Flat' packages with :file:`egg-info` metadata." -msgstr "" +msgstr "«Пласкі» пакунки із метаданими в :file:`egg-info`." #: ../source/discussions/pip-vs-easy-install.rst:41 msgid "Encapsulated Egg format" -msgstr "" +msgstr "Інкапсульований формат Egg" #: ../source/discussions/pip-vs-easy-install.rst:44 msgid "sys.path modification" -msgstr "" +msgstr "Модифікація sys.path" #: ../source/discussions/pip-vs-easy-install.rst:48 msgid "Installs from :term:`Eggs `" -msgstr "" +msgstr "Встановлення із :term:`Eggs `" #: ../source/discussions/pip-vs-easy-install.rst:51 msgid "`pylauncher support`_" @@ -780,15 +940,15 @@ msgstr ":ref:`Багатоверсійні встановлення Date: Wed, 1 Sep 2021 22:29:42 +0200 Subject: [PATCH 0111/1072] Translated using Weblate (Chinese (Simplified)) Currently translated at 25.0% (570 of 2271 strings) Co-authored-by: xlivevil Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hans/ Translation: pypa/packaging.python.org --- locales/zh_Hans/LC_MESSAGES/messages.mo | Bin 100719 -> 100727 bytes locales/zh_Hans/LC_MESSAGES/messages.po | 7 ++++--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/locales/zh_Hans/LC_MESSAGES/messages.mo b/locales/zh_Hans/LC_MESSAGES/messages.mo index 7136caf1ec6cff05c6626eab191d706601659334..a3d93c5db85ccaf3e865a8a6aa196d95de131bc1 100644 GIT binary patch delta 12102 zcmZA72Y3}l+s5%(O6Vo@7J34q_t1MMNUxzoklv&SNDeLZ4k{o5N>c$TQUno@DoPJh zL@6Rwsvt=J{`b!0y}Z7?-iO~jvvX#5XJ_YZj_-qcLC@v|&B+jWp1_zK`HbC)8^iyM z$3Nw;B<93k_$f}to)}ufn3OmJQ{W=ZfvYeh?n8a>dcEefx^z>&eF~Z)QMMe)^#?+)YNytV%Qhc;o<;=5DM#YF8+*VJYzbRwjIqY zW6VSHPq7Wo;=bge-HixiE@RU23@7!s@CMI-bJ${a{*rkdw zJuq;C!fOhRsv5Hl8&u=$>F_q*$Iu$aOrSnPEo1tSFT^I~3F{d17F%FjS=X4#>|cjX z$#2)=#IRz0V>nk6g_;BNu`#a17>;lLra+%&a06rh#I3lTjutmG<_>wKNZU~upGr?& z54U0zR>$CX>@8}J_f?O&1r0gN(bx*<%A7)dJ_l!)9ZUEIjESW1I~Bb!80$7OCL6Xz z-J|zVS2zhZH!hCeoiYrkE z-i>;UE?^Wsz+i0D(wI!x5%qWtbDhQskCPQW4U zxc|es*H7EoA?eTM>fQ}UUEw%Pi_38^ZbA)pz7DosA!k|Cf>Irsf2KdC#x2hM&eOPt z`m4ABr*>rg_fV+N$&SEtQ@Q0m)ZC?3bs_yjcv3I=!x$1(yXaTOJtqwN*8?a9?s-x<~L>bu5p7t9^x2$kE^4%c;1MhVO90bk83T zWEk<#Anq%cVf>S0G-{3vLJegMZo)8*rb&AqHMI9pb89KXsD5@~dMw0nB*Uu6{(z}Z zK|6Y4B^-s}xDD0e6%50tm>WZe+1Xqb>yvlKjGXv7TuQ!=8FnALjxc5(U|peyS%%9vc(8>`UaR179RJlZZ$7f`b}@{QT@bX z1kS;F_#@`Qv}3s6SPC^~qHqkyH+5p{mF~wN@(Y-n6S#tz$RE%s5eAL5&vOb?UL5)M zHf2yJ8i8DkX@I?PAI`@jc<(zKpnCsQ0ICBK0hst1?` zUt=ju#fNmo)lmnIM4fmiOoGwQ{%-#;OiBG@WLlU7mJ9!NF6kt1&zIMbv?xxjgGshBi4JmYr%J zkLuIxkT=0l8ur9_I0KVouIYAG7s4#$^)U%{#T3{Zb)~~F9gasG_(RlO*@TtxXVge0 z4a~4hW+lu)MNce%6HpzjMRl+n6XUO#6t7@Hyp0;cd#K6z3iY&Pm}ytgN|>9xJr2Rq zsP^~q4-CAfP>8~nS3(XPsJrn zh%c}_zQGC@vB5s)gHcb*d{jS6a4&AaRyb%QEoq--JGYCx$G6r)*nzy@4pu>o4N%~- zCfiOsDNf)X@`~SawfF)#7c-ehfpahwzPBsfUDVuJv)fLt0(^+kHk&aHJM1-PCYJcY z_O~04k;m-gZwQRsZ|egWDR5iNCkN~h)<0;!ug76$>K`EAtft8!`}e^?Wb{n*VLSOU z{%9Y+p%_N}HdKGV<9j&mh<$Z?gL@f~K@1NMjwyN6e`O1plN4$u;Qk}WGSyGmdmD7p zURhquK>d2mi2G3Y{=CbdU<&f&r|jg)gvrQrqUKgX)KgPe^_)N#OikYBG$)}k97#b3 zSc^L2y;uUvFpl{!8Y|*dtbqqmvp?vJJ#Y+WA)kgi!4;SWcVHPj;_BZZgJ3fJ!fK0` zusz2&d(PUo*KFtP8eR{BsPBx4v8S^iCM6$&DRDIF%BQ&f3tYY!b%m=@>%dmjh;0=(H^)g zY6Pp|9PW7?)CHdX&F;U3I+44-G5+&t@Qex#*|bacgNraP`Et~~+>h!Y&UpoOBKJ^N z`V7^f{wCLnr9jPvw5WDrs1YcEy1;U%b`=8@>QJbL8md@SM>A0$Scn>-rMQg~U5A=f z-LKk7xe&9G$KgD@hi!4}AGV(h&OcG@9$;EbcFn%%1hP?3MM-B()QPmfycp&380RF^ zq??60(Z#NQm2*8Nq<$-E{|@H?=LzSp)_}S0DjqstI)nbS9RxdbI18Xou#~eR>K4>= zHo}DDEuC$h9h_ZIC)UF^z+`e2qfm1o7K`8l)TI0YwUET&WPF5qJSN|D+tDXCSo6tO zV<{Yb%TC6Xx9!q>2;cI#_wVq{DgUx>KoNK8i{qOK6ei-Zd&X?U7uXxu-si0cGd{3u z_ZS>Q-smCg1P3~Td+_Qb`^xp%W4`&w%RaFO=>Ly>$J>F8`P`DHJkodv>*2L$JpWlJ z6sEQY)<(_pNmvu-<8VBSm9g=2Mggbc6b{tsh5gCq=1co0+0j?_^N(;l?cQKD-1gc& zRZnp*`D>T&e#7%Wh>C-6_`?&+F;3wai&=1k^GDRsT}3^P%Z=whUK=q#`5}zPzfc#@ z%=7$7+6fPk_d(5x;t4!|T_}y|$SWoY*bg*z745MTJNmnZM^PsdhdS_G%z>{kJ7(o| zNbSp_I$VG{fiwj}-Q&c0?c~Xh5#)tYv${KKg$!U$oQs;o8!-T51}|a0LUs}*C~OZr9d+-QB7m#|k9hdPnl zs1bOGy0YXY?c~jX8nOBqj;&Db1DFISVOr(0D5&8w=Q`AyzXLTAB}&;dZ-tr*(O3{i zV`f~5>UbAwi1*_{M&<-oCht|o9&iO|6^+84q?dj6YH$cG=G zCdYDAM?w5|m@SwJOX5E4fKO2Ox*3mvZe0}WJE9lrOJ{=1m!L*)JF49&)Z=;ywPHTR zKn#T#e(uzY^cq`ZR8>#E&6v$t7N4SSNs(%H;dlo%LZ-Us|FK#PTav!TjNGc0H9Y^P z+&(ou|964aSdRTeYH>^0|0Q-M-&LFEe-nkAbv*x1ual@ZliGFd(9ggbVk?iviTs?l7FcY&wn2ZZ6ZDYKNjsn zjYQSPp8u+~1S^tfd&hR%3UzA+<2igE^;|b?V&_N~)KfAORlfrDoPXo;kfyf2D5{?- z0SdbJwNYo<3-#K47S+LX)V)sD%=7;qNRN7+vtlZ&g;CfHyW@JiiNVc1|Iha4s1q94 z!t?+0UM%h*4{hn01l)?ibqWWmxYf$@e>VTRwdcPDf7-^*)^%8l{RdDTKSQ0^<+h&x zQ_BO?QxM+HjzD!RK;9p9VIN{b+<_7JJ(kCRFt?unV(sk$(FD~|8(fV8umxs}vXiAZ zYSR6T4>5TM&wojMiSLnD?Z^SRqRpsVc&8JO7uN6WnSJ;k&ct$EJaZHeU~A@|ncLM4 z-K}oc$nN%?ZX;@8Nz=oA@2|ps*x8uSmy6ez(;VS9?!DBrCr#}-HlJZp^2XzAN25_4EWpIL67@WP zg?bmUb#GIyvBPI+4p5&Hg*6 zA!|Ct4s~bDN!}B6D`HWf{}9#gbJU4!LS5;1sQwP1PV5Ax(fj`y3YrvuqDJ5a`d2>H zHcW(dsZWL)sivro+M?QbM=iy@k@NKbDESe!wIeD}dB)G|Kc7P?HPoi(p9Rd{a`T84 zpqv`DW{b&sW!VSXQ8d0mTcsyDA&c}mwdDP{BP?>iTUXNMXSmrl$+vn?2LVh7er_GnRS%) zWuxsA;to-OgKPVMDD9VcH`MyC?JOVsok-{!&7*wSb*BCKsjr87iJGqd0Ok1YR|<=$ zS9f~ewKXTM5_6QW{Ymgn>u(!yF)=0!|FGDZbA-0L*bIx$9~YM0og8m|)bt@P5h0w) zJYWwVfj_ z5UV%&s@+8ET|Fq{V)8E?iZ%)b?*k9*A`*|z% z{|llT&GcI`>zp66FYvuRW)j1R<%BkUQTL{NOb=&9T{7EkB8tj?FuiNIl5#Q12?^d< z{QqwQRsP1SjlVtT-&MrdL@i<}p>3ese+v1kG|vd$$NX=aeAtCHTR6V|2N#%KRK6wR zx6-bBl!}GKheQ##GZzjarV;PDc7<^_@y4|g%Un67YqOO6jw?^3tmFHymU6NFVY@+t zA6=s@|iZMt)nxmQ*}M# z7w0_6*g9Fvr>@Z_xPZDsL^a|yc`u@S;h!MmZ+APCjuC16w9zjeaej`tctB9Y8#GGsbq95fw#5h9R zX+k4DpEybE)BQhA<>YPzRac5U6?W0tcy32SD*h(EATm*Z9jo9RB7Pf1;h9Uma`g?I(?CGZF42;@E#X zzK-%sqL{n5tEM2t5Hp=$+7lbVz{EI|dS(^j@SMq$phk1Qd`WpeWLd^r}*n zB1#dEsvtrTr3&JA|96J(b+7B;H_z;z-PzgM**zybnUm`NoK&;31s)|cCQm`*FMpIW zrZlAo7=_^^`LG=>!4cR4L&_Kvgkvy0PQ^Uk`g(XDbObZcH}}oTcy&g=()EvlOe;pv(?0U=oJZGG-$6De4&0n|um3CI5?~{EKz!F+OB{ zW1?BV7@Lt_Xh6fTSd1~W(KJGhfr%K0^Kcx;H`gh!Pm>sH%uQT{%h=JhhQ{0>FW%Vh zC_A6ZN?r-KVk4}HUK4wXYGab>QJ0`9tsIT@kX@MrsLuz{y4)D%8=%z`E>qDCvtU$n zV{%~(>Kb)Lo#AlQ*f@zAr04Jg-oRA2r-faA81=btF%+*jpJD=emX@}`gE5rjo6!_< z;yl!W*P(8squ3FzU>2;_%9!jJhq}GGIVWNm`3lT{hn%OeAo&$6gvnbQlMRdDIjoL> zyc9y(*fT1R+CdGM$Km(n?NJ{r(bjfhEj&!#8dG8}x<~87uozav?K=0d4I0Eo)2Sbi+CC7}&tA)sxRMQD z}W29G2|^VgoZE1kH|MM!jiE02(B;I zeA7OxcA{?EZ%`+22K#zk|7#Rb7l) z+Ho(`euiNs9FGm~OAJRdmRk=BpvFui9Lw=d#c}pbH)AUDqnMEfoWktnSJ)^8KE{Ih z+~xVl8^hDv6hbvL5;+%B1$*HpoQrwhvJKsUpOGKKMmTH&{XdDq0SYwI)SqYv(;-Yl zeiqeLS1=Ra!*ci!>Ws_qVI4Rc)$k^m8e2Q#-TLkrMEwY4SeQu|j!!0W{dJ$_oNQkp zil7EtJ=6h)qjop})sShp$>WKJ>e@!{*!6Q!UB3u-;%cmbiBqieF*o^f)PZlgJndAv zG95dNm}+m2GSh6A*T4uiY=d)f45q_O)9t9vg`wn?F*P>F^w=JCrrj|Z2cr%=88udx zV>IqU_2kn4g<=$n&#*nv1|!LbpmwkbwS#q-5|3dTJcY^e0;&fuqXy?))ZLO|rkz2H zV;Ffu9E^QX+y9K$F>sH98gObBlLS6TUCWN|+B52c1_9zor{7g0TO zA2sOG%;s|8V(gER@7W1#J~kr1hjn!SSD9mPi?O(j6|1oYHefHi@k8u}ZRaubajAA= z6nW11%n8^GYhk4YTng5Y#NOm@E#y&+cacsuyFcJEVa$h2a`++6=lJFVh4fSmTtqkH z7<`V!7xPqOhmlKc&qRM@FVSLL&iWlV06Q*ae#hg;xHKWlbXr_G9EiEuSUoWVbz(VI z*ar5-irVl;3hLtYAKR(1G@d7~g25QPlEz>JY7jL?U7|kN2?wJt$!X_R)S$eNS?~!C z#GIqy17>~_XGwA4%bvS~2(`v4eIm?q|DOI2}LT$}Nf&wi(lk?f=C@@>XA3x8dvLp*wip z!(jmmeAcAfX$QqV+(%w)7p=uRNL$PZZUx$4ite#9+$Gf5S+Lg*t{i-b-Zm@n3^v}+ zcLoeQVE4BUza#H|kVi5`AF}m<;}p0YX8K{T6JDXoDI9Z=f1F z3)O%HsQoR)bhrw2oDCP~{|pqiQjrA@VRHNtb(>tktQhr^y+jRBXVMw9gI+if`(rpJ zzi1B}f$G6hIGbx;5p{xJU$X1Zpc-=N68%4i4Q^4PE*tf;{oqtAKt3CFEjOcfaL9QI z)sV}mGrfh{;UB1mJx7fNeMi@J*-m=Za_U#1)~|7Haqe>-vj)tMuHvfmcjsfLchl}D$e9Dxzyi)< zs7p}JSq+nu*LB7?8#|k!8rI4;z+iF}y-{Oe7?!|Es6n|AHIW>`ckmj9dknr`?2e}Y z%A8L=AIo9lZ95p}{br}`ZTK&r>v@OofAV+x1{8UhU)ngn8A4$acE86hfp@SME=uB7 z!j$*z+}#hyl2`kKd4dD&z!J^V>DKOW*;u2a0&-%^0)oT=G=4pm2CG5`}u3Qo$Zsb z2Cn|c-c`Tie)4-RU-y#xe;^fGU$QeSOg|OHVHk=_onNB5?lkIloNYY+_F9I8$hTp4 zyofr1TAt?*(k6JAyaQ@XM!p2R^| zCJpPk)+GlaholzL-fKk{J>!7wY6Y7V3aEaVEy`m06#=h%InxCeQy#<`QxPnC_YF_8s{- zMEg06L3;ilr|>2f=TU>Nd9dgIMl%}IlCQ^J^uP|>MqZFF1=_(+sGnr7p(daz***Wq zr`p(kkcSQ1<+KMJmdi8mQXfE#>P)#k|C`V- zT+epp*jV$#^}L?{8_wK(p8un=$!{-3X=gMpXS-PZ7=K6g@VjB2|4z9Q17TFO3HMA_ z9D%x)7oE3J*Z2`?@T4!``M+%BMvdy0s2Oqq=EJv8gLoN+<6exxtH=~#iWamd7E#C! z+O387{Y8UsV1&J2FF9|c8uAb$Ib*M|&5M$#E2B_9Hpil#YHt_u{P|-Us$ut0gDrhg zdjjQA53N|#C2frruyfIX=fB&{qe5qJ5;dVD;m?@0m>ooaq7FQ|xaU73W+9zomY{lO zUkN)VPGTkUvo6nA($S1nW(>SdK^rb`u0+lG8&N$`q?~Pe z9BM4YV-XyJIdCy*$6HWcybBl7Gv8n|c|rwyz$K{pU=?n{4ag-3n64G=wOEMS;diK> z_yu)lsiTk`hGPcuYCPhyV=U@gC*b=y2Gx+@%696_iMnLvQ2VWi8vXI8?FRenx&KD` z1s;#irT7{fY(kyE11y21s@NXsh$YF#qZ+af3*%R)9p82Sg_>gjM)k}~R728Lwc8iK zV!HohDHOz^sKK!iwWF7~1yl0(n6kJNU&p(sYaPoipi9>h^^8bBJ#*O?*Q2&O zin?9TqGrt77#K%kI6rr4MtX#8u;pu>|DOLDRwPeCU6MjI?8H$Y)k9BlA6BaAnO67& zL%39pYkB@pxm{{|{_g@GVHE3o*Wr?|emN$RZ>h`uzmY=rdY=E)>j>)2B)Y!s`bjv0 z`~d0Y=DgSIE?*HBt znl|?QKNjso^+Z&h=f7&r!>Z)LP3(^2P?x3`p2LBt`#Pqn9V6{fcgbW_{UX$T{<+IT zn%VjY)P5=kDCpWpqgtAPdhI@e+Q9?Vwf35O{`Z0OsQWn!X25FL5o56{uEJZGwuR?^ zZGV7j&>Jm1|Id44QI{-lE6*h3QUoqj_=<|Ftv&x|^VMza4EKIpJ6cy_Io9t+?f5>b zVdvU;{!cBpPcnPZa@>fOa4S~Edl;tsziOf=rd;SlTH3rzOOTzxt zM-H^FYV&b8`4e1<{Ri1Mri_E_iR{H%)aM;yC!WrzDfn#+Xh&6s+IPKAaUETlYnbQ% zMsswyy{0`!F#416_kG;M_8Ujqhs=Ocp8u=Y$Ec~b^k_TS>Y}FR4lW;#ngM5EYFvmK z)XPTG|9L5VMuldoBd9@k9W&ywF`oY)5-y+)kan!+|MZd%3zN@BJ*4)aX2|QPi6+}P zds{a`9e5jRW;}?x8!n=Mca7uzuRw)|x~-y6XPAJeFyDClvUwj%lGl67?q~>V2Qx4w zE=JwYD^Tx(Yfux`CR79Vp|(5j^3$jjyd0pQF1d^9l7}vT>GD()?2a-!^I{6ND~8%( zY1Ca&5$obmtb;o+7XQK4*kGc4-Y-Gjp6gHz4V_6PM{ic z4!g7dI;zWJrr54-i}}bqp)SQ()aPfSw)+s(kTs|?-Hh7bZdAj*!AyGp|CWLV#U)e^ z{E7aVqc(hj_0gMZdnyLCqh_e>JED3h5oxEn#6LVn%x$q3$wj zDNQsa_9|`7H=ajW*TGsM2bxaZezdU#43DjtY z+v@V|xSZ%fT~79;r5AZD^N;`Ka zClX!VVai$x60cELm6$_h@f*VVmn30^HT4KB%$A1t1OHV?lasD(Hu7(YuL&*B@H<;H zCEXcm(Cwt22co}J#5X8C#&pE{w%Y8byo}H?PW}JXFWR5klWV2R#dBgS@eQH-ygl(N zQIqXX5l@ImgqB%E5z5~acPM{`7jXf>v&O$WG+_U`1g`%l>qa?}v(asn0q^jkdqgAh zUC7&(|Gyz#edH;5Dk3@C{*KjIv4c44Hh2d$t%tC_6YH5o{iTibPrY1Swsj`dRsKs} zj1OqhQ|cL!ojgtzZut^J=O#wv4wQGFszc2V%JYa%U0p}a$|nn9NB7B0Hj5?cW(do@&9&ylu9l6oRQ8o)ajM=3BmK( zpE<(u17bh%6ZLJ0GlZ7bL;;RijCC!Dy~G#(n*aTC+ZDgi>x-88Y}A%`pXg(&{P$Z| zG`xNKf0TWdzi@?H)coD>nU-C$Uq)P%%ObIt;?u0CeKcu6>kz+Qcz!t_?!BCsAUncm{?8(LaAKsc0z8x zbLA?OyHoxQnZN!2Lw6IuCQr#{R#HAgXxT|rqnv zmj5qnrtyL6#B?g+iOQ6J<@9XxBkE0~47$Z$net>KseDN6r@RW^#p0;_`2s0Ah zDQ|G=OW`h8F2hc{Qtm?JBQ~(@mqa_aJ|*R7%1NjtGgh|6|BcKUZskPWLxi!@SIg(* zKak|0EhDGVVZsGEd^h$@sHqn5Fh1N->r1o6GC^ZzZ# z0V+|-L46Bcf_;e|gqHj`3PZ4gq*iq9k#H^?fl|=RcifFUeA( z66GY+Qq%vJ`JTp{qkb%T9?D0tFu9gbiPL_Ghrg?PMBdYtXE~4HBv)SH%z|l?G5${R zfzc%W@PgafD`rr*&$=c=5C<~pq2r6kSOi8c}ZP<%B`u(i=}Zsb=@!) zr{ehl|GZkZxbj*mx=?Q8R;JtoKmMhgizn{Ib;Q7io&b S4d^zkZ}+0xR~Glq#Qz`DScb6x diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po index cc385ce67..cc8332b72 100644 --- a/locales/zh_Hans/LC_MESSAGES/messages.po +++ b/locales/zh_Hans/LC_MESSAGES/messages.po @@ -5,13 +5,14 @@ # Zuorong Zhang , 2021. # bluewindde <13548563428@139.com>, 2021. # Cube Kassaki <2524737581@qq.com>, 2021. +# xlivevil , 2021. msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-08-27 07:33+0000\n" -"Last-Translator: Cube Kassaki <2524737581@qq.com>\n" +"PO-Revision-Date: 2021-09-01 20:29+0000\n" +"Last-Translator: xlivevil \n" "Language-Team: Chinese (Simplified) \n" "Language: zh_Hans\n" @@ -1099,7 +1100,7 @@ msgstr "" #: ../source/glossary.rst:78 msgid "Module" -msgstr "模块(Module)" +msgstr "模块" #: ../source/glossary.rst:81 msgid "" From 8fa212bcd0a7da84ba8346bd0ff69c951fea7395 Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Thu, 2 Sep 2021 17:23:35 +0800 Subject: [PATCH 0112/1072] Add backquotes for commands --- source/specifications/direct-url.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/source/specifications/direct-url.rst b/source/specifications/direct-url.rst index 7df786cae..6a75181a4 100644 --- a/source/specifications/direct-url.rst +++ b/source/specifications/direct-url.rst @@ -278,18 +278,18 @@ Example pip commands and their effect on direct_url.json Commands that generate a ``direct_url.json``: -* pip install https://example.com/app-1.0.tgz -* pip install https://example.com/app-1.0.whl -* pip install "git+https://example.com/repo/app.git#egg=app&subdirectory=setup" -* pip install ./app -* pip install file:///home/user/app -* pip install --editable "git+https://example.com/repo/app.git#egg=app&subdirectory=setup" +* ``pip install https://example.com/app-1.0.tgz`` +* ``pip install https://example.com/app-1.0.whl`` +* ``pip install "git+https://example.com/repo/app.git#egg=app&subdirectory=setup"`` +* ``pip install ./app`` +* ``pip install file:///home/user/app`` +* ``pip install --editable "git+https://example.com/repo/app.git#egg=app&subdirectory=setup"`` (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``"editable": true`` and no ``vcs_info`` will be set) -* pip install -e ./app +* ``pip install -e ./app`` Commands that *do not* generate a ``direct_url.json`` -* pip install app -* pip install app --no-index --find-links https://example.com/ +* ``pip install app`` +* ``pip install app --no-index --find-links https://example.com/`` From 526ee6d6563855551bfee4d967a06823044ddbd4 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Thu, 2 Sep 2021 18:38:54 +0800 Subject: [PATCH 0113/1072] Fix broken links --- README.rst | 2 +- source/conf.py | 7 +++ source/contribute.rst | 10 ++-- .../deploying-python-applications.rst | 2 +- .../install-requires-vs-requirements.rst | 2 +- source/discussions/wheel-vs-egg.rst | 2 +- source/glossary.rst | 4 +- .../analyzing-pypi-package-downloads.rst | 3 +- .../creating-and-discovering-plugins.rst | 2 +- ...distributing-packages-using-setuptools.rst | 26 +++++------ source/guides/hosting-your-own-index.rst | 4 +- source/guides/index-mirrors-and-caches.rst | 2 +- .../guides/installing-scientific-packages.rst | 14 +++--- .../guides/installing-using-linux-tools.rst | 6 +-- .../guides/making-a-pypi-friendly-readme.rst | 6 +-- source/guides/packaging-binary-extensions.rst | 24 +++++----- .../single-sourcing-package-version.rst | 6 +-- .../supporting-multiple-python-versions.rst | 8 ++-- .../supporting-windows-using-appveyor.rst | 8 ++-- source/index.rst | 2 +- source/key_projects.rst | 46 +++++++++---------- source/overview.rst | 18 ++++---- .../binary-distribution-format.rst | 8 ++-- source/specifications/core-metadata.rst | 14 +++--- .../declaring-project-metadata.rst | 4 +- source/specifications/direct-url.rst | 6 +-- source/specifications/index.rst | 2 +- source/tutorials/creating-documentation.rst | 4 +- source/tutorials/installing-packages.rst | 10 ++-- source/tutorials/managing-dependencies.rst | 2 +- 30 files changed, 130 insertions(+), 124 deletions(-) diff --git a/README.rst b/README.rst index 0ec5f2bc4..eab80f1a8 100644 --- a/README.rst +++ b/README.rst @@ -7,7 +7,7 @@ The "Python Packaging User Guide" (PyPUG) aims to be the authoritative resource how to package and install distributions in Python using current tools. To follow the development of Python packaging, see the `Python -Packaging Authority `_. +Packaging Authority `_. Code of Conduct --------------- diff --git a/source/conf.py b/source/conf.py index 8213f988e..7ff4eb7c7 100644 --- a/source/conf.py +++ b/source/conf.py @@ -383,6 +383,13 @@ linkcheck_ignore = [ "http://localhost:\d+", + # Ignoring these links as they will redirect to login page if folks haven't logged in. + "https://github.com/pypa/packaging-problems/issues/new?template=general_issue.yml", + "https://github.com/pypa/packaging-problems/issues/new?template=packaging_tutorial.yml&title=Trouble+with+the+packaging+tutorial&guide=https://packaging.python.org/tutorials/packaging-projects", + # This shows that PyPI previously hosted at pypi.python.org + "https://pypi.python.org", + # Weblate has different UI for different languages + "https://weblate.org/", ] # Example configuration for intersphinx: refer to the Python standard library. diff --git a/source/contribute.rst b/source/contribute.rst index e51fab8e2..18e55e695 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -18,9 +18,9 @@ Most of the work on the |PyPUG| takes place on the `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `. -.. __: https://github.com/pypa/python-packaging-user-guide/ -.. __: https://github.com/pypa/python-packaging-user-guide/issues -.. __: https://github.com/pypa/python-packaging-user-guide/pulls +.. __: https://github.com/pypa/packaging.python.org/ +.. __: https://github.com/pypa/packaging.python.org/issues +.. __: https://github.com/pypa/packaging.python.org/pulls By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__. @@ -124,7 +124,7 @@ Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need: -1. `Nox `_. You can install or upgrade +1. `Nox `_. You can install or upgrade nox using ``pip``: .. code-block:: bash @@ -136,7 +136,7 @@ need: Python 3.6 on your operating system. .. _Hitchhiker's Guide to Python installation instructions: - http://docs.python-guide.org/en/latest/starting/installation/ + https://docs.python-guide.org/starting/installation/ To build the guide, run the following bash command in the source folder: diff --git a/source/discussions/deploying-python-applications.rst b/source/discussions/deploying-python-applications.rst index d1bd91c05..2c5fd3828 100644 --- a/source/discussions/deploying-python-applications.rst +++ b/source/discussions/deploying-python-applications.rst @@ -73,7 +73,7 @@ directory, independent of any other Python installation on the computer. A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in -the `documentation `__. The tool is released +the `documentation `__. The tool is released under the MIT-licence. Application bundles diff --git a/source/discussions/install-requires-vs-requirements.rst b/source/discussions/install-requires-vs-requirements.rst index 86bdf4781..95578bca8 100644 --- a/source/discussions/install-requires-vs-requirements.rst +++ b/source/discussions/install-requires-vs-requirements.rst @@ -88,4 +88,4 @@ installs them using ``python -m pip install -r``. ---- .. [1] For more on "Abstract" vs "Concrete" requirements, see - https://caremad.io/2013/07/setup-vs-requirement/. + https://caremad.io/posts/2013/07/setup-vs-requirement/. diff --git a/source/discussions/wheel-vs-egg.rst b/source/discussions/wheel-vs-egg.rst index a77657127..8368fd2c0 100644 --- a/source/discussions/wheel-vs-egg.rst +++ b/source/discussions/wheel-vs-egg.rst @@ -39,7 +39,7 @@ Here's a breakdown of the important differences between :term:`Wheel` and :term: specification and the implementation that packaged it. * :term:`Wheel` is internally organized by `sysconfig path type - `_, + `_, therefore making it easier to convert to other formats. ---- diff --git a/source/glossary.rst b/source/glossary.rst index c4ac86c7a..0c09cfe10 100644 --- a/source/glossary.rst +++ b/source/glossary.rst @@ -128,12 +128,12 @@ Glossary PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at - https://www.pypa.io, host projects on `GitHub + https://www.pypa.io/en/latest/, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ - and `the Python Discourse forum `__. + and `the Python Discourse forum `__. Python Package Index (PyPI) diff --git a/source/guides/analyzing-pypi-package-downloads.rst b/source/guides/analyzing-pypi-package-downloads.rst index abb3cc48b..f0b2c967d 100644 --- a/source/guides/analyzing-pypi-package-downloads.rst +++ b/source/guides/analyzing-pypi-package-downloads.rst @@ -83,7 +83,7 @@ include: +------------------------+-----------------+-----------------------------+ | file.version | Package version | ``0.1.6``, ``1.4.2`` | +------------------------+-----------------+-----------------------------+ -| details.installer.name | Installer | pip, `bandersnatch`_ | +| details.installer.name | Installer | pip, :ref:`bandersnatch` | +------------------------+-----------------+-----------------------------+ | details.python | Python version | ``2.7.12``, ``3.6.4`` | +------------------------+-----------------+-----------------------------+ @@ -304,7 +304,6 @@ References .. [#] `PyPI BigQuery dataset announcement email `__ .. _public PyPI download statistics dataset: https://console.cloud.google.com/bigquery?p=bigquery-public-data&d=pypi&page=dataset -.. _bandersnatch: /key_projects/#bandersnatch .. _Google BigQuery: https://cloud.google.com/bigquery .. _BigQuery web UI: https://console.cloud.google.com/bigquery .. _pypinfo: https://github.com/ofek/pypinfo/blob/master/README.rst diff --git a/source/guides/creating-and-discovering-plugins.rst b/source/guides/creating-and-discovering-plugins.rst index 783f1a9ed..53776ec54 100644 --- a/source/guides/creating-and-discovering-plugins.rst +++ b/source/guides/creating-and-discovering-plugins.rst @@ -171,5 +171,5 @@ Now the module of your choice can be imported by executing `, most packaging tools other than setuptools provide support for defining entry points. -.. _Setuptools: https://setuptools.readthedocs.io +.. _Setuptools: https://setuptools.readthedocs.io/en/latest/ .. _backport: https://importlib-metadata.readthedocs.io/en/latest/ diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index a179ea130..6fa724e07 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -57,7 +57,7 @@ setup.py The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py -`_ in the `PyPA +`_ in the `PyPA sample project `_. :file:`setup.py` serves two primary functions: @@ -78,7 +78,7 @@ setup.cfg :file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg -`_ in the `PyPA +`_ in the `PyPA sample project `_. @@ -87,13 +87,13 @@ README.rst / README.md All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText -`_ with an "rst" extension, although +`_ with an "rst" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument). For an example, see `README.md -`_ from the `PyPA +`_ from the `PyPA sample project `_. .. note:: Projects using :ref:`setuptools` 0.6.27+ have standard readme files @@ -113,7 +113,7 @@ writing a :file:`MANIFEST.in` file, including a list of what's included by default, see ":ref:`Using MANIFEST.in`". For an example, see the `MANIFEST.in -`_ from the `PyPA +`_ from the `PyPA sample project `_. .. note:: :file:`MANIFEST.in` does not affect binary distributions such as wheels. @@ -128,7 +128,7 @@ If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer. For an example, see the `LICENSE.txt -`_ from the `PyPA +`_ from the `PyPA sample project `_. @@ -139,7 +139,7 @@ Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close. For an example, see the `sample -`_ package that's +`_ package that's included in the `PyPA sample project `_. @@ -154,7 +154,7 @@ specific details of your project are defined. The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py -`_ contained in the +`_ contained in the `PyPA sample project `_. @@ -237,7 +237,7 @@ A `content type can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) -`_, +`_, and the Github-flavored Markdown dialect of `Markdown `_ respectively. @@ -477,7 +477,7 @@ Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution. For more information see the distutils section on `Installing Additional Files -`_. +`_. .. note:: @@ -491,7 +491,7 @@ For more information see the distutils section on `Installing Additional Files ~~~~~~~~~~~ Although ``setup()`` supports a `scripts -`_ +`_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below). @@ -576,7 +576,7 @@ Semantic versioning (preferred) ******************************* For new projects, the recommended versioning scheme is based on `Semantic Versioning -`_, but adopts a different approach to handling pre-releases and +`_, but adopts a different approach to handling pre-releases and build metadata. The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, @@ -592,7 +592,7 @@ Adopting this approach as a project author allows users to make use of :pep:`"co a matching MAJOR version. Python projects adopting semantic versioning should abide by clauses 1-8 of the -`Semantic Versioning 2.0.0 specification `_. +`Semantic Versioning 2.0.0 specification `_. Date based versioning ********************* diff --git a/source/guides/hosting-your-own-index.rst b/source/guides/hosting-your-own-index.rst index b0867aed3..785d6c83d 100644 --- a/source/guides/hosting-your-own-index.rst +++ b/source/guides/hosting-your-own-index.rst @@ -59,5 +59,5 @@ instruct users to add the URL to their installer's configuration. :pep:`503`. -.. _devpi: http://doc.devpi.net/latest/ -.. _Twisted: https://twistedmatrix.com/ +.. _devpi: https://devpi.net/docs/devpi/devpi/latest/%2Bd/index.html +.. _Twisted: https://twistedmatrix.com/trac/ diff --git a/source/guides/index-mirrors-and-caches.rst b/source/guides/index-mirrors-and-caches.rst index d960e7bee..18dc3463e 100644 --- a/source/guides/index-mirrors-and-caches.rst +++ b/source/guides/index-mirrors-and-caches.rst @@ -48,7 +48,7 @@ devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__. -__ http://doc.devpi.net/latest/quickstart-pypimirror.html +__ https://devpi.net/docs/devpi/devpi/latest/+d/quickstart-pypimirror.html Complete mirror with bandersnatch diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst index a978e4fba..0cf037927 100644 --- a/source/guides/installing-scientific-packages.rst +++ b/source/guides/installing-scientific-packages.rst @@ -13,9 +13,9 @@ it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software. -In particular, `NumPy `__, which provides the basis +In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack -`__ can be configured +`__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs. @@ -67,7 +67,7 @@ the CPython Windows installers published on python.org. For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers -`__. Many Python users on +`__. Many Python users on Windows have reported a positive experience with these prebuilt versions. As with Linux system packages, the Windows installers will only install into a @@ -92,14 +92,14 @@ published on python.org. macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack -`__ +`__ SciPy distributions ------------------- The SciPy site lists `several distributions -`__ that provide the full SciPy stack to +`__ that provide the full SciPy stack to end users in an easy to use and update format. Some of these distributions may not be compatible with the standard ``pip`` @@ -107,7 +107,7 @@ and ``virtualenv`` based toolchain. Spack ------ -`Spack `_ is a flexible package manager +`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. @@ -127,7 +127,7 @@ be loaded and unloaded from the user's environment. The conda cross-platform package manager ---------------------------------------- -`Anaconda `_ is a Python distribution +`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be diff --git a/source/guides/installing-using-linux-tools.rst b/source/guides/installing-using-linux-tools.rst index 8f12a4dfe..b4752d3aa 100644 --- a/source/guides/installing-using-linux-tools.rst +++ b/source/guides/installing-using-linux-tools.rst @@ -66,8 +66,8 @@ To install pip and wheel for the system Python, there are two options: 2. Enable the `PyPA Copr Repo - `_ using `these instructions - `__ [1]_. You can install + `_ using `these instructions + `__ [1]_. You can install pip and wheel like so: .. code-block:: bash @@ -89,7 +89,7 @@ To install pip, wheel, and setuptools, in a parallel, non-system environment includes pip, setuptools, and wheel. * For Redhat, see here: - http://developers.redhat.com/products/softwarecollections/overview/ + https://developers.redhat.com/products/softwarecollections/overview * For CentOS, see here: https://www.softwarecollections.org/en/ Be aware that collections may not contain the most recent versions. diff --git a/source/guides/making-a-pypi-friendly-readme.rst b/source/guides/making-a-pypi-friendly-readme.rst index 0cba44c2c..8eacff409 100644 --- a/source/guides/making-a-pypi-friendly-readme.rst +++ b/source/guides/making-a-pypi-friendly-readme.rst @@ -14,9 +14,9 @@ For your README to display properly on PyPI, choose a markup language supported Formats supported by `PyPI's README renderer `_ are: * plain text -* `reStructuredText `_ (without Sphinx extensions) +* `reStructuredText `_ (without Sphinx extensions) * Markdown (`GitHub Flavored Markdown `_ by default, - or `CommonMark `_) + or `CommonMark `_) It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file. @@ -97,7 +97,7 @@ If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source. Note that Sphinx extensions used in docstrings, such as -`directives and roles `_ +`directives and roles `_ (e.g., "``:py:func:`getattr```" or "``:ref:`my-reference-label```"), are not allowed here and will result in error messages like "``Error: Unknown interpreted text role "py:func".``". diff --git a/source/guides/packaging-binary-extensions.rst b/source/guides/packaging-binary-extensions.rst index 001787b97..6ddb72d7b 100644 --- a/source/guides/packaging-binary-extensions.rst +++ b/source/guides/packaging-binary-extensions.rst @@ -32,18 +32,18 @@ conventional categories: available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the - `datetime.py `_ + `datetime.py `_ module if the C implementation ( - `_datetimemodule.c `_) + `_datetimemodule.c `_) is not available. * **wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more "Pythonic" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. - *Example*: `functools.py `_ + *Example*: `functools.py `_ is a Python module wrapper for - `_functoolsmodule.c `_. + `_functoolsmodule.c `_. * **low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve @@ -51,7 +51,7 @@ conventional categories: standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from - `sysmodule.c `_. + `sysmodule.c `_. One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's @@ -120,7 +120,7 @@ also be considered: need to create your own accelerator module. * for long running applications, the JIT compiled `PyPy interpreter - `__ may offer a suitable alternative to the standard + `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the @@ -129,7 +129,7 @@ also be considered: an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem). -* `Cython `__ is a mature static compiler that can +* `Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional @@ -160,19 +160,19 @@ but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date. * In addition to being useful for the creation of accelerator modules, - `Cython `__ is also useful for creating wrapper + `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs. -* `pybind11 `__ is a pure C++11 library +* `pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam. -* `cffi `__ is a project created by some of the PyPy +* `cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its @@ -259,7 +259,7 @@ Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions. To set up a build environment for binary extensions, install -`Visual Studio Community Edition `__ +`Visual Studio Community Edition `__ - any recent version is fine. One caveat: if you use Visual Studio 2019 or later, your extension will depend @@ -304,7 +304,7 @@ Publishing binary extensions ============================ For interim guidance on this topic, see the discussion in -`this issue `_. +`this issue `_. :: diff --git a/source/guides/single-sourcing-package-version.rst b/source/guides/single-sourcing-package-version.rst index adbddb45a..1f6caa70e 100644 --- a/source/guides/single-sourcing-package-version.rst +++ b/source/guides/single-sourcing-package-version.rst @@ -9,7 +9,7 @@ There are many techniques to maintain a single source of truth for the version number of your project: #. Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py - `_):: + `_):: import codecs import os.path @@ -135,7 +135,7 @@ number of your project: then ``setuptools`` must be added to the project's ``install_requires`` list. - Example using this technique: `setuptools `_. + Example using this technique: `setuptools `_. #. Set the value to ``__version__`` in ``sample/__init__.py`` and import @@ -160,4 +160,4 @@ number of your project: #. Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using - `setuptools_scm `_. + `setuptools_scm `_. diff --git a/source/guides/supporting-multiple-python-versions.rst b/source/guides/supporting-multiple-python-versions.rst index c75dcc830..87bd693da 100644 --- a/source/guides/supporting-multiple-python-versions.rst +++ b/source/guides/supporting-multiple-python-versions.rst @@ -58,7 +58,7 @@ These services also offer facilities to run your project's test suite on 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: @@ -66,7 +66,7 @@ Windows: - `Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing. - - `Appveyor `_ provides a Windows environment + - `Appveyor `_ provides a Windows environment (Windows Server 2012). :: @@ -78,7 +78,7 @@ Windows: document? Both `Travis CI`_ and Appveyor_ require a `YAML -`_-formatted file as specification for the instructions +`_-formatted file as specification for the instructions for testing. If any tests fail, the output log for that specific configuration can be inspected. @@ -88,7 +88,7 @@ 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 +`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. diff --git a/source/guides/supporting-windows-using-appveyor.rst b/source/guides/supporting-windows-using-appveyor.rst index 567a2a1d9..ff7b4f235 100644 --- a/source/guides/supporting-windows-using-appveyor.rst +++ b/source/guides/supporting-windows-using-appveyor.rst @@ -39,7 +39,7 @@ 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 +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 @@ -237,8 +237,8 @@ For reference, the SDK setup support script is listed here: :language: bat :linenos: -.. _Appveyor: http://www.appveyor.com/ +.. _Appveyor: https://www.appveyor.com// .. _Travis: https://travis-ci.org/ -.. _Github: https://github.org/ +.. _Github: https://github.com/ .. _Bitbucket: https://bitbucket.org/ -.. _Tox: http://tox.testrun.org +.. _Tox: https://tox.readthedocs.io/en/latest/ diff --git a/source/index.rst b/source/index.rst index 2ec3e2e55..3a32ceaf2 100644 --- a/source/index.rst +++ b/source/index.rst @@ -28,7 +28,7 @@ tools. This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊 -.. _GitHub: https://github.com/pypa/python-packaging-user-guide +.. _GitHub: https://github.com/pypa/packaging.python.org .. _Python Packaging Authority: https://pypa.io diff --git a/source/key_projects.rst b/source/key_projects.rst index d6b8b4c9c..da077441b 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -34,7 +34,7 @@ Content Delivery Network (CDN). build ===== -`Docs `__ | +`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ @@ -48,7 +48,7 @@ build packages, as well as a Python API. cibuildwheel ============ -`Docs `__ | +`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | @@ -63,7 +63,7 @@ platforms and Python versions on most CI systems. Also see :ref:`multibuild`. distlib ======= -`Docs `__ | +`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__ @@ -89,7 +89,7 @@ of packages that are incompatible with those standards. packaging ========= -`Docs `__ | +`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ @@ -136,7 +136,7 @@ command-line interface (CLI). Pipenv ====== -`Docs `__ | +`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__ @@ -180,9 +180,9 @@ causing dependency conflicts with other packages installed on the system. Python Packaging User Guide =========================== -`Docs `__ | -`Issues `__ | -`GitHub `__ +`Docs `__ | +`Issues `__ | +`GitHub `__ This guide! @@ -192,7 +192,7 @@ readme_renderer =============== `GitHub and docs `__ | -`PyPI `__ +`PyPI `__ ``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup @@ -342,12 +342,12 @@ lets you create a buildout configuration and reproduce the same software later. conda ===== -`Docs `__ +`Docs `__ conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc -`__ specifically aimed at the scientific +`__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult. @@ -370,8 +370,8 @@ fetching them from PyPI and modifying their metadata. devpi ===== -`Docs `__ | -`Issues `__ | +`Docs `__ | +`Issues `__ | `PyPI `__ devpi features a powerful PyPI-compatible server and PyPI proxy cache @@ -406,8 +406,8 @@ Python 2, so long as they can be imported on Python 3. enscons ======= -`Source `__ | -`Issues `__ | +`Source `__ | +`Issues `__ | `PyPI `__ Enscons is a Python packaging tool based on `SCons`_. It builds @@ -420,7 +420,7 @@ build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons. -.. _SCons: http://scons.org/ +.. _SCons: https://scons.org/ .. _hashdist: @@ -502,7 +502,7 @@ piwheels ======== `Website `__ | -`Docs `__ | +`Docs `__ | `GitHub `__ piwheels is a website, and software underpinning it, that fetches @@ -580,9 +580,9 @@ applications and command line tools fast & easy. Spack ===== -`Docs `__ | -`GitHub `__ | -`Paper `__ | +`Docs `__ | +`GitHub `__ | +`Paper `__ | `Slides `__ A flexible package manager designed to support multiple versions, @@ -620,7 +620,7 @@ ensurepip ========= `Docs `__ | -`Issues `__ +`Issues `__ A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most @@ -634,7 +634,7 @@ distutils ========= `Docs `__ | -`Issues `__ +`Issues `__ The original Python packaging system, added to the standard library in Python 2.0. @@ -655,7 +655,7 @@ venv ==== `Docs `__ | -`Issues `__ +`Issues `__ A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more diff --git a/source/overview.rst b/source/overview.rst index c4fdaaf18..758f0587d 100644 --- a/source/overview.rst +++ b/source/overview.rst @@ -68,7 +68,7 @@ who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons -`_. +`_. However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version @@ -205,7 +205,7 @@ respective packaging guides. * `Heroku `_ * `Google App Engine `_ * `PythonAnywhere `_ -* `OpenShift `_ +* `OpenShift `_ * "Serverless" frameworks like `Zappa `_ In all these setups, the platform takes care of packaging and @@ -231,7 +231,7 @@ guides: * `Kivy `_ * `Beeware `_ * `Brython `_ -* `Flexx `_ +* `Flexx `_ If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the @@ -279,19 +279,19 @@ developers is a package ecosystem called `Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments -`_. +`_. Instructions on building and publishing for the Anaconda ecosystem: -* `Building libraries and applications with conda `_ -* `Transitioning a native Python package to Anaconda `_ +* `Building libraries and applications with conda `_ +* `Transitioning a native Python package to Anaconda `_ A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages: * `Enthought Canopy `_ -* `ActiveState ActivePython `_ +* `ActiveState ActivePython `_ * `WinPython `_ .. _bringing-your-own-python: @@ -415,12 +415,12 @@ virtualenv ^^^^^^^^^^ `Virtualenvs -`_ have +`_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool -`_ and +`_ and `osnap `_, both of which wrap virtualenvs in a self-contained way. diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst index 92079ce39..1bcd55010 100644 --- a/source/specifications/binary-distribution-format.rst +++ b/source/specifications/binary-distribution-format.rst @@ -311,10 +311,10 @@ checker only needs to establish that RECORD matches the signature. See -- http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html -- http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html -- http://self-issued.info/docs/draft-ietf-jose-json-web-key.html -- http://self-issued.info/docs/draft-jones-jose-json-private-key.html +- https://self-issued.info/docs/draft-ietf-jose-json-web-signature.html +- https://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html +- https://self-issued.info/docs/draft-ietf-jose-json-web-key.html +- https://self-issued.info/docs/draft-jones-jose-json-private-key.html Comparison to .egg diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst index 484960f22..cb22fcf92 100644 --- a/source/specifications/core-metadata.rst +++ b/source/specifications/core-metadata.rst @@ -237,11 +237,11 @@ A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description. Historically, PyPI supported descriptions in plain text and `reStructuredText -(reST) `_, +(reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 -`_) as many code hosting sites render +`_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when @@ -276,9 +276,9 @@ specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized: - ``GFM`` for `Github-flavored Markdown - `_ + `_ - ``CommonMark`` for `CommonMark - `_ + `_ Example:: @@ -728,9 +728,9 @@ Examples:: ---- .. [1] reStructuredText markup: - http://docutils.sourceforge.net/ + https://docutils.sourceforge.io/ -.. _`Python Package Index`: http://pypi.org/ +.. _`Python Package Index`: https://pypi.org/ .. [2] RFC 822 Long Header Fields: - http://www.freesoft.org/CIE/RFC/822/7.htm + https://www.freesoft.org/CIE/RFC/822/7.htm diff --git a/source/specifications/declaring-project-metadata.rst b/source/specifications/declaring-project-metadata.rst index 2a54f1640..639a5bb3b 100644 --- a/source/specifications/declaring-project-metadata.rst +++ b/source/specifications/declaring-project-metadata.rst @@ -303,5 +303,5 @@ provided via tooling later on. value, is acceptable). -.. _RFC 822: https://tools.ietf.org/html/rfc822 -.. _TOML: https://toml.io/ +.. _RFC 822: https://datatracker.ietf.org/doc/html/rfc822 +.. _TOML: https://toml.io/en/ diff --git a/source/specifications/direct-url.rst b/source/specifications/direct-url.rst index 7df786cae..1b5e385db 100644 --- a/source/specifications/direct-url.rst +++ b/source/specifications/direct-url.rst @@ -24,7 +24,7 @@ This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier). This JSON file MUST be a dictionary, compliant with `RFC 8259 -`_ and UTF-8 encoded. +`_ and UTF-8 encoded. If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be @@ -82,7 +82,7 @@ present as a dictionary with the following key: in editable mode, ``false`` otherwise. If absent, default to ``false``. When ``url`` refers to a local directory, it MUST have the ``file`` sheme and -be compliant with `RFC 8089 `_. In +be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute. @@ -178,7 +178,7 @@ Bazaar Home page - https://bazaar.canonical.com/ + https://bazaar.canonical.com/en/ vcs command diff --git a/source/specifications/index.rst b/source/specifications/index.rst index 6a282b243..38cf068c9 100644 --- a/source/specifications/index.rst +++ b/source/specifications/index.rst @@ -6,7 +6,7 @@ PyPA specifications This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on -`pypa.io `__. +`pypa.io `__. Package Distribution Metadata diff --git a/source/tutorials/creating-documentation.rst b/source/tutorials/creating-documentation.rst index 392220f31..633be9048 100644 --- a/source/tutorials/creating-documentation.rst +++ b/source/tutorials/creating-documentation.rst @@ -6,7 +6,7 @@ Creating Documentation This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_. -.. _Sphinx: http://sphinx-doc.org/ +.. _Sphinx: https://www.sphinx-doc.org/en/master/ .. _Read The Docs: https://readthedocs.org/ Installing Sphinx @@ -27,7 +27,7 @@ Use ``pip`` to install Sphinx: For other installation methods, see this `installation guide`_ by Sphinx. -.. _installation guide: http://www.sphinx-doc.org/en/master/usage/installation.html +.. _installation guide: https://www.sphinx-doc.org/en/master/usage/installation.html Getting Started With Sphinx --------------------------- diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst index f6bb02b79..201a15d97 100644 --- a/source/tutorials/installing-packages.rst +++ b/source/tutorials/installing-packages.rst @@ -93,7 +93,7 @@ please install the latest 3.x version from `python.org`_ or refer to the set one up, and then continue with the tutorial as written. .. _getting started tutorial: https://opentechschool.github.io/python-beginners/en/getting_started.html#what-is-python-exactly -.. _python.org: https://python.org +.. _python.org: https://www.python.org/ Ensure you can run pip from the command line -------------------------------------------- @@ -119,7 +119,7 @@ using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`. .. _Homebrew: https://brew.sh -.. _Installing Python: http://docs.python-guide.org/en/latest/starting/installation/ +.. _Installing Python: https://docs.python-guide.org/starting/installation/ If ``pip`` isn't already installed, then first try to bootstrap it from the standard library: @@ -271,7 +271,7 @@ Using :ref:`virtualenv`:

\Scripts\activate For more information, see the :doc:`venv ` docs or -the `virtualenv `_ docs. +the `virtualenv `_ docs. The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current @@ -432,7 +432,7 @@ current user, use the ``--user`` flag: py -m pip install --user SomeProject For more information see the `User Installs -`_ section +`_ section from the pip docs. Note that the ``--user`` flag has no effect when inside a virtual environment @@ -463,7 +463,7 @@ directory to your :envvar:`PATH`: .. _user base: https://docs.python.org/3/library/site.html#site.USER_BASE .. _modifying ~/.profile: https://stackoverflow.com/a/14638025 -.. _Control Panel: https://msdn.microsoft.com/en-us/library/windows/desktop/bb776899(v=vs.85).aspx +.. _Control Panel: https://docs.microsoft.com/en-us/windows/win32/shell/user-environment-variables?redirectedfrom=MSDN Requirements files ================== diff --git a/source/tutorials/managing-dependencies.rst b/source/tutorials/managing-dependencies.rst index 6eb94b1b6..ac8535410 100644 --- a/source/tutorials/managing-dependencies.rst +++ b/source/tutorials/managing-dependencies.rst @@ -58,7 +58,7 @@ Use ``pip`` to install Pipenv: See :ref:`Installing to the User Site` for more information. .. _npm: https://www.npmjs.com/ -.. _bundler: http://bundler.io/ +.. _bundler: https://bundler.io/ .. _user installation: https://pip.pypa.io/en/stable/user_guide/#user-installs Installing packages for your project From fd5900849ed07f99e10f9c129a4be1b4799619c8 Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Thu, 2 Sep 2021 21:26:11 +0800 Subject: [PATCH 0114/1072] Use `--editable`` instead of `-e` Co-authored-by: Brian Rutledge --- source/specifications/direct-url.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/direct-url.rst b/source/specifications/direct-url.rst index 6a75181a4..105653699 100644 --- a/source/specifications/direct-url.rst +++ b/source/specifications/direct-url.rst @@ -287,7 +287,7 @@ Commands that generate a ``direct_url.json``: (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``"editable": true`` and no ``vcs_info`` will be set) -* ``pip install -e ./app`` +* ``pip install --editable ./app`` Commands that *do not* generate a ``direct_url.json`` From 0c30fbad801118cc004ddfd9b528f2c31276534b Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Thu, 2 Sep 2021 21:28:39 +0800 Subject: [PATCH 0115/1072] Fix broken links --- source/index.rst | 2 +- source/overview.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/source/index.rst b/source/index.rst index 3a32ceaf2..8f5909f81 100644 --- a/source/index.rst +++ b/source/index.rst @@ -29,7 +29,7 @@ This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊 .. _GitHub: https://github.com/pypa/packaging.python.org -.. _Python Packaging Authority: https://pypa.io +.. _Python Packaging Authority: https://www.pypa.io/en/latest/ Get started diff --git a/source/overview.rst b/source/overview.rst index 758f0587d..d4378ca88 100644 --- a/source/overview.rst +++ b/source/overview.rst @@ -206,7 +206,7 @@ respective packaging guides. * `Google App Engine `_ * `PythonAnywhere `_ * `OpenShift `_ -* "Serverless" frameworks like `Zappa `_ +* "Serverless" frameworks like `Zappa `_ In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does From 32f3585d511398fa8d0c94f63338b4f9868e8a9b Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Thu, 2 Sep 2021 21:28:56 +0800 Subject: [PATCH 0116/1072] Add more links to ignore in linkcheck --- source/conf.py | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/source/conf.py b/source/conf.py index 7ff4eb7c7..e681a8256 100644 --- a/source/conf.py +++ b/source/conf.py @@ -384,12 +384,14 @@ linkcheck_ignore = [ "http://localhost:\d+", # Ignoring these links as they will redirect to login page if folks haven't logged in. - "https://github.com/pypa/packaging-problems/issues/new?template=general_issue.yml", - "https://github.com/pypa/packaging-problems/issues/new?template=packaging_tutorial.yml&title=Trouble+with+the+packaging+tutorial&guide=https://packaging.python.org/tutorials/packaging-projects", + "https://github.com/pypa/packaging-problems/issues/new?/*", + "https://console.cloud.google.com/bigquery/*", # This shows that PyPI previously hosted at pypi.python.org "https://pypi.python.org", # Weblate has different UI for different languages "https://weblate.org/", + # This is an example that showing to folks + "https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE", ] # Example configuration for intersphinx: refer to the Python standard library. From ec8784c2b592f93f4d2a275d18717fcfebb3a759 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Thu, 2 Sep 2021 16:26:42 +0200 Subject: [PATCH 0117/1072] Adjust the translation lookup dir in Sphinx config --- source/conf.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/source/conf.py b/source/conf.py index 8213f988e..4d3e8dcf3 100644 --- a/source/conf.py +++ b/source/conf.py @@ -89,6 +89,8 @@ # Usually you set "language" from the command line for these cases. language = None +locale_dirs = ['../locales'] + # making all documents use single text domain gettext_compact = "messages" From e6f537ce4935b04039cb0ef22161a3b7ff630d90 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Thu, 2 Sep 2021 16:31:41 +0200 Subject: [PATCH 0118/1072] Bypass positional CLI args to underlying cmd @ nox --- noxfile.py | 1 + 1 file changed, 1 insertion(+) diff --git a/noxfile.py b/noxfile.py index 0a47e123e..225433b50 100644 --- a/noxfile.py +++ b/noxfile.py @@ -43,6 +43,7 @@ def build(session, autobuild=False): "-b", "html", # use HTML builder "-n", # nitpicky warn about all missing references "-W", # Treat warnings as errors. + *session.posargs, "source", # where the rst files are located target_build_dir, # where to put the html output ) From 608f2864d2a5494d409f25fd4ea23f10f9b381bc Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Thu, 2 Sep 2021 23:57:02 +0800 Subject: [PATCH 0119/1072] Fix broken links --- source/guides/analyzing-pypi-package-downloads.rst | 2 +- source/guides/installing-using-linux-tools.rst | 4 ++-- source/guides/packaging-binary-extensions.rst | 2 +- source/guides/packaging-namespace-packages.rst | 2 +- ...ibution-releases-using-github-actions-ci-cd-workflows.rst | 2 +- source/overview.rst | 5 ++--- source/specifications/index.rst | 2 +- source/tutorials/installing-packages.rst | 2 +- 8 files changed, 10 insertions(+), 11 deletions(-) diff --git a/source/guides/analyzing-pypi-package-downloads.rst b/source/guides/analyzing-pypi-package-downloads.rst index f0b2c967d..f66cd5132 100644 --- a/source/guides/analyzing-pypi-package-downloads.rst +++ b/source/guides/analyzing-pypi-package-downloads.rst @@ -53,7 +53,7 @@ In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card -`__ +`__ - Navigate to the `BigQuery web UI`_. - Create a new project. diff --git a/source/guides/installing-using-linux-tools.rst b/source/guides/installing-using-linux-tools.rst index b4752d3aa..790a405e6 100644 --- a/source/guides/installing-using-linux-tools.rst +++ b/source/guides/installing-using-linux-tools.rst @@ -94,9 +94,9 @@ To install pip, wheel, and setuptools, in a parallel, non-system environment Be aware that collections may not contain the most recent versions. -2. Enable the `IUS repository `_ and +2. Enable the `IUS repository `_ and install one of the `parallel-installable - `_ + `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date. diff --git a/source/guides/packaging-binary-extensions.rst b/source/guides/packaging-binary-extensions.rst index 6ddb72d7b..ded99d85a 100644 --- a/source/guides/packaging-binary-extensions.rst +++ b/source/guides/packaging-binary-extensions.rst @@ -165,7 +165,7 @@ wrapper modules up to date. hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs. -* `pybind11 `__ is a pure C++11 library +* `pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It diff --git a/source/guides/packaging-namespace-packages.rst b/source/guides/packaging-namespace-packages.rst index dd3c0f4b7..13d93cd31 100644 --- a/source/guides/packaging-namespace-packages.rst +++ b/source/guides/packaging-namespace-packages.rst @@ -236,7 +236,7 @@ to :func:`~setuptools.setup` in :file:`setup.py`. For example: A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_. -.. _setuptools: https://setuptools.readthedocs.io +.. _setuptools: https://setuptools.readthedocs.io/en/latest/ .. _pkg_resources.declare_namespace: https://setuptools.readthedocs.io/en/latest/setuptools.html#namespace-packages .. _pkg_resources namespace example project: diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index bd8ea42eb..6d5171543 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -144,4 +144,4 @@ sure that your release pipeline remains healthy! .. _`pypa/gh-action-pypi-publish GitHub Action`: https://github.com/marketplace/actions/pypi-publish .. _Secrets: - https://help.github.com/en/articles/virtual-environments-for-github-actions#creating-and-using-secrets-encrypted-variables + https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#creating-and-using-secrets-encrypted-variables diff --git a/source/overview.rst b/source/overview.rst index d4378ca88..77c7d2501 100644 --- a/source/overview.rst +++ b/source/overview.rst @@ -290,7 +290,6 @@ A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages: -* `Enthought Canopy `_ * `ActiveState ActivePython `_ * `WinPython `_ @@ -362,7 +361,7 @@ data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include: * `Vagrant `_ -* `VHD `_, `AMI `_, and `other formats `_ +* `VHD `_, `AMI `_, and `other formats `_ * `OpenStack `_ - A cloud management system in Python, with extensive VM support Bringing your own hardware @@ -405,7 +404,7 @@ Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM -`_ to +`_ to generate both deb and RPMs from the same source. In most deployment pipelines, the OS package manager is just one piece diff --git a/source/specifications/index.rst b/source/specifications/index.rst index 38cf068c9..6a282b243 100644 --- a/source/specifications/index.rst +++ b/source/specifications/index.rst @@ -6,7 +6,7 @@ PyPA specifications This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on -`pypa.io `__. +`pypa.io `__. Package Distribution Metadata diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst index 201a15d97..7f3c02335 100644 --- a/source/tutorials/installing-packages.rst +++ b/source/tutorials/installing-packages.rst @@ -462,7 +462,7 @@ directory to your :envvar:`PATH`: ``PATH`` changes to take effect. .. _user base: https://docs.python.org/3/library/site.html#site.USER_BASE -.. _modifying ~/.profile: https://stackoverflow.com/a/14638025 +.. _modifying ~/.profile: https://stackoverflow.com/questions/14637979/how-to-permanently-set-path-on-linux-unix/14638025#14638025 .. _Control Panel: https://docs.microsoft.com/en-us/windows/win32/shell/user-environment-variables?redirectedfrom=MSDN Requirements files From 920c1d35e0ff5c7111887befbfd1449b3ac94a77 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Thu, 2 Sep 2021 23:58:03 +0800 Subject: [PATCH 0120/1072] Add more links to ignore in linkcheck --- source/conf.py | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/source/conf.py b/source/conf.py index e681a8256..36155bdff 100644 --- a/source/conf.py +++ b/source/conf.py @@ -381,11 +381,16 @@ 'user': (f'{github_sponsors_url}/%s', '@'), # noqa: WPS323 } +linkcheck_anchors = False + linkcheck_ignore = [ "http://localhost:\d+", # Ignoring these links as they will redirect to login page if folks haven't logged in. "https://github.com/pypa/packaging-problems/issues/new?/*", "https://console.cloud.google.com/bigquery/*", + "https://console.developers.google.com/apis/library/bigquery-json.googleapis.com", + "https://test.pypi.org/manage/account/#api-tokens", + "https://pypi.org/manage/account/#api-tokens", # This shows that PyPI previously hosted at pypi.python.org "https://pypi.python.org", # Weblate has different UI for different languages From ae43f328fd11de43c8385bf37ca5ee6bc68f4631 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Fri, 3 Sep 2021 18:27:53 +0800 Subject: [PATCH 0121/1072] Revert "Use `--editable`` instead of `-e`" This reverts commit fd5900849ed07f99e10f9c129a4be1b4799619c8. --- source/specifications/direct-url.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/direct-url.rst b/source/specifications/direct-url.rst index 105653699..6a75181a4 100644 --- a/source/specifications/direct-url.rst +++ b/source/specifications/direct-url.rst @@ -287,7 +287,7 @@ Commands that generate a ``direct_url.json``: (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``"editable": true`` and no ``vcs_info`` will be set) -* ``pip install --editable ./app`` +* ``pip install -e ./app`` Commands that *do not* generate a ``direct_url.json`` From 248a843ee3d5e0846c511d4a8b088e755e55931c Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Fri, 3 Sep 2021 19:49:42 +0800 Subject: [PATCH 0122/1072] Add more docs to `intersphinx_mapping` --- source/conf.py | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/source/conf.py b/source/conf.py index 36155bdff..a2d11a8da 100644 --- a/source/conf.py +++ b/source/conf.py @@ -406,6 +406,14 @@ 'pip': ('https://pip.pypa.io/en/latest/', None), 'setuptools': ('https://setuptools.readthedocs.io/en/latest/', None), 'twine': ('https://twine.readthedocs.io/en/stable/', None), + 'pypa': ('https://www.pypa.io/en/latest/', None), + 'nox': ('https://nox.thea.codes/en/latest/', None), + 'pynsist': ('https://pynsist.readthedocs.io/en/latest/', None), + 'scipy': ('https://www.scipy.org', None), + 'sphinx': ('https://www.sphinx-doc.org/en/master', None), + 'pybind11': ('https://pybind11.readthedocs.io/en/stable/', None), + 'cffi': ('https://cffi.readthedocs.io/en/latest/', None), + } From e497eb0cd46014d799f6d02c1bb57e6c2592de31 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Fri, 3 Sep 2021 21:42:24 +0800 Subject: [PATCH 0123/1072] Use intersphinx references --- README.rst | 4 ++-- source/contribute.rst | 9 +++------ source/discussions/deploying-python-applications.rst | 2 +- 3 files changed, 6 insertions(+), 9 deletions(-) diff --git a/README.rst b/README.rst index eab80f1a8..93bfd771e 100644 --- a/README.rst +++ b/README.rst @@ -6,8 +6,8 @@ http://packaging.python.org The "Python Packaging User Guide" (PyPUG) aims to be the authoritative resource on how to package and install distributions in Python using current tools. -To follow the development of Python packaging, see the `Python -Packaging Authority `_. +To follow the development of Python packaging, see the :doc:`Python +Packaging Authority `. Code of Conduct --------------- diff --git a/source/contribute.rst b/source/contribute.rst index 18e55e695..155945d23 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -124,7 +124,7 @@ Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need: -1. `Nox `_. You can install or upgrade +1. :doc:`Nox `. You can install or upgrade nox using ``pip``: .. code-block:: bash @@ -132,11 +132,8 @@ need: python -m pip install --user nox 2. Python 3.6. Our build scripts are designed to work with Python 3.6 only. - See the `Hitchhiker's Guide to Python installation instructions`_ to install - Python 3.6 on your operating system. - -.. _Hitchhiker's Guide to Python installation instructions: - https://docs.python-guide.org/starting/installation/ + See the :doc:`Hitchhiker's Guide to Python installation instructions ` + to install Python 3.6 on your operating system. To build the guide, run the following bash command in the source folder: diff --git a/source/discussions/deploying-python-applications.rst b/source/discussions/deploying-python-applications.rst index 2c5fd3828..de781d9fd 100644 --- a/source/discussions/deploying-python-applications.rst +++ b/source/discussions/deploying-python-applications.rst @@ -73,7 +73,7 @@ directory, independent of any other Python installation on the computer. A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in -the `documentation `__. The tool is released +the `documentation `. The tool is released under the MIT-licence. Application bundles From f8a55b27b9fa880aaef89bf155b432e2890c7c7d Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Fri, 3 Sep 2021 21:42:30 +0800 Subject: [PATCH 0124/1072] Add more docs to `intersphinx_mapping` --- source/conf.py | 1 + 1 file changed, 1 insertion(+) diff --git a/source/conf.py b/source/conf.py index a2d11a8da..7b87775b7 100644 --- a/source/conf.py +++ b/source/conf.py @@ -413,6 +413,7 @@ 'sphinx': ('https://www.sphinx-doc.org/en/master', None), 'pybind11': ('https://pybind11.readthedocs.io/en/stable/', None), 'cffi': ('https://cffi.readthedocs.io/en/latest/', None), + 'python-guide': ('https://docs.python-guide.org', None), } From e421cd203f06be4f2d6159cdb4c269ad12051fac Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 4 Sep 2021 00:45:02 +0800 Subject: [PATCH 0125/1072] Update the config of `linkcheck` and `intersphinx` --- source/conf.py | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/source/conf.py b/source/conf.py index 4d3e8dcf3..e2ee8ec87 100644 --- a/source/conf.py +++ b/source/conf.py @@ -385,6 +385,11 @@ linkcheck_ignore = [ "http://localhost:\d+", + # This is an example that showing to the reader + "https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE", + # Ignoring it as it will redirect to login page if reader hasn't logged in. + "https://pypi.org/manage/*", + "https://test.pypi.org/manage/*", ] # Example configuration for intersphinx: refer to the Python standard library. @@ -394,6 +399,9 @@ 'pip': ('https://pip.pypa.io/en/latest/', None), 'setuptools': ('https://setuptools.readthedocs.io/en/latest/', None), 'twine': ('https://twine.readthedocs.io/en/stable/', None), + 'tox': ('https://tox.readthedocs.io/en/latest/', None), + 'scipy': ('https://www.scipy.org', None), + 'openstack': ('https://docs.openstack.org/glance/latest/', None), } From 77bc4c2f31a578c4465cdf53dc4fdb4399f46724 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 4 Sep 2021 00:45:09 +0800 Subject: [PATCH 0126/1072] Fix broken links --- .../analyzing-pypi-package-downloads.rst | 3 +-- ...distributing-packages-using-setuptools.rst | 2 +- .../guides/installing-scientific-packages.rst | 4 ++-- .../guides/installing-using-linux-tools.rst | 4 ++-- ...ing-using-pip-and-virtual-environments.rst | 2 +- .../guides/packaging-namespace-packages.rst | 2 +- ...s-using-github-actions-ci-cd-workflows.rst | 2 +- .../supporting-multiple-python-versions.rst | 2 +- .../supporting-windows-using-appveyor.rst | 4 ++-- source/key_projects.rst | 6 +++--- source/overview.rst | 20 +++++++++---------- source/tutorials/installing-packages.rst | 2 +- 12 files changed, 25 insertions(+), 28 deletions(-) diff --git a/source/guides/analyzing-pypi-package-downloads.rst b/source/guides/analyzing-pypi-package-downloads.rst index abb3cc48b..f0b2c967d 100644 --- a/source/guides/analyzing-pypi-package-downloads.rst +++ b/source/guides/analyzing-pypi-package-downloads.rst @@ -83,7 +83,7 @@ include: +------------------------+-----------------+-----------------------------+ | file.version | Package version | ``0.1.6``, ``1.4.2`` | +------------------------+-----------------+-----------------------------+ -| details.installer.name | Installer | pip, `bandersnatch`_ | +| details.installer.name | Installer | pip, :ref:`bandersnatch` | +------------------------+-----------------+-----------------------------+ | details.python | Python version | ``2.7.12``, ``3.6.4`` | +------------------------+-----------------+-----------------------------+ @@ -304,7 +304,6 @@ References .. [#] `PyPI BigQuery dataset announcement email `__ .. _public PyPI download statistics dataset: https://console.cloud.google.com/bigquery?p=bigquery-public-data&d=pypi&page=dataset -.. _bandersnatch: /key_projects/#bandersnatch .. _Google BigQuery: https://cloud.google.com/bigquery .. _BigQuery web UI: https://console.cloud.google.com/bigquery .. _pypinfo: https://github.com/ofek/pypinfo/blob/master/README.rst diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index a179ea130..b1c59ecd8 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -536,7 +536,7 @@ generated during the install of your :term:`distribution `. For more information, see `Automatic Script Creation -`_ +`_ from the :doc:`setuptools docs `. .. _`Choosing a versioning scheme`: diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst index a978e4fba..0a81484df 100644 --- a/source/guides/installing-scientific-packages.rst +++ b/source/guides/installing-scientific-packages.rst @@ -91,8 +91,8 @@ published on python.org. macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to -install the `scientific Python stack -`__ +install the :ref:`scientific Python stack +` SciPy distributions diff --git a/source/guides/installing-using-linux-tools.rst b/source/guides/installing-using-linux-tools.rst index 8f12a4dfe..75add0d37 100644 --- a/source/guides/installing-using-linux-tools.rst +++ b/source/guides/installing-using-linux-tools.rst @@ -94,9 +94,9 @@ To install pip, wheel, and setuptools, in a parallel, non-system environment Be aware that collections may not contain the most recent versions. -2. Enable the `IUS repository `_ and +2. Enable the `IUS repository `_ and install one of the `parallel-installable - `_ + `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date. diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst index 16b7a2cfb..eabc0796a 100644 --- a/source/guides/installing-using-pip-and-virtual-environments.rst +++ b/source/guides/installing-using-pip-and-virtual-environments.rst @@ -301,7 +301,7 @@ specifying the extra in brackets: py -m pip install requests[security] .. _extras: - https://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-extras-optional-features-with-their-own-dependencies + https://setuptools.readthedocs.io/en/latest/userguide/dependency_management.html#optional-dependencies Installing from source diff --git a/source/guides/packaging-namespace-packages.rst b/source/guides/packaging-namespace-packages.rst index dd3c0f4b7..b0a30c335 100644 --- a/source/guides/packaging-namespace-packages.rst +++ b/source/guides/packaging-namespace-packages.rst @@ -238,6 +238,6 @@ in the `pkg_resources namespace example project`_. .. _setuptools: https://setuptools.readthedocs.io .. _pkg_resources.declare_namespace: - https://setuptools.readthedocs.io/en/latest/setuptools.html#namespace-packages + https://setuptools.readthedocs.io/en/latest/pkg_resources.html#namespace-package-support .. _pkg_resources namespace example project: https://github.com/pypa/sample-namespace-packages/tree/master/pkg_resources diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index bd8ea42eb..55e251826 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -144,4 +144,4 @@ sure that your release pipeline remains healthy! .. _`pypa/gh-action-pypi-publish GitHub Action`: https://github.com/marketplace/actions/pypi-publish .. _Secrets: - https://help.github.com/en/articles/virtual-environments-for-github-actions#creating-and-using-secrets-encrypted-variables + https://docs.github.com/en/actions/reference/encrypted-secrets diff --git a/source/guides/supporting-multiple-python-versions.rst b/source/guides/supporting-multiple-python-versions.rst index c75dcc830..324b4b932 100644 --- a/source/guides/supporting-multiple-python-versions.rst +++ b/source/guides/supporting-multiple-python-versions.rst @@ -88,7 +88,7 @@ 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 +`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. diff --git a/source/guides/supporting-windows-using-appveyor.rst b/source/guides/supporting-windows-using-appveyor.rst index 567a2a1d9..09e3e8f65 100644 --- a/source/guides/supporting-windows-using-appveyor.rst +++ b/source/guides/supporting-windows-using-appveyor.rst @@ -149,7 +149,7 @@ Additional notes Testing with tox ---------------- -Many projects use the `Tox`_ tool to run their tests. It ensures that tests +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. @@ -239,6 +239,6 @@ For reference, the SDK setup support script is listed here: .. _Appveyor: http://www.appveyor.com/ .. _Travis: https://travis-ci.org/ -.. _Github: https://github.org/ +.. _Github: https://github.com .. _Bitbucket: https://bitbucket.org/ .. _Tox: http://tox.testrun.org diff --git a/source/key_projects.rst b/source/key_projects.rst index d6b8b4c9c..13f0b953c 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -371,7 +371,7 @@ devpi ===== `Docs `__ | -`Issues `__ | +:gh:`Issues ` | `PyPI `__ devpi features a powerful PyPI-compatible server and PyPI proxy cache @@ -406,8 +406,8 @@ Python 2, so long as they can be imported on Python 3. enscons ======= -`Source `__ | -`Issues `__ | +:gh:`Source ` | +:gh:`Issues ` | `PyPI `__ Enscons is a Python packaging tool based on `SCons`_. It builds diff --git a/source/overview.rst b/source/overview.rst index c4fdaaf18..07d36babd 100644 --- a/source/overview.rst +++ b/source/overview.rst @@ -206,7 +206,7 @@ respective packaging guides. * `Google App Engine `_ * `PythonAnywhere `_ * `OpenShift `_ -* "Serverless" frameworks like `Zappa `_ +* "Serverless" frameworks like :gh:`Zappa ` In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does @@ -228,7 +228,7 @@ If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides: -* `Kivy `_ +* `Kivy `_ * `Beeware `_ * `Brython `_ * `Flexx `_ @@ -248,9 +248,9 @@ machines of developers and data scientists. Technologies which support this model: -* `PEX `_ (Python EXecutable) +* :gh:`PEX ` (Python EXecutable) * :doc:`zipapp ` (does not help manage dependencies, requires Python 3.5+) -* `shiv `_ (requires Python 3) +* :gh:`shiv ` (requires Python 3) .. note:: Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, @@ -290,7 +290,6 @@ A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages: -* `Enthought Canopy `_ * `ActiveState ActivePython `_ * `WinPython `_ @@ -324,8 +323,8 @@ A selection of Python freezers: * `pynsist `_ - Windows only Most of the above imply single-user deployments. For multi-component -server applications, see `Chef Omnibus -`_. +server applications, see :gh:`Chef Omnibus +`. Bringing your own userspace @@ -362,7 +361,7 @@ data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include: * `Vagrant `_ -* `VHD `_, `AMI `_, and `other formats `_ +* `VHD `_, `AMI `_, and :ref:`other formats ` * `OpenStack `_ - A cloud management system in Python, with extensive VM support Bringing your own hardware @@ -376,8 +375,7 @@ Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children. -Embed your code on an `Adafruit -`_, +Embed your code on an :gh:`Adafruit `, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day. @@ -405,7 +403,7 @@ Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM -`_ to +`_ to generate both deb and RPMs from the same source. In most deployment pipelines, the OS package manager is just one piece diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst index f6bb02b79..d9a873f85 100644 --- a/source/tutorials/installing-packages.rst +++ b/source/tutorials/installing-packages.rst @@ -683,4 +683,4 @@ Install `setuptools extras`_. and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0 -.. _setuptools extras: https://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-extras-optional-features-with-their-own-dependencies +.. _setuptools extras: https://setuptools.readthedocs.io/en/latest/userguide/dependency_management.html#optional-dependencies From 0ffc6a1f8223f354bc0706f64a36738d81cea698 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 4 Sep 2021 00:52:02 +0800 Subject: [PATCH 0127/1072] Fix an intersphinx error --- source/overview.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/overview.rst b/source/overview.rst index 07d36babd..eaa7303b5 100644 --- a/source/overview.rst +++ b/source/overview.rst @@ -361,7 +361,7 @@ data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include: * `Vagrant `_ -* `VHD `_, `AMI `_, and :ref:`other formats ` +* `VHD `_, `AMI `_, and :doc:`other formats ` * `OpenStack `_ - A cloud management system in Python, with extensive VM support Bringing your own hardware From 6bdad46deffa7bf408c79fec224a184b985d3412 Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sat, 4 Sep 2021 14:25:56 +0800 Subject: [PATCH 0128/1072] Remove `linkcheck_anchors` Co-authored-by: Sviatoslav Sydorenko --- source/conf.py | 1 - 1 file changed, 1 deletion(-) diff --git a/source/conf.py b/source/conf.py index 7b87775b7..c10dad13d 100644 --- a/source/conf.py +++ b/source/conf.py @@ -381,7 +381,6 @@ 'user': (f'{github_sponsors_url}/%s', '@'), # noqa: WPS323 } -linkcheck_anchors = False linkcheck_ignore = [ "http://localhost:\d+", From 61883a290f99eb3d475c3d6eaed116da6e314e93 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Thu, 26 Aug 2021 13:33:44 +0000 Subject: [PATCH 0129/1072] Update messages.pot as of version cc488ec --- locales/messages.pot | 1132 +++++++++++++++++++++--------------------- 1 file changed, 567 insertions(+), 565 deletions(-) diff --git a/locales/messages.pot b/locales/messages.pot index 5ea4b3276..4eac54e62 100644 --- a/locales/messages.pot +++ b/locales/messages.pot @@ -8,7 +8,7 @@ msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide \n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-07-06 19:32+0800\n" +"POT-Creation-Date: 2021-08-26 13:33+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" @@ -40,170 +40,222 @@ msgstr "" msgid "Writing new content" msgstr "" -#: ../source/contribute.rst:15 +#: ../source/contribute.rst:14 +msgid "Translate the guide" +msgstr "" + +#: ../source/contribute.rst:16 msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." msgstr "" -#: ../source/contribute.rst:24 +#: ../source/contribute.rst:25 msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." msgstr "" -#: ../source/contribute.rst:31 +#: ../source/contribute.rst:32 msgid "Documentation types" msgstr "" -#: ../source/contribute.rst:33 +#: ../source/contribute.rst:34 msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." msgstr "" -#: ../source/contribute.rst:38 +#: ../source/contribute.rst:39 #: ../source/tutorials/index.rst:2 msgid "Tutorials" msgstr "" -#: ../source/contribute.rst:40 +#: ../source/contribute.rst:41 msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." msgstr "" -#: ../source/contribute.rst:47 +#: ../source/contribute.rst:48 #: ../source/guides/index.rst:2 msgid "Guides" msgstr "" -#: ../source/contribute.rst:49 +#: ../source/contribute.rst:50 msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." msgstr "" -#: ../source/contribute.rst:56 +#: ../source/contribute.rst:57 #: ../source/discussions/index.rst:2 msgid "Discussions" msgstr "" -#: ../source/contribute.rst:58 +#: ../source/contribute.rst:59 msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." msgstr "" -#: ../source/contribute.rst:63 +#: ../source/contribute.rst:64 msgid "Specifications" msgstr "" -#: ../source/contribute.rst:65 +#: ../source/contribute.rst:66 msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." msgstr "" -#: ../source/contribute.rst:73 +#: ../source/contribute.rst:72 +msgid "Translations" +msgstr "" + +#: ../source/contribute.rst:74 +msgid "We use `Weblate`_ to manage translations of this project. Please visit the `packaging.python.org`_ project on Weblate to contribute." +msgstr "" + +#: ../source/contribute.rst:77 +msgid "If you are experiencing issues while you are working on translations, please open an issue on `Github`_." +msgstr "" + +#: ../source/contribute.rst:82 +msgid "Any translations of this project should follow `reStructuredText syntax`_." +msgstr "" + +#: ../source/contribute.rst:90 +msgid "Adding a language" +msgstr "" + +#: ../source/contribute.rst:92 +msgid "If your language is not listed on `packaging.python.org`_, click the button :guilabel:`Start new translation` at the bottom of the language list and add the language you want to translate." +msgstr "" + +#: ../source/contribute.rst:97 +msgid "Following reStructuredText syntax" +msgstr "" + +#: ../source/contribute.rst:99 +msgid "If you are not familiar with reStructuredText (RST) syntax, please read `this guide`_ before translating on Weblate." +msgstr "" + +#: ../source/contribute.rst:102 +msgid "**Do not translate the text in reference directly**" +msgstr "" + +#: ../source/contribute.rst:104 +msgid "When translating the text in reference, please do not translate them directly." +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Wrong: Translate the following text directly:" +msgstr "" + +#: ../source/contribute.rst:0 +msgid "Right: Translate the following text with your own language and add the original reference:" +msgstr "" + +#: ../source/contribute.rst:121 msgid "Building the guide locally" msgstr "" -#: ../source/contribute.rst:75 +#: ../source/contribute.rst:123 msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" msgstr "" -#: ../source/contribute.rst:79 -msgid "`Nox `_. You can install or upgrade nox using ``pip``::" +#: ../source/contribute.rst:127 +msgid "`Nox `_. You can install or upgrade nox using ``pip``:" msgstr "" -#: ../source/contribute.rst:84 +#: ../source/contribute.rst:134 msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." msgstr "" -#: ../source/contribute.rst:91 -msgid "To build the guide, run the following bash command in the source folder::" +#: ../source/contribute.rst:141 +msgid "To build the guide, run the following bash command in the source folder:" msgstr "" -#: ../source/contribute.rst:95 +#: ../source/contribute.rst:147 msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." msgstr "" -#: ../source/contribute.rst:100 -msgid "You can build the guide and serve it via an HTTP server using the following command::" +#: ../source/contribute.rst:152 +msgid "You can build the guide and serve it via an HTTP server using the following command:" msgstr "" -#: ../source/contribute.rst:105 +#: ../source/contribute.rst:159 msgid "The guide will be browsable via http://localhost:8000." msgstr "" -#: ../source/contribute.rst:109 +#: ../source/contribute.rst:163 msgid "Where the guide is deployed" msgstr "" -#: ../source/contribute.rst:111 +#: ../source/contribute.rst:165 msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." msgstr "" -#: ../source/contribute.rst:117 +#: ../source/contribute.rst:171 msgid "Style guide" msgstr "" -#: ../source/contribute.rst:119 +#: ../source/contribute.rst:173 msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." msgstr "" -#: ../source/contribute.rst:126 +#: ../source/contribute.rst:180 msgid "Purpose" msgstr "" -#: ../source/contribute.rst:128 +#: ../source/contribute.rst:182 msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." msgstr "" -#: ../source/contribute.rst:133 +#: ../source/contribute.rst:187 msgid "Scope" msgstr "" -#: ../source/contribute.rst:135 +#: ../source/contribute.rst:189 msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." msgstr "" -#: ../source/contribute.rst:138 +#: ../source/contribute.rst:192 msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." msgstr "" -#: ../source/contribute.rst:146 +#: ../source/contribute.rst:200 msgid "Audience" msgstr "" -#: ../source/contribute.rst:148 +#: ../source/contribute.rst:202 msgid "The audience of this guide is anyone who uses Python with packages." msgstr "" -#: ../source/contribute.rst:150 +#: ../source/contribute.rst:204 msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." msgstr "" -#: ../source/contribute.rst:154 +#: ../source/contribute.rst:208 msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." msgstr "" -#: ../source/contribute.rst:160 +#: ../source/contribute.rst:214 msgid "Voice and tone" msgstr "" -#: ../source/contribute.rst:162 +#: ../source/contribute.rst:216 msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." msgstr "" -#: ../source/contribute.rst:165 +#: ../source/contribute.rst:219 msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." msgstr "" -#: ../source/contribute.rst:170 +#: ../source/contribute.rst:224 msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." msgstr "" -#: ../source/contribute.rst:177 +#: ../source/contribute.rst:231 msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." msgstr "" -#: ../source/contribute.rst:184 +#: ../source/contribute.rst:238 msgid "Conventions and mechanics" msgstr "" -#: ../source/contribute.rst:192 +#: ../source/contribute.rst:246 msgid "**Write to the reader**" msgstr "" -#: ../source/contribute.rst:187 +#: ../source/contribute.rst:241 msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." msgstr "" @@ -219,27 +271,27 @@ msgstr "" msgid "Right: To install it, run…" msgstr "" -#: ../source/contribute.rst:198 +#: ../source/contribute.rst:252 msgid "**State assumptions**" msgstr "" -#: ../source/contribute.rst:195 +#: ../source/contribute.rst:249 msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." msgstr "" -#: ../source/contribute.rst:203 +#: ../source/contribute.rst:257 msgid "**Cross-reference generously**" msgstr "" -#: ../source/contribute.rst:201 +#: ../source/contribute.rst:255 msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." msgstr "" -#: ../source/contribute.rst:213 +#: ../source/contribute.rst:267 msgid "**Respect naming practices**" msgstr "" -#: ../source/contribute.rst:206 +#: ../source/contribute.rst:260 msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." msgstr "" @@ -259,11 +311,11 @@ msgstr "" msgid "Right: …hosted on GitHub." msgstr "" -#: ../source/contribute.rst:222 +#: ../source/contribute.rst:276 msgid "**Use a gender-neutral style**" msgstr "" -#: ../source/contribute.rst:216 +#: ../source/contribute.rst:270 msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." msgstr "" @@ -279,15 +331,15 @@ msgstr "" msgid "Right: A maintainer uploads the file. Then the maintainer…" msgstr "" -#: ../source/contribute.rst:234 +#: ../source/contribute.rst:288 msgid "**Headings**" msgstr "" -#: ../source/contribute.rst:225 +#: ../source/contribute.rst:279 msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." msgstr "" -#: ../source/contribute.rst:230 +#: ../source/contribute.rst:284 msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." msgstr "" @@ -299,11 +351,11 @@ msgstr "" msgid "Right: Things you should know about Python" msgstr "" -#: ../source/contribute.rst:237 +#: ../source/contribute.rst:291 msgid "**Numbers**" msgstr "" -#: ../source/contribute.rst:237 +#: ../source/contribute.rst:291 msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." msgstr "" @@ -339,7 +391,7 @@ msgid "Last Reviewed" msgstr "" #: ../source/discussions/deploying-python-applications.rst:7 -msgid "2014-11-11" +msgid "2021-8-24" msgstr "" #: ../source/discussions/deploying-python-applications.rst:11 @@ -348,6 +400,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:22 #: ../source/guides/index-mirrors-and-caches.rst:12 #: ../source/guides/installing-scientific-packages.rst:9 +#: ../source/guides/installing-using-linux-tools.rst:11 #: ../source/guides/packaging-binary-extensions.rst:17 #: ../source/guides/supporting-multiple-python-versions.rst:12 #: ../source/guides/supporting-windows-using-appveyor.rst:15 @@ -371,6 +424,7 @@ msgid "OS packaging & installers" msgstr "" #: ../source/discussions/deploying-python-applications.rst:52 +#: ../source/discussions/deploying-python-applications.rst:89 msgid "Windows" msgstr "" @@ -394,7 +448,40 @@ msgstr "" msgid "Application bundles" msgstr "" -#: ../source/discussions/deploying-python-applications.rst:91 +#: ../source/discussions/deploying-python-applications.rst:92 +msgid "py2exe" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:94 +msgid "`py2exe `__ is a distutils extension which allows to build standalone Windows executable programs (32-bit and 64-bit) from Python scripts. Python versions included in the official development cycle are supported (refers to `Status of Python branches`__). py2exe can build console executables and windows (GUI) executables. Building windows services, and DLL/EXE COM servers might work but it is not actively supported. The distutils extension is released under the MIT-licence and Mozilla Public License 2.0." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:106 +msgid "macOS" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:109 +msgid "py2app" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:111 +msgid "`py2app `__ is a Python setuptools command which will allow you to make standalone macOS application bundles and plugins from Python scripts. Note that py2app MUST be used on macOS to build applications, it cannot create Mac applications on other platforms. py2app is released under the MIT-license." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:118 +msgid "Unix (including Linux and macOS)" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:121 +#: ../source/key_projects.rst:470 +msgid "pex" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:123 +msgid "`pex `__ is a library for generating .pex (Python EXecutable) files which are executable Python environments in the spirit of virtualenvs. pex is an expansion upon the ideas outlined in :pep:`441` and makes the deployment of Python applications as simple as cp. pex files may even include multiple platform-specific Python distributions, meaning that a single pex file can be portable across Linux and macOS. pex is released under the Apache License 2.0." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:132 msgid "Configuration management" msgstr "" @@ -407,7 +494,6 @@ msgid "install_requires vs requirements files" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:382 msgid "install_requires" msgstr "" @@ -440,7 +526,7 @@ msgid "Lastly, it's important to understand that ``install_requires`` is a listi msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:64 -#: ../source/tutorials/installing-packages.rst:460 +#: ../source/tutorials/installing-packages.rst:468 msgid "Requirements files" msgstr "" @@ -1517,7 +1603,9 @@ msgid "The most relevant arguments are explained below. Most of the snippets giv msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:164 -msgid "name" +#: ../source/specifications/declaring-project-metadata.rst:29 +#: ../source/specifications/declaring-project-metadata.rst:41 +msgid "``name``" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:170 @@ -1537,8 +1625,9 @@ msgid "Comparison of project names is case insensitive and treats arbitrarily-lo msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:190 -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "version" +#: ../source/specifications/declaring-project-metadata.rst:34 +#: ../source/specifications/declaring-project-metadata.rst:54 +msgid "``version``" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:196 @@ -1558,7 +1647,8 @@ msgid "If the project code itself needs run-time access to the version, the simp msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:214 -msgid "description" +#: ../source/specifications/declaring-project-metadata.rst:66 +msgid "``description``" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:222 @@ -1578,7 +1668,7 @@ msgid "A `content type ` in yo msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:370 -msgid "py_modules" +msgid "``py_modules``" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:376 msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." msgstr "" +#: ../source/guides/distributing-packages-using-setuptools.rst:382 +msgid "``install_requires``" +msgstr "" + #: ../source/guides/distributing-packages-using-setuptools.rst:388 msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." msgstr "" @@ -1658,7 +1755,7 @@ msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:398 -msgid "python_requires" +msgid "``python_requires``" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:400 @@ -1682,7 +1779,7 @@ msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ` msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:431 -msgid "package_data" +msgid "``package_data``" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:440 @@ -1698,7 +1795,7 @@ msgid "For more information, see :std:doc:`Including Data Files `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." +msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_), and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:479 @@ -1718,7 +1815,7 @@ msgid "When installing packages as egg, ``data_files`` is not supported. So, if msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:491 -msgid "scripts" +msgid "``scripts``" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:493 @@ -1726,7 +1823,7 @@ msgid "Although ``setup()`` supports a `scripts `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgid "Use ``console_script`` `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:538 @@ -1898,203 +1995,203 @@ msgid "Assuming you're in the root of your project directory, then run:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:674 -msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." +msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with ``install_requires`` and any scripts declared with ``console_scripts``. Dependencies will be installed in the usual, non-editable mode." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:680 +#: ../source/guides/distributing-packages-using-setuptools.rst:681 msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:688 +#: ../source/guides/distributing-packages-using-setuptools.rst:689 msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:692 +#: ../source/guides/distributing-packages-using-setuptools.rst:693 msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:697 +#: ../source/guides/distributing-packages-using-setuptools.rst:698 msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:701 -msgid "Lastly, if you don't want to install any dependencies at all, you can run::" +#: ../source/guides/distributing-packages-using-setuptools.rst:702 +msgid "Lastly, if you don't want to install any dependencies at all, you can run:" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:706 +#: ../source/guides/distributing-packages-using-setuptools.rst:709 msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:713 +#: ../source/guides/distributing-packages-using-setuptools.rst:716 msgid "Packaging your project" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:715 +#: ../source/guides/distributing-packages-using-setuptools.rst:718 msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:720 +#: ../source/guides/distributing-packages-using-setuptools.rst:723 msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:737 +#: ../source/guides/distributing-packages-using-setuptools.rst:740 msgid "Source distributions" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:739 +#: ../source/guides/distributing-packages-using-setuptools.rst:742 msgid "Minimally, you should create a :term:`Source Distribution `:" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:755 +#: ../source/guides/distributing-packages-using-setuptools.rst:758 msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:763 +#: ../source/guides/distributing-packages-using-setuptools.rst:766 msgid "Wheels" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:765 +#: ../source/guides/distributing-packages-using-setuptools.rst:768 msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:770 +#: ../source/guides/distributing-packages-using-setuptools.rst:773 msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:773 +#: ../source/guides/distributing-packages-using-setuptools.rst:776 msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:776 +#: ../source/guides/distributing-packages-using-setuptools.rst:779 msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:785 +#: ../source/guides/distributing-packages-using-setuptools.rst:788 msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:792 +#: ../source/guides/distributing-packages-using-setuptools.rst:795 msgid "Pure Python Wheels" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:794 +#: ../source/guides/distributing-packages-using-setuptools.rst:797 msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:797 -#: ../source/guides/distributing-packages-using-setuptools.rst:826 +#: ../source/guides/distributing-packages-using-setuptools.rst:800 +#: ../source/guides/distributing-packages-using-setuptools.rst:829 msgid "To build the wheel:" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:811 +#: ../source/guides/distributing-packages-using-setuptools.rst:814 msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:815 +#: ../source/guides/distributing-packages-using-setuptools.rst:818 msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:821 +#: ../source/guides/distributing-packages-using-setuptools.rst:824 msgid "Platform Wheels" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:823 +#: ../source/guides/distributing-packages-using-setuptools.rst:826 msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:841 +#: ../source/guides/distributing-packages-using-setuptools.rst:844 msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:847 +#: ../source/guides/distributing-packages-using-setuptools.rst:850 msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:855 +#: ../source/guides/distributing-packages-using-setuptools.rst:858 msgid "Uploading your Project to PyPI" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:857 +#: ../source/guides/distributing-packages-using-setuptools.rst:860 msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:861 +#: ../source/guides/distributing-packages-using-setuptools.rst:864 msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:866 +#: ../source/guides/distributing-packages-using-setuptools.rst:869 msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:871 +#: ../source/guides/distributing-packages-using-setuptools.rst:874 msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:877 -msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" +#: ../source/guides/distributing-packages-using-setuptools.rst:880 +msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files:" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:888 +#: ../source/guides/distributing-packages-using-setuptools.rst:893 msgid "Create an account" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:890 +#: ../source/guides/distributing-packages-using-setuptools.rst:895 msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:894 +#: ../source/guides/distributing-packages-using-setuptools.rst:899 msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:897 +#: ../source/guides/distributing-packages-using-setuptools.rst:902 msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:901 +#: ../source/guides/distributing-packages-using-setuptools.rst:906 msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:904 +#: ../source/guides/distributing-packages-using-setuptools.rst:909 msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:913 +#: ../source/guides/distributing-packages-using-setuptools.rst:918 msgid "**Be aware that this stores your token in plaintext.**" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:915 +#: ../source/guides/distributing-packages-using-setuptools.rst:920 #: ../source/guides/migrating-to-pypi-org.rst:70 #: ../source/guides/migrating-to-pypi-org.rst:109 #: ../source/guides/using-testpypi.rst:83 msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:921 +#: ../source/guides/distributing-packages-using-setuptools.rst:926 msgid "Upload your distributions" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:923 +#: ../source/guides/distributing-packages-using-setuptools.rst:928 msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:926 +#: ../source/guides/distributing-packages-using-setuptools.rst:931 msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:930 +#: ../source/guides/distributing-packages-using-setuptools.rst:935 msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:937 +#: ../source/guides/distributing-packages-using-setuptools.rst:942 msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:944 -#: ../source/tutorials/installing-packages.rst:663 +#: ../source/guides/distributing-packages-using-setuptools.rst:949 +#: ../source/tutorials/installing-packages.rst:671 msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:950 +#: ../source/guides/distributing-packages-using-setuptools.rst:955 msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." msgstr "" @@ -2211,50 +2308,50 @@ msgid "This file is generated by Distutils or :ref:`setuptools` when it generate msgstr "" #: ../source/guides/dropping-older-python-versions.rst:108 -msgid "You can see the contents of the generated file like this::" +msgid "You can see the contents of the generated file like this:" msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:112 +#: ../source/guides/dropping-older-python-versions.rst:114 msgid "Validate that the following is in place, before publishing the package:" msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:114 +#: ../source/guides/dropping-older-python-versions.rst:116 msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:115 +#: ../source/guides/dropping-older-python-versions.rst:117 msgid "The Requires-Python field is set and matches your specification in setup.py." msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:118 +#: ../source/guides/dropping-older-python-versions.rst:120 msgid "4. Using Twine to publish" msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:120 +#: ../source/guides/dropping-older-python-versions.rst:122 msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:122 +#: ../source/guides/dropping-older-python-versions.rst:124 msgid "Make sure you are using the newest version of Twine, at least 1.9." msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:125 +#: ../source/guides/dropping-older-python-versions.rst:127 msgid "Dropping a Python release" msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:127 +#: ../source/guides/dropping-older-python-versions.rst:129 msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:129 +#: ../source/guides/dropping-older-python-versions.rst:131 msgid "It must be done in this order for the automated fallback to work." msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:131 +#: ../source/guides/dropping-older-python-versions.rst:133 msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:133 +#: ../source/guides/dropping-older-python-versions.rst:135 msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." msgstr "" @@ -2351,26 +2448,26 @@ msgid "`Fast & local installs `_::" +msgid "A variation on the above which pre-builds the installation files for the requirements using :ref:`python -m pip wheel `:" msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:45 +#: ../source/guides/index-mirrors-and-caches.rst:46 msgid "Caching with devpi" msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:47 +#: ../source/guides/index-mirrors-and-caches.rst:48 msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:55 +#: ../source/guides/index-mirrors-and-caches.rst:56 msgid "Complete mirror with bandersnatch" msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:57 +#: ../source/guides/index-mirrors-and-caches.rst:58 msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:63 +#: ../source/guides/index-mirrors-and-caches.rst:64 msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." msgstr "" @@ -2463,7 +2560,7 @@ msgid "Some of these distributions may not be compatible with the standard ``pip msgstr "" #: ../source/guides/installing-scientific-packages.rst:109 -#: ../source/key_projects.rst:596 +#: ../source/key_projects.rst:581 msgid "Spack" msgstr "" @@ -2492,15 +2589,15 @@ msgid "Installing stand alone command line tools" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:4 -msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." +msgid "Many packages provide command line applications. Examples of such packages are `mypy `_, `flake8 `_, `black `_, and :ref:`pipenv`." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:10 -msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." +msgid "Usually you want to be able to access these applications from anywhere on your system, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:15 -msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." +msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that its applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the applications from anywhere." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:21 @@ -2508,44 +2605,43 @@ msgid "pipx only works with Python 3.6+." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:23 -msgid "``pipx`` is installed with ``pip``:" +msgid "pipx is installed with pip:" msgstr "" -#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 -msgid "You may need to restart your terminal for the path updates to take effect." +#: ../source/guides/installing-stand-alone-command-line-tools.rst:41 +msgid "``ensurepath`` ensures that the application directory is on your ``$PATH``. You may need to restart your terminal for this update to take effect." msgstr "" -#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 -msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." +#: ../source/guides/installing-stand-alone-command-line-tools.rst:44 +msgid "Now you can install packages with ``pipx install`` and run the package's applications(s) from anywhere." msgstr "" -#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 -#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 -msgid "For example" +#: ../source/guides/installing-stand-alone-command-line-tools.rst:52 +msgid "For example:" msgstr "" -#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 -msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." +#: ../source/guides/installing-stand-alone-command-line-tools.rst:72 +msgid "To see a list of packages installed with pipx and which applications are available, use ``pipx list``:" msgstr "" -#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 -msgid "To upgrade or uninstall the package" +#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 +msgid "To upgrade or uninstall a package:" msgstr "" -#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 -msgid "``pipx`` can be upgraded or uninstalled with pip" +#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 +msgid "pipx can be upgraded or uninstalled with pip:" msgstr "" -#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 -msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." +#: ../source/guides/installing-stand-alone-command-line-tools.rst:116 +msgid "pipx also allows you to install and run the latest version of an application in a temporary, ephemeral environment. For example:" msgstr "" -#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 -msgid "To see the full list of commands ``pipx`` offers, run" +#: ../source/guides/installing-stand-alone-command-line-tools.rst:123 +msgid "To see the full list of commands pipx offers, run:" msgstr "" -#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 -msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." +#: ../source/guides/installing-stand-alone-command-line-tools.rst:129 +msgid "You can learn more about pipx at https://pypa.github.io/pipx/." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:5 @@ -2553,140 +2649,110 @@ msgid "Installing pip/setuptools/wheel with Linux Package Managers" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:8 -msgid "2015-09-17" +msgid "2021-07-26" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:11 +#: ../source/guides/installing-using-linux-tools.rst:13 msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:14 +#: ../source/guides/installing-using-linux-tools.rst:16 msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:18 +#: ../source/guides/installing-using-linux-tools.rst:20 msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:25 +#: ../source/guides/installing-using-linux-tools.rst:27 msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:32 -msgid "Fedora" -msgstr "" - #: ../source/guides/installing-using-linux-tools.rst:34 -msgid "Fedora 21:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:36 -#: ../source/guides/installing-using-linux-tools.rst:45 -#: ../source/guides/installing-using-linux-tools.rst:124 -#: ../source/guides/installing-using-linux-tools.rst:138 -#: ../source/guides/installing-using-linux-tools.rst:158 -msgid "Python 2::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:41 -msgid "Python 3: ``sudo yum install python3 python3-wheel``" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:43 -msgid "Fedora 22:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:50 -msgid "Python 3: ``sudo dnf install python3 python3-wheel``" +msgid "Fedora" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:53 -msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" +#: ../source/guides/installing-using-linux-tools.rst:40 +msgid "To learn more about Python in Fedora, please visit the `official Fedora docs`_, `Python Classroom`_ or `Fedora Loves Python`_." msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:63 +#: ../source/guides/installing-using-linux-tools.rst:48 msgid "CentOS/RHEL" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:65 +#: ../source/guides/installing-using-linux-tools.rst:50 msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:68 +#: ../source/guides/installing-using-linux-tools.rst:53 msgid "To install pip and wheel for the system Python, there are two options:" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:70 -msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" +#: ../source/guides/installing-using-linux-tools.rst:55 +msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 7, you can install pip and wheel like so:" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:77 -msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:81 +#: ../source/guides/installing-using-linux-tools.rst:64 msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:85 -msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" +#: ../source/guides/installing-using-linux-tools.rst:68 +msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so:" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:92 -msgid "To additionally upgrade setuptools, run::" +#: ../source/guides/installing-using-linux-tools.rst:77 +msgid "To additionally upgrade setuptools, run:" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:97 +#: ../source/guides/installing-using-linux-tools.rst:84 msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:101 +#: ../source/guides/installing-using-linux-tools.rst:88 msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:104 +#: ../source/guides/installing-using-linux-tools.rst:91 msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:106 +#: ../source/guides/installing-using-linux-tools.rst:93 msgid "For CentOS, see here: https://www.softwarecollections.org/en/" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:108 +#: ../source/guides/installing-using-linux-tools.rst:95 msgid "Be aware that collections may not contain the most recent versions." msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:110 +#: ../source/guides/installing-using-linux-tools.rst:97 msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:116 -msgid "For example, for Python 3.4 on CentOS7/RHEL7::" +#: ../source/guides/installing-using-linux-tools.rst:103 +msgid "For example, for Python 3.4 on CentOS7/RHEL7:" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:122 +#: ../source/guides/installing-using-linux-tools.rst:111 msgid "openSUSE" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:129 -#: ../source/guides/installing-using-linux-tools.rst:143 -#: ../source/guides/installing-using-linux-tools.rst:162 -msgid "Python 3::" +#: ../source/guides/installing-using-linux-tools.rst:118 +msgid "Debian/Ubuntu" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:135 -msgid "Debian/Ubuntu" +#: ../source/guides/installing-using-linux-tools.rst:120 +msgid "Firstly, update and refresh repository lists by running this command:" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:150 +#: ../source/guides/installing-using-linux-tools.rst:129 msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:156 +#: ../source/guides/installing-using-linux-tools.rst:135 msgid "Arch Linux" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:168 +#: ../source/guides/installing-using-linux-tools.rst:143 msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." msgstr "" @@ -2711,212 +2777,216 @@ msgid ":ref:`pip` is the reference Python package manager. It's used to install msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 -msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." +msgid "Debian and most other distributions include a `python-pip`_ package; if you want to use the Linux distribution-provided versions of pip, see :doc:`/guides/installing-using-linux-tools`." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 -msgid "Afterwards, you should have the newest pip installed in your user site:" +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:37 +msgid "Afterwards, you should have the latest version of pip installed in your user site:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 -msgid "The Python installers for Windows include pip. You should be able to access pip using:" +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:48 +msgid "The Python installers for Windows include pip. You can make sure that pip is up-to-date by running:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 -msgid "You can make sure that pip is up-to-date by running:" +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:57 +msgid "Afterwards, you should have the latest version of pip:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:66 msgid "Installing virtualenv" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:68 msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:74 msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:95 msgid "Creating a virtual environment" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:97 msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:106 msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:122 msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:125 msgid "venv will create a virtual Python installation in the ``env`` folder." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:127 msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:132 msgid "Activating a virtual environment" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:134 msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 -msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:151 +msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:166 +msgid "It should be in the ``env`` directory:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:181 msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:187 msgid "Leaving the virtual environment" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:189 msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:195 msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 msgid "Installing packages" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:202 msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:217 msgid "pip should download requests and all of its dependencies and install them:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:238 msgid "Installing specific versions" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:240 msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:256 msgid "To install the latest ``2.x`` release of requests:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:270 msgid "To install pre-release versions of packages, use the ``--pre`` flag:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:286 msgid "Installing extras" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:288 msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:308 msgid "Installing from source" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:310 msgid "pip can install a package directly from source, for example:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:326 msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:347 msgid "Installing from version control systems" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:349 msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:356 msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 -#: ../source/tutorials/installing-packages.rst:569 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 +#: ../source/tutorials/installing-packages.rst:577 msgid "Installing from local archives" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:363 msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:378 msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:394 msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 msgid "Using other package indexes" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:402 msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 -#: ../source/tutorials/installing-packages.rst:389 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:434 +#: ../source/tutorials/installing-packages.rst:397 msgid "Upgrading packages" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:436 msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:452 msgid "Using requirements files" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:454 msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 msgid "Freezing dependencies" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:480 msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:495 msgid "Which will output a list of package specifiers such as:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:511 msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." msgstr "" @@ -3033,10 +3103,10 @@ msgid "Build the sdist and wheel for your project as described under :ref:`Packa msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:125 -msgid "Run ``twine check`` on the sdist and wheel::" +msgid "Run ``twine check`` on the sdist and wheel:" msgstr "" -#: ../source/guides/making-a-pypi-friendly-readme.rst:129 +#: ../source/guides/making-a-pypi-friendly-readme.rst:131 msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." msgstr "" @@ -3366,124 +3436,74 @@ msgid "Binary extensions for Windows" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:258 -msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:263 -msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:269 -msgid "To set up a build environment for binary extensions, the steps are as follows:" +msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions. To set up a build environment for binary extensions, install `Visual Studio Community Edition `__ - any recent version is fine." msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:271 -msgid "For Python 2.7" +#: ../source/guides/packaging-binary-extensions.rst:265 +msgid "One caveat: if you use Visual Studio 2019 or later, your extension will depend on an \"extra\" file, ``VCRUNTIME140_1.dll``, in addition to the ``VCRUNTIME140.dll`` that all previous versions back to 2015 depend on. This will add an extra requirement to using your extension on versions of CPython that do not include this extra file. To avoid this, you can add the compile-time argument ``/d2FH4-``. Recent versions of Python may include this file." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:273 -msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:276 -msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:278 -#: ../source/guides/packaging-binary-extensions.rst:288 -#: ../source/guides/packaging-binary-extensions.rst:295 -msgid "Done." +msgid "Building for Python prior to 3.5 is discouraged, because older versions of Visual Studio are no longer available from Microsoft. If you do need to build for older versions, you can set ``DISTUTILS_USE_SDK=1`` and ``MSSdk=1`` to force a the currently activated version of MSVC to be found, and you should exercise care when designing your extension not to malloc/free memory across different libraries, avoid relying on changed data structures, and so on. Tools for generating extension modules usually avoid these things for you." msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:280 -msgid "For Python 3.4" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:282 -msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:285 -msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:287 -msgid "Set DISTUTILS_USE_SDK=1" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:290 -msgid "For Python 3.5" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:292 -msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:297 -msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:301 -msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:305 +#: ../source/guides/packaging-binary-extensions.rst:284 msgid "Binary extensions for Linux" msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:307 +#: ../source/guides/packaging-binary-extensions.rst:286 msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:313 +#: ../source/guides/packaging-binary-extensions.rst:292 msgid "Binary extensions for macOS" msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:315 +#: ../source/guides/packaging-binary-extensions.rst:294 msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:325 +#: ../source/guides/packaging-binary-extensions.rst:304 msgid "Publishing binary extensions" msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:327 +#: ../source/guides/packaging-binary-extensions.rst:306 msgid "For interim guidance on this topic, see the discussion in `this issue `_." msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:343 +#: ../source/guides/packaging-binary-extensions.rst:322 msgid "Additional resources" msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:345 +#: ../source/guides/packaging-binary-extensions.rst:324 msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:352 +#: ../source/guides/packaging-binary-extensions.rst:331 msgid "Cross-platform wheel generation with scikit-build" msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:354 +#: ../source/guides/packaging-binary-extensions.rst:333 msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:362 +#: ../source/guides/packaging-binary-extensions.rst:341 msgid "Introduction to C/C++ extension modules" msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:364 +#: ../source/guides/packaging-binary-extensions.rst:343 msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:367 +#: ../source/guides/packaging-binary-extensions.rst:346 msgid "`What are (c)python extension modules? `_" msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:368 +#: ../source/guides/packaging-binary-extensions.rst:347 msgid "`Releasing the gil `_" msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:369 +#: ../source/guides/packaging-binary-extensions.rst:348 msgid "`Writing cpython extension modules using C++ `_" msgstr "" @@ -4166,54 +4186,58 @@ msgid "Packaging tool recommendations" msgstr "" #: ../source/guides/tool-recommendations.rst:49 -msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" +msgid "Use :ref:`setuptools` to define projects. [5]_ [6]_" msgstr "" -#: ../source/guides/tool-recommendations.rst:52 -msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." +#: ../source/guides/tool-recommendations.rst:51 +msgid "Use :ref:`build` to create :term:`Source Distributions ` and :term:`wheels `." msgstr "" -#: ../source/guides/tool-recommendations.rst:56 +#: ../source/guides/tool-recommendations.rst:54 +msgid "If you have binary extensions and want to distribute wheels for multiple platforms, use :ref:`cibuildwheel` as part of your CI setup to build distributable wheels." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:58 msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." msgstr "" -#: ../source/guides/tool-recommendations.rst:61 +#: ../source/guides/tool-recommendations.rst:63 msgid "Publishing platform migration" msgstr "" -#: ../source/guides/tool-recommendations.rst:63 +#: ../source/guides/tool-recommendations.rst:65 msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." msgstr "" -#: ../source/guides/tool-recommendations.rst:67 +#: ../source/guides/tool-recommendations.rst:69 msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." msgstr "" -#: ../source/guides/tool-recommendations.rst:72 +#: ../source/guides/tool-recommendations.rst:74 msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." msgstr "" -#: ../source/guides/tool-recommendations.rst:77 +#: ../source/guides/tool-recommendations.rst:79 msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." msgstr "" -#: ../source/guides/tool-recommendations.rst:82 +#: ../source/guides/tool-recommendations.rst:84 msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." msgstr "" -#: ../source/guides/tool-recommendations.rst:88 +#: ../source/guides/tool-recommendations.rst:90 msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." msgstr "" -#: ../source/guides/tool-recommendations.rst:93 +#: ../source/guides/tool-recommendations.rst:95 msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." msgstr "" -#: ../source/guides/tool-recommendations.rst:102 +#: ../source/guides/tool-recommendations.rst:104 msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." msgstr "" -#: ../source/guides/tool-recommendations.rst:107 +#: ../source/guides/tool-recommendations.rst:109 msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." msgstr "" @@ -4394,10 +4418,10 @@ msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; msgstr "" #: ../source/guides/using-manifest-in.rst:95 -msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" +msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands:" msgstr "" -#: ../source/guides/using-manifest-in.rst:101 +#: ../source/guides/using-manifest-in.rst:103 msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." msgstr "" @@ -4410,7 +4434,7 @@ msgid "Registering your account" msgstr "" #: ../source/guides/using-testpypi.rst:15 -msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." +msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." msgstr "" #: ../source/guides/using-testpypi.rst:19 @@ -4422,7 +4446,7 @@ msgid "Using TestPyPI with Twine" msgstr "" #: ../source/guides/using-testpypi.rst:26 -msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" +msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag:" msgstr "" #: ../source/guides/using-testpypi.rst:33 @@ -4434,11 +4458,11 @@ msgid "Using TestPyPI with pip" msgstr "" #: ../source/guides/using-testpypi.rst:41 -msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" +msgid "You can tell :ref:`pip` to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag:" msgstr "" #: ../source/guides/using-testpypi.rst:56 -msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" +msgid "If you want to allow pip to also download packages from PyPI, you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" msgstr "" #: ../source/guides/using-testpypi.rst:73 @@ -4769,274 +4793,258 @@ msgid "Non-PyPA Projects" msgstr "" #: ../source/key_projects.rst:329 -msgid "bento" -msgstr "" - -#: ../source/key_projects.rst:331 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:336 -msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." -msgstr "" - -#: ../source/key_projects.rst:344 msgid "buildout" msgstr "" -#: ../source/key_projects.rst:346 +#: ../source/key_projects.rst:331 msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" msgstr "" -#: ../source/key_projects.rst:351 +#: ../source/key_projects.rst:336 msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." msgstr "" -#: ../source/key_projects.rst:358 +#: ../source/key_projects.rst:343 msgid "conda" msgstr "" -#: ../source/key_projects.rst:360 +#: ../source/key_projects.rst:345 msgid "`Docs `__" msgstr "" -#: ../source/key_projects.rst:362 +#: ../source/key_projects.rst:347 msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." msgstr "" -#: ../source/key_projects.rst:369 +#: ../source/key_projects.rst:354 msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." msgstr "" -#: ../source/key_projects.rst:373 +#: ../source/key_projects.rst:358 msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." msgstr "" -#: ../source/key_projects.rst:386 +#: ../source/key_projects.rst:371 msgid "devpi" msgstr "" -#: ../source/key_projects.rst:388 +#: ../source/key_projects.rst:373 msgid "`Docs `__ | `Issues `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:392 +#: ../source/key_projects.rst:377 msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." msgstr "" -#: ../source/key_projects.rst:401 +#: ../source/key_projects.rst:386 msgid "flit" msgstr "" -#: ../source/key_projects.rst:403 +#: ../source/key_projects.rst:388 msgid "`Docs `__ | `Issues `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:407 +#: ../source/key_projects.rst:392 msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." msgstr "" -#: ../source/key_projects.rst:412 +#: ../source/key_projects.rst:397 msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." msgstr "" -#: ../source/key_projects.rst:422 +#: ../source/key_projects.rst:407 msgid "enscons" msgstr "" -#: ../source/key_projects.rst:424 +#: ../source/key_projects.rst:409 msgid "`Source `__ | `Issues `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:428 +#: ../source/key_projects.rst:413 msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." msgstr "" -#: ../source/key_projects.rst:443 +#: ../source/key_projects.rst:428 msgid "Hashdist" msgstr "" -#: ../source/key_projects.rst:445 +#: ../source/key_projects.rst:430 msgid "`Docs `__ | `GitHub `__" msgstr "" -#: ../source/key_projects.rst:448 +#: ../source/key_projects.rst:433 msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." msgstr "" -#: ../source/key_projects.rst:460 +#: ../source/key_projects.rst:445 msgid "hatch" msgstr "" -#: ../source/key_projects.rst:462 +#: ../source/key_projects.rst:447 msgid "`GitHub and Docs `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:465 +#: ../source/key_projects.rst:450 msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." msgstr "" -#: ../source/key_projects.rst:475 +#: ../source/key_projects.rst:460 msgid "multibuild" msgstr "" -#: ../source/key_projects.rst:477 +#: ../source/key_projects.rst:462 msgid "`GitHub `__" msgstr "" -#: ../source/key_projects.rst:479 +#: ../source/key_projects.rst:464 msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." msgstr "" -#: ../source/key_projects.rst:485 -msgid "pex" -msgstr "" - -#: ../source/key_projects.rst:487 +#: ../source/key_projects.rst:472 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:491 +#: ../source/key_projects.rst:476 msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." msgstr "" -#: ../source/key_projects.rst:500 +#: ../source/key_projects.rst:485 msgid "pip-tools" msgstr "" -#: ../source/key_projects.rst:502 +#: ../source/key_projects.rst:487 msgid "`GitHub and Docs `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:505 +#: ../source/key_projects.rst:490 msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." msgstr "" -#: ../source/key_projects.rst:517 +#: ../source/key_projects.rst:502 msgid "piwheels" msgstr "" -#: ../source/key_projects.rst:519 +#: ../source/key_projects.rst:504 msgid "`Website `__ | `Docs `__ | `GitHub `__" msgstr "" -#: ../source/key_projects.rst:523 +#: ../source/key_projects.rst:508 msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." msgstr "" -#: ../source/key_projects.rst:532 +#: ../source/key_projects.rst:517 msgid "poetry" msgstr "" -#: ../source/key_projects.rst:534 +#: ../source/key_projects.rst:519 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:538 +#: ../source/key_projects.rst:523 msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." msgstr "" -#: ../source/key_projects.rst:548 +#: ../source/key_projects.rst:533 msgid "pypiserver" msgstr "" -#: ../source/key_projects.rst:550 +#: ../source/key_projects.rst:535 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:554 +#: ../source/key_projects.rst:539 msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." msgstr "" -#: ../source/key_projects.rst:564 +#: ../source/key_projects.rst:549 msgid "scikit-build" msgstr "" -#: ../source/key_projects.rst:566 +#: ../source/key_projects.rst:551 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:570 +#: ../source/key_projects.rst:555 msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." msgstr "" -#: ../source/key_projects.rst:582 +#: ../source/key_projects.rst:567 msgid "shiv" msgstr "" -#: ../source/key_projects.rst:584 +#: ../source/key_projects.rst:569 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:588 +#: ../source/key_projects.rst:573 msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." msgstr "" -#: ../source/key_projects.rst:598 +#: ../source/key_projects.rst:583 msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" msgstr "" -#: ../source/key_projects.rst:603 +#: ../source/key_projects.rst:588 msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." msgstr "" -#: ../source/key_projects.rst:611 +#: ../source/key_projects.rst:596 msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." msgstr "" -#: ../source/key_projects.rst:617 +#: ../source/key_projects.rst:602 msgid "zest.releaser" msgstr "" -#: ../source/key_projects.rst:619 +#: ../source/key_projects.rst:604 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:623 +#: ../source/key_projects.rst:608 msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." msgstr "" -#: ../source/key_projects.rst:630 +#: ../source/key_projects.rst:615 msgid "Standard Library Projects" msgstr "" -#: ../source/key_projects.rst:635 +#: ../source/key_projects.rst:620 msgid "ensurepip" msgstr "" -#: ../source/key_projects.rst:637 +#: ../source/key_projects.rst:622 msgid "`Docs `__ | `Issues `__" msgstr "" -#: ../source/key_projects.rst:640 +#: ../source/key_projects.rst:625 msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." msgstr "" -#: ../source/key_projects.rst:649 +#: ../source/key_projects.rst:634 msgid "distutils" msgstr "" -#: ../source/key_projects.rst:651 +#: ../source/key_projects.rst:636 msgid "`Docs `__ | `Issues `__" msgstr "" -#: ../source/key_projects.rst:654 +#: ../source/key_projects.rst:639 msgid "The original Python packaging system, added to the standard library in Python 2.0." msgstr "" -#: ../source/key_projects.rst:657 +#: ../source/key_projects.rst:642 msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." msgstr "" -#: ../source/key_projects.rst:670 +#: ../source/key_projects.rst:655 msgid "venv" msgstr "" -#: ../source/key_projects.rst:672 +#: ../source/key_projects.rst:657 msgid "`Docs `__ | `Issues `__" msgstr "" -#: ../source/key_projects.rst:675 +#: ../source/key_projects.rst:660 msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." msgstr "" @@ -5732,6 +5740,10 @@ msgstr "" msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." msgstr "" +#: ../source/overview.rst:148 +msgid "A summary of Python's packaging capabilities for tools and libraries." +msgstr "" + #: ../source/overview.rst:148 msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." msgstr "" @@ -6044,6 +6056,10 @@ msgstr "" msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." msgstr "" +#: ../source/overview.rst:389 +msgid "A summary of technologies used to package Python applications." +msgstr "" + #: ../source/overview.rst:389 msgid "The simplified gamut of technologies used to package Python applications." msgstr "" @@ -6252,6 +6268,10 @@ msgstr "" msgid "Distribution name, e.g. 'django', 'pyramid'." msgstr "" +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "version" +msgstr "" + #: ../source/specifications/binary-distribution-format.rst:127 msgid "Distribution version, e.g. 1.0." msgstr "" @@ -7166,20 +7186,10 @@ msgstr "" msgid "The only fields required to be statically defined are:" msgstr "" -#: ../source/specifications/declaring-project-metadata.rst:29 -#: ../source/specifications/declaring-project-metadata.rst:41 -msgid "``name``" -msgstr "" - #: ../source/specifications/declaring-project-metadata.rst:31 msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" msgstr "" -#: ../source/specifications/declaring-project-metadata.rst:34 -#: ../source/specifications/declaring-project-metadata.rst:54 -msgid "``version``" -msgstr "" - #: ../source/specifications/declaring-project-metadata.rst:36 msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." msgstr "" @@ -7215,10 +7225,6 @@ msgstr "" msgid "Users SHOULD prefer to specify already-normalized versions." msgstr "" -#: ../source/specifications/declaring-project-metadata.rst:66 -msgid "``description``" -msgstr "" - #: ../source/specifications/declaring-project-metadata.rst:69 msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" msgstr "" @@ -7267,10 +7273,6 @@ msgstr "" msgid "The Python version requirements of the project." msgstr "" -#: ../source/specifications/declaring-project-metadata.rst:125 -msgid "``license``" -msgstr "" - #: ../source/specifications/declaring-project-metadata.rst:127 msgid "TOML_ type: table" msgstr "" @@ -7327,10 +7329,6 @@ msgstr "" msgid "Multiple values should be separated by commas." msgstr "" -#: ../source/specifications/declaring-project-metadata.rst:181 -msgid "``keywords``" -msgstr "" - #: ../source/specifications/declaring-project-metadata.rst:183 #: ../source/specifications/declaring-project-metadata.rst:193 msgid "TOML_ type: array of strings" @@ -7344,10 +7342,6 @@ msgstr "" msgid "The keywords for the project." msgstr "" -#: ../source/specifications/declaring-project-metadata.rst:191 -msgid "``classifiers``" -msgstr "" - #: ../source/specifications/declaring-project-metadata.rst:194 msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" msgstr "" @@ -8321,30 +8315,38 @@ msgid "Source distributions are also known as *sdists* for short." msgstr "" #: ../source/specifications/source-distribution-format.rst:24 -msgid "Source distribution file name" +msgid "Source trees" msgstr "" #: ../source/specifications/source-distribution-format.rst:26 +msgid "A *source tree* is a collection of files and directories -- like a version control system checkout -- which contains a :file:`pyproject.toml` file that can be use to build a source distribution from the contained files and directories. :pep:`517` and :pep:`518` specify what is required to meet the definition of what :file:`pyproject.toml` must contain for something to be deemed a source tree." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:34 +msgid "Source distribution file name" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:36 msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." msgstr "" -#: ../source/specifications/source-distribution-format.rst:31 +#: ../source/specifications/source-distribution-format.rst:41 msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." msgstr "" -#: ../source/specifications/source-distribution-format.rst:35 +#: ../source/specifications/source-distribution-format.rst:45 msgid "Source distribution file format" msgstr "" -#: ../source/specifications/source-distribution-format.rst:37 +#: ../source/specifications/source-distribution-format.rst:47 msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." msgstr "" -#: ../source/specifications/source-distribution-format.rst:45 +#: ../source/specifications/source-distribution-format.rst:55 msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." msgstr "" -#: ../source/specifications/source-distribution-format.rst:48 +#: ../source/specifications/source-distribution-format.rst:58 msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." msgstr "" @@ -8369,7 +8371,7 @@ msgid "For support related to a specific project, see the links on the :doc:`Pro msgstr "" #: ../source/support.rst:8 -msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." +msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." msgstr "" #: ../source/tutorials/creating-documentation.rst:5 @@ -8517,246 +8519,246 @@ msgid "Ensure pip, setuptools, and wheel are up to date" msgstr "" #: ../source/tutorials/installing-packages.rst:161 -msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" +msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives:" msgstr "" -#: ../source/tutorials/installing-packages.rst:169 +#: ../source/tutorials/installing-packages.rst:178 msgid "Optionally, create a virtual environment" msgstr "" -#: ../source/tutorials/installing-packages.rst:171 +#: ../source/tutorials/installing-packages.rst:180 msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" msgstr "" -#: ../source/tutorials/installing-packages.rst:188 +#: ../source/tutorials/installing-packages.rst:197 msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." msgstr "" -#: ../source/tutorials/installing-packages.rst:195 +#: ../source/tutorials/installing-packages.rst:204 msgid "Creating Virtual Environments" msgstr "" -#: ../source/tutorials/installing-packages.rst:197 +#: ../source/tutorials/installing-packages.rst:206 msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." msgstr "" -#: ../source/tutorials/installing-packages.rst:203 +#: ../source/tutorials/installing-packages.rst:212 msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." msgstr "" -#: ../source/tutorials/installing-packages.rst:209 +#: ../source/tutorials/installing-packages.rst:218 msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." msgstr "" -#: ../source/tutorials/installing-packages.rst:213 +#: ../source/tutorials/installing-packages.rst:222 msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." msgstr "" -#: ../source/tutorials/installing-packages.rst:216 +#: ../source/tutorials/installing-packages.rst:225 msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." msgstr "" -#: ../source/tutorials/installing-packages.rst:220 +#: ../source/tutorials/installing-packages.rst:229 msgid "Currently, there are two common tools for creating Python virtual environments:" msgstr "" -#: ../source/tutorials/installing-packages.rst:222 +#: ../source/tutorials/installing-packages.rst:231 msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." msgstr "" -#: ../source/tutorials/installing-packages.rst:225 +#: ../source/tutorials/installing-packages.rst:234 msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." msgstr "" -#: ../source/tutorials/installing-packages.rst:230 +#: ../source/tutorials/installing-packages.rst:239 msgid "The basic usage is like so:" msgstr "" -#: ../source/tutorials/installing-packages.rst:232 +#: ../source/tutorials/installing-packages.rst:241 msgid "Using `venv`_:" msgstr "" -#: ../source/tutorials/installing-packages.rst:248 +#: ../source/tutorials/installing-packages.rst:257 msgid "Using :ref:`virtualenv`:" msgstr "" -#: ../source/tutorials/installing-packages.rst:264 +#: ../source/tutorials/installing-packages.rst:273 msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." msgstr "" -#: ../source/tutorials/installing-packages.rst:266 +#: ../source/tutorials/installing-packages.rst:275 msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." msgstr "" -#: ../source/tutorials/installing-packages.rst:271 +#: ../source/tutorials/installing-packages.rst:280 msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" msgstr "" -#: ../source/tutorials/installing-packages.rst:281 +#: ../source/tutorials/installing-packages.rst:290 msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." msgstr "" -#: ../source/tutorials/installing-packages.rst:288 +#: ../source/tutorials/installing-packages.rst:297 msgid "Use pip for Installing" msgstr "" -#: ../source/tutorials/installing-packages.rst:290 -msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." +#: ../source/tutorials/installing-packages.rst:299 +msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete :doc:`Reference Guide `." msgstr "" -#: ../source/tutorials/installing-packages.rst:297 +#: ../source/tutorials/installing-packages.rst:305 msgid "Installing from PyPI" msgstr "" -#: ../source/tutorials/installing-packages.rst:299 +#: ../source/tutorials/installing-packages.rst:307 msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." msgstr "" -#: ../source/tutorials/installing-packages.rst:307 +#: ../source/tutorials/installing-packages.rst:315 msgid "To install the latest version of \"SomeProject\":" msgstr "" -#: ../source/tutorials/installing-packages.rst:321 +#: ../source/tutorials/installing-packages.rst:329 msgid "To install a specific version:" msgstr "" -#: ../source/tutorials/installing-packages.rst:335 +#: ../source/tutorials/installing-packages.rst:343 msgid "To install greater than or equal to one version and less than another:" msgstr "" -#: ../source/tutorials/installing-packages.rst:350 +#: ../source/tutorials/installing-packages.rst:358 msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" msgstr "" -#: ../source/tutorials/installing-packages.rst:365 +#: ../source/tutorials/installing-packages.rst:373 msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." msgstr "" -#: ../source/tutorials/installing-packages.rst:370 +#: ../source/tutorials/installing-packages.rst:378 msgid "Source Distributions vs Wheels" msgstr "" -#: ../source/tutorials/installing-packages.rst:372 +#: ../source/tutorials/installing-packages.rst:380 msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." msgstr "" -#: ../source/tutorials/installing-packages.rst:378 +#: ../source/tutorials/installing-packages.rst:386 msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." msgstr "" -#: ../source/tutorials/installing-packages.rst:383 +#: ../source/tutorials/installing-packages.rst:391 msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." msgstr "" -#: ../source/tutorials/installing-packages.rst:391 +#: ../source/tutorials/installing-packages.rst:399 msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." msgstr "" -#: ../source/tutorials/installing-packages.rst:408 +#: ../source/tutorials/installing-packages.rst:416 msgid "Installing to the User Site" msgstr "" -#: ../source/tutorials/installing-packages.rst:410 +#: ../source/tutorials/installing-packages.rst:418 msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" msgstr "" -#: ../source/tutorials/installing-packages.rst:425 +#: ../source/tutorials/installing-packages.rst:433 msgid "For more information see the `User Installs `_ section from the pip docs." msgstr "" -#: ../source/tutorials/installing-packages.rst:429 +#: ../source/tutorials/installing-packages.rst:437 msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." msgstr "" -#: ../source/tutorials/installing-packages.rst:432 +#: ../source/tutorials/installing-packages.rst:440 msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" msgstr "" -#: ../source/tutorials/installing-packages.rst:440 +#: ../source/tutorials/installing-packages.rst:448 msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." msgstr "" -#: ../source/tutorials/installing-packages.rst:446 +#: ../source/tutorials/installing-packages.rst:454 msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." msgstr "" -#: ../source/tutorials/installing-packages.rst:462 +#: ../source/tutorials/installing-packages.rst:470 msgid "Install a list of requirements specified in a :ref:`Requirements File `." msgstr "" -#: ../source/tutorials/installing-packages.rst:478 +#: ../source/tutorials/installing-packages.rst:486 msgid "Installing from VCS" msgstr "" -#: ../source/tutorials/installing-packages.rst:480 +#: ../source/tutorials/installing-packages.rst:488 msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." msgstr "" -#: ../source/tutorials/installing-packages.rst:502 +#: ../source/tutorials/installing-packages.rst:510 msgid "Installing from other Indexes" msgstr "" -#: ../source/tutorials/installing-packages.rst:504 +#: ../source/tutorials/installing-packages.rst:512 msgid "Install from an alternate index" msgstr "" -#: ../source/tutorials/installing-packages.rst:518 +#: ../source/tutorials/installing-packages.rst:526 msgid "Search an additional index during install, in addition to :term:`PyPI `" msgstr "" -#: ../source/tutorials/installing-packages.rst:534 +#: ../source/tutorials/installing-packages.rst:542 msgid "Installing from a local src tree" msgstr "" -#: ../source/tutorials/installing-packages.rst:537 +#: ../source/tutorials/installing-packages.rst:545 msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." msgstr "" -#: ../source/tutorials/installing-packages.rst:554 +#: ../source/tutorials/installing-packages.rst:562 msgid "You can also install normally from src" msgstr "" -#: ../source/tutorials/installing-packages.rst:571 +#: ../source/tutorials/installing-packages.rst:579 msgid "Install a particular source archive file." msgstr "" -#: ../source/tutorials/installing-packages.rst:585 +#: ../source/tutorials/installing-packages.rst:593 msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" msgstr "" -#: ../source/tutorials/installing-packages.rst:605 +#: ../source/tutorials/installing-packages.rst:613 msgid "Installing from other sources" msgstr "" -#: ../source/tutorials/installing-packages.rst:607 +#: ../source/tutorials/installing-packages.rst:615 msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." msgstr "" -#: ../source/tutorials/installing-packages.rst:619 +#: ../source/tutorials/installing-packages.rst:627 msgid "Installing Prereleases" msgstr "" -#: ../source/tutorials/installing-packages.rst:621 +#: ../source/tutorials/installing-packages.rst:629 msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." msgstr "" -#: ../source/tutorials/installing-packages.rst:637 +#: ../source/tutorials/installing-packages.rst:645 msgid "Installing Setuptools \"Extras\"" msgstr "" -#: ../source/tutorials/installing-packages.rst:639 +#: ../source/tutorials/installing-packages.rst:647 msgid "Install `setuptools extras`_." msgstr "" -#: ../source/tutorials/installing-packages.rst:659 +#: ../source/tutorials/installing-packages.rst:667 msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." msgstr "" -#: ../source/tutorials/installing-packages.rst:668 +#: ../source/tutorials/installing-packages.rst:676 msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." msgstr "" -#: ../source/tutorials/installing-packages.rst:673 +#: ../source/tutorials/installing-packages.rst:681 msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" msgstr "" @@ -8882,7 +8884,7 @@ msgid "This tutorial walks you through how to package a simple Python project. I msgstr "" #: ../source/tutorials/packaging-projects.rst:10 -msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" +msgid "If you have trouble running the commands in this tutorial, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" msgstr "" #: ../source/tutorials/packaging-projects.rst:18 From 7260424415ebcdac27886773d97387ed198e474c Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Fri, 27 Aug 2021 12:18:45 +0000 Subject: [PATCH 0130/1072] Update messages.pot as of version 0ef3d3f --- locales/messages.pot | 318 +++++++++++++++++++++---------------------- 1 file changed, 159 insertions(+), 159 deletions(-) diff --git a/locales/messages.pot b/locales/messages.pot index 4eac54e62..35aa4171a 100644 --- a/locales/messages.pot +++ b/locales/messages.pot @@ -8,7 +8,7 @@ msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide \n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-08-26 13:33+0000\n" +"POT-Creation-Date: 2021-08-27 12:18+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" @@ -526,7 +526,7 @@ msgid "Lastly, it's important to understand that ``install_requires`` is a listi msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:64 -#: ../source/tutorials/installing-packages.rst:468 +#: ../source/tutorials/installing-packages.rst:469 msgid "Requirements files" msgstr "" @@ -681,7 +681,7 @@ msgid "Yes, via setup.cfg" msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:68 -msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" +msgid "https://setuptools.readthedocs.io/en/latest/deprecated/easy_install.html#natural-script-launcher" msgstr "" #: ../source/discussions/wheel-vs-egg.rst:5 @@ -773,224 +773,224 @@ msgid "Egg" msgstr "" #: ../source/glossary.rst:44 -msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" +msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see ` :doc:`The Internal Structure of Python Eggs ` and `Python Eggs `_" msgstr "" -#: ../source/glossary.rst:49 +#: ../source/glossary.rst:48 msgid "Extension Module" msgstr "" -#: ../source/glossary.rst:52 +#: ../source/glossary.rst:51 msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." msgstr "" -#: ../source/glossary.rst:59 +#: ../source/glossary.rst:58 msgid "Known Good Set (KGS)" msgstr "" -#: ../source/glossary.rst:62 +#: ../source/glossary.rst:61 msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." msgstr "" -#: ../source/glossary.rst:68 +#: ../source/glossary.rst:67 msgid "Import Package" msgstr "" -#: ../source/glossary.rst:71 +#: ../source/glossary.rst:70 msgid "A Python module which can contain other modules or recursively, other packages." msgstr "" -#: ../source/glossary.rst:74 +#: ../source/glossary.rst:73 msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." msgstr "" -#: ../source/glossary.rst:78 +#: ../source/glossary.rst:77 msgid "Module" msgstr "" -#: ../source/glossary.rst:81 +#: ../source/glossary.rst:80 msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." msgstr "" -#: ../source/glossary.rst:84 +#: ../source/glossary.rst:83 msgid "Package Index" msgstr "" -#: ../source/glossary.rst:87 +#: ../source/glossary.rst:86 msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." msgstr "" -#: ../source/glossary.rst:90 +#: ../source/glossary.rst:89 msgid "Per Project Index" msgstr "" -#: ../source/glossary.rst:93 +#: ../source/glossary.rst:92 msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." msgstr "" -#: ../source/glossary.rst:97 +#: ../source/glossary.rst:96 msgid "Project" msgstr "" -#: ../source/glossary.rst:100 +#: ../source/glossary.rst:99 msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." msgstr "" -#: ../source/glossary.rst:104 +#: ../source/glossary.rst:103 msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." msgstr "" -#: ../source/glossary.rst:110 +#: ../source/glossary.rst:109 msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." msgstr "" -#: ../source/glossary.rst:115 +#: ../source/glossary.rst:114 msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." msgstr "" -#: ../source/glossary.rst:121 +#: ../source/glossary.rst:120 msgid "Pure Module" msgstr "" -#: ../source/glossary.rst:124 +#: ../source/glossary.rst:123 msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." msgstr "" -#: ../source/glossary.rst:127 +#: ../source/glossary.rst:126 msgid "Python Packaging Authority (PyPA)" msgstr "" -#: ../source/glossary.rst:130 +#: ../source/glossary.rst:129 msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." msgstr "" -#: ../source/glossary.rst:139 +#: ../source/glossary.rst:138 msgid "Python Package Index (PyPI)" msgstr "" -#: ../source/glossary.rst:142 +#: ../source/glossary.rst:141 msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." msgstr "" -#: ../source/glossary.rst:145 +#: ../source/glossary.rst:144 msgid "pypi.org" msgstr "" -#: ../source/glossary.rst:148 +#: ../source/glossary.rst:147 msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." msgstr "" -#: ../source/glossary.rst:152 +#: ../source/glossary.rst:151 msgid "pyproject.toml" msgstr "" -#: ../source/glossary.rst:155 +#: ../source/glossary.rst:154 msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." msgstr "" -#: ../source/glossary.rst:157 +#: ../source/glossary.rst:156 msgid "Release" msgstr "" -#: ../source/glossary.rst:160 +#: ../source/glossary.rst:159 msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." msgstr "" -#: ../source/glossary.rst:163 +#: ../source/glossary.rst:162 msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." msgstr "" -#: ../source/glossary.rst:168 +#: ../source/glossary.rst:167 msgid "Requirement" msgstr "" -#: ../source/glossary.rst:171 +#: ../source/glossary.rst:170 msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." msgstr "" -#: ../source/glossary.rst:177 +#: ../source/glossary.rst:176 msgid "Requirement Specifier" msgstr "" -#: ../source/glossary.rst:180 +#: ../source/glossary.rst:179 msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" msgstr "" -#: ../source/glossary.rst:187 +#: ../source/glossary.rst:186 msgid "Requirements File" msgstr "" -#: ../source/glossary.rst:190 +#: ../source/glossary.rst:189 msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." msgstr "" -#: ../source/glossary.rst:194 +#: ../source/glossary.rst:193 #: ../source/guides/distributing-packages-using-setuptools.rst:56 msgid "setup.py" msgstr "" -#: ../source/glossary.rst:195 +#: ../source/glossary.rst:194 #: ../source/guides/distributing-packages-using-setuptools.rst:77 msgid "setup.cfg" msgstr "" -#: ../source/glossary.rst:198 +#: ../source/glossary.rst:197 msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." msgstr "" -#: ../source/glossary.rst:201 +#: ../source/glossary.rst:200 msgid "Source Archive" msgstr "" -#: ../source/glossary.rst:204 +#: ../source/glossary.rst:203 msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." msgstr "" -#: ../source/glossary.rst:208 +#: ../source/glossary.rst:207 msgid "Source Distribution (or \"sdist\")" msgstr "" -#: ../source/glossary.rst:211 +#: ../source/glossary.rst:210 msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." msgstr "" -#: ../source/glossary.rst:216 +#: ../source/glossary.rst:215 msgid "System Package" msgstr "" -#: ../source/glossary.rst:219 +#: ../source/glossary.rst:218 msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." msgstr "" -#: ../source/glossary.rst:222 +#: ../source/glossary.rst:221 msgid "Version Specifier" msgstr "" -#: ../source/glossary.rst:225 +#: ../source/glossary.rst:224 msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." msgstr "" -#: ../source/glossary.rst:231 +#: ../source/glossary.rst:230 msgid "Virtual Environment" msgstr "" -#: ../source/glossary.rst:234 +#: ../source/glossary.rst:233 msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." msgstr "" -#: ../source/glossary.rst:238 +#: ../source/glossary.rst:237 msgid "Wheel" msgstr "" -#: ../source/glossary.rst:241 +#: ../source/glossary.rst:240 msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." msgstr "" -#: ../source/glossary.rst:244 +#: ../source/glossary.rst:243 msgid "Working Set" msgstr "" -#: ../source/glossary.rst:247 +#: ../source/glossary.rst:246 msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." msgstr "" @@ -1831,7 +1831,7 @@ msgid "Use this keyword to specify any plugins that your project provides for an msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:512 -msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." +msgid "For more information, see the section on :ref:`Advertising Behavior ` from the :ref:`setuptools` docs." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:516 @@ -1843,11 +1843,11 @@ msgid "``console_scripts``" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:531 -msgid "Use ``console_script`` `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgid "Use ``console_script`` :ref:`entry points ` to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:538 -msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." +msgid "For more information, see `Automatic Script Creation `_ from the :doc:`setuptools docs `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:545 @@ -2019,7 +2019,7 @@ msgid "Lastly, if you don't want to install any dependencies at all, you can run msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:709 -msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." +msgid "For more information, see the :doc:`` section of the :doc:`setuptools docs `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:716 @@ -2187,7 +2187,7 @@ msgid "You can see if your package has successfully uploaded by navigating to th msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:949 -#: ../source/tutorials/installing-packages.rst:671 +#: ../source/tutorials/installing-packages.rst:672 msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." msgstr "" @@ -2444,30 +2444,30 @@ msgid "pip provides a number of facilities for speeding up installation by using msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:32 -msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." +msgid ":ref:`Fast & local installs ` by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:36 +#: ../source/guides/index-mirrors-and-caches.rst:35 msgid "A variation on the above which pre-builds the installation files for the requirements using :ref:`python -m pip wheel `:" msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:46 +#: ../source/guides/index-mirrors-and-caches.rst:45 msgid "Caching with devpi" msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:48 +#: ../source/guides/index-mirrors-and-caches.rst:47 msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:56 +#: ../source/guides/index-mirrors-and-caches.rst:55 msgid "Complete mirror with bandersnatch" msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:58 +#: ../source/guides/index-mirrors-and-caches.rst:57 msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:64 +#: ../source/guides/index-mirrors-and-caches.rst:63 msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." msgstr "" @@ -2909,84 +2909,84 @@ msgid "pip can install a package directly from source, for example:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:326 -msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" +msgid "Additionally, pip can install packages from source in :doc:`development mode `, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:347 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:345 msgid "Installing from version control systems" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:349 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:347 msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:356 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:354 msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 -#: ../source/tutorials/installing-packages.rst:577 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:359 +#: ../source/tutorials/installing-packages.rst:578 msgid "Installing from local archives" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:363 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:378 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:376 msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:394 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:392 msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:398 msgid "Using other package indexes" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:402 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:415 msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:434 -#: ../source/tutorials/installing-packages.rst:397 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:432 +#: ../source/tutorials/installing-packages.rst:398 msgid "Upgrading packages" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:436 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:434 msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:452 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:450 msgid "Using requirements files" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:454 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:452 msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:476 msgid "Freezing dependencies" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:480 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:495 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:493 msgid "Which will output a list of package specifiers such as:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:511 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:509 msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." msgstr "" @@ -3416,7 +3416,7 @@ msgid "Implementing binary extensions" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:224 -msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." +msgid "The CPython :doc:`Extending and Embedding ` guide includes an introduction to writing a :doc:`custom extension module in C `." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:241 @@ -3584,7 +3584,7 @@ msgid "pkgutil-style namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:131 -msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." +msgid "Python 2.3 introduced the :doc:`pkgutil ` module and the :py:func:`python:pkgutil.extend_path` function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:136 @@ -3592,12 +3592,12 @@ msgid "To create a pkgutil-style namespace package, you need to provide an :file msgstr "" #: ../source/guides/packaging-namespace-packages.rst:148 -#: ../source/guides/packaging-namespace-packages.rst:194 +#: ../source/guides/packaging-namespace-packages.rst:193 msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:155 -#: ../source/guides/packaging-namespace-packages.rst:201 +#: ../source/guides/packaging-namespace-packages.rst:200 msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." msgstr "" @@ -3605,31 +3605,31 @@ msgstr "" msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." msgstr "" -#: ../source/guides/packaging-namespace-packages.rst:171 +#: ../source/guides/packaging-namespace-packages.rst:170 msgid "pkg_resources-style namespace packages" msgstr "" -#: ../source/guides/packaging-namespace-packages.rst:173 +#: ../source/guides/packaging-namespace-packages.rst:172 msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." msgstr "" -#: ../source/guides/packaging-namespace-packages.rst:182 +#: ../source/guides/packaging-namespace-packages.rst:181 msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" msgstr "" -#: ../source/guides/packaging-namespace-packages.rst:206 +#: ../source/guides/packaging-namespace-packages.rst:205 msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" msgstr "" -#: ../source/guides/packaging-namespace-packages.rst:216 +#: ../source/guides/packaging-namespace-packages.rst:215 msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." msgstr "" -#: ../source/guides/packaging-namespace-packages.rst:223 +#: ../source/guides/packaging-namespace-packages.rst:222 msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" msgstr "" -#: ../source/guides/packaging-namespace-packages.rst:237 +#: ../source/guides/packaging-namespace-packages.rst:236 msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." msgstr "" @@ -3710,7 +3710,7 @@ msgid "Then, add the following under the ``build-n-publish`` section:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 -msgid "This will download your repository into the CI runner and then install and activate Python 3.7." +msgid "This will download your repository into the CI runner and then install and activate Python 3.9." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 @@ -4166,7 +4166,7 @@ msgid "Use :ref:`pip` to install Python :term:`packages ` msgstr "" #: ../source/guides/tool-recommendations.rst:34 -msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" +msgid "Use :ref:`virtualenv`, or :doc:`venv ` to isolate application specific dependencies from a shared Python installation. [4]_" msgstr "" #: ../source/guides/tool-recommendations.rst:37 @@ -5705,7 +5705,7 @@ msgid "So long as your code contains nothing but pure Python code, and you know msgstr "" #: ../source/overview.rst:95 -msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." +msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can :doc:`go here to learn more `." msgstr "" #: ../source/overview.rst:100 @@ -5761,7 +5761,7 @@ msgid "With the variety of operating systems, configurations, and people out the msgstr "" #: ../source/overview.rst:166 -msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." +msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like :doc:`setuptools entry_points `." msgstr "" #: ../source/overview.rst:172 @@ -5873,7 +5873,7 @@ msgid "`PEX `_ (Python EXecutable)" msgstr "" #: ../source/overview.rst:252 -msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" +msgid ":doc:`zipapp ` (does not help manage dependencies, requires Python 3.5+)" msgstr "" #: ../source/overview.rst:253 @@ -8527,7 +8527,7 @@ msgid "Optionally, create a virtual environment" msgstr "" #: ../source/tutorials/installing-packages.rst:180 -msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" +msgid "See :ref:`section below ` for details, but here's the basic :doc:`venv ` [3]_ command to use on a typical Linux system:" msgstr "" #: ../source/tutorials/installing-packages.rst:197 @@ -8563,7 +8563,7 @@ msgid "Currently, there are two common tools for creating Python virtual environ msgstr "" #: ../source/tutorials/installing-packages.rst:231 -msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." +msgid ":doc:`venv ` is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." msgstr "" #: ../source/tutorials/installing-packages.rst:234 @@ -8575,7 +8575,7 @@ msgid "The basic usage is like so:" msgstr "" #: ../source/tutorials/installing-packages.rst:241 -msgid "Using `venv`_:" +msgid "Using :doc:`venv `:" msgstr "" #: ../source/tutorials/installing-packages.rst:257 @@ -8583,182 +8583,182 @@ msgid "Using :ref:`virtualenv`:" msgstr "" #: ../source/tutorials/installing-packages.rst:273 -msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." +msgid "For more information, see the :doc:`venv ` docs or the `virtualenv `_ docs." msgstr "" -#: ../source/tutorials/installing-packages.rst:275 +#: ../source/tutorials/installing-packages.rst:276 msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." msgstr "" -#: ../source/tutorials/installing-packages.rst:280 +#: ../source/tutorials/installing-packages.rst:281 msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" msgstr "" -#: ../source/tutorials/installing-packages.rst:290 +#: ../source/tutorials/installing-packages.rst:291 msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." msgstr "" -#: ../source/tutorials/installing-packages.rst:297 +#: ../source/tutorials/installing-packages.rst:298 msgid "Use pip for Installing" msgstr "" -#: ../source/tutorials/installing-packages.rst:299 -msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete :doc:`Reference Guide `." +#: ../source/tutorials/installing-packages.rst:300 +msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the :doc:`pip docs `, which includes a complete :doc:`Reference Guide `." msgstr "" -#: ../source/tutorials/installing-packages.rst:305 +#: ../source/tutorials/installing-packages.rst:306 msgid "Installing from PyPI" msgstr "" -#: ../source/tutorials/installing-packages.rst:307 +#: ../source/tutorials/installing-packages.rst:308 msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." msgstr "" -#: ../source/tutorials/installing-packages.rst:315 +#: ../source/tutorials/installing-packages.rst:316 msgid "To install the latest version of \"SomeProject\":" msgstr "" -#: ../source/tutorials/installing-packages.rst:329 +#: ../source/tutorials/installing-packages.rst:330 msgid "To install a specific version:" msgstr "" -#: ../source/tutorials/installing-packages.rst:343 +#: ../source/tutorials/installing-packages.rst:344 msgid "To install greater than or equal to one version and less than another:" msgstr "" -#: ../source/tutorials/installing-packages.rst:358 +#: ../source/tutorials/installing-packages.rst:359 msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" msgstr "" -#: ../source/tutorials/installing-packages.rst:373 +#: ../source/tutorials/installing-packages.rst:374 msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." msgstr "" -#: ../source/tutorials/installing-packages.rst:378 +#: ../source/tutorials/installing-packages.rst:379 msgid "Source Distributions vs Wheels" msgstr "" -#: ../source/tutorials/installing-packages.rst:380 +#: ../source/tutorials/installing-packages.rst:381 msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." msgstr "" -#: ../source/tutorials/installing-packages.rst:386 +#: ../source/tutorials/installing-packages.rst:387 msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." msgstr "" -#: ../source/tutorials/installing-packages.rst:391 +#: ../source/tutorials/installing-packages.rst:392 msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." msgstr "" -#: ../source/tutorials/installing-packages.rst:399 +#: ../source/tutorials/installing-packages.rst:400 msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." msgstr "" -#: ../source/tutorials/installing-packages.rst:416 +#: ../source/tutorials/installing-packages.rst:417 msgid "Installing to the User Site" msgstr "" -#: ../source/tutorials/installing-packages.rst:418 +#: ../source/tutorials/installing-packages.rst:419 msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" msgstr "" -#: ../source/tutorials/installing-packages.rst:433 +#: ../source/tutorials/installing-packages.rst:434 msgid "For more information see the `User Installs `_ section from the pip docs." msgstr "" -#: ../source/tutorials/installing-packages.rst:437 +#: ../source/tutorials/installing-packages.rst:438 msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." msgstr "" -#: ../source/tutorials/installing-packages.rst:440 +#: ../source/tutorials/installing-packages.rst:441 msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" msgstr "" -#: ../source/tutorials/installing-packages.rst:448 +#: ../source/tutorials/installing-packages.rst:449 msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." msgstr "" -#: ../source/tutorials/installing-packages.rst:454 +#: ../source/tutorials/installing-packages.rst:455 msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." msgstr "" -#: ../source/tutorials/installing-packages.rst:470 +#: ../source/tutorials/installing-packages.rst:471 msgid "Install a list of requirements specified in a :ref:`Requirements File `." msgstr "" -#: ../source/tutorials/installing-packages.rst:486 +#: ../source/tutorials/installing-packages.rst:487 msgid "Installing from VCS" msgstr "" -#: ../source/tutorials/installing-packages.rst:488 +#: ../source/tutorials/installing-packages.rst:489 msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." msgstr "" -#: ../source/tutorials/installing-packages.rst:510 +#: ../source/tutorials/installing-packages.rst:511 msgid "Installing from other Indexes" msgstr "" -#: ../source/tutorials/installing-packages.rst:512 +#: ../source/tutorials/installing-packages.rst:513 msgid "Install from an alternate index" msgstr "" -#: ../source/tutorials/installing-packages.rst:526 +#: ../source/tutorials/installing-packages.rst:527 msgid "Search an additional index during install, in addition to :term:`PyPI `" msgstr "" -#: ../source/tutorials/installing-packages.rst:542 +#: ../source/tutorials/installing-packages.rst:543 msgid "Installing from a local src tree" msgstr "" -#: ../source/tutorials/installing-packages.rst:545 -msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." +#: ../source/tutorials/installing-packages.rst:546 +msgid "Installing from local src in :doc:`Development Mode `, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." msgstr "" -#: ../source/tutorials/installing-packages.rst:562 +#: ../source/tutorials/installing-packages.rst:563 msgid "You can also install normally from src" msgstr "" -#: ../source/tutorials/installing-packages.rst:579 +#: ../source/tutorials/installing-packages.rst:580 msgid "Install a particular source archive file." msgstr "" -#: ../source/tutorials/installing-packages.rst:593 +#: ../source/tutorials/installing-packages.rst:594 msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" msgstr "" -#: ../source/tutorials/installing-packages.rst:613 +#: ../source/tutorials/installing-packages.rst:614 msgid "Installing from other sources" msgstr "" -#: ../source/tutorials/installing-packages.rst:615 +#: ../source/tutorials/installing-packages.rst:616 msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." msgstr "" -#: ../source/tutorials/installing-packages.rst:627 +#: ../source/tutorials/installing-packages.rst:628 msgid "Installing Prereleases" msgstr "" -#: ../source/tutorials/installing-packages.rst:629 +#: ../source/tutorials/installing-packages.rst:630 msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." msgstr "" -#: ../source/tutorials/installing-packages.rst:645 +#: ../source/tutorials/installing-packages.rst:646 msgid "Installing Setuptools \"Extras\"" msgstr "" -#: ../source/tutorials/installing-packages.rst:647 +#: ../source/tutorials/installing-packages.rst:648 msgid "Install `setuptools extras`_." msgstr "" -#: ../source/tutorials/installing-packages.rst:667 +#: ../source/tutorials/installing-packages.rst:668 msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." msgstr "" -#: ../source/tutorials/installing-packages.rst:676 +#: ../source/tutorials/installing-packages.rst:677 msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." msgstr "" -#: ../source/tutorials/installing-packages.rst:681 +#: ../source/tutorials/installing-packages.rst:682 msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" msgstr "" @@ -8799,7 +8799,7 @@ msgid "Use ``pip`` to install Pipenv:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:54 -msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." +msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the :py:data:`user base `'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." msgstr "" #: ../source/tutorials/managing-dependencies.rst:65 From 4999c87ebb0e20aeadeccc2a42036ac009c6a0ec Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sat, 4 Sep 2021 14:30:28 +0800 Subject: [PATCH 0131/1072] Remove an empty line Co-authored-by: Sviatoslav Sydorenko --- source/conf.py | 1 - 1 file changed, 1 deletion(-) diff --git a/source/conf.py b/source/conf.py index c10dad13d..82ba64734 100644 --- a/source/conf.py +++ b/source/conf.py @@ -381,7 +381,6 @@ 'user': (f'{github_sponsors_url}/%s', '@'), # noqa: WPS323 } - linkcheck_ignore = [ "http://localhost:\d+", # Ignoring these links as they will redirect to login page if folks haven't logged in. From 89580bb9dd1b5db188f02e9cbbd8d821da2e95ac Mon Sep 17 00:00:00 2001 From: Rafael Fontenelle Date: Sun, 5 Sep 2021 16:34:36 +0200 Subject: [PATCH 0132/1072] Translated using Weblate (Portuguese (Brazil)) Currently translated at 19.3% (440 of 2271 strings) Co-authored-by: Rafael Fontenelle Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/pt_BR/ Translation: pypa/packaging.python.org --- locales/pt_BR/LC_MESSAGES/messages.mo | Bin 110880 -> 111137 bytes locales/pt_BR/LC_MESSAGES/messages.po | 8 ++++---- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/locales/pt_BR/LC_MESSAGES/messages.mo b/locales/pt_BR/LC_MESSAGES/messages.mo index c2c1b4fad93572ba177fae803b0adcb80a1eba80..18fdf1d874326556b3af8b8657190d05bef570f0 100644 GIT binary patch delta 9512 zcmZA72YgRg8^H1B8i|Tk5hH{kqD71ZK_zC5DpD1S8X-ZfM8pn%BX+A|Qz}X;Mw%c> zX;o>hqGnpus8JnC6{T;D_xId$^zG-pA5XsLIsZG)J?Gr}|F`K^yjEZH@?0#QZ;`NM zJ0j(9MPZTG@=z|TwIY3jL{4A~*21tVBIU6kuEZ%=2m^yfhGPg8W?!ptCwXR75g#1* zg4usE`jMw0`|-#+3ZD1M5@N9eKYfQV@Mn*DG%g#=PV;?dPG^2x}Yb z>(*Yb9+7xkk!Ir^oJzzbF7ipOb*hW9E&VD^q zvrz`!A^|%k0NQ3Lp?BrgdBB#l#hKaPqM|d5Z)fHK) z_4PzP!#y|+C)O8<#eCtke-R4t6nxmx7+gi3+Cbzb@}Pzyx3Etmk*U;oY%DT}{1iSV zkBp>FZ9 z>*fNZJ9|X7QIQtSO4z!K$S>HmD@}{lIXk_Vuc9w@MO}X|>J?P%X8Oi0yhZ*1b^RZ^ zi;TxRsM`(gA>xmdQE%}IWEYaR)xg+AyRPN6V`30MN>pmx4=yTWekVLVBFF6w&g z`5$L zBJ1!5X5l*nj7_-g&&h8i`BqIl0>*`vJhuee+Ro_ zO0wyMr$=%uKL3lWqY))xG{czV%QqAPSutx2_Xv-VH79Uo99O72!n_!rBErc_w+SL^ z$@k+)^17l)Z-@9{I$uZGk%VGiw~prh3`;r@h$Xd?<_P$NfmjW`r6Y>-$p#3A>`%H-wdisZqj_$ju) za(piDa8L-CXGTfNJep3MelZpGaeJDXh;Gd{<8;{qbI&)SUcojji~F!BUcykkje6ip z3(bkQLLF|MP=|Lc7Q!Kz%W=jc-9w^0i_hEz*HN479_og&L}Uva6u{P`yOx^z zyvxkv)d%&2_M`6Sip}#ar{&l#5Ou%R-!)g<2uqT8M(y05!4$YyNkeVwpcUo-wNOta z9JSN5K)s@FSR4mqb)1N0aRZjY{n!{Uqqa=IO8OH34E|otZ%TXKCOurap8%GulkRv3s6$rCr5aUZ{h>6tti zk7M7hvmzKpllQ>9 z3^V+jeB*9z3$FW|t76CF_iziy=Y1j47DM;y4P=Hxz0ybc9CqBtB!k_sIEH@7{D3c` z7cRpT_Lu%8o3ElGV83bd&#*N45iEt*k=regQG4x*1EzCsMeU5cFbR*MFE%}B_R|^j zllMa%cJUa8qc9H#{vLahUpmC;>(m-?nE9QGW?!4m_zCh)&hY0Xu0BHFV7+A8?I!uV z$IOY${KkxudH9(66{sh&ocmK7KSFJROIQv6z+enGVUE+%LxC2TKG* zY3PrcSOO2CA6~GZ-^Hfvpy*jM&ZEw8ugM3Y4!7jh{~v2M?p}C)aut50U5L zEG}#JIYPmUip&dUgB&bMz6T59aa(^LwGZ4tJ>V16dt3OT(cfAXqp7cp#c(!ilfR4F zl6%n`zsCI9eNR!yN5xs|MJ!By74-mjP&a&n&!hJxbC1iQUTFyGdd*Q!xFhQN-BC}p zAL<1rpkpvzkrSvJp1~ZN{sP`1pZ|k-K}o&B z$&l~BEc_Am#1>yQoqG+2vt8M1=H>PE>$JbF5cs2+8beTrU01A(30MXfpf+VD>Iv+& z?zbL8z1O*@EpWxw|7N|9dI68^=gtkYUZESbziv>vyxppte}N zH3{`VkUIUwtu z!=lvRbsYBu@-plFNbV`edzFsIyk3rcMa5BMsLO%^j>O{-26-;#;w;SMtzrr5h4ZRB zn*5tWj{DZznlJtO4!9QeKo5C8E6L{tiaF8;E8tH!2{ZUSo;Te#4%b}V*O7Or=)n_4 z5B$K-k^bbzOLB(f;k1{&mX|N%xR2>-{*L=n8eP_Lhu1jNPCE;konGJ{`s# z0vz`{-Ix%U%_#QWhw@f&qZ#ZY(p>12y|os zCzgd3$V*kCX)zoJU=%)wJ5Wc_UhDU$$NLlgIKGsqOp{?XERT&)hg&!F!9l23I0~!a zTw9-G-GlU7If8luIeg{S^^YQxt6ax^^ntxq9CvgCzu>sfglg!~6<1Km;!1K*n<$po zAwAGg)ERC84#5nZfPU2-$NbcBnMhD{uIJP&AU zdiBC)G$HjHkw%k%7LH70{Z=g0eZz`qV_M=S>IrxDFnj1j zr8nxFKO6&b2I{TJKwWVU7RRqqJI_U|h>x%UQ2?{#= z%3*$nNe$G_7uv^+>s?ru{5R_qE1M2Fd8?Y&U_MYTEH8> zAuWzsT+tPL1LqGmz5mxCX1IPe)Lh^x)QRmrda<6@FvkB&6bdJp@!XcKs%JJ1_0=g8 zxn1%p)+P5(GWWV8YTxLKbE(f7;mARZOm^HKnY>4uiD%*{$Ni#m1oi1zaVB--ZD?MU2mJ``I5P2+-JYzxL?J3&U4(~jGE@et~G4PD^4U$etePvq=EbI;NjIZ}yyv-LDyCx3wY)V#3R^!|rfnp|HJQlJd# zJztF4Y1g4n(VLM@?UC&ihEee)`f_GrOC1?R-g=pt7q(z3`HAJGGj@5`aew0-iM;$s z_Z4P-h+avjWcw}enG^YJm6<2L!XWC;p+1J6raSHzl`^Zf1sH$rC{*WzURVofqYj&$ zm>18XP9zsG9R1%ny}1(>AWueZ$_e-@&coiAvc_@0Lw=9(f-%t-+bA!2}{;1=9JnHyQ!!B%}iF$?kHgO^3Wu%c$f1G=p0=IFCA0-awrJAK3al*=FJ? zf_lIzs1sIQYcp#H>_dGI)IRZPHsfC>prcf1Q$9p}h&Y=~XME0D#OjOs{4b4qfMC?^ z!cgb*#?~m*D~&~6Z!GEwPe)xp4fRBqZ)Uve6|Sd3uPht&1ooh|%t6#%dl7ZRpHQ3l zj;;6EV)}?5>UL$2mKR2+`_LLsnW@746@{Yv=BwN5q7&LX9AC;36Wpr*{mDn&YlJTK z3Hpjuuz6nWLfw!0ArmXh&r#ahF8?wtbmIpGrE9&m(># z+7O!v9jCf58M-6FWQ=7B1BkbYs(khl9$9cAz}KTQLK<<8(1qFRpM`Pk-hHijl^8(Y z1bb-(%P_mH&X+nx>EM30gxLZ^Ng{~$Hs6f^4JUDElx zlGx~GjC?G}in=_Hi%ijd0`<4`6{(B1^~xw)K8m9W9S*vDK5 zLh>i&j<^7IsY!VfK0ChFx&LMO6&yl*PrOguB65h|iMedVv)f%}^S2r0-I!pi+#llPIsoZ}s@u6h6~hmT-gnH{EW~8E;ZE8uKA93&La5T`F1o z;b3ZbA#s0KH=mmSoEb~<2{DccwI8&_2gDc8uKyJ_+)l;Ic7>O4gDvw~<-X2nI+Ai0 z>ML#x(a)|^&-#of6lxOrSx1*1!~|Oo!EQudqM^3`ZDI;>m3WcLH?a-!GT^>5^UQXC z@TrW|i1U1&jj!ReWfgf#!pBy;hk?WlViNToh%!V|Vik3B@HD#j|8)|59VtRQrt;ZR zh&&I`kccN%60Hec%41_9m~sQGihBrM7Lw1zA^5yo!y5)=-v1G8LbtR;RS z?h`wR62u*%zHWrNtfkEB);|mHZ0`TIq7~l}(}@N|4eHkuK6c$G>K5DbBD_f6l;}bE z2fhBhB-2T}h$)0FFA#kx|AFmnoz|D8yi*G-ag=Ld5jQh`dcz>Waf9>N1 z%42Qb&24{HYDGmUykIv7u$H4<*GVQO62*06``H-mOPnD_P~RLE66J|Ra$R1+aH0U^ zM%c^N&$hNL%?A@nx)Vhy|4kI2oJQ24{FFFMG$;S}vi@JmP%UqLTsbFv!MT-Xw`TR& z*(P{cY)n$@h`@dcLlcL@#|-Ni7uY``DKLIma$HhEVq8*8-}oW%$z!+1t)1A|yJnq` z*tk&z=LeP8`snh{5li?s8@&Bmd1pyf&0%acG(I*aHZG8Vi7~NB`?kf6ppX>ve>>B4 LwvS10GMfDt?CE~u delta 9298 zcmY+}2YgRg8^H1B3NfQZ)C!`KsFe_#B*Y$xP3*mE2C@BPQz}%&3{jgPr1q#8yjIQH zt47hP+M{@X&pkKqr|EhT$5_XCj!RKbv>G#EvQxj$F$LYIKkaNk=Xk^McgGiwpKM(s8H<_|dN~$E zy@6tmL70JZWycz*7YcW5?AY9~73vMPbL{CDg*R!LF<4i(7w5b#DprySpkiYQ5l_5< z`SBUf#;hep%CcVqKEsRbe2e;&QX)Q-SCtmIK>28pNKIT^M&v%;!TDNWR%9=BDkm}t z3zQe>hAYsOl}yG8G%Y8}jY}!}Rurj1`7l03sVp)9{;DF*3pc*3EDBtGp;wjIoC32E-xjMZ6R%Fu99_z3z#-MvWkzjV5 zf*mOzt}oIUeH(~Wq<$!-#f{;n&m>3C(R4rlxrd$&X)U(DL0_ED!EJGG6On6d&(q92 z;HzdXk*!peZXxm(AL3)Y-IAuo6Ora!{((6tzd_wUGk2{|Z~(P$%xq0d;XKrLKe>&_ zD4dOYoJU)cyjTeJ6$hg}cq11X?QCoC3MQdDe%nr@2zNXib5q{g-gpjsQGSAY;pQDo zeS6G9IU4msvoI&F$Lx3jeegVH#+T@UE^S{gGFdS{7DnA6%rOGbQErX8Ux`lUiNf$O zb1R3rw8AxUj8^&QYzQEPkr-#TU z^z3Ooh(A+~;_*3`1oh^oFb)UfGu)2d`iLw??{7rD$NhK)oAouLq;Nmef^RXB>q}>D zS9||X%*u{O28j6K1uTQ_QSUrppm{YFa2)%GBHcvxbN9R@$rZ(GqkafR;%DwkJ745b zIxO2q^K>+#JjYwubQrHh$A8dp-Vrt%VQ!%NNS=`L5Ol-KqeQrQxjvdPOS#?{^GcqM z72zS|01vSO17l420%|9$KF+-32-LpN7WEYmLhY2X=*mcDxl^$LeJCG5U%ZQTG5vT> zU@-)73FRIW7}uC?A~#KaGHTyQKUpLMy;1v68}z^)*q8l=U`M<&#q^D^X|(@cc4$3K zq$mb|YYyyz`UFv^<9rOdQyxE^7NR^2(^8&4gN2E5JQk+B^gHGfJcN5N1-;omVWtQj zUJ_!>DEW*&)aRK+)0HPvdA6B=2GL_Y+0lEBdFO$sPf!u_VQu^ZyI>GTpJuMF z9c~vfJwC)N_!nN{I{zTuL(b1-F2LHZIP=bXp`KtE>VXq*3kOWcI+R1_oBGMPi}Fm= z8>+X!oTxi$c?xFYxaFvwdE-L!#C!2e%D7>r#}TP6XE;d%7NPgn%=#hdfgzlW%Q6G=~ zI{uHXGzb2LdcY^7ze(BEX5#o6BdCvEBhrBS8*4>sV9|ASOzejV_yn8cjP<7T-NJ5^ z7bh}5aJ;pFzDBvjMv(_N7i)5T8NG?7XNLp$mh$l=Gu{tw=KWI++#>P|?#6JOk<288 zSFk$AE&WNP3FW(6nZ&T{Hj!HR6hCR1Y4H@6*&#xsh{aA^TUMYe$&E3*%dFRF_wl~i zp!2L3C%%BoC_dWH`^D)8^o7y8QJ=KMLB1Vu4PM4A=!w%0aZX%To-V-SG^j z;lkyPiL|F&@wk~$h(tcVb1{>mpN$%xf%!rOuk(-xT#kZE-*L z#}*jK-RUYf2|Hj2?<)}(<6x|J!K|ixaX$|bc#)w?{j*DE7@qpo+{k0hOTEjT7pHS~ zA=L3+9`#Pcu^K1ng?T8iy~4Yud&K`~nf8IXft-%{ z9sMvf+e@OhKqaTXreiqj12lKGw{q<2*xzx)1IE9eV4_nI>$uQyC29*KIqpDh>iv$# zQ7?4P@si_J$D63idcm_=*VN1B`cuYcl#>{t3T{et7_ z^LeB<(1vO70S@Ma@;LjoNoUCs$}V4b%bvR*vjX*I!=Vh8Fjq)P2KzKj%h$v_cASaY zsr<88_Sfzb)Nj8Js26I)cbN{?jubj!H2#ji;u^N^&t^$o?CojEBHWV0zOG9e@@3hB ziXvZfha51I_n@ESL%D5Tr^n^7?2pmJyp}z@&Z2hO+jt7!A|pvs@>%vUUdaa^bB!dU z_LbQDmi-+uAN4q&0+#(1ToLo?a@LZJKKUTbh}V$UCHK)CFBi0=CpU5n3sSCAh$h9J z*b`$=kNX{U^gMUW@|C%eKjx&qChC091`A*x%*OR)8W|l<3sLWI75d>mr~aPfGki$> zKd3iwudvzwBkCNVlV2NMdH2szM@7pbmi^1B4eEJM;wB#C9%{?{P}CBaUMQZ7&TNOU zFJ8tmSc~@mN$YV34liyjO;`Vg@?+F5oZTfY`xDM5z_dtzJWl;3OvZ#j%kKTnOPN>v z4z-1Em$qComCX4dOBQ3hGM4=b_6|KL2l72u3PUgm`=gHMWta{VQUAcO1zS??RKc=; zVr|C+>T~hOf(f{z5-o$l{8b~0{St!dbC@HxEf7J z{Wbg=BdS|6mII?}Sn`qbD`Y{G7qu+=%jQ&V%l@?LSI4x3H(g$Dcp~ar5{udwmZ1-B zcahO|a~XBVXXuF^Fh6FkXGtL}fsxn{c_>+hiIi{Ex8x|!Xkf`e>YIm~S9v7Dvj4zv z6}4}bX-H?osyL1P8e?a4U2SAKQ*aYY-mpUp)TWMTY7UG+y|Ecc$Ci1Rp7KrxKdmVT zP?yt>&3Qt~X0MeoDH_}-~6(B86_?NX>WToZNpg=0EKNjsdXXVnnUEEkztVQ`f?WQNJ*2S`aMAk(;t~Wib5Kh99xEh)Cg zKImq)zeSxX^LFPI>-aBCW-c~DebW1=@9a71#PSLC0vVVlwe$F*o}e-YU=!4dDF(IA zBw#S^Lw%JWuowpPG%eH`i&GwhF1@q0WOPQ_jVdaTFmuZ0tc!qLy)Ct71H=PR) z_A$LbUtcp^U!k^uTR+p;{Lr2K%A@v`kpAX|Mhq}hdEx-ZKd(V{Q&E-!^Dx%*9XCYn z6Pomi@;h_aSD&88g(ff0&#=T`hA)TXFzXumMgTX31&1fI8ln4>zME z(+K7n%A-ay{$G*VJklJndX#x*FEAZ9kamnE!`Yr`tXT~w;A6@j9M>P;;w9`EV@@18 z&W!s_<1INzeXa?tl6Vzap(S9VB`H{9600JJcc?iuxXB>^WlPjpp@291f{lg@8f@y*JsJ*>C2I4f-(XtcWbo^f-qZ7yttbloznO@uk zb(tKD+LWX53C3ba9QC7R|7N^~y(zC=Zazq|uVB%kd<&;w*OiPCZtw}-qkLqwC1JR3 zjV0B%zWhN(FI;l1d7|#9<9sCQxSxeBIYA=o6S}SENhs&Xtdt`XEeXYTsLS{w%#2B> z=h=fL@EqR4&&YSE+}gnS*KvM+qdDLz>J<3^b>@5R)LWa(gyVsFL0{B&TgI`PV+3}h zz76VPvm15dIf>emZ%}7WNiv-=LlWa(d!>g{;fcEL=R&=JAL@ZYm;|bcAVQG)qIR)Az4;`kBxhs7m}mXhfArk{u*#A{+N!N8JO)HTDO&<~g*geF&eqb$Vc zL<=H6L1(sqJn~&(uVyc)WBM0n(Em%DD9xho1hT5yX@;{8lj{G{HF7#k%M(=zMyXE0 z0rt-&-D{t-Yk3^N#xqV?7pBy7V9tR8Ib5CCswtPFt{~d4FB7^7Xwn%)sMnV^Uh|{~ zq6T$e5*zFq^G|KcUpwVhNY4ZDchtRnMI*>rfYQ{m9Z3#*U+j zcvH0h!)+w_lFkX9k!LxzC*%Lj$?lzF&S>upu4>fgrB*+1H1#5)Df<&0$X_6e6Tc9p zi4laR?rd*G%p`O<&@`L)oA{Qx)O3T)ZGw+8`|Iu^`J)62v9QAEFrYJ1ID(zDK&o!A z|07IiU>)L>hfLEqc}CqOwAx)0`_dLRXX)drL6xAA>UAFN=%|6 z3z3={kts`=Wy((akzCrzuO$B!`F8k(=t%IzVE-iO=InEhIwop6P2u1D1dFfKA|8-u z!Iu^KNkm82a8`#-cbJAl|t z9Mgi6hNot58&QIDOeZEg^|{IGa`Ur3zYeR9&W4U`&{Tq$Oum#|;+Hpu6SJw~bHh$; zF&oj7QXCOUJ|8Z_t{8yhi4Wxa5}NW;E{K(h4dm_ipQahoX(E)kM64mA2u+O%KDh1w z1hFglXFb7(n4JbW24OhSg-FMiZ!jaVmgr5SCO-V^)SZ9r_us_X(vuCH$uA{Z5qpUF zL^0ww;>UlTB!PTQ!i)NMM4^9e3!uD$&{TuiN>pU~Tdi?5bFtR{jvPQP33YlV}FQ`grypC9(8K8v=0W+D$2 zZbTjO=ZPWY>tjw#P4CI9cFKP`l?y3PBnDH?\n" "Language-Team: Portuguese (Brazil) \n" @@ -17,7 +17,7 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=n > 1;\n" -"X-Generator: Weblate 4.8-dev\n" +"X-Generator: Weblate 4.8.1-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -3156,11 +3156,11 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:545 msgid "Choosing a versioning scheme" -msgstr "" +msgstr "Escolhendo um esquema de versionamento" #: ../source/guides/distributing-packages-using-setuptools.rst:548 msgid "Standards compliance for interoperability" -msgstr "" +msgstr "Conformidade de padrões para interoperabilidade" #: ../source/guides/distributing-packages-using-setuptools.rst:550 msgid "" From a28991dc065924dd2a1a6bc9f2df3836e878c12b Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Sun, 5 Sep 2021 16:34:36 +0200 Subject: [PATCH 0133/1072] Translated using Weblate (Chinese (Simplified)) Currently translated at 26.0% (592 of 2271 strings) Co-authored-by: meowmeowmeowcat Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hans/ Translation: pypa/packaging.python.org --- locales/zh_Hans/LC_MESSAGES/messages.mo | Bin 100727 -> 105911 bytes locales/zh_Hans/LC_MESSAGES/messages.po | 55 ++++++++++++++---------- 2 files changed, 33 insertions(+), 22 deletions(-) diff --git a/locales/zh_Hans/LC_MESSAGES/messages.mo b/locales/zh_Hans/LC_MESSAGES/messages.mo index a3d93c5db85ccaf3e865a8a6aa196d95de131bc1..d7e13ccef4963aba6dfdf8a7544138359ed0449b 100644 GIT binary patch delta 16923 zcma)?cYIVu*MR2|2%SI>iPTGx8jxN>2Wd(ZsTSBJS;#^fn}nvap-DoA(0dg`AV827 zit=I?RIDf}Vs?|Dg1)aEmG3!sCNaL>_s4gCzr%CR%-ktw&YU}0{bg0?iJVaX7vUw> zD4u>Ll&S>>g)3D%M5(76N~u!cw^Hf>_yg$O&@4jcow!0B)ztky=U3h-%I9%ex4 zZw;&lk3xCxbyywd!OBYc)m@a*6jW}jR3wamV)r#145h=7upD%o@;Jj3$b8k)rasMZ zvEf?79fk)CPdM}|b-@%|GW^8wYr|VmCiI)3)lR80*kujFp-iBrVO_%phK-?2yt!cq z!(Olw;j;TE_O=D>EAQiI#;j^?rt-(xR@qv7mMYzyr^>a5h4@KKZ~-eyHX3_upUaqz>nacuuD&+w!zN5(CP3h zyalWEQEDFLCHpEh89N;g#r{t}rS8H${fQ6Z0HwN8zZnk0zB-VJ!DbIB)e%1Y5c^LM zsCg6&hO6O4cmvLcdmp9~*l3Vaxo|SvPKQHjd=vZoA-coQ7`-a?AMiz3nbET0tFR}W z^@!fG9C!=+A}j~9hx?WK3FX{yrJjPv9#x95RjU!Y!>3?P?B#|pz|XN?gH_<3kxJEo zC!lQI6(}nYK#7^|qjd20gIBSK!%!GGTGzMrqsWV0U<4duI0?G2)1U;~SEl?Xybn8s zQDorSuo~4^tUlePuPHhA+RCz!F%93_%S>H zYs2}E=@spS(!n8PpMh7fUx)JECT1gBau~{%UWBD!#uK`JIcz59e>X}974N_V_&%%- zdq1hvH24^t2j3H$y&pMFd*to$dJjK@vcl_7V(BiN3M;#`tLH-5>kPxyQ1Z++*pKnm z+bESNsOr|NZ`c~{rMxH1g8A?~Tt7j3U`(`9I7P+4WOxo{z&0_&13UwXSC!&X>RI?Q zjD-V8mj&<$OlN$xX_D@+A+<7*RxkzjfcL{=ur2%)mVuSL#D#^I;2!Mtll4lwPf=\Scripts\activate For more information, see the :doc:`venv ` docs or -the `virtualenv `_ docs. +the :doc:`virtualenv ` docs. The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current From 42f8d15cae0a679d4a09fa3463184a39bfe39bf9 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 18 Sep 2021 16:11:40 +0800 Subject: [PATCH 0159/1072] Stick with the site root --- source/guides/hosting-your-own-index.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/hosting-your-own-index.rst b/source/guides/hosting-your-own-index.rst index ac3c02e16..a4ff2b35c 100644 --- a/source/guides/hosting-your-own-index.rst +++ b/source/guides/hosting-your-own-index.rst @@ -59,4 +59,4 @@ instruct users to add the URL to their installer's configuration. :pep:`503`. -.. _Twisted: https://twistedmatrix.com/trac/ +.. _Twisted: https://twistedmatrix.com/ From d48a533f49f2e1a1b559d13370acb9cbfd7bc24d Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 18 Sep 2021 16:13:08 +0800 Subject: [PATCH 0160/1072] Use Shortened link --- source/tutorials/installing-packages.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst index 3cb11cbab..c68ea6c18 100644 --- a/source/tutorials/installing-packages.rst +++ b/source/tutorials/installing-packages.rst @@ -461,7 +461,7 @@ directory to your :envvar:`PATH`: ``PATH`` changes to take effect. .. _user base: https://docs.python.org/3/library/site.html#site.USER_BASE -.. _modifying ~/.profile: https://stackoverflow.com/questions/14637979/how-to-permanently-set-path-on-linux-unix/14638025#14638025 +.. _modifying ~/.profile: https://stackoverflow.com/a/14638025 .. _Control Panel: https://docs.microsoft.com/en-us/windows/win32/shell/user-environment-variables?redirectedfrom=MSDN Requirements files From f66e4026bd53c9893e22808fb124b10b51a5ff84 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 18 Sep 2021 16:25:35 +0800 Subject: [PATCH 0161/1072] Use `:rfc:` role --- source/overview.rst | 2 +- source/specifications/core-metadata.rst | 9 +++------ source/specifications/declaring-project-metadata.rst | 3 +-- source/specifications/direct-url.rst | 5 ++--- 4 files changed, 7 insertions(+), 12 deletions(-) diff --git a/source/overview.rst b/source/overview.rst index e152c09e3..476e31298 100644 --- a/source/overview.rst +++ b/source/overview.rst @@ -231,7 +231,7 @@ guides: * `Kivy `_ * `Beeware `_ * `Brython `_ -* :py:module:`Flexx ` +* `Flexx `_ If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst index cb22fcf92..9305c7ea6 100644 --- a/source/specifications/core-metadata.rst +++ b/source/specifications/core-metadata.rst @@ -240,8 +240,7 @@ Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown -`_ (`RFC 7763 -`_) as many code hosting sites render +`_ (:rfc:`7763`) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when @@ -275,10 +274,8 @@ Other parameters might be specific to the chosen subtype. For example, for the specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized: -- ``GFM`` for `Github-flavored Markdown - `_ -- ``CommonMark`` for `CommonMark - `_ +- ``GFM`` for :rfc:`Github-flavored Markdown <7764#section-3.2>` +- ``CommonMark`` for :rfc:`CommonMark ` Example:: diff --git a/source/specifications/declaring-project-metadata.rst b/source/specifications/declaring-project-metadata.rst index 101cbd526..ccd058ad1 100644 --- a/source/specifications/declaring-project-metadata.rst +++ b/source/specifications/declaring-project-metadata.rst @@ -157,7 +157,7 @@ meaning is open to interpretation. These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, -in `RFC 822`_) and not contain commas. The ``email`` value MUST be a +in :rfc:`822`) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional. Using the data to fill in :ref:`core metadata ` is as @@ -303,5 +303,4 @@ provided via tooling later on. value, is acceptable). -.. _RFC 822: https://datatracker.ietf.org/doc/html/rfc822 .. _TOML: https://toml.io diff --git a/source/specifications/direct-url.rst b/source/specifications/direct-url.rst index 8dd1acbe1..9b8180c47 100644 --- a/source/specifications/direct-url.rst +++ b/source/specifications/direct-url.rst @@ -23,8 +23,7 @@ specifying a direct URL reference (including a VCS URL). This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier). -This JSON file MUST be a dictionary, compliant with `RFC 8259 -`_ and UTF-8 encoded. +This JSON file MUST be a dictionary, compliant with :rfc:`8259` and UTF-8 encoded. If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be @@ -82,7 +81,7 @@ present as a dictionary with the following key: in editable mode, ``false`` otherwise. If absent, default to ``false``. When ``url`` refers to a local directory, it MUST have the ``file`` sheme and -be compliant with `RFC 8089 `_. In +be compliant with :rfc:`8089`. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute. From 8d3e77f103bf9da29add3634f740439c34c1c235 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 18 Sep 2021 16:32:53 +0800 Subject: [PATCH 0162/1072] Fix a typo --- source/specifications/core-metadata.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst index 9305c7ea6..94dd4a7ae 100644 --- a/source/specifications/core-metadata.rst +++ b/source/specifications/core-metadata.rst @@ -275,7 +275,7 @@ specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized: - ``GFM`` for :rfc:`Github-flavored Markdown <7764#section-3.2>` -- ``CommonMark`` for :rfc:`CommonMark ` +- ``CommonMark`` for :rfc:`CommonMark <7764#section-3.5>` Example:: From 6d94b2f06f46e55b3816270fcf6ca10b0fdb59ae Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 18 Sep 2021 16:45:11 +0800 Subject: [PATCH 0163/1072] Make the list of intersphinx mapping alphabetically --- source/conf.py | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/source/conf.py b/source/conf.py index f906c5e07..1a3ab3592 100644 --- a/source/conf.py +++ b/source/conf.py @@ -398,34 +398,33 @@ # Example configuration for intersphinx: refer to the Python standard library. intersphinx_mapping = { - 'build': ('https://pypa-build.readthedocs.io/en/stable/', None), 'boltons': ('https://boltons.readthedocs.io/en/latest/', None), + 'build': ('https://pypa-build.readthedocs.io/en/stable/', None), 'cffi': ('https://cffi.readthedocs.io/en/latest/', None), 'conda': ('https://conda.io/en/latest/', None), - 'distlib': ('https://distlib.readthedocs.io/en/latest/', None), 'devpi': ('https://devpi.net/docs/devpi/devpi/latest/+doc', None), 'dh-virtualenv': ('https://dh-virtualenv.readthedocs.io/en/latest/', None), + 'distlib': ('https://distlib.readthedocs.io/en/latest/', None), 'flexx': ('https://flexx.readthedocs.io/en/latest/', None), + 'nox': ('https://nox.thea.codes/en/latest/', None), 'openstack': ('https://docs.openstack.org/glance/latest/', None), 'packaging': ('https://packaging.pypa.io/en/latest/', None), 'packaging.python.org': ('https://packaging.python.org/', None), + 'pip': ('https://pip.pypa.io/en/latest/', None), + 'pipenv': ('https://pipenv.pypa.io/en/latest/', None), 'piwheels': ('https://piwheels.readthedocs.io/en/latest/', None), + 'pybind11': ('https://pybind11.readthedocs.io/en/stable/', None), + 'pynsist': ('https://pynsist.readthedocs.io/en/latest/', None), + 'pypa': ('https://www.pypa.io/en/latest/', None), 'python': ('https://docs.python.org/3', None), + 'python-guide': ('https://docs.python-guide.org', None), 'python2': ('https://docs.python.org/2', None), - 'pip': ('https://pip.pypa.io/en/latest/', None), - 'pipenv': ('https://pipenv.pypa.io/en/latest/', None), 'scipy': ('https://www.scipy.org', None), 'setuptools': ('https://setuptools.readthedocs.io/en/latest/', None), - 'tox': ('https://tox.readthedocs.io/en/latest/', None), - 'twine': ('https://twine.readthedocs.io/en/stable/', None), - 'pypa': ('https://www.pypa.io/en/latest/', None), - 'nox': ('https://nox.thea.codes/en/latest/', None), - 'pynsist': ('https://pynsist.readthedocs.io/en/latest/', None), - 'scipy': ('https://www.scipy.org', None), 'spack': ('https://spack.readthedocs.io/en/latest/', None), 'sphinx': ('https://www.sphinx-doc.org/en/master', None), - 'pybind11': ('https://pybind11.readthedocs.io/en/stable/', None), - 'python-guide': ('https://docs.python-guide.org', None), + 'tox': ('https://tox.readthedocs.io/en/latest/', None), + 'twine': ('https://twine.readthedocs.io/en/stable/', None), 'virtualenv': ('https://virtualenv.pypa.io/en/stable/', None), } From 98576211c88c2955085e72a00a86396ae3181f73 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 18 Sep 2021 16:53:52 +0800 Subject: [PATCH 0164/1072] Fix a broken link --- source/specifications/core-metadata.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst index 94dd4a7ae..5a4d9b354 100644 --- a/source/specifications/core-metadata.rst +++ b/source/specifications/core-metadata.rst @@ -730,4 +730,4 @@ Examples:: .. _`Python Package Index`: https://pypi.org/ .. [2] RFC 822 Long Header Fields: - https://www.freesoft.org/CIE/RFC/822/7.htm + :rfc:`822#section-3.1.1` From 1edc00748b49161ad7d03e469f0b66573250be8c Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 18 Sep 2021 16:59:56 +0800 Subject: [PATCH 0165/1072] Use intersphinx reference --- source/guides/installing-scientific-packages.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst index 64abf3e85..cd67eecc2 100644 --- a/source/guides/installing-scientific-packages.rst +++ b/source/guides/installing-scientific-packages.rst @@ -14,8 +14,8 @@ kinds of hardware, or to interoperate with different pieces of external software. In particular, `NumPy `__, which provides the basis -for most of the software in the `scientific Python stack -`__ can be configured +for most of the software in the :doc:`scientific Python stack +` can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs. From 20491e18a0be3afa9f66c8cfb2bbc41155490377 Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sat, 18 Sep 2021 17:02:36 +0800 Subject: [PATCH 0166/1072] Remove an unnesscary trailing slash --- source/guides/supporting-windows-using-appveyor.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/supporting-windows-using-appveyor.rst b/source/guides/supporting-windows-using-appveyor.rst index fe19d146c..3a2d944a7 100644 --- a/source/guides/supporting-windows-using-appveyor.rst +++ b/source/guides/supporting-windows-using-appveyor.rst @@ -237,7 +237,7 @@ For reference, the SDK setup support script is listed here: :language: bat :linenos: -.. _Appveyor: https://www.appveyor.com// +.. _Appveyor: https://www.appveyor.com/ .. _Travis: https://travis-ci.org/ .. _Github: https://github.com .. _Bitbucket: https://bitbucket.org/ From 1ebe9db2a417958c07cf78b77b5bbbb0967db4af Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 18 Sep 2021 17:10:05 +0800 Subject: [PATCH 0167/1072] Fix a broken link --- source/guides/installing-using-linux-tools.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/installing-using-linux-tools.rst b/source/guides/installing-using-linux-tools.rst index 790a405e6..c91ce7924 100644 --- a/source/guides/installing-using-linux-tools.rst +++ b/source/guides/installing-using-linux-tools.rst @@ -54,7 +54,7 @@ To install pip and wheel for the system Python, there are two options: 1. Enable the `EPEL repository `_ using `these instructions - `__. + `__. On EPEL 7, you can install pip and wheel like so: .. code-block:: bash From b046f7f9feef6cb6670a40a6e181289b8ff74306 Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sun, 19 Sep 2021 11:07:32 +0800 Subject: [PATCH 0168/1072] Remove a blank line Co-authored-by: Sviatoslav Sydorenko --- ...istribution-releases-using-github-actions-ci-cd-workflows.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index 423c59e44..55e251826 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -145,4 +145,3 @@ sure that your release pipeline remains healthy! https://github.com/marketplace/actions/pypi-publish .. _Secrets: https://docs.github.com/en/actions/reference/encrypted-secrets - From 58fd7bb55cdf23271bc553e8ccc4502458bdeedb Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sun, 19 Sep 2021 11:10:39 +0800 Subject: [PATCH 0169/1072] Don't specify the language in URL Co-authored-by: Sviatoslav Sydorenko --- source/tutorials/creating-documentation.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/tutorials/creating-documentation.rst b/source/tutorials/creating-documentation.rst index 3dd354cfa..de47c7013 100644 --- a/source/tutorials/creating-documentation.rst +++ b/source/tutorials/creating-documentation.rst @@ -7,7 +7,7 @@ Creating Documentation This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_. -.. _Sphinx: https://www.sphinx-doc.org/en/master/ +.. _Sphinx: https://www.sphinx-doc.org .. _Read The Docs: https://readthedocs.org/ Installing Sphinx From f49cf510a730ea0f5e9bccd5ce5f634cd0ac998a Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sun, 19 Sep 2021 11:18:04 +0800 Subject: [PATCH 0170/1072] Don't specify the language --- source/key_projects.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/key_projects.rst b/source/key_projects.rst index 24f9465fd..5ff9f0175 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -48,7 +48,7 @@ build packages, as well as a Python API. cibuildwheel ============ -`Docs `__ | +`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | @@ -118,7 +118,7 @@ on error. pip === -`Docs `__ | +`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ From c458033dd41e9e8767eb1baa826f2b0cc6c1eec1 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sun, 19 Sep 2021 11:26:12 +0800 Subject: [PATCH 0171/1072] Use extlinks for links of Github issue --- source/guides/packaging-binary-extensions.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/packaging-binary-extensions.rst b/source/guides/packaging-binary-extensions.rst index 852c044be..6f9088333 100644 --- a/source/guides/packaging-binary-extensions.rst +++ b/source/guides/packaging-binary-extensions.rst @@ -304,7 +304,7 @@ Publishing binary extensions ============================ For interim guidance on this topic, see the discussion in -`this issue `_. +:issue:`this issue <284>`. :: From 5b0e753b4c8ec40c113a4064fc90716939d59a68 Mon Sep 17 00:00:00 2001 From: Eric Date: Sat, 2 Oct 2021 05:36:17 +0200 Subject: [PATCH 0172/1072] Translated using Weblate (Chinese (Simplified)) Currently translated at 26.3% (598 of 2271 strings) Co-authored-by: Eric Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hans/ Translation: pypa/packaging.python.org --- locales/zh_Hans/LC_MESSAGES/messages.po | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po index 70af2f8f0..86eacd7f1 100644 --- a/locales/zh_Hans/LC_MESSAGES/messages.po +++ b/locales/zh_Hans/LC_MESSAGES/messages.po @@ -12,8 +12,8 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-09-13 10:46+0000\n" -"Last-Translator: Zuorong Zhang \n" +"PO-Revision-Date: 2021-10-02 03:36+0000\n" +"Last-Translator: Eric \n" "Language-Team: Chinese (Simplified) \n" "Language: zh_Hans\n" @@ -1509,7 +1509,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:58 msgid "Navigate to the `BigQuery web UI`_." -msgstr "导航到 `BigQuery 网页用户界面`_。" +msgstr "导航到 `BigQuery web UI`_。" #: ../source/guides/analyzing-pypi-package-downloads.rst:59 msgid "Create a new project." From 9ad33061a2daaafb604c7b977993cb2a963e300c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E8=B0=AD=E4=B9=9D=E9=BC=8E?= <109224573@qq.com> Date: Sun, 10 Oct 2021 17:58:02 +0800 Subject: [PATCH 0173/1072] remove bbFreeze link (#996) --- source/overview.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/source/overview.rst b/source/overview.rst index eaa7303b5..63d194831 100644 --- a/source/overview.rst +++ b/source/overview.rst @@ -318,7 +318,6 @@ A selection of Python freezers: * `constructor `_ - For command-line installers * `py2exe `_ - Windows only * `py2app `_ - Mac only -* `bbFreeze `_ - Windows, Linux, Python 2 only * `osnap `_ - Windows and Mac * `pynsist `_ - Windows only From 2eef2b0c295936832736df089e394b8217ec4422 Mon Sep 17 00:00:00 2001 From: Frost Ming Date: Mon, 11 Oct 2021 01:44:55 +0800 Subject: [PATCH 0174/1072] Add pdm to non-PyPA project list (#987) * Add pdm to key_projects * Update source/key_projects.rst Co-authored-by: Brian Rutledge Co-authored-by: Brian Rutledge Co-authored-by: Brian Rutledge --- source/key_projects.rst | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/source/key_projects.rst b/source/key_projects.rst index 5ff9f0175..4200743fb 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -464,6 +464,20 @@ multibuild Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`. +.. _pdm: + +pdm +=== + +`Docs `__ | +`GitHub `__ | +`PyPI `__ + +PDM is a modern Python package manager with :pep:`582` support. It installs and +manages packages in a similar way to ``npm`` that doesn't need to create a +:term:`virtual environment` at all. It also uses :term:`pyproject.toml` to store +project metadata as defined in :pep:`621`. + .. _pex: pex From 938e637842a34c741f0d691e2adddbe159c8cabc Mon Sep 17 00:00:00 2001 From: Anderson Bravalheri Date: Sun, 10 Oct 2021 18:51:56 +0100 Subject: [PATCH 0175/1072] Add PyScaffold to the list of key projects (#986) * Add PyScaffold to the list of key projects * Update source/key_projects.rst Adopt suggestions from code review. Co-authored-by: Brian Rutledge Co-authored-by: Brian Rutledge --- source/key_projects.rst | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/source/key_projects.rst b/source/key_projects.rst index 4200743fb..39b1ab7ce 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -557,6 +557,24 @@ upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI. +.. _pyscaffold: + +PyScaffold +========== + +`Docs `__ | +`GitHub `__ | +`PyPI `__ + +PyScaffold is a project generator for bootstrapping Python packages, +ready to be shared on PyPI and installable via :ref:`pip`. +It relies on a set of sane default configurations for established tools +(such as :ref:`setuptools`, pytest_ and Sphinx_) to provide a productive +environment so developers can start coding right away. +PyScaffold can also be used with existing projects to make packaging +easier. + + .. _scikit-build: scikit-build @@ -679,3 +697,5 @@ information, see the section on :ref:`Creating and using Virtual Environments`. ---- .. _distribute: https://pypi.org/project/distribute +.. _Sphinx: https://www.sphinx-doc.org/en/master/ +.. _pytest: https://docs.pytest.org/en/stable/ From 865cc37ea62137df61ae65aa9732bce523a6edb2 Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Mon, 11 Oct 2021 17:47:56 +0800 Subject: [PATCH 0176/1072] Don't use intersphinx reference in the README.rst (#1000) --- README.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.rst b/README.rst index 93bfd771e..eab80f1a8 100644 --- a/README.rst +++ b/README.rst @@ -6,8 +6,8 @@ http://packaging.python.org The "Python Packaging User Guide" (PyPUG) aims to be the authoritative resource on how to package and install distributions in Python using current tools. -To follow the development of Python packaging, see the :doc:`Python -Packaging Authority `. +To follow the development of Python packaging, see the `Python +Packaging Authority `_. Code of Conduct --------------- From 635b6fc93ec2d34e133415c8a6c37eb7a4865518 Mon Sep 17 00:00:00 2001 From: "John T. Wodder II" Date: Wed, 27 Oct 2021 09:04:13 -0400 Subject: [PATCH 0177/1072] Clarify how MANIFEST.in's "include" and "exclude" work --- source/guides/using-manifest-in.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/source/guides/using-manifest-in.rst b/source/guides/using-manifest-in.rst index c8bfa8802..e23c0cbfd 100644 --- a/source/guides/using-manifest-in.rst +++ b/source/guides/using-manifest-in.rst @@ -67,7 +67,9 @@ are: Command Description ========================================================= ================================================================================================== :samp:`include {pat1} {pat2} ...` Add all files matching any of the listed patterns + (Files must be given as paths relative to the root of the project) :samp:`exclude {pat1} {pat2} ...` Remove all files matching any of the listed patterns + (Files must be given as paths relative to the root of the project) :samp:`recursive-include {dir-pattern} {pat1} {pat2} ...` Add all files under directories matching ``dir-pattern`` that match any of the listed patterns :samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...` Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns :samp:`global-include {pat1} {pat2} ...` Add all files anywhere in the source tree matching any of the listed patterns From 713300a5c5359263b8de969ea2bda3461a1ffb2a Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Fri, 29 Oct 2021 11:46:28 +0800 Subject: [PATCH 0178/1072] Use Wayback Machine for pipenv docs --- source/conf.py | 2 +- source/key_projects.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/source/conf.py b/source/conf.py index 1a3ab3592..55a066b7e 100644 --- a/source/conf.py +++ b/source/conf.py @@ -411,7 +411,7 @@ 'packaging': ('https://packaging.pypa.io/en/latest/', None), 'packaging.python.org': ('https://packaging.python.org/', None), 'pip': ('https://pip.pypa.io/en/latest/', None), - 'pipenv': ('https://pipenv.pypa.io/en/latest/', None), + # 'pipenv': ('https://pipenv.pypa.io/en/latest/', None), 'piwheels': ('https://piwheels.readthedocs.io/en/latest/', None), 'pybind11': ('https://pybind11.readthedocs.io/en/stable/', None), 'pynsist': ('https://pynsist.readthedocs.io/en/latest/', None), diff --git a/source/key_projects.rst b/source/key_projects.rst index 39b1ab7ce..3654cbca3 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -136,7 +136,7 @@ command-line interface (CLI). Pipenv ====== -:doc:`Docs ` | +`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__ From 726544cde330cbd7740905deff52992780726e1e Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Fri, 12 Nov 2021 23:43:08 +0800 Subject: [PATCH 0179/1072] Update links(pipenv, scipy) --- source/conf.py | 3 +-- source/guides/installing-scientific-packages.rst | 14 +++++++------- source/key_projects.rst | 2 +- 3 files changed, 9 insertions(+), 10 deletions(-) diff --git a/source/conf.py b/source/conf.py index 55a066b7e..67cdf5f12 100644 --- a/source/conf.py +++ b/source/conf.py @@ -411,7 +411,7 @@ 'packaging': ('https://packaging.pypa.io/en/latest/', None), 'packaging.python.org': ('https://packaging.python.org/', None), 'pip': ('https://pip.pypa.io/en/latest/', None), - # 'pipenv': ('https://pipenv.pypa.io/en/latest/', None), + 'pipenv': ('https://pipenv.pypa.io/en/latest/', None), 'piwheels': ('https://piwheels.readthedocs.io/en/latest/', None), 'pybind11': ('https://pybind11.readthedocs.io/en/stable/', None), 'pynsist': ('https://pynsist.readthedocs.io/en/latest/', None), @@ -419,7 +419,6 @@ 'python': ('https://docs.python.org/3', None), 'python-guide': ('https://docs.python-guide.org', None), 'python2': ('https://docs.python.org/2', None), - 'scipy': ('https://www.scipy.org', None), 'setuptools': ('https://setuptools.readthedocs.io/en/latest/', None), 'spack': ('https://spack.readthedocs.io/en/latest/', None), 'sphinx': ('https://www.sphinx-doc.org/en/master', None), diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst index cd67eecc2..d9244c938 100644 --- a/source/guides/installing-scientific-packages.rst +++ b/source/guides/installing-scientific-packages.rst @@ -14,8 +14,8 @@ kinds of hardware, or to interoperate with different pieces of external software. In particular, `NumPy `__, which provides the basis -for most of the software in the :doc:`scientific Python stack -` can be configured +for most of the software in the `scientific Python stack +`__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs. @@ -90,16 +90,16 @@ macOS installers that are compatible with the macOS CPython binaries published on python.org. macOS users also have access to Linux distribution style package managers -such as ``MacPorts``. The SciPy site has more details on using MacPorts to -install the :ref:`scientific Python stack -` +such as ``Homebrew``. The SciPy site has more details on using Homebrew to +install the `scientific Python stack +`__. SciPy distributions ------------------- -The SciPy site lists :doc:`several distributions -` that provide the full SciPy stack to +The SciPy site lists `several distributions +`__ that provide the full SciPy stack to end users in an easy to use and update format. Some of these distributions may not be compatible with the standard ``pip`` diff --git a/source/key_projects.rst b/source/key_projects.rst index 3654cbca3..39b1ab7ce 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -136,7 +136,7 @@ command-line interface (CLI). Pipenv ====== -`Docs `__ | +:doc:`Docs ` | `Source `__ | `Issues `__ | `PyPI `__ From c22a660cda7065dc027fdf44025e7ea5b791e45b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Juan=20Luis=20Cano=20Rodr=C3=ADguez?= Date: Mon, 22 Nov 2021 10:57:58 +0100 Subject: [PATCH 0180/1072] Fix broken links --- source/guides/installing-scientific-packages.rst | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst index cd67eecc2..ad7b62378 100644 --- a/source/guides/installing-scientific-packages.rst +++ b/source/guides/installing-scientific-packages.rst @@ -14,8 +14,8 @@ kinds of hardware, or to interoperate with different pieces of external software. In particular, `NumPy `__, which provides the basis -for most of the software in the :doc:`scientific Python stack -` can be configured +for most of the software in the `scientific Python stack +`_ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs. @@ -98,8 +98,9 @@ install the :ref:`scientific Python stack SciPy distributions ------------------- -The SciPy site lists :doc:`several distributions -` that provide the full SciPy stack to +The SciPy site lists `several distributions +`_ +that provide the full SciPy stack to end users in an easy to use and update format. Some of these distributions may not be compatible with the standard ``pip`` From 7f7f4c2473c08646f3757c5b15974faa396ae077 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Juan=20Luis=20Cano=20Rodr=C3=ADguez?= Date: Mon, 22 Nov 2021 10:58:45 +0100 Subject: [PATCH 0181/1072] SciPy promotes Homebrew now See https://github.com/scipy/scipy.org/pull/413#discussion_r727927388. --- source/guides/installing-scientific-packages.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst index ad7b62378..2afb45b54 100644 --- a/source/guides/installing-scientific-packages.rst +++ b/source/guides/installing-scientific-packages.rst @@ -90,9 +90,8 @@ macOS installers that are compatible with the macOS CPython binaries published on python.org. macOS users also have access to Linux distribution style package managers -such as ``MacPorts``. The SciPy site has more details on using MacPorts to -install the :ref:`scientific Python stack -` +such as ``Homebrew``. The SciPy site has more details on using Homebrew to +`install SciPy on macOS `_. SciPy distributions From f28877bbf96e16289f0ff13920243dd636fb416f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Juan=20Luis=20Cano=20Rodr=C3=ADguez?= Date: Mon, 22 Nov 2021 10:58:59 +0100 Subject: [PATCH 0182/1072] Remove broken and unused intersphinx link --- source/conf.py | 1 - 1 file changed, 1 deletion(-) diff --git a/source/conf.py b/source/conf.py index 55a066b7e..9a58922f3 100644 --- a/source/conf.py +++ b/source/conf.py @@ -419,7 +419,6 @@ 'python': ('https://docs.python.org/3', None), 'python-guide': ('https://docs.python-guide.org', None), 'python2': ('https://docs.python.org/2', None), - 'scipy': ('https://www.scipy.org', None), 'setuptools': ('https://setuptools.readthedocs.io/en/latest/', None), 'spack': ('https://spack.readthedocs.io/en/latest/', None), 'sphinx': ('https://www.sphinx-doc.org/en/master', None), From 19356dcf06d0b4a99409ff369660852074e8e830 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Juan=20Luis=20Cano=20Rodr=C3=ADguez?= Date: Mon, 22 Nov 2021 11:02:25 +0100 Subject: [PATCH 0183/1072] Fix HTML output directory in contributor documentation --- source/contribute.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/contribute.rst b/source/contribute.rst index 155945d23..2e609f553 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -142,7 +142,7 @@ To build the guide, run the following bash command in the source folder: nox -s build After the process has completed you can find the HTML output in the -``./build/html`` directory. You can open the ``index.html`` file to view the +``./build`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server. From db7007d46341696ca1fd972048ec580723dc805d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Juan=20Luis=20Cano=20Rodr=C3=ADguez?= Date: Mon, 22 Nov 2021 15:46:54 +0100 Subject: [PATCH 0184/1072] Revert "Fix HTML output directory in contributor documentation" This reverts commit 19356dcf06d0b4a99409ff369660852074e8e830. --- source/contribute.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/contribute.rst b/source/contribute.rst index 2e609f553..155945d23 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -142,7 +142,7 @@ To build the guide, run the following bash command in the source folder: nox -s build After the process has completed you can find the HTML output in the -``./build`` directory. You can open the ``index.html`` file to view the +``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server. From 13363ce3aa2f0a2ee9c75709eda89e6867c0e3c0 Mon Sep 17 00:00:00 2001 From: Diego Ramirez Date: Mon, 22 Nov 2021 09:06:10 -0600 Subject: [PATCH 0185/1072] Remove the sample project MANIFEST.in reference If pypa/sampleproject#155 gets merged, the link may get broken, and also may cause a confussion. --- source/guides/distributing-packages-using-setuptools.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index 1253fcb93..c7b5d9d7d 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -112,9 +112,10 @@ are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see ":ref:`Using MANIFEST.in`". -For an example, see the `MANIFEST.in -`_ from the `PyPA -sample project `_. +However, you may not have to use a :file:`MANIFEST.in`. For an example, the `PyPA +sample project `_ has removed its manifest +file, since all the necessary files have been included by :ref:`setuptools` 43.0.0 +and newer. .. note:: :file:`MANIFEST.in` does not affect binary distributions such as wheels. From 19df32df375179d92efde18d9b3813b346857079 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Mon, 22 Nov 2021 18:19:39 +0100 Subject: [PATCH 0186/1072] Fix the scipy mac install section anchor in the link --- source/guides/installing-scientific-packages.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst index 2afb45b54..a5feb4ad5 100644 --- a/source/guides/installing-scientific-packages.rst +++ b/source/guides/installing-scientific-packages.rst @@ -91,7 +91,7 @@ published on python.org. macOS users also have access to Linux distribution style package managers such as ``Homebrew``. The SciPy site has more details on using Homebrew to -`install SciPy on macOS `_. +`install SciPy on macOS `_. SciPy distributions From c8e12dfe9fb35919e9b2c58bac38ddc47a95d627 Mon Sep 17 00:00:00 2001 From: Vita Markova Date: Tue, 23 Nov 2021 15:41:08 +0100 Subject: [PATCH 0187/1072] Translated using Weblate (Russian) Currently translated at 21.9% (498 of 2271 strings) Co-authored-by: Vita Markova Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/ru/ Translation: pypa/packaging.python.org --- locales/ru/LC_MESSAGES/messages.po | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/locales/ru/LC_MESSAGES/messages.po b/locales/ru/LC_MESSAGES/messages.po index 763e20810..4a2c2835a 100644 --- a/locales/ru/LC_MESSAGES/messages.po +++ b/locales/ru/LC_MESSAGES/messages.po @@ -2,13 +2,14 @@ # Copyright (C) 2013–2020, PyPA # This file is distributed under the same license as the Python Packaging User Guide package. # Mingun , 2021. +# Vita Markova , 2021. msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-08-30 17:33+0000\n" -"Last-Translator: Mingun \n" +"PO-Revision-Date: 2021-10-09 10:22+0000\n" +"Last-Translator: Vita Markova \n" "Language-Team: Russian \n" "Language: ru\n" @@ -17,7 +18,7 @@ msgstr "" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && n" "%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n" -"X-Generator: Weblate 4.8.1-dev\n" +"X-Generator: Weblate 4.9-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -60,6 +61,9 @@ msgstr "Типы документации" #: ../source/contribute.rst:33 msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." msgstr "" +"Проект состоит из четырёх разных типов документации с определённым " +"назначением. Пожалуйста, выбирайте подходящий тип документации, когда " +"предлагаете изменения." #: ../source/contribute.rst:38 #: ../source/tutorials/index.rst:2 From 361ec3e9b2d593db5466040bd23c602a52bfbc97 Mon Sep 17 00:00:00 2001 From: YangYulin Date: Tue, 23 Nov 2021 15:41:08 +0100 Subject: [PATCH 0188/1072] Translated using Weblate (Chinese (Simplified)) Currently translated at 26.4% (600 of 2271 strings) Co-authored-by: YangYulin Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hans/ Translation: pypa/packaging.python.org --- locales/zh_Hans/LC_MESSAGES/messages.po | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po index 86eacd7f1..a68626abf 100644 --- a/locales/zh_Hans/LC_MESSAGES/messages.po +++ b/locales/zh_Hans/LC_MESSAGES/messages.po @@ -7,13 +7,14 @@ # Cube Kassaki <2524737581@qq.com>, 2021. # xlivevil , 2021. # Eric , 2021. +# YangYulin , 2021. msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-10-02 03:36+0000\n" -"Last-Translator: Eric \n" +"PO-Revision-Date: 2021-10-18 15:51+0000\n" +"Last-Translator: YangYulin \n" "Language-Team: Chinese (Simplified) \n" "Language: zh_Hans\n" @@ -1137,6 +1138,7 @@ msgid "" "specific :term:`Project` as the index preferred or required to resolve " "dependencies of that project." msgstr "" +"专用或其他非规范的：term:`Package Index`由特定的：term:`Project`表示，作为首选索引或解决该项目依赖关系所需的索引。" #: ../source/glossary.rst:97 msgid "Project" @@ -1148,6 +1150,8 @@ msgid "" "other resources, or some combination thereof that is intended to be packaged " "into a :term:`Distribution `." msgstr "" +"数据或其他资源的库、框架、脚本、插件、应用程序或集合，或其组合，旨在打包成:term:`Distribution `。" #: ../source/glossary.rst:104 msgid "" From 95516e90ec76fe43e7d6fb6d98e9cbe2e25f9b21 Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Tue, 23 Nov 2021 15:41:09 +0100 Subject: [PATCH 0189/1072] Translated using Weblate (Chinese (Simplified)) Currently translated at 26.8% (610 of 2271 strings) Translated using Weblate (Chinese (Simplified)) Currently translated at 26.5% (604 of 2271 strings) Co-authored-by: meowmeowmeowcat Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hans/ Translation: pypa/packaging.python.org --- locales/zh_Hans/LC_MESSAGES/messages.po | 28 +++++++++++++++++-------- 1 file changed, 19 insertions(+), 9 deletions(-) diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po index a68626abf..0f5fbf0fa 100644 --- a/locales/zh_Hans/LC_MESSAGES/messages.po +++ b/locales/zh_Hans/LC_MESSAGES/messages.po @@ -13,8 +13,8 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-10-18 15:51+0000\n" -"Last-Translator: YangYulin \n" +"PO-Revision-Date: 2021-10-23 18:40+0000\n" +"Last-Translator: meowmeowmeowcat \n" "Language-Team: Chinese (Simplified) \n" "Language: zh_Hans\n" @@ -163,7 +163,7 @@ msgid "" "the `Hitchhiker's Guide to Python installation instructions`_ to install " "Python 3.6 on your operating system." msgstr "" -"Python 3.6。我们的构建脚本只为 Python 3.6 而设计。请参阅 `Hitchhiker's Guide to Python " +"Python 3.6。我们的构建脚本只为 Python 3.6 而设计。请参阅 `Hitchhiker's Guide to 5Python " "installation instructions`_ 将 Python 3.6 安装于您的操作系统中。" #: ../source/contribute.rst:91 @@ -1459,18 +1459,18 @@ msgstr "未在 PyPI 上托管的软件包（为了比较）" msgid "" "Unofficial scripts or attempts at download count inflation (raises download " "counts)" -msgstr "" +msgstr "非官方的脚本或令下载量膨胀的尝试（提高下载量）" #: ../source/guides/analyzing-pypi-package-downloads.rst:32 msgid "Known historical data quality issues (lowers download counts)" -msgstr "" +msgstr "已知的历史数据质量问题（降低了下载次数）" #: ../source/guides/analyzing-pypi-package-downloads.rst:34 msgid "" "**Not particularly useful:** Just because a project has been downloaded a " "lot doesn't mean it's good; Similarly just because a project hasn't been " "downloaded a lot doesn't mean it's bad!" -msgstr "" +msgstr "**不是特别有用：** 一个项目被下载了很多，并不意味着它是好的；同样，一个项目没有被下载很多，也不意味着它不好！" #: ../source/guides/analyzing-pypi-package-downloads.rst:38 msgid "" @@ -1513,7 +1513,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:58 msgid "Navigate to the `BigQuery web UI`_." -msgstr "导航到 `BigQuery web UI`_。" +msgstr "导航到 `BigQuery web UI`_ 。" #: ../source/guides/analyzing-pypi-package-downloads.rst:59 msgid "Create a new project." @@ -2130,6 +2130,9 @@ msgid "" "pypa/sampleproject/blob/master/setup.cfg>`_ in the `PyPA sample project " "`_." msgstr "" +":file:`setup.cfg`是一个 ini 文件，包含 :file:`setup.py`命令的默认选项。 例如，参阅 `PyPA 样本项目 " +"`_ 中的 `setup.cfg `_ 。" #: ../source/guides/distributing-packages-using-setuptools.rst:86 msgid "README.rst / README.md" @@ -2187,6 +2190,8 @@ msgid "" "blob/master/MANIFEST.in>`_ from the `PyPA sample project `_." msgstr "" +"例如，请参阅 `PyPA 样本项目`_ 中的 `MANIFEST.in " +"`_ 。" #: ../source/guides/distributing-packages-using-setuptools.rst:119 msgid "" @@ -2257,6 +2262,8 @@ msgid "" "master/setup.py>`_ contained in the `PyPA sample project `_." msgstr "" +"最相关的参数解释如下。这里给出的大部分片段来自于 `PyPA样本项目 `_ " +"中的`setup.py `_ 。" #: ../source/guides/distributing-packages-using-setuptools.rst:164 msgid "name" @@ -2268,12 +2275,14 @@ msgid "" "term:`PyPI `. Per :pep:`508`, valid project " "names must:" msgstr "" +"这是您的项目名称，这决定了您的项目如何在 :term:`PyPI ` 中列出。 根据 " +":pep:`508`，有效的项目名称必须是：" #: ../source/guides/distributing-packages-using-setuptools.rst:174 msgid "" "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), " "and/or periods (``.``), and" -msgstr "" +msgstr "仅由 ASCII 字母、数字、下划线（``_``）、连字符（``-``）和/或句号（``.``）组成，并且" #: ../source/guides/distributing-packages-using-setuptools.rst:176 msgid "Start & end with an ASCII letter or digit." @@ -2297,7 +2306,7 @@ msgid "" "This is the current version of your project, allowing your users to " "determine whether or not they have the latest version, and to indicate which " "specific versions they've tested their own software against." -msgstr "" +msgstr "这是您的项目的当前版本，允许您的用户确定他们是否有最新的版本，并指出他们对自己的软件进行过哪些具体的测试。" #: ../source/guides/distributing-packages-using-setuptools.rst:200 msgid "" @@ -2310,6 +2319,7 @@ msgid "" "See :ref:`Choosing a versioning scheme` for more information on ways to use " "versions to convey compatibility information to your users." msgstr "" +"请参阅 :ref:`选择版本方案 `以了解更多关于如何使用版本来向您的用户传达兼容性信息。" #: ../source/guides/distributing-packages-using-setuptools.rst:206 msgid "" From 892636333e6442563d4bfc38feae61dafcbe4a5c Mon Sep 17 00:00:00 2001 From: Nathan Date: Tue, 23 Nov 2021 15:41:09 +0100 Subject: [PATCH 0190/1072] Translated using Weblate (French) Currently translated at 9.7% (221 of 2271 strings) Added translation using Weblate (French) Co-authored-by: Nathan Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/fr/ Translation: pypa/packaging.python.org --- locales/fr/LC_MESSAGES/messages.po | 9379 ++++++++++++++++++++++++++++ 1 file changed, 9379 insertions(+) create mode 100644 locales/fr/LC_MESSAGES/messages.po diff --git a/locales/fr/LC_MESSAGES/messages.po b/locales/fr/LC_MESSAGES/messages.po new file mode 100644 index 000000000..8422c8223 --- /dev/null +++ b/locales/fr/LC_MESSAGES/messages.po @@ -0,0 +1,9379 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2013–2020, PyPA +# This file is distributed under the same license as the Python Packaging User Guide package. +# Nathan , 2021. +msgid "" +msgstr "" +"Project-Id-Version: Python Packaging User Guide\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-07-06 19:32+0800\n" +"PO-Revision-Date: 2021-10-23 18:40+0000\n" +"Last-Translator: Nathan \n" +"Language-Team: French \n" +"Language: fr\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=2; plural=n > 1;\n" +"X-Generator: Weblate 4.9-dev\n" + +#: ../source/contribute.rst:5 +msgid "Contribute to this guide" +msgstr "Contribuer à ce guide" + +#: ../source/contribute.rst:7 +msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" +msgstr "" +"La |PyPUG| accueille les contributeurs ! Il existe de nombreuses façons de " +"contribuer, notamment :" + +#: ../source/contribute.rst:10 +msgid "Reading the guide and giving feedback" +msgstr "Lire le guide et envoyer des commentaires" + +#: ../source/contribute.rst:11 +msgid "Reviewing new contributions" +msgstr "Passer en revue les nouvelles contributions" + +#: ../source/contribute.rst:12 +msgid "Revising existing content" +msgstr "Réviser le contenu existant" + +#: ../source/contribute.rst:13 +msgid "Writing new content" +msgstr "Rédiger du nouveau contenu" + +#: ../source/contribute.rst:15 +msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." +msgstr "" +"La plupart du travail sur |PyPUG| prend place sur le `dépôt GitHub du projet`" +"__. Pour commencer, consultez la liste des open issues et des pull requests. " +"Si vous avez l'intention de rédiger ou modifier le guide, veuillez lire le " +":ref:`style guide `" + +#: ../source/contribute.rst:24 +msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." +msgstr "" +"En contribuant à la |PyPUG|, vous devez respecter le `Code de conduite`__ de " +"la PSF." + +#: ../source/contribute.rst:31 +msgid "Documentation types" +msgstr "Types de documentation" + +#: ../source/contribute.rst:33 +msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." +msgstr "" +"Ce projet consiste en quatre types de documentation utilisés à des fins " +"spécifiques. Lorsque vous proposez des nouveaux ajouts au projet, veuillez " +"sélectionner le type de documentation approprié." + +#: ../source/contribute.rst:38 +#: ../source/tutorials/index.rst:2 +msgid "Tutorials" +msgstr "Tutoriels" + +#: ../source/contribute.rst:40 +msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." +msgstr "" + +#: ../source/contribute.rst:47 +#: ../source/guides/index.rst:2 +msgid "Guides" +msgstr "Guides" + +#: ../source/contribute.rst:49 +msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." +msgstr "" + +#: ../source/contribute.rst:56 +#: ../source/discussions/index.rst:2 +msgid "Discussions" +msgstr "Discussions" + +#: ../source/contribute.rst:58 +msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." +msgstr "" + +#: ../source/contribute.rst:63 +msgid "Specifications" +msgstr "Spécifications" + +#: ../source/contribute.rst:65 +msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." +msgstr "" + +#: ../source/contribute.rst:73 +msgid "Building the guide locally" +msgstr "Compiler le guide localement" + +#: ../source/contribute.rst:75 +msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" +msgstr "" +"Même si ce n'est pas nécessaire pour effectuer des contributions, il peut " +"être utile de compiler le guide localement afin de test vos modifications. " +"Afin de compiler ce guide localement, vous aurez besoin de :" + +#: ../source/contribute.rst:79 +msgid "`Nox `_. You can install or upgrade nox using ``pip``::" +msgstr "" +"`Nox `_. Vous pouvez installer nox en " +"utilisant ``pip``::" + +#: ../source/contribute.rst:84 +msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." +msgstr "" +"Python 3.6. Nos scripts de compilation sont conçus pour fonctionner avec " +"Python 3.6 uniquement. Consultez le `Guide de l'auto-stoppeur pour Python : " +"Installer Python correctement`_ pour installer Python 3.6 sur votre système " +"d'exploitation." + +#: ../source/contribute.rst:91 +msgid "To build the guide, run the following bash command in the source folder::" +msgstr "" +"Pour compiler le guide, exécutez la commande bash suivante dans le dossier " +"source ::" + +#: ../source/contribute.rst:95 +msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." +msgstr "" +"Une fois le processus terminé vous pouvez retrouver le résultat au format " +"HTML dans le dossier ``./build/html``. Vous pouvez ouvrir le fichier ``index." +"html`` pour visualiser le guide dans votre navigateur, mais il est " +"recommandé de déployer le guide sur un serveur HTTP." + +#: ../source/contribute.rst:100 +msgid "You can build the guide and serve it via an HTTP server using the following command::" +msgstr "" +"Vous pouvez compiler le guide et le déployer sur un serveur HTTP en " +"utilisant la commande suivante : :" + +#: ../source/contribute.rst:105 +msgid "The guide will be browsable via http://localhost:8000." +msgstr "Le guide pourra être consulté à l'adresse http://localhost:8000." + +#: ../source/contribute.rst:109 +msgid "Where the guide is deployed" +msgstr "Où le guide est-il déployé ?" + +#: ../source/contribute.rst:111 +msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." +msgstr "" + +#: ../source/contribute.rst:117 +msgid "Style guide" +msgstr "Guide de conception" + +#: ../source/contribute.rst:119 +msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." +msgstr "" + +#: ../source/contribute.rst:126 +msgid "Purpose" +msgstr "Objectif" + +#: ../source/contribute.rst:128 +msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." +msgstr "" +"L'objectif du |PyPUG| est d'être la ressource officielle sur la façon " +"d'empaqueter, publier, et installer des projets Python en utilisant des " +"outils courants." + +#: ../source/contribute.rst:133 +msgid "Scope" +msgstr "Portée" + +#: ../source/contribute.rst:135 +msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." +msgstr "" +"Le guide a pour but de répondre aux questions et de résoudre les problèmes " +"par des recommandations précises et ciblées." + +#: ../source/contribute.rst:138 +msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." +msgstr "" +"Ce guide n'a pas pour but d'être exhaustif et de remplacer la documentation " +"des projets individuels. Par exemple, pip possède des dizaines de commandes, " +"d'options et de paramètres. La documentation de pip décrit chacun d'entre " +"eux en détail, alors que ce guide ne décrit que les parties de pip qui sont " +"nécessaires pour accomplir les tâches spécifiques décrites dans ce guide." + +#: ../source/contribute.rst:146 +msgid "Audience" +msgstr "Public cible" + +#: ../source/contribute.rst:148 +msgid "The audience of this guide is anyone who uses Python with packages." +msgstr "" +"Le public visé par ce guide est toute personne qui utilise Python avec des " +"paquets." + +#: ../source/contribute.rst:150 +msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." +msgstr "" +"N'oubliez pas que la communauté Python est grande et accueillante. Les " +"lecteurs n'ont peut-être pas le même âge, le même genre, le même niveau " +"d'éducation, la même culture et bien d'autres choses encore, mais ils " +"méritent autant que vous d'apprendre à connaître le paquetage." + +#: ../source/contribute.rst:154 +msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." +msgstr "" +"En particulier, gardez à l'esprit que toutes les personnes qui utilisent " +"Python ne se considèrent pas comme des développeurs. Le public de ce guide " +"comprend aussi bien des astronomes, des peintres ou des étudiants que des " +"développeurs de logiciels professionnels." + +#: ../source/contribute.rst:160 +msgid "Voice and tone" +msgstr "Tonalité" + +#: ../source/contribute.rst:162 +msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." +msgstr "" +"Lorsque vous rédigez ce guide, tâchez d'écrire avec un ton accessible et " +"simple, même si vous connaissez toutes les solutions." + +#: ../source/contribute.rst:165 +msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." +msgstr "" +"Imaginez que vous travaillez sur un projet Python avec une personne que vous " +"savez intelligente et compétente. Vous aimez travailler avec elle et elle " +"aime travailler avec vous. Cette personne vous pose une question et vous " +"connaissez la réponse. Comment répondre ? C'est *ainsi* que vous devriez " +"écrire ce guide." + +#: ../source/contribute.rst:170 +msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." +msgstr "" +"Voici une méthode de vérification rapide : essayez de lire à haute voix pour " +"vous faire une idée de la tonalité de votre texte. Est-ce que cela ressemble " +"à ce que vous diriez ou est-ce que vous avez l'impression de jouer un rôle " +"ou de faire un discours ? N'hésitez pas à utiliser des contractions et ne " +"vous souciez pas de respecter des règles de grammaire strictes. Vous avez la " +"permission de terminer une phrase par une préposition, si nécessaire." + +#: ../source/contribute.rst:177 +msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." +msgstr "" +"Lorsque vous rédigez le guide, adaptez votre ton au sérieux et à la " +"difficulté du sujet. Si vous rédigez un didacticiel d'introduction, vous " +"pouvez faire une blague, mais si vous traitez d'une recommandation de " +"sécurité sensible, il est préférable d'éviter toute plaisanterie." + +#: ../source/contribute.rst:184 +msgid "Conventions and mechanics" +msgstr "Conventions et mécanismes" + +#: ../source/contribute.rst:192 +msgid "**Write to the reader**" +msgstr "**Écrivez au lecteur**" + +#: ../source/contribute.rst:187 +msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." +msgstr "" +"Lorsque vous donnez des recommandations ou des étapes à suivre, adressez-" +"vous directement au lecteur en disant *vous* ou utilisez l'impératif." + +#: ../source/contribute.rst:0 +msgid "Wrong: To install it, the user runs…" +msgstr "Mauvais : Pour l'installer, l'utilisateur exécute…" + +#: ../source/contribute.rst:0 +msgid "Right: You can install it by running…" +msgstr "Correct : Vous pouvez l'installer en exécutant…" + +#: ../source/contribute.rst:0 +msgid "Right: To install it, run…" +msgstr "Correct : Pour l'installer, exécutez…" + +#: ../source/contribute.rst:198 +msgid "**State assumptions**" +msgstr "" + +#: ../source/contribute.rst:195 +msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." +msgstr "" + +#: ../source/contribute.rst:203 +msgid "**Cross-reference generously**" +msgstr "" + +#: ../source/contribute.rst:201 +msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." +msgstr "" +"La première fois que vous mentionnez un outil ou une pratique, ajoutez un " +"lien vers la page ou le guide concerné, ou ajoutez un lien vers tout " +"document pertinent. Économisez une recherche au lecteur." + +#: ../source/contribute.rst:213 +msgid "**Respect naming practices**" +msgstr "**Respectez les conventions de nommage**" + +#: ../source/contribute.rst:206 +msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." +msgstr "" +"Lorsque vous nommez des outils, sites, personnes ou autres noms propres, " +"respectez leur casse." + +#: ../source/contribute.rst:0 +msgid "Wrong: Pip uses…" +msgstr "Mauvais : Pip utilise…" + +#: ../source/contribute.rst:0 +msgid "Right: pip uses…" +msgstr "Correct : pip utilise…" + +#: ../source/contribute.rst:0 +msgid "Wrong: …hosted on github." +msgstr "Mauvais : …hébergé sur github." + +#: ../source/contribute.rst:0 +msgid "Right: …hosted on GitHub." +msgstr "Correct : …hébergé sur GitHub." + +#: ../source/contribute.rst:222 +msgid "**Use a gender-neutral style**" +msgstr "**Adoptez un style neutre et non genré**" + +#: ../source/contribute.rst:216 +msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." +msgstr "" +"Souvent, vous vous adresserez au lecteur directement avec *vous*, *votre* et " +"*vos*. Utilisez dans la mesure du possible des formes non genrées, sinon " +"adoptez l'écriture inclusive." + +#: ../source/contribute.rst:0 +msgid "Wrong: A maintainer uploads the file. Then he…" +msgstr "Mauvais : Un mainteneur met en ligne le fichier. Puis il…" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then they…" +msgstr "Correct : Un·e mainteneur·euse met en ligne le fichier. Puis…" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then the maintainer…" +msgstr "" + +#: ../source/contribute.rst:234 +msgid "**Headings**" +msgstr "**Titres**" + +#: ../source/contribute.rst:225 +msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." +msgstr "" +"Rédigez des titres qui utilisent les mots recherchés par le lecteur ou la " +"lectrice. Un bon moyen d'y parvenir est de faire en sorte que votre titre " +"réponde à une question implicite. Par exemple, un lecteur ou une lectrice " +"pourrait vouloir savoir *Comment installer MaBibliothèque ?* et un bon titre " +"pourrait être *Installer MaBibliothèque*." + +#: ../source/contribute.rst:230 +msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." +msgstr "" +"Dans les titres de section, employez la casse des phrases. En d'autres " +"termes, rédigez les titres comme vous le feriez pour une phrase classique." + +#: ../source/contribute.rst:0 +msgid "Wrong: Things You Should Know About Python" +msgstr "Mauvais : Les Choses Que Vous Devez Savoir À Propos de Python" + +#: ../source/contribute.rst:0 +msgid "Right: Things you should know about Python" +msgstr "Correct : Les choses que vous devez savoir à propos de Python" + +#: ../source/contribute.rst:237 +msgid "**Numbers**" +msgstr "**Nombres**" + +#: ../source/contribute.rst:237 +msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." +msgstr "" +"Dans le corps du texte, écrivez les chiffres de un à neuf comme des mots. " +"Pour les autres chiffres ou les chiffres des tableaux, utilisez des " +"caractères numériques." + +#: ../source/discussions/deploying-python-applications.rst:4 +msgid "Deploying Python applications" +msgstr "Déployer des applications Python" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Page Status" +msgstr "État de la page" + +#: ../source/discussions/deploying-python-applications.rst:6 +#: ../source/guides/index-mirrors-and-caches.rst:7 +#: ../source/guides/installing-using-linux-tools.rst:7 +#: ../source/guides/packaging-binary-extensions.rst:7 +#: ../source/guides/supporting-multiple-python-versions.rst:7 +#: ../source/guides/supporting-windows-using-appveyor.rst:5 +msgid "Incomplete" +msgstr "Incomplète" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Last Reviewed" +msgstr "Dernière révision" + +#: ../source/discussions/deploying-python-applications.rst:7 +msgid "2014-11-11" +msgstr "2014-11-11" + +#: ../source/discussions/deploying-python-applications.rst:11 +#: ../source/discussions/install-requires-vs-requirements.rst:9 +#: ../source/guides/analyzing-pypi-package-downloads.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:22 +#: ../source/guides/index-mirrors-and-caches.rst:12 +#: ../source/guides/installing-scientific-packages.rst:9 +#: ../source/guides/packaging-binary-extensions.rst:17 +#: ../source/guides/supporting-multiple-python-versions.rst:12 +#: ../source/guides/supporting-windows-using-appveyor.rst:15 +#: ../source/overview.rst:23 +#: ../source/specifications/core-metadata.rst:38 +#: ../source/specifications/direct-url.rst:14 +#: ../source/tutorials/installing-packages.rst:23 +msgid "Contents" +msgstr "Contenu" + +#: ../source/discussions/deploying-python-applications.rst:14 +msgid "Overview" +msgstr "Aperçu" + +#: ../source/discussions/deploying-python-applications.rst:18 +msgid "Supporting multiple hardware platforms" +msgstr "Prendre en charge plusieurs plateformes matérielles" + +#: ../source/discussions/deploying-python-applications.rst:40 +msgid "OS packaging & installers" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:52 +msgid "Windows" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:61 +msgid "Pynsist" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:63 +msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:70 +msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." +msgstr "" +"Le programme installé peut être lancé à partir d'un raccourci que " +"l'installateur ajoute au menu démarrer. Il utilise un interpréteur Python " +"installé dans son répertoire racine, indépendamment de toute autre " +"installation de Python sur l'ordinateur." + +#: ../source/discussions/deploying-python-applications.rst:74 +msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." +msgstr "" +"L'un des gros avantages de Pynsist est que les paquets Windows peuvent être " +"compilés sous Linux. Il y a plusieurs exemples pour différents types de " +"programmes (console, interface graphique) dans la `documentation " +"`__. L'outil est publié sous licence MIT." + +#: ../source/discussions/deploying-python-applications.rst:80 +msgid "Application bundles" +msgstr "Paquets d'applications" + +#: ../source/discussions/deploying-python-applications.rst:91 +msgid "Configuration management" +msgstr "Gestion de la configuration" + +#: ../source/discussions/index.rst:4 +msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." +msgstr "" +"Les **discussions** ont pour but de fournir une information complète sur un " +"sujet spécifique. Si vous essayez seulement de mener à bien vos tâches, " +"consultez :doc:`/guides/index`." + +#: ../source/discussions/install-requires-vs-requirements.rst:5 +msgid "install_requires vs requirements files" +msgstr "Fichiers requirements vs install_requires" + +#: ../source/discussions/install-requires-vs-requirements.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:382 +msgid "install_requires" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:14 +msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" +"``install_requires`` est un mot-clé de :ref:`setuptools` :file:`setup.py` " +"qui doit être utilisé pour spécifier ce dont un projet à besoin *au minimum* " +"pour s'exécuter correctement. Lorsque le projet est installé par :ref:`pip`, " +"c'est cette spécification qui est utilisée pour installer ses dépendances." + +#: ../source/discussions/install-requires-vs-requirements.rst:19 +msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" +msgstr "" +"Par exemple, si le projet nécessite A et B, votre ``install_requires`` " +"ressemblerait à ceci :" + +#: ../source/discussions/install-requires-vs-requirements.rst:29 +msgid "Additionally, it's best practice to indicate any known lower or upper bounds." +msgstr "" +"En outre, il est préférable d'indiquer toute limite inférieure ou supérieure " +"connue." + +#: ../source/discussions/install-requires-vs-requirements.rst:31 +msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" +msgstr "" +"Par exemple, on peut savoir que votre projet nécessite au moins la v1 de « A " +"» et la v2 de « B », ce qui donne le résultat suivant :" + +#: ../source/discussions/install-requires-vs-requirements.rst:41 +msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" +msgstr "" +"On peut également savoir que le projet A respecte le système de version " +"sémantique, et que la v2 de « A » indique une rupture de compatibilité, il " +"est donc logique de ne pas autoriser la version 2 :" + +#: ../source/discussions/install-requires-vs-requirements.rst:51 +msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:56 +msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:64 +#: ../source/tutorials/installing-packages.rst:460 +msgid "Requirements files" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:66 +msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:69 +msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:73 +msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:78 +msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:84 +msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:90 +msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:6 +msgid "pip vs easy_install" +msgstr "pip vs easy_install" + +#: ../source/discussions/pip-vs-easy-install.rst:9 +msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:14 +msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:22 +msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**pip**" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**easy_install**" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +msgid "Installs from :term:`Wheels `" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Yes" +msgstr "Oui" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:30 +#: ../source/discussions/pip-vs-easy-install.rst:32 +#: ../source/discussions/pip-vs-easy-install.rst:35 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:51 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "No" +msgstr "Non" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Uninstall Packages" +msgstr "Désinstaller des paquets" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Yes (``python -m pip uninstall``)" +msgstr "Oui (``python -m pip uninstall``)" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Dependency Overrides" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Yes (:ref:`Requirements Files `)" +msgstr "Oui (:ref:`Requirements Files `)" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "List Installed Packages" +msgstr "Lister les paquets installés" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" +msgstr "Oui (``python -m pip list`` et ``python -m pip freeze``)" + +#: ../source/discussions/pip-vs-easy-install.rst:38 +msgid ":pep:`438` Support" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Installation format" +msgstr "Format d'installation" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "'Flat' packages with :file:`egg-info` metadata." +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Encapsulated Egg format" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:44 +msgid "sys.path modification" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:48 +msgid "Installs from :term:`Eggs `" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "`pylauncher support`_" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "Yes [1]_" +msgstr "Oui [1]_" + +#: ../source/discussions/pip-vs-easy-install.rst:54 +msgid ":ref:`Multi-version Installs`" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Exclude scripts during install" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "per project index" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Only in virtualenv" +msgstr "Seulement dans virtualenv" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Yes, via setup.cfg" +msgstr "Oui, via setup.cfg" + +#: ../source/discussions/pip-vs-easy-install.rst:68 +msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:5 +msgid "Wheel vs Egg" +msgstr "Wheel vs Egg" + +#: ../source/discussions/wheel-vs-egg.rst:7 +msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:11 +msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:14 +msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:17 +msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:20 +msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:22 +msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:26 +msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:31 +msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:34 +msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:38 +msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:41 +msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:47 +msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." +msgstr "" + +#: ../source/glossary.rst:3 +msgid "Glossary" +msgstr "Glossaire" + +#: ../source/glossary.rst:8 +msgid "Binary Distribution" +msgstr "Distribution binaire" + +#: ../source/glossary.rst:11 +msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." +msgstr "" + +#: ../source/glossary.rst:14 +msgid "Built Distribution" +msgstr "Distribution compilée" + +#: ../source/glossary.rst:17 +msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." +msgstr "" + +#: ../source/glossary.rst:26 +msgid "Distribution Package" +msgstr "" + +#: ../source/glossary.rst:29 +msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." +msgstr "" + +#: ../source/glossary.rst:34 +msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." +msgstr "" + +#: ../source/glossary.rst:41 +msgid "Egg" +msgstr "Egg" + +#: ../source/glossary.rst:44 +msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" +msgstr "" + +#: ../source/glossary.rst:49 +msgid "Extension Module" +msgstr "Module d'extension" + +#: ../source/glossary.rst:52 +msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." +msgstr "" + +#: ../source/glossary.rst:59 +msgid "Known Good Set (KGS)" +msgstr "" + +#: ../source/glossary.rst:62 +msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." +msgstr "" + +#: ../source/glossary.rst:68 +msgid "Import Package" +msgstr "" + +#: ../source/glossary.rst:71 +msgid "A Python module which can contain other modules or recursively, other packages." +msgstr "" + +#: ../source/glossary.rst:74 +msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." +msgstr "" + +#: ../source/glossary.rst:78 +msgid "Module" +msgstr "Module" + +#: ../source/glossary.rst:81 +msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." +msgstr "" + +#: ../source/glossary.rst:84 +msgid "Package Index" +msgstr "" + +#: ../source/glossary.rst:87 +msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." +msgstr "" + +#: ../source/glossary.rst:90 +msgid "Per Project Index" +msgstr "" + +#: ../source/glossary.rst:93 +msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." +msgstr "" + +#: ../source/glossary.rst:97 +msgid "Project" +msgstr "Projet" + +#: ../source/glossary.rst:100 +msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." +msgstr "" + +#: ../source/glossary.rst:104 +msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." +msgstr "" + +#: ../source/glossary.rst:110 +msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." +msgstr "" + +#: ../source/glossary.rst:115 +msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." +msgstr "" + +#: ../source/glossary.rst:121 +msgid "Pure Module" +msgstr "Module pur" + +#: ../source/glossary.rst:124 +msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." +msgstr "" + +#: ../source/glossary.rst:127 +msgid "Python Packaging Authority (PyPA)" +msgstr "" + +#: ../source/glossary.rst:130 +msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." +msgstr "" + +#: ../source/glossary.rst:139 +msgid "Python Package Index (PyPI)" +msgstr "Index des Paquets Python (PyPI)" + +#: ../source/glossary.rst:142 +msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." +msgstr "" +"`PyPI `_ est l':term:`Index de Paquets` par défaut pour la " +"communauté Python. Il est ouvert à tous les développeurs Python pour qu'ils " +"utilisent et distribuent leurs paquets." + +#: ../source/glossary.rst:145 +msgid "pypi.org" +msgstr "pypi.org" + +#: ../source/glossary.rst:148 +msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." +msgstr "" + +#: ../source/glossary.rst:152 +msgid "pyproject.toml" +msgstr "pyproject.toml" + +#: ../source/glossary.rst:155 +msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." +msgstr "" + +#: ../source/glossary.rst:157 +msgid "Release" +msgstr "Version" + +#: ../source/glossary.rst:160 +msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." +msgstr "" +"Une image d'un :term:`Projet` à un certain moment dans le temps, défini par " +"un numéro de version." + +#: ../source/glossary.rst:163 +msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." +msgstr "" + +#: ../source/glossary.rst:168 +msgid "Requirement" +msgstr "" + +#: ../source/glossary.rst:171 +msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." +msgstr "" + +#: ../source/glossary.rst:177 +msgid "Requirement Specifier" +msgstr "" + +#: ../source/glossary.rst:180 +msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" +msgstr "" + +#: ../source/glossary.rst:187 +msgid "Requirements File" +msgstr "" + +#: ../source/glossary.rst:190 +msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." +msgstr "" + +#: ../source/glossary.rst:194 +#: ../source/guides/distributing-packages-using-setuptools.rst:56 +msgid "setup.py" +msgstr "setup.py" + +#: ../source/glossary.rst:195 +#: ../source/guides/distributing-packages-using-setuptools.rst:77 +msgid "setup.cfg" +msgstr "setup.cfg" + +#: ../source/glossary.rst:198 +msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." +msgstr "" + +#: ../source/glossary.rst:201 +msgid "Source Archive" +msgstr "" + +#: ../source/glossary.rst:204 +msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:208 +msgid "Source Distribution (or \"sdist\")" +msgstr "" + +#: ../source/glossary.rst:211 +msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." +msgstr "" + +#: ../source/glossary.rst:216 +msgid "System Package" +msgstr "Paquet système" + +#: ../source/glossary.rst:219 +msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." +msgstr "" +"Un paquet fourni dans un format natif au système d'exploitation, par ex. un " +"fichier rpm ou dpkg." + +#: ../source/glossary.rst:222 +msgid "Version Specifier" +msgstr "" + +#: ../source/glossary.rst:225 +msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." +msgstr "" + +#: ../source/glossary.rst:231 +msgid "Virtual Environment" +msgstr "Environnement virtuel" + +#: ../source/glossary.rst:234 +msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/glossary.rst:238 +msgid "Wheel" +msgstr "Wheel" + +#: ../source/glossary.rst:241 +msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." +msgstr "" + +#: ../source/glossary.rst:244 +msgid "Working Set" +msgstr "" + +#: ../source/glossary.rst:247 +msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:3 +msgid "Analyzing PyPI package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:5 +msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:15 +#: ../source/guides/supporting-windows-using-appveyor.rst:18 +msgid "Background" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:17 +msgid "PyPI does not display download statistics for a number of reasons: [#]_" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:19 +msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:24 +msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:27 +msgid "``pip``'s download cache (lowers download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:28 +msgid "Internal or unofficial mirrors (can both raise or lower download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:29 +msgid "Packages not hosted on PyPI (for comparisons sake)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:30 +msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:32 +msgid "Known historical data quality issues (lowers download counts)" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:34 +msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:38 +msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:43 +msgid "Public dataset" +msgstr "Jeu de données public" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:45 +msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:50 +msgid "Getting set up" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:52 +msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:58 +msgid "Navigate to the `BigQuery web UI`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:59 +msgid "Create a new project." +msgstr "Créer un nouveau projet." + +#: ../source/guides/analyzing-pypi-package-downloads.rst:60 +msgid "Enable the `BigQuery API `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:63 +msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:69 +msgid "Data schema" +msgstr "Schéma de données" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:71 +msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +msgid "Column" +msgstr "Colonne" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/guides/using-manifest-in.rst:67 +#: ../source/specifications/core-metadata.rst:185 +msgid "Description" +msgstr "Description" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/specifications/direct-url.rst:226 +msgid "Examples" +msgstr "Exemples" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "timestamp" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "Date and time" +msgstr "Date et heure" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "``2020-03-09 00:33:03 UTC``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "file.project" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "Project name" +msgstr "Nom du projet" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "``pipenv``, ``nose``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "file.version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "Package version" +msgstr "Version du paquet" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "``0.1.6``, ``1.4.2``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "details.installer.name" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "Installer" +msgstr "Installateur" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "pip, `bandersnatch`_" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "details.python" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "Python version" +msgstr "Version de Python" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "``2.7.12``, ``3.6.4``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:93 +msgid "Useful queries" +msgstr "Requêtes utiles" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:95 +msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:97 +msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:102 +msgid "Counting package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:104 +msgid "The following query counts the total number of downloads for the project \"pytest\"." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:119 +#: ../source/guides/analyzing-pypi-package-downloads.rst:140 +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "num_downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:121 +msgid "26190085" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:124 +msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:142 +msgid "24334215" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:146 +msgid "Package downloads over time" +msgstr "Téléchargements de paquets au cours du temps" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:148 +msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +msgid "month" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "1956741" +msgstr "1956741" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "2018-01-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2344692" +msgstr "2344692" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2017-12-01" +msgstr "2017-12-01" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "1730398" +msgstr "1730398" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "2017-11-01" +msgstr "2017-11-01" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2047310" +msgstr "2047310" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2017-10-01" +msgstr "2017-10-01" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "1744443" +msgstr "1744443" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "2017-09-01" +msgstr "2017-09-01" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "1916952" +msgstr "1916952" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "2017-08-01" +msgstr "2017-08-01" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:184 +msgid "Python versions over time" +msgstr "Versions de Python au cours du temps" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:186 +msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." +msgstr "" +"Extraie la version de Python à partir de la colonne ``details.python``. " +"Attention : Cette requête traite plus de 500 Go de données." + +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "python" +msgstr "python" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "3.7" +msgstr "3.7" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "18051328726" +msgstr "18051328726" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "3.6" +msgstr "3.6" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "9635067203" +msgstr "9635067203" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "3.8" +msgstr "3.8" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "7781904681" +msgstr "7781904681" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "2.7" +msgstr "2.7" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "6381252241" +msgstr "6381252241" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "null" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "2026630299" +msgstr "2026630299" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "3.5" +msgstr "3.5" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "1894153540" +msgstr "1894153540" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:221 +msgid "Caveats" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:223 +msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:231 +msgid "Additional tools" +msgstr "Outils supplémentaires" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:233 +msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." +msgstr "" +"En plus de l'utilisation de la console BigQuery, il existe quelques outils " +"supplémentaires qui peuvent être utiles pour analyser les statistiques de " +"téléchargement." + +#: ../source/guides/analyzing-pypi-package-downloads.rst:237 +msgid "``google-cloud-bigquery``" +msgstr "``google-cloud-bigquery``" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:239 +msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:267 +msgid "``pypinfo``" +msgstr "``pypinfo``" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:269 +msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:273 +msgid "Install `pypinfo`_ using pip." +msgstr "Installez `pypinfo`_ à l'aide de pip." + +#: ../source/guides/analyzing-pypi-package-downloads.rst:279 +msgid "Usage:" +msgstr "Usage :" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:295 +msgid "``pandas-gbq``" +msgstr "``pandas-gbq``" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:297 +msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:301 +#: ../source/specifications/binary-distribution-format.rst:459 +msgid "References" +msgstr "Références" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:303 +msgid "`PyPI Download Counts deprecation email `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:304 +msgid "`PyPI BigQuery dataset announcement email `__" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:3 +msgid "Creating and discovering plugins" +msgstr "Créer et découvrir des extensions" + +#: ../source/guides/creating-and-discovering-plugins.rst:5 +msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:10 +msgid "There are three major approaches to doing automatic plugin discovery:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:12 +msgid "`Using naming convention`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:13 +msgid "`Using namespace packages`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:14 +msgid "`Using package metadata`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:18 +msgid "Using naming convention" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:20 +msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:38 +msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:48 +msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:59 +msgid "Using namespace packages" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:61 +msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:89 +msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:101 +msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:115 +msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:121 +msgid "Using package metadata" +msgstr "En utilisant les métadonnées du paquet" + +#: ../source/guides/creating-and-discovering-plugins.rst:123 +msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:128 +msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:139 +msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:154 +msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:163 +msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:166 +msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:170 +msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:5 +msgid "Packaging and distributing projects" +msgstr "Paqueter et distribuer des projets" + +#: ../source/guides/distributing-packages-using-setuptools.rst:7 +msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:11 +msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:15 +msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:25 +msgid "Requirements for packaging and distributing" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:26 +msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:29 +msgid "Install \"twine\" [1]_:" +msgstr "Installez « twine » [1]_ :" + +#: ../source/guides/distributing-packages-using-setuptools.rst:43 +msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:49 +msgid "Configuring your project" +msgstr "Configurer votre projet" + +#: ../source/guides/distributing-packages-using-setuptools.rst:53 +msgid "Initial files" +msgstr "Fichiers initiaux" + +#: ../source/guides/distributing-packages-using-setuptools.rst:58 +msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:63 +msgid ":file:`setup.py` serves two primary functions:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:65 +msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:71 +msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:79 +msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:86 +msgid "README.rst / README.md" +msgstr "README.rst / README.md" + +#: ../source/guides/distributing-packages-using-setuptools.rst:88 +msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:95 +msgid "For an example, see `README.md `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:99 +msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:108 +msgid "MANIFEST.in" +msgstr "MANIFEST.in" + +#: ../source/guides/distributing-packages-using-setuptools.rst:110 +msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:115 +msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:119 +msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:122 +msgid "LICENSE.txt" +msgstr "LICENSE.txt" + +#: ../source/guides/distributing-packages-using-setuptools.rst:124 +msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:130 +msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:135 +msgid "" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:137 +msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:141 +msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:149 +msgid "setup() args" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:151 +msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:155 +msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:164 +msgid "name" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:170 +msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:174 +msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:176 +msgid "Start & end with an ASCII letter or digit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:178 +msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:190 +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "version" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:196 +msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:200 +msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:203 +msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:206 +msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:214 +msgid "description" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:222 +msgid "Give a short and long description for your project." +msgstr "Renseignez une description courte et longue pour votre projet." + +#: ../source/guides/distributing-packages-using-setuptools.rst:224 +msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:229 +msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:235 +msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:245 +msgid "url" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:252 +msgid "Give a homepage URL for your project." +msgstr "Renseignez une URL pour la page d'accueil de votre projet." + +#: ../source/guides/distributing-packages-using-setuptools.rst:256 +msgid "author" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:263 +msgid "Provide details about the author." +msgstr "Renseignez des informations sur l'auteur." + +#: ../source/guides/distributing-packages-using-setuptools.rst:267 +msgid "license" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:273 +msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:279 +msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:287 +msgid "classifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:316 +msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." +msgstr "" +"Renseignez une liste de classifieurs qui catégorisent votre projet. Pour la " +"liste complète, consultez https://pypi.org/classifiers/." + +#: ../source/guides/distributing-packages-using-setuptools.rst:319 +msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:327 +msgid "keywords" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:333 +msgid "List keywords that describe your project." +msgstr "Listez les mots-clés qui décrivent votre projet." + +#: ../source/guides/distributing-packages-using-setuptools.rst:337 +msgid "project_urls" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:349 +msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:355 +msgid "packages" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:361 +msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:370 +msgid "py_modules" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:376 +msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:388 +msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:392 +msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:398 +msgid "python_requires" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:400 +msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:407 +msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:412 +msgid "And so on." +msgstr "Et ainsi de suite." + +#: ../source/guides/distributing-packages-using-setuptools.rst:416 +msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:422 +msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:431 +msgid "package_data" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:440 +msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:445 +msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:449 +msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:457 +msgid "data_files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:463 +msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:469 +msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:479 +msgid "For more information see the distutils section on `Installing Additional Files `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:484 +msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:491 +msgid "scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:493 +msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:500 +msgid "entry_points" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:509 +msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:512 +msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:516 +msgid "The most commonly used entry point is \"console_scripts\" (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:521 +msgid "console_scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:531 +msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:538 +msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:545 +msgid "Choosing a versioning scheme" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:548 +msgid "Standards compliance for interoperability" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:550 +msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:556 +msgid "Here are some examples of compliant version numbers::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:567 +msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:573 +msgid "Scheme choices" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:576 +msgid "Semantic versioning (preferred)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:578 +msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:582 +msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:585 +msgid "MAJOR version when they make incompatible API changes," +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:586 +msgid "MINOR version when they add functionality in a backwards-compatible manner, and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:587 +msgid "MAINTENANCE version when they make backwards-compatible bug fixes." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:589 +msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:594 +msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:598 +msgid "Date based versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:600 +msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:604 +msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:607 +msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:611 +msgid "Serial versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:613 +msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:616 +msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:621 +msgid "Hybrid schemes" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:623 +msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:629 +msgid "Pre-release versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:631 +msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:634 +msgid "zero or more dev releases (denoted with a \".devN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:635 +msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:636 +msgid "zero or more beta releases (denoted with a \".bN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:637 +msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:639 +msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:644 +msgid "Local version identifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:646 +msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:653 +msgid "A local version identifier takes the form ``+``. For example::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:661 +msgid "Working in \"development mode\"" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:663 +msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:667 +msgid "Assuming you're in the root of your project directory, then run:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:674 +msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:680 +msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:688 +msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:692 +msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:697 +msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:701 +msgid "Lastly, if you don't want to install any dependencies at all, you can run::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:706 +msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:713 +msgid "Packaging your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:715 +msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:720 +msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:737 +msgid "Source distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:739 +msgid "Minimally, you should create a :term:`Source Distribution `:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:755 +msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:763 +msgid "Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:765 +msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:770 +msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:773 +msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:776 +msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:785 +msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:792 +msgid "Pure Python Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:794 +msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:797 +#: ../source/guides/distributing-packages-using-setuptools.rst:826 +msgid "To build the wheel:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:811 +msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:815 +msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:821 +msgid "Platform Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:823 +msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:841 +msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:847 +msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:855 +msgid "Uploading your Project to PyPI" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:857 +msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:861 +msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:866 +msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:871 +msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:877 +msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:888 +msgid "Create an account" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:890 +msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:894 +msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:897 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:901 +msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:904 +msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:913 +msgid "**Be aware that this stores your token in plaintext.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:915 +#: ../source/guides/migrating-to-pypi-org.rst:70 +#: ../source/guides/migrating-to-pypi-org.rst:109 +#: ../source/guides/using-testpypi.rst:83 +msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:921 +msgid "Upload your distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:923 +msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:926 +msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:930 +msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:937 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:944 +#: ../source/tutorials/installing-packages.rst:663 +msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:950 +msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:5 +msgid "Dropping support for older Python versions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:7 +msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:9 +msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:12 +msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:14 +msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:17 +msgid "Requirements" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:19 +msgid "This workflow requires that:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:21 +msgid "The publisher is using the latest version of :ref:`setuptools`," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:22 +msgid "The latest version of :ref:`twine` is used to upload the package," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:23 +msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:26 +msgid "Dealing with the universal wheels" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:28 +msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:36 +msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:48 +msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:53 +msgid "Defining the Python version required" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:56 +msgid "1. Download the newest version of Setuptools" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:58 +msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:60 +msgid "Steps:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:74 +msgid "`setuptools` version should be above 24.0.0." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:77 +msgid "2. Specify the version ranges for supported Python distributions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:79 +msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:81 +#: ../source/specifications/core-metadata.rst:139 +#: ../source/specifications/core-metadata.rst:463 +#: ../source/specifications/core-metadata.rst:487 +#: ../source/specifications/core-metadata.rst:527 +#: ../source/specifications/core-metadata.rst:550 +#: ../source/specifications/core-metadata.rst:583 +#: ../source/specifications/core-metadata.rst:693 +#: ../source/specifications/core-metadata.rst:722 +msgid "Examples::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:86 +msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:101 +msgid "3. Validating the Metadata before publishing" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:103 +msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:105 +msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:108 +msgid "You can see the contents of the generated file like this::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:112 +msgid "Validate that the following is in place, before publishing the package:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:114 +msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:115 +msgid "The Requires-Python field is set and matches your specification in setup.py." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:118 +msgid "4. Using Twine to publish" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:120 +msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:122 +msgid "Make sure you are using the newest version of Twine, at least 1.9." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:125 +msgid "Dropping a Python release" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:127 +msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:129 +msgid "It must be done in this order for the automated fallback to work." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:131 +msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:133 +msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:5 +msgid "Hosting your own simple repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:8 +msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:13 +msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:29 +msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:35 +msgid "\"Manual\" repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:37 +msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:51 +msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:58 +msgid "For complete documentation of the simple repository protocol, see :pep:`503`." +msgstr "" + +#: ../source/guides/index.rst:8 +#: ../source/guides/index.rst:8 +msgid "Installing Packages:" +msgstr "" + +#: ../source/guides/index.rst:20 +#: ../source/guides/index.rst:20 +msgid "Building and Publishing Projects:" +msgstr "" + +#: ../source/guides/index.rst:38 +#: ../source/guides/index.rst:38 +msgid "Miscellaneous:" +msgstr "" + +#: ../source/guides/index.rst:4 +msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:5 +msgid "Package index mirrors and caches" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:8 +#: ../source/guides/supporting-multiple-python-versions.rst:8 +msgid "2014-12-24" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:14 +msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:17 +msgid "Three options are available in this area:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:19 +msgid "pip provides local caching options," +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:20 +msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:22 +msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:27 +msgid "Caching with pip" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:29 +msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:32 +msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:36 +msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:45 +msgid "Caching with devpi" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:47 +msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:55 +msgid "Complete mirror with bandersnatch" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:57 +msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:63 +msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:5 +msgid "Installing scientific packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:11 +msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:16 +msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:22 +msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:29 +msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:35 +msgid "Building from source" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:37 +msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:45 +msgid "Linux distribution packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:47 +msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:51 +msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:57 +msgid "Windows installers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:59 +msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:64 +msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:67 +msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:73 +msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:79 +msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:86 +msgid "macOS installers and package managers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:88 +msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:92 +msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:99 +msgid "SciPy distributions" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:101 +msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:105 +msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:109 +#: ../source/key_projects.rst:596 +msgid "Spack" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:110 +msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:119 +msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:128 +msgid "The conda cross-platform package manager" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:130 +msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:136 +msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 +msgid "Installing stand alone command line tools" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 +msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 +msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 +msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 +msgid "pipx only works with Python 3.6+." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 +msgid "``pipx`` is installed with ``pip``:" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 +msgid "You may need to restart your terminal for the path updates to take effect." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 +msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 +#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 +msgid "For example" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 +msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 +msgid "To upgrade or uninstall the package" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 +msgid "``pipx`` can be upgraded or uninstalled with pip" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 +msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 +msgid "To see the full list of commands ``pipx`` offers, run" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 +msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:5 +msgid "Installing pip/setuptools/wheel with Linux Package Managers" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:8 +msgid "2015-09-17" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:11 +msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:14 +msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:18 +msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:25 +msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:32 +msgid "Fedora" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:34 +msgid "Fedora 21:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:36 +#: ../source/guides/installing-using-linux-tools.rst:45 +#: ../source/guides/installing-using-linux-tools.rst:124 +#: ../source/guides/installing-using-linux-tools.rst:138 +#: ../source/guides/installing-using-linux-tools.rst:158 +msgid "Python 2::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:41 +msgid "Python 3: ``sudo yum install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:43 +msgid "Fedora 22:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:50 +msgid "Python 3: ``sudo dnf install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:53 +msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:63 +msgid "CentOS/RHEL" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:65 +msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:68 +msgid "To install pip and wheel for the system Python, there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:70 +msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:77 +msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:81 +msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:85 +msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:92 +msgid "To additionally upgrade setuptools, run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:97 +msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:101 +msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:104 +msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:106 +msgid "For CentOS, see here: https://www.softwarecollections.org/en/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:108 +msgid "Be aware that collections may not contain the most recent versions." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:110 +msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:116 +msgid "For example, for Python 3.4 on CentOS7/RHEL7::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:122 +msgid "openSUSE" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:129 +#: ../source/guides/installing-using-linux-tools.rst:143 +#: ../source/guides/installing-using-linux-tools.rst:162 +msgid "Python 3::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:135 +msgid "Debian/Ubuntu" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:150 +msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:156 +msgid "Arch Linux" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:168 +msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 +msgid "Installing packages using pip and virtual environments" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 +msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 +msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 +msgid "Installing pip" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 +msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 +msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 +msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 +msgid "Afterwards, you should have the newest pip installed in your user site:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 +msgid "The Python installers for Windows include pip. You should be able to access pip using:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 +msgid "You can make sure that pip is up-to-date by running:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 +msgid "Installing virtualenv" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 +msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 +msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 +msgid "Creating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 +msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 +msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 +msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 +msgid "venv will create a virtual Python installation in the ``env`` folder." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 +msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 +msgid "Activating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 +msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 +msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 +msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 +msgid "Leaving the virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 +msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 +msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 +msgid "Installing packages" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 +msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 +msgid "pip should download requests and all of its dependencies and install them:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 +msgid "Installing specific versions" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 +msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 +msgid "To install the latest ``2.x`` release of requests:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 +msgid "To install pre-release versions of packages, use the ``--pre`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 +msgid "Installing extras" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 +msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 +msgid "Installing from source" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 +msgid "pip can install a package directly from source, for example:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 +msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 +msgid "Installing from version control systems" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 +msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 +msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 +#: ../source/tutorials/installing-packages.rst:569 +msgid "Installing from local archives" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 +msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 +msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 +msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 +msgid "Using other package indexes" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 +msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 +msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 +#: ../source/tutorials/installing-packages.rst:389 +msgid "Upgrading packages" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 +msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 +msgid "Using requirements files" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 +msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 +msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 +msgid "Freezing dependencies" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 +msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 +msgid "Which will output a list of package specifiers such as:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 +msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:2 +msgid "Making a PyPI-friendly README" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:4 +msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:9 +msgid "Creating a README file" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:11 +msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:13 +msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:16 +msgid "plain text" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:17 +msgid "`reStructuredText `_ (without Sphinx extensions)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:18 +msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:21 +msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:25 +msgid "Including your README in your package's metadata" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:27 +msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:33 +msgid ":ref:`description-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:34 +msgid ":ref:`description-content-type-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:36 +msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:39 +msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:45 +msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:60 +msgid "The minimum required versions of the respective tools are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:62 +msgid "``setuptools >= 38.6.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:63 +msgid "``wheel >= 0.31.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:64 +msgid "``twine >= 1.11.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:66 +msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:72 +msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:95 +msgid "Validating reStructuredText markup" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:97 +msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:100 +msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:105 +msgid "You can check your README for markup errors before uploading as follows:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:107 +msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:122 +msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:125 +msgid "Run ``twine check`` on the sdist and wheel::" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:129 +msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:4 +msgid "Migrating to PyPI.org" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:6 +msgid ":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``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:12 +msgid "Publishing releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:14 +msgid "``pypi.org`` is the default upload platform as of September 2016." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:16 +msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:22 +msgid "The default upload settings switched to ``pypi.org`` in the following versions:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:24 +msgid "``twine`` 1.8.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:25 +msgid "``setuptools`` 27.0.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:26 +msgid "Python 2.7.13 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:27 +msgid "Python 3.4.6 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:28 +msgid "Python 3.5.3 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:29 +msgid "Python 3.6.0 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:31 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:48 +msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:51 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:67 +msgid "(``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.)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:73 +msgid "Registering package names & metadata" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:75 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:79 +msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:84 +msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:89 +#: ../source/guides/using-testpypi.rst:5 +msgid "Using TestPyPI" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:91 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:113 +msgid "Registering new user accounts" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:115 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:121 +msgid "Browsing packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:123 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:130 +msgid "Downloading packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:132 +msgid "``pypi.org`` is the default host for downloading packages." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:135 +msgid "Managing published packages and releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:137 +msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:5 +msgid "Multi-version installs" +msgstr "" + +#: ../source/guides/multi-version-installs.rst:8 +msgid "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``)." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:13 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:31 +msgid "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 ``python -c ''`` to invoke the application's main entry point directly." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:38 +msgid "Refer to the `pkg_resources documentation `__ for more details." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:5 +msgid "Packaging binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:8 +msgid "2013-12-08" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:10 +msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:20 +msgid "An overview of binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:23 +msgid "Use cases" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:25 +msgid "The typical use cases for binary extensions break down into just three conventional categories:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:28 +msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:39 +msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:47 +msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:56 +msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:61 +msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:71 +msgid "Disadvantages" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:73 +msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:80 +msgid "This means that binary extensions:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:82 +msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:85 +msgid "may not be compatible with different builds of the CPython reference interpreter" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:88 +msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:91 +msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:96 +msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:101 +msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:108 +msgid "Alternatives to handcoded accelerator modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:110 +msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:115 +msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:122 +msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:132 +msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:141 +msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:150 +msgid "Alternatives to handcoded wrapper modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:152 +msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:158 +msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:162 +msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:168 +msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:175 +msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:181 +msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:185 +msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:189 +msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:203 +msgid "Alternatives for low level system access" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:205 +msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:213 +msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:222 +msgid "Implementing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:224 +msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:241 +msgid "Building binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:244 +msgid "Building extensions for multiple platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:246 +msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:256 +msgid "Binary extensions for Windows" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:258 +msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:263 +msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:269 +msgid "To set up a build environment for binary extensions, the steps are as follows:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:271 +msgid "For Python 2.7" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:273 +msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:276 +msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:278 +#: ../source/guides/packaging-binary-extensions.rst:288 +#: ../source/guides/packaging-binary-extensions.rst:295 +msgid "Done." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:280 +msgid "For Python 3.4" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:282 +msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:285 +msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:287 +msgid "Set DISTUTILS_USE_SDK=1" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:290 +msgid "For Python 3.5" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:292 +msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:297 +msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:301 +msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:305 +msgid "Binary extensions for Linux" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:307 +msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:313 +msgid "Binary extensions for macOS" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:315 +msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:325 +msgid "Publishing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:327 +msgid "For interim guidance on this topic, see the discussion in `this issue `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:343 +msgid "Additional resources" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:345 +msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:352 +msgid "Cross-platform wheel generation with scikit-build" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:354 +msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:362 +msgid "Introduction to C/C++ extension modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:364 +msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:367 +msgid "`What are (c)python extension modules? `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:368 +msgid "`Releasing the gil `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:369 +msgid "`Writing cpython extension modules using C++ `_" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:3 +msgid "Packaging namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:5 +msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:24 +msgid "And you use this package in your code like so::" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:29 +msgid "Then you can break these sub-packages into two separate distributions:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:46 +msgid "Each sub-package can now be separately installed, used, and versioned." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:48 +msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:58 +msgid "Creating a namespace package" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:60 +msgid "There are currently three different approaches to creating namespace packages:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:62 +msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:66 +msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:69 +msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:73 +msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:80 +msgid "Native namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:82 +msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:97 +msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:102 +msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:117 +msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:123 +msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:129 +msgid "pkgutil-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:131 +msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:136 +msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:148 +#: ../source/guides/packaging-namespace-packages.rst:194 +msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:155 +#: ../source/guides/packaging-namespace-packages.rst:201 +msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:160 +msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:171 +msgid "pkg_resources-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:173 +msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:182 +msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:206 +msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:216 +msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:223 +msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:237 +msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 +msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 +msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 +msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 +msgid "Saving credentials on GitHub" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 +msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 +msgid "Let's begin! 🚀" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 +msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 +msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 +msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 +msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 +msgid "Creating a workflow definition" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 +msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 +msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 +msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 +msgid "Defining a workflow job environment" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 +msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 +msgid "Checking out the project and building distributions" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 +msgid "Then, add the following under the ``build-n-publish`` section:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 +msgid "This will download your repository into the CI runner and then install and activate Python 3.7." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 +msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 +msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 +msgid "So add this to the steps list:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 +msgid "Publishing the distribution to PyPI and TestPyPI" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 +msgid "Finally, add the following steps at the end:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 +msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 +msgid "That's all, folks!" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 +msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:5 +msgid "Single-sourcing the package version" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:8 +msgid "There are many techniques to maintain a single source of truth for the version number of your project:" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:11 +msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:38 +msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:47 +msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:52 +msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:55 +msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:58 +msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:65 +msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:76 +msgid "Example using this technique: `warehouse `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:78 +msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:86 +msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:91 +msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:95 +msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:110 +msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:114 +msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:128 +msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:134 +msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:138 +msgid "Example using this technique: `setuptools `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:141 +msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:155 +msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:161 +msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:5 +msgid "Supporting multiple Python versions" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:37 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:43 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:49 +msgid "Automated testing and continuous integration" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:51 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:60 +msgid "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:" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:66 +msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:69 +msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:80 +msgid "Both `Travis CI`_ 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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:85 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:89 +msgid "Tools for single-source Python packages" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:91 +msgid "`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_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:100 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:107 +msgid "a Python 2 (by syntax) module in a Python 3 project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:108 +msgid "a Python 3 (by syntax) module in a *Python 2* project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:110 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:117 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:124 +msgid "What's in which Python?" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:126 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:3 +msgid "Supporting Windows using Appveyor" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:6 +msgid "2015-12-03" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:8 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:20 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:24 +msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:30 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:38 +msgid "Setting up" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:40 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:45 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:49 +msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:54 +msgid "Adding Appveyor support to your project" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:61 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:69 +msgid "appveyor.yml" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:75 +msgid "This file can be downloaded from `here `__." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:77 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:80 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:88 +msgid "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``)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:94 +msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:97 +msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:100 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:109 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:114 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:119 +msgid "Support script" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:121 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:126 +msgid "`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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:133 +msgid "You can simply download the batch file and include it in your project unchanged." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:137 +msgid "Access to the built wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:139 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:147 +msgid "Additional notes" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:150 +msgid "Testing with tox" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:152 +msgid "Many projects use the `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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:156 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:160 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:165 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:170 +msgid "``DISTUTILS_USE_SDK``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:171 +msgid "``MSSdk``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:172 +msgid "``INCLUDE``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:173 +msgid "``LIB``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:175 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:181 +msgid "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 Travis or 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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:188 +msgid "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``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:192 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:197 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:203 +msgid "Automatically uploading wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:205 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:210 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:216 +msgid "External dependencies" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:218 +msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:221 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:230 +msgid "Support scripts" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:232 +msgid "For reference, the SDK setup support script is listed here:" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:234 +msgid "``appveyor-sample/build.cmd``" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:5 +msgid "Tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:7 +msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:12 +msgid "Application dependency management" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:14 +msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:18 +msgid "When ``pipenv`` does not meet your use case, consider other tools like:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:20 +msgid ":ref:`pip`" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:22 +msgid "`pip-tools `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:24 +msgid "`Poetry `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:27 +msgid "Installation tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:29 +msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:34 +msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:37 +msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:40 +msgid ":ref:`buildout`: primarily focused on the web development community" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:42 +msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:47 +msgid "Packaging tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:49 +msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:52 +msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:56 +msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:61 +msgid "Publishing platform migration" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:63 +msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:67 +msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:72 +msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:77 +msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:82 +msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:88 +msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:93 +msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:102 +msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:107 +msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:5 +msgid "Including files in source distributions with ``MANIFEST.in``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:7 +msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:17 +msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:22 +msgid "How files are included in an sdist" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:24 +msgid "The following files are included in a source distribution by default:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:26 +msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:28 +msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:30 +msgid "scripts specified by the ``scripts`` ``setup()`` argument" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:31 +msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:33 +msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:35 +msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:37 +msgid "all files matching the pattern :file:`test/test*.py`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:38 +msgid ":file:`setup.py` (or whatever you called your setup script)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:39 +msgid ":file:`setup.cfg`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:40 +msgid ":file:`README`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:41 +msgid ":file:`README.txt`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:42 +msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:43 +msgid ":file:`README.md` (setuptools 36.4.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:44 +msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:45 +msgid ":file:`MANIFEST.in`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:47 +msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:52 +msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:60 +msgid ":file:`MANIFEST.in` commands" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:62 +msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:67 +msgid "Command" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid ":samp:`include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid "Add all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid ":samp:`exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid "Remove all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid ":samp:`global-include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid "Add all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid ":samp:`global-exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid "Remove all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid ":samp:`graft {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid "Add all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid ":samp:`prune {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid "Remove all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:79 +msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:87 +msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:91 +msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:95 +msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:101 +msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." +msgstr "" + +#: ../source/guides/using-testpypi.rst:7 +msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" +msgstr "" + +#: ../source/guides/using-testpypi.rst:13 +msgid "Registering your account" +msgstr "" + +#: ../source/guides/using-testpypi.rst:15 +msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." +msgstr "" + +#: ../source/guides/using-testpypi.rst:19 +msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." +msgstr "" + +#: ../source/guides/using-testpypi.rst:24 +msgid "Using TestPyPI with Twine" +msgstr "" + +#: ../source/guides/using-testpypi.rst:26 +msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:33 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/using-testpypi.rst:39 +msgid "Using TestPyPI with pip" +msgstr "" + +#: ../source/guides/using-testpypi.rst:41 +msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:56 +msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" +msgstr "" + +#: ../source/guides/using-testpypi.rst:73 +msgid "Setting up TestPyPI in :file:`.pypirc`" +msgstr "" + +#: ../source/guides/using-testpypi.rst:75 +msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" +msgstr "" + +#: ../source/index.rst:3 +#: ../source/key_projects.rst:181 +msgid "Python Packaging User Guide" +msgstr "" + +#: ../source/index.rst:5 +msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." +msgstr "" + +#: ../source/index.rst:5 +msgid "python, packaging, guide, tutorial" +msgstr "" + +#: ../source/index.rst:24 +msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." +msgstr "" + +#: ../source/index.rst:28 +msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" +msgstr "" + +#: ../source/index.rst:36 +msgid "Get started" +msgstr "" + +#: ../source/index.rst:38 +msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" +msgstr "" + +#: ../source/index.rst:41 +msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" +msgstr "" + +#: ../source/index.rst:43 +msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" +msgstr "" + +#: ../source/index.rst:45 +msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" +msgstr "" + +#: ../source/index.rst:47 +msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" +msgstr "" + +#: ../source/index.rst:52 +msgid "Learn more" +msgstr "" + +#: ../source/index.rst:54 +msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" +msgstr "" + +#: ../source/index.rst:56 +msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/index.rst:58 +msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." +msgstr "" + +#: ../source/index.rst:60 +msgid "The :doc:`specifications/index` section for packaging interoperability specifications." +msgstr "" + +#: ../source/index.rst:62 +msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." +msgstr "" + +#: ../source/key_projects.rst:6 +msgid "Project Summaries" +msgstr "" + +#: ../source/key_projects.rst:8 +msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." +msgstr "" + +#: ../source/key_projects.rst:14 +msgid "PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:19 +msgid "bandersnatch" +msgstr "" + +#: ../source/key_projects.rst:21 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:25 +msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." +msgstr "" + +#: ../source/key_projects.rst:35 +msgid "build" +msgstr "" + +#: ../source/key_projects.rst:37 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:42 +msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." +msgstr "" + +#: ../source/key_projects.rst:49 +msgid "cibuildwheel" +msgstr "" + +#: ../source/key_projects.rst:51 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" +msgstr "" + +#: ../source/key_projects.rst:58 +msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." +msgstr "" + +#: ../source/key_projects.rst:64 +msgid "distlib" +msgstr "" + +#: ../source/key_projects.rst:66 +msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:71 +msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." +msgstr "" + +#: ../source/key_projects.rst:80 +msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." +msgstr "" + +#: ../source/key_projects.rst:90 +msgid "packaging" +msgstr "" + +#: ../source/key_projects.rst:92 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:97 +msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." +msgstr "" + +#: ../source/key_projects.rst:99 +msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." +msgstr "" + +#: ../source/key_projects.rst:107 +msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." +msgstr "" + +#: ../source/key_projects.rst:119 +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "pip" +msgstr "" + +#: ../source/key_projects.rst:121 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:126 +msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." +msgstr "" + +#: ../source/key_projects.rst:129 +msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." +msgstr "" + +#: ../source/key_projects.rst:137 +msgid "Pipenv" +msgstr "" + +#: ../source/key_projects.rst:139 +msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:144 +msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." +msgstr "" + +#: ../source/key_projects.rst:148 +msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." +msgstr "" + +#: ../source/key_projects.rst:159 +msgid "Pipfile" +msgstr "" + +#: ../source/key_projects.rst:161 +msgid "`Source `__" +msgstr "" + +#: ../source/key_projects.rst:163 +msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." +msgstr "" + +#: ../source/key_projects.rst:170 +msgid "pipx" +msgstr "" + +#: ../source/key_projects.rst:172 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:176 +msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." +msgstr "" + +#: ../source/key_projects.rst:183 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:187 +msgid "This guide!" +msgstr "" + +#: ../source/key_projects.rst:192 +msgid "readme_renderer" +msgstr "" + +#: ../source/key_projects.rst:194 +msgid "`GitHub and docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:197 +msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." +msgstr "" + +#: ../source/key_projects.rst:208 +msgid "setuptools" +msgstr "" + +#: ../source/key_projects.rst:210 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:215 +msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." +msgstr "" + +#: ../source/key_projects.rst:220 +msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." +msgstr "" + +#: ../source/key_projects.rst:227 +msgid "trove-classifiers" +msgstr "" + +#: ../source/key_projects.rst:229 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:233 +msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." +msgstr "" + +#: ../source/key_projects.rst:239 +msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." +msgstr "" + +#: ../source/key_projects.rst:253 +msgid "twine" +msgstr "" + +#: ../source/key_projects.rst:255 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:260 +msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." +msgstr "" + +#: ../source/key_projects.rst:270 +#: ../source/overview.rst:415 +msgid "virtualenv" +msgstr "" + +#: ../source/key_projects.rst:272 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:277 +msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/key_projects.rst:290 +msgid "Warehouse" +msgstr "" + +#: ../source/key_projects.rst:292 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:296 +msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." +msgstr "" + +#: ../source/key_projects.rst:304 +msgid "wheel" +msgstr "" + +#: ../source/key_projects.rst:306 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:311 +msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." +msgstr "" + +#: ../source/key_projects.rst:315 +msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." +msgstr "" + +#: ../source/key_projects.rst:324 +msgid "Non-PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:329 +msgid "bento" +msgstr "" + +#: ../source/key_projects.rst:331 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:336 +msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." +msgstr "" + +#: ../source/key_projects.rst:344 +msgid "buildout" +msgstr "" + +#: ../source/key_projects.rst:346 +msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:351 +msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." +msgstr "" + +#: ../source/key_projects.rst:358 +msgid "conda" +msgstr "" + +#: ../source/key_projects.rst:360 +msgid "`Docs `__" +msgstr "" + +#: ../source/key_projects.rst:362 +msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." +msgstr "" + +#: ../source/key_projects.rst:369 +msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." +msgstr "" + +#: ../source/key_projects.rst:373 +msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." +msgstr "" + +#: ../source/key_projects.rst:386 +msgid "devpi" +msgstr "" + +#: ../source/key_projects.rst:388 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:392 +msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." +msgstr "" + +#: ../source/key_projects.rst:401 +msgid "flit" +msgstr "" + +#: ../source/key_projects.rst:403 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:407 +msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." +msgstr "" + +#: ../source/key_projects.rst:412 +msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." +msgstr "" + +#: ../source/key_projects.rst:422 +msgid "enscons" +msgstr "" + +#: ../source/key_projects.rst:424 +msgid "`Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:428 +msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." +msgstr "" + +#: ../source/key_projects.rst:443 +msgid "Hashdist" +msgstr "" + +#: ../source/key_projects.rst:445 +msgid "`Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:448 +msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." +msgstr "" + +#: ../source/key_projects.rst:460 +msgid "hatch" +msgstr "" + +#: ../source/key_projects.rst:462 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:465 +msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." +msgstr "" + +#: ../source/key_projects.rst:475 +msgid "multibuild" +msgstr "" + +#: ../source/key_projects.rst:477 +msgid "`GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:479 +msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." +msgstr "" + +#: ../source/key_projects.rst:485 +msgid "pex" +msgstr "" + +#: ../source/key_projects.rst:487 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:491 +msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." +msgstr "" + +#: ../source/key_projects.rst:500 +msgid "pip-tools" +msgstr "" + +#: ../source/key_projects.rst:502 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:505 +msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." +msgstr "" + +#: ../source/key_projects.rst:517 +msgid "piwheels" +msgstr "" + +#: ../source/key_projects.rst:519 +msgid "`Website `__ | `Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:523 +msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." +msgstr "" + +#: ../source/key_projects.rst:532 +msgid "poetry" +msgstr "" + +#: ../source/key_projects.rst:534 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:538 +msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." +msgstr "" + +#: ../source/key_projects.rst:548 +msgid "pypiserver" +msgstr "" + +#: ../source/key_projects.rst:550 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:554 +msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." +msgstr "" + +#: ../source/key_projects.rst:564 +msgid "scikit-build" +msgstr "" + +#: ../source/key_projects.rst:566 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:570 +msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." +msgstr "" + +#: ../source/key_projects.rst:582 +msgid "shiv" +msgstr "" + +#: ../source/key_projects.rst:584 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:588 +msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." +msgstr "" + +#: ../source/key_projects.rst:598 +msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" +msgstr "" + +#: ../source/key_projects.rst:603 +msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." +msgstr "" + +#: ../source/key_projects.rst:611 +msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." +msgstr "" + +#: ../source/key_projects.rst:617 +msgid "zest.releaser" +msgstr "" + +#: ../source/key_projects.rst:619 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:623 +msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." +msgstr "" + +#: ../source/key_projects.rst:630 +msgid "Standard Library Projects" +msgstr "" + +#: ../source/key_projects.rst:635 +msgid "ensurepip" +msgstr "" + +#: ../source/key_projects.rst:637 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:640 +msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." +msgstr "" + +#: ../source/key_projects.rst:649 +msgid "distutils" +msgstr "" + +#: ../source/key_projects.rst:651 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:654 +msgid "The original Python packaging system, added to the standard library in Python 2.0." +msgstr "" + +#: ../source/key_projects.rst:657 +msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." +msgstr "" + +#: ../source/key_projects.rst:670 +msgid "venv" +msgstr "" + +#: ../source/key_projects.rst:672 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:675 +msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/news.rst:2 +msgid "News" +msgstr "" + +#: ../source/news.rst:5 +msgid "September 2019" +msgstr "" + +#: ../source/news.rst:6 +msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" +msgstr "" + +#: ../source/news.rst:9 +msgid "August 2019" +msgstr "" + +#: ../source/news.rst:10 +msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" +msgstr "" + +#: ../source/news.rst:13 +msgid "July 2019" +msgstr "" + +#: ../source/news.rst:14 +msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" +msgstr "" + +#: ../source/news.rst:15 +msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" +msgstr "" + +#: ../source/news.rst:16 +msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" +msgstr "" + +#: ../source/news.rst:17 +msgid "Updated directory layout examples for consistency. (:pr:`611`)" +msgstr "" + +#: ../source/news.rst:18 +msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" +msgstr "" + +#: ../source/news.rst:21 +msgid "June 2019" +msgstr "" + +#: ../source/news.rst:22 +msgid "Fixed some typos. (:pr:`620`)" +msgstr "" + +#: ../source/news.rst:25 +msgid "May 2019" +msgstr "" + +#: ../source/news.rst:26 +msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" +msgstr "" + +#: ../source/news.rst:27 +msgid "Added a MANIFEST.in guide page. (:pr:`609`)" +msgstr "" + +#: ../source/news.rst:30 +msgid "April 2019" +msgstr "" + +#: ../source/news.rst:31 +msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" +msgstr "" + +#: ../source/news.rst:32 +msgid "Reduced emphasis on virtualenv. (:pr:`606`)" +msgstr "" + +#: ../source/news.rst:35 +msgid "March 2019" +msgstr "" + +#: ../source/news.rst:36 +msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" +msgstr "" + +#: ../source/news.rst:37 +msgid "Covered RTD details for contributing. (:pr:`600`)" +msgstr "" + +#: ../source/news.rst:40 +msgid "February 2019" +msgstr "" + +#: ../source/news.rst:41 +msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" +msgstr "" + +#: ../source/news.rst:42 +msgid "Added instructions to install Python CLI applications. (:pr:`594`)" +msgstr "" + +#: ../source/news.rst:45 +msgid "January 2019" +msgstr "" + +#: ../source/news.rst:46 +msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" +msgstr "" + +#: ../source/news.rst:47 +msgid "Updated Sphinx and Nox. (:pr:`591`)" +msgstr "" + +#: ../source/news.rst:48 +msgid "Referenced Twine from Python3. (:pr:`581`)" +msgstr "" + +#: ../source/news.rst:51 +msgid "December 2018" +msgstr "" + +#: ../source/news.rst:52 +msgid "No programmers in the office!" +msgstr "" + +#: ../source/news.rst:55 +msgid "November 2018" +msgstr "" + +#: ../source/news.rst:56 +msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" +msgstr "" + +#: ../source/news.rst:57 +msgid "Changed bumpversion to bump2version. (:pr:`572`)" +msgstr "" + +#: ../source/news.rst:58 +msgid "Added single-sourcing package version example. (:pr:`573`)" +msgstr "" + +#: ../source/news.rst:59 +msgid "Added a guide for creating documentation. (:pr:`568`)" +msgstr "" + +#: ../source/news.rst:62 +msgid "October 2018" +msgstr "" + +#: ../source/news.rst:63 +msgid "Updated Nox package name. (:pr:`566`)" +msgstr "" + +#: ../source/news.rst:64 +msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" +msgstr "" + +#: ../source/news.rst:67 +msgid "September 2018" +msgstr "" + +#: ../source/news.rst:68 +msgid "Added a section on checking RST markup. (:pr:`554`)" +msgstr "" + +#: ../source/news.rst:69 +msgid "Updated user installs page. (:pr:`558`)" +msgstr "" + +#: ../source/news.rst:70 +msgid "Updated Google BigQuery urls. (:pr:`556`)" +msgstr "" + +#: ../source/news.rst:71 +msgid "Replaced tar command with working command. (:pr:`552`)" +msgstr "" + +#: ../source/news.rst:72 +msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" +msgstr "" + +#: ../source/news.rst:75 +msgid "August 2018" +msgstr "" + +#: ../source/news.rst:76 +msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" +msgstr "" + +#: ../source/news.rst:77 +msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" +msgstr "" + +#: ../source/news.rst:78 +msgid "Updated Python version supported by virtualenv. (:pr:`538`)" +msgstr "" + +#: ../source/news.rst:79 +msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" +msgstr "" + +#: ../source/news.rst:82 +msgid "July 2018" +msgstr "" + +#: ../source/news.rst:84 +msgid "Improved binary extension docs. (:pr:`531`)" +msgstr "" + +#: ../source/news.rst:85 +msgid "Added scikit-build to key projects. (:pr:`530`)" +msgstr "" + +#: ../source/news.rst:88 +msgid "June 2018" +msgstr "" + +#: ../source/news.rst:90 +msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" +msgstr "" + +#: ../source/news.rst:91 +msgid "Updated Markdown descriptions explanation. (:pr:`522`)" +msgstr "" + +#: ../source/news.rst:94 +msgid "May 2018" +msgstr "" + +#: ../source/news.rst:96 +msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" +msgstr "" + +#: ../source/news.rst:97 +msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" +msgstr "" + +#: ../source/news.rst:98 +msgid "Simplified packaging tutorial. (:pr:`498`)" +msgstr "" + +#: ../source/news.rst:99 +msgid "Updated Windows users instructions for clarity. (:pr:`493`)" +msgstr "" + +#: ../source/news.rst:100 +msgid "Updated the license section description for completeness. (:pr:`492`)" +msgstr "" + +#: ../source/news.rst:101 +msgid "Added specification-style document to contributing section. (:pr:`489`)" +msgstr "" + +#: ../source/news.rst:102 +msgid "Added documentation types to contributing guide. (:pr:`485`)" +msgstr "" + +#: ../source/news.rst:105 +msgid "April 2018" +msgstr "" + +#: ../source/news.rst:107 +msgid "Added README guide. (:pr:`461`)" +msgstr "" + +#: ../source/news.rst:108 +msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" +msgstr "" + +#: ../source/news.rst:109 +msgid "Added instructions for Warehouse. (:pr:`471`)" +msgstr "" + +#: ../source/news.rst:110 +msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" +msgstr "" + +#: ../source/news.rst:111 +msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" +msgstr "" + +#: ../source/news.rst:112 +msgid "Added a guide for phasing out Python versions. (:pr:`459`)" +msgstr "" + +#: ../source/news.rst:113 +msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" +msgstr "" + +#: ../source/news.rst:116 +msgid "March 2018" +msgstr "" + +#: ../source/news.rst:118 +msgid "Updated \"installing scientific packages\". (:pr:`455`)" +msgstr "" + +#: ../source/news.rst:119 +msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" +msgstr "" + +#: ../source/news.rst:120 +msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" +msgstr "" + +#: ../source/news.rst:121 +msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" +msgstr "" + +#: ../source/news.rst:124 +msgid "February 2018" +msgstr "" + +#: ../source/news.rst:126 +msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" +msgstr "" + +#: ../source/news.rst:127 +msgid "Updated PyPI migration info. (:pr:`439`)" +msgstr "" + +#: ../source/news.rst:128 +msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" +msgstr "" + +#: ../source/news.rst:129 +msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" +msgstr "" + +#: ../source/news.rst:130 +msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" +msgstr "" + +#: ../source/news.rst:133 +msgid "January 2018" +msgstr "" + +#: ../source/news.rst:135 +msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" +msgstr "" + +#: ../source/news.rst:136 +msgid "Updated README.rst explanation. (:pr:`419`)" +msgstr "" + +#: ../source/news.rst:139 +msgid "December 2017" +msgstr "" + +#: ../source/news.rst:141 +msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" +msgstr "" + +#: ../source/news.rst:142 +msgid "Noted which fields can be used with environment markers. (:pr:`416`)" +msgstr "" + +#: ../source/news.rst:143 +msgid "Updated Requires-Python section. (:pr:`414`)" +msgstr "" + +#: ../source/news.rst:144 +msgid "Added news page. (:pr:`404`)" +msgstr "" + +#: ../source/news.rst:147 +msgid "November 2017" +msgstr "" + +#: ../source/news.rst:149 +msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" +msgstr "" + +#: ../source/news.rst:150 +msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" +msgstr "" + +#: ../source/news.rst:152 +msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:153 +msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" +msgstr "" + +#: ../source/news.rst:156 +msgid "October 2017" +msgstr "" + +#: ../source/news.rst:158 +msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:159 +msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" +msgstr "" + +#: ../source/news.rst:160 +msgid "Split the specifications page into multiple pages. (:pr:`386`)" +msgstr "" + +#: ../source/news.rst:163 +msgid "September 2017" +msgstr "" + +#: ../source/news.rst:165 +msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" +msgstr "" + +#: ../source/news.rst:167 +msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" +msgstr "" + +#: ../source/news.rst:170 +msgid "August 2017" +msgstr "" + +#: ../source/news.rst:172 +msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" +msgstr "" + +#: ../source/news.rst:173 +msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" +msgstr "" + +#: ../source/news.rst:174 +msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" +msgstr "" + +#: ../source/news.rst:177 +msgid "July 2017" +msgstr "" + +#: ../source/news.rst:179 +msgid "Added ``flit`` to the key projects list. (:pr:`358`)" +msgstr "" + +#: ../source/news.rst:180 +msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" +msgstr "" + +#: ../source/news.rst:181 +msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" +msgstr "" + +#: ../source/news.rst:182 +msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" +msgstr "" + +#: ../source/news.rst:183 +msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" +msgstr "" + +#: ../source/news.rst:186 +msgid "June 2017" +msgstr "" + +#: ../source/news.rst:188 +msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" +msgstr "" + +#: ../source/news.rst:189 +msgid "Added documentation for ``python_requires``. (:pr:`338`)" +msgstr "" + +#: ../source/news.rst:190 +msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" +msgstr "" + +#: ../source/news.rst:191 +msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" +msgstr "" + +#: ../source/news.rst:192 +msgid "Added a license section to the distributing guide. (:pr:`331`)" +msgstr "" + +#: ../source/news.rst:193 +msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" +msgstr "" + +#: ../source/news.rst:194 +msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" +msgstr "" + +#: ../source/news.rst:195 +msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" +msgstr "" + +#: ../source/news.rst:196 +msgid "Switched to the PyPA theme. (:pr:`305`)" +msgstr "" + +#: ../source/news.rst:197 +msgid "Re-organized the documentation into the new structure. (:pr:`318`)" +msgstr "" + +#: ../source/news.rst:200 +msgid "May 2017" +msgstr "" + +#: ../source/news.rst:202 +msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" +msgstr "" + +#: ../source/news.rst:203 +msgid "Added contributor and style guide. (:pr:`307`)" +msgstr "" + +#: ../source/news.rst:204 +msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" +msgstr "" + +#: ../source/news.rst:207 +msgid "April 2017" +msgstr "" + +#: ../source/news.rst:209 +msgid "Added travis configuration for testing pull requests. (:pr:`300`)" +msgstr "" + +#: ../source/news.rst:210 +msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" +msgstr "" + +#: ../source/news.rst:211 +msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" +msgstr "" + +#: ../source/news.rst:212 +msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" +msgstr "" + +#: ../source/news.rst:213 +msgid "Added a topic on namespace packages. (:pr:`290`)" +msgstr "" + +#: ../source/news.rst:214 +msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" +msgstr "" + +#: ../source/news.rst:215 +msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" +msgstr "" + +#: ../source/news.rst:216 +msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" +msgstr "" + +#: ../source/news.rst:217 +msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" +msgstr "" + +#: ../source/news.rst:219 +msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" +msgstr "" + +#: ../source/news.rst:223 +msgid "March 2017" +msgstr "" + +#: ../source/news.rst:225 +msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" +msgstr "" + +#: ../source/news.rst:228 +msgid "February 2017" +msgstr "" + +#: ../source/news.rst:230 +msgid "Added :pep:`518`. (:pr:`281`)" +msgstr "" + +#: ../source/overview.rst:3 +msgid "An Overview of Packaging for Python" +msgstr "" + +#: ../source/overview.rst:7 +msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." +msgstr "" + +#: ../source/overview.rst:12 +msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." +msgstr "" + +#: ../source/overview.rst:18 +msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." +msgstr "" + +#: ../source/overview.rst:26 +msgid "Thinking about deployment" +msgstr "" + +#: ../source/overview.rst:28 +msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" +msgstr "" + +#: ../source/overview.rst:32 +msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" +msgstr "" + +#: ../source/overview.rst:35 +msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" +msgstr "" + +#: ../source/overview.rst:37 +msgid "Is your software installed individually, or in large deployment batches?" +msgstr "" + +#: ../source/overview.rst:39 +msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." +msgstr "" + +#: ../source/overview.rst:46 +msgid "Packaging Python libraries and tools" +msgstr "" + +#: ../source/overview.rst:48 +msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/overview.rst:53 +msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." +msgstr "" + +#: ../source/overview.rst:59 +msgid "Python modules" +msgstr "" + +#: ../source/overview.rst:61 +msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." +msgstr "" + +#: ../source/overview.rst:66 +msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." +msgstr "" + +#: ../source/overview.rst:73 +msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." +msgstr "" + +#: ../source/overview.rst:78 +msgid "Python source distributions" +msgstr "" + +#: ../source/overview.rst:80 +msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." +msgstr "" + +#: ../source/overview.rst:84 +msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." +msgstr "" + +#: ../source/overview.rst:90 +msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." +msgstr "" + +#: ../source/overview.rst:95 +msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." +msgstr "" + +#: ../source/overview.rst:100 +msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." +msgstr "" + +#: ../source/overview.rst:107 +msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" +msgstr "" + +#: ../source/overview.rst:114 +msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." +msgstr "" + +#: ../source/overview.rst:119 +msgid "Python binary distributions" +msgstr "" + +#: ../source/overview.rst:121 +msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." +msgstr "" + +#: ../source/overview.rst:125 +msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." +msgstr "" + +#: ../source/overview.rst:132 +msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." +msgstr "" + +#: ../source/overview.rst:140 +msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." +msgstr "" + +#: ../source/overview.rst:148 +msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." +msgstr "" + +#: ../source/overview.rst:155 +msgid "Packaging Python applications" +msgstr "" + +#: ../source/overview.rst:157 +msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." +msgstr "" + +#: ../source/overview.rst:162 +msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." +msgstr "" + +#: ../source/overview.rst:166 +msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." +msgstr "" + +#: ../source/overview.rst:172 +msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." +msgstr "" + +#: ../source/overview.rst:176 +msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." +msgstr "" + +#: ../source/overview.rst:181 +msgid "Depending on a framework" +msgstr "" + +#: ../source/overview.rst:183 +msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." +msgstr "" + +#: ../source/overview.rst:189 +msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." +msgstr "" + +#: ../source/overview.rst:195 +msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." +msgstr "" + +#: ../source/overview.rst:199 +msgid "Service platforms" +msgstr "" + +#: ../source/overview.rst:201 +msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." +msgstr "" + +#: ../source/overview.rst:205 +msgid "`Heroku `_" +msgstr "" + +#: ../source/overview.rst:206 +msgid "`Google App Engine `_" +msgstr "" + +#: ../source/overview.rst:207 +msgid "`PythonAnywhere `_" +msgstr "" + +#: ../source/overview.rst:208 +msgid "`OpenShift `_" +msgstr "" + +#: ../source/overview.rst:209 +msgid "\"Serverless\" frameworks like `Zappa `_" +msgstr "" + +#: ../source/overview.rst:211 +msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." +msgstr "" + +#: ../source/overview.rst:216 +msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." +msgstr "" + +#: ../source/overview.rst:220 +msgid "Web browsers and mobile applications" +msgstr "" + +#: ../source/overview.rst:222 +msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." +msgstr "" + +#: ../source/overview.rst:227 +msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" +msgstr "" + +#: ../source/overview.rst:231 +msgid "`Kivy `_" +msgstr "" + +#: ../source/overview.rst:232 +msgid "`Beeware `_" +msgstr "" + +#: ../source/overview.rst:233 +msgid "`Brython `_" +msgstr "" + +#: ../source/overview.rst:234 +msgid "`Flexx `_" +msgstr "" + +#: ../source/overview.rst:236 +msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." +msgstr "" + +#: ../source/overview.rst:241 +msgid "Depending on a pre-installed Python" +msgstr "" + +#: ../source/overview.rst:243 +msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." +msgstr "" + +#: ../source/overview.rst:249 +msgid "Technologies which support this model:" +msgstr "" + +#: ../source/overview.rst:251 +msgid "`PEX `_ (Python EXecutable)" +msgstr "" + +#: ../source/overview.rst:252 +msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" +msgstr "" + +#: ../source/overview.rst:253 +msgid "`shiv `_ (requires Python 3)" +msgstr "" + +#: ../source/overview.rst:255 +msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." +msgstr "" + +#: ../source/overview.rst:260 +msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." +msgstr "" + +#: ../source/overview.rst:267 +msgid "Depending on a separate software distribution ecosystem" +msgstr "" + +#: ../source/overview.rst:269 +msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." +msgstr "" + +#: ../source/overview.rst:274 +msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." +msgstr "" + +#: ../source/overview.rst:284 +msgid "Instructions on building and publishing for the Anaconda ecosystem:" +msgstr "" + +#: ../source/overview.rst:286 +msgid "`Building libraries and applications with conda `_" +msgstr "" + +#: ../source/overview.rst:287 +msgid "`Transitioning a native Python package to Anaconda `_" +msgstr "" + +#: ../source/overview.rst:289 +msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" +msgstr "" + +#: ../source/overview.rst:293 +msgid "`Enthought Canopy `_" +msgstr "" + +#: ../source/overview.rst:294 +msgid "`ActiveState ActivePython `_" +msgstr "" + +#: ../source/overview.rst:295 +msgid "`WinPython `_" +msgstr "" + +#: ../source/overview.rst:300 +msgid "Bringing your own Python executable" +msgstr "" + +#: ../source/overview.rst:302 +msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." +msgstr "" + +#: ../source/overview.rst:306 +msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." +msgstr "" + +#: ../source/overview.rst:311 +msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." +msgstr "" + +#: ../source/overview.rst:315 +msgid "A selection of Python freezers:" +msgstr "" + +#: ../source/overview.rst:317 +msgid "`pyInstaller `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:318 +msgid "`cx_Freeze `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:319 +msgid "`constructor `_ - For command-line installers" +msgstr "" + +#: ../source/overview.rst:320 +msgid "`py2exe `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:321 +msgid "`py2app `_ - Mac only" +msgstr "" + +#: ../source/overview.rst:322 +msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" +msgstr "" + +#: ../source/overview.rst:323 +msgid "`osnap `_ - Windows and Mac" +msgstr "" + +#: ../source/overview.rst:324 +msgid "`pynsist `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:326 +msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." +msgstr "" + +#: ../source/overview.rst:332 +msgid "Bringing your own userspace" +msgstr "" + +#: ../source/overview.rst:334 +msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." +msgstr "" + +#: ../source/overview.rst:341 +msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." +msgstr "" + +#: ../source/overview.rst:344 +msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" +msgstr "" + +#: ../source/overview.rst:347 +msgid "`AppImage `_" +msgstr "" + +#: ../source/overview.rst:348 +msgid "`Docker `_" +msgstr "" + +#: ../source/overview.rst:349 +msgid "`Flatpak `_" +msgstr "" + +#: ../source/overview.rst:350 +msgid "`Snapcraft `_" +msgstr "" + +#: ../source/overview.rst:353 +msgid "Bringing your own kernel" +msgstr "" + +#: ../source/overview.rst:355 +msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." +msgstr "" + +#: ../source/overview.rst:360 +msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" +msgstr "" + +#: ../source/overview.rst:364 +msgid "`Vagrant `_" +msgstr "" + +#: ../source/overview.rst:365 +msgid "`VHD `_, `AMI `_, and `other formats `_" +msgstr "" + +#: ../source/overview.rst:366 +msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" +msgstr "" + +#: ../source/overview.rst:369 +msgid "Bringing your own hardware" +msgstr "" + +#: ../source/overview.rst:371 +msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." +msgstr "" + +#: ../source/overview.rst:375 +msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." +msgstr "" + +#: ../source/overview.rst:379 +msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." +msgstr "" + +#: ../source/overview.rst:389 +msgid "The simplified gamut of technologies used to package Python applications." +msgstr "" + +#: ../source/overview.rst:392 +msgid "What about..." +msgstr "" + +#: ../source/overview.rst:394 +msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." +msgstr "" + +#: ../source/overview.rst:398 +msgid "Operating system packages" +msgstr "" + +#: ../source/overview.rst:400 +msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." +msgstr "" + +#: ../source/overview.rst:411 +msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." +msgstr "" + +#: ../source/overview.rst:417 +msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." +msgstr "" + +#: ../source/overview.rst:427 +msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." +msgstr "" + +#: ../source/overview.rst:432 +msgid "Security" +msgstr "" + +#: ../source/overview.rst:434 +msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." +msgstr "" + +#: ../source/overview.rst:437 +msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." +msgstr "" + +#: ../source/overview.rst:446 +msgid "Wrap up" +msgstr "" + +#: ../source/overview.rst:448 +msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:6 +msgid "Binary distribution format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:8 +msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:13 +msgid "Abstract" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:15 +msgid "This PEP describes a built-package format for Python called \"wheel\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:17 +msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:27 +msgid "PEP Acceptance" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:29 +msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:34 +msgid "Rationale" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:36 +msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:43 +msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:52 +msgid "Details" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:55 +msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:57 +msgid "Wheel installation notionally consists of two phases:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:59 +msgid "Unpack." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:61 +msgid "Parse ``distribution-1.0.dist-info/WHEEL``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:62 +msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:64 +msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:66 +msgid "Else unpack archive into platlib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:68 +msgid "Spread." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:70 +msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:72 +msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:78 +msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:80 +msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:82 +msgid "Remove empty ``distribution-1.0.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:83 +msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:87 +msgid "Recommended installer features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:97 +msgid "Rewrite ``#!python``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:90 +msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:96 +msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:102 +msgid "Generate script wrappers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:100 +msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:105 +msgid "Recommended archiver features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:112 +msgid "Place ``.dist-info`` at the end of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:108 +msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:115 +msgid "File Format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:118 +msgid "File name convention" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:120 +msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "distribution" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "Distribution name, e.g. 'django', 'pyramid'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "Distribution version, e.g. 1.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:135 +msgid "build tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:130 +msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "language implementation and version tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "E.g. 'py27', 'py2', 'py3'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "abi tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "E.g. 'cp33m', 'abi3', 'none'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "platform tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "E.g. 'linux_x86_64', 'any'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:146 +msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:151 +msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:156 +msgid "Escaping and Unicode" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:158 +msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:161 +msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:164 +msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:166 +msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:169 +msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:172 +msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:176 +msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:182 +msgid "File contents" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:184 +msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:188 +msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:191 +msgid "``{distribution}-{version}.dist-info/`` contains metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:192 +msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:196 +msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:200 +msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:202 +msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:212 +msgid "``Wheel-Version`` is the version number of the Wheel specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:213 +msgid "``Generator`` is the name and optionally the version of the software that produced the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:215 +msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:218 +msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:220 +msgid "``Build`` is the build number and is omitted if there is no build number." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:221 +msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:224 +msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:226 +msgid "Wheel does not contain setup.py or setup.cfg." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:228 +msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:235 +#: ../source/specifications/recording-installed-packages.rst:35 +msgid "The .dist-info directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:237 +msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:239 +msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:241 +msgid "WHEEL is the wheel metadata specific to a build of the package." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:242 +msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:248 +msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:249 +msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:251 +msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:254 +msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:261 +msgid "The .data directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:263 +msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:271 +msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:277 +msgid "Signed wheel files" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:279 +msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:290 +msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:295 +msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:302 +msgid "(The hash value is the same format used in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:304 +msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:307 +msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:312 +msgid "See" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:314 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:315 +msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:316 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:317 +msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:321 +msgid "Comparison to .egg" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:323 +msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:328 +msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:331 +msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:337 +msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:341 +msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:344 +msgid "Wheel is a reference to the other Python." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:348 +msgid "FAQ" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:352 +msgid "Wheel defines a .data directory. Should I put all my data there?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:354 +msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:363 +msgid "Why does wheel include attached signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:365 +msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:373 +msgid "Why does wheel allow JWS signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:375 +msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:381 +msgid "Why does wheel also allow S/MIME signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:383 +msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:386 +msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:391 +msgid "What's the deal with \"purelib\" vs. \"platlib\"?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:393 +msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:398 +msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:403 +msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:409 +msgid "Is it possible to import Python code directly from a wheel file?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:411 +msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:417 +msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:426 +msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:443 +msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:450 +msgid "Changes" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:452 +msgid "Since :pep:`427`, this specification has changed as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:454 +msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:461 +msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:466 +msgid "Appendix" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:468 +msgid "Example urlsafe-base64-nopad implementation::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:482 +msgid "Copyright" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:484 +msgid "This document has been placed into the public domain." +msgstr "" + +#: ../source/specifications/core-metadata.rst:5 +msgid "Core metadata specifications" +msgstr "" + +#: ../source/specifications/core-metadata.rst:7 +msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:10 +msgid "``Metadata-Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:11 +msgid "``Name``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:12 +msgid "``Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:14 +msgid "All the other fields are optional." +msgstr "" + +#: ../source/specifications/core-metadata.rst:16 +msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." +msgstr "" + +#: ../source/specifications/core-metadata.rst:25 +msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:30 +msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." +msgstr "" + +#: ../source/specifications/core-metadata.rst:41 +msgid "Metadata-Version" +msgstr "" + +#: ../source/specifications/core-metadata.rst:45 +msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." +msgstr "" + +#: ../source/specifications/core-metadata.rst:48 +msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:54 +msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." +msgstr "" + +#: ../source/specifications/core-metadata.rst:58 +#: ../source/specifications/core-metadata.rst:80 +#: ../source/specifications/core-metadata.rst:95 +#: ../source/specifications/core-metadata.rst:155 +#: ../source/specifications/core-metadata.rst:170 +#: ../source/specifications/core-metadata.rst:208 +#: ../source/specifications/core-metadata.rst:283 +#: ../source/specifications/core-metadata.rst:287 +#: ../source/specifications/core-metadata.rst:291 +#: ../source/specifications/core-metadata.rst:295 +#: ../source/specifications/core-metadata.rst:327 +#: ../source/specifications/core-metadata.rst:347 +#: ../source/specifications/core-metadata.rst:373 +#: ../source/specifications/core-metadata.rst:391 +#: ../source/specifications/core-metadata.rst:416 +#: ../source/specifications/core-metadata.rst:438 +#: ../source/specifications/core-metadata.rst:600 +#: ../source/specifications/core-metadata.rst:620 +#: ../source/specifications/core-metadata.rst:630 +msgid "Example::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:66 +msgid "Name" +msgstr "" + +#: ../source/specifications/core-metadata.rst:69 +msgid "Added additional restrictions on format from :pep:`508`" +msgstr "" + +#: ../source/specifications/core-metadata.rst:72 +msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:88 +msgid "Version" +msgstr "" + +#: ../source/specifications/core-metadata.rst:92 +msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:101 +msgid "Dynamic (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:105 +msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." +msgstr "" + +#: ../source/specifications/core-metadata.rst:108 +msgid "When found in the metadata of a source distribution, the following rules apply:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:111 +msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." +msgstr "" + +#: ../source/specifications/core-metadata.rst:115 +msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:118 +msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:122 +msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." +msgstr "" + +#: ../source/specifications/core-metadata.rst:127 +msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:131 +msgid "Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:135 +msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." +msgstr "" + +#: ../source/specifications/core-metadata.rst:146 +msgid "Supported-Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:150 +msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." +msgstr "" + +#: ../source/specifications/core-metadata.rst:164 +msgid "Summary" +msgstr "" + +#: ../source/specifications/core-metadata.rst:168 +msgid "A one-line summary of what the distribution does." +msgstr "" + +#: ../source/specifications/core-metadata.rst:188 +msgid "This field may be specified in the message body instead." +msgstr "" + +#: ../source/specifications/core-metadata.rst:191 +msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:196 +msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." +msgstr "" + +#: ../source/specifications/core-metadata.rst:202 +msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:219 +msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." +msgstr "" + +#: ../source/specifications/core-metadata.rst:223 +msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:232 +msgid "Description-Content-Type" +msgstr "" + +#: ../source/specifications/core-metadata.rst:236 +msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:239 +msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." +msgstr "" + +#: ../source/specifications/core-metadata.rst:253 +msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:259 +msgid "Format::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:263 +msgid "The ``type/subtype`` part has only a few legal values:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:265 +msgid "``text/plain``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:266 +msgid "``text/x-rst``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:267 +msgid "``text/markdown``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:269 +msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:273 +msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:278 +msgid "``GFM`` for `Github-flavored Markdown `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:280 +msgid "``CommonMark`` for `CommonMark `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:299 +msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." +msgstr "" + +#: ../source/specifications/core-metadata.rst:303 +msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:307 +msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:311 +msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." +msgstr "" + +#: ../source/specifications/core-metadata.rst:320 +msgid "Keywords" +msgstr "" + +#: ../source/specifications/core-metadata.rst:324 +msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." +msgstr "" + +#: ../source/specifications/core-metadata.rst:333 +msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." +msgstr "" + +#: ../source/specifications/core-metadata.rst:341 +msgid "Home-page" +msgstr "" + +#: ../source/specifications/core-metadata.rst:345 +msgid "A string containing the URL for the distribution's home page." +msgstr "" + +#: ../source/specifications/core-metadata.rst:353 +msgid "Download-URL" +msgstr "" + +#: ../source/specifications/core-metadata.rst:357 +msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:366 +msgid "Author" +msgstr "" + +#: ../source/specifications/core-metadata.rst:370 +msgid "A string containing the author's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:383 +msgid "Author-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:387 +msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:395 +#: ../source/specifications/core-metadata.rst:442 +msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:405 +msgid "Maintainer" +msgstr "" + +#: ../source/specifications/core-metadata.rst:409 +msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:412 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:426 +msgid "Maintainer-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:430 +msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:434 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:452 +msgid "License" +msgstr "" + +#: ../source/specifications/core-metadata.rst:456 +msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." +msgstr "" + +#: ../source/specifications/core-metadata.rst:476 +msgid "Classifier (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:480 +msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:485 +#: ../source/specifications/core-metadata.rst:574 +#: ../source/specifications/core-metadata.rst:691 +#: ../source/specifications/core-metadata.rst:715 +msgid "This field may be followed by an environment marker after a semicolon." +msgstr "" + +#: ../source/specifications/core-metadata.rst:496 +msgid "Requires-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:499 +#: ../source/specifications/core-metadata.rst:561 +#: ../source/specifications/core-metadata.rst:663 +#: ../source/specifications/core-metadata.rst:704 +msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." +msgstr "" + +#: ../source/specifications/core-metadata.rst:503 +msgid "Each entry contains a string naming some other distutils project required by this distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:506 +msgid "The format of a requirement string contains from one to four parts:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:508 +msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." +msgstr "" + +#: ../source/specifications/core-metadata.rst:510 +msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." +msgstr "" + +#: ../source/specifications/core-metadata.rst:513 +msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:516 +msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." +msgstr "" + +#: ../source/specifications/core-metadata.rst:519 +msgid "See :pep:`508` for full details of the allowed format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:521 +msgid "The project names should correspond to names as found on the `Python Package Index`_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:524 +msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:538 +msgid "Requires-Python" +msgstr "" + +#: ../source/specifications/core-metadata.rst:542 +msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." +msgstr "" + +#: ../source/specifications/core-metadata.rst:546 +msgid "The value must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:548 +msgid "This field cannot be followed by an environment marker." +msgstr "" + +#: ../source/specifications/core-metadata.rst:558 +msgid "Requires-External (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:565 +msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:570 +msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:576 +msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." +msgstr "" + +#: ../source/specifications/core-metadata.rst:581 +msgid "Notice that there is no particular rule on the strings to be used." +msgstr "" + +#: ../source/specifications/core-metadata.rst:593 +msgid "Project-URL (multiple-use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:597 +msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." +msgstr "" + +#: ../source/specifications/core-metadata.rst:604 +msgid "The label is free text limited to 32 characters." +msgstr "" + +#: ../source/specifications/core-metadata.rst:612 +msgid "Provides-Extra (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:616 +msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." +msgstr "" + +#: ../source/specifications/core-metadata.rst:625 +msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:635 +msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." +msgstr "" + +#: ../source/specifications/core-metadata.rst:639 +msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:644 +msgid "Rarely Used Fields" +msgstr "" + +#: ../source/specifications/core-metadata.rst:646 +msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:651 +msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." +msgstr "" + +#: ../source/specifications/core-metadata.rst:660 +msgid "Provides-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:667 +msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:672 +msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:679 +msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:687 +msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." +msgstr "" + +#: ../source/specifications/core-metadata.rst:701 +msgid "Obsoletes-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:708 +msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." +msgstr "" + +#: ../source/specifications/core-metadata.rst:712 +msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:717 +msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:730 +msgid "reStructuredText markup: http://docutils.sourceforge.net/" +msgstr "" + +#: ../source/specifications/core-metadata.rst:735 +msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:6 +msgid "Declaring build system dependencies" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:8 +msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:5 +msgid "Declaring project metadata" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:7 +msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:12 +msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:18 +msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:27 +msgid "The only fields required to be statically defined are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:29 +#: ../source/specifications/declaring-project-metadata.rst:41 +msgid "``name``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:31 +msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:34 +#: ../source/specifications/declaring-project-metadata.rst:54 +msgid "``version``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:36 +msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:43 +#: ../source/specifications/declaring-project-metadata.rst:56 +#: ../source/specifications/declaring-project-metadata.rst:68 +#: ../source/specifications/declaring-project-metadata.rst:117 +msgid "TOML_ type: string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:44 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:47 +msgid "The name of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:49 +msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:57 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:60 +msgid "The version of the project as supported by :pep:`440`." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:62 +msgid "Users SHOULD prefer to specify already-normalized versions." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:66 +msgid "``description``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:69 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:72 +msgid "The summary description of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:76 +msgid "``readme``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:78 +msgid "TOML_ type: string or table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:79 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:83 +msgid "The full description of the project (i.e. the README)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:85 +msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:96 +msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:103 +msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:115 +msgid "``requires-python``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:118 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:121 +msgid "The Python version requirements of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:125 +msgid "``license``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:127 +msgid "TOML_ type: table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:128 +msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:131 +msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:140 +msgid "``authors``/``maintainers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:142 +msgid "TOML_ type: Array of inline tables with string keys and values" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:143 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:149 +msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:154 +msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:157 +msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:163 +msgid "Using the data to fill in :ref:`core metadata ` is as follows:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:166 +msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:169 +msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:173 +msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:177 +msgid "Multiple values should be separated by commas." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:181 +msgid "``keywords``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:183 +#: ../source/specifications/declaring-project-metadata.rst:193 +msgid "TOML_ type: array of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:184 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:187 +msgid "The keywords for the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:191 +msgid "``classifiers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:194 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:197 +msgid "Trove classifiers which apply to the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:201 +msgid "``urls``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:203 +msgid "TOML_ type: table with keys and values of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:204 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:207 +msgid "A table of URLs where the key is the URL label and the value is the URL itself." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:212 +msgid "Entry points" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:214 +msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:216 +msgid ":ref:`Entry points specification `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:218 +msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:224 +msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:228 +msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:234 +msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:242 +msgid "``dependencies``/``optional-dependencies``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:244 +msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:247 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:251 +msgid "The (optional) dependencies of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:253 +msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:258 +msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:269 +msgid "``dynamic``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:271 +msgid "TOML_ type: array of string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:272 +msgid "A corresponding :ref:`core metadata ` field does not exist" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:275 +msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:281 +msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:283 +msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:285 +msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:290 +msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:294 +msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:296 +msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:300 +msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:6 +msgid "Dependency specifiers" +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:8 +msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:11 +msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." +msgstr "" + +#: ../source/specifications/direct-url.rst:6 +msgid "Recording the Direct URL Origin of installed distributions" +msgstr "" + +#: ../source/specifications/direct-url.rst:8 +msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." +msgstr "" + +#: ../source/specifications/direct-url.rst:17 +msgid "Specification" +msgstr "" + +#: ../source/specifications/direct-url.rst:19 +msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/direct-url.rst:23 +#: ../source/specifications/recording-installed-packages.rst:206 +msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." +msgstr "" + +#: ../source/specifications/direct-url.rst:26 +msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." +msgstr "" + +#: ../source/specifications/direct-url.rst:29 +msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." +msgstr "" + +#: ../source/specifications/direct-url.rst:36 +msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." +msgstr "" + +#: ../source/specifications/direct-url.rst:39 +msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" +msgstr "" + +#: ../source/specifications/direct-url.rst:45 +msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." +msgstr "" + +#: ../source/specifications/direct-url.rst:49 +msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" +msgstr "" + +#: ../source/specifications/direct-url.rst:52 +msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." +msgstr "" + +#: ../source/specifications/direct-url.rst:58 +msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." +msgstr "" + +#: ../source/specifications/direct-url.rst:61 +msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." +msgstr "" + +#: ../source/specifications/direct-url.rst:68 +msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:71 +msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." +msgstr "" + +#: ../source/specifications/direct-url.rst:78 +msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:81 +msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." +msgstr "" + +#: ../source/specifications/direct-url.rst:84 +msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." +msgstr "" + +#: ../source/specifications/direct-url.rst:91 +msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." +msgstr "" + +#: ../source/specifications/direct-url.rst:96 +msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." +msgstr "" + +#: ../source/specifications/direct-url.rst:102 +msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." +msgstr "" + +#: ../source/specifications/direct-url.rst:110 +msgid "Registered VCS" +msgstr "" + +#: ../source/specifications/direct-url.rst:112 +msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." +msgstr "" + +#: ../source/specifications/direct-url.rst:122 +msgid "Git" +msgstr "" + +#: ../source/specifications/direct-url.rst:124 +#: ../source/specifications/direct-url.rst:156 +#: ../source/specifications/direct-url.rst:179 +#: ../source/specifications/direct-url.rst:202 +msgid "Home page" +msgstr "" + +#: ../source/specifications/direct-url.rst:126 +msgid "https://git-scm.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:128 +#: ../source/specifications/direct-url.rst:160 +#: ../source/specifications/direct-url.rst:183 +#: ../source/specifications/direct-url.rst:206 +msgid "vcs command" +msgstr "" + +#: ../source/specifications/direct-url.rst:130 +#: ../source/specifications/direct-url.rst:134 +msgid "git" +msgstr "" + +#: ../source/specifications/direct-url.rst:132 +#: ../source/specifications/direct-url.rst:164 +#: ../source/specifications/direct-url.rst:187 +#: ../source/specifications/direct-url.rst:210 +msgid "``vcs`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:136 +#: ../source/specifications/direct-url.rst:168 +#: ../source/specifications/direct-url.rst:191 +#: ../source/specifications/direct-url.rst:214 +msgid "``requested_revision`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:138 +msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." +msgstr "" + +#: ../source/specifications/direct-url.rst:141 +#: ../source/specifications/direct-url.rst:172 +#: ../source/specifications/direct-url.rst:195 +#: ../source/specifications/direct-url.rst:219 +msgid "``commit_id`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:143 +msgid "A commit hash (40 hexadecimal characters sha1)." +msgstr "" + +#: ../source/specifications/direct-url.rst:147 +msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." +msgstr "" + +#: ../source/specifications/direct-url.rst:154 +msgid "Mercurial" +msgstr "" + +#: ../source/specifications/direct-url.rst:158 +msgid "https://www.mercurial-scm.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:162 +#: ../source/specifications/direct-url.rst:166 +msgid "hg" +msgstr "" + +#: ../source/specifications/direct-url.rst:170 +msgid "A tag name, branch name, changeset ID, shortened changeset ID." +msgstr "" + +#: ../source/specifications/direct-url.rst:174 +msgid "A changeset ID (40 hexadecimal characters)." +msgstr "" + +#: ../source/specifications/direct-url.rst:177 +msgid "Bazaar" +msgstr "" + +#: ../source/specifications/direct-url.rst:181 +msgid "https://bazaar.canonical.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:185 +#: ../source/specifications/direct-url.rst:189 +msgid "bzr" +msgstr "" + +#: ../source/specifications/direct-url.rst:193 +msgid "A tag name, branch name, revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:197 +msgid "A revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:200 +msgid "Subversion" +msgstr "" + +#: ../source/specifications/direct-url.rst:204 +msgid "https://subversion.apache.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:208 +#: ../source/specifications/direct-url.rst:212 +msgid "svn" +msgstr "" + +#: ../source/specifications/direct-url.rst:216 +msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." +msgstr "" + +#: ../source/specifications/direct-url.rst:221 +msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." +msgstr "" + +#: ../source/specifications/direct-url.rst:229 +msgid "Example direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:231 +msgid "Source archive:" +msgstr "" + +#: ../source/specifications/direct-url.rst:242 +msgid "Git URL with tag and commit-hash:" +msgstr "" + +#: ../source/specifications/direct-url.rst:255 +msgid "Local directory:" +msgstr "" + +#: ../source/specifications/direct-url.rst:264 +msgid "Local directory installed in editable mode:" +msgstr "" + +#: ../source/specifications/direct-url.rst:277 +msgid "Example pip commands and their effect on direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:279 +msgid "Commands that generate a ``direct_url.json``:" +msgstr "" + +#: ../source/specifications/direct-url.rst:281 +msgid "pip install https://example.com/app-1.0.tgz" +msgstr "" + +#: ../source/specifications/direct-url.rst:282 +msgid "pip install https://example.com/app-1.0.whl" +msgstr "" + +#: ../source/specifications/direct-url.rst:283 +msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" +msgstr "" + +#: ../source/specifications/direct-url.rst:284 +msgid "pip install ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:285 +msgid "pip install file:///home/user/app" +msgstr "" + +#: ../source/specifications/direct-url.rst:286 +msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" +msgstr "" + +#: ../source/specifications/direct-url.rst:290 +msgid "pip install -e ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:292 +msgid "Commands that *do not* generate a ``direct_url.json``" +msgstr "" + +#: ../source/specifications/direct-url.rst:294 +msgid "pip install app" +msgstr "" + +#: ../source/specifications/direct-url.rst:295 +msgid "pip install app --no-index --find-links https://example.com/" +msgstr "" + +#: ../source/specifications/entry-points.rst:5 +msgid "Entry points specification" +msgstr "" + +#: ../source/specifications/entry-points.rst:7 +msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" +msgstr "" + +#: ../source/specifications/entry-points.rst:11 +msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." +msgstr "" + +#: ../source/specifications/entry-points.rst:14 +msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." +msgstr "" + +#: ../source/specifications/entry-points.rst:19 +msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." +msgstr "" + +#: ../source/specifications/entry-points.rst:28 +msgid "Data model" +msgstr "" + +#: ../source/specifications/entry-points.rst:30 +msgid "Conceptually, an entry point is defined by three required properties:" +msgstr "" + +#: ../source/specifications/entry-points.rst:32 +msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:42 +msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:51 +msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:64 +msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." +msgstr "" + +#: ../source/specifications/entry-points.rst:68 +msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." +msgstr "" + +#: ../source/specifications/entry-points.rst:73 +msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." +msgstr "" + +#: ../source/specifications/entry-points.rst:80 +msgid "File format" +msgstr "" + +#: ../source/specifications/entry-points.rst:82 +msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." +msgstr "" + +#: ../source/specifications/entry-points.rst:87 +msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:97 +msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:100 +msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." +msgstr "" + +#: ../source/specifications/entry-points.rst:104 +msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." +msgstr "" + +#: ../source/specifications/entry-points.rst:112 +msgid "For example::" +msgstr "" + +#: ../source/specifications/entry-points.rst:124 +msgid "Use for scripts" +msgstr "" + +#: ../source/specifications/entry-points.rst:126 +msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." +msgstr "" + +#: ../source/specifications/entry-points.rst:134 +msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:141 +msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." +msgstr "" + +#: ../source/specifications/entry-points.rst:149 +msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." +msgstr "" + +#: ../source/specifications/entry-points.rst:154 +msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." +msgstr "" + +#: ../source/specifications/index.rst:4 +msgid "PyPA specifications" +msgstr "" + +#: ../source/specifications/index.rst:6 +msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." +msgstr "" + +#: ../source/specifications/index.rst:13 +msgid "Package Distribution Metadata" +msgstr "" + +#: ../source/specifications/index.rst:30 +msgid "Package Distribution File Formats" +msgstr "" + +#: ../source/specifications/index.rst:40 +msgid "Package Index Interfaces" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:6 +msgid "Platform compatibility tags" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:8 +msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:12 +msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:16 +msgid "Platform tags for Windows" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:18 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:22 +msgid "Platform tags for macOS (Mac OS X)" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:24 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:28 +msgid "Platform tags for common Linux distributions" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:32 +msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:36 +msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:41 +msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:44 +msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:46 +msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:49 +msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:54 +msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:59 +msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:65 +msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:71 +msgid "Manylinux compatibility support" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:74 +msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:76 +msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:79 +msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "Tool" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux1``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2010``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2014``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux_x_y``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=8.1.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=20.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "auditwheel" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=1.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=2.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.3.0`` [#]_" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:90 +msgid "Platform tags for other \\*nix platforms" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:92 +msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:98 +msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" +msgstr "" + +#: ../source/specifications/pypirc.rst:6 +msgid "The :file:`.pypirc` file" +msgstr "" + +#: ../source/specifications/pypirc.rst:8 +msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." +msgstr "" + +#: ../source/specifications/pypirc.rst:13 +msgid "The format (originally defined by the :ref:`distutils` package) is:" +msgstr "" + +#: ../source/specifications/pypirc.rst:32 +msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:35 +msgid "Each section describing a repository defines three fields:" +msgstr "" + +#: ../source/specifications/pypirc.rst:37 +msgid "``repository``: The URL of the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:38 +msgid "``username``: The registered username on the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:39 +msgid "``password``: The password that will used to authenticate the username." +msgstr "" + +#: ../source/specifications/pypirc.rst:43 +msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." +msgstr "" + +#: ../source/specifications/pypirc.rst:47 +msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" +msgstr "" + +#: ../source/specifications/pypirc.rst:57 +msgid "Common configurations" +msgstr "" + +#: ../source/specifications/pypirc.rst:61 +msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." +msgstr "" + +#: ../source/specifications/pypirc.rst:66 +msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" +msgstr "" + +#: ../source/specifications/pypirc.rst:82 +msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." +msgstr "" + +#: ../source/specifications/pypirc.rst:86 +msgid "Using a PyPI token" +msgstr "" + +#: ../source/specifications/pypirc.rst:88 +msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" +msgstr "" + +#: ../source/specifications/pypirc.rst:97 +msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." +msgstr "" + +#: ../source/specifications/pypirc.rst:103 +msgid "Using another package index" +msgstr "" + +#: ../source/specifications/pypirc.rst:105 +msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" +msgstr "" + +#: ../source/specifications/pypirc.rst:132 +msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:5 +msgid "Recording installed projects" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:7 +msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:12 +msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:21 +msgid "History and change workflow" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:23 +msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:29 +msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:37 +msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:41 +msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:50 +msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:60 +msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:69 +msgid "This ``.dist-info`` directory can contain these files, described in detail below:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:72 +msgid "``METADATA``: contains project metadata" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:73 +msgid "``RECORD``: records the list of installed files." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:74 +msgid "``INSTALLER``: records the name of the tool used to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:76 +msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:82 +msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:87 +msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:94 +msgid "The METADATA file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:96 +msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:99 +msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:105 +msgid "The RECORD file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:107 +msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:110 +msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:113 +msgid "field delimiter: ``,`` (comma)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:114 +msgid "quoting char: ``\"`` (straight double quote)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:115 +msgid "line terminator: either ``\\r\\n`` or ``\\n``." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:117 +msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:120 +msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:125 +msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:130 +msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:133 +msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:139 +msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:146 +msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:151 +msgid "Here is an example snippet of a possible ``RECORD`` file::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:170 +msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:177 +msgid "The INSTALLER file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:179 +msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:185 +msgid "The file can be terminated by zero or more ASCII whitespace characters." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:187 +msgid "Here are examples of two possible ``INSTALLER`` files::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:195 +msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:201 +msgid "The direct_url.json file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:203 +msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:209 +msgid "Its detailed specification is at :ref:`direct-url`." +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:6 +msgid "Simple repository API" +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:8 +msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:6 +msgid "Source distribution format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:8 +msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:13 +msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:21 +msgid "Source distributions are also known as *sdists* for short." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:24 +msgid "Source distribution file name" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:26 +msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:31 +msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:35 +msgid "Source distribution file format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:37 +msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:45 +msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:48 +msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:6 +msgid "Version specifiers" +msgstr "" + +#: ../source/specifications/version-specifiers.rst:8 +msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:11 +msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." +msgstr "" + +#: ../source/support.rst:3 +msgid "How to Get Support" +msgstr "" + +#: ../source/support.rst:5 +msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." +msgstr "" + +#: ../source/support.rst:8 +msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:5 +msgid "Creating Documentation" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:7 +msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:13 +msgid "Installing Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:14 +msgid "Use ``pip`` to install Sphinx:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:28 +msgid "For other installation methods, see this `installation guide`_ by Sphinx." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:33 +msgid "Getting Started With Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:35 +msgid "Create a ``docs`` directory inside your project to hold your documentation:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:42 +msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:49 +msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:51 +msgid "You can add some information about your project in ``index.rst``, then build them:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:57 +msgid "For more details on the build process, see this `guide`_ by Read The Docs." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:62 +msgid "Other Sources" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:64 +msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/index.rst:4 +msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:5 +msgid "Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:7 +msgid "This section covers the basics of how to install Python :term:`packages `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:10 +msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:28 +msgid "Requirements for Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:30 +msgid "This section describes the steps to follow before installing other Python packages." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:35 +msgid "Ensure you can run Python from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:37 +msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:53 +msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:57 +msgid "If you're a newcomer and you get an error like this:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:66 +msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:72 +msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:82 +msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:87 +msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:99 +msgid "Ensure you can run pip from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:101 +msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:116 +msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:124 +msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:139 +msgid "If that still doesn't allow you to run ``python -m pip``:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:141 +msgid "Securely Download `get-pip.py `_ [1]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:144 +msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:150 +msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:159 +msgid "Ensure pip, setuptools, and wheel are up to date" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:161 +msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:169 +msgid "Optionally, create a virtual environment" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:171 +msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:188 +msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:195 +msgid "Creating Virtual Environments" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:197 +msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:203 +msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:209 +msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:213 +msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:216 +msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:220 +msgid "Currently, there are two common tools for creating Python virtual environments:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:222 +msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:225 +msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:230 +msgid "The basic usage is like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:232 +msgid "Using `venv`_:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:248 +msgid "Using :ref:`virtualenv`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:264 +msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:266 +msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:271 +msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:281 +msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:288 +msgid "Use pip for Installing" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:290 +msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:297 +msgid "Installing from PyPI" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:299 +msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:307 +msgid "To install the latest version of \"SomeProject\":" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:321 +msgid "To install a specific version:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:335 +msgid "To install greater than or equal to one version and less than another:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:350 +msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:365 +msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:370 +msgid "Source Distributions vs Wheels" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:372 +msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:378 +msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:383 +msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:391 +msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:408 +msgid "Installing to the User Site" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:410 +msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:425 +msgid "For more information see the `User Installs `_ section from the pip docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:429 +msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:432 +msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:440 +msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:446 +msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:462 +msgid "Install a list of requirements specified in a :ref:`Requirements File `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:478 +msgid "Installing from VCS" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:480 +msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:502 +msgid "Installing from other Indexes" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:504 +msgid "Install from an alternate index" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:518 +msgid "Search an additional index during install, in addition to :term:`PyPI `" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:534 +msgid "Installing from a local src tree" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:537 +msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:554 +msgid "You can also install normally from src" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:571 +msgid "Install a particular source archive file." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:585 +msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:605 +msgid "Installing from other sources" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:607 +msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:619 +msgid "Installing Prereleases" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:621 +msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:637 +msgid "Installing Setuptools \"Extras\"" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:639 +msgid "Install `setuptools extras`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:659 +msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:668 +msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:673 +msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:4 +msgid "Managing Application Dependencies" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:6 +msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:9 +msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:13 +msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:17 +msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:24 +msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:30 +msgid "Installing Pipenv" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:32 +msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:38 +msgid "Use ``pip`` to install Pipenv:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:54 +msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:65 +msgid "Installing packages for your project" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:67 +msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:76 +msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:112 +msgid "Using installed packages" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:114 +msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:125 +msgid "Then you can run this script using ``pipenv run``:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:131 +msgid "You should get output similar to this:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:137 +msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:143 +#: ../source/tutorials/packaging-projects.rst:594 +msgid "Next steps" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:145 +msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:148 +msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:151 +msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:160 +msgid "Other Tools for Application Dependency Management" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:162 +msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:166 +msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:172 +msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:175 +msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:177 +msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:2 +msgid "Packaging Python Projects" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:4 +msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:10 +msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:18 +msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:35 +msgid "A simple project" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:37 +msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:41 +msgid "Create the following file structure locally:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:51 +msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:54 +msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:63 +msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:67 +msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:75 +msgid "Creating the package files" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:77 +msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:95 +msgid "Creating a test directory" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:97 +msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:101 +msgid "Creating pyproject.toml" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:103 +msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:117 +msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:121 +msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:127 +msgid "See :pep:`517` and :pep:`518` for background and details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:131 +msgid "Configuring metadata" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:133 +msgid "There are two types of metadata: static and dynamic." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:135 +msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:137 +msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:141 +msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:148 +msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:153 +msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:185 +msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:191 +#: ../source/tutorials/packaging-projects.rst:286 +msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:196 +msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:199 +#: ../source/tutorials/packaging-projects.rst:293 +msgid "``author`` and ``author_email`` are used to identify the author of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:201 +#: ../source/tutorials/packaging-projects.rst:295 +msgid "``description`` is a short, one-sentence summary of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:202 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:206 +#: ../source/tutorials/packaging-projects.rst:300 +msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:208 +#: ../source/tutorials/packaging-projects.rst:302 +msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:211 +#: ../source/tutorials/packaging-projects.rst:305 +msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:213 +#: ../source/tutorials/packaging-projects.rst:307 +msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:221 +msgid "In the ``options`` category, we have controls for setuptools itself:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:223 +msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:227 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:234 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:238 +#: ../source/tutorials/packaging-projects.rst:329 +msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:244 +msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:248 +msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:283 +msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:291 +msgid "``version`` is the package version. See :pep:`440` for more details on versions." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:296 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:314 +msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:319 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:325 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:333 +msgid "Creating README.md" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:335 +msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:347 +msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:354 +msgid "Creating a LICENSE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:356 +msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:387 +msgid "Including other files" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:389 +msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:393 +msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:402 +msgid "Generating distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:404 +msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:408 +msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:422 +msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:425 +msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:439 +msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:449 +msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:458 +msgid "Uploading the distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:460 +msgid "Finally, it's time to upload your package to the Python Package Index!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:462 +msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:470 +msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:477 +msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:492 +msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:506 +msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:510 +msgid "After the command completes, you should see output similar to this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:523 +msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:528 +msgid "Installing your newly uploaded package" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:530 +msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:546 +msgid "Make sure to specify your username in the package name!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:548 +msgid "pip should install the package from TestPyPI and the output should look something like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:558 +msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:565 +msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:580 +msgid "and import the package:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:588 +msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:596 +msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:599 +msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:604 +msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:608 +msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:610 +msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:613 +msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:617 +msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:619 +msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:622 +msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:624 +msgid "Read about :doc:`/guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:625 +msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." +msgstr "" From 2293987ca2c1151b16b2ea7a2654c1a4881c29c9 Mon Sep 17 00:00:00 2001 From: moto kawasaki Date: Tue, 23 Nov 2021 15:41:10 +0100 Subject: [PATCH 0191/1072] Translated using Weblate (Japanese) Currently translated at 11.5% (262 of 2271 strings) Translated using Weblate (Japanese) Currently translated at 4.3% (98 of 2271 strings) Added translation using Weblate (Japanese) Co-authored-by: moto kawasaki Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/ja/ Translation: pypa/packaging.python.org --- locales/ja/LC_MESSAGES/messages.po | 9475 ++++++++++++++++++++++++++++ 1 file changed, 9475 insertions(+) create mode 100644 locales/ja/LC_MESSAGES/messages.po diff --git a/locales/ja/LC_MESSAGES/messages.po b/locales/ja/LC_MESSAGES/messages.po new file mode 100644 index 000000000..1702920c2 --- /dev/null +++ b/locales/ja/LC_MESSAGES/messages.po @@ -0,0 +1,9475 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2013–2020, PyPA +# This file is distributed under the same license as the Python Packaging User Guide package. +# moto kawasaki , 2021. +msgid "" +msgstr "" +"Project-Id-Version: Python Packaging User Guide\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2021-07-06 19:32+0800\n" +"PO-Revision-Date: 2021-11-22 17:23+0000\n" +"Last-Translator: moto kawasaki \n" +"Language-Team: Japanese \n" +"Language: ja\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=1; plural=0;\n" +"X-Generator: Weblate 4.10-dev\n" + +#: ../source/contribute.rst:5 +msgid "Contribute to this guide" +msgstr "このガイドに貢献するには" + +#: ../source/contribute.rst:7 +msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" +msgstr "|PyPUG|は貢献者を歓迎します！さまざまな貢献方法があります。例えば：" + +#: ../source/contribute.rst:10 +msgid "Reading the guide and giving feedback" +msgstr "このガイドを読んでフィードバックを伝えること" + +#: ../source/contribute.rst:11 +msgid "Reviewing new contributions" +msgstr "新しい貢献文書を査読すること" + +#: ../source/contribute.rst:12 +msgid "Revising existing content" +msgstr "既存の文書を修正すること" + +#: ../source/contribute.rst:13 +msgid "Writing new content" +msgstr "新しく文書を書くこと" + +#: ../source/contribute.rst:15 +msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." +msgstr "" +"|PyPUG|のほとんどの作業は`プロジェクトのGitHubリポジトリ `__で行われます。手始めに`未解決の問題 `__のリストをチェックアウトして(改善策の)`" +"プルリクエスト `__を送ってください。もしあなたがこのガイドに何かを書き加えたり編集したりするつもりなら、:ref:`" +"スタイルガイド `__を読みましょう。" + +#: ../source/contribute.rst:24 +msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." +msgstr "|PyPUG|に貢献を行うのであれば、あなたがPSFの`行動規範 `__に従うことが期待されています。" + +#: ../source/contribute.rst:31 +msgid "Documentation types" +msgstr "文書の類型" + +#: ../source/contribute.rst:33 +msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." +msgstr "" +"本プロジェクトは、特定の目的に合わせた四つの別個の文書類型で成り立っています。新たに追加することを提案する場合には、いずれかの適切な文書類型を選択してくだ" +"さい。" + +#: ../source/contribute.rst:38 +#: ../source/tutorials/index.rst:2 +msgid "Tutorials" +msgstr "チュートリアル型文書" + +#: ../source/contribute.rst:40 +msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." +msgstr "" +"チュートリアルは目標を達成することで読者に新しい概念を教えることに注力しています。こうするべきだという意見に従ったステップバイステップのガイドになっていま" +"す。大筋に無関係な警告や情報は省略されています。`チュートリアル型文書の例 `_." + +#: ../source/contribute.rst:47 +#: ../source/guides/index.rst:2 +msgid "Guides" +msgstr "ガイド型文書" + +#: ../source/contribute.rst:49 +msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." +msgstr "" +"ガイドは特定のタスクを達成することに力点を置いていて、前提となる知識のレベルをある程度仮定することができます。ガイドはチュートリアルと似ていますが、しかし" +"ガイドはもっと狭い分野に明確に焦点を当てるものであり、必要に応じて多数の注意書きを行ったり追加的な情報を盛り込んだりすることができます。ガイドでは、そのタ" +"スクを達成するための複数のやり方を議論することもできます。:doc:`ガイド型文書の例 `." + +#: ../source/contribute.rst:56 +#: ../source/discussions/index.rst:2 +msgid "Discussions" +msgstr "議論型文書" + +#: ../source/contribute.rst:58 +msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." +msgstr "" +"議論型文書では、理解促進と情報提供に重点を置きます。議論型文書では、特定のゴールを念頭に置くことなく、ある特定の話題について深く探求します。:doc:`" +"議論型文書の例 `." + +#: ../source/contribute.rst:63 +msgid "Specifications" +msgstr "仕様型文書" + +#: ../source/contribute.rst:65 +msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." +msgstr "" +"仕様型文書は、パッケージングツール間で相互運用のためのインターフェイスとして合意された事項について網羅的に文書化することに重点を置く参照用の文書です。:d" +"oc:`仕様型文書の例 `." + +#: ../source/contribute.rst:73 +msgid "Building the guide locally" +msgstr "この文書を手元でビルドするには" + +#: ../source/contribute.rst:75 +msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" +msgstr "" +"貢献寄与をするために必須というわけではありませんが、この文書を手元でビルドすることはあなたが行った変更をテストするのに役に立ちます。この文書を手元でビルド" +"するには：" + +#: ../source/contribute.rst:79 +msgid "`Nox `_. You can install or upgrade nox using ``pip``::" +msgstr "" +"`Nox `_. " +"noxは``pip``::を用いてインストールまたはアップグレードできます。" + +#: ../source/contribute.rst:84 +msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." +msgstr "" +"Python 3.6. 我々のビルドスクリプトはPython 3.6でのみ動作するように設計されている。あなたの使っているOSにPython " +"3.6をインストールする方法については `Hitchhiker's Guide to Python のインストールの手引き `_ を見てほしい。" + +#: ../source/contribute.rst:91 +msgid "To build the guide, run the following bash command in the source folder::" +msgstr "この文書をビルドするには、以下のbashコマンドをsourceディレクトリで実行してください。::" + +#: ../source/contribute.rst:95 +msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." +msgstr "" +"処理が終わると、``./build/html``の下にHTMLの出力ファイルが見つかるはずです。ここの``index." +"html``をブラウザで開くことでこの文書を閲覧することができますが、HTTPサーバを使って文書を提供する方がお勧めです。" + +#: ../source/contribute.rst:100 +msgid "You can build the guide and serve it via an HTTP server using the following command::" +msgstr "HTTPサーバを用いてこの文書を提供するには、以下のコマンドを使います。::" + +#: ../source/contribute.rst:105 +msgid "The guide will be browsable via http://localhost:8000." +msgstr "この文書は、http://localhost:8000から閲覧できます。" + +#: ../source/contribute.rst:109 +msgid "Where the guide is deployed" +msgstr "この文書が展開される場所" + +#: ../source/contribute.rst:111 +msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." +msgstr "" +"この文書はReadTheDocsを通じて展開されていて、https://readthedocs.org/projects/" +"python-packaging-user-guide/から読めるようになっています。また、Fast." +"lyから独自のドメイン名から提供されるようになっています(第二文はここだけでは意味が取れない)。" + +#: ../source/contribute.rst:117 +msgid "Style guide" +msgstr "スタイルガイド" + +#: ../source/contribute.rst:119 +msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." +msgstr "" +"このスタイルガイドは、あなたがどのように|PyPUG|を書くべきかについて推奨事項を与えます。あなたが書き始める前に目を通してください。スタイルガイドに従" +"うことであなたの貢献がまとまりのある全体の中の一部として追加され、あなたの貢献がプロジェクトによって受け入れられやすくなります。" + +#: ../source/contribute.rst:126 +msgid "Purpose" +msgstr "目的" + +#: ../source/contribute.rst:128 +msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." +msgstr "" +"|PyPUG|の目的は、現在のツール群を用いてPythonプロジェクトをパッケージし、公開し、インストールする方法に関して権威ある参照先となることです。" + +#: ../source/contribute.rst:133 +msgid "Scope" +msgstr "スコープ" + +#: ../source/contribute.rst:135 +msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." +msgstr "この文書は、正確で的を射た推奨事項を添えた形で疑問に答え問題を解決することを意図しています。" + +#: ../source/contribute.rst:138 +msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." +msgstr "" +"この文書は網羅的であることを目指してはおらず、それぞれのプロジェクトのドキュメントを置き換えることも意図していません。例えば、pipにはたくさんのコマンド" +"やオプションや設定事項があります。pipのドキュメントはその一つ一つについて詳細に記述していますが、この文書ではこの文書に記述されたタスクを完了するために" +"必要となる部分に限ってpipに触れています。" + +#: ../source/contribute.rst:146 +msgid "Audience" +msgstr "想定される読者" + +#: ../source/contribute.rst:148 +msgid "The audience of this guide is anyone who uses Python with packages." +msgstr "この文書の読者として想定されるのは、Pythonのパッケージを扱う方です。" + +#: ../source/contribute.rst:150 +msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." +msgstr "" +"Pythonコミュニティが巨大で温かいコミュニティであることを忘れないでください。読者は年齢・性別・教育程度・文化やその他諸々の点であなたと同じではないか" +"もしれませんが、しかし、あなたがあなたにできる限りパッケージングについて学ぶことを称賛します。" + +#: ../source/contribute.rst:154 +msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." +msgstr "" +"とりわけ、Pythonを使う人なら誰でも自分をプログラマーだと思っているというわけではないことを覚えておいてください。この文書の想定される読者には、ソフト" +"ウェア開発を職業としているプロだけでなく、宇宙飛行士や画家あるいは学生も含まれるのです。" + +#: ../source/contribute.rst:160 +msgid "Voice and tone" +msgstr "口調や語調" + +#: ../source/contribute.rst:162 +msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." +msgstr "この文書を書く時には、たとえあなたが答えを全部わかっていたとしても親しみやすく控えめな語調で書くように努力してください。" + +#: ../source/contribute.rst:165 +msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." +msgstr "" +"頭が良くてスキルのある人たちと一緒にPythonのプロジェクトをやるところを思い描いてください。あなたは彼らと働くのが好きだし、彼らもあなたと働くのが好き" +"なのです。そんな人があなたに質問をして、あなたが答えを知っていたとしましょう。あなたはどんな風に応対しますか？*それ*こそが、あなたがこの文書を書く時のや" +"り方なのです。" + +#: ../source/contribute.rst:170 +msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." +msgstr "" +"簡単な確認方法：あなたが書いたものを声に出して読めば、その口調や語調の感じがわかります。それはあなたが言いたかった感じに響きましたか、それとも、演説の一部" +"みたいに聞こえましたか？短縮形を使っても構いませんし、曖昧な文法規則に固執することはありません。あなたはここに、もしそうしたいのならば前置詞で文を終わって" +"も構わないと言う権限を与えられました。" + +#: ../source/contribute.rst:177 +msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." +msgstr "" +"ガイド文書を書くときは、論題の深刻さや難しさに合った語調に調整してください。もしあなたが入門篇のようなチュートリアルを書くときには冗談を挟んでも構いません" +"が、繊細な注意を必要とするセキュリティ上の推奨事項をカバーするなら冗談を全く入れないようにしたいと思うかもしれません。" + +#: ../source/contribute.rst:184 +msgid "Conventions and mechanics" +msgstr "慣例と手順" + +#: ../source/contribute.rst:192 +msgid "**Write to the reader**" +msgstr "**読者に向けて書く**" + +#: ../source/contribute.rst:187 +msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." +msgstr "推奨事項や実行すべきステップを与えるときは、読者に*あなた*と呼びかけるか、または、命令法を用いて欲しい。" + +#: ../source/contribute.rst:0 +msgid "Wrong: To install it, the user runs…" +msgstr "誤：それをインストールするために、ユーザは...を実行します。" + +#: ../source/contribute.rst:0 +msgid "Right: You can install it by running…" +msgstr "正：...を実行することであなたはそれをインストールすることができます。" + +#: ../source/contribute.rst:0 +msgid "Right: To install it, run…" +msgstr "正：それをインストールするには、...を実行してください。" + +#: ../source/contribute.rst:198 +msgid "**State assumptions**" +msgstr "**前提条件の明示**" + +#: ../source/contribute.rst:195 +msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." +msgstr "" +"暗黙のうちに前提条件を仮定することのないようにしましょう。Webページとして提供するということは、この文書のどのページであってもそれが読者にとっての初めて" +"のページになるかもしれないということです。" + +#: ../source/contribute.rst:203 +msgid "**Cross-reference generously**" +msgstr "**豊富な相互参照**" + +#: ../source/contribute.rst:201 +msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." +msgstr "" +"あるツールや行為にあなたが初めて言及するときには、ガイドのそれを説明している部分へのリンク、または、どこか他の場所であっても適切な説明文書へのリンクも提供" +"してください。" + +#: ../source/contribute.rst:213 +msgid "**Respect naming practices**" +msgstr "**命名慣習を尊重すること**" + +#: ../source/contribute.rst:206 +msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." +msgstr "ツールやサイト、登場人物や他の適切な名詞に名前を付けるときには、大文字小文字などそれぞれが好んで使っている書き方を尊重してください。" + +#: ../source/contribute.rst:0 +msgid "Wrong: Pip uses…" +msgstr "誤：Pipは…" + +#: ../source/contribute.rst:0 +msgid "Right: pip uses…" +msgstr "正：pipは…" + +#: ../source/contribute.rst:0 +msgid "Wrong: …hosted on github." +msgstr "誤：...はgithubにホストされている。" + +#: ../source/contribute.rst:0 +msgid "Right: …hosted on GitHub." +msgstr "正：...はGitHubにホストされている。" + +#: ../source/contribute.rst:222 +msgid "**Use a gender-neutral style**" +msgstr "**ジェンダー中立なスタイルを使う**" + +#: ../source/contribute.rst:216 +msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." +msgstr "" +"あなたが読者に直接呼びかけるときは「あなた」「あなたの」「あなたのもの」を使ってください。そうできない場合は代名詞として「彼ら」「彼らの」「彼らのもの」を" +"使う(訳註：従来なら\"he\", \"she\"を用いた場所に\"they\"を使うことでジェンダーへの配慮を示す場合がある" +")か、または、代名詞をまったく使わないようにしましょう。" + +#: ../source/contribute.rst:0 +msgid "Wrong: A maintainer uploads the file. Then he…" +msgstr "誤：メンテナンス担当者がファイルをアップロードする。それから、彼は…" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then they…" +msgstr "正：メンテナンス担当者がファイルをアップロードする。それから、彼らは…" + +#: ../source/contribute.rst:0 +msgid "Right: A maintainer uploads the file. Then the maintainer…" +msgstr "正：メンテナンス担当者がファイルをアップロードする。それから、メンテナンス担当者は…" + +#: ../source/contribute.rst:234 +msgid "**Headings**" +msgstr "**見出しの付け方**" + +#: ../source/contribute.rst:225 +msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." +msgstr "" +"見出しには読者が検索で使うような単語を使いましょう。質問の意図に答える形で見出しを書くのは良い方法です。読者が例えば*MyLibraryをインストールする" +"にはどうすれば良いの？*ということを知りたいとすれば、適切な見出しとしては*MyLibraryをインストールするには*のようになるでしょう。" + +#: ../source/contribute.rst:230 +msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." +msgstr "見出し部分では通常の文章のように大文字小文字を使いましょう。言い換えるなら、ごく普通の文を書く時のように見出しを書きましょう。" + +#: ../source/contribute.rst:0 +msgid "Wrong: Things You Should Know About Python" +msgstr "誤：Pythonについてあなたが知っておくべき事柄 (訳註：日本語には大文字小文字の区別がないので誤例にならないのではないか)" + +#: ../source/contribute.rst:0 +msgid "Right: Things you should know about Python" +msgstr "正：Pythonについてあなたが知っておくべき事柄" + +#: ../source/contribute.rst:237 +msgid "**Numbers**" +msgstr "**数値の書き方**" + +#: ../source/contribute.rst:237 +msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." +msgstr "" +"地の文では一から九までの数字を単語で書きましょう(訳註：日本語では漢数字にするよりもアラビア数字の方が適切かもしれません)。表の中ではアラビア数字で書きま" +"しょう。" + +#: ../source/discussions/deploying-python-applications.rst:4 +msgid "Deploying Python applications" +msgstr "Pythonで書かれたアプリケーションを配置(deploy)する" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Page Status" +msgstr "ページステイタス" + +#: ../source/discussions/deploying-python-applications.rst:6 +#: ../source/guides/index-mirrors-and-caches.rst:7 +#: ../source/guides/installing-using-linux-tools.rst:7 +#: ../source/guides/packaging-binary-extensions.rst:7 +#: ../source/guides/supporting-multiple-python-versions.rst:7 +#: ../source/guides/supporting-windows-using-appveyor.rst:5 +msgid "Incomplete" +msgstr "未完了" + +#: ../source/discussions/deploying-python-applications.rst:0 +#: ../source/guides/index-mirrors-and-caches.rst:0 +#: ../source/guides/installing-using-linux-tools.rst:0 +#: ../source/guides/packaging-binary-extensions.rst:0 +#: ../source/guides/supporting-multiple-python-versions.rst:0 +#: ../source/guides/supporting-windows-using-appveyor.rst:0 +msgid "Last Reviewed" +msgstr "最終査読日" + +#: ../source/discussions/deploying-python-applications.rst:7 +msgid "2014-11-11" +msgstr "2014年11月11日" + +#: ../source/discussions/deploying-python-applications.rst:11 +#: ../source/discussions/install-requires-vs-requirements.rst:9 +#: ../source/guides/analyzing-pypi-package-downloads.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:22 +#: ../source/guides/index-mirrors-and-caches.rst:12 +#: ../source/guides/installing-scientific-packages.rst:9 +#: ../source/guides/packaging-binary-extensions.rst:17 +#: ../source/guides/supporting-multiple-python-versions.rst:12 +#: ../source/guides/supporting-windows-using-appveyor.rst:15 +#: ../source/overview.rst:23 +#: ../source/specifications/core-metadata.rst:38 +#: ../source/specifications/direct-url.rst:14 +#: ../source/tutorials/installing-packages.rst:23 +msgid "Contents" +msgstr "内容" + +#: ../source/discussions/deploying-python-applications.rst:14 +msgid "Overview" +msgstr "概要" + +#: ../source/discussions/deploying-python-applications.rst:18 +msgid "Supporting multiple hardware platforms" +msgstr "複数のハードウェアプラットフォームをサポートする" + +#: ../source/discussions/deploying-python-applications.rst:40 +msgid "OS packaging & installers" +msgstr "OSパッケージングとインストーラ" + +#: ../source/discussions/deploying-python-applications.rst:52 +msgid "Windows" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:61 +msgid "Pynsist" +msgstr "" + +#: ../source/discussions/deploying-python-applications.rst:63 +msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." +msgstr "" +"`Pynsist `__は、Pythonで書かれたプログラム群をNSISベースのPyt" +"honインタープリタ付きの単体インストーラにまとめるツールです。ほとんどの場合、パッケージング作業ではユーザがPythonインタープリタのバージョンを選択" +"することとプログラムの依存関係を宣言することしか求められません。このツールは、指定されたWindows版のPythonインタープリタをダウンロードして、依" +"存関係にあるすべてをWindows上で実行可能な単体インストーラにまとめます。" + +#: ../source/discussions/deploying-python-applications.rst:70 +msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." +msgstr "" +"インストーラがスタートメニューに追加したショートカットから、インストールされたプログラムを起動することができます。プログラムは、そのアプリケーション用のデ" +"ィレクトリの中にインストールされたPythonインタープリタで同じコンピュータ内にある他のPythonからは独立したをものを使います。" + +#: ../source/discussions/deploying-python-applications.rst:74 +msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." +msgstr "" +"Pynsistを使う大きな利点は、Windows用のパッケージをLinux上で作成することができるということです。`説明文書 " +" `__には異なる種類のプログラム(コンソール用やGUIを使うものなど)の例がいくつかあります。このツールはMITライセンスのもとに公開されています。" + +#: ../source/discussions/deploying-python-applications.rst:80 +msgid "Application bundles" +msgstr "アプリケーションバンドル" + +#: ../source/discussions/deploying-python-applications.rst:91 +msgid "Configuration management" +msgstr "設定管理" + +#: ../source/discussions/index.rst:4 +msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." +msgstr "" +"**議論型文書**は、特定の話題について網羅的な情報を提供することに重点を置いています。もしあなたがとにかく何かを終わらせようとしているだけなら、:doc" +":`/guides/index`を見た方が良いでしょう。" + +#: ../source/discussions/install-requires-vs-requirements.rst:5 +msgid "install_requires vs requirements files" +msgstr "install_requiresかrequirementsか" + +#: ../source/discussions/install-requires-vs-requirements.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:382 +msgid "install_requires" +msgstr "" + +#: ../source/discussions/install-requires-vs-requirements.rst:14 +msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" +"``install_requires``は:ref:`setuptools` :file:`setup.py`のキーワードで、そのプロジェクトが正しく動作" +"するために必要な最小限のものを指定するものです。プロジェクトが:ref:`pip`でインストールされた場合には、プロジェクトが依存するパッケージをインスト" +"ールするのに用いられます。" + +#: ../source/discussions/install-requires-vs-requirements.rst:19 +msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" +msgstr "例えば、プロジェクトがAとBに依存しているなら、``install_requires``は次のようになるでしょう：" + +#: ../source/discussions/install-requires-vs-requirements.rst:29 +msgid "Additionally, it's best practice to indicate any known lower or upper bounds." +msgstr "さらに、下限や上限がわかっているなら、それを示しておくことがベストプラクティスです。" + +#: ../source/discussions/install-requires-vs-requirements.rst:31 +msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" +msgstr "例えば、あなたのプロジェクトが少なくともv1の'A'と少なくともv2の'B'を必要とするとわかっているなら、次のようになるでしょう：" + +#: ../source/discussions/install-requires-vs-requirements.rst:41 +msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" +msgstr "" +"また、Aがセマンティックバージョニングの方法に従っていて'A'の(将来の)v2は互換性を持たなくなるだろうかということがわかっているので、(自分たちのプロ" +"ジェクトの側では)v2を許容したくないとしましょう：" + +#: ../source/discussions/install-requires-vs-requirements.rst:51 +msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." +msgstr "" +"依存関係にあるものを特定のバージョンに固定するために、あるいは、さらなる依存関係(すなわち、あなたの依存先が依存するもの)を指定するために``instal" +"l_requires``を使うことはベストプラクティスとは考えられていません。これは過剰に制限的であり、依存関係にあるものをまとめて更新することからユーザ" +"が得られる利益を阻害するものと考えられています。" + +#: ../source/discussions/install-requires-vs-requirements.rst:56 +msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" +msgstr "" +"最後に、``install_requires``が必要事項の「要約」のリスト、つまり、単に必要事項の名前とバージョンが要求されるだけあって、どこから(すな" +"わち、どんな索引や情報源から)充当するのかについては要求していないのだということを理解することは重要です。どこから(すなわち、どのようにして「具体化」され" +"るのか)という点については、:ref:`pip`のオプションを使ってインストール時に決定されるのです。[1]_" + +#: ../source/discussions/install-requires-vs-requirements.rst:64 +#: ../source/tutorials/installing-packages.rst:460 +msgid "Requirements files" +msgstr "Requirementsファイル" + +#: ../source/discussions/install-requires-vs-requirements.rst:66 +msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." +msgstr "" +":ref:`Requirementsファイル `は、一番簡単にいうならば、:ref:`pip:pip " +"install`の引数のリストをファイルに書いただけのものです。" + +#: ../source/discussions/install-requires-vs-requirements.rst:69 +msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." +msgstr "" +"``install_requires``が単一のプロジェクトにおける依存関係を定義する一方で、:ref:`Requirements Files `はPython環境全体に対する要求事項を定義するのにしばしば用いられます。" + +#: ../source/discussions/install-requires-vs-requirements.rst:73 +msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." +msgstr "" +"``install_requires``での要求事項が最小限のものである一方で、requirementsファイルは再現可能な形で環境全体をインストールでき" +"るようにする:ref:`repeatable installations " +"`という目的に沿って限定されたバージョンの網羅的なリストを含むことがしばしばです。" + +#: ../source/discussions/install-requires-vs-requirements.rst:78 +msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" +msgstr "" +"``install_requires``での要求事項が「要約」、すなわち特定の索引には紐づけられていないのに対して、requirementsファイルではし" +"ばしば``--index-url``や``--find-" +"links``のようなpipのオプションが含まれていて特定の索引やパッケージ登録簿に紐づけられた「具体的な」要求事項になっています。[1]_" + +#: ../source/discussions/install-requires-vs-requirements.rst:84 +msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." +msgstr "" +"``install_requires``では、メタデータがインストール中にpipによって自動的に解析される一方、requirementsファイルではそうで" +"はなく、``python -m pip install -r``を使ってユーザが明示的にインストールする時に使われるだけです。" + +#: ../source/discussions/install-requires-vs-requirements.rst:90 +msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." +msgstr "" +"要求事項が「要約」か「具体的」かの議論についてもっと知りたい場合は、https://caremad.io/2013/07/" +"setup-vs-requirement/をご覧ください。" + +#: ../source/discussions/pip-vs-easy-install.rst:6 +msgid "pip vs easy_install" +msgstr "pip対easy_install" + +#: ../source/discussions/pip-vs-easy-install.rst:9 +msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." +msgstr "" +":ref:`easy_install `は、現在では`非推奨`とされていますが、2004年に:ref:`setuptools`" +"の一部として公開されました。requirementsファイルを利用して自動的に依存関係にあるパッケージも併せて:term:`PyPI `から:term:`packages `をインストールすることができるというのは当時としては画期的でした。" + +#: ../source/discussions/pip-vs-easy-install.rst:14 +msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." +msgstr "" +"依然として:ref:`setuptools`を部品に使ってビルドされてはいますが、:ref:`easy_install " +"`を置き換えるものとして:ref:`pip`が2008年に後からやってきました。当時はパッケージを(かなり単純に:term:`" +"sdists `から「フラット」なパッケージとしてインストールするものであって):term:`Eggs `の形でインストールするものでも、:term:`" +"Eggs `からインストールするものでも*なかった*こと、そして、簡単に環境を再現する力をユーザに与える:ref:`Requirements " +"Files `の考え方を導入したことは注目に値します。" + +#: ../source/discussions/pip-vs-easy-install.rst:22 +msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" +msgstr "pipと非推奨となったeasy_installの重要な違いをおさらいしておきましょう：" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**pip**" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:25 +msgid "**easy_install**" +msgstr "" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +msgid "Installs from :term:`Wheels `" +msgstr ":term:`Wheels `からのインストール" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Yes" +msgstr "はい" + +#: ../source/discussions/pip-vs-easy-install.rst:27 +#: ../source/discussions/pip-vs-easy-install.rst:30 +#: ../source/discussions/pip-vs-easy-install.rst:32 +#: ../source/discussions/pip-vs-easy-install.rst:35 +#: ../source/discussions/pip-vs-easy-install.rst:38 +#: ../source/discussions/pip-vs-easy-install.rst:44 +#: ../source/discussions/pip-vs-easy-install.rst:48 +#: ../source/discussions/pip-vs-easy-install.rst:51 +#: ../source/discussions/pip-vs-easy-install.rst:54 +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "No" +msgstr "いいえ" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Uninstall Packages" +msgstr "パッケージのアンインストール" + +#: ../source/discussions/pip-vs-easy-install.rst:30 +msgid "Yes (``python -m pip uninstall``)" +msgstr "はい (``python -m pip uninstall``)" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Dependency Overrides" +msgstr "依存関係を上書きする" + +#: ../source/discussions/pip-vs-easy-install.rst:32 +msgid "Yes (:ref:`Requirements Files `)" +msgstr "はい (:ref:`Requirementsファイル `" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "List Installed Packages" +msgstr "インストールされたパッケージのリスト" + +#: ../source/discussions/pip-vs-easy-install.rst:35 +msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" +msgstr "はい (``python -m pip list`` and ``python -m pip freeze``)" + +#: ../source/discussions/pip-vs-easy-install.rst:38 +msgid ":pep:`438` Support" +msgstr ":pep:`438` サポート" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Installation format" +msgstr "インストールフォーマット" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "'Flat' packages with :file:`egg-info` metadata." +msgstr ":file:`egg-info`のメタデータを伴った「フラット」なパッケージ。" + +#: ../source/discussions/pip-vs-easy-install.rst:41 +msgid "Encapsulated Egg format" +msgstr "カプセル化されたEggフォーマット" + +#: ../source/discussions/pip-vs-easy-install.rst:44 +msgid "sys.path modification" +msgstr "sys.pathの変更" + +#: ../source/discussions/pip-vs-easy-install.rst:48 +msgid "Installs from :term:`Eggs `" +msgstr ":term:`Eggs `からのインストール" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "`pylauncher support`_" +msgstr "`pylauncherサポート `_" + +#: ../source/discussions/pip-vs-easy-install.rst:51 +msgid "Yes [1]_" +msgstr "はい [1]_" + +#: ../source/discussions/pip-vs-easy-install.rst:54 +msgid ":ref:`Multi-version Installs`" +msgstr ":ref:`複数バージョンのインストール `" + +#: ../source/discussions/pip-vs-easy-install.rst:57 +msgid "Exclude scripts during install" +msgstr "インストール中にスクリプトを除外する" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "per project index" +msgstr "プロジェクトごとの索引" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Only in virtualenv" +msgstr "virtualenvの中のみ" + +#: ../source/discussions/pip-vs-easy-install.rst:60 +msgid "Yes, via setup.cfg" +msgstr "はい、setup.cfgを通じて" + +#: ../source/discussions/pip-vs-easy-install.rst:68 +msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" +msgstr "" + +#: ../source/discussions/wheel-vs-egg.rst:5 +msgid "Wheel vs Egg" +msgstr "Wheel対Egg" + +#: ../source/discussions/wheel-vs-egg.rst:7 +msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." +msgstr "" +":term:`Wheel`と :term:`Egg`は、どちらも、試験目的の場合や本番環境の場合にはコストが高すぎるビルドやコンパイルをしなくてもプログラ" +"ムをインストールするというユースケースに対応することを目指したパッケージングのフォーマットです。" + +#: ../source/discussions/wheel-vs-egg.rst:11 +msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." +msgstr "" +":term:`Egg`のフォーマットは、2004年に:ref:`setuptools`によって、また、:term:`Wheel`のフォーマットは2012年" +"に:pep:`427`によって導入されました。" + +#: ../source/discussions/wheel-vs-egg.rst:14 +msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." +msgstr "" +":term:`Wheel`は、現在、Pythonにおける :term:`ビルド済配布物 `および :term:`" +"バイナリ配布物 `の標準であるとみなされています。" + +#: ../source/discussions/wheel-vs-egg.rst:17 +msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." +msgstr ":term:`Wheel`と :term:`Egg`の重要な差異について以下にまとめます。" + +#: ../source/discussions/wheel-vs-egg.rst:20 +msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." +msgstr ":term:`Wheel`には :pep:`公式PEP <427>`が存在します。 :term:`Egg`には対応するPEPがありません。" + +#: ../source/discussions/wheel-vs-egg.rst:22 +msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." +msgstr "" +":term:`Wheel`は :term:`配布物 `のフォーマット、つまり、パッケージのフォーマットです。[1]_ :term:`Egg`は配布物のフォーマットでもあり、かつ、(もし圧縮さ" +"れたままであれば)実行時のインストールフォーマットであってimportができるように設計されています。" + +#: ../source/discussions/wheel-vs-egg.rst:26 +msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." +msgstr "" +":term:`Wheel`形式のファイルには.pycファイルが含まれていません。従って、配布物には(コンパイル済のファイル抜きの)Pythonファイルのみ" +"(含み、Pythonのバージョン2と3で使用可能ですので、 :term:`sdist `と同様にwheelは「汎用」であると言うことができます。" + +#: ../source/discussions/wheel-vs-egg.rst:31 +msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." +msgstr "" +":term:`Wheel`は :pep:`PEP376-compliant <376>`に従って ``.dist-info`` ディレクトリを用います。" +"Eggは ``.egg-info`` を用います。" + +#: ../source/discussions/wheel-vs-egg.rst:34 +msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." +msgstr "" +":term:`Wheel`には:pep:`richer file naming convention <425>`が存在します。単独のwheelアーカイブ" +"はPython言語のバージョンや実装、ABI、そしてシステムのアーキテクチャとの互換性を表示することができます。" + +#: ../source/discussions/wheel-vs-egg.rst:38 +msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." +msgstr "" +":term:`Wheel`はバージョン付けされています。それぞれのwheelファイルは、それをパッケージしたwheelの仕様や実装のバージョンを保持してい" +"ます。" + +#: ../source/discussions/wheel-vs-egg.rst:41 +msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." +msgstr "" +":term:`Wheel`は内部では`sysconfigパスの型 `_で整理されているので、他のフォーマットに変換するのがより簡単になっています。" + +#: ../source/discussions/wheel-vs-egg.rst:47 +msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." +msgstr "" +":pep:`Wheelファイルから直接にimportすることは現時点では公式にサポートされていません<427#is-it-possible-to-" +"import-python-code-directly-from-a-wheel-" +"file>`が、状況によって幾つかのケースでwheelは重要な実行時フォーマットとして使われます。" + +#: ../source/glossary.rst:3 +msgid "Glossary" +msgstr "用語集" + +#: ../source/glossary.rst:8 +msgid "Binary Distribution" +msgstr "バイナリ配布物" + +#: ../source/glossary.rst:11 +msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." +msgstr "`ビルド済配布物 `の特定の種類で、コンパイル済みの拡張部分を含むもの。" + +#: ../source/glossary.rst:14 +msgid "Built Distribution" +msgstr "ビルド済配布物" + +#: ../source/glossary.rst:17 +msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." +msgstr "" +":term:`配布物 `とは、ターゲットとなるシステムの適切な位置に移動することでインストールされるファイルや" +"メタデータを内包したフォーマットです。:term:`Wheel`はそのようなフォーマットですが、他方で、distutilの :term:`" +"ソースコード配布物 `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." +msgstr "" +":term:`モジュール `すなわちPythonの :term:`パッケージ `や、ある :term:`R" +"elease`を配布するために使われるその他のリソースファイルを内部に含むバージョン付きアーカイブファイル。アーカイブファイルはエンドユーザがインターネッ" +"トからダウンロードしてインストールするものです。" + +#: ../source/glossary.rst:34 +msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." +msgstr "" +"配布物パッケージは単語ひとつで「パッケージ」や「配布物」と呼ばれることもしばしばですが、 :term:`Import Package`(これも通常は単に「" +"パッケージ」と呼ばれます)や他の種類の配布物(例えばLinuxディストリビューションやPython言語の配布物)でよく単語ひとつの「配布物」と呼ばれるもの" +"との混同を避けるために明確に述べる必要がある場合には、本ガイドでは長い方の呼び方を用いることがあります。" + +#: ../source/glossary.rst:41 +msgid "Egg" +msgstr "Egg" + +#: ../source/glossary.rst:44 +msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" +msgstr "" +":term:`ビルド済配布物 `フォーマットは :ref:`setuptools`によって導入されましたが、 " +":term:`Wheel`によって置き換えられつつあります。詳細については、`Python Eggの内部構造 `_と`Python Eggs " +"`_ を参照してください。" + +#: ../source/glossary.rst:49 +msgid "Extension Module" +msgstr "拡張モジュール" + +#: ../source/glossary.rst:52 +msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." +msgstr "" +":term:`モジュール `とは、Pythonの実装のうちの低レベル言語で書かれた部分で、C/C++で書かれたCythonやJavaで書か" +"れたJythonが該当する。典型的には動的にロードできるコンパイル済みのファイルをひとつ含んでいて、Unix上では共有オブジェクトファイル(." +"so)、Windows上ではDLL(拡張子.pydを与えられる)のPython拡張、Jython拡張ではJavaのクラスファイルの形を取る。" + +#: ../source/glossary.rst:59 +msgid "Known Good Set (KGS)" +msgstr "既知の良好な組み合わせ(KGS)" + +#: ../source/glossary.rst:62 +msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." +msgstr "" +"(KGSとは)相互に互換性のある特定のバージョンの配布物の集合。典型的には、テストスイートで全てのテストに合格して実行できるようなパッケージの特定の組み合" +"わせが既知の良好なセット(KGS)であると宣言されます。この用語は、個々の配布物を複数組み合わせて構成されるフレームワークやツールキットで共通して用いられ" +"ます。" + +#: ../source/glossary.rst:68 +msgid "Import Package" +msgstr "パッケージをimportする" + +#: ../source/glossary.rst:71 +msgid "A Python module which can contain other modules or recursively, other packages." +msgstr "直接に、あるいは何段階になっても良いが、他のパッケージを組み込んで使うようなPythonモジュール。" + +#: ../source/glossary.rst:74 +msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." +msgstr "" +"インポートパッケージは、より普通には「パッケージ」という用語で呼ばれますが、本ガイドでは、同様に単に「パッケージ」と呼ばれることが普通である " +":term:`配布物パッケージ `との混同を避けるために必要な場合には、長い方の用語を用いることにします。" + +#: ../source/glossary.rst:78 +msgid "Module" +msgstr "モジュール" + +#: ../source/glossary.rst:81 +msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." +msgstr "" +"Pythonにおけるソースコード再利用の基本的な単位で、 :term:`Pure Module`か :term:`Extension " +"Module`の二つのタイプのうちのいずれか。" + +#: ../source/glossary.rst:84 +msgid "Package Index" +msgstr "パッケージ索引" + +#: ../source/glossary.rst:87 +msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." +msgstr "" +":term:`パッケージ `の発見・消費(訳註、意訳になるが検索・ダウンロードが適切か)を自動化するwebインターフェイスを伴った配布物のリポジトリ。" + +#: ../source/glossary.rst:90 +msgid "Per Project Index" +msgstr "プロジェクト単位の索引" + +#: ../source/glossary.rst:93 +msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." +msgstr "" +"ある :term:`プロジェクト `が嗜好するか要求する依存関係を解決するために、:term:`プロジェクト `" +"の単位で示された仲間内または非公式の :term:`パッケージ索引 `。" + +#: ../source/glossary.rst:97 +msgid "Project" +msgstr "プロジェクト" + +#: ../source/glossary.rst:100 +msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." +msgstr "" +"ライブラリ、フレームワーク、スクリプト、プラグイン、アプリケーション、ないし一連のデータもしくはその他のリソース、または、これらの組み合わせで " +":term:`配布物 `として意図的にパッケージされたもの。" + +#: ../source/glossary.rst:104 +msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." +msgstr "" +"ほとんどのプロジェクトで :pep:`518` ``build-system``として :ref:`distutils`か " +":ref:`setuptools`を用いて :term:`配布物 `を作成しますので、現時点でプロジェクトを定義するもうひとつの実践的な方法は、プロジェクトのソースコードの一番上のディレクトリに " +":term:`pyproject.toml`や :term:`setup.py`または :term:`setup." +"cfg`のファイルを含む何ものかというものです。" + +#: ../source/glossary.rst:110 +msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." +msgstr "" +"Pythonにおけるプロジェクトは、 :term:`PyPI `に登録される一意の名前を持っていなければなりません。そして、プロジェクトはそれぞれひとつまたはより多くの :term:`リリース " +"`を含んでいて、各リリースはひとつまたはより多くの :term:`配布物 `を内包しています。" + +#: ../source/glossary.rst:115 +msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." +msgstr "" +"そのプロジェクトを稼働させるためにインポートされるパッケージの名前に因んでプロジェクトに名前をつけるのが普通であるという強い慣習があることを覚えておいてく" +"ださい。しかしながら、常にそうしなければならないわけではありません。「なんとか」というプロジェクトから配布物をインストールしていながらも、「かんとか」(訳" +"註、「なんとか」とは無関係の別の名前の例)という名前でのみインポート可能なパッケージを提供することは可能です。" + +#: ../source/glossary.rst:121 +msgid "Pure Module" +msgstr "純粋なモジュール" + +#: ../source/glossary.rst:124 +msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." +msgstr "" +"Pythonで書かれていて単一の``.py``ファイル(とおそらくは対応する``.pyc``ファイルや``.pyo``ファイル)に収められた " +":term:`モジュール `。" + +#: ../source/glossary.rst:127 +msgid "Python Packaging Authority (PyPA)" +msgstr "Pythonパッケージングオーソリティ(PyPA)" + +#: ../source/glossary.rst:130 +msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." +msgstr "" +"PyPAは、Pythonのパッケージングに関係する多くのプロジェクトを維持管理する作業グループです。その活動の一環として https://" +"www.pypa.io を維持管理しており、 `GitHub `_ と `Bitbucket " +"`_ に関連プロジェクトを置くとともに、 `distutils-sig メーリングリスト " +"`_ と `" +"Python談話フォーラム `__ で議論を進めています。" + +#: ../source/glossary.rst:139 +msgid "Python Package Index (PyPI)" +msgstr "Pythonパッケージインデックス (PyPI)" + +#: ../source/glossary.rst:142 +msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." +msgstr "" +"`PyPI `_ は、Pythonコミュニティにとってデフォルトの :term:`Package " +"Index`です。ここから配布物を取り出し、また、配布するためにすべてのPython開発者に開かれています。" + +#: ../source/glossary.rst:145 +msgid "pypi.org" +msgstr "pypi.org" + +#: ../source/glossary.rst:148 +msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." +msgstr "" +"`pypi.org `_ は、 :term:`Python パッケージインデックス(PyPI)` " +"のためのドメイン名です。2017年にそれまでのドメイン名である ``pypi.python.org`` を置き換えました。 " +":ref:`warehouse`を使っています。" + +#: ../source/glossary.rst:152 +msgid "pyproject.toml" +msgstr "pyproject.toml" + +#: ../source/glossary.rst:155 +msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." +msgstr "ツール不可知論者の :term:`プロジェクト ` 仕様を示すファイル。 :pep:`518` で定義。" + +#: ../source/glossary.rst:157 +msgid "Release" +msgstr "リリース" + +#: ../source/glossary.rst:160 +msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." +msgstr "ある特定の時点における :term:`プロジェクト `のスナップショットで、バージョン識別子付きのもの。" + +#: ../source/glossary.rst:163 +msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." +msgstr "" +"リリースを作成することは、複数の :term:`配布物 ` " +"を公開することを伴います。例えば、あるプロジェクトのバージョン1." +"0がリリースされたならば、ソースコード配布物とWindowsインストーラ付配布物の両方が利用可能となっているという具合です。" + +#: ../source/glossary.rst:168 +msgid "Requirement" +msgstr "要求事項" + +#: ../source/glossary.rst:171 +msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." +msgstr "" +"インストールされる :term:`パッケージ ` の仕様。 :term:`PYPA ` が推奨するインストーラである :ref:`pip` " +"では、「要求事項」とも解釈できる仕様を様々な様式で書くことを許容しています。詳細については、 :ref:`pip:pip install` " +"の項を参照してください。" + +#: ../source/glossary.rst:177 +msgid "Requirement Specifier" +msgstr "要求事項指示子" + +#: ../source/glossary.rst:180 +msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" +msgstr "" +":term:`パッケージインデックス `からパッケージをインストールするために :ref:`pip` で用いられる様式。" +"この様式の EBNF 文法構造については :ref:`setuptools` のドキュメントにある <`" +"pkg_resources.Requirement `_ の項をご覧ください。例えば、\"foo>=1." +"3\"は要求事項識別子であり、\"foo\"の部分がプロジェクトの名称、\">=1.3\"の部分が :term:`バージョン識別子 ` に該当します。" + +#: ../source/glossary.rst:187 +msgid "Requirements File" +msgstr "Requirementsファイル" + +#: ../source/glossary.rst:190 +msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." +msgstr "" +":ref:`pip`を用いてインストールできるように :term:`要求事項 ` を記したファイル。詳しい情報は、 " +":ref:`pip` のドキュメントの :ref:`pip:Requirementsファイル ` " +"をみてください。" + +#: ../source/glossary.rst:194 +#: ../source/guides/distributing-packages-using-setuptools.rst:56 +msgid "setup.py" +msgstr "setup.py" + +#: ../source/glossary.rst:195 +#: ../source/guides/distributing-packages-using-setuptools.rst:77 +msgid "setup.cfg" +msgstr "setup.cfg" + +#: ../source/glossary.rst:198 +msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." +msgstr "" +":ref:`distutils`や :ref:`setuptools` で使われるプロジェクトの仕様を記したファイル。 :term:`pyproject." +"toml`も見てください。" + +#: ../source/glossary.rst:201 +msgid "Source Archive" +msgstr "ソースコードアーカイブ" + +#: ../source/glossary.rst:204 +msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." +msgstr "" +":term:`ソースコード配布物 ` や :term:`ビルド配布物 " +"` という用語を作る前には、:term:`リリース " +"`向けに生のソースコードを収めたアーカイブのことをこう呼んでいた。" + +#: ../source/glossary.rst:208 +msgid "Source Distribution (or \"sdist\")" +msgstr "`ソースコード配布物 (またはsdist) `" + +#: ../source/glossary.rst:211 +msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." +msgstr "" +":ref:`pip`のようなツールでインストールするか :term:`ビルド配布物 ` " +"を生成するのに必要なメタデータと必須ソースコードを提供する :term:`配布物 ` フォーマット。" + +#: ../source/glossary.rst:216 +msgid "System Package" +msgstr "システムパッケージ" + +#: ../source/glossary.rst:219 +msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." +msgstr "rpmやdpkgのように、オペレーティングシステムに固有のフォーマットで提供されるパッケージ。" + +#: ../source/glossary.rst:222 +msgid "Version Specifier" +msgstr "バージョン識別子" + +#: ../source/glossary.rst:225 +msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." +msgstr "" +":term:`要求事項指定子 ` のバージョン部分。例えば、\"foo>=1.3\"の中の\">=1." +"3\"の部分。:pep:`440`には、Pythonパッケージングが現在サポートしている指定子の :pep:`完全な仕様 <440#version-" +"specifiers>` が含まれています。 :ref:`setuptools` v8.0や :ref:`pip` v6." +"0はPEP440への対応を実装しています。" + +#: ../source/glossary.rst:231 +msgid "Virtual Environment" +msgstr "仮想環境" + +#: ../source/glossary.rst:234 +msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" +"システム全体からではなく、ある特定のアプリケーションだけから使えるようにパッケージをインストールすることができる、隔離されたPython環境。詳細は " +":ref:`仮想環境の生成と使用 ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." +msgstr "" +"一連のインポート可能な :term:`配布物 `。これらは `sys.path` " +"変数から検索できる配布物です。あるプロジェクトには、高々(訳註、at mostではなくat least、すくなくとも、か。)ひとつの :term:`" +"配布物 ` が動作可能セットにあります。" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:3 +msgid "Analyzing PyPI package downloads" +msgstr "PyPIパッケージのダウンロード状況の解析" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:5 +msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." +msgstr "" +"この節では、公開のPyPIダウンロードデータセットを用いて、PyPIにホストされているパッケージ(あるいはパッケージ群)のダウンロード状況を詳しく見ていく" +"ことを記述しています。例えば、ダウンロードに使われたPythonのバージョンの分布を発見することができます。" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:15 +#: ../source/guides/supporting-windows-using-appveyor.rst:18 +msgid "Background" +msgstr "背景" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:17 +msgid "PyPI does not display download statistics for a number of reasons: [#]_" +msgstr "PyPIはいくつもの理由からダウンロード統計を表示しません。:[#]_" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:19 +msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." +msgstr "" +"**コンテンツデリバリネットワーク(CDN)と一緒に動かす時の効率の悪さ** ダウンロード用系は常に変動します。プロジェクトのページでのダウンロードは強烈" +"にキャッシュされていますが、(訳註、統計を正しく取ろうとするなら)より頻繁にキャッシュし直さなければならず、これはキャッシュの効率性を損ねます。" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:24 +msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" +msgstr "**非常に不正確** 次に挙げるものを含め、いくつもの要因でダウンロード数が正確とは言えないものになります：" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:27 +msgid "``pip``'s download cache (lowers download counts)" +msgstr "``pip``のダウンロードキャッシュ (ダウンロード数を小さくする)" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:28 +msgid "Internal or unofficial mirrors (can both raise or lower download counts)" +msgstr "内部の、または、非公式のミラーサイト (ダウンロード数を大きくする要因にも小さくする要因にもなる)" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:29 +msgid "Packages not hosted on PyPI (for comparisons sake)" +msgstr "PyPIにホストされていないパッケージ (比較することの妥当性を損ねる)" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:30 +msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" +msgstr "ダウンロード数を増やす非公式のスクリプトまたは試行 (ダウンロード数を大きくする)" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:32 +msgid "Known historical data quality issues (lowers download counts)" +msgstr "過去のデータ品質における既知の問題 (ダウンロード数を小さくする)" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:34 +msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:38 +msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:43 +msgid "Public dataset" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:45 +msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:50 +msgid "Getting set up" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:52 +msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:58 +msgid "Navigate to the `BigQuery web UI`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:59 +msgid "Create a new project." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:60 +msgid "Enable the `BigQuery API `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:63 +msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:69 +msgid "Data schema" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:71 +msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +msgid "Column" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/guides/using-manifest-in.rst:67 +#: ../source/specifications/core-metadata.rst:185 +msgid "Description" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:78 +#: ../source/specifications/direct-url.rst:226 +msgid "Examples" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "timestamp" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "Date and time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:80 +msgid "``2020-03-09 00:33:03 UTC``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "file.project" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "Project name" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:82 +msgid "``pipenv``, ``nose``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "file.version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "Package version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:84 +msgid "``0.1.6``, ``1.4.2``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "details.installer.name" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "Installer" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:86 +msgid "pip, `bandersnatch`_" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "details.python" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "Python version" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:88 +msgid "``2.7.12``, ``3.6.4``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:93 +msgid "Useful queries" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:95 +msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:97 +msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:102 +msgid "Counting package downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:104 +msgid "The following query counts the total number of downloads for the project \"pytest\"." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:119 +#: ../source/guides/analyzing-pypi-package-downloads.rst:140 +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "num_downloads" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:121 +msgid "26190085" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:124 +msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:142 +msgid "24334215" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:146 +msgid "Package downloads over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:148 +msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:168 +msgid "month" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "1956741" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:170 +msgid "2018-01-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2344692" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:172 +msgid "2017-12-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "1730398" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:174 +msgid "2017-11-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2047310" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:176 +msgid "2017-10-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "1744443" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:178 +msgid "2017-09-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "1916952" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:180 +msgid "2017-08-01" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:184 +msgid "Python versions over time" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:186 +msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:205 +msgid "python" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "3.7" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:207 +msgid "18051328726" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "3.6" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:209 +msgid "9635067203" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "3.8" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:211 +msgid "7781904681" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "2.7" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:213 +msgid "6381252241" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "null" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:215 +msgid "2026630299" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "3.5" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:217 +msgid "1894153540" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:221 +msgid "Caveats" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:223 +msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:231 +msgid "Additional tools" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:233 +msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:237 +msgid "``google-cloud-bigquery``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:239 +msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:267 +msgid "``pypinfo``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:269 +msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:273 +msgid "Install `pypinfo`_ using pip." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:279 +msgid "Usage:" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:295 +msgid "``pandas-gbq``" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:297 +msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:301 +#: ../source/specifications/binary-distribution-format.rst:459 +msgid "References" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:303 +msgid "`PyPI Download Counts deprecation email `__" +msgstr "" + +#: ../source/guides/analyzing-pypi-package-downloads.rst:304 +msgid "`PyPI BigQuery dataset announcement email `__" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:3 +msgid "Creating and discovering plugins" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:5 +msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:10 +msgid "There are three major approaches to doing automatic plugin discovery:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:12 +msgid "`Using naming convention`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:13 +msgid "`Using namespace packages`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:14 +msgid "`Using package metadata`_." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:18 +msgid "Using naming convention" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:20 +msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:38 +msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:48 +msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:59 +msgid "Using namespace packages" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:61 +msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:89 +msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:101 +msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:115 +msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:121 +msgid "Using package metadata" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:123 +msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:128 +msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:139 +msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:154 +msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:163 +msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:166 +msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." +msgstr "" + +#: ../source/guides/creating-and-discovering-plugins.rst:170 +msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:5 +msgid "Packaging and distributing projects" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:7 +msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:11 +msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:15 +msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:25 +msgid "Requirements for packaging and distributing" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:26 +msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:29 +msgid "Install \"twine\" [1]_:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:43 +msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:49 +msgid "Configuring your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:53 +msgid "Initial files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:58 +msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:63 +msgid ":file:`setup.py` serves two primary functions:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:65 +msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:71 +msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:79 +msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:86 +msgid "README.rst / README.md" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:88 +msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:95 +msgid "For an example, see `README.md `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:99 +msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:108 +msgid "MANIFEST.in" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:110 +msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:115 +msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:119 +msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:122 +msgid "LICENSE.txt" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:124 +msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:130 +msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:135 +msgid "" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:137 +msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:141 +msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:149 +msgid "setup() args" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:151 +msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:155 +msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:164 +msgid "name" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:170 +msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:174 +msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:176 +msgid "Start & end with an ASCII letter or digit." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:178 +msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:190 +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "version" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:196 +msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:200 +msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:203 +msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:206 +msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:214 +msgid "description" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:222 +msgid "Give a short and long description for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:224 +msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:229 +msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:235 +msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:245 +msgid "url" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:252 +msgid "Give a homepage URL for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:256 +msgid "author" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:263 +msgid "Provide details about the author." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:267 +msgid "license" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:273 +msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:279 +msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:287 +msgid "classifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:316 +msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:319 +msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:327 +msgid "keywords" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:333 +msgid "List keywords that describe your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:337 +msgid "project_urls" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:349 +msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:355 +msgid "packages" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:361 +msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:370 +msgid "py_modules" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:376 +msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:388 +msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:392 +msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:398 +msgid "python_requires" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:400 +msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:407 +msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:412 +msgid "And so on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:416 +msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:422 +msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:431 +msgid "package_data" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:440 +msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:445 +msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:449 +msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:457 +msgid "data_files" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:463 +msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:469 +msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:479 +msgid "For more information see the distutils section on `Installing Additional Files `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:484 +msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:491 +msgid "scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:493 +msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:500 +msgid "entry_points" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:509 +msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:512 +msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:516 +msgid "The most commonly used entry point is \"console_scripts\" (see below)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:521 +msgid "console_scripts" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:531 +msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:538 +msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:545 +msgid "Choosing a versioning scheme" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:548 +msgid "Standards compliance for interoperability" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:550 +msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:556 +msgid "Here are some examples of compliant version numbers::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:567 +msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:573 +msgid "Scheme choices" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:576 +msgid "Semantic versioning (preferred)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:578 +msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:582 +msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:585 +msgid "MAJOR version when they make incompatible API changes," +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:586 +msgid "MINOR version when they add functionality in a backwards-compatible manner, and" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:587 +msgid "MAINTENANCE version when they make backwards-compatible bug fixes." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:589 +msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:594 +msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:598 +msgid "Date based versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:600 +msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:604 +msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:607 +msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:611 +msgid "Serial versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:613 +msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:616 +msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:621 +msgid "Hybrid schemes" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:623 +msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:629 +msgid "Pre-release versioning" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:631 +msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:634 +msgid "zero or more dev releases (denoted with a \".devN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:635 +msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:636 +msgid "zero or more beta releases (denoted with a \".bN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:637 +msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:639 +msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:644 +msgid "Local version identifiers" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:646 +msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:653 +msgid "A local version identifier takes the form ``+``. For example::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:661 +msgid "Working in \"development mode\"" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:663 +msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:667 +msgid "Assuming you're in the root of your project directory, then run:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:674 +msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:680 +msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:688 +msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:692 +msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:697 +msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:701 +msgid "Lastly, if you don't want to install any dependencies at all, you can run::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:706 +msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:713 +msgid "Packaging your project" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:715 +msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:720 +msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:737 +msgid "Source distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:739 +msgid "Minimally, you should create a :term:`Source Distribution `:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:755 +msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:763 +msgid "Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:765 +msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:770 +msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:773 +msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:776 +msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:785 +msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:792 +msgid "Pure Python Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:794 +msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:797 +#: ../source/guides/distributing-packages-using-setuptools.rst:826 +msgid "To build the wheel:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:811 +msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:815 +msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:821 +msgid "Platform Wheels" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:823 +msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:841 +msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:847 +msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:855 +msgid "Uploading your Project to PyPI" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:857 +msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:861 +msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:866 +msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:871 +msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:877 +msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:888 +msgid "Create an account" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:890 +msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:894 +msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:897 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:901 +msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:904 +msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:913 +msgid "**Be aware that this stores your token in plaintext.**" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:915 +#: ../source/guides/migrating-to-pypi-org.rst:70 +#: ../source/guides/migrating-to-pypi-org.rst:109 +#: ../source/guides/using-testpypi.rst:83 +msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:921 +msgid "Upload your distributions" +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:923 +msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:926 +msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:930 +msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:937 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:944 +#: ../source/tutorials/installing-packages.rst:663 +msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." +msgstr "" + +#: ../source/guides/distributing-packages-using-setuptools.rst:950 +msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:5 +msgid "Dropping support for older Python versions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:7 +msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:9 +msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:12 +msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:14 +msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:17 +msgid "Requirements" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:19 +msgid "This workflow requires that:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:21 +msgid "The publisher is using the latest version of :ref:`setuptools`," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:22 +msgid "The latest version of :ref:`twine` is used to upload the package," +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:23 +msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:26 +msgid "Dealing with the universal wheels" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:28 +msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:36 +msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:48 +msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:53 +msgid "Defining the Python version required" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:56 +msgid "1. Download the newest version of Setuptools" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:58 +msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:60 +msgid "Steps:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:74 +msgid "`setuptools` version should be above 24.0.0." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:77 +msgid "2. Specify the version ranges for supported Python distributions" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:79 +msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:81 +#: ../source/specifications/core-metadata.rst:139 +#: ../source/specifications/core-metadata.rst:463 +#: ../source/specifications/core-metadata.rst:487 +#: ../source/specifications/core-metadata.rst:527 +#: ../source/specifications/core-metadata.rst:550 +#: ../source/specifications/core-metadata.rst:583 +#: ../source/specifications/core-metadata.rst:693 +#: ../source/specifications/core-metadata.rst:722 +msgid "Examples::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:86 +msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:101 +msgid "3. Validating the Metadata before publishing" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:103 +msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:105 +msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:108 +msgid "You can see the contents of the generated file like this::" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:112 +msgid "Validate that the following is in place, before publishing the package:" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:114 +msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:115 +msgid "The Requires-Python field is set and matches your specification in setup.py." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:118 +msgid "4. Using Twine to publish" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:120 +msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:122 +msgid "Make sure you are using the newest version of Twine, at least 1.9." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:125 +msgid "Dropping a Python release" +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:127 +msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:129 +msgid "It must be done in this order for the automated fallback to work." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:131 +msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." +msgstr "" + +#: ../source/guides/dropping-older-python-versions.rst:133 +msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:5 +msgid "Hosting your own simple repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:8 +msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:13 +msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:29 +msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:35 +msgid "\"Manual\" repository" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:37 +msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:51 +msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." +msgstr "" + +#: ../source/guides/hosting-your-own-index.rst:58 +msgid "For complete documentation of the simple repository protocol, see :pep:`503`." +msgstr "" + +#: ../source/guides/index.rst:8 +#: ../source/guides/index.rst:8 +msgid "Installing Packages:" +msgstr "" + +#: ../source/guides/index.rst:20 +#: ../source/guides/index.rst:20 +msgid "Building and Publishing Projects:" +msgstr "" + +#: ../source/guides/index.rst:38 +#: ../source/guides/index.rst:38 +msgid "Miscellaneous:" +msgstr "" + +#: ../source/guides/index.rst:4 +msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:5 +msgid "Package index mirrors and caches" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:8 +#: ../source/guides/supporting-multiple-python-versions.rst:8 +msgid "2014-12-24" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:14 +msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:17 +msgid "Three options are available in this area:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:19 +msgid "pip provides local caching options," +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:20 +msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:22 +msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:27 +msgid "Caching with pip" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:29 +msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:32 +msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:36 +msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:45 +msgid "Caching with devpi" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:47 +msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:55 +msgid "Complete mirror with bandersnatch" +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:57 +msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." +msgstr "" + +#: ../source/guides/index-mirrors-and-caches.rst:63 +msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:5 +msgid "Installing scientific packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:11 +msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:16 +msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:22 +msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:29 +msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:35 +msgid "Building from source" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:37 +msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:45 +msgid "Linux distribution packages" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:47 +msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:51 +msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:57 +msgid "Windows installers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:59 +msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:64 +msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:67 +msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:73 +msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:79 +msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:86 +msgid "macOS installers and package managers" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:88 +msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:92 +msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:99 +msgid "SciPy distributions" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:101 +msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:105 +msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:109 +#: ../source/key_projects.rst:596 +msgid "Spack" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:110 +msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:119 +msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:128 +msgid "The conda cross-platform package manager" +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:130 +msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." +msgstr "" + +#: ../source/guides/installing-scientific-packages.rst:136 +msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 +msgid "Installing stand alone command line tools" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 +msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 +msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 +msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 +msgid "pipx only works with Python 3.6+." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 +msgid "``pipx`` is installed with ``pip``:" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 +msgid "You may need to restart your terminal for the path updates to take effect." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 +msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 +#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 +msgid "For example" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 +msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 +msgid "To upgrade or uninstall the package" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 +msgid "``pipx`` can be upgraded or uninstalled with pip" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 +msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 +msgid "To see the full list of commands ``pipx`` offers, run" +msgstr "" + +#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 +msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:5 +msgid "Installing pip/setuptools/wheel with Linux Package Managers" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:8 +msgid "2015-09-17" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:11 +msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:14 +msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:18 +msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:25 +msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:32 +msgid "Fedora" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:34 +msgid "Fedora 21:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:36 +#: ../source/guides/installing-using-linux-tools.rst:45 +#: ../source/guides/installing-using-linux-tools.rst:124 +#: ../source/guides/installing-using-linux-tools.rst:138 +#: ../source/guides/installing-using-linux-tools.rst:158 +msgid "Python 2::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:41 +msgid "Python 3: ``sudo yum install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:43 +msgid "Fedora 22:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:50 +msgid "Python 3: ``sudo dnf install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:53 +msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:63 +msgid "CentOS/RHEL" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:65 +msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:68 +msgid "To install pip and wheel for the system Python, there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:70 +msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:77 +msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:81 +msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:85 +msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:92 +msgid "To additionally upgrade setuptools, run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:97 +msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:101 +msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:104 +msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:106 +msgid "For CentOS, see here: https://www.softwarecollections.org/en/" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:108 +msgid "Be aware that collections may not contain the most recent versions." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:110 +msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:116 +msgid "For example, for Python 3.4 on CentOS7/RHEL7::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:122 +msgid "openSUSE" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:129 +#: ../source/guides/installing-using-linux-tools.rst:143 +#: ../source/guides/installing-using-linux-tools.rst:162 +msgid "Python 3::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:135 +msgid "Debian/Ubuntu" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:150 +msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:156 +msgid "Arch Linux" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:168 +msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 +msgid "Installing packages using pip and virtual environments" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 +msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 +msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 +msgid "Installing pip" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 +msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 +msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 +msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 +msgid "Afterwards, you should have the newest pip installed in your user site:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 +msgid "The Python installers for Windows include pip. You should be able to access pip using:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 +msgid "You can make sure that pip is up-to-date by running:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 +msgid "Installing virtualenv" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 +msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 +msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 +msgid "Creating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 +msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 +msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 +msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 +msgid "venv will create a virtual Python installation in the ``env`` folder." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 +msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 +msgid "Activating a virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 +msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 +msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 +msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 +msgid "Leaving the virtual environment" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 +msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 +msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 +msgid "Installing packages" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 +msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 +msgid "pip should download requests and all of its dependencies and install them:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 +msgid "Installing specific versions" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 +msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 +msgid "To install the latest ``2.x`` release of requests:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 +msgid "To install pre-release versions of packages, use the ``--pre`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 +msgid "Installing extras" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 +msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 +msgid "Installing from source" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 +msgid "pip can install a package directly from source, for example:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 +msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 +msgid "Installing from version control systems" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 +msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 +msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 +#: ../source/tutorials/installing-packages.rst:569 +msgid "Installing from local archives" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 +msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 +msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 +msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 +msgid "Using other package indexes" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 +msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 +msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 +#: ../source/tutorials/installing-packages.rst:389 +msgid "Upgrading packages" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 +msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 +msgid "Using requirements files" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 +msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 +msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 +msgid "Freezing dependencies" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 +msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 +msgid "Which will output a list of package specifiers such as:" +msgstr "" + +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 +msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:2 +msgid "Making a PyPI-friendly README" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:4 +msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:9 +msgid "Creating a README file" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:11 +msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:13 +msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:16 +msgid "plain text" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:17 +msgid "`reStructuredText `_ (without Sphinx extensions)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:18 +msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:21 +msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:25 +msgid "Including your README in your package's metadata" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:27 +msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:33 +msgid ":ref:`description-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:34 +msgid ":ref:`description-content-type-optional`" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:36 +msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:39 +msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:45 +msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:60 +msgid "The minimum required versions of the respective tools are:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:62 +msgid "``setuptools >= 38.6.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:63 +msgid "``wheel >= 0.31.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:64 +msgid "``twine >= 1.11.0``" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:66 +msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:72 +msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:95 +msgid "Validating reStructuredText markup" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:97 +msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:100 +msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:105 +msgid "You can check your README for markup errors before uploading as follows:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:107 +msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:122 +msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:125 +msgid "Run ``twine check`` on the sdist and wheel::" +msgstr "" + +#: ../source/guides/making-a-pypi-friendly-readme.rst:129 +msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:4 +msgid "Migrating to PyPI.org" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:6 +msgid ":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``." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:12 +msgid "Publishing releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:14 +msgid "``pypi.org`` is the default upload platform as of September 2016." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:16 +msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:22 +msgid "The default upload settings switched to ``pypi.org`` in the following versions:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:24 +msgid "``twine`` 1.8.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:25 +msgid "``setuptools`` 27.0.0" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:26 +msgid "Python 2.7.13 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:27 +msgid "Python 3.4.6 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:28 +msgid "Python 3.5.3 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:29 +msgid "Python 3.6.0 (``distutils`` update)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:31 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:48 +msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:51 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:67 +msgid "(``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.)" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:73 +msgid "Registering package names & metadata" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:75 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:79 +msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:84 +msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:89 +#: ../source/guides/using-testpypi.rst:5 +msgid "Using TestPyPI" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:91 +msgid "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:" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:113 +msgid "Registering new user accounts" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:115 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:121 +msgid "Browsing packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:123 +msgid "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." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:130 +msgid "Downloading packages" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:132 +msgid "``pypi.org`` is the default host for downloading packages." +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:135 +msgid "Managing published packages and releases" +msgstr "" + +#: ../source/guides/migrating-to-pypi-org.rst:137 +msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:5 +msgid "Multi-version installs" +msgstr "" + +#: ../source/guides/multi-version-installs.rst:8 +msgid "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``)." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:13 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:19 +msgid "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." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:31 +msgid "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 ``python -c ''`` to invoke the application's main entry point directly." +msgstr "" + +#: ../source/guides/multi-version-installs.rst:38 +msgid "Refer to the `pkg_resources documentation `__ for more details." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:5 +msgid "Packaging binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:8 +msgid "2013-12-08" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:10 +msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:20 +msgid "An overview of binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:23 +msgid "Use cases" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:25 +msgid "The typical use cases for binary extensions break down into just three conventional categories:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:28 +msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:39 +msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:47 +msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:56 +msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:61 +msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:71 +msgid "Disadvantages" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:73 +msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:80 +msgid "This means that binary extensions:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:82 +msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:85 +msgid "may not be compatible with different builds of the CPython reference interpreter" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:88 +msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:91 +msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:96 +msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:101 +msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:108 +msgid "Alternatives to handcoded accelerator modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:110 +msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:115 +msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:122 +msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:132 +msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:141 +msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:150 +msgid "Alternatives to handcoded wrapper modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:152 +msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:158 +msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:162 +msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:168 +msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:175 +msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:181 +msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:185 +msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:189 +msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:203 +msgid "Alternatives for low level system access" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:205 +msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:213 +msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:222 +msgid "Implementing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:224 +msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:241 +msgid "Building binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:244 +msgid "Building extensions for multiple platforms" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:246 +msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:256 +msgid "Binary extensions for Windows" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:258 +msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:263 +msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:269 +msgid "To set up a build environment for binary extensions, the steps are as follows:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:271 +msgid "For Python 2.7" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:273 +msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:276 +msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:278 +#: ../source/guides/packaging-binary-extensions.rst:288 +#: ../source/guides/packaging-binary-extensions.rst:295 +msgid "Done." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:280 +msgid "For Python 3.4" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:282 +msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:285 +msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:287 +msgid "Set DISTUTILS_USE_SDK=1" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:290 +msgid "For Python 3.5" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:292 +msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:297 +msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:301 +msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:305 +msgid "Binary extensions for Linux" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:307 +msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:313 +msgid "Binary extensions for macOS" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:315 +msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:325 +msgid "Publishing binary extensions" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:327 +msgid "For interim guidance on this topic, see the discussion in `this issue `_." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:343 +msgid "Additional resources" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:345 +msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:352 +msgid "Cross-platform wheel generation with scikit-build" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:354 +msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:362 +msgid "Introduction to C/C++ extension modules" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:364 +msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:367 +msgid "`What are (c)python extension modules? `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:368 +msgid "`Releasing the gil `_" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:369 +msgid "`Writing cpython extension modules using C++ `_" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:3 +msgid "Packaging namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:5 +msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:24 +msgid "And you use this package in your code like so::" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:29 +msgid "Then you can break these sub-packages into two separate distributions:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:46 +msgid "Each sub-package can now be separately installed, used, and versioned." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:48 +msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:58 +msgid "Creating a namespace package" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:60 +msgid "There are currently three different approaches to creating namespace packages:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:62 +msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:66 +msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:69 +msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:73 +msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:80 +msgid "Native namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:82 +msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:97 +msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:102 +msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:117 +msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:123 +msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:129 +msgid "pkgutil-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:131 +msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:136 +msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:148 +#: ../source/guides/packaging-namespace-packages.rst:194 +msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:155 +#: ../source/guides/packaging-namespace-packages.rst:201 +msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:160 +msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:171 +msgid "pkg_resources-style namespace packages" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:173 +msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:182 +msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:206 +msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:216 +msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:223 +msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" +msgstr "" + +#: ../source/guides/packaging-namespace-packages.rst:237 +msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 +msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 +msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 +msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 +msgid "Saving credentials on GitHub" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 +msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 +msgid "Let's begin! 🚀" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 +msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 +msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 +msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 +msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 +msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 +msgid "Creating a workflow definition" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 +msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 +msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 +msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 +msgid "Defining a workflow job environment" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 +msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 +msgid "Checking out the project and building distributions" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 +msgid "Then, add the following under the ``build-n-publish`` section:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 +msgid "This will download your repository into the CI runner and then install and activate Python 3.7." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 +msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 +msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 +msgid "So add this to the steps list:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 +msgid "Publishing the distribution to PyPI and TestPyPI" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 +msgid "Finally, add the following steps at the end:" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 +msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 +msgid "That's all, folks!" +msgstr "" + +#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 +msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:5 +msgid "Single-sourcing the package version" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:8 +msgid "There are many techniques to maintain a single source of truth for the version number of your project:" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:11 +msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:38 +msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:47 +msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:52 +msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:55 +msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:58 +msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:65 +msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:76 +msgid "Example using this technique: `warehouse `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:78 +msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:86 +msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:91 +msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:95 +msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:110 +msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:114 +msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:128 +msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:134 +msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:138 +msgid "Example using this technique: `setuptools `_." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:141 +msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:155 +msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." +msgstr "" + +#: ../source/guides/single-sourcing-package-version.rst:161 +msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:5 +msgid "Supporting multiple Python versions" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:37 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:43 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:49 +msgid "Automated testing and continuous integration" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:51 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:60 +msgid "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:" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:66 +msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:69 +msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:80 +msgid "Both `Travis CI`_ 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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:85 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:89 +msgid "Tools for single-source Python packages" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:91 +msgid "`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_." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:100 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:107 +msgid "a Python 2 (by syntax) module in a Python 3 project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:108 +msgid "a Python 3 (by syntax) module in a *Python 2* project." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:110 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:117 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:124 +msgid "What's in which Python?" +msgstr "" + +#: ../source/guides/supporting-multiple-python-versions.rst:126 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:3 +msgid "Supporting Windows using Appveyor" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:6 +msgid "2015-12-03" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:8 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:20 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:24 +msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:30 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:38 +msgid "Setting up" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:40 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:45 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:49 +msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:54 +msgid "Adding Appveyor support to your project" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:56 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:61 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:69 +msgid "appveyor.yml" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:75 +msgid "This file can be downloaded from `here `__." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:77 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:80 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:88 +msgid "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``)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:94 +msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:97 +msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:100 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:109 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:114 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:119 +msgid "Support script" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:121 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:126 +msgid "`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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:133 +msgid "You can simply download the batch file and include it in your project unchanged." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:137 +msgid "Access to the built wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:139 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:147 +msgid "Additional notes" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:150 +msgid "Testing with tox" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:152 +msgid "Many projects use the `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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:156 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:160 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:165 +msgid "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" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:170 +msgid "``DISTUTILS_USE_SDK``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:171 +msgid "``MSSdk``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:172 +msgid "``INCLUDE``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:173 +msgid "``LIB``" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:175 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:181 +msgid "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 Travis or 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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:188 +msgid "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``." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:192 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:197 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:203 +msgid "Automatically uploading wheels" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:205 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:210 +msgid "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)." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:216 +msgid "External dependencies" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:218 +msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:221 +msgid "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." +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:230 +msgid "Support scripts" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:232 +msgid "For reference, the SDK setup support script is listed here:" +msgstr "" + +#: ../source/guides/supporting-windows-using-appveyor.rst:234 +msgid "``appveyor-sample/build.cmd``" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:5 +msgid "Tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:7 +msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:12 +msgid "Application dependency management" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:14 +msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:18 +msgid "When ``pipenv`` does not meet your use case, consider other tools like:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:20 +msgid ":ref:`pip`" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:22 +msgid "`pip-tools `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:24 +msgid "`Poetry `_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:27 +msgid "Installation tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:29 +msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:34 +msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:37 +msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:40 +msgid ":ref:`buildout`: primarily focused on the web development community" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:42 +msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:47 +msgid "Packaging tool recommendations" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:49 +msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:52 +msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:56 +msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:61 +msgid "Publishing platform migration" +msgstr "" + +#: ../source/guides/tool-recommendations.rst:63 +msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:67 +msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:72 +msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:77 +msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:82 +msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:88 +msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:93 +msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:102 +msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." +msgstr "" + +#: ../source/guides/tool-recommendations.rst:107 +msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:5 +msgid "Including files in source distributions with ``MANIFEST.in``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:7 +msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:17 +msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:22 +msgid "How files are included in an sdist" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:24 +msgid "The following files are included in a source distribution by default:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:26 +msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:28 +msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:30 +msgid "scripts specified by the ``scripts`` ``setup()`` argument" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:31 +msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:33 +msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:35 +msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:37 +msgid "all files matching the pattern :file:`test/test*.py`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:38 +msgid ":file:`setup.py` (or whatever you called your setup script)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:39 +msgid ":file:`setup.cfg`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:40 +msgid ":file:`README`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:41 +msgid ":file:`README.txt`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:42 +msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:43 +msgid ":file:`README.md` (setuptools 36.4.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:44 +msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:45 +msgid ":file:`MANIFEST.in`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:47 +msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:52 +msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:60 +msgid ":file:`MANIFEST.in` commands" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:62 +msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:67 +msgid "Command" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid ":samp:`include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:69 +msgid "Add all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid ":samp:`exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:70 +msgid "Remove all files matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:71 +msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:72 +msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid ":samp:`global-include {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:73 +msgid "Add all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid ":samp:`global-exclude {pat1} {pat2} ...`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:74 +msgid "Remove all files anywhere in the source tree matching any of the listed patterns" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid ":samp:`graft {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:75 +msgid "Add all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid ":samp:`prune {dir-pattern}`" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:76 +msgid "Remove all files under directories matching ``dir-pattern``" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:79 +msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:87 +msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:91 +msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." +msgstr "" + +#: ../source/guides/using-manifest-in.rst:95 +msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" +msgstr "" + +#: ../source/guides/using-manifest-in.rst:101 +msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." +msgstr "" + +#: ../source/guides/using-testpypi.rst:7 +msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" +msgstr "" + +#: ../source/guides/using-testpypi.rst:13 +msgid "Registering your account" +msgstr "" + +#: ../source/guides/using-testpypi.rst:15 +msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." +msgstr "" + +#: ../source/guides/using-testpypi.rst:19 +msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." +msgstr "" + +#: ../source/guides/using-testpypi.rst:24 +msgid "Using TestPyPI with Twine" +msgstr "" + +#: ../source/guides/using-testpypi.rst:26 +msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:33 +msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." +msgstr "" + +#: ../source/guides/using-testpypi.rst:39 +msgid "Using TestPyPI with pip" +msgstr "" + +#: ../source/guides/using-testpypi.rst:41 +msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" +msgstr "" + +#: ../source/guides/using-testpypi.rst:56 +msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" +msgstr "" + +#: ../source/guides/using-testpypi.rst:73 +msgid "Setting up TestPyPI in :file:`.pypirc`" +msgstr "" + +#: ../source/guides/using-testpypi.rst:75 +msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" +msgstr "" + +#: ../source/index.rst:3 +#: ../source/key_projects.rst:181 +msgid "Python Packaging User Guide" +msgstr "" + +#: ../source/index.rst:5 +msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." +msgstr "" + +#: ../source/index.rst:5 +msgid "python, packaging, guide, tutorial" +msgstr "" + +#: ../source/index.rst:24 +msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." +msgstr "" + +#: ../source/index.rst:28 +msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" +msgstr "" + +#: ../source/index.rst:36 +msgid "Get started" +msgstr "" + +#: ../source/index.rst:38 +msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" +msgstr "" + +#: ../source/index.rst:41 +msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" +msgstr "" + +#: ../source/index.rst:43 +msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" +msgstr "" + +#: ../source/index.rst:45 +msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" +msgstr "" + +#: ../source/index.rst:47 +msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" +msgstr "" + +#: ../source/index.rst:52 +msgid "Learn more" +msgstr "" + +#: ../source/index.rst:54 +msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" +msgstr "" + +#: ../source/index.rst:56 +msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/index.rst:58 +msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." +msgstr "" + +#: ../source/index.rst:60 +msgid "The :doc:`specifications/index` section for packaging interoperability specifications." +msgstr "" + +#: ../source/index.rst:62 +msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." +msgstr "" + +#: ../source/key_projects.rst:6 +msgid "Project Summaries" +msgstr "" + +#: ../source/key_projects.rst:8 +msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." +msgstr "" + +#: ../source/key_projects.rst:14 +msgid "PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:19 +msgid "bandersnatch" +msgstr "" + +#: ../source/key_projects.rst:21 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:25 +msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." +msgstr "" + +#: ../source/key_projects.rst:35 +msgid "build" +msgstr "" + +#: ../source/key_projects.rst:37 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:42 +msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." +msgstr "" + +#: ../source/key_projects.rst:49 +msgid "cibuildwheel" +msgstr "" + +#: ../source/key_projects.rst:51 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" +msgstr "" + +#: ../source/key_projects.rst:58 +msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." +msgstr "" + +#: ../source/key_projects.rst:64 +msgid "distlib" +msgstr "" + +#: ../source/key_projects.rst:66 +msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:71 +msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." +msgstr "" + +#: ../source/key_projects.rst:80 +msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." +msgstr "" + +#: ../source/key_projects.rst:90 +msgid "packaging" +msgstr "" + +#: ../source/key_projects.rst:92 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:97 +msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." +msgstr "" + +#: ../source/key_projects.rst:99 +msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." +msgstr "" + +#: ../source/key_projects.rst:107 +msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." +msgstr "" + +#: ../source/key_projects.rst:119 +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "pip" +msgstr "" + +#: ../source/key_projects.rst:121 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:126 +msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." +msgstr "" + +#: ../source/key_projects.rst:129 +msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." +msgstr "" + +#: ../source/key_projects.rst:137 +msgid "Pipenv" +msgstr "" + +#: ../source/key_projects.rst:139 +msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:144 +msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." +msgstr "" + +#: ../source/key_projects.rst:148 +msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." +msgstr "" + +#: ../source/key_projects.rst:159 +msgid "Pipfile" +msgstr "" + +#: ../source/key_projects.rst:161 +msgid "`Source `__" +msgstr "" + +#: ../source/key_projects.rst:163 +msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." +msgstr "" + +#: ../source/key_projects.rst:170 +msgid "pipx" +msgstr "" + +#: ../source/key_projects.rst:172 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:176 +msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." +msgstr "" + +#: ../source/key_projects.rst:183 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:187 +msgid "This guide!" +msgstr "" + +#: ../source/key_projects.rst:192 +msgid "readme_renderer" +msgstr "" + +#: ../source/key_projects.rst:194 +msgid "`GitHub and docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:197 +msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." +msgstr "" + +#: ../source/key_projects.rst:208 +msgid "setuptools" +msgstr "" + +#: ../source/key_projects.rst:210 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:215 +msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." +msgstr "" + +#: ../source/key_projects.rst:220 +msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." +msgstr "" + +#: ../source/key_projects.rst:227 +msgid "trove-classifiers" +msgstr "" + +#: ../source/key_projects.rst:229 +msgid "`Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:233 +msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." +msgstr "" + +#: ../source/key_projects.rst:239 +msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." +msgstr "" + +#: ../source/key_projects.rst:253 +msgid "twine" +msgstr "" + +#: ../source/key_projects.rst:255 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:260 +msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." +msgstr "" + +#: ../source/key_projects.rst:270 +#: ../source/overview.rst:415 +msgid "virtualenv" +msgstr "" + +#: ../source/key_projects.rst:272 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:277 +msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/key_projects.rst:290 +msgid "Warehouse" +msgstr "" + +#: ../source/key_projects.rst:292 +msgid "`Docs `__ | `Issues `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:296 +msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." +msgstr "" + +#: ../source/key_projects.rst:304 +msgid "wheel" +msgstr "" + +#: ../source/key_projects.rst:306 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:311 +msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." +msgstr "" + +#: ../source/key_projects.rst:315 +msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." +msgstr "" + +#: ../source/key_projects.rst:324 +msgid "Non-PyPA Projects" +msgstr "" + +#: ../source/key_projects.rst:329 +msgid "bento" +msgstr "" + +#: ../source/key_projects.rst:331 +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:336 +msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." +msgstr "" + +#: ../source/key_projects.rst:344 +msgid "buildout" +msgstr "" + +#: ../source/key_projects.rst:346 +msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:351 +msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." +msgstr "" + +#: ../source/key_projects.rst:358 +msgid "conda" +msgstr "" + +#: ../source/key_projects.rst:360 +msgid "`Docs `__" +msgstr "" + +#: ../source/key_projects.rst:362 +msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." +msgstr "" + +#: ../source/key_projects.rst:369 +msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." +msgstr "" + +#: ../source/key_projects.rst:373 +msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." +msgstr "" + +#: ../source/key_projects.rst:386 +msgid "devpi" +msgstr "" + +#: ../source/key_projects.rst:388 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:392 +msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." +msgstr "" + +#: ../source/key_projects.rst:401 +msgid "flit" +msgstr "" + +#: ../source/key_projects.rst:403 +msgid "`Docs `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:407 +msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." +msgstr "" + +#: ../source/key_projects.rst:412 +msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." +msgstr "" + +#: ../source/key_projects.rst:422 +msgid "enscons" +msgstr "" + +#: ../source/key_projects.rst:424 +msgid "`Source `__ | `Issues `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:428 +msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." +msgstr "" + +#: ../source/key_projects.rst:443 +msgid "Hashdist" +msgstr "" + +#: ../source/key_projects.rst:445 +msgid "`Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:448 +msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." +msgstr "" + +#: ../source/key_projects.rst:460 +msgid "hatch" +msgstr "" + +#: ../source/key_projects.rst:462 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:465 +msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." +msgstr "" + +#: ../source/key_projects.rst:475 +msgid "multibuild" +msgstr "" + +#: ../source/key_projects.rst:477 +msgid "`GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:479 +msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." +msgstr "" + +#: ../source/key_projects.rst:485 +msgid "pex" +msgstr "" + +#: ../source/key_projects.rst:487 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:491 +msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." +msgstr "" + +#: ../source/key_projects.rst:500 +msgid "pip-tools" +msgstr "" + +#: ../source/key_projects.rst:502 +msgid "`GitHub and Docs `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:505 +msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." +msgstr "" + +#: ../source/key_projects.rst:517 +msgid "piwheels" +msgstr "" + +#: ../source/key_projects.rst:519 +msgid "`Website `__ | `Docs `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:523 +msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." +msgstr "" + +#: ../source/key_projects.rst:532 +msgid "poetry" +msgstr "" + +#: ../source/key_projects.rst:534 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:538 +msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." +msgstr "" + +#: ../source/key_projects.rst:548 +msgid "pypiserver" +msgstr "" + +#: ../source/key_projects.rst:550 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:554 +msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." +msgstr "" + +#: ../source/key_projects.rst:564 +msgid "scikit-build" +msgstr "" + +#: ../source/key_projects.rst:566 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:570 +msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." +msgstr "" + +#: ../source/key_projects.rst:582 +msgid "shiv" +msgstr "" + +#: ../source/key_projects.rst:584 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:588 +msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." +msgstr "" + +#: ../source/key_projects.rst:598 +msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" +msgstr "" + +#: ../source/key_projects.rst:603 +msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." +msgstr "" + +#: ../source/key_projects.rst:611 +msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." +msgstr "" + +#: ../source/key_projects.rst:617 +msgid "zest.releaser" +msgstr "" + +#: ../source/key_projects.rst:619 +msgid "`Docs `__ | `GitHub `__ | `PyPI `__" +msgstr "" + +#: ../source/key_projects.rst:623 +msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." +msgstr "" + +#: ../source/key_projects.rst:630 +msgid "Standard Library Projects" +msgstr "" + +#: ../source/key_projects.rst:635 +msgid "ensurepip" +msgstr "" + +#: ../source/key_projects.rst:637 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:640 +msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." +msgstr "" + +#: ../source/key_projects.rst:649 +msgid "distutils" +msgstr "" + +#: ../source/key_projects.rst:651 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:654 +msgid "The original Python packaging system, added to the standard library in Python 2.0." +msgstr "" + +#: ../source/key_projects.rst:657 +msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." +msgstr "" + +#: ../source/key_projects.rst:670 +msgid "venv" +msgstr "" + +#: ../source/key_projects.rst:672 +msgid "`Docs `__ | `Issues `__" +msgstr "" + +#: ../source/key_projects.rst:675 +msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." +msgstr "" + +#: ../source/news.rst:2 +msgid "News" +msgstr "" + +#: ../source/news.rst:5 +msgid "September 2019" +msgstr "" + +#: ../source/news.rst:6 +msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" +msgstr "" + +#: ../source/news.rst:9 +msgid "August 2019" +msgstr "" + +#: ../source/news.rst:10 +msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" +msgstr "" + +#: ../source/news.rst:13 +msgid "July 2019" +msgstr "" + +#: ../source/news.rst:14 +msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" +msgstr "" + +#: ../source/news.rst:15 +msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" +msgstr "" + +#: ../source/news.rst:16 +msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" +msgstr "" + +#: ../source/news.rst:17 +msgid "Updated directory layout examples for consistency. (:pr:`611`)" +msgstr "" + +#: ../source/news.rst:18 +msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" +msgstr "" + +#: ../source/news.rst:21 +msgid "June 2019" +msgstr "" + +#: ../source/news.rst:22 +msgid "Fixed some typos. (:pr:`620`)" +msgstr "" + +#: ../source/news.rst:25 +msgid "May 2019" +msgstr "" + +#: ../source/news.rst:26 +msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" +msgstr "" + +#: ../source/news.rst:27 +msgid "Added a MANIFEST.in guide page. (:pr:`609`)" +msgstr "" + +#: ../source/news.rst:30 +msgid "April 2019" +msgstr "" + +#: ../source/news.rst:31 +msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" +msgstr "" + +#: ../source/news.rst:32 +msgid "Reduced emphasis on virtualenv. (:pr:`606`)" +msgstr "" + +#: ../source/news.rst:35 +msgid "March 2019" +msgstr "" + +#: ../source/news.rst:36 +msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" +msgstr "" + +#: ../source/news.rst:37 +msgid "Covered RTD details for contributing. (:pr:`600`)" +msgstr "" + +#: ../source/news.rst:40 +msgid "February 2019" +msgstr "" + +#: ../source/news.rst:41 +msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" +msgstr "" + +#: ../source/news.rst:42 +msgid "Added instructions to install Python CLI applications. (:pr:`594`)" +msgstr "" + +#: ../source/news.rst:45 +msgid "January 2019" +msgstr "" + +#: ../source/news.rst:46 +msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" +msgstr "" + +#: ../source/news.rst:47 +msgid "Updated Sphinx and Nox. (:pr:`591`)" +msgstr "" + +#: ../source/news.rst:48 +msgid "Referenced Twine from Python3. (:pr:`581`)" +msgstr "" + +#: ../source/news.rst:51 +msgid "December 2018" +msgstr "" + +#: ../source/news.rst:52 +msgid "No programmers in the office!" +msgstr "" + +#: ../source/news.rst:55 +msgid "November 2018" +msgstr "" + +#: ../source/news.rst:56 +msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" +msgstr "" + +#: ../source/news.rst:57 +msgid "Changed bumpversion to bump2version. (:pr:`572`)" +msgstr "" + +#: ../source/news.rst:58 +msgid "Added single-sourcing package version example. (:pr:`573`)" +msgstr "" + +#: ../source/news.rst:59 +msgid "Added a guide for creating documentation. (:pr:`568`)" +msgstr "" + +#: ../source/news.rst:62 +msgid "October 2018" +msgstr "" + +#: ../source/news.rst:63 +msgid "Updated Nox package name. (:pr:`566`)" +msgstr "" + +#: ../source/news.rst:64 +msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" +msgstr "" + +#: ../source/news.rst:67 +msgid "September 2018" +msgstr "" + +#: ../source/news.rst:68 +msgid "Added a section on checking RST markup. (:pr:`554`)" +msgstr "" + +#: ../source/news.rst:69 +msgid "Updated user installs page. (:pr:`558`)" +msgstr "" + +#: ../source/news.rst:70 +msgid "Updated Google BigQuery urls. (:pr:`556`)" +msgstr "" + +#: ../source/news.rst:71 +msgid "Replaced tar command with working command. (:pr:`552`)" +msgstr "" + +#: ../source/news.rst:72 +msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" +msgstr "" + +#: ../source/news.rst:75 +msgid "August 2018" +msgstr "" + +#: ../source/news.rst:76 +msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" +msgstr "" + +#: ../source/news.rst:77 +msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" +msgstr "" + +#: ../source/news.rst:78 +msgid "Updated Python version supported by virtualenv. (:pr:`538`)" +msgstr "" + +#: ../source/news.rst:79 +msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" +msgstr "" + +#: ../source/news.rst:82 +msgid "July 2018" +msgstr "" + +#: ../source/news.rst:84 +msgid "Improved binary extension docs. (:pr:`531`)" +msgstr "" + +#: ../source/news.rst:85 +msgid "Added scikit-build to key projects. (:pr:`530`)" +msgstr "" + +#: ../source/news.rst:88 +msgid "June 2018" +msgstr "" + +#: ../source/news.rst:90 +msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" +msgstr "" + +#: ../source/news.rst:91 +msgid "Updated Markdown descriptions explanation. (:pr:`522`)" +msgstr "" + +#: ../source/news.rst:94 +msgid "May 2018" +msgstr "" + +#: ../source/news.rst:96 +msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" +msgstr "" + +#: ../source/news.rst:97 +msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" +msgstr "" + +#: ../source/news.rst:98 +msgid "Simplified packaging tutorial. (:pr:`498`)" +msgstr "" + +#: ../source/news.rst:99 +msgid "Updated Windows users instructions for clarity. (:pr:`493`)" +msgstr "" + +#: ../source/news.rst:100 +msgid "Updated the license section description for completeness. (:pr:`492`)" +msgstr "" + +#: ../source/news.rst:101 +msgid "Added specification-style document to contributing section. (:pr:`489`)" +msgstr "" + +#: ../source/news.rst:102 +msgid "Added documentation types to contributing guide. (:pr:`485`)" +msgstr "" + +#: ../source/news.rst:105 +msgid "April 2018" +msgstr "" + +#: ../source/news.rst:107 +msgid "Added README guide. (:pr:`461`)" +msgstr "" + +#: ../source/news.rst:108 +msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" +msgstr "" + +#: ../source/news.rst:109 +msgid "Added instructions for Warehouse. (:pr:`471`)" +msgstr "" + +#: ../source/news.rst:110 +msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" +msgstr "" + +#: ../source/news.rst:111 +msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" +msgstr "" + +#: ../source/news.rst:112 +msgid "Added a guide for phasing out Python versions. (:pr:`459`)" +msgstr "" + +#: ../source/news.rst:113 +msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" +msgstr "" + +#: ../source/news.rst:116 +msgid "March 2018" +msgstr "" + +#: ../source/news.rst:118 +msgid "Updated \"installing scientific packages\". (:pr:`455`)" +msgstr "" + +#: ../source/news.rst:119 +msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" +msgstr "" + +#: ../source/news.rst:120 +msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" +msgstr "" + +#: ../source/news.rst:121 +msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" +msgstr "" + +#: ../source/news.rst:124 +msgid "February 2018" +msgstr "" + +#: ../source/news.rst:126 +msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" +msgstr "" + +#: ../source/news.rst:127 +msgid "Updated PyPI migration info. (:pr:`439`)" +msgstr "" + +#: ../source/news.rst:128 +msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" +msgstr "" + +#: ../source/news.rst:129 +msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" +msgstr "" + +#: ../source/news.rst:130 +msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" +msgstr "" + +#: ../source/news.rst:133 +msgid "January 2018" +msgstr "" + +#: ../source/news.rst:135 +msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" +msgstr "" + +#: ../source/news.rst:136 +msgid "Updated README.rst explanation. (:pr:`419`)" +msgstr "" + +#: ../source/news.rst:139 +msgid "December 2017" +msgstr "" + +#: ../source/news.rst:141 +msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" +msgstr "" + +#: ../source/news.rst:142 +msgid "Noted which fields can be used with environment markers. (:pr:`416`)" +msgstr "" + +#: ../source/news.rst:143 +msgid "Updated Requires-Python section. (:pr:`414`)" +msgstr "" + +#: ../source/news.rst:144 +msgid "Added news page. (:pr:`404`)" +msgstr "" + +#: ../source/news.rst:147 +msgid "November 2017" +msgstr "" + +#: ../source/news.rst:149 +msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" +msgstr "" + +#: ../source/news.rst:150 +msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" +msgstr "" + +#: ../source/news.rst:152 +msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:153 +msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" +msgstr "" + +#: ../source/news.rst:156 +msgid "October 2017" +msgstr "" + +#: ../source/news.rst:158 +msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" +msgstr "" + +#: ../source/news.rst:159 +msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" +msgstr "" + +#: ../source/news.rst:160 +msgid "Split the specifications page into multiple pages. (:pr:`386`)" +msgstr "" + +#: ../source/news.rst:163 +msgid "September 2017" +msgstr "" + +#: ../source/news.rst:165 +msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" +msgstr "" + +#: ../source/news.rst:167 +msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" +msgstr "" + +#: ../source/news.rst:170 +msgid "August 2017" +msgstr "" + +#: ../source/news.rst:172 +msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" +msgstr "" + +#: ../source/news.rst:173 +msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" +msgstr "" + +#: ../source/news.rst:174 +msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" +msgstr "" + +#: ../source/news.rst:177 +msgid "July 2017" +msgstr "" + +#: ../source/news.rst:179 +msgid "Added ``flit`` to the key projects list. (:pr:`358`)" +msgstr "" + +#: ../source/news.rst:180 +msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" +msgstr "" + +#: ../source/news.rst:181 +msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" +msgstr "" + +#: ../source/news.rst:182 +msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" +msgstr "" + +#: ../source/news.rst:183 +msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" +msgstr "" + +#: ../source/news.rst:186 +msgid "June 2017" +msgstr "" + +#: ../source/news.rst:188 +msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" +msgstr "" + +#: ../source/news.rst:189 +msgid "Added documentation for ``python_requires``. (:pr:`338`)" +msgstr "" + +#: ../source/news.rst:190 +msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" +msgstr "" + +#: ../source/news.rst:191 +msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" +msgstr "" + +#: ../source/news.rst:192 +msgid "Added a license section to the distributing guide. (:pr:`331`)" +msgstr "" + +#: ../source/news.rst:193 +msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" +msgstr "" + +#: ../source/news.rst:194 +msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" +msgstr "" + +#: ../source/news.rst:195 +msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" +msgstr "" + +#: ../source/news.rst:196 +msgid "Switched to the PyPA theme. (:pr:`305`)" +msgstr "" + +#: ../source/news.rst:197 +msgid "Re-organized the documentation into the new structure. (:pr:`318`)" +msgstr "" + +#: ../source/news.rst:200 +msgid "May 2017" +msgstr "" + +#: ../source/news.rst:202 +msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" +msgstr "" + +#: ../source/news.rst:203 +msgid "Added contributor and style guide. (:pr:`307`)" +msgstr "" + +#: ../source/news.rst:204 +msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" +msgstr "" + +#: ../source/news.rst:207 +msgid "April 2017" +msgstr "" + +#: ../source/news.rst:209 +msgid "Added travis configuration for testing pull requests. (:pr:`300`)" +msgstr "" + +#: ../source/news.rst:210 +msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" +msgstr "" + +#: ../source/news.rst:211 +msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" +msgstr "" + +#: ../source/news.rst:212 +msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" +msgstr "" + +#: ../source/news.rst:213 +msgid "Added a topic on namespace packages. (:pr:`290`)" +msgstr "" + +#: ../source/news.rst:214 +msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" +msgstr "" + +#: ../source/news.rst:215 +msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" +msgstr "" + +#: ../source/news.rst:216 +msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" +msgstr "" + +#: ../source/news.rst:217 +msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" +msgstr "" + +#: ../source/news.rst:219 +msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" +msgstr "" + +#: ../source/news.rst:223 +msgid "March 2017" +msgstr "" + +#: ../source/news.rst:225 +msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" +msgstr "" + +#: ../source/news.rst:228 +msgid "February 2017" +msgstr "" + +#: ../source/news.rst:230 +msgid "Added :pep:`518`. (:pr:`281`)" +msgstr "" + +#: ../source/overview.rst:3 +msgid "An Overview of Packaging for Python" +msgstr "" + +#: ../source/overview.rst:7 +msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." +msgstr "" + +#: ../source/overview.rst:12 +msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." +msgstr "" + +#: ../source/overview.rst:18 +msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." +msgstr "" + +#: ../source/overview.rst:26 +msgid "Thinking about deployment" +msgstr "" + +#: ../source/overview.rst:28 +msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" +msgstr "" + +#: ../source/overview.rst:32 +msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" +msgstr "" + +#: ../source/overview.rst:35 +msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" +msgstr "" + +#: ../source/overview.rst:37 +msgid "Is your software installed individually, or in large deployment batches?" +msgstr "" + +#: ../source/overview.rst:39 +msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." +msgstr "" + +#: ../source/overview.rst:46 +msgid "Packaging Python libraries and tools" +msgstr "" + +#: ../source/overview.rst:48 +msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/overview.rst:53 +msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." +msgstr "" + +#: ../source/overview.rst:59 +msgid "Python modules" +msgstr "" + +#: ../source/overview.rst:61 +msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." +msgstr "" + +#: ../source/overview.rst:66 +msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." +msgstr "" + +#: ../source/overview.rst:73 +msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." +msgstr "" + +#: ../source/overview.rst:78 +msgid "Python source distributions" +msgstr "" + +#: ../source/overview.rst:80 +msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." +msgstr "" + +#: ../source/overview.rst:84 +msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." +msgstr "" + +#: ../source/overview.rst:90 +msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." +msgstr "" + +#: ../source/overview.rst:95 +msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." +msgstr "" + +#: ../source/overview.rst:100 +msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." +msgstr "" + +#: ../source/overview.rst:107 +msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" +msgstr "" + +#: ../source/overview.rst:114 +msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." +msgstr "" + +#: ../source/overview.rst:119 +msgid "Python binary distributions" +msgstr "" + +#: ../source/overview.rst:121 +msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." +msgstr "" + +#: ../source/overview.rst:125 +msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." +msgstr "" + +#: ../source/overview.rst:132 +msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." +msgstr "" + +#: ../source/overview.rst:140 +msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." +msgstr "" + +#: ../source/overview.rst:148 +msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." +msgstr "" + +#: ../source/overview.rst:155 +msgid "Packaging Python applications" +msgstr "" + +#: ../source/overview.rst:157 +msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." +msgstr "" + +#: ../source/overview.rst:162 +msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." +msgstr "" + +#: ../source/overview.rst:166 +msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." +msgstr "" + +#: ../source/overview.rst:172 +msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." +msgstr "" + +#: ../source/overview.rst:176 +msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." +msgstr "" + +#: ../source/overview.rst:181 +msgid "Depending on a framework" +msgstr "" + +#: ../source/overview.rst:183 +msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." +msgstr "" + +#: ../source/overview.rst:189 +msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." +msgstr "" + +#: ../source/overview.rst:195 +msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." +msgstr "" + +#: ../source/overview.rst:199 +msgid "Service platforms" +msgstr "" + +#: ../source/overview.rst:201 +msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." +msgstr "" + +#: ../source/overview.rst:205 +msgid "`Heroku `_" +msgstr "" + +#: ../source/overview.rst:206 +msgid "`Google App Engine `_" +msgstr "" + +#: ../source/overview.rst:207 +msgid "`PythonAnywhere `_" +msgstr "" + +#: ../source/overview.rst:208 +msgid "`OpenShift `_" +msgstr "" + +#: ../source/overview.rst:209 +msgid "\"Serverless\" frameworks like `Zappa `_" +msgstr "" + +#: ../source/overview.rst:211 +msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." +msgstr "" + +#: ../source/overview.rst:216 +msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." +msgstr "" + +#: ../source/overview.rst:220 +msgid "Web browsers and mobile applications" +msgstr "" + +#: ../source/overview.rst:222 +msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." +msgstr "" + +#: ../source/overview.rst:227 +msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" +msgstr "" + +#: ../source/overview.rst:231 +msgid "`Kivy `_" +msgstr "" + +#: ../source/overview.rst:232 +msgid "`Beeware `_" +msgstr "" + +#: ../source/overview.rst:233 +msgid "`Brython `_" +msgstr "" + +#: ../source/overview.rst:234 +msgid "`Flexx `_" +msgstr "" + +#: ../source/overview.rst:236 +msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." +msgstr "" + +#: ../source/overview.rst:241 +msgid "Depending on a pre-installed Python" +msgstr "" + +#: ../source/overview.rst:243 +msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." +msgstr "" + +#: ../source/overview.rst:249 +msgid "Technologies which support this model:" +msgstr "" + +#: ../source/overview.rst:251 +msgid "`PEX `_ (Python EXecutable)" +msgstr "" + +#: ../source/overview.rst:252 +msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" +msgstr "" + +#: ../source/overview.rst:253 +msgid "`shiv `_ (requires Python 3)" +msgstr "" + +#: ../source/overview.rst:255 +msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." +msgstr "" + +#: ../source/overview.rst:260 +msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." +msgstr "" + +#: ../source/overview.rst:267 +msgid "Depending on a separate software distribution ecosystem" +msgstr "" + +#: ../source/overview.rst:269 +msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." +msgstr "" + +#: ../source/overview.rst:274 +msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." +msgstr "" + +#: ../source/overview.rst:284 +msgid "Instructions on building and publishing for the Anaconda ecosystem:" +msgstr "" + +#: ../source/overview.rst:286 +msgid "`Building libraries and applications with conda `_" +msgstr "" + +#: ../source/overview.rst:287 +msgid "`Transitioning a native Python package to Anaconda `_" +msgstr "" + +#: ../source/overview.rst:289 +msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" +msgstr "" + +#: ../source/overview.rst:293 +msgid "`Enthought Canopy `_" +msgstr "" + +#: ../source/overview.rst:294 +msgid "`ActiveState ActivePython `_" +msgstr "" + +#: ../source/overview.rst:295 +msgid "`WinPython `_" +msgstr "" + +#: ../source/overview.rst:300 +msgid "Bringing your own Python executable" +msgstr "" + +#: ../source/overview.rst:302 +msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." +msgstr "" + +#: ../source/overview.rst:306 +msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." +msgstr "" + +#: ../source/overview.rst:311 +msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." +msgstr "" + +#: ../source/overview.rst:315 +msgid "A selection of Python freezers:" +msgstr "" + +#: ../source/overview.rst:317 +msgid "`pyInstaller `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:318 +msgid "`cx_Freeze `_ - Cross-platform" +msgstr "" + +#: ../source/overview.rst:319 +msgid "`constructor `_ - For command-line installers" +msgstr "" + +#: ../source/overview.rst:320 +msgid "`py2exe `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:321 +msgid "`py2app `_ - Mac only" +msgstr "" + +#: ../source/overview.rst:322 +msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" +msgstr "" + +#: ../source/overview.rst:323 +msgid "`osnap `_ - Windows and Mac" +msgstr "" + +#: ../source/overview.rst:324 +msgid "`pynsist `_ - Windows only" +msgstr "" + +#: ../source/overview.rst:326 +msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." +msgstr "" + +#: ../source/overview.rst:332 +msgid "Bringing your own userspace" +msgstr "" + +#: ../source/overview.rst:334 +msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." +msgstr "" + +#: ../source/overview.rst:341 +msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." +msgstr "" + +#: ../source/overview.rst:344 +msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" +msgstr "" + +#: ../source/overview.rst:347 +msgid "`AppImage `_" +msgstr "" + +#: ../source/overview.rst:348 +msgid "`Docker `_" +msgstr "" + +#: ../source/overview.rst:349 +msgid "`Flatpak `_" +msgstr "" + +#: ../source/overview.rst:350 +msgid "`Snapcraft `_" +msgstr "" + +#: ../source/overview.rst:353 +msgid "Bringing your own kernel" +msgstr "" + +#: ../source/overview.rst:355 +msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." +msgstr "" + +#: ../source/overview.rst:360 +msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" +msgstr "" + +#: ../source/overview.rst:364 +msgid "`Vagrant `_" +msgstr "" + +#: ../source/overview.rst:365 +msgid "`VHD `_, `AMI `_, and `other formats `_" +msgstr "" + +#: ../source/overview.rst:366 +msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" +msgstr "" + +#: ../source/overview.rst:369 +msgid "Bringing your own hardware" +msgstr "" + +#: ../source/overview.rst:371 +msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." +msgstr "" + +#: ../source/overview.rst:375 +msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." +msgstr "" + +#: ../source/overview.rst:379 +msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." +msgstr "" + +#: ../source/overview.rst:389 +msgid "The simplified gamut of technologies used to package Python applications." +msgstr "" + +#: ../source/overview.rst:392 +msgid "What about..." +msgstr "" + +#: ../source/overview.rst:394 +msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." +msgstr "" + +#: ../source/overview.rst:398 +msgid "Operating system packages" +msgstr "" + +#: ../source/overview.rst:400 +msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." +msgstr "" + +#: ../source/overview.rst:411 +msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." +msgstr "" + +#: ../source/overview.rst:417 +msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." +msgstr "" + +#: ../source/overview.rst:427 +msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." +msgstr "" + +#: ../source/overview.rst:432 +msgid "Security" +msgstr "" + +#: ../source/overview.rst:434 +msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." +msgstr "" + +#: ../source/overview.rst:437 +msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." +msgstr "" + +#: ../source/overview.rst:446 +msgid "Wrap up" +msgstr "" + +#: ../source/overview.rst:448 +msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:6 +msgid "Binary distribution format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:8 +msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:13 +msgid "Abstract" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:15 +msgid "This PEP describes a built-package format for Python called \"wheel\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:17 +msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:27 +msgid "PEP Acceptance" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:29 +msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:34 +msgid "Rationale" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:36 +msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:43 +msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:52 +msgid "Details" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:55 +msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:57 +msgid "Wheel installation notionally consists of two phases:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:59 +msgid "Unpack." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:61 +msgid "Parse ``distribution-1.0.dist-info/WHEEL``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:62 +msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:64 +msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:66 +msgid "Else unpack archive into platlib (site-packages)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:68 +msgid "Spread." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:70 +msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:72 +msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:78 +msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:80 +msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:82 +msgid "Remove empty ``distribution-1.0.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:83 +msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:87 +msgid "Recommended installer features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:97 +msgid "Rewrite ``#!python``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:90 +msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:96 +msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:102 +msgid "Generate script wrappers." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:100 +msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:105 +msgid "Recommended archiver features" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:112 +msgid "Place ``.dist-info`` at the end of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:108 +msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:115 +msgid "File Format" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:118 +msgid "File name convention" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:120 +msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "distribution" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:124 +msgid "Distribution name, e.g. 'django', 'pyramid'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "Distribution version, e.g. 1.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:135 +msgid "build tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:130 +msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "language implementation and version tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:138 +msgid "E.g. 'py27', 'py2', 'py3'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "abi tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:141 +msgid "E.g. 'cp33m', 'abi3', 'none'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "platform tag" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:144 +msgid "E.g. 'linux_x86_64', 'any'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:146 +msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:151 +msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:156 +msgid "Escaping and Unicode" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:158 +msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:161 +msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:164 +msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:166 +msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:169 +msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:172 +msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:176 +msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:182 +msgid "File contents" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:184 +msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:188 +msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:191 +msgid "``{distribution}-{version}.dist-info/`` contains metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:192 +msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:196 +msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:200 +msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:202 +msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:212 +msgid "``Wheel-Version`` is the version number of the Wheel specification." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:213 +msgid "``Generator`` is the name and optionally the version of the software that produced the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:215 +msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:218 +msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:220 +msgid "``Build`` is the build number and is omitted if there is no build number." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:221 +msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:224 +msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:226 +msgid "Wheel does not contain setup.py or setup.cfg." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:228 +msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:235 +#: ../source/specifications/recording-installed-packages.rst:35 +msgid "The .dist-info directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:237 +msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:239 +msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:241 +msgid "WHEEL is the wheel metadata specific to a build of the package." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:242 +msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:248 +msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:249 +msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:251 +msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:254 +msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:261 +msgid "The .data directory" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:263 +msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:271 +msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:277 +msgid "Signed wheel files" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:279 +msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:290 +msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:295 +msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:302 +msgid "(The hash value is the same format used in RECORD.)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:304 +msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:307 +msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:312 +msgid "See" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:314 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:315 +msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:316 +msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:317 +msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:321 +msgid "Comparison to .egg" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:323 +msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:328 +msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:331 +msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:337 +msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:341 +msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:344 +msgid "Wheel is a reference to the other Python." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:348 +msgid "FAQ" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:352 +msgid "Wheel defines a .data directory. Should I put all my data there?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:354 +msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:363 +msgid "Why does wheel include attached signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:365 +msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:373 +msgid "Why does wheel allow JWS signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:375 +msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:381 +msgid "Why does wheel also allow S/MIME signatures?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:383 +msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:386 +msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:391 +msgid "What's the deal with \"purelib\" vs. \"platlib\"?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:393 +msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:398 +msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:403 +msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:409 +msgid "Is it possible to import Python code directly from a wheel file?" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:411 +msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:417 +msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:426 +msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:443 +msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:450 +msgid "Changes" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:452 +msgid "Since :pep:`427`, this specification has changed as follows:" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:454 +msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:461 +msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:466 +msgid "Appendix" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:468 +msgid "Example urlsafe-base64-nopad implementation::" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:482 +msgid "Copyright" +msgstr "" + +#: ../source/specifications/binary-distribution-format.rst:484 +msgid "This document has been placed into the public domain." +msgstr "" + +#: ../source/specifications/core-metadata.rst:5 +msgid "Core metadata specifications" +msgstr "" + +#: ../source/specifications/core-metadata.rst:7 +msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:10 +msgid "``Metadata-Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:11 +msgid "``Name``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:12 +msgid "``Version``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:14 +msgid "All the other fields are optional." +msgstr "" + +#: ../source/specifications/core-metadata.rst:16 +msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." +msgstr "" + +#: ../source/specifications/core-metadata.rst:25 +msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:30 +msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." +msgstr "" + +#: ../source/specifications/core-metadata.rst:41 +msgid "Metadata-Version" +msgstr "" + +#: ../source/specifications/core-metadata.rst:45 +msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." +msgstr "" + +#: ../source/specifications/core-metadata.rst:48 +msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:54 +msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." +msgstr "" + +#: ../source/specifications/core-metadata.rst:58 +#: ../source/specifications/core-metadata.rst:80 +#: ../source/specifications/core-metadata.rst:95 +#: ../source/specifications/core-metadata.rst:155 +#: ../source/specifications/core-metadata.rst:170 +#: ../source/specifications/core-metadata.rst:208 +#: ../source/specifications/core-metadata.rst:283 +#: ../source/specifications/core-metadata.rst:287 +#: ../source/specifications/core-metadata.rst:291 +#: ../source/specifications/core-metadata.rst:295 +#: ../source/specifications/core-metadata.rst:327 +#: ../source/specifications/core-metadata.rst:347 +#: ../source/specifications/core-metadata.rst:373 +#: ../source/specifications/core-metadata.rst:391 +#: ../source/specifications/core-metadata.rst:416 +#: ../source/specifications/core-metadata.rst:438 +#: ../source/specifications/core-metadata.rst:600 +#: ../source/specifications/core-metadata.rst:620 +#: ../source/specifications/core-metadata.rst:630 +msgid "Example::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:66 +msgid "Name" +msgstr "" + +#: ../source/specifications/core-metadata.rst:69 +msgid "Added additional restrictions on format from :pep:`508`" +msgstr "" + +#: ../source/specifications/core-metadata.rst:72 +msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:88 +msgid "Version" +msgstr "" + +#: ../source/specifications/core-metadata.rst:92 +msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:101 +msgid "Dynamic (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:105 +msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." +msgstr "" + +#: ../source/specifications/core-metadata.rst:108 +msgid "When found in the metadata of a source distribution, the following rules apply:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:111 +msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." +msgstr "" + +#: ../source/specifications/core-metadata.rst:115 +msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:118 +msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:122 +msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." +msgstr "" + +#: ../source/specifications/core-metadata.rst:127 +msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:131 +msgid "Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:135 +msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." +msgstr "" + +#: ../source/specifications/core-metadata.rst:146 +msgid "Supported-Platform (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:150 +msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." +msgstr "" + +#: ../source/specifications/core-metadata.rst:164 +msgid "Summary" +msgstr "" + +#: ../source/specifications/core-metadata.rst:168 +msgid "A one-line summary of what the distribution does." +msgstr "" + +#: ../source/specifications/core-metadata.rst:188 +msgid "This field may be specified in the message body instead." +msgstr "" + +#: ../source/specifications/core-metadata.rst:191 +msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:196 +msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." +msgstr "" + +#: ../source/specifications/core-metadata.rst:202 +msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:219 +msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." +msgstr "" + +#: ../source/specifications/core-metadata.rst:223 +msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:232 +msgid "Description-Content-Type" +msgstr "" + +#: ../source/specifications/core-metadata.rst:236 +msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." +msgstr "" + +#: ../source/specifications/core-metadata.rst:239 +msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." +msgstr "" + +#: ../source/specifications/core-metadata.rst:253 +msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:259 +msgid "Format::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:263 +msgid "The ``type/subtype`` part has only a few legal values:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:265 +msgid "``text/plain``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:266 +msgid "``text/x-rst``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:267 +msgid "``text/markdown``" +msgstr "" + +#: ../source/specifications/core-metadata.rst:269 +msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:273 +msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:278 +msgid "``GFM`` for `Github-flavored Markdown `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:280 +msgid "``CommonMark`` for `CommonMark `_" +msgstr "" + +#: ../source/specifications/core-metadata.rst:299 +msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." +msgstr "" + +#: ../source/specifications/core-metadata.rst:303 +msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:307 +msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:311 +msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." +msgstr "" + +#: ../source/specifications/core-metadata.rst:320 +msgid "Keywords" +msgstr "" + +#: ../source/specifications/core-metadata.rst:324 +msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." +msgstr "" + +#: ../source/specifications/core-metadata.rst:333 +msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." +msgstr "" + +#: ../source/specifications/core-metadata.rst:341 +msgid "Home-page" +msgstr "" + +#: ../source/specifications/core-metadata.rst:345 +msgid "A string containing the URL for the distribution's home page." +msgstr "" + +#: ../source/specifications/core-metadata.rst:353 +msgid "Download-URL" +msgstr "" + +#: ../source/specifications/core-metadata.rst:357 +msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:366 +msgid "Author" +msgstr "" + +#: ../source/specifications/core-metadata.rst:370 +msgid "A string containing the author's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:383 +msgid "Author-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:387 +msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:395 +#: ../source/specifications/core-metadata.rst:442 +msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" +msgstr "" + +#: ../source/specifications/core-metadata.rst:405 +msgid "Maintainer" +msgstr "" + +#: ../source/specifications/core-metadata.rst:409 +msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." +msgstr "" + +#: ../source/specifications/core-metadata.rst:412 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:426 +msgid "Maintainer-email" +msgstr "" + +#: ../source/specifications/core-metadata.rst:430 +msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." +msgstr "" + +#: ../source/specifications/core-metadata.rst:434 +msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:452 +msgid "License" +msgstr "" + +#: ../source/specifications/core-metadata.rst:456 +msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." +msgstr "" + +#: ../source/specifications/core-metadata.rst:476 +msgid "Classifier (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:480 +msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:485 +#: ../source/specifications/core-metadata.rst:574 +#: ../source/specifications/core-metadata.rst:691 +#: ../source/specifications/core-metadata.rst:715 +msgid "This field may be followed by an environment marker after a semicolon." +msgstr "" + +#: ../source/specifications/core-metadata.rst:496 +msgid "Requires-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:499 +#: ../source/specifications/core-metadata.rst:561 +#: ../source/specifications/core-metadata.rst:663 +#: ../source/specifications/core-metadata.rst:704 +msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." +msgstr "" + +#: ../source/specifications/core-metadata.rst:503 +msgid "Each entry contains a string naming some other distutils project required by this distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:506 +msgid "The format of a requirement string contains from one to four parts:" +msgstr "" + +#: ../source/specifications/core-metadata.rst:508 +msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." +msgstr "" + +#: ../source/specifications/core-metadata.rst:510 +msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." +msgstr "" + +#: ../source/specifications/core-metadata.rst:513 +msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:516 +msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." +msgstr "" + +#: ../source/specifications/core-metadata.rst:519 +msgid "See :pep:`508` for full details of the allowed format." +msgstr "" + +#: ../source/specifications/core-metadata.rst:521 +msgid "The project names should correspond to names as found on the `Python Package Index`_." +msgstr "" + +#: ../source/specifications/core-metadata.rst:524 +msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:538 +msgid "Requires-Python" +msgstr "" + +#: ../source/specifications/core-metadata.rst:542 +msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." +msgstr "" + +#: ../source/specifications/core-metadata.rst:546 +msgid "The value must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:548 +msgid "This field cannot be followed by an environment marker." +msgstr "" + +#: ../source/specifications/core-metadata.rst:558 +msgid "Requires-External (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:565 +msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:570 +msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." +msgstr "" + +#: ../source/specifications/core-metadata.rst:576 +msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." +msgstr "" + +#: ../source/specifications/core-metadata.rst:581 +msgid "Notice that there is no particular rule on the strings to be used." +msgstr "" + +#: ../source/specifications/core-metadata.rst:593 +msgid "Project-URL (multiple-use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:597 +msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." +msgstr "" + +#: ../source/specifications/core-metadata.rst:604 +msgid "The label is free text limited to 32 characters." +msgstr "" + +#: ../source/specifications/core-metadata.rst:612 +msgid "Provides-Extra (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:616 +msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." +msgstr "" + +#: ../source/specifications/core-metadata.rst:625 +msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." +msgstr "" + +#: ../source/specifications/core-metadata.rst:635 +msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." +msgstr "" + +#: ../source/specifications/core-metadata.rst:639 +msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:644 +msgid "Rarely Used Fields" +msgstr "" + +#: ../source/specifications/core-metadata.rst:646 +msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." +msgstr "" + +#: ../source/specifications/core-metadata.rst:651 +msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." +msgstr "" + +#: ../source/specifications/core-metadata.rst:660 +msgid "Provides-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:667 +msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." +msgstr "" + +#: ../source/specifications/core-metadata.rst:672 +msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." +msgstr "" + +#: ../source/specifications/core-metadata.rst:679 +msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:687 +msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." +msgstr "" + +#: ../source/specifications/core-metadata.rst:701 +msgid "Obsoletes-Dist (multiple use)" +msgstr "" + +#: ../source/specifications/core-metadata.rst:708 +msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." +msgstr "" + +#: ../source/specifications/core-metadata.rst:712 +msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." +msgstr "" + +#: ../source/specifications/core-metadata.rst:717 +msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." +msgstr "" + +#: ../source/specifications/core-metadata.rst:730 +msgid "reStructuredText markup: http://docutils.sourceforge.net/" +msgstr "" + +#: ../source/specifications/core-metadata.rst:735 +msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:6 +msgid "Declaring build system dependencies" +msgstr "" + +#: ../source/specifications/declaring-build-dependencies.rst:8 +msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:5 +msgid "Declaring project metadata" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:7 +msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:12 +msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:18 +msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:27 +msgid "The only fields required to be statically defined are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:29 +#: ../source/specifications/declaring-project-metadata.rst:41 +msgid "``name``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:31 +msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:34 +#: ../source/specifications/declaring-project-metadata.rst:54 +msgid "``version``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:36 +msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:43 +#: ../source/specifications/declaring-project-metadata.rst:56 +#: ../source/specifications/declaring-project-metadata.rst:68 +#: ../source/specifications/declaring-project-metadata.rst:117 +msgid "TOML_ type: string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:44 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:47 +msgid "The name of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:49 +msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:57 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:60 +msgid "The version of the project as supported by :pep:`440`." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:62 +msgid "Users SHOULD prefer to specify already-normalized versions." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:66 +msgid "``description``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:69 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:72 +msgid "The summary description of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:76 +msgid "``readme``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:78 +msgid "TOML_ type: string or table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:79 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:83 +msgid "The full description of the project (i.e. the README)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:85 +msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:96 +msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:103 +msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:115 +msgid "``requires-python``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:118 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:121 +msgid "The Python version requirements of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:125 +msgid "``license``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:127 +msgid "TOML_ type: table" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:128 +msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:131 +msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:140 +msgid "``authors``/``maintainers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:142 +msgid "TOML_ type: Array of inline tables with string keys and values" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:143 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:149 +msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:154 +msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:157 +msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:163 +msgid "Using the data to fill in :ref:`core metadata ` is as follows:" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:166 +msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:169 +msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:173 +msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:177 +msgid "Multiple values should be separated by commas." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:181 +msgid "``keywords``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:183 +#: ../source/specifications/declaring-project-metadata.rst:193 +msgid "TOML_ type: array of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:184 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:187 +msgid "The keywords for the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:191 +msgid "``classifiers``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:194 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:197 +msgid "Trove classifiers which apply to the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:201 +msgid "``urls``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:203 +msgid "TOML_ type: table with keys and values of strings" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:204 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:207 +msgid "A table of URLs where the key is the URL label and the value is the URL itself." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:212 +msgid "Entry points" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:214 +msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:216 +msgid ":ref:`Entry points specification `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:218 +msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:224 +msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:228 +msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:234 +msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:242 +msgid "``dependencies``/``optional-dependencies``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:244 +msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:247 +msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:251 +msgid "The (optional) dependencies of the project." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:253 +msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:258 +msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:269 +msgid "``dynamic``" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:271 +msgid "TOML_ type: array of string" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:272 +msgid "A corresponding :ref:`core metadata ` field does not exist" +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:275 +msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:281 +msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:283 +msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:285 +msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:290 +msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:294 +msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:296 +msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." +msgstr "" + +#: ../source/specifications/declaring-project-metadata.rst:300 +msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:6 +msgid "Dependency specifiers" +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:8 +msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." +msgstr "" + +#: ../source/specifications/dependency-specifiers.rst:11 +msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." +msgstr "" + +#: ../source/specifications/direct-url.rst:6 +msgid "Recording the Direct URL Origin of installed distributions" +msgstr "" + +#: ../source/specifications/direct-url.rst:8 +msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." +msgstr "" + +#: ../source/specifications/direct-url.rst:17 +msgid "Specification" +msgstr "" + +#: ../source/specifications/direct-url.rst:19 +msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/direct-url.rst:23 +#: ../source/specifications/recording-installed-packages.rst:206 +msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." +msgstr "" + +#: ../source/specifications/direct-url.rst:26 +msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." +msgstr "" + +#: ../source/specifications/direct-url.rst:29 +msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." +msgstr "" + +#: ../source/specifications/direct-url.rst:36 +msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." +msgstr "" + +#: ../source/specifications/direct-url.rst:39 +msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" +msgstr "" + +#: ../source/specifications/direct-url.rst:45 +msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." +msgstr "" + +#: ../source/specifications/direct-url.rst:49 +msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" +msgstr "" + +#: ../source/specifications/direct-url.rst:52 +msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." +msgstr "" + +#: ../source/specifications/direct-url.rst:58 +msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." +msgstr "" + +#: ../source/specifications/direct-url.rst:61 +msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." +msgstr "" + +#: ../source/specifications/direct-url.rst:68 +msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:71 +msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." +msgstr "" + +#: ../source/specifications/direct-url.rst:78 +msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" +msgstr "" + +#: ../source/specifications/direct-url.rst:81 +msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." +msgstr "" + +#: ../source/specifications/direct-url.rst:84 +msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." +msgstr "" + +#: ../source/specifications/direct-url.rst:91 +msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." +msgstr "" + +#: ../source/specifications/direct-url.rst:96 +msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." +msgstr "" + +#: ../source/specifications/direct-url.rst:102 +msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." +msgstr "" + +#: ../source/specifications/direct-url.rst:110 +msgid "Registered VCS" +msgstr "" + +#: ../source/specifications/direct-url.rst:112 +msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." +msgstr "" + +#: ../source/specifications/direct-url.rst:122 +msgid "Git" +msgstr "" + +#: ../source/specifications/direct-url.rst:124 +#: ../source/specifications/direct-url.rst:156 +#: ../source/specifications/direct-url.rst:179 +#: ../source/specifications/direct-url.rst:202 +msgid "Home page" +msgstr "" + +#: ../source/specifications/direct-url.rst:126 +msgid "https://git-scm.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:128 +#: ../source/specifications/direct-url.rst:160 +#: ../source/specifications/direct-url.rst:183 +#: ../source/specifications/direct-url.rst:206 +msgid "vcs command" +msgstr "" + +#: ../source/specifications/direct-url.rst:130 +#: ../source/specifications/direct-url.rst:134 +msgid "git" +msgstr "" + +#: ../source/specifications/direct-url.rst:132 +#: ../source/specifications/direct-url.rst:164 +#: ../source/specifications/direct-url.rst:187 +#: ../source/specifications/direct-url.rst:210 +msgid "``vcs`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:136 +#: ../source/specifications/direct-url.rst:168 +#: ../source/specifications/direct-url.rst:191 +#: ../source/specifications/direct-url.rst:214 +msgid "``requested_revision`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:138 +msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." +msgstr "" + +#: ../source/specifications/direct-url.rst:141 +#: ../source/specifications/direct-url.rst:172 +#: ../source/specifications/direct-url.rst:195 +#: ../source/specifications/direct-url.rst:219 +msgid "``commit_id`` field" +msgstr "" + +#: ../source/specifications/direct-url.rst:143 +msgid "A commit hash (40 hexadecimal characters sha1)." +msgstr "" + +#: ../source/specifications/direct-url.rst:147 +msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." +msgstr "" + +#: ../source/specifications/direct-url.rst:154 +msgid "Mercurial" +msgstr "" + +#: ../source/specifications/direct-url.rst:158 +msgid "https://www.mercurial-scm.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:162 +#: ../source/specifications/direct-url.rst:166 +msgid "hg" +msgstr "" + +#: ../source/specifications/direct-url.rst:170 +msgid "A tag name, branch name, changeset ID, shortened changeset ID." +msgstr "" + +#: ../source/specifications/direct-url.rst:174 +msgid "A changeset ID (40 hexadecimal characters)." +msgstr "" + +#: ../source/specifications/direct-url.rst:177 +msgid "Bazaar" +msgstr "" + +#: ../source/specifications/direct-url.rst:181 +msgid "https://bazaar.canonical.com/" +msgstr "" + +#: ../source/specifications/direct-url.rst:185 +#: ../source/specifications/direct-url.rst:189 +msgid "bzr" +msgstr "" + +#: ../source/specifications/direct-url.rst:193 +msgid "A tag name, branch name, revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:197 +msgid "A revision id." +msgstr "" + +#: ../source/specifications/direct-url.rst:200 +msgid "Subversion" +msgstr "" + +#: ../source/specifications/direct-url.rst:204 +msgid "https://subversion.apache.org/" +msgstr "" + +#: ../source/specifications/direct-url.rst:208 +#: ../source/specifications/direct-url.rst:212 +msgid "svn" +msgstr "" + +#: ../source/specifications/direct-url.rst:216 +msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." +msgstr "" + +#: ../source/specifications/direct-url.rst:221 +msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." +msgstr "" + +#: ../source/specifications/direct-url.rst:229 +msgid "Example direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:231 +msgid "Source archive:" +msgstr "" + +#: ../source/specifications/direct-url.rst:242 +msgid "Git URL with tag and commit-hash:" +msgstr "" + +#: ../source/specifications/direct-url.rst:255 +msgid "Local directory:" +msgstr "" + +#: ../source/specifications/direct-url.rst:264 +msgid "Local directory installed in editable mode:" +msgstr "" + +#: ../source/specifications/direct-url.rst:277 +msgid "Example pip commands and their effect on direct_url.json" +msgstr "" + +#: ../source/specifications/direct-url.rst:279 +msgid "Commands that generate a ``direct_url.json``:" +msgstr "" + +#: ../source/specifications/direct-url.rst:281 +msgid "pip install https://example.com/app-1.0.tgz" +msgstr "" + +#: ../source/specifications/direct-url.rst:282 +msgid "pip install https://example.com/app-1.0.whl" +msgstr "" + +#: ../source/specifications/direct-url.rst:283 +msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" +msgstr "" + +#: ../source/specifications/direct-url.rst:284 +msgid "pip install ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:285 +msgid "pip install file:///home/user/app" +msgstr "" + +#: ../source/specifications/direct-url.rst:286 +msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" +msgstr "" + +#: ../source/specifications/direct-url.rst:290 +msgid "pip install -e ./app" +msgstr "" + +#: ../source/specifications/direct-url.rst:292 +msgid "Commands that *do not* generate a ``direct_url.json``" +msgstr "" + +#: ../source/specifications/direct-url.rst:294 +msgid "pip install app" +msgstr "" + +#: ../source/specifications/direct-url.rst:295 +msgid "pip install app --no-index --find-links https://example.com/" +msgstr "" + +#: ../source/specifications/entry-points.rst:5 +msgid "Entry points specification" +msgstr "" + +#: ../source/specifications/entry-points.rst:7 +msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" +msgstr "" + +#: ../source/specifications/entry-points.rst:11 +msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." +msgstr "" + +#: ../source/specifications/entry-points.rst:14 +msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." +msgstr "" + +#: ../source/specifications/entry-points.rst:19 +msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." +msgstr "" + +#: ../source/specifications/entry-points.rst:28 +msgid "Data model" +msgstr "" + +#: ../source/specifications/entry-points.rst:30 +msgid "Conceptually, an entry point is defined by three required properties:" +msgstr "" + +#: ../source/specifications/entry-points.rst:32 +msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:42 +msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:51 +msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:64 +msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." +msgstr "" + +#: ../source/specifications/entry-points.rst:68 +msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." +msgstr "" + +#: ../source/specifications/entry-points.rst:73 +msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." +msgstr "" + +#: ../source/specifications/entry-points.rst:80 +msgid "File format" +msgstr "" + +#: ../source/specifications/entry-points.rst:82 +msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." +msgstr "" + +#: ../source/specifications/entry-points.rst:87 +msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:97 +msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." +msgstr "" + +#: ../source/specifications/entry-points.rst:100 +msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." +msgstr "" + +#: ../source/specifications/entry-points.rst:104 +msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." +msgstr "" + +#: ../source/specifications/entry-points.rst:112 +msgid "For example::" +msgstr "" + +#: ../source/specifications/entry-points.rst:124 +msgid "Use for scripts" +msgstr "" + +#: ../source/specifications/entry-points.rst:126 +msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." +msgstr "" + +#: ../source/specifications/entry-points.rst:134 +msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" +msgstr "" + +#: ../source/specifications/entry-points.rst:141 +msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." +msgstr "" + +#: ../source/specifications/entry-points.rst:149 +msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." +msgstr "" + +#: ../source/specifications/entry-points.rst:154 +msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." +msgstr "" + +#: ../source/specifications/index.rst:4 +msgid "PyPA specifications" +msgstr "" + +#: ../source/specifications/index.rst:6 +msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." +msgstr "" + +#: ../source/specifications/index.rst:13 +msgid "Package Distribution Metadata" +msgstr "" + +#: ../source/specifications/index.rst:30 +msgid "Package Distribution File Formats" +msgstr "" + +#: ../source/specifications/index.rst:40 +msgid "Package Index Interfaces" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:6 +msgid "Platform compatibility tags" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:8 +msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:12 +msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:16 +msgid "Platform tags for Windows" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:18 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:22 +msgid "Platform tags for macOS (Mac OS X)" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:24 +msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:28 +msgid "Platform tags for common Linux distributions" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:32 +msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:36 +msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:41 +msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:44 +msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:46 +msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:49 +msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:54 +msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:59 +msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:65 +msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:71 +msgid "Manylinux compatibility support" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:74 +msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:76 +msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:79 +msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "Tool" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux1``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2010``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux2014``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:83 +msgid "``manylinux_x_y``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=8.1.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=19.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:85 +msgid "``>=20.3``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "auditwheel" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=1.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=2.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.0.0``" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:86 +msgid "``>=3.3.0`` [#]_" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:90 +msgid "Platform tags for other \\*nix platforms" +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:92 +msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." +msgstr "" + +#: ../source/specifications/platform-compatibility-tags.rst:98 +msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" +msgstr "" + +#: ../source/specifications/pypirc.rst:6 +msgid "The :file:`.pypirc` file" +msgstr "" + +#: ../source/specifications/pypirc.rst:8 +msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." +msgstr "" + +#: ../source/specifications/pypirc.rst:13 +msgid "The format (originally defined by the :ref:`distutils` package) is:" +msgstr "" + +#: ../source/specifications/pypirc.rst:32 +msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:35 +msgid "Each section describing a repository defines three fields:" +msgstr "" + +#: ../source/specifications/pypirc.rst:37 +msgid "``repository``: The URL of the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:38 +msgid "``username``: The registered username on the repository." +msgstr "" + +#: ../source/specifications/pypirc.rst:39 +msgid "``password``: The password that will used to authenticate the username." +msgstr "" + +#: ../source/specifications/pypirc.rst:43 +msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." +msgstr "" + +#: ../source/specifications/pypirc.rst:47 +msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" +msgstr "" + +#: ../source/specifications/pypirc.rst:57 +msgid "Common configurations" +msgstr "" + +#: ../source/specifications/pypirc.rst:61 +msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." +msgstr "" + +#: ../source/specifications/pypirc.rst:66 +msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" +msgstr "" + +#: ../source/specifications/pypirc.rst:82 +msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." +msgstr "" + +#: ../source/specifications/pypirc.rst:86 +msgid "Using a PyPI token" +msgstr "" + +#: ../source/specifications/pypirc.rst:88 +msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" +msgstr "" + +#: ../source/specifications/pypirc.rst:97 +msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." +msgstr "" + +#: ../source/specifications/pypirc.rst:103 +msgid "Using another package index" +msgstr "" + +#: ../source/specifications/pypirc.rst:105 +msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" +msgstr "" + +#: ../source/specifications/pypirc.rst:132 +msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:5 +msgid "Recording installed projects" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:7 +msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:12 +msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:21 +msgid "History and change workflow" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:23 +msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:29 +msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:37 +msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:41 +msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:50 +msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:60 +msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:69 +msgid "This ``.dist-info`` directory can contain these files, described in detail below:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:72 +msgid "``METADATA``: contains project metadata" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:73 +msgid "``RECORD``: records the list of installed files." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:74 +msgid "``INSTALLER``: records the name of the tool used to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:76 +msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:82 +msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:87 +msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:94 +msgid "The METADATA file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:96 +msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:99 +msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:105 +msgid "The RECORD file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:107 +msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:110 +msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:113 +msgid "field delimiter: ``,`` (comma)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:114 +msgid "quoting char: ``\"`` (straight double quote)," +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:115 +msgid "line terminator: either ``\\r\\n`` or ``\\n``." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:117 +msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:120 +msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:125 +msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:130 +msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:133 +msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:139 +msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:146 +msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:151 +msgid "Here is an example snippet of a possible ``RECORD`` file::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:170 +msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:177 +msgid "The INSTALLER file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:179 +msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:185 +msgid "The file can be terminated by zero or more ASCII whitespace characters." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:187 +msgid "Here are examples of two possible ``INSTALLER`` files::" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:195 +msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:201 +msgid "The direct_url.json file" +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:203 +msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." +msgstr "" + +#: ../source/specifications/recording-installed-packages.rst:209 +msgid "Its detailed specification is at :ref:`direct-url`." +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:6 +msgid "Simple repository API" +msgstr "" + +#: ../source/specifications/simple-repository-api.rst:8 +msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:6 +msgid "Source distribution format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:8 +msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:13 +msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:21 +msgid "Source distributions are also known as *sdists* for short." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:24 +msgid "Source distribution file name" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:26 +msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:31 +msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:35 +msgid "Source distribution file format" +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:37 +msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:45 +msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." +msgstr "" + +#: ../source/specifications/source-distribution-format.rst:48 +msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:6 +msgid "Version specifiers" +msgstr "" + +#: ../source/specifications/version-specifiers.rst:8 +msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." +msgstr "" + +#: ../source/specifications/version-specifiers.rst:11 +msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." +msgstr "" + +#: ../source/support.rst:3 +msgid "How to Get Support" +msgstr "" + +#: ../source/support.rst:5 +msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." +msgstr "" + +#: ../source/support.rst:8 +msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:5 +msgid "Creating Documentation" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:7 +msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:13 +msgid "Installing Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:14 +msgid "Use ``pip`` to install Sphinx:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:28 +msgid "For other installation methods, see this `installation guide`_ by Sphinx." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:33 +msgid "Getting Started With Sphinx" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:35 +msgid "Create a ``docs`` directory inside your project to hold your documentation:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:42 +msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:49 +msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:51 +msgid "You can add some information about your project in ``index.rst``, then build them:" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:57 +msgid "For more details on the build process, see this `guide`_ by Read The Docs." +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:62 +msgid "Other Sources" +msgstr "" + +#: ../source/tutorials/creating-documentation.rst:64 +msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/index.rst:4 +msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:5 +msgid "Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:7 +msgid "This section covers the basics of how to install Python :term:`packages `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:10 +msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:28 +msgid "Requirements for Installing Packages" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:30 +msgid "This section describes the steps to follow before installing other Python packages." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:35 +msgid "Ensure you can run Python from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:37 +msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:53 +msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:57 +msgid "If you're a newcomer and you get an error like this:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:66 +msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:72 +msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:82 +msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:87 +msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:99 +msgid "Ensure you can run pip from the command line" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:101 +msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:116 +msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:124 +msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:139 +msgid "If that still doesn't allow you to run ``python -m pip``:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:141 +msgid "Securely Download `get-pip.py `_ [1]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:144 +msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:150 +msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:159 +msgid "Ensure pip, setuptools, and wheel are up to date" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:161 +msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:169 +msgid "Optionally, create a virtual environment" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:171 +msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:188 +msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:195 +msgid "Creating Virtual Environments" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:197 +msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:203 +msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:209 +msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:213 +msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:216 +msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:220 +msgid "Currently, there are two common tools for creating Python virtual environments:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:222 +msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:225 +msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:230 +msgid "The basic usage is like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:232 +msgid "Using `venv`_:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:248 +msgid "Using :ref:`virtualenv`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:264 +msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:266 +msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:271 +msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:281 +msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:288 +msgid "Use pip for Installing" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:290 +msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:297 +msgid "Installing from PyPI" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:299 +msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:307 +msgid "To install the latest version of \"SomeProject\":" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:321 +msgid "To install a specific version:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:335 +msgid "To install greater than or equal to one version and less than another:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:350 +msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:365 +msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:370 +msgid "Source Distributions vs Wheels" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:372 +msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:378 +msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:383 +msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:391 +msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:408 +msgid "Installing to the User Site" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:410 +msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:425 +msgid "For more information see the `User Installs `_ section from the pip docs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:429 +msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:432 +msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:440 +msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:446 +msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:462 +msgid "Install a list of requirements specified in a :ref:`Requirements File `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:478 +msgid "Installing from VCS" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:480 +msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:502 +msgid "Installing from other Indexes" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:504 +msgid "Install from an alternate index" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:518 +msgid "Search an additional index during install, in addition to :term:`PyPI `" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:534 +msgid "Installing from a local src tree" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:537 +msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:554 +msgid "You can also install normally from src" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:571 +msgid "Install a particular source archive file." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:585 +msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:605 +msgid "Installing from other sources" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:607 +msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:619 +msgid "Installing Prereleases" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:621 +msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:637 +msgid "Installing Setuptools \"Extras\"" +msgstr "" + +#: ../source/tutorials/installing-packages.rst:639 +msgid "Install `setuptools extras`_." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:659 +msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:668 +msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." +msgstr "" + +#: ../source/tutorials/installing-packages.rst:673 +msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:4 +msgid "Managing Application Dependencies" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:6 +msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:9 +msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:13 +msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:17 +msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:24 +msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:30 +msgid "Installing Pipenv" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:32 +msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:38 +msgid "Use ``pip`` to install Pipenv:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:54 +msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:65 +msgid "Installing packages for your project" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:67 +msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:76 +msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:112 +msgid "Using installed packages" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:114 +msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:125 +msgid "Then you can run this script using ``pipenv run``:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:131 +msgid "You should get output similar to this:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:137 +msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:143 +#: ../source/tutorials/packaging-projects.rst:594 +msgid "Next steps" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:145 +msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:148 +msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:151 +msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:160 +msgid "Other Tools for Application Dependency Management" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:162 +msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:166 +msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:172 +msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:175 +msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" +msgstr "" + +#: ../source/tutorials/managing-dependencies.rst:177 +msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:2 +msgid "Packaging Python Projects" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:4 +msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:10 +msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:18 +msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:35 +msgid "A simple project" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:37 +msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:41 +msgid "Create the following file structure locally:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:51 +msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:54 +msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:63 +msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:67 +msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:75 +msgid "Creating the package files" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:77 +msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:95 +msgid "Creating a test directory" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:97 +msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:101 +msgid "Creating pyproject.toml" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:103 +msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:117 +msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:121 +msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:127 +msgid "See :pep:`517` and :pep:`518` for background and details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:131 +msgid "Configuring metadata" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:133 +msgid "There are two types of metadata: static and dynamic." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:135 +msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:137 +msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:141 +msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:148 +msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:153 +msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:185 +msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:191 +#: ../source/tutorials/packaging-projects.rst:286 +msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:196 +msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:199 +#: ../source/tutorials/packaging-projects.rst:293 +msgid "``author`` and ``author_email`` are used to identify the author of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:201 +#: ../source/tutorials/packaging-projects.rst:295 +msgid "``description`` is a short, one-sentence summary of the package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:202 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:206 +#: ../source/tutorials/packaging-projects.rst:300 +msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:208 +#: ../source/tutorials/packaging-projects.rst:302 +msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:211 +#: ../source/tutorials/packaging-projects.rst:305 +msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:213 +#: ../source/tutorials/packaging-projects.rst:307 +msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:221 +msgid "In the ``options`` category, we have controls for setuptools itself:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:223 +msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:227 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:234 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:238 +#: ../source/tutorials/packaging-projects.rst:329 +msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:244 +msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:248 +msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:283 +msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:291 +msgid "``version`` is the package version. See :pep:`440` for more details on versions." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:296 +msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:314 +msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:319 +msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:325 +msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:333 +msgid "Creating README.md" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:335 +msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:347 +msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:354 +msgid "Creating a LICENSE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:356 +msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:387 +msgid "Including other files" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:389 +msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:393 +msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:402 +msgid "Generating distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:404 +msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:408 +msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:422 +msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:425 +msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:439 +msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:449 +msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:458 +msgid "Uploading the distribution archives" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:460 +msgid "Finally, it's time to upload your package to the Python Package Index!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:462 +msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:470 +msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:477 +msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:492 +msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:506 +msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:510 +msgid "After the command completes, you should see output similar to this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:523 +msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:528 +msgid "Installing your newly uploaded package" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:530 +msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:546 +msgid "Make sure to specify your username in the package name!" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:548 +msgid "pip should install the package from TestPyPI and the output should look something like this:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:558 +msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:565 +msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:580 +msgid "and import the package:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:588 +msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:596 +msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:599 +msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:604 +msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:608 +msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:610 +msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:613 +msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:617 +msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:619 +msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:622 +msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:624 +msgid "Read about :doc:`/guides/packaging-binary-extensions`." +msgstr "" + +#: ../source/tutorials/packaging-projects.rst:625 +msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." +msgstr "" From 3fab5ca709ad151951c87efdd7110dfad696eb72 Mon Sep 17 00:00:00 2001 From: Rafael Fontenelle Date: Tue, 23 Nov 2021 15:41:12 +0100 Subject: [PATCH 0192/1072] Translated using Weblate (Portuguese (Brazil)) Currently translated at 80.3% (1825 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 77.0% (1750 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 77.0% (1750 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 77.0% (1750 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 77.0% (1750 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 77.0% (1750 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 77.0% (1750 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 77.0% (1750 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 75.8% (1723 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 73.8% (1678 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 60.5% (1376 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 54.5% (1239 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 49.0% (1115 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 49.0% (1115 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 49.0% (1115 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 49.0% (1115 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 49.0% (1114 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 23.1% (525 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 23.1% (525 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 23.0% (524 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 21.2% (483 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 19.4% (441 of 2271 strings) Co-authored-by: Rafael Fontenelle Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/pt_BR/ Translation: pypa/packaging.python.org --- locales/pt_BR/LC_MESSAGES/messages.po | 4347 +++++++++++++++++++++---- 1 file changed, 3671 insertions(+), 676 deletions(-) diff --git a/locales/pt_BR/LC_MESSAGES/messages.po b/locales/pt_BR/LC_MESSAGES/messages.po index 8f2c2dc1e..e4e6fe91c 100644 --- a/locales/pt_BR/LC_MESSAGES/messages.po +++ b/locales/pt_BR/LC_MESSAGES/messages.po @@ -8,7 +8,7 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-09-05 14:34+0000\n" +"PO-Revision-Date: 2021-11-14 08:57+0000\n" "Last-Translator: Rafael Fontenelle \n" "Language-Team: Portuguese (Brazil) \n" @@ -17,7 +17,7 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=n > 1;\n" -"X-Generator: Weblate 4.8.1-dev\n" +"X-Generator: Weblate 4.9.1-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -641,13 +641,13 @@ msgid "" "specific topic. If you're just trying to get stuff done, see :doc:`/guides/" "index`." msgstr "" -"**Discussões ** têm como objetivo fornecer informações abrangentes sobre um " +"**Discussões** têm como objetivo fornecer informações abrangentes sobre um " "tópico específico. Se você está apenas tentando fazer as coisas, veja :doc:`/" "guides/index`." #: ../source/discussions/install-requires-vs-requirements.rst:5 msgid "install_requires vs requirements files" -msgstr "install_requires vs arquivos de requisitos" +msgstr "install_requires vs arquivos requirements" #: ../source/discussions/install-requires-vs-requirements.rst:12 #: ../source/guides/distributing-packages-using-setuptools.rst:382 @@ -661,9 +661,9 @@ msgid "" "correctly. When the project is installed by :ref:`pip`, this is the " "specification that is used to install its dependencies." msgstr "" -"``install_requires`` é uma palavra-chave de :file:`setup.py` do " -":ref:`setuptools` que deve ser usada para especificar o que um projeto " -"**minimamente** precisa para rodar corretamente. Quando o projeto é " +"``install_requires`` é uma palavra-chave de :file:`setup.py` do :ref:" +"`setuptools` que deve ser usada para especificar o que um projeto " +"**minimamente** precisa para executar corretamente. Quando o projeto é " "instalado por :ref:`pip`, esta é a especificação que é usada para instalar " "suas dependências." @@ -760,8 +760,8 @@ msgid "" msgstr "" "Considerando que os requisitos de ``install_requires`` são mínimos, os " "arquivos de requisitos frequentemente contêm uma lista exaustiva de versões " -"fixadas com o propósito de alcançar :ref:`instalações repetíveis " -"` de um ambiente completo." +"fixadas com o propósito de alcançar :ref:`instalações repetíveis ` de um ambiente completo." #: ../source/discussions/install-requires-vs-requirements.rst:78 msgid "" @@ -825,12 +825,12 @@ msgid "" "which gave users the power to easily replicate environments." msgstr "" "O :ref:`pip` veio mais tarde em 2008, como alternativa ao :ref:`easy_install " -"`, embora ainda amplamente construído sobre os componentes " -":ref:`setuptools`. Era notável na época por *não* instalar pacotes como " -":term:`Eggs ` ou de :term:`Eggs ` (mas simplesmente como pacotes " -"\"planos\" de :term:`sdists `), e " -"introduzindo a ideia de :ref:`Arquivos de Requisitos `, que deu aos usuários o poder de replicar ambientes facilmente." +"`, embora ainda amplamente construído sobre os componentes :" +"ref:`setuptools`. Era notável na época por *não* instalar pacotes como :term:" +"`Eggs ` ou de :term:`Eggs ` (mas simplesmente como pacotes \"planos" +"\" de :term:`sdists `), e introduzindo a " +"ideia de :ref:`Arquivos de Requisitos `, que deu aos " +"usuários o poder de replicar ambientes facilmente." #: ../source/discussions/pip-vs-easy-install.rst:22 msgid "" @@ -955,8 +955,8 @@ msgid "" "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" "launcher" msgstr "" -"https://setuptools.readthedocs.io/en/latest/deprecated/easy_install.html" -"#natural-script-launcher" +"https://setuptools.readthedocs.io/en/latest/deprecated/easy_install." +"html#natural-script-launcher" #: ../source/discussions/wheel-vs-egg.rst:5 msgid "Wheel vs Egg" @@ -986,17 +986,17 @@ msgid "" ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." msgstr "" -":term:`Wheel` é atualmente considerado o padrão para o empacotamento :term:`" -"contruído ` e :term:`binário ` para " -"Python." +":term:`Wheel` é atualmente considerado o padrão para o empacotamento :term:" +"`contruído ` e :term:`binário ` " +"para Python." #: ../source/discussions/wheel-vs-egg.rst:17 msgid "" "Here's a breakdown of the important differences between :term:`Wheel` and :" "term:`Egg`." msgstr "" -"Aqui está uma análise das diferenças importantes entre :term:`Wheel` e " -":term:`Egg`." +"Aqui está uma análise das diferenças importantes entre :term:`Wheel` e :term:" +"`Egg`." #: ../source/discussions/wheel-vs-egg.rst:20 msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." @@ -1042,7 +1042,7 @@ msgid "" "wheel archive can indicate its compatibility with a number of Python " "language versions and implementations, ABIs, and system architectures." msgstr "" -": term: `Wheel` tem uma :pep:`convenção de nomenclatura de arquivo mais rica " +":term:`Wheel` tem uma :pep:`convenção de nomenclatura de arquivo mais rica " "<425>`. Um único arquivo de wheel pode indicar sua compatibilidade com " "várias versões e implementações da linguagem Python, ABIs e arquiteturas de " "sistema." @@ -1108,8 +1108,8 @@ msgid "" msgstr "" "Um formato de :term:`Distribuição ` contendo arquivos " "e metadados que só precisam ser movidos para o local correto no sistema de " -"destino, para serem instalados. :term:`Wheel` é esse formato, enquanto o " -":term:`Distribuição Fonte ` do distutil " +"destino, para serem instalados. :term:`Wheel` é esse formato, enquanto o :" +"term:`Distribuição Fonte ` do distutil " "não é, pois requer uma etapa de construção antes de poder ser instalado. " "Este formato não implica que os arquivos Python tenham que ser pré-" "compilados (:term:`Wheel` intencionalmente não inclui arquivos Python " @@ -1126,9 +1126,9 @@ msgid "" "to distribute a :term:`Release`. The archive file is what an end-user will " "download from the internet and install." msgstr "" -"Um arquivo com versão que contém :term:`pacotes ` Python, " -":term:`módulos `, e outros arquivos de recursos que são usados para " -"distribuir um :term:`Lançamento `. O arquivo é o que um usuário " +"Um arquivo com versão que contém :term:`pacotes ` Python, :" +"term:`módulos `, e outros arquivos de recursos que são usados para " +"distribuir um :term:`Release` (lançamento). O arquivo é o que um usuário " "final irá baixar da Internet e instalar." #: ../source/glossary.rst:34 @@ -1144,10 +1144,10 @@ msgstr "" "Um pacote de distribuição é mais comumente referido com as palavras \"pacote" "\" ou \"distribuição\", mas este guia pode usar o termo expandido quando " "mais clareza for necessária para evitar confusão com um :term:`Pacote de " -"Importação ` (que também é comumente chamado de \"pacote\") " -"ou outro tipo de distribuição (por exemplo, uma distribuição Linux ou a " -"distribuição da linguagem Python), que são frequentemente referidos com o " -"único termo \"distribuição\"." +"Importação` (que também é comumente chamado de \"pacote\") ou outro tipo de " +"distribuição (por exemplo, uma distribuição Linux ou a distribuição da " +"linguagem Python), que são frequentemente referidos com o único termo " +"\"distribuição\"." #: ../source/glossary.rst:41 msgid "Egg" @@ -1161,11 +1161,11 @@ msgid "" "deprecated/python_eggs.html>`_ and `Python Eggs `_" msgstr "" -"Um formato :term:`Distribuição Construída` introduzido por :ref:`setuptools`" -", que está sendo substituído por :term:`Wheel`. Para obter detalhes, " -"consulte `The Internal Structure of Python Eggs `_ e `Python Eggs " -"`_" +"Um formato :term:`Distribuição Construída` introduzido por :ref:" +"`setuptools`, que está sendo substituído por :term:`Wheel`. Para obter " +"detalhes, consulte `The Internal Structure of Python Eggs `_ e `Python " +"Eggs `_" #: ../source/glossary.rst:49 msgid "Extension Module" @@ -1239,8 +1239,7 @@ msgid "" "term:`Pure Module`, or :term:`Extension Module`." msgstr "" "A unidade básica de reutilização de código em Python, existindo em um dos " -"dois tipos: :term:`Módulo Puro ` ou :term:`Módulo de Extensão " -"`." +"dois tipos: :term:`Módulo Puro` ou :term:`Módulo de Extensão`." #: ../source/glossary.rst:84 msgid "Package Index" @@ -1264,9 +1263,9 @@ msgid "" "specific :term:`Project` as the index preferred or required to resolve " "dependencies of that project." msgstr "" -"Um :term:`Índice de Pacotes ` privado ou outro não canônico " -"indicado por um :term:`Projeto ` específico como o índice preferido " -"ou necessário para resolver dependências desse projeto." +"Um :term:`Índice de Pacotes` privado ou outro não canônico indicado por um :" +"term:`Projeto` específico como o índice preferido ou necessário para " +"resolver dependências desse projeto." #: ../source/glossary.rst:97 msgid "Project" @@ -1290,11 +1289,11 @@ msgid "" "something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:" "`setup.cfg` file at the root of the project source directory." msgstr "" -"Como a maioria dos projetos cria :term:`Distribuições `" -" usando ``build-system`` da :pep:`518`, :ref:`distutils` ou :ref:`setuptools`" -", outra maneira prática de definir projetos atualmente é algo que contém um " -"arquivo :term:`pyproject.toml`, :term:`setup.py` ou :term:`setup.cfg` na " -"raiz do diretório fonte do projeto." +"Como a maioria dos projetos cria :term:`Distribuições ` usando ``build-system`` da :pep:`518`, :ref:`distutils` ou :ref:" +"`setuptools`, outra maneira prática de definir projetos atualmente é algo " +"que contém um arquivo :term:`pyproject.toml`, :term:`setup.py` ou :term:" +"`setup.cfg` na raiz do diretório fonte do projeto." #: ../source/glossary.rst:110 msgid "" @@ -1304,9 +1303,9 @@ msgid "" "`distributions `." msgstr "" "Projetos Python devem ter nomes únicos, que são registrados no :term:`PyPI " -"`. Cada projeto conterá então um ou mais :term:`" -"Lançamentos `, e cada lançamento pode incluir uma ou mais :term:`" -"distribuições `." +"`. Cada projeto conterá então um ou mais :term:" +"`Lançamentos `, e cada lançamento pode incluir uma ou mais :term:" +"`distribuições `." #: ../source/glossary.rst:115 msgid "" @@ -1329,8 +1328,8 @@ msgid "" "A :term:`Module` written in Python and contained in a single ``.py`` file " "(and possibly associated ``.pyc`` and/or ``.pyo`` files)." msgstr "" -"Um :term:`Módulo ` escrito em Python e contido em um único arquivo ``" -".py`` (e possivelmente arquivos ``.pyc`` e/ou ``.pyo`` associados)." +"Um :term:`Módulo` escrito em Python e contido em um único arquivo ``.py`` (e " +"possivelmente arquivos ``.pyc`` e/ou ``.pyo`` associados)." #: ../source/glossary.rst:127 msgid "Python Packaging Authority (PyPA)" @@ -1347,11 +1346,10 @@ msgid "" msgstr "" "PyPA é um grupo de trabalho que mantém muitos dos projetos relevantes em " "pacotes Python. Eles mantêm um site em https://www.pypa.io, hospedam " -"projetos no `GitHub `_ e `Bitbucket " -"`_, e discutem questões na `lista de discussão " -"distutils-sig `_ e `o fórum Discourse do Python `__." +"projetos no `GitHub `_ e `Bitbucket `_, e discutem questões na `lista de discussão distutils-" +"sig `_ e " +"`o fórum Discourse do Python `__." #: ../source/glossary.rst:139 msgid "Python Package Index (PyPI)" @@ -1363,9 +1361,9 @@ msgid "" "Python community. It is open to all Python developers to consume and " "distribute their distributions." msgstr "" -"`PyPI ` _ é o :term:`Índice de Pacotes ` " -"padrão para a comunidade Python. Está aberto a todos os desenvolvedores " -"Python para consumir e distribuir suas distribuições." +"`PyPI `_ é o :term:`Índice de Pacotes` padrão para a " +"comunidade Python. Está aberto a todos os desenvolvedores Python para " +"consumir e distribuir suas distribuições." #: ../source/glossary.rst:145 msgid "pypi.org" @@ -1401,8 +1399,8 @@ msgid "" "A snapshot of a :term:`Project` at a particular point in time, denoted by a " "version identifier." msgstr "" -"Um snapshot de um :term:`Projeto ` em um determinado ponto no " -"tempo, denotado por um identificador de versão." +"Um snapshot de um :term:`Projeto` em um determinado ponto no tempo, denotado " +"por um identificador de versão." #: ../source/glossary.rst:163 msgid "" @@ -1411,8 +1409,8 @@ msgid "" "released, it could be available in both a source distribution format and a " "Windows installer distribution format." msgstr "" -"Fazer um lançamento pode implicar na publicação de várias :term:`" -"Distribuições `. Por exemplo, se a versão 1.0 de um " +"Fazer um lançamento pode implicar na publicação de várias :term:" +"`Distribuições `. Por exemplo, se a versão 1.0 de um " "projeto foi lançada, ele pode estar disponível em um formato de distribuição " "fonte e um formato de distribuição de instalador do Windows." @@ -1428,7 +1426,7 @@ msgid "" "considered a \"requirement\". For more information, see the :ref:`pip:pip " "install` reference." msgstr "" -"Uma especificação para uma :term:`pacote ` a ser " +"Uma especificação para um :term:`pacote ` a ser " "instalado. :ref:`pip`, o instalador recomendado do :term:`PYPA `, permite várias formas de especificação que " "podem ser consideradas um \"requisito\". Para obter mais informações, " @@ -1448,12 +1446,11 @@ msgid "" "project name, and the \">=1.3\" portion is the :term:`Version Specifier`" msgstr "" "Um formato usado por :ref:`pip` para instalar pacotes de um :term:`Índice de " -"Pacotes `. Para um diagrama EBNF do formato, veja a entrada `" -"pkg_resources.Requirement `_ na documentação do " -":ref:`setuptools`. Por exemplo, \"foo>=1.3\" é um especificador de " -"requisitos, onde \"foo\" é o nome do projeto e a parte \">=1.3\" é o :term:`" -"Especificador de Versão`" +"Pacotes`. Para um diagrama EBNF do formato, veja a entrada `pkg_resources." +"Requirement `_ na documentação do :ref:`setuptools`. Por " +"exemplo, \"foo>=1.3\" é um especificador de requisitos, onde \"foo\" é o " +"nome do projeto e a parte \">=1.3\" é o :term:`Especificador de Versão`" #: ../source/glossary.rst:187 msgid "Requirements File" @@ -1466,8 +1463,8 @@ msgid "" "on :ref:`pip:Requirements Files`." msgstr "" "Um arquivo contendo uma lista de :term:`Requisitos ` que podem " -"ser instalados usando :ref:`pip`. Para mais informações, veja a documentação " -":ref:`pip` em :ref:`pip:Requirements Files`." +"ser instalados usando :ref:`pip`. Para mais informações, veja a " +"documentação :ref:`pip` em :ref:`pip:Requirements Files`." #: ../source/glossary.rst:194 #: ../source/guides/distributing-packages-using-setuptools.rst:56 @@ -1484,8 +1481,8 @@ msgid "" "The project specification files for :ref:`distutils` and :ref:`setuptools`. " "See also :term:`pyproject.toml`." msgstr "" -"Os arquivos de especificação do projeto para :ref:`distutils` e " -":ref:`setuptools`. Veja também:term:`pyproject.toml`." +"Os arquivos de especificação do projeto para :ref:`distutils` e :ref:" +"`setuptools`. Veja também:term:`pyproject.toml`." #: ../source/glossary.rst:201 msgid "Source Archive" @@ -1497,9 +1494,10 @@ msgid "" "creation of a :term:`Source Distribution ` or :term:`Built Distribution`." msgstr "" -"Um arquivo contendo o código-fonte bruto para um :term:`Lançamento `" -", antes da criação de uma :term:`Distribuição Fonte ` ou :term:`Distribuição Construída `." +"Um arquivo contendo o código-fonte bruto para um :term:`Lançamento " +"`, antes da criação de uma :term:`Distribuição Fonte ` ou :term:`Distribuição Construída `." #: ../source/glossary.rst:208 msgid "Source Distribution (or \"sdist\")" @@ -1559,9 +1557,9 @@ msgid "" "Environments`." msgstr "" "Um ambiente Python isolado que permite que os pacotes sejam instalados para " -"uso por um aplicativo específico, em vez de serem instalados em todo o " -"sistema. Para obter mais informações, consulte a seção sobre :ref:`Criando e " -"usando ambientes virtuais `." +"uso por uma aplicação específica, em vez de serem instalados em todo o " +"sistema. Para obter mais informações, consulte a seção sobre :ref:`Creating " +"and using Virtual Environments`." #: ../source/glossary.rst:238 msgid "Wheel" @@ -1659,8 +1657,8 @@ msgid "" "Unofficial scripts or attempts at download count inflation (raises download " "counts)" msgstr "" -"Scripts não oficiais ou tentativas de aumento da contagem de download (" -"aumenta a contagem de downloads)" +"Scripts não oficiais ou tentativas de aumento da contagem de download " +"(aumenta a contagem de downloads)" #: ../source/guides/analyzing-pypi-package-downloads.rst:32 msgid "Known historical data quality issues (lowers download counts)" @@ -1720,8 +1718,8 @@ msgstr "" "dataset>`_, você precisará de uma conta do Google e habilitar a API do " "BigQuery em um projeto do Google Cloud Platform. Você pode executar até 1 TB " "de consultas por mês `usando o free tier do BigQuery sem um cartão de " -"crédito `__" +"crédito `__" #: ../source/guides/analyzing-pypi-package-downloads.rst:58 msgid "Navigate to the `BigQuery web UI`_." @@ -1736,8 +1734,8 @@ msgid "" "Enable the `BigQuery API `__." msgstr "" -"Habilite a `API do BigQuery `__." +"Habilite a `BigQuery API `__." #: ../source/guides/analyzing-pypi-package-downloads.rst:63 msgid "" @@ -1836,7 +1834,7 @@ msgstr "details.python" #: ../source/guides/analyzing-pypi-package-downloads.rst:88 msgid "Python version" -msgstr "Versão do python" +msgstr "Versão do Python" #: ../source/guides/analyzing-pypi-package-downloads.rst:88 msgid "``2.7.12``, ``3.6.4``" @@ -1851,8 +1849,8 @@ msgid "" "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" " "button." msgstr "" -"Executa consultas na `interface web do BigQuery`_ clicando no botão \"Compose" -" query\"." +"Executa consultas na `interface web do BigQuery`_ clicando no botão " +"\"Compose query\"." #: ../source/guides/analyzing-pypi-package-downloads.rst:97 msgid "" @@ -2040,8 +2038,8 @@ msgid "" msgstr "" "Além das advertências listadas no histórico acima, Linehaul sofreu de um bug " "que causou um subestimamento das estatísticas de download antes de 26 de " -"julho de 2018. Downloads antes dessa data são proporcionalmente precisos (" -"por exemplo, a porcentagem de Python 2 vs. Python 3 downloads), mas os " +"julho de 2018. Downloads antes dessa data são proporcionalmente precisos " +"(por exemplo, a porcentagem de Python 2 vs. Python 3 downloads), mas os " "números totais são menores do que o real em uma ordem de magnitude." #: ../source/guides/analyzing-pypi-package-downloads.rst:231 @@ -2083,8 +2081,8 @@ msgid "" msgstr "" "`pypinfo`_ é uma ferramenta de linha de comando que fornece acesso ao " "conjunto de dados e pode gerar várias consultas úteis. Por exemplo, você " -"pode consultar o número total de downloads de um pacote com o comando ``" -"pypinfo package_name``." +"pode consultar o número total de downloads de um pacote com o comando " +"``pypinfo package_name``." #: ../source/guides/analyzing-pypi-package-downloads.rst:273 msgid "Install `pypinfo`_ using pip." @@ -2122,8 +2120,8 @@ msgid "" "`PyPI BigQuery dataset announcement email `__" msgstr "" -"`E-mail de anúncio do conjunto de dados BigQuery do PyPI `__" +"`E-mail de anúncio do conjunto de dados BigQuery do PyPI `__" #: ../source/guides/creating-and-discovering-plugins.rst:3 msgid "Creating and discovering plugins" @@ -2136,10 +2134,10 @@ msgid "" "packages can be separately distributed, your application or library may want " "to automatically **discover** all of the plugins available." msgstr "" -"Frequentemente, ao criar um aplicativo ou biblioteca Python, você desejará " +"Frequentemente, ao criar uma aplicação ou biblioteca Python, você desejará " "ter a capacidade de fornecer personalizações ou recursos extras por meio de " "**plug-ins**. Como os pacotes Python podem ser distribuídos separadamente, " -"seu aplicativo ou biblioteca pode querer **descobrir** automaticamente todos " +"sua aplicação ou biblioteca pode querer **descobrir** automaticamente todos " "os plugins disponíveis." #: ../source/guides/creating-and-discovering-plugins.rst:10 @@ -2172,7 +2170,7 @@ msgid "" "uses the naming convention ``flask_{plugin_name}``. If you wanted to " "automatically discover all of the Flask plugins installed:" msgstr "" -"Se todos os plugins para seu aplicativo seguem a mesma convenção de " +"Se todos os plugins para sua aplicação seguem a mesma convenção de " "nomenclatura, você pode usar :func:`pkgutil.iter_modules` para descobrir " "todos os módulos de nível superior que correspondem à convenção de " "nomenclatura. Por exemplo, `Flask`_ usa a convenção de nomenclatura " @@ -2215,10 +2213,10 @@ msgstr "" ":doc:`Pacotes de espaços de nome ` podem ser " "usados para fornecer uma convenção de onde colocar plugins e também fornece " "uma maneira de realizar a descoberta. Por exemplo, se você fizer do " -"subpacote ``myapp.plugins`` um pacote de espaço de nomes, então outras " -":term:`distribuições ` pode fornecer módulos e pacotes " -"para aquele espaço de nomes. Uma vez instalado, você pode usar :func:`pkgutil" -".iter_modules` para descobrir todos os módulos e pacotes instalados sob esse " +"subpacote ``myapp.plugins`` um pacote de espaço de nomes, então outras :term:" +"`distribuições ` pode fornecer módulos e pacotes para " +"aquele espaço de nomes. Uma vez instalado, você pode usar :func:`pkgutil." +"iter_modules` para descobrir todos os módulos e pacotes instalados sob esse " "espaço de nomes:" #: ../source/guides/creating-and-discovering-plugins.rst:89 @@ -2264,8 +2262,8 @@ msgstr "" "incluir o estilo de pacote de espaço de nomes :file:`__init__.py` no " "diretório do subpacote de espaço de nomes (``myapp/plugins``). Isso também " "significa que os plugins precisarão passar explicitamente uma lista de " -"pacotes para o argumento ``packages`` de :func:`setup` ao invés de usar " -":func:`setuptools.find_packages`." +"pacotes para o argumento ``packages`` de :func:`setup` ao invés de usar :" +"func:`setuptools.find_packages`." #: ../source/guides/creating-and-discovering-plugins.rst:115 msgid "" @@ -2291,8 +2289,8 @@ msgid "" "discovery." msgstr "" "`Setuptools`_ fornece :doc:`suporte especial ` para plugins. Fornecendo o argumento ``entry_points`` para " -":func:`setup` em :file:`setup.py`, os plugins podem se registrar para serem " +"entry_point>` para plugins. Fornecendo o argumento ``entry_points`` para :" +"func:`setup` em :file:`setup.py`, os plugins podem se registrar para serem " "descobertos." #: ../source/guides/creating-and-discovering-plugins.rst:128 @@ -2310,16 +2308,16 @@ msgid "" "``importlib_metadata >= 3.6`` for Python 3.6-3.9):" msgstr "" "Então você pode descobrir e carregar todos os pontos de entrada registrados " -"usando :func:`importlib.metadata.entry_points` (ou o `backport`_ ``" -"importlib_metadata >= 3.6`` para Python 3.6-3.9):" +"usando :func:`importlib.metadata.entry_points` (ou o `backport`_ " +"``importlib_metadata >= 3.6`` para Python 3.6-3.9):" #: ../source/guides/creating-and-discovering-plugins.rst:154 msgid "" "In this example, ``discovered_plugins`` would be a collection of type :class:" "`importlib.metadata.EntryPoint`:" msgstr "" -"Neste exemplo, ``discover_plugins`` seria uma coleção do tipo " -":class:`importlib.metadata.EntryPoint`:" +"Neste exemplo, ``discover_plugins`` seria uma coleção do tipo :class:" +"`importlib.metadata.EntryPoint`:" #: ../source/guides/creating-and-discovering-plugins.rst:163 msgid "" @@ -2408,8 +2406,8 @@ msgid "" "`)." msgstr "" "Você precisará disso para enviar as :term:`distribuições `do seu projeto para o :term:`PyPI ` (" -"veja :ref:`abaixo `)." +"Package>` do seu projeto para o :term:`PyPI ` " +"(veja :ref:`abaixo `)." #: ../source/guides/distributing-packages-using-setuptools.rst:49 msgid "Configuring your project" @@ -2466,8 +2464,8 @@ msgid "" "pypa/sampleproject/blob/master/setup.cfg>`_ in the `PyPA sample project " "`_." msgstr "" -":file:`setup.cfg` é um arquivo ini que contém opções padrão para os comandos " -":file:`setup.py`. Para obter um exemplo, consulte o `setup.cfg " +":file:`setup.cfg` é um arquivo ini que contém opções padrão para os " +"comandos :file:`setup.py`. Para obter um exemplo, consulte o `setup.cfg " "`_ no `projeto " "de exemplo PyPA `_." @@ -2488,8 +2486,8 @@ msgstr "" "projeto. O formato mais comum é `reStructuredText `_ com uma extensão \"rst\", embora isso não seja " "um requisito; múltiplas variantes do `Markdown `_ também são suportadas (veja o argumento :ref:`" -"long_description_content_type ` do ``setup()``)." +"projects/markdown/>`_ também são suportadas (veja o argumento :ref:" +"`long_description_content_type ` do ``setup()``)." #: ../source/guides/distributing-packages-using-setuptools.rst:95 msgid "" @@ -2498,8 +2496,8 @@ msgid "" "sampleproject>`_." msgstr "" "Para obter um exemplo, consulte o `README.md `_ do `projeto de exemplo PyPA " -"`_." +"sampleproject/blob/master/README.md>`_ do `projeto de exemplo PyPA `_." #: ../source/guides/distributing-packages-using-setuptools.rst:99 msgid "" @@ -2511,10 +2509,10 @@ msgid "" "don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, " "include it to be explicit." msgstr "" -"Projetos usando :ref:`setuptools` 0.6.27+ têm arquivos leia-me padrão " -"(:file:`README.rst`, :file:`README.txt` ou :file:`README`) incluídos nas " -"distribuições de código-fonte por padrão. A biblioteca interna " -":ref:`distutils` adota este comportamento a partir do Python 3.7. " +"Projetos usando :ref:`setuptools` 0.6.27+ têm arquivos leia-me padrão (:file:" +"`README.rst`, :file:`README.txt` ou :file:`README`) incluídos nas " +"distribuições de código-fonte por padrão. A biblioteca interna :ref:" +"`distutils` adota este comportamento a partir do Python 3.7. " "Adicionalmente, :ref:`setuptools` 36.4.0+ incluirá um :file:`README.md` se " "encontrado. Se você estiver usando setuptools, você não precisa listar seu " "arquivo leia-me em :file:`MANIFEST.in`. Caso contrário, inclua para ser " @@ -2533,9 +2531,9 @@ msgid "" msgstr "" "Um :file:`MANIFEST.in` é necessário quando você precisa empacotar arquivos " "adicionais que não são incluídos automaticamente em uma distribuição de " -"código-fonte. Para obter detalhes sobre como escrever um arquivo " -":file:`MANIFEST.in`, incluindo uma lista do que é incluído por padrão, " -"consulte \":ref:`Usando MANIFEST.in `\"." +"código-fonte. Para obter detalhes sobre como escrever um arquivo :file:" +"`MANIFEST.in`, incluindo uma lista do que é incluído por padrão, consulte \":" +"ref:`Using MANIFEST.in`\"." #: ../source/guides/distributing-packages-using-setuptools.rst:115 msgid "" @@ -2593,8 +2591,8 @@ msgid "" "same :ref:`name ` as your project, or something very close." msgstr "" "Embora não seja obrigatório, a prática mais comum é incluir seus módulos e " -"pacotes Python em um único pacote de nível superior que tem o mesmo :ref:`" -"name ` do seu projeto, ou algo muito próximo." +"pacotes Python em um único pacote de nível superior que tem o mesmo :ref:" +"`name ` do seu projeto, ou algo muito próximo." #: ../source/guides/distributing-packages-using-setuptools.rst:141 msgid "" @@ -2642,8 +2640,8 @@ msgid "" "term:`PyPI `. Per :pep:`508`, valid project " "names must:" msgstr "" -"Este é o nome do seu projeto, determinando como ele está listado no :term:`" -"PyPI `. Conforme :pep:`508`, nomes de projetos " +"Este é o nome do seu projeto, determinando como ele está listado no :term:" +"`PyPI `. Conforme :pep:`508`, nomes de projetos " "válidos devem:" #: ../source/guides/distributing-packages-using-setuptools.rst:174 @@ -2651,8 +2649,8 @@ msgid "" "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), " "and/or periods (``.``), and" msgstr "" -"Consistir apenas em letras ASCII, dígitos, sublinhados (``_``), hífenes " -"(``-``) e/ou pontos (``.``) e" +"Consistir apenas em letras ASCII, dígitos, sublinhados (``_``), hífenes (``-" +"``) e/ou pontos (``.``) e" #: ../source/guides/distributing-packages-using-setuptools.rst:176 msgid "Start & end with an ASCII letter or digit." @@ -2667,9 +2665,9 @@ msgid "" msgstr "" "A comparação de nomes de projetos não diferencia maiúsculas de minúsculas e " "trata sequências arbitrariamente longas de sublinhados, hífenes e/ou pontos " -"como iguais. Por exemplo, se você registrar um projeto chamado ``cool-stuff``" -", os usuários poderão baixá-lo ou declarar uma dependência dele usando " -"qualquer uma das seguintes formas de escrever::" +"como iguais. Por exemplo, se você registrar um projeto chamado ``cool-" +"stuff``, os usuários poderão baixá-lo ou declarar uma dependência dele " +"usando qualquer uma das seguintes formas de escrever::" #: ../source/guides/distributing-packages-using-setuptools.rst:190 #: ../source/specifications/binary-distribution-format.rst:127 @@ -2745,10 +2743,10 @@ msgid "" "https://pypi.org/user/jaraco/)." msgstr "" "``description`` também é exibido em listas de projetos. Por exemplo, ele é " -"visível nas páginas de resultados de pesquisa, como https://pypi.org/search/" -"?q=jupyter, nas listas da página inicial de projetos populares e novos " -"lançamentos e na lista de projetos que você mantém no perfil de sua conta (" -"como https://pypi.org/user/jaraco/)." +"visível nas páginas de resultados de pesquisa, como https://pypi.org/search/?" +"q=jupyter, nas listas da página inicial de projetos populares e novos " +"lançamentos e na lista de projetos que você mantém no perfil de sua conta " +"(como https://pypi.org/user/jaraco/)." #: ../source/guides/distributing-packages-using-setuptools.rst:235 msgid "" @@ -2761,14 +2759,14 @@ msgid "" "Markdown dialect of `Markdown `_ respectively." msgstr "" -"Um `tipo de conteúdo `_ pode ser especificado " -"com o argumento ``long_description_content_type``, que pode ser um de ``text/" +"Um `tipo de conteúdo `_ pode ser especificado com o " +"argumento ``long_description_content_type``, que pode ser um de ``text/" "plain``, ``text/x-rst`` ou ``text/markdown``, correspondendo a nenhuma " "formatação, `reStructuredText (reST) `_, e o dialeto Markdown com " -"sabor do GitHub de `Markdown `" -"_ respectivamente." +"sabor do GitHub de `Markdown `_ respectivamente." #: ../source/guides/distributing-packages-using-setuptools.rst:245 msgid "url" @@ -2842,7 +2840,7 @@ msgstr "" "quais versões do Python um projeto suporta, essas informações são usadas " "apenas para pesquisar e navegar por projetos no PyPI, não para instalar " "projetos. Para realmente restringir em quais versões do Python um projeto " -"pode ser instalado, use o argumento :ref:`python_requires`." +"pode ser instalado, use o argumento :ref:`python_requires `." #: ../source/guides/distributing-packages-using-setuptools.rst:327 msgid "keywords" @@ -2919,9 +2917,9 @@ msgid "" "For more on using \"install_requires\" see :ref:`install_requires vs " "Requirements files`." msgstr "" -"Para mais informações sobre como usar \"install_requires\", veja :ref:`" -"install_requires vs Arquivos de requisitos `." +"Para mais informações sobre como usar \"install_requires\", veja :ref:" +"`install_requires vs Arquivos de requisitos `." #: ../source/guides/distributing-packages-using-setuptools.rst:398 msgid "python_requires" @@ -2990,8 +2988,8 @@ msgid "" "be of interest to programmers using the package. These files are called " "\"package data\"." msgstr "" -"Frequentemente, arquivos adicionais precisam ser instalados em um :term:`" -"pacote `. Esses arquivos geralmente são dados intimamente " +"Frequentemente, arquivos adicionais precisam ser instalados em um :term:" +"`pacote `. Esses arquivos geralmente são dados intimamente " "relacionados à implementação do pacote ou arquivos de texto contendo " "documentação que pode ser do interesse dos programadores que usam o pacote. " "Esses arquivos são chamados de \"dados do pacote\"." @@ -3061,8 +3059,8 @@ msgid "" "additional-files>`_." msgstr "" "Para obter mais informações, consulte a seção distutils em `Instalando " -"arquivos adicionais `_." +"arquivos adicionais `_." #: ../source/guides/distributing-packages-using-setuptools.rst:484 msgid "" @@ -3090,8 +3088,8 @@ msgstr "" "Embora ``setup()`` tenha suporte a uma palavra-chave `scripts `_ para apontar " "para scripts pré-fabricados para instalar, o recomendado A abordagem para " -"obter compatibilidade entre plataformas é usar pontos de entrada " -":ref:`console_scripts` (veja abaixo)." +"obter compatibilidade entre plataformas é usar pontos de entrada :ref:" +"`console_scripts` (veja abaixo)." #: ../source/guides/distributing-packages-using-setuptools.rst:500 msgid "entry_points" @@ -3140,8 +3138,8 @@ msgstr "" "setuptools.html#dynamic-discovery-of-services-and-plugins>`_ \"console_script" "\" para registrar suas interfaces de script. Você pode então deixar o " "conjunto de ferramentas lidar com o trabalho de transformar essas interfaces " -"em scripts reais [2]_. Os scripts serão gerados durante a instalação do seu " -":term:`distribuição `." +"em scripts reais [2]_. Os scripts serão gerados durante a instalação do seu :" +"term:`distribuição `." #: ../source/guides/distributing-packages-using-setuptools.rst:538 msgid "" @@ -3149,10 +3147,10 @@ msgid "" "readthedocs.io/en/latest/setuptools.html#automatic-script-creation>`_ from " "the `setuptools docs `_." msgstr "" -"Para obter mais informações, consulte `Automatic Script Creation " -"`_ da `documentação do setuptools `_." +"Para obter mais informações, consulte `Automatic Script Creation `_ da `documentação do setuptools `_." #: ../source/guides/distributing-packages-using-setuptools.rst:545 msgid "Choosing a versioning scheme" @@ -3170,10 +3168,15 @@ msgid "" "identifiers>` specified in :pep:`440` in order to be supported in tools and " "libraries like ``pip`` and ``setuptools``." msgstr "" +"Diferentes projetos Python podem usar diferentes esquemas de controle de " +"versão com base nas necessidades daquele projeto específico, mas todos eles " +"são obrigados a cumprir com o :pep:`esquema públicode versão <440#public-" +"version-identifiers>` flexível especificado na :pep:`440` para serem " +"suportados em ferramentas e bibliotecas como ``pip`` e ``setuptools``." #: ../source/guides/distributing-packages-using-setuptools.rst:556 msgid "Here are some examples of compliant version numbers::" -msgstr "" +msgstr "Aqui estão alguns exemplos de números de versão compatíveis::" #: ../source/guides/distributing-packages-using-setuptools.rst:567 msgid "" @@ -3182,14 +3185,18 @@ msgid "" "`version normalisation <440#normalization>` that maps variant spellings of " "different version numbers to a standardised canonical form." msgstr "" +"Para acomodar ainda mais as variações históricas nas abordagens de numeração " +"de versão, :pep:`440` também define uma técnica abrangente para :pep:" +"`normalização de versão <440#normalization>` que mapeia grafias variantes de " +"diferentes números de versão para uma forma canônica padronizada." #: ../source/guides/distributing-packages-using-setuptools.rst:573 msgid "Scheme choices" -msgstr "" +msgstr "Opções de esquema" #: ../source/guides/distributing-packages-using-setuptools.rst:576 msgid "Semantic versioning (preferred)" -msgstr "" +msgstr "Versionamento semântico (preferencial)" #: ../source/guides/distributing-packages-using-setuptools.rst:578 msgid "" @@ -3197,26 +3204,35 @@ msgid "" "Versioning `_, but adopts a different approach to " "handling pre-releases and build metadata." msgstr "" +"Para novos projetos, o esquema de controle de versão recomendado é baseado " +"em `Versionamento semântico `_, mas adota uma abordagem " +"diferente para lidar com pré-lançamentos e metadados de compilação." #: ../source/guides/distributing-packages-using-setuptools.rst:582 msgid "" "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE " "numbering scheme, where the project author increments:" msgstr "" +"A essência do versionamento semântico é um esquema de numeração MAIOR.MENOR." +"MANUTENÇÃO de 3 partes, onde o autor do projeto incrementa:" #: ../source/guides/distributing-packages-using-setuptools.rst:585 msgid "MAJOR version when they make incompatible API changes," -msgstr "" +msgstr "Versão PRINCIPAL quando eles fazem alterações de API incompatíveis," #: ../source/guides/distributing-packages-using-setuptools.rst:586 msgid "" "MINOR version when they add functionality in a backwards-compatible manner, " "and" msgstr "" +"Versão MENOR quando adicionam funcionalidade de maneira compatível com " +"versões anteriores, e" #: ../source/guides/distributing-packages-using-setuptools.rst:587 msgid "MAINTENANCE version when they make backwards-compatible bug fixes." msgstr "" +"Versão MANUTENÇÃO quando eles fazem correções de bugs compatíveis com " +"versões anteriores." #: ../source/guides/distributing-packages-using-setuptools.rst:589 msgid "" @@ -3225,16 +3241,22 @@ msgid "" "X.Y`` requires at least release X.Y, but also allows any later release with " "a matching MAJOR version." msgstr "" +"Adotar essa abordagem como autor do projeto permite que os usuários façam " +"uso dos especificadores de :pep:`\"lançamentos compatíveis\" <440#compatible-" +"release>`, onde ``name ~= X.Y`` requer pelo menos a versão X.Y, mas também " +"permite qualquer versão posterior com uma versão PRINCIPAL correspondente." #: ../source/guides/distributing-packages-using-setuptools.rst:594 msgid "" "Python projects adopting semantic versioning should abide by clauses 1-8 of " "the `Semantic Versioning 2.0.0 specification `_." msgstr "" +"Projetos Python que adotam versões semânticas devem obedecer às cláusulas " +"1-8 da `especificação de Versionamento Semântico 2.0.0 `_." #: ../source/guides/distributing-packages-using-setuptools.rst:598 msgid "Date based versioning" -msgstr "" +msgstr "Versionamento baseado em data" #: ../source/guides/distributing-packages-using-setuptools.rst:600 msgid "" @@ -3242,6 +3264,10 @@ msgid "" "with a regular time based release cadence and a deprecation process that " "provides warnings for a number of releases prior to removal of a feature." msgstr "" +"O versionamento semântico não é uma escolha adequada para todos os projetos, " +"como aqueles com uma cadência de lançamento baseada em tempo regular e um " +"processo de descontinuidade que fornece avisos para vários lançamentos antes " +"da remoção de um recurso." #: ../source/guides/distributing-packages-using-setuptools.rst:604 msgid "" @@ -3249,22 +3275,29 @@ msgid "" "tell how old the base feature set of a particular release is given just the " "version number." msgstr "" +"Uma vantagem principal do versionamento baseado em data é que é simples " +"dizer quantos anos o conjunto de recursos básicos de uma determinada versão " +"recebe apenas o número da versão." #: ../source/guides/distributing-packages-using-setuptools.rst:607 msgid "" "Version numbers for date based projects typically take the form of YEAR." "MONTH (for example, ``12.04``, ``15.10``)." msgstr "" +"Os números de versão para projetos baseados em data normalmente assumem a " +"forma de ANO.MÊS (por exemplo, ``12.04``, ``15.10``)." #: ../source/guides/distributing-packages-using-setuptools.rst:611 msgid "Serial versioning" -msgstr "" +msgstr "Versionamento serial" #: ../source/guides/distributing-packages-using-setuptools.rst:613 msgid "" "This is the simplest possible versioning scheme, and consists of a single " "number which is incremented every release." msgstr "" +"Este é o esquema de versionamento mais simples possível e consiste em um " +"único número que é incrementado a cada versão." #: ../source/guides/distributing-packages-using-setuptools.rst:616 msgid "" @@ -3272,10 +3305,14 @@ msgid "" "hardest to track as an end user, as serial version numbers convey little or " "no information regarding API backwards compatibility." msgstr "" +"Embora o versionamento serial seja muito fácil de gerenciar como " +"desenvolvedor, é o mais difícil de rastrear como usuário final, pois os " +"números de versão serial transmitem pouca ou nenhuma informação sobre " +"compatibilidade com versões anteriores da API." #: ../source/guides/distributing-packages-using-setuptools.rst:621 msgid "Hybrid schemes" -msgstr "" +msgstr "Esquemas híbridos" #: ../source/guides/distributing-packages-using-setuptools.rst:623 msgid "" @@ -3284,42 +3321,52 @@ msgid "" "numbering scheme that readily conveys the approximate age of a release, but " "doesn't otherwise commit to a particular release cadence within the year." msgstr "" +"Combinações dos esquemas acima são possíveis. Por exemplo, um projeto pode " +"combinar o versionamento baseado em data com o versionamento serial para " +"criar um esquema de numeração ANO.SÉRIE que transmite prontamente a idade " +"aproximada de um lançamento, mas não se compromete com uma cadência de " +"lançamento particular dentro do ano." #: ../source/guides/distributing-packages-using-setuptools.rst:629 msgid "Pre-release versioning" -msgstr "" +msgstr "Versionamento de pré-lançamento" #: ../source/guides/distributing-packages-using-setuptools.rst:631 msgid "" "Regardless of the base versioning scheme, pre-releases for a given final " "release may be published as:" msgstr "" +"Independentemente do esquema de versionamento base, os pré-lançamentos para " +"uma determinada versão final podem ser publicados como:" #: ../source/guides/distributing-packages-using-setuptools.rst:634 msgid "zero or more dev releases (denoted with a \".devN\" suffix)" -msgstr "" +msgstr "zero ou mais versões dev (denotadas com um sufixo \".devN\")" #: ../source/guides/distributing-packages-using-setuptools.rst:635 msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" -msgstr "" +msgstr "zero ou mais versões alfa (denotadas com um sufixo \".aN\")" #: ../source/guides/distributing-packages-using-setuptools.rst:636 msgid "zero or more beta releases (denoted with a \".bN\" suffix)" -msgstr "" +msgstr "zero ou mais versões beta (denotadas com um sufixo \".bN\")" #: ../source/guides/distributing-packages-using-setuptools.rst:637 msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" msgstr "" +"zero ou mais candidatos a lançamento (denotados com um sufixo \".rcN\")" #: ../source/guides/distributing-packages-using-setuptools.rst:639 msgid "" "``pip`` and other modern Python package installers ignore pre-releases by " "default when deciding which versions of dependencies to install." msgstr "" +"``pip`` e outros instaladores de pacotes Python modernos ignoram os pré-" +"lançamentos por padrão ao decidir quais versões de dependências instalar." #: ../source/guides/distributing-packages-using-setuptools.rst:644 msgid "Local version identifiers" -msgstr "" +msgstr "Identificadores de versão local" #: ../source/guides/distributing-packages-using-setuptools.rst:646 msgid "" @@ -3330,16 +3377,25 @@ msgid "" "builds not intended for publication, or modified variants of a release " "maintained by a redistributor." msgstr "" +"Identificadores de versão pública são projetados para suportar distribuição " +"via :term:`PyPI `. As ferramentas de " +"distribuição de software do Python também suportam a noção de um :pep:" +"`identificador de versão local <440#local-version-identifiers>`, que pode " +"ser usado para identificar compilações de desenvolvimento local não " +"destinadas à publicação, ou variantes modificadas de uma versão mantida por " +"um redistribuidor." #: ../source/guides/distributing-packages-using-setuptools.rst:653 msgid "" "A local version identifier takes the form ``" "+``. For example::" msgstr "" +"Um identificador de versão local assume a forma ``+``. Por exemplo::" #: ../source/guides/distributing-packages-using-setuptools.rst:661 msgid "Working in \"development mode\"" -msgstr "" +msgstr "Trabalhando em \"modo de desenvolvimento\"" #: ../source/guides/distributing-packages-using-setuptools.rst:663 msgid "" @@ -3347,10 +3403,13 @@ msgid "" "\"editable\" or \"develop\" mode while you're working on it. This allows " "your project to be both installed and editable in project form." msgstr "" +"Embora não seja obrigatório, é comum instalar localmente seu projeto no modo " +"\"editável\" ou \"desenvolvimento\" enquanto você trabalha nele. Isso " +"permite que seu projeto seja instalado e editável na forma de projeto." #: ../source/guides/distributing-packages-using-setuptools.rst:667 msgid "Assuming you're in the root of your project directory, then run:" -msgstr "" +msgstr "Supondo que você esteja na raiz do diretório do seu projeto, execute:" #: ../source/guides/distributing-packages-using-setuptools.rst:674 msgid "" @@ -3361,6 +3420,12 @@ msgid "" "declared with \"console_scripts\". Dependencies will be installed in the " "usual, non-editable mode." msgstr "" +"Embora um pouco enigmático, ``-e`` é abreviação de ``--editable``, e ``.`` " +"refere-se ao diretório de trabalho atual, então juntos, isso significa " +"instalar o diretório atual (ou seja, seu projeto) em modo editável. Isso " +"também instalará quaisquer dependências declaradas com \"install_requires\" " +"e quaisquer scripts declarados com \"console_scripts\". As dependências " +"serão instaladas no modo usual e não editável." #: ../source/guides/distributing-packages-using-setuptools.rst:680 msgid "" @@ -3369,6 +3434,10 @@ msgid "" "and \"bar\", but you want \"bar\" installed from VCS in editable mode, then " "you could construct a requirements file like so::" msgstr "" +"É bastante comum também querer instalar algumas de suas dependências no modo " +"editável. Por exemplo, supondo que seu projeto requer \"foo\" e \"bar\", mas " +"você deseja \"bar\" instalado do VCS no modo editável, então você poderia " +"construir um arquivo de requisitos como::" #: ../source/guides/distributing-packages-using-setuptools.rst:688 msgid "" @@ -3376,6 +3445,9 @@ msgid "" "line overrides the \"bar\" dependency, such that it's fulfilled from VCS, " "not PyPI." msgstr "" +"A primeira linha diz para instalar seu projeto e todas as dependências. A " +"segunda linha substitui a dependência \"bar\", de modo que seja preenchida a " +"partir do VCS, não PyPI." #: ../source/guides/distributing-packages-using-setuptools.rst:692 msgid "" @@ -3383,6 +3455,9 @@ msgid "" "mode, the requirements file should look like this, with the local paths at " "the top of the file::" msgstr "" +"Se, no entanto, você quiser \"bar\" instalado de um diretório local em modo " +"editável, o arquivo de requisitos deve ser semelhante a este, com os " +"caminhos locais no topo do arquivo::" #: ../source/guides/distributing-packages-using-setuptools.rst:697 msgid "" @@ -3392,11 +3467,18 @@ msgid "" "the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." msgstr "" +"Caso contrário, a dependência será resolvida pelo PyPI, devido à ordem de " +"instalação do arquivo de requisitos. Para mais informações sobre os arquivos " +"de requisitos, consulte a seção :ref:`Requirements File ` na documentação do pip. Para obter mais informações sobre as " +"instalações de VCS, consulte a seção :ref:`VCS Support ` da " +"documentação do pip." #: ../source/guides/distributing-packages-using-setuptools.rst:701 msgid "" "Lastly, if you don't want to install any dependencies at all, you can run::" msgstr "" +"Por último, se você não deseja instalar nenhuma dependência, pode executar::" #: ../source/guides/distributing-packages-using-setuptools.rst:706 msgid "" @@ -3404,10 +3486,13 @@ msgid "" "readthedocs.io/en/latest/setuptools.html#development-mode>`_ section of the " "`setuptools docs `_." msgstr "" +"Para obter mais informações, consulte a seção `Development Mode `_ da " +"`documentação do setuptools `_." #: ../source/guides/distributing-packages-using-setuptools.rst:713 msgid "Packaging your project" -msgstr "" +msgstr "Empacotando seu projeto" #: ../source/guides/distributing-packages-using-setuptools.rst:715 msgid "" @@ -3416,22 +3501,30 @@ msgid "" "`Distribution ` (aka \":term:`Package `\") for your project." msgstr "" +"Para ter seu projeto instalável de um :term:`Índice de Pacotes` como o :term:" +"`PyPI `, você precisará criar uma :term:" +"`Distribuição ` (também conhecida como \":term:`Pacote " +"`\") para seu projeto." #: ../source/guides/distributing-packages-using-setuptools.rst:720 msgid "" "Before you can build wheels and sdists for your project, you'll need to " "install the ``build`` package:" msgstr "" +"Antes de compilar wheels e sdists para seu projeto, você precisará instalar " +"o pacote ``build``:" #: ../source/guides/distributing-packages-using-setuptools.rst:737 msgid "Source distributions" -msgstr "" +msgstr "Distribuições fontes" #: ../source/guides/distributing-packages-using-setuptools.rst:739 msgid "" "Minimally, you should create a :term:`Source Distribution `:" msgstr "" +"Minimamente, você deve criar uma :term:`Distribuição Fonte `:" #: ../source/guides/distributing-packages-using-setuptools.rst:755 msgid "" @@ -3441,10 +3534,15 @@ msgid "" "involves a build step to build out the installation metadata from :file:" "`setup.py` and/or :file:`setup.cfg`." msgstr "" +"Uma \"distribuição fonte\" é não construída (ou seja, não é uma :term:" +"`Distribuição Construída`) e requer uma etapa de construção quando instalada " +"pelo pip. Mesmo se a distribuição for puro Python (ou seja, não contém " +"extensões), ainda envolve uma etapa de construção para construir os " +"metadados de instalação de :file:`setup.py` e/ou :file:`setup.cfg`." #: ../source/guides/distributing-packages-using-setuptools.rst:763 msgid "Wheels" -msgstr "" +msgstr "Wheels" #: ../source/guides/distributing-packages-using-setuptools.rst:765 msgid "" @@ -3453,18 +3551,28 @@ msgid "" "through the \"build\" process. Installing wheels is substantially faster for " "the end user than installing from a source distribution." msgstr "" +"Você também deve criar uma wheel para o seu projeto. Uma wheel é um :term:" +"`pacote construído ` que pode ser instalado sem a " +"necessidade de passar pelo processo de \"construção\". Instalar wheel é " +"substancialmente mais rápido para o usuário final do que instalar a partir " +"de uma distribuição original." #: ../source/guides/distributing-packages-using-setuptools.rst:770 msgid "" "If your project is pure Python then you'll be creating a :ref:`\"Pure Python " "Wheel\" (see section below) `." msgstr "" +"Se o seu projeto for puro Python, você criará uma :ref:`\"Wheel de Python " +"Puro\" (consulte a seção abaixo) `." #: ../source/guides/distributing-packages-using-setuptools.rst:773 msgid "" "If your project contains compiled extensions, then you'll be creating what's " "called a :ref:`*Platform Wheel* (see section below) `." msgstr "" +"Se o seu projeto contém extensões compiladas, então você criará o que é " +"chamado de :ref:`*Wheel de Plataforma* (veja a seção abaixo) `." #: ../source/guides/distributing-packages-using-setuptools.rst:776 msgid "" @@ -3472,27 +3580,34 @@ msgid "" "you should create what's called a *Universal Wheel* by adding the following " "to your :file:`setup.cfg` file:" msgstr "" +"Se o seu projeto também tiver suporte a Python 2 *e* não contiver extensões " +"C, você deve criar o que é chamado de *Wheel Universal* adicionando o " +"seguinte ao seu arquivo :file:`setup.cfg`:" #: ../source/guides/distributing-packages-using-setuptools.rst:785 msgid "" "Only use this setting if your project does not have any C extensions *and* " "supports Python 2 and 3." msgstr "" +"Use esta configuração apenas se o seu projeto não tiver extensões C *e* " +"tiver suporte ao Python 2 e 3." #: ../source/guides/distributing-packages-using-setuptools.rst:792 msgid "Pure Python Wheels" -msgstr "" +msgstr "Wheels de Puro Python" #: ../source/guides/distributing-packages-using-setuptools.rst:794 msgid "" "*Pure Python Wheels* contain no compiled extensions, and therefore only " "require a single Python wheel." msgstr "" +"*Wheels de Python Puro* contêm nenhuma extensão compilada e, portanto, só " +"exigem um único wheel Python." #: ../source/guides/distributing-packages-using-setuptools.rst:797 #: ../source/guides/distributing-packages-using-setuptools.rst:826 msgid "To build the wheel:" -msgstr "" +msgstr "Para construir o wheel:" #: ../source/guides/distributing-packages-using-setuptools.rst:811 msgid "" @@ -3500,22 +3615,31 @@ msgid "" "wheel that's named such that it's usable on any Python 3 installation. For " "details on the naming of wheel files, see :pep:`425`." msgstr "" +"O pacote ``wheel`` detectará que o código é puro Python, e construirá um " +"wheel cujo nome pode ser usado em qualquer instalação do Python 3. Para " +"obter detalhes sobre a nomenclatura de arquivos wheel, consulte :pep:`425`." #: ../source/guides/distributing-packages-using-setuptools.rst:815 msgid "" "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both " "files for you; this is useful when you don't need multiple wheels." msgstr "" +"Se você executar ``build`` sem ``--wheel`` ou ``--sdist``, ele irá construir " +"os dois arquivos para você; isso é útil quando você não precisa de vários " +"wheels." #: ../source/guides/distributing-packages-using-setuptools.rst:821 msgid "Platform Wheels" -msgstr "" +msgstr "Wheels de Plataforma" #: ../source/guides/distributing-packages-using-setuptools.rst:823 msgid "" "*Platform Wheels* are wheels that are specific to a certain platform like " "Linux, macOS, or Windows, usually due to containing compiled extensions." msgstr "" +"*Wheels de Plataforma* são wheels que são específicos para uma certa " +"plataforma, como Linux, macOS ou Windows, geralmente em razão de conter " +"extensões compiladas." #: ../source/guides/distributing-packages-using-setuptools.rst:841 msgid "" @@ -3523,6 +3647,9 @@ msgid "" "build a wheel that's named such that it's only usable on the platform that " "it was built on. For details on the naming of wheel files, see :pep:`425`." msgstr "" +"O pacote ``wheel`` detectará que o código não é puro Python e construirá um " +"wheel cujo nome só pode ser usado na plataforma em que foi construído. Para " +"obter detalhes sobre a nomenclatura de arquivos wheel, consulte :pep:`425`." #: ../source/guides/distributing-packages-using-setuptools.rst:847 msgid "" @@ -3530,10 +3657,13 @@ msgid "" "platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. " "Details of the latter are defined in :pep:`513`." msgstr "" +":term:`PyPI ` tem suporte atualmente a envios " +"de wheels de plataforma do Windows, macOS e da ABI multidistro " +"``manylinux*``. Detalhes sobre o último estão definidos em :pep:`513`." #: ../source/guides/distributing-packages-using-setuptools.rst:855 msgid "Uploading your Project to PyPI" -msgstr "" +msgstr "Enviando seu Projeto para PyPI" #: ../source/guides/distributing-packages-using-setuptools.rst:857 msgid "" @@ -3541,6 +3671,9 @@ msgid "" "`` was created under your project's root directory. That's where you'll find " "your distribution file(s) to upload." msgstr "" +"Quando você executou o comando para criar sua distribuição, um novo " +"diretório ``dist/`` foi criado no diretório raiz do seu projeto. É onde você " +"encontrará seus arquivos de distribuição para enviar." #: ../source/guides/distributing-packages-using-setuptools.rst:861 msgid "" @@ -3549,6 +3682,11 @@ msgid "" "or the configuration in your :file:`setup.py` file, you will need to rebuild " "these files again before you can distribute the changes to PyPI." msgstr "" +"Esses arquivos são criados apenas quando você executa o comando para criar " +"sua distribuição. Isso significa que a qualquer momento que você alterar a " +"fonte do seu projeto ou a configuração no arquivo :file:`setup.py`, você " +"precisará reconstruir esses arquivos novamente antes de distribuir as " +"alterações para PyPI." #: ../source/guides/distributing-packages-using-setuptools.rst:866 msgid "" @@ -3557,6 +3695,10 @@ msgid "" "basis. See :ref:`using-test-pypi` on how to setup your configuration in " "order to use it." msgstr "" +"Antes de lançar no repositório principal do PyPI, você pode preferir treinar " +"com o `site de teste do PyPI `_ que é redefinido em " +"uma base semirregular. Veja :ref:`using-test-pypi` sobre como definir sua " +"configuração para usá-lo." #: ../source/guides/distributing-packages-using-setuptools.rst:871 msgid "" @@ -3566,6 +3708,12 @@ msgid "" "HTTP or unverified HTTPS connection on some Python versions, allowing your " "username and password to be intercepted during transmission." msgstr "" +"Em outros recursos, você pode encontrar referências ao uso de ``python setup." +"py register`` e ``python setup.py upload``. Esses métodos de registro e " +"envio de um pacote são **fortemente desencorajados**, pois podem usar uma " +"conexão HTTP de texto simples ou HTTPS não verificada em algumas versões " +"Python, permitindo que seu nome de usuário e senha sejam interceptados " +"durante a transmissão." #: ../source/guides/distributing-packages-using-setuptools.rst:877 msgid "" @@ -3576,6 +3724,13 @@ msgid "" "long descriptions provided in :file:`setup.py` are valid. You can do this " "by running :std:doc:`twine check ` on your package files::" msgstr "" +"O analisador de reStructuredText usado no PyPI **não é** Sphinx! Além disso, " +"para garantir a segurança de todos os usuários, certos tipos de URLs e " +"diretivas são proibidos ou removidos (por exemplo, a diretiva ``.. raw::``). " +"**Antes** de tentar enviar sua distribuição, você deve verificar se suas " +"descrições breves/longas fornecidas no :file:`setup.py` são válidas. Você " +"pode fazer isso executando :std:doc:`twine check ` em todos arquivos " +"do seu pacote::" #: ../source/guides/distributing-packages-using-setuptools.rst:888 msgid "Create an account" @@ -3587,12 +3742,17 @@ msgid "" "You can create an account `using the form on the PyPI website `_." msgstr "" +"Primeiro, você precisa de uma conta de usuário do :term:`PyPI `. Você pode criar uma conta `usando o formulário no " +"site do PyPI `_." #: ../source/guides/distributing-packages-using-setuptools.rst:894 msgid "" "Now you'll create a PyPI `API token`_ so you will be able to securely upload " "your project." msgstr "" +"Agora você criará um PyPI `token de API `_ para que possa enviar " +"o seu projeto com segurança." #: ../source/guides/distributing-packages-using-setuptools.rst:897 msgid "" @@ -3600,22 +3760,29 @@ msgid "" "token`_; don't limit its scope to a particular project, since you are " "creating a new project." msgstr "" +"Acesse https://pypi.org/manage/account/#api-tokens e crie um novo `API de " +"token `_; não limite seu escopo a um projeto específico, já que " +"você está criando um novo projeto." #: ../source/guides/distributing-packages-using-setuptools.rst:901 msgid "" "**Don't close the page until you have copied and saved the token — you won't " "see that token again.**" msgstr "" +"**Não feche a página antes de copiar e salvar o token -- você não verá o " +"token novamente.**" #: ../source/guides/distributing-packages-using-setuptools.rst:904 msgid "" "To avoid having to copy and paste the token every time you upload, you can " "create a :file:`$HOME/.pypirc` file:" msgstr "" +"Para evitar ter que copiar e colar o token toda vez que você enviar, você " +"pode criar um arquivo :file:`$HOME/.pypirc`:" #: ../source/guides/distributing-packages-using-setuptools.rst:913 msgid "**Be aware that this stores your token in plaintext.**" -msgstr "" +msgstr "**Esteja ciente de que isso armazena seu token em texto simples.**" #: ../source/guides/distributing-packages-using-setuptools.rst:915 #: ../source/guides/migrating-to-pypi-org.rst:70 @@ -3624,16 +3791,19 @@ msgstr "" msgid "" "For more details, see the :ref:`specification ` for :file:`.pypirc`." msgstr "" +"Para mais detalhes, veja a :ref:`especificação ` do :file:`.pypirc`." #: ../source/guides/distributing-packages-using-setuptools.rst:921 msgid "Upload your distributions" -msgstr "" +msgstr "Enviar suas distribuições" #: ../source/guides/distributing-packages-using-setuptools.rst:923 msgid "" "Once you have an account you can upload your distributions to :term:`PyPI " "` using :ref:`twine`." msgstr "" +"Assim que tiver uma conta, você pode enviar suas distribuições para o :term:" +"`PyPI ` usando :ref:`twine`." #: ../source/guides/distributing-packages-using-setuptools.rst:926 msgid "" @@ -3641,12 +3811,17 @@ msgid "" "the project already exists on PyPI - if it doesn't exist yet, it will be " "automatically created when the first release is uploaded." msgstr "" +"O processo de envio de uma versão é o mesmo, independentemente de o projeto " +"já existir ou não no PyPI -- se ainda não existir, será criado " +"automaticamente quando a primeira versão for carregada." #: ../source/guides/distributing-packages-using-setuptools.rst:930 msgid "" "For the second and subsequent releases, PyPI only requires that the version " "number of the new release differ from any previous releases." msgstr "" +"Para a segunda versão e as subsequentes, PyPI requer apenas que o número da " +"versão da nova versão seja diferente de todas as versões anteriores." #: ../source/guides/distributing-packages-using-setuptools.rst:937 msgid "" @@ -3655,6 +3830,10 @@ msgid "" "the name of your project that you uploaded. It may take a minute or two for " "your project to appear on the site." msgstr "" +"Você pode ver se o seu pacote foi enviado com sucesso navegando para a URL " +"``https://pypi.org/project/`` onde ``projetoexemplo`` é o " +"nome do seu projeto que você enviou. O seu projeto pode demorar um ou dois " +"minutos para aparecer no site." #: ../source/guides/distributing-packages-using-setuptools.rst:944 #: ../source/tutorials/installing-packages.rst:663 @@ -3663,6 +3842,10 @@ msgid "" "ref:`pip` is currently considering changing this by `making user installs " "the default behavior `_." msgstr "" +"Dependendo da sua plataforma, isso pode exigir acesso de root ou de " +"administrador. :ref:`pip` está atualmente considerando mudar isso `tornando " +"as instalações de usuário o comportamento padrão `_." #: ../source/guides/distributing-packages-using-setuptools.rst:950 msgid "" @@ -3671,16 +3854,24 @@ msgid "" "Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for " "Windows <397>` allow scripts to be used in many cases, but not all." msgstr "" +"Especificamente, a abordagem \"console_script\" gera arquivos ``.exe`` no " +"Windows, que são necessários por causa dos arquivos ``.exe`` de casos " +"especiais do sistema operacional. Recursos de execução de script como " +"``PATHEXT`` e o :pep:`Inicializador do Python para Windows <397>` permitem " +"que scripts sejam usados em muitos casos, mas não em todos." #: ../source/guides/dropping-older-python-versions.rst:5 msgid "Dropping support for older Python versions" -msgstr "" +msgstr "Descartando suporte para versões mais antigas do Python" #: ../source/guides/dropping-older-python-versions.rst:7 msgid "" "Dropping support for older Python versions is supported by the standard :ref:" "`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." msgstr "" +"O descarte de suporte para versões mais antigas do Python é suportado pela " +"especificação padrão :ref:`core-metadata` 1.2 através de um atributo " +"\"Requires-Python\"." #: ../source/guides/dropping-older-python-versions.rst:9 msgid "" @@ -3689,12 +3880,20 @@ msgid "" "version in the package metadata. If they do not match, it will attempt to " "install the last package distribution that supported that Python runtime." msgstr "" +"Clientes com Metadata 1.2+, como Pip 9.0+, irão aderir a esta especificação " +"combinando o tempo de execução Python atual e comparando-o com a versão " +"necessária nos metadados do pacote. Se eles não corresponderem, ele tentará " +"instalar a última distribuição de pacote que oferece suporte a esse tempo de " +"execução do Python." #: ../source/guides/dropping-older-python-versions.rst:12 msgid "" "This mechanism can be used to drop support for older Python versions, by " "amending the \"Requires-Python\" attribute in the package metadata." msgstr "" +"Este mecanismo pode ser usado para descartar o suporte para versões mais " +"antigas do Python, alterando o atributo \"Requires-Python\" nos metadados do " +"pacote." #: ../source/guides/dropping-older-python-versions.rst:14 msgid "" @@ -3702,32 +3901,37 @@ msgid "" "tools such as ``flit`` may offer similar functionality but users will need " "to consult relevant documentation." msgstr "" +"Este guia é especificamente para usuários de :ref:`setuptools`, outras " +"ferramentas de empacotamento como ``flit`` podem oferecer funcionalidade " +"semelhante, mas os usuários precisarão consultar a documentação relevante." #: ../source/guides/dropping-older-python-versions.rst:17 msgid "Requirements" -msgstr "" +msgstr "Requisitos" #: ../source/guides/dropping-older-python-versions.rst:19 msgid "This workflow requires that:" -msgstr "" +msgstr "Este fluxo de trabalho exige que:" #: ../source/guides/dropping-older-python-versions.rst:21 msgid "The publisher is using the latest version of :ref:`setuptools`," -msgstr "" +msgstr "O editor esteja usando a versão mais recente de :ref:`setuptools`," #: ../source/guides/dropping-older-python-versions.rst:22 msgid "The latest version of :ref:`twine` is used to upload the package," -msgstr "" +msgstr "A última versão do :ref:`twine` seja usada para enviar o pacote," #: ../source/guides/dropping-older-python-versions.rst:23 msgid "" "The user installing the package has at least Pip 9.0, or a client that " "supports the Metadata 1.2 specification." msgstr "" +"O usuário que instala o pacote tenha pelo menos Pip 9.0 ou um cliente que " +"tenha suporte à especificação Metadata 1.2." #: ../source/guides/dropping-older-python-versions.rst:26 msgid "Dealing with the universal wheels" -msgstr "" +msgstr "Lidando com os wheels universais" #: ../source/guides/dropping-older-python-versions.rst:28 msgid "" @@ -3738,12 +3942,20 @@ msgid "" "often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` " "section by setting ``universal = 1`` if they use setuptools." msgstr "" +"Tradicionalmente, os projetos que fornecem código Python que é " +"semanticamente compatível com Python 2 e Python 3, produzem :term:`wheels " +"` que têm uma tag ``py2.py3`` em seus nomes. Ao descartar o suporte " +"para Python 2, é importante não se esquecer de alterar essa tag para apenas " +"``py3``. Isso geralmente é configurado em :file:`setup.cfg` na seção " +"``[bdist_wheel]`` definindo ``universal = 1`` se eles usam setuptools." #: ../source/guides/dropping-older-python-versions.rst:36 msgid "" "If you use this method, either remove this option or section, or explicitly " "set ``universal`` to ``0``:" msgstr "" +"Se você usar este método, remova esta opção ou seção, ou defina " +"explicitamente ``universal`` como ``0``:" #: ../source/guides/dropping-older-python-versions.rst:48 msgid "" @@ -3751,38 +3963,46 @@ msgid "" "flags, make sure that your scripts don't have ``--universal`` in your " "package creation scripts." msgstr "" +"Visto que ser possível sobrescrever as configurações de :file:`setup.cfg` " +"via sinalizadores CLI, certifique-se de que seus scripts não tenham ``--" +"universal`` em seus scripts de criação de pacote." #: ../source/guides/dropping-older-python-versions.rst:53 msgid "Defining the Python version required" -msgstr "" +msgstr "Definindo a versão Python exigida" #: ../source/guides/dropping-older-python-versions.rst:56 msgid "1. Download the newest version of Setuptools" -msgstr "" +msgstr "1. Baixe a versão mais recente do Setuptools" #: ../source/guides/dropping-older-python-versions.rst:58 msgid "" "Ensure that before you generate source distributions or binary " "distributions, you update Setuptools and install twine." msgstr "" +"Certifique-se de, antes de gerar distribuições de fontes ou distribuições " +"binárias, atualizar o Setuptools e instalar o twine." #: ../source/guides/dropping-older-python-versions.rst:60 msgid "Steps:" -msgstr "" +msgstr "Passos:" #: ../source/guides/dropping-older-python-versions.rst:74 msgid "`setuptools` version should be above 24.0.0." -msgstr "" +msgstr "A versão do `setuptools` deve ser superior a 24.0.0." #: ../source/guides/dropping-older-python-versions.rst:77 msgid "2. Specify the version ranges for supported Python distributions" msgstr "" +"2. Especifique os intervalos de versão para distribuições Python suportadas" #: ../source/guides/dropping-older-python-versions.rst:79 msgid "" "You can specify version ranges and exclusion rules, such as at least Python " "3. Or, Python 2.7, 3.4 and beyond." msgstr "" +"Você pode especificar intervalos de versão e regras de exclusão, como pelo " +"menos Python 3. Ou Python 2.7, 3.4 e superior." #: ../source/guides/dropping-older-python-versions.rst:81 #: ../source/specifications/core-metadata.rst:139 @@ -3794,7 +4014,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:693 #: ../source/specifications/core-metadata.rst:722 msgid "Examples::" -msgstr "" +msgstr "Exemplos::" #: ../source/guides/dropping-older-python-versions.rst:86 msgid "" @@ -3802,16 +4022,21 @@ msgid "" "file:`setup.py` script. This will insert the ``Requires-Python`` metadata " "values based on the argument you provide in ``python_requires``." msgstr "" +"A maneira de definir esses valores está na chamada de ``setup`` dentro do " +"seu script :file:`setup.py`. Isso irá inserir os valores de metadados " +"``Requires-Python`` com base no argumento fornecido em ``python_requires``." #: ../source/guides/dropping-older-python-versions.rst:101 msgid "3. Validating the Metadata before publishing" -msgstr "" +msgstr "3. Validando o Metadata antes de publicar" #: ../source/guides/dropping-older-python-versions.rst:103 msgid "" "Within a Python source package (the zip or the tar-gz file you download) is " "a text file called PKG-INFO." msgstr "" +"Dentro de um pacote fonte Python (o arquivo zip ou tar-gz que você baixou) " +"está um arquivo de texto chamado PKG-INFO." #: ../source/guides/dropping-older-python-versions.rst:105 msgid "" @@ -3819,59 +4044,75 @@ msgid "" "the source package. The file contains a set of keys and values, the list of " "keys is part of the PyPa standard metadata format." msgstr "" +"Este arquivo é gerado pelo Distutils ou :ref:`setuptools` quando ele gera o " +"pacote fonte. O arquivo contém um conjunto de chaves e valores, a lista de " +"chaves faz parte do formato de metadados padrão do PyPa." #: ../source/guides/dropping-older-python-versions.rst:108 msgid "You can see the contents of the generated file like this::" -msgstr "" +msgstr "Você pode ver o conteúdo do arquivo gerado assim::" #: ../source/guides/dropping-older-python-versions.rst:112 msgid "Validate that the following is in place, before publishing the package:" -msgstr "" +msgstr "Valide que o seguinte está no lugar, antes de publicar o pacote:" #: ../source/guides/dropping-older-python-versions.rst:114 msgid "" "If you have upgraded correctly, the Metadata-Version value should be 1.2 or " "higher." msgstr "" +"Se você atualizou corretamente, o valor de Metadata-Version deve ser 1.2 ou " +"superior." #: ../source/guides/dropping-older-python-versions.rst:115 msgid "" "The Requires-Python field is set and matches your specification in setup.py." msgstr "" +"O campo Requires-Python está definido e corresponde a sua especificação no " +"setup.py." #: ../source/guides/dropping-older-python-versions.rst:118 msgid "4. Using Twine to publish" -msgstr "" +msgstr "4. Usando Twine para publicar" #: ../source/guides/dropping-older-python-versions.rst:120 msgid "" "Twine has a number of advantages, apart from being faster it is now the " "supported method for publishing packages." msgstr "" +"Twine tem uma série de vantagens, além de ser mais rápido, agora é o método " +"suportado para publicação de pacotes." #: ../source/guides/dropping-older-python-versions.rst:122 msgid "Make sure you are using the newest version of Twine, at least 1.9." msgstr "" +"Certifique-se de estar usando a versão mais recente do Twine, pelo menos 1.9." #: ../source/guides/dropping-older-python-versions.rst:125 msgid "Dropping a Python release" -msgstr "" +msgstr "Descartando uma versão Python" #: ../source/guides/dropping-older-python-versions.rst:127 msgid "" "Once you have published a package with the Requires-Python metadata, you can " "then make a further update removing that Python runtime from support." msgstr "" +"Depois de publicar um pacote com os metadados de Requires-Python, você pode " +"fazer uma atualização adicional removendo esse tempo de execução Python do " +"suporte." #: ../source/guides/dropping-older-python-versions.rst:129 msgid "It must be done in this order for the automated fallback to work." msgstr "" +"Deve ser feito nesta ordem para que o alternativa automatizada funcione." #: ../source/guides/dropping-older-python-versions.rst:131 msgid "" "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 " "of your package." msgstr "" +"Por exemplo, você publicou o Requires-Python: \">=2.7\" como a versão 1.0.0 " +"do seu pacote." #: ../source/guides/dropping-older-python-versions.rst:133 msgid "" @@ -3880,10 +4121,14 @@ msgid "" "2.7 will have version 1.0.0 of the package installed, and any >=3.5 users " "will receive version 2.0.0." msgstr "" +"Se você atualizasse a string da versão para \">=3.5\" e publicasse uma nova " +"versão 2.0.0 do seu pacote, todos os usuários executando o Pip 9.0+ a partir " +"da versão 2.7 terão a versão 1.0.0 do pacote instalada e qualquer >=3.5 " +"usuários receberão a versão 2.0.0." #: ../source/guides/hosting-your-own-index.rst:5 msgid "Hosting your own simple repository" -msgstr "" +msgstr "Hospedando seu próprio simples repositório" #: ../source/guides/hosting-your-own-index.rst:8 msgid "" @@ -3892,6 +4137,10 @@ msgid "" "directory structure and use any web server that can serve static files and " "generate an autoindex." msgstr "" +"Se você deseja hospedar seu próprio repositório simples [1]_, você pode usar " +"um pacote de software como `devpi`_ ou você pode usar simplesmente criar a " +"estrutura de diretório apropriada e usar qualquer servidor web que pode " +"servir arquivos estáticos e gerar um autoindex." #: ../source/guides/hosting-your-own-index.rst:13 msgid "" @@ -3899,6 +4148,10 @@ msgid "" "your user's default repositories, you should instruct them in your project's " "description to configure their installer appropriately. For example with pip:" msgstr "" +"Em ambos os casos, como você hospedará um repositório que provavelmente não " +"está nos repositórios padrão do usuário, você deve instruí-los na descrição " +"do seu projeto para configurar o instalador apropriadamente. Por exemplo, " +"com pip:" #: ../source/guides/hosting-your-own-index.rst:29 msgid "" @@ -3906,10 +4159,13 @@ msgid "" "with valid HTTPS. At this time, the security of your user's installations " "depends on all repositories using a valid HTTPS setup." msgstr "" +"Além disso, é **altamente** recomendado que você sirva seu repositório com " +"HTTPS válido. Neste momento, a segurança das instalações do seu usuário " +"depende de todos os repositórios usando uma configuração válida do HTTPS." #: ../source/guides/hosting-your-own-index.rst:35 msgid "\"Manual\" repository" -msgstr "" +msgstr "Repositório \"manual\"" #: ../source/guides/hosting-your-own-index.rst:37 msgid "" @@ -3920,6 +4176,12 @@ msgid "" "projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the " "version 0.1) You should end up with a structure that looks like::" msgstr "" +"O layout do diretório é bastante simples, dentro de um diretório raiz você " +"precisa criar um diretório para cada projeto. Este diretório deve ser o nome " +"normalizado (conforme definido por :pep:`503`) do projeto. Em cada um desses " +"diretórios, basta colocar cada um dos arquivos para download. Se você tem os " +"projetos \"Foo\" (com as versões 1.0 e 2.0) e \"bar\" (com a versão 0.1), " +"você deve acabar com uma estrutura parecida com::" #: ../source/guides/hosting-your-own-index.rst:51 msgid "" @@ -3928,23 +4190,30 @@ msgid "" "server in `Twisted`_, you would simply run ``twistd -n web --path .`` and " "then instruct users to add the URL to their installer's configuration." msgstr "" +"Assim que tiver esse layout, basta configurar seu servidor web para servir o " +"diretório raiz com o autoindex habilitado. Para um exemplo usando o servidor " +"Web embutido em `Twisted`_, você simplesmente executaria ``twistd -n web --" +"path .`` e então instruiria os usuários a adicionar a URL à configuração de " +"seu instalador." #: ../source/guides/hosting-your-own-index.rst:58 msgid "" "For complete documentation of the simple repository protocol, see :pep:`503`." msgstr "" +"Para a documentação completa do protocolo de repositório simples, veja :pep:" +"`503`." #: ../source/guides/index.rst:8 msgid "Installing Packages:" -msgstr "" +msgstr "Instalando pacotes:" #: ../source/guides/index.rst:20 msgid "Building and Publishing Projects:" -msgstr "" +msgstr "Construindo e publicando projetos:" #: ../source/guides/index.rst:38 msgid "Miscellaneous:" -msgstr "" +msgstr "Diversos:" #: ../source/guides/index.rst:4 msgid "" @@ -3952,15 +4221,19 @@ msgid "" "are already familiar with the basics of Python packaging. If you're looking " "for an introduction to packaging, see :doc:`/tutorials/index`." msgstr "" +"**Guias** se concentram em realizar uma tarefa específica e presumem que " +"você já esteja familiarizado com os fundamentos do empacotamento do Python. " +"Se você está procurando uma introdução ao empacotamento, veja :doc:`/" +"tutorials/index`." #: ../source/guides/index-mirrors-and-caches.rst:5 msgid "Package index mirrors and caches" -msgstr "" +msgstr "Espelhos e caches de índice de pacotes" #: ../source/guides/index-mirrors-and-caches.rst:8 #: ../source/guides/supporting-multiple-python-versions.rst:8 msgid "2014-12-24" -msgstr "" +msgstr "2014-12-24" #: ../source/guides/index-mirrors-and-caches.rst:14 msgid "" @@ -3968,36 +4241,45 @@ msgid "" "installation, allow offline work, handle corporate firewalls or just plain " "Internet flakiness." msgstr "" +"O espelhamento ou cache do PyPI pode ser usado para acelerar a instalação do " +"pacote local, permitir o trabalho offline, lidar com firewalls corporativos " +"ou simplesmente falhas na Internet." #: ../source/guides/index-mirrors-and-caches.rst:17 msgid "Three options are available in this area:" -msgstr "" +msgstr "Três opções estão disponíveis nesta área:" #: ../source/guides/index-mirrors-and-caches.rst:19 msgid "pip provides local caching options," -msgstr "" +msgstr "pip fornece opções de cache local," #: ../source/guides/index-mirrors-and-caches.rst:20 msgid "" "devpi provides higher-level caching option, potentially shared amongst many " "users or machines, and" msgstr "" +"devpi fornece uma opção de cache de alto nível, potencialmente compartilhada " +"entre vários usuários ou várias máquinas, e" #: ../source/guides/index-mirrors-and-caches.rst:22 msgid "" "bandersnatch provides a local complete mirror of all PyPI :term:`packages " "`." msgstr "" +"bandersnatch fornece um espelho local completo de todos os :term:`pacotes " +"` do PyPI." #: ../source/guides/index-mirrors-and-caches.rst:27 msgid "Caching with pip" -msgstr "" +msgstr "Fazendo cache com pip" #: ../source/guides/index-mirrors-and-caches.rst:29 msgid "" "pip provides a number of facilities for speeding up installation by using " "local cached copies of :term:`packages `:" msgstr "" +"pip fornece uma série de facilidades para acelerar a instalação usando " +"cópias locais em cache de :term:`pacotes `:" #: ../source/guides/index-mirrors-and-caches.rst:32 msgid "" @@ -4005,6 +4287,9 @@ msgid "" "from-local-packages>`_ by downloading all the requirements for a project and " "then pointing pip at those downloaded files instead of going to PyPI." msgstr "" +"`Instalações rápidas e locais `_ baixando todos os requisitos para um " +"projeto e apontando pip para esses arquivos baixados em vez de ir para PyPI." #: ../source/guides/index-mirrors-and-caches.rst:36 msgid "" @@ -4012,10 +4297,13 @@ msgid "" "requirements using `python -m pip wheel `_::" msgstr "" +"Uma variação acima, que pré-constrói os arquivos de instalação para os " +"requisitos usando `python -m pip wheel `_::" #: ../source/guides/index-mirrors-and-caches.rst:45 msgid "Caching with devpi" -msgstr "" +msgstr "Fazendo cache com devpi" #: ../source/guides/index-mirrors-and-caches.rst:47 msgid "" @@ -4023,10 +4311,13 @@ msgid "" "machine you know will always be available to you. See the `devpi " "documentation for getting started`__." msgstr "" +"devpi é um servidor proxy de cache que você executa em seu laptop ou alguma " +"outra máquina que você sabe que sempre estará disponível para você. Veja a " +"`documentação do devpi para começar`__." #: ../source/guides/index-mirrors-and-caches.rst:55 msgid "Complete mirror with bandersnatch" -msgstr "" +msgstr "Espelho completo com bandersnatch" #: ../source/guides/index-mirrors-and-caches.rst:57 msgid "" @@ -4034,6 +4325,9 @@ msgid "" "` (externally-hosted packages are not mirrored). See " "the `bandersnatch documentation for getting that going`__." msgstr "" +"bandersnatch irá configurar um espelho local completo de todos os :term:" +"`pacotes ` do PyPI (pacotes hospedados externamente " +"não são espelhados). Veja a `documentação do bandersnatch para fazer isso`__." #: ../source/guides/index-mirrors-and-caches.rst:63 msgid "" @@ -4042,10 +4336,14 @@ msgid "" "bandersnatch which will only cache :term:`packages ` " "hosted on PyPI." msgstr "" +"Um benefício do devpi é que ele criará um espelho que inclui :term:`pacotes " +"` que são externos ao PyPI, ao contrário do " +"bandersnatch que armazenará apenas em cache os :term:`pacotes ` hospedados no PyPI." #: ../source/guides/installing-scientific-packages.rst:5 msgid "Installing scientific packages" -msgstr "" +msgstr "Instalando pacotes científicos" #: ../source/guides/installing-scientific-packages.rst:11 msgid "" @@ -4054,6 +4352,10 @@ msgid "" "kinds of hardware, or to interoperate with different pieces of external " "software." msgstr "" +"O software científico tende a ter dependências mais complexas do que a " +"maioria e, frequentemente, terá várias opções de construção para tirar " +"proveito de diferentes tipos de hardware ou para interoperar com diferentes " +"partes de software externo." #: ../source/guides/installing-scientific-packages.rst:16 msgid "" @@ -4063,6 +4365,11 @@ msgid "" "different FORTRAN libraries, and can take advantage of different levels of " "vectorised instructions available in modern CPUs." msgstr "" +"Em particular, `NumPy `__, que fornece a base para a " +"maioria do software na `pilha científica Python `__ pode ser configurado para interoperar com " +"diferentes bibliotecas FORTRAN e pode tirar proveito de diferentes níveis de " +"instruções vetorizadas disponíveis em CPUs modernas." #: ../source/guides/installing-scientific-packages.rst:22 msgid "" @@ -4073,6 +4380,13 @@ msgid "" "netlib.org/atlas/>`__ BLAS/LAPACK library, restricted to SSE2 instructions, " "so they may not provide optimal linear algebra performance." msgstr "" +"A partir da versão 1.10.4 do NumPy e da versão 1.0.0 do SciPy, binários pré-" +"construídos de 32 e 64 bits no formato ``wheel`` estão disponíveis para " +"todos os principais sistemas operacionais (Windows, macOS e Linux) em PyPI. " +"Observe, no entanto, que no Windows, os binários do NumPy são vinculados à " +"biblioteca BLAS/LAPACK do `ATLAS `__, restrita " +"às instruções SSE2, portanto, podem não fornecer desempenho da álgebra " +"linear." #: ../source/guides/installing-scientific-packages.rst:29 msgid "" @@ -4081,10 +4395,14 @@ msgid "" "environment to install from source and don't provide pre-built wheel files " "on PyPI)." msgstr "" +"Existem várias opções alternativas para obter bibliotecas científicas Python " +"(ou quaisquer outras bibliotecas Python que requerem um ambiente de " +"compilação para instalar a partir do código-fonte e não fornecem arquivos de " +"wheel pré-construídos no PyPI)." #: ../source/guides/installing-scientific-packages.rst:35 msgid "Building from source" -msgstr "" +msgstr "Construindo a partir do código-fonte" #: ../source/guides/installing-scientific-packages.rst:37 msgid "" @@ -4094,10 +4412,15 @@ msgid "" "to spend the time wrangling compilers and linkers for both C and FORTRAN, " "building from source is always an option." msgstr "" +"A mesma complexidade que torna difícil distribuir o NumPy (e muitos dos " +"projetos que dependem dele) como arquivos wheel também torna difícil " +"construí-los a partir do código-fonte. No entanto, para pessoas intrépidas " +"que estão dispostas a gastar o tempo discutindo compiladores e vinculadores " +"para C e FORTRAN, construir a partir do código-fonte é sempre uma opção." #: ../source/guides/installing-scientific-packages.rst:45 msgid "Linux distribution packages" -msgstr "" +msgstr "Pacotes de distribuição Linux" #: ../source/guides/installing-scientific-packages.rst:47 msgid "" @@ -4105,6 +4428,9 @@ msgid "" "versions of various pieces of scientific software, including NumPy and other " "parts of the scientific Python stack." msgstr "" +"Para usuários Linux, o gerenciador de pacotes do sistema frequentemente terá " +"versões pré-compiladas de várias peças de software científico, incluindo " +"NumPy e outras partes da pilha científica Python." #: ../source/guides/installing-scientific-packages.rst:51 msgid "" @@ -4113,10 +4439,13 @@ msgid "" "distributions installed into the system Python when using virtual " "environments)." msgstr "" +"Se usar versões que podem ter vários meses é aceitável, então esta é " +"provavelmente uma boa opção (apenas certifique-se de permitir o acesso às " +"distribuições instaladas no sistema Python ao usar ambientes virtuais)." #: ../source/guides/installing-scientific-packages.rst:57 msgid "Windows installers" -msgstr "" +msgstr "Instaladores para Windows" #: ../source/guides/installing-scientific-packages.rst:59 msgid "" @@ -4125,12 +4454,19 @@ msgid "" "download page. Using these installers allows users to avoid the need to set " "up a suitable environment to build extensions locally." msgstr "" +"Muitos projetos Python que não publicam (ou não podem) atualmente publicar " +"arquivos wheel, pelo menos publicam instaladores Windows, seja no PyPI ou na " +"página de download de seus projetos. O uso desses instaladores permite que " +"os usuários evitem a necessidade de configurar um ambiente adequado para " +"construir extensões localmente." #: ../source/guides/installing-scientific-packages.rst:64 msgid "" "The extensions provided in these installers are typically compatible with " "the CPython Windows installers published on python.org." msgstr "" +"As extensões fornecidas nesses instaladores são normalmente compatíveis com " +"os instaladores do CPython para o Windows publicados em python.org." #: ../source/guides/installing-scientific-packages.rst:67 msgid "" @@ -4140,6 +4476,11 @@ msgid "" ">`__. Many Python users on Windows have reported a positive experience with " "these prebuilt versions." msgstr "" +"Para projetos que não fornecem seus próprios instaladores para Windows (e " +"até mesmo alguns que oferecem), Christoph Gohlke da Universidade da " +"Califórnia fornece uma `coleção de instaladores para Windows `__. Muitos usuários do Python no Windows " +"relataram uma experiência positiva com essas versões pré-construídas." #: ../source/guides/installing-scientific-packages.rst:73 msgid "" @@ -4149,6 +4490,11 @@ msgid "" "Python when using virtual environments is a common approach to working " "around this limitation." msgstr "" +"Tal como acontece com os pacotes de sistema Linux, os instaladores Windows " +"irão apenas instalar em uma instalação de sistema Python -- eles não têm " +"suporte à instalação em ambientes virtuais. Permitir o acesso a " +"distribuições instaladas no sistema Python ao usar ambientes virtuais é uma " +"abordagem comum para contornar essa limitação." #: ../source/guides/installing-scientific-packages.rst:79 msgid "" @@ -4156,10 +4502,13 @@ msgid "" "subcommand that can convert a Windows :command:`bdist_wininst` installer to " "a wheel." msgstr "" +"O projeto :term:`Wheel` também fornece um subcomando :command:`wheel " +"convert` que pode converter um instalador para Windows :command:" +"`bdist_wininst` em um wheel." #: ../source/guides/installing-scientific-packages.rst:86 msgid "macOS installers and package managers" -msgstr "" +msgstr "Instaladores e gerenciadores de pacote para macOS" #: ../source/guides/installing-scientific-packages.rst:88 msgid "" @@ -4167,6 +4516,9 @@ msgid "" "macOS installers that are compatible with the macOS CPython binaries " "published on python.org." msgstr "" +"Semelhante à situação no Windows, muitos projetos (incluindo NumPy) publicam " +"instaladores para macOS que são compatíveis com os binários do CPython para " +"macOS publicados em python.org." #: ../source/guides/installing-scientific-packages.rst:92 msgid "" @@ -4175,10 +4527,14 @@ msgid "" "install the `scientific Python stack `__" msgstr "" +"Os usuários do macOS também têm acesso aos gerenciadores de pacotes de " +"estilo de distribuição Linux, como ``MacPorts``. O site SciPy tem mais " +"detalhes sobre como usar MacPorts para instalar a `pilha científica Python " +"`__" #: ../source/guides/installing-scientific-packages.rst:99 msgid "SciPy distributions" -msgstr "" +msgstr "Distribuições SciPy" #: ../source/guides/installing-scientific-packages.rst:101 msgid "" @@ -4186,17 +4542,22 @@ msgid "" "html>`__ that provide the full SciPy stack to end users in an easy to use " "and update format." msgstr "" +"O site SciPy lista `várias distribuições `__ que fornecem a pilha SciPy completa para usuários finais em um " +"formato fácil de usar e atualizar." #: ../source/guides/installing-scientific-packages.rst:105 msgid "" "Some of these distributions may not be compatible with the standard ``pip`` " "and ``virtualenv`` based toolchain." msgstr "" +"Algumas dessas distribuições podem não ser compatíveis com o conjunto de " +"ferramentas padrão ``pip`` e ``virtualenv``." #: ../source/guides/installing-scientific-packages.rst:109 #: ../source/key_projects.rst:596 msgid "Spack" -msgstr "" +msgstr "Spack" #: ../source/guides/installing-scientific-packages.rst:110 msgid "" @@ -4209,6 +4570,16 @@ msgid "" "destructive; installing a new version of one package does not break existing " "installations, so many configurations can coexist on the same system." msgstr "" +"`Spack `_ é um gerenciador de pacotes " +"flexível projetado para oferecer suporte a múltiplas versões, configurações, " +"plataformas e compiladores. Ele foi construído para dar suporte às " +"necessidades de grandes centros de supercomputação e equipes de aplicações " +"científicas, que frequentemente precisam criar software de muitas maneiras " +"diferentes. O Spack não está limitado a Python; ele pode instalar pacotes " +"para ``C``, ``C++``, ``Fortran``, ``R`` e outras linguagens. É não " +"destrutivo; instalar uma nova versão de um pacote não interrompe as " +"instalações existentes, portanto, muitas configurações podem coexistir no " +"mesmo sistema." #: ../source/guides/installing-scientific-packages.rst:119 msgid "" @@ -4219,10 +4590,17 @@ msgid "" "single package file. Spack also generates *module* files so that packages " "can be loaded and unloaded from the user's environment." msgstr "" +"O Spack oferece uma sintaxe simples, mas poderosa, que permite aos usuários " +"especificar versões e opções de configuração de forma concisa. Os arquivos " +"de pacote são escritos em puro Python e são modelados para que seja fácil " +"trocar compiladores, implementações de dependência (como MPI), versões e " +"opções de construção com um único arquivo de pacote. O Spack também gera " +"arquivos de *módulo* para que os pacotes possam ser carregados e " +"descarregados do ambiente do usuário." #: ../source/guides/installing-scientific-packages.rst:128 msgid "The conda cross-platform package manager" -msgstr "" +msgstr "O gerenciador de pacotes multiplataforma conda" #: ../source/guides/installing-scientific-packages.rst:130 msgid "" @@ -4232,6 +4610,11 @@ msgid "" "Anaconda, about 200 packages are installed by default, and a total of " "400-500 can be installed and updated from the Anaconda repository." msgstr "" +"`Anaconda `_ é uma distribuição Python " +"publicada pela Anaconda, Inc. É uma coleção estável de pacotes de código " +"aberto para *big data* e uso científico. A partir da versão 5.0 do Anaconda, " +"cerca de 200 pacotes são instalados por padrão, e um total de 400-500 podem " +"ser instalados e atualizados a partir do repositório Anaconda." #: ../source/guides/installing-scientific-packages.rst:136 msgid "" @@ -4249,10 +4632,24 @@ msgid "" "packages. Conda is available in Anaconda and Miniconda (an easy-to-install " "download with just Python and conda)." msgstr "" +"``conda`` é um sistema de gerenciamento de pacotes e de gerenciamento de " +"ambiente de código aberto (licenciado por BSD) incluído no Anaconda que " +"permite aos usuários instalar várias versões de pacotes de software binários " +"e suas dependências, e alternar facilmente entre eles. É uma ferramenta " +"multiplataforma que funciona no Windows, no macOS e no Linux. O Conda pode " +"ser usado para empacotar e distribuir todos os tipos de pacotes, não está " +"limitado apenas a pacotes Python. Possui suporte total para ambientes " +"virtuais nativos. Conda torna os ambientes cidadãos de primeira classe, " +"facilitando a criação de ambientes independentes até mesmo para bibliotecas " +"C. Está escrito em Python, mas é agnóstico ao Python. O Conda gerencia o " +"próprio Python como um pacote, de forma que :command:`conda update python` " +"seja possível, em contraste com o pip, que gerencia apenas os pacotes " +"Python. O Conda está disponível no Anaconda e no Miniconda (um download " +"fácil de instalar com apenas Python e conda)." #: ../source/guides/installing-stand-alone-command-line-tools.rst:2 msgid "Installing stand alone command line tools" -msgstr "" +msgstr "Instalando ferramentas de linha de comando autônomas" #: ../source/guides/installing-stand-alone-command-line-tools.rst:4 msgid "" @@ -4261,6 +4658,10 @@ msgid "" "github.com/PyCQA/flake8>`_, :ref:`pipenv`,and `black `_." msgstr "" +"Muitos pacotes têm pontos de entrada de linha de comando. Exemplos deste " +"tipo de aplicação são `mypy `_, `flake8 " +"`_, :ref:`pipenv`e `black `_." #: ../source/guides/installing-stand-alone-command-line-tools.rst:10 msgid "" @@ -4269,6 +4670,9 @@ msgid "" "version conflicts and break dependencies the operating system has on Python " "packages." msgstr "" +"Normalmente você deseja acessá-los de qualquer lugar, mas instalar pacotes e " +"suas dependências no mesmo ambiente global pode causar conflitos de versão e " +"quebrar as dependências que o sistema operacional tem nos pacotes Python." #: ../source/guides/installing-stand-alone-command-line-tools.rst:15 msgid "" @@ -4278,74 +4682,91 @@ msgid "" "or uninstalled without causing conflicts with other packages, and allows you " "to safely run the program from anywhere." msgstr "" +":ref:`pipx` resolve isso criando um ambiente virtual para cada pacote, " +"enquanto também garante que as aplicações do pacote sejam acessíveis através " +"de um diretório que está em seu ``$PATH``. Isso permite que cada pacote seja " +"atualizado ou desinstalado sem causar conflitos com outros pacotes e permite " +"que você execute o programa com segurança de qualquer lugar." #: ../source/guides/installing-stand-alone-command-line-tools.rst:21 msgid "pipx only works with Python 3.6+." -msgstr "" +msgstr "pipx só funciona com Python 3.6+." #: ../source/guides/installing-stand-alone-command-line-tools.rst:23 msgid "``pipx`` is installed with ``pip``:" -msgstr "" +msgstr "``pipx`` é instalado com ``pip``:" #: ../source/guides/installing-stand-alone-command-line-tools.rst:30 msgid "" "You may need to restart your terminal for the path updates to take effect." msgstr "" +"Você pode precisar reiniciar seu terminal para que as atualizações de " +"caminho tenham efeito." #: ../source/guides/installing-stand-alone-command-line-tools.rst:32 msgid "" "Now you can install packages with ``pipx install`` and access the package's " "entry point(s) from anywhere." msgstr "" +"Agora você pode instalar pacotes com ``pipx install`` e acessar os pontos de " +"entrada do pacote de qualquer lugar." #: ../source/guides/installing-stand-alone-command-line-tools.rst:39 #: ../source/guides/installing-stand-alone-command-line-tools.rst:100 msgid "For example" -msgstr "" +msgstr "Por exemplo" #: ../source/guides/installing-stand-alone-command-line-tools.rst:59 msgid "" "To see a list of packages installed with pipx and which CLI applications are " "available, use ``pipx list``." msgstr "" +"Para ver uma lista de pacotes instalados com pipx e quais aplicações de " +"linha de comando estão disponíveis, use ``pipx list``." #: ../source/guides/installing-stand-alone-command-line-tools.rst:79 msgid "To upgrade or uninstall the package" -msgstr "" +msgstr "Para atualizar ou desinstalar o pacote" #: ../source/guides/installing-stand-alone-command-line-tools.rst:86 msgid "``pipx`` can be upgraded or uninstalled with pip" -msgstr "" +msgstr "``pipx`` pode ser atualizado ou desinstalado com pip" #: ../source/guides/installing-stand-alone-command-line-tools.rst:93 msgid "" "``pipx`` also allows you to install and run the latest version of a cli tool " "in a temporary, ephemeral environment." msgstr "" +"`` pipx`` também permite que você instale e execute a versão mais recente de " +"uma ferramenta cli em um ambiente temporário e efêmero." #: ../source/guides/installing-stand-alone-command-line-tools.rst:106 msgid "To see the full list of commands ``pipx`` offers, run" -msgstr "" +msgstr "Para ver a lista completa de comandos ``pipx`` oferece, execute" #: ../source/guides/installing-stand-alone-command-line-tools.rst:112 msgid "" "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/" "pipx." msgstr "" +"Você pode aprender mais sobre ``pipx`` em sua página inicial, https://github." +"com/pypa/pipx." #: ../source/guides/installing-using-linux-tools.rst:5 msgid "Installing pip/setuptools/wheel with Linux Package Managers" -msgstr "" +msgstr "Instalando pip/setuptools/wheel com gerenciadores de pacotes do Linux" #: ../source/guides/installing-using-linux-tools.rst:8 msgid "2015-09-17" -msgstr "" +msgstr "2015-09-17" #: ../source/guides/installing-using-linux-tools.rst:11 msgid "" "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:" "`wheel` using Linux package managers." msgstr "" +"Esta seção cobre como instalar :ref:`pip`, :ref:`setuptools` e :ref:`wheel` " +"usando gerenciadores de pacotes do Linux." #: ../source/guides/installing-using-linux-tools.rst:14 msgid "" @@ -4353,6 +4774,9 @@ msgid "" "python.org>`_, then this section does not apply. See the :ref:" "`installing_requirements` section instead." msgstr "" +"Se você estiver usando um Python que foi baixado de `python.org `_, então esta seção não se aplica. Veja a seção :ref:" +"`installing_requirements`." #: ../source/guides/installing-using-linux-tools.rst:18 msgid "" @@ -4363,6 +4787,13 @@ msgid "" "there are additional repositories that can be enabled to provide newer " "versions. The repositories we know about are explained below." msgstr "" +"Observe que é comum que as versões de :ref:`pip`, :ref:`setuptools` e :ref:" +"`wheel` suportadas por uma distribuição Linux específica estejam " +"desatualizadas no momento em que é lançado para o público, e as atualizações " +"geralmente ocorrem apenas por motivos de segurança, não para atualizações de " +"recursos. Para certas distribuições, existem repositórios adicionais que " +"podem ser ativados para fornecer versões mais recentes. Os repositórios que " +"conhecemos são explicados abaixo." #: ../source/guides/installing-using-linux-tools.rst:25 msgid "" @@ -4372,14 +4803,19 @@ msgid "" "original unpatched versions. When this is known, we will make note of it " "below." msgstr "" +"Observe também que é um tanto comum que as Distribuições apliquem patches " +"para fins de segurança e normalização de acordo com seus próprios padrões. " +"Em alguns casos, isso pode levar a bugs ou comportamentos inesperados que " +"variam em relação às versões originais sem patch. Quando isso for conhecido, " +"faremos anotações sobre isso a seguir." #: ../source/guides/installing-using-linux-tools.rst:32 msgid "Fedora" -msgstr "" +msgstr "Fedora" #: ../source/guides/installing-using-linux-tools.rst:34 msgid "Fedora 21:" -msgstr "" +msgstr "Fedora 21:" #: ../source/guides/installing-using-linux-tools.rst:36 #: ../source/guides/installing-using-linux-tools.rst:45 @@ -4387,19 +4823,19 @@ msgstr "" #: ../source/guides/installing-using-linux-tools.rst:138 #: ../source/guides/installing-using-linux-tools.rst:158 msgid "Python 2::" -msgstr "" +msgstr "Python 2::" #: ../source/guides/installing-using-linux-tools.rst:41 msgid "Python 3: ``sudo yum install python3 python3-wheel``" -msgstr "" +msgstr "Python 3: ``sudo yum install python3 python3-wheel``" #: ../source/guides/installing-using-linux-tools.rst:43 msgid "Fedora 22:" -msgstr "" +msgstr "Fedora 22:" #: ../source/guides/installing-using-linux-tools.rst:50 msgid "Python 3: ``sudo dnf install python3 python3-wheel``" -msgstr "" +msgstr "Python 3: ``sudo dnf install python3 python3-wheel``" #: ../source/guides/installing-using-linux-tools.rst:53 msgid "" @@ -4408,20 +4844,26 @@ msgid "" ">`_ using the `Copr Repo instructions `__, and then run::" msgstr "" +"Para obter versões mais novas do pip, setuptools e wheel para Python 2, você " +"pode habilitar o `PyPA Copr Repo `_ usando as `instruções do Copr Repo `__ e então executar::" #: ../source/guides/installing-using-linux-tools.rst:63 msgid "CentOS/RHEL" -msgstr "" +msgstr "CentOS/RHEL" #: ../source/guides/installing-using-linux-tools.rst:65 msgid "" "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core " "repositories, although :ref:`setuptools` is installed by default." msgstr "" +"CentOS e RHEL não oferecem :ref:`pip` ou :ref:`wheel` em seus repositórios " +"principais, embora :ref:`setuptools` seja instalado por padrão." #: ../source/guides/installing-using-linux-tools.rst:68 msgid "To install pip and wheel for the system Python, there are two options:" -msgstr "" +msgstr "Para instalar pip e wheel para o sistema Python, existem duas opções:" #: ../source/guides/installing-using-linux-tools.rst:70 msgid "" @@ -4430,16 +4872,22 @@ msgid "" "EPEL#How_can_I_use_these_extra_packages.3F>`__. On EPEL 6 and EPEL7, you can " "install pip like so::" msgstr "" +"Habilite o `repositório EPEL `_ usando " +"`estas instruções `__. Em EPEL 6 e EPEL 7, você " +"pode instalar pip assim::" #: ../source/guides/installing-using-linux-tools.rst:77 msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" -msgstr "" +msgstr "No EPEL 7 (mas não no EPEL 6), você pode instalar wheel desta forma::" #: ../source/guides/installing-using-linux-tools.rst:81 msgid "" "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer " "setuptools, since it's in the core repository." msgstr "" +"Como a EPEL oferece apenas pacotes extras não conflitantes, a EPEL não " +"oferece setuptools, pois está no repositório central." #: ../source/guides/installing-using-linux-tools.rst:85 msgid "" @@ -4447,36 +4895,46 @@ msgid "" ">`_ using `these instructions `__ [1]_. You can install pip and wheel like so::" msgstr "" +"Habilite o `Copr Repo do PyPA `_ usando `estas instruções `__ [1]_. Você pode instalar pip e wheel desta forma::" #: ../source/guides/installing-using-linux-tools.rst:92 msgid "To additionally upgrade setuptools, run::" -msgstr "" +msgstr "Para adicionalmente atualizar setuptools, execute::" #: ../source/guides/installing-using-linux-tools.rst:97 msgid "" "To install pip, wheel, and setuptools, in a parallel, non-system environment " "(using yum) then there are two options:" msgstr "" +"Para instalar pip, wheel e setuptools, em um ambiente paralelo, sem sistema " +"(usando yum), existem duas opções:" #: ../source/guides/installing-using-linux-tools.rst:101 msgid "" "Use the \"Software Collections\" feature to enable a parallel collection " "that includes pip, setuptools, and wheel." msgstr "" +"Use o recurso \"Coleções de software\" para habilitar uma coleção paralela " +"que inclui pip, setuptools e wheel." #: ../source/guides/installing-using-linux-tools.rst:104 msgid "" "For Redhat, see here: http://developers.redhat.com/products/" "softwarecollections/overview/" msgstr "" +"Para Redhat, veja aqui: http://developers.redhat.com/products/" +"softwarecollections/overview/" #: ../source/guides/installing-using-linux-tools.rst:106 msgid "For CentOS, see here: https://www.softwarecollections.org/en/" -msgstr "" +msgstr "Para CentOS, veja aqui: https://www.softwarecollections.org/en/" #: ../source/guides/installing-using-linux-tools.rst:108 msgid "Be aware that collections may not contain the most recent versions." msgstr "" +"Esteja ciente de que as coleções podem não conter as versões mais recentes." #: ../source/guides/installing-using-linux-tools.rst:110 msgid "" @@ -4485,24 +4943,28 @@ msgid "" "installable-package>`_ Pythons, along with pip, setuptools, and wheel, which " "are kept fairly up to date." msgstr "" +"Habilite o `repositório do IUS `_ e instale " +"um dos Pythons `pré-instaláveis `_, junto com pip, setuptools e wheel, que são mantidos " +"razoavelmente atualizados." #: ../source/guides/installing-using-linux-tools.rst:116 msgid "For example, for Python 3.4 on CentOS7/RHEL7::" -msgstr "" +msgstr "Por exemplo, para Python 3.4 no CentOS7/RHEL7::" #: ../source/guides/installing-using-linux-tools.rst:122 msgid "openSUSE" -msgstr "" +msgstr "openSUSE" #: ../source/guides/installing-using-linux-tools.rst:129 #: ../source/guides/installing-using-linux-tools.rst:143 #: ../source/guides/installing-using-linux-tools.rst:162 msgid "Python 3::" -msgstr "" +msgstr "Python 3::" #: ../source/guides/installing-using-linux-tools.rst:135 msgid "Debian/Ubuntu" -msgstr "" +msgstr "Debian/Ubuntu" #: ../source/guides/installing-using-linux-tools.rst:150 msgid "" @@ -4510,20 +4972,27 @@ msgid "" "`_ by default, " "which is a significant behavior change that can be surprising to some users." msgstr "" +"Versões recentes do Debian/Ubuntu modificaram o pip para usar o `\"User " +"Scheme\" `_ " +"(Esquema de usuário) por padrão, que é um mudança significativa de " +"comportamento que pode surpreender alguns usuários." #: ../source/guides/installing-using-linux-tools.rst:156 msgid "Arch Linux" -msgstr "" +msgstr "Arch Linux" #: ../source/guides/installing-using-linux-tools.rst:168 msgid "" "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the " "only option is to manually place the repo files as described." msgstr "" +"Atualmente, não há plug-in do yum para \"copr\" disponível para CentOS/RHEL, " +"então a única opção é colocar manualmente os arquivos de repositório " +"conforme descrito." #: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 msgid "Installing packages using pip and virtual environments" -msgstr "" +msgstr "Instalando pacotes usando pip e ambientes virtuais" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 msgid "" @@ -4532,6 +5001,11 @@ msgid "" "for Python 2. These are the lowest-level tools for managing Python packages " "and are recommended if higher-level tools do not suit your needs." msgstr "" +"Este guia discute como instalar pacotes usando :ref:`pip` e um gerenciador " +"de ambiente virtual: ou :ref:`venv` para Python 3 ou :ref:`virtualenv` para " +"Python 2 Estas são as ferramentas de nível mais baixo para gerenciar pacotes " +"Python e são recomendadas se as ferramentas de nível mais alto não atenderem " +"às suas necessidades." #: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 msgid "" @@ -4539,10 +5013,13 @@ msgid "" "Package` which is different from an :term:`Import Package` that which is " "used to import modules in your Python source code." msgstr "" +"Este documento usa o termo **pacote** para se referir a um :term:`Pacote de " +"Distribuição` que é diferente de um :term:`Pacote de Importação` que é usado " +"para importar módulos em seu código-fonte do Python." #: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 msgid "Installing pip" -msgstr "" +msgstr "Instalando pip" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 msgid "" @@ -4550,6 +5027,9 @@ msgid "" "update packages. You'll need to make sure you have the latest version of pip " "installed." msgstr "" +":ref:`pip` é o gerenciador de pacotes de referência Python. É usado para " +"instalar e atualizar pacotes. Você precisará certificar-se de que possui a " +"versão mais recente do pip instalada." #: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 msgid "" @@ -4557,6 +5037,9 @@ msgid "" "want to use the Linux distribution-provided versions of pip see :doc:`/" "guides/installing-using-linux-tools`." msgstr "" +"O Debian e a maioria das outras distribuições incluem um pacote `python-" +"pip`_, se você deseja usar as versões fornecidas pela distribuição Linux do " +"pip, consulte :doc:`/guides/installation-using-linux-tools`." #: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 msgid "" @@ -4564,24 +5047,31 @@ msgid "" "It's recommended to use the system pip to bootstrap a user installation of " "pip:" msgstr "" +"Você também pode instalar o pip por conta própria para garantir que possui a " +"versão mais recente. É recomendado usar o sistema pip para inicializar uma " +"instalação de usuário do pip:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 msgid "Afterwards, you should have the newest pip installed in your user site:" msgstr "" +"Depois disso, você deve ter o pip mais recente instalado em seu site de " +"usuário:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 msgid "" "The Python installers for Windows include pip. You should be able to access " "pip using:" msgstr "" +"Os instaladores do Python para Windows incluem pip. Você deve ser capaz de " +"acessar o pip usando:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 msgid "You can make sure that pip is up-to-date by running:" -msgstr "" +msgstr "Você pode ter certeza de que o pip está atualizado executando:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 msgid "Installing virtualenv" -msgstr "" +msgstr "Instalando virtualenv" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 msgid "" @@ -4590,6 +5080,10 @@ msgid "" "the Python standard library and requires no additional installation. If you " "are using venv, you may skip this section." msgstr "" +"Se você estiver usando o Python 3.3 ou mais recente, o módulo :mod:`venv` é " +"a forma preferida de criar e gerenciar ambientes virtuais. venv está " +"incluído na biblioteca padrão Python e não requer instalação adicional. Se " +"você estiver usando venv, pode pular esta seção." #: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 msgid "" @@ -4598,10 +5092,14 @@ msgid "" "which could break system tools or other projects. You can install virtualenv " "using pip." msgstr "" +":ref:`virtualenv` é usado para gerenciar pacotes Python para diferentes " +"projetos. O uso do virtualenv permite que você evite instalar pacotes Python " +"globalmente, o que poderia quebrar as ferramentas do sistema ou outros " +"projetos. Você pode instalar virtualenv usando pip." #: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 msgid "Creating a virtual environment" -msgstr "" +msgstr "Criando um ambiente virtual" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 msgid "" @@ -4614,6 +5112,13 @@ msgid "" "always recommended to use a virtual environment while developing Python " "applications." msgstr "" +":ref:`venv` (para Python 3) e :ref:`virtualenv` (para Python 2) permitem que " +"você gerencie instalações de pacotes separadas para projetos diferentes. " +"Eles essencialmente permitem que você crie uma instalação \"virtual\" " +"isolada do Python e instale pacotes nessa instalação virtual. Ao trocar de " +"projeto, você pode simplesmente criar um novo ambiente virtual e não precisa " +"se preocupar em quebrar os pacotes instalados nos outros ambientes. É sempre " +"recomendável usar um ambiente virtual ao desenvolver aplicações Python." #: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 msgid "" @@ -4621,26 +5126,33 @@ msgid "" "venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the " "below commands." msgstr "" +"Para criar um ambiente virtual, vá até o diretório do seu projeto e execute " +"venv. Se você estiver usando Python 2, substitua ``venv`` por ``virtualenv`` " +"nos comandos abaixo." #: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 msgid "" "The second argument is the location to create the virtual environment. " "Generally, you can just create this in your project and call it ``env``." msgstr "" +"O segundo argumento é o local para criar o ambiente virtual. Geralmente, " +"você pode apenas criar isso em seu projeto e chamá-lo de ``env``." #: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 msgid "venv will create a virtual Python installation in the ``env`` folder." -msgstr "" +msgstr "venv irá criar uma instalação virtual Python na pasta ``env``." #: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 msgid "" "You should exclude your virtual environment directory from your version " "control system using ``.gitignore`` or similar." msgstr "" +"Você deve excluir seu diretório de ambiente virtual de seu sistema de " +"controle de versão usando ``.gitignore`` ou similar." #: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 msgid "Activating a virtual environment" -msgstr "" +msgstr "Ativando um ambiente virtual" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 msgid "" @@ -4649,12 +5161,18 @@ msgid "" "will put the virtual environment-specific ``python`` and ``pip`` executables " "into your shell's ``PATH``." msgstr "" +"Antes de começar a instalar ou usar pacotes em seu ambiente virtual, você " +"precisará *ativá-lo*. Ativar um ambiente virtual colocará os executáveis " +"``python`` e ``pip`` específicos do ambiente virtual no ``PATH`` de seu " +"shell." #: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 msgid "" "You can confirm you're in the virtual environment by checking the location " "of your Python interpreter, it should point to the ``env`` directory." msgstr "" +"Você pode confirmar que está no ambiente virtual verificando a localização " +"do seu interpretador Python, ele deve apontar para o diretório ``env``." #: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 msgid "" @@ -4662,16 +5180,21 @@ msgid "" "into that specific environment and you'll be able to import and use packages " "in your Python application." msgstr "" +"Contanto que seu ambiente virtual esteja ativado, pip instalará pacotes " +"naquele ambiente específico e você poderá importar e usar pacotes em sua " +"aplicação Python." #: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 msgid "Leaving the virtual environment" -msgstr "" +msgstr "Saindo do ambiente virtual" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 msgid "" "If you want to switch projects or otherwise leave your virtual environment, " "simply run:" msgstr "" +"Se você deseja trocar de projeto ou de outra forma deixar seu ambiente " +"virtual, basta executar:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 msgid "" @@ -4679,6 +5202,9 @@ msgid "" "instructions above about activating a virtual environment. There's no need " "to re-create the virtual environment." msgstr "" +"Se você deseja entrar novamente no ambiente virtual, basta seguir as mesmas " +"instruções acima sobre como ativar um ambiente virtual. Não há necessidade " +"de recriar o ambiente virtual." #: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 msgid "Installing packages" @@ -4689,15 +5215,18 @@ msgid "" "Now that you're in your virtual environment you can install packages. Let's " "install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" msgstr "" +"Agora que você está em seu ambiente virtual, pode instalar pacotes. Vamos " +"instalar a biblioteca `Requests`_ do :term:`Python Package Index (PyPI)`:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 msgid "" "pip should download requests and all of its dependencies and install them:" msgstr "" +"pip deve baixar solicitações e todas as suas dependências e instalá-los:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 msgid "Installing specific versions" -msgstr "" +msgstr "Instalando versões específicas" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 msgid "" @@ -4705,32 +5234,39 @@ msgid "" "`version specifiers `. For example, to install a specific " "version of ``requests``:" msgstr "" +"pip permite que você especifique qual versão de um pacote instalar usando :" +"term:`especificadores de versão `. Por exemplo, " +"para instalar uma versão específica do ``requests``:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 msgid "To install the latest ``2.x`` release of requests:" -msgstr "" +msgstr "Para instalar a versão ``2.x`` mais recente do requests:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 msgid "To install pre-release versions of packages, use the ``--pre`` flag:" msgstr "" +"Para instalar versões de pré-lançamento de pacotes, use o sinalizador ``--" +"pre``:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 msgid "Installing extras" -msgstr "" +msgstr "Instalando extras" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 msgid "" "Some packages have optional `extras`_. You can tell pip to install these by " "specifying the extra in brackets:" msgstr "" +"Alguns pacotes possuem `extras`_ opcionais. Você pode dizer ao pip para " +"instalá-los especificando o extra entre colchetes:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 msgid "Installing from source" -msgstr "" +msgstr "Instalando a partir do código-fonte" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 msgid "pip can install a package directly from source, for example:" -msgstr "" +msgstr "pip pode instalar um pacote diretamente do código-fonte, por exemplo:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 msgid "" @@ -4738,33 +5274,45 @@ msgid "" "meaning that changes to the source directory will immediately affect the " "installed package without needing to re-install:" msgstr "" +"Além disso, pip pode instalar pacotes do código-fonte no `modo de " +"desenvolvimento`_, o que significa que as mudanças no diretório de código-" +"fonte afetarão imediatamente o pacote instalado sem a necessidade de " +"reinstalar:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 msgid "Installing from version control systems" -msgstr "" +msgstr "Instalando a partir de sistemas de controle de versão" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 msgid "" "pip can install packages directly from their version control system. For " "example, you can install directly from a git repository:" msgstr "" +"pip pode instalar pacotes diretamente de seu sistema de controle de versão. " +"Por exemplo, você pode instalar diretamente de um repositório git:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 msgid "" "For more information on supported version control systems and syntax, see " "pip's documentation on :ref:`VCS Support `." msgstr "" +"Para mais informações sobre os sistemas de controle de versão suportados e " +"sintaxe, consulte a documentação do pip em :ref:`Suporte VCS `." #: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 #: ../source/tutorials/installing-packages.rst:569 msgid "Installing from local archives" -msgstr "" +msgstr "Instalando de arquivos locais" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 msgid "" "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, " "wheel, or tar file) you can install it directly with pip:" msgstr "" +"Se você tiver uma cópia local de um arquivo do :term:`Pacote de " +"Distribuição` (um arquivo zip, wheel ou tar), você pode instalá-lo " +"diretamente com pip:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 msgid "" @@ -4772,6 +5320,9 @@ msgid "" "tell pip to look for packages there and not to use the :term:`Python Package " "Index (PyPI)` at all:" msgstr "" +"Se você tiver um diretório contendo arquivos de vários pacotes, você pode " +"dizer ao pip para procurar por pacotes lá e não usar o :term:`Python Package " +"Index (PyPI)` de forma alguma:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 msgid "" @@ -4779,16 +5330,21 @@ msgid "" "connectivity or if you want to strictly control the origin of distribution " "packages." msgstr "" +"Isso é útil se você estiver instalando pacotes em um sistema com " +"conectividade limitada ou se quiser controlar estritamente a origem dos " +"pacotes de distribuição." #: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 msgid "Using other package indexes" -msgstr "" +msgstr "Usando outros índices de pacotes" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 msgid "" "If you want to download packages from a different index than the :term:" "`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" msgstr "" +"Se você quiser baixar pacotes de um índice diferente do :term:`Python " +"Package Index (PyPI)`, você pode usar o sinalizador ``--index-url``:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 msgid "" @@ -4796,21 +5352,27 @@ msgid "" "(PyPI)` and a separate index, you can use the ``--extra-index-url`` flag " "instead:" msgstr "" +"Se você deseja permitir pacotes do :term:`Python Package Index (PyPI)` e de " +"um índice separado, você pode usar a sinalização ``--extra-index-url`` em " +"seu lugar:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 #: ../source/tutorials/installing-packages.rst:389 msgid "Upgrading packages" -msgstr "" +msgstr "Atualizando pacotes" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 msgid "" "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, " "to install the latest version of ``requests`` and all of its dependencies:" msgstr "" +"pip pode atualizar pacotes no local usando o sinalizador ``--upgrade``. Por " +"exemplo, para instalar a versão mais recente de ``requests`` e todas as suas " +"dependências:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 msgid "Using requirements files" -msgstr "" +msgstr "Usando arquivos de requisitos" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 msgid "" @@ -4818,36 +5380,46 @@ msgid "" "dependencies in a :ref:`Requirements File `. For " "example you could create a :file:`requirements.txt` file containing:" msgstr "" +"Em vez de instalar pacotes individualmente, pip permite que você declare " +"todas as dependências em um :ref:`Arquivo de Requisitos `. Por exemplo, você pode criar um arquivo :file:`requirements.txt` " +"contendo:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 msgid "" "And tell pip to install all of the packages in this file using the ``-r`` " "flag:" msgstr "" +"E diga ao pip para instalar todos os pacotes neste arquivo usando o " +"sinalizador ``-r``:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 msgid "Freezing dependencies" -msgstr "" +msgstr "Congelando dependências" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 msgid "" "Pip can export a list of all installed packages and their versions using the " "``freeze`` command:" msgstr "" +"Pip pode exportar uma lista de todos os pacotes instalados e suas versões " +"usando o comando ``freeze``:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 msgid "Which will output a list of package specifiers such as:" -msgstr "" +msgstr "O que resultará em uma lista de especificadores de pacote, como:" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 msgid "" "This is useful for creating :ref:`pip:Requirements Files` that can re-create " "the exact versions of all packages installed in an environment." msgstr "" +"Isso é útil para criar :ref:`pip:Requirements Files` que podem recriar as " +"versões exatas de todos os pacotes instalados em um ambiente." #: ../source/guides/making-a-pypi-friendly-readme.rst:2 msgid "Making a PyPI-friendly README" -msgstr "" +msgstr "Criando um README amigável para PyPI" #: ../source/guides/making-a-pypi-friendly-readme.rst:4 msgid "" @@ -4856,16 +5428,22 @@ msgid "" "in a PyPI-friendly format and include your README in your package so it " "appears on PyPI." msgstr "" +"Os arquivos README podem ajudar seus usuários a entender o seu projeto e " +"podem ser usados para definir a descrição do seu projeto no PyPI. Este guia " +"ajuda a criar um README em um formato amigável ao PyPI e inclui seu README " +"em seu pacote para que apareça no PyPI." #: ../source/guides/making-a-pypi-friendly-readme.rst:9 msgid "Creating a README file" -msgstr "" +msgstr "Criando um arquivo README" #: ../source/guides/making-a-pypi-friendly-readme.rst:11 msgid "" "README files for Python projects are often named ``README``, ``README.txt``, " "``README.rst``, or ``README.md``." msgstr "" +"Arquivos README para projetos Python são frequentemente chamados de " +"``README``, ``README.txt``, ``README.rst`` ou ``README.md``." #: ../source/guides/making-a-pypi-friendly-readme.rst:13 msgid "" @@ -4873,32 +5451,41 @@ msgid "" "supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" msgstr "" +"Para que seu README seja exibido corretamente no PyPI, escolha uma linguagem " +"de marcação suportada pelo PyPI. Os formatos suportados pelo renderizador de " +"README do `PyPI `_ são:" #: ../source/guides/making-a-pypi-friendly-readme.rst:16 msgid "plain text" -msgstr "" +msgstr "texto simples" #: ../source/guides/making-a-pypi-friendly-readme.rst:17 msgid "" "`reStructuredText `_ (without " "Sphinx extensions)" msgstr "" +"`reStructuredText `_ (sem " +"extensões do Sphinx)" #: ../source/guides/making-a-pypi-friendly-readme.rst:18 msgid "" "Markdown (`GitHub Flavored Markdown `_ by " "default, or `CommonMark `_)" msgstr "" +"Markdown (`GitHub Flavored Markdown `_ por " +"padrão ou `CommonMark `_)" #: ../source/guides/making-a-pypi-friendly-readme.rst:21 msgid "" "It's customary to save your README file in the root of your project, in the " "same directory as your :file:`setup.py` file." msgstr "" +"É comum salvar seu arquivo README na raiz de seu projeto, no mesmo diretório " +"que seu arquivo :file:`setup.py`." #: ../source/guides/making-a-pypi-friendly-readme.rst:25 msgid "Including your README in your package's metadata" -msgstr "" +msgstr "Incluindo seu README nos metadados do seu pacote" #: ../source/guides/making-a-pypi-friendly-readme.rst:27 msgid "" @@ -4906,20 +5493,26 @@ msgid "" "project's ``Description`` and ``Description-Content-Type`` metadata, " "typically in your project's :file:`setup.py` file." msgstr "" +"Para incluir o conteúdo do README como a descrição do pacote, defina os " +"metadados ``Description`` e ``Description-Content-Type`` do seu projeto, " +"normalmente no arquivo :file:`setup.py` do seu projeto." #: ../source/guides/making-a-pypi-friendly-readme.rst:33 msgid ":ref:`description-optional`" -msgstr "" +msgstr ":ref:`description-optional`" #: ../source/guides/making-a-pypi-friendly-readme.rst:34 msgid ":ref:`description-content-type-optional`" -msgstr "" +msgstr ":ref:`description-content-type-optional`" #: ../source/guides/making-a-pypi-friendly-readme.rst:36 msgid "" "For example, to set these values in a package's :file:`setup.py` file, use " "``setup()``'s ``long_description`` and ``long_description_content_type``." msgstr "" +"Por exemplo, para definir esses valores em um arquivo :file:`setup.py` do " +"pacote, use ``long_description`` e ``long_description_content_type`` do " +"``setup()``." #: ../source/guides/making-a-pypi-friendly-readme.rst:39 msgid "" @@ -4928,16 +5521,23 @@ msgid "" "``Content-Type``-style value for your README file's markup, such as ``text/" "plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." msgstr "" +"Defina o valor de ``long_description`` para o conteúdo (não o caminho) do " +"próprio arquivo README. Defina o ``long_description_content_type`` para um " +"valor aceito no estilo ``Content-Type`` para a marcação do seu arquivo " +"README, como ``text/plain``, ``text/t-rst`` (para reStructuredText) ou " +"``text/markdown``." #: ../source/guides/making-a-pypi-friendly-readme.rst:45 msgid "" "If you're using GitHub-flavored Markdown to write a project's description, " "ensure you upgrade the following tools:" msgstr "" +"Se você estiver usando o Markdown do GitHub para escrever a descrição de um " +"projeto, certifique-se de atualizar as seguintes ferramentas:" #: ../source/guides/making-a-pypi-friendly-readme.rst:60 msgid "The minimum required versions of the respective tools are:" -msgstr "" +msgstr "As versões mínimas exigidas das respectivas ferramentas são:" #: ../source/guides/making-a-pypi-friendly-readme.rst:62 msgid "``setuptools >= 38.6.0``" @@ -4956,6 +5556,8 @@ msgid "" "It's recommended that you use ``twine`` to upload the project's distribution " "packages:" msgstr "" +"É recomendado que você use ``twine`` para enviar pacotes de distribuição do " +"projeto:" #: ../source/guides/making-a-pypi-friendly-readme.rst:72 msgid "" @@ -4963,10 +5565,13 @@ msgid "" "file:`README.md` as ``long_description`` and identifies the markup as GitHub-" "flavored Markdown:" msgstr "" +"Por exemplo, veja este arquivo :file:`setup.py`, que lê o conteúdo de :file:" +"`README.md` como ``long_description`` e identifica a marcação como Markdown " +"do GitHub:" #: ../source/guides/making-a-pypi-friendly-readme.rst:95 msgid "Validating reStructuredText markup" -msgstr "" +msgstr "Validando a marcação reStructuredText" #: ../source/guides/making-a-pypi-friendly-readme.rst:97 msgid "" @@ -4974,6 +5579,9 @@ msgid "" "prevent it from rendering, causing PyPI to instead just show the README's " "raw source." msgstr "" +"Se o seu README for escrito em reStructuredText, qualquer marcação inválida " +"irá impedi-lo de renderizar, fazendo com que o PyPI mostre apenas o código-" +"fonte não tratado do README." #: ../source/guides/making-a-pypi-friendly-readme.rst:100 msgid "" @@ -4983,27 +5591,37 @@ msgid "" "\"), are not allowed here and will result in error messages like \"``Error: " "Unknown interpreted text role \"py:func\".``\"." msgstr "" +"Observe que as extensões Sphinx usadas em docstrings, como `diretivas e " +"funções `_ (por exemplo, \"``:py:func:`getattr```\" ou \"``:ref:`my-reference-" +"label```\"), não são permitidas aqui e resultarão em mensagens de erro como " +"\"``Error: Unknown interpreted text role \"py:func\".``\"." #: ../source/guides/making-a-pypi-friendly-readme.rst:105 msgid "" "You can check your README for markup errors before uploading as follows:" msgstr "" +"Você pode verificar se há erros de marcação em seu README antes de enviar:" #: ../source/guides/making-a-pypi-friendly-readme.rst:107 msgid "" "Install the latest version of `twine `_; " "version 1.12.0 or higher is required:" msgstr "" +"Instale a versão mais recente do `twine `_; " +"versão 1.12.0 ou superior é necessária:" #: ../source/guides/making-a-pypi-friendly-readme.rst:122 msgid "" "Build the sdist and wheel for your project as described under :ref:" "`Packaging Your Project`." msgstr "" +"Construa o sdist e o wheel para seu projeto conforme descrito em :ref:" +"`Empacotando seu projeto `." #: ../source/guides/making-a-pypi-friendly-readme.rst:125 msgid "Run ``twine check`` on the sdist and wheel::" -msgstr "" +msgstr "Execute ``twine check`` no sdist e wheel::" #: ../source/guides/making-a-pypi-friendly-readme.rst:129 msgid "" @@ -5011,10 +5629,13 @@ msgid "" "renders fine, the command will output ``Checking distribution FILENAME: " "Passed``." msgstr "" +"Este comando relatará quaisquer problemas ao processar seu README. Se sua " +"marcação renderizar corretamente, o comando produzirá ``Checking " +"Distribution FILENAME: Passed``." #: ../source/guides/migrating-to-pypi-org.rst:4 msgid "Migrating to PyPI.org" -msgstr "" +msgstr "Migrando para PyPI.org" #: ../source/guides/migrating-to-pypi-org.rst:6 msgid "" @@ -5023,32 +5644,42 @@ msgid "" "expected to use. These are the tools and processes that people will need to " "interact with ``PyPI.org``." msgstr "" +":term:`pypi.org` é a nova versão reescrita do PyPI que substituiu a base de " +"código legada do PyPI. É a versão padrão do PyPI que se espera que as " +"pessoas usem. Estas são as ferramentas e processos que as pessoas precisarão " +"para interagir com o ``PyPI .org``." #: ../source/guides/migrating-to-pypi-org.rst:12 msgid "Publishing releases" -msgstr "" +msgstr "Publicando lançamentos" #: ../source/guides/migrating-to-pypi-org.rst:14 msgid "``pypi.org`` is the default upload platform as of September 2016." -msgstr "" +msgstr "``pypi.org`` é a plataforma padrão para envio em setembro de 2016." #: ../source/guides/migrating-to-pypi-org.rst:16 msgid "" "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. " "As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." msgstr "" +"Os envios por meio de ``pypi.python.org`` foram *desativados* em **3 de " +"julho de 2017**. Desde 13 de abril de 2018, ``pypi.org`` é a URL do PyPI." #: ../source/guides/migrating-to-pypi-org.rst:19 msgid "" "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." msgstr "" +"A maneira recomendada de migrar para PyPI.org para enviar é garantir que " +"você esteja usando uma versão nova o suficiente de sua ferramenta de envio." #: ../source/guides/migrating-to-pypi-org.rst:22 msgid "" "The default upload settings switched to ``pypi.org`` in the following " "versions:" msgstr "" +"As configurações de envio padrão mudaram para ``pypi.org`` nas seguintes " +"versões:" #: ../source/guides/migrating-to-pypi-org.rst:24 msgid "``twine`` 1.8.0" @@ -5060,19 +5691,19 @@ msgstr "``setuptools`` 27.0.0" #: ../source/guides/migrating-to-pypi-org.rst:26 msgid "Python 2.7.13 (``distutils`` update)" -msgstr "" +msgstr "Python 2.7.13 (atualização de ``distutils``)" #: ../source/guides/migrating-to-pypi-org.rst:27 msgid "Python 3.4.6 (``distutils`` update)" -msgstr "" +msgstr "Python 3.4.6 (atualização de ``distutils``)" #: ../source/guides/migrating-to-pypi-org.rst:28 msgid "Python 3.5.3 (``distutils`` update)" -msgstr "" +msgstr "Python 3.5.3 (atualização de ``distutils``)" #: ../source/guides/migrating-to-pypi-org.rst:29 msgid "Python 3.6.0 (``distutils`` update)" -msgstr "" +msgstr "Python 3.6.0 (atualização de ``distutils``)" #: ../source/guides/migrating-to-pypi-org.rst:31 msgid "" @@ -5082,12 +5713,19 @@ msgid "" "configured in a file located at :file:`$HOME/.pypirc`. If you see a file " "like:" msgstr "" +"Além de garantir que você esteja em uma versão nova o suficiente da " +"ferramenta para que o padrão da ferramenta seja alterado, você também deve " +"se certificar de que não configurou a ferramenta para substituir sua URL de " +"envio padrão. Normalmente, isso é configurado em um arquivo localizado em :" +"file:`$HOME/.pypirc`. Se você vir um arquivo como:" #: ../source/guides/migrating-to-pypi-org.rst:48 msgid "" "Then simply delete the line starting with ``repository`` and you will use " "your upload tool's default URL." msgstr "" +"Em seguida, simplesmente exclua a linha começando com ``repository`` e você " +"usará a URL padrão da sua ferramenta de envio." #: ../source/guides/migrating-to-pypi-org.rst:51 msgid "" @@ -5096,16 +5734,23 @@ msgid "" "pypirc` and include the ``repository:`` line, but use the value ``https://" "upload.pypi.org/legacy/`` instead:" msgstr "" +"Se por algum motivo você não puder atualizar a versão de sua ferramenta para " +"uma versão que usa o padrão PyPI.org, então você pode editar :file:`$HOME/." +"pypirc` e incluir a linha ``repository:``, mas use o valor ``https://upload." +"pypi.org/legacy/`` em vez disso:" #: ../source/guides/migrating-to-pypi-org.rst:67 msgid "" "(``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.)" msgstr "" +"(``legacy`` nesta URL refere-se ao fato de que esta é a emulação da " +"implementação do novo servidor para a API de envio da implementação do " +"servidor legado.)" #: ../source/guides/migrating-to-pypi-org.rst:73 msgid "Registering package names & metadata" -msgstr "" +msgstr "Registrando nomes pacotes e metadados" #: ../source/guides/migrating-to-pypi-org.rst:75 msgid "" @@ -5113,23 +5758,30 @@ msgid "" "command prior to the first upload is no longer required, and is not " "currently supported by the legacy upload API emulation on PyPI.org." msgstr "" +"O pré-registro explícito de nomes de pacotes com o comando ``setup.py " +"register`` antes do primeiro envio não é mais necessário e não é mais " +"suportado pela emulação de API de envio legado no PyPI.org." #: ../source/guides/migrating-to-pypi-org.rst:79 msgid "" "As a result, attempting explicit registration after switching to using PyPI." "org for uploads will give the following error message::" msgstr "" +"Como resultado, a tentativa de registro explícito após alternar para o uso " +"de PyPI.org para envios gerará a seguinte mensagem de erro::" #: ../source/guides/migrating-to-pypi-org.rst:84 msgid "" "The solution is to skip the registration step, and proceed directly to " "uploading artifacts." msgstr "" +"A solução é pular a etapa de registro e prosseguir diretamente para o envio " +"dos artefatos." #: ../source/guides/migrating-to-pypi-org.rst:89 #: ../source/guides/using-testpypi.rst:5 msgid "Using TestPyPI" -msgstr "" +msgstr "Usando TestPyPI" #: ../source/guides/migrating-to-pypi-org.rst:91 msgid "" @@ -5139,10 +5791,15 @@ msgid "" "``https://testpypi.python.org/pypi`` with ``https://test.pypi.org/legacy/``, " "for example:" msgstr "" +"O TestPyPI legado (testpypi.python.org) não está mais disponível; use `test." +"pypi.org `_ em vez disso. Se você usar o TestPyPI, " +"você deve atualizar seu :file:`$HOME/.pypirc` para lidar com o novo local do " +"TestPyPI, substituindo ``https://testpypi.python.org/pypi`` por ``https://" +"test.pypi.org/legacy/``, por exemplo:" #: ../source/guides/migrating-to-pypi-org.rst:113 msgid "Registering new user accounts" -msgstr "" +msgstr "Registrando novas contas de usuário" #: ../source/guides/migrating-to-pypi-org.rst:115 msgid "" @@ -5150,10 +5807,14 @@ msgid "" "through ``pypi.python.org`` was *switched off* on **February 20, 2018**. New " "user registrations at ``pypi.org`` are open." msgstr "" +"A fim de ajudar a mitigar ataques de spam contra PyPI, o registro de novo " +"usuário por meio de ``pypi.python.org`` foi *desativado* em **20 de " +"fevereiro de 2018**. Novos registros de usuários em ``pypi.org`` estão " +"abertos." #: ../source/guides/migrating-to-pypi-org.rst:121 msgid "Browsing packages" -msgstr "" +msgstr "Navegando pelos pacotes" #: ../source/guides/migrating-to-pypi-org.rst:123 msgid "" @@ -5162,28 +5823,34 @@ msgid "" "org``. The domain pypi.python.org now redirects to pypi.org, and may be " "disabled sometime in the future." msgstr "" +"Embora ``pypi.python.org`` ainda possa ser usado em links de outras " +"documentações do PyPA, etc, a interface padrão para navegar pelos pacotes é " +"``pypi.org``. O domínio pypi.python.org agora redireciona para pypi.org e " +"pode ser desativado em algum momento no futuro." #: ../source/guides/migrating-to-pypi-org.rst:130 msgid "Downloading packages" -msgstr "" +msgstr "Baixando pacotes" #: ../source/guides/migrating-to-pypi-org.rst:132 msgid "``pypi.org`` is the default host for downloading packages." -msgstr "" +msgstr "``pypi.org`` é o host padrão para download de pacotes." #: ../source/guides/migrating-to-pypi-org.rst:135 msgid "Managing published packages and releases" -msgstr "" +msgstr "Gerenciando pacotes e lançamentos publicados" #: ../source/guides/migrating-to-pypi-org.rst:137 msgid "" "``pypi.org`` provides a fully functional interface for logged in users to " "manage their published packages and releases." msgstr "" +"``pypi.org`` fornece uma interface totalmente funcional para usuários " +"autenticados gerenciarem seus pacotes publicados e lançamentos." #: ../source/guides/multi-version-installs.rst:5 msgid "Multi-version installs" -msgstr "" +msgstr "Instalações de várias versões" #: ../source/guides/multi-version-installs.rst:8 msgid "" @@ -5192,6 +5859,10 @@ msgid "" "must ``require`` the appropriate version of the project at run time (using " "``pkg_resources``)." msgstr "" +"easy_install permite a instalação simultânea de diferentes versões do mesmo " +"projeto em um único ambiente compartilhado por vários programas que devem " +"exigir (``require``) a versão apropriada do projeto em tempo de execução " +"(usando ``pkg_resources``)." #: ../source/guides/multi-version-installs.rst:13 msgid "" @@ -5201,6 +5872,11 @@ msgid "" "environment shared by multiple applications, such as the system Python in a " "Linux distribution." msgstr "" +"Para muitos casos de uso, ambientes virtuais atendem a essa necessidade sem " +"a complicação da diretiva ``require``. No entanto, a vantagem de instalações " +"paralelas dentro do mesmo ambiente é que funciona para um ambiente " +"compartilhado por várias aplicações, como o sistema Python em uma " +"distribuição Linux." #: ../source/guides/multi-version-installs.rst:19 msgid "" @@ -5216,6 +5892,18 @@ msgid "" "available by default, so the subsequent ``require`` call in your own code " "fails with a spurious version conflict." msgstr "" +"A principal limitação da instalação paralela baseada em ``pkg_resources`` é " +"que assim que você importa ``pkg_resources`` ele bloqueia a versão *padrão* " +"de tudo que já está disponível em sys.path. Isso pode causar problemas, já " +"que ``setuptools`` scripts de linha de comando criados usam " +"``pkg_resources`` para encontrar o ponto de entrada a ser executado. Isso " +"significa que, por exemplo, você não pode usar testes de ``require`` " +"invocados através do ``nose`` ou uma aplicação WSGI invocada através do " +"``gunicorn`` se sua aplicação precisa de uma versão não padrão de qualquer " +"coisa que está disponível no ``sys.path`` padrão -- o script wrapper para a " +"aplicação principal travará na versão que está disponível por padrão, então " +"a chamada subsequente de ``require`` em seu próprio código falhará com um " +"conflito de versão espúrio." #: ../source/guides/multi-version-installs.rst:31 msgid "" @@ -5226,6 +5914,12 @@ msgid "" "script or use ``python -c ''`` to invoke the application's main " "entry point directly." msgstr "" +"Isso pode ser contornado definindo todas as dependências em ``__main__.__ " +"require__`` antes de importar ``pkg_resources`` pela primeira vez, mas essa " +"abordagem significa que as invocações de linha de comando padrão das " +"ferramentas afetadas não podem ser usadas -- é necessário escrever um script " +"wrapper personalizado ou usar ``python -c ''`` para invocar o ponto " +"de entrada principal da aplicação diretamente." #: ../source/guides/multi-version-installs.rst:38 msgid "" @@ -5237,11 +5931,11 @@ msgstr "" #: ../source/guides/packaging-binary-extensions.rst:5 msgid "Packaging binary extensions" -msgstr "" +msgstr "Empacotando extensões binárias" #: ../source/guides/packaging-binary-extensions.rst:8 msgid "2013-12-08" -msgstr "" +msgstr "2013-12-08" #: ../source/guides/packaging-binary-extensions.rst:10 msgid "" @@ -5251,20 +5945,27 @@ msgid "" "to create importable C extensions that allow things which aren't always easy " "to achieve in pure Python code." msgstr "" +"Uma das características do interpretador de referência CPython é que, além " +"de permitir a execução do código Python, também expõe uma API C rica para " +"uso por outro software. Um dos usos mais comuns dessa API C é criar " +"extensões C importáveis que permitem coisas que nem sempre são fáceis de " +"alcançar em código puro Python." #: ../source/guides/packaging-binary-extensions.rst:20 msgid "An overview of binary extensions" -msgstr "" +msgstr "Uma visão geral de extensões binárias" #: ../source/guides/packaging-binary-extensions.rst:23 msgid "Use cases" -msgstr "" +msgstr "Casos de uso" #: ../source/guides/packaging-binary-extensions.rst:25 msgid "" "The typical use cases for binary extensions break down into just three " "conventional categories:" msgstr "" +"Os casos de uso típicos para extensões binárias se dividem em apenas três " +"categorias convencionais:" #: ../source/guides/packaging-binary-extensions.rst:28 msgid "" @@ -5279,6 +5980,16 @@ msgid "" "github.com/python/cpython/blob/master/Modules/_datetimemodule.c>`_) is not " "available." msgstr "" +"**Módulos aceleradores**: esses módulos são completamente autocontidos e são " +"criados exclusivamente para executar mais rápido do que o código puro Python " +"equivalente é executado em CPython. Idealmente, os módulos aceleradores " +"sempre terão um Python equivalente puro para usar como fallback se a versão " +"acelerada não estiver disponível em um determinado sistema. A biblioteca " +"padrão do CPython faz uso extensivo de módulos aceleradores. *Exemplo*: Ao " +"importar ``datetime``, Python recorre ao módulo `datetime.py `_ se a implementação C " +"( `_datetimemodule.c `_) não estiver disponível." #: ../source/guides/packaging-binary-extensions.rst:39 msgid "" @@ -5291,6 +6002,14 @@ msgid "" "Python module wrapper for `_functoolsmodule.c `_." msgstr "" +"**módulos wrapper**: esses módulos são criados para expor as interfaces C " +"existentes ao código Python. Eles podem expor a interface C subjacente " +"diretamente ou então expor uma API mais \"Pythônica\" que faz uso dos " +"recursos da linguagem Python para tornar a API mais fácil de usar. A " +"biblioteca padrão do CPython faz uso extensivo de módulos wrapper. " +"*Exemplo*: `functools.py `_ é um módulo Python wrapper para `_functoolsmodule.c `_." #: ../source/guides/packaging-binary-extensions.rst:47 msgid "" @@ -5303,6 +6022,15 @@ msgid "" "which comes from `sysmodule.c `_." msgstr "" +"**acesso de baixo nível ao sistema**: esses módulos são criados para acessar " +"os recursos de baixo nível do tempo de execução do CPython, do sistema " +"operacional ou do hardware subjacente. Por meio do código específico da " +"plataforma, os módulos de extensão podem alcançar coisas que não são " +"possíveis no código puro Python. Vários módulos de biblioteca padrão do " +"CPython são escritos em C para acessar as partes internas do interpretador " +"que não são expostas no nível da linguagem. *Exemplo*: ``sys``, que vem de " +"`sysmodule.c `_." #: ../source/guides/packaging-binary-extensions.rst:56 msgid "" @@ -5311,6 +6039,11 @@ msgid "" "global interpreter lock around long-running operations (regardless of " "whether those operations are CPU or IO bound)." msgstr "" +"Um recurso particularmente notável das extensões C é que, quando não " +"precisam chamar de volta para o tempo de execução do interpretador, podem " +"liberar o bloqueio do interpretador global do CPython em torno de operações " +"de longa duração (independentemente de essas operações serem vinculados à " +"CPU ou à E/S)." #: ../source/guides/packaging-binary-extensions.rst:61 msgid "" @@ -5322,10 +6055,18 @@ msgid "" "concurrent execution of vectorised operations and to tightly control the " "exact memory layout of created objects." msgstr "" +"Nem todos os módulos de extensão se encaixam perfeitamente nas categorias " +"acima. Os módulos de extensão incluídos com NumPy, por exemplo, abrangem " +"todos os três casos de uso -- eles movem loops internos para C por motivos " +"de velocidade, agrupam bibliotecas externas escritas em C, FORTRAN e outras " +"linguagens e usam interfaces de sistema de baixo nível para CPython e o " +"sistema operacional subjacente para oferecer suporte à execução simultânea " +"de operações vetorizadas e para controlar rigidamente o layout de memória " +"exato dos objetos criados." #: ../source/guides/packaging-binary-extensions.rst:71 msgid "Disadvantages" -msgstr "" +msgstr "Desvantagens" #: ../source/guides/packaging-binary-extensions.rst:73 msgid "" @@ -5336,28 +6077,41 @@ msgid "" "any language that can bind to the CPython C API) typically require that " "custom binaries be created for different platforms." msgstr "" +"A principal desvantagem de usar extensões binárias é o fato de tornar a " +"distribuição subsequente do software mais difícil. Uma das vantagens de usar " +"o Python é que ele é amplamente multiplataforma, e as linguagens usadas para " +"escrever módulos de extensão (normalmente C ou C++, mas na verdade qualquer " +"linguagem que possa se ligar à API C do CPython) normalmente exigem que " +"binários personalizados podem ser criados para plataformas diferentes." #: ../source/guides/packaging-binary-extensions.rst:80 msgid "This means that binary extensions:" -msgstr "" +msgstr "Isso significa que extensões binárias:" #: ../source/guides/packaging-binary-extensions.rst:82 msgid "" "require that end users be able to either build them from source, or else " "that someone publish pre-built binaries for common platforms" msgstr "" +"exigem que os usuários finais sejam capazes de criá-las a partir do código-" +"fonte, ou então que alguém publique binários pré-construídos para " +"plataformas comuns" #: ../source/guides/packaging-binary-extensions.rst:85 msgid "" "may not be compatible with different builds of the CPython reference " "interpreter" msgstr "" +"pode não ser compatível com diferentes compilações do interpretador de " +"referência do CPython" #: ../source/guides/packaging-binary-extensions.rst:88 msgid "" "often will not work correctly with alternative interpreters such as PyPy, " "IronPython or Jython" msgstr "" +"frequentemente não funciona corretamente com interpretadores alternativos " +"como PyPy, Iron Python ou Jython" #: ../source/guides/packaging-binary-extensions.rst:91 msgid "" @@ -5365,6 +6119,10 @@ msgid "" "be familiar not only with Python, but also with the language used to create " "the binary extension, as well as with the details of the CPython C API." msgstr "" +"se codificado manualmente, torna a manutenção mais difícil, exigindo que os " +"mantenedores estejam familiarizados não apenas com Python, mas também com a " +"linguagem usada para criar a extensão binária, bem como com os detalhes da " +"API C do CPython." #: ../source/guides/packaging-binary-extensions.rst:96 msgid "" @@ -5373,6 +6131,10 @@ msgid "" "introducing additional complexity in the test suite to ensure both versions " "are always executed." msgstr "" +"se uma implementação de fallback de puro Python for fornecida, torna a " +"manutenção mais difícil, exigindo que as alterações sejam implementadas em " +"dois lugares, e introduzindo complexidade adicional no conjunto de testes " +"para garantir que ambas as versões sejam sempre executadas." #: ../source/guides/packaging-binary-extensions.rst:101 msgid "" @@ -5381,10 +6143,15 @@ msgid "" "zipfiles) often won't work for extension modules (as the dynamic loading " "mechanisms on most platforms can only load libraries from disk)." msgstr "" +"Outra desvantagem de depender de extensões binárias é que mecanismos de " +"importação alternativos (como a capacidade de importar módulos diretamente " +"de arquivos zip) geralmente não funcionam para módulos de extensão (já que " +"os mecanismos de carregamento dinâmico na maioria das plataformas só podem " +"carregar bibliotecas do disco)." #: ../source/guides/packaging-binary-extensions.rst:108 msgid "Alternatives to handcoded accelerator modules" -msgstr "" +msgstr "Alternativas para módulos aceleradores codificados manualmente" #: ../source/guides/packaging-binary-extensions.rst:110 msgid "" @@ -5393,6 +6160,10 @@ msgid "" "additional maintenance effort), a number of other alternatives should also " "be considered:" msgstr "" +"Quando os módulos de extensão estão apenas sendo usados para tornar o código " +"executado mais rápido (após a criação de perfil ter identificado o código " +"onde o aumento de velocidade vale um esforço de manutenção adicional), uma " +"série de outras alternativas também devem ser consideradas:" #: ../source/guides/packaging-binary-extensions.rst:115 msgid "" @@ -5403,6 +6174,12 @@ msgid "" "appropriate choice of standard library or third party module can avoid the " "need to create your own accelerator module." msgstr "" +"procure alternativas otimizadas existentes. A biblioteca padrão do CPython " +"inclui uma série de estruturas de dados e algoritmos otimizados " +"(especialmente nos módulos embutidos e ``collections`` e ``itertools``). O " +"índice de Pacotes do Python também oferece alternativas adicionais. Às " +"vezes, a escolha apropriada de biblioteca padrão ou módulo de terceiros pode " +"evitar a necessidade de criar seu próprio módulo acelerador." #: ../source/guides/packaging-binary-extensions.rst:122 msgid "" @@ -5416,6 +6193,16 @@ msgid "" "having one live reference instead of two often won't break anything, but no " "references instead of one is a major problem)." msgstr "" +"para aplicações de longa execução, o `interpretador PyPy `__ compilado por JIT pode oferecer uma alternativa adequada ao tempo de " +"execução padrão do CPython. A principal barreira para a adoção do PyPy é " +"normalmente a dependência de outros módulos de extensão binários -- enquanto " +"o PyPy emula a API C do CPython, os módulos que dependem disso causam " +"problemas para o PyPy de JIT e a camada de emulação pode frequentemente " +"expor defeitos latentes na extensão módulos que o CPython atualmente tolera " +"(frequentemente em torno de erros de contagem de referências -- um objeto " +"com uma referência ativa em vez de duas geralmente não quebrará nada, mas " +"nenhuma referência em vez de uma é um grande problema)." #: ../source/guides/packaging-binary-extensions.rst:132 msgid "" @@ -5428,6 +6215,15 @@ msgid "" "benefit of having a reduced barrier to entry for Python programmers " "(relative to other languages like C or C++)." msgstr "" +"`Cython `__ é um compilador estático maduro que pode " +"compilar a maioria dos códigos Python para módulos de extensão C. A " +"compilação inicial fornece alguns aumentos de velocidade (contornando a " +"camada de interpretador do CPython) e os recursos opcionais de tipagem " +"estática do Cython podem oferecer oportunidades adicionais para aumentos de " +"velocidade. Usar o Cython ainda tem a desvantagem de aumentar a complexidade " +"de distribuição do aplicativo resultante, mas tem o benefício de ter uma " +"barreira de entrada reduzida para programadores Python (em relação a outras " +"linguagens como C ou C++)." #: ../source/guides/packaging-binary-extensions.rst:141 msgid "" @@ -5438,10 +6234,17 @@ msgid "" "code is running, but can provide significant speed increases, especially for " "operations that are amenable to vectorisation." msgstr "" +"`Numba `__ é uma ferramenta mais recente, criada " +"por membros da comunidade científica do Python, que visa alavancar o LLVM " +"para permitir a compilação seletiva de partes de uma aplicação Python para " +"código de máquina nativo em tempo de execução. Requer que o LLVM esteja " +"disponível no sistema onde o código está sendo executado, mas pode fornecer " +"aumentos de velocidade significativos, especialmente para operações que são " +"passíveis de vetorização." #: ../source/guides/packaging-binary-extensions.rst:150 msgid "Alternatives to handcoded wrapper modules" -msgstr "" +msgstr "Alternativas para módulos wrapper codificados manualmente" #: ../source/guides/packaging-binary-extensions.rst:152 msgid "" @@ -5451,6 +6254,12 @@ msgid "" "to tap into that functionality. However, wrapping modules by hand is quite " "tedious, so a number of other alternative approaches should be considered." msgstr "" +"A ABI C (Interface Binária de Aplicação) é um padrão comum para " +"compartilhamento de funcionalidade entre vários aplicativos. Um dos pontos " +"fortes da API C do CPython (Interface de Programação de Aplicação) é " +"permitir que os usuários do Python aproveitem essa funcionalidade. No " +"entanto, empacotar módulos manualmente é muito tedioso, portanto, várias " +"outras abordagens alternativas devem ser consideradas." #: ../source/guides/packaging-binary-extensions.rst:158 msgid "" @@ -5458,6 +6267,9 @@ msgid "" "but they *can* significantly reduce the maintenance burden of keeping " "wrapper modules up to date." msgstr "" +"As abordagens descritas abaixo não simplificam o caso de distribuição, mas " +"*podem* reduzir significativamente a carga de manutenção de manter os " +"módulos wrapper atualizados." #: ../source/guides/packaging-binary-extensions.rst:162 msgid "" @@ -5466,6 +6278,11 @@ msgid "" "C++. It still involves wrapping the interfaces by hand, however, and is very " "repetitive, so may not be a good choice for wrapping large APIs." msgstr "" +"Além de ser útil para a criação de módulos aceleradores, `Cython `__ também é útil para criar módulos wrapper para C ou C++. No " +"entanto, ainda envolve fazer wrapper das interfaces manualmente e é muito " +"repetitivo, portanto, pode não ser uma boa escolha para empacotar APIs " +"grandes." #: ../source/guides/packaging-binary-extensions.rst:168 msgid "" @@ -5476,6 +6293,12 @@ msgid "" "Python `__, but doesn't require the Boost libraries or BJam." msgstr "" +"`pybind11 `__ é uma biblioteca C++11 pura " +"que fornece uma interface C++ limpa para a API C do CPython (e PyPy). Não " +"requer uma etapa de pré-processamento; ele é escrito inteiramente em C++ " +"modelado. Auxiliares são incluídos para construções de Setuptools ou CMake. " +"Foi baseado em `Boost.Python `__, mas não requer as bibliotecas Boost ou BJam." #: ../source/guides/packaging-binary-extensions.rst:175 msgid "" @@ -5485,6 +6308,11 @@ msgid "" "makes it relatively straightforward to wrap a C module based on its header " "files, even if you don't know C yourself." msgstr "" +"`cffi `__ é um projeto criado por alguns dos " +"desenvolvedores PyPy para torná-lo simples para desenvolvedores que já " +"conhecem Python e C expor seus módulos C a aplicações Python. Também torna " +"relativamente simples fazer um wrapper de um módulo C com base em seus " +"arquivos de cabeçalho, mesmo que você não conheça C." #: ../source/guides/packaging-binary-extensions.rst:181 msgid "" @@ -5492,6 +6320,9 @@ msgid "" "JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing " "JIT optimisations." msgstr "" +"Uma das principais vantagens do ``cffi`` é que ele é compatível com o PyPy " +"de JIT, permitindo que os módulos wrapper de CFFI participem totalmente das " +"otimizações JIT de rastreamento do PyPy." #: ../source/guides/packaging-binary-extensions.rst:185 msgid "" @@ -5499,6 +6330,9 @@ msgid "" "a variety of programming languages, including Python, to interface with C " "and C++ code." msgstr "" +"`SWIG `__ é um wrapper gerador de interface que " +"permite uma variedade de linguagens de programação, incluindo Python, para " +"fazer interface com código C e C++." #: ../source/guides/packaging-binary-extensions.rst:189 msgid "" @@ -5513,10 +6347,21 @@ msgid "" "``cffi`` *can* operate directly at the C ABI level, it suffers from the same " "interface inconsistency problems as ``ctypes`` when it is used that way." msgstr "" +"O módulo ``ctypes`` da biblioteca padrão, embora útil para obter acesso a " +"interfaces de nível C quando as informações do cabeçalho não estão " +"disponíveis, sofre do fato de operar exclusivamente no nível ABI do C e, " +"portanto, não tem verificação automática de consistência entre os interface " +"realmente sendo exportada pela biblioteca e aquela declarada no código " +"Python. Em contraste, as alternativas acima são todas capazes de operar no " +"nível *API* do C, usando arquivos de cabeçalho C para garantir consistência " +"entre a interface exportada pela biblioteca sendo empacotada e aquela " +"esperada pelo módulo empacotador Python. Enquanto ``cffi`` *pode* operar " +"diretamente no nível ABI do C, ele sofre dos mesmos problemas de " +"inconsistência de interface que ``ctypes`` quando é usado dessa forma." #: ../source/guides/packaging-binary-extensions.rst:203 msgid "Alternatives for low level system access" -msgstr "" +msgstr "Alternativas para acesso de baixo nível ao sistema" #: ../source/guides/packaging-binary-extensions.rst:205 msgid "" @@ -5528,6 +6373,14 @@ msgid "" "like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API " "interfaces." msgstr "" +"Para aplicações que precisam de acesso de baixo nível ao sistema " +"(independentemente do motivo), um módulo de extensão binária geralmente *é* " +"a melhor maneira de fazer isso. Isso é particularmente verdadeiro para o " +"acesso de baixo nível ao próprio tempo de execução do CPython, uma vez que " +"algumas operações (como liberar o Bloqueio Global do Interpretador) são " +"simplesmente inválidas quando o interpretador está executando o código, " +"mesmo se um módulo como ``ctypes`` ou ``cffi`` é usado para obter acesso às " +"interfaces API C relevantes." #: ../source/guides/packaging-binary-extensions.rst:213 msgid "" @@ -5538,10 +6391,17 @@ msgid "" "compatible ABI), and then use one of the wrapping techniques described above " "to make the interface available as an importable Python module." msgstr "" +"Para casos em que o módulo de extensão está manipulando o sistema " +"operacional ou hardware subjacente (em vez do tempo de execução do CPython), " +"às vezes pode ser melhor apenas escrever uma biblioteca C comum (ou uma " +"biblioteca em outra linguagem de programação de sistemas como C++ ou Rust " +"que pode exportar uma ABI compatível com C) e, em seguida, usar uma das " +"técnicas de agrupamento descritas acima para tornar a interface disponível " +"como um módulo Python importável." #: ../source/guides/packaging-binary-extensions.rst:222 msgid "Implementing binary extensions" -msgstr "" +msgstr "Implementando extensões binárias" #: ../source/guides/packaging-binary-extensions.rst:224 msgid "" @@ -5549,14 +6409,18 @@ msgid "" ">`_ guide includes an introduction to writing a `custom extension module in " "C `_." msgstr "" +"O guia `Estendendo e Incorporando `_ do CPython inclui uma introdução a escrever um `módulo de extensão " +"personalizado no C `_." #: ../source/guides/packaging-binary-extensions.rst:241 msgid "Building binary extensions" -msgstr "" +msgstr "Construindo extensões binárias" #: ../source/guides/packaging-binary-extensions.rst:244 msgid "Building extensions for multiple platforms" -msgstr "" +msgstr "Construindo extensões para várias plataformas" #: ../source/guides/packaging-binary-extensions.rst:246 msgid "" @@ -5568,10 +6432,17 @@ msgid "" "redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:" "`multibuild`." msgstr "" +"Se você planeja distribuir sua extensão, você deve fornecer :term:`wheels " +"` para todas as plataformas que pretende oferecer suporte. Para a " +"maioria das extensões, é pelo menos um pacote por versão Python vezes o " +"número de sistemas opcionais e arquiteturas aos quais você oferece suporte. " +"Geralmente são construídos em sistemas de integração contínua (CI). Existem " +"ferramentas para lhe ajudar a construir binários altamente redistribuíveis " +"de CI; estes incluem :ref:`cibuildwheel` e :ref:`multibuild`." #: ../source/guides/packaging-binary-extensions.rst:256 msgid "Binary extensions for Windows" -msgstr "" +msgstr "Extensões binárias para Windows" #: ../source/guides/packaging-binary-extensions.rst:258 msgid "" @@ -5580,6 +6451,10 @@ msgid "" "build the official CPython interpreter, and should be used to build " "compatible binary extensions." msgstr "" +"Antes que seja possível construir uma extensão binária, é necessário " +"garantir que você tenha um compilador adequado disponível. No Windows, o " +"Visual C é usado para construir o interpretador oficial do CPython e deve " +"ser usado para construir extensões binárias compatíveis." #: ../source/guides/packaging-binary-extensions.rst:263 msgid "" @@ -5590,16 +6465,24 @@ msgid "" "differently if you do not already have a copy of the relevant version of " "Visual Studio." msgstr "" +"Python 2.7 usou Visual Studio 2008, Python 3.3 e 3.4 usou Visual Studio 2010 " +"e Python 3.5+ usa Visual Studio 2015 ou posterior. Infelizmente, as versões " +"mais antigas do Visual Studio não estão mais facilmente disponíveis na " +"Microsoft, portanto, para versões do Python anteriores a 3.5, os " +"compiladores devem ser obtidos de forma diferente se você ainda não tiver " +"uma cópia da versão relevante do Visual Studio." #: ../source/guides/packaging-binary-extensions.rst:269 msgid "" "To set up a build environment for binary extensions, the steps are as " "follows:" msgstr "" +"Para configurar um ambiente de construção para extensões binárias, as etapas " +"são as seguintes:" #: ../source/guides/packaging-binary-extensions.rst:271 msgid "For Python 2.7" -msgstr "" +msgstr "Para Python 2.7" #: ../source/guides/packaging-binary-extensions.rst:273 msgid "" @@ -5607,22 +6490,27 @@ msgid "" "from `Microsoft's website `__." msgstr "" +"Instale \"Visual C++ Compiler Package for Python 2.7\", que está disponível " +"no `site da Microsoft `__." #: ../source/guides/packaging-binary-extensions.rst:276 msgid "" "Use (a recent version of) setuptools in your setup.py (pip will do this for " "you, in any case)." msgstr "" +"Use (uma versão recente de) setuptools em seu setup.py (pip fará isso por " +"você, em qualquer caso)." #: ../source/guides/packaging-binary-extensions.rst:278 #: ../source/guides/packaging-binary-extensions.rst:288 #: ../source/guides/packaging-binary-extensions.rst:295 msgid "Done." -msgstr "" +msgstr "Pronto." #: ../source/guides/packaging-binary-extensions.rst:280 msgid "For Python 3.4" -msgstr "" +msgstr "Para Python 3.4" #: ../source/guides/packaging-binary-extensions.rst:282 msgid "" @@ -5630,20 +6518,25 @@ msgid "" "available from `Microsoft's website `__." msgstr "" +"Instale \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), que está " +"disponível no `site da Microsoft `__." #: ../source/guides/packaging-binary-extensions.rst:285 msgid "" "Work from an SDK command prompt (with the environment variables set, and the " "SDK on PATH)." msgstr "" +"Trabalhe em um prompt de comando do SDK (com as variáveis de ambiente " +"definidas e o SDK no PATH)." #: ../source/guides/packaging-binary-extensions.rst:287 msgid "Set DISTUTILS_USE_SDK=1" -msgstr "" +msgstr "Defina DISTUTILS_USE_SDK=1" #: ../source/guides/packaging-binary-extensions.rst:290 msgid "For Python 3.5" -msgstr "" +msgstr "Para Python 3.5" #: ../source/guides/packaging-binary-extensions.rst:292 msgid "" @@ -5651,6 +6544,9 @@ msgid "" "en-us/downloads/download-visual-studio-vs.aspx>`__ (or any later version, " "when these are released)." msgstr "" +"Instale `Visual Studio 2015 Community Edition `__ (ou qualquer versão " +"posterior, quando estas tiverem sido lançadas)." #: ../source/guides/packaging-binary-extensions.rst:297 msgid "" @@ -5658,16 +6554,22 @@ msgid "" "compatible way, which means that any future version of Visual Studio will be " "able to build Python extensions for all Python versions from 3.5 onwards." msgstr "" +"Observe que a partir do Python 3.5 em diante, o Visual Studio funciona de " +"maneira compatível com versões anteriores, o que significa que qualquer " +"versão futura do Visual Studio será capaz de construir extensões Python para " +"todas as versões Python de 3.5 em diante." #: ../source/guides/packaging-binary-extensions.rst:301 msgid "" "Building with the recommended compiler on Windows ensures that a compatible " "C library is used throughout the Python process." msgstr "" +"Construir com o compilador recomendado no Windows garante que uma biblioteca " +"C compatível seja usada em todo o processo do Python." #: ../source/guides/packaging-binary-extensions.rst:305 msgid "Binary extensions for Linux" -msgstr "" +msgstr "Extensões binárias para Linux" #: ../source/guides/packaging-binary-extensions.rst:307 msgid "" @@ -5676,10 +6578,15 @@ msgid "" "images provide a build environment with a glibc old enough to support most " "current Linux distributions on common architectures." msgstr "" +"Os binários do Linux devem usar uma glibc suficientemente antiga para serem " +"compatíveis com distribuições mais antigas. As imagens Docker do `manylinux " +"`_ fornecem um ambiente de construção com " +"uma glibc antiga o suficiente para oferecer suporte à maioria das " +"distribuições Linux atuais em arquiteturas comuns." #: ../source/guides/packaging-binary-extensions.rst:313 msgid "Binary extensions for macOS" -msgstr "" +msgstr "Extensões binárias para macOS" #: ../source/guides/packaging-binary-extensions.rst:315 msgid "" @@ -5692,20 +6599,31 @@ msgid "" "Spinning Wheels wiki `_." msgstr "" +"A compatibilidade binária no macOS é determinada pelo sistema mínimo alvo de " +"implantação, por exemplo, *10.9*, que geralmente é especificado com a " +"variável de ambiente ``MACOSX_DEPLOYMENT_TARGET`` ao construir binários no " +"macOS. Ao construir com setuptools / distutils, o alvo de implantação é " +"especificado com o sinalizador ``--plat-name``, por exemplo, ``macosx-10.9-" +"x86_64``. Para alvos de implantação comuns para distribuições do Python para " +"macOS, consulte a `Spinning Wheels na wiki do MacPython `_." #: ../source/guides/packaging-binary-extensions.rst:325 msgid "Publishing binary extensions" -msgstr "" +msgstr "Publicando extensões binárias" #: ../source/guides/packaging-binary-extensions.rst:327 msgid "" "For interim guidance on this topic, see the discussion in `this issue " "`_." msgstr "" +"Para obter orientações provisórias sobre este tópico, consulte a discussão " +"`neste relatório de problema `_." #: ../source/guides/packaging-binary-extensions.rst:343 msgid "Additional resources" -msgstr "" +msgstr "Recursos adicionais" #: ../source/guides/packaging-binary-extensions.rst:345 msgid "" @@ -5716,10 +6634,16 @@ msgid "" "for developers looking to understand more about the underlying binary " "interfaces that those systems rely on at runtime." msgstr "" +"O desenvolvimento e distribuição multiplataforma de módulos de extensão é um " +"tópico complexo, portanto, este guia se concentra principalmente em fornecer " +"indicadores para várias ferramentas que automatizam o tratamento dos " +"desafios técnicos subjacentes. Os recursos adicionais nesta seção são " +"destinados a desenvolvedores que procuram entender mais sobre as interfaces " +"binárias subjacentes das quais esses sistemas dependem em tempo de execução." #: ../source/guides/packaging-binary-extensions.rst:352 msgid "Cross-platform wheel generation with scikit-build" -msgstr "" +msgstr "Geração de wheel multiplataforma com scikit-build" #: ../source/guides/packaging-binary-extensions.rst:354 msgid "" @@ -5730,36 +6654,49 @@ msgid "" "system generator `_ for Python binary extension modules." msgstr "" +"O pacote `scikit-build `_ " +"ajuda a abstrair as operações de construção multiplataforma e fornece " +"recursos adicionais ao criar pacotes de extensões binárias. Documentação " +"adicional também está disponível no `tempo de execução C, compilador e " +"gerador de sistema de construção `_ para módulos Python de extensão binária." #: ../source/guides/packaging-binary-extensions.rst:362 msgid "Introduction to C/C++ extension modules" -msgstr "" +msgstr "Introdução a módulos de extensão C/C++" #: ../source/guides/packaging-binary-extensions.rst:364 msgid "" "For a more in depth explanation of how extension modules are used by CPython " "on a Debian system, see the following articles:" msgstr "" +"Para uma explicação mais detalhada de como os módulos de extensão são usados " +"pelo CPython em um sistema Debian, consulte os seguintes artigos (todos em " +"inglês):" #: ../source/guides/packaging-binary-extensions.rst:367 msgid "" "`What are (c)python extension modules? `_" msgstr "" +"`O que são módulos de extensão (c)python? `_" #: ../source/guides/packaging-binary-extensions.rst:368 msgid "`Releasing the gil `_" -msgstr "" +msgstr "`Liberando o gil `_" #: ../source/guides/packaging-binary-extensions.rst:369 msgid "" "`Writing cpython extension modules using C++ `_" msgstr "" +"`Escrevendo módulos de extensão cpython usando C++ `_" #: ../source/guides/packaging-namespace-packages.rst:3 msgid "Packaging namespace packages" -msgstr "" +msgstr "Empacotando pacotes de espaço de nomes" #: ../source/guides/packaging-namespace-packages.rst:5 msgid "" @@ -5769,18 +6706,25 @@ msgid "" "**distributions** in this document to avoid ambiguity). For example, if you " "have the following package structure:" msgstr "" +"Os pacotes de espaçode nomes permitem que você divida os subpacotes e " +"módulos dentro de um único :term:`pacote ` em vários :" +"term:`pacotes de distribuição ` (referidos como " +"**distribuições** em este documento para evitar ambiguidade). Por exemplo, " +"se você tiver a seguinte estrutura de pacote:" #: ../source/guides/packaging-namespace-packages.rst:24 msgid "And you use this package in your code like so::" -msgstr "" +msgstr "E você usa este pacote em seu código assim::" #: ../source/guides/packaging-namespace-packages.rst:29 msgid "Then you can break these sub-packages into two separate distributions:" msgstr "" +"Então você pode quebrar esses subpacotes em duas distribuições separadas:" #: ../source/guides/packaging-namespace-packages.rst:46 msgid "Each sub-package can now be separately installed, used, and versioned." msgstr "" +"Cada subpacote pode agora ser instalado, usado e versionado separadamente." #: ../source/guides/packaging-namespace-packages.rst:48 msgid "" @@ -5792,16 +6736,26 @@ msgid "" "mynamespace_subpackage_a`` (you could even use ``import " "mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." msgstr "" +"Os pacotes de espaço de nomes podem ser úteis para uma grande coleção de " +"pacotes vagamente relacionados (como um grande corpo de bibliotecas de " +"cliente para vários produtos de uma única empresa). No entanto, os pacotes " +"de espaço de nomes vêm com várias ressalvas e não são apropriados em todos " +"os casos. Uma alternativa simples é usar um prefixo em todas as suas " +"distribuições, como ``import mynamespace_subpackage_a`` (você pode até usar " +"``import mynamespace_subpackage_a as subpackage_a`` para manter o objeto de " +"importação curto)." #: ../source/guides/packaging-namespace-packages.rst:58 msgid "Creating a namespace package" -msgstr "" +msgstr "Criando um pacote de espaço de nomes" #: ../source/guides/packaging-namespace-packages.rst:60 msgid "" "There are currently three different approaches to creating namespace " "packages:" msgstr "" +"Atualmente, existem três abordagens diferentes para a criação de pacotes de " +"espaço de nomes:" #: ../source/guides/packaging-namespace-packages.rst:62 msgid "" @@ -5810,6 +6764,10 @@ msgid "" "if packages in your namespace only ever need to support Python 3 and " "installation via ``pip``." msgstr "" +"Usar `pacotes de espaço de nomes nativos`_. Este tipo de pacote de espaço de " +"nomes é definido na :pep:`420` e está disponível em Python 3.3 e posterior. " +"Isso é recomendado se os pacotes em seu espaço de nomes precisarem apenas " +"oferecer suporte ao Python 3 e à instalação via ``pip``." #: ../source/guides/packaging-namespace-packages.rst:66 msgid "" @@ -5817,6 +6775,9 @@ msgid "" "packages that need to support Python 2 and 3 and installation via both " "``pip`` and ``python setup.py install``." msgstr "" +"Usar `pacotes de espaço de nomes no estilo pkgutil`_. Isso é recomendado " +"para novos pacotes que precisam oferecer suporte a Python 2 e 3 e à " +"instalação via ``pip`` e ``python setup.py install``." #: ../source/guides/packaging-namespace-packages.rst:69 msgid "" @@ -5824,6 +6785,9 @@ msgid "" "you need compatibility with packages already using this method or if your " "package needs to be zip-safe." msgstr "" +"Usar `pacotes de espaço de nomes no estilo pkg_resources`_. Este método é " +"recomendado se você precisa de compatibilidade com pacotes que já usam este " +"método ou se seu pacote precisa ser seguro para uso de zip." #: ../source/guides/packaging-namespace-packages.rst:73 msgid "" @@ -5832,10 +6796,15 @@ msgid "" "compatible with the other methods. It's inadvisable to use different methods " "in different distributions that provide packages to the same namespace." msgstr "" +"Embora os pacotes de espaço de nomes nativos e pacotes de espaçode nomes no " +"estilo pkgutil sejam amplamente compatíveis, os pacotes de espaçode nomes no " +"estilo pkg_resources não são compatíveis com os outros métodos. Não é " +"aconselhável usar métodos diferentes em distribuições diferentes que " +"fornecem pacotes para o mesmo espaço de nomes." #: ../source/guides/packaging-namespace-packages.rst:80 msgid "Native namespace packages" -msgstr "" +msgstr "Pacotes se espaço de nomes nativos" #: ../source/guides/packaging-namespace-packages.rst:82 msgid "" @@ -5844,6 +6813,10 @@ msgid "" "`__init__.py` from the namespace package directory. An example file " "structure:" msgstr "" +"Python 3.3 adicionou pacotes de espaço de nomes **implícitos** a partir da :" +"pep:`420`. Tudo o que é necessário para criar um pacote de espaço de nomes " +"nativo é omitir :file:`__init__.py` do diretório do pacote de espaço de " +"nomes. Um exemplo de estrutura de arquivo:" #: ../source/guides/packaging-namespace-packages.rst:97 msgid "" @@ -5852,6 +6825,10 @@ msgid "" "`__init__.py`. If any distribution does not, it will cause the namespace " "logic to fail and the other sub-packages will not be importable." msgstr "" +"É extremamente importante que toda distribuição que usa o pacote de espaço " +"de nomes omita o :file:`__init__.py` ou use um :file:`__init__.py` no estilo " +"pkgutil. Se alguma distribuição não o fizer, isso fará com que a lógica do " +"espaço de nomes falhe e os outros subpacotes não serão importáveis." #: ../source/guides/packaging-namespace-packages.rst:102 msgid "" @@ -5860,12 +6837,19 @@ msgid "" "`setuptools.find_namespace_packages` instead or explicitly list all packages " "in your :file:`setup.py`. For example:" msgstr "" +"Porque ``mynamespace`` não contém um :file:`__init__.py`, :func:`setuptools." +"find_packages` não encontrará o subpacote. Você deve usar :func:`setuptools." +"find_namespace_packages` ou listar explicitamente todos os pacotes em seu :" +"file:`setup.py`. Por exemplo:" #: ../source/guides/packaging-namespace-packages.rst:117 msgid "" "A complete working example of two native namespace packages can be found in " "the `native namespace package example project`_." msgstr "" +"Um exemplo de trabalho completo de dois pacotes de espaço de nomes nativos " +"pode ser encontrado no `projeto exemplo de pacote de espaço de nomes " +"nativo`_." #: ../source/guides/packaging-namespace-packages.rst:123 msgid "" @@ -5874,10 +6858,15 @@ msgid "" "Python 3 and pkgutil-style namespace packages in the distributions that need " "to support Python 2 and 3." msgstr "" +"Como os pacotes de espaço de nomes nativos e no estilo pkgutil são " +"amplamente compatíveis, você pode usar pacotes de espaço de nomes nativos " +"nas distribuições que oferecem suporte apenas a Python 3 e pacotes de espaço " +"de nomes no estilo pkgutil nas distribuições que precisam oferecer suporte a " +"Python 2 e 3." #: ../source/guides/packaging-namespace-packages.rst:129 msgid "pkgutil-style namespace packages" -msgstr "" +msgstr "Pacotes de espaço de nomes no estilo pkgutil" #: ../source/guides/packaging-namespace-packages.rst:131 msgid "" @@ -5886,12 +6875,18 @@ msgid "" "with both Python 2.3+ and Python 3. This is the recommended approach for the " "highest level of compatibility." msgstr "" +"Python 2.3 introduziu o módulo `pkgutil`_ e a função `extend_path`_. Isso " +"pode ser usado para declarar pacotes de espaço de nomes que precisam ser " +"compatíveis com Python 2.3+ e Python 3. Esta é a abordagem recomendada para " +"o nível mais alto de compatibilidade." #: ../source/guides/packaging-namespace-packages.rst:136 msgid "" "To create a pkgutil-style namespace package, you need to provide an :file:" "`__init__.py` file for the namespace package:" msgstr "" +"Para criar um pacote de espaço de nomes no estilo pkgutil, você precisa " +"fornecer um arquivo :file:`__init__.py` para o pacote de espaço de nomes:" #: ../source/guides/packaging-namespace-packages.rst:148 #: ../source/guides/packaging-namespace-packages.rst:194 @@ -5899,6 +6894,8 @@ msgid "" "The :file:`__init__.py` file for the namespace package needs to contain " "**only** the following:" msgstr "" +"O arquivo :file:`__init__.py` para o pacote de espaço de nomes precisa " +"conter **apenas** o seguinte:" #: ../source/guides/packaging-namespace-packages.rst:155 #: ../source/guides/packaging-namespace-packages.rst:201 @@ -5908,16 +6905,24 @@ msgid "" "the namespace logic to fail and the other sub-packages will not be " "importable. Any additional code in :file:`__init__.py` will be inaccessible." msgstr "" +"**Cada** distribuição que usa o pacote de espaço de nomes deve incluir um :" +"file:`__init__.py` idêntico. Se alguma distribuição não o fizer, isso fará " +"com que a lógica do espaço de nomes falhe e os outros subpacotes não serão " +"importáveis. Qualquer código adicional no :file:`__init__.py` ficará " +"inacessível." #: ../source/guides/packaging-namespace-packages.rst:160 msgid "" "A complete working example of two pkgutil-style namespace packages can be " "found in the `pkgutil namespace example project`_." msgstr "" +"Um exemplo completamente funcional de dois pacotes de espaço de nomes no " +"estilo pkgutil pode ser encontrado no `projeto exemplo de espaço de nomes de " +"pkgutil`_." #: ../source/guides/packaging-namespace-packages.rst:171 msgid "pkg_resources-style namespace packages" -msgstr "" +msgstr "Pacotes de espaço de nomes no estilo pkg_resources" #: ../source/guides/packaging-namespace-packages.rst:173 msgid "" @@ -5930,18 +6935,32 @@ msgid "" "using this as the different methods are not cross-compatible and it's not " "advisable to try to migrate an existing package." msgstr "" +"`Setuptools`_ fornece a função `pkg_resources.declare_namespace`_ e o " +"argumento ``namespace_packages`` para :func:`~setuptools.setup`. Juntos, " +"eles podem ser usados para declarar pacotes de espaço de nomes. Embora essa " +"abordagem não seja mais recomendada, ela está amplamente presente na maioria " +"dos pacotes de espaço de nomes existentes. Se você estiver criando uma nova " +"distribuição dentro de um pacote de espaço de nomes existente que usa esse " +"método, é recomendável continuar usando-o, pois os diferentes métodos não " +"são compatíveis entre si e não é aconselhável tentar migrar um pacote " +"existente." #: ../source/guides/packaging-namespace-packages.rst:182 msgid "" "To create a pkg_resources-style namespace package, you need to provide an :" "file:`__init__.py` file for the namespace package:" msgstr "" +"Para criar um pacote de espaço de nomes no estilo pkg_resources, você " +"precisa fornecer um arquivo :file:`__init __. Py` para o pacote de espaço de " +"nomes:" #: ../source/guides/packaging-namespace-packages.rst:206 msgid "" "Some older recommendations advise the following in the namespace package :" "file:`__init__.py`:" msgstr "" +"Algumas recomendações mais antigas aconselham o seguinte no :file:`__init__." +"py` de pacotes de espaço de nomes:" #: ../source/guides/packaging-namespace-packages.rst:216 msgid "" @@ -5951,23 +6970,37 @@ msgid "" "cross-compatible. If the presence of setuptools is a concern then the " "package should just explicitly depend on setuptools via ``install_requires``." msgstr "" +"A ideia por trás disso era que, no caso raro de setuptools não estar " +"disponível, os pacotes recorreriam aos pacotes no estilo pkgutil. Isso não é " +"aconselhável porque os pacotes de espaço de nomes estilo pkgutil e " +"pkg_resources não são compatíveis entre si. Se a presença de setuptools é " +"uma preocupação, então o pacote deve depender explicitamente de setuptools " +"via ``install_requires``." #: ../source/guides/packaging-namespace-packages.rst:223 msgid "" "Finally, every distribution must provide the ``namespace_packages`` argument " "to :func:`~setuptools.setup` in :file:`setup.py`. For example:" msgstr "" +"Finalmente, cada distribuição deve fornecer o argumento " +"``namespace_packages`` para :func:`~setuptools.setup` no :file:`setup.py`. " +"Por exemplo:" #: ../source/guides/packaging-namespace-packages.rst:237 msgid "" "A complete working example of two pkg_resources-style namespace packages can " "be found in the `pkg_resources namespace example project`_." msgstr "" +"Um exemplo de completamente funcional de dois pacotes de espaço de nomes no " +"estilo pkg_resources pode ser encontrado no `projeto exemplo de espaço de " +"nomes de pkg_resources`_." #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 msgid "" "Publishing package distribution releases using GitHub Actions CI/CD workflows" msgstr "" +"Publicando versões de distribuição de pacotes usando fluxos de trabalho de " +"CI/CD do GitHub Actions" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 msgid "" @@ -5977,16 +7010,23 @@ msgid "" "Python distribution whenever a tagged commit is pushed. It will use the " "`pypa/gh-action-pypi-publish GitHub Action`_." msgstr "" +"O `CI/CD do GitHub Actions`_ permite que você execute uma série de comandos " +"sempre que ocorrer um evento na plataforma GitHub. Uma escolha popular é ter " +"um fluxo de trabalho que é disparado por um evento ``push``. Este guia " +"mostra como publicar uma distribuição Python sempre que um commit marcado é " +"enviado. Ele usará o `GitHub Action pypa/gh-action-pypi-publish`_." #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 msgid "" "This guide *assumes* that you already have a project that you know how to " "build distributions for and *it lives on GitHub*." msgstr "" +"Este guia *presume* que você já tem um projeto para o qual sabe como " +"construir distribuições e *ele reside no GitHub*." #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 msgid "Saving credentials on GitHub" -msgstr "" +msgstr "Salvando credenciais no GitHub" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 msgid "" @@ -5994,10 +7034,13 @@ msgid "" "meaning that we'll have two separate sets of credentials. And we'll need to " "save them in the GitHub repository settings." msgstr "" +"Neste guia, demonstraremos o envio para o PyPI e TestPyPI, o que significa " +"que teremos dois conjuntos separados de credenciais. E precisaremos salvá-" +"los nas configurações do repositório do GitHub." #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 msgid "Let's begin! 🚀" -msgstr "" +msgstr "Vamos começar! 🚀" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 msgid "" @@ -6008,74 +7051,100 @@ msgid "" "the token list. **Don't close the page just yet — you won't see that token " "again.**" msgstr "" +"Vá para https://pypi.org/manage/account/#api-tokens e crie um novo `token de " +"API `_. Se você já tem o projeto no PyPI, limite o escopo do " +"token apenas a esse projeto. Você pode chamá-lo de algo como ``GitHub " +"Actions CI/CD — project-org/project-repo`` para que seja facilmente " +"distinguível na lista de tokens. **Não feche a página ainda -- você não verá " +"esse token novamente.**" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 msgid "" "In a separate browser tab or window, go to the ``Settings`` tab of your " "target repository and then click on `Secrets`_ in the left sidebar." msgstr "" +"Em uma guia ou janela separada do navegador, vá para a aba ``Configurações`` " +"do seu repositório de destino e clique em `Secrets`_ na barra lateral " +"esquerda." #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 msgid "" "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from " "the first step." msgstr "" +"Crie um novo segredo chamado ` PYPI_API_TOKEN`` e copie e cole o token da " +"primeira etapa." #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 msgid "" "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the " "steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." msgstr "" +"Agora, vá para https://test.pypi.org/manage/account/#api-tokens e repita as " +"etapas. Salve esse token de TestePyPI no GitHub como ``TEST_PYPI_API_TOKEN``." #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 msgid "" "If you don't have a TestPyPI account, you'll need to create it. It's not the " "same as a regular PyPI account." msgstr "" +"Se você não tiver uma conta TestPyPI, precisará criá-la. Não é o mesmo que " +"uma conta do PyPI comum." #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 msgid "Creating a workflow definition" -msgstr "" +msgstr "Criando uma definição de fluxo de trabalho" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 msgid "" "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/" "workflows/`` directory of your repository." msgstr "" +"Os fluxos de trabalho de CI/CD do GitHub são declarados em arquivos YAML " +"armazenados no diretório ``.github/workflows/`` do seu repositório." #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." msgstr "" +"Vamos criar um arquivo chamado ``.github/workflows/publish-to-test-pypi." +"yml``." #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 msgid "" "Start it with a meaningful name and define the event that should make GitHub " "run this workflow:" msgstr "" +"Comece com um nome significativo e defina o evento que deve fazer o GitHub " +"executar este fluxo de trabalho:" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 msgid "Defining a workflow job environment" -msgstr "" +msgstr "Definindo um ambiente de tarefa do fluxo de trabalho" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 msgid "" "Now, let's add initial setup for our job. It's a process that will execute " "commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" msgstr "" +"Agora, vamos adicionar a configuração inicial para nosso trabalho. É um " +"processo que executará comandos que definiremos mais tarde. Neste guia, " +"usaremos o Ubuntu 18.04:" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 msgid "Checking out the project and building distributions" -msgstr "" +msgstr "Fazendo checkout do projeto e construindo as distribuições" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 msgid "Then, add the following under the ``build-n-publish`` section:" -msgstr "" +msgstr "Então, adiccione o seguinte sob a seção ``build-n-publish``:" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 msgid "" "This will download your repository into the CI runner and then install and " "activate Python 3.7." msgstr "" +"Isso fará o download do seu repositório no executor de CI e, em seguida, " +"instalará e ativará o Python 3.7." #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 msgid "" @@ -6083,24 +7152,29 @@ msgid "" "package, assuming that your project has a ``pyproject.toml`` properly set up " "(see :pep:`517`/:pep:`518`)." msgstr "" +"E agora podemos construir dists a partir da fonte. Neste exemplo, usaremos o " +"pacote ``build``, presumindo que seu projeto tem um ``pyproject.toml`` " +"configurado corretamente (veja :pep:`517` /:pep:`518`)." #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 msgid "" "You can use any other method for building distributions as long as it " "produces ready-to-upload artifacts saved into the ``dist/`` folder." msgstr "" +"Você pode usar qualquer outro método para construir distribuições, desde que " +"produza artefatos prontos para enviar, salvos na pasta ``dist/``." #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 msgid "So add this to the steps list:" -msgstr "" +msgstr "Então, adicione isso à lista de etapas:" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 msgid "Publishing the distribution to PyPI and TestPyPI" -msgstr "" +msgstr "Publicando a distribuição para PyPI e TestPyPI" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 msgid "Finally, add the following steps at the end:" -msgstr "" +msgstr "Finalmente, adicione as seguintes etapas ao final:" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 msgid "" @@ -6109,10 +7183,14 @@ msgid "" "unconditionally and the second does that to PyPI, but only if the current " "commit is tagged." msgstr "" +"Essas duas etapas usam a GitHub Action `pypa/gh-action-pypi-publish`_: a " +"primeira carrega o conteúdo da pasta ``dist /`` para TestPyPI " +"incondicionalmente e a segunda faz isso para PyPI, mas apenas se o commit " +"atual estiver marcado." #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 msgid "That's all, folks!" -msgstr "" +msgstr "Isso é tudo, pessoal!" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 msgid "" @@ -6121,22 +7199,31 @@ msgid "" "TestPyPI which is useful for providing test builds to your alpha users as " "well as making sure that your release pipeline remains healthy!" msgstr "" +"Agora, sempre que você fizer um push de um commit com tag para seu " +"repositório Git remoto no GitHub, este fluxo de trabalho irá publicá-lo no " +"PyPI. E publicará qualquer push para TestPyPI que seja útil para fornecer " +"construções de teste para seus usuários alfa, bem como garantir que sua " +"versão pipeline permaneça saudável!" #: ../source/guides/single-sourcing-package-version.rst:5 msgid "Single-sourcing the package version" -msgstr "" +msgstr "Mantendo uma única fonte da versão do pacote" #: ../source/guides/single-sourcing-package-version.rst:8 msgid "" "There are many techniques to maintain a single source of truth for the " "version number of your project:" msgstr "" +"Existem muitas técnicas para manter uma única fonte para o número de versão " +"do seu projeto:" #: ../source/guides/single-sourcing-package-version.rst:11 msgid "" "Read the file in :file:`setup.py` and get the version. Example (from `pip " "setup.py `_)::" msgstr "" +"Leia o arquivo em :file:`setup.py` e obtenha a versão. Exemplo (de `pip " +"setup.py `_)::" #: ../source/guides/single-sourcing-package-version.rst:38 msgid "" @@ -6144,6 +7231,9 @@ msgid "" "instead placing the following in the project's ``setup.cfg`` file (replacing " "\"package\" with the import name of the package):" msgstr "" +"A partir do lançamento do setuptools 46.4.0, pode-se realizar a mesma coisa " +"colocando o seguinte no arquivo ``setup.cfg`` do projeto (substituindo " +"\"pacote\" pelo nome de importação do pacote):" #: ../source/guides/single-sourcing-package-version.rst:47 msgid "" @@ -6152,18 +7242,27 @@ msgid "" "so that ``attr:`` can function without having to import any of the package's " "dependencies." msgstr "" +"Versões anteriores de setuptools implementavam a diretiva ``attr:`` " +"importando o módulo, mas setuptools 46.4.0 adicionou uma análise de AST " +"rudimentar para que ``attr:`` possa funcionar sem ter que importar nenhuma " +"das dependências do pacote." #: ../source/guides/single-sourcing-package-version.rst:52 msgid "" "Also, please be aware that declarative config indicators, including the " "``attr:`` directive, are not supported in parameters to ``setup.py``." msgstr "" +"Além disso, esteja ciente de que os indicadores de configuração " +"declarativos, incluindo a diretiva ``attr: ``, não são suportados em " +"parâmetros para ``setup.py``." #: ../source/guides/single-sourcing-package-version.rst:55 msgid "" "Use an external build tool that either manages updating both locations, or " "offers an API that both locations can use." msgstr "" +"Use uma ferramenta de construção externa que gerencia a atualização de ambos " +"os locais ou oferece uma API que ambos os locais podem usar." #: ../source/guides/single-sourcing-package-version.rst:58 msgid "" @@ -6172,6 +7271,11 @@ msgid "" "`_, `commitizen `_, `zest.releaser `_." msgstr "" +"Poucas ferramentas que você poderia usar, sem nenhuma ordem específica, e " +"não necessariamente completas: `bump2version `_, `changes `_, `commitizen " +"`_, `zest.releaser `_." #: ../source/guides/single-sourcing-package-version.rst:65 msgid "" @@ -6179,24 +7283,33 @@ msgid "" "your project (e.g. :file:`version.py`), then have :file:`setup.py` read and " "``exec`` the value into a variable." msgstr "" +"Defina o valor para uma variável global ``__version__`` em um módulo " +"dedicado em seu projeto (por exemplo, :file:`version.py`), então faça com " +"que :file:`setup.py` leia e execute (``exec``) o valor em uma variável." #: ../source/guides/single-sourcing-package-version.rst:76 msgid "" "Example using this technique: `warehouse `_." msgstr "" +"Exemplo usando esta técnica: `warehouse `_." #: ../source/guides/single-sourcing-package-version.rst:78 msgid "" "Place the value in a simple ``VERSION`` text file and have both :file:`setup." "py` and the project code read it." msgstr "" +"Coloque o valor em um arquivo de texto simples ``VERSION`` e tenha ambos :" +"file:`setup.py` e o código do projeto lidos." #: ../source/guides/single-sourcing-package-version.rst:86 msgid "" "An advantage with this technique is that it's not specific to Python. Any " "tool can read the version." msgstr "" +"Uma vantagem dessa técnica é que ela não é específica do Python. Qualquer " +"ferramenta pode ler a versão." #: ../source/guides/single-sourcing-package-version.rst:91 msgid "" @@ -6204,6 +7317,9 @@ msgid "" "in all your source and binary distributions (e.g. add ``include VERSION`` to " "your :file:`MANIFEST.in`)." msgstr "" +"Com esta abordagem, você deve se certificar de que o arquivo ``VERSION`` " +"está incluído em todas as suas distribuições de fonte e binárias (por " +"exemplo, adicione ``include VERSION`` ao seu :file:`MANIFEST.in`)." #: ../source/guides/single-sourcing-package-version.rst:95 msgid "" @@ -6213,6 +7329,11 @@ msgid "" "as the ``importlib-metadata`` project.) An installed project's version can " "be fetched with the API as follows::" msgstr "" +"Defina o valor em :file:`setup.py` e faça com que o código do projeto use a " +"API ``importlib.metadata`` para buscar o valor em tempo de execução. " +"(``importlib.metadata`` foi introduzido no Python 3.8 e está disponível para " +"versões anteriores como o projeto ``importlib-metadata``.) A versão de um " +"projeto instalado pode ser obtida com a API da seguinte forma::" #: ../source/guides/single-sourcing-package-version.rst:110 msgid "" @@ -6220,6 +7341,9 @@ msgid "" "installation metadata, which is not necessarily the code that's currently " "imported." msgstr "" +"Esteja ciente de que a API ``importlib.metadata`` só sabe sobre o que está " +"nos metadados de instalação, o que não é necessariamente o código que está " +"importado no momento." #: ../source/guides/single-sourcing-package-version.rst:114 msgid "" @@ -6227,30 +7351,42 @@ msgid "" "``install_requires`` value needs to be edited to install ``importlib-" "metadata`` on pre-3.8 versions of Python like so::" msgstr "" +"Se um projeto usa este método para buscar sua versão em tempo de execução, " +"então seu valor ``install_requires`` precisa ser editado para instalar " +"``importlib-metadata`` em versões pré-3.8 do Python como::" #: ../source/guides/single-sourcing-package-version.rst:128 msgid "" "An older (and less efficient) alternative to ``importlib.metadata`` is the " "``pkg_resources`` API provided by ``setuptools``::" msgstr "" +"’Uma alternativa mais antiga (e menos eficiente) ao ``importlib.metadata`` é " +"a API ``pkg_resources`` fornecida pelo ``setuptools``::" #: ../source/guides/single-sourcing-package-version.rst:134 msgid "" "If a project uses ``pkg_resources`` to fetch its own version at runtime, " "then ``setuptools`` must be added to the project's ``install_requires`` list." msgstr "" +"Se um projeto usa ``pkg_resources`` para buscar sua própria versão em tempo " +"de execução, então ``setuptools`` deve ser adicionado à lista " +"``install_requires`` do projeto." #: ../source/guides/single-sourcing-package-version.rst:138 msgid "" "Example using this technique: `setuptools `_." msgstr "" +"Exemplo usando esta técnica: `setuptools `_." #: ../source/guides/single-sourcing-package-version.rst:141 msgid "" "Set the value to ``__version__`` in ``sample/__init__.py`` and import " "``sample`` in :file:`setup.py`." msgstr "" +"Defina o valor para ``__version__`` em ``sample/__init__.py`` e importe " +"``sample`` no :file:`setup.py`." #: ../source/guides/single-sourcing-package-version.rst:155 msgid "" @@ -6258,6 +7394,10 @@ msgid "" "__init__.py`` imports packages from ``install_requires`` dependencies, which " "will very likely not be installed yet when :file:`setup.py` is run." msgstr "" +"Embora esta técnica seja comum, esteja ciente que ela vai falhar se ``sample/" +"__init__.py`` importar pacotes de dependências ``install_requires``, que " +"muito provavelmente ainda não estarão instalados quando :file:`setup.py` for " +"executado." #: ../source/guides/single-sourcing-package-version.rst:161 msgid "" @@ -6265,10 +7405,13 @@ msgid "" "Mercurial, etc) instead of in the code, and automatically extract it from " "there using `setuptools_scm `_." msgstr "" +"Mantenha o número da versão nas tags de um sistema de controle de versão " +"(Git, Mercurial, etc), em vez de no código, e extraia-o automaticamente de " +"lá usando `setuptools_scm `_." #: ../source/guides/supporting-multiple-python-versions.rst:5 msgid "Supporting multiple Python versions" -msgstr "" +msgstr "Fornecendo suporte a várias versões do Python" #: ../source/guides/supporting-multiple-python-versions.rst:37 msgid "" @@ -6278,6 +7421,11 @@ msgid "" "standard library packages, and the changes between Python versions 2.x and 3." "x include changes in the language syntax." msgstr "" +"Além do trabalho necessário para criar um pacote Python, geralmente é " +"necessário que o pacote esteja disponível em diferentes versões do Python. " +"Diferentes versões Python podem conter diferentes (ou renomeados) pacotes de " +"biblioteca padrão, e as alterações entre Python versões 2.x e 3.x incluem " +"alterações na sintaxe da linguagem." #: ../source/guides/supporting-multiple-python-versions.rst:43 msgid "" @@ -6286,10 +7434,15 @@ msgid "" "time-consuming. Fortunately, several tools are available for dealing with " "this, and these will briefly be discussed here." msgstr "" +"Executados manualmente, todos os testes necessários para garantir que o " +"pacote funcione corretamente em todas as versões alvo Python (e sistemas " +"operacionais!) podem consumir muito tempo. Felizmente, várias ferramentas " +"estão disponíveis para lidar com isso, e elas serão brevemente discutidas " +"aqui." #: ../source/guides/supporting-multiple-python-versions.rst:49 msgid "Automated testing and continuous integration" -msgstr "" +msgstr "Testes automatizados e integração contínua" #: ../source/guides/supporting-multiple-python-versions.rst:51 msgid "" @@ -6298,6 +7451,11 @@ msgid "" "github.com>`_ or `Bitbucket `_) and run your " "project's test suite every time a new commit is made." msgstr "" +"Vários serviços hospedados para testes automatizados estão disponíveis. " +"Esses serviços normalmente irão monitorar seu repositório de código-fonte " +"(por exemplo, no `Github `_ ou `Bitbucket `_) e executar um conjunto de testes do seu projeto toda vez " +"que um novo commit é feito." #: ../source/guides/supporting-multiple-python-versions.rst:56 msgid "" @@ -6305,6 +7463,10 @@ msgid "" "*multiple versions of Python*, giving rapid feedback about whether the code " "will work, without the developer having to perform such tests themselves." msgstr "" +"Esses serviços também oferecem facilidades para executar o conjunto de " +"testes do seu projeto em *várias versões do Python*, fornecendo um feedback " +"rápido sobre se o código funcionará, sem que o desenvolvedor tenha que " +"realizar esses testes por conta própria." #: ../source/guides/supporting-multiple-python-versions.rst:60 msgid "" @@ -6313,6 +7475,10 @@ msgid "" "integration systems. There are two hosted services which when used in " "conjunction provide automated testing across Linux, Mac and Windows:" msgstr "" +"A Wikipédia tem uma extensa `comparação `_ de muitos sistemas de " +"integração contínua. Existem dois serviços hospedados que, quando usados em " +"conjunto, fornecem testes automatizados no Linux, Mac e Windows:" #: ../source/guides/supporting-multiple-python-versions.rst:66 msgid "" @@ -6320,12 +7486,17 @@ msgid "" "environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit " "while the macOS is 10.9.2 at the time of writing." msgstr "" +"`Travis CI `_ fornece um ambiente Linux e macOS. O " +"ambiente Linux é Ubuntu 12.04 LTS Server Edition de 64 bits, enquanto o " +"macOS é 10.9.2 no momento da escrita." #: ../source/guides/supporting-multiple-python-versions.rst:69 msgid "" "`Appveyor `_ provides a Windows environment " "(Windows Server 2012)." msgstr "" +"`Appveyor `_ fornece um ambiente Windows (Windows " +"Server 2012)." #: ../source/guides/supporting-multiple-python-versions.rst:80 msgid "" @@ -6333,16 +7504,22 @@ msgid "" "formatted file as specification for the instructions for testing. If any " "tests fail, the output log for that specific configuration can be inspected." msgstr "" +"Tanto o `Travis CI`_ quanto o Appveyor_ exigem um arquivo formatado em `YAML " +"`_ como especificação para as instruções de teste. Se " +"algum teste falhar, o log de saída para essa configuração específica pode " +"ser inspecionado." #: ../source/guides/supporting-multiple-python-versions.rst:85 msgid "" "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." msgstr "" +"Para projetos Python que devem ser implantados em Python 2 e 3 com uma " +"estratégia de única fonte, há uma série de opções." #: ../source/guides/supporting-multiple-python-versions.rst:89 msgid "Tools for single-source Python packages" -msgstr "" +msgstr "Ferramentas para pacotes Python de única fonte" #: ../source/guides/supporting-multiple-python-versions.rst:91 msgid "" @@ -6355,6 +7532,14 @@ msgid "" "Armin Ronacher, can be used to automatically apply the code modifications " "provided by six_." msgstr "" +"`six `_ é uma ferramenta desenvolvida por " +"Benjamin Peterson para resolver as diferenças entre Python 2 e Python 3. O " +"pacote six_ desfrutou de uso generalizado e pode ser considerado como uma " +"maneira confiável de escrever um módulo Python de fonte única que pode ser " +"usado em Python 2 e 3. O módulo six_ pode ser usado a partir de Python 2.5. " +"Uma ferramenta chamada `modernize `_, " +"desenvolvida por Armin Ronacher, pode ser usada para aplicar automaticamente " +"as modificações de código fornecidas por six_." #: ../source/guides/supporting-multiple-python-versions.rst:100 msgid "" @@ -6364,14 +7549,19 @@ msgid "" "interoperability between Python 2 and Python 3 with a language syntax that " "matches one of the two Python versions: one may use" msgstr "" +"Semelhante a six_, `python-future `_ " +"é um pacote que fornece uma camada de compatibilidade entre o código-fonte " +"de Python 2 e Python 3; no entanto, ao contrário do six_, este pacote visa " +"fornecer interoperabilidade entre Python 2 e Python 3 com uma sintaxe de " +"linguagem que corresponda a uma das duas versões Python: pode-se usar" #: ../source/guides/supporting-multiple-python-versions.rst:107 msgid "a Python 2 (by syntax) module in a Python 3 project." -msgstr "" +msgstr "um módulo Python 2 (por sintaxe) em um projeto Python 3." #: ../source/guides/supporting-multiple-python-versions.rst:108 msgid "a Python 3 (by syntax) module in a *Python 2* project." -msgstr "" +msgstr "um módulo Python 3 (por sintaxe) em um projeto *Python 3*." #: ../source/guides/supporting-multiple-python-versions.rst:110 msgid "" @@ -6382,6 +7572,12 @@ msgid "" "``futurize`` and ``pasteurize`` that can be applied to either a Python 2 " "module or a Python 3 module respectively." msgstr "" +"Por causa da bidirecionalidade, python-future_ oferece um caminho para " +"converter um pacote Python 2 na sintaxe de Python 3, módulo por módulo. No " +"entanto, em contraste com six_, python-future_ é compatível apenas com " +"Python 2.6. Semelhante a modernize_ para six_, python-future_ vem com dois " +"scripts chamados ``futurize`` e ``pasteurize`` que podem ser aplicados a um " +"módulo Python 2 ou um módulo Python 3 respectivamente." #: ../source/guides/supporting-multiple-python-versions.rst:117 msgid "" @@ -6391,10 +7587,16 @@ msgid "" "provides for forward-compatibility to Python 3. Any remaining compatibility " "problems would require manual changes." msgstr "" +"O uso de six_ ou python-future_ adiciona uma dependência adicional de tempo " +"de execução ao seu pacote: com python-future_, o script ``futurize`` pode " +"ser chamado com a opção ``--stage1`` para aplicar apenas as mudanças que " +"Python 2.6+ já fornece compatibilidade com versões futuras para Python 3. " +"Quaisquer problemas de compatibilidade remanescentes exigiriam alterações " +"manuais." #: ../source/guides/supporting-multiple-python-versions.rst:124 msgid "What's in which Python?" -msgstr "" +msgstr "O que há em cada Python?" #: ../source/guides/supporting-multiple-python-versions.rst:126 msgid "" @@ -6405,14 +7607,21 @@ msgid "" "com/blog/201803/whats_in_which_python_3436.html>`__. These lists may be used " "to check whether any changes between Python versions may affect your package." msgstr "" +"Ned Batchelder fornece uma lista de alterações em cada versão Python para " +"`Python 2 `__, `Python 3.0-3.3 `__ e `Python 3.4-3.6 `__. Essas listas podem ser " +"usadas para verificar se quaisquer mudanças entre as versões Python podem " +"afetar seu pacote." #: ../source/guides/supporting-windows-using-appveyor.rst:3 msgid "Supporting Windows using Appveyor" -msgstr "" +msgstr "Oferece suporte a Windows usando Appveyor" #: ../source/guides/supporting-windows-using-appveyor.rst:6 msgid "2015-12-03" -msgstr "" +msgstr "2015-12-03" #: ../source/guides/supporting-windows-using-appveyor.rst:8 msgid "" @@ -6421,6 +7630,10 @@ msgid "" "the code on Windows, and building Windows-targeted binaries for projects " "that use C extensions." msgstr "" +"Esta seção cobre como usar o serviço gratuito de integração contínua " +"`Appveyor`_ para fornecer suporte a Windows para seu projeto. Isso inclui " +"testar o código no Windows e construir binários direcionados para Windows " +"para projetos que usam extensões C." #: ../source/guides/supporting-windows-using-appveyor.rst:20 msgid "" @@ -6428,6 +7641,9 @@ msgid "" "support can be a challenge, because setting up a suitable Windows test " "environment is non-trivial, and may require buying software licenses." msgstr "" +"Muitos projetos são desenvolvidos em Unix por padrão, e fornecer suporte ao " +"Windows pode ser um desafio, porque configurar um ambiente de teste adequado " +"no Windows não é trivial e pode exigir a compra de licenças de software." #: ../source/guides/supporting-windows-using-appveyor.rst:24 msgid "" @@ -6437,6 +7653,11 @@ msgid "" "are Windows hosts and have the necessary compilers installed to build Python " "extensions." msgstr "" +"O serviço Appveyor é um serviço de integração contínua, muito parecido com o " +"serviço `Travis`_ mais conhecido que é comumente usado para testes por " +"projetos hospedados no `Github`_. No entanto, ao contrário do Travis, os " +"workers de construção no Appveyor são hosts Windows e têm os compiladores " +"necessários instalados para construir extensões Python." #: ../source/guides/supporting-windows-using-appveyor.rst:30 msgid "" @@ -6447,10 +7668,16 @@ msgid "" "for testing) it is possible for projects without a dedicated Windows " "environment to provide Windows-targeted binaries." msgstr "" +"Os usuários do Windows normalmente não têm acesso a um compilador C e, " +"portanto, dependem de projetos que usam extensões C distribuindo wheels " +"binárias no PyPI para que a distribuição seja instalável via ``python -m pip " +"install ``. Ao usar o Appveyor como um serviço de construção (mesmo " +"que não seja para teste), é possível para projetos sem um ambiente Windows " +"dedicado fornecer binários direcionados ao Windows." #: ../source/guides/supporting-windows-using-appveyor.rst:38 msgid "Setting up" -msgstr "" +msgstr "Configurando" #: ../source/guides/supporting-windows-using-appveyor.rst:40 msgid "" @@ -6459,6 +7686,11 @@ msgid "" "given in `the Appveyor documentation `__. The " "free tier of account is perfectly adequate for open source projects." msgstr "" +"Para usar o Appveyor para construir wheels de Windows para o seu projeto, " +"você deve ter uma conta no serviço. As instruções sobre como configurar uma " +"conta são fornecidas `na documentação do Appveyor `__. O nível de conta grátis é perfeitamente adequado para projetos de " +"código aberto." #: ../source/guides/supporting-windows-using-appveyor.rst:45 msgid "" @@ -6466,6 +7698,9 @@ msgid "" "your project is hosted on one of those two services, setting up Appveyor " "integration is straightforward." msgstr "" +"O Appveyor fornece integração com `Github`_ e `Bitbucket`_, portanto, desde " +"que seu projeto esteja hospedado em um desses dois serviços, configurar a " +"integração do Appveyor é simples." #: ../source/guides/supporting-windows-using-appveyor.rst:49 msgid "" @@ -6473,10 +7708,13 @@ msgid "" "will automatically build your project each time a commit occurs. This " "behaviour will be familiar to users of Travis." msgstr "" +"Depois de configurar sua conta do Appveyor e adicionar seu projeto, o " +"Appveyor construirá automaticamente seu projeto cada vez que ocorrer um " +"commit. Esse comportamento será familiar para os usuários do Travis." #: ../source/guides/supporting-windows-using-appveyor.rst:54 msgid "Adding Appveyor support to your project" -msgstr "" +msgstr "Adicionando suporte a Appveyor ao seu projeto" #: ../source/guides/supporting-windows-using-appveyor.rst:56 msgid "" @@ -6485,6 +7723,11 @@ msgid "" "be included in the file are covered in the Appveyor documentation. This " "guide will provide the details necessary to set up wheel builds." msgstr "" +"Para definir como o Appveyor deve construir seu projeto, você precisa " +"adicionar um arquivo :file:`appveyor.yml` ao seu projeto. Os detalhes " +"completos do que pode ser incluído no arquivo são cobertos na documentação " +"do Appveyor. Este guia fornecerá os detalhes necessários para configurar a " +"configuração dos wheels." #: ../source/guides/supporting-windows-using-appveyor.rst:61 msgid "" @@ -6496,10 +7739,17 @@ msgid "" "version of Visual Studio used includes 64-bit compilers with no additional " "setup)." msgstr "" +"O Appveyor inclui por padrão todos os conjuntos de ferramentas do compilador " +"necessários para construir extensões para Python. Para Python 2.7, 3.5+ e " +"versões de 32 bits de 3.3 e 3.4, as ferramentas funcionam prontamente. Mas " +"para as versões de 64 bits do Python 3.3 e 3.4, há uma pequena quantidade de " +"configuração adicional necessária para permitir que os distutils saibam onde " +"encontrar os compiladores de 64 bits. (De 3.5 em diante, a versão do Visual " +"Studio usada inclui compiladores de 64 bits sem configuração adicional)." #: ../source/guides/supporting-windows-using-appveyor.rst:69 msgid "appveyor.yml" -msgstr "" +msgstr "appveyor.yml" #: ../source/guides/supporting-windows-using-appveyor.rst:75 msgid "" @@ -6507,12 +7757,17 @@ msgid "" "pypa/python-packaging-user-guide/master/source/guides/appveyor-sample/" "appveyor.yml>`__." msgstr "" +"Este arquivo pode ser baixado `daqui `__." #: ../source/guides/supporting-windows-using-appveyor.rst:77 msgid "" "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." msgstr "" +"O arquivo :file:`appveyor.yml` deve estar localizado no diretório raiz do " +"seu projeto. Está no formato ``YAML`` e consiste em várias seções." #: ../source/guides/supporting-windows-using-appveyor.rst:80 msgid "" @@ -6524,6 +7779,14 @@ msgid "" "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)." msgstr "" +"A seção ``environment`` é a chave para definir as versões Python para as " +"quais seus wheels serão criados. O Appveyor vem com Python 2.6, 2.7, 3.3, " +"3.4 e 3.5 instalados, em compilações de 32 e 64 bits. O arquivo de exemplo é " +"criado para todos esses ambientes, exceto Python 2.6. A instalação do Python " +"2.6 é mais complexa, pois não vem com o pip incluído. Não oferecemos suporte " +"ao 2.6 neste documento (já que os usuários do Windows que ainda usam o " +"Python 2 geralmente são capazes de migrar para o Python 2.7 sem muita " +"dificuldade)." #: ../source/guides/supporting-windows-using-appveyor.rst:88 msgid "" @@ -6533,18 +7796,27 @@ msgid "" "circumstances (for example, to install additional build packages such as " "``Cython``, or test tools such as ``tox``)." msgstr "" +"A seção ``install`` usa pip para instalar qualquer software adicional que o " +"projeto possa exigir. O único requisito para a construção de wheels é o " +"projeto ``wheel``, mas os projetos podem desejar personalizar este código em " +"certas circunstâncias (por exemplo, para instalar pacotes de construção " +"adicionais, como ``Cython``, ou ferramentas de teste como ``tox``)." #: ../source/guides/supporting-windows-using-appveyor.rst:94 msgid "" "The ``build`` section simply switches off builds - there is no build step " "needed for Python, unlike languages like ``C#``." msgstr "" +"A seção ``build`` simplesmente desativa as construções -- não há etapa de " +"construção necessária para Python, ao contrário de linguagens como ``C#``." #: ../source/guides/supporting-windows-using-appveyor.rst:97 msgid "" "The main sections that will need to be tailored to your project are " "``test_script`` and ``after_test``." msgstr "" +"As principais seções que precisarão ser adaptadas ao seu projeto são " +"``test_script`` e ``after_test``." #: ../source/guides/supporting-windows-using-appveyor.rst:100 msgid "" @@ -6557,6 +7829,15 @@ msgid "" "you are using ``tox`` there are some additional configuration changes you " "will need to consider, which are described below." msgstr "" +"A seção ``test_script`` é onde você executará os testes do seu projeto. O " +"arquivo fornecido executa seu conjunto de testes usando ``setup.py test``. " +"Se você está interessado apenas em construir wheels, e não em executar seus " +"testes no Windows, você pode substituir esta seção por um comando fictício, " +"como ``echo Skipped Tests``. Você pode querer usar outra ferramenta de " +"teste, como ``nose`` ou :file:`py.test`. Ou você pode desejar usar um driver " +"de teste como o ``tox`` -- entretanto, se você estiver usando o ``tox``, " +"existem algumas alterações de configuração adicionais que você precisará " +"considerar, que são descritas abaixo." #: ../source/guides/supporting-windows-using-appveyor.rst:109 msgid "" @@ -6565,16 +7846,23 @@ msgid "" "(specifically, ``setuptools``) then the ``setup.py bdist_wheel`` command " "will build your wheels." msgstr "" +"O ``after_test`` é executado uma vez que seus testes foram concluídos, e " +"então é onde os wheels devem ser construídos. Presumindo que seu projeto usa " +"as ferramentas recomendadas (especificamente, ``setuptools``) então o " +"comando ``setup.py bdist_wheel`` irá construir seus wheels." #: ../source/guides/supporting-windows-using-appveyor.rst:114 msgid "" "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." msgstr "" +"Observe que os wheels só serão construídos se seus testes forem bem-" +"sucedidos. Se você espera que seus testes falhem no Windows, você pode pulá-" +"los conforme descrito acima." #: ../source/guides/supporting-windows-using-appveyor.rst:119 msgid "Support script" -msgstr "" +msgstr "Script de suporte" #: ../source/guides/supporting-windows-using-appveyor.rst:121 msgid "" @@ -6583,6 +7871,11 @@ msgid "" "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." msgstr "" +"O arquivo :file:`appveyor.yml` depende de um único script de suporte, que " +"configura o ambiente para usar o compilador SDK para compilações de 64 bits " +"no Python 3.3 e 3.4. Para projetos que não precisam de um compilador, ou que " +"não oferecem suporte a 3.3 ou 3.4 em Windows 64 bits, apenas o arquivo :file:" +"`appveyor.yml` é necessário." #: ../source/guides/supporting-windows-using-appveyor.rst:126 msgid "" @@ -6595,16 +7888,26 @@ msgid "" "Python 3.3 or 3.4, so don't set the environment variable for any other " "builds." msgstr "" +"`build.cmd `__ é um script em lote " +"do Windows que executa um único comando em um ambiente com o compilador " +"apropriado para a versão Python selecionada. Tudo que você precisa fazer é " +"definir a única variável de ambiente ``DISTUTILS_USE_SDK`` para um valor de " +"``1`` e o script faz o resto. Ele configura o SDK necessário para " +"compilações de 64 bits de Python 3.3 ou 3.4, portanto, não defina a variável " +"de ambiente para quaisquer outras compilações." #: ../source/guides/supporting-windows-using-appveyor.rst:133 msgid "" "You can simply download the batch file and include it in your project " "unchanged." msgstr "" +"Você pode simplesmente baixar o arquivo em lote e incluí-lo em seu projeto " +"inalterado." #: ../source/guides/supporting-windows-using-appveyor.rst:137 msgid "Access to the built wheels" -msgstr "" +msgstr "Acesso aos wheels construídos" #: ../source/guides/supporting-windows-using-appveyor.rst:139 msgid "" @@ -6616,14 +7919,21 @@ msgid "" "architecture. You can download those wheels and upload them to PyPI as part " "of your release process." msgstr "" +"Quando sua construção for concluída, os wheels construídos estarão " +"disponíveis no painel de controle do Appveyor para o seu projeto. Eles podem " +"ser encontrados acessando a página de status de construção de cada " +"construção por vez. No topo da saída de construção, há uma série de links, " +"um dos quais é \"Artifacts\" (Artefatos). Essa página incluirá uma lista de " +"links para os wheels dessa versão Python / arquitetura. Você pode baixar " +"esses wheels e enviá-los para PyPI como parte de seu processo de lançamento." #: ../source/guides/supporting-windows-using-appveyor.rst:147 msgid "Additional notes" -msgstr "" +msgstr "Notas adicionais" #: ../source/guides/supporting-windows-using-appveyor.rst:150 msgid "Testing with tox" -msgstr "" +msgstr "Testando com tox" #: ../source/guides/supporting-windows-using-appveyor.rst:152 msgid "" @@ -6631,6 +7941,9 @@ msgid "" "are run in an isolated environment using the exact files that will be " "distributed by the project." msgstr "" +"Muitos projetos usam a ferramenta `Tox`_ para executar seus testes. Ele " +"garante que os testes sejam executados em um ambiente isolado usando os " +"arquivos exatos que serão distribuídos pelo projeto." #: ../source/guides/supporting-windows-using-appveyor.rst:156 msgid "" @@ -6638,6 +7951,9 @@ msgid "" "considerations (in actual fact, these issues are not specific to Appveyor, " "and may well affect other CI systems)." msgstr "" +"Para usar o ``tox`` no Appveyor, há algumas considerações adicionais (na " +"verdade, esses problemas não são específicos do Appveyor e podem afetar " +"outros sistemas de CI)." #: ../source/guides/supporting-windows-using-appveyor.rst:160 msgid "" @@ -6646,6 +7962,10 @@ msgid "" "control the compiler, this \"test isolation\" feature will cause the tests " "to use the wrong compiler by default." msgstr "" +"Por padrão, ``tox`` apenas passa um subconjunto escolhido de variáveis de " +"ambiente para os processos de teste. Como ``distutils`` usa variáveis de " +"ambiente para controlar o compilador, este recurso de \"isolamento de teste" +"\" fará com que os testes usem o compilador errado por padrão." #: ../source/guides/supporting-windows-using-appveyor.rst:165 msgid "" @@ -6654,22 +7974,26 @@ msgid "" "list the additional environment variables to be passed to the subprocess. " "For the SDK compilers, you need" msgstr "" +"Para forçar o ``tox`` passar as variáveis de ambiente necessárias para o " +"subprocesso, você precisa definir a opção de configuração ``passenv`` do " +"``tox`` para listar as variáveis de ambiente adicionais a serem passadas " +"para o subprocesso. Para os compiladores SDK, você precisa" #: ../source/guides/supporting-windows-using-appveyor.rst:170 msgid "``DISTUTILS_USE_SDK``" -msgstr "" +msgstr "``DISTUTILS_USE_SDK``" #: ../source/guides/supporting-windows-using-appveyor.rst:171 msgid "``MSSdk``" -msgstr "" +msgstr "``MSSdk``" #: ../source/guides/supporting-windows-using-appveyor.rst:172 msgid "``INCLUDE``" -msgstr "" +msgstr "``INCLUDE``" #: ../source/guides/supporting-windows-using-appveyor.rst:173 msgid "``LIB``" -msgstr "" +msgstr "``LIB``" #: ../source/guides/supporting-windows-using-appveyor.rst:175 msgid "" @@ -6679,6 +8003,11 @@ msgid "" "supplied :file:`build.cmd` script does this by default whenever " "``DISTUTILS_USE_SDK`` is set." msgstr "" +"A opção ``passenv`` pode ser definida em seu :file:`tox.ini`, ou se você " +"preferir evitar adicionar configurações específicas do Windows aos seus " +"arquivos de projeto gerais, pode ser definida configurando a variável de " +"ambiente ``TOX_TESTENV_PASSENV``. O script :file:`build.cmd` fornecido faz " +"isso por padrão sempre que ``DISTUTILS_USE_SDK`` é definida." #: ../source/guides/supporting-windows-using-appveyor.rst:181 msgid "" @@ -6690,6 +8019,13 @@ msgid "" "specify which environment to use (there are default environments for most " "versions of Python)." msgstr "" +"Quando usado interativamente, ``tox`` permite que você execute seus testes " +"em vários ambientes (frequentemente, isso significa várias versões do " +"Python). Este recurso não é tão útil em um ambiente de CI como Travis ou " +"Appveyor, onde todos os testes são executados em ambientes isolados para " +"cada configuração. Como resultado, os projetos geralmente fornecem um " +"argumento ``-e NOMEENV`` para ``tox`` para especificar qual ambiente usar " +"(há ambientes padrão para a maioria das versões do Python)." #: ../source/guides/supporting-windows-using-appveyor.rst:188 msgid "" @@ -6697,6 +8033,9 @@ msgid "" "where there are (for example) two installations of Python 3.4 (32-bit and 64-" "bit) available, but only one ``py34`` environment in ``tox``." msgstr "" +"No entanto, isso *não* funciona bem com um sistema de CI no Windows como o " +"Appveyor, onde há (por exemplo) duas instalações de Python 3.4 (32 bits e 64 " +"bits) disponíveis, mas apenas um ambiente ``py34`` no ``tox``." #: ../source/guides/supporting-windows-using-appveyor.rst:192 msgid "" @@ -6705,6 +8044,11 @@ msgid "" "that was used to run ``tox``. This will ensure that when Appveyor runs the " "tests, they will be run with the configured interpreter." msgstr "" +"Para executar testes usando o ``tox``, portanto, os projetos provavelmente " +"devem usar o ambiente padrão ``py`` no ``tox``, que usa o interpretador " +"Python que foi usado para executar ``tox`` . Isso garantirá que, quando o " +"Appveyor executar os testes, eles serão executados com o interpretador " +"configurado." #: ../source/guides/supporting-windows-using-appveyor.rst:197 msgid "" @@ -6713,10 +8057,13 @@ msgid "" "their :file:`tox.ini` file. Doing so is, however, outside the scope of this " "document." msgstr "" +"Para oferecer suporte à execução no ambiente ``py``, é possível que projetos " +"com configurações complexas de ``tox`` precisem modificar seu arquivo :file:" +"`tox.ini`. Fazer isso está, no entanto, fora do escopo deste documento." #: ../source/guides/supporting-windows-using-appveyor.rst:203 msgid "Automatically uploading wheels" -msgstr "" +msgstr "Enviando automaticamente wheels" #: ../source/guides/supporting-windows-using-appveyor.rst:205 msgid "" @@ -6725,6 +8072,11 @@ msgid "" "(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." msgstr "" +"É possível solicitar que o Appveyor envie automaticamente os wheels. Há uma " +"etapa ``deployment`` disponível no :file:`appveyor.yml` que pode ser usada " +"para, por exemplo, copiar os artefatos construídos para um site FTP ou uma " +"instância do Amazon S3. A documentação sobre como fazer isso está incluída " +"nos guias do Appveyor." #: ../source/guides/supporting-windows-using-appveyor.rst:210 msgid "" @@ -6733,16 +8085,22 @@ msgid "" "clear that uploading new wheels after every commit is desirable (although " "some projects may wish to do this)." msgstr "" +"Alternativamente, seria possível adicionar um passo ``twine upload`` à " +"construção. O :file:`appveyor.yml` fornecido não faz isso, pois não está " +"claro se é desejável enviar novos wheels após cada commit (embora alguns " +"projetos possam desejar fazer isso)." #: ../source/guides/supporting-windows-using-appveyor.rst:216 msgid "External dependencies" -msgstr "" +msgstr "Dependências externas" #: ../source/guides/supporting-windows-using-appveyor.rst:218 msgid "" "The supplied scripts will successfully build any distribution that does not " "rely on 3rd party external libraries for the build." msgstr "" +"Os scripts fornecidos construirão com sucesso qualquer distribuição que não " +"dependa de bibliotecas externas de terceiros para a construção." #: ../source/guides/supporting-windows-using-appveyor.rst:221 msgid "" @@ -6753,32 +8111,42 @@ msgid "" "to the compiler. However, this level of configuration is beyond the scope of " "this document." msgstr "" +"É possível adicionar etapas à configuração :file:`appveyor.yml` (normalmente " +"na seção \"install\") para baixar e/ou construir bibliotecas externas " +"necessárias para a distribuição. E se necessário, é possível adicionar " +"configuração extra para a construção para fornecer a localização dessas " +"bibliotecas para o compilador. No entanto, esse nível de configuração está " +"além do escopo deste documento." #: ../source/guides/supporting-windows-using-appveyor.rst:230 msgid "Support scripts" -msgstr "" +msgstr "Scripts de suporte" #: ../source/guides/supporting-windows-using-appveyor.rst:232 msgid "For reference, the SDK setup support script is listed here:" msgstr "" +"Para referência, o script de suporte de configuração do SDK está listado " +"aqui:" #: ../source/guides/supporting-windows-using-appveyor.rst:234 msgid "``appveyor-sample/build.cmd``" -msgstr "" +msgstr "``appveyor-sample/build.cmd``" #: ../source/guides/tool-recommendations.rst:5 msgid "Tool recommendations" -msgstr "" +msgstr "Recomendações de ferramentas" #: ../source/guides/tool-recommendations.rst:7 msgid "" "If you're familiar with Python packaging and installation, and just want to " "know what tools are currently recommended, then here it is." msgstr "" +"Se você está familiarizado com o pacote e a instalação do Python e só deseja " +"saber quais ferramentas são recomendadas atualmente, aqui está." #: ../source/guides/tool-recommendations.rst:12 msgid "Application dependency management" -msgstr "" +msgstr "Gerenciamento de dependências de aplicações" #: ../source/guides/tool-recommendations.rst:14 msgid "" @@ -6786,26 +8154,31 @@ msgid "" "applications. See :doc:`../tutorials/managing-dependencies` for more details " "on using ``pipenv``." msgstr "" +"Use :ref:`pipenv` para gerenciar as dependências da biblioteca ao " +"desenvolver aplicações Python. Veja :doc:`../tutorials/managing-" +"dependencies` para mais detalhes sobre como usar o ``pip env``." #: ../source/guides/tool-recommendations.rst:18 msgid "When ``pipenv`` does not meet your use case, consider other tools like:" msgstr "" +"Quando ``pipenv`` não atende ao seu caso de uso, considere outras " +"ferramentas como:" #: ../source/guides/tool-recommendations.rst:20 msgid ":ref:`pip`" -msgstr "" +msgstr ":ref:`pip`" #: ../source/guides/tool-recommendations.rst:22 msgid "`pip-tools `_" -msgstr "" +msgstr "`pip-tools `_" #: ../source/guides/tool-recommendations.rst:24 msgid "`Poetry `_" -msgstr "" +msgstr "`Poetry `_" #: ../source/guides/tool-recommendations.rst:27 msgid "Installation tool recommendations" -msgstr "" +msgstr "Recomendações de ferramentas de instalação" #: ../source/guides/tool-recommendations.rst:29 msgid "" @@ -6814,38 +8187,52 @@ msgid "" "ref:`pip` is installed, you may need to also install :ref:`wheel` to get the " "benefit of wheel caching. [3]_" msgstr "" +"Use :ref:`pip` para instalar :term:`pacotes ` do " +"Python a partir do :term:`PyPI `. [1]_ [2]_ " +"Dependendo de como :ref:`pip` é instalado, você também pode precisar " +"instalar o :ref:`wheel` para obter o benefício do armazenamento em cache do " +"wheel. [3]_" #: ../source/guides/tool-recommendations.rst:34 msgid "" "Use :ref:`virtualenv`, or `venv`_ to isolate application specific " "dependencies from a shared Python installation. [4]_" msgstr "" +"Use :ref:`virtualenv` ou `venv`_ para isolar dependências específicas da " +"aplicação de uma instalação compartilhada do Python. [4]_" #: ../source/guides/tool-recommendations.rst:37 msgid "" "If you're looking for management of fully integrated cross-platform software " "stacks, consider:" msgstr "" +"Se você estiver procurando por gerenciamento de pilhas de software " +"multiplataforma totalmente integradas, considere:" #: ../source/guides/tool-recommendations.rst:40 msgid ":ref:`buildout`: primarily focused on the web development community" msgstr "" +":ref:`buildout`: focado principalmente na comunidade de desenvolvimento web" #: ../source/guides/tool-recommendations.rst:42 msgid "" ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the " "scientific community." msgstr "" +":ref:`spack`, :ref:`hashdist` ou :ref:`conda`: focado principalmente na " +"comunidade científica." #: ../source/guides/tool-recommendations.rst:47 msgid "Packaging tool recommendations" -msgstr "" +msgstr "Recomendações de ferramentas de empacotamento" #: ../source/guides/tool-recommendations.rst:49 msgid "" "Use :ref:`setuptools` to define projects and create :term:`Source " "Distributions `. [5]_ [6]_" msgstr "" +"Use :ref:`setuptools` para definir projetos e criar :term:`Distribuições " +"Fontes `. [5]_ [6]_" #: ../source/guides/tool-recommendations.rst:52 msgid "" @@ -6853,16 +8240,21 @@ msgid "" "`wheel project ` to create :term:`wheels `. This is " "especially beneficial, if your project contains binary extensions." msgstr "" +"Use a extensão ``bdist_wheel`` :ref:`setuptools` disponível no :ref: " +"`projeto wheel ` para criar :term:`wheels `. Isso é " +"especialmente benéfico se o seu projeto contiver extensões binárias." #: ../source/guides/tool-recommendations.rst:56 msgid "" "Use `twine `_ for uploading distributions " "to :term:`PyPI `." msgstr "" +"Use `twine `_ para enviar distribuições para " +"o :term:`PyPI `." #: ../source/guides/tool-recommendations.rst:61 msgid "Publishing platform migration" -msgstr "" +msgstr "Migração da plataforma de publicação" #: ../source/guides/tool-recommendations.rst:63 msgid "" @@ -6870,12 +8262,18 @@ msgid "" "python.org `_) has been phased out in favour of an " "updated implementation hosted at `pypi.org `_." msgstr "" +"A implementação do Python Package Index original (anteriormente hospedada em " +"`pypi.python.org `_) foi eliminada em favor de uma " +"implementação atualizada hospedada em `pypi.org `_." #: ../source/guides/tool-recommendations.rst:67 msgid "" "See :ref:`Migrating to PyPI.org` for more information on the status of the " "migration, and what settings to change in your clients." msgstr "" +"Veja :ref:`Migrando para PyPI.org ` para mais " +"informações sobre o status da migração, e quais configurações alterar em " +"seus clientes." #: ../source/guides/tool-recommendations.rst:72 msgid "" @@ -6884,6 +8282,10 @@ msgid "" "(which pip doesn't support). For a detailed breakdown, see :ref:`pip vs " "easy_install`." msgstr "" +"Existem alguns casos em que você pode escolher usar ``easy_install`` (do :" +"ref:`setuptools`), por exemplo se você precisar instalar a partir de :term:" +"`Eggs ` (que pip não oferece suporte). Para uma análise detalhada, " +"consulte :ref:`pip vs easy_install`." #: ../source/guides/tool-recommendations.rst:77 msgid "" @@ -6892,6 +8294,10 @@ msgid "" "`rationale section <453#rationale>` from :pep:`453` as for why pip was " "chosen." msgstr "" +"A aceitação da :pep:`453` significa que :ref:`pip` estará disponível por " +"padrão na maioria das instalações do Python 3.4 ou posterior. Veja a :pep:" +"`seção de motivos <453#rationale>` da :pep:`453` para saber por que pip foi " +"escolhido." #: ../source/guides/tool-recommendations.rst:82 msgid "" @@ -6901,6 +8307,11 @@ msgid "" "found in various linux distros, does not depend on \"python-wheel\" " "currently." msgstr "" +"`get-pip.py `_ e :ref:`virtualenv` " +"instalam :ref:`wheel`, enquanto :ref:`ensurepip` e :ref:`venv ` não " +"instalam atualmente. Além disso, o pacote comum \"python-pip\" que é " +"encontrado em várias distros do Linux, não depende do \"python-wheel\" " +"atualmente." #: ../source/guides/tool-recommendations.rst:88 msgid "" @@ -6909,6 +8320,10 @@ msgid "" "`virtualenv`. However, using :ref:`virtualenv` will still be recommended for " "users that need cross-version consistency." msgstr "" +"A partir do Python 3.4, ``venv `` criará ambientes virtualenv com ``pip`` " +"instalado, tornando-o uma alternativa igual a :ref:`virtualenv`. No entanto, " +"usar :ref:`virtualenv` ainda será recomendado para usuários que precisam de " +"consistência entre versões." #: ../source/guides/tool-recommendations.rst:93 msgid "" @@ -6921,6 +8336,14 @@ msgid "" "``setuptools`` support all of the modern metadata fields described in :ref:" "`core-metadata`." msgstr "" +"Embora você possa usar ``distutils`` puro para muitos projetos, ele não " +"oferece suporta à definição de dependências em outros projetos e não possui " +"vários utilitários de conveniência para preencher automaticamente os " +"metadados de distribuição fornecidos pelo ``setuptools``. Estando fora da " +"biblioteca padrão, ``setuptools`` também oferece um conjunto de recursos " +"mais consistente em diferentes versões do Python e (ao contrário de " +"``distutils``), versões recentes do ``setuptools`` oferecem suporte a todos " +"os campos de metadados modernos descritos em :ref:`core-metadata`." #: ../source/guides/tool-recommendations.rst:102 msgid "" @@ -6929,16 +8352,23 @@ msgid "" "prebuilt :term:`wheel ` file), it will actually build your project " "using :ref:`setuptools` instead." msgstr "" +"Mesmo para projetos que escolhem usar ``distutils``, quando o :ref:`pip` " +"instala tais projetos diretamente da fonte (ao invés de instalar de um " +"arquivo :term:`wheel ` pré-construído), ele irá, na verdade, " +"construir seu projeto usando :ref:`setuptools`." #: ../source/guides/tool-recommendations.rst:107 msgid "" "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` " "in June 2013, thereby making setuptools the default choice for packaging." msgstr "" +"`distribute`_ (um fork do setuptools) foi mesclado no :ref:`setuptools` em " +"junho de 2013, tornando assim setuptools a escolha padrão para empacotamento." #: ../source/guides/using-manifest-in.rst:5 msgid "Including files in source distributions with ``MANIFEST.in``" msgstr "" +"Incluindo arquivos em distribuições de código-fonte com ``MANIFEST.in``" #: ../source/guides/using-manifest-in.rst:7 msgid "" @@ -6953,90 +8383,115 @@ msgid "" "in the sdist so that people that build or install from the sdist get the " "correct results." msgstr "" +"Ao construir uma :term:`distribuição fonte ` para o seu pacote, por padrão apenas um conjunto mínimo de arquivos é " +"incluído. Você pode querer incluir arquivos extras na distribuição, como um " +"arquivo de autores/contribuidores, um diretório :file:`docs/` ou um " +"diretório de arquivos de dados usado para fins de teste. Pode até haver " +"arquivos extras que você *precisa* incluir; por exemplo, se o seu :file:" +"`setup.py` calcula a ``long_description`` do seu projeto lendo um arquivo " +"README e um changelog, você precisará incluir ambos os arquivos no sdist " +"para que as pessoas que construam ou instalar a partir do sdist obtém os " +"resultados corretos." #: ../source/guides/using-manifest-in.rst:17 msgid "" "Adding & removing files to & from the source distribution is done by writing " "a :file:`MANIFEST.in` file at the project root." msgstr "" +"Adicionar e remover arquivos para e da distribuição fonte é feito escrevendo " +"um arquivo :file:`MANIFEST.in` na raiz do projeto." #: ../source/guides/using-manifest-in.rst:22 msgid "How files are included in an sdist" -msgstr "" +msgstr "Como os arquivos são incluídos em um sdist" #: ../source/guides/using-manifest-in.rst:24 msgid "The following files are included in a source distribution by default:" msgstr "" +"Os seguintes arquivos são incluídos em uma distribuição fonte por padrão:" #: ../source/guides/using-manifest-in.rst:26 msgid "" "all Python source files implied by the ``py_modules`` and ``packages`` " "``setup()`` arguments" msgstr "" +"todos os arquivos fonte Python implícitos pelos argumentos ``py_modules`` e " +"``packages`` do ``setup()``" #: ../source/guides/using-manifest-in.rst:28 msgid "" "all C source files mentioned in the ``ext_modules`` or ``libraries`` " "``setup()`` arguments" msgstr "" +"todos os arquivos fonte C mencionados nos argumentos ``ext_modules`` ou " +"``libraries`` do ``setup()``" #: ../source/guides/using-manifest-in.rst:30 msgid "scripts specified by the ``scripts`` ``setup()`` argument" -msgstr "" +msgstr "scripts especificados pelo argumento ``scripts`` do ``setup()``" #: ../source/guides/using-manifest-in.rst:31 msgid "" "all files specified by the ``package_data`` and ``data_files`` ``setup()`` " "arguments" msgstr "" +"todos os arquivos especificados pelos argumentos ``package_data`` e " +"``data_files`` do ``setup()``" #: ../source/guides/using-manifest-in.rst:33 msgid "" "the file specified by the ``license_file`` option in :file:`setup.cfg` " "(setuptools 40.8.0+)" msgstr "" +"o arquivo especificado pela opção ``license_file`` em :file:`setup.cfg` " +"(setuptools 40.8.0+)" #: ../source/guides/using-manifest-in.rst:35 msgid "" "all files specified by the ``license_files`` option in :file:`setup.cfg` " "(setuptools 42.0.0+)" msgstr "" +"todos os arquivos especificados pela opção ``license_files`` em :file:`setup." +"cfg` (setuptools 42.0.0+)" #: ../source/guides/using-manifest-in.rst:37 msgid "all files matching the pattern :file:`test/test*.py`" -msgstr "" +msgstr "todos os arquivos correspondendo ao padrão :file:`test/test*.py`" #: ../source/guides/using-manifest-in.rst:38 msgid ":file:`setup.py` (or whatever you called your setup script)" msgstr "" +":file:`setup.py` (ou o que quer que você tenha chamado de seu script de " +"configuração)" #: ../source/guides/using-manifest-in.rst:39 msgid ":file:`setup.cfg`" -msgstr "" +msgstr ":file:`setup.cfg`" #: ../source/guides/using-manifest-in.rst:40 msgid ":file:`README`" -msgstr "" +msgstr ":file:`README`" #: ../source/guides/using-manifest-in.rst:41 msgid ":file:`README.txt`" -msgstr "" +msgstr ":file:`README.txt`" #: ../source/guides/using-manifest-in.rst:42 msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" -msgstr "" +msgstr ":file:`README.rst` (Python 3.7+ ou setuptools 0.6.27+)" #: ../source/guides/using-manifest-in.rst:43 msgid ":file:`README.md` (setuptools 36.4.0+)" -msgstr "" +msgstr ":file:`README.md` (setuptools 36.4.0+)" #: ../source/guides/using-manifest-in.rst:44 msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" -msgstr "" +msgstr ":file:`pyproject.toml` (setuptools 43.0.0+)" #: ../source/guides/using-manifest-in.rst:45 msgid ":file:`MANIFEST.in`" -msgstr "" +msgstr ":file:`MANIFEST.in`" #: ../source/guides/using-manifest-in.rst:47 msgid "" @@ -7045,6 +8500,10 @@ msgid "" "files to & from the sdist. Default files can even be removed from the sdist " "with the appropriate :file:`MANIFEST.in` command." msgstr "" +"Depois de adicionar os arquivos acima ao sdist, os comandos em :file:" +"`MANIFEST.in` (se tal arquivo existir) são executados para adicionar e " +"remover outros arquivos para e do sdist. Os arquivos padrão podem até mesmo " +"ser removidos do sdist com o comando apropriado de :file:`MANIFEST.in`." #: ../source/guides/using-manifest-in.rst:52 msgid "" @@ -7054,10 +8513,15 @@ msgid "" "and an :file:`*.egg-info` directory. This behavior cannot be changed with :" "file:`MANIFEST.in`." msgstr "" +"Após processar o arquivo :file:`MANIFEST.in`, setuptools remove o diretório :" +"file:`build/` bem como quaisquer diretórios chamados :file:`RCS`, :file:" +"`CVS` ou :file:`.svn` do sdist, e adiciona um arquivo :file:`PKG-INFO` e um " +"diretório :file:`*.egg-info`. Este comportamento não pode ser alterado com :" +"file:`MANIFEST.in`." #: ../source/guides/using-manifest-in.rst:60 msgid ":file:`MANIFEST.in` commands" -msgstr "" +msgstr "Comandos do :file:`MANIFEST.in`" #: ../source/guides/using-manifest-in.rst:62 msgid "" @@ -7065,81 +8529,96 @@ msgid "" "setuptools to add or remove some set of files from the sdist. The commands " "are:" msgstr "" +"Um arquivo :file:`MANIFEST.in` consiste em comandos, um por linha, " +"instruindo o setuptools a adicionar ou remover algum conjunto de arquivos do " +"sdist. Os comandos são:" #: ../source/guides/using-manifest-in.rst:67 msgid "Command" -msgstr "" +msgstr "Comando" #: ../source/guides/using-manifest-in.rst:69 msgid ":samp:`include {pat1} {pat2} ...`" -msgstr "" +msgstr ":samp:`include {padrão1} {padrão2} ...`" #: ../source/guides/using-manifest-in.rst:69 msgid "Add all files matching any of the listed patterns" msgstr "" +"Adiciona todos os arquivos correspondendo a qualquer um dos padrões listados" #: ../source/guides/using-manifest-in.rst:70 msgid ":samp:`exclude {pat1} {pat2} ...`" -msgstr "" +msgstr ":samp:`exclude {padrão1} {padrão2} ...`" #: ../source/guides/using-manifest-in.rst:70 msgid "Remove all files matching any of the listed patterns" msgstr "" +"Remove todos os arquivos correspondendo a qualquer um dos padrões listados" #: ../source/guides/using-manifest-in.rst:71 msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" -msgstr "" +msgstr ":samp:`recursive-include {padrão-dir} {padrão1} {padrão2} ...`" #: ../source/guides/using-manifest-in.rst:71 msgid "" "Add all files under directories matching ``dir-pattern`` that match any of " "the listed patterns" msgstr "" +"Adiciona todos os arquivos sob diretórios correspondendo a ``padrão-dir`` " +"que correspondem a qualquer um dos padrões listados" #: ../source/guides/using-manifest-in.rst:72 msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" -msgstr "" +msgstr ":samp:`recursive-exclude {padrão-dir} {padrão1} {padrão2} ...`" #: ../source/guides/using-manifest-in.rst:72 msgid "" "Remove all files under directories matching ``dir-pattern`` that match any " "of the listed patterns" msgstr "" +"Remove todos os arquivos sob diretórios correspondendo a ``padrão-dir`` que " +"correspondem a qualquer um dos padrões listados" #: ../source/guides/using-manifest-in.rst:73 msgid ":samp:`global-include {pat1} {pat2} ...`" -msgstr "" +msgstr ":samp:`global-include {padrão1} {padrão2} ...`" #: ../source/guides/using-manifest-in.rst:73 msgid "" "Add all files anywhere in the source tree matching any of the listed patterns" msgstr "" +"Adiciona todos os arquivos em qualquer lugar na árvore de fontes que " +"correspondam a qualquer um dos padrões listados" #: ../source/guides/using-manifest-in.rst:74 msgid ":samp:`global-exclude {pat1} {pat2} ...`" -msgstr "" +msgstr ":samp:`global-exclude {padrão1} {padrão2} ...`" #: ../source/guides/using-manifest-in.rst:74 msgid "" "Remove all files anywhere in the source tree matching any of the listed " "patterns" msgstr "" +"Remove todos os arquivos de qualquer lugar na árvore de fontes que " +"correspondam a qualquer um dos padrões listados" #: ../source/guides/using-manifest-in.rst:75 msgid ":samp:`graft {dir-pattern}`" -msgstr "" +msgstr ":samp:`graft {padrão-dir}`" #: ../source/guides/using-manifest-in.rst:75 msgid "Add all files under directories matching ``dir-pattern``" msgstr "" +"Adiciona todos os arquivos sob diretórios correspondendo a ``padrão-dir``" #: ../source/guides/using-manifest-in.rst:76 msgid ":samp:`prune {dir-pattern}`" -msgstr "" +msgstr ":samp:`prune {padrão-dir}`" #: ../source/guides/using-manifest-in.rst:76 msgid "Remove all files under directories matching ``dir-pattern``" msgstr "" +"Remove todos os arquivos sob diretórios correspondendo a ``padrão-dir``" #: ../source/guides/using-manifest-in.rst:79 msgid "" @@ -7152,6 +8631,14 @@ msgid "" "support for ``**`` matching zero or more characters including forward slash, " "backslash, and colon." msgstr "" +"Os padrões aqui são padrões do estilo glob: ``*`` corresponde a zero ou mais " +"caracteres de nome de arquivo regulares (no Unix, tudo exceto barra; no " +"Windows, tudo exceto barra invertida e dois pontos); ``?`` corresponde a um " +"único caractere de nome de arquivo regular, e ``[chars]`` corresponde a " +"qualquer um dos caracteres entre os colchetes (que podem conter intervalos " +"de caracteres, por exemplo, ``[az]`` ou ``[ a-fA-F0-9]``). Setuptools também " +"tem suporte não documentado para ``**`` correspondendo a zero ou mais " +"caracteres, incluindo barra, barra invertida e dois pontos." #: ../source/guides/using-manifest-in.rst:87 msgid "" @@ -7159,6 +8646,9 @@ msgid "" "``graft example*`` will include a directory named :file:`examples` in the " "project root but will not include :file:`docs/examples/`." msgstr "" +"Os padrões de diretório são relativos à raiz do diretório do projeto; por " +"exemplo, ``graft exemplo*`` incluirá um diretório chamado :file:`exemplos` " +"na raiz do projeto, mas não incluirá :file:`docs/exemplos/`." #: ../source/guides/using-manifest-in.rst:91 msgid "" @@ -7166,12 +8656,17 @@ msgid "" "setuptools will automatically convert the slashes to the local platform's " "appropriate directory separator." msgstr "" +"Nomes de arquivos e diretórios em :file:`MANIFEST.in` devem ser separados " +"por ``/``; setuptools irá converter automaticamente as barras para o " +"separador de diretório apropriado da plataforma local." #: ../source/guides/using-manifest-in.rst:95 msgid "" "Commands are processed in the order they appear in the :file:`MANIFEST.in` " "file. For example, given the commands::" msgstr "" +"Os comandos são processados na ordem em que aparecem no arquivo :file:" +"`MANIFEST.in`. Por exemplo, dados os comandos ::" #: ../source/guides/using-manifest-in.rst:101 msgid "" @@ -7183,6 +8678,13 @@ msgid "" "`tests` happened to contain any ``*.pyc`` files, they would end up included " "in the sdist because the exclusion happened before they were included." msgstr "" +"o conteúdo da árvore de diretórios :file:`tests` será primeiro adicionado ao " +"sdist, e depois disso todos os arquivos no sdist com uma extensão ``.pyc``, " +"``.pyo`` ou ``.pyd`` será removidos do sdist. Se os comandos estivessem na " +"ordem oposta, então os arquivos ``*.pyc`` etc. seriam removidos apenas do " +"que já estava no sdist antes de adicionar :file:`tests`, e se :file:`tests` " +"contivesse quaisquer arquivos ``*.pyc``, eles acabariam incluídos no sdist " +"porque a exclusão aconteceu antes de serem incluídos." #: ../source/guides/using-testpypi.rst:7 msgid "" @@ -7191,10 +8693,14 @@ msgid "" "without worrying about affecting the real index. TestPyPI is hosted at `test." "pypi.org `_" msgstr "" +"``Test PyPI`` é uma instância separada do :term:`Python Package Index " +"(PyPI)` que permite que você experimente as ferramentas de distribuição e o " +"processo sem se preocupar em afetar o índice real. O TestPyPI está hospedado " +"em `test.pypi.org `_" #: ../source/guides/using-testpypi.rst:13 msgid "Registering your account" -msgstr "" +msgstr "Registrando sua conta" #: ../source/guides/using-testpypi.rst:15 msgid "" @@ -7202,22 +8708,29 @@ msgid "" "separate user account for specifically for TestPyPI. Go to https://test.pypi." "org/account/register/ to register your account." msgstr "" +"Como o TestPyPI tem um banco de dados separado do PyPI real, você precisará " +"de uma conta de usuário separada especificamente para o TestPyPI. Vá para " +"https://test.pypi.org/account/register/ para registrar sua conta." #: ../source/guides/using-testpypi.rst:19 msgid "" "The database for TestPyPI may be periodically pruned, so it is not unusual " "for user accounts to be deleted." msgstr "" +"O banco de dados do TestPyPI pode ser apagado periodicamente, portanto, não " +"é incomum que contas de usuário sejam excluídas." #: ../source/guides/using-testpypi.rst:24 msgid "Using TestPyPI with Twine" -msgstr "" +msgstr "Usando TestPyPI com Twine" #: ../source/guides/using-testpypi.rst:26 msgid "" "You can upload your distributions to TestPyPI using :ref:`twine` by " "specifying the ``--repository`` flag" msgstr "" +"Você pode enviar suas distribuições para TestPyPI usando :ref:`twine` " +"especificando o sinalizador ``--repository``" #: ../source/guides/using-testpypi.rst:33 msgid "" @@ -7226,16 +8739,22 @@ msgid "" "``sampleproject`` is the name of your project that you uploaded. It may take " "a minute or two for your project to appear on the site." msgstr "" +"Você pode ver se o seu pacote foi enviado com sucesso navegando para a URL " +"``https://test.pypi.org/project/`` onde ``projetoexemplo`` é " +"o nome do seu projeto que você enviou. O seu projeto pode demorar um ou dois " +"minutos para aparecer no site." #: ../source/guides/using-testpypi.rst:39 msgid "Using TestPyPI with pip" -msgstr "" +msgstr "Usando TestPyPI com pip" #: ../source/guides/using-testpypi.rst:41 msgid "" "You can tell pip to download packages from TestPyPI instead of PyPI by " "specifying the ``--index-url`` flag" msgstr "" +"Você pode dizer ao pip para baixar pacotes do TestPyPI, em vez d0 PyPI, " +"especificando o sinalizador ``--index-url``" #: ../source/guides/using-testpypi.rst:56 msgid "" @@ -7243,16 +8762,21 @@ msgid "" "specify ``--extra-index-url`` to point to PyPI. This is useful when the " "package you're testing has dependencies:" msgstr "" +"Se você quiser permitir que pip também extraia outros pacotes de PyPI, você " +"pode especificar ``--extra-index-url`` para apontar para PyPI. Isso é útil " +"quando o pacote que você está testando tem dependências:" #: ../source/guides/using-testpypi.rst:73 msgid "Setting up TestPyPI in :file:`.pypirc`" -msgstr "" +msgstr "Configurando TestPyPI no :file:`.pypirc`" #: ../source/guides/using-testpypi.rst:75 msgid "" "If you want to avoid entering your username, you can configure TestPyPI in " "your :file:`$HOME/.pypirc`:" msgstr "" +"Se você quiser evitar de ter que inserir seu nome de usuário, pode " +"configurar o TestPyPI em seu :file:`$HOME/.pypirc`:" #: ../source/index.rst:3 ../source/key_projects.rst:181 msgid "Python Packaging User Guide" @@ -7263,10 +8787,12 @@ msgid "" "The Python Packaging User Guide (PyPUG) is a collection of tutorials and " "guides for packaging Python software." msgstr "" +"O Guia de Usuário para Empacotamento de Python (PyPUG) é uma coleção de " +"tutoriais e guias para empacotar software Python." #: ../source/index.rst:5 msgid "python, packaging, guide, tutorial" -msgstr "" +msgstr "python, packaging, guide, tutorial, empacotamento, guia" #: ../source/index.rst:24 msgid "" @@ -7274,28 +8800,38 @@ msgid "" "references to help you distribute and install Python packages with modern " "tools." msgstr "" +"Seja bem-vindo(a) ao *Guia de Usuário para Empacotamento de Python*, uma " +"coleção de tutoriais e referências para lhe ajudar a distribuir e instalar " +"pacotes Python com ferramentas modernas." #: ../source/index.rst:28 msgid "" "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. " "We happily accept any :doc:`contributions and feedback `. 😊" msgstr "" +"Este guia é mantido no `GitHub`_ pela `Python Packaging Authority`_. " +"Aceitamos quaisquer :doc:`contribuições e feedback `. 😊" #: ../source/index.rst:36 msgid "Get started" -msgstr "" +msgstr "Primeiros passos" #: ../source/index.rst:38 msgid "" "Essential tools and concepts for working within the Python development " "ecosystem are covered in our :doc:`tutorials/index` section:" msgstr "" +"Ferramentas e conceitos essenciais para trabalhar dentro do ecossistema de " +"desenvolvimento do Python são abordados em nossa seção de :doc:`tutorials/" +"index`:" #: ../source/index.rst:41 msgid "" "To learn how to install packages, see the :doc:`tutorial on installing " "packages `" msgstr "" +"Para saber como instalar pacotes, veja o :doc:`tutorial sobre como instalar " +"pacotes `" #: ../source/index.rst:43 msgid "" @@ -7303,33 +8839,45 @@ msgid "" "the :doc:`tutorial on managing application dependencies `" msgstr "" +"Para saber como gerenciar dependências em um projeto controlador por versão, " +"veja o :doc:`tutorial sobre como gerenciar dependências de aplicações " +"`" #: ../source/index.rst:45 msgid "" "To learn how to package and distribute your projects, see the :doc:`tutorial " "on packaging and distributing `" msgstr "" +"Para saber como empacotar e distribuir seus projetos, veja o :doc:`tutorial " +"sobre como empacotar e distribuir `" #: ../source/index.rst:47 msgid "" "To get an overview of packaging options for Python libraries and " "applications, see the :doc:`Overview of Python Packaging `" msgstr "" +"Para obter uma visão geral das opções de empacotamento para bibliotecas e " +"aplicações Python , veja a :doc:`Visão geral de empacotamento no Python " +"`" #: ../source/index.rst:52 msgid "Learn more" -msgstr "" +msgstr "Saiba mais" #: ../source/index.rst:54 msgid "" "Beyond our :doc:`tutorials/index`, this guide has several other resources:" msgstr "" +"Além de nossos :doc:`tutorials/index`, este guia possui vários outros " +"recursos:" #: ../source/index.rst:56 msgid "" "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/" "installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." msgstr "" +"A seção :doc:`guides/index` para passos a passos, tal como :doc:`guides/" +"installing-using-linux-tools` ou :doc:`guides/packaging-binary-extensions`." #: ../source/index.rst:58 msgid "" @@ -7337,36 +8885,45 @@ msgid "" "as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-" "vs-easy-install`." msgstr "" +"A seção :doc:`discussions/index` para referências detalhadas sobre tópicos " +"como :doc:`discussions/deploying-python-applications` ou :doc:`discussions/" +"pip-vs-easy-install`." #: ../source/index.rst:60 msgid "" "The :doc:`specifications/index` section for packaging interoperability " "specifications." msgstr "" +"A seção :doc:`specifications/index` para especificações de " +"interoperabilidade de empacotamento." #: ../source/index.rst:62 msgid "" "Additionally, there is a list of :doc:`other projects ` " "maintained by members of the Python Packaging Authority." msgstr "" +"Além disso, há uma lista de :doc:`outros projetos ` mantidos " +"por membros da Python Packaging Authority." #: ../source/key_projects.rst:6 msgid "Project Summaries" -msgstr "" +msgstr "Resumos de projetos" #: ../source/key_projects.rst:8 msgid "" "Summaries and links for the most relevant projects in the space of Python " "installation and packaging." msgstr "" +"Resumos e links para os projetos mais relevantes no espaço de instalação e " +"empacotamento do Python." #: ../source/key_projects.rst:14 msgid "PyPA Projects" -msgstr "" +msgstr "Projetos do PyPA" #: ../source/key_projects.rst:19 msgid "bandersnatch" -msgstr "" +msgstr "bandersnatch" #: ../source/key_projects.rst:21 msgid "" @@ -7374,6 +8931,9 @@ msgid "" "github.com/pypa/bandersnatch>`__ | `PyPI `__" msgstr "" +"`Issues `__ | `GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:25 msgid "" @@ -7382,10 +8942,15 @@ msgid "" "and latency on package downloads (especially in the context of automated " "tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." msgstr "" +"``bandersnatch`` é um cliente de espelhamento do PyPI projetado para criar " +"de forma eficiente um espelho completo do conteúdo do PyPI. Assim, as " +"organizações economizam largura de banda e latência nos downloads de pacotes " +"(especialmente no contexto de testes automatizados) e evitam o carregamento " +"excessivo da Content Delivery Network (CDN) do PyPI." #: ../source/key_projects.rst:35 msgid "build" -msgstr "" +msgstr "build" #: ../source/key_projects.rst:37 msgid "" @@ -7393,16 +8958,21 @@ msgid "" "pypa/build/issues>`__ | `GitHub `__ | `PyPI " "`__" msgstr "" +"`Documentação `__ | `Issues `__ | `GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:42 msgid "" "``build`` is a :pep:`517` compatible Python package builder. It provides a " "CLI to build packages, as well as a Python API." msgstr "" +"``build`` é um construtor de pacotes Python compatível com a :pep:`517`. Ele " +"fornece uma CLI para construir pacotes, bem como uma API Python." #: ../source/key_projects.rst:49 msgid "cibuildwheel" -msgstr "" +msgstr "cibuildwheel" #: ../source/key_projects.rst:51 msgid "" @@ -7412,6 +8982,11 @@ msgid "" "`Discussions `__ | " "`Discord #cibuildwheel `__" msgstr "" +"`Documentação `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | " +"`Discussões `__ | `Discord " +"#cibuildwheel `__" #: ../source/key_projects.rst:58 msgid "" @@ -7419,10 +8994,13 @@ msgid "" "all common platforms and Python versions on most CI systems. Also see :ref:" "`multibuild`." msgstr "" +"``cibuildwheel`` é um pacote Python que constrói :term:`wheels ` para " +"todas as plataformas comuns e versões Python na maioria dos sistemas CI. " +"Veja também :ref:`multibuild`." #: ../source/key_projects.rst:64 msgid "distlib" -msgstr "" +msgstr "distlib" #: ../source/key_projects.rst:66 msgid "" @@ -7430,6 +9008,10 @@ msgid "" "pypa/distlib/issues?status=new&status=open>`__ | `Bitbucket `__ | `PyPI `__" msgstr "" +"`Documentação `__ | `Issues `__ | `Bitbucket " +"`__ | `PyPI `__" #: ../source/key_projects.rst:71 msgid "" @@ -7441,6 +9023,13 @@ msgid "" "interoperability, resolve dependencies, manage package resources, and do " "other similar functions." msgstr "" +"``distlib`` é uma biblioteca que implementa funções de baixo nível " +"relacionadas ao empacotamento e distribuição de software Python. ``distlib`` " +"implementa várias PEPs relevantes (padrões de proposta de aprimoramento do " +"Python) e é útil para desenvolvedores de ferramentas de empacotamento de " +"terceiros para fazer e enviar :term:`distribuições ` " +"binária e fonte, alcançar interoperabilidade, resolver dependências, " +"gerenciar recursos de pacote e executar outras funções semelhantes." #: ../source/key_projects.rst:80 msgid "" @@ -7451,10 +9040,16 @@ msgid "" "standards and fall into the subset of packages that are incompatible with " "those standards." msgstr "" +"Ao contrário do projeto :ref:`packaging` mais estrito (abaixo), que " +"implementa especificamente padrões modernos de interoperabilidade de pacotes " +"Python, ``distlib`` também tenta fornecer comportamentos de fallback " +"razoáveis quando solicitados a lidar com pacotes legados e metadados " +"anteriores à interoperabilidade moderna padrões e se enquadram no " +"subconjunto de pacotes que são incompatíveis com esses padrões." #: ../source/key_projects.rst:90 msgid "packaging" -msgstr "" +msgstr "empacotamento" #: ../source/key_projects.rst:92 msgid "" @@ -7462,11 +9057,16 @@ msgid "" "packaging/issues>`__ | `GitHub `__ | " "`PyPI `__" msgstr "" +"`Documentação `__ | `Issues `__ | `GitHub `__ | " +"`PyPI `__" #: ../source/key_projects.rst:97 msgid "" "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." msgstr "" +"Utilitários básicos para o empacotamento do Python usado por :ref:`pip` e :" +"ref:`setuptools`." #: ../source/key_projects.rst:99 msgid "" @@ -7477,6 +9077,13 @@ msgid "" "distribution, and installation tools listed here often use its functionality " "to parse, discover, and otherwise handle dependency attributes." msgstr "" +"Os utilitários principais na biblioteca de empacotamento lidam com " +"manipulação de versão, especificadores, marcadores, requisitos, tags e " +"atributos e tarefas semelhantes para pacotes Python. A maioria dos usuários " +"Python confia nesta biblioteca sem precisar chamá-la explicitamente; os " +"desenvolvedores de outras ferramentas de empacotamento, distribuição e " +"instalação Python listadas aqui geralmente usam sua funcionalidade para " +"analisar, descobrir e, de outra forma, lidar com atributos de dependência." #: ../source/key_projects.rst:107 msgid "" @@ -7488,11 +9095,18 @@ msgid "" "reading of ambiguous metadata in cases where :ref:`packaging` will instead " "report on error." msgstr "" +"Este projeto foca especificamente na implementação dos padrões modernos de " +"interoperabilidade de pacotes Python definidos em :ref:`packaging-" +"specifications`, e irá relatar erros para pacotes legados suficientemente " +"antigos que são incompatíveis com esses padrões. Em contraste, o projeto :" +"ref:`distlib` é uma biblioteca mais permissiva que tenta fornecer uma " +"leitura plausível de metadados ambíguos em casos onde :ref:`packaging` irá " +"relatar um erro." #: ../source/key_projects.rst:119 #: ../source/specifications/platform-compatibility-tags.rst:85 msgid "pip" -msgstr "" +msgstr "pip" #: ../source/key_projects.rst:121 msgid "" @@ -7500,12 +9114,17 @@ msgid "" "pip/issues>`__ | `GitHub `__ | `PyPI `__" msgstr "" +"`Documentação `__ | `Issues `__ | `GitHub `__ | `PyPI " +"`__" #: ../source/key_projects.rst:126 msgid "" "The most popular tool for installing Python packages, and the one included " "with modern versions of Python." msgstr "" +"A ferramenta mais popular para instalação de pacotes Python e incluída nas " +"versões modernas do Python." #: ../source/key_projects.rst:129 msgid "" @@ -7514,10 +9133,14 @@ msgid "" "incorporated into a wide range of development workflows via its command-line " "interface (CLI)." msgstr "" +"Ele fornece os recursos básicos essenciais para localizar, baixar e instalar " +"pacotes do PyPI e outros índices de pacotes do Python e pode ser incorporado " +"em uma ampla gama de fluxos de trabalho de desenvolvimento por meio de sua " +"interface de linha de comando (CLI)." #: ../source/key_projects.rst:137 msgid "Pipenv" -msgstr "" +msgstr "Pipenv" #: ../source/key_projects.rst:139 msgid "" @@ -7525,6 +9148,9 @@ msgid "" "pipenv>`__ | `Issues `__ | `PyPI " "`__" msgstr "" +"`Documentação `__ | `Código-fonte `__ | `Issues `__ | " +"`PyPI `__" #: ../source/key_projects.rst:144 msgid "" @@ -7533,6 +9159,10 @@ msgid "" "`virtualenv` into one single toolchain. It features very pretty terminal " "colors." msgstr "" +"Pipenv é um projeto que visa trazer o melhor de todos os mundos de " +"empacotamento para o mundo Python. Ele agrega :ref:`Pipfile`, :ref:`pip` e :" +"ref:`virtualenv` em um único conjunto de ferramentas. Possui cores de " +"terminal muito bonitas." #: ../source/key_projects.rst:148 msgid "" @@ -7543,14 +9173,21 @@ msgid "" "and dependencies. It is used by Python users and system administrators, but " "has been less maintained since late 2018." msgstr "" +"O Pipenv visa ajudar os usuários a gerenciar ambientes, dependências e " +"pacotes importados na linha de comando. Ele também funciona bem no Windows " +"(que outras ferramentas muitas vezes não atendem), cria e verifica hashes de " +"arquivo, para garantir a conformidade com especificadores de dependência " +"bloqueados por hash e facilita a desinstalação de pacotes e dependências. " +"Ele é usado por usuários Python e administradores de sistema, mas tem menos " +"manutenção desde o final de 2018." #: ../source/key_projects.rst:159 msgid "Pipfile" -msgstr "" +msgstr "Pipfile" #: ../source/key_projects.rst:161 msgid "`Source `__" -msgstr "" +msgstr "`Código-fonte `__" #: ../source/key_projects.rst:163 msgid "" @@ -7558,22 +9195,30 @@ msgid "" "application-centric alternative to :ref:`pip`'s lower-level :file:" "`requirements.txt` file." msgstr "" +":file:`Pipfile` e sua irmã :file:`Pipfile.lock` são uma alternativa centrada " +"na aplicação de nível superior ao arquivo de baixo nível :file:`requirements." +"txt` do :ref:`pip`." #: ../source/key_projects.rst:170 msgid "pipx" -msgstr "" +msgstr "pipx" #: ../source/key_projects.rst:172 msgid "" "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" +"`Documentação `__ | `GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:176 msgid "" "pipx is a tool to install and run Python command-line applications without " "causing dependency conflicts with other packages installed on the system." msgstr "" +"pipx é uma ferramenta para instalar e executar aplicações de linha de " +"comando Python sem causar conflitos de dependência com outros pacotes " +"instalados no sistema." #: ../source/key_projects.rst:183 msgid "" @@ -7581,20 +9226,25 @@ msgid "" "com/pypa/python-packaging-user-guide/issues>`__ | `GitHub `__" msgstr "" +"`Documentação `__ | `Issues " +"`__ | `GitHub " +"`__" #: ../source/key_projects.rst:187 msgid "This guide!" -msgstr "" +msgstr "Este guia!" #: ../source/key_projects.rst:192 msgid "readme_renderer" -msgstr "" +msgstr "readme_renderer" #: ../source/key_projects.rst:194 msgid "" "`GitHub and docs `__ | `PyPI " "`__" msgstr "" +"`GitHub e documentação `__ | `PyPI " +"`__" #: ../source/key_projects.rst:197 msgid "" @@ -7604,10 +9254,16 @@ msgid "" "`twine`, as part of their release management process, to check that their " "package descriptions will properly display on PyPI." msgstr "" +"``readme_renderer`` é uma biblioteca que os desenvolvedores de pacote usam " +"para renderizar seus arquivos de documentação de usuário (README) no HTML a " +"partir de linguagens de marcação como Markdown ou reStructuredText. Os " +"desenvolvedores o chamam por conta própria ou via :ref:`twine`, como parte " +"de seu processo de gerenciamento de lançamento, para verificar se as " +"descrições de seus pacotes serão exibidas corretamente no PyPI." #: ../source/key_projects.rst:208 msgid "setuptools" -msgstr "" +msgstr "setuptools" #: ../source/key_projects.rst:210 msgid "" @@ -7615,6 +9271,9 @@ msgid "" "github.com/pypa/setuptools/issues>`__ | `GitHub `__ | `PyPI `__" msgstr "" +"`Documentação `__ | `Issues " +"`__ | `GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:215 msgid "" @@ -7623,16 +9282,23 @@ msgid "" "Python :term:`distributions `, especially ones that " "have dependencies on other packages." msgstr "" +"setuptools (que inclui ``easy_install``) é uma coleção de melhorias para os " +"distutils Python que permitem a você construir e distribuir mais facilmente :" +"term:`distribuições ` Python, especialmente aquelas " +"que possuem dependências de outros pacotes." #: ../source/key_projects.rst:220 msgid "" "`distribute`_ was a fork of setuptools that was merged back into setuptools " "(in v0.7), thereby making setuptools the primary choice for Python packaging." msgstr "" +"`distribute`_ era um fork do setuptools que foi mesclado no setuptools (na " +"v0.7), tornando assim setuptools a escolha primária para o empacotamento " +"Python." #: ../source/key_projects.rst:227 msgid "trove-classifiers" -msgstr "" +msgstr "trove-classifiers" #: ../source/key_projects.rst:229 msgid "" @@ -7640,6 +9306,9 @@ msgid "" "`__ | `PyPI `__" msgstr "" +"`Issues `__ | `GitHub " +"`__ | `PyPI `__" #: ../source/key_projects.rst:233 msgid "" @@ -7649,6 +9318,12 @@ msgid "" "metadata/#classifier-multiple-use>`_ so that users can better find projects " "that match their needs on the PyPI." msgstr "" +"trove-classifiers é a fonte canônica para `classificadores no PyPI `_, que os mantenedores de projetos usam para " +"`descrever sistematicamente seus projetos `_ para que os " +"usuários possam encontrar melhor os projetos que correspondem às suas " +"necessidades no PyPI." #: ../source/key_projects.rst:239 msgid "" @@ -7662,10 +9337,20 @@ msgid "" "the project hosts discussions on proposed classifiers and requests for new " "classifiers." msgstr "" +"O pacote trove-classifiers contém uma lista de classificadores válidos e " +"classificadores descontinuados (que são pareados com os classificadores que " +"os substituem). Use este pacote para validar classificadores usados em " +"pacotes destinados ao envio para o PyPI. Como esta lista de classificadores " +"é publicada como código, você pode instalá-la e importá-la, proporcionando " +"um fluxo de trabalho mais conveniente em comparação com a referência à " +"`lista publicada em PyPI `_. O `rastreador de " +"problemas `_ para o " +"projeto hospeda discussões sobre classificadores propostos e solicitações de " +"novos classificadores." #: ../source/key_projects.rst:253 msgid "twine" -msgstr "" +msgstr "twine" #: ../source/key_projects.rst:255 msgid "" @@ -7673,6 +9358,9 @@ msgid "" "com/pypa/twine/issues>`__ | `GitHub `__ | " "`PyPI `__" msgstr "" +"`Documentação `__ | `Issues " +"`__ | `GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:260 msgid "" @@ -7682,10 +9370,15 @@ msgid "" "because it's the official PyPI upload tool, it's fast and secure, it's " "maintained, and it reliably works." msgstr "" +"Twine é a principal ferramenta que os desenvolvedores usam para enviar " +"pacotes para o índice de pacotes Python ou outros Python Package Index. É um " +"programa de linha de comando que passa arquivos de programa e metadados para " +"uma API web. Os desenvolvedores o usam porque é a ferramenta oficial de " +"envio do PyPI, é rápida e segura, é mantida e funciona de forma confiável." #: ../source/key_projects.rst:270 ../source/overview.rst:415 msgid "virtualenv" -msgstr "" +msgstr "virtualenv" #: ../source/key_projects.rst:272 msgid "" @@ -7693,6 +9386,9 @@ msgid "" "com/pypa/virtualenv/issues>`__ | `GitHub `__ | `PyPI `__" msgstr "" +"`Documentação `__ | `Issues `__ | `GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:277 msgid "" @@ -7704,16 +9400,26 @@ msgid "" "troubleshooting the virtual environments. For more information, see the " "section on :ref:`Creating and using Virtual Environments`." msgstr "" +"virtualenv é uma ferramenta que usa a variável de ambiente de caminho de " +"linha de comando para criar :term: `Ambientes Virtuais ` do Python, assim como :ref:`venv` faz. virtualenv fornece " +"funcionalidade adicional, em comparação com :ref:`venv`, oferecendo suporte " +"ao Python 2.7 e fornecendo recursos convenientes para configurar, manter, " +"duplicar e solucionar problemas de ambientes virtuais. Para obter mais " +"informações, consulte a seção sobre :ref:`Creating and using Virtual " +"Environments`." #: ../source/key_projects.rst:290 msgid "Warehouse" -msgstr "" +msgstr "Warehouse" #: ../source/key_projects.rst:292 msgid "" "`Docs `__ | `Issues `__ | `GitHub `__" msgstr "" +"`Documentação `__ | `Issues `__ | `GitHub `__" #: ../source/key_projects.rst:296 msgid "" @@ -7721,10 +9427,13 @@ msgid "" "hosted at `pypi.org `_. The default source for :ref:`pip` " "downloads." msgstr "" +"A base de código atual que alimenta o :term:`Python Package Index (PyPI)`. " +"Está hospedado em `pypi.org `_. A fonte padrão para " +"downloads do :ref:`pip`." #: ../source/key_projects.rst:304 msgid "wheel" -msgstr "" +msgstr "wheel" #: ../source/key_projects.rst:306 msgid "" @@ -7732,6 +9441,9 @@ msgid "" "com/pypa/wheel/issues>`__ | `GitHub `__ | " "`PyPI `__" msgstr "" +"`Documentação `__ | `Issues " +"`__ | `GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:311 msgid "" @@ -7739,6 +9451,10 @@ msgid "" "extension for creating :term:`wheel distributions `. Additionally, " "it offers its own command line utility for creating and installing wheels." msgstr "" +"Primeiramente, o projeto wheel oferece a extensão ``bdist_wheel`` do :ref:" +"`setuptools` para criar :term:`distribuições wheel `. Além disso, " +"oferece seu próprio utilitário de linha de comando para criar e instalar " +"wheels." #: ../source/key_projects.rst:315 msgid "" @@ -7748,14 +9464,20 @@ msgid "" "check metadata for compliance, and repair the wheel and metadata to properly " "link and include external shared libraries in a package." msgstr "" +"Veja também `auditwheel `__, uma " +"ferramenta que os desenvolvedores de pacotes usam para verificar e corrigir " +"pacotes Python que eles estão fazendo no formato de roda binária. Ele " +"fornece funcionalidade para descobrir dependências, verificar a conformidade " +"dos metadados e corrigir wheel e os metadados para vincular e incluir " +"bibliotecas externas compartilhadas em um pacote." #: ../source/key_projects.rst:324 msgid "Non-PyPA Projects" -msgstr "" +msgstr "Projetos não-PyPA" #: ../source/key_projects.rst:329 msgid "bento" -msgstr "" +msgstr "bento" #: ../source/key_projects.rst:331 msgid "" @@ -7763,6 +9485,9 @@ msgid "" "cournape/Bento/issues>`__ | `GitHub `__ | " "`PyPI `__" msgstr "" +"`Documentação `__ | `Issues `__ | `GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:336 msgid "" @@ -7770,10 +9495,14 @@ msgid "" "alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's " "philosophy is reproducibility, extensibility and simplicity (in that order)." msgstr "" +"Bento é uma solução de ferramenta de empacotamento para software Python, " +"direcionada como uma alternativa ao :ref:`distutils`, :ref:`setuptools `, " +"etc. A filosofia do Bento é reprodutibilidade, extensibilidade e " +"simplicidade (nesta ordem)." #: ../source/key_projects.rst:344 msgid "buildout" -msgstr "" +msgstr "buildout" #: ../source/key_projects.rst:346 msgid "" @@ -7781,6 +9510,9 @@ msgid "" "launchpad.net/zc.buildout>`__ | `PyPI `__ | `GitHub `__" msgstr "" +"`Documentação `__ | `Issues `__ | `PyPI `__ | `GitHub `__" #: ../source/key_projects.rst:351 msgid "" @@ -7789,14 +9521,18 @@ msgid "" "based. It lets you create a buildout configuration and reproduce the same " "software later." msgstr "" +"Buildout é um sistema de construção baseado em Python para criar, montar e " +"distribuir aplicativos de várias partes, algumas das quais podem ser não " +"baseadas em Python. Ele permite que você crie uma configuração de buildout e " +"reproduza o mesmo software posteriormente." #: ../source/key_projects.rst:358 msgid "conda" -msgstr "" +msgstr "conda" #: ../source/key_projects.rst:360 msgid "`Docs `__" -msgstr "" +msgstr "`Documentação `__" #: ../source/key_projects.rst:362 msgid "" @@ -7806,6 +9542,11 @@ msgid "" "aimed at the scientific community, and in particular on Windows where the " "installation of binary extensions is often difficult." msgstr "" +"conda é a ferramenta de gerenciamento de pacotes para as instalações do " +"`Anaconda `__ Python . Anaconda Python " +"é uma distribuição do `Anaconda, Inc `__ " +"voltada especificamente para a comunidade científica, e em particular no " +"Windows onde a instalação de extensões binárias é frequentemente difícil ." #: ../source/key_projects.rst:369 msgid "" @@ -7813,6 +9554,10 @@ msgid "" "but provides many of their combined features in terms of package management, " "virtual environment management and deployment of binary extensions." msgstr "" +"Conda é uma ferramenta completamente separada de :ref:`pip`, virtualenv e " +"wheel, mas fornece muitos de seus recursos combinados em termos de " +"gerenciamento de pacotes, gerenciamento de ambiente virtual e implantação de " +"extensões binárias." #: ../source/key_projects.rst:373 msgid "" @@ -7826,16 +9571,27 @@ msgid "" "Python packages installable by conda by first fetching them from PyPI and " "modifying their metadata." msgstr "" +"O Conda não instala pacotes do PyPI e pode instalar apenas a partir dos " +"repositórios oficiais do Anaconda, ou anaconda.org (um local para pacotes " +"*conda* contribuídos pelo usuário), ou um servidor de pacotes local (por " +"exemplo, intranet). No entanto, observe que :ref:`pip` pode ser instalado e " +"trabalhar lado a lado com o conda para gerenciar :term:`distribuições " +"` do PyPI. Além disso, `conda skeleton `__ é uma ferramenta para fazer pacotes Python instaláveis " +"pelo conda primeiro obtendo-os em PyPI e modificando seus metadados." #: ../source/key_projects.rst:386 msgid "devpi" -msgstr "" +msgstr "devpi" #: ../source/key_projects.rst:388 msgid "" "`Docs `__ | `Issues `__ | `PyPI `__" msgstr "" +"`Documentação `__ | `Issues `__ | `PyPI `__" #: ../source/key_projects.rst:392 msgid "" @@ -7844,16 +9600,23 @@ msgid "" "activities with Python. devpi also provides a browsable and searchable web " "interface." msgstr "" +"devpi apresenta um poderoso servidor compatível com PyPI e cache de proxy " +"PyPI com uma ferramenta de linha de comando complementar para conduzir " +"atividades de empacotamento, teste e lançamento com Python. devpi também " +"fornece uma interface web navegável e pesquisável." #: ../source/key_projects.rst:401 msgid "flit" -msgstr "" +msgstr "flit" #: ../source/key_projects.rst:403 msgid "" "`Docs `__ | `Issues `__ | `PyPI `__" msgstr "" +"`Documentação `__ | `Issues `__ | `PyPI `__" #: ../source/key_projects.rst:407 msgid "" @@ -7862,6 +9625,11 @@ msgid "" "packaging. Flit can generate a configuration file to quickly set up a simple " "project, build source distributions and wheels, and upload them to PyPI." msgstr "" +"O Flit fornece uma maneira simples de enviar pacotes e módulos puro Python " +"para o PyPI. Ele se concentra em `facilitar as coisas fáceis `_ para empacotar. O Flit pode gerar um arquivo de configuração " +"para configurar rapidamente um projeto simples, construir distribuições " +"fonte e wheels e enviá-los para PyPI." #: ../source/key_projects.rst:412 msgid "" @@ -7870,10 +9638,15 @@ msgid "" "upload them to PyPI. Flit requires Python 3, but you can use it to " "distribute modules for Python 2, so long as they can be imported on Python 3." msgstr "" +"Flit usa ``pyproject.toml`` para configurar um projeto. O Flit não depende " +"de ferramentas como :ref:`setuptools` para construir distribuições, ou :ref:" +"`twine` para enviá-las ao PyPI. O Flit requer Python 3, mas você pode usá-lo " +"para distribuir módulos para Python 2, desde que eles possam ser importados " +"no Python 3." #: ../source/key_projects.rst:422 msgid "enscons" -msgstr "" +msgstr "enscons" #: ../source/key_projects.rst:424 msgid "" @@ -7881,6 +9654,9 @@ msgid "" "bitbucket.org/dholth/enscons/issues>`__ | `PyPI `__" msgstr "" +"`Código-fonte `__ | `Issues " +"`__ | `PyPI `__" #: ../source/key_projects.rst:428 msgid "" @@ -7893,16 +9669,27 @@ msgid "" "sdists that can be automatically built by :ref:`pip`, and wheels that are " "independent of enscons." msgstr "" +"Enscons é uma ferramenta de empacotamento Python baseada em `SCons`_. Ele " +"cria distribuições de código-fonte compatíveis com :ref:`pip` e wheels sem " +"usar distutils ou setuptools, incluindo distribuições com extensões C. " +"Enscons tem uma arquitetura e filosofia diferente de :ref:`distutils`. Em " +"vez de adicionar recursos de compilação a um sistema de empacotamento " +"Python, enscons adiciona empacotamento Python a um sistema de construção de " +"propósito geral. Enscons ajuda você a construir sdists que podem ser " +"construídos automaticamente por :ref:`pip`, e wheels que são independentes " +"de enscons." #: ../source/key_projects.rst:443 msgid "Hashdist" -msgstr "" +msgstr "Hashdist" #: ../source/key_projects.rst:445 msgid "" "`Docs `__ | `GitHub `__" msgstr "" +"`Documentação `__ | `GitHub " +"`__" #: ../source/key_projects.rst:448 msgid "" @@ -7914,16 +9701,26 @@ msgid "" "distribution stateless, cached, and branchable. It is used by some " "researchers but has been lacking in maintenance since 2016." msgstr "" +"Hashdist é uma biblioteca para construir distribuições de software que não " +"dependem do root. Hashdist está tentando ser \"o preferido do Debian para os " +"casos em que a tecnologia Debian não funciona\". A melhor maneira para " +"Pythonistas pensarem sobre Hashdist pode ser um híbrido mais poderoso de :" +"ref:`virtualenv` e :ref:`buildout`. Ele tem como objetivo resolver o " +"problema de instalação de software científico e tornar a distribuição de " +"pacotes sem estado, com cache e com capacidade de distribuição. É usado por " +"alguns pesquisadores, mas não tem manutenção desde 2016." #: ../source/key_projects.rst:460 msgid "hatch" -msgstr "" +msgstr "hatch" #: ../source/key_projects.rst:462 msgid "" "`GitHub and Docs `__ | `PyPI `__" msgstr "" +"`GitHub e documentação `__ | `PyPI `__" #: ../source/key_projects.rst:465 msgid "" @@ -7933,14 +9730,20 @@ msgid "" "publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload " "packages to PyPI, and :ref:`pip` to download and install packages." msgstr "" +"Hatch é uma ferramenta de linha de comando unificada destinada a gerenciar " +"convenientemente dependências e isolamento de ambiente para desenvolvedores " +"Python. Os desenvolvedores de pacotes Python usam o Hatch para configurar, " +"criar versões, especificar dependências e publicar pacotes no PyPI. Por " +"baixo do capô, ele usa :ref:`twine` para enviar pacotes para PyPI, e :ref:" +"`pip` para baixar e instalar pacotes." #: ../source/key_projects.rst:475 msgid "multibuild" -msgstr "" +msgstr "multibuild" #: ../source/key_projects.rst:477 msgid "`GitHub `__" -msgstr "" +msgstr "`GitHub `__" #: ../source/key_projects.rst:479 msgid "" @@ -7948,16 +9751,21 @@ msgid "" "`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :" "ref:`cibuildwheel`." msgstr "" +"Multibuild é um conjunto de scripts de CI para construir e testar Python :" +"term:`wheels ` para Linux, macOS e (menos flexível) Windows. Veja " +"também :ref:`cibuildwheel`." #: ../source/key_projects.rst:485 msgid "pex" -msgstr "" +msgstr "pex" #: ../source/key_projects.rst:487 msgid "" "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" +"`Documentação `__ | `GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:491 msgid "" @@ -7967,16 +9775,24 @@ msgid "" "with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are " "designed to make deployment of Python applications as simple as ``cp``." msgstr "" +"pex é uma biblioteca e ferramenta para gerar arquivos :file:`.pex` (Python " +"EXecutable), ambientes autônomos Python no espírito de :ref:`virtualenv`. Os " +"arquivos :file:`.pex` são apenas arquivos zip cuidadosamente construídos com " +"um ``#!/usr/bin/env python`` e um :file:`__main__.py` especial, e são " +"projetados para fazer a implantação de aplicações Python tão simples quanto " +"``cp``." #: ../source/key_projects.rst:500 msgid "pip-tools" -msgstr "" +msgstr "pip-tools" #: ../source/key_projects.rst:502 msgid "" "`GitHub and Docs `__ | `PyPI " "`__" msgstr "" +"`GitHub e documentação `__ | `PyPI " +"`__" #: ../source/key_projects.rst:505 msgid "" @@ -7988,16 +9804,26 @@ msgid "" "their program, update all dependencies (a feature :ref:`pip` currently does " "not provide), and create layers of constraints for the program to obey." msgstr "" +"pip-tools é um conjunto de ferramentas destinadas aos administradores de " +"sistema Python e gerentes de lançamento que desejam manter suas compilações " +"determinísticas e, ao mesmo tempo, manter-se atualizado com as novas versões " +"de suas dependências. Os usuários podem especificar a liberação particular " +"de suas dependências por meio de hash, fazer convenientemente uma lista " +"devidamente formatada de requisitos de informações em outras partes de seu " +"programa, atualizar todas as dependências (um recurso :ref:`pip` atualmente " +"não fornece) e criar camadas de restrições para o programa obedecer." #: ../source/key_projects.rst:517 msgid "piwheels" -msgstr "" +msgstr "piwheels" #: ../source/key_projects.rst:519 msgid "" "`Website `__ | `Docs `__ | `GitHub `__" msgstr "" +"`Site `__ | `Documentação `__ | `GitHub `__" #: ../source/key_projects.rst:523 msgid "" @@ -8006,16 +9832,22 @@ msgid "" "that are optimized for installation onto Raspberry Pi computers. Raspberry " "Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." msgstr "" +"piwheels é um site, e o software que o sustenta, que busca pacotes de " +"distribuição de código-fonte do PyPI e os compila em wheels binários que são " +"otimizadas para instalação em computadores Raspberry Pi. O Raspberry Pi OS " +"pré-configura pip para usar piwheels.org como um índice adicional para PyPI." #: ../source/key_projects.rst:532 msgid "poetry" -msgstr "" +msgstr "poetry" #: ../source/key_projects.rst:534 msgid "" "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" +"`Documentação `__ | `GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:538 msgid "" @@ -8026,10 +9858,17 @@ msgid "" "speed users' experience of installation and dependency resolution by locally " "caching metadata about dependencies." msgstr "" +"poetry é uma ferramenta de linha de comando para lidar com a instalação de " +"dependências e isolamento, bem como construção e empacotamento de pacotes " +"Python. Ele usa ``pyproject.toml`` e, ao invés de depender da funcionalidade " +"do resolvedor no :ref:`pip`, fornece seu próprio resolvedor de dependências. " +"Ele tenta acelerar a experiência dos usuários de instalação e resolução de " +"dependências, armazenando localmente em cache os metadados sobre as " +"dependências." #: ../source/key_projects.rst:548 msgid "pypiserver" -msgstr "" +msgstr "pypiserver" #: ../source/key_projects.rst:550 msgid "" @@ -8037,6 +9876,9 @@ msgid "" "`GitHub `__ | `PyPI `__" msgstr "" +"`Documentação `__ | `GitHub `__ | `PyPI " +"`__" #: ../source/key_projects.rst:554 msgid "" @@ -8047,10 +9889,16 @@ msgid "" "publicly. Organizations who use pypiserver usually download packages both " "from pypiserver and from PyPI." msgstr "" +"pypiserver é um aplicativo minimalista que serve como um índice de pacotes " +"privado Python dentro das organizações, implementando uma API simples e uma " +"interface de navegador. Você pode enviar pacotes privados usando ferramentas " +"de envio padrão, e os usuários podem baixar e instalá-los com :ref:`pip`, " +"sem publicá-los publicamente. As organizações que usam o pypiserver " +"geralmente baixam pacotes tanto do pypiserver quanto do PyPI." #: ../source/key_projects.rst:564 msgid "scikit-build" -msgstr "" +msgstr "scikit-build" #: ../source/key_projects.rst:566 msgid "" @@ -8058,6 +9906,9 @@ msgid "" "github.com/scikit-build/scikit-build/>`__ | `PyPI `__" msgstr "" +"`Documentação `__ | `GitHub " +"`__ | `PyPI `__" #: ../source/key_projects.rst:570 msgid "" @@ -8070,16 +9921,27 @@ msgid "" "large projects, the user can install `ninja `__ (also available on PyPI)." msgstr "" +"Scikit-build é um gerador de sistema de construção aprimorado para extensões " +"C/C++/Fortran/Cython do CPython que se integra com :ref:`setuptools`, :ref:" +"`wheel` e :ref:`pip`. Ele usa internamente `cmake `__ (disponível em PyPI) para fornecer melhor suporte para " +"compiladores adicionais, sistemas de construção, compilação cruzada e " +"localização de dependências e seus requisitos de construção associados. Para " +"acelerar e paralelizar a construção de grandes projetos, o usuário pode " +"instalar o `ninja `__ (também disponível no " +"PyPI)." #: ../source/key_projects.rst:582 msgid "shiv" -msgstr "" +msgstr "shiv" #: ../source/key_projects.rst:584 msgid "" "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" +"`Documentação `__ | `GitHub `__ | `PyPI `__" #: ../source/key_projects.rst:588 msgid "" @@ -8088,6 +9950,10 @@ msgid "" "Its primary goal is making distributing Python applications and command line " "tools fast & easy." msgstr "" +"shiv é um utilitário de linha de comando para construir *zipapps* Python " +"totalmente autocontidos conforme descrito na :pep:`441`, mas com todas as " +"suas dependências incluídas. Seu objetivo principal é tornar a distribuição " +"Python de aplicações e ferramentas de linha de comando rápida e fácil." #: ../source/key_projects.rst:598 msgid "" @@ -8096,6 +9962,10 @@ msgid "" "sc/2015/3723/00/2807623.pdf>`__ | `Slides `__" msgstr "" +"`Documentação `__ | `GitHub `__ | `Artigo `__ | `Slides `__" #: ../source/key_projects.rst:603 msgid "" @@ -8107,16 +9977,25 @@ msgid "" "building high performance scientific applications on clusters and " "supercomputers." msgstr "" +"Um gerenciador de pacotes flexível projetado para oferecer suporte a várias " +"versões, configurações, plataformas e compiladores. O Spack é como o " +"Homebrew, mas os pacotes são escritos em Python e parametrizados para " +"permitir fácil troca de compiladores, versões de bibliotecas, opções de " +"construção, etc. Arbitrariamente, muitas versões de pacotes podem coexistir " +"no mesmo sistema. O Spack foi projetado para construir rapidamente " +"aplicativos científicos de alto desempenho em clusters e supercomputadores." #: ../source/key_projects.rst:611 msgid "" "Spack is not in PyPI (yet), but it requires no installation and can be used " "immediately after cloning from GitHub." msgstr "" +"O Spack não está no PyPI (ainda), mas não requer instalação e pode ser usado " +"imediatamente após a clonagem do GitHub." #: ../source/key_projects.rst:617 msgid "zest.releaser" -msgstr "" +msgstr "zest.releaser" #: ../source/key_projects.rst:619 msgid "" @@ -8124,6 +10003,9 @@ msgid "" "github.com/zestsoftware/zest.releaser/>`__ | `PyPI `__" msgstr "" +"`Documentação `__ | `GitHub " +"`__ | `PyPI `__" #: ../source/key_projects.rst:623 msgid "" @@ -8132,20 +10014,27 @@ msgid "" "automate incrementing package version numbers, updating changelogs, tagging " "releases in source control, and uploading new packages to PyPI." msgstr "" +"``zest.releaser`` é uma ferramenta de lançamento de pacote Python que " +"fornece uma camada de abstração sobre :ref:`twine`. Os desenvolvedores " +"Python usam ``zest.releaser`` para automatizar o incremento de números de " +"versão de pacote, atualizando changelogs, marcando lançamentos no controle " +"de fontes e enviando novos pacotes para PyPI." #: ../source/key_projects.rst:630 msgid "Standard Library Projects" -msgstr "" +msgstr "Projetos de biblioteca padrão" #: ../source/key_projects.rst:635 msgid "ensurepip" -msgstr "" +msgstr "ensurepip" #: ../source/key_projects.rst:637 msgid "" "`Docs `__ | `Issues " "`__" msgstr "" +"`Documentação `__ | " +"`Issues `__" #: ../source/key_projects.rst:640 msgid "" @@ -8154,22 +10043,30 @@ msgid "" "environment. In most cases, end users won't use this module, but rather it " "will be used during the build of the Python distribution." msgstr "" +"Um pacote na Biblioteca Padrão do Python que fornece suporte para preparar " +"o :ref:`pip` em uma instalação existente do Python ou em ambiente virtual. " +"Na maioria dos casos, os usuários finais não usarão este módulo, mas em vez " +"disso, ele será usado durante a construção da distribuição Python." #: ../source/key_projects.rst:649 msgid "distutils" -msgstr "" +msgstr "distutils" #: ../source/key_projects.rst:651 msgid "" "`Docs `__ | `Issues " "`__" msgstr "" +"`Documentação `__ | " +"`Issues `__" #: ../source/key_projects.rst:654 msgid "" "The original Python packaging system, added to the standard library in " "Python 2.0." msgstr "" +"O sistema de empacotamento original do Python, adicionado à biblioteca " +"padrão no Python 2.0." #: ../source/key_projects.rst:657 msgid "" @@ -8181,16 +10078,27 @@ msgid "" "entry point declarations), it also provides a consistent build interface and " "feature set across all supported Python versions." msgstr "" +"Devido aos desafios de manter um sistema de empacotamento onde as " +"atualizações de recursos estão fortemente acopladas às atualizações de tempo " +"de execução da linguagem, o uso direto de :ref:`distutils` agora é " +"ativamente desencorajado, com :ref:`Setuptools` sendo o substituto " +"preferido. :ref:`Setuptools` não apenas fornece recursos que o :ref:" +"`distutils` simples não oferece (como declarações de dependência e " +"declarações de ponto de entrada), ele também fornece uma interface de " +"construção consistente e conjunto de recursos em todas as versões Python " +"suportadas ." #: ../source/key_projects.rst:670 msgid "venv" -msgstr "" +msgstr "venv" #: ../source/key_projects.rst:672 msgid "" "`Docs `__ | `Issues `__" msgstr "" +"`Documentação `__ | `Issues " +"`__" #: ../source/key_projects.rst:675 msgid "" @@ -8199,630 +10107,724 @@ msgid "" "information, see the section on :ref:`Creating and using Virtual " "Environments`." msgstr "" +"Um pacote na Biblioteca Padrão do Python (começando com Python 3.3) para " +"criar :term:`Ambientes Virtuais `. Para obter mais " +"informações, consulte a seção :ref:`Creating and using Virtual Environments`." #: ../source/news.rst:2 msgid "News" -msgstr "" +msgstr "Notícias" #: ../source/news.rst:5 msgid "September 2019" -msgstr "" +msgstr "Setembro de 2019" #: ../source/news.rst:6 msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" msgstr "" +"Adicionado um guia sobre como publicar dists por meio do GitHub Actions. (:" +"pr:`647`)" #: ../source/news.rst:9 msgid "August 2019" -msgstr "" +msgstr "Agosto de 2019" #: ../source/news.rst:10 msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" -msgstr "" +msgstr "Atualizado para usar :file:`python3 -m` ao instalar pipx. (:pr:`631`)" #: ../source/news.rst:13 msgid "July 2019" -msgstr "" +msgstr "Julho de 2019" #: ../source/news.rst:14 msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" -msgstr "" +msgstr "Todos os números PEP marcados com função :pep:. (:pr:`629`)" #: ../source/news.rst:15 msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" msgstr "" +"Atualizada a versão do Sphinx e removido intersphinx para pypa.io. (:pr:" +"`625`)" #: ../source/news.rst:16 msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" -msgstr "" +msgstr "Mencionado :file:`find_namespace_packages`. (:pr:`622`)" #: ../source/news.rst:17 msgid "Updated directory layout examples for consistency. (:pr:`611`)" msgstr "" +"Atualizados os exemplos de layout de diretório para consistência. (:pr:`611`)" #: ../source/news.rst:18 msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" -msgstr "" +msgstr "Atualizado o link do Bandersnatch para GitHub. (:pr:`623`)" #: ../source/news.rst:21 msgid "June 2019" -msgstr "" +msgstr "Junho de 2019" #: ../source/news.rst:22 msgid "Fixed some typos. (:pr:`620`)" -msgstr "" +msgstr "Corrigidos de alguns erros de escrita. (:pr:`620`)" #: ../source/news.rst:25 msgid "May 2019" -msgstr "" +msgstr "Maio de 2019" #: ../source/news.rst:26 msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" msgstr "" +"Adicionado o uso de :file:`python_requires` ao tutorial de empacotamento. (:" +"pr:`613`)" #: ../source/news.rst:27 msgid "Added a MANIFEST.in guide page. (:pr:`609`)" -msgstr "" +msgstr "Adiciondo uma página de guia sobre MANIFEST.in. (:pr:`609`)" #: ../source/news.rst:30 msgid "April 2019" -msgstr "" +msgstr "Abril de 2019" #: ../source/news.rst:31 msgid "" "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" msgstr "" +"Adicionada uma menção para :file:`shiv` na seção de projetos-chave. (:pr:" +"`608`)" #: ../source/news.rst:32 msgid "Reduced emphasis on virtualenv. (:pr:`606`)" -msgstr "" +msgstr "Reduzida a ênfase em virtualenv. (:pr:`606`)" #: ../source/news.rst:35 msgid "March 2019" -msgstr "" +msgstr "Março de 2019" #: ../source/news.rst:36 msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" msgstr "" +"Movida a opção de versão do guia de única fonte para Python 3. (:pr:`605`)" #: ../source/news.rst:37 msgid "Covered RTD details for contributing. (:pr:`600`)" -msgstr "" +msgstr "Cobertos detalhes de RTD para contribuição. (:pr:`600`)" #: ../source/news.rst:40 msgid "February 2019" -msgstr "" +msgstr "Fevereiro de 2019" #: ../source/news.rst:41 msgid "" "Elaborate upon the differences between the tutorial and the real packaging " "process. (:pr:`602`)" msgstr "" +"Explicada as diferenças entre o tutorial e o processo de empacotamento real. " +"(:pr:`602`)" #: ../source/news.rst:42 msgid "Added instructions to install Python CLI applications. (:pr:`594`)" msgstr "" +"Adicionadas as instruções para instalar aplicações CLI do Python. (:pr:`594`)" #: ../source/news.rst:45 msgid "January 2019" -msgstr "" +msgstr "Janeiro de 2019" #: ../source/news.rst:46 msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" -msgstr "" +msgstr "Adicionado :file:`--no-deps` ao tutorial de empacotamento. (:pr:`593`)" #: ../source/news.rst:47 msgid "Updated Sphinx and Nox. (:pr:`591`)" -msgstr "" +msgstr "Atualizado Sphinx e Nox. (:pr:`591`)" #: ../source/news.rst:48 msgid "Referenced Twine from Python3. (:pr:`581`)" -msgstr "" +msgstr "Referenciado o Twine do Python3. (:pr:`581`)" #: ../source/news.rst:51 msgid "December 2018" -msgstr "" +msgstr "Dezembro de 2018" #: ../source/news.rst:52 msgid "No programmers in the office!" -msgstr "" +msgstr "Sem programadores no escritório!" #: ../source/news.rst:55 msgid "November 2018" -msgstr "" +msgstr "Novembro de 2018" #: ../source/news.rst:56 msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" msgstr "" +"Removido o link da página de destino para o guia de migração do PyPI. (:pr:" +"`575`)" #: ../source/news.rst:57 msgid "Changed bumpversion to bump2version. (:pr:`572`)" -msgstr "" +msgstr "Alterado bumpversion para bump2version. (:pr:`572`)" #: ../source/news.rst:58 msgid "Added single-sourcing package version example. (:pr:`573`)" -msgstr "" +msgstr "Adicionado exemplo de versão de pacote de única fonte. (:pr:`573`)" #: ../source/news.rst:59 msgid "Added a guide for creating documentation. (:pr:`568`)" -msgstr "" +msgstr "Adicionado um guia para a criação de documentação. (:pr:`568`)" #: ../source/news.rst:62 msgid "October 2018" -msgstr "" +msgstr "Outubro de 2018" #: ../source/news.rst:63 msgid "Updated Nox package name. (:pr:`566`)" -msgstr "" +msgstr "Atualizado o nome do pacote Nox. (:pr:`566`)" #: ../source/news.rst:64 msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" -msgstr "" +msgstr "Mencionadas extensões Sphinx nos guias. (:pr:`562`)" #: ../source/news.rst:67 msgid "September 2018" -msgstr "" +msgstr "Setembro de 2018" #: ../source/news.rst:68 msgid "Added a section on checking RST markup. (:pr:`554`)" -msgstr "" +msgstr "Adicionada uma seção sobre como verificar a marcação RST. (:pr:`554`)" #: ../source/news.rst:69 msgid "Updated user installs page. (:pr:`558`)" -msgstr "" +msgstr "Atualizada página de instalações do usuário. (:pr:`558`)" #: ../source/news.rst:70 msgid "Updated Google BigQuery urls. (:pr:`556`)" -msgstr "" +msgstr "Atualizadas as URLs do Google BigQuery. (:pr:`556`)" #: ../source/news.rst:71 msgid "Replaced tar command with working command. (:pr:`552`)" -msgstr "" +msgstr "Substituído o comando tar pelo comando de trabalho. (:pr:`552`)" #: ../source/news.rst:72 msgid "" "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" msgstr "" +"Alterado para aspas duplas no pip install SomeProject==1.4. (:pr:`550`)" #: ../source/news.rst:75 msgid "August 2018" -msgstr "" +msgstr "Agosto de 2018" #: ../source/news.rst:76 msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" msgstr "" +"Removida a recomendação de armazenar senhas em texto não criptografado. (:pr:" +"`546`)" #: ../source/news.rst:77 msgid "" "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" msgstr "" +"Movida a Visão geral para um ponto baseado em tarefas junto com os outros. (:" +"pr:`540`)" #: ../source/news.rst:78 msgid "Updated Python version supported by virtualenv. (:pr:`538`)" -msgstr "" +msgstr "Atualizada a versão do Python compatível com virtualenv. (:pr:`538`)" #: ../source/news.rst:79 msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" -msgstr "" +msgstr "Adicionado esboço/rascunho da nova página de Visão geral. (:pr:`519`)" #: ../source/news.rst:82 msgid "July 2018" -msgstr "" +msgstr "Julho de 2018" #: ../source/news.rst:84 msgid "Improved binary extension docs. (:pr:`531`)" -msgstr "" +msgstr "Melhorada a documentação de extensão binária. (:pr:`531`)" #: ../source/news.rst:85 msgid "Added scikit-build to key projects. (:pr:`530`)" -msgstr "" +msgstr "Adicionado o scikit-build aos principais projetos. (:pr:`530`)" #: ../source/news.rst:88 msgid "June 2018" -msgstr "" +msgstr "Junho de 2018" #: ../source/news.rst:90 msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" msgstr "" +"Corrigidas as categorias de interoperabilidade de PEP para pypa.io. (:pr:" +"`527`)" #: ../source/news.rst:91 msgid "Updated Markdown descriptions explanation. (:pr:`522`)" -msgstr "" +msgstr "Atualizada a explicação das descrições de Markdown. (:pr:`522`)" #: ../source/news.rst:94 msgid "May 2018" -msgstr "" +msgstr "Maio de 2018" #: ../source/news.rst:96 msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" msgstr "" +"Adicionadas notas sobre problemas com Provides-Dist e Obsoletes-Dist. (:pr:" +"`513`)" #: ../source/news.rst:97 msgid "" "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" msgstr "" +"Removido o aviso de desatualizado sobre a mistura da versão Python com o " +"Pipenv. (:pr:`501`)" #: ../source/news.rst:98 msgid "Simplified packaging tutorial. (:pr:`498`)" -msgstr "" +msgstr "Simplificado o tutorial de empacotamento. (:pr:`498`)" #: ../source/news.rst:99 msgid "Updated Windows users instructions for clarity. (:pr:`493`)" msgstr "" +"Atualizadas as instruções do usuário Windows para maior clareza. (:pr:`493`)" #: ../source/news.rst:100 msgid "Updated the license section description for completeness. (:pr:`492`)" msgstr "" +"Atualizada a descrição da seção da licença para integridade. (:pr:`492`)" #: ../source/news.rst:101 msgid "Added specification-style document to contributing section. (:pr:`489`)" msgstr "" +"Adicionado documento de estilo de especificação à seção de contribuição. (:" +"pr:`489`)" #: ../source/news.rst:102 msgid "Added documentation types to contributing guide. (:pr:`485`)" -msgstr "" +msgstr "Adicionados tipos de documentação ao guia de contribuição. (:pr:`485`)" #: ../source/news.rst:105 msgid "April 2018" -msgstr "" +msgstr "Abril de 2018" #: ../source/news.rst:107 msgid "Added README guide. (:pr:`461`)" -msgstr "" +msgstr "Adicionado guia de README. (:pr:`461`)" #: ../source/news.rst:108 msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" msgstr "" +"Atualizadas as instruções e status para o lançamento do PyPI. (:pr:`475`)" #: ../source/news.rst:109 msgid "Added instructions for Warehouse. (:pr:`471`)" -msgstr "" +msgstr "Adicionadas instruções para o Warehouse. (:pr:`471`)" #: ../source/news.rst:110 msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" -msgstr "" +msgstr "Removidas referências de GPG do tutorial de publicação. (:pr:`466`)" #: ../source/news.rst:111 msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" -msgstr "" +msgstr "Adicionado 'O que há em cada Python 3.4–3.6?'. (:pr:`468`)" #: ../source/news.rst:112 msgid "Added a guide for phasing out Python versions. (:pr:`459`)" -msgstr "" +msgstr "Adicionado um guia para descontinuar as versões do Python. (:pr:`459`)" #: ../source/news.rst:113 msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" -msgstr "" +msgstr "Tornada padrão a variante GFM do Description-Content-Type. (:pr:`462`)" #: ../source/news.rst:116 msgid "March 2018" -msgstr "" +msgstr "Março de 2018" #: ../source/news.rst:118 msgid "Updated \"installing scientific packages\". (:pr:`455`)" -msgstr "" +msgstr "Atualizado \"instalando pacotes científicos\". (:pr:`455`)" #: ../source/news.rst:119 msgid "" "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" msgstr "" +"Adicionado :file:`long_description_content_type` para seguir a PEP 556. (:pr:" +"`457`)" #: ../source/news.rst:120 msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" msgstr "" +"Esclarecido um classificador de descrição longa em pypi.org. (:pr:`456`)" #: ../source/news.rst:121 msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" msgstr "" +"Atualizada a especificação dos metadados principais para seguir a PEP 556. (:" +"pr:`412`)" #: ../source/news.rst:124 msgid "February 2018" -msgstr "" +msgstr "Fevereiro de 2018" #: ../source/news.rst:126 msgid "" "Added python3-venv and python3-pip to Debian installation instructions. (:pr:" "`445`)" msgstr "" +"Adicionados python3-venv e python3-pip às instruções de instalação do " +"Debian. (:pr:`445`)" #: ../source/news.rst:127 msgid "Updated PyPI migration info. (:pr:`439`)" -msgstr "" +msgstr "Informações de migração do PyPI atualizadas. (:pr:`439`)" #: ../source/news.rst:128 msgid "" "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" msgstr "" +"Adicionado um aviso sobre o gerenciamento de várias versões com pipenv. (:pr:" +"`430`)" #: ../source/news.rst:129 msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" msgstr "" +"Adicionado exemplo de vários e-mails aos metadados principais. (:pr:`429`)" #: ../source/news.rst:130 msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" msgstr "" +"Adicionada explicação de \"legado\" em test.pypi.org/legacy. (:pr:`426`)" #: ../source/news.rst:133 msgid "January 2018" -msgstr "" +msgstr "Janeiro de 2018" #: ../source/news.rst:135 msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" msgstr "" +"Adicionado um link para a lista de classificadores do PyPI. (:pr:`425`)" #: ../source/news.rst:136 msgid "Updated README.rst explanation. (:pr:`419`)" -msgstr "" +msgstr "Atualizada uma explicação sobre README.rst. (:pr:`419`)" #: ../source/news.rst:139 msgid "December 2017" -msgstr "" +msgstr "Dezembro de 2017" #: ../source/news.rst:141 msgid "" "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" msgstr "" +"Substituído :file:`~` por :file:`$HOME` nos guias e tutoriais. (:pr:`418`)" #: ../source/news.rst:142 msgid "Noted which fields can be used with environment markers. (:pr:`416`)" msgstr "" +"Adicionada nota sobre quais campos podem ser usados com marcadores de " +"ambiente. (:pr:`416`)" #: ../source/news.rst:143 msgid "Updated Requires-Python section. (:pr:`414`)" -msgstr "" +msgstr "Atualizada a seção Requires-Python. (:pr:`414`)" #: ../source/news.rst:144 msgid "Added news page. (:pr:`404`)" -msgstr "" +msgstr "Adicionada página de notícias. (:pr:`404`)" #: ../source/news.rst:147 msgid "November 2017" -msgstr "" +msgstr "Novembro de 2017" #: ../source/news.rst:149 msgid "" "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" msgstr "" +"Introduzido um novo tutorial de gerenciamento de dependências baseado no " +"Pipenv. (:pr:`402`)" #: ../source/news.rst:150 msgid "" "Updated the *Single Sourcing Package Version* tutorial to reflect pip's " "current strategy. (:pr:`400`)" msgstr "" +"Atualizado o tutorial *Versão de pacote de fonte única* para refletir a " +"estratégia atual do pip. (:pr:`400`)" #: ../source/news.rst:152 msgid "" "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:" "`398`)" msgstr "" +"Adicionada documentação sobre o argumento ``py_modules`` ao ``setup``. (:pr:" +"`398`)" #: ../source/news.rst:153 msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" -msgstr "" +msgstr "Simplificadas as palavras da seção :file:`manifest.in`. (:pr:`395`)" #: ../source/news.rst:156 msgid "October 2017" -msgstr "" +msgstr "Outubro de 2017" #: ../source/news.rst:158 msgid "" "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" msgstr "" +"Adicionada uma especificação para o arquivo :file:`entry_points.txt`. (:pr:" +"`398`)" #: ../source/news.rst:159 msgid "" "Created a new guide for managing packages using ``pip`` and ``virtualenv``. " "(:pr:`385`)" msgstr "" +"Criado um novo guia para gerenciamento de pacotes usando ``pip`` e " +"``virtualenv``. (:pr:`385`)" #: ../source/news.rst:160 msgid "Split the specifications page into multiple pages. (:pr:`386`)" -msgstr "" +msgstr "Dividida a página de especificações em várias páginas. (:pr:`386`)" #: ../source/news.rst:163 msgid "September 2017" -msgstr "" +msgstr "Setembro de 2017" #: ../source/news.rst:165 msgid "" "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:" "`379`)" msgstr "" +"Incentivado o uso de ``readme_renderer`` validar o :file:`README.rst`. (:pr:" +"`379`)" #: ../source/news.rst:167 msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" -msgstr "" +msgstr "Recomendado o uso da opção ``--user-base``. (:pr:`374`)" #: ../source/news.rst:170 msgid "August 2017" -msgstr "" +msgstr "Agosto de 2017" #: ../source/news.rst:172 msgid "" "Added a new, experimental tutorial on installing packages using ``Pipenv``. " "(:pr:`369`)" msgstr "" +"Adicionado um novo tutorial experimental sobre a instalação de pacotes " +"usando ``Pipenv``. (:pr:`369`)" #: ../source/news.rst:173 msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" -msgstr "" +msgstr "Adicionado um novo guia sobre como usar o ``TestPyPI``. (:pr:`366`)" #: ../source/news.rst:174 msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" -msgstr "" +msgstr "Adicionado :file:`pypi.org` como um termo. (:pr:`365`)" #: ../source/news.rst:177 msgid "July 2017" -msgstr "" +msgstr "Julho de 2017" #: ../source/news.rst:179 msgid "Added ``flit`` to the key projects list. (:pr:`358`)" -msgstr "" +msgstr "Adicionado ``flit`` à lista de projetos principais. (:pr:`358`)" #: ../source/news.rst:180 msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" -msgstr "" +msgstr "Adicionado ``enscons`` à lista de projetos principais. (:pr:`357`)" #: ../source/news.rst:181 msgid "" "Updated this guide's ``readme`` with instructions on how to build the guide " "locally. (:pr:`356`)" msgstr "" +"Atualizado o ``readme`` deste guia com instruções sobre como contruir o guia " +"localmente. (:pr:`356`)" #: ../source/news.rst:182 msgid "" "Made the new ``TestPyPI`` URL more visible, adding note to homepage about " "pypi.org. (:pr:`354`)" msgstr "" +"Melhorada a visibilidade da nova URL do ``TestPyPI``, adicionando uma nota à " +"página inicial sobre pypi.org. (:pr:`354`)" #: ../source/news.rst:183 msgid "" "Added a note about the removal of the explicit registration API. (:pr:`347`)" msgstr "" +"Adicionada uma nota sobre a remoção da API de registro explícito. (:pr:`347`)" #: ../source/news.rst:186 msgid "June 2017" -msgstr "" +msgstr "Junho de 2017" #: ../source/news.rst:188 msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" msgstr "" +"Adicionado um documento sobre a migração de envios para :file:`PyPI.org`. (:" +"pr:`339`)" #: ../source/news.rst:189 msgid "Added documentation for ``python_requires``. (:pr:`338`)" -msgstr "" +msgstr "Adicionada documentação para ``python_requires``. (:pr:`338`)" #: ../source/news.rst:190 msgid "" "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:" "pr:`335`)" msgstr "" +"Adicionada uma nota sobre a migração do PyPI no tutorial *Recomendações de " +"ferramentas*. (:pr:`335`)" #: ../source/news.rst:191 msgid "" "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" msgstr "" +"Adicionada uma nota de que o :file:`manifest.in` não afeta os wheels. (:pr:" +"`332`)" #: ../source/news.rst:192 msgid "Added a license section to the distributing guide. (:pr:`331`)" -msgstr "" +msgstr "Adicionada uma seção de licença ao guia de distribuição. (:pr:`331`)" #: ../source/news.rst:193 msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" -msgstr "" +msgstr "Expandida a seção sobre o argumento ``name``. (:pr:`329`)" #: ../source/news.rst:194 msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" -msgstr "" +msgstr "Ajustada a página inicial. (:pr:`327`, :pr:`326`, :pr:`324`)" #: ../source/news.rst:195 msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" -msgstr "" +msgstr "Atualizado para Sphinx 1.6.2. (:pr:`323`)" #: ../source/news.rst:196 msgid "Switched to the PyPA theme. (:pr:`305`)" -msgstr "" +msgstr "Trocado para o tema do PyPA. (:pr:`305`)" #: ../source/news.rst:197 msgid "Re-organized the documentation into the new structure. (:pr:`318`)" -msgstr "" +msgstr "Reorganizada a documentação na nova estrutura. (:pr:`318`)" #: ../source/news.rst:200 msgid "May 2017" -msgstr "" +msgstr "Maio de 2017" #: ../source/news.rst:202 msgid "" "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" msgstr "" +"Adicionada documentação para o campo ``Description-Content-Type``. (:pr:" +"`258`)" #: ../source/news.rst:203 msgid "Added contributor and style guide. (:pr:`307`)" -msgstr "" +msgstr "Adicionado guia de contribuidor e de estilo. (:pr:`307`)" #: ../source/news.rst:204 msgid "" "Documented ``pip`` and ``easy_install``'s differences for per-project " "indexes. (:pr:`233`)" msgstr "" +"Documentadas as diferenças entre ``pip`` e ``easy_install`` para índices por " +"projeto. (:pr:`233`)" #: ../source/news.rst:207 msgid "April 2017" -msgstr "" +msgstr "Abril de 2017" #: ../source/news.rst:209 msgid "Added travis configuration for testing pull requests. (:pr:`300`)" msgstr "" +"Adicionada configuração de travis para testar pull requests. (:pr:`300`)" #: ../source/news.rst:210 msgid "" "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:" "`299`)" msgstr "" +"Mencionado o requisito do pacote ``wheel`` para a criação de wheels (:pr:" +"`299`)" #: ../source/news.rst:211 msgid "" "Removed the ``twine register`` reference in the *Distributing Packages* " "tutorial. (:pr:`271`)" msgstr "" +"Removida a referência a ``twine register`` no tutorial *Distribuindo " +"pacotes*. (:pr:`271`)" #: ../source/news.rst:212 msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" msgstr "" +"Adicionado um tópico sobre descoberta de plugins. (:pr:`294`, :pr:`296`)" #: ../source/news.rst:213 msgid "Added a topic on namespace packages. (:pr:`290`)" -msgstr "" +msgstr "Adicionado um tópico sobre pacotes de espaço de nomes. (:pr:`290`)" #: ../source/news.rst:214 msgid "" "Added documentation explaining prominently how to install ``pip`` in ``/usr/" "local``. (:pr:`230`)" msgstr "" +"Adicionada documentação explicando em destaque como instalar ``pip`` em ``/" +"usr/local``. (:pr:`230`)" #: ../source/news.rst:215 msgid "" "Updated development mode documentation to mention that order of local " "packages matters. (:pr:`208`)" msgstr "" +"Atualizada a documentação do modo de desenvolvimento para mencionar que a " +"ordem dos pacotes locais é importante. (:pr:`208`)" #: ../source/news.rst:216 msgid "" "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted " "projects (:pr:`239`)" msgstr "" +"Conversão de link do readthedocs para sua migração ``.org`` -> ``.io`` para " +"projetos hospedados (:pr:`239`)" #: ../source/news.rst:217 msgid "" "Swaped order of :file:`setup.py` arguments for the upload command, as order " "is significant. (:pr:`260`)" msgstr "" +"Trocada a ordem dos argumentos do :file:`setup.py` para o comando de envio, " +"pois a ordem é significativa. (:pr:`260`)" #: ../source/news.rst:219 msgid "" "Explained how to install from unsupported sources using a helper " "application. (:pr:`289`)" msgstr "" +"Explicado como instalar de fontes não suportadas usando uma aplicação " +"auxiliar. (:pr:`289`)" #: ../source/news.rst:223 msgid "March 2017" -msgstr "" +msgstr "Março de 2017" #: ../source/news.rst:225 msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" -msgstr "" +msgstr "Coberto ``manylinux1`` em *wheels de plataforma*. (:pr:`283`)" #: ../source/news.rst:228 msgid "February 2017" -msgstr "" +msgstr "Fevereiro de 2017" #: ../source/news.rst:230 msgid "Added :pep:`518`. (:pr:`281`)" -msgstr "" +msgstr "Adicionada a :pep:`518`. (:pr:`281`)" #: ../source/overview.rst:3 msgid "An Overview of Packaging for Python" -msgstr "" +msgstr "Uma visão geral de empacotamento para Python" #: ../source/overview.rst:7 msgid "" @@ -8830,6 +10832,10 @@ msgid "" "many ways. You can build web sites or industrial robots or a game for your " "friends to play, and much more, all using the same core technology." msgstr "" +"Como uma linguagem de programação de propósito geral, Python foi projetado " +"para ser usado de várias maneiras. Você pode construir sites ou robôs " +"industriais ou um jogo para seus amigos jogarem e muito mais, todos usando a " +"mesma tecnologia básica." #: ../source/overview.rst:12 msgid "" @@ -8839,6 +10845,11 @@ msgid "" "before writing code, but this process does wonders for avoiding future " "headaches." msgstr "" +"A flexibilidade do Python é o porquê do primeiro passo em cada projeto " +"Python deva ser pensar sobre o público do projeto e o ambiente " +"correspondente onde o projeto será executado. Pode parecer estranho pensar " +"em empacotamento antes de escrever o código, mas esse processo faz " +"maravilhas para evitar dores de cabeça futuras." #: ../source/overview.rst:18 msgid "" @@ -8846,16 +10857,22 @@ msgid "" "Python's plethora of packaging options. Read on to choose the best " "technology for your next project." msgstr "" +"Esta visão geral fornece uma árvore de decisão de propósito geral para " +"raciocinar sobre a abundância de opções de empacotamento do Python. Continue " +"lendo para escolher a melhor tecnologia para seu próximo projeto." #: ../source/overview.rst:26 msgid "Thinking about deployment" -msgstr "" +msgstr "Pensando sobre a implantação" #: ../source/overview.rst:28 msgid "" "Packages exist to be installed (or *deployed*), so before you package " "anything, you'll want to have some answers to the deployment questions below:" msgstr "" +"Os pacotes existem para serem instalados (ou *implantados*, *deployed*), " +"portanto, antes de empacotar qualquer coisa, você vai querer ter algumas " +"respostas para as perguntas de implantação abaixo:" #: ../source/overview.rst:32 msgid "" @@ -8863,17 +10880,24 @@ msgid "" "developers doing software development, operations people in a datacenter, or " "a less software-savvy group?" msgstr "" +"Quem são os usuários do seu software? Seu software será instalado por outros " +"desenvolvedores que fazem o desenvolvimento de software, pessoas de " +"operações em um datacenter ou um grupo com menos experiência em software?" #: ../source/overview.rst:35 msgid "" "Is your software intended to run on servers, desktops, mobile clients " "(phones, tablets, etc.), or embedded in dedicated devices?" msgstr "" +"O seu software deve ser executado em servidores, desktops, clientes móveis " +"(telefones, tablets, etc.) ou incorporado em dispositivos dedicados?" #: ../source/overview.rst:37 msgid "" "Is your software installed individually, or in large deployment batches?" msgstr "" +"O seu software é instalado individualmente ou em grandes lotes de " +"implantação?" #: ../source/overview.rst:39 msgid "" @@ -8883,10 +10907,15 @@ msgid "" "overview will guide you to the packaging technologies best suited to your " "project." msgstr "" +"O empacotamento tem tudo a ver com o ambiente de destino e a experiência de " +"implantação. Existem muitas respostas para as perguntas acima e cada " +"combinação de circunstâncias tem suas próprias soluções. Com essas " +"informações, a visão geral a seguir o guiará para as tecnologias de " +"empacotamento mais adequadas ao seu projeto." #: ../source/overview.rst:46 msgid "Packaging Python libraries and tools" -msgstr "" +msgstr "Empacotando bibliotecas e ferramentas Python" #: ../source/overview.rst:48 msgid "" @@ -8895,6 +10924,10 @@ msgid "" "code to developers, which you can read about in :doc:`guides/distributing-" "packages-using-setuptools`." msgstr "" +"Você deve ter ouvido falar sobre PyPI, ``setup.py`` e arquivos ``wheel``. " +"Estas são apenas algumas das ferramentas que o ecossistema Python oferece " +"para distribuir código Python para desenvolvedores, sobre as quais você pode " +"ler em :doc:`guides/distributing-packages-using-setuptools`." #: ../source/overview.rst:53 msgid "" @@ -8903,10 +10936,15 @@ msgid "" "to package Python for a non-technical audience and/or a production setting, " "skip ahead to :ref:`packaging-applications`." msgstr "" +"As abordagens a seguir para empacotamento são destinadas a bibliotecas e " +"ferramentas usadas pelo público técnico em um ambiente de desenvolvimento. " +"Se você está procurando maneiras de empacotar Python para um público não " +"técnico e/ou uma configuração de produção, pule para :ref:`packaging-" +"applications`." #: ../source/overview.rst:59 msgid "Python modules" -msgstr "" +msgstr "Módulos Python" #: ../source/overview.rst:61 msgid "" @@ -8914,6 +10952,10 @@ msgid "" "redistributed and reused. You will also need to ensure it's written for the " "right version of Python, and only relies on the standard library." msgstr "" +"Um arquivo Python, desde que dependa apenas da biblioteca padrão, pode ser " +"redistribuído e reutilizado. Você também precisará garantir que ele foi " +"escrito para a versão correta do Python e depende apenas da biblioteca " +"padrão." #: ../source/overview.rst:66 msgid "" @@ -8924,6 +10966,12 @@ msgid "" "`boltons `_." msgstr "" +"Isso é ótimo para compartilhar scripts e trechos simples entre pessoas que " +"possuem versões Python compatíveis (como via e-mail, StackOverflow ou gists " +"do GitHub). Existem até algumas bibliotecas Python inteiras que oferecem " +"isso como uma opção, como `bottle.py `_ e " +"`boltons `_." #: ../source/overview.rst:73 msgid "" @@ -8931,10 +10979,13 @@ msgid "" "files, need additional libraries, or need a specific version of Python, " "hence the options below." msgstr "" +"No entanto, esse padrão não será escalonado para projetos que consistem em " +"vários arquivos, precisam de bibliotecas adicionais ou precisam de uma " +"versão específica do Python, daí as opções abaixo." #: ../source/overview.rst:78 msgid "Python source distributions" -msgstr "" +msgstr "Distribuições fonte Python" #: ../source/overview.rst:80 msgid "" @@ -8942,6 +10993,9 @@ msgid "" "a directory structure. Any directory containing Python files can comprise " "an :term:`Import Package`." msgstr "" +"Se o seu código consiste em vários arquivos Python, ele geralmente é " +"organizado em uma estrutura de diretório. Qualquer diretório contendo " +"arquivos Python pode incluir um :term:`Pacote de Importação`." #: ../source/overview.rst:84 msgid "" @@ -8951,6 +11005,11 @@ msgid "" "to get incomplete transfers, and harder to guarantee code integrity at the " "destination." msgstr "" +"Como os pacotes consistem em vários arquivos, eles são mais difíceis de " +"distribuir. A maioria dos protocolos tem suporte à transferência de apenas " +"um arquivo por vez (quando foi a última vez que você clicou em um link e ele " +"baixou vários arquivos?). É mais fácil obter transferências incompletas e " +"mais difícil garantir a integridade do código no destino." #: ../source/overview.rst:90 msgid "" @@ -8959,6 +11018,10 @@ msgid "" "use Python's native packaging tools to create a *source* :term:`Distribution " "Package`, or *sdist* for short." msgstr "" +"Contanto que seu código não contenha nada além de código puro Python, e você " +"saiba que seu ambiente de implantação tem suporte a sua versão de Python, " +"então você pode usar as ferramentas de empacotamento nativas do Python para " +"criar um :term:`Pacote de Distribuição` fonte, ou *sdist*." #: ../source/overview.rst:95 msgid "" @@ -8967,6 +11030,10 @@ msgid "" "depend on other Python packages, you can `go here to learn more `_." msgstr "" +"Os *sdists* do Python são arquivos compactados (arquivos ``.tar.gz``) " +"contendo um ou mais pacotes ou módulos. Se seu código for puro Python e você " +"depender apenas de outros pacotes Python, você pode `clicar aqui para saber " +"mais `_." #: ../source/overview.rst:100 msgid "" @@ -8976,6 +11043,12 @@ msgid "" "org/project/numpy>`_), you will need to use the format detailed in the next " "section, which also has many advantages for pure-Python libraries." msgstr "" +"Se você confiar em qualquer código não-Python ou pacotes não-Python (como " +"`libxml2 `_ no caso de `lxml " +"`_, ou bibliotecas BLAS no caso de `numpy " +"`_), você precisará usar o formato detalhado " +"no a próxima seção, que também tem muitas vantagens para bibliotecas puro " +"Python." #: ../source/overview.rst:107 msgid "" @@ -8985,6 +11058,10 @@ msgid "" "package, and so does `Pillow `_, an " "actively-maintained fork of PIL!" msgstr "" +"Python e PyPI oferecem suporte a várias distribuições, fornecendo diferentes " +"implementações do mesmo pacote. Por exemplo, a `distribuição PIL `_ não mantida, mas seminal fornece o pacote PIL, e " +"também o `Pillow `_, um fork do PIL!" #: ../source/overview.rst:114 msgid "" @@ -8992,10 +11069,13 @@ msgid "" "in replacement for PIL, just by changing your project's ``install_requires`` " "or ``requirements.txt``." msgstr "" +"Este superpoder de empacotamento do Python torna possível que o Pillow seja " +"um substituto imediato para o PIL, apenas alterando o ``install_requires`` " +"ou ``requirements.txt`` do seu projeto." #: ../source/overview.rst:119 msgid "Python binary distributions" -msgstr "" +msgstr "Distribuições binárias Python" #: ../source/overview.rst:121 msgid "" @@ -9003,6 +11083,9 @@ msgid "" "the software ecosystem, in particular libraries written in C, C++, Fortran, " "Rust, and other languages." msgstr "" +"Grande parte do poder prático do Python vem de sua capacidade de integração " +"com o ecossistema de software, em particular bibliotecas escritas em C, C +" +"+, Fortran, Rust e outras linguagens." #: ../source/overview.rst:125 msgid "" @@ -9013,6 +11096,12 @@ msgid "" "wheels because installation is always faster, so even pure-Python packages " "work better with wheels." msgstr "" +"Nem todos os desenvolvedores têm as ferramentas ou experiências certas para " +"construir esses componentes escritos nessas linguagens compiladas, então " +"Python criou o :term:`Wheel`, um formato de pacote projetado para enviar " +"bibliotecas com artefatos compilados. Na verdade, o instalador do pacote " +"Python, ``pip``, sempre prefere wheels porque a instalação é sempre mais " +"rápida, então mesmo os pacotes puro Python funcionam melhor com wheels." #: ../source/overview.rst:132 msgid "" @@ -9023,12 +11112,21 @@ msgid "" "archives together, *unless* you're creating artifacts for a very specific " "use case where you know the recipient only needs one or the other." msgstr "" +"As distribuições binárias são melhores quando vêm com distribuições de fonte " +"correspondentes. Mesmo que você não envie wheels do seu código para todos os " +"sistemas operacionais, ao enviar o sdist, você permite que usuários de " +"outras plataformas ainda o construam por conta própria. O padrão é publicar " +"arquivos sdist e wheel juntos, *a menos* que você esteja criando artefatos " +"para um caso de uso muito específico, onde sabe que o destinatário só " +"precisa de um ou de outro." #: ../source/overview.rst:140 msgid "" "Python and PyPI make it easy to upload both wheels and sdists together. Just " "follow the :doc:`tutorials/packaging-projects` tutorial." msgstr "" +"Python e PyPI facilitam o envio de wheels e sdists juntos. Basta seguir o " +"tutorial :doc:`tutorials/packaging-projects`." #: ../source/overview.rst:148 msgid "" @@ -9036,10 +11134,13 @@ msgid "" "Excerpted from `The Packaging Gradient (2017) `_." msgstr "" +"Bibliotecas embutidas recomendadas e tecnologias de empacotamento de " +"ferramentas do Python. Extraído de `The Packaging Gradient (2017) `_." #: ../source/overview.rst:155 msgid "Packaging Python applications" -msgstr "" +msgstr "Empacotando aplicações do Python" #: ../source/overview.rst:157 msgid "" @@ -9048,12 +11149,18 @@ msgid "" "target environments which have Python, and an audience who knows how to " "install Python packages." msgstr "" +"Até agora, discutimos apenas as ferramentas de distribuição nativas do " +"Python. Com base em nossa introdução, você estaria correto em inferir que " +"essas abordagens embutidas têm como alvo apenas ambientes que possuem Python " +"e um público que sabe como instalar pacotes Python." #: ../source/overview.rst:162 msgid "" "With the variety of operating systems, configurations, and people out there, " "this assumption is only safe when targeting a developer audience." msgstr "" +"Com a variedade de sistemas operacionais, configurações e pessoas por aí, " +"essa suposição só é segura quando se destina a um público de desenvolvedores." #: ../source/overview.rst:166 msgid "" @@ -9063,12 +11170,20 @@ msgid "" "technologies like `setuptools entry_points `_." msgstr "" +"O empacotamento nativo do Python é construído principalmente para distribuir " +"código reutilizável, chamado de bibliotecas, entre os desenvolvedores. Você " +"pode adicionar **ferramentas** ou aplicações básicas para desenvolvedores ao " +"pacote de biblioteca do Python, usando tecnologias como `entry_points do " +"setuptools `_." #: ../source/overview.rst:172 msgid "" "Libraries are building blocks, not complete applications. For distributing " "applications, there's a whole new world of technologies out there." msgstr "" +"Bibliotecas são blocos de construção, não aplicações completas. Para " +"distribuir aplicações, existe um novo mundo de tecnologias por aí." #: ../source/overview.rst:176 msgid "" @@ -9076,10 +11191,13 @@ msgid "" "to their dependencies on the target environment, so you can choose the right " "one for your project." msgstr "" +"As próximas seções organizam essas opções de pacote de aplicações de acordo " +"com suas dependências no ambiente de destino, para que você possa escolher o " +"certo para o seu projeto." #: ../source/overview.rst:181 msgid "Depending on a framework" -msgstr "" +msgstr "Dependendo de um framework" #: ../source/overview.rst:183 msgid "" @@ -9089,6 +11207,11 @@ msgid "" "frontends and mobile clients, are complex enough to target that a framework " "becomes more than a convenience." msgstr "" +"Alguns tipos de aplicações Python, como backends de sites e outros serviços " +"de rede, são comuns o suficiente para que tenham estruturas para permitir " +"seu desenvolvimento e empacotamento. Outros tipos de aplicações, como " +"frontends web dinâmicos e clientes móveis, são complexos o suficiente para " +"fazer com que uma estrutura se torne mais do que uma conveniência." #: ../source/overview.rst:189 msgid "" @@ -9098,16 +11221,24 @@ msgid "" "cases, you'll want to defer to your framework's packaging guide for the " "easiest and most reliable production experience." msgstr "" +"Em todos esses casos, faz sentido trabalhar de trás para frente, a partir da " +"história de empacotamento e implantação da estrutura. Algumas estruturas " +"incluem um sistema de implantação que envolve as tecnologias descritas no " +"restante do guia. Nesses casos, você desejará consultar o guia de " +"empacotamento de sua estrutura para obter a experiência de produção mais " +"fácil e confiável." #: ../source/overview.rst:195 msgid "" "If you ever wonder how these platforms and frameworks work under the hood, " "you can always read the sections beyond." msgstr "" +"Se você já se perguntou como essas plataformas e estruturas funcionam nos " +"bastidores, você sempre pode ler as seções seguintes." #: ../source/overview.rst:199 msgid "Service platforms" -msgstr "" +msgstr "Plataformas de serviço" #: ../source/overview.rst:201 msgid "" @@ -9115,27 +11246,31 @@ msgid "" "or Google App Engine, you are going to want to follow their respective " "packaging guides." msgstr "" +"Se estiver desenvolvendo para uma \"plataforma como serviço\" ou \"PaaS\", " +"como Heroku ou Google App Engine, você vai querer seguir seus respectivos " +"guias de empacotamento." #: ../source/overview.rst:205 msgid "" "`Heroku `_" msgstr "" +"`Heroku `_" #: ../source/overview.rst:206 msgid "`Google App Engine `_" -msgstr "" +msgstr "`Google App Engine `_" #: ../source/overview.rst:207 msgid "`PythonAnywhere `_" -msgstr "" +msgstr "`PythonAnywhere `_" #: ../source/overview.rst:208 msgid "`OpenShift `_" -msgstr "" +msgstr "`OpenShift `_" #: ../source/overview.rst:209 msgid "\"Serverless\" frameworks like `Zappa `_" -msgstr "" +msgstr "Frameworks \"serverless\" como `Zappa `_" #: ../source/overview.rst:211 msgid "" @@ -9143,16 +11278,23 @@ msgid "" "long as you follow their patterns. Most software does not fit one of these " "templates, hence the existence of all the other options below." msgstr "" +"Em todas essas configurações, a plataforma cuida do empacotamento e da " +"implantação, desde que você siga seus padrões. A maioria dos softwares não " +"se encaixa em um desses modelos, daí a existência de todas as outras opções " +"abaixo." #: ../source/overview.rst:216 msgid "" "If you're developing software that will be deployed to machines you own, " "users' personal computers, or any other arrangement, read on." msgstr "" +"Se você estiver desenvolvendo um software que será implantado em suas " +"máquinas, computadores pessoais de usuários ou qualquer outro arranjo, " +"continue lendo." #: ../source/overview.rst:220 msgid "Web browsers and mobile applications" -msgstr "" +msgstr "Navegadores web e aplicações móveis" #: ../source/overview.rst:222 msgid "" @@ -9160,28 +11302,34 @@ msgid "" "write a mobile app or web application frontend in Python. While the language " "may be familiar, the packaging and deployment practices are brand new." msgstr "" +"Os avanços constantes do Python estão levando-o a novos espaços. Hoje em " +"dia, você pode escrever uma aplicação móvel ou frontend de aplicação web no " +"Python. Embora a linguagem possa ser familiar, as práticas de empacotamento " +"e implantação são novas." #: ../source/overview.rst:227 msgid "" "If you're planning on releasing to these new frontiers, you'll want to check " "out the following frameworks, and refer to their packaging guides:" msgstr "" +"Se você está planejando lançar para essas novas fronteiras, convém verificar " +"as seguintes estruturas e consultar seus guias de empacotamento:" #: ../source/overview.rst:231 msgid "`Kivy `_" -msgstr "" +msgstr "`Kivy `_" #: ../source/overview.rst:232 msgid "`Beeware `_" -msgstr "" +msgstr "`Beeware `_" #: ../source/overview.rst:233 msgid "`Brython `_" -msgstr "" +msgstr "`Brython `_" #: ../source/overview.rst:234 msgid "`Flexx `_" -msgstr "" +msgstr "`Flexx `_" #: ../source/overview.rst:236 msgid "" @@ -9189,10 +11337,13 @@ msgid "" "about some of the technologies and techniques utilized by the frameworks " "above, continue reading below." msgstr "" +"Se você *não* está interessado em usar um framework ou plataforma, ou apenas " +"quer saber sobre algumas das tecnologias e técnicas utilizadas pelos " +"frameworks acima, continue lendo abaixo." #: ../source/overview.rst:241 msgid "Depending on a pre-installed Python" -msgstr "" +msgstr "Dependendo de um Python pré-instalado" #: ../source/overview.rst:243 msgid "" @@ -9202,24 +11353,31 @@ msgid "" "Python preexisting in your data centers or on the personal machines of " "developers and data scientists." msgstr "" +"Escolha um computador arbitrário e, dependendo do contexto, há uma boa " +"chance do Python já estar instalado. Incluído por padrão na maioria dos " +"sistemas operacionais Linux e Mac por muitos anos, você pode depender " +"razoavelmente do Python preexistente em seus datacenters ou nas máquinas " +"pessoais de desenvolvedores e cientistas de dados." #: ../source/overview.rst:249 msgid "Technologies which support this model:" -msgstr "" +msgstr "Tecnologias que têm suporte a este modelo:" #: ../source/overview.rst:251 msgid "`PEX `_ (Python EXecutable)" -msgstr "" +msgstr "`PEX `_ (Python EXecutable)" #: ../source/overview.rst:252 msgid "" "`zipapp `_ (does not help " "manage dependencies, requires Python 3.5+)" msgstr "" +"`zipapp `_ (não ajuda a " +"gerenciar dependências, requer Python 3.5+)" #: ../source/overview.rst:253 msgid "`shiv `_ (requires Python 3)" -msgstr "" +msgstr "`shiv `_ (requer Python 3)" #: ../source/overview.rst:255 msgid "" @@ -9227,6 +11385,9 @@ msgid "" "most on the target environment. Of course, this also makes for the smallest " "package, as small as single-digit megabytes, or even kilobytes." msgstr "" +"De todas as abordagens aqui, depender de um Python pré-instalado depende " +"mais do ambiente de destino. Claro, isso também contribui para o menor " +"pacote, tão pequeno quanto megabytes de um dígito, ou mesmo kilobytes." #: ../source/overview.rst:260 msgid "" @@ -9234,10 +11395,13 @@ msgid "" "size of our package, so the solutions here are roughly arranged by " "increasing size of output." msgstr "" +"Em geral, diminuir a dependência do sistema de destino aumenta o tamanho do " +"nosso pacote, portanto, as soluções aqui são organizadas de forma grosseira " +"pelo aumento do tamanho da saída." #: ../source/overview.rst:267 msgid "Depending on a separate software distribution ecosystem" -msgstr "" +msgstr "Dependendo de um ecossistema separado de distribuição de software" #: ../source/overview.rst:269 msgid "" @@ -9246,6 +11410,11 @@ msgid "" "\"app stores\", but even those focus on consumer applications and offer " "little for developers." msgstr "" +"Por um longo tempo, muitos sistemas operacionais, incluindo Mac e Windows, " +"não tinham gerenciamento de pacotes integrado. Apenas recentemente esses " +"sistemas operacionais ganharam as chamadas \"*app store*\", mas mesmo " +"aqueles se concentram em aplicações de consumo e oferecem pouco para os " +"desenvolvedores." #: ../source/overview.rst:274 msgid "" @@ -9259,44 +11428,61 @@ msgid "" "`_." msgstr "" +"Os desenvolvedores buscaram soluções por muito tempo e, nessa luta, surgiram " +"com suas próprias soluções de gerenciamento de pacotes, como o `Homebrew " +"`_. A alternativa mais relevante para desenvolvedores " +"Python é um ecossistema de pacotes chamado `Anaconda `_. O Anaconda é construído em torno " +"do Python e é cada vez mais comum em ambientes acadêmicos, analíticos e " +"outros ambientes orientados a dados, chegando até a ambientes orientados a " +"servidor `_." #: ../source/overview.rst:284 msgid "Instructions on building and publishing for the Anaconda ecosystem:" msgstr "" +"Instruções sobre como construir e publicar para o ecossistema do Anaconda:" #: ../source/overview.rst:286 msgid "" "`Building libraries and applications with conda `_" msgstr "" +"`Building libraries and applications with conda `_" #: ../source/overview.rst:287 msgid "" "`Transitioning a native Python package to Anaconda `_" msgstr "" +"`Transitioning a native Python package to Anaconda `_" #: ../source/overview.rst:289 msgid "" "A similar model involves installing an alternative Python distribution, but " "does not support arbitrary operating system-level packages:" msgstr "" +"Um modelo semelhante envolve a instalação de uma distribuição alternativa " +"Python, mas não oferece suporte a pacotes arbitrários em nível de sistema " +"operacional:" #: ../source/overview.rst:293 msgid "`Enthought Canopy `_" -msgstr "" +msgstr "`Enthought Canopy `_" #: ../source/overview.rst:294 msgid "`ActiveState ActivePython `_" -msgstr "" +msgstr "`ActiveState ActivePython `_" #: ../source/overview.rst:295 msgid "`WinPython `_" -msgstr "" +msgstr "`WinPython `_" #: ../source/overview.rst:300 msgid "Bringing your own Python executable" -msgstr "" +msgstr "Trazendo seu próprio executável Python" #: ../source/overview.rst:302 msgid "" @@ -9304,6 +11490,9 @@ msgid "" "operating system natively supports one or more formats of program they can " "natively execute." msgstr "" +"A computação como a conhecemos é definida pela capacidade de executar " +"programas. Cada sistema operacional oferece suporte nativamente a um ou mais " +"formatos de programa que eles podem executar nativamente." #: ../source/overview.rst:306 msgid "" @@ -9311,6 +11500,10 @@ msgid "" "into one of these formats, most of which involve embedding the Python " "interpreter and any other dependencies into a single executable file." msgstr "" +"Existem muitas técnicas e tecnologias que transformam seu programa Python em " +"um desses formatos, a maioria das quais envolve a incorporação do " +"interpretador Python e quaisquer outras dependências em um único arquivo " +"executável." #: ../source/overview.rst:311 msgid "" @@ -9318,57 +11511,68 @@ msgid "" "user experience, though often requires multiple technologies, and a good " "amount of effort." msgstr "" +"Essa abordagem, chamada *congelamento*, oferece ampla compatibilidade e " +"experiência perfeita do usuário, embora muitas vezes exija múltiplas " +"tecnologias e uma boa quantidade de esforço." #: ../source/overview.rst:315 msgid "A selection of Python freezers:" -msgstr "" +msgstr "Uma seleção de congeladores Python:" #: ../source/overview.rst:317 msgid "`pyInstaller `_ - Cross-platform" -msgstr "" +msgstr "`pyInstaller `_ - Multiplataforma" #: ../source/overview.rst:318 msgid "" "`cx_Freeze `_ - Cross-platform" msgstr "" +"`cx_Freeze `_ - Multiplataforma" #: ../source/overview.rst:319 msgid "" "`constructor `_ - For command-line " "installers" msgstr "" +"`constructor `_ - Para instaladores de " +"linha de comando" #: ../source/overview.rst:320 msgid "`py2exe `_ - Windows only" -msgstr "" +msgstr "`py2exe `_ - Windows apenas" #: ../source/overview.rst:321 msgid "`py2app `_ - Mac only" -msgstr "" +msgstr "`py2app `_ - Mac apenas" #: ../source/overview.rst:322 msgid "" "`bbFreeze `_ - Windows, Linux, Python 2 " "only" msgstr "" +"`bbFreeze `_ - Windows, Linux, Python 2 " +"apenas" #: ../source/overview.rst:323 msgid "`osnap `_ - Windows and Mac" -msgstr "" +msgstr "`osnap `_ - Windows e Mac" #: ../source/overview.rst:324 msgid "`pynsist `_ - Windows only" -msgstr "" +msgstr "`pynsist `_ - Windows apenas" #: ../source/overview.rst:326 msgid "" "Most of the above imply single-user deployments. For multi-component server " "applications, see `Chef Omnibus `_." msgstr "" +"A maioria dos itens acima implica em implantações de um único usuário. Para " +"aplicações de servidor com vários componentes, consulte `Chef Omnibus " +"`_." #: ../source/overview.rst:332 msgid "Bringing your own userspace" -msgstr "" +msgstr "Trazendo seu próprio espaço de usuário" #: ../source/overview.rst:334 msgid "" @@ -9378,38 +11582,48 @@ msgid "" "level virtualization `_, or *containerization*." msgstr "" +"Um número crescente de sistemas operacionais -- incluindo Linux, Mac OS e " +"Windows -- pode ser configurado para executar aplicações empacotadas como " +"imagens leves, usando um arranjo relativamente moderno, frequentemente " +"referido como `virtualização em nível de sistema operacional `_ ou " +"*conteinerização*." #: ../source/overview.rst:341 msgid "" "These techniques are mostly Python agnostic, because they package whole OS " "filesystems, not just Python or Python packages." msgstr "" +"Essas técnicas são principalmente Python agnósticas, porque empacotam " +"sistemas de arquivos de SO inteiros, não apenas Python ou pacotes Python." #: ../source/overview.rst:344 msgid "" "Adoption is most extensive among Linux servers, where the technology " "originated and where the technologies below work best:" msgstr "" +"A adoção é mais extensa entre os servidores Linux, onde a tecnologia se " +"originou e onde as tecnologias abaixo funcionam melhor:" #: ../source/overview.rst:347 msgid "`AppImage `_" -msgstr "" +msgstr "`AppImage `_" #: ../source/overview.rst:348 msgid "`Docker `_" -msgstr "" +msgstr "`Docker `_" #: ../source/overview.rst:349 msgid "`Flatpak `_" -msgstr "" +msgstr "`Flatpak `_" #: ../source/overview.rst:350 msgid "`Snapcraft `_" -msgstr "" +msgstr "`Snapcraft `_" #: ../source/overview.rst:353 msgid "Bringing your own kernel" -msgstr "" +msgstr "Trazendo seu próprio kernel" #: ../source/overview.rst:355 msgid "" @@ -9418,6 +11632,11 @@ msgid "" "of their own. Running these virtual machines, or VMs, is a mature approach, " "widespread in data center environments." msgstr "" +"A maioria dos sistemas operacionais oferece suporte a alguma forma de " +"virtualização clássica, executando aplicações empacotadas como imagens " +"contendo um sistema operacional completo próprio. Executar essas máquinas " +"virtuais, ou VMs, é uma abordagem madura, amplamente difundida em ambientes " +"de datacenter." #: ../source/overview.rst:360 msgid "" @@ -9425,10 +11644,13 @@ msgid "" "centers, though certain complex applications can benefit from this " "packaging. Technologies are Python agnostic, and include:" msgstr "" +"Essas técnicas são reservadas principalmente para implantações em grande " +"escala em datacenters, embora algumas aplicativas complexas possam se " +"beneficiar desse pacote. As tecnologias são agnósticas ao Python e incluem:" #: ../source/overview.rst:364 msgid "`Vagrant `_" -msgstr "" +msgstr "`Vagrant `_" #: ../source/overview.rst:365 msgid "" @@ -9436,16 +11658,21 @@ msgid "" "wikipedia.org/wiki/Amazon_Machine_Image>`_, and `other formats `_" msgstr "" +"`VHD `_, `AMI `_ e `outros formatos `_" #: ../source/overview.rst:366 msgid "" "`OpenStack `_ - A cloud " "management system in Python, with extensive VM support" msgstr "" +"`OpenStack `_ - Um sistema de " +"gerenciamento de nuvem em Python, com suporte extenso a VM" #: ../source/overview.rst:369 msgid "Bringing your own hardware" -msgstr "" +msgstr "Trazendo seu próprio hardware" #: ../source/overview.rst:371 msgid "" @@ -9453,6 +11680,9 @@ msgid "" "already-installed on some hardware. This way, your software's user would " "require only electricity." msgstr "" +"A maneira mais abrangente de enviar seu software seria enviá-lo já instalado " +"em algum hardware. Dessa forma, o usuário do seu software precisaria apenas " +"de eletricidade." #: ../source/overview.rst:375 msgid "" @@ -9460,6 +11690,10 @@ msgid "" "tech-savvy, you can find hardware appliances being used by everyone from the " "most advanced data centers to the youngest children." msgstr "" +"Considerando que as máquinas virtuais descritas acima são reservadas " +"principalmente para os conhecedores de tecnologia, você pode encontrar " +"dispositivos de hardware sendo usados por todos, desde os datacenters mais " +"avançados até as crianças mais novas." #: ../source/overview.rst:379 msgid "" @@ -9469,25 +11703,33 @@ msgid "" "datacenter or your users' homes. They plug and play, and you can call it a " "day." msgstr "" +"Incorpore seu código em um `Adafruit `_, `Micro Python `_ ou hardware mais poderoso executando Python e, em seguida, envie-o " +"para o datacenter ou para as casas de seus usuários. Eles conectam e estará " +"funcionando, e você pode encerrar o dia." #: ../source/overview.rst:389 msgid "" "The simplified gamut of technologies used to package Python applications." msgstr "" +"A gama simplificada de tecnologias usadas para empacotar aplicações Python." #: ../source/overview.rst:392 msgid "What about..." -msgstr "" +msgstr "E quanto a..." #: ../source/overview.rst:394 msgid "" "The sections above can only summarize so much, and you might be wondering " "about some of the more conspicuous gaps." msgstr "" +"As seções acima resumem muito, e você pode estar se perguntando sobre " +"algumas das lacunas mais evidentes." #: ../source/overview.rst:398 msgid "Operating system packages" -msgstr "" +msgstr "Pacotes de sistema operacional" #: ../source/overview.rst:400 msgid "" @@ -9501,12 +11743,23 @@ msgid "" "fpm.readthedocs.io/en/latest/source/virtualenv.html>`_ to generate both deb " "and RPMs from the same source." msgstr "" +"Como mencionado em :ref:`depending-on-a-separate-ecosystem` acima, alguns " +"sistemas operacionais possuem gerenciadores de pacotes próprios. Se você " +"tiver certeza do sistema operacional que está almejando, pode depender " +"diretamente de um formato como `deb `_ (para Debian, Ubuntu , etc.) ou `RPM `_ (para Red Hat, Fedora, etc.) e " +"usar esse gerenciador de pacotes embutido para cuidar da instalação, e mesmo " +"implantação. Você pode até usar `FPM `_ para gerar deb e RPMs da mesma fonte." #: ../source/overview.rst:411 msgid "" "In most deployment pipelines, the OS package manager is just one piece of " "the puzzle." msgstr "" +"Na maioria das pipelines de implantação, o gerenciador de pacotes do SO é " +"apenas uma peça do quebra-cabeça." #: ../source/overview.rst:417 msgid "" @@ -9518,6 +11771,14 @@ msgid "" "en/1.0/tutorial.html>`_ and `osnap `_, " "both of which wrap virtualenvs in a self-contained way." msgstr "" +"`Virtualenvs `_ têm sido uma ferramenta indispensável para várias gerações de " +"desenvolvedores Python, mas estão desaparecendo lentamente de vista, à " +"medida que estão sendo envoltos por ferramentas de nível superior. Com o " +"empacotamento em particular, virtualenvs são usados como primitivos na " +"`ferramenta dh-virtualenv `_ e `osnap `_, ambos " +"envolvem virtualenvs de uma forma independente." #: ../source/overview.rst:427 msgid "" @@ -9525,6 +11786,10 @@ msgid "" "from the Internet into a virtualenv, as one might do in a development " "environment. The overview above is full of much better solutions." msgstr "" +"Para implantações de produção, não dependa da execução de ``python -m pip " +"install`` da Internet em um virtualenv, como alguém pode fazer em um " +"ambiente de desenvolvimento. A visão geral acima está repleta de soluções " +"muito melhores." #: ../source/overview.rst:432 msgid "Security" @@ -9535,6 +11800,8 @@ msgid "" "The further down the gradient you come, the harder it gets to update " "components of your package. Everything is more tightly bound together." msgstr "" +"Quanto mais fundo você descer nas camadas, mais difícil será para atualizar " +"os componentes do seu pacote. Tudo está mais estreitamente ligado." #: ../source/overview.rst:437 msgid "" @@ -9546,10 +11813,17 @@ msgid "" "versus dynamic linking `_." msgstr "" +"Por exemplo, se surgir um problema de segurança do kernel e você estiver " +"implantando contêineres, o kernel do sistema host pode ser atualizado sem a " +"necessidade de uma nova compilação em nome da aplicação. Se você implantar " +"imagens de VM, precisará de uma nova construção. Se essa dinâmica torna ou " +"não uma opção mais segura ainda é um debate antigo, voltando à questão ainda " +"não resolvida de `ligação estática versus ligação dinâmica `_." #: ../source/overview.rst:446 msgid "Wrap up" -msgstr "" +msgstr "Resumo" #: ../source/overview.rst:448 msgid "" @@ -9559,24 +11833,34 @@ msgid "" "to realize that the varied landscape is a small price Python programmers pay " "for using one of the most balanced, flexible languages available." msgstr "" +"O empacotamento no Python tem a reputação de ser um percurso acidentado. " +"Essa impressão é principalmente um subproduto da versatilidade do Python. " +"Depois de entender os limites naturais entre cada solução de empacotamento, " +"você começa a perceber que o cenário variado é um preço pequeno Python que " +"os programadores pagam por usar uma das linguagens mais equilibradas e " +"flexíveis disponíveis." #: ../source/specifications/binary-distribution-format.rst:6 msgid "Binary distribution format" -msgstr "" +msgstr "Formato de distribuição binária" #: ../source/specifications/binary-distribution-format.rst:8 msgid "" "The binary distribution format (:term:`wheel `) was originally " "defined in :pep:`427`. The current version of the specification is here." msgstr "" +"O formato de distribuição binária (:term:`wheel `) foi originalmente " +"definido na :pep:`427`. A versão atual da especificação está aqui." #: ../source/specifications/binary-distribution-format.rst:13 msgid "Abstract" -msgstr "" +msgstr "Abstrato" #: ../source/specifications/binary-distribution-format.rst:15 msgid "This PEP describes a built-package format for Python called \"wheel\"." msgstr "" +"Esta PEP descreve um formato de pacote construído para Python chamado \"wheel" +"\"." #: ../source/specifications/binary-distribution-format.rst:17 msgid "" @@ -9588,20 +11872,30 @@ msgid "" "tool while preserving enough information to spread its contents out onto " "their final paths at any later time." msgstr "" +"Um wheel é um arquivo em formato ZIP com um nome de arquivo formatado de " +"forma especial e a extensão ``.whl``. Ele contém uma única distribuição " +"quase como seria instalado de acordo com a PEP 376 com um esquema de " +"instalação particular. Embora um instalador especializado seja recomendado, " +"um arquivo wheel pode ser instalado simplesmente descompactando em pacotes " +"de sites com a ferramenta padrão de \"descompactação\" enquanto preserva " +"informações suficientes para espalhar seu conteúdo em seus caminhos finais a " +"qualquer momento." #: ../source/specifications/binary-distribution-format.rst:27 msgid "PEP Acceptance" -msgstr "" +msgstr "Aceitação da PEP" #: ../source/specifications/binary-distribution-format.rst:29 msgid "" "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick " "Coghlan on 16th February, 2013 [1]_" msgstr "" +"Esta PEP foi aceita, e a versão do wheel definida foi atualizada para 1.0, " +"por Nick Coghlan em 16 de fevereiro de 2013 [1]_" #: ../source/specifications/binary-distribution-format.rst:34 msgid "Rationale" -msgstr "" +msgstr "Justificativa" #: ../source/specifications/binary-distribution-format.rst:36 msgid "" @@ -9612,6 +11906,13 @@ msgid "" "conflating build-install is slow, hard to maintain, and hinders innovation " "in both build systems and installers." msgstr "" +"Python precisa de um formato de pacote mais fácil de instalar do que sdist. " +"Os pacotes sdist do Python são definidos e requerem os sistemas de " +"construção distutils e setuptools, executando código arbitrário para " +"construir e instalar e recompilar o código apenas para que possa ser " +"instalado em um novo virtualenv. Este sistema de combinação entre construção " +"e instalação é lento, difícil de manter e impede a inovação tanto nos " +"sistemas de construção quanto nos instaladores." #: ../source/specifications/binary-distribution-format.rst:43 msgid "" @@ -9621,51 +11922,63 @@ msgid "" "amortizing compile time over many installations, and removes the need to " "install a build system in the target environment." msgstr "" +"O wheel tenta remediar esses problemas fornecendo uma interface mais simples " +"entre o sistema de compilação e o instalador. O formato do pacote binário " +"wheel libera os instaladores de ter que saber sobre o sistema de compilação, " +"economiza tempo amortizando o tempo de compilação em muitas instalações e " +"elimina a necessidade de instalar um sistema de compilação no ambiente de " +"destino." #: ../source/specifications/binary-distribution-format.rst:52 msgid "Details" -msgstr "" +msgstr "Detalhes" #: ../source/specifications/binary-distribution-format.rst:55 msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" -msgstr "" +msgstr "Instalando um wheel 'distribution-1.0-py32-none-any.whl'" #: ../source/specifications/binary-distribution-format.rst:57 msgid "Wheel installation notionally consists of two phases:" -msgstr "" +msgstr "A instalação do wheel consiste, em teoria, em duas fases:" #: ../source/specifications/binary-distribution-format.rst:59 msgid "Unpack." -msgstr "" +msgstr "Despempacotar." #: ../source/specifications/binary-distribution-format.rst:61 msgid "Parse ``distribution-1.0.dist-info/WHEEL``." -msgstr "" +msgstr "Analisar ``distribution-1.0.dist-info/WHEEL``." #: ../source/specifications/binary-distribution-format.rst:62 msgid "" "Check that installer is compatible with Wheel-Version. Warn if minor " "version is greater, abort if major version is greater." msgstr "" +"Verificar se o instalador é compatível com a versão Wheel. Avisa se a versão " +"secundária é maior, cancela se a versão principal é maior." #: ../source/specifications/binary-distribution-format.rst:64 msgid "" "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." msgstr "" +"Se Root-Is-Purelib == 'true', descompactar o arquivo em purelib (sites-" +"packages)." #: ../source/specifications/binary-distribution-format.rst:66 msgid "Else unpack archive into platlib (site-packages)." -msgstr "" +msgstr "Caso contrário, descompactar o arquivo em platlib (site-packages)." #: ../source/specifications/binary-distribution-format.rst:68 msgid "Spread." -msgstr "" +msgstr "Espalhar." #: ../source/specifications/binary-distribution-format.rst:70 msgid "" "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is " "data) ``distribution-1.0.data/``." msgstr "" +"O arquivo descompactado inclui ``distribution-1.0.dist-info/`` e (se houver " +"dados) ``distribution-1.0.data/``." #: ../source/specifications/binary-distribution-format.rst:72 msgid "" @@ -9675,34 +11988,45 @@ msgid "" "headers|scripts|data)``. The initially supported paths are taken from " "``distutils.command.install``." msgstr "" +"Mover cada subárvore de ``distribution-1.0.data/`` em seu caminho de " +"destino. Cada subdiretório de ``distribution-1.0.data/`` é uma chave para um " +"dicionário de diretórios de destino, como ``distribution-1.0.data/(purelib|" +"platlib|headers|scripts|data)``. Os caminhos inicialmente suportados são " +"obtidos de ``distutils.command.install``." #: ../source/specifications/binary-distribution-format.rst:78 msgid "" "If applicable, update scripts starting with ``#!python`` to point to the " "correct interpreter." msgstr "" +"Se aplicável, atualizar os scripts começando com ``#!python`` para apontar " +"para o interpretador correto." #: ../source/specifications/binary-distribution-format.rst:80 msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." msgstr "" +"Atualizar ``distribution-1.0.dist-info/RECORD`` com os caminhos instalados." #: ../source/specifications/binary-distribution-format.rst:82 msgid "Remove empty ``distribution-1.0.data`` directory." -msgstr "" +msgstr "Remover o diretório vazio ``distribution-1.0.data``." #: ../source/specifications/binary-distribution-format.rst:83 msgid "" "Compile any installed .py to .pyc. (Uninstallers should be smart enough to " "remove .pyc even if it is not mentioned in RECORD.)" msgstr "" +"Compilar qualquer .py instalado em .pyc. (Os desinstaladores devem ser " +"inteligentes o suficiente para remover .pyc, mesmo que não seja mencionado " +"em RECORD.)" #: ../source/specifications/binary-distribution-format.rst:87 msgid "Recommended installer features" -msgstr "" +msgstr "Recursos de instalador recomendados" #: ../source/specifications/binary-distribution-format.rst:97 msgid "Rewrite ``#!python``." -msgstr "" +msgstr "Reescrever ``#!python``." #: ../source/specifications/binary-distribution-format.rst:90 msgid "" @@ -9711,16 +12035,23 @@ msgid "" "python'``, rewrite to point to the correct interpreter. Unix installers may " "need to add the +x bit to these files if the archive was created on Windows." msgstr "" +"No wheel, os scripts são empacotados em ``{distribuição}-{versão}.data/" +"scripts/``. Se a primeira linha de um arquivo em ``scripts/`` começar " +"exatamente com ``b'#!python'``, reescreva para apontar para o interpretador " +"correto. Os instaladores do Unix podem precisar adicionar o bit +x a esses " +"arquivos se o arquivo tiver sido criado em Windows." #: ../source/specifications/binary-distribution-format.rst:96 msgid "" "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI " "script instead of a console script." msgstr "" +"A convenção ``b'#!pythonw'`` é permitida. ``b'#!pythonw'`` indica um script " +"GUI ao invés de um script de console." #: ../source/specifications/binary-distribution-format.rst:102 msgid "Generate script wrappers." -msgstr "" +msgstr "Gerar script wrappers." #: ../source/specifications/binary-distribution-format.rst:100 msgid "" @@ -9728,14 +12059,17 @@ msgid "" "accompanying .exe wrappers. Windows installers may want to add them during " "install." msgstr "" +"No wheel, scripts empacotados em sistemas Unix certamente não serão " +"acompanhados de wrappers .exe. Os instaladores Windows podem querer adicioná-" +"los durante a instalação." #: ../source/specifications/binary-distribution-format.rst:105 msgid "Recommended archiver features" -msgstr "" +msgstr "Recursos de arquivador recomendados" #: ../source/specifications/binary-distribution-format.rst:112 msgid "Place ``.dist-info`` at the end of the archive." -msgstr "" +msgstr "Colocar ``.dist-info`` no final do arquivo." #: ../source/specifications/binary-distribution-format.rst:108 msgid "" @@ -9744,36 +12078,42 @@ msgid "" "including the ability to amend the metadata without rewriting the entire " "archive." msgstr "" +"Os arquivadores são encorajados a colocar os arquivos ``.dist-info`` " +"fisicamente no final do repositório. Isso permite alguns truques de ZIP " +"potencialmente interessantes, incluindo a capacidade de corrigir os " +"metadados sem reescrever todo o arquivo." #: ../source/specifications/binary-distribution-format.rst:115 msgid "File Format" -msgstr "" +msgstr "Formato de arquivos" #: ../source/specifications/binary-distribution-format.rst:118 msgid "File name convention" -msgstr "" +msgstr "Convenção de nome de arquivos" #: ../source/specifications/binary-distribution-format.rst:120 msgid "" "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-" "{abi tag}-{platform tag}.whl``." msgstr "" +"O nome de arquivo do wheel é ``{distribuição}-{versão}(-{tag da " +"construção})?-{tag do python}-{tag de abi}-{tag da plataforma}.whl``." #: ../source/specifications/binary-distribution-format.rst:124 msgid "distribution" -msgstr "" +msgstr "distribuição" #: ../source/specifications/binary-distribution-format.rst:124 msgid "Distribution name, e.g. 'django', 'pyramid'." -msgstr "" +msgstr "Nome da distribuição (p.ex., 'django', 'pyramid')." #: ../source/specifications/binary-distribution-format.rst:127 msgid "Distribution version, e.g. 1.0." -msgstr "" +msgstr "Versão da distribuição (p.ex., 1.0)." #: ../source/specifications/binary-distribution-format.rst:135 msgid "build tag" -msgstr "" +msgstr "tag da construção" #: ../source/specifications/binary-distribution-format.rst:130 msgid "" @@ -9783,30 +12123,36 @@ msgid "" "item tuple with the first item being the initial digits as an ``int``, and " "the second item being the remainder of the tag as a ``str``." msgstr "" +"Número de construção opcional. Deve começar com um dígito. Atua como um " +"desempate se os nomes de arquivo de dois wheels forem iguais em todos os " +"outros aspectos (ou seja, nome, versão e outras tags). Classifique como uma " +"tupla vazia se não for especificado, caso contrário, classifique como uma " +"tupla de dois itens com o primeiro item sendo os dígitos iniciais como um " +"``int``, e o segundo item sendo o restante da tag como um ``str``." #: ../source/specifications/binary-distribution-format.rst:138 msgid "language implementation and version tag" -msgstr "" +msgstr "implementação da linguagem e tag de versão" #: ../source/specifications/binary-distribution-format.rst:138 msgid "E.g. 'py27', 'py2', 'py3'." -msgstr "" +msgstr "p.ex., 'py27', 'py2', 'py3'." #: ../source/specifications/binary-distribution-format.rst:141 msgid "abi tag" -msgstr "" +msgstr "tag de abi" #: ../source/specifications/binary-distribution-format.rst:141 msgid "E.g. 'cp33m', 'abi3', 'none'." -msgstr "" +msgstr "p.ex., 'cp33m', 'abi3', 'none'." #: ../source/specifications/binary-distribution-format.rst:144 msgid "platform tag" -msgstr "" +msgstr "tag da plataforma" #: ../source/specifications/binary-distribution-format.rst:144 msgid "E.g. 'linux_x86_64', 'any'." -msgstr "" +msgstr "p.ex., 'linux_x86_64', 'any'." #: ../source/specifications/binary-distribution-format.rst:146 msgid "" @@ -9815,6 +12161,10 @@ msgid "" "Python 2.7 implementation), with no ABI (pure Python), on any CPU " "architecture." msgstr "" +"Por exemplo, ``distribution-1.0-1-py27-none-any.whl`` é a primeira " +"construção de um pacote chamado 'distribution' e é compatível com Python 2.7 " +"(qualquer implementação Python 2.7), com sem ABI (puro Python), em qualquer " +"arquitetura de CPU." #: ../source/specifications/binary-distribution-format.rst:151 msgid "" @@ -9822,10 +12172,14 @@ msgid "" "\"compatibility tags.\" The compatibility tags express the package's basic " "interpreter requirements and are detailed in PEP 425." msgstr "" +"Os últimos três componentes do nome do arquivo antes da extensão são " +"chamados de \"tags de compatibilidade\". As tags de compatibilidade " +"expressam os requisitos básicos do interpretador do pacote e são detalhadas " +"na PEP 425." #: ../source/specifications/binary-distribution-format.rst:156 msgid "Escaping and Unicode" -msgstr "" +msgstr "Escape e Unicode" #: ../source/specifications/binary-distribution-format.rst:158 msgid "" @@ -9833,6 +12187,9 @@ msgid "" "MINUS), this character cannot appear within any component. This is handled " "as follows:" msgstr "" +"Como os componentes do nome do arquivo são separados por um traço (``-``, " +"HYPHEN-MINUS), este caractere não pode aparecer em nenhum componente. Isso é " +"tratado da seguinte maneira:" #: ../source/specifications/binary-distribution-format.rst:161 msgid "" @@ -9840,18 +12197,26 @@ msgid "" "and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent " "to :pep:`503` normalisation followed by replacing ``-`` with ``_``." msgstr "" +"Em nomes de distribuição, qualquer ocorrência de caracteres ``-_.`` (HYPHEN-" +"MINUS, LOW LINE e FULL STOP) deve ser substituída por ``_`` (LOW LINE). Isso " +"é equivalente à normalização da :pep:`503` seguida pela substituição de ``-" +"`` por ``_``." #: ../source/specifications/binary-distribution-format.rst:164 msgid "" "Version numbers should be normalised according to :pep:`440`. Normalised " "version numbers cannot contain ``-``." msgstr "" +"Os números de versão devem ser normalizados de acordo com a :pep:`440`. Os " +"números de versão normalizados não podem conter ``-``." #: ../source/specifications/binary-distribution-format.rst:166 msgid "" "The remaining components may not contain ``-`` characters, so no escaping is " "necessary." msgstr "" +"Os componentes restantes não podem conter caracteres ``-``, portanto, nenhum " +"escape é necessário." #: ../source/specifications/binary-distribution-format.rst:169 msgid "" @@ -9859,6 +12224,9 @@ msgid "" "contain ``-``, as the resulting file may not be processed correctly if they " "do." msgstr "" +"Ferramentas que produzem wheels devem verificar se os componentes do nome de " +"arquivo não contêm ``-``, pois o arquivo resultante pode não ser processado " +"corretamente se contiverem." #: ../source/specifications/binary-distribution-format.rst:172 msgid "" @@ -9866,6 +12234,9 @@ msgid "" "updated to support non-ASCII filenames, but they are supported in this " "specification." msgstr "" +"O nome do arquivo é Unicode. Levará algum tempo até que as ferramentas sejam " +"atualizadas para oferecer suporte a nomes de arquivos não ASCII, mas eles " +"são suportados nesta especificação." #: ../source/specifications/binary-distribution-format.rst:176 msgid "" @@ -9873,10 +12244,14 @@ msgid "" "clients in common use do not properly display UTF-8 filenames, the encoding " "is supported by both the ZIP specification and Python's ``zipfile``." msgstr "" +"Os nomes de arquivos *dentro* do arquivo são codificados como UTF-8. Embora " +"alguns clientes ZIP em uso comum não exibam nomes de arquivo UTF-8 " +"apropriadamente, a codificação é suportada pela especificação ZIP e pelo " +"``zipfile`` do Python." #: ../source/specifications/binary-distribution-format.rst:182 msgid "File contents" -msgstr "" +msgstr "Conteúdo dos arquivos" #: ../source/specifications/binary-distribution-format.rst:184 msgid "" @@ -9884,6 +12259,9 @@ msgid "" "of the package, e.g. ``beaglevote`` and {version} is replaced with its " "version, e.g. ``1.0.0``, consist of:" msgstr "" +"O conteúdo de um arquivo wheel, onde {distribuição} é substituído pelo nome " +"do pacote, por exemplo, ``beaglevote`` e {version} é substituído por sua " +"versão, p.ex., ``1.0.0``, consiste em:" #: ../source/specifications/binary-distribution-format.rst:188 msgid "" @@ -9891,10 +12269,13 @@ msgid "" "``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and " "``platlib`` are usually both ``site-packages``." msgstr "" +"``/``, a raiz do arquivo, contém todos os arquivos a serem instalados em " +"``purelib`` ou ``platlib`` conforme especificado em ``WHEEL``. ``purelib`` e " +"``platlib`` são normalmente ``site-packages``." #: ../source/specifications/binary-distribution-format.rst:191 msgid "``{distribution}-{version}.dist-info/`` contains metadata." -msgstr "" +msgstr "``{distribuição}-{versão}.dist-info/`` contém metadados." #: ../source/specifications/binary-distribution-format.rst:192 msgid "" @@ -9903,6 +12284,10 @@ msgid "" "an index into a dictionary of install paths (e.g. ``data``, ``scripts``, " "``include``, ``purelib``, ``platlib``)." msgstr "" +"``{distribuição}-{versão}.data/`` contém um subdiretório para cada chave de " +"esquema de instalação não vazia ainda não coberta, onde o nome do " +"subdiretório é um índice em um dicionário de caminhos de instalação (p.ex., " +"``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." #: ../source/specifications/binary-distribution-format.rst:196 msgid "" @@ -9910,28 +12295,38 @@ msgid "" "python'`` in order to enjoy script wrapper generation and ``#!python`` " "rewriting at install time. They may have any or no extension." msgstr "" +"Scripts Python devem aparecer em ``scripts`` e começar exatamente com ``b'#!" +"python'`` para desfrutar da geração do wrapper de script e reescrever ``#!" +"python`` no momento da instalação. Eles podem ter qualquer ou nenhuma " +"extensão." #: ../source/specifications/binary-distribution-format.rst:200 msgid "" "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or " "greater format metadata." msgstr "" +"``{distribuição}-{versão}.dist-info/METADATA`` é Metadata versão 1.1 ou " +"metadados de formato superior." #: ../source/specifications/binary-distribution-format.rst:202 msgid "" "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive " "itself in the same basic key: value format::" msgstr "" +"``{distribuição}-{versão}.dist-info/WHEEL`` são metadados sobre p arquivo em " +"si no mesmo formato \"chave: valor\"::" #: ../source/specifications/binary-distribution-format.rst:212 msgid "``Wheel-Version`` is the version number of the Wheel specification." -msgstr "" +msgstr "``Wheel-Version`` é o número de versão da especificação Wheel." #: ../source/specifications/binary-distribution-format.rst:213 msgid "" "``Generator`` is the name and optionally the version of the software that " "produced the archive." msgstr "" +"``Generator`` é o nome e, opcionalmente, a versão do software que produziu o " +"arquivo." #: ../source/specifications/binary-distribution-format.rst:215 msgid "" @@ -9939,17 +12334,24 @@ msgid "" "be installed into purelib; otherwise the root should be installed into " "platlib." msgstr "" +"``Root-Is-Purelib`` é verdadeiro se o diretório de nível superior do arquivo " +"deve ser instalado em purelib; caso contrário, a raiz deve ser instalada no " +"platlib." #: ../source/specifications/binary-distribution-format.rst:218 msgid "" "``Tag`` is the wheel's expanded compatibility tags; in the example the " "filename would contain ``py2.py3-none-any``." msgstr "" +"``Tag`` são as tags de compatibilidade expandida do wheel; no exemplo, o " +"nome do arquivo conteria ``py2.py3-none-any``." #: ../source/specifications/binary-distribution-format.rst:220 msgid "" "``Build`` is the build number and is omitted if there is no build number." msgstr "" +"``Build`` é o número da construção e é omitido se não houver número da " +"construção." #: ../source/specifications/binary-distribution-format.rst:221 msgid "" @@ -9957,16 +12359,22 @@ msgid "" "it supports, and must fail if Wheel-Version has a greater major version than " "the version it supports." msgstr "" +"Um instalador de wheel deve avisar se Wheel-Version é maior do que a versão " +"que ele suporta, e deve falhar se Wheel-Version tiver uma versão principal " +"maior do que a versão que ele suporta." #: ../source/specifications/binary-distribution-format.rst:224 +#, fuzzy msgid "" "Wheel, being an installation format that is intended to work across multiple " "versions of Python, does not generally include .pyc files." msgstr "" +"O Wheel, sendo um formato de instalação destinado a funcionar em várias " +"versões do Python, geralmente não inclui arquivos .pyc." #: ../source/specifications/binary-distribution-format.rst:226 msgid "Wheel does not contain setup.py or setup.cfg." -msgstr "" +msgstr "Wheel não contém setup.py ou setup.cfg." #: ../source/specifications/binary-distribution-format.rst:228 msgid "" @@ -10336,13 +12744,15 @@ msgstr "" #: ../source/specifications/core-metadata.rst:5 msgid "Core metadata specifications" -msgstr "" +msgstr "Especificações de metadados principais" #: ../source/specifications/core-metadata.rst:7 msgid "" "Fields defined in the following specification should be considered valid, " "complete and not subject to change. The required fields are:" msgstr "" +"Os campos definidos nas especificações a seguir devem ser considerados " +"válidos, completos e não sujeitos a alterações. Os campos obrigatórios são:" #: ../source/specifications/core-metadata.rst:10 msgid "``Metadata-Version``" @@ -10350,7 +12760,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:11 msgid "``Name``" -msgstr "" +msgstr "``Name``" #: ../source/specifications/core-metadata.rst:12 msgid "``Version``" @@ -10358,7 +12768,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:14 msgid "All the other fields are optional." -msgstr "" +msgstr "Todos os outros campos são opcionais." #: ../source/specifications/core-metadata.rst:16 msgid "" @@ -10371,6 +12781,14 @@ msgid "" "email.parser` module can parse using the :data:`~.python:email.policy." "compat32` policy." msgstr "" +"O formato de arquivo padrão para metadados (incluindo em :doc:`wheels " +"` e :doc:`projetos instalados `) é baseado no formato de cabeçalhos de e-mail. No " +"entanto, os formatos de e-mail foram revisados várias vezes e não é " +"especificado exatamente qual RFC de e-mail se aplica aos metadados do " +"pacote. Na ausência de uma definição precisa, o padrão prático é definido " +"pelo que o módulo da biblioteca padrão :mod:`python:email.parser` pode " +"analisar usando a política :data:`~.python:email.policy.compat32`." #: ../source/specifications/core-metadata.rst:25 msgid "" @@ -10379,6 +12797,10 @@ msgid "" "format. The need for tools to work with years worth of existing packages " "makes it difficult to shift to a new format." msgstr "" +"Embora a :pep:`566` tenha definido uma maneira de transformar metadados em " +"um dicionário compatível com JSON, isso ainda não é usado como um formato de " +"intercâmbio padrão. A necessidade de ferramentas para trabalhar com anos de " +"pacotes existentes torna difícil mudar para um novo formato." #: ../source/specifications/core-metadata.rst:30 msgid "" @@ -10389,16 +12811,25 @@ msgid "" "more relaxed formatting rules even for metadata files that are nominally " "less than version 2.1." msgstr "" +"*Interpretando metadados antigos:* Na :pep:`566`, a especificação do formato " +"do campo do especificador de versão foi relaxada para aceitar a sintaxe " +"usada por ferramentas de publicação populares (nomeadamente para remover o " +"requisito de que os especificadores de versão devem estar entre parênteses). " +"Os consumidores de metadados podem querer usar regras de formatação mais " +"relaxadas, mesmo para arquivos de metadados que são nominalmente inferiores " +"à versão 2.1." #: ../source/specifications/core-metadata.rst:41 msgid "Metadata-Version" -msgstr "" +msgstr "Metadata-Version" #: ../source/specifications/core-metadata.rst:45 msgid "" "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", " "\"2.1\" and \"2.2\"." msgstr "" +"Versão do formato de arquivo; valores válidos são \"1.0\", \"1.1\", \"1.2\", " +"\"2.1\" e \"2.2\"." #: ../source/specifications/core-metadata.rst:48 msgid "" @@ -10408,6 +12839,11 @@ msgid "" "they support (as described in :pep:`440`, the major version is the value " "before the first dot)." msgstr "" +"Ferramentas automatizadas que consomem metadados DEVEM avisar se " +"``metadata_version`` é maior que a versão mais alta à qual oferecem suporte, " +"e DEVEM falhar se ``metadata_version`` tem uma versão maior do que a versão " +"mais alta à qual oferecem suporte (como descrito na :pep:`440`, a versão " +"principal é o valor antes do primeiro ponto)." #: ../source/specifications/core-metadata.rst:54 msgid "" @@ -10415,6 +12851,9 @@ msgid "" "metadata using the lowest metadata version that includes all of the needed " "fields." msgstr "" +"Para uma compatibilidade mais ampla, as ferramentas de construção PODEM " +"escolher produzir metadados de distribuição usando a versão de metadados " +"mais baixa que inclui todos os campos necessários." #: ../source/specifications/core-metadata.rst:58 #: ../source/specifications/core-metadata.rst:80 @@ -10436,7 +12875,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:620 #: ../source/specifications/core-metadata.rst:630 msgid "Example::" -msgstr "" +msgstr "Exemplo::" #: ../source/specifications/core-metadata.rst:66 msgid "Name" @@ -10444,7 +12883,7 @@ msgstr "Nome" #: ../source/specifications/core-metadata.rst:69 msgid "Added additional restrictions on format from :pep:`508`" -msgstr "" +msgstr "Adicionadas restrições adicionais ao formato da :pep:`508`" #: ../source/specifications/core-metadata.rst:72 msgid "" @@ -10454,6 +12893,11 @@ msgid "" "number. Distribution names are limited to those which match the following " "regex (run with ``re.IGNORECASE``)::" msgstr "" +"O nome da distribuição. O campo de nome é o identificador principal de uma " +"distribuição. Um nome válido consiste apenas em letras e números ASCII, " +"ponto, sublinhado e hífen. Deve começar e terminar com uma letra ou número. " +"Os nomes de distribuição são limitados àqueles que correspondem ao seguinte " +"regex (executado com ``re.IGNORECASE``)::" #: ../source/specifications/core-metadata.rst:88 msgid "Version" @@ -10464,22 +12908,28 @@ msgid "" "A string containing the distribution's version number. This field must be " "in the format specified in :pep:`440`." msgstr "" +"Uma string contendo o número da versão da distribuição. Este campo deve " +"estar no formato especificado na :pep:`440`." #: ../source/specifications/core-metadata.rst:101 msgid "Dynamic (multiple use)" -msgstr "" +msgstr "Dynamic (vários usos)" #: ../source/specifications/core-metadata.rst:105 msgid "" "A string containing the name of another core metadata field. The field names " "``Name`` and ``Version`` may not be specified in this field." msgstr "" +"Uma string contendo o nome de outro campo de metadados principal. Os nomes " +"dos campos ``Name`` e ``Version`` não podem ser especificados neste campo." #: ../source/specifications/core-metadata.rst:108 msgid "" "When found in the metadata of a source distribution, the following rules " "apply:" msgstr "" +"Quando encontrados nos metadados de uma distribuição fonte, as seguintes " +"regras se aplicam:" #: ../source/specifications/core-metadata.rst:111 msgid "" @@ -10488,12 +12938,19 @@ msgid "" "field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT " "be present in the wheel." msgstr "" +"Se um campo *não* estiver marcado como ``Dynamic``, então o valor do campo " +"em qualquer wheel construído a partir do sdist DEVE corresponder ao valor do " +"sdist. Se o campo não estiver no sdist e não estiver marcado como " +"``Dynamic``, ele NÃO DEVE estar presente no wheel." #: ../source/specifications/core-metadata.rst:115 msgid "" "If a field is marked as ``Dynamic``, it may contain any valid value in a " "wheel built from the sdist (including not being present at all)." msgstr "" +"Se um campo for marcado como ``Dynamic``, ele pode conter qualquer valor " +"válido em um wheel construído a partir do sdist (incluindo não estar " +"presente)." #: ../source/specifications/core-metadata.rst:118 msgid "" @@ -10501,6 +12958,10 @@ msgid "" "should be treated as if they were specified with ``Dynamic`` (i.e. there are " "no special restrictions on the metadata of wheels built from the sdist)." msgstr "" +"Se a versão dos metadados sdist for anterior à versão 2.2, todos os campos " +"devem ser tratados como se tivessem sido especificados com ``Dynamic`` (ou " +"seja, não há restrições especiais sobre os metadados dos wheels construídos " +"a partir do sdist)." #: ../source/specifications/core-metadata.rst:122 msgid "" @@ -10509,15 +12970,20 @@ msgid "" "build time, and may not be the same as the value in the sdist or in other " "wheels for the project." msgstr "" +"Em qualquer contexto que não seja uma distribuição fonte, ``Dynamic`` é " +"apenas para informação e indica que o valor do campo foi calculado no tempo " +"de construção do wheel, e pode não ser o mesmo que o valor no sdist ou em " +"outros wheels para o projeto." #: ../source/specifications/core-metadata.rst:127 msgid "" "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." msgstr "" +"Detalhes completos da semântica de ``Dynamic`` são descritos na :pep:`643`." #: ../source/specifications/core-metadata.rst:131 msgid "Platform (multiple use)" -msgstr "" +msgstr "Platform (vários usos)" #: ../source/specifications/core-metadata.rst:135 msgid "" @@ -10894,7 +13360,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:538 msgid "Requires-Python" -msgstr "" +msgstr "Requires-Python" #: ../source/specifications/core-metadata.rst:542 msgid "" @@ -12166,7 +14632,7 @@ msgstr "" #: ../source/specifications/index.rst:4 msgid "PyPA specifications" -msgstr "" +msgstr "Especificações do PyPA" #: ../source/specifications/index.rst:6 msgid "" @@ -12175,18 +14641,22 @@ msgid "" "standards, and for proposing new ones, is documented on `pypa.io `__." msgstr "" +"Esta é uma lista de especificações de interoperabilidade atualmente ativas " +"mantidas pela Python Packaging Authority. O processo de atualização desses " +"padrões e de proposição de novos está documentado em `pypa.io `__." #: ../source/specifications/index.rst:13 msgid "Package Distribution Metadata" -msgstr "" +msgstr "Metadados de distribuição de pacotes" #: ../source/specifications/index.rst:30 msgid "Package Distribution File Formats" -msgstr "" +msgstr "Formatos de arquivos de distribuição de pacotes" #: ../source/specifications/index.rst:40 msgid "Package Index Interfaces" -msgstr "" +msgstr "Interfaces de índices de pacotes" #: ../source/specifications/platform-compatibility-tags.rst:6 msgid "Platform compatibility tags" @@ -12896,39 +15366,44 @@ msgstr "" #: ../source/tutorials/creating-documentation.rst:5 msgid "Creating Documentation" -msgstr "" +msgstr "Criando documentação" #: ../source/tutorials/creating-documentation.rst:7 msgid "" "This section covers the basics of how to create documentation using " "`Sphinx`_ and host the documentation for free in `Read The Docs`_." msgstr "" +"Esta seção cobre o básico de como criar documentação usando `Sphinx`_ e " +"hospedar a documentação gratuitamente em `Read The Docs`_." #: ../source/tutorials/creating-documentation.rst:13 msgid "Installing Sphinx" -msgstr "" +msgstr "Instalando o Sphinx" #: ../source/tutorials/creating-documentation.rst:14 msgid "Use ``pip`` to install Sphinx:" -msgstr "" +msgstr "Use ``pip`` para instalar o Sphinx:" #: ../source/tutorials/creating-documentation.rst:28 msgid "" "For other installation methods, see this `installation guide`_ by Sphinx." msgstr "" +"Para outros métodos de instalação, veja esta `guia de instalação`_ do Sphinx." #: ../source/tutorials/creating-documentation.rst:33 msgid "Getting Started With Sphinx" -msgstr "" +msgstr "Primeiros passos com Sphinx" #: ../source/tutorials/creating-documentation.rst:35 msgid "" "Create a ``docs`` directory inside your project to hold your documentation:" msgstr "" +"Crie um diretório ``docs`` dentro de seu projeto para conter sua " +"documentação:" #: ../source/tutorials/creating-documentation.rst:42 msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" -msgstr "" +msgstr "Execute ``sphinx-quickstart`` dentro do diretório ``docs``:" #: ../source/tutorials/creating-documentation.rst:49 msgid "" @@ -12936,27 +15411,35 @@ msgid "" "configurations, and creates an ``index.rst`` file as well as a ``conf.py`` " "file." msgstr "" +"Isso configura um diretório fonte, orienta você por algumas configurações " +"básicas e cria um arquivo ``index.rst``, bem como um arquivo ``conf.py``." #: ../source/tutorials/creating-documentation.rst:51 msgid "" "You can add some information about your project in ``index.rst``, then build " "them:" msgstr "" +"Você pode adicionar algumas informações sobre o seu projeto em ``index.rst`` " +"e, em seguida, construí-las:" #: ../source/tutorials/creating-documentation.rst:57 msgid "" "For more details on the build process, see this `guide`_ by Read The Docs." msgstr "" +"Para mais detalhes sobre o processo de construção, veja o `guia`_ do Read " +"The Docs." #: ../source/tutorials/creating-documentation.rst:62 msgid "Other Sources" -msgstr "" +msgstr "Outras fontes" #: ../source/tutorials/creating-documentation.rst:64 msgid "" "For a more detailed guide on how to use Sphinx and reStructuredText, please " "see this `documentation tutorial`_ on Hitchhiker's Guide to Python." msgstr "" +"Para um guia mais detalhado sobre como usar o Sphinx e o reStructuredText, " +"consulte este `tutorial de documentação`_ no Guia do Mochileiro para Python." #: ../source/tutorials/index.rst:4 msgid "" @@ -12964,16 +15447,22 @@ msgid "" "with packaging concepts. For more detailed information on specific packaging " "topics, see :doc:`/guides/index`." msgstr "" +"**Tutoriais** são guias passo a passo opinativos para ajudá-lo a se " +"familiarizar com os conceitos de empacotamento. Para obter informações mais " +"detalhadas sobre tópicos de empacotamento específicos, consulte :doc:`/" +"guides/index`." #: ../source/tutorials/installing-packages.rst:5 msgid "Installing Packages" -msgstr "" +msgstr "Instalando pacotes" #: ../source/tutorials/installing-packages.rst:7 msgid "" "This section covers the basics of how to install Python :term:`packages " "`." msgstr "" +"Esta seção cobre o básico de como instalar term:`pacotes ` Python." #: ../source/tutorials/installing-packages.rst:10 msgid "" @@ -12987,26 +15476,43 @@ msgid "" "preferred, because it can easily be confused with a Linux distribution, or " "another larger software distribution like Python itself." msgstr "" +"É importante notar que o termo \"pacote\" neste contexto está sendo usado " +"para descrever um pacote de software a ser instalado (ou seja, como um " +"sinônimo para uma :term:`distribuição `). Não se " +"refere ao tipo de :term:`pacote ` que você importa em " +"seu código-fonte Python (ou seja, um contêiner de módulos). É comum na " +"comunidade Python referir-se a uma :term:`distribuição ` usando o termo \"pacote\". Usar o termo \"distribuição\" " +"geralmente não é preferido, porque pode ser facilmente confundido com uma " +"distribuição Linux ou outra distribuição de software maior como o próprio " +"Python." #: ../source/tutorials/installing-packages.rst:28 msgid "Requirements for Installing Packages" -msgstr "" +msgstr "Requisitos para instalar pacotes" #: ../source/tutorials/installing-packages.rst:30 msgid "" "This section describes the steps to follow before installing other Python " "packages." msgstr "" +"Esta seção descreve as etapas a serem seguidas antes de instalar outros " +"pacotes Python." #: ../source/tutorials/installing-packages.rst:35 msgid "Ensure you can run Python from the command line" msgstr "" +"Certifique-se de que você consegue executar Python a partir da linha de " +"comando" #: ../source/tutorials/installing-packages.rst:37 msgid "" "Before you go any further, make sure you have Python and that the expected " "version is available from your command line. You can check this by running:" msgstr "" +"Antes de prosseguir, certifique-se de ter o Python e de que a versão " +"esperada está disponível em sua linha de comando. Você pode verificar isso " +"executando:" #: ../source/tutorials/installing-packages.rst:53 msgid "" @@ -13014,10 +15520,13 @@ msgid "" "please install the latest 3.x version from `python.org`_ or refer to the " "`Installing Python`_ section of the Hitchhiker's Guide to Python." msgstr "" +"Você deve obter alguma saída como ``Python 3.6.3``. Se você não tiver o " +"Python, instale a versão 3.x mais recente de `python.org`_ ou consulte a " +"seção `Instalando Python`_ do Guia do Mochileiro para Python." #: ../source/tutorials/installing-packages.rst:57 msgid "If you're a newcomer and you get an error like this:" -msgstr "" +msgstr "Se você for um novato e receber um erro como este:" #: ../source/tutorials/installing-packages.rst:66 msgid "" @@ -13026,6 +15535,10 @@ msgid "" "the Python for Beginners `getting started tutorial`_ for an introduction to " "using your operating system's shell and interacting with Python." msgstr "" +"É porque este comando e outros comandos sugeridos neste tutorial devem ser " +"executados em um *shell* (também chamado de *terminal* ou *console*). Veja o " +"`tutorial de introdução`_ para iniciantes do Python para uma introdução " +"sobre como usar o shell do seu sistema operacional e interagir com o Python." #: ../source/tutorials/installing-packages.rst:72 msgid "" @@ -13033,6 +15546,9 @@ msgid "" "can run system commands like those in this tutorial by prefacing them with a " "``!`` character:" msgstr "" +"Se estiver usando um shell aprimorado como o IPython ou o notebook Jupyter, " +"você pode executar comandos do sistema como os deste tutorial precedendo-os " +"com um caractere ``!``:" #: ../source/tutorials/installing-packages.rst:82 msgid "" @@ -13041,6 +15557,10 @@ msgid "" "the currently running notebook (which may not be the same Python " "installation that the ``python`` command refers to)." msgstr "" +"É recomendado escrever ``{sys.executable}`` em vez de ``python`` simples " +"para garantir que os comandos sejam executados na instalação do Python " +"correspondendo ao ambiente em execução (que pode não ser o mesmo Python " +"instalação à qual o comando ``python`` se refere)." #: ../source/tutorials/installing-packages.rst:87 msgid "" @@ -13052,16 +15572,27 @@ msgid "" "you get a permissions error, come back to the section on creating virtual " "environments, set one up, and then continue with the tutorial as written." msgstr "" +"Devido à forma como a maioria das distribuições Linux está lidando com a " +"migração Python 3, os usuários Linux usando o sistema Python sem criar um " +"ambiente virtual primeiro devem substituir o comando ``python`` neste " +"tutorial por ``python3`` e o comando ``python -m pip`` com ``python3 -m pip " +"--user``. *Não* execute nenhum dos comandos neste tutorial com ``sudo``: se " +"você receber um erro de permissão, volte para a seção sobre como criar " +"ambientes virtuais, configure um e então continue com o tutorial como " +"escrito." #: ../source/tutorials/installing-packages.rst:99 msgid "Ensure you can run pip from the command line" msgstr "" +"Certifique-se de que você pode executar o pip a partir da linha de comando" #: ../source/tutorials/installing-packages.rst:101 msgid "" "Additionally, you'll need to make sure you have :ref:`pip` available. You " "can check this by running:" msgstr "" +"Além disso, você precisa ter certeza de ter :ref:`pip` disponível. Você pode " +"verificar isso executando:" #: ../source/tutorials/installing-packages.rst:116 msgid "" @@ -13070,21 +15601,29 @@ msgid "" "installed using your OS package manager, you may have to install pip " "separately, see :doc:`/guides/installing-using-linux-tools`." msgstr "" +"Se você instalou Python a partir do código-fonte, com um instalador de " +"`python.org`_, ou via `Homebrew`_, você já deve ter o pip. Se você estiver " +"no Linux e instalado usando o gerenciador de pacotes do sistema operacional, " +"pode ser necessário instalar o pip separadamente, consulte :doc:`/guides/" +"installing-using-linux-tools`." #: ../source/tutorials/installing-packages.rst:124 msgid "" "If ``pip`` isn't already installed, then first try to bootstrap it from the " "standard library:" msgstr "" +"Se o ``pip`` ainda não estiver instalado, tente primeiro inicializá-lo a " +"partir da biblioteca padrão:" #: ../source/tutorials/installing-packages.rst:139 msgid "If that still doesn't allow you to run ``python -m pip``:" -msgstr "" +msgstr "Se isso ainda não permitir que você execute ``python -m pip``:" #: ../source/tutorials/installing-packages.rst:141 msgid "" "Securely Download `get-pip.py `_ [1]_" msgstr "" +"Baixe com segurança `get-pip.py `_ [1]_" #: ../source/tutorials/installing-packages.rst:144 msgid "" @@ -13092,6 +15631,9 @@ msgid "" "Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're " "not installed already." msgstr "" +"Execute ``python get-pip.py``. [2]_ Isso vai instalar ou atualizar o pip. " +"Adicionalmente, vai instalar :ref:`setuptools` e :ref:`wheel` se ainda não " +"estiverem instalados." #: ../source/tutorials/installing-packages.rst:150 msgid "" @@ -13101,10 +15643,15 @@ msgid "" "can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/" "local`` which is designed for locally-installed software." msgstr "" +"Tenha cuidado se estiver usando uma instalação do Python gerenciada por seu " +"sistema operacional ou outro gerenciador de pacotes. get-pip.py não coordena " +"com essas ferramentas e pode deixar seu sistema em um estado inconsistente. " +"Você pode usar ``python get-pip.py --prefix=/usr/local/`` para instalar em " +"``/usr/local`` que é projetado para software instalado localmente." #: ../source/tutorials/installing-packages.rst:159 msgid "Ensure pip, setuptools, and wheel are up to date" -msgstr "" +msgstr "Certifique-se que pip, setuptools e wheel estejam atualizados" #: ../source/tutorials/installing-packages.rst:161 msgid "" @@ -13112,10 +15659,14 @@ msgid "" "up to date copies of the ``setuptools`` and ``wheel`` projects are useful to " "ensure you can also install from source archives::" msgstr "" +"Embora ``pip`` sozinho seja suficiente para instalar a partir de arquivos " +"binários pré-compilados, cópias atualizadas dos projetos ``setuptools`` e " +"``wheel`` são úteis para garantir que você também possa instalar a partir de " +"arquivos fonte::" #: ../source/tutorials/installing-packages.rst:169 msgid "Optionally, create a virtual environment" -msgstr "" +msgstr "Opcionalmente, crie um ambiente virtual" #: ../source/tutorials/installing-packages.rst:171 msgid "" @@ -13123,6 +15674,9 @@ msgid "" "details, but here's the basic `venv`_ [3]_ command to use on a typical Linux " "system:" msgstr "" +"Veja a :ref:`seção abaixo ` para " +"detalhes, mas aqui está o comando básico de `venv`_ [3]_ para usar em um " +"sistema Linux típico:" #: ../source/tutorials/installing-packages.rst:188 msgid "" @@ -13130,10 +15684,12 @@ msgid "" "subdirectory, and configure the current shell to use it as the default " "``python`` environment." msgstr "" +"Isso criará um novo ambiente virtual no subdiretório ``tutorial_env`` e " +"configurará o shell atual para usá-lo como o ambiente ``python`` padrão." #: ../source/tutorials/installing-packages.rst:195 msgid "Creating Virtual Environments" -msgstr "" +msgstr "Criando ambientes virtuais" #: ../source/tutorials/installing-packages.rst:197 msgid "" @@ -13143,6 +15699,11 @@ msgid "" "safely install global command line tools, see :doc:`/guides/installing-stand-" "alone-command-line-tools`." msgstr "" +"\"Ambientes virtuais\" do Python permitem que :term:`pacotes ` Python sejam instalados em um local isolado para uma " +"aplicação em particular, ao invés de serem instalados globalmente. Se você " +"deseja instalar ferramentas de linha de comando globais com segurança, " +"consulte :doc:`/guides/installing-stand-alone-command-line-tools`." #: ../source/tutorials/installing-packages.rst:203 msgid "" @@ -13152,6 +15713,12 @@ msgid "" "your platform’s standard location is), it’s easy to end up in a situation " "where you unintentionally upgrade an application that shouldn’t be upgraded." msgstr "" +"Imagine que você tenha uma aplicação que precisa da versão 1 do LibFoo, mas " +"outra aplicação requer a versão 2. Como você pode usar essas duas " +"aplicações? Se você instalar tudo em /usr/lib/python3.6/site-packages (ou " +"qualquer que seja o local padrão de sua plataforma), é fácil acabar em uma " +"situação em que você atualiza acidentalmente uma aplicação que não deveria " +"ser atualizada." #: ../source/tutorials/installing-packages.rst:209 msgid "" @@ -13159,12 +15726,18 @@ msgid "" "be? If an application works, any change in its libraries or the versions of " "those libraries can break the application." msgstr "" +"Ou, de forma mais geral, e se você quiser instalar uma aplicação e deixá-la " +"como está? Se uma aplicação funcionar, qualquer alteração em suas " +"bibliotecas ou nas versões dessas bibliotecas pode interromper a aplicação." #: ../source/tutorials/installing-packages.rst:213 msgid "" "Also, what if you can’t install :term:`packages ` into " "the global site-packages directory? For instance, on a shared host." msgstr "" +"Além disso, e se você não puder instalar :term:`pacotes ` no diretório global site-packages? Por exemplo, em um host " +"compartilhado." #: ../source/tutorials/installing-packages.rst:216 msgid "" @@ -13172,12 +15745,17 @@ msgid "" "installation directories and they don’t share libraries with other virtual " "environments." msgstr "" +"Em todos esses casos, os ambientes virtuais podem lhe ajudar. Eles têm seus " +"próprios diretórios de instalação e não compartilham bibliotecas com outros " +"ambientes virtuais." #: ../source/tutorials/installing-packages.rst:220 msgid "" "Currently, there are two common tools for creating Python virtual " "environments:" msgstr "" +"Atualmente, existem duas ferramentas comuns para a criação de ambientes " +"virtuais Python:" #: ../source/tutorials/installing-packages.rst:222 msgid "" @@ -13185,6 +15763,9 @@ msgid "" "`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 " "and later." msgstr "" +"`venv`_ está disponível por padrão no Python 3.3 e posterior, e instala :ref:" +"`pip` e :ref:`setuptools` em ambientes virtuais criados no Python 3.4 e " +"posterior." #: ../source/tutorials/installing-packages.rst:225 msgid "" @@ -13193,24 +15774,30 @@ msgid "" "always installed into created virtual environments by default (regardless of " "Python version)." msgstr "" +":ref:`virtualenv` precisa ser instalado separadamente, mas oferece suporte a " +"Python 2.7+ e Python 3.3+, e :ref:`pip`, :ref:`setuptools` e :ref:`wheel` " +"são sempre instalados em ambientes virtuais criados por padrão " +"(independentemente da versão Python)." #: ../source/tutorials/installing-packages.rst:230 msgid "The basic usage is like so:" -msgstr "" +msgstr "O uso básico é assim:" #: ../source/tutorials/installing-packages.rst:232 msgid "Using `venv`_:" -msgstr "" +msgstr "Usando `venv`_:" #: ../source/tutorials/installing-packages.rst:248 msgid "Using :ref:`virtualenv`:" -msgstr "" +msgstr "Usando :ref:`virtualenv`:" #: ../source/tutorials/installing-packages.rst:264 msgid "" "For more information, see the `venv`_ docs or the `virtualenv `_ docs." msgstr "" +"Para mais informações, veja a documentação do `venv`_ ou do`virtualenv " +"`_." #: ../source/tutorials/installing-packages.rst:266 msgid "" @@ -13218,6 +15805,9 @@ msgid "" "environment's variables are set within the current shell, and not in a " "subprocess (which then disappears, having no useful effect)." msgstr "" +"O uso de :command:`source` em shells Unix garante que as variáveis do " +"ambiente virtual sejam definidas dentro do shell atual, e não em um " +"subprocesso (que então desaparece, sem nenhum efeito útil)." #: ../source/tutorials/installing-packages.rst:271 msgid "" @@ -13225,6 +15815,9 @@ msgid "" "`source` command, but should rather run the :command:`activate` script " "directly from the command shell like so:" msgstr "" +"Em ambos os casos acima, os usuários Windows não devem _não_ usar o comando :" +"command:`source`, mas devem executar o script :command:`activate` " +"diretamente do shell de comando assim:" #: ../source/tutorials/installing-packages.rst:281 msgid "" @@ -13233,10 +15826,15 @@ msgid "" "higher level tool, :ref:`Pipenv`, that automatically manages a separate " "virtual environment for each project and application that you work on." msgstr "" +"Gerenciar vários ambientes virtuais diretamente pode se tornar tedioso, " +"então o :ref:`tutorial de gerenciamento de dependências ` apresenta uma ferramenta de alto nível, :ref:`Pipenv`, que " +"gerencia automaticamente um ambiente virtual separado para cada projeto e " +"aplicação no qual você trabalha." #: ../source/tutorials/installing-packages.rst:288 msgid "Use pip for Installing" -msgstr "" +msgstr "Usar pip para instalação" #: ../source/tutorials/installing-packages.rst:290 msgid "" @@ -13245,10 +15843,14 @@ msgid "" "which includes a complete `Reference Guide `_." msgstr "" +":ref:`pip` é o instalador recomendado. A seguir, cobriremos os cenários de " +"uso mais comuns. Para obter mais detalhes, consulte a `documentação do pip " +"`_, que inclui um `Guia de referências `_ completo." #: ../source/tutorials/installing-packages.rst:297 msgid "Installing from PyPI" -msgstr "" +msgstr "Instalando a partir do PyPI" #: ../source/tutorials/installing-packages.rst:299 msgid "" @@ -13260,34 +15862,45 @@ msgid "" "specification <440#version-specifiers>` of the currently supported " "specifiers. Below are some examples." msgstr "" +"O uso mais comum do :ref:`pip` é instalar a partir do :term:`Python Package " +"Index ` usando um :term:`especificador de " +"requisitos `. De modo geral, um especificador " +"de requisitos é composto de um nome de projeto seguido por um :term:" +"`especificador de versão ` opcional . :pep:`440` " +"contém uma :pep:`especificação completa <440#version-specifiers>` dos " +"especificadores suportados atualmente. Abaixo estão alguns exemplos." #: ../source/tutorials/installing-packages.rst:307 msgid "To install the latest version of \"SomeProject\":" -msgstr "" +msgstr "Para instalar a versão mais recente de \"SomeProject\":" #: ../source/tutorials/installing-packages.rst:321 msgid "To install a specific version:" -msgstr "" +msgstr "Para instalar uma versão específica:" #: ../source/tutorials/installing-packages.rst:335 msgid "To install greater than or equal to one version and less than another:" -msgstr "" +msgstr "Para instalar maior ou igual a uma versão e menor que outra:" #: ../source/tutorials/installing-packages.rst:350 msgid "" "To install a version that's :pep:`\"compatible\" <440#compatible-release>` " "with a certain version: [4]_" msgstr "" +"Para instalar uma versão que é :pep:`\"compatível\" <440#compatible-" +"release>` com uma determinada versão: [4]_" #: ../source/tutorials/installing-packages.rst:365 msgid "" "In this case, this means to install any version \"==1.4.*\" version that's " "also \">=1.4.2\"." msgstr "" +"Nesse caso, isso significa instalar qualquer versão \"==1.4.*\" que também " +"seja \">=1.4.2\"." #: ../source/tutorials/installing-packages.rst:370 msgid "Source Distributions vs Wheels" -msgstr "" +msgstr "Distribuições de fonte vs Wheels" #: ../source/tutorials/installing-packages.rst:372 msgid "" @@ -13297,6 +15910,11 @@ msgid "" "can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." msgstr "" +":ref:`pip` pode instalar a partir de :term:`Distribuições Fonte (sdist) " +"` ou :term:`Wheels `, mas se ambos " +"estiverem presentes no PyPI, pip irá preferir um :term:`wheel ` " +"compatível. Você pode substituir o comportamento padrão do pip, por exemplo " +"usando sua opção :ref:`--no-binary `." #: ../source/tutorials/installing-packages.rst:378 msgid "" @@ -13305,6 +15923,10 @@ msgid "" "Distributions (sdist) `, especially when " "a project contains compiled extensions." msgstr "" +":term:`Wheels ` são um formato de :term:`distribuição ` pré-construído que fornece uma instalação mais rápida em " +"comparação com :term:`Distribuições Fonte (sdist) `, especialmente quando um projeto contém extensões compiladas." #: ../source/tutorials/installing-packages.rst:383 msgid "" @@ -13312,10 +15934,13 @@ msgid "" "wheel and cache it for future installs, instead of rebuilding the source " "distribution in the future." msgstr "" +"Se :ref:`pip` não encontrar um wheel para instalar, ele irá construir um " +"wheel localmente e armazená-lo em cache para instalações futuras, ao invés " +"de reconstruir a distribuição fonte no futuro." #: ../source/tutorials/installing-packages.rst:391 msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." -msgstr "" +msgstr "Atualize um ``SomeProject`` já instalado para o mais recente do PyPI." #: ../source/tutorials/installing-packages.rst:408 msgid "Installing to the User Site" @@ -13326,18 +15951,26 @@ msgid "" "To install :term:`packages ` that are isolated to the " "current user, use the ``--user`` flag:" msgstr "" +"Para instalar :term:`pacotes ` que são isolados para " +"o usuário atual, use o sinalizador ``--user``:" #: ../source/tutorials/installing-packages.rst:425 msgid "" "For more information see the `User Installs `_ section from the pip docs." msgstr "" +"Para obter mais informações, consulte a seção `User Installs `_ da documentação do " +"pip." #: ../source/tutorials/installing-packages.rst:429 msgid "" "Note that the ``--user`` flag has no effect when inside a virtual " "environment - all installation commands will affect the virtual environment." msgstr "" +"Observe que o sinalizador ``--user`` não tem efeito quando dentro de um " +"ambiente virtual -- todos os comandos de instalação afetarão o ambiente " +"virtual." #: ../source/tutorials/installing-packages.rst:432 msgid "" @@ -13349,6 +15982,13 @@ msgid "" "available in your shell after installation, you'll need to add the directory " "to your :envvar:`PATH`:" msgstr "" +"Se ``SomeProject`` definir quaisquer scripts de linha de comando ou pontos " +"de entrada de console, ``--user`` fará com que sejam instalados dentro do " +"diretório binário da `base do usuário`_, que pode ou não já estar presente " +"em seu :envvar:`PATH` do shell. (A partir da versão 10, pip exibe um aviso " +"ao instalar qualquer script em um diretório fora de :envvar:`PATH`.) Se os " +"scripts não estiverem disponíveis em seu shell após a instalação, você " +"precisará adicionar o diretório ao seu :envvar:`PATH`:" #: ../source/tutorials/installing-packages.rst:440 msgid "" @@ -13358,6 +15998,12 @@ msgid "" "path to your home directory) so you'll need to add ``~/.local/bin`` to your " "``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." msgstr "" +"No Linux e no macOS você pode encontrar o diretório binário da base do " +"usuário executando ``python -m site --user-base`` e adicionando ``bin`` no " +"final. Por exemplo, isso normalmente imprimirá ``~/.local`` (com ``~`` " +"expandido para o caminho absoluto para o seu diretório inicial), então você " +"precisará adicionar ``~/.local/bin`` para seu ``PATH``. Você pode definir " +"seu ``PATH`` permanentemente `modificando ~/.profile`_." #: ../source/tutorials/installing-packages.rst:446 msgid "" @@ -13369,40 +16015,55 @@ msgid "" "can set your user ``PATH`` permanently in the `Control Panel`_. You may need " "to log out for the ``PATH`` changes to take effect." msgstr "" +"No Windows você pode encontrar o diretório binário base do usuário " +"executando ``py -m site --user-site`` e substituindo ``site-packages`` por " +"``Scripts``. Por exemplo, isso poderia retornar ``C:\\Users\\Username" +"\\AppData\\Roaming\\Python36\\site-packages``, então você precisaria definir " +"seu ``PATH`` para incluir ``C:\\Users\\Username\\AppData\\Roaming" +"\\Python36\\Scripts``. Você pode definir seu usuário ``PATH`` " +"permanentemente no `Painel de Controle`_. Você pode precisar encerrar a " +"sessão para que as alterações de ``PATH`` tenham efeito." #: ../source/tutorials/installing-packages.rst:462 msgid "" "Install a list of requirements specified in a :ref:`Requirements File `." msgstr "" +"Instale uma lista de requisitos especificados em um :ref:`arquivo de " +"requisitos `." #: ../source/tutorials/installing-packages.rst:478 msgid "Installing from VCS" -msgstr "" +msgstr "Instalando a partir de VCS" #: ../source/tutorials/installing-packages.rst:480 msgid "" "Install a project from VCS in \"editable\" mode. For a full breakdown of " "the syntax, see pip's section on :ref:`VCS Support `." msgstr "" +"Instale um projeto a partir de VCS em um modo \"editável\". Para um " +"instrução completa da sintaxe, veja a seção do pip em :ref:`VCS Support `." #: ../source/tutorials/installing-packages.rst:502 msgid "Installing from other Indexes" -msgstr "" +msgstr "Instalando a partir de outros índices" #: ../source/tutorials/installing-packages.rst:504 msgid "Install from an alternate index" -msgstr "" +msgstr "Instalar a partir de um índice alternativo" #: ../source/tutorials/installing-packages.rst:518 msgid "" "Search an additional index during install, in addition to :term:`PyPI " "`" msgstr "" +"Pesquise um índice adicional durante a instalação, além do :term:`PyPI " +"`" #: ../source/tutorials/installing-packages.rst:534 msgid "Installing from a local src tree" -msgstr "" +msgstr "Instalando a partir de uma árvore de fontes local" #: ../source/tutorials/installing-packages.rst:537 msgid "" @@ -13411,24 +16072,30 @@ msgid "" "way that the project appears to be installed, but yet is still editable from " "the src tree." msgstr "" +"Instale a partir dos fontes locais em `Development Mode `_, ou seja, de " +"tal forma que o projeto parece estar instalado, mas ainda seja editável a " +"partir da árvore de fontes." #: ../source/tutorials/installing-packages.rst:554 msgid "You can also install normally from src" -msgstr "" +msgstr "Você também pode instalar normalmente a partir dos fontes" #: ../source/tutorials/installing-packages.rst:571 msgid "Install a particular source archive file." -msgstr "" +msgstr "Instale um arquivo de pacote fonte em particular." #: ../source/tutorials/installing-packages.rst:585 msgid "" "Install from a local directory containing archives (and don't check :term:" "`PyPI `)" msgstr "" +"Instale de um pacote contendo diretório local (e não verifique o :term:`PyPI " +"`)" #: ../source/tutorials/installing-packages.rst:605 msgid "Installing from other sources" -msgstr "" +msgstr "Instalando a partir de outras fontes" #: ../source/tutorials/installing-packages.rst:607 msgid "" @@ -13437,24 +16104,30 @@ msgid "" "index format, and use the ``--extra-index-url`` flag to direct pip to use " "that index." msgstr "" +"Para instalar a partir de outras fontes de dados (por exemplo, armazenamento " +"Amazon S3), você pode criar uma aplicação auxiliar que apresente os dados em " +"um formato de índice compatível com :pep:`503` e usar o sinalizador ``--" +"extra-index-url`` para direcionar o pip para usar esse índice." #: ../source/tutorials/installing-packages.rst:619 msgid "Installing Prereleases" -msgstr "" +msgstr "Instalando pré-lançamentos" #: ../source/tutorials/installing-packages.rst:621 msgid "" "Find pre-release and development versions, in addition to stable versions. " "By default, pip only finds stable versions." msgstr "" +"Encontre versões de pré-lançamento e desenvolvimento, além de versões " +"estáveis. Por padrão, pip só encontra versões estáveis." #: ../source/tutorials/installing-packages.rst:637 msgid "Installing Setuptools \"Extras\"" -msgstr "" +msgstr "Instalando Setuptools \"extras\"" #: ../source/tutorials/installing-packages.rst:639 msgid "Install `setuptools extras`_." -msgstr "" +msgstr "Instale `setuptools extras`_." #: ../source/tutorials/installing-packages.rst:659 msgid "" @@ -13462,6 +16135,9 @@ msgid "" "command:`curl` that verifies SSL certificates when downloading from https " "URLs." msgstr "" +"\"Segurança\" neste contexto significa usar um navegador moderno ou uma " +"ferramenta como :command:`curl` que verifica os certificados SSL ao baixar " +"de URLs https." #: ../source/tutorials/installing-packages.rst:668 msgid "" @@ -13469,22 +16145,29 @@ msgid "" "`virtualenv`) will create virtualenv environments with ``pip`` pre-" "installed, thereby making it an equal alternative to :ref:`virtualenv`." msgstr "" +"Começando com Python 3.4, ``venv`` (uma alternativa à biblioteca padrão " +"para :ref:`virtualenv`) criará ambientes do virtualenv com ``pip`` pré-" +"instalado, tornando-o uma alternativa igual a :ref:`virtualenv`." #: ../source/tutorials/installing-packages.rst:673 msgid "" "The compatible release specifier was accepted in :pep:`440` and support was " "released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" msgstr "" +"O especificador de versão compatível foi aceito em :pep:`440` e o suporte " +"foi lançado em :ref:`setuptools` v8.0 e :ref:`pip` v6.0" #: ../source/tutorials/managing-dependencies.rst:4 msgid "Managing Application Dependencies" -msgstr "" +msgstr "Gerenciando dependências de aplicações" #: ../source/tutorials/managing-dependencies.rst:6 msgid "" "The :ref:`package installation tutorial ` covered the " "basics of getting set up to install and update Python packages." msgstr "" +"O :ref:`tutorial de instalação do pacote ` cobriu os " +"fundamentos da configuração para instalar e atualizar pacotes Python." #: ../source/tutorials/managing-dependencies.rst:9 msgid "" @@ -13493,6 +16176,10 @@ msgid "" "up development environments automatically for projects with multiple " "contributors." msgstr "" +"No entanto, executar esses comandos interativamente pode se tornar tedioso " +"até mesmo para seus próprios projetos pessoais, e as coisas ficam ainda mais " +"difíceis ao tentar configurar ambientes de desenvolvimento automaticamente " +"para projetos com vários contribuidores." #: ../source/tutorials/managing-dependencies.rst:13 msgid "" @@ -13500,6 +16187,10 @@ msgid "" "dependencies for an application. It will show you how to install and use the " "necessary tools and make strong recommendations on best practices." msgstr "" +"Este tutorial orienta você no uso de :ref:`Pipenv` para gerenciar " +"dependências para uma aplicação. Ele mostrará como instalar e usar as " +"ferramentas necessárias e fará recomendações fortes sobre as melhores " +"práticas." #: ../source/tutorials/managing-dependencies.rst:17 msgid "" @@ -13510,6 +16201,13 @@ msgid "" "(including web applications), but is also very well suited to managing " "development and testing environments for any kind of project." msgstr "" +"Lembre-se de que Python é usado para muitos propósitos diferentes e, " +"precisamente, como você deseja gerenciar suas dependências pode mudar com " +"base em como você decide publicar seu software. A orientação apresentada " +"aqui é mais diretamente aplicável ao desenvolvimento e implantação de " +"serviços de rede (incluindo aplicações web), mas também é muito adequada " +"para gerenciar ambientes de desenvolvimento e teste para qualquer tipo de " +"projeto." #: ../source/tutorials/managing-dependencies.rst:24 msgid "" @@ -13518,10 +16216,14 @@ msgid "" "python-poetry/poetry>`_ project as an alternative dependency management " "solution." msgstr "" +"Desenvolvedores de bibliotecas Python, ou de aplicações que tem suporte a " +"distribuição como bibliotecas Python, também devem considerar o projeto " +"`poetry `_ como uma solução " +"alternativa de gerenciamento de dependências." #: ../source/tutorials/managing-dependencies.rst:30 msgid "Installing Pipenv" -msgstr "" +msgstr "Instalando Pipenv" #: ../source/tutorials/managing-dependencies.rst:32 msgid "" @@ -13531,10 +16233,16 @@ msgid "" "Pipenv is recommended for collaborative projects as it's a higher-level tool " "that simplifies dependency management for common use cases." msgstr "" +":ref:`Pipenv` é um gerenciador de dependências para projetos Python. Se você " +"está familiarizado com o `npm`_ do Node.js ou o `bundler`_ do Ruby, é " +"semelhante em espírito a essas ferramentas. Enquanto :ref:`pip` por si só " +"costuma ser suficiente para uso pessoal, Pipenv é recomendado para projetos " +"colaborativos por ser uma ferramenta de nível superior que simplifica o " +"gerenciamento de dependências para casos de uso comuns." #: ../source/tutorials/managing-dependencies.rst:38 msgid "Use ``pip`` to install Pipenv:" -msgstr "" +msgstr "Use ``pip`` para instalar Pipenv:" #: ../source/tutorials/managing-dependencies.rst:54 msgid "" @@ -13543,10 +16251,15 @@ msgid "" "you'll need to add the `user base`_'s binary directory to your ``PATH``. " "See :ref:`Installing to the User Site` for more information." msgstr "" +"Isso faz uma `instalação do usuário`_ para evitar quebrar qualquer pacote do " +"sistema. Se ``pipenv`` não estiver disponível em seu shell após a " +"instalação, você precisará adicionar o diretório binário da `base de " +"usuário`_ ao seu ``PATH``. Veja :ref:`Instalando no Site do Usuário` para " +"mais informações." #: ../source/tutorials/managing-dependencies.rst:65 msgid "Installing packages for your project" -msgstr "" +msgstr "Instalando pacotes para seu projeto" #: ../source/tutorials/managing-dependencies.rst:67 msgid "" @@ -13554,6 +16267,9 @@ msgid "" "change into your project's directory (or just an empty directory for this " "tutorial) and run:" msgstr "" +"O Pipenv gerencia dependências por projeto. Para instalar pacotes, mude para " +"o diretório do seu projeto (ou apenas um diretório vazio para este tutorial) " +"e execute:" #: ../source/tutorials/managing-dependencies.rst:76 msgid "" @@ -13563,24 +16279,32 @@ msgid "" "when you share your project with others. You should get output similar to " "this (although the exact paths shown will vary):" msgstr "" +"Pipenv irá instalar a biblioteca `Requests`_ e criar um ``Pipfile`` para " +"você no diretório do seu projeto. O :ref:`Pipfile` é usado para rastrear " +"quais dependências seu projeto precisa no caso de você precisar reinstalá-" +"las, como quando você compartilha seu projeto com outras pessoas. Você deve " +"obter uma saída semelhante a esta (embora os caminhos exatos mostrados " +"variem):" #: ../source/tutorials/managing-dependencies.rst:112 msgid "Using installed packages" -msgstr "" +msgstr "Usando pacotes instalados" #: ../source/tutorials/managing-dependencies.rst:114 msgid "" "Now that Requests is installed you can create a simple :file:`main.py` file " "to use it:" msgstr "" +"Agora que Requests está instalado você pode criar um :file:`main.py` simples " +"para usá-lo:" #: ../source/tutorials/managing-dependencies.rst:125 msgid "Then you can run this script using ``pipenv run``:" -msgstr "" +msgstr "Então, você pode executar este script usando ``pipenv run``:" #: ../source/tutorials/managing-dependencies.rst:131 msgid "You should get output similar to this:" -msgstr "" +msgstr "Você deve obter uma saída similar a esta:" #: ../source/tutorials/managing-dependencies.rst:137 msgid "" @@ -13588,17 +16312,22 @@ msgid "" "your script. It's also possible to spawn a new shell that ensures all " "commands have access to your installed packages with ``pipenv shell``." msgstr "" +"Usar ``pipenv run`` garante que seus pacotes instalados estejam disponíveis " +"para seu script. Também é possível gerar um novo shell que garante que todos " +"os comandos tenham acesso aos seus pacotes instalados com ``pipenv shell``." #: ../source/tutorials/managing-dependencies.rst:143 #: ../source/tutorials/packaging-projects.rst:594 msgid "Next steps" -msgstr "" +msgstr "Próximos passos" #: ../source/tutorials/managing-dependencies.rst:145 msgid "" "Congratulations, you now know how to effectively manage dependencies and " "development environments on a collaborative Python project! ✨ 🍰 ✨" msgstr "" +"Parabéns, agora você sabe como gerenciar dependências e ambientes de " +"desenvolvimento com eficácia em um projeto colaborativo Python! ✨ 🍰 ✨" #: ../source/tutorials/managing-dependencies.rst:148 msgid "" @@ -13606,6 +16335,9 @@ msgid "" "see the :ref:`tutorial on packaging and distributing packages `." msgstr "" +"Se você estiver interessado em criar e distribuir seus próprios pacotes " +"Python, veja o :ref:`tutorial sobre empacotamento e distribuição de pacotes " +"`." #: ../source/tutorials/managing-dependencies.rst:151 msgid "" @@ -13614,10 +16346,14 @@ msgid "" "environment with ``pipenv install -e `` " "(e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." msgstr "" +"Observe que quando sua aplicação inclui definições de pacotes fonte do " +"Python, elas (e suas dependências) podem ser adicionadas ao seu ambiente de " +"``pipenv`` com ``pipenv install -e `` " +"(por exemplo, ``pipenv install -e .`` ou ``pipenv install -e src``)." #: ../source/tutorials/managing-dependencies.rst:160 msgid "Other Tools for Application Dependency Management" -msgstr "" +msgstr "Outras ferramentas para gerenciamento de dependências de aplicações" #: ../source/tutorials/managing-dependencies.rst:162 msgid "" @@ -13625,6 +16361,10 @@ msgid "" "isn't working well for you or your use case, you may want to explore these " "other tools and techniques to see if one of them is a better fit:" msgstr "" +"Se você achar que essa abordagem específica para gerenciar dependências de " +"aplicações não está funcionando bem para você ou seu caso de uso, convém " +"explorar essas outras ferramentas e técnicas para ver se uma delas se " +"encaixa melhor:" #: ../source/tutorials/managing-dependencies.rst:166 msgid "" @@ -13636,6 +16376,13 @@ msgid "" "components from PyPI will itself support distribution as a ``pip``-" "installable Python package)." msgstr "" +"`poetry `__ para uma ferramenta " +"comparável em escopo a ``pipenv`` que se concentra mais diretamente em casos " +"de uso onde o repositório sendo gerenciado é estruturado como um projeto " +"Python com um arquivo ``pyproject.toml`` válido (por outro lado, ``pipenv`` " +"explicitamente evita fazer a suposição de que a aplicação que está sendo " +"trabalhado que depende dos componentes do PyPI será compatível com a " +"distribuição como um pacote Python instalável com ``pip``)." #: ../source/tutorials/managing-dependencies.rst:172 msgid "" @@ -13644,12 +16391,19 @@ msgid "" "versions, tagging releases, and creating new skeleton projects from project " "templates)" msgstr "" +"`hatch `_ para uma cobertura opinativa de " +"ainda mais etapas no fluxo de trabalho de gerenciamento de projeto (como " +"incrementar versões, marcar lançamentos e criar novos projetos básicos a " +"partir de modelos de projeto)" #: ../source/tutorials/managing-dependencies.rst:175 msgid "" "`pip-tools `_ to build your own " "custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" msgstr "" +"`pip-tools `_ para construir seu " +"próprio fluxo de trabalho personalizado a partir de peças de nível inferior " +"como ``pip-compile`` e ``pip-sync``" #: ../source/tutorials/managing-dependencies.rst:177 msgid "" @@ -13658,10 +16412,14 @@ msgid "" "lock files or converting them to pip-tools compatible output. Designed for " "containerized Python applications but not limited to them." msgstr "" +"micropipenv `_ é um invólucro " +"leve para pip para oferecer suporte a requirements.txt, arquivos de bloqueio " +"de Pipenv e de Poesia ou convertê-los em saída compatível com pip-tools. " +"Projetado para aplicações em contêineres Python, mas não se limitando a elas." #: ../source/tutorials/packaging-projects.rst:2 msgid "Packaging Python Projects" -msgstr "" +msgstr "Empacotando projetos Python" #: ../source/tutorials/packaging-projects.rst:4 msgid "" @@ -13670,6 +16428,9 @@ msgid "" "package, how to build the package, and how to upload it to the Python " "Package Index." msgstr "" +"Este tutorial mostra como empacotar um projeto Python simples. Ele mostrará " +"como adicionar os arquivos e a estrutura necessários para criar o pacote, " +"como construir o pacote e como enviá-lo para o Índice de Pacotes do Python." #: ../source/tutorials/packaging-projects.rst:10 msgid "" @@ -13677,16 +16438,21 @@ msgid "" "command and its output, then `open an issue`_ on the `packaging-problems`_ " "repository on GitHub. We'll do our best to help you!" msgstr "" +"Se você tiver problemas para executar os comandos neste tutorial, copie o " +"comando e sua saída e, em seguida, `relate um problema`_ no repositório " +"`packaging-problems`_ no GitHub. Faremos o nosso melhor para ajudá-lo!" #: ../source/tutorials/packaging-projects.rst:18 msgid "" "Some of the commands require a newer version of :ref:`pip`, so start by " "making sure you have the latest version installed:" msgstr "" +"Alguns comandos exigem uma nova versão de :ref:`pip`, então comece " +"certificando-se de que você tenha a versão mais recente instalada:" #: ../source/tutorials/packaging-projects.rst:35 msgid "A simple project" -msgstr "" +msgstr "Um projeto simples" #: ../source/tutorials/packaging-projects.rst:37 msgid "" @@ -13694,16 +16460,21 @@ msgid "" "following this tutorial as-is using this project, before packaging your own " "project." msgstr "" +"Este tutorial usa um projeto simples chamado ``example_package``. " +"Recomendamos seguir este tutorial como está usando este projeto, antes de " +"empacotar seu próprio projeto." #: ../source/tutorials/packaging-projects.rst:41 msgid "Create the following file structure locally:" -msgstr "" +msgstr "Crie a seguinte estrutura de arquivos localmente:" #: ../source/tutorials/packaging-projects.rst:51 msgid "" ":file:`__init__.py` is required to import the directory as a package, and " "should be empty." msgstr "" +":file:`__init__.py` é necessário para importar o diretório como um pacote, e " +"deve estar vazio." #: ../source/tutorials/packaging-projects.rst:54 msgid "" @@ -13711,6 +16482,9 @@ msgid "" "contain the logic (functions, classes, constants, etc.) of your package. " "Open that file and enter the following content:" msgstr "" +":file:`example.py` é um exemplo de módulo dentro do pacote que pode conter a " +"lógica (funções, classes, constantes, etc.) do seu pacote. Abra esse arquivo " +"e insira o seguinte conteúdo:" #: ../source/tutorials/packaging-projects.rst:63 msgid "" @@ -13718,34 +16492,43 @@ msgid "" "`import packages `, take a few minutes to read over the " "`Python documentation for packages and modules`_." msgstr "" +"Se você não está familiarizado com :term:`módulos ` e :term:`pacotes " +"de importação ` do Python, reserve alguns minutos para " +"ler a `documentação do Python para pacotes e módulos`_." #: ../source/tutorials/packaging-projects.rst:67 msgid "" "Once you create this structure, you'll want to run all of the commands in " "this tutorial within the ``packaging_tutorial`` directory." msgstr "" +"Depois de criar esta estrutura, você desejará executar todos os comandos " +"neste tutorial dentro do diretório ``packaging_tutorial``." #: ../source/tutorials/packaging-projects.rst:75 msgid "Creating the package files" -msgstr "" +msgstr "Criando arquivos do pacote" #: ../source/tutorials/packaging-projects.rst:77 msgid "" "You will now add files that are used to prepare the project for " "distribution. When you're done, the project structure will look like this:" msgstr "" +"Agora você adicionará arquivos que são usados para preparar o projeto para " +"distribuição. Quando terminar, a estrutura do projeto ficará assim:" #: ../source/tutorials/packaging-projects.rst:95 msgid "Creating a test directory" -msgstr "" +msgstr "Criando um diretório de teste" #: ../source/tutorials/packaging-projects.rst:97 msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." msgstr "" +":file:`tests/` é um espaço reservado, ou *placeholder*, para arquivos de " +"teste. Deixe-o vazio por enquanto." #: ../source/tutorials/packaging-projects.rst:101 msgid "Creating pyproject.toml" -msgstr "" +msgstr "Criando pyproject.toml" #: ../source/tutorials/packaging-projects.rst:103 msgid "" @@ -13753,6 +16536,10 @@ msgid "" "what is required to build your project. This tutorial uses :ref:" "`setuptools`, so open :file:`pyproject.toml` and enter the following content:" msgstr "" +":file:`pyproject.toml` informa as ferramentas de construção (como :ref:`pip` " +"e :ref:`build`) o que é necessário para construir seu projeto. Este tutorial " +"usa :ref:`setuptools`, então abra :file:`pyproject.toml` e insira o seguinte " +"conteúdo:" #: ../source/tutorials/packaging-projects.rst:117 msgid "" @@ -13760,6 +16547,9 @@ msgid "" "your package. Listing something here will *only* make it available during " "the build, not after it is installed." msgstr "" +"``build-system.requires`` fornece uma lista de pacotes que são necessários " +"para construir seu pacote. Listar algo aqui *apenas* o tornará disponível " +"durante a construção, não depois de instalado." #: ../source/tutorials/packaging-projects.rst:121 msgid "" @@ -13769,18 +16559,23 @@ msgid "" "details would be completely different than the :ref:`setuptools` " "configuration described below." msgstr "" +"``build-system.build-backend`` é o nome do objeto Python que será usado para " +"realizar a construção. Se você fosse usar um sistema de construção " +"diferente, como :ref:`flit` ou :ref:`poetry`, eles iriam aqui, e os detalhes " +"de configuração seriam completamente diferentes da configuração do :ref:" +"`setuptools` descrita abaixo." #: ../source/tutorials/packaging-projects.rst:127 msgid "See :pep:`517` and :pep:`518` for background and details." -msgstr "" +msgstr "Veja :pep:`517` e :pep:`518` para um informações e detalhes." #: ../source/tutorials/packaging-projects.rst:131 msgid "Configuring metadata" -msgstr "" +msgstr "Configurando metadados" #: ../source/tutorials/packaging-projects.rst:133 msgid "There are two types of metadata: static and dynamic." -msgstr "" +msgstr "Há dois tipos de metadados: estáticos e dinâmicos." #: ../source/tutorials/packaging-projects.rst:135 msgid "" @@ -13788,6 +16583,9 @@ msgid "" "This is simpler, easier to read, and avoids many common errors, like " "encoding errors." msgstr "" +"Metadados estáticos (:file:`setup.cfg`): garantidamente os mesmos sempre. " +"Isso é mais simples, fácil de ler e evita muitos erros comuns, como erros de " +"codificação." #: ../source/tutorials/packaging-projects.rst:137 msgid "" @@ -13795,6 +16593,10 @@ msgid "" "that are dynamic or determined at install-time, as well as extension modules " "or extensions to setuptools, need to go into :file:`setup.py`." msgstr "" +"Metadados dinâmicos (:file:`setup.py`): possivelmente não determinísticos. " +"Quaisquer itens que são dinâmicos ou determinados no momento da instalação, " +"bem como módulos de extensão ou extensões para setuptools, precisam ir para :" +"file:`setup.py`." #: ../source/tutorials/packaging-projects.rst:141 msgid "" @@ -13803,6 +16605,11 @@ msgid "" "necessary. :file:`setup.py` used to be required, but can be omitted with " "newer versions of setuptools and pip." msgstr "" +"Metadados estáticos (:file:`setup.cfg`) devem ser preferidos. Metadados " +"dinâmicos (:file:`setup.py`) devem ser usados apenas como uma saída de " +"emergência quando for absolutamente necessário. :file:`setup.py` costumava " +"ser necessário, mas pode ser omitido com as versões mais recentes de " +"setuptools e pip." #: ../source/tutorials/packaging-projects.rst:148 msgid "" @@ -13811,6 +16618,10 @@ msgid "" "which code files to include. Eventually much of this configuration may be " "able to move to :file:`pyproject.toml`." msgstr "" +":file:`setup.cfg` é o arquivo de configuração para :ref:`setuptools`. Ele " +"informa ao setuptools sobre o seu pacote (como o nome e a versão), bem como " +"os arquivos de código a serem incluídos. Eventualmente, grande parte desta " +"configuração pode ser movida para :file:`pyproject.toml`." #: ../source/tutorials/packaging-projects.rst:153 msgid "" @@ -13819,6 +16630,10 @@ msgid "" "and that your package doesn't conflict with packages uploaded by other " "people following this tutorial." msgstr "" +"Abra :file:`setup.cfg` e insira o seguinte conteúdo. Mude o ``name`` para " +"incluir seu nome de usuário; isso garante que você tenha um nome de pacote " +"exclusivo e que seu pacote não entre em conflito com os pacotes carregados " +"por outras pessoas que seguem este tutorial." #: ../source/tutorials/packaging-projects.rst:185 msgid "" @@ -13828,6 +16643,11 @@ msgid "" "quotes around values. This example package uses a relatively minimal set of " "``metadata``:" msgstr "" +"Há uma `variedade de metadados e opções `_ suportados aqui. Isso está no " +"formato :doc:`configparser `; não coloque aspas " +"em torno dos valores. Este pacote de exemplo usa um conjunto relativamente " +"mínimo de ``metadata``:" #: ../source/tutorials/packaging-projects.rst:191 #: ../source/tutorials/packaging-projects.rst:286 @@ -13838,6 +16658,11 @@ msgid "" "username,** as this ensures you won't try to upload a package with the same " "name as one which already exists." msgstr "" +"``name`` é o *nome da distribuição* do seu pacote. Pode ser qualquer nome, " +"desde que contenha apenas letras, números, ``_`` e ``-``. Também não deve " +"ser feito em pypi.org. **Certifique-se de atualizá-lo com seu nome de " +"usuário**, pois isso garante que você não tentará enviar um pacote com o " +"mesmo nome de um que já existe." #: ../source/tutorials/packaging-projects.rst:196 msgid "" @@ -13845,6 +16670,9 @@ msgid "" "versions. You can use ``file:`` or ``attr:`` directives to read from a file " "or package attribute." msgstr "" +"``version`` é a versão do pacote. Consulte a :pep:`440` para obter mais " +"detalhes sobre as versões. Você pode usar as diretivas ``file:`` ou ``attr:" +"`` para ler um arquivo ou atributo de pacote." #: ../source/tutorials/packaging-projects.rst:199 #: ../source/tutorials/packaging-projects.rst:293 @@ -13852,11 +16680,12 @@ msgid "" "``author`` and ``author_email`` are used to identify the author of the " "package." msgstr "" +"``author`` e ``author_email`` são usados para identificar o autor do pacote." #: ../source/tutorials/packaging-projects.rst:201 #: ../source/tutorials/packaging-projects.rst:295 msgid "``description`` is a short, one-sentence summary of the package." -msgstr "" +msgstr "``description`` é um resumo curto do pacote contendo apenas uma frase." #: ../source/tutorials/packaging-projects.rst:202 msgid "" @@ -13865,6 +16694,10 @@ msgid "" "long description is loaded from :file:`README.md` (which is a common " "pattern) using the ``file:`` directive." msgstr "" +"``long_description`` é uma descrição detalhada do pacote. Isso é mostrado na " +"página de detalhes do pacote no Índice do Pacotes Python. Neste caso, a " +"descrição longa é carregada de :file:`README.md` (que é um padrão comum) " +"usando a diretiva ``file:``." #: ../source/tutorials/packaging-projects.rst:206 #: ../source/tutorials/packaging-projects.rst:300 @@ -13872,6 +16705,8 @@ msgid "" "``long_description_content_type`` tells the index what type of markup is " "used for the long description. In this case, it's Markdown." msgstr "" +"``long_description_content_type`` diz ao índice que tipo de marcação é usado " +"para a descrição longa. Neste caso, é Markdown." #: ../source/tutorials/packaging-projects.rst:208 #: ../source/tutorials/packaging-projects.rst:302 @@ -13880,6 +16715,9 @@ msgid "" "will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting " "service." msgstr "" +"``url`` é a URL da página inicial do projeto. Para muitos projetos, será " +"apenas um link para GitHub, GitLab, Bitbucket ou serviço de hospedagem de " +"código semelhante." #: ../source/tutorials/packaging-projects.rst:211 #: ../source/tutorials/packaging-projects.rst:305 @@ -13887,6 +16725,9 @@ msgid "" "``project_urls`` lets you list any number of extra links to show on PyPI. " "Generally this could be to documentation, issue trackers, etc." msgstr "" +"``project_urls`` permite listar qualquer número de links extras para mostrar " +"no PyPI. Geralmente, isso pode ser para documentação, rastreadores de " +"problemas, etc." #: ../source/tutorials/packaging-projects.rst:213 #: ../source/tutorials/packaging-projects.rst:307 @@ -13899,10 +16740,17 @@ msgid "" "your package will work on. For a complete list of classifiers, see https://" "pypi.org/classifiers/." msgstr "" +"``classifiers`` fornece o índice e :ref:`pip` alguns metadados adicionais " +"sobre seu pacote. Nesse caso, o pacote é compatível apenas com Python 3, " +"está licenciado sob a licença MIT e é independente do sistema operacional. " +"Você deve sempre incluir pelo menos a(s) versão(ões) do Python em que seu " +"pacote funciona, em que licença seu pacote está disponível e em quais " +"sistemas operacionais seu pacote funcionará. Para obter uma lista completa " +"de classificadores, consulte https://pypi.org/classifiers/." #: ../source/tutorials/packaging-projects.rst:221 msgid "In the ``options`` category, we have controls for setuptools itself:" -msgstr "" +msgstr "Na categoria ``options``, temos controles para o próprio setuptools:" #: ../source/tutorials/packaging-projects.rst:223 msgid "" @@ -13911,6 +16759,10 @@ msgid "" "project that contains all Python source files for the package --- so in this " "case the ``src`` directory is designated the root package." msgstr "" +"``package_dir`` é um mapeamento de nomes e diretórios de pacotes. Um nome de " +"pacote vazio representa o \"pacote raiz\" -- o diretório no projeto que " +"contém todos os arquivos fonte Python para o pacote -- então, neste caso, o " +"diretório ``src`` é designado o pacote raiz." #: ../source/tutorials/packaging-projects.rst:227 msgid "" @@ -13922,6 +16774,13 @@ msgid "" "use. In this case, the list of packages will be ``example_package`` as " "that's the only package present." msgstr "" +"``packages`` é uma lista de todos os Python :term:`pacotes de importação " +"` que devem ser incluídos no :term:`pacote de " +"distribuição `. Em vez de listar cada pacote " +"manualmente, podemos usar a diretiva ``find:`` para descobrir " +"automaticamente todos os pacotes e subpacotes e ``options.packages.find`` " +"para especificar o ``package_dir`` a ser usado. Neste caso, a lista de " +"pacotes será ``example_package`` visto que é o único pacote presente." #: ../source/tutorials/packaging-projects.rst:234 msgid "" @@ -13929,6 +16788,9 @@ msgid "" "Installers like :ref:`pip` will look back through older versions of packages " "until it finds one that has a matching Python version." msgstr "" +"``python_requires`` fornece as versões do Python suportadas pelo seu " +"projeto. Instaladores como :ref:`pip` olharão para as versões anteriores dos " +"pacotes até encontrar um que tenha uma versão correspondente do Python." #: ../source/tutorials/packaging-projects.rst:238 #: ../source/tutorials/packaging-projects.rst:329 @@ -13936,6 +16798,8 @@ msgid "" "There are many more than the ones mentioned here. See :doc:`/guides/" "distributing-packages-using-setuptools` for more details." msgstr "" +"Existem muitos mais do que os mencionados aqui. Veja :doc:`/guides/" +"distributing-packages-using-setuptools` para mais detalhes." #: ../source/tutorials/packaging-projects.rst:244 msgid "" @@ -13943,6 +16807,9 @@ msgid "" "setuptools about your package (such as the name and version) as well as " "which code files to include." msgstr "" +":file:`setup.py` é o script de construção para :ref:`setuptools`. Ele " +"informa ao setuptools sobre o seu pacote (como o nome e a versão), bem como " +"os arquivos de código a serem incluídos." #: ../source/tutorials/packaging-projects.rst:248 msgid "" @@ -13951,18 +16818,26 @@ msgid "" "and that your package doesn't conflict with packages uploaded by other " "people following this tutorial." msgstr "" +"Abra :file:`setup.py` e insira o seguinte conteúdo. Mude o ``name`` para " +"incluir seu nome de usuário; isso garante que você tenha um nome de pacote " +"exclusivo e que seu pacote não entre em conflito com os pacotes carregados " +"por outras pessoas que seguem este tutorial." #: ../source/tutorials/packaging-projects.rst:283 msgid "" ":func:`setup` takes several arguments. This example package uses a " "relatively minimal set:" msgstr "" +":func:`setup` recebe vários argumentos. Este pacote de exemplo usa um " +"conjunto relativamente mínimo:" #: ../source/tutorials/packaging-projects.rst:291 msgid "" "``version`` is the package version. See :pep:`440` for more details on " "versions." msgstr "" +"``version`` é a versão do pacote. Consulte :pep:`440` para obter mais " +"detalhes sobre as versões." #: ../source/tutorials/packaging-projects.rst:296 msgid "" @@ -13970,6 +16845,9 @@ msgid "" "on the package detail page on the Python Package Index. In this case, the " "long description is loaded from :file:`README.md`, which is a common pattern." msgstr "" +"``long_description`` é uma descrição detalhada do pacote. Isso é mostrado na " +"página de detalhes do pacote no Índice do Pacotes do Python. Neste caso, a " +"descrição longa é carregada de :file:`README.md`, que é um padrão comum." #: ../source/tutorials/packaging-projects.rst:314 msgid "" @@ -13979,6 +16857,10 @@ msgid "" "package --- so in this case the ``src`` directory is designated the root " "package." msgstr "" +"``package_dir`` é um dicionário com nomes de pacotes para chaves e " +"diretórios para valores. Um nome de pacote vazio representa o \"pacote raiz" +"\" -- o diretório no projeto que contém todos os arquivos fonte Python para " +"o pacote -- então, neste caso, o diretório ``src`` é designado o pacote raiz." #: ../source/tutorials/packaging-projects.rst:319 msgid "" @@ -13989,6 +16871,13 @@ msgid "" "subpackages under ``package_dir``. In this case, the list of packages will " "be ``example_package`` as that's the only package present." msgstr "" +"``packages`` é uma lista de todos os :term:`pacotes de importação ` do Python que devem ser incluídos no :term:`pacote de " +"distribuição `. Em vez de listar cada pacote " +"manualmente, podemos usar :func:`find_packages` para descobrir " +"automaticamente todos os pacotes e subpacotes em ``package_dir``. Neste " +"caso, a lista de pacotes será ``example_package`` visto que é o único pacote " +"presente." #: ../source/tutorials/packaging-projects.rst:325 msgid "" @@ -13996,16 +16885,21 @@ msgid "" "Installers like :ref:`pip` will look back though older versions of packages " "until it finds one that has a matching Python version." msgstr "" +"``python_requires`` fornece as versões do Python suportadas pelo seu " +"projeto. Instaladores como :ref:`pip` olharão para as versões anteriores dos " +"pacotes até encontrar um que tenha uma versão correspondente do Python." #: ../source/tutorials/packaging-projects.rst:333 msgid "Creating README.md" -msgstr "" +msgstr "Criando README.md" #: ../source/tutorials/packaging-projects.rst:335 msgid "" "Open :file:`README.md` and enter the following content. You can customize " "this if you'd like." msgstr "" +"Abra :file:`README.md` e insira o seguinte conteúdo. Você pode personalizar " +"isso se desejar." #: ../source/tutorials/packaging-projects.rst:347 msgid "" @@ -14014,10 +16908,15 @@ msgid "" "code when you :ref:`generate a source distribution `. " "Newer versions of :ref:`setuptools` will do this automatically." msgstr "" +"Porque nossa configuração carrega :file:`README.md` para fornecer um " +"``long_description``, :file:`README.md` deve ser incluído junto com seu " +"código quando você :ref:`gerar uma distribuição fonte `. Versões mais recentes de :ref:`setuptools` farão isso " +"automaticamente." #: ../source/tutorials/packaging-projects.rst:354 msgid "Creating a LICENSE" -msgstr "" +msgstr "Criando um LICENSE" #: ../source/tutorials/packaging-projects.rst:356 msgid "" @@ -14027,10 +16926,16 @@ msgid "" "choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` " "and enter the license text. For example, if you had chosen the MIT license:" msgstr "" +"É importante que cada pacote enviado para o Índice de Pacotes do Python " +"inclua uma licença. Isso informa aos usuários que instalam seu pacote os " +"termos sob os quais eles podem usá-lo. Para obter ajuda na escolha de uma " +"licença, consulte https://choosealicense.com/. Depois de escolher uma " +"licença, abra :file:`LICENSE` e digite o texto da licença. Por exemplo, se " +"você escolheu a licença MIT:" #: ../source/tutorials/packaging-projects.rst:387 msgid "Including other files" -msgstr "" +msgstr "Incluindo outros arquivos" #: ../source/tutorials/packaging-projects.rst:389 msgid "" @@ -14038,6 +16943,9 @@ msgid "" "distribution `. If you want to control " "what goes in this explicitly, see :ref:`Using MANIFEST.in`." msgstr "" +"Os arquivos listados acima serão incluídos automaticamente em sua :term:" +"`distribuição fonte `. Se você deseja " +"controlar o que entra explicitamente, consulte :ref:`Using MANIFEST.in`." #: ../source/tutorials/packaging-projects.rst:393 msgid "" @@ -14047,10 +16955,15 @@ msgid "" "Files ` from the :doc:`setuptools docs " "`." msgstr "" +"A :term:`distribuição construída ` final terá os " +"arquivos Python nos pacotes descobertos ou listados Python. Se você deseja " +"controlar o que acontece aqui, como adicionar arquivos de dados, consulte :" +"doc:`Incluindo Arquivos de Dados ` da :doc:" +"`documentação do setuptools `." #: ../source/tutorials/packaging-projects.rst:402 msgid "Generating distribution archives" -msgstr "" +msgstr "Gerando arquivos de distribuição" #: ../source/tutorials/packaging-projects.rst:404 msgid "" @@ -14058,28 +16971,39 @@ msgid "" "Package>` for the package. These are archives that are uploaded to the " "Python Package Index and can be installed by :ref:`pip`." msgstr "" +"O próximo passo é gerar :term:`pacotes de distribuição ` para o pacote. Estes são arquivos que são enviados para o " +"Índice de Pacotes do Python e podem ser instalados pelo :ref:`pip`." #: ../source/tutorials/packaging-projects.rst:408 msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" msgstr "" +"Certifique-se de que você tenha a versão mais recente da :ref:`construção " +"` do PyPA instalada:" #: ../source/tutorials/packaging-projects.rst:422 msgid "" "If you have trouble installing these, see the :doc:`installing-packages` " "tutorial." msgstr "" +"Se você tiver problemas ao instalá-los, veja o tutorial :doc:`installing-" +"packages`." #: ../source/tutorials/packaging-projects.rst:425 msgid "" "Now run this command from the same directory where :file:`pyproject.toml` is " "located:" msgstr "" +"Agora, execute este comando a partir do mesmo diretório no qual :file:" +"`pyproject.toml` está localizado:" #: ../source/tutorials/packaging-projects.rst:439 msgid "" "This command should output a lot of text and once completed should generate " "two files in the :file:`dist` directory:" msgstr "" +"Este comando deve produzir muito texto e, uma vez concluído, deve gerar dois " +"arquivos no diretório :file:`dist`:" #: ../source/tutorials/packaging-projects.rst:449 msgid "" @@ -14091,14 +17015,23 @@ msgid "" "with. In this case, our example package is compatible with Python on any " "platform so only one built distribution is needed." msgstr "" +"O arquivo ``tar.gz`` é um :term:`arquivo fonte ` enquanto o " +"arquivo ``.whl`` é uma :term:`distribuição construída `. As versões :ref:`pip` mais recentes instalam preferencialmente " +"distribuições construídas, mas irão recorrer aos arquivos fonte se " +"necessário. Você deve sempre enviar um arquivo fonte e fornecer arquivos " +"construídos para as plataformas com as quais seu projeto é compatível. Neste " +"caso, nosso pacote de exemplo é compatível com Python em qualquer " +"plataforma, portanto, apenas uma distribuição construída é necessária." #: ../source/tutorials/packaging-projects.rst:458 msgid "Uploading the distribution archives" -msgstr "" +msgstr "Enviando os arquivos de distribuição" #: ../source/tutorials/packaging-projects.rst:460 msgid "Finally, it's time to upload your package to the Python Package Index!" msgstr "" +"Finalmente, é hora de enviar seu pacote para o Índice de Pacotes do Python!" #: ../source/tutorials/packaging-projects.rst:462 msgid "" @@ -14110,6 +17043,13 @@ msgid "" "You will also need to verify your email address before you're able to upload " "any packages. For more details, see :doc:`/guides/using-testpypi`." msgstr "" +"A primeira coisa que você precisa fazer é registrar uma conta no Test PyPI, " +"que é uma instância separada do índice do pacote destinada a teste e " +"experimentação. É ótimo para coisas como este tutorial, em que não queremos " +"necessariamente enviar para o índice real. Para registrar uma conta, vá em " +"https://test.pypi.org/account/register/ e conclua as etapas nessa página. " +"Você também precisará verificar seu endereço de e-mail antes de enviar " +"qualquer pacote. Para mais detalhes, veja :doc:`/guides/using-testpypi`." #: ../source/tutorials/packaging-projects.rst:470 msgid "" @@ -14118,17 +17058,25 @@ msgid "" "to \"Entire account\". **Don't close the page until you have copied and " "saved the token — you won't see that token again.**" msgstr "" +"Para enviar seu projeto com segurança, você precisará de um `token de API`_ " +"do PyPI. Crie um em https://test.pypi.org/manage/account/#api-tokens, " +"definindo o \"Escopo\" como \"Toda a conta\". **Não feche a página antes de " +"copiar e salvar o token -- você não verá o token novamente.**" #: ../source/tutorials/packaging-projects.rst:477 msgid "" "Now that you are registered, you can use :ref:`twine` to upload the " "distribution packages. You'll need to install Twine:" msgstr "" +"Agora que você está registrado, você pode usar: ref:`twine` para enviar os " +"pacotes de distribuição. Você precisará instalar o Twine:" #: ../source/tutorials/packaging-projects.rst:492 msgid "" "Once installed, run Twine to upload all of the archives under :file:`dist`:" msgstr "" +"Uma vez instalado, execute o Twine para enviar de todos os arquivos em :file:" +"`dist`:" #: ../source/tutorials/packaging-projects.rst:506 msgid "" @@ -14136,20 +17084,27 @@ msgid "" "``__token__``. For the password, use the token value, including the ``pypi-" "`` prefix." msgstr "" +"Você será solicitado a fornecer um nome de usuário e uma senha. Para o nome " +"de usuário, use ``__token__``. Para a senha, use o valor do token, incluindo " +"o prefixo ``pypi-``." #: ../source/tutorials/packaging-projects.rst:510 msgid "After the command completes, you should see output similar to this:" msgstr "" +"Depois que o comando for concluído, você deverá ver uma saída semelhante a " +"esta:" #: ../source/tutorials/packaging-projects.rst:523 msgid "" "Once uploaded your package should be viewable on TestPyPI, for example, " "https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" msgstr "" +"Depois de enviado, seu pacote pode ser visto no Test PyPI, por exemplo, em " +"https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" #: ../source/tutorials/packaging-projects.rst:528 msgid "Installing your newly uploaded package" -msgstr "" +msgstr "Instalando seu pacote recém-enviado" #: ../source/tutorials/packaging-projects.rst:530 msgid "" @@ -14157,16 +17112,20 @@ msgid "" "Create a :ref:`virtual environment ` and install your package from TestPyPI:" msgstr "" +"Você pode usar o :ref:`pip` para instalar seu pacote e verificar se ele " +"funciona. Crie um :ref:`ambiente virtual ` e instale seu pacote a partir do Test PyPI:" #: ../source/tutorials/packaging-projects.rst:546 msgid "Make sure to specify your username in the package name!" -msgstr "" +msgstr "Certifique-se de especificar seu nome de usuário no nome do pacote!" #: ../source/tutorials/packaging-projects.rst:548 msgid "" "pip should install the package from TestPyPI and the output should look " "something like this:" msgstr "" +"pip deve instalar o pacote de Test PyPI e a saída deve ser semelhante a esta:" #: ../source/tutorials/packaging-projects.rst:558 msgid "" @@ -14177,16 +17136,24 @@ msgid "" "package doesn't have any dependencies, it's a good practice to avoid " "installing dependencies when using TestPyPI." msgstr "" +"Este exemplo usa o sinalizador ``--index-url`` para especificar Test PyPI em " +"vez do PyPI real. Além disso, ele especifica ``--no-deps``. Como o Test PyPI " +"não tem os mesmos pacotes que o PyPI real, é possível que a tentativa de " +"instalação de dependências falhe ou instale algo inesperado. Embora nosso " +"pacote de exemplo não tenha nenhuma dependência, é uma boa prática evitar " +"instalar dependências ao usar o Test PyPI." #: ../source/tutorials/packaging-projects.rst:565 msgid "" "You can test that it was installed correctly by importing the package. Make " "sure you're still in your virtual environment, then run Python:" msgstr "" +"Você pode testar se ele foi instalado corretamente importando o pacote. " +"Certifique-se de que ainda está em seu ambiente virtual e execute o Python:" #: ../source/tutorials/packaging-projects.rst:580 msgid "and import the package:" -msgstr "" +msgstr "e importe o pacote:" #: ../source/tutorials/packaging-projects.rst:588 msgid "" @@ -14195,11 +17162,15 @@ msgid "" "` in :file:`setup.cfg` or :file:`setup.py` (in this " "case, ``example-pkg-YOUR-USERNAME-HERE``)." msgstr "" +"Note que o :term:`pacote de importação ` é " +"``example_package`` independente de qual ``name`` você deu ao seu :term:" +"`pacote de distribuição ` no :file:`setup.cfg` ou :" +"file:`setup.py` (neste caso, ``example-pkg-YOUR-USERNAME-HERE``)." #: ../source/tutorials/packaging-projects.rst:596 msgid "" "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" -msgstr "" +msgstr "**Parabéns, você empacotou e distribuiu um projeto Python!** ✨ 🍰 ✨" #: ../source/tutorials/packaging-projects.rst:599 msgid "" @@ -14208,6 +17179,10 @@ msgid "" "deletes packages and accounts. It is best to use TestPyPI for testing and " "experiments like this tutorial." msgstr "" +"Lembre-se de que este tutorial mostrou como enviar o seu pacote para Test " +"PyPI, que não é um armazenamento permanente. O sistema de teste " +"ocasionalmente exclui pacotes e contas. É melhor usar Test PyPI para testes " +"e experimentos como este tutorial." #: ../source/tutorials/packaging-projects.rst:604 msgid "" @@ -14215,12 +17190,17 @@ msgid "" "can do much the same as you did in this tutorial, but with these important " "differences:" msgstr "" +"Quando estiver pronto para carregar um pacote real para o Índice de Pacotes " +"do Python, você pode fazer quase o mesmo que fez neste tutorial, mas com " +"estas diferenças importantes:" #: ../source/tutorials/packaging-projects.rst:608 msgid "" "Choose a memorable and unique name for your package. You don't have to " "append your username as you did in the tutorial." msgstr "" +"Escolha um nome único e memorável para o seu pacote. Você não precisa " +"acrescentar seu nome de usuário como fez no tutorial." #: ../source/tutorials/packaging-projects.rst:610 msgid "" @@ -14228,6 +17208,9 @@ msgid "" "servers and the login details from the test server are not shared with the " "main server." msgstr "" +"Registre uma conta em https://pypi.org -- observe que esses são dois " +"servidores separados e os detalhes de login do servidor de teste não são " +"compartilhados com o servidor principal." #: ../source/tutorials/packaging-projects.rst:613 msgid "" @@ -14236,31 +17219,43 @@ msgid "" "you're uploading the package in production, you don't need to specify ``--" "repository``; the package will upload to https://pypi.org/ by default." msgstr "" +"Use ``twine upload dist/*`` para enviar seu pacote e insira suas credenciais " +"para a conta que você registrou no PyPI real. Agora que você está enviando o " +"pacote em produção, você não precisa especificar ``--repository``; o pacote " +"será enviado para https://pypi.org/ por padrão." #: ../source/tutorials/packaging-projects.rst:617 msgid "" "Install your package from the real PyPI using ``python3 -m pip install [your-" "package]``." msgstr "" +"Instale seu pacote a partir do PyPI real usando ``python3 -m pip install " +"[seu-pacote]``." #: ../source/tutorials/packaging-projects.rst:619 msgid "" "At this point if you want to read more on packaging Python libraries here " "are some things you can do:" msgstr "" +"Neste ponto, se você quiser ler mais sobre o empacotamento de bibliotecas " +"Python, aqui estão algumas coisas que você pode fazer:" #: ../source/tutorials/packaging-projects.rst:622 msgid "" "Read more about using :ref:`setuptools` to package libraries in :doc:`/" "guides/distributing-packages-using-setuptools`." msgstr "" +"Leia mais sobre como usar :ref:`setuptools` para empacotar bibliotecas em :" +"doc:`/guides/distributing-packages-using-setuptools`." #: ../source/tutorials/packaging-projects.rst:624 msgid "Read about :doc:`/guides/packaging-binary-extensions`." -msgstr "" +msgstr "Leia sobre :doc:`/guides/packaging-binary-extensions`." #: ../source/tutorials/packaging-projects.rst:625 msgid "" "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:" "`hatch`, and :ref:`poetry`." msgstr "" +"Considere alternativas ao :ref:`setuptools`, tal como :ref:`flit`, :ref:" +"`hatch` e :ref:`poetry`." From 6df211a6076b7655b5de2b3c1fde0a55b896ed87 Mon Sep 17 00:00:00 2001 From: Tymofii Lytvynenko Date: Tue, 23 Nov 2021 15:41:12 +0100 Subject: [PATCH 0193/1072] Translated using Weblate (Ukrainian) Currently translated at 20.7% (471 of 2271 strings) Co-authored-by: Tymofii Lytvynenko Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/uk/ Translation: pypa/packaging.python.org --- locales/uk/LC_MESSAGES/messages.po | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/locales/uk/LC_MESSAGES/messages.po b/locales/uk/LC_MESSAGES/messages.po index 5f9e45967..352d4f221 100644 --- a/locales/uk/LC_MESSAGES/messages.po +++ b/locales/uk/LC_MESSAGES/messages.po @@ -11,8 +11,8 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-09-05 14:34+0000\n" -"Last-Translator: Sviatoslav Sydorenko \n" +"PO-Revision-Date: 2021-11-07 16:11+0000\n" +"Last-Translator: Tymofii Lytvynenko \n" "Language-Team: Ukrainian \n" "Language: uk\n" @@ -21,7 +21,7 @@ msgstr "" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && n" "%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n" -"X-Generator: Weblate 4.8.1-dev\n" +"X-Generator: Weblate 4.9-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -58,7 +58,7 @@ msgid "" "`pull requests`__. If you're planning to write or edit the guide, please " "read the :ref:`style guide `." msgstr "" -"Переважна більшість роботи над |PyPUG| відбувається у `репозиторії проекту " +"Переважна більшість роботи над |PyPUG| відбувається у `репозиторії проєкту " "на GitHub `__. Аби розпочати, ознайомтеся з " "переліком `відкритих іш'ю `__ та `пул реквестів `" "__. Якщо ви збираєтеся написати статтю чи відредагувати це керівництво, будь " @@ -83,8 +83,8 @@ msgid "" "purposes. When proposing new additions to the project please pick the " "appropriate documentation type." msgstr "" -"Цей проект містить чотири ясно виражені типи документації із чіткими " -"призначеннями. Пропонуючи нові доповнення до проекту, будь ласка, оберіть " +"Цей проєкт містить чотири ясно виражені типи документації із чіткими " +"призначеннями. Пропонуючи нові доповнення до проєкту, будь ласка, оберіть " "відповідний вид документації." #: ../source/contribute.rst:38 ../source/tutorials/index.rst:2 @@ -181,7 +181,7 @@ msgid "" "the `Hitchhiker's Guide to Python installation instructions`_ to install " "Python 3.6 on your operating system." msgstr "" -"Python 3.6. Наші скрипти збирання спроектовані, щоб працювати лише із Python " +"Python 3.6. Наші скрипти збирання спроєктовані, щоб працювати лише із Python " "3.6. Скористайтеся `керівництвом автостопера по інструкціях встановлення " "Python `_, аби " "встановити Python 3.6 у вашій операційній системі." @@ -257,7 +257,7 @@ msgid "" "package, publish, and install Python projects using current tools." msgstr "" "|PyPUG| має на меті бути авторитетним ресурсом щодо того як пакувати, " -"публікувати та встановлювати проекти на Python, використовуючи сучасні " +"публікувати та встановлювати проєкти на Python, використовуючи сучасні " "засоби." #: ../source/contribute.rst:133 @@ -671,7 +671,7 @@ msgid "" msgstr "" "``install_requires`` — ключове слово у :ref:`setuptools`-файлі :file:`setup." "py`, яке слід використовувати для зазначення того, що проєкт потребує " -"**мінімально**, аби запускатися коректно. Коли проект інстальовано за " +"**мінімально**, аби запускатися коректно. Коли проєкт інстальовано за " "допомогою :ref:`pip`, це специфікація, яка використовується для встановлення " "його залежностей." From 85f4d277663884e856b077bd36db5097a1d9a958 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Tue, 23 Nov 2021 15:41:14 +0100 Subject: [PATCH 0194/1072] Translated using Weblate (Portuguese (Brazil)) Currently translated at 21.2% (483 of 2271 strings) Co-authored-by: Sviatoslav Sydorenko Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/pt_BR/ Translation: pypa/packaging.python.org --- locales/pt_BR/LC_MESSAGES/messages.po | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/locales/pt_BR/LC_MESSAGES/messages.po b/locales/pt_BR/LC_MESSAGES/messages.po index e4e6fe91c..41240274d 100644 --- a/locales/pt_BR/LC_MESSAGES/messages.po +++ b/locales/pt_BR/LC_MESSAGES/messages.po @@ -2840,7 +2840,7 @@ msgstr "" "quais versões do Python um projeto suporta, essas informações são usadas " "apenas para pesquisar e navegar por projetos no PyPI, não para instalar " "projetos. Para realmente restringir em quais versões do Python um projeto " -"pode ser instalado, use o argumento :ref:`python_requires `." +"pode ser instalado, use o argumento :ref:`python_requires`." #: ../source/guides/distributing-packages-using-setuptools.rst:327 msgid "keywords" From c4fc51693d44e3daf344aee03f3e63d6e94eca3d Mon Sep 17 00:00:00 2001 From: Rafael Fontenelle Date: Thu, 25 Nov 2021 01:21:26 +0100 Subject: [PATCH 0195/1072] Translated using Weblate (Portuguese (Brazil)) Currently translated at 89.7% (2038 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 87.0% (1976 of 2271 strings) Co-authored-by: Rafael Fontenelle Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/pt_BR/ Translation: pypa/packaging.python.org --- locales/pt_BR/LC_MESSAGES/messages.po | 665 ++++++++++++++++++++++---- 1 file changed, 559 insertions(+), 106 deletions(-) diff --git a/locales/pt_BR/LC_MESSAGES/messages.po b/locales/pt_BR/LC_MESSAGES/messages.po index 41240274d..1d357d33e 100644 --- a/locales/pt_BR/LC_MESSAGES/messages.po +++ b/locales/pt_BR/LC_MESSAGES/messages.po @@ -8,7 +8,7 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-11-14 08:57+0000\n" +"PO-Revision-Date: 2021-11-25 00:21+0000\n" "Last-Translator: Rafael Fontenelle \n" "Language-Team: Portuguese (Brazil) \n" @@ -17,7 +17,7 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=n > 1;\n" -"X-Generator: Weblate 4.9.1-dev\n" +"X-Generator: Weblate 4.10-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -390,7 +390,7 @@ msgstr "Certo: Para instalá-lo, execute…" #: ../source/contribute.rst:198 msgid "**State assumptions**" -msgstr "**Assuma pressupostos**" +msgstr "**Presuma**" #: ../source/contribute.rst:195 msgid "" @@ -1061,7 +1061,7 @@ msgid "" "python.org/2/library/sysconfig.html#installation-paths>`_, therefore making " "it easier to convert to other formats." msgstr "" -": term: `Wheel` é internamente organizado pelo `tipo de caminho sysconfig " +":term: `Wheel` é internamente organizado pelo `tipo de caminho sysconfig " "`_, " "portanto tornando mais fácil converter para outros formatos." @@ -2654,7 +2654,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:176 msgid "Start & end with an ASCII letter or digit." -msgstr "Comecar e terminar com uma letra ou dígito ASCII." +msgstr "Começar e terminar com uma letra ou dígito ASCII." #: ../source/guides/distributing-packages-using-setuptools.rst:178 msgid "" @@ -6706,9 +6706,9 @@ msgid "" "**distributions** in this document to avoid ambiguity). For example, if you " "have the following package structure:" msgstr "" -"Os pacotes de espaçode nomes permitem que você divida os subpacotes e " -"módulos dentro de um único :term:`pacote ` em vários :" -"term:`pacotes de distribuição ` (referidos como " +"Os pacotes de espaço de nomes permitem que você divida os subpacotes e " +"módulos dentro de um único :term:`pacote ` em vários " +":term:`pacotes de distribuição ` (referidos como " "**distribuições** em este documento para evitar ambiguidade). Por exemplo, " "se você tiver a seguinte estrutura de pacote:" @@ -6796,9 +6796,9 @@ msgid "" "compatible with the other methods. It's inadvisable to use different methods " "in different distributions that provide packages to the same namespace." msgstr "" -"Embora os pacotes de espaço de nomes nativos e pacotes de espaçode nomes no " -"estilo pkgutil sejam amplamente compatíveis, os pacotes de espaçode nomes no " -"estilo pkg_resources não são compatíveis com os outros métodos. Não é " +"Embora os pacotes de espaço de nomes nativos e pacotes de espaço de nomes no " +"estilo pkgutil sejam amplamente compatíveis, os pacotes de espaço de nomes " +"no estilo pkg_resources não são compatíveis com os outros métodos. Não é " "aconselhável usar métodos diferentes em distribuições diferentes que " "fornecem pacotes para o mesmo espaço de nomes." @@ -7136,7 +7136,7 @@ msgstr "Fazendo checkout do projeto e construindo as distribuições" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 msgid "Then, add the following under the ``build-n-publish`` section:" -msgstr "Então, adiccione o seguinte sob a seção ``build-n-publish``:" +msgstr "Então, adicione o seguinte sob a seção ``build-n-publish``:" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 msgid "" @@ -8950,7 +8950,7 @@ msgstr "" #: ../source/key_projects.rst:35 msgid "build" -msgstr "build" +msgstr "construir" #: ../source/key_projects.rst:37 msgid "" @@ -10180,7 +10180,7 @@ msgstr "" #: ../source/news.rst:27 msgid "Added a MANIFEST.in guide page. (:pr:`609`)" -msgstr "Adiciondo uma página de guia sobre MANIFEST.in. (:pr:`609`)" +msgstr "Adicionada uma página de guia sobre MANIFEST.in. (:pr:`609`)" #: ../source/news.rst:30 msgid "April 2019" @@ -10639,8 +10639,8 @@ msgid "" "Updated this guide's ``readme`` with instructions on how to build the guide " "locally. (:pr:`356`)" msgstr "" -"Atualizado o ``readme`` deste guia com instruções sobre como contruir o guia " -"localmente. (:pr:`356`)" +"Atualizado o ``readme`` deste guia com instruções sobre como construir o " +"guia localmente. (:pr:`356`)" #: ../source/news.rst:182 msgid "" @@ -11595,7 +11595,8 @@ msgid "" "filesystems, not just Python or Python packages." msgstr "" "Essas técnicas são principalmente Python agnósticas, porque empacotam " -"sistemas de arquivos de SO inteiros, não apenas Python ou pacotes Python." +"sistemas de arquivos inteiros de sistemas operacionais, não apenas Python ou " +"pacotes Python." #: ../source/overview.rst:344 msgid "" @@ -11758,8 +11759,8 @@ msgid "" "In most deployment pipelines, the OS package manager is just one piece of " "the puzzle." msgstr "" -"Na maioria das pipelines de implantação, o gerenciador de pacotes do SO é " -"apenas uma peça do quebra-cabeça." +"Na maioria das pipelines de implantação, o gerenciador de pacotes do sistema " +"operacional é apenas uma peça do quebra-cabeça." #: ../source/overview.rst:417 msgid "" @@ -11943,7 +11944,7 @@ msgstr "A instalação do wheel consiste, em teoria, em duas fases:" #: ../source/specifications/binary-distribution-format.rst:59 msgid "Unpack." -msgstr "Despempacotar." +msgstr "Desempacotar." #: ../source/specifications/binary-distribution-format.rst:61 msgid "Parse ``distribution-1.0.dist-info/WHEEL``." @@ -12364,7 +12365,6 @@ msgstr "" "maior do que a versão que ele suporta." #: ../source/specifications/binary-distribution-format.rst:224 -#, fuzzy msgid "" "Wheel, being an installation format that is intended to work across multiple " "versions of Python, does not generally include .pyc files." @@ -12383,27 +12383,36 @@ msgid "" "layout offers a superset of the functionality provided by the existing " "wininst and egg binary formats." msgstr "" +"Esta versão da especificação do wheel é baseada nos esquemas de instalação " +"do distutils e não define como instalar arquivos em outros locais. O layout " +"oferece um superconjunto da funcionalidade fornecida pelos formatos binários " +"wininst e egg existentes." #: ../source/specifications/binary-distribution-format.rst:235 #: ../source/specifications/recording-installed-packages.rst:35 msgid "The .dist-info directory" -msgstr "" +msgstr "O diretório .dist-info" #: ../source/specifications/binary-distribution-format.rst:237 msgid "" "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and " "RECORD." msgstr "" +"Os diretórios .dist-info de wheels incluem no mínimo METADATA, WHEEL e " +"RECORD." #: ../source/specifications/binary-distribution-format.rst:239 msgid "" "METADATA is the package metadata, the same format as PKG-INFO as found at " "the root of sdists." msgstr "" +"METADATA são os metadados do pacote, o mesmo formato do PKG-INFO encontrado " +"na raiz dos sdists." #: ../source/specifications/binary-distribution-format.rst:241 msgid "WHEEL is the wheel metadata specific to a build of the package." msgstr "" +"WHEEL são os metadados de wheel específicos para uma construção do pacote." #: ../source/specifications/binary-distribution-format.rst:242 msgid "" @@ -12413,21 +12422,31 @@ msgid "" "better; specifically, md5 and sha1 are not permitted, as signed wheel files " "rely on the strong hashes in RECORD to validate the integrity of the archive." msgstr "" +"RECORD é uma lista de (quase) todos os arquivos no wheel seus hashes " +"seguros. Ao contrário da PEP 376, nenhum arquivo, exceto RECORD, pode conter " +"um hash de si mesmo, deve incluir seu hash. O algoritmo hash deve ser sha256 " +"ou melhor; especificamente, md5 e sha1 não são permitidos, pois os arquivos " +"wheel assinados contam com hashes fortes em RECORD para validar a " +"integridade do arquivo." #: ../source/specifications/binary-distribution-format.rst:248 msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." -msgstr "" +msgstr "INSTALLER e REQUESTED da PEP 376 não são incluídos no arquivo." #: ../source/specifications/binary-distribution-format.rst:249 msgid "" "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." msgstr "" +"RECORD.jws é usado para assinaturas digitais. Não é mencionado no RECORD." #: ../source/specifications/binary-distribution-format.rst:251 msgid "" "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME " "signatures to secure their wheel files. It is not mentioned in RECORD." msgstr "" +"RECORD.p7s é permitido como cortesia para qualquer pessoa que prefira usar " +"assinaturas S/MIME para proteger seus arquivos wheels. Não é mencionado no " +"RECORD." #: ../source/specifications/binary-distribution-format.rst:254 msgid "" @@ -12436,10 +12455,14 @@ msgid "" "fail if any file in the archive is not both mentioned and correctly hashed " "in RECORD." msgstr "" +"Durante a extração, os instaladores de wheels verificam todos os hashes em " +"RECORD em relação ao conteúdo do arquivo. Além de RECORD e suas assinaturas, " +"a instalação falhará se qualquer arquivo no arquivo não for mencionado e com " +"hash correto em RECORD." #: ../source/specifications/binary-distribution-format.rst:261 msgid "The .data directory" -msgstr "" +msgstr "O diretório .data" #: ../source/specifications/binary-distribution-format.rst:263 msgid "" @@ -12447,6 +12470,9 @@ msgid "" "data directory, named as the .dist-info directory but with the .data/ " "extension::" msgstr "" +"Qualquer arquivo que não é normalmente instalado dentro de site-packages vai " +"para o diretório .data, nomeado como o diretório .dist-info, mas com a " +"extensão .data/::" #: ../source/specifications/binary-distribution-format.rst:271 msgid "" @@ -12454,10 +12480,13 @@ msgid "" "documentation and so forth from the distribution. During installation the " "contents of these subdirectories are moved onto their destination paths." msgstr "" +"O diretório .data contém subdiretórios com os scripts, cabeçalhos, " +"documentação e assim por diante da distribuição. Durante a instalação, o " +"conteúdo desses subdiretórios é movido para seus caminhos de destino." #: ../source/specifications/binary-distribution-format.rst:277 msgid "Signed wheel files" -msgstr "" +msgstr "Arquivos wheels assinados" #: ../source/specifications/binary-distribution-format.rst:279 msgid "" @@ -12468,6 +12497,13 @@ msgid "" "possible entries are hashed, including any generated files such as .pyc " "files, but not RECORD which cannot contain its own hash. For example::" msgstr "" +"Os arquivos wheels incluem um RECORD estendido que permite assinaturas " +"digitais. O RECORD da PEP 376 foi alterado para incluir um hash seguro " +"``digestname=urlsafe_b64encode_nopad(digest)`` (codificação base64 de " +"urlsafe sem caracteres ao final =) como a segunda coluna em vez de um " +"md5sum. Todas as entradas possíveis são hash, incluindo quaisquer arquivos " +"gerados, como arquivos .pyc, mas não RECORD, que não pode conter seu próprio " +"hash. Por exemplo::" #: ../source/specifications/binary-distribution-format.rst:290 msgid "" @@ -12476,6 +12512,10 @@ msgid "" "file in the archive must have a correct hash in RECORD or the installation " "will fail." msgstr "" +"O(s) arquivo(s) de assinatura RECORD.jws e RECORD.p7s não são mencionados em " +"RECORD, pois eles só podem ser adicionados após RECORD ser gerado. Todos os " +"outros arquivos no arquivo devem ter um hash correto em RECORD ou a " +"instalação falhará." #: ../source/specifications/binary-distribution-format.rst:295 msgid "" @@ -12484,16 +12524,22 @@ msgid "" "RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD " "as the signature's JSON payload::" msgstr "" +"Se assinaturas da web JSON forem usadas, uma ou mais assinaturas JSON Web " +"Signature JSON Serialization (JWS-JS) serão armazenadas em um arquivo " +"RECORD.jws adjacente a RECORD. JWS é usado para assinar RECORD incluindo o " +"hash SHA-256 de RECORD como a carga JSON da assinatura::" #: ../source/specifications/binary-distribution-format.rst:302 msgid "(The hash value is the same format used in RECORD.)" -msgstr "" +msgstr "(O valor hash é o mesmo formato usado em RECORD.)" #: ../source/specifications/binary-distribution-format.rst:304 msgid "" "If RECORD.p7s is used, it must contain a detached S/MIME format signature of " "RECORD." msgstr "" +"Se RECORD.p7s for usado, ele deve conter uma assinatura de formato S/MIME " +"separada de RECORD." #: ../source/specifications/binary-distribution-format.rst:307 msgid "" @@ -12502,31 +12548,37 @@ msgid "" "installer checks file hashes against RECORD, a separate signature checker " "only needs to establish that RECORD matches the signature." msgstr "" +"Um instalador de wheel não precisa entender as assinaturas digitais, mas " +"DEVE verificar os hashes em RECORD em relação ao conteúdo do arquivo " +"extraído. Quando o instalador verifica os hashes do arquivo em relação ao " +"RECORD, um verificador de assinatura separado só precisa estabelecer se " +"RECORD corresponde à assinatura." #: ../source/specifications/binary-distribution-format.rst:312 msgid "See" -msgstr "" +msgstr "Veja" #: ../source/specifications/binary-distribution-format.rst:314 msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" -msgstr "" +msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" #: ../source/specifications/binary-distribution-format.rst:315 msgid "" "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" msgstr "" +"http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" #: ../source/specifications/binary-distribution-format.rst:316 msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" -msgstr "" +msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" #: ../source/specifications/binary-distribution-format.rst:317 msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" -msgstr "" +msgstr "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" #: ../source/specifications/binary-distribution-format.rst:321 msgid "Comparison to .egg" -msgstr "" +msgstr "Comparação com .egg" #: ../source/specifications/binary-distribution-format.rst:323 msgid "" @@ -12536,12 +12588,19 @@ msgid "" "versions of Python so you don't always have to wait for the packager to " "catch up." msgstr "" +"Wheel é um formato de instalação; ovo é importável. Os arquivos wheel não " +"precisam incluir .pyc e estão menos vinculados a uma versão ou implementação " +"específica do Python. O Wheel pode instalar pacotes (puro Python) " +"construídos com versões anteriores do Python, portanto, você nem sempre " +"precisa esperar que o empacotador os atualize." #: ../source/specifications/binary-distribution-format.rst:328 msgid "" "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible " "with the new world of Python packaging and the new concepts it brings." msgstr "" +"O Wheel usa diretórios .dist-info; egg usa .egg-info. Wheel é compatível com " +"o novo mundo da empacotamento de Python e os novos conceitos que ele traz." #: ../source/specifications/binary-distribution-format.rst:331 msgid "" @@ -12551,6 +12610,11 @@ msgid "" "architectures. Historically the ABI has been specific to a CPython release, " "wheel is ready for the stable ABI." msgstr "" +"O Wheel tem uma convenção de nomenclatura de arquivo mais rica para o mundo " +"de múltiplas implementações de hoje. Um único arquivo de wheel pode indicar " +"sua compatibilidade com várias versões e implementações de linguagem Python, " +"ABIs e arquiteturas de sistema. Historicamente, a ABI tem sido específica " +"para uma versão do CPython, o wheel estando pronto para a ABI estável." #: ../source/specifications/binary-distribution-format.rst:337 msgid "" @@ -12558,6 +12622,9 @@ msgid "" "generates egg-info, and then converts it to a .whl. It is also possible to " "convert existing eggs and bdist_wininst distributions." msgstr "" +"O wheel não causa perdas. A implementação do primeiro wheel, bdist_wheel, " +"sempre gera egg-info e, então, as converte em .whl. Também é possível " +"converter eggs existentes e distribuições de bdist_wininst." #: ../source/specifications/binary-distribution-format.rst:341 msgid "" @@ -12565,18 +12632,21 @@ msgid "" "specification and the implementation that packaged it. Hopefully the next " "migration can simply be to Wheel 2.0." msgstr "" +"Wheel é versionado. Cada arquivo wheel contém a versão da especificação " +"wheel e a implementação que a empacotou. Esperançosamente, a próxima " +"migração pode ser simplesmente para Wheel 2.0." #: ../source/specifications/binary-distribution-format.rst:344 msgid "Wheel is a reference to the other Python." -msgstr "" +msgstr "Wheel é uma referência a outro Python." #: ../source/specifications/binary-distribution-format.rst:348 msgid "FAQ" -msgstr "" +msgstr "FAQ" #: ../source/specifications/binary-distribution-format.rst:352 msgid "Wheel defines a .data directory. Should I put all my data there?" -msgstr "" +msgstr "Wheel define um diretório .data. Devo colocar todos os meus dados lá?" #: ../source/specifications/binary-distribution-format.rst:354 msgid "" @@ -12587,10 +12657,16 @@ msgid "" "though *those* files will usually not be distributed in *wheel's* ``.data`` " "directory." msgstr "" +"Esta especificação não tem uma opinião sobre como você deve organizar seu " +"código. O diretório .data é apenas um lugar para quaisquer arquivos que não " +"são normalmente instalados dentro de ``site-packages`` ou no PYTHONPATH. Em " +"outras palavras, você pode continuar a usar ``pkgutil.get_data(pacote, " +"recurso)`` ainda que *esses* arquivos normalmente não sejam distribuídos no " +"diretório ``.data`` do *wheel*." #: ../source/specifications/binary-distribution-format.rst:363 msgid "Why does wheel include attached signatures?" -msgstr "" +msgstr "Por que o wheel inclui assinaturas anexadas?" #: ../source/specifications/binary-distribution-format.rst:365 msgid "" @@ -12600,10 +12676,15 @@ msgid "" "individual files can be verified without having to download the whole " "archive." msgstr "" +"Assinaturas anexadas são mais convenientes do que assinaturas separadas " +"porque elas viajam com o arquivo. Uma vez que apenas os arquivos individuais " +"são assinados, o arquivo pode ser recompactado sem invalidar a assinatura ou " +"os arquivos individuais podem ser verificados sem ter que baixar todo o " +"arquivo." #: ../source/specifications/binary-distribution-format.rst:373 msgid "Why does wheel allow JWS signatures?" -msgstr "" +msgstr "Por que wheel permite assinaturas JWS?" #: ../source/specifications/binary-distribution-format.rst:375 msgid "" @@ -12611,26 +12692,34 @@ msgid "" "implement, a feature that is also one of wheel's primary design goals. JWS " "yields a useful, concise pure-Python implementation." msgstr "" +"As especificações JOSE das quais o JWS faz parte foram projetadas para serem " +"fáceis de implementar, um recurso que também é um dos principais objetivos " +"do projeto da roda. O JWS produz uma implementação puro Python concisa e " +"útil." #: ../source/specifications/binary-distribution-format.rst:381 msgid "Why does wheel also allow S/MIME signatures?" -msgstr "" +msgstr "Por que wheel também permite assinaturas S/MIME?" #: ../source/specifications/binary-distribution-format.rst:383 msgid "" "S/MIME signatures are allowed for users who need or want to use existing " "public key infrastructure with wheel." msgstr "" +"Assinaturas S/MIME são permitidas para usuários que precisam ou querem usar " +"uma infraestrutura de chaves públicas existente com o wheel." #: ../source/specifications/binary-distribution-format.rst:386 msgid "" "Signed packages are only a basic building block in a secure package update " "system. Wheel only provides the building block." msgstr "" +"Pacotes assinados são apenas um bloco de construção básico em um sistema de " +"atualização segura de pacotes. Wheel só fornece o bloco de construção." #: ../source/specifications/binary-distribution-format.rst:391 msgid "What's the deal with \"purelib\" vs. \"platlib\"?" -msgstr "" +msgstr "Qual é a diferença entre \"purelib\" e \"platlib\"?" #: ../source/specifications/binary-distribution-format.rst:393 msgid "" @@ -12639,6 +12728,10 @@ msgid "" "packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent " "packages to '/usr/lib64/pythonX.Y/site-packages'." msgstr "" +"O Wheel preserva a distinção \"purelib\" vs. \"platlib\", que é " +"significativa em algumas plataformas. Por exemplo, o Fedora instala pacotes " +"puro Python em '/usr/lib/pythonX.Y/site-packages' e pacotes dependentes de " +"plataforma em '/usr/lib64/pythonX.Y/site-packages'." #: ../source/specifications/binary-distribution-format.rst:398 msgid "" @@ -12647,6 +12740,10 @@ msgid "" "true\" with those same files in the root, and it is legal to have files in " "both the \"purelib\" and \"platlib\" categories." msgstr "" +"Um wheel com \"Root-Is-Purelib: false\" com todos os seus arquivos em " +"``{nome}-{versão}.data/purelib`` é equivalente a um wheel com \"Root-Is-" +"Purelib: true\" com os mesmos arquivos na raiz, e é válido ter arquivos nas " +"categorias \"purelib\" e \"platlib\"." #: ../source/specifications/binary-distribution-format.rst:403 msgid "" @@ -12654,10 +12751,13 @@ msgid "" "depending on whether it is pure Python or not and those files should be at " "the root with the appropriate setting given for \"Root-is-purelib\"." msgstr "" +"Na prática, um wheel deve ter apenas um de \"purelib\" ou \"platlib\" " +"dependendo se é puro Python ou não e esses arquivos devem estar na raiz com " +"a configuração apropriada fornecida para \"Root-is-purelib\"." #: ../source/specifications/binary-distribution-format.rst:409 msgid "Is it possible to import Python code directly from a wheel file?" -msgstr "" +msgstr "É possível importar código Python diretamente de um arquivo wheel?" #: ../source/specifications/binary-distribution-format.rst:411 msgid "" @@ -12667,6 +12767,11 @@ msgid "" "``sys.path``. However, while this behaviour is a natural consequence of the " "format design, actually relying on it is generally discouraged." msgstr "" +"Tecnicamente, devido à combinação de suporte de instalação via extração " +"simples e usando um formato de arquivo compatível com ``zipimport``, um " +"subconjunto de arquivos wheel oferece suporte a ser colocado diretamente no " +"``sys.path``. No entanto, embora esse comportamento seja uma consequência " +"natural do design do formato, não é recomendável confiar nele." #: ../source/specifications/binary-distribution-format.rst:417 msgid "" @@ -12678,6 +12783,14 @@ msgid "" "purposes, or integrating fully with the standard build machinery for C " "extensions by publishing header files in the appropriate place)." msgstr "" +"Em primeiro lugar, o wheel *é* projetado principalmente como um formato de " +"distribuição, então pular a etapa de instalação também significa evitar " +"deliberadamente qualquer dependência de recursos que pressupõem a instalação " +"completa (como ser capaz de usar ferramentas padrão como ``pip`` e " +"``virtualenv`` para capturar e gerenciar dependências de uma forma que " +"possam ser devidamente rastreadas para fins de auditoria e atualização de " +"segurança, ou integração completa com o maquinário de construção padrão para " +"extensões C, publicando arquivos de cabeçalho no local apropriado)." #: ../source/specifications/binary-distribution-format.rst:426 msgid "" @@ -12696,6 +12809,22 @@ msgid "" "uses the abstract resource APIs internally, interfacing with external " "components may still require the availability of an actual on-disk file." msgstr "" +"Em segundo lugar, embora alguns softwares Python sejam escritos para " +"suportar a execução direta de um arquivo zip, ainda é comum que o código " +"seja escrito assumindo que foi totalmente instalado. Quando essa suposição é " +"quebrada ao tentar executar o software a partir de um arquivo zip, as falhas " +"podem frequentemente ser obscuras e difíceis de diagnosticar (especialmente " +"quando ocorrem em bibliotecas de terceiros). As duas fontes mais comuns de " +"problemas com isso são o fato de que a importação de extensões C de um " +"arquivo zip *não* ser suportada pelo CPython (uma vez que fazer isso não é " +"suportado diretamente pela máquina de carregamento dinâmico em qualquer " +"plataforma) e que quando executando a partir de um arquivo zip, o atributo " +"``__file__`` não se refere mais a um caminho de sistema de arquivos comum, " +"mas a um caminho de combinação que inclui tanto a localização do arquivo zip " +"no sistema de arquivos quanto o caminho relativo para o módulo dentro do " +"arquivo. Mesmo quando o software usa corretamente as APIs de recursos " +"abstratos internamente, a interface com componentes externos ainda pode " +"exigir a disponibilidade de um arquivo real no disco." #: ../source/specifications/binary-distribution-format.rst:443 msgid "" @@ -12705,42 +12834,52 @@ msgid "" "many projects will require a failure to be reproduced with a fully installed " "package before accepting it as a genuine bug." msgstr "" +"Como metaclasses, *monkeypatching* e importadores de metacaminho, se você " +"ainda não tem certeza de que precisa tirar proveito desse recurso, é quase " +"certo que não precisa dele. Se você decidir usá-lo de qualquer maneira, " +"esteja ciente de que muitos projetos exigirão que uma falha seja reproduzida " +"com um pacote totalmente instalado antes de aceitá-lo como um bug genuíno." #: ../source/specifications/binary-distribution-format.rst:450 msgid "Changes" -msgstr "" +msgstr "Alterações" #: ../source/specifications/binary-distribution-format.rst:452 msgid "Since :pep:`427`, this specification has changed as follows:" -msgstr "" +msgstr "Desde a :pep:`427`, esta especificação mudou da seguinte forma:" #: ../source/specifications/binary-distribution-format.rst:454 msgid "" "The rules on escaping in wheel filenames were revised, to bring them into " "line with what popular tools actually do (February 2021)." msgstr "" +"As regras sobre como escapar em nomes de arquivos wheel foram revisadas, " +"para alinhá-las com o que as ferramentas populares realmente fazem (" +"fevereiro de 2021)." #: ../source/specifications/binary-distribution-format.rst:461 msgid "" "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-" "February/124103.html)" msgstr "" +"Aceitação da PEP (https://mail.python.org/pipermail/python-dev/2013-February/" +"124103.html)" #: ../source/specifications/binary-distribution-format.rst:466 msgid "Appendix" -msgstr "" +msgstr "Apêndice" #: ../source/specifications/binary-distribution-format.rst:468 msgid "Example urlsafe-base64-nopad implementation::" -msgstr "" +msgstr "Exemplo de implementação de urlsafe-base64-nopad::" #: ../source/specifications/binary-distribution-format.rst:482 msgid "Copyright" -msgstr "" +msgstr "Diretos autorais" #: ../source/specifications/binary-distribution-format.rst:484 msgid "This document has been placed into the public domain." -msgstr "" +msgstr "Este documento foi colocado em domínio público." #: ../source/specifications/core-metadata.rst:5 msgid "Core metadata specifications" @@ -12991,10 +13130,13 @@ msgid "" "distribution which is not listed in the \"Operating System\" Trove " "classifiers. See \"Classifier\" below." msgstr "" +"Uma especificação da plataforma que descreve um sistema operacional " +"suportado pela distribuição que não está listado nos classificadores Trove " +"de \"Operating System\". Veja \"Classifier\" abaixo." #: ../source/specifications/core-metadata.rst:146 msgid "Supported-Platform (multiple use)" -msgstr "" +msgstr "Supported-Platform (vários usos)" #: ../source/specifications/core-metadata.rst:150 msgid "" @@ -13003,18 +13145,22 @@ msgid "" "binary distribution was compiled. The semantics of the Supported-Platform " "field are not specified in this PEP." msgstr "" +"As distribuições binárias contendo um arquivo PKG-INFO usarão o campo " +"Supported-Platform em seus metadados para especificar o sistema operacional " +"e a CPU para os quais a distribuição binária foi compilada. A semântica do " +"campo Supported-Platform não é especificada nesta PEP." #: ../source/specifications/core-metadata.rst:164 msgid "Summary" -msgstr "" +msgstr "Summary" #: ../source/specifications/core-metadata.rst:168 msgid "A one-line summary of what the distribution does." -msgstr "" +msgstr "Um resumo de uma linha do que a distribuição faz." #: ../source/specifications/core-metadata.rst:188 msgid "This field may be specified in the message body instead." -msgstr "" +msgstr "Este campo pode ser especificado no corpo da mensagem." #: ../source/specifications/core-metadata.rst:191 msgid "" @@ -13023,6 +13169,10 @@ msgid "" "size for this field, though people shouldn't include their instruction " "manual as the description." msgstr "" +"Uma descrição mais longa da distribuição que pode ter vários parágrafos. " +"Software que lida com metadados não deve presumir nenhum tamanho máximo para " +"este campo, embora as pessoas não devam incluir seu manual de instruções " +"como a descrição." #: ../source/specifications/core-metadata.rst:196 msgid "" @@ -13031,6 +13181,10 @@ msgid "" "optional; programs can also display the contents of the field as-is. This " "means that authors should be conservative in the markup they use." msgstr "" +"O conteúdo deste campo pode ser escrito usando a marcação reStructuredText " +"[1]_. Para programas que funcionam com metadados, o suporte à marcação é " +"opcional; os programas também podem exibir o conteúdo do campo como está. " +"Isso significa que os autores devem ser conservadores na marcação que usam." #: ../source/specifications/core-metadata.rst:202 msgid "" @@ -13039,6 +13193,11 @@ msgid "" "pipe (\"|\") char. As a result, the Description field is encoded into a " "folded field that can be interpreted by RFC822 parser [2]_." msgstr "" +"Para oferecer suporte a linhas vazias e linhas com indentação em relação ao " +"formato do RFC 822, qualquer caractere CRLF deve ser sufixado por 7 espaços " +"seguidos por um caractere de encadeamento ou pipe (\"|\"). Como resultado, o " +"campo Description é codificado em um campo dobrado que pode ser interpretado " +"pelo analisador RFC822 [2]_." #: ../source/specifications/core-metadata.rst:219 msgid "" @@ -13046,6 +13205,9 @@ msgid "" "and a pipe char have to be replaced by a single CRLF when the field is " "unfolded using a RFC822 reader." msgstr "" +"Esta codificação implica que quaisquer ocorrências de um CRLF seguido por 7 " +"espaços e um caractere pipe devem ser substituídos por um único CRLF quando " +"o campo é desdobrado usando um leitor de RFC822." #: ../source/specifications/core-metadata.rst:223 msgid "" @@ -13053,16 +13215,22 @@ msgid "" "message body (i.e., after a completely blank line following the headers, " "with no indentation or other special formatting necessary)." msgstr "" +"Alternativamente, a descrição da distribuição pode ser fornecida no corpo da " +"mensagem (ou seja, após uma linha completamente em branco após os " +"cabeçalhos, sem recuo ou outra formatação especial necessária)." #: ../source/specifications/core-metadata.rst:232 msgid "Description-Content-Type" -msgstr "" +msgstr "Description-Content-Type" #: ../source/specifications/core-metadata.rst:236 msgid "" "A string stating the markup syntax (if any) used in the distribution's " "description, so that tools can intelligently render the description." msgstr "" +"Uma string informando a sintaxe de marcação (se houver) usada na descrição " +"da distribuição, para que as ferramentas possam renderizar a descrição de " +"maneira inteligente." #: ../source/specifications/core-metadata.rst:239 msgid "" @@ -13080,6 +13248,20 @@ msgid "" "their description, opening up the possibility for PyPI and other tools to be " "able to render Markdown and other formats." msgstr "" +"Historicamente, o PyPI oferecia suporte a descrições em texto simples e `" +"reStructuredText (reST) `_, e poderia renderizar reST em HTML. No entanto, é " +"comum que os autores da distribuição escrevam a descrição em `Markdown " +"`_ (`RFC 7763 `_) visto que tantos sites de hospedagem de código " +"renderizam READMEs de Markdown, e os autores reutilizariam o arquivo para a " +"descrição. O PyPI não reconhecia o formato e, portanto, não conseguia " +"processar a descrição corretamente. Isso resultava em muitos pacotes no PyPI " +"com descrições mal renderizadas quando Markdown é deixado como texto " +"simples, ou pior, era tentado ser renderizado como reST. Este campo permite " +"que o autor da distribuição especifique o formato de sua descrição, abrindo " +"a possibilidade para PyPI e outras ferramentas serem capazes de renderizar " +"Markdown e outros formatos." #: ../source/specifications/core-metadata.rst:253 msgid "" @@ -13088,26 +13270,30 @@ msgid "" "html>`_). Briefly, this means that it has a ``type/subtype`` part and then " "it can optionally have a number of parameters:" msgstr "" +"O formato deste campo é o mesmo do cabeçalho ``Content-Type`` em HTTP (ou " +"seja: `RFC 1341 `_)" +". Resumidamente, isso significa que ele tem uma parte do ``tipo/subtipo`` e " +"então pode opcionalmente ter uma série de parâmetros:" #: ../source/specifications/core-metadata.rst:259 msgid "Format::" -msgstr "" +msgstr "Formato::" #: ../source/specifications/core-metadata.rst:263 msgid "The ``type/subtype`` part has only a few legal values:" -msgstr "" +msgstr "A parta ``tipo/subtipo`` tem apenas alguns poucos valores válidos:" #: ../source/specifications/core-metadata.rst:265 msgid "``text/plain``" -msgstr "" +msgstr "``text/plain``" #: ../source/specifications/core-metadata.rst:266 msgid "``text/x-rst``" -msgstr "" +msgstr "``text/x-rst``" #: ../source/specifications/core-metadata.rst:267 msgid "``text/markdown``" -msgstr "" +msgstr "``text/markdown``" #: ../source/specifications/core-metadata.rst:269 msgid "" @@ -13115,6 +13301,9 @@ msgid "" "the description. The only legal value is ``UTF-8``. If omitted, it is " "assumed to be ``UTF-8``." msgstr "" +"O parâmetro ``charset`` pode ser usado para especificar a codificação de " +"caracteres da descrição. O único valor válido é ``UTF-8``. Se omitido, é " +"considerado ``UTF-8``." #: ../source/specifications/core-metadata.rst:273 msgid "" @@ -13123,18 +13312,27 @@ msgid "" "allows specifying the variant of Markdown in use (defaults to ``GFM`` if not " "specified). Currently, two variants are recognized:" msgstr "" +"Outros parâmetros podem ser específicos para o subtipo escolhido. Por " +"exemplo, para o subtipo ``markdown``, existe um parâmetro opcional " +"``variant`` que permite especificar a variante do Markdown em uso (o padrão " +"é ``GFM`` se não for especificado). Atualmente, duas variantes são " +"reconhecidas:" #: ../source/specifications/core-metadata.rst:278 msgid "" "``GFM`` for `Github-flavored Markdown `_" msgstr "" +"``GFM`` para `Github-flavored Markdown `_" #: ../source/specifications/core-metadata.rst:280 msgid "" "``CommonMark`` for `CommonMark `_" msgstr "" +"``CommonMark`` para `CommonMark `_" #: ../source/specifications/core-metadata.rst:299 msgid "" @@ -13142,6 +13340,9 @@ msgid "" "attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to " "``text/plain`` if it is not valid rst." msgstr "" +"Se um ``Description-Content-Type`` não for especificado, as aplicações devem " +"tentar renderizá-lo como ``text/x-rst; charset=UTF-8`` e volta para ``text/" +"plain`` se não for válido primeiro." #: ../source/specifications/core-metadata.rst:303 msgid "" @@ -13149,6 +13350,9 @@ msgid "" "content type is ``text/plain`` (Although PyPI will probably reject anything " "with an unrecognized value)." msgstr "" +"Se um ``Description-Content-Type`` é um valor não reconhecido, então o tipo " +"de conteúdo presumido ser ``text/plain`` (embora PyPI provavelmente rejeite " +"qualquer coisa com um valor não reconhecido)." #: ../source/specifications/core-metadata.rst:307 msgid "" @@ -13156,6 +13360,9 @@ msgid "" "not specified or is set to an unrecognized value, then the assumed " "``variant`` is ``GFM``." msgstr "" +"Se o ``Description-Content-Type`` for ``text/markdown`` e ``variant`` não " +"for especificado ou estiver definido com um valor não reconhecido, então a " +"presume-se ``variant`` ser ``GFM`` ." #: ../source/specifications/core-metadata.rst:311 msgid "" @@ -13163,16 +13370,20 @@ msgid "" "``variant`` defaults to ``GFM`` and thus it is equivalent to the example " "before it." msgstr "" +"Portanto, para o último exemplo acima, o ``charset`` padrão é ``UTF-8`` e o " +"``variant`` padrão ``GFM`` e, portanto, é equivalente ao exemplo anterior." #: ../source/specifications/core-metadata.rst:320 msgid "Keywords" -msgstr "" +msgstr "Keywords" #: ../source/specifications/core-metadata.rst:324 msgid "" "A list of additional keywords, separated by commas, to be used to assist " "searching for the distribution in a larger catalog." msgstr "" +"Uma lista de palavras-chave adicionais, separadas por vírgulas, a serem " +"usadas para auxiliar na busca pela distribuição em um catálogo maior." #: ../source/specifications/core-metadata.rst:333 msgid "" @@ -13181,18 +13392,22 @@ msgid "" "very widely used for many years, so it was easier to update the " "specification to match the de facto standard." msgstr "" +"A especificação anteriormente mostrava palavras-chave separadas por espaços, " +"mas distutils e setuptools a implementaram com vírgulas. Essas ferramentas " +"foram amplamente utilizadas por muitos anos, então era mais fácil atualizar " +"a especificação para corresponder ao padrão de fato." #: ../source/specifications/core-metadata.rst:341 msgid "Home-page" -msgstr "" +msgstr "Home-page" #: ../source/specifications/core-metadata.rst:345 msgid "A string containing the URL for the distribution's home page." -msgstr "" +msgstr "Uma string contendo a URL para a página da distribuição." #: ../source/specifications/core-metadata.rst:353 msgid "Download-URL" -msgstr "" +msgstr "Download-URL" #: ../source/specifications/core-metadata.rst:357 msgid "" @@ -13200,26 +13415,33 @@ msgid "" "be downloaded. (This means that the URL can't be something like \".../" "BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" msgstr "" +"Uma string contendo a URL a partir da qual esta versão da distribuição pode " +"ser baixada. (Isso significa que a URL não pode ser algo como \"" +".../BeagleVote-latest.tgz\", mas deve ser \".../BeagleVote-0.45.tgz\".)" #: ../source/specifications/core-metadata.rst:366 msgid "Author" -msgstr "" +msgstr "Author" #: ../source/specifications/core-metadata.rst:370 msgid "" "A string containing the author's name at a minimum; additional contact " "information may be provided." msgstr "" +"Um string contendo o nome do autor, no mínimo; informações de contato " +"adicionais podem ser fornecidas." #: ../source/specifications/core-metadata.rst:383 msgid "Author-email" -msgstr "" +msgstr "Author-email" #: ../source/specifications/core-metadata.rst:387 msgid "" "A string containing the author's e-mail address. It can contain a name and " "e-mail address in the legal forms for a RFC-822 ``From:`` header." msgstr "" +"Uma string contendo o endereço de e-mail do autor. Ela pode conter um nome e " +"endereço de e-mail nas formas válidos para um cabeçalho ``From:`` do RFC-822." #: ../source/specifications/core-metadata.rst:395 #: ../source/specifications/core-metadata.rst:442 @@ -13227,6 +13449,8 @@ msgid "" "Per RFC-822, this field may contain multiple comma-separated e-mail " "addresses::" msgstr "" +"De acordo com RFC-822, este campo pode conter vários endereços de e-mail " +"separados por vírgula::" #: ../source/specifications/core-metadata.rst:405 msgid "Maintainer" @@ -13237,6 +13461,8 @@ msgid "" "A string containing the maintainer's name at a minimum; additional contact " "information may be provided." msgstr "" +"Uma string contendo o nome do mantenedor, no mínimo; informações de contato " +"adicionais podem ser fornecidas." #: ../source/specifications/core-metadata.rst:412 msgid "" @@ -13244,16 +13470,22 @@ msgid "" "by someone other than the original author: it should be omitted if it is " "identical to ``Author``." msgstr "" +"Observe que este campo deve ser usado quando um projeto está sendo mantido " +"por alguém que não seja o autor original: ele deve ser omitido se for " +"idêntico a ``Author``." #: ../source/specifications/core-metadata.rst:426 msgid "Maintainer-email" -msgstr "" +msgstr "Maintainer-email" #: ../source/specifications/core-metadata.rst:430 msgid "" "A string containing the maintainer's e-mail address. It can contain a name " "and e-mail address in the legal forms for a RFC-822 ``From:`` header." msgstr "" +"Uma string contendo o endereço de e-mail do mantenedor. Ela pode conter um " +"nome e endereço de e-mail nas formas válidas para um cabeçalho ``From:`` do " +"RFC-822." #: ../source/specifications/core-metadata.rst:434 msgid "" @@ -13261,10 +13493,13 @@ msgid "" "by someone other than the original author: it should be omitted if it is " "identical to ``Author-email``." msgstr "" +"Observe que este campo deve ser usado quando um projeto está sendo mantido " +"por alguém que não seja o autor original: ele deve ser omitido se for " +"idêntico a ``Author-email``." #: ../source/specifications/core-metadata.rst:452 msgid "License" -msgstr "" +msgstr "License" #: ../source/specifications/core-metadata.rst:456 msgid "" @@ -13275,10 +13510,15 @@ msgid "" "``Classifier`` field, or to indicate a variation or exception to such a " "license." msgstr "" +"Texto indicando a licença cobrindo a distribuição onde a licença não é uma " +"seleção dos classificadores Trove \"License\". Veja :ref:`\"Classifier \"" +"` abaixo. Este campo também pode ser usado para " +"especificar uma versão particular de uma licença que é nomeada através do " +"campo ``Classifier``, ou para indicar uma variação ou exceção a tal licença." #: ../source/specifications/core-metadata.rst:476 msgid "Classifier (multiple use)" -msgstr "" +msgstr "Classifier (vários usos)" #: ../source/specifications/core-metadata.rst:480 msgid "" @@ -13287,6 +13527,10 @@ msgid "" "Package Index publishes a dynamic list of `currently defined classifiers " "`__." msgstr "" +"Cada entrada é uma string que fornece um único valor de classificação para a " +"distribuição. Os classificadores são descritos na :pep:`301`, e o Python " +"Package Index publica uma lista dinâmica de `classificadores atualmente " +"definidos `__." #: ../source/specifications/core-metadata.rst:485 #: ../source/specifications/core-metadata.rst:574 @@ -13294,10 +13538,12 @@ msgstr "" #: ../source/specifications/core-metadata.rst:715 msgid "This field may be followed by an environment marker after a semicolon." msgstr "" +"Este campo pode ser seguido por um marcador de ambiente após um ponto e " +"vírgula." #: ../source/specifications/core-metadata.rst:496 msgid "Requires-Dist (multiple use)" -msgstr "" +msgstr "Requires-Dist (vários usos)" #: ../source/specifications/core-metadata.rst:499 #: ../source/specifications/core-metadata.rst:561 @@ -13307,56 +13553,74 @@ msgid "" "The field format specification was relaxed to accept the syntax used by " "popular publishing tools." msgstr "" +"A especificação do formato de campo foi relaxada para aceitar a sintaxe " +"usada por ferramentas de publicação populares." #: ../source/specifications/core-metadata.rst:503 msgid "" "Each entry contains a string naming some other distutils project required by " "this distribution." msgstr "" +"Cada entrada contém uma string nomeando algum outro projeto distutils " +"requerido por esta distribuição." #: ../source/specifications/core-metadata.rst:506 msgid "The format of a requirement string contains from one to four parts:" -msgstr "" +msgstr "O formato de uma string de requisito contém de uma a quatro partes:" #: ../source/specifications/core-metadata.rst:508 msgid "" "A project name, in the same format as the ``Name:`` field. The only " "mandatory part." msgstr "" +"Um nome de projeto, no mesmo formato do campo ``Name:``. A única parte " +"obrigatória." #: ../source/specifications/core-metadata.rst:510 msgid "" "A comma-separated list of 'extra' names. These are defined by the required " "project, referring to specific features which may need extra dependencies." msgstr "" +"Uma lista separada por vírgulas de nomes \"extras\". Estes são definidos " +"pelo projeto requerido, referindo-se a recursos específicos que podem " +"precisar de dependências extras." #: ../source/specifications/core-metadata.rst:513 msgid "" "A version specifier. Tools parsing the format should accept optional " "parentheses around this, but tools generating it should not use parentheses." msgstr "" +"Um especificador de versão. As ferramentas que analisam o formato devem " +"aceitar parênteses opcionais em torno disso, mas as ferramentas que o geram " +"não devem usar parênteses." #: ../source/specifications/core-metadata.rst:516 msgid "" "An environment marker after a semicolon. This means that the requirement is " "only needed in the specified conditions." msgstr "" +"Um marcador de ambiente após um ponto e vírgula. Isso significa que o " +"requisito só é necessário nas condições especificadas." #: ../source/specifications/core-metadata.rst:519 msgid "See :pep:`508` for full details of the allowed format." -msgstr "" +msgstr "Veja a :pep:`508` para detalhes completos do formato permitido." #: ../source/specifications/core-metadata.rst:521 msgid "" "The project names should correspond to names as found on the `Python Package " "Index`_." msgstr "" +"Os nomes dos projetos devem corresponder aos nomes encontrados no `Python " +"Package Index`_." #: ../source/specifications/core-metadata.rst:524 msgid "" "Version specifiers must follow the rules described in :doc:`version-" "specifiers`." msgstr "" +"Os especificadores de versão devem seguir as regras descritas em :doc" +":`version-specifiers`." #: ../source/specifications/core-metadata.rst:538 msgid "Requires-Python" @@ -13368,18 +13632,22 @@ msgid "" "guaranteed to be compatible with. Installation tools may look at this when " "picking which version of a project to install." msgstr "" +"Este campo especifica a(s) versão(ões) do Python com as quais a distribuição " +"tem garantia de compatibilidade. As ferramentas de instalação podem observar " +"isso ao escolher qual versão de um projeto instalar." #: ../source/specifications/core-metadata.rst:546 msgid "The value must be in the format specified in :doc:`version-specifiers`." msgstr "" +"O valor deve estar no formato especificado em :doc:`version-specifiers`." #: ../source/specifications/core-metadata.rst:548 msgid "This field cannot be followed by an environment marker." -msgstr "" +msgstr "Este campo não pode ser seguido por um marcador de ambiente." #: ../source/specifications/core-metadata.rst:558 msgid "Requires-External (multiple use)" -msgstr "" +msgstr "Requires-External (vários usos)" #: ../source/specifications/core-metadata.rst:565 msgid "" @@ -13388,12 +13656,18 @@ msgid "" "to downstream project maintainers, and has no semantics which are meaningful " "to the ``distutils`` distribution." msgstr "" +"Cada entrada contém uma string que descreve alguma dependência no sistema de " +"que a distribuição deve ser usada. Este campo tem como objetivo servir como " +"uma dica para os mantenedores do projeto downstream, e não tem semântica que " +"seja significativa para a distribuição ``distutils``." #: ../source/specifications/core-metadata.rst:570 msgid "" "The format of a requirement string is a name of an external dependency, " "optionally followed by a version declaration within parentheses." msgstr "" +"O formato de uma string de requisito é o nome de uma dependência externa, " +"opcionalmente seguido por uma declaração de versão entre parênteses." #: ../source/specifications/core-metadata.rst:576 msgid "" @@ -13402,28 +13676,35 @@ msgid "" "`440`: they should correspond to the version scheme used by the external " "dependency." msgstr "" +"Como eles se referem a lançamentos de software não-Python, os números de " +"versão para este campo **não** são obrigados a estar em conformidade com o " +"formato especificado na :pep:`440`: eles devem corresponder ao esquema de " +"versão usado pela dependência externa." #: ../source/specifications/core-metadata.rst:581 msgid "Notice that there is no particular rule on the strings to be used." msgstr "" +"Observe que não há uma regra específica sobre as strings a serem usadas." #: ../source/specifications/core-metadata.rst:593 msgid "Project-URL (multiple-use)" -msgstr "" +msgstr "Project-URL (vários usos)" #: ../source/specifications/core-metadata.rst:597 msgid "" "A string containing a browsable URL for the project and a label for it, " "separated by a comma." msgstr "" +"Uma string contendo uma URL navegável para o projeto e um rótulo para ele, " +"separados por uma vírgula." #: ../source/specifications/core-metadata.rst:604 msgid "The label is free text limited to 32 characters." -msgstr "" +msgstr "O rótulo é um texto livre limitado a 32 caracteres." #: ../source/specifications/core-metadata.rst:612 msgid "Provides-Extra (multiple use)" -msgstr "" +msgstr "Provides-Extra (vários usos)" #: ../source/specifications/core-metadata.rst:616 msgid "" @@ -13431,6 +13712,9 @@ msgid "" "identifier. May be used to make a dependency conditional on whether the " "optional feature has been requested." msgstr "" +"Uma string contendo o nome de um recurso opcional. Deve ser um identificador " +"Python válido. Pode ser usado para tornar uma dependência condicional ao " +"fato de o recurso opcional ter sido solicitado." #: ../source/specifications/core-metadata.rst:625 msgid "" @@ -13439,6 +13723,10 @@ msgid "" "comma (,). The requirements are evaluated for each requested feature and " "added to the set of requirements for the distribution." msgstr "" +"Uma segunda distribuição requer uma dependência opcional, colocando-a entre " +"colchetes, e pode solicitar vários recursos, separando-os com uma vírgula (,)" +". Os requisitos são avaliados para cada recurso solicitado e adicionados ao " +"conjunto de requisitos para a distribuição." #: ../source/specifications/core-metadata.rst:635 msgid "" @@ -13446,16 +13734,21 @@ msgid "" "that are needed for running automated tests and generating documentation, " "respectively." msgstr "" +"Dois nomes de recursos ``test`` e ``doc`` são reservados para marcar " +"dependências que são necessárias para executar testes automatizados e gerar " +"documentação, respectivamente." #: ../source/specifications/core-metadata.rst:639 msgid "" "It is legal to specify ``Provides-Extra:`` without referencing it in any " "``Requires-Dist:``." msgstr "" +"É válido especificar ``Provides-Extra:`` sem referenciá-lo em qualquer " +"``Requer-Dist:``." #: ../source/specifications/core-metadata.rst:644 msgid "Rarely Used Fields" -msgstr "" +msgstr "Campos raramente usados" #: ../source/specifications/core-metadata.rst:646 msgid "" @@ -13464,6 +13757,10 @@ msgid "" "it isn't at all clear how tools should interpret them in the context of an " "open index server such as `PyPI `__." msgstr "" +"Os campos nesta seção são raramente usados atualmente, já que seu design foi " +"inspirado por mecanismos comparáveis em sistemas de gerenciamento de pacotes " +"Linux, e não está claro como as ferramentas devem interpretá-los no contexto " +"de um servidor de indexação aberto, como `PyPI `__." #: ../source/specifications/core-metadata.rst:651 msgid "" @@ -13474,10 +13771,16 @@ msgid "" "used for their originally intended purpose in combination with a curated " "package repository." msgstr "" +"Como resultado, as ferramentas de instalação populares os ignoram " +"completamente, o que significa que há pouco incentivo para os editores de " +"pacotes configurá-los apropriadamente. No entanto, eles são retidos na " +"especificação de metadados, pois ainda são potencialmente úteis para fins " +"informativos e também podem ser usados para o propósito originalmente " +"pretendido em combinação com um repositório de pacotes com curadoria." #: ../source/specifications/core-metadata.rst:660 msgid "Provides-Dist (multiple use)" -msgstr "" +msgstr "Provides-Dist (vários usos)" #: ../source/specifications/core-metadata.rst:667 msgid "" @@ -13485,6 +13788,9 @@ msgid "" "within this distribution. This field *must* include the project identified " "in the ``Name`` field, followed by the version : Name (Version)." msgstr "" +"Cada entrada contém uma string nomeando um projeto Distutils que está " +"contido nesta distribuição. Este campo *deve* incluir o projeto identificado " +"no campo ``Name``, seguido da versão: Nome (Versão)." #: ../source/specifications/core-metadata.rst:672 msgid "" @@ -13494,6 +13800,12 @@ msgid "" "which is now available as a separate distribution. Installing such a source " "distribution satisfies requirements for both ``ZODB`` and ``transaction``." msgstr "" +"Uma distribuição pode fornecer nomes adicionais, por exemplo, para indicar " +"que vários projetos foram agrupados. Por exemplo, distribuições de código-" +"fonte do projeto ``ZODB`` historicamente incluíram o projeto ``transaction``" +", que agora está disponível como uma distribuição separada. Instalar tal " +"distribuição de código-fonte satisfaz os requisitos para ``ZODB`` e " +"``transaction``." #: ../source/specifications/core-metadata.rst:679 msgid "" @@ -13505,6 +13817,13 @@ msgid "" "bindings``, allowing other projects to depend only on having at most one of " "them installed." msgstr "" +"Uma distribuição também pode fornecer um nome de projeto \"virtual\", que " +"não corresponde a nenhum projeto distribuído separadamente: tal nome pode " +"ser usado para indicar uma capacidade abstrata que pode ser fornecida por um " +"de vários projetos. Por exemplo, vários projetos podem fornecer ligações " +"*(bindings)* de RDBMS para uso por um determinado ORM: cada projeto pode " +"declarar que fornece ``ORM-bindings``, permitindo que outros projetos " +"dependam apenas de ter no máximo um deles instalado." #: ../source/specifications/core-metadata.rst:687 msgid "" @@ -13512,10 +13831,13 @@ msgid "" "in :doc:`version-specifiers`. The distribution's version number will be " "implied if none is specified." msgstr "" +"Uma declaração de versão pode ser fornecida e deve seguir as regras " +"descritas em :doc:`version-specifiers`. O número da versão da distribuição " +"estará implícito se nenhum for especificado." #: ../source/specifications/core-metadata.rst:701 msgid "Obsoletes-Dist (multiple use)" -msgstr "" +msgstr "Obsoletes-Dist (vários usos)" #: ../source/specifications/core-metadata.rst:708 msgid "" @@ -13523,12 +13845,17 @@ msgid "" "which this distribution renders obsolete, meaning that the two projects " "should not be installed at the same time." msgstr "" +"Cada entrada contém uma string que descreve a distribuição de um projeto " +"distutils que esta distribuição torna obsoleta, o que significa que os dois " +"projetos não devem ser instalados ao mesmo tempo." #: ../source/specifications/core-metadata.rst:712 msgid "" "Version declarations can be supplied. Version numbers must be in the format " "specified in :doc:`version-specifiers`." msgstr "" +"Declarações de versão podem ser fornecidas. Os números de versão devem estar " +"no formato especificado em :doc:`version-specifiers`." #: ../source/specifications/core-metadata.rst:717 msgid "" @@ -13536,18 +13863,22 @@ msgid "" "g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install " "Torqued Python, the Gorgon distribution should be removed." msgstr "" +"O uso mais comum deste campo será no caso de alteração do nome de um " +"projeto, por exemplo, Gorgon 2.3 é incluído no Torqued Python 1.0. Quando " +"você instala o Torqued Python, a distribuição Gorgon deve ser removida." #: ../source/specifications/core-metadata.rst:730 msgid "reStructuredText markup: http://docutils.sourceforge.net/" -msgstr "" +msgstr "Marcação reStructuredText: http://docutils.sourceforge.net/" #: ../source/specifications/core-metadata.rst:735 msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" msgstr "" +"\"Long Header Fields\" do RFC 822: http://www.freesoft.org/CIE/RFC/822/7.htm" #: ../source/specifications/declaring-build-dependencies.rst:6 msgid "Declaring build system dependencies" -msgstr "" +msgstr "Declarando dependências do sistema de construção" #: ../source/specifications/declaring-build-dependencies.rst:8 msgid "" @@ -13556,10 +13887,14 @@ msgid "" "dependencies that must be installed in order to run the project's build " "system successfully." msgstr "" +"`pyproject.toml` é um formato de arquivo independente do sistema de " +"construção definido na :pep:`518` que os projetos podem fornecer para " +"declarar quaisquer dependências de nível Python que devem ser instaladas " +"para executar o sistema de construção do projeto com sucesso." #: ../source/specifications/declaring-project-metadata.rst:5 msgid "Declaring project metadata" -msgstr "" +msgstr "Declarando os metadados do projeto" #: ../source/specifications/declaring-project-metadata.rst:7 msgid "" @@ -13568,6 +13903,10 @@ msgid "" "consume. It defines the following specification as the canonical source for " "the format used." msgstr "" +"A :pep:`621` especifica como escrever :ref:`metadados principais `de um projeto em um arquivo ``pyproject.toml`` para ferramentas " +"relacionadas ao empacotamento consumirem. Ele define a seguinte " +"especificação como a fonte canônica para o formato usado." #: ../source/specifications/declaring-project-metadata.rst:12 msgid "" @@ -13577,6 +13916,12 @@ msgid "" "(defined later in this specification) and represents metadata that a tool " "will later provide." msgstr "" +"Existem dois tipos de metadados: *estáticos* e *dinâmicos*. Metadados " +"estáticos são especificados diretamente no arquivo ``pyproject.toml`` e não " +"podem ser especificados ou alterados por uma ferramenta. Os metadados " +"dinâmicos são listados por meio do campo ``dynamic`` (definido " +"posteriormente nesta especificação) e representam os metadados que uma " +"ferramenta fornecerá posteriormente." #: ../source/specifications/declaring-project-metadata.rst:18 msgid "" @@ -13588,21 +13933,32 @@ msgid "" "`. The lack of a ``[project]`` table " "implicitly means the build back-end will dynamically provide all fields." msgstr "" +"Os campos definidos nesta especificação DEVEM estar em uma tabela chamada " +"``[project]`` no arquivo ``pyproject.toml``. Nenhuma ferramenta pode " +"adicionar campos a esta tabela que não sejam definidos por esta " +"especificação. Para ferramentas que desejam armazenar suas próprias " +"configurações em ``pyproject.toml``, eles podem usar a tabela ``[tool]`` " +"conforme definido na :ref:`especificação da declaração de dependências de " +"construção `. A falta de uma tabela " +"``[project]`` implicitamente significa que o baccend da construção fornecerá " +"dinamicamente todos os campos." #: ../source/specifications/declaring-project-metadata.rst:27 msgid "The only fields required to be statically defined are:" -msgstr "" +msgstr "Os únicos campos que precisam ser definidos estaticamente são:" #: ../source/specifications/declaring-project-metadata.rst:29 #: ../source/specifications/declaring-project-metadata.rst:41 msgid "``name``" -msgstr "" +msgstr "``name``" #: ../source/specifications/declaring-project-metadata.rst:31 msgid "" "The fields which are required but may be specified *either* statically or " "listed as dynamic are:" msgstr "" +"Os campos que são obrigatórios, mas podem ser especificados *ou* " +"estaticamente ou listados como dinâmicos são:" #: ../source/specifications/declaring-project-metadata.rst:34 #: ../source/specifications/declaring-project-metadata.rst:54 @@ -13614,65 +13970,75 @@ msgid "" "All other fields are considered optional and my be specified statically, " "listed as dynamic, or left unspecified." msgstr "" +"Todos os outros campos são considerados opcionais e podem ser especificados " +"estaticamente, listados como dinâmicos ou não especificados." #: ../source/specifications/declaring-project-metadata.rst:43 #: ../source/specifications/declaring-project-metadata.rst:56 #: ../source/specifications/declaring-project-metadata.rst:68 #: ../source/specifications/declaring-project-metadata.rst:117 msgid "TOML_ type: string" -msgstr "" +msgstr "Tipo TOML_: string" #: ../source/specifications/declaring-project-metadata.rst:44 msgid "" "Corresponding :ref:`core metadata ` field: :ref:`Name `" msgstr "" +"Campo correspondente dos :ref:`metadados principais `: :ref:`" +"Name `" #: ../source/specifications/declaring-project-metadata.rst:47 msgid "The name of the project." -msgstr "" +msgstr "O nome do projeto." #: ../source/specifications/declaring-project-metadata.rst:49 msgid "" "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it " "is read for internal consistency." msgstr "" +"As ferramentas DEVEM normalizar este nome, conforme especificado por " +":pep:`503`, assim que for lido para consistência interna." #: ../source/specifications/declaring-project-metadata.rst:57 msgid "" "Corresponding :ref:`core metadata ` field: :ref:`Version " "`" msgstr "" +"Campo correspondente dos :ref:`metadados principais `: :ref:`" +"Version `" #: ../source/specifications/declaring-project-metadata.rst:60 msgid "The version of the project as supported by :pep:`440`." -msgstr "" +msgstr "A versão do projeto conforme suportado pela :pep:`440`." #: ../source/specifications/declaring-project-metadata.rst:62 msgid "Users SHOULD prefer to specify already-normalized versions." -msgstr "" +msgstr "Os usuários DEVEM preferir especificar versões já normalizadas." #: ../source/specifications/declaring-project-metadata.rst:66 msgid "``description``" -msgstr "" +msgstr "``description``" #: ../source/specifications/declaring-project-metadata.rst:69 msgid "" "Corresponding :ref:`core metadata ` field: :ref:`Summary " "`" msgstr "" +"Campo correspondente dos :ref:`metadados principais `: :ref:`" +"Summary `" #: ../source/specifications/declaring-project-metadata.rst:72 msgid "The summary description of the project." -msgstr "" +msgstr "A descrição resumida do projeto." #: ../source/specifications/declaring-project-metadata.rst:76 msgid "``readme``" -msgstr "" +msgstr "``readme``" #: ../source/specifications/declaring-project-metadata.rst:78 msgid "TOML_ type: string or table" -msgstr "" +msgstr "Tipo TOML_: string ou tabela" #: ../source/specifications/declaring-project-metadata.rst:79 msgid "" @@ -13680,10 +14046,13 @@ msgid "" "` and :ref:`Description-Content-Type `" msgstr "" +"Campos correspondente dos :ref:`metadados principais `: :ref:`" +"Description ` e :ref:`Description-Content-Type " +"`" #: ../source/specifications/declaring-project-metadata.rst:83 msgid "The full description of the project (i.e. the README)." -msgstr "" +msgstr "A descrição completa do projeto (isto é, o README)." #: ../source/specifications/declaring-project-metadata.rst:85 msgid "" @@ -13698,6 +14067,17 @@ msgid "" "For all unrecognized suffixes when a content-type is not provided, tools " "MUST raise an error." msgstr "" +"O campo aceita uma string ou uma tabela. Se for uma string, então é um " +"caminho relativo ao ``pyproject.toml`` para um arquivo texto contendo a " +"descrição completa. As ferramentas DEVEM assumir que a codificação do " +"arquivo é UTF-8. Se o caminho do arquivo termina com um sufixo ``.md``, ou " +"sua versão em caixa alta, então as ferramentas DEVEM presumir que o tipo de " +"conteúdo é ``text/markdown``. Se o caminho do arquivo termina em ``.rst``, " +"então as ferramentas DEVEM presumir que o tipo de conteúdo é ``text/x-rst``. " +"Se uma ferramenta reconhece mais extensões do que esta PEP, elas podem " +"inferir o tipo de conteúdo para o usuário sem especificar este campo como " +"``dunamic``. Para todos os sufixos não reconhecidos quando um tipo de " +"conteúdo não é fornecido, as ferramentas DEVEM levantar um erro." #: ../source/specifications/declaring-project-metadata.rst:96 msgid "" @@ -13707,6 +14087,12 @@ msgid "" "is the full description. These keys are mutually-exclusive, thus tools MUST " "raise an error if the metadata specifies both keys." msgstr "" +"O campo ``readme`` também pode receber uma tabela. A chave ``file`` tem um " +"valor string que representa um caminho relativo a ``pyproject.toml`` para um " +"arquivo contendo a descrição completa. A chave ``text`` tem um valor de " +"string que é a descrição completa. Essas chaves são mutuamente exclusivas, " +"portanto, as ferramentas DEVEM levantar um erro se os metadados " +"especificarem ambas as chaves." #: ../source/specifications/declaring-project-metadata.rst:103 msgid "" @@ -13719,34 +14105,48 @@ msgid "" "content-type as supported by the :ref:`core metadata `. " "Otherwise tools MUST raise an error for unsupported content-types." msgstr "" +"Uma tabela especificada no campo ``readme`` também possui um campo ``content-" +"type`` que recebe uma string especificando o tipo de conteúdo da descrição " +"completa. Uma ferramenta DEVE levantar um erro se os metadados não " +"especificarem esse campo na tabela. Se os metadados não especificarem o " +"parâmetro ``charset``, será considerado UTF-8. As ferramentas PODEM oferecer " +"suporte a outras codificações, se assim o desejarem. As ferramentas PODEM " +"oferecer suporte a tipos de conteúdo alternativos que podem transformar em " +"um tipo de conteúdo conforme suportado pelos :ref:`metadados principais " +"`. Caso contrário, as ferramentas DEVEM levantar um erro para " +"tipos de conteúdo não suportados." #: ../source/specifications/declaring-project-metadata.rst:115 msgid "``requires-python``" -msgstr "" +msgstr "``requires-python``" #: ../source/specifications/declaring-project-metadata.rst:118 msgid "" "Corresponding :ref:`core metadata ` field: :ref:`Requires-" "Python `" msgstr "" +"Campo correspondente dos :ref:`metadados principais `: :ref" +":`Requires-Python `" #: ../source/specifications/declaring-project-metadata.rst:121 msgid "The Python version requirements of the project." -msgstr "" +msgstr "Os requisitos de versão do Python do projeto." #: ../source/specifications/declaring-project-metadata.rst:125 msgid "``license``" -msgstr "" +msgstr "``license``" #: ../source/specifications/declaring-project-metadata.rst:127 msgid "TOML_ type: table" -msgstr "" +msgstr "Tipo TOML_: tabela" #: ../source/specifications/declaring-project-metadata.rst:128 msgid "" "Corresponding :ref:`core metadata ` field: :ref:`License " "`" msgstr "" +"Campo correspondente dos :ref:`metadados principais `: :ref:`" +"License `" #: ../source/specifications/declaring-project-metadata.rst:131 msgid "" @@ -13757,14 +14157,21 @@ msgid "" "keys are mutually exclusive, so a tool MUST raise an error if the metadata " "specifies both keys." msgstr "" +"A tabela pode ter uma de duas chaves. A chave ``file`` tem um valor de " +"string que é um caminho de arquivo relativo a ``pyproject.toml`` para o " +"arquivo que contém a licença do projeto. As ferramentas DEVEM presumir que a " +"codificação do arquivo é UTF-8. A chave ``text`` tem um valor de string que " +"é a licença do projeto. Essas chaves são mutuamente exclusivas, portanto, " +"uma ferramenta DEVE levantar um erro se os metadados especificarem ambas as " +"chaves." #: ../source/specifications/declaring-project-metadata.rst:140 msgid "``authors``/``maintainers``" -msgstr "" +msgstr "``authors``/``maintainers``" #: ../source/specifications/declaring-project-metadata.rst:142 msgid "TOML_ type: Array of inline tables with string keys and values" -msgstr "" +msgstr "Tipo TOML_: Vetor de tabelas em linha com strings de chaves e valores" #: ../source/specifications/declaring-project-metadata.rst:143 msgid "" @@ -13773,6 +14180,10 @@ msgid "" "`Maintainer `, and :ref:`Maintainer-email `" msgstr "" +"Campos correspondentes dos :ref:`metadados principais `: " +":ref:`Author `, :ref:`Author-email `, :ref:`Maintainer ` e :ref" +":`Maintainer-email `" #: ../source/specifications/declaring-project-metadata.rst:149 msgid "" @@ -13780,12 +14191,17 @@ msgid "" "The exact meaning is open to interpretation — it may list the original or " "primary authors, current maintainers, or owners of the package." msgstr "" +"As pessoas ou organizações consideradas \"autoras\" do projeto. O " +"significado exato está aberto à interpretação -- pode listar os autores " +"originais ou primários, mantenedores atuais ou proprietários do pacote." #: ../source/specifications/declaring-project-metadata.rst:154 msgid "" "The \"maintainers\" field is similar to \"authors\" in that its exact " "meaning is open to interpretation." msgstr "" +"O campo \"maintainers\" é semelhante a \"authors\" no sentido de que seu " +"significado exato está aberto à interpretação." #: ../source/specifications/declaring-project-metadata.rst:157 msgid "" @@ -13795,17 +14211,27 @@ msgid "" "contain commas. The ``email`` value MUST be a valid email address. Both keys " "are optional." msgstr "" +"Estes campos aceitam um vetor de tabelas com 2 chaves: ``name`` e ``email``. " +"Ambos os valores devem ser strings. O valor ``name`` DEVE ser um nome de e-" +"mail válido (ou seja, o que quer que possa ser colocado como um nome, antes " +"de um e-mail, em `RFC 822`_) e não conter vírgulas. O valor ``email`` DEVE " +"ser um endereço de email válido. Ambas as chaves são opcionais." #: ../source/specifications/declaring-project-metadata.rst:163 msgid "" "Using the data to fill in :ref:`core metadata ` is as follows:" msgstr "" +"O uso dos dados para preencher :ref:`metadados principais ` " +"deve ser feito da seguinte forma:" #: ../source/specifications/declaring-project-metadata.rst:166 msgid "" "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." msgstr "" +"Se somente ``name`` for fornecido, o valor vai em :ref:`Author ` ou :ref:`Maintainer ` conforme " +"apropriado." #: ../source/specifications/declaring-project-metadata.rst:169 msgid "" @@ -13813,6 +14239,9 @@ msgid "" "metadata-author-email>` or :ref:`Maintainer-email ` as appropriate." msgstr "" +"Se somente ``email`` é fornecido, o valor vai em :ref:`Author-email ` ou :ref:`Maintainer-email ` conforme apropriado." #: ../source/specifications/declaring-project-metadata.rst:173 msgid "" @@ -13820,77 +14249,89 @@ msgid "" "email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." msgstr "" +"Se ``email`` e ``name`` são fornecidos, o valor vai em :ref:`Author-email " +"` ou :ref:`Maintainer-email ` conforme apropriado, com o formado ``{name} <{email}>``." #: ../source/specifications/declaring-project-metadata.rst:177 msgid "Multiple values should be separated by commas." -msgstr "" +msgstr "Vários valores devem ser separados por vírgulas." #: ../source/specifications/declaring-project-metadata.rst:181 msgid "``keywords``" -msgstr "" +msgstr "``keywords``" #: ../source/specifications/declaring-project-metadata.rst:183 #: ../source/specifications/declaring-project-metadata.rst:193 msgid "TOML_ type: array of strings" -msgstr "" +msgstr "Tipo TOML_: vetor de strings" #: ../source/specifications/declaring-project-metadata.rst:184 msgid "" "Corresponding :ref:`core metadata ` field: :ref:`Keywords " "`" msgstr "" +"Campo correspondente dos :ref:`metadados principais `: :ref:`" +"Keywords `" #: ../source/specifications/declaring-project-metadata.rst:187 msgid "The keywords for the project." -msgstr "" +msgstr "As palavras-chave do projeto." #: ../source/specifications/declaring-project-metadata.rst:191 msgid "``classifiers``" -msgstr "" +msgstr "``classifiers``" #: ../source/specifications/declaring-project-metadata.rst:194 msgid "" "Corresponding :ref:`core metadata ` field: :ref:`Classifier " "`" msgstr "" +"Campo correspondente dos :ref:`metadados principais `: :ref:`" +"Classifier `" #: ../source/specifications/declaring-project-metadata.rst:197 msgid "Trove classifiers which apply to the project." -msgstr "" +msgstr "Classificadores Trove que se aplicam ao projeto." #: ../source/specifications/declaring-project-metadata.rst:201 msgid "``urls``" -msgstr "" +msgstr "``urls``" #: ../source/specifications/declaring-project-metadata.rst:203 msgid "TOML_ type: table with keys and values of strings" -msgstr "" +msgstr "Tipo TOML_: tabela com chaves e valores de strings" #: ../source/specifications/declaring-project-metadata.rst:204 msgid "" "Corresponding :ref:`core metadata ` field: :ref:`Project-URL " "`" msgstr "" +"Campo correspondente dos :ref:`metadados principais `: :ref" +":`Project-URL `" #: ../source/specifications/declaring-project-metadata.rst:207 msgid "" "A table of URLs where the key is the URL label and the value is the URL " "itself." msgstr "" +"Uma tabela de URLs onde a chave é o rótulo da URL e o valor é a URL em si." #: ../source/specifications/declaring-project-metadata.rst:212 msgid "Entry points" -msgstr "" +msgstr "Pontos de entrada" #: ../source/specifications/declaring-project-metadata.rst:214 msgid "" "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and " "``[project.entry-points]``)" msgstr "" +"Tipo TOML_: tabela (``[project.scripts]``, ``[project.gui-scripts]`` e " +"``[project.entry-points]``)" #: ../source/specifications/declaring-project-metadata.rst:216 msgid ":ref:`Entry points specification `" -msgstr "" +msgstr ":ref:`Especificação de pontos de entrada `" #: ../source/specifications/declaring-project-metadata.rst:218 msgid "" @@ -13899,6 +14340,10 @@ msgid "" "specification `. The key of the table is the name of the entry " "point and the value is the object reference." msgstr "" +"Existem três tabelas relacionadas aos pontos de entrada. A tabela ``[project." +"scripts]`` corresponde ao grupo ``console_scripts`` na :ref:`especificação " +"de pontos de entrada `. A chave da tabela é o nome do ponto de " +"entrada e o valor é a referência do objeto." #: ../source/specifications/declaring-project-metadata.rst:224 msgid "" @@ -13906,6 +14351,9 @@ msgid "" "in the :ref:`entry points specification `. Its format is the " "same as ``[project.scripts]``." msgstr "" +"A tabela ``[project.gui-scripts]`` corresponde ao grupo ``gui_scripts`` na " +":ref:`especificação de pontos de entrada `. Seu formato é o " +"mesmo que ``[project.scripts]``." #: ../source/specifications/declaring-project-metadata.rst:228 msgid "" @@ -13914,6 +14362,11 @@ msgid "" "same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but " "instead keep the entry point groups to only one level deep." msgstr "" +"A tabela ``[project.entry-points]`` é uma coleção de tabelas. O nome de cada " +"subtabela é um grupo de pontos de entrada. A chave e a semântica do valor " +"são iguais a ``[project.scripts]``. Os usuários NÃO DEVEM criar subtabelas " +"aninhadas, mas sim manter os grupos de pontos de entrada em apenas um nível " +"de profundidade." #: ../source/specifications/declaring-project-metadata.rst:234 msgid "" @@ -15461,7 +15914,7 @@ msgid "" "This section covers the basics of how to install Python :term:`packages " "`." msgstr "" -"Esta seção cobre o básico de como instalar term:`pacotes ` Python." #: ../source/tutorials/installing-packages.rst:10 From 6f56cd98915b27658bac8a8a2e4d5674654852b8 Mon Sep 17 00:00:00 2001 From: moto kawasaki Date: Thu, 25 Nov 2021 01:21:26 +0100 Subject: [PATCH 0196/1072] Translated using Weblate (Japanese) Currently translated at 12.4% (283 of 2271 strings) Co-authored-by: moto kawasaki Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/ja/ Translation: pypa/packaging.python.org --- locales/ja/LC_MESSAGES/messages.po | 49 +++++++++++++++++++++--------- 1 file changed, 34 insertions(+), 15 deletions(-) diff --git a/locales/ja/LC_MESSAGES/messages.po b/locales/ja/LC_MESSAGES/messages.po index 1702920c2..6ac55fddf 100644 --- a/locales/ja/LC_MESSAGES/messages.po +++ b/locales/ja/LC_MESSAGES/messages.po @@ -7,7 +7,7 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-11-22 17:23+0000\n" +"PO-Revision-Date: 2021-11-25 00:21+0000\n" "Last-Translator: moto kawasaki \n" "Language-Team: Japanese \n" @@ -1177,65 +1177,84 @@ msgstr "過去のデータ品質における既知の問題 (ダウンロード #: ../source/guides/analyzing-pypi-package-downloads.rst:34 msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" msgstr "" +"**とりわけ利用価値があるというわけではない** プロジェクト(の配布物、訳註。)がたくさんダウンロードされたからといってそれだけで良いことだと決まったわ" +"けではありませんし、あまりダウンロードされなかったとしてもそれだけで悪いことだと決めつけることもできません！" #: ../source/guides/analyzing-pypi-package-downloads.rst:38 msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." msgstr "" +"まとめると、様々な理由からそれ(訳註、ダウンロード統計)の価値が低い上、動作させるために犠牲になるものが多いので、限られた資源の効率的な利用にはならないの" +"です。" #: ../source/guides/analyzing-pypi-package-downloads.rst:43 msgid "Public dataset" -msgstr "" +msgstr "公開データセット" #: ../source/guides/analyzing-pypi-package-downloads.rst:45 msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." msgstr "" +"別の方法としては、 `Linehaulプロジェクト `__ " +"がダウンロードのログをPyPIから `Google BigQuery`_ [#]_ へ連続的に取り出して、公開のデータセットとして保管しています。" #: ../source/guides/analyzing-pypi-package-downloads.rst:50 msgid "Getting set up" -msgstr "" +msgstr "セットアップのやり方" #: ../source/guides/analyzing-pypi-package-downloads.rst:52 msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" msgstr "" +"`Google BigQuery`_ を使って `PyPIダウンロード統計の公開データセット `_ にクエリを行うためには、まずGoogleアカウントが必要で、Google Cloud Platform " +"(GCP)でBigQuery APIを有効にしておく必要があります。`クレジットカード登録なしのBigQuery 無料枠 `__ を使うと一ヶ月当たり1TBまでのクエリを走らせることができます。" #: ../source/guides/analyzing-pypi-package-downloads.rst:58 msgid "Navigate to the `BigQuery web UI`_." -msgstr "" +msgstr "`BigQuery web UI`_ の使い方。" #: ../source/guides/analyzing-pypi-package-downloads.rst:59 msgid "Create a new project." -msgstr "" +msgstr "新しいプロジェクトを作成する。" #: ../source/guides/analyzing-pypi-package-downloads.rst:60 msgid "Enable the `BigQuery API `__." msgstr "" +"`BigQuery API `__ を有効にする。" #: ../source/guides/analyzing-pypi-package-downloads.rst:63 msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." msgstr "" +"BigQueryの始め方についてさらに詳しい指南が欲しい場合は、`Cloud Console を使用したクイックスタート `__ を参照してください。" #: ../source/guides/analyzing-pypi-package-downloads.rst:69 msgid "Data schema" -msgstr "" +msgstr "データ構造" #: ../source/guides/analyzing-pypi-package-downloads.rst:71 msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" msgstr "" +"それぞれのダウンロードの情報を格納した ``bigquery-public-data.pypi.file_downloads``テーブルについての説明をL" +"inehaulが書きました。このテーブルは、どのファイルがどのようにダウンロードされたかに関する情報を格納しています。`テーブル構造 " +"`__ から役に立つカラムをいくつか挙げると：" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 msgid "Column" -msgstr "" +msgstr "カラム" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 #: ../source/guides/using-manifest-in.rst:67 #: ../source/specifications/core-metadata.rst:185 msgid "Description" -msgstr "" +msgstr "説明" #: ../source/guides/analyzing-pypi-package-downloads.rst:78 #: ../source/specifications/direct-url.rst:226 msgid "Examples" -msgstr "" +msgstr "例" #: ../source/guides/analyzing-pypi-package-downloads.rst:80 msgid "timestamp" @@ -1243,7 +1262,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:80 msgid "Date and time" -msgstr "" +msgstr "日付と時刻" #: ../source/guides/analyzing-pypi-package-downloads.rst:80 msgid "``2020-03-09 00:33:03 UTC``" @@ -1255,7 +1274,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:82 msgid "Project name" -msgstr "" +msgstr "プロジェクト名" #: ../source/guides/analyzing-pypi-package-downloads.rst:82 msgid "``pipenv``, ``nose``" @@ -1267,7 +1286,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:84 msgid "Package version" -msgstr "" +msgstr "パッケージのバージョン" #: ../source/guides/analyzing-pypi-package-downloads.rst:84 msgid "``0.1.6``, ``1.4.2``" @@ -1279,7 +1298,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:86 msgid "Installer" -msgstr "" +msgstr "インストーラ" #: ../source/guides/analyzing-pypi-package-downloads.rst:86 msgid "pip, `bandersnatch`_" @@ -1291,7 +1310,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:88 msgid "Python version" -msgstr "" +msgstr "Pythonのバージョン" #: ../source/guides/analyzing-pypi-package-downloads.rst:88 msgid "``2.7.12``, ``3.6.4``" @@ -1299,7 +1318,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:93 msgid "Useful queries" -msgstr "" +msgstr "役に立つクエリ" #: ../source/guides/analyzing-pypi-package-downloads.rst:95 msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." From e4e06d7eb3d17be01232b2bbe05a0b5df30b835e Mon Sep 17 00:00:00 2001 From: Rafael Fontenelle Date: Sat, 27 Nov 2021 15:42:51 +0100 Subject: [PATCH 0197/1072] Translated using Weblate (Portuguese (Brazil)) Currently translated at 93.9% (2133 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 93.6% (2126 of 2271 strings) Co-authored-by: Rafael Fontenelle Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/pt_BR/ Translation: pypa/packaging.python.org --- locales/pt_BR/LC_MESSAGES/messages.po | 288 ++++++++++++++++++++++---- 1 file changed, 242 insertions(+), 46 deletions(-) diff --git a/locales/pt_BR/LC_MESSAGES/messages.po b/locales/pt_BR/LC_MESSAGES/messages.po index 1d357d33e..75959ab60 100644 --- a/locales/pt_BR/LC_MESSAGES/messages.po +++ b/locales/pt_BR/LC_MESSAGES/messages.po @@ -8,7 +8,7 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-11-25 00:21+0000\n" +"PO-Revision-Date: 2021-11-27 14:42+0000\n" "Last-Translator: Rafael Fontenelle \n" "Language-Team: Portuguese (Brazil) \n" @@ -13904,7 +13904,7 @@ msgid "" "the format used." msgstr "" "A :pep:`621` especifica como escrever :ref:`metadados principais `de um projeto em um arquivo ``pyproject.toml`` para ferramentas " +"metadata>` de um projeto em um arquivo ``pyproject.toml`` para ferramentas " "relacionadas ao empacotamento consumirem. Ele define a seguinte " "especificação como a fonte canônica para o formato usado." @@ -14375,16 +14375,22 @@ msgid "" "table, as they would be ambiguous in the face of ``[project.scripts]`` and " "``[project.gui-scripts]``, respectively." msgstr "" +"Backends de construção DEVEM levantar um erro se os metadados definem uma " +"tabela ``[project.entry-points.console_scripts]`` ou ``[project.entry-points." +"gui_scripts]``, pois elas seriam ambíguas perante ``[project.scripts]`` e " +"``[project.gui-scripts]``, respectivamente." #: ../source/specifications/declaring-project-metadata.rst:242 msgid "``dependencies``/``optional-dependencies``" -msgstr "" +msgstr "``dependencies``/``optional-dependencies``" #: ../source/specifications/declaring-project-metadata.rst:244 msgid "" "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with " "values of arrays of :pep:`508` strings (``optional-dependencies``)" msgstr "" +"Tipo TOML_: Vetor de strings da :pep:`508` (``dependencies``) e uma tabela " +"com valores de vetores de strings da :pep:`508` (``optional-dependencies``)" #: ../source/specifications/declaring-project-metadata.rst:247 msgid "" @@ -14392,10 +14398,13 @@ msgid "" "Dist ` and :ref:`Provides-Extra `" msgstr "" +"Campo correspondente dos :ref:`metadados principais `: :ref" +":`Requires-Dist ` e :ref:`Provides-Extra `" #: ../source/specifications/declaring-project-metadata.rst:251 msgid "The (optional) dependencies of the project." -msgstr "" +msgstr "As dependências (opcionais) do projeto." #: ../source/specifications/declaring-project-metadata.rst:253 msgid "" @@ -14404,6 +14413,10 @@ msgid "" "valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist " "` entry." msgstr "" +"Para ``dependencies``, é uma chave cujo valor é um array de strings. Cada " +"string representa uma dependência do projeto e DEVE ser formatada como uma " +"string válida :pep:`508`. Cada string mapeia diretamente para um :ref" +":`Requires-Dist `." #: ../source/specifications/declaring-project-metadata.rst:258 msgid "" @@ -14415,19 +14428,28 @@ msgid "" "dist>` entry for the matching :ref:`Provides-Extra ` metadata." msgstr "" +"Para ``optional-dependencies``, é uma tabela onde cada chave especifica um " +"extra e cujo valor é um vetor de strings. As strings dos vetores devem ser " +"strings válidas da :pep:`508`. As chaves DEVEM ser valores válidos para :ref" +":`Provides-Extra `. Cada valor no vetor torna-" +"se assim uma entrada correspondente de :ref:`Requer-Dist ` para os metadados correspondentes de :ref:`Provides-Extra " +"`." #: ../source/specifications/declaring-project-metadata.rst:269 msgid "``dynamic``" -msgstr "" +msgstr "``dynamic``" #: ../source/specifications/declaring-project-metadata.rst:271 msgid "TOML_ type: array of string" -msgstr "" +msgstr "Tipo TOML_: vetor de string" #: ../source/specifications/declaring-project-metadata.rst:272 msgid "" "A corresponding :ref:`core metadata ` field does not exist" msgstr "" +"Não há um campo correspondente dos :ref:`metadados principais `" #: ../source/specifications/declaring-project-metadata.rst:275 msgid "" @@ -14436,18 +14458,28 @@ msgid "" "delineates which metadata is purposefully unspecified and expected to stay " "unspecified compared to being provided via tooling later on." msgstr "" +"Especifica quais campos listados por esta PEP foram intencionalmente não " +"especificados para que outra ferramenta possa/vai fornecer tais metadados " +"dinamicamente. Isso delineia claramente quais metadados são propositalmente " +"não especificados e espera-se que permaneçam não especificados em comparação " +"a serem fornecidos por meio de ferramentas posteriormente." #: ../source/specifications/declaring-project-metadata.rst:281 msgid "" "A build back-end MUST honour statically-specified metadata (which means the " "metadata did not list the field in ``dynamic``)." msgstr "" +"Um backend de construção DEVE respeitar metadados especificados " +"estaticamente (o que significa que os metadados não listam o campo em " +"``dynamic``)." #: ../source/specifications/declaring-project-metadata.rst:283 msgid "" "A build back-end MUST raise an error if the metadata specifies ``name`` in " "``dynamic``." msgstr "" +"Um backend de construção DEVE gerar um erro se os metadados especificarem " +"``name`` em ``dynamic``." #: ../source/specifications/declaring-project-metadata.rst:285 msgid "" @@ -14457,6 +14489,11 @@ msgid "" "should not be possible for a required field to not be listed somehow in the " "``[project]`` table)." msgstr "" +"Se a especificação de :ref: `metadados principais ` lista um " +"campo como \"Required\", então os metadados DEVEM especificar o campo " +"estaticamente ou listá-lo em ``dynamic`` (backends de construção DEVEM gerar " +"um erro, caso contrário , ou seja, não deve ser possível que um campo " +"obrigatório não seja listado de alguma forma na tabela ``[project]``)." #: ../source/specifications/declaring-project-metadata.rst:290 msgid "" @@ -14464,12 +14501,18 @@ msgid "" "\"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is " "a build back-end will provide the data for the field later." msgstr "" +"Se a especificação de :ref:`metadados principais ` listar um " +"campo como \"Optional\", os metadados PODEM listá-lo em ``dynamic`` se a " +"expectativa for um backend de construção fornecerá os dados para o campo " +"mais tarde." #: ../source/specifications/declaring-project-metadata.rst:294 msgid "" "Build back-ends MUST raise an error if the metadata specifies a field " "statically as well as being listed in ``dynamic``." msgstr "" +"Os backends de construção DEVEM levantar um erro se os metadados " +"especificarem um campo estaticamente, além de serem listados em `` dynamic``." #: ../source/specifications/declaring-project-metadata.rst:296 msgid "" @@ -14478,6 +14521,10 @@ msgid "" "``dynamic`` is the only way to allow a tool to fill in metadata and the user " "must opt into the filling in)." msgstr "" +"Se os metadados não listam um campo em ``dynamic``, então um backend de " +"construção NÃO PODE preencher os metadados necessários em nome do usuário (" +"ou seja, ``dynamic`` é a única maneira de permitir que uma ferramenta " +"preencha metadados e o usuário deve optar pelo preenchimento)." #: ../source/specifications/declaring-project-metadata.rst:300 msgid "" @@ -14485,26 +14532,34 @@ msgid "" "``dynamic`` but the build back-end was unable to determine the data for it " "(omitting the data, if determined to be the accurate value, is acceptable)." msgstr "" +"Os backends de construção DEVEM levantar um erro se os metadados " +"especificarem um campo em ``dynamic``, mas o backend de construção não foi " +"capaz de determinar os dados para ele (omitir os dados, se determinado como " +"o valor exato, é aceitável) ." #: ../source/specifications/dependency-specifiers.rst:6 msgid "Dependency specifiers" -msgstr "" +msgstr "Especificadores de dependência" #: ../source/specifications/dependency-specifiers.rst:8 msgid "" "The dependency specifier format used to declare a dependency on another " "component is defined in :pep:`508`." msgstr "" +"O formato do especificador de dependência usado para declarar uma " +"dependência de outro componente é definido na :pep:`508`." #: ../source/specifications/dependency-specifiers.rst:11 msgid "" "The environment markers section in this PEP supersedes the environment " "markers section in :pep:`345`." msgstr "" +"A seção de marcadores de ambiente nesta PEP substitui a seção de marcadores " +"de ambiente na :pep:`345`." #: ../source/specifications/direct-url.rst:6 msgid "Recording the Direct URL Origin of installed distributions" -msgstr "" +msgstr "Gravando a Origem da URL Direta de distribuições instaladas" #: ../source/specifications/direct-url.rst:8 msgid "" @@ -14513,10 +14568,14 @@ msgid "" "Origin of the distribution. The layout of this file was originally specified " "in :pep:`610` and is formally documented here." msgstr "" +"Este documento especifica um arquivo :file:`direct_url.json` no diretório " +":file:`*.dist-info` de uma distribuição instalada, para registrar a origem " +"da URL direta da distribuição. O layout deste arquivo foi originalmente " +"especificado na :pep:`610` e está formalmente documentado aqui." #: ../source/specifications/direct-url.rst:17 msgid "Specification" -msgstr "" +msgstr "Especificação" #: ../source/specifications/direct-url.rst:19 msgid "" @@ -14524,6 +14583,10 @@ msgid "" "directory by installers when installing a distribution from a requirement " "specifying a direct URL reference (including a VCS URL)." msgstr "" +"O arquivo :file:`direct_url.json` DEVE ser criado no diretório :file:`*.dist-" +"info` pelos instaladores ao instalar uma distribuição a partir de um " +"requisito especificando uma referência de URL direta (incluindo uma URL de " +"VCS)." #: ../source/specifications/direct-url.rst:23 #: ../source/specifications/recording-installed-packages.rst:206 @@ -14531,12 +14594,16 @@ msgid "" "This file MUST NOT be created when installing a distribution from an other " "type of requirement (i.e. name plus version specifier)." msgstr "" +"Este arquivo NÃO DEVE ser criado ao instalar uma distribuição de outro tipo " +"de requisito (ou seja, nome mais especificador de versão)." #: ../source/specifications/direct-url.rst:26 msgid "" "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." msgstr "" +"Este arquivo JSON DEVE ser um dicionário compatível com `RFC 8259 " +"`_ e codificado em UTF-8." #: ../source/specifications/direct-url.rst:29 msgid "" @@ -14548,18 +14615,29 @@ msgid "" "(possibly empty) subdictionary as value, with the possible keys defined " "below." msgstr "" +"Se presente, DEVE conter pelo menos dois campos. O primeiro é ``url``, com " +"tipo ``string``. Dependendo de qual ``url`` se refere, o segundo campo DEVE " +"ser um de ``vcs_info`` (se ``url`` é uma referência de VCS), ``archive_info``" +" (se ``url`` é um arquivo de código-fonte ou um wheel) ou ``dir_info`` (se " +"``url`` é um diretório local). Estes campos informacionais têm um " +"subdicionário (possivelmente vazio) como valor, com as chaves possíveis " +"definidas abaixo." #: ../source/specifications/direct-url.rst:36 msgid "" "``url`` MUST be stripped of any sensitive authentication information, for " "security reasons." msgstr "" +"``url`` DEVE ser podado a fim de retirar qualquer informação de autenticação " +"sensível, por razões de segurança." #: ../source/specifications/direct-url.rst:39 msgid "" "The user:password section of the URL MAY however be composed of environment " "variables, matching the following regular expression::" msgstr "" +"A seção usuário:senha da URL PODE, entretanto, ser composta de variáveis de " +"ambiente, correspondendo à seguinte expressão regular::" #: ../source/specifications/direct-url.rst:45 msgid "" @@ -14567,12 +14645,17 @@ msgid "" "security sensitive string. A typical example is ``git`` in the case of an " "URL such as ``ssh://git@gitlab.com/user/repo``." msgstr "" +"Além disso, a seção usuário:senha da URL PODE ser uma string bem conhecida e " +"não sensível à segurança. Um exemplo típico é ``git`` no caso de uma URL " +"como ``ssh://git@gitlab.com/user/repo``." #: ../source/specifications/direct-url.rst:49 msgid "" "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be " "present as a dictionary with the following keys:" msgstr "" +"Quando a ``url`` faz referência a um repositório VCS, a chave ``vcs_info`` " +"DEVE estar presente como um dicionário com as seguintes chaves:" #: ../source/specifications/direct-url.rst:52 msgid "" @@ -14582,6 +14665,11 @@ msgid "" "MUST be compatible with the corresponding VCS, so an installer can hand it " "off without transformation to a checkout/download command of the VCS." msgstr "" +"Uma chave ``vcs`` (tipo ``string``) DEVE estar presente, contendo o nome do " +"VCS (ou seja, um de ``git``, ``hg``, ``bzr``, ``svn``). Outros VCS DEVERIAM " +"ser registrados escrevendo uma PEP para alterar esta especificação. O valor " +"``url`` DEVE ser compatível com o VCS correspondente, para que um instalador " +"possa entregá-lo sem transformação em um comando de checkout/download do VCS." #: ../source/specifications/direct-url.rst:58 msgid "" @@ -14589,6 +14677,9 @@ msgid "" "branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to " "install." msgstr "" +"Uma chave ``required_revision`` (tipo ``string``) PODE estar presente " +"nomeando um branch/tag/ref/commit/revisão/etc (em um formato compatível com " +"o VCS) para instalar." #: ../source/specifications/direct-url.rst:61 msgid "" @@ -14598,12 +14689,19 @@ msgid "" "in order to reference the immutable version of the source code that was " "installed." msgstr "" +"Uma chave ``commit_id`` (tipo ``string``) DEVE estar presente, contendo o " +"número exato de commit/revisão que foi instalado. Se o VCS oferecer suporte " +"a identificadores de revisão baseados em hash de commit, tal hash de commit " +"DEVE ser usado como ``commit_id`` para referenciar a versão imutável do " +"código-fonte que foi instalado." #: ../source/specifications/direct-url.rst:68 msgid "" "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key " "MUST be present as a dictionary with the following key:" msgstr "" +"Quando ``url`` se refere a um arquivo fonte ou wheel, a chave " +"``archive_info`` DEVE estar presente como um dicionário com a seguinte chave:" #: ../source/specifications/direct-url.rst:71 msgid "" @@ -14614,18 +14712,29 @@ msgid "" "that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and " "'sha512'." msgstr "" +"Uma chave ``hash`` (tipo ``string``) DEVE estar presente, com o valor " +"``=``. É RECOMENDADO que apenas hashes que " +"são fornecidos incondicionalmente pela última versão do módulo ``hashlib`` " +"da biblioteca padrão sejam usados para hashes de arquivo fonte. No momento " +"da escrita, essa lista consistia em 'md5', 'sha1', 'sha224', 'sha256', " +"'sha384' e 'sha512'." #: ../source/specifications/direct-url.rst:78 msgid "" "When ``url`` refers to a local directory, the ``dir_info`` key MUST be " "present as a dictionary with the following key:" msgstr "" +"Quando ``url`` se refere a um diretório local, a chave ``dir_info`` DEVE " +"estar presente como um dicionário com a seguinte chave:" #: ../source/specifications/direct-url.rst:81 msgid "" "``editable`` (type: ``boolean``): ``true`` if the distribution was installed " "in editable mode, ``false`` otherwise. If absent, default to ``false``." msgstr "" +"``editable`` (tipo: ``boolean``): ``true`` se a distribuição foi instalada " +"em modo editável, ``false`` caso contrário. Se ausente, é usado o padrão " +"``false``." #: ../source/specifications/direct-url.rst:84 msgid "" @@ -14634,6 +14743,11 @@ msgid "" "particular, the path component must be absolute. Symbolic links SHOULD be " "preserved when making relative paths absolute." msgstr "" +"Quando ``url`` se refere a um diretório local, ele DEVE ter o esquema `` " +"file`` e ser compatível com `RFC 8089 `" +"_. Em particular, o componente do caminho deve ser absoluto. Links " +"simbólicos DEVERIAM ser preservados ao tornar os caminhos relativos " +"absolutos." #: ../source/specifications/direct-url.rst:91 msgid "" @@ -14642,6 +14756,10 @@ msgid "" "attempt to infer any VCS information and therefore MUST NOT output any VCS " "related information (such as ``vcs_info``) in :file:`direct_url.json`." msgstr "" +"Quando a URL solicitada tem o esquema file:// e aponta para um diretório " +"local que contém um checkout VCS, os instaladores NÃO DEVEM tentar inferir " +"nenhuma informação VCS e, portanto, NÃO DEVEM emitir nenhuma informação " +"relacionada ao VCS (como ``vcs_info``) in :file:` direct_url.json`." #: ../source/specifications/direct-url.rst:96 msgid "" @@ -14649,6 +14767,10 @@ msgid "" "path, relative to the root of the VCS repository, source archive or local " "directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." msgstr "" +"Um campo ``subdirectory`` de nível superior PODE estar presente contendo um " +"caminho de diretório, relativo à raiz do repositório VCS, arquivo fonte ou " +"diretório local, para especificar onde ``pyproject.toml`` ou ``setup.py`` " +"está localizado." #: ../source/specifications/direct-url.rst:102 msgid "" @@ -14659,10 +14781,16 @@ msgid "" "provided in the requested URL as faithfully as possible. This information is " "however *enriched* with more precise data, such as ``commit_id``." msgstr "" +"Como regra geral, os instaladores devem, tanto quanto possível, preservar as " +"informações fornecidas na URL solicitada ao gerar :file:`direct_url.json`. " +"Por exemplo, as variáveis de ambiente usuário:senha devem ser preservadas e " +"``required_revision`` deve refletir a revisão que foi fornecida na URL " +"solicitada o mais fielmente possível. No entanto, essas informações são " +"*enriquecidas* com dados mais precisos, como ``commit_id``." #: ../source/specifications/direct-url.rst:110 msgid "Registered VCS" -msgstr "" +msgstr "VCS registrados" #: ../source/specifications/direct-url.rst:112 msgid "" @@ -14674,64 +14802,74 @@ msgid "" "name (lowercased). Additional fields that would be necessary to support such " "VCS SHOULD be prefixed with the VCS command name." msgstr "" +"Esta seção lista os VCS registrados; expandidos, informações específicas do " +"VCS sobre como usar ``vcs``, ``required_revision`` e outros campos de " +"``vcs_info``; e, em alguns casos, campos adicionais específicos de VCS. As " +"ferramentas PODEM oferecer suporte a outros VCS, embora seja RECOMENDADO " +"registrá-las escrevendo uma PEP para alterar esta especificação. O campo " +"``vcs`` DEVERIA ser o nome do comando (em letras minúsculas). Os campos " +"adicionais que seriam necessários para oferecer suporte a esse VCS DEVERIAM " +"ser prefixados com o nome do comando VCS." #: ../source/specifications/direct-url.rst:122 msgid "Git" -msgstr "" +msgstr "Git" #: ../source/specifications/direct-url.rst:124 #: ../source/specifications/direct-url.rst:156 #: ../source/specifications/direct-url.rst:179 #: ../source/specifications/direct-url.rst:202 msgid "Home page" -msgstr "" +msgstr "Site" #: ../source/specifications/direct-url.rst:126 msgid "https://git-scm.com/" -msgstr "" +msgstr "https://git-scm.com/" #: ../source/specifications/direct-url.rst:128 #: ../source/specifications/direct-url.rst:160 #: ../source/specifications/direct-url.rst:183 #: ../source/specifications/direct-url.rst:206 msgid "vcs command" -msgstr "" +msgstr "Comando vcs" #: ../source/specifications/direct-url.rst:130 #: ../source/specifications/direct-url.rst:134 msgid "git" -msgstr "" +msgstr "git" #: ../source/specifications/direct-url.rst:132 #: ../source/specifications/direct-url.rst:164 #: ../source/specifications/direct-url.rst:187 #: ../source/specifications/direct-url.rst:210 msgid "``vcs`` field" -msgstr "" +msgstr "Campo ``vcs``" #: ../source/specifications/direct-url.rst:136 #: ../source/specifications/direct-url.rst:168 #: ../source/specifications/direct-url.rst:191 #: ../source/specifications/direct-url.rst:214 msgid "``requested_revision`` field" -msgstr "" +msgstr "Campo ``requested_revision``" #: ../source/specifications/direct-url.rst:138 msgid "" "A tag name, branch name, Git ref, commit hash, shortened commit hash, or " "other commit-ish." msgstr "" +"Um nome de tag, nome de branch, ref Git, hash de commit, hash de commit " +"encurtado ou outra coisa relacionada a commit." #: ../source/specifications/direct-url.rst:141 #: ../source/specifications/direct-url.rst:172 #: ../source/specifications/direct-url.rst:195 #: ../source/specifications/direct-url.rst:219 msgid "``commit_id`` field" -msgstr "" +msgstr "Campo ``commit_id``" #: ../source/specifications/direct-url.rst:143 msgid "A commit hash (40 hexadecimal characters sha1)." -msgstr "" +msgstr "Um hash de confirmação (40 caracteres hexadecimais sha1)." #: ../source/specifications/direct-url.rst:147 msgid "" @@ -14740,48 +14878,54 @@ msgid "" "ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning " "with ``refs/remotes/origin/`` after cloning corresponds to a branch." msgstr "" +"Os instaladores podem usar os comandos ``git show-ref`` e ``git symbolic-" +"ref`` para determinar se o ``required_revision`` corresponde a um ref Git. " +"Por sua vez, um ref começando com ``refs/tags/`` corresponde a uma tag, e um " +"ref começando com ``refs/remotes/origin/`` após a clonagem corresponde a um " +"branch." #: ../source/specifications/direct-url.rst:154 msgid "Mercurial" -msgstr "" +msgstr "Mercurial" #: ../source/specifications/direct-url.rst:158 msgid "https://www.mercurial-scm.org/" -msgstr "" +msgstr "https://www.mercurial-scm.org/" #: ../source/specifications/direct-url.rst:162 #: ../source/specifications/direct-url.rst:166 msgid "hg" -msgstr "" +msgstr "hg" #: ../source/specifications/direct-url.rst:170 msgid "A tag name, branch name, changeset ID, shortened changeset ID." msgstr "" +"Um nome de tag, nome de branch, ID de changeset, ID de changeset abreviado." #: ../source/specifications/direct-url.rst:174 msgid "A changeset ID (40 hexadecimal characters)." -msgstr "" +msgstr "Um ID de changeset (40 caracteres hexadecimais)." #: ../source/specifications/direct-url.rst:177 msgid "Bazaar" -msgstr "" +msgstr "Bazaar" #: ../source/specifications/direct-url.rst:181 msgid "https://bazaar.canonical.com/" -msgstr "" +msgstr "https://bazaar.canonical.com/" #: ../source/specifications/direct-url.rst:185 #: ../source/specifications/direct-url.rst:189 msgid "bzr" -msgstr "" +msgstr "bzr" #: ../source/specifications/direct-url.rst:193 msgid "A tag name, branch name, revision id." -msgstr "" +msgstr "Um nome de tag, nome de branch, id de revisão." #: ../source/specifications/direct-url.rst:197 msgid "A revision id." -msgstr "" +msgstr "Um id de revisão." #: ../source/specifications/direct-url.rst:200 msgid "Subversion" @@ -14794,69 +14938,76 @@ msgstr "" #: ../source/specifications/direct-url.rst:208 #: ../source/specifications/direct-url.rst:212 msgid "svn" -msgstr "" +msgstr "svn" #: ../source/specifications/direct-url.rst:216 msgid "" "``requested_revision`` must be compatible with ``svn checkout`` ``--" "revision`` option. In Subversion, branch or tag is part of ``url``." msgstr "" +"``requested_revision`` deve ser compatível com a opção ``--revision`` do ``" +"svn checkout``. No Subversion, branch ou tag é parte de ``url``." #: ../source/specifications/direct-url.rst:221 msgid "" "Since Subversion does not support globally unique identifiers, this field is " "the Subversion revision number in the corresponding repository." msgstr "" +"Visto que o Subversion não oferece suporte a identificadores globalmente " +"únicos, este campo é o número da revisão do Subversion no repositório " +"correspondente." #: ../source/specifications/direct-url.rst:229 msgid "Example direct_url.json" -msgstr "" +msgstr "Exemplo de direct_url.json" #: ../source/specifications/direct-url.rst:231 msgid "Source archive:" -msgstr "" +msgstr "Arquivo fonte:" #: ../source/specifications/direct-url.rst:242 msgid "Git URL with tag and commit-hash:" -msgstr "" +msgstr "URL Git com tag e hash de commit:" #: ../source/specifications/direct-url.rst:255 msgid "Local directory:" -msgstr "" +msgstr "Diretório local:" #: ../source/specifications/direct-url.rst:264 msgid "Local directory installed in editable mode:" -msgstr "" +msgstr "Diretório local instalado em modo editável:" #: ../source/specifications/direct-url.rst:277 msgid "Example pip commands and their effect on direct_url.json" -msgstr "" +msgstr "Exemplo de comandos pip e seus efeitos em direct_url.json" #: ../source/specifications/direct-url.rst:279 msgid "Commands that generate a ``direct_url.json``:" -msgstr "" +msgstr "Comandos que geram um ``direct_url.json``:" #: ../source/specifications/direct-url.rst:281 msgid "pip install https://example.com/app-1.0.tgz" -msgstr "" +msgstr "pip install https://example.com/app-1.0.tgz" #: ../source/specifications/direct-url.rst:282 msgid "pip install https://example.com/app-1.0.whl" -msgstr "" +msgstr "pip install https://example.com/app-1.0.whl" #: ../source/specifications/direct-url.rst:283 msgid "" "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup" "\"" msgstr "" +"pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=" +"setup\"" #: ../source/specifications/direct-url.rst:284 msgid "pip install ./app" -msgstr "" +msgstr "pip install ./app" #: ../source/specifications/direct-url.rst:285 msgid "pip install file:///home/user/app" -msgstr "" +msgstr "pip install file:///home/user/app" #: ../source/specifications/direct-url.rst:286 msgid "" @@ -14865,32 +15016,39 @@ msgid "" "directory where the git repository has been cloned to, and ``dir_info`` will " "be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" msgstr "" +"pip install --editable \"git+https://example.com/repo/app." +"git#egg=app&subdirectory=setup\" (caso em que, ``url`` será o diretório " +"local para o qual o repositório git foi clonado e ``dir_info`` estará " +"presente com ``\"editable\": true`` e nenhum ``vcs_info`` será definido)" #: ../source/specifications/direct-url.rst:290 msgid "pip install -e ./app" -msgstr "" +msgstr "pip install -e ./app" #: ../source/specifications/direct-url.rst:292 msgid "Commands that *do not* generate a ``direct_url.json``" -msgstr "" +msgstr "Comandos que *não* geram um ``direct_url.json``" #: ../source/specifications/direct-url.rst:294 msgid "pip install app" -msgstr "" +msgstr "pip install app" #: ../source/specifications/direct-url.rst:295 msgid "pip install app --no-index --find-links https://example.com/" -msgstr "" +msgstr "pip install app --no-index --find-links https://example.com/" #: ../source/specifications/entry-points.rst:5 msgid "Entry points specification" -msgstr "" +msgstr "Especificação de pontos de entrada" #: ../source/specifications/entry-points.rst:7 msgid "" "*Entry points* are a mechanism for an installed distribution to advertise " "components it provides to be discovered and used by other code. For example:" msgstr "" +"*Pontos de entrada* são um mecanismo para uma distribuição instalada " +"anunciar componentes que ela fornece para serem descobertos e usados por " +"outro código. Por exemplo:" #: ../source/specifications/entry-points.rst:11 msgid "" @@ -14899,6 +15057,10 @@ msgid "" "installs the distribution, it will create a command-line wrapper for each " "entry point." msgstr "" +"As distribuições podem especificar pontos de entrada ``console_scripts``, " +"cada um referindo-se a uma função. Quando *pip* (ou outro instalador " +"compatível com console_scripts) instala a distribuição, ele cria um wrapper " +"de linha de comando para cada ponto de entrada." #: ../source/specifications/entry-points.rst:14 msgid "" @@ -14907,6 +15069,10 @@ msgid "" "installed packages. For more about this, see :doc:`/guides/creating-and-" "discovering-plugins`." msgstr "" +"As aplicações podem usar pontos de entrada para carregar plug-ins; por " +"exemplo, Pygments (uma ferramenta de realce de sintaxe) pode usar lexers e " +"estilos adicionais de pacotes instalados separadamente. Para mais " +"informações, consulte :doc:`/guides/creating-and-discovering-plugins`." #: ../source/specifications/entry-points.rst:19 msgid "" @@ -14919,14 +15085,26 @@ msgid "" "portably read published entry point metadata (potentially with different " "caching and conflict resolution strategies)." msgstr "" +"O formato de arquivo de ponto de entrada foi originalmente desenvolvido para " +"permitir que pacotes construídos com setuptools forneçam metadados de ponto " +"de integração que seriam lidos em tempo de execução com ``importlib." +"metadata``. Ele agora é definido como uma especificação de " +"interoperabilidade PyPA a fim de permitir que outras ferramentas de " +"construção além do setuptools publiquem metadados de ponto de entrada " +"compatíveis com ``importlib.metadata`` e bibliotecas de tempo de execução " +"diferentes de ``importlib.metadata`` para ler portavelmente publicado " +"metadados de ponto de entrada (potencialmente com diferentes estratégias de " +"cache e resolução de conflitos)." #: ../source/specifications/entry-points.rst:28 msgid "Data model" -msgstr "" +msgstr "Modelo de dados" #: ../source/specifications/entry-points.rst:30 msgid "Conceptually, an entry point is defined by three required properties:" msgstr "" +"Conceitualmente, um ponto de entrada é definido por três propriedades " +"necessárias:" #: ../source/specifications/entry-points.rst:32 msgid "" @@ -14940,6 +15118,15 @@ msgid "" "of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w" "+)*$``)." msgstr "" +"O **grupo** ao qual um ponto de entrada pertence indica que tipo de objeto " +"ele fornece. Por exemplo, o grupo ``console_scripts`` é para pontos de " +"entrada referentes a funções que podem ser usadas como um comando, enquanto " +"``pygments.styles`` é o grupo para classes que definem estilos de pigmentos. " +"O consumidor normalmente define a interface esperada. Para evitar conflitos, " +"os consumidores que definem um novo grupo devem usar nomes começando com um " +"nome PyPI pertencente ao projeto do consumidor, seguido por ``.``. Os nomes " +"dos grupos devem ser um ou mais grupos de letras, números e sublinhados, " +"separados por pontos (regex ``^\\w+(\\.\\w+)*$``)." #: ../source/specifications/entry-points.rst:42 msgid "" @@ -14953,6 +15140,15 @@ msgid "" "is recommended to use only letters, numbers, underscores, dots and dashes " "(regex ``[\\w.-]+``)." msgstr "" +"O **nome** identifica este ponto de entrada em seu grupo. O significado " +"preciso disso depende do cliente. Para scripts de console, o nome do ponto " +"de entrada é o comando que será usado para iniciá-lo. Em uma distribuição, " +"os nomes dos pontos de entrada devem ser exclusivos. Se distribuições " +"diferentes fornecerem o mesmo nome, o consumidor decide como lidar com tais " +"conflitos. O nome pode conter quaisquer caracteres, exceto ``=``, mas não " +"pode começar ou terminar com nenhum caractere de espaço em branco, ou " +"começar com ``[``. Para novos pontos de entrada, é recomendado usar apenas " +"letras, números, sublinhados, pontos e travessões (regex ``[\\w.-]+``)." #: ../source/specifications/entry-points.rst:51 msgid "" From 4da1d61a10ddd0405b8eeea9a5d176683f6fa79d Mon Sep 17 00:00:00 2001 From: moto kawasaki Date: Thu, 25 Nov 2021 23:26:27 +0000 Subject: [PATCH 0198/1072] Translated using Weblate (Japanese) Currently translated at 14.2% (323 of 2271 strings) Translation: pypa/packaging.python.org Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/ja/ --- locales/ja/LC_MESSAGES/messages.po | 82 +++++++++++++++++------------- 1 file changed, 46 insertions(+), 36 deletions(-) diff --git a/locales/ja/LC_MESSAGES/messages.po b/locales/ja/LC_MESSAGES/messages.po index 6ac55fddf..cdd10af41 100644 --- a/locales/ja/LC_MESSAGES/messages.po +++ b/locales/ja/LC_MESSAGES/messages.po @@ -7,7 +7,7 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-11-25 00:21+0000\n" +"PO-Revision-Date: 2021-11-27 18:18+0000\n" "Last-Translator: moto kawasaki \n" "Language-Team: Japanese \n" @@ -1322,19 +1322,21 @@ msgstr "役に立つクエリ" #: ../source/guides/analyzing-pypi-package-downloads.rst:95 msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." -msgstr "" +msgstr "「クエリを新規作成」ボタンをクリックすることで `BigQuery web UI`_ 内でクエリを走らせましょう。" #: ../source/guides/analyzing-pypi-package-downloads.rst:97 msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." msgstr "" +"クエリのコストを削減するためにデータベースの行がパーティションされた状態で格納されていることを覚えておいてください。これらの例では、``timestamp" +"`` カラムを使って絞り込むことで最近のダウンロード履歴を分析しています。" #: ../source/guides/analyzing-pypi-package-downloads.rst:102 msgid "Counting package downloads" -msgstr "" +msgstr "パッケージのダウンロードを数える" #: ../source/guides/analyzing-pypi-package-downloads.rst:104 msgid "The following query counts the total number of downloads for the project \"pytest\"." -msgstr "" +msgstr "次のクエリは\"pytest\"プロジェクトのダウンロード総数を数えています。" #: ../source/guides/analyzing-pypi-package-downloads.rst:119 #: ../source/guides/analyzing-pypi-package-downloads.rst:140 @@ -1349,7 +1351,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:124 msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." -msgstr "" +msgstr "pipを通じてダウンロードされた数だけを数えるには、``details.installer.name``カラムを使って抽出します。" #: ../source/guides/analyzing-pypi-package-downloads.rst:142 msgid "24334215" @@ -1357,11 +1359,12 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:146 msgid "Package downloads over time" -msgstr "" +msgstr "時系列のパッケージダウンロード数" #: ../source/guides/analyzing-pypi-package-downloads.rst:148 msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." msgstr "" +"月毎のダウンロード数を数えるには、``TIMESTAMP_TRUNC``関数を使います。このカラムを使って抽出することは、通信量を抑えることにもなります。" #: ../source/guides/analyzing-pypi-package-downloads.rst:168 msgid "month" @@ -1369,7 +1372,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:170 msgid "1956741" -msgstr "" +msgstr "1956741" #: ../source/guides/analyzing-pypi-package-downloads.rst:170 msgid "2018-01-01" @@ -1377,87 +1380,87 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:172 msgid "2344692" -msgstr "" +msgstr "2344692" #: ../source/guides/analyzing-pypi-package-downloads.rst:172 msgid "2017-12-01" -msgstr "" +msgstr "2017-12-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:174 msgid "1730398" -msgstr "" +msgstr "1730398" #: ../source/guides/analyzing-pypi-package-downloads.rst:174 msgid "2017-11-01" -msgstr "" +msgstr "2017-11-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:176 msgid "2047310" -msgstr "" +msgstr "2047310" #: ../source/guides/analyzing-pypi-package-downloads.rst:176 msgid "2017-10-01" -msgstr "" +msgstr "2017-10-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:178 msgid "1744443" -msgstr "" +msgstr "1744443" #: ../source/guides/analyzing-pypi-package-downloads.rst:178 msgid "2017-09-01" -msgstr "" +msgstr "2017-09-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:180 msgid "1916952" -msgstr "" +msgstr "1916952" #: ../source/guides/analyzing-pypi-package-downloads.rst:180 msgid "2017-08-01" -msgstr "" +msgstr "2017-08-01" #: ../source/guides/analyzing-pypi-package-downloads.rst:184 msgid "Python versions over time" -msgstr "" +msgstr "時系列で見たPythonバージョン" #: ../source/guides/analyzing-pypi-package-downloads.rst:186 msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." -msgstr "" +msgstr "``details.python``カラムからPythonのバージョンを取り出します。警告：このクエリは500GB以上のデータを処理します。" #: ../source/guides/analyzing-pypi-package-downloads.rst:205 msgid "python" -msgstr "" +msgstr "python" #: ../source/guides/analyzing-pypi-package-downloads.rst:207 msgid "3.7" -msgstr "" +msgstr "3.7" #: ../source/guides/analyzing-pypi-package-downloads.rst:207 msgid "18051328726" -msgstr "" +msgstr "18051328726" #: ../source/guides/analyzing-pypi-package-downloads.rst:209 msgid "3.6" -msgstr "" +msgstr "3.6" #: ../source/guides/analyzing-pypi-package-downloads.rst:209 msgid "9635067203" -msgstr "" +msgstr "9635067203" #: ../source/guides/analyzing-pypi-package-downloads.rst:211 msgid "3.8" -msgstr "" +msgstr "3.8" #: ../source/guides/analyzing-pypi-package-downloads.rst:211 msgid "7781904681" -msgstr "" +msgstr "7781904681" #: ../source/guides/analyzing-pypi-package-downloads.rst:213 msgid "2.7" -msgstr "" +msgstr "2.7" #: ../source/guides/analyzing-pypi-package-downloads.rst:213 msgid "6381252241" -msgstr "" +msgstr "6381252241" #: ../source/guides/analyzing-pypi-package-downloads.rst:215 msgid "null" @@ -1465,47 +1468,54 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:215 msgid "2026630299" -msgstr "" +msgstr "2026630299" #: ../source/guides/analyzing-pypi-package-downloads.rst:217 msgid "3.5" -msgstr "" +msgstr "3.5" #: ../source/guides/analyzing-pypi-package-downloads.rst:217 msgid "1894153540" -msgstr "" +msgstr "1894153540" #: ../source/guides/analyzing-pypi-package-downloads.rst:221 msgid "Caveats" -msgstr "" +msgstr "注意書き" #: ../source/guides/analyzing-pypi-package-downloads.rst:223 msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." msgstr "" +"上記の背景に列挙した注意書きに加えて、Linehaulは、極端に過小報告されていたダウンロード統計の原因となったバグに2018年7月26日まで悩まされてい" +"ました。この日より前のダウンロード数については、比率の点(例えばPython2とPython3の百分率)では正確ですが、絶対数の点では桁が異なるほどに過小" +"です。" #: ../source/guides/analyzing-pypi-package-downloads.rst:231 msgid "Additional tools" -msgstr "" +msgstr "その他のツール" #: ../source/guides/analyzing-pypi-package-downloads.rst:233 msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." -msgstr "" +msgstr "BigQueryコンソールを用いる他に、ダウンロード統計を分析する際に役に立つと思われるツールがいくつかあります。" #: ../source/guides/analyzing-pypi-package-downloads.rst:237 msgid "``google-cloud-bigquery``" -msgstr "" +msgstr "``google-cloud-bigquery``" #: ../source/guides/analyzing-pypi-package-downloads.rst:239 msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." msgstr "" +"BigQuery APIとBigQuery用の公式Pythonクライアントである `google-cloud-bigquery`_ " +"プロジェクトを使って、プログラムからPyPIの公開ダウンロード統計データセットにアクセスすることもできます。" #: ../source/guides/analyzing-pypi-package-downloads.rst:267 msgid "``pypinfo``" -msgstr "" +msgstr "``pypinfo``" #: ../source/guides/analyzing-pypi-package-downloads.rst:269 msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." msgstr "" +"`pypinfo`_ はデータセットにアクセスして、役に立つクエリをいくつか生成する機能を提供するコマンドラインツールです。例えば、``pypinfo " +"package_name``を実行すれば、そのパッケージのダウンロード総数を問い合わせることができます。" #: ../source/guides/analyzing-pypi-package-downloads.rst:273 msgid "Install `pypinfo`_ using pip." From 78167707ccdc7dd735cf4dcdbefc05c712204826 Mon Sep 17 00:00:00 2001 From: Rafael Fontenelle Date: Sun, 28 Nov 2021 18:48:34 +0100 Subject: [PATCH 0199/1072] Translated using Weblate (Portuguese (Brazil)) Currently translated at 100.0% (2271 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 100.0% (2271 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 95.2% (2163 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 95.2% (2163 of 2271 strings) Translated using Weblate (Portuguese (Brazil)) Currently translated at 95.2% (2163 of 2271 strings) Co-authored-by: Rafael Fontenelle Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/pt_BR/ Translation: pypa/packaging.python.org --- locales/pt_BR/LC_MESSAGES/messages.po | 466 ++++++++++++++++++++++---- 1 file changed, 392 insertions(+), 74 deletions(-) diff --git a/locales/pt_BR/LC_MESSAGES/messages.po b/locales/pt_BR/LC_MESSAGES/messages.po index 75959ab60..8e4396269 100644 --- a/locales/pt_BR/LC_MESSAGES/messages.po +++ b/locales/pt_BR/LC_MESSAGES/messages.po @@ -8,7 +8,7 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-11-27 14:42+0000\n" +"PO-Revision-Date: 2021-11-28 17:48+0000\n" "Last-Translator: Rafael Fontenelle \n" "Language-Team: Portuguese (Brazil) \n" @@ -1061,7 +1061,7 @@ msgid "" "python.org/2/library/sysconfig.html#installation-paths>`_, therefore making " "it easier to convert to other formats." msgstr "" -":term: `Wheel` é internamente organizado pelo `tipo de caminho sysconfig " +":term:`Wheel` é internamente organizado pelo `tipo de caminho sysconfig " "`_, " "portanto tornando mais fácil converter para outros formatos." @@ -6221,7 +6221,7 @@ msgstr "" "camada de interpretador do CPython) e os recursos opcionais de tipagem " "estática do Cython podem oferecer oportunidades adicionais para aumentos de " "velocidade. Usar o Cython ainda tem a desvantagem de aumentar a complexidade " -"de distribuição do aplicativo resultante, mas tem o benefício de ter uma " +"de distribuição da aplicação resultante, mas tem o benefício de ter uma " "barreira de entrada reduzida para programadores Python (em relação a outras " "linguagens como C ou C++)." @@ -6255,7 +6255,7 @@ msgid "" "tedious, so a number of other alternative approaches should be considered." msgstr "" "A ABI C (Interface Binária de Aplicação) é um padrão comum para " -"compartilhamento de funcionalidade entre vários aplicativos. Um dos pontos " +"compartilhamento de funcionalidade entre várias aplicações. Um dos pontos " "fortes da API C do CPython (Interface de Programação de Aplicação) é " "permitir que os usuários do Python aproveitem essa funcionalidade. No " "entanto, empacotar módulos manualmente é muito tedioso, portanto, várias " @@ -9401,13 +9401,12 @@ msgid "" "section on :ref:`Creating and using Virtual Environments`." msgstr "" "virtualenv é uma ferramenta que usa a variável de ambiente de caminho de " -"linha de comando para criar :term: `Ambientes Virtuais ` do Python, assim como :ref:`venv` faz. virtualenv fornece " -"funcionalidade adicional, em comparação com :ref:`venv`, oferecendo suporte " -"ao Python 2.7 e fornecendo recursos convenientes para configurar, manter, " -"duplicar e solucionar problemas de ambientes virtuais. Para obter mais " -"informações, consulte a seção sobre :ref:`Creating and using Virtual " -"Environments`." +"linha de comando para criar :term:`Ambientes Virtuais ` " +"do Python, assim como :ref:`venv` faz. virtualenv fornece funcionalidade " +"adicional, em comparação com :ref:`venv`, oferecendo suporte ao Python 2.7 e " +"fornecendo recursos convenientes para configurar, manter, duplicar e " +"solucionar problemas de ambientes virtuais. Para obter mais informações, " +"consulte a seção sobre :ref:`Creating and using Virtual Environments`." #: ../source/key_projects.rst:290 msgid "Warehouse" @@ -9522,7 +9521,7 @@ msgid "" "software later." msgstr "" "Buildout é um sistema de construção baseado em Python para criar, montar e " -"distribuir aplicativos de várias partes, algumas das quais podem ser não " +"distribuir aplicações de várias partes, algumas das quais podem ser não " "baseadas em Python. Ele permite que você crie uma configuração de buildout e " "reproduza o mesmo software posteriormente." @@ -9889,7 +9888,7 @@ msgid "" "publicly. Organizations who use pypiserver usually download packages both " "from pypiserver and from PyPI." msgstr "" -"pypiserver é um aplicativo minimalista que serve como um índice de pacotes " +"pypiserver é uma aplicação minimalista que serve como um índice de pacotes " "privado Python dentro das organizações, implementando uma API simples e uma " "interface de navegador. Você pode enviar pacotes privados usando ferramentas " "de envio padrão, e os usuários podem baixar e instalá-los com :ref:`pip`, " @@ -9983,7 +9982,7 @@ msgstr "" "permitir fácil troca de compiladores, versões de bibliotecas, opções de " "construção, etc. Arbitrariamente, muitas versões de pacotes podem coexistir " "no mesmo sistema. O Spack foi projetado para construir rapidamente " -"aplicativos científicos de alto desempenho em clusters e supercomputadores." +"aplicações científicas de alto desempenho em clusters e supercomputadores." #: ../source/key_projects.rst:611 msgid "" @@ -13940,7 +13939,7 @@ msgstr "" "configurações em ``pyproject.toml``, eles podem usar a tabela ``[tool]`` " "conforme definido na :ref:`especificação da declaração de dependências de " "construção `. A falta de uma tabela " -"``[project]`` implicitamente significa que o baccend da construção fornecerá " +"``[project]`` implicitamente significa que o backend da construção fornecerá " "dinamicamente todos os campos." #: ../source/specifications/declaring-project-metadata.rst:27 @@ -14489,7 +14488,7 @@ msgid "" "should not be possible for a required field to not be listed somehow in the " "``[project]`` table)." msgstr "" -"Se a especificação de :ref: `metadados principais ` lista um " +"Se a especificação de :ref:`metadados principais ` lista um " "campo como \"Required\", então os metadados DEVEM especificar o campo " "estaticamente ou listá-lo em ``dynamic`` (backends de construção DEVEM gerar " "um erro, caso contrário , ou seja, não deve ser possível que um campo " @@ -14759,7 +14758,7 @@ msgstr "" "Quando a URL solicitada tem o esquema file:// e aponta para um diretório " "local que contém um checkout VCS, os instaladores NÃO DEVEM tentar inferir " "nenhuma informação VCS e, portanto, NÃO DEVEM emitir nenhuma informação " -"relacionada ao VCS (como ``vcs_info``) in :file:` direct_url.json`." +"relacionada ao VCS (como ``vcs_info``) in :file:`direct_url.json`." #: ../source/specifications/direct-url.rst:96 msgid "" @@ -15157,6 +15156,10 @@ msgid "" "parts delimited by dots and the colon is a valid Python identifier. It is " "intended to be looked up like this::" msgstr "" +"A **referência de objeto** aponta para um objeto Python. Ele está no formato " +"``importable.module`` ou ``importable.module:object.attr``. Cada uma das " +"partes delimitadas por pontos e dois pontos é um identificador válido " +"Python. Destina-se a ser consultado assim::" #: ../source/specifications/entry-points.rst:64 msgid "" @@ -15164,6 +15167,9 @@ msgid "" "for want of a better term, especially where it points to a function to " "launch a program." msgstr "" +"Algumas ferramentas chamam esse tipo de referência de objeto por si só de " +"\"ponto de entrada\", por falta de um termo melhor, especialmente quando " +"aponta para uma função para iniciar um programa." #: ../source/specifications/entry-points.rst:68 msgid "" @@ -15172,6 +15178,10 @@ msgid "" "If these are specified, the entry point requires the dependencies of those " "'extras'. See the metadata field :ref:`metadata_provides_extra`." msgstr "" +"Há também uma propriedade opcional: os **extras** são um conjunto de strings " +"que identifica recursos opcionais da distribuição que fornece o ponto de " +"entrada. Se forem especificados, o ponto de entrada requer as dependências " +"desses 'extras'. Veja o campo de metadados :ref:`metadata_provides_extra`." #: ../source/specifications/entry-points.rst:73 msgid "" @@ -15181,10 +15191,17 @@ msgid "" "of handling extras was tied to setuptools' model of managing 'egg' packages, " "but newer tools such as pip and virtualenv use a different model." msgstr "" +"Usar extras para um ponto de entrada não é mais recomendado. Os consumidores " +"devem oferecer suporte para analisá-los em distribuições existentes, mas " +"podem então ignorá-los. Novas ferramentas de publicação não precisam " +"suportar especificações extras. A funcionalidade de manipulação de extras " +"estava ligada ao modelo do setuptools de gerenciamento de pacotes \"egg\", " +"mas as ferramentas mais recentes, como pip e virtualenv, usam um modelo " +"diferente." #: ../source/specifications/entry-points.rst:80 msgid "File format" -msgstr "" +msgstr "Formato de arquivo" #: ../source/specifications/entry-points.rst:82 msgid "" @@ -15193,6 +15210,10 @@ msgid "" "described in :pep:`376` for installed distributions, and in :pep:`427` for " "wheels. The file uses the UTF-8 character encoding." msgstr "" +"Os pontos de entrada são definidos em um arquivo chamado :file:`entry_points." +"txt` no diretório :file:`*.dist-info` da distribuição. Este é o diretório " +"descrito em :pep:`376` para distribuições instaladas e em :pep:`427` para " +"wheels. O arquivo usa a codificação de caracteres UTF-8." #: ../source/specifications/entry-points.rst:87 msgid "" @@ -15201,12 +15222,20 @@ msgid "" "whereas entry point names are case sensitive. A case-sensitive config parser " "can be made like this::" msgstr "" +"O conteúdo do arquivo está no formato INI, conforme lido pelo módulo " +":mod:`configparser` do Python. No entanto, o configparser trata os nomes " +"como não diferenciando maiúsculas de minúsculas por padrão, enquanto os " +"nomes de pontos de entrada diferenciam maiúsculas de minúsculas. Um " +"analisador de configuração com distinção entre maiúsculas e minúsculas pode " +"ser feito assim::" #: ../source/specifications/entry-points.rst:97 msgid "" "The entry points file must always use ``=`` to delimit names from values " "(whereas configparser also allows using ``:``)." msgstr "" +"O arquivo de pontos de entrada deve sempre usar ``=`` para delimitar nomes " +"de valores (enquanto o configparser também permite o uso de ``:``)." #: ../source/specifications/entry-points.rst:100 msgid "" @@ -15215,6 +15244,10 @@ msgid "" "extras. If extras are used, they are a comma-separated list inside square " "brackets." msgstr "" +"As seções do arquivo de configuração representam grupos de pontos de " +"entrada, os nomes são nomes e os valores codificam a referência do objeto e " +"os extras opcionais. Se extras forem usados, eles serão uma lista separada " +"por vírgulas entre colchetes." #: ../source/specifications/entry-points.rst:104 msgid "" @@ -15226,14 +15259,22 @@ msgid "" "tools writing the file, it is recommended only to insert a space between the " "object reference and the left square bracket." msgstr "" +"Dentro de um valor, os leitores devem aceitar e ignorar os espaços (" +"incluindo vários espaços consecutivos) antes ou depois dos dois pontos, " +"entre a referência do objeto e o colchete esquerdo, entre os nomes extras e " +"os colchetes e dois pontos que os delimitam, e depois do quadrado direito " +"suporte. A sintaxe para extras é formalmente especificada como parte de " +":pep:`508` (como ``extras``). Para ferramentas de gravação de arquivo, é " +"recomendável inserir apenas um espaço entre a referência do objeto e o " +"colchete esquerdo." #: ../source/specifications/entry-points.rst:112 msgid "For example::" -msgstr "" +msgstr "Por exemplo::" #: ../source/specifications/entry-points.rst:124 msgid "Use for scripts" -msgstr "" +msgstr "Uso para scripts" #: ../source/specifications/entry-points.rst:126 msgid "" @@ -15245,12 +15286,21 @@ msgid "" "return an integer to be used as a process exit code, and returning ``None`` " "is equivalent to returning ``0``." msgstr "" +"Dois grupos de pontos de entrada têm um significado especial no " +"empacotamento: ``console_scripts`` e ``gui_scripts``. Em ambos os grupos, o " +"nome do ponto de entrada deve ser usado como um comando em um shell do " +"sistema após a instalação do pacote. A referência do objeto aponta para uma " +"função que será chamada sem argumentos quando este comando for executado. A " +"função pode retornar um inteiro para ser usado como um código de saída do " +"processo, e retornar ``None`` é equivalente a retornar ``0``." #: ../source/specifications/entry-points.rst:134 msgid "" "For instance, the entry point ``mycmd = mymod:main`` would create a command " "``mycmd`` launching a script like this::" msgstr "" +"Por exemplo, o ponto de entrada ``mycmd = mymod:main`` criaria um comando " +"``mycmd`` lançando um script como este::" #: ../source/specifications/entry-points.rst:141 msgid "" @@ -15262,6 +15312,13 @@ msgid "" "standard streams unless application code redirects them. Other platforms do " "not have the same distinction." msgstr "" +"A diferença entre ``console_scripts`` e ``gui_scripts`` afeta apenas os " +"sistemas Windows. ``console_scripts`` são empacotados em um executável de " +"console, então eles são anexados a um console e podem usar ``sys.stdin``, " +"``sys.stdout`` e ``sys.stderr`` para entrada e saída. ``gui_scripts`` são " +"empacotados em um executável GUI, então eles podem ser iniciados sem um " +"console, mas não podem usar streams padrão a menos que o código da aplicação " +"os redirecione. Outras plataformas não têm a mesma distinção." #: ../source/specifications/entry-points.rst:149 msgid "" @@ -15270,6 +15327,11 @@ msgid "" "not responsible for putting this directory in the ``PATH`` environment " "variable which defines where command-line tools are found." msgstr "" +"Espera-se que as ferramentas de instalação configurem wrappers para " +"``console_scripts`` e ``gui_scripts`` no diretório de scripts do esquema de " +"instalação. Eles não são responsáveis por colocar este diretório na variável " +"de ambiente ``PATH`` que define onde as ferramentas de linha de comando são " +"encontradas." #: ../source/specifications/entry-points.rst:154 msgid "" @@ -15278,6 +15340,11 @@ msgid "" "only in case. The behaviour of install tools when names differ only in case " "is undefined." msgstr "" +"Como os arquivos são criados a partir dos nomes e alguns sistemas de " +"arquivos não fazem distinção entre maiúsculas e minúsculas, os pacotes devem " +"evitar o uso de nomes nesses grupos que diferem apenas em maiúsculas e " +"minúsculas. O comportamento das ferramentas de instalação quando os nomes " +"diferem apenas no caso de ser indefinido." #: ../source/specifications/index.rst:4 msgid "PyPA specifications" @@ -15309,7 +15376,7 @@ msgstr "Interfaces de índices de pacotes" #: ../source/specifications/platform-compatibility-tags.rst:6 msgid "Platform compatibility tags" -msgstr "" +msgstr "Tags de compatibilidade de plataforma" #: ../source/specifications/platform-compatibility-tags.rst:8 msgid "" @@ -15317,36 +15384,47 @@ msgid "" "compatible with specific platforms, and allows installers to understand " "which distributions are compatible with the system they are running on." msgstr "" +"As tags de compatibilidade de plataforma permitem que ferramentas de " +"construção marquem as distribuições como sendo compatíveis com plataformas " +"específicas e permitem que os instaladores entendam quais distribuições são " +"compatíveis com o sistema em que estão executando." #: ../source/specifications/platform-compatibility-tags.rst:12 msgid "" "The platform compatibility tagging model used for the ``wheel`` distribution " "format is defined in :pep:`425`." msgstr "" +"O modelo de tag de compatibilidade de plataforma usado para o formato de " +"distribuição ``wheel`` é definido em :pep:`425`." #: ../source/specifications/platform-compatibility-tags.rst:16 msgid "Platform tags for Windows" -msgstr "" +msgstr "Tags de plataforma para Windows" #: ../source/specifications/platform-compatibility-tags.rst:18 msgid "" "The scheme defined in :pep:`425` covers public distribution of wheel files " "to systems running Windows." msgstr "" +"O esquema definido em :pep:`425` cobre a distribuição pública de arquivos " +"wheel para sistemas executando Windows." #: ../source/specifications/platform-compatibility-tags.rst:22 msgid "Platform tags for macOS (Mac OS X)" -msgstr "" +msgstr "Tags de plataforma para macOS (Mac OS X)" #: ../source/specifications/platform-compatibility-tags.rst:24 msgid "" "The scheme defined in :pep:`425` covers public distribution of wheel files " "to systems running macOS (previously known as Mac OS X)." msgstr "" +"O esquema definido em :pep:`425` cobre a distribuição pública de arquivos " +"wheel para sistemas que executam macOS (anteriormente conhecido como Mac OS " +"X)." #: ../source/specifications/platform-compatibility-tags.rst:28 msgid "Platform tags for common Linux distributions" -msgstr "" +msgstr "Tags de plataforma para distribuições Linux comuns" #: ../source/specifications/platform-compatibility-tags.rst:32 msgid "" @@ -15354,6 +15432,10 @@ msgid "" "wheel files (and \\*nix wheel files in general) to Linux platforms, due to " "the large ecosystem of Linux platforms and subtle differences between them." msgstr "" +"O esquema definido em :pep:`425` é insuficiente para distribuição pública de " +"arquivos wheel (e arquivos wheel do \\*nix em geral) para plataformas Linux, " +"devido ao grande ecossistema de plataformas Linux e diferenças sutis entre " +"elas." #: ../source/specifications/platform-compatibility-tags.rst:36 msgid "" @@ -15362,18 +15444,27 @@ msgid "" "``manylinux`` platform tag which can be used across most common Linux " "distributions." msgstr "" +"Em vez disso, a :pep:`600` define o padrão ``manylinux``, que representa um " +"subconjunto comum de plataformas Linux, e permite a construção de wheels com " +"a tag de plataforma ``manylinux`` que pode ser usada na maioria das " +"distribuições Linux." #: ../source/specifications/platform-compatibility-tags.rst:41 msgid "" "There were multiple iterations of the ``manylinux`` specification, each " "representing the common subset of Linux platforms at a given point in time:" msgstr "" +"Houve várias iterações da especificação ``manylinux``, cada uma " +"representando o subconjunto comum de plataformas Linux em um determinado " +"ponto no tempo:" #: ../source/specifications/platform-compatibility-tags.rst:44 msgid "" "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, " "and is based on a compatible Linux platform from 2007." msgstr "" +"``manylinux1`` (:pep:`513`) oferece suporte às arquiteturas ``x86_64`` e " +"``i686`` e é baseado em uma plataforma Linux compatível de 2007." #: ../source/specifications/platform-compatibility-tags.rst:46 msgid "" @@ -15381,6 +15472,9 @@ msgid "" "architectures. and updates the previous specification to be based on a " "compatible Linux platform from 2010 instead." msgstr "" +"``manylinux2010`` (:pep:`571`) oferece suporte às arquiteturas ``x86_64`` e " +"``i686`` e atualiza a especificação anterior para se basear em uma " +"plataforma Linux compatível a partir de 2010." #: ../source/specifications/platform-compatibility-tags.rst:49 msgid "" @@ -15389,6 +15483,9 @@ msgid "" "``s390x``) and updates the base platform to a compatible Linux platform from " "2014." msgstr "" +"``manylinux2014`` (:pep:`599`) adiciona suporte para várias arquiteturas " +"adicionais (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le`` e ``s390x``) e " +"atualiza a plataforma base para uma plataforma Linux compatível de 2014." #: ../source/specifications/platform-compatibility-tags.rst:54 msgid "" @@ -15397,6 +15494,12 @@ msgid "" "versions supported (e.g. ``manylinux_2_24`` should work on any distro using " "glibc 2.24+). Previous tags are still supported for backward compatibility." msgstr "" +"``manylinux_x_y`` (:pep:`600`) substitui todas as PEPs anteriores para " +"definir um padrão à prova de futuro. Ele define ``x`` e ``y`` como as " +"versões principais e secundárias do glibc suportadas (por exemplo, " +"``manylinux_2_24`` deve funcionar em qualquer distro usando glibc 2.24+). " +"Tags anteriores ainda são suportadas para compatibilidade com versões " +"anteriores." #: ../source/specifications/platform-compatibility-tags.rst:59 msgid "" @@ -15406,6 +15509,12 @@ msgid "" "that ``manylinux2010`` distributions are not expected to work on platforms " "that existed before 2010)." msgstr "" +"Em geral, as distribuições construídas para versões mais antigas da " +"especificação são compatíveis com versões futuras (o que significa que as " +"distribuições ``manylinux1`` devem continuar a funcionar em sistemas " +"modernos), mas não compatíveis com versões anteriores (significando que " +"distribuições ``manylinux2010`` não devem trabalhar em plataformas que " +"existiam antes de 2010)." #: ../source/specifications/platform-compatibility-tags.rst:65 msgid "" @@ -15414,88 +15523,98 @@ msgid "" "for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning " "that these images will no longer receive security updates." msgstr "" +"Os mantenedores do pacote devem tentar atingir a especificação mais " +"compatível possível, com a ressalva de que o ambiente de compilação " +"fornecido para ``manylinux1`` e ``manylinux2010`` atingiu o fim da vida, o " +"que significa que essas imagens não receberão mais atualizações de segurança." #: ../source/specifications/platform-compatibility-tags.rst:71 msgid "Manylinux compatibility support" -msgstr "" +msgstr "Suporte a compatibilidade de manylinux" #: ../source/specifications/platform-compatibility-tags.rst:74 msgid "" "The ``manylinux2014`` specification is relatively new and is not yet widely " "recognised by install tools." msgstr "" +"A especificação de ``manylinux2014`` é relativamente nova e ainda não é " +"amplamente reconhecida pelas ferramentas de instalação." #: ../source/specifications/platform-compatibility-tags.rst:76 msgid "" "The ``manylinux_x_y`` specification is relatively new and is not yet widely " "recognised by install tools." msgstr "" +"A especificação de ``manylinux_x_y`` é relativamente nova e não é amplamente " +"reconhecida pelas ferramentas de instalação." #: ../source/specifications/platform-compatibility-tags.rst:79 msgid "" "The following table shows the minimum versions of relevant projects to " "support the various ``manylinux`` standards:" msgstr "" +"A tabela a seguir mostra as versões mínimas de projetos relevantes para " +"oferecer suporte aos vários padrões ``manylinux``:" #: ../source/specifications/platform-compatibility-tags.rst:83 msgid "Tool" -msgstr "" +msgstr "Ferramenta" #: ../source/specifications/platform-compatibility-tags.rst:83 msgid "``manylinux1``" -msgstr "" +msgstr "``manylinux1``" #: ../source/specifications/platform-compatibility-tags.rst:83 msgid "``manylinux2010``" -msgstr "" +msgstr "``manylinux2010``" #: ../source/specifications/platform-compatibility-tags.rst:83 msgid "``manylinux2014``" -msgstr "" +msgstr "``manylinux2014``" #: ../source/specifications/platform-compatibility-tags.rst:83 msgid "``manylinux_x_y``" -msgstr "" +msgstr "``manylinux_x_y``" #: ../source/specifications/platform-compatibility-tags.rst:85 msgid "``>=8.1.0``" -msgstr "" +msgstr "``>=8.1.0``" #: ../source/specifications/platform-compatibility-tags.rst:85 msgid "``>=19.0``" -msgstr "" +msgstr "``>=19.0``" #: ../source/specifications/platform-compatibility-tags.rst:85 msgid "``>=19.3``" -msgstr "" +msgstr "``>=19.3``" #: ../source/specifications/platform-compatibility-tags.rst:85 msgid "``>=20.3``" -msgstr "" +msgstr "``>=20.3``" #: ../source/specifications/platform-compatibility-tags.rst:86 msgid "auditwheel" -msgstr "" +msgstr "auditwheel" #: ../source/specifications/platform-compatibility-tags.rst:86 msgid "``>=1.0.0``" -msgstr "" +msgstr "``>=1.0.0``" #: ../source/specifications/platform-compatibility-tags.rst:86 msgid "``>=2.0.0``" -msgstr "" +msgstr "``>=2.0.0``" #: ../source/specifications/platform-compatibility-tags.rst:86 msgid "``>=3.0.0``" -msgstr "" +msgstr "``>=3.0.0``" #: ../source/specifications/platform-compatibility-tags.rst:86 msgid "``>=3.3.0`` [#]_" -msgstr "" +msgstr "``>=3.3.0`` [#]_" #: ../source/specifications/platform-compatibility-tags.rst:90 msgid "Platform tags for other \\*nix platforms" -msgstr "" +msgstr "Tags de plataforma para outras plataformas \\*nix" #: ../source/specifications/platform-compatibility-tags.rst:92 msgid "" @@ -15504,14 +15623,20 @@ msgid "" "(albeit intermittently) under way to define improved compatibility tagging " "schemes for AIX and for Alpine Linux." msgstr "" +"O esquema definido na :pep:`425` geralmente não é suficiente para a " +"distribuição pública de arquivos wheel para outras plataformas \\*nix. " +"Esforços estão atualmente (embora de forma intermitente) em andamento para " +"definir esquemas de marcação de compatibilidade aprimorados para AIX e " +"Alpine Linux." #: ../source/specifications/platform-compatibility-tags.rst:98 msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" msgstr "" +"Suporte somente para ``manylinux_2_24`` foi adicionado em auditwheel 3.3.0" #: ../source/specifications/pypirc.rst:6 msgid "The :file:`.pypirc` file" -msgstr "" +msgstr "O arquivo :file:`.pypirc`" #: ../source/specifications/pypirc.rst:8 msgid "" @@ -15520,32 +15645,38 @@ msgid "" "that you don't have to enter the URL, username, or password whenever you " "upload a package with :ref:`twine` or :ref:`flit`." msgstr "" +"Um arquivo :file:`.pypirc` permite que você defina a configuração para " +":term:`índices de pacotes <Índice de Pacotes>` (referido aqui como " +"\"repositórios\"), para que você não precise inserir a URL, nome de usuário " +"ou senha sempre que você enviar um pacote com :ref:`twine` ou :ref:`flit`." #: ../source/specifications/pypirc.rst:13 msgid "The format (originally defined by the :ref:`distutils` package) is:" -msgstr "" +msgstr "O formato (originalmente definido pelo pacote :ref:`distutils`) é:" #: ../source/specifications/pypirc.rst:32 msgid "" "The ``distutils`` section defines an ``index-servers`` field that lists the " "name of all sections describing a repository." msgstr "" +"A seção ``distutils`` define um campo ``index-servers`` que lista o nome de " +"todas as seções descrevendo um repositório." #: ../source/specifications/pypirc.rst:35 msgid "Each section describing a repository defines three fields:" -msgstr "" +msgstr "Cada seção descrevendo um repositório define três campos:" #: ../source/specifications/pypirc.rst:37 msgid "``repository``: The URL of the repository." -msgstr "" +msgstr "``repository``: A URL do repositório." #: ../source/specifications/pypirc.rst:38 msgid "``username``: The registered username on the repository." -msgstr "" +msgstr "``username``: O nome de usuário registrado no repositório." #: ../source/specifications/pypirc.rst:39 msgid "``password``: The password that will used to authenticate the username." -msgstr "" +msgstr "``password``: A senha que será usada para autenticar o nome de usuário." #: ../source/specifications/pypirc.rst:43 msgid "" @@ -15553,16 +15684,21 @@ msgid "" "consider an alternative like `keyring`_, setting environment variables, or " "providing the password on the command line." msgstr "" +"Esteja ciente de que isso armazena sua senha em texto simples. Para melhor " +"segurança, considere uma alternativa como `chaveiro `_, " +"configurando variáveis de ambiente ou fornecendo a senha na linha de comando." #: ../source/specifications/pypirc.rst:47 msgid "" "Otherwise, set the permissions on :file:`.pypirc` so that only you can view " "or modify it. For example, on Linux or macOS, run:" msgstr "" +"Caso contrário, defina as permissões em :file:`.pypirc` para que somente " +"você possa ver ou modificá-lo. Por exemplo, no Linux ou macOS, execute:" #: ../source/specifications/pypirc.rst:57 msgid "Common configurations" -msgstr "" +msgstr "Configurações comuns" #: ../source/specifications/pypirc.rst:61 msgid "" @@ -15571,38 +15707,50 @@ msgid "" "pypirc`, but with different defaults. Please refer to each project's " "documentation for more details and usage instructions." msgstr "" +"Esses exemplos se aplicam a :ref:`twine` e projetos como :ref:`hatch` que o " +"usam sob o capô. Outros projetos (por exemplo, :ref:`flit`) também usam " +":file:`.pypirc`, mas com padrões diferentes. Consulte a documentação de cada " +"projeto para obter mais detalhes e instruções de uso." #: ../source/specifications/pypirc.rst:66 msgid "" "Twine's default configuration mimics a :file:`.pypirc` with repository " "sections for PyPI and TestPyPI:" msgstr "" +"A configuração padrão do Twine imita um :file:`.pypirc` com seções de " +"repositório para PyPI e TestPyPI:" #: ../source/specifications/pypirc.rst:82 msgid "" "Twine will add additional configuration from :file:`$HOME/.pypirc`, the " "command line, and environment variables to this default configuration." msgstr "" +"Twine irá adicionar configuração adicional de :file:`$HOME/.pypirc`, a linha " +"de comando e variáveis de ambiente a esta configuração padrão." #: ../source/specifications/pypirc.rst:86 msgid "Using a PyPI token" -msgstr "" +msgstr "Usando um token do PyPI" #: ../source/specifications/pypirc.rst:88 msgid "" "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` " "similar to:" msgstr "" +"Para definir seu `token de API `_ para PyPI, você pode criar um " +":file:`$HOME/.pypirc` semelhante a:" #: ../source/specifications/pypirc.rst:97 msgid "" "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using " "the API token from your TestPyPI account." msgstr "" +"Para o :ref:`TestPyPI `, adicione a seção ``[testpypi]``, " +"usando o token de API de sua conta do TestPyPI." #: ../source/specifications/pypirc.rst:103 msgid "Using another package index" -msgstr "" +msgstr "Usando outro índice de pacotes" #: ../source/specifications/pypirc.rst:105 msgid "" @@ -15610,16 +15758,23 @@ msgid "" "servers`` field to include the repository name. Here is a complete example " "of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" msgstr "" +"Para configurar um repositório adicional, você precisará redefinir o campo " +"``index-servers`` para incluir o nome do repositório. Aqui está um exemplo " +"completo de um :file:`$HOME/.pypirc` para PyPI, TestPyPI e um repositório " +"privado:" #: ../source/specifications/pypirc.rst:132 msgid "" "Instead of using the ``password`` field, consider saving your API tokens and " "passwords securely using `keyring`_ (which is installed by Twine):" msgstr "" +"Em vez de usar o campo ``password``, considere salvar seus tokens de API e " +"senhas com segurança usando um `chaveiro `_ (que é instalado pelo " +"Twine):" #: ../source/specifications/recording-installed-packages.rst:5 msgid "Recording installed projects" -msgstr "" +msgstr "Gravando projetos instalados" #: ../source/specifications/recording-installed-packages.rst:7 msgid "" @@ -15628,6 +15783,10 @@ msgid "" "metadata format allows tools to query, manage or uninstall projects, " "regardless of how they were installed." msgstr "" +"Este documento especifica um formato comum de gravação de informações sobre " +":term:`projetos ` Python instalados em um ambiente. Um formato de " +"metadados comum permite que as ferramentas consultem, gerenciem ou " +"desinstalem projetos, independentemente de como foram instalados." #: ../source/specifications/recording-installed-packages.rst:12 msgid "" @@ -15637,10 +15796,16 @@ msgid "" "a list of installed files in a format specific to Python tooling, it should " "still record the name and version of the installed project." msgstr "" +"Quase todas as informações são opcionais. Isso permite que ferramentas fora " +"do ecossistema Python, como gerenciadores de pacotes Linux, se integrem com " +"as ferramentas Python tanto quanto possível. Por exemplo, mesmo se um " +"instalador não puder fornecer facilmente uma lista de arquivos instalados em " +"um formato específico para as ferramentas Python, ele ainda deve registrar o " +"nome e a versão do projeto instalado." #: ../source/specifications/recording-installed-packages.rst:21 msgid "History and change workflow" -msgstr "" +msgstr "Histórico e fluxo de trabalho de mudança" #: ../source/specifications/recording-installed-packages.rst:23 msgid "" @@ -15649,6 +15814,11 @@ msgid "" "Python Distributions*. Further amendments (except trivial language or " "typography fixes) must be made through the PEP process (see :pep:`1`)." msgstr "" +"Os metadados descritos aqui foram especificados primeiro na :pep:`376`, e " +"posteriormente alterados na :pep:`627`. Era conhecido anteriormente como *" +"Banco de dados de distribuições Python instaladas*. Outras alterações (" +"exceto correções triviais de linguagem ou tipografia) devem ser feitas " +"através do processo de PEP (veja :pep:`1`)." #: ../source/specifications/recording-installed-packages.rst:29 msgid "" @@ -15656,6 +15826,9 @@ msgid "" "introduce changes to it may include additional information such as " "rationales and backwards compatibility considerations." msgstr "" +"Embora este documento seja a especificação normativa, essas PEPs que " +"introduzem alterações nele podem incluir informações adicionais, como " +"justificativas e considerações de compatibilidade com versões anteriores." #: ../source/specifications/recording-installed-packages.rst:37 msgid "" @@ -15663,6 +15836,9 @@ msgid "" "install a \"``.dist-info``\" directory located alongside importable modules " "and packages (commonly, the ``site-packages`` directory)." msgstr "" +"Cada projeto instalado de uma distribuição deve, além dos arquivos, instalar " +"um diretório \"``.dist-info``\" localizado junto com os módulos e pacotes " +"importáveis (comumente, o diretório ``site-packages``)." #: ../source/specifications/recording-installed-packages.rst:41 msgid "" @@ -15674,6 +15850,14 @@ msgid "" "chacaters, so the ``.dist-info`` directory always has exactly one dash (``-" "``) character in its stem, separating the ``name`` and ``version`` fields." msgstr "" +"Este diretório é nomeado como ``{name}-{version}.dist-info``, com os campos " +"``name`` e ``version`` correspondendo a :ref:`core-metadata`. Ambos os " +"campos devem ser normalizados (consulte a :pep:`PEP 503 <503#normalized-" +"names>` e a :pep:`PEP 440 <440#normalization>` para a definição de " +"normalização para cada campo respectivamente) e substitua os caracteres de " +"traço (``-``) por caracteres de sublinhado (``_``), então o diretório " +"``.dist-info`` sempre tem exatamente um caractere de traço (``-``) em seu " +"radical, separando os campos ``name`` e ``version``." #: ../source/specifications/recording-installed-packages.rst:50 msgid "" @@ -15685,6 +15869,14 @@ msgid "" "both ``name`` and ``version`` fields using the rules described above, and " "existing tools are encouraged to start normalizing those fields." msgstr "" +"Historicamente, as ferramentas falharam em substituir caracteres de ponto ou " +"normalizar maiúsculas e minúsculas no campo ``name``, ou não realizar a " +"normalização no campo ``version``. Ferramentas que consomem diretórios " +"``.dist-info`` devem esperar que esses campos sejam desnormalizados e tratá-" +"los como equivalentes a suas contrapartes normalizadas. Novas ferramentas " +"que escrevem diretórios ``.dist-info`` DEVEM normalizar ambos os campos " +"``name`` e ``version`` usando as regras descritas acima, e as ferramentas " +"existentes são encorajadas a começar a normalizar esses campos." #: ../source/specifications/recording-installed-packages.rst:60 msgid "" @@ -15697,25 +15889,38 @@ msgid "" "API for such tools to consume, so tools can have access to the unnormalized " "name when displaying distrubution information." msgstr "" +"O nome do diretório ``.dist-info`` é formatado para representar " +"inequivocamente uma distribuição como um caminho do sistema de arquivos. As " +"ferramentas que apresentam um nome de distribuição a um usuário devem evitar " +"o uso do nome normalizado e, em vez disso, apresentar o nome especificado (" +"quando necessário antes da resolução de um pacote instalado) ou ler os " +"respectivos campos nos metadados principais, uma vez que os valores listados " +"não têm escape e são precisos refletem a distribuição. As bibliotecas devem " +"fornecer API para o consumo dessas ferramentas, de forma que as ferramentas " +"possam ter acesso ao nome não normalizado ao exibir informações de " +"distribuição." #: ../source/specifications/recording-installed-packages.rst:69 msgid "" "This ``.dist-info`` directory can contain these files, described in detail " "below:" msgstr "" +"Este diretório ``.dist-info`` pode conter esses arquivos, descritos em " +"detalhes abaixo:" #: ../source/specifications/recording-installed-packages.rst:72 msgid "``METADATA``: contains project metadata" -msgstr "" +msgstr "``METADATA``: contém metadados do projeto" #: ../source/specifications/recording-installed-packages.rst:73 msgid "``RECORD``: records the list of installed files." -msgstr "" +msgstr "``RECORD``: registra a lista de arquivos instalados." #: ../source/specifications/recording-installed-packages.rst:74 msgid "" "``INSTALLER``: records the name of the tool used to install the project." msgstr "" +"``INSTALLER``: registra o nome da ferramenta usada para instalar o projeto." #: ../source/specifications/recording-installed-packages.rst:76 msgid "" @@ -15723,6 +15928,9 @@ msgid "" "installing tool's discretion. Additional installer-specific files may be " "present." msgstr "" +"O arquivo ``METADATA`` é obrigatório. Todos os outros arquivos podem ser " +"omitidos a critério da ferramenta de instalação. Arquivos adicionais " +"específicos do instalador podem estar presentes." #: ../source/specifications/recording-installed-packages.rst:82 msgid "" @@ -15731,6 +15939,10 @@ msgid "" "Such files may be copied to the ``.dist-info`` directory of an installed " "project." msgstr "" +"A especificação :ref:`binary-distribution-format` descreve arquivos " +"adicionais que podem aparecer no diretório ``.dist-info`` de um :term:`Wheel`" +". Esses arquivos podem ser copiados para o diretório ``.dist-info`` de um " +"projeto instalado." #: ../source/specifications/recording-installed-packages.rst:87 msgid "" @@ -15739,16 +15951,23 @@ msgid "" "standardized again in the future. See `PEP 376 `_ for its original meaning." msgstr "" +"As versões anteriores desta especificação também especificavam um arquivo " +"``REQUESTED``. Este arquivo agora é considerado uma extensão específica da " +"ferramenta, mas pode ser padronizado novamente no futuro. Consulte `PEP 376 " +"`_ para seu significado " +"original." #: ../source/specifications/recording-installed-packages.rst:94 msgid "The METADATA file" -msgstr "" +msgstr "O arquivo METADATA" #: ../source/specifications/recording-installed-packages.rst:96 msgid "" "The ``METADATA`` file contains metadata as described in the :ref:`core-" "metadata` specification, version 1.1 or greater." msgstr "" +"O arquivo ``METADATA`` contém metadados conforme descrito na especificação " +":ref:`core-metadata`, versão 1.1 ou superior." #: ../source/specifications/recording-installed-packages.rst:99 msgid "" @@ -15756,40 +15975,52 @@ msgid "" "core metadata is not available, installers must report an error and fail to " "install the project." msgstr "" +"O arquivo ``METADATA`` é obrigatório. Se não puder ser criado ou se os " +"metadados principais necessários não estiverem disponíveis, os instaladores " +"devem relatar um erro e falhar ao instalar o projeto." #: ../source/specifications/recording-installed-packages.rst:105 msgid "The RECORD file" -msgstr "" +msgstr "O arquivo RECORD" #: ../source/specifications/recording-installed-packages.rst:107 msgid "" "The ``RECORD`` file holds the list of installed files. It is a CSV file " "containing one record (line) per installed file." msgstr "" +"O arquivo ``RECORD`` contém a lista de arquivos instalados. É um arquivo CSV " +"contendo um registro (linha) por arquivo instalado." #: ../source/specifications/recording-installed-packages.rst:110 msgid "" "The CSV dialect must be readable with the default ``reader`` of Python's " "``csv`` module:" msgstr "" +"O dialeto CSV deve ser legível com o ``reader`` padrão do módulo ``csv`` do " +"Python:" #: ../source/specifications/recording-installed-packages.rst:113 msgid "field delimiter: ``,`` (comma)," -msgstr "" +msgstr "delimitador de campo: ``,`` (vírgula)," #: ../source/specifications/recording-installed-packages.rst:114 msgid "quoting char: ``\"`` (straight double quote)," -msgstr "" +msgstr "caractere de aspas: ``\"`` (aspas duplas)," #: ../source/specifications/recording-installed-packages.rst:115 msgid "line terminator: either ``\\r\\n`` or ``\\n``." msgstr "" +"terminador de linha: ``\\r\\n" +"`` ou ``\\n" +"``." #: ../source/specifications/recording-installed-packages.rst:117 msgid "" "Each record is composed of three elements: the file's **path**, the **hash** " "of the contents, and its **size**." msgstr "" +"Cada registro é composto de três elementos: o **caminho** do arquivo, o " +"**hash** do conteúdo e seu **tamanho**." #: ../source/specifications/recording-installed-packages.rst:120 msgid "" @@ -15798,6 +16029,10 @@ msgid "" "Windows, directories may be separated either by forward- or backslashes (``/" "`` or ``\\``)." msgstr "" +"O *caminho* pode ser absoluto ou relativo ao diretório que contém o " +"diretório ``.dist-info`` (comumente, o diretório ``site-packages``). No " +"Windows, os diretórios podem ser separados por barras ou barras invertidas " +"(``/`` ou ``\\``)." #: ../source/specifications/recording-installed-packages.rst:125 msgid "" @@ -15806,12 +16041,18 @@ msgid "" "and the digest of the file's contents, encoded with the urlsafe-base64-nopad " "encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." msgstr "" +"O *hash* é uma string vazia ou o nome de um algoritmo hash de ``hashlib." +"algorithms_guaranteed``, seguido pelo caractere igual ``=`` e o resumo do " +"conteúdo do arquivo, codificado com a codificação urlsafe-base64-nopad " +"(``base64.urlsafe_b64encode(digest)`` com ``=`` ao final removido)." #: ../source/specifications/recording-installed-packages.rst:130 msgid "" "The *size* is either the empty string, or file's size in bytes, as a base 10 " "integer." msgstr "" +"O *tamanho* é a string vazia ou o tamanho do arquivo em bytes, como um " +"inteiro de base 10." #: ../source/specifications/recording-installed-packages.rst:133 msgid "" @@ -15821,6 +16062,11 @@ msgid "" "is discouraged, as it prevents verifying the integrity of the installed " "project." msgstr "" +"Para qualquer arquivo, um ou ambos os campos de *hash* e *tamanho* podem ser " +"deixados em branco. Normalmente, entradas para arquivos ``.pyc`` e o próprio " +"arquivo ``RECORD`` têm *hash* e *tamanho* vazios. Para os demais arquivos, " +"não é recomendável deixar as informações de fora, pois impede a verificação " +"da integridade do projeto instalado." #: ../source/specifications/recording-installed-packages.rst:139 msgid "" @@ -15830,6 +16076,11 @@ msgid "" "directory (including the ``RECORD`` file itself) must be listed. Directories " "should not be listed." msgstr "" +"Se o arquivo ``RECORD`` estiver presente, ele deve listar todos os arquivos " +"instalados do projeto, exceto os arquivos ``.pyc`` correspondentes aos " +"arquivos ``.py`` listados em ``RECORD``, que são opcionais. Notavelmente, o " +"conteúdo do diretório ``.dist-info`` (incluindo o próprio arquivo ``RECORD``)" +" deve ser listado. Os diretórios não devem ser listados." #: ../source/specifications/recording-installed-packages.rst:146 msgid "" @@ -15837,10 +16088,14 @@ msgid "" "in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding " "to removed ``.py`` files, and any directories emptied by the uninstallation." msgstr "" +"Para desinstalar completamente um pacote, uma ferramenta precisa remover " +"todos os arquivos listados em ``RECORD``, todos os arquivos ``.pyc`` (de " +"todos os níveis de otimização) correspondentes aos arquivos ``.py`` " +"removidos e quaisquer diretórios esvaziados pela desinstalação." #: ../source/specifications/recording-installed-packages.rst:151 msgid "Here is an example snippet of a possible ``RECORD`` file::" -msgstr "" +msgstr "Aqui está um trecho de exemplo de um possível arquivo ``RECORD``::" #: ../source/specifications/recording-installed-packages.rst:170 msgid "" @@ -15849,10 +16104,14 @@ msgid "" "tools that rely on other sources of information, such as system package " "managers in Linux distros.)" msgstr "" +"Se o arquivo ``RECORD`` estiver faltando, as ferramentas que dependem de " +"``.dist-info`` não devem tentar desinstalar ou atualizar o pacote. (Isso não " +"se aplica a ferramentas que dependem de outras fontes de informação, como " +"gerenciadores de pacotes do sistema em distros Linux.)" #: ../source/specifications/recording-installed-packages.rst:177 msgid "The INSTALLER file" -msgstr "" +msgstr "O arquivo INSTALLER" #: ../source/specifications/recording-installed-packages.rst:179 msgid "" @@ -15861,14 +16120,20 @@ msgid "" "``INSTALLER`` should contain the command name. Otherwise, it should contain " "a printable ASCII string." msgstr "" +"Se presente, ``INSTALLER`` é um arquivo de texto de uma linha que nomeia a " +"ferramenta usada para instalar o projeto. Se o instalador for executável a " +"partir da linha de comando, ``INSTALLER`` deve conter o nome do comando. " +"Caso contrário, deve conter uma string ASCII imprimível." #: ../source/specifications/recording-installed-packages.rst:185 msgid "The file can be terminated by zero or more ASCII whitespace characters." msgstr "" +"O arquivo pode ser encerrado com zero ou mais caracteres de espaço em branco " +"ASCII." #: ../source/specifications/recording-installed-packages.rst:187 msgid "Here are examples of two possible ``INSTALLER`` files::" -msgstr "" +msgstr "Aqui estão exemplos de dois possíveis arquivos ``INSTALLER``::" #: ../source/specifications/recording-installed-packages.rst:195 msgid "" @@ -15877,24 +16142,31 @@ msgid "" "suggest that the tool named in ``INSTALLER`` may be able to do the " "uninstallation." msgstr "" +"Este valor deve ser usado apenas para fins informativos. Por exemplo, se uma " +"ferramenta é solicitada a desinstalar um projeto, mas não encontra o arquivo " +"``RECORD``, pode sugerir que a ferramenta nomeada em ``INSTALLER`` pode ser " +"capaz de fazer a desinstalação." #: ../source/specifications/recording-installed-packages.rst:201 msgid "The direct_url.json file" -msgstr "" +msgstr "O arquivo direct_url.json" #: ../source/specifications/recording-installed-packages.rst:203 msgid "" "This file MUST be created by installers when installing a distribution from " "a requirement specifying a direct URL reference (including a VCS URL)." msgstr "" +"Este arquivo DEVE ser criado por instaladores ao instalar uma distribuição a " +"partir de um requisito que especifica uma referência de URL direta (" +"incluindo uma URL de VCS)." #: ../source/specifications/recording-installed-packages.rst:209 msgid "Its detailed specification is at :ref:`direct-url`." -msgstr "" +msgstr "Sua especificação detalhada está em :ref:`direct-url`." #: ../source/specifications/simple-repository-api.rst:6 msgid "Simple repository API" -msgstr "" +msgstr "API simples de repositório" #: ../source/specifications/simple-repository-api.rst:8 msgid "" @@ -15904,10 +16176,15 @@ msgid "" "and specifying the interface version provided by an index server in :pep:" "`629`." msgstr "" +"A interface atual para consultar versões de pacotes disponíveis e recuperar " +"pacotes de um servidor de indexação é definida em :pep:`503`, com a adição " +"de suporte a retirada ou \"yank\" (que permite um tipo de exclusão de " +"arquivo) conforme definido em :pep:`592` e especificando a versão da " +"interface fornecida por um servidor de indexação em :pep:`629`." #: ../source/specifications/source-distribution-format.rst:6 msgid "Source distribution format" -msgstr "" +msgstr "Formato de distribuição fonte" #: ../source/specifications/source-distribution-format.rst:8 msgid "" @@ -15916,6 +16193,10 @@ msgid "" "The layout of such a distribution was originally specified in :pep:`517` and " "is formally documented here." msgstr "" +"O formato padrão atual do formato de distribuição fonte é identificado pela " +"presença de um arquivo :file:`pyproject.toml` no arquivo de distribuição. O " +"layout de tal distribuição foi originalmente especificado na :pep:`517` e " +"está formalmente documentado aqui." #: ../source/specifications/source-distribution-format.rst:13 msgid "" @@ -15927,14 +16208,21 @@ msgid "" "MUST follow the rules applicable to source distributions defined in the " "metadata specification." msgstr "" +"Existe também o formato de distribuição fonte legado, implicitamente " +"definido pelo comportamento do módulo ``distutils`` na biblioteca padrão, ao " +"executar :command:`setup.py sdist`. Este documento não tenta padronizar este " +"formato, exceto para observar que se uma distribuição de fonte legada contém " +"um arquivo ``PKG-INFO`` usando metadados versão 2.2 ou posterior, então ela " +"DEVE seguir as regras aplicáveis às distribuições de fonte definidas nos " +"metadados especificação." #: ../source/specifications/source-distribution-format.rst:21 msgid "Source distributions are also known as *sdists* for short." -msgstr "" +msgstr "Distribuições fonte também são conhecidas pela abreviação *sdists*." #: ../source/specifications/source-distribution-format.rst:24 msgid "Source distribution file name" -msgstr "" +msgstr "Nome de arquivo da distribuição fonte" #: ../source/specifications/source-distribution-format.rst:26 msgid "" @@ -15944,16 +16232,23 @@ msgid "" "canonicalization rules) with ``-`` characters replaced with ``_``, and " "``{version}`` is the project version." msgstr "" +"O nome do arquivo de um sdist não está padronizado atualmente, embora a " +"forma *de fato* seja ``{name}-{version}.tar.gz``, onde ``{name}`` é a forma " +"canônica do nome do projeto (veja :pep:`503` para as regras de canonização) " +"com caracteres ``-`` substituídos por ``_`` e ``{version}`` é a versão do " +"projeto." #: ../source/specifications/source-distribution-format.rst:31 msgid "" "The name and version components of the filename MUST match the values stored " "in the metadata contained in the file." msgstr "" +"O nome e os componentes da versão do nome do arquivo DEVEM corresponder aos " +"valores armazenados nos metadados contidos no arquivo." #: ../source/specifications/source-distribution-format.rst:35 msgid "Source distribution file format" -msgstr "" +msgstr "Formato de arquivo de distribuição fonte" #: ../source/specifications/source-distribution-format.rst:37 msgid "" @@ -15966,44 +16261,63 @@ msgid "" "`core-metadata` specification. The metadata MUST conform to at least version " "2.2 of the metadata specification." msgstr "" +"Uma distribuição fonte ``.tar.gz`` (sdist) contém um único diretório de " +"nível superior chamado ``{name}-{version}`` (por exemplo, ``foo-1.0``), " +"contendo os arquivos fonte do pacote. O nome e a versão DEVEM corresponder " +"aos metadados armazenados no arquivo. Este diretório também deve conter um " +":file:`pyproject.toml` no formato definido em :ref:`declaring-build-" +"dependencies` e um arquivo ``PKG-INFO`` contendo metadados no formato " +"descrito na especificação :ref:`core-metadata`. Os metadados DEVEM estar em " +"conformidade com pelo menos a versão 2.2 da especificação de metadados." #: ../source/specifications/source-distribution-format.rst:45 msgid "" "No other content of a sdist is required or defined. Build systems can store " "whatever information they need in the sdist to build the project." msgstr "" +"Nenhum outro conteúdo de um sdist é necessário ou definido. Os sistemas de " +"construção podem armazenar qualquer informação necessária no sdist para " +"construir o projeto." #: ../source/specifications/source-distribution-format.rst:48 msgid "" "The tarball should use the modern POSIX.1-2001 pax tar format, which " "specifies UTF-8 based file names." msgstr "" +"O tarball deve usar o formato tar pax POSIX.1-2001 moderno, que especifica " +"nomes de arquivo baseados em UTF-8." #: ../source/specifications/version-specifiers.rst:6 msgid "Version specifiers" -msgstr "" +msgstr "Especificadores de versão" #: ../source/specifications/version-specifiers.rst:8 msgid "" "Version numbering requirements and the semantics for specifying comparisons " "between versions are defined in :pep:`440`." msgstr "" +"Os requisitos de numeração de versão e a semântica para especificar " +"comparações entre as versões são definidos na :pep:`440`." #: ../source/specifications/version-specifiers.rst:11 msgid "" "The version specifiers section in this PEP supersedes the version specifiers " "section in :pep:`345`." msgstr "" +"A seção de especificadores de versão nesta PEP substitui a seção de " +"especificadores de versão na :pep:`345`." #: ../source/support.rst:3 msgid "How to Get Support" -msgstr "" +msgstr "Como obter suporte" #: ../source/support.rst:5 msgid "" "For support related to a specific project, see the links on the :doc:" "`Projects ` page." msgstr "" +"Para suporte relacionado a um projeto específico, consulte os links na " +"página :doc:`Projetos `." #: ../source/support.rst:8 msgid "" @@ -16012,6 +16326,10 @@ msgid "" "`packaging-problems `_ " "repository on GitHub." msgstr "" +"Para algo mais geral, ou quando você não tiver certeza, por favor `relate um " +"problema `_ no " +"repositório `packaging-problems `" +"_ no GitHub." #: ../source/tutorials/creating-documentation.rst:5 msgid "Creating Documentation" @@ -16593,7 +16911,7 @@ msgstr "Atualize um ``SomeProject`` já instalado para o mais recente do PyPI." #: ../source/tutorials/installing-packages.rst:408 msgid "Installing to the User Site" -msgstr "" +msgstr "Instalando para o site do usuário" #: ../source/tutorials/installing-packages.rst:410 msgid "" @@ -17606,9 +17924,9 @@ msgid "" msgstr "" "A :term:`distribuição construída ` final terá os " "arquivos Python nos pacotes descobertos ou listados Python. Se você deseja " -"controlar o que acontece aqui, como adicionar arquivos de dados, consulte :" -"doc:`Incluindo Arquivos de Dados ` da :doc:" -"`documentação do setuptools `." +"controlar o que acontece aqui, como adicionar arquivos de dados, consulte " +":doc:`Incluindo Arquivos de Dados ` da :doc:`" +"documentação do setuptools `." #: ../source/tutorials/packaging-projects.rst:402 msgid "Generating distribution archives" @@ -17717,7 +18035,7 @@ msgid "" "Now that you are registered, you can use :ref:`twine` to upload the " "distribution packages. You'll need to install Twine:" msgstr "" -"Agora que você está registrado, você pode usar: ref:`twine` para enviar os " +"Agora que você está registrado, você pode usar :ref:`twine` para enviar os " "pacotes de distribuição. Você precisará instalar o Twine:" #: ../source/tutorials/packaging-projects.rst:492 From d4d8fa27e8010602db1b7d960d05eab854260316 Mon Sep 17 00:00:00 2001 From: Rafael Fontenelle Date: Thu, 2 Dec 2021 23:12:07 +0100 Subject: [PATCH 0200/1072] Translated using Weblate (Portuguese (Brazil)) Currently translated at 100.0% (2271 of 2271 strings) Co-authored-by: Rafael Fontenelle Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/pt_BR/ Translation: pypa/packaging.python.org --- locales/pt_BR/LC_MESSAGES/messages.po | 59 ++++++++++++++------------- 1 file changed, 30 insertions(+), 29 deletions(-) diff --git a/locales/pt_BR/LC_MESSAGES/messages.po b/locales/pt_BR/LC_MESSAGES/messages.po index 8e4396269..7f42a7129 100644 --- a/locales/pt_BR/LC_MESSAGES/messages.po +++ b/locales/pt_BR/LC_MESSAGES/messages.po @@ -8,7 +8,7 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-11-28 17:48+0000\n" +"PO-Revision-Date: 2021-11-29 08:50+0000\n" "Last-Translator: Rafael Fontenelle \n" "Language-Team: Portuguese (Brazil) \n" @@ -1179,12 +1179,12 @@ msgid "" "file for Python extensions on Unix, a DLL (given the .pyd extension) for " "Python extensions on Windows, or a Java class file for Jython extensions." msgstr "" -"Um :term:`Módulo ` escrito na linguagem de baixo nível da " -"implementação Python: C/C ++ para Python, Java para Jython. Normalmente " -"contido em um único arquivo pré-compilado carregável dinamicamente, por " -"exemplo, um arquivo de objeto compartilhado (.so) para extensões Python no " -"Unix, uma DLL (dada a extensão .pyd) para extensões Python no Windows ou um " -"arquivo de classe Java para extensões Jython." +"Um :term:`Módulo` escrito na linguagem de baixo nível da implementação " +"Python: C/C++ para Python, Java para Jython. Normalmente contido em um único " +"arquivo pré-compilado carregável dinamicamente, por exemplo, um arquivo de " +"objeto compartilhado (.so) para extensões Python no Unix, uma DLL (dada a " +"extensão .pyd) para extensões Python no Windows ou um arquivo de classe Java " +"para extensões Jython." #: ../source/glossary.rst:59 msgid "Known Good Set (KGS)" @@ -3657,8 +3657,8 @@ msgid "" "platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. " "Details of the latter are defined in :pep:`513`." msgstr "" -":term:`PyPI ` tem suporte atualmente a envios " -"de wheels de plataforma do Windows, macOS e da ABI multidistro " +":term:`PyPI ` oferece suporte atualmente a " +"envios de wheels de plataforma do Windows, macOS e da ABI multidistro " "``manylinux*``. Detalhes sobre o último estão definidos em :pep:`513`." #: ../source/guides/distributing-packages-using-setuptools.rst:855 @@ -4491,8 +4491,8 @@ msgid "" "around this limitation." msgstr "" "Tal como acontece com os pacotes de sistema Linux, os instaladores Windows " -"irão apenas instalar em uma instalação de sistema Python -- eles não têm " -"suporte à instalação em ambientes virtuais. Permitir o acesso a " +"irão apenas instalar em uma instalação de sistema Python -- eles não " +"oferecem suporte à instalação em ambientes virtuais. Permitir o acesso a " "distribuições instaladas no sistema Python ao usar ambientes virtuais é uma " "abordagem comum para contornar essa limitação." @@ -8637,7 +8637,7 @@ msgstr "" "único caractere de nome de arquivo regular, e ``[chars]`` corresponde a " "qualquer um dos caracteres entre os colchetes (que podem conter intervalos " "de caracteres, por exemplo, ``[az]`` ou ``[ a-fA-F0-9]``). Setuptools também " -"tem suporte não documentado para ``**`` correspondendo a zero ou mais " +"oferece suporte não documentado a ``**`` correspondendo a zero ou mais " "caracteres, incluindo barra, barra invertida e dois pontos." #: ../source/guides/using-manifest-in.rst:87 @@ -8857,7 +8857,7 @@ msgid "" "applications, see the :doc:`Overview of Python Packaging `" msgstr "" "Para obter uma visão geral das opções de empacotamento para bibliotecas e " -"aplicações Python , veja a :doc:`Visão geral de empacotamento no Python " +"aplicações Python, veja a :doc:`Visão geral de empacotamento no Python " "`" #: ../source/index.rst:52 @@ -11005,10 +11005,10 @@ msgid "" "destination." msgstr "" "Como os pacotes consistem em vários arquivos, eles são mais difíceis de " -"distribuir. A maioria dos protocolos tem suporte à transferência de apenas " -"um arquivo por vez (quando foi a última vez que você clicou em um link e ele " -"baixou vários arquivos?). É mais fácil obter transferências incompletas e " -"mais difícil garantir a integridade do código no destino." +"distribuir. A maioria dos protocolos oferece suporte à transferência de " +"apenas um arquivo por vez (quando foi a última vez que você clicou em um " +"link e ele baixou vários arquivos?). É mais fácil obter transferências " +"incompletas e mais difícil garantir a integridade do código no destino." #: ../source/overview.rst:90 msgid "" @@ -11018,9 +11018,9 @@ msgid "" "Package`, or *sdist* for short." msgstr "" "Contanto que seu código não contenha nada além de código puro Python, e você " -"saiba que seu ambiente de implantação tem suporte a sua versão de Python, " -"então você pode usar as ferramentas de empacotamento nativas do Python para " -"criar um :term:`Pacote de Distribuição` fonte, ou *sdist*." +"saiba que seu ambiente de implantação oferece suporte a sua versão de " +"Python, então você pode usar as ferramentas de empacotamento nativas do " +"Python para criar um :term:`Pacote de Distribuição` fonte, ou *sdist*." #: ../source/overview.rst:95 msgid "" @@ -11058,9 +11058,10 @@ msgid "" "actively-maintained fork of PIL!" msgstr "" "Python e PyPI oferecem suporte a várias distribuições, fornecendo diferentes " -"implementações do mesmo pacote. Por exemplo, a `distribuição PIL `_ não mantida, mas seminal fornece o pacote PIL, e " -"também o `Pillow `_, um fork do PIL!" +"implementações do mesmo pacote. Por exemplo, a `distribuição PIL " +"`_ não mantida, mas inspiracional, fornece o " +"pacote PIL, e também o `Pillow `_, um fork " +"do PIL!" #: ../source/overview.rst:114 msgid "" @@ -11083,8 +11084,8 @@ msgid "" "Rust, and other languages." msgstr "" "Grande parte do poder prático do Python vem de sua capacidade de integração " -"com o ecossistema de software, em particular bibliotecas escritas em C, C +" -"+, Fortran, Rust e outras linguagens." +"com o ecossistema de software, em particular bibliotecas escritas em C, C++, " +"Fortran, Rust e outras linguagens." #: ../source/overview.rst:125 msgid "" @@ -11360,7 +11361,7 @@ msgstr "" #: ../source/overview.rst:249 msgid "Technologies which support this model:" -msgstr "Tecnologias que têm suporte a este modelo:" +msgstr "Tecnologias que oferecem suporte a este modelo:" #: ../source/overview.rst:251 msgid "`PEX `_ (Python EXecutable)" @@ -17183,9 +17184,9 @@ msgid "" "python-poetry/poetry>`_ project as an alternative dependency management " "solution." msgstr "" -"Desenvolvedores de bibliotecas Python, ou de aplicações que tem suporte a " -"distribuição como bibliotecas Python, também devem considerar o projeto " -"`poetry `_ como uma solução " +"Desenvolvedores de bibliotecas Python, ou de aplicações que oferece suporte " +"a distribuição como bibliotecas Python, também devem considerar o projeto `" +"poetry `_ como uma solução " "alternativa de gerenciamento de dependências." #: ../source/tutorials/managing-dependencies.rst:30 From 7abd992d2ff49ea1db30abca268f7aeef399b3f6 Mon Sep 17 00:00:00 2001 From: moto kawasaki Date: Thu, 2 Dec 2021 23:12:07 +0100 Subject: [PATCH 0201/1072] Translated using Weblate (Japanese) Currently translated at 16.3% (372 of 2271 strings) Translated using Weblate (Japanese) Currently translated at 15.0% (341 of 2271 strings) Co-authored-by: moto kawasaki Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/ja/ Translation: pypa/packaging.python.org --- locales/ja/LC_MESSAGES/messages.po | 123 +++++++++++++++++++++++------ 1 file changed, 101 insertions(+), 22 deletions(-) diff --git a/locales/ja/LC_MESSAGES/messages.po b/locales/ja/LC_MESSAGES/messages.po index cdd10af41..21c1708e2 100644 --- a/locales/ja/LC_MESSAGES/messages.po +++ b/locales/ja/LC_MESSAGES/messages.po @@ -7,7 +7,7 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-11-27 18:18+0000\n" +"PO-Revision-Date: 2021-12-02 22:12+0000\n" "Last-Translator: moto kawasaki \n" "Language-Team: Japanese \n" @@ -1519,196 +1519,275 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:273 msgid "Install `pypinfo`_ using pip." -msgstr "" +msgstr "pipを用いて `pypinfo`_ をインストール。" #: ../source/guides/analyzing-pypi-package-downloads.rst:279 msgid "Usage:" -msgstr "" +msgstr "使い方：" #: ../source/guides/analyzing-pypi-package-downloads.rst:295 msgid "``pandas-gbq``" -msgstr "" +msgstr "``pandas-gbq``" #: ../source/guides/analyzing-pypi-package-downloads.rst:297 msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." -msgstr "" +msgstr "`pandas-bbq`_ プロジェクトを使えば `Pandas`_ 経由でクエリ結果を参照することができます。" #: ../source/guides/analyzing-pypi-package-downloads.rst:301 #: ../source/specifications/binary-distribution-format.rst:459 msgid "References" -msgstr "" +msgstr "参考文献" #: ../source/guides/analyzing-pypi-package-downloads.rst:303 msgid "`PyPI Download Counts deprecation email `__" msgstr "" +"`PyPI ダウンロード統計を非推奨とするメール (PyPI Download Counts deprecation email) " +"`__" #: ../source/guides/analyzing-pypi-package-downloads.rst:304 msgid "`PyPI BigQuery dataset announcement email `__" msgstr "" +"`PyPI BigQueryデータセットをアナウンスするメール (PyPI BigQuery dataset announcement email) " +"`__" #: ../source/guides/creating-and-discovering-plugins.rst:3 msgid "Creating and discovering plugins" -msgstr "" +msgstr "プラグイン作成と発見" #: ../source/guides/creating-and-discovering-plugins.rst:5 msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." msgstr "" +"Pythonのアプリケーションまたはライブラリを作成する時には、カスタマイズができるようにしたり **プラグイン** " +"を通じて機能を追加できるようにしたりすることがしばしばあります。Pythonのパッケージは別々に配布できますので、" +"あなたのアプリケーションまたはライブラリが利用可能なすべてのプラグインを自動的に **探し出す** ようにしたくなるかもしれません。" #: ../source/guides/creating-and-discovering-plugins.rst:10 msgid "There are three major approaches to doing automatic plugin discovery:" -msgstr "" +msgstr "プラグインの自動検出には大きく分けて３個の実現方法があります。" #: ../source/guides/creating-and-discovering-plugins.rst:12 msgid "`Using naming convention`_." -msgstr "" +msgstr "`命名規則を用いるやり方 `_ 。" #: ../source/guides/creating-and-discovering-plugins.rst:13 msgid "`Using namespace packages`_." -msgstr "" +msgstr "`namespaceパッケージを用いるやり方 `_ 。" #: ../source/guides/creating-and-discovering-plugins.rst:14 msgid "`Using package metadata`_." -msgstr "" +msgstr "`パッケージのメタデータを用いるやり方 `_ 。" #: ../source/guides/creating-and-discovering-plugins.rst:18 msgid "Using naming convention" -msgstr "" +msgstr "命名規則を用いるやり方" #: ../source/guides/creating-and-discovering-plugins.rst:20 msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" msgstr "" +"あなたのアプリケーション用のすべてのプラグインが命名規則に従うのであれば、 :func:`pkgutil.iter_modules` " +"を用いて命名規則に合致するトップレベルのすべてのモジュールを発見することができます。例えば、 `Flask`_ は命名規則として " +"``flask_{plugin_name}`` を使います。もし、すべてのインストール済みFlask用プラグインを発見したいのであれば：" #: ../source/guides/creating-and-discovering-plugins.rst:38 msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" msgstr "" +"もしあなたが `Flask-SQLAlchemy`_ と `Flask-Talisman`_ のふたつのプラグインをインストールしてあるなら、 " +"``discovered_plugins`` は次のようになるでしょう：" #: ../source/guides/creating-and-discovering-plugins.rst:48 msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." msgstr "" +"プラグインの命名規則を用いることで、あなたの命名規則に従うすべてのパッケージについてPython パッケージインデックスの `simple API`_ " +"から検索することもできるようになります。" #: ../source/guides/creating-and-discovering-plugins.rst:59 msgid "Using namespace packages" -msgstr "" +msgstr "namespaceパッケージを用いるやり方" #: ../source/guides/creating-and-discovering-plugins.rst:61 msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" msgstr "" +":doc:`Namespace パッケージ ` " +"を使えば、プラグインをどこに配置するかに関する規則や、発見するための方法も提供できます。例えば、あなたが名前空間を決めるサブパッケージ ``myapp." +"plugins`` を作成したら、その名前空間に他の :term:`配布物 ` " +"がモジュールやパッケージを配置することができます。インストールが終われば、あなたは :func:`pkgutil.iter_modules` " +"を用いてインストール済みの全てのモジュールやパッケージをその名前空間で発見できるでしょう。" #: ../source/guides/creating-and-discovering-plugins.rst:89 msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" msgstr "" +":func:`~pkgutil.iter_modules` に ``myapp.plugins.__path__`` " +"を指定すると、その名前空間の直下にあるモジュールだけを探索するようになります。例えば、あなたがモジュールの ``myapp.plugins.a`` と " +"``myapp.plugins.b`` を提供する配布物をインストールしているとしたら、 ``discovered_plugins`` " +"は次のようになるでしょう：" #: ../source/guides/creating-and-discovering-plugins.rst:101 msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." msgstr "" +"この例ではサブパッケージを名前空間を決めるパッケージ(``myapp.plugins``)として使っていますが、トップレベルのパッケージをこの(``mya" +"pp_plugins``のような)目的に用いることも可能です。名前空間をどのようにして決めるかは好みの問題ですが、あなたのプロジェクトのトップレベルのパッ" +"ケージ(この場合では``myapp``)をプラグインの名前空間を決めるために用いると、全体の名前空間を破壊するようなプラグインがひとつあるだけで、あなたの" +"プロジェクトをインポートすることができなくなるのでお勧めしません。「名前空間を決めるサブパッケージ」の手法がうまく動作するためには、プラグインパッケージ側" +"のトップレベルパッケージのディレクトリ(この場合には``myapp``)に :file:`__init__.py` " +"が存在してはいけませんし、名前空間を決めるサブパッケージのディレクトリ(``myapp/plugins``)にある :file:`__init__." +"py`をプラグインパッケージ側でインクルードしなければなりません。これはまた、 プラグインの側で:func:`setuptools." +"find_packages` を使うのではなく、パッケージの名前を :func:`setup`の ``packages`` " +"引数に明示的に渡す必要がある、ということを意味しています。" #: ../source/guides/creating-and-discovering-plugins.rst:115 msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." msgstr "" +"名前空間を決めるパッケージは込み入った機能で、いくつかの異なる作成方法があります。 :doc:`packaging-namespace-packages`" +" 文書を読むとともに、あなたのプロジェクト用のプラグインとしてはどちらの手法が好ましいのかを明白に文書化しておくことを強くお勧めします。" #: ../source/guides/creating-and-discovering-plugins.rst:121 msgid "Using package metadata" -msgstr "" +msgstr "パッケージのメタデータを用いるやり方" #: ../source/guides/creating-and-discovering-plugins.rst:123 msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." msgstr "" +"`Setuptools`_ はプラグイン向けに :doc:`特別なサポート ` " +"を提供しています。 :file:`setup.py` の中の :func:`setup`の ``entry_points`` " +"引数を準備することで、プラグインが検出されるように登録することができます。" #: ../source/guides/creating-and-discovering-plugins.rst:128 msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" msgstr "" +"例えば、``myapp-plugin-a`` という名前のパッケージが存在して、その :file:`setup.py` をインクルードする場合：" #: ../source/guides/creating-and-discovering-plugins.rst:139 msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" msgstr "" +"そして、 :func:`import lib.metadata.entry_points` (あるいはPython 3.6-3.9用の " +"`backport`_ ``import lib_metadata>=3.6``)を使うことで、登録されたエントリポイントを全て検出することができます。" #: ../source/guides/creating-and-discovering-plugins.rst:154 msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" msgstr "" +"この例では、 ``discovered_plugins`` は :class:`import lib.metadata.EntryPoint` " +"型の(オブジェクトの)集合となるでしょう。" #: ../source/guides/creating-and-discovering-plugins.rst:163 msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." msgstr "" +"今や、``discovered_plugins['a'].load()`` を実行することで、あなたが選んだモジュールをインポートすることができます。" #: ../source/guides/creating-and-discovering-plugins.rst:166 msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." msgstr "" +":file:`setup.py` における ``entry_points`` の指定はかなり自由度が高く、オプションがたくさんあります。 :doc:`" +"entry_point ` の全部のセクションに目を通すことをお勧めします。" #: ../source/guides/creating-and-discovering-plugins.rst:170 msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." msgstr "" +"この仕様は :doc:`標準ライブラリ ` " +"の一部なので、setuptools以外のほとんどのパッケージングツールでもエントリポイントを定義できる機能を提供しています。" #: ../source/guides/distributing-packages-using-setuptools.rst:5 msgid "Packaging and distributing projects" -msgstr "" +msgstr "パッケージングとプロジェクトの配布" #: ../source/guides/distributing-packages-using-setuptools.rst:7 msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." msgstr "" +"この節では、あなた自身のPythonパッケージを設定し、パッケージにまとめ、そして配布する方法の基本について説明します。あなたが既に :doc:`/" +"tutorials/installing-packages` " +"ページの内容については慣れ親しんでいるものと仮定して進めます(訳者による蛇足、まだの方は読んできてね)。" #: ../source/guides/distributing-packages-using-setuptools.rst:11 msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." msgstr "" +"この節は、Pythonプロジェクトの開発についての全体的なベストプラクティスを説明しているわけではありません。例えば、バージョン管理や文書化、あるいは試験" +"について、手引きとなったりツールを推奨するようなことはありません。" #: ../source/guides/distributing-packages-using-setuptools.rst:15 msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." msgstr "" +"より詳しい参考文献としては、:ref:`setuptools` の説明文書の中の :std:doc:`パッケージのビルドと配布 ` を挙げておきますが、推奨事項のいくつかはもはや古くなっているかもしれません。喰い違いがあった場合には、Python " +"パッケージングユーザガイドの推奨事項を優先してください。" #: ../source/guides/distributing-packages-using-setuptools.rst:25 msgid "Requirements for packaging and distributing" -msgstr "" +msgstr "パッケージングと配布に対する要求事項" #: ../source/guides/distributing-packages-using-setuptools.rst:26 msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." msgstr "" +"最初に、あなたが既に :ref:`パッケージをインストールする際の要求事項 ` " +"を満たしていることを確実にしてください。" #: ../source/guides/distributing-packages-using-setuptools.rst:29 msgid "Install \"twine\" [1]_:" -msgstr "" +msgstr "\"twine\"をインストールする [1]_:" #: ../source/guides/distributing-packages-using-setuptools.rst:43 msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." msgstr "" +"あなたのプロジェクトの :term:`配布物 ` を :term:`PyPI ` にアップロードする( :ref:`後述 ` " +")ためにこれが必要になるでしょう。" #: ../source/guides/distributing-packages-using-setuptools.rst:49 msgid "Configuring your project" -msgstr "" +msgstr "あなたのプロジェクトを設定する" #: ../source/guides/distributing-packages-using-setuptools.rst:53 msgid "Initial files" -msgstr "" +msgstr "最初に必要なファイル群" #: ../source/guides/distributing-packages-using-setuptools.rst:58 msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." msgstr "" +"最重要のファイルは、あなたのプロジェクトのディレクトリの一番上(ルート)にある :file:`setup.py` です。`PyPA サンプルプロジェクト " +"`_ の `setup.py `_ に具体例があります。" #: ../source/guides/distributing-packages-using-setuptools.rst:63 msgid ":file:`setup.py` serves two primary functions:" -msgstr "" +msgstr ":file:`setup.py` はふたつの主要な機能を提供します。" #: ../source/guides/distributing-packages-using-setuptools.rst:65 msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." msgstr "" +"まず、あなたのプロジェクトをさまざまな角度から設定するためのファイルです。 :file:`setup.py` の主要な機能は、グローバルな " +"``setup()`` 関数を含んでいることです。この関数にキーワード引数を渡すことで、あなたのプロジェクトの特定の細部を定義することができます。" +"適切な引数のほとんどについて :ref:`次節 ` で説明します。" #: ../source/guides/distributing-packages-using-setuptools.rst:71 msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." msgstr "" +"それは、パッケージングする上での作業項目に関連したさまざまなコマンドを走らせるためのコマンドラインインタフェイスです。使用可能なコマンドを一覧するには、 " +"``python setup.py --help-commands`` を実行してください。" #: ../source/guides/distributing-packages-using-setuptools.rst:79 msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." msgstr "" +":file:`setup.cfg` は :file:`setup.py` のコマンド群に対するオプションの既定値を含みます。 `PyPA " +"サンプルプロジェクト `_ の中の `setup.cfg " +"`_ に使用例が出ています。" #: ../source/guides/distributing-packages-using-setuptools.rst:86 msgid "README.rst / README.md" -msgstr "" +msgstr "README.rstとREADME.md" #: ../source/guides/distributing-packages-using-setuptools.rst:88 msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." msgstr "" +"すべてのプロジェクトは、プロジェクトのゴールを記したreadmeファイルを備えるべきです。一番良くあるフォーマットは拡張子が \"rst\" の `" +"reStructuredText `_ " +"ですが、これは(訳註、必須の)要求事項というわけではありません。他にも複数の種類の `マークダウン `_ フォーマットがサポートされています(``setup()`` の :ref:`" +"long_description_content_type ` 引数を見てください)。" #: ../source/guides/distributing-packages-using-setuptools.rst:95 msgid "For an example, see `README.md `_ from the `PyPA sample project `_." msgstr "" +"`PyPA sample project `_ の中の `" +"README.md `_ " +"に例が出ています。" #: ../source/guides/distributing-packages-using-setuptools.rst:99 msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." @@ -1732,7 +1811,7 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:122 msgid "LICENSE.txt" -msgstr "" +msgstr "LICENSE.txt" #: ../source/guides/distributing-packages-using-setuptools.rst:124 msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." From 42311844be6f79fcf9de1988b1c17d454ed53077 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=A4=A7=E8=83=96=E7=BA=B8?= Date: Thu, 2 Dec 2021 23:12:08 +0100 Subject: [PATCH 0202/1072] Translated using Weblate (Chinese (Simplified)) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently translated at 26.9% (613 of 2271 strings) Co-authored-by: 大胖纸 Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hans/ Translation: pypa/packaging.python.org --- locales/zh_Hans/LC_MESSAGES/messages.po | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po index 0f5fbf0fa..3950c581c 100644 --- a/locales/zh_Hans/LC_MESSAGES/messages.po +++ b/locales/zh_Hans/LC_MESSAGES/messages.po @@ -8,13 +8,14 @@ # xlivevil , 2021. # Eric , 2021. # YangYulin , 2021. +# 大胖纸 , 2021. msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-10-23 18:40+0000\n" -"Last-Translator: meowmeowmeowcat \n" +"PO-Revision-Date: 2021-12-02 22:12+0000\n" +"Last-Translator: 大胖纸 \n" "Language-Team: Chinese (Simplified) \n" "Language: zh_Hans\n" @@ -22,7 +23,7 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=1; plural=0;\n" -"X-Generator: Weblate 4.9-dev\n" +"X-Generator: Weblate 4.10-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -1280,7 +1281,7 @@ msgstr "" #: ../source/glossary.rst:177 msgid "Requirement Specifier" -msgstr "" +msgstr "需求说明符" #: ../source/glossary.rst:180 msgid "" @@ -1294,7 +1295,7 @@ msgstr "" #: ../source/glossary.rst:187 msgid "Requirements File" -msgstr "" +msgstr "需求文件" #: ../source/glossary.rst:190 msgid "" From dda85cead1232467464de9b3242acc6e11292121 Mon Sep 17 00:00:00 2001 From: moto kawasaki Date: Sat, 4 Dec 2021 08:51:52 +0100 Subject: [PATCH 0203/1072] Translated using Weblate (Japanese) Currently translated at 16.6% (377 of 2271 strings) Co-authored-by: moto kawasaki Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/ja/ Translation: pypa/packaging.python.org --- locales/ja/LC_MESSAGES/messages.po | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/locales/ja/LC_MESSAGES/messages.po b/locales/ja/LC_MESSAGES/messages.po index 21c1708e2..d9157f01c 100644 --- a/locales/ja/LC_MESSAGES/messages.po +++ b/locales/ja/LC_MESSAGES/messages.po @@ -7,7 +7,7 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-12-02 22:12+0000\n" +"PO-Revision-Date: 2021-12-04 07:51+0000\n" "Last-Translator: moto kawasaki \n" "Language-Team: Japanese \n" @@ -1792,22 +1792,35 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:99 msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." msgstr "" +":ref:`setuptools`の0.6." +"27およびそれ以降のバージョンを使っているプロジェクトでは、標準のreadmeファイル(:file:`README.rst`、 :file:`README" +".txt`、または :file:`README`)がデフォルトでソースコード配布物に含まれるようになっています。標準ライブラリの " +":ref:`distutils` では、Python 3.7からこの動作を採用しました。さらに、:ref:`setuptools` の36.4." +"0およびそれ以降のバージョンでは、もし見つかれば :file:`README.md` " +"を含めるようになっています。もしあなたがsetuptoolsを使っているのであれば、あなたはreadmeファイルを :file:`MANIFEST.in`" +" に明記する必要はありません。そうでないなら、明示的に書いてください。" #: ../source/guides/distributing-packages-using-setuptools.rst:108 msgid "MANIFEST.in" -msgstr "" +msgstr "MANIFEST.in" #: ../source/guides/distributing-packages-using-setuptools.rst:110 msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." msgstr "" +"自動的に追加されるファイル以外のファイルをソースコード配布物に追加したい場合には、 :file:`MANIFEST.in` が必要になります。 " +"どんなファイルがデフォルトで自動的に追加されるのかも含めて、 :file:`MANIFEST.in` の書き方の詳細については「 :ref:`" +"MANIFEST.in の使い方 `」を見てください。" #: ../source/guides/distributing-packages-using-setuptools.rst:115 msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." msgstr "" +"`PyPA sample project `_ の `" +"MANIFEST.in `" +"_ に例がでています。" #: ../source/guides/distributing-packages-using-setuptools.rst:119 msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." -msgstr "" +msgstr ":file:`MANIFEST.in` は、wheelなどのバイナリ配布物には影響を与えません。" #: ../source/guides/distributing-packages-using-setuptools.rst:122 msgid "LICENSE.txt" From cfd358b748e1f7361571c2e129f5f113b7a71fcb Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Sat, 27 Nov 2021 18:44:00 +0100 Subject: [PATCH 0204/1072] Bump translation workflow Python version to 3.10 --- .github/workflows/translation.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index 4638e5c4e..e8161431c 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -20,7 +20,8 @@ jobs: - name: Set up Python uses: actions/setup-python@v2 with: - python-version: 3.9 + python-version: >- + 3.10 - name: Install Python tooling run: python -m pip install --upgrade nox virtualenv From d4f4c0b2bc64b4a13e50fddc198719330047e90f Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Sat, 27 Nov 2021 18:47:20 +0100 Subject: [PATCH 0205/1072] Fix the Git user setup in the translation workflow --- .github/workflows/translation.yml | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index e8161431c..9d6007ac3 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -16,6 +16,11 @@ jobs: steps: - name: Grab the repo src uses: actions/checkout@v2 + - name: Setup git user as [bot] + # Refs: + # * https://github.community/t/github-actions-bot-email-address/17204/6 + # * https://github.com/actions/checkout/issues/13#issuecomment-724415212 + uses: fregante/setup-git-user@v1.0.1 - name: Set up Python uses: actions/setup-python@v2 @@ -31,8 +36,6 @@ jobs: - name: Commit the POT file to Git run: | - git config --local user.email "github-actions[bot]@users.noreply.github.com" - git config --local user.name "github-actions[bot]" git_hash=$(git rev-parse --short "${GITHUB_SHA}") git commit -m "Update messages.pot as of version ${git_hash}" locales/messages.pot From 5e14855a98ca57e3dff492064c6d9262530dd0f3 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Sat, 27 Nov 2021 19:03:29 +0100 Subject: [PATCH 0206/1072] Push i18n POT file to a separate branch --- .github/workflows/translation.yml | 42 ++++++++++++++++++++++++------- 1 file changed, 33 insertions(+), 9 deletions(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index 9d6007ac3..bcfc07f11 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -9,6 +9,9 @@ on: types: - completed +env: + I18N_BRANCH: translation/source + jobs: build: runs-on: ubuntu-latest @@ -16,12 +19,36 @@ jobs: steps: - name: Grab the repo src uses: actions/checkout@v2 + with: + fetch-depth: 0 # To reach the common commit - name: Setup git user as [bot] # Refs: # * https://github.community/t/github-actions-bot-email-address/17204/6 # * https://github.com/actions/checkout/issues/13#issuecomment-724415212 uses: fregante/setup-git-user@v1.0.1 + - name: Switch to the translation source branch + run: | + sh -x + + git fetch origin \ + '+refs/heads/${{ + env.I18N_BRANCH + }}:refs/remotes/origin/${{ + env.SRC_BRANCH + }}' + + git checkout -B '${{ env.I18N_BRANCH }}' \ + 'origin/${{ env.I18N_BRANCH }}' + + - name: >- + Merge '${{ github.event.repository.default_branch }}' + to '${{ env.I18N_BRANCH }}' + run: | + sh -x + + git merge '${{ github.event.repository.default_branch }}' + - name: Set up Python uses: actions/setup-python@v2 with: @@ -37,15 +64,12 @@ jobs: - name: Commit the POT file to Git run: | git_hash=$(git rev-parse --short "${GITHUB_SHA}") - git commit -m "Update messages.pot as of version ${git_hash}" locales/messages.pot - - - name: Check if any sources have changed since the last update - if: failure() - run: echo "There are no changes to the RST sources since the last update. Nothing to do." + git commit \ + -m "Update messages.pot as of version ${git_hash}" \ + locales/messages.pot - name: >- - Push the updated POT file back to - ${{ github.repository }}@${{ github.event.repository.default_branch }} - on GitHub + Push the updated POT file back to '${{ env.I18N_BRANCH }}' + branch on GitHub run: | - git push --atomic origin HEAD:${{ github.event.repository.default_branch }} + git push --atomic origin 'HEAD:${{ env.I18N_BRANCH }}' From 10c4e62b6005576a28dc84b64b99f572e397e491 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Sat, 27 Nov 2021 19:24:35 +0100 Subject: [PATCH 0207/1072] Drop the tracked `locales/messages.pot` file --- locales/messages.pot | 9254 ------------------------------------------ 1 file changed, 9254 deletions(-) delete mode 100644 locales/messages.pot diff --git a/locales/messages.pot b/locales/messages.pot deleted file mode 100644 index 5ea4b3276..000000000 --- a/locales/messages.pot +++ /dev/null @@ -1,9254 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2013–2020, PyPA -# This file is distributed under the same license as the Python Packaging User Guide package. -# FIRST AUTHOR , YEAR. -# -#, fuzzy -msgid "" -msgstr "" -"Project-Id-Version: Python Packaging User Guide \n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=UTF-8\n" -"Content-Transfer-Encoding: 8bit\n" - -#: ../source/contribute.rst:5 -msgid "Contribute to this guide" -msgstr "" - -#: ../source/contribute.rst:7 -msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" -msgstr "" - -#: ../source/contribute.rst:10 -msgid "Reading the guide and giving feedback" -msgstr "" - -#: ../source/contribute.rst:11 -msgid "Reviewing new contributions" -msgstr "" - -#: ../source/contribute.rst:12 -msgid "Revising existing content" -msgstr "" - -#: ../source/contribute.rst:13 -msgid "Writing new content" -msgstr "" - -#: ../source/contribute.rst:15 -msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." -msgstr "" - -#: ../source/contribute.rst:24 -msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." -msgstr "" - -#: ../source/contribute.rst:31 -msgid "Documentation types" -msgstr "" - -#: ../source/contribute.rst:33 -msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." -msgstr "" - -#: ../source/contribute.rst:38 -#: ../source/tutorials/index.rst:2 -msgid "Tutorials" -msgstr "" - -#: ../source/contribute.rst:40 -msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." -msgstr "" - -#: ../source/contribute.rst:47 -#: ../source/guides/index.rst:2 -msgid "Guides" -msgstr "" - -#: ../source/contribute.rst:49 -msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." -msgstr "" - -#: ../source/contribute.rst:56 -#: ../source/discussions/index.rst:2 -msgid "Discussions" -msgstr "" - -#: ../source/contribute.rst:58 -msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." -msgstr "" - -#: ../source/contribute.rst:63 -msgid "Specifications" -msgstr "" - -#: ../source/contribute.rst:65 -msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." -msgstr "" - -#: ../source/contribute.rst:73 -msgid "Building the guide locally" -msgstr "" - -#: ../source/contribute.rst:75 -msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" -msgstr "" - -#: ../source/contribute.rst:79 -msgid "`Nox `_. You can install or upgrade nox using ``pip``::" -msgstr "" - -#: ../source/contribute.rst:84 -msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." -msgstr "" - -#: ../source/contribute.rst:91 -msgid "To build the guide, run the following bash command in the source folder::" -msgstr "" - -#: ../source/contribute.rst:95 -msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." -msgstr "" - -#: ../source/contribute.rst:100 -msgid "You can build the guide and serve it via an HTTP server using the following command::" -msgstr "" - -#: ../source/contribute.rst:105 -msgid "The guide will be browsable via http://localhost:8000." -msgstr "" - -#: ../source/contribute.rst:109 -msgid "Where the guide is deployed" -msgstr "" - -#: ../source/contribute.rst:111 -msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." -msgstr "" - -#: ../source/contribute.rst:117 -msgid "Style guide" -msgstr "" - -#: ../source/contribute.rst:119 -msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." -msgstr "" - -#: ../source/contribute.rst:126 -msgid "Purpose" -msgstr "" - -#: ../source/contribute.rst:128 -msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." -msgstr "" - -#: ../source/contribute.rst:133 -msgid "Scope" -msgstr "" - -#: ../source/contribute.rst:135 -msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." -msgstr "" - -#: ../source/contribute.rst:138 -msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." -msgstr "" - -#: ../source/contribute.rst:146 -msgid "Audience" -msgstr "" - -#: ../source/contribute.rst:148 -msgid "The audience of this guide is anyone who uses Python with packages." -msgstr "" - -#: ../source/contribute.rst:150 -msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." -msgstr "" - -#: ../source/contribute.rst:154 -msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." -msgstr "" - -#: ../source/contribute.rst:160 -msgid "Voice and tone" -msgstr "" - -#: ../source/contribute.rst:162 -msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." -msgstr "" - -#: ../source/contribute.rst:165 -msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." -msgstr "" - -#: ../source/contribute.rst:170 -msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." -msgstr "" - -#: ../source/contribute.rst:177 -msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." -msgstr "" - -#: ../source/contribute.rst:184 -msgid "Conventions and mechanics" -msgstr "" - -#: ../source/contribute.rst:192 -msgid "**Write to the reader**" -msgstr "" - -#: ../source/contribute.rst:187 -msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: To install it, the user runs…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: You can install it by running…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: To install it, run…" -msgstr "" - -#: ../source/contribute.rst:198 -msgid "**State assumptions**" -msgstr "" - -#: ../source/contribute.rst:195 -msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." -msgstr "" - -#: ../source/contribute.rst:203 -msgid "**Cross-reference generously**" -msgstr "" - -#: ../source/contribute.rst:201 -msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." -msgstr "" - -#: ../source/contribute.rst:213 -msgid "**Respect naming practices**" -msgstr "" - -#: ../source/contribute.rst:206 -msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: Pip uses…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: pip uses…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: …hosted on github." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: …hosted on GitHub." -msgstr "" - -#: ../source/contribute.rst:222 -msgid "**Use a gender-neutral style**" -msgstr "" - -#: ../source/contribute.rst:216 -msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: A maintainer uploads the file. Then he…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then they…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then the maintainer…" -msgstr "" - -#: ../source/contribute.rst:234 -msgid "**Headings**" -msgstr "" - -#: ../source/contribute.rst:225 -msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." -msgstr "" - -#: ../source/contribute.rst:230 -msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: Things You Should Know About Python" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: Things you should know about Python" -msgstr "" - -#: ../source/contribute.rst:237 -msgid "**Numbers**" -msgstr "" - -#: ../source/contribute.rst:237 -msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:4 -msgid "Deploying Python applications" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Page Status" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:6 -#: ../source/guides/index-mirrors-and-caches.rst:7 -#: ../source/guides/installing-using-linux-tools.rst:7 -#: ../source/guides/packaging-binary-extensions.rst:7 -#: ../source/guides/supporting-multiple-python-versions.rst:7 -#: ../source/guides/supporting-windows-using-appveyor.rst:5 -msgid "Incomplete" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Last Reviewed" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:7 -msgid "2014-11-11" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:11 -#: ../source/discussions/install-requires-vs-requirements.rst:9 -#: ../source/guides/analyzing-pypi-package-downloads.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:22 -#: ../source/guides/index-mirrors-and-caches.rst:12 -#: ../source/guides/installing-scientific-packages.rst:9 -#: ../source/guides/packaging-binary-extensions.rst:17 -#: ../source/guides/supporting-multiple-python-versions.rst:12 -#: ../source/guides/supporting-windows-using-appveyor.rst:15 -#: ../source/overview.rst:23 -#: ../source/specifications/core-metadata.rst:38 -#: ../source/specifications/direct-url.rst:14 -#: ../source/tutorials/installing-packages.rst:23 -msgid "Contents" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:14 -msgid "Overview" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:18 -msgid "Supporting multiple hardware platforms" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:40 -msgid "OS packaging & installers" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:52 -msgid "Windows" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:61 -msgid "Pynsist" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:63 -msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:70 -msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:74 -msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:80 -msgid "Application bundles" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:91 -msgid "Configuration management" -msgstr "" - -#: ../source/discussions/index.rst:4 -msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:5 -msgid "install_requires vs requirements files" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:382 -msgid "install_requires" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:14 -msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:19 -msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:29 -msgid "Additionally, it's best practice to indicate any known lower or upper bounds." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:31 -msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:41 -msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:51 -msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:56 -msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:64 -#: ../source/tutorials/installing-packages.rst:460 -msgid "Requirements files" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:66 -msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:69 -msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:73 -msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:78 -msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:84 -msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:90 -msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:6 -msgid "pip vs easy_install" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:9 -msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:14 -msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:22 -msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**pip**" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**easy_install**" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -msgid "Installs from :term:`Wheels `" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Yes" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:30 -#: ../source/discussions/pip-vs-easy-install.rst:32 -#: ../source/discussions/pip-vs-easy-install.rst:35 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:51 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "No" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Uninstall Packages" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Yes (``python -m pip uninstall``)" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Dependency Overrides" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Yes (:ref:`Requirements Files `)" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "List Installed Packages" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:38 -msgid ":pep:`438` Support" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Installation format" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "'Flat' packages with :file:`egg-info` metadata." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Encapsulated Egg format" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:44 -msgid "sys.path modification" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:48 -msgid "Installs from :term:`Eggs `" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "`pylauncher support`_" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "Yes [1]_" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:54 -msgid ":ref:`Multi-version Installs`" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Exclude scripts during install" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "per project index" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Only in virtualenv" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Yes, via setup.cfg" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:68 -msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:5 -msgid "Wheel vs Egg" -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:7 -msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:11 -msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:14 -msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:17 -msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:20 -msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:22 -msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:26 -msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:31 -msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:34 -msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:38 -msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:41 -msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:47 -msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." -msgstr "" - -#: ../source/glossary.rst:3 -msgid "Glossary" -msgstr "" - -#: ../source/glossary.rst:8 -msgid "Binary Distribution" -msgstr "" - -#: ../source/glossary.rst:11 -msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." -msgstr "" - -#: ../source/glossary.rst:14 -msgid "Built Distribution" -msgstr "" - -#: ../source/glossary.rst:17 -msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." -msgstr "" - -#: ../source/glossary.rst:26 -msgid "Distribution Package" -msgstr "" - -#: ../source/glossary.rst:29 -msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." -msgstr "" - -#: ../source/glossary.rst:34 -msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." -msgstr "" - -#: ../source/glossary.rst:41 -msgid "Egg" -msgstr "" - -#: ../source/glossary.rst:44 -msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" -msgstr "" - -#: ../source/glossary.rst:49 -msgid "Extension Module" -msgstr "" - -#: ../source/glossary.rst:52 -msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." -msgstr "" - -#: ../source/glossary.rst:59 -msgid "Known Good Set (KGS)" -msgstr "" - -#: ../source/glossary.rst:62 -msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." -msgstr "" - -#: ../source/glossary.rst:68 -msgid "Import Package" -msgstr "" - -#: ../source/glossary.rst:71 -msgid "A Python module which can contain other modules or recursively, other packages." -msgstr "" - -#: ../source/glossary.rst:74 -msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." -msgstr "" - -#: ../source/glossary.rst:78 -msgid "Module" -msgstr "" - -#: ../source/glossary.rst:81 -msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." -msgstr "" - -#: ../source/glossary.rst:84 -msgid "Package Index" -msgstr "" - -#: ../source/glossary.rst:87 -msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." -msgstr "" - -#: ../source/glossary.rst:90 -msgid "Per Project Index" -msgstr "" - -#: ../source/glossary.rst:93 -msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." -msgstr "" - -#: ../source/glossary.rst:97 -msgid "Project" -msgstr "" - -#: ../source/glossary.rst:100 -msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." -msgstr "" - -#: ../source/glossary.rst:104 -msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." -msgstr "" - -#: ../source/glossary.rst:110 -msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." -msgstr "" - -#: ../source/glossary.rst:115 -msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." -msgstr "" - -#: ../source/glossary.rst:121 -msgid "Pure Module" -msgstr "" - -#: ../source/glossary.rst:124 -msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." -msgstr "" - -#: ../source/glossary.rst:127 -msgid "Python Packaging Authority (PyPA)" -msgstr "" - -#: ../source/glossary.rst:130 -msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." -msgstr "" - -#: ../source/glossary.rst:139 -msgid "Python Package Index (PyPI)" -msgstr "" - -#: ../source/glossary.rst:142 -msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." -msgstr "" - -#: ../source/glossary.rst:145 -msgid "pypi.org" -msgstr "" - -#: ../source/glossary.rst:148 -msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." -msgstr "" - -#: ../source/glossary.rst:152 -msgid "pyproject.toml" -msgstr "" - -#: ../source/glossary.rst:155 -msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." -msgstr "" - -#: ../source/glossary.rst:157 -msgid "Release" -msgstr "" - -#: ../source/glossary.rst:160 -msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." -msgstr "" - -#: ../source/glossary.rst:163 -msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." -msgstr "" - -#: ../source/glossary.rst:168 -msgid "Requirement" -msgstr "" - -#: ../source/glossary.rst:171 -msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." -msgstr "" - -#: ../source/glossary.rst:177 -msgid "Requirement Specifier" -msgstr "" - -#: ../source/glossary.rst:180 -msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" -msgstr "" - -#: ../source/glossary.rst:187 -msgid "Requirements File" -msgstr "" - -#: ../source/glossary.rst:190 -msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." -msgstr "" - -#: ../source/glossary.rst:194 -#: ../source/guides/distributing-packages-using-setuptools.rst:56 -msgid "setup.py" -msgstr "" - -#: ../source/glossary.rst:195 -#: ../source/guides/distributing-packages-using-setuptools.rst:77 -msgid "setup.cfg" -msgstr "" - -#: ../source/glossary.rst:198 -msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." -msgstr "" - -#: ../source/glossary.rst:201 -msgid "Source Archive" -msgstr "" - -#: ../source/glossary.rst:204 -msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:208 -msgid "Source Distribution (or \"sdist\")" -msgstr "" - -#: ../source/glossary.rst:211 -msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:216 -msgid "System Package" -msgstr "" - -#: ../source/glossary.rst:219 -msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." -msgstr "" - -#: ../source/glossary.rst:222 -msgid "Version Specifier" -msgstr "" - -#: ../source/glossary.rst:225 -msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." -msgstr "" - -#: ../source/glossary.rst:231 -msgid "Virtual Environment" -msgstr "" - -#: ../source/glossary.rst:234 -msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/glossary.rst:238 -msgid "Wheel" -msgstr "" - -#: ../source/glossary.rst:241 -msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." -msgstr "" - -#: ../source/glossary.rst:244 -msgid "Working Set" -msgstr "" - -#: ../source/glossary.rst:247 -msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:3 -msgid "Analyzing PyPI package downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:5 -msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:15 -#: ../source/guides/supporting-windows-using-appveyor.rst:18 -msgid "Background" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:17 -msgid "PyPI does not display download statistics for a number of reasons: [#]_" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:19 -msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:24 -msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:27 -msgid "``pip``'s download cache (lowers download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:28 -msgid "Internal or unofficial mirrors (can both raise or lower download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:29 -msgid "Packages not hosted on PyPI (for comparisons sake)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:30 -msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:32 -msgid "Known historical data quality issues (lowers download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:34 -msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:38 -msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:43 -msgid "Public dataset" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:45 -msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:50 -msgid "Getting set up" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:52 -msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:58 -msgid "Navigate to the `BigQuery web UI`_." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:59 -msgid "Create a new project." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:60 -msgid "Enable the `BigQuery API `__." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:63 -msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:69 -msgid "Data schema" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:71 -msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -msgid "Column" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/guides/using-manifest-in.rst:67 -#: ../source/specifications/core-metadata.rst:185 -msgid "Description" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/specifications/direct-url.rst:226 -msgid "Examples" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "timestamp" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "Date and time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "``2020-03-09 00:33:03 UTC``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "file.project" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "Project name" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "``pipenv``, ``nose``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "file.version" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "Package version" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "``0.1.6``, ``1.4.2``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "details.installer.name" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "Installer" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "pip, `bandersnatch`_" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "details.python" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "Python version" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "``2.7.12``, ``3.6.4``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:93 -msgid "Useful queries" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:95 -msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:97 -msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:102 -msgid "Counting package downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:104 -msgid "The following query counts the total number of downloads for the project \"pytest\"." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:119 -#: ../source/guides/analyzing-pypi-package-downloads.rst:140 -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "num_downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:121 -msgid "26190085" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:124 -msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:142 -msgid "24334215" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:146 -msgid "Package downloads over time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:148 -msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -msgid "month" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "1956741" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "2018-01-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2344692" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2017-12-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "1730398" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "2017-11-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2047310" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2017-10-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "1744443" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "2017-09-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "1916952" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "2017-08-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:184 -msgid "Python versions over time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:186 -msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "python" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "3.7" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "18051328726" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "3.6" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "9635067203" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "3.8" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "7781904681" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "2.7" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "6381252241" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "null" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "2026630299" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "3.5" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "1894153540" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:221 -msgid "Caveats" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:223 -msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:231 -msgid "Additional tools" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:233 -msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:237 -msgid "``google-cloud-bigquery``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:239 -msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:267 -msgid "``pypinfo``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:269 -msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:273 -msgid "Install `pypinfo`_ using pip." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:279 -msgid "Usage:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:295 -msgid "``pandas-gbq``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:297 -msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:301 -#: ../source/specifications/binary-distribution-format.rst:459 -msgid "References" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:303 -msgid "`PyPI Download Counts deprecation email `__" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:304 -msgid "`PyPI BigQuery dataset announcement email `__" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:3 -msgid "Creating and discovering plugins" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:5 -msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:10 -msgid "There are three major approaches to doing automatic plugin discovery:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:12 -msgid "`Using naming convention`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:13 -msgid "`Using namespace packages`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:14 -msgid "`Using package metadata`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:18 -msgid "Using naming convention" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:20 -msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:38 -msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:48 -msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:59 -msgid "Using namespace packages" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:61 -msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:89 -msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:101 -msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:115 -msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:121 -msgid "Using package metadata" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:123 -msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:128 -msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:139 -msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:154 -msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:163 -msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:166 -msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:170 -msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:5 -msgid "Packaging and distributing projects" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:7 -msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:11 -msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:15 -msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:25 -msgid "Requirements for packaging and distributing" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:26 -msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:29 -msgid "Install \"twine\" [1]_:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:43 -msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:49 -msgid "Configuring your project" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:53 -msgid "Initial files" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:58 -msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:63 -msgid ":file:`setup.py` serves two primary functions:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:65 -msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:71 -msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:79 -msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:86 -msgid "README.rst / README.md" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:88 -msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:95 -msgid "For an example, see `README.md `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:99 -msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:108 -msgid "MANIFEST.in" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:110 -msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:115 -msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:119 -msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:122 -msgid "LICENSE.txt" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:124 -msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:130 -msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:135 -msgid "" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:137 -msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:141 -msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:149 -msgid "setup() args" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:151 -msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:155 -msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:164 -msgid "name" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:170 -msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:174 -msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:176 -msgid "Start & end with an ASCII letter or digit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:178 -msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:190 -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "version" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:196 -msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:200 -msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:203 -msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:206 -msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:214 -msgid "description" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:222 -msgid "Give a short and long description for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:224 -msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:229 -msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:235 -msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:245 -msgid "url" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:252 -msgid "Give a homepage URL for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:256 -msgid "author" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:263 -msgid "Provide details about the author." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:267 -msgid "license" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:273 -msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:279 -msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:287 -msgid "classifiers" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:316 -msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:319 -msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:327 -msgid "keywords" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:333 -msgid "List keywords that describe your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:337 -msgid "project_urls" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:349 -msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:355 -msgid "packages" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:361 -msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:370 -msgid "py_modules" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:376 -msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:388 -msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:392 -msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:398 -msgid "python_requires" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:400 -msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:407 -msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:412 -msgid "And so on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:416 -msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:422 -msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:431 -msgid "package_data" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:440 -msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:445 -msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:449 -msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:457 -msgid "data_files" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:463 -msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:469 -msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:479 -msgid "For more information see the distutils section on `Installing Additional Files `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:484 -msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:491 -msgid "scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:493 -msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:500 -msgid "entry_points" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:509 -msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:512 -msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:516 -msgid "The most commonly used entry point is \"console_scripts\" (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:521 -msgid "console_scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:531 -msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:538 -msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:545 -msgid "Choosing a versioning scheme" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:548 -msgid "Standards compliance for interoperability" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:550 -msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:556 -msgid "Here are some examples of compliant version numbers::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:567 -msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:573 -msgid "Scheme choices" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:576 -msgid "Semantic versioning (preferred)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:578 -msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:582 -msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:585 -msgid "MAJOR version when they make incompatible API changes," -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:586 -msgid "MINOR version when they add functionality in a backwards-compatible manner, and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:587 -msgid "MAINTENANCE version when they make backwards-compatible bug fixes." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:589 -msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:594 -msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:598 -msgid "Date based versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:600 -msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:604 -msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:607 -msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:611 -msgid "Serial versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:613 -msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:616 -msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:621 -msgid "Hybrid schemes" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:623 -msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:629 -msgid "Pre-release versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:631 -msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:634 -msgid "zero or more dev releases (denoted with a \".devN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:635 -msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:636 -msgid "zero or more beta releases (denoted with a \".bN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:637 -msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:639 -msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:644 -msgid "Local version identifiers" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:646 -msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:653 -msgid "A local version identifier takes the form ``+``. For example::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:661 -msgid "Working in \"development mode\"" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:663 -msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:667 -msgid "Assuming you're in the root of your project directory, then run:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:674 -msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:680 -msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:688 -msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:692 -msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:697 -msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:701 -msgid "Lastly, if you don't want to install any dependencies at all, you can run::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:706 -msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:713 -msgid "Packaging your project" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:715 -msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:720 -msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:737 -msgid "Source distributions" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:739 -msgid "Minimally, you should create a :term:`Source Distribution `:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:755 -msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:763 -msgid "Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:765 -msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:770 -msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:773 -msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:776 -msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:785 -msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:792 -msgid "Pure Python Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:794 -msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:797 -#: ../source/guides/distributing-packages-using-setuptools.rst:826 -msgid "To build the wheel:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:811 -msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:815 -msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:821 -msgid "Platform Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:823 -msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:841 -msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:847 -msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:855 -msgid "Uploading your Project to PyPI" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:857 -msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:861 -msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:866 -msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:871 -msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:877 -msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:888 -msgid "Create an account" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:890 -msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:894 -msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:897 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:901 -msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:904 -msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:913 -msgid "**Be aware that this stores your token in plaintext.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:915 -#: ../source/guides/migrating-to-pypi-org.rst:70 -#: ../source/guides/migrating-to-pypi-org.rst:109 -#: ../source/guides/using-testpypi.rst:83 -msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:921 -msgid "Upload your distributions" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:923 -msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:926 -msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:930 -msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:937 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:944 -#: ../source/tutorials/installing-packages.rst:663 -msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:950 -msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:5 -msgid "Dropping support for older Python versions" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:7 -msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:9 -msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:12 -msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:14 -msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:17 -msgid "Requirements" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:19 -msgid "This workflow requires that:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:21 -msgid "The publisher is using the latest version of :ref:`setuptools`," -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:22 -msgid "The latest version of :ref:`twine` is used to upload the package," -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:23 -msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:26 -msgid "Dealing with the universal wheels" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:28 -msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:36 -msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:48 -msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:53 -msgid "Defining the Python version required" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:56 -msgid "1. Download the newest version of Setuptools" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:58 -msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:60 -msgid "Steps:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:74 -msgid "`setuptools` version should be above 24.0.0." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:77 -msgid "2. Specify the version ranges for supported Python distributions" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:79 -msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:81 -#: ../source/specifications/core-metadata.rst:139 -#: ../source/specifications/core-metadata.rst:463 -#: ../source/specifications/core-metadata.rst:487 -#: ../source/specifications/core-metadata.rst:527 -#: ../source/specifications/core-metadata.rst:550 -#: ../source/specifications/core-metadata.rst:583 -#: ../source/specifications/core-metadata.rst:693 -#: ../source/specifications/core-metadata.rst:722 -msgid "Examples::" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:86 -msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:101 -msgid "3. Validating the Metadata before publishing" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:103 -msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:105 -msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:108 -msgid "You can see the contents of the generated file like this::" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:112 -msgid "Validate that the following is in place, before publishing the package:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:114 -msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:115 -msgid "The Requires-Python field is set and matches your specification in setup.py." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:118 -msgid "4. Using Twine to publish" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:120 -msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:122 -msgid "Make sure you are using the newest version of Twine, at least 1.9." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:125 -msgid "Dropping a Python release" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:127 -msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:129 -msgid "It must be done in this order for the automated fallback to work." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:131 -msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:133 -msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:5 -msgid "Hosting your own simple repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:8 -msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:13 -msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:29 -msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:35 -msgid "\"Manual\" repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:37 -msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:51 -msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:58 -msgid "For complete documentation of the simple repository protocol, see :pep:`503`." -msgstr "" - -#: ../source/guides/index.rst:8 -#: ../source/guides/index.rst:8 -msgid "Installing Packages:" -msgstr "" - -#: ../source/guides/index.rst:20 -#: ../source/guides/index.rst:20 -msgid "Building and Publishing Projects:" -msgstr "" - -#: ../source/guides/index.rst:38 -#: ../source/guides/index.rst:38 -msgid "Miscellaneous:" -msgstr "" - -#: ../source/guides/index.rst:4 -msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:5 -msgid "Package index mirrors and caches" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:8 -#: ../source/guides/supporting-multiple-python-versions.rst:8 -msgid "2014-12-24" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:14 -msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:17 -msgid "Three options are available in this area:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:19 -msgid "pip provides local caching options," -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:20 -msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:22 -msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:27 -msgid "Caching with pip" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:29 -msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:32 -msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:36 -msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:45 -msgid "Caching with devpi" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:47 -msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:55 -msgid "Complete mirror with bandersnatch" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:57 -msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:63 -msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:5 -msgid "Installing scientific packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:11 -msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:16 -msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:22 -msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:29 -msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:35 -msgid "Building from source" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:37 -msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:45 -msgid "Linux distribution packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:47 -msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:51 -msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:57 -msgid "Windows installers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:59 -msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:64 -msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:67 -msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:73 -msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:79 -msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:86 -msgid "macOS installers and package managers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:88 -msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:92 -msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:99 -msgid "SciPy distributions" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:101 -msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:105 -msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:109 -#: ../source/key_projects.rst:596 -msgid "Spack" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:110 -msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:119 -msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:128 -msgid "The conda cross-platform package manager" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:130 -msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:136 -msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 -msgid "Installing stand alone command line tools" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 -msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 -msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 -msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 -msgid "pipx only works with Python 3.6+." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 -msgid "``pipx`` is installed with ``pip``:" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 -msgid "You may need to restart your terminal for the path updates to take effect." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 -msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 -#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 -msgid "For example" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 -msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 -msgid "To upgrade or uninstall the package" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 -msgid "``pipx`` can be upgraded or uninstalled with pip" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 -msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 -msgid "To see the full list of commands ``pipx`` offers, run" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 -msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:5 -msgid "Installing pip/setuptools/wheel with Linux Package Managers" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:8 -msgid "2015-09-17" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:11 -msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:14 -msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:18 -msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:25 -msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:32 -msgid "Fedora" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:34 -msgid "Fedora 21:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:36 -#: ../source/guides/installing-using-linux-tools.rst:45 -#: ../source/guides/installing-using-linux-tools.rst:124 -#: ../source/guides/installing-using-linux-tools.rst:138 -#: ../source/guides/installing-using-linux-tools.rst:158 -msgid "Python 2::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:41 -msgid "Python 3: ``sudo yum install python3 python3-wheel``" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:43 -msgid "Fedora 22:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:50 -msgid "Python 3: ``sudo dnf install python3 python3-wheel``" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:53 -msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:63 -msgid "CentOS/RHEL" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:65 -msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:68 -msgid "To install pip and wheel for the system Python, there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:70 -msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:77 -msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:81 -msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:85 -msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:92 -msgid "To additionally upgrade setuptools, run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:97 -msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:101 -msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:104 -msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:106 -msgid "For CentOS, see here: https://www.softwarecollections.org/en/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:108 -msgid "Be aware that collections may not contain the most recent versions." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:110 -msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:116 -msgid "For example, for Python 3.4 on CentOS7/RHEL7::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:122 -msgid "openSUSE" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:129 -#: ../source/guides/installing-using-linux-tools.rst:143 -#: ../source/guides/installing-using-linux-tools.rst:162 -msgid "Python 3::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:135 -msgid "Debian/Ubuntu" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:150 -msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:156 -msgid "Arch Linux" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:168 -msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 -msgid "Installing packages using pip and virtual environments" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 -msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 -msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 -msgid "Installing pip" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 -msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 -msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 -msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 -msgid "Afterwards, you should have the newest pip installed in your user site:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 -msgid "The Python installers for Windows include pip. You should be able to access pip using:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 -msgid "You can make sure that pip is up-to-date by running:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 -msgid "Installing virtualenv" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 -msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 -msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 -msgid "Creating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 -msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 -msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 -msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 -msgid "venv will create a virtual Python installation in the ``env`` folder." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 -msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 -msgid "Activating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 -msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 -msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 -msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 -msgid "Leaving the virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 -msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 -msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 -msgid "Installing packages" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 -msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 -msgid "pip should download requests and all of its dependencies and install them:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 -msgid "Installing specific versions" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 -msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 -msgid "To install the latest ``2.x`` release of requests:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 -msgid "To install pre-release versions of packages, use the ``--pre`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 -msgid "Installing extras" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 -msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 -msgid "Installing from source" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 -msgid "pip can install a package directly from source, for example:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 -msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 -msgid "Installing from version control systems" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 -msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 -msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 -#: ../source/tutorials/installing-packages.rst:569 -msgid "Installing from local archives" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 -msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 -msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 -msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 -msgid "Using other package indexes" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 -msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 -msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 -#: ../source/tutorials/installing-packages.rst:389 -msgid "Upgrading packages" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 -msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 -msgid "Using requirements files" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 -msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 -msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 -msgid "Freezing dependencies" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 -msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 -msgid "Which will output a list of package specifiers such as:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 -msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:2 -msgid "Making a PyPI-friendly README" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:4 -msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:9 -msgid "Creating a README file" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:11 -msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:13 -msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:16 -msgid "plain text" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:17 -msgid "`reStructuredText `_ (without Sphinx extensions)" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:18 -msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:21 -msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:25 -msgid "Including your README in your package's metadata" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:27 -msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:33 -msgid ":ref:`description-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:34 -msgid ":ref:`description-content-type-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:36 -msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:39 -msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:45 -msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:60 -msgid "The minimum required versions of the respective tools are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:62 -msgid "``setuptools >= 38.6.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:63 -msgid "``wheel >= 0.31.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:64 -msgid "``twine >= 1.11.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:66 -msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:72 -msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:95 -msgid "Validating reStructuredText markup" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:97 -msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:100 -msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:105 -msgid "You can check your README for markup errors before uploading as follows:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:107 -msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:122 -msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:125 -msgid "Run ``twine check`` on the sdist and wheel::" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:129 -msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:4 -msgid "Migrating to PyPI.org" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:6 -msgid ":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``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:12 -msgid "Publishing releases" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:14 -msgid "``pypi.org`` is the default upload platform as of September 2016." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:16 -msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:19 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:22 -msgid "The default upload settings switched to ``pypi.org`` in the following versions:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:24 -msgid "``twine`` 1.8.0" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:25 -msgid "``setuptools`` 27.0.0" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:26 -msgid "Python 2.7.13 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:27 -msgid "Python 3.4.6 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:28 -msgid "Python 3.5.3 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:29 -msgid "Python 3.6.0 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:31 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:48 -msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:51 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:67 -msgid "(``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.)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:73 -msgid "Registering package names & metadata" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:75 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:79 -msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:84 -msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:89 -#: ../source/guides/using-testpypi.rst:5 -msgid "Using TestPyPI" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:91 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:113 -msgid "Registering new user accounts" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:115 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:121 -msgid "Browsing packages" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:123 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:130 -msgid "Downloading packages" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:132 -msgid "``pypi.org`` is the default host for downloading packages." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:135 -msgid "Managing published packages and releases" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:137 -msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:5 -msgid "Multi-version installs" -msgstr "" - -#: ../source/guides/multi-version-installs.rst:8 -msgid "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``)." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:13 -msgid "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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:19 -msgid "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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:31 -msgid "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 ``python -c ''`` to invoke the application's main entry point directly." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:38 -msgid "Refer to the `pkg_resources documentation `__ for more details." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:5 -msgid "Packaging binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:8 -msgid "2013-12-08" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:10 -msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:20 -msgid "An overview of binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:23 -msgid "Use cases" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:25 -msgid "The typical use cases for binary extensions break down into just three conventional categories:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:28 -msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:39 -msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:47 -msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:56 -msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:61 -msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:71 -msgid "Disadvantages" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:73 -msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:80 -msgid "This means that binary extensions:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:82 -msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:85 -msgid "may not be compatible with different builds of the CPython reference interpreter" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:88 -msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:91 -msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:96 -msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:101 -msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:108 -msgid "Alternatives to handcoded accelerator modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:110 -msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:115 -msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:122 -msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:132 -msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:141 -msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:150 -msgid "Alternatives to handcoded wrapper modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:152 -msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:158 -msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:162 -msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:168 -msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:175 -msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:181 -msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:185 -msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:189 -msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:203 -msgid "Alternatives for low level system access" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:205 -msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:213 -msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:222 -msgid "Implementing binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:224 -msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:241 -msgid "Building binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:244 -msgid "Building extensions for multiple platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:246 -msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:256 -msgid "Binary extensions for Windows" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:258 -msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:263 -msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:269 -msgid "To set up a build environment for binary extensions, the steps are as follows:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:271 -msgid "For Python 2.7" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:273 -msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:276 -msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:278 -#: ../source/guides/packaging-binary-extensions.rst:288 -#: ../source/guides/packaging-binary-extensions.rst:295 -msgid "Done." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:280 -msgid "For Python 3.4" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:282 -msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:285 -msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:287 -msgid "Set DISTUTILS_USE_SDK=1" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:290 -msgid "For Python 3.5" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:292 -msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:297 -msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:301 -msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:305 -msgid "Binary extensions for Linux" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:307 -msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:313 -msgid "Binary extensions for macOS" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:315 -msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:325 -msgid "Publishing binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:327 -msgid "For interim guidance on this topic, see the discussion in `this issue `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:343 -msgid "Additional resources" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:345 -msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:352 -msgid "Cross-platform wheel generation with scikit-build" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:354 -msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:362 -msgid "Introduction to C/C++ extension modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:364 -msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:367 -msgid "`What are (c)python extension modules? `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:368 -msgid "`Releasing the gil `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:369 -msgid "`Writing cpython extension modules using C++ `_" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:3 -msgid "Packaging namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:5 -msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:24 -msgid "And you use this package in your code like so::" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:29 -msgid "Then you can break these sub-packages into two separate distributions:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:46 -msgid "Each sub-package can now be separately installed, used, and versioned." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:48 -msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:58 -msgid "Creating a namespace package" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:60 -msgid "There are currently three different approaches to creating namespace packages:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:62 -msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:66 -msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:69 -msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:73 -msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:80 -msgid "Native namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:82 -msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:97 -msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:102 -msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:117 -msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:123 -msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:129 -msgid "pkgutil-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:131 -msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:136 -msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:148 -#: ../source/guides/packaging-namespace-packages.rst:194 -msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:155 -#: ../source/guides/packaging-namespace-packages.rst:201 -msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:160 -msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:171 -msgid "pkg_resources-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:173 -msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:182 -msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:206 -msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:216 -msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:223 -msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:237 -msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 -msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 -msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 -msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 -msgid "Saving credentials on GitHub" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 -msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 -msgid "Let's begin! 🚀" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 -msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 -msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 -msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 -msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 -msgid "Creating a workflow definition" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 -msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 -msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 -msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 -msgid "Defining a workflow job environment" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 -msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 -msgid "Checking out the project and building distributions" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 -msgid "Then, add the following under the ``build-n-publish`` section:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 -msgid "This will download your repository into the CI runner and then install and activate Python 3.7." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 -msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 -msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 -msgid "So add this to the steps list:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 -msgid "Publishing the distribution to PyPI and TestPyPI" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 -msgid "Finally, add the following steps at the end:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 -msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 -msgid "That's all, folks!" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 -msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:5 -msgid "Single-sourcing the package version" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:8 -msgid "There are many techniques to maintain a single source of truth for the version number of your project:" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:11 -msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:38 -msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:47 -msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:52 -msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:55 -msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:58 -msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:65 -msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:76 -msgid "Example using this technique: `warehouse `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:78 -msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:86 -msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:91 -msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:95 -msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:110 -msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:114 -msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:128 -msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:134 -msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:138 -msgid "Example using this technique: `setuptools `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:141 -msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:155 -msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:161 -msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:5 -msgid "Supporting multiple Python versions" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:37 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:43 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:49 -msgid "Automated testing and continuous integration" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:51 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:56 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:60 -msgid "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:" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:66 -msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:69 -msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:80 -msgid "Both `Travis CI`_ 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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:85 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:89 -msgid "Tools for single-source Python packages" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:91 -msgid "`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_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:100 -msgid "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" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:107 -msgid "a Python 2 (by syntax) module in a Python 3 project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:108 -msgid "a Python 3 (by syntax) module in a *Python 2* project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:110 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:117 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:124 -msgid "What's in which Python?" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:126 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:3 -msgid "Supporting Windows using Appveyor" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:6 -msgid "2015-12-03" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:8 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:20 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:24 -msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:30 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:38 -msgid "Setting up" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:40 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:45 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:49 -msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:54 -msgid "Adding Appveyor support to your project" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:56 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:61 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:69 -msgid "appveyor.yml" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:75 -msgid "This file can be downloaded from `here `__." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:77 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:80 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:88 -msgid "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``)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:94 -msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:97 -msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:100 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:109 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:114 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:119 -msgid "Support script" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:121 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:126 -msgid "`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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:133 -msgid "You can simply download the batch file and include it in your project unchanged." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:137 -msgid "Access to the built wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:139 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:147 -msgid "Additional notes" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:150 -msgid "Testing with tox" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:152 -msgid "Many projects use the `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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:156 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:160 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:165 -msgid "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" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:170 -msgid "``DISTUTILS_USE_SDK``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:171 -msgid "``MSSdk``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:172 -msgid "``INCLUDE``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:173 -msgid "``LIB``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:175 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:181 -msgid "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 Travis or 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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:188 -msgid "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``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:192 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:197 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:203 -msgid "Automatically uploading wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:205 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:210 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:216 -msgid "External dependencies" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:218 -msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:221 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:230 -msgid "Support scripts" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:232 -msgid "For reference, the SDK setup support script is listed here:" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:234 -msgid "``appveyor-sample/build.cmd``" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:5 -msgid "Tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:7 -msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:12 -msgid "Application dependency management" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:14 -msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:18 -msgid "When ``pipenv`` does not meet your use case, consider other tools like:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:20 -msgid ":ref:`pip`" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:22 -msgid "`pip-tools `_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:24 -msgid "`Poetry `_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:27 -msgid "Installation tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:29 -msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:34 -msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:37 -msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:40 -msgid ":ref:`buildout`: primarily focused on the web development community" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:42 -msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:47 -msgid "Packaging tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:49 -msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:52 -msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:56 -msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:61 -msgid "Publishing platform migration" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:63 -msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:67 -msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:72 -msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:77 -msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:82 -msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:88 -msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:93 -msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:102 -msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:107 -msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:5 -msgid "Including files in source distributions with ``MANIFEST.in``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:7 -msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:17 -msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:22 -msgid "How files are included in an sdist" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:24 -msgid "The following files are included in a source distribution by default:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:26 -msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:28 -msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:30 -msgid "scripts specified by the ``scripts`` ``setup()`` argument" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:31 -msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:33 -msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:35 -msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:37 -msgid "all files matching the pattern :file:`test/test*.py`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:38 -msgid ":file:`setup.py` (or whatever you called your setup script)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:39 -msgid ":file:`setup.cfg`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:40 -msgid ":file:`README`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:41 -msgid ":file:`README.txt`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:42 -msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:43 -msgid ":file:`README.md` (setuptools 36.4.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:44 -msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:45 -msgid ":file:`MANIFEST.in`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:47 -msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:52 -msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:60 -msgid ":file:`MANIFEST.in` commands" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:62 -msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:67 -msgid "Command" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:69 -msgid ":samp:`include {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:69 -msgid "Add all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid ":samp:`exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid "Remove all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid ":samp:`global-include {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid "Add all files anywhere in the source tree matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid ":samp:`global-exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid "Remove all files anywhere in the source tree matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid ":samp:`graft {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid "Add all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid ":samp:`prune {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid "Remove all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:79 -msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:87 -msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:91 -msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:95 -msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:101 -msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." -msgstr "" - -#: ../source/guides/using-testpypi.rst:7 -msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" -msgstr "" - -#: ../source/guides/using-testpypi.rst:13 -msgid "Registering your account" -msgstr "" - -#: ../source/guides/using-testpypi.rst:15 -msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." -msgstr "" - -#: ../source/guides/using-testpypi.rst:19 -msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." -msgstr "" - -#: ../source/guides/using-testpypi.rst:24 -msgid "Using TestPyPI with Twine" -msgstr "" - -#: ../source/guides/using-testpypi.rst:26 -msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:33 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." -msgstr "" - -#: ../source/guides/using-testpypi.rst:39 -msgid "Using TestPyPI with pip" -msgstr "" - -#: ../source/guides/using-testpypi.rst:41 -msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:56 -msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" -msgstr "" - -#: ../source/guides/using-testpypi.rst:73 -msgid "Setting up TestPyPI in :file:`.pypirc`" -msgstr "" - -#: ../source/guides/using-testpypi.rst:75 -msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" -msgstr "" - -#: ../source/index.rst:3 -#: ../source/key_projects.rst:181 -msgid "Python Packaging User Guide" -msgstr "" - -#: ../source/index.rst:5 -msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." -msgstr "" - -#: ../source/index.rst:5 -msgid "python, packaging, guide, tutorial" -msgstr "" - -#: ../source/index.rst:24 -msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." -msgstr "" - -#: ../source/index.rst:28 -msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" -msgstr "" - -#: ../source/index.rst:36 -msgid "Get started" -msgstr "" - -#: ../source/index.rst:38 -msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" -msgstr "" - -#: ../source/index.rst:41 -msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" -msgstr "" - -#: ../source/index.rst:43 -msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" -msgstr "" - -#: ../source/index.rst:45 -msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" -msgstr "" - -#: ../source/index.rst:47 -msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" -msgstr "" - -#: ../source/index.rst:52 -msgid "Learn more" -msgstr "" - -#: ../source/index.rst:54 -msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" -msgstr "" - -#: ../source/index.rst:56 -msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." -msgstr "" - -#: ../source/index.rst:58 -msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." -msgstr "" - -#: ../source/index.rst:60 -msgid "The :doc:`specifications/index` section for packaging interoperability specifications." -msgstr "" - -#: ../source/index.rst:62 -msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." -msgstr "" - -#: ../source/key_projects.rst:6 -msgid "Project Summaries" -msgstr "" - -#: ../source/key_projects.rst:8 -msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." -msgstr "" - -#: ../source/key_projects.rst:14 -msgid "PyPA Projects" -msgstr "" - -#: ../source/key_projects.rst:19 -msgid "bandersnatch" -msgstr "" - -#: ../source/key_projects.rst:21 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:25 -msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." -msgstr "" - -#: ../source/key_projects.rst:35 -msgid "build" -msgstr "" - -#: ../source/key_projects.rst:37 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:42 -msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." -msgstr "" - -#: ../source/key_projects.rst:49 -msgid "cibuildwheel" -msgstr "" - -#: ../source/key_projects.rst:51 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" -msgstr "" - -#: ../source/key_projects.rst:58 -msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." -msgstr "" - -#: ../source/key_projects.rst:64 -msgid "distlib" -msgstr "" - -#: ../source/key_projects.rst:66 -msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:71 -msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." -msgstr "" - -#: ../source/key_projects.rst:80 -msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." -msgstr "" - -#: ../source/key_projects.rst:90 -msgid "packaging" -msgstr "" - -#: ../source/key_projects.rst:92 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:97 -msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." -msgstr "" - -#: ../source/key_projects.rst:99 -msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." -msgstr "" - -#: ../source/key_projects.rst:107 -msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." -msgstr "" - -#: ../source/key_projects.rst:119 -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "pip" -msgstr "" - -#: ../source/key_projects.rst:121 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:126 -msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." -msgstr "" - -#: ../source/key_projects.rst:129 -msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." -msgstr "" - -#: ../source/key_projects.rst:137 -msgid "Pipenv" -msgstr "" - -#: ../source/key_projects.rst:139 -msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:144 -msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." -msgstr "" - -#: ../source/key_projects.rst:148 -msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." -msgstr "" - -#: ../source/key_projects.rst:159 -msgid "Pipfile" -msgstr "" - -#: ../source/key_projects.rst:161 -msgid "`Source `__" -msgstr "" - -#: ../source/key_projects.rst:163 -msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." -msgstr "" - -#: ../source/key_projects.rst:170 -msgid "pipx" -msgstr "" - -#: ../source/key_projects.rst:172 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:176 -msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." -msgstr "" - -#: ../source/key_projects.rst:183 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:187 -msgid "This guide!" -msgstr "" - -#: ../source/key_projects.rst:192 -msgid "readme_renderer" -msgstr "" - -#: ../source/key_projects.rst:194 -msgid "`GitHub and docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:197 -msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." -msgstr "" - -#: ../source/key_projects.rst:208 -msgid "setuptools" -msgstr "" - -#: ../source/key_projects.rst:210 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:215 -msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." -msgstr "" - -#: ../source/key_projects.rst:220 -msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." -msgstr "" - -#: ../source/key_projects.rst:227 -msgid "trove-classifiers" -msgstr "" - -#: ../source/key_projects.rst:229 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:233 -msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." -msgstr "" - -#: ../source/key_projects.rst:239 -msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." -msgstr "" - -#: ../source/key_projects.rst:253 -msgid "twine" -msgstr "" - -#: ../source/key_projects.rst:255 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:260 -msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." -msgstr "" - -#: ../source/key_projects.rst:270 -#: ../source/overview.rst:415 -msgid "virtualenv" -msgstr "" - -#: ../source/key_projects.rst:272 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:277 -msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/key_projects.rst:290 -msgid "Warehouse" -msgstr "" - -#: ../source/key_projects.rst:292 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:296 -msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." -msgstr "" - -#: ../source/key_projects.rst:304 -msgid "wheel" -msgstr "" - -#: ../source/key_projects.rst:306 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:311 -msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." -msgstr "" - -#: ../source/key_projects.rst:315 -msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." -msgstr "" - -#: ../source/key_projects.rst:324 -msgid "Non-PyPA Projects" -msgstr "" - -#: ../source/key_projects.rst:329 -msgid "bento" -msgstr "" - -#: ../source/key_projects.rst:331 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:336 -msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." -msgstr "" - -#: ../source/key_projects.rst:344 -msgid "buildout" -msgstr "" - -#: ../source/key_projects.rst:346 -msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:351 -msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." -msgstr "" - -#: ../source/key_projects.rst:358 -msgid "conda" -msgstr "" - -#: ../source/key_projects.rst:360 -msgid "`Docs `__" -msgstr "" - -#: ../source/key_projects.rst:362 -msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." -msgstr "" - -#: ../source/key_projects.rst:369 -msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." -msgstr "" - -#: ../source/key_projects.rst:373 -msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." -msgstr "" - -#: ../source/key_projects.rst:386 -msgid "devpi" -msgstr "" - -#: ../source/key_projects.rst:388 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:392 -msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." -msgstr "" - -#: ../source/key_projects.rst:401 -msgid "flit" -msgstr "" - -#: ../source/key_projects.rst:403 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:407 -msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." -msgstr "" - -#: ../source/key_projects.rst:412 -msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." -msgstr "" - -#: ../source/key_projects.rst:422 -msgid "enscons" -msgstr "" - -#: ../source/key_projects.rst:424 -msgid "`Source `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:428 -msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." -msgstr "" - -#: ../source/key_projects.rst:443 -msgid "Hashdist" -msgstr "" - -#: ../source/key_projects.rst:445 -msgid "`Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:448 -msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." -msgstr "" - -#: ../source/key_projects.rst:460 -msgid "hatch" -msgstr "" - -#: ../source/key_projects.rst:462 -msgid "`GitHub and Docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:465 -msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." -msgstr "" - -#: ../source/key_projects.rst:475 -msgid "multibuild" -msgstr "" - -#: ../source/key_projects.rst:477 -msgid "`GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:479 -msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." -msgstr "" - -#: ../source/key_projects.rst:485 -msgid "pex" -msgstr "" - -#: ../source/key_projects.rst:487 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:491 -msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." -msgstr "" - -#: ../source/key_projects.rst:500 -msgid "pip-tools" -msgstr "" - -#: ../source/key_projects.rst:502 -msgid "`GitHub and Docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:505 -msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." -msgstr "" - -#: ../source/key_projects.rst:517 -msgid "piwheels" -msgstr "" - -#: ../source/key_projects.rst:519 -msgid "`Website `__ | `Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:523 -msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." -msgstr "" - -#: ../source/key_projects.rst:532 -msgid "poetry" -msgstr "" - -#: ../source/key_projects.rst:534 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:538 -msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." -msgstr "" - -#: ../source/key_projects.rst:548 -msgid "pypiserver" -msgstr "" - -#: ../source/key_projects.rst:550 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:554 -msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." -msgstr "" - -#: ../source/key_projects.rst:564 -msgid "scikit-build" -msgstr "" - -#: ../source/key_projects.rst:566 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:570 -msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." -msgstr "" - -#: ../source/key_projects.rst:582 -msgid "shiv" -msgstr "" - -#: ../source/key_projects.rst:584 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:588 -msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." -msgstr "" - -#: ../source/key_projects.rst:598 -msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" -msgstr "" - -#: ../source/key_projects.rst:603 -msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." -msgstr "" - -#: ../source/key_projects.rst:611 -msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." -msgstr "" - -#: ../source/key_projects.rst:617 -msgid "zest.releaser" -msgstr "" - -#: ../source/key_projects.rst:619 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:623 -msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." -msgstr "" - -#: ../source/key_projects.rst:630 -msgid "Standard Library Projects" -msgstr "" - -#: ../source/key_projects.rst:635 -msgid "ensurepip" -msgstr "" - -#: ../source/key_projects.rst:637 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:640 -msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." -msgstr "" - -#: ../source/key_projects.rst:649 -msgid "distutils" -msgstr "" - -#: ../source/key_projects.rst:651 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:654 -msgid "The original Python packaging system, added to the standard library in Python 2.0." -msgstr "" - -#: ../source/key_projects.rst:657 -msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." -msgstr "" - -#: ../source/key_projects.rst:670 -msgid "venv" -msgstr "" - -#: ../source/key_projects.rst:672 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:675 -msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/news.rst:2 -msgid "News" -msgstr "" - -#: ../source/news.rst:5 -msgid "September 2019" -msgstr "" - -#: ../source/news.rst:6 -msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" -msgstr "" - -#: ../source/news.rst:9 -msgid "August 2019" -msgstr "" - -#: ../source/news.rst:10 -msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" -msgstr "" - -#: ../source/news.rst:13 -msgid "July 2019" -msgstr "" - -#: ../source/news.rst:14 -msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" -msgstr "" - -#: ../source/news.rst:15 -msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" -msgstr "" - -#: ../source/news.rst:16 -msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" -msgstr "" - -#: ../source/news.rst:17 -msgid "Updated directory layout examples for consistency. (:pr:`611`)" -msgstr "" - -#: ../source/news.rst:18 -msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" -msgstr "" - -#: ../source/news.rst:21 -msgid "June 2019" -msgstr "" - -#: ../source/news.rst:22 -msgid "Fixed some typos. (:pr:`620`)" -msgstr "" - -#: ../source/news.rst:25 -msgid "May 2019" -msgstr "" - -#: ../source/news.rst:26 -msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" -msgstr "" - -#: ../source/news.rst:27 -msgid "Added a MANIFEST.in guide page. (:pr:`609`)" -msgstr "" - -#: ../source/news.rst:30 -msgid "April 2019" -msgstr "" - -#: ../source/news.rst:31 -msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" -msgstr "" - -#: ../source/news.rst:32 -msgid "Reduced emphasis on virtualenv. (:pr:`606`)" -msgstr "" - -#: ../source/news.rst:35 -msgid "March 2019" -msgstr "" - -#: ../source/news.rst:36 -msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" -msgstr "" - -#: ../source/news.rst:37 -msgid "Covered RTD details for contributing. (:pr:`600`)" -msgstr "" - -#: ../source/news.rst:40 -msgid "February 2019" -msgstr "" - -#: ../source/news.rst:41 -msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" -msgstr "" - -#: ../source/news.rst:42 -msgid "Added instructions to install Python CLI applications. (:pr:`594`)" -msgstr "" - -#: ../source/news.rst:45 -msgid "January 2019" -msgstr "" - -#: ../source/news.rst:46 -msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" -msgstr "" - -#: ../source/news.rst:47 -msgid "Updated Sphinx and Nox. (:pr:`591`)" -msgstr "" - -#: ../source/news.rst:48 -msgid "Referenced Twine from Python3. (:pr:`581`)" -msgstr "" - -#: ../source/news.rst:51 -msgid "December 2018" -msgstr "" - -#: ../source/news.rst:52 -msgid "No programmers in the office!" -msgstr "" - -#: ../source/news.rst:55 -msgid "November 2018" -msgstr "" - -#: ../source/news.rst:56 -msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" -msgstr "" - -#: ../source/news.rst:57 -msgid "Changed bumpversion to bump2version. (:pr:`572`)" -msgstr "" - -#: ../source/news.rst:58 -msgid "Added single-sourcing package version example. (:pr:`573`)" -msgstr "" - -#: ../source/news.rst:59 -msgid "Added a guide for creating documentation. (:pr:`568`)" -msgstr "" - -#: ../source/news.rst:62 -msgid "October 2018" -msgstr "" - -#: ../source/news.rst:63 -msgid "Updated Nox package name. (:pr:`566`)" -msgstr "" - -#: ../source/news.rst:64 -msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" -msgstr "" - -#: ../source/news.rst:67 -msgid "September 2018" -msgstr "" - -#: ../source/news.rst:68 -msgid "Added a section on checking RST markup. (:pr:`554`)" -msgstr "" - -#: ../source/news.rst:69 -msgid "Updated user installs page. (:pr:`558`)" -msgstr "" - -#: ../source/news.rst:70 -msgid "Updated Google BigQuery urls. (:pr:`556`)" -msgstr "" - -#: ../source/news.rst:71 -msgid "Replaced tar command with working command. (:pr:`552`)" -msgstr "" - -#: ../source/news.rst:72 -msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" -msgstr "" - -#: ../source/news.rst:75 -msgid "August 2018" -msgstr "" - -#: ../source/news.rst:76 -msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" -msgstr "" - -#: ../source/news.rst:77 -msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" -msgstr "" - -#: ../source/news.rst:78 -msgid "Updated Python version supported by virtualenv. (:pr:`538`)" -msgstr "" - -#: ../source/news.rst:79 -msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" -msgstr "" - -#: ../source/news.rst:82 -msgid "July 2018" -msgstr "" - -#: ../source/news.rst:84 -msgid "Improved binary extension docs. (:pr:`531`)" -msgstr "" - -#: ../source/news.rst:85 -msgid "Added scikit-build to key projects. (:pr:`530`)" -msgstr "" - -#: ../source/news.rst:88 -msgid "June 2018" -msgstr "" - -#: ../source/news.rst:90 -msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" -msgstr "" - -#: ../source/news.rst:91 -msgid "Updated Markdown descriptions explanation. (:pr:`522`)" -msgstr "" - -#: ../source/news.rst:94 -msgid "May 2018" -msgstr "" - -#: ../source/news.rst:96 -msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" -msgstr "" - -#: ../source/news.rst:97 -msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" -msgstr "" - -#: ../source/news.rst:98 -msgid "Simplified packaging tutorial. (:pr:`498`)" -msgstr "" - -#: ../source/news.rst:99 -msgid "Updated Windows users instructions for clarity. (:pr:`493`)" -msgstr "" - -#: ../source/news.rst:100 -msgid "Updated the license section description for completeness. (:pr:`492`)" -msgstr "" - -#: ../source/news.rst:101 -msgid "Added specification-style document to contributing section. (:pr:`489`)" -msgstr "" - -#: ../source/news.rst:102 -msgid "Added documentation types to contributing guide. (:pr:`485`)" -msgstr "" - -#: ../source/news.rst:105 -msgid "April 2018" -msgstr "" - -#: ../source/news.rst:107 -msgid "Added README guide. (:pr:`461`)" -msgstr "" - -#: ../source/news.rst:108 -msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" -msgstr "" - -#: ../source/news.rst:109 -msgid "Added instructions for Warehouse. (:pr:`471`)" -msgstr "" - -#: ../source/news.rst:110 -msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" -msgstr "" - -#: ../source/news.rst:111 -msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" -msgstr "" - -#: ../source/news.rst:112 -msgid "Added a guide for phasing out Python versions. (:pr:`459`)" -msgstr "" - -#: ../source/news.rst:113 -msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" -msgstr "" - -#: ../source/news.rst:116 -msgid "March 2018" -msgstr "" - -#: ../source/news.rst:118 -msgid "Updated \"installing scientific packages\". (:pr:`455`)" -msgstr "" - -#: ../source/news.rst:119 -msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" -msgstr "" - -#: ../source/news.rst:120 -msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" -msgstr "" - -#: ../source/news.rst:121 -msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" -msgstr "" - -#: ../source/news.rst:124 -msgid "February 2018" -msgstr "" - -#: ../source/news.rst:126 -msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" -msgstr "" - -#: ../source/news.rst:127 -msgid "Updated PyPI migration info. (:pr:`439`)" -msgstr "" - -#: ../source/news.rst:128 -msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" -msgstr "" - -#: ../source/news.rst:129 -msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" -msgstr "" - -#: ../source/news.rst:130 -msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" -msgstr "" - -#: ../source/news.rst:133 -msgid "January 2018" -msgstr "" - -#: ../source/news.rst:135 -msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" -msgstr "" - -#: ../source/news.rst:136 -msgid "Updated README.rst explanation. (:pr:`419`)" -msgstr "" - -#: ../source/news.rst:139 -msgid "December 2017" -msgstr "" - -#: ../source/news.rst:141 -msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" -msgstr "" - -#: ../source/news.rst:142 -msgid "Noted which fields can be used with environment markers. (:pr:`416`)" -msgstr "" - -#: ../source/news.rst:143 -msgid "Updated Requires-Python section. (:pr:`414`)" -msgstr "" - -#: ../source/news.rst:144 -msgid "Added news page. (:pr:`404`)" -msgstr "" - -#: ../source/news.rst:147 -msgid "November 2017" -msgstr "" - -#: ../source/news.rst:149 -msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" -msgstr "" - -#: ../source/news.rst:150 -msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" -msgstr "" - -#: ../source/news.rst:152 -msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" -msgstr "" - -#: ../source/news.rst:153 -msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" -msgstr "" - -#: ../source/news.rst:156 -msgid "October 2017" -msgstr "" - -#: ../source/news.rst:158 -msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" -msgstr "" - -#: ../source/news.rst:159 -msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" -msgstr "" - -#: ../source/news.rst:160 -msgid "Split the specifications page into multiple pages. (:pr:`386`)" -msgstr "" - -#: ../source/news.rst:163 -msgid "September 2017" -msgstr "" - -#: ../source/news.rst:165 -msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" -msgstr "" - -#: ../source/news.rst:167 -msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" -msgstr "" - -#: ../source/news.rst:170 -msgid "August 2017" -msgstr "" - -#: ../source/news.rst:172 -msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" -msgstr "" - -#: ../source/news.rst:173 -msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" -msgstr "" - -#: ../source/news.rst:174 -msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" -msgstr "" - -#: ../source/news.rst:177 -msgid "July 2017" -msgstr "" - -#: ../source/news.rst:179 -msgid "Added ``flit`` to the key projects list. (:pr:`358`)" -msgstr "" - -#: ../source/news.rst:180 -msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" -msgstr "" - -#: ../source/news.rst:181 -msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" -msgstr "" - -#: ../source/news.rst:182 -msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" -msgstr "" - -#: ../source/news.rst:183 -msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" -msgstr "" - -#: ../source/news.rst:186 -msgid "June 2017" -msgstr "" - -#: ../source/news.rst:188 -msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" -msgstr "" - -#: ../source/news.rst:189 -msgid "Added documentation for ``python_requires``. (:pr:`338`)" -msgstr "" - -#: ../source/news.rst:190 -msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" -msgstr "" - -#: ../source/news.rst:191 -msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" -msgstr "" - -#: ../source/news.rst:192 -msgid "Added a license section to the distributing guide. (:pr:`331`)" -msgstr "" - -#: ../source/news.rst:193 -msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" -msgstr "" - -#: ../source/news.rst:194 -msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" -msgstr "" - -#: ../source/news.rst:195 -msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" -msgstr "" - -#: ../source/news.rst:196 -msgid "Switched to the PyPA theme. (:pr:`305`)" -msgstr "" - -#: ../source/news.rst:197 -msgid "Re-organized the documentation into the new structure. (:pr:`318`)" -msgstr "" - -#: ../source/news.rst:200 -msgid "May 2017" -msgstr "" - -#: ../source/news.rst:202 -msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" -msgstr "" - -#: ../source/news.rst:203 -msgid "Added contributor and style guide. (:pr:`307`)" -msgstr "" - -#: ../source/news.rst:204 -msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" -msgstr "" - -#: ../source/news.rst:207 -msgid "April 2017" -msgstr "" - -#: ../source/news.rst:209 -msgid "Added travis configuration for testing pull requests. (:pr:`300`)" -msgstr "" - -#: ../source/news.rst:210 -msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" -msgstr "" - -#: ../source/news.rst:211 -msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" -msgstr "" - -#: ../source/news.rst:212 -msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" -msgstr "" - -#: ../source/news.rst:213 -msgid "Added a topic on namespace packages. (:pr:`290`)" -msgstr "" - -#: ../source/news.rst:214 -msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" -msgstr "" - -#: ../source/news.rst:215 -msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" -msgstr "" - -#: ../source/news.rst:216 -msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" -msgstr "" - -#: ../source/news.rst:217 -msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" -msgstr "" - -#: ../source/news.rst:219 -msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" -msgstr "" - -#: ../source/news.rst:223 -msgid "March 2017" -msgstr "" - -#: ../source/news.rst:225 -msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" -msgstr "" - -#: ../source/news.rst:228 -msgid "February 2017" -msgstr "" - -#: ../source/news.rst:230 -msgid "Added :pep:`518`. (:pr:`281`)" -msgstr "" - -#: ../source/overview.rst:3 -msgid "An Overview of Packaging for Python" -msgstr "" - -#: ../source/overview.rst:7 -msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." -msgstr "" - -#: ../source/overview.rst:12 -msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." -msgstr "" - -#: ../source/overview.rst:18 -msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." -msgstr "" - -#: ../source/overview.rst:26 -msgid "Thinking about deployment" -msgstr "" - -#: ../source/overview.rst:28 -msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" -msgstr "" - -#: ../source/overview.rst:32 -msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" -msgstr "" - -#: ../source/overview.rst:35 -msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" -msgstr "" - -#: ../source/overview.rst:37 -msgid "Is your software installed individually, or in large deployment batches?" -msgstr "" - -#: ../source/overview.rst:39 -msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." -msgstr "" - -#: ../source/overview.rst:46 -msgid "Packaging Python libraries and tools" -msgstr "" - -#: ../source/overview.rst:48 -msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." -msgstr "" - -#: ../source/overview.rst:53 -msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." -msgstr "" - -#: ../source/overview.rst:59 -msgid "Python modules" -msgstr "" - -#: ../source/overview.rst:61 -msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." -msgstr "" - -#: ../source/overview.rst:66 -msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." -msgstr "" - -#: ../source/overview.rst:73 -msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." -msgstr "" - -#: ../source/overview.rst:78 -msgid "Python source distributions" -msgstr "" - -#: ../source/overview.rst:80 -msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." -msgstr "" - -#: ../source/overview.rst:84 -msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." -msgstr "" - -#: ../source/overview.rst:90 -msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." -msgstr "" - -#: ../source/overview.rst:95 -msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." -msgstr "" - -#: ../source/overview.rst:100 -msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." -msgstr "" - -#: ../source/overview.rst:107 -msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" -msgstr "" - -#: ../source/overview.rst:114 -msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." -msgstr "" - -#: ../source/overview.rst:119 -msgid "Python binary distributions" -msgstr "" - -#: ../source/overview.rst:121 -msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." -msgstr "" - -#: ../source/overview.rst:125 -msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." -msgstr "" - -#: ../source/overview.rst:132 -msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." -msgstr "" - -#: ../source/overview.rst:140 -msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." -msgstr "" - -#: ../source/overview.rst:148 -msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." -msgstr "" - -#: ../source/overview.rst:155 -msgid "Packaging Python applications" -msgstr "" - -#: ../source/overview.rst:157 -msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." -msgstr "" - -#: ../source/overview.rst:162 -msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." -msgstr "" - -#: ../source/overview.rst:166 -msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." -msgstr "" - -#: ../source/overview.rst:172 -msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." -msgstr "" - -#: ../source/overview.rst:176 -msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." -msgstr "" - -#: ../source/overview.rst:181 -msgid "Depending on a framework" -msgstr "" - -#: ../source/overview.rst:183 -msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." -msgstr "" - -#: ../source/overview.rst:189 -msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." -msgstr "" - -#: ../source/overview.rst:195 -msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." -msgstr "" - -#: ../source/overview.rst:199 -msgid "Service platforms" -msgstr "" - -#: ../source/overview.rst:201 -msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." -msgstr "" - -#: ../source/overview.rst:205 -msgid "`Heroku `_" -msgstr "" - -#: ../source/overview.rst:206 -msgid "`Google App Engine `_" -msgstr "" - -#: ../source/overview.rst:207 -msgid "`PythonAnywhere `_" -msgstr "" - -#: ../source/overview.rst:208 -msgid "`OpenShift `_" -msgstr "" - -#: ../source/overview.rst:209 -msgid "\"Serverless\" frameworks like `Zappa `_" -msgstr "" - -#: ../source/overview.rst:211 -msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." -msgstr "" - -#: ../source/overview.rst:216 -msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." -msgstr "" - -#: ../source/overview.rst:220 -msgid "Web browsers and mobile applications" -msgstr "" - -#: ../source/overview.rst:222 -msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." -msgstr "" - -#: ../source/overview.rst:227 -msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" -msgstr "" - -#: ../source/overview.rst:231 -msgid "`Kivy `_" -msgstr "" - -#: ../source/overview.rst:232 -msgid "`Beeware `_" -msgstr "" - -#: ../source/overview.rst:233 -msgid "`Brython `_" -msgstr "" - -#: ../source/overview.rst:234 -msgid "`Flexx `_" -msgstr "" - -#: ../source/overview.rst:236 -msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." -msgstr "" - -#: ../source/overview.rst:241 -msgid "Depending on a pre-installed Python" -msgstr "" - -#: ../source/overview.rst:243 -msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." -msgstr "" - -#: ../source/overview.rst:249 -msgid "Technologies which support this model:" -msgstr "" - -#: ../source/overview.rst:251 -msgid "`PEX `_ (Python EXecutable)" -msgstr "" - -#: ../source/overview.rst:252 -msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" -msgstr "" - -#: ../source/overview.rst:253 -msgid "`shiv `_ (requires Python 3)" -msgstr "" - -#: ../source/overview.rst:255 -msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." -msgstr "" - -#: ../source/overview.rst:260 -msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." -msgstr "" - -#: ../source/overview.rst:267 -msgid "Depending on a separate software distribution ecosystem" -msgstr "" - -#: ../source/overview.rst:269 -msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." -msgstr "" - -#: ../source/overview.rst:274 -msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." -msgstr "" - -#: ../source/overview.rst:284 -msgid "Instructions on building and publishing for the Anaconda ecosystem:" -msgstr "" - -#: ../source/overview.rst:286 -msgid "`Building libraries and applications with conda `_" -msgstr "" - -#: ../source/overview.rst:287 -msgid "`Transitioning a native Python package to Anaconda `_" -msgstr "" - -#: ../source/overview.rst:289 -msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" -msgstr "" - -#: ../source/overview.rst:293 -msgid "`Enthought Canopy `_" -msgstr "" - -#: ../source/overview.rst:294 -msgid "`ActiveState ActivePython `_" -msgstr "" - -#: ../source/overview.rst:295 -msgid "`WinPython `_" -msgstr "" - -#: ../source/overview.rst:300 -msgid "Bringing your own Python executable" -msgstr "" - -#: ../source/overview.rst:302 -msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." -msgstr "" - -#: ../source/overview.rst:306 -msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." -msgstr "" - -#: ../source/overview.rst:311 -msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." -msgstr "" - -#: ../source/overview.rst:315 -msgid "A selection of Python freezers:" -msgstr "" - -#: ../source/overview.rst:317 -msgid "`pyInstaller `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:318 -msgid "`cx_Freeze `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:319 -msgid "`constructor `_ - For command-line installers" -msgstr "" - -#: ../source/overview.rst:320 -msgid "`py2exe `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:321 -msgid "`py2app `_ - Mac only" -msgstr "" - -#: ../source/overview.rst:322 -msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" -msgstr "" - -#: ../source/overview.rst:323 -msgid "`osnap `_ - Windows and Mac" -msgstr "" - -#: ../source/overview.rst:324 -msgid "`pynsist `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:326 -msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." -msgstr "" - -#: ../source/overview.rst:332 -msgid "Bringing your own userspace" -msgstr "" - -#: ../source/overview.rst:334 -msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." -msgstr "" - -#: ../source/overview.rst:341 -msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." -msgstr "" - -#: ../source/overview.rst:344 -msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" -msgstr "" - -#: ../source/overview.rst:347 -msgid "`AppImage `_" -msgstr "" - -#: ../source/overview.rst:348 -msgid "`Docker `_" -msgstr "" - -#: ../source/overview.rst:349 -msgid "`Flatpak `_" -msgstr "" - -#: ../source/overview.rst:350 -msgid "`Snapcraft `_" -msgstr "" - -#: ../source/overview.rst:353 -msgid "Bringing your own kernel" -msgstr "" - -#: ../source/overview.rst:355 -msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." -msgstr "" - -#: ../source/overview.rst:360 -msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" -msgstr "" - -#: ../source/overview.rst:364 -msgid "`Vagrant `_" -msgstr "" - -#: ../source/overview.rst:365 -msgid "`VHD `_, `AMI `_, and `other formats `_" -msgstr "" - -#: ../source/overview.rst:366 -msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" -msgstr "" - -#: ../source/overview.rst:369 -msgid "Bringing your own hardware" -msgstr "" - -#: ../source/overview.rst:371 -msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." -msgstr "" - -#: ../source/overview.rst:375 -msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." -msgstr "" - -#: ../source/overview.rst:379 -msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." -msgstr "" - -#: ../source/overview.rst:389 -msgid "The simplified gamut of technologies used to package Python applications." -msgstr "" - -#: ../source/overview.rst:392 -msgid "What about..." -msgstr "" - -#: ../source/overview.rst:394 -msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." -msgstr "" - -#: ../source/overview.rst:398 -msgid "Operating system packages" -msgstr "" - -#: ../source/overview.rst:400 -msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." -msgstr "" - -#: ../source/overview.rst:411 -msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." -msgstr "" - -#: ../source/overview.rst:417 -msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." -msgstr "" - -#: ../source/overview.rst:427 -msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." -msgstr "" - -#: ../source/overview.rst:432 -msgid "Security" -msgstr "" - -#: ../source/overview.rst:434 -msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." -msgstr "" - -#: ../source/overview.rst:437 -msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." -msgstr "" - -#: ../source/overview.rst:446 -msgid "Wrap up" -msgstr "" - -#: ../source/overview.rst:448 -msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:6 -msgid "Binary distribution format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:8 -msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:13 -msgid "Abstract" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:15 -msgid "This PEP describes a built-package format for Python called \"wheel\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:17 -msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:27 -msgid "PEP Acceptance" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:29 -msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:34 -msgid "Rationale" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:36 -msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:43 -msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:52 -msgid "Details" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:55 -msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:57 -msgid "Wheel installation notionally consists of two phases:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:59 -msgid "Unpack." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:61 -msgid "Parse ``distribution-1.0.dist-info/WHEEL``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:62 -msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:64 -msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:66 -msgid "Else unpack archive into platlib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:68 -msgid "Spread." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:70 -msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:72 -msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:78 -msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:80 -msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:82 -msgid "Remove empty ``distribution-1.0.data`` directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:83 -msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:87 -msgid "Recommended installer features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:97 -msgid "Rewrite ``#!python``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:90 -msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:96 -msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:102 -msgid "Generate script wrappers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:100 -msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:105 -msgid "Recommended archiver features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:112 -msgid "Place ``.dist-info`` at the end of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:108 -msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:115 -msgid "File Format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:118 -msgid "File name convention" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:120 -msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "distribution" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "Distribution name, e.g. 'django', 'pyramid'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "Distribution version, e.g. 1.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:135 -msgid "build tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:130 -msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "language implementation and version tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "E.g. 'py27', 'py2', 'py3'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "abi tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "E.g. 'cp33m', 'abi3', 'none'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "platform tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "E.g. 'linux_x86_64', 'any'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:146 -msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:151 -msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:156 -msgid "Escaping and Unicode" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:158 -msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:161 -msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:164 -msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:166 -msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:169 -msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:172 -msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:176 -msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:182 -msgid "File contents" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:184 -msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:188 -msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:191 -msgid "``{distribution}-{version}.dist-info/`` contains metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:192 -msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:196 -msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:200 -msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:202 -msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:212 -msgid "``Wheel-Version`` is the version number of the Wheel specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:213 -msgid "``Generator`` is the name and optionally the version of the software that produced the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:215 -msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:218 -msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:220 -msgid "``Build`` is the build number and is omitted if there is no build number." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:221 -msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:224 -msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:226 -msgid "Wheel does not contain setup.py or setup.cfg." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:228 -msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:235 -#: ../source/specifications/recording-installed-packages.rst:35 -msgid "The .dist-info directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:237 -msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:239 -msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:241 -msgid "WHEEL is the wheel metadata specific to a build of the package." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:242 -msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:248 -msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:249 -msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:251 -msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:254 -msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:261 -msgid "The .data directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:263 -msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:271 -msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:277 -msgid "Signed wheel files" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:279 -msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:290 -msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:295 -msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:302 -msgid "(The hash value is the same format used in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:304 -msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:307 -msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:312 -msgid "See" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:314 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:315 -msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:316 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:317 -msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:321 -msgid "Comparison to .egg" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:323 -msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:328 -msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:331 -msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:337 -msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:341 -msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:344 -msgid "Wheel is a reference to the other Python." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:348 -msgid "FAQ" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:352 -msgid "Wheel defines a .data directory. Should I put all my data there?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:354 -msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:363 -msgid "Why does wheel include attached signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:365 -msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:373 -msgid "Why does wheel allow JWS signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:375 -msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:381 -msgid "Why does wheel also allow S/MIME signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:383 -msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:386 -msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:391 -msgid "What's the deal with \"purelib\" vs. \"platlib\"?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:393 -msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:398 -msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:403 -msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:409 -msgid "Is it possible to import Python code directly from a wheel file?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:411 -msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:417 -msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:426 -msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:443 -msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:450 -msgid "Changes" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:452 -msgid "Since :pep:`427`, this specification has changed as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:454 -msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:461 -msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:466 -msgid "Appendix" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:468 -msgid "Example urlsafe-base64-nopad implementation::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:482 -msgid "Copyright" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:484 -msgid "This document has been placed into the public domain." -msgstr "" - -#: ../source/specifications/core-metadata.rst:5 -msgid "Core metadata specifications" -msgstr "" - -#: ../source/specifications/core-metadata.rst:7 -msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:10 -msgid "``Metadata-Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:11 -msgid "``Name``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:12 -msgid "``Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:14 -msgid "All the other fields are optional." -msgstr "" - -#: ../source/specifications/core-metadata.rst:16 -msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." -msgstr "" - -#: ../source/specifications/core-metadata.rst:25 -msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:30 -msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." -msgstr "" - -#: ../source/specifications/core-metadata.rst:41 -msgid "Metadata-Version" -msgstr "" - -#: ../source/specifications/core-metadata.rst:45 -msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." -msgstr "" - -#: ../source/specifications/core-metadata.rst:48 -msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:54 -msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." -msgstr "" - -#: ../source/specifications/core-metadata.rst:58 -#: ../source/specifications/core-metadata.rst:80 -#: ../source/specifications/core-metadata.rst:95 -#: ../source/specifications/core-metadata.rst:155 -#: ../source/specifications/core-metadata.rst:170 -#: ../source/specifications/core-metadata.rst:208 -#: ../source/specifications/core-metadata.rst:283 -#: ../source/specifications/core-metadata.rst:287 -#: ../source/specifications/core-metadata.rst:291 -#: ../source/specifications/core-metadata.rst:295 -#: ../source/specifications/core-metadata.rst:327 -#: ../source/specifications/core-metadata.rst:347 -#: ../source/specifications/core-metadata.rst:373 -#: ../source/specifications/core-metadata.rst:391 -#: ../source/specifications/core-metadata.rst:416 -#: ../source/specifications/core-metadata.rst:438 -#: ../source/specifications/core-metadata.rst:600 -#: ../source/specifications/core-metadata.rst:620 -#: ../source/specifications/core-metadata.rst:630 -msgid "Example::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:66 -msgid "Name" -msgstr "" - -#: ../source/specifications/core-metadata.rst:69 -msgid "Added additional restrictions on format from :pep:`508`" -msgstr "" - -#: ../source/specifications/core-metadata.rst:72 -msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:88 -msgid "Version" -msgstr "" - -#: ../source/specifications/core-metadata.rst:92 -msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:101 -msgid "Dynamic (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:105 -msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." -msgstr "" - -#: ../source/specifications/core-metadata.rst:108 -msgid "When found in the metadata of a source distribution, the following rules apply:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:111 -msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." -msgstr "" - -#: ../source/specifications/core-metadata.rst:115 -msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:118 -msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:122 -msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." -msgstr "" - -#: ../source/specifications/core-metadata.rst:127 -msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:131 -msgid "Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:135 -msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." -msgstr "" - -#: ../source/specifications/core-metadata.rst:146 -msgid "Supported-Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:150 -msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." -msgstr "" - -#: ../source/specifications/core-metadata.rst:164 -msgid "Summary" -msgstr "" - -#: ../source/specifications/core-metadata.rst:168 -msgid "A one-line summary of what the distribution does." -msgstr "" - -#: ../source/specifications/core-metadata.rst:188 -msgid "This field may be specified in the message body instead." -msgstr "" - -#: ../source/specifications/core-metadata.rst:191 -msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:196 -msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." -msgstr "" - -#: ../source/specifications/core-metadata.rst:202 -msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:219 -msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." -msgstr "" - -#: ../source/specifications/core-metadata.rst:223 -msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:232 -msgid "Description-Content-Type" -msgstr "" - -#: ../source/specifications/core-metadata.rst:236 -msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:239 -msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." -msgstr "" - -#: ../source/specifications/core-metadata.rst:253 -msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:259 -msgid "Format::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:263 -msgid "The ``type/subtype`` part has only a few legal values:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:265 -msgid "``text/plain``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:266 -msgid "``text/x-rst``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:267 -msgid "``text/markdown``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:269 -msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:273 -msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:278 -msgid "``GFM`` for `Github-flavored Markdown `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:280 -msgid "``CommonMark`` for `CommonMark `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:299 -msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." -msgstr "" - -#: ../source/specifications/core-metadata.rst:303 -msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:307 -msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:311 -msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." -msgstr "" - -#: ../source/specifications/core-metadata.rst:320 -msgid "Keywords" -msgstr "" - -#: ../source/specifications/core-metadata.rst:324 -msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." -msgstr "" - -#: ../source/specifications/core-metadata.rst:333 -msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." -msgstr "" - -#: ../source/specifications/core-metadata.rst:341 -msgid "Home-page" -msgstr "" - -#: ../source/specifications/core-metadata.rst:345 -msgid "A string containing the URL for the distribution's home page." -msgstr "" - -#: ../source/specifications/core-metadata.rst:353 -msgid "Download-URL" -msgstr "" - -#: ../source/specifications/core-metadata.rst:357 -msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:366 -msgid "Author" -msgstr "" - -#: ../source/specifications/core-metadata.rst:370 -msgid "A string containing the author's name at a minimum; additional contact information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:383 -msgid "Author-email" -msgstr "" - -#: ../source/specifications/core-metadata.rst:387 -msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:395 -#: ../source/specifications/core-metadata.rst:442 -msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:405 -msgid "Maintainer" -msgstr "" - -#: ../source/specifications/core-metadata.rst:409 -msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:412 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:426 -msgid "Maintainer-email" -msgstr "" - -#: ../source/specifications/core-metadata.rst:430 -msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:434 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:452 -msgid "License" -msgstr "" - -#: ../source/specifications/core-metadata.rst:456 -msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." -msgstr "" - -#: ../source/specifications/core-metadata.rst:476 -msgid "Classifier (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:480 -msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:485 -#: ../source/specifications/core-metadata.rst:574 -#: ../source/specifications/core-metadata.rst:691 -#: ../source/specifications/core-metadata.rst:715 -msgid "This field may be followed by an environment marker after a semicolon." -msgstr "" - -#: ../source/specifications/core-metadata.rst:496 -msgid "Requires-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:499 -#: ../source/specifications/core-metadata.rst:561 -#: ../source/specifications/core-metadata.rst:663 -#: ../source/specifications/core-metadata.rst:704 -msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." -msgstr "" - -#: ../source/specifications/core-metadata.rst:503 -msgid "Each entry contains a string naming some other distutils project required by this distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:506 -msgid "The format of a requirement string contains from one to four parts:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:508 -msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." -msgstr "" - -#: ../source/specifications/core-metadata.rst:510 -msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." -msgstr "" - -#: ../source/specifications/core-metadata.rst:513 -msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:516 -msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." -msgstr "" - -#: ../source/specifications/core-metadata.rst:519 -msgid "See :pep:`508` for full details of the allowed format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:521 -msgid "The project names should correspond to names as found on the `Python Package Index`_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:524 -msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:538 -msgid "Requires-Python" -msgstr "" - -#: ../source/specifications/core-metadata.rst:542 -msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." -msgstr "" - -#: ../source/specifications/core-metadata.rst:546 -msgid "The value must be in the format specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:548 -msgid "This field cannot be followed by an environment marker." -msgstr "" - -#: ../source/specifications/core-metadata.rst:558 -msgid "Requires-External (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:565 -msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:570 -msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:576 -msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." -msgstr "" - -#: ../source/specifications/core-metadata.rst:581 -msgid "Notice that there is no particular rule on the strings to be used." -msgstr "" - -#: ../source/specifications/core-metadata.rst:593 -msgid "Project-URL (multiple-use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:597 -msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." -msgstr "" - -#: ../source/specifications/core-metadata.rst:604 -msgid "The label is free text limited to 32 characters." -msgstr "" - -#: ../source/specifications/core-metadata.rst:612 -msgid "Provides-Extra (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:616 -msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." -msgstr "" - -#: ../source/specifications/core-metadata.rst:625 -msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:635 -msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." -msgstr "" - -#: ../source/specifications/core-metadata.rst:639 -msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:644 -msgid "Rarely Used Fields" -msgstr "" - -#: ../source/specifications/core-metadata.rst:646 -msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:651 -msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." -msgstr "" - -#: ../source/specifications/core-metadata.rst:660 -msgid "Provides-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:667 -msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:672 -msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:679 -msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:687 -msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." -msgstr "" - -#: ../source/specifications/core-metadata.rst:701 -msgid "Obsoletes-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:708 -msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." -msgstr "" - -#: ../source/specifications/core-metadata.rst:712 -msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:717 -msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:730 -msgid "reStructuredText markup: http://docutils.sourceforge.net/" -msgstr "" - -#: ../source/specifications/core-metadata.rst:735 -msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:6 -msgid "Declaring build system dependencies" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:8 -msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:5 -msgid "Declaring project metadata" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:7 -msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:12 -msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:18 -msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:27 -msgid "The only fields required to be statically defined are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:29 -#: ../source/specifications/declaring-project-metadata.rst:41 -msgid "``name``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:31 -msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:34 -#: ../source/specifications/declaring-project-metadata.rst:54 -msgid "``version``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:36 -msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:43 -#: ../source/specifications/declaring-project-metadata.rst:56 -#: ../source/specifications/declaring-project-metadata.rst:68 -#: ../source/specifications/declaring-project-metadata.rst:117 -msgid "TOML_ type: string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:44 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:47 -msgid "The name of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:49 -msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:57 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:60 -msgid "The version of the project as supported by :pep:`440`." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:62 -msgid "Users SHOULD prefer to specify already-normalized versions." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:66 -msgid "``description``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:69 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:72 -msgid "The summary description of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:76 -msgid "``readme``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:78 -msgid "TOML_ type: string or table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:79 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:83 -msgid "The full description of the project (i.e. the README)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:85 -msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:96 -msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:103 -msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:115 -msgid "``requires-python``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:118 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:121 -msgid "The Python version requirements of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:125 -msgid "``license``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:127 -msgid "TOML_ type: table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:128 -msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:131 -msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:140 -msgid "``authors``/``maintainers``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:142 -msgid "TOML_ type: Array of inline tables with string keys and values" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:143 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:149 -msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:154 -msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:157 -msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:163 -msgid "Using the data to fill in :ref:`core metadata ` is as follows:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:166 -msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:169 -msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:173 -msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:177 -msgid "Multiple values should be separated by commas." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:181 -msgid "``keywords``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:183 -#: ../source/specifications/declaring-project-metadata.rst:193 -msgid "TOML_ type: array of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:184 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:187 -msgid "The keywords for the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:191 -msgid "``classifiers``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:194 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:197 -msgid "Trove classifiers which apply to the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:201 -msgid "``urls``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:203 -msgid "TOML_ type: table with keys and values of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:204 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:207 -msgid "A table of URLs where the key is the URL label and the value is the URL itself." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:212 -msgid "Entry points" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:214 -msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:216 -msgid ":ref:`Entry points specification `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:218 -msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:224 -msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:228 -msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:234 -msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:242 -msgid "``dependencies``/``optional-dependencies``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:244 -msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:247 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:251 -msgid "The (optional) dependencies of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:253 -msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:258 -msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:269 -msgid "``dynamic``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:271 -msgid "TOML_ type: array of string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:272 -msgid "A corresponding :ref:`core metadata ` field does not exist" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:275 -msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:281 -msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:283 -msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:285 -msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:290 -msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:294 -msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:296 -msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:300 -msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:6 -msgid "Dependency specifiers" -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:8 -msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:11 -msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." -msgstr "" - -#: ../source/specifications/direct-url.rst:6 -msgid "Recording the Direct URL Origin of installed distributions" -msgstr "" - -#: ../source/specifications/direct-url.rst:8 -msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." -msgstr "" - -#: ../source/specifications/direct-url.rst:17 -msgid "Specification" -msgstr "" - -#: ../source/specifications/direct-url.rst:19 -msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/direct-url.rst:23 -#: ../source/specifications/recording-installed-packages.rst:206 -msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." -msgstr "" - -#: ../source/specifications/direct-url.rst:26 -msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." -msgstr "" - -#: ../source/specifications/direct-url.rst:29 -msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." -msgstr "" - -#: ../source/specifications/direct-url.rst:36 -msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." -msgstr "" - -#: ../source/specifications/direct-url.rst:39 -msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" -msgstr "" - -#: ../source/specifications/direct-url.rst:45 -msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." -msgstr "" - -#: ../source/specifications/direct-url.rst:49 -msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" -msgstr "" - -#: ../source/specifications/direct-url.rst:52 -msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." -msgstr "" - -#: ../source/specifications/direct-url.rst:58 -msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." -msgstr "" - -#: ../source/specifications/direct-url.rst:61 -msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." -msgstr "" - -#: ../source/specifications/direct-url.rst:68 -msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:71 -msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." -msgstr "" - -#: ../source/specifications/direct-url.rst:78 -msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:81 -msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." -msgstr "" - -#: ../source/specifications/direct-url.rst:84 -msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." -msgstr "" - -#: ../source/specifications/direct-url.rst:91 -msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." -msgstr "" - -#: ../source/specifications/direct-url.rst:96 -msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." -msgstr "" - -#: ../source/specifications/direct-url.rst:102 -msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." -msgstr "" - -#: ../source/specifications/direct-url.rst:110 -msgid "Registered VCS" -msgstr "" - -#: ../source/specifications/direct-url.rst:112 -msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." -msgstr "" - -#: ../source/specifications/direct-url.rst:122 -msgid "Git" -msgstr "" - -#: ../source/specifications/direct-url.rst:124 -#: ../source/specifications/direct-url.rst:156 -#: ../source/specifications/direct-url.rst:179 -#: ../source/specifications/direct-url.rst:202 -msgid "Home page" -msgstr "" - -#: ../source/specifications/direct-url.rst:126 -msgid "https://git-scm.com/" -msgstr "" - -#: ../source/specifications/direct-url.rst:128 -#: ../source/specifications/direct-url.rst:160 -#: ../source/specifications/direct-url.rst:183 -#: ../source/specifications/direct-url.rst:206 -msgid "vcs command" -msgstr "" - -#: ../source/specifications/direct-url.rst:130 -#: ../source/specifications/direct-url.rst:134 -msgid "git" -msgstr "" - -#: ../source/specifications/direct-url.rst:132 -#: ../source/specifications/direct-url.rst:164 -#: ../source/specifications/direct-url.rst:187 -#: ../source/specifications/direct-url.rst:210 -msgid "``vcs`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:136 -#: ../source/specifications/direct-url.rst:168 -#: ../source/specifications/direct-url.rst:191 -#: ../source/specifications/direct-url.rst:214 -msgid "``requested_revision`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:138 -msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." -msgstr "" - -#: ../source/specifications/direct-url.rst:141 -#: ../source/specifications/direct-url.rst:172 -#: ../source/specifications/direct-url.rst:195 -#: ../source/specifications/direct-url.rst:219 -msgid "``commit_id`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:143 -msgid "A commit hash (40 hexadecimal characters sha1)." -msgstr "" - -#: ../source/specifications/direct-url.rst:147 -msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." -msgstr "" - -#: ../source/specifications/direct-url.rst:154 -msgid "Mercurial" -msgstr "" - -#: ../source/specifications/direct-url.rst:158 -msgid "https://www.mercurial-scm.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:162 -#: ../source/specifications/direct-url.rst:166 -msgid "hg" -msgstr "" - -#: ../source/specifications/direct-url.rst:170 -msgid "A tag name, branch name, changeset ID, shortened changeset ID." -msgstr "" - -#: ../source/specifications/direct-url.rst:174 -msgid "A changeset ID (40 hexadecimal characters)." -msgstr "" - -#: ../source/specifications/direct-url.rst:177 -msgid "Bazaar" -msgstr "" - -#: ../source/specifications/direct-url.rst:181 -msgid "https://bazaar.canonical.com/" -msgstr "" - -#: ../source/specifications/direct-url.rst:185 -#: ../source/specifications/direct-url.rst:189 -msgid "bzr" -msgstr "" - -#: ../source/specifications/direct-url.rst:193 -msgid "A tag name, branch name, revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:197 -msgid "A revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:200 -msgid "Subversion" -msgstr "" - -#: ../source/specifications/direct-url.rst:204 -msgid "https://subversion.apache.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:208 -#: ../source/specifications/direct-url.rst:212 -msgid "svn" -msgstr "" - -#: ../source/specifications/direct-url.rst:216 -msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." -msgstr "" - -#: ../source/specifications/direct-url.rst:221 -msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." -msgstr "" - -#: ../source/specifications/direct-url.rst:229 -msgid "Example direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:231 -msgid "Source archive:" -msgstr "" - -#: ../source/specifications/direct-url.rst:242 -msgid "Git URL with tag and commit-hash:" -msgstr "" - -#: ../source/specifications/direct-url.rst:255 -msgid "Local directory:" -msgstr "" - -#: ../source/specifications/direct-url.rst:264 -msgid "Local directory installed in editable mode:" -msgstr "" - -#: ../source/specifications/direct-url.rst:277 -msgid "Example pip commands and their effect on direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:279 -msgid "Commands that generate a ``direct_url.json``:" -msgstr "" - -#: ../source/specifications/direct-url.rst:281 -msgid "pip install https://example.com/app-1.0.tgz" -msgstr "" - -#: ../source/specifications/direct-url.rst:282 -msgid "pip install https://example.com/app-1.0.whl" -msgstr "" - -#: ../source/specifications/direct-url.rst:283 -msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" -msgstr "" - -#: ../source/specifications/direct-url.rst:284 -msgid "pip install ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:285 -msgid "pip install file:///home/user/app" -msgstr "" - -#: ../source/specifications/direct-url.rst:286 -msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" -msgstr "" - -#: ../source/specifications/direct-url.rst:290 -msgid "pip install -e ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:292 -msgid "Commands that *do not* generate a ``direct_url.json``" -msgstr "" - -#: ../source/specifications/direct-url.rst:294 -msgid "pip install app" -msgstr "" - -#: ../source/specifications/direct-url.rst:295 -msgid "pip install app --no-index --find-links https://example.com/" -msgstr "" - -#: ../source/specifications/entry-points.rst:5 -msgid "Entry points specification" -msgstr "" - -#: ../source/specifications/entry-points.rst:7 -msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" -msgstr "" - -#: ../source/specifications/entry-points.rst:11 -msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." -msgstr "" - -#: ../source/specifications/entry-points.rst:14 -msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." -msgstr "" - -#: ../source/specifications/entry-points.rst:19 -msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." -msgstr "" - -#: ../source/specifications/entry-points.rst:28 -msgid "Data model" -msgstr "" - -#: ../source/specifications/entry-points.rst:30 -msgid "Conceptually, an entry point is defined by three required properties:" -msgstr "" - -#: ../source/specifications/entry-points.rst:32 -msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:42 -msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:51 -msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:64 -msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." -msgstr "" - -#: ../source/specifications/entry-points.rst:68 -msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." -msgstr "" - -#: ../source/specifications/entry-points.rst:73 -msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." -msgstr "" - -#: ../source/specifications/entry-points.rst:80 -msgid "File format" -msgstr "" - -#: ../source/specifications/entry-points.rst:82 -msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." -msgstr "" - -#: ../source/specifications/entry-points.rst:87 -msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:97 -msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:100 -msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." -msgstr "" - -#: ../source/specifications/entry-points.rst:104 -msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." -msgstr "" - -#: ../source/specifications/entry-points.rst:112 -msgid "For example::" -msgstr "" - -#: ../source/specifications/entry-points.rst:124 -msgid "Use for scripts" -msgstr "" - -#: ../source/specifications/entry-points.rst:126 -msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." -msgstr "" - -#: ../source/specifications/entry-points.rst:134 -msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:141 -msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." -msgstr "" - -#: ../source/specifications/entry-points.rst:149 -msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." -msgstr "" - -#: ../source/specifications/entry-points.rst:154 -msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." -msgstr "" - -#: ../source/specifications/index.rst:4 -msgid "PyPA specifications" -msgstr "" - -#: ../source/specifications/index.rst:6 -msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." -msgstr "" - -#: ../source/specifications/index.rst:13 -msgid "Package Distribution Metadata" -msgstr "" - -#: ../source/specifications/index.rst:30 -msgid "Package Distribution File Formats" -msgstr "" - -#: ../source/specifications/index.rst:40 -msgid "Package Index Interfaces" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:6 -msgid "Platform compatibility tags" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:8 -msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:12 -msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:16 -msgid "Platform tags for Windows" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:18 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:22 -msgid "Platform tags for macOS (Mac OS X)" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:24 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:28 -msgid "Platform tags for common Linux distributions" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:32 -msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:36 -msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:41 -msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:44 -msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:46 -msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:49 -msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:54 -msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:59 -msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:65 -msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:71 -msgid "Manylinux compatibility support" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:74 -msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:76 -msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:79 -msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "Tool" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux1``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2010``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2014``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux_x_y``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=8.1.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=20.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "auditwheel" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=1.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=2.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.3.0`` [#]_" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:90 -msgid "Platform tags for other \\*nix platforms" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:92 -msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:98 -msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" -msgstr "" - -#: ../source/specifications/pypirc.rst:6 -msgid "The :file:`.pypirc` file" -msgstr "" - -#: ../source/specifications/pypirc.rst:8 -msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." -msgstr "" - -#: ../source/specifications/pypirc.rst:13 -msgid "The format (originally defined by the :ref:`distutils` package) is:" -msgstr "" - -#: ../source/specifications/pypirc.rst:32 -msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:35 -msgid "Each section describing a repository defines three fields:" -msgstr "" - -#: ../source/specifications/pypirc.rst:37 -msgid "``repository``: The URL of the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:38 -msgid "``username``: The registered username on the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:39 -msgid "``password``: The password that will used to authenticate the username." -msgstr "" - -#: ../source/specifications/pypirc.rst:43 -msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." -msgstr "" - -#: ../source/specifications/pypirc.rst:47 -msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" -msgstr "" - -#: ../source/specifications/pypirc.rst:57 -msgid "Common configurations" -msgstr "" - -#: ../source/specifications/pypirc.rst:61 -msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." -msgstr "" - -#: ../source/specifications/pypirc.rst:66 -msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" -msgstr "" - -#: ../source/specifications/pypirc.rst:82 -msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." -msgstr "" - -#: ../source/specifications/pypirc.rst:86 -msgid "Using a PyPI token" -msgstr "" - -#: ../source/specifications/pypirc.rst:88 -msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" -msgstr "" - -#: ../source/specifications/pypirc.rst:97 -msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." -msgstr "" - -#: ../source/specifications/pypirc.rst:103 -msgid "Using another package index" -msgstr "" - -#: ../source/specifications/pypirc.rst:105 -msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" -msgstr "" - -#: ../source/specifications/pypirc.rst:132 -msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:5 -msgid "Recording installed projects" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:7 -msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:12 -msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:21 -msgid "History and change workflow" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:23 -msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:29 -msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:37 -msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:41 -msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:50 -msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:60 -msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:69 -msgid "This ``.dist-info`` directory can contain these files, described in detail below:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:72 -msgid "``METADATA``: contains project metadata" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:73 -msgid "``RECORD``: records the list of installed files." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:74 -msgid "``INSTALLER``: records the name of the tool used to install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:76 -msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:82 -msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:87 -msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:94 -msgid "The METADATA file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:96 -msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:99 -msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:105 -msgid "The RECORD file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:107 -msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:110 -msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:113 -msgid "field delimiter: ``,`` (comma)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:114 -msgid "quoting char: ``\"`` (straight double quote)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:115 -msgid "line terminator: either ``\\r\\n`` or ``\\n``." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:117 -msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:120 -msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:125 -msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:130 -msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:133 -msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:139 -msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:146 -msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:151 -msgid "Here is an example snippet of a possible ``RECORD`` file::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:170 -msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:177 -msgid "The INSTALLER file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:179 -msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:185 -msgid "The file can be terminated by zero or more ASCII whitespace characters." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:187 -msgid "Here are examples of two possible ``INSTALLER`` files::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:195 -msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:201 -msgid "The direct_url.json file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:203 -msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:209 -msgid "Its detailed specification is at :ref:`direct-url`." -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:6 -msgid "Simple repository API" -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:8 -msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:6 -msgid "Source distribution format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:8 -msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:13 -msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:21 -msgid "Source distributions are also known as *sdists* for short." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:24 -msgid "Source distribution file name" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:26 -msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:31 -msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:35 -msgid "Source distribution file format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:37 -msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:45 -msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:48 -msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:6 -msgid "Version specifiers" -msgstr "" - -#: ../source/specifications/version-specifiers.rst:8 -msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:11 -msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." -msgstr "" - -#: ../source/support.rst:3 -msgid "How to Get Support" -msgstr "" - -#: ../source/support.rst:5 -msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." -msgstr "" - -#: ../source/support.rst:8 -msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:5 -msgid "Creating Documentation" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:7 -msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:13 -msgid "Installing Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:14 -msgid "Use ``pip`` to install Sphinx:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:28 -msgid "For other installation methods, see this `installation guide`_ by Sphinx." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:33 -msgid "Getting Started With Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:35 -msgid "Create a ``docs`` directory inside your project to hold your documentation:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:42 -msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:49 -msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:51 -msgid "You can add some information about your project in ``index.rst``, then build them:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:57 -msgid "For more details on the build process, see this `guide`_ by Read The Docs." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:62 -msgid "Other Sources" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:64 -msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/index.rst:4 -msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:5 -msgid "Installing Packages" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:7 -msgid "This section covers the basics of how to install Python :term:`packages `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:10 -msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:28 -msgid "Requirements for Installing Packages" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:30 -msgid "This section describes the steps to follow before installing other Python packages." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:35 -msgid "Ensure you can run Python from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:37 -msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:53 -msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:57 -msgid "If you're a newcomer and you get an error like this:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:66 -msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:72 -msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:82 -msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:87 -msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:99 -msgid "Ensure you can run pip from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:101 -msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:116 -msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:124 -msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:139 -msgid "If that still doesn't allow you to run ``python -m pip``:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:141 -msgid "Securely Download `get-pip.py `_ [1]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:144 -msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:150 -msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:159 -msgid "Ensure pip, setuptools, and wheel are up to date" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:161 -msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:169 -msgid "Optionally, create a virtual environment" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:171 -msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:188 -msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:195 -msgid "Creating Virtual Environments" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:197 -msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:203 -msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:209 -msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:213 -msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:216 -msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:220 -msgid "Currently, there are two common tools for creating Python virtual environments:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:222 -msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:225 -msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:230 -msgid "The basic usage is like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:232 -msgid "Using `venv`_:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:248 -msgid "Using :ref:`virtualenv`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:264 -msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:266 -msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:271 -msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:281 -msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:288 -msgid "Use pip for Installing" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:290 -msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:297 -msgid "Installing from PyPI" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:299 -msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:307 -msgid "To install the latest version of \"SomeProject\":" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:321 -msgid "To install a specific version:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:335 -msgid "To install greater than or equal to one version and less than another:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:350 -msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:365 -msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:370 -msgid "Source Distributions vs Wheels" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:372 -msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:378 -msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:383 -msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:391 -msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:408 -msgid "Installing to the User Site" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:410 -msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:425 -msgid "For more information see the `User Installs `_ section from the pip docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:429 -msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:432 -msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:440 -msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:446 -msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:462 -msgid "Install a list of requirements specified in a :ref:`Requirements File `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:478 -msgid "Installing from VCS" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:480 -msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:502 -msgid "Installing from other Indexes" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:504 -msgid "Install from an alternate index" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:518 -msgid "Search an additional index during install, in addition to :term:`PyPI `" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:534 -msgid "Installing from a local src tree" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:537 -msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:554 -msgid "You can also install normally from src" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:571 -msgid "Install a particular source archive file." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:585 -msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:605 -msgid "Installing from other sources" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:607 -msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:619 -msgid "Installing Prereleases" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:621 -msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:637 -msgid "Installing Setuptools \"Extras\"" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:639 -msgid "Install `setuptools extras`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:659 -msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:668 -msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:673 -msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:4 -msgid "Managing Application Dependencies" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:6 -msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:9 -msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:13 -msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:17 -msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:24 -msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:30 -msgid "Installing Pipenv" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:32 -msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:38 -msgid "Use ``pip`` to install Pipenv:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:54 -msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:65 -msgid "Installing packages for your project" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:67 -msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:76 -msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:112 -msgid "Using installed packages" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:114 -msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:125 -msgid "Then you can run this script using ``pipenv run``:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:131 -msgid "You should get output similar to this:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:137 -msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:143 -#: ../source/tutorials/packaging-projects.rst:594 -msgid "Next steps" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:145 -msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:148 -msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:151 -msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:160 -msgid "Other Tools for Application Dependency Management" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:162 -msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:166 -msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:172 -msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:175 -msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:177 -msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:2 -msgid "Packaging Python Projects" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:4 -msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:10 -msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:18 -msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:35 -msgid "A simple project" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:37 -msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:41 -msgid "Create the following file structure locally:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:51 -msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:54 -msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:63 -msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:67 -msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:75 -msgid "Creating the package files" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:77 -msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:95 -msgid "Creating a test directory" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:97 -msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:101 -msgid "Creating pyproject.toml" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:103 -msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:117 -msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:121 -msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:127 -msgid "See :pep:`517` and :pep:`518` for background and details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:131 -msgid "Configuring metadata" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:133 -msgid "There are two types of metadata: static and dynamic." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:135 -msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:137 -msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:141 -msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:148 -msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:153 -msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:185 -msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:191 -#: ../source/tutorials/packaging-projects.rst:286 -msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:196 -msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:199 -#: ../source/tutorials/packaging-projects.rst:293 -msgid "``author`` and ``author_email`` are used to identify the author of the package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:201 -#: ../source/tutorials/packaging-projects.rst:295 -msgid "``description`` is a short, one-sentence summary of the package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:202 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:206 -#: ../source/tutorials/packaging-projects.rst:300 -msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:208 -#: ../source/tutorials/packaging-projects.rst:302 -msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:211 -#: ../source/tutorials/packaging-projects.rst:305 -msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:213 -#: ../source/tutorials/packaging-projects.rst:307 -msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:221 -msgid "In the ``options`` category, we have controls for setuptools itself:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:223 -msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:227 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:234 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:238 -#: ../source/tutorials/packaging-projects.rst:329 -msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:244 -msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:248 -msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:283 -msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:291 -msgid "``version`` is the package version. See :pep:`440` for more details on versions." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:296 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:314 -msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:319 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:325 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:333 -msgid "Creating README.md" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:335 -msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:347 -msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:354 -msgid "Creating a LICENSE" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:356 -msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:387 -msgid "Including other files" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:389 -msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:393 -msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:402 -msgid "Generating distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:404 -msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:408 -msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:422 -msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:425 -msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:439 -msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:449 -msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:458 -msgid "Uploading the distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:460 -msgid "Finally, it's time to upload your package to the Python Package Index!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:462 -msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:470 -msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:477 -msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:492 -msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:506 -msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:510 -msgid "After the command completes, you should see output similar to this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:523 -msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:528 -msgid "Installing your newly uploaded package" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:530 -msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:546 -msgid "Make sure to specify your username in the package name!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:548 -msgid "pip should install the package from TestPyPI and the output should look something like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:558 -msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:565 -msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:580 -msgid "and import the package:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:588 -msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:596 -msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:599 -msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:604 -msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:608 -msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:610 -msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:613 -msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:617 -msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:619 -msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:622 -msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:624 -msgid "Read about :doc:`/guides/packaging-binary-extensions`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:625 -msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." -msgstr "" From 6d909a95e21c35cb5da50dda066c22b1322fcd5b Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Sat, 27 Nov 2021 19:26:48 +0100 Subject: [PATCH 0208/1072] Always push to the translation branch --- .github/workflows/translation.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index bcfc07f11..fd57fcf1b 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -71,5 +71,6 @@ jobs: - name: >- Push the updated POT file back to '${{ env.I18N_BRANCH }}' branch on GitHub + if: always() run: | git push --atomic origin 'HEAD:${{ env.I18N_BRANCH }}' From d82e88727cf2d9b0f038d98284bb20888504a351 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Sat, 27 Nov 2021 19:27:23 +0100 Subject: [PATCH 0209/1072] Forcefully include POT file in translation branch --- .github/workflows/translation.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index fd57fcf1b..3a3ab307f 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -64,6 +64,7 @@ jobs: - name: Commit the POT file to Git run: | git_hash=$(git rev-parse --short "${GITHUB_SHA}") + git add --force locales/messages.pot git commit \ -m "Update messages.pot as of version ${git_hash}" \ locales/messages.pot From 1f40cfc709ee297594c93bdc8347c6bc20539133 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Sat, 27 Nov 2021 19:30:03 +0100 Subject: [PATCH 0210/1072] Make indentation consistent @ translation workflow --- .github/workflows/translation.yml | 116 +++++++++++++++--------------- 1 file changed, 58 insertions(+), 58 deletions(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index 3a3ab307f..3f4609c70 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -1,77 +1,77 @@ name: Translation on: - workflow_run: - workflows: - - Test - branches: - - main - types: - - completed + workflow_run: + workflows: + - Test + branches: + - main + types: + - completed env: I18N_BRANCH: translation/source jobs: - build: - runs-on: ubuntu-latest + build: + runs-on: ubuntu-latest - steps: - - name: Grab the repo src - uses: actions/checkout@v2 - with: - fetch-depth: 0 # To reach the common commit - - name: Setup git user as [bot] - # Refs: - # * https://github.community/t/github-actions-bot-email-address/17204/6 - # * https://github.com/actions/checkout/issues/13#issuecomment-724415212 - uses: fregante/setup-git-user@v1.0.1 + steps: + - name: Grab the repo src + uses: actions/checkout@v2 + with: + fetch-depth: 0 # To reach the common commit + - name: Setup git user as [bot] + # Refs: + # * https://github.community/t/github-actions-bot-email-address/17204/6 + # * https://github.com/actions/checkout/issues/13#issuecomment-724415212 + uses: fregante/setup-git-user@v1.0.1 - - name: Switch to the translation source branch - run: | - sh -x + - name: Switch to the translation source branch + run: | + sh -x - git fetch origin \ - '+refs/heads/${{ - env.I18N_BRANCH - }}:refs/remotes/origin/${{ - env.SRC_BRANCH - }}' + git fetch origin \ + '+refs/heads/${{ + env.I18N_BRANCH + }}:refs/remotes/origin/${{ + env.SRC_BRANCH + }}' - git checkout -B '${{ env.I18N_BRANCH }}' \ - 'origin/${{ env.I18N_BRANCH }}' + git checkout -B '${{ env.I18N_BRANCH }}' \ + 'origin/${{ env.I18N_BRANCH }}' - - name: >- - Merge '${{ github.event.repository.default_branch }}' - to '${{ env.I18N_BRANCH }}' - run: | - sh -x + - name: >- + Merge '${{ github.event.repository.default_branch }}' + to '${{ env.I18N_BRANCH }}' + run: | + sh -x - git merge '${{ github.event.repository.default_branch }}' + git merge '${{ github.event.repository.default_branch }}' - - name: Set up Python - uses: actions/setup-python@v2 - with: - python-version: >- - 3.10 + - name: Set up Python + uses: actions/setup-python@v2 + with: + python-version: >- + 3.10 - - name: Install Python tooling - run: python -m pip install --upgrade nox virtualenv + - name: Install Python tooling + run: python -m pip install --upgrade nox virtualenv - - name: Generate a fresh POT file out of RST documents - run: python -m nox -s translation + - name: Generate a fresh POT file out of RST documents + run: python -m nox -s translation - - name: Commit the POT file to Git - run: | - git_hash=$(git rev-parse --short "${GITHUB_SHA}") - git add --force locales/messages.pot - git commit \ - -m "Update messages.pot as of version ${git_hash}" \ - locales/messages.pot + - name: Commit the POT file to Git + run: | + git_hash=$(git rev-parse --short "${GITHUB_SHA}") + git add --force locales/messages.pot + git commit \ + -m "Update messages.pot as of version ${git_hash}" \ + locales/messages.pot - - name: >- - Push the updated POT file back to '${{ env.I18N_BRANCH }}' - branch on GitHub - if: always() - run: | - git push --atomic origin 'HEAD:${{ env.I18N_BRANCH }}' + - name: >- + Push the updated POT file back to '${{ env.I18N_BRANCH }}' + branch on GitHub + if: always() + run: | + git push --atomic origin 'HEAD:${{ env.I18N_BRANCH }}' From e8170d86e717885230f75d07f9518729037262d0 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Mon, 29 Nov 2021 03:24:04 +0100 Subject: [PATCH 0211/1072] Improve the grammar of the GHA bot Git setup step Co-authored-by: Rafael Fontenelle --- .github/workflows/translation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index 3f4609c70..3dacc497d 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -21,7 +21,7 @@ jobs: uses: actions/checkout@v2 with: fetch-depth: 0 # To reach the common commit - - name: Setup git user as [bot] + - name: Set up git user as [bot] # Refs: # * https://github.community/t/github-actions-bot-email-address/17204/6 # * https://github.com/actions/checkout/issues/13#issuecomment-724415212 From 59a3f428f5c3617b8d09ce7621c9b8cf06933fa4 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Sun, 5 Dec 2021 00:57:48 +0100 Subject: [PATCH 0212/1072] Fix branch variable name in translation workflow --- .github/workflows/translation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index 3dacc497d..7b1bf40d4 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -35,7 +35,7 @@ jobs: '+refs/heads/${{ env.I18N_BRANCH }}:refs/remotes/origin/${{ - env.SRC_BRANCH + env.I18N_BRANCH }}' git checkout -B '${{ env.I18N_BRANCH }}' \ From d0536c070ff16f90212630fe99159ded7525dcdf Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sun, 5 Dec 2021 13:30:17 +0800 Subject: [PATCH 0213/1072] Use Sphinx 4.3.1 --- requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements.txt b/requirements.txt index efb73f167..c4113b12b 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,4 +1,4 @@ -sphinx==4.0.3 +sphinx==4.3.1 sphinx-autobuild==0.7.1 sphinx-inline-tabs==2021.4.11b9 python-docs-theme==2021.5 From e9a488cbb2dab74bcbffac94479656aae65c4232 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Sun, 5 Dec 2021 18:48:43 +0100 Subject: [PATCH 0214/1072] Drop translations from the 'main' branch --- .gitignore | 3 +- locales/.gitignore | 1 - locales/eo/LC_MESSAGES/messages.po | 13576 ---------------- locales/es/LC_MESSAGES/messages.po | 9293 ----------- locales/fr/LC_MESSAGES/messages.po | 9379 ----------- locales/ja/LC_MESSAGES/messages.po | 9596 ------------ locales/pt_BR/LC_MESSAGES/messages.po | 18229 ---------------------- locales/ro/LC_MESSAGES/messages.po | 9257 ----------- locales/ru/LC_MESSAGES/messages.po | 9302 ----------- locales/si/LC_MESSAGES/messages.po | 9253 ----------- locales/uk/LC_MESSAGES/messages.po | 13763 ---------------- locales/zh_Hans/LC_MESSAGES/messages.po | 13922 ----------------- locales/zh_Hant/LC_MESSAGES/messages.po | 13545 ---------------- 13 files changed, 2 insertions(+), 129117 deletions(-) delete mode 100644 locales/.gitignore delete mode 100644 locales/eo/LC_MESSAGES/messages.po delete mode 100644 locales/es/LC_MESSAGES/messages.po delete mode 100644 locales/fr/LC_MESSAGES/messages.po delete mode 100644 locales/ja/LC_MESSAGES/messages.po delete mode 100644 locales/pt_BR/LC_MESSAGES/messages.po delete mode 100644 locales/ro/LC_MESSAGES/messages.po delete mode 100644 locales/ru/LC_MESSAGES/messages.po delete mode 100644 locales/si/LC_MESSAGES/messages.po delete mode 100644 locales/uk/LC_MESSAGES/messages.po delete mode 100644 locales/zh_Hans/LC_MESSAGES/messages.po delete mode 100644 locales/zh_Hant/LC_MESSAGES/messages.po diff --git a/.gitignore b/.gitignore index b430bcdba..301e238bb 100644 --- a/.gitignore +++ b/.gitignore @@ -3,4 +3,5 @@ build/ .nox *.pyc __pycache__ -.DS_Store \ No newline at end of file +.DS_Store +/locales/ diff --git a/locales/.gitignore b/locales/.gitignore deleted file mode 100644 index cd1f2c943..000000000 --- a/locales/.gitignore +++ /dev/null @@ -1 +0,0 @@ -*.mo diff --git a/locales/eo/LC_MESSAGES/messages.po b/locales/eo/LC_MESSAGES/messages.po deleted file mode 100644 index 97ede6591..000000000 --- a/locales/eo/LC_MESSAGES/messages.po +++ /dev/null @@ -1,13576 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2013–2020, PyPA -# This file is distributed under the same license as the Python Packaging User Guide package. -# phlostically , 2021. -# meowmeowmeowcat , 2021. -msgid "" -msgstr "" -"Project-Id-Version: Python Packaging User Guide\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-08-06 05:45+0000\n" -"Last-Translator: meowmeowmeowcat \n" -"Language-Team: Esperanto \n" -"Language: eo\n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=UTF-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Plural-Forms: nplurals=2; plural=n != 1;\n" -"X-Generator: Weblate 4.8-dev\n" - -#: ../source/contribute.rst:5 -msgid "Contribute to this guide" -msgstr "Kontribui al ĉi tiu gvidilo" - -#: ../source/contribute.rst:7 -msgid "" -"The |PyPUG| welcomes contributors! There are lots of ways to help out, " -"including:" -msgstr "" -"La |PyPUG| bonvenigas kontribuantojn! Jen kelke el multaj manieroj helpi nin:" - -#: ../source/contribute.rst:10 -msgid "Reading the guide and giving feedback" -msgstr "Legi la gvidilon kaj doni opiniojn pri ĝi" - -#: ../source/contribute.rst:11 -msgid "Reviewing new contributions" -msgstr "Revizii novajn kontribuojn" - -#: ../source/contribute.rst:12 -msgid "Revising existing content" -msgstr "Poluri ekzistantan enhavon" - -#: ../source/contribute.rst:13 -msgid "Writing new content" -msgstr "Verki novan enhavon" - -#: ../source/contribute.rst:15 -msgid "" -"Most of the work on the |PyPUG| takes place on the `project's GitHub " -"repository`__. To get started, check out the list of `open issues`__ and " -"`pull requests`__. If you're planning to write or edit the guide, please " -"read the :ref:`style guide `." -msgstr "" - -#: ../source/contribute.rst:24 -msgid "" -"By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of " -"Conduct`__." -msgstr "" - -#: ../source/contribute.rst:31 -msgid "Documentation types" -msgstr "Tipoj de dokumentaro" - -#: ../source/contribute.rst:33 -msgid "" -"This project consists of four distinct documentation types with specific " -"purposes. When proposing new additions to the project please pick the " -"appropriate documentation type." -msgstr "" - -#: ../source/contribute.rst:38 ../source/tutorials/index.rst:2 -msgid "Tutorials" -msgstr "Lerniloj" - -#: ../source/contribute.rst:40 -msgid "" -"Tutorials are focused on teaching the reader new concepts by accomplishing a " -"goal. They are opinionated step-by-step guides. They do not include " -"extraneous warnings or information. `example tutorial-style document`_." -msgstr "" - -#: ../source/contribute.rst:47 ../source/guides/index.rst:2 -msgid "Guides" -msgstr "Gvidiloj" - -#: ../source/contribute.rst:49 -msgid "" -"Guides are focused on accomplishing a specific task and can assume some " -"level of pre-requisite knowledge. These are similar to tutorials, but have a " -"narrow and clear focus and can provide lots of caveats and additional " -"information as needed. They may also discuss multiple approaches to " -"accomplishing the task. :doc:`example guide-style document `." -msgstr "" - -#: ../source/contribute.rst:56 ../source/discussions/index.rst:2 -msgid "Discussions" -msgstr "Diskutoj" - -#: ../source/contribute.rst:58 -msgid "" -"Discussions are focused on understanding and information. These explore a " -"specific topic without a specific goal in mind. :doc:`example discussion-" -"style document `." -msgstr "" - -#: ../source/contribute.rst:63 -msgid "Specifications" -msgstr "Specifiloj" - -#: ../source/contribute.rst:65 -msgid "" -"Specifications are reference documention focused on comprehensively " -"documenting an agreed-upon interface for interoperability between packaging " -"tools. :doc:`example specification-style document `." -msgstr "" - -#: ../source/contribute.rst:73 -msgid "Building the guide locally" -msgstr "" - -#: ../source/contribute.rst:75 -msgid "" -"Though not required to contribute, it may be useful to build this guide " -"locally in order to test your changes. In order to build this guide locally, " -"you'll need:" -msgstr "" - -#: ../source/contribute.rst:79 -msgid "" -"`Nox `_. You can install or upgrade " -"nox using ``pip``::" -msgstr "" -"`Nox `_. Vi povas instali aŭ " -"ĝisdatigi nox per ``pip``::" - -#: ../source/contribute.rst:84 -msgid "" -"Python 3.6. Our build scripts are designed to work with Python 3.6 only. See " -"the `Hitchhiker's Guide to Python installation instructions`_ to install " -"Python 3.6 on your operating system." -msgstr "" - -#: ../source/contribute.rst:91 -msgid "" -"To build the guide, run the following bash command in the source folder::" -msgstr "" - -#: ../source/contribute.rst:95 -msgid "" -"After the process has completed you can find the HTML output in the ``./" -"build/html`` directory. You can open the ``index.html`` file to view the " -"guide in web browser, but it's recommended to serve the guide using an HTTP " -"server." -msgstr "" - -#: ../source/contribute.rst:100 -msgid "" -"You can build the guide and serve it via an HTTP server using the following " -"command::" -msgstr "" - -#: ../source/contribute.rst:105 -msgid "The guide will be browsable via http://localhost:8000." -msgstr "La gvidilo estos legebla ĉe http://localhost:8000." - -#: ../source/contribute.rst:109 -msgid "Where the guide is deployed" -msgstr "" - -#: ../source/contribute.rst:111 -msgid "" -"The guide is deployed via ReadTheDocs and the configuration lives at https://" -"readthedocs.org/projects/python-packaging-user-guide/. It's served from a " -"custom domain and fronted by Fast.ly." -msgstr "" - -#: ../source/contribute.rst:117 -msgid "Style guide" -msgstr "Rekomendoj pri stilo" - -#: ../source/contribute.rst:119 -msgid "" -"This style guide has recommendations for how you should write the |PyPUG|. " -"Before you start writing, please review it. By following the style guide, " -"your contributions will help add to a cohesive whole and make it easier for " -"your contributions to be accepted into the project." -msgstr "" - -#: ../source/contribute.rst:126 -msgid "Purpose" -msgstr "Celo" - -#: ../source/contribute.rst:128 -msgid "" -"The purpose of the |PyPUG| is to be the authoritative resource on how to " -"package, publish, and install Python projects using current tools." -msgstr "" - -#: ../source/contribute.rst:133 -msgid "Scope" -msgstr "Amplekso" - -#: ../source/contribute.rst:135 -msgid "" -"The guide is meant to answer questions and solve problems with accurate and " -"focused recommendations." -msgstr "" - -#: ../source/contribute.rst:138 -msgid "" -"The guide isn't meant to be comprehensive and it's not meant to replace " -"individual projects' documentation. For example, pip has dozens of commands, " -"options, and settings. The pip documentation describes each of them in " -"detail, while this guide describes only the parts of pip that are needed to " -"complete the specific tasks described in this guide." -msgstr "" - -#: ../source/contribute.rst:146 -msgid "Audience" -msgstr "" - -#: ../source/contribute.rst:148 -msgid "The audience of this guide is anyone who uses Python with packages." -msgstr "" - -#: ../source/contribute.rst:150 -msgid "" -"Don't forget that the Python community is big and welcoming. Readers may not " -"share your age, gender, education, culture, and more, but they deserve to " -"learn about packaging just as much as you do." -msgstr "" - -#: ../source/contribute.rst:154 -msgid "" -"In particular, keep in mind that not all people who use Python see " -"themselves as programmers. The audience of this guide includes astronomers " -"or painters or students as well as professional software developers." -msgstr "" - -#: ../source/contribute.rst:160 -msgid "Voice and tone" -msgstr "Voĉo kaj tono" - -#: ../source/contribute.rst:162 -msgid "" -"When writing this guide, strive to write with a voice that's approachable " -"and humble, even if you have all the answers." -msgstr "" - -#: ../source/contribute.rst:165 -msgid "" -"Imagine you're working on a Python project with someone you know to be smart " -"and skilled. You like working with them and they like working with you. That " -"person has asked you a question and you know the answer. How do you respond? " -"*That* is how you should write this guide." -msgstr "" - -#: ../source/contribute.rst:170 -msgid "" -"Here's a quick check: try reading aloud to get a sense for your writing's " -"voice and tone. Does it sound like something you would say or does it sound " -"like you're acting out a part or giving a speech? Feel free to use " -"contractions and don't worry about sticking to fussy grammar rules. You are " -"hereby granted permission to end a sentence in a preposition, if that's what " -"you want to end it with." -msgstr "" - -#: ../source/contribute.rst:177 -msgid "" -"When writing the guide, adjust your tone for the seriousness and difficulty " -"of the topic. If you're writing an introductory tutorial, it's OK to make a " -"joke, but if you're covering a sensitive security recommendation, you might " -"want to avoid jokes altogether." -msgstr "" - -#: ../source/contribute.rst:184 -msgid "Conventions and mechanics" -msgstr "" - -#: ../source/contribute.rst:192 -msgid "**Write to the reader**" -msgstr "**Verku por la leganto**" - -#: ../source/contribute.rst:187 -msgid "" -"When giving recommendations or steps to take, address the reader as *you* or " -"use the imperative mood." -msgstr "" -"Kiam vi donas rekomendojn aŭ farendaĵojn, alparolu la leganton kiel «vi», aŭ " -"uzu la imperativon." - -#: ../source/contribute.rst:0 -msgid "Wrong: To install it, the user runs…" -msgstr "Netaŭga: Por instali ĝin, la uzanto rulas…" - -#: ../source/contribute.rst:0 -msgid "Right: You can install it by running…" -msgstr "Taŭga: Vi povas instali ĝin per rulado de…" - -#: ../source/contribute.rst:0 -msgid "Right: To install it, run…" -msgstr "Taŭga: Por instali ĝin, rulu…" - -#: ../source/contribute.rst:198 -msgid "**State assumptions**" -msgstr "**Klarigu supozojn**" - -#: ../source/contribute.rst:195 -msgid "" -"Avoid making unstated assumptions. Reading on the web means that any page of " -"the guide may be the first page of the guide that the reader ever sees. If " -"you're going to make assumptions, then say what assumptions that you're " -"going to make." -msgstr "" - -#: ../source/contribute.rst:203 -msgid "**Cross-reference generously**" -msgstr "**Interreferencu ofte**" - -#: ../source/contribute.rst:201 -msgid "" -"The first time you mention a tool or practice, link to the part of the guide " -"that covers it, or link to a relevant document elsewhere. Save the reader a " -"search." -msgstr "" - -#: ../source/contribute.rst:213 -msgid "**Respect naming practices**" -msgstr "**Respektu nomojn**" - -#: ../source/contribute.rst:206 -msgid "" -"When naming tools, sites, people, and other proper nouns, use their " -"preferred capitalization." -msgstr "" -"Kiam vi nomas ilojn, retejojn, homojn kaj aliajn proprajn nomojn, uzu iliajn " -"preferatajn usklojn." - -#: ../source/contribute.rst:0 -msgid "Wrong: Pip uses…" -msgstr "Netaŭga: Pip uzas…" - -#: ../source/contribute.rst:0 -msgid "Right: pip uses…" -msgstr "Taŭga: pip uzas…" - -#: ../source/contribute.rst:0 -msgid "Wrong: …hosted on github." -msgstr "Netaŭga: …gastigata ĉe github." - -#: ../source/contribute.rst:0 -msgid "Right: …hosted on GitHub." -msgstr "Taŭga: …gastigata ĉe GitHub." - -#: ../source/contribute.rst:222 -msgid "**Use a gender-neutral style**" -msgstr "**Uzu seksneŭtralan stilon**" - -#: ../source/contribute.rst:216 -msgid "" -"Often, you'll address the reader directly with *you*, *your* and *yours*. " -"Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or " -"avoid pronouns entirely." -msgstr "" -"Ofte vi rekte alparolu la leganton per *vi*, *vin* aŭ *via*. Alie, uzu " -"seksneŭtralajn pronomojn *ili*, *ŝ/li* aŭ entute evitu pronomojn." - -#: ../source/contribute.rst:0 -msgid "Wrong: A maintainer uploads the file. Then he…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then they…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then the maintainer…" -msgstr "" - -#: ../source/contribute.rst:234 -msgid "**Headings**" -msgstr "**Titoloj de paragrafoj**" - -#: ../source/contribute.rst:225 -msgid "" -"Write headings that use words the reader is searching for. A good way to do " -"this is to have your heading complete an implied question. For example, a " -"reader might want to know *How do I install MyLibrary?* so a good heading " -"might be *Install MyLibrary*." -msgstr "" - -#: ../source/contribute.rst:230 -msgid "" -"In section headings, use sentence case. In other words, write headings as " -"you would write a typical sentence." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: Things You Should Know About Python" -msgstr "Netaŭga: Sciindaĵoj Pri Python" - -#: ../source/contribute.rst:0 -msgid "Right: Things you should know about Python" -msgstr "Taŭga: Sciindaĵoj pri Python" - -#: ../source/contribute.rst:237 -msgid "**Numbers**" -msgstr "**Nombroj**" - -#: ../source/contribute.rst:237 -msgid "" -"In body text, write numbers one through nine as words. For other numbers or " -"numbers in tables, use numerals." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:4 -msgid "Deploying Python applications" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Page Status" -msgstr "Stato de la paĝo" - -#: ../source/discussions/deploying-python-applications.rst:6 -#: ../source/guides/index-mirrors-and-caches.rst:7 -#: ../source/guides/installing-using-linux-tools.rst:7 -#: ../source/guides/packaging-binary-extensions.rst:7 -#: ../source/guides/supporting-multiple-python-versions.rst:7 -#: ../source/guides/supporting-windows-using-appveyor.rst:5 -msgid "Incomplete" -msgstr "Nekompleta" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Last Reviewed" -msgstr "Laste reviziita" - -#: ../source/discussions/deploying-python-applications.rst:7 -msgid "2014-11-11" -msgstr "2014-11-11" - -#: ../source/discussions/deploying-python-applications.rst:11 -#: ../source/discussions/install-requires-vs-requirements.rst:9 -#: ../source/guides/analyzing-pypi-package-downloads.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:22 -#: ../source/guides/index-mirrors-and-caches.rst:12 -#: ../source/guides/installing-scientific-packages.rst:9 -#: ../source/guides/packaging-binary-extensions.rst:17 -#: ../source/guides/supporting-multiple-python-versions.rst:12 -#: ../source/guides/supporting-windows-using-appveyor.rst:15 -#: ../source/overview.rst:23 ../source/specifications/core-metadata.rst:38 -#: ../source/specifications/direct-url.rst:14 -#: ../source/tutorials/installing-packages.rst:23 -msgid "Contents" -msgstr "Enhavoj" - -#: ../source/discussions/deploying-python-applications.rst:14 -msgid "Overview" -msgstr "Superrigardo" - -#: ../source/discussions/deploying-python-applications.rst:18 -msgid "Supporting multiple hardware platforms" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:40 -msgid "OS packaging & installers" -msgstr "Pakado kaj instaliloj por mastrumaj sistemoj" - -#: ../source/discussions/deploying-python-applications.rst:52 -msgid "Windows" -msgstr "Windows" - -#: ../source/discussions/deploying-python-applications.rst:61 -msgid "Pynsist" -msgstr "Pynsist" - -#: ../source/discussions/deploying-python-applications.rst:63 -msgid "" -"`Pynsist `__ is a tool that bundles Python " -"programs together with the Python-interpreter into a single installer based " -"on NSIS. In most cases, packaging only requires the user to choose a version " -"of the Python-interpreter and declare the dependencies of the program. The " -"tool downloads the specified Python-interpreter for Windows and packages it " -"with all the dependencies in a single Windows-executable installer." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:70 -msgid "" -"The installed program can be started from a shortcut that the installer adds " -"to the start-menu. It uses a Python interpreter installed within its " -"application directory, independent of any other Python installation on the " -"computer." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:74 -msgid "" -"A big advantage of Pynsist is that the Windows packages can be built on " -"Linux. There are several examples for different kinds of programs (console, " -"GUI) in the `documentation `__. The tool is " -"released under the MIT-licence." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:80 -msgid "Application bundles" -msgstr "Aplikprogramaj faskoj" - -#: ../source/discussions/deploying-python-applications.rst:91 -msgid "Configuration management" -msgstr "Administrado de agordoj" - -#: ../source/discussions/index.rst:4 -msgid "" -"**Discussions** are focused on providing comprehensive information about a " -"specific topic. If you're just trying to get stuff done, see :doc:`/guides/" -"index`." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:5 -msgid "install_requires vs requirements files" -msgstr "install_requires kontraste kun requirements.txt" - -#: ../source/discussions/install-requires-vs-requirements.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:382 -msgid "install_requires" -msgstr "install_requires" - -#: ../source/discussions/install-requires-vs-requirements.rst:14 -msgid "" -"``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that " -"should be used to specify what a project **minimally** needs to run " -"correctly. When the project is installed by :ref:`pip`, this is the " -"specification that is used to install its dependencies." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:19 -msgid "" -"For example, if the project requires A and B, your ``install_requires`` " -"would be like so:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:29 -msgid "" -"Additionally, it's best practice to indicate any known lower or upper bounds." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:31 -msgid "" -"For example, it may be known, that your project requires at least v1 of 'A', " -"and v2 of 'B', so it would be like so:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:41 -msgid "" -"It may also be known that project A follows semantic versioning, and that v2 " -"of 'A' will indicate a break in compatibility, so it makes sense to not " -"allow v2:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:51 -msgid "" -"It is not considered best practice to use ``install_requires`` to pin " -"dependencies to specific versions, or to specify sub-dependencies (i.e. " -"dependencies of your dependencies). This is overly-restrictive, and " -"prevents the user from gaining the benefit of dependency upgrades." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:56 -msgid "" -"Lastly, it's important to understand that ``install_requires`` is a listing " -"of \"Abstract\" requirements, i.e just names and version restrictions that " -"don't determine where the dependencies will be fulfilled from (i.e. from " -"what index or source). The where (i.e. how they are to be made \"Concrete" -"\") is to be determined at install time using :ref:`pip` options. [1]_" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:64 -#: ../source/tutorials/installing-packages.rst:460 -msgid "Requirements files" -msgstr "Dosiero requirements.txt" - -#: ../source/discussions/install-requires-vs-requirements.rst:66 -msgid "" -":ref:`Requirements Files ` described most simply, " -"are just a list of :ref:`pip:pip install` arguments placed into a file." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:69 -msgid "" -"Whereas ``install_requires`` defines the dependencies for a single project, :" -"ref:`Requirements Files ` are often used to define " -"the requirements for a complete Python environment." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:73 -msgid "" -"Whereas ``install_requires`` requirements are minimal, requirements files " -"often contain an exhaustive listing of pinned versions for the purpose of " -"achieving :ref:`repeatable installations ` of a complete " -"environment." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:78 -msgid "" -"Whereas ``install_requires`` requirements are \"Abstract\", i.e. not " -"associated with any particular index, requirements files often contain pip " -"options like ``--index-url`` or ``--find-links`` to make requirements " -"\"Concrete\", i.e. associated with a particular index or directory of " -"packages. [1]_" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:84 -msgid "" -"Whereas ``install_requires`` metadata is automatically analyzed by pip " -"during an install, requirements files are not, and only are used when a user " -"specifically installs them using ``python -m pip install -r``." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:90 -msgid "" -"For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad." -"io/2013/07/setup-vs-requirement/." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:6 -msgid "pip vs easy_install" -msgstr "pip kontraste kun easy_install" - -#: ../source/discussions/pip-vs-easy-install.rst:9 -msgid "" -":ref:`easy_install `, now `deprecated`_, was released in 2004 " -"as part of :ref:`setuptools`. It was notable at the time for installing :" -"term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing " -"dependencies." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:14 -msgid "" -":ref:`pip` came later in 2008, as alternative to :ref:`easy_install " -"`, although still largely built on top of :ref:`setuptools` " -"components. It was notable at the time for *not* installing packages as :" -"term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' " -"packages from :term:`sdists `), and " -"introducing the idea of :ref:`Requirements Files `, " -"which gave users the power to easily replicate environments." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:22 -msgid "" -"Here's a breakdown of the important differences between pip and the " -"deprecated easy_install:" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**pip**" -msgstr "**pip**" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**easy_install**" -msgstr "**easy_install**" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -msgid "Installs from :term:`Wheels `" -msgstr "Instali el :term:`Wheel `" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Yes" -msgstr "Jes" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:30 -#: ../source/discussions/pip-vs-easy-install.rst:32 -#: ../source/discussions/pip-vs-easy-install.rst:35 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:51 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "No" -msgstr "Ne" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Uninstall Packages" -msgstr "Malinstali Pakojn" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Yes (``python -m pip uninstall``)" -msgstr "Jes (``python -m pip uninstall``)" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Dependency Overrides" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Yes (:ref:`Requirements Files `)" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "List Installed Packages" -msgstr "Listigi instalitajn pakojn" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" -msgstr "Jes (``python -m pip list`` kaj ``python -m pip freeze``)" - -#: ../source/discussions/pip-vs-easy-install.rst:38 -msgid ":pep:`438` Support" -msgstr "Subteno de :pep:`438`" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Installation format" -msgstr "Instala dosierformo" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "'Flat' packages with :file:`egg-info` metadata." -msgstr "Plata pako kun metadatenoj en :file:`egg-info`." - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Encapsulated Egg format" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:44 -msgid "sys.path modification" -msgstr "modifado de sys.path" - -#: ../source/discussions/pip-vs-easy-install.rst:48 -msgid "Installs from :term:`Eggs `" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "`pylauncher support`_" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "Yes [1]_" -msgstr "Jes [1]_" - -#: ../source/discussions/pip-vs-easy-install.rst:54 -msgid ":ref:`Multi-version Installs`" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Exclude scripts during install" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "per project index" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Only in virtualenv" -msgstr "Nur en virtualenv" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Yes, via setup.cfg" -msgstr "Jes, per setup.cfg" - -#: ../source/discussions/pip-vs-easy-install.rst:68 -msgid "" -"https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" -"launcher" -msgstr "" -"https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" -"launcher" - -#: ../source/discussions/wheel-vs-egg.rst:5 -msgid "Wheel vs Egg" -msgstr "Wheel kontraste kun Egg" - -#: ../source/discussions/wheel-vs-egg.rst:7 -msgid "" -":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support " -"the use case of needing an install artifact that doesn't require building or " -"compilation, which can be costly in testing and production workflows." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:11 -msgid "" -"The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas " -"the :term:`Wheel` format was introduced by :pep:`427` in 2012." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:14 -msgid "" -":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:17 -msgid "" -"Here's a breakdown of the important differences between :term:`Wheel` and :" -"term:`Egg`." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:20 -msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:22 -msgid "" -":term:`Wheel` is a :term:`distribution ` format, i.e a " -"packaging format. [1]_ :term:`Egg` was both a distribution format and a " -"runtime installation format (if left zipped), and was designed to be " -"importable." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:26 -msgid "" -":term:`Wheel` archives do not include .pyc files. Therefore, when the " -"distribution only contains Python files (i.e. no compiled extensions), and " -"is compatible with Python 2 and 3, it's possible for a wheel to be " -"\"universal\", similar to an :term:`sdist `." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:31 -msgid "" -":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. " -"Egg used ``.egg-info``." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:34 -msgid "" -":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single " -"wheel archive can indicate its compatibility with a number of Python " -"language versions and implementations, ABIs, and system architectures." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:38 -msgid "" -":term:`Wheel` is versioned. Every wheel file contains the version of the " -"wheel specification and the implementation that packaged it." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:41 -msgid "" -":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making " -"it easier to convert to other formats." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:47 -msgid "" -"Circumstantially, in some cases, wheels can be used as an importable runtime " -"format, although :pep:`this is not officially supported at this time <427#is-" -"it-possible-to-import-python-code-directly-from-a-wheel-file>`." -msgstr "" - -#: ../source/glossary.rst:3 -msgid "Glossary" -msgstr "Terminaro" - -#: ../source/glossary.rst:8 -msgid "Binary Distribution" -msgstr "" - -#: ../source/glossary.rst:11 -msgid "" -"A specific kind of :term:`Built Distribution` that contains compiled " -"extensions." -msgstr "" - -#: ../source/glossary.rst:14 -msgid "Built Distribution" -msgstr "" - -#: ../source/glossary.rst:17 -msgid "" -"A :term:`Distribution ` format containing files and " -"metadata that only need to be moved to the correct location on the target " -"system, to be installed. :term:`Wheel` is such a format, whereas distutil's :" -"term:`Source Distribution ` is not, in " -"that it requires a build step before it can be installed. This format does " -"not imply that Python files have to be precompiled (:term:`Wheel` " -"intentionally does not include compiled Python files)." -msgstr "" - -#: ../source/glossary.rst:26 -msgid "Distribution Package" -msgstr "" - -#: ../source/glossary.rst:29 -msgid "" -"A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used " -"to distribute a :term:`Release`. The archive file is what an end-user will " -"download from the internet and install." -msgstr "" - -#: ../source/glossary.rst:34 -msgid "" -"A distribution package is more commonly referred to with the single words " -"\"package\" or \"distribution\", but this guide may use the expanded term " -"when more clarity is needed to prevent confusion with an :term:`Import " -"Package` (which is also commonly called a \"package\") or another kind of " -"distribution (e.g. a Linux distribution or the Python language " -"distribution), which are often referred to with the single term " -"\"distribution\"." -msgstr "" - -#: ../source/glossary.rst:41 -msgid "Egg" -msgstr "Egg" - -#: ../source/glossary.rst:44 -msgid "" -"A :term:`Built Distribution` format introduced by :ref:`setuptools`, which " -"is being replaced by :term:`Wheel`. For details, see `The Internal " -"Structure of Python Eggs `_ and `Python Eggs `_" -msgstr "" - -#: ../source/glossary.rst:49 -msgid "Extension Module" -msgstr "" - -#: ../source/glossary.rst:52 -msgid "" -"A :term:`Module` written in the low-level language of the Python " -"implementation: C/C++ for Python, Java for Jython. Typically contained in a " -"single dynamically loadable pre-compiled file, e.g. a shared object (.so) " -"file for Python extensions on Unix, a DLL (given the .pyd extension) for " -"Python extensions on Windows, or a Java class file for Jython extensions." -msgstr "" - -#: ../source/glossary.rst:59 -msgid "Known Good Set (KGS)" -msgstr "" - -#: ../source/glossary.rst:62 -msgid "" -"A set of distributions at specified versions which are compatible with each " -"other. Typically a test suite will be run which passes all tests before a " -"specific set of packages is declared a known good set. This term is commonly " -"used by frameworks and toolkits which are comprised of multiple individual " -"distributions." -msgstr "" - -#: ../source/glossary.rst:68 -msgid "Import Package" -msgstr "" - -#: ../source/glossary.rst:71 -msgid "" -"A Python module which can contain other modules or recursively, other " -"packages." -msgstr "" - -#: ../source/glossary.rst:74 -msgid "" -"An import package is more commonly referred to with the single word \"package" -"\", but this guide will use the expanded term when more clarity is needed to " -"prevent confusion with a :term:`Distribution Package` which is also commonly " -"called a \"package\"." -msgstr "" - -#: ../source/glossary.rst:78 -msgid "Module" -msgstr "Modulo" - -#: ../source/glossary.rst:81 -msgid "" -"The basic unit of code reusability in Python, existing in one of two types: :" -"term:`Pure Module`, or :term:`Extension Module`." -msgstr "" - -#: ../source/glossary.rst:84 -msgid "Package Index" -msgstr "" - -#: ../source/glossary.rst:87 -msgid "" -"A repository of distributions with a web interface to automate :term:" -"`package ` discovery and consumption." -msgstr "" - -#: ../source/glossary.rst:90 -msgid "Per Project Index" -msgstr "" - -#: ../source/glossary.rst:93 -msgid "" -"A private or other non-canonical :term:`Package Index` indicated by a " -"specific :term:`Project` as the index preferred or required to resolve " -"dependencies of that project." -msgstr "" - -#: ../source/glossary.rst:97 -msgid "Project" -msgstr "Projekto" - -#: ../source/glossary.rst:100 -msgid "" -"A library, framework, script, plugin, application, or collection of data or " -"other resources, or some combination thereof that is intended to be packaged " -"into a :term:`Distribution `." -msgstr "" - -#: ../source/glossary.rst:104 -msgid "" -"Since most projects create :term:`Distributions ` " -"using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:" -"`setuptools`, another practical way to define projects currently is " -"something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:" -"`setup.cfg` file at the root of the project source directory." -msgstr "" - -#: ../source/glossary.rst:110 -msgid "" -"Python projects must have unique names, which are registered on :term:`PyPI " -"`. Each project will then contain one or more :" -"term:`Releases `, and each release may comprise one or more :term:" -"`distributions `." -msgstr "" - -#: ../source/glossary.rst:115 -msgid "" -"Note that there is a strong convention to name a project after the name of " -"the package that is imported to run that project. However, this doesn't have " -"to hold true. It's possible to install a distribution from the project 'foo' " -"and have it provide a package importable only as 'bar'." -msgstr "" - -#: ../source/glossary.rst:121 -msgid "Pure Module" -msgstr "Pura Modulo" - -#: ../source/glossary.rst:124 -msgid "" -"A :term:`Module` written in Python and contained in a single ``.py`` file " -"(and possibly associated ``.pyc`` and/or ``.pyo`` files)." -msgstr "" - -#: ../source/glossary.rst:127 -msgid "Python Packaging Authority (PyPA)" -msgstr "" - -#: ../source/glossary.rst:130 -msgid "" -"PyPA is a working group that maintains many of the relevant projects in " -"Python packaging. They maintain a site at https://www.pypa.io, host projects " -"on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python " -"Discourse forum `__." -msgstr "" - -#: ../source/glossary.rst:139 -msgid "Python Package Index (PyPI)" -msgstr "" - -#: ../source/glossary.rst:142 -msgid "" -"`PyPI `_ is the default :term:`Package Index` for the " -"Python community. It is open to all Python developers to consume and " -"distribute their distributions." -msgstr "" - -#: ../source/glossary.rst:145 -msgid "pypi.org" -msgstr "pypi.org" - -#: ../source/glossary.rst:148 -msgid "" -"`pypi.org `_ is the domain name for the :term:`Python " -"Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi." -"python.org``, in 2017. It is powered by :ref:`warehouse`." -msgstr "" - -#: ../source/glossary.rst:152 -msgid "pyproject.toml" -msgstr "pyproject.toml" - -#: ../source/glossary.rst:155 -msgid "" -"The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." -msgstr "" - -#: ../source/glossary.rst:157 -msgid "Release" -msgstr "" - -#: ../source/glossary.rst:160 -msgid "" -"A snapshot of a :term:`Project` at a particular point in time, denoted by a " -"version identifier." -msgstr "" - -#: ../source/glossary.rst:163 -msgid "" -"Making a release may entail the publishing of multiple :term:`Distributions " -"`. For example, if version 1.0 of a project was " -"released, it could be available in both a source distribution format and a " -"Windows installer distribution format." -msgstr "" - -#: ../source/glossary.rst:168 -msgid "Requirement" -msgstr "" - -#: ../source/glossary.rst:171 -msgid "" -"A specification for a :term:`package ` to be " -"installed. :ref:`pip`, the :term:`PYPA ` " -"recommended installer, allows various forms of specification that can all be " -"considered a \"requirement\". For more information, see the :ref:`pip:pip " -"install` reference." -msgstr "" - -#: ../source/glossary.rst:177 -msgid "Requirement Specifier" -msgstr "" - -#: ../source/glossary.rst:180 -msgid "" -"A format used by :ref:`pip` to install packages from a :term:`Package " -"Index`. For an EBNF diagram of the format, see the `pkg_resources." -"Requirement `_ entry in the :ref:`setuptools` docs. For " -"example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the " -"project name, and the \">=1.3\" portion is the :term:`Version Specifier`" -msgstr "" - -#: ../source/glossary.rst:187 -msgid "Requirements File" -msgstr "" - -#: ../source/glossary.rst:190 -msgid "" -"A file containing a list of :term:`Requirements ` that can be " -"installed using :ref:`pip`. For more information, see the :ref:`pip` docs " -"on :ref:`pip:Requirements Files`." -msgstr "" - -#: ../source/glossary.rst:194 -#: ../source/guides/distributing-packages-using-setuptools.rst:56 -msgid "setup.py" -msgstr "setup.py" - -#: ../source/glossary.rst:195 -#: ../source/guides/distributing-packages-using-setuptools.rst:77 -msgid "setup.cfg" -msgstr "setup.cfg" - -#: ../source/glossary.rst:198 -msgid "" -"The project specification files for :ref:`distutils` and :ref:`setuptools`. " -"See also :term:`pyproject.toml`." -msgstr "" - -#: ../source/glossary.rst:201 -msgid "Source Archive" -msgstr "" - -#: ../source/glossary.rst:204 -msgid "" -"An archive containing the raw source code for a :term:`Release`, prior to " -"creation of a :term:`Source Distribution ` or :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:208 -msgid "Source Distribution (or \"sdist\")" -msgstr "" - -#: ../source/glossary.rst:211 -msgid "" -"A :term:`distribution ` format (usually generated " -"using ``python setup.py sdist``) that provides metadata and the essential " -"source files needed for installing by a tool like :ref:`pip`, or for " -"generating a :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:216 -msgid "System Package" -msgstr "" - -#: ../source/glossary.rst:219 -msgid "" -"A package provided in a format native to the operating system, e.g. an rpm " -"or dpkg file." -msgstr "" - -#: ../source/glossary.rst:222 -msgid "Version Specifier" -msgstr "Versio-Specifilo" - -#: ../source/glossary.rst:225 -msgid "" -"The version component of a :term:`Requirement Specifier`. For example, the " -"\">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full " -"specification <440#version-specifiers>` of the specifiers that Python " -"packaging currently supports. Support for PEP440 was implemented in :ref:" -"`setuptools` v8.0 and :ref:`pip` v6.0." -msgstr "" - -#: ../source/glossary.rst:231 -msgid "Virtual Environment" -msgstr "" - -#: ../source/glossary.rst:234 -msgid "" -"An isolated Python environment that allows packages to be installed for use " -"by a particular application, rather than being installed system wide. For " -"more information, see the section on :ref:`Creating and using Virtual " -"Environments`." -msgstr "" - -#: ../source/glossary.rst:238 -msgid "Wheel" -msgstr "Wheel" - -#: ../source/glossary.rst:241 -msgid "" -"A :term:`Built Distribution` format introduced by :pep:`427`, which is " -"intended to replace the :term:`Egg` format. Wheel is currently supported " -"by :ref:`pip`." -msgstr "" - -#: ../source/glossary.rst:244 -msgid "Working Set" -msgstr "" - -#: ../source/glossary.rst:247 -msgid "" -"A collection of :term:`distributions ` available for " -"importing. These are the distributions that are on the `sys.path` variable. " -"At most, one :term:`Distribution ` for a project is " -"possible in a working set." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:3 -msgid "Analyzing PyPI package downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:5 -msgid "" -"This section covers how to use the public PyPI download statistics dataset " -"to learn more about downloads of a package (or packages) hosted on PyPI. For " -"example, you can use it to discover the distribution of Python versions used " -"to download a package." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:15 -#: ../source/guides/supporting-windows-using-appveyor.rst:18 -msgid "Background" -msgstr "Fonaj informoj" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:17 -msgid "PyPI does not display download statistics for a number of reasons: [#]_" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:19 -msgid "" -"**Inefficient to make work with a Content Distribution Network (CDN):** " -"Download statistics change constantly. Including them in project pages, " -"which are heavily cached, would require invalidating the cache more often, " -"and reduce the overall effectiveness of the cache." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:24 -msgid "" -"**Highly inaccurate:** A number of things prevent the download counts from " -"being accurate, some of which include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:27 -msgid "``pip``'s download cache (lowers download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:28 -msgid "" -"Internal or unofficial mirrors (can both raise or lower download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:29 -msgid "Packages not hosted on PyPI (for comparisons sake)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:30 -msgid "" -"Unofficial scripts or attempts at download count inflation (raises download " -"counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:32 -msgid "Known historical data quality issues (lowers download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:34 -msgid "" -"**Not particularly useful:** Just because a project has been downloaded a " -"lot doesn't mean it's good; Similarly just because a project hasn't been " -"downloaded a lot doesn't mean it's bad!" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:38 -msgid "" -"In short, because it's value is low for various reasons, and the tradeoffs " -"required to make it work are high, it has been not an effective use of " -"limited resources." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:43 -msgid "Public dataset" -msgstr "Publika datenaro" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:45 -msgid "" -"As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, " -"where they are stored as a public dataset." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:50 -msgid "Getting set up" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:52 -msgid "" -"In order to use `Google BigQuery`_ to query the `public PyPI download " -"statistics dataset`_, you'll need a Google account and to enable the " -"BigQuery API on a Google Cloud Platform project. You can run the up to 1TB " -"of queries per month `using the BigQuery free tier without a credit card " -"`__" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:58 -msgid "Navigate to the `BigQuery web UI`_." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:59 -msgid "Create a new project." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:60 -msgid "" -"Enable the `BigQuery API `__." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:63 -msgid "" -"For more detailed instructions on how to get started with BigQuery, check " -"out the `BigQuery quickstart guide `__." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:69 -msgid "Data schema" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:71 -msgid "" -"Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` " -"table for each download. The table contains information about what file was " -"downloaded and how it was downloaded. Some useful columns from the `table " -"schema `__ include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -msgid "Column" -msgstr "Kolumno" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/guides/using-manifest-in.rst:67 -#: ../source/specifications/core-metadata.rst:185 -msgid "Description" -msgstr "Priskribo" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/specifications/direct-url.rst:226 -msgid "Examples" -msgstr "Ekzemploj" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "timestamp" -msgstr "timestamp" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "Date and time" -msgstr "Dato kaj tempo" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "``2020-03-09 00:33:03 UTC``" -msgstr "``2020-03-09 00:33:03 UTC``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "file.project" -msgstr "file.project" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "Project name" -msgstr "Nomo de projekto" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "``pipenv``, ``nose``" -msgstr "``pipenv``, ``nose``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "file.version" -msgstr "file.version" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "Package version" -msgstr "Versio de pako" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "``0.1.6``, ``1.4.2``" -msgstr "``0.1.6``, ``1.4.2``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "details.installer.name" -msgstr "details.installer.name" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "Installer" -msgstr "Instalilo" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "pip, `bandersnatch`_" -msgstr "pip, `bandersnatch`_" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "details.python" -msgstr "details.python" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "Python version" -msgstr "Versio de Python" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "``2.7.12``, ``3.6.4``" -msgstr "``2.7.12``, ``3.6.4``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:93 -msgid "Useful queries" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:95 -msgid "" -"Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" " -"button." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:97 -msgid "" -"Note that the rows are stored in a partitioned, which helps limit the cost " -"of queries. These example queries analyze downloads from recent history by " -"filtering on the ``timestamp`` column." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:102 -msgid "Counting package downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:104 -msgid "" -"The following query counts the total number of downloads for the project " -"\"pytest\"." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:119 -#: ../source/guides/analyzing-pypi-package-downloads.rst:140 -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "num_downloads" -msgstr "num_downloads" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:121 -msgid "26190085" -msgstr "26190085" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:124 -msgid "" -"To only count downloads from pip, filter on the ``details.installer.name`` " -"column." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:142 -msgid "24334215" -msgstr "24334215" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:146 -msgid "Package downloads over time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:148 -msgid "" -"To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also " -"filtering by this column reduces corresponding costs." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -msgid "month" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "1956741" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "2018-01-01" -msgstr "2018-01-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2344692" -msgstr "2344692" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2017-12-01" -msgstr "2017-12-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "1730398" -msgstr "1730398" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "2017-11-01" -msgstr "2017-11-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2047310" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2017-10-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "1744443" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "2017-09-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "1916952" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "2017-08-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:184 -msgid "Python versions over time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:186 -msgid "" -"Extract the Python version from the ``details.python`` column. Warning: This " -"query processes over 500 GB of data." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "python" -msgstr "python" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "3.7" -msgstr "3.7" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "18051328726" -msgstr "18051328726" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "3.6" -msgstr "3.6" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "9635067203" -msgstr "9635067203" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "3.8" -msgstr "3.8" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "7781904681" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "2.7" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "6381252241" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "null" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "2026630299" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "3.5" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "1894153540" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:221 -msgid "Caveats" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:223 -msgid "" -"In addition to the caveats listed in the background above, Linehaul suffered " -"from a bug which caused it to significantly under-report download statistics " -"prior to July 26, 2018. Downloads before this date are proportionally " -"accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total " -"numbers are lower than actual by an order of magnitude." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:231 -msgid "Additional tools" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:233 -msgid "" -"Besides using the BigQuery console, there are some additional tools which " -"may be useful when analyzing download statistics." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:237 -msgid "``google-cloud-bigquery``" -msgstr "``google-cloud-bigquery``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:239 -msgid "" -"You can also access the public PyPI download statistics dataset " -"programmatically via the BigQuery API and the `google-cloud-bigquery`_ " -"project, the official Python client library for BigQuery." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:267 -msgid "``pypinfo``" -msgstr "``pypinfo``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:269 -msgid "" -"`pypinfo`_ is a command-line tool which provides access to the dataset and " -"can generate several useful queries. For example, you can query the total " -"number of download for a package with the command ``pypinfo package_name``." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:273 -msgid "Install `pypinfo`_ using pip." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:279 -msgid "Usage:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:295 -msgid "``pandas-gbq``" -msgstr "``pandas-gbq``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:297 -msgid "" -"The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:301 -#: ../source/specifications/binary-distribution-format.rst:459 -msgid "References" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:303 -msgid "" -"`PyPI Download Counts deprecation email `__" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:304 -msgid "" -"`PyPI BigQuery dataset announcement email `__" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:3 -msgid "Creating and discovering plugins" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:5 -msgid "" -"Often when creating a Python application or library you'll want the ability " -"to provide customizations or extra features via **plugins**. Because Python " -"packages can be separately distributed, your application or library may want " -"to automatically **discover** all of the plugins available." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:10 -msgid "There are three major approaches to doing automatic plugin discovery:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:12 -msgid "`Using naming convention`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:13 -msgid "`Using namespace packages`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:14 -msgid "`Using package metadata`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:18 -msgid "Using naming convention" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:20 -msgid "" -"If all of the plugins for your application follow the same naming " -"convention, you can use :func:`pkgutil.iter_modules` to discover all of the " -"top-level modules that match the naming convention. For example, `Flask`_ " -"uses the naming convention ``flask_{plugin_name}``. If you wanted to " -"automatically discover all of the Flask plugins installed:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:38 -msgid "" -"If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins " -"installed then ``discovered_plugins`` would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:48 -msgid "" -"Using naming convention for plugins also allows you to query the Python " -"Package Index's `simple API`_ for all packages that conform to your naming " -"convention." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:59 -msgid "Using namespace packages" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:61 -msgid "" -":doc:`Namespace packages ` can be used to " -"provide a convention for where to place plugins and also provides a way to " -"perform discovery. For example, if you make the sub-package ``myapp." -"plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once " -"installed, you can use :func:`pkgutil.iter_modules` to discover all modules " -"and packages installed under that namespace:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:89 -msgid "" -"Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` " -"causes it to only look for the modules directly under that namespace. For " -"example, if you have installed distributions that provide the modules " -"``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in " -"this case would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:101 -msgid "" -"This sample uses a sub-package as the namespace package (``myapp.plugins``), " -"but it's also possible to use a top-level package for this purpose (such as " -"``myapp_plugins``). How to pick the namespace to use is a matter of " -"preference, but it's not recommended to make your project's main top-level " -"package (``myapp`` in this case) a namespace package for the purpose of " -"plugins, as one bad plugin could cause the entire namespace to break which " -"would in turn make your project unimportable. For the \"namespace sub-package" -"\" approach to work, the plugin packages must omit the :file:`__init__.py` " -"for your top-level package directory (``myapp`` in this case) and include " -"the namespace-package style :file:`__init__.py` in the namespace sub-package " -"directory (``myapp/plugins``). This also means that plugins will need to " -"explicitly pass a list of packages to :func:`setup`'s ``packages`` argument " -"instead of using :func:`setuptools.find_packages`." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:115 -msgid "" -"Namespace packages are a complex feature and there are several different " -"ways to create them. It's highly recommended to read the :doc:`packaging-" -"namespace-packages` documentation and clearly document which approach is " -"preferred for plugins to your project." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:121 -msgid "Using package metadata" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:123 -msgid "" -"`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :" -"func:`setup` in :file:`setup.py` plugins can register themselves for " -"discovery." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:128 -msgid "" -"For example if you have a package named ``myapp-plugin-a`` and it includes " -"in its :file:`setup.py`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:139 -msgid "" -"Then you can discover and load all of the registered entry points by using :" -"func:`importlib.metadata.entry_points` (or the `backport`_ " -"``importlib_metadata >= 3.6`` for Python 3.6-3.9):" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:154 -msgid "" -"In this example, ``discovered_plugins`` would be a collection of type :class:" -"`importlib.metadata.EntryPoint`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:163 -msgid "" -"Now the module of your choice can be imported by executing " -"``discovered_plugins['a'].load()``." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:166 -msgid "" -"The ``entry_point`` specification in :file:`setup.py` is fairly flexible and " -"has a lot of options. It's recommended to read over the entire section on :" -"doc:`entry points ` ." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:170 -msgid "" -"Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools " -"provide support for defining entry points." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:5 -msgid "Packaging and distributing projects" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:7 -msgid "" -"This section covers the basics of how to configure, package and distribute " -"your own Python projects. It assumes that you are already familiar with the " -"contents of the :doc:`/tutorials/installing-packages` page." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:11 -msgid "" -"The section does *not* aim to cover best practices for Python project " -"development as a whole. For example, it does not provide guidance or tool " -"recommendations for version control, documentation, or testing." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:15 -msgid "" -"For more reference material, see :std:doc:`Building and Distributing " -"Packages ` in the :ref:`setuptools` docs, but note that " -"some advisory content there may be outdated. In the event of conflicts, " -"prefer the advice in the Python Packaging User Guide." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:25 -msgid "Requirements for packaging and distributing" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:26 -msgid "" -"First, make sure you have already fulfilled the :ref:`requirements for " -"installing packages `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:29 -msgid "Install \"twine\" [1]_:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:43 -msgid "" -"You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below " -"`)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:49 -msgid "Configuring your project" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:53 -msgid "Initial files" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:58 -msgid "" -"The most important file is :file:`setup.py` which exists at the root of your " -"project directory. For an example, see the `setup.py `_ in the `PyPA sample project " -"`_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:63 -msgid ":file:`setup.py` serves two primary functions:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:65 -msgid "" -"It's the file where various aspects of your project are configured. The " -"primary feature of :file:`setup.py` is that it contains a global ``setup()`` " -"function. The keyword arguments to this function are how specific details " -"of your project are defined. The most relevant arguments are explained in :" -"ref:`the section below `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:71 -msgid "" -"It's the command line interface for running various commands that relate to " -"packaging tasks. To get a listing of available commands, run ``python setup." -"py --help-commands``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:79 -msgid "" -":file:`setup.cfg` is an ini file that contains option defaults for :file:" -"`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project " -"`_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:86 -msgid "README.rst / README.md" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:88 -msgid "" -"All projects should contain a readme file that covers the goal of the " -"project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not " -"a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:" -"`long_description_content_type ` argument)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:95 -msgid "" -"For an example, see `README.md `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:99 -msgid "" -"Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:" -"`README.rst`, :file:`README.txt`, or :file:`README`) included in source " -"distributions by default. The built-in :ref:`distutils` library adopts this " -"behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ " -"will include a :file:`README.md` if found. If you are using setuptools, you " -"don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, " -"include it to be explicit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:108 -msgid "MANIFEST.in" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:110 -msgid "" -"A :file:`MANIFEST.in` is needed when you need to package additional files " -"that are not automatically included in a source distribution. For details " -"on writing a :file:`MANIFEST.in` file, including a list of what's included " -"by default, see \":ref:`Using MANIFEST.in`\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:115 -msgid "" -"For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:119 -msgid "" -":file:`MANIFEST.in` does not affect binary distributions such as wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:122 -msgid "LICENSE.txt" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:124 -msgid "" -"Every package should include a license file detailing the terms of " -"distribution. In many jurisdictions, packages without an explicit license " -"can not be legally used or distributed by anyone other than the copyright " -"holder. If you're unsure which license to choose, you can use resources such " -"as `GitHub's Choose a License `_ or consult a " -"lawyer." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:130 -msgid "" -"For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:135 -msgid "" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:137 -msgid "" -"Although it's not required, the most common practice is to include your " -"Python modules and packages under a single top-level package that has the " -"same :ref:`name ` as your project, or something very close." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:141 -msgid "" -"For an example, see the `sample `_ package that's included in the `PyPA sample project " -"`_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:149 -msgid "setup() args" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:151 -msgid "" -"As mentioned above, the primary feature of :file:`setup.py` is that it " -"contains a global ``setup()`` function. The keyword arguments to this " -"function are how specific details of your project are defined." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:155 -msgid "" -"The most relevant arguments are explained below. Most of the snippets given " -"are taken from the `setup.py `_ contained in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:164 -msgid "name" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:170 -msgid "" -"This is the name of your project, determining how your project is listed on :" -"term:`PyPI `. Per :pep:`508`, valid project " -"names must:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:174 -msgid "" -"Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), " -"and/or periods (``.``), and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:176 -msgid "Start & end with an ASCII letter or digit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:178 -msgid "" -"Comparison of project names is case insensitive and treats arbitrarily-long " -"runs of underscores, hyphens, and/or periods as equal. For example, if you " -"register a project named ``cool-stuff``, users will be able to download it " -"or declare a dependency on it using any of the following spellings::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:190 -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "version" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:196 -msgid "" -"This is the current version of your project, allowing your users to " -"determine whether or not they have the latest version, and to indicate which " -"specific versions they've tested their own software against." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:200 -msgid "" -"Versions are displayed on :term:`PyPI ` for " -"each release if you publish your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:203 -msgid "" -"See :ref:`Choosing a versioning scheme` for more information on ways to use " -"versions to convey compatibility information to your users." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:206 -msgid "" -"If the project code itself needs run-time access to the version, the " -"simplest way is to keep the version in both :file:`setup.py` and your code. " -"If you'd rather not duplicate the value, there are a few ways to manage " -"this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:214 -msgid "description" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:222 -msgid "Give a short and long description for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:224 -msgid "" -"These values will be displayed on :term:`PyPI ` " -"if you publish your project. On ``pypi.org``, the user interface displays " -"``description`` in the grey banner and ``long_description`` in the section " -"named \"Project Description\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:229 -msgid "" -"``description`` is also displayed in lists of projects. For example, it's " -"visible in the search results pages such as https://pypi.org/search/?" -"q=jupyter, the front-page lists of trending projects and new releases, and " -"the list of projects you maintain within your account profile (such as " -"https://pypi.org/user/jaraco/)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:235 -msgid "" -"A `content type `_ can be specified with the " -"``long_description_content_type`` argument, which can be one of ``text/" -"plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no " -"formatting, `reStructuredText (reST) `_, and the Github-flavored " -"Markdown dialect of `Markdown `_ respectively." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:245 -msgid "url" -msgstr "url" - -#: ../source/guides/distributing-packages-using-setuptools.rst:252 -msgid "Give a homepage URL for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:256 -msgid "author" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:263 -msgid "Provide details about the author." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:267 -msgid "license" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:273 -msgid "" -"The ``license`` argument doesn't have to indicate the license under which " -"your package is being released, although you may optionally do so if you " -"want. If you're using a standard, well-known license, then your main " -"indication can and should be via the ``classifiers`` argument. Classifiers " -"exist for all major open-source licenses." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:279 -msgid "" -"The \"license\" argument is more typically used to indicate differences from " -"well-known licenses, or to include your own, unique license. As a general " -"rule, it's a good idea to use a standard, well-known license, both to avoid " -"confusion and because some organizations avoid software whose license is " -"unapproved." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:287 -msgid "classifiers" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:316 -msgid "" -"Provide a list of classifiers that categorize your project. For a full " -"listing, see https://pypi.org/classifiers/." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:319 -msgid "" -"Although the list of classifiers is often used to declare what Python " -"versions a project supports, this information is only used for searching & " -"browsing projects on PyPI, not for installing projects. To actually " -"restrict what Python versions a project can be installed on, use the :ref:" -"`python_requires` argument." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:327 -msgid "keywords" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:333 -msgid "List keywords that describe your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:337 -msgid "project_urls" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:349 -msgid "" -"List additional relevant URLs about your project. This is the place to link " -"to bug trackers, source repositories, or where to support package " -"development. The string of the key is the exact text that will be displayed " -"on PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:355 -msgid "packages" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:361 -msgid "" -"Set ``packages`` to a list of all :term:`packages ` in your " -"project, including their subpackages, sub-subpackages, etc. Although the " -"packages can be listed manually, ``setuptools.find_packages()`` finds them " -"automatically. Use the ``include`` keyword argument to find only the given " -"packages. Use the ``exclude`` keyword argument to omit packages that are " -"not intended to be released and installed." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:370 -msgid "py_modules" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:376 -msgid "" -"If your project contains any single-file Python modules that aren't part of " -"a package, set ``py_modules`` to a list of the names of the modules (minus " -"the ``.py`` extension) in order to make :ref:`setuptools` aware of them." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:388 -msgid "" -"\"install_requires\" should be used to specify what dependencies a project " -"minimally needs to run. When the project is installed by :ref:`pip`, this is " -"the specification that is used to install its dependencies." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:392 -msgid "" -"For more on using \"install_requires\" see :ref:`install_requires vs " -"Requirements files`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:398 -msgid "python_requires" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:400 -msgid "" -"If your project only runs on certain Python versions, setting the " -"``python_requires`` argument to the appropriate :pep:`440` version specifier " -"string will prevent :ref:`pip` from installing the project on other Python " -"versions. For example, if your package is for Python 3+ only, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:407 -msgid "" -"If your package is for Python 2.6, 2.7, and all versions of Python 3 " -"starting with 3.3, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:412 -msgid "And so on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:416 -msgid "" -"Support for this feature is relatively recent. Your project's source " -"distributions and wheels (see :ref:`Packaging Your Project`) must be built " -"using at least version 24.2.0 of :ref:`setuptools` in order for the " -"``python_requires`` argument to be recognized and the appropriate metadata " -"generated." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:422 -msgid "" -"In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the " -"``python_requires`` metadata. Users with earlier versions of pip will be " -"able to download & install projects on any Python version regardless of the " -"projects' ``python_requires`` values." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:431 -msgid "package_data" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:440 -msgid "" -"Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the " -"package’s implementation, or text files containing documentation that might " -"be of interest to programmers using the package. These files are called " -"\"package data\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:445 -msgid "" -"The value must be a mapping from package name to a list of relative path " -"names that should be copied into the package. The paths are interpreted as " -"relative to the directory containing the package." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:449 -msgid "" -"For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:457 -msgid "data_files" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:463 -msgid "" -"Although configuring :ref:`Package Data` is sufficient for most needs, in " -"some cases you may need to place data files *outside* of your :term:" -"`packages `. The ``data_files`` directive allows you to do " -"that. It is mostly useful if you need to install files which are used by " -"other programs, which may be unaware of Python packages." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:469 -msgid "" -"Each ``(directory, files)`` pair in the sequence specifies the installation " -"directory and the files to install there. The ``directory`` must be a " -"relative path (although this may change in the future, see `wheel Issue #92 " -"`_). and it is interpreted relative " -"to the installation prefix (Python’s ``sys.prefix`` for a default " -"installation; ``site.USER_BASE`` for a user installation). Each file name in " -"``files`` is interpreted relative to the :file:`setup.py` script at the top " -"of the project source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:479 -msgid "" -"For more information see the distutils section on `Installing Additional " -"Files `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:484 -msgid "" -"When installing packages as egg, ``data_files`` is not supported. So, if " -"your project uses :ref:`setuptools`, you must use ``pip`` to install it. " -"Alternatively, if you must use ``python setup.py``, then you need to pass " -"the ``--old-and-unmanageable`` option." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:491 -msgid "scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:493 -msgid "" -"Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made " -"scripts to install, the recommended approach to achieve cross-platform " -"compatibility is to use :ref:`console_scripts` entry points (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:500 -msgid "entry_points" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:509 -msgid "" -"Use this keyword to specify any plugins that your project provides for any " -"named entry points that may be defined by your project or others that you " -"depend on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:512 -msgid "" -"For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:516 -msgid "The most commonly used entry point is \"console_scripts\" (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:521 -msgid "console_scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:531 -msgid "" -"Use \"console_script\" `entry points `_ to " -"register your script interfaces. You can then let the toolchain handle the " -"work of turning these interfaces into actual scripts [2]_. The scripts will " -"be generated during the install of your :term:`distribution `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:538 -msgid "" -"For more information, see `Automatic Script Creation `_ from " -"the `setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:545 -msgid "Choosing a versioning scheme" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:548 -msgid "Standards compliance for interoperability" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:550 -msgid "" -"Different Python projects may use different versioning schemes based on the " -"needs of that particular project, but all of them are required to comply " -"with the flexible :pep:`public version scheme <440#public-version-" -"identifiers>` specified in :pep:`440` in order to be supported in tools and " -"libraries like ``pip`` and ``setuptools``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:556 -msgid "Here are some examples of compliant version numbers::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:567 -msgid "" -"To further accommodate historical variations in approaches to version " -"numbering, :pep:`440` also defines a comprehensive technique for :pep:" -"`version normalisation <440#normalization>` that maps variant spellings of " -"different version numbers to a standardised canonical form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:573 -msgid "Scheme choices" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:576 -msgid "Semantic versioning (preferred)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:578 -msgid "" -"For new projects, the recommended versioning scheme is based on `Semantic " -"Versioning `_, but adopts a different approach to " -"handling pre-releases and build metadata." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:582 -msgid "" -"The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE " -"numbering scheme, where the project author increments:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:585 -msgid "MAJOR version when they make incompatible API changes," -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:586 -msgid "" -"MINOR version when they add functionality in a backwards-compatible manner, " -"and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:587 -msgid "MAINTENANCE version when they make backwards-compatible bug fixes." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:589 -msgid "" -"Adopting this approach as a project author allows users to make use of :pep:`" -"\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= " -"X.Y`` requires at least release X.Y, but also allows any later release with " -"a matching MAJOR version." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:594 -msgid "" -"Python projects adopting semantic versioning should abide by clauses 1-8 of " -"the `Semantic Versioning 2.0.0 specification `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:598 -msgid "Date based versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:600 -msgid "" -"Semantic versioning is not a suitable choice for all projects, such as those " -"with a regular time based release cadence and a deprecation process that " -"provides warnings for a number of releases prior to removal of a feature." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:604 -msgid "" -"A key advantage of date based versioning is that it is straightforward to " -"tell how old the base feature set of a particular release is given just the " -"version number." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:607 -msgid "" -"Version numbers for date based projects typically take the form of YEAR." -"MONTH (for example, ``12.04``, ``15.10``)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:611 -msgid "Serial versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:613 -msgid "" -"This is the simplest possible versioning scheme, and consists of a single " -"number which is incremented every release." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:616 -msgid "" -"While serial versioning is very easy to manage as a developer, it is the " -"hardest to track as an end user, as serial version numbers convey little or " -"no information regarding API backwards compatibility." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:621 -msgid "Hybrid schemes" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:623 -msgid "" -"Combinations of the above schemes are possible. For example, a project may " -"combine date based versioning with serial versioning to create a YEAR.SERIAL " -"numbering scheme that readily conveys the approximate age of a release, but " -"doesn't otherwise commit to a particular release cadence within the year." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:629 -msgid "Pre-release versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:631 -msgid "" -"Regardless of the base versioning scheme, pre-releases for a given final " -"release may be published as:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:634 -msgid "zero or more dev releases (denoted with a \".devN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:635 -msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:636 -msgid "zero or more beta releases (denoted with a \".bN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:637 -msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:639 -msgid "" -"``pip`` and other modern Python package installers ignore pre-releases by " -"default when deciding which versions of dependencies to install." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:644 -msgid "Local version identifiers" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:646 -msgid "" -"Public version identifiers are designed to support distribution via :term:" -"`PyPI `. Python's software distribution tools " -"also support the notion of a :pep:`local version identifier <440#local-" -"version-identifiers>`, which can be used to identify local development " -"builds not intended for publication, or modified variants of a release " -"maintained by a redistributor." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:653 -msgid "" -"A local version identifier takes the form ``" -"+``. For example::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:661 -msgid "Working in \"development mode\"" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:663 -msgid "" -"Although not required, it's common to locally install your project in " -"\"editable\" or \"develop\" mode while you're working on it. This allows " -"your project to be both installed and editable in project form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:667 -msgid "Assuming you're in the root of your project directory, then run:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:674 -msgid "" -"Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` " -"refers to the current working directory, so together, it means to install " -"the current directory (i.e. your project) in editable mode. This will also " -"install any dependencies declared with \"install_requires\" and any scripts " -"declared with \"console_scripts\". Dependencies will be installed in the " -"usual, non-editable mode." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:680 -msgid "" -"It's fairly common to also want to install some of your dependencies in " -"editable mode as well. For example, supposing your project requires \"foo\" " -"and \"bar\", but you want \"bar\" installed from VCS in editable mode, then " -"you could construct a requirements file like so::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:688 -msgid "" -"The first line says to install your project and any dependencies. The second " -"line overrides the \"bar\" dependency, such that it's fulfilled from VCS, " -"not PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:692 -msgid "" -"If, however, you want \"bar\" installed from a local directory in editable " -"mode, the requirements file should look like this, with the local paths at " -"the top of the file::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:697 -msgid "" -"Otherwise, the dependency will be fulfilled from PyPI, due to the " -"installation order of the requirements file. For more on requirements " -"files, see the :ref:`Requirements File ` section in " -"the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:701 -msgid "" -"Lastly, if you don't want to install any dependencies at all, you can run::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:706 -msgid "" -"For more information, see the `Development Mode `_ section of the " -"`setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:713 -msgid "Packaging your project" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:715 -msgid "" -"To have your project installable from a :term:`Package Index` like :term:" -"`PyPI `, you'll need to create a :term:" -"`Distribution ` (aka \":term:`Package `\") for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:720 -msgid "" -"Before you can build wheels and sdists for your project, you'll need to " -"install the ``build`` package:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:737 -msgid "Source distributions" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:739 -msgid "" -"Minimally, you should create a :term:`Source Distribution `:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:755 -msgid "" -"A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built " -"Distribution`), and requires a build step when installed by pip. Even if " -"the distribution is pure Python (i.e. contains no extensions), it still " -"involves a build step to build out the installation metadata from :file:" -"`setup.py` and/or :file:`setup.cfg`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:763 -msgid "Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:765 -msgid "" -"You should also create a wheel for your project. A wheel is a :term:`built " -"package ` that can be installed without needing to go " -"through the \"build\" process. Installing wheels is substantially faster for " -"the end user than installing from a source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:770 -msgid "" -"If your project is pure Python then you'll be creating a :ref:`\"Pure Python " -"Wheel\" (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:773 -msgid "" -"If your project contains compiled extensions, then you'll be creating what's " -"called a :ref:`*Platform Wheel* (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:776 -msgid "" -"If your project also supports Python 2 *and* contains no C extensions, then " -"you should create what's called a *Universal Wheel* by adding the following " -"to your :file:`setup.cfg` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:785 -msgid "" -"Only use this setting if your project does not have any C extensions *and* " -"supports Python 2 and 3." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:792 -msgid "Pure Python Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:794 -msgid "" -"*Pure Python Wheels* contain no compiled extensions, and therefore only " -"require a single Python wheel." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:797 -#: ../source/guides/distributing-packages-using-setuptools.rst:826 -msgid "To build the wheel:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:811 -msgid "" -"The ``wheel`` package will detect that the code is pure Python, and build a " -"wheel that's named such that it's usable on any Python 3 installation. For " -"details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:815 -msgid "" -"If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both " -"files for you; this is useful when you don't need multiple wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:821 -msgid "Platform Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:823 -msgid "" -"*Platform Wheels* are wheels that are specific to a certain platform like " -"Linux, macOS, or Windows, usually due to containing compiled extensions." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:841 -msgid "" -"The ``wheel`` package will detect that the code is not pure Python, and " -"build a wheel that's named such that it's only usable on the platform that " -"it was built on. For details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:847 -msgid "" -":term:`PyPI ` currently supports uploads of " -"platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. " -"Details of the latter are defined in :pep:`513`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:855 -msgid "Uploading your Project to PyPI" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:857 -msgid "" -"When you ran the command to create your distribution, a new directory ``dist/" -"`` was created under your project's root directory. That's where you'll find " -"your distribution file(s) to upload." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:861 -msgid "" -"These files are only created when you run the command to create your " -"distribution. This means that any time you change the source of your project " -"or the configuration in your :file:`setup.py` file, you will need to rebuild " -"these files again before you can distribute the changes to PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:866 -msgid "" -"Before releasing on main PyPI repo, you might prefer training with the `PyPI " -"test site `_ which is cleaned on a semi regular " -"basis. See :ref:`using-test-pypi` on how to setup your configuration in " -"order to use it." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:871 -msgid "" -"In other resources you may encounter references to using ``python setup.py " -"register`` and ``python setup.py upload``. These methods of registering and " -"uploading a package are **strongly discouraged** as it may use a plaintext " -"HTTP or unverified HTTPS connection on some Python versions, allowing your " -"username and password to be intercepted during transmission." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:877 -msgid "" -"The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to " -"ensure safety of all users, certain kinds of URLs and directives are " -"forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** " -"trying to upload your distribution, you should check to see if your brief / " -"long descriptions provided in :file:`setup.py` are valid. You can do this " -"by running :std:doc:`twine check ` on your package files::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:888 -msgid "Create an account" -msgstr "Krei konton" - -#: ../source/guides/distributing-packages-using-setuptools.rst:890 -msgid "" -"First, you need a :term:`PyPI ` user account. " -"You can create an account `using the form on the PyPI website `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:894 -msgid "" -"Now you'll create a PyPI `API token`_ so you will be able to securely upload " -"your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:897 -msgid "" -"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " -"token`_; don't limit its scope to a particular project, since you are " -"creating a new project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:901 -msgid "" -"**Don't close the page until you have copied and saved the token — you won't " -"see that token again.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:904 -msgid "" -"To avoid having to copy and paste the token every time you upload, you can " -"create a :file:`$HOME/.pypirc` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:913 -msgid "**Be aware that this stores your token in plaintext.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:915 -#: ../source/guides/migrating-to-pypi-org.rst:70 -#: ../source/guides/migrating-to-pypi-org.rst:109 -#: ../source/guides/using-testpypi.rst:83 -msgid "" -"For more details, see the :ref:`specification ` for :file:`.pypirc`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:921 -msgid "Upload your distributions" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:923 -msgid "" -"Once you have an account you can upload your distributions to :term:`PyPI " -"` using :ref:`twine`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:926 -msgid "" -"The process for uploading a release is the same regardless of whether or not " -"the project already exists on PyPI - if it doesn't exist yet, it will be " -"automatically created when the first release is uploaded." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:930 -msgid "" -"For the second and subsequent releases, PyPI only requires that the version " -"number of the new release differ from any previous releases." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:937 -msgid "" -"You can see if your package has successfully uploaded by navigating to the " -"URL ``https://pypi.org/project/`` where ``sampleproject`` is " -"the name of your project that you uploaded. It may take a minute or two for " -"your project to appear on the site." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:944 -#: ../source/tutorials/installing-packages.rst:663 -msgid "" -"Depending on your platform, this may require root or Administrator access. :" -"ref:`pip` is currently considering changing this by `making user installs " -"the default behavior `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:950 -msgid "" -"Specifically, the \"console_script\" approach generates ``.exe`` files on " -"Windows, which are necessary because the OS special-cases ``.exe`` files. " -"Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for " -"Windows <397>` allow scripts to be used in many cases, but not all." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:5 -msgid "Dropping support for older Python versions" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:7 -msgid "" -"Dropping support for older Python versions is supported by the standard :ref:" -"`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:9 -msgid "" -"Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification " -"by matching the current Python runtime and comparing it with the required " -"version in the package metadata. If they do not match, it will attempt to " -"install the last package distribution that supported that Python runtime." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:12 -msgid "" -"This mechanism can be used to drop support for older Python versions, by " -"amending the \"Requires-Python\" attribute in the package metadata." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:14 -msgid "" -"This guide is specifically for users of :ref:`setuptools`, other packaging " -"tools such as ``flit`` may offer similar functionality but users will need " -"to consult relevant documentation." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:17 -msgid "Requirements" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:19 -msgid "This workflow requires that:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:21 -msgid "The publisher is using the latest version of :ref:`setuptools`," -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:22 -msgid "The latest version of :ref:`twine` is used to upload the package," -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:23 -msgid "" -"The user installing the package has at least Pip 9.0, or a client that " -"supports the Metadata 1.2 specification." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:26 -msgid "Dealing with the universal wheels" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:28 -msgid "" -"Traditionally, projects providing Python code that is semantically " -"compatible with both Python 2 and Python 3, produce :term:`wheels ` " -"that have a ``py2.py3`` tag in their names. When dropping support for Python " -"2, it is important not to forget to change this tag to just ``py3``. It is " -"often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` " -"section by setting ``universal = 1`` if they use setuptools." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:36 -msgid "" -"If you use this method, either remove this option or section, or explicitly " -"set ``universal`` to ``0``:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:48 -msgid "" -"Since it is possible to override the :file:`setup.cfg` settings via CLI " -"flags, make sure that your scripts don't have ``--universal`` in your " -"package creation scripts." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:53 -msgid "Defining the Python version required" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:56 -msgid "1. Download the newest version of Setuptools" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:58 -msgid "" -"Ensure that before you generate source distributions or binary " -"distributions, you update Setuptools and install twine." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:60 -msgid "Steps:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:74 -msgid "`setuptools` version should be above 24.0.0." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:77 -msgid "2. Specify the version ranges for supported Python distributions" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:79 -msgid "" -"You can specify version ranges and exclusion rules, such as at least Python " -"3. Or, Python 2.7, 3.4 and beyond." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:81 -#: ../source/specifications/core-metadata.rst:139 -#: ../source/specifications/core-metadata.rst:463 -#: ../source/specifications/core-metadata.rst:487 -#: ../source/specifications/core-metadata.rst:527 -#: ../source/specifications/core-metadata.rst:550 -#: ../source/specifications/core-metadata.rst:583 -#: ../source/specifications/core-metadata.rst:693 -#: ../source/specifications/core-metadata.rst:722 -msgid "Examples::" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:86 -msgid "" -"The way to set those values is within the call to ``setup`` within your :" -"file:`setup.py` script. This will insert the ``Requires-Python`` metadata " -"values based on the argument you provide in ``python_requires``." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:101 -msgid "3. Validating the Metadata before publishing" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:103 -msgid "" -"Within a Python source package (the zip or the tar-gz file you download) is " -"a text file called PKG-INFO." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:105 -msgid "" -"This file is generated by Distutils or :ref:`setuptools` when it generates " -"the source package. The file contains a set of keys and values, the list of " -"keys is part of the PyPa standard metadata format." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:108 -msgid "You can see the contents of the generated file like this::" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:112 -msgid "Validate that the following is in place, before publishing the package:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:114 -msgid "" -"If you have upgraded correctly, the Metadata-Version value should be 1.2 or " -"higher." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:115 -msgid "" -"The Requires-Python field is set and matches your specification in setup.py." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:118 -msgid "4. Using Twine to publish" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:120 -msgid "" -"Twine has a number of advantages, apart from being faster it is now the " -"supported method for publishing packages." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:122 -msgid "Make sure you are using the newest version of Twine, at least 1.9." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:125 -msgid "Dropping a Python release" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:127 -msgid "" -"Once you have published a package with the Requires-Python metadata, you can " -"then make a further update removing that Python runtime from support." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:129 -msgid "It must be done in this order for the automated fallback to work." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:131 -msgid "" -"For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 " -"of your package." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:133 -msgid "" -"If you were then to update the version string to \">=3.5\", and publish a " -"new version 2.0.0 of your package, any users running Pip 9.0+ from version " -"2.7 will have version 1.0.0 of the package installed, and any >=3.5 users " -"will receive version 2.0.0." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:5 -msgid "Hosting your own simple repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:8 -msgid "" -"If you wish to host your own simple repository [1]_, you can either use a " -"software package like `devpi`_ or you can use simply create the proper " -"directory structure and use any web server that can serve static files and " -"generate an autoindex." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:13 -msgid "" -"In either case, since you'll be hosting a repository that is likely not in " -"your user's default repositories, you should instruct them in your project's " -"description to configure their installer appropriately. For example with pip:" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:29 -msgid "" -"In addition, it is **highly** recommended that you serve your repository " -"with valid HTTPS. At this time, the security of your user's installations " -"depends on all repositories using a valid HTTPS setup." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:35 -msgid "\"Manual\" repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:37 -msgid "" -"The directory layout is fairly simple, within a root directory you need to " -"create a directory for each project. This directory should be the normalized " -"name (as defined by :pep:`503`) of the project. Within each of these " -"directories simply place each of the downloadable files. If you have the " -"projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the " -"version 0.1) You should end up with a structure that looks like::" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:51 -msgid "" -"Once you have this layout, simply configure your webserver to serve the root " -"directory with autoindex enabled. For an example using the built in Web " -"server in `Twisted`_, you would simply run ``twistd -n web --path .`` and " -"then instruct users to add the URL to their installer's configuration." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:58 -msgid "" -"For complete documentation of the simple repository protocol, see :pep:`503`." -msgstr "" - -#: ../source/guides/index.rst:8 -msgid "Installing Packages:" -msgstr "" - -#: ../source/guides/index.rst:20 -msgid "Building and Publishing Projects:" -msgstr "" - -#: ../source/guides/index.rst:38 -msgid "Miscellaneous:" -msgstr "" - -#: ../source/guides/index.rst:4 -msgid "" -"**Guides** are focused on accomplishing a specific task and assume that you " -"are already familiar with the basics of Python packaging. If you're looking " -"for an introduction to packaging, see :doc:`/tutorials/index`." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:5 -msgid "Package index mirrors and caches" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:8 -#: ../source/guides/supporting-multiple-python-versions.rst:8 -msgid "2014-12-24" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:14 -msgid "" -"Mirroring or caching of PyPI can be used to speed up local package " -"installation, allow offline work, handle corporate firewalls or just plain " -"Internet flakiness." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:17 -msgid "Three options are available in this area:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:19 -msgid "pip provides local caching options," -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:20 -msgid "" -"devpi provides higher-level caching option, potentially shared amongst many " -"users or machines, and" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:22 -msgid "" -"bandersnatch provides a local complete mirror of all PyPI :term:`packages " -"`." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:27 -msgid "Caching with pip" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:29 -msgid "" -"pip provides a number of facilities for speeding up installation by using " -"local cached copies of :term:`packages `:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:32 -msgid "" -"`Fast & local installs `_ by downloading all the requirements for a project and " -"then pointing pip at those downloaded files instead of going to PyPI." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:36 -msgid "" -"A variation on the above which pre-builds the installation files for the " -"requirements using `python -m pip wheel `_::" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:45 -msgid "Caching with devpi" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:47 -msgid "" -"devpi is a caching proxy server which you run on your laptop, or some other " -"machine you know will always be available to you. See the `devpi " -"documentation for getting started`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:55 -msgid "Complete mirror with bandersnatch" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:57 -msgid "" -"bandersnatch will set up a complete local mirror of all PyPI :term:`packages " -"` (externally-hosted packages are not mirrored). See " -"the `bandersnatch documentation for getting that going`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:63 -msgid "" -"A benefit of devpi is that it will create a mirror which includes :term:" -"`packages ` that are external to PyPI, unlike " -"bandersnatch which will only cache :term:`packages ` " -"hosted on PyPI." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:5 -msgid "Installing scientific packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:11 -msgid "" -"Scientific software tends to have more complex dependencies than most, and " -"it will often have multiple build options to take advantage of different " -"kinds of hardware, or to interoperate with different pieces of external " -"software." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:16 -msgid "" -"In particular, `NumPy `__, which provides the basis " -"for most of the software in the `scientific Python stack `__ can be configured to interoperate with " -"different FORTRAN libraries, and can take advantage of different levels of " -"vectorised instructions available in modern CPUs." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:22 -msgid "" -"Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built " -"32-bit and 64-bit binaries in the ``wheel`` format are available for all " -"major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, " -"that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, " -"so they may not provide optimal linear algebra performance." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:29 -msgid "" -"There are a number of alternative options for obtaining scientific Python " -"libraries (or any other Python libraries that require a compilation " -"environment to install from source and don't provide pre-built wheel files " -"on PyPI)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:35 -msgid "Building from source" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:37 -msgid "" -"The same complexity which makes it difficult to distribute NumPy (and many " -"of the projects that depend on it) as wheel files also make them difficult " -"to build from source yourself. However, for intrepid folks that are willing " -"to spend the time wrangling compilers and linkers for both C and FORTRAN, " -"building from source is always an option." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:45 -msgid "Linux distribution packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:47 -msgid "" -"For Linux users, the system package manager will often have pre-compiled " -"versions of various pieces of scientific software, including NumPy and other " -"parts of the scientific Python stack." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:51 -msgid "" -"If using versions which may be several months old is acceptable, then this " -"is likely to be a good option (just make sure to allow access to " -"distributions installed into the system Python when using virtual " -"environments)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:57 -msgid "Windows installers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:59 -msgid "" -"Many Python projects that don't (or can't) currently publish wheel files at " -"least publish Windows installers, either on PyPI or on their project " -"download page. Using these installers allows users to avoid the need to set " -"up a suitable environment to build extensions locally." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:64 -msgid "" -"The extensions provided in these installers are typically compatible with " -"the CPython Windows installers published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:67 -msgid "" -"For projects which don't provide their own Windows installers (and even some " -"which do), Christoph Gohlke at the University of California provides a " -"`collection of Windows installers `__. Many Python users on Windows have reported a positive experience with " -"these prebuilt versions." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:73 -msgid "" -"As with Linux system packages, the Windows installers will only install into " -"a system Python installation - they do not support installation in virtual " -"environments. Allowing access to distributions installed into the system " -"Python when using virtual environments is a common approach to working " -"around this limitation." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:79 -msgid "" -"The :term:`Wheel` project also provides a :command:`wheel convert` " -"subcommand that can convert a Windows :command:`bdist_wininst` installer to " -"a wheel." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:86 -msgid "macOS installers and package managers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:88 -msgid "" -"Similar to the situation on Windows, many projects (including NumPy) publish " -"macOS installers that are compatible with the macOS CPython binaries " -"published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:92 -msgid "" -"macOS users also have access to Linux distribution style package managers " -"such as ``MacPorts``. The SciPy site has more details on using MacPorts to " -"install the `scientific Python stack `__" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:99 -msgid "SciPy distributions" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:101 -msgid "" -"The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use " -"and update format." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:105 -msgid "" -"Some of these distributions may not be compatible with the standard ``pip`` " -"and ``virtualenv`` based toolchain." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:109 -#: ../source/key_projects.rst:596 -msgid "Spack" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:110 -msgid "" -"`Spack `_ is a flexible package manager " -"designed to support multiple versions, configurations, platforms, and " -"compilers. It was built to support the needs of large supercomputing centers " -"and scientific application teams, who must often build software many " -"different ways. Spack is not limited to Python; it can install packages for " -"``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-" -"destructive; installing a new version of one package does not break existing " -"installations, so many configurations can coexist on the same system." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:119 -msgid "" -"Spack offers a simple but powerful syntax that allows users to specify " -"versions and configuration options concisely. Package files are written in " -"pure Python, and they are templated so that it is easy to swap compilers, " -"dependency implementations (like MPI), versions, and build options with a " -"single package file. Spack also generates *module* files so that packages " -"can be loaded and unloaded from the user's environment." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:128 -msgid "The conda cross-platform package manager" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:130 -msgid "" -"`Anaconda `_ is a Python distribution " -"published by Anaconda, Inc. It is a stable collection of Open Source " -"packages for big data and scientific use. As of the 5.0 release of " -"Anaconda, about 200 packages are installed by default, and a total of " -"400-500 can be installed and updated from the Anaconda repository." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:136 -msgid "" -"``conda`` is an open source (BSD licensed) package management system and " -"environment management system included in Anaconda that allows users to " -"install multiple versions of binary software packages and their " -"dependencies, and easily switch between them. It is a cross-platform tool " -"working on Windows, macOS, and Linux. Conda can be used to package up and " -"distribute all kinds of packages, it is not limited to just Python packages. " -"It has full support for native virtual environments. Conda makes " -"environments first-class citizens, making it easy to create independent " -"environments even for C libraries. It is written in Python, but is Python-" -"agnostic. Conda manages Python itself as a package, so that :command:`conda " -"update python` is possible, in contrast to pip, which only manages Python " -"packages. Conda is available in Anaconda and Miniconda (an easy-to-install " -"download with just Python and conda)." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 -msgid "Installing stand alone command line tools" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 -msgid "" -"Many packages have command line entry points. Examples of this type of " -"application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 -msgid "" -"Usually you want to be able to access these from anywhere, but installing " -"packages and their dependencies to the same global environment can cause " -"version conflicts and break dependencies the operating system has on Python " -"packages." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 -msgid "" -":ref:`pipx` solves this by creating a virtual environment for each package, " -"while also ensuring that package's applications are accessible through a " -"directory that is on your ``$PATH``. This allows each package to be upgraded " -"or uninstalled without causing conflicts with other packages, and allows you " -"to safely run the program from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 -msgid "pipx only works with Python 3.6+." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 -msgid "``pipx`` is installed with ``pip``:" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 -msgid "" -"You may need to restart your terminal for the path updates to take effect." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 -msgid "" -"Now you can install packages with ``pipx install`` and access the package's " -"entry point(s) from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 -#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 -msgid "For example" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 -msgid "" -"To see a list of packages installed with pipx and which CLI applications are " -"available, use ``pipx list``." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 -msgid "To upgrade or uninstall the package" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 -msgid "``pipx`` can be upgraded or uninstalled with pip" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 -msgid "" -"``pipx`` also allows you to install and run the latest version of a cli tool " -"in a temporary, ephemeral environment." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 -msgid "To see the full list of commands ``pipx`` offers, run" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 -msgid "" -"You can learn more about ``pipx`` at its homepage, https://github.com/pypa/" -"pipx." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:5 -msgid "Installing pip/setuptools/wheel with Linux Package Managers" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:8 -msgid "2015-09-17" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:11 -msgid "" -"This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:" -"`wheel` using Linux package managers." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:14 -msgid "" -"If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:" -"`installing_requirements` section instead." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:18 -msgid "" -"Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, " -"and :ref:`wheel` supported by a specific Linux Distribution to be outdated " -"by the time it's released to the public, and updates generally only occur " -"for security reasons, not for feature updates. For certain Distributions, " -"there are additional repositories that can be enabled to provide newer " -"versions. The repositories we know about are explained below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:25 -msgid "" -"Also note that it's somewhat common for Distributions to apply patches for " -"the sake of security and normalization to their own standards. In some " -"cases, this can lead to bugs or unexpected behaviors that vary from the " -"original unpatched versions. When this is known, we will make note of it " -"below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:32 -msgid "Fedora" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:34 -msgid "Fedora 21:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:36 -#: ../source/guides/installing-using-linux-tools.rst:45 -#: ../source/guides/installing-using-linux-tools.rst:124 -#: ../source/guides/installing-using-linux-tools.rst:138 -#: ../source/guides/installing-using-linux-tools.rst:158 -msgid "Python 2::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:41 -msgid "Python 3: ``sudo yum install python3 python3-wheel``" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:43 -msgid "Fedora 22:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:50 -msgid "Python 3: ``sudo dnf install python3 python3-wheel``" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:53 -msgid "" -"To get newer versions of pip, setuptools, and wheel for Python 2, you can " -"enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:63 -msgid "CentOS/RHEL" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:65 -msgid "" -"CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core " -"repositories, although :ref:`setuptools` is installed by default." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:68 -msgid "To install pip and wheel for the system Python, there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:70 -msgid "" -"Enable the `EPEL repository `_ using " -"`these instructions `__. On EPEL 6 and EPEL7, you can " -"install pip like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:77 -msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:81 -msgid "" -"Since EPEL only offers extra, non-conflicting packages, EPEL does not offer " -"setuptools, since it's in the core repository." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:85 -msgid "" -"Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:92 -msgid "To additionally upgrade setuptools, run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:97 -msgid "" -"To install pip, wheel, and setuptools, in a parallel, non-system environment " -"(using yum) then there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:101 -msgid "" -"Use the \"Software Collections\" feature to enable a parallel collection " -"that includes pip, setuptools, and wheel." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:104 -msgid "" -"For Redhat, see here: http://developers.redhat.com/products/" -"softwarecollections/overview/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:106 -msgid "For CentOS, see here: https://www.softwarecollections.org/en/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:108 -msgid "Be aware that collections may not contain the most recent versions." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:110 -msgid "" -"Enable the `IUS repository `_ and install " -"one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which " -"are kept fairly up to date." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:116 -msgid "For example, for Python 3.4 on CentOS7/RHEL7::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:122 -msgid "openSUSE" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:129 -#: ../source/guides/installing-using-linux-tools.rst:143 -#: ../source/guides/installing-using-linux-tools.rst:162 -msgid "Python 3::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:135 -msgid "Debian/Ubuntu" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:150 -msgid "" -"Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" " -"`_ by default, " -"which is a significant behavior change that can be surprising to some users." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:156 -msgid "Arch Linux" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:168 -msgid "" -"Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the " -"only option is to manually place the repo files as described." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 -msgid "Installing packages using pip and virtual environments" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 -msgid "" -"This guide discusses how to install packages using :ref:`pip` and a virtual " -"environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` " -"for Python 2. These are the lowest-level tools for managing Python packages " -"and are recommended if higher-level tools do not suit your needs." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 -msgid "" -"This doc uses the term **package** to refer to a :term:`Distribution " -"Package` which is different from an :term:`Import Package` that which is " -"used to import modules in your Python source code." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 -msgid "Installing pip" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 -msgid "" -":ref:`pip` is the reference Python package manager. It's used to install and " -"update packages. You'll need to make sure you have the latest version of pip " -"installed." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 -msgid "" -"Debian and most other distributions include a `python-pip`_ package, if you " -"want to use the Linux distribution-provided versions of pip see :doc:`/" -"guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 -msgid "" -"You can also install pip yourself to ensure you have the latest version. " -"It's recommended to use the system pip to bootstrap a user installation of " -"pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 -msgid "Afterwards, you should have the newest pip installed in your user site:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 -msgid "" -"The Python installers for Windows include pip. You should be able to access " -"pip using:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 -msgid "You can make sure that pip is up-to-date by running:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 -msgid "Installing virtualenv" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 -msgid "" -"If you are using Python 3.3 or newer, the :mod:`venv` module is the " -"preferred way to create and manage virtual environments. venv is included in " -"the Python standard library and requires no additional installation. If you " -"are using venv, you may skip this section." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 -msgid "" -":ref:`virtualenv` is used to manage Python packages for different projects. " -"Using virtualenv allows you to avoid installing Python packages globally " -"which could break system tools or other projects. You can install virtualenv " -"using pip." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 -msgid "Creating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 -msgid "" -":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to " -"manage separate package installations for different projects. They " -"essentially allow you to create a \"virtual\" isolated Python installation " -"and install packages into that virtual installation. When you switch " -"projects, you can simply create a new virtual environment and not have to " -"worry about breaking the packages installed in the other environments. It is " -"always recommended to use a virtual environment while developing Python " -"applications." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 -msgid "" -"To create a virtual environment, go to your project's directory and run " -"venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the " -"below commands." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 -msgid "" -"The second argument is the location to create the virtual environment. " -"Generally, you can just create this in your project and call it ``env``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 -msgid "venv will create a virtual Python installation in the ``env`` folder." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 -msgid "" -"You should exclude your virtual environment directory from your version " -"control system using ``.gitignore`` or similar." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 -msgid "Activating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 -msgid "" -"Before you can start installing or using packages in your virtual " -"environment you'll need to *activate* it. Activating a virtual environment " -"will put the virtual environment-specific ``python`` and ``pip`` executables " -"into your shell's ``PATH``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 -msgid "" -"You can confirm you're in the virtual environment by checking the location " -"of your Python interpreter, it should point to the ``env`` directory." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 -msgid "" -"As long as your virtual environment is activated pip will install packages " -"into that specific environment and you'll be able to import and use packages " -"in your Python application." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 -msgid "Leaving the virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 -msgid "" -"If you want to switch projects or otherwise leave your virtual environment, " -"simply run:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 -msgid "" -"If you want to re-enter the virtual environment just follow the same " -"instructions above about activating a virtual environment. There's no need " -"to re-create the virtual environment." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 -msgid "Installing packages" -msgstr "Instalo de pakoj" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 -msgid "" -"Now that you're in your virtual environment you can install packages. Let's " -"install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 -msgid "" -"pip should download requests and all of its dependencies and install them:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 -msgid "Installing specific versions" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 -msgid "" -"pip allows you to specify which version of a package to install using :term:" -"`version specifiers `. For example, to install a specific " -"version of ``requests``:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 -msgid "To install the latest ``2.x`` release of requests:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 -msgid "To install pre-release versions of packages, use the ``--pre`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 -msgid "Installing extras" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 -msgid "" -"Some packages have optional `extras`_. You can tell pip to install these by " -"specifying the extra in brackets:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 -msgid "Installing from source" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 -msgid "pip can install a package directly from source, for example:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 -msgid "" -"Additionally, pip can install packages from source in `development mode`_, " -"meaning that changes to the source directory will immediately affect the " -"installed package without needing to re-install:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 -msgid "Installing from version control systems" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 -msgid "" -"pip can install packages directly from their version control system. For " -"example, you can install directly from a git repository:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 -msgid "" -"For more information on supported version control systems and syntax, see " -"pip's documentation on :ref:`VCS Support `." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 -#: ../source/tutorials/installing-packages.rst:569 -msgid "Installing from local archives" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 -msgid "" -"If you have a local copy of a :term:`Distribution Package`'s archive (a zip, " -"wheel, or tar file) you can install it directly with pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 -msgid "" -"If you have a directory containing archives of multiple packages, you can " -"tell pip to look for packages there and not to use the :term:`Python Package " -"Index (PyPI)` at all:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 -msgid "" -"This is useful if you are installing packages on a system with limited " -"connectivity or if you want to strictly control the origin of distribution " -"packages." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 -msgid "Using other package indexes" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 -msgid "" -"If you want to download packages from a different index than the :term:" -"`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 -msgid "" -"If you want to allow packages from both the :term:`Python Package Index " -"(PyPI)` and a separate index, you can use the ``--extra-index-url`` flag " -"instead:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 -#: ../source/tutorials/installing-packages.rst:389 -msgid "Upgrading packages" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 -msgid "" -"pip can upgrade packages in-place using the ``--upgrade`` flag. For example, " -"to install the latest version of ``requests`` and all of its dependencies:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 -msgid "Using requirements files" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 -msgid "" -"Instead of installing packages individually, pip allows you to declare all " -"dependencies in a :ref:`Requirements File `. For " -"example you could create a :file:`requirements.txt` file containing:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 -msgid "" -"And tell pip to install all of the packages in this file using the ``-r`` " -"flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 -msgid "Freezing dependencies" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 -msgid "" -"Pip can export a list of all installed packages and their versions using the " -"``freeze`` command:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 -msgid "Which will output a list of package specifiers such as:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 -msgid "" -"This is useful for creating :ref:`pip:Requirements Files` that can re-create " -"the exact versions of all packages installed in an environment." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:2 -msgid "Making a PyPI-friendly README" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:4 -msgid "" -"README files can help your users understand your project and can be used to " -"set your project's description on PyPI. This guide helps you create a README " -"in a PyPI-friendly format and include your README in your package so it " -"appears on PyPI." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:9 -msgid "Creating a README file" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:11 -msgid "" -"README files for Python projects are often named ``README``, ``README.txt``, " -"``README.rst``, or ``README.md``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:13 -msgid "" -"For your README to display properly on PyPI, choose a markup language " -"supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:16 -msgid "plain text" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:17 -msgid "" -"`reStructuredText `_ (without " -"Sphinx extensions)" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:18 -msgid "" -"Markdown (`GitHub Flavored Markdown `_ by " -"default, or `CommonMark `_)" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:21 -msgid "" -"It's customary to save your README file in the root of your project, in the " -"same directory as your :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:25 -msgid "Including your README in your package's metadata" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:27 -msgid "" -"To include your README's contents as your package description, set your " -"project's ``Description`` and ``Description-Content-Type`` metadata, " -"typically in your project's :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:33 -msgid ":ref:`description-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:34 -msgid ":ref:`description-content-type-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:36 -msgid "" -"For example, to set these values in a package's :file:`setup.py` file, use " -"``setup()``'s ``long_description`` and ``long_description_content_type``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:39 -msgid "" -"Set the value of ``long_description`` to the contents (not the path) of the " -"README file itself. Set the ``long_description_content_type`` to an accepted " -"``Content-Type``-style value for your README file's markup, such as ``text/" -"plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:45 -msgid "" -"If you're using GitHub-flavored Markdown to write a project's description, " -"ensure you upgrade the following tools:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:60 -msgid "The minimum required versions of the respective tools are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:62 -msgid "``setuptools >= 38.6.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:63 -msgid "``wheel >= 0.31.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:64 -msgid "``twine >= 1.11.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:66 -msgid "" -"It's recommended that you use ``twine`` to upload the project's distribution " -"packages:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:72 -msgid "" -"For example, see this :file:`setup.py` file, which reads the contents of :" -"file:`README.md` as ``long_description`` and identifies the markup as GitHub-" -"flavored Markdown:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:95 -msgid "Validating reStructuredText markup" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:97 -msgid "" -"If your README is written in reStructuredText, any invalid markup will " -"prevent it from rendering, causing PyPI to instead just show the README's " -"raw source." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:100 -msgid "" -"Note that Sphinx extensions used in docstrings, such as `directives and " -"roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```" -"\"), are not allowed here and will result in error messages like \"``Error: " -"Unknown interpreted text role \"py:func\".``\"." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:105 -msgid "" -"You can check your README for markup errors before uploading as follows:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:107 -msgid "" -"Install the latest version of `twine `_; " -"version 1.12.0 or higher is required:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:122 -msgid "" -"Build the sdist and wheel for your project as described under :ref:" -"`Packaging Your Project`." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:125 -msgid "Run ``twine check`` on the sdist and wheel::" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:129 -msgid "" -"This command will report any problems rendering your README. If your markup " -"renders fine, the command will output ``Checking distribution FILENAME: " -"Passed``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:4 -msgid "Migrating to PyPI.org" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:6 -msgid "" -":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``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:12 -msgid "Publishing releases" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:14 -msgid "``pypi.org`` is the default upload platform as of September 2016." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:16 -msgid "" -"Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. " -"As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:19 -msgid "" -"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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:22 -msgid "" -"The default upload settings switched to ``pypi.org`` in the following " -"versions:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:24 -msgid "``twine`` 1.8.0" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:25 -msgid "``setuptools`` 27.0.0" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:26 -msgid "Python 2.7.13 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:27 -msgid "Python 3.4.6 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:28 -msgid "Python 3.5.3 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:29 -msgid "Python 3.6.0 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:31 -msgid "" -"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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:48 -msgid "" -"Then simply delete the line starting with ``repository`` and you will use " -"your upload tool's default URL." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:51 -msgid "" -"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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:67 -msgid "" -"(``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.)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:73 -msgid "Registering package names & metadata" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:75 -msgid "" -"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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:79 -msgid "" -"As a result, attempting explicit registration after switching to using PyPI." -"org for uploads will give the following error message::" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:84 -msgid "" -"The solution is to skip the registration step, and proceed directly to " -"uploading artifacts." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:89 -#: ../source/guides/using-testpypi.rst:5 -msgid "Using TestPyPI" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:91 -msgid "" -"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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:113 -msgid "Registering new user accounts" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:115 -msgid "" -"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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:121 -msgid "Browsing packages" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:123 -msgid "" -"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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:130 -msgid "Downloading packages" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:132 -msgid "``pypi.org`` is the default host for downloading packages." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:135 -msgid "Managing published packages and releases" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:137 -msgid "" -"``pypi.org`` provides a fully functional interface for logged in users to " -"manage their published packages and releases." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:5 -msgid "Multi-version installs" -msgstr "" - -#: ../source/guides/multi-version-installs.rst:8 -msgid "" -"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``)." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:13 -msgid "" -"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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:19 -msgid "" -"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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:31 -msgid "" -"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 ``python -c ''`` to invoke the application's main " -"entry point directly." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:38 -msgid "" -"Refer to the `pkg_resources documentation `__ for more details." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:5 -msgid "Packaging binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:8 -msgid "2013-12-08" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:10 -msgid "" -"One of the features of the CPython reference interpreter is that, in " -"addition to allowing the execution of Python code, it also exposes a rich C " -"API for use by other software. One of the most common uses of this C API is " -"to create importable C extensions that allow things which aren't always easy " -"to achieve in pure Python code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:20 -msgid "An overview of binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:23 -msgid "Use cases" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:25 -msgid "" -"The typical use cases for binary extensions break down into just three " -"conventional categories:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:28 -msgid "" -"**accelerator modules**: these modules are completely self-contained, and " -"are created solely to run faster than the equivalent pure Python code runs " -"in CPython. Ideally, accelerator modules will always have a pure Python " -"equivalent to use as a fallback if the accelerated version isn't available " -"on a given system. The CPython standard library makes extensive use of " -"accelerator modules. *Example*: When importing ``datetime``, Python falls " -"back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not " -"available." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:39 -msgid "" -"**wrapper modules**: these modules are created to expose existing C " -"interfaces to Python code. They may either expose the underlying C interface " -"directly, or else expose a more \"Pythonic\" API that makes use of Python " -"language features to make the API easier to use. The CPython standard " -"library makes extensive use of wrapper modules. *Example*: `functools.py " -"`_ is a " -"Python module wrapper for `_functoolsmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:47 -msgid "" -"**low-level system access**: these modules are created to access lower level " -"features of the CPython runtime, the operating system, or the underlying " -"hardware. Through platform specific code, extension modules may achieve " -"things that aren't possible in pure Python code. A number of CPython " -"standard library modules are written in C in order to access interpreter " -"internals that aren't exposed at the language level. *Example*: ``sys``, " -"which comes from `sysmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:56 -msgid "" -"One particularly notable feature of C extensions is that, when they don't " -"need to call back into the interpreter runtime, they can release CPython's " -"global interpreter lock around long-running operations (regardless of " -"whether those operations are CPU or IO bound)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:61 -msgid "" -"Not all extension modules will fit neatly into the above categories. The " -"extension modules included with NumPy, for example, span all three use cases " -"- they move inner loops to C for speed reasons, wrap external libraries " -"written in C, FORTRAN and other languages, and use low level system " -"interfaces for both CPython and the underlying operation system to support " -"concurrent execution of vectorised operations and to tightly control the " -"exact memory layout of created objects." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:71 -msgid "Disadvantages" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:73 -msgid "" -"The main disadvantage of using binary extensions is the fact that it makes " -"subsequent distribution of the software more difficult. One of the " -"advantages of using Python is that it is largely cross platform, and the " -"languages used to write extension modules (typically C or C++, but really " -"any language that can bind to the CPython C API) typically require that " -"custom binaries be created for different platforms." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:80 -msgid "This means that binary extensions:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:82 -msgid "" -"require that end users be able to either build them from source, or else " -"that someone publish pre-built binaries for common platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:85 -msgid "" -"may not be compatible with different builds of the CPython reference " -"interpreter" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:88 -msgid "" -"often will not work correctly with alternative interpreters such as PyPy, " -"IronPython or Jython" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:91 -msgid "" -"if handcoded, make maintenance more difficult by requiring that maintainers " -"be familiar not only with Python, but also with the language used to create " -"the binary extension, as well as with the details of the CPython C API." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:96 -msgid "" -"if a pure Python fallback implementation is provided, make maintenance more " -"difficult by requiring that changes be implemented in two places, and " -"introducing additional complexity in the test suite to ensure both versions " -"are always executed." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:101 -msgid "" -"Another disadvantage of relying on binary extensions is that alternative " -"import mechanisms (such as the ability to import modules directly from " -"zipfiles) often won't work for extension modules (as the dynamic loading " -"mechanisms on most platforms can only load libraries from disk)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:108 -msgid "Alternatives to handcoded accelerator modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:110 -msgid "" -"When extension modules are just being used to make code run faster (after " -"profiling has identified the code where the speed increase is worth " -"additional maintenance effort), a number of other alternatives should also " -"be considered:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:115 -msgid "" -"look for existing optimised alternatives. The CPython standard library " -"includes a number of optimised data structures and algorithms (especially in " -"the builtins and the ``collections`` and ``itertools`` modules). The Python " -"Package Index also offers additional alternatives. Sometimes, the " -"appropriate choice of standard library or third party module can avoid the " -"need to create your own accelerator module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:122 -msgid "" -"for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython " -"runtime. The main barrier to adopting PyPy is typically reliance on other " -"binary extension modules - while PyPy does emulate the CPython C API, " -"modules that rely on that cause problems for the PyPy JIT, and the emulation " -"layer can often expose latent defects in extension modules that CPython " -"currently tolerates (frequently around reference counting errors - an object " -"having one live reference instead of two often won't break anything, but no " -"references instead of one is a major problem)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:132 -msgid "" -"`Cython `__ is a mature static compiler that can compile " -"most Python code to C extension modules. The initial compilation provides " -"some speed increases (by bypassing the CPython interpreter layer), and " -"Cython's optional static typing features can offer additional opportunities " -"for speed increases. Using Cython still has the disadvantage of increasing " -"the complexity of distributing the resulting application, but has the " -"benefit of having a reduced barrier to entry for Python programmers " -"(relative to other languages like C or C++)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:141 -msgid "" -"`Numba `__ is a newer tool, created by members of " -"the scientific Python community, that aims to leverage LLVM to allow " -"selective compilation of pieces of a Python application to native machine " -"code at runtime. It requires that LLVM be available on the system where the " -"code is running, but can provide significant speed increases, especially for " -"operations that are amenable to vectorisation." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:150 -msgid "Alternatives to handcoded wrapper modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:152 -msgid "" -"The C ABI (Application Binary Interface) is a common standard for sharing " -"functionality between multiple applications. One of the strengths of the " -"CPython C API (Application Programming Interface) is allowing Python users " -"to tap into that functionality. However, wrapping modules by hand is quite " -"tedious, so a number of other alternative approaches should be considered." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:158 -msgid "" -"The approaches described below don't simplify the distribution case at all, " -"but they *can* significantly reduce the maintenance burden of keeping " -"wrapper modules up to date." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:162 -msgid "" -"In addition to being useful for the creation of accelerator modules, `Cython " -"`__ is also useful for creating wrapper modules for C or " -"C++. It still involves wrapping the interfaces by hand, however, and is very " -"repetitive, so may not be a good choice for wrapping large APIs." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:168 -msgid "" -"`pybind11 `__ is a pure C++11 library that " -"provides a clean C++ interface to the CPython (and PyPy) C API. It does not " -"require a pre-processing step; it is written entirely in templated C++. " -"Helpers are included for Setuptools or CMake builds. It was based on `Boost." -"Python `__, but doesn't require the Boost libraries or BJam." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:175 -msgid "" -"`cffi `__ is a project created by some of the " -"PyPy developers to make it straightforward for developers that already know " -"both Python and C to expose their C modules to Python applications. It also " -"makes it relatively straightforward to wrap a C module based on its header " -"files, even if you don't know C yourself." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:181 -msgid "" -"One of the key advantages of ``cffi`` is that it is compatible with the PyPy " -"JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing " -"JIT optimisations." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:185 -msgid "" -"`SWIG `__ is a wrapper interface generator that allows " -"a variety of programming languages, including Python, to interface with C " -"and C++ code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:189 -msgid "" -"The standard library's ``ctypes`` module, while useful for getting access to " -"C level interfaces when header information isn't available, suffers from the " -"fact that it operates solely at the C ABI level, and thus has no automatic " -"consistency checking between the interface actually being exported by the " -"library and the one declared in the Python code. By contrast, the above " -"alternatives are all able to operate at the C *API* level, using C header " -"files to ensure consistency between the interface exported by the library " -"being wrapped and the one expected by the Python wrapper module. While " -"``cffi`` *can* operate directly at the C ABI level, it suffers from the same " -"interface inconsistency problems as ``ctypes`` when it is used that way." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:203 -msgid "Alternatives for low level system access" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:205 -msgid "" -"For applications that need low level system access (regardless of the " -"reason), a binary extension module often *is* the best way to go about it. " -"This is particularly true for low level access to the CPython runtime " -"itself, since some operations (like releasing the Global Interpreter Lock) " -"are simply invalid when the interpreter is running code, even if a module " -"like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API " -"interfaces." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:213 -msgid "" -"For cases where the extension module is manipulating the underlying " -"operating system or hardware (rather than the CPython runtime), it may " -"sometimes be better to just write an ordinary C library (or a library in " -"another systems programming language like C++ or Rust that can export a C " -"compatible ABI), and then use one of the wrapping techniques described above " -"to make the interface available as an importable Python module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:222 -msgid "Implementing binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:224 -msgid "" -"The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in " -"C `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:241 -msgid "Building binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:244 -msgid "Building extensions for multiple platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:246 -msgid "" -"If you plan to distribute your extension, you should provide :term:`wheels " -"` for all the platforms you intend to support. For most extensions, " -"this is at least one package per Python version times the number of OS and " -"architectures you support. These are usually built on continuous " -"integration (CI) systems. There are tools to help you build highly " -"redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:" -"`multibuild`." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:256 -msgid "Binary extensions for Windows" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:258 -msgid "" -"Before it is possible to build a binary extension, it is necessary to ensure " -"that you have a suitable compiler available. On Windows, Visual C is used to " -"build the official CPython interpreter, and should be used to build " -"compatible binary extensions." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:263 -msgid "" -"Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio " -"2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older " -"versions of Visual Studio are no longer easily available from Microsoft, so " -"for versions of Python prior to 3.5, the compilers must be obtained " -"differently if you do not already have a copy of the relevant version of " -"Visual Studio." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:269 -msgid "" -"To set up a build environment for binary extensions, the steps are as " -"follows:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:271 -msgid "For Python 2.7" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:273 -msgid "" -"Install \"Visual C++ Compiler Package for Python 2.7\", which is available " -"from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:276 -msgid "" -"Use (a recent version of) setuptools in your setup.py (pip will do this for " -"you, in any case)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:278 -#: ../source/guides/packaging-binary-extensions.rst:288 -#: ../source/guides/packaging-binary-extensions.rst:295 -msgid "Done." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:280 -msgid "For Python 3.4" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:282 -msgid "" -"Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is " -"available from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:285 -msgid "" -"Work from an SDK command prompt (with the environment variables set, and the " -"SDK on PATH)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:287 -msgid "Set DISTUTILS_USE_SDK=1" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:290 -msgid "For Python 3.5" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:292 -msgid "" -"Install `Visual Studio 2015 Community Edition `__ (or any later version, " -"when these are released)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:297 -msgid "" -"Note that from Python 3.5 onwards, Visual Studio works in a backward " -"compatible way, which means that any future version of Visual Studio will be " -"able to build Python extensions for all Python versions from 3.5 onwards." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:301 -msgid "" -"Building with the recommended compiler on Windows ensures that a compatible " -"C library is used throughout the Python process." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:305 -msgid "Binary extensions for Linux" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:307 -msgid "" -"Linux binaries must use a sufficiently old glibc to be compatible with older " -"distributions. The `manylinux `_ Docker " -"images provide a build environment with a glibc old enough to support most " -"current Linux distributions on common architectures." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:313 -msgid "Binary extensions for macOS" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:315 -msgid "" -"Binary compatibility on macOS is determined by the target minimum deployment " -"system, e.g. *10.9*, which is often specified with the " -"``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries " -"on macOS. When building with setuptools / distutils, the deployment target " -"is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For " -"common deployment targets for macOS Python distributions, see the `MacPython " -"Spinning Wheels wiki `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:325 -msgid "Publishing binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:327 -msgid "" -"For interim guidance on this topic, see the discussion in `this issue " -"`_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:343 -msgid "Additional resources" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:345 -msgid "" -"Cross-platform development and distribution of extension modules is a " -"complex topic, so this guide focuses primarily on providing pointers to " -"various tools that automate dealing with the underlying technical " -"challenges. The additional resources in this section are instead intended " -"for developers looking to understand more about the underlying binary " -"interfaces that those systems rely on at runtime." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:352 -msgid "Cross-platform wheel generation with scikit-build" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:354 -msgid "" -"The `scikit-build `_ package " -"helps abstract cross-platform build operations and provides additional " -"capabilities when creating binary extension packages. Additional " -"documentation is also available on the `C runtime, compiler, and build " -"system generator `_ for Python binary extension modules." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:362 -msgid "Introduction to C/C++ extension modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:364 -msgid "" -"For a more in depth explanation of how extension modules are used by CPython " -"on a Debian system, see the following articles:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:367 -msgid "" -"`What are (c)python extension modules? `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:368 -msgid "`Releasing the gil `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:369 -msgid "" -"`Writing cpython extension modules using C++ `_" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:3 -msgid "Packaging namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:5 -msgid "" -"Namespace packages allow you to split the sub-packages and modules within a " -"single :term:`package ` across multiple, separate :term:" -"`distribution packages ` (referred to as " -"**distributions** in this document to avoid ambiguity). For example, if you " -"have the following package structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:24 -msgid "And you use this package in your code like so::" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:29 -msgid "Then you can break these sub-packages into two separate distributions:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:46 -msgid "Each sub-package can now be separately installed, used, and versioned." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:48 -msgid "" -"Namespace packages can be useful for a large collection of loosely-related " -"packages (such as a large corpus of client libraries for multiple products " -"from a single company). However, namespace packages come with several " -"caveats and are not appropriate in all cases. A simple alternative is to use " -"a prefix on all of your distributions such as ``import " -"mynamespace_subpackage_a`` (you could even use ``import " -"mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:58 -msgid "Creating a namespace package" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:60 -msgid "" -"There are currently three different approaches to creating namespace " -"packages:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:62 -msgid "" -"Use `native namespace packages`_. This type of namespace package is defined " -"in :pep:`420` and is available in Python 3.3 and later. This is recommended " -"if packages in your namespace only ever need to support Python 3 and " -"installation via ``pip``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:66 -msgid "" -"Use `pkgutil-style namespace packages`_. This is recommended for new " -"packages that need to support Python 2 and 3 and installation via both " -"``pip`` and ``python setup.py install``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:69 -msgid "" -"Use `pkg_resources-style namespace packages`_. This method is recommended if " -"you need compatibility with packages already using this method or if your " -"package needs to be zip-safe." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:73 -msgid "" -"While native namespace packages and pkgutil-style namespace packages are " -"largely compatible, pkg_resources-style namespace packages are not " -"compatible with the other methods. It's inadvisable to use different methods " -"in different distributions that provide packages to the same namespace." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:80 -msgid "Native namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:82 -msgid "" -"Python 3.3 added **implicit** namespace packages from :pep:`420`. All that " -"is required to create a native namespace package is that you just omit :file:" -"`__init__.py` from the namespace package directory. An example file " -"structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:97 -msgid "" -"It is extremely important that every distribution that uses the namespace " -"package omits the :file:`__init__.py` or uses a pkgutil-style :file:" -"`__init__.py`. If any distribution does not, it will cause the namespace " -"logic to fail and the other sub-packages will not be importable." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:102 -msgid "" -"Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:" -"`setuptools.find_packages` won't find the sub-package. You must use :func:" -"`setuptools.find_namespace_packages` instead or explicitly list all packages " -"in your :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:117 -msgid "" -"A complete working example of two native namespace packages can be found in " -"the `native namespace package example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:123 -msgid "" -"Because native and pkgutil-style namespace packages are largely compatible, " -"you can use native namespace packages in the distributions that only support " -"Python 3 and pkgutil-style namespace packages in the distributions that need " -"to support Python 2 and 3." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:129 -msgid "pkgutil-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:131 -msgid "" -"Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. " -"This can be used to declare namespace packages that need to be compatible " -"with both Python 2.3+ and Python 3. This is the recommended approach for the " -"highest level of compatibility." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:136 -msgid "" -"To create a pkgutil-style namespace package, you need to provide an :file:" -"`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:148 -#: ../source/guides/packaging-namespace-packages.rst:194 -msgid "" -"The :file:`__init__.py` file for the namespace package needs to contain " -"**only** the following:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:155 -#: ../source/guides/packaging-namespace-packages.rst:201 -msgid "" -"**Every** distribution that uses the namespace package must include an " -"identical :file:`__init__.py`. If any distribution does not, it will cause " -"the namespace logic to fail and the other sub-packages will not be " -"importable. Any additional code in :file:`__init__.py` will be inaccessible." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:160 -msgid "" -"A complete working example of two pkgutil-style namespace packages can be " -"found in the `pkgutil namespace example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:171 -msgid "pkg_resources-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:173 -msgid "" -"`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and " -"the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together " -"these can be used to declare namespace packages. While this approach is no " -"longer recommended, it is widely present in most existing namespace " -"packages. If you are creating a new distribution within an existing " -"namespace package that uses this method then it's recommended to continue " -"using this as the different methods are not cross-compatible and it's not " -"advisable to try to migrate an existing package." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:182 -msgid "" -"To create a pkg_resources-style namespace package, you need to provide an :" -"file:`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:206 -msgid "" -"Some older recommendations advise the following in the namespace package :" -"file:`__init__.py`:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:216 -msgid "" -"The idea behind this was that in the rare case that setuptools isn't " -"available packages would fall-back to the pkgutil-style packages. This isn't " -"advisable because pkgutil and pkg_resources-style namespace packages are not " -"cross-compatible. If the presence of setuptools is a concern then the " -"package should just explicitly depend on setuptools via ``install_requires``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:223 -msgid "" -"Finally, every distribution must provide the ``namespace_packages`` argument " -"to :func:`~setuptools.setup` in :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:237 -msgid "" -"A complete working example of two pkg_resources-style namespace packages can " -"be found in the `pkg_resources namespace example project`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 -msgid "" -"Publishing package distribution releases using GitHub Actions CI/CD workflows" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 -msgid "" -"`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an " -"event occurs on the GitHub platform. One popular choice is having a workflow " -"that's triggered by a ``push`` event. This guide shows you how to publish a " -"Python distribution whenever a tagged commit is pushed. It will use the " -"`pypa/gh-action-pypi-publish GitHub Action`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 -msgid "" -"This guide *assumes* that you already have a project that you know how to " -"build distributions for and *it lives on GitHub*." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 -msgid "Saving credentials on GitHub" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 -msgid "" -"In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, " -"meaning that we'll have two separate sets of credentials. And we'll need to " -"save them in the GitHub repository settings." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 -msgid "Let's begin! 🚀" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 -msgid "" -"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " -"token`_. If you have the project on PyPI already, limit the token scope to " -"just that project. You can call it something like ``GitHub Actions CI/CD — " -"project-org/project-repo`` in order for it to be easily distinguishable in " -"the token list. **Don't close the page just yet — you won't see that token " -"again.**" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 -msgid "" -"In a separate browser tab or window, go to the ``Settings`` tab of your " -"target repository and then click on `Secrets`_ in the left sidebar." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 -msgid "" -"Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from " -"the first step." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 -msgid "" -"Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the " -"steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 -msgid "" -"If you don't have a TestPyPI account, you'll need to create it. It's not the " -"same as a regular PyPI account." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 -msgid "Creating a workflow definition" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 -msgid "" -"GitHub CI/CD workflows are declared in YAML files stored in the ``.github/" -"workflows/`` directory of your repository." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 -msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 -msgid "" -"Start it with a meaningful name and define the event that should make GitHub " -"run this workflow:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 -msgid "Defining a workflow job environment" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 -msgid "" -"Now, let's add initial setup for our job. It's a process that will execute " -"commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 -msgid "Checking out the project and building distributions" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 -msgid "Then, add the following under the ``build-n-publish`` section:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 -msgid "" -"This will download your repository into the CI runner and then install and " -"activate Python 3.7." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 -msgid "" -"And now we can build dists from source. In this example, we'll use ``build`` " -"package, assuming that your project has a ``pyproject.toml`` properly set up " -"(see :pep:`517`/:pep:`518`)." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 -msgid "" -"You can use any other method for building distributions as long as it " -"produces ready-to-upload artifacts saved into the ``dist/`` folder." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 -msgid "So add this to the steps list:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 -msgid "Publishing the distribution to PyPI and TestPyPI" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 -msgid "Finally, add the following steps at the end:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 -msgid "" -"These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the " -"first one uploads contents of the ``dist/`` folder into TestPyPI " -"unconditionally and the second does that to PyPI, but only if the current " -"commit is tagged." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 -msgid "That's all, folks!" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 -msgid "" -"Now, whenever you push a tagged commit to your Git repository remote on " -"GitHub, this workflow will publish it to PyPI. And it'll publish any push to " -"TestPyPI which is useful for providing test builds to your alpha users as " -"well as making sure that your release pipeline remains healthy!" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:5 -msgid "Single-sourcing the package version" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:8 -msgid "" -"There are many techniques to maintain a single source of truth for the " -"version number of your project:" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:11 -msgid "" -"Read the file in :file:`setup.py` and get the version. Example (from `pip " -"setup.py `_)::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:38 -msgid "" -"As of the release of setuptools 46.4.0, one can accomplish the same thing by " -"instead placing the following in the project's ``setup.cfg`` file (replacing " -"\"package\" with the import name of the package):" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:47 -msgid "" -"Earlier versions of setuptools implemented the ``attr:`` directive by " -"importing the module, but setuptools 46.4.0 added rudimentary AST analysis " -"so that ``attr:`` can function without having to import any of the package's " -"dependencies." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:52 -msgid "" -"Also, please be aware that declarative config indicators, including the " -"``attr:`` directive, are not supported in parameters to ``setup.py``." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:55 -msgid "" -"Use an external build tool that either manages updating both locations, or " -"offers an API that both locations can use." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:58 -msgid "" -"Few tools you could use, in no particular order, and not necessarily " -"complete: `bump2version `_, `changes " -"`_, `commitizen `_, `zest.releaser `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:65 -msgid "" -"Set the value to a ``__version__`` global variable in a dedicated module in " -"your project (e.g. :file:`version.py`), then have :file:`setup.py` read and " -"``exec`` the value into a variable." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:76 -msgid "" -"Example using this technique: `warehouse `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:78 -msgid "" -"Place the value in a simple ``VERSION`` text file and have both :file:`setup." -"py` and the project code read it." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:86 -msgid "" -"An advantage with this technique is that it's not specific to Python. Any " -"tool can read the version." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:91 -msgid "" -"With this approach you must make sure that the ``VERSION`` file is included " -"in all your source and binary distributions (e.g. add ``include VERSION`` to " -"your :file:`MANIFEST.in`)." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:95 -msgid "" -"Set the value in :file:`setup.py`, and have the project code use the " -"``importlib.metadata`` API to fetch the value at runtime. (``importlib." -"metadata`` was introduced in Python 3.8 and is available to older versions " -"as the ``importlib-metadata`` project.) An installed project's version can " -"be fetched with the API as follows::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:110 -msgid "" -"Be aware that the ``importlib.metadata`` API only knows about what's in the " -"installation metadata, which is not necessarily the code that's currently " -"imported." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:114 -msgid "" -"If a project uses this method to fetch its version at runtime, then its " -"``install_requires`` value needs to be edited to install ``importlib-" -"metadata`` on pre-3.8 versions of Python like so::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:128 -msgid "" -"An older (and less efficient) alternative to ``importlib.metadata`` is the " -"``pkg_resources`` API provided by ``setuptools``::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:134 -msgid "" -"If a project uses ``pkg_resources`` to fetch its own version at runtime, " -"then ``setuptools`` must be added to the project's ``install_requires`` list." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:138 -msgid "" -"Example using this technique: `setuptools `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:141 -msgid "" -"Set the value to ``__version__`` in ``sample/__init__.py`` and import " -"``sample`` in :file:`setup.py`." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:155 -msgid "" -"Although this technique is common, beware that it will fail if ``sample/" -"__init__.py`` imports packages from ``install_requires`` dependencies, which " -"will very likely not be installed yet when :file:`setup.py` is run." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:161 -msgid "" -"Keep the version number in the tags of a version control system (Git, " -"Mercurial, etc) instead of in the code, and automatically extract it from " -"there using `setuptools_scm `_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:5 -msgid "Supporting multiple Python versions" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:37 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:43 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:49 -msgid "Automated testing and continuous integration" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:51 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:56 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:60 -msgid "" -"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:" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:66 -msgid "" -"`Travis CI `_ provides both a Linux and a macOS " -"environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit " -"while the macOS is 10.9.2 at the time of writing." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:69 -msgid "" -"`Appveyor `_ provides a Windows environment " -"(Windows Server 2012)." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:80 -msgid "" -"Both `Travis CI`_ 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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:85 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:89 -msgid "Tools for single-source Python packages" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:91 -msgid "" -"`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_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:100 -msgid "" -"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" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:107 -msgid "a Python 2 (by syntax) module in a Python 3 project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:108 -msgid "a Python 3 (by syntax) module in a *Python 2* project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:110 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:117 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:124 -msgid "What's in which Python?" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:126 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:3 -msgid "Supporting Windows using Appveyor" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:6 -msgid "2015-12-03" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:8 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:20 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:24 -msgid "" -"The Appveyor service is a continuous integration service, much like the " -"better-known `Travis`_ service that is commonly used for testing by projects " -"hosted on `Github`_. However, unlike Travis, the build workers on Appveyor " -"are Windows hosts and have the necessary compilers installed to build Python " -"extensions." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:30 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:38 -msgid "Setting up" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:40 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:45 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:49 -msgid "" -"Once you have set up your Appveyor account and added your project, Appveyor " -"will automatically build your project each time a commit occurs. This " -"behaviour will be familiar to users of Travis." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:54 -msgid "Adding Appveyor support to your project" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:56 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:61 -msgid "" -"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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:69 -msgid "appveyor.yml" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:75 -msgid "" -"This file can be downloaded from `here `__." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:77 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:80 -msgid "" -"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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:88 -msgid "" -"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``)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:94 -msgid "" -"The ``build`` section simply switches off builds - there is no build step " -"needed for Python, unlike languages like ``C#``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:97 -msgid "" -"The main sections that will need to be tailored to your project are " -"``test_script`` and ``after_test``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:100 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:109 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:114 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:119 -msgid "Support script" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:121 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:126 -msgid "" -"`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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:133 -msgid "" -"You can simply download the batch file and include it in your project " -"unchanged." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:137 -msgid "Access to the built wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:139 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:147 -msgid "Additional notes" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:150 -msgid "Testing with tox" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:152 -msgid "" -"Many projects use the `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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:156 -msgid "" -"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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:160 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:165 -msgid "" -"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" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:170 -msgid "``DISTUTILS_USE_SDK``" -msgstr "``DISTUTILS_USE_SDK``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:171 -msgid "``MSSdk``" -msgstr "``MSSdk``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:172 -msgid "``INCLUDE``" -msgstr "``INCLUDE``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:173 -msgid "``LIB``" -msgstr "``LIB``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:175 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:181 -msgid "" -"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 Travis or 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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:188 -msgid "" -"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``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:192 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:197 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:203 -msgid "Automatically uploading wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:205 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:210 -msgid "" -"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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:216 -msgid "External dependencies" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:218 -msgid "" -"The supplied scripts will successfully build any distribution that does not " -"rely on 3rd party external libraries for the build." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:221 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:230 -msgid "Support scripts" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:232 -msgid "For reference, the SDK setup support script is listed here:" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:234 -msgid "``appveyor-sample/build.cmd``" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:5 -msgid "Tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:7 -msgid "" -"If you're familiar with Python packaging and installation, and just want to " -"know what tools are currently recommended, then here it is." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:12 -msgid "Application dependency management" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:14 -msgid "" -"Use :ref:`pipenv` to manage library dependencies when developing Python " -"applications. See :doc:`../tutorials/managing-dependencies` for more details " -"on using ``pipenv``." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:18 -msgid "When ``pipenv`` does not meet your use case, consider other tools like:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:20 -msgid ":ref:`pip`" -msgstr ":ref:`pip`" - -#: ../source/guides/tool-recommendations.rst:22 -msgid "`pip-tools `_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:24 -msgid "`Poetry `_" -msgstr "`Poetry `_" - -#: ../source/guides/tool-recommendations.rst:27 -msgid "Installation tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:29 -msgid "" -"Use :ref:`pip` to install Python :term:`packages ` " -"from :term:`PyPI `. [1]_ [2]_ Depending on how :" -"ref:`pip` is installed, you may need to also install :ref:`wheel` to get the " -"benefit of wheel caching. [3]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:34 -msgid "" -"Use :ref:`virtualenv`, or `venv`_ to isolate application specific " -"dependencies from a shared Python installation. [4]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:37 -msgid "" -"If you're looking for management of fully integrated cross-platform software " -"stacks, consider:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:40 -msgid ":ref:`buildout`: primarily focused on the web development community" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:42 -msgid "" -":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the " -"scientific community." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:47 -msgid "Packaging tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:49 -msgid "" -"Use :ref:`setuptools` to define projects and create :term:`Source " -"Distributions `. [5]_ [6]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:52 -msgid "" -"Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:" -"`wheel project ` to create :term:`wheels `. This is " -"especially beneficial, if your project contains binary extensions." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:56 -msgid "" -"Use `twine `_ for uploading distributions " -"to :term:`PyPI `." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:61 -msgid "Publishing platform migration" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:63 -msgid "" -"The original Python Package Index implementation (previously hosted at `pypi." -"python.org `_) has been phased out in favour of an " -"updated implementation hosted at `pypi.org `_." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:67 -msgid "" -"See :ref:`Migrating to PyPI.org` for more information on the status of the " -"migration, and what settings to change in your clients." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:72 -msgid "" -"There are some cases where you might choose to use ``easy_install`` (from :" -"ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` " -"(which pip doesn't support). For a detailed breakdown, see :ref:`pip vs " -"easy_install`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:77 -msgid "" -"The acceptance of :pep:`453` means that :ref:`pip` will be available by " -"default in most installations of Python 3.4 or later. See the :pep:" -"`rationale section <453#rationale>` from :pep:`453` as for why pip was " -"chosen." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:82 -msgid "" -"`get-pip.py `_ and :ref:" -"`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv " -"` do not currently. Also, the common \"python-pip\" package that's " -"found in various linux distros, does not depend on \"python-wheel\" " -"currently." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:88 -msgid "" -"Beginning with Python 3.4, ``venv`` will create virtualenv environments with " -"``pip`` installed, thereby making it an equal alternative to :ref:" -"`virtualenv`. However, using :ref:`virtualenv` will still be recommended for " -"users that need cross-version consistency." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:93 -msgid "" -"Although you can use pure ``distutils`` for many projects, it does not " -"support defining dependencies on other projects and is missing several " -"convenience utilities for automatically populating distribution metadata " -"correctly that are provided by ``setuptools``. Being outside the standard " -"library, ``setuptools`` also offers a more consistent feature set across " -"different versions of Python, and (unlike ``distutils``), recent versions of " -"``setuptools`` support all of the modern metadata fields described in :ref:" -"`core-metadata`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:102 -msgid "" -"Even for projects that do choose to use ``distutils``, when :ref:`pip` " -"installs such projects directly from source (rather than installing from a " -"prebuilt :term:`wheel ` file), it will actually build your project " -"using :ref:`setuptools` instead." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:107 -msgid "" -"`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` " -"in June 2013, thereby making setuptools the default choice for packaging." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:5 -msgid "Including files in source distributions with ``MANIFEST.in``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:7 -msgid "" -"When building a :term:`source distribution ` for your package, by default only a minimal set of files are " -"included. You may find yourself wanting to include extra files in the " -"source distribution, such as an authors/contributors file, a :file:`docs/` " -"directory, or a directory of data files used for testing purposes. There " -"may even be extra files that you *need* to include; for example, if your :" -"file:`setup.py` computes your project's ``long_description`` by reading from " -"both a README and a changelog file, you'll need to include both those files " -"in the sdist so that people that build or install from the sdist get the " -"correct results." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:17 -msgid "" -"Adding & removing files to & from the source distribution is done by writing " -"a :file:`MANIFEST.in` file at the project root." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:22 -msgid "How files are included in an sdist" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:24 -msgid "The following files are included in a source distribution by default:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:26 -msgid "" -"all Python source files implied by the ``py_modules`` and ``packages`` " -"``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:28 -msgid "" -"all C source files mentioned in the ``ext_modules`` or ``libraries`` " -"``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:30 -msgid "scripts specified by the ``scripts`` ``setup()`` argument" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:31 -msgid "" -"all files specified by the ``package_data`` and ``data_files`` ``setup()`` " -"arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:33 -msgid "" -"the file specified by the ``license_file`` option in :file:`setup.cfg` " -"(setuptools 40.8.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:35 -msgid "" -"all files specified by the ``license_files`` option in :file:`setup.cfg` " -"(setuptools 42.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:37 -msgid "all files matching the pattern :file:`test/test*.py`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:38 -msgid ":file:`setup.py` (or whatever you called your setup script)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:39 -msgid ":file:`setup.cfg`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:40 -msgid ":file:`README`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:41 -msgid ":file:`README.txt`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:42 -msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:43 -msgid ":file:`README.md` (setuptools 36.4.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:44 -msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:45 -msgid ":file:`MANIFEST.in`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:47 -msgid "" -"After adding the above files to the sdist, the commands in :file:`MANIFEST." -"in` (if such a file exists) are executed in order to add and remove further " -"files to & from the sdist. Default files can even be removed from the sdist " -"with the appropriate :file:`MANIFEST.in` command." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:52 -msgid "" -"After processing the :file:`MANIFEST.in` file, setuptools removes the :file:" -"`build/` directory as well as any directories named :file:`RCS`, :file:" -"`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file " -"and an :file:`*.egg-info` directory. This behavior cannot be changed with :" -"file:`MANIFEST.in`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:60 -msgid ":file:`MANIFEST.in` commands" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:62 -msgid "" -"A :file:`MANIFEST.in` file consists of commands, one per line, instructing " -"setuptools to add or remove some set of files from the sdist. The commands " -"are:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:67 -msgid "Command" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:69 -msgid ":samp:`include {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:69 -msgid "Add all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid ":samp:`exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid "Remove all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid "" -"Add all files under directories matching ``dir-pattern`` that match any of " -"the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid "" -"Remove all files under directories matching ``dir-pattern`` that match any " -"of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid ":samp:`global-include {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid "" -"Add all files anywhere in the source tree matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid ":samp:`global-exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid "" -"Remove all files anywhere in the source tree matching any of the listed " -"patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid ":samp:`graft {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid "Add all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid ":samp:`prune {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid "Remove all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:79 -msgid "" -"The patterns here are glob-style patterns: ``*`` matches zero or more " -"regular filename characters (on Unix, everything except forward slash; on " -"Windows, everything except backslash and colon); ``?`` matches a single " -"regular filename character, and ``[chars]`` matches any one of the " -"characters between the square brackets (which may contain character ranges, " -"e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented " -"support for ``**`` matching zero or more characters including forward slash, " -"backslash, and colon." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:87 -msgid "" -"Directory patterns are relative to the root of the project directory; e.g., " -"``graft example*`` will include a directory named :file:`examples` in the " -"project root but will not include :file:`docs/examples/`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:91 -msgid "" -"File & directory names in :file:`MANIFEST.in` should be ``/``-separated; " -"setuptools will automatically convert the slashes to the local platform's " -"appropriate directory separator." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:95 -msgid "" -"Commands are processed in the order they appear in the :file:`MANIFEST.in` " -"file. For example, given the commands::" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:101 -msgid "" -"the contents of the directory tree :file:`tests` will first be added to the " -"sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, " -"or ``.pyd`` extension will be removed from the sdist. If the commands were " -"in the opposite order, then ``*.pyc`` files etc. would be only be removed " -"from what was already in the sdist before adding :file:`tests`, and if :file:" -"`tests` happened to contain any ``*.pyc`` files, they would end up included " -"in the sdist because the exclusion happened before they were included." -msgstr "" - -#: ../source/guides/using-testpypi.rst:7 -msgid "" -"``TestPyPI`` is a separate instance of the :term:`Python Package Index " -"(PyPI)` that allows you to try out the distribution tools and process " -"without worrying about affecting the real index. TestPyPI is hosted at `test." -"pypi.org `_" -msgstr "" - -#: ../source/guides/using-testpypi.rst:13 -msgid "Registering your account" -msgstr "" - -#: ../source/guides/using-testpypi.rst:15 -msgid "" -"Because TestPyPI has a separate database from the live PyPI, you'll need a " -"separate user account for specifically for TestPyPI. Go to https://test.pypi." -"org/account/register/ to register your account." -msgstr "" - -#: ../source/guides/using-testpypi.rst:19 -msgid "" -"The database for TestPyPI may be periodically pruned, so it is not unusual " -"for user accounts to be deleted." -msgstr "" - -#: ../source/guides/using-testpypi.rst:24 -msgid "Using TestPyPI with Twine" -msgstr "" - -#: ../source/guides/using-testpypi.rst:26 -msgid "" -"You can upload your distributions to TestPyPI using :ref:`twine` by " -"specifying the ``--repository`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:33 -msgid "" -"You can see if your package has successfully uploaded by navigating to the " -"URL ``https://test.pypi.org/project/`` where " -"``sampleproject`` is the name of your project that you uploaded. It may take " -"a minute or two for your project to appear on the site." -msgstr "" - -#: ../source/guides/using-testpypi.rst:39 -msgid "Using TestPyPI with pip" -msgstr "" - -#: ../source/guides/using-testpypi.rst:41 -msgid "" -"You can tell pip to download packages from TestPyPI instead of PyPI by " -"specifying the ``--index-url`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:56 -msgid "" -"If you want to allow pip to also pull other packages from PyPI you can " -"specify ``--extra-index-url`` to point to PyPI. This is useful when the " -"package you're testing has dependencies:" -msgstr "" - -#: ../source/guides/using-testpypi.rst:73 -msgid "Setting up TestPyPI in :file:`.pypirc`" -msgstr "" - -#: ../source/guides/using-testpypi.rst:75 -msgid "" -"If you want to avoid entering your username, you can configure TestPyPI in " -"your :file:`$HOME/.pypirc`:" -msgstr "" - -#: ../source/index.rst:3 ../source/key_projects.rst:181 -msgid "Python Packaging User Guide" -msgstr "Manlibro por Python-Uzantoj pri Pakado" - -#: ../source/index.rst:5 -msgid "" -"The Python Packaging User Guide (PyPUG) is a collection of tutorials and " -"guides for packaging Python software." -msgstr "" - -#: ../source/index.rst:5 -msgid "python, packaging, guide, tutorial" -msgstr "" - -#: ../source/index.rst:24 -msgid "" -"Welcome to the *Python Packaging User Guide*, a collection of tutorials and " -"references to help you distribute and install Python packages with modern " -"tools." -msgstr "" - -#: ../source/index.rst:28 -msgid "" -"This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. " -"We happily accept any :doc:`contributions and feedback `. 😊" -msgstr "" - -#: ../source/index.rst:36 -msgid "Get started" -msgstr "Komenci" - -#: ../source/index.rst:38 -msgid "" -"Essential tools and concepts for working within the Python development " -"ecosystem are covered in our :doc:`tutorials/index` section:" -msgstr "" - -#: ../source/index.rst:41 -msgid "" -"To learn how to install packages, see the :doc:`tutorial on installing " -"packages `" -msgstr "" - -#: ../source/index.rst:43 -msgid "" -"To learn how to manage dependencies in a version controlled project, see " -"the :doc:`tutorial on managing application dependencies `" -msgstr "" - -#: ../source/index.rst:45 -msgid "" -"To learn how to package and distribute your projects, see the :doc:`tutorial " -"on packaging and distributing `" -msgstr "" - -#: ../source/index.rst:47 -msgid "" -"To get an overview of packaging options for Python libraries and " -"applications, see the :doc:`Overview of Python Packaging `" -msgstr "" - -#: ../source/index.rst:52 -msgid "Learn more" -msgstr "Lerni pli" - -#: ../source/index.rst:54 -msgid "" -"Beyond our :doc:`tutorials/index`, this guide has several other resources:" -msgstr "" - -#: ../source/index.rst:56 -msgid "" -"The :doc:`guides/index` section for walk throughs, such as :doc:`guides/" -"installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." -msgstr "" - -#: ../source/index.rst:58 -msgid "" -"The :doc:`discussions/index` section for in-depth references on topics such " -"as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-" -"vs-easy-install`." -msgstr "" - -#: ../source/index.rst:60 -msgid "" -"The :doc:`specifications/index` section for packaging interoperability " -"specifications." -msgstr "" - -#: ../source/index.rst:62 -msgid "" -"Additionally, there is a list of :doc:`other projects ` " -"maintained by members of the Python Packaging Authority." -msgstr "" - -#: ../source/key_projects.rst:6 -msgid "Project Summaries" -msgstr "" - -#: ../source/key_projects.rst:8 -msgid "" -"Summaries and links for the most relevant projects in the space of Python " -"installation and packaging." -msgstr "" - -#: ../source/key_projects.rst:14 -msgid "PyPA Projects" -msgstr "Projektoj de PyPA" - -#: ../source/key_projects.rst:19 -msgid "bandersnatch" -msgstr "bandersnatch" - -#: ../source/key_projects.rst:21 -msgid "" -"`Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`Cimoj `__ | `GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:25 -msgid "" -"``bandersnatch`` is a PyPI mirroring client designed to efficiently create a " -"complete mirror of the contents of PyPI. Organizations thus save bandwidth " -"and latency on package downloads (especially in the context of automated " -"tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." -msgstr "" - -#: ../source/key_projects.rst:35 -msgid "build" -msgstr "build" - -#: ../source/key_projects.rst:37 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI " -"`__" -msgstr "" -"`Dokumentaro `__ | `Cimoj `__ | `GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:42 -msgid "" -"``build`` is a :pep:`517` compatible Python package builder. It provides a " -"CLI to build packages, as well as a Python API." -msgstr "" - -#: ../source/key_projects.rst:49 -msgid "cibuildwheel" -msgstr "cibuildwheel" - -#: ../source/key_projects.rst:51 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | " -"`Discussions `__ | " -"`Discord #cibuildwheel `__" -msgstr "" -"`Dokumentaro `__ | `Cimoj `__ | `GitHub `__ | `PyPI `__ | " -"`Diskutoj `__ | `Discord " -"#cibuildwheel `__" - -#: ../source/key_projects.rst:58 -msgid "" -"``cibuildwheel`` is a Python package that builds :term:`wheels ` for " -"all common platforms and Python versions on most CI systems. Also see :ref:" -"`multibuild`." -msgstr "" - -#: ../source/key_projects.rst:64 -msgid "distlib" -msgstr "distlib" - -#: ../source/key_projects.rst:66 -msgid "" -"`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" -msgstr "" -"`Dokumentaro `__ | `Cimoj `__ | `Bitbucket " -"`__ | `PyPI `__" - -#: ../source/key_projects.rst:71 -msgid "" -"``distlib`` is a library which implements low-level functions that relate to " -"packaging and distribution of Python software. ``distlib`` implements " -"several relevant PEPs (Python Enhancement Proposal standards) and is useful " -"for developers of third-party packaging tools to make and upload binary and " -"source :term:`distributions `, achieve " -"interoperability, resolve dependencies, manage package resources, and do " -"other similar functions." -msgstr "" - -#: ../source/key_projects.rst:80 -msgid "" -"Unlike the stricter :ref:`packaging` project (below), which specifically " -"implements modern Python packaging interoperability standards, ``distlib`` " -"also attempts to provide reasonable fallback behaviours when asked to handle " -"legacy packages and metadata that predate the modern interoperability " -"standards and fall into the subset of packages that are incompatible with " -"those standards." -msgstr "" - -#: ../source/key_projects.rst:90 -msgid "packaging" -msgstr "pakado" - -#: ../source/key_projects.rst:92 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:97 -msgid "" -"Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." -msgstr "" - -#: ../source/key_projects.rst:99 -msgid "" -"The core utilities in the packaging library handle version handling, " -"specifiers, markers, requirements, tags, and similar attributes and tasks " -"for Python packages. Most Python users rely on this library without needing " -"to explicitly call it; developers of the other Python packaging, " -"distribution, and installation tools listed here often use its functionality " -"to parse, discover, and otherwise handle dependency attributes." -msgstr "" - -#: ../source/key_projects.rst:107 -msgid "" -"This project specifically focuses on implementing the modern Python " -"packaging interoperability standards defined at :ref:`packaging-" -"specifications`, and will report errors for sufficiently old legacy packages " -"that are incompatible with those standards. In contrast, the :ref:`distlib` " -"project is a more permissive library that attempts to provide a plausible " -"reading of ambiguous metadata in cases where :ref:`packaging` will instead " -"report on error." -msgstr "" - -#: ../source/key_projects.rst:119 -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "pip" -msgstr "pip" - -#: ../source/key_projects.rst:121 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`Dokumentaro `__ | `Cimoj `__ | `GitHub `__ | `PyPI " -"`__" - -#: ../source/key_projects.rst:126 -msgid "" -"The most popular tool for installing Python packages, and the one included " -"with modern versions of Python." -msgstr "" - -#: ../source/key_projects.rst:129 -msgid "" -"It provides the essential core features for finding, downloading, and " -"installing packages from PyPI and other Python package indexes, and can be " -"incorporated into a wide range of development workflows via its command-line " -"interface (CLI)." -msgstr "" - -#: ../source/key_projects.rst:137 -msgid "Pipenv" -msgstr "Pipenv" - -#: ../source/key_projects.rst:139 -msgid "" -"`Docs `__ | `Source `__ | `Issues `__ | `PyPI " -"`__" -msgstr "" -"`Dokumentaro `__ | `Fonto `__ | `Cimoj `__ | `PyPI " -"`__" - -#: ../source/key_projects.rst:144 -msgid "" -"Pipenv is a project that aims to bring the best of all packaging worlds to " -"the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:" -"`virtualenv` into one single toolchain. It features very pretty terminal " -"colors." -msgstr "" - -#: ../source/key_projects.rst:148 -msgid "" -"Pipenv aims to help users manage environments, dependencies, and imported " -"packages on the command line. It also works well on Windows (which other " -"tools often underserve), makes and checkes file hashes, to ensure compliance " -"with hash-locked dependency specifiers, and eases uninstallation of packages " -"and dependencies. It is used by Python users and system administrators, but " -"has been less maintained since late 2018." -msgstr "" - -#: ../source/key_projects.rst:159 -msgid "Pipfile" -msgstr "Pipfile" - -#: ../source/key_projects.rst:161 -msgid "`Source `__" -msgstr "`Fonto `__" - -#: ../source/key_projects.rst:163 -msgid "" -":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level " -"application-centric alternative to :ref:`pip`'s lower-level :file:" -"`requirements.txt` file." -msgstr "" - -#: ../source/key_projects.rst:170 -msgid "pipx" -msgstr "pipx" - -#: ../source/key_projects.rst:172 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:176 -msgid "" -"pipx is a tool to install and run Python command-line applications without " -"causing dependency conflicts with other packages installed on the system." -msgstr "" - -#: ../source/key_projects.rst:183 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:187 -msgid "This guide!" -msgstr "" - -#: ../source/key_projects.rst:192 -msgid "readme_renderer" -msgstr "readme_renderer" - -#: ../source/key_projects.rst:194 -msgid "" -"`GitHub and docs `__ | `PyPI " -"`__" -msgstr "" - -#: ../source/key_projects.rst:197 -msgid "" -"``readme_renderer`` is a library that package developers use to render their " -"user documentation (README) files into HTML from markup languages such as " -"Markdown or reStructuredText. Developers call it on its own or via :ref:" -"`twine`, as part of their release management process, to check that their " -"package descriptions will properly display on PyPI." -msgstr "" - -#: ../source/key_projects.rst:208 -msgid "setuptools" -msgstr "setuptools" - -#: ../source/key_projects.rst:210 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`Dokumentaro `__ | `Cimoj " -"`__ | `GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:215 -msgid "" -"setuptools (which includes ``easy_install``) is a collection of enhancements " -"to the Python distutils that allow you to more easily build and distribute " -"Python :term:`distributions `, especially ones that " -"have dependencies on other packages." -msgstr "" - -#: ../source/key_projects.rst:220 -msgid "" -"`distribute`_ was a fork of setuptools that was merged back into setuptools " -"(in v0.7), thereby making setuptools the primary choice for Python packaging." -msgstr "" - -#: ../source/key_projects.rst:227 -msgid "trove-classifiers" -msgstr "" - -#: ../source/key_projects.rst:229 -msgid "" -"`Issues `__ | `GitHub " -"`__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:233 -msgid "" -"trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically " -"describe their projects `_ so that users can better find projects " -"that match their needs on the PyPI." -msgstr "" - -#: ../source/key_projects.rst:239 -msgid "" -"The trove-classifiers package contains a list of valid classifiers and " -"deprecated classifiers (which are paired with the classifiers that replace " -"them). Use this package to validate classifiers used in packages intended " -"for uploading to PyPI. As this list of classifiers is published as code, you " -"can install and import it, giving you a more convenient workflow compared to " -"referring to the `list published on PyPI `_. " -"The `issue tracker `_ for " -"the project hosts discussions on proposed classifiers and requests for new " -"classifiers." -msgstr "" - -#: ../source/key_projects.rst:253 -msgid "twine" -msgstr "" - -#: ../source/key_projects.rst:255 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:260 -msgid "" -"Twine is the primary tool developers use to upload packages to the Python " -"Package Index or other Python package indexes. It is a command-line program " -"that passes program files and metadata to a web API. Developers use it " -"because it's the official PyPI upload tool, it's fast and secure, it's " -"maintained, and it reliably works." -msgstr "" - -#: ../source/key_projects.rst:270 ../source/overview.rst:415 -msgid "virtualenv" -msgstr "" - -#: ../source/key_projects.rst:272 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:277 -msgid "" -"virtualenv is a tool which uses the command-line path environment variable " -"to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional " -"functionality, compared to :ref:`venv`, by supporting Python 2.7 and by " -"providing convenient features for configuring, maintaining, duplicating, and " -"troubleshooting the virtual environments. For more information, see the " -"section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/key_projects.rst:290 -msgid "Warehouse" -msgstr "" - -#: ../source/key_projects.rst:292 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:296 -msgid "" -"The current codebase powering the :term:`Python Package Index (PyPI)`. It is " -"hosted at `pypi.org `_. The default source for :ref:`pip` " -"downloads." -msgstr "" - -#: ../source/key_projects.rst:304 -msgid "wheel" -msgstr "" - -#: ../source/key_projects.rst:306 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:311 -msgid "" -"Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` " -"extension for creating :term:`wheel distributions `. Additionally, " -"it offers its own command line utility for creating and installing wheels." -msgstr "" - -#: ../source/key_projects.rst:315 -msgid "" -"See also `auditwheel `__, a tool that " -"package developers use to check and fix Python packages they are making in " -"the binary wheel format. It provides functionality to discover dependencies, " -"check metadata for compliance, and repair the wheel and metadata to properly " -"link and include external shared libraries in a package." -msgstr "" - -#: ../source/key_projects.rst:324 -msgid "Non-PyPA Projects" -msgstr "" - -#: ../source/key_projects.rst:329 -msgid "bento" -msgstr "" - -#: ../source/key_projects.rst:331 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:336 -msgid "" -"Bento is a packaging tool solution for Python software, targeted as an " -"alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's " -"philosophy is reproducibility, extensibility and simplicity (in that order)." -msgstr "" - -#: ../source/key_projects.rst:344 -msgid "buildout" -msgstr "" - -#: ../source/key_projects.rst:346 -msgid "" -"`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:351 -msgid "" -"Buildout is a Python-based build system for creating, assembling and " -"deploying applications from multiple parts, some of which may be non-Python-" -"based. It lets you create a buildout configuration and reproduce the same " -"software later." -msgstr "" - -#: ../source/key_projects.rst:358 -msgid "conda" -msgstr "" - -#: ../source/key_projects.rst:360 -msgid "`Docs `__" -msgstr "" - -#: ../source/key_projects.rst:362 -msgid "" -"conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution " -"from `Anaconda, Inc `__ specifically " -"aimed at the scientific community, and in particular on Windows where the " -"installation of binary extensions is often difficult." -msgstr "" - -#: ../source/key_projects.rst:369 -msgid "" -"Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, " -"but provides many of their combined features in terms of package management, " -"virtual environment management and deployment of binary extensions." -msgstr "" - -#: ../source/key_projects.rst:373 -msgid "" -"Conda does not install packages from PyPI and can install only from the " -"official Anaconda repositories, or anaconda.org (a place for user-" -"contributed *conda* packages), or a local (e.g. intranet) package server. " -"However, note that :ref:`pip` can be installed into, and work side-by-side " -"with conda for managing :term:`distributions ` from " -"PyPI. Also, `conda skeleton `__ is a tool to make " -"Python packages installable by conda by first fetching them from PyPI and " -"modifying their metadata." -msgstr "" - -#: ../source/key_projects.rst:386 -msgid "devpi" -msgstr "" - -#: ../source/key_projects.rst:388 -msgid "" -"`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:392 -msgid "" -"devpi features a powerful PyPI-compatible server and PyPI proxy cache with a " -"complementary command line tool to drive packaging, testing and release " -"activities with Python. devpi also provides a browsable and searchable web " -"interface." -msgstr "" - -#: ../source/key_projects.rst:401 -msgid "flit" -msgstr "" - -#: ../source/key_projects.rst:403 -msgid "" -"`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:407 -msgid "" -"Flit provides a simple way to upload pure Python packages and modules to " -"PyPI. It focuses on `making the easy things easy `_ for " -"packaging. Flit can generate a configuration file to quickly set up a simple " -"project, build source distributions and wheels, and upload them to PyPI." -msgstr "" - -#: ../source/key_projects.rst:412 -msgid "" -"Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on " -"tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to " -"upload them to PyPI. Flit requires Python 3, but you can use it to " -"distribute modules for Python 2, so long as they can be imported on Python 3." -msgstr "" - -#: ../source/key_projects.rst:422 -msgid "enscons" -msgstr "" - -#: ../source/key_projects.rst:424 -msgid "" -"`Source `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:428 -msgid "" -"Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-" -"compatible source distributions and wheels without using distutils or " -"setuptools, including distributions with C extensions. Enscons has a " -"different architecture and philosophy than :ref:`distutils`. Rather than " -"adding build features to a Python packaging system, enscons adds Python " -"packaging to a general purpose build system. Enscons helps you to build " -"sdists that can be automatically built by :ref:`pip`, and wheels that are " -"independent of enscons." -msgstr "" - -#: ../source/key_projects.rst:443 -msgid "Hashdist" -msgstr "" - -#: ../source/key_projects.rst:445 -msgid "" -"`Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:448 -msgid "" -"Hashdist is a library for building non-root software distributions. Hashdist " -"is trying to be “the Debian of choice for cases where Debian technology " -"doesn’t work”. The best way for Pythonistas to think about Hashdist may be a " -"more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed " -"at solving the problem of installing scientific software, and making package " -"distribution stateless, cached, and branchable. It is used by some " -"researchers but has been lacking in maintenance since 2016." -msgstr "" - -#: ../source/key_projects.rst:460 -msgid "hatch" -msgstr "" - -#: ../source/key_projects.rst:462 -msgid "" -"`GitHub and Docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:465 -msgid "" -"Hatch is a unified command-line tool meant to conveniently manage " -"dependencies and environment isolation for Python developers. Python package " -"developers use Hatch to configure, version, specify dependencies for, and " -"publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload " -"packages to PyPI, and :ref:`pip` to download and install packages." -msgstr "" - -#: ../source/key_projects.rst:475 -msgid "multibuild" -msgstr "" - -#: ../source/key_projects.rst:477 -msgid "`GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:479 -msgid "" -"Multibuild is a set of CI scripts for building and testing Python :term:" -"`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :" -"ref:`cibuildwheel`." -msgstr "" - -#: ../source/key_projects.rst:485 -msgid "pex" -msgstr "" - -#: ../source/key_projects.rst:487 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:491 -msgid "" -"pex is both a library and tool for generating :file:`.pex` (Python " -"EXecutable) files, standalone Python environments in the spirit of :ref:" -"`virtualenv`. :file:`.pex` files are just carefully constructed zip files " -"with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are " -"designed to make deployment of Python applications as simple as ``cp``." -msgstr "" - -#: ../source/key_projects.rst:500 -msgid "pip-tools" -msgstr "" - -#: ../source/key_projects.rst:502 -msgid "" -"`GitHub and Docs `__ | `PyPI " -"`__" -msgstr "" - -#: ../source/key_projects.rst:505 -msgid "" -"pip-tools is a suite of tools meant for Python system administrators and " -"release managers who particularly want to keep their builds deterministic " -"yet stay up to date with new versions of their dependencies. Users can " -"specify particular release of their dependencies via hash, conveniently make " -"a properly formatted list of requirements from information in other parts of " -"their program, update all dependencies (a feature :ref:`pip` currently does " -"not provide), and create layers of constraints for the program to obey." -msgstr "" - -#: ../source/key_projects.rst:517 -msgid "piwheels" -msgstr "" - -#: ../source/key_projects.rst:519 -msgid "" -"`Website `__ | `Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:523 -msgid "" -"piwheels is a website, and software underpinning it, that fetches source " -"code distribution packages from PyPI and compiles them into binary wheels " -"that are optimized for installation onto Raspberry Pi computers. Raspberry " -"Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." -msgstr "" - -#: ../source/key_projects.rst:532 -msgid "poetry" -msgstr "" - -#: ../source/key_projects.rst:534 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:538 -msgid "" -"poetry is a command-line tool to handle dependency installation and " -"isolation as well as building and packaging of Python packages. It uses " -"``pyproject.toml`` and, instead of depending on the resolver functionality " -"within :ref:`pip`, provides its own dependency resolver. It attempts to " -"speed users' experience of installation and dependency resolution by locally " -"caching metadata about dependencies." -msgstr "" - -#: ../source/key_projects.rst:548 -msgid "pypiserver" -msgstr "" - -#: ../source/key_projects.rst:550 -msgid "" -"`Docs `__ | " -"`GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:554 -msgid "" -"pypiserver is a minimalist application that serves as a private Python " -"package index within organizations, implementing a simple API and browser " -"interface. You can upload private packages using standard upload tools, and " -"users can download and install them with :ref:`pip`, without publishing them " -"publicly. Organizations who use pypiserver usually download packages both " -"from pypiserver and from PyPI." -msgstr "" - -#: ../source/key_projects.rst:564 -msgid "scikit-build" -msgstr "" - -#: ../source/key_projects.rst:566 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:570 -msgid "" -"Scikit-build is an improved build system generator for CPython C/C++/Fortran/" -"Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :" -"ref:`pip`. It internally uses `cmake `__ " -"(available on PyPI) to provide better support for additional compilers, " -"build systems, cross compilation, and locating dependencies and their " -"associated build requirements. To speed up and parallelize the build of " -"large projects, the user can install `ninja `__ (also available on PyPI)." -msgstr "" - -#: ../source/key_projects.rst:582 -msgid "shiv" -msgstr "" - -#: ../source/key_projects.rst:584 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:588 -msgid "" -"shiv is a command line utility for building fully self contained Python " -"zipapps as outlined in :pep:`441`, but with all their dependencies included. " -"Its primary goal is making distributing Python applications and command line " -"tools fast & easy." -msgstr "" - -#: ../source/key_projects.rst:598 -msgid "" -"`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" -msgstr "" - -#: ../source/key_projects.rst:603 -msgid "" -"A flexible package manager designed to support multiple versions, " -"configurations, platforms, and compilers. Spack is like Homebrew, but " -"packages are written in Python and parameterized to allow easy swapping of " -"compilers, library versions, build options, etc. Arbitrarily many versions " -"of packages can coexist on the same system. Spack was designed for rapidly " -"building high performance scientific applications on clusters and " -"supercomputers." -msgstr "" - -#: ../source/key_projects.rst:611 -msgid "" -"Spack is not in PyPI (yet), but it requires no installation and can be used " -"immediately after cloning from GitHub." -msgstr "" - -#: ../source/key_projects.rst:617 -msgid "zest.releaser" -msgstr "" - -#: ../source/key_projects.rst:619 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:623 -msgid "" -"``zest.releaser`` is a Python package release tool providing an abstraction " -"layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to " -"automate incrementing package version numbers, updating changelogs, tagging " -"releases in source control, and uploading new packages to PyPI." -msgstr "" - -#: ../source/key_projects.rst:630 -msgid "Standard Library Projects" -msgstr "" - -#: ../source/key_projects.rst:635 -msgid "ensurepip" -msgstr "" - -#: ../source/key_projects.rst:637 -msgid "" -"`Docs `__ | `Issues " -"`__" -msgstr "" - -#: ../source/key_projects.rst:640 -msgid "" -"A package in the Python Standard Library that provides support for " -"bootstrapping :ref:`pip` into an existing Python installation or virtual " -"environment. In most cases, end users won't use this module, but rather it " -"will be used during the build of the Python distribution." -msgstr "" - -#: ../source/key_projects.rst:649 -msgid "distutils" -msgstr "" - -#: ../source/key_projects.rst:651 -msgid "" -"`Docs `__ | `Issues " -"`__" -msgstr "" - -#: ../source/key_projects.rst:654 -msgid "" -"The original Python packaging system, added to the standard library in " -"Python 2.0." -msgstr "" - -#: ../source/key_projects.rst:657 -msgid "" -"Due to the challenges of maintaining a packaging system where feature " -"updates are tightly coupled to language runtime updates, direct usage of :" -"ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being " -"the preferred replacement. :ref:`Setuptools` not only provides features that " -"plain :ref:`distutils` doesn't offer (such as dependency declarations and " -"entry point declarations), it also provides a consistent build interface and " -"feature set across all supported Python versions." -msgstr "" - -#: ../source/key_projects.rst:670 -msgid "venv" -msgstr "" - -#: ../source/key_projects.rst:672 -msgid "" -"`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:675 -msgid "" -"A package in the Python Standard Library (starting with Python 3.3) for " -"creating :term:`Virtual Environments `. For more " -"information, see the section on :ref:`Creating and using Virtual " -"Environments`." -msgstr "" - -#: ../source/news.rst:2 -msgid "News" -msgstr "" - -#: ../source/news.rst:5 -msgid "September 2019" -msgstr "" - -#: ../source/news.rst:6 -msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" -msgstr "" - -#: ../source/news.rst:9 -msgid "August 2019" -msgstr "" - -#: ../source/news.rst:10 -msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" -msgstr "" - -#: ../source/news.rst:13 -msgid "July 2019" -msgstr "" - -#: ../source/news.rst:14 -msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" -msgstr "" - -#: ../source/news.rst:15 -msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" -msgstr "" - -#: ../source/news.rst:16 -msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" -msgstr "" - -#: ../source/news.rst:17 -msgid "Updated directory layout examples for consistency. (:pr:`611`)" -msgstr "" - -#: ../source/news.rst:18 -msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" -msgstr "" - -#: ../source/news.rst:21 -msgid "June 2019" -msgstr "" - -#: ../source/news.rst:22 -msgid "Fixed some typos. (:pr:`620`)" -msgstr "" - -#: ../source/news.rst:25 -msgid "May 2019" -msgstr "" - -#: ../source/news.rst:26 -msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" -msgstr "" - -#: ../source/news.rst:27 -msgid "Added a MANIFEST.in guide page. (:pr:`609`)" -msgstr "" - -#: ../source/news.rst:30 -msgid "April 2019" -msgstr "" - -#: ../source/news.rst:31 -msgid "" -"Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" -msgstr "" - -#: ../source/news.rst:32 -msgid "Reduced emphasis on virtualenv. (:pr:`606`)" -msgstr "" - -#: ../source/news.rst:35 -msgid "March 2019" -msgstr "" - -#: ../source/news.rst:36 -msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" -msgstr "" - -#: ../source/news.rst:37 -msgid "Covered RTD details for contributing. (:pr:`600`)" -msgstr "" - -#: ../source/news.rst:40 -msgid "February 2019" -msgstr "" - -#: ../source/news.rst:41 -msgid "" -"Elaborate upon the differences between the tutorial and the real packaging " -"process. (:pr:`602`)" -msgstr "" - -#: ../source/news.rst:42 -msgid "Added instructions to install Python CLI applications. (:pr:`594`)" -msgstr "" - -#: ../source/news.rst:45 -msgid "January 2019" -msgstr "" - -#: ../source/news.rst:46 -msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" -msgstr "" - -#: ../source/news.rst:47 -msgid "Updated Sphinx and Nox. (:pr:`591`)" -msgstr "" - -#: ../source/news.rst:48 -msgid "Referenced Twine from Python3. (:pr:`581`)" -msgstr "" - -#: ../source/news.rst:51 -msgid "December 2018" -msgstr "" - -#: ../source/news.rst:52 -msgid "No programmers in the office!" -msgstr "" - -#: ../source/news.rst:55 -msgid "November 2018" -msgstr "" - -#: ../source/news.rst:56 -msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" -msgstr "" - -#: ../source/news.rst:57 -msgid "Changed bumpversion to bump2version. (:pr:`572`)" -msgstr "" - -#: ../source/news.rst:58 -msgid "Added single-sourcing package version example. (:pr:`573`)" -msgstr "" - -#: ../source/news.rst:59 -msgid "Added a guide for creating documentation. (:pr:`568`)" -msgstr "" - -#: ../source/news.rst:62 -msgid "October 2018" -msgstr "" - -#: ../source/news.rst:63 -msgid "Updated Nox package name. (:pr:`566`)" -msgstr "" - -#: ../source/news.rst:64 -msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" -msgstr "" - -#: ../source/news.rst:67 -msgid "September 2018" -msgstr "" - -#: ../source/news.rst:68 -msgid "Added a section on checking RST markup. (:pr:`554`)" -msgstr "" - -#: ../source/news.rst:69 -msgid "Updated user installs page. (:pr:`558`)" -msgstr "" - -#: ../source/news.rst:70 -msgid "Updated Google BigQuery urls. (:pr:`556`)" -msgstr "" - -#: ../source/news.rst:71 -msgid "Replaced tar command with working command. (:pr:`552`)" -msgstr "" - -#: ../source/news.rst:72 -msgid "" -"Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" -msgstr "" - -#: ../source/news.rst:75 -msgid "August 2018" -msgstr "" - -#: ../source/news.rst:76 -msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" -msgstr "" - -#: ../source/news.rst:77 -msgid "" -"Moved the Overview to a task based lead in along with the others. (:pr:`540`)" -msgstr "" - -#: ../source/news.rst:78 -msgid "Updated Python version supported by virtualenv. (:pr:`538`)" -msgstr "" - -#: ../source/news.rst:79 -msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" -msgstr "" - -#: ../source/news.rst:82 -msgid "July 2018" -msgstr "" - -#: ../source/news.rst:84 -msgid "Improved binary extension docs. (:pr:`531`)" -msgstr "" - -#: ../source/news.rst:85 -msgid "Added scikit-build to key projects. (:pr:`530`)" -msgstr "" - -#: ../source/news.rst:88 -msgid "June 2018" -msgstr "" - -#: ../source/news.rst:90 -msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" -msgstr "" - -#: ../source/news.rst:91 -msgid "Updated Markdown descriptions explanation. (:pr:`522`)" -msgstr "" - -#: ../source/news.rst:94 -msgid "May 2018" -msgstr "" - -#: ../source/news.rst:96 -msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" -msgstr "" - -#: ../source/news.rst:97 -msgid "" -"Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" -msgstr "" - -#: ../source/news.rst:98 -msgid "Simplified packaging tutorial. (:pr:`498`)" -msgstr "" - -#: ../source/news.rst:99 -msgid "Updated Windows users instructions for clarity. (:pr:`493`)" -msgstr "" - -#: ../source/news.rst:100 -msgid "Updated the license section description for completeness. (:pr:`492`)" -msgstr "" - -#: ../source/news.rst:101 -msgid "Added specification-style document to contributing section. (:pr:`489`)" -msgstr "" - -#: ../source/news.rst:102 -msgid "Added documentation types to contributing guide. (:pr:`485`)" -msgstr "" - -#: ../source/news.rst:105 -msgid "April 2018" -msgstr "" - -#: ../source/news.rst:107 -msgid "Added README guide. (:pr:`461`)" -msgstr "" - -#: ../source/news.rst:108 -msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" -msgstr "" - -#: ../source/news.rst:109 -msgid "Added instructions for Warehouse. (:pr:`471`)" -msgstr "" - -#: ../source/news.rst:110 -msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" -msgstr "" - -#: ../source/news.rst:111 -msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" -msgstr "" - -#: ../source/news.rst:112 -msgid "Added a guide for phasing out Python versions. (:pr:`459`)" -msgstr "" - -#: ../source/news.rst:113 -msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" -msgstr "" - -#: ../source/news.rst:116 -msgid "March 2018" -msgstr "" - -#: ../source/news.rst:118 -msgid "Updated \"installing scientific packages\". (:pr:`455`)" -msgstr "" - -#: ../source/news.rst:119 -msgid "" -"Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" -msgstr "" - -#: ../source/news.rst:120 -msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" -msgstr "" - -#: ../source/news.rst:121 -msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" -msgstr "" - -#: ../source/news.rst:124 -msgid "February 2018" -msgstr "" - -#: ../source/news.rst:126 -msgid "" -"Added python3-venv and python3-pip to Debian installation instructions. (:pr:" -"`445`)" -msgstr "" - -#: ../source/news.rst:127 -msgid "Updated PyPI migration info. (:pr:`439`)" -msgstr "" - -#: ../source/news.rst:128 -msgid "" -"Added a warning about managing multiple versions with pipenv. (:pr:`430`)" -msgstr "" - -#: ../source/news.rst:129 -msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" -msgstr "" - -#: ../source/news.rst:130 -msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" -msgstr "" - -#: ../source/news.rst:133 -msgid "January 2018" -msgstr "" - -#: ../source/news.rst:135 -msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" -msgstr "" - -#: ../source/news.rst:136 -msgid "Updated README.rst explanation. (:pr:`419`)" -msgstr "" - -#: ../source/news.rst:139 -msgid "December 2017" -msgstr "" - -#: ../source/news.rst:141 -msgid "" -"Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" -msgstr "" - -#: ../source/news.rst:142 -msgid "Noted which fields can be used with environment markers. (:pr:`416`)" -msgstr "" - -#: ../source/news.rst:143 -msgid "Updated Requires-Python section. (:pr:`414`)" -msgstr "" - -#: ../source/news.rst:144 -msgid "Added news page. (:pr:`404`)" -msgstr "" - -#: ../source/news.rst:147 -msgid "November 2017" -msgstr "" - -#: ../source/news.rst:149 -msgid "" -"Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" -msgstr "" - -#: ../source/news.rst:150 -msgid "" -"Updated the *Single Sourcing Package Version* tutorial to reflect pip's " -"current strategy. (:pr:`400`)" -msgstr "" - -#: ../source/news.rst:152 -msgid "" -"Added documentation about the ``py_modules`` argument to ``setup``. (:pr:" -"`398`)" -msgstr "" - -#: ../source/news.rst:153 -msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" -msgstr "" - -#: ../source/news.rst:156 -msgid "October 2017" -msgstr "" - -#: ../source/news.rst:158 -msgid "" -"Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" -msgstr "" - -#: ../source/news.rst:159 -msgid "" -"Created a new guide for managing packages using ``pip`` and ``virtualenv``. " -"(:pr:`385`)" -msgstr "" - -#: ../source/news.rst:160 -msgid "Split the specifications page into multiple pages. (:pr:`386`)" -msgstr "" - -#: ../source/news.rst:163 -msgid "September 2017" -msgstr "" - -#: ../source/news.rst:165 -msgid "" -"Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:" -"`379`)" -msgstr "" - -#: ../source/news.rst:167 -msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" -msgstr "" - -#: ../source/news.rst:170 -msgid "August 2017" -msgstr "" - -#: ../source/news.rst:172 -msgid "" -"Added a new, experimental tutorial on installing packages using ``Pipenv``. " -"(:pr:`369`)" -msgstr "" - -#: ../source/news.rst:173 -msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" -msgstr "" - -#: ../source/news.rst:174 -msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" -msgstr "" - -#: ../source/news.rst:177 -msgid "July 2017" -msgstr "" - -#: ../source/news.rst:179 -msgid "Added ``flit`` to the key projects list. (:pr:`358`)" -msgstr "" - -#: ../source/news.rst:180 -msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" -msgstr "" - -#: ../source/news.rst:181 -msgid "" -"Updated this guide's ``readme`` with instructions on how to build the guide " -"locally. (:pr:`356`)" -msgstr "" - -#: ../source/news.rst:182 -msgid "" -"Made the new ``TestPyPI`` URL more visible, adding note to homepage about " -"pypi.org. (:pr:`354`)" -msgstr "" - -#: ../source/news.rst:183 -msgid "" -"Added a note about the removal of the explicit registration API. (:pr:`347`)" -msgstr "" - -#: ../source/news.rst:186 -msgid "June 2017" -msgstr "" - -#: ../source/news.rst:188 -msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" -msgstr "" - -#: ../source/news.rst:189 -msgid "Added documentation for ``python_requires``. (:pr:`338`)" -msgstr "" - -#: ../source/news.rst:190 -msgid "" -"Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:" -"pr:`335`)" -msgstr "" - -#: ../source/news.rst:191 -msgid "" -"Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" -msgstr "" - -#: ../source/news.rst:192 -msgid "Added a license section to the distributing guide. (:pr:`331`)" -msgstr "" - -#: ../source/news.rst:193 -msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" -msgstr "" - -#: ../source/news.rst:194 -msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" -msgstr "" - -#: ../source/news.rst:195 -msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" -msgstr "" - -#: ../source/news.rst:196 -msgid "Switched to the PyPA theme. (:pr:`305`)" -msgstr "" - -#: ../source/news.rst:197 -msgid "Re-organized the documentation into the new structure. (:pr:`318`)" -msgstr "" - -#: ../source/news.rst:200 -msgid "May 2017" -msgstr "" - -#: ../source/news.rst:202 -msgid "" -"Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" -msgstr "" - -#: ../source/news.rst:203 -msgid "Added contributor and style guide. (:pr:`307`)" -msgstr "" - -#: ../source/news.rst:204 -msgid "" -"Documented ``pip`` and ``easy_install``'s differences for per-project " -"indexes. (:pr:`233`)" -msgstr "" - -#: ../source/news.rst:207 -msgid "April 2017" -msgstr "" - -#: ../source/news.rst:209 -msgid "Added travis configuration for testing pull requests. (:pr:`300`)" -msgstr "" - -#: ../source/news.rst:210 -msgid "" -"Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:" -"`299`)" -msgstr "" - -#: ../source/news.rst:211 -msgid "" -"Removed the ``twine register`` reference in the *Distributing Packages* " -"tutorial. (:pr:`271`)" -msgstr "" - -#: ../source/news.rst:212 -msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" -msgstr "" - -#: ../source/news.rst:213 -msgid "Added a topic on namespace packages. (:pr:`290`)" -msgstr "" - -#: ../source/news.rst:214 -msgid "" -"Added documentation explaining prominently how to install ``pip`` in ``/usr/" -"local``. (:pr:`230`)" -msgstr "" - -#: ../source/news.rst:215 -msgid "" -"Updated development mode documentation to mention that order of local " -"packages matters. (:pr:`208`)" -msgstr "" - -#: ../source/news.rst:216 -msgid "" -"Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted " -"projects (:pr:`239`)" -msgstr "" - -#: ../source/news.rst:217 -msgid "" -"Swaped order of :file:`setup.py` arguments for the upload command, as order " -"is significant. (:pr:`260`)" -msgstr "" - -#: ../source/news.rst:219 -msgid "" -"Explained how to install from unsupported sources using a helper " -"application. (:pr:`289`)" -msgstr "" - -#: ../source/news.rst:223 -msgid "March 2017" -msgstr "" - -#: ../source/news.rst:225 -msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" -msgstr "" - -#: ../source/news.rst:228 -msgid "February 2017" -msgstr "" - -#: ../source/news.rst:230 -msgid "Added :pep:`518`. (:pr:`281`)" -msgstr "" - -#: ../source/overview.rst:3 -msgid "An Overview of Packaging for Python" -msgstr "" - -#: ../source/overview.rst:7 -msgid "" -"As a general-purpose programming language, Python is designed to be used in " -"many ways. You can build web sites or industrial robots or a game for your " -"friends to play, and much more, all using the same core technology." -msgstr "" - -#: ../source/overview.rst:12 -msgid "" -"Python's flexibility is why the first step in every Python project must be " -"to think about the project's audience and the corresponding environment " -"where the project will run. It might seem strange to think about packaging " -"before writing code, but this process does wonders for avoiding future " -"headaches." -msgstr "" - -#: ../source/overview.rst:18 -msgid "" -"This overview provides a general-purpose decision tree for reasoning about " -"Python's plethora of packaging options. Read on to choose the best " -"technology for your next project." -msgstr "" - -#: ../source/overview.rst:26 -msgid "Thinking about deployment" -msgstr "" - -#: ../source/overview.rst:28 -msgid "" -"Packages exist to be installed (or *deployed*), so before you package " -"anything, you'll want to have some answers to the deployment questions below:" -msgstr "" - -#: ../source/overview.rst:32 -msgid "" -"Who are your software's users? Will your software be installed by other " -"developers doing software development, operations people in a datacenter, or " -"a less software-savvy group?" -msgstr "" - -#: ../source/overview.rst:35 -msgid "" -"Is your software intended to run on servers, desktops, mobile clients " -"(phones, tablets, etc.), or embedded in dedicated devices?" -msgstr "" - -#: ../source/overview.rst:37 -msgid "" -"Is your software installed individually, or in large deployment batches?" -msgstr "" - -#: ../source/overview.rst:39 -msgid "" -"Packaging is all about target environment and deployment experience. There " -"are many answers to the questions above and each combination of " -"circumstances has its own solutions. With this information, the following " -"overview will guide you to the packaging technologies best suited to your " -"project." -msgstr "" - -#: ../source/overview.rst:46 -msgid "Packaging Python libraries and tools" -msgstr "" - -#: ../source/overview.rst:48 -msgid "" -"You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are " -"just a few of the tools Python's ecosystem provides for distributing Python " -"code to developers, which you can read about in :doc:`guides/distributing-" -"packages-using-setuptools`." -msgstr "" - -#: ../source/overview.rst:53 -msgid "" -"The following approaches to packaging are meant for libraries and tools used " -"by technical audience in a development setting. If you're looking for ways " -"to package Python for a non-technical audience and/or a production setting, " -"skip ahead to :ref:`packaging-applications`." -msgstr "" - -#: ../source/overview.rst:59 -msgid "Python modules" -msgstr "" - -#: ../source/overview.rst:61 -msgid "" -"A Python file, provided it only relies on the standard library, can be " -"redistributed and reused. You will also need to ensure it's written for the " -"right version of Python, and only relies on the standard library." -msgstr "" - -#: ../source/overview.rst:66 -msgid "" -"This is great for sharing simple scripts and snippets between people who " -"both have compatible Python versions (such as via email, StackOverflow, or " -"GitHub gists). There are even some entire Python libraries that offer this " -"as an option, such as `bottle.py `_ and " -"`boltons `_." -msgstr "" - -#: ../source/overview.rst:73 -msgid "" -"However, this pattern won't scale for projects that consist of multiple " -"files, need additional libraries, or need a specific version of Python, " -"hence the options below." -msgstr "" - -#: ../source/overview.rst:78 -msgid "Python source distributions" -msgstr "" - -#: ../source/overview.rst:80 -msgid "" -"If your code consists of multiple Python files, it's usually organized into " -"a directory structure. Any directory containing Python files can comprise " -"an :term:`Import Package`." -msgstr "" - -#: ../source/overview.rst:84 -msgid "" -"Because packages consist of multiple files, they are harder to distribute. " -"Most protocols support transferring only one file at a time (when was the " -"last time you clicked a link and it downloaded multiple files?). It's easier " -"to get incomplete transfers, and harder to guarantee code integrity at the " -"destination." -msgstr "" - -#: ../source/overview.rst:90 -msgid "" -"So long as your code contains nothing but pure Python code, and you know " -"your deployment environment supports your version of Python, then you can " -"use Python's native packaging tools to create a *source* :term:`Distribution " -"Package`, or *sdist* for short." -msgstr "" - -#: ../source/overview.rst:95 -msgid "" -"Python's *sdists* are compressed archives (``.tar.gz`` files) containing one " -"or more packages or modules. If your code is pure-Python, and you only " -"depend on other Python packages, you can `go here to learn more `_." -msgstr "" - -#: ../source/overview.rst:100 -msgid "" -"If you rely on any non-Python code, or non-Python packages (such as `libxml2 " -"`_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next " -"section, which also has many advantages for pure-Python libraries." -msgstr "" - -#: ../source/overview.rst:107 -msgid "" -"Python and PyPI support multiple distributions providing different " -"implementations of the same package. For instance the unmaintained-but-" -"seminal `PIL distribution `_ provides the PIL " -"package, and so does `Pillow `_, an " -"actively-maintained fork of PIL!" -msgstr "" - -#: ../source/overview.rst:114 -msgid "" -"This Python packaging superpower makes it possible for Pillow to be a drop-" -"in replacement for PIL, just by changing your project's ``install_requires`` " -"or ``requirements.txt``." -msgstr "" - -#: ../source/overview.rst:119 -msgid "Python binary distributions" -msgstr "" - -#: ../source/overview.rst:121 -msgid "" -"So much of Python's practical power comes from its ability to integrate with " -"the software ecosystem, in particular libraries written in C, C++, Fortran, " -"Rust, and other languages." -msgstr "" - -#: ../source/overview.rst:125 -msgid "" -"Not all developers have the right tools or experiences to build these " -"components written in these compiled languages, so Python created the :term:" -"`Wheel`, a package format designed to ship libraries with compiled " -"artifacts. In fact, Python's package installer, ``pip``, always prefers " -"wheels because installation is always faster, so even pure-Python packages " -"work better with wheels." -msgstr "" - -#: ../source/overview.rst:132 -msgid "" -"Binary distributions are best when they come with source distributions to " -"match. Even if you don't upload wheels of your code for every operating " -"system, by uploading the sdist, you're enabling users of other platforms to " -"still build it for themselves. Default to publishing both sdist and wheel " -"archives together, *unless* you're creating artifacts for a very specific " -"use case where you know the recipient only needs one or the other." -msgstr "" - -#: ../source/overview.rst:140 -msgid "" -"Python and PyPI make it easy to upload both wheels and sdists together. Just " -"follow the :doc:`tutorials/packaging-projects` tutorial." -msgstr "" - -#: ../source/overview.rst:148 -msgid "" -"Python's recommended built-in library and tool packaging technologies. " -"Excerpted from `The Packaging Gradient (2017) `_." -msgstr "" - -#: ../source/overview.rst:155 -msgid "Packaging Python applications" -msgstr "" - -#: ../source/overview.rst:157 -msgid "" -"So far we've only discussed Python's native distribution tools. Based on our " -"introduction, you would be correct to infer these built-in approaches only " -"target environments which have Python, and an audience who knows how to " -"install Python packages." -msgstr "" - -#: ../source/overview.rst:162 -msgid "" -"With the variety of operating systems, configurations, and people out there, " -"this assumption is only safe when targeting a developer audience." -msgstr "" - -#: ../source/overview.rst:166 -msgid "" -"Python's native packaging is mostly built for distributing reusable code, " -"called libraries, between developers. You can piggyback **tools**, or basic " -"applications for developers, on top of Python's library packaging, using " -"technologies like `setuptools entry_points `_." -msgstr "" - -#: ../source/overview.rst:172 -msgid "" -"Libraries are building blocks, not complete applications. For distributing " -"applications, there's a whole new world of technologies out there." -msgstr "" - -#: ../source/overview.rst:176 -msgid "" -"The next few sections organize these application packaging options according " -"to their dependencies on the target environment, so you can choose the right " -"one for your project." -msgstr "" - -#: ../source/overview.rst:181 -msgid "Depending on a framework" -msgstr "" - -#: ../source/overview.rst:183 -msgid "" -"Some types of Python applications, like web site backends and other network " -"services, are common enough that they have frameworks to enable their " -"development and packaging. Other types of applications, like dynamic web " -"frontends and mobile clients, are complex enough to target that a framework " -"becomes more than a convenience." -msgstr "" - -#: ../source/overview.rst:189 -msgid "" -"In all these cases, it makes sense to work backwards, from the framework's " -"packaging and deployment story. Some frameworks include a deployment system " -"which wraps the technologies outlined in the rest of the guide. In these " -"cases, you'll want to defer to your framework's packaging guide for the " -"easiest and most reliable production experience." -msgstr "" - -#: ../source/overview.rst:195 -msgid "" -"If you ever wonder how these platforms and frameworks work under the hood, " -"you can always read the sections beyond." -msgstr "" - -#: ../source/overview.rst:199 -msgid "Service platforms" -msgstr "" - -#: ../source/overview.rst:201 -msgid "" -"If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku " -"or Google App Engine, you are going to want to follow their respective " -"packaging guides." -msgstr "" - -#: ../source/overview.rst:205 -msgid "" -"`Heroku `_" -msgstr "" - -#: ../source/overview.rst:206 -msgid "`Google App Engine `_" -msgstr "" - -#: ../source/overview.rst:207 -msgid "`PythonAnywhere `_" -msgstr "" - -#: ../source/overview.rst:208 -msgid "`OpenShift `_" -msgstr "" - -#: ../source/overview.rst:209 -msgid "\"Serverless\" frameworks like `Zappa `_" -msgstr "" - -#: ../source/overview.rst:211 -msgid "" -"In all these setups, the platform takes care of packaging and deployment, as " -"long as you follow their patterns. Most software does not fit one of these " -"templates, hence the existence of all the other options below." -msgstr "" - -#: ../source/overview.rst:216 -msgid "" -"If you're developing software that will be deployed to machines you own, " -"users' personal computers, or any other arrangement, read on." -msgstr "" - -#: ../source/overview.rst:220 -msgid "Web browsers and mobile applications" -msgstr "" - -#: ../source/overview.rst:222 -msgid "" -"Python's steady advances are leading it into new spaces. These days you can " -"write a mobile app or web application frontend in Python. While the language " -"may be familiar, the packaging and deployment practices are brand new." -msgstr "" - -#: ../source/overview.rst:227 -msgid "" -"If you're planning on releasing to these new frontiers, you'll want to check " -"out the following frameworks, and refer to their packaging guides:" -msgstr "" - -#: ../source/overview.rst:231 -msgid "`Kivy `_" -msgstr "" - -#: ../source/overview.rst:232 -msgid "`Beeware `_" -msgstr "" - -#: ../source/overview.rst:233 -msgid "`Brython `_" -msgstr "" - -#: ../source/overview.rst:234 -msgid "`Flexx `_" -msgstr "" - -#: ../source/overview.rst:236 -msgid "" -"If you are *not* interested in using a framework or platform, or just wonder " -"about some of the technologies and techniques utilized by the frameworks " -"above, continue reading below." -msgstr "" - -#: ../source/overview.rst:241 -msgid "Depending on a pre-installed Python" -msgstr "" - -#: ../source/overview.rst:243 -msgid "" -"Pick an arbitrary computer, and depending on the context, there's a very " -"good chance Python is already installed. Included by default in most Linux " -"and Mac operating systems for many years now, you can reasonably depend on " -"Python preexisting in your data centers or on the personal machines of " -"developers and data scientists." -msgstr "" - -#: ../source/overview.rst:249 -msgid "Technologies which support this model:" -msgstr "" - -#: ../source/overview.rst:251 -msgid "`PEX `_ (Python EXecutable)" -msgstr "" - -#: ../source/overview.rst:252 -msgid "" -"`zipapp `_ (does not help " -"manage dependencies, requires Python 3.5+)" -msgstr "" - -#: ../source/overview.rst:253 -msgid "`shiv `_ (requires Python 3)" -msgstr "" - -#: ../source/overview.rst:255 -msgid "" -"Of all the approaches here, depending on a pre-installed Python relies the " -"most on the target environment. Of course, this also makes for the smallest " -"package, as small as single-digit megabytes, or even kilobytes." -msgstr "" - -#: ../source/overview.rst:260 -msgid "" -"In general, decreasing the dependency on the target system increases the " -"size of our package, so the solutions here are roughly arranged by " -"increasing size of output." -msgstr "" - -#: ../source/overview.rst:267 -msgid "Depending on a separate software distribution ecosystem" -msgstr "" - -#: ../source/overview.rst:269 -msgid "" -"For a long time many operating systems, including Mac and Windows, lacked " -"built-in package management. Only recently did these OSes gain so-called " -"\"app stores\", but even those focus on consumer applications and offer " -"little for developers." -msgstr "" - -#: ../source/overview.rst:274 -msgid "" -"Developers long sought remedies, and in this struggle, emerged with their " -"own package management solutions, such as `Homebrew `_. " -"The most relevant alternative for Python developers is a package ecosystem " -"called `Anaconda `_. Anaconda is built around Python and is " -"increasingly common in academic, analytical, and other data-oriented " -"environments, even making its way `into server-oriented environments " -"`_." -msgstr "" - -#: ../source/overview.rst:284 -msgid "Instructions on building and publishing for the Anaconda ecosystem:" -msgstr "" - -#: ../source/overview.rst:286 -msgid "" -"`Building libraries and applications with conda `_" -msgstr "" - -#: ../source/overview.rst:287 -msgid "" -"`Transitioning a native Python package to Anaconda `_" -msgstr "" - -#: ../source/overview.rst:289 -msgid "" -"A similar model involves installing an alternative Python distribution, but " -"does not support arbitrary operating system-level packages:" -msgstr "" - -#: ../source/overview.rst:293 -msgid "`Enthought Canopy `_" -msgstr "" - -#: ../source/overview.rst:294 -msgid "`ActiveState ActivePython `_" -msgstr "" - -#: ../source/overview.rst:295 -msgid "`WinPython `_" -msgstr "" - -#: ../source/overview.rst:300 -msgid "Bringing your own Python executable" -msgstr "" - -#: ../source/overview.rst:302 -msgid "" -"Computing as we know it is defined by the ability to execute programs. Every " -"operating system natively supports one or more formats of program they can " -"natively execute." -msgstr "" - -#: ../source/overview.rst:306 -msgid "" -"There are many techniques and technologies which turn your Python program " -"into one of these formats, most of which involve embedding the Python " -"interpreter and any other dependencies into a single executable file." -msgstr "" - -#: ../source/overview.rst:311 -msgid "" -"This approach, called *freezing*, offers wide compatibility and seamless " -"user experience, though often requires multiple technologies, and a good " -"amount of effort." -msgstr "" - -#: ../source/overview.rst:315 -msgid "A selection of Python freezers:" -msgstr "" - -#: ../source/overview.rst:317 -msgid "`pyInstaller `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:318 -msgid "" -"`cx_Freeze `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:319 -msgid "" -"`constructor `_ - For command-line " -"installers" -msgstr "" - -#: ../source/overview.rst:320 -msgid "`py2exe `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:321 -msgid "`py2app `_ - Mac only" -msgstr "" - -#: ../source/overview.rst:322 -msgid "" -"`bbFreeze `_ - Windows, Linux, Python 2 " -"only" -msgstr "" - -#: ../source/overview.rst:323 -msgid "`osnap `_ - Windows and Mac" -msgstr "" - -#: ../source/overview.rst:324 -msgid "`pynsist `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:326 -msgid "" -"Most of the above imply single-user deployments. For multi-component server " -"applications, see `Chef Omnibus `_." -msgstr "" - -#: ../source/overview.rst:332 -msgid "Bringing your own userspace" -msgstr "" - -#: ../source/overview.rst:334 -msgid "" -"An increasing number of operating systems -- including Linux, Mac OS, and " -"Windows -- can be set up to run applications packaged as lightweight images, " -"using a relatively modern arrangement often referred to as `operating-system-" -"level virtualization `_, or *containerization*." -msgstr "" - -#: ../source/overview.rst:341 -msgid "" -"These techniques are mostly Python agnostic, because they package whole OS " -"filesystems, not just Python or Python packages." -msgstr "" - -#: ../source/overview.rst:344 -msgid "" -"Adoption is most extensive among Linux servers, where the technology " -"originated and where the technologies below work best:" -msgstr "" - -#: ../source/overview.rst:347 -msgid "`AppImage `_" -msgstr "" - -#: ../source/overview.rst:348 -msgid "`Docker `_" -msgstr "" - -#: ../source/overview.rst:349 -msgid "`Flatpak `_" -msgstr "" - -#: ../source/overview.rst:350 -msgid "`Snapcraft `_" -msgstr "" - -#: ../source/overview.rst:353 -msgid "Bringing your own kernel" -msgstr "" - -#: ../source/overview.rst:355 -msgid "" -"Most operating systems support some form of classical virtualization, " -"running applications packaged as images containing a full operating system " -"of their own. Running these virtual machines, or VMs, is a mature approach, " -"widespread in data center environments." -msgstr "" - -#: ../source/overview.rst:360 -msgid "" -"These techniques are mostly reserved for larger scale deployments in data " -"centers, though certain complex applications can benefit from this " -"packaging. Technologies are Python agnostic, and include:" -msgstr "" - -#: ../source/overview.rst:364 -msgid "`Vagrant `_" -msgstr "" - -#: ../source/overview.rst:365 -msgid "" -"`VHD `_, `AMI `_, and `other formats `_" -msgstr "" - -#: ../source/overview.rst:366 -msgid "" -"`OpenStack `_ - A cloud " -"management system in Python, with extensive VM support" -msgstr "" - -#: ../source/overview.rst:369 -msgid "Bringing your own hardware" -msgstr "" - -#: ../source/overview.rst:371 -msgid "" -"The most all-encompassing way to ship your software would be to ship it " -"already-installed on some hardware. This way, your software's user would " -"require only electricity." -msgstr "" - -#: ../source/overview.rst:375 -msgid "" -"Whereas the virtual machines described above are primarily reserved for the " -"tech-savvy, you can find hardware appliances being used by everyone from the " -"most advanced data centers to the youngest children." -msgstr "" - -#: ../source/overview.rst:379 -msgid "" -"Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the " -"datacenter or your users' homes. They plug and play, and you can call it a " -"day." -msgstr "" - -#: ../source/overview.rst:389 -msgid "" -"The simplified gamut of technologies used to package Python applications." -msgstr "" - -#: ../source/overview.rst:392 -msgid "What about..." -msgstr "" - -#: ../source/overview.rst:394 -msgid "" -"The sections above can only summarize so much, and you might be wondering " -"about some of the more conspicuous gaps." -msgstr "" - -#: ../source/overview.rst:398 -msgid "Operating system packages" -msgstr "" - -#: ../source/overview.rst:400 -msgid "" -"As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some " -"operating systems have package managers of their own. If you're very sure of " -"the operating system you're targeting, you can depend directly on a format " -"like `deb `_ (for Debian, " -"Ubuntu, etc.) or `RPM `_ " -"(for Red Hat, Fedora, etc.), and use that built-in package manager to take " -"care of installation, and even deployment. You can even use `FPM `_ to generate both deb " -"and RPMs from the same source." -msgstr "" - -#: ../source/overview.rst:411 -msgid "" -"In most deployment pipelines, the OS package manager is just one piece of " -"the puzzle." -msgstr "" - -#: ../source/overview.rst:417 -msgid "" -"`Virtualenvs `_ have been an indispensable tool for multiple generations of Python " -"developer, but are slowly fading from view, as they are being wrapped by " -"higher-level tools. With packaging in particular, virtualenvs are used as a " -"primitive in `the dh-virtualenv tool `_ and `osnap `_, " -"both of which wrap virtualenvs in a self-contained way." -msgstr "" - -#: ../source/overview.rst:427 -msgid "" -"For production deployments, do not rely on running ``python -m pip install`` " -"from the Internet into a virtualenv, as one might do in a development " -"environment. The overview above is full of much better solutions." -msgstr "" - -#: ../source/overview.rst:432 -msgid "Security" -msgstr "Sekureco" - -#: ../source/overview.rst:434 -msgid "" -"The further down the gradient you come, the harder it gets to update " -"components of your package. Everything is more tightly bound together." -msgstr "" - -#: ../source/overview.rst:437 -msgid "" -"For example, if a kernel security issue emerges, and you're deploying " -"containers, the host system's kernel can be updated without requiring a new " -"build on behalf of the application. If you deploy VM images, you'll need a " -"new build. Whether or not this dynamic makes one option more secure is still " -"a bit of an old debate, going back to the still-unsettled matter of `static " -"versus dynamic linking `_." -msgstr "" - -#: ../source/overview.rst:446 -msgid "Wrap up" -msgstr "" - -#: ../source/overview.rst:448 -msgid "" -"Packaging in Python has a bit of a reputation for being a bumpy ride. This " -"impression is mostly a byproduct of Python's versatility. Once you " -"understand the natural boundaries between each packaging solution, you begin " -"to realize that the varied landscape is a small price Python programmers pay " -"for using one of the most balanced, flexible languages available." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:6 -msgid "Binary distribution format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:8 -msgid "" -"The binary distribution format (:term:`wheel `) was originally " -"defined in :pep:`427`. The current version of the specification is here." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:13 -msgid "Abstract" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:15 -msgid "This PEP describes a built-package format for Python called \"wheel\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:17 -msgid "" -"A wheel is a ZIP-format archive with a specially formatted file name and the " -"``.whl`` extension. It contains a single distribution nearly as it would be " -"installed according to PEP 376 with a particular installation scheme. " -"Although a specialized installer is recommended, a wheel file may be " -"installed by simply unpacking into site-packages with the standard 'unzip' " -"tool while preserving enough information to spread its contents out onto " -"their final paths at any later time." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:27 -msgid "PEP Acceptance" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:29 -msgid "" -"This PEP was accepted, and the defined wheel version updated to 1.0, by Nick " -"Coghlan on 16th February, 2013 [1]_" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:34 -msgid "Rationale" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:36 -msgid "" -"Python needs a package format that is easier to install than sdist. Python's " -"sdist packages are defined by and require the distutils and setuptools build " -"systems, running arbitrary code to build-and-install, and re-compile, code " -"just so it can be installed into a new virtualenv. This system of " -"conflating build-install is slow, hard to maintain, and hinders innovation " -"in both build systems and installers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:43 -msgid "" -"Wheel attempts to remedy these problems by providing a simpler interface " -"between the build system and the installer. The wheel binary package format " -"frees installers from having to know about the build system, saves time by " -"amortizing compile time over many installations, and removes the need to " -"install a build system in the target environment." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:52 -msgid "Details" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:55 -msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:57 -msgid "Wheel installation notionally consists of two phases:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:59 -msgid "Unpack." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:61 -msgid "Parse ``distribution-1.0.dist-info/WHEEL``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:62 -msgid "" -"Check that installer is compatible with Wheel-Version. Warn if minor " -"version is greater, abort if major version is greater." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:64 -msgid "" -"If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:66 -msgid "Else unpack archive into platlib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:68 -msgid "Spread." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:70 -msgid "" -"Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is " -"data) ``distribution-1.0.data/``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:72 -msgid "" -"Move each subtree of ``distribution-1.0.data/`` onto its destination path. " -"Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of " -"destination directories, such as ``distribution-1.0.data/(purelib|platlib|" -"headers|scripts|data)``. The initially supported paths are taken from " -"``distutils.command.install``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:78 -msgid "" -"If applicable, update scripts starting with ``#!python`` to point to the " -"correct interpreter." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:80 -msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:82 -msgid "Remove empty ``distribution-1.0.data`` directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:83 -msgid "" -"Compile any installed .py to .pyc. (Uninstallers should be smart enough to " -"remove .pyc even if it is not mentioned in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:87 -msgid "Recommended installer features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:97 -msgid "Rewrite ``#!python``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:90 -msgid "" -"In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/" -"``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!" -"python'``, rewrite to point to the correct interpreter. Unix installers may " -"need to add the +x bit to these files if the archive was created on Windows." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:96 -msgid "" -"The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI " -"script instead of a console script." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:102 -msgid "Generate script wrappers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:100 -msgid "" -"In wheel, scripts packaged on Unix systems will certainly not have " -"accompanying .exe wrappers. Windows installers may want to add them during " -"install." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:105 -msgid "Recommended archiver features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:112 -msgid "Place ``.dist-info`` at the end of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:108 -msgid "" -"Archivers are encouraged to place the ``.dist-info`` files physically at the " -"end of the archive. This enables some potentially interesting ZIP tricks " -"including the ability to amend the metadata without rewriting the entire " -"archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:115 -msgid "File Format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:118 -msgid "File name convention" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:120 -msgid "" -"The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-" -"{abi tag}-{platform tag}.whl``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "distribution" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "Distribution name, e.g. 'django', 'pyramid'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "Distribution version, e.g. 1.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:135 -msgid "build tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:130 -msgid "" -"Optional build number. Must start with a digit. Acts as a tie-breaker if " -"two wheel file names are the same in all other respects (i.e. name, version, " -"and other tags). Sort as an empty tuple if unspecified, else sort as a two-" -"item tuple with the first item being the initial digits as an ``int``, and " -"the second item being the remainder of the tag as a ``str``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "language implementation and version tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "E.g. 'py27', 'py2', 'py3'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "abi tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "E.g. 'cp33m', 'abi3', 'none'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "platform tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "E.g. 'linux_x86_64', 'any'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:146 -msgid "" -"For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of " -"a package called 'distribution', and is compatible with Python 2.7 (any " -"Python 2.7 implementation), with no ABI (pure Python), on any CPU " -"architecture." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:151 -msgid "" -"The last three components of the filename before the extension are called " -"\"compatibility tags.\" The compatibility tags express the package's basic " -"interpreter requirements and are detailed in PEP 425." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:156 -msgid "Escaping and Unicode" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:158 -msgid "" -"As the components of the filename are separated by a dash (``-``, HYPHEN-" -"MINUS), this character cannot appear within any component. This is handled " -"as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:161 -msgid "" -"In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE " -"and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent " -"to :pep:`503` normalisation followed by replacing ``-`` with ``_``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:164 -msgid "" -"Version numbers should be normalised according to :pep:`440`. Normalised " -"version numbers cannot contain ``-``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:166 -msgid "" -"The remaining components may not contain ``-`` characters, so no escaping is " -"necessary." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:169 -msgid "" -"Tools producing wheels should verify that the filename components do not " -"contain ``-``, as the resulting file may not be processed correctly if they " -"do." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:172 -msgid "" -"The archive filename is Unicode. It will be some time before the tools are " -"updated to support non-ASCII filenames, but they are supported in this " -"specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:176 -msgid "" -"The filenames *inside* the archive are encoded as UTF-8. Although some ZIP " -"clients in common use do not properly display UTF-8 filenames, the encoding " -"is supported by both the ZIP specification and Python's ``zipfile``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:182 -msgid "File contents" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:184 -msgid "" -"The contents of a wheel file, where {distribution} is replaced with the name " -"of the package, e.g. ``beaglevote`` and {version} is replaced with its " -"version, e.g. ``1.0.0``, consist of:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:188 -msgid "" -"``/``, the root of the archive, contains all files to be installed in " -"``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and " -"``platlib`` are usually both ``site-packages``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:191 -msgid "``{distribution}-{version}.dist-info/`` contains metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:192 -msgid "" -"``{distribution}-{version}.data/`` contains one subdirectory for each non-" -"empty install scheme key not already covered, where the subdirectory name is " -"an index into a dictionary of install paths (e.g. ``data``, ``scripts``, " -"``include``, ``purelib``, ``platlib``)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:196 -msgid "" -"Python scripts must appear in ``scripts`` and begin with exactly ``b'#!" -"python'`` in order to enjoy script wrapper generation and ``#!python`` " -"rewriting at install time. They may have any or no extension." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:200 -msgid "" -"``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or " -"greater format metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:202 -msgid "" -"``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive " -"itself in the same basic key: value format::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:212 -msgid "``Wheel-Version`` is the version number of the Wheel specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:213 -msgid "" -"``Generator`` is the name and optionally the version of the software that " -"produced the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:215 -msgid "" -"``Root-Is-Purelib`` is true if the top level directory of the archive should " -"be installed into purelib; otherwise the root should be installed into " -"platlib." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:218 -msgid "" -"``Tag`` is the wheel's expanded compatibility tags; in the example the " -"filename would contain ``py2.py3-none-any``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:220 -msgid "" -"``Build`` is the build number and is omitted if there is no build number." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:221 -msgid "" -"A wheel installer should warn if Wheel-Version is greater than the version " -"it supports, and must fail if Wheel-Version has a greater major version than " -"the version it supports." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:224 -msgid "" -"Wheel, being an installation format that is intended to work across multiple " -"versions of Python, does not generally include .pyc files." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:226 -msgid "Wheel does not contain setup.py or setup.cfg." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:228 -msgid "" -"This version of the wheel specification is based on the distutils install " -"schemes and does not define how to install files to other locations. The " -"layout offers a superset of the functionality provided by the existing " -"wininst and egg binary formats." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:235 -#: ../source/specifications/recording-installed-packages.rst:35 -msgid "The .dist-info directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:237 -msgid "" -"Wheel .dist-info directories include at a minimum METADATA, WHEEL, and " -"RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:239 -msgid "" -"METADATA is the package metadata, the same format as PKG-INFO as found at " -"the root of sdists." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:241 -msgid "WHEEL is the wheel metadata specific to a build of the package." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:242 -msgid "" -"RECORD is a list of (almost) all the files in the wheel and their secure " -"hashes. Unlike PEP 376, every file except RECORD, which cannot contain a " -"hash of itself, must include its hash. The hash algorithm must be sha256 or " -"better; specifically, md5 and sha1 are not permitted, as signed wheel files " -"rely on the strong hashes in RECORD to validate the integrity of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:248 -msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:249 -msgid "" -"RECORD.jws is used for digital signatures. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:251 -msgid "" -"RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME " -"signatures to secure their wheel files. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:254 -msgid "" -"During extraction, wheel installers verify all the hashes in RECORD against " -"the file contents. Apart from RECORD and its signatures, installation will " -"fail if any file in the archive is not both mentioned and correctly hashed " -"in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:261 -msgid "The .data directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:263 -msgid "" -"Any file that is not normally installed inside site-packages goes into the ." -"data directory, named as the .dist-info directory but with the .data/ " -"extension::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:271 -msgid "" -"The .data directory contains subdirectories with the scripts, headers, " -"documentation and so forth from the distribution. During installation the " -"contents of these subdirectories are moved onto their destination paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:277 -msgid "Signed wheel files" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:279 -msgid "" -"Wheel files include an extended RECORD that enables digital signatures. PEP " -"376's RECORD is altered to include a secure hash " -"``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with " -"no trailing = characters) as the second column instead of an md5sum. All " -"possible entries are hashed, including any generated files such as .pyc " -"files, but not RECORD which cannot contain its own hash. For example::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:290 -msgid "" -"The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD " -"at all since they can only be added after RECORD is generated. Every other " -"file in the archive must have a correct hash in RECORD or the installation " -"will fail." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:295 -msgid "" -"If JSON web signatures are used, one or more JSON Web Signature JSON " -"Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to " -"RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD " -"as the signature's JSON payload::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:302 -msgid "(The hash value is the same format used in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:304 -msgid "" -"If RECORD.p7s is used, it must contain a detached S/MIME format signature of " -"RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:307 -msgid "" -"A wheel installer is not required to understand digital signatures but MUST " -"verify the hashes in RECORD against the extracted file contents. When the " -"installer checks file hashes against RECORD, a separate signature checker " -"only needs to establish that RECORD matches the signature." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:312 -msgid "See" -msgstr "Vidu" - -#: ../source/specifications/binary-distribution-format.rst:314 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" -msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" - -#: ../source/specifications/binary-distribution-format.rst:315 -msgid "" -"http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" -msgstr "" -"http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" - -#: ../source/specifications/binary-distribution-format.rst:316 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" -msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" - -#: ../source/specifications/binary-distribution-format.rst:317 -msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" -msgstr "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" - -#: ../source/specifications/binary-distribution-format.rst:321 -msgid "Comparison to .egg" -msgstr "Komparo al .egg" - -#: ../source/specifications/binary-distribution-format.rst:323 -msgid "" -"Wheel is an installation format; egg is importable. Wheel archives do not " -"need to include .pyc and are less tied to a specific Python version or " -"implementation. Wheel can install (pure Python) packages built with previous " -"versions of Python so you don't always have to wait for the packager to " -"catch up." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:328 -msgid "" -"Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible " -"with the new world of Python packaging and the new concepts it brings." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:331 -msgid "" -"Wheel has a richer file naming convention for today's multi-implementation " -"world. A single wheel archive can indicate its compatibility with a number " -"of Python language versions and implementations, ABIs, and system " -"architectures. Historically the ABI has been specific to a CPython release, " -"wheel is ready for the stable ABI." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:337 -msgid "" -"Wheel is lossless. The first wheel implementation bdist_wheel always " -"generates egg-info, and then converts it to a .whl. It is also possible to " -"convert existing eggs and bdist_wininst distributions." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:341 -msgid "" -"Wheel is versioned. Every wheel file contains the version of the wheel " -"specification and the implementation that packaged it. Hopefully the next " -"migration can simply be to Wheel 2.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:344 -msgid "Wheel is a reference to the other Python." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:348 -msgid "FAQ" -msgstr "Oftaj demandoj" - -#: ../source/specifications/binary-distribution-format.rst:352 -msgid "Wheel defines a .data directory. Should I put all my data there?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:354 -msgid "" -"This specification does not have an opinion on how you should organize your " -"code. The .data directory is just a place for any files that are not " -"normally installed inside ``site-packages`` or on the PYTHONPATH. In other " -"words, you may continue to use ``pkgutil.get_data(package, resource)`` even " -"though *those* files will usually not be distributed in *wheel's* ``.data`` " -"directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:363 -msgid "Why does wheel include attached signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:365 -msgid "" -"Attached signatures are more convenient than detached signatures because " -"they travel with the archive. Since only the individual files are signed, " -"the archive can be recompressed without invalidating the signature or " -"individual files can be verified without having to download the whole " -"archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:373 -msgid "Why does wheel allow JWS signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:375 -msgid "" -"The JOSE specifications of which JWS is a part are designed to be easy to " -"implement, a feature that is also one of wheel's primary design goals. JWS " -"yields a useful, concise pure-Python implementation." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:381 -msgid "Why does wheel also allow S/MIME signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:383 -msgid "" -"S/MIME signatures are allowed for users who need or want to use existing " -"public key infrastructure with wheel." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:386 -msgid "" -"Signed packages are only a basic building block in a secure package update " -"system. Wheel only provides the building block." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:391 -msgid "What's the deal with \"purelib\" vs. \"platlib\"?" -msgstr "Kio temas pri «purelib» kontraste kun «platlib»?" - -#: ../source/specifications/binary-distribution-format.rst:393 -msgid "" -"Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is " -"significant on some platforms. For example, Fedora installs pure Python " -"packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent " -"packages to '/usr/lib64/pythonX.Y/site-packages'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:398 -msgid "" -"A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-" -"{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: " -"true\" with those same files in the root, and it is legal to have files in " -"both the \"purelib\" and \"platlib\" categories." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:403 -msgid "" -"In practice a wheel should have only one of \"purelib\" or \"platlib\" " -"depending on whether it is pure Python or not and those files should be at " -"the root with the appropriate setting given for \"Root-is-purelib\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:409 -msgid "Is it possible to import Python code directly from a wheel file?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:411 -msgid "" -"Technically, due to the combination of supporting installation via simple " -"extraction and using an archive format that is compatible with " -"``zipimport``, a subset of wheel files *do* support being placed directly on " -"``sys.path``. However, while this behaviour is a natural consequence of the " -"format design, actually relying on it is generally discouraged." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:417 -msgid "" -"Firstly, wheel *is* designed primarily as a distribution format, so skipping " -"the installation step also means deliberately avoiding any reliance on " -"features that assume full installation (such as being able to use standard " -"tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in " -"a way that can be properly tracked for auditing and security update " -"purposes, or integrating fully with the standard build machinery for C " -"extensions by publishing header files in the appropriate place)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:426 -msgid "" -"Secondly, while some Python software is written to support running directly " -"from a zip archive, it is still common for code to be written assuming it " -"has been fully installed. When that assumption is broken by trying to run " -"the software from a zip archive, the failures can often be obscure and hard " -"to diagnose (especially when they occur in third party libraries). The two " -"most common sources of problems with this are the fact that importing C " -"extensions from a zip archive is *not* supported by CPython (since doing so " -"is not supported directly by the dynamic loading machinery on any platform) " -"and that when running from a zip archive the ``__file__`` attribute no " -"longer refers to an ordinary filesystem path, but to a combination path that " -"includes both the location of the zip archive on the filesystem and the " -"relative path to the module inside the archive. Even when software correctly " -"uses the abstract resource APIs internally, interfacing with external " -"components may still require the availability of an actual on-disk file." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:443 -msgid "" -"Like metaclasses, monkeypatching and metapath importers, if you're not " -"already sure you need to take advantage of this feature, you almost " -"certainly don't need it. If you *do* decide to use it anyway, be aware that " -"many projects will require a failure to be reproduced with a fully installed " -"package before accepting it as a genuine bug." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:450 -msgid "Changes" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:452 -msgid "Since :pep:`427`, this specification has changed as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:454 -msgid "" -"The rules on escaping in wheel filenames were revised, to bring them into " -"line with what popular tools actually do (February 2021)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:461 -msgid "" -"PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-" -"February/124103.html)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:466 -msgid "Appendix" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:468 -msgid "Example urlsafe-base64-nopad implementation::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:482 -msgid "Copyright" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:484 -msgid "This document has been placed into the public domain." -msgstr "" - -#: ../source/specifications/core-metadata.rst:5 -msgid "Core metadata specifications" -msgstr "" - -#: ../source/specifications/core-metadata.rst:7 -msgid "" -"Fields defined in the following specification should be considered valid, " -"complete and not subject to change. The required fields are:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:10 -msgid "``Metadata-Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:11 -msgid "``Name``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:12 -msgid "``Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:14 -msgid "All the other fields are optional." -msgstr "" - -#: ../source/specifications/core-metadata.rst:16 -msgid "" -"The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats " -"have been revised several times, and exactly which email RFC applies to " -"packaging metadata is not specified. In the absence of a precise definition, " -"the practical standard is set by what the standard library :mod:`python:" -"email.parser` module can parse using the :data:`~.python:email.policy." -"compat32` policy." -msgstr "" - -#: ../source/specifications/core-metadata.rst:25 -msgid "" -"Although :pep:`566` defined a way to transform metadata into a JSON-" -"compatible dictionary, this is not yet used as a standard interchange " -"format. The need for tools to work with years worth of existing packages " -"makes it difficult to shift to a new format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:30 -msgid "" -"*Interpreting old metadata:* In :pep:`566`, the version specifier field " -"format specification was relaxed to accept the syntax used by popular " -"publishing tools (namely to remove the requirement that version specifiers " -"must be surrounded by parentheses). Metadata consumers may want to use the " -"more relaxed formatting rules even for metadata files that are nominally " -"less than version 2.1." -msgstr "" - -#: ../source/specifications/core-metadata.rst:41 -msgid "Metadata-Version" -msgstr "" - -#: ../source/specifications/core-metadata.rst:45 -msgid "" -"Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", " -"\"2.1\" and \"2.2\"." -msgstr "" - -#: ../source/specifications/core-metadata.rst:48 -msgid "" -"Automated tools consuming metadata SHOULD warn if ``metadata_version`` is " -"greater than the highest version they support, and MUST fail if " -"``metadata_version`` has a greater major version than the highest version " -"they support (as described in :pep:`440`, the major version is the value " -"before the first dot)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:54 -msgid "" -"For broader compatibility, build tools MAY choose to produce distribution " -"metadata using the lowest metadata version that includes all of the needed " -"fields." -msgstr "" - -#: ../source/specifications/core-metadata.rst:58 -#: ../source/specifications/core-metadata.rst:80 -#: ../source/specifications/core-metadata.rst:95 -#: ../source/specifications/core-metadata.rst:155 -#: ../source/specifications/core-metadata.rst:170 -#: ../source/specifications/core-metadata.rst:208 -#: ../source/specifications/core-metadata.rst:283 -#: ../source/specifications/core-metadata.rst:287 -#: ../source/specifications/core-metadata.rst:291 -#: ../source/specifications/core-metadata.rst:295 -#: ../source/specifications/core-metadata.rst:327 -#: ../source/specifications/core-metadata.rst:347 -#: ../source/specifications/core-metadata.rst:373 -#: ../source/specifications/core-metadata.rst:391 -#: ../source/specifications/core-metadata.rst:416 -#: ../source/specifications/core-metadata.rst:438 -#: ../source/specifications/core-metadata.rst:600 -#: ../source/specifications/core-metadata.rst:620 -#: ../source/specifications/core-metadata.rst:630 -msgid "Example::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:66 -msgid "Name" -msgstr "Nomo" - -#: ../source/specifications/core-metadata.rst:69 -msgid "Added additional restrictions on format from :pep:`508`" -msgstr "" - -#: ../source/specifications/core-metadata.rst:72 -msgid "" -"The name of the distribution. The name field is the primary identifier for a " -"distribution. A valid name consists only of ASCII letters and numbers, " -"period, underscore and hyphen. It must start and end with a letter or " -"number. Distribution names are limited to those which match the following " -"regex (run with ``re.IGNORECASE``)::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:88 -msgid "Version" -msgstr "Versio" - -#: ../source/specifications/core-metadata.rst:92 -msgid "" -"A string containing the distribution's version number. This field must be " -"in the format specified in :pep:`440`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:101 -msgid "Dynamic (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:105 -msgid "" -"A string containing the name of another core metadata field. The field names " -"``Name`` and ``Version`` may not be specified in this field." -msgstr "" - -#: ../source/specifications/core-metadata.rst:108 -msgid "" -"When found in the metadata of a source distribution, the following rules " -"apply:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:111 -msgid "" -"If a field is *not* marked as ``Dynamic``, then the value of the field in " -"any wheel built from the sdist MUST match the value in the sdist. If the " -"field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT " -"be present in the wheel." -msgstr "" - -#: ../source/specifications/core-metadata.rst:115 -msgid "" -"If a field is marked as ``Dynamic``, it may contain any valid value in a " -"wheel built from the sdist (including not being present at all)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:118 -msgid "" -"If the sdist metadata version is older than version 2.2, then all fields " -"should be treated as if they were specified with ``Dynamic`` (i.e. there are " -"no special restrictions on the metadata of wheels built from the sdist)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:122 -msgid "" -"In any context other than a source distribution, ``Dynamic`` is for " -"information only, and indicates that the field value was calculated at wheel " -"build time, and may not be the same as the value in the sdist or in other " -"wheels for the project." -msgstr "" - -#: ../source/specifications/core-metadata.rst:127 -msgid "" -"Full details of the semantics of ``Dynamic`` are described in :pep:`643`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:131 -msgid "Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:135 -msgid "" -"A Platform specification describing an operating system supported by the " -"distribution which is not listed in the \"Operating System\" Trove " -"classifiers. See \"Classifier\" below." -msgstr "" - -#: ../source/specifications/core-metadata.rst:146 -msgid "Supported-Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:150 -msgid "" -"Binary distributions containing a PKG-INFO file will use the Supported-" -"Platform field in their metadata to specify the OS and CPU for which the " -"binary distribution was compiled. The semantics of the Supported-Platform " -"field are not specified in this PEP." -msgstr "" - -#: ../source/specifications/core-metadata.rst:164 -msgid "Summary" -msgstr "" - -#: ../source/specifications/core-metadata.rst:168 -msgid "A one-line summary of what the distribution does." -msgstr "" - -#: ../source/specifications/core-metadata.rst:188 -msgid "This field may be specified in the message body instead." -msgstr "" - -#: ../source/specifications/core-metadata.rst:191 -msgid "" -"A longer description of the distribution that can run to several " -"paragraphs. Software that deals with metadata should not assume any maximum " -"size for this field, though people shouldn't include their instruction " -"manual as the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:196 -msgid "" -"The contents of this field can be written using reStructuredText markup " -"[1]_. For programs that work with the metadata, supporting markup is " -"optional; programs can also display the contents of the field as-is. This " -"means that authors should be conservative in the markup they use." -msgstr "" - -#: ../source/specifications/core-metadata.rst:202 -msgid "" -"To support empty lines and lines with indentation with respect to the RFC " -"822 format, any CRLF character has to be suffixed by 7 spaces followed by a " -"pipe (\"|\") char. As a result, the Description field is encoded into a " -"folded field that can be interpreted by RFC822 parser [2]_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:219 -msgid "" -"This encoding implies that any occurrences of a CRLF followed by 7 spaces " -"and a pipe char have to be replaced by a single CRLF when the field is " -"unfolded using a RFC822 reader." -msgstr "" - -#: ../source/specifications/core-metadata.rst:223 -msgid "" -"Alternatively, the distribution's description may instead be provided in the " -"message body (i.e., after a completely blank line following the headers, " -"with no indentation or other special formatting necessary)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:232 -msgid "Description-Content-Type" -msgstr "" - -#: ../source/specifications/core-metadata.rst:236 -msgid "" -"A string stating the markup syntax (if any) used in the distribution's " -"description, so that tools can intelligently render the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:239 -msgid "" -"Historically, PyPI supported descriptions in plain text and " -"`reStructuredText (reST) `_, and could render reST into HTML. However, it is " -"common for distribution authors to write the description in `Markdown " -"`_ (`RFC 7763 `_) as many code hosting sites render Markdown " -"READMEs, and authors would reuse the file for the description. PyPI didn't " -"recognize the format and so could not render the description correctly. This " -"resulted in many packages on PyPI with poorly-rendered descriptions when " -"Markdown is left as plain text, or worse, was attempted to be rendered as " -"reST. This field allows the distribution author to specify the format of " -"their description, opening up the possibility for PyPI and other tools to be " -"able to render Markdown and other formats." -msgstr "" - -#: ../source/specifications/core-metadata.rst:253 -msgid "" -"The format of this field is the same as the ``Content-Type`` header in HTTP " -"(i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then " -"it can optionally have a number of parameters:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:259 -msgid "Format::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:263 -msgid "The ``type/subtype`` part has only a few legal values:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:265 -msgid "``text/plain``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:266 -msgid "``text/x-rst``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:267 -msgid "``text/markdown``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:269 -msgid "" -"The ``charset`` parameter can be used to specify the character encoding of " -"the description. The only legal value is ``UTF-8``. If omitted, it is " -"assumed to be ``UTF-8``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:273 -msgid "" -"Other parameters might be specific to the chosen subtype. For example, for " -"the ``markdown`` subtype, there is an optional ``variant`` parameter that " -"allows specifying the variant of Markdown in use (defaults to ``GFM`` if not " -"specified). Currently, two variants are recognized:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:278 -msgid "" -"``GFM`` for `Github-flavored Markdown `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:280 -msgid "" -"``CommonMark`` for `CommonMark `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:299 -msgid "" -"If a ``Description-Content-Type`` is not specified, then applications should " -"attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to " -"``text/plain`` if it is not valid rst." -msgstr "" - -#: ../source/specifications/core-metadata.rst:303 -msgid "" -"If a ``Description-Content-Type`` is an unrecognized value, then the assumed " -"content type is ``text/plain`` (Although PyPI will probably reject anything " -"with an unrecognized value)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:307 -msgid "" -"If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is " -"not specified or is set to an unrecognized value, then the assumed " -"``variant`` is ``GFM``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:311 -msgid "" -"So for the last example above, the ``charset`` defaults to ``UTF-8`` and the " -"``variant`` defaults to ``GFM`` and thus it is equivalent to the example " -"before it." -msgstr "" - -#: ../source/specifications/core-metadata.rst:320 -msgid "Keywords" -msgstr "" - -#: ../source/specifications/core-metadata.rst:324 -msgid "" -"A list of additional keywords, separated by commas, to be used to assist " -"searching for the distribution in a larger catalog." -msgstr "" - -#: ../source/specifications/core-metadata.rst:333 -msgid "" -"The specification previously showed keywords separated by spaces, but " -"distutils and setuptools implemented it with commas. These tools have been " -"very widely used for many years, so it was easier to update the " -"specification to match the de facto standard." -msgstr "" - -#: ../source/specifications/core-metadata.rst:341 -msgid "Home-page" -msgstr "" - -#: ../source/specifications/core-metadata.rst:345 -msgid "A string containing the URL for the distribution's home page." -msgstr "" - -#: ../source/specifications/core-metadata.rst:353 -msgid "Download-URL" -msgstr "" - -#: ../source/specifications/core-metadata.rst:357 -msgid "" -"A string containing the URL from which this version of the distribution can " -"be downloaded. (This means that the URL can't be something like \".../" -"BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:366 -msgid "Author" -msgstr "" - -#: ../source/specifications/core-metadata.rst:370 -msgid "" -"A string containing the author's name at a minimum; additional contact " -"information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:383 -msgid "Author-email" -msgstr "" - -#: ../source/specifications/core-metadata.rst:387 -msgid "" -"A string containing the author's e-mail address. It can contain a name and " -"e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:395 -#: ../source/specifications/core-metadata.rst:442 -msgid "" -"Per RFC-822, this field may contain multiple comma-separated e-mail " -"addresses::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:405 -msgid "Maintainer" -msgstr "Prizorganto" - -#: ../source/specifications/core-metadata.rst:409 -msgid "" -"A string containing the maintainer's name at a minimum; additional contact " -"information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:412 -msgid "" -"Note that this field is intended for use when a project is being maintained " -"by someone other than the original author: it should be omitted if it is " -"identical to ``Author``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:426 -msgid "Maintainer-email" -msgstr "" - -#: ../source/specifications/core-metadata.rst:430 -msgid "" -"A string containing the maintainer's e-mail address. It can contain a name " -"and e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:434 -msgid "" -"Note that this field is intended for use when a project is being maintained " -"by someone other than the original author: it should be omitted if it is " -"identical to ``Author-email``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:452 -msgid "License" -msgstr "" - -#: ../source/specifications/core-metadata.rst:456 -msgid "" -"Text indicating the license covering the distribution where the license is " -"not a selection from the \"License\" Trove classifiers. See :ref:`" -"\"Classifier\" ` below. This field may also be used to " -"specify a particular version of a license which is named via the " -"``Classifier`` field, or to indicate a variation or exception to such a " -"license." -msgstr "" - -#: ../source/specifications/core-metadata.rst:476 -msgid "Classifier (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:480 -msgid "" -"Each entry is a string giving a single classification value for the " -"distribution. Classifiers are described in :pep:`301`, and the Python " -"Package Index publishes a dynamic list of `currently defined classifiers " -"`__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:485 -#: ../source/specifications/core-metadata.rst:574 -#: ../source/specifications/core-metadata.rst:691 -#: ../source/specifications/core-metadata.rst:715 -msgid "This field may be followed by an environment marker after a semicolon." -msgstr "" - -#: ../source/specifications/core-metadata.rst:496 -msgid "Requires-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:499 -#: ../source/specifications/core-metadata.rst:561 -#: ../source/specifications/core-metadata.rst:663 -#: ../source/specifications/core-metadata.rst:704 -msgid "" -"The field format specification was relaxed to accept the syntax used by " -"popular publishing tools." -msgstr "" - -#: ../source/specifications/core-metadata.rst:503 -msgid "" -"Each entry contains a string naming some other distutils project required by " -"this distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:506 -msgid "The format of a requirement string contains from one to four parts:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:508 -msgid "" -"A project name, in the same format as the ``Name:`` field. The only " -"mandatory part." -msgstr "" - -#: ../source/specifications/core-metadata.rst:510 -msgid "" -"A comma-separated list of 'extra' names. These are defined by the required " -"project, referring to specific features which may need extra dependencies." -msgstr "" - -#: ../source/specifications/core-metadata.rst:513 -msgid "" -"A version specifier. Tools parsing the format should accept optional " -"parentheses around this, but tools generating it should not use parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:516 -msgid "" -"An environment marker after a semicolon. This means that the requirement is " -"only needed in the specified conditions." -msgstr "" - -#: ../source/specifications/core-metadata.rst:519 -msgid "See :pep:`508` for full details of the allowed format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:521 -msgid "" -"The project names should correspond to names as found on the `Python Package " -"Index`_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:524 -msgid "" -"Version specifiers must follow the rules described in :doc:`version-" -"specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:538 -msgid "Requires-Python" -msgstr "" - -#: ../source/specifications/core-metadata.rst:542 -msgid "" -"This field specifies the Python version(s) that the distribution is " -"guaranteed to be compatible with. Installation tools may look at this when " -"picking which version of a project to install." -msgstr "" - -#: ../source/specifications/core-metadata.rst:546 -msgid "The value must be in the format specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:548 -msgid "This field cannot be followed by an environment marker." -msgstr "" - -#: ../source/specifications/core-metadata.rst:558 -msgid "Requires-External (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:565 -msgid "" -"Each entry contains a string describing some dependency in the system that " -"the distribution is to be used. This field is intended to serve as a hint " -"to downstream project maintainers, and has no semantics which are meaningful " -"to the ``distutils`` distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:570 -msgid "" -"The format of a requirement string is a name of an external dependency, " -"optionally followed by a version declaration within parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:576 -msgid "" -"Because they refer to non-Python software releases, version numbers for this " -"field are **not** required to conform to the format specified in :pep:" -"`440`: they should correspond to the version scheme used by the external " -"dependency." -msgstr "" - -#: ../source/specifications/core-metadata.rst:581 -msgid "Notice that there is no particular rule on the strings to be used." -msgstr "" - -#: ../source/specifications/core-metadata.rst:593 -msgid "Project-URL (multiple-use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:597 -msgid "" -"A string containing a browsable URL for the project and a label for it, " -"separated by a comma." -msgstr "" - -#: ../source/specifications/core-metadata.rst:604 -msgid "The label is free text limited to 32 characters." -msgstr "" - -#: ../source/specifications/core-metadata.rst:612 -msgid "Provides-Extra (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:616 -msgid "" -"A string containing the name of an optional feature. Must be a valid Python " -"identifier. May be used to make a dependency conditional on whether the " -"optional feature has been requested." -msgstr "" - -#: ../source/specifications/core-metadata.rst:625 -msgid "" -"A second distribution requires an optional dependency by placing it inside " -"square brackets, and can request multiple features by separating them with a " -"comma (,). The requirements are evaluated for each requested feature and " -"added to the set of requirements for the distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:635 -msgid "" -"Two feature names ``test`` and ``doc`` are reserved to mark dependencies " -"that are needed for running automated tests and generating documentation, " -"respectively." -msgstr "" - -#: ../source/specifications/core-metadata.rst:639 -msgid "" -"It is legal to specify ``Provides-Extra:`` without referencing it in any " -"``Requires-Dist:``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:644 -msgid "Rarely Used Fields" -msgstr "Malofte uzataj kampoj" - -#: ../source/specifications/core-metadata.rst:646 -msgid "" -"The fields in this section are currently rarely used, as their design was " -"inspired by comparable mechanisms in Linux package management systems, and " -"it isn't at all clear how tools should interpret them in the context of an " -"open index server such as `PyPI `__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:651 -msgid "" -"As a result, popular installation tools ignore them completely, which in " -"turn means there is little incentive for package publishers to set them " -"appropriately. However, they're retained in the metadata specification, as " -"they're still potentially useful for informational purposes, and can also be " -"used for their originally intended purpose in combination with a curated " -"package repository." -msgstr "" - -#: ../source/specifications/core-metadata.rst:660 -msgid "Provides-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:667 -msgid "" -"Each entry contains a string naming a Distutils project which is contained " -"within this distribution. This field *must* include the project identified " -"in the ``Name`` field, followed by the version : Name (Version)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:672 -msgid "" -"A distribution may provide additional names, e.g. to indicate that multiple " -"projects have been bundled together. For instance, source distributions of " -"the ``ZODB`` project have historically included the ``transaction`` project, " -"which is now available as a separate distribution. Installing such a source " -"distribution satisfies requirements for both ``ZODB`` and ``transaction``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:679 -msgid "" -"A distribution may also provide a \"virtual\" project name, which does not " -"correspond to any separately-distributed project: such a name might be used " -"to indicate an abstract capability which could be supplied by one of " -"multiple projects. E.g., multiple projects might supply RDBMS bindings for " -"use by a given ORM: each project might declare that it provides ``ORM-" -"bindings``, allowing other projects to depend only on having at most one of " -"them installed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:687 -msgid "" -"A version declaration may be supplied and must follow the rules described " -"in :doc:`version-specifiers`. The distribution's version number will be " -"implied if none is specified." -msgstr "" - -#: ../source/specifications/core-metadata.rst:701 -msgid "Obsoletes-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:708 -msgid "" -"Each entry contains a string describing a distutils project's distribution " -"which this distribution renders obsolete, meaning that the two projects " -"should not be installed at the same time." -msgstr "" - -#: ../source/specifications/core-metadata.rst:712 -msgid "" -"Version declarations can be supplied. Version numbers must be in the format " -"specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:717 -msgid "" -"The most common use of this field will be in case a project name changes, e." -"g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install " -"Torqued Python, the Gorgon distribution should be removed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:730 -msgid "reStructuredText markup: http://docutils.sourceforge.net/" -msgstr "Marklingvo reStructuredText: http://docutils.sourceforge.net/" - -#: ../source/specifications/core-metadata.rst:735 -msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:6 -msgid "Declaring build system dependencies" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:8 -msgid "" -"`pyproject.toml` is a build system independent file format defined in :pep:" -"`518` that projects may provide in order to declare any Python level " -"dependencies that must be installed in order to run the project's build " -"system successfully." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:5 -msgid "Declaring project metadata" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:7 -msgid "" -":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to " -"consume. It defines the following specification as the canonical source for " -"the format used." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:12 -msgid "" -"There are two kinds of metadata: *static* and *dynamic*. Static metadata is " -"specified in the ``pyproject.toml`` file directly and cannot be specified or " -"changed by a tool. Dynamic metadata is listed via the ``dynamic`` field " -"(defined later in this specification) and represents metadata that a tool " -"will later provide." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:18 -msgid "" -"The fields defined in this specification MUST be in a table named " -"``[project]`` in ``pyproject.toml``. No tools may add fields to this table " -"which are not defined by this specification. For tools wishing to store " -"their own settings in ``pyproject.toml``, they may use the ``[tool]`` table " -"as defined in the :ref:`build dependency declaration specification " -"`. The lack of a ``[project]`` table " -"implicitly means the build back-end will dynamically provide all fields." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:27 -msgid "The only fields required to be statically defined are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:29 -#: ../source/specifications/declaring-project-metadata.rst:41 -msgid "``name``" -msgstr "``name``" - -#: ../source/specifications/declaring-project-metadata.rst:31 -msgid "" -"The fields which are required but may be specified *either* statically or " -"listed as dynamic are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:34 -#: ../source/specifications/declaring-project-metadata.rst:54 -msgid "``version``" -msgstr "``version``" - -#: ../source/specifications/declaring-project-metadata.rst:36 -msgid "" -"All other fields are considered optional and my be specified statically, " -"listed as dynamic, or left unspecified." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:43 -#: ../source/specifications/declaring-project-metadata.rst:56 -#: ../source/specifications/declaring-project-metadata.rst:68 -#: ../source/specifications/declaring-project-metadata.rst:117 -msgid "TOML_ type: string" -msgstr "Tipo de TOML_: signoĉeno" - -#: ../source/specifications/declaring-project-metadata.rst:44 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Name `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:47 -msgid "The name of the project." -msgstr "La nomo de la projekto." - -#: ../source/specifications/declaring-project-metadata.rst:49 -msgid "" -"Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it " -"is read for internal consistency." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:57 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Version " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:60 -msgid "The version of the project as supported by :pep:`440`." -msgstr "La versio de la projekto laŭ :pep:`440`." - -#: ../source/specifications/declaring-project-metadata.rst:62 -msgid "Users SHOULD prefer to specify already-normalized versions." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:66 -msgid "``description``" -msgstr "``description``" - -#: ../source/specifications/declaring-project-metadata.rst:69 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Summary " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:72 -msgid "The summary description of the project." -msgstr "La resuma priskribo de la projekto." - -#: ../source/specifications/declaring-project-metadata.rst:76 -msgid "``readme``" -msgstr "``readme``" - -#: ../source/specifications/declaring-project-metadata.rst:78 -msgid "TOML_ type: string or table" -msgstr "Tipo de TOML_: signoĉeno aŭ tabelo" - -#: ../source/specifications/declaring-project-metadata.rst:79 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Description " -"` and :ref:`Description-Content-Type `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:83 -msgid "The full description of the project (i.e. the README)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:85 -msgid "" -"The field accepts either a string or a table. If it is a string then it is a " -"path relative to ``pyproject.toml`` to a text file containing the full " -"description. Tools MUST assume the file's encoding is UTF-8. If the file " -"path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the " -"content-type is ``text/markdown``. If the file path ends in a case-" -"insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-" -"rst``. If a tool recognizes more extensions than this PEP, they MAY infer " -"the content-type for the user without specifying this field as ``dynamic``. " -"For all unrecognized suffixes when a content-type is not provided, tools " -"MUST raise an error." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:96 -msgid "" -"The ``readme`` field may also take a table. The ``file`` key has a string " -"value representing a path relative to ``pyproject.toml`` to a file " -"containing the full description. The ``text`` key has a string value which " -"is the full description. These keys are mutually-exclusive, thus tools MUST " -"raise an error if the metadata specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:103 -msgid "" -"A table specified in the ``readme`` field also has a ``content-type`` field " -"which takes a string specifying the content-type of the full description. A " -"tool MUST raise an error if the metadata does not specify this field in the " -"table. If the metadata does not specify the ``charset`` parameter, then it " -"is assumed to be UTF-8. Tools MAY support other encodings if they choose to. " -"Tools MAY support alternative content-types which they can transform to a " -"content-type as supported by the :ref:`core metadata `. " -"Otherwise tools MUST raise an error for unsupported content-types." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:115 -msgid "``requires-python``" -msgstr "``requires-python``" - -#: ../source/specifications/declaring-project-metadata.rst:118 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Requires-" -"Python `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:121 -msgid "The Python version requirements of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:125 -msgid "``license``" -msgstr "``license``" - -#: ../source/specifications/declaring-project-metadata.rst:127 -msgid "TOML_ type: table" -msgstr "Tipo de TOML_: tabelo" - -#: ../source/specifications/declaring-project-metadata.rst:128 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`License " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:131 -msgid "" -"The table may have one of two keys. The ``file`` key has a string value that " -"is a file path relative to ``pyproject.toml`` to the file which contains the " -"license for the project. Tools MUST assume the file's encoding is UTF-8. The " -"``text`` key has a string value which is the license of the project. These " -"keys are mutually exclusive, so a tool MUST raise an error if the metadata " -"specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:140 -msgid "``authors``/``maintainers``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:142 -msgid "TOML_ type: Array of inline tables with string keys and values" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:143 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:" -"`Maintainer `, and :ref:`Maintainer-email `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:149 -msgid "" -"The people or organizations considered to be the \"authors\" of the project. " -"The exact meaning is open to interpretation — it may list the original or " -"primary authors, current maintainers, or owners of the package." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:154 -msgid "" -"The \"maintainers\" field is similar to \"authors\" in that its exact " -"meaning is open to interpretation." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:157 -msgid "" -"These fields accept an array of tables with 2 keys: ``name`` and ``email``. " -"Both values must be strings. The ``name`` value MUST be a valid email name " -"(i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not " -"contain commas. The ``email`` value MUST be a valid email address. Both keys " -"are optional." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:163 -msgid "" -"Using the data to fill in :ref:`core metadata ` is as follows:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:166 -msgid "" -"If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:169 -msgid "" -"If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:173 -msgid "" -"If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-" -"email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:177 -msgid "Multiple values should be separated by commas." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:181 -msgid "``keywords``" -msgstr "``keywords``" - -#: ../source/specifications/declaring-project-metadata.rst:183 -#: ../source/specifications/declaring-project-metadata.rst:193 -msgid "TOML_ type: array of strings" -msgstr "Tipo de TOML_: listo de signoĉenoj" - -#: ../source/specifications/declaring-project-metadata.rst:184 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Keywords " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:187 -msgid "The keywords for the project." -msgstr "La ŝlosilvortoj pri la projekto." - -#: ../source/specifications/declaring-project-metadata.rst:191 -msgid "``classifiers``" -msgstr "``classifiers``" - -#: ../source/specifications/declaring-project-metadata.rst:194 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Classifier " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:197 -msgid "Trove classifiers which apply to the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:201 -msgid "``urls``" -msgstr "``urls``" - -#: ../source/specifications/declaring-project-metadata.rst:203 -msgid "TOML_ type: table with keys and values of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:204 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Project-URL " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:207 -msgid "" -"A table of URLs where the key is the URL label and the value is the URL " -"itself." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:212 -msgid "Entry points" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:214 -msgid "" -"TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and " -"``[project.entry-points]``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:216 -msgid ":ref:`Entry points specification `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:218 -msgid "" -"There are three tables related to entry points. The ``[project.scripts]`` " -"table corresponds to the ``console_scripts`` group in the :ref:`entry points " -"specification `. The key of the table is the name of the entry " -"point and the value is the object reference." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:224 -msgid "" -"The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group " -"in the :ref:`entry points specification `. Its format is the " -"same as ``[project.scripts]``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:228 -msgid "" -"The ``[project.entry-points]`` table is a collection of tables. Each sub-" -"table's name is an entry point group. The key and value semantics are the " -"same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but " -"instead keep the entry point groups to only one level deep." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:234 -msgid "" -"Build back-ends MUST raise an error if the metadata defines a ``[project." -"entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` " -"table, as they would be ambiguous in the face of ``[project.scripts]`` and " -"``[project.gui-scripts]``, respectively." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:242 -msgid "``dependencies``/``optional-dependencies``" -msgstr "``dependencies``/``optional-dependencies``" - -#: ../source/specifications/declaring-project-metadata.rst:244 -msgid "" -"TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with " -"values of arrays of :pep:`508` strings (``optional-dependencies``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:247 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Requires-" -"Dist ` and :ref:`Provides-Extra `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:251 -msgid "The (optional) dependencies of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:253 -msgid "" -"For ``dependencies``, it is a key whose value is an array of strings. Each " -"string represents a dependency of the project and MUST be formatted as a " -"valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist " -"` entry." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:258 -msgid "" -"For ``optional-dependencies``, it is a table where each key specifies an " -"extra and whose value is an array of strings. The strings of the arrays must " -"be valid :pep:`508` strings. The keys MUST be valid values for :ref:" -"`Provides-Extra `. Each value in the array " -"thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:269 -msgid "``dynamic``" -msgstr "``dynamic``" - -#: ../source/specifications/declaring-project-metadata.rst:271 -msgid "TOML_ type: array of string" -msgstr "Tipo de TOML_: listo de signoĉenoj" - -#: ../source/specifications/declaring-project-metadata.rst:272 -msgid "" -"A corresponding :ref:`core metadata ` field does not exist" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:275 -msgid "" -"Specifies which fields listed by this PEP were intentionally unspecified so " -"another tool can/will provide such metadata dynamically. This clearly " -"delineates which metadata is purposefully unspecified and expected to stay " -"unspecified compared to being provided via tooling later on." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:281 -msgid "" -"A build back-end MUST honour statically-specified metadata (which means the " -"metadata did not list the field in ``dynamic``)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:283 -msgid "" -"A build back-end MUST raise an error if the metadata specifies ``name`` in " -"``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:285 -msgid "" -"If the :ref:`core metadata ` specification lists a field as " -"\"Required\", then the metadata MUST specify the field statically or list it " -"in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it " -"should not be possible for a required field to not be listed somehow in the " -"``[project]`` table)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:290 -msgid "" -"If the :ref:`core metadata ` specification lists a field as " -"\"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is " -"a build back-end will provide the data for the field later." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:294 -msgid "" -"Build back-ends MUST raise an error if the metadata specifies a field " -"statically as well as being listed in ``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:296 -msgid "" -"If the metadata does not list a field in ``dynamic``, then a build back-end " -"CANNOT fill in the requisite metadata on behalf of the user (i.e. " -"``dynamic`` is the only way to allow a tool to fill in metadata and the user " -"must opt into the filling in)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:300 -msgid "" -"Build back-ends MUST raise an error if the metadata specifies a field in " -"``dynamic`` but the build back-end was unable to determine the data for it " -"(omitting the data, if determined to be the accurate value, is acceptable)." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:6 -msgid "Dependency specifiers" -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:8 -msgid "" -"The dependency specifier format used to declare a dependency on another " -"component is defined in :pep:`508`." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:11 -msgid "" -"The environment markers section in this PEP supersedes the environment " -"markers section in :pep:`345`." -msgstr "" - -#: ../source/specifications/direct-url.rst:6 -msgid "Recording the Direct URL Origin of installed distributions" -msgstr "" - -#: ../source/specifications/direct-url.rst:8 -msgid "" -"This document specifies a :file:`direct_url.json` file in the :file:`*.dist-" -"info` directory of an installed distribution, to record the Direct URL " -"Origin of the distribution. The layout of this file was originally specified " -"in :pep:`610` and is formally documented here." -msgstr "" - -#: ../source/specifications/direct-url.rst:17 -msgid "Specification" -msgstr "Specifado" - -#: ../source/specifications/direct-url.rst:19 -msgid "" -"The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` " -"directory by installers when installing a distribution from a requirement " -"specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/direct-url.rst:23 -#: ../source/specifications/recording-installed-packages.rst:206 -msgid "" -"This file MUST NOT be created when installing a distribution from an other " -"type of requirement (i.e. name plus version specifier)." -msgstr "" - -#: ../source/specifications/direct-url.rst:26 -msgid "" -"This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." -msgstr "" - -#: ../source/specifications/direct-url.rst:29 -msgid "" -"If present, it MUST contain at least two fields. The first one is ``url``, " -"with type ``string``. Depending on what ``url`` refers to, the second field " -"MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), " -"``archive_info`` (if ``url`` is a source archives or a wheel), or " -"``dir_info`` (if ``url`` is a local directory). These info fields have a " -"(possibly empty) subdictionary as value, with the possible keys defined " -"below." -msgstr "" - -#: ../source/specifications/direct-url.rst:36 -msgid "" -"``url`` MUST be stripped of any sensitive authentication information, for " -"security reasons." -msgstr "" - -#: ../source/specifications/direct-url.rst:39 -msgid "" -"The user:password section of the URL MAY however be composed of environment " -"variables, matching the following regular expression::" -msgstr "" - -#: ../source/specifications/direct-url.rst:45 -msgid "" -"Additionally, the user:password section of the URL MAY be a well-known, non " -"security sensitive string. A typical example is ``git`` in the case of an " -"URL such as ``ssh://git@gitlab.com/user/repo``." -msgstr "" - -#: ../source/specifications/direct-url.rst:49 -msgid "" -"When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be " -"present as a dictionary with the following keys:" -msgstr "" - -#: ../source/specifications/direct-url.rst:52 -msgid "" -"A ``vcs`` key (type ``string``) MUST be present, containing the name of the " -"VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be " -"registered by writing a PEP to amend this specification. The ``url`` value " -"MUST be compatible with the corresponding VCS, so an installer can hand it " -"off without transformation to a checkout/download command of the VCS." -msgstr "" - -#: ../source/specifications/direct-url.rst:58 -msgid "" -"A ``requested_revision`` key (type ``string``) MAY be present naming a " -"branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to " -"install." -msgstr "" - -#: ../source/specifications/direct-url.rst:61 -msgid "" -"A ``commit_id`` key (type ``string``) MUST be present, containing the exact " -"commit/revision number that was installed. If the VCS supports commit-hash " -"based revision identifiers, such commit-hash MUST be used as ``commit_id`` " -"in order to reference the immutable version of the source code that was " -"installed." -msgstr "" - -#: ../source/specifications/direct-url.rst:68 -msgid "" -"When ``url`` refers to a source archive or a wheel, the ``archive_info`` key " -"MUST be present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:71 -msgid "" -"A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are " -"unconditionally provided by the latest version of the standard library's " -"``hashlib`` module be used for source archive hashes. At time of writing, " -"that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and " -"'sha512'." -msgstr "" - -#: ../source/specifications/direct-url.rst:78 -msgid "" -"When ``url`` refers to a local directory, the ``dir_info`` key MUST be " -"present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:81 -msgid "" -"``editable`` (type: ``boolean``): ``true`` if the distribution was installed " -"in editable mode, ``false`` otherwise. If absent, default to ``false``." -msgstr "" - -#: ../source/specifications/direct-url.rst:84 -msgid "" -"When ``url`` refers to a local directory, it MUST have the ``file`` sheme " -"and be compliant with `RFC 8089 `_. In " -"particular, the path component must be absolute. Symbolic links SHOULD be " -"preserved when making relative paths absolute." -msgstr "" - -#: ../source/specifications/direct-url.rst:91 -msgid "" -"When the requested URL has the file:// scheme and points to a local " -"directory that happens to contain a VCS checkout, installers MUST NOT " -"attempt to infer any VCS information and therefore MUST NOT output any VCS " -"related information (such as ``vcs_info``) in :file:`direct_url.json`." -msgstr "" - -#: ../source/specifications/direct-url.rst:96 -msgid "" -"A top-level ``subdirectory`` field MAY be present containing a directory " -"path, relative to the root of the VCS repository, source archive or local " -"directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." -msgstr "" - -#: ../source/specifications/direct-url.rst:102 -msgid "" -"As a general rule, installers should as much as possible preserve the " -"information that was provided in the requested URL when generating :file:" -"`direct_url.json`. For example user:password environment variables should be " -"preserved and ``requested_revision`` should reflect the revision that was " -"provided in the requested URL as faithfully as possible. This information is " -"however *enriched* with more precise data, such as ``commit_id``." -msgstr "" - -#: ../source/specifications/direct-url.rst:110 -msgid "Registered VCS" -msgstr "" - -#: ../source/specifications/direct-url.rst:112 -msgid "" -"This section lists the registered VCS's; expanded, VCS-specific information " -"on how to use the ``vcs``, ``requested_revision``, and other fields of " -"``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY " -"support other VCS's although it is RECOMMENDED to register them by writing a " -"PEP to amend this specification. The ``vcs`` field SHOULD be the command " -"name (lowercased). Additional fields that would be necessary to support such " -"VCS SHOULD be prefixed with the VCS command name." -msgstr "" - -#: ../source/specifications/direct-url.rst:122 -msgid "Git" -msgstr "" - -#: ../source/specifications/direct-url.rst:124 -#: ../source/specifications/direct-url.rst:156 -#: ../source/specifications/direct-url.rst:179 -#: ../source/specifications/direct-url.rst:202 -msgid "Home page" -msgstr "" - -#: ../source/specifications/direct-url.rst:126 -msgid "https://git-scm.com/" -msgstr "" - -#: ../source/specifications/direct-url.rst:128 -#: ../source/specifications/direct-url.rst:160 -#: ../source/specifications/direct-url.rst:183 -#: ../source/specifications/direct-url.rst:206 -msgid "vcs command" -msgstr "" - -#: ../source/specifications/direct-url.rst:130 -#: ../source/specifications/direct-url.rst:134 -msgid "git" -msgstr "" - -#: ../source/specifications/direct-url.rst:132 -#: ../source/specifications/direct-url.rst:164 -#: ../source/specifications/direct-url.rst:187 -#: ../source/specifications/direct-url.rst:210 -msgid "``vcs`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:136 -#: ../source/specifications/direct-url.rst:168 -#: ../source/specifications/direct-url.rst:191 -#: ../source/specifications/direct-url.rst:214 -msgid "``requested_revision`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:138 -msgid "" -"A tag name, branch name, Git ref, commit hash, shortened commit hash, or " -"other commit-ish." -msgstr "" - -#: ../source/specifications/direct-url.rst:141 -#: ../source/specifications/direct-url.rst:172 -#: ../source/specifications/direct-url.rst:195 -#: ../source/specifications/direct-url.rst:219 -msgid "``commit_id`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:143 -msgid "A commit hash (40 hexadecimal characters sha1)." -msgstr "" - -#: ../source/specifications/direct-url.rst:147 -msgid "" -"Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to " -"determine if the ``requested_revision`` corresponds to a Git ref. In turn, a " -"ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning " -"with ``refs/remotes/origin/`` after cloning corresponds to a branch." -msgstr "" - -#: ../source/specifications/direct-url.rst:154 -msgid "Mercurial" -msgstr "" - -#: ../source/specifications/direct-url.rst:158 -msgid "https://www.mercurial-scm.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:162 -#: ../source/specifications/direct-url.rst:166 -msgid "hg" -msgstr "" - -#: ../source/specifications/direct-url.rst:170 -msgid "A tag name, branch name, changeset ID, shortened changeset ID." -msgstr "" - -#: ../source/specifications/direct-url.rst:174 -msgid "A changeset ID (40 hexadecimal characters)." -msgstr "" - -#: ../source/specifications/direct-url.rst:177 -msgid "Bazaar" -msgstr "" - -#: ../source/specifications/direct-url.rst:181 -msgid "https://bazaar.canonical.com/" -msgstr "" - -#: ../source/specifications/direct-url.rst:185 -#: ../source/specifications/direct-url.rst:189 -msgid "bzr" -msgstr "" - -#: ../source/specifications/direct-url.rst:193 -msgid "A tag name, branch name, revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:197 -msgid "A revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:200 -msgid "Subversion" -msgstr "" - -#: ../source/specifications/direct-url.rst:204 -msgid "https://subversion.apache.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:208 -#: ../source/specifications/direct-url.rst:212 -msgid "svn" -msgstr "" - -#: ../source/specifications/direct-url.rst:216 -msgid "" -"``requested_revision`` must be compatible with ``svn checkout`` ``--" -"revision`` option. In Subversion, branch or tag is part of ``url``." -msgstr "" - -#: ../source/specifications/direct-url.rst:221 -msgid "" -"Since Subversion does not support globally unique identifiers, this field is " -"the Subversion revision number in the corresponding repository." -msgstr "" - -#: ../source/specifications/direct-url.rst:229 -msgid "Example direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:231 -msgid "Source archive:" -msgstr "" - -#: ../source/specifications/direct-url.rst:242 -msgid "Git URL with tag and commit-hash:" -msgstr "" - -#: ../source/specifications/direct-url.rst:255 -msgid "Local directory:" -msgstr "" - -#: ../source/specifications/direct-url.rst:264 -msgid "Local directory installed in editable mode:" -msgstr "" - -#: ../source/specifications/direct-url.rst:277 -msgid "Example pip commands and their effect on direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:279 -msgid "Commands that generate a ``direct_url.json``:" -msgstr "" - -#: ../source/specifications/direct-url.rst:281 -msgid "pip install https://example.com/app-1.0.tgz" -msgstr "" - -#: ../source/specifications/direct-url.rst:282 -msgid "pip install https://example.com/app-1.0.whl" -msgstr "" - -#: ../source/specifications/direct-url.rst:283 -msgid "" -"pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup" -"\"" -msgstr "" - -#: ../source/specifications/direct-url.rst:284 -msgid "pip install ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:285 -msgid "pip install file:///home/user/app" -msgstr "" - -#: ../source/specifications/direct-url.rst:286 -msgid "" -"pip install --editable \"git+https://example.com/repo/app." -"git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local " -"directory where the git repository has been cloned to, and ``dir_info`` will " -"be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" -msgstr "" - -#: ../source/specifications/direct-url.rst:290 -msgid "pip install -e ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:292 -msgid "Commands that *do not* generate a ``direct_url.json``" -msgstr "" - -#: ../source/specifications/direct-url.rst:294 -msgid "pip install app" -msgstr "" - -#: ../source/specifications/direct-url.rst:295 -msgid "pip install app --no-index --find-links https://example.com/" -msgstr "" - -#: ../source/specifications/entry-points.rst:5 -msgid "Entry points specification" -msgstr "" - -#: ../source/specifications/entry-points.rst:7 -msgid "" -"*Entry points* are a mechanism for an installed distribution to advertise " -"components it provides to be discovered and used by other code. For example:" -msgstr "" - -#: ../source/specifications/entry-points.rst:11 -msgid "" -"Distributions can specify ``console_scripts`` entry points, each referring " -"to a function. When *pip* (or another console_scripts aware installer) " -"installs the distribution, it will create a command-line wrapper for each " -"entry point." -msgstr "" - -#: ../source/specifications/entry-points.rst:14 -msgid "" -"Applications can use entry points to load plugins; e.g. Pygments (a syntax " -"highlighting tool) can use additional lexers and styles from separately " -"installed packages. For more about this, see :doc:`/guides/creating-and-" -"discovering-plugins`." -msgstr "" - -#: ../source/specifications/entry-points.rst:19 -msgid "" -"The entry point file format was originally developed to allow packages built " -"with setuptools to provide integration point metadata that would be read at " -"runtime with ``importlib.metadata``. It is now defined as a PyPA " -"interoperability specification in order to allow build tools other than " -"setuptools to publish ``importlib.metadata`` compatible entry point " -"metadata, and runtime libraries other than ``importlib.metadata`` to " -"portably read published entry point metadata (potentially with different " -"caching and conflict resolution strategies)." -msgstr "" - -#: ../source/specifications/entry-points.rst:28 -msgid "Data model" -msgstr "" - -#: ../source/specifications/entry-points.rst:30 -msgid "Conceptually, an entry point is defined by three required properties:" -msgstr "" - -#: ../source/specifications/entry-points.rst:32 -msgid "" -"The **group** that an entry point belongs to indicates what sort of object " -"it provides. For instance, the group ``console_scripts`` is for entry points " -"referring to functions which can be used as a command, while ``pygments." -"styles`` is the group for classes defining pygments styles. The consumer " -"typically defines the expected interface. To avoid clashes, consumers " -"defining a new group should use names starting with a PyPI name owned by the " -"consumer project, followed by ``.``. Group names must be one or more groups " -"of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w" -"+)*$``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:42 -msgid "" -"The **name** identifies this entry point within its group. The precise " -"meaning of this is up to the consumer. For console scripts, the name of the " -"entry point is the command that will be used to launch it. Within a " -"distribution, entry point names should be unique. If different distributions " -"provide the same name, the consumer decides how to handle such conflicts. " -"The name may contain any characters except ``=``, but it cannot start or end " -"with any whitespace character, or start with ``[``. For new entry points, it " -"is recommended to use only letters, numbers, underscores, dots and dashes " -"(regex ``[\\w.-]+``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:51 -msgid "" -"The **object reference** points to a Python object. It is either in the form " -"``importable.module``, or ``importable.module:object.attr``. Each of the " -"parts delimited by dots and the colon is a valid Python identifier. It is " -"intended to be looked up like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:64 -msgid "" -"Some tools call this kind of object reference by itself an 'entry point', " -"for want of a better term, especially where it points to a function to " -"launch a program." -msgstr "" - -#: ../source/specifications/entry-points.rst:68 -msgid "" -"There is also an optional property: the **extras** are a set of strings " -"identifying optional features of the distribution providing the entry point. " -"If these are specified, the entry point requires the dependencies of those " -"'extras'. See the metadata field :ref:`metadata_provides_extra`." -msgstr "" - -#: ../source/specifications/entry-points.rst:73 -msgid "" -"Using extras for an entry point is no longer recommended. Consumers should " -"support parsing them from existing distributions, but may then ignore them. " -"New publishing tools need not support specifying extras. The functionality " -"of handling extras was tied to setuptools' model of managing 'egg' packages, " -"but newer tools such as pip and virtualenv use a different model." -msgstr "" - -#: ../source/specifications/entry-points.rst:80 -msgid "File format" -msgstr "" - -#: ../source/specifications/entry-points.rst:82 -msgid "" -"Entry points are defined in a file called :file:`entry_points.txt` in the :" -"file:`*.dist-info` directory of the distribution. This is the directory " -"described in :pep:`376` for installed distributions, and in :pep:`427` for " -"wheels. The file uses the UTF-8 character encoding." -msgstr "" - -#: ../source/specifications/entry-points.rst:87 -msgid "" -"The file contents are in INI format, as read by Python's :mod:`configparser` " -"module. However, configparser treats names as case-insensitive by default, " -"whereas entry point names are case sensitive. A case-sensitive config parser " -"can be made like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:97 -msgid "" -"The entry points file must always use ``=`` to delimit names from values " -"(whereas configparser also allows using ``:``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:100 -msgid "" -"The sections of the config file represent entry point groups, the names are " -"names, and the values encode both the object reference and the optional " -"extras. If extras are used, they are a comma-separated list inside square " -"brackets." -msgstr "" - -#: ../source/specifications/entry-points.rst:104 -msgid "" -"Within a value, readers must accept and ignore spaces (including multiple " -"consecutive spaces) before or after the colon, between the object reference " -"and the left square bracket, between the extra names and the square brackets " -"and colons delimiting them, and after the right square bracket. The syntax " -"for extras is formally specified as part of :pep:`508` (as ``extras``). For " -"tools writing the file, it is recommended only to insert a space between the " -"object reference and the left square bracket." -msgstr "" - -#: ../source/specifications/entry-points.rst:112 -msgid "For example::" -msgstr "" - -#: ../source/specifications/entry-points.rst:124 -msgid "Use for scripts" -msgstr "" - -#: ../source/specifications/entry-points.rst:126 -msgid "" -"Two groups of entry points have special significance in packaging: " -"``console_scripts`` and ``gui_scripts``. In both groups, the name of the " -"entry point should be usable as a command in a system shell after the " -"package is installed. The object reference points to a function which will " -"be called with no arguments when this command is run. The function may " -"return an integer to be used as a process exit code, and returning ``None`` " -"is equivalent to returning ``0``." -msgstr "" - -#: ../source/specifications/entry-points.rst:134 -msgid "" -"For instance, the entry point ``mycmd = mymod:main`` would create a command " -"``mycmd`` launching a script like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:141 -msgid "" -"The difference between ``console_scripts`` and ``gui_scripts`` only affects " -"Windows systems. ``console_scripts`` are wrapped in a console executable, so " -"they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and " -"``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI " -"executable, so they can be started without a console, but cannot use " -"standard streams unless application code redirects them. Other platforms do " -"not have the same distinction." -msgstr "" - -#: ../source/specifications/entry-points.rst:149 -msgid "" -"Install tools are expected to set up wrappers for both ``console_scripts`` " -"and ``gui_scripts`` in the scripts directory of the install scheme. They are " -"not responsible for putting this directory in the ``PATH`` environment " -"variable which defines where command-line tools are found." -msgstr "" - -#: ../source/specifications/entry-points.rst:154 -msgid "" -"As files are created from the names, and some filesystems are case-" -"insensitive, packages should avoid using names in these groups which differ " -"only in case. The behaviour of install tools when names differ only in case " -"is undefined." -msgstr "" - -#: ../source/specifications/index.rst:4 -msgid "PyPA specifications" -msgstr "" - -#: ../source/specifications/index.rst:6 -msgid "" -"This is a list of currently active interoperability specifications " -"maintained by the Python Packaging Authority. The process for updating these " -"standards, and for proposing new ones, is documented on `pypa.io `__." -msgstr "" - -#: ../source/specifications/index.rst:13 -msgid "Package Distribution Metadata" -msgstr "" - -#: ../source/specifications/index.rst:30 -msgid "Package Distribution File Formats" -msgstr "" - -#: ../source/specifications/index.rst:40 -msgid "Package Index Interfaces" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:6 -msgid "Platform compatibility tags" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:8 -msgid "" -"Platform compatibility tags allow build tools to mark distributions as being " -"compatible with specific platforms, and allows installers to understand " -"which distributions are compatible with the system they are running on." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:12 -msgid "" -"The platform compatibility tagging model used for the ``wheel`` distribution " -"format is defined in :pep:`425`." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:16 -msgid "Platform tags for Windows" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:18 -msgid "" -"The scheme defined in :pep:`425` covers public distribution of wheel files " -"to systems running Windows." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:22 -msgid "Platform tags for macOS (Mac OS X)" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:24 -msgid "" -"The scheme defined in :pep:`425` covers public distribution of wheel files " -"to systems running macOS (previously known as Mac OS X)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:28 -msgid "Platform tags for common Linux distributions" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:32 -msgid "" -"The scheme defined in :pep:`425` is insufficient for public distribution of " -"wheel files (and \\*nix wheel files in general) to Linux platforms, due to " -"the large ecosystem of Linux platforms and subtle differences between them." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:36 -msgid "" -"Instead, :pep:`600` defines the ``manylinux`` standard, which represents a " -"common subset of Linux platforms, and allows building wheels tagged with the " -"``manylinux`` platform tag which can be used across most common Linux " -"distributions." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:41 -msgid "" -"There were multiple iterations of the ``manylinux`` specification, each " -"representing the common subset of Linux platforms at a given point in time:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:44 -msgid "" -"``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, " -"and is based on a compatible Linux platform from 2007." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:46 -msgid "" -"``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` " -"architectures. and updates the previous specification to be based on a " -"compatible Linux platform from 2010 instead." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:49 -msgid "" -"``manylinux2014`` (:pep:`599`) adds support for a number of additional " -"architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and " -"``s390x``) and updates the base platform to a compatible Linux platform from " -"2014." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:54 -msgid "" -"``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a " -"future-proof standard. It defines ``x`` and ``y`` as glibc major an minor " -"versions supported (e.g. ``manylinux_2_24`` should work on any distro using " -"glibc 2.24+). Previous tags are still supported for backward compatibility." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:59 -msgid "" -"In general, distributions built for older versions of the specification are " -"forwards-compatible (meaning that ``manylinux1`` distributions should " -"continue to work on modern systems) but not backwards-compatible (meaning " -"that ``manylinux2010`` distributions are not expected to work on platforms " -"that existed before 2010)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:65 -msgid "" -"Package maintainers should attempt to target the most compatible " -"specification possible, with the caveat that the provided build environment " -"for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning " -"that these images will no longer receive security updates." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:71 -msgid "Manylinux compatibility support" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:74 -msgid "" -"The ``manylinux2014`` specification is relatively new and is not yet widely " -"recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:76 -msgid "" -"The ``manylinux_x_y`` specification is relatively new and is not yet widely " -"recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:79 -msgid "" -"The following table shows the minimum versions of relevant projects to " -"support the various ``manylinux`` standards:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "Tool" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux1``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2010``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2014``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux_x_y``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=8.1.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=20.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "auditwheel" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=1.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=2.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.3.0`` [#]_" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:90 -msgid "Platform tags for other \\*nix platforms" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:92 -msgid "" -"The scheme defined in :pep:`425` is not generally sufficient for public " -"distribution of wheel files to other \\*nix platforms. Efforts are currently " -"(albeit intermittently) under way to define improved compatibility tagging " -"schemes for AIX and for Alpine Linux." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:98 -msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" -msgstr "" - -#: ../source/specifications/pypirc.rst:6 -msgid "The :file:`.pypirc` file" -msgstr "" - -#: ../source/specifications/pypirc.rst:8 -msgid "" -"A :file:`.pypirc` file allows you to define the configuration for :term:" -"`package indexes ` (referred to here as \"repositories\"), so " -"that you don't have to enter the URL, username, or password whenever you " -"upload a package with :ref:`twine` or :ref:`flit`." -msgstr "" - -#: ../source/specifications/pypirc.rst:13 -msgid "The format (originally defined by the :ref:`distutils` package) is:" -msgstr "" - -#: ../source/specifications/pypirc.rst:32 -msgid "" -"The ``distutils`` section defines an ``index-servers`` field that lists the " -"name of all sections describing a repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:35 -msgid "Each section describing a repository defines three fields:" -msgstr "" - -#: ../source/specifications/pypirc.rst:37 -msgid "``repository``: The URL of the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:38 -msgid "``username``: The registered username on the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:39 -msgid "``password``: The password that will used to authenticate the username." -msgstr "" - -#: ../source/specifications/pypirc.rst:43 -msgid "" -"Be aware that this stores your password in plain text. For better security, " -"consider an alternative like `keyring`_, setting environment variables, or " -"providing the password on the command line." -msgstr "" - -#: ../source/specifications/pypirc.rst:47 -msgid "" -"Otherwise, set the permissions on :file:`.pypirc` so that only you can view " -"or modify it. For example, on Linux or macOS, run:" -msgstr "" - -#: ../source/specifications/pypirc.rst:57 -msgid "Common configurations" -msgstr "" - -#: ../source/specifications/pypirc.rst:61 -msgid "" -"These examples apply to :ref:`twine`, and projects like :ref:`hatch` that " -"use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`." -"pypirc`, but with different defaults. Please refer to each project's " -"documentation for more details and usage instructions." -msgstr "" - -#: ../source/specifications/pypirc.rst:66 -msgid "" -"Twine's default configuration mimics a :file:`.pypirc` with repository " -"sections for PyPI and TestPyPI:" -msgstr "" - -#: ../source/specifications/pypirc.rst:82 -msgid "" -"Twine will add additional configuration from :file:`$HOME/.pypirc`, the " -"command line, and environment variables to this default configuration." -msgstr "" - -#: ../source/specifications/pypirc.rst:86 -msgid "Using a PyPI token" -msgstr "" - -#: ../source/specifications/pypirc.rst:88 -msgid "" -"To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` " -"similar to:" -msgstr "" - -#: ../source/specifications/pypirc.rst:97 -msgid "" -"For :ref:`TestPyPI `, add a ``[testpypi]`` section, using " -"the API token from your TestPyPI account." -msgstr "" - -#: ../source/specifications/pypirc.rst:103 -msgid "Using another package index" -msgstr "" - -#: ../source/specifications/pypirc.rst:105 -msgid "" -"To configure an additional repository, you'll need to redefine the ``index-" -"servers`` field to include the repository name. Here is a complete example " -"of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" -msgstr "" - -#: ../source/specifications/pypirc.rst:132 -msgid "" -"Instead of using the ``password`` field, consider saving your API tokens and " -"passwords securely using `keyring`_ (which is installed by Twine):" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:5 -msgid "Recording installed projects" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:7 -msgid "" -"This document specifies a common format of recording information about " -"Python :term:`projects ` installed in an environment. A common " -"metadata format allows tools to query, manage or uninstall projects, " -"regardless of how they were installed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:12 -msgid "" -"Almost all information is optional. This allows tools outside the Python " -"ecosystem, such as Linux package managers, to integrate with Python tooling " -"as much as possible. For example, even if an installer cannot easily provide " -"a list of installed files in a format specific to Python tooling, it should " -"still record the name and version of the installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:21 -msgid "History and change workflow" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:23 -msgid "" -"The metadata described here was first specified in :pep:`376`, and later " -"amended in :pep:`627`. It was formerly known as *Database of Installed " -"Python Distributions*. Further amendments (except trivial language or " -"typography fixes) must be made through the PEP process (see :pep:`1`)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:29 -msgid "" -"While this document is the normative specification, these PEPs that " -"introduce changes to it may include additional information such as " -"rationales and backwards compatibility considerations." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:37 -msgid "" -"Each project installed from a distribution must, in addition to files, " -"install a \"``.dist-info``\" directory located alongside importable modules " -"and packages (commonly, the ``site-packages`` directory)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:41 -msgid "" -"This directory is named as ``{name}-{version}.dist-info``, with ``name`` and " -"``version`` fields corresponding to :ref:`core-metadata`. Both fields must " -"be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 " -"<440#normalization>` for the definition of normalization for each field " -"respectively), and replace dash (``-``) characters with underscore (``_``) " -"chacaters, so the ``.dist-info`` directory always has exactly one dash (``-" -"``) character in its stem, separating the ``name`` and ``version`` fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:50 -msgid "" -"Historically, tools have failed to replace dot characters or normalize case " -"in the ``name`` field, or not perform normalization in the ``version`` " -"field. Tools consuming ``.dist-info`` directories should expect those fields " -"to be unnormalized, and treat them as equivalent to their normalized " -"counterparts. New tools that write ``.dist-info`` directories MUST normalize " -"both ``name`` and ``version`` fields using the rules described above, and " -"existing tools are encouraged to start normalizing those fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:60 -msgid "" -"The ``.dist-info`` directory's name is formatted to unambigiously represent " -"a distribution as a filesystem path. Tools presenting a distribution name to " -"a user should avoid using the normalized name, and instead present the " -"specified name (when needed prior to resolution to an installed package), or " -"read the respective fields in Core Metadata, since values listed there are " -"unescaped and accurately reflect the distribution. Libraries should provide " -"API for such tools to consume, so tools can have access to the unnormalized " -"name when displaying distrubution information." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:69 -msgid "" -"This ``.dist-info`` directory can contain these files, described in detail " -"below:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:72 -msgid "``METADATA``: contains project metadata" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:73 -msgid "``RECORD``: records the list of installed files." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:74 -msgid "" -"``INSTALLER``: records the name of the tool used to install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:76 -msgid "" -"The ``METADATA`` file is mandatory. All other files may be omitted at the " -"installing tool's discretion. Additional installer-specific files may be " -"present." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:82 -msgid "" -"The :ref:`binary-distribution-format` specification describes additional " -"files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. " -"Such files may be copied to the ``.dist-info`` directory of an installed " -"project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:87 -msgid "" -"The previous versions of this specification also specified a ``REQUESTED`` " -"file. This file is now considered a tool-specific extension, but may be " -"standardized again in the future. See `PEP 376 `_ for its original meaning." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:94 -msgid "The METADATA file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:96 -msgid "" -"The ``METADATA`` file contains metadata as described in the :ref:`core-" -"metadata` specification, version 1.1 or greater." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:99 -msgid "" -"The ``METADATA`` file is mandatory. If it cannot be created, or if required " -"core metadata is not available, installers must report an error and fail to " -"install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:105 -msgid "The RECORD file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:107 -msgid "" -"The ``RECORD`` file holds the list of installed files. It is a CSV file " -"containing one record (line) per installed file." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:110 -msgid "" -"The CSV dialect must be readable with the default ``reader`` of Python's " -"``csv`` module:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:113 -msgid "field delimiter: ``,`` (comma)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:114 -msgid "quoting char: ``\"`` (straight double quote)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:115 -msgid "line terminator: either ``\\r\\n`` or ``\\n``." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:117 -msgid "" -"Each record is composed of three elements: the file's **path**, the **hash** " -"of the contents, and its **size**." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:120 -msgid "" -"The *path* may be either absolute, or relative to the directory containing " -"the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On " -"Windows, directories may be separated either by forward- or backslashes (``/" -"`` or ``\\``)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:125 -msgid "" -"The *hash* is either an empty string or the name of a hash algorithm from " -"``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` " -"and the digest of the file's contents, encoded with the urlsafe-base64-nopad " -"encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:130 -msgid "" -"The *size* is either the empty string, or file's size in bytes, as a base 10 " -"integer." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:133 -msgid "" -"For any file, either or both of the *hash* and *size* fields may be left " -"empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself " -"have empty *hash* and *size*. For other files, leaving the information out " -"is discouraged, as it prevents verifying the integrity of the installed " -"project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:139 -msgid "" -"If the ``RECORD`` file is present, it must list all installed files of the " -"project, except ``.pyc`` files corresponding to ``.py`` files listed in " -"``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` " -"directory (including the ``RECORD`` file itself) must be listed. Directories " -"should not be listed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:146 -msgid "" -"To completely uninstall a package, a tool needs to remove all files listed " -"in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding " -"to removed ``.py`` files, and any directories emptied by the uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:151 -msgid "Here is an example snippet of a possible ``RECORD`` file::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:170 -msgid "" -"If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must " -"not atempt to uninstall or upgrade the package. (This does not apply to " -"tools that rely on other sources of information, such as system package " -"managers in Linux distros.)" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:177 -msgid "The INSTALLER file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:179 -msgid "" -"If present, ``INSTALLER`` is a single-line text file naming the tool used to " -"install the project. If the installer is executable from the command line, " -"``INSTALLER`` should contain the command name. Otherwise, it should contain " -"a printable ASCII string." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:185 -msgid "The file can be terminated by zero or more ASCII whitespace characters." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:187 -msgid "Here are examples of two possible ``INSTALLER`` files::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:195 -msgid "" -"This value should be used for informational purposes only. For example, if a " -"tool is asked to uninstall a project but finds no ``RECORD`` file, it may " -"suggest that the tool named in ``INSTALLER`` may be able to do the " -"uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:201 -msgid "The direct_url.json file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:203 -msgid "" -"This file MUST be created by installers when installing a distribution from " -"a requirement specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:209 -msgid "Its detailed specification is at :ref:`direct-url`." -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:6 -msgid "Simple repository API" -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:8 -msgid "" -"The current interface for querying available package versions and retrieving " -"packages from an index server is defined in :pep:`503`, with the addition of " -"\"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` " -"and specifying the interface version provided by an index server in :pep:" -"`629`." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:6 -msgid "Source distribution format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:8 -msgid "" -"The current standard format of source distribution format is identified by " -"the presence of a :file:`pyproject.toml` file in the distribution archive. " -"The layout of such a distribution was originally specified in :pep:`517` and " -"is formally documented here." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:13 -msgid "" -"There is also the legacy source distribution format, implicitly defined by " -"the behaviour of ``distutils`` module in the standard library, when " -"executing :command:`setup.py sdist`. This document does not attempt to " -"standardise this format, except to note that if a legacy source distribution " -"contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it " -"MUST follow the rules applicable to source distributions defined in the " -"metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:21 -msgid "Source distributions are also known as *sdists* for short." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:24 -msgid "Source distribution file name" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:26 -msgid "" -"The file name of a sdist is not currently standardised, although the *de " -"facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the " -"canonicalized form of the project name (see :pep:`503` for the " -"canonicalization rules) with ``-`` characters replaced with ``_``, and " -"``{version}`` is the project version." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:31 -msgid "" -"The name and version components of the filename MUST match the values stored " -"in the metadata contained in the file." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:35 -msgid "Source distribution file format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:37 -msgid "" -"A ``.tar.gz`` source distribution (sdist) contains a single top-level " -"directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the " -"source files of the package. The name and version MUST match the metadata " -"stored in the file. This directory must also contain a :file:`pyproject." -"toml` in the format defined in :ref:`declaring-build-dependencies`, and a " -"``PKG-INFO`` file containing metadata in the format described in the :ref:" -"`core-metadata` specification. The metadata MUST conform to at least version " -"2.2 of the metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:45 -msgid "" -"No other content of a sdist is required or defined. Build systems can store " -"whatever information they need in the sdist to build the project." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:48 -msgid "" -"The tarball should use the modern POSIX.1-2001 pax tar format, which " -"specifies UTF-8 based file names." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:6 -msgid "Version specifiers" -msgstr "" - -#: ../source/specifications/version-specifiers.rst:8 -msgid "" -"Version numbering requirements and the semantics for specifying comparisons " -"between versions are defined in :pep:`440`." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:11 -msgid "" -"The version specifiers section in this PEP supersedes the version specifiers " -"section in :pep:`345`." -msgstr "" - -#: ../source/support.rst:3 -msgid "How to Get Support" -msgstr "" - -#: ../source/support.rst:5 -msgid "" -"For support related to a specific project, see the links on the :doc:" -"`Projects ` page." -msgstr "" - -#: ../source/support.rst:8 -msgid "" -"For something more general, or when you're just not sure, please `open an " -"issue `_ on the " -"`packaging-problems `_ " -"repository on GitHub." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:5 -msgid "Creating Documentation" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:7 -msgid "" -"This section covers the basics of how to create documentation using " -"`Sphinx`_ and host the documentation for free in `Read The Docs`_." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:13 -msgid "Installing Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:14 -msgid "Use ``pip`` to install Sphinx:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:28 -msgid "" -"For other installation methods, see this `installation guide`_ by Sphinx." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:33 -msgid "Getting Started With Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:35 -msgid "" -"Create a ``docs`` directory inside your project to hold your documentation:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:42 -msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:49 -msgid "" -"This sets up a source directory, walks you through some basic " -"configurations, and creates an ``index.rst`` file as well as a ``conf.py`` " -"file." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:51 -msgid "" -"You can add some information about your project in ``index.rst``, then build " -"them:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:57 -msgid "" -"For more details on the build process, see this `guide`_ by Read The Docs." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:62 -msgid "Other Sources" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:64 -msgid "" -"For a more detailed guide on how to use Sphinx and reStructuredText, please " -"see this `documentation tutorial`_ on Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/index.rst:4 -msgid "" -"**Tutorials** are opinionated step-by-step guides to help you get familiar " -"with packaging concepts. For more detailed information on specific packaging " -"topics, see :doc:`/guides/index`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:5 -msgid "Installing Packages" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:7 -msgid "" -"This section covers the basics of how to install Python :term:`packages " -"`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:10 -msgid "" -"It's important to note that the term \"package\" in this context is being " -"used to describe a bundle of software to be installed (i.e. as a synonym for " -"a :term:`distribution `). It does not to refer to the " -"kind of :term:`package ` that you import in your Python " -"source code (i.e. a container of modules). It is common in the Python " -"community to refer to a :term:`distribution ` using " -"the term \"package\". Using the term \"distribution\" is often not " -"preferred, because it can easily be confused with a Linux distribution, or " -"another larger software distribution like Python itself." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:28 -msgid "Requirements for Installing Packages" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:30 -msgid "" -"This section describes the steps to follow before installing other Python " -"packages." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:35 -msgid "Ensure you can run Python from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:37 -msgid "" -"Before you go any further, make sure you have Python and that the expected " -"version is available from your command line. You can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:53 -msgid "" -"You should get some output like ``Python 3.6.3``. If you do not have Python, " -"please install the latest 3.x version from `python.org`_ or refer to the " -"`Installing Python`_ section of the Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:57 -msgid "If you're a newcomer and you get an error like this:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:66 -msgid "" -"It's because this command and other suggested commands in this tutorial are " -"intended to be run in a *shell* (also called a *terminal* or *console*). See " -"the Python for Beginners `getting started tutorial`_ for an introduction to " -"using your operating system's shell and interacting with Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:72 -msgid "" -"If you're using an enhanced shell like IPython or the Jupyter notebook, you " -"can run system commands like those in this tutorial by prefacing them with a " -"``!`` character:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:82 -msgid "" -"It's recommended to write ``{sys.executable}`` rather than plain ``python`` " -"in order to ensure that commands are run in the Python installation matching " -"the currently running notebook (which may not be the same Python " -"installation that the ``python`` command refers to)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:87 -msgid "" -"Due to the way most Linux distributions are handling the Python 3 migration, " -"Linux users using the system Python without creating a virtual environment " -"first should replace the ``python`` command in this tutorial with " -"``python3`` and the ``python -m pip`` command with ``python3 -m pip --" -"user``. Do *not* run any of the commands in this tutorial with ``sudo``: if " -"you get a permissions error, come back to the section on creating virtual " -"environments, set one up, and then continue with the tutorial as written." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:99 -msgid "Ensure you can run pip from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:101 -msgid "" -"Additionally, you'll need to make sure you have :ref:`pip` available. You " -"can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:116 -msgid "" -"If you installed Python from source, with an installer from `python.org`_, " -"or via `Homebrew`_ you should already have pip. If you're on Linux and " -"installed using your OS package manager, you may have to install pip " -"separately, see :doc:`/guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:124 -msgid "" -"If ``pip`` isn't already installed, then first try to bootstrap it from the " -"standard library:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:139 -msgid "If that still doesn't allow you to run ``python -m pip``:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:141 -msgid "" -"Securely Download `get-pip.py `_ [1]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:144 -msgid "" -"Run ``python get-pip.py``. [2]_ This will install or upgrade pip. " -"Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're " -"not installed already." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:150 -msgid "" -"Be cautious if you're using a Python install that's managed by your " -"operating system or another package manager. get-pip.py does not coordinate " -"with those tools, and may leave your system in an inconsistent state. You " -"can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/" -"local`` which is designed for locally-installed software." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:159 -msgid "Ensure pip, setuptools, and wheel are up to date" -msgstr "Certigu, ke pip, setuptools kaj wheel estas ĝisdataj" - -#: ../source/tutorials/installing-packages.rst:161 -msgid "" -"While ``pip`` alone is sufficient to install from pre-built binary archives, " -"up to date copies of the ``setuptools`` and ``wheel`` projects are useful to " -"ensure you can also install from source archives::" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:169 -msgid "Optionally, create a virtual environment" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:171 -msgid "" -"See :ref:`section below ` for " -"details, but here's the basic `venv`_ [3]_ command to use on a typical Linux " -"system:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:188 -msgid "" -"This will create a new virtual environment in the ``tutorial_env`` " -"subdirectory, and configure the current shell to use it as the default " -"``python`` environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:195 -msgid "Creating Virtual Environments" -msgstr "Krei Virtualajn Mediojn" - -#: ../source/tutorials/installing-packages.rst:197 -msgid "" -"Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular " -"application, rather than being installed globally. If you are looking to " -"safely install global command line tools, see :doc:`/guides/installing-stand-" -"alone-command-line-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:203 -msgid "" -"Imagine you have an application that needs version 1 of LibFoo, but another " -"application requires version 2. How can you use both these applications? If " -"you install everything into /usr/lib/python3.6/site-packages (or whatever " -"your platform’s standard location is), it’s easy to end up in a situation " -"where you unintentionally upgrade an application that shouldn’t be upgraded." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:209 -msgid "" -"Or more generally, what if you want to install an application and leave it " -"be? If an application works, any change in its libraries or the versions of " -"those libraries can break the application." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:213 -msgid "" -"Also, what if you can’t install :term:`packages ` into " -"the global site-packages directory? For instance, on a shared host." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:216 -msgid "" -"In all these cases, virtual environments can help you. They have their own " -"installation directories and they don’t share libraries with other virtual " -"environments." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:220 -msgid "" -"Currently, there are two common tools for creating Python virtual " -"environments:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:222 -msgid "" -"`venv`_ is available by default in Python 3.3 and later, and installs :ref:" -"`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 " -"and later." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:225 -msgid "" -":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ " -"and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are " -"always installed into created virtual environments by default (regardless of " -"Python version)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:230 -msgid "The basic usage is like so:" -msgstr "Jen la baza uzmaniero:" - -#: ../source/tutorials/installing-packages.rst:232 -msgid "Using `venv`_:" -msgstr "Uzante `venv`_:" - -#: ../source/tutorials/installing-packages.rst:248 -msgid "Using :ref:`virtualenv`:" -msgstr "Uzante :ref:`virtualenv`:" - -#: ../source/tutorials/installing-packages.rst:264 -msgid "" -"For more information, see the `venv`_ docs or the `virtualenv `_ docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:266 -msgid "" -"The use of :command:`source` under Unix shells ensures that the virtual " -"environment's variables are set within the current shell, and not in a " -"subprocess (which then disappears, having no useful effect)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:271 -msgid "" -"In both of the above cases, Windows users should _not_ use the :command:" -"`source` command, but should rather run the :command:`activate` script " -"directly from the command shell like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:281 -msgid "" -"Managing multiple virtual environments directly can become tedious, so the :" -"ref:`dependency management tutorial ` introduces a " -"higher level tool, :ref:`Pipenv`, that automatically manages a separate " -"virtual environment for each project and application that you work on." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:288 -msgid "Use pip for Installing" -msgstr "Uzu pip por instali" - -#: ../source/tutorials/installing-packages.rst:290 -msgid "" -":ref:`pip` is the recommended installer. Below, we'll cover the most common " -"usage scenarios. For more detail, see the `pip docs `_, " -"which includes a complete `Reference Guide `_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:297 -msgid "Installing from PyPI" -msgstr "Instali el PyPI" - -#: ../source/tutorials/installing-packages.rst:299 -msgid "" -"The most common usage of :ref:`pip` is to install from the :term:`Python " -"Package Index ` using a :term:`requirement " -"specifier `. Generally speaking, a requirement " -"specifier is composed of a project name followed by an optional :term:" -"`version specifier `. :pep:`440` contains a :pep:`full " -"specification <440#version-specifiers>` of the currently supported " -"specifiers. Below are some examples." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:307 -msgid "To install the latest version of \"SomeProject\":" -msgstr "Por instali la plej novan version de «SomeProject»:" - -#: ../source/tutorials/installing-packages.rst:321 -msgid "To install a specific version:" -msgstr "Por instali specifan version:" - -#: ../source/tutorials/installing-packages.rst:335 -msgid "To install greater than or equal to one version and less than another:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:350 -msgid "" -"To install a version that's :pep:`\"compatible\" <440#compatible-release>` " -"with a certain version: [4]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:365 -msgid "" -"In this case, this means to install any version \"==1.4.*\" version that's " -"also \">=1.4.2\"." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:370 -msgid "Source Distributions vs Wheels" -msgstr "Fonto-Distribuoj kontraste kun Wheel-oj" - -#: ../source/tutorials/installing-packages.rst:372 -msgid "" -":ref:`pip` can install from either :term:`Source Distributions (sdist) " -"` or :term:`Wheels `, but if both " -"are present on PyPI, pip will prefer a compatible :term:`wheel `. You " -"can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:378 -msgid "" -":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source " -"Distributions (sdist) `, especially when " -"a project contains compiled extensions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:383 -msgid "" -"If :ref:`pip` does not find a wheel to install, it will locally build a " -"wheel and cache it for future installs, instead of rebuilding the source " -"distribution in the future." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:391 -msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:408 -msgid "Installing to the User Site" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:410 -msgid "" -"To install :term:`packages ` that are isolated to the " -"current user, use the ``--user`` flag:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:425 -msgid "" -"For more information see the `User Installs `_ section from the pip docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:429 -msgid "" -"Note that the ``--user`` flag has no effect when inside a virtual " -"environment - all installation commands will affect the virtual environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:432 -msgid "" -"If ``SomeProject`` defines any command-line scripts or console entry points, " -"``--user`` will cause them to be installed inside the `user base`_'s binary " -"directory, which may or may not already be present in your shell's :envvar:" -"`PATH`. (Starting in version 10, pip displays a warning when installing any " -"scripts to a directory outside :envvar:`PATH`.) If the scripts are not " -"available in your shell after installation, you'll need to add the directory " -"to your :envvar:`PATH`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:440 -msgid "" -"On Linux and macOS you can find the user base binary directory by running " -"``python -m site --user-base`` and adding ``bin`` to the end. For example, " -"this will typically print ``~/.local`` (with ``~`` expanded to the absolute " -"path to your home directory) so you'll need to add ``~/.local/bin`` to your " -"``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:446 -msgid "" -"On Windows you can find the user base binary directory by running ``py -m " -"site --user-site`` and replacing ``site-packages`` with ``Scripts``. For " -"example, this could return ``C:\\Users\\Username\\AppData\\Roaming" -"\\Python36\\site-packages`` so you would need to set your ``PATH`` to " -"include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You " -"can set your user ``PATH`` permanently in the `Control Panel`_. You may need " -"to log out for the ``PATH`` changes to take effect." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:462 -msgid "" -"Install a list of requirements specified in a :ref:`Requirements File `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:478 -msgid "Installing from VCS" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:480 -msgid "" -"Install a project from VCS in \"editable\" mode. For a full breakdown of " -"the syntax, see pip's section on :ref:`VCS Support `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:502 -msgid "Installing from other Indexes" -msgstr "Instali el aliaj Indeksoj" - -#: ../source/tutorials/installing-packages.rst:504 -msgid "Install from an alternate index" -msgstr "Instali el alternativa indekso" - -#: ../source/tutorials/installing-packages.rst:518 -msgid "" -"Search an additional index during install, in addition to :term:`PyPI " -"`" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:534 -msgid "Installing from a local src tree" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:537 -msgid "" -"Installing from local src in `Development Mode `_, i.e. in such a " -"way that the project appears to be installed, but yet is still editable from " -"the src tree." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:554 -msgid "You can also install normally from src" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:571 -msgid "Install a particular source archive file." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:585 -msgid "" -"Install from a local directory containing archives (and don't check :term:" -"`PyPI `)" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:605 -msgid "Installing from other sources" -msgstr "Instali el aliaj fontoj" - -#: ../source/tutorials/installing-packages.rst:607 -msgid "" -"To install from other data sources (for example Amazon S3 storage) you can " -"create a helper application that presents the data in a :pep:`503` compliant " -"index format, and use the ``--extra-index-url`` flag to direct pip to use " -"that index." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:619 -msgid "Installing Prereleases" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:621 -msgid "" -"Find pre-release and development versions, in addition to stable versions. " -"By default, pip only finds stable versions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:637 -msgid "Installing Setuptools \"Extras\"" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:639 -msgid "Install `setuptools extras`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:659 -msgid "" -"\"Secure\" in this context means using a modern browser or a tool like :" -"command:`curl` that verifies SSL certificates when downloading from https " -"URLs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:668 -msgid "" -"Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:" -"`virtualenv`) will create virtualenv environments with ``pip`` pre-" -"installed, thereby making it an equal alternative to :ref:`virtualenv`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:673 -msgid "" -"The compatible release specifier was accepted in :pep:`440` and support was " -"released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:4 -msgid "Managing Application Dependencies" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:6 -msgid "" -"The :ref:`package installation tutorial ` covered the " -"basics of getting set up to install and update Python packages." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:9 -msgid "" -"However, running these commands interactively can get tedious even for your " -"own personal projects, and things get even more difficult when trying to set " -"up development environments automatically for projects with multiple " -"contributors." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:13 -msgid "" -"This tutorial walks you through the use of :ref:`Pipenv` to manage " -"dependencies for an application. It will show you how to install and use the " -"necessary tools and make strong recommendations on best practices." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:17 -msgid "" -"Keep in mind that Python is used for a great many different purposes, and " -"precisely how you want to manage your dependencies may change based on how " -"you decide to publish your software. The guidance presented here is most " -"directly applicable to the development and deployment of network services " -"(including web applications), but is also very well suited to managing " -"development and testing environments for any kind of project." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:24 -msgid "" -"Developers of Python libraries, or of applications that support distribution " -"as Python libraries, should also consider the `poetry `_ project as an alternative dependency management " -"solution." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:30 -msgid "Installing Pipenv" -msgstr "Instali Pipenv" - -#: ../source/tutorials/managing-dependencies.rst:32 -msgid "" -":ref:`Pipenv` is a dependency manager for Python projects. If you're " -"familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit " -"to those tools. While :ref:`pip` alone is often sufficient for personal use, " -"Pipenv is recommended for collaborative projects as it's a higher-level tool " -"that simplifies dependency management for common use cases." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:38 -msgid "Use ``pip`` to install Pipenv:" -msgstr "Uzi ``pip`` por instali Pipenv:" - -#: ../source/tutorials/managing-dependencies.rst:54 -msgid "" -"This does a `user installation`_ to prevent breaking any system-wide " -"packages. If ``pipenv`` isn't available in your shell after installation, " -"you'll need to add the `user base`_'s binary directory to your ``PATH``. " -"See :ref:`Installing to the User Site` for more information." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:65 -msgid "Installing packages for your project" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:67 -msgid "" -"Pipenv manages dependencies on a per-project basis. To install packages, " -"change into your project's directory (or just an empty directory for this " -"tutorial) and run:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:76 -msgid "" -"Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you " -"in your project's directory. The :ref:`Pipfile` is used to track which " -"dependencies your project needs in case you need to re-install them, such as " -"when you share your project with others. You should get output similar to " -"this (although the exact paths shown will vary):" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:112 -msgid "Using installed packages" -msgstr "Uzi instalitajn pakojn" - -#: ../source/tutorials/managing-dependencies.rst:114 -msgid "" -"Now that Requests is installed you can create a simple :file:`main.py` file " -"to use it:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:125 -msgid "Then you can run this script using ``pipenv run``:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:131 -msgid "You should get output similar to this:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:137 -msgid "" -"Using ``pipenv run`` ensures that your installed packages are available to " -"your script. It's also possible to spawn a new shell that ensures all " -"commands have access to your installed packages with ``pipenv shell``." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:143 -#: ../source/tutorials/packaging-projects.rst:594 -msgid "Next steps" -msgstr "Sekvaj paŝoj" - -#: ../source/tutorials/managing-dependencies.rst:145 -msgid "" -"Congratulations, you now know how to effectively manage dependencies and " -"development environments on a collaborative Python project! ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:148 -msgid "" -"If you're interested in creating and distributing your own Python packages, " -"see the :ref:`tutorial on packaging and distributing packages `." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:151 -msgid "" -"Note that when your application includes definitions of Python source " -"packages, they (and their dependencies) can be added to your ``pipenv`` " -"environment with ``pipenv install -e `` " -"(e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:160 -msgid "Other Tools for Application Dependency Management" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:162 -msgid "" -"If you find this particular approach to managing application dependencies " -"isn't working well for you or your use case, you may want to explore these " -"other tools and techniques to see if one of them is a better fit:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:166 -msgid "" -"`poetry `__ for a tool comparable " -"in scope to ``pipenv`` that focuses more directly on use cases where the " -"repository being managed is structured as a Python project with a valid " -"``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making " -"the assumption that the application being worked on that's depending on " -"components from PyPI will itself support distribution as a ``pip``-" -"installable Python package)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:172 -msgid "" -"`hatch `_ for opinionated coverage of even " -"more steps in the project management workflow (such as incrementing " -"versions, tagging releases, and creating new skeleton projects from project " -"templates)" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:175 -msgid "" -"`pip-tools `_ to build your own " -"custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:177 -msgid "" -"`micropipenv `_ is a " -"lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry " -"lock files or converting them to pip-tools compatible output. Designed for " -"containerized Python applications but not limited to them." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:2 -msgid "Packaging Python Projects" -msgstr "Paki projektojn de Python" - -#: ../source/tutorials/packaging-projects.rst:4 -msgid "" -"This tutorial walks you through how to package a simple Python project. It " -"will show you how to add the necessary files and structure to create the " -"package, how to build the package, and how to upload it to the Python " -"Package Index." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:10 -msgid "" -"If you have trouble running the commands in this tutoral, please copy the " -"command and its output, then `open an issue`_ on the `packaging-problems`_ " -"repository on GitHub. We'll do our best to help you!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:18 -msgid "" -"Some of the commands require a newer version of :ref:`pip`, so start by " -"making sure you have the latest version installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:35 -msgid "A simple project" -msgstr "Simpla projekto" - -#: ../source/tutorials/packaging-projects.rst:37 -msgid "" -"This tutorial uses a simple project named ``example_package``. We recommend " -"following this tutorial as-is using this project, before packaging your own " -"project." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:41 -msgid "Create the following file structure locally:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:51 -msgid "" -":file:`__init__.py` is required to import the directory as a package, and " -"should be empty." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:54 -msgid "" -":file:`example.py` is an example of a module within the package that could " -"contain the logic (functions, classes, constants, etc.) of your package. " -"Open that file and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:63 -msgid "" -"If you are unfamiliar with Python's :term:`modules ` and :term:" -"`import packages `, take a few minutes to read over the " -"`Python documentation for packages and modules`_." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:67 -msgid "" -"Once you create this structure, you'll want to run all of the commands in " -"this tutorial within the ``packaging_tutorial`` directory." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:75 -msgid "Creating the package files" -msgstr "Krei dosierojn de la pakaĵo" - -#: ../source/tutorials/packaging-projects.rst:77 -msgid "" -"You will now add files that are used to prepare the project for " -"distribution. When you're done, the project structure will look like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:95 -msgid "Creating a test directory" -msgstr "Krei elprovan dosierujon" - -#: ../source/tutorials/packaging-projects.rst:97 -msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:101 -msgid "Creating pyproject.toml" -msgstr "Krei la dosieron pyproject.toml" - -#: ../source/tutorials/packaging-projects.rst:103 -msgid "" -":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) " -"what is required to build your project. This tutorial uses :ref:" -"`setuptools`, so open :file:`pyproject.toml` and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:117 -msgid "" -"``build-system.requires`` gives a list of packages that are needed to build " -"your package. Listing something here will *only* make it available during " -"the build, not after it is installed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:121 -msgid "" -"``build-system.build-backend`` is the name of Python object that will be " -"used to perform the build. If you were to use a different build system, such " -"as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration " -"details would be completely different than the :ref:`setuptools` " -"configuration described below." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:127 -msgid "See :pep:`517` and :pep:`518` for background and details." -msgstr "Vidu :pep:`517` kaj :pep:`518` por fonaj informoj kaj detaloj." - -#: ../source/tutorials/packaging-projects.rst:131 -msgid "Configuring metadata" -msgstr "Agordi metadatenojn" - -#: ../source/tutorials/packaging-projects.rst:133 -msgid "There are two types of metadata: static and dynamic." -msgstr "Ekzistas du tipoj de metadatenoj: statika kaj dinamika." - -#: ../source/tutorials/packaging-projects.rst:135 -msgid "" -"Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. " -"This is simpler, easier to read, and avoids many common errors, like " -"encoding errors." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:137 -msgid "" -"Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items " -"that are dynamic or determined at install-time, as well as extension modules " -"or extensions to setuptools, need to go into :file:`setup.py`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:141 -msgid "" -"Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:" -"file:`setup.py`) should be used only as an escape hatch when absolutely " -"necessary. :file:`setup.py` used to be required, but can be omitted with " -"newer versions of setuptools and pip." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:148 -msgid "" -":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells " -"setuptools about your package (such as the name and version) as well as " -"which code files to include. Eventually much of this configuration may be " -"able to move to :file:`pyproject.toml`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:153 -msgid "" -"Open :file:`setup.cfg` and enter the following content. Change the ``name`` " -"to include your username; this ensures that you have a unique package name " -"and that your package doesn't conflict with packages uploaded by other " -"people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:185 -msgid "" -"There are a `variety of metadata and options `_ supported here. This is " -"in :doc:`configparser ` format; do not place " -"quotes around values. This example package uses a relatively minimal set of " -"``metadata``:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:191 -#: ../source/tutorials/packaging-projects.rst:286 -msgid "" -"``name`` is the *distribution name* of your package. This can be any name as " -"long as it only contains letters, numbers, ``_`` , and ``-``. It also must " -"not already be taken on pypi.org. **Be sure to update this with your " -"username,** as this ensures you won't try to upload a package with the same " -"name as one which already exists." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:196 -msgid "" -"``version`` is the package version. See :pep:`440` for more details on " -"versions. You can use ``file:`` or ``attr:`` directives to read from a file " -"or package attribute." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:199 -#: ../source/tutorials/packaging-projects.rst:293 -msgid "" -"``author`` and ``author_email`` are used to identify the author of the " -"package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:201 -#: ../source/tutorials/packaging-projects.rst:295 -msgid "``description`` is a short, one-sentence summary of the package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:202 -msgid "" -"``long_description`` is a detailed description of the package. This is shown " -"on the package detail page on the Python Package Index. In this case, the " -"long description is loaded from :file:`README.md` (which is a common " -"pattern) using the ``file:`` directive." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:206 -#: ../source/tutorials/packaging-projects.rst:300 -msgid "" -"``long_description_content_type`` tells the index what type of markup is " -"used for the long description. In this case, it's Markdown." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:208 -#: ../source/tutorials/packaging-projects.rst:302 -msgid "" -"``url`` is the URL for the homepage of the project. For many projects, this " -"will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting " -"service." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:211 -#: ../source/tutorials/packaging-projects.rst:305 -msgid "" -"``project_urls`` lets you list any number of extra links to show on PyPI. " -"Generally this could be to documentation, issue trackers, etc." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:213 -#: ../source/tutorials/packaging-projects.rst:307 -msgid "" -"``classifiers`` gives the index and :ref:`pip` some additional metadata " -"about your package. In this case, the package is only compatible with Python " -"3, is licensed under the MIT license, and is OS-independent. You should " -"always include at least which version(s) of Python your package works on, " -"which license your package is available under, and which operating systems " -"your package will work on. For a complete list of classifiers, see https://" -"pypi.org/classifiers/." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:221 -msgid "In the ``options`` category, we have controls for setuptools itself:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:223 -msgid "" -"``package_dir`` is a mapping of package names and directories. An empty " -"package name represents the \"root package\" --- the directory in the " -"project that contains all Python source files for the package --- so in this " -"case the ``src`` directory is designated the root package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:227 -msgid "" -"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " -"`. Instead of listing each package manually, we can " -"use the ``find:`` directive to automatically discover all packages and " -"subpackages and ``options.packages.find`` to specify the ``package_dir`` to " -"use. In this case, the list of packages will be ``example_package`` as " -"that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:234 -msgid "" -"``python_requires`` gives the versions of Python supported by your project. " -"Installers like :ref:`pip` will look back through older versions of packages " -"until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:238 -#: ../source/tutorials/packaging-projects.rst:329 -msgid "" -"There are many more than the ones mentioned here. See :doc:`/guides/" -"distributing-packages-using-setuptools` for more details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:244 -msgid "" -":file:`setup.py` is the build script for :ref:`setuptools`. It tells " -"setuptools about your package (such as the name and version) as well as " -"which code files to include." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:248 -msgid "" -"Open :file:`setup.py` and enter the following content. Change the ``name`` " -"to include your username; this ensures that you have a unique package name " -"and that your package doesn't conflict with packages uploaded by other " -"people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:283 -msgid "" -":func:`setup` takes several arguments. This example package uses a " -"relatively minimal set:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:291 -msgid "" -"``version`` is the package version. See :pep:`440` for more details on " -"versions." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:296 -msgid "" -"``long_description`` is a detailed description of the package. This is shown " -"on the package detail page on the Python Package Index. In this case, the " -"long description is loaded from :file:`README.md`, which is a common pattern." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:314 -msgid "" -"``package_dir`` is a dictionary with package names for keys and directories " -"for values. An empty package name represents the \"root package\" --- the " -"directory in the project that contains all Python source files for the " -"package --- so in this case the ``src`` directory is designated the root " -"package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:319 -msgid "" -"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " -"`. Instead of listing each package manually, we can " -"use :func:`find_packages` to automatically discover all packages and " -"subpackages under ``package_dir``. In this case, the list of packages will " -"be ``example_package`` as that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:325 -msgid "" -"``python_requires`` gives the versions of Python supported by your project. " -"Installers like :ref:`pip` will look back though older versions of packages " -"until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:333 -msgid "Creating README.md" -msgstr "Krei la dosieron README.md" - -#: ../source/tutorials/packaging-projects.rst:335 -msgid "" -"Open :file:`README.md` and enter the following content. You can customize " -"this if you'd like." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:347 -msgid "" -"Because our configuration loads :file:`README.md` to provide a " -"``long_description``, :file:`README.md` must be included along with your " -"code when you :ref:`generate a source distribution `. " -"Newer versions of :ref:`setuptools` will do this automatically." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:354 -msgid "Creating a LICENSE" -msgstr "Krei la dosieron LICENSE" - -#: ../source/tutorials/packaging-projects.rst:356 -msgid "" -"It's important for every package uploaded to the Python Package Index to " -"include a license. This tells users who install your package the terms under " -"which they can use your package. For help picking a license, see https://" -"choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` " -"and enter the license text. For example, if you had chosen the MIT license:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:387 -msgid "Including other files" -msgstr "Inkluzivi aliajn dosierojn" - -#: ../source/tutorials/packaging-projects.rst:389 -msgid "" -"The files listed above will be included automatically in your :term:`source " -"distribution `. If you want to control " -"what goes in this explicitly, see :ref:`Using MANIFEST.in`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:393 -msgid "" -"The final :term:`built distribution ` will have the " -"Python files in the discovered or listed Python packages. If you want to " -"control what goes here, such as to add data files, see :doc:`Including Data " -"Files ` from the :doc:`setuptools docs " -"`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:402 -msgid "Generating distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:404 -msgid "" -"The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the " -"Python Package Index and can be installed by :ref:`pip`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:408 -msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:422 -msgid "" -"If you have trouble installing these, see the :doc:`installing-packages` " -"tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:425 -msgid "" -"Now run this command from the same directory where :file:`pyproject.toml` is " -"located:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:439 -msgid "" -"This command should output a lot of text and once completed should generate " -"two files in the :file:`dist` directory:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:449 -msgid "" -"The ``tar.gz`` file is a :term:`source archive ` whereas the " -"``.whl`` file is a :term:`built distribution `. Newer :" -"ref:`pip` versions preferentially install built distributions, but will fall " -"back to source archives if needed. You should always upload a source archive " -"and provide built archives for the platforms your project is compatible " -"with. In this case, our example package is compatible with Python on any " -"platform so only one built distribution is needed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:458 -msgid "Uploading the distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:460 -msgid "Finally, it's time to upload your package to the Python Package Index!" -msgstr "Finfine, vi pretas alŝuti vian pakon al PyPI!" - -#: ../source/tutorials/packaging-projects.rst:462 -msgid "" -"The first thing you'll need to do is register an account on TestPyPI, which " -"is a separate instance of the package index intended for testing and " -"experimentation. It's great for things like this tutorial where we don't " -"necessarily want to upload to the real index. To register an account, go to " -"https://test.pypi.org/account/register/ and complete the steps on that page. " -"You will also need to verify your email address before you're able to upload " -"any packages. For more details, see :doc:`/guides/using-testpypi`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:470 -msgid "" -"To securely upload your project, you'll need a PyPI `API token`_. Create one " -"at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" " -"to \"Entire account\". **Don't close the page until you have copied and " -"saved the token — you won't see that token again.**" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:477 -msgid "" -"Now that you are registered, you can use :ref:`twine` to upload the " -"distribution packages. You'll need to install Twine:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:492 -msgid "" -"Once installed, run Twine to upload all of the archives under :file:`dist`:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:506 -msgid "" -"You will be prompted for a username and password. For the username, use " -"``__token__``. For the password, use the token value, including the ``pypi-" -"`` prefix." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:510 -msgid "After the command completes, you should see output similar to this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:523 -msgid "" -"Once uploaded your package should be viewable on TestPyPI, for example, " -"https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:528 -msgid "Installing your newly uploaded package" -msgstr "Instali vian nove alŝutitan pakon" - -#: ../source/tutorials/packaging-projects.rst:530 -msgid "" -"You can use :ref:`pip` to install your package and verify that it works. " -"Create a :ref:`virtual environment ` and install your package from TestPyPI:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:546 -msgid "Make sure to specify your username in the package name!" -msgstr "Certigu, ke vi indikas vian salutnomon en la nomo de la pako!" - -#: ../source/tutorials/packaging-projects.rst:548 -msgid "" -"pip should install the package from TestPyPI and the output should look " -"something like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:558 -msgid "" -"This example uses ``--index-url`` flag to specify TestPyPI instead of live " -"PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have " -"the same packages as the live PyPI, it's possible that attempting to install " -"dependencies may fail or install something unexpected. While our example " -"package doesn't have any dependencies, it's a good practice to avoid " -"installing dependencies when using TestPyPI." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:565 -msgid "" -"You can test that it was installed correctly by importing the package. Make " -"sure you're still in your virtual environment, then run Python:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:580 -msgid "and import the package:" -msgstr "kaj enportu la pakon:" - -#: ../source/tutorials/packaging-projects.rst:588 -msgid "" -"Note that the :term:`import package ` is ``example_package`` " -"regardless of what ``name`` you gave your :term:`distribution package " -"` in :file:`setup.cfg` or :file:`setup.py` (in this " -"case, ``example-pkg-YOUR-USERNAME-HERE``)." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:596 -msgid "" -"**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" -msgstr "**Gratulon, vi pakis kaj distribuis Python-projekton!** ✨ 🍰 ✨" - -#: ../source/tutorials/packaging-projects.rst:599 -msgid "" -"Keep in mind that this tutorial showed you how to upload your package to " -"Test PyPI, which isn't a permanent storage. The Test system occasionally " -"deletes packages and accounts. It is best to use TestPyPI for testing and " -"experiments like this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:604 -msgid "" -"When you are ready to upload a real package to the Python Package Index you " -"can do much the same as you did in this tutorial, but with these important " -"differences:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:608 -msgid "" -"Choose a memorable and unique name for your package. You don't have to " -"append your username as you did in the tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:610 -msgid "" -"Register an account on https://pypi.org - note that these are two separate " -"servers and the login details from the test server are not shared with the " -"main server." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:613 -msgid "" -"Use ``twine upload dist/*`` to upload your package and enter your " -"credentials for the account you registered on the real PyPI. Now that " -"you're uploading the package in production, you don't need to specify ``--" -"repository``; the package will upload to https://pypi.org/ by default." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:617 -msgid "" -"Install your package from the real PyPI using ``python3 -m pip install [your-" -"package]``." -msgstr "" -"Instalu vian pakon el la vera PyPI per ``python3 -m pip install [your-" -"package]``." - -#: ../source/tutorials/packaging-projects.rst:619 -msgid "" -"At this point if you want to read more on packaging Python libraries here " -"are some things you can do:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:622 -msgid "" -"Read more about using :ref:`setuptools` to package libraries in :doc:`/" -"guides/distributing-packages-using-setuptools`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:624 -msgid "Read about :doc:`/guides/packaging-binary-extensions`." -msgstr "Legu pri :doc:`/guides/packaging-binary-extensions`." - -#: ../source/tutorials/packaging-projects.rst:625 -msgid "" -"Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:" -"`hatch`, and :ref:`poetry`." -msgstr "" diff --git a/locales/es/LC_MESSAGES/messages.po b/locales/es/LC_MESSAGES/messages.po deleted file mode 100644 index 8086e8a58..000000000 --- a/locales/es/LC_MESSAGES/messages.po +++ /dev/null @@ -1,9293 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2013–2020, PyPA -# This file is distributed under the same license as the Python Packaging User Guide package. -# Adolfo Jayme Barrientos , 2021. -# meowmeowmeowcat , 2021. -msgid "" -msgstr "" -"Project-Id-Version: Python Packaging User Guide\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-08-26 12:32+0000\n" -"Last-Translator: Adolfo Jayme Barrientos \n" -"Language-Team: Spanish \n" -"Language: es\n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=UTF-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Plural-Forms: nplurals=2; plural=n != 1;\n" -"X-Generator: Weblate 4.8.1-dev\n" - -#: ../source/contribute.rst:5 -msgid "Contribute to this guide" -msgstr "Contribuya a esta guía" - -#: ../source/contribute.rst:7 -msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" -msgstr "" -"La |PyPUG| aprecia las contribuciones de cualquier tipo, entre los cuales se " -"incluyen:" - -#: ../source/contribute.rst:10 -msgid "Reading the guide and giving feedback" -msgstr "Leer la guía y brindar observaciones" - -#: ../source/contribute.rst:11 -msgid "Reviewing new contributions" -msgstr "Revisar contribuciones nuevas" - -#: ../source/contribute.rst:12 -msgid "Revising existing content" -msgstr "Revisar el contenido existente" - -#: ../source/contribute.rst:13 -msgid "Writing new content" -msgstr "Escribir contenido nuevo" - -#: ../source/contribute.rst:15 -msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." -msgstr "" - -#: ../source/contribute.rst:24 -msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." -msgstr "" -"Al contribuir a la |PyPUG|, se esperará de usted que se adhiera al `Código " -"de conducta`__ de la PSF." - -#: ../source/contribute.rst:31 -msgid "Documentation types" -msgstr "Tipos de documentación" - -#: ../source/contribute.rst:33 -msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." -msgstr "" -"Este proyecto se compone de cuatro tipos de documentación diferentes, cada " -"uno con finalidades específicas. Al proponer adiciones nuevas al proyecto, " -"seleccione el tipo de documentación apropiado." - -#: ../source/contribute.rst:38 -#: ../source/tutorials/index.rst:2 -msgid "Tutorials" -msgstr "Tutoriales" - -#: ../source/contribute.rst:40 -msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." -msgstr "" - -#: ../source/contribute.rst:47 -#: ../source/guides/index.rst:2 -msgid "Guides" -msgstr "Guías" - -#: ../source/contribute.rst:49 -msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." -msgstr "" - -#: ../source/contribute.rst:56 -#: ../source/discussions/index.rst:2 -msgid "Discussions" -msgstr "Debates" - -#: ../source/contribute.rst:58 -msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." -msgstr "" - -#: ../source/contribute.rst:63 -msgid "Specifications" -msgstr "Especificaciones" - -#: ../source/contribute.rst:65 -msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." -msgstr "" - -#: ../source/contribute.rst:73 -msgid "Building the guide locally" -msgstr "" - -#: ../source/contribute.rst:75 -msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" -msgstr "" - -#: ../source/contribute.rst:79 -msgid "`Nox `_. You can install or upgrade nox using ``pip``::" -msgstr "" - -#: ../source/contribute.rst:84 -msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." -msgstr "" - -#: ../source/contribute.rst:91 -msgid "To build the guide, run the following bash command in the source folder::" -msgstr "" - -#: ../source/contribute.rst:95 -msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." -msgstr "" - -#: ../source/contribute.rst:100 -msgid "You can build the guide and serve it via an HTTP server using the following command::" -msgstr "" - -#: ../source/contribute.rst:105 -msgid "The guide will be browsable via http://localhost:8000." -msgstr "Podrá explorar la guía a través de http://localhost:8000." - -#: ../source/contribute.rst:109 -msgid "Where the guide is deployed" -msgstr "" - -#: ../source/contribute.rst:111 -msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." -msgstr "" - -#: ../source/contribute.rst:117 -msgid "Style guide" -msgstr "Guía de estilo" - -#: ../source/contribute.rst:119 -msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." -msgstr "" - -#: ../source/contribute.rst:126 -msgid "Purpose" -msgstr "Propósito" - -#: ../source/contribute.rst:128 -msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." -msgstr "" - -#: ../source/contribute.rst:133 -msgid "Scope" -msgstr "Alcance" - -#: ../source/contribute.rst:135 -msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." -msgstr "" - -#: ../source/contribute.rst:138 -msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." -msgstr "" - -#: ../source/contribute.rst:146 -msgid "Audience" -msgstr "Audiencia" - -#: ../source/contribute.rst:148 -msgid "The audience of this guide is anyone who uses Python with packages." -msgstr "" -"La audiencia de esta guía es cualquier persona que utilice Python con " -"paquetes." - -#: ../source/contribute.rst:150 -msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." -msgstr "" -"No olvide que la comunidad de Python es grande y hospitalaria. Sus lectores " -"podrían no compartir su edad, su género, su formación o su cultura, pero " -"tienen el mismo derecho que usted a aprender sobre el empaquetamiento." - -#: ../source/contribute.rst:154 -msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." -msgstr "" -"Sobre todo, tenga en mente que no todas las personas que utilizan Python se " -"autodescriben como programadoras. La audiencia de esta guía incluye " -"astrónomos y pintores y estudiantes, no solo desarrolladores profesionales " -"de programas informáticos." - -#: ../source/contribute.rst:160 -msgid "Voice and tone" -msgstr "Voz y tono" - -#: ../source/contribute.rst:162 -msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." -msgstr "" -"Aunque posea todas las respuestas, al escribir esta guía procure utilizar un " -"tono de voz humilde y accesible." - -#: ../source/contribute.rst:165 -msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." -msgstr "" - -#: ../source/contribute.rst:170 -msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." -msgstr "" - -#: ../source/contribute.rst:177 -msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." -msgstr "" - -#: ../source/contribute.rst:184 -msgid "Conventions and mechanics" -msgstr "Convenciones y mecánicas" - -#: ../source/contribute.rst:192 -msgid "**Write to the reader**" -msgstr "**Escriba dirigiéndose a quien lee**" - -#: ../source/contribute.rst:187 -msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." -msgstr "" -"Al dar recomendaciones o pasos que seguir, diríjase de *usted* a la " -"audiencia lectora o utilice el modo imperativo." - -#: ../source/contribute.rst:0 -msgid "Wrong: To install it, the user runs…" -msgstr "Incorrecto: Para instalarlo, el usuario ejecuta…" - -#: ../source/contribute.rst:0 -msgid "Right: You can install it by running…" -msgstr "Correcto: Puede instalarlo ejecutando…" - -#: ../source/contribute.rst:0 -msgid "Right: To install it, run…" -msgstr "Correcto: Para instalarlo, ejecute…" - -#: ../source/contribute.rst:198 -msgid "**State assumptions**" -msgstr "" - -#: ../source/contribute.rst:195 -msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." -msgstr "" - -#: ../source/contribute.rst:203 -msgid "**Cross-reference generously**" -msgstr "" - -#: ../source/contribute.rst:201 -msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." -msgstr "" - -#: ../source/contribute.rst:213 -msgid "**Respect naming practices**" -msgstr "" - -#: ../source/contribute.rst:206 -msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: Pip uses…" -msgstr "Incorrecto: Pip utiliza…" - -#: ../source/contribute.rst:0 -msgid "Right: pip uses…" -msgstr "Correcto: pip utiliza…" - -#: ../source/contribute.rst:0 -msgid "Wrong: …hosted on github." -msgstr "Incorrecto: … se aloja en github." - -#: ../source/contribute.rst:0 -msgid "Right: …hosted on GitHub." -msgstr "Correcto: … se aloja en GitHub." - -#: ../source/contribute.rst:222 -msgid "**Use a gender-neutral style**" -msgstr "**Utilice un estilo que no marque géneros innecesariamente**" - -#: ../source/contribute.rst:216 -msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: A maintainer uploads the file. Then he…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then they…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then the maintainer…" -msgstr "" - -#: ../source/contribute.rst:234 -msgid "**Headings**" -msgstr "**Títulos**" - -#: ../source/contribute.rst:225 -msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." -msgstr "" - -#: ../source/contribute.rst:230 -msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: Things You Should Know About Python" -msgstr "Incorrecto: Cosas Que Debe Saber Acerca de Python" - -#: ../source/contribute.rst:0 -msgid "Right: Things you should know about Python" -msgstr "Correcto: Cosas que debe saber acerca de Python" - -#: ../source/contribute.rst:237 -msgid "**Numbers**" -msgstr "**Números**" - -#: ../source/contribute.rst:237 -msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:4 -msgid "Deploying Python applications" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Page Status" -msgstr "Estado de página" - -#: ../source/discussions/deploying-python-applications.rst:6 -#: ../source/guides/index-mirrors-and-caches.rst:7 -#: ../source/guides/installing-using-linux-tools.rst:7 -#: ../source/guides/packaging-binary-extensions.rst:7 -#: ../source/guides/supporting-multiple-python-versions.rst:7 -#: ../source/guides/supporting-windows-using-appveyor.rst:5 -msgid "Incomplete" -msgstr "Incompleta" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Last Reviewed" -msgstr "Última revisión" - -#: ../source/discussions/deploying-python-applications.rst:7 -msgid "2014-11-11" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:11 -#: ../source/discussions/install-requires-vs-requirements.rst:9 -#: ../source/guides/analyzing-pypi-package-downloads.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:22 -#: ../source/guides/index-mirrors-and-caches.rst:12 -#: ../source/guides/installing-scientific-packages.rst:9 -#: ../source/guides/packaging-binary-extensions.rst:17 -#: ../source/guides/supporting-multiple-python-versions.rst:12 -#: ../source/guides/supporting-windows-using-appveyor.rst:15 -#: ../source/overview.rst:23 -#: ../source/specifications/core-metadata.rst:38 -#: ../source/specifications/direct-url.rst:14 -#: ../source/tutorials/installing-packages.rst:23 -msgid "Contents" -msgstr "Contenido" - -#: ../source/discussions/deploying-python-applications.rst:14 -msgid "Overview" -msgstr "Visión de conjunto" - -#: ../source/discussions/deploying-python-applications.rst:18 -msgid "Supporting multiple hardware platforms" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:40 -msgid "OS packaging & installers" -msgstr "Empaquetamiento para sistemas operativos e instaladores" - -#: ../source/discussions/deploying-python-applications.rst:52 -msgid "Windows" -msgstr "Windows" - -#: ../source/discussions/deploying-python-applications.rst:61 -msgid "Pynsist" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:63 -msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:70 -msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:74 -msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:80 -msgid "Application bundles" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:91 -msgid "Configuration management" -msgstr "" - -#: ../source/discussions/index.rst:4 -msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:5 -msgid "install_requires vs requirements files" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:382 -msgid "install_requires" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:14 -msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:19 -msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:29 -msgid "Additionally, it's best practice to indicate any known lower or upper bounds." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:31 -msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:41 -msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:51 -msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:56 -msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:64 -#: ../source/tutorials/installing-packages.rst:460 -msgid "Requirements files" -msgstr "Archivos de requisitos" - -#: ../source/discussions/install-requires-vs-requirements.rst:66 -msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:69 -msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:73 -msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:78 -msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:84 -msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:90 -msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:6 -msgid "pip vs easy_install" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:9 -msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:14 -msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:22 -msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**pip**" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**easy_install**" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -msgid "Installs from :term:`Wheels `" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Yes" -msgstr "Sí" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:30 -#: ../source/discussions/pip-vs-easy-install.rst:32 -#: ../source/discussions/pip-vs-easy-install.rst:35 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:51 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "No" -msgstr "No" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Uninstall Packages" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Yes (``python -m pip uninstall``)" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Dependency Overrides" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Yes (:ref:`Requirements Files `)" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "List Installed Packages" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:38 -msgid ":pep:`438` Support" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Installation format" -msgstr "Formato de instalación" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "'Flat' packages with :file:`egg-info` metadata." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Encapsulated Egg format" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:44 -msgid "sys.path modification" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:48 -msgid "Installs from :term:`Eggs `" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "`pylauncher support`_" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "Yes [1]_" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:54 -msgid ":ref:`Multi-version Installs`" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Exclude scripts during install" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "per project index" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Only in virtualenv" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Yes, via setup.cfg" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:68 -msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:5 -msgid "Wheel vs Egg" -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:7 -msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:11 -msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:14 -msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:17 -msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:20 -msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:22 -msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:26 -msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:31 -msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:34 -msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:38 -msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:41 -msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:47 -msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." -msgstr "" - -#: ../source/glossary.rst:3 -msgid "Glossary" -msgstr "" - -#: ../source/glossary.rst:8 -msgid "Binary Distribution" -msgstr "" - -#: ../source/glossary.rst:11 -msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." -msgstr "" - -#: ../source/glossary.rst:14 -msgid "Built Distribution" -msgstr "" - -#: ../source/glossary.rst:17 -msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." -msgstr "" - -#: ../source/glossary.rst:26 -msgid "Distribution Package" -msgstr "" - -#: ../source/glossary.rst:29 -msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." -msgstr "" - -#: ../source/glossary.rst:34 -msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." -msgstr "" - -#: ../source/glossary.rst:41 -msgid "Egg" -msgstr "" - -#: ../source/glossary.rst:44 -msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" -msgstr "" - -#: ../source/glossary.rst:49 -msgid "Extension Module" -msgstr "" - -#: ../source/glossary.rst:52 -msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." -msgstr "" - -#: ../source/glossary.rst:59 -msgid "Known Good Set (KGS)" -msgstr "" - -#: ../source/glossary.rst:62 -msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." -msgstr "" - -#: ../source/glossary.rst:68 -msgid "Import Package" -msgstr "" - -#: ../source/glossary.rst:71 -msgid "A Python module which can contain other modules or recursively, other packages." -msgstr "" - -#: ../source/glossary.rst:74 -msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." -msgstr "" - -#: ../source/glossary.rst:78 -msgid "Module" -msgstr "" - -#: ../source/glossary.rst:81 -msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." -msgstr "" - -#: ../source/glossary.rst:84 -msgid "Package Index" -msgstr "" - -#: ../source/glossary.rst:87 -msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." -msgstr "" - -#: ../source/glossary.rst:90 -msgid "Per Project Index" -msgstr "" - -#: ../source/glossary.rst:93 -msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." -msgstr "" - -#: ../source/glossary.rst:97 -msgid "Project" -msgstr "" - -#: ../source/glossary.rst:100 -msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." -msgstr "" - -#: ../source/glossary.rst:104 -msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." -msgstr "" - -#: ../source/glossary.rst:110 -msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." -msgstr "" - -#: ../source/glossary.rst:115 -msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." -msgstr "" - -#: ../source/glossary.rst:121 -msgid "Pure Module" -msgstr "" - -#: ../source/glossary.rst:124 -msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." -msgstr "" - -#: ../source/glossary.rst:127 -msgid "Python Packaging Authority (PyPA)" -msgstr "" - -#: ../source/glossary.rst:130 -msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." -msgstr "" - -#: ../source/glossary.rst:139 -msgid "Python Package Index (PyPI)" -msgstr "" - -#: ../source/glossary.rst:142 -msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." -msgstr "" - -#: ../source/glossary.rst:145 -msgid "pypi.org" -msgstr "" - -#: ../source/glossary.rst:148 -msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." -msgstr "" - -#: ../source/glossary.rst:152 -msgid "pyproject.toml" -msgstr "" - -#: ../source/glossary.rst:155 -msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." -msgstr "" - -#: ../source/glossary.rst:157 -msgid "Release" -msgstr "" - -#: ../source/glossary.rst:160 -msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." -msgstr "" - -#: ../source/glossary.rst:163 -msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." -msgstr "" - -#: ../source/glossary.rst:168 -msgid "Requirement" -msgstr "" - -#: ../source/glossary.rst:171 -msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." -msgstr "" - -#: ../source/glossary.rst:177 -msgid "Requirement Specifier" -msgstr "" - -#: ../source/glossary.rst:180 -msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" -msgstr "" - -#: ../source/glossary.rst:187 -msgid "Requirements File" -msgstr "Archivo de requisitos" - -#: ../source/glossary.rst:190 -msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." -msgstr "" - -#: ../source/glossary.rst:194 -#: ../source/guides/distributing-packages-using-setuptools.rst:56 -msgid "setup.py" -msgstr "" - -#: ../source/glossary.rst:195 -#: ../source/guides/distributing-packages-using-setuptools.rst:77 -msgid "setup.cfg" -msgstr "" - -#: ../source/glossary.rst:198 -msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." -msgstr "" - -#: ../source/glossary.rst:201 -msgid "Source Archive" -msgstr "" - -#: ../source/glossary.rst:204 -msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:208 -msgid "Source Distribution (or \"sdist\")" -msgstr "" - -#: ../source/glossary.rst:211 -msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:216 -msgid "System Package" -msgstr "Paquete de sistema" - -#: ../source/glossary.rst:219 -msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." -msgstr "" -"Un paquete provisto en un formato nativo del sistema operativo, por ejemplo, " -"un archivo de RPM o de APT." - -#: ../source/glossary.rst:222 -msgid "Version Specifier" -msgstr "" - -#: ../source/glossary.rst:225 -msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." -msgstr "" - -#: ../source/glossary.rst:231 -msgid "Virtual Environment" -msgstr "Entorno virtual" - -#: ../source/glossary.rst:234 -msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/glossary.rst:238 -msgid "Wheel" -msgstr "" - -#: ../source/glossary.rst:241 -msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." -msgstr "" - -#: ../source/glossary.rst:244 -msgid "Working Set" -msgstr "" - -#: ../source/glossary.rst:247 -msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:3 -msgid "Analyzing PyPI package downloads" -msgstr "Análisis de las descargas de los paquetes de PyPI" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:5 -msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:15 -#: ../source/guides/supporting-windows-using-appveyor.rst:18 -msgid "Background" -msgstr "Trasfondo" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:17 -msgid "PyPI does not display download statistics for a number of reasons: [#]_" -msgstr "" -"Existen varias razones por las cuales PyPI no muestra estadísticas de " -"descargas: [#]_" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:19 -msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:24 -msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:27 -msgid "``pip``'s download cache (lowers download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:28 -msgid "Internal or unofficial mirrors (can both raise or lower download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:29 -msgid "Packages not hosted on PyPI (for comparisons sake)" -msgstr "Paquetes no hospedados en PyPI (para comparar)" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:30 -msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:32 -msgid "Known historical data quality issues (lowers download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:34 -msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:38 -msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:43 -msgid "Public dataset" -msgstr "Conjunto de datos público" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:45 -msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:50 -msgid "Getting set up" -msgstr "Puesta en marcha" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:52 -msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:58 -msgid "Navigate to the `BigQuery web UI`_." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:59 -msgid "Create a new project." -msgstr "Cree un proyecto nuevo." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:60 -msgid "Enable the `BigQuery API `__." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:63 -msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:69 -msgid "Data schema" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:71 -msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -msgid "Column" -msgstr "Columna" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/guides/using-manifest-in.rst:67 -#: ../source/specifications/core-metadata.rst:185 -msgid "Description" -msgstr "Descripción" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/specifications/direct-url.rst:226 -msgid "Examples" -msgstr "Ejemplos" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "timestamp" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "Date and time" -msgstr "Fecha y hora" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "``2020-03-09 00:33:03 UTC``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "file.project" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "Project name" -msgstr "Nombre de proyecto" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "``pipenv``, ``nose``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "file.version" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "Package version" -msgstr "Versión del paquete" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "``0.1.6``, ``1.4.2``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "details.installer.name" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "Installer" -msgstr "Instalador" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "pip, `bandersnatch`_" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "details.python" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "Python version" -msgstr "Versión de Python" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "``2.7.12``, ``3.6.4``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:93 -msgid "Useful queries" -msgstr "Consultas prácticas" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:95 -msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:97 -msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:102 -msgid "Counting package downloads" -msgstr "Contar las descargas del paquete" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:104 -msgid "The following query counts the total number of downloads for the project \"pytest\"." -msgstr "" -"La consulta siguiente devuelve el recuento total de descargas para el " -"proyecto «pytest»." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:119 -#: ../source/guides/analyzing-pypi-package-downloads.rst:140 -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "num_downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:121 -msgid "26190085" -msgstr "26190085" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:124 -msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:142 -msgid "24334215" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:146 -msgid "Package downloads over time" -msgstr "Descargas del paquete conforme avanza el tiempo" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:148 -msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -msgid "month" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "1956741" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "2018-01-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2344692" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2017-12-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "1730398" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "2017-11-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2047310" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2017-10-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "1744443" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "2017-09-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "1916952" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "2017-08-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:184 -msgid "Python versions over time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:186 -msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "python" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "3.7" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "18051328726" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "3.6" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "9635067203" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "3.8" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "7781904681" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "2.7" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "6381252241" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "null" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "2026630299" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "3.5" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "1894153540" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:221 -msgid "Caveats" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:223 -msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:231 -msgid "Additional tools" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:233 -msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:237 -msgid "``google-cloud-bigquery``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:239 -msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:267 -msgid "``pypinfo``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:269 -msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:273 -msgid "Install `pypinfo`_ using pip." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:279 -msgid "Usage:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:295 -msgid "``pandas-gbq``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:297 -msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:301 -#: ../source/specifications/binary-distribution-format.rst:459 -msgid "References" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:303 -msgid "`PyPI Download Counts deprecation email `__" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:304 -msgid "`PyPI BigQuery dataset announcement email `__" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:3 -msgid "Creating and discovering plugins" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:5 -msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:10 -msgid "There are three major approaches to doing automatic plugin discovery:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:12 -msgid "`Using naming convention`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:13 -msgid "`Using namespace packages`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:14 -msgid "`Using package metadata`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:18 -msgid "Using naming convention" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:20 -msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:38 -msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:48 -msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:59 -msgid "Using namespace packages" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:61 -msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:89 -msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:101 -msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:115 -msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:121 -msgid "Using package metadata" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:123 -msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:128 -msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:139 -msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:154 -msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:163 -msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:166 -msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:170 -msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:5 -msgid "Packaging and distributing projects" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:7 -msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:11 -msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:15 -msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:25 -msgid "Requirements for packaging and distributing" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:26 -msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:29 -msgid "Install \"twine\" [1]_:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:43 -msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:49 -msgid "Configuring your project" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:53 -msgid "Initial files" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:58 -msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:63 -msgid ":file:`setup.py` serves two primary functions:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:65 -msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:71 -msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:79 -msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:86 -msgid "README.rst / README.md" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:88 -msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:95 -msgid "For an example, see `README.md `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:99 -msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:108 -msgid "MANIFEST.in" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:110 -msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:115 -msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:119 -msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:122 -msgid "LICENSE.txt" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:124 -msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:130 -msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:135 -msgid "" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:137 -msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:141 -msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:149 -msgid "setup() args" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:151 -msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:155 -msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:164 -msgid "name" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:170 -msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:174 -msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:176 -msgid "Start & end with an ASCII letter or digit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:178 -msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:190 -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "version" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:196 -msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:200 -msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:203 -msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:206 -msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:214 -msgid "description" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:222 -msgid "Give a short and long description for your project." -msgstr "Brinde una descripción breve y una larga del proyecto." - -#: ../source/guides/distributing-packages-using-setuptools.rst:224 -msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:229 -msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:235 -msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:245 -msgid "url" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:252 -msgid "Give a homepage URL for your project." -msgstr "Proporcione un URL de página principal del proyecto." - -#: ../source/guides/distributing-packages-using-setuptools.rst:256 -msgid "author" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:263 -msgid "Provide details about the author." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:267 -msgid "license" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:273 -msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:279 -msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:287 -msgid "classifiers" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:316 -msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:319 -msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:327 -msgid "keywords" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:333 -msgid "List keywords that describe your project." -msgstr "Añada palabras clave que describan su proyecto." - -#: ../source/guides/distributing-packages-using-setuptools.rst:337 -msgid "project_urls" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:349 -msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:355 -msgid "packages" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:361 -msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:370 -msgid "py_modules" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:376 -msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:388 -msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:392 -msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:398 -msgid "python_requires" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:400 -msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:407 -msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:412 -msgid "And so on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:416 -msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:422 -msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:431 -msgid "package_data" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:440 -msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:445 -msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:449 -msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:457 -msgid "data_files" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:463 -msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:469 -msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:479 -msgid "For more information see the distutils section on `Installing Additional Files `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:484 -msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:491 -msgid "scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:493 -msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:500 -msgid "entry_points" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:509 -msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:512 -msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:516 -msgid "The most commonly used entry point is \"console_scripts\" (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:521 -msgid "console_scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:531 -msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:538 -msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:545 -msgid "Choosing a versioning scheme" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:548 -msgid "Standards compliance for interoperability" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:550 -msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:556 -msgid "Here are some examples of compliant version numbers::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:567 -msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:573 -msgid "Scheme choices" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:576 -msgid "Semantic versioning (preferred)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:578 -msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:582 -msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:585 -msgid "MAJOR version when they make incompatible API changes," -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:586 -msgid "MINOR version when they add functionality in a backwards-compatible manner, and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:587 -msgid "MAINTENANCE version when they make backwards-compatible bug fixes." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:589 -msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:594 -msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:598 -msgid "Date based versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:600 -msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:604 -msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:607 -msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:611 -msgid "Serial versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:613 -msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:616 -msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:621 -msgid "Hybrid schemes" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:623 -msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:629 -msgid "Pre-release versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:631 -msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:634 -msgid "zero or more dev releases (denoted with a \".devN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:635 -msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:636 -msgid "zero or more beta releases (denoted with a \".bN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:637 -msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:639 -msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:644 -msgid "Local version identifiers" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:646 -msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:653 -msgid "A local version identifier takes the form ``+``. For example::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:661 -msgid "Working in \"development mode\"" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:663 -msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:667 -msgid "Assuming you're in the root of your project directory, then run:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:674 -msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:680 -msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:688 -msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:692 -msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:697 -msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:701 -msgid "Lastly, if you don't want to install any dependencies at all, you can run::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:706 -msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:713 -msgid "Packaging your project" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:715 -msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:720 -msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:737 -msgid "Source distributions" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:739 -msgid "Minimally, you should create a :term:`Source Distribution `:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:755 -msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:763 -msgid "Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:765 -msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:770 -msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:773 -msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:776 -msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:785 -msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:792 -msgid "Pure Python Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:794 -msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:797 -#: ../source/guides/distributing-packages-using-setuptools.rst:826 -msgid "To build the wheel:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:811 -msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:815 -msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:821 -msgid "Platform Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:823 -msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:841 -msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:847 -msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:855 -msgid "Uploading your Project to PyPI" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:857 -msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:861 -msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:866 -msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:871 -msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:877 -msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:888 -msgid "Create an account" -msgstr "Crear cuenta" - -#: ../source/guides/distributing-packages-using-setuptools.rst:890 -msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:894 -msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:897 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:901 -msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:904 -msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:913 -msgid "**Be aware that this stores your token in plaintext.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:915 -#: ../source/guides/migrating-to-pypi-org.rst:70 -#: ../source/guides/migrating-to-pypi-org.rst:109 -#: ../source/guides/using-testpypi.rst:83 -msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:921 -msgid "Upload your distributions" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:923 -msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:926 -msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:930 -msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:937 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:944 -#: ../source/tutorials/installing-packages.rst:663 -msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:950 -msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:5 -msgid "Dropping support for older Python versions" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:7 -msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:9 -msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:12 -msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:14 -msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:17 -msgid "Requirements" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:19 -msgid "This workflow requires that:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:21 -msgid "The publisher is using the latest version of :ref:`setuptools`," -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:22 -msgid "The latest version of :ref:`twine` is used to upload the package," -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:23 -msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:26 -msgid "Dealing with the universal wheels" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:28 -msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:36 -msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:48 -msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:53 -msgid "Defining the Python version required" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:56 -msgid "1. Download the newest version of Setuptools" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:58 -msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:60 -msgid "Steps:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:74 -msgid "`setuptools` version should be above 24.0.0." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:77 -msgid "2. Specify the version ranges for supported Python distributions" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:79 -msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:81 -#: ../source/specifications/core-metadata.rst:139 -#: ../source/specifications/core-metadata.rst:463 -#: ../source/specifications/core-metadata.rst:487 -#: ../source/specifications/core-metadata.rst:527 -#: ../source/specifications/core-metadata.rst:550 -#: ../source/specifications/core-metadata.rst:583 -#: ../source/specifications/core-metadata.rst:693 -#: ../source/specifications/core-metadata.rst:722 -msgid "Examples::" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:86 -msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:101 -msgid "3. Validating the Metadata before publishing" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:103 -msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:105 -msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:108 -msgid "You can see the contents of the generated file like this::" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:112 -msgid "Validate that the following is in place, before publishing the package:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:114 -msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:115 -msgid "The Requires-Python field is set and matches your specification in setup.py." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:118 -msgid "4. Using Twine to publish" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:120 -msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:122 -msgid "Make sure you are using the newest version of Twine, at least 1.9." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:125 -msgid "Dropping a Python release" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:127 -msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:129 -msgid "It must be done in this order for the automated fallback to work." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:131 -msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:133 -msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:5 -msgid "Hosting your own simple repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:8 -msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:13 -msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:29 -msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:35 -msgid "\"Manual\" repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:37 -msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:51 -msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:58 -msgid "For complete documentation of the simple repository protocol, see :pep:`503`." -msgstr "" - -#: ../source/guides/index.rst:8 -#: ../source/guides/index.rst:8 -msgid "Installing Packages:" -msgstr "" - -#: ../source/guides/index.rst:20 -#: ../source/guides/index.rst:20 -msgid "Building and Publishing Projects:" -msgstr "" - -#: ../source/guides/index.rst:38 -#: ../source/guides/index.rst:38 -msgid "Miscellaneous:" -msgstr "" - -#: ../source/guides/index.rst:4 -msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:5 -msgid "Package index mirrors and caches" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:8 -#: ../source/guides/supporting-multiple-python-versions.rst:8 -msgid "2014-12-24" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:14 -msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:17 -msgid "Three options are available in this area:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:19 -msgid "pip provides local caching options," -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:20 -msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:22 -msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:27 -msgid "Caching with pip" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:29 -msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:32 -msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:36 -msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:45 -msgid "Caching with devpi" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:47 -msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:55 -msgid "Complete mirror with bandersnatch" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:57 -msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:63 -msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:5 -msgid "Installing scientific packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:11 -msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:16 -msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:22 -msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:29 -msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:35 -msgid "Building from source" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:37 -msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:45 -msgid "Linux distribution packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:47 -msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:51 -msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:57 -msgid "Windows installers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:59 -msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:64 -msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:67 -msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:73 -msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:79 -msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:86 -msgid "macOS installers and package managers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:88 -msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:92 -msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:99 -msgid "SciPy distributions" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:101 -msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:105 -msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:109 -#: ../source/key_projects.rst:596 -msgid "Spack" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:110 -msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:119 -msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:128 -msgid "The conda cross-platform package manager" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:130 -msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:136 -msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 -msgid "Installing stand alone command line tools" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 -msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 -msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 -msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 -msgid "pipx only works with Python 3.6+." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 -msgid "``pipx`` is installed with ``pip``:" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 -msgid "You may need to restart your terminal for the path updates to take effect." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 -msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 -#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 -msgid "For example" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 -msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 -msgid "To upgrade or uninstall the package" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 -msgid "``pipx`` can be upgraded or uninstalled with pip" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 -msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 -msgid "To see the full list of commands ``pipx`` offers, run" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 -msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:5 -msgid "Installing pip/setuptools/wheel with Linux Package Managers" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:8 -msgid "2015-09-17" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:11 -msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:14 -msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:18 -msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:25 -msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:32 -msgid "Fedora" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:34 -msgid "Fedora 21:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:36 -#: ../source/guides/installing-using-linux-tools.rst:45 -#: ../source/guides/installing-using-linux-tools.rst:124 -#: ../source/guides/installing-using-linux-tools.rst:138 -#: ../source/guides/installing-using-linux-tools.rst:158 -msgid "Python 2::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:41 -msgid "Python 3: ``sudo yum install python3 python3-wheel``" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:43 -msgid "Fedora 22:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:50 -msgid "Python 3: ``sudo dnf install python3 python3-wheel``" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:53 -msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:63 -msgid "CentOS/RHEL" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:65 -msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:68 -msgid "To install pip and wheel for the system Python, there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:70 -msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:77 -msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:81 -msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:85 -msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:92 -msgid "To additionally upgrade setuptools, run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:97 -msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:101 -msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:104 -msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:106 -msgid "For CentOS, see here: https://www.softwarecollections.org/en/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:108 -msgid "Be aware that collections may not contain the most recent versions." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:110 -msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:116 -msgid "For example, for Python 3.4 on CentOS7/RHEL7::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:122 -msgid "openSUSE" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:129 -#: ../source/guides/installing-using-linux-tools.rst:143 -#: ../source/guides/installing-using-linux-tools.rst:162 -msgid "Python 3::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:135 -msgid "Debian/Ubuntu" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:150 -msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:156 -msgid "Arch Linux" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:168 -msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 -msgid "Installing packages using pip and virtual environments" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 -msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 -msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 -msgid "Installing pip" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 -msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 -msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 -msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 -msgid "Afterwards, you should have the newest pip installed in your user site:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 -msgid "The Python installers for Windows include pip. You should be able to access pip using:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 -msgid "You can make sure that pip is up-to-date by running:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 -msgid "Installing virtualenv" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 -msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 -msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 -msgid "Creating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 -msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 -msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 -msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 -msgid "venv will create a virtual Python installation in the ``env`` folder." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 -msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 -msgid "Activating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 -msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 -msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 -msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 -msgid "Leaving the virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 -msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 -msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 -msgid "Installing packages" -msgstr "Instalación de paquetes" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 -msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 -msgid "pip should download requests and all of its dependencies and install them:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 -msgid "Installing specific versions" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 -msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 -msgid "To install the latest ``2.x`` release of requests:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 -msgid "To install pre-release versions of packages, use the ``--pre`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 -msgid "Installing extras" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 -msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 -msgid "Installing from source" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 -msgid "pip can install a package directly from source, for example:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 -msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 -msgid "Installing from version control systems" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 -msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 -msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 -#: ../source/tutorials/installing-packages.rst:569 -msgid "Installing from local archives" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 -msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 -msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 -msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 -msgid "Using other package indexes" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 -msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 -msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 -#: ../source/tutorials/installing-packages.rst:389 -msgid "Upgrading packages" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 -msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 -msgid "Using requirements files" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 -msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 -msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 -msgid "Freezing dependencies" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 -msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 -msgid "Which will output a list of package specifiers such as:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 -msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:2 -msgid "Making a PyPI-friendly README" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:4 -msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:9 -msgid "Creating a README file" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:11 -msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:13 -msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:16 -msgid "plain text" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:17 -msgid "`reStructuredText `_ (without Sphinx extensions)" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:18 -msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:21 -msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:25 -msgid "Including your README in your package's metadata" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:27 -msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:33 -msgid ":ref:`description-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:34 -msgid ":ref:`description-content-type-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:36 -msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:39 -msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:45 -msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:60 -msgid "The minimum required versions of the respective tools are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:62 -msgid "``setuptools >= 38.6.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:63 -msgid "``wheel >= 0.31.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:64 -msgid "``twine >= 1.11.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:66 -msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:72 -msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:95 -msgid "Validating reStructuredText markup" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:97 -msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:100 -msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:105 -msgid "You can check your README for markup errors before uploading as follows:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:107 -msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:122 -msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:125 -msgid "Run ``twine check`` on the sdist and wheel::" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:129 -msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:4 -msgid "Migrating to PyPI.org" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:6 -msgid ":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``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:12 -msgid "Publishing releases" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:14 -msgid "``pypi.org`` is the default upload platform as of September 2016." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:16 -msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:19 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:22 -msgid "The default upload settings switched to ``pypi.org`` in the following versions:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:24 -msgid "``twine`` 1.8.0" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:25 -msgid "``setuptools`` 27.0.0" -msgstr "``setuptools`` 27.0.0" - -#: ../source/guides/migrating-to-pypi-org.rst:26 -msgid "Python 2.7.13 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:27 -msgid "Python 3.4.6 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:28 -msgid "Python 3.5.3 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:29 -msgid "Python 3.6.0 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:31 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:48 -msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:51 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:67 -msgid "(``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.)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:73 -msgid "Registering package names & metadata" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:75 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:79 -msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:84 -msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:89 -#: ../source/guides/using-testpypi.rst:5 -msgid "Using TestPyPI" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:91 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:113 -msgid "Registering new user accounts" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:115 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:121 -msgid "Browsing packages" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:123 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:130 -msgid "Downloading packages" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:132 -msgid "``pypi.org`` is the default host for downloading packages." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:135 -msgid "Managing published packages and releases" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:137 -msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:5 -msgid "Multi-version installs" -msgstr "" - -#: ../source/guides/multi-version-installs.rst:8 -msgid "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``)." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:13 -msgid "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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:19 -msgid "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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:31 -msgid "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 ``python -c ''`` to invoke the application's main entry point directly." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:38 -msgid "Refer to the `pkg_resources documentation `__ for more details." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:5 -msgid "Packaging binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:8 -msgid "2013-12-08" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:10 -msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:20 -msgid "An overview of binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:23 -msgid "Use cases" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:25 -msgid "The typical use cases for binary extensions break down into just three conventional categories:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:28 -msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:39 -msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:47 -msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:56 -msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:61 -msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:71 -msgid "Disadvantages" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:73 -msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:80 -msgid "This means that binary extensions:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:82 -msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:85 -msgid "may not be compatible with different builds of the CPython reference interpreter" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:88 -msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:91 -msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:96 -msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:101 -msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:108 -msgid "Alternatives to handcoded accelerator modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:110 -msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:115 -msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:122 -msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:132 -msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:141 -msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:150 -msgid "Alternatives to handcoded wrapper modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:152 -msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:158 -msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:162 -msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:168 -msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:175 -msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:181 -msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:185 -msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:189 -msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:203 -msgid "Alternatives for low level system access" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:205 -msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:213 -msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:222 -msgid "Implementing binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:224 -msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:241 -msgid "Building binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:244 -msgid "Building extensions for multiple platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:246 -msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:256 -msgid "Binary extensions for Windows" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:258 -msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:263 -msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:269 -msgid "To set up a build environment for binary extensions, the steps are as follows:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:271 -msgid "For Python 2.7" -msgstr "Para Python 2.7" - -#: ../source/guides/packaging-binary-extensions.rst:273 -msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:276 -msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:278 -#: ../source/guides/packaging-binary-extensions.rst:288 -#: ../source/guides/packaging-binary-extensions.rst:295 -msgid "Done." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:280 -msgid "For Python 3.4" -msgstr "Para Python 3.4" - -#: ../source/guides/packaging-binary-extensions.rst:282 -msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:285 -msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:287 -msgid "Set DISTUTILS_USE_SDK=1" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:290 -msgid "For Python 3.5" -msgstr "Para Python 3.5" - -#: ../source/guides/packaging-binary-extensions.rst:292 -msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:297 -msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:301 -msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:305 -msgid "Binary extensions for Linux" -msgstr "Extensiones binarias para Linux" - -#: ../source/guides/packaging-binary-extensions.rst:307 -msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:313 -msgid "Binary extensions for macOS" -msgstr "Extensiones binarias para macOS" - -#: ../source/guides/packaging-binary-extensions.rst:315 -msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:325 -msgid "Publishing binary extensions" -msgstr "Publicación de extensiones binarias" - -#: ../source/guides/packaging-binary-extensions.rst:327 -msgid "For interim guidance on this topic, see the discussion in `this issue `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:343 -msgid "Additional resources" -msgstr "Recursos adicionales" - -#: ../source/guides/packaging-binary-extensions.rst:345 -msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:352 -msgid "Cross-platform wheel generation with scikit-build" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:354 -msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:362 -msgid "Introduction to C/C++ extension modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:364 -msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:367 -msgid "`What are (c)python extension modules? `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:368 -msgid "`Releasing the gil `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:369 -msgid "`Writing cpython extension modules using C++ `_" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:3 -msgid "Packaging namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:5 -msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:24 -msgid "And you use this package in your code like so::" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:29 -msgid "Then you can break these sub-packages into two separate distributions:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:46 -msgid "Each sub-package can now be separately installed, used, and versioned." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:48 -msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:58 -msgid "Creating a namespace package" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:60 -msgid "There are currently three different approaches to creating namespace packages:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:62 -msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:66 -msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:69 -msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:73 -msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:80 -msgid "Native namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:82 -msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:97 -msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:102 -msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:117 -msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:123 -msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:129 -msgid "pkgutil-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:131 -msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:136 -msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:148 -#: ../source/guides/packaging-namespace-packages.rst:194 -msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:155 -#: ../source/guides/packaging-namespace-packages.rst:201 -msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:160 -msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:171 -msgid "pkg_resources-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:173 -msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:182 -msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:206 -msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:216 -msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:223 -msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:237 -msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 -msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 -msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 -msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 -msgid "Saving credentials on GitHub" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 -msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 -msgid "Let's begin! 🚀" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 -msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 -msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 -msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 -msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 -msgid "Creating a workflow definition" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 -msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 -msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 -msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 -msgid "Defining a workflow job environment" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 -msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 -msgid "Checking out the project and building distributions" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 -msgid "Then, add the following under the ``build-n-publish`` section:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 -msgid "This will download your repository into the CI runner and then install and activate Python 3.7." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 -msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 -msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 -msgid "So add this to the steps list:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 -msgid "Publishing the distribution to PyPI and TestPyPI" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 -msgid "Finally, add the following steps at the end:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 -msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 -msgid "That's all, folks!" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 -msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:5 -msgid "Single-sourcing the package version" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:8 -msgid "There are many techniques to maintain a single source of truth for the version number of your project:" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:11 -msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:38 -msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:47 -msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:52 -msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:55 -msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:58 -msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:65 -msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:76 -msgid "Example using this technique: `warehouse `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:78 -msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:86 -msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:91 -msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:95 -msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:110 -msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:114 -msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:128 -msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:134 -msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:138 -msgid "Example using this technique: `setuptools `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:141 -msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:155 -msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:161 -msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:5 -msgid "Supporting multiple Python versions" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:37 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:43 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:49 -msgid "Automated testing and continuous integration" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:51 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:56 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:60 -msgid "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:" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:66 -msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:69 -msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:80 -msgid "Both `Travis CI`_ 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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:85 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:89 -msgid "Tools for single-source Python packages" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:91 -msgid "`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_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:100 -msgid "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" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:107 -msgid "a Python 2 (by syntax) module in a Python 3 project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:108 -msgid "a Python 3 (by syntax) module in a *Python 2* project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:110 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:117 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:124 -msgid "What's in which Python?" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:126 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:3 -msgid "Supporting Windows using Appveyor" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:6 -msgid "2015-12-03" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:8 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:20 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:24 -msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:30 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:38 -msgid "Setting up" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:40 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:45 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:49 -msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:54 -msgid "Adding Appveyor support to your project" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:56 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:61 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:69 -msgid "appveyor.yml" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:75 -msgid "This file can be downloaded from `here `__." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:77 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:80 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:88 -msgid "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``)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:94 -msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:97 -msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:100 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:109 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:114 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:119 -msgid "Support script" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:121 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:126 -msgid "`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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:133 -msgid "You can simply download the batch file and include it in your project unchanged." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:137 -msgid "Access to the built wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:139 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:147 -msgid "Additional notes" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:150 -msgid "Testing with tox" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:152 -msgid "Many projects use the `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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:156 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:160 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:165 -msgid "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" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:170 -msgid "``DISTUTILS_USE_SDK``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:171 -msgid "``MSSdk``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:172 -msgid "``INCLUDE``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:173 -msgid "``LIB``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:175 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:181 -msgid "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 Travis or 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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:188 -msgid "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``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:192 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:197 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:203 -msgid "Automatically uploading wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:205 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:210 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:216 -msgid "External dependencies" -msgstr "Dependencias externas" - -#: ../source/guides/supporting-windows-using-appveyor.rst:218 -msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:221 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:230 -msgid "Support scripts" -msgstr "Secuencias de apoyo" - -#: ../source/guides/supporting-windows-using-appveyor.rst:232 -msgid "For reference, the SDK setup support script is listed here:" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:234 -msgid "``appveyor-sample/build.cmd``" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:5 -msgid "Tool recommendations" -msgstr "Recomendaciones de herramientas" - -#: ../source/guides/tool-recommendations.rst:7 -msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:12 -msgid "Application dependency management" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:14 -msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:18 -msgid "When ``pipenv`` does not meet your use case, consider other tools like:" -msgstr "" -"Si ``pipenv`` no se ajusta a sus necesidades, considere utilizar otras " -"herramientas, como:" - -#: ../source/guides/tool-recommendations.rst:20 -msgid ":ref:`pip`" -msgstr ":ref:`pip`" - -#: ../source/guides/tool-recommendations.rst:22 -msgid "`pip-tools `_" -msgstr "`pip-tools `_" - -#: ../source/guides/tool-recommendations.rst:24 -msgid "`Poetry `_" -msgstr "`Poetry `_" - -#: ../source/guides/tool-recommendations.rst:27 -msgid "Installation tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:29 -msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:34 -msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:37 -msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:40 -msgid ":ref:`buildout`: primarily focused on the web development community" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:42 -msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:47 -msgid "Packaging tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:49 -msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:52 -msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:56 -msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:61 -msgid "Publishing platform migration" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:63 -msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:67 -msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:72 -msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:77 -msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:82 -msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:88 -msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:93 -msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:102 -msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:107 -msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:5 -msgid "Including files in source distributions with ``MANIFEST.in``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:7 -msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:17 -msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:22 -msgid "How files are included in an sdist" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:24 -msgid "The following files are included in a source distribution by default:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:26 -msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:28 -msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:30 -msgid "scripts specified by the ``scripts`` ``setup()`` argument" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:31 -msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:33 -msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:35 -msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:37 -msgid "all files matching the pattern :file:`test/test*.py`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:38 -msgid ":file:`setup.py` (or whatever you called your setup script)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:39 -msgid ":file:`setup.cfg`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:40 -msgid ":file:`README`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:41 -msgid ":file:`README.txt`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:42 -msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:43 -msgid ":file:`README.md` (setuptools 36.4.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:44 -msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:45 -msgid ":file:`MANIFEST.in`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:47 -msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:52 -msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:60 -msgid ":file:`MANIFEST.in` commands" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:62 -msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:67 -msgid "Command" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:69 -msgid ":samp:`include {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:69 -msgid "Add all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid ":samp:`exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid "Remove all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid ":samp:`global-include {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid "Add all files anywhere in the source tree matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid ":samp:`global-exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid "Remove all files anywhere in the source tree matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid ":samp:`graft {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid "Add all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid ":samp:`prune {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid "Remove all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:79 -msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:87 -msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:91 -msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:95 -msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:101 -msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." -msgstr "" - -#: ../source/guides/using-testpypi.rst:7 -msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" -msgstr "" - -#: ../source/guides/using-testpypi.rst:13 -msgid "Registering your account" -msgstr "" - -#: ../source/guides/using-testpypi.rst:15 -msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." -msgstr "" - -#: ../source/guides/using-testpypi.rst:19 -msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." -msgstr "" - -#: ../source/guides/using-testpypi.rst:24 -msgid "Using TestPyPI with Twine" -msgstr "" - -#: ../source/guides/using-testpypi.rst:26 -msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:33 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." -msgstr "" - -#: ../source/guides/using-testpypi.rst:39 -msgid "Using TestPyPI with pip" -msgstr "" - -#: ../source/guides/using-testpypi.rst:41 -msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:56 -msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" -msgstr "" - -#: ../source/guides/using-testpypi.rst:73 -msgid "Setting up TestPyPI in :file:`.pypirc`" -msgstr "" - -#: ../source/guides/using-testpypi.rst:75 -msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" -msgstr "" - -#: ../source/index.rst:3 -#: ../source/key_projects.rst:181 -msgid "Python Packaging User Guide" -msgstr "Manual de uso del empaquetamiento de Python" - -#: ../source/index.rst:5 -msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." -msgstr "" - -#: ../source/index.rst:5 -msgid "python, packaging, guide, tutorial" -msgstr "" - -#: ../source/index.rst:24 -msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." -msgstr "" - -#: ../source/index.rst:28 -msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" -msgstr "" - -#: ../source/index.rst:36 -msgid "Get started" -msgstr "" - -#: ../source/index.rst:38 -msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" -msgstr "" - -#: ../source/index.rst:41 -msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" -msgstr "" - -#: ../source/index.rst:43 -msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" -msgstr "" - -#: ../source/index.rst:45 -msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" -msgstr "" - -#: ../source/index.rst:47 -msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" -msgstr "" - -#: ../source/index.rst:52 -msgid "Learn more" -msgstr "" - -#: ../source/index.rst:54 -msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" -msgstr "" - -#: ../source/index.rst:56 -msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." -msgstr "" - -#: ../source/index.rst:58 -msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." -msgstr "" - -#: ../source/index.rst:60 -msgid "The :doc:`specifications/index` section for packaging interoperability specifications." -msgstr "" - -#: ../source/index.rst:62 -msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." -msgstr "" - -#: ../source/key_projects.rst:6 -msgid "Project Summaries" -msgstr "" - -#: ../source/key_projects.rst:8 -msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." -msgstr "" - -#: ../source/key_projects.rst:14 -msgid "PyPA Projects" -msgstr "" - -#: ../source/key_projects.rst:19 -msgid "bandersnatch" -msgstr "" - -#: ../source/key_projects.rst:21 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:25 -msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." -msgstr "" - -#: ../source/key_projects.rst:35 -msgid "build" -msgstr "" - -#: ../source/key_projects.rst:37 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:42 -msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." -msgstr "" - -#: ../source/key_projects.rst:49 -msgid "cibuildwheel" -msgstr "" - -#: ../source/key_projects.rst:51 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" -msgstr "" - -#: ../source/key_projects.rst:58 -msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." -msgstr "" - -#: ../source/key_projects.rst:64 -msgid "distlib" -msgstr "" - -#: ../source/key_projects.rst:66 -msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:71 -msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." -msgstr "" - -#: ../source/key_projects.rst:80 -msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." -msgstr "" - -#: ../source/key_projects.rst:90 -msgid "packaging" -msgstr "" - -#: ../source/key_projects.rst:92 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:97 -msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." -msgstr "" - -#: ../source/key_projects.rst:99 -msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." -msgstr "" - -#: ../source/key_projects.rst:107 -msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." -msgstr "" - -#: ../source/key_projects.rst:119 -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "pip" -msgstr "" - -#: ../source/key_projects.rst:121 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:126 -msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." -msgstr "" - -#: ../source/key_projects.rst:129 -msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." -msgstr "" - -#: ../source/key_projects.rst:137 -msgid "Pipenv" -msgstr "" - -#: ../source/key_projects.rst:139 -msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:144 -msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." -msgstr "" - -#: ../source/key_projects.rst:148 -msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." -msgstr "" - -#: ../source/key_projects.rst:159 -msgid "Pipfile" -msgstr "" - -#: ../source/key_projects.rst:161 -msgid "`Source `__" -msgstr "" - -#: ../source/key_projects.rst:163 -msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." -msgstr "" - -#: ../source/key_projects.rst:170 -msgid "pipx" -msgstr "" - -#: ../source/key_projects.rst:172 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:176 -msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." -msgstr "" - -#: ../source/key_projects.rst:183 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:187 -msgid "This guide!" -msgstr "" - -#: ../source/key_projects.rst:192 -msgid "readme_renderer" -msgstr "" - -#: ../source/key_projects.rst:194 -msgid "`GitHub and docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:197 -msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." -msgstr "" - -#: ../source/key_projects.rst:208 -msgid "setuptools" -msgstr "" - -#: ../source/key_projects.rst:210 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:215 -msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." -msgstr "" - -#: ../source/key_projects.rst:220 -msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." -msgstr "" - -#: ../source/key_projects.rst:227 -msgid "trove-classifiers" -msgstr "" - -#: ../source/key_projects.rst:229 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:233 -msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." -msgstr "" - -#: ../source/key_projects.rst:239 -msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." -msgstr "" - -#: ../source/key_projects.rst:253 -msgid "twine" -msgstr "" - -#: ../source/key_projects.rst:255 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:260 -msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." -msgstr "" - -#: ../source/key_projects.rst:270 -#: ../source/overview.rst:415 -msgid "virtualenv" -msgstr "" - -#: ../source/key_projects.rst:272 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:277 -msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/key_projects.rst:290 -msgid "Warehouse" -msgstr "" - -#: ../source/key_projects.rst:292 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:296 -msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." -msgstr "" - -#: ../source/key_projects.rst:304 -msgid "wheel" -msgstr "" - -#: ../source/key_projects.rst:306 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:311 -msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." -msgstr "" - -#: ../source/key_projects.rst:315 -msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." -msgstr "" - -#: ../source/key_projects.rst:324 -msgid "Non-PyPA Projects" -msgstr "" - -#: ../source/key_projects.rst:329 -msgid "bento" -msgstr "" - -#: ../source/key_projects.rst:331 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:336 -msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." -msgstr "" - -#: ../source/key_projects.rst:344 -msgid "buildout" -msgstr "" - -#: ../source/key_projects.rst:346 -msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:351 -msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." -msgstr "" - -#: ../source/key_projects.rst:358 -msgid "conda" -msgstr "" - -#: ../source/key_projects.rst:360 -msgid "`Docs `__" -msgstr "" - -#: ../source/key_projects.rst:362 -msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." -msgstr "" - -#: ../source/key_projects.rst:369 -msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." -msgstr "" - -#: ../source/key_projects.rst:373 -msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." -msgstr "" - -#: ../source/key_projects.rst:386 -msgid "devpi" -msgstr "" - -#: ../source/key_projects.rst:388 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:392 -msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." -msgstr "" - -#: ../source/key_projects.rst:401 -msgid "flit" -msgstr "" - -#: ../source/key_projects.rst:403 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:407 -msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." -msgstr "" - -#: ../source/key_projects.rst:412 -msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." -msgstr "" - -#: ../source/key_projects.rst:422 -msgid "enscons" -msgstr "" - -#: ../source/key_projects.rst:424 -msgid "`Source `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:428 -msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." -msgstr "" - -#: ../source/key_projects.rst:443 -msgid "Hashdist" -msgstr "" - -#: ../source/key_projects.rst:445 -msgid "`Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:448 -msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." -msgstr "" - -#: ../source/key_projects.rst:460 -msgid "hatch" -msgstr "" - -#: ../source/key_projects.rst:462 -msgid "`GitHub and Docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:465 -msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." -msgstr "" - -#: ../source/key_projects.rst:475 -msgid "multibuild" -msgstr "" - -#: ../source/key_projects.rst:477 -msgid "`GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:479 -msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." -msgstr "" - -#: ../source/key_projects.rst:485 -msgid "pex" -msgstr "" - -#: ../source/key_projects.rst:487 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:491 -msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." -msgstr "" - -#: ../source/key_projects.rst:500 -msgid "pip-tools" -msgstr "" - -#: ../source/key_projects.rst:502 -msgid "`GitHub and Docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:505 -msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." -msgstr "" - -#: ../source/key_projects.rst:517 -msgid "piwheels" -msgstr "" - -#: ../source/key_projects.rst:519 -msgid "`Website `__ | `Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:523 -msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." -msgstr "" - -#: ../source/key_projects.rst:532 -msgid "poetry" -msgstr "" - -#: ../source/key_projects.rst:534 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:538 -msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." -msgstr "" - -#: ../source/key_projects.rst:548 -msgid "pypiserver" -msgstr "" - -#: ../source/key_projects.rst:550 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:554 -msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." -msgstr "" - -#: ../source/key_projects.rst:564 -msgid "scikit-build" -msgstr "" - -#: ../source/key_projects.rst:566 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:570 -msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." -msgstr "" - -#: ../source/key_projects.rst:582 -msgid "shiv" -msgstr "" - -#: ../source/key_projects.rst:584 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:588 -msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." -msgstr "" - -#: ../source/key_projects.rst:598 -msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" -msgstr "" - -#: ../source/key_projects.rst:603 -msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." -msgstr "" - -#: ../source/key_projects.rst:611 -msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." -msgstr "" - -#: ../source/key_projects.rst:617 -msgid "zest.releaser" -msgstr "" - -#: ../source/key_projects.rst:619 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:623 -msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." -msgstr "" - -#: ../source/key_projects.rst:630 -msgid "Standard Library Projects" -msgstr "" - -#: ../source/key_projects.rst:635 -msgid "ensurepip" -msgstr "" - -#: ../source/key_projects.rst:637 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:640 -msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." -msgstr "" - -#: ../source/key_projects.rst:649 -msgid "distutils" -msgstr "" - -#: ../source/key_projects.rst:651 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:654 -msgid "The original Python packaging system, added to the standard library in Python 2.0." -msgstr "" - -#: ../source/key_projects.rst:657 -msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." -msgstr "" - -#: ../source/key_projects.rst:670 -msgid "venv" -msgstr "" - -#: ../source/key_projects.rst:672 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:675 -msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/news.rst:2 -msgid "News" -msgstr "" - -#: ../source/news.rst:5 -msgid "September 2019" -msgstr "" - -#: ../source/news.rst:6 -msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" -msgstr "" - -#: ../source/news.rst:9 -msgid "August 2019" -msgstr "" - -#: ../source/news.rst:10 -msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" -msgstr "" - -#: ../source/news.rst:13 -msgid "July 2019" -msgstr "" - -#: ../source/news.rst:14 -msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" -msgstr "" - -#: ../source/news.rst:15 -msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" -msgstr "" - -#: ../source/news.rst:16 -msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" -msgstr "" - -#: ../source/news.rst:17 -msgid "Updated directory layout examples for consistency. (:pr:`611`)" -msgstr "" - -#: ../source/news.rst:18 -msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" -msgstr "" - -#: ../source/news.rst:21 -msgid "June 2019" -msgstr "" - -#: ../source/news.rst:22 -msgid "Fixed some typos. (:pr:`620`)" -msgstr "" - -#: ../source/news.rst:25 -msgid "May 2019" -msgstr "" - -#: ../source/news.rst:26 -msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" -msgstr "" - -#: ../source/news.rst:27 -msgid "Added a MANIFEST.in guide page. (:pr:`609`)" -msgstr "" - -#: ../source/news.rst:30 -msgid "April 2019" -msgstr "" - -#: ../source/news.rst:31 -msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" -msgstr "" - -#: ../source/news.rst:32 -msgid "Reduced emphasis on virtualenv. (:pr:`606`)" -msgstr "" - -#: ../source/news.rst:35 -msgid "March 2019" -msgstr "" - -#: ../source/news.rst:36 -msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" -msgstr "" - -#: ../source/news.rst:37 -msgid "Covered RTD details for contributing. (:pr:`600`)" -msgstr "" - -#: ../source/news.rst:40 -msgid "February 2019" -msgstr "" - -#: ../source/news.rst:41 -msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" -msgstr "" - -#: ../source/news.rst:42 -msgid "Added instructions to install Python CLI applications. (:pr:`594`)" -msgstr "" - -#: ../source/news.rst:45 -msgid "January 2019" -msgstr "" - -#: ../source/news.rst:46 -msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" -msgstr "" - -#: ../source/news.rst:47 -msgid "Updated Sphinx and Nox. (:pr:`591`)" -msgstr "" - -#: ../source/news.rst:48 -msgid "Referenced Twine from Python3. (:pr:`581`)" -msgstr "" - -#: ../source/news.rst:51 -msgid "December 2018" -msgstr "" - -#: ../source/news.rst:52 -msgid "No programmers in the office!" -msgstr "" - -#: ../source/news.rst:55 -msgid "November 2018" -msgstr "" - -#: ../source/news.rst:56 -msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" -msgstr "" - -#: ../source/news.rst:57 -msgid "Changed bumpversion to bump2version. (:pr:`572`)" -msgstr "" - -#: ../source/news.rst:58 -msgid "Added single-sourcing package version example. (:pr:`573`)" -msgstr "" - -#: ../source/news.rst:59 -msgid "Added a guide for creating documentation. (:pr:`568`)" -msgstr "" - -#: ../source/news.rst:62 -msgid "October 2018" -msgstr "" - -#: ../source/news.rst:63 -msgid "Updated Nox package name. (:pr:`566`)" -msgstr "" - -#: ../source/news.rst:64 -msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" -msgstr "" - -#: ../source/news.rst:67 -msgid "September 2018" -msgstr "" - -#: ../source/news.rst:68 -msgid "Added a section on checking RST markup. (:pr:`554`)" -msgstr "" - -#: ../source/news.rst:69 -msgid "Updated user installs page. (:pr:`558`)" -msgstr "" - -#: ../source/news.rst:70 -msgid "Updated Google BigQuery urls. (:pr:`556`)" -msgstr "" - -#: ../source/news.rst:71 -msgid "Replaced tar command with working command. (:pr:`552`)" -msgstr "" - -#: ../source/news.rst:72 -msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" -msgstr "" - -#: ../source/news.rst:75 -msgid "August 2018" -msgstr "" - -#: ../source/news.rst:76 -msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" -msgstr "" - -#: ../source/news.rst:77 -msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" -msgstr "" - -#: ../source/news.rst:78 -msgid "Updated Python version supported by virtualenv. (:pr:`538`)" -msgstr "" - -#: ../source/news.rst:79 -msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" -msgstr "" - -#: ../source/news.rst:82 -msgid "July 2018" -msgstr "" - -#: ../source/news.rst:84 -msgid "Improved binary extension docs. (:pr:`531`)" -msgstr "" - -#: ../source/news.rst:85 -msgid "Added scikit-build to key projects. (:pr:`530`)" -msgstr "" - -#: ../source/news.rst:88 -msgid "June 2018" -msgstr "" - -#: ../source/news.rst:90 -msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" -msgstr "" - -#: ../source/news.rst:91 -msgid "Updated Markdown descriptions explanation. (:pr:`522`)" -msgstr "" - -#: ../source/news.rst:94 -msgid "May 2018" -msgstr "" - -#: ../source/news.rst:96 -msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" -msgstr "" - -#: ../source/news.rst:97 -msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" -msgstr "" - -#: ../source/news.rst:98 -msgid "Simplified packaging tutorial. (:pr:`498`)" -msgstr "" - -#: ../source/news.rst:99 -msgid "Updated Windows users instructions for clarity. (:pr:`493`)" -msgstr "" - -#: ../source/news.rst:100 -msgid "Updated the license section description for completeness. (:pr:`492`)" -msgstr "" - -#: ../source/news.rst:101 -msgid "Added specification-style document to contributing section. (:pr:`489`)" -msgstr "" - -#: ../source/news.rst:102 -msgid "Added documentation types to contributing guide. (:pr:`485`)" -msgstr "" - -#: ../source/news.rst:105 -msgid "April 2018" -msgstr "" - -#: ../source/news.rst:107 -msgid "Added README guide. (:pr:`461`)" -msgstr "" - -#: ../source/news.rst:108 -msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" -msgstr "" - -#: ../source/news.rst:109 -msgid "Added instructions for Warehouse. (:pr:`471`)" -msgstr "" - -#: ../source/news.rst:110 -msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" -msgstr "" - -#: ../source/news.rst:111 -msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" -msgstr "" - -#: ../source/news.rst:112 -msgid "Added a guide for phasing out Python versions. (:pr:`459`)" -msgstr "" - -#: ../source/news.rst:113 -msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" -msgstr "" - -#: ../source/news.rst:116 -msgid "March 2018" -msgstr "" - -#: ../source/news.rst:118 -msgid "Updated \"installing scientific packages\". (:pr:`455`)" -msgstr "" - -#: ../source/news.rst:119 -msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" -msgstr "" - -#: ../source/news.rst:120 -msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" -msgstr "" - -#: ../source/news.rst:121 -msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" -msgstr "" - -#: ../source/news.rst:124 -msgid "February 2018" -msgstr "" - -#: ../source/news.rst:126 -msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" -msgstr "" - -#: ../source/news.rst:127 -msgid "Updated PyPI migration info. (:pr:`439`)" -msgstr "" - -#: ../source/news.rst:128 -msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" -msgstr "" - -#: ../source/news.rst:129 -msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" -msgstr "" - -#: ../source/news.rst:130 -msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" -msgstr "" - -#: ../source/news.rst:133 -msgid "January 2018" -msgstr "" - -#: ../source/news.rst:135 -msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" -msgstr "" - -#: ../source/news.rst:136 -msgid "Updated README.rst explanation. (:pr:`419`)" -msgstr "" - -#: ../source/news.rst:139 -msgid "December 2017" -msgstr "" - -#: ../source/news.rst:141 -msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" -msgstr "" - -#: ../source/news.rst:142 -msgid "Noted which fields can be used with environment markers. (:pr:`416`)" -msgstr "" - -#: ../source/news.rst:143 -msgid "Updated Requires-Python section. (:pr:`414`)" -msgstr "" - -#: ../source/news.rst:144 -msgid "Added news page. (:pr:`404`)" -msgstr "" - -#: ../source/news.rst:147 -msgid "November 2017" -msgstr "" - -#: ../source/news.rst:149 -msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" -msgstr "" - -#: ../source/news.rst:150 -msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" -msgstr "" - -#: ../source/news.rst:152 -msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" -msgstr "" - -#: ../source/news.rst:153 -msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" -msgstr "" - -#: ../source/news.rst:156 -msgid "October 2017" -msgstr "" - -#: ../source/news.rst:158 -msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" -msgstr "" - -#: ../source/news.rst:159 -msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" -msgstr "" - -#: ../source/news.rst:160 -msgid "Split the specifications page into multiple pages. (:pr:`386`)" -msgstr "" - -#: ../source/news.rst:163 -msgid "September 2017" -msgstr "" - -#: ../source/news.rst:165 -msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" -msgstr "" - -#: ../source/news.rst:167 -msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" -msgstr "" - -#: ../source/news.rst:170 -msgid "August 2017" -msgstr "" - -#: ../source/news.rst:172 -msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" -msgstr "" - -#: ../source/news.rst:173 -msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" -msgstr "" - -#: ../source/news.rst:174 -msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" -msgstr "" - -#: ../source/news.rst:177 -msgid "July 2017" -msgstr "" - -#: ../source/news.rst:179 -msgid "Added ``flit`` to the key projects list. (:pr:`358`)" -msgstr "" - -#: ../source/news.rst:180 -msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" -msgstr "" - -#: ../source/news.rst:181 -msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" -msgstr "" - -#: ../source/news.rst:182 -msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" -msgstr "" - -#: ../source/news.rst:183 -msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" -msgstr "" - -#: ../source/news.rst:186 -msgid "June 2017" -msgstr "" - -#: ../source/news.rst:188 -msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" -msgstr "" - -#: ../source/news.rst:189 -msgid "Added documentation for ``python_requires``. (:pr:`338`)" -msgstr "" - -#: ../source/news.rst:190 -msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" -msgstr "" - -#: ../source/news.rst:191 -msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" -msgstr "" - -#: ../source/news.rst:192 -msgid "Added a license section to the distributing guide. (:pr:`331`)" -msgstr "" - -#: ../source/news.rst:193 -msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" -msgstr "" - -#: ../source/news.rst:194 -msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" -msgstr "" - -#: ../source/news.rst:195 -msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" -msgstr "" - -#: ../source/news.rst:196 -msgid "Switched to the PyPA theme. (:pr:`305`)" -msgstr "" - -#: ../source/news.rst:197 -msgid "Re-organized the documentation into the new structure. (:pr:`318`)" -msgstr "" - -#: ../source/news.rst:200 -msgid "May 2017" -msgstr "" - -#: ../source/news.rst:202 -msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" -msgstr "" - -#: ../source/news.rst:203 -msgid "Added contributor and style guide. (:pr:`307`)" -msgstr "" - -#: ../source/news.rst:204 -msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" -msgstr "" - -#: ../source/news.rst:207 -msgid "April 2017" -msgstr "" - -#: ../source/news.rst:209 -msgid "Added travis configuration for testing pull requests. (:pr:`300`)" -msgstr "" - -#: ../source/news.rst:210 -msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" -msgstr "" - -#: ../source/news.rst:211 -msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" -msgstr "" - -#: ../source/news.rst:212 -msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" -msgstr "" - -#: ../source/news.rst:213 -msgid "Added a topic on namespace packages. (:pr:`290`)" -msgstr "" - -#: ../source/news.rst:214 -msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" -msgstr "" - -#: ../source/news.rst:215 -msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" -msgstr "" - -#: ../source/news.rst:216 -msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" -msgstr "" - -#: ../source/news.rst:217 -msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" -msgstr "" - -#: ../source/news.rst:219 -msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" -msgstr "" - -#: ../source/news.rst:223 -msgid "March 2017" -msgstr "" - -#: ../source/news.rst:225 -msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" -msgstr "" - -#: ../source/news.rst:228 -msgid "February 2017" -msgstr "" - -#: ../source/news.rst:230 -msgid "Added :pep:`518`. (:pr:`281`)" -msgstr "" - -#: ../source/overview.rst:3 -msgid "An Overview of Packaging for Python" -msgstr "" - -#: ../source/overview.rst:7 -msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." -msgstr "" - -#: ../source/overview.rst:12 -msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." -msgstr "" - -#: ../source/overview.rst:18 -msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." -msgstr "" - -#: ../source/overview.rst:26 -msgid "Thinking about deployment" -msgstr "" - -#: ../source/overview.rst:28 -msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" -msgstr "" - -#: ../source/overview.rst:32 -msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" -msgstr "" - -#: ../source/overview.rst:35 -msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" -msgstr "" - -#: ../source/overview.rst:37 -msgid "Is your software installed individually, or in large deployment batches?" -msgstr "" - -#: ../source/overview.rst:39 -msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." -msgstr "" - -#: ../source/overview.rst:46 -msgid "Packaging Python libraries and tools" -msgstr "" - -#: ../source/overview.rst:48 -msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." -msgstr "" - -#: ../source/overview.rst:53 -msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." -msgstr "" - -#: ../source/overview.rst:59 -msgid "Python modules" -msgstr "" - -#: ../source/overview.rst:61 -msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." -msgstr "" - -#: ../source/overview.rst:66 -msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." -msgstr "" - -#: ../source/overview.rst:73 -msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." -msgstr "" - -#: ../source/overview.rst:78 -msgid "Python source distributions" -msgstr "" - -#: ../source/overview.rst:80 -msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." -msgstr "" - -#: ../source/overview.rst:84 -msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." -msgstr "" - -#: ../source/overview.rst:90 -msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." -msgstr "" - -#: ../source/overview.rst:95 -msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." -msgstr "" - -#: ../source/overview.rst:100 -msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." -msgstr "" - -#: ../source/overview.rst:107 -msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" -msgstr "" - -#: ../source/overview.rst:114 -msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." -msgstr "" - -#: ../source/overview.rst:119 -msgid "Python binary distributions" -msgstr "" - -#: ../source/overview.rst:121 -msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." -msgstr "" - -#: ../source/overview.rst:125 -msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." -msgstr "" - -#: ../source/overview.rst:132 -msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." -msgstr "" - -#: ../source/overview.rst:140 -msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." -msgstr "" - -#: ../source/overview.rst:148 -msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." -msgstr "" - -#: ../source/overview.rst:155 -msgid "Packaging Python applications" -msgstr "" - -#: ../source/overview.rst:157 -msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." -msgstr "" - -#: ../source/overview.rst:162 -msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." -msgstr "" - -#: ../source/overview.rst:166 -msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." -msgstr "" - -#: ../source/overview.rst:172 -msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." -msgstr "" - -#: ../source/overview.rst:176 -msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." -msgstr "" - -#: ../source/overview.rst:181 -msgid "Depending on a framework" -msgstr "" - -#: ../source/overview.rst:183 -msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." -msgstr "" - -#: ../source/overview.rst:189 -msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." -msgstr "" - -#: ../source/overview.rst:195 -msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." -msgstr "" - -#: ../source/overview.rst:199 -msgid "Service platforms" -msgstr "" - -#: ../source/overview.rst:201 -msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." -msgstr "" - -#: ../source/overview.rst:205 -msgid "`Heroku `_" -msgstr "" - -#: ../source/overview.rst:206 -msgid "`Google App Engine `_" -msgstr "" - -#: ../source/overview.rst:207 -msgid "`PythonAnywhere `_" -msgstr "" - -#: ../source/overview.rst:208 -msgid "`OpenShift `_" -msgstr "" - -#: ../source/overview.rst:209 -msgid "\"Serverless\" frameworks like `Zappa `_" -msgstr "" - -#: ../source/overview.rst:211 -msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." -msgstr "" - -#: ../source/overview.rst:216 -msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." -msgstr "" - -#: ../source/overview.rst:220 -msgid "Web browsers and mobile applications" -msgstr "" - -#: ../source/overview.rst:222 -msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." -msgstr "" - -#: ../source/overview.rst:227 -msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" -msgstr "" - -#: ../source/overview.rst:231 -msgid "`Kivy `_" -msgstr "" - -#: ../source/overview.rst:232 -msgid "`Beeware `_" -msgstr "" - -#: ../source/overview.rst:233 -msgid "`Brython `_" -msgstr "" - -#: ../source/overview.rst:234 -msgid "`Flexx `_" -msgstr "" - -#: ../source/overview.rst:236 -msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." -msgstr "" - -#: ../source/overview.rst:241 -msgid "Depending on a pre-installed Python" -msgstr "" - -#: ../source/overview.rst:243 -msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." -msgstr "" - -#: ../source/overview.rst:249 -msgid "Technologies which support this model:" -msgstr "" - -#: ../source/overview.rst:251 -msgid "`PEX `_ (Python EXecutable)" -msgstr "" - -#: ../source/overview.rst:252 -msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" -msgstr "" - -#: ../source/overview.rst:253 -msgid "`shiv `_ (requires Python 3)" -msgstr "" - -#: ../source/overview.rst:255 -msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." -msgstr "" - -#: ../source/overview.rst:260 -msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." -msgstr "" - -#: ../source/overview.rst:267 -msgid "Depending on a separate software distribution ecosystem" -msgstr "" - -#: ../source/overview.rst:269 -msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." -msgstr "" - -#: ../source/overview.rst:274 -msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." -msgstr "" - -#: ../source/overview.rst:284 -msgid "Instructions on building and publishing for the Anaconda ecosystem:" -msgstr "" - -#: ../source/overview.rst:286 -msgid "`Building libraries and applications with conda `_" -msgstr "" - -#: ../source/overview.rst:287 -msgid "`Transitioning a native Python package to Anaconda `_" -msgstr "" - -#: ../source/overview.rst:289 -msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" -msgstr "" - -#: ../source/overview.rst:293 -msgid "`Enthought Canopy `_" -msgstr "" - -#: ../source/overview.rst:294 -msgid "`ActiveState ActivePython `_" -msgstr "" - -#: ../source/overview.rst:295 -msgid "`WinPython `_" -msgstr "" - -#: ../source/overview.rst:300 -msgid "Bringing your own Python executable" -msgstr "" - -#: ../source/overview.rst:302 -msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." -msgstr "" - -#: ../source/overview.rst:306 -msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." -msgstr "" - -#: ../source/overview.rst:311 -msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." -msgstr "" - -#: ../source/overview.rst:315 -msgid "A selection of Python freezers:" -msgstr "" - -#: ../source/overview.rst:317 -msgid "`pyInstaller `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:318 -msgid "`cx_Freeze `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:319 -msgid "`constructor `_ - For command-line installers" -msgstr "" - -#: ../source/overview.rst:320 -msgid "`py2exe `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:321 -msgid "`py2app `_ - Mac only" -msgstr "" - -#: ../source/overview.rst:322 -msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" -msgstr "" - -#: ../source/overview.rst:323 -msgid "`osnap `_ - Windows and Mac" -msgstr "" - -#: ../source/overview.rst:324 -msgid "`pynsist `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:326 -msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." -msgstr "" - -#: ../source/overview.rst:332 -msgid "Bringing your own userspace" -msgstr "" - -#: ../source/overview.rst:334 -msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." -msgstr "" - -#: ../source/overview.rst:341 -msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." -msgstr "" - -#: ../source/overview.rst:344 -msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" -msgstr "" - -#: ../source/overview.rst:347 -msgid "`AppImage `_" -msgstr "" - -#: ../source/overview.rst:348 -msgid "`Docker `_" -msgstr "" - -#: ../source/overview.rst:349 -msgid "`Flatpak `_" -msgstr "" - -#: ../source/overview.rst:350 -msgid "`Snapcraft `_" -msgstr "" - -#: ../source/overview.rst:353 -msgid "Bringing your own kernel" -msgstr "" - -#: ../source/overview.rst:355 -msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." -msgstr "" - -#: ../source/overview.rst:360 -msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" -msgstr "" - -#: ../source/overview.rst:364 -msgid "`Vagrant `_" -msgstr "" - -#: ../source/overview.rst:365 -msgid "`VHD `_, `AMI `_, and `other formats `_" -msgstr "" - -#: ../source/overview.rst:366 -msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" -msgstr "" - -#: ../source/overview.rst:369 -msgid "Bringing your own hardware" -msgstr "" - -#: ../source/overview.rst:371 -msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." -msgstr "" - -#: ../source/overview.rst:375 -msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." -msgstr "" - -#: ../source/overview.rst:379 -msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." -msgstr "" - -#: ../source/overview.rst:389 -msgid "The simplified gamut of technologies used to package Python applications." -msgstr "" - -#: ../source/overview.rst:392 -msgid "What about..." -msgstr "" - -#: ../source/overview.rst:394 -msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." -msgstr "" - -#: ../source/overview.rst:398 -msgid "Operating system packages" -msgstr "" - -#: ../source/overview.rst:400 -msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." -msgstr "" - -#: ../source/overview.rst:411 -msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." -msgstr "" - -#: ../source/overview.rst:417 -msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." -msgstr "" - -#: ../source/overview.rst:427 -msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." -msgstr "" - -#: ../source/overview.rst:432 -msgid "Security" -msgstr "Seguridad" - -#: ../source/overview.rst:434 -msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." -msgstr "" - -#: ../source/overview.rst:437 -msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." -msgstr "" - -#: ../source/overview.rst:446 -msgid "Wrap up" -msgstr "" - -#: ../source/overview.rst:448 -msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:6 -msgid "Binary distribution format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:8 -msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:13 -msgid "Abstract" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:15 -msgid "This PEP describes a built-package format for Python called \"wheel\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:17 -msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:27 -msgid "PEP Acceptance" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:29 -msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:34 -msgid "Rationale" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:36 -msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:43 -msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:52 -msgid "Details" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:55 -msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:57 -msgid "Wheel installation notionally consists of two phases:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:59 -msgid "Unpack." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:61 -msgid "Parse ``distribution-1.0.dist-info/WHEEL``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:62 -msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:64 -msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:66 -msgid "Else unpack archive into platlib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:68 -msgid "Spread." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:70 -msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:72 -msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:78 -msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:80 -msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:82 -msgid "Remove empty ``distribution-1.0.data`` directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:83 -msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:87 -msgid "Recommended installer features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:97 -msgid "Rewrite ``#!python``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:90 -msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:96 -msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:102 -msgid "Generate script wrappers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:100 -msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:105 -msgid "Recommended archiver features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:112 -msgid "Place ``.dist-info`` at the end of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:108 -msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:115 -msgid "File Format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:118 -msgid "File name convention" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:120 -msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "distribution" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "Distribution name, e.g. 'django', 'pyramid'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "Distribution version, e.g. 1.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:135 -msgid "build tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:130 -msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "language implementation and version tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "E.g. 'py27', 'py2', 'py3'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "abi tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "E.g. 'cp33m', 'abi3', 'none'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "platform tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "E.g. 'linux_x86_64', 'any'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:146 -msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:151 -msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:156 -msgid "Escaping and Unicode" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:158 -msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:161 -msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:164 -msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:166 -msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:169 -msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:172 -msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:176 -msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:182 -msgid "File contents" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:184 -msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:188 -msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:191 -msgid "``{distribution}-{version}.dist-info/`` contains metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:192 -msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:196 -msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:200 -msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:202 -msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:212 -msgid "``Wheel-Version`` is the version number of the Wheel specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:213 -msgid "``Generator`` is the name and optionally the version of the software that produced the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:215 -msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:218 -msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:220 -msgid "``Build`` is the build number and is omitted if there is no build number." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:221 -msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:224 -msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:226 -msgid "Wheel does not contain setup.py or setup.cfg." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:228 -msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:235 -#: ../source/specifications/recording-installed-packages.rst:35 -msgid "The .dist-info directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:237 -msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:239 -msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:241 -msgid "WHEEL is the wheel metadata specific to a build of the package." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:242 -msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:248 -msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:249 -msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:251 -msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:254 -msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:261 -msgid "The .data directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:263 -msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:271 -msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:277 -msgid "Signed wheel files" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:279 -msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:290 -msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:295 -msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:302 -msgid "(The hash value is the same format used in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:304 -msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:307 -msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:312 -msgid "See" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:314 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:315 -msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:316 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:317 -msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:321 -msgid "Comparison to .egg" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:323 -msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:328 -msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:331 -msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:337 -msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:341 -msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:344 -msgid "Wheel is a reference to the other Python." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:348 -msgid "FAQ" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:352 -msgid "Wheel defines a .data directory. Should I put all my data there?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:354 -msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:363 -msgid "Why does wheel include attached signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:365 -msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:373 -msgid "Why does wheel allow JWS signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:375 -msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:381 -msgid "Why does wheel also allow S/MIME signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:383 -msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:386 -msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:391 -msgid "What's the deal with \"purelib\" vs. \"platlib\"?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:393 -msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:398 -msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:403 -msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:409 -msgid "Is it possible to import Python code directly from a wheel file?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:411 -msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:417 -msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:426 -msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:443 -msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:450 -msgid "Changes" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:452 -msgid "Since :pep:`427`, this specification has changed as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:454 -msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:461 -msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:466 -msgid "Appendix" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:468 -msgid "Example urlsafe-base64-nopad implementation::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:482 -msgid "Copyright" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:484 -msgid "This document has been placed into the public domain." -msgstr "" - -#: ../source/specifications/core-metadata.rst:5 -msgid "Core metadata specifications" -msgstr "" - -#: ../source/specifications/core-metadata.rst:7 -msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:10 -msgid "``Metadata-Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:11 -msgid "``Name``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:12 -msgid "``Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:14 -msgid "All the other fields are optional." -msgstr "" - -#: ../source/specifications/core-metadata.rst:16 -msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." -msgstr "" - -#: ../source/specifications/core-metadata.rst:25 -msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:30 -msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." -msgstr "" - -#: ../source/specifications/core-metadata.rst:41 -msgid "Metadata-Version" -msgstr "" - -#: ../source/specifications/core-metadata.rst:45 -msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." -msgstr "" - -#: ../source/specifications/core-metadata.rst:48 -msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:54 -msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." -msgstr "" - -#: ../source/specifications/core-metadata.rst:58 -#: ../source/specifications/core-metadata.rst:80 -#: ../source/specifications/core-metadata.rst:95 -#: ../source/specifications/core-metadata.rst:155 -#: ../source/specifications/core-metadata.rst:170 -#: ../source/specifications/core-metadata.rst:208 -#: ../source/specifications/core-metadata.rst:283 -#: ../source/specifications/core-metadata.rst:287 -#: ../source/specifications/core-metadata.rst:291 -#: ../source/specifications/core-metadata.rst:295 -#: ../source/specifications/core-metadata.rst:327 -#: ../source/specifications/core-metadata.rst:347 -#: ../source/specifications/core-metadata.rst:373 -#: ../source/specifications/core-metadata.rst:391 -#: ../source/specifications/core-metadata.rst:416 -#: ../source/specifications/core-metadata.rst:438 -#: ../source/specifications/core-metadata.rst:600 -#: ../source/specifications/core-metadata.rst:620 -#: ../source/specifications/core-metadata.rst:630 -msgid "Example::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:66 -msgid "Name" -msgstr "Nombre" - -#: ../source/specifications/core-metadata.rst:69 -msgid "Added additional restrictions on format from :pep:`508`" -msgstr "" - -#: ../source/specifications/core-metadata.rst:72 -msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:88 -msgid "Version" -msgstr "Versión" - -#: ../source/specifications/core-metadata.rst:92 -msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:101 -msgid "Dynamic (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:105 -msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." -msgstr "" - -#: ../source/specifications/core-metadata.rst:108 -msgid "When found in the metadata of a source distribution, the following rules apply:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:111 -msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." -msgstr "" - -#: ../source/specifications/core-metadata.rst:115 -msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:118 -msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:122 -msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." -msgstr "" - -#: ../source/specifications/core-metadata.rst:127 -msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:131 -msgid "Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:135 -msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." -msgstr "" - -#: ../source/specifications/core-metadata.rst:146 -msgid "Supported-Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:150 -msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." -msgstr "" - -#: ../source/specifications/core-metadata.rst:164 -msgid "Summary" -msgstr "" - -#: ../source/specifications/core-metadata.rst:168 -msgid "A one-line summary of what the distribution does." -msgstr "" - -#: ../source/specifications/core-metadata.rst:188 -msgid "This field may be specified in the message body instead." -msgstr "" - -#: ../source/specifications/core-metadata.rst:191 -msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:196 -msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." -msgstr "" - -#: ../source/specifications/core-metadata.rst:202 -msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:219 -msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." -msgstr "" - -#: ../source/specifications/core-metadata.rst:223 -msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:232 -msgid "Description-Content-Type" -msgstr "" - -#: ../source/specifications/core-metadata.rst:236 -msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:239 -msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." -msgstr "" - -#: ../source/specifications/core-metadata.rst:253 -msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:259 -msgid "Format::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:263 -msgid "The ``type/subtype`` part has only a few legal values:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:265 -msgid "``text/plain``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:266 -msgid "``text/x-rst``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:267 -msgid "``text/markdown``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:269 -msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:273 -msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:278 -msgid "``GFM`` for `Github-flavored Markdown `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:280 -msgid "``CommonMark`` for `CommonMark `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:299 -msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." -msgstr "" - -#: ../source/specifications/core-metadata.rst:303 -msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:307 -msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:311 -msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." -msgstr "" - -#: ../source/specifications/core-metadata.rst:320 -msgid "Keywords" -msgstr "" - -#: ../source/specifications/core-metadata.rst:324 -msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." -msgstr "" - -#: ../source/specifications/core-metadata.rst:333 -msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." -msgstr "" - -#: ../source/specifications/core-metadata.rst:341 -msgid "Home-page" -msgstr "" - -#: ../source/specifications/core-metadata.rst:345 -msgid "A string containing the URL for the distribution's home page." -msgstr "" - -#: ../source/specifications/core-metadata.rst:353 -msgid "Download-URL" -msgstr "" - -#: ../source/specifications/core-metadata.rst:357 -msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:366 -msgid "Author" -msgstr "" - -#: ../source/specifications/core-metadata.rst:370 -msgid "A string containing the author's name at a minimum; additional contact information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:383 -msgid "Author-email" -msgstr "" - -#: ../source/specifications/core-metadata.rst:387 -msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:395 -#: ../source/specifications/core-metadata.rst:442 -msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:405 -msgid "Maintainer" -msgstr "Responsable" - -#: ../source/specifications/core-metadata.rst:409 -msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:412 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:426 -msgid "Maintainer-email" -msgstr "" - -#: ../source/specifications/core-metadata.rst:430 -msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:434 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:452 -msgid "License" -msgstr "" - -#: ../source/specifications/core-metadata.rst:456 -msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." -msgstr "" - -#: ../source/specifications/core-metadata.rst:476 -msgid "Classifier (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:480 -msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:485 -#: ../source/specifications/core-metadata.rst:574 -#: ../source/specifications/core-metadata.rst:691 -#: ../source/specifications/core-metadata.rst:715 -msgid "This field may be followed by an environment marker after a semicolon." -msgstr "" - -#: ../source/specifications/core-metadata.rst:496 -msgid "Requires-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:499 -#: ../source/specifications/core-metadata.rst:561 -#: ../source/specifications/core-metadata.rst:663 -#: ../source/specifications/core-metadata.rst:704 -msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." -msgstr "" - -#: ../source/specifications/core-metadata.rst:503 -msgid "Each entry contains a string naming some other distutils project required by this distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:506 -msgid "The format of a requirement string contains from one to four parts:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:508 -msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." -msgstr "" - -#: ../source/specifications/core-metadata.rst:510 -msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." -msgstr "" - -#: ../source/specifications/core-metadata.rst:513 -msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:516 -msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." -msgstr "" - -#: ../source/specifications/core-metadata.rst:519 -msgid "See :pep:`508` for full details of the allowed format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:521 -msgid "The project names should correspond to names as found on the `Python Package Index`_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:524 -msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:538 -msgid "Requires-Python" -msgstr "" - -#: ../source/specifications/core-metadata.rst:542 -msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." -msgstr "" - -#: ../source/specifications/core-metadata.rst:546 -msgid "The value must be in the format specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:548 -msgid "This field cannot be followed by an environment marker." -msgstr "" - -#: ../source/specifications/core-metadata.rst:558 -msgid "Requires-External (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:565 -msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:570 -msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:576 -msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." -msgstr "" - -#: ../source/specifications/core-metadata.rst:581 -msgid "Notice that there is no particular rule on the strings to be used." -msgstr "" - -#: ../source/specifications/core-metadata.rst:593 -msgid "Project-URL (multiple-use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:597 -msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." -msgstr "" - -#: ../source/specifications/core-metadata.rst:604 -msgid "The label is free text limited to 32 characters." -msgstr "" - -#: ../source/specifications/core-metadata.rst:612 -msgid "Provides-Extra (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:616 -msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." -msgstr "" - -#: ../source/specifications/core-metadata.rst:625 -msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:635 -msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." -msgstr "" - -#: ../source/specifications/core-metadata.rst:639 -msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:644 -msgid "Rarely Used Fields" -msgstr "" - -#: ../source/specifications/core-metadata.rst:646 -msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:651 -msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." -msgstr "" - -#: ../source/specifications/core-metadata.rst:660 -msgid "Provides-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:667 -msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:672 -msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:679 -msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:687 -msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." -msgstr "" - -#: ../source/specifications/core-metadata.rst:701 -msgid "Obsoletes-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:708 -msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." -msgstr "" - -#: ../source/specifications/core-metadata.rst:712 -msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:717 -msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:730 -msgid "reStructuredText markup: http://docutils.sourceforge.net/" -msgstr "" - -#: ../source/specifications/core-metadata.rst:735 -msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:6 -msgid "Declaring build system dependencies" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:8 -msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:5 -msgid "Declaring project metadata" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:7 -msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:12 -msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:18 -msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:27 -msgid "The only fields required to be statically defined are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:29 -#: ../source/specifications/declaring-project-metadata.rst:41 -msgid "``name``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:31 -msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:34 -#: ../source/specifications/declaring-project-metadata.rst:54 -msgid "``version``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:36 -msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:43 -#: ../source/specifications/declaring-project-metadata.rst:56 -#: ../source/specifications/declaring-project-metadata.rst:68 -#: ../source/specifications/declaring-project-metadata.rst:117 -msgid "TOML_ type: string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:44 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:47 -msgid "The name of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:49 -msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:57 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:60 -msgid "The version of the project as supported by :pep:`440`." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:62 -msgid "Users SHOULD prefer to specify already-normalized versions." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:66 -msgid "``description``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:69 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:72 -msgid "The summary description of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:76 -msgid "``readme``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:78 -msgid "TOML_ type: string or table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:79 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:83 -msgid "The full description of the project (i.e. the README)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:85 -msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:96 -msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:103 -msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:115 -msgid "``requires-python``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:118 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:121 -msgid "The Python version requirements of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:125 -msgid "``license``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:127 -msgid "TOML_ type: table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:128 -msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:131 -msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:140 -msgid "``authors``/``maintainers``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:142 -msgid "TOML_ type: Array of inline tables with string keys and values" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:143 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:149 -msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:154 -msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:157 -msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:163 -msgid "Using the data to fill in :ref:`core metadata ` is as follows:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:166 -msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:169 -msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:173 -msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:177 -msgid "Multiple values should be separated by commas." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:181 -msgid "``keywords``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:183 -#: ../source/specifications/declaring-project-metadata.rst:193 -msgid "TOML_ type: array of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:184 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:187 -msgid "The keywords for the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:191 -msgid "``classifiers``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:194 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:197 -msgid "Trove classifiers which apply to the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:201 -msgid "``urls``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:203 -msgid "TOML_ type: table with keys and values of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:204 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:207 -msgid "A table of URLs where the key is the URL label and the value is the URL itself." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:212 -msgid "Entry points" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:214 -msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:216 -msgid ":ref:`Entry points specification `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:218 -msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:224 -msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:228 -msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:234 -msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:242 -msgid "``dependencies``/``optional-dependencies``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:244 -msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:247 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:251 -msgid "The (optional) dependencies of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:253 -msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:258 -msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:269 -msgid "``dynamic``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:271 -msgid "TOML_ type: array of string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:272 -msgid "A corresponding :ref:`core metadata ` field does not exist" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:275 -msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:281 -msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:283 -msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:285 -msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:290 -msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:294 -msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:296 -msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:300 -msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:6 -msgid "Dependency specifiers" -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:8 -msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:11 -msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." -msgstr "" - -#: ../source/specifications/direct-url.rst:6 -msgid "Recording the Direct URL Origin of installed distributions" -msgstr "" - -#: ../source/specifications/direct-url.rst:8 -msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." -msgstr "" - -#: ../source/specifications/direct-url.rst:17 -msgid "Specification" -msgstr "" - -#: ../source/specifications/direct-url.rst:19 -msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/direct-url.rst:23 -#: ../source/specifications/recording-installed-packages.rst:206 -msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." -msgstr "" - -#: ../source/specifications/direct-url.rst:26 -msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." -msgstr "" - -#: ../source/specifications/direct-url.rst:29 -msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." -msgstr "" - -#: ../source/specifications/direct-url.rst:36 -msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." -msgstr "" - -#: ../source/specifications/direct-url.rst:39 -msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" -msgstr "" - -#: ../source/specifications/direct-url.rst:45 -msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." -msgstr "" - -#: ../source/specifications/direct-url.rst:49 -msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" -msgstr "" - -#: ../source/specifications/direct-url.rst:52 -msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." -msgstr "" - -#: ../source/specifications/direct-url.rst:58 -msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." -msgstr "" - -#: ../source/specifications/direct-url.rst:61 -msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." -msgstr "" - -#: ../source/specifications/direct-url.rst:68 -msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:71 -msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." -msgstr "" - -#: ../source/specifications/direct-url.rst:78 -msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:81 -msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." -msgstr "" - -#: ../source/specifications/direct-url.rst:84 -msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." -msgstr "" - -#: ../source/specifications/direct-url.rst:91 -msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." -msgstr "" - -#: ../source/specifications/direct-url.rst:96 -msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." -msgstr "" - -#: ../source/specifications/direct-url.rst:102 -msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." -msgstr "" - -#: ../source/specifications/direct-url.rst:110 -msgid "Registered VCS" -msgstr "" - -#: ../source/specifications/direct-url.rst:112 -msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." -msgstr "" - -#: ../source/specifications/direct-url.rst:122 -msgid "Git" -msgstr "" - -#: ../source/specifications/direct-url.rst:124 -#: ../source/specifications/direct-url.rst:156 -#: ../source/specifications/direct-url.rst:179 -#: ../source/specifications/direct-url.rst:202 -msgid "Home page" -msgstr "" - -#: ../source/specifications/direct-url.rst:126 -msgid "https://git-scm.com/" -msgstr "" - -#: ../source/specifications/direct-url.rst:128 -#: ../source/specifications/direct-url.rst:160 -#: ../source/specifications/direct-url.rst:183 -#: ../source/specifications/direct-url.rst:206 -msgid "vcs command" -msgstr "" - -#: ../source/specifications/direct-url.rst:130 -#: ../source/specifications/direct-url.rst:134 -msgid "git" -msgstr "" - -#: ../source/specifications/direct-url.rst:132 -#: ../source/specifications/direct-url.rst:164 -#: ../source/specifications/direct-url.rst:187 -#: ../source/specifications/direct-url.rst:210 -msgid "``vcs`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:136 -#: ../source/specifications/direct-url.rst:168 -#: ../source/specifications/direct-url.rst:191 -#: ../source/specifications/direct-url.rst:214 -msgid "``requested_revision`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:138 -msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." -msgstr "" - -#: ../source/specifications/direct-url.rst:141 -#: ../source/specifications/direct-url.rst:172 -#: ../source/specifications/direct-url.rst:195 -#: ../source/specifications/direct-url.rst:219 -msgid "``commit_id`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:143 -msgid "A commit hash (40 hexadecimal characters sha1)." -msgstr "" - -#: ../source/specifications/direct-url.rst:147 -msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." -msgstr "" - -#: ../source/specifications/direct-url.rst:154 -msgid "Mercurial" -msgstr "" - -#: ../source/specifications/direct-url.rst:158 -msgid "https://www.mercurial-scm.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:162 -#: ../source/specifications/direct-url.rst:166 -msgid "hg" -msgstr "" - -#: ../source/specifications/direct-url.rst:170 -msgid "A tag name, branch name, changeset ID, shortened changeset ID." -msgstr "" - -#: ../source/specifications/direct-url.rst:174 -msgid "A changeset ID (40 hexadecimal characters)." -msgstr "" - -#: ../source/specifications/direct-url.rst:177 -msgid "Bazaar" -msgstr "" - -#: ../source/specifications/direct-url.rst:181 -msgid "https://bazaar.canonical.com/" -msgstr "" - -#: ../source/specifications/direct-url.rst:185 -#: ../source/specifications/direct-url.rst:189 -msgid "bzr" -msgstr "" - -#: ../source/specifications/direct-url.rst:193 -msgid "A tag name, branch name, revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:197 -msgid "A revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:200 -msgid "Subversion" -msgstr "" - -#: ../source/specifications/direct-url.rst:204 -msgid "https://subversion.apache.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:208 -#: ../source/specifications/direct-url.rst:212 -msgid "svn" -msgstr "" - -#: ../source/specifications/direct-url.rst:216 -msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." -msgstr "" - -#: ../source/specifications/direct-url.rst:221 -msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." -msgstr "" - -#: ../source/specifications/direct-url.rst:229 -msgid "Example direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:231 -msgid "Source archive:" -msgstr "" - -#: ../source/specifications/direct-url.rst:242 -msgid "Git URL with tag and commit-hash:" -msgstr "" - -#: ../source/specifications/direct-url.rst:255 -msgid "Local directory:" -msgstr "" - -#: ../source/specifications/direct-url.rst:264 -msgid "Local directory installed in editable mode:" -msgstr "" - -#: ../source/specifications/direct-url.rst:277 -msgid "Example pip commands and their effect on direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:279 -msgid "Commands that generate a ``direct_url.json``:" -msgstr "" - -#: ../source/specifications/direct-url.rst:281 -msgid "pip install https://example.com/app-1.0.tgz" -msgstr "" - -#: ../source/specifications/direct-url.rst:282 -msgid "pip install https://example.com/app-1.0.whl" -msgstr "" - -#: ../source/specifications/direct-url.rst:283 -msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" -msgstr "" - -#: ../source/specifications/direct-url.rst:284 -msgid "pip install ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:285 -msgid "pip install file:///home/user/app" -msgstr "" - -#: ../source/specifications/direct-url.rst:286 -msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" -msgstr "" - -#: ../source/specifications/direct-url.rst:290 -msgid "pip install -e ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:292 -msgid "Commands that *do not* generate a ``direct_url.json``" -msgstr "" - -#: ../source/specifications/direct-url.rst:294 -msgid "pip install app" -msgstr "" - -#: ../source/specifications/direct-url.rst:295 -msgid "pip install app --no-index --find-links https://example.com/" -msgstr "" - -#: ../source/specifications/entry-points.rst:5 -msgid "Entry points specification" -msgstr "" - -#: ../source/specifications/entry-points.rst:7 -msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" -msgstr "" - -#: ../source/specifications/entry-points.rst:11 -msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." -msgstr "" - -#: ../source/specifications/entry-points.rst:14 -msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." -msgstr "" - -#: ../source/specifications/entry-points.rst:19 -msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." -msgstr "" - -#: ../source/specifications/entry-points.rst:28 -msgid "Data model" -msgstr "" - -#: ../source/specifications/entry-points.rst:30 -msgid "Conceptually, an entry point is defined by three required properties:" -msgstr "" - -#: ../source/specifications/entry-points.rst:32 -msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:42 -msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:51 -msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:64 -msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." -msgstr "" - -#: ../source/specifications/entry-points.rst:68 -msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." -msgstr "" - -#: ../source/specifications/entry-points.rst:73 -msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." -msgstr "" - -#: ../source/specifications/entry-points.rst:80 -msgid "File format" -msgstr "Formato de archivo" - -#: ../source/specifications/entry-points.rst:82 -msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." -msgstr "" - -#: ../source/specifications/entry-points.rst:87 -msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:97 -msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:100 -msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." -msgstr "" - -#: ../source/specifications/entry-points.rst:104 -msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." -msgstr "" - -#: ../source/specifications/entry-points.rst:112 -msgid "For example::" -msgstr "Por ejemplo::" - -#: ../source/specifications/entry-points.rst:124 -msgid "Use for scripts" -msgstr "" - -#: ../source/specifications/entry-points.rst:126 -msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." -msgstr "" - -#: ../source/specifications/entry-points.rst:134 -msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:141 -msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." -msgstr "" - -#: ../source/specifications/entry-points.rst:149 -msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." -msgstr "" - -#: ../source/specifications/entry-points.rst:154 -msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." -msgstr "" - -#: ../source/specifications/index.rst:4 -msgid "PyPA specifications" -msgstr "Especificaciones de PyPA" - -#: ../source/specifications/index.rst:6 -msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." -msgstr "" - -#: ../source/specifications/index.rst:13 -msgid "Package Distribution Metadata" -msgstr "Metadatos de distribución de paquetes" - -#: ../source/specifications/index.rst:30 -msgid "Package Distribution File Formats" -msgstr "Formatos de archivo de distribución de paquetes" - -#: ../source/specifications/index.rst:40 -msgid "Package Index Interfaces" -msgstr "Interfaces del Índice de paquetes" - -#: ../source/specifications/platform-compatibility-tags.rst:6 -msgid "Platform compatibility tags" -msgstr "Etiquetas de compatibilidad con plataformas" - -#: ../source/specifications/platform-compatibility-tags.rst:8 -msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:12 -msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:16 -msgid "Platform tags for Windows" -msgstr "Etiquetas de plataforma para Windows" - -#: ../source/specifications/platform-compatibility-tags.rst:18 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:22 -msgid "Platform tags for macOS (Mac OS X)" -msgstr "Etiquetas de plataforma para macOS (Mac OS X)" - -#: ../source/specifications/platform-compatibility-tags.rst:24 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:28 -msgid "Platform tags for common Linux distributions" -msgstr "Etiquetas de plataforma para distribuciones Linux comunes" - -#: ../source/specifications/platform-compatibility-tags.rst:32 -msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:36 -msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:41 -msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:44 -msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:46 -msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:49 -msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:54 -msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:59 -msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:65 -msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:71 -msgid "Manylinux compatibility support" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:74 -msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:76 -msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:79 -msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "Tool" -msgstr "Herramienta" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux1``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2010``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2014``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux_x_y``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=8.1.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=20.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "auditwheel" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=1.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=2.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.3.0`` [#]_" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:90 -msgid "Platform tags for other \\*nix platforms" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:92 -msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:98 -msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" -msgstr "" - -#: ../source/specifications/pypirc.rst:6 -msgid "The :file:`.pypirc` file" -msgstr "El archivo :file:`.pypirc`" - -#: ../source/specifications/pypirc.rst:8 -msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." -msgstr "" - -#: ../source/specifications/pypirc.rst:13 -msgid "The format (originally defined by the :ref:`distutils` package) is:" -msgstr "El formato (definido originalmente por el paquete :ref:`distutils`) es:" - -#: ../source/specifications/pypirc.rst:32 -msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:35 -msgid "Each section describing a repository defines three fields:" -msgstr "" - -#: ../source/specifications/pypirc.rst:37 -msgid "``repository``: The URL of the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:38 -msgid "``username``: The registered username on the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:39 -msgid "``password``: The password that will used to authenticate the username." -msgstr "" - -#: ../source/specifications/pypirc.rst:43 -msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." -msgstr "" - -#: ../source/specifications/pypirc.rst:47 -msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" -msgstr "" - -#: ../source/specifications/pypirc.rst:57 -msgid "Common configurations" -msgstr "Configuraciones habituales" - -#: ../source/specifications/pypirc.rst:61 -msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." -msgstr "" - -#: ../source/specifications/pypirc.rst:66 -msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" -msgstr "" - -#: ../source/specifications/pypirc.rst:82 -msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." -msgstr "" - -#: ../source/specifications/pypirc.rst:86 -msgid "Using a PyPI token" -msgstr "Uso de una ficha de PyPI" - -#: ../source/specifications/pypirc.rst:88 -msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" -msgstr "" - -#: ../source/specifications/pypirc.rst:97 -msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." -msgstr "" - -#: ../source/specifications/pypirc.rst:103 -msgid "Using another package index" -msgstr "Uso de otro índice de paquetes" - -#: ../source/specifications/pypirc.rst:105 -msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" -msgstr "" - -#: ../source/specifications/pypirc.rst:132 -msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:5 -msgid "Recording installed projects" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:7 -msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:12 -msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:21 -msgid "History and change workflow" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:23 -msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:29 -msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:37 -msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:41 -msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:50 -msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:60 -msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:69 -msgid "This ``.dist-info`` directory can contain these files, described in detail below:" -msgstr "" -"El directorio ``.dist-info`` puede contener los archivos que se describen a " -"detalle a continuación:" - -#: ../source/specifications/recording-installed-packages.rst:72 -msgid "``METADATA``: contains project metadata" -msgstr "``METADATA``: contiene metadatos sobre el proyecto" - -#: ../source/specifications/recording-installed-packages.rst:73 -msgid "``RECORD``: records the list of installed files." -msgstr "``RECORD``: registra la lista de archivos instalados." - -#: ../source/specifications/recording-installed-packages.rst:74 -msgid "``INSTALLER``: records the name of the tool used to install the project." -msgstr "" -"``INSTALLER``: registra el nombre de la herramienta utilizada para instalar " -"el proyecto." - -#: ../source/specifications/recording-installed-packages.rst:76 -msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:82 -msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:87 -msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:94 -msgid "The METADATA file" -msgstr "El archivo METADATA" - -#: ../source/specifications/recording-installed-packages.rst:96 -msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:99 -msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:105 -msgid "The RECORD file" -msgstr "El archivo RECORD" - -#: ../source/specifications/recording-installed-packages.rst:107 -msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:110 -msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:113 -msgid "field delimiter: ``,`` (comma)," -msgstr "delimitador de campos: ``,`` (coma)," - -#: ../source/specifications/recording-installed-packages.rst:114 -msgid "quoting char: ``\"`` (straight double quote)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:115 -msgid "line terminator: either ``\\r\\n`` or ``\\n``." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:117 -msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:120 -msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:125 -msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:130 -msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:133 -msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:139 -msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:146 -msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:151 -msgid "Here is an example snippet of a possible ``RECORD`` file::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:170 -msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:177 -msgid "The INSTALLER file" -msgstr "El archivo INSTALLER" - -#: ../source/specifications/recording-installed-packages.rst:179 -msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:185 -msgid "The file can be terminated by zero or more ASCII whitespace characters." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:187 -msgid "Here are examples of two possible ``INSTALLER`` files::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:195 -msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:201 -msgid "The direct_url.json file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:203 -msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:209 -msgid "Its detailed specification is at :ref:`direct-url`." -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:6 -msgid "Simple repository API" -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:8 -msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:6 -msgid "Source distribution format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:8 -msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:13 -msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:21 -msgid "Source distributions are also known as *sdists* for short." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:24 -msgid "Source distribution file name" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:26 -msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:31 -msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:35 -msgid "Source distribution file format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:37 -msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:45 -msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:48 -msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:6 -msgid "Version specifiers" -msgstr "" - -#: ../source/specifications/version-specifiers.rst:8 -msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:11 -msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." -msgstr "" - -#: ../source/support.rst:3 -msgid "How to Get Support" -msgstr "Cómo obtener asistencia" - -#: ../source/support.rst:5 -msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." -msgstr "" - -#: ../source/support.rst:8 -msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:5 -msgid "Creating Documentation" -msgstr "Creación de documentación" - -#: ../source/tutorials/creating-documentation.rst:7 -msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:13 -msgid "Installing Sphinx" -msgstr "Instalación de Sphinx" - -#: ../source/tutorials/creating-documentation.rst:14 -msgid "Use ``pip`` to install Sphinx:" -msgstr "Sírvase de ``pip`` para instalar Sphinx:" - -#: ../source/tutorials/creating-documentation.rst:28 -msgid "For other installation methods, see this `installation guide`_ by Sphinx." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:33 -msgid "Getting Started With Sphinx" -msgstr "Primeros pasos con Sphinx" - -#: ../source/tutorials/creating-documentation.rst:35 -msgid "Create a ``docs`` directory inside your project to hold your documentation:" -msgstr "" -"Cree un directorio denominado ``docs`` en el proyecto; allí se almacenará su " -"documentación:" - -#: ../source/tutorials/creating-documentation.rst:42 -msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" -msgstr "Ejecute ``sphinx-quickstart`` dentro del directorio ``docs``:" - -#: ../source/tutorials/creating-documentation.rst:49 -msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:51 -msgid "You can add some information about your project in ``index.rst``, then build them:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:57 -msgid "For more details on the build process, see this `guide`_ by Read The Docs." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:62 -msgid "Other Sources" -msgstr "Otras fuentes" - -#: ../source/tutorials/creating-documentation.rst:64 -msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/index.rst:4 -msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:5 -msgid "Installing Packages" -msgstr "Instalación de paquetes" - -#: ../source/tutorials/installing-packages.rst:7 -msgid "This section covers the basics of how to install Python :term:`packages `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:10 -msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:28 -msgid "Requirements for Installing Packages" -msgstr "Requisitos para instalar paquetes" - -#: ../source/tutorials/installing-packages.rst:30 -msgid "This section describes the steps to follow before installing other Python packages." -msgstr "" -"Esta sección describe los pasos que hay que seguir antes de instalar otros " -"paquetes de Python." - -#: ../source/tutorials/installing-packages.rst:35 -msgid "Ensure you can run Python from the command line" -msgstr "Cerciórese de que pueda ejecutar Python desde la línea de órdenes" - -#: ../source/tutorials/installing-packages.rst:37 -msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:53 -msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:57 -msgid "If you're a newcomer and you get an error like this:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:66 -msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:72 -msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:82 -msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:87 -msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:99 -msgid "Ensure you can run pip from the command line" -msgstr "Cerciórese de que pueda ejecutar pip desde la línea de órdenes" - -#: ../source/tutorials/installing-packages.rst:101 -msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:116 -msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:124 -msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:139 -msgid "If that still doesn't allow you to run ``python -m pip``:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:141 -msgid "Securely Download `get-pip.py `_ [1]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:144 -msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:150 -msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:159 -msgid "Ensure pip, setuptools, and wheel are up to date" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:161 -msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:169 -msgid "Optionally, create a virtual environment" -msgstr "Facultativamente, cree un entorno virtual" - -#: ../source/tutorials/installing-packages.rst:171 -msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:188 -msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:195 -msgid "Creating Virtual Environments" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:197 -msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:203 -msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:209 -msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:213 -msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:216 -msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:220 -msgid "Currently, there are two common tools for creating Python virtual environments:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:222 -msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:225 -msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:230 -msgid "The basic usage is like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:232 -msgid "Using `venv`_:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:248 -msgid "Using :ref:`virtualenv`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:264 -msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:266 -msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:271 -msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:281 -msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:288 -msgid "Use pip for Installing" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:290 -msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:297 -msgid "Installing from PyPI" -msgstr "Instalación a partir de PyPI" - -#: ../source/tutorials/installing-packages.rst:299 -msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:307 -msgid "To install the latest version of \"SomeProject\":" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:321 -msgid "To install a specific version:" -msgstr "Para instalar una versión específica:" - -#: ../source/tutorials/installing-packages.rst:335 -msgid "To install greater than or equal to one version and less than another:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:350 -msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:365 -msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:370 -msgid "Source Distributions vs Wheels" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:372 -msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:378 -msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:383 -msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:391 -msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:408 -msgid "Installing to the User Site" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:410 -msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:425 -msgid "For more information see the `User Installs `_ section from the pip docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:429 -msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:432 -msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:440 -msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:446 -msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:462 -msgid "Install a list of requirements specified in a :ref:`Requirements File `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:478 -msgid "Installing from VCS" -msgstr "Instalación a partir de un sistema de control de versiones" - -#: ../source/tutorials/installing-packages.rst:480 -msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:502 -msgid "Installing from other Indexes" -msgstr "Instalación a partir de otros índices" - -#: ../source/tutorials/installing-packages.rst:504 -msgid "Install from an alternate index" -msgstr "Instalación a partir de un índice alternativo" - -#: ../source/tutorials/installing-packages.rst:518 -msgid "Search an additional index during install, in addition to :term:`PyPI `" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:534 -msgid "Installing from a local src tree" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:537 -msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:554 -msgid "You can also install normally from src" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:571 -msgid "Install a particular source archive file." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:585 -msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:605 -msgid "Installing from other sources" -msgstr "Instalación a partir de otras fuentes" - -#: ../source/tutorials/installing-packages.rst:607 -msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:619 -msgid "Installing Prereleases" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:621 -msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:637 -msgid "Installing Setuptools \"Extras\"" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:639 -msgid "Install `setuptools extras`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:659 -msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:668 -msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:673 -msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:4 -msgid "Managing Application Dependencies" -msgstr "Gestión de las dependencias de aplicación" - -#: ../source/tutorials/managing-dependencies.rst:6 -msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:9 -msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:13 -msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:17 -msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:24 -msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:30 -msgid "Installing Pipenv" -msgstr "Instalación de Pipenv" - -#: ../source/tutorials/managing-dependencies.rst:32 -msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:38 -msgid "Use ``pip`` to install Pipenv:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:54 -msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:65 -msgid "Installing packages for your project" -msgstr "Instalación de paquetes para su proyecto" - -#: ../source/tutorials/managing-dependencies.rst:67 -msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:76 -msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:112 -msgid "Using installed packages" -msgstr "Utilización de paquetes instalados" - -#: ../source/tutorials/managing-dependencies.rst:114 -msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:125 -msgid "Then you can run this script using ``pipenv run``:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:131 -msgid "You should get output similar to this:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:137 -msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:143 -#: ../source/tutorials/packaging-projects.rst:594 -msgid "Next steps" -msgstr "Próximos pasos" - -#: ../source/tutorials/managing-dependencies.rst:145 -msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:148 -msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:151 -msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:160 -msgid "Other Tools for Application Dependency Management" -msgstr "Otras herramientas para la gestión de las dependencias de aplicación" - -#: ../source/tutorials/managing-dependencies.rst:162 -msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:166 -msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:172 -msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:175 -msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:177 -msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:2 -msgid "Packaging Python Projects" -msgstr "Empaquetamiento de proyectos Python" - -#: ../source/tutorials/packaging-projects.rst:4 -msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:10 -msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:18 -msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:35 -msgid "A simple project" -msgstr "Un proyecto sencillo" - -#: ../source/tutorials/packaging-projects.rst:37 -msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:41 -msgid "Create the following file structure locally:" -msgstr "Cree la estructura siguiente de manera local:" - -#: ../source/tutorials/packaging-projects.rst:51 -msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:54 -msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:63 -msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:67 -msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:75 -msgid "Creating the package files" -msgstr "Creación de los archivos del paquete" - -#: ../source/tutorials/packaging-projects.rst:77 -msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:95 -msgid "Creating a test directory" -msgstr "Creación de un directorio de pruebas" - -#: ../source/tutorials/packaging-projects.rst:97 -msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:101 -msgid "Creating pyproject.toml" -msgstr "Creación de pyproject.toml" - -#: ../source/tutorials/packaging-projects.rst:103 -msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:117 -msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:121 -msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:127 -msgid "See :pep:`517` and :pep:`518` for background and details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:131 -msgid "Configuring metadata" -msgstr "Configuración de los metadatos" - -#: ../source/tutorials/packaging-projects.rst:133 -msgid "There are two types of metadata: static and dynamic." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:135 -msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:137 -msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:141 -msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:148 -msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:153 -msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:185 -msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:191 -#: ../source/tutorials/packaging-projects.rst:286 -msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:196 -msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:199 -#: ../source/tutorials/packaging-projects.rst:293 -msgid "``author`` and ``author_email`` are used to identify the author of the package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:201 -#: ../source/tutorials/packaging-projects.rst:295 -msgid "``description`` is a short, one-sentence summary of the package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:202 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:206 -#: ../source/tutorials/packaging-projects.rst:300 -msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:208 -#: ../source/tutorials/packaging-projects.rst:302 -msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:211 -#: ../source/tutorials/packaging-projects.rst:305 -msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:213 -#: ../source/tutorials/packaging-projects.rst:307 -msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:221 -msgid "In the ``options`` category, we have controls for setuptools itself:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:223 -msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:227 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:234 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:238 -#: ../source/tutorials/packaging-projects.rst:329 -msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:244 -msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:248 -msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:283 -msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:291 -msgid "``version`` is the package version. See :pep:`440` for more details on versions." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:296 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:314 -msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:319 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:325 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:333 -msgid "Creating README.md" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:335 -msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:347 -msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:354 -msgid "Creating a LICENSE" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:356 -msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:387 -msgid "Including other files" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:389 -msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:393 -msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:402 -msgid "Generating distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:404 -msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:408 -msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:422 -msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:425 -msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:439 -msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:449 -msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:458 -msgid "Uploading the distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:460 -msgid "Finally, it's time to upload your package to the Python Package Index!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:462 -msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:470 -msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:477 -msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:492 -msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:506 -msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:510 -msgid "After the command completes, you should see output similar to this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:523 -msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:528 -msgid "Installing your newly uploaded package" -msgstr "Instalación de su paquete recién cargado" - -#: ../source/tutorials/packaging-projects.rst:530 -msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:546 -msgid "Make sure to specify your username in the package name!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:548 -msgid "pip should install the package from TestPyPI and the output should look something like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:558 -msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:565 -msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:580 -msgid "and import the package:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:588 -msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:596 -msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:599 -msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:604 -msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:608 -msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:610 -msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:613 -msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:617 -msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:619 -msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:622 -msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:624 -msgid "Read about :doc:`/guides/packaging-binary-extensions`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:625 -msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." -msgstr "" diff --git a/locales/fr/LC_MESSAGES/messages.po b/locales/fr/LC_MESSAGES/messages.po deleted file mode 100644 index 8422c8223..000000000 --- a/locales/fr/LC_MESSAGES/messages.po +++ /dev/null @@ -1,9379 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2013–2020, PyPA -# This file is distributed under the same license as the Python Packaging User Guide package. -# Nathan , 2021. -msgid "" -msgstr "" -"Project-Id-Version: Python Packaging User Guide\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-10-23 18:40+0000\n" -"Last-Translator: Nathan \n" -"Language-Team: French \n" -"Language: fr\n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=UTF-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Plural-Forms: nplurals=2; plural=n > 1;\n" -"X-Generator: Weblate 4.9-dev\n" - -#: ../source/contribute.rst:5 -msgid "Contribute to this guide" -msgstr "Contribuer à ce guide" - -#: ../source/contribute.rst:7 -msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" -msgstr "" -"La |PyPUG| accueille les contributeurs ! Il existe de nombreuses façons de " -"contribuer, notamment :" - -#: ../source/contribute.rst:10 -msgid "Reading the guide and giving feedback" -msgstr "Lire le guide et envoyer des commentaires" - -#: ../source/contribute.rst:11 -msgid "Reviewing new contributions" -msgstr "Passer en revue les nouvelles contributions" - -#: ../source/contribute.rst:12 -msgid "Revising existing content" -msgstr "Réviser le contenu existant" - -#: ../source/contribute.rst:13 -msgid "Writing new content" -msgstr "Rédiger du nouveau contenu" - -#: ../source/contribute.rst:15 -msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." -msgstr "" -"La plupart du travail sur |PyPUG| prend place sur le `dépôt GitHub du projet`" -"__. Pour commencer, consultez la liste des open issues et des pull requests. " -"Si vous avez l'intention de rédiger ou modifier le guide, veuillez lire le " -":ref:`style guide `" - -#: ../source/contribute.rst:24 -msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." -msgstr "" -"En contribuant à la |PyPUG|, vous devez respecter le `Code de conduite`__ de " -"la PSF." - -#: ../source/contribute.rst:31 -msgid "Documentation types" -msgstr "Types de documentation" - -#: ../source/contribute.rst:33 -msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." -msgstr "" -"Ce projet consiste en quatre types de documentation utilisés à des fins " -"spécifiques. Lorsque vous proposez des nouveaux ajouts au projet, veuillez " -"sélectionner le type de documentation approprié." - -#: ../source/contribute.rst:38 -#: ../source/tutorials/index.rst:2 -msgid "Tutorials" -msgstr "Tutoriels" - -#: ../source/contribute.rst:40 -msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." -msgstr "" - -#: ../source/contribute.rst:47 -#: ../source/guides/index.rst:2 -msgid "Guides" -msgstr "Guides" - -#: ../source/contribute.rst:49 -msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." -msgstr "" - -#: ../source/contribute.rst:56 -#: ../source/discussions/index.rst:2 -msgid "Discussions" -msgstr "Discussions" - -#: ../source/contribute.rst:58 -msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." -msgstr "" - -#: ../source/contribute.rst:63 -msgid "Specifications" -msgstr "Spécifications" - -#: ../source/contribute.rst:65 -msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." -msgstr "" - -#: ../source/contribute.rst:73 -msgid "Building the guide locally" -msgstr "Compiler le guide localement" - -#: ../source/contribute.rst:75 -msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" -msgstr "" -"Même si ce n'est pas nécessaire pour effectuer des contributions, il peut " -"être utile de compiler le guide localement afin de test vos modifications. " -"Afin de compiler ce guide localement, vous aurez besoin de :" - -#: ../source/contribute.rst:79 -msgid "`Nox `_. You can install or upgrade nox using ``pip``::" -msgstr "" -"`Nox `_. Vous pouvez installer nox en " -"utilisant ``pip``::" - -#: ../source/contribute.rst:84 -msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." -msgstr "" -"Python 3.6. Nos scripts de compilation sont conçus pour fonctionner avec " -"Python 3.6 uniquement. Consultez le `Guide de l'auto-stoppeur pour Python : " -"Installer Python correctement`_ pour installer Python 3.6 sur votre système " -"d'exploitation." - -#: ../source/contribute.rst:91 -msgid "To build the guide, run the following bash command in the source folder::" -msgstr "" -"Pour compiler le guide, exécutez la commande bash suivante dans le dossier " -"source ::" - -#: ../source/contribute.rst:95 -msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." -msgstr "" -"Une fois le processus terminé vous pouvez retrouver le résultat au format " -"HTML dans le dossier ``./build/html``. Vous pouvez ouvrir le fichier ``index." -"html`` pour visualiser le guide dans votre navigateur, mais il est " -"recommandé de déployer le guide sur un serveur HTTP." - -#: ../source/contribute.rst:100 -msgid "You can build the guide and serve it via an HTTP server using the following command::" -msgstr "" -"Vous pouvez compiler le guide et le déployer sur un serveur HTTP en " -"utilisant la commande suivante : :" - -#: ../source/contribute.rst:105 -msgid "The guide will be browsable via http://localhost:8000." -msgstr "Le guide pourra être consulté à l'adresse http://localhost:8000." - -#: ../source/contribute.rst:109 -msgid "Where the guide is deployed" -msgstr "Où le guide est-il déployé ?" - -#: ../source/contribute.rst:111 -msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." -msgstr "" - -#: ../source/contribute.rst:117 -msgid "Style guide" -msgstr "Guide de conception" - -#: ../source/contribute.rst:119 -msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." -msgstr "" - -#: ../source/contribute.rst:126 -msgid "Purpose" -msgstr "Objectif" - -#: ../source/contribute.rst:128 -msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." -msgstr "" -"L'objectif du |PyPUG| est d'être la ressource officielle sur la façon " -"d'empaqueter, publier, et installer des projets Python en utilisant des " -"outils courants." - -#: ../source/contribute.rst:133 -msgid "Scope" -msgstr "Portée" - -#: ../source/contribute.rst:135 -msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." -msgstr "" -"Le guide a pour but de répondre aux questions et de résoudre les problèmes " -"par des recommandations précises et ciblées." - -#: ../source/contribute.rst:138 -msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." -msgstr "" -"Ce guide n'a pas pour but d'être exhaustif et de remplacer la documentation " -"des projets individuels. Par exemple, pip possède des dizaines de commandes, " -"d'options et de paramètres. La documentation de pip décrit chacun d'entre " -"eux en détail, alors que ce guide ne décrit que les parties de pip qui sont " -"nécessaires pour accomplir les tâches spécifiques décrites dans ce guide." - -#: ../source/contribute.rst:146 -msgid "Audience" -msgstr "Public cible" - -#: ../source/contribute.rst:148 -msgid "The audience of this guide is anyone who uses Python with packages." -msgstr "" -"Le public visé par ce guide est toute personne qui utilise Python avec des " -"paquets." - -#: ../source/contribute.rst:150 -msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." -msgstr "" -"N'oubliez pas que la communauté Python est grande et accueillante. Les " -"lecteurs n'ont peut-être pas le même âge, le même genre, le même niveau " -"d'éducation, la même culture et bien d'autres choses encore, mais ils " -"méritent autant que vous d'apprendre à connaître le paquetage." - -#: ../source/contribute.rst:154 -msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." -msgstr "" -"En particulier, gardez à l'esprit que toutes les personnes qui utilisent " -"Python ne se considèrent pas comme des développeurs. Le public de ce guide " -"comprend aussi bien des astronomes, des peintres ou des étudiants que des " -"développeurs de logiciels professionnels." - -#: ../source/contribute.rst:160 -msgid "Voice and tone" -msgstr "Tonalité" - -#: ../source/contribute.rst:162 -msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." -msgstr "" -"Lorsque vous rédigez ce guide, tâchez d'écrire avec un ton accessible et " -"simple, même si vous connaissez toutes les solutions." - -#: ../source/contribute.rst:165 -msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." -msgstr "" -"Imaginez que vous travaillez sur un projet Python avec une personne que vous " -"savez intelligente et compétente. Vous aimez travailler avec elle et elle " -"aime travailler avec vous. Cette personne vous pose une question et vous " -"connaissez la réponse. Comment répondre ? C'est *ainsi* que vous devriez " -"écrire ce guide." - -#: ../source/contribute.rst:170 -msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." -msgstr "" -"Voici une méthode de vérification rapide : essayez de lire à haute voix pour " -"vous faire une idée de la tonalité de votre texte. Est-ce que cela ressemble " -"à ce que vous diriez ou est-ce que vous avez l'impression de jouer un rôle " -"ou de faire un discours ? N'hésitez pas à utiliser des contractions et ne " -"vous souciez pas de respecter des règles de grammaire strictes. Vous avez la " -"permission de terminer une phrase par une préposition, si nécessaire." - -#: ../source/contribute.rst:177 -msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." -msgstr "" -"Lorsque vous rédigez le guide, adaptez votre ton au sérieux et à la " -"difficulté du sujet. Si vous rédigez un didacticiel d'introduction, vous " -"pouvez faire une blague, mais si vous traitez d'une recommandation de " -"sécurité sensible, il est préférable d'éviter toute plaisanterie." - -#: ../source/contribute.rst:184 -msgid "Conventions and mechanics" -msgstr "Conventions et mécanismes" - -#: ../source/contribute.rst:192 -msgid "**Write to the reader**" -msgstr "**Écrivez au lecteur**" - -#: ../source/contribute.rst:187 -msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." -msgstr "" -"Lorsque vous donnez des recommandations ou des étapes à suivre, adressez-" -"vous directement au lecteur en disant *vous* ou utilisez l'impératif." - -#: ../source/contribute.rst:0 -msgid "Wrong: To install it, the user runs…" -msgstr "Mauvais : Pour l'installer, l'utilisateur exécute…" - -#: ../source/contribute.rst:0 -msgid "Right: You can install it by running…" -msgstr "Correct : Vous pouvez l'installer en exécutant…" - -#: ../source/contribute.rst:0 -msgid "Right: To install it, run…" -msgstr "Correct : Pour l'installer, exécutez…" - -#: ../source/contribute.rst:198 -msgid "**State assumptions**" -msgstr "" - -#: ../source/contribute.rst:195 -msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." -msgstr "" - -#: ../source/contribute.rst:203 -msgid "**Cross-reference generously**" -msgstr "" - -#: ../source/contribute.rst:201 -msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." -msgstr "" -"La première fois que vous mentionnez un outil ou une pratique, ajoutez un " -"lien vers la page ou le guide concerné, ou ajoutez un lien vers tout " -"document pertinent. Économisez une recherche au lecteur." - -#: ../source/contribute.rst:213 -msgid "**Respect naming practices**" -msgstr "**Respectez les conventions de nommage**" - -#: ../source/contribute.rst:206 -msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." -msgstr "" -"Lorsque vous nommez des outils, sites, personnes ou autres noms propres, " -"respectez leur casse." - -#: ../source/contribute.rst:0 -msgid "Wrong: Pip uses…" -msgstr "Mauvais : Pip utilise…" - -#: ../source/contribute.rst:0 -msgid "Right: pip uses…" -msgstr "Correct : pip utilise…" - -#: ../source/contribute.rst:0 -msgid "Wrong: …hosted on github." -msgstr "Mauvais : …hébergé sur github." - -#: ../source/contribute.rst:0 -msgid "Right: …hosted on GitHub." -msgstr "Correct : …hébergé sur GitHub." - -#: ../source/contribute.rst:222 -msgid "**Use a gender-neutral style**" -msgstr "**Adoptez un style neutre et non genré**" - -#: ../source/contribute.rst:216 -msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." -msgstr "" -"Souvent, vous vous adresserez au lecteur directement avec *vous*, *votre* et " -"*vos*. Utilisez dans la mesure du possible des formes non genrées, sinon " -"adoptez l'écriture inclusive." - -#: ../source/contribute.rst:0 -msgid "Wrong: A maintainer uploads the file. Then he…" -msgstr "Mauvais : Un mainteneur met en ligne le fichier. Puis il…" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then they…" -msgstr "Correct : Un·e mainteneur·euse met en ligne le fichier. Puis…" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then the maintainer…" -msgstr "" - -#: ../source/contribute.rst:234 -msgid "**Headings**" -msgstr "**Titres**" - -#: ../source/contribute.rst:225 -msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." -msgstr "" -"Rédigez des titres qui utilisent les mots recherchés par le lecteur ou la " -"lectrice. Un bon moyen d'y parvenir est de faire en sorte que votre titre " -"réponde à une question implicite. Par exemple, un lecteur ou une lectrice " -"pourrait vouloir savoir *Comment installer MaBibliothèque ?* et un bon titre " -"pourrait être *Installer MaBibliothèque*." - -#: ../source/contribute.rst:230 -msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." -msgstr "" -"Dans les titres de section, employez la casse des phrases. En d'autres " -"termes, rédigez les titres comme vous le feriez pour une phrase classique." - -#: ../source/contribute.rst:0 -msgid "Wrong: Things You Should Know About Python" -msgstr "Mauvais : Les Choses Que Vous Devez Savoir À Propos de Python" - -#: ../source/contribute.rst:0 -msgid "Right: Things you should know about Python" -msgstr "Correct : Les choses que vous devez savoir à propos de Python" - -#: ../source/contribute.rst:237 -msgid "**Numbers**" -msgstr "**Nombres**" - -#: ../source/contribute.rst:237 -msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." -msgstr "" -"Dans le corps du texte, écrivez les chiffres de un à neuf comme des mots. " -"Pour les autres chiffres ou les chiffres des tableaux, utilisez des " -"caractères numériques." - -#: ../source/discussions/deploying-python-applications.rst:4 -msgid "Deploying Python applications" -msgstr "Déployer des applications Python" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Page Status" -msgstr "État de la page" - -#: ../source/discussions/deploying-python-applications.rst:6 -#: ../source/guides/index-mirrors-and-caches.rst:7 -#: ../source/guides/installing-using-linux-tools.rst:7 -#: ../source/guides/packaging-binary-extensions.rst:7 -#: ../source/guides/supporting-multiple-python-versions.rst:7 -#: ../source/guides/supporting-windows-using-appveyor.rst:5 -msgid "Incomplete" -msgstr "Incomplète" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Last Reviewed" -msgstr "Dernière révision" - -#: ../source/discussions/deploying-python-applications.rst:7 -msgid "2014-11-11" -msgstr "2014-11-11" - -#: ../source/discussions/deploying-python-applications.rst:11 -#: ../source/discussions/install-requires-vs-requirements.rst:9 -#: ../source/guides/analyzing-pypi-package-downloads.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:22 -#: ../source/guides/index-mirrors-and-caches.rst:12 -#: ../source/guides/installing-scientific-packages.rst:9 -#: ../source/guides/packaging-binary-extensions.rst:17 -#: ../source/guides/supporting-multiple-python-versions.rst:12 -#: ../source/guides/supporting-windows-using-appveyor.rst:15 -#: ../source/overview.rst:23 -#: ../source/specifications/core-metadata.rst:38 -#: ../source/specifications/direct-url.rst:14 -#: ../source/tutorials/installing-packages.rst:23 -msgid "Contents" -msgstr "Contenu" - -#: ../source/discussions/deploying-python-applications.rst:14 -msgid "Overview" -msgstr "Aperçu" - -#: ../source/discussions/deploying-python-applications.rst:18 -msgid "Supporting multiple hardware platforms" -msgstr "Prendre en charge plusieurs plateformes matérielles" - -#: ../source/discussions/deploying-python-applications.rst:40 -msgid "OS packaging & installers" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:52 -msgid "Windows" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:61 -msgid "Pynsist" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:63 -msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:70 -msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." -msgstr "" -"Le programme installé peut être lancé à partir d'un raccourci que " -"l'installateur ajoute au menu démarrer. Il utilise un interpréteur Python " -"installé dans son répertoire racine, indépendamment de toute autre " -"installation de Python sur l'ordinateur." - -#: ../source/discussions/deploying-python-applications.rst:74 -msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." -msgstr "" -"L'un des gros avantages de Pynsist est que les paquets Windows peuvent être " -"compilés sous Linux. Il y a plusieurs exemples pour différents types de " -"programmes (console, interface graphique) dans la `documentation " -"`__. L'outil est publié sous licence MIT." - -#: ../source/discussions/deploying-python-applications.rst:80 -msgid "Application bundles" -msgstr "Paquets d'applications" - -#: ../source/discussions/deploying-python-applications.rst:91 -msgid "Configuration management" -msgstr "Gestion de la configuration" - -#: ../source/discussions/index.rst:4 -msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." -msgstr "" -"Les **discussions** ont pour but de fournir une information complète sur un " -"sujet spécifique. Si vous essayez seulement de mener à bien vos tâches, " -"consultez :doc:`/guides/index`." - -#: ../source/discussions/install-requires-vs-requirements.rst:5 -msgid "install_requires vs requirements files" -msgstr "Fichiers requirements vs install_requires" - -#: ../source/discussions/install-requires-vs-requirements.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:382 -msgid "install_requires" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:14 -msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." -msgstr "" -"``install_requires`` est un mot-clé de :ref:`setuptools` :file:`setup.py` " -"qui doit être utilisé pour spécifier ce dont un projet à besoin *au minimum* " -"pour s'exécuter correctement. Lorsque le projet est installé par :ref:`pip`, " -"c'est cette spécification qui est utilisée pour installer ses dépendances." - -#: ../source/discussions/install-requires-vs-requirements.rst:19 -msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" -msgstr "" -"Par exemple, si le projet nécessite A et B, votre ``install_requires`` " -"ressemblerait à ceci :" - -#: ../source/discussions/install-requires-vs-requirements.rst:29 -msgid "Additionally, it's best practice to indicate any known lower or upper bounds." -msgstr "" -"En outre, il est préférable d'indiquer toute limite inférieure ou supérieure " -"connue." - -#: ../source/discussions/install-requires-vs-requirements.rst:31 -msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" -msgstr "" -"Par exemple, on peut savoir que votre projet nécessite au moins la v1 de « A " -"» et la v2 de « B », ce qui donne le résultat suivant :" - -#: ../source/discussions/install-requires-vs-requirements.rst:41 -msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" -msgstr "" -"On peut également savoir que le projet A respecte le système de version " -"sémantique, et que la v2 de « A » indique une rupture de compatibilité, il " -"est donc logique de ne pas autoriser la version 2 :" - -#: ../source/discussions/install-requires-vs-requirements.rst:51 -msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:56 -msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:64 -#: ../source/tutorials/installing-packages.rst:460 -msgid "Requirements files" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:66 -msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:69 -msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:73 -msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:78 -msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:84 -msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:90 -msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:6 -msgid "pip vs easy_install" -msgstr "pip vs easy_install" - -#: ../source/discussions/pip-vs-easy-install.rst:9 -msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:14 -msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:22 -msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**pip**" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**easy_install**" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -msgid "Installs from :term:`Wheels `" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Yes" -msgstr "Oui" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:30 -#: ../source/discussions/pip-vs-easy-install.rst:32 -#: ../source/discussions/pip-vs-easy-install.rst:35 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:51 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "No" -msgstr "Non" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Uninstall Packages" -msgstr "Désinstaller des paquets" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Yes (``python -m pip uninstall``)" -msgstr "Oui (``python -m pip uninstall``)" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Dependency Overrides" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Yes (:ref:`Requirements Files `)" -msgstr "Oui (:ref:`Requirements Files `)" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "List Installed Packages" -msgstr "Lister les paquets installés" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" -msgstr "Oui (``python -m pip list`` et ``python -m pip freeze``)" - -#: ../source/discussions/pip-vs-easy-install.rst:38 -msgid ":pep:`438` Support" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Installation format" -msgstr "Format d'installation" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "'Flat' packages with :file:`egg-info` metadata." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Encapsulated Egg format" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:44 -msgid "sys.path modification" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:48 -msgid "Installs from :term:`Eggs `" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "`pylauncher support`_" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "Yes [1]_" -msgstr "Oui [1]_" - -#: ../source/discussions/pip-vs-easy-install.rst:54 -msgid ":ref:`Multi-version Installs`" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Exclude scripts during install" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "per project index" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Only in virtualenv" -msgstr "Seulement dans virtualenv" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Yes, via setup.cfg" -msgstr "Oui, via setup.cfg" - -#: ../source/discussions/pip-vs-easy-install.rst:68 -msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:5 -msgid "Wheel vs Egg" -msgstr "Wheel vs Egg" - -#: ../source/discussions/wheel-vs-egg.rst:7 -msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:11 -msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:14 -msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:17 -msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:20 -msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:22 -msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:26 -msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:31 -msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:34 -msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:38 -msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:41 -msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:47 -msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." -msgstr "" - -#: ../source/glossary.rst:3 -msgid "Glossary" -msgstr "Glossaire" - -#: ../source/glossary.rst:8 -msgid "Binary Distribution" -msgstr "Distribution binaire" - -#: ../source/glossary.rst:11 -msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." -msgstr "" - -#: ../source/glossary.rst:14 -msgid "Built Distribution" -msgstr "Distribution compilée" - -#: ../source/glossary.rst:17 -msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." -msgstr "" - -#: ../source/glossary.rst:26 -msgid "Distribution Package" -msgstr "" - -#: ../source/glossary.rst:29 -msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." -msgstr "" - -#: ../source/glossary.rst:34 -msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." -msgstr "" - -#: ../source/glossary.rst:41 -msgid "Egg" -msgstr "Egg" - -#: ../source/glossary.rst:44 -msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" -msgstr "" - -#: ../source/glossary.rst:49 -msgid "Extension Module" -msgstr "Module d'extension" - -#: ../source/glossary.rst:52 -msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." -msgstr "" - -#: ../source/glossary.rst:59 -msgid "Known Good Set (KGS)" -msgstr "" - -#: ../source/glossary.rst:62 -msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." -msgstr "" - -#: ../source/glossary.rst:68 -msgid "Import Package" -msgstr "" - -#: ../source/glossary.rst:71 -msgid "A Python module which can contain other modules or recursively, other packages." -msgstr "" - -#: ../source/glossary.rst:74 -msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." -msgstr "" - -#: ../source/glossary.rst:78 -msgid "Module" -msgstr "Module" - -#: ../source/glossary.rst:81 -msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." -msgstr "" - -#: ../source/glossary.rst:84 -msgid "Package Index" -msgstr "" - -#: ../source/glossary.rst:87 -msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." -msgstr "" - -#: ../source/glossary.rst:90 -msgid "Per Project Index" -msgstr "" - -#: ../source/glossary.rst:93 -msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." -msgstr "" - -#: ../source/glossary.rst:97 -msgid "Project" -msgstr "Projet" - -#: ../source/glossary.rst:100 -msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." -msgstr "" - -#: ../source/glossary.rst:104 -msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." -msgstr "" - -#: ../source/glossary.rst:110 -msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." -msgstr "" - -#: ../source/glossary.rst:115 -msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." -msgstr "" - -#: ../source/glossary.rst:121 -msgid "Pure Module" -msgstr "Module pur" - -#: ../source/glossary.rst:124 -msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." -msgstr "" - -#: ../source/glossary.rst:127 -msgid "Python Packaging Authority (PyPA)" -msgstr "" - -#: ../source/glossary.rst:130 -msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." -msgstr "" - -#: ../source/glossary.rst:139 -msgid "Python Package Index (PyPI)" -msgstr "Index des Paquets Python (PyPI)" - -#: ../source/glossary.rst:142 -msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." -msgstr "" -"`PyPI `_ est l':term:`Index de Paquets` par défaut pour la " -"communauté Python. Il est ouvert à tous les développeurs Python pour qu'ils " -"utilisent et distribuent leurs paquets." - -#: ../source/glossary.rst:145 -msgid "pypi.org" -msgstr "pypi.org" - -#: ../source/glossary.rst:148 -msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." -msgstr "" - -#: ../source/glossary.rst:152 -msgid "pyproject.toml" -msgstr "pyproject.toml" - -#: ../source/glossary.rst:155 -msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." -msgstr "" - -#: ../source/glossary.rst:157 -msgid "Release" -msgstr "Version" - -#: ../source/glossary.rst:160 -msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." -msgstr "" -"Une image d'un :term:`Projet` à un certain moment dans le temps, défini par " -"un numéro de version." - -#: ../source/glossary.rst:163 -msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." -msgstr "" - -#: ../source/glossary.rst:168 -msgid "Requirement" -msgstr "" - -#: ../source/glossary.rst:171 -msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." -msgstr "" - -#: ../source/glossary.rst:177 -msgid "Requirement Specifier" -msgstr "" - -#: ../source/glossary.rst:180 -msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" -msgstr "" - -#: ../source/glossary.rst:187 -msgid "Requirements File" -msgstr "" - -#: ../source/glossary.rst:190 -msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." -msgstr "" - -#: ../source/glossary.rst:194 -#: ../source/guides/distributing-packages-using-setuptools.rst:56 -msgid "setup.py" -msgstr "setup.py" - -#: ../source/glossary.rst:195 -#: ../source/guides/distributing-packages-using-setuptools.rst:77 -msgid "setup.cfg" -msgstr "setup.cfg" - -#: ../source/glossary.rst:198 -msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." -msgstr "" - -#: ../source/glossary.rst:201 -msgid "Source Archive" -msgstr "" - -#: ../source/glossary.rst:204 -msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:208 -msgid "Source Distribution (or \"sdist\")" -msgstr "" - -#: ../source/glossary.rst:211 -msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:216 -msgid "System Package" -msgstr "Paquet système" - -#: ../source/glossary.rst:219 -msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." -msgstr "" -"Un paquet fourni dans un format natif au système d'exploitation, par ex. un " -"fichier rpm ou dpkg." - -#: ../source/glossary.rst:222 -msgid "Version Specifier" -msgstr "" - -#: ../source/glossary.rst:225 -msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." -msgstr "" - -#: ../source/glossary.rst:231 -msgid "Virtual Environment" -msgstr "Environnement virtuel" - -#: ../source/glossary.rst:234 -msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/glossary.rst:238 -msgid "Wheel" -msgstr "Wheel" - -#: ../source/glossary.rst:241 -msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." -msgstr "" - -#: ../source/glossary.rst:244 -msgid "Working Set" -msgstr "" - -#: ../source/glossary.rst:247 -msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:3 -msgid "Analyzing PyPI package downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:5 -msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:15 -#: ../source/guides/supporting-windows-using-appveyor.rst:18 -msgid "Background" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:17 -msgid "PyPI does not display download statistics for a number of reasons: [#]_" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:19 -msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:24 -msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:27 -msgid "``pip``'s download cache (lowers download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:28 -msgid "Internal or unofficial mirrors (can both raise or lower download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:29 -msgid "Packages not hosted on PyPI (for comparisons sake)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:30 -msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:32 -msgid "Known historical data quality issues (lowers download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:34 -msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:38 -msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:43 -msgid "Public dataset" -msgstr "Jeu de données public" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:45 -msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:50 -msgid "Getting set up" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:52 -msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:58 -msgid "Navigate to the `BigQuery web UI`_." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:59 -msgid "Create a new project." -msgstr "Créer un nouveau projet." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:60 -msgid "Enable the `BigQuery API `__." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:63 -msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:69 -msgid "Data schema" -msgstr "Schéma de données" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:71 -msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -msgid "Column" -msgstr "Colonne" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/guides/using-manifest-in.rst:67 -#: ../source/specifications/core-metadata.rst:185 -msgid "Description" -msgstr "Description" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/specifications/direct-url.rst:226 -msgid "Examples" -msgstr "Exemples" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "timestamp" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "Date and time" -msgstr "Date et heure" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "``2020-03-09 00:33:03 UTC``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "file.project" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "Project name" -msgstr "Nom du projet" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "``pipenv``, ``nose``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "file.version" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "Package version" -msgstr "Version du paquet" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "``0.1.6``, ``1.4.2``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "details.installer.name" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "Installer" -msgstr "Installateur" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "pip, `bandersnatch`_" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "details.python" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "Python version" -msgstr "Version de Python" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "``2.7.12``, ``3.6.4``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:93 -msgid "Useful queries" -msgstr "Requêtes utiles" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:95 -msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:97 -msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:102 -msgid "Counting package downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:104 -msgid "The following query counts the total number of downloads for the project \"pytest\"." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:119 -#: ../source/guides/analyzing-pypi-package-downloads.rst:140 -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "num_downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:121 -msgid "26190085" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:124 -msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:142 -msgid "24334215" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:146 -msgid "Package downloads over time" -msgstr "Téléchargements de paquets au cours du temps" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:148 -msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -msgid "month" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "1956741" -msgstr "1956741" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "2018-01-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2344692" -msgstr "2344692" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2017-12-01" -msgstr "2017-12-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "1730398" -msgstr "1730398" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "2017-11-01" -msgstr "2017-11-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2047310" -msgstr "2047310" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2017-10-01" -msgstr "2017-10-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "1744443" -msgstr "1744443" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "2017-09-01" -msgstr "2017-09-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "1916952" -msgstr "1916952" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "2017-08-01" -msgstr "2017-08-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:184 -msgid "Python versions over time" -msgstr "Versions de Python au cours du temps" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:186 -msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." -msgstr "" -"Extraie la version de Python à partir de la colonne ``details.python``. " -"Attention : Cette requête traite plus de 500 Go de données." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "python" -msgstr "python" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "3.7" -msgstr "3.7" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "18051328726" -msgstr "18051328726" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "3.6" -msgstr "3.6" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "9635067203" -msgstr "9635067203" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "3.8" -msgstr "3.8" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "7781904681" -msgstr "7781904681" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "2.7" -msgstr "2.7" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "6381252241" -msgstr "6381252241" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "null" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "2026630299" -msgstr "2026630299" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "3.5" -msgstr "3.5" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "1894153540" -msgstr "1894153540" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:221 -msgid "Caveats" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:223 -msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:231 -msgid "Additional tools" -msgstr "Outils supplémentaires" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:233 -msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." -msgstr "" -"En plus de l'utilisation de la console BigQuery, il existe quelques outils " -"supplémentaires qui peuvent être utiles pour analyser les statistiques de " -"téléchargement." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:237 -msgid "``google-cloud-bigquery``" -msgstr "``google-cloud-bigquery``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:239 -msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:267 -msgid "``pypinfo``" -msgstr "``pypinfo``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:269 -msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:273 -msgid "Install `pypinfo`_ using pip." -msgstr "Installez `pypinfo`_ à l'aide de pip." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:279 -msgid "Usage:" -msgstr "Usage :" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:295 -msgid "``pandas-gbq``" -msgstr "``pandas-gbq``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:297 -msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:301 -#: ../source/specifications/binary-distribution-format.rst:459 -msgid "References" -msgstr "Références" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:303 -msgid "`PyPI Download Counts deprecation email `__" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:304 -msgid "`PyPI BigQuery dataset announcement email `__" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:3 -msgid "Creating and discovering plugins" -msgstr "Créer et découvrir des extensions" - -#: ../source/guides/creating-and-discovering-plugins.rst:5 -msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:10 -msgid "There are three major approaches to doing automatic plugin discovery:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:12 -msgid "`Using naming convention`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:13 -msgid "`Using namespace packages`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:14 -msgid "`Using package metadata`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:18 -msgid "Using naming convention" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:20 -msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:38 -msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:48 -msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:59 -msgid "Using namespace packages" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:61 -msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:89 -msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:101 -msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:115 -msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:121 -msgid "Using package metadata" -msgstr "En utilisant les métadonnées du paquet" - -#: ../source/guides/creating-and-discovering-plugins.rst:123 -msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:128 -msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:139 -msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:154 -msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:163 -msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:166 -msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:170 -msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:5 -msgid "Packaging and distributing projects" -msgstr "Paqueter et distribuer des projets" - -#: ../source/guides/distributing-packages-using-setuptools.rst:7 -msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:11 -msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:15 -msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:25 -msgid "Requirements for packaging and distributing" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:26 -msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:29 -msgid "Install \"twine\" [1]_:" -msgstr "Installez « twine » [1]_ :" - -#: ../source/guides/distributing-packages-using-setuptools.rst:43 -msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:49 -msgid "Configuring your project" -msgstr "Configurer votre projet" - -#: ../source/guides/distributing-packages-using-setuptools.rst:53 -msgid "Initial files" -msgstr "Fichiers initiaux" - -#: ../source/guides/distributing-packages-using-setuptools.rst:58 -msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:63 -msgid ":file:`setup.py` serves two primary functions:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:65 -msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:71 -msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:79 -msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:86 -msgid "README.rst / README.md" -msgstr "README.rst / README.md" - -#: ../source/guides/distributing-packages-using-setuptools.rst:88 -msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:95 -msgid "For an example, see `README.md `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:99 -msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:108 -msgid "MANIFEST.in" -msgstr "MANIFEST.in" - -#: ../source/guides/distributing-packages-using-setuptools.rst:110 -msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:115 -msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:119 -msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:122 -msgid "LICENSE.txt" -msgstr "LICENSE.txt" - -#: ../source/guides/distributing-packages-using-setuptools.rst:124 -msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:130 -msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:135 -msgid "" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:137 -msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:141 -msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:149 -msgid "setup() args" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:151 -msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:155 -msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:164 -msgid "name" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:170 -msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:174 -msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:176 -msgid "Start & end with an ASCII letter or digit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:178 -msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:190 -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "version" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:196 -msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:200 -msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:203 -msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:206 -msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:214 -msgid "description" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:222 -msgid "Give a short and long description for your project." -msgstr "Renseignez une description courte et longue pour votre projet." - -#: ../source/guides/distributing-packages-using-setuptools.rst:224 -msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:229 -msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:235 -msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:245 -msgid "url" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:252 -msgid "Give a homepage URL for your project." -msgstr "Renseignez une URL pour la page d'accueil de votre projet." - -#: ../source/guides/distributing-packages-using-setuptools.rst:256 -msgid "author" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:263 -msgid "Provide details about the author." -msgstr "Renseignez des informations sur l'auteur." - -#: ../source/guides/distributing-packages-using-setuptools.rst:267 -msgid "license" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:273 -msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:279 -msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:287 -msgid "classifiers" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:316 -msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." -msgstr "" -"Renseignez une liste de classifieurs qui catégorisent votre projet. Pour la " -"liste complète, consultez https://pypi.org/classifiers/." - -#: ../source/guides/distributing-packages-using-setuptools.rst:319 -msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:327 -msgid "keywords" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:333 -msgid "List keywords that describe your project." -msgstr "Listez les mots-clés qui décrivent votre projet." - -#: ../source/guides/distributing-packages-using-setuptools.rst:337 -msgid "project_urls" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:349 -msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:355 -msgid "packages" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:361 -msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:370 -msgid "py_modules" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:376 -msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:388 -msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:392 -msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:398 -msgid "python_requires" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:400 -msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:407 -msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:412 -msgid "And so on." -msgstr "Et ainsi de suite." - -#: ../source/guides/distributing-packages-using-setuptools.rst:416 -msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:422 -msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:431 -msgid "package_data" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:440 -msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:445 -msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:449 -msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:457 -msgid "data_files" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:463 -msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:469 -msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:479 -msgid "For more information see the distutils section on `Installing Additional Files `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:484 -msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:491 -msgid "scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:493 -msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:500 -msgid "entry_points" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:509 -msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:512 -msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:516 -msgid "The most commonly used entry point is \"console_scripts\" (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:521 -msgid "console_scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:531 -msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:538 -msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:545 -msgid "Choosing a versioning scheme" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:548 -msgid "Standards compliance for interoperability" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:550 -msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:556 -msgid "Here are some examples of compliant version numbers::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:567 -msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:573 -msgid "Scheme choices" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:576 -msgid "Semantic versioning (preferred)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:578 -msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:582 -msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:585 -msgid "MAJOR version when they make incompatible API changes," -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:586 -msgid "MINOR version when they add functionality in a backwards-compatible manner, and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:587 -msgid "MAINTENANCE version when they make backwards-compatible bug fixes." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:589 -msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:594 -msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:598 -msgid "Date based versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:600 -msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:604 -msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:607 -msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:611 -msgid "Serial versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:613 -msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:616 -msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:621 -msgid "Hybrid schemes" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:623 -msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:629 -msgid "Pre-release versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:631 -msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:634 -msgid "zero or more dev releases (denoted with a \".devN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:635 -msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:636 -msgid "zero or more beta releases (denoted with a \".bN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:637 -msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:639 -msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:644 -msgid "Local version identifiers" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:646 -msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:653 -msgid "A local version identifier takes the form ``+``. For example::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:661 -msgid "Working in \"development mode\"" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:663 -msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:667 -msgid "Assuming you're in the root of your project directory, then run:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:674 -msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:680 -msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:688 -msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:692 -msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:697 -msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:701 -msgid "Lastly, if you don't want to install any dependencies at all, you can run::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:706 -msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:713 -msgid "Packaging your project" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:715 -msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:720 -msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:737 -msgid "Source distributions" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:739 -msgid "Minimally, you should create a :term:`Source Distribution `:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:755 -msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:763 -msgid "Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:765 -msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:770 -msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:773 -msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:776 -msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:785 -msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:792 -msgid "Pure Python Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:794 -msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:797 -#: ../source/guides/distributing-packages-using-setuptools.rst:826 -msgid "To build the wheel:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:811 -msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:815 -msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:821 -msgid "Platform Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:823 -msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:841 -msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:847 -msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:855 -msgid "Uploading your Project to PyPI" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:857 -msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:861 -msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:866 -msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:871 -msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:877 -msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:888 -msgid "Create an account" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:890 -msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:894 -msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:897 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:901 -msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:904 -msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:913 -msgid "**Be aware that this stores your token in plaintext.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:915 -#: ../source/guides/migrating-to-pypi-org.rst:70 -#: ../source/guides/migrating-to-pypi-org.rst:109 -#: ../source/guides/using-testpypi.rst:83 -msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:921 -msgid "Upload your distributions" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:923 -msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:926 -msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:930 -msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:937 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:944 -#: ../source/tutorials/installing-packages.rst:663 -msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:950 -msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:5 -msgid "Dropping support for older Python versions" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:7 -msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:9 -msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:12 -msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:14 -msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:17 -msgid "Requirements" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:19 -msgid "This workflow requires that:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:21 -msgid "The publisher is using the latest version of :ref:`setuptools`," -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:22 -msgid "The latest version of :ref:`twine` is used to upload the package," -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:23 -msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:26 -msgid "Dealing with the universal wheels" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:28 -msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:36 -msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:48 -msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:53 -msgid "Defining the Python version required" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:56 -msgid "1. Download the newest version of Setuptools" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:58 -msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:60 -msgid "Steps:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:74 -msgid "`setuptools` version should be above 24.0.0." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:77 -msgid "2. Specify the version ranges for supported Python distributions" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:79 -msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:81 -#: ../source/specifications/core-metadata.rst:139 -#: ../source/specifications/core-metadata.rst:463 -#: ../source/specifications/core-metadata.rst:487 -#: ../source/specifications/core-metadata.rst:527 -#: ../source/specifications/core-metadata.rst:550 -#: ../source/specifications/core-metadata.rst:583 -#: ../source/specifications/core-metadata.rst:693 -#: ../source/specifications/core-metadata.rst:722 -msgid "Examples::" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:86 -msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:101 -msgid "3. Validating the Metadata before publishing" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:103 -msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:105 -msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:108 -msgid "You can see the contents of the generated file like this::" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:112 -msgid "Validate that the following is in place, before publishing the package:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:114 -msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:115 -msgid "The Requires-Python field is set and matches your specification in setup.py." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:118 -msgid "4. Using Twine to publish" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:120 -msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:122 -msgid "Make sure you are using the newest version of Twine, at least 1.9." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:125 -msgid "Dropping a Python release" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:127 -msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:129 -msgid "It must be done in this order for the automated fallback to work." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:131 -msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:133 -msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:5 -msgid "Hosting your own simple repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:8 -msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:13 -msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:29 -msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:35 -msgid "\"Manual\" repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:37 -msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:51 -msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:58 -msgid "For complete documentation of the simple repository protocol, see :pep:`503`." -msgstr "" - -#: ../source/guides/index.rst:8 -#: ../source/guides/index.rst:8 -msgid "Installing Packages:" -msgstr "" - -#: ../source/guides/index.rst:20 -#: ../source/guides/index.rst:20 -msgid "Building and Publishing Projects:" -msgstr "" - -#: ../source/guides/index.rst:38 -#: ../source/guides/index.rst:38 -msgid "Miscellaneous:" -msgstr "" - -#: ../source/guides/index.rst:4 -msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:5 -msgid "Package index mirrors and caches" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:8 -#: ../source/guides/supporting-multiple-python-versions.rst:8 -msgid "2014-12-24" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:14 -msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:17 -msgid "Three options are available in this area:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:19 -msgid "pip provides local caching options," -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:20 -msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:22 -msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:27 -msgid "Caching with pip" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:29 -msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:32 -msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:36 -msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:45 -msgid "Caching with devpi" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:47 -msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:55 -msgid "Complete mirror with bandersnatch" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:57 -msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:63 -msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:5 -msgid "Installing scientific packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:11 -msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:16 -msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:22 -msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:29 -msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:35 -msgid "Building from source" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:37 -msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:45 -msgid "Linux distribution packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:47 -msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:51 -msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:57 -msgid "Windows installers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:59 -msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:64 -msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:67 -msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:73 -msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:79 -msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:86 -msgid "macOS installers and package managers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:88 -msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:92 -msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:99 -msgid "SciPy distributions" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:101 -msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:105 -msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:109 -#: ../source/key_projects.rst:596 -msgid "Spack" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:110 -msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:119 -msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:128 -msgid "The conda cross-platform package manager" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:130 -msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:136 -msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 -msgid "Installing stand alone command line tools" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 -msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 -msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 -msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 -msgid "pipx only works with Python 3.6+." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 -msgid "``pipx`` is installed with ``pip``:" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 -msgid "You may need to restart your terminal for the path updates to take effect." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 -msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 -#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 -msgid "For example" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 -msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 -msgid "To upgrade or uninstall the package" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 -msgid "``pipx`` can be upgraded or uninstalled with pip" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 -msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 -msgid "To see the full list of commands ``pipx`` offers, run" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 -msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:5 -msgid "Installing pip/setuptools/wheel with Linux Package Managers" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:8 -msgid "2015-09-17" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:11 -msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:14 -msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:18 -msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:25 -msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:32 -msgid "Fedora" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:34 -msgid "Fedora 21:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:36 -#: ../source/guides/installing-using-linux-tools.rst:45 -#: ../source/guides/installing-using-linux-tools.rst:124 -#: ../source/guides/installing-using-linux-tools.rst:138 -#: ../source/guides/installing-using-linux-tools.rst:158 -msgid "Python 2::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:41 -msgid "Python 3: ``sudo yum install python3 python3-wheel``" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:43 -msgid "Fedora 22:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:50 -msgid "Python 3: ``sudo dnf install python3 python3-wheel``" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:53 -msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:63 -msgid "CentOS/RHEL" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:65 -msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:68 -msgid "To install pip and wheel for the system Python, there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:70 -msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:77 -msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:81 -msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:85 -msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:92 -msgid "To additionally upgrade setuptools, run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:97 -msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:101 -msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:104 -msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:106 -msgid "For CentOS, see here: https://www.softwarecollections.org/en/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:108 -msgid "Be aware that collections may not contain the most recent versions." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:110 -msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:116 -msgid "For example, for Python 3.4 on CentOS7/RHEL7::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:122 -msgid "openSUSE" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:129 -#: ../source/guides/installing-using-linux-tools.rst:143 -#: ../source/guides/installing-using-linux-tools.rst:162 -msgid "Python 3::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:135 -msgid "Debian/Ubuntu" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:150 -msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:156 -msgid "Arch Linux" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:168 -msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 -msgid "Installing packages using pip and virtual environments" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 -msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 -msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 -msgid "Installing pip" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 -msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 -msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 -msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 -msgid "Afterwards, you should have the newest pip installed in your user site:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 -msgid "The Python installers for Windows include pip. You should be able to access pip using:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 -msgid "You can make sure that pip is up-to-date by running:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 -msgid "Installing virtualenv" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 -msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 -msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 -msgid "Creating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 -msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 -msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 -msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 -msgid "venv will create a virtual Python installation in the ``env`` folder." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 -msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 -msgid "Activating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 -msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 -msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 -msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 -msgid "Leaving the virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 -msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 -msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 -msgid "Installing packages" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 -msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 -msgid "pip should download requests and all of its dependencies and install them:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 -msgid "Installing specific versions" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 -msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 -msgid "To install the latest ``2.x`` release of requests:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 -msgid "To install pre-release versions of packages, use the ``--pre`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 -msgid "Installing extras" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 -msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 -msgid "Installing from source" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 -msgid "pip can install a package directly from source, for example:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 -msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 -msgid "Installing from version control systems" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 -msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 -msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 -#: ../source/tutorials/installing-packages.rst:569 -msgid "Installing from local archives" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 -msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 -msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 -msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 -msgid "Using other package indexes" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 -msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 -msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 -#: ../source/tutorials/installing-packages.rst:389 -msgid "Upgrading packages" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 -msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 -msgid "Using requirements files" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 -msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 -msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 -msgid "Freezing dependencies" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 -msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 -msgid "Which will output a list of package specifiers such as:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 -msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:2 -msgid "Making a PyPI-friendly README" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:4 -msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:9 -msgid "Creating a README file" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:11 -msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:13 -msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:16 -msgid "plain text" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:17 -msgid "`reStructuredText `_ (without Sphinx extensions)" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:18 -msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:21 -msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:25 -msgid "Including your README in your package's metadata" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:27 -msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:33 -msgid ":ref:`description-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:34 -msgid ":ref:`description-content-type-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:36 -msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:39 -msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:45 -msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:60 -msgid "The minimum required versions of the respective tools are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:62 -msgid "``setuptools >= 38.6.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:63 -msgid "``wheel >= 0.31.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:64 -msgid "``twine >= 1.11.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:66 -msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:72 -msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:95 -msgid "Validating reStructuredText markup" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:97 -msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:100 -msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:105 -msgid "You can check your README for markup errors before uploading as follows:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:107 -msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:122 -msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:125 -msgid "Run ``twine check`` on the sdist and wheel::" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:129 -msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:4 -msgid "Migrating to PyPI.org" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:6 -msgid ":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``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:12 -msgid "Publishing releases" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:14 -msgid "``pypi.org`` is the default upload platform as of September 2016." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:16 -msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:19 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:22 -msgid "The default upload settings switched to ``pypi.org`` in the following versions:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:24 -msgid "``twine`` 1.8.0" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:25 -msgid "``setuptools`` 27.0.0" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:26 -msgid "Python 2.7.13 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:27 -msgid "Python 3.4.6 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:28 -msgid "Python 3.5.3 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:29 -msgid "Python 3.6.0 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:31 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:48 -msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:51 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:67 -msgid "(``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.)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:73 -msgid "Registering package names & metadata" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:75 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:79 -msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:84 -msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:89 -#: ../source/guides/using-testpypi.rst:5 -msgid "Using TestPyPI" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:91 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:113 -msgid "Registering new user accounts" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:115 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:121 -msgid "Browsing packages" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:123 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:130 -msgid "Downloading packages" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:132 -msgid "``pypi.org`` is the default host for downloading packages." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:135 -msgid "Managing published packages and releases" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:137 -msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:5 -msgid "Multi-version installs" -msgstr "" - -#: ../source/guides/multi-version-installs.rst:8 -msgid "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``)." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:13 -msgid "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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:19 -msgid "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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:31 -msgid "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 ``python -c ''`` to invoke the application's main entry point directly." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:38 -msgid "Refer to the `pkg_resources documentation `__ for more details." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:5 -msgid "Packaging binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:8 -msgid "2013-12-08" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:10 -msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:20 -msgid "An overview of binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:23 -msgid "Use cases" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:25 -msgid "The typical use cases for binary extensions break down into just three conventional categories:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:28 -msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:39 -msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:47 -msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:56 -msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:61 -msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:71 -msgid "Disadvantages" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:73 -msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:80 -msgid "This means that binary extensions:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:82 -msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:85 -msgid "may not be compatible with different builds of the CPython reference interpreter" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:88 -msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:91 -msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:96 -msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:101 -msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:108 -msgid "Alternatives to handcoded accelerator modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:110 -msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:115 -msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:122 -msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:132 -msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:141 -msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:150 -msgid "Alternatives to handcoded wrapper modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:152 -msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:158 -msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:162 -msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:168 -msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:175 -msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:181 -msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:185 -msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:189 -msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:203 -msgid "Alternatives for low level system access" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:205 -msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:213 -msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:222 -msgid "Implementing binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:224 -msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:241 -msgid "Building binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:244 -msgid "Building extensions for multiple platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:246 -msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:256 -msgid "Binary extensions for Windows" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:258 -msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:263 -msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:269 -msgid "To set up a build environment for binary extensions, the steps are as follows:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:271 -msgid "For Python 2.7" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:273 -msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:276 -msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:278 -#: ../source/guides/packaging-binary-extensions.rst:288 -#: ../source/guides/packaging-binary-extensions.rst:295 -msgid "Done." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:280 -msgid "For Python 3.4" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:282 -msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:285 -msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:287 -msgid "Set DISTUTILS_USE_SDK=1" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:290 -msgid "For Python 3.5" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:292 -msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:297 -msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:301 -msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:305 -msgid "Binary extensions for Linux" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:307 -msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:313 -msgid "Binary extensions for macOS" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:315 -msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:325 -msgid "Publishing binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:327 -msgid "For interim guidance on this topic, see the discussion in `this issue `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:343 -msgid "Additional resources" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:345 -msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:352 -msgid "Cross-platform wheel generation with scikit-build" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:354 -msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:362 -msgid "Introduction to C/C++ extension modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:364 -msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:367 -msgid "`What are (c)python extension modules? `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:368 -msgid "`Releasing the gil `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:369 -msgid "`Writing cpython extension modules using C++ `_" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:3 -msgid "Packaging namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:5 -msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:24 -msgid "And you use this package in your code like so::" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:29 -msgid "Then you can break these sub-packages into two separate distributions:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:46 -msgid "Each sub-package can now be separately installed, used, and versioned." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:48 -msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:58 -msgid "Creating a namespace package" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:60 -msgid "There are currently three different approaches to creating namespace packages:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:62 -msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:66 -msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:69 -msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:73 -msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:80 -msgid "Native namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:82 -msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:97 -msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:102 -msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:117 -msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:123 -msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:129 -msgid "pkgutil-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:131 -msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:136 -msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:148 -#: ../source/guides/packaging-namespace-packages.rst:194 -msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:155 -#: ../source/guides/packaging-namespace-packages.rst:201 -msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:160 -msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:171 -msgid "pkg_resources-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:173 -msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:182 -msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:206 -msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:216 -msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:223 -msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:237 -msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 -msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 -msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 -msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 -msgid "Saving credentials on GitHub" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 -msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 -msgid "Let's begin! 🚀" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 -msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 -msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 -msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 -msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 -msgid "Creating a workflow definition" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 -msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 -msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 -msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 -msgid "Defining a workflow job environment" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 -msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 -msgid "Checking out the project and building distributions" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 -msgid "Then, add the following under the ``build-n-publish`` section:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 -msgid "This will download your repository into the CI runner and then install and activate Python 3.7." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 -msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 -msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 -msgid "So add this to the steps list:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 -msgid "Publishing the distribution to PyPI and TestPyPI" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 -msgid "Finally, add the following steps at the end:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 -msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 -msgid "That's all, folks!" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 -msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:5 -msgid "Single-sourcing the package version" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:8 -msgid "There are many techniques to maintain a single source of truth for the version number of your project:" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:11 -msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:38 -msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:47 -msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:52 -msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:55 -msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:58 -msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:65 -msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:76 -msgid "Example using this technique: `warehouse `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:78 -msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:86 -msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:91 -msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:95 -msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:110 -msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:114 -msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:128 -msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:134 -msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:138 -msgid "Example using this technique: `setuptools `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:141 -msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:155 -msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:161 -msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:5 -msgid "Supporting multiple Python versions" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:37 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:43 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:49 -msgid "Automated testing and continuous integration" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:51 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:56 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:60 -msgid "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:" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:66 -msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:69 -msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:80 -msgid "Both `Travis CI`_ 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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:85 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:89 -msgid "Tools for single-source Python packages" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:91 -msgid "`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_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:100 -msgid "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" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:107 -msgid "a Python 2 (by syntax) module in a Python 3 project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:108 -msgid "a Python 3 (by syntax) module in a *Python 2* project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:110 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:117 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:124 -msgid "What's in which Python?" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:126 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:3 -msgid "Supporting Windows using Appveyor" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:6 -msgid "2015-12-03" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:8 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:20 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:24 -msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:30 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:38 -msgid "Setting up" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:40 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:45 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:49 -msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:54 -msgid "Adding Appveyor support to your project" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:56 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:61 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:69 -msgid "appveyor.yml" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:75 -msgid "This file can be downloaded from `here `__." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:77 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:80 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:88 -msgid "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``)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:94 -msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:97 -msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:100 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:109 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:114 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:119 -msgid "Support script" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:121 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:126 -msgid "`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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:133 -msgid "You can simply download the batch file and include it in your project unchanged." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:137 -msgid "Access to the built wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:139 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:147 -msgid "Additional notes" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:150 -msgid "Testing with tox" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:152 -msgid "Many projects use the `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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:156 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:160 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:165 -msgid "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" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:170 -msgid "``DISTUTILS_USE_SDK``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:171 -msgid "``MSSdk``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:172 -msgid "``INCLUDE``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:173 -msgid "``LIB``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:175 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:181 -msgid "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 Travis or 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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:188 -msgid "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``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:192 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:197 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:203 -msgid "Automatically uploading wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:205 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:210 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:216 -msgid "External dependencies" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:218 -msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:221 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:230 -msgid "Support scripts" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:232 -msgid "For reference, the SDK setup support script is listed here:" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:234 -msgid "``appveyor-sample/build.cmd``" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:5 -msgid "Tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:7 -msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:12 -msgid "Application dependency management" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:14 -msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:18 -msgid "When ``pipenv`` does not meet your use case, consider other tools like:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:20 -msgid ":ref:`pip`" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:22 -msgid "`pip-tools `_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:24 -msgid "`Poetry `_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:27 -msgid "Installation tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:29 -msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:34 -msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:37 -msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:40 -msgid ":ref:`buildout`: primarily focused on the web development community" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:42 -msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:47 -msgid "Packaging tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:49 -msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:52 -msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:56 -msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:61 -msgid "Publishing platform migration" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:63 -msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:67 -msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:72 -msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:77 -msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:82 -msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:88 -msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:93 -msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:102 -msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:107 -msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:5 -msgid "Including files in source distributions with ``MANIFEST.in``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:7 -msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:17 -msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:22 -msgid "How files are included in an sdist" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:24 -msgid "The following files are included in a source distribution by default:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:26 -msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:28 -msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:30 -msgid "scripts specified by the ``scripts`` ``setup()`` argument" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:31 -msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:33 -msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:35 -msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:37 -msgid "all files matching the pattern :file:`test/test*.py`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:38 -msgid ":file:`setup.py` (or whatever you called your setup script)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:39 -msgid ":file:`setup.cfg`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:40 -msgid ":file:`README`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:41 -msgid ":file:`README.txt`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:42 -msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:43 -msgid ":file:`README.md` (setuptools 36.4.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:44 -msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:45 -msgid ":file:`MANIFEST.in`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:47 -msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:52 -msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:60 -msgid ":file:`MANIFEST.in` commands" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:62 -msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:67 -msgid "Command" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:69 -msgid ":samp:`include {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:69 -msgid "Add all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid ":samp:`exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid "Remove all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid ":samp:`global-include {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid "Add all files anywhere in the source tree matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid ":samp:`global-exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid "Remove all files anywhere in the source tree matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid ":samp:`graft {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid "Add all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid ":samp:`prune {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid "Remove all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:79 -msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:87 -msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:91 -msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:95 -msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:101 -msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." -msgstr "" - -#: ../source/guides/using-testpypi.rst:7 -msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" -msgstr "" - -#: ../source/guides/using-testpypi.rst:13 -msgid "Registering your account" -msgstr "" - -#: ../source/guides/using-testpypi.rst:15 -msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." -msgstr "" - -#: ../source/guides/using-testpypi.rst:19 -msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." -msgstr "" - -#: ../source/guides/using-testpypi.rst:24 -msgid "Using TestPyPI with Twine" -msgstr "" - -#: ../source/guides/using-testpypi.rst:26 -msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:33 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." -msgstr "" - -#: ../source/guides/using-testpypi.rst:39 -msgid "Using TestPyPI with pip" -msgstr "" - -#: ../source/guides/using-testpypi.rst:41 -msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:56 -msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" -msgstr "" - -#: ../source/guides/using-testpypi.rst:73 -msgid "Setting up TestPyPI in :file:`.pypirc`" -msgstr "" - -#: ../source/guides/using-testpypi.rst:75 -msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" -msgstr "" - -#: ../source/index.rst:3 -#: ../source/key_projects.rst:181 -msgid "Python Packaging User Guide" -msgstr "" - -#: ../source/index.rst:5 -msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." -msgstr "" - -#: ../source/index.rst:5 -msgid "python, packaging, guide, tutorial" -msgstr "" - -#: ../source/index.rst:24 -msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." -msgstr "" - -#: ../source/index.rst:28 -msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" -msgstr "" - -#: ../source/index.rst:36 -msgid "Get started" -msgstr "" - -#: ../source/index.rst:38 -msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" -msgstr "" - -#: ../source/index.rst:41 -msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" -msgstr "" - -#: ../source/index.rst:43 -msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" -msgstr "" - -#: ../source/index.rst:45 -msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" -msgstr "" - -#: ../source/index.rst:47 -msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" -msgstr "" - -#: ../source/index.rst:52 -msgid "Learn more" -msgstr "" - -#: ../source/index.rst:54 -msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" -msgstr "" - -#: ../source/index.rst:56 -msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." -msgstr "" - -#: ../source/index.rst:58 -msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." -msgstr "" - -#: ../source/index.rst:60 -msgid "The :doc:`specifications/index` section for packaging interoperability specifications." -msgstr "" - -#: ../source/index.rst:62 -msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." -msgstr "" - -#: ../source/key_projects.rst:6 -msgid "Project Summaries" -msgstr "" - -#: ../source/key_projects.rst:8 -msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." -msgstr "" - -#: ../source/key_projects.rst:14 -msgid "PyPA Projects" -msgstr "" - -#: ../source/key_projects.rst:19 -msgid "bandersnatch" -msgstr "" - -#: ../source/key_projects.rst:21 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:25 -msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." -msgstr "" - -#: ../source/key_projects.rst:35 -msgid "build" -msgstr "" - -#: ../source/key_projects.rst:37 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:42 -msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." -msgstr "" - -#: ../source/key_projects.rst:49 -msgid "cibuildwheel" -msgstr "" - -#: ../source/key_projects.rst:51 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" -msgstr "" - -#: ../source/key_projects.rst:58 -msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." -msgstr "" - -#: ../source/key_projects.rst:64 -msgid "distlib" -msgstr "" - -#: ../source/key_projects.rst:66 -msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:71 -msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." -msgstr "" - -#: ../source/key_projects.rst:80 -msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." -msgstr "" - -#: ../source/key_projects.rst:90 -msgid "packaging" -msgstr "" - -#: ../source/key_projects.rst:92 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:97 -msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." -msgstr "" - -#: ../source/key_projects.rst:99 -msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." -msgstr "" - -#: ../source/key_projects.rst:107 -msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." -msgstr "" - -#: ../source/key_projects.rst:119 -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "pip" -msgstr "" - -#: ../source/key_projects.rst:121 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:126 -msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." -msgstr "" - -#: ../source/key_projects.rst:129 -msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." -msgstr "" - -#: ../source/key_projects.rst:137 -msgid "Pipenv" -msgstr "" - -#: ../source/key_projects.rst:139 -msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:144 -msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." -msgstr "" - -#: ../source/key_projects.rst:148 -msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." -msgstr "" - -#: ../source/key_projects.rst:159 -msgid "Pipfile" -msgstr "" - -#: ../source/key_projects.rst:161 -msgid "`Source `__" -msgstr "" - -#: ../source/key_projects.rst:163 -msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." -msgstr "" - -#: ../source/key_projects.rst:170 -msgid "pipx" -msgstr "" - -#: ../source/key_projects.rst:172 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:176 -msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." -msgstr "" - -#: ../source/key_projects.rst:183 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:187 -msgid "This guide!" -msgstr "" - -#: ../source/key_projects.rst:192 -msgid "readme_renderer" -msgstr "" - -#: ../source/key_projects.rst:194 -msgid "`GitHub and docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:197 -msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." -msgstr "" - -#: ../source/key_projects.rst:208 -msgid "setuptools" -msgstr "" - -#: ../source/key_projects.rst:210 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:215 -msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." -msgstr "" - -#: ../source/key_projects.rst:220 -msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." -msgstr "" - -#: ../source/key_projects.rst:227 -msgid "trove-classifiers" -msgstr "" - -#: ../source/key_projects.rst:229 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:233 -msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." -msgstr "" - -#: ../source/key_projects.rst:239 -msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." -msgstr "" - -#: ../source/key_projects.rst:253 -msgid "twine" -msgstr "" - -#: ../source/key_projects.rst:255 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:260 -msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." -msgstr "" - -#: ../source/key_projects.rst:270 -#: ../source/overview.rst:415 -msgid "virtualenv" -msgstr "" - -#: ../source/key_projects.rst:272 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:277 -msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/key_projects.rst:290 -msgid "Warehouse" -msgstr "" - -#: ../source/key_projects.rst:292 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:296 -msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." -msgstr "" - -#: ../source/key_projects.rst:304 -msgid "wheel" -msgstr "" - -#: ../source/key_projects.rst:306 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:311 -msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." -msgstr "" - -#: ../source/key_projects.rst:315 -msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." -msgstr "" - -#: ../source/key_projects.rst:324 -msgid "Non-PyPA Projects" -msgstr "" - -#: ../source/key_projects.rst:329 -msgid "bento" -msgstr "" - -#: ../source/key_projects.rst:331 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:336 -msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." -msgstr "" - -#: ../source/key_projects.rst:344 -msgid "buildout" -msgstr "" - -#: ../source/key_projects.rst:346 -msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:351 -msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." -msgstr "" - -#: ../source/key_projects.rst:358 -msgid "conda" -msgstr "" - -#: ../source/key_projects.rst:360 -msgid "`Docs `__" -msgstr "" - -#: ../source/key_projects.rst:362 -msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." -msgstr "" - -#: ../source/key_projects.rst:369 -msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." -msgstr "" - -#: ../source/key_projects.rst:373 -msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." -msgstr "" - -#: ../source/key_projects.rst:386 -msgid "devpi" -msgstr "" - -#: ../source/key_projects.rst:388 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:392 -msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." -msgstr "" - -#: ../source/key_projects.rst:401 -msgid "flit" -msgstr "" - -#: ../source/key_projects.rst:403 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:407 -msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." -msgstr "" - -#: ../source/key_projects.rst:412 -msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." -msgstr "" - -#: ../source/key_projects.rst:422 -msgid "enscons" -msgstr "" - -#: ../source/key_projects.rst:424 -msgid "`Source `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:428 -msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." -msgstr "" - -#: ../source/key_projects.rst:443 -msgid "Hashdist" -msgstr "" - -#: ../source/key_projects.rst:445 -msgid "`Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:448 -msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." -msgstr "" - -#: ../source/key_projects.rst:460 -msgid "hatch" -msgstr "" - -#: ../source/key_projects.rst:462 -msgid "`GitHub and Docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:465 -msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." -msgstr "" - -#: ../source/key_projects.rst:475 -msgid "multibuild" -msgstr "" - -#: ../source/key_projects.rst:477 -msgid "`GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:479 -msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." -msgstr "" - -#: ../source/key_projects.rst:485 -msgid "pex" -msgstr "" - -#: ../source/key_projects.rst:487 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:491 -msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." -msgstr "" - -#: ../source/key_projects.rst:500 -msgid "pip-tools" -msgstr "" - -#: ../source/key_projects.rst:502 -msgid "`GitHub and Docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:505 -msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." -msgstr "" - -#: ../source/key_projects.rst:517 -msgid "piwheels" -msgstr "" - -#: ../source/key_projects.rst:519 -msgid "`Website `__ | `Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:523 -msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." -msgstr "" - -#: ../source/key_projects.rst:532 -msgid "poetry" -msgstr "" - -#: ../source/key_projects.rst:534 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:538 -msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." -msgstr "" - -#: ../source/key_projects.rst:548 -msgid "pypiserver" -msgstr "" - -#: ../source/key_projects.rst:550 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:554 -msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." -msgstr "" - -#: ../source/key_projects.rst:564 -msgid "scikit-build" -msgstr "" - -#: ../source/key_projects.rst:566 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:570 -msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." -msgstr "" - -#: ../source/key_projects.rst:582 -msgid "shiv" -msgstr "" - -#: ../source/key_projects.rst:584 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:588 -msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." -msgstr "" - -#: ../source/key_projects.rst:598 -msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" -msgstr "" - -#: ../source/key_projects.rst:603 -msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." -msgstr "" - -#: ../source/key_projects.rst:611 -msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." -msgstr "" - -#: ../source/key_projects.rst:617 -msgid "zest.releaser" -msgstr "" - -#: ../source/key_projects.rst:619 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:623 -msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." -msgstr "" - -#: ../source/key_projects.rst:630 -msgid "Standard Library Projects" -msgstr "" - -#: ../source/key_projects.rst:635 -msgid "ensurepip" -msgstr "" - -#: ../source/key_projects.rst:637 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:640 -msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." -msgstr "" - -#: ../source/key_projects.rst:649 -msgid "distutils" -msgstr "" - -#: ../source/key_projects.rst:651 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:654 -msgid "The original Python packaging system, added to the standard library in Python 2.0." -msgstr "" - -#: ../source/key_projects.rst:657 -msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." -msgstr "" - -#: ../source/key_projects.rst:670 -msgid "venv" -msgstr "" - -#: ../source/key_projects.rst:672 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:675 -msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/news.rst:2 -msgid "News" -msgstr "" - -#: ../source/news.rst:5 -msgid "September 2019" -msgstr "" - -#: ../source/news.rst:6 -msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" -msgstr "" - -#: ../source/news.rst:9 -msgid "August 2019" -msgstr "" - -#: ../source/news.rst:10 -msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" -msgstr "" - -#: ../source/news.rst:13 -msgid "July 2019" -msgstr "" - -#: ../source/news.rst:14 -msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" -msgstr "" - -#: ../source/news.rst:15 -msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" -msgstr "" - -#: ../source/news.rst:16 -msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" -msgstr "" - -#: ../source/news.rst:17 -msgid "Updated directory layout examples for consistency. (:pr:`611`)" -msgstr "" - -#: ../source/news.rst:18 -msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" -msgstr "" - -#: ../source/news.rst:21 -msgid "June 2019" -msgstr "" - -#: ../source/news.rst:22 -msgid "Fixed some typos. (:pr:`620`)" -msgstr "" - -#: ../source/news.rst:25 -msgid "May 2019" -msgstr "" - -#: ../source/news.rst:26 -msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" -msgstr "" - -#: ../source/news.rst:27 -msgid "Added a MANIFEST.in guide page. (:pr:`609`)" -msgstr "" - -#: ../source/news.rst:30 -msgid "April 2019" -msgstr "" - -#: ../source/news.rst:31 -msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" -msgstr "" - -#: ../source/news.rst:32 -msgid "Reduced emphasis on virtualenv. (:pr:`606`)" -msgstr "" - -#: ../source/news.rst:35 -msgid "March 2019" -msgstr "" - -#: ../source/news.rst:36 -msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" -msgstr "" - -#: ../source/news.rst:37 -msgid "Covered RTD details for contributing. (:pr:`600`)" -msgstr "" - -#: ../source/news.rst:40 -msgid "February 2019" -msgstr "" - -#: ../source/news.rst:41 -msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" -msgstr "" - -#: ../source/news.rst:42 -msgid "Added instructions to install Python CLI applications. (:pr:`594`)" -msgstr "" - -#: ../source/news.rst:45 -msgid "January 2019" -msgstr "" - -#: ../source/news.rst:46 -msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" -msgstr "" - -#: ../source/news.rst:47 -msgid "Updated Sphinx and Nox. (:pr:`591`)" -msgstr "" - -#: ../source/news.rst:48 -msgid "Referenced Twine from Python3. (:pr:`581`)" -msgstr "" - -#: ../source/news.rst:51 -msgid "December 2018" -msgstr "" - -#: ../source/news.rst:52 -msgid "No programmers in the office!" -msgstr "" - -#: ../source/news.rst:55 -msgid "November 2018" -msgstr "" - -#: ../source/news.rst:56 -msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" -msgstr "" - -#: ../source/news.rst:57 -msgid "Changed bumpversion to bump2version. (:pr:`572`)" -msgstr "" - -#: ../source/news.rst:58 -msgid "Added single-sourcing package version example. (:pr:`573`)" -msgstr "" - -#: ../source/news.rst:59 -msgid "Added a guide for creating documentation. (:pr:`568`)" -msgstr "" - -#: ../source/news.rst:62 -msgid "October 2018" -msgstr "" - -#: ../source/news.rst:63 -msgid "Updated Nox package name. (:pr:`566`)" -msgstr "" - -#: ../source/news.rst:64 -msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" -msgstr "" - -#: ../source/news.rst:67 -msgid "September 2018" -msgstr "" - -#: ../source/news.rst:68 -msgid "Added a section on checking RST markup. (:pr:`554`)" -msgstr "" - -#: ../source/news.rst:69 -msgid "Updated user installs page. (:pr:`558`)" -msgstr "" - -#: ../source/news.rst:70 -msgid "Updated Google BigQuery urls. (:pr:`556`)" -msgstr "" - -#: ../source/news.rst:71 -msgid "Replaced tar command with working command. (:pr:`552`)" -msgstr "" - -#: ../source/news.rst:72 -msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" -msgstr "" - -#: ../source/news.rst:75 -msgid "August 2018" -msgstr "" - -#: ../source/news.rst:76 -msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" -msgstr "" - -#: ../source/news.rst:77 -msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" -msgstr "" - -#: ../source/news.rst:78 -msgid "Updated Python version supported by virtualenv. (:pr:`538`)" -msgstr "" - -#: ../source/news.rst:79 -msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" -msgstr "" - -#: ../source/news.rst:82 -msgid "July 2018" -msgstr "" - -#: ../source/news.rst:84 -msgid "Improved binary extension docs. (:pr:`531`)" -msgstr "" - -#: ../source/news.rst:85 -msgid "Added scikit-build to key projects. (:pr:`530`)" -msgstr "" - -#: ../source/news.rst:88 -msgid "June 2018" -msgstr "" - -#: ../source/news.rst:90 -msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" -msgstr "" - -#: ../source/news.rst:91 -msgid "Updated Markdown descriptions explanation. (:pr:`522`)" -msgstr "" - -#: ../source/news.rst:94 -msgid "May 2018" -msgstr "" - -#: ../source/news.rst:96 -msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" -msgstr "" - -#: ../source/news.rst:97 -msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" -msgstr "" - -#: ../source/news.rst:98 -msgid "Simplified packaging tutorial. (:pr:`498`)" -msgstr "" - -#: ../source/news.rst:99 -msgid "Updated Windows users instructions for clarity. (:pr:`493`)" -msgstr "" - -#: ../source/news.rst:100 -msgid "Updated the license section description for completeness. (:pr:`492`)" -msgstr "" - -#: ../source/news.rst:101 -msgid "Added specification-style document to contributing section. (:pr:`489`)" -msgstr "" - -#: ../source/news.rst:102 -msgid "Added documentation types to contributing guide. (:pr:`485`)" -msgstr "" - -#: ../source/news.rst:105 -msgid "April 2018" -msgstr "" - -#: ../source/news.rst:107 -msgid "Added README guide. (:pr:`461`)" -msgstr "" - -#: ../source/news.rst:108 -msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" -msgstr "" - -#: ../source/news.rst:109 -msgid "Added instructions for Warehouse. (:pr:`471`)" -msgstr "" - -#: ../source/news.rst:110 -msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" -msgstr "" - -#: ../source/news.rst:111 -msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" -msgstr "" - -#: ../source/news.rst:112 -msgid "Added a guide for phasing out Python versions. (:pr:`459`)" -msgstr "" - -#: ../source/news.rst:113 -msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" -msgstr "" - -#: ../source/news.rst:116 -msgid "March 2018" -msgstr "" - -#: ../source/news.rst:118 -msgid "Updated \"installing scientific packages\". (:pr:`455`)" -msgstr "" - -#: ../source/news.rst:119 -msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" -msgstr "" - -#: ../source/news.rst:120 -msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" -msgstr "" - -#: ../source/news.rst:121 -msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" -msgstr "" - -#: ../source/news.rst:124 -msgid "February 2018" -msgstr "" - -#: ../source/news.rst:126 -msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" -msgstr "" - -#: ../source/news.rst:127 -msgid "Updated PyPI migration info. (:pr:`439`)" -msgstr "" - -#: ../source/news.rst:128 -msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" -msgstr "" - -#: ../source/news.rst:129 -msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" -msgstr "" - -#: ../source/news.rst:130 -msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" -msgstr "" - -#: ../source/news.rst:133 -msgid "January 2018" -msgstr "" - -#: ../source/news.rst:135 -msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" -msgstr "" - -#: ../source/news.rst:136 -msgid "Updated README.rst explanation. (:pr:`419`)" -msgstr "" - -#: ../source/news.rst:139 -msgid "December 2017" -msgstr "" - -#: ../source/news.rst:141 -msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" -msgstr "" - -#: ../source/news.rst:142 -msgid "Noted which fields can be used with environment markers. (:pr:`416`)" -msgstr "" - -#: ../source/news.rst:143 -msgid "Updated Requires-Python section. (:pr:`414`)" -msgstr "" - -#: ../source/news.rst:144 -msgid "Added news page. (:pr:`404`)" -msgstr "" - -#: ../source/news.rst:147 -msgid "November 2017" -msgstr "" - -#: ../source/news.rst:149 -msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" -msgstr "" - -#: ../source/news.rst:150 -msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" -msgstr "" - -#: ../source/news.rst:152 -msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" -msgstr "" - -#: ../source/news.rst:153 -msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" -msgstr "" - -#: ../source/news.rst:156 -msgid "October 2017" -msgstr "" - -#: ../source/news.rst:158 -msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" -msgstr "" - -#: ../source/news.rst:159 -msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" -msgstr "" - -#: ../source/news.rst:160 -msgid "Split the specifications page into multiple pages. (:pr:`386`)" -msgstr "" - -#: ../source/news.rst:163 -msgid "September 2017" -msgstr "" - -#: ../source/news.rst:165 -msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" -msgstr "" - -#: ../source/news.rst:167 -msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" -msgstr "" - -#: ../source/news.rst:170 -msgid "August 2017" -msgstr "" - -#: ../source/news.rst:172 -msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" -msgstr "" - -#: ../source/news.rst:173 -msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" -msgstr "" - -#: ../source/news.rst:174 -msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" -msgstr "" - -#: ../source/news.rst:177 -msgid "July 2017" -msgstr "" - -#: ../source/news.rst:179 -msgid "Added ``flit`` to the key projects list. (:pr:`358`)" -msgstr "" - -#: ../source/news.rst:180 -msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" -msgstr "" - -#: ../source/news.rst:181 -msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" -msgstr "" - -#: ../source/news.rst:182 -msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" -msgstr "" - -#: ../source/news.rst:183 -msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" -msgstr "" - -#: ../source/news.rst:186 -msgid "June 2017" -msgstr "" - -#: ../source/news.rst:188 -msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" -msgstr "" - -#: ../source/news.rst:189 -msgid "Added documentation for ``python_requires``. (:pr:`338`)" -msgstr "" - -#: ../source/news.rst:190 -msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" -msgstr "" - -#: ../source/news.rst:191 -msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" -msgstr "" - -#: ../source/news.rst:192 -msgid "Added a license section to the distributing guide. (:pr:`331`)" -msgstr "" - -#: ../source/news.rst:193 -msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" -msgstr "" - -#: ../source/news.rst:194 -msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" -msgstr "" - -#: ../source/news.rst:195 -msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" -msgstr "" - -#: ../source/news.rst:196 -msgid "Switched to the PyPA theme. (:pr:`305`)" -msgstr "" - -#: ../source/news.rst:197 -msgid "Re-organized the documentation into the new structure. (:pr:`318`)" -msgstr "" - -#: ../source/news.rst:200 -msgid "May 2017" -msgstr "" - -#: ../source/news.rst:202 -msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" -msgstr "" - -#: ../source/news.rst:203 -msgid "Added contributor and style guide. (:pr:`307`)" -msgstr "" - -#: ../source/news.rst:204 -msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" -msgstr "" - -#: ../source/news.rst:207 -msgid "April 2017" -msgstr "" - -#: ../source/news.rst:209 -msgid "Added travis configuration for testing pull requests. (:pr:`300`)" -msgstr "" - -#: ../source/news.rst:210 -msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" -msgstr "" - -#: ../source/news.rst:211 -msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" -msgstr "" - -#: ../source/news.rst:212 -msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" -msgstr "" - -#: ../source/news.rst:213 -msgid "Added a topic on namespace packages. (:pr:`290`)" -msgstr "" - -#: ../source/news.rst:214 -msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" -msgstr "" - -#: ../source/news.rst:215 -msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" -msgstr "" - -#: ../source/news.rst:216 -msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" -msgstr "" - -#: ../source/news.rst:217 -msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" -msgstr "" - -#: ../source/news.rst:219 -msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" -msgstr "" - -#: ../source/news.rst:223 -msgid "March 2017" -msgstr "" - -#: ../source/news.rst:225 -msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" -msgstr "" - -#: ../source/news.rst:228 -msgid "February 2017" -msgstr "" - -#: ../source/news.rst:230 -msgid "Added :pep:`518`. (:pr:`281`)" -msgstr "" - -#: ../source/overview.rst:3 -msgid "An Overview of Packaging for Python" -msgstr "" - -#: ../source/overview.rst:7 -msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." -msgstr "" - -#: ../source/overview.rst:12 -msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." -msgstr "" - -#: ../source/overview.rst:18 -msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." -msgstr "" - -#: ../source/overview.rst:26 -msgid "Thinking about deployment" -msgstr "" - -#: ../source/overview.rst:28 -msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" -msgstr "" - -#: ../source/overview.rst:32 -msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" -msgstr "" - -#: ../source/overview.rst:35 -msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" -msgstr "" - -#: ../source/overview.rst:37 -msgid "Is your software installed individually, or in large deployment batches?" -msgstr "" - -#: ../source/overview.rst:39 -msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." -msgstr "" - -#: ../source/overview.rst:46 -msgid "Packaging Python libraries and tools" -msgstr "" - -#: ../source/overview.rst:48 -msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." -msgstr "" - -#: ../source/overview.rst:53 -msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." -msgstr "" - -#: ../source/overview.rst:59 -msgid "Python modules" -msgstr "" - -#: ../source/overview.rst:61 -msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." -msgstr "" - -#: ../source/overview.rst:66 -msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." -msgstr "" - -#: ../source/overview.rst:73 -msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." -msgstr "" - -#: ../source/overview.rst:78 -msgid "Python source distributions" -msgstr "" - -#: ../source/overview.rst:80 -msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." -msgstr "" - -#: ../source/overview.rst:84 -msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." -msgstr "" - -#: ../source/overview.rst:90 -msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." -msgstr "" - -#: ../source/overview.rst:95 -msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." -msgstr "" - -#: ../source/overview.rst:100 -msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." -msgstr "" - -#: ../source/overview.rst:107 -msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" -msgstr "" - -#: ../source/overview.rst:114 -msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." -msgstr "" - -#: ../source/overview.rst:119 -msgid "Python binary distributions" -msgstr "" - -#: ../source/overview.rst:121 -msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." -msgstr "" - -#: ../source/overview.rst:125 -msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." -msgstr "" - -#: ../source/overview.rst:132 -msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." -msgstr "" - -#: ../source/overview.rst:140 -msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." -msgstr "" - -#: ../source/overview.rst:148 -msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." -msgstr "" - -#: ../source/overview.rst:155 -msgid "Packaging Python applications" -msgstr "" - -#: ../source/overview.rst:157 -msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." -msgstr "" - -#: ../source/overview.rst:162 -msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." -msgstr "" - -#: ../source/overview.rst:166 -msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." -msgstr "" - -#: ../source/overview.rst:172 -msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." -msgstr "" - -#: ../source/overview.rst:176 -msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." -msgstr "" - -#: ../source/overview.rst:181 -msgid "Depending on a framework" -msgstr "" - -#: ../source/overview.rst:183 -msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." -msgstr "" - -#: ../source/overview.rst:189 -msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." -msgstr "" - -#: ../source/overview.rst:195 -msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." -msgstr "" - -#: ../source/overview.rst:199 -msgid "Service platforms" -msgstr "" - -#: ../source/overview.rst:201 -msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." -msgstr "" - -#: ../source/overview.rst:205 -msgid "`Heroku `_" -msgstr "" - -#: ../source/overview.rst:206 -msgid "`Google App Engine `_" -msgstr "" - -#: ../source/overview.rst:207 -msgid "`PythonAnywhere `_" -msgstr "" - -#: ../source/overview.rst:208 -msgid "`OpenShift `_" -msgstr "" - -#: ../source/overview.rst:209 -msgid "\"Serverless\" frameworks like `Zappa `_" -msgstr "" - -#: ../source/overview.rst:211 -msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." -msgstr "" - -#: ../source/overview.rst:216 -msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." -msgstr "" - -#: ../source/overview.rst:220 -msgid "Web browsers and mobile applications" -msgstr "" - -#: ../source/overview.rst:222 -msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." -msgstr "" - -#: ../source/overview.rst:227 -msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" -msgstr "" - -#: ../source/overview.rst:231 -msgid "`Kivy `_" -msgstr "" - -#: ../source/overview.rst:232 -msgid "`Beeware `_" -msgstr "" - -#: ../source/overview.rst:233 -msgid "`Brython `_" -msgstr "" - -#: ../source/overview.rst:234 -msgid "`Flexx `_" -msgstr "" - -#: ../source/overview.rst:236 -msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." -msgstr "" - -#: ../source/overview.rst:241 -msgid "Depending on a pre-installed Python" -msgstr "" - -#: ../source/overview.rst:243 -msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." -msgstr "" - -#: ../source/overview.rst:249 -msgid "Technologies which support this model:" -msgstr "" - -#: ../source/overview.rst:251 -msgid "`PEX `_ (Python EXecutable)" -msgstr "" - -#: ../source/overview.rst:252 -msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" -msgstr "" - -#: ../source/overview.rst:253 -msgid "`shiv `_ (requires Python 3)" -msgstr "" - -#: ../source/overview.rst:255 -msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." -msgstr "" - -#: ../source/overview.rst:260 -msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." -msgstr "" - -#: ../source/overview.rst:267 -msgid "Depending on a separate software distribution ecosystem" -msgstr "" - -#: ../source/overview.rst:269 -msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." -msgstr "" - -#: ../source/overview.rst:274 -msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." -msgstr "" - -#: ../source/overview.rst:284 -msgid "Instructions on building and publishing for the Anaconda ecosystem:" -msgstr "" - -#: ../source/overview.rst:286 -msgid "`Building libraries and applications with conda `_" -msgstr "" - -#: ../source/overview.rst:287 -msgid "`Transitioning a native Python package to Anaconda `_" -msgstr "" - -#: ../source/overview.rst:289 -msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" -msgstr "" - -#: ../source/overview.rst:293 -msgid "`Enthought Canopy `_" -msgstr "" - -#: ../source/overview.rst:294 -msgid "`ActiveState ActivePython `_" -msgstr "" - -#: ../source/overview.rst:295 -msgid "`WinPython `_" -msgstr "" - -#: ../source/overview.rst:300 -msgid "Bringing your own Python executable" -msgstr "" - -#: ../source/overview.rst:302 -msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." -msgstr "" - -#: ../source/overview.rst:306 -msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." -msgstr "" - -#: ../source/overview.rst:311 -msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." -msgstr "" - -#: ../source/overview.rst:315 -msgid "A selection of Python freezers:" -msgstr "" - -#: ../source/overview.rst:317 -msgid "`pyInstaller `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:318 -msgid "`cx_Freeze `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:319 -msgid "`constructor `_ - For command-line installers" -msgstr "" - -#: ../source/overview.rst:320 -msgid "`py2exe `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:321 -msgid "`py2app `_ - Mac only" -msgstr "" - -#: ../source/overview.rst:322 -msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" -msgstr "" - -#: ../source/overview.rst:323 -msgid "`osnap `_ - Windows and Mac" -msgstr "" - -#: ../source/overview.rst:324 -msgid "`pynsist `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:326 -msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." -msgstr "" - -#: ../source/overview.rst:332 -msgid "Bringing your own userspace" -msgstr "" - -#: ../source/overview.rst:334 -msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." -msgstr "" - -#: ../source/overview.rst:341 -msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." -msgstr "" - -#: ../source/overview.rst:344 -msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" -msgstr "" - -#: ../source/overview.rst:347 -msgid "`AppImage `_" -msgstr "" - -#: ../source/overview.rst:348 -msgid "`Docker `_" -msgstr "" - -#: ../source/overview.rst:349 -msgid "`Flatpak `_" -msgstr "" - -#: ../source/overview.rst:350 -msgid "`Snapcraft `_" -msgstr "" - -#: ../source/overview.rst:353 -msgid "Bringing your own kernel" -msgstr "" - -#: ../source/overview.rst:355 -msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." -msgstr "" - -#: ../source/overview.rst:360 -msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" -msgstr "" - -#: ../source/overview.rst:364 -msgid "`Vagrant `_" -msgstr "" - -#: ../source/overview.rst:365 -msgid "`VHD `_, `AMI `_, and `other formats `_" -msgstr "" - -#: ../source/overview.rst:366 -msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" -msgstr "" - -#: ../source/overview.rst:369 -msgid "Bringing your own hardware" -msgstr "" - -#: ../source/overview.rst:371 -msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." -msgstr "" - -#: ../source/overview.rst:375 -msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." -msgstr "" - -#: ../source/overview.rst:379 -msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." -msgstr "" - -#: ../source/overview.rst:389 -msgid "The simplified gamut of technologies used to package Python applications." -msgstr "" - -#: ../source/overview.rst:392 -msgid "What about..." -msgstr "" - -#: ../source/overview.rst:394 -msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." -msgstr "" - -#: ../source/overview.rst:398 -msgid "Operating system packages" -msgstr "" - -#: ../source/overview.rst:400 -msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." -msgstr "" - -#: ../source/overview.rst:411 -msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." -msgstr "" - -#: ../source/overview.rst:417 -msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." -msgstr "" - -#: ../source/overview.rst:427 -msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." -msgstr "" - -#: ../source/overview.rst:432 -msgid "Security" -msgstr "" - -#: ../source/overview.rst:434 -msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." -msgstr "" - -#: ../source/overview.rst:437 -msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." -msgstr "" - -#: ../source/overview.rst:446 -msgid "Wrap up" -msgstr "" - -#: ../source/overview.rst:448 -msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:6 -msgid "Binary distribution format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:8 -msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:13 -msgid "Abstract" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:15 -msgid "This PEP describes a built-package format for Python called \"wheel\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:17 -msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:27 -msgid "PEP Acceptance" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:29 -msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:34 -msgid "Rationale" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:36 -msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:43 -msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:52 -msgid "Details" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:55 -msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:57 -msgid "Wheel installation notionally consists of two phases:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:59 -msgid "Unpack." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:61 -msgid "Parse ``distribution-1.0.dist-info/WHEEL``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:62 -msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:64 -msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:66 -msgid "Else unpack archive into platlib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:68 -msgid "Spread." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:70 -msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:72 -msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:78 -msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:80 -msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:82 -msgid "Remove empty ``distribution-1.0.data`` directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:83 -msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:87 -msgid "Recommended installer features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:97 -msgid "Rewrite ``#!python``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:90 -msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:96 -msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:102 -msgid "Generate script wrappers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:100 -msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:105 -msgid "Recommended archiver features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:112 -msgid "Place ``.dist-info`` at the end of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:108 -msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:115 -msgid "File Format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:118 -msgid "File name convention" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:120 -msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "distribution" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "Distribution name, e.g. 'django', 'pyramid'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "Distribution version, e.g. 1.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:135 -msgid "build tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:130 -msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "language implementation and version tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "E.g. 'py27', 'py2', 'py3'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "abi tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "E.g. 'cp33m', 'abi3', 'none'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "platform tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "E.g. 'linux_x86_64', 'any'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:146 -msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:151 -msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:156 -msgid "Escaping and Unicode" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:158 -msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:161 -msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:164 -msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:166 -msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:169 -msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:172 -msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:176 -msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:182 -msgid "File contents" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:184 -msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:188 -msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:191 -msgid "``{distribution}-{version}.dist-info/`` contains metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:192 -msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:196 -msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:200 -msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:202 -msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:212 -msgid "``Wheel-Version`` is the version number of the Wheel specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:213 -msgid "``Generator`` is the name and optionally the version of the software that produced the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:215 -msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:218 -msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:220 -msgid "``Build`` is the build number and is omitted if there is no build number." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:221 -msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:224 -msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:226 -msgid "Wheel does not contain setup.py or setup.cfg." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:228 -msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:235 -#: ../source/specifications/recording-installed-packages.rst:35 -msgid "The .dist-info directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:237 -msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:239 -msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:241 -msgid "WHEEL is the wheel metadata specific to a build of the package." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:242 -msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:248 -msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:249 -msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:251 -msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:254 -msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:261 -msgid "The .data directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:263 -msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:271 -msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:277 -msgid "Signed wheel files" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:279 -msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:290 -msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:295 -msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:302 -msgid "(The hash value is the same format used in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:304 -msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:307 -msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:312 -msgid "See" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:314 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:315 -msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:316 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:317 -msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:321 -msgid "Comparison to .egg" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:323 -msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:328 -msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:331 -msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:337 -msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:341 -msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:344 -msgid "Wheel is a reference to the other Python." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:348 -msgid "FAQ" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:352 -msgid "Wheel defines a .data directory. Should I put all my data there?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:354 -msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:363 -msgid "Why does wheel include attached signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:365 -msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:373 -msgid "Why does wheel allow JWS signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:375 -msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:381 -msgid "Why does wheel also allow S/MIME signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:383 -msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:386 -msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:391 -msgid "What's the deal with \"purelib\" vs. \"platlib\"?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:393 -msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:398 -msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:403 -msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:409 -msgid "Is it possible to import Python code directly from a wheel file?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:411 -msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:417 -msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:426 -msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:443 -msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:450 -msgid "Changes" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:452 -msgid "Since :pep:`427`, this specification has changed as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:454 -msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:461 -msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:466 -msgid "Appendix" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:468 -msgid "Example urlsafe-base64-nopad implementation::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:482 -msgid "Copyright" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:484 -msgid "This document has been placed into the public domain." -msgstr "" - -#: ../source/specifications/core-metadata.rst:5 -msgid "Core metadata specifications" -msgstr "" - -#: ../source/specifications/core-metadata.rst:7 -msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:10 -msgid "``Metadata-Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:11 -msgid "``Name``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:12 -msgid "``Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:14 -msgid "All the other fields are optional." -msgstr "" - -#: ../source/specifications/core-metadata.rst:16 -msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." -msgstr "" - -#: ../source/specifications/core-metadata.rst:25 -msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:30 -msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." -msgstr "" - -#: ../source/specifications/core-metadata.rst:41 -msgid "Metadata-Version" -msgstr "" - -#: ../source/specifications/core-metadata.rst:45 -msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." -msgstr "" - -#: ../source/specifications/core-metadata.rst:48 -msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:54 -msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." -msgstr "" - -#: ../source/specifications/core-metadata.rst:58 -#: ../source/specifications/core-metadata.rst:80 -#: ../source/specifications/core-metadata.rst:95 -#: ../source/specifications/core-metadata.rst:155 -#: ../source/specifications/core-metadata.rst:170 -#: ../source/specifications/core-metadata.rst:208 -#: ../source/specifications/core-metadata.rst:283 -#: ../source/specifications/core-metadata.rst:287 -#: ../source/specifications/core-metadata.rst:291 -#: ../source/specifications/core-metadata.rst:295 -#: ../source/specifications/core-metadata.rst:327 -#: ../source/specifications/core-metadata.rst:347 -#: ../source/specifications/core-metadata.rst:373 -#: ../source/specifications/core-metadata.rst:391 -#: ../source/specifications/core-metadata.rst:416 -#: ../source/specifications/core-metadata.rst:438 -#: ../source/specifications/core-metadata.rst:600 -#: ../source/specifications/core-metadata.rst:620 -#: ../source/specifications/core-metadata.rst:630 -msgid "Example::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:66 -msgid "Name" -msgstr "" - -#: ../source/specifications/core-metadata.rst:69 -msgid "Added additional restrictions on format from :pep:`508`" -msgstr "" - -#: ../source/specifications/core-metadata.rst:72 -msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:88 -msgid "Version" -msgstr "" - -#: ../source/specifications/core-metadata.rst:92 -msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:101 -msgid "Dynamic (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:105 -msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." -msgstr "" - -#: ../source/specifications/core-metadata.rst:108 -msgid "When found in the metadata of a source distribution, the following rules apply:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:111 -msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." -msgstr "" - -#: ../source/specifications/core-metadata.rst:115 -msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:118 -msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:122 -msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." -msgstr "" - -#: ../source/specifications/core-metadata.rst:127 -msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:131 -msgid "Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:135 -msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." -msgstr "" - -#: ../source/specifications/core-metadata.rst:146 -msgid "Supported-Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:150 -msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." -msgstr "" - -#: ../source/specifications/core-metadata.rst:164 -msgid "Summary" -msgstr "" - -#: ../source/specifications/core-metadata.rst:168 -msgid "A one-line summary of what the distribution does." -msgstr "" - -#: ../source/specifications/core-metadata.rst:188 -msgid "This field may be specified in the message body instead." -msgstr "" - -#: ../source/specifications/core-metadata.rst:191 -msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:196 -msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." -msgstr "" - -#: ../source/specifications/core-metadata.rst:202 -msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:219 -msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." -msgstr "" - -#: ../source/specifications/core-metadata.rst:223 -msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:232 -msgid "Description-Content-Type" -msgstr "" - -#: ../source/specifications/core-metadata.rst:236 -msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:239 -msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." -msgstr "" - -#: ../source/specifications/core-metadata.rst:253 -msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:259 -msgid "Format::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:263 -msgid "The ``type/subtype`` part has only a few legal values:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:265 -msgid "``text/plain``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:266 -msgid "``text/x-rst``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:267 -msgid "``text/markdown``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:269 -msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:273 -msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:278 -msgid "``GFM`` for `Github-flavored Markdown `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:280 -msgid "``CommonMark`` for `CommonMark `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:299 -msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." -msgstr "" - -#: ../source/specifications/core-metadata.rst:303 -msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:307 -msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:311 -msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." -msgstr "" - -#: ../source/specifications/core-metadata.rst:320 -msgid "Keywords" -msgstr "" - -#: ../source/specifications/core-metadata.rst:324 -msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." -msgstr "" - -#: ../source/specifications/core-metadata.rst:333 -msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." -msgstr "" - -#: ../source/specifications/core-metadata.rst:341 -msgid "Home-page" -msgstr "" - -#: ../source/specifications/core-metadata.rst:345 -msgid "A string containing the URL for the distribution's home page." -msgstr "" - -#: ../source/specifications/core-metadata.rst:353 -msgid "Download-URL" -msgstr "" - -#: ../source/specifications/core-metadata.rst:357 -msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:366 -msgid "Author" -msgstr "" - -#: ../source/specifications/core-metadata.rst:370 -msgid "A string containing the author's name at a minimum; additional contact information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:383 -msgid "Author-email" -msgstr "" - -#: ../source/specifications/core-metadata.rst:387 -msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:395 -#: ../source/specifications/core-metadata.rst:442 -msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:405 -msgid "Maintainer" -msgstr "" - -#: ../source/specifications/core-metadata.rst:409 -msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:412 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:426 -msgid "Maintainer-email" -msgstr "" - -#: ../source/specifications/core-metadata.rst:430 -msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:434 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:452 -msgid "License" -msgstr "" - -#: ../source/specifications/core-metadata.rst:456 -msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." -msgstr "" - -#: ../source/specifications/core-metadata.rst:476 -msgid "Classifier (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:480 -msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:485 -#: ../source/specifications/core-metadata.rst:574 -#: ../source/specifications/core-metadata.rst:691 -#: ../source/specifications/core-metadata.rst:715 -msgid "This field may be followed by an environment marker after a semicolon." -msgstr "" - -#: ../source/specifications/core-metadata.rst:496 -msgid "Requires-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:499 -#: ../source/specifications/core-metadata.rst:561 -#: ../source/specifications/core-metadata.rst:663 -#: ../source/specifications/core-metadata.rst:704 -msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." -msgstr "" - -#: ../source/specifications/core-metadata.rst:503 -msgid "Each entry contains a string naming some other distutils project required by this distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:506 -msgid "The format of a requirement string contains from one to four parts:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:508 -msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." -msgstr "" - -#: ../source/specifications/core-metadata.rst:510 -msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." -msgstr "" - -#: ../source/specifications/core-metadata.rst:513 -msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:516 -msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." -msgstr "" - -#: ../source/specifications/core-metadata.rst:519 -msgid "See :pep:`508` for full details of the allowed format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:521 -msgid "The project names should correspond to names as found on the `Python Package Index`_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:524 -msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:538 -msgid "Requires-Python" -msgstr "" - -#: ../source/specifications/core-metadata.rst:542 -msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." -msgstr "" - -#: ../source/specifications/core-metadata.rst:546 -msgid "The value must be in the format specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:548 -msgid "This field cannot be followed by an environment marker." -msgstr "" - -#: ../source/specifications/core-metadata.rst:558 -msgid "Requires-External (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:565 -msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:570 -msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:576 -msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." -msgstr "" - -#: ../source/specifications/core-metadata.rst:581 -msgid "Notice that there is no particular rule on the strings to be used." -msgstr "" - -#: ../source/specifications/core-metadata.rst:593 -msgid "Project-URL (multiple-use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:597 -msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." -msgstr "" - -#: ../source/specifications/core-metadata.rst:604 -msgid "The label is free text limited to 32 characters." -msgstr "" - -#: ../source/specifications/core-metadata.rst:612 -msgid "Provides-Extra (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:616 -msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." -msgstr "" - -#: ../source/specifications/core-metadata.rst:625 -msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:635 -msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." -msgstr "" - -#: ../source/specifications/core-metadata.rst:639 -msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:644 -msgid "Rarely Used Fields" -msgstr "" - -#: ../source/specifications/core-metadata.rst:646 -msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:651 -msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." -msgstr "" - -#: ../source/specifications/core-metadata.rst:660 -msgid "Provides-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:667 -msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:672 -msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:679 -msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:687 -msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." -msgstr "" - -#: ../source/specifications/core-metadata.rst:701 -msgid "Obsoletes-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:708 -msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." -msgstr "" - -#: ../source/specifications/core-metadata.rst:712 -msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:717 -msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:730 -msgid "reStructuredText markup: http://docutils.sourceforge.net/" -msgstr "" - -#: ../source/specifications/core-metadata.rst:735 -msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:6 -msgid "Declaring build system dependencies" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:8 -msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:5 -msgid "Declaring project metadata" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:7 -msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:12 -msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:18 -msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:27 -msgid "The only fields required to be statically defined are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:29 -#: ../source/specifications/declaring-project-metadata.rst:41 -msgid "``name``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:31 -msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:34 -#: ../source/specifications/declaring-project-metadata.rst:54 -msgid "``version``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:36 -msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:43 -#: ../source/specifications/declaring-project-metadata.rst:56 -#: ../source/specifications/declaring-project-metadata.rst:68 -#: ../source/specifications/declaring-project-metadata.rst:117 -msgid "TOML_ type: string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:44 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:47 -msgid "The name of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:49 -msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:57 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:60 -msgid "The version of the project as supported by :pep:`440`." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:62 -msgid "Users SHOULD prefer to specify already-normalized versions." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:66 -msgid "``description``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:69 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:72 -msgid "The summary description of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:76 -msgid "``readme``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:78 -msgid "TOML_ type: string or table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:79 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:83 -msgid "The full description of the project (i.e. the README)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:85 -msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:96 -msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:103 -msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:115 -msgid "``requires-python``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:118 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:121 -msgid "The Python version requirements of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:125 -msgid "``license``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:127 -msgid "TOML_ type: table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:128 -msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:131 -msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:140 -msgid "``authors``/``maintainers``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:142 -msgid "TOML_ type: Array of inline tables with string keys and values" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:143 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:149 -msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:154 -msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:157 -msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:163 -msgid "Using the data to fill in :ref:`core metadata ` is as follows:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:166 -msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:169 -msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:173 -msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:177 -msgid "Multiple values should be separated by commas." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:181 -msgid "``keywords``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:183 -#: ../source/specifications/declaring-project-metadata.rst:193 -msgid "TOML_ type: array of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:184 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:187 -msgid "The keywords for the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:191 -msgid "``classifiers``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:194 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:197 -msgid "Trove classifiers which apply to the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:201 -msgid "``urls``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:203 -msgid "TOML_ type: table with keys and values of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:204 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:207 -msgid "A table of URLs where the key is the URL label and the value is the URL itself." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:212 -msgid "Entry points" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:214 -msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:216 -msgid ":ref:`Entry points specification `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:218 -msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:224 -msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:228 -msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:234 -msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:242 -msgid "``dependencies``/``optional-dependencies``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:244 -msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:247 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:251 -msgid "The (optional) dependencies of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:253 -msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:258 -msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:269 -msgid "``dynamic``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:271 -msgid "TOML_ type: array of string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:272 -msgid "A corresponding :ref:`core metadata ` field does not exist" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:275 -msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:281 -msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:283 -msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:285 -msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:290 -msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:294 -msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:296 -msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:300 -msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:6 -msgid "Dependency specifiers" -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:8 -msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:11 -msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." -msgstr "" - -#: ../source/specifications/direct-url.rst:6 -msgid "Recording the Direct URL Origin of installed distributions" -msgstr "" - -#: ../source/specifications/direct-url.rst:8 -msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." -msgstr "" - -#: ../source/specifications/direct-url.rst:17 -msgid "Specification" -msgstr "" - -#: ../source/specifications/direct-url.rst:19 -msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/direct-url.rst:23 -#: ../source/specifications/recording-installed-packages.rst:206 -msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." -msgstr "" - -#: ../source/specifications/direct-url.rst:26 -msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." -msgstr "" - -#: ../source/specifications/direct-url.rst:29 -msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." -msgstr "" - -#: ../source/specifications/direct-url.rst:36 -msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." -msgstr "" - -#: ../source/specifications/direct-url.rst:39 -msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" -msgstr "" - -#: ../source/specifications/direct-url.rst:45 -msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." -msgstr "" - -#: ../source/specifications/direct-url.rst:49 -msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" -msgstr "" - -#: ../source/specifications/direct-url.rst:52 -msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." -msgstr "" - -#: ../source/specifications/direct-url.rst:58 -msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." -msgstr "" - -#: ../source/specifications/direct-url.rst:61 -msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." -msgstr "" - -#: ../source/specifications/direct-url.rst:68 -msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:71 -msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." -msgstr "" - -#: ../source/specifications/direct-url.rst:78 -msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:81 -msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." -msgstr "" - -#: ../source/specifications/direct-url.rst:84 -msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." -msgstr "" - -#: ../source/specifications/direct-url.rst:91 -msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." -msgstr "" - -#: ../source/specifications/direct-url.rst:96 -msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." -msgstr "" - -#: ../source/specifications/direct-url.rst:102 -msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." -msgstr "" - -#: ../source/specifications/direct-url.rst:110 -msgid "Registered VCS" -msgstr "" - -#: ../source/specifications/direct-url.rst:112 -msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." -msgstr "" - -#: ../source/specifications/direct-url.rst:122 -msgid "Git" -msgstr "" - -#: ../source/specifications/direct-url.rst:124 -#: ../source/specifications/direct-url.rst:156 -#: ../source/specifications/direct-url.rst:179 -#: ../source/specifications/direct-url.rst:202 -msgid "Home page" -msgstr "" - -#: ../source/specifications/direct-url.rst:126 -msgid "https://git-scm.com/" -msgstr "" - -#: ../source/specifications/direct-url.rst:128 -#: ../source/specifications/direct-url.rst:160 -#: ../source/specifications/direct-url.rst:183 -#: ../source/specifications/direct-url.rst:206 -msgid "vcs command" -msgstr "" - -#: ../source/specifications/direct-url.rst:130 -#: ../source/specifications/direct-url.rst:134 -msgid "git" -msgstr "" - -#: ../source/specifications/direct-url.rst:132 -#: ../source/specifications/direct-url.rst:164 -#: ../source/specifications/direct-url.rst:187 -#: ../source/specifications/direct-url.rst:210 -msgid "``vcs`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:136 -#: ../source/specifications/direct-url.rst:168 -#: ../source/specifications/direct-url.rst:191 -#: ../source/specifications/direct-url.rst:214 -msgid "``requested_revision`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:138 -msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." -msgstr "" - -#: ../source/specifications/direct-url.rst:141 -#: ../source/specifications/direct-url.rst:172 -#: ../source/specifications/direct-url.rst:195 -#: ../source/specifications/direct-url.rst:219 -msgid "``commit_id`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:143 -msgid "A commit hash (40 hexadecimal characters sha1)." -msgstr "" - -#: ../source/specifications/direct-url.rst:147 -msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." -msgstr "" - -#: ../source/specifications/direct-url.rst:154 -msgid "Mercurial" -msgstr "" - -#: ../source/specifications/direct-url.rst:158 -msgid "https://www.mercurial-scm.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:162 -#: ../source/specifications/direct-url.rst:166 -msgid "hg" -msgstr "" - -#: ../source/specifications/direct-url.rst:170 -msgid "A tag name, branch name, changeset ID, shortened changeset ID." -msgstr "" - -#: ../source/specifications/direct-url.rst:174 -msgid "A changeset ID (40 hexadecimal characters)." -msgstr "" - -#: ../source/specifications/direct-url.rst:177 -msgid "Bazaar" -msgstr "" - -#: ../source/specifications/direct-url.rst:181 -msgid "https://bazaar.canonical.com/" -msgstr "" - -#: ../source/specifications/direct-url.rst:185 -#: ../source/specifications/direct-url.rst:189 -msgid "bzr" -msgstr "" - -#: ../source/specifications/direct-url.rst:193 -msgid "A tag name, branch name, revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:197 -msgid "A revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:200 -msgid "Subversion" -msgstr "" - -#: ../source/specifications/direct-url.rst:204 -msgid "https://subversion.apache.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:208 -#: ../source/specifications/direct-url.rst:212 -msgid "svn" -msgstr "" - -#: ../source/specifications/direct-url.rst:216 -msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." -msgstr "" - -#: ../source/specifications/direct-url.rst:221 -msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." -msgstr "" - -#: ../source/specifications/direct-url.rst:229 -msgid "Example direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:231 -msgid "Source archive:" -msgstr "" - -#: ../source/specifications/direct-url.rst:242 -msgid "Git URL with tag and commit-hash:" -msgstr "" - -#: ../source/specifications/direct-url.rst:255 -msgid "Local directory:" -msgstr "" - -#: ../source/specifications/direct-url.rst:264 -msgid "Local directory installed in editable mode:" -msgstr "" - -#: ../source/specifications/direct-url.rst:277 -msgid "Example pip commands and their effect on direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:279 -msgid "Commands that generate a ``direct_url.json``:" -msgstr "" - -#: ../source/specifications/direct-url.rst:281 -msgid "pip install https://example.com/app-1.0.tgz" -msgstr "" - -#: ../source/specifications/direct-url.rst:282 -msgid "pip install https://example.com/app-1.0.whl" -msgstr "" - -#: ../source/specifications/direct-url.rst:283 -msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" -msgstr "" - -#: ../source/specifications/direct-url.rst:284 -msgid "pip install ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:285 -msgid "pip install file:///home/user/app" -msgstr "" - -#: ../source/specifications/direct-url.rst:286 -msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" -msgstr "" - -#: ../source/specifications/direct-url.rst:290 -msgid "pip install -e ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:292 -msgid "Commands that *do not* generate a ``direct_url.json``" -msgstr "" - -#: ../source/specifications/direct-url.rst:294 -msgid "pip install app" -msgstr "" - -#: ../source/specifications/direct-url.rst:295 -msgid "pip install app --no-index --find-links https://example.com/" -msgstr "" - -#: ../source/specifications/entry-points.rst:5 -msgid "Entry points specification" -msgstr "" - -#: ../source/specifications/entry-points.rst:7 -msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" -msgstr "" - -#: ../source/specifications/entry-points.rst:11 -msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." -msgstr "" - -#: ../source/specifications/entry-points.rst:14 -msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." -msgstr "" - -#: ../source/specifications/entry-points.rst:19 -msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." -msgstr "" - -#: ../source/specifications/entry-points.rst:28 -msgid "Data model" -msgstr "" - -#: ../source/specifications/entry-points.rst:30 -msgid "Conceptually, an entry point is defined by three required properties:" -msgstr "" - -#: ../source/specifications/entry-points.rst:32 -msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:42 -msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:51 -msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:64 -msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." -msgstr "" - -#: ../source/specifications/entry-points.rst:68 -msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." -msgstr "" - -#: ../source/specifications/entry-points.rst:73 -msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." -msgstr "" - -#: ../source/specifications/entry-points.rst:80 -msgid "File format" -msgstr "" - -#: ../source/specifications/entry-points.rst:82 -msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." -msgstr "" - -#: ../source/specifications/entry-points.rst:87 -msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:97 -msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:100 -msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." -msgstr "" - -#: ../source/specifications/entry-points.rst:104 -msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." -msgstr "" - -#: ../source/specifications/entry-points.rst:112 -msgid "For example::" -msgstr "" - -#: ../source/specifications/entry-points.rst:124 -msgid "Use for scripts" -msgstr "" - -#: ../source/specifications/entry-points.rst:126 -msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." -msgstr "" - -#: ../source/specifications/entry-points.rst:134 -msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:141 -msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." -msgstr "" - -#: ../source/specifications/entry-points.rst:149 -msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." -msgstr "" - -#: ../source/specifications/entry-points.rst:154 -msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." -msgstr "" - -#: ../source/specifications/index.rst:4 -msgid "PyPA specifications" -msgstr "" - -#: ../source/specifications/index.rst:6 -msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." -msgstr "" - -#: ../source/specifications/index.rst:13 -msgid "Package Distribution Metadata" -msgstr "" - -#: ../source/specifications/index.rst:30 -msgid "Package Distribution File Formats" -msgstr "" - -#: ../source/specifications/index.rst:40 -msgid "Package Index Interfaces" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:6 -msgid "Platform compatibility tags" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:8 -msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:12 -msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:16 -msgid "Platform tags for Windows" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:18 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:22 -msgid "Platform tags for macOS (Mac OS X)" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:24 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:28 -msgid "Platform tags for common Linux distributions" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:32 -msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:36 -msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:41 -msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:44 -msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:46 -msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:49 -msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:54 -msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:59 -msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:65 -msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:71 -msgid "Manylinux compatibility support" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:74 -msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:76 -msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:79 -msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "Tool" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux1``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2010``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2014``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux_x_y``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=8.1.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=20.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "auditwheel" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=1.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=2.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.3.0`` [#]_" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:90 -msgid "Platform tags for other \\*nix platforms" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:92 -msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:98 -msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" -msgstr "" - -#: ../source/specifications/pypirc.rst:6 -msgid "The :file:`.pypirc` file" -msgstr "" - -#: ../source/specifications/pypirc.rst:8 -msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." -msgstr "" - -#: ../source/specifications/pypirc.rst:13 -msgid "The format (originally defined by the :ref:`distutils` package) is:" -msgstr "" - -#: ../source/specifications/pypirc.rst:32 -msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:35 -msgid "Each section describing a repository defines three fields:" -msgstr "" - -#: ../source/specifications/pypirc.rst:37 -msgid "``repository``: The URL of the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:38 -msgid "``username``: The registered username on the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:39 -msgid "``password``: The password that will used to authenticate the username." -msgstr "" - -#: ../source/specifications/pypirc.rst:43 -msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." -msgstr "" - -#: ../source/specifications/pypirc.rst:47 -msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" -msgstr "" - -#: ../source/specifications/pypirc.rst:57 -msgid "Common configurations" -msgstr "" - -#: ../source/specifications/pypirc.rst:61 -msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." -msgstr "" - -#: ../source/specifications/pypirc.rst:66 -msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" -msgstr "" - -#: ../source/specifications/pypirc.rst:82 -msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." -msgstr "" - -#: ../source/specifications/pypirc.rst:86 -msgid "Using a PyPI token" -msgstr "" - -#: ../source/specifications/pypirc.rst:88 -msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" -msgstr "" - -#: ../source/specifications/pypirc.rst:97 -msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." -msgstr "" - -#: ../source/specifications/pypirc.rst:103 -msgid "Using another package index" -msgstr "" - -#: ../source/specifications/pypirc.rst:105 -msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" -msgstr "" - -#: ../source/specifications/pypirc.rst:132 -msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:5 -msgid "Recording installed projects" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:7 -msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:12 -msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:21 -msgid "History and change workflow" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:23 -msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:29 -msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:37 -msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:41 -msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:50 -msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:60 -msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:69 -msgid "This ``.dist-info`` directory can contain these files, described in detail below:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:72 -msgid "``METADATA``: contains project metadata" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:73 -msgid "``RECORD``: records the list of installed files." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:74 -msgid "``INSTALLER``: records the name of the tool used to install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:76 -msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:82 -msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:87 -msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:94 -msgid "The METADATA file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:96 -msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:99 -msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:105 -msgid "The RECORD file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:107 -msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:110 -msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:113 -msgid "field delimiter: ``,`` (comma)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:114 -msgid "quoting char: ``\"`` (straight double quote)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:115 -msgid "line terminator: either ``\\r\\n`` or ``\\n``." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:117 -msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:120 -msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:125 -msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:130 -msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:133 -msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:139 -msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:146 -msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:151 -msgid "Here is an example snippet of a possible ``RECORD`` file::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:170 -msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:177 -msgid "The INSTALLER file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:179 -msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:185 -msgid "The file can be terminated by zero or more ASCII whitespace characters." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:187 -msgid "Here are examples of two possible ``INSTALLER`` files::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:195 -msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:201 -msgid "The direct_url.json file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:203 -msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:209 -msgid "Its detailed specification is at :ref:`direct-url`." -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:6 -msgid "Simple repository API" -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:8 -msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:6 -msgid "Source distribution format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:8 -msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:13 -msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:21 -msgid "Source distributions are also known as *sdists* for short." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:24 -msgid "Source distribution file name" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:26 -msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:31 -msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:35 -msgid "Source distribution file format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:37 -msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:45 -msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:48 -msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:6 -msgid "Version specifiers" -msgstr "" - -#: ../source/specifications/version-specifiers.rst:8 -msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:11 -msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." -msgstr "" - -#: ../source/support.rst:3 -msgid "How to Get Support" -msgstr "" - -#: ../source/support.rst:5 -msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." -msgstr "" - -#: ../source/support.rst:8 -msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:5 -msgid "Creating Documentation" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:7 -msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:13 -msgid "Installing Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:14 -msgid "Use ``pip`` to install Sphinx:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:28 -msgid "For other installation methods, see this `installation guide`_ by Sphinx." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:33 -msgid "Getting Started With Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:35 -msgid "Create a ``docs`` directory inside your project to hold your documentation:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:42 -msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:49 -msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:51 -msgid "You can add some information about your project in ``index.rst``, then build them:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:57 -msgid "For more details on the build process, see this `guide`_ by Read The Docs." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:62 -msgid "Other Sources" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:64 -msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/index.rst:4 -msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:5 -msgid "Installing Packages" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:7 -msgid "This section covers the basics of how to install Python :term:`packages `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:10 -msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:28 -msgid "Requirements for Installing Packages" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:30 -msgid "This section describes the steps to follow before installing other Python packages." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:35 -msgid "Ensure you can run Python from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:37 -msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:53 -msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:57 -msgid "If you're a newcomer and you get an error like this:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:66 -msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:72 -msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:82 -msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:87 -msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:99 -msgid "Ensure you can run pip from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:101 -msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:116 -msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:124 -msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:139 -msgid "If that still doesn't allow you to run ``python -m pip``:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:141 -msgid "Securely Download `get-pip.py `_ [1]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:144 -msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:150 -msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:159 -msgid "Ensure pip, setuptools, and wheel are up to date" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:161 -msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:169 -msgid "Optionally, create a virtual environment" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:171 -msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:188 -msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:195 -msgid "Creating Virtual Environments" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:197 -msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:203 -msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:209 -msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:213 -msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:216 -msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:220 -msgid "Currently, there are two common tools for creating Python virtual environments:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:222 -msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:225 -msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:230 -msgid "The basic usage is like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:232 -msgid "Using `venv`_:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:248 -msgid "Using :ref:`virtualenv`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:264 -msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:266 -msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:271 -msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:281 -msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:288 -msgid "Use pip for Installing" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:290 -msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:297 -msgid "Installing from PyPI" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:299 -msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:307 -msgid "To install the latest version of \"SomeProject\":" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:321 -msgid "To install a specific version:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:335 -msgid "To install greater than or equal to one version and less than another:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:350 -msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:365 -msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:370 -msgid "Source Distributions vs Wheels" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:372 -msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:378 -msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:383 -msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:391 -msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:408 -msgid "Installing to the User Site" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:410 -msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:425 -msgid "For more information see the `User Installs `_ section from the pip docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:429 -msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:432 -msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:440 -msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:446 -msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:462 -msgid "Install a list of requirements specified in a :ref:`Requirements File `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:478 -msgid "Installing from VCS" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:480 -msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:502 -msgid "Installing from other Indexes" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:504 -msgid "Install from an alternate index" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:518 -msgid "Search an additional index during install, in addition to :term:`PyPI `" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:534 -msgid "Installing from a local src tree" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:537 -msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:554 -msgid "You can also install normally from src" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:571 -msgid "Install a particular source archive file." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:585 -msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:605 -msgid "Installing from other sources" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:607 -msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:619 -msgid "Installing Prereleases" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:621 -msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:637 -msgid "Installing Setuptools \"Extras\"" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:639 -msgid "Install `setuptools extras`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:659 -msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:668 -msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:673 -msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:4 -msgid "Managing Application Dependencies" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:6 -msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:9 -msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:13 -msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:17 -msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:24 -msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:30 -msgid "Installing Pipenv" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:32 -msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:38 -msgid "Use ``pip`` to install Pipenv:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:54 -msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:65 -msgid "Installing packages for your project" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:67 -msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:76 -msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:112 -msgid "Using installed packages" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:114 -msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:125 -msgid "Then you can run this script using ``pipenv run``:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:131 -msgid "You should get output similar to this:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:137 -msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:143 -#: ../source/tutorials/packaging-projects.rst:594 -msgid "Next steps" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:145 -msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:148 -msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:151 -msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:160 -msgid "Other Tools for Application Dependency Management" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:162 -msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:166 -msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:172 -msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:175 -msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:177 -msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:2 -msgid "Packaging Python Projects" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:4 -msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:10 -msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:18 -msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:35 -msgid "A simple project" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:37 -msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:41 -msgid "Create the following file structure locally:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:51 -msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:54 -msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:63 -msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:67 -msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:75 -msgid "Creating the package files" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:77 -msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:95 -msgid "Creating a test directory" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:97 -msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:101 -msgid "Creating pyproject.toml" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:103 -msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:117 -msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:121 -msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:127 -msgid "See :pep:`517` and :pep:`518` for background and details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:131 -msgid "Configuring metadata" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:133 -msgid "There are two types of metadata: static and dynamic." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:135 -msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:137 -msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:141 -msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:148 -msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:153 -msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:185 -msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:191 -#: ../source/tutorials/packaging-projects.rst:286 -msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:196 -msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:199 -#: ../source/tutorials/packaging-projects.rst:293 -msgid "``author`` and ``author_email`` are used to identify the author of the package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:201 -#: ../source/tutorials/packaging-projects.rst:295 -msgid "``description`` is a short, one-sentence summary of the package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:202 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:206 -#: ../source/tutorials/packaging-projects.rst:300 -msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:208 -#: ../source/tutorials/packaging-projects.rst:302 -msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:211 -#: ../source/tutorials/packaging-projects.rst:305 -msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:213 -#: ../source/tutorials/packaging-projects.rst:307 -msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:221 -msgid "In the ``options`` category, we have controls for setuptools itself:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:223 -msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:227 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:234 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:238 -#: ../source/tutorials/packaging-projects.rst:329 -msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:244 -msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:248 -msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:283 -msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:291 -msgid "``version`` is the package version. See :pep:`440` for more details on versions." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:296 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:314 -msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:319 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:325 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:333 -msgid "Creating README.md" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:335 -msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:347 -msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:354 -msgid "Creating a LICENSE" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:356 -msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:387 -msgid "Including other files" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:389 -msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:393 -msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:402 -msgid "Generating distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:404 -msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:408 -msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:422 -msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:425 -msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:439 -msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:449 -msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:458 -msgid "Uploading the distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:460 -msgid "Finally, it's time to upload your package to the Python Package Index!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:462 -msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:470 -msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:477 -msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:492 -msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:506 -msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:510 -msgid "After the command completes, you should see output similar to this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:523 -msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:528 -msgid "Installing your newly uploaded package" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:530 -msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:546 -msgid "Make sure to specify your username in the package name!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:548 -msgid "pip should install the package from TestPyPI and the output should look something like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:558 -msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:565 -msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:580 -msgid "and import the package:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:588 -msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:596 -msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:599 -msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:604 -msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:608 -msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:610 -msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:613 -msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:617 -msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:619 -msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:622 -msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:624 -msgid "Read about :doc:`/guides/packaging-binary-extensions`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:625 -msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." -msgstr "" diff --git a/locales/ja/LC_MESSAGES/messages.po b/locales/ja/LC_MESSAGES/messages.po deleted file mode 100644 index d9157f01c..000000000 --- a/locales/ja/LC_MESSAGES/messages.po +++ /dev/null @@ -1,9596 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2013–2020, PyPA -# This file is distributed under the same license as the Python Packaging User Guide package. -# moto kawasaki , 2021. -msgid "" -msgstr "" -"Project-Id-Version: Python Packaging User Guide\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-12-04 07:51+0000\n" -"Last-Translator: moto kawasaki \n" -"Language-Team: Japanese \n" -"Language: ja\n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=UTF-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Plural-Forms: nplurals=1; plural=0;\n" -"X-Generator: Weblate 4.10-dev\n" - -#: ../source/contribute.rst:5 -msgid "Contribute to this guide" -msgstr "このガイドに貢献するには" - -#: ../source/contribute.rst:7 -msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" -msgstr "|PyPUG|は貢献者を歓迎します！さまざまな貢献方法があります。例えば：" - -#: ../source/contribute.rst:10 -msgid "Reading the guide and giving feedback" -msgstr "このガイドを読んでフィードバックを伝えること" - -#: ../source/contribute.rst:11 -msgid "Reviewing new contributions" -msgstr "新しい貢献文書を査読すること" - -#: ../source/contribute.rst:12 -msgid "Revising existing content" -msgstr "既存の文書を修正すること" - -#: ../source/contribute.rst:13 -msgid "Writing new content" -msgstr "新しく文書を書くこと" - -#: ../source/contribute.rst:15 -msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." -msgstr "" -"|PyPUG|のほとんどの作業は`プロジェクトのGitHubリポジトリ `__で行われます。手始めに`未解決の問題 `__のリストをチェックアウトして(改善策の)`" -"プルリクエスト `__を送ってください。もしあなたがこのガイドに何かを書き加えたり編集したりするつもりなら、:ref:`" -"スタイルガイド `__を読みましょう。" - -#: ../source/contribute.rst:24 -msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." -msgstr "|PyPUG|に貢献を行うのであれば、あなたがPSFの`行動規範 `__に従うことが期待されています。" - -#: ../source/contribute.rst:31 -msgid "Documentation types" -msgstr "文書の類型" - -#: ../source/contribute.rst:33 -msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." -msgstr "" -"本プロジェクトは、特定の目的に合わせた四つの別個の文書類型で成り立っています。新たに追加することを提案する場合には、いずれかの適切な文書類型を選択してくだ" -"さい。" - -#: ../source/contribute.rst:38 -#: ../source/tutorials/index.rst:2 -msgid "Tutorials" -msgstr "チュートリアル型文書" - -#: ../source/contribute.rst:40 -msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." -msgstr "" -"チュートリアルは目標を達成することで読者に新しい概念を教えることに注力しています。こうするべきだという意見に従ったステップバイステップのガイドになっていま" -"す。大筋に無関係な警告や情報は省略されています。`チュートリアル型文書の例 `_." - -#: ../source/contribute.rst:47 -#: ../source/guides/index.rst:2 -msgid "Guides" -msgstr "ガイド型文書" - -#: ../source/contribute.rst:49 -msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." -msgstr "" -"ガイドは特定のタスクを達成することに力点を置いていて、前提となる知識のレベルをある程度仮定することができます。ガイドはチュートリアルと似ていますが、しかし" -"ガイドはもっと狭い分野に明確に焦点を当てるものであり、必要に応じて多数の注意書きを行ったり追加的な情報を盛り込んだりすることができます。ガイドでは、そのタ" -"スクを達成するための複数のやり方を議論することもできます。:doc:`ガイド型文書の例 `." - -#: ../source/contribute.rst:56 -#: ../source/discussions/index.rst:2 -msgid "Discussions" -msgstr "議論型文書" - -#: ../source/contribute.rst:58 -msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." -msgstr "" -"議論型文書では、理解促進と情報提供に重点を置きます。議論型文書では、特定のゴールを念頭に置くことなく、ある特定の話題について深く探求します。:doc:`" -"議論型文書の例 `." - -#: ../source/contribute.rst:63 -msgid "Specifications" -msgstr "仕様型文書" - -#: ../source/contribute.rst:65 -msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." -msgstr "" -"仕様型文書は、パッケージングツール間で相互運用のためのインターフェイスとして合意された事項について網羅的に文書化することに重点を置く参照用の文書です。:d" -"oc:`仕様型文書の例 `." - -#: ../source/contribute.rst:73 -msgid "Building the guide locally" -msgstr "この文書を手元でビルドするには" - -#: ../source/contribute.rst:75 -msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" -msgstr "" -"貢献寄与をするために必須というわけではありませんが、この文書を手元でビルドすることはあなたが行った変更をテストするのに役に立ちます。この文書を手元でビルド" -"するには：" - -#: ../source/contribute.rst:79 -msgid "`Nox `_. You can install or upgrade nox using ``pip``::" -msgstr "" -"`Nox `_. " -"noxは``pip``::を用いてインストールまたはアップグレードできます。" - -#: ../source/contribute.rst:84 -msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." -msgstr "" -"Python 3.6. 我々のビルドスクリプトはPython 3.6でのみ動作するように設計されている。あなたの使っているOSにPython " -"3.6をインストールする方法については `Hitchhiker's Guide to Python のインストールの手引き `_ を見てほしい。" - -#: ../source/contribute.rst:91 -msgid "To build the guide, run the following bash command in the source folder::" -msgstr "この文書をビルドするには、以下のbashコマンドをsourceディレクトリで実行してください。::" - -#: ../source/contribute.rst:95 -msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." -msgstr "" -"処理が終わると、``./build/html``の下にHTMLの出力ファイルが見つかるはずです。ここの``index." -"html``をブラウザで開くことでこの文書を閲覧することができますが、HTTPサーバを使って文書を提供する方がお勧めです。" - -#: ../source/contribute.rst:100 -msgid "You can build the guide and serve it via an HTTP server using the following command::" -msgstr "HTTPサーバを用いてこの文書を提供するには、以下のコマンドを使います。::" - -#: ../source/contribute.rst:105 -msgid "The guide will be browsable via http://localhost:8000." -msgstr "この文書は、http://localhost:8000から閲覧できます。" - -#: ../source/contribute.rst:109 -msgid "Where the guide is deployed" -msgstr "この文書が展開される場所" - -#: ../source/contribute.rst:111 -msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." -msgstr "" -"この文書はReadTheDocsを通じて展開されていて、https://readthedocs.org/projects/" -"python-packaging-user-guide/から読めるようになっています。また、Fast." -"lyから独自のドメイン名から提供されるようになっています(第二文はここだけでは意味が取れない)。" - -#: ../source/contribute.rst:117 -msgid "Style guide" -msgstr "スタイルガイド" - -#: ../source/contribute.rst:119 -msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." -msgstr "" -"このスタイルガイドは、あなたがどのように|PyPUG|を書くべきかについて推奨事項を与えます。あなたが書き始める前に目を通してください。スタイルガイドに従" -"うことであなたの貢献がまとまりのある全体の中の一部として追加され、あなたの貢献がプロジェクトによって受け入れられやすくなります。" - -#: ../source/contribute.rst:126 -msgid "Purpose" -msgstr "目的" - -#: ../source/contribute.rst:128 -msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." -msgstr "" -"|PyPUG|の目的は、現在のツール群を用いてPythonプロジェクトをパッケージし、公開し、インストールする方法に関して権威ある参照先となることです。" - -#: ../source/contribute.rst:133 -msgid "Scope" -msgstr "スコープ" - -#: ../source/contribute.rst:135 -msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." -msgstr "この文書は、正確で的を射た推奨事項を添えた形で疑問に答え問題を解決することを意図しています。" - -#: ../source/contribute.rst:138 -msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." -msgstr "" -"この文書は網羅的であることを目指してはおらず、それぞれのプロジェクトのドキュメントを置き換えることも意図していません。例えば、pipにはたくさんのコマンド" -"やオプションや設定事項があります。pipのドキュメントはその一つ一つについて詳細に記述していますが、この文書ではこの文書に記述されたタスクを完了するために" -"必要となる部分に限ってpipに触れています。" - -#: ../source/contribute.rst:146 -msgid "Audience" -msgstr "想定される読者" - -#: ../source/contribute.rst:148 -msgid "The audience of this guide is anyone who uses Python with packages." -msgstr "この文書の読者として想定されるのは、Pythonのパッケージを扱う方です。" - -#: ../source/contribute.rst:150 -msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." -msgstr "" -"Pythonコミュニティが巨大で温かいコミュニティであることを忘れないでください。読者は年齢・性別・教育程度・文化やその他諸々の点であなたと同じではないか" -"もしれませんが、しかし、あなたがあなたにできる限りパッケージングについて学ぶことを称賛します。" - -#: ../source/contribute.rst:154 -msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." -msgstr "" -"とりわけ、Pythonを使う人なら誰でも自分をプログラマーだと思っているというわけではないことを覚えておいてください。この文書の想定される読者には、ソフト" -"ウェア開発を職業としているプロだけでなく、宇宙飛行士や画家あるいは学生も含まれるのです。" - -#: ../source/contribute.rst:160 -msgid "Voice and tone" -msgstr "口調や語調" - -#: ../source/contribute.rst:162 -msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." -msgstr "この文書を書く時には、たとえあなたが答えを全部わかっていたとしても親しみやすく控えめな語調で書くように努力してください。" - -#: ../source/contribute.rst:165 -msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." -msgstr "" -"頭が良くてスキルのある人たちと一緒にPythonのプロジェクトをやるところを思い描いてください。あなたは彼らと働くのが好きだし、彼らもあなたと働くのが好き" -"なのです。そんな人があなたに質問をして、あなたが答えを知っていたとしましょう。あなたはどんな風に応対しますか？*それ*こそが、あなたがこの文書を書く時のや" -"り方なのです。" - -#: ../source/contribute.rst:170 -msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." -msgstr "" -"簡単な確認方法：あなたが書いたものを声に出して読めば、その口調や語調の感じがわかります。それはあなたが言いたかった感じに響きましたか、それとも、演説の一部" -"みたいに聞こえましたか？短縮形を使っても構いませんし、曖昧な文法規則に固執することはありません。あなたはここに、もしそうしたいのならば前置詞で文を終わって" -"も構わないと言う権限を与えられました。" - -#: ../source/contribute.rst:177 -msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." -msgstr "" -"ガイド文書を書くときは、論題の深刻さや難しさに合った語調に調整してください。もしあなたが入門篇のようなチュートリアルを書くときには冗談を挟んでも構いません" -"が、繊細な注意を必要とするセキュリティ上の推奨事項をカバーするなら冗談を全く入れないようにしたいと思うかもしれません。" - -#: ../source/contribute.rst:184 -msgid "Conventions and mechanics" -msgstr "慣例と手順" - -#: ../source/contribute.rst:192 -msgid "**Write to the reader**" -msgstr "**読者に向けて書く**" - -#: ../source/contribute.rst:187 -msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." -msgstr "推奨事項や実行すべきステップを与えるときは、読者に*あなた*と呼びかけるか、または、命令法を用いて欲しい。" - -#: ../source/contribute.rst:0 -msgid "Wrong: To install it, the user runs…" -msgstr "誤：それをインストールするために、ユーザは...を実行します。" - -#: ../source/contribute.rst:0 -msgid "Right: You can install it by running…" -msgstr "正：...を実行することであなたはそれをインストールすることができます。" - -#: ../source/contribute.rst:0 -msgid "Right: To install it, run…" -msgstr "正：それをインストールするには、...を実行してください。" - -#: ../source/contribute.rst:198 -msgid "**State assumptions**" -msgstr "**前提条件の明示**" - -#: ../source/contribute.rst:195 -msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." -msgstr "" -"暗黙のうちに前提条件を仮定することのないようにしましょう。Webページとして提供するということは、この文書のどのページであってもそれが読者にとっての初めて" -"のページになるかもしれないということです。" - -#: ../source/contribute.rst:203 -msgid "**Cross-reference generously**" -msgstr "**豊富な相互参照**" - -#: ../source/contribute.rst:201 -msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." -msgstr "" -"あるツールや行為にあなたが初めて言及するときには、ガイドのそれを説明している部分へのリンク、または、どこか他の場所であっても適切な説明文書へのリンクも提供" -"してください。" - -#: ../source/contribute.rst:213 -msgid "**Respect naming practices**" -msgstr "**命名慣習を尊重すること**" - -#: ../source/contribute.rst:206 -msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." -msgstr "ツールやサイト、登場人物や他の適切な名詞に名前を付けるときには、大文字小文字などそれぞれが好んで使っている書き方を尊重してください。" - -#: ../source/contribute.rst:0 -msgid "Wrong: Pip uses…" -msgstr "誤：Pipは…" - -#: ../source/contribute.rst:0 -msgid "Right: pip uses…" -msgstr "正：pipは…" - -#: ../source/contribute.rst:0 -msgid "Wrong: …hosted on github." -msgstr "誤：...はgithubにホストされている。" - -#: ../source/contribute.rst:0 -msgid "Right: …hosted on GitHub." -msgstr "正：...はGitHubにホストされている。" - -#: ../source/contribute.rst:222 -msgid "**Use a gender-neutral style**" -msgstr "**ジェンダー中立なスタイルを使う**" - -#: ../source/contribute.rst:216 -msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." -msgstr "" -"あなたが読者に直接呼びかけるときは「あなた」「あなたの」「あなたのもの」を使ってください。そうできない場合は代名詞として「彼ら」「彼らの」「彼らのもの」を" -"使う(訳註：従来なら\"he\", \"she\"を用いた場所に\"they\"を使うことでジェンダーへの配慮を示す場合がある" -")か、または、代名詞をまったく使わないようにしましょう。" - -#: ../source/contribute.rst:0 -msgid "Wrong: A maintainer uploads the file. Then he…" -msgstr "誤：メンテナンス担当者がファイルをアップロードする。それから、彼は…" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then they…" -msgstr "正：メンテナンス担当者がファイルをアップロードする。それから、彼らは…" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then the maintainer…" -msgstr "正：メンテナンス担当者がファイルをアップロードする。それから、メンテナンス担当者は…" - -#: ../source/contribute.rst:234 -msgid "**Headings**" -msgstr "**見出しの付け方**" - -#: ../source/contribute.rst:225 -msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." -msgstr "" -"見出しには読者が検索で使うような単語を使いましょう。質問の意図に答える形で見出しを書くのは良い方法です。読者が例えば*MyLibraryをインストールする" -"にはどうすれば良いの？*ということを知りたいとすれば、適切な見出しとしては*MyLibraryをインストールするには*のようになるでしょう。" - -#: ../source/contribute.rst:230 -msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." -msgstr "見出し部分では通常の文章のように大文字小文字を使いましょう。言い換えるなら、ごく普通の文を書く時のように見出しを書きましょう。" - -#: ../source/contribute.rst:0 -msgid "Wrong: Things You Should Know About Python" -msgstr "誤：Pythonについてあなたが知っておくべき事柄 (訳註：日本語には大文字小文字の区別がないので誤例にならないのではないか)" - -#: ../source/contribute.rst:0 -msgid "Right: Things you should know about Python" -msgstr "正：Pythonについてあなたが知っておくべき事柄" - -#: ../source/contribute.rst:237 -msgid "**Numbers**" -msgstr "**数値の書き方**" - -#: ../source/contribute.rst:237 -msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." -msgstr "" -"地の文では一から九までの数字を単語で書きましょう(訳註：日本語では漢数字にするよりもアラビア数字の方が適切かもしれません)。表の中ではアラビア数字で書きま" -"しょう。" - -#: ../source/discussions/deploying-python-applications.rst:4 -msgid "Deploying Python applications" -msgstr "Pythonで書かれたアプリケーションを配置(deploy)する" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Page Status" -msgstr "ページステイタス" - -#: ../source/discussions/deploying-python-applications.rst:6 -#: ../source/guides/index-mirrors-and-caches.rst:7 -#: ../source/guides/installing-using-linux-tools.rst:7 -#: ../source/guides/packaging-binary-extensions.rst:7 -#: ../source/guides/supporting-multiple-python-versions.rst:7 -#: ../source/guides/supporting-windows-using-appveyor.rst:5 -msgid "Incomplete" -msgstr "未完了" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Last Reviewed" -msgstr "最終査読日" - -#: ../source/discussions/deploying-python-applications.rst:7 -msgid "2014-11-11" -msgstr "2014年11月11日" - -#: ../source/discussions/deploying-python-applications.rst:11 -#: ../source/discussions/install-requires-vs-requirements.rst:9 -#: ../source/guides/analyzing-pypi-package-downloads.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:22 -#: ../source/guides/index-mirrors-and-caches.rst:12 -#: ../source/guides/installing-scientific-packages.rst:9 -#: ../source/guides/packaging-binary-extensions.rst:17 -#: ../source/guides/supporting-multiple-python-versions.rst:12 -#: ../source/guides/supporting-windows-using-appveyor.rst:15 -#: ../source/overview.rst:23 -#: ../source/specifications/core-metadata.rst:38 -#: ../source/specifications/direct-url.rst:14 -#: ../source/tutorials/installing-packages.rst:23 -msgid "Contents" -msgstr "内容" - -#: ../source/discussions/deploying-python-applications.rst:14 -msgid "Overview" -msgstr "概要" - -#: ../source/discussions/deploying-python-applications.rst:18 -msgid "Supporting multiple hardware platforms" -msgstr "複数のハードウェアプラットフォームをサポートする" - -#: ../source/discussions/deploying-python-applications.rst:40 -msgid "OS packaging & installers" -msgstr "OSパッケージングとインストーラ" - -#: ../source/discussions/deploying-python-applications.rst:52 -msgid "Windows" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:61 -msgid "Pynsist" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:63 -msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." -msgstr "" -"`Pynsist `__は、Pythonで書かれたプログラム群をNSISベースのPyt" -"honインタープリタ付きの単体インストーラにまとめるツールです。ほとんどの場合、パッケージング作業ではユーザがPythonインタープリタのバージョンを選択" -"することとプログラムの依存関係を宣言することしか求められません。このツールは、指定されたWindows版のPythonインタープリタをダウンロードして、依" -"存関係にあるすべてをWindows上で実行可能な単体インストーラにまとめます。" - -#: ../source/discussions/deploying-python-applications.rst:70 -msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." -msgstr "" -"インストーラがスタートメニューに追加したショートカットから、インストールされたプログラムを起動することができます。プログラムは、そのアプリケーション用のデ" -"ィレクトリの中にインストールされたPythonインタープリタで同じコンピュータ内にある他のPythonからは独立したをものを使います。" - -#: ../source/discussions/deploying-python-applications.rst:74 -msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." -msgstr "" -"Pynsistを使う大きな利点は、Windows用のパッケージをLinux上で作成することができるということです。`説明文書 " -" `__には異なる種類のプログラム(コンソール用やGUIを使うものなど)の例がいくつかあります。このツールはMITライセンスのもとに公開されています。" - -#: ../source/discussions/deploying-python-applications.rst:80 -msgid "Application bundles" -msgstr "アプリケーションバンドル" - -#: ../source/discussions/deploying-python-applications.rst:91 -msgid "Configuration management" -msgstr "設定管理" - -#: ../source/discussions/index.rst:4 -msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." -msgstr "" -"**議論型文書**は、特定の話題について網羅的な情報を提供することに重点を置いています。もしあなたがとにかく何かを終わらせようとしているだけなら、:doc" -":`/guides/index`を見た方が良いでしょう。" - -#: ../source/discussions/install-requires-vs-requirements.rst:5 -msgid "install_requires vs requirements files" -msgstr "install_requiresかrequirementsか" - -#: ../source/discussions/install-requires-vs-requirements.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:382 -msgid "install_requires" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:14 -msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." -msgstr "" -"``install_requires``は:ref:`setuptools` :file:`setup.py`のキーワードで、そのプロジェクトが正しく動作" -"するために必要な最小限のものを指定するものです。プロジェクトが:ref:`pip`でインストールされた場合には、プロジェクトが依存するパッケージをインスト" -"ールするのに用いられます。" - -#: ../source/discussions/install-requires-vs-requirements.rst:19 -msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" -msgstr "例えば、プロジェクトがAとBに依存しているなら、``install_requires``は次のようになるでしょう：" - -#: ../source/discussions/install-requires-vs-requirements.rst:29 -msgid "Additionally, it's best practice to indicate any known lower or upper bounds." -msgstr "さらに、下限や上限がわかっているなら、それを示しておくことがベストプラクティスです。" - -#: ../source/discussions/install-requires-vs-requirements.rst:31 -msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" -msgstr "例えば、あなたのプロジェクトが少なくともv1の'A'と少なくともv2の'B'を必要とするとわかっているなら、次のようになるでしょう：" - -#: ../source/discussions/install-requires-vs-requirements.rst:41 -msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" -msgstr "" -"また、Aがセマンティックバージョニングの方法に従っていて'A'の(将来の)v2は互換性を持たなくなるだろうかということがわかっているので、(自分たちのプロ" -"ジェクトの側では)v2を許容したくないとしましょう：" - -#: ../source/discussions/install-requires-vs-requirements.rst:51 -msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." -msgstr "" -"依存関係にあるものを特定のバージョンに固定するために、あるいは、さらなる依存関係(すなわち、あなたの依存先が依存するもの)を指定するために``instal" -"l_requires``を使うことはベストプラクティスとは考えられていません。これは過剰に制限的であり、依存関係にあるものをまとめて更新することからユーザ" -"が得られる利益を阻害するものと考えられています。" - -#: ../source/discussions/install-requires-vs-requirements.rst:56 -msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" -msgstr "" -"最後に、``install_requires``が必要事項の「要約」のリスト、つまり、単に必要事項の名前とバージョンが要求されるだけあって、どこから(すな" -"わち、どんな索引や情報源から)充当するのかについては要求していないのだということを理解することは重要です。どこから(すなわち、どのようにして「具体化」され" -"るのか)という点については、:ref:`pip`のオプションを使ってインストール時に決定されるのです。[1]_" - -#: ../source/discussions/install-requires-vs-requirements.rst:64 -#: ../source/tutorials/installing-packages.rst:460 -msgid "Requirements files" -msgstr "Requirementsファイル" - -#: ../source/discussions/install-requires-vs-requirements.rst:66 -msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." -msgstr "" -":ref:`Requirementsファイル `は、一番簡単にいうならば、:ref:`pip:pip " -"install`の引数のリストをファイルに書いただけのものです。" - -#: ../source/discussions/install-requires-vs-requirements.rst:69 -msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." -msgstr "" -"``install_requires``が単一のプロジェクトにおける依存関係を定義する一方で、:ref:`Requirements Files `はPython環境全体に対する要求事項を定義するのにしばしば用いられます。" - -#: ../source/discussions/install-requires-vs-requirements.rst:73 -msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." -msgstr "" -"``install_requires``での要求事項が最小限のものである一方で、requirementsファイルは再現可能な形で環境全体をインストールでき" -"るようにする:ref:`repeatable installations " -"`という目的に沿って限定されたバージョンの網羅的なリストを含むことがしばしばです。" - -#: ../source/discussions/install-requires-vs-requirements.rst:78 -msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" -msgstr "" -"``install_requires``での要求事項が「要約」、すなわち特定の索引には紐づけられていないのに対して、requirementsファイルではし" -"ばしば``--index-url``や``--find-" -"links``のようなpipのオプションが含まれていて特定の索引やパッケージ登録簿に紐づけられた「具体的な」要求事項になっています。[1]_" - -#: ../source/discussions/install-requires-vs-requirements.rst:84 -msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." -msgstr "" -"``install_requires``では、メタデータがインストール中にpipによって自動的に解析される一方、requirementsファイルではそうで" -"はなく、``python -m pip install -r``を使ってユーザが明示的にインストールする時に使われるだけです。" - -#: ../source/discussions/install-requires-vs-requirements.rst:90 -msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." -msgstr "" -"要求事項が「要約」か「具体的」かの議論についてもっと知りたい場合は、https://caremad.io/2013/07/" -"setup-vs-requirement/をご覧ください。" - -#: ../source/discussions/pip-vs-easy-install.rst:6 -msgid "pip vs easy_install" -msgstr "pip対easy_install" - -#: ../source/discussions/pip-vs-easy-install.rst:9 -msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." -msgstr "" -":ref:`easy_install `は、現在では`非推奨`とされていますが、2004年に:ref:`setuptools`" -"の一部として公開されました。requirementsファイルを利用して自動的に依存関係にあるパッケージも併せて:term:`PyPI `から:term:`packages `をインストールすることができるというのは当時としては画期的でした。" - -#: ../source/discussions/pip-vs-easy-install.rst:14 -msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." -msgstr "" -"依然として:ref:`setuptools`を部品に使ってビルドされてはいますが、:ref:`easy_install " -"`を置き換えるものとして:ref:`pip`が2008年に後からやってきました。当時はパッケージを(かなり単純に:term:`" -"sdists `から「フラット」なパッケージとしてインストールするものであって):term:`Eggs `の形でインストールするものでも、:term:`" -"Eggs `からインストールするものでも*なかった*こと、そして、簡単に環境を再現する力をユーザに与える:ref:`Requirements " -"Files `の考え方を導入したことは注目に値します。" - -#: ../source/discussions/pip-vs-easy-install.rst:22 -msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" -msgstr "pipと非推奨となったeasy_installの重要な違いをおさらいしておきましょう：" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**pip**" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**easy_install**" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -msgid "Installs from :term:`Wheels `" -msgstr ":term:`Wheels `からのインストール" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Yes" -msgstr "はい" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:30 -#: ../source/discussions/pip-vs-easy-install.rst:32 -#: ../source/discussions/pip-vs-easy-install.rst:35 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:51 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "No" -msgstr "いいえ" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Uninstall Packages" -msgstr "パッケージのアンインストール" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Yes (``python -m pip uninstall``)" -msgstr "はい (``python -m pip uninstall``)" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Dependency Overrides" -msgstr "依存関係を上書きする" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Yes (:ref:`Requirements Files `)" -msgstr "はい (:ref:`Requirementsファイル `" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "List Installed Packages" -msgstr "インストールされたパッケージのリスト" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" -msgstr "はい (``python -m pip list`` and ``python -m pip freeze``)" - -#: ../source/discussions/pip-vs-easy-install.rst:38 -msgid ":pep:`438` Support" -msgstr ":pep:`438` サポート" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Installation format" -msgstr "インストールフォーマット" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "'Flat' packages with :file:`egg-info` metadata." -msgstr ":file:`egg-info`のメタデータを伴った「フラット」なパッケージ。" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Encapsulated Egg format" -msgstr "カプセル化されたEggフォーマット" - -#: ../source/discussions/pip-vs-easy-install.rst:44 -msgid "sys.path modification" -msgstr "sys.pathの変更" - -#: ../source/discussions/pip-vs-easy-install.rst:48 -msgid "Installs from :term:`Eggs `" -msgstr ":term:`Eggs `からのインストール" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "`pylauncher support`_" -msgstr "`pylauncherサポート `_" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "Yes [1]_" -msgstr "はい [1]_" - -#: ../source/discussions/pip-vs-easy-install.rst:54 -msgid ":ref:`Multi-version Installs`" -msgstr ":ref:`複数バージョンのインストール `" - -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Exclude scripts during install" -msgstr "インストール中にスクリプトを除外する" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "per project index" -msgstr "プロジェクトごとの索引" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Only in virtualenv" -msgstr "virtualenvの中のみ" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Yes, via setup.cfg" -msgstr "はい、setup.cfgを通じて" - -#: ../source/discussions/pip-vs-easy-install.rst:68 -msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:5 -msgid "Wheel vs Egg" -msgstr "Wheel対Egg" - -#: ../source/discussions/wheel-vs-egg.rst:7 -msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." -msgstr "" -":term:`Wheel`と :term:`Egg`は、どちらも、試験目的の場合や本番環境の場合にはコストが高すぎるビルドやコンパイルをしなくてもプログラ" -"ムをインストールするというユースケースに対応することを目指したパッケージングのフォーマットです。" - -#: ../source/discussions/wheel-vs-egg.rst:11 -msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." -msgstr "" -":term:`Egg`のフォーマットは、2004年に:ref:`setuptools`によって、また、:term:`Wheel`のフォーマットは2012年" -"に:pep:`427`によって導入されました。" - -#: ../source/discussions/wheel-vs-egg.rst:14 -msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." -msgstr "" -":term:`Wheel`は、現在、Pythonにおける :term:`ビルド済配布物 `および :term:`" -"バイナリ配布物 `の標準であるとみなされています。" - -#: ../source/discussions/wheel-vs-egg.rst:17 -msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." -msgstr ":term:`Wheel`と :term:`Egg`の重要な差異について以下にまとめます。" - -#: ../source/discussions/wheel-vs-egg.rst:20 -msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." -msgstr ":term:`Wheel`には :pep:`公式PEP <427>`が存在します。 :term:`Egg`には対応するPEPがありません。" - -#: ../source/discussions/wheel-vs-egg.rst:22 -msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." -msgstr "" -":term:`Wheel`は :term:`配布物 `のフォーマット、つまり、パッケージのフォーマットです。[1]_ :term:`Egg`は配布物のフォーマットでもあり、かつ、(もし圧縮さ" -"れたままであれば)実行時のインストールフォーマットであってimportができるように設計されています。" - -#: ../source/discussions/wheel-vs-egg.rst:26 -msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." -msgstr "" -":term:`Wheel`形式のファイルには.pycファイルが含まれていません。従って、配布物には(コンパイル済のファイル抜きの)Pythonファイルのみ" -"(含み、Pythonのバージョン2と3で使用可能ですので、 :term:`sdist `と同様にwheelは「汎用」であると言うことができます。" - -#: ../source/discussions/wheel-vs-egg.rst:31 -msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." -msgstr "" -":term:`Wheel`は :pep:`PEP376-compliant <376>`に従って ``.dist-info`` ディレクトリを用います。" -"Eggは ``.egg-info`` を用います。" - -#: ../source/discussions/wheel-vs-egg.rst:34 -msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." -msgstr "" -":term:`Wheel`には:pep:`richer file naming convention <425>`が存在します。単独のwheelアーカイブ" -"はPython言語のバージョンや実装、ABI、そしてシステムのアーキテクチャとの互換性を表示することができます。" - -#: ../source/discussions/wheel-vs-egg.rst:38 -msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." -msgstr "" -":term:`Wheel`はバージョン付けされています。それぞれのwheelファイルは、それをパッケージしたwheelの仕様や実装のバージョンを保持してい" -"ます。" - -#: ../source/discussions/wheel-vs-egg.rst:41 -msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." -msgstr "" -":term:`Wheel`は内部では`sysconfigパスの型 `_で整理されているので、他のフォーマットに変換するのがより簡単になっています。" - -#: ../source/discussions/wheel-vs-egg.rst:47 -msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." -msgstr "" -":pep:`Wheelファイルから直接にimportすることは現時点では公式にサポートされていません<427#is-it-possible-to-" -"import-python-code-directly-from-a-wheel-" -"file>`が、状況によって幾つかのケースでwheelは重要な実行時フォーマットとして使われます。" - -#: ../source/glossary.rst:3 -msgid "Glossary" -msgstr "用語集" - -#: ../source/glossary.rst:8 -msgid "Binary Distribution" -msgstr "バイナリ配布物" - -#: ../source/glossary.rst:11 -msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." -msgstr "`ビルド済配布物 `の特定の種類で、コンパイル済みの拡張部分を含むもの。" - -#: ../source/glossary.rst:14 -msgid "Built Distribution" -msgstr "ビルド済配布物" - -#: ../source/glossary.rst:17 -msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." -msgstr "" -":term:`配布物 `とは、ターゲットとなるシステムの適切な位置に移動することでインストールされるファイルや" -"メタデータを内包したフォーマットです。:term:`Wheel`はそのようなフォーマットですが、他方で、distutilの :term:`" -"ソースコード配布物 `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." -msgstr "" -":term:`モジュール `すなわちPythonの :term:`パッケージ `や、ある :term:`R" -"elease`を配布するために使われるその他のリソースファイルを内部に含むバージョン付きアーカイブファイル。アーカイブファイルはエンドユーザがインターネッ" -"トからダウンロードしてインストールするものです。" - -#: ../source/glossary.rst:34 -msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." -msgstr "" -"配布物パッケージは単語ひとつで「パッケージ」や「配布物」と呼ばれることもしばしばですが、 :term:`Import Package`(これも通常は単に「" -"パッケージ」と呼ばれます)や他の種類の配布物(例えばLinuxディストリビューションやPython言語の配布物)でよく単語ひとつの「配布物」と呼ばれるもの" -"との混同を避けるために明確に述べる必要がある場合には、本ガイドでは長い方の呼び方を用いることがあります。" - -#: ../source/glossary.rst:41 -msgid "Egg" -msgstr "Egg" - -#: ../source/glossary.rst:44 -msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" -msgstr "" -":term:`ビルド済配布物 `フォーマットは :ref:`setuptools`によって導入されましたが、 " -":term:`Wheel`によって置き換えられつつあります。詳細については、`Python Eggの内部構造 `_と`Python Eggs " -"`_ を参照してください。" - -#: ../source/glossary.rst:49 -msgid "Extension Module" -msgstr "拡張モジュール" - -#: ../source/glossary.rst:52 -msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." -msgstr "" -":term:`モジュール `とは、Pythonの実装のうちの低レベル言語で書かれた部分で、C/C++で書かれたCythonやJavaで書か" -"れたJythonが該当する。典型的には動的にロードできるコンパイル済みのファイルをひとつ含んでいて、Unix上では共有オブジェクトファイル(." -"so)、Windows上ではDLL(拡張子.pydを与えられる)のPython拡張、Jython拡張ではJavaのクラスファイルの形を取る。" - -#: ../source/glossary.rst:59 -msgid "Known Good Set (KGS)" -msgstr "既知の良好な組み合わせ(KGS)" - -#: ../source/glossary.rst:62 -msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." -msgstr "" -"(KGSとは)相互に互換性のある特定のバージョンの配布物の集合。典型的には、テストスイートで全てのテストに合格して実行できるようなパッケージの特定の組み合" -"わせが既知の良好なセット(KGS)であると宣言されます。この用語は、個々の配布物を複数組み合わせて構成されるフレームワークやツールキットで共通して用いられ" -"ます。" - -#: ../source/glossary.rst:68 -msgid "Import Package" -msgstr "パッケージをimportする" - -#: ../source/glossary.rst:71 -msgid "A Python module which can contain other modules or recursively, other packages." -msgstr "直接に、あるいは何段階になっても良いが、他のパッケージを組み込んで使うようなPythonモジュール。" - -#: ../source/glossary.rst:74 -msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." -msgstr "" -"インポートパッケージは、より普通には「パッケージ」という用語で呼ばれますが、本ガイドでは、同様に単に「パッケージ」と呼ばれることが普通である " -":term:`配布物パッケージ `との混同を避けるために必要な場合には、長い方の用語を用いることにします。" - -#: ../source/glossary.rst:78 -msgid "Module" -msgstr "モジュール" - -#: ../source/glossary.rst:81 -msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." -msgstr "" -"Pythonにおけるソースコード再利用の基本的な単位で、 :term:`Pure Module`か :term:`Extension " -"Module`の二つのタイプのうちのいずれか。" - -#: ../source/glossary.rst:84 -msgid "Package Index" -msgstr "パッケージ索引" - -#: ../source/glossary.rst:87 -msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." -msgstr "" -":term:`パッケージ `の発見・消費(訳註、意訳になるが検索・ダウンロードが適切か)を自動化するwebインターフェイスを伴った配布物のリポジトリ。" - -#: ../source/glossary.rst:90 -msgid "Per Project Index" -msgstr "プロジェクト単位の索引" - -#: ../source/glossary.rst:93 -msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." -msgstr "" -"ある :term:`プロジェクト `が嗜好するか要求する依存関係を解決するために、:term:`プロジェクト `" -"の単位で示された仲間内または非公式の :term:`パッケージ索引 `。" - -#: ../source/glossary.rst:97 -msgid "Project" -msgstr "プロジェクト" - -#: ../source/glossary.rst:100 -msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." -msgstr "" -"ライブラリ、フレームワーク、スクリプト、プラグイン、アプリケーション、ないし一連のデータもしくはその他のリソース、または、これらの組み合わせで " -":term:`配布物 `として意図的にパッケージされたもの。" - -#: ../source/glossary.rst:104 -msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." -msgstr "" -"ほとんどのプロジェクトで :pep:`518` ``build-system``として :ref:`distutils`か " -":ref:`setuptools`を用いて :term:`配布物 `を作成しますので、現時点でプロジェクトを定義するもうひとつの実践的な方法は、プロジェクトのソースコードの一番上のディレクトリに " -":term:`pyproject.toml`や :term:`setup.py`または :term:`setup." -"cfg`のファイルを含む何ものかというものです。" - -#: ../source/glossary.rst:110 -msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." -msgstr "" -"Pythonにおけるプロジェクトは、 :term:`PyPI `に登録される一意の名前を持っていなければなりません。そして、プロジェクトはそれぞれひとつまたはより多くの :term:`リリース " -"`を含んでいて、各リリースはひとつまたはより多くの :term:`配布物 `を内包しています。" - -#: ../source/glossary.rst:115 -msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." -msgstr "" -"そのプロジェクトを稼働させるためにインポートされるパッケージの名前に因んでプロジェクトに名前をつけるのが普通であるという強い慣習があることを覚えておいてく" -"ださい。しかしながら、常にそうしなければならないわけではありません。「なんとか」というプロジェクトから配布物をインストールしていながらも、「かんとか」(訳" -"註、「なんとか」とは無関係の別の名前の例)という名前でのみインポート可能なパッケージを提供することは可能です。" - -#: ../source/glossary.rst:121 -msgid "Pure Module" -msgstr "純粋なモジュール" - -#: ../source/glossary.rst:124 -msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." -msgstr "" -"Pythonで書かれていて単一の``.py``ファイル(とおそらくは対応する``.pyc``ファイルや``.pyo``ファイル)に収められた " -":term:`モジュール `。" - -#: ../source/glossary.rst:127 -msgid "Python Packaging Authority (PyPA)" -msgstr "Pythonパッケージングオーソリティ(PyPA)" - -#: ../source/glossary.rst:130 -msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." -msgstr "" -"PyPAは、Pythonのパッケージングに関係する多くのプロジェクトを維持管理する作業グループです。その活動の一環として https://" -"www.pypa.io を維持管理しており、 `GitHub `_ と `Bitbucket " -"`_ に関連プロジェクトを置くとともに、 `distutils-sig メーリングリスト " -"`_ と `" -"Python談話フォーラム `__ で議論を進めています。" - -#: ../source/glossary.rst:139 -msgid "Python Package Index (PyPI)" -msgstr "Pythonパッケージインデックス (PyPI)" - -#: ../source/glossary.rst:142 -msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." -msgstr "" -"`PyPI `_ は、Pythonコミュニティにとってデフォルトの :term:`Package " -"Index`です。ここから配布物を取り出し、また、配布するためにすべてのPython開発者に開かれています。" - -#: ../source/glossary.rst:145 -msgid "pypi.org" -msgstr "pypi.org" - -#: ../source/glossary.rst:148 -msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." -msgstr "" -"`pypi.org `_ は、 :term:`Python パッケージインデックス(PyPI)` " -"のためのドメイン名です。2017年にそれまでのドメイン名である ``pypi.python.org`` を置き換えました。 " -":ref:`warehouse`を使っています。" - -#: ../source/glossary.rst:152 -msgid "pyproject.toml" -msgstr "pyproject.toml" - -#: ../source/glossary.rst:155 -msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." -msgstr "ツール不可知論者の :term:`プロジェクト ` 仕様を示すファイル。 :pep:`518` で定義。" - -#: ../source/glossary.rst:157 -msgid "Release" -msgstr "リリース" - -#: ../source/glossary.rst:160 -msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." -msgstr "ある特定の時点における :term:`プロジェクト `のスナップショットで、バージョン識別子付きのもの。" - -#: ../source/glossary.rst:163 -msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." -msgstr "" -"リリースを作成することは、複数の :term:`配布物 ` " -"を公開することを伴います。例えば、あるプロジェクトのバージョン1." -"0がリリースされたならば、ソースコード配布物とWindowsインストーラ付配布物の両方が利用可能となっているという具合です。" - -#: ../source/glossary.rst:168 -msgid "Requirement" -msgstr "要求事項" - -#: ../source/glossary.rst:171 -msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." -msgstr "" -"インストールされる :term:`パッケージ ` の仕様。 :term:`PYPA ` が推奨するインストーラである :ref:`pip` " -"では、「要求事項」とも解釈できる仕様を様々な様式で書くことを許容しています。詳細については、 :ref:`pip:pip install` " -"の項を参照してください。" - -#: ../source/glossary.rst:177 -msgid "Requirement Specifier" -msgstr "要求事項指示子" - -#: ../source/glossary.rst:180 -msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" -msgstr "" -":term:`パッケージインデックス `からパッケージをインストールするために :ref:`pip` で用いられる様式。" -"この様式の EBNF 文法構造については :ref:`setuptools` のドキュメントにある <`" -"pkg_resources.Requirement `_ の項をご覧ください。例えば、\"foo>=1." -"3\"は要求事項識別子であり、\"foo\"の部分がプロジェクトの名称、\">=1.3\"の部分が :term:`バージョン識別子 ` に該当します。" - -#: ../source/glossary.rst:187 -msgid "Requirements File" -msgstr "Requirementsファイル" - -#: ../source/glossary.rst:190 -msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." -msgstr "" -":ref:`pip`を用いてインストールできるように :term:`要求事項 ` を記したファイル。詳しい情報は、 " -":ref:`pip` のドキュメントの :ref:`pip:Requirementsファイル ` " -"をみてください。" - -#: ../source/glossary.rst:194 -#: ../source/guides/distributing-packages-using-setuptools.rst:56 -msgid "setup.py" -msgstr "setup.py" - -#: ../source/glossary.rst:195 -#: ../source/guides/distributing-packages-using-setuptools.rst:77 -msgid "setup.cfg" -msgstr "setup.cfg" - -#: ../source/glossary.rst:198 -msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." -msgstr "" -":ref:`distutils`や :ref:`setuptools` で使われるプロジェクトの仕様を記したファイル。 :term:`pyproject." -"toml`も見てください。" - -#: ../source/glossary.rst:201 -msgid "Source Archive" -msgstr "ソースコードアーカイブ" - -#: ../source/glossary.rst:204 -msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." -msgstr "" -":term:`ソースコード配布物 ` や :term:`ビルド配布物 " -"` という用語を作る前には、:term:`リリース " -"`向けに生のソースコードを収めたアーカイブのことをこう呼んでいた。" - -#: ../source/glossary.rst:208 -msgid "Source Distribution (or \"sdist\")" -msgstr "`ソースコード配布物 (またはsdist) `" - -#: ../source/glossary.rst:211 -msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." -msgstr "" -":ref:`pip`のようなツールでインストールするか :term:`ビルド配布物 ` " -"を生成するのに必要なメタデータと必須ソースコードを提供する :term:`配布物 ` フォーマット。" - -#: ../source/glossary.rst:216 -msgid "System Package" -msgstr "システムパッケージ" - -#: ../source/glossary.rst:219 -msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." -msgstr "rpmやdpkgのように、オペレーティングシステムに固有のフォーマットで提供されるパッケージ。" - -#: ../source/glossary.rst:222 -msgid "Version Specifier" -msgstr "バージョン識別子" - -#: ../source/glossary.rst:225 -msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." -msgstr "" -":term:`要求事項指定子 ` のバージョン部分。例えば、\"foo>=1.3\"の中の\">=1." -"3\"の部分。:pep:`440`には、Pythonパッケージングが現在サポートしている指定子の :pep:`完全な仕様 <440#version-" -"specifiers>` が含まれています。 :ref:`setuptools` v8.0や :ref:`pip` v6." -"0はPEP440への対応を実装しています。" - -#: ../source/glossary.rst:231 -msgid "Virtual Environment" -msgstr "仮想環境" - -#: ../source/glossary.rst:234 -msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" -"システム全体からではなく、ある特定のアプリケーションだけから使えるようにパッケージをインストールすることができる、隔離されたPython環境。詳細は " -":ref:`仮想環境の生成と使用 ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." -msgstr "" -"一連のインポート可能な :term:`配布物 `。これらは `sys.path` " -"変数から検索できる配布物です。あるプロジェクトには、高々(訳註、at mostではなくat least、すくなくとも、か。)ひとつの :term:`" -"配布物 ` が動作可能セットにあります。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:3 -msgid "Analyzing PyPI package downloads" -msgstr "PyPIパッケージのダウンロード状況の解析" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:5 -msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." -msgstr "" -"この節では、公開のPyPIダウンロードデータセットを用いて、PyPIにホストされているパッケージ(あるいはパッケージ群)のダウンロード状況を詳しく見ていく" -"ことを記述しています。例えば、ダウンロードに使われたPythonのバージョンの分布を発見することができます。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:15 -#: ../source/guides/supporting-windows-using-appveyor.rst:18 -msgid "Background" -msgstr "背景" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:17 -msgid "PyPI does not display download statistics for a number of reasons: [#]_" -msgstr "PyPIはいくつもの理由からダウンロード統計を表示しません。:[#]_" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:19 -msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." -msgstr "" -"**コンテンツデリバリネットワーク(CDN)と一緒に動かす時の効率の悪さ** ダウンロード用系は常に変動します。プロジェクトのページでのダウンロードは強烈" -"にキャッシュされていますが、(訳註、統計を正しく取ろうとするなら)より頻繁にキャッシュし直さなければならず、これはキャッシュの効率性を損ねます。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:24 -msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" -msgstr "**非常に不正確** 次に挙げるものを含め、いくつもの要因でダウンロード数が正確とは言えないものになります：" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:27 -msgid "``pip``'s download cache (lowers download counts)" -msgstr "``pip``のダウンロードキャッシュ (ダウンロード数を小さくする)" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:28 -msgid "Internal or unofficial mirrors (can both raise or lower download counts)" -msgstr "内部の、または、非公式のミラーサイト (ダウンロード数を大きくする要因にも小さくする要因にもなる)" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:29 -msgid "Packages not hosted on PyPI (for comparisons sake)" -msgstr "PyPIにホストされていないパッケージ (比較することの妥当性を損ねる)" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:30 -msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" -msgstr "ダウンロード数を増やす非公式のスクリプトまたは試行 (ダウンロード数を大きくする)" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:32 -msgid "Known historical data quality issues (lowers download counts)" -msgstr "過去のデータ品質における既知の問題 (ダウンロード数を小さくする)" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:34 -msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" -msgstr "" -"**とりわけ利用価値があるというわけではない** プロジェクト(の配布物、訳註。)がたくさんダウンロードされたからといってそれだけで良いことだと決まったわ" -"けではありませんし、あまりダウンロードされなかったとしてもそれだけで悪いことだと決めつけることもできません！" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:38 -msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." -msgstr "" -"まとめると、様々な理由からそれ(訳註、ダウンロード統計)の価値が低い上、動作させるために犠牲になるものが多いので、限られた資源の効率的な利用にはならないの" -"です。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:43 -msgid "Public dataset" -msgstr "公開データセット" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:45 -msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." -msgstr "" -"別の方法としては、 `Linehaulプロジェクト `__ " -"がダウンロードのログをPyPIから `Google BigQuery`_ [#]_ へ連続的に取り出して、公開のデータセットとして保管しています。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:50 -msgid "Getting set up" -msgstr "セットアップのやり方" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:52 -msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" -msgstr "" -"`Google BigQuery`_ を使って `PyPIダウンロード統計の公開データセット `_ にクエリを行うためには、まずGoogleアカウントが必要で、Google Cloud Platform " -"(GCP)でBigQuery APIを有効にしておく必要があります。`クレジットカード登録なしのBigQuery 無料枠 `__ を使うと一ヶ月当たり1TBまでのクエリを走らせることができます。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:58 -msgid "Navigate to the `BigQuery web UI`_." -msgstr "`BigQuery web UI`_ の使い方。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:59 -msgid "Create a new project." -msgstr "新しいプロジェクトを作成する。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:60 -msgid "Enable the `BigQuery API `__." -msgstr "" -"`BigQuery API `__ を有効にする。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:63 -msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." -msgstr "" -"BigQueryの始め方についてさらに詳しい指南が欲しい場合は、`Cloud Console を使用したクイックスタート `__ を参照してください。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:69 -msgid "Data schema" -msgstr "データ構造" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:71 -msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" -msgstr "" -"それぞれのダウンロードの情報を格納した ``bigquery-public-data.pypi.file_downloads``テーブルについての説明をL" -"inehaulが書きました。このテーブルは、どのファイルがどのようにダウンロードされたかに関する情報を格納しています。`テーブル構造 " -"`__ から役に立つカラムをいくつか挙げると：" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -msgid "Column" -msgstr "カラム" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/guides/using-manifest-in.rst:67 -#: ../source/specifications/core-metadata.rst:185 -msgid "Description" -msgstr "説明" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/specifications/direct-url.rst:226 -msgid "Examples" -msgstr "例" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "timestamp" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "Date and time" -msgstr "日付と時刻" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "``2020-03-09 00:33:03 UTC``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "file.project" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "Project name" -msgstr "プロジェクト名" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "``pipenv``, ``nose``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "file.version" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "Package version" -msgstr "パッケージのバージョン" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "``0.1.6``, ``1.4.2``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "details.installer.name" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "Installer" -msgstr "インストーラ" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "pip, `bandersnatch`_" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "details.python" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "Python version" -msgstr "Pythonのバージョン" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "``2.7.12``, ``3.6.4``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:93 -msgid "Useful queries" -msgstr "役に立つクエリ" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:95 -msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." -msgstr "「クエリを新規作成」ボタンをクリックすることで `BigQuery web UI`_ 内でクエリを走らせましょう。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:97 -msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." -msgstr "" -"クエリのコストを削減するためにデータベースの行がパーティションされた状態で格納されていることを覚えておいてください。これらの例では、``timestamp" -"`` カラムを使って絞り込むことで最近のダウンロード履歴を分析しています。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:102 -msgid "Counting package downloads" -msgstr "パッケージのダウンロードを数える" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:104 -msgid "The following query counts the total number of downloads for the project \"pytest\"." -msgstr "次のクエリは\"pytest\"プロジェクトのダウンロード総数を数えています。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:119 -#: ../source/guides/analyzing-pypi-package-downloads.rst:140 -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "num_downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:121 -msgid "26190085" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:124 -msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." -msgstr "pipを通じてダウンロードされた数だけを数えるには、``details.installer.name``カラムを使って抽出します。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:142 -msgid "24334215" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:146 -msgid "Package downloads over time" -msgstr "時系列のパッケージダウンロード数" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:148 -msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." -msgstr "" -"月毎のダウンロード数を数えるには、``TIMESTAMP_TRUNC``関数を使います。このカラムを使って抽出することは、通信量を抑えることにもなります。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -msgid "month" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "1956741" -msgstr "1956741" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "2018-01-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2344692" -msgstr "2344692" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2017-12-01" -msgstr "2017-12-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "1730398" -msgstr "1730398" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "2017-11-01" -msgstr "2017-11-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2047310" -msgstr "2047310" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2017-10-01" -msgstr "2017-10-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "1744443" -msgstr "1744443" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "2017-09-01" -msgstr "2017-09-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "1916952" -msgstr "1916952" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "2017-08-01" -msgstr "2017-08-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:184 -msgid "Python versions over time" -msgstr "時系列で見たPythonバージョン" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:186 -msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." -msgstr "``details.python``カラムからPythonのバージョンを取り出します。警告：このクエリは500GB以上のデータを処理します。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "python" -msgstr "python" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "3.7" -msgstr "3.7" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "18051328726" -msgstr "18051328726" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "3.6" -msgstr "3.6" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "9635067203" -msgstr "9635067203" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "3.8" -msgstr "3.8" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "7781904681" -msgstr "7781904681" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "2.7" -msgstr "2.7" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "6381252241" -msgstr "6381252241" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "null" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "2026630299" -msgstr "2026630299" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "3.5" -msgstr "3.5" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "1894153540" -msgstr "1894153540" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:221 -msgid "Caveats" -msgstr "注意書き" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:223 -msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." -msgstr "" -"上記の背景に列挙した注意書きに加えて、Linehaulは、極端に過小報告されていたダウンロード統計の原因となったバグに2018年7月26日まで悩まされてい" -"ました。この日より前のダウンロード数については、比率の点(例えばPython2とPython3の百分率)では正確ですが、絶対数の点では桁が異なるほどに過小" -"です。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:231 -msgid "Additional tools" -msgstr "その他のツール" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:233 -msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." -msgstr "BigQueryコンソールを用いる他に、ダウンロード統計を分析する際に役に立つと思われるツールがいくつかあります。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:237 -msgid "``google-cloud-bigquery``" -msgstr "``google-cloud-bigquery``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:239 -msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." -msgstr "" -"BigQuery APIとBigQuery用の公式Pythonクライアントである `google-cloud-bigquery`_ " -"プロジェクトを使って、プログラムからPyPIの公開ダウンロード統計データセットにアクセスすることもできます。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:267 -msgid "``pypinfo``" -msgstr "``pypinfo``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:269 -msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." -msgstr "" -"`pypinfo`_ はデータセットにアクセスして、役に立つクエリをいくつか生成する機能を提供するコマンドラインツールです。例えば、``pypinfo " -"package_name``を実行すれば、そのパッケージのダウンロード総数を問い合わせることができます。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:273 -msgid "Install `pypinfo`_ using pip." -msgstr "pipを用いて `pypinfo`_ をインストール。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:279 -msgid "Usage:" -msgstr "使い方：" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:295 -msgid "``pandas-gbq``" -msgstr "``pandas-gbq``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:297 -msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." -msgstr "`pandas-bbq`_ プロジェクトを使えば `Pandas`_ 経由でクエリ結果を参照することができます。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:301 -#: ../source/specifications/binary-distribution-format.rst:459 -msgid "References" -msgstr "参考文献" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:303 -msgid "`PyPI Download Counts deprecation email `__" -msgstr "" -"`PyPI ダウンロード統計を非推奨とするメール (PyPI Download Counts deprecation email) " -"`__" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:304 -msgid "`PyPI BigQuery dataset announcement email `__" -msgstr "" -"`PyPI BigQueryデータセットをアナウンスするメール (PyPI BigQuery dataset announcement email) " -"`__" - -#: ../source/guides/creating-and-discovering-plugins.rst:3 -msgid "Creating and discovering plugins" -msgstr "プラグイン作成と発見" - -#: ../source/guides/creating-and-discovering-plugins.rst:5 -msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." -msgstr "" -"Pythonのアプリケーションまたはライブラリを作成する時には、カスタマイズができるようにしたり **プラグイン** " -"を通じて機能を追加できるようにしたりすることがしばしばあります。Pythonのパッケージは別々に配布できますので、" -"あなたのアプリケーションまたはライブラリが利用可能なすべてのプラグインを自動的に **探し出す** ようにしたくなるかもしれません。" - -#: ../source/guides/creating-and-discovering-plugins.rst:10 -msgid "There are three major approaches to doing automatic plugin discovery:" -msgstr "プラグインの自動検出には大きく分けて３個の実現方法があります。" - -#: ../source/guides/creating-and-discovering-plugins.rst:12 -msgid "`Using naming convention`_." -msgstr "`命名規則を用いるやり方 `_ 。" - -#: ../source/guides/creating-and-discovering-plugins.rst:13 -msgid "`Using namespace packages`_." -msgstr "`namespaceパッケージを用いるやり方 `_ 。" - -#: ../source/guides/creating-and-discovering-plugins.rst:14 -msgid "`Using package metadata`_." -msgstr "`パッケージのメタデータを用いるやり方 `_ 。" - -#: ../source/guides/creating-and-discovering-plugins.rst:18 -msgid "Using naming convention" -msgstr "命名規則を用いるやり方" - -#: ../source/guides/creating-and-discovering-plugins.rst:20 -msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" -msgstr "" -"あなたのアプリケーション用のすべてのプラグインが命名規則に従うのであれば、 :func:`pkgutil.iter_modules` " -"を用いて命名規則に合致するトップレベルのすべてのモジュールを発見することができます。例えば、 `Flask`_ は命名規則として " -"``flask_{plugin_name}`` を使います。もし、すべてのインストール済みFlask用プラグインを発見したいのであれば：" - -#: ../source/guides/creating-and-discovering-plugins.rst:38 -msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" -msgstr "" -"もしあなたが `Flask-SQLAlchemy`_ と `Flask-Talisman`_ のふたつのプラグインをインストールしてあるなら、 " -"``discovered_plugins`` は次のようになるでしょう：" - -#: ../source/guides/creating-and-discovering-plugins.rst:48 -msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." -msgstr "" -"プラグインの命名規則を用いることで、あなたの命名規則に従うすべてのパッケージについてPython パッケージインデックスの `simple API`_ " -"から検索することもできるようになります。" - -#: ../source/guides/creating-and-discovering-plugins.rst:59 -msgid "Using namespace packages" -msgstr "namespaceパッケージを用いるやり方" - -#: ../source/guides/creating-and-discovering-plugins.rst:61 -msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" -msgstr "" -":doc:`Namespace パッケージ ` " -"を使えば、プラグインをどこに配置するかに関する規則や、発見するための方法も提供できます。例えば、あなたが名前空間を決めるサブパッケージ ``myapp." -"plugins`` を作成したら、その名前空間に他の :term:`配布物 ` " -"がモジュールやパッケージを配置することができます。インストールが終われば、あなたは :func:`pkgutil.iter_modules` " -"を用いてインストール済みの全てのモジュールやパッケージをその名前空間で発見できるでしょう。" - -#: ../source/guides/creating-and-discovering-plugins.rst:89 -msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" -msgstr "" -":func:`~pkgutil.iter_modules` に ``myapp.plugins.__path__`` " -"を指定すると、その名前空間の直下にあるモジュールだけを探索するようになります。例えば、あなたがモジュールの ``myapp.plugins.a`` と " -"``myapp.plugins.b`` を提供する配布物をインストールしているとしたら、 ``discovered_plugins`` " -"は次のようになるでしょう：" - -#: ../source/guides/creating-and-discovering-plugins.rst:101 -msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." -msgstr "" -"この例ではサブパッケージを名前空間を決めるパッケージ(``myapp.plugins``)として使っていますが、トップレベルのパッケージをこの(``mya" -"pp_plugins``のような)目的に用いることも可能です。名前空間をどのようにして決めるかは好みの問題ですが、あなたのプロジェクトのトップレベルのパッ" -"ケージ(この場合では``myapp``)をプラグインの名前空間を決めるために用いると、全体の名前空間を破壊するようなプラグインがひとつあるだけで、あなたの" -"プロジェクトをインポートすることができなくなるのでお勧めしません。「名前空間を決めるサブパッケージ」の手法がうまく動作するためには、プラグインパッケージ側" -"のトップレベルパッケージのディレクトリ(この場合には``myapp``)に :file:`__init__.py` " -"が存在してはいけませんし、名前空間を決めるサブパッケージのディレクトリ(``myapp/plugins``)にある :file:`__init__." -"py`をプラグインパッケージ側でインクルードしなければなりません。これはまた、 プラグインの側で:func:`setuptools." -"find_packages` を使うのではなく、パッケージの名前を :func:`setup`の ``packages`` " -"引数に明示的に渡す必要がある、ということを意味しています。" - -#: ../source/guides/creating-and-discovering-plugins.rst:115 -msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." -msgstr "" -"名前空間を決めるパッケージは込み入った機能で、いくつかの異なる作成方法があります。 :doc:`packaging-namespace-packages`" -" 文書を読むとともに、あなたのプロジェクト用のプラグインとしてはどちらの手法が好ましいのかを明白に文書化しておくことを強くお勧めします。" - -#: ../source/guides/creating-and-discovering-plugins.rst:121 -msgid "Using package metadata" -msgstr "パッケージのメタデータを用いるやり方" - -#: ../source/guides/creating-and-discovering-plugins.rst:123 -msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." -msgstr "" -"`Setuptools`_ はプラグイン向けに :doc:`特別なサポート ` " -"を提供しています。 :file:`setup.py` の中の :func:`setup`の ``entry_points`` " -"引数を準備することで、プラグインが検出されるように登録することができます。" - -#: ../source/guides/creating-and-discovering-plugins.rst:128 -msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" -msgstr "" -"例えば、``myapp-plugin-a`` という名前のパッケージが存在して、その :file:`setup.py` をインクルードする場合：" - -#: ../source/guides/creating-and-discovering-plugins.rst:139 -msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" -msgstr "" -"そして、 :func:`import lib.metadata.entry_points` (あるいはPython 3.6-3.9用の " -"`backport`_ ``import lib_metadata>=3.6``)を使うことで、登録されたエントリポイントを全て検出することができます。" - -#: ../source/guides/creating-and-discovering-plugins.rst:154 -msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" -msgstr "" -"この例では、 ``discovered_plugins`` は :class:`import lib.metadata.EntryPoint` " -"型の(オブジェクトの)集合となるでしょう。" - -#: ../source/guides/creating-and-discovering-plugins.rst:163 -msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." -msgstr "" -"今や、``discovered_plugins['a'].load()`` を実行することで、あなたが選んだモジュールをインポートすることができます。" - -#: ../source/guides/creating-and-discovering-plugins.rst:166 -msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." -msgstr "" -":file:`setup.py` における ``entry_points`` の指定はかなり自由度が高く、オプションがたくさんあります。 :doc:`" -"entry_point ` の全部のセクションに目を通すことをお勧めします。" - -#: ../source/guides/creating-and-discovering-plugins.rst:170 -msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." -msgstr "" -"この仕様は :doc:`標準ライブラリ ` " -"の一部なので、setuptools以外のほとんどのパッケージングツールでもエントリポイントを定義できる機能を提供しています。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:5 -msgid "Packaging and distributing projects" -msgstr "パッケージングとプロジェクトの配布" - -#: ../source/guides/distributing-packages-using-setuptools.rst:7 -msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." -msgstr "" -"この節では、あなた自身のPythonパッケージを設定し、パッケージにまとめ、そして配布する方法の基本について説明します。あなたが既に :doc:`/" -"tutorials/installing-packages` " -"ページの内容については慣れ親しんでいるものと仮定して進めます(訳者による蛇足、まだの方は読んできてね)。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:11 -msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." -msgstr "" -"この節は、Pythonプロジェクトの開発についての全体的なベストプラクティスを説明しているわけではありません。例えば、バージョン管理や文書化、あるいは試験" -"について、手引きとなったりツールを推奨するようなことはありません。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:15 -msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." -msgstr "" -"より詳しい参考文献としては、:ref:`setuptools` の説明文書の中の :std:doc:`パッケージのビルドと配布 ` を挙げておきますが、推奨事項のいくつかはもはや古くなっているかもしれません。喰い違いがあった場合には、Python " -"パッケージングユーザガイドの推奨事項を優先してください。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:25 -msgid "Requirements for packaging and distributing" -msgstr "パッケージングと配布に対する要求事項" - -#: ../source/guides/distributing-packages-using-setuptools.rst:26 -msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." -msgstr "" -"最初に、あなたが既に :ref:`パッケージをインストールする際の要求事項 ` " -"を満たしていることを確実にしてください。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:29 -msgid "Install \"twine\" [1]_:" -msgstr "\"twine\"をインストールする [1]_:" - -#: ../source/guides/distributing-packages-using-setuptools.rst:43 -msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." -msgstr "" -"あなたのプロジェクトの :term:`配布物 ` を :term:`PyPI ` にアップロードする( :ref:`後述 ` " -")ためにこれが必要になるでしょう。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:49 -msgid "Configuring your project" -msgstr "あなたのプロジェクトを設定する" - -#: ../source/guides/distributing-packages-using-setuptools.rst:53 -msgid "Initial files" -msgstr "最初に必要なファイル群" - -#: ../source/guides/distributing-packages-using-setuptools.rst:58 -msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." -msgstr "" -"最重要のファイルは、あなたのプロジェクトのディレクトリの一番上(ルート)にある :file:`setup.py` です。`PyPA サンプルプロジェクト " -"`_ の `setup.py `_ に具体例があります。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:63 -msgid ":file:`setup.py` serves two primary functions:" -msgstr ":file:`setup.py` はふたつの主要な機能を提供します。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:65 -msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." -msgstr "" -"まず、あなたのプロジェクトをさまざまな角度から設定するためのファイルです。 :file:`setup.py` の主要な機能は、グローバルな " -"``setup()`` 関数を含んでいることです。この関数にキーワード引数を渡すことで、あなたのプロジェクトの特定の細部を定義することができます。" -"適切な引数のほとんどについて :ref:`次節 ` で説明します。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:71 -msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." -msgstr "" -"それは、パッケージングする上での作業項目に関連したさまざまなコマンドを走らせるためのコマンドラインインタフェイスです。使用可能なコマンドを一覧するには、 " -"``python setup.py --help-commands`` を実行してください。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:79 -msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." -msgstr "" -":file:`setup.cfg` は :file:`setup.py` のコマンド群に対するオプションの既定値を含みます。 `PyPA " -"サンプルプロジェクト `_ の中の `setup.cfg " -"`_ に使用例が出ています。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:86 -msgid "README.rst / README.md" -msgstr "README.rstとREADME.md" - -#: ../source/guides/distributing-packages-using-setuptools.rst:88 -msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." -msgstr "" -"すべてのプロジェクトは、プロジェクトのゴールを記したreadmeファイルを備えるべきです。一番良くあるフォーマットは拡張子が \"rst\" の `" -"reStructuredText `_ " -"ですが、これは(訳註、必須の)要求事項というわけではありません。他にも複数の種類の `マークダウン `_ フォーマットがサポートされています(``setup()`` の :ref:`" -"long_description_content_type ` 引数を見てください)。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:95 -msgid "For an example, see `README.md `_ from the `PyPA sample project `_." -msgstr "" -"`PyPA sample project `_ の中の `" -"README.md `_ " -"に例が出ています。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:99 -msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." -msgstr "" -":ref:`setuptools`の0.6." -"27およびそれ以降のバージョンを使っているプロジェクトでは、標準のreadmeファイル(:file:`README.rst`、 :file:`README" -".txt`、または :file:`README`)がデフォルトでソースコード配布物に含まれるようになっています。標準ライブラリの " -":ref:`distutils` では、Python 3.7からこの動作を採用しました。さらに、:ref:`setuptools` の36.4." -"0およびそれ以降のバージョンでは、もし見つかれば :file:`README.md` " -"を含めるようになっています。もしあなたがsetuptoolsを使っているのであれば、あなたはreadmeファイルを :file:`MANIFEST.in`" -" に明記する必要はありません。そうでないなら、明示的に書いてください。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:108 -msgid "MANIFEST.in" -msgstr "MANIFEST.in" - -#: ../source/guides/distributing-packages-using-setuptools.rst:110 -msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." -msgstr "" -"自動的に追加されるファイル以外のファイルをソースコード配布物に追加したい場合には、 :file:`MANIFEST.in` が必要になります。 " -"どんなファイルがデフォルトで自動的に追加されるのかも含めて、 :file:`MANIFEST.in` の書き方の詳細については「 :ref:`" -"MANIFEST.in の使い方 `」を見てください。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:115 -msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." -msgstr "" -"`PyPA sample project `_ の `" -"MANIFEST.in `" -"_ に例がでています。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:119 -msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." -msgstr ":file:`MANIFEST.in` は、wheelなどのバイナリ配布物には影響を与えません。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:122 -msgid "LICENSE.txt" -msgstr "LICENSE.txt" - -#: ../source/guides/distributing-packages-using-setuptools.rst:124 -msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:130 -msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:135 -msgid "" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:137 -msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:141 -msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:149 -msgid "setup() args" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:151 -msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:155 -msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:164 -msgid "name" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:170 -msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:174 -msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:176 -msgid "Start & end with an ASCII letter or digit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:178 -msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:190 -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "version" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:196 -msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:200 -msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:203 -msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:206 -msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:214 -msgid "description" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:222 -msgid "Give a short and long description for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:224 -msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:229 -msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:235 -msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:245 -msgid "url" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:252 -msgid "Give a homepage URL for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:256 -msgid "author" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:263 -msgid "Provide details about the author." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:267 -msgid "license" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:273 -msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:279 -msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:287 -msgid "classifiers" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:316 -msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:319 -msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:327 -msgid "keywords" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:333 -msgid "List keywords that describe your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:337 -msgid "project_urls" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:349 -msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:355 -msgid "packages" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:361 -msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:370 -msgid "py_modules" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:376 -msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:388 -msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:392 -msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:398 -msgid "python_requires" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:400 -msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:407 -msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:412 -msgid "And so on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:416 -msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:422 -msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:431 -msgid "package_data" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:440 -msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:445 -msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:449 -msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:457 -msgid "data_files" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:463 -msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:469 -msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:479 -msgid "For more information see the distutils section on `Installing Additional Files `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:484 -msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:491 -msgid "scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:493 -msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:500 -msgid "entry_points" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:509 -msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:512 -msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:516 -msgid "The most commonly used entry point is \"console_scripts\" (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:521 -msgid "console_scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:531 -msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:538 -msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:545 -msgid "Choosing a versioning scheme" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:548 -msgid "Standards compliance for interoperability" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:550 -msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:556 -msgid "Here are some examples of compliant version numbers::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:567 -msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:573 -msgid "Scheme choices" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:576 -msgid "Semantic versioning (preferred)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:578 -msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:582 -msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:585 -msgid "MAJOR version when they make incompatible API changes," -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:586 -msgid "MINOR version when they add functionality in a backwards-compatible manner, and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:587 -msgid "MAINTENANCE version when they make backwards-compatible bug fixes." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:589 -msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:594 -msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:598 -msgid "Date based versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:600 -msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:604 -msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:607 -msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:611 -msgid "Serial versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:613 -msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:616 -msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:621 -msgid "Hybrid schemes" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:623 -msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:629 -msgid "Pre-release versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:631 -msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:634 -msgid "zero or more dev releases (denoted with a \".devN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:635 -msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:636 -msgid "zero or more beta releases (denoted with a \".bN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:637 -msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:639 -msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:644 -msgid "Local version identifiers" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:646 -msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:653 -msgid "A local version identifier takes the form ``+``. For example::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:661 -msgid "Working in \"development mode\"" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:663 -msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:667 -msgid "Assuming you're in the root of your project directory, then run:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:674 -msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:680 -msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:688 -msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:692 -msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:697 -msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:701 -msgid "Lastly, if you don't want to install any dependencies at all, you can run::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:706 -msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:713 -msgid "Packaging your project" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:715 -msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:720 -msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:737 -msgid "Source distributions" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:739 -msgid "Minimally, you should create a :term:`Source Distribution `:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:755 -msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:763 -msgid "Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:765 -msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:770 -msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:773 -msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:776 -msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:785 -msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:792 -msgid "Pure Python Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:794 -msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:797 -#: ../source/guides/distributing-packages-using-setuptools.rst:826 -msgid "To build the wheel:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:811 -msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:815 -msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:821 -msgid "Platform Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:823 -msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:841 -msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:847 -msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:855 -msgid "Uploading your Project to PyPI" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:857 -msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:861 -msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:866 -msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:871 -msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:877 -msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:888 -msgid "Create an account" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:890 -msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:894 -msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:897 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:901 -msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:904 -msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:913 -msgid "**Be aware that this stores your token in plaintext.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:915 -#: ../source/guides/migrating-to-pypi-org.rst:70 -#: ../source/guides/migrating-to-pypi-org.rst:109 -#: ../source/guides/using-testpypi.rst:83 -msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:921 -msgid "Upload your distributions" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:923 -msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:926 -msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:930 -msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:937 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:944 -#: ../source/tutorials/installing-packages.rst:663 -msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:950 -msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:5 -msgid "Dropping support for older Python versions" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:7 -msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:9 -msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:12 -msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:14 -msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:17 -msgid "Requirements" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:19 -msgid "This workflow requires that:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:21 -msgid "The publisher is using the latest version of :ref:`setuptools`," -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:22 -msgid "The latest version of :ref:`twine` is used to upload the package," -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:23 -msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:26 -msgid "Dealing with the universal wheels" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:28 -msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:36 -msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:48 -msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:53 -msgid "Defining the Python version required" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:56 -msgid "1. Download the newest version of Setuptools" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:58 -msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:60 -msgid "Steps:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:74 -msgid "`setuptools` version should be above 24.0.0." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:77 -msgid "2. Specify the version ranges for supported Python distributions" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:79 -msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:81 -#: ../source/specifications/core-metadata.rst:139 -#: ../source/specifications/core-metadata.rst:463 -#: ../source/specifications/core-metadata.rst:487 -#: ../source/specifications/core-metadata.rst:527 -#: ../source/specifications/core-metadata.rst:550 -#: ../source/specifications/core-metadata.rst:583 -#: ../source/specifications/core-metadata.rst:693 -#: ../source/specifications/core-metadata.rst:722 -msgid "Examples::" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:86 -msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:101 -msgid "3. Validating the Metadata before publishing" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:103 -msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:105 -msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:108 -msgid "You can see the contents of the generated file like this::" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:112 -msgid "Validate that the following is in place, before publishing the package:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:114 -msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:115 -msgid "The Requires-Python field is set and matches your specification in setup.py." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:118 -msgid "4. Using Twine to publish" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:120 -msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:122 -msgid "Make sure you are using the newest version of Twine, at least 1.9." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:125 -msgid "Dropping a Python release" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:127 -msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:129 -msgid "It must be done in this order for the automated fallback to work." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:131 -msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:133 -msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:5 -msgid "Hosting your own simple repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:8 -msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:13 -msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:29 -msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:35 -msgid "\"Manual\" repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:37 -msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:51 -msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:58 -msgid "For complete documentation of the simple repository protocol, see :pep:`503`." -msgstr "" - -#: ../source/guides/index.rst:8 -#: ../source/guides/index.rst:8 -msgid "Installing Packages:" -msgstr "" - -#: ../source/guides/index.rst:20 -#: ../source/guides/index.rst:20 -msgid "Building and Publishing Projects:" -msgstr "" - -#: ../source/guides/index.rst:38 -#: ../source/guides/index.rst:38 -msgid "Miscellaneous:" -msgstr "" - -#: ../source/guides/index.rst:4 -msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:5 -msgid "Package index mirrors and caches" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:8 -#: ../source/guides/supporting-multiple-python-versions.rst:8 -msgid "2014-12-24" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:14 -msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:17 -msgid "Three options are available in this area:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:19 -msgid "pip provides local caching options," -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:20 -msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:22 -msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:27 -msgid "Caching with pip" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:29 -msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:32 -msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:36 -msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:45 -msgid "Caching with devpi" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:47 -msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:55 -msgid "Complete mirror with bandersnatch" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:57 -msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:63 -msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:5 -msgid "Installing scientific packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:11 -msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:16 -msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:22 -msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:29 -msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:35 -msgid "Building from source" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:37 -msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:45 -msgid "Linux distribution packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:47 -msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:51 -msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:57 -msgid "Windows installers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:59 -msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:64 -msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:67 -msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:73 -msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:79 -msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:86 -msgid "macOS installers and package managers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:88 -msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:92 -msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:99 -msgid "SciPy distributions" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:101 -msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:105 -msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:109 -#: ../source/key_projects.rst:596 -msgid "Spack" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:110 -msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:119 -msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:128 -msgid "The conda cross-platform package manager" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:130 -msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:136 -msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 -msgid "Installing stand alone command line tools" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 -msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 -msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 -msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 -msgid "pipx only works with Python 3.6+." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 -msgid "``pipx`` is installed with ``pip``:" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 -msgid "You may need to restart your terminal for the path updates to take effect." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 -msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 -#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 -msgid "For example" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 -msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 -msgid "To upgrade or uninstall the package" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 -msgid "``pipx`` can be upgraded or uninstalled with pip" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 -msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 -msgid "To see the full list of commands ``pipx`` offers, run" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 -msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:5 -msgid "Installing pip/setuptools/wheel with Linux Package Managers" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:8 -msgid "2015-09-17" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:11 -msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:14 -msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:18 -msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:25 -msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:32 -msgid "Fedora" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:34 -msgid "Fedora 21:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:36 -#: ../source/guides/installing-using-linux-tools.rst:45 -#: ../source/guides/installing-using-linux-tools.rst:124 -#: ../source/guides/installing-using-linux-tools.rst:138 -#: ../source/guides/installing-using-linux-tools.rst:158 -msgid "Python 2::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:41 -msgid "Python 3: ``sudo yum install python3 python3-wheel``" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:43 -msgid "Fedora 22:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:50 -msgid "Python 3: ``sudo dnf install python3 python3-wheel``" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:53 -msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:63 -msgid "CentOS/RHEL" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:65 -msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:68 -msgid "To install pip and wheel for the system Python, there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:70 -msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:77 -msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:81 -msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:85 -msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:92 -msgid "To additionally upgrade setuptools, run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:97 -msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:101 -msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:104 -msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:106 -msgid "For CentOS, see here: https://www.softwarecollections.org/en/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:108 -msgid "Be aware that collections may not contain the most recent versions." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:110 -msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:116 -msgid "For example, for Python 3.4 on CentOS7/RHEL7::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:122 -msgid "openSUSE" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:129 -#: ../source/guides/installing-using-linux-tools.rst:143 -#: ../source/guides/installing-using-linux-tools.rst:162 -msgid "Python 3::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:135 -msgid "Debian/Ubuntu" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:150 -msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:156 -msgid "Arch Linux" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:168 -msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 -msgid "Installing packages using pip and virtual environments" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 -msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 -msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 -msgid "Installing pip" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 -msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 -msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 -msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 -msgid "Afterwards, you should have the newest pip installed in your user site:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 -msgid "The Python installers for Windows include pip. You should be able to access pip using:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 -msgid "You can make sure that pip is up-to-date by running:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 -msgid "Installing virtualenv" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 -msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 -msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 -msgid "Creating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 -msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 -msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 -msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 -msgid "venv will create a virtual Python installation in the ``env`` folder." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 -msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 -msgid "Activating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 -msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 -msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 -msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 -msgid "Leaving the virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 -msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 -msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 -msgid "Installing packages" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 -msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 -msgid "pip should download requests and all of its dependencies and install them:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 -msgid "Installing specific versions" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 -msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 -msgid "To install the latest ``2.x`` release of requests:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 -msgid "To install pre-release versions of packages, use the ``--pre`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 -msgid "Installing extras" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 -msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 -msgid "Installing from source" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 -msgid "pip can install a package directly from source, for example:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 -msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 -msgid "Installing from version control systems" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 -msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 -msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 -#: ../source/tutorials/installing-packages.rst:569 -msgid "Installing from local archives" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 -msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 -msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 -msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 -msgid "Using other package indexes" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 -msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 -msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 -#: ../source/tutorials/installing-packages.rst:389 -msgid "Upgrading packages" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 -msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 -msgid "Using requirements files" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 -msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 -msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 -msgid "Freezing dependencies" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 -msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 -msgid "Which will output a list of package specifiers such as:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 -msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:2 -msgid "Making a PyPI-friendly README" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:4 -msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:9 -msgid "Creating a README file" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:11 -msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:13 -msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:16 -msgid "plain text" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:17 -msgid "`reStructuredText `_ (without Sphinx extensions)" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:18 -msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:21 -msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:25 -msgid "Including your README in your package's metadata" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:27 -msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:33 -msgid ":ref:`description-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:34 -msgid ":ref:`description-content-type-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:36 -msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:39 -msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:45 -msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:60 -msgid "The minimum required versions of the respective tools are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:62 -msgid "``setuptools >= 38.6.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:63 -msgid "``wheel >= 0.31.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:64 -msgid "``twine >= 1.11.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:66 -msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:72 -msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:95 -msgid "Validating reStructuredText markup" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:97 -msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:100 -msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:105 -msgid "You can check your README for markup errors before uploading as follows:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:107 -msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:122 -msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:125 -msgid "Run ``twine check`` on the sdist and wheel::" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:129 -msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:4 -msgid "Migrating to PyPI.org" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:6 -msgid ":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``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:12 -msgid "Publishing releases" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:14 -msgid "``pypi.org`` is the default upload platform as of September 2016." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:16 -msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:19 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:22 -msgid "The default upload settings switched to ``pypi.org`` in the following versions:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:24 -msgid "``twine`` 1.8.0" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:25 -msgid "``setuptools`` 27.0.0" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:26 -msgid "Python 2.7.13 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:27 -msgid "Python 3.4.6 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:28 -msgid "Python 3.5.3 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:29 -msgid "Python 3.6.0 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:31 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:48 -msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:51 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:67 -msgid "(``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.)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:73 -msgid "Registering package names & metadata" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:75 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:79 -msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:84 -msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:89 -#: ../source/guides/using-testpypi.rst:5 -msgid "Using TestPyPI" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:91 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:113 -msgid "Registering new user accounts" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:115 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:121 -msgid "Browsing packages" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:123 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:130 -msgid "Downloading packages" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:132 -msgid "``pypi.org`` is the default host for downloading packages." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:135 -msgid "Managing published packages and releases" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:137 -msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:5 -msgid "Multi-version installs" -msgstr "" - -#: ../source/guides/multi-version-installs.rst:8 -msgid "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``)." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:13 -msgid "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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:19 -msgid "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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:31 -msgid "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 ``python -c ''`` to invoke the application's main entry point directly." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:38 -msgid "Refer to the `pkg_resources documentation `__ for more details." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:5 -msgid "Packaging binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:8 -msgid "2013-12-08" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:10 -msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:20 -msgid "An overview of binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:23 -msgid "Use cases" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:25 -msgid "The typical use cases for binary extensions break down into just three conventional categories:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:28 -msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:39 -msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:47 -msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:56 -msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:61 -msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:71 -msgid "Disadvantages" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:73 -msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:80 -msgid "This means that binary extensions:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:82 -msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:85 -msgid "may not be compatible with different builds of the CPython reference interpreter" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:88 -msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:91 -msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:96 -msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:101 -msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:108 -msgid "Alternatives to handcoded accelerator modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:110 -msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:115 -msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:122 -msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:132 -msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:141 -msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:150 -msgid "Alternatives to handcoded wrapper modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:152 -msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:158 -msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:162 -msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:168 -msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:175 -msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:181 -msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:185 -msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:189 -msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:203 -msgid "Alternatives for low level system access" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:205 -msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:213 -msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:222 -msgid "Implementing binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:224 -msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:241 -msgid "Building binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:244 -msgid "Building extensions for multiple platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:246 -msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:256 -msgid "Binary extensions for Windows" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:258 -msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:263 -msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:269 -msgid "To set up a build environment for binary extensions, the steps are as follows:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:271 -msgid "For Python 2.7" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:273 -msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:276 -msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:278 -#: ../source/guides/packaging-binary-extensions.rst:288 -#: ../source/guides/packaging-binary-extensions.rst:295 -msgid "Done." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:280 -msgid "For Python 3.4" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:282 -msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:285 -msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:287 -msgid "Set DISTUTILS_USE_SDK=1" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:290 -msgid "For Python 3.5" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:292 -msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:297 -msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:301 -msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:305 -msgid "Binary extensions for Linux" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:307 -msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:313 -msgid "Binary extensions for macOS" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:315 -msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:325 -msgid "Publishing binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:327 -msgid "For interim guidance on this topic, see the discussion in `this issue `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:343 -msgid "Additional resources" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:345 -msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:352 -msgid "Cross-platform wheel generation with scikit-build" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:354 -msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:362 -msgid "Introduction to C/C++ extension modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:364 -msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:367 -msgid "`What are (c)python extension modules? `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:368 -msgid "`Releasing the gil `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:369 -msgid "`Writing cpython extension modules using C++ `_" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:3 -msgid "Packaging namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:5 -msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:24 -msgid "And you use this package in your code like so::" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:29 -msgid "Then you can break these sub-packages into two separate distributions:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:46 -msgid "Each sub-package can now be separately installed, used, and versioned." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:48 -msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:58 -msgid "Creating a namespace package" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:60 -msgid "There are currently three different approaches to creating namespace packages:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:62 -msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:66 -msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:69 -msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:73 -msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:80 -msgid "Native namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:82 -msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:97 -msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:102 -msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:117 -msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:123 -msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:129 -msgid "pkgutil-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:131 -msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:136 -msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:148 -#: ../source/guides/packaging-namespace-packages.rst:194 -msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:155 -#: ../source/guides/packaging-namespace-packages.rst:201 -msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:160 -msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:171 -msgid "pkg_resources-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:173 -msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:182 -msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:206 -msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:216 -msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:223 -msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:237 -msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 -msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 -msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 -msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 -msgid "Saving credentials on GitHub" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 -msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 -msgid "Let's begin! 🚀" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 -msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 -msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 -msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 -msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 -msgid "Creating a workflow definition" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 -msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 -msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 -msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 -msgid "Defining a workflow job environment" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 -msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 -msgid "Checking out the project and building distributions" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 -msgid "Then, add the following under the ``build-n-publish`` section:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 -msgid "This will download your repository into the CI runner and then install and activate Python 3.7." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 -msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 -msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 -msgid "So add this to the steps list:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 -msgid "Publishing the distribution to PyPI and TestPyPI" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 -msgid "Finally, add the following steps at the end:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 -msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 -msgid "That's all, folks!" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 -msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:5 -msgid "Single-sourcing the package version" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:8 -msgid "There are many techniques to maintain a single source of truth for the version number of your project:" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:11 -msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:38 -msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:47 -msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:52 -msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:55 -msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:58 -msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:65 -msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:76 -msgid "Example using this technique: `warehouse `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:78 -msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:86 -msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:91 -msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:95 -msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:110 -msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:114 -msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:128 -msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:134 -msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:138 -msgid "Example using this technique: `setuptools `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:141 -msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:155 -msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:161 -msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:5 -msgid "Supporting multiple Python versions" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:37 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:43 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:49 -msgid "Automated testing and continuous integration" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:51 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:56 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:60 -msgid "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:" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:66 -msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:69 -msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:80 -msgid "Both `Travis CI`_ 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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:85 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:89 -msgid "Tools for single-source Python packages" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:91 -msgid "`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_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:100 -msgid "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" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:107 -msgid "a Python 2 (by syntax) module in a Python 3 project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:108 -msgid "a Python 3 (by syntax) module in a *Python 2* project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:110 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:117 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:124 -msgid "What's in which Python?" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:126 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:3 -msgid "Supporting Windows using Appveyor" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:6 -msgid "2015-12-03" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:8 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:20 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:24 -msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:30 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:38 -msgid "Setting up" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:40 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:45 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:49 -msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:54 -msgid "Adding Appveyor support to your project" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:56 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:61 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:69 -msgid "appveyor.yml" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:75 -msgid "This file can be downloaded from `here `__." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:77 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:80 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:88 -msgid "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``)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:94 -msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:97 -msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:100 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:109 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:114 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:119 -msgid "Support script" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:121 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:126 -msgid "`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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:133 -msgid "You can simply download the batch file and include it in your project unchanged." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:137 -msgid "Access to the built wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:139 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:147 -msgid "Additional notes" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:150 -msgid "Testing with tox" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:152 -msgid "Many projects use the `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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:156 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:160 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:165 -msgid "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" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:170 -msgid "``DISTUTILS_USE_SDK``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:171 -msgid "``MSSdk``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:172 -msgid "``INCLUDE``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:173 -msgid "``LIB``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:175 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:181 -msgid "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 Travis or 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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:188 -msgid "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``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:192 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:197 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:203 -msgid "Automatically uploading wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:205 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:210 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:216 -msgid "External dependencies" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:218 -msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:221 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:230 -msgid "Support scripts" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:232 -msgid "For reference, the SDK setup support script is listed here:" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:234 -msgid "``appveyor-sample/build.cmd``" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:5 -msgid "Tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:7 -msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:12 -msgid "Application dependency management" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:14 -msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:18 -msgid "When ``pipenv`` does not meet your use case, consider other tools like:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:20 -msgid ":ref:`pip`" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:22 -msgid "`pip-tools `_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:24 -msgid "`Poetry `_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:27 -msgid "Installation tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:29 -msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:34 -msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:37 -msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:40 -msgid ":ref:`buildout`: primarily focused on the web development community" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:42 -msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:47 -msgid "Packaging tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:49 -msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:52 -msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:56 -msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:61 -msgid "Publishing platform migration" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:63 -msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:67 -msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:72 -msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:77 -msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:82 -msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:88 -msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:93 -msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:102 -msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:107 -msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:5 -msgid "Including files in source distributions with ``MANIFEST.in``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:7 -msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:17 -msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:22 -msgid "How files are included in an sdist" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:24 -msgid "The following files are included in a source distribution by default:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:26 -msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:28 -msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:30 -msgid "scripts specified by the ``scripts`` ``setup()`` argument" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:31 -msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:33 -msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:35 -msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:37 -msgid "all files matching the pattern :file:`test/test*.py`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:38 -msgid ":file:`setup.py` (or whatever you called your setup script)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:39 -msgid ":file:`setup.cfg`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:40 -msgid ":file:`README`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:41 -msgid ":file:`README.txt`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:42 -msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:43 -msgid ":file:`README.md` (setuptools 36.4.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:44 -msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:45 -msgid ":file:`MANIFEST.in`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:47 -msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:52 -msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:60 -msgid ":file:`MANIFEST.in` commands" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:62 -msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:67 -msgid "Command" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:69 -msgid ":samp:`include {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:69 -msgid "Add all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid ":samp:`exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid "Remove all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid ":samp:`global-include {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid "Add all files anywhere in the source tree matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid ":samp:`global-exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid "Remove all files anywhere in the source tree matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid ":samp:`graft {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid "Add all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid ":samp:`prune {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid "Remove all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:79 -msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:87 -msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:91 -msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:95 -msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:101 -msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." -msgstr "" - -#: ../source/guides/using-testpypi.rst:7 -msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" -msgstr "" - -#: ../source/guides/using-testpypi.rst:13 -msgid "Registering your account" -msgstr "" - -#: ../source/guides/using-testpypi.rst:15 -msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." -msgstr "" - -#: ../source/guides/using-testpypi.rst:19 -msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." -msgstr "" - -#: ../source/guides/using-testpypi.rst:24 -msgid "Using TestPyPI with Twine" -msgstr "" - -#: ../source/guides/using-testpypi.rst:26 -msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:33 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." -msgstr "" - -#: ../source/guides/using-testpypi.rst:39 -msgid "Using TestPyPI with pip" -msgstr "" - -#: ../source/guides/using-testpypi.rst:41 -msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:56 -msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" -msgstr "" - -#: ../source/guides/using-testpypi.rst:73 -msgid "Setting up TestPyPI in :file:`.pypirc`" -msgstr "" - -#: ../source/guides/using-testpypi.rst:75 -msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" -msgstr "" - -#: ../source/index.rst:3 -#: ../source/key_projects.rst:181 -msgid "Python Packaging User Guide" -msgstr "" - -#: ../source/index.rst:5 -msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." -msgstr "" - -#: ../source/index.rst:5 -msgid "python, packaging, guide, tutorial" -msgstr "" - -#: ../source/index.rst:24 -msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." -msgstr "" - -#: ../source/index.rst:28 -msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" -msgstr "" - -#: ../source/index.rst:36 -msgid "Get started" -msgstr "" - -#: ../source/index.rst:38 -msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" -msgstr "" - -#: ../source/index.rst:41 -msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" -msgstr "" - -#: ../source/index.rst:43 -msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" -msgstr "" - -#: ../source/index.rst:45 -msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" -msgstr "" - -#: ../source/index.rst:47 -msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" -msgstr "" - -#: ../source/index.rst:52 -msgid "Learn more" -msgstr "" - -#: ../source/index.rst:54 -msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" -msgstr "" - -#: ../source/index.rst:56 -msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." -msgstr "" - -#: ../source/index.rst:58 -msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." -msgstr "" - -#: ../source/index.rst:60 -msgid "The :doc:`specifications/index` section for packaging interoperability specifications." -msgstr "" - -#: ../source/index.rst:62 -msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." -msgstr "" - -#: ../source/key_projects.rst:6 -msgid "Project Summaries" -msgstr "" - -#: ../source/key_projects.rst:8 -msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." -msgstr "" - -#: ../source/key_projects.rst:14 -msgid "PyPA Projects" -msgstr "" - -#: ../source/key_projects.rst:19 -msgid "bandersnatch" -msgstr "" - -#: ../source/key_projects.rst:21 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:25 -msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." -msgstr "" - -#: ../source/key_projects.rst:35 -msgid "build" -msgstr "" - -#: ../source/key_projects.rst:37 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:42 -msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." -msgstr "" - -#: ../source/key_projects.rst:49 -msgid "cibuildwheel" -msgstr "" - -#: ../source/key_projects.rst:51 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" -msgstr "" - -#: ../source/key_projects.rst:58 -msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." -msgstr "" - -#: ../source/key_projects.rst:64 -msgid "distlib" -msgstr "" - -#: ../source/key_projects.rst:66 -msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:71 -msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." -msgstr "" - -#: ../source/key_projects.rst:80 -msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." -msgstr "" - -#: ../source/key_projects.rst:90 -msgid "packaging" -msgstr "" - -#: ../source/key_projects.rst:92 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:97 -msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." -msgstr "" - -#: ../source/key_projects.rst:99 -msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." -msgstr "" - -#: ../source/key_projects.rst:107 -msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." -msgstr "" - -#: ../source/key_projects.rst:119 -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "pip" -msgstr "" - -#: ../source/key_projects.rst:121 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:126 -msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." -msgstr "" - -#: ../source/key_projects.rst:129 -msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." -msgstr "" - -#: ../source/key_projects.rst:137 -msgid "Pipenv" -msgstr "" - -#: ../source/key_projects.rst:139 -msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:144 -msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." -msgstr "" - -#: ../source/key_projects.rst:148 -msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." -msgstr "" - -#: ../source/key_projects.rst:159 -msgid "Pipfile" -msgstr "" - -#: ../source/key_projects.rst:161 -msgid "`Source `__" -msgstr "" - -#: ../source/key_projects.rst:163 -msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." -msgstr "" - -#: ../source/key_projects.rst:170 -msgid "pipx" -msgstr "" - -#: ../source/key_projects.rst:172 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:176 -msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." -msgstr "" - -#: ../source/key_projects.rst:183 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:187 -msgid "This guide!" -msgstr "" - -#: ../source/key_projects.rst:192 -msgid "readme_renderer" -msgstr "" - -#: ../source/key_projects.rst:194 -msgid "`GitHub and docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:197 -msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." -msgstr "" - -#: ../source/key_projects.rst:208 -msgid "setuptools" -msgstr "" - -#: ../source/key_projects.rst:210 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:215 -msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." -msgstr "" - -#: ../source/key_projects.rst:220 -msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." -msgstr "" - -#: ../source/key_projects.rst:227 -msgid "trove-classifiers" -msgstr "" - -#: ../source/key_projects.rst:229 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:233 -msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." -msgstr "" - -#: ../source/key_projects.rst:239 -msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." -msgstr "" - -#: ../source/key_projects.rst:253 -msgid "twine" -msgstr "" - -#: ../source/key_projects.rst:255 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:260 -msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." -msgstr "" - -#: ../source/key_projects.rst:270 -#: ../source/overview.rst:415 -msgid "virtualenv" -msgstr "" - -#: ../source/key_projects.rst:272 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:277 -msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/key_projects.rst:290 -msgid "Warehouse" -msgstr "" - -#: ../source/key_projects.rst:292 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:296 -msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." -msgstr "" - -#: ../source/key_projects.rst:304 -msgid "wheel" -msgstr "" - -#: ../source/key_projects.rst:306 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:311 -msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." -msgstr "" - -#: ../source/key_projects.rst:315 -msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." -msgstr "" - -#: ../source/key_projects.rst:324 -msgid "Non-PyPA Projects" -msgstr "" - -#: ../source/key_projects.rst:329 -msgid "bento" -msgstr "" - -#: ../source/key_projects.rst:331 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:336 -msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." -msgstr "" - -#: ../source/key_projects.rst:344 -msgid "buildout" -msgstr "" - -#: ../source/key_projects.rst:346 -msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:351 -msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." -msgstr "" - -#: ../source/key_projects.rst:358 -msgid "conda" -msgstr "" - -#: ../source/key_projects.rst:360 -msgid "`Docs `__" -msgstr "" - -#: ../source/key_projects.rst:362 -msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." -msgstr "" - -#: ../source/key_projects.rst:369 -msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." -msgstr "" - -#: ../source/key_projects.rst:373 -msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." -msgstr "" - -#: ../source/key_projects.rst:386 -msgid "devpi" -msgstr "" - -#: ../source/key_projects.rst:388 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:392 -msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." -msgstr "" - -#: ../source/key_projects.rst:401 -msgid "flit" -msgstr "" - -#: ../source/key_projects.rst:403 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:407 -msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." -msgstr "" - -#: ../source/key_projects.rst:412 -msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." -msgstr "" - -#: ../source/key_projects.rst:422 -msgid "enscons" -msgstr "" - -#: ../source/key_projects.rst:424 -msgid "`Source `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:428 -msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." -msgstr "" - -#: ../source/key_projects.rst:443 -msgid "Hashdist" -msgstr "" - -#: ../source/key_projects.rst:445 -msgid "`Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:448 -msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." -msgstr "" - -#: ../source/key_projects.rst:460 -msgid "hatch" -msgstr "" - -#: ../source/key_projects.rst:462 -msgid "`GitHub and Docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:465 -msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." -msgstr "" - -#: ../source/key_projects.rst:475 -msgid "multibuild" -msgstr "" - -#: ../source/key_projects.rst:477 -msgid "`GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:479 -msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." -msgstr "" - -#: ../source/key_projects.rst:485 -msgid "pex" -msgstr "" - -#: ../source/key_projects.rst:487 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:491 -msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." -msgstr "" - -#: ../source/key_projects.rst:500 -msgid "pip-tools" -msgstr "" - -#: ../source/key_projects.rst:502 -msgid "`GitHub and Docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:505 -msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." -msgstr "" - -#: ../source/key_projects.rst:517 -msgid "piwheels" -msgstr "" - -#: ../source/key_projects.rst:519 -msgid "`Website `__ | `Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:523 -msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." -msgstr "" - -#: ../source/key_projects.rst:532 -msgid "poetry" -msgstr "" - -#: ../source/key_projects.rst:534 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:538 -msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." -msgstr "" - -#: ../source/key_projects.rst:548 -msgid "pypiserver" -msgstr "" - -#: ../source/key_projects.rst:550 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:554 -msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." -msgstr "" - -#: ../source/key_projects.rst:564 -msgid "scikit-build" -msgstr "" - -#: ../source/key_projects.rst:566 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:570 -msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." -msgstr "" - -#: ../source/key_projects.rst:582 -msgid "shiv" -msgstr "" - -#: ../source/key_projects.rst:584 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:588 -msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." -msgstr "" - -#: ../source/key_projects.rst:598 -msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" -msgstr "" - -#: ../source/key_projects.rst:603 -msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." -msgstr "" - -#: ../source/key_projects.rst:611 -msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." -msgstr "" - -#: ../source/key_projects.rst:617 -msgid "zest.releaser" -msgstr "" - -#: ../source/key_projects.rst:619 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:623 -msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." -msgstr "" - -#: ../source/key_projects.rst:630 -msgid "Standard Library Projects" -msgstr "" - -#: ../source/key_projects.rst:635 -msgid "ensurepip" -msgstr "" - -#: ../source/key_projects.rst:637 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:640 -msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." -msgstr "" - -#: ../source/key_projects.rst:649 -msgid "distutils" -msgstr "" - -#: ../source/key_projects.rst:651 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:654 -msgid "The original Python packaging system, added to the standard library in Python 2.0." -msgstr "" - -#: ../source/key_projects.rst:657 -msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." -msgstr "" - -#: ../source/key_projects.rst:670 -msgid "venv" -msgstr "" - -#: ../source/key_projects.rst:672 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:675 -msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/news.rst:2 -msgid "News" -msgstr "" - -#: ../source/news.rst:5 -msgid "September 2019" -msgstr "" - -#: ../source/news.rst:6 -msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" -msgstr "" - -#: ../source/news.rst:9 -msgid "August 2019" -msgstr "" - -#: ../source/news.rst:10 -msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" -msgstr "" - -#: ../source/news.rst:13 -msgid "July 2019" -msgstr "" - -#: ../source/news.rst:14 -msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" -msgstr "" - -#: ../source/news.rst:15 -msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" -msgstr "" - -#: ../source/news.rst:16 -msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" -msgstr "" - -#: ../source/news.rst:17 -msgid "Updated directory layout examples for consistency. (:pr:`611`)" -msgstr "" - -#: ../source/news.rst:18 -msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" -msgstr "" - -#: ../source/news.rst:21 -msgid "June 2019" -msgstr "" - -#: ../source/news.rst:22 -msgid "Fixed some typos. (:pr:`620`)" -msgstr "" - -#: ../source/news.rst:25 -msgid "May 2019" -msgstr "" - -#: ../source/news.rst:26 -msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" -msgstr "" - -#: ../source/news.rst:27 -msgid "Added a MANIFEST.in guide page. (:pr:`609`)" -msgstr "" - -#: ../source/news.rst:30 -msgid "April 2019" -msgstr "" - -#: ../source/news.rst:31 -msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" -msgstr "" - -#: ../source/news.rst:32 -msgid "Reduced emphasis on virtualenv. (:pr:`606`)" -msgstr "" - -#: ../source/news.rst:35 -msgid "March 2019" -msgstr "" - -#: ../source/news.rst:36 -msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" -msgstr "" - -#: ../source/news.rst:37 -msgid "Covered RTD details for contributing. (:pr:`600`)" -msgstr "" - -#: ../source/news.rst:40 -msgid "February 2019" -msgstr "" - -#: ../source/news.rst:41 -msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" -msgstr "" - -#: ../source/news.rst:42 -msgid "Added instructions to install Python CLI applications. (:pr:`594`)" -msgstr "" - -#: ../source/news.rst:45 -msgid "January 2019" -msgstr "" - -#: ../source/news.rst:46 -msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" -msgstr "" - -#: ../source/news.rst:47 -msgid "Updated Sphinx and Nox. (:pr:`591`)" -msgstr "" - -#: ../source/news.rst:48 -msgid "Referenced Twine from Python3. (:pr:`581`)" -msgstr "" - -#: ../source/news.rst:51 -msgid "December 2018" -msgstr "" - -#: ../source/news.rst:52 -msgid "No programmers in the office!" -msgstr "" - -#: ../source/news.rst:55 -msgid "November 2018" -msgstr "" - -#: ../source/news.rst:56 -msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" -msgstr "" - -#: ../source/news.rst:57 -msgid "Changed bumpversion to bump2version. (:pr:`572`)" -msgstr "" - -#: ../source/news.rst:58 -msgid "Added single-sourcing package version example. (:pr:`573`)" -msgstr "" - -#: ../source/news.rst:59 -msgid "Added a guide for creating documentation. (:pr:`568`)" -msgstr "" - -#: ../source/news.rst:62 -msgid "October 2018" -msgstr "" - -#: ../source/news.rst:63 -msgid "Updated Nox package name. (:pr:`566`)" -msgstr "" - -#: ../source/news.rst:64 -msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" -msgstr "" - -#: ../source/news.rst:67 -msgid "September 2018" -msgstr "" - -#: ../source/news.rst:68 -msgid "Added a section on checking RST markup. (:pr:`554`)" -msgstr "" - -#: ../source/news.rst:69 -msgid "Updated user installs page. (:pr:`558`)" -msgstr "" - -#: ../source/news.rst:70 -msgid "Updated Google BigQuery urls. (:pr:`556`)" -msgstr "" - -#: ../source/news.rst:71 -msgid "Replaced tar command with working command. (:pr:`552`)" -msgstr "" - -#: ../source/news.rst:72 -msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" -msgstr "" - -#: ../source/news.rst:75 -msgid "August 2018" -msgstr "" - -#: ../source/news.rst:76 -msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" -msgstr "" - -#: ../source/news.rst:77 -msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" -msgstr "" - -#: ../source/news.rst:78 -msgid "Updated Python version supported by virtualenv. (:pr:`538`)" -msgstr "" - -#: ../source/news.rst:79 -msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" -msgstr "" - -#: ../source/news.rst:82 -msgid "July 2018" -msgstr "" - -#: ../source/news.rst:84 -msgid "Improved binary extension docs. (:pr:`531`)" -msgstr "" - -#: ../source/news.rst:85 -msgid "Added scikit-build to key projects. (:pr:`530`)" -msgstr "" - -#: ../source/news.rst:88 -msgid "June 2018" -msgstr "" - -#: ../source/news.rst:90 -msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" -msgstr "" - -#: ../source/news.rst:91 -msgid "Updated Markdown descriptions explanation. (:pr:`522`)" -msgstr "" - -#: ../source/news.rst:94 -msgid "May 2018" -msgstr "" - -#: ../source/news.rst:96 -msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" -msgstr "" - -#: ../source/news.rst:97 -msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" -msgstr "" - -#: ../source/news.rst:98 -msgid "Simplified packaging tutorial. (:pr:`498`)" -msgstr "" - -#: ../source/news.rst:99 -msgid "Updated Windows users instructions for clarity. (:pr:`493`)" -msgstr "" - -#: ../source/news.rst:100 -msgid "Updated the license section description for completeness. (:pr:`492`)" -msgstr "" - -#: ../source/news.rst:101 -msgid "Added specification-style document to contributing section. (:pr:`489`)" -msgstr "" - -#: ../source/news.rst:102 -msgid "Added documentation types to contributing guide. (:pr:`485`)" -msgstr "" - -#: ../source/news.rst:105 -msgid "April 2018" -msgstr "" - -#: ../source/news.rst:107 -msgid "Added README guide. (:pr:`461`)" -msgstr "" - -#: ../source/news.rst:108 -msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" -msgstr "" - -#: ../source/news.rst:109 -msgid "Added instructions for Warehouse. (:pr:`471`)" -msgstr "" - -#: ../source/news.rst:110 -msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" -msgstr "" - -#: ../source/news.rst:111 -msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" -msgstr "" - -#: ../source/news.rst:112 -msgid "Added a guide for phasing out Python versions. (:pr:`459`)" -msgstr "" - -#: ../source/news.rst:113 -msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" -msgstr "" - -#: ../source/news.rst:116 -msgid "March 2018" -msgstr "" - -#: ../source/news.rst:118 -msgid "Updated \"installing scientific packages\". (:pr:`455`)" -msgstr "" - -#: ../source/news.rst:119 -msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" -msgstr "" - -#: ../source/news.rst:120 -msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" -msgstr "" - -#: ../source/news.rst:121 -msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" -msgstr "" - -#: ../source/news.rst:124 -msgid "February 2018" -msgstr "" - -#: ../source/news.rst:126 -msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" -msgstr "" - -#: ../source/news.rst:127 -msgid "Updated PyPI migration info. (:pr:`439`)" -msgstr "" - -#: ../source/news.rst:128 -msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" -msgstr "" - -#: ../source/news.rst:129 -msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" -msgstr "" - -#: ../source/news.rst:130 -msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" -msgstr "" - -#: ../source/news.rst:133 -msgid "January 2018" -msgstr "" - -#: ../source/news.rst:135 -msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" -msgstr "" - -#: ../source/news.rst:136 -msgid "Updated README.rst explanation. (:pr:`419`)" -msgstr "" - -#: ../source/news.rst:139 -msgid "December 2017" -msgstr "" - -#: ../source/news.rst:141 -msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" -msgstr "" - -#: ../source/news.rst:142 -msgid "Noted which fields can be used with environment markers. (:pr:`416`)" -msgstr "" - -#: ../source/news.rst:143 -msgid "Updated Requires-Python section. (:pr:`414`)" -msgstr "" - -#: ../source/news.rst:144 -msgid "Added news page. (:pr:`404`)" -msgstr "" - -#: ../source/news.rst:147 -msgid "November 2017" -msgstr "" - -#: ../source/news.rst:149 -msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" -msgstr "" - -#: ../source/news.rst:150 -msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" -msgstr "" - -#: ../source/news.rst:152 -msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" -msgstr "" - -#: ../source/news.rst:153 -msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" -msgstr "" - -#: ../source/news.rst:156 -msgid "October 2017" -msgstr "" - -#: ../source/news.rst:158 -msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" -msgstr "" - -#: ../source/news.rst:159 -msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" -msgstr "" - -#: ../source/news.rst:160 -msgid "Split the specifications page into multiple pages. (:pr:`386`)" -msgstr "" - -#: ../source/news.rst:163 -msgid "September 2017" -msgstr "" - -#: ../source/news.rst:165 -msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" -msgstr "" - -#: ../source/news.rst:167 -msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" -msgstr "" - -#: ../source/news.rst:170 -msgid "August 2017" -msgstr "" - -#: ../source/news.rst:172 -msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" -msgstr "" - -#: ../source/news.rst:173 -msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" -msgstr "" - -#: ../source/news.rst:174 -msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" -msgstr "" - -#: ../source/news.rst:177 -msgid "July 2017" -msgstr "" - -#: ../source/news.rst:179 -msgid "Added ``flit`` to the key projects list. (:pr:`358`)" -msgstr "" - -#: ../source/news.rst:180 -msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" -msgstr "" - -#: ../source/news.rst:181 -msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" -msgstr "" - -#: ../source/news.rst:182 -msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" -msgstr "" - -#: ../source/news.rst:183 -msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" -msgstr "" - -#: ../source/news.rst:186 -msgid "June 2017" -msgstr "" - -#: ../source/news.rst:188 -msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" -msgstr "" - -#: ../source/news.rst:189 -msgid "Added documentation for ``python_requires``. (:pr:`338`)" -msgstr "" - -#: ../source/news.rst:190 -msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" -msgstr "" - -#: ../source/news.rst:191 -msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" -msgstr "" - -#: ../source/news.rst:192 -msgid "Added a license section to the distributing guide. (:pr:`331`)" -msgstr "" - -#: ../source/news.rst:193 -msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" -msgstr "" - -#: ../source/news.rst:194 -msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" -msgstr "" - -#: ../source/news.rst:195 -msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" -msgstr "" - -#: ../source/news.rst:196 -msgid "Switched to the PyPA theme. (:pr:`305`)" -msgstr "" - -#: ../source/news.rst:197 -msgid "Re-organized the documentation into the new structure. (:pr:`318`)" -msgstr "" - -#: ../source/news.rst:200 -msgid "May 2017" -msgstr "" - -#: ../source/news.rst:202 -msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" -msgstr "" - -#: ../source/news.rst:203 -msgid "Added contributor and style guide. (:pr:`307`)" -msgstr "" - -#: ../source/news.rst:204 -msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" -msgstr "" - -#: ../source/news.rst:207 -msgid "April 2017" -msgstr "" - -#: ../source/news.rst:209 -msgid "Added travis configuration for testing pull requests. (:pr:`300`)" -msgstr "" - -#: ../source/news.rst:210 -msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" -msgstr "" - -#: ../source/news.rst:211 -msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" -msgstr "" - -#: ../source/news.rst:212 -msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" -msgstr "" - -#: ../source/news.rst:213 -msgid "Added a topic on namespace packages. (:pr:`290`)" -msgstr "" - -#: ../source/news.rst:214 -msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" -msgstr "" - -#: ../source/news.rst:215 -msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" -msgstr "" - -#: ../source/news.rst:216 -msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" -msgstr "" - -#: ../source/news.rst:217 -msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" -msgstr "" - -#: ../source/news.rst:219 -msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" -msgstr "" - -#: ../source/news.rst:223 -msgid "March 2017" -msgstr "" - -#: ../source/news.rst:225 -msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" -msgstr "" - -#: ../source/news.rst:228 -msgid "February 2017" -msgstr "" - -#: ../source/news.rst:230 -msgid "Added :pep:`518`. (:pr:`281`)" -msgstr "" - -#: ../source/overview.rst:3 -msgid "An Overview of Packaging for Python" -msgstr "" - -#: ../source/overview.rst:7 -msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." -msgstr "" - -#: ../source/overview.rst:12 -msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." -msgstr "" - -#: ../source/overview.rst:18 -msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." -msgstr "" - -#: ../source/overview.rst:26 -msgid "Thinking about deployment" -msgstr "" - -#: ../source/overview.rst:28 -msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" -msgstr "" - -#: ../source/overview.rst:32 -msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" -msgstr "" - -#: ../source/overview.rst:35 -msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" -msgstr "" - -#: ../source/overview.rst:37 -msgid "Is your software installed individually, or in large deployment batches?" -msgstr "" - -#: ../source/overview.rst:39 -msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." -msgstr "" - -#: ../source/overview.rst:46 -msgid "Packaging Python libraries and tools" -msgstr "" - -#: ../source/overview.rst:48 -msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." -msgstr "" - -#: ../source/overview.rst:53 -msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." -msgstr "" - -#: ../source/overview.rst:59 -msgid "Python modules" -msgstr "" - -#: ../source/overview.rst:61 -msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." -msgstr "" - -#: ../source/overview.rst:66 -msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." -msgstr "" - -#: ../source/overview.rst:73 -msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." -msgstr "" - -#: ../source/overview.rst:78 -msgid "Python source distributions" -msgstr "" - -#: ../source/overview.rst:80 -msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." -msgstr "" - -#: ../source/overview.rst:84 -msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." -msgstr "" - -#: ../source/overview.rst:90 -msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." -msgstr "" - -#: ../source/overview.rst:95 -msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." -msgstr "" - -#: ../source/overview.rst:100 -msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." -msgstr "" - -#: ../source/overview.rst:107 -msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" -msgstr "" - -#: ../source/overview.rst:114 -msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." -msgstr "" - -#: ../source/overview.rst:119 -msgid "Python binary distributions" -msgstr "" - -#: ../source/overview.rst:121 -msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." -msgstr "" - -#: ../source/overview.rst:125 -msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." -msgstr "" - -#: ../source/overview.rst:132 -msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." -msgstr "" - -#: ../source/overview.rst:140 -msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." -msgstr "" - -#: ../source/overview.rst:148 -msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." -msgstr "" - -#: ../source/overview.rst:155 -msgid "Packaging Python applications" -msgstr "" - -#: ../source/overview.rst:157 -msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." -msgstr "" - -#: ../source/overview.rst:162 -msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." -msgstr "" - -#: ../source/overview.rst:166 -msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." -msgstr "" - -#: ../source/overview.rst:172 -msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." -msgstr "" - -#: ../source/overview.rst:176 -msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." -msgstr "" - -#: ../source/overview.rst:181 -msgid "Depending on a framework" -msgstr "" - -#: ../source/overview.rst:183 -msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." -msgstr "" - -#: ../source/overview.rst:189 -msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." -msgstr "" - -#: ../source/overview.rst:195 -msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." -msgstr "" - -#: ../source/overview.rst:199 -msgid "Service platforms" -msgstr "" - -#: ../source/overview.rst:201 -msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." -msgstr "" - -#: ../source/overview.rst:205 -msgid "`Heroku `_" -msgstr "" - -#: ../source/overview.rst:206 -msgid "`Google App Engine `_" -msgstr "" - -#: ../source/overview.rst:207 -msgid "`PythonAnywhere `_" -msgstr "" - -#: ../source/overview.rst:208 -msgid "`OpenShift `_" -msgstr "" - -#: ../source/overview.rst:209 -msgid "\"Serverless\" frameworks like `Zappa `_" -msgstr "" - -#: ../source/overview.rst:211 -msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." -msgstr "" - -#: ../source/overview.rst:216 -msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." -msgstr "" - -#: ../source/overview.rst:220 -msgid "Web browsers and mobile applications" -msgstr "" - -#: ../source/overview.rst:222 -msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." -msgstr "" - -#: ../source/overview.rst:227 -msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" -msgstr "" - -#: ../source/overview.rst:231 -msgid "`Kivy `_" -msgstr "" - -#: ../source/overview.rst:232 -msgid "`Beeware `_" -msgstr "" - -#: ../source/overview.rst:233 -msgid "`Brython `_" -msgstr "" - -#: ../source/overview.rst:234 -msgid "`Flexx `_" -msgstr "" - -#: ../source/overview.rst:236 -msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." -msgstr "" - -#: ../source/overview.rst:241 -msgid "Depending on a pre-installed Python" -msgstr "" - -#: ../source/overview.rst:243 -msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." -msgstr "" - -#: ../source/overview.rst:249 -msgid "Technologies which support this model:" -msgstr "" - -#: ../source/overview.rst:251 -msgid "`PEX `_ (Python EXecutable)" -msgstr "" - -#: ../source/overview.rst:252 -msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" -msgstr "" - -#: ../source/overview.rst:253 -msgid "`shiv `_ (requires Python 3)" -msgstr "" - -#: ../source/overview.rst:255 -msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." -msgstr "" - -#: ../source/overview.rst:260 -msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." -msgstr "" - -#: ../source/overview.rst:267 -msgid "Depending on a separate software distribution ecosystem" -msgstr "" - -#: ../source/overview.rst:269 -msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." -msgstr "" - -#: ../source/overview.rst:274 -msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." -msgstr "" - -#: ../source/overview.rst:284 -msgid "Instructions on building and publishing for the Anaconda ecosystem:" -msgstr "" - -#: ../source/overview.rst:286 -msgid "`Building libraries and applications with conda `_" -msgstr "" - -#: ../source/overview.rst:287 -msgid "`Transitioning a native Python package to Anaconda `_" -msgstr "" - -#: ../source/overview.rst:289 -msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" -msgstr "" - -#: ../source/overview.rst:293 -msgid "`Enthought Canopy `_" -msgstr "" - -#: ../source/overview.rst:294 -msgid "`ActiveState ActivePython `_" -msgstr "" - -#: ../source/overview.rst:295 -msgid "`WinPython `_" -msgstr "" - -#: ../source/overview.rst:300 -msgid "Bringing your own Python executable" -msgstr "" - -#: ../source/overview.rst:302 -msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." -msgstr "" - -#: ../source/overview.rst:306 -msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." -msgstr "" - -#: ../source/overview.rst:311 -msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." -msgstr "" - -#: ../source/overview.rst:315 -msgid "A selection of Python freezers:" -msgstr "" - -#: ../source/overview.rst:317 -msgid "`pyInstaller `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:318 -msgid "`cx_Freeze `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:319 -msgid "`constructor `_ - For command-line installers" -msgstr "" - -#: ../source/overview.rst:320 -msgid "`py2exe `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:321 -msgid "`py2app `_ - Mac only" -msgstr "" - -#: ../source/overview.rst:322 -msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" -msgstr "" - -#: ../source/overview.rst:323 -msgid "`osnap `_ - Windows and Mac" -msgstr "" - -#: ../source/overview.rst:324 -msgid "`pynsist `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:326 -msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." -msgstr "" - -#: ../source/overview.rst:332 -msgid "Bringing your own userspace" -msgstr "" - -#: ../source/overview.rst:334 -msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." -msgstr "" - -#: ../source/overview.rst:341 -msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." -msgstr "" - -#: ../source/overview.rst:344 -msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" -msgstr "" - -#: ../source/overview.rst:347 -msgid "`AppImage `_" -msgstr "" - -#: ../source/overview.rst:348 -msgid "`Docker `_" -msgstr "" - -#: ../source/overview.rst:349 -msgid "`Flatpak `_" -msgstr "" - -#: ../source/overview.rst:350 -msgid "`Snapcraft `_" -msgstr "" - -#: ../source/overview.rst:353 -msgid "Bringing your own kernel" -msgstr "" - -#: ../source/overview.rst:355 -msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." -msgstr "" - -#: ../source/overview.rst:360 -msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" -msgstr "" - -#: ../source/overview.rst:364 -msgid "`Vagrant `_" -msgstr "" - -#: ../source/overview.rst:365 -msgid "`VHD `_, `AMI `_, and `other formats `_" -msgstr "" - -#: ../source/overview.rst:366 -msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" -msgstr "" - -#: ../source/overview.rst:369 -msgid "Bringing your own hardware" -msgstr "" - -#: ../source/overview.rst:371 -msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." -msgstr "" - -#: ../source/overview.rst:375 -msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." -msgstr "" - -#: ../source/overview.rst:379 -msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." -msgstr "" - -#: ../source/overview.rst:389 -msgid "The simplified gamut of technologies used to package Python applications." -msgstr "" - -#: ../source/overview.rst:392 -msgid "What about..." -msgstr "" - -#: ../source/overview.rst:394 -msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." -msgstr "" - -#: ../source/overview.rst:398 -msgid "Operating system packages" -msgstr "" - -#: ../source/overview.rst:400 -msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." -msgstr "" - -#: ../source/overview.rst:411 -msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." -msgstr "" - -#: ../source/overview.rst:417 -msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." -msgstr "" - -#: ../source/overview.rst:427 -msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." -msgstr "" - -#: ../source/overview.rst:432 -msgid "Security" -msgstr "" - -#: ../source/overview.rst:434 -msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." -msgstr "" - -#: ../source/overview.rst:437 -msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." -msgstr "" - -#: ../source/overview.rst:446 -msgid "Wrap up" -msgstr "" - -#: ../source/overview.rst:448 -msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:6 -msgid "Binary distribution format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:8 -msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:13 -msgid "Abstract" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:15 -msgid "This PEP describes a built-package format for Python called \"wheel\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:17 -msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:27 -msgid "PEP Acceptance" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:29 -msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:34 -msgid "Rationale" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:36 -msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:43 -msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:52 -msgid "Details" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:55 -msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:57 -msgid "Wheel installation notionally consists of two phases:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:59 -msgid "Unpack." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:61 -msgid "Parse ``distribution-1.0.dist-info/WHEEL``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:62 -msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:64 -msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:66 -msgid "Else unpack archive into platlib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:68 -msgid "Spread." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:70 -msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:72 -msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:78 -msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:80 -msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:82 -msgid "Remove empty ``distribution-1.0.data`` directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:83 -msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:87 -msgid "Recommended installer features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:97 -msgid "Rewrite ``#!python``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:90 -msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:96 -msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:102 -msgid "Generate script wrappers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:100 -msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:105 -msgid "Recommended archiver features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:112 -msgid "Place ``.dist-info`` at the end of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:108 -msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:115 -msgid "File Format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:118 -msgid "File name convention" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:120 -msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "distribution" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "Distribution name, e.g. 'django', 'pyramid'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "Distribution version, e.g. 1.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:135 -msgid "build tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:130 -msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "language implementation and version tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "E.g. 'py27', 'py2', 'py3'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "abi tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "E.g. 'cp33m', 'abi3', 'none'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "platform tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "E.g. 'linux_x86_64', 'any'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:146 -msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:151 -msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:156 -msgid "Escaping and Unicode" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:158 -msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:161 -msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:164 -msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:166 -msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:169 -msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:172 -msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:176 -msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:182 -msgid "File contents" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:184 -msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:188 -msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:191 -msgid "``{distribution}-{version}.dist-info/`` contains metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:192 -msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:196 -msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:200 -msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:202 -msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:212 -msgid "``Wheel-Version`` is the version number of the Wheel specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:213 -msgid "``Generator`` is the name and optionally the version of the software that produced the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:215 -msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:218 -msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:220 -msgid "``Build`` is the build number and is omitted if there is no build number." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:221 -msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:224 -msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:226 -msgid "Wheel does not contain setup.py or setup.cfg." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:228 -msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:235 -#: ../source/specifications/recording-installed-packages.rst:35 -msgid "The .dist-info directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:237 -msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:239 -msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:241 -msgid "WHEEL is the wheel metadata specific to a build of the package." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:242 -msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:248 -msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:249 -msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:251 -msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:254 -msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:261 -msgid "The .data directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:263 -msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:271 -msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:277 -msgid "Signed wheel files" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:279 -msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:290 -msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:295 -msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:302 -msgid "(The hash value is the same format used in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:304 -msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:307 -msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:312 -msgid "See" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:314 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:315 -msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:316 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:317 -msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:321 -msgid "Comparison to .egg" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:323 -msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:328 -msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:331 -msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:337 -msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:341 -msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:344 -msgid "Wheel is a reference to the other Python." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:348 -msgid "FAQ" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:352 -msgid "Wheel defines a .data directory. Should I put all my data there?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:354 -msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:363 -msgid "Why does wheel include attached signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:365 -msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:373 -msgid "Why does wheel allow JWS signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:375 -msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:381 -msgid "Why does wheel also allow S/MIME signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:383 -msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:386 -msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:391 -msgid "What's the deal with \"purelib\" vs. \"platlib\"?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:393 -msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:398 -msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:403 -msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:409 -msgid "Is it possible to import Python code directly from a wheel file?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:411 -msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:417 -msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:426 -msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:443 -msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:450 -msgid "Changes" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:452 -msgid "Since :pep:`427`, this specification has changed as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:454 -msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:461 -msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:466 -msgid "Appendix" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:468 -msgid "Example urlsafe-base64-nopad implementation::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:482 -msgid "Copyright" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:484 -msgid "This document has been placed into the public domain." -msgstr "" - -#: ../source/specifications/core-metadata.rst:5 -msgid "Core metadata specifications" -msgstr "" - -#: ../source/specifications/core-metadata.rst:7 -msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:10 -msgid "``Metadata-Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:11 -msgid "``Name``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:12 -msgid "``Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:14 -msgid "All the other fields are optional." -msgstr "" - -#: ../source/specifications/core-metadata.rst:16 -msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." -msgstr "" - -#: ../source/specifications/core-metadata.rst:25 -msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:30 -msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." -msgstr "" - -#: ../source/specifications/core-metadata.rst:41 -msgid "Metadata-Version" -msgstr "" - -#: ../source/specifications/core-metadata.rst:45 -msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." -msgstr "" - -#: ../source/specifications/core-metadata.rst:48 -msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:54 -msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." -msgstr "" - -#: ../source/specifications/core-metadata.rst:58 -#: ../source/specifications/core-metadata.rst:80 -#: ../source/specifications/core-metadata.rst:95 -#: ../source/specifications/core-metadata.rst:155 -#: ../source/specifications/core-metadata.rst:170 -#: ../source/specifications/core-metadata.rst:208 -#: ../source/specifications/core-metadata.rst:283 -#: ../source/specifications/core-metadata.rst:287 -#: ../source/specifications/core-metadata.rst:291 -#: ../source/specifications/core-metadata.rst:295 -#: ../source/specifications/core-metadata.rst:327 -#: ../source/specifications/core-metadata.rst:347 -#: ../source/specifications/core-metadata.rst:373 -#: ../source/specifications/core-metadata.rst:391 -#: ../source/specifications/core-metadata.rst:416 -#: ../source/specifications/core-metadata.rst:438 -#: ../source/specifications/core-metadata.rst:600 -#: ../source/specifications/core-metadata.rst:620 -#: ../source/specifications/core-metadata.rst:630 -msgid "Example::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:66 -msgid "Name" -msgstr "" - -#: ../source/specifications/core-metadata.rst:69 -msgid "Added additional restrictions on format from :pep:`508`" -msgstr "" - -#: ../source/specifications/core-metadata.rst:72 -msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:88 -msgid "Version" -msgstr "" - -#: ../source/specifications/core-metadata.rst:92 -msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:101 -msgid "Dynamic (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:105 -msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." -msgstr "" - -#: ../source/specifications/core-metadata.rst:108 -msgid "When found in the metadata of a source distribution, the following rules apply:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:111 -msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." -msgstr "" - -#: ../source/specifications/core-metadata.rst:115 -msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:118 -msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:122 -msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." -msgstr "" - -#: ../source/specifications/core-metadata.rst:127 -msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:131 -msgid "Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:135 -msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." -msgstr "" - -#: ../source/specifications/core-metadata.rst:146 -msgid "Supported-Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:150 -msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." -msgstr "" - -#: ../source/specifications/core-metadata.rst:164 -msgid "Summary" -msgstr "" - -#: ../source/specifications/core-metadata.rst:168 -msgid "A one-line summary of what the distribution does." -msgstr "" - -#: ../source/specifications/core-metadata.rst:188 -msgid "This field may be specified in the message body instead." -msgstr "" - -#: ../source/specifications/core-metadata.rst:191 -msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:196 -msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." -msgstr "" - -#: ../source/specifications/core-metadata.rst:202 -msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:219 -msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." -msgstr "" - -#: ../source/specifications/core-metadata.rst:223 -msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:232 -msgid "Description-Content-Type" -msgstr "" - -#: ../source/specifications/core-metadata.rst:236 -msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:239 -msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." -msgstr "" - -#: ../source/specifications/core-metadata.rst:253 -msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:259 -msgid "Format::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:263 -msgid "The ``type/subtype`` part has only a few legal values:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:265 -msgid "``text/plain``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:266 -msgid "``text/x-rst``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:267 -msgid "``text/markdown``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:269 -msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:273 -msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:278 -msgid "``GFM`` for `Github-flavored Markdown `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:280 -msgid "``CommonMark`` for `CommonMark `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:299 -msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." -msgstr "" - -#: ../source/specifications/core-metadata.rst:303 -msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:307 -msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:311 -msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." -msgstr "" - -#: ../source/specifications/core-metadata.rst:320 -msgid "Keywords" -msgstr "" - -#: ../source/specifications/core-metadata.rst:324 -msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." -msgstr "" - -#: ../source/specifications/core-metadata.rst:333 -msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." -msgstr "" - -#: ../source/specifications/core-metadata.rst:341 -msgid "Home-page" -msgstr "" - -#: ../source/specifications/core-metadata.rst:345 -msgid "A string containing the URL for the distribution's home page." -msgstr "" - -#: ../source/specifications/core-metadata.rst:353 -msgid "Download-URL" -msgstr "" - -#: ../source/specifications/core-metadata.rst:357 -msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:366 -msgid "Author" -msgstr "" - -#: ../source/specifications/core-metadata.rst:370 -msgid "A string containing the author's name at a minimum; additional contact information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:383 -msgid "Author-email" -msgstr "" - -#: ../source/specifications/core-metadata.rst:387 -msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:395 -#: ../source/specifications/core-metadata.rst:442 -msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:405 -msgid "Maintainer" -msgstr "" - -#: ../source/specifications/core-metadata.rst:409 -msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:412 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:426 -msgid "Maintainer-email" -msgstr "" - -#: ../source/specifications/core-metadata.rst:430 -msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:434 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:452 -msgid "License" -msgstr "" - -#: ../source/specifications/core-metadata.rst:456 -msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." -msgstr "" - -#: ../source/specifications/core-metadata.rst:476 -msgid "Classifier (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:480 -msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:485 -#: ../source/specifications/core-metadata.rst:574 -#: ../source/specifications/core-metadata.rst:691 -#: ../source/specifications/core-metadata.rst:715 -msgid "This field may be followed by an environment marker after a semicolon." -msgstr "" - -#: ../source/specifications/core-metadata.rst:496 -msgid "Requires-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:499 -#: ../source/specifications/core-metadata.rst:561 -#: ../source/specifications/core-metadata.rst:663 -#: ../source/specifications/core-metadata.rst:704 -msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." -msgstr "" - -#: ../source/specifications/core-metadata.rst:503 -msgid "Each entry contains a string naming some other distutils project required by this distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:506 -msgid "The format of a requirement string contains from one to four parts:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:508 -msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." -msgstr "" - -#: ../source/specifications/core-metadata.rst:510 -msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." -msgstr "" - -#: ../source/specifications/core-metadata.rst:513 -msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:516 -msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." -msgstr "" - -#: ../source/specifications/core-metadata.rst:519 -msgid "See :pep:`508` for full details of the allowed format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:521 -msgid "The project names should correspond to names as found on the `Python Package Index`_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:524 -msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:538 -msgid "Requires-Python" -msgstr "" - -#: ../source/specifications/core-metadata.rst:542 -msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." -msgstr "" - -#: ../source/specifications/core-metadata.rst:546 -msgid "The value must be in the format specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:548 -msgid "This field cannot be followed by an environment marker." -msgstr "" - -#: ../source/specifications/core-metadata.rst:558 -msgid "Requires-External (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:565 -msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:570 -msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:576 -msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." -msgstr "" - -#: ../source/specifications/core-metadata.rst:581 -msgid "Notice that there is no particular rule on the strings to be used." -msgstr "" - -#: ../source/specifications/core-metadata.rst:593 -msgid "Project-URL (multiple-use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:597 -msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." -msgstr "" - -#: ../source/specifications/core-metadata.rst:604 -msgid "The label is free text limited to 32 characters." -msgstr "" - -#: ../source/specifications/core-metadata.rst:612 -msgid "Provides-Extra (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:616 -msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." -msgstr "" - -#: ../source/specifications/core-metadata.rst:625 -msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:635 -msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." -msgstr "" - -#: ../source/specifications/core-metadata.rst:639 -msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:644 -msgid "Rarely Used Fields" -msgstr "" - -#: ../source/specifications/core-metadata.rst:646 -msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:651 -msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." -msgstr "" - -#: ../source/specifications/core-metadata.rst:660 -msgid "Provides-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:667 -msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:672 -msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:679 -msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:687 -msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." -msgstr "" - -#: ../source/specifications/core-metadata.rst:701 -msgid "Obsoletes-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:708 -msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." -msgstr "" - -#: ../source/specifications/core-metadata.rst:712 -msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:717 -msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:730 -msgid "reStructuredText markup: http://docutils.sourceforge.net/" -msgstr "" - -#: ../source/specifications/core-metadata.rst:735 -msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:6 -msgid "Declaring build system dependencies" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:8 -msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:5 -msgid "Declaring project metadata" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:7 -msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:12 -msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:18 -msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:27 -msgid "The only fields required to be statically defined are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:29 -#: ../source/specifications/declaring-project-metadata.rst:41 -msgid "``name``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:31 -msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:34 -#: ../source/specifications/declaring-project-metadata.rst:54 -msgid "``version``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:36 -msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:43 -#: ../source/specifications/declaring-project-metadata.rst:56 -#: ../source/specifications/declaring-project-metadata.rst:68 -#: ../source/specifications/declaring-project-metadata.rst:117 -msgid "TOML_ type: string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:44 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:47 -msgid "The name of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:49 -msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:57 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:60 -msgid "The version of the project as supported by :pep:`440`." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:62 -msgid "Users SHOULD prefer to specify already-normalized versions." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:66 -msgid "``description``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:69 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:72 -msgid "The summary description of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:76 -msgid "``readme``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:78 -msgid "TOML_ type: string or table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:79 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:83 -msgid "The full description of the project (i.e. the README)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:85 -msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:96 -msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:103 -msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:115 -msgid "``requires-python``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:118 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:121 -msgid "The Python version requirements of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:125 -msgid "``license``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:127 -msgid "TOML_ type: table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:128 -msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:131 -msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:140 -msgid "``authors``/``maintainers``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:142 -msgid "TOML_ type: Array of inline tables with string keys and values" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:143 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:149 -msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:154 -msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:157 -msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:163 -msgid "Using the data to fill in :ref:`core metadata ` is as follows:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:166 -msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:169 -msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:173 -msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:177 -msgid "Multiple values should be separated by commas." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:181 -msgid "``keywords``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:183 -#: ../source/specifications/declaring-project-metadata.rst:193 -msgid "TOML_ type: array of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:184 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:187 -msgid "The keywords for the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:191 -msgid "``classifiers``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:194 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:197 -msgid "Trove classifiers which apply to the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:201 -msgid "``urls``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:203 -msgid "TOML_ type: table with keys and values of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:204 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:207 -msgid "A table of URLs where the key is the URL label and the value is the URL itself." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:212 -msgid "Entry points" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:214 -msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:216 -msgid ":ref:`Entry points specification `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:218 -msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:224 -msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:228 -msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:234 -msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:242 -msgid "``dependencies``/``optional-dependencies``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:244 -msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:247 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:251 -msgid "The (optional) dependencies of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:253 -msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:258 -msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:269 -msgid "``dynamic``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:271 -msgid "TOML_ type: array of string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:272 -msgid "A corresponding :ref:`core metadata ` field does not exist" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:275 -msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:281 -msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:283 -msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:285 -msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:290 -msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:294 -msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:296 -msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:300 -msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:6 -msgid "Dependency specifiers" -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:8 -msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:11 -msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." -msgstr "" - -#: ../source/specifications/direct-url.rst:6 -msgid "Recording the Direct URL Origin of installed distributions" -msgstr "" - -#: ../source/specifications/direct-url.rst:8 -msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." -msgstr "" - -#: ../source/specifications/direct-url.rst:17 -msgid "Specification" -msgstr "" - -#: ../source/specifications/direct-url.rst:19 -msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/direct-url.rst:23 -#: ../source/specifications/recording-installed-packages.rst:206 -msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." -msgstr "" - -#: ../source/specifications/direct-url.rst:26 -msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." -msgstr "" - -#: ../source/specifications/direct-url.rst:29 -msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." -msgstr "" - -#: ../source/specifications/direct-url.rst:36 -msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." -msgstr "" - -#: ../source/specifications/direct-url.rst:39 -msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" -msgstr "" - -#: ../source/specifications/direct-url.rst:45 -msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." -msgstr "" - -#: ../source/specifications/direct-url.rst:49 -msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" -msgstr "" - -#: ../source/specifications/direct-url.rst:52 -msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." -msgstr "" - -#: ../source/specifications/direct-url.rst:58 -msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." -msgstr "" - -#: ../source/specifications/direct-url.rst:61 -msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." -msgstr "" - -#: ../source/specifications/direct-url.rst:68 -msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:71 -msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." -msgstr "" - -#: ../source/specifications/direct-url.rst:78 -msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:81 -msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." -msgstr "" - -#: ../source/specifications/direct-url.rst:84 -msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." -msgstr "" - -#: ../source/specifications/direct-url.rst:91 -msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." -msgstr "" - -#: ../source/specifications/direct-url.rst:96 -msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." -msgstr "" - -#: ../source/specifications/direct-url.rst:102 -msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." -msgstr "" - -#: ../source/specifications/direct-url.rst:110 -msgid "Registered VCS" -msgstr "" - -#: ../source/specifications/direct-url.rst:112 -msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." -msgstr "" - -#: ../source/specifications/direct-url.rst:122 -msgid "Git" -msgstr "" - -#: ../source/specifications/direct-url.rst:124 -#: ../source/specifications/direct-url.rst:156 -#: ../source/specifications/direct-url.rst:179 -#: ../source/specifications/direct-url.rst:202 -msgid "Home page" -msgstr "" - -#: ../source/specifications/direct-url.rst:126 -msgid "https://git-scm.com/" -msgstr "" - -#: ../source/specifications/direct-url.rst:128 -#: ../source/specifications/direct-url.rst:160 -#: ../source/specifications/direct-url.rst:183 -#: ../source/specifications/direct-url.rst:206 -msgid "vcs command" -msgstr "" - -#: ../source/specifications/direct-url.rst:130 -#: ../source/specifications/direct-url.rst:134 -msgid "git" -msgstr "" - -#: ../source/specifications/direct-url.rst:132 -#: ../source/specifications/direct-url.rst:164 -#: ../source/specifications/direct-url.rst:187 -#: ../source/specifications/direct-url.rst:210 -msgid "``vcs`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:136 -#: ../source/specifications/direct-url.rst:168 -#: ../source/specifications/direct-url.rst:191 -#: ../source/specifications/direct-url.rst:214 -msgid "``requested_revision`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:138 -msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." -msgstr "" - -#: ../source/specifications/direct-url.rst:141 -#: ../source/specifications/direct-url.rst:172 -#: ../source/specifications/direct-url.rst:195 -#: ../source/specifications/direct-url.rst:219 -msgid "``commit_id`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:143 -msgid "A commit hash (40 hexadecimal characters sha1)." -msgstr "" - -#: ../source/specifications/direct-url.rst:147 -msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." -msgstr "" - -#: ../source/specifications/direct-url.rst:154 -msgid "Mercurial" -msgstr "" - -#: ../source/specifications/direct-url.rst:158 -msgid "https://www.mercurial-scm.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:162 -#: ../source/specifications/direct-url.rst:166 -msgid "hg" -msgstr "" - -#: ../source/specifications/direct-url.rst:170 -msgid "A tag name, branch name, changeset ID, shortened changeset ID." -msgstr "" - -#: ../source/specifications/direct-url.rst:174 -msgid "A changeset ID (40 hexadecimal characters)." -msgstr "" - -#: ../source/specifications/direct-url.rst:177 -msgid "Bazaar" -msgstr "" - -#: ../source/specifications/direct-url.rst:181 -msgid "https://bazaar.canonical.com/" -msgstr "" - -#: ../source/specifications/direct-url.rst:185 -#: ../source/specifications/direct-url.rst:189 -msgid "bzr" -msgstr "" - -#: ../source/specifications/direct-url.rst:193 -msgid "A tag name, branch name, revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:197 -msgid "A revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:200 -msgid "Subversion" -msgstr "" - -#: ../source/specifications/direct-url.rst:204 -msgid "https://subversion.apache.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:208 -#: ../source/specifications/direct-url.rst:212 -msgid "svn" -msgstr "" - -#: ../source/specifications/direct-url.rst:216 -msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." -msgstr "" - -#: ../source/specifications/direct-url.rst:221 -msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." -msgstr "" - -#: ../source/specifications/direct-url.rst:229 -msgid "Example direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:231 -msgid "Source archive:" -msgstr "" - -#: ../source/specifications/direct-url.rst:242 -msgid "Git URL with tag and commit-hash:" -msgstr "" - -#: ../source/specifications/direct-url.rst:255 -msgid "Local directory:" -msgstr "" - -#: ../source/specifications/direct-url.rst:264 -msgid "Local directory installed in editable mode:" -msgstr "" - -#: ../source/specifications/direct-url.rst:277 -msgid "Example pip commands and their effect on direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:279 -msgid "Commands that generate a ``direct_url.json``:" -msgstr "" - -#: ../source/specifications/direct-url.rst:281 -msgid "pip install https://example.com/app-1.0.tgz" -msgstr "" - -#: ../source/specifications/direct-url.rst:282 -msgid "pip install https://example.com/app-1.0.whl" -msgstr "" - -#: ../source/specifications/direct-url.rst:283 -msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" -msgstr "" - -#: ../source/specifications/direct-url.rst:284 -msgid "pip install ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:285 -msgid "pip install file:///home/user/app" -msgstr "" - -#: ../source/specifications/direct-url.rst:286 -msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" -msgstr "" - -#: ../source/specifications/direct-url.rst:290 -msgid "pip install -e ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:292 -msgid "Commands that *do not* generate a ``direct_url.json``" -msgstr "" - -#: ../source/specifications/direct-url.rst:294 -msgid "pip install app" -msgstr "" - -#: ../source/specifications/direct-url.rst:295 -msgid "pip install app --no-index --find-links https://example.com/" -msgstr "" - -#: ../source/specifications/entry-points.rst:5 -msgid "Entry points specification" -msgstr "" - -#: ../source/specifications/entry-points.rst:7 -msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" -msgstr "" - -#: ../source/specifications/entry-points.rst:11 -msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." -msgstr "" - -#: ../source/specifications/entry-points.rst:14 -msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." -msgstr "" - -#: ../source/specifications/entry-points.rst:19 -msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." -msgstr "" - -#: ../source/specifications/entry-points.rst:28 -msgid "Data model" -msgstr "" - -#: ../source/specifications/entry-points.rst:30 -msgid "Conceptually, an entry point is defined by three required properties:" -msgstr "" - -#: ../source/specifications/entry-points.rst:32 -msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:42 -msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:51 -msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:64 -msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." -msgstr "" - -#: ../source/specifications/entry-points.rst:68 -msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." -msgstr "" - -#: ../source/specifications/entry-points.rst:73 -msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." -msgstr "" - -#: ../source/specifications/entry-points.rst:80 -msgid "File format" -msgstr "" - -#: ../source/specifications/entry-points.rst:82 -msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." -msgstr "" - -#: ../source/specifications/entry-points.rst:87 -msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:97 -msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:100 -msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." -msgstr "" - -#: ../source/specifications/entry-points.rst:104 -msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." -msgstr "" - -#: ../source/specifications/entry-points.rst:112 -msgid "For example::" -msgstr "" - -#: ../source/specifications/entry-points.rst:124 -msgid "Use for scripts" -msgstr "" - -#: ../source/specifications/entry-points.rst:126 -msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." -msgstr "" - -#: ../source/specifications/entry-points.rst:134 -msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:141 -msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." -msgstr "" - -#: ../source/specifications/entry-points.rst:149 -msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." -msgstr "" - -#: ../source/specifications/entry-points.rst:154 -msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." -msgstr "" - -#: ../source/specifications/index.rst:4 -msgid "PyPA specifications" -msgstr "" - -#: ../source/specifications/index.rst:6 -msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." -msgstr "" - -#: ../source/specifications/index.rst:13 -msgid "Package Distribution Metadata" -msgstr "" - -#: ../source/specifications/index.rst:30 -msgid "Package Distribution File Formats" -msgstr "" - -#: ../source/specifications/index.rst:40 -msgid "Package Index Interfaces" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:6 -msgid "Platform compatibility tags" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:8 -msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:12 -msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:16 -msgid "Platform tags for Windows" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:18 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:22 -msgid "Platform tags for macOS (Mac OS X)" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:24 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:28 -msgid "Platform tags for common Linux distributions" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:32 -msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:36 -msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:41 -msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:44 -msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:46 -msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:49 -msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:54 -msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:59 -msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:65 -msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:71 -msgid "Manylinux compatibility support" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:74 -msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:76 -msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:79 -msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "Tool" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux1``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2010``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2014``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux_x_y``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=8.1.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=20.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "auditwheel" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=1.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=2.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.3.0`` [#]_" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:90 -msgid "Platform tags for other \\*nix platforms" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:92 -msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:98 -msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" -msgstr "" - -#: ../source/specifications/pypirc.rst:6 -msgid "The :file:`.pypirc` file" -msgstr "" - -#: ../source/specifications/pypirc.rst:8 -msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." -msgstr "" - -#: ../source/specifications/pypirc.rst:13 -msgid "The format (originally defined by the :ref:`distutils` package) is:" -msgstr "" - -#: ../source/specifications/pypirc.rst:32 -msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:35 -msgid "Each section describing a repository defines three fields:" -msgstr "" - -#: ../source/specifications/pypirc.rst:37 -msgid "``repository``: The URL of the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:38 -msgid "``username``: The registered username on the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:39 -msgid "``password``: The password that will used to authenticate the username." -msgstr "" - -#: ../source/specifications/pypirc.rst:43 -msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." -msgstr "" - -#: ../source/specifications/pypirc.rst:47 -msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" -msgstr "" - -#: ../source/specifications/pypirc.rst:57 -msgid "Common configurations" -msgstr "" - -#: ../source/specifications/pypirc.rst:61 -msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." -msgstr "" - -#: ../source/specifications/pypirc.rst:66 -msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" -msgstr "" - -#: ../source/specifications/pypirc.rst:82 -msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." -msgstr "" - -#: ../source/specifications/pypirc.rst:86 -msgid "Using a PyPI token" -msgstr "" - -#: ../source/specifications/pypirc.rst:88 -msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" -msgstr "" - -#: ../source/specifications/pypirc.rst:97 -msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." -msgstr "" - -#: ../source/specifications/pypirc.rst:103 -msgid "Using another package index" -msgstr "" - -#: ../source/specifications/pypirc.rst:105 -msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" -msgstr "" - -#: ../source/specifications/pypirc.rst:132 -msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:5 -msgid "Recording installed projects" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:7 -msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:12 -msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:21 -msgid "History and change workflow" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:23 -msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:29 -msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:37 -msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:41 -msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:50 -msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:60 -msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:69 -msgid "This ``.dist-info`` directory can contain these files, described in detail below:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:72 -msgid "``METADATA``: contains project metadata" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:73 -msgid "``RECORD``: records the list of installed files." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:74 -msgid "``INSTALLER``: records the name of the tool used to install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:76 -msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:82 -msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:87 -msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:94 -msgid "The METADATA file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:96 -msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:99 -msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:105 -msgid "The RECORD file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:107 -msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:110 -msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:113 -msgid "field delimiter: ``,`` (comma)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:114 -msgid "quoting char: ``\"`` (straight double quote)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:115 -msgid "line terminator: either ``\\r\\n`` or ``\\n``." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:117 -msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:120 -msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:125 -msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:130 -msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:133 -msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:139 -msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:146 -msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:151 -msgid "Here is an example snippet of a possible ``RECORD`` file::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:170 -msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:177 -msgid "The INSTALLER file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:179 -msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:185 -msgid "The file can be terminated by zero or more ASCII whitespace characters." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:187 -msgid "Here are examples of two possible ``INSTALLER`` files::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:195 -msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:201 -msgid "The direct_url.json file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:203 -msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:209 -msgid "Its detailed specification is at :ref:`direct-url`." -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:6 -msgid "Simple repository API" -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:8 -msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:6 -msgid "Source distribution format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:8 -msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:13 -msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:21 -msgid "Source distributions are also known as *sdists* for short." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:24 -msgid "Source distribution file name" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:26 -msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:31 -msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:35 -msgid "Source distribution file format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:37 -msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:45 -msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:48 -msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:6 -msgid "Version specifiers" -msgstr "" - -#: ../source/specifications/version-specifiers.rst:8 -msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:11 -msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." -msgstr "" - -#: ../source/support.rst:3 -msgid "How to Get Support" -msgstr "" - -#: ../source/support.rst:5 -msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." -msgstr "" - -#: ../source/support.rst:8 -msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:5 -msgid "Creating Documentation" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:7 -msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:13 -msgid "Installing Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:14 -msgid "Use ``pip`` to install Sphinx:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:28 -msgid "For other installation methods, see this `installation guide`_ by Sphinx." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:33 -msgid "Getting Started With Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:35 -msgid "Create a ``docs`` directory inside your project to hold your documentation:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:42 -msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:49 -msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:51 -msgid "You can add some information about your project in ``index.rst``, then build them:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:57 -msgid "For more details on the build process, see this `guide`_ by Read The Docs." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:62 -msgid "Other Sources" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:64 -msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/index.rst:4 -msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:5 -msgid "Installing Packages" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:7 -msgid "This section covers the basics of how to install Python :term:`packages `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:10 -msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:28 -msgid "Requirements for Installing Packages" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:30 -msgid "This section describes the steps to follow before installing other Python packages." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:35 -msgid "Ensure you can run Python from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:37 -msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:53 -msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:57 -msgid "If you're a newcomer and you get an error like this:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:66 -msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:72 -msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:82 -msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:87 -msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:99 -msgid "Ensure you can run pip from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:101 -msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:116 -msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:124 -msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:139 -msgid "If that still doesn't allow you to run ``python -m pip``:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:141 -msgid "Securely Download `get-pip.py `_ [1]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:144 -msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:150 -msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:159 -msgid "Ensure pip, setuptools, and wheel are up to date" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:161 -msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:169 -msgid "Optionally, create a virtual environment" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:171 -msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:188 -msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:195 -msgid "Creating Virtual Environments" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:197 -msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:203 -msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:209 -msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:213 -msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:216 -msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:220 -msgid "Currently, there are two common tools for creating Python virtual environments:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:222 -msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:225 -msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:230 -msgid "The basic usage is like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:232 -msgid "Using `venv`_:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:248 -msgid "Using :ref:`virtualenv`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:264 -msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:266 -msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:271 -msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:281 -msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:288 -msgid "Use pip for Installing" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:290 -msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:297 -msgid "Installing from PyPI" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:299 -msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:307 -msgid "To install the latest version of \"SomeProject\":" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:321 -msgid "To install a specific version:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:335 -msgid "To install greater than or equal to one version and less than another:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:350 -msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:365 -msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:370 -msgid "Source Distributions vs Wheels" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:372 -msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:378 -msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:383 -msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:391 -msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:408 -msgid "Installing to the User Site" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:410 -msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:425 -msgid "For more information see the `User Installs `_ section from the pip docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:429 -msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:432 -msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:440 -msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:446 -msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:462 -msgid "Install a list of requirements specified in a :ref:`Requirements File `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:478 -msgid "Installing from VCS" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:480 -msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:502 -msgid "Installing from other Indexes" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:504 -msgid "Install from an alternate index" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:518 -msgid "Search an additional index during install, in addition to :term:`PyPI `" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:534 -msgid "Installing from a local src tree" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:537 -msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:554 -msgid "You can also install normally from src" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:571 -msgid "Install a particular source archive file." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:585 -msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:605 -msgid "Installing from other sources" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:607 -msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:619 -msgid "Installing Prereleases" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:621 -msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:637 -msgid "Installing Setuptools \"Extras\"" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:639 -msgid "Install `setuptools extras`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:659 -msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:668 -msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:673 -msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:4 -msgid "Managing Application Dependencies" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:6 -msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:9 -msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:13 -msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:17 -msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:24 -msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:30 -msgid "Installing Pipenv" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:32 -msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:38 -msgid "Use ``pip`` to install Pipenv:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:54 -msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:65 -msgid "Installing packages for your project" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:67 -msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:76 -msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:112 -msgid "Using installed packages" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:114 -msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:125 -msgid "Then you can run this script using ``pipenv run``:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:131 -msgid "You should get output similar to this:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:137 -msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:143 -#: ../source/tutorials/packaging-projects.rst:594 -msgid "Next steps" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:145 -msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:148 -msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:151 -msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:160 -msgid "Other Tools for Application Dependency Management" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:162 -msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:166 -msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:172 -msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:175 -msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:177 -msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:2 -msgid "Packaging Python Projects" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:4 -msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:10 -msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:18 -msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:35 -msgid "A simple project" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:37 -msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:41 -msgid "Create the following file structure locally:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:51 -msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:54 -msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:63 -msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:67 -msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:75 -msgid "Creating the package files" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:77 -msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:95 -msgid "Creating a test directory" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:97 -msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:101 -msgid "Creating pyproject.toml" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:103 -msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:117 -msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:121 -msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:127 -msgid "See :pep:`517` and :pep:`518` for background and details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:131 -msgid "Configuring metadata" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:133 -msgid "There are two types of metadata: static and dynamic." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:135 -msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:137 -msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:141 -msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:148 -msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:153 -msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:185 -msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:191 -#: ../source/tutorials/packaging-projects.rst:286 -msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:196 -msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:199 -#: ../source/tutorials/packaging-projects.rst:293 -msgid "``author`` and ``author_email`` are used to identify the author of the package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:201 -#: ../source/tutorials/packaging-projects.rst:295 -msgid "``description`` is a short, one-sentence summary of the package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:202 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:206 -#: ../source/tutorials/packaging-projects.rst:300 -msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:208 -#: ../source/tutorials/packaging-projects.rst:302 -msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:211 -#: ../source/tutorials/packaging-projects.rst:305 -msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:213 -#: ../source/tutorials/packaging-projects.rst:307 -msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:221 -msgid "In the ``options`` category, we have controls for setuptools itself:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:223 -msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:227 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:234 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:238 -#: ../source/tutorials/packaging-projects.rst:329 -msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:244 -msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:248 -msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:283 -msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:291 -msgid "``version`` is the package version. See :pep:`440` for more details on versions." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:296 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:314 -msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:319 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:325 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:333 -msgid "Creating README.md" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:335 -msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:347 -msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:354 -msgid "Creating a LICENSE" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:356 -msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:387 -msgid "Including other files" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:389 -msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:393 -msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:402 -msgid "Generating distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:404 -msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:408 -msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:422 -msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:425 -msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:439 -msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:449 -msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:458 -msgid "Uploading the distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:460 -msgid "Finally, it's time to upload your package to the Python Package Index!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:462 -msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:470 -msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:477 -msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:492 -msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:506 -msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:510 -msgid "After the command completes, you should see output similar to this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:523 -msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:528 -msgid "Installing your newly uploaded package" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:530 -msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:546 -msgid "Make sure to specify your username in the package name!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:548 -msgid "pip should install the package from TestPyPI and the output should look something like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:558 -msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:565 -msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:580 -msgid "and import the package:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:588 -msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:596 -msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:599 -msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:604 -msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:608 -msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:610 -msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:613 -msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:617 -msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:619 -msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:622 -msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:624 -msgid "Read about :doc:`/guides/packaging-binary-extensions`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:625 -msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." -msgstr "" diff --git a/locales/pt_BR/LC_MESSAGES/messages.po b/locales/pt_BR/LC_MESSAGES/messages.po deleted file mode 100644 index 7f42a7129..000000000 --- a/locales/pt_BR/LC_MESSAGES/messages.po +++ /dev/null @@ -1,18229 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2013–2020, PyPA -# This file is distributed under the same license as the Python Packaging User Guide package. -# Rafael Fontenelle , 2021. -# meowmeowmeowcat , 2021. -msgid "" -msgstr "" -"Project-Id-Version: Python Packaging User Guide\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-11-29 08:50+0000\n" -"Last-Translator: Rafael Fontenelle \n" -"Language-Team: Portuguese (Brazil) \n" -"Language: pt_BR\n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=UTF-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Plural-Forms: nplurals=2; plural=n > 1;\n" -"X-Generator: Weblate 4.10-dev\n" - -#: ../source/contribute.rst:5 -msgid "Contribute to this guide" -msgstr "Contribuir para este guia" - -#: ../source/contribute.rst:7 -msgid "" -"The |PyPUG| welcomes contributors! There are lots of ways to help out, " -"including:" -msgstr "" -"O |PyPUG| dá as boas-vindas aos(às) contribuidores(as)! Existem muitas " -"maneiras de ajudar, incluindo:" - -#: ../source/contribute.rst:10 -msgid "Reading the guide and giving feedback" -msgstr "Lendo o guia e dando feedback" - -#: ../source/contribute.rst:11 -msgid "Reviewing new contributions" -msgstr "Revisando novas contribuições" - -#: ../source/contribute.rst:12 -msgid "Revising existing content" -msgstr "Revisando conteúdo existente" - -#: ../source/contribute.rst:13 -msgid "Writing new content" -msgstr "Escrevendo novo conteúdo" - -#: ../source/contribute.rst:15 -msgid "" -"Most of the work on the |PyPUG| takes place on the `project's GitHub " -"repository`__. To get started, check out the list of `open issues`__ and " -"`pull requests`__. If you're planning to write or edit the guide, please " -"read the :ref:`style guide `." -msgstr "" -"A maior parte do trabalho no |PyPUG| ocorre no `repositório GitHub do " -"projeto `__. Para começar, verifique a lista de " -"`problemas abertos `__ e `pull requests`__. Se você está " -"planejando escrever ou editar o guia, leia o :ref:`guia de estilo " -"`." - -#: ../source/contribute.rst:24 -msgid "" -"By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of " -"Conduct`__." -msgstr "" -"Ao contribuir para o |PyPUG|, espera-se que você siga o `Código de Conduta " -"`__ da PSF." - -#: ../source/contribute.rst:31 -msgid "Documentation types" -msgstr "Tipos de documentação" - -#: ../source/contribute.rst:33 -msgid "" -"This project consists of four distinct documentation types with specific " -"purposes. When proposing new additions to the project please pick the " -"appropriate documentation type." -msgstr "" -"Este projeto consiste em quatro tipos de documentação distintos com " -"finalidades específicas. Ao propor novas adições ao projeto, escolha o tipo " -"de documentação apropriado." - -#: ../source/contribute.rst:38 ../source/tutorials/index.rst:2 -msgid "Tutorials" -msgstr "Tutoriais" - -#: ../source/contribute.rst:40 -msgid "" -"Tutorials are focused on teaching the reader new concepts by accomplishing a " -"goal. They are opinionated step-by-step guides. They do not include " -"extraneous warnings or information. `example tutorial-style document`_." -msgstr "" -"Os tutoriais são focados em ensinar ao leitor novos conceitos através da " -"realização de um objetivo. Eles são guias passo a passo opinativos. Eles não " -"incluem avisos ou informações estranhas. `Exemplo de documento no estilo " -"tutorial `_." - -#: ../source/contribute.rst:47 ../source/guides/index.rst:2 -msgid "Guides" -msgstr "Guias" - -#: ../source/contribute.rst:49 -msgid "" -"Guides are focused on accomplishing a specific task and can assume some " -"level of pre-requisite knowledge. These are similar to tutorials, but have a " -"narrow and clear focus and can provide lots of caveats and additional " -"information as needed. They may also discuss multiple approaches to " -"accomplishing the task. :doc:`example guide-style document `." -msgstr "" -"Os guias são focados em realizar uma tarefa específica e podem assumir algum " -"nível de conhecimento pré-requisito. Eles são semelhantes aos tutoriais, mas " -"têm um foco estreito e claro e podem fornecer muitas advertências e " -"informações adicionais, conforme necessário. Eles também podem discutir " -"várias abordagens para realizar a tarefa. :doc:`Exemplo de documento no " -"estilo guia `." - -#: ../source/contribute.rst:56 ../source/discussions/index.rst:2 -msgid "Discussions" -msgstr "Discussões" - -#: ../source/contribute.rst:58 -msgid "" -"Discussions are focused on understanding and information. These explore a " -"specific topic without a specific goal in mind. :doc:`example discussion-" -"style document `." -msgstr "" -"As discussões são focadas em compreensão e informação. Eles exploram um " -"tópico específico sem um objetivo específico em mente. :doc:`Exemplo de " -"documento no estilo discussão `." - -#: ../source/contribute.rst:63 -msgid "Specifications" -msgstr "Especificações" - -#: ../source/contribute.rst:65 -msgid "" -"Specifications are reference documention focused on comprehensively " -"documenting an agreed-upon interface for interoperability between packaging " -"tools. :doc:`example specification-style document `." -msgstr "" -"As especificações são documentação de referência focada na documentação " -"abrangente de uma interface acordada para interoperabilidade entre " -"ferramentas de empacotamento. :doc:`Exemplo de documento no estilo " -"especificação `." - -#: ../source/contribute.rst:73 -msgid "Building the guide locally" -msgstr "Construindo o guia localmente" - -#: ../source/contribute.rst:75 -msgid "" -"Though not required to contribute, it may be useful to build this guide " -"locally in order to test your changes. In order to build this guide locally, " -"you'll need:" -msgstr "" -"Embora não seja necessário contribuir, pode ser útil construir este guia " -"localmente para testar suas alterações. Para construir este guia localmente, " -"você precisará:" - -#: ../source/contribute.rst:79 -msgid "" -"`Nox `_. You can install or upgrade " -"nox using ``pip``::" -msgstr "" -"`Nox `_. Você pode instalar ou " -"atualizar o nox usando o ``pip``::" - -#: ../source/contribute.rst:84 -msgid "" -"Python 3.6. Our build scripts are designed to work with Python 3.6 only. See " -"the `Hitchhiker's Guide to Python installation instructions`_ to install " -"Python 3.6 on your operating system." -msgstr "" -"Python 3.6. Nossos scripts de construção são projetados para funcionar " -"apenas com Python 3.6. Consulte o `Guia do mochileiro para as instruções de " -"instalação do Python `_ para instalar o Python 3.6 em seu sistema operacional." - -#: ../source/contribute.rst:91 -msgid "" -"To build the guide, run the following bash command in the source folder::" -msgstr "" -"Para construir o guia, execute o seguinte comando bash na pasta do código-" -"fonte::" - -#: ../source/contribute.rst:95 -msgid "" -"After the process has completed you can find the HTML output in the ``./" -"build/html`` directory. You can open the ``index.html`` file to view the " -"guide in web browser, but it's recommended to serve the guide using an HTTP " -"server." -msgstr "" -"Após a conclusão do processo, você pode encontrar a saída HTML no diretório " -"``./build/html``. Você pode abrir o arquivo ``index.html`` para ver o guia " -"no navegador web, mas é recomendado servir o guia usando um servidor HTTP." - -#: ../source/contribute.rst:100 -msgid "" -"You can build the guide and serve it via an HTTP server using the following " -"command::" -msgstr "" -"Você pode construir o guia e exibi-lo por meio de um servidor HTTP usando o " -"seguinte comando::" - -#: ../source/contribute.rst:105 -msgid "The guide will be browsable via http://localhost:8000." -msgstr "O guia poderá ser navegado em http://localhost:8000." - -#: ../source/contribute.rst:109 -msgid "Where the guide is deployed" -msgstr "Onde o guia é disponibilizado" - -#: ../source/contribute.rst:111 -msgid "" -"The guide is deployed via ReadTheDocs and the configuration lives at https://" -"readthedocs.org/projects/python-packaging-user-guide/. It's served from a " -"custom domain and fronted by Fast.ly." -msgstr "" -"O guia é disponibilizado via ReadTheDocs e a configuração está em https://" -"readthedocs.org/projects/python-packaging-user-guide/.. É servido a partir " -"de um domínio personalizado e guardado por Fast.ly." - -#: ../source/contribute.rst:117 -msgid "Style guide" -msgstr "Guia de estilo" - -#: ../source/contribute.rst:119 -msgid "" -"This style guide has recommendations for how you should write the |PyPUG|. " -"Before you start writing, please review it. By following the style guide, " -"your contributions will help add to a cohesive whole and make it easier for " -"your contributions to be accepted into the project." -msgstr "" -"Este guia de estilo contém recomendações de como você deve escrever o |" -"PyPUG|. Antes de começar a escrever, revise-o. Seguindo o guia de estilo, " -"suas contribuições ajudarão a formar um todo coeso e tornar mais fácil para " -"que suas contribuições sejam aceitas no projeto." - -#: ../source/contribute.rst:126 -msgid "Purpose" -msgstr "Propósito" - -#: ../source/contribute.rst:128 -msgid "" -"The purpose of the |PyPUG| is to be the authoritative resource on how to " -"package, publish, and install Python projects using current tools." -msgstr "" -"O objetivo do |PyPUG| é ser o recurso autorizado sobre como empacotar, " -"publicar e instalar projetos Python usando as ferramentas atuais." - -#: ../source/contribute.rst:133 -msgid "Scope" -msgstr "Escopo" - -#: ../source/contribute.rst:135 -msgid "" -"The guide is meant to answer questions and solve problems with accurate and " -"focused recommendations." -msgstr "" -"O guia destina-se a responder a perguntas e resolver problemas com " -"recomendações precisas e focadas." - -#: ../source/contribute.rst:138 -msgid "" -"The guide isn't meant to be comprehensive and it's not meant to replace " -"individual projects' documentation. For example, pip has dozens of commands, " -"options, and settings. The pip documentation describes each of them in " -"detail, while this guide describes only the parts of pip that are needed to " -"complete the specific tasks described in this guide." -msgstr "" -"O guia não pretende ser abrangente e não pretende substituir a documentação " -"de projetos individuais. Por exemplo, pip tem dezenas de comandos, opções e " -"configurações. A documentação do pip descreve cada um deles em detalhes, " -"enquanto este guia descreve apenas as partes do pip que são necessárias para " -"concluir as tarefas específicas descritas neste guia." - -#: ../source/contribute.rst:146 -msgid "Audience" -msgstr "Público-alvo" - -#: ../source/contribute.rst:148 -msgid "The audience of this guide is anyone who uses Python with packages." -msgstr "" -"O público-alvo deste guia é qualquer pessoa que use Python com pacotes." - -#: ../source/contribute.rst:150 -msgid "" -"Don't forget that the Python community is big and welcoming. Readers may not " -"share your age, gender, education, culture, and more, but they deserve to " -"learn about packaging just as much as you do." -msgstr "" -"Não se esqueça de que a comunidade Python é grande e acolhedora. Os leitores " -"podem não compartilhar sua idade, sexo, educação, cultura e muito mais, mas " -"eles merecem aprender sobre empacotamento tanto quanto você." - -#: ../source/contribute.rst:154 -msgid "" -"In particular, keep in mind that not all people who use Python see " -"themselves as programmers. The audience of this guide includes astronomers " -"or painters or students as well as professional software developers." -msgstr "" -"Em particular, tenha em mente que nem todas as pessoas que usam Python se " -"consideram programadores. O público deste guia inclui astrônomos, pintores " -"ou estudantes, bem como desenvolvedores de software profissionais." - -#: ../source/contribute.rst:160 -msgid "Voice and tone" -msgstr "Voz e tom" - -#: ../source/contribute.rst:162 -msgid "" -"When writing this guide, strive to write with a voice that's approachable " -"and humble, even if you have all the answers." -msgstr "" -"Ao escrever este guia, esforce-se para escrever com uma voz que seja " -"acessível e humilde, mesmo que você tenha todas as respostas." - -#: ../source/contribute.rst:165 -msgid "" -"Imagine you're working on a Python project with someone you know to be smart " -"and skilled. You like working with them and they like working with you. That " -"person has asked you a question and you know the answer. How do you respond? " -"*That* is how you should write this guide." -msgstr "" -"Imagine que você está trabalhando em um projeto Python com alguém que sabe " -"ser inteligente e habilidoso. Você gosta de trabalhar com eles e eles gostam " -"de trabalhar com você. Essa pessoa fez uma pergunta e você sabe a resposta. " -"Como você responde? *É assim* que você deve escrever este guia." - -#: ../source/contribute.rst:170 -msgid "" -"Here's a quick check: try reading aloud to get a sense for your writing's " -"voice and tone. Does it sound like something you would say or does it sound " -"like you're acting out a part or giving a speech? Feel free to use " -"contractions and don't worry about sticking to fussy grammar rules. You are " -"hereby granted permission to end a sentence in a preposition, if that's what " -"you want to end it with." -msgstr "" -"Aqui está uma verificação rápida: tente ler em voz alta para ter uma noção " -"da voz e do tom de sua escrita. Parece algo que você diria ou parece que " -"você está encenando um papel ou fazendo um discurso? Sinta-se à vontade para " -"usar contrações e não se preocupe em seguir regras gramaticais complicadas. " -"Você tem permissão para encerrar uma frase em uma preposição, se for assim " -"que deseja encerrá-la." - -#: ../source/contribute.rst:177 -msgid "" -"When writing the guide, adjust your tone for the seriousness and difficulty " -"of the topic. If you're writing an introductory tutorial, it's OK to make a " -"joke, but if you're covering a sensitive security recommendation, you might " -"want to avoid jokes altogether." -msgstr "" -"Ao escrever o guia, ajuste seu tom de acordo com a seriedade e a dificuldade " -"do tópico. Se você estiver escrevendo um tutorial introdutório, não há " -"problema em fazer uma piada, mas se estiver cobrindo uma recomendação de " -"segurança sensível, convém evitar piadas completamente." - -#: ../source/contribute.rst:184 -msgid "Conventions and mechanics" -msgstr "Convenções e mecânicas" - -#: ../source/contribute.rst:192 -msgid "**Write to the reader**" -msgstr "**Escreva para o leitor**" - -#: ../source/contribute.rst:187 -msgid "" -"When giving recommendations or steps to take, address the reader as *you* or " -"use the imperative mood." -msgstr "" -"Ao dar recomendações ou etapas a serem seguidas, dirija-se ao leitor como " -"*você* ou use o humor imperativo." - -#: ../source/contribute.rst:0 -msgid "Wrong: To install it, the user runs…" -msgstr "Errado: Para instalá-lo, o usuário executa…" - -#: ../source/contribute.rst:0 -msgid "Right: You can install it by running…" -msgstr "Certo: Você pode instalá-lo executando…" - -#: ../source/contribute.rst:0 -msgid "Right: To install it, run…" -msgstr "Certo: Para instalá-lo, execute…" - -#: ../source/contribute.rst:198 -msgid "**State assumptions**" -msgstr "**Presuma**" - -#: ../source/contribute.rst:195 -msgid "" -"Avoid making unstated assumptions. Reading on the web means that any page of " -"the guide may be the first page of the guide that the reader ever sees. If " -"you're going to make assumptions, then say what assumptions that you're " -"going to make." -msgstr "" -"Evite fazer suposições não declaradas. Ler na web significa que qualquer " -"página do guia pode ser a primeira página do guia que o leitor vê. Se você " -"vai fazer suposições, diga quais suposições você vai fazer." - -#: ../source/contribute.rst:203 -msgid "**Cross-reference generously**" -msgstr "**Faça uso generoso de referência cruzada**" - -#: ../source/contribute.rst:201 -msgid "" -"The first time you mention a tool or practice, link to the part of the guide " -"that covers it, or link to a relevant document elsewhere. Save the reader a " -"search." -msgstr "" -"Na primeira vez que você mencionar uma ferramenta ou prática, coloque um " -"link para a parte do guia que a cobre ou para um documento relevante em " -"outro lugar. Economize uma pesquisa ao leitor." - -#: ../source/contribute.rst:213 -msgid "**Respect naming practices**" -msgstr "**Respeite as práticas de nomenclatura**" - -#: ../source/contribute.rst:206 -msgid "" -"When naming tools, sites, people, and other proper nouns, use their " -"preferred capitalization." -msgstr "" -"Ao nomear ferramentas, sites, pessoas e outros nomes próprios, use a " -"capitalização de sua preferência." - -#: ../source/contribute.rst:0 -msgid "Wrong: Pip uses…" -msgstr "Errado: Pip usa…" - -#: ../source/contribute.rst:0 -msgid "Right: pip uses…" -msgstr "Certo: pip usa…" - -#: ../source/contribute.rst:0 -msgid "Wrong: …hosted on github." -msgstr "Errado: …hospedado no github." - -#: ../source/contribute.rst:0 -msgid "Right: …hosted on GitHub." -msgstr "Certo: …hospedado no GitHub." - -#: ../source/contribute.rst:222 -msgid "**Use a gender-neutral style**" -msgstr "**Use um estilo de gênero neutro**" - -#: ../source/contribute.rst:216 -msgid "" -"Often, you'll address the reader directly with *you*, *your* and *yours*. " -"Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or " -"avoid pronouns entirely." -msgstr "" -"Frequentemente, você se dirigirá ao leitor diretamente com *you*, *your* e " -"*yours*. Caso contrário, use pronomes de gênero neutro *they*, *their* e " -"*theirs* ou evite os pronomes completamente." - -#: ../source/contribute.rst:0 -msgid "Wrong: A maintainer uploads the file. Then he…" -msgstr "Errado: A maintainer uploads the file. Then he…" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then they…" -msgstr "Certo: A maintainer uploads the file. Then they…" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then the maintainer…" -msgstr "Certo: A maintainer uploads the file. Then the maintainer…" - -#: ../source/contribute.rst:234 -msgid "**Headings**" -msgstr "**Títulos**" - -#: ../source/contribute.rst:225 -msgid "" -"Write headings that use words the reader is searching for. A good way to do " -"this is to have your heading complete an implied question. For example, a " -"reader might want to know *How do I install MyLibrary?* so a good heading " -"might be *Install MyLibrary*." -msgstr "" -"Escreva títulos que usem palavras que o leitor esteja procurando. Uma boa " -"maneira de fazer isso é fazer com que o cabeçalho responda a uma pergunta " -"implícita. Por exemplo, um leitor pode querer saber *How do I install " -"MyLibrary?*, de forma que um bom título pode ser *Install MyLibrary*." - -#: ../source/contribute.rst:230 -msgid "" -"In section headings, use sentence case. In other words, write headings as " -"you would write a typical sentence." -msgstr "" -"Nos cabeçalhos das seções, use letras maiúsculas e minúsculas. Em outras " -"palavras, escreva os cabeçalhos da mesma forma que escreveria uma frase " -"típica." - -#: ../source/contribute.rst:0 -msgid "Wrong: Things You Should Know About Python" -msgstr "Errado: Things You Should Know About Python" - -#: ../source/contribute.rst:0 -msgid "Right: Things you should know about Python" -msgstr "Certo: Things you should know about Python" - -#: ../source/contribute.rst:237 -msgid "**Numbers**" -msgstr "**Números**" - -#: ../source/contribute.rst:237 -msgid "" -"In body text, write numbers one through nine as words. For other numbers or " -"numbers in tables, use numerals." -msgstr "" -"No corpo do texto, escreva os números de um a nove como palavras. Para " -"outros números ou números nas tabelas, use numerais." - -#: ../source/discussions/deploying-python-applications.rst:4 -msgid "Deploying Python applications" -msgstr "Fazendo deploy de aplicações Python" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Page Status" -msgstr "Status da página" - -#: ../source/discussions/deploying-python-applications.rst:6 -#: ../source/guides/index-mirrors-and-caches.rst:7 -#: ../source/guides/installing-using-linux-tools.rst:7 -#: ../source/guides/packaging-binary-extensions.rst:7 -#: ../source/guides/supporting-multiple-python-versions.rst:7 -#: ../source/guides/supporting-windows-using-appveyor.rst:5 -msgid "Incomplete" -msgstr "Incompleta" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Last Reviewed" -msgstr "Última revisão" - -#: ../source/discussions/deploying-python-applications.rst:7 -msgid "2014-11-11" -msgstr "2014-11-11" - -#: ../source/discussions/deploying-python-applications.rst:11 -#: ../source/discussions/install-requires-vs-requirements.rst:9 -#: ../source/guides/analyzing-pypi-package-downloads.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:22 -#: ../source/guides/index-mirrors-and-caches.rst:12 -#: ../source/guides/installing-scientific-packages.rst:9 -#: ../source/guides/packaging-binary-extensions.rst:17 -#: ../source/guides/supporting-multiple-python-versions.rst:12 -#: ../source/guides/supporting-windows-using-appveyor.rst:15 -#: ../source/overview.rst:23 ../source/specifications/core-metadata.rst:38 -#: ../source/specifications/direct-url.rst:14 -#: ../source/tutorials/installing-packages.rst:23 -msgid "Contents" -msgstr "Conteúdo" - -#: ../source/discussions/deploying-python-applications.rst:14 -msgid "Overview" -msgstr "Visão geral" - -#: ../source/discussions/deploying-python-applications.rst:18 -msgid "Supporting multiple hardware platforms" -msgstr "Oferecendo suporte a várias plataformas de hardware" - -#: ../source/discussions/deploying-python-applications.rst:40 -msgid "OS packaging & installers" -msgstr "Empacotamento de sistema operacional e instaladores" - -#: ../source/discussions/deploying-python-applications.rst:52 -msgid "Windows" -msgstr "Windows" - -#: ../source/discussions/deploying-python-applications.rst:61 -msgid "Pynsist" -msgstr "Pynsist" - -#: ../source/discussions/deploying-python-applications.rst:63 -msgid "" -"`Pynsist `__ is a tool that bundles Python " -"programs together with the Python-interpreter into a single installer based " -"on NSIS. In most cases, packaging only requires the user to choose a version " -"of the Python-interpreter and declare the dependencies of the program. The " -"tool downloads the specified Python-interpreter for Windows and packages it " -"with all the dependencies in a single Windows-executable installer." -msgstr "" -"`Pynsist `__ é uma ferramenta que agrupa " -"programas Python junto com o interpretador Python em um único instalador " -"baseado em NSIS. Na maioria dos casos, o empacotamento requer apenas que o " -"usuário escolha uma versão do interpretador Python e declare as dependências " -"do programa. A ferramenta baixa o interpretador Python especificado para " -"Windows e o empacota com todas as dependências em um único instalador " -"executável do Windows." - -#: ../source/discussions/deploying-python-applications.rst:70 -msgid "" -"The installed program can be started from a shortcut that the installer adds " -"to the start-menu. It uses a Python interpreter installed within its " -"application directory, independent of any other Python installation on the " -"computer." -msgstr "" -"O programa instalado pode ser iniciado a partir de um atalho que o " -"instalador adiciona ao menu iniciar. Ele usa um interpretador Python " -"instalado em seu diretório de aplicação, independente de qualquer outra " -"instalação Python no computador." - -#: ../source/discussions/deploying-python-applications.rst:74 -msgid "" -"A big advantage of Pynsist is that the Windows packages can be built on " -"Linux. There are several examples for different kinds of programs (console, " -"GUI) in the `documentation `__. The tool is " -"released under the MIT-licence." -msgstr "" -"Uma grande vantagem do Pynsist é que os pacotes do Windows podem ser " -"construídos no Linux. Existem vários exemplos para diferentes tipos de " -"programas (console, GUI) na `documentação `__. A ferramenta é lançada sob a licença do MIT." - -#: ../source/discussions/deploying-python-applications.rst:80 -msgid "Application bundles" -msgstr "Pacotes de aplicações" - -#: ../source/discussions/deploying-python-applications.rst:91 -msgid "Configuration management" -msgstr "Gerenciamento de configuração" - -#: ../source/discussions/index.rst:4 -msgid "" -"**Discussions** are focused on providing comprehensive information about a " -"specific topic. If you're just trying to get stuff done, see :doc:`/guides/" -"index`." -msgstr "" -"**Discussões** têm como objetivo fornecer informações abrangentes sobre um " -"tópico específico. Se você está apenas tentando fazer as coisas, veja :doc:`/" -"guides/index`." - -#: ../source/discussions/install-requires-vs-requirements.rst:5 -msgid "install_requires vs requirements files" -msgstr "install_requires vs arquivos requirements" - -#: ../source/discussions/install-requires-vs-requirements.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:382 -msgid "install_requires" -msgstr "install_requires" - -#: ../source/discussions/install-requires-vs-requirements.rst:14 -msgid "" -"``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that " -"should be used to specify what a project **minimally** needs to run " -"correctly. When the project is installed by :ref:`pip`, this is the " -"specification that is used to install its dependencies." -msgstr "" -"``install_requires`` é uma palavra-chave de :file:`setup.py` do :ref:" -"`setuptools` que deve ser usada para especificar o que um projeto " -"**minimamente** precisa para executar corretamente. Quando o projeto é " -"instalado por :ref:`pip`, esta é a especificação que é usada para instalar " -"suas dependências." - -#: ../source/discussions/install-requires-vs-requirements.rst:19 -msgid "" -"For example, if the project requires A and B, your ``install_requires`` " -"would be like so:" -msgstr "" -"Por exemplo, se o projeto requer A e B, seu ``install_requires`` seria assim:" - -#: ../source/discussions/install-requires-vs-requirements.rst:29 -msgid "" -"Additionally, it's best practice to indicate any known lower or upper bounds." -msgstr "" -"Além disso, é uma prática recomendada indicar qualquer limite inferior ou " -"superior conhecido." - -#: ../source/discussions/install-requires-vs-requirements.rst:31 -msgid "" -"For example, it may be known, that your project requires at least v1 of 'A', " -"and v2 of 'B', so it would be like so:" -msgstr "" -"Por exemplo, pode-se saber que seu projeto requer pelo menos v1 de \"A\" e " -"v2 de \"B\", então seria assim:" - -#: ../source/discussions/install-requires-vs-requirements.rst:41 -msgid "" -"It may also be known that project A follows semantic versioning, and that v2 " -"of 'A' will indicate a break in compatibility, so it makes sense to not " -"allow v2:" -msgstr "" -"Também pode ser sabido que o projeto A segue versionamento semântico, e que " -"a v2 de \"A\" irá indicar uma quebra na compatibilidade, então faz sentido " -"não permitir a v2:" - -#: ../source/discussions/install-requires-vs-requirements.rst:51 -msgid "" -"It is not considered best practice to use ``install_requires`` to pin " -"dependencies to specific versions, or to specify sub-dependencies (i.e. " -"dependencies of your dependencies). This is overly-restrictive, and " -"prevents the user from gaining the benefit of dependency upgrades." -msgstr "" -"Não é considerada a melhor prática usar ``install_requires`` para fixar " -"dependências em versões específicas, ou para especificar subdependências (ou " -"seja, dependências de suas dependências). Isso é excessivamente restritivo e " -"evita que o usuário obtenha o benefício de atualizações de dependência." - -#: ../source/discussions/install-requires-vs-requirements.rst:56 -msgid "" -"Lastly, it's important to understand that ``install_requires`` is a listing " -"of \"Abstract\" requirements, i.e just names and version restrictions that " -"don't determine where the dependencies will be fulfilled from (i.e. from " -"what index or source). The where (i.e. how they are to be made \"Concrete" -"\") is to be determined at install time using :ref:`pip` options. [1]_" -msgstr "" -"Por último, é importante entender que ``install_requires`` é uma lista de " -"requisitos \"abstratos\", ou seja, apenas nomes e restrições de versão que " -"não determinam de onde as dependências serão preenchidas (ou seja, de qual " -"índice ou fonte). O local (ou seja, como eles devem ser feitos de \"concreto" -"\") deve ser determinado no momento da instalação usando as opções :ref:" -"`pip`. [1]_" - -#: ../source/discussions/install-requires-vs-requirements.rst:64 -#: ../source/tutorials/installing-packages.rst:460 -msgid "Requirements files" -msgstr "Arquivos de requisitos" - -#: ../source/discussions/install-requires-vs-requirements.rst:66 -msgid "" -":ref:`Requirements Files ` described most simply, " -"are just a list of :ref:`pip:pip install` arguments placed into a file." -msgstr "" -":ref:`Arquivos de requisitos ` descritos de forma " -"mais simples, são apenas uma lista de argumentos :ref:`pip:pip install` " -"colocados em um arquivo." - -#: ../source/discussions/install-requires-vs-requirements.rst:69 -msgid "" -"Whereas ``install_requires`` defines the dependencies for a single project, :" -"ref:`Requirements Files ` are often used to define " -"the requirements for a complete Python environment." -msgstr "" -"Considerando que ``install_requires`` define as dependências para um único " -"projeto, :ref:`arquivos de requisitos ` são " -"frequentemente usados para definir os requisitos para um ambiente Python " -"completo." - -#: ../source/discussions/install-requires-vs-requirements.rst:73 -msgid "" -"Whereas ``install_requires`` requirements are minimal, requirements files " -"often contain an exhaustive listing of pinned versions for the purpose of " -"achieving :ref:`repeatable installations ` of a complete " -"environment." -msgstr "" -"Considerando que os requisitos de ``install_requires`` são mínimos, os " -"arquivos de requisitos frequentemente contêm uma lista exaustiva de versões " -"fixadas com o propósito de alcançar :ref:`instalações repetíveis ` de um ambiente completo." - -#: ../source/discussions/install-requires-vs-requirements.rst:78 -msgid "" -"Whereas ``install_requires`` requirements are \"Abstract\", i.e. not " -"associated with any particular index, requirements files often contain pip " -"options like ``--index-url`` or ``--find-links`` to make requirements " -"\"Concrete\", i.e. associated with a particular index or directory of " -"packages. [1]_" -msgstr "" -"Considerando que os requisitos de ``install_requires`` são \"abstratos\", ou " -"seja, não estão associados a nenhum índice em particular, os arquivos de " -"requisitos geralmente contêm opções de pip como ``--index-url`` ou ``--find-" -"links`` para fazer requisitos \"concreto \", isto é, associado a um " -"determinado índice ou diretório de pacotes. [1]_" - -#: ../source/discussions/install-requires-vs-requirements.rst:84 -msgid "" -"Whereas ``install_requires`` metadata is automatically analyzed by pip " -"during an install, requirements files are not, and only are used when a user " -"specifically installs them using ``python -m pip install -r``." -msgstr "" -"Enquanto os metadados ``install_requires`` são automaticamente analisados " -"pelo pip durante uma instalação, os arquivos de requisitos não são, e são " -"usados apenas quando um usuário os instala especificamente usando ``python -" -"m pip install -r``." - -#: ../source/discussions/install-requires-vs-requirements.rst:90 -msgid "" -"For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad." -"io/2013/07/setup-vs-requirement/." -msgstr "" -"Para obter mais informações sobre os requisitos \"abstratos\" vs \"concretos" -"\", consulte https://caremad.io/2013/07/setup-vs-requirement/." - -#: ../source/discussions/pip-vs-easy-install.rst:6 -msgid "pip vs easy_install" -msgstr "pip vs easy_install" - -#: ../source/discussions/pip-vs-easy-install.rst:9 -msgid "" -":ref:`easy_install `, now `deprecated`_, was released in 2004 " -"as part of :ref:`setuptools`. It was notable at the time for installing :" -"term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing " -"dependencies." -msgstr "" -":ref:`easy_install `, agora `descontinuado `_, foi " -"lançado em 2004 como parte do :ref:`setuptools`. Era notável na época para " -"instalar :term:`pacotes ` do :term:`PyPI ` usando especificadores de requisitos e instalando " -"dependências automaticamente." - -#: ../source/discussions/pip-vs-easy-install.rst:14 -msgid "" -":ref:`pip` came later in 2008, as alternative to :ref:`easy_install " -"`, although still largely built on top of :ref:`setuptools` " -"components. It was notable at the time for *not* installing packages as :" -"term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' " -"packages from :term:`sdists `), and " -"introducing the idea of :ref:`Requirements Files `, " -"which gave users the power to easily replicate environments." -msgstr "" -"O :ref:`pip` veio mais tarde em 2008, como alternativa ao :ref:`easy_install " -"`, embora ainda amplamente construído sobre os componentes :" -"ref:`setuptools`. Era notável na época por *não* instalar pacotes como :term:" -"`Eggs ` ou de :term:`Eggs ` (mas simplesmente como pacotes \"planos" -"\" de :term:`sdists `), e introduzindo a " -"ideia de :ref:`Arquivos de Requisitos `, que deu aos " -"usuários o poder de replicar ambientes facilmente." - -#: ../source/discussions/pip-vs-easy-install.rst:22 -msgid "" -"Here's a breakdown of the important differences between pip and the " -"deprecated easy_install:" -msgstr "" -"Aqui está uma análise das diferenças importantes entre o pip e o " -"descontinuado easy_install:" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**pip**" -msgstr "**pip**" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**easy_install**" -msgstr "**easy_install**" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -msgid "Installs from :term:`Wheels `" -msgstr "Instala de :term:`Wheels `" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Yes" -msgstr "Sim" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:30 -#: ../source/discussions/pip-vs-easy-install.rst:32 -#: ../source/discussions/pip-vs-easy-install.rst:35 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:51 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "No" -msgstr "Não" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Uninstall Packages" -msgstr "Desinstala pacotes" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Yes (``python -m pip uninstall``)" -msgstr "Sim (``python -m pip uninstall``)" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Dependency Overrides" -msgstr "Substitui dependências" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Yes (:ref:`Requirements Files `)" -msgstr "Sim (:ref:`Arquivo de Requisitos `)" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "List Installed Packages" -msgstr "Lista pacotes instalados" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" -msgstr "Sim (``python -m pip list`` e ``python -m pip freeze``)" - -#: ../source/discussions/pip-vs-easy-install.rst:38 -msgid ":pep:`438` Support" -msgstr "Suporte a :pep:`438`" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Installation format" -msgstr "Formato de instalação" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "'Flat' packages with :file:`egg-info` metadata." -msgstr "Pacotes \"planos\" com metadados de :file:`egg-info`." - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Encapsulated Egg format" -msgstr "Formato Egg encapsulado" - -#: ../source/discussions/pip-vs-easy-install.rst:44 -msgid "sys.path modification" -msgstr "Modificação de sys.path" - -#: ../source/discussions/pip-vs-easy-install.rst:48 -msgid "Installs from :term:`Eggs `" -msgstr "Instala de :term:`Eggs `" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "`pylauncher support`_" -msgstr "`suporte a pylauncher `_" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "Yes [1]_" -msgstr "Sim [1]_" - -#: ../source/discussions/pip-vs-easy-install.rst:54 -msgid ":ref:`Multi-version Installs`" -msgstr ":ref:`Instalações multiversões `" - -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Exclude scripts during install" -msgstr "Exclui scripts durante a instalação" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "per project index" -msgstr "índice por projeto" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Only in virtualenv" -msgstr "Apenas em virtualenv" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Yes, via setup.cfg" -msgstr "Sim, via setup.cfg" - -#: ../source/discussions/pip-vs-easy-install.rst:68 -msgid "" -"https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" -"launcher" -msgstr "" -"https://setuptools.readthedocs.io/en/latest/deprecated/easy_install." -"html#natural-script-launcher" - -#: ../source/discussions/wheel-vs-egg.rst:5 -msgid "Wheel vs Egg" -msgstr "Wheel vs Egg" - -#: ../source/discussions/wheel-vs-egg.rst:7 -msgid "" -":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support " -"the use case of needing an install artifact that doesn't require building or " -"compilation, which can be costly in testing and production workflows." -msgstr "" -":term:`Wheel` e :term:`Egg` são formatos de empacotamento que visam oferecer " -"suporte ao caso de uso de necessidade de um artefato de instalação que não " -"requer construção ou compilação, o que pode ser caro em testes e fluxos de " -"trabalho de produção." - -#: ../source/discussions/wheel-vs-egg.rst:11 -msgid "" -"The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas " -"the :term:`Wheel` format was introduced by :pep:`427` in 2012." -msgstr "" -"O formato :term:`Egg` foi introduzido por :ref:`setuptools` em 2004, " -"enquanto o formato :term:`Wheel` foi introduzido pela :pep:`427` em 2012." - -#: ../source/discussions/wheel-vs-egg.rst:14 -msgid "" -":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." -msgstr "" -":term:`Wheel` é atualmente considerado o padrão para o empacotamento :term:" -"`contruído ` e :term:`binário ` " -"para Python." - -#: ../source/discussions/wheel-vs-egg.rst:17 -msgid "" -"Here's a breakdown of the important differences between :term:`Wheel` and :" -"term:`Egg`." -msgstr "" -"Aqui está uma análise das diferenças importantes entre :term:`Wheel` e :term:" -"`Egg`." - -#: ../source/discussions/wheel-vs-egg.rst:20 -msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." -msgstr ":term:`Wheel` tem uma :pep:`PEP oficial <427>`. :term:`Egg` não tinha." - -#: ../source/discussions/wheel-vs-egg.rst:22 -msgid "" -":term:`Wheel` is a :term:`distribution ` format, i.e a " -"packaging format. [1]_ :term:`Egg` was both a distribution format and a " -"runtime installation format (if left zipped), and was designed to be " -"importable." -msgstr "" -":term:`Wheel` é um formato de :term:`distribuição `, " -"ou seja, um formato de empacotamento. [1]_ :term:`Egg` era um formato de " -"distribuição e um formato de instalação em tempo de execução (se deixado " -"compactado), e foi projetado para ser importável." - -#: ../source/discussions/wheel-vs-egg.rst:26 -msgid "" -":term:`Wheel` archives do not include .pyc files. Therefore, when the " -"distribution only contains Python files (i.e. no compiled extensions), and " -"is compatible with Python 2 and 3, it's possible for a wheel to be " -"\"universal\", similar to an :term:`sdist `." -msgstr "" -"Os arquivos :term:`Wheel` não incluem arquivos .pyc. Portanto, quando a " -"distribuição contém apenas arquivos Python (ou seja, sem extensões " -"compiladas) e é compatível com Python 2 e 3, é possível que um wheel seja " -"\"universal\", semelhante a um :term:`sdist `." - -#: ../source/discussions/wheel-vs-egg.rst:31 -msgid "" -":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. " -"Egg used ``.egg-info``." -msgstr "" -":term:`Wheel` usa diretórios ``.dist-info`` :pep:`compatíveis com a PEP376 " -"<376>`. Egg usava ``.egg-info``." - -#: ../source/discussions/wheel-vs-egg.rst:34 -msgid "" -":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single " -"wheel archive can indicate its compatibility with a number of Python " -"language versions and implementations, ABIs, and system architectures." -msgstr "" -":term:`Wheel` tem uma :pep:`convenção de nomenclatura de arquivo mais rica " -"<425>`. Um único arquivo de wheel pode indicar sua compatibilidade com " -"várias versões e implementações da linguagem Python, ABIs e arquiteturas de " -"sistema." - -#: ../source/discussions/wheel-vs-egg.rst:38 -msgid "" -":term:`Wheel` is versioned. Every wheel file contains the version of the " -"wheel specification and the implementation that packaged it." -msgstr "" -":term:`Wheel` é versionado. Cada arquivo wheel contém a versão da " -"especificação wheel e a implementação que a empacotou." - -#: ../source/discussions/wheel-vs-egg.rst:41 -msgid "" -":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making " -"it easier to convert to other formats." -msgstr "" -":term:`Wheel` é internamente organizado pelo `tipo de caminho sysconfig " -"`_, " -"portanto tornando mais fácil converter para outros formatos." - -#: ../source/discussions/wheel-vs-egg.rst:47 -msgid "" -"Circumstantially, in some cases, wheels can be used as an importable runtime " -"format, although :pep:`this is not officially supported at this time <427#is-" -"it-possible-to-import-python-code-directly-from-a-wheel-file>`." -msgstr "" -"Circunstancialmente, em alguns casos, wheels podem ser usados como um " -"formato de tempo de execução importável, embora :pep:`não haja suporte " -"oficial a isso no momento <427#is-it-possible-to-import-python-code-directly-" -"from-a-wheel-file>`." - -#: ../source/glossary.rst:3 -msgid "Glossary" -msgstr "Glossário" - -#: ../source/glossary.rst:8 -msgid "Binary Distribution" -msgstr "Distribuição Binária" - -#: ../source/glossary.rst:11 -msgid "" -"A specific kind of :term:`Built Distribution` that contains compiled " -"extensions." -msgstr "" -"Um tipo específico de :term:`Distribuição Construída` que contém extensões " -"compiladas." - -#: ../source/glossary.rst:14 -msgid "Built Distribution" -msgstr "Distribuição Construída" - -#: ../source/glossary.rst:17 -msgid "" -"A :term:`Distribution ` format containing files and " -"metadata that only need to be moved to the correct location on the target " -"system, to be installed. :term:`Wheel` is such a format, whereas distutil's :" -"term:`Source Distribution ` is not, in " -"that it requires a build step before it can be installed. This format does " -"not imply that Python files have to be precompiled (:term:`Wheel` " -"intentionally does not include compiled Python files)." -msgstr "" -"Um formato de :term:`Distribuição ` contendo arquivos " -"e metadados que só precisam ser movidos para o local correto no sistema de " -"destino, para serem instalados. :term:`Wheel` é esse formato, enquanto o :" -"term:`Distribuição Fonte ` do distutil " -"não é, pois requer uma etapa de construção antes de poder ser instalado. " -"Este formato não implica que os arquivos Python tenham que ser pré-" -"compilados (:term:`Wheel` intencionalmente não inclui arquivos Python " -"compilados)." - -#: ../source/glossary.rst:26 -msgid "Distribution Package" -msgstr "Pacote de Distribuição" - -#: ../source/glossary.rst:29 -msgid "" -"A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used " -"to distribute a :term:`Release`. The archive file is what an end-user will " -"download from the internet and install." -msgstr "" -"Um arquivo com versão que contém :term:`pacotes ` Python, :" -"term:`módulos `, e outros arquivos de recursos que são usados para " -"distribuir um :term:`Release` (lançamento). O arquivo é o que um usuário " -"final irá baixar da Internet e instalar." - -#: ../source/glossary.rst:34 -msgid "" -"A distribution package is more commonly referred to with the single words " -"\"package\" or \"distribution\", but this guide may use the expanded term " -"when more clarity is needed to prevent confusion with an :term:`Import " -"Package` (which is also commonly called a \"package\") or another kind of " -"distribution (e.g. a Linux distribution or the Python language " -"distribution), which are often referred to with the single term " -"\"distribution\"." -msgstr "" -"Um pacote de distribuição é mais comumente referido com as palavras \"pacote" -"\" ou \"distribuição\", mas este guia pode usar o termo expandido quando " -"mais clareza for necessária para evitar confusão com um :term:`Pacote de " -"Importação` (que também é comumente chamado de \"pacote\") ou outro tipo de " -"distribuição (por exemplo, uma distribuição Linux ou a distribuição da " -"linguagem Python), que são frequentemente referidos com o único termo " -"\"distribuição\"." - -#: ../source/glossary.rst:41 -msgid "Egg" -msgstr "Egg" - -#: ../source/glossary.rst:44 -msgid "" -"A :term:`Built Distribution` format introduced by :ref:`setuptools`, which " -"is being replaced by :term:`Wheel`. For details, see `The Internal " -"Structure of Python Eggs `_ and `Python Eggs `_" -msgstr "" -"Um formato :term:`Distribuição Construída` introduzido por :ref:" -"`setuptools`, que está sendo substituído por :term:`Wheel`. Para obter " -"detalhes, consulte `The Internal Structure of Python Eggs `_ e `Python " -"Eggs `_" - -#: ../source/glossary.rst:49 -msgid "Extension Module" -msgstr "Módulo de Extensão" - -#: ../source/glossary.rst:52 -msgid "" -"A :term:`Module` written in the low-level language of the Python " -"implementation: C/C++ for Python, Java for Jython. Typically contained in a " -"single dynamically loadable pre-compiled file, e.g. a shared object (.so) " -"file for Python extensions on Unix, a DLL (given the .pyd extension) for " -"Python extensions on Windows, or a Java class file for Jython extensions." -msgstr "" -"Um :term:`Módulo` escrito na linguagem de baixo nível da implementação " -"Python: C/C++ para Python, Java para Jython. Normalmente contido em um único " -"arquivo pré-compilado carregável dinamicamente, por exemplo, um arquivo de " -"objeto compartilhado (.so) para extensões Python no Unix, uma DLL (dada a " -"extensão .pyd) para extensões Python no Windows ou um arquivo de classe Java " -"para extensões Jython." - -#: ../source/glossary.rst:59 -msgid "Known Good Set (KGS)" -msgstr "Known Good Set (KGS)" - -#: ../source/glossary.rst:62 -msgid "" -"A set of distributions at specified versions which are compatible with each " -"other. Typically a test suite will be run which passes all tests before a " -"specific set of packages is declared a known good set. This term is commonly " -"used by frameworks and toolkits which are comprised of multiple individual " -"distributions." -msgstr "" -"Um conjunto de distribuições em versões especificadas que são compatíveis " -"entre si. Normalmente, será executado um conjunto de testes que passa em " -"todos os testes antes que um conjunto específico de pacotes seja declarado " -"como um conjunto sabidamente bom (*known good set*). Este termo é comumente " -"usado por frameworks e kits de ferramentas que são compostos de várias " -"distribuições individuais." - -#: ../source/glossary.rst:68 -msgid "Import Package" -msgstr "Pacote de Importação" - -#: ../source/glossary.rst:71 -msgid "" -"A Python module which can contain other modules or recursively, other " -"packages." -msgstr "" -"Um módulo Python que pode conter outros módulos ou recursivamente, outros " -"pacotes." - -#: ../source/glossary.rst:74 -msgid "" -"An import package is more commonly referred to with the single word \"package" -"\", but this guide will use the expanded term when more clarity is needed to " -"prevent confusion with a :term:`Distribution Package` which is also commonly " -"called a \"package\"." -msgstr "" -"Um pacote de importação é mais comumente referido com a única palavra " -"\"pacote\", mas este guia usará o termo expandido quando mais clareza for " -"necessária para evitar confusão com um :term:`Pacote de Distribuição` que " -"também é comumente chamado de \"pacote\" ." - -#: ../source/glossary.rst:78 -msgid "Module" -msgstr "Módulo" - -#: ../source/glossary.rst:81 -msgid "" -"The basic unit of code reusability in Python, existing in one of two types: :" -"term:`Pure Module`, or :term:`Extension Module`." -msgstr "" -"A unidade básica de reutilização de código em Python, existindo em um dos " -"dois tipos: :term:`Módulo Puro` ou :term:`Módulo de Extensão`." - -#: ../source/glossary.rst:84 -msgid "Package Index" -msgstr "Índice de Pacotes" - -#: ../source/glossary.rst:87 -msgid "" -"A repository of distributions with a web interface to automate :term:" -"`package ` discovery and consumption." -msgstr "" -"Um repositório de distribuições com uma interface web para automatizar " -"descoberta e consumo de :term:`pacotes `." - -#: ../source/glossary.rst:90 -msgid "Per Project Index" -msgstr "Índice Por Projeto" - -#: ../source/glossary.rst:93 -msgid "" -"A private or other non-canonical :term:`Package Index` indicated by a " -"specific :term:`Project` as the index preferred or required to resolve " -"dependencies of that project." -msgstr "" -"Um :term:`Índice de Pacotes` privado ou outro não canônico indicado por um :" -"term:`Projeto` específico como o índice preferido ou necessário para " -"resolver dependências desse projeto." - -#: ../source/glossary.rst:97 -msgid "Project" -msgstr "Projeto" - -#: ../source/glossary.rst:100 -msgid "" -"A library, framework, script, plugin, application, or collection of data or " -"other resources, or some combination thereof that is intended to be packaged " -"into a :term:`Distribution `." -msgstr "" -"Uma biblioteca, estrutura, script, plugin, aplicação ou coleção de dados ou " -"outros recursos, ou alguma combinação dos mesmos que se destina a ser " -"empacotado em uma :term:`Distribuição `." - -#: ../source/glossary.rst:104 -msgid "" -"Since most projects create :term:`Distributions ` " -"using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:" -"`setuptools`, another practical way to define projects currently is " -"something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:" -"`setup.cfg` file at the root of the project source directory." -msgstr "" -"Como a maioria dos projetos cria :term:`Distribuições ` usando ``build-system`` da :pep:`518`, :ref:`distutils` ou :ref:" -"`setuptools`, outra maneira prática de definir projetos atualmente é algo " -"que contém um arquivo :term:`pyproject.toml`, :term:`setup.py` ou :term:" -"`setup.cfg` na raiz do diretório fonte do projeto." - -#: ../source/glossary.rst:110 -msgid "" -"Python projects must have unique names, which are registered on :term:`PyPI " -"`. Each project will then contain one or more :" -"term:`Releases `, and each release may comprise one or more :term:" -"`distributions `." -msgstr "" -"Projetos Python devem ter nomes únicos, que são registrados no :term:`PyPI " -"`. Cada projeto conterá então um ou mais :term:" -"`Lançamentos `, e cada lançamento pode incluir uma ou mais :term:" -"`distribuições `." - -#: ../source/glossary.rst:115 -msgid "" -"Note that there is a strong convention to name a project after the name of " -"the package that is imported to run that project. However, this doesn't have " -"to hold true. It's possible to install a distribution from the project 'foo' " -"and have it provide a package importable only as 'bar'." -msgstr "" -"Observe que há uma forte convenção para dar o nome do projeto ao pacote que " -"é importado para executar esse projeto. No entanto, isso não é obrigatório. " -"É possível instalar uma distribuição do projeto \"foo\" e fazer com que ele " -"forneça um pacote importável apenas como \"bar\"." - -#: ../source/glossary.rst:121 -msgid "Pure Module" -msgstr "Módulo Puro" - -#: ../source/glossary.rst:124 -msgid "" -"A :term:`Module` written in Python and contained in a single ``.py`` file " -"(and possibly associated ``.pyc`` and/or ``.pyo`` files)." -msgstr "" -"Um :term:`Módulo` escrito em Python e contido em um único arquivo ``.py`` (e " -"possivelmente arquivos ``.pyc`` e/ou ``.pyo`` associados)." - -#: ../source/glossary.rst:127 -msgid "Python Packaging Authority (PyPA)" -msgstr "Python Packaging Authority (PyPA)" - -#: ../source/glossary.rst:130 -msgid "" -"PyPA is a working group that maintains many of the relevant projects in " -"Python packaging. They maintain a site at https://www.pypa.io, host projects " -"on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python " -"Discourse forum `__." -msgstr "" -"PyPA é um grupo de trabalho que mantém muitos dos projetos relevantes em " -"pacotes Python. Eles mantêm um site em https://www.pypa.io, hospedam " -"projetos no `GitHub `_ e `Bitbucket `_, e discutem questões na `lista de discussão distutils-" -"sig `_ e " -"`o fórum Discourse do Python `__." - -#: ../source/glossary.rst:139 -msgid "Python Package Index (PyPI)" -msgstr "Python Package Index (PyPI)" - -#: ../source/glossary.rst:142 -msgid "" -"`PyPI `_ is the default :term:`Package Index` for the " -"Python community. It is open to all Python developers to consume and " -"distribute their distributions." -msgstr "" -"`PyPI `_ é o :term:`Índice de Pacotes` padrão para a " -"comunidade Python. Está aberto a todos os desenvolvedores Python para " -"consumir e distribuir suas distribuições." - -#: ../source/glossary.rst:145 -msgid "pypi.org" -msgstr "pypi.org" - -#: ../source/glossary.rst:148 -msgid "" -"`pypi.org `_ is the domain name for the :term:`Python " -"Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi." -"python.org``, in 2017. It is powered by :ref:`warehouse`." -msgstr "" -"`pypi.org `_ é o nome de domínio do :term:`Python Package " -"Index (PyPI)`. Ele substituiu o nome de domínio do índice legado, ``pypi." -"python.org``, em 2017. Ele é tornado possível pelo :ref:`warehouse`." - -#: ../source/glossary.rst:152 -msgid "pyproject.toml" -msgstr "pyproject.toml" - -#: ../source/glossary.rst:155 -msgid "" -"The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." -msgstr "" -"O arquivo de especificação agnóstica de ferramenta para :term:`Projetos " -"`. Definido na :pep:`518`." - -#: ../source/glossary.rst:157 -msgid "Release" -msgstr "Lançamento" - -#: ../source/glossary.rst:160 -msgid "" -"A snapshot of a :term:`Project` at a particular point in time, denoted by a " -"version identifier." -msgstr "" -"Um snapshot de um :term:`Projeto` em um determinado ponto no tempo, denotado " -"por um identificador de versão." - -#: ../source/glossary.rst:163 -msgid "" -"Making a release may entail the publishing of multiple :term:`Distributions " -"`. For example, if version 1.0 of a project was " -"released, it could be available in both a source distribution format and a " -"Windows installer distribution format." -msgstr "" -"Fazer um lançamento pode implicar na publicação de várias :term:" -"`Distribuições `. Por exemplo, se a versão 1.0 de um " -"projeto foi lançada, ele pode estar disponível em um formato de distribuição " -"fonte e um formato de distribuição de instalador do Windows." - -#: ../source/glossary.rst:168 -msgid "Requirement" -msgstr "Requisito" - -#: ../source/glossary.rst:171 -msgid "" -"A specification for a :term:`package ` to be " -"installed. :ref:`pip`, the :term:`PYPA ` " -"recommended installer, allows various forms of specification that can all be " -"considered a \"requirement\". For more information, see the :ref:`pip:pip " -"install` reference." -msgstr "" -"Uma especificação para um :term:`pacote ` a ser " -"instalado. :ref:`pip`, o instalador recomendado do :term:`PYPA `, permite várias formas de especificação que " -"podem ser consideradas um \"requisito\". Para obter mais informações, " -"consulte a referência de :ref:`pip:pip install`." - -#: ../source/glossary.rst:177 -msgid "Requirement Specifier" -msgstr "Especificador de Requisitos" - -#: ../source/glossary.rst:180 -msgid "" -"A format used by :ref:`pip` to install packages from a :term:`Package " -"Index`. For an EBNF diagram of the format, see the `pkg_resources." -"Requirement `_ entry in the :ref:`setuptools` docs. For " -"example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the " -"project name, and the \">=1.3\" portion is the :term:`Version Specifier`" -msgstr "" -"Um formato usado por :ref:`pip` para instalar pacotes de um :term:`Índice de " -"Pacotes`. Para um diagrama EBNF do formato, veja a entrada `pkg_resources." -"Requirement `_ na documentação do :ref:`setuptools`. Por " -"exemplo, \"foo>=1.3\" é um especificador de requisitos, onde \"foo\" é o " -"nome do projeto e a parte \">=1.3\" é o :term:`Especificador de Versão`" - -#: ../source/glossary.rst:187 -msgid "Requirements File" -msgstr "Arquivo de Requisitos" - -#: ../source/glossary.rst:190 -msgid "" -"A file containing a list of :term:`Requirements ` that can be " -"installed using :ref:`pip`. For more information, see the :ref:`pip` docs " -"on :ref:`pip:Requirements Files`." -msgstr "" -"Um arquivo contendo uma lista de :term:`Requisitos ` que podem " -"ser instalados usando :ref:`pip`. Para mais informações, veja a " -"documentação :ref:`pip` em :ref:`pip:Requirements Files`." - -#: ../source/glossary.rst:194 -#: ../source/guides/distributing-packages-using-setuptools.rst:56 -msgid "setup.py" -msgstr "setup.py" - -#: ../source/glossary.rst:195 -#: ../source/guides/distributing-packages-using-setuptools.rst:77 -msgid "setup.cfg" -msgstr "setup.cfg" - -#: ../source/glossary.rst:198 -msgid "" -"The project specification files for :ref:`distutils` and :ref:`setuptools`. " -"See also :term:`pyproject.toml`." -msgstr "" -"Os arquivos de especificação do projeto para :ref:`distutils` e :ref:" -"`setuptools`. Veja também:term:`pyproject.toml`." - -#: ../source/glossary.rst:201 -msgid "Source Archive" -msgstr "Arquivo Fonte" - -#: ../source/glossary.rst:204 -msgid "" -"An archive containing the raw source code for a :term:`Release`, prior to " -"creation of a :term:`Source Distribution ` or :term:`Built Distribution`." -msgstr "" -"Um arquivo contendo o código-fonte bruto para um :term:`Lançamento " -"`, antes da criação de uma :term:`Distribuição Fonte ` ou :term:`Distribuição Construída `." - -#: ../source/glossary.rst:208 -msgid "Source Distribution (or \"sdist\")" -msgstr "Distribuição Fonte (ou \"sdist\")" - -#: ../source/glossary.rst:211 -msgid "" -"A :term:`distribution ` format (usually generated " -"using ``python setup.py sdist``) that provides metadata and the essential " -"source files needed for installing by a tool like :ref:`pip`, or for " -"generating a :term:`Built Distribution`." -msgstr "" -"Um formato de :term:`distribuição ` (geralmente gerado " -"usando ``python setup.py sdist``) que fornece metadados e os arquivos-fonte " -"essenciais necessários para a instalação por uma ferramenta como :ref:`pip`, " -"ou para gerar uma :term:`Distribuição Construída `." - -#: ../source/glossary.rst:216 -msgid "System Package" -msgstr "Pacote de Sistemas" - -#: ../source/glossary.rst:219 -msgid "" -"A package provided in a format native to the operating system, e.g. an rpm " -"or dpkg file." -msgstr "" -"Um pacote fornecido em um formato nativo para o sistema operacional, por " -"exemplo, um arquivo rpm ou dpkg." - -#: ../source/glossary.rst:222 -msgid "Version Specifier" -msgstr "Especificador de Versão" - -#: ../source/glossary.rst:225 -msgid "" -"The version component of a :term:`Requirement Specifier`. For example, the " -"\">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full " -"specification <440#version-specifiers>` of the specifiers that Python " -"packaging currently supports. Support for PEP440 was implemented in :ref:" -"`setuptools` v8.0 and :ref:`pip` v6.0." -msgstr "" -"O componente de versão de um :term:`Especificador de Requisitos `. Por exemplo, a parte \">=1.3\" de \"foo>=1.3\". A :pep:`440` " -"contém uma :pep:`especificação completa <440#version-specifiers>` dos " -"especificadores que o pacote Python oferece suporte atualmente. O suporte " -"para PEP440 foi implementado em :ref:`setuptools` v8.0 e :ref:`pip` v6.0." - -#: ../source/glossary.rst:231 -msgid "Virtual Environment" -msgstr "Ambiente Virtual" - -#: ../source/glossary.rst:234 -msgid "" -"An isolated Python environment that allows packages to be installed for use " -"by a particular application, rather than being installed system wide. For " -"more information, see the section on :ref:`Creating and using Virtual " -"Environments`." -msgstr "" -"Um ambiente Python isolado que permite que os pacotes sejam instalados para " -"uso por uma aplicação específica, em vez de serem instalados em todo o " -"sistema. Para obter mais informações, consulte a seção sobre :ref:`Creating " -"and using Virtual Environments`." - -#: ../source/glossary.rst:238 -msgid "Wheel" -msgstr "Wheel" - -#: ../source/glossary.rst:241 -msgid "" -"A :term:`Built Distribution` format introduced by :pep:`427`, which is " -"intended to replace the :term:`Egg` format. Wheel is currently supported " -"by :ref:`pip`." -msgstr "" -"Um formato de :term:`Distribuição Construída` introduzido por :pep:`427`, " -"que se destina a substituir o formato :term:`Egg`. O Wheel é atualmente " -"suportado pelo :ref:`pip`." - -#: ../source/glossary.rst:244 -msgid "Working Set" -msgstr "Conjunto de Trabalho" - -#: ../source/glossary.rst:247 -msgid "" -"A collection of :term:`distributions ` available for " -"importing. These are the distributions that are on the `sys.path` variable. " -"At most, one :term:`Distribution ` for a project is " -"possible in a working set." -msgstr "" -"Uma coleção de :term:`distribuições ` disponíveis para " -"importação. Estas são as distribuições que estão na variável `sys.path`. No " -"máximo, uma :term:`Distribuição ` para um projeto é " -"possível em um conjunto de trabalho." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:3 -msgid "Analyzing PyPI package downloads" -msgstr "Analisando downloads de pacotes PyPI" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:5 -msgid "" -"This section covers how to use the public PyPI download statistics dataset " -"to learn more about downloads of a package (or packages) hosted on PyPI. For " -"example, you can use it to discover the distribution of Python versions used " -"to download a package." -msgstr "" -"Esta seção cobre como usar o conjunto de dados de estatísticas de download " -"público do PyPI para saber mais sobre os downloads de um pacote (ou pacotes) " -"hospedado no PyPI. Por exemplo, você pode usá-lo para descobrir a " -"distribuição das versões do Python usadas para baixar um pacote." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:15 -#: ../source/guides/supporting-windows-using-appveyor.rst:18 -msgid "Background" -msgstr "Contexto" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:17 -msgid "PyPI does not display download statistics for a number of reasons: [#]_" -msgstr "O PyPI não exibe estatísticas de download por vários motivos: [#]_" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:19 -msgid "" -"**Inefficient to make work with a Content Distribution Network (CDN):** " -"Download statistics change constantly. Including them in project pages, " -"which are heavily cached, would require invalidating the cache more often, " -"and reduce the overall effectiveness of the cache." -msgstr "" -"**Ineficiente para fazer funcionar com uma Rede de Distribuição de Conteúdo " -"(CDN):** As estatísticas de download mudam constantemente. Incluí-las nas " -"páginas do projeto, que são altamente armazenadas em cache, exigiria a " -"invalidação do cache com mais frequência e reduziria a eficácia geral do " -"cache." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:24 -msgid "" -"**Highly inaccurate:** A number of things prevent the download counts from " -"being accurate, some of which include:" -msgstr "" -"**Altamente imprecisa:** Várias coisas impedem que as contagens de download " -"sejam precisas, algumas das quais incluem:" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:27 -msgid "``pip``'s download cache (lowers download counts)" -msgstr "Cache de download do ``pip`` (diminui a contagem de downloads)" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:28 -msgid "" -"Internal or unofficial mirrors (can both raise or lower download counts)" -msgstr "" -"Espelhos internos ou não oficiais (pode aumentar ou diminuir as contagens de " -"download)" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:29 -msgid "Packages not hosted on PyPI (for comparisons sake)" -msgstr "Pacotes não hospedados no PyPI (para fins de comparação)" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:30 -msgid "" -"Unofficial scripts or attempts at download count inflation (raises download " -"counts)" -msgstr "" -"Scripts não oficiais ou tentativas de aumento da contagem de download " -"(aumenta a contagem de downloads)" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:32 -msgid "Known historical data quality issues (lowers download counts)" -msgstr "" -"Problemas conhecidos de qualidade de dados históricos (diminui a contagem de " -"downloads)" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:34 -msgid "" -"**Not particularly useful:** Just because a project has been downloaded a " -"lot doesn't mean it's good; Similarly just because a project hasn't been " -"downloaded a lot doesn't mean it's bad!" -msgstr "" -"**Não é particularmente útil:** Só porque um projeto foi muito baixado, não " -"significa que ele seja bom; Da mesma forma, só porque um projeto não foi " -"muito baixado, não significa que ele seja ruim!" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:38 -msgid "" -"In short, because it's value is low for various reasons, and the tradeoffs " -"required to make it work are high, it has been not an effective use of " -"limited resources." -msgstr "" -"Resumindo, como seu valor é baixo por vários motivos e as compensações " -"necessárias para fazê-lo funcionar são altas, não tem sido um uso eficaz de " -"recursos limitados." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:43 -msgid "Public dataset" -msgstr "Conjunto de dados públicos" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:45 -msgid "" -"As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, " -"where they are stored as a public dataset." -msgstr "" -"Como alternativa, o `projeto Linehaul `__ " -"transmite registros de download do PyPI para o `Google BigQuery`_ [#]_, onde " -"são armazenados como um conjunto de dados público." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:50 -msgid "Getting set up" -msgstr "Preparando-se" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:52 -msgid "" -"In order to use `Google BigQuery`_ to query the `public PyPI download " -"statistics dataset`_, you'll need a Google account and to enable the " -"BigQuery API on a Google Cloud Platform project. You can run the up to 1TB " -"of queries per month `using the BigQuery free tier without a credit card " -"`__" -msgstr "" -"Para usar o `Google BigQuery`_ para consultar o `conjunto de dados de " -"estatísticas de download PyPI público `_, você precisará de uma conta do Google e habilitar a API do " -"BigQuery em um projeto do Google Cloud Platform. Você pode executar até 1 TB " -"de consultas por mês `usando o free tier do BigQuery sem um cartão de " -"crédito `__" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:58 -msgid "Navigate to the `BigQuery web UI`_." -msgstr "Acesse a `interface web do BigQuery `_." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:59 -msgid "Create a new project." -msgstr "Crie um novo projeto." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:60 -msgid "" -"Enable the `BigQuery API `__." -msgstr "" -"Habilite a `BigQuery API `__." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:63 -msgid "" -"For more detailed instructions on how to get started with BigQuery, check " -"out the `BigQuery quickstart guide `__." -msgstr "" -"Para obter instruções mais detalhadas sobre como começar a usar o BigQuery, " -"consulte o `guia de início rápido do BigQuery `__." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:69 -msgid "Data schema" -msgstr "Esquema de dados" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:71 -msgid "" -"Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` " -"table for each download. The table contains information about what file was " -"downloaded and how it was downloaded. Some useful columns from the `table " -"schema `__ include:" -msgstr "" -"Linehaul escreve uma entrada em uma tabela ``bigquery-public-data.pypi." -"file_downloads`` para cada download. A tabela contém informações sobre qual " -"arquivo foi baixado e como foi baixado. Algumas colunas úteis do `esquema da " -"tabela `__ inclui:" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -msgid "Column" -msgstr "Coluna" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/guides/using-manifest-in.rst:67 -#: ../source/specifications/core-metadata.rst:185 -msgid "Description" -msgstr "Descrição" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/specifications/direct-url.rst:226 -msgid "Examples" -msgstr "Exemplos" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "timestamp" -msgstr "timestamp" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "Date and time" -msgstr "Data e hora" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "``2020-03-09 00:33:03 UTC``" -msgstr "``2020-03-09 00:33:03 UTC``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "file.project" -msgstr "file.project" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "Project name" -msgstr "Nome do projeto" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "``pipenv``, ``nose``" -msgstr "``pipenv``, ``nose``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "file.version" -msgstr "file.version" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "Package version" -msgstr "Versão do pacote" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "``0.1.6``, ``1.4.2``" -msgstr "``0.1.6``, ``1.4.2``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "details.installer.name" -msgstr "details.installer.name" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "Installer" -msgstr "Instalador" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "pip, `bandersnatch`_" -msgstr "pip, `bandersnatch`_" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "details.python" -msgstr "details.python" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "Python version" -msgstr "Versão do Python" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "``2.7.12``, ``3.6.4``" -msgstr "``2.7.12``, ``3.6.4``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:93 -msgid "Useful queries" -msgstr "Consultas úteis" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:95 -msgid "" -"Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" " -"button." -msgstr "" -"Executa consultas na `interface web do BigQuery`_ clicando no botão " -"\"Compose query\"." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:97 -msgid "" -"Note that the rows are stored in a partitioned, which helps limit the cost " -"of queries. These example queries analyze downloads from recent history by " -"filtering on the ``timestamp`` column." -msgstr "" -"Observe que as linhas são armazenadas em uma partição particionada, o que " -"ajuda a limitar o custo das consultas. Essas consultas de exemplo analisam " -"downloads do histórico recente filtrando na coluna ``timestamp``." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:102 -msgid "Counting package downloads" -msgstr "Contando downloads de pacotes" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:104 -msgid "" -"The following query counts the total number of downloads for the project " -"\"pytest\"." -msgstr "" -"A consulta a seguir conta o número total de downloads do projeto \"pytest\"." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:119 -#: ../source/guides/analyzing-pypi-package-downloads.rst:140 -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "num_downloads" -msgstr "num_downloads" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:121 -msgid "26190085" -msgstr "26190085" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:124 -msgid "" -"To only count downloads from pip, filter on the ``details.installer.name`` " -"column." -msgstr "" -"Para contar apenas os downloads do pip, filtre na coluna ``details.installer." -"name``." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:142 -msgid "24334215" -msgstr "24334215" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:146 -msgid "Package downloads over time" -msgstr "Downloads de pacotes ao longo do tempo" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:148 -msgid "" -"To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also " -"filtering by this column reduces corresponding costs." -msgstr "" -"Para agrupar por downloads mensais, use a função ``TIMESTAMP_TRUNC``. Além " -"disso, a filtragem por esta coluna reduz os custos correspondentes." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -msgid "month" -msgstr "mês" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "1956741" -msgstr "1956741" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "2018-01-01" -msgstr "2018-01-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2344692" -msgstr "2344692" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2017-12-01" -msgstr "2017-12-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "1730398" -msgstr "1730398" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "2017-11-01" -msgstr "2017-11-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2047310" -msgstr "2047310" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2017-10-01" -msgstr "2017-10-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "1744443" -msgstr "1744443" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "2017-09-01" -msgstr "2017-09-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "1916952" -msgstr "1916952" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "2017-08-01" -msgstr "2017-08-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:184 -msgid "Python versions over time" -msgstr "Versões Python ao longo do tempo" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:186 -msgid "" -"Extract the Python version from the ``details.python`` column. Warning: This " -"query processes over 500 GB of data." -msgstr "" -"Extrai a versão Python da coluna ``details.python``. Aviso: esta consulta " -"processa mais de 500 GB de dados." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "python" -msgstr "python" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "3.7" -msgstr "3.7" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "18051328726" -msgstr "18051328726" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "3.6" -msgstr "3.6" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "9635067203" -msgstr "9635067203" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "3.8" -msgstr "3.8" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "7781904681" -msgstr "7781904681" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "2.7" -msgstr "2.7" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "6381252241" -msgstr "6381252241" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "null" -msgstr "null" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "2026630299" -msgstr "2026630299" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "3.5" -msgstr "3.5" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "1894153540" -msgstr "1894153540" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:221 -msgid "Caveats" -msgstr "Ressalvas" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:223 -msgid "" -"In addition to the caveats listed in the background above, Linehaul suffered " -"from a bug which caused it to significantly under-report download statistics " -"prior to July 26, 2018. Downloads before this date are proportionally " -"accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total " -"numbers are lower than actual by an order of magnitude." -msgstr "" -"Além das advertências listadas no histórico acima, Linehaul sofreu de um bug " -"que causou um subestimamento das estatísticas de download antes de 26 de " -"julho de 2018. Downloads antes dessa data são proporcionalmente precisos " -"(por exemplo, a porcentagem de Python 2 vs. Python 3 downloads), mas os " -"números totais são menores do que o real em uma ordem de magnitude." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:231 -msgid "Additional tools" -msgstr "Ferramentas adicionais" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:233 -msgid "" -"Besides using the BigQuery console, there are some additional tools which " -"may be useful when analyzing download statistics." -msgstr "" -"Além de usar o console do BigQuery, existem algumas ferramentas adicionais " -"que podem ser úteis ao analisar estatísticas de download." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:237 -msgid "``google-cloud-bigquery``" -msgstr "``google-cloud-bigquery``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:239 -msgid "" -"You can also access the public PyPI download statistics dataset " -"programmatically via the BigQuery API and the `google-cloud-bigquery`_ " -"project, the official Python client library for BigQuery." -msgstr "" -"Você também pode acessar o conjunto de dados público de estatísticas de " -"download PyPI de maneira programática por meio da API do BigQuery e do " -"projeto `google-cloud-bigquery`_, a biblioteca cliente oficial do Python " -"para BigQuery." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:267 -msgid "``pypinfo``" -msgstr "``pypinfo``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:269 -msgid "" -"`pypinfo`_ is a command-line tool which provides access to the dataset and " -"can generate several useful queries. For example, you can query the total " -"number of download for a package with the command ``pypinfo package_name``." -msgstr "" -"`pypinfo`_ é uma ferramenta de linha de comando que fornece acesso ao " -"conjunto de dados e pode gerar várias consultas úteis. Por exemplo, você " -"pode consultar o número total de downloads de um pacote com o comando " -"``pypinfo package_name``." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:273 -msgid "Install `pypinfo`_ using pip." -msgstr "Instale `pypinfo`_ usando o pip." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:279 -msgid "Usage:" -msgstr "Uso:" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:295 -msgid "``pandas-gbq``" -msgstr "``pandas-gbq``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:297 -msgid "" -"The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." -msgstr "" -"O projeto `pandas-gbq`_ permite acessar resultados de pesquisa com `Pandas`_." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:301 -#: ../source/specifications/binary-distribution-format.rst:459 -msgid "References" -msgstr "Referências" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:303 -msgid "" -"`PyPI Download Counts deprecation email `__" -msgstr "" -"`E-mail de descontinuação das contagens de download do PyPI `__" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:304 -msgid "" -"`PyPI BigQuery dataset announcement email `__" -msgstr "" -"`E-mail de anúncio do conjunto de dados BigQuery do PyPI `__" - -#: ../source/guides/creating-and-discovering-plugins.rst:3 -msgid "Creating and discovering plugins" -msgstr "Criando e descobrindo plug-ins" - -#: ../source/guides/creating-and-discovering-plugins.rst:5 -msgid "" -"Often when creating a Python application or library you'll want the ability " -"to provide customizations or extra features via **plugins**. Because Python " -"packages can be separately distributed, your application or library may want " -"to automatically **discover** all of the plugins available." -msgstr "" -"Frequentemente, ao criar uma aplicação ou biblioteca Python, você desejará " -"ter a capacidade de fornecer personalizações ou recursos extras por meio de " -"**plug-ins**. Como os pacotes Python podem ser distribuídos separadamente, " -"sua aplicação ou biblioteca pode querer **descobrir** automaticamente todos " -"os plugins disponíveis." - -#: ../source/guides/creating-and-discovering-plugins.rst:10 -msgid "There are three major approaches to doing automatic plugin discovery:" -msgstr "" -"Existem três abordagens principais para fazer a descoberta automática de " -"plugins:" - -#: ../source/guides/creating-and-discovering-plugins.rst:12 -msgid "`Using naming convention`_." -msgstr "`Usando convenção de nomenclatura `_." - -#: ../source/guides/creating-and-discovering-plugins.rst:13 -msgid "`Using namespace packages`_." -msgstr "`Usando pacotes de espaço de nomes `_." - -#: ../source/guides/creating-and-discovering-plugins.rst:14 -msgid "`Using package metadata`_." -msgstr "`Usando metadados de pacote `_." - -#: ../source/guides/creating-and-discovering-plugins.rst:18 -msgid "Using naming convention" -msgstr "Usando convenção de nomenclatura" - -#: ../source/guides/creating-and-discovering-plugins.rst:20 -msgid "" -"If all of the plugins for your application follow the same naming " -"convention, you can use :func:`pkgutil.iter_modules` to discover all of the " -"top-level modules that match the naming convention. For example, `Flask`_ " -"uses the naming convention ``flask_{plugin_name}``. If you wanted to " -"automatically discover all of the Flask plugins installed:" -msgstr "" -"Se todos os plugins para sua aplicação seguem a mesma convenção de " -"nomenclatura, você pode usar :func:`pkgutil.iter_modules` para descobrir " -"todos os módulos de nível superior que correspondem à convenção de " -"nomenclatura. Por exemplo, `Flask`_ usa a convenção de nomenclatura " -"``flask_{nome_plugin}``. Se você quiser descobrir automaticamente todos os " -"plugins Flask instalados:" - -#: ../source/guides/creating-and-discovering-plugins.rst:38 -msgid "" -"If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins " -"installed then ``discovered_plugins`` would be:" -msgstr "" -"Se você tivesse os plugins `Flask-SQLAlchemy`_ e `Flask-Talisman`_ " -"instalados, então ``discover_plugins`` seria:" - -#: ../source/guides/creating-and-discovering-plugins.rst:48 -msgid "" -"Using naming convention for plugins also allows you to query the Python " -"Package Index's `simple API`_ for all packages that conform to your naming " -"convention." -msgstr "" -"Usar a convenção de nomenclatura para plugins também permite que você " -"consulte a `API simples `_ do Índice de Pacotes Python para " -"todos os pacotes que estão em conformidade com a sua convenção de " -"nomenclatura." - -#: ../source/guides/creating-and-discovering-plugins.rst:59 -msgid "Using namespace packages" -msgstr "Usando pacotes de espaço de nomes" - -#: ../source/guides/creating-and-discovering-plugins.rst:61 -msgid "" -":doc:`Namespace packages ` can be used to " -"provide a convention for where to place plugins and also provides a way to " -"perform discovery. For example, if you make the sub-package ``myapp." -"plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once " -"installed, you can use :func:`pkgutil.iter_modules` to discover all modules " -"and packages installed under that namespace:" -msgstr "" -":doc:`Pacotes de espaços de nome ` podem ser " -"usados para fornecer uma convenção de onde colocar plugins e também fornece " -"uma maneira de realizar a descoberta. Por exemplo, se você fizer do " -"subpacote ``myapp.plugins`` um pacote de espaço de nomes, então outras :term:" -"`distribuições ` pode fornecer módulos e pacotes para " -"aquele espaço de nomes. Uma vez instalado, você pode usar :func:`pkgutil." -"iter_modules` para descobrir todos os módulos e pacotes instalados sob esse " -"espaço de nomes:" - -#: ../source/guides/creating-and-discovering-plugins.rst:89 -msgid "" -"Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` " -"causes it to only look for the modules directly under that namespace. For " -"example, if you have installed distributions that provide the modules " -"``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in " -"this case would be:" -msgstr "" -"Especificar ``myapp.plugins.__path__`` para :func:`~pkgutil.iter_modules` " -"faz com que ele procure apenas os módulos diretamente sob aquele espaço de " -"nomes. Por exemplo, se você instalou distribuições que fornecem os módulos " -"``myapp.plugins.a`` e ``myapp.plugins.b``, então ``found_plugins`` neste " -"caso seria:" - -#: ../source/guides/creating-and-discovering-plugins.rst:101 -msgid "" -"This sample uses a sub-package as the namespace package (``myapp.plugins``), " -"but it's also possible to use a top-level package for this purpose (such as " -"``myapp_plugins``). How to pick the namespace to use is a matter of " -"preference, but it's not recommended to make your project's main top-level " -"package (``myapp`` in this case) a namespace package for the purpose of " -"plugins, as one bad plugin could cause the entire namespace to break which " -"would in turn make your project unimportable. For the \"namespace sub-package" -"\" approach to work, the plugin packages must omit the :file:`__init__.py` " -"for your top-level package directory (``myapp`` in this case) and include " -"the namespace-package style :file:`__init__.py` in the namespace sub-package " -"directory (``myapp/plugins``). This also means that plugins will need to " -"explicitly pass a list of packages to :func:`setup`'s ``packages`` argument " -"instead of using :func:`setuptools.find_packages`." -msgstr "" -"Este exemplo usa um subpacote como o pacote de espaço de nomes (``myapp." -"plugins``), mas também é possível usar um pacote de nível superior para este " -"propósito (como ``myapp_plugins``). Como escolher o espaço de nomes a ser " -"usado é uma questão de preferência, mas não é recomendado fazer do pacote de " -"nível superior principal do seu projeto (``myapp``, neste caso) um pacote de " -"espaço de nomes para fins de plugins, como um plugin ruim poderia fazer com " -"que todo o espaço de nomes seja interrompido, o que, por sua vez, tornaria " -"seu projeto não importável. Para que a abordagem de \"subpacote de espaço de " -"nomes\" funcione, os pacotes de plugin devem omitir o :file:`__init__.py` " -"para o diretório de pacote de nível superior (``myapp``, neste caso) e " -"incluir o estilo de pacote de espaço de nomes :file:`__init__.py` no " -"diretório do subpacote de espaço de nomes (``myapp/plugins``). Isso também " -"significa que os plugins precisarão passar explicitamente uma lista de " -"pacotes para o argumento ``packages`` de :func:`setup` ao invés de usar :" -"func:`setuptools.find_packages`." - -#: ../source/guides/creating-and-discovering-plugins.rst:115 -msgid "" -"Namespace packages are a complex feature and there are several different " -"ways to create them. It's highly recommended to read the :doc:`packaging-" -"namespace-packages` documentation and clearly document which approach is " -"preferred for plugins to your project." -msgstr "" -"Os pacotes de espaço de nomes são um recurso complexo e existem várias " -"maneiras diferentes de criá-los. É altamente recomendado ler a documentação " -"de :doc:`packaging-namespace-packages` e documentar claramente qual " -"abordagem é preferida para plugins em seu projeto." - -#: ../source/guides/creating-and-discovering-plugins.rst:121 -msgid "Using package metadata" -msgstr "Usando metadados de pacote" - -#: ../source/guides/creating-and-discovering-plugins.rst:123 -msgid "" -"`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :" -"func:`setup` in :file:`setup.py` plugins can register themselves for " -"discovery." -msgstr "" -"`Setuptools`_ fornece :doc:`suporte especial ` para plugins. Fornecendo o argumento ``entry_points`` para :" -"func:`setup` em :file:`setup.py`, os plugins podem se registrar para serem " -"descobertos." - -#: ../source/guides/creating-and-discovering-plugins.rst:128 -msgid "" -"For example if you have a package named ``myapp-plugin-a`` and it includes " -"in its :file:`setup.py`:" -msgstr "" -"Por exemplo, se você tem um pacote chamado ``myapp-plugin-a`` e ele inclui " -"em seu :file:`setup.py`:" - -#: ../source/guides/creating-and-discovering-plugins.rst:139 -msgid "" -"Then you can discover and load all of the registered entry points by using :" -"func:`importlib.metadata.entry_points` (or the `backport`_ " -"``importlib_metadata >= 3.6`` for Python 3.6-3.9):" -msgstr "" -"Então você pode descobrir e carregar todos os pontos de entrada registrados " -"usando :func:`importlib.metadata.entry_points` (ou o `backport`_ " -"``importlib_metadata >= 3.6`` para Python 3.6-3.9):" - -#: ../source/guides/creating-and-discovering-plugins.rst:154 -msgid "" -"In this example, ``discovered_plugins`` would be a collection of type :class:" -"`importlib.metadata.EntryPoint`:" -msgstr "" -"Neste exemplo, ``discover_plugins`` seria uma coleção do tipo :class:" -"`importlib.metadata.EntryPoint`:" - -#: ../source/guides/creating-and-discovering-plugins.rst:163 -msgid "" -"Now the module of your choice can be imported by executing " -"``discovered_plugins['a'].load()``." -msgstr "" -"Agora o módulo de sua escolha pode ser importado executando " -"``discovered_plugins['a'].Load()``." - -#: ../source/guides/creating-and-discovering-plugins.rst:166 -msgid "" -"The ``entry_point`` specification in :file:`setup.py` is fairly flexible and " -"has a lot of options. It's recommended to read over the entire section on :" -"doc:`entry points ` ." -msgstr "" -"A especificação ``entry_point`` em :file:`setup.py` é bastante flexível e " -"tem muitas opções. É recomendado ler toda a seção sobre :doc:`pontos de " -"entrada ` ." - -#: ../source/guides/creating-and-discovering-plugins.rst:170 -msgid "" -"Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools " -"provide support for defining entry points." -msgstr "" -"Visto que esta especificação é parte da :doc:`biblioteca padrão `, a maioria das ferramentas de empacotamento, " -"exceto setuptools, fornecem suporte para definir pontos de entrada." - -#: ../source/guides/distributing-packages-using-setuptools.rst:5 -msgid "Packaging and distributing projects" -msgstr "Empacotando e distribuindo projetos" - -#: ../source/guides/distributing-packages-using-setuptools.rst:7 -msgid "" -"This section covers the basics of how to configure, package and distribute " -"your own Python projects. It assumes that you are already familiar with the " -"contents of the :doc:`/tutorials/installing-packages` page." -msgstr "" -"Esta seção cobre os fundamentos de como configurar, empacotar e distribuir " -"seus próprios projetos Python. Ele assume que você já está familiarizado com " -"o conteúdo da página :doc:`/tutorials/installing-packages`." - -#: ../source/guides/distributing-packages-using-setuptools.rst:11 -msgid "" -"The section does *not* aim to cover best practices for Python project " -"development as a whole. For example, it does not provide guidance or tool " -"recommendations for version control, documentation, or testing." -msgstr "" -"A seção *não* visa cobrir as melhores práticas para o desenvolvimento de " -"projetos Python como um todo. Por exemplo, ele não fornece orientação ou " -"recomendações de ferramentas para controle de versão, documentação ou teste." - -#: ../source/guides/distributing-packages-using-setuptools.rst:15 -msgid "" -"For more reference material, see :std:doc:`Building and Distributing " -"Packages ` in the :ref:`setuptools` docs, but note that " -"some advisory content there may be outdated. In the event of conflicts, " -"prefer the advice in the Python Packaging User Guide." -msgstr "" -"Para mais material de referência, veja :std:doc:`Construindo e Distribuindo " -"Pacotes ` na documentação :ref:`setuptools`, mas note que " -"alguns conteúdos de aviso podem estar desatualizados. No caso de conflitos, " -"dê preferência ao conselho do Guia de Usuário para Empacotamento de Python." - -#: ../source/guides/distributing-packages-using-setuptools.rst:25 -msgid "Requirements for packaging and distributing" -msgstr "Requisitos para empacotamento e distribuição" - -#: ../source/guides/distributing-packages-using-setuptools.rst:26 -msgid "" -"First, make sure you have already fulfilled the :ref:`requirements for " -"installing packages `." -msgstr "" -"Primeiro, certifique-se de que você já cumpriu os :ref:`requisitos para " -"instalação de pacotes `." - -#: ../source/guides/distributing-packages-using-setuptools.rst:29 -msgid "Install \"twine\" [1]_:" -msgstr "Instale \"twine\" [1]_:" - -#: ../source/guides/distributing-packages-using-setuptools.rst:43 -msgid "" -"You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below " -"`)." -msgstr "" -"Você precisará disso para enviar as :term:`distribuições ` do seu projeto para o :term:`PyPI ` " -"(veja :ref:`abaixo `)." - -#: ../source/guides/distributing-packages-using-setuptools.rst:49 -msgid "Configuring your project" -msgstr "Configurando seu projeto" - -#: ../source/guides/distributing-packages-using-setuptools.rst:53 -msgid "Initial files" -msgstr "Arquivos iniciais" - -#: ../source/guides/distributing-packages-using-setuptools.rst:58 -msgid "" -"The most important file is :file:`setup.py` which exists at the root of your " -"project directory. For an example, see the `setup.py `_ in the `PyPA sample project " -"`_." -msgstr "" -"O arquivo mais importante é :file:`setup.py` que existe na raiz do diretório " -"do seu projeto. Para obter um exemplo, consulte o `setup.py `_ no `projeto de exemplo PyPA " -"`_." - -#: ../source/guides/distributing-packages-using-setuptools.rst:63 -msgid ":file:`setup.py` serves two primary functions:" -msgstr ":file:`setup.py` tem duas funções principais:" - -#: ../source/guides/distributing-packages-using-setuptools.rst:65 -msgid "" -"It's the file where various aspects of your project are configured. The " -"primary feature of :file:`setup.py` is that it contains a global ``setup()`` " -"function. The keyword arguments to this function are how specific details " -"of your project are defined. The most relevant arguments are explained in :" -"ref:`the section below `." -msgstr "" -"É o arquivo onde vários aspectos do seu projeto são configurados. A " -"principal característica do :file:`setup.py` é que ele contém uma função " -"global ``setup()``. Os argumentos nomeados para esta função são como os " -"detalhes específicos do seu projeto são definidos. Os argumentos mais " -"relevantes são explicados em :ref:`a seção abaixo de `." - -#: ../source/guides/distributing-packages-using-setuptools.rst:71 -msgid "" -"It's the command line interface for running various commands that relate to " -"packaging tasks. To get a listing of available commands, run ``python setup." -"py --help-commands``." -msgstr "" -"É a interface de linha de comando para executar vários comandos relacionados " -"a tarefas de empacotamento. Para obter uma lista dos comandos disponíveis, " -"execute ``python setup.py --help-commands``." - -#: ../source/guides/distributing-packages-using-setuptools.rst:79 -msgid "" -":file:`setup.cfg` is an ini file that contains option defaults for :file:" -"`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project " -"`_." -msgstr "" -":file:`setup.cfg` é um arquivo ini que contém opções padrão para os " -"comandos :file:`setup.py`. Para obter um exemplo, consulte o `setup.cfg " -"`_ no `projeto " -"de exemplo PyPA `_." - -#: ../source/guides/distributing-packages-using-setuptools.rst:86 -msgid "README.rst / README.md" -msgstr "README.rst / README.md" - -#: ../source/guides/distributing-packages-using-setuptools.rst:88 -msgid "" -"All projects should contain a readme file that covers the goal of the " -"project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not " -"a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:" -"`long_description_content_type ` argument)." -msgstr "" -"Todos os projetos devem conter um arquivo leia-me que cubra o objetivo do " -"projeto. O formato mais comum é `reStructuredText `_ com uma extensão \"rst\", embora isso não seja " -"um requisito; múltiplas variantes do `Markdown `_ também são suportadas (veja o argumento :ref:" -"`long_description_content_type ` do ``setup()``)." - -#: ../source/guides/distributing-packages-using-setuptools.rst:95 -msgid "" -"For an example, see `README.md `_ from the `PyPA sample project `_." -msgstr "" -"Para obter um exemplo, consulte o `README.md `_ do `projeto de exemplo PyPA `_." - -#: ../source/guides/distributing-packages-using-setuptools.rst:99 -msgid "" -"Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:" -"`README.rst`, :file:`README.txt`, or :file:`README`) included in source " -"distributions by default. The built-in :ref:`distutils` library adopts this " -"behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ " -"will include a :file:`README.md` if found. If you are using setuptools, you " -"don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, " -"include it to be explicit." -msgstr "" -"Projetos usando :ref:`setuptools` 0.6.27+ têm arquivos leia-me padrão (:file:" -"`README.rst`, :file:`README.txt` ou :file:`README`) incluídos nas " -"distribuições de código-fonte por padrão. A biblioteca interna :ref:" -"`distutils` adota este comportamento a partir do Python 3.7. " -"Adicionalmente, :ref:`setuptools` 36.4.0+ incluirá um :file:`README.md` se " -"encontrado. Se você estiver usando setuptools, você não precisa listar seu " -"arquivo leia-me em :file:`MANIFEST.in`. Caso contrário, inclua para ser " -"explícito." - -#: ../source/guides/distributing-packages-using-setuptools.rst:108 -msgid "MANIFEST.in" -msgstr "MANIFEST.in" - -#: ../source/guides/distributing-packages-using-setuptools.rst:110 -msgid "" -"A :file:`MANIFEST.in` is needed when you need to package additional files " -"that are not automatically included in a source distribution. For details " -"on writing a :file:`MANIFEST.in` file, including a list of what's included " -"by default, see \":ref:`Using MANIFEST.in`\"." -msgstr "" -"Um :file:`MANIFEST.in` é necessário quando você precisa empacotar arquivos " -"adicionais que não são incluídos automaticamente em uma distribuição de " -"código-fonte. Para obter detalhes sobre como escrever um arquivo :file:" -"`MANIFEST.in`, incluindo uma lista do que é incluído por padrão, consulte \":" -"ref:`Using MANIFEST.in`\"." - -#: ../source/guides/distributing-packages-using-setuptools.rst:115 -msgid "" -"For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." -msgstr "" -"Para obter um exemplo, consulte o `MANIFEST.in `_ do `projeto de exemplo PyPA " -"`_." - -#: ../source/guides/distributing-packages-using-setuptools.rst:119 -msgid "" -":file:`MANIFEST.in` does not affect binary distributions such as wheels." -msgstr ":file:`MANIFEST.in` não afeta distribuições binárias como wheels." - -#: ../source/guides/distributing-packages-using-setuptools.rst:122 -msgid "LICENSE.txt" -msgstr "LICENSE.txt" - -#: ../source/guides/distributing-packages-using-setuptools.rst:124 -msgid "" -"Every package should include a license file detailing the terms of " -"distribution. In many jurisdictions, packages without an explicit license " -"can not be legally used or distributed by anyone other than the copyright " -"holder. If you're unsure which license to choose, you can use resources such " -"as `GitHub's Choose a License `_ or consult a " -"lawyer." -msgstr "" -"Cada pacote deve incluir um arquivo de licença detalhando os termos de " -"distribuição. Em muitas jurisdições, os pacotes sem uma licença explícita " -"não podem ser legalmente usados ou distribuídos por ninguém que não seja o " -"detentor dos direitos autorais. Se não tiver certeza de qual licença " -"escolher, você pode usar recursos como `Escolha uma licença do GitHub " -"`_ ou consultar um advogado." - -#: ../source/guides/distributing-packages-using-setuptools.rst:130 -msgid "" -"For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." -msgstr "" -"Para obter um exemplo, consulte o `LICENSE.txt `_ do `projeto de exemplo PyPA " -"`_." - -#: ../source/guides/distributing-packages-using-setuptools.rst:135 -msgid "" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:137 -msgid "" -"Although it's not required, the most common practice is to include your " -"Python modules and packages under a single top-level package that has the " -"same :ref:`name ` as your project, or something very close." -msgstr "" -"Embora não seja obrigatório, a prática mais comum é incluir seus módulos e " -"pacotes Python em um único pacote de nível superior que tem o mesmo :ref:" -"`name ` do seu projeto, ou algo muito próximo." - -#: ../source/guides/distributing-packages-using-setuptools.rst:141 -msgid "" -"For an example, see the `sample `_ package that's included in the `PyPA sample project " -"`_." -msgstr "" -"Para obter um exemplo, consulte o pacote de `exemplo `_ que está incluído no `projeto " -"de exemplo PyPA `_." - -#: ../source/guides/distributing-packages-using-setuptools.rst:149 -msgid "setup() args" -msgstr "Argumentos de setup()" - -#: ../source/guides/distributing-packages-using-setuptools.rst:151 -msgid "" -"As mentioned above, the primary feature of :file:`setup.py` is that it " -"contains a global ``setup()`` function. The keyword arguments to this " -"function are how specific details of your project are defined." -msgstr "" -"Como mencionado acima, o principal recurso do :file:`setup.py` é que ele " -"contém uma função global ``setup()``. Os argumentos nomeados para esta " -"função são como os detalhes específicos do seu projeto são definidos." - -#: ../source/guides/distributing-packages-using-setuptools.rst:155 -msgid "" -"The most relevant arguments are explained below. Most of the snippets given " -"are taken from the `setup.py `_ contained in the `PyPA sample project `_." -msgstr "" -"Os argumentos mais relevantes são explicados a seguir. A maioria dos " -"fragmentos fornecidos são retirados do `setup.py `_ contido no `projeto de exemplo PyPA " -"`_." - -#: ../source/guides/distributing-packages-using-setuptools.rst:164 -msgid "name" -msgstr "name" - -#: ../source/guides/distributing-packages-using-setuptools.rst:170 -msgid "" -"This is the name of your project, determining how your project is listed on :" -"term:`PyPI `. Per :pep:`508`, valid project " -"names must:" -msgstr "" -"Este é o nome do seu projeto, determinando como ele está listado no :term:" -"`PyPI `. Conforme :pep:`508`, nomes de projetos " -"válidos devem:" - -#: ../source/guides/distributing-packages-using-setuptools.rst:174 -msgid "" -"Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), " -"and/or periods (``.``), and" -msgstr "" -"Consistir apenas em letras ASCII, dígitos, sublinhados (``_``), hífenes (``-" -"``) e/ou pontos (``.``) e" - -#: ../source/guides/distributing-packages-using-setuptools.rst:176 -msgid "Start & end with an ASCII letter or digit." -msgstr "Começar e terminar com uma letra ou dígito ASCII." - -#: ../source/guides/distributing-packages-using-setuptools.rst:178 -msgid "" -"Comparison of project names is case insensitive and treats arbitrarily-long " -"runs of underscores, hyphens, and/or periods as equal. For example, if you " -"register a project named ``cool-stuff``, users will be able to download it " -"or declare a dependency on it using any of the following spellings::" -msgstr "" -"A comparação de nomes de projetos não diferencia maiúsculas de minúsculas e " -"trata sequências arbitrariamente longas de sublinhados, hífenes e/ou pontos " -"como iguais. Por exemplo, se você registrar um projeto chamado ``cool-" -"stuff``, os usuários poderão baixá-lo ou declarar uma dependência dele " -"usando qualquer uma das seguintes formas de escrever::" - -#: ../source/guides/distributing-packages-using-setuptools.rst:190 -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "version" -msgstr "version" - -#: ../source/guides/distributing-packages-using-setuptools.rst:196 -msgid "" -"This is the current version of your project, allowing your users to " -"determine whether or not they have the latest version, and to indicate which " -"specific versions they've tested their own software against." -msgstr "" -"Esta é a versão atual do seu projeto, permitindo que seus usuários " -"determinem se têm ou não a versão mais recente e indiquem em quais versões " -"específicas eles testaram seu próprio software." - -#: ../source/guides/distributing-packages-using-setuptools.rst:200 -msgid "" -"Versions are displayed on :term:`PyPI ` for " -"each release if you publish your project." -msgstr "" -"As versões são exibidas em :term:`PyPI ` para " -"cada lançamento se você publicar seu projeto." - -#: ../source/guides/distributing-packages-using-setuptools.rst:203 -msgid "" -"See :ref:`Choosing a versioning scheme` for more information on ways to use " -"versions to convey compatibility information to your users." -msgstr "" -"Veja :ref:`Escolhendo um esquema de versionamento ` para mais informações sobre maneiras de usar versões para " -"transmitir informações de compatibilidade para seus usuários." - -#: ../source/guides/distributing-packages-using-setuptools.rst:206 -msgid "" -"If the project code itself needs run-time access to the version, the " -"simplest way is to keep the version in both :file:`setup.py` and your code. " -"If you'd rather not duplicate the value, there are a few ways to manage " -"this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." -msgstr "" -"Se o código do projeto em si precisa de acesso em tempo de execução para a " -"versão, a maneira mais simples é manter a versão em :file:`setup.py` e seu " -"código. Se você preferir não duplicar o valor, existem algumas maneiras de " -"gerenciar isso. Consulte a seção de tópicos avançados \":ref:`Fonte única da " -"versão `\"." - -#: ../source/guides/distributing-packages-using-setuptools.rst:214 -msgid "description" -msgstr "description" - -#: ../source/guides/distributing-packages-using-setuptools.rst:222 -msgid "Give a short and long description for your project." -msgstr "Da uma descrição curta e longa para seu projeto." - -#: ../source/guides/distributing-packages-using-setuptools.rst:224 -msgid "" -"These values will be displayed on :term:`PyPI ` " -"if you publish your project. On ``pypi.org``, the user interface displays " -"``description`` in the grey banner and ``long_description`` in the section " -"named \"Project Description\"." -msgstr "" -"Esses valores serão exibidos no :term:`PyPI ` " -"se você publicar seu projeto. No ``pypi.org``, a interface do usuário exibe " -"``description`` no banner cinza e ``long_description`` na seção chamada " -"\"Descrição do Projeto\"." - -#: ../source/guides/distributing-packages-using-setuptools.rst:229 -msgid "" -"``description`` is also displayed in lists of projects. For example, it's " -"visible in the search results pages such as https://pypi.org/search/?" -"q=jupyter, the front-page lists of trending projects and new releases, and " -"the list of projects you maintain within your account profile (such as " -"https://pypi.org/user/jaraco/)." -msgstr "" -"``description`` também é exibido em listas de projetos. Por exemplo, ele é " -"visível nas páginas de resultados de pesquisa, como https://pypi.org/search/?" -"q=jupyter, nas listas da página inicial de projetos populares e novos " -"lançamentos e na lista de projetos que você mantém no perfil de sua conta " -"(como https://pypi.org/user/jaraco/)." - -#: ../source/guides/distributing-packages-using-setuptools.rst:235 -msgid "" -"A `content type `_ can be specified with the " -"``long_description_content_type`` argument, which can be one of ``text/" -"plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no " -"formatting, `reStructuredText (reST) `_, and the Github-flavored " -"Markdown dialect of `Markdown `_ respectively." -msgstr "" -"Um `tipo de conteúdo `_ pode ser especificado com o " -"argumento ``long_description_content_type``, que pode ser um de ``text/" -"plain``, ``text/x-rst`` ou ``text/markdown``, correspondendo a nenhuma " -"formatação, `reStructuredText (reST) `_, e o dialeto Markdown com " -"sabor do GitHub de `Markdown `_ respectivamente." - -#: ../source/guides/distributing-packages-using-setuptools.rst:245 -msgid "url" -msgstr "url" - -#: ../source/guides/distributing-packages-using-setuptools.rst:252 -msgid "Give a homepage URL for your project." -msgstr "Fornece o URL da página inicial do seu projeto." - -#: ../source/guides/distributing-packages-using-setuptools.rst:256 -msgid "author" -msgstr "author" - -#: ../source/guides/distributing-packages-using-setuptools.rst:263 -msgid "Provide details about the author." -msgstr "Fornece detalhes sobre o autor." - -#: ../source/guides/distributing-packages-using-setuptools.rst:267 -msgid "license" -msgstr "license" - -#: ../source/guides/distributing-packages-using-setuptools.rst:273 -msgid "" -"The ``license`` argument doesn't have to indicate the license under which " -"your package is being released, although you may optionally do so if you " -"want. If you're using a standard, well-known license, then your main " -"indication can and should be via the ``classifiers`` argument. Classifiers " -"exist for all major open-source licenses." -msgstr "" -"O argumento ``license`` não precisa indicar a licença sob a qual seu pacote " -"está sendo lançado, embora você possa opcionalmente fazer isso se desejar. " -"Se você estiver usando uma licença padrão bem conhecida, sua indicação " -"principal pode e deve ser por meio do argumento ``classifiers``. Existem " -"classificadores para todas as principais licenças de código aberto." - -#: ../source/guides/distributing-packages-using-setuptools.rst:279 -msgid "" -"The \"license\" argument is more typically used to indicate differences from " -"well-known licenses, or to include your own, unique license. As a general " -"rule, it's a good idea to use a standard, well-known license, both to avoid " -"confusion and because some organizations avoid software whose license is " -"unapproved." -msgstr "" -"O argumento \"license\" é mais comumente usado para indicar diferenças de " -"licenças conhecidas ou para incluir sua própria licença exclusiva. Como " -"regra geral, é uma boa ideia usar uma licença padrão bem conhecida, tanto " -"para evitar confusão quanto porque algumas organizações evitam software cuja " -"licença não é aprovada." - -#: ../source/guides/distributing-packages-using-setuptools.rst:287 -msgid "classifiers" -msgstr "classifiers" - -#: ../source/guides/distributing-packages-using-setuptools.rst:316 -msgid "" -"Provide a list of classifiers that categorize your project. For a full " -"listing, see https://pypi.org/classifiers/." -msgstr "" -"Fornece uma lista de classificadores que categorizam seu projeto. Para obter " -"uma lista completa, consulte https://pypi.org/classifiers/." - -#: ../source/guides/distributing-packages-using-setuptools.rst:319 -msgid "" -"Although the list of classifiers is often used to declare what Python " -"versions a project supports, this information is only used for searching & " -"browsing projects on PyPI, not for installing projects. To actually " -"restrict what Python versions a project can be installed on, use the :ref:" -"`python_requires` argument." -msgstr "" -"Embora a lista de classificadores seja frequentemente usada para declarar " -"quais versões do Python um projeto suporta, essas informações são usadas " -"apenas para pesquisar e navegar por projetos no PyPI, não para instalar " -"projetos. Para realmente restringir em quais versões do Python um projeto " -"pode ser instalado, use o argumento :ref:`python_requires`." - -#: ../source/guides/distributing-packages-using-setuptools.rst:327 -msgid "keywords" -msgstr "keywords" - -#: ../source/guides/distributing-packages-using-setuptools.rst:333 -msgid "List keywords that describe your project." -msgstr "Lista as palavras-chave que descrevem seu projeto." - -#: ../source/guides/distributing-packages-using-setuptools.rst:337 -msgid "project_urls" -msgstr "project_urls" - -#: ../source/guides/distributing-packages-using-setuptools.rst:349 -msgid "" -"List additional relevant URLs about your project. This is the place to link " -"to bug trackers, source repositories, or where to support package " -"development. The string of the key is the exact text that will be displayed " -"on PyPI." -msgstr "" -"Lista URLs relevantes adicionais sobre seu projeto. Este é o lugar para se " -"conectar a rastreadores de bugs, repositórios fontes ou onde oferecer " -"suporte ao desenvolvimento de pacotes. A string da chave é o texto exato que " -"será exibido no PyPI." - -#: ../source/guides/distributing-packages-using-setuptools.rst:355 -msgid "packages" -msgstr "packages" - -#: ../source/guides/distributing-packages-using-setuptools.rst:361 -msgid "" -"Set ``packages`` to a list of all :term:`packages ` in your " -"project, including their subpackages, sub-subpackages, etc. Although the " -"packages can be listed manually, ``setuptools.find_packages()`` finds them " -"automatically. Use the ``include`` keyword argument to find only the given " -"packages. Use the ``exclude`` keyword argument to omit packages that are " -"not intended to be released and installed." -msgstr "" -"Defina ``packages`` para uma lista de todos :term:`pacotes ` " -"em seu projeto, incluindo seus subpacotes, sub-subpacotes, etc. Embora os " -"pacotes possam ser listados manualmente, ``setuptools.find_packages()`` " -"encontra-os automaticamente. Use o argumento nomeado ``include`` para " -"encontrar apenas os pacotes fornecidos. Use o argumento nomeado ``exclude`` " -"para omitir pacotes que não devem ser lançados e instalados." - -#: ../source/guides/distributing-packages-using-setuptools.rst:370 -msgid "py_modules" -msgstr "py_modules" - -#: ../source/guides/distributing-packages-using-setuptools.rst:376 -msgid "" -"If your project contains any single-file Python modules that aren't part of " -"a package, set ``py_modules`` to a list of the names of the modules (minus " -"the ``.py`` extension) in order to make :ref:`setuptools` aware of them." -msgstr "" -"Se o seu projeto contém qualquer módulo Python de arquivo único que não faz " -"parte de um pacote, defina ``py_modules`` para uma lista dos nomes dos " -"módulos (menos a extensão ``.py``) para fazer o :ref:`setuptools` ficar " -"ciente deles." - -#: ../source/guides/distributing-packages-using-setuptools.rst:388 -msgid "" -"\"install_requires\" should be used to specify what dependencies a project " -"minimally needs to run. When the project is installed by :ref:`pip`, this is " -"the specification that is used to install its dependencies." -msgstr "" -"\"install_requires\" deve ser usado para especificar quais dependências um " -"projeto precisa minimamente para ser executado. Quando o projeto é instalado " -"pelo :ref:`pip`, esta é a especificação que é usada para instalar suas " -"dependências." - -#: ../source/guides/distributing-packages-using-setuptools.rst:392 -msgid "" -"For more on using \"install_requires\" see :ref:`install_requires vs " -"Requirements files`." -msgstr "" -"Para mais informações sobre como usar \"install_requires\", veja :ref:" -"`install_requires vs Arquivos de requisitos `." - -#: ../source/guides/distributing-packages-using-setuptools.rst:398 -msgid "python_requires" -msgstr "python_requires" - -#: ../source/guides/distributing-packages-using-setuptools.rst:400 -msgid "" -"If your project only runs on certain Python versions, setting the " -"``python_requires`` argument to the appropriate :pep:`440` version specifier " -"string will prevent :ref:`pip` from installing the project on other Python " -"versions. For example, if your package is for Python 3+ only, write::" -msgstr "" -"Se o seu projeto só funciona em certas versões do Python, definir o " -"argumento ``python_requires`` para a string apropriada especificadora de " -"versão da :pep:`440` impedirá :ref:`pip` de instalar o projeto em outras " -"versões do Python. Por exemplo, se seu pacote for apenas para Python 3+, " -"escreva::" - -#: ../source/guides/distributing-packages-using-setuptools.rst:407 -msgid "" -"If your package is for Python 2.6, 2.7, and all versions of Python 3 " -"starting with 3.3, write::" -msgstr "" -"Se o seu pacote for para Python 2.6, 2.7 e todas as versões do Python 3 " -"começando com 3.3, escreva::" - -#: ../source/guides/distributing-packages-using-setuptools.rst:412 -msgid "And so on." -msgstr "E por aí vai." - -#: ../source/guides/distributing-packages-using-setuptools.rst:416 -msgid "" -"Support for this feature is relatively recent. Your project's source " -"distributions and wheels (see :ref:`Packaging Your Project`) must be built " -"using at least version 24.2.0 of :ref:`setuptools` in order for the " -"``python_requires`` argument to be recognized and the appropriate metadata " -"generated." -msgstr "" -"O suporte para esse recurso é relativamente recente. As distribuições de " -"código-fonte e wheels do seu projeto (veja :ref:`Empacotando seu projeto " -"`) devem ser construídas usando pelo menos a versão " -"24.2.0 do :ref:`setuptools` para que o argumento ``python_requires`` seja " -"reconhecido e os metadados apropriados gerados." - -#: ../source/guides/distributing-packages-using-setuptools.rst:422 -msgid "" -"In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the " -"``python_requires`` metadata. Users with earlier versions of pip will be " -"able to download & install projects on any Python version regardless of the " -"projects' ``python_requires`` values." -msgstr "" -"Além disso, apenas as versões 9.0.0 e superiores do :ref:`pip` reconhecem os " -"metadados de ``python_requires``. Usuários com versões anteriores do pip " -"serão capazes de baixar e instalar projetos em qualquer versão do Python, " -"independentemente dos valores de ``python_requires`` dos projetos." - -#: ../source/guides/distributing-packages-using-setuptools.rst:431 -msgid "package_data" -msgstr "package_data" - -#: ../source/guides/distributing-packages-using-setuptools.rst:440 -msgid "" -"Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the " -"package’s implementation, or text files containing documentation that might " -"be of interest to programmers using the package. These files are called " -"\"package data\"." -msgstr "" -"Frequentemente, arquivos adicionais precisam ser instalados em um :term:" -"`pacote `. Esses arquivos geralmente são dados intimamente " -"relacionados à implementação do pacote ou arquivos de texto contendo " -"documentação que pode ser do interesse dos programadores que usam o pacote. " -"Esses arquivos são chamados de \"dados do pacote\"." - -#: ../source/guides/distributing-packages-using-setuptools.rst:445 -msgid "" -"The value must be a mapping from package name to a list of relative path " -"names that should be copied into the package. The paths are interpreted as " -"relative to the directory containing the package." -msgstr "" -"O valor deve ser um mapeamento do nome do pacote para uma lista de nomes de " -"caminhos relativos que devem ser copiados para o pacote. Os caminhos são " -"interpretados como relativos ao diretório que contém o pacote." - -#: ../source/guides/distributing-packages-using-setuptools.rst:449 -msgid "" -"For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." -msgstr "" -"Para mais informações, veja :std:doc:`Incluindo arquivos de dados " -"` da :std:doc:`documentação do setuptools " -"`." - -#: ../source/guides/distributing-packages-using-setuptools.rst:457 -msgid "data_files" -msgstr "data_files" - -#: ../source/guides/distributing-packages-using-setuptools.rst:463 -msgid "" -"Although configuring :ref:`Package Data` is sufficient for most needs, in " -"some cases you may need to place data files *outside* of your :term:" -"`packages `. The ``data_files`` directive allows you to do " -"that. It is mostly useful if you need to install files which are used by " -"other programs, which may be unaware of Python packages." -msgstr "" -"Embora configurar :ref:`Dados de pacote ` seja suficiente para " -"a maioria das necessidades, em alguns casos você pode precisar colocar " -"arquivos de dados *fora* de seus :term:`pacotes `. A " -"diretiva ``data_files`` permite que você faça isso. É mais útil se você " -"precisar instalar arquivos que são usados por outros programas, que podem " -"não ter conhecimento dos pacotes Python." - -#: ../source/guides/distributing-packages-using-setuptools.rst:469 -msgid "" -"Each ``(directory, files)`` pair in the sequence specifies the installation " -"directory and the files to install there. The ``directory`` must be a " -"relative path (although this may change in the future, see `wheel Issue #92 " -"`_). and it is interpreted relative " -"to the installation prefix (Python’s ``sys.prefix`` for a default " -"installation; ``site.USER_BASE`` for a user installation). Each file name in " -"``files`` is interpreted relative to the :file:`setup.py` script at the top " -"of the project source distribution." -msgstr "" -"Cada par ``(directory, files)`` na sequência especifica o diretório de " -"instalação e os arquivos a serem instalados nele. O ``directory`` deve ser " -"um caminho relativo (embora isso possa mudar no futuro, consulte `relatório " -"de problema #92 do wheel `_) e é " -"interpretado em relação ao prefixo de instalação (``sys.prefix`` do Python " -"para uma instalação padrão; ``site.USER_BASE`` para uma instalação do " -"usuário). Cada nome de arquivo em ``files`` é interpretado em relação ao " -"script :file:`setup.py` no topo da distribuição do código-fonte do projeto." - -#: ../source/guides/distributing-packages-using-setuptools.rst:479 -msgid "" -"For more information see the distutils section on `Installing Additional " -"Files `_." -msgstr "" -"Para obter mais informações, consulte a seção distutils em `Instalando " -"arquivos adicionais `_." - -#: ../source/guides/distributing-packages-using-setuptools.rst:484 -msgid "" -"When installing packages as egg, ``data_files`` is not supported. So, if " -"your project uses :ref:`setuptools`, you must use ``pip`` to install it. " -"Alternatively, if you must use ``python setup.py``, then you need to pass " -"the ``--old-and-unmanageable`` option." -msgstr "" -"Ao instalar pacotes como ovo, ``data_files`` não é suportado. Então, se seu " -"projeto usa :ref:`setuptools`, você deve usar ``pip`` para instalá-lo. " -"Alternativamente, se você deve usar ``python setup.py``, então você precisa " -"passar a opção ``--old-and-unmanageable``." - -#: ../source/guides/distributing-packages-using-setuptools.rst:491 -msgid "scripts" -msgstr "scripts" - -#: ../source/guides/distributing-packages-using-setuptools.rst:493 -msgid "" -"Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made " -"scripts to install, the recommended approach to achieve cross-platform " -"compatibility is to use :ref:`console_scripts` entry points (see below)." -msgstr "" -"Embora ``setup()`` tenha suporte a uma palavra-chave `scripts `_ para apontar " -"para scripts pré-fabricados para instalar, o recomendado A abordagem para " -"obter compatibilidade entre plataformas é usar pontos de entrada :ref:" -"`console_scripts` (veja abaixo)." - -#: ../source/guides/distributing-packages-using-setuptools.rst:500 -msgid "entry_points" -msgstr "entry_points" - -#: ../source/guides/distributing-packages-using-setuptools.rst:509 -msgid "" -"Use this keyword to specify any plugins that your project provides for any " -"named entry points that may be defined by your project or others that you " -"depend on." -msgstr "" -"Use esta palavra-chave para especificar quaisquer plugins que seu projeto " -"fornece para quaisquer pontos de entrada nomeados que podem ser definidos " -"por seu projeto ou outros dos quais você depende." - -#: ../source/guides/distributing-packages-using-setuptools.rst:512 -msgid "" -"For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." -msgstr "" -"Para obter mais informações, consulte a seção sobre `Comportamento de " -"Publicidade `_ da " -"documentação do :ref:`setuptools`." - -#: ../source/guides/distributing-packages-using-setuptools.rst:516 -msgid "The most commonly used entry point is \"console_scripts\" (see below)." -msgstr "" -"O ponto de entrada mais comumente usado é \"console_scripts\" (veja abaixo)." - -#: ../source/guides/distributing-packages-using-setuptools.rst:521 -msgid "console_scripts" -msgstr "console_scripts" - -#: ../source/guides/distributing-packages-using-setuptools.rst:531 -msgid "" -"Use \"console_script\" `entry points `_ to " -"register your script interfaces. You can then let the toolchain handle the " -"work of turning these interfaces into actual scripts [2]_. The scripts will " -"be generated during the install of your :term:`distribution `." -msgstr "" -"Use `pontos de entrada `_ \"console_script" -"\" para registrar suas interfaces de script. Você pode então deixar o " -"conjunto de ferramentas lidar com o trabalho de transformar essas interfaces " -"em scripts reais [2]_. Os scripts serão gerados durante a instalação do seu :" -"term:`distribuição `." - -#: ../source/guides/distributing-packages-using-setuptools.rst:538 -msgid "" -"For more information, see `Automatic Script Creation `_ from " -"the `setuptools docs `_." -msgstr "" -"Para obter mais informações, consulte `Automatic Script Creation `_ da `documentação do setuptools `_." - -#: ../source/guides/distributing-packages-using-setuptools.rst:545 -msgid "Choosing a versioning scheme" -msgstr "Escolhendo um esquema de versionamento" - -#: ../source/guides/distributing-packages-using-setuptools.rst:548 -msgid "Standards compliance for interoperability" -msgstr "Conformidade de padrões para interoperabilidade" - -#: ../source/guides/distributing-packages-using-setuptools.rst:550 -msgid "" -"Different Python projects may use different versioning schemes based on the " -"needs of that particular project, but all of them are required to comply " -"with the flexible :pep:`public version scheme <440#public-version-" -"identifiers>` specified in :pep:`440` in order to be supported in tools and " -"libraries like ``pip`` and ``setuptools``." -msgstr "" -"Diferentes projetos Python podem usar diferentes esquemas de controle de " -"versão com base nas necessidades daquele projeto específico, mas todos eles " -"são obrigados a cumprir com o :pep:`esquema públicode versão <440#public-" -"version-identifiers>` flexível especificado na :pep:`440` para serem " -"suportados em ferramentas e bibliotecas como ``pip`` e ``setuptools``." - -#: ../source/guides/distributing-packages-using-setuptools.rst:556 -msgid "Here are some examples of compliant version numbers::" -msgstr "Aqui estão alguns exemplos de números de versão compatíveis::" - -#: ../source/guides/distributing-packages-using-setuptools.rst:567 -msgid "" -"To further accommodate historical variations in approaches to version " -"numbering, :pep:`440` also defines a comprehensive technique for :pep:" -"`version normalisation <440#normalization>` that maps variant spellings of " -"different version numbers to a standardised canonical form." -msgstr "" -"Para acomodar ainda mais as variações históricas nas abordagens de numeração " -"de versão, :pep:`440` também define uma técnica abrangente para :pep:" -"`normalização de versão <440#normalization>` que mapeia grafias variantes de " -"diferentes números de versão para uma forma canônica padronizada." - -#: ../source/guides/distributing-packages-using-setuptools.rst:573 -msgid "Scheme choices" -msgstr "Opções de esquema" - -#: ../source/guides/distributing-packages-using-setuptools.rst:576 -msgid "Semantic versioning (preferred)" -msgstr "Versionamento semântico (preferencial)" - -#: ../source/guides/distributing-packages-using-setuptools.rst:578 -msgid "" -"For new projects, the recommended versioning scheme is based on `Semantic " -"Versioning `_, but adopts a different approach to " -"handling pre-releases and build metadata." -msgstr "" -"Para novos projetos, o esquema de controle de versão recomendado é baseado " -"em `Versionamento semântico `_, mas adota uma abordagem " -"diferente para lidar com pré-lançamentos e metadados de compilação." - -#: ../source/guides/distributing-packages-using-setuptools.rst:582 -msgid "" -"The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE " -"numbering scheme, where the project author increments:" -msgstr "" -"A essência do versionamento semântico é um esquema de numeração MAIOR.MENOR." -"MANUTENÇÃO de 3 partes, onde o autor do projeto incrementa:" - -#: ../source/guides/distributing-packages-using-setuptools.rst:585 -msgid "MAJOR version when they make incompatible API changes," -msgstr "Versão PRINCIPAL quando eles fazem alterações de API incompatíveis," - -#: ../source/guides/distributing-packages-using-setuptools.rst:586 -msgid "" -"MINOR version when they add functionality in a backwards-compatible manner, " -"and" -msgstr "" -"Versão MENOR quando adicionam funcionalidade de maneira compatível com " -"versões anteriores, e" - -#: ../source/guides/distributing-packages-using-setuptools.rst:587 -msgid "MAINTENANCE version when they make backwards-compatible bug fixes." -msgstr "" -"Versão MANUTENÇÃO quando eles fazem correções de bugs compatíveis com " -"versões anteriores." - -#: ../source/guides/distributing-packages-using-setuptools.rst:589 -msgid "" -"Adopting this approach as a project author allows users to make use of :pep:`" -"\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= " -"X.Y`` requires at least release X.Y, but also allows any later release with " -"a matching MAJOR version." -msgstr "" -"Adotar essa abordagem como autor do projeto permite que os usuários façam " -"uso dos especificadores de :pep:`\"lançamentos compatíveis\" <440#compatible-" -"release>`, onde ``name ~= X.Y`` requer pelo menos a versão X.Y, mas também " -"permite qualquer versão posterior com uma versão PRINCIPAL correspondente." - -#: ../source/guides/distributing-packages-using-setuptools.rst:594 -msgid "" -"Python projects adopting semantic versioning should abide by clauses 1-8 of " -"the `Semantic Versioning 2.0.0 specification `_." -msgstr "" -"Projetos Python que adotam versões semânticas devem obedecer às cláusulas " -"1-8 da `especificação de Versionamento Semântico 2.0.0 `_." - -#: ../source/guides/distributing-packages-using-setuptools.rst:598 -msgid "Date based versioning" -msgstr "Versionamento baseado em data" - -#: ../source/guides/distributing-packages-using-setuptools.rst:600 -msgid "" -"Semantic versioning is not a suitable choice for all projects, such as those " -"with a regular time based release cadence and a deprecation process that " -"provides warnings for a number of releases prior to removal of a feature." -msgstr "" -"O versionamento semântico não é uma escolha adequada para todos os projetos, " -"como aqueles com uma cadência de lançamento baseada em tempo regular e um " -"processo de descontinuidade que fornece avisos para vários lançamentos antes " -"da remoção de um recurso." - -#: ../source/guides/distributing-packages-using-setuptools.rst:604 -msgid "" -"A key advantage of date based versioning is that it is straightforward to " -"tell how old the base feature set of a particular release is given just the " -"version number." -msgstr "" -"Uma vantagem principal do versionamento baseado em data é que é simples " -"dizer quantos anos o conjunto de recursos básicos de uma determinada versão " -"recebe apenas o número da versão." - -#: ../source/guides/distributing-packages-using-setuptools.rst:607 -msgid "" -"Version numbers for date based projects typically take the form of YEAR." -"MONTH (for example, ``12.04``, ``15.10``)." -msgstr "" -"Os números de versão para projetos baseados em data normalmente assumem a " -"forma de ANO.MÊS (por exemplo, ``12.04``, ``15.10``)." - -#: ../source/guides/distributing-packages-using-setuptools.rst:611 -msgid "Serial versioning" -msgstr "Versionamento serial" - -#: ../source/guides/distributing-packages-using-setuptools.rst:613 -msgid "" -"This is the simplest possible versioning scheme, and consists of a single " -"number which is incremented every release." -msgstr "" -"Este é o esquema de versionamento mais simples possível e consiste em um " -"único número que é incrementado a cada versão." - -#: ../source/guides/distributing-packages-using-setuptools.rst:616 -msgid "" -"While serial versioning is very easy to manage as a developer, it is the " -"hardest to track as an end user, as serial version numbers convey little or " -"no information regarding API backwards compatibility." -msgstr "" -"Embora o versionamento serial seja muito fácil de gerenciar como " -"desenvolvedor, é o mais difícil de rastrear como usuário final, pois os " -"números de versão serial transmitem pouca ou nenhuma informação sobre " -"compatibilidade com versões anteriores da API." - -#: ../source/guides/distributing-packages-using-setuptools.rst:621 -msgid "Hybrid schemes" -msgstr "Esquemas híbridos" - -#: ../source/guides/distributing-packages-using-setuptools.rst:623 -msgid "" -"Combinations of the above schemes are possible. For example, a project may " -"combine date based versioning with serial versioning to create a YEAR.SERIAL " -"numbering scheme that readily conveys the approximate age of a release, but " -"doesn't otherwise commit to a particular release cadence within the year." -msgstr "" -"Combinações dos esquemas acima são possíveis. Por exemplo, um projeto pode " -"combinar o versionamento baseado em data com o versionamento serial para " -"criar um esquema de numeração ANO.SÉRIE que transmite prontamente a idade " -"aproximada de um lançamento, mas não se compromete com uma cadência de " -"lançamento particular dentro do ano." - -#: ../source/guides/distributing-packages-using-setuptools.rst:629 -msgid "Pre-release versioning" -msgstr "Versionamento de pré-lançamento" - -#: ../source/guides/distributing-packages-using-setuptools.rst:631 -msgid "" -"Regardless of the base versioning scheme, pre-releases for a given final " -"release may be published as:" -msgstr "" -"Independentemente do esquema de versionamento base, os pré-lançamentos para " -"uma determinada versão final podem ser publicados como:" - -#: ../source/guides/distributing-packages-using-setuptools.rst:634 -msgid "zero or more dev releases (denoted with a \".devN\" suffix)" -msgstr "zero ou mais versões dev (denotadas com um sufixo \".devN\")" - -#: ../source/guides/distributing-packages-using-setuptools.rst:635 -msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" -msgstr "zero ou mais versões alfa (denotadas com um sufixo \".aN\")" - -#: ../source/guides/distributing-packages-using-setuptools.rst:636 -msgid "zero or more beta releases (denoted with a \".bN\" suffix)" -msgstr "zero ou mais versões beta (denotadas com um sufixo \".bN\")" - -#: ../source/guides/distributing-packages-using-setuptools.rst:637 -msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" -msgstr "" -"zero ou mais candidatos a lançamento (denotados com um sufixo \".rcN\")" - -#: ../source/guides/distributing-packages-using-setuptools.rst:639 -msgid "" -"``pip`` and other modern Python package installers ignore pre-releases by " -"default when deciding which versions of dependencies to install." -msgstr "" -"``pip`` e outros instaladores de pacotes Python modernos ignoram os pré-" -"lançamentos por padrão ao decidir quais versões de dependências instalar." - -#: ../source/guides/distributing-packages-using-setuptools.rst:644 -msgid "Local version identifiers" -msgstr "Identificadores de versão local" - -#: ../source/guides/distributing-packages-using-setuptools.rst:646 -msgid "" -"Public version identifiers are designed to support distribution via :term:" -"`PyPI `. Python's software distribution tools " -"also support the notion of a :pep:`local version identifier <440#local-" -"version-identifiers>`, which can be used to identify local development " -"builds not intended for publication, or modified variants of a release " -"maintained by a redistributor." -msgstr "" -"Identificadores de versão pública são projetados para suportar distribuição " -"via :term:`PyPI `. As ferramentas de " -"distribuição de software do Python também suportam a noção de um :pep:" -"`identificador de versão local <440#local-version-identifiers>`, que pode " -"ser usado para identificar compilações de desenvolvimento local não " -"destinadas à publicação, ou variantes modificadas de uma versão mantida por " -"um redistribuidor." - -#: ../source/guides/distributing-packages-using-setuptools.rst:653 -msgid "" -"A local version identifier takes the form ``" -"+``. For example::" -msgstr "" -"Um identificador de versão local assume a forma ``+``. Por exemplo::" - -#: ../source/guides/distributing-packages-using-setuptools.rst:661 -msgid "Working in \"development mode\"" -msgstr "Trabalhando em \"modo de desenvolvimento\"" - -#: ../source/guides/distributing-packages-using-setuptools.rst:663 -msgid "" -"Although not required, it's common to locally install your project in " -"\"editable\" or \"develop\" mode while you're working on it. This allows " -"your project to be both installed and editable in project form." -msgstr "" -"Embora não seja obrigatório, é comum instalar localmente seu projeto no modo " -"\"editável\" ou \"desenvolvimento\" enquanto você trabalha nele. Isso " -"permite que seu projeto seja instalado e editável na forma de projeto." - -#: ../source/guides/distributing-packages-using-setuptools.rst:667 -msgid "Assuming you're in the root of your project directory, then run:" -msgstr "Supondo que você esteja na raiz do diretório do seu projeto, execute:" - -#: ../source/guides/distributing-packages-using-setuptools.rst:674 -msgid "" -"Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` " -"refers to the current working directory, so together, it means to install " -"the current directory (i.e. your project) in editable mode. This will also " -"install any dependencies declared with \"install_requires\" and any scripts " -"declared with \"console_scripts\". Dependencies will be installed in the " -"usual, non-editable mode." -msgstr "" -"Embora um pouco enigmático, ``-e`` é abreviação de ``--editable``, e ``.`` " -"refere-se ao diretório de trabalho atual, então juntos, isso significa " -"instalar o diretório atual (ou seja, seu projeto) em modo editável. Isso " -"também instalará quaisquer dependências declaradas com \"install_requires\" " -"e quaisquer scripts declarados com \"console_scripts\". As dependências " -"serão instaladas no modo usual e não editável." - -#: ../source/guides/distributing-packages-using-setuptools.rst:680 -msgid "" -"It's fairly common to also want to install some of your dependencies in " -"editable mode as well. For example, supposing your project requires \"foo\" " -"and \"bar\", but you want \"bar\" installed from VCS in editable mode, then " -"you could construct a requirements file like so::" -msgstr "" -"É bastante comum também querer instalar algumas de suas dependências no modo " -"editável. Por exemplo, supondo que seu projeto requer \"foo\" e \"bar\", mas " -"você deseja \"bar\" instalado do VCS no modo editável, então você poderia " -"construir um arquivo de requisitos como::" - -#: ../source/guides/distributing-packages-using-setuptools.rst:688 -msgid "" -"The first line says to install your project and any dependencies. The second " -"line overrides the \"bar\" dependency, such that it's fulfilled from VCS, " -"not PyPI." -msgstr "" -"A primeira linha diz para instalar seu projeto e todas as dependências. A " -"segunda linha substitui a dependência \"bar\", de modo que seja preenchida a " -"partir do VCS, não PyPI." - -#: ../source/guides/distributing-packages-using-setuptools.rst:692 -msgid "" -"If, however, you want \"bar\" installed from a local directory in editable " -"mode, the requirements file should look like this, with the local paths at " -"the top of the file::" -msgstr "" -"Se, no entanto, você quiser \"bar\" instalado de um diretório local em modo " -"editável, o arquivo de requisitos deve ser semelhante a este, com os " -"caminhos locais no topo do arquivo::" - -#: ../source/guides/distributing-packages-using-setuptools.rst:697 -msgid "" -"Otherwise, the dependency will be fulfilled from PyPI, due to the " -"installation order of the requirements file. For more on requirements " -"files, see the :ref:`Requirements File ` section in " -"the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." -msgstr "" -"Caso contrário, a dependência será resolvida pelo PyPI, devido à ordem de " -"instalação do arquivo de requisitos. Para mais informações sobre os arquivos " -"de requisitos, consulte a seção :ref:`Requirements File ` na documentação do pip. Para obter mais informações sobre as " -"instalações de VCS, consulte a seção :ref:`VCS Support ` da " -"documentação do pip." - -#: ../source/guides/distributing-packages-using-setuptools.rst:701 -msgid "" -"Lastly, if you don't want to install any dependencies at all, you can run::" -msgstr "" -"Por último, se você não deseja instalar nenhuma dependência, pode executar::" - -#: ../source/guides/distributing-packages-using-setuptools.rst:706 -msgid "" -"For more information, see the `Development Mode `_ section of the " -"`setuptools docs `_." -msgstr "" -"Para obter mais informações, consulte a seção `Development Mode `_ da " -"`documentação do setuptools `_." - -#: ../source/guides/distributing-packages-using-setuptools.rst:713 -msgid "Packaging your project" -msgstr "Empacotando seu projeto" - -#: ../source/guides/distributing-packages-using-setuptools.rst:715 -msgid "" -"To have your project installable from a :term:`Package Index` like :term:" -"`PyPI `, you'll need to create a :term:" -"`Distribution ` (aka \":term:`Package `\") for your project." -msgstr "" -"Para ter seu projeto instalável de um :term:`Índice de Pacotes` como o :term:" -"`PyPI `, você precisará criar uma :term:" -"`Distribuição ` (também conhecida como \":term:`Pacote " -"`\") para seu projeto." - -#: ../source/guides/distributing-packages-using-setuptools.rst:720 -msgid "" -"Before you can build wheels and sdists for your project, you'll need to " -"install the ``build`` package:" -msgstr "" -"Antes de compilar wheels e sdists para seu projeto, você precisará instalar " -"o pacote ``build``:" - -#: ../source/guides/distributing-packages-using-setuptools.rst:737 -msgid "Source distributions" -msgstr "Distribuições fontes" - -#: ../source/guides/distributing-packages-using-setuptools.rst:739 -msgid "" -"Minimally, you should create a :term:`Source Distribution `:" -msgstr "" -"Minimamente, você deve criar uma :term:`Distribuição Fonte `:" - -#: ../source/guides/distributing-packages-using-setuptools.rst:755 -msgid "" -"A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built " -"Distribution`), and requires a build step when installed by pip. Even if " -"the distribution is pure Python (i.e. contains no extensions), it still " -"involves a build step to build out the installation metadata from :file:" -"`setup.py` and/or :file:`setup.cfg`." -msgstr "" -"Uma \"distribuição fonte\" é não construída (ou seja, não é uma :term:" -"`Distribuição Construída`) e requer uma etapa de construção quando instalada " -"pelo pip. Mesmo se a distribuição for puro Python (ou seja, não contém " -"extensões), ainda envolve uma etapa de construção para construir os " -"metadados de instalação de :file:`setup.py` e/ou :file:`setup.cfg`." - -#: ../source/guides/distributing-packages-using-setuptools.rst:763 -msgid "Wheels" -msgstr "Wheels" - -#: ../source/guides/distributing-packages-using-setuptools.rst:765 -msgid "" -"You should also create a wheel for your project. A wheel is a :term:`built " -"package ` that can be installed without needing to go " -"through the \"build\" process. Installing wheels is substantially faster for " -"the end user than installing from a source distribution." -msgstr "" -"Você também deve criar uma wheel para o seu projeto. Uma wheel é um :term:" -"`pacote construído ` que pode ser instalado sem a " -"necessidade de passar pelo processo de \"construção\". Instalar wheel é " -"substancialmente mais rápido para o usuário final do que instalar a partir " -"de uma distribuição original." - -#: ../source/guides/distributing-packages-using-setuptools.rst:770 -msgid "" -"If your project is pure Python then you'll be creating a :ref:`\"Pure Python " -"Wheel\" (see section below) `." -msgstr "" -"Se o seu projeto for puro Python, você criará uma :ref:`\"Wheel de Python " -"Puro\" (consulte a seção abaixo) `." - -#: ../source/guides/distributing-packages-using-setuptools.rst:773 -msgid "" -"If your project contains compiled extensions, then you'll be creating what's " -"called a :ref:`*Platform Wheel* (see section below) `." -msgstr "" -"Se o seu projeto contém extensões compiladas, então você criará o que é " -"chamado de :ref:`*Wheel de Plataforma* (veja a seção abaixo) `." - -#: ../source/guides/distributing-packages-using-setuptools.rst:776 -msgid "" -"If your project also supports Python 2 *and* contains no C extensions, then " -"you should create what's called a *Universal Wheel* by adding the following " -"to your :file:`setup.cfg` file:" -msgstr "" -"Se o seu projeto também tiver suporte a Python 2 *e* não contiver extensões " -"C, você deve criar o que é chamado de *Wheel Universal* adicionando o " -"seguinte ao seu arquivo :file:`setup.cfg`:" - -#: ../source/guides/distributing-packages-using-setuptools.rst:785 -msgid "" -"Only use this setting if your project does not have any C extensions *and* " -"supports Python 2 and 3." -msgstr "" -"Use esta configuração apenas se o seu projeto não tiver extensões C *e* " -"tiver suporte ao Python 2 e 3." - -#: ../source/guides/distributing-packages-using-setuptools.rst:792 -msgid "Pure Python Wheels" -msgstr "Wheels de Puro Python" - -#: ../source/guides/distributing-packages-using-setuptools.rst:794 -msgid "" -"*Pure Python Wheels* contain no compiled extensions, and therefore only " -"require a single Python wheel." -msgstr "" -"*Wheels de Python Puro* contêm nenhuma extensão compilada e, portanto, só " -"exigem um único wheel Python." - -#: ../source/guides/distributing-packages-using-setuptools.rst:797 -#: ../source/guides/distributing-packages-using-setuptools.rst:826 -msgid "To build the wheel:" -msgstr "Para construir o wheel:" - -#: ../source/guides/distributing-packages-using-setuptools.rst:811 -msgid "" -"The ``wheel`` package will detect that the code is pure Python, and build a " -"wheel that's named such that it's usable on any Python 3 installation. For " -"details on the naming of wheel files, see :pep:`425`." -msgstr "" -"O pacote ``wheel`` detectará que o código é puro Python, e construirá um " -"wheel cujo nome pode ser usado em qualquer instalação do Python 3. Para " -"obter detalhes sobre a nomenclatura de arquivos wheel, consulte :pep:`425`." - -#: ../source/guides/distributing-packages-using-setuptools.rst:815 -msgid "" -"If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both " -"files for you; this is useful when you don't need multiple wheels." -msgstr "" -"Se você executar ``build`` sem ``--wheel`` ou ``--sdist``, ele irá construir " -"os dois arquivos para você; isso é útil quando você não precisa de vários " -"wheels." - -#: ../source/guides/distributing-packages-using-setuptools.rst:821 -msgid "Platform Wheels" -msgstr "Wheels de Plataforma" - -#: ../source/guides/distributing-packages-using-setuptools.rst:823 -msgid "" -"*Platform Wheels* are wheels that are specific to a certain platform like " -"Linux, macOS, or Windows, usually due to containing compiled extensions." -msgstr "" -"*Wheels de Plataforma* são wheels que são específicos para uma certa " -"plataforma, como Linux, macOS ou Windows, geralmente em razão de conter " -"extensões compiladas." - -#: ../source/guides/distributing-packages-using-setuptools.rst:841 -msgid "" -"The ``wheel`` package will detect that the code is not pure Python, and " -"build a wheel that's named such that it's only usable on the platform that " -"it was built on. For details on the naming of wheel files, see :pep:`425`." -msgstr "" -"O pacote ``wheel`` detectará que o código não é puro Python e construirá um " -"wheel cujo nome só pode ser usado na plataforma em que foi construído. Para " -"obter detalhes sobre a nomenclatura de arquivos wheel, consulte :pep:`425`." - -#: ../source/guides/distributing-packages-using-setuptools.rst:847 -msgid "" -":term:`PyPI ` currently supports uploads of " -"platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. " -"Details of the latter are defined in :pep:`513`." -msgstr "" -":term:`PyPI ` oferece suporte atualmente a " -"envios de wheels de plataforma do Windows, macOS e da ABI multidistro " -"``manylinux*``. Detalhes sobre o último estão definidos em :pep:`513`." - -#: ../source/guides/distributing-packages-using-setuptools.rst:855 -msgid "Uploading your Project to PyPI" -msgstr "Enviando seu Projeto para PyPI" - -#: ../source/guides/distributing-packages-using-setuptools.rst:857 -msgid "" -"When you ran the command to create your distribution, a new directory ``dist/" -"`` was created under your project's root directory. That's where you'll find " -"your distribution file(s) to upload." -msgstr "" -"Quando você executou o comando para criar sua distribuição, um novo " -"diretório ``dist/`` foi criado no diretório raiz do seu projeto. É onde você " -"encontrará seus arquivos de distribuição para enviar." - -#: ../source/guides/distributing-packages-using-setuptools.rst:861 -msgid "" -"These files are only created when you run the command to create your " -"distribution. This means that any time you change the source of your project " -"or the configuration in your :file:`setup.py` file, you will need to rebuild " -"these files again before you can distribute the changes to PyPI." -msgstr "" -"Esses arquivos são criados apenas quando você executa o comando para criar " -"sua distribuição. Isso significa que a qualquer momento que você alterar a " -"fonte do seu projeto ou a configuração no arquivo :file:`setup.py`, você " -"precisará reconstruir esses arquivos novamente antes de distribuir as " -"alterações para PyPI." - -#: ../source/guides/distributing-packages-using-setuptools.rst:866 -msgid "" -"Before releasing on main PyPI repo, you might prefer training with the `PyPI " -"test site `_ which is cleaned on a semi regular " -"basis. See :ref:`using-test-pypi` on how to setup your configuration in " -"order to use it." -msgstr "" -"Antes de lançar no repositório principal do PyPI, você pode preferir treinar " -"com o `site de teste do PyPI `_ que é redefinido em " -"uma base semirregular. Veja :ref:`using-test-pypi` sobre como definir sua " -"configuração para usá-lo." - -#: ../source/guides/distributing-packages-using-setuptools.rst:871 -msgid "" -"In other resources you may encounter references to using ``python setup.py " -"register`` and ``python setup.py upload``. These methods of registering and " -"uploading a package are **strongly discouraged** as it may use a plaintext " -"HTTP or unverified HTTPS connection on some Python versions, allowing your " -"username and password to be intercepted during transmission." -msgstr "" -"Em outros recursos, você pode encontrar referências ao uso de ``python setup." -"py register`` e ``python setup.py upload``. Esses métodos de registro e " -"envio de um pacote são **fortemente desencorajados**, pois podem usar uma " -"conexão HTTP de texto simples ou HTTPS não verificada em algumas versões " -"Python, permitindo que seu nome de usuário e senha sejam interceptados " -"durante a transmissão." - -#: ../source/guides/distributing-packages-using-setuptools.rst:877 -msgid "" -"The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to " -"ensure safety of all users, certain kinds of URLs and directives are " -"forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** " -"trying to upload your distribution, you should check to see if your brief / " -"long descriptions provided in :file:`setup.py` are valid. You can do this " -"by running :std:doc:`twine check ` on your package files::" -msgstr "" -"O analisador de reStructuredText usado no PyPI **não é** Sphinx! Além disso, " -"para garantir a segurança de todos os usuários, certos tipos de URLs e " -"diretivas são proibidos ou removidos (por exemplo, a diretiva ``.. raw::``). " -"**Antes** de tentar enviar sua distribuição, você deve verificar se suas " -"descrições breves/longas fornecidas no :file:`setup.py` são válidas. Você " -"pode fazer isso executando :std:doc:`twine check ` em todos arquivos " -"do seu pacote::" - -#: ../source/guides/distributing-packages-using-setuptools.rst:888 -msgid "Create an account" -msgstr "Criar uma conta" - -#: ../source/guides/distributing-packages-using-setuptools.rst:890 -msgid "" -"First, you need a :term:`PyPI ` user account. " -"You can create an account `using the form on the PyPI website `_." -msgstr "" -"Primeiro, você precisa de uma conta de usuário do :term:`PyPI `. Você pode criar uma conta `usando o formulário no " -"site do PyPI `_." - -#: ../source/guides/distributing-packages-using-setuptools.rst:894 -msgid "" -"Now you'll create a PyPI `API token`_ so you will be able to securely upload " -"your project." -msgstr "" -"Agora você criará um PyPI `token de API `_ para que possa enviar " -"o seu projeto com segurança." - -#: ../source/guides/distributing-packages-using-setuptools.rst:897 -msgid "" -"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " -"token`_; don't limit its scope to a particular project, since you are " -"creating a new project." -msgstr "" -"Acesse https://pypi.org/manage/account/#api-tokens e crie um novo `API de " -"token `_; não limite seu escopo a um projeto específico, já que " -"você está criando um novo projeto." - -#: ../source/guides/distributing-packages-using-setuptools.rst:901 -msgid "" -"**Don't close the page until you have copied and saved the token — you won't " -"see that token again.**" -msgstr "" -"**Não feche a página antes de copiar e salvar o token -- você não verá o " -"token novamente.**" - -#: ../source/guides/distributing-packages-using-setuptools.rst:904 -msgid "" -"To avoid having to copy and paste the token every time you upload, you can " -"create a :file:`$HOME/.pypirc` file:" -msgstr "" -"Para evitar ter que copiar e colar o token toda vez que você enviar, você " -"pode criar um arquivo :file:`$HOME/.pypirc`:" - -#: ../source/guides/distributing-packages-using-setuptools.rst:913 -msgid "**Be aware that this stores your token in plaintext.**" -msgstr "**Esteja ciente de que isso armazena seu token em texto simples.**" - -#: ../source/guides/distributing-packages-using-setuptools.rst:915 -#: ../source/guides/migrating-to-pypi-org.rst:70 -#: ../source/guides/migrating-to-pypi-org.rst:109 -#: ../source/guides/using-testpypi.rst:83 -msgid "" -"For more details, see the :ref:`specification ` for :file:`.pypirc`." -msgstr "" -"Para mais detalhes, veja a :ref:`especificação ` do :file:`.pypirc`." - -#: ../source/guides/distributing-packages-using-setuptools.rst:921 -msgid "Upload your distributions" -msgstr "Enviar suas distribuições" - -#: ../source/guides/distributing-packages-using-setuptools.rst:923 -msgid "" -"Once you have an account you can upload your distributions to :term:`PyPI " -"` using :ref:`twine`." -msgstr "" -"Assim que tiver uma conta, você pode enviar suas distribuições para o :term:" -"`PyPI ` usando :ref:`twine`." - -#: ../source/guides/distributing-packages-using-setuptools.rst:926 -msgid "" -"The process for uploading a release is the same regardless of whether or not " -"the project already exists on PyPI - if it doesn't exist yet, it will be " -"automatically created when the first release is uploaded." -msgstr "" -"O processo de envio de uma versão é o mesmo, independentemente de o projeto " -"já existir ou não no PyPI -- se ainda não existir, será criado " -"automaticamente quando a primeira versão for carregada." - -#: ../source/guides/distributing-packages-using-setuptools.rst:930 -msgid "" -"For the second and subsequent releases, PyPI only requires that the version " -"number of the new release differ from any previous releases." -msgstr "" -"Para a segunda versão e as subsequentes, PyPI requer apenas que o número da " -"versão da nova versão seja diferente de todas as versões anteriores." - -#: ../source/guides/distributing-packages-using-setuptools.rst:937 -msgid "" -"You can see if your package has successfully uploaded by navigating to the " -"URL ``https://pypi.org/project/`` where ``sampleproject`` is " -"the name of your project that you uploaded. It may take a minute or two for " -"your project to appear on the site." -msgstr "" -"Você pode ver se o seu pacote foi enviado com sucesso navegando para a URL " -"``https://pypi.org/project/`` onde ``projetoexemplo`` é o " -"nome do seu projeto que você enviou. O seu projeto pode demorar um ou dois " -"minutos para aparecer no site." - -#: ../source/guides/distributing-packages-using-setuptools.rst:944 -#: ../source/tutorials/installing-packages.rst:663 -msgid "" -"Depending on your platform, this may require root or Administrator access. :" -"ref:`pip` is currently considering changing this by `making user installs " -"the default behavior `_." -msgstr "" -"Dependendo da sua plataforma, isso pode exigir acesso de root ou de " -"administrador. :ref:`pip` está atualmente considerando mudar isso `tornando " -"as instalações de usuário o comportamento padrão `_." - -#: ../source/guides/distributing-packages-using-setuptools.rst:950 -msgid "" -"Specifically, the \"console_script\" approach generates ``.exe`` files on " -"Windows, which are necessary because the OS special-cases ``.exe`` files. " -"Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for " -"Windows <397>` allow scripts to be used in many cases, but not all." -msgstr "" -"Especificamente, a abordagem \"console_script\" gera arquivos ``.exe`` no " -"Windows, que são necessários por causa dos arquivos ``.exe`` de casos " -"especiais do sistema operacional. Recursos de execução de script como " -"``PATHEXT`` e o :pep:`Inicializador do Python para Windows <397>` permitem " -"que scripts sejam usados em muitos casos, mas não em todos." - -#: ../source/guides/dropping-older-python-versions.rst:5 -msgid "Dropping support for older Python versions" -msgstr "Descartando suporte para versões mais antigas do Python" - -#: ../source/guides/dropping-older-python-versions.rst:7 -msgid "" -"Dropping support for older Python versions is supported by the standard :ref:" -"`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." -msgstr "" -"O descarte de suporte para versões mais antigas do Python é suportado pela " -"especificação padrão :ref:`core-metadata` 1.2 através de um atributo " -"\"Requires-Python\"." - -#: ../source/guides/dropping-older-python-versions.rst:9 -msgid "" -"Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification " -"by matching the current Python runtime and comparing it with the required " -"version in the package metadata. If they do not match, it will attempt to " -"install the last package distribution that supported that Python runtime." -msgstr "" -"Clientes com Metadata 1.2+, como Pip 9.0+, irão aderir a esta especificação " -"combinando o tempo de execução Python atual e comparando-o com a versão " -"necessária nos metadados do pacote. Se eles não corresponderem, ele tentará " -"instalar a última distribuição de pacote que oferece suporte a esse tempo de " -"execução do Python." - -#: ../source/guides/dropping-older-python-versions.rst:12 -msgid "" -"This mechanism can be used to drop support for older Python versions, by " -"amending the \"Requires-Python\" attribute in the package metadata." -msgstr "" -"Este mecanismo pode ser usado para descartar o suporte para versões mais " -"antigas do Python, alterando o atributo \"Requires-Python\" nos metadados do " -"pacote." - -#: ../source/guides/dropping-older-python-versions.rst:14 -msgid "" -"This guide is specifically for users of :ref:`setuptools`, other packaging " -"tools such as ``flit`` may offer similar functionality but users will need " -"to consult relevant documentation." -msgstr "" -"Este guia é especificamente para usuários de :ref:`setuptools`, outras " -"ferramentas de empacotamento como ``flit`` podem oferecer funcionalidade " -"semelhante, mas os usuários precisarão consultar a documentação relevante." - -#: ../source/guides/dropping-older-python-versions.rst:17 -msgid "Requirements" -msgstr "Requisitos" - -#: ../source/guides/dropping-older-python-versions.rst:19 -msgid "This workflow requires that:" -msgstr "Este fluxo de trabalho exige que:" - -#: ../source/guides/dropping-older-python-versions.rst:21 -msgid "The publisher is using the latest version of :ref:`setuptools`," -msgstr "O editor esteja usando a versão mais recente de :ref:`setuptools`," - -#: ../source/guides/dropping-older-python-versions.rst:22 -msgid "The latest version of :ref:`twine` is used to upload the package," -msgstr "A última versão do :ref:`twine` seja usada para enviar o pacote," - -#: ../source/guides/dropping-older-python-versions.rst:23 -msgid "" -"The user installing the package has at least Pip 9.0, or a client that " -"supports the Metadata 1.2 specification." -msgstr "" -"O usuário que instala o pacote tenha pelo menos Pip 9.0 ou um cliente que " -"tenha suporte à especificação Metadata 1.2." - -#: ../source/guides/dropping-older-python-versions.rst:26 -msgid "Dealing with the universal wheels" -msgstr "Lidando com os wheels universais" - -#: ../source/guides/dropping-older-python-versions.rst:28 -msgid "" -"Traditionally, projects providing Python code that is semantically " -"compatible with both Python 2 and Python 3, produce :term:`wheels ` " -"that have a ``py2.py3`` tag in their names. When dropping support for Python " -"2, it is important not to forget to change this tag to just ``py3``. It is " -"often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` " -"section by setting ``universal = 1`` if they use setuptools." -msgstr "" -"Tradicionalmente, os projetos que fornecem código Python que é " -"semanticamente compatível com Python 2 e Python 3, produzem :term:`wheels " -"` que têm uma tag ``py2.py3`` em seus nomes. Ao descartar o suporte " -"para Python 2, é importante não se esquecer de alterar essa tag para apenas " -"``py3``. Isso geralmente é configurado em :file:`setup.cfg` na seção " -"``[bdist_wheel]`` definindo ``universal = 1`` se eles usam setuptools." - -#: ../source/guides/dropping-older-python-versions.rst:36 -msgid "" -"If you use this method, either remove this option or section, or explicitly " -"set ``universal`` to ``0``:" -msgstr "" -"Se você usar este método, remova esta opção ou seção, ou defina " -"explicitamente ``universal`` como ``0``:" - -#: ../source/guides/dropping-older-python-versions.rst:48 -msgid "" -"Since it is possible to override the :file:`setup.cfg` settings via CLI " -"flags, make sure that your scripts don't have ``--universal`` in your " -"package creation scripts." -msgstr "" -"Visto que ser possível sobrescrever as configurações de :file:`setup.cfg` " -"via sinalizadores CLI, certifique-se de que seus scripts não tenham ``--" -"universal`` em seus scripts de criação de pacote." - -#: ../source/guides/dropping-older-python-versions.rst:53 -msgid "Defining the Python version required" -msgstr "Definindo a versão Python exigida" - -#: ../source/guides/dropping-older-python-versions.rst:56 -msgid "1. Download the newest version of Setuptools" -msgstr "1. Baixe a versão mais recente do Setuptools" - -#: ../source/guides/dropping-older-python-versions.rst:58 -msgid "" -"Ensure that before you generate source distributions or binary " -"distributions, you update Setuptools and install twine." -msgstr "" -"Certifique-se de, antes de gerar distribuições de fontes ou distribuições " -"binárias, atualizar o Setuptools e instalar o twine." - -#: ../source/guides/dropping-older-python-versions.rst:60 -msgid "Steps:" -msgstr "Passos:" - -#: ../source/guides/dropping-older-python-versions.rst:74 -msgid "`setuptools` version should be above 24.0.0." -msgstr "A versão do `setuptools` deve ser superior a 24.0.0." - -#: ../source/guides/dropping-older-python-versions.rst:77 -msgid "2. Specify the version ranges for supported Python distributions" -msgstr "" -"2. Especifique os intervalos de versão para distribuições Python suportadas" - -#: ../source/guides/dropping-older-python-versions.rst:79 -msgid "" -"You can specify version ranges and exclusion rules, such as at least Python " -"3. Or, Python 2.7, 3.4 and beyond." -msgstr "" -"Você pode especificar intervalos de versão e regras de exclusão, como pelo " -"menos Python 3. Ou Python 2.7, 3.4 e superior." - -#: ../source/guides/dropping-older-python-versions.rst:81 -#: ../source/specifications/core-metadata.rst:139 -#: ../source/specifications/core-metadata.rst:463 -#: ../source/specifications/core-metadata.rst:487 -#: ../source/specifications/core-metadata.rst:527 -#: ../source/specifications/core-metadata.rst:550 -#: ../source/specifications/core-metadata.rst:583 -#: ../source/specifications/core-metadata.rst:693 -#: ../source/specifications/core-metadata.rst:722 -msgid "Examples::" -msgstr "Exemplos::" - -#: ../source/guides/dropping-older-python-versions.rst:86 -msgid "" -"The way to set those values is within the call to ``setup`` within your :" -"file:`setup.py` script. This will insert the ``Requires-Python`` metadata " -"values based on the argument you provide in ``python_requires``." -msgstr "" -"A maneira de definir esses valores está na chamada de ``setup`` dentro do " -"seu script :file:`setup.py`. Isso irá inserir os valores de metadados " -"``Requires-Python`` com base no argumento fornecido em ``python_requires``." - -#: ../source/guides/dropping-older-python-versions.rst:101 -msgid "3. Validating the Metadata before publishing" -msgstr "3. Validando o Metadata antes de publicar" - -#: ../source/guides/dropping-older-python-versions.rst:103 -msgid "" -"Within a Python source package (the zip or the tar-gz file you download) is " -"a text file called PKG-INFO." -msgstr "" -"Dentro de um pacote fonte Python (o arquivo zip ou tar-gz que você baixou) " -"está um arquivo de texto chamado PKG-INFO." - -#: ../source/guides/dropping-older-python-versions.rst:105 -msgid "" -"This file is generated by Distutils or :ref:`setuptools` when it generates " -"the source package. The file contains a set of keys and values, the list of " -"keys is part of the PyPa standard metadata format." -msgstr "" -"Este arquivo é gerado pelo Distutils ou :ref:`setuptools` quando ele gera o " -"pacote fonte. O arquivo contém um conjunto de chaves e valores, a lista de " -"chaves faz parte do formato de metadados padrão do PyPa." - -#: ../source/guides/dropping-older-python-versions.rst:108 -msgid "You can see the contents of the generated file like this::" -msgstr "Você pode ver o conteúdo do arquivo gerado assim::" - -#: ../source/guides/dropping-older-python-versions.rst:112 -msgid "Validate that the following is in place, before publishing the package:" -msgstr "Valide que o seguinte está no lugar, antes de publicar o pacote:" - -#: ../source/guides/dropping-older-python-versions.rst:114 -msgid "" -"If you have upgraded correctly, the Metadata-Version value should be 1.2 or " -"higher." -msgstr "" -"Se você atualizou corretamente, o valor de Metadata-Version deve ser 1.2 ou " -"superior." - -#: ../source/guides/dropping-older-python-versions.rst:115 -msgid "" -"The Requires-Python field is set and matches your specification in setup.py." -msgstr "" -"O campo Requires-Python está definido e corresponde a sua especificação no " -"setup.py." - -#: ../source/guides/dropping-older-python-versions.rst:118 -msgid "4. Using Twine to publish" -msgstr "4. Usando Twine para publicar" - -#: ../source/guides/dropping-older-python-versions.rst:120 -msgid "" -"Twine has a number of advantages, apart from being faster it is now the " -"supported method for publishing packages." -msgstr "" -"Twine tem uma série de vantagens, além de ser mais rápido, agora é o método " -"suportado para publicação de pacotes." - -#: ../source/guides/dropping-older-python-versions.rst:122 -msgid "Make sure you are using the newest version of Twine, at least 1.9." -msgstr "" -"Certifique-se de estar usando a versão mais recente do Twine, pelo menos 1.9." - -#: ../source/guides/dropping-older-python-versions.rst:125 -msgid "Dropping a Python release" -msgstr "Descartando uma versão Python" - -#: ../source/guides/dropping-older-python-versions.rst:127 -msgid "" -"Once you have published a package with the Requires-Python metadata, you can " -"then make a further update removing that Python runtime from support." -msgstr "" -"Depois de publicar um pacote com os metadados de Requires-Python, você pode " -"fazer uma atualização adicional removendo esse tempo de execução Python do " -"suporte." - -#: ../source/guides/dropping-older-python-versions.rst:129 -msgid "It must be done in this order for the automated fallback to work." -msgstr "" -"Deve ser feito nesta ordem para que o alternativa automatizada funcione." - -#: ../source/guides/dropping-older-python-versions.rst:131 -msgid "" -"For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 " -"of your package." -msgstr "" -"Por exemplo, você publicou o Requires-Python: \">=2.7\" como a versão 1.0.0 " -"do seu pacote." - -#: ../source/guides/dropping-older-python-versions.rst:133 -msgid "" -"If you were then to update the version string to \">=3.5\", and publish a " -"new version 2.0.0 of your package, any users running Pip 9.0+ from version " -"2.7 will have version 1.0.0 of the package installed, and any >=3.5 users " -"will receive version 2.0.0." -msgstr "" -"Se você atualizasse a string da versão para \">=3.5\" e publicasse uma nova " -"versão 2.0.0 do seu pacote, todos os usuários executando o Pip 9.0+ a partir " -"da versão 2.7 terão a versão 1.0.0 do pacote instalada e qualquer >=3.5 " -"usuários receberão a versão 2.0.0." - -#: ../source/guides/hosting-your-own-index.rst:5 -msgid "Hosting your own simple repository" -msgstr "Hospedando seu próprio simples repositório" - -#: ../source/guides/hosting-your-own-index.rst:8 -msgid "" -"If you wish to host your own simple repository [1]_, you can either use a " -"software package like `devpi`_ or you can use simply create the proper " -"directory structure and use any web server that can serve static files and " -"generate an autoindex." -msgstr "" -"Se você deseja hospedar seu próprio repositório simples [1]_, você pode usar " -"um pacote de software como `devpi`_ ou você pode usar simplesmente criar a " -"estrutura de diretório apropriada e usar qualquer servidor web que pode " -"servir arquivos estáticos e gerar um autoindex." - -#: ../source/guides/hosting-your-own-index.rst:13 -msgid "" -"In either case, since you'll be hosting a repository that is likely not in " -"your user's default repositories, you should instruct them in your project's " -"description to configure their installer appropriately. For example with pip:" -msgstr "" -"Em ambos os casos, como você hospedará um repositório que provavelmente não " -"está nos repositórios padrão do usuário, você deve instruí-los na descrição " -"do seu projeto para configurar o instalador apropriadamente. Por exemplo, " -"com pip:" - -#: ../source/guides/hosting-your-own-index.rst:29 -msgid "" -"In addition, it is **highly** recommended that you serve your repository " -"with valid HTTPS. At this time, the security of your user's installations " -"depends on all repositories using a valid HTTPS setup." -msgstr "" -"Além disso, é **altamente** recomendado que você sirva seu repositório com " -"HTTPS válido. Neste momento, a segurança das instalações do seu usuário " -"depende de todos os repositórios usando uma configuração válida do HTTPS." - -#: ../source/guides/hosting-your-own-index.rst:35 -msgid "\"Manual\" repository" -msgstr "Repositório \"manual\"" - -#: ../source/guides/hosting-your-own-index.rst:37 -msgid "" -"The directory layout is fairly simple, within a root directory you need to " -"create a directory for each project. This directory should be the normalized " -"name (as defined by :pep:`503`) of the project. Within each of these " -"directories simply place each of the downloadable files. If you have the " -"projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the " -"version 0.1) You should end up with a structure that looks like::" -msgstr "" -"O layout do diretório é bastante simples, dentro de um diretório raiz você " -"precisa criar um diretório para cada projeto. Este diretório deve ser o nome " -"normalizado (conforme definido por :pep:`503`) do projeto. Em cada um desses " -"diretórios, basta colocar cada um dos arquivos para download. Se você tem os " -"projetos \"Foo\" (com as versões 1.0 e 2.0) e \"bar\" (com a versão 0.1), " -"você deve acabar com uma estrutura parecida com::" - -#: ../source/guides/hosting-your-own-index.rst:51 -msgid "" -"Once you have this layout, simply configure your webserver to serve the root " -"directory with autoindex enabled. For an example using the built in Web " -"server in `Twisted`_, you would simply run ``twistd -n web --path .`` and " -"then instruct users to add the URL to their installer's configuration." -msgstr "" -"Assim que tiver esse layout, basta configurar seu servidor web para servir o " -"diretório raiz com o autoindex habilitado. Para um exemplo usando o servidor " -"Web embutido em `Twisted`_, você simplesmente executaria ``twistd -n web --" -"path .`` e então instruiria os usuários a adicionar a URL à configuração de " -"seu instalador." - -#: ../source/guides/hosting-your-own-index.rst:58 -msgid "" -"For complete documentation of the simple repository protocol, see :pep:`503`." -msgstr "" -"Para a documentação completa do protocolo de repositório simples, veja :pep:" -"`503`." - -#: ../source/guides/index.rst:8 -msgid "Installing Packages:" -msgstr "Instalando pacotes:" - -#: ../source/guides/index.rst:20 -msgid "Building and Publishing Projects:" -msgstr "Construindo e publicando projetos:" - -#: ../source/guides/index.rst:38 -msgid "Miscellaneous:" -msgstr "Diversos:" - -#: ../source/guides/index.rst:4 -msgid "" -"**Guides** are focused on accomplishing a specific task and assume that you " -"are already familiar with the basics of Python packaging. If you're looking " -"for an introduction to packaging, see :doc:`/tutorials/index`." -msgstr "" -"**Guias** se concentram em realizar uma tarefa específica e presumem que " -"você já esteja familiarizado com os fundamentos do empacotamento do Python. " -"Se você está procurando uma introdução ao empacotamento, veja :doc:`/" -"tutorials/index`." - -#: ../source/guides/index-mirrors-and-caches.rst:5 -msgid "Package index mirrors and caches" -msgstr "Espelhos e caches de índice de pacotes" - -#: ../source/guides/index-mirrors-and-caches.rst:8 -#: ../source/guides/supporting-multiple-python-versions.rst:8 -msgid "2014-12-24" -msgstr "2014-12-24" - -#: ../source/guides/index-mirrors-and-caches.rst:14 -msgid "" -"Mirroring or caching of PyPI can be used to speed up local package " -"installation, allow offline work, handle corporate firewalls or just plain " -"Internet flakiness." -msgstr "" -"O espelhamento ou cache do PyPI pode ser usado para acelerar a instalação do " -"pacote local, permitir o trabalho offline, lidar com firewalls corporativos " -"ou simplesmente falhas na Internet." - -#: ../source/guides/index-mirrors-and-caches.rst:17 -msgid "Three options are available in this area:" -msgstr "Três opções estão disponíveis nesta área:" - -#: ../source/guides/index-mirrors-and-caches.rst:19 -msgid "pip provides local caching options," -msgstr "pip fornece opções de cache local," - -#: ../source/guides/index-mirrors-and-caches.rst:20 -msgid "" -"devpi provides higher-level caching option, potentially shared amongst many " -"users or machines, and" -msgstr "" -"devpi fornece uma opção de cache de alto nível, potencialmente compartilhada " -"entre vários usuários ou várias máquinas, e" - -#: ../source/guides/index-mirrors-and-caches.rst:22 -msgid "" -"bandersnatch provides a local complete mirror of all PyPI :term:`packages " -"`." -msgstr "" -"bandersnatch fornece um espelho local completo de todos os :term:`pacotes " -"` do PyPI." - -#: ../source/guides/index-mirrors-and-caches.rst:27 -msgid "Caching with pip" -msgstr "Fazendo cache com pip" - -#: ../source/guides/index-mirrors-and-caches.rst:29 -msgid "" -"pip provides a number of facilities for speeding up installation by using " -"local cached copies of :term:`packages `:" -msgstr "" -"pip fornece uma série de facilidades para acelerar a instalação usando " -"cópias locais em cache de :term:`pacotes `:" - -#: ../source/guides/index-mirrors-and-caches.rst:32 -msgid "" -"`Fast & local installs `_ by downloading all the requirements for a project and " -"then pointing pip at those downloaded files instead of going to PyPI." -msgstr "" -"`Instalações rápidas e locais `_ baixando todos os requisitos para um " -"projeto e apontando pip para esses arquivos baixados em vez de ir para PyPI." - -#: ../source/guides/index-mirrors-and-caches.rst:36 -msgid "" -"A variation on the above which pre-builds the installation files for the " -"requirements using `python -m pip wheel `_::" -msgstr "" -"Uma variação acima, que pré-constrói os arquivos de instalação para os " -"requisitos usando `python -m pip wheel `_::" - -#: ../source/guides/index-mirrors-and-caches.rst:45 -msgid "Caching with devpi" -msgstr "Fazendo cache com devpi" - -#: ../source/guides/index-mirrors-and-caches.rst:47 -msgid "" -"devpi is a caching proxy server which you run on your laptop, or some other " -"machine you know will always be available to you. See the `devpi " -"documentation for getting started`__." -msgstr "" -"devpi é um servidor proxy de cache que você executa em seu laptop ou alguma " -"outra máquina que você sabe que sempre estará disponível para você. Veja a " -"`documentação do devpi para começar`__." - -#: ../source/guides/index-mirrors-and-caches.rst:55 -msgid "Complete mirror with bandersnatch" -msgstr "Espelho completo com bandersnatch" - -#: ../source/guides/index-mirrors-and-caches.rst:57 -msgid "" -"bandersnatch will set up a complete local mirror of all PyPI :term:`packages " -"` (externally-hosted packages are not mirrored). See " -"the `bandersnatch documentation for getting that going`__." -msgstr "" -"bandersnatch irá configurar um espelho local completo de todos os :term:" -"`pacotes ` do PyPI (pacotes hospedados externamente " -"não são espelhados). Veja a `documentação do bandersnatch para fazer isso`__." - -#: ../source/guides/index-mirrors-and-caches.rst:63 -msgid "" -"A benefit of devpi is that it will create a mirror which includes :term:" -"`packages ` that are external to PyPI, unlike " -"bandersnatch which will only cache :term:`packages ` " -"hosted on PyPI." -msgstr "" -"Um benefício do devpi é que ele criará um espelho que inclui :term:`pacotes " -"` que são externos ao PyPI, ao contrário do " -"bandersnatch que armazenará apenas em cache os :term:`pacotes ` hospedados no PyPI." - -#: ../source/guides/installing-scientific-packages.rst:5 -msgid "Installing scientific packages" -msgstr "Instalando pacotes científicos" - -#: ../source/guides/installing-scientific-packages.rst:11 -msgid "" -"Scientific software tends to have more complex dependencies than most, and " -"it will often have multiple build options to take advantage of different " -"kinds of hardware, or to interoperate with different pieces of external " -"software." -msgstr "" -"O software científico tende a ter dependências mais complexas do que a " -"maioria e, frequentemente, terá várias opções de construção para tirar " -"proveito de diferentes tipos de hardware ou para interoperar com diferentes " -"partes de software externo." - -#: ../source/guides/installing-scientific-packages.rst:16 -msgid "" -"In particular, `NumPy `__, which provides the basis " -"for most of the software in the `scientific Python stack `__ can be configured to interoperate with " -"different FORTRAN libraries, and can take advantage of different levels of " -"vectorised instructions available in modern CPUs." -msgstr "" -"Em particular, `NumPy `__, que fornece a base para a " -"maioria do software na `pilha científica Python `__ pode ser configurado para interoperar com " -"diferentes bibliotecas FORTRAN e pode tirar proveito de diferentes níveis de " -"instruções vetorizadas disponíveis em CPUs modernas." - -#: ../source/guides/installing-scientific-packages.rst:22 -msgid "" -"Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built " -"32-bit and 64-bit binaries in the ``wheel`` format are available for all " -"major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, " -"that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, " -"so they may not provide optimal linear algebra performance." -msgstr "" -"A partir da versão 1.10.4 do NumPy e da versão 1.0.0 do SciPy, binários pré-" -"construídos de 32 e 64 bits no formato ``wheel`` estão disponíveis para " -"todos os principais sistemas operacionais (Windows, macOS e Linux) em PyPI. " -"Observe, no entanto, que no Windows, os binários do NumPy são vinculados à " -"biblioteca BLAS/LAPACK do `ATLAS `__, restrita " -"às instruções SSE2, portanto, podem não fornecer desempenho da álgebra " -"linear." - -#: ../source/guides/installing-scientific-packages.rst:29 -msgid "" -"There are a number of alternative options for obtaining scientific Python " -"libraries (or any other Python libraries that require a compilation " -"environment to install from source and don't provide pre-built wheel files " -"on PyPI)." -msgstr "" -"Existem várias opções alternativas para obter bibliotecas científicas Python " -"(ou quaisquer outras bibliotecas Python que requerem um ambiente de " -"compilação para instalar a partir do código-fonte e não fornecem arquivos de " -"wheel pré-construídos no PyPI)." - -#: ../source/guides/installing-scientific-packages.rst:35 -msgid "Building from source" -msgstr "Construindo a partir do código-fonte" - -#: ../source/guides/installing-scientific-packages.rst:37 -msgid "" -"The same complexity which makes it difficult to distribute NumPy (and many " -"of the projects that depend on it) as wheel files also make them difficult " -"to build from source yourself. However, for intrepid folks that are willing " -"to spend the time wrangling compilers and linkers for both C and FORTRAN, " -"building from source is always an option." -msgstr "" -"A mesma complexidade que torna difícil distribuir o NumPy (e muitos dos " -"projetos que dependem dele) como arquivos wheel também torna difícil " -"construí-los a partir do código-fonte. No entanto, para pessoas intrépidas " -"que estão dispostas a gastar o tempo discutindo compiladores e vinculadores " -"para C e FORTRAN, construir a partir do código-fonte é sempre uma opção." - -#: ../source/guides/installing-scientific-packages.rst:45 -msgid "Linux distribution packages" -msgstr "Pacotes de distribuição Linux" - -#: ../source/guides/installing-scientific-packages.rst:47 -msgid "" -"For Linux users, the system package manager will often have pre-compiled " -"versions of various pieces of scientific software, including NumPy and other " -"parts of the scientific Python stack." -msgstr "" -"Para usuários Linux, o gerenciador de pacotes do sistema frequentemente terá " -"versões pré-compiladas de várias peças de software científico, incluindo " -"NumPy e outras partes da pilha científica Python." - -#: ../source/guides/installing-scientific-packages.rst:51 -msgid "" -"If using versions which may be several months old is acceptable, then this " -"is likely to be a good option (just make sure to allow access to " -"distributions installed into the system Python when using virtual " -"environments)." -msgstr "" -"Se usar versões que podem ter vários meses é aceitável, então esta é " -"provavelmente uma boa opção (apenas certifique-se de permitir o acesso às " -"distribuições instaladas no sistema Python ao usar ambientes virtuais)." - -#: ../source/guides/installing-scientific-packages.rst:57 -msgid "Windows installers" -msgstr "Instaladores para Windows" - -#: ../source/guides/installing-scientific-packages.rst:59 -msgid "" -"Many Python projects that don't (or can't) currently publish wheel files at " -"least publish Windows installers, either on PyPI or on their project " -"download page. Using these installers allows users to avoid the need to set " -"up a suitable environment to build extensions locally." -msgstr "" -"Muitos projetos Python que não publicam (ou não podem) atualmente publicar " -"arquivos wheel, pelo menos publicam instaladores Windows, seja no PyPI ou na " -"página de download de seus projetos. O uso desses instaladores permite que " -"os usuários evitem a necessidade de configurar um ambiente adequado para " -"construir extensões localmente." - -#: ../source/guides/installing-scientific-packages.rst:64 -msgid "" -"The extensions provided in these installers are typically compatible with " -"the CPython Windows installers published on python.org." -msgstr "" -"As extensões fornecidas nesses instaladores são normalmente compatíveis com " -"os instaladores do CPython para o Windows publicados em python.org." - -#: ../source/guides/installing-scientific-packages.rst:67 -msgid "" -"For projects which don't provide their own Windows installers (and even some " -"which do), Christoph Gohlke at the University of California provides a " -"`collection of Windows installers `__. Many Python users on Windows have reported a positive experience with " -"these prebuilt versions." -msgstr "" -"Para projetos que não fornecem seus próprios instaladores para Windows (e " -"até mesmo alguns que oferecem), Christoph Gohlke da Universidade da " -"Califórnia fornece uma `coleção de instaladores para Windows `__. Muitos usuários do Python no Windows " -"relataram uma experiência positiva com essas versões pré-construídas." - -#: ../source/guides/installing-scientific-packages.rst:73 -msgid "" -"As with Linux system packages, the Windows installers will only install into " -"a system Python installation - they do not support installation in virtual " -"environments. Allowing access to distributions installed into the system " -"Python when using virtual environments is a common approach to working " -"around this limitation." -msgstr "" -"Tal como acontece com os pacotes de sistema Linux, os instaladores Windows " -"irão apenas instalar em uma instalação de sistema Python -- eles não " -"oferecem suporte à instalação em ambientes virtuais. Permitir o acesso a " -"distribuições instaladas no sistema Python ao usar ambientes virtuais é uma " -"abordagem comum para contornar essa limitação." - -#: ../source/guides/installing-scientific-packages.rst:79 -msgid "" -"The :term:`Wheel` project also provides a :command:`wheel convert` " -"subcommand that can convert a Windows :command:`bdist_wininst` installer to " -"a wheel." -msgstr "" -"O projeto :term:`Wheel` também fornece um subcomando :command:`wheel " -"convert` que pode converter um instalador para Windows :command:" -"`bdist_wininst` em um wheel." - -#: ../source/guides/installing-scientific-packages.rst:86 -msgid "macOS installers and package managers" -msgstr "Instaladores e gerenciadores de pacote para macOS" - -#: ../source/guides/installing-scientific-packages.rst:88 -msgid "" -"Similar to the situation on Windows, many projects (including NumPy) publish " -"macOS installers that are compatible with the macOS CPython binaries " -"published on python.org." -msgstr "" -"Semelhante à situação no Windows, muitos projetos (incluindo NumPy) publicam " -"instaladores para macOS que são compatíveis com os binários do CPython para " -"macOS publicados em python.org." - -#: ../source/guides/installing-scientific-packages.rst:92 -msgid "" -"macOS users also have access to Linux distribution style package managers " -"such as ``MacPorts``. The SciPy site has more details on using MacPorts to " -"install the `scientific Python stack `__" -msgstr "" -"Os usuários do macOS também têm acesso aos gerenciadores de pacotes de " -"estilo de distribuição Linux, como ``MacPorts``. O site SciPy tem mais " -"detalhes sobre como usar MacPorts para instalar a `pilha científica Python " -"`__" - -#: ../source/guides/installing-scientific-packages.rst:99 -msgid "SciPy distributions" -msgstr "Distribuições SciPy" - -#: ../source/guides/installing-scientific-packages.rst:101 -msgid "" -"The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use " -"and update format." -msgstr "" -"O site SciPy lista `várias distribuições `__ que fornecem a pilha SciPy completa para usuários finais em um " -"formato fácil de usar e atualizar." - -#: ../source/guides/installing-scientific-packages.rst:105 -msgid "" -"Some of these distributions may not be compatible with the standard ``pip`` " -"and ``virtualenv`` based toolchain." -msgstr "" -"Algumas dessas distribuições podem não ser compatíveis com o conjunto de " -"ferramentas padrão ``pip`` e ``virtualenv``." - -#: ../source/guides/installing-scientific-packages.rst:109 -#: ../source/key_projects.rst:596 -msgid "Spack" -msgstr "Spack" - -#: ../source/guides/installing-scientific-packages.rst:110 -msgid "" -"`Spack `_ is a flexible package manager " -"designed to support multiple versions, configurations, platforms, and " -"compilers. It was built to support the needs of large supercomputing centers " -"and scientific application teams, who must often build software many " -"different ways. Spack is not limited to Python; it can install packages for " -"``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-" -"destructive; installing a new version of one package does not break existing " -"installations, so many configurations can coexist on the same system." -msgstr "" -"`Spack `_ é um gerenciador de pacotes " -"flexível projetado para oferecer suporte a múltiplas versões, configurações, " -"plataformas e compiladores. Ele foi construído para dar suporte às " -"necessidades de grandes centros de supercomputação e equipes de aplicações " -"científicas, que frequentemente precisam criar software de muitas maneiras " -"diferentes. O Spack não está limitado a Python; ele pode instalar pacotes " -"para ``C``, ``C++``, ``Fortran``, ``R`` e outras linguagens. É não " -"destrutivo; instalar uma nova versão de um pacote não interrompe as " -"instalações existentes, portanto, muitas configurações podem coexistir no " -"mesmo sistema." - -#: ../source/guides/installing-scientific-packages.rst:119 -msgid "" -"Spack offers a simple but powerful syntax that allows users to specify " -"versions and configuration options concisely. Package files are written in " -"pure Python, and they are templated so that it is easy to swap compilers, " -"dependency implementations (like MPI), versions, and build options with a " -"single package file. Spack also generates *module* files so that packages " -"can be loaded and unloaded from the user's environment." -msgstr "" -"O Spack oferece uma sintaxe simples, mas poderosa, que permite aos usuários " -"especificar versões e opções de configuração de forma concisa. Os arquivos " -"de pacote são escritos em puro Python e são modelados para que seja fácil " -"trocar compiladores, implementações de dependência (como MPI), versões e " -"opções de construção com um único arquivo de pacote. O Spack também gera " -"arquivos de *módulo* para que os pacotes possam ser carregados e " -"descarregados do ambiente do usuário." - -#: ../source/guides/installing-scientific-packages.rst:128 -msgid "The conda cross-platform package manager" -msgstr "O gerenciador de pacotes multiplataforma conda" - -#: ../source/guides/installing-scientific-packages.rst:130 -msgid "" -"`Anaconda `_ is a Python distribution " -"published by Anaconda, Inc. It is a stable collection of Open Source " -"packages for big data and scientific use. As of the 5.0 release of " -"Anaconda, about 200 packages are installed by default, and a total of " -"400-500 can be installed and updated from the Anaconda repository." -msgstr "" -"`Anaconda `_ é uma distribuição Python " -"publicada pela Anaconda, Inc. É uma coleção estável de pacotes de código " -"aberto para *big data* e uso científico. A partir da versão 5.0 do Anaconda, " -"cerca de 200 pacotes são instalados por padrão, e um total de 400-500 podem " -"ser instalados e atualizados a partir do repositório Anaconda." - -#: ../source/guides/installing-scientific-packages.rst:136 -msgid "" -"``conda`` is an open source (BSD licensed) package management system and " -"environment management system included in Anaconda that allows users to " -"install multiple versions of binary software packages and their " -"dependencies, and easily switch between them. It is a cross-platform tool " -"working on Windows, macOS, and Linux. Conda can be used to package up and " -"distribute all kinds of packages, it is not limited to just Python packages. " -"It has full support for native virtual environments. Conda makes " -"environments first-class citizens, making it easy to create independent " -"environments even for C libraries. It is written in Python, but is Python-" -"agnostic. Conda manages Python itself as a package, so that :command:`conda " -"update python` is possible, in contrast to pip, which only manages Python " -"packages. Conda is available in Anaconda and Miniconda (an easy-to-install " -"download with just Python and conda)." -msgstr "" -"``conda`` é um sistema de gerenciamento de pacotes e de gerenciamento de " -"ambiente de código aberto (licenciado por BSD) incluído no Anaconda que " -"permite aos usuários instalar várias versões de pacotes de software binários " -"e suas dependências, e alternar facilmente entre eles. É uma ferramenta " -"multiplataforma que funciona no Windows, no macOS e no Linux. O Conda pode " -"ser usado para empacotar e distribuir todos os tipos de pacotes, não está " -"limitado apenas a pacotes Python. Possui suporte total para ambientes " -"virtuais nativos. Conda torna os ambientes cidadãos de primeira classe, " -"facilitando a criação de ambientes independentes até mesmo para bibliotecas " -"C. Está escrito em Python, mas é agnóstico ao Python. O Conda gerencia o " -"próprio Python como um pacote, de forma que :command:`conda update python` " -"seja possível, em contraste com o pip, que gerencia apenas os pacotes " -"Python. O Conda está disponível no Anaconda e no Miniconda (um download " -"fácil de instalar com apenas Python e conda)." - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 -msgid "Installing stand alone command line tools" -msgstr "Instalando ferramentas de linha de comando autônomas" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 -msgid "" -"Many packages have command line entry points. Examples of this type of " -"application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." -msgstr "" -"Muitos pacotes têm pontos de entrada de linha de comando. Exemplos deste " -"tipo de aplicação são `mypy `_, `flake8 " -"`_, :ref:`pipenv`e `black `_." - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 -msgid "" -"Usually you want to be able to access these from anywhere, but installing " -"packages and their dependencies to the same global environment can cause " -"version conflicts and break dependencies the operating system has on Python " -"packages." -msgstr "" -"Normalmente você deseja acessá-los de qualquer lugar, mas instalar pacotes e " -"suas dependências no mesmo ambiente global pode causar conflitos de versão e " -"quebrar as dependências que o sistema operacional tem nos pacotes Python." - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 -msgid "" -":ref:`pipx` solves this by creating a virtual environment for each package, " -"while also ensuring that package's applications are accessible through a " -"directory that is on your ``$PATH``. This allows each package to be upgraded " -"or uninstalled without causing conflicts with other packages, and allows you " -"to safely run the program from anywhere." -msgstr "" -":ref:`pipx` resolve isso criando um ambiente virtual para cada pacote, " -"enquanto também garante que as aplicações do pacote sejam acessíveis através " -"de um diretório que está em seu ``$PATH``. Isso permite que cada pacote seja " -"atualizado ou desinstalado sem causar conflitos com outros pacotes e permite " -"que você execute o programa com segurança de qualquer lugar." - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 -msgid "pipx only works with Python 3.6+." -msgstr "pipx só funciona com Python 3.6+." - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 -msgid "``pipx`` is installed with ``pip``:" -msgstr "``pipx`` é instalado com ``pip``:" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 -msgid "" -"You may need to restart your terminal for the path updates to take effect." -msgstr "" -"Você pode precisar reiniciar seu terminal para que as atualizações de " -"caminho tenham efeito." - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 -msgid "" -"Now you can install packages with ``pipx install`` and access the package's " -"entry point(s) from anywhere." -msgstr "" -"Agora você pode instalar pacotes com ``pipx install`` e acessar os pontos de " -"entrada do pacote de qualquer lugar." - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 -#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 -msgid "For example" -msgstr "Por exemplo" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 -msgid "" -"To see a list of packages installed with pipx and which CLI applications are " -"available, use ``pipx list``." -msgstr "" -"Para ver uma lista de pacotes instalados com pipx e quais aplicações de " -"linha de comando estão disponíveis, use ``pipx list``." - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 -msgid "To upgrade or uninstall the package" -msgstr "Para atualizar ou desinstalar o pacote" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 -msgid "``pipx`` can be upgraded or uninstalled with pip" -msgstr "``pipx`` pode ser atualizado ou desinstalado com pip" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 -msgid "" -"``pipx`` also allows you to install and run the latest version of a cli tool " -"in a temporary, ephemeral environment." -msgstr "" -"`` pipx`` também permite que você instale e execute a versão mais recente de " -"uma ferramenta cli em um ambiente temporário e efêmero." - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 -msgid "To see the full list of commands ``pipx`` offers, run" -msgstr "Para ver a lista completa de comandos ``pipx`` oferece, execute" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 -msgid "" -"You can learn more about ``pipx`` at its homepage, https://github.com/pypa/" -"pipx." -msgstr "" -"Você pode aprender mais sobre ``pipx`` em sua página inicial, https://github." -"com/pypa/pipx." - -#: ../source/guides/installing-using-linux-tools.rst:5 -msgid "Installing pip/setuptools/wheel with Linux Package Managers" -msgstr "Instalando pip/setuptools/wheel com gerenciadores de pacotes do Linux" - -#: ../source/guides/installing-using-linux-tools.rst:8 -msgid "2015-09-17" -msgstr "2015-09-17" - -#: ../source/guides/installing-using-linux-tools.rst:11 -msgid "" -"This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:" -"`wheel` using Linux package managers." -msgstr "" -"Esta seção cobre como instalar :ref:`pip`, :ref:`setuptools` e :ref:`wheel` " -"usando gerenciadores de pacotes do Linux." - -#: ../source/guides/installing-using-linux-tools.rst:14 -msgid "" -"If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:" -"`installing_requirements` section instead." -msgstr "" -"Se você estiver usando um Python que foi baixado de `python.org `_, então esta seção não se aplica. Veja a seção :ref:" -"`installing_requirements`." - -#: ../source/guides/installing-using-linux-tools.rst:18 -msgid "" -"Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, " -"and :ref:`wheel` supported by a specific Linux Distribution to be outdated " -"by the time it's released to the public, and updates generally only occur " -"for security reasons, not for feature updates. For certain Distributions, " -"there are additional repositories that can be enabled to provide newer " -"versions. The repositories we know about are explained below." -msgstr "" -"Observe que é comum que as versões de :ref:`pip`, :ref:`setuptools` e :ref:" -"`wheel` suportadas por uma distribuição Linux específica estejam " -"desatualizadas no momento em que é lançado para o público, e as atualizações " -"geralmente ocorrem apenas por motivos de segurança, não para atualizações de " -"recursos. Para certas distribuições, existem repositórios adicionais que " -"podem ser ativados para fornecer versões mais recentes. Os repositórios que " -"conhecemos são explicados abaixo." - -#: ../source/guides/installing-using-linux-tools.rst:25 -msgid "" -"Also note that it's somewhat common for Distributions to apply patches for " -"the sake of security and normalization to their own standards. In some " -"cases, this can lead to bugs or unexpected behaviors that vary from the " -"original unpatched versions. When this is known, we will make note of it " -"below." -msgstr "" -"Observe também que é um tanto comum que as Distribuições apliquem patches " -"para fins de segurança e normalização de acordo com seus próprios padrões. " -"Em alguns casos, isso pode levar a bugs ou comportamentos inesperados que " -"variam em relação às versões originais sem patch. Quando isso for conhecido, " -"faremos anotações sobre isso a seguir." - -#: ../source/guides/installing-using-linux-tools.rst:32 -msgid "Fedora" -msgstr "Fedora" - -#: ../source/guides/installing-using-linux-tools.rst:34 -msgid "Fedora 21:" -msgstr "Fedora 21:" - -#: ../source/guides/installing-using-linux-tools.rst:36 -#: ../source/guides/installing-using-linux-tools.rst:45 -#: ../source/guides/installing-using-linux-tools.rst:124 -#: ../source/guides/installing-using-linux-tools.rst:138 -#: ../source/guides/installing-using-linux-tools.rst:158 -msgid "Python 2::" -msgstr "Python 2::" - -#: ../source/guides/installing-using-linux-tools.rst:41 -msgid "Python 3: ``sudo yum install python3 python3-wheel``" -msgstr "Python 3: ``sudo yum install python3 python3-wheel``" - -#: ../source/guides/installing-using-linux-tools.rst:43 -msgid "Fedora 22:" -msgstr "Fedora 22:" - -#: ../source/guides/installing-using-linux-tools.rst:50 -msgid "Python 3: ``sudo dnf install python3 python3-wheel``" -msgstr "Python 3: ``sudo dnf install python3 python3-wheel``" - -#: ../source/guides/installing-using-linux-tools.rst:53 -msgid "" -"To get newer versions of pip, setuptools, and wheel for Python 2, you can " -"enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" -msgstr "" -"Para obter versões mais novas do pip, setuptools e wheel para Python 2, você " -"pode habilitar o `PyPA Copr Repo `_ usando as `instruções do Copr Repo `__ e então executar::" - -#: ../source/guides/installing-using-linux-tools.rst:63 -msgid "CentOS/RHEL" -msgstr "CentOS/RHEL" - -#: ../source/guides/installing-using-linux-tools.rst:65 -msgid "" -"CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core " -"repositories, although :ref:`setuptools` is installed by default." -msgstr "" -"CentOS e RHEL não oferecem :ref:`pip` ou :ref:`wheel` em seus repositórios " -"principais, embora :ref:`setuptools` seja instalado por padrão." - -#: ../source/guides/installing-using-linux-tools.rst:68 -msgid "To install pip and wheel for the system Python, there are two options:" -msgstr "Para instalar pip e wheel para o sistema Python, existem duas opções:" - -#: ../source/guides/installing-using-linux-tools.rst:70 -msgid "" -"Enable the `EPEL repository `_ using " -"`these instructions `__. On EPEL 6 and EPEL7, you can " -"install pip like so::" -msgstr "" -"Habilite o `repositório EPEL `_ usando " -"`estas instruções `__. Em EPEL 6 e EPEL 7, você " -"pode instalar pip assim::" - -#: ../source/guides/installing-using-linux-tools.rst:77 -msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" -msgstr "No EPEL 7 (mas não no EPEL 6), você pode instalar wheel desta forma::" - -#: ../source/guides/installing-using-linux-tools.rst:81 -msgid "" -"Since EPEL only offers extra, non-conflicting packages, EPEL does not offer " -"setuptools, since it's in the core repository." -msgstr "" -"Como a EPEL oferece apenas pacotes extras não conflitantes, a EPEL não " -"oferece setuptools, pois está no repositório central." - -#: ../source/guides/installing-using-linux-tools.rst:85 -msgid "" -"Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" -msgstr "" -"Habilite o `Copr Repo do PyPA `_ usando `estas instruções `__ [1]_. Você pode instalar pip e wheel desta forma::" - -#: ../source/guides/installing-using-linux-tools.rst:92 -msgid "To additionally upgrade setuptools, run::" -msgstr "Para adicionalmente atualizar setuptools, execute::" - -#: ../source/guides/installing-using-linux-tools.rst:97 -msgid "" -"To install pip, wheel, and setuptools, in a parallel, non-system environment " -"(using yum) then there are two options:" -msgstr "" -"Para instalar pip, wheel e setuptools, em um ambiente paralelo, sem sistema " -"(usando yum), existem duas opções:" - -#: ../source/guides/installing-using-linux-tools.rst:101 -msgid "" -"Use the \"Software Collections\" feature to enable a parallel collection " -"that includes pip, setuptools, and wheel." -msgstr "" -"Use o recurso \"Coleções de software\" para habilitar uma coleção paralela " -"que inclui pip, setuptools e wheel." - -#: ../source/guides/installing-using-linux-tools.rst:104 -msgid "" -"For Redhat, see here: http://developers.redhat.com/products/" -"softwarecollections/overview/" -msgstr "" -"Para Redhat, veja aqui: http://developers.redhat.com/products/" -"softwarecollections/overview/" - -#: ../source/guides/installing-using-linux-tools.rst:106 -msgid "For CentOS, see here: https://www.softwarecollections.org/en/" -msgstr "Para CentOS, veja aqui: https://www.softwarecollections.org/en/" - -#: ../source/guides/installing-using-linux-tools.rst:108 -msgid "Be aware that collections may not contain the most recent versions." -msgstr "" -"Esteja ciente de que as coleções podem não conter as versões mais recentes." - -#: ../source/guides/installing-using-linux-tools.rst:110 -msgid "" -"Enable the `IUS repository `_ and install " -"one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which " -"are kept fairly up to date." -msgstr "" -"Habilite o `repositório do IUS `_ e instale " -"um dos Pythons `pré-instaláveis `_, junto com pip, setuptools e wheel, que são mantidos " -"razoavelmente atualizados." - -#: ../source/guides/installing-using-linux-tools.rst:116 -msgid "For example, for Python 3.4 on CentOS7/RHEL7::" -msgstr "Por exemplo, para Python 3.4 no CentOS7/RHEL7::" - -#: ../source/guides/installing-using-linux-tools.rst:122 -msgid "openSUSE" -msgstr "openSUSE" - -#: ../source/guides/installing-using-linux-tools.rst:129 -#: ../source/guides/installing-using-linux-tools.rst:143 -#: ../source/guides/installing-using-linux-tools.rst:162 -msgid "Python 3::" -msgstr "Python 3::" - -#: ../source/guides/installing-using-linux-tools.rst:135 -msgid "Debian/Ubuntu" -msgstr "Debian/Ubuntu" - -#: ../source/guides/installing-using-linux-tools.rst:150 -msgid "" -"Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" " -"`_ by default, " -"which is a significant behavior change that can be surprising to some users." -msgstr "" -"Versões recentes do Debian/Ubuntu modificaram o pip para usar o `\"User " -"Scheme\" `_ " -"(Esquema de usuário) por padrão, que é um mudança significativa de " -"comportamento que pode surpreender alguns usuários." - -#: ../source/guides/installing-using-linux-tools.rst:156 -msgid "Arch Linux" -msgstr "Arch Linux" - -#: ../source/guides/installing-using-linux-tools.rst:168 -msgid "" -"Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the " -"only option is to manually place the repo files as described." -msgstr "" -"Atualmente, não há plug-in do yum para \"copr\" disponível para CentOS/RHEL, " -"então a única opção é colocar manualmente os arquivos de repositório " -"conforme descrito." - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 -msgid "Installing packages using pip and virtual environments" -msgstr "Instalando pacotes usando pip e ambientes virtuais" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 -msgid "" -"This guide discusses how to install packages using :ref:`pip` and a virtual " -"environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` " -"for Python 2. These are the lowest-level tools for managing Python packages " -"and are recommended if higher-level tools do not suit your needs." -msgstr "" -"Este guia discute como instalar pacotes usando :ref:`pip` e um gerenciador " -"de ambiente virtual: ou :ref:`venv` para Python 3 ou :ref:`virtualenv` para " -"Python 2 Estas são as ferramentas de nível mais baixo para gerenciar pacotes " -"Python e são recomendadas se as ferramentas de nível mais alto não atenderem " -"às suas necessidades." - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 -msgid "" -"This doc uses the term **package** to refer to a :term:`Distribution " -"Package` which is different from an :term:`Import Package` that which is " -"used to import modules in your Python source code." -msgstr "" -"Este documento usa o termo **pacote** para se referir a um :term:`Pacote de " -"Distribuição` que é diferente de um :term:`Pacote de Importação` que é usado " -"para importar módulos em seu código-fonte do Python." - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 -msgid "Installing pip" -msgstr "Instalando pip" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 -msgid "" -":ref:`pip` is the reference Python package manager. It's used to install and " -"update packages. You'll need to make sure you have the latest version of pip " -"installed." -msgstr "" -":ref:`pip` é o gerenciador de pacotes de referência Python. É usado para " -"instalar e atualizar pacotes. Você precisará certificar-se de que possui a " -"versão mais recente do pip instalada." - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 -msgid "" -"Debian and most other distributions include a `python-pip`_ package, if you " -"want to use the Linux distribution-provided versions of pip see :doc:`/" -"guides/installing-using-linux-tools`." -msgstr "" -"O Debian e a maioria das outras distribuições incluem um pacote `python-" -"pip`_, se você deseja usar as versões fornecidas pela distribuição Linux do " -"pip, consulte :doc:`/guides/installation-using-linux-tools`." - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 -msgid "" -"You can also install pip yourself to ensure you have the latest version. " -"It's recommended to use the system pip to bootstrap a user installation of " -"pip:" -msgstr "" -"Você também pode instalar o pip por conta própria para garantir que possui a " -"versão mais recente. É recomendado usar o sistema pip para inicializar uma " -"instalação de usuário do pip:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 -msgid "Afterwards, you should have the newest pip installed in your user site:" -msgstr "" -"Depois disso, você deve ter o pip mais recente instalado em seu site de " -"usuário:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 -msgid "" -"The Python installers for Windows include pip. You should be able to access " -"pip using:" -msgstr "" -"Os instaladores do Python para Windows incluem pip. Você deve ser capaz de " -"acessar o pip usando:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 -msgid "You can make sure that pip is up-to-date by running:" -msgstr "Você pode ter certeza de que o pip está atualizado executando:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 -msgid "Installing virtualenv" -msgstr "Instalando virtualenv" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 -msgid "" -"If you are using Python 3.3 or newer, the :mod:`venv` module is the " -"preferred way to create and manage virtual environments. venv is included in " -"the Python standard library and requires no additional installation. If you " -"are using venv, you may skip this section." -msgstr "" -"Se você estiver usando o Python 3.3 ou mais recente, o módulo :mod:`venv` é " -"a forma preferida de criar e gerenciar ambientes virtuais. venv está " -"incluído na biblioteca padrão Python e não requer instalação adicional. Se " -"você estiver usando venv, pode pular esta seção." - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 -msgid "" -":ref:`virtualenv` is used to manage Python packages for different projects. " -"Using virtualenv allows you to avoid installing Python packages globally " -"which could break system tools or other projects. You can install virtualenv " -"using pip." -msgstr "" -":ref:`virtualenv` é usado para gerenciar pacotes Python para diferentes " -"projetos. O uso do virtualenv permite que você evite instalar pacotes Python " -"globalmente, o que poderia quebrar as ferramentas do sistema ou outros " -"projetos. Você pode instalar virtualenv usando pip." - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 -msgid "Creating a virtual environment" -msgstr "Criando um ambiente virtual" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 -msgid "" -":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to " -"manage separate package installations for different projects. They " -"essentially allow you to create a \"virtual\" isolated Python installation " -"and install packages into that virtual installation. When you switch " -"projects, you can simply create a new virtual environment and not have to " -"worry about breaking the packages installed in the other environments. It is " -"always recommended to use a virtual environment while developing Python " -"applications." -msgstr "" -":ref:`venv` (para Python 3) e :ref:`virtualenv` (para Python 2) permitem que " -"você gerencie instalações de pacotes separadas para projetos diferentes. " -"Eles essencialmente permitem que você crie uma instalação \"virtual\" " -"isolada do Python e instale pacotes nessa instalação virtual. Ao trocar de " -"projeto, você pode simplesmente criar um novo ambiente virtual e não precisa " -"se preocupar em quebrar os pacotes instalados nos outros ambientes. É sempre " -"recomendável usar um ambiente virtual ao desenvolver aplicações Python." - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 -msgid "" -"To create a virtual environment, go to your project's directory and run " -"venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the " -"below commands." -msgstr "" -"Para criar um ambiente virtual, vá até o diretório do seu projeto e execute " -"venv. Se você estiver usando Python 2, substitua ``venv`` por ``virtualenv`` " -"nos comandos abaixo." - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 -msgid "" -"The second argument is the location to create the virtual environment. " -"Generally, you can just create this in your project and call it ``env``." -msgstr "" -"O segundo argumento é o local para criar o ambiente virtual. Geralmente, " -"você pode apenas criar isso em seu projeto e chamá-lo de ``env``." - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 -msgid "venv will create a virtual Python installation in the ``env`` folder." -msgstr "venv irá criar uma instalação virtual Python na pasta ``env``." - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 -msgid "" -"You should exclude your virtual environment directory from your version " -"control system using ``.gitignore`` or similar." -msgstr "" -"Você deve excluir seu diretório de ambiente virtual de seu sistema de " -"controle de versão usando ``.gitignore`` ou similar." - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 -msgid "Activating a virtual environment" -msgstr "Ativando um ambiente virtual" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 -msgid "" -"Before you can start installing or using packages in your virtual " -"environment you'll need to *activate* it. Activating a virtual environment " -"will put the virtual environment-specific ``python`` and ``pip`` executables " -"into your shell's ``PATH``." -msgstr "" -"Antes de começar a instalar ou usar pacotes em seu ambiente virtual, você " -"precisará *ativá-lo*. Ativar um ambiente virtual colocará os executáveis " -"``python`` e ``pip`` específicos do ambiente virtual no ``PATH`` de seu " -"shell." - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 -msgid "" -"You can confirm you're in the virtual environment by checking the location " -"of your Python interpreter, it should point to the ``env`` directory." -msgstr "" -"Você pode confirmar que está no ambiente virtual verificando a localização " -"do seu interpretador Python, ele deve apontar para o diretório ``env``." - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 -msgid "" -"As long as your virtual environment is activated pip will install packages " -"into that specific environment and you'll be able to import and use packages " -"in your Python application." -msgstr "" -"Contanto que seu ambiente virtual esteja ativado, pip instalará pacotes " -"naquele ambiente específico e você poderá importar e usar pacotes em sua " -"aplicação Python." - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 -msgid "Leaving the virtual environment" -msgstr "Saindo do ambiente virtual" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 -msgid "" -"If you want to switch projects or otherwise leave your virtual environment, " -"simply run:" -msgstr "" -"Se você deseja trocar de projeto ou de outra forma deixar seu ambiente " -"virtual, basta executar:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 -msgid "" -"If you want to re-enter the virtual environment just follow the same " -"instructions above about activating a virtual environment. There's no need " -"to re-create the virtual environment." -msgstr "" -"Se você deseja entrar novamente no ambiente virtual, basta seguir as mesmas " -"instruções acima sobre como ativar um ambiente virtual. Não há necessidade " -"de recriar o ambiente virtual." - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 -msgid "Installing packages" -msgstr "Instalando pacotes" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 -msgid "" -"Now that you're in your virtual environment you can install packages. Let's " -"install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" -msgstr "" -"Agora que você está em seu ambiente virtual, pode instalar pacotes. Vamos " -"instalar a biblioteca `Requests`_ do :term:`Python Package Index (PyPI)`:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 -msgid "" -"pip should download requests and all of its dependencies and install them:" -msgstr "" -"pip deve baixar solicitações e todas as suas dependências e instalá-los:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 -msgid "Installing specific versions" -msgstr "Instalando versões específicas" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 -msgid "" -"pip allows you to specify which version of a package to install using :term:" -"`version specifiers `. For example, to install a specific " -"version of ``requests``:" -msgstr "" -"pip permite que você especifique qual versão de um pacote instalar usando :" -"term:`especificadores de versão `. Por exemplo, " -"para instalar uma versão específica do ``requests``:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 -msgid "To install the latest ``2.x`` release of requests:" -msgstr "Para instalar a versão ``2.x`` mais recente do requests:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 -msgid "To install pre-release versions of packages, use the ``--pre`` flag:" -msgstr "" -"Para instalar versões de pré-lançamento de pacotes, use o sinalizador ``--" -"pre``:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 -msgid "Installing extras" -msgstr "Instalando extras" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 -msgid "" -"Some packages have optional `extras`_. You can tell pip to install these by " -"specifying the extra in brackets:" -msgstr "" -"Alguns pacotes possuem `extras`_ opcionais. Você pode dizer ao pip para " -"instalá-los especificando o extra entre colchetes:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 -msgid "Installing from source" -msgstr "Instalando a partir do código-fonte" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 -msgid "pip can install a package directly from source, for example:" -msgstr "pip pode instalar um pacote diretamente do código-fonte, por exemplo:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 -msgid "" -"Additionally, pip can install packages from source in `development mode`_, " -"meaning that changes to the source directory will immediately affect the " -"installed package without needing to re-install:" -msgstr "" -"Além disso, pip pode instalar pacotes do código-fonte no `modo de " -"desenvolvimento`_, o que significa que as mudanças no diretório de código-" -"fonte afetarão imediatamente o pacote instalado sem a necessidade de " -"reinstalar:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 -msgid "Installing from version control systems" -msgstr "Instalando a partir de sistemas de controle de versão" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 -msgid "" -"pip can install packages directly from their version control system. For " -"example, you can install directly from a git repository:" -msgstr "" -"pip pode instalar pacotes diretamente de seu sistema de controle de versão. " -"Por exemplo, você pode instalar diretamente de um repositório git:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 -msgid "" -"For more information on supported version control systems and syntax, see " -"pip's documentation on :ref:`VCS Support `." -msgstr "" -"Para mais informações sobre os sistemas de controle de versão suportados e " -"sintaxe, consulte a documentação do pip em :ref:`Suporte VCS `." - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 -#: ../source/tutorials/installing-packages.rst:569 -msgid "Installing from local archives" -msgstr "Instalando de arquivos locais" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 -msgid "" -"If you have a local copy of a :term:`Distribution Package`'s archive (a zip, " -"wheel, or tar file) you can install it directly with pip:" -msgstr "" -"Se você tiver uma cópia local de um arquivo do :term:`Pacote de " -"Distribuição` (um arquivo zip, wheel ou tar), você pode instalá-lo " -"diretamente com pip:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 -msgid "" -"If you have a directory containing archives of multiple packages, you can " -"tell pip to look for packages there and not to use the :term:`Python Package " -"Index (PyPI)` at all:" -msgstr "" -"Se você tiver um diretório contendo arquivos de vários pacotes, você pode " -"dizer ao pip para procurar por pacotes lá e não usar o :term:`Python Package " -"Index (PyPI)` de forma alguma:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 -msgid "" -"This is useful if you are installing packages on a system with limited " -"connectivity or if you want to strictly control the origin of distribution " -"packages." -msgstr "" -"Isso é útil se você estiver instalando pacotes em um sistema com " -"conectividade limitada ou se quiser controlar estritamente a origem dos " -"pacotes de distribuição." - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 -msgid "Using other package indexes" -msgstr "Usando outros índices de pacotes" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 -msgid "" -"If you want to download packages from a different index than the :term:" -"`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" -msgstr "" -"Se você quiser baixar pacotes de um índice diferente do :term:`Python " -"Package Index (PyPI)`, você pode usar o sinalizador ``--index-url``:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 -msgid "" -"If you want to allow packages from both the :term:`Python Package Index " -"(PyPI)` and a separate index, you can use the ``--extra-index-url`` flag " -"instead:" -msgstr "" -"Se você deseja permitir pacotes do :term:`Python Package Index (PyPI)` e de " -"um índice separado, você pode usar a sinalização ``--extra-index-url`` em " -"seu lugar:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 -#: ../source/tutorials/installing-packages.rst:389 -msgid "Upgrading packages" -msgstr "Atualizando pacotes" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 -msgid "" -"pip can upgrade packages in-place using the ``--upgrade`` flag. For example, " -"to install the latest version of ``requests`` and all of its dependencies:" -msgstr "" -"pip pode atualizar pacotes no local usando o sinalizador ``--upgrade``. Por " -"exemplo, para instalar a versão mais recente de ``requests`` e todas as suas " -"dependências:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 -msgid "Using requirements files" -msgstr "Usando arquivos de requisitos" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 -msgid "" -"Instead of installing packages individually, pip allows you to declare all " -"dependencies in a :ref:`Requirements File `. For " -"example you could create a :file:`requirements.txt` file containing:" -msgstr "" -"Em vez de instalar pacotes individualmente, pip permite que você declare " -"todas as dependências em um :ref:`Arquivo de Requisitos `. Por exemplo, você pode criar um arquivo :file:`requirements.txt` " -"contendo:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 -msgid "" -"And tell pip to install all of the packages in this file using the ``-r`` " -"flag:" -msgstr "" -"E diga ao pip para instalar todos os pacotes neste arquivo usando o " -"sinalizador ``-r``:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 -msgid "Freezing dependencies" -msgstr "Congelando dependências" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 -msgid "" -"Pip can export a list of all installed packages and their versions using the " -"``freeze`` command:" -msgstr "" -"Pip pode exportar uma lista de todos os pacotes instalados e suas versões " -"usando o comando ``freeze``:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 -msgid "Which will output a list of package specifiers such as:" -msgstr "O que resultará em uma lista de especificadores de pacote, como:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 -msgid "" -"This is useful for creating :ref:`pip:Requirements Files` that can re-create " -"the exact versions of all packages installed in an environment." -msgstr "" -"Isso é útil para criar :ref:`pip:Requirements Files` que podem recriar as " -"versões exatas de todos os pacotes instalados em um ambiente." - -#: ../source/guides/making-a-pypi-friendly-readme.rst:2 -msgid "Making a PyPI-friendly README" -msgstr "Criando um README amigável para PyPI" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:4 -msgid "" -"README files can help your users understand your project and can be used to " -"set your project's description on PyPI. This guide helps you create a README " -"in a PyPI-friendly format and include your README in your package so it " -"appears on PyPI." -msgstr "" -"Os arquivos README podem ajudar seus usuários a entender o seu projeto e " -"podem ser usados para definir a descrição do seu projeto no PyPI. Este guia " -"ajuda a criar um README em um formato amigável ao PyPI e inclui seu README " -"em seu pacote para que apareça no PyPI." - -#: ../source/guides/making-a-pypi-friendly-readme.rst:9 -msgid "Creating a README file" -msgstr "Criando um arquivo README" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:11 -msgid "" -"README files for Python projects are often named ``README``, ``README.txt``, " -"``README.rst``, or ``README.md``." -msgstr "" -"Arquivos README para projetos Python são frequentemente chamados de " -"``README``, ``README.txt``, ``README.rst`` ou ``README.md``." - -#: ../source/guides/making-a-pypi-friendly-readme.rst:13 -msgid "" -"For your README to display properly on PyPI, choose a markup language " -"supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" -msgstr "" -"Para que seu README seja exibido corretamente no PyPI, escolha uma linguagem " -"de marcação suportada pelo PyPI. Os formatos suportados pelo renderizador de " -"README do `PyPI `_ são:" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:16 -msgid "plain text" -msgstr "texto simples" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:17 -msgid "" -"`reStructuredText `_ (without " -"Sphinx extensions)" -msgstr "" -"`reStructuredText `_ (sem " -"extensões do Sphinx)" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:18 -msgid "" -"Markdown (`GitHub Flavored Markdown `_ by " -"default, or `CommonMark `_)" -msgstr "" -"Markdown (`GitHub Flavored Markdown `_ por " -"padrão ou `CommonMark `_)" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:21 -msgid "" -"It's customary to save your README file in the root of your project, in the " -"same directory as your :file:`setup.py` file." -msgstr "" -"É comum salvar seu arquivo README na raiz de seu projeto, no mesmo diretório " -"que seu arquivo :file:`setup.py`." - -#: ../source/guides/making-a-pypi-friendly-readme.rst:25 -msgid "Including your README in your package's metadata" -msgstr "Incluindo seu README nos metadados do seu pacote" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:27 -msgid "" -"To include your README's contents as your package description, set your " -"project's ``Description`` and ``Description-Content-Type`` metadata, " -"typically in your project's :file:`setup.py` file." -msgstr "" -"Para incluir o conteúdo do README como a descrição do pacote, defina os " -"metadados ``Description`` e ``Description-Content-Type`` do seu projeto, " -"normalmente no arquivo :file:`setup.py` do seu projeto." - -#: ../source/guides/making-a-pypi-friendly-readme.rst:33 -msgid ":ref:`description-optional`" -msgstr ":ref:`description-optional`" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:34 -msgid ":ref:`description-content-type-optional`" -msgstr ":ref:`description-content-type-optional`" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:36 -msgid "" -"For example, to set these values in a package's :file:`setup.py` file, use " -"``setup()``'s ``long_description`` and ``long_description_content_type``." -msgstr "" -"Por exemplo, para definir esses valores em um arquivo :file:`setup.py` do " -"pacote, use ``long_description`` e ``long_description_content_type`` do " -"``setup()``." - -#: ../source/guides/making-a-pypi-friendly-readme.rst:39 -msgid "" -"Set the value of ``long_description`` to the contents (not the path) of the " -"README file itself. Set the ``long_description_content_type`` to an accepted " -"``Content-Type``-style value for your README file's markup, such as ``text/" -"plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." -msgstr "" -"Defina o valor de ``long_description`` para o conteúdo (não o caminho) do " -"próprio arquivo README. Defina o ``long_description_content_type`` para um " -"valor aceito no estilo ``Content-Type`` para a marcação do seu arquivo " -"README, como ``text/plain``, ``text/t-rst`` (para reStructuredText) ou " -"``text/markdown``." - -#: ../source/guides/making-a-pypi-friendly-readme.rst:45 -msgid "" -"If you're using GitHub-flavored Markdown to write a project's description, " -"ensure you upgrade the following tools:" -msgstr "" -"Se você estiver usando o Markdown do GitHub para escrever a descrição de um " -"projeto, certifique-se de atualizar as seguintes ferramentas:" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:60 -msgid "The minimum required versions of the respective tools are:" -msgstr "As versões mínimas exigidas das respectivas ferramentas são:" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:62 -msgid "``setuptools >= 38.6.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:63 -msgid "``wheel >= 0.31.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:64 -msgid "``twine >= 1.11.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:66 -msgid "" -"It's recommended that you use ``twine`` to upload the project's distribution " -"packages:" -msgstr "" -"É recomendado que você use ``twine`` para enviar pacotes de distribuição do " -"projeto:" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:72 -msgid "" -"For example, see this :file:`setup.py` file, which reads the contents of :" -"file:`README.md` as ``long_description`` and identifies the markup as GitHub-" -"flavored Markdown:" -msgstr "" -"Por exemplo, veja este arquivo :file:`setup.py`, que lê o conteúdo de :file:" -"`README.md` como ``long_description`` e identifica a marcação como Markdown " -"do GitHub:" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:95 -msgid "Validating reStructuredText markup" -msgstr "Validando a marcação reStructuredText" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:97 -msgid "" -"If your README is written in reStructuredText, any invalid markup will " -"prevent it from rendering, causing PyPI to instead just show the README's " -"raw source." -msgstr "" -"Se o seu README for escrito em reStructuredText, qualquer marcação inválida " -"irá impedi-lo de renderizar, fazendo com que o PyPI mostre apenas o código-" -"fonte não tratado do README." - -#: ../source/guides/making-a-pypi-friendly-readme.rst:100 -msgid "" -"Note that Sphinx extensions used in docstrings, such as `directives and " -"roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```" -"\"), are not allowed here and will result in error messages like \"``Error: " -"Unknown interpreted text role \"py:func\".``\"." -msgstr "" -"Observe que as extensões Sphinx usadas em docstrings, como `diretivas e " -"funções `_ (por exemplo, \"``:py:func:`getattr```\" ou \"``:ref:`my-reference-" -"label```\"), não são permitidas aqui e resultarão em mensagens de erro como " -"\"``Error: Unknown interpreted text role \"py:func\".``\"." - -#: ../source/guides/making-a-pypi-friendly-readme.rst:105 -msgid "" -"You can check your README for markup errors before uploading as follows:" -msgstr "" -"Você pode verificar se há erros de marcação em seu README antes de enviar:" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:107 -msgid "" -"Install the latest version of `twine `_; " -"version 1.12.0 or higher is required:" -msgstr "" -"Instale a versão mais recente do `twine `_; " -"versão 1.12.0 ou superior é necessária:" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:122 -msgid "" -"Build the sdist and wheel for your project as described under :ref:" -"`Packaging Your Project`." -msgstr "" -"Construa o sdist e o wheel para seu projeto conforme descrito em :ref:" -"`Empacotando seu projeto `." - -#: ../source/guides/making-a-pypi-friendly-readme.rst:125 -msgid "Run ``twine check`` on the sdist and wheel::" -msgstr "Execute ``twine check`` no sdist e wheel::" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:129 -msgid "" -"This command will report any problems rendering your README. If your markup " -"renders fine, the command will output ``Checking distribution FILENAME: " -"Passed``." -msgstr "" -"Este comando relatará quaisquer problemas ao processar seu README. Se sua " -"marcação renderizar corretamente, o comando produzirá ``Checking " -"Distribution FILENAME: Passed``." - -#: ../source/guides/migrating-to-pypi-org.rst:4 -msgid "Migrating to PyPI.org" -msgstr "Migrando para PyPI.org" - -#: ../source/guides/migrating-to-pypi-org.rst:6 -msgid "" -":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``." -msgstr "" -":term:`pypi.org` é a nova versão reescrita do PyPI que substituiu a base de " -"código legada do PyPI. É a versão padrão do PyPI que se espera que as " -"pessoas usem. Estas são as ferramentas e processos que as pessoas precisarão " -"para interagir com o ``PyPI .org``." - -#: ../source/guides/migrating-to-pypi-org.rst:12 -msgid "Publishing releases" -msgstr "Publicando lançamentos" - -#: ../source/guides/migrating-to-pypi-org.rst:14 -msgid "``pypi.org`` is the default upload platform as of September 2016." -msgstr "``pypi.org`` é a plataforma padrão para envio em setembro de 2016." - -#: ../source/guides/migrating-to-pypi-org.rst:16 -msgid "" -"Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. " -"As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." -msgstr "" -"Os envios por meio de ``pypi.python.org`` foram *desativados* em **3 de " -"julho de 2017**. Desde 13 de abril de 2018, ``pypi.org`` é a URL do PyPI." - -#: ../source/guides/migrating-to-pypi-org.rst:19 -msgid "" -"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." -msgstr "" -"A maneira recomendada de migrar para PyPI.org para enviar é garantir que " -"você esteja usando uma versão nova o suficiente de sua ferramenta de envio." - -#: ../source/guides/migrating-to-pypi-org.rst:22 -msgid "" -"The default upload settings switched to ``pypi.org`` in the following " -"versions:" -msgstr "" -"As configurações de envio padrão mudaram para ``pypi.org`` nas seguintes " -"versões:" - -#: ../source/guides/migrating-to-pypi-org.rst:24 -msgid "``twine`` 1.8.0" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:25 -msgid "``setuptools`` 27.0.0" -msgstr "``setuptools`` 27.0.0" - -#: ../source/guides/migrating-to-pypi-org.rst:26 -msgid "Python 2.7.13 (``distutils`` update)" -msgstr "Python 2.7.13 (atualização de ``distutils``)" - -#: ../source/guides/migrating-to-pypi-org.rst:27 -msgid "Python 3.4.6 (``distutils`` update)" -msgstr "Python 3.4.6 (atualização de ``distutils``)" - -#: ../source/guides/migrating-to-pypi-org.rst:28 -msgid "Python 3.5.3 (``distutils`` update)" -msgstr "Python 3.5.3 (atualização de ``distutils``)" - -#: ../source/guides/migrating-to-pypi-org.rst:29 -msgid "Python 3.6.0 (``distutils`` update)" -msgstr "Python 3.6.0 (atualização de ``distutils``)" - -#: ../source/guides/migrating-to-pypi-org.rst:31 -msgid "" -"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:" -msgstr "" -"Além de garantir que você esteja em uma versão nova o suficiente da " -"ferramenta para que o padrão da ferramenta seja alterado, você também deve " -"se certificar de que não configurou a ferramenta para substituir sua URL de " -"envio padrão. Normalmente, isso é configurado em um arquivo localizado em :" -"file:`$HOME/.pypirc`. Se você vir um arquivo como:" - -#: ../source/guides/migrating-to-pypi-org.rst:48 -msgid "" -"Then simply delete the line starting with ``repository`` and you will use " -"your upload tool's default URL." -msgstr "" -"Em seguida, simplesmente exclua a linha começando com ``repository`` e você " -"usará a URL padrão da sua ferramenta de envio." - -#: ../source/guides/migrating-to-pypi-org.rst:51 -msgid "" -"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:" -msgstr "" -"Se por algum motivo você não puder atualizar a versão de sua ferramenta para " -"uma versão que usa o padrão PyPI.org, então você pode editar :file:`$HOME/." -"pypirc` e incluir a linha ``repository:``, mas use o valor ``https://upload." -"pypi.org/legacy/`` em vez disso:" - -#: ../source/guides/migrating-to-pypi-org.rst:67 -msgid "" -"(``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.)" -msgstr "" -"(``legacy`` nesta URL refere-se ao fato de que esta é a emulação da " -"implementação do novo servidor para a API de envio da implementação do " -"servidor legado.)" - -#: ../source/guides/migrating-to-pypi-org.rst:73 -msgid "Registering package names & metadata" -msgstr "Registrando nomes pacotes e metadados" - -#: ../source/guides/migrating-to-pypi-org.rst:75 -msgid "" -"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." -msgstr "" -"O pré-registro explícito de nomes de pacotes com o comando ``setup.py " -"register`` antes do primeiro envio não é mais necessário e não é mais " -"suportado pela emulação de API de envio legado no PyPI.org." - -#: ../source/guides/migrating-to-pypi-org.rst:79 -msgid "" -"As a result, attempting explicit registration after switching to using PyPI." -"org for uploads will give the following error message::" -msgstr "" -"Como resultado, a tentativa de registro explícito após alternar para o uso " -"de PyPI.org para envios gerará a seguinte mensagem de erro::" - -#: ../source/guides/migrating-to-pypi-org.rst:84 -msgid "" -"The solution is to skip the registration step, and proceed directly to " -"uploading artifacts." -msgstr "" -"A solução é pular a etapa de registro e prosseguir diretamente para o envio " -"dos artefatos." - -#: ../source/guides/migrating-to-pypi-org.rst:89 -#: ../source/guides/using-testpypi.rst:5 -msgid "Using TestPyPI" -msgstr "Usando TestPyPI" - -#: ../source/guides/migrating-to-pypi-org.rst:91 -msgid "" -"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:" -msgstr "" -"O TestPyPI legado (testpypi.python.org) não está mais disponível; use `test." -"pypi.org `_ em vez disso. Se você usar o TestPyPI, " -"você deve atualizar seu :file:`$HOME/.pypirc` para lidar com o novo local do " -"TestPyPI, substituindo ``https://testpypi.python.org/pypi`` por ``https://" -"test.pypi.org/legacy/``, por exemplo:" - -#: ../source/guides/migrating-to-pypi-org.rst:113 -msgid "Registering new user accounts" -msgstr "Registrando novas contas de usuário" - -#: ../source/guides/migrating-to-pypi-org.rst:115 -msgid "" -"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." -msgstr "" -"A fim de ajudar a mitigar ataques de spam contra PyPI, o registro de novo " -"usuário por meio de ``pypi.python.org`` foi *desativado* em **20 de " -"fevereiro de 2018**. Novos registros de usuários em ``pypi.org`` estão " -"abertos." - -#: ../source/guides/migrating-to-pypi-org.rst:121 -msgid "Browsing packages" -msgstr "Navegando pelos pacotes" - -#: ../source/guides/migrating-to-pypi-org.rst:123 -msgid "" -"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." -msgstr "" -"Embora ``pypi.python.org`` ainda possa ser usado em links de outras " -"documentações do PyPA, etc, a interface padrão para navegar pelos pacotes é " -"``pypi.org``. O domínio pypi.python.org agora redireciona para pypi.org e " -"pode ser desativado em algum momento no futuro." - -#: ../source/guides/migrating-to-pypi-org.rst:130 -msgid "Downloading packages" -msgstr "Baixando pacotes" - -#: ../source/guides/migrating-to-pypi-org.rst:132 -msgid "``pypi.org`` is the default host for downloading packages." -msgstr "``pypi.org`` é o host padrão para download de pacotes." - -#: ../source/guides/migrating-to-pypi-org.rst:135 -msgid "Managing published packages and releases" -msgstr "Gerenciando pacotes e lançamentos publicados" - -#: ../source/guides/migrating-to-pypi-org.rst:137 -msgid "" -"``pypi.org`` provides a fully functional interface for logged in users to " -"manage their published packages and releases." -msgstr "" -"``pypi.org`` fornece uma interface totalmente funcional para usuários " -"autenticados gerenciarem seus pacotes publicados e lançamentos." - -#: ../source/guides/multi-version-installs.rst:5 -msgid "Multi-version installs" -msgstr "Instalações de várias versões" - -#: ../source/guides/multi-version-installs.rst:8 -msgid "" -"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``)." -msgstr "" -"easy_install permite a instalação simultânea de diferentes versões do mesmo " -"projeto em um único ambiente compartilhado por vários programas que devem " -"exigir (``require``) a versão apropriada do projeto em tempo de execução " -"(usando ``pkg_resources``)." - -#: ../source/guides/multi-version-installs.rst:13 -msgid "" -"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." -msgstr "" -"Para muitos casos de uso, ambientes virtuais atendem a essa necessidade sem " -"a complicação da diretiva ``require``. No entanto, a vantagem de instalações " -"paralelas dentro do mesmo ambiente é que funciona para um ambiente " -"compartilhado por várias aplicações, como o sistema Python em uma " -"distribuição Linux." - -#: ../source/guides/multi-version-installs.rst:19 -msgid "" -"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." -msgstr "" -"A principal limitação da instalação paralela baseada em ``pkg_resources`` é " -"que assim que você importa ``pkg_resources`` ele bloqueia a versão *padrão* " -"de tudo que já está disponível em sys.path. Isso pode causar problemas, já " -"que ``setuptools`` scripts de linha de comando criados usam " -"``pkg_resources`` para encontrar o ponto de entrada a ser executado. Isso " -"significa que, por exemplo, você não pode usar testes de ``require`` " -"invocados através do ``nose`` ou uma aplicação WSGI invocada através do " -"``gunicorn`` se sua aplicação precisa de uma versão não padrão de qualquer " -"coisa que está disponível no ``sys.path`` padrão -- o script wrapper para a " -"aplicação principal travará na versão que está disponível por padrão, então " -"a chamada subsequente de ``require`` em seu próprio código falhará com um " -"conflito de versão espúrio." - -#: ../source/guides/multi-version-installs.rst:31 -msgid "" -"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 ``python -c ''`` to invoke the application's main " -"entry point directly." -msgstr "" -"Isso pode ser contornado definindo todas as dependências em ``__main__.__ " -"require__`` antes de importar ``pkg_resources`` pela primeira vez, mas essa " -"abordagem significa que as invocações de linha de comando padrão das " -"ferramentas afetadas não podem ser usadas -- é necessário escrever um script " -"wrapper personalizado ou usar ``python -c ''`` para invocar o ponto " -"de entrada principal da aplicação diretamente." - -#: ../source/guides/multi-version-installs.rst:38 -msgid "" -"Refer to the `pkg_resources documentation `__ for more details." -msgstr "" -"Confira a `documentação de pkg_resources `__ para mais detalhes." - -#: ../source/guides/packaging-binary-extensions.rst:5 -msgid "Packaging binary extensions" -msgstr "Empacotando extensões binárias" - -#: ../source/guides/packaging-binary-extensions.rst:8 -msgid "2013-12-08" -msgstr "2013-12-08" - -#: ../source/guides/packaging-binary-extensions.rst:10 -msgid "" -"One of the features of the CPython reference interpreter is that, in " -"addition to allowing the execution of Python code, it also exposes a rich C " -"API for use by other software. One of the most common uses of this C API is " -"to create importable C extensions that allow things which aren't always easy " -"to achieve in pure Python code." -msgstr "" -"Uma das características do interpretador de referência CPython é que, além " -"de permitir a execução do código Python, também expõe uma API C rica para " -"uso por outro software. Um dos usos mais comuns dessa API C é criar " -"extensões C importáveis que permitem coisas que nem sempre são fáceis de " -"alcançar em código puro Python." - -#: ../source/guides/packaging-binary-extensions.rst:20 -msgid "An overview of binary extensions" -msgstr "Uma visão geral de extensões binárias" - -#: ../source/guides/packaging-binary-extensions.rst:23 -msgid "Use cases" -msgstr "Casos de uso" - -#: ../source/guides/packaging-binary-extensions.rst:25 -msgid "" -"The typical use cases for binary extensions break down into just three " -"conventional categories:" -msgstr "" -"Os casos de uso típicos para extensões binárias se dividem em apenas três " -"categorias convencionais:" - -#: ../source/guides/packaging-binary-extensions.rst:28 -msgid "" -"**accelerator modules**: these modules are completely self-contained, and " -"are created solely to run faster than the equivalent pure Python code runs " -"in CPython. Ideally, accelerator modules will always have a pure Python " -"equivalent to use as a fallback if the accelerated version isn't available " -"on a given system. The CPython standard library makes extensive use of " -"accelerator modules. *Example*: When importing ``datetime``, Python falls " -"back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not " -"available." -msgstr "" -"**Módulos aceleradores**: esses módulos são completamente autocontidos e são " -"criados exclusivamente para executar mais rápido do que o código puro Python " -"equivalente é executado em CPython. Idealmente, os módulos aceleradores " -"sempre terão um Python equivalente puro para usar como fallback se a versão " -"acelerada não estiver disponível em um determinado sistema. A biblioteca " -"padrão do CPython faz uso extensivo de módulos aceleradores. *Exemplo*: Ao " -"importar ``datetime``, Python recorre ao módulo `datetime.py `_ se a implementação C " -"( `_datetimemodule.c `_) não estiver disponível." - -#: ../source/guides/packaging-binary-extensions.rst:39 -msgid "" -"**wrapper modules**: these modules are created to expose existing C " -"interfaces to Python code. They may either expose the underlying C interface " -"directly, or else expose a more \"Pythonic\" API that makes use of Python " -"language features to make the API easier to use. The CPython standard " -"library makes extensive use of wrapper modules. *Example*: `functools.py " -"`_ is a " -"Python module wrapper for `_functoolsmodule.c `_." -msgstr "" -"**módulos wrapper**: esses módulos são criados para expor as interfaces C " -"existentes ao código Python. Eles podem expor a interface C subjacente " -"diretamente ou então expor uma API mais \"Pythônica\" que faz uso dos " -"recursos da linguagem Python para tornar a API mais fácil de usar. A " -"biblioteca padrão do CPython faz uso extensivo de módulos wrapper. " -"*Exemplo*: `functools.py `_ é um módulo Python wrapper para `_functoolsmodule.c `_." - -#: ../source/guides/packaging-binary-extensions.rst:47 -msgid "" -"**low-level system access**: these modules are created to access lower level " -"features of the CPython runtime, the operating system, or the underlying " -"hardware. Through platform specific code, extension modules may achieve " -"things that aren't possible in pure Python code. A number of CPython " -"standard library modules are written in C in order to access interpreter " -"internals that aren't exposed at the language level. *Example*: ``sys``, " -"which comes from `sysmodule.c `_." -msgstr "" -"**acesso de baixo nível ao sistema**: esses módulos são criados para acessar " -"os recursos de baixo nível do tempo de execução do CPython, do sistema " -"operacional ou do hardware subjacente. Por meio do código específico da " -"plataforma, os módulos de extensão podem alcançar coisas que não são " -"possíveis no código puro Python. Vários módulos de biblioteca padrão do " -"CPython são escritos em C para acessar as partes internas do interpretador " -"que não são expostas no nível da linguagem. *Exemplo*: ``sys``, que vem de " -"`sysmodule.c `_." - -#: ../source/guides/packaging-binary-extensions.rst:56 -msgid "" -"One particularly notable feature of C extensions is that, when they don't " -"need to call back into the interpreter runtime, they can release CPython's " -"global interpreter lock around long-running operations (regardless of " -"whether those operations are CPU or IO bound)." -msgstr "" -"Um recurso particularmente notável das extensões C é que, quando não " -"precisam chamar de volta para o tempo de execução do interpretador, podem " -"liberar o bloqueio do interpretador global do CPython em torno de operações " -"de longa duração (independentemente de essas operações serem vinculados à " -"CPU ou à E/S)." - -#: ../source/guides/packaging-binary-extensions.rst:61 -msgid "" -"Not all extension modules will fit neatly into the above categories. The " -"extension modules included with NumPy, for example, span all three use cases " -"- they move inner loops to C for speed reasons, wrap external libraries " -"written in C, FORTRAN and other languages, and use low level system " -"interfaces for both CPython and the underlying operation system to support " -"concurrent execution of vectorised operations and to tightly control the " -"exact memory layout of created objects." -msgstr "" -"Nem todos os módulos de extensão se encaixam perfeitamente nas categorias " -"acima. Os módulos de extensão incluídos com NumPy, por exemplo, abrangem " -"todos os três casos de uso -- eles movem loops internos para C por motivos " -"de velocidade, agrupam bibliotecas externas escritas em C, FORTRAN e outras " -"linguagens e usam interfaces de sistema de baixo nível para CPython e o " -"sistema operacional subjacente para oferecer suporte à execução simultânea " -"de operações vetorizadas e para controlar rigidamente o layout de memória " -"exato dos objetos criados." - -#: ../source/guides/packaging-binary-extensions.rst:71 -msgid "Disadvantages" -msgstr "Desvantagens" - -#: ../source/guides/packaging-binary-extensions.rst:73 -msgid "" -"The main disadvantage of using binary extensions is the fact that it makes " -"subsequent distribution of the software more difficult. One of the " -"advantages of using Python is that it is largely cross platform, and the " -"languages used to write extension modules (typically C or C++, but really " -"any language that can bind to the CPython C API) typically require that " -"custom binaries be created for different platforms." -msgstr "" -"A principal desvantagem de usar extensões binárias é o fato de tornar a " -"distribuição subsequente do software mais difícil. Uma das vantagens de usar " -"o Python é que ele é amplamente multiplataforma, e as linguagens usadas para " -"escrever módulos de extensão (normalmente C ou C++, mas na verdade qualquer " -"linguagem que possa se ligar à API C do CPython) normalmente exigem que " -"binários personalizados podem ser criados para plataformas diferentes." - -#: ../source/guides/packaging-binary-extensions.rst:80 -msgid "This means that binary extensions:" -msgstr "Isso significa que extensões binárias:" - -#: ../source/guides/packaging-binary-extensions.rst:82 -msgid "" -"require that end users be able to either build them from source, or else " -"that someone publish pre-built binaries for common platforms" -msgstr "" -"exigem que os usuários finais sejam capazes de criá-las a partir do código-" -"fonte, ou então que alguém publique binários pré-construídos para " -"plataformas comuns" - -#: ../source/guides/packaging-binary-extensions.rst:85 -msgid "" -"may not be compatible with different builds of the CPython reference " -"interpreter" -msgstr "" -"pode não ser compatível com diferentes compilações do interpretador de " -"referência do CPython" - -#: ../source/guides/packaging-binary-extensions.rst:88 -msgid "" -"often will not work correctly with alternative interpreters such as PyPy, " -"IronPython or Jython" -msgstr "" -"frequentemente não funciona corretamente com interpretadores alternativos " -"como PyPy, Iron Python ou Jython" - -#: ../source/guides/packaging-binary-extensions.rst:91 -msgid "" -"if handcoded, make maintenance more difficult by requiring that maintainers " -"be familiar not only with Python, but also with the language used to create " -"the binary extension, as well as with the details of the CPython C API." -msgstr "" -"se codificado manualmente, torna a manutenção mais difícil, exigindo que os " -"mantenedores estejam familiarizados não apenas com Python, mas também com a " -"linguagem usada para criar a extensão binária, bem como com os detalhes da " -"API C do CPython." - -#: ../source/guides/packaging-binary-extensions.rst:96 -msgid "" -"if a pure Python fallback implementation is provided, make maintenance more " -"difficult by requiring that changes be implemented in two places, and " -"introducing additional complexity in the test suite to ensure both versions " -"are always executed." -msgstr "" -"se uma implementação de fallback de puro Python for fornecida, torna a " -"manutenção mais difícil, exigindo que as alterações sejam implementadas em " -"dois lugares, e introduzindo complexidade adicional no conjunto de testes " -"para garantir que ambas as versões sejam sempre executadas." - -#: ../source/guides/packaging-binary-extensions.rst:101 -msgid "" -"Another disadvantage of relying on binary extensions is that alternative " -"import mechanisms (such as the ability to import modules directly from " -"zipfiles) often won't work for extension modules (as the dynamic loading " -"mechanisms on most platforms can only load libraries from disk)." -msgstr "" -"Outra desvantagem de depender de extensões binárias é que mecanismos de " -"importação alternativos (como a capacidade de importar módulos diretamente " -"de arquivos zip) geralmente não funcionam para módulos de extensão (já que " -"os mecanismos de carregamento dinâmico na maioria das plataformas só podem " -"carregar bibliotecas do disco)." - -#: ../source/guides/packaging-binary-extensions.rst:108 -msgid "Alternatives to handcoded accelerator modules" -msgstr "Alternativas para módulos aceleradores codificados manualmente" - -#: ../source/guides/packaging-binary-extensions.rst:110 -msgid "" -"When extension modules are just being used to make code run faster (after " -"profiling has identified the code where the speed increase is worth " -"additional maintenance effort), a number of other alternatives should also " -"be considered:" -msgstr "" -"Quando os módulos de extensão estão apenas sendo usados para tornar o código " -"executado mais rápido (após a criação de perfil ter identificado o código " -"onde o aumento de velocidade vale um esforço de manutenção adicional), uma " -"série de outras alternativas também devem ser consideradas:" - -#: ../source/guides/packaging-binary-extensions.rst:115 -msgid "" -"look for existing optimised alternatives. The CPython standard library " -"includes a number of optimised data structures and algorithms (especially in " -"the builtins and the ``collections`` and ``itertools`` modules). The Python " -"Package Index also offers additional alternatives. Sometimes, the " -"appropriate choice of standard library or third party module can avoid the " -"need to create your own accelerator module." -msgstr "" -"procure alternativas otimizadas existentes. A biblioteca padrão do CPython " -"inclui uma série de estruturas de dados e algoritmos otimizados " -"(especialmente nos módulos embutidos e ``collections`` e ``itertools``). O " -"índice de Pacotes do Python também oferece alternativas adicionais. Às " -"vezes, a escolha apropriada de biblioteca padrão ou módulo de terceiros pode " -"evitar a necessidade de criar seu próprio módulo acelerador." - -#: ../source/guides/packaging-binary-extensions.rst:122 -msgid "" -"for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython " -"runtime. The main barrier to adopting PyPy is typically reliance on other " -"binary extension modules - while PyPy does emulate the CPython C API, " -"modules that rely on that cause problems for the PyPy JIT, and the emulation " -"layer can often expose latent defects in extension modules that CPython " -"currently tolerates (frequently around reference counting errors - an object " -"having one live reference instead of two often won't break anything, but no " -"references instead of one is a major problem)." -msgstr "" -"para aplicações de longa execução, o `interpretador PyPy `__ compilado por JIT pode oferecer uma alternativa adequada ao tempo de " -"execução padrão do CPython. A principal barreira para a adoção do PyPy é " -"normalmente a dependência de outros módulos de extensão binários -- enquanto " -"o PyPy emula a API C do CPython, os módulos que dependem disso causam " -"problemas para o PyPy de JIT e a camada de emulação pode frequentemente " -"expor defeitos latentes na extensão módulos que o CPython atualmente tolera " -"(frequentemente em torno de erros de contagem de referências -- um objeto " -"com uma referência ativa em vez de duas geralmente não quebrará nada, mas " -"nenhuma referência em vez de uma é um grande problema)." - -#: ../source/guides/packaging-binary-extensions.rst:132 -msgid "" -"`Cython `__ is a mature static compiler that can compile " -"most Python code to C extension modules. The initial compilation provides " -"some speed increases (by bypassing the CPython interpreter layer), and " -"Cython's optional static typing features can offer additional opportunities " -"for speed increases. Using Cython still has the disadvantage of increasing " -"the complexity of distributing the resulting application, but has the " -"benefit of having a reduced barrier to entry for Python programmers " -"(relative to other languages like C or C++)." -msgstr "" -"`Cython `__ é um compilador estático maduro que pode " -"compilar a maioria dos códigos Python para módulos de extensão C. A " -"compilação inicial fornece alguns aumentos de velocidade (contornando a " -"camada de interpretador do CPython) e os recursos opcionais de tipagem " -"estática do Cython podem oferecer oportunidades adicionais para aumentos de " -"velocidade. Usar o Cython ainda tem a desvantagem de aumentar a complexidade " -"de distribuição da aplicação resultante, mas tem o benefício de ter uma " -"barreira de entrada reduzida para programadores Python (em relação a outras " -"linguagens como C ou C++)." - -#: ../source/guides/packaging-binary-extensions.rst:141 -msgid "" -"`Numba `__ is a newer tool, created by members of " -"the scientific Python community, that aims to leverage LLVM to allow " -"selective compilation of pieces of a Python application to native machine " -"code at runtime. It requires that LLVM be available on the system where the " -"code is running, but can provide significant speed increases, especially for " -"operations that are amenable to vectorisation." -msgstr "" -"`Numba `__ é uma ferramenta mais recente, criada " -"por membros da comunidade científica do Python, que visa alavancar o LLVM " -"para permitir a compilação seletiva de partes de uma aplicação Python para " -"código de máquina nativo em tempo de execução. Requer que o LLVM esteja " -"disponível no sistema onde o código está sendo executado, mas pode fornecer " -"aumentos de velocidade significativos, especialmente para operações que são " -"passíveis de vetorização." - -#: ../source/guides/packaging-binary-extensions.rst:150 -msgid "Alternatives to handcoded wrapper modules" -msgstr "Alternativas para módulos wrapper codificados manualmente" - -#: ../source/guides/packaging-binary-extensions.rst:152 -msgid "" -"The C ABI (Application Binary Interface) is a common standard for sharing " -"functionality between multiple applications. One of the strengths of the " -"CPython C API (Application Programming Interface) is allowing Python users " -"to tap into that functionality. However, wrapping modules by hand is quite " -"tedious, so a number of other alternative approaches should be considered." -msgstr "" -"A ABI C (Interface Binária de Aplicação) é um padrão comum para " -"compartilhamento de funcionalidade entre várias aplicações. Um dos pontos " -"fortes da API C do CPython (Interface de Programação de Aplicação) é " -"permitir que os usuários do Python aproveitem essa funcionalidade. No " -"entanto, empacotar módulos manualmente é muito tedioso, portanto, várias " -"outras abordagens alternativas devem ser consideradas." - -#: ../source/guides/packaging-binary-extensions.rst:158 -msgid "" -"The approaches described below don't simplify the distribution case at all, " -"but they *can* significantly reduce the maintenance burden of keeping " -"wrapper modules up to date." -msgstr "" -"As abordagens descritas abaixo não simplificam o caso de distribuição, mas " -"*podem* reduzir significativamente a carga de manutenção de manter os " -"módulos wrapper atualizados." - -#: ../source/guides/packaging-binary-extensions.rst:162 -msgid "" -"In addition to being useful for the creation of accelerator modules, `Cython " -"`__ is also useful for creating wrapper modules for C or " -"C++. It still involves wrapping the interfaces by hand, however, and is very " -"repetitive, so may not be a good choice for wrapping large APIs." -msgstr "" -"Além de ser útil para a criação de módulos aceleradores, `Cython `__ também é útil para criar módulos wrapper para C ou C++. No " -"entanto, ainda envolve fazer wrapper das interfaces manualmente e é muito " -"repetitivo, portanto, pode não ser uma boa escolha para empacotar APIs " -"grandes." - -#: ../source/guides/packaging-binary-extensions.rst:168 -msgid "" -"`pybind11 `__ is a pure C++11 library that " -"provides a clean C++ interface to the CPython (and PyPy) C API. It does not " -"require a pre-processing step; it is written entirely in templated C++. " -"Helpers are included for Setuptools or CMake builds. It was based on `Boost." -"Python `__, but doesn't require the Boost libraries or BJam." -msgstr "" -"`pybind11 `__ é uma biblioteca C++11 pura " -"que fornece uma interface C++ limpa para a API C do CPython (e PyPy). Não " -"requer uma etapa de pré-processamento; ele é escrito inteiramente em C++ " -"modelado. Auxiliares são incluídos para construções de Setuptools ou CMake. " -"Foi baseado em `Boost.Python `__, mas não requer as bibliotecas Boost ou BJam." - -#: ../source/guides/packaging-binary-extensions.rst:175 -msgid "" -"`cffi `__ is a project created by some of the " -"PyPy developers to make it straightforward for developers that already know " -"both Python and C to expose their C modules to Python applications. It also " -"makes it relatively straightforward to wrap a C module based on its header " -"files, even if you don't know C yourself." -msgstr "" -"`cffi `__ é um projeto criado por alguns dos " -"desenvolvedores PyPy para torná-lo simples para desenvolvedores que já " -"conhecem Python e C expor seus módulos C a aplicações Python. Também torna " -"relativamente simples fazer um wrapper de um módulo C com base em seus " -"arquivos de cabeçalho, mesmo que você não conheça C." - -#: ../source/guides/packaging-binary-extensions.rst:181 -msgid "" -"One of the key advantages of ``cffi`` is that it is compatible with the PyPy " -"JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing " -"JIT optimisations." -msgstr "" -"Uma das principais vantagens do ``cffi`` é que ele é compatível com o PyPy " -"de JIT, permitindo que os módulos wrapper de CFFI participem totalmente das " -"otimizações JIT de rastreamento do PyPy." - -#: ../source/guides/packaging-binary-extensions.rst:185 -msgid "" -"`SWIG `__ is a wrapper interface generator that allows " -"a variety of programming languages, including Python, to interface with C " -"and C++ code." -msgstr "" -"`SWIG `__ é um wrapper gerador de interface que " -"permite uma variedade de linguagens de programação, incluindo Python, para " -"fazer interface com código C e C++." - -#: ../source/guides/packaging-binary-extensions.rst:189 -msgid "" -"The standard library's ``ctypes`` module, while useful for getting access to " -"C level interfaces when header information isn't available, suffers from the " -"fact that it operates solely at the C ABI level, and thus has no automatic " -"consistency checking between the interface actually being exported by the " -"library and the one declared in the Python code. By contrast, the above " -"alternatives are all able to operate at the C *API* level, using C header " -"files to ensure consistency between the interface exported by the library " -"being wrapped and the one expected by the Python wrapper module. While " -"``cffi`` *can* operate directly at the C ABI level, it suffers from the same " -"interface inconsistency problems as ``ctypes`` when it is used that way." -msgstr "" -"O módulo ``ctypes`` da biblioteca padrão, embora útil para obter acesso a " -"interfaces de nível C quando as informações do cabeçalho não estão " -"disponíveis, sofre do fato de operar exclusivamente no nível ABI do C e, " -"portanto, não tem verificação automática de consistência entre os interface " -"realmente sendo exportada pela biblioteca e aquela declarada no código " -"Python. Em contraste, as alternativas acima são todas capazes de operar no " -"nível *API* do C, usando arquivos de cabeçalho C para garantir consistência " -"entre a interface exportada pela biblioteca sendo empacotada e aquela " -"esperada pelo módulo empacotador Python. Enquanto ``cffi`` *pode* operar " -"diretamente no nível ABI do C, ele sofre dos mesmos problemas de " -"inconsistência de interface que ``ctypes`` quando é usado dessa forma." - -#: ../source/guides/packaging-binary-extensions.rst:203 -msgid "Alternatives for low level system access" -msgstr "Alternativas para acesso de baixo nível ao sistema" - -#: ../source/guides/packaging-binary-extensions.rst:205 -msgid "" -"For applications that need low level system access (regardless of the " -"reason), a binary extension module often *is* the best way to go about it. " -"This is particularly true for low level access to the CPython runtime " -"itself, since some operations (like releasing the Global Interpreter Lock) " -"are simply invalid when the interpreter is running code, even if a module " -"like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API " -"interfaces." -msgstr "" -"Para aplicações que precisam de acesso de baixo nível ao sistema " -"(independentemente do motivo), um módulo de extensão binária geralmente *é* " -"a melhor maneira de fazer isso. Isso é particularmente verdadeiro para o " -"acesso de baixo nível ao próprio tempo de execução do CPython, uma vez que " -"algumas operações (como liberar o Bloqueio Global do Interpretador) são " -"simplesmente inválidas quando o interpretador está executando o código, " -"mesmo se um módulo como ``ctypes`` ou ``cffi`` é usado para obter acesso às " -"interfaces API C relevantes." - -#: ../source/guides/packaging-binary-extensions.rst:213 -msgid "" -"For cases where the extension module is manipulating the underlying " -"operating system or hardware (rather than the CPython runtime), it may " -"sometimes be better to just write an ordinary C library (or a library in " -"another systems programming language like C++ or Rust that can export a C " -"compatible ABI), and then use one of the wrapping techniques described above " -"to make the interface available as an importable Python module." -msgstr "" -"Para casos em que o módulo de extensão está manipulando o sistema " -"operacional ou hardware subjacente (em vez do tempo de execução do CPython), " -"às vezes pode ser melhor apenas escrever uma biblioteca C comum (ou uma " -"biblioteca em outra linguagem de programação de sistemas como C++ ou Rust " -"que pode exportar uma ABI compatível com C) e, em seguida, usar uma das " -"técnicas de agrupamento descritas acima para tornar a interface disponível " -"como um módulo Python importável." - -#: ../source/guides/packaging-binary-extensions.rst:222 -msgid "Implementing binary extensions" -msgstr "Implementando extensões binárias" - -#: ../source/guides/packaging-binary-extensions.rst:224 -msgid "" -"The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in " -"C `_." -msgstr "" -"O guia `Estendendo e Incorporando `_ do CPython inclui uma introdução a escrever um `módulo de extensão " -"personalizado no C `_." - -#: ../source/guides/packaging-binary-extensions.rst:241 -msgid "Building binary extensions" -msgstr "Construindo extensões binárias" - -#: ../source/guides/packaging-binary-extensions.rst:244 -msgid "Building extensions for multiple platforms" -msgstr "Construindo extensões para várias plataformas" - -#: ../source/guides/packaging-binary-extensions.rst:246 -msgid "" -"If you plan to distribute your extension, you should provide :term:`wheels " -"` for all the platforms you intend to support. For most extensions, " -"this is at least one package per Python version times the number of OS and " -"architectures you support. These are usually built on continuous " -"integration (CI) systems. There are tools to help you build highly " -"redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:" -"`multibuild`." -msgstr "" -"Se você planeja distribuir sua extensão, você deve fornecer :term:`wheels " -"` para todas as plataformas que pretende oferecer suporte. Para a " -"maioria das extensões, é pelo menos um pacote por versão Python vezes o " -"número de sistemas opcionais e arquiteturas aos quais você oferece suporte. " -"Geralmente são construídos em sistemas de integração contínua (CI). Existem " -"ferramentas para lhe ajudar a construir binários altamente redistribuíveis " -"de CI; estes incluem :ref:`cibuildwheel` e :ref:`multibuild`." - -#: ../source/guides/packaging-binary-extensions.rst:256 -msgid "Binary extensions for Windows" -msgstr "Extensões binárias para Windows" - -#: ../source/guides/packaging-binary-extensions.rst:258 -msgid "" -"Before it is possible to build a binary extension, it is necessary to ensure " -"that you have a suitable compiler available. On Windows, Visual C is used to " -"build the official CPython interpreter, and should be used to build " -"compatible binary extensions." -msgstr "" -"Antes que seja possível construir uma extensão binária, é necessário " -"garantir que você tenha um compilador adequado disponível. No Windows, o " -"Visual C é usado para construir o interpretador oficial do CPython e deve " -"ser usado para construir extensões binárias compatíveis." - -#: ../source/guides/packaging-binary-extensions.rst:263 -msgid "" -"Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio " -"2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older " -"versions of Visual Studio are no longer easily available from Microsoft, so " -"for versions of Python prior to 3.5, the compilers must be obtained " -"differently if you do not already have a copy of the relevant version of " -"Visual Studio." -msgstr "" -"Python 2.7 usou Visual Studio 2008, Python 3.3 e 3.4 usou Visual Studio 2010 " -"e Python 3.5+ usa Visual Studio 2015 ou posterior. Infelizmente, as versões " -"mais antigas do Visual Studio não estão mais facilmente disponíveis na " -"Microsoft, portanto, para versões do Python anteriores a 3.5, os " -"compiladores devem ser obtidos de forma diferente se você ainda não tiver " -"uma cópia da versão relevante do Visual Studio." - -#: ../source/guides/packaging-binary-extensions.rst:269 -msgid "" -"To set up a build environment for binary extensions, the steps are as " -"follows:" -msgstr "" -"Para configurar um ambiente de construção para extensões binárias, as etapas " -"são as seguintes:" - -#: ../source/guides/packaging-binary-extensions.rst:271 -msgid "For Python 2.7" -msgstr "Para Python 2.7" - -#: ../source/guides/packaging-binary-extensions.rst:273 -msgid "" -"Install \"Visual C++ Compiler Package for Python 2.7\", which is available " -"from `Microsoft's website `__." -msgstr "" -"Instale \"Visual C++ Compiler Package for Python 2.7\", que está disponível " -"no `site da Microsoft `__." - -#: ../source/guides/packaging-binary-extensions.rst:276 -msgid "" -"Use (a recent version of) setuptools in your setup.py (pip will do this for " -"you, in any case)." -msgstr "" -"Use (uma versão recente de) setuptools em seu setup.py (pip fará isso por " -"você, em qualquer caso)." - -#: ../source/guides/packaging-binary-extensions.rst:278 -#: ../source/guides/packaging-binary-extensions.rst:288 -#: ../source/guides/packaging-binary-extensions.rst:295 -msgid "Done." -msgstr "Pronto." - -#: ../source/guides/packaging-binary-extensions.rst:280 -msgid "For Python 3.4" -msgstr "Para Python 3.4" - -#: ../source/guides/packaging-binary-extensions.rst:282 -msgid "" -"Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is " -"available from `Microsoft's website `__." -msgstr "" -"Instale \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), que está " -"disponível no `site da Microsoft `__." - -#: ../source/guides/packaging-binary-extensions.rst:285 -msgid "" -"Work from an SDK command prompt (with the environment variables set, and the " -"SDK on PATH)." -msgstr "" -"Trabalhe em um prompt de comando do SDK (com as variáveis de ambiente " -"definidas e o SDK no PATH)." - -#: ../source/guides/packaging-binary-extensions.rst:287 -msgid "Set DISTUTILS_USE_SDK=1" -msgstr "Defina DISTUTILS_USE_SDK=1" - -#: ../source/guides/packaging-binary-extensions.rst:290 -msgid "For Python 3.5" -msgstr "Para Python 3.5" - -#: ../source/guides/packaging-binary-extensions.rst:292 -msgid "" -"Install `Visual Studio 2015 Community Edition `__ (or any later version, " -"when these are released)." -msgstr "" -"Instale `Visual Studio 2015 Community Edition `__ (ou qualquer versão " -"posterior, quando estas tiverem sido lançadas)." - -#: ../source/guides/packaging-binary-extensions.rst:297 -msgid "" -"Note that from Python 3.5 onwards, Visual Studio works in a backward " -"compatible way, which means that any future version of Visual Studio will be " -"able to build Python extensions for all Python versions from 3.5 onwards." -msgstr "" -"Observe que a partir do Python 3.5 em diante, o Visual Studio funciona de " -"maneira compatível com versões anteriores, o que significa que qualquer " -"versão futura do Visual Studio será capaz de construir extensões Python para " -"todas as versões Python de 3.5 em diante." - -#: ../source/guides/packaging-binary-extensions.rst:301 -msgid "" -"Building with the recommended compiler on Windows ensures that a compatible " -"C library is used throughout the Python process." -msgstr "" -"Construir com o compilador recomendado no Windows garante que uma biblioteca " -"C compatível seja usada em todo o processo do Python." - -#: ../source/guides/packaging-binary-extensions.rst:305 -msgid "Binary extensions for Linux" -msgstr "Extensões binárias para Linux" - -#: ../source/guides/packaging-binary-extensions.rst:307 -msgid "" -"Linux binaries must use a sufficiently old glibc to be compatible with older " -"distributions. The `manylinux `_ Docker " -"images provide a build environment with a glibc old enough to support most " -"current Linux distributions on common architectures." -msgstr "" -"Os binários do Linux devem usar uma glibc suficientemente antiga para serem " -"compatíveis com distribuições mais antigas. As imagens Docker do `manylinux " -"`_ fornecem um ambiente de construção com " -"uma glibc antiga o suficiente para oferecer suporte à maioria das " -"distribuições Linux atuais em arquiteturas comuns." - -#: ../source/guides/packaging-binary-extensions.rst:313 -msgid "Binary extensions for macOS" -msgstr "Extensões binárias para macOS" - -#: ../source/guides/packaging-binary-extensions.rst:315 -msgid "" -"Binary compatibility on macOS is determined by the target minimum deployment " -"system, e.g. *10.9*, which is often specified with the " -"``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries " -"on macOS. When building with setuptools / distutils, the deployment target " -"is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For " -"common deployment targets for macOS Python distributions, see the `MacPython " -"Spinning Wheels wiki `_." -msgstr "" -"A compatibilidade binária no macOS é determinada pelo sistema mínimo alvo de " -"implantação, por exemplo, *10.9*, que geralmente é especificado com a " -"variável de ambiente ``MACOSX_DEPLOYMENT_TARGET`` ao construir binários no " -"macOS. Ao construir com setuptools / distutils, o alvo de implantação é " -"especificado com o sinalizador ``--plat-name``, por exemplo, ``macosx-10.9-" -"x86_64``. Para alvos de implantação comuns para distribuições do Python para " -"macOS, consulte a `Spinning Wheels na wiki do MacPython `_." - -#: ../source/guides/packaging-binary-extensions.rst:325 -msgid "Publishing binary extensions" -msgstr "Publicando extensões binárias" - -#: ../source/guides/packaging-binary-extensions.rst:327 -msgid "" -"For interim guidance on this topic, see the discussion in `this issue " -"`_." -msgstr "" -"Para obter orientações provisórias sobre este tópico, consulte a discussão " -"`neste relatório de problema `_." - -#: ../source/guides/packaging-binary-extensions.rst:343 -msgid "Additional resources" -msgstr "Recursos adicionais" - -#: ../source/guides/packaging-binary-extensions.rst:345 -msgid "" -"Cross-platform development and distribution of extension modules is a " -"complex topic, so this guide focuses primarily on providing pointers to " -"various tools that automate dealing with the underlying technical " -"challenges. The additional resources in this section are instead intended " -"for developers looking to understand more about the underlying binary " -"interfaces that those systems rely on at runtime." -msgstr "" -"O desenvolvimento e distribuição multiplataforma de módulos de extensão é um " -"tópico complexo, portanto, este guia se concentra principalmente em fornecer " -"indicadores para várias ferramentas que automatizam o tratamento dos " -"desafios técnicos subjacentes. Os recursos adicionais nesta seção são " -"destinados a desenvolvedores que procuram entender mais sobre as interfaces " -"binárias subjacentes das quais esses sistemas dependem em tempo de execução." - -#: ../source/guides/packaging-binary-extensions.rst:352 -msgid "Cross-platform wheel generation with scikit-build" -msgstr "Geração de wheel multiplataforma com scikit-build" - -#: ../source/guides/packaging-binary-extensions.rst:354 -msgid "" -"The `scikit-build `_ package " -"helps abstract cross-platform build operations and provides additional " -"capabilities when creating binary extension packages. Additional " -"documentation is also available on the `C runtime, compiler, and build " -"system generator `_ for Python binary extension modules." -msgstr "" -"O pacote `scikit-build `_ " -"ajuda a abstrair as operações de construção multiplataforma e fornece " -"recursos adicionais ao criar pacotes de extensões binárias. Documentação " -"adicional também está disponível no `tempo de execução C, compilador e " -"gerador de sistema de construção `_ para módulos Python de extensão binária." - -#: ../source/guides/packaging-binary-extensions.rst:362 -msgid "Introduction to C/C++ extension modules" -msgstr "Introdução a módulos de extensão C/C++" - -#: ../source/guides/packaging-binary-extensions.rst:364 -msgid "" -"For a more in depth explanation of how extension modules are used by CPython " -"on a Debian system, see the following articles:" -msgstr "" -"Para uma explicação mais detalhada de como os módulos de extensão são usados " -"pelo CPython em um sistema Debian, consulte os seguintes artigos (todos em " -"inglês):" - -#: ../source/guides/packaging-binary-extensions.rst:367 -msgid "" -"`What are (c)python extension modules? `_" -msgstr "" -"`O que são módulos de extensão (c)python? `_" - -#: ../source/guides/packaging-binary-extensions.rst:368 -msgid "`Releasing the gil `_" -msgstr "`Liberando o gil `_" - -#: ../source/guides/packaging-binary-extensions.rst:369 -msgid "" -"`Writing cpython extension modules using C++ `_" -msgstr "" -"`Escrevendo módulos de extensão cpython usando C++ `_" - -#: ../source/guides/packaging-namespace-packages.rst:3 -msgid "Packaging namespace packages" -msgstr "Empacotando pacotes de espaço de nomes" - -#: ../source/guides/packaging-namespace-packages.rst:5 -msgid "" -"Namespace packages allow you to split the sub-packages and modules within a " -"single :term:`package ` across multiple, separate :term:" -"`distribution packages ` (referred to as " -"**distributions** in this document to avoid ambiguity). For example, if you " -"have the following package structure:" -msgstr "" -"Os pacotes de espaço de nomes permitem que você divida os subpacotes e " -"módulos dentro de um único :term:`pacote ` em vários " -":term:`pacotes de distribuição ` (referidos como " -"**distribuições** em este documento para evitar ambiguidade). Por exemplo, " -"se você tiver a seguinte estrutura de pacote:" - -#: ../source/guides/packaging-namespace-packages.rst:24 -msgid "And you use this package in your code like so::" -msgstr "E você usa este pacote em seu código assim::" - -#: ../source/guides/packaging-namespace-packages.rst:29 -msgid "Then you can break these sub-packages into two separate distributions:" -msgstr "" -"Então você pode quebrar esses subpacotes em duas distribuições separadas:" - -#: ../source/guides/packaging-namespace-packages.rst:46 -msgid "Each sub-package can now be separately installed, used, and versioned." -msgstr "" -"Cada subpacote pode agora ser instalado, usado e versionado separadamente." - -#: ../source/guides/packaging-namespace-packages.rst:48 -msgid "" -"Namespace packages can be useful for a large collection of loosely-related " -"packages (such as a large corpus of client libraries for multiple products " -"from a single company). However, namespace packages come with several " -"caveats and are not appropriate in all cases. A simple alternative is to use " -"a prefix on all of your distributions such as ``import " -"mynamespace_subpackage_a`` (you could even use ``import " -"mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." -msgstr "" -"Os pacotes de espaço de nomes podem ser úteis para uma grande coleção de " -"pacotes vagamente relacionados (como um grande corpo de bibliotecas de " -"cliente para vários produtos de uma única empresa). No entanto, os pacotes " -"de espaço de nomes vêm com várias ressalvas e não são apropriados em todos " -"os casos. Uma alternativa simples é usar um prefixo em todas as suas " -"distribuições, como ``import mynamespace_subpackage_a`` (você pode até usar " -"``import mynamespace_subpackage_a as subpackage_a`` para manter o objeto de " -"importação curto)." - -#: ../source/guides/packaging-namespace-packages.rst:58 -msgid "Creating a namespace package" -msgstr "Criando um pacote de espaço de nomes" - -#: ../source/guides/packaging-namespace-packages.rst:60 -msgid "" -"There are currently three different approaches to creating namespace " -"packages:" -msgstr "" -"Atualmente, existem três abordagens diferentes para a criação de pacotes de " -"espaço de nomes:" - -#: ../source/guides/packaging-namespace-packages.rst:62 -msgid "" -"Use `native namespace packages`_. This type of namespace package is defined " -"in :pep:`420` and is available in Python 3.3 and later. This is recommended " -"if packages in your namespace only ever need to support Python 3 and " -"installation via ``pip``." -msgstr "" -"Usar `pacotes de espaço de nomes nativos`_. Este tipo de pacote de espaço de " -"nomes é definido na :pep:`420` e está disponível em Python 3.3 e posterior. " -"Isso é recomendado se os pacotes em seu espaço de nomes precisarem apenas " -"oferecer suporte ao Python 3 e à instalação via ``pip``." - -#: ../source/guides/packaging-namespace-packages.rst:66 -msgid "" -"Use `pkgutil-style namespace packages`_. This is recommended for new " -"packages that need to support Python 2 and 3 and installation via both " -"``pip`` and ``python setup.py install``." -msgstr "" -"Usar `pacotes de espaço de nomes no estilo pkgutil`_. Isso é recomendado " -"para novos pacotes que precisam oferecer suporte a Python 2 e 3 e à " -"instalação via ``pip`` e ``python setup.py install``." - -#: ../source/guides/packaging-namespace-packages.rst:69 -msgid "" -"Use `pkg_resources-style namespace packages`_. This method is recommended if " -"you need compatibility with packages already using this method or if your " -"package needs to be zip-safe." -msgstr "" -"Usar `pacotes de espaço de nomes no estilo pkg_resources`_. Este método é " -"recomendado se você precisa de compatibilidade com pacotes que já usam este " -"método ou se seu pacote precisa ser seguro para uso de zip." - -#: ../source/guides/packaging-namespace-packages.rst:73 -msgid "" -"While native namespace packages and pkgutil-style namespace packages are " -"largely compatible, pkg_resources-style namespace packages are not " -"compatible with the other methods. It's inadvisable to use different methods " -"in different distributions that provide packages to the same namespace." -msgstr "" -"Embora os pacotes de espaço de nomes nativos e pacotes de espaço de nomes no " -"estilo pkgutil sejam amplamente compatíveis, os pacotes de espaço de nomes " -"no estilo pkg_resources não são compatíveis com os outros métodos. Não é " -"aconselhável usar métodos diferentes em distribuições diferentes que " -"fornecem pacotes para o mesmo espaço de nomes." - -#: ../source/guides/packaging-namespace-packages.rst:80 -msgid "Native namespace packages" -msgstr "Pacotes se espaço de nomes nativos" - -#: ../source/guides/packaging-namespace-packages.rst:82 -msgid "" -"Python 3.3 added **implicit** namespace packages from :pep:`420`. All that " -"is required to create a native namespace package is that you just omit :file:" -"`__init__.py` from the namespace package directory. An example file " -"structure:" -msgstr "" -"Python 3.3 adicionou pacotes de espaço de nomes **implícitos** a partir da :" -"pep:`420`. Tudo o que é necessário para criar um pacote de espaço de nomes " -"nativo é omitir :file:`__init__.py` do diretório do pacote de espaço de " -"nomes. Um exemplo de estrutura de arquivo:" - -#: ../source/guides/packaging-namespace-packages.rst:97 -msgid "" -"It is extremely important that every distribution that uses the namespace " -"package omits the :file:`__init__.py` or uses a pkgutil-style :file:" -"`__init__.py`. If any distribution does not, it will cause the namespace " -"logic to fail and the other sub-packages will not be importable." -msgstr "" -"É extremamente importante que toda distribuição que usa o pacote de espaço " -"de nomes omita o :file:`__init__.py` ou use um :file:`__init__.py` no estilo " -"pkgutil. Se alguma distribuição não o fizer, isso fará com que a lógica do " -"espaço de nomes falhe e os outros subpacotes não serão importáveis." - -#: ../source/guides/packaging-namespace-packages.rst:102 -msgid "" -"Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:" -"`setuptools.find_packages` won't find the sub-package. You must use :func:" -"`setuptools.find_namespace_packages` instead or explicitly list all packages " -"in your :file:`setup.py`. For example:" -msgstr "" -"Porque ``mynamespace`` não contém um :file:`__init__.py`, :func:`setuptools." -"find_packages` não encontrará o subpacote. Você deve usar :func:`setuptools." -"find_namespace_packages` ou listar explicitamente todos os pacotes em seu :" -"file:`setup.py`. Por exemplo:" - -#: ../source/guides/packaging-namespace-packages.rst:117 -msgid "" -"A complete working example of two native namespace packages can be found in " -"the `native namespace package example project`_." -msgstr "" -"Um exemplo de trabalho completo de dois pacotes de espaço de nomes nativos " -"pode ser encontrado no `projeto exemplo de pacote de espaço de nomes " -"nativo`_." - -#: ../source/guides/packaging-namespace-packages.rst:123 -msgid "" -"Because native and pkgutil-style namespace packages are largely compatible, " -"you can use native namespace packages in the distributions that only support " -"Python 3 and pkgutil-style namespace packages in the distributions that need " -"to support Python 2 and 3." -msgstr "" -"Como os pacotes de espaço de nomes nativos e no estilo pkgutil são " -"amplamente compatíveis, você pode usar pacotes de espaço de nomes nativos " -"nas distribuições que oferecem suporte apenas a Python 3 e pacotes de espaço " -"de nomes no estilo pkgutil nas distribuições que precisam oferecer suporte a " -"Python 2 e 3." - -#: ../source/guides/packaging-namespace-packages.rst:129 -msgid "pkgutil-style namespace packages" -msgstr "Pacotes de espaço de nomes no estilo pkgutil" - -#: ../source/guides/packaging-namespace-packages.rst:131 -msgid "" -"Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. " -"This can be used to declare namespace packages that need to be compatible " -"with both Python 2.3+ and Python 3. This is the recommended approach for the " -"highest level of compatibility." -msgstr "" -"Python 2.3 introduziu o módulo `pkgutil`_ e a função `extend_path`_. Isso " -"pode ser usado para declarar pacotes de espaço de nomes que precisam ser " -"compatíveis com Python 2.3+ e Python 3. Esta é a abordagem recomendada para " -"o nível mais alto de compatibilidade." - -#: ../source/guides/packaging-namespace-packages.rst:136 -msgid "" -"To create a pkgutil-style namespace package, you need to provide an :file:" -"`__init__.py` file for the namespace package:" -msgstr "" -"Para criar um pacote de espaço de nomes no estilo pkgutil, você precisa " -"fornecer um arquivo :file:`__init__.py` para o pacote de espaço de nomes:" - -#: ../source/guides/packaging-namespace-packages.rst:148 -#: ../source/guides/packaging-namespace-packages.rst:194 -msgid "" -"The :file:`__init__.py` file for the namespace package needs to contain " -"**only** the following:" -msgstr "" -"O arquivo :file:`__init__.py` para o pacote de espaço de nomes precisa " -"conter **apenas** o seguinte:" - -#: ../source/guides/packaging-namespace-packages.rst:155 -#: ../source/guides/packaging-namespace-packages.rst:201 -msgid "" -"**Every** distribution that uses the namespace package must include an " -"identical :file:`__init__.py`. If any distribution does not, it will cause " -"the namespace logic to fail and the other sub-packages will not be " -"importable. Any additional code in :file:`__init__.py` will be inaccessible." -msgstr "" -"**Cada** distribuição que usa o pacote de espaço de nomes deve incluir um :" -"file:`__init__.py` idêntico. Se alguma distribuição não o fizer, isso fará " -"com que a lógica do espaço de nomes falhe e os outros subpacotes não serão " -"importáveis. Qualquer código adicional no :file:`__init__.py` ficará " -"inacessível." - -#: ../source/guides/packaging-namespace-packages.rst:160 -msgid "" -"A complete working example of two pkgutil-style namespace packages can be " -"found in the `pkgutil namespace example project`_." -msgstr "" -"Um exemplo completamente funcional de dois pacotes de espaço de nomes no " -"estilo pkgutil pode ser encontrado no `projeto exemplo de espaço de nomes de " -"pkgutil`_." - -#: ../source/guides/packaging-namespace-packages.rst:171 -msgid "pkg_resources-style namespace packages" -msgstr "Pacotes de espaço de nomes no estilo pkg_resources" - -#: ../source/guides/packaging-namespace-packages.rst:173 -msgid "" -"`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and " -"the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together " -"these can be used to declare namespace packages. While this approach is no " -"longer recommended, it is widely present in most existing namespace " -"packages. If you are creating a new distribution within an existing " -"namespace package that uses this method then it's recommended to continue " -"using this as the different methods are not cross-compatible and it's not " -"advisable to try to migrate an existing package." -msgstr "" -"`Setuptools`_ fornece a função `pkg_resources.declare_namespace`_ e o " -"argumento ``namespace_packages`` para :func:`~setuptools.setup`. Juntos, " -"eles podem ser usados para declarar pacotes de espaço de nomes. Embora essa " -"abordagem não seja mais recomendada, ela está amplamente presente na maioria " -"dos pacotes de espaço de nomes existentes. Se você estiver criando uma nova " -"distribuição dentro de um pacote de espaço de nomes existente que usa esse " -"método, é recomendável continuar usando-o, pois os diferentes métodos não " -"são compatíveis entre si e não é aconselhável tentar migrar um pacote " -"existente." - -#: ../source/guides/packaging-namespace-packages.rst:182 -msgid "" -"To create a pkg_resources-style namespace package, you need to provide an :" -"file:`__init__.py` file for the namespace package:" -msgstr "" -"Para criar um pacote de espaço de nomes no estilo pkg_resources, você " -"precisa fornecer um arquivo :file:`__init __. Py` para o pacote de espaço de " -"nomes:" - -#: ../source/guides/packaging-namespace-packages.rst:206 -msgid "" -"Some older recommendations advise the following in the namespace package :" -"file:`__init__.py`:" -msgstr "" -"Algumas recomendações mais antigas aconselham o seguinte no :file:`__init__." -"py` de pacotes de espaço de nomes:" - -#: ../source/guides/packaging-namespace-packages.rst:216 -msgid "" -"The idea behind this was that in the rare case that setuptools isn't " -"available packages would fall-back to the pkgutil-style packages. This isn't " -"advisable because pkgutil and pkg_resources-style namespace packages are not " -"cross-compatible. If the presence of setuptools is a concern then the " -"package should just explicitly depend on setuptools via ``install_requires``." -msgstr "" -"A ideia por trás disso era que, no caso raro de setuptools não estar " -"disponível, os pacotes recorreriam aos pacotes no estilo pkgutil. Isso não é " -"aconselhável porque os pacotes de espaço de nomes estilo pkgutil e " -"pkg_resources não são compatíveis entre si. Se a presença de setuptools é " -"uma preocupação, então o pacote deve depender explicitamente de setuptools " -"via ``install_requires``." - -#: ../source/guides/packaging-namespace-packages.rst:223 -msgid "" -"Finally, every distribution must provide the ``namespace_packages`` argument " -"to :func:`~setuptools.setup` in :file:`setup.py`. For example:" -msgstr "" -"Finalmente, cada distribuição deve fornecer o argumento " -"``namespace_packages`` para :func:`~setuptools.setup` no :file:`setup.py`. " -"Por exemplo:" - -#: ../source/guides/packaging-namespace-packages.rst:237 -msgid "" -"A complete working example of two pkg_resources-style namespace packages can " -"be found in the `pkg_resources namespace example project`_." -msgstr "" -"Um exemplo de completamente funcional de dois pacotes de espaço de nomes no " -"estilo pkg_resources pode ser encontrado no `projeto exemplo de espaço de " -"nomes de pkg_resources`_." - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 -msgid "" -"Publishing package distribution releases using GitHub Actions CI/CD workflows" -msgstr "" -"Publicando versões de distribuição de pacotes usando fluxos de trabalho de " -"CI/CD do GitHub Actions" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 -msgid "" -"`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an " -"event occurs on the GitHub platform. One popular choice is having a workflow " -"that's triggered by a ``push`` event. This guide shows you how to publish a " -"Python distribution whenever a tagged commit is pushed. It will use the " -"`pypa/gh-action-pypi-publish GitHub Action`_." -msgstr "" -"O `CI/CD do GitHub Actions`_ permite que você execute uma série de comandos " -"sempre que ocorrer um evento na plataforma GitHub. Uma escolha popular é ter " -"um fluxo de trabalho que é disparado por um evento ``push``. Este guia " -"mostra como publicar uma distribuição Python sempre que um commit marcado é " -"enviado. Ele usará o `GitHub Action pypa/gh-action-pypi-publish`_." - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 -msgid "" -"This guide *assumes* that you already have a project that you know how to " -"build distributions for and *it lives on GitHub*." -msgstr "" -"Este guia *presume* que você já tem um projeto para o qual sabe como " -"construir distribuições e *ele reside no GitHub*." - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 -msgid "Saving credentials on GitHub" -msgstr "Salvando credenciais no GitHub" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 -msgid "" -"In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, " -"meaning that we'll have two separate sets of credentials. And we'll need to " -"save them in the GitHub repository settings." -msgstr "" -"Neste guia, demonstraremos o envio para o PyPI e TestPyPI, o que significa " -"que teremos dois conjuntos separados de credenciais. E precisaremos salvá-" -"los nas configurações do repositório do GitHub." - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 -msgid "Let's begin! 🚀" -msgstr "Vamos começar! 🚀" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 -msgid "" -"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " -"token`_. If you have the project on PyPI already, limit the token scope to " -"just that project. You can call it something like ``GitHub Actions CI/CD — " -"project-org/project-repo`` in order for it to be easily distinguishable in " -"the token list. **Don't close the page just yet — you won't see that token " -"again.**" -msgstr "" -"Vá para https://pypi.org/manage/account/#api-tokens e crie um novo `token de " -"API `_. Se você já tem o projeto no PyPI, limite o escopo do " -"token apenas a esse projeto. Você pode chamá-lo de algo como ``GitHub " -"Actions CI/CD — project-org/project-repo`` para que seja facilmente " -"distinguível na lista de tokens. **Não feche a página ainda -- você não verá " -"esse token novamente.**" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 -msgid "" -"In a separate browser tab or window, go to the ``Settings`` tab of your " -"target repository and then click on `Secrets`_ in the left sidebar." -msgstr "" -"Em uma guia ou janela separada do navegador, vá para a aba ``Configurações`` " -"do seu repositório de destino e clique em `Secrets`_ na barra lateral " -"esquerda." - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 -msgid "" -"Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from " -"the first step." -msgstr "" -"Crie um novo segredo chamado ` PYPI_API_TOKEN`` e copie e cole o token da " -"primeira etapa." - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 -msgid "" -"Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the " -"steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." -msgstr "" -"Agora, vá para https://test.pypi.org/manage/account/#api-tokens e repita as " -"etapas. Salve esse token de TestePyPI no GitHub como ``TEST_PYPI_API_TOKEN``." - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 -msgid "" -"If you don't have a TestPyPI account, you'll need to create it. It's not the " -"same as a regular PyPI account." -msgstr "" -"Se você não tiver uma conta TestPyPI, precisará criá-la. Não é o mesmo que " -"uma conta do PyPI comum." - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 -msgid "Creating a workflow definition" -msgstr "Criando uma definição de fluxo de trabalho" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 -msgid "" -"GitHub CI/CD workflows are declared in YAML files stored in the ``.github/" -"workflows/`` directory of your repository." -msgstr "" -"Os fluxos de trabalho de CI/CD do GitHub são declarados em arquivos YAML " -"armazenados no diretório ``.github/workflows/`` do seu repositório." - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 -msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." -msgstr "" -"Vamos criar um arquivo chamado ``.github/workflows/publish-to-test-pypi." -"yml``." - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 -msgid "" -"Start it with a meaningful name and define the event that should make GitHub " -"run this workflow:" -msgstr "" -"Comece com um nome significativo e defina o evento que deve fazer o GitHub " -"executar este fluxo de trabalho:" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 -msgid "Defining a workflow job environment" -msgstr "Definindo um ambiente de tarefa do fluxo de trabalho" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 -msgid "" -"Now, let's add initial setup for our job. It's a process that will execute " -"commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" -msgstr "" -"Agora, vamos adicionar a configuração inicial para nosso trabalho. É um " -"processo que executará comandos que definiremos mais tarde. Neste guia, " -"usaremos o Ubuntu 18.04:" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 -msgid "Checking out the project and building distributions" -msgstr "Fazendo checkout do projeto e construindo as distribuições" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 -msgid "Then, add the following under the ``build-n-publish`` section:" -msgstr "Então, adicione o seguinte sob a seção ``build-n-publish``:" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 -msgid "" -"This will download your repository into the CI runner and then install and " -"activate Python 3.7." -msgstr "" -"Isso fará o download do seu repositório no executor de CI e, em seguida, " -"instalará e ativará o Python 3.7." - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 -msgid "" -"And now we can build dists from source. In this example, we'll use ``build`` " -"package, assuming that your project has a ``pyproject.toml`` properly set up " -"(see :pep:`517`/:pep:`518`)." -msgstr "" -"E agora podemos construir dists a partir da fonte. Neste exemplo, usaremos o " -"pacote ``build``, presumindo que seu projeto tem um ``pyproject.toml`` " -"configurado corretamente (veja :pep:`517` /:pep:`518`)." - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 -msgid "" -"You can use any other method for building distributions as long as it " -"produces ready-to-upload artifacts saved into the ``dist/`` folder." -msgstr "" -"Você pode usar qualquer outro método para construir distribuições, desde que " -"produza artefatos prontos para enviar, salvos na pasta ``dist/``." - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 -msgid "So add this to the steps list:" -msgstr "Então, adicione isso à lista de etapas:" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 -msgid "Publishing the distribution to PyPI and TestPyPI" -msgstr "Publicando a distribuição para PyPI e TestPyPI" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 -msgid "Finally, add the following steps at the end:" -msgstr "Finalmente, adicione as seguintes etapas ao final:" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 -msgid "" -"These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the " -"first one uploads contents of the ``dist/`` folder into TestPyPI " -"unconditionally and the second does that to PyPI, but only if the current " -"commit is tagged." -msgstr "" -"Essas duas etapas usam a GitHub Action `pypa/gh-action-pypi-publish`_: a " -"primeira carrega o conteúdo da pasta ``dist /`` para TestPyPI " -"incondicionalmente e a segunda faz isso para PyPI, mas apenas se o commit " -"atual estiver marcado." - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 -msgid "That's all, folks!" -msgstr "Isso é tudo, pessoal!" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 -msgid "" -"Now, whenever you push a tagged commit to your Git repository remote on " -"GitHub, this workflow will publish it to PyPI. And it'll publish any push to " -"TestPyPI which is useful for providing test builds to your alpha users as " -"well as making sure that your release pipeline remains healthy!" -msgstr "" -"Agora, sempre que você fizer um push de um commit com tag para seu " -"repositório Git remoto no GitHub, este fluxo de trabalho irá publicá-lo no " -"PyPI. E publicará qualquer push para TestPyPI que seja útil para fornecer " -"construções de teste para seus usuários alfa, bem como garantir que sua " -"versão pipeline permaneça saudável!" - -#: ../source/guides/single-sourcing-package-version.rst:5 -msgid "Single-sourcing the package version" -msgstr "Mantendo uma única fonte da versão do pacote" - -#: ../source/guides/single-sourcing-package-version.rst:8 -msgid "" -"There are many techniques to maintain a single source of truth for the " -"version number of your project:" -msgstr "" -"Existem muitas técnicas para manter uma única fonte para o número de versão " -"do seu projeto:" - -#: ../source/guides/single-sourcing-package-version.rst:11 -msgid "" -"Read the file in :file:`setup.py` and get the version. Example (from `pip " -"setup.py `_)::" -msgstr "" -"Leia o arquivo em :file:`setup.py` e obtenha a versão. Exemplo (de `pip " -"setup.py `_)::" - -#: ../source/guides/single-sourcing-package-version.rst:38 -msgid "" -"As of the release of setuptools 46.4.0, one can accomplish the same thing by " -"instead placing the following in the project's ``setup.cfg`` file (replacing " -"\"package\" with the import name of the package):" -msgstr "" -"A partir do lançamento do setuptools 46.4.0, pode-se realizar a mesma coisa " -"colocando o seguinte no arquivo ``setup.cfg`` do projeto (substituindo " -"\"pacote\" pelo nome de importação do pacote):" - -#: ../source/guides/single-sourcing-package-version.rst:47 -msgid "" -"Earlier versions of setuptools implemented the ``attr:`` directive by " -"importing the module, but setuptools 46.4.0 added rudimentary AST analysis " -"so that ``attr:`` can function without having to import any of the package's " -"dependencies." -msgstr "" -"Versões anteriores de setuptools implementavam a diretiva ``attr:`` " -"importando o módulo, mas setuptools 46.4.0 adicionou uma análise de AST " -"rudimentar para que ``attr:`` possa funcionar sem ter que importar nenhuma " -"das dependências do pacote." - -#: ../source/guides/single-sourcing-package-version.rst:52 -msgid "" -"Also, please be aware that declarative config indicators, including the " -"``attr:`` directive, are not supported in parameters to ``setup.py``." -msgstr "" -"Além disso, esteja ciente de que os indicadores de configuração " -"declarativos, incluindo a diretiva ``attr: ``, não são suportados em " -"parâmetros para ``setup.py``." - -#: ../source/guides/single-sourcing-package-version.rst:55 -msgid "" -"Use an external build tool that either manages updating both locations, or " -"offers an API that both locations can use." -msgstr "" -"Use uma ferramenta de construção externa que gerencia a atualização de ambos " -"os locais ou oferece uma API que ambos os locais podem usar." - -#: ../source/guides/single-sourcing-package-version.rst:58 -msgid "" -"Few tools you could use, in no particular order, and not necessarily " -"complete: `bump2version `_, `changes " -"`_, `commitizen `_, `zest.releaser `_." -msgstr "" -"Poucas ferramentas que você poderia usar, sem nenhuma ordem específica, e " -"não necessariamente completas: `bump2version `_, `changes `_, `commitizen " -"`_, `zest.releaser `_." - -#: ../source/guides/single-sourcing-package-version.rst:65 -msgid "" -"Set the value to a ``__version__`` global variable in a dedicated module in " -"your project (e.g. :file:`version.py`), then have :file:`setup.py` read and " -"``exec`` the value into a variable." -msgstr "" -"Defina o valor para uma variável global ``__version__`` em um módulo " -"dedicado em seu projeto (por exemplo, :file:`version.py`), então faça com " -"que :file:`setup.py` leia e execute (``exec``) o valor em uma variável." - -#: ../source/guides/single-sourcing-package-version.rst:76 -msgid "" -"Example using this technique: `warehouse `_." -msgstr "" -"Exemplo usando esta técnica: `warehouse `_." - -#: ../source/guides/single-sourcing-package-version.rst:78 -msgid "" -"Place the value in a simple ``VERSION`` text file and have both :file:`setup." -"py` and the project code read it." -msgstr "" -"Coloque o valor em um arquivo de texto simples ``VERSION`` e tenha ambos :" -"file:`setup.py` e o código do projeto lidos." - -#: ../source/guides/single-sourcing-package-version.rst:86 -msgid "" -"An advantage with this technique is that it's not specific to Python. Any " -"tool can read the version." -msgstr "" -"Uma vantagem dessa técnica é que ela não é específica do Python. Qualquer " -"ferramenta pode ler a versão." - -#: ../source/guides/single-sourcing-package-version.rst:91 -msgid "" -"With this approach you must make sure that the ``VERSION`` file is included " -"in all your source and binary distributions (e.g. add ``include VERSION`` to " -"your :file:`MANIFEST.in`)." -msgstr "" -"Com esta abordagem, você deve se certificar de que o arquivo ``VERSION`` " -"está incluído em todas as suas distribuições de fonte e binárias (por " -"exemplo, adicione ``include VERSION`` ao seu :file:`MANIFEST.in`)." - -#: ../source/guides/single-sourcing-package-version.rst:95 -msgid "" -"Set the value in :file:`setup.py`, and have the project code use the " -"``importlib.metadata`` API to fetch the value at runtime. (``importlib." -"metadata`` was introduced in Python 3.8 and is available to older versions " -"as the ``importlib-metadata`` project.) An installed project's version can " -"be fetched with the API as follows::" -msgstr "" -"Defina o valor em :file:`setup.py` e faça com que o código do projeto use a " -"API ``importlib.metadata`` para buscar o valor em tempo de execução. " -"(``importlib.metadata`` foi introduzido no Python 3.8 e está disponível para " -"versões anteriores como o projeto ``importlib-metadata``.) A versão de um " -"projeto instalado pode ser obtida com a API da seguinte forma::" - -#: ../source/guides/single-sourcing-package-version.rst:110 -msgid "" -"Be aware that the ``importlib.metadata`` API only knows about what's in the " -"installation metadata, which is not necessarily the code that's currently " -"imported." -msgstr "" -"Esteja ciente de que a API ``importlib.metadata`` só sabe sobre o que está " -"nos metadados de instalação, o que não é necessariamente o código que está " -"importado no momento." - -#: ../source/guides/single-sourcing-package-version.rst:114 -msgid "" -"If a project uses this method to fetch its version at runtime, then its " -"``install_requires`` value needs to be edited to install ``importlib-" -"metadata`` on pre-3.8 versions of Python like so::" -msgstr "" -"Se um projeto usa este método para buscar sua versão em tempo de execução, " -"então seu valor ``install_requires`` precisa ser editado para instalar " -"``importlib-metadata`` em versões pré-3.8 do Python como::" - -#: ../source/guides/single-sourcing-package-version.rst:128 -msgid "" -"An older (and less efficient) alternative to ``importlib.metadata`` is the " -"``pkg_resources`` API provided by ``setuptools``::" -msgstr "" -"’Uma alternativa mais antiga (e menos eficiente) ao ``importlib.metadata`` é " -"a API ``pkg_resources`` fornecida pelo ``setuptools``::" - -#: ../source/guides/single-sourcing-package-version.rst:134 -msgid "" -"If a project uses ``pkg_resources`` to fetch its own version at runtime, " -"then ``setuptools`` must be added to the project's ``install_requires`` list." -msgstr "" -"Se um projeto usa ``pkg_resources`` para buscar sua própria versão em tempo " -"de execução, então ``setuptools`` deve ser adicionado à lista " -"``install_requires`` do projeto." - -#: ../source/guides/single-sourcing-package-version.rst:138 -msgid "" -"Example using this technique: `setuptools `_." -msgstr "" -"Exemplo usando esta técnica: `setuptools `_." - -#: ../source/guides/single-sourcing-package-version.rst:141 -msgid "" -"Set the value to ``__version__`` in ``sample/__init__.py`` and import " -"``sample`` in :file:`setup.py`." -msgstr "" -"Defina o valor para ``__version__`` em ``sample/__init__.py`` e importe " -"``sample`` no :file:`setup.py`." - -#: ../source/guides/single-sourcing-package-version.rst:155 -msgid "" -"Although this technique is common, beware that it will fail if ``sample/" -"__init__.py`` imports packages from ``install_requires`` dependencies, which " -"will very likely not be installed yet when :file:`setup.py` is run." -msgstr "" -"Embora esta técnica seja comum, esteja ciente que ela vai falhar se ``sample/" -"__init__.py`` importar pacotes de dependências ``install_requires``, que " -"muito provavelmente ainda não estarão instalados quando :file:`setup.py` for " -"executado." - -#: ../source/guides/single-sourcing-package-version.rst:161 -msgid "" -"Keep the version number in the tags of a version control system (Git, " -"Mercurial, etc) instead of in the code, and automatically extract it from " -"there using `setuptools_scm `_." -msgstr "" -"Mantenha o número da versão nas tags de um sistema de controle de versão " -"(Git, Mercurial, etc), em vez de no código, e extraia-o automaticamente de " -"lá usando `setuptools_scm `_." - -#: ../source/guides/supporting-multiple-python-versions.rst:5 -msgid "Supporting multiple Python versions" -msgstr "Fornecendo suporte a várias versões do Python" - -#: ../source/guides/supporting-multiple-python-versions.rst:37 -msgid "" -"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." -msgstr "" -"Além do trabalho necessário para criar um pacote Python, geralmente é " -"necessário que o pacote esteja disponível em diferentes versões do Python. " -"Diferentes versões Python podem conter diferentes (ou renomeados) pacotes de " -"biblioteca padrão, e as alterações entre Python versões 2.x e 3.x incluem " -"alterações na sintaxe da linguagem." - -#: ../source/guides/supporting-multiple-python-versions.rst:43 -msgid "" -"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." -msgstr "" -"Executados manualmente, todos os testes necessários para garantir que o " -"pacote funcione corretamente em todas as versões alvo Python (e sistemas " -"operacionais!) podem consumir muito tempo. Felizmente, várias ferramentas " -"estão disponíveis para lidar com isso, e elas serão brevemente discutidas " -"aqui." - -#: ../source/guides/supporting-multiple-python-versions.rst:49 -msgid "Automated testing and continuous integration" -msgstr "Testes automatizados e integração contínua" - -#: ../source/guides/supporting-multiple-python-versions.rst:51 -msgid "" -"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." -msgstr "" -"Vários serviços hospedados para testes automatizados estão disponíveis. " -"Esses serviços normalmente irão monitorar seu repositório de código-fonte " -"(por exemplo, no `Github `_ ou `Bitbucket `_) e executar um conjunto de testes do seu projeto toda vez " -"que um novo commit é feito." - -#: ../source/guides/supporting-multiple-python-versions.rst:56 -msgid "" -"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." -msgstr "" -"Esses serviços também oferecem facilidades para executar o conjunto de " -"testes do seu projeto em *várias versões do Python*, fornecendo um feedback " -"rápido sobre se o código funcionará, sem que o desenvolvedor tenha que " -"realizar esses testes por conta própria." - -#: ../source/guides/supporting-multiple-python-versions.rst:60 -msgid "" -"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:" -msgstr "" -"A Wikipédia tem uma extensa `comparação `_ de muitos sistemas de " -"integração contínua. Existem dois serviços hospedados que, quando usados em " -"conjunto, fornecem testes automatizados no Linux, Mac e Windows:" - -#: ../source/guides/supporting-multiple-python-versions.rst:66 -msgid "" -"`Travis CI `_ provides both a Linux and a macOS " -"environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit " -"while the macOS is 10.9.2 at the time of writing." -msgstr "" -"`Travis CI `_ fornece um ambiente Linux e macOS. O " -"ambiente Linux é Ubuntu 12.04 LTS Server Edition de 64 bits, enquanto o " -"macOS é 10.9.2 no momento da escrita." - -#: ../source/guides/supporting-multiple-python-versions.rst:69 -msgid "" -"`Appveyor `_ provides a Windows environment " -"(Windows Server 2012)." -msgstr "" -"`Appveyor `_ fornece um ambiente Windows (Windows " -"Server 2012)." - -#: ../source/guides/supporting-multiple-python-versions.rst:80 -msgid "" -"Both `Travis CI`_ 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." -msgstr "" -"Tanto o `Travis CI`_ quanto o Appveyor_ exigem um arquivo formatado em `YAML " -"`_ como especificação para as instruções de teste. Se " -"algum teste falhar, o log de saída para essa configuração específica pode " -"ser inspecionado." - -#: ../source/guides/supporting-multiple-python-versions.rst:85 -msgid "" -"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." -msgstr "" -"Para projetos Python que devem ser implantados em Python 2 e 3 com uma " -"estratégia de única fonte, há uma série de opções." - -#: ../source/guides/supporting-multiple-python-versions.rst:89 -msgid "Tools for single-source Python packages" -msgstr "Ferramentas para pacotes Python de única fonte" - -#: ../source/guides/supporting-multiple-python-versions.rst:91 -msgid "" -"`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_." -msgstr "" -"`six `_ é uma ferramenta desenvolvida por " -"Benjamin Peterson para resolver as diferenças entre Python 2 e Python 3. O " -"pacote six_ desfrutou de uso generalizado e pode ser considerado como uma " -"maneira confiável de escrever um módulo Python de fonte única que pode ser " -"usado em Python 2 e 3. O módulo six_ pode ser usado a partir de Python 2.5. " -"Uma ferramenta chamada `modernize `_, " -"desenvolvida por Armin Ronacher, pode ser usada para aplicar automaticamente " -"as modificações de código fornecidas por six_." - -#: ../source/guides/supporting-multiple-python-versions.rst:100 -msgid "" -"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" -msgstr "" -"Semelhante a six_, `python-future `_ " -"é um pacote que fornece uma camada de compatibilidade entre o código-fonte " -"de Python 2 e Python 3; no entanto, ao contrário do six_, este pacote visa " -"fornecer interoperabilidade entre Python 2 e Python 3 com uma sintaxe de " -"linguagem que corresponda a uma das duas versões Python: pode-se usar" - -#: ../source/guides/supporting-multiple-python-versions.rst:107 -msgid "a Python 2 (by syntax) module in a Python 3 project." -msgstr "um módulo Python 2 (por sintaxe) em um projeto Python 3." - -#: ../source/guides/supporting-multiple-python-versions.rst:108 -msgid "a Python 3 (by syntax) module in a *Python 2* project." -msgstr "um módulo Python 3 (por sintaxe) em um projeto *Python 3*." - -#: ../source/guides/supporting-multiple-python-versions.rst:110 -msgid "" -"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." -msgstr "" -"Por causa da bidirecionalidade, python-future_ oferece um caminho para " -"converter um pacote Python 2 na sintaxe de Python 3, módulo por módulo. No " -"entanto, em contraste com six_, python-future_ é compatível apenas com " -"Python 2.6. Semelhante a modernize_ para six_, python-future_ vem com dois " -"scripts chamados ``futurize`` e ``pasteurize`` que podem ser aplicados a um " -"módulo Python 2 ou um módulo Python 3 respectivamente." - -#: ../source/guides/supporting-multiple-python-versions.rst:117 -msgid "" -"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." -msgstr "" -"O uso de six_ ou python-future_ adiciona uma dependência adicional de tempo " -"de execução ao seu pacote: com python-future_, o script ``futurize`` pode " -"ser chamado com a opção ``--stage1`` para aplicar apenas as mudanças que " -"Python 2.6+ já fornece compatibilidade com versões futuras para Python 3. " -"Quaisquer problemas de compatibilidade remanescentes exigiriam alterações " -"manuais." - -#: ../source/guides/supporting-multiple-python-versions.rst:124 -msgid "What's in which Python?" -msgstr "O que há em cada Python?" - -#: ../source/guides/supporting-multiple-python-versions.rst:126 -msgid "" -"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." -msgstr "" -"Ned Batchelder fornece uma lista de alterações em cada versão Python para " -"`Python 2 `__, `Python 3.0-3.3 `__ e `Python 3.4-3.6 `__. Essas listas podem ser " -"usadas para verificar se quaisquer mudanças entre as versões Python podem " -"afetar seu pacote." - -#: ../source/guides/supporting-windows-using-appveyor.rst:3 -msgid "Supporting Windows using Appveyor" -msgstr "Oferece suporte a Windows usando Appveyor" - -#: ../source/guides/supporting-windows-using-appveyor.rst:6 -msgid "2015-12-03" -msgstr "2015-12-03" - -#: ../source/guides/supporting-windows-using-appveyor.rst:8 -msgid "" -"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." -msgstr "" -"Esta seção cobre como usar o serviço gratuito de integração contínua " -"`Appveyor`_ para fornecer suporte a Windows para seu projeto. Isso inclui " -"testar o código no Windows e construir binários direcionados para Windows " -"para projetos que usam extensões C." - -#: ../source/guides/supporting-windows-using-appveyor.rst:20 -msgid "" -"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." -msgstr "" -"Muitos projetos são desenvolvidos em Unix por padrão, e fornecer suporte ao " -"Windows pode ser um desafio, porque configurar um ambiente de teste adequado " -"no Windows não é trivial e pode exigir a compra de licenças de software." - -#: ../source/guides/supporting-windows-using-appveyor.rst:24 -msgid "" -"The Appveyor service is a continuous integration service, much like the " -"better-known `Travis`_ service that is commonly used for testing by projects " -"hosted on `Github`_. However, unlike Travis, the build workers on Appveyor " -"are Windows hosts and have the necessary compilers installed to build Python " -"extensions." -msgstr "" -"O serviço Appveyor é um serviço de integração contínua, muito parecido com o " -"serviço `Travis`_ mais conhecido que é comumente usado para testes por " -"projetos hospedados no `Github`_. No entanto, ao contrário do Travis, os " -"workers de construção no Appveyor são hosts Windows e têm os compiladores " -"necessários instalados para construir extensões Python." - -#: ../source/guides/supporting-windows-using-appveyor.rst:30 -msgid "" -"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." -msgstr "" -"Os usuários do Windows normalmente não têm acesso a um compilador C e, " -"portanto, dependem de projetos que usam extensões C distribuindo wheels " -"binárias no PyPI para que a distribuição seja instalável via ``python -m pip " -"install ``. Ao usar o Appveyor como um serviço de construção (mesmo " -"que não seja para teste), é possível para projetos sem um ambiente Windows " -"dedicado fornecer binários direcionados ao Windows." - -#: ../source/guides/supporting-windows-using-appveyor.rst:38 -msgid "Setting up" -msgstr "Configurando" - -#: ../source/guides/supporting-windows-using-appveyor.rst:40 -msgid "" -"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." -msgstr "" -"Para usar o Appveyor para construir wheels de Windows para o seu projeto, " -"você deve ter uma conta no serviço. As instruções sobre como configurar uma " -"conta são fornecidas `na documentação do Appveyor `__. O nível de conta grátis é perfeitamente adequado para projetos de " -"código aberto." - -#: ../source/guides/supporting-windows-using-appveyor.rst:45 -msgid "" -"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." -msgstr "" -"O Appveyor fornece integração com `Github`_ e `Bitbucket`_, portanto, desde " -"que seu projeto esteja hospedado em um desses dois serviços, configurar a " -"integração do Appveyor é simples." - -#: ../source/guides/supporting-windows-using-appveyor.rst:49 -msgid "" -"Once you have set up your Appveyor account and added your project, Appveyor " -"will automatically build your project each time a commit occurs. This " -"behaviour will be familiar to users of Travis." -msgstr "" -"Depois de configurar sua conta do Appveyor e adicionar seu projeto, o " -"Appveyor construirá automaticamente seu projeto cada vez que ocorrer um " -"commit. Esse comportamento será familiar para os usuários do Travis." - -#: ../source/guides/supporting-windows-using-appveyor.rst:54 -msgid "Adding Appveyor support to your project" -msgstr "Adicionando suporte a Appveyor ao seu projeto" - -#: ../source/guides/supporting-windows-using-appveyor.rst:56 -msgid "" -"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." -msgstr "" -"Para definir como o Appveyor deve construir seu projeto, você precisa " -"adicionar um arquivo :file:`appveyor.yml` ao seu projeto. Os detalhes " -"completos do que pode ser incluído no arquivo são cobertos na documentação " -"do Appveyor. Este guia fornecerá os detalhes necessários para configurar a " -"configuração dos wheels." - -#: ../source/guides/supporting-windows-using-appveyor.rst:61 -msgid "" -"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)." -msgstr "" -"O Appveyor inclui por padrão todos os conjuntos de ferramentas do compilador " -"necessários para construir extensões para Python. Para Python 2.7, 3.5+ e " -"versões de 32 bits de 3.3 e 3.4, as ferramentas funcionam prontamente. Mas " -"para as versões de 64 bits do Python 3.3 e 3.4, há uma pequena quantidade de " -"configuração adicional necessária para permitir que os distutils saibam onde " -"encontrar os compiladores de 64 bits. (De 3.5 em diante, a versão do Visual " -"Studio usada inclui compiladores de 64 bits sem configuração adicional)." - -#: ../source/guides/supporting-windows-using-appveyor.rst:69 -msgid "appveyor.yml" -msgstr "appveyor.yml" - -#: ../source/guides/supporting-windows-using-appveyor.rst:75 -msgid "" -"This file can be downloaded from `here `__." -msgstr "" -"Este arquivo pode ser baixado `daqui `__." - -#: ../source/guides/supporting-windows-using-appveyor.rst:77 -msgid "" -"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." -msgstr "" -"O arquivo :file:`appveyor.yml` deve estar localizado no diretório raiz do " -"seu projeto. Está no formato ``YAML`` e consiste em várias seções." - -#: ../source/guides/supporting-windows-using-appveyor.rst:80 -msgid "" -"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)." -msgstr "" -"A seção ``environment`` é a chave para definir as versões Python para as " -"quais seus wheels serão criados. O Appveyor vem com Python 2.6, 2.7, 3.3, " -"3.4 e 3.5 instalados, em compilações de 32 e 64 bits. O arquivo de exemplo é " -"criado para todos esses ambientes, exceto Python 2.6. A instalação do Python " -"2.6 é mais complexa, pois não vem com o pip incluído. Não oferecemos suporte " -"ao 2.6 neste documento (já que os usuários do Windows que ainda usam o " -"Python 2 geralmente são capazes de migrar para o Python 2.7 sem muita " -"dificuldade)." - -#: ../source/guides/supporting-windows-using-appveyor.rst:88 -msgid "" -"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``)." -msgstr "" -"A seção ``install`` usa pip para instalar qualquer software adicional que o " -"projeto possa exigir. O único requisito para a construção de wheels é o " -"projeto ``wheel``, mas os projetos podem desejar personalizar este código em " -"certas circunstâncias (por exemplo, para instalar pacotes de construção " -"adicionais, como ``Cython``, ou ferramentas de teste como ``tox``)." - -#: ../source/guides/supporting-windows-using-appveyor.rst:94 -msgid "" -"The ``build`` section simply switches off builds - there is no build step " -"needed for Python, unlike languages like ``C#``." -msgstr "" -"A seção ``build`` simplesmente desativa as construções -- não há etapa de " -"construção necessária para Python, ao contrário de linguagens como ``C#``." - -#: ../source/guides/supporting-windows-using-appveyor.rst:97 -msgid "" -"The main sections that will need to be tailored to your project are " -"``test_script`` and ``after_test``." -msgstr "" -"As principais seções que precisarão ser adaptadas ao seu projeto são " -"``test_script`` e ``after_test``." - -#: ../source/guides/supporting-windows-using-appveyor.rst:100 -msgid "" -"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." -msgstr "" -"A seção ``test_script`` é onde você executará os testes do seu projeto. O " -"arquivo fornecido executa seu conjunto de testes usando ``setup.py test``. " -"Se você está interessado apenas em construir wheels, e não em executar seus " -"testes no Windows, você pode substituir esta seção por um comando fictício, " -"como ``echo Skipped Tests``. Você pode querer usar outra ferramenta de " -"teste, como ``nose`` ou :file:`py.test`. Ou você pode desejar usar um driver " -"de teste como o ``tox`` -- entretanto, se você estiver usando o ``tox``, " -"existem algumas alterações de configuração adicionais que você precisará " -"considerar, que são descritas abaixo." - -#: ../source/guides/supporting-windows-using-appveyor.rst:109 -msgid "" -"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." -msgstr "" -"O ``after_test`` é executado uma vez que seus testes foram concluídos, e " -"então é onde os wheels devem ser construídos. Presumindo que seu projeto usa " -"as ferramentas recomendadas (especificamente, ``setuptools``) então o " -"comando ``setup.py bdist_wheel`` irá construir seus wheels." - -#: ../source/guides/supporting-windows-using-appveyor.rst:114 -msgid "" -"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." -msgstr "" -"Observe que os wheels só serão construídos se seus testes forem bem-" -"sucedidos. Se você espera que seus testes falhem no Windows, você pode pulá-" -"los conforme descrito acima." - -#: ../source/guides/supporting-windows-using-appveyor.rst:119 -msgid "Support script" -msgstr "Script de suporte" - -#: ../source/guides/supporting-windows-using-appveyor.rst:121 -msgid "" -"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." -msgstr "" -"O arquivo :file:`appveyor.yml` depende de um único script de suporte, que " -"configura o ambiente para usar o compilador SDK para compilações de 64 bits " -"no Python 3.3 e 3.4. Para projetos que não precisam de um compilador, ou que " -"não oferecem suporte a 3.3 ou 3.4 em Windows 64 bits, apenas o arquivo :file:" -"`appveyor.yml` é necessário." - -#: ../source/guides/supporting-windows-using-appveyor.rst:126 -msgid "" -"`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." -msgstr "" -"`build.cmd `__ é um script em lote " -"do Windows que executa um único comando em um ambiente com o compilador " -"apropriado para a versão Python selecionada. Tudo que você precisa fazer é " -"definir a única variável de ambiente ``DISTUTILS_USE_SDK`` para um valor de " -"``1`` e o script faz o resto. Ele configura o SDK necessário para " -"compilações de 64 bits de Python 3.3 ou 3.4, portanto, não defina a variável " -"de ambiente para quaisquer outras compilações." - -#: ../source/guides/supporting-windows-using-appveyor.rst:133 -msgid "" -"You can simply download the batch file and include it in your project " -"unchanged." -msgstr "" -"Você pode simplesmente baixar o arquivo em lote e incluí-lo em seu projeto " -"inalterado." - -#: ../source/guides/supporting-windows-using-appveyor.rst:137 -msgid "Access to the built wheels" -msgstr "Acesso aos wheels construídos" - -#: ../source/guides/supporting-windows-using-appveyor.rst:139 -msgid "" -"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." -msgstr "" -"Quando sua construção for concluída, os wheels construídos estarão " -"disponíveis no painel de controle do Appveyor para o seu projeto. Eles podem " -"ser encontrados acessando a página de status de construção de cada " -"construção por vez. No topo da saída de construção, há uma série de links, " -"um dos quais é \"Artifacts\" (Artefatos). Essa página incluirá uma lista de " -"links para os wheels dessa versão Python / arquitetura. Você pode baixar " -"esses wheels e enviá-los para PyPI como parte de seu processo de lançamento." - -#: ../source/guides/supporting-windows-using-appveyor.rst:147 -msgid "Additional notes" -msgstr "Notas adicionais" - -#: ../source/guides/supporting-windows-using-appveyor.rst:150 -msgid "Testing with tox" -msgstr "Testando com tox" - -#: ../source/guides/supporting-windows-using-appveyor.rst:152 -msgid "" -"Many projects use the `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." -msgstr "" -"Muitos projetos usam a ferramenta `Tox`_ para executar seus testes. Ele " -"garante que os testes sejam executados em um ambiente isolado usando os " -"arquivos exatos que serão distribuídos pelo projeto." - -#: ../source/guides/supporting-windows-using-appveyor.rst:156 -msgid "" -"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)." -msgstr "" -"Para usar o ``tox`` no Appveyor, há algumas considerações adicionais (na " -"verdade, esses problemas não são específicos do Appveyor e podem afetar " -"outros sistemas de CI)." - -#: ../source/guides/supporting-windows-using-appveyor.rst:160 -msgid "" -"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." -msgstr "" -"Por padrão, ``tox`` apenas passa um subconjunto escolhido de variáveis de " -"ambiente para os processos de teste. Como ``distutils`` usa variáveis de " -"ambiente para controlar o compilador, este recurso de \"isolamento de teste" -"\" fará com que os testes usem o compilador errado por padrão." - -#: ../source/guides/supporting-windows-using-appveyor.rst:165 -msgid "" -"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" -msgstr "" -"Para forçar o ``tox`` passar as variáveis de ambiente necessárias para o " -"subprocesso, você precisa definir a opção de configuração ``passenv`` do " -"``tox`` para listar as variáveis de ambiente adicionais a serem passadas " -"para o subprocesso. Para os compiladores SDK, você precisa" - -#: ../source/guides/supporting-windows-using-appveyor.rst:170 -msgid "``DISTUTILS_USE_SDK``" -msgstr "``DISTUTILS_USE_SDK``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:171 -msgid "``MSSdk``" -msgstr "``MSSdk``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:172 -msgid "``INCLUDE``" -msgstr "``INCLUDE``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:173 -msgid "``LIB``" -msgstr "``LIB``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:175 -msgid "" -"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." -msgstr "" -"A opção ``passenv`` pode ser definida em seu :file:`tox.ini`, ou se você " -"preferir evitar adicionar configurações específicas do Windows aos seus " -"arquivos de projeto gerais, pode ser definida configurando a variável de " -"ambiente ``TOX_TESTENV_PASSENV``. O script :file:`build.cmd` fornecido faz " -"isso por padrão sempre que ``DISTUTILS_USE_SDK`` é definida." - -#: ../source/guides/supporting-windows-using-appveyor.rst:181 -msgid "" -"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 Travis or 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)." -msgstr "" -"Quando usado interativamente, ``tox`` permite que você execute seus testes " -"em vários ambientes (frequentemente, isso significa várias versões do " -"Python). Este recurso não é tão útil em um ambiente de CI como Travis ou " -"Appveyor, onde todos os testes são executados em ambientes isolados para " -"cada configuração. Como resultado, os projetos geralmente fornecem um " -"argumento ``-e NOMEENV`` para ``tox`` para especificar qual ambiente usar " -"(há ambientes padrão para a maioria das versões do Python)." - -#: ../source/guides/supporting-windows-using-appveyor.rst:188 -msgid "" -"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``." -msgstr "" -"No entanto, isso *não* funciona bem com um sistema de CI no Windows como o " -"Appveyor, onde há (por exemplo) duas instalações de Python 3.4 (32 bits e 64 " -"bits) disponíveis, mas apenas um ambiente ``py34`` no ``tox``." - -#: ../source/guides/supporting-windows-using-appveyor.rst:192 -msgid "" -"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." -msgstr "" -"Para executar testes usando o ``tox``, portanto, os projetos provavelmente " -"devem usar o ambiente padrão ``py`` no ``tox``, que usa o interpretador " -"Python que foi usado para executar ``tox`` . Isso garantirá que, quando o " -"Appveyor executar os testes, eles serão executados com o interpretador " -"configurado." - -#: ../source/guides/supporting-windows-using-appveyor.rst:197 -msgid "" -"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." -msgstr "" -"Para oferecer suporte à execução no ambiente ``py``, é possível que projetos " -"com configurações complexas de ``tox`` precisem modificar seu arquivo :file:" -"`tox.ini`. Fazer isso está, no entanto, fora do escopo deste documento." - -#: ../source/guides/supporting-windows-using-appveyor.rst:203 -msgid "Automatically uploading wheels" -msgstr "Enviando automaticamente wheels" - -#: ../source/guides/supporting-windows-using-appveyor.rst:205 -msgid "" -"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." -msgstr "" -"É possível solicitar que o Appveyor envie automaticamente os wheels. Há uma " -"etapa ``deployment`` disponível no :file:`appveyor.yml` que pode ser usada " -"para, por exemplo, copiar os artefatos construídos para um site FTP ou uma " -"instância do Amazon S3. A documentação sobre como fazer isso está incluída " -"nos guias do Appveyor." - -#: ../source/guides/supporting-windows-using-appveyor.rst:210 -msgid "" -"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)." -msgstr "" -"Alternativamente, seria possível adicionar um passo ``twine upload`` à " -"construção. O :file:`appveyor.yml` fornecido não faz isso, pois não está " -"claro se é desejável enviar novos wheels após cada commit (embora alguns " -"projetos possam desejar fazer isso)." - -#: ../source/guides/supporting-windows-using-appveyor.rst:216 -msgid "External dependencies" -msgstr "Dependências externas" - -#: ../source/guides/supporting-windows-using-appveyor.rst:218 -msgid "" -"The supplied scripts will successfully build any distribution that does not " -"rely on 3rd party external libraries for the build." -msgstr "" -"Os scripts fornecidos construirão com sucesso qualquer distribuição que não " -"dependa de bibliotecas externas de terceiros para a construção." - -#: ../source/guides/supporting-windows-using-appveyor.rst:221 -msgid "" -"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." -msgstr "" -"É possível adicionar etapas à configuração :file:`appveyor.yml` (normalmente " -"na seção \"install\") para baixar e/ou construir bibliotecas externas " -"necessárias para a distribuição. E se necessário, é possível adicionar " -"configuração extra para a construção para fornecer a localização dessas " -"bibliotecas para o compilador. No entanto, esse nível de configuração está " -"além do escopo deste documento." - -#: ../source/guides/supporting-windows-using-appveyor.rst:230 -msgid "Support scripts" -msgstr "Scripts de suporte" - -#: ../source/guides/supporting-windows-using-appveyor.rst:232 -msgid "For reference, the SDK setup support script is listed here:" -msgstr "" -"Para referência, o script de suporte de configuração do SDK está listado " -"aqui:" - -#: ../source/guides/supporting-windows-using-appveyor.rst:234 -msgid "``appveyor-sample/build.cmd``" -msgstr "``appveyor-sample/build.cmd``" - -#: ../source/guides/tool-recommendations.rst:5 -msgid "Tool recommendations" -msgstr "Recomendações de ferramentas" - -#: ../source/guides/tool-recommendations.rst:7 -msgid "" -"If you're familiar with Python packaging and installation, and just want to " -"know what tools are currently recommended, then here it is." -msgstr "" -"Se você está familiarizado com o pacote e a instalação do Python e só deseja " -"saber quais ferramentas são recomendadas atualmente, aqui está." - -#: ../source/guides/tool-recommendations.rst:12 -msgid "Application dependency management" -msgstr "Gerenciamento de dependências de aplicações" - -#: ../source/guides/tool-recommendations.rst:14 -msgid "" -"Use :ref:`pipenv` to manage library dependencies when developing Python " -"applications. See :doc:`../tutorials/managing-dependencies` for more details " -"on using ``pipenv``." -msgstr "" -"Use :ref:`pipenv` para gerenciar as dependências da biblioteca ao " -"desenvolver aplicações Python. Veja :doc:`../tutorials/managing-" -"dependencies` para mais detalhes sobre como usar o ``pip env``." - -#: ../source/guides/tool-recommendations.rst:18 -msgid "When ``pipenv`` does not meet your use case, consider other tools like:" -msgstr "" -"Quando ``pipenv`` não atende ao seu caso de uso, considere outras " -"ferramentas como:" - -#: ../source/guides/tool-recommendations.rst:20 -msgid ":ref:`pip`" -msgstr ":ref:`pip`" - -#: ../source/guides/tool-recommendations.rst:22 -msgid "`pip-tools `_" -msgstr "`pip-tools `_" - -#: ../source/guides/tool-recommendations.rst:24 -msgid "`Poetry `_" -msgstr "`Poetry `_" - -#: ../source/guides/tool-recommendations.rst:27 -msgid "Installation tool recommendations" -msgstr "Recomendações de ferramentas de instalação" - -#: ../source/guides/tool-recommendations.rst:29 -msgid "" -"Use :ref:`pip` to install Python :term:`packages ` " -"from :term:`PyPI `. [1]_ [2]_ Depending on how :" -"ref:`pip` is installed, you may need to also install :ref:`wheel` to get the " -"benefit of wheel caching. [3]_" -msgstr "" -"Use :ref:`pip` para instalar :term:`pacotes ` do " -"Python a partir do :term:`PyPI `. [1]_ [2]_ " -"Dependendo de como :ref:`pip` é instalado, você também pode precisar " -"instalar o :ref:`wheel` para obter o benefício do armazenamento em cache do " -"wheel. [3]_" - -#: ../source/guides/tool-recommendations.rst:34 -msgid "" -"Use :ref:`virtualenv`, or `venv`_ to isolate application specific " -"dependencies from a shared Python installation. [4]_" -msgstr "" -"Use :ref:`virtualenv` ou `venv`_ para isolar dependências específicas da " -"aplicação de uma instalação compartilhada do Python. [4]_" - -#: ../source/guides/tool-recommendations.rst:37 -msgid "" -"If you're looking for management of fully integrated cross-platform software " -"stacks, consider:" -msgstr "" -"Se você estiver procurando por gerenciamento de pilhas de software " -"multiplataforma totalmente integradas, considere:" - -#: ../source/guides/tool-recommendations.rst:40 -msgid ":ref:`buildout`: primarily focused on the web development community" -msgstr "" -":ref:`buildout`: focado principalmente na comunidade de desenvolvimento web" - -#: ../source/guides/tool-recommendations.rst:42 -msgid "" -":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the " -"scientific community." -msgstr "" -":ref:`spack`, :ref:`hashdist` ou :ref:`conda`: focado principalmente na " -"comunidade científica." - -#: ../source/guides/tool-recommendations.rst:47 -msgid "Packaging tool recommendations" -msgstr "Recomendações de ferramentas de empacotamento" - -#: ../source/guides/tool-recommendations.rst:49 -msgid "" -"Use :ref:`setuptools` to define projects and create :term:`Source " -"Distributions `. [5]_ [6]_" -msgstr "" -"Use :ref:`setuptools` para definir projetos e criar :term:`Distribuições " -"Fontes `. [5]_ [6]_" - -#: ../source/guides/tool-recommendations.rst:52 -msgid "" -"Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:" -"`wheel project ` to create :term:`wheels `. This is " -"especially beneficial, if your project contains binary extensions." -msgstr "" -"Use a extensão ``bdist_wheel`` :ref:`setuptools` disponível no :ref: " -"`projeto wheel ` para criar :term:`wheels `. Isso é " -"especialmente benéfico se o seu projeto contiver extensões binárias." - -#: ../source/guides/tool-recommendations.rst:56 -msgid "" -"Use `twine `_ for uploading distributions " -"to :term:`PyPI `." -msgstr "" -"Use `twine `_ para enviar distribuições para " -"o :term:`PyPI `." - -#: ../source/guides/tool-recommendations.rst:61 -msgid "Publishing platform migration" -msgstr "Migração da plataforma de publicação" - -#: ../source/guides/tool-recommendations.rst:63 -msgid "" -"The original Python Package Index implementation (previously hosted at `pypi." -"python.org `_) has been phased out in favour of an " -"updated implementation hosted at `pypi.org `_." -msgstr "" -"A implementação do Python Package Index original (anteriormente hospedada em " -"`pypi.python.org `_) foi eliminada em favor de uma " -"implementação atualizada hospedada em `pypi.org `_." - -#: ../source/guides/tool-recommendations.rst:67 -msgid "" -"See :ref:`Migrating to PyPI.org` for more information on the status of the " -"migration, and what settings to change in your clients." -msgstr "" -"Veja :ref:`Migrando para PyPI.org ` para mais " -"informações sobre o status da migração, e quais configurações alterar em " -"seus clientes." - -#: ../source/guides/tool-recommendations.rst:72 -msgid "" -"There are some cases where you might choose to use ``easy_install`` (from :" -"ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` " -"(which pip doesn't support). For a detailed breakdown, see :ref:`pip vs " -"easy_install`." -msgstr "" -"Existem alguns casos em que você pode escolher usar ``easy_install`` (do :" -"ref:`setuptools`), por exemplo se você precisar instalar a partir de :term:" -"`Eggs ` (que pip não oferece suporte). Para uma análise detalhada, " -"consulte :ref:`pip vs easy_install`." - -#: ../source/guides/tool-recommendations.rst:77 -msgid "" -"The acceptance of :pep:`453` means that :ref:`pip` will be available by " -"default in most installations of Python 3.4 or later. See the :pep:" -"`rationale section <453#rationale>` from :pep:`453` as for why pip was " -"chosen." -msgstr "" -"A aceitação da :pep:`453` significa que :ref:`pip` estará disponível por " -"padrão na maioria das instalações do Python 3.4 ou posterior. Veja a :pep:" -"`seção de motivos <453#rationale>` da :pep:`453` para saber por que pip foi " -"escolhido." - -#: ../source/guides/tool-recommendations.rst:82 -msgid "" -"`get-pip.py `_ and :ref:" -"`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv " -"` do not currently. Also, the common \"python-pip\" package that's " -"found in various linux distros, does not depend on \"python-wheel\" " -"currently." -msgstr "" -"`get-pip.py `_ e :ref:`virtualenv` " -"instalam :ref:`wheel`, enquanto :ref:`ensurepip` e :ref:`venv ` não " -"instalam atualmente. Além disso, o pacote comum \"python-pip\" que é " -"encontrado em várias distros do Linux, não depende do \"python-wheel\" " -"atualmente." - -#: ../source/guides/tool-recommendations.rst:88 -msgid "" -"Beginning with Python 3.4, ``venv`` will create virtualenv environments with " -"``pip`` installed, thereby making it an equal alternative to :ref:" -"`virtualenv`. However, using :ref:`virtualenv` will still be recommended for " -"users that need cross-version consistency." -msgstr "" -"A partir do Python 3.4, ``venv `` criará ambientes virtualenv com ``pip`` " -"instalado, tornando-o uma alternativa igual a :ref:`virtualenv`. No entanto, " -"usar :ref:`virtualenv` ainda será recomendado para usuários que precisam de " -"consistência entre versões." - -#: ../source/guides/tool-recommendations.rst:93 -msgid "" -"Although you can use pure ``distutils`` for many projects, it does not " -"support defining dependencies on other projects and is missing several " -"convenience utilities for automatically populating distribution metadata " -"correctly that are provided by ``setuptools``. Being outside the standard " -"library, ``setuptools`` also offers a more consistent feature set across " -"different versions of Python, and (unlike ``distutils``), recent versions of " -"``setuptools`` support all of the modern metadata fields described in :ref:" -"`core-metadata`." -msgstr "" -"Embora você possa usar ``distutils`` puro para muitos projetos, ele não " -"oferece suporta à definição de dependências em outros projetos e não possui " -"vários utilitários de conveniência para preencher automaticamente os " -"metadados de distribuição fornecidos pelo ``setuptools``. Estando fora da " -"biblioteca padrão, ``setuptools`` também oferece um conjunto de recursos " -"mais consistente em diferentes versões do Python e (ao contrário de " -"``distutils``), versões recentes do ``setuptools`` oferecem suporte a todos " -"os campos de metadados modernos descritos em :ref:`core-metadata`." - -#: ../source/guides/tool-recommendations.rst:102 -msgid "" -"Even for projects that do choose to use ``distutils``, when :ref:`pip` " -"installs such projects directly from source (rather than installing from a " -"prebuilt :term:`wheel ` file), it will actually build your project " -"using :ref:`setuptools` instead." -msgstr "" -"Mesmo para projetos que escolhem usar ``distutils``, quando o :ref:`pip` " -"instala tais projetos diretamente da fonte (ao invés de instalar de um " -"arquivo :term:`wheel ` pré-construído), ele irá, na verdade, " -"construir seu projeto usando :ref:`setuptools`." - -#: ../source/guides/tool-recommendations.rst:107 -msgid "" -"`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` " -"in June 2013, thereby making setuptools the default choice for packaging." -msgstr "" -"`distribute`_ (um fork do setuptools) foi mesclado no :ref:`setuptools` em " -"junho de 2013, tornando assim setuptools a escolha padrão para empacotamento." - -#: ../source/guides/using-manifest-in.rst:5 -msgid "Including files in source distributions with ``MANIFEST.in``" -msgstr "" -"Incluindo arquivos em distribuições de código-fonte com ``MANIFEST.in``" - -#: ../source/guides/using-manifest-in.rst:7 -msgid "" -"When building a :term:`source distribution ` for your package, by default only a minimal set of files are " -"included. You may find yourself wanting to include extra files in the " -"source distribution, such as an authors/contributors file, a :file:`docs/` " -"directory, or a directory of data files used for testing purposes. There " -"may even be extra files that you *need* to include; for example, if your :" -"file:`setup.py` computes your project's ``long_description`` by reading from " -"both a README and a changelog file, you'll need to include both those files " -"in the sdist so that people that build or install from the sdist get the " -"correct results." -msgstr "" -"Ao construir uma :term:`distribuição fonte ` para o seu pacote, por padrão apenas um conjunto mínimo de arquivos é " -"incluído. Você pode querer incluir arquivos extras na distribuição, como um " -"arquivo de autores/contribuidores, um diretório :file:`docs/` ou um " -"diretório de arquivos de dados usado para fins de teste. Pode até haver " -"arquivos extras que você *precisa* incluir; por exemplo, se o seu :file:" -"`setup.py` calcula a ``long_description`` do seu projeto lendo um arquivo " -"README e um changelog, você precisará incluir ambos os arquivos no sdist " -"para que as pessoas que construam ou instalar a partir do sdist obtém os " -"resultados corretos." - -#: ../source/guides/using-manifest-in.rst:17 -msgid "" -"Adding & removing files to & from the source distribution is done by writing " -"a :file:`MANIFEST.in` file at the project root." -msgstr "" -"Adicionar e remover arquivos para e da distribuição fonte é feito escrevendo " -"um arquivo :file:`MANIFEST.in` na raiz do projeto." - -#: ../source/guides/using-manifest-in.rst:22 -msgid "How files are included in an sdist" -msgstr "Como os arquivos são incluídos em um sdist" - -#: ../source/guides/using-manifest-in.rst:24 -msgid "The following files are included in a source distribution by default:" -msgstr "" -"Os seguintes arquivos são incluídos em uma distribuição fonte por padrão:" - -#: ../source/guides/using-manifest-in.rst:26 -msgid "" -"all Python source files implied by the ``py_modules`` and ``packages`` " -"``setup()`` arguments" -msgstr "" -"todos os arquivos fonte Python implícitos pelos argumentos ``py_modules`` e " -"``packages`` do ``setup()``" - -#: ../source/guides/using-manifest-in.rst:28 -msgid "" -"all C source files mentioned in the ``ext_modules`` or ``libraries`` " -"``setup()`` arguments" -msgstr "" -"todos os arquivos fonte C mencionados nos argumentos ``ext_modules`` ou " -"``libraries`` do ``setup()``" - -#: ../source/guides/using-manifest-in.rst:30 -msgid "scripts specified by the ``scripts`` ``setup()`` argument" -msgstr "scripts especificados pelo argumento ``scripts`` do ``setup()``" - -#: ../source/guides/using-manifest-in.rst:31 -msgid "" -"all files specified by the ``package_data`` and ``data_files`` ``setup()`` " -"arguments" -msgstr "" -"todos os arquivos especificados pelos argumentos ``package_data`` e " -"``data_files`` do ``setup()``" - -#: ../source/guides/using-manifest-in.rst:33 -msgid "" -"the file specified by the ``license_file`` option in :file:`setup.cfg` " -"(setuptools 40.8.0+)" -msgstr "" -"o arquivo especificado pela opção ``license_file`` em :file:`setup.cfg` " -"(setuptools 40.8.0+)" - -#: ../source/guides/using-manifest-in.rst:35 -msgid "" -"all files specified by the ``license_files`` option in :file:`setup.cfg` " -"(setuptools 42.0.0+)" -msgstr "" -"todos os arquivos especificados pela opção ``license_files`` em :file:`setup." -"cfg` (setuptools 42.0.0+)" - -#: ../source/guides/using-manifest-in.rst:37 -msgid "all files matching the pattern :file:`test/test*.py`" -msgstr "todos os arquivos correspondendo ao padrão :file:`test/test*.py`" - -#: ../source/guides/using-manifest-in.rst:38 -msgid ":file:`setup.py` (or whatever you called your setup script)" -msgstr "" -":file:`setup.py` (ou o que quer que você tenha chamado de seu script de " -"configuração)" - -#: ../source/guides/using-manifest-in.rst:39 -msgid ":file:`setup.cfg`" -msgstr ":file:`setup.cfg`" - -#: ../source/guides/using-manifest-in.rst:40 -msgid ":file:`README`" -msgstr ":file:`README`" - -#: ../source/guides/using-manifest-in.rst:41 -msgid ":file:`README.txt`" -msgstr ":file:`README.txt`" - -#: ../source/guides/using-manifest-in.rst:42 -msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" -msgstr ":file:`README.rst` (Python 3.7+ ou setuptools 0.6.27+)" - -#: ../source/guides/using-manifest-in.rst:43 -msgid ":file:`README.md` (setuptools 36.4.0+)" -msgstr ":file:`README.md` (setuptools 36.4.0+)" - -#: ../source/guides/using-manifest-in.rst:44 -msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" -msgstr ":file:`pyproject.toml` (setuptools 43.0.0+)" - -#: ../source/guides/using-manifest-in.rst:45 -msgid ":file:`MANIFEST.in`" -msgstr ":file:`MANIFEST.in`" - -#: ../source/guides/using-manifest-in.rst:47 -msgid "" -"After adding the above files to the sdist, the commands in :file:`MANIFEST." -"in` (if such a file exists) are executed in order to add and remove further " -"files to & from the sdist. Default files can even be removed from the sdist " -"with the appropriate :file:`MANIFEST.in` command." -msgstr "" -"Depois de adicionar os arquivos acima ao sdist, os comandos em :file:" -"`MANIFEST.in` (se tal arquivo existir) são executados para adicionar e " -"remover outros arquivos para e do sdist. Os arquivos padrão podem até mesmo " -"ser removidos do sdist com o comando apropriado de :file:`MANIFEST.in`." - -#: ../source/guides/using-manifest-in.rst:52 -msgid "" -"After processing the :file:`MANIFEST.in` file, setuptools removes the :file:" -"`build/` directory as well as any directories named :file:`RCS`, :file:" -"`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file " -"and an :file:`*.egg-info` directory. This behavior cannot be changed with :" -"file:`MANIFEST.in`." -msgstr "" -"Após processar o arquivo :file:`MANIFEST.in`, setuptools remove o diretório :" -"file:`build/` bem como quaisquer diretórios chamados :file:`RCS`, :file:" -"`CVS` ou :file:`.svn` do sdist, e adiciona um arquivo :file:`PKG-INFO` e um " -"diretório :file:`*.egg-info`. Este comportamento não pode ser alterado com :" -"file:`MANIFEST.in`." - -#: ../source/guides/using-manifest-in.rst:60 -msgid ":file:`MANIFEST.in` commands" -msgstr "Comandos do :file:`MANIFEST.in`" - -#: ../source/guides/using-manifest-in.rst:62 -msgid "" -"A :file:`MANIFEST.in` file consists of commands, one per line, instructing " -"setuptools to add or remove some set of files from the sdist. The commands " -"are:" -msgstr "" -"Um arquivo :file:`MANIFEST.in` consiste em comandos, um por linha, " -"instruindo o setuptools a adicionar ou remover algum conjunto de arquivos do " -"sdist. Os comandos são:" - -#: ../source/guides/using-manifest-in.rst:67 -msgid "Command" -msgstr "Comando" - -#: ../source/guides/using-manifest-in.rst:69 -msgid ":samp:`include {pat1} {pat2} ...`" -msgstr ":samp:`include {padrão1} {padrão2} ...`" - -#: ../source/guides/using-manifest-in.rst:69 -msgid "Add all files matching any of the listed patterns" -msgstr "" -"Adiciona todos os arquivos correspondendo a qualquer um dos padrões listados" - -#: ../source/guides/using-manifest-in.rst:70 -msgid ":samp:`exclude {pat1} {pat2} ...`" -msgstr ":samp:`exclude {padrão1} {padrão2} ...`" - -#: ../source/guides/using-manifest-in.rst:70 -msgid "Remove all files matching any of the listed patterns" -msgstr "" -"Remove todos os arquivos correspondendo a qualquer um dos padrões listados" - -#: ../source/guides/using-manifest-in.rst:71 -msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" -msgstr ":samp:`recursive-include {padrão-dir} {padrão1} {padrão2} ...`" - -#: ../source/guides/using-manifest-in.rst:71 -msgid "" -"Add all files under directories matching ``dir-pattern`` that match any of " -"the listed patterns" -msgstr "" -"Adiciona todos os arquivos sob diretórios correspondendo a ``padrão-dir`` " -"que correspondem a qualquer um dos padrões listados" - -#: ../source/guides/using-manifest-in.rst:72 -msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" -msgstr ":samp:`recursive-exclude {padrão-dir} {padrão1} {padrão2} ...`" - -#: ../source/guides/using-manifest-in.rst:72 -msgid "" -"Remove all files under directories matching ``dir-pattern`` that match any " -"of the listed patterns" -msgstr "" -"Remove todos os arquivos sob diretórios correspondendo a ``padrão-dir`` que " -"correspondem a qualquer um dos padrões listados" - -#: ../source/guides/using-manifest-in.rst:73 -msgid ":samp:`global-include {pat1} {pat2} ...`" -msgstr ":samp:`global-include {padrão1} {padrão2} ...`" - -#: ../source/guides/using-manifest-in.rst:73 -msgid "" -"Add all files anywhere in the source tree matching any of the listed patterns" -msgstr "" -"Adiciona todos os arquivos em qualquer lugar na árvore de fontes que " -"correspondam a qualquer um dos padrões listados" - -#: ../source/guides/using-manifest-in.rst:74 -msgid ":samp:`global-exclude {pat1} {pat2} ...`" -msgstr ":samp:`global-exclude {padrão1} {padrão2} ...`" - -#: ../source/guides/using-manifest-in.rst:74 -msgid "" -"Remove all files anywhere in the source tree matching any of the listed " -"patterns" -msgstr "" -"Remove todos os arquivos de qualquer lugar na árvore de fontes que " -"correspondam a qualquer um dos padrões listados" - -#: ../source/guides/using-manifest-in.rst:75 -msgid ":samp:`graft {dir-pattern}`" -msgstr ":samp:`graft {padrão-dir}`" - -#: ../source/guides/using-manifest-in.rst:75 -msgid "Add all files under directories matching ``dir-pattern``" -msgstr "" -"Adiciona todos os arquivos sob diretórios correspondendo a ``padrão-dir``" - -#: ../source/guides/using-manifest-in.rst:76 -msgid ":samp:`prune {dir-pattern}`" -msgstr ":samp:`prune {padrão-dir}`" - -#: ../source/guides/using-manifest-in.rst:76 -msgid "Remove all files under directories matching ``dir-pattern``" -msgstr "" -"Remove todos os arquivos sob diretórios correspondendo a ``padrão-dir``" - -#: ../source/guides/using-manifest-in.rst:79 -msgid "" -"The patterns here are glob-style patterns: ``*`` matches zero or more " -"regular filename characters (on Unix, everything except forward slash; on " -"Windows, everything except backslash and colon); ``?`` matches a single " -"regular filename character, and ``[chars]`` matches any one of the " -"characters between the square brackets (which may contain character ranges, " -"e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented " -"support for ``**`` matching zero or more characters including forward slash, " -"backslash, and colon." -msgstr "" -"Os padrões aqui são padrões do estilo glob: ``*`` corresponde a zero ou mais " -"caracteres de nome de arquivo regulares (no Unix, tudo exceto barra; no " -"Windows, tudo exceto barra invertida e dois pontos); ``?`` corresponde a um " -"único caractere de nome de arquivo regular, e ``[chars]`` corresponde a " -"qualquer um dos caracteres entre os colchetes (que podem conter intervalos " -"de caracteres, por exemplo, ``[az]`` ou ``[ a-fA-F0-9]``). Setuptools também " -"oferece suporte não documentado a ``**`` correspondendo a zero ou mais " -"caracteres, incluindo barra, barra invertida e dois pontos." - -#: ../source/guides/using-manifest-in.rst:87 -msgid "" -"Directory patterns are relative to the root of the project directory; e.g., " -"``graft example*`` will include a directory named :file:`examples` in the " -"project root but will not include :file:`docs/examples/`." -msgstr "" -"Os padrões de diretório são relativos à raiz do diretório do projeto; por " -"exemplo, ``graft exemplo*`` incluirá um diretório chamado :file:`exemplos` " -"na raiz do projeto, mas não incluirá :file:`docs/exemplos/`." - -#: ../source/guides/using-manifest-in.rst:91 -msgid "" -"File & directory names in :file:`MANIFEST.in` should be ``/``-separated; " -"setuptools will automatically convert the slashes to the local platform's " -"appropriate directory separator." -msgstr "" -"Nomes de arquivos e diretórios em :file:`MANIFEST.in` devem ser separados " -"por ``/``; setuptools irá converter automaticamente as barras para o " -"separador de diretório apropriado da plataforma local." - -#: ../source/guides/using-manifest-in.rst:95 -msgid "" -"Commands are processed in the order they appear in the :file:`MANIFEST.in` " -"file. For example, given the commands::" -msgstr "" -"Os comandos são processados na ordem em que aparecem no arquivo :file:" -"`MANIFEST.in`. Por exemplo, dados os comandos ::" - -#: ../source/guides/using-manifest-in.rst:101 -msgid "" -"the contents of the directory tree :file:`tests` will first be added to the " -"sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, " -"or ``.pyd`` extension will be removed from the sdist. If the commands were " -"in the opposite order, then ``*.pyc`` files etc. would be only be removed " -"from what was already in the sdist before adding :file:`tests`, and if :file:" -"`tests` happened to contain any ``*.pyc`` files, they would end up included " -"in the sdist because the exclusion happened before they were included." -msgstr "" -"o conteúdo da árvore de diretórios :file:`tests` será primeiro adicionado ao " -"sdist, e depois disso todos os arquivos no sdist com uma extensão ``.pyc``, " -"``.pyo`` ou ``.pyd`` será removidos do sdist. Se os comandos estivessem na " -"ordem oposta, então os arquivos ``*.pyc`` etc. seriam removidos apenas do " -"que já estava no sdist antes de adicionar :file:`tests`, e se :file:`tests` " -"contivesse quaisquer arquivos ``*.pyc``, eles acabariam incluídos no sdist " -"porque a exclusão aconteceu antes de serem incluídos." - -#: ../source/guides/using-testpypi.rst:7 -msgid "" -"``TestPyPI`` is a separate instance of the :term:`Python Package Index " -"(PyPI)` that allows you to try out the distribution tools and process " -"without worrying about affecting the real index. TestPyPI is hosted at `test." -"pypi.org `_" -msgstr "" -"``Test PyPI`` é uma instância separada do :term:`Python Package Index " -"(PyPI)` que permite que você experimente as ferramentas de distribuição e o " -"processo sem se preocupar em afetar o índice real. O TestPyPI está hospedado " -"em `test.pypi.org `_" - -#: ../source/guides/using-testpypi.rst:13 -msgid "Registering your account" -msgstr "Registrando sua conta" - -#: ../source/guides/using-testpypi.rst:15 -msgid "" -"Because TestPyPI has a separate database from the live PyPI, you'll need a " -"separate user account for specifically for TestPyPI. Go to https://test.pypi." -"org/account/register/ to register your account." -msgstr "" -"Como o TestPyPI tem um banco de dados separado do PyPI real, você precisará " -"de uma conta de usuário separada especificamente para o TestPyPI. Vá para " -"https://test.pypi.org/account/register/ para registrar sua conta." - -#: ../source/guides/using-testpypi.rst:19 -msgid "" -"The database for TestPyPI may be periodically pruned, so it is not unusual " -"for user accounts to be deleted." -msgstr "" -"O banco de dados do TestPyPI pode ser apagado periodicamente, portanto, não " -"é incomum que contas de usuário sejam excluídas." - -#: ../source/guides/using-testpypi.rst:24 -msgid "Using TestPyPI with Twine" -msgstr "Usando TestPyPI com Twine" - -#: ../source/guides/using-testpypi.rst:26 -msgid "" -"You can upload your distributions to TestPyPI using :ref:`twine` by " -"specifying the ``--repository`` flag" -msgstr "" -"Você pode enviar suas distribuições para TestPyPI usando :ref:`twine` " -"especificando o sinalizador ``--repository``" - -#: ../source/guides/using-testpypi.rst:33 -msgid "" -"You can see if your package has successfully uploaded by navigating to the " -"URL ``https://test.pypi.org/project/`` where " -"``sampleproject`` is the name of your project that you uploaded. It may take " -"a minute or two for your project to appear on the site." -msgstr "" -"Você pode ver se o seu pacote foi enviado com sucesso navegando para a URL " -"``https://test.pypi.org/project/`` onde ``projetoexemplo`` é " -"o nome do seu projeto que você enviou. O seu projeto pode demorar um ou dois " -"minutos para aparecer no site." - -#: ../source/guides/using-testpypi.rst:39 -msgid "Using TestPyPI with pip" -msgstr "Usando TestPyPI com pip" - -#: ../source/guides/using-testpypi.rst:41 -msgid "" -"You can tell pip to download packages from TestPyPI instead of PyPI by " -"specifying the ``--index-url`` flag" -msgstr "" -"Você pode dizer ao pip para baixar pacotes do TestPyPI, em vez d0 PyPI, " -"especificando o sinalizador ``--index-url``" - -#: ../source/guides/using-testpypi.rst:56 -msgid "" -"If you want to allow pip to also pull other packages from PyPI you can " -"specify ``--extra-index-url`` to point to PyPI. This is useful when the " -"package you're testing has dependencies:" -msgstr "" -"Se você quiser permitir que pip também extraia outros pacotes de PyPI, você " -"pode especificar ``--extra-index-url`` para apontar para PyPI. Isso é útil " -"quando o pacote que você está testando tem dependências:" - -#: ../source/guides/using-testpypi.rst:73 -msgid "Setting up TestPyPI in :file:`.pypirc`" -msgstr "Configurando TestPyPI no :file:`.pypirc`" - -#: ../source/guides/using-testpypi.rst:75 -msgid "" -"If you want to avoid entering your username, you can configure TestPyPI in " -"your :file:`$HOME/.pypirc`:" -msgstr "" -"Se você quiser evitar de ter que inserir seu nome de usuário, pode " -"configurar o TestPyPI em seu :file:`$HOME/.pypirc`:" - -#: ../source/index.rst:3 ../source/key_projects.rst:181 -msgid "Python Packaging User Guide" -msgstr "Guia de Usuário para Empacotamento de Python" - -#: ../source/index.rst:5 -msgid "" -"The Python Packaging User Guide (PyPUG) is a collection of tutorials and " -"guides for packaging Python software." -msgstr "" -"O Guia de Usuário para Empacotamento de Python (PyPUG) é uma coleção de " -"tutoriais e guias para empacotar software Python." - -#: ../source/index.rst:5 -msgid "python, packaging, guide, tutorial" -msgstr "python, packaging, guide, tutorial, empacotamento, guia" - -#: ../source/index.rst:24 -msgid "" -"Welcome to the *Python Packaging User Guide*, a collection of tutorials and " -"references to help you distribute and install Python packages with modern " -"tools." -msgstr "" -"Seja bem-vindo(a) ao *Guia de Usuário para Empacotamento de Python*, uma " -"coleção de tutoriais e referências para lhe ajudar a distribuir e instalar " -"pacotes Python com ferramentas modernas." - -#: ../source/index.rst:28 -msgid "" -"This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. " -"We happily accept any :doc:`contributions and feedback `. 😊" -msgstr "" -"Este guia é mantido no `GitHub`_ pela `Python Packaging Authority`_. " -"Aceitamos quaisquer :doc:`contribuições e feedback `. 😊" - -#: ../source/index.rst:36 -msgid "Get started" -msgstr "Primeiros passos" - -#: ../source/index.rst:38 -msgid "" -"Essential tools and concepts for working within the Python development " -"ecosystem are covered in our :doc:`tutorials/index` section:" -msgstr "" -"Ferramentas e conceitos essenciais para trabalhar dentro do ecossistema de " -"desenvolvimento do Python são abordados em nossa seção de :doc:`tutorials/" -"index`:" - -#: ../source/index.rst:41 -msgid "" -"To learn how to install packages, see the :doc:`tutorial on installing " -"packages `" -msgstr "" -"Para saber como instalar pacotes, veja o :doc:`tutorial sobre como instalar " -"pacotes `" - -#: ../source/index.rst:43 -msgid "" -"To learn how to manage dependencies in a version controlled project, see " -"the :doc:`tutorial on managing application dependencies `" -msgstr "" -"Para saber como gerenciar dependências em um projeto controlador por versão, " -"veja o :doc:`tutorial sobre como gerenciar dependências de aplicações " -"`" - -#: ../source/index.rst:45 -msgid "" -"To learn how to package and distribute your projects, see the :doc:`tutorial " -"on packaging and distributing `" -msgstr "" -"Para saber como empacotar e distribuir seus projetos, veja o :doc:`tutorial " -"sobre como empacotar e distribuir `" - -#: ../source/index.rst:47 -msgid "" -"To get an overview of packaging options for Python libraries and " -"applications, see the :doc:`Overview of Python Packaging `" -msgstr "" -"Para obter uma visão geral das opções de empacotamento para bibliotecas e " -"aplicações Python, veja a :doc:`Visão geral de empacotamento no Python " -"`" - -#: ../source/index.rst:52 -msgid "Learn more" -msgstr "Saiba mais" - -#: ../source/index.rst:54 -msgid "" -"Beyond our :doc:`tutorials/index`, this guide has several other resources:" -msgstr "" -"Além de nossos :doc:`tutorials/index`, este guia possui vários outros " -"recursos:" - -#: ../source/index.rst:56 -msgid "" -"The :doc:`guides/index` section for walk throughs, such as :doc:`guides/" -"installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." -msgstr "" -"A seção :doc:`guides/index` para passos a passos, tal como :doc:`guides/" -"installing-using-linux-tools` ou :doc:`guides/packaging-binary-extensions`." - -#: ../source/index.rst:58 -msgid "" -"The :doc:`discussions/index` section for in-depth references on topics such " -"as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-" -"vs-easy-install`." -msgstr "" -"A seção :doc:`discussions/index` para referências detalhadas sobre tópicos " -"como :doc:`discussions/deploying-python-applications` ou :doc:`discussions/" -"pip-vs-easy-install`." - -#: ../source/index.rst:60 -msgid "" -"The :doc:`specifications/index` section for packaging interoperability " -"specifications." -msgstr "" -"A seção :doc:`specifications/index` para especificações de " -"interoperabilidade de empacotamento." - -#: ../source/index.rst:62 -msgid "" -"Additionally, there is a list of :doc:`other projects ` " -"maintained by members of the Python Packaging Authority." -msgstr "" -"Além disso, há uma lista de :doc:`outros projetos ` mantidos " -"por membros da Python Packaging Authority." - -#: ../source/key_projects.rst:6 -msgid "Project Summaries" -msgstr "Resumos de projetos" - -#: ../source/key_projects.rst:8 -msgid "" -"Summaries and links for the most relevant projects in the space of Python " -"installation and packaging." -msgstr "" -"Resumos e links para os projetos mais relevantes no espaço de instalação e " -"empacotamento do Python." - -#: ../source/key_projects.rst:14 -msgid "PyPA Projects" -msgstr "Projetos do PyPA" - -#: ../source/key_projects.rst:19 -msgid "bandersnatch" -msgstr "bandersnatch" - -#: ../source/key_projects.rst:21 -msgid "" -"`Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`Issues `__ | `GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:25 -msgid "" -"``bandersnatch`` is a PyPI mirroring client designed to efficiently create a " -"complete mirror of the contents of PyPI. Organizations thus save bandwidth " -"and latency on package downloads (especially in the context of automated " -"tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." -msgstr "" -"``bandersnatch`` é um cliente de espelhamento do PyPI projetado para criar " -"de forma eficiente um espelho completo do conteúdo do PyPI. Assim, as " -"organizações economizam largura de banda e latência nos downloads de pacotes " -"(especialmente no contexto de testes automatizados) e evitam o carregamento " -"excessivo da Content Delivery Network (CDN) do PyPI." - -#: ../source/key_projects.rst:35 -msgid "build" -msgstr "construir" - -#: ../source/key_projects.rst:37 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI " -"`__" -msgstr "" -"`Documentação `__ | `Issues `__ | `GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:42 -msgid "" -"``build`` is a :pep:`517` compatible Python package builder. It provides a " -"CLI to build packages, as well as a Python API." -msgstr "" -"``build`` é um construtor de pacotes Python compatível com a :pep:`517`. Ele " -"fornece uma CLI para construir pacotes, bem como uma API Python." - -#: ../source/key_projects.rst:49 -msgid "cibuildwheel" -msgstr "cibuildwheel" - -#: ../source/key_projects.rst:51 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | " -"`Discussions `__ | " -"`Discord #cibuildwheel `__" -msgstr "" -"`Documentação `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | " -"`Discussões `__ | `Discord " -"#cibuildwheel `__" - -#: ../source/key_projects.rst:58 -msgid "" -"``cibuildwheel`` is a Python package that builds :term:`wheels ` for " -"all common platforms and Python versions on most CI systems. Also see :ref:" -"`multibuild`." -msgstr "" -"``cibuildwheel`` é um pacote Python que constrói :term:`wheels ` para " -"todas as plataformas comuns e versões Python na maioria dos sistemas CI. " -"Veja também :ref:`multibuild`." - -#: ../source/key_projects.rst:64 -msgid "distlib" -msgstr "distlib" - -#: ../source/key_projects.rst:66 -msgid "" -"`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" -msgstr "" -"`Documentação `__ | `Issues `__ | `Bitbucket " -"`__ | `PyPI `__" - -#: ../source/key_projects.rst:71 -msgid "" -"``distlib`` is a library which implements low-level functions that relate to " -"packaging and distribution of Python software. ``distlib`` implements " -"several relevant PEPs (Python Enhancement Proposal standards) and is useful " -"for developers of third-party packaging tools to make and upload binary and " -"source :term:`distributions `, achieve " -"interoperability, resolve dependencies, manage package resources, and do " -"other similar functions." -msgstr "" -"``distlib`` é uma biblioteca que implementa funções de baixo nível " -"relacionadas ao empacotamento e distribuição de software Python. ``distlib`` " -"implementa várias PEPs relevantes (padrões de proposta de aprimoramento do " -"Python) e é útil para desenvolvedores de ferramentas de empacotamento de " -"terceiros para fazer e enviar :term:`distribuições ` " -"binária e fonte, alcançar interoperabilidade, resolver dependências, " -"gerenciar recursos de pacote e executar outras funções semelhantes." - -#: ../source/key_projects.rst:80 -msgid "" -"Unlike the stricter :ref:`packaging` project (below), which specifically " -"implements modern Python packaging interoperability standards, ``distlib`` " -"also attempts to provide reasonable fallback behaviours when asked to handle " -"legacy packages and metadata that predate the modern interoperability " -"standards and fall into the subset of packages that are incompatible with " -"those standards." -msgstr "" -"Ao contrário do projeto :ref:`packaging` mais estrito (abaixo), que " -"implementa especificamente padrões modernos de interoperabilidade de pacotes " -"Python, ``distlib`` também tenta fornecer comportamentos de fallback " -"razoáveis quando solicitados a lidar com pacotes legados e metadados " -"anteriores à interoperabilidade moderna padrões e se enquadram no " -"subconjunto de pacotes que são incompatíveis com esses padrões." - -#: ../source/key_projects.rst:90 -msgid "packaging" -msgstr "empacotamento" - -#: ../source/key_projects.rst:92 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" -"`Documentação `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" - -#: ../source/key_projects.rst:97 -msgid "" -"Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." -msgstr "" -"Utilitários básicos para o empacotamento do Python usado por :ref:`pip` e :" -"ref:`setuptools`." - -#: ../source/key_projects.rst:99 -msgid "" -"The core utilities in the packaging library handle version handling, " -"specifiers, markers, requirements, tags, and similar attributes and tasks " -"for Python packages. Most Python users rely on this library without needing " -"to explicitly call it; developers of the other Python packaging, " -"distribution, and installation tools listed here often use its functionality " -"to parse, discover, and otherwise handle dependency attributes." -msgstr "" -"Os utilitários principais na biblioteca de empacotamento lidam com " -"manipulação de versão, especificadores, marcadores, requisitos, tags e " -"atributos e tarefas semelhantes para pacotes Python. A maioria dos usuários " -"Python confia nesta biblioteca sem precisar chamá-la explicitamente; os " -"desenvolvedores de outras ferramentas de empacotamento, distribuição e " -"instalação Python listadas aqui geralmente usam sua funcionalidade para " -"analisar, descobrir e, de outra forma, lidar com atributos de dependência." - -#: ../source/key_projects.rst:107 -msgid "" -"This project specifically focuses on implementing the modern Python " -"packaging interoperability standards defined at :ref:`packaging-" -"specifications`, and will report errors for sufficiently old legacy packages " -"that are incompatible with those standards. In contrast, the :ref:`distlib` " -"project is a more permissive library that attempts to provide a plausible " -"reading of ambiguous metadata in cases where :ref:`packaging` will instead " -"report on error." -msgstr "" -"Este projeto foca especificamente na implementação dos padrões modernos de " -"interoperabilidade de pacotes Python definidos em :ref:`packaging-" -"specifications`, e irá relatar erros para pacotes legados suficientemente " -"antigos que são incompatíveis com esses padrões. Em contraste, o projeto :" -"ref:`distlib` é uma biblioteca mais permissiva que tenta fornecer uma " -"leitura plausível de metadados ambíguos em casos onde :ref:`packaging` irá " -"relatar um erro." - -#: ../source/key_projects.rst:119 -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "pip" -msgstr "pip" - -#: ../source/key_projects.rst:121 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`Documentação `__ | `Issues `__ | `GitHub `__ | `PyPI " -"`__" - -#: ../source/key_projects.rst:126 -msgid "" -"The most popular tool for installing Python packages, and the one included " -"with modern versions of Python." -msgstr "" -"A ferramenta mais popular para instalação de pacotes Python e incluída nas " -"versões modernas do Python." - -#: ../source/key_projects.rst:129 -msgid "" -"It provides the essential core features for finding, downloading, and " -"installing packages from PyPI and other Python package indexes, and can be " -"incorporated into a wide range of development workflows via its command-line " -"interface (CLI)." -msgstr "" -"Ele fornece os recursos básicos essenciais para localizar, baixar e instalar " -"pacotes do PyPI e outros índices de pacotes do Python e pode ser incorporado " -"em uma ampla gama de fluxos de trabalho de desenvolvimento por meio de sua " -"interface de linha de comando (CLI)." - -#: ../source/key_projects.rst:137 -msgid "Pipenv" -msgstr "Pipenv" - -#: ../source/key_projects.rst:139 -msgid "" -"`Docs `__ | `Source `__ | `Issues `__ | `PyPI " -"`__" -msgstr "" -"`Documentação `__ | `Código-fonte `__ | `Issues `__ | " -"`PyPI `__" - -#: ../source/key_projects.rst:144 -msgid "" -"Pipenv is a project that aims to bring the best of all packaging worlds to " -"the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:" -"`virtualenv` into one single toolchain. It features very pretty terminal " -"colors." -msgstr "" -"Pipenv é um projeto que visa trazer o melhor de todos os mundos de " -"empacotamento para o mundo Python. Ele agrega :ref:`Pipfile`, :ref:`pip` e :" -"ref:`virtualenv` em um único conjunto de ferramentas. Possui cores de " -"terminal muito bonitas." - -#: ../source/key_projects.rst:148 -msgid "" -"Pipenv aims to help users manage environments, dependencies, and imported " -"packages on the command line. It also works well on Windows (which other " -"tools often underserve), makes and checkes file hashes, to ensure compliance " -"with hash-locked dependency specifiers, and eases uninstallation of packages " -"and dependencies. It is used by Python users and system administrators, but " -"has been less maintained since late 2018." -msgstr "" -"O Pipenv visa ajudar os usuários a gerenciar ambientes, dependências e " -"pacotes importados na linha de comando. Ele também funciona bem no Windows " -"(que outras ferramentas muitas vezes não atendem), cria e verifica hashes de " -"arquivo, para garantir a conformidade com especificadores de dependência " -"bloqueados por hash e facilita a desinstalação de pacotes e dependências. " -"Ele é usado por usuários Python e administradores de sistema, mas tem menos " -"manutenção desde o final de 2018." - -#: ../source/key_projects.rst:159 -msgid "Pipfile" -msgstr "Pipfile" - -#: ../source/key_projects.rst:161 -msgid "`Source `__" -msgstr "`Código-fonte `__" - -#: ../source/key_projects.rst:163 -msgid "" -":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level " -"application-centric alternative to :ref:`pip`'s lower-level :file:" -"`requirements.txt` file." -msgstr "" -":file:`Pipfile` e sua irmã :file:`Pipfile.lock` são uma alternativa centrada " -"na aplicação de nível superior ao arquivo de baixo nível :file:`requirements." -"txt` do :ref:`pip`." - -#: ../source/key_projects.rst:170 -msgid "pipx" -msgstr "pipx" - -#: ../source/key_projects.rst:172 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`Documentação `__ | `GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:176 -msgid "" -"pipx is a tool to install and run Python command-line applications without " -"causing dependency conflicts with other packages installed on the system." -msgstr "" -"pipx é uma ferramenta para instalar e executar aplicações de linha de " -"comando Python sem causar conflitos de dependência com outros pacotes " -"instalados no sistema." - -#: ../source/key_projects.rst:183 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" -"`Documentação `__ | `Issues " -"`__ | `GitHub " -"`__" - -#: ../source/key_projects.rst:187 -msgid "This guide!" -msgstr "Este guia!" - -#: ../source/key_projects.rst:192 -msgid "readme_renderer" -msgstr "readme_renderer" - -#: ../source/key_projects.rst:194 -msgid "" -"`GitHub and docs `__ | `PyPI " -"`__" -msgstr "" -"`GitHub e documentação `__ | `PyPI " -"`__" - -#: ../source/key_projects.rst:197 -msgid "" -"``readme_renderer`` is a library that package developers use to render their " -"user documentation (README) files into HTML from markup languages such as " -"Markdown or reStructuredText. Developers call it on its own or via :ref:" -"`twine`, as part of their release management process, to check that their " -"package descriptions will properly display on PyPI." -msgstr "" -"``readme_renderer`` é uma biblioteca que os desenvolvedores de pacote usam " -"para renderizar seus arquivos de documentação de usuário (README) no HTML a " -"partir de linguagens de marcação como Markdown ou reStructuredText. Os " -"desenvolvedores o chamam por conta própria ou via :ref:`twine`, como parte " -"de seu processo de gerenciamento de lançamento, para verificar se as " -"descrições de seus pacotes serão exibidas corretamente no PyPI." - -#: ../source/key_projects.rst:208 -msgid "setuptools" -msgstr "setuptools" - -#: ../source/key_projects.rst:210 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`Documentação `__ | `Issues " -"`__ | `GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:215 -msgid "" -"setuptools (which includes ``easy_install``) is a collection of enhancements " -"to the Python distutils that allow you to more easily build and distribute " -"Python :term:`distributions `, especially ones that " -"have dependencies on other packages." -msgstr "" -"setuptools (que inclui ``easy_install``) é uma coleção de melhorias para os " -"distutils Python que permitem a você construir e distribuir mais facilmente :" -"term:`distribuições ` Python, especialmente aquelas " -"que possuem dependências de outros pacotes." - -#: ../source/key_projects.rst:220 -msgid "" -"`distribute`_ was a fork of setuptools that was merged back into setuptools " -"(in v0.7), thereby making setuptools the primary choice for Python packaging." -msgstr "" -"`distribute`_ era um fork do setuptools que foi mesclado no setuptools (na " -"v0.7), tornando assim setuptools a escolha primária para o empacotamento " -"Python." - -#: ../source/key_projects.rst:227 -msgid "trove-classifiers" -msgstr "trove-classifiers" - -#: ../source/key_projects.rst:229 -msgid "" -"`Issues `__ | `GitHub " -"`__ | `PyPI `__" -msgstr "" -"`Issues `__ | `GitHub " -"`__ | `PyPI `__" - -#: ../source/key_projects.rst:233 -msgid "" -"trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically " -"describe their projects `_ so that users can better find projects " -"that match their needs on the PyPI." -msgstr "" -"trove-classifiers é a fonte canônica para `classificadores no PyPI `_, que os mantenedores de projetos usam para " -"`descrever sistematicamente seus projetos `_ para que os " -"usuários possam encontrar melhor os projetos que correspondem às suas " -"necessidades no PyPI." - -#: ../source/key_projects.rst:239 -msgid "" -"The trove-classifiers package contains a list of valid classifiers and " -"deprecated classifiers (which are paired with the classifiers that replace " -"them). Use this package to validate classifiers used in packages intended " -"for uploading to PyPI. As this list of classifiers is published as code, you " -"can install and import it, giving you a more convenient workflow compared to " -"referring to the `list published on PyPI `_. " -"The `issue tracker `_ for " -"the project hosts discussions on proposed classifiers and requests for new " -"classifiers." -msgstr "" -"O pacote trove-classifiers contém uma lista de classificadores válidos e " -"classificadores descontinuados (que são pareados com os classificadores que " -"os substituem). Use este pacote para validar classificadores usados em " -"pacotes destinados ao envio para o PyPI. Como esta lista de classificadores " -"é publicada como código, você pode instalá-la e importá-la, proporcionando " -"um fluxo de trabalho mais conveniente em comparação com a referência à " -"`lista publicada em PyPI `_. O `rastreador de " -"problemas `_ para o " -"projeto hospeda discussões sobre classificadores propostos e solicitações de " -"novos classificadores." - -#: ../source/key_projects.rst:253 -msgid "twine" -msgstr "twine" - -#: ../source/key_projects.rst:255 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" -"`Documentação `__ | `Issues " -"`__ | `GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:260 -msgid "" -"Twine is the primary tool developers use to upload packages to the Python " -"Package Index or other Python package indexes. It is a command-line program " -"that passes program files and metadata to a web API. Developers use it " -"because it's the official PyPI upload tool, it's fast and secure, it's " -"maintained, and it reliably works." -msgstr "" -"Twine é a principal ferramenta que os desenvolvedores usam para enviar " -"pacotes para o índice de pacotes Python ou outros Python Package Index. É um " -"programa de linha de comando que passa arquivos de programa e metadados para " -"uma API web. Os desenvolvedores o usam porque é a ferramenta oficial de " -"envio do PyPI, é rápida e segura, é mantida e funciona de forma confiável." - -#: ../source/key_projects.rst:270 ../source/overview.rst:415 -msgid "virtualenv" -msgstr "virtualenv" - -#: ../source/key_projects.rst:272 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`Documentação `__ | `Issues `__ | `GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:277 -msgid "" -"virtualenv is a tool which uses the command-line path environment variable " -"to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional " -"functionality, compared to :ref:`venv`, by supporting Python 2.7 and by " -"providing convenient features for configuring, maintaining, duplicating, and " -"troubleshooting the virtual environments. For more information, see the " -"section on :ref:`Creating and using Virtual Environments`." -msgstr "" -"virtualenv é uma ferramenta que usa a variável de ambiente de caminho de " -"linha de comando para criar :term:`Ambientes Virtuais ` " -"do Python, assim como :ref:`venv` faz. virtualenv fornece funcionalidade " -"adicional, em comparação com :ref:`venv`, oferecendo suporte ao Python 2.7 e " -"fornecendo recursos convenientes para configurar, manter, duplicar e " -"solucionar problemas de ambientes virtuais. Para obter mais informações, " -"consulte a seção sobre :ref:`Creating and using Virtual Environments`." - -#: ../source/key_projects.rst:290 -msgid "Warehouse" -msgstr "Warehouse" - -#: ../source/key_projects.rst:292 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" -"`Documentação `__ | `Issues `__ | `GitHub `__" - -#: ../source/key_projects.rst:296 -msgid "" -"The current codebase powering the :term:`Python Package Index (PyPI)`. It is " -"hosted at `pypi.org `_. The default source for :ref:`pip` " -"downloads." -msgstr "" -"A base de código atual que alimenta o :term:`Python Package Index (PyPI)`. " -"Está hospedado em `pypi.org `_. A fonte padrão para " -"downloads do :ref:`pip`." - -#: ../source/key_projects.rst:304 -msgid "wheel" -msgstr "wheel" - -#: ../source/key_projects.rst:306 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" -"`Documentação `__ | `Issues " -"`__ | `GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:311 -msgid "" -"Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` " -"extension for creating :term:`wheel distributions `. Additionally, " -"it offers its own command line utility for creating and installing wheels." -msgstr "" -"Primeiramente, o projeto wheel oferece a extensão ``bdist_wheel`` do :ref:" -"`setuptools` para criar :term:`distribuições wheel `. Além disso, " -"oferece seu próprio utilitário de linha de comando para criar e instalar " -"wheels." - -#: ../source/key_projects.rst:315 -msgid "" -"See also `auditwheel `__, a tool that " -"package developers use to check and fix Python packages they are making in " -"the binary wheel format. It provides functionality to discover dependencies, " -"check metadata for compliance, and repair the wheel and metadata to properly " -"link and include external shared libraries in a package." -msgstr "" -"Veja também `auditwheel `__, uma " -"ferramenta que os desenvolvedores de pacotes usam para verificar e corrigir " -"pacotes Python que eles estão fazendo no formato de roda binária. Ele " -"fornece funcionalidade para descobrir dependências, verificar a conformidade " -"dos metadados e corrigir wheel e os metadados para vincular e incluir " -"bibliotecas externas compartilhadas em um pacote." - -#: ../source/key_projects.rst:324 -msgid "Non-PyPA Projects" -msgstr "Projetos não-PyPA" - -#: ../source/key_projects.rst:329 -msgid "bento" -msgstr "bento" - -#: ../source/key_projects.rst:331 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" -"`Documentação `__ | `Issues `__ | `GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:336 -msgid "" -"Bento is a packaging tool solution for Python software, targeted as an " -"alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's " -"philosophy is reproducibility, extensibility and simplicity (in that order)." -msgstr "" -"Bento é uma solução de ferramenta de empacotamento para software Python, " -"direcionada como uma alternativa ao :ref:`distutils`, :ref:`setuptools `, " -"etc. A filosofia do Bento é reprodutibilidade, extensibilidade e " -"simplicidade (nesta ordem)." - -#: ../source/key_projects.rst:344 -msgid "buildout" -msgstr "buildout" - -#: ../source/key_projects.rst:346 -msgid "" -"`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" -msgstr "" -"`Documentação `__ | `Issues `__ | `PyPI `__ | `GitHub `__" - -#: ../source/key_projects.rst:351 -msgid "" -"Buildout is a Python-based build system for creating, assembling and " -"deploying applications from multiple parts, some of which may be non-Python-" -"based. It lets you create a buildout configuration and reproduce the same " -"software later." -msgstr "" -"Buildout é um sistema de construção baseado em Python para criar, montar e " -"distribuir aplicações de várias partes, algumas das quais podem ser não " -"baseadas em Python. Ele permite que você crie uma configuração de buildout e " -"reproduza o mesmo software posteriormente." - -#: ../source/key_projects.rst:358 -msgid "conda" -msgstr "conda" - -#: ../source/key_projects.rst:360 -msgid "`Docs `__" -msgstr "`Documentação `__" - -#: ../source/key_projects.rst:362 -msgid "" -"conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution " -"from `Anaconda, Inc `__ specifically " -"aimed at the scientific community, and in particular on Windows where the " -"installation of binary extensions is often difficult." -msgstr "" -"conda é a ferramenta de gerenciamento de pacotes para as instalações do " -"`Anaconda `__ Python . Anaconda Python " -"é uma distribuição do `Anaconda, Inc `__ " -"voltada especificamente para a comunidade científica, e em particular no " -"Windows onde a instalação de extensões binárias é frequentemente difícil ." - -#: ../source/key_projects.rst:369 -msgid "" -"Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, " -"but provides many of their combined features in terms of package management, " -"virtual environment management and deployment of binary extensions." -msgstr "" -"Conda é uma ferramenta completamente separada de :ref:`pip`, virtualenv e " -"wheel, mas fornece muitos de seus recursos combinados em termos de " -"gerenciamento de pacotes, gerenciamento de ambiente virtual e implantação de " -"extensões binárias." - -#: ../source/key_projects.rst:373 -msgid "" -"Conda does not install packages from PyPI and can install only from the " -"official Anaconda repositories, or anaconda.org (a place for user-" -"contributed *conda* packages), or a local (e.g. intranet) package server. " -"However, note that :ref:`pip` can be installed into, and work side-by-side " -"with conda for managing :term:`distributions ` from " -"PyPI. Also, `conda skeleton `__ is a tool to make " -"Python packages installable by conda by first fetching them from PyPI and " -"modifying their metadata." -msgstr "" -"O Conda não instala pacotes do PyPI e pode instalar apenas a partir dos " -"repositórios oficiais do Anaconda, ou anaconda.org (um local para pacotes " -"*conda* contribuídos pelo usuário), ou um servidor de pacotes local (por " -"exemplo, intranet). No entanto, observe que :ref:`pip` pode ser instalado e " -"trabalhar lado a lado com o conda para gerenciar :term:`distribuições " -"` do PyPI. Além disso, `conda skeleton `__ é uma ferramenta para fazer pacotes Python instaláveis " -"pelo conda primeiro obtendo-os em PyPI e modificando seus metadados." - -#: ../source/key_projects.rst:386 -msgid "devpi" -msgstr "devpi" - -#: ../source/key_projects.rst:388 -msgid "" -"`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" -"`Documentação `__ | `Issues `__ | `PyPI `__" - -#: ../source/key_projects.rst:392 -msgid "" -"devpi features a powerful PyPI-compatible server and PyPI proxy cache with a " -"complementary command line tool to drive packaging, testing and release " -"activities with Python. devpi also provides a browsable and searchable web " -"interface." -msgstr "" -"devpi apresenta um poderoso servidor compatível com PyPI e cache de proxy " -"PyPI com uma ferramenta de linha de comando complementar para conduzir " -"atividades de empacotamento, teste e lançamento com Python. devpi também " -"fornece uma interface web navegável e pesquisável." - -#: ../source/key_projects.rst:401 -msgid "flit" -msgstr "flit" - -#: ../source/key_projects.rst:403 -msgid "" -"`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" -"`Documentação `__ | `Issues `__ | `PyPI `__" - -#: ../source/key_projects.rst:407 -msgid "" -"Flit provides a simple way to upload pure Python packages and modules to " -"PyPI. It focuses on `making the easy things easy `_ for " -"packaging. Flit can generate a configuration file to quickly set up a simple " -"project, build source distributions and wheels, and upload them to PyPI." -msgstr "" -"O Flit fornece uma maneira simples de enviar pacotes e módulos puro Python " -"para o PyPI. Ele se concentra em `facilitar as coisas fáceis `_ para empacotar. O Flit pode gerar um arquivo de configuração " -"para configurar rapidamente um projeto simples, construir distribuições " -"fonte e wheels e enviá-los para PyPI." - -#: ../source/key_projects.rst:412 -msgid "" -"Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on " -"tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to " -"upload them to PyPI. Flit requires Python 3, but you can use it to " -"distribute modules for Python 2, so long as they can be imported on Python 3." -msgstr "" -"Flit usa ``pyproject.toml`` para configurar um projeto. O Flit não depende " -"de ferramentas como :ref:`setuptools` para construir distribuições, ou :ref:" -"`twine` para enviá-las ao PyPI. O Flit requer Python 3, mas você pode usá-lo " -"para distribuir módulos para Python 2, desde que eles possam ser importados " -"no Python 3." - -#: ../source/key_projects.rst:422 -msgid "enscons" -msgstr "enscons" - -#: ../source/key_projects.rst:424 -msgid "" -"`Source `__ | `Issues `__ | `PyPI `__" -msgstr "" -"`Código-fonte `__ | `Issues " -"`__ | `PyPI `__" - -#: ../source/key_projects.rst:428 -msgid "" -"Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-" -"compatible source distributions and wheels without using distutils or " -"setuptools, including distributions with C extensions. Enscons has a " -"different architecture and philosophy than :ref:`distutils`. Rather than " -"adding build features to a Python packaging system, enscons adds Python " -"packaging to a general purpose build system. Enscons helps you to build " -"sdists that can be automatically built by :ref:`pip`, and wheels that are " -"independent of enscons." -msgstr "" -"Enscons é uma ferramenta de empacotamento Python baseada em `SCons`_. Ele " -"cria distribuições de código-fonte compatíveis com :ref:`pip` e wheels sem " -"usar distutils ou setuptools, incluindo distribuições com extensões C. " -"Enscons tem uma arquitetura e filosofia diferente de :ref:`distutils`. Em " -"vez de adicionar recursos de compilação a um sistema de empacotamento " -"Python, enscons adiciona empacotamento Python a um sistema de construção de " -"propósito geral. Enscons ajuda você a construir sdists que podem ser " -"construídos automaticamente por :ref:`pip`, e wheels que são independentes " -"de enscons." - -#: ../source/key_projects.rst:443 -msgid "Hashdist" -msgstr "Hashdist" - -#: ../source/key_projects.rst:445 -msgid "" -"`Docs `__ | `GitHub `__" -msgstr "" -"`Documentação `__ | `GitHub " -"`__" - -#: ../source/key_projects.rst:448 -msgid "" -"Hashdist is a library for building non-root software distributions. Hashdist " -"is trying to be “the Debian of choice for cases where Debian technology " -"doesn’t work”. The best way for Pythonistas to think about Hashdist may be a " -"more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed " -"at solving the problem of installing scientific software, and making package " -"distribution stateless, cached, and branchable. It is used by some " -"researchers but has been lacking in maintenance since 2016." -msgstr "" -"Hashdist é uma biblioteca para construir distribuições de software que não " -"dependem do root. Hashdist está tentando ser \"o preferido do Debian para os " -"casos em que a tecnologia Debian não funciona\". A melhor maneira para " -"Pythonistas pensarem sobre Hashdist pode ser um híbrido mais poderoso de :" -"ref:`virtualenv` e :ref:`buildout`. Ele tem como objetivo resolver o " -"problema de instalação de software científico e tornar a distribuição de " -"pacotes sem estado, com cache e com capacidade de distribuição. É usado por " -"alguns pesquisadores, mas não tem manutenção desde 2016." - -#: ../source/key_projects.rst:460 -msgid "hatch" -msgstr "hatch" - -#: ../source/key_projects.rst:462 -msgid "" -"`GitHub and Docs `__ | `PyPI `__" -msgstr "" -"`GitHub e documentação `__ | `PyPI `__" - -#: ../source/key_projects.rst:465 -msgid "" -"Hatch is a unified command-line tool meant to conveniently manage " -"dependencies and environment isolation for Python developers. Python package " -"developers use Hatch to configure, version, specify dependencies for, and " -"publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload " -"packages to PyPI, and :ref:`pip` to download and install packages." -msgstr "" -"Hatch é uma ferramenta de linha de comando unificada destinada a gerenciar " -"convenientemente dependências e isolamento de ambiente para desenvolvedores " -"Python. Os desenvolvedores de pacotes Python usam o Hatch para configurar, " -"criar versões, especificar dependências e publicar pacotes no PyPI. Por " -"baixo do capô, ele usa :ref:`twine` para enviar pacotes para PyPI, e :ref:" -"`pip` para baixar e instalar pacotes." - -#: ../source/key_projects.rst:475 -msgid "multibuild" -msgstr "multibuild" - -#: ../source/key_projects.rst:477 -msgid "`GitHub `__" -msgstr "`GitHub `__" - -#: ../source/key_projects.rst:479 -msgid "" -"Multibuild is a set of CI scripts for building and testing Python :term:" -"`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :" -"ref:`cibuildwheel`." -msgstr "" -"Multibuild é um conjunto de scripts de CI para construir e testar Python :" -"term:`wheels ` para Linux, macOS e (menos flexível) Windows. Veja " -"também :ref:`cibuildwheel`." - -#: ../source/key_projects.rst:485 -msgid "pex" -msgstr "pex" - -#: ../source/key_projects.rst:487 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`Documentação `__ | `GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:491 -msgid "" -"pex is both a library and tool for generating :file:`.pex` (Python " -"EXecutable) files, standalone Python environments in the spirit of :ref:" -"`virtualenv`. :file:`.pex` files are just carefully constructed zip files " -"with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are " -"designed to make deployment of Python applications as simple as ``cp``." -msgstr "" -"pex é uma biblioteca e ferramenta para gerar arquivos :file:`.pex` (Python " -"EXecutable), ambientes autônomos Python no espírito de :ref:`virtualenv`. Os " -"arquivos :file:`.pex` são apenas arquivos zip cuidadosamente construídos com " -"um ``#!/usr/bin/env python`` e um :file:`__main__.py` especial, e são " -"projetados para fazer a implantação de aplicações Python tão simples quanto " -"``cp``." - -#: ../source/key_projects.rst:500 -msgid "pip-tools" -msgstr "pip-tools" - -#: ../source/key_projects.rst:502 -msgid "" -"`GitHub and Docs `__ | `PyPI " -"`__" -msgstr "" -"`GitHub e documentação `__ | `PyPI " -"`__" - -#: ../source/key_projects.rst:505 -msgid "" -"pip-tools is a suite of tools meant for Python system administrators and " -"release managers who particularly want to keep their builds deterministic " -"yet stay up to date with new versions of their dependencies. Users can " -"specify particular release of their dependencies via hash, conveniently make " -"a properly formatted list of requirements from information in other parts of " -"their program, update all dependencies (a feature :ref:`pip` currently does " -"not provide), and create layers of constraints for the program to obey." -msgstr "" -"pip-tools é um conjunto de ferramentas destinadas aos administradores de " -"sistema Python e gerentes de lançamento que desejam manter suas compilações " -"determinísticas e, ao mesmo tempo, manter-se atualizado com as novas versões " -"de suas dependências. Os usuários podem especificar a liberação particular " -"de suas dependências por meio de hash, fazer convenientemente uma lista " -"devidamente formatada de requisitos de informações em outras partes de seu " -"programa, atualizar todas as dependências (um recurso :ref:`pip` atualmente " -"não fornece) e criar camadas de restrições para o programa obedecer." - -#: ../source/key_projects.rst:517 -msgid "piwheels" -msgstr "piwheels" - -#: ../source/key_projects.rst:519 -msgid "" -"`Website `__ | `Docs `__ | `GitHub `__" -msgstr "" -"`Site `__ | `Documentação `__ | `GitHub `__" - -#: ../source/key_projects.rst:523 -msgid "" -"piwheels is a website, and software underpinning it, that fetches source " -"code distribution packages from PyPI and compiles them into binary wheels " -"that are optimized for installation onto Raspberry Pi computers. Raspberry " -"Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." -msgstr "" -"piwheels é um site, e o software que o sustenta, que busca pacotes de " -"distribuição de código-fonte do PyPI e os compila em wheels binários que são " -"otimizadas para instalação em computadores Raspberry Pi. O Raspberry Pi OS " -"pré-configura pip para usar piwheels.org como um índice adicional para PyPI." - -#: ../source/key_projects.rst:532 -msgid "poetry" -msgstr "poetry" - -#: ../source/key_projects.rst:534 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`Documentação `__ | `GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:538 -msgid "" -"poetry is a command-line tool to handle dependency installation and " -"isolation as well as building and packaging of Python packages. It uses " -"``pyproject.toml`` and, instead of depending on the resolver functionality " -"within :ref:`pip`, provides its own dependency resolver. It attempts to " -"speed users' experience of installation and dependency resolution by locally " -"caching metadata about dependencies." -msgstr "" -"poetry é uma ferramenta de linha de comando para lidar com a instalação de " -"dependências e isolamento, bem como construção e empacotamento de pacotes " -"Python. Ele usa ``pyproject.toml`` e, ao invés de depender da funcionalidade " -"do resolvedor no :ref:`pip`, fornece seu próprio resolvedor de dependências. " -"Ele tenta acelerar a experiência dos usuários de instalação e resolução de " -"dependências, armazenando localmente em cache os metadados sobre as " -"dependências." - -#: ../source/key_projects.rst:548 -msgid "pypiserver" -msgstr "pypiserver" - -#: ../source/key_projects.rst:550 -msgid "" -"`Docs `__ | " -"`GitHub `__ | `PyPI `__" -msgstr "" -"`Documentação `__ | `GitHub `__ | `PyPI " -"`__" - -#: ../source/key_projects.rst:554 -msgid "" -"pypiserver is a minimalist application that serves as a private Python " -"package index within organizations, implementing a simple API and browser " -"interface. You can upload private packages using standard upload tools, and " -"users can download and install them with :ref:`pip`, without publishing them " -"publicly. Organizations who use pypiserver usually download packages both " -"from pypiserver and from PyPI." -msgstr "" -"pypiserver é uma aplicação minimalista que serve como um índice de pacotes " -"privado Python dentro das organizações, implementando uma API simples e uma " -"interface de navegador. Você pode enviar pacotes privados usando ferramentas " -"de envio padrão, e os usuários podem baixar e instalá-los com :ref:`pip`, " -"sem publicá-los publicamente. As organizações que usam o pypiserver " -"geralmente baixam pacotes tanto do pypiserver quanto do PyPI." - -#: ../source/key_projects.rst:564 -msgid "scikit-build" -msgstr "scikit-build" - -#: ../source/key_projects.rst:566 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`Documentação `__ | `GitHub " -"`__ | `PyPI `__" - -#: ../source/key_projects.rst:570 -msgid "" -"Scikit-build is an improved build system generator for CPython C/C++/Fortran/" -"Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :" -"ref:`pip`. It internally uses `cmake `__ " -"(available on PyPI) to provide better support for additional compilers, " -"build systems, cross compilation, and locating dependencies and their " -"associated build requirements. To speed up and parallelize the build of " -"large projects, the user can install `ninja `__ (also available on PyPI)." -msgstr "" -"Scikit-build é um gerador de sistema de construção aprimorado para extensões " -"C/C++/Fortran/Cython do CPython que se integra com :ref:`setuptools`, :ref:" -"`wheel` e :ref:`pip`. Ele usa internamente `cmake `__ (disponível em PyPI) para fornecer melhor suporte para " -"compiladores adicionais, sistemas de construção, compilação cruzada e " -"localização de dependências e seus requisitos de construção associados. Para " -"acelerar e paralelizar a construção de grandes projetos, o usuário pode " -"instalar o `ninja `__ (também disponível no " -"PyPI)." - -#: ../source/key_projects.rst:582 -msgid "shiv" -msgstr "shiv" - -#: ../source/key_projects.rst:584 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`Documentação `__ | `GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:588 -msgid "" -"shiv is a command line utility for building fully self contained Python " -"zipapps as outlined in :pep:`441`, but with all their dependencies included. " -"Its primary goal is making distributing Python applications and command line " -"tools fast & easy." -msgstr "" -"shiv é um utilitário de linha de comando para construir *zipapps* Python " -"totalmente autocontidos conforme descrito na :pep:`441`, mas com todas as " -"suas dependências incluídas. Seu objetivo principal é tornar a distribuição " -"Python de aplicações e ferramentas de linha de comando rápida e fácil." - -#: ../source/key_projects.rst:598 -msgid "" -"`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" -msgstr "" -"`Documentação `__ | `GitHub `__ | `Artigo `__ | `Slides `__" - -#: ../source/key_projects.rst:603 -msgid "" -"A flexible package manager designed to support multiple versions, " -"configurations, platforms, and compilers. Spack is like Homebrew, but " -"packages are written in Python and parameterized to allow easy swapping of " -"compilers, library versions, build options, etc. Arbitrarily many versions " -"of packages can coexist on the same system. Spack was designed for rapidly " -"building high performance scientific applications on clusters and " -"supercomputers." -msgstr "" -"Um gerenciador de pacotes flexível projetado para oferecer suporte a várias " -"versões, configurações, plataformas e compiladores. O Spack é como o " -"Homebrew, mas os pacotes são escritos em Python e parametrizados para " -"permitir fácil troca de compiladores, versões de bibliotecas, opções de " -"construção, etc. Arbitrariamente, muitas versões de pacotes podem coexistir " -"no mesmo sistema. O Spack foi projetado para construir rapidamente " -"aplicações científicas de alto desempenho em clusters e supercomputadores." - -#: ../source/key_projects.rst:611 -msgid "" -"Spack is not in PyPI (yet), but it requires no installation and can be used " -"immediately after cloning from GitHub." -msgstr "" -"O Spack não está no PyPI (ainda), mas não requer instalação e pode ser usado " -"imediatamente após a clonagem do GitHub." - -#: ../source/key_projects.rst:617 -msgid "zest.releaser" -msgstr "zest.releaser" - -#: ../source/key_projects.rst:619 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`Documentação `__ | `GitHub " -"`__ | `PyPI `__" - -#: ../source/key_projects.rst:623 -msgid "" -"``zest.releaser`` is a Python package release tool providing an abstraction " -"layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to " -"automate incrementing package version numbers, updating changelogs, tagging " -"releases in source control, and uploading new packages to PyPI." -msgstr "" -"``zest.releaser`` é uma ferramenta de lançamento de pacote Python que " -"fornece uma camada de abstração sobre :ref:`twine`. Os desenvolvedores " -"Python usam ``zest.releaser`` para automatizar o incremento de números de " -"versão de pacote, atualizando changelogs, marcando lançamentos no controle " -"de fontes e enviando novos pacotes para PyPI." - -#: ../source/key_projects.rst:630 -msgid "Standard Library Projects" -msgstr "Projetos de biblioteca padrão" - -#: ../source/key_projects.rst:635 -msgid "ensurepip" -msgstr "ensurepip" - -#: ../source/key_projects.rst:637 -msgid "" -"`Docs `__ | `Issues " -"`__" -msgstr "" -"`Documentação `__ | " -"`Issues `__" - -#: ../source/key_projects.rst:640 -msgid "" -"A package in the Python Standard Library that provides support for " -"bootstrapping :ref:`pip` into an existing Python installation or virtual " -"environment. In most cases, end users won't use this module, but rather it " -"will be used during the build of the Python distribution." -msgstr "" -"Um pacote na Biblioteca Padrão do Python que fornece suporte para preparar " -"o :ref:`pip` em uma instalação existente do Python ou em ambiente virtual. " -"Na maioria dos casos, os usuários finais não usarão este módulo, mas em vez " -"disso, ele será usado durante a construção da distribuição Python." - -#: ../source/key_projects.rst:649 -msgid "distutils" -msgstr "distutils" - -#: ../source/key_projects.rst:651 -msgid "" -"`Docs `__ | `Issues " -"`__" -msgstr "" -"`Documentação `__ | " -"`Issues `__" - -#: ../source/key_projects.rst:654 -msgid "" -"The original Python packaging system, added to the standard library in " -"Python 2.0." -msgstr "" -"O sistema de empacotamento original do Python, adicionado à biblioteca " -"padrão no Python 2.0." - -#: ../source/key_projects.rst:657 -msgid "" -"Due to the challenges of maintaining a packaging system where feature " -"updates are tightly coupled to language runtime updates, direct usage of :" -"ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being " -"the preferred replacement. :ref:`Setuptools` not only provides features that " -"plain :ref:`distutils` doesn't offer (such as dependency declarations and " -"entry point declarations), it also provides a consistent build interface and " -"feature set across all supported Python versions." -msgstr "" -"Devido aos desafios de manter um sistema de empacotamento onde as " -"atualizações de recursos estão fortemente acopladas às atualizações de tempo " -"de execução da linguagem, o uso direto de :ref:`distutils` agora é " -"ativamente desencorajado, com :ref:`Setuptools` sendo o substituto " -"preferido. :ref:`Setuptools` não apenas fornece recursos que o :ref:" -"`distutils` simples não oferece (como declarações de dependência e " -"declarações de ponto de entrada), ele também fornece uma interface de " -"construção consistente e conjunto de recursos em todas as versões Python " -"suportadas ." - -#: ../source/key_projects.rst:670 -msgid "venv" -msgstr "venv" - -#: ../source/key_projects.rst:672 -msgid "" -"`Docs `__ | `Issues `__" -msgstr "" -"`Documentação `__ | `Issues " -"`__" - -#: ../source/key_projects.rst:675 -msgid "" -"A package in the Python Standard Library (starting with Python 3.3) for " -"creating :term:`Virtual Environments `. For more " -"information, see the section on :ref:`Creating and using Virtual " -"Environments`." -msgstr "" -"Um pacote na Biblioteca Padrão do Python (começando com Python 3.3) para " -"criar :term:`Ambientes Virtuais `. Para obter mais " -"informações, consulte a seção :ref:`Creating and using Virtual Environments`." - -#: ../source/news.rst:2 -msgid "News" -msgstr "Notícias" - -#: ../source/news.rst:5 -msgid "September 2019" -msgstr "Setembro de 2019" - -#: ../source/news.rst:6 -msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" -msgstr "" -"Adicionado um guia sobre como publicar dists por meio do GitHub Actions. (:" -"pr:`647`)" - -#: ../source/news.rst:9 -msgid "August 2019" -msgstr "Agosto de 2019" - -#: ../source/news.rst:10 -msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" -msgstr "Atualizado para usar :file:`python3 -m` ao instalar pipx. (:pr:`631`)" - -#: ../source/news.rst:13 -msgid "July 2019" -msgstr "Julho de 2019" - -#: ../source/news.rst:14 -msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" -msgstr "Todos os números PEP marcados com função :pep:. (:pr:`629`)" - -#: ../source/news.rst:15 -msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" -msgstr "" -"Atualizada a versão do Sphinx e removido intersphinx para pypa.io. (:pr:" -"`625`)" - -#: ../source/news.rst:16 -msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" -msgstr "Mencionado :file:`find_namespace_packages`. (:pr:`622`)" - -#: ../source/news.rst:17 -msgid "Updated directory layout examples for consistency. (:pr:`611`)" -msgstr "" -"Atualizados os exemplos de layout de diretório para consistência. (:pr:`611`)" - -#: ../source/news.rst:18 -msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" -msgstr "Atualizado o link do Bandersnatch para GitHub. (:pr:`623`)" - -#: ../source/news.rst:21 -msgid "June 2019" -msgstr "Junho de 2019" - -#: ../source/news.rst:22 -msgid "Fixed some typos. (:pr:`620`)" -msgstr "Corrigidos de alguns erros de escrita. (:pr:`620`)" - -#: ../source/news.rst:25 -msgid "May 2019" -msgstr "Maio de 2019" - -#: ../source/news.rst:26 -msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" -msgstr "" -"Adicionado o uso de :file:`python_requires` ao tutorial de empacotamento. (:" -"pr:`613`)" - -#: ../source/news.rst:27 -msgid "Added a MANIFEST.in guide page. (:pr:`609`)" -msgstr "Adicionada uma página de guia sobre MANIFEST.in. (:pr:`609`)" - -#: ../source/news.rst:30 -msgid "April 2019" -msgstr "Abril de 2019" - -#: ../source/news.rst:31 -msgid "" -"Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" -msgstr "" -"Adicionada uma menção para :file:`shiv` na seção de projetos-chave. (:pr:" -"`608`)" - -#: ../source/news.rst:32 -msgid "Reduced emphasis on virtualenv. (:pr:`606`)" -msgstr "Reduzida a ênfase em virtualenv. (:pr:`606`)" - -#: ../source/news.rst:35 -msgid "March 2019" -msgstr "Março de 2019" - -#: ../source/news.rst:36 -msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" -msgstr "" -"Movida a opção de versão do guia de única fonte para Python 3. (:pr:`605`)" - -#: ../source/news.rst:37 -msgid "Covered RTD details for contributing. (:pr:`600`)" -msgstr "Cobertos detalhes de RTD para contribuição. (:pr:`600`)" - -#: ../source/news.rst:40 -msgid "February 2019" -msgstr "Fevereiro de 2019" - -#: ../source/news.rst:41 -msgid "" -"Elaborate upon the differences between the tutorial and the real packaging " -"process. (:pr:`602`)" -msgstr "" -"Explicada as diferenças entre o tutorial e o processo de empacotamento real. " -"(:pr:`602`)" - -#: ../source/news.rst:42 -msgid "Added instructions to install Python CLI applications. (:pr:`594`)" -msgstr "" -"Adicionadas as instruções para instalar aplicações CLI do Python. (:pr:`594`)" - -#: ../source/news.rst:45 -msgid "January 2019" -msgstr "Janeiro de 2019" - -#: ../source/news.rst:46 -msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" -msgstr "Adicionado :file:`--no-deps` ao tutorial de empacotamento. (:pr:`593`)" - -#: ../source/news.rst:47 -msgid "Updated Sphinx and Nox. (:pr:`591`)" -msgstr "Atualizado Sphinx e Nox. (:pr:`591`)" - -#: ../source/news.rst:48 -msgid "Referenced Twine from Python3. (:pr:`581`)" -msgstr "Referenciado o Twine do Python3. (:pr:`581`)" - -#: ../source/news.rst:51 -msgid "December 2018" -msgstr "Dezembro de 2018" - -#: ../source/news.rst:52 -msgid "No programmers in the office!" -msgstr "Sem programadores no escritório!" - -#: ../source/news.rst:55 -msgid "November 2018" -msgstr "Novembro de 2018" - -#: ../source/news.rst:56 -msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" -msgstr "" -"Removido o link da página de destino para o guia de migração do PyPI. (:pr:" -"`575`)" - -#: ../source/news.rst:57 -msgid "Changed bumpversion to bump2version. (:pr:`572`)" -msgstr "Alterado bumpversion para bump2version. (:pr:`572`)" - -#: ../source/news.rst:58 -msgid "Added single-sourcing package version example. (:pr:`573`)" -msgstr "Adicionado exemplo de versão de pacote de única fonte. (:pr:`573`)" - -#: ../source/news.rst:59 -msgid "Added a guide for creating documentation. (:pr:`568`)" -msgstr "Adicionado um guia para a criação de documentação. (:pr:`568`)" - -#: ../source/news.rst:62 -msgid "October 2018" -msgstr "Outubro de 2018" - -#: ../source/news.rst:63 -msgid "Updated Nox package name. (:pr:`566`)" -msgstr "Atualizado o nome do pacote Nox. (:pr:`566`)" - -#: ../source/news.rst:64 -msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" -msgstr "Mencionadas extensões Sphinx nos guias. (:pr:`562`)" - -#: ../source/news.rst:67 -msgid "September 2018" -msgstr "Setembro de 2018" - -#: ../source/news.rst:68 -msgid "Added a section on checking RST markup. (:pr:`554`)" -msgstr "Adicionada uma seção sobre como verificar a marcação RST. (:pr:`554`)" - -#: ../source/news.rst:69 -msgid "Updated user installs page. (:pr:`558`)" -msgstr "Atualizada página de instalações do usuário. (:pr:`558`)" - -#: ../source/news.rst:70 -msgid "Updated Google BigQuery urls. (:pr:`556`)" -msgstr "Atualizadas as URLs do Google BigQuery. (:pr:`556`)" - -#: ../source/news.rst:71 -msgid "Replaced tar command with working command. (:pr:`552`)" -msgstr "Substituído o comando tar pelo comando de trabalho. (:pr:`552`)" - -#: ../source/news.rst:72 -msgid "" -"Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" -msgstr "" -"Alterado para aspas duplas no pip install SomeProject==1.4. (:pr:`550`)" - -#: ../source/news.rst:75 -msgid "August 2018" -msgstr "Agosto de 2018" - -#: ../source/news.rst:76 -msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" -msgstr "" -"Removida a recomendação de armazenar senhas em texto não criptografado. (:pr:" -"`546`)" - -#: ../source/news.rst:77 -msgid "" -"Moved the Overview to a task based lead in along with the others. (:pr:`540`)" -msgstr "" -"Movida a Visão geral para um ponto baseado em tarefas junto com os outros. (:" -"pr:`540`)" - -#: ../source/news.rst:78 -msgid "Updated Python version supported by virtualenv. (:pr:`538`)" -msgstr "Atualizada a versão do Python compatível com virtualenv. (:pr:`538`)" - -#: ../source/news.rst:79 -msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" -msgstr "Adicionado esboço/rascunho da nova página de Visão geral. (:pr:`519`)" - -#: ../source/news.rst:82 -msgid "July 2018" -msgstr "Julho de 2018" - -#: ../source/news.rst:84 -msgid "Improved binary extension docs. (:pr:`531`)" -msgstr "Melhorada a documentação de extensão binária. (:pr:`531`)" - -#: ../source/news.rst:85 -msgid "Added scikit-build to key projects. (:pr:`530`)" -msgstr "Adicionado o scikit-build aos principais projetos. (:pr:`530`)" - -#: ../source/news.rst:88 -msgid "June 2018" -msgstr "Junho de 2018" - -#: ../source/news.rst:90 -msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" -msgstr "" -"Corrigidas as categorias de interoperabilidade de PEP para pypa.io. (:pr:" -"`527`)" - -#: ../source/news.rst:91 -msgid "Updated Markdown descriptions explanation. (:pr:`522`)" -msgstr "Atualizada a explicação das descrições de Markdown. (:pr:`522`)" - -#: ../source/news.rst:94 -msgid "May 2018" -msgstr "Maio de 2018" - -#: ../source/news.rst:96 -msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" -msgstr "" -"Adicionadas notas sobre problemas com Provides-Dist e Obsoletes-Dist. (:pr:" -"`513`)" - -#: ../source/news.rst:97 -msgid "" -"Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" -msgstr "" -"Removido o aviso de desatualizado sobre a mistura da versão Python com o " -"Pipenv. (:pr:`501`)" - -#: ../source/news.rst:98 -msgid "Simplified packaging tutorial. (:pr:`498`)" -msgstr "Simplificado o tutorial de empacotamento. (:pr:`498`)" - -#: ../source/news.rst:99 -msgid "Updated Windows users instructions for clarity. (:pr:`493`)" -msgstr "" -"Atualizadas as instruções do usuário Windows para maior clareza. (:pr:`493`)" - -#: ../source/news.rst:100 -msgid "Updated the license section description for completeness. (:pr:`492`)" -msgstr "" -"Atualizada a descrição da seção da licença para integridade. (:pr:`492`)" - -#: ../source/news.rst:101 -msgid "Added specification-style document to contributing section. (:pr:`489`)" -msgstr "" -"Adicionado documento de estilo de especificação à seção de contribuição. (:" -"pr:`489`)" - -#: ../source/news.rst:102 -msgid "Added documentation types to contributing guide. (:pr:`485`)" -msgstr "Adicionados tipos de documentação ao guia de contribuição. (:pr:`485`)" - -#: ../source/news.rst:105 -msgid "April 2018" -msgstr "Abril de 2018" - -#: ../source/news.rst:107 -msgid "Added README guide. (:pr:`461`)" -msgstr "Adicionado guia de README. (:pr:`461`)" - -#: ../source/news.rst:108 -msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" -msgstr "" -"Atualizadas as instruções e status para o lançamento do PyPI. (:pr:`475`)" - -#: ../source/news.rst:109 -msgid "Added instructions for Warehouse. (:pr:`471`)" -msgstr "Adicionadas instruções para o Warehouse. (:pr:`471`)" - -#: ../source/news.rst:110 -msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" -msgstr "Removidas referências de GPG do tutorial de publicação. (:pr:`466`)" - -#: ../source/news.rst:111 -msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" -msgstr "Adicionado 'O que há em cada Python 3.4–3.6?'. (:pr:`468`)" - -#: ../source/news.rst:112 -msgid "Added a guide for phasing out Python versions. (:pr:`459`)" -msgstr "Adicionado um guia para descontinuar as versões do Python. (:pr:`459`)" - -#: ../source/news.rst:113 -msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" -msgstr "Tornada padrão a variante GFM do Description-Content-Type. (:pr:`462`)" - -#: ../source/news.rst:116 -msgid "March 2018" -msgstr "Março de 2018" - -#: ../source/news.rst:118 -msgid "Updated \"installing scientific packages\". (:pr:`455`)" -msgstr "Atualizado \"instalando pacotes científicos\". (:pr:`455`)" - -#: ../source/news.rst:119 -msgid "" -"Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" -msgstr "" -"Adicionado :file:`long_description_content_type` para seguir a PEP 556. (:pr:" -"`457`)" - -#: ../source/news.rst:120 -msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" -msgstr "" -"Esclarecido um classificador de descrição longa em pypi.org. (:pr:`456`)" - -#: ../source/news.rst:121 -msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" -msgstr "" -"Atualizada a especificação dos metadados principais para seguir a PEP 556. (:" -"pr:`412`)" - -#: ../source/news.rst:124 -msgid "February 2018" -msgstr "Fevereiro de 2018" - -#: ../source/news.rst:126 -msgid "" -"Added python3-venv and python3-pip to Debian installation instructions. (:pr:" -"`445`)" -msgstr "" -"Adicionados python3-venv e python3-pip às instruções de instalação do " -"Debian. (:pr:`445`)" - -#: ../source/news.rst:127 -msgid "Updated PyPI migration info. (:pr:`439`)" -msgstr "Informações de migração do PyPI atualizadas. (:pr:`439`)" - -#: ../source/news.rst:128 -msgid "" -"Added a warning about managing multiple versions with pipenv. (:pr:`430`)" -msgstr "" -"Adicionado um aviso sobre o gerenciamento de várias versões com pipenv. (:pr:" -"`430`)" - -#: ../source/news.rst:129 -msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" -msgstr "" -"Adicionado exemplo de vários e-mails aos metadados principais. (:pr:`429`)" - -#: ../source/news.rst:130 -msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" -msgstr "" -"Adicionada explicação de \"legado\" em test.pypi.org/legacy. (:pr:`426`)" - -#: ../source/news.rst:133 -msgid "January 2018" -msgstr "Janeiro de 2018" - -#: ../source/news.rst:135 -msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" -msgstr "" -"Adicionado um link para a lista de classificadores do PyPI. (:pr:`425`)" - -#: ../source/news.rst:136 -msgid "Updated README.rst explanation. (:pr:`419`)" -msgstr "Atualizada uma explicação sobre README.rst. (:pr:`419`)" - -#: ../source/news.rst:139 -msgid "December 2017" -msgstr "Dezembro de 2017" - -#: ../source/news.rst:141 -msgid "" -"Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" -msgstr "" -"Substituído :file:`~` por :file:`$HOME` nos guias e tutoriais. (:pr:`418`)" - -#: ../source/news.rst:142 -msgid "Noted which fields can be used with environment markers. (:pr:`416`)" -msgstr "" -"Adicionada nota sobre quais campos podem ser usados com marcadores de " -"ambiente. (:pr:`416`)" - -#: ../source/news.rst:143 -msgid "Updated Requires-Python section. (:pr:`414`)" -msgstr "Atualizada a seção Requires-Python. (:pr:`414`)" - -#: ../source/news.rst:144 -msgid "Added news page. (:pr:`404`)" -msgstr "Adicionada página de notícias. (:pr:`404`)" - -#: ../source/news.rst:147 -msgid "November 2017" -msgstr "Novembro de 2017" - -#: ../source/news.rst:149 -msgid "" -"Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" -msgstr "" -"Introduzido um novo tutorial de gerenciamento de dependências baseado no " -"Pipenv. (:pr:`402`)" - -#: ../source/news.rst:150 -msgid "" -"Updated the *Single Sourcing Package Version* tutorial to reflect pip's " -"current strategy. (:pr:`400`)" -msgstr "" -"Atualizado o tutorial *Versão de pacote de fonte única* para refletir a " -"estratégia atual do pip. (:pr:`400`)" - -#: ../source/news.rst:152 -msgid "" -"Added documentation about the ``py_modules`` argument to ``setup``. (:pr:" -"`398`)" -msgstr "" -"Adicionada documentação sobre o argumento ``py_modules`` ao ``setup``. (:pr:" -"`398`)" - -#: ../source/news.rst:153 -msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" -msgstr "Simplificadas as palavras da seção :file:`manifest.in`. (:pr:`395`)" - -#: ../source/news.rst:156 -msgid "October 2017" -msgstr "Outubro de 2017" - -#: ../source/news.rst:158 -msgid "" -"Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" -msgstr "" -"Adicionada uma especificação para o arquivo :file:`entry_points.txt`. (:pr:" -"`398`)" - -#: ../source/news.rst:159 -msgid "" -"Created a new guide for managing packages using ``pip`` and ``virtualenv``. " -"(:pr:`385`)" -msgstr "" -"Criado um novo guia para gerenciamento de pacotes usando ``pip`` e " -"``virtualenv``. (:pr:`385`)" - -#: ../source/news.rst:160 -msgid "Split the specifications page into multiple pages. (:pr:`386`)" -msgstr "Dividida a página de especificações em várias páginas. (:pr:`386`)" - -#: ../source/news.rst:163 -msgid "September 2017" -msgstr "Setembro de 2017" - -#: ../source/news.rst:165 -msgid "" -"Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:" -"`379`)" -msgstr "" -"Incentivado o uso de ``readme_renderer`` validar o :file:`README.rst`. (:pr:" -"`379`)" - -#: ../source/news.rst:167 -msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" -msgstr "Recomendado o uso da opção ``--user-base``. (:pr:`374`)" - -#: ../source/news.rst:170 -msgid "August 2017" -msgstr "Agosto de 2017" - -#: ../source/news.rst:172 -msgid "" -"Added a new, experimental tutorial on installing packages using ``Pipenv``. " -"(:pr:`369`)" -msgstr "" -"Adicionado um novo tutorial experimental sobre a instalação de pacotes " -"usando ``Pipenv``. (:pr:`369`)" - -#: ../source/news.rst:173 -msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" -msgstr "Adicionado um novo guia sobre como usar o ``TestPyPI``. (:pr:`366`)" - -#: ../source/news.rst:174 -msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" -msgstr "Adicionado :file:`pypi.org` como um termo. (:pr:`365`)" - -#: ../source/news.rst:177 -msgid "July 2017" -msgstr "Julho de 2017" - -#: ../source/news.rst:179 -msgid "Added ``flit`` to the key projects list. (:pr:`358`)" -msgstr "Adicionado ``flit`` à lista de projetos principais. (:pr:`358`)" - -#: ../source/news.rst:180 -msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" -msgstr "Adicionado ``enscons`` à lista de projetos principais. (:pr:`357`)" - -#: ../source/news.rst:181 -msgid "" -"Updated this guide's ``readme`` with instructions on how to build the guide " -"locally. (:pr:`356`)" -msgstr "" -"Atualizado o ``readme`` deste guia com instruções sobre como construir o " -"guia localmente. (:pr:`356`)" - -#: ../source/news.rst:182 -msgid "" -"Made the new ``TestPyPI`` URL more visible, adding note to homepage about " -"pypi.org. (:pr:`354`)" -msgstr "" -"Melhorada a visibilidade da nova URL do ``TestPyPI``, adicionando uma nota à " -"página inicial sobre pypi.org. (:pr:`354`)" - -#: ../source/news.rst:183 -msgid "" -"Added a note about the removal of the explicit registration API. (:pr:`347`)" -msgstr "" -"Adicionada uma nota sobre a remoção da API de registro explícito. (:pr:`347`)" - -#: ../source/news.rst:186 -msgid "June 2017" -msgstr "Junho de 2017" - -#: ../source/news.rst:188 -msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" -msgstr "" -"Adicionado um documento sobre a migração de envios para :file:`PyPI.org`. (:" -"pr:`339`)" - -#: ../source/news.rst:189 -msgid "Added documentation for ``python_requires``. (:pr:`338`)" -msgstr "Adicionada documentação para ``python_requires``. (:pr:`338`)" - -#: ../source/news.rst:190 -msgid "" -"Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:" -"pr:`335`)" -msgstr "" -"Adicionada uma nota sobre a migração do PyPI no tutorial *Recomendações de " -"ferramentas*. (:pr:`335`)" - -#: ../source/news.rst:191 -msgid "" -"Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" -msgstr "" -"Adicionada uma nota de que o :file:`manifest.in` não afeta os wheels. (:pr:" -"`332`)" - -#: ../source/news.rst:192 -msgid "Added a license section to the distributing guide. (:pr:`331`)" -msgstr "Adicionada uma seção de licença ao guia de distribuição. (:pr:`331`)" - -#: ../source/news.rst:193 -msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" -msgstr "Expandida a seção sobre o argumento ``name``. (:pr:`329`)" - -#: ../source/news.rst:194 -msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" -msgstr "Ajustada a página inicial. (:pr:`327`, :pr:`326`, :pr:`324`)" - -#: ../source/news.rst:195 -msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" -msgstr "Atualizado para Sphinx 1.6.2. (:pr:`323`)" - -#: ../source/news.rst:196 -msgid "Switched to the PyPA theme. (:pr:`305`)" -msgstr "Trocado para o tema do PyPA. (:pr:`305`)" - -#: ../source/news.rst:197 -msgid "Re-organized the documentation into the new structure. (:pr:`318`)" -msgstr "Reorganizada a documentação na nova estrutura. (:pr:`318`)" - -#: ../source/news.rst:200 -msgid "May 2017" -msgstr "Maio de 2017" - -#: ../source/news.rst:202 -msgid "" -"Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" -msgstr "" -"Adicionada documentação para o campo ``Description-Content-Type``. (:pr:" -"`258`)" - -#: ../source/news.rst:203 -msgid "Added contributor and style guide. (:pr:`307`)" -msgstr "Adicionado guia de contribuidor e de estilo. (:pr:`307`)" - -#: ../source/news.rst:204 -msgid "" -"Documented ``pip`` and ``easy_install``'s differences for per-project " -"indexes. (:pr:`233`)" -msgstr "" -"Documentadas as diferenças entre ``pip`` e ``easy_install`` para índices por " -"projeto. (:pr:`233`)" - -#: ../source/news.rst:207 -msgid "April 2017" -msgstr "Abril de 2017" - -#: ../source/news.rst:209 -msgid "Added travis configuration for testing pull requests. (:pr:`300`)" -msgstr "" -"Adicionada configuração de travis para testar pull requests. (:pr:`300`)" - -#: ../source/news.rst:210 -msgid "" -"Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:" -"`299`)" -msgstr "" -"Mencionado o requisito do pacote ``wheel`` para a criação de wheels (:pr:" -"`299`)" - -#: ../source/news.rst:211 -msgid "" -"Removed the ``twine register`` reference in the *Distributing Packages* " -"tutorial. (:pr:`271`)" -msgstr "" -"Removida a referência a ``twine register`` no tutorial *Distribuindo " -"pacotes*. (:pr:`271`)" - -#: ../source/news.rst:212 -msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" -msgstr "" -"Adicionado um tópico sobre descoberta de plugins. (:pr:`294`, :pr:`296`)" - -#: ../source/news.rst:213 -msgid "Added a topic on namespace packages. (:pr:`290`)" -msgstr "Adicionado um tópico sobre pacotes de espaço de nomes. (:pr:`290`)" - -#: ../source/news.rst:214 -msgid "" -"Added documentation explaining prominently how to install ``pip`` in ``/usr/" -"local``. (:pr:`230`)" -msgstr "" -"Adicionada documentação explicando em destaque como instalar ``pip`` em ``/" -"usr/local``. (:pr:`230`)" - -#: ../source/news.rst:215 -msgid "" -"Updated development mode documentation to mention that order of local " -"packages matters. (:pr:`208`)" -msgstr "" -"Atualizada a documentação do modo de desenvolvimento para mencionar que a " -"ordem dos pacotes locais é importante. (:pr:`208`)" - -#: ../source/news.rst:216 -msgid "" -"Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted " -"projects (:pr:`239`)" -msgstr "" -"Conversão de link do readthedocs para sua migração ``.org`` -> ``.io`` para " -"projetos hospedados (:pr:`239`)" - -#: ../source/news.rst:217 -msgid "" -"Swaped order of :file:`setup.py` arguments for the upload command, as order " -"is significant. (:pr:`260`)" -msgstr "" -"Trocada a ordem dos argumentos do :file:`setup.py` para o comando de envio, " -"pois a ordem é significativa. (:pr:`260`)" - -#: ../source/news.rst:219 -msgid "" -"Explained how to install from unsupported sources using a helper " -"application. (:pr:`289`)" -msgstr "" -"Explicado como instalar de fontes não suportadas usando uma aplicação " -"auxiliar. (:pr:`289`)" - -#: ../source/news.rst:223 -msgid "March 2017" -msgstr "Março de 2017" - -#: ../source/news.rst:225 -msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" -msgstr "Coberto ``manylinux1`` em *wheels de plataforma*. (:pr:`283`)" - -#: ../source/news.rst:228 -msgid "February 2017" -msgstr "Fevereiro de 2017" - -#: ../source/news.rst:230 -msgid "Added :pep:`518`. (:pr:`281`)" -msgstr "Adicionada a :pep:`518`. (:pr:`281`)" - -#: ../source/overview.rst:3 -msgid "An Overview of Packaging for Python" -msgstr "Uma visão geral de empacotamento para Python" - -#: ../source/overview.rst:7 -msgid "" -"As a general-purpose programming language, Python is designed to be used in " -"many ways. You can build web sites or industrial robots or a game for your " -"friends to play, and much more, all using the same core technology." -msgstr "" -"Como uma linguagem de programação de propósito geral, Python foi projetado " -"para ser usado de várias maneiras. Você pode construir sites ou robôs " -"industriais ou um jogo para seus amigos jogarem e muito mais, todos usando a " -"mesma tecnologia básica." - -#: ../source/overview.rst:12 -msgid "" -"Python's flexibility is why the first step in every Python project must be " -"to think about the project's audience and the corresponding environment " -"where the project will run. It might seem strange to think about packaging " -"before writing code, but this process does wonders for avoiding future " -"headaches." -msgstr "" -"A flexibilidade do Python é o porquê do primeiro passo em cada projeto " -"Python deva ser pensar sobre o público do projeto e o ambiente " -"correspondente onde o projeto será executado. Pode parecer estranho pensar " -"em empacotamento antes de escrever o código, mas esse processo faz " -"maravilhas para evitar dores de cabeça futuras." - -#: ../source/overview.rst:18 -msgid "" -"This overview provides a general-purpose decision tree for reasoning about " -"Python's plethora of packaging options. Read on to choose the best " -"technology for your next project." -msgstr "" -"Esta visão geral fornece uma árvore de decisão de propósito geral para " -"raciocinar sobre a abundância de opções de empacotamento do Python. Continue " -"lendo para escolher a melhor tecnologia para seu próximo projeto." - -#: ../source/overview.rst:26 -msgid "Thinking about deployment" -msgstr "Pensando sobre a implantação" - -#: ../source/overview.rst:28 -msgid "" -"Packages exist to be installed (or *deployed*), so before you package " -"anything, you'll want to have some answers to the deployment questions below:" -msgstr "" -"Os pacotes existem para serem instalados (ou *implantados*, *deployed*), " -"portanto, antes de empacotar qualquer coisa, você vai querer ter algumas " -"respostas para as perguntas de implantação abaixo:" - -#: ../source/overview.rst:32 -msgid "" -"Who are your software's users? Will your software be installed by other " -"developers doing software development, operations people in a datacenter, or " -"a less software-savvy group?" -msgstr "" -"Quem são os usuários do seu software? Seu software será instalado por outros " -"desenvolvedores que fazem o desenvolvimento de software, pessoas de " -"operações em um datacenter ou um grupo com menos experiência em software?" - -#: ../source/overview.rst:35 -msgid "" -"Is your software intended to run on servers, desktops, mobile clients " -"(phones, tablets, etc.), or embedded in dedicated devices?" -msgstr "" -"O seu software deve ser executado em servidores, desktops, clientes móveis " -"(telefones, tablets, etc.) ou incorporado em dispositivos dedicados?" - -#: ../source/overview.rst:37 -msgid "" -"Is your software installed individually, or in large deployment batches?" -msgstr "" -"O seu software é instalado individualmente ou em grandes lotes de " -"implantação?" - -#: ../source/overview.rst:39 -msgid "" -"Packaging is all about target environment and deployment experience. There " -"are many answers to the questions above and each combination of " -"circumstances has its own solutions. With this information, the following " -"overview will guide you to the packaging technologies best suited to your " -"project." -msgstr "" -"O empacotamento tem tudo a ver com o ambiente de destino e a experiência de " -"implantação. Existem muitas respostas para as perguntas acima e cada " -"combinação de circunstâncias tem suas próprias soluções. Com essas " -"informações, a visão geral a seguir o guiará para as tecnologias de " -"empacotamento mais adequadas ao seu projeto." - -#: ../source/overview.rst:46 -msgid "Packaging Python libraries and tools" -msgstr "Empacotando bibliotecas e ferramentas Python" - -#: ../source/overview.rst:48 -msgid "" -"You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are " -"just a few of the tools Python's ecosystem provides for distributing Python " -"code to developers, which you can read about in :doc:`guides/distributing-" -"packages-using-setuptools`." -msgstr "" -"Você deve ter ouvido falar sobre PyPI, ``setup.py`` e arquivos ``wheel``. " -"Estas são apenas algumas das ferramentas que o ecossistema Python oferece " -"para distribuir código Python para desenvolvedores, sobre as quais você pode " -"ler em :doc:`guides/distributing-packages-using-setuptools`." - -#: ../source/overview.rst:53 -msgid "" -"The following approaches to packaging are meant for libraries and tools used " -"by technical audience in a development setting. If you're looking for ways " -"to package Python for a non-technical audience and/or a production setting, " -"skip ahead to :ref:`packaging-applications`." -msgstr "" -"As abordagens a seguir para empacotamento são destinadas a bibliotecas e " -"ferramentas usadas pelo público técnico em um ambiente de desenvolvimento. " -"Se você está procurando maneiras de empacotar Python para um público não " -"técnico e/ou uma configuração de produção, pule para :ref:`packaging-" -"applications`." - -#: ../source/overview.rst:59 -msgid "Python modules" -msgstr "Módulos Python" - -#: ../source/overview.rst:61 -msgid "" -"A Python file, provided it only relies on the standard library, can be " -"redistributed and reused. You will also need to ensure it's written for the " -"right version of Python, and only relies on the standard library." -msgstr "" -"Um arquivo Python, desde que dependa apenas da biblioteca padrão, pode ser " -"redistribuído e reutilizado. Você também precisará garantir que ele foi " -"escrito para a versão correta do Python e depende apenas da biblioteca " -"padrão." - -#: ../source/overview.rst:66 -msgid "" -"This is great for sharing simple scripts and snippets between people who " -"both have compatible Python versions (such as via email, StackOverflow, or " -"GitHub gists). There are even some entire Python libraries that offer this " -"as an option, such as `bottle.py `_ and " -"`boltons `_." -msgstr "" -"Isso é ótimo para compartilhar scripts e trechos simples entre pessoas que " -"possuem versões Python compatíveis (como via e-mail, StackOverflow ou gists " -"do GitHub). Existem até algumas bibliotecas Python inteiras que oferecem " -"isso como uma opção, como `bottle.py `_ e " -"`boltons `_." - -#: ../source/overview.rst:73 -msgid "" -"However, this pattern won't scale for projects that consist of multiple " -"files, need additional libraries, or need a specific version of Python, " -"hence the options below." -msgstr "" -"No entanto, esse padrão não será escalonado para projetos que consistem em " -"vários arquivos, precisam de bibliotecas adicionais ou precisam de uma " -"versão específica do Python, daí as opções abaixo." - -#: ../source/overview.rst:78 -msgid "Python source distributions" -msgstr "Distribuições fonte Python" - -#: ../source/overview.rst:80 -msgid "" -"If your code consists of multiple Python files, it's usually organized into " -"a directory structure. Any directory containing Python files can comprise " -"an :term:`Import Package`." -msgstr "" -"Se o seu código consiste em vários arquivos Python, ele geralmente é " -"organizado em uma estrutura de diretório. Qualquer diretório contendo " -"arquivos Python pode incluir um :term:`Pacote de Importação`." - -#: ../source/overview.rst:84 -msgid "" -"Because packages consist of multiple files, they are harder to distribute. " -"Most protocols support transferring only one file at a time (when was the " -"last time you clicked a link and it downloaded multiple files?). It's easier " -"to get incomplete transfers, and harder to guarantee code integrity at the " -"destination." -msgstr "" -"Como os pacotes consistem em vários arquivos, eles são mais difíceis de " -"distribuir. A maioria dos protocolos oferece suporte à transferência de " -"apenas um arquivo por vez (quando foi a última vez que você clicou em um " -"link e ele baixou vários arquivos?). É mais fácil obter transferências " -"incompletas e mais difícil garantir a integridade do código no destino." - -#: ../source/overview.rst:90 -msgid "" -"So long as your code contains nothing but pure Python code, and you know " -"your deployment environment supports your version of Python, then you can " -"use Python's native packaging tools to create a *source* :term:`Distribution " -"Package`, or *sdist* for short." -msgstr "" -"Contanto que seu código não contenha nada além de código puro Python, e você " -"saiba que seu ambiente de implantação oferece suporte a sua versão de " -"Python, então você pode usar as ferramentas de empacotamento nativas do " -"Python para criar um :term:`Pacote de Distribuição` fonte, ou *sdist*." - -#: ../source/overview.rst:95 -msgid "" -"Python's *sdists* are compressed archives (``.tar.gz`` files) containing one " -"or more packages or modules. If your code is pure-Python, and you only " -"depend on other Python packages, you can `go here to learn more `_." -msgstr "" -"Os *sdists* do Python são arquivos compactados (arquivos ``.tar.gz``) " -"contendo um ou mais pacotes ou módulos. Se seu código for puro Python e você " -"depender apenas de outros pacotes Python, você pode `clicar aqui para saber " -"mais `_." - -#: ../source/overview.rst:100 -msgid "" -"If you rely on any non-Python code, or non-Python packages (such as `libxml2 " -"`_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next " -"section, which also has many advantages for pure-Python libraries." -msgstr "" -"Se você confiar em qualquer código não-Python ou pacotes não-Python (como " -"`libxml2 `_ no caso de `lxml " -"`_, ou bibliotecas BLAS no caso de `numpy " -"`_), você precisará usar o formato detalhado " -"no a próxima seção, que também tem muitas vantagens para bibliotecas puro " -"Python." - -#: ../source/overview.rst:107 -msgid "" -"Python and PyPI support multiple distributions providing different " -"implementations of the same package. For instance the unmaintained-but-" -"seminal `PIL distribution `_ provides the PIL " -"package, and so does `Pillow `_, an " -"actively-maintained fork of PIL!" -msgstr "" -"Python e PyPI oferecem suporte a várias distribuições, fornecendo diferentes " -"implementações do mesmo pacote. Por exemplo, a `distribuição PIL " -"`_ não mantida, mas inspiracional, fornece o " -"pacote PIL, e também o `Pillow `_, um fork " -"do PIL!" - -#: ../source/overview.rst:114 -msgid "" -"This Python packaging superpower makes it possible for Pillow to be a drop-" -"in replacement for PIL, just by changing your project's ``install_requires`` " -"or ``requirements.txt``." -msgstr "" -"Este superpoder de empacotamento do Python torna possível que o Pillow seja " -"um substituto imediato para o PIL, apenas alterando o ``install_requires`` " -"ou ``requirements.txt`` do seu projeto." - -#: ../source/overview.rst:119 -msgid "Python binary distributions" -msgstr "Distribuições binárias Python" - -#: ../source/overview.rst:121 -msgid "" -"So much of Python's practical power comes from its ability to integrate with " -"the software ecosystem, in particular libraries written in C, C++, Fortran, " -"Rust, and other languages." -msgstr "" -"Grande parte do poder prático do Python vem de sua capacidade de integração " -"com o ecossistema de software, em particular bibliotecas escritas em C, C++, " -"Fortran, Rust e outras linguagens." - -#: ../source/overview.rst:125 -msgid "" -"Not all developers have the right tools or experiences to build these " -"components written in these compiled languages, so Python created the :term:" -"`Wheel`, a package format designed to ship libraries with compiled " -"artifacts. In fact, Python's package installer, ``pip``, always prefers " -"wheels because installation is always faster, so even pure-Python packages " -"work better with wheels." -msgstr "" -"Nem todos os desenvolvedores têm as ferramentas ou experiências certas para " -"construir esses componentes escritos nessas linguagens compiladas, então " -"Python criou o :term:`Wheel`, um formato de pacote projetado para enviar " -"bibliotecas com artefatos compilados. Na verdade, o instalador do pacote " -"Python, ``pip``, sempre prefere wheels porque a instalação é sempre mais " -"rápida, então mesmo os pacotes puro Python funcionam melhor com wheels." - -#: ../source/overview.rst:132 -msgid "" -"Binary distributions are best when they come with source distributions to " -"match. Even if you don't upload wheels of your code for every operating " -"system, by uploading the sdist, you're enabling users of other platforms to " -"still build it for themselves. Default to publishing both sdist and wheel " -"archives together, *unless* you're creating artifacts for a very specific " -"use case where you know the recipient only needs one or the other." -msgstr "" -"As distribuições binárias são melhores quando vêm com distribuições de fonte " -"correspondentes. Mesmo que você não envie wheels do seu código para todos os " -"sistemas operacionais, ao enviar o sdist, você permite que usuários de " -"outras plataformas ainda o construam por conta própria. O padrão é publicar " -"arquivos sdist e wheel juntos, *a menos* que você esteja criando artefatos " -"para um caso de uso muito específico, onde sabe que o destinatário só " -"precisa de um ou de outro." - -#: ../source/overview.rst:140 -msgid "" -"Python and PyPI make it easy to upload both wheels and sdists together. Just " -"follow the :doc:`tutorials/packaging-projects` tutorial." -msgstr "" -"Python e PyPI facilitam o envio de wheels e sdists juntos. Basta seguir o " -"tutorial :doc:`tutorials/packaging-projects`." - -#: ../source/overview.rst:148 -msgid "" -"Python's recommended built-in library and tool packaging technologies. " -"Excerpted from `The Packaging Gradient (2017) `_." -msgstr "" -"Bibliotecas embutidas recomendadas e tecnologias de empacotamento de " -"ferramentas do Python. Extraído de `The Packaging Gradient (2017) `_." - -#: ../source/overview.rst:155 -msgid "Packaging Python applications" -msgstr "Empacotando aplicações do Python" - -#: ../source/overview.rst:157 -msgid "" -"So far we've only discussed Python's native distribution tools. Based on our " -"introduction, you would be correct to infer these built-in approaches only " -"target environments which have Python, and an audience who knows how to " -"install Python packages." -msgstr "" -"Até agora, discutimos apenas as ferramentas de distribuição nativas do " -"Python. Com base em nossa introdução, você estaria correto em inferir que " -"essas abordagens embutidas têm como alvo apenas ambientes que possuem Python " -"e um público que sabe como instalar pacotes Python." - -#: ../source/overview.rst:162 -msgid "" -"With the variety of operating systems, configurations, and people out there, " -"this assumption is only safe when targeting a developer audience." -msgstr "" -"Com a variedade de sistemas operacionais, configurações e pessoas por aí, " -"essa suposição só é segura quando se destina a um público de desenvolvedores." - -#: ../source/overview.rst:166 -msgid "" -"Python's native packaging is mostly built for distributing reusable code, " -"called libraries, between developers. You can piggyback **tools**, or basic " -"applications for developers, on top of Python's library packaging, using " -"technologies like `setuptools entry_points `_." -msgstr "" -"O empacotamento nativo do Python é construído principalmente para distribuir " -"código reutilizável, chamado de bibliotecas, entre os desenvolvedores. Você " -"pode adicionar **ferramentas** ou aplicações básicas para desenvolvedores ao " -"pacote de biblioteca do Python, usando tecnologias como `entry_points do " -"setuptools `_." - -#: ../source/overview.rst:172 -msgid "" -"Libraries are building blocks, not complete applications. For distributing " -"applications, there's a whole new world of technologies out there." -msgstr "" -"Bibliotecas são blocos de construção, não aplicações completas. Para " -"distribuir aplicações, existe um novo mundo de tecnologias por aí." - -#: ../source/overview.rst:176 -msgid "" -"The next few sections organize these application packaging options according " -"to their dependencies on the target environment, so you can choose the right " -"one for your project." -msgstr "" -"As próximas seções organizam essas opções de pacote de aplicações de acordo " -"com suas dependências no ambiente de destino, para que você possa escolher o " -"certo para o seu projeto." - -#: ../source/overview.rst:181 -msgid "Depending on a framework" -msgstr "Dependendo de um framework" - -#: ../source/overview.rst:183 -msgid "" -"Some types of Python applications, like web site backends and other network " -"services, are common enough that they have frameworks to enable their " -"development and packaging. Other types of applications, like dynamic web " -"frontends and mobile clients, are complex enough to target that a framework " -"becomes more than a convenience." -msgstr "" -"Alguns tipos de aplicações Python, como backends de sites e outros serviços " -"de rede, são comuns o suficiente para que tenham estruturas para permitir " -"seu desenvolvimento e empacotamento. Outros tipos de aplicações, como " -"frontends web dinâmicos e clientes móveis, são complexos o suficiente para " -"fazer com que uma estrutura se torne mais do que uma conveniência." - -#: ../source/overview.rst:189 -msgid "" -"In all these cases, it makes sense to work backwards, from the framework's " -"packaging and deployment story. Some frameworks include a deployment system " -"which wraps the technologies outlined in the rest of the guide. In these " -"cases, you'll want to defer to your framework's packaging guide for the " -"easiest and most reliable production experience." -msgstr "" -"Em todos esses casos, faz sentido trabalhar de trás para frente, a partir da " -"história de empacotamento e implantação da estrutura. Algumas estruturas " -"incluem um sistema de implantação que envolve as tecnologias descritas no " -"restante do guia. Nesses casos, você desejará consultar o guia de " -"empacotamento de sua estrutura para obter a experiência de produção mais " -"fácil e confiável." - -#: ../source/overview.rst:195 -msgid "" -"If you ever wonder how these platforms and frameworks work under the hood, " -"you can always read the sections beyond." -msgstr "" -"Se você já se perguntou como essas plataformas e estruturas funcionam nos " -"bastidores, você sempre pode ler as seções seguintes." - -#: ../source/overview.rst:199 -msgid "Service platforms" -msgstr "Plataformas de serviço" - -#: ../source/overview.rst:201 -msgid "" -"If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku " -"or Google App Engine, you are going to want to follow their respective " -"packaging guides." -msgstr "" -"Se estiver desenvolvendo para uma \"plataforma como serviço\" ou \"PaaS\", " -"como Heroku ou Google App Engine, você vai querer seguir seus respectivos " -"guias de empacotamento." - -#: ../source/overview.rst:205 -msgid "" -"`Heroku `_" -msgstr "" -"`Heroku `_" - -#: ../source/overview.rst:206 -msgid "`Google App Engine `_" -msgstr "`Google App Engine `_" - -#: ../source/overview.rst:207 -msgid "`PythonAnywhere `_" -msgstr "`PythonAnywhere `_" - -#: ../source/overview.rst:208 -msgid "`OpenShift `_" -msgstr "`OpenShift `_" - -#: ../source/overview.rst:209 -msgid "\"Serverless\" frameworks like `Zappa `_" -msgstr "Frameworks \"serverless\" como `Zappa `_" - -#: ../source/overview.rst:211 -msgid "" -"In all these setups, the platform takes care of packaging and deployment, as " -"long as you follow their patterns. Most software does not fit one of these " -"templates, hence the existence of all the other options below." -msgstr "" -"Em todas essas configurações, a plataforma cuida do empacotamento e da " -"implantação, desde que você siga seus padrões. A maioria dos softwares não " -"se encaixa em um desses modelos, daí a existência de todas as outras opções " -"abaixo." - -#: ../source/overview.rst:216 -msgid "" -"If you're developing software that will be deployed to machines you own, " -"users' personal computers, or any other arrangement, read on." -msgstr "" -"Se você estiver desenvolvendo um software que será implantado em suas " -"máquinas, computadores pessoais de usuários ou qualquer outro arranjo, " -"continue lendo." - -#: ../source/overview.rst:220 -msgid "Web browsers and mobile applications" -msgstr "Navegadores web e aplicações móveis" - -#: ../source/overview.rst:222 -msgid "" -"Python's steady advances are leading it into new spaces. These days you can " -"write a mobile app or web application frontend in Python. While the language " -"may be familiar, the packaging and deployment practices are brand new." -msgstr "" -"Os avanços constantes do Python estão levando-o a novos espaços. Hoje em " -"dia, você pode escrever uma aplicação móvel ou frontend de aplicação web no " -"Python. Embora a linguagem possa ser familiar, as práticas de empacotamento " -"e implantação são novas." - -#: ../source/overview.rst:227 -msgid "" -"If you're planning on releasing to these new frontiers, you'll want to check " -"out the following frameworks, and refer to their packaging guides:" -msgstr "" -"Se você está planejando lançar para essas novas fronteiras, convém verificar " -"as seguintes estruturas e consultar seus guias de empacotamento:" - -#: ../source/overview.rst:231 -msgid "`Kivy `_" -msgstr "`Kivy `_" - -#: ../source/overview.rst:232 -msgid "`Beeware `_" -msgstr "`Beeware `_" - -#: ../source/overview.rst:233 -msgid "`Brython `_" -msgstr "`Brython `_" - -#: ../source/overview.rst:234 -msgid "`Flexx `_" -msgstr "`Flexx `_" - -#: ../source/overview.rst:236 -msgid "" -"If you are *not* interested in using a framework or platform, or just wonder " -"about some of the technologies and techniques utilized by the frameworks " -"above, continue reading below." -msgstr "" -"Se você *não* está interessado em usar um framework ou plataforma, ou apenas " -"quer saber sobre algumas das tecnologias e técnicas utilizadas pelos " -"frameworks acima, continue lendo abaixo." - -#: ../source/overview.rst:241 -msgid "Depending on a pre-installed Python" -msgstr "Dependendo de um Python pré-instalado" - -#: ../source/overview.rst:243 -msgid "" -"Pick an arbitrary computer, and depending on the context, there's a very " -"good chance Python is already installed. Included by default in most Linux " -"and Mac operating systems for many years now, you can reasonably depend on " -"Python preexisting in your data centers or on the personal machines of " -"developers and data scientists." -msgstr "" -"Escolha um computador arbitrário e, dependendo do contexto, há uma boa " -"chance do Python já estar instalado. Incluído por padrão na maioria dos " -"sistemas operacionais Linux e Mac por muitos anos, você pode depender " -"razoavelmente do Python preexistente em seus datacenters ou nas máquinas " -"pessoais de desenvolvedores e cientistas de dados." - -#: ../source/overview.rst:249 -msgid "Technologies which support this model:" -msgstr "Tecnologias que oferecem suporte a este modelo:" - -#: ../source/overview.rst:251 -msgid "`PEX `_ (Python EXecutable)" -msgstr "`PEX `_ (Python EXecutable)" - -#: ../source/overview.rst:252 -msgid "" -"`zipapp `_ (does not help " -"manage dependencies, requires Python 3.5+)" -msgstr "" -"`zipapp `_ (não ajuda a " -"gerenciar dependências, requer Python 3.5+)" - -#: ../source/overview.rst:253 -msgid "`shiv `_ (requires Python 3)" -msgstr "`shiv `_ (requer Python 3)" - -#: ../source/overview.rst:255 -msgid "" -"Of all the approaches here, depending on a pre-installed Python relies the " -"most on the target environment. Of course, this also makes for the smallest " -"package, as small as single-digit megabytes, or even kilobytes." -msgstr "" -"De todas as abordagens aqui, depender de um Python pré-instalado depende " -"mais do ambiente de destino. Claro, isso também contribui para o menor " -"pacote, tão pequeno quanto megabytes de um dígito, ou mesmo kilobytes." - -#: ../source/overview.rst:260 -msgid "" -"In general, decreasing the dependency on the target system increases the " -"size of our package, so the solutions here are roughly arranged by " -"increasing size of output." -msgstr "" -"Em geral, diminuir a dependência do sistema de destino aumenta o tamanho do " -"nosso pacote, portanto, as soluções aqui são organizadas de forma grosseira " -"pelo aumento do tamanho da saída." - -#: ../source/overview.rst:267 -msgid "Depending on a separate software distribution ecosystem" -msgstr "Dependendo de um ecossistema separado de distribuição de software" - -#: ../source/overview.rst:269 -msgid "" -"For a long time many operating systems, including Mac and Windows, lacked " -"built-in package management. Only recently did these OSes gain so-called " -"\"app stores\", but even those focus on consumer applications and offer " -"little for developers." -msgstr "" -"Por um longo tempo, muitos sistemas operacionais, incluindo Mac e Windows, " -"não tinham gerenciamento de pacotes integrado. Apenas recentemente esses " -"sistemas operacionais ganharam as chamadas \"*app store*\", mas mesmo " -"aqueles se concentram em aplicações de consumo e oferecem pouco para os " -"desenvolvedores." - -#: ../source/overview.rst:274 -msgid "" -"Developers long sought remedies, and in this struggle, emerged with their " -"own package management solutions, such as `Homebrew `_. " -"The most relevant alternative for Python developers is a package ecosystem " -"called `Anaconda `_. Anaconda is built around Python and is " -"increasingly common in academic, analytical, and other data-oriented " -"environments, even making its way `into server-oriented environments " -"`_." -msgstr "" -"Os desenvolvedores buscaram soluções por muito tempo e, nessa luta, surgiram " -"com suas próprias soluções de gerenciamento de pacotes, como o `Homebrew " -"`_. A alternativa mais relevante para desenvolvedores " -"Python é um ecossistema de pacotes chamado `Anaconda `_. O Anaconda é construído em torno " -"do Python e é cada vez mais comum em ambientes acadêmicos, analíticos e " -"outros ambientes orientados a dados, chegando até a ambientes orientados a " -"servidor `_." - -#: ../source/overview.rst:284 -msgid "Instructions on building and publishing for the Anaconda ecosystem:" -msgstr "" -"Instruções sobre como construir e publicar para o ecossistema do Anaconda:" - -#: ../source/overview.rst:286 -msgid "" -"`Building libraries and applications with conda `_" -msgstr "" -"`Building libraries and applications with conda `_" - -#: ../source/overview.rst:287 -msgid "" -"`Transitioning a native Python package to Anaconda `_" -msgstr "" -"`Transitioning a native Python package to Anaconda `_" - -#: ../source/overview.rst:289 -msgid "" -"A similar model involves installing an alternative Python distribution, but " -"does not support arbitrary operating system-level packages:" -msgstr "" -"Um modelo semelhante envolve a instalação de uma distribuição alternativa " -"Python, mas não oferece suporte a pacotes arbitrários em nível de sistema " -"operacional:" - -#: ../source/overview.rst:293 -msgid "`Enthought Canopy `_" -msgstr "`Enthought Canopy `_" - -#: ../source/overview.rst:294 -msgid "`ActiveState ActivePython `_" -msgstr "`ActiveState ActivePython `_" - -#: ../source/overview.rst:295 -msgid "`WinPython `_" -msgstr "`WinPython `_" - -#: ../source/overview.rst:300 -msgid "Bringing your own Python executable" -msgstr "Trazendo seu próprio executável Python" - -#: ../source/overview.rst:302 -msgid "" -"Computing as we know it is defined by the ability to execute programs. Every " -"operating system natively supports one or more formats of program they can " -"natively execute." -msgstr "" -"A computação como a conhecemos é definida pela capacidade de executar " -"programas. Cada sistema operacional oferece suporte nativamente a um ou mais " -"formatos de programa que eles podem executar nativamente." - -#: ../source/overview.rst:306 -msgid "" -"There are many techniques and technologies which turn your Python program " -"into one of these formats, most of which involve embedding the Python " -"interpreter and any other dependencies into a single executable file." -msgstr "" -"Existem muitas técnicas e tecnologias que transformam seu programa Python em " -"um desses formatos, a maioria das quais envolve a incorporação do " -"interpretador Python e quaisquer outras dependências em um único arquivo " -"executável." - -#: ../source/overview.rst:311 -msgid "" -"This approach, called *freezing*, offers wide compatibility and seamless " -"user experience, though often requires multiple technologies, and a good " -"amount of effort." -msgstr "" -"Essa abordagem, chamada *congelamento*, oferece ampla compatibilidade e " -"experiência perfeita do usuário, embora muitas vezes exija múltiplas " -"tecnologias e uma boa quantidade de esforço." - -#: ../source/overview.rst:315 -msgid "A selection of Python freezers:" -msgstr "Uma seleção de congeladores Python:" - -#: ../source/overview.rst:317 -msgid "`pyInstaller `_ - Cross-platform" -msgstr "`pyInstaller `_ - Multiplataforma" - -#: ../source/overview.rst:318 -msgid "" -"`cx_Freeze `_ - Cross-platform" -msgstr "" -"`cx_Freeze `_ - Multiplataforma" - -#: ../source/overview.rst:319 -msgid "" -"`constructor `_ - For command-line " -"installers" -msgstr "" -"`constructor `_ - Para instaladores de " -"linha de comando" - -#: ../source/overview.rst:320 -msgid "`py2exe `_ - Windows only" -msgstr "`py2exe `_ - Windows apenas" - -#: ../source/overview.rst:321 -msgid "`py2app `_ - Mac only" -msgstr "`py2app `_ - Mac apenas" - -#: ../source/overview.rst:322 -msgid "" -"`bbFreeze `_ - Windows, Linux, Python 2 " -"only" -msgstr "" -"`bbFreeze `_ - Windows, Linux, Python 2 " -"apenas" - -#: ../source/overview.rst:323 -msgid "`osnap `_ - Windows and Mac" -msgstr "`osnap `_ - Windows e Mac" - -#: ../source/overview.rst:324 -msgid "`pynsist `_ - Windows only" -msgstr "`pynsist `_ - Windows apenas" - -#: ../source/overview.rst:326 -msgid "" -"Most of the above imply single-user deployments. For multi-component server " -"applications, see `Chef Omnibus `_." -msgstr "" -"A maioria dos itens acima implica em implantações de um único usuário. Para " -"aplicações de servidor com vários componentes, consulte `Chef Omnibus " -"`_." - -#: ../source/overview.rst:332 -msgid "Bringing your own userspace" -msgstr "Trazendo seu próprio espaço de usuário" - -#: ../source/overview.rst:334 -msgid "" -"An increasing number of operating systems -- including Linux, Mac OS, and " -"Windows -- can be set up to run applications packaged as lightweight images, " -"using a relatively modern arrangement often referred to as `operating-system-" -"level virtualization `_, or *containerization*." -msgstr "" -"Um número crescente de sistemas operacionais -- incluindo Linux, Mac OS e " -"Windows -- pode ser configurado para executar aplicações empacotadas como " -"imagens leves, usando um arranjo relativamente moderno, frequentemente " -"referido como `virtualização em nível de sistema operacional `_ ou " -"*conteinerização*." - -#: ../source/overview.rst:341 -msgid "" -"These techniques are mostly Python agnostic, because they package whole OS " -"filesystems, not just Python or Python packages." -msgstr "" -"Essas técnicas são principalmente Python agnósticas, porque empacotam " -"sistemas de arquivos inteiros de sistemas operacionais, não apenas Python ou " -"pacotes Python." - -#: ../source/overview.rst:344 -msgid "" -"Adoption is most extensive among Linux servers, where the technology " -"originated and where the technologies below work best:" -msgstr "" -"A adoção é mais extensa entre os servidores Linux, onde a tecnologia se " -"originou e onde as tecnologias abaixo funcionam melhor:" - -#: ../source/overview.rst:347 -msgid "`AppImage `_" -msgstr "`AppImage `_" - -#: ../source/overview.rst:348 -msgid "`Docker `_" -msgstr "`Docker `_" - -#: ../source/overview.rst:349 -msgid "`Flatpak `_" -msgstr "`Flatpak `_" - -#: ../source/overview.rst:350 -msgid "`Snapcraft `_" -msgstr "`Snapcraft `_" - -#: ../source/overview.rst:353 -msgid "Bringing your own kernel" -msgstr "Trazendo seu próprio kernel" - -#: ../source/overview.rst:355 -msgid "" -"Most operating systems support some form of classical virtualization, " -"running applications packaged as images containing a full operating system " -"of their own. Running these virtual machines, or VMs, is a mature approach, " -"widespread in data center environments." -msgstr "" -"A maioria dos sistemas operacionais oferece suporte a alguma forma de " -"virtualização clássica, executando aplicações empacotadas como imagens " -"contendo um sistema operacional completo próprio. Executar essas máquinas " -"virtuais, ou VMs, é uma abordagem madura, amplamente difundida em ambientes " -"de datacenter." - -#: ../source/overview.rst:360 -msgid "" -"These techniques are mostly reserved for larger scale deployments in data " -"centers, though certain complex applications can benefit from this " -"packaging. Technologies are Python agnostic, and include:" -msgstr "" -"Essas técnicas são reservadas principalmente para implantações em grande " -"escala em datacenters, embora algumas aplicativas complexas possam se " -"beneficiar desse pacote. As tecnologias são agnósticas ao Python e incluem:" - -#: ../source/overview.rst:364 -msgid "`Vagrant `_" -msgstr "`Vagrant `_" - -#: ../source/overview.rst:365 -msgid "" -"`VHD `_, `AMI `_, and `other formats `_" -msgstr "" -"`VHD `_, `AMI `_ e `outros formatos `_" - -#: ../source/overview.rst:366 -msgid "" -"`OpenStack `_ - A cloud " -"management system in Python, with extensive VM support" -msgstr "" -"`OpenStack `_ - Um sistema de " -"gerenciamento de nuvem em Python, com suporte extenso a VM" - -#: ../source/overview.rst:369 -msgid "Bringing your own hardware" -msgstr "Trazendo seu próprio hardware" - -#: ../source/overview.rst:371 -msgid "" -"The most all-encompassing way to ship your software would be to ship it " -"already-installed on some hardware. This way, your software's user would " -"require only electricity." -msgstr "" -"A maneira mais abrangente de enviar seu software seria enviá-lo já instalado " -"em algum hardware. Dessa forma, o usuário do seu software precisaria apenas " -"de eletricidade." - -#: ../source/overview.rst:375 -msgid "" -"Whereas the virtual machines described above are primarily reserved for the " -"tech-savvy, you can find hardware appliances being used by everyone from the " -"most advanced data centers to the youngest children." -msgstr "" -"Considerando que as máquinas virtuais descritas acima são reservadas " -"principalmente para os conhecedores de tecnologia, você pode encontrar " -"dispositivos de hardware sendo usados por todos, desde os datacenters mais " -"avançados até as crianças mais novas." - -#: ../source/overview.rst:379 -msgid "" -"Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the " -"datacenter or your users' homes. They plug and play, and you can call it a " -"day." -msgstr "" -"Incorpore seu código em um `Adafruit `_, `Micro Python `_ ou hardware mais poderoso executando Python e, em seguida, envie-o " -"para o datacenter ou para as casas de seus usuários. Eles conectam e estará " -"funcionando, e você pode encerrar o dia." - -#: ../source/overview.rst:389 -msgid "" -"The simplified gamut of technologies used to package Python applications." -msgstr "" -"A gama simplificada de tecnologias usadas para empacotar aplicações Python." - -#: ../source/overview.rst:392 -msgid "What about..." -msgstr "E quanto a..." - -#: ../source/overview.rst:394 -msgid "" -"The sections above can only summarize so much, and you might be wondering " -"about some of the more conspicuous gaps." -msgstr "" -"As seções acima resumem muito, e você pode estar se perguntando sobre " -"algumas das lacunas mais evidentes." - -#: ../source/overview.rst:398 -msgid "Operating system packages" -msgstr "Pacotes de sistema operacional" - -#: ../source/overview.rst:400 -msgid "" -"As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some " -"operating systems have package managers of their own. If you're very sure of " -"the operating system you're targeting, you can depend directly on a format " -"like `deb `_ (for Debian, " -"Ubuntu, etc.) or `RPM `_ " -"(for Red Hat, Fedora, etc.), and use that built-in package manager to take " -"care of installation, and even deployment. You can even use `FPM `_ to generate both deb " -"and RPMs from the same source." -msgstr "" -"Como mencionado em :ref:`depending-on-a-separate-ecosystem` acima, alguns " -"sistemas operacionais possuem gerenciadores de pacotes próprios. Se você " -"tiver certeza do sistema operacional que está almejando, pode depender " -"diretamente de um formato como `deb `_ (para Debian, Ubuntu , etc.) ou `RPM `_ (para Red Hat, Fedora, etc.) e " -"usar esse gerenciador de pacotes embutido para cuidar da instalação, e mesmo " -"implantação. Você pode até usar `FPM `_ para gerar deb e RPMs da mesma fonte." - -#: ../source/overview.rst:411 -msgid "" -"In most deployment pipelines, the OS package manager is just one piece of " -"the puzzle." -msgstr "" -"Na maioria das pipelines de implantação, o gerenciador de pacotes do sistema " -"operacional é apenas uma peça do quebra-cabeça." - -#: ../source/overview.rst:417 -msgid "" -"`Virtualenvs `_ have been an indispensable tool for multiple generations of Python " -"developer, but are slowly fading from view, as they are being wrapped by " -"higher-level tools. With packaging in particular, virtualenvs are used as a " -"primitive in `the dh-virtualenv tool `_ and `osnap `_, " -"both of which wrap virtualenvs in a self-contained way." -msgstr "" -"`Virtualenvs `_ têm sido uma ferramenta indispensável para várias gerações de " -"desenvolvedores Python, mas estão desaparecendo lentamente de vista, à " -"medida que estão sendo envoltos por ferramentas de nível superior. Com o " -"empacotamento em particular, virtualenvs são usados como primitivos na " -"`ferramenta dh-virtualenv `_ e `osnap `_, ambos " -"envolvem virtualenvs de uma forma independente." - -#: ../source/overview.rst:427 -msgid "" -"For production deployments, do not rely on running ``python -m pip install`` " -"from the Internet into a virtualenv, as one might do in a development " -"environment. The overview above is full of much better solutions." -msgstr "" -"Para implantações de produção, não dependa da execução de ``python -m pip " -"install`` da Internet em um virtualenv, como alguém pode fazer em um " -"ambiente de desenvolvimento. A visão geral acima está repleta de soluções " -"muito melhores." - -#: ../source/overview.rst:432 -msgid "Security" -msgstr "Segurança" - -#: ../source/overview.rst:434 -msgid "" -"The further down the gradient you come, the harder it gets to update " -"components of your package. Everything is more tightly bound together." -msgstr "" -"Quanto mais fundo você descer nas camadas, mais difícil será para atualizar " -"os componentes do seu pacote. Tudo está mais estreitamente ligado." - -#: ../source/overview.rst:437 -msgid "" -"For example, if a kernel security issue emerges, and you're deploying " -"containers, the host system's kernel can be updated without requiring a new " -"build on behalf of the application. If you deploy VM images, you'll need a " -"new build. Whether or not this dynamic makes one option more secure is still " -"a bit of an old debate, going back to the still-unsettled matter of `static " -"versus dynamic linking `_." -msgstr "" -"Por exemplo, se surgir um problema de segurança do kernel e você estiver " -"implantando contêineres, o kernel do sistema host pode ser atualizado sem a " -"necessidade de uma nova compilação em nome da aplicação. Se você implantar " -"imagens de VM, precisará de uma nova construção. Se essa dinâmica torna ou " -"não uma opção mais segura ainda é um debate antigo, voltando à questão ainda " -"não resolvida de `ligação estática versus ligação dinâmica `_." - -#: ../source/overview.rst:446 -msgid "Wrap up" -msgstr "Resumo" - -#: ../source/overview.rst:448 -msgid "" -"Packaging in Python has a bit of a reputation for being a bumpy ride. This " -"impression is mostly a byproduct of Python's versatility. Once you " -"understand the natural boundaries between each packaging solution, you begin " -"to realize that the varied landscape is a small price Python programmers pay " -"for using one of the most balanced, flexible languages available." -msgstr "" -"O empacotamento no Python tem a reputação de ser um percurso acidentado. " -"Essa impressão é principalmente um subproduto da versatilidade do Python. " -"Depois de entender os limites naturais entre cada solução de empacotamento, " -"você começa a perceber que o cenário variado é um preço pequeno Python que " -"os programadores pagam por usar uma das linguagens mais equilibradas e " -"flexíveis disponíveis." - -#: ../source/specifications/binary-distribution-format.rst:6 -msgid "Binary distribution format" -msgstr "Formato de distribuição binária" - -#: ../source/specifications/binary-distribution-format.rst:8 -msgid "" -"The binary distribution format (:term:`wheel `) was originally " -"defined in :pep:`427`. The current version of the specification is here." -msgstr "" -"O formato de distribuição binária (:term:`wheel `) foi originalmente " -"definido na :pep:`427`. A versão atual da especificação está aqui." - -#: ../source/specifications/binary-distribution-format.rst:13 -msgid "Abstract" -msgstr "Abstrato" - -#: ../source/specifications/binary-distribution-format.rst:15 -msgid "This PEP describes a built-package format for Python called \"wheel\"." -msgstr "" -"Esta PEP descreve um formato de pacote construído para Python chamado \"wheel" -"\"." - -#: ../source/specifications/binary-distribution-format.rst:17 -msgid "" -"A wheel is a ZIP-format archive with a specially formatted file name and the " -"``.whl`` extension. It contains a single distribution nearly as it would be " -"installed according to PEP 376 with a particular installation scheme. " -"Although a specialized installer is recommended, a wheel file may be " -"installed by simply unpacking into site-packages with the standard 'unzip' " -"tool while preserving enough information to spread its contents out onto " -"their final paths at any later time." -msgstr "" -"Um wheel é um arquivo em formato ZIP com um nome de arquivo formatado de " -"forma especial e a extensão ``.whl``. Ele contém uma única distribuição " -"quase como seria instalado de acordo com a PEP 376 com um esquema de " -"instalação particular. Embora um instalador especializado seja recomendado, " -"um arquivo wheel pode ser instalado simplesmente descompactando em pacotes " -"de sites com a ferramenta padrão de \"descompactação\" enquanto preserva " -"informações suficientes para espalhar seu conteúdo em seus caminhos finais a " -"qualquer momento." - -#: ../source/specifications/binary-distribution-format.rst:27 -msgid "PEP Acceptance" -msgstr "Aceitação da PEP" - -#: ../source/specifications/binary-distribution-format.rst:29 -msgid "" -"This PEP was accepted, and the defined wheel version updated to 1.0, by Nick " -"Coghlan on 16th February, 2013 [1]_" -msgstr "" -"Esta PEP foi aceita, e a versão do wheel definida foi atualizada para 1.0, " -"por Nick Coghlan em 16 de fevereiro de 2013 [1]_" - -#: ../source/specifications/binary-distribution-format.rst:34 -msgid "Rationale" -msgstr "Justificativa" - -#: ../source/specifications/binary-distribution-format.rst:36 -msgid "" -"Python needs a package format that is easier to install than sdist. Python's " -"sdist packages are defined by and require the distutils and setuptools build " -"systems, running arbitrary code to build-and-install, and re-compile, code " -"just so it can be installed into a new virtualenv. This system of " -"conflating build-install is slow, hard to maintain, and hinders innovation " -"in both build systems and installers." -msgstr "" -"Python precisa de um formato de pacote mais fácil de instalar do que sdist. " -"Os pacotes sdist do Python são definidos e requerem os sistemas de " -"construção distutils e setuptools, executando código arbitrário para " -"construir e instalar e recompilar o código apenas para que possa ser " -"instalado em um novo virtualenv. Este sistema de combinação entre construção " -"e instalação é lento, difícil de manter e impede a inovação tanto nos " -"sistemas de construção quanto nos instaladores." - -#: ../source/specifications/binary-distribution-format.rst:43 -msgid "" -"Wheel attempts to remedy these problems by providing a simpler interface " -"between the build system and the installer. The wheel binary package format " -"frees installers from having to know about the build system, saves time by " -"amortizing compile time over many installations, and removes the need to " -"install a build system in the target environment." -msgstr "" -"O wheel tenta remediar esses problemas fornecendo uma interface mais simples " -"entre o sistema de compilação e o instalador. O formato do pacote binário " -"wheel libera os instaladores de ter que saber sobre o sistema de compilação, " -"economiza tempo amortizando o tempo de compilação em muitas instalações e " -"elimina a necessidade de instalar um sistema de compilação no ambiente de " -"destino." - -#: ../source/specifications/binary-distribution-format.rst:52 -msgid "Details" -msgstr "Detalhes" - -#: ../source/specifications/binary-distribution-format.rst:55 -msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" -msgstr "Instalando um wheel 'distribution-1.0-py32-none-any.whl'" - -#: ../source/specifications/binary-distribution-format.rst:57 -msgid "Wheel installation notionally consists of two phases:" -msgstr "A instalação do wheel consiste, em teoria, em duas fases:" - -#: ../source/specifications/binary-distribution-format.rst:59 -msgid "Unpack." -msgstr "Desempacotar." - -#: ../source/specifications/binary-distribution-format.rst:61 -msgid "Parse ``distribution-1.0.dist-info/WHEEL``." -msgstr "Analisar ``distribution-1.0.dist-info/WHEEL``." - -#: ../source/specifications/binary-distribution-format.rst:62 -msgid "" -"Check that installer is compatible with Wheel-Version. Warn if minor " -"version is greater, abort if major version is greater." -msgstr "" -"Verificar se o instalador é compatível com a versão Wheel. Avisa se a versão " -"secundária é maior, cancela se a versão principal é maior." - -#: ../source/specifications/binary-distribution-format.rst:64 -msgid "" -"If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." -msgstr "" -"Se Root-Is-Purelib == 'true', descompactar o arquivo em purelib (sites-" -"packages)." - -#: ../source/specifications/binary-distribution-format.rst:66 -msgid "Else unpack archive into platlib (site-packages)." -msgstr "Caso contrário, descompactar o arquivo em platlib (site-packages)." - -#: ../source/specifications/binary-distribution-format.rst:68 -msgid "Spread." -msgstr "Espalhar." - -#: ../source/specifications/binary-distribution-format.rst:70 -msgid "" -"Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is " -"data) ``distribution-1.0.data/``." -msgstr "" -"O arquivo descompactado inclui ``distribution-1.0.dist-info/`` e (se houver " -"dados) ``distribution-1.0.data/``." - -#: ../source/specifications/binary-distribution-format.rst:72 -msgid "" -"Move each subtree of ``distribution-1.0.data/`` onto its destination path. " -"Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of " -"destination directories, such as ``distribution-1.0.data/(purelib|platlib|" -"headers|scripts|data)``. The initially supported paths are taken from " -"``distutils.command.install``." -msgstr "" -"Mover cada subárvore de ``distribution-1.0.data/`` em seu caminho de " -"destino. Cada subdiretório de ``distribution-1.0.data/`` é uma chave para um " -"dicionário de diretórios de destino, como ``distribution-1.0.data/(purelib|" -"platlib|headers|scripts|data)``. Os caminhos inicialmente suportados são " -"obtidos de ``distutils.command.install``." - -#: ../source/specifications/binary-distribution-format.rst:78 -msgid "" -"If applicable, update scripts starting with ``#!python`` to point to the " -"correct interpreter." -msgstr "" -"Se aplicável, atualizar os scripts começando com ``#!python`` para apontar " -"para o interpretador correto." - -#: ../source/specifications/binary-distribution-format.rst:80 -msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." -msgstr "" -"Atualizar ``distribution-1.0.dist-info/RECORD`` com os caminhos instalados." - -#: ../source/specifications/binary-distribution-format.rst:82 -msgid "Remove empty ``distribution-1.0.data`` directory." -msgstr "Remover o diretório vazio ``distribution-1.0.data``." - -#: ../source/specifications/binary-distribution-format.rst:83 -msgid "" -"Compile any installed .py to .pyc. (Uninstallers should be smart enough to " -"remove .pyc even if it is not mentioned in RECORD.)" -msgstr "" -"Compilar qualquer .py instalado em .pyc. (Os desinstaladores devem ser " -"inteligentes o suficiente para remover .pyc, mesmo que não seja mencionado " -"em RECORD.)" - -#: ../source/specifications/binary-distribution-format.rst:87 -msgid "Recommended installer features" -msgstr "Recursos de instalador recomendados" - -#: ../source/specifications/binary-distribution-format.rst:97 -msgid "Rewrite ``#!python``." -msgstr "Reescrever ``#!python``." - -#: ../source/specifications/binary-distribution-format.rst:90 -msgid "" -"In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/" -"``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!" -"python'``, rewrite to point to the correct interpreter. Unix installers may " -"need to add the +x bit to these files if the archive was created on Windows." -msgstr "" -"No wheel, os scripts são empacotados em ``{distribuição}-{versão}.data/" -"scripts/``. Se a primeira linha de um arquivo em ``scripts/`` começar " -"exatamente com ``b'#!python'``, reescreva para apontar para o interpretador " -"correto. Os instaladores do Unix podem precisar adicionar o bit +x a esses " -"arquivos se o arquivo tiver sido criado em Windows." - -#: ../source/specifications/binary-distribution-format.rst:96 -msgid "" -"The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI " -"script instead of a console script." -msgstr "" -"A convenção ``b'#!pythonw'`` é permitida. ``b'#!pythonw'`` indica um script " -"GUI ao invés de um script de console." - -#: ../source/specifications/binary-distribution-format.rst:102 -msgid "Generate script wrappers." -msgstr "Gerar script wrappers." - -#: ../source/specifications/binary-distribution-format.rst:100 -msgid "" -"In wheel, scripts packaged on Unix systems will certainly not have " -"accompanying .exe wrappers. Windows installers may want to add them during " -"install." -msgstr "" -"No wheel, scripts empacotados em sistemas Unix certamente não serão " -"acompanhados de wrappers .exe. Os instaladores Windows podem querer adicioná-" -"los durante a instalação." - -#: ../source/specifications/binary-distribution-format.rst:105 -msgid "Recommended archiver features" -msgstr "Recursos de arquivador recomendados" - -#: ../source/specifications/binary-distribution-format.rst:112 -msgid "Place ``.dist-info`` at the end of the archive." -msgstr "Colocar ``.dist-info`` no final do arquivo." - -#: ../source/specifications/binary-distribution-format.rst:108 -msgid "" -"Archivers are encouraged to place the ``.dist-info`` files physically at the " -"end of the archive. This enables some potentially interesting ZIP tricks " -"including the ability to amend the metadata without rewriting the entire " -"archive." -msgstr "" -"Os arquivadores são encorajados a colocar os arquivos ``.dist-info`` " -"fisicamente no final do repositório. Isso permite alguns truques de ZIP " -"potencialmente interessantes, incluindo a capacidade de corrigir os " -"metadados sem reescrever todo o arquivo." - -#: ../source/specifications/binary-distribution-format.rst:115 -msgid "File Format" -msgstr "Formato de arquivos" - -#: ../source/specifications/binary-distribution-format.rst:118 -msgid "File name convention" -msgstr "Convenção de nome de arquivos" - -#: ../source/specifications/binary-distribution-format.rst:120 -msgid "" -"The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-" -"{abi tag}-{platform tag}.whl``." -msgstr "" -"O nome de arquivo do wheel é ``{distribuição}-{versão}(-{tag da " -"construção})?-{tag do python}-{tag de abi}-{tag da plataforma}.whl``." - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "distribution" -msgstr "distribuição" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "Distribution name, e.g. 'django', 'pyramid'." -msgstr "Nome da distribuição (p.ex., 'django', 'pyramid')." - -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "Distribution version, e.g. 1.0." -msgstr "Versão da distribuição (p.ex., 1.0)." - -#: ../source/specifications/binary-distribution-format.rst:135 -msgid "build tag" -msgstr "tag da construção" - -#: ../source/specifications/binary-distribution-format.rst:130 -msgid "" -"Optional build number. Must start with a digit. Acts as a tie-breaker if " -"two wheel file names are the same in all other respects (i.e. name, version, " -"and other tags). Sort as an empty tuple if unspecified, else sort as a two-" -"item tuple with the first item being the initial digits as an ``int``, and " -"the second item being the remainder of the tag as a ``str``." -msgstr "" -"Número de construção opcional. Deve começar com um dígito. Atua como um " -"desempate se os nomes de arquivo de dois wheels forem iguais em todos os " -"outros aspectos (ou seja, nome, versão e outras tags). Classifique como uma " -"tupla vazia se não for especificado, caso contrário, classifique como uma " -"tupla de dois itens com o primeiro item sendo os dígitos iniciais como um " -"``int``, e o segundo item sendo o restante da tag como um ``str``." - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "language implementation and version tag" -msgstr "implementação da linguagem e tag de versão" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "E.g. 'py27', 'py2', 'py3'." -msgstr "p.ex., 'py27', 'py2', 'py3'." - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "abi tag" -msgstr "tag de abi" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "E.g. 'cp33m', 'abi3', 'none'." -msgstr "p.ex., 'cp33m', 'abi3', 'none'." - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "platform tag" -msgstr "tag da plataforma" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "E.g. 'linux_x86_64', 'any'." -msgstr "p.ex., 'linux_x86_64', 'any'." - -#: ../source/specifications/binary-distribution-format.rst:146 -msgid "" -"For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of " -"a package called 'distribution', and is compatible with Python 2.7 (any " -"Python 2.7 implementation), with no ABI (pure Python), on any CPU " -"architecture." -msgstr "" -"Por exemplo, ``distribution-1.0-1-py27-none-any.whl`` é a primeira " -"construção de um pacote chamado 'distribution' e é compatível com Python 2.7 " -"(qualquer implementação Python 2.7), com sem ABI (puro Python), em qualquer " -"arquitetura de CPU." - -#: ../source/specifications/binary-distribution-format.rst:151 -msgid "" -"The last three components of the filename before the extension are called " -"\"compatibility tags.\" The compatibility tags express the package's basic " -"interpreter requirements and are detailed in PEP 425." -msgstr "" -"Os últimos três componentes do nome do arquivo antes da extensão são " -"chamados de \"tags de compatibilidade\". As tags de compatibilidade " -"expressam os requisitos básicos do interpretador do pacote e são detalhadas " -"na PEP 425." - -#: ../source/specifications/binary-distribution-format.rst:156 -msgid "Escaping and Unicode" -msgstr "Escape e Unicode" - -#: ../source/specifications/binary-distribution-format.rst:158 -msgid "" -"As the components of the filename are separated by a dash (``-``, HYPHEN-" -"MINUS), this character cannot appear within any component. This is handled " -"as follows:" -msgstr "" -"Como os componentes do nome do arquivo são separados por um traço (``-``, " -"HYPHEN-MINUS), este caractere não pode aparecer em nenhum componente. Isso é " -"tratado da seguinte maneira:" - -#: ../source/specifications/binary-distribution-format.rst:161 -msgid "" -"In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE " -"and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent " -"to :pep:`503` normalisation followed by replacing ``-`` with ``_``." -msgstr "" -"Em nomes de distribuição, qualquer ocorrência de caracteres ``-_.`` (HYPHEN-" -"MINUS, LOW LINE e FULL STOP) deve ser substituída por ``_`` (LOW LINE). Isso " -"é equivalente à normalização da :pep:`503` seguida pela substituição de ``-" -"`` por ``_``." - -#: ../source/specifications/binary-distribution-format.rst:164 -msgid "" -"Version numbers should be normalised according to :pep:`440`. Normalised " -"version numbers cannot contain ``-``." -msgstr "" -"Os números de versão devem ser normalizados de acordo com a :pep:`440`. Os " -"números de versão normalizados não podem conter ``-``." - -#: ../source/specifications/binary-distribution-format.rst:166 -msgid "" -"The remaining components may not contain ``-`` characters, so no escaping is " -"necessary." -msgstr "" -"Os componentes restantes não podem conter caracteres ``-``, portanto, nenhum " -"escape é necessário." - -#: ../source/specifications/binary-distribution-format.rst:169 -msgid "" -"Tools producing wheels should verify that the filename components do not " -"contain ``-``, as the resulting file may not be processed correctly if they " -"do." -msgstr "" -"Ferramentas que produzem wheels devem verificar se os componentes do nome de " -"arquivo não contêm ``-``, pois o arquivo resultante pode não ser processado " -"corretamente se contiverem." - -#: ../source/specifications/binary-distribution-format.rst:172 -msgid "" -"The archive filename is Unicode. It will be some time before the tools are " -"updated to support non-ASCII filenames, but they are supported in this " -"specification." -msgstr "" -"O nome do arquivo é Unicode. Levará algum tempo até que as ferramentas sejam " -"atualizadas para oferecer suporte a nomes de arquivos não ASCII, mas eles " -"são suportados nesta especificação." - -#: ../source/specifications/binary-distribution-format.rst:176 -msgid "" -"The filenames *inside* the archive are encoded as UTF-8. Although some ZIP " -"clients in common use do not properly display UTF-8 filenames, the encoding " -"is supported by both the ZIP specification and Python's ``zipfile``." -msgstr "" -"Os nomes de arquivos *dentro* do arquivo são codificados como UTF-8. Embora " -"alguns clientes ZIP em uso comum não exibam nomes de arquivo UTF-8 " -"apropriadamente, a codificação é suportada pela especificação ZIP e pelo " -"``zipfile`` do Python." - -#: ../source/specifications/binary-distribution-format.rst:182 -msgid "File contents" -msgstr "Conteúdo dos arquivos" - -#: ../source/specifications/binary-distribution-format.rst:184 -msgid "" -"The contents of a wheel file, where {distribution} is replaced with the name " -"of the package, e.g. ``beaglevote`` and {version} is replaced with its " -"version, e.g. ``1.0.0``, consist of:" -msgstr "" -"O conteúdo de um arquivo wheel, onde {distribuição} é substituído pelo nome " -"do pacote, por exemplo, ``beaglevote`` e {version} é substituído por sua " -"versão, p.ex., ``1.0.0``, consiste em:" - -#: ../source/specifications/binary-distribution-format.rst:188 -msgid "" -"``/``, the root of the archive, contains all files to be installed in " -"``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and " -"``platlib`` are usually both ``site-packages``." -msgstr "" -"``/``, a raiz do arquivo, contém todos os arquivos a serem instalados em " -"``purelib`` ou ``platlib`` conforme especificado em ``WHEEL``. ``purelib`` e " -"``platlib`` são normalmente ``site-packages``." - -#: ../source/specifications/binary-distribution-format.rst:191 -msgid "``{distribution}-{version}.dist-info/`` contains metadata." -msgstr "``{distribuição}-{versão}.dist-info/`` contém metadados." - -#: ../source/specifications/binary-distribution-format.rst:192 -msgid "" -"``{distribution}-{version}.data/`` contains one subdirectory for each non-" -"empty install scheme key not already covered, where the subdirectory name is " -"an index into a dictionary of install paths (e.g. ``data``, ``scripts``, " -"``include``, ``purelib``, ``platlib``)." -msgstr "" -"``{distribuição}-{versão}.data/`` contém um subdiretório para cada chave de " -"esquema de instalação não vazia ainda não coberta, onde o nome do " -"subdiretório é um índice em um dicionário de caminhos de instalação (p.ex., " -"``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." - -#: ../source/specifications/binary-distribution-format.rst:196 -msgid "" -"Python scripts must appear in ``scripts`` and begin with exactly ``b'#!" -"python'`` in order to enjoy script wrapper generation and ``#!python`` " -"rewriting at install time. They may have any or no extension." -msgstr "" -"Scripts Python devem aparecer em ``scripts`` e começar exatamente com ``b'#!" -"python'`` para desfrutar da geração do wrapper de script e reescrever ``#!" -"python`` no momento da instalação. Eles podem ter qualquer ou nenhuma " -"extensão." - -#: ../source/specifications/binary-distribution-format.rst:200 -msgid "" -"``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or " -"greater format metadata." -msgstr "" -"``{distribuição}-{versão}.dist-info/METADATA`` é Metadata versão 1.1 ou " -"metadados de formato superior." - -#: ../source/specifications/binary-distribution-format.rst:202 -msgid "" -"``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive " -"itself in the same basic key: value format::" -msgstr "" -"``{distribuição}-{versão}.dist-info/WHEEL`` são metadados sobre p arquivo em " -"si no mesmo formato \"chave: valor\"::" - -#: ../source/specifications/binary-distribution-format.rst:212 -msgid "``Wheel-Version`` is the version number of the Wheel specification." -msgstr "``Wheel-Version`` é o número de versão da especificação Wheel." - -#: ../source/specifications/binary-distribution-format.rst:213 -msgid "" -"``Generator`` is the name and optionally the version of the software that " -"produced the archive." -msgstr "" -"``Generator`` é o nome e, opcionalmente, a versão do software que produziu o " -"arquivo." - -#: ../source/specifications/binary-distribution-format.rst:215 -msgid "" -"``Root-Is-Purelib`` is true if the top level directory of the archive should " -"be installed into purelib; otherwise the root should be installed into " -"platlib." -msgstr "" -"``Root-Is-Purelib`` é verdadeiro se o diretório de nível superior do arquivo " -"deve ser instalado em purelib; caso contrário, a raiz deve ser instalada no " -"platlib." - -#: ../source/specifications/binary-distribution-format.rst:218 -msgid "" -"``Tag`` is the wheel's expanded compatibility tags; in the example the " -"filename would contain ``py2.py3-none-any``." -msgstr "" -"``Tag`` são as tags de compatibilidade expandida do wheel; no exemplo, o " -"nome do arquivo conteria ``py2.py3-none-any``." - -#: ../source/specifications/binary-distribution-format.rst:220 -msgid "" -"``Build`` is the build number and is omitted if there is no build number." -msgstr "" -"``Build`` é o número da construção e é omitido se não houver número da " -"construção." - -#: ../source/specifications/binary-distribution-format.rst:221 -msgid "" -"A wheel installer should warn if Wheel-Version is greater than the version " -"it supports, and must fail if Wheel-Version has a greater major version than " -"the version it supports." -msgstr "" -"Um instalador de wheel deve avisar se Wheel-Version é maior do que a versão " -"que ele suporta, e deve falhar se Wheel-Version tiver uma versão principal " -"maior do que a versão que ele suporta." - -#: ../source/specifications/binary-distribution-format.rst:224 -msgid "" -"Wheel, being an installation format that is intended to work across multiple " -"versions of Python, does not generally include .pyc files." -msgstr "" -"O Wheel, sendo um formato de instalação destinado a funcionar em várias " -"versões do Python, geralmente não inclui arquivos .pyc." - -#: ../source/specifications/binary-distribution-format.rst:226 -msgid "Wheel does not contain setup.py or setup.cfg." -msgstr "Wheel não contém setup.py ou setup.cfg." - -#: ../source/specifications/binary-distribution-format.rst:228 -msgid "" -"This version of the wheel specification is based on the distutils install " -"schemes and does not define how to install files to other locations. The " -"layout offers a superset of the functionality provided by the existing " -"wininst and egg binary formats." -msgstr "" -"Esta versão da especificação do wheel é baseada nos esquemas de instalação " -"do distutils e não define como instalar arquivos em outros locais. O layout " -"oferece um superconjunto da funcionalidade fornecida pelos formatos binários " -"wininst e egg existentes." - -#: ../source/specifications/binary-distribution-format.rst:235 -#: ../source/specifications/recording-installed-packages.rst:35 -msgid "The .dist-info directory" -msgstr "O diretório .dist-info" - -#: ../source/specifications/binary-distribution-format.rst:237 -msgid "" -"Wheel .dist-info directories include at a minimum METADATA, WHEEL, and " -"RECORD." -msgstr "" -"Os diretórios .dist-info de wheels incluem no mínimo METADATA, WHEEL e " -"RECORD." - -#: ../source/specifications/binary-distribution-format.rst:239 -msgid "" -"METADATA is the package metadata, the same format as PKG-INFO as found at " -"the root of sdists." -msgstr "" -"METADATA são os metadados do pacote, o mesmo formato do PKG-INFO encontrado " -"na raiz dos sdists." - -#: ../source/specifications/binary-distribution-format.rst:241 -msgid "WHEEL is the wheel metadata specific to a build of the package." -msgstr "" -"WHEEL são os metadados de wheel específicos para uma construção do pacote." - -#: ../source/specifications/binary-distribution-format.rst:242 -msgid "" -"RECORD is a list of (almost) all the files in the wheel and their secure " -"hashes. Unlike PEP 376, every file except RECORD, which cannot contain a " -"hash of itself, must include its hash. The hash algorithm must be sha256 or " -"better; specifically, md5 and sha1 are not permitted, as signed wheel files " -"rely on the strong hashes in RECORD to validate the integrity of the archive." -msgstr "" -"RECORD é uma lista de (quase) todos os arquivos no wheel seus hashes " -"seguros. Ao contrário da PEP 376, nenhum arquivo, exceto RECORD, pode conter " -"um hash de si mesmo, deve incluir seu hash. O algoritmo hash deve ser sha256 " -"ou melhor; especificamente, md5 e sha1 não são permitidos, pois os arquivos " -"wheel assinados contam com hashes fortes em RECORD para validar a " -"integridade do arquivo." - -#: ../source/specifications/binary-distribution-format.rst:248 -msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." -msgstr "INSTALLER e REQUESTED da PEP 376 não são incluídos no arquivo." - -#: ../source/specifications/binary-distribution-format.rst:249 -msgid "" -"RECORD.jws is used for digital signatures. It is not mentioned in RECORD." -msgstr "" -"RECORD.jws é usado para assinaturas digitais. Não é mencionado no RECORD." - -#: ../source/specifications/binary-distribution-format.rst:251 -msgid "" -"RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME " -"signatures to secure their wheel files. It is not mentioned in RECORD." -msgstr "" -"RECORD.p7s é permitido como cortesia para qualquer pessoa que prefira usar " -"assinaturas S/MIME para proteger seus arquivos wheels. Não é mencionado no " -"RECORD." - -#: ../source/specifications/binary-distribution-format.rst:254 -msgid "" -"During extraction, wheel installers verify all the hashes in RECORD against " -"the file contents. Apart from RECORD and its signatures, installation will " -"fail if any file in the archive is not both mentioned and correctly hashed " -"in RECORD." -msgstr "" -"Durante a extração, os instaladores de wheels verificam todos os hashes em " -"RECORD em relação ao conteúdo do arquivo. Além de RECORD e suas assinaturas, " -"a instalação falhará se qualquer arquivo no arquivo não for mencionado e com " -"hash correto em RECORD." - -#: ../source/specifications/binary-distribution-format.rst:261 -msgid "The .data directory" -msgstr "O diretório .data" - -#: ../source/specifications/binary-distribution-format.rst:263 -msgid "" -"Any file that is not normally installed inside site-packages goes into the ." -"data directory, named as the .dist-info directory but with the .data/ " -"extension::" -msgstr "" -"Qualquer arquivo que não é normalmente instalado dentro de site-packages vai " -"para o diretório .data, nomeado como o diretório .dist-info, mas com a " -"extensão .data/::" - -#: ../source/specifications/binary-distribution-format.rst:271 -msgid "" -"The .data directory contains subdirectories with the scripts, headers, " -"documentation and so forth from the distribution. During installation the " -"contents of these subdirectories are moved onto their destination paths." -msgstr "" -"O diretório .data contém subdiretórios com os scripts, cabeçalhos, " -"documentação e assim por diante da distribuição. Durante a instalação, o " -"conteúdo desses subdiretórios é movido para seus caminhos de destino." - -#: ../source/specifications/binary-distribution-format.rst:277 -msgid "Signed wheel files" -msgstr "Arquivos wheels assinados" - -#: ../source/specifications/binary-distribution-format.rst:279 -msgid "" -"Wheel files include an extended RECORD that enables digital signatures. PEP " -"376's RECORD is altered to include a secure hash " -"``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with " -"no trailing = characters) as the second column instead of an md5sum. All " -"possible entries are hashed, including any generated files such as .pyc " -"files, but not RECORD which cannot contain its own hash. For example::" -msgstr "" -"Os arquivos wheels incluem um RECORD estendido que permite assinaturas " -"digitais. O RECORD da PEP 376 foi alterado para incluir um hash seguro " -"``digestname=urlsafe_b64encode_nopad(digest)`` (codificação base64 de " -"urlsafe sem caracteres ao final =) como a segunda coluna em vez de um " -"md5sum. Todas as entradas possíveis são hash, incluindo quaisquer arquivos " -"gerados, como arquivos .pyc, mas não RECORD, que não pode conter seu próprio " -"hash. Por exemplo::" - -#: ../source/specifications/binary-distribution-format.rst:290 -msgid "" -"The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD " -"at all since they can only be added after RECORD is generated. Every other " -"file in the archive must have a correct hash in RECORD or the installation " -"will fail." -msgstr "" -"O(s) arquivo(s) de assinatura RECORD.jws e RECORD.p7s não são mencionados em " -"RECORD, pois eles só podem ser adicionados após RECORD ser gerado. Todos os " -"outros arquivos no arquivo devem ter um hash correto em RECORD ou a " -"instalação falhará." - -#: ../source/specifications/binary-distribution-format.rst:295 -msgid "" -"If JSON web signatures are used, one or more JSON Web Signature JSON " -"Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to " -"RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD " -"as the signature's JSON payload::" -msgstr "" -"Se assinaturas da web JSON forem usadas, uma ou mais assinaturas JSON Web " -"Signature JSON Serialization (JWS-JS) serão armazenadas em um arquivo " -"RECORD.jws adjacente a RECORD. JWS é usado para assinar RECORD incluindo o " -"hash SHA-256 de RECORD como a carga JSON da assinatura::" - -#: ../source/specifications/binary-distribution-format.rst:302 -msgid "(The hash value is the same format used in RECORD.)" -msgstr "(O valor hash é o mesmo formato usado em RECORD.)" - -#: ../source/specifications/binary-distribution-format.rst:304 -msgid "" -"If RECORD.p7s is used, it must contain a detached S/MIME format signature of " -"RECORD." -msgstr "" -"Se RECORD.p7s for usado, ele deve conter uma assinatura de formato S/MIME " -"separada de RECORD." - -#: ../source/specifications/binary-distribution-format.rst:307 -msgid "" -"A wheel installer is not required to understand digital signatures but MUST " -"verify the hashes in RECORD against the extracted file contents. When the " -"installer checks file hashes against RECORD, a separate signature checker " -"only needs to establish that RECORD matches the signature." -msgstr "" -"Um instalador de wheel não precisa entender as assinaturas digitais, mas " -"DEVE verificar os hashes em RECORD em relação ao conteúdo do arquivo " -"extraído. Quando o instalador verifica os hashes do arquivo em relação ao " -"RECORD, um verificador de assinatura separado só precisa estabelecer se " -"RECORD corresponde à assinatura." - -#: ../source/specifications/binary-distribution-format.rst:312 -msgid "See" -msgstr "Veja" - -#: ../source/specifications/binary-distribution-format.rst:314 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" -msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" - -#: ../source/specifications/binary-distribution-format.rst:315 -msgid "" -"http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" -msgstr "" -"http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" - -#: ../source/specifications/binary-distribution-format.rst:316 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" -msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" - -#: ../source/specifications/binary-distribution-format.rst:317 -msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" -msgstr "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" - -#: ../source/specifications/binary-distribution-format.rst:321 -msgid "Comparison to .egg" -msgstr "Comparação com .egg" - -#: ../source/specifications/binary-distribution-format.rst:323 -msgid "" -"Wheel is an installation format; egg is importable. Wheel archives do not " -"need to include .pyc and are less tied to a specific Python version or " -"implementation. Wheel can install (pure Python) packages built with previous " -"versions of Python so you don't always have to wait for the packager to " -"catch up." -msgstr "" -"Wheel é um formato de instalação; ovo é importável. Os arquivos wheel não " -"precisam incluir .pyc e estão menos vinculados a uma versão ou implementação " -"específica do Python. O Wheel pode instalar pacotes (puro Python) " -"construídos com versões anteriores do Python, portanto, você nem sempre " -"precisa esperar que o empacotador os atualize." - -#: ../source/specifications/binary-distribution-format.rst:328 -msgid "" -"Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible " -"with the new world of Python packaging and the new concepts it brings." -msgstr "" -"O Wheel usa diretórios .dist-info; egg usa .egg-info. Wheel é compatível com " -"o novo mundo da empacotamento de Python e os novos conceitos que ele traz." - -#: ../source/specifications/binary-distribution-format.rst:331 -msgid "" -"Wheel has a richer file naming convention for today's multi-implementation " -"world. A single wheel archive can indicate its compatibility with a number " -"of Python language versions and implementations, ABIs, and system " -"architectures. Historically the ABI has been specific to a CPython release, " -"wheel is ready for the stable ABI." -msgstr "" -"O Wheel tem uma convenção de nomenclatura de arquivo mais rica para o mundo " -"de múltiplas implementações de hoje. Um único arquivo de wheel pode indicar " -"sua compatibilidade com várias versões e implementações de linguagem Python, " -"ABIs e arquiteturas de sistema. Historicamente, a ABI tem sido específica " -"para uma versão do CPython, o wheel estando pronto para a ABI estável." - -#: ../source/specifications/binary-distribution-format.rst:337 -msgid "" -"Wheel is lossless. The first wheel implementation bdist_wheel always " -"generates egg-info, and then converts it to a .whl. It is also possible to " -"convert existing eggs and bdist_wininst distributions." -msgstr "" -"O wheel não causa perdas. A implementação do primeiro wheel, bdist_wheel, " -"sempre gera egg-info e, então, as converte em .whl. Também é possível " -"converter eggs existentes e distribuições de bdist_wininst." - -#: ../source/specifications/binary-distribution-format.rst:341 -msgid "" -"Wheel is versioned. Every wheel file contains the version of the wheel " -"specification and the implementation that packaged it. Hopefully the next " -"migration can simply be to Wheel 2.0." -msgstr "" -"Wheel é versionado. Cada arquivo wheel contém a versão da especificação " -"wheel e a implementação que a empacotou. Esperançosamente, a próxima " -"migração pode ser simplesmente para Wheel 2.0." - -#: ../source/specifications/binary-distribution-format.rst:344 -msgid "Wheel is a reference to the other Python." -msgstr "Wheel é uma referência a outro Python." - -#: ../source/specifications/binary-distribution-format.rst:348 -msgid "FAQ" -msgstr "FAQ" - -#: ../source/specifications/binary-distribution-format.rst:352 -msgid "Wheel defines a .data directory. Should I put all my data there?" -msgstr "Wheel define um diretório .data. Devo colocar todos os meus dados lá?" - -#: ../source/specifications/binary-distribution-format.rst:354 -msgid "" -"This specification does not have an opinion on how you should organize your " -"code. The .data directory is just a place for any files that are not " -"normally installed inside ``site-packages`` or on the PYTHONPATH. In other " -"words, you may continue to use ``pkgutil.get_data(package, resource)`` even " -"though *those* files will usually not be distributed in *wheel's* ``.data`` " -"directory." -msgstr "" -"Esta especificação não tem uma opinião sobre como você deve organizar seu " -"código. O diretório .data é apenas um lugar para quaisquer arquivos que não " -"são normalmente instalados dentro de ``site-packages`` ou no PYTHONPATH. Em " -"outras palavras, você pode continuar a usar ``pkgutil.get_data(pacote, " -"recurso)`` ainda que *esses* arquivos normalmente não sejam distribuídos no " -"diretório ``.data`` do *wheel*." - -#: ../source/specifications/binary-distribution-format.rst:363 -msgid "Why does wheel include attached signatures?" -msgstr "Por que o wheel inclui assinaturas anexadas?" - -#: ../source/specifications/binary-distribution-format.rst:365 -msgid "" -"Attached signatures are more convenient than detached signatures because " -"they travel with the archive. Since only the individual files are signed, " -"the archive can be recompressed without invalidating the signature or " -"individual files can be verified without having to download the whole " -"archive." -msgstr "" -"Assinaturas anexadas são mais convenientes do que assinaturas separadas " -"porque elas viajam com o arquivo. Uma vez que apenas os arquivos individuais " -"são assinados, o arquivo pode ser recompactado sem invalidar a assinatura ou " -"os arquivos individuais podem ser verificados sem ter que baixar todo o " -"arquivo." - -#: ../source/specifications/binary-distribution-format.rst:373 -msgid "Why does wheel allow JWS signatures?" -msgstr "Por que wheel permite assinaturas JWS?" - -#: ../source/specifications/binary-distribution-format.rst:375 -msgid "" -"The JOSE specifications of which JWS is a part are designed to be easy to " -"implement, a feature that is also one of wheel's primary design goals. JWS " -"yields a useful, concise pure-Python implementation." -msgstr "" -"As especificações JOSE das quais o JWS faz parte foram projetadas para serem " -"fáceis de implementar, um recurso que também é um dos principais objetivos " -"do projeto da roda. O JWS produz uma implementação puro Python concisa e " -"útil." - -#: ../source/specifications/binary-distribution-format.rst:381 -msgid "Why does wheel also allow S/MIME signatures?" -msgstr "Por que wheel também permite assinaturas S/MIME?" - -#: ../source/specifications/binary-distribution-format.rst:383 -msgid "" -"S/MIME signatures are allowed for users who need or want to use existing " -"public key infrastructure with wheel." -msgstr "" -"Assinaturas S/MIME são permitidas para usuários que precisam ou querem usar " -"uma infraestrutura de chaves públicas existente com o wheel." - -#: ../source/specifications/binary-distribution-format.rst:386 -msgid "" -"Signed packages are only a basic building block in a secure package update " -"system. Wheel only provides the building block." -msgstr "" -"Pacotes assinados são apenas um bloco de construção básico em um sistema de " -"atualização segura de pacotes. Wheel só fornece o bloco de construção." - -#: ../source/specifications/binary-distribution-format.rst:391 -msgid "What's the deal with \"purelib\" vs. \"platlib\"?" -msgstr "Qual é a diferença entre \"purelib\" e \"platlib\"?" - -#: ../source/specifications/binary-distribution-format.rst:393 -msgid "" -"Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is " -"significant on some platforms. For example, Fedora installs pure Python " -"packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent " -"packages to '/usr/lib64/pythonX.Y/site-packages'." -msgstr "" -"O Wheel preserva a distinção \"purelib\" vs. \"platlib\", que é " -"significativa em algumas plataformas. Por exemplo, o Fedora instala pacotes " -"puro Python em '/usr/lib/pythonX.Y/site-packages' e pacotes dependentes de " -"plataforma em '/usr/lib64/pythonX.Y/site-packages'." - -#: ../source/specifications/binary-distribution-format.rst:398 -msgid "" -"A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-" -"{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: " -"true\" with those same files in the root, and it is legal to have files in " -"both the \"purelib\" and \"platlib\" categories." -msgstr "" -"Um wheel com \"Root-Is-Purelib: false\" com todos os seus arquivos em " -"``{nome}-{versão}.data/purelib`` é equivalente a um wheel com \"Root-Is-" -"Purelib: true\" com os mesmos arquivos na raiz, e é válido ter arquivos nas " -"categorias \"purelib\" e \"platlib\"." - -#: ../source/specifications/binary-distribution-format.rst:403 -msgid "" -"In practice a wheel should have only one of \"purelib\" or \"platlib\" " -"depending on whether it is pure Python or not and those files should be at " -"the root with the appropriate setting given for \"Root-is-purelib\"." -msgstr "" -"Na prática, um wheel deve ter apenas um de \"purelib\" ou \"platlib\" " -"dependendo se é puro Python ou não e esses arquivos devem estar na raiz com " -"a configuração apropriada fornecida para \"Root-is-purelib\"." - -#: ../source/specifications/binary-distribution-format.rst:409 -msgid "Is it possible to import Python code directly from a wheel file?" -msgstr "É possível importar código Python diretamente de um arquivo wheel?" - -#: ../source/specifications/binary-distribution-format.rst:411 -msgid "" -"Technically, due to the combination of supporting installation via simple " -"extraction and using an archive format that is compatible with " -"``zipimport``, a subset of wheel files *do* support being placed directly on " -"``sys.path``. However, while this behaviour is a natural consequence of the " -"format design, actually relying on it is generally discouraged." -msgstr "" -"Tecnicamente, devido à combinação de suporte de instalação via extração " -"simples e usando um formato de arquivo compatível com ``zipimport``, um " -"subconjunto de arquivos wheel oferece suporte a ser colocado diretamente no " -"``sys.path``. No entanto, embora esse comportamento seja uma consequência " -"natural do design do formato, não é recomendável confiar nele." - -#: ../source/specifications/binary-distribution-format.rst:417 -msgid "" -"Firstly, wheel *is* designed primarily as a distribution format, so skipping " -"the installation step also means deliberately avoiding any reliance on " -"features that assume full installation (such as being able to use standard " -"tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in " -"a way that can be properly tracked for auditing and security update " -"purposes, or integrating fully with the standard build machinery for C " -"extensions by publishing header files in the appropriate place)." -msgstr "" -"Em primeiro lugar, o wheel *é* projetado principalmente como um formato de " -"distribuição, então pular a etapa de instalação também significa evitar " -"deliberadamente qualquer dependência de recursos que pressupõem a instalação " -"completa (como ser capaz de usar ferramentas padrão como ``pip`` e " -"``virtualenv`` para capturar e gerenciar dependências de uma forma que " -"possam ser devidamente rastreadas para fins de auditoria e atualização de " -"segurança, ou integração completa com o maquinário de construção padrão para " -"extensões C, publicando arquivos de cabeçalho no local apropriado)." - -#: ../source/specifications/binary-distribution-format.rst:426 -msgid "" -"Secondly, while some Python software is written to support running directly " -"from a zip archive, it is still common for code to be written assuming it " -"has been fully installed. When that assumption is broken by trying to run " -"the software from a zip archive, the failures can often be obscure and hard " -"to diagnose (especially when they occur in third party libraries). The two " -"most common sources of problems with this are the fact that importing C " -"extensions from a zip archive is *not* supported by CPython (since doing so " -"is not supported directly by the dynamic loading machinery on any platform) " -"and that when running from a zip archive the ``__file__`` attribute no " -"longer refers to an ordinary filesystem path, but to a combination path that " -"includes both the location of the zip archive on the filesystem and the " -"relative path to the module inside the archive. Even when software correctly " -"uses the abstract resource APIs internally, interfacing with external " -"components may still require the availability of an actual on-disk file." -msgstr "" -"Em segundo lugar, embora alguns softwares Python sejam escritos para " -"suportar a execução direta de um arquivo zip, ainda é comum que o código " -"seja escrito assumindo que foi totalmente instalado. Quando essa suposição é " -"quebrada ao tentar executar o software a partir de um arquivo zip, as falhas " -"podem frequentemente ser obscuras e difíceis de diagnosticar (especialmente " -"quando ocorrem em bibliotecas de terceiros). As duas fontes mais comuns de " -"problemas com isso são o fato de que a importação de extensões C de um " -"arquivo zip *não* ser suportada pelo CPython (uma vez que fazer isso não é " -"suportado diretamente pela máquina de carregamento dinâmico em qualquer " -"plataforma) e que quando executando a partir de um arquivo zip, o atributo " -"``__file__`` não se refere mais a um caminho de sistema de arquivos comum, " -"mas a um caminho de combinação que inclui tanto a localização do arquivo zip " -"no sistema de arquivos quanto o caminho relativo para o módulo dentro do " -"arquivo. Mesmo quando o software usa corretamente as APIs de recursos " -"abstratos internamente, a interface com componentes externos ainda pode " -"exigir a disponibilidade de um arquivo real no disco." - -#: ../source/specifications/binary-distribution-format.rst:443 -msgid "" -"Like metaclasses, monkeypatching and metapath importers, if you're not " -"already sure you need to take advantage of this feature, you almost " -"certainly don't need it. If you *do* decide to use it anyway, be aware that " -"many projects will require a failure to be reproduced with a fully installed " -"package before accepting it as a genuine bug." -msgstr "" -"Como metaclasses, *monkeypatching* e importadores de metacaminho, se você " -"ainda não tem certeza de que precisa tirar proveito desse recurso, é quase " -"certo que não precisa dele. Se você decidir usá-lo de qualquer maneira, " -"esteja ciente de que muitos projetos exigirão que uma falha seja reproduzida " -"com um pacote totalmente instalado antes de aceitá-lo como um bug genuíno." - -#: ../source/specifications/binary-distribution-format.rst:450 -msgid "Changes" -msgstr "Alterações" - -#: ../source/specifications/binary-distribution-format.rst:452 -msgid "Since :pep:`427`, this specification has changed as follows:" -msgstr "Desde a :pep:`427`, esta especificação mudou da seguinte forma:" - -#: ../source/specifications/binary-distribution-format.rst:454 -msgid "" -"The rules on escaping in wheel filenames were revised, to bring them into " -"line with what popular tools actually do (February 2021)." -msgstr "" -"As regras sobre como escapar em nomes de arquivos wheel foram revisadas, " -"para alinhá-las com o que as ferramentas populares realmente fazem (" -"fevereiro de 2021)." - -#: ../source/specifications/binary-distribution-format.rst:461 -msgid "" -"PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-" -"February/124103.html)" -msgstr "" -"Aceitação da PEP (https://mail.python.org/pipermail/python-dev/2013-February/" -"124103.html)" - -#: ../source/specifications/binary-distribution-format.rst:466 -msgid "Appendix" -msgstr "Apêndice" - -#: ../source/specifications/binary-distribution-format.rst:468 -msgid "Example urlsafe-base64-nopad implementation::" -msgstr "Exemplo de implementação de urlsafe-base64-nopad::" - -#: ../source/specifications/binary-distribution-format.rst:482 -msgid "Copyright" -msgstr "Diretos autorais" - -#: ../source/specifications/binary-distribution-format.rst:484 -msgid "This document has been placed into the public domain." -msgstr "Este documento foi colocado em domínio público." - -#: ../source/specifications/core-metadata.rst:5 -msgid "Core metadata specifications" -msgstr "Especificações de metadados principais" - -#: ../source/specifications/core-metadata.rst:7 -msgid "" -"Fields defined in the following specification should be considered valid, " -"complete and not subject to change. The required fields are:" -msgstr "" -"Os campos definidos nas especificações a seguir devem ser considerados " -"válidos, completos e não sujeitos a alterações. Os campos obrigatórios são:" - -#: ../source/specifications/core-metadata.rst:10 -msgid "``Metadata-Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:11 -msgid "``Name``" -msgstr "``Name``" - -#: ../source/specifications/core-metadata.rst:12 -msgid "``Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:14 -msgid "All the other fields are optional." -msgstr "Todos os outros campos são opcionais." - -#: ../source/specifications/core-metadata.rst:16 -msgid "" -"The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats " -"have been revised several times, and exactly which email RFC applies to " -"packaging metadata is not specified. In the absence of a precise definition, " -"the practical standard is set by what the standard library :mod:`python:" -"email.parser` module can parse using the :data:`~.python:email.policy." -"compat32` policy." -msgstr "" -"O formato de arquivo padrão para metadados (incluindo em :doc:`wheels " -"` e :doc:`projetos instalados `) é baseado no formato de cabeçalhos de e-mail. No " -"entanto, os formatos de e-mail foram revisados várias vezes e não é " -"especificado exatamente qual RFC de e-mail se aplica aos metadados do " -"pacote. Na ausência de uma definição precisa, o padrão prático é definido " -"pelo que o módulo da biblioteca padrão :mod:`python:email.parser` pode " -"analisar usando a política :data:`~.python:email.policy.compat32`." - -#: ../source/specifications/core-metadata.rst:25 -msgid "" -"Although :pep:`566` defined a way to transform metadata into a JSON-" -"compatible dictionary, this is not yet used as a standard interchange " -"format. The need for tools to work with years worth of existing packages " -"makes it difficult to shift to a new format." -msgstr "" -"Embora a :pep:`566` tenha definido uma maneira de transformar metadados em " -"um dicionário compatível com JSON, isso ainda não é usado como um formato de " -"intercâmbio padrão. A necessidade de ferramentas para trabalhar com anos de " -"pacotes existentes torna difícil mudar para um novo formato." - -#: ../source/specifications/core-metadata.rst:30 -msgid "" -"*Interpreting old metadata:* In :pep:`566`, the version specifier field " -"format specification was relaxed to accept the syntax used by popular " -"publishing tools (namely to remove the requirement that version specifiers " -"must be surrounded by parentheses). Metadata consumers may want to use the " -"more relaxed formatting rules even for metadata files that are nominally " -"less than version 2.1." -msgstr "" -"*Interpretando metadados antigos:* Na :pep:`566`, a especificação do formato " -"do campo do especificador de versão foi relaxada para aceitar a sintaxe " -"usada por ferramentas de publicação populares (nomeadamente para remover o " -"requisito de que os especificadores de versão devem estar entre parênteses). " -"Os consumidores de metadados podem querer usar regras de formatação mais " -"relaxadas, mesmo para arquivos de metadados que são nominalmente inferiores " -"à versão 2.1." - -#: ../source/specifications/core-metadata.rst:41 -msgid "Metadata-Version" -msgstr "Metadata-Version" - -#: ../source/specifications/core-metadata.rst:45 -msgid "" -"Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", " -"\"2.1\" and \"2.2\"." -msgstr "" -"Versão do formato de arquivo; valores válidos são \"1.0\", \"1.1\", \"1.2\", " -"\"2.1\" e \"2.2\"." - -#: ../source/specifications/core-metadata.rst:48 -msgid "" -"Automated tools consuming metadata SHOULD warn if ``metadata_version`` is " -"greater than the highest version they support, and MUST fail if " -"``metadata_version`` has a greater major version than the highest version " -"they support (as described in :pep:`440`, the major version is the value " -"before the first dot)." -msgstr "" -"Ferramentas automatizadas que consomem metadados DEVEM avisar se " -"``metadata_version`` é maior que a versão mais alta à qual oferecem suporte, " -"e DEVEM falhar se ``metadata_version`` tem uma versão maior do que a versão " -"mais alta à qual oferecem suporte (como descrito na :pep:`440`, a versão " -"principal é o valor antes do primeiro ponto)." - -#: ../source/specifications/core-metadata.rst:54 -msgid "" -"For broader compatibility, build tools MAY choose to produce distribution " -"metadata using the lowest metadata version that includes all of the needed " -"fields." -msgstr "" -"Para uma compatibilidade mais ampla, as ferramentas de construção PODEM " -"escolher produzir metadados de distribuição usando a versão de metadados " -"mais baixa que inclui todos os campos necessários." - -#: ../source/specifications/core-metadata.rst:58 -#: ../source/specifications/core-metadata.rst:80 -#: ../source/specifications/core-metadata.rst:95 -#: ../source/specifications/core-metadata.rst:155 -#: ../source/specifications/core-metadata.rst:170 -#: ../source/specifications/core-metadata.rst:208 -#: ../source/specifications/core-metadata.rst:283 -#: ../source/specifications/core-metadata.rst:287 -#: ../source/specifications/core-metadata.rst:291 -#: ../source/specifications/core-metadata.rst:295 -#: ../source/specifications/core-metadata.rst:327 -#: ../source/specifications/core-metadata.rst:347 -#: ../source/specifications/core-metadata.rst:373 -#: ../source/specifications/core-metadata.rst:391 -#: ../source/specifications/core-metadata.rst:416 -#: ../source/specifications/core-metadata.rst:438 -#: ../source/specifications/core-metadata.rst:600 -#: ../source/specifications/core-metadata.rst:620 -#: ../source/specifications/core-metadata.rst:630 -msgid "Example::" -msgstr "Exemplo::" - -#: ../source/specifications/core-metadata.rst:66 -msgid "Name" -msgstr "Nome" - -#: ../source/specifications/core-metadata.rst:69 -msgid "Added additional restrictions on format from :pep:`508`" -msgstr "Adicionadas restrições adicionais ao formato da :pep:`508`" - -#: ../source/specifications/core-metadata.rst:72 -msgid "" -"The name of the distribution. The name field is the primary identifier for a " -"distribution. A valid name consists only of ASCII letters and numbers, " -"period, underscore and hyphen. It must start and end with a letter or " -"number. Distribution names are limited to those which match the following " -"regex (run with ``re.IGNORECASE``)::" -msgstr "" -"O nome da distribuição. O campo de nome é o identificador principal de uma " -"distribuição. Um nome válido consiste apenas em letras e números ASCII, " -"ponto, sublinhado e hífen. Deve começar e terminar com uma letra ou número. " -"Os nomes de distribuição são limitados àqueles que correspondem ao seguinte " -"regex (executado com ``re.IGNORECASE``)::" - -#: ../source/specifications/core-metadata.rst:88 -msgid "Version" -msgstr "Versão" - -#: ../source/specifications/core-metadata.rst:92 -msgid "" -"A string containing the distribution's version number. This field must be " -"in the format specified in :pep:`440`." -msgstr "" -"Uma string contendo o número da versão da distribuição. Este campo deve " -"estar no formato especificado na :pep:`440`." - -#: ../source/specifications/core-metadata.rst:101 -msgid "Dynamic (multiple use)" -msgstr "Dynamic (vários usos)" - -#: ../source/specifications/core-metadata.rst:105 -msgid "" -"A string containing the name of another core metadata field. The field names " -"``Name`` and ``Version`` may not be specified in this field." -msgstr "" -"Uma string contendo o nome de outro campo de metadados principal. Os nomes " -"dos campos ``Name`` e ``Version`` não podem ser especificados neste campo." - -#: ../source/specifications/core-metadata.rst:108 -msgid "" -"When found in the metadata of a source distribution, the following rules " -"apply:" -msgstr "" -"Quando encontrados nos metadados de uma distribuição fonte, as seguintes " -"regras se aplicam:" - -#: ../source/specifications/core-metadata.rst:111 -msgid "" -"If a field is *not* marked as ``Dynamic``, then the value of the field in " -"any wheel built from the sdist MUST match the value in the sdist. If the " -"field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT " -"be present in the wheel." -msgstr "" -"Se um campo *não* estiver marcado como ``Dynamic``, então o valor do campo " -"em qualquer wheel construído a partir do sdist DEVE corresponder ao valor do " -"sdist. Se o campo não estiver no sdist e não estiver marcado como " -"``Dynamic``, ele NÃO DEVE estar presente no wheel." - -#: ../source/specifications/core-metadata.rst:115 -msgid "" -"If a field is marked as ``Dynamic``, it may contain any valid value in a " -"wheel built from the sdist (including not being present at all)." -msgstr "" -"Se um campo for marcado como ``Dynamic``, ele pode conter qualquer valor " -"válido em um wheel construído a partir do sdist (incluindo não estar " -"presente)." - -#: ../source/specifications/core-metadata.rst:118 -msgid "" -"If the sdist metadata version is older than version 2.2, then all fields " -"should be treated as if they were specified with ``Dynamic`` (i.e. there are " -"no special restrictions on the metadata of wheels built from the sdist)." -msgstr "" -"Se a versão dos metadados sdist for anterior à versão 2.2, todos os campos " -"devem ser tratados como se tivessem sido especificados com ``Dynamic`` (ou " -"seja, não há restrições especiais sobre os metadados dos wheels construídos " -"a partir do sdist)." - -#: ../source/specifications/core-metadata.rst:122 -msgid "" -"In any context other than a source distribution, ``Dynamic`` is for " -"information only, and indicates that the field value was calculated at wheel " -"build time, and may not be the same as the value in the sdist or in other " -"wheels for the project." -msgstr "" -"Em qualquer contexto que não seja uma distribuição fonte, ``Dynamic`` é " -"apenas para informação e indica que o valor do campo foi calculado no tempo " -"de construção do wheel, e pode não ser o mesmo que o valor no sdist ou em " -"outros wheels para o projeto." - -#: ../source/specifications/core-metadata.rst:127 -msgid "" -"Full details of the semantics of ``Dynamic`` are described in :pep:`643`." -msgstr "" -"Detalhes completos da semântica de ``Dynamic`` são descritos na :pep:`643`." - -#: ../source/specifications/core-metadata.rst:131 -msgid "Platform (multiple use)" -msgstr "Platform (vários usos)" - -#: ../source/specifications/core-metadata.rst:135 -msgid "" -"A Platform specification describing an operating system supported by the " -"distribution which is not listed in the \"Operating System\" Trove " -"classifiers. See \"Classifier\" below." -msgstr "" -"Uma especificação da plataforma que descreve um sistema operacional " -"suportado pela distribuição que não está listado nos classificadores Trove " -"de \"Operating System\". Veja \"Classifier\" abaixo." - -#: ../source/specifications/core-metadata.rst:146 -msgid "Supported-Platform (multiple use)" -msgstr "Supported-Platform (vários usos)" - -#: ../source/specifications/core-metadata.rst:150 -msgid "" -"Binary distributions containing a PKG-INFO file will use the Supported-" -"Platform field in their metadata to specify the OS and CPU for which the " -"binary distribution was compiled. The semantics of the Supported-Platform " -"field are not specified in this PEP." -msgstr "" -"As distribuições binárias contendo um arquivo PKG-INFO usarão o campo " -"Supported-Platform em seus metadados para especificar o sistema operacional " -"e a CPU para os quais a distribuição binária foi compilada. A semântica do " -"campo Supported-Platform não é especificada nesta PEP." - -#: ../source/specifications/core-metadata.rst:164 -msgid "Summary" -msgstr "Summary" - -#: ../source/specifications/core-metadata.rst:168 -msgid "A one-line summary of what the distribution does." -msgstr "Um resumo de uma linha do que a distribuição faz." - -#: ../source/specifications/core-metadata.rst:188 -msgid "This field may be specified in the message body instead." -msgstr "Este campo pode ser especificado no corpo da mensagem." - -#: ../source/specifications/core-metadata.rst:191 -msgid "" -"A longer description of the distribution that can run to several " -"paragraphs. Software that deals with metadata should not assume any maximum " -"size for this field, though people shouldn't include their instruction " -"manual as the description." -msgstr "" -"Uma descrição mais longa da distribuição que pode ter vários parágrafos. " -"Software que lida com metadados não deve presumir nenhum tamanho máximo para " -"este campo, embora as pessoas não devam incluir seu manual de instruções " -"como a descrição." - -#: ../source/specifications/core-metadata.rst:196 -msgid "" -"The contents of this field can be written using reStructuredText markup " -"[1]_. For programs that work with the metadata, supporting markup is " -"optional; programs can also display the contents of the field as-is. This " -"means that authors should be conservative in the markup they use." -msgstr "" -"O conteúdo deste campo pode ser escrito usando a marcação reStructuredText " -"[1]_. Para programas que funcionam com metadados, o suporte à marcação é " -"opcional; os programas também podem exibir o conteúdo do campo como está. " -"Isso significa que os autores devem ser conservadores na marcação que usam." - -#: ../source/specifications/core-metadata.rst:202 -msgid "" -"To support empty lines and lines with indentation with respect to the RFC " -"822 format, any CRLF character has to be suffixed by 7 spaces followed by a " -"pipe (\"|\") char. As a result, the Description field is encoded into a " -"folded field that can be interpreted by RFC822 parser [2]_." -msgstr "" -"Para oferecer suporte a linhas vazias e linhas com indentação em relação ao " -"formato do RFC 822, qualquer caractere CRLF deve ser sufixado por 7 espaços " -"seguidos por um caractere de encadeamento ou pipe (\"|\"). Como resultado, o " -"campo Description é codificado em um campo dobrado que pode ser interpretado " -"pelo analisador RFC822 [2]_." - -#: ../source/specifications/core-metadata.rst:219 -msgid "" -"This encoding implies that any occurrences of a CRLF followed by 7 spaces " -"and a pipe char have to be replaced by a single CRLF when the field is " -"unfolded using a RFC822 reader." -msgstr "" -"Esta codificação implica que quaisquer ocorrências de um CRLF seguido por 7 " -"espaços e um caractere pipe devem ser substituídos por um único CRLF quando " -"o campo é desdobrado usando um leitor de RFC822." - -#: ../source/specifications/core-metadata.rst:223 -msgid "" -"Alternatively, the distribution's description may instead be provided in the " -"message body (i.e., after a completely blank line following the headers, " -"with no indentation or other special formatting necessary)." -msgstr "" -"Alternativamente, a descrição da distribuição pode ser fornecida no corpo da " -"mensagem (ou seja, após uma linha completamente em branco após os " -"cabeçalhos, sem recuo ou outra formatação especial necessária)." - -#: ../source/specifications/core-metadata.rst:232 -msgid "Description-Content-Type" -msgstr "Description-Content-Type" - -#: ../source/specifications/core-metadata.rst:236 -msgid "" -"A string stating the markup syntax (if any) used in the distribution's " -"description, so that tools can intelligently render the description." -msgstr "" -"Uma string informando a sintaxe de marcação (se houver) usada na descrição " -"da distribuição, para que as ferramentas possam renderizar a descrição de " -"maneira inteligente." - -#: ../source/specifications/core-metadata.rst:239 -msgid "" -"Historically, PyPI supported descriptions in plain text and " -"`reStructuredText (reST) `_, and could render reST into HTML. However, it is " -"common for distribution authors to write the description in `Markdown " -"`_ (`RFC 7763 `_) as many code hosting sites render Markdown " -"READMEs, and authors would reuse the file for the description. PyPI didn't " -"recognize the format and so could not render the description correctly. This " -"resulted in many packages on PyPI with poorly-rendered descriptions when " -"Markdown is left as plain text, or worse, was attempted to be rendered as " -"reST. This field allows the distribution author to specify the format of " -"their description, opening up the possibility for PyPI and other tools to be " -"able to render Markdown and other formats." -msgstr "" -"Historicamente, o PyPI oferecia suporte a descrições em texto simples e `" -"reStructuredText (reST) `_, e poderia renderizar reST em HTML. No entanto, é " -"comum que os autores da distribuição escrevam a descrição em `Markdown " -"`_ (`RFC 7763 `_) visto que tantos sites de hospedagem de código " -"renderizam READMEs de Markdown, e os autores reutilizariam o arquivo para a " -"descrição. O PyPI não reconhecia o formato e, portanto, não conseguia " -"processar a descrição corretamente. Isso resultava em muitos pacotes no PyPI " -"com descrições mal renderizadas quando Markdown é deixado como texto " -"simples, ou pior, era tentado ser renderizado como reST. Este campo permite " -"que o autor da distribuição especifique o formato de sua descrição, abrindo " -"a possibilidade para PyPI e outras ferramentas serem capazes de renderizar " -"Markdown e outros formatos." - -#: ../source/specifications/core-metadata.rst:253 -msgid "" -"The format of this field is the same as the ``Content-Type`` header in HTTP " -"(i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then " -"it can optionally have a number of parameters:" -msgstr "" -"O formato deste campo é o mesmo do cabeçalho ``Content-Type`` em HTTP (ou " -"seja: `RFC 1341 `_)" -". Resumidamente, isso significa que ele tem uma parte do ``tipo/subtipo`` e " -"então pode opcionalmente ter uma série de parâmetros:" - -#: ../source/specifications/core-metadata.rst:259 -msgid "Format::" -msgstr "Formato::" - -#: ../source/specifications/core-metadata.rst:263 -msgid "The ``type/subtype`` part has only a few legal values:" -msgstr "A parta ``tipo/subtipo`` tem apenas alguns poucos valores válidos:" - -#: ../source/specifications/core-metadata.rst:265 -msgid "``text/plain``" -msgstr "``text/plain``" - -#: ../source/specifications/core-metadata.rst:266 -msgid "``text/x-rst``" -msgstr "``text/x-rst``" - -#: ../source/specifications/core-metadata.rst:267 -msgid "``text/markdown``" -msgstr "``text/markdown``" - -#: ../source/specifications/core-metadata.rst:269 -msgid "" -"The ``charset`` parameter can be used to specify the character encoding of " -"the description. The only legal value is ``UTF-8``. If omitted, it is " -"assumed to be ``UTF-8``." -msgstr "" -"O parâmetro ``charset`` pode ser usado para especificar a codificação de " -"caracteres da descrição. O único valor válido é ``UTF-8``. Se omitido, é " -"considerado ``UTF-8``." - -#: ../source/specifications/core-metadata.rst:273 -msgid "" -"Other parameters might be specific to the chosen subtype. For example, for " -"the ``markdown`` subtype, there is an optional ``variant`` parameter that " -"allows specifying the variant of Markdown in use (defaults to ``GFM`` if not " -"specified). Currently, two variants are recognized:" -msgstr "" -"Outros parâmetros podem ser específicos para o subtipo escolhido. Por " -"exemplo, para o subtipo ``markdown``, existe um parâmetro opcional " -"``variant`` que permite especificar a variante do Markdown em uso (o padrão " -"é ``GFM`` se não for especificado). Atualmente, duas variantes são " -"reconhecidas:" - -#: ../source/specifications/core-metadata.rst:278 -msgid "" -"``GFM`` for `Github-flavored Markdown `_" -msgstr "" -"``GFM`` para `Github-flavored Markdown `_" - -#: ../source/specifications/core-metadata.rst:280 -msgid "" -"``CommonMark`` for `CommonMark `_" -msgstr "" -"``CommonMark`` para `CommonMark `_" - -#: ../source/specifications/core-metadata.rst:299 -msgid "" -"If a ``Description-Content-Type`` is not specified, then applications should " -"attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to " -"``text/plain`` if it is not valid rst." -msgstr "" -"Se um ``Description-Content-Type`` não for especificado, as aplicações devem " -"tentar renderizá-lo como ``text/x-rst; charset=UTF-8`` e volta para ``text/" -"plain`` se não for válido primeiro." - -#: ../source/specifications/core-metadata.rst:303 -msgid "" -"If a ``Description-Content-Type`` is an unrecognized value, then the assumed " -"content type is ``text/plain`` (Although PyPI will probably reject anything " -"with an unrecognized value)." -msgstr "" -"Se um ``Description-Content-Type`` é um valor não reconhecido, então o tipo " -"de conteúdo presumido ser ``text/plain`` (embora PyPI provavelmente rejeite " -"qualquer coisa com um valor não reconhecido)." - -#: ../source/specifications/core-metadata.rst:307 -msgid "" -"If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is " -"not specified or is set to an unrecognized value, then the assumed " -"``variant`` is ``GFM``." -msgstr "" -"Se o ``Description-Content-Type`` for ``text/markdown`` e ``variant`` não " -"for especificado ou estiver definido com um valor não reconhecido, então a " -"presume-se ``variant`` ser ``GFM`` ." - -#: ../source/specifications/core-metadata.rst:311 -msgid "" -"So for the last example above, the ``charset`` defaults to ``UTF-8`` and the " -"``variant`` defaults to ``GFM`` and thus it is equivalent to the example " -"before it." -msgstr "" -"Portanto, para o último exemplo acima, o ``charset`` padrão é ``UTF-8`` e o " -"``variant`` padrão ``GFM`` e, portanto, é equivalente ao exemplo anterior." - -#: ../source/specifications/core-metadata.rst:320 -msgid "Keywords" -msgstr "Keywords" - -#: ../source/specifications/core-metadata.rst:324 -msgid "" -"A list of additional keywords, separated by commas, to be used to assist " -"searching for the distribution in a larger catalog." -msgstr "" -"Uma lista de palavras-chave adicionais, separadas por vírgulas, a serem " -"usadas para auxiliar na busca pela distribuição em um catálogo maior." - -#: ../source/specifications/core-metadata.rst:333 -msgid "" -"The specification previously showed keywords separated by spaces, but " -"distutils and setuptools implemented it with commas. These tools have been " -"very widely used for many years, so it was easier to update the " -"specification to match the de facto standard." -msgstr "" -"A especificação anteriormente mostrava palavras-chave separadas por espaços, " -"mas distutils e setuptools a implementaram com vírgulas. Essas ferramentas " -"foram amplamente utilizadas por muitos anos, então era mais fácil atualizar " -"a especificação para corresponder ao padrão de fato." - -#: ../source/specifications/core-metadata.rst:341 -msgid "Home-page" -msgstr "Home-page" - -#: ../source/specifications/core-metadata.rst:345 -msgid "A string containing the URL for the distribution's home page." -msgstr "Uma string contendo a URL para a página da distribuição." - -#: ../source/specifications/core-metadata.rst:353 -msgid "Download-URL" -msgstr "Download-URL" - -#: ../source/specifications/core-metadata.rst:357 -msgid "" -"A string containing the URL from which this version of the distribution can " -"be downloaded. (This means that the URL can't be something like \".../" -"BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" -msgstr "" -"Uma string contendo a URL a partir da qual esta versão da distribuição pode " -"ser baixada. (Isso significa que a URL não pode ser algo como \"" -".../BeagleVote-latest.tgz\", mas deve ser \".../BeagleVote-0.45.tgz\".)" - -#: ../source/specifications/core-metadata.rst:366 -msgid "Author" -msgstr "Author" - -#: ../source/specifications/core-metadata.rst:370 -msgid "" -"A string containing the author's name at a minimum; additional contact " -"information may be provided." -msgstr "" -"Um string contendo o nome do autor, no mínimo; informações de contato " -"adicionais podem ser fornecidas." - -#: ../source/specifications/core-metadata.rst:383 -msgid "Author-email" -msgstr "Author-email" - -#: ../source/specifications/core-metadata.rst:387 -msgid "" -"A string containing the author's e-mail address. It can contain a name and " -"e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" -"Uma string contendo o endereço de e-mail do autor. Ela pode conter um nome e " -"endereço de e-mail nas formas válidos para um cabeçalho ``From:`` do RFC-822." - -#: ../source/specifications/core-metadata.rst:395 -#: ../source/specifications/core-metadata.rst:442 -msgid "" -"Per RFC-822, this field may contain multiple comma-separated e-mail " -"addresses::" -msgstr "" -"De acordo com RFC-822, este campo pode conter vários endereços de e-mail " -"separados por vírgula::" - -#: ../source/specifications/core-metadata.rst:405 -msgid "Maintainer" -msgstr "Mantenedor" - -#: ../source/specifications/core-metadata.rst:409 -msgid "" -"A string containing the maintainer's name at a minimum; additional contact " -"information may be provided." -msgstr "" -"Uma string contendo o nome do mantenedor, no mínimo; informações de contato " -"adicionais podem ser fornecidas." - -#: ../source/specifications/core-metadata.rst:412 -msgid "" -"Note that this field is intended for use when a project is being maintained " -"by someone other than the original author: it should be omitted if it is " -"identical to ``Author``." -msgstr "" -"Observe que este campo deve ser usado quando um projeto está sendo mantido " -"por alguém que não seja o autor original: ele deve ser omitido se for " -"idêntico a ``Author``." - -#: ../source/specifications/core-metadata.rst:426 -msgid "Maintainer-email" -msgstr "Maintainer-email" - -#: ../source/specifications/core-metadata.rst:430 -msgid "" -"A string containing the maintainer's e-mail address. It can contain a name " -"and e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" -"Uma string contendo o endereço de e-mail do mantenedor. Ela pode conter um " -"nome e endereço de e-mail nas formas válidas para um cabeçalho ``From:`` do " -"RFC-822." - -#: ../source/specifications/core-metadata.rst:434 -msgid "" -"Note that this field is intended for use when a project is being maintained " -"by someone other than the original author: it should be omitted if it is " -"identical to ``Author-email``." -msgstr "" -"Observe que este campo deve ser usado quando um projeto está sendo mantido " -"por alguém que não seja o autor original: ele deve ser omitido se for " -"idêntico a ``Author-email``." - -#: ../source/specifications/core-metadata.rst:452 -msgid "License" -msgstr "License" - -#: ../source/specifications/core-metadata.rst:456 -msgid "" -"Text indicating the license covering the distribution where the license is " -"not a selection from the \"License\" Trove classifiers. See :ref:`" -"\"Classifier\" ` below. This field may also be used to " -"specify a particular version of a license which is named via the " -"``Classifier`` field, or to indicate a variation or exception to such a " -"license." -msgstr "" -"Texto indicando a licença cobrindo a distribuição onde a licença não é uma " -"seleção dos classificadores Trove \"License\". Veja :ref:`\"Classifier \"" -"` abaixo. Este campo também pode ser usado para " -"especificar uma versão particular de uma licença que é nomeada através do " -"campo ``Classifier``, ou para indicar uma variação ou exceção a tal licença." - -#: ../source/specifications/core-metadata.rst:476 -msgid "Classifier (multiple use)" -msgstr "Classifier (vários usos)" - -#: ../source/specifications/core-metadata.rst:480 -msgid "" -"Each entry is a string giving a single classification value for the " -"distribution. Classifiers are described in :pep:`301`, and the Python " -"Package Index publishes a dynamic list of `currently defined classifiers " -"`__." -msgstr "" -"Cada entrada é uma string que fornece um único valor de classificação para a " -"distribuição. Os classificadores são descritos na :pep:`301`, e o Python " -"Package Index publica uma lista dinâmica de `classificadores atualmente " -"definidos `__." - -#: ../source/specifications/core-metadata.rst:485 -#: ../source/specifications/core-metadata.rst:574 -#: ../source/specifications/core-metadata.rst:691 -#: ../source/specifications/core-metadata.rst:715 -msgid "This field may be followed by an environment marker after a semicolon." -msgstr "" -"Este campo pode ser seguido por um marcador de ambiente após um ponto e " -"vírgula." - -#: ../source/specifications/core-metadata.rst:496 -msgid "Requires-Dist (multiple use)" -msgstr "Requires-Dist (vários usos)" - -#: ../source/specifications/core-metadata.rst:499 -#: ../source/specifications/core-metadata.rst:561 -#: ../source/specifications/core-metadata.rst:663 -#: ../source/specifications/core-metadata.rst:704 -msgid "" -"The field format specification was relaxed to accept the syntax used by " -"popular publishing tools." -msgstr "" -"A especificação do formato de campo foi relaxada para aceitar a sintaxe " -"usada por ferramentas de publicação populares." - -#: ../source/specifications/core-metadata.rst:503 -msgid "" -"Each entry contains a string naming some other distutils project required by " -"this distribution." -msgstr "" -"Cada entrada contém uma string nomeando algum outro projeto distutils " -"requerido por esta distribuição." - -#: ../source/specifications/core-metadata.rst:506 -msgid "The format of a requirement string contains from one to four parts:" -msgstr "O formato de uma string de requisito contém de uma a quatro partes:" - -#: ../source/specifications/core-metadata.rst:508 -msgid "" -"A project name, in the same format as the ``Name:`` field. The only " -"mandatory part." -msgstr "" -"Um nome de projeto, no mesmo formato do campo ``Name:``. A única parte " -"obrigatória." - -#: ../source/specifications/core-metadata.rst:510 -msgid "" -"A comma-separated list of 'extra' names. These are defined by the required " -"project, referring to specific features which may need extra dependencies." -msgstr "" -"Uma lista separada por vírgulas de nomes \"extras\". Estes são definidos " -"pelo projeto requerido, referindo-se a recursos específicos que podem " -"precisar de dependências extras." - -#: ../source/specifications/core-metadata.rst:513 -msgid "" -"A version specifier. Tools parsing the format should accept optional " -"parentheses around this, but tools generating it should not use parentheses." -msgstr "" -"Um especificador de versão. As ferramentas que analisam o formato devem " -"aceitar parênteses opcionais em torno disso, mas as ferramentas que o geram " -"não devem usar parênteses." - -#: ../source/specifications/core-metadata.rst:516 -msgid "" -"An environment marker after a semicolon. This means that the requirement is " -"only needed in the specified conditions." -msgstr "" -"Um marcador de ambiente após um ponto e vírgula. Isso significa que o " -"requisito só é necessário nas condições especificadas." - -#: ../source/specifications/core-metadata.rst:519 -msgid "See :pep:`508` for full details of the allowed format." -msgstr "Veja a :pep:`508` para detalhes completos do formato permitido." - -#: ../source/specifications/core-metadata.rst:521 -msgid "" -"The project names should correspond to names as found on the `Python Package " -"Index`_." -msgstr "" -"Os nomes dos projetos devem corresponder aos nomes encontrados no `Python " -"Package Index`_." - -#: ../source/specifications/core-metadata.rst:524 -msgid "" -"Version specifiers must follow the rules described in :doc:`version-" -"specifiers`." -msgstr "" -"Os especificadores de versão devem seguir as regras descritas em :doc" -":`version-specifiers`." - -#: ../source/specifications/core-metadata.rst:538 -msgid "Requires-Python" -msgstr "Requires-Python" - -#: ../source/specifications/core-metadata.rst:542 -msgid "" -"This field specifies the Python version(s) that the distribution is " -"guaranteed to be compatible with. Installation tools may look at this when " -"picking which version of a project to install." -msgstr "" -"Este campo especifica a(s) versão(ões) do Python com as quais a distribuição " -"tem garantia de compatibilidade. As ferramentas de instalação podem observar " -"isso ao escolher qual versão de um projeto instalar." - -#: ../source/specifications/core-metadata.rst:546 -msgid "The value must be in the format specified in :doc:`version-specifiers`." -msgstr "" -"O valor deve estar no formato especificado em :doc:`version-specifiers`." - -#: ../source/specifications/core-metadata.rst:548 -msgid "This field cannot be followed by an environment marker." -msgstr "Este campo não pode ser seguido por um marcador de ambiente." - -#: ../source/specifications/core-metadata.rst:558 -msgid "Requires-External (multiple use)" -msgstr "Requires-External (vários usos)" - -#: ../source/specifications/core-metadata.rst:565 -msgid "" -"Each entry contains a string describing some dependency in the system that " -"the distribution is to be used. This field is intended to serve as a hint " -"to downstream project maintainers, and has no semantics which are meaningful " -"to the ``distutils`` distribution." -msgstr "" -"Cada entrada contém uma string que descreve alguma dependência no sistema de " -"que a distribuição deve ser usada. Este campo tem como objetivo servir como " -"uma dica para os mantenedores do projeto downstream, e não tem semântica que " -"seja significativa para a distribuição ``distutils``." - -#: ../source/specifications/core-metadata.rst:570 -msgid "" -"The format of a requirement string is a name of an external dependency, " -"optionally followed by a version declaration within parentheses." -msgstr "" -"O formato de uma string de requisito é o nome de uma dependência externa, " -"opcionalmente seguido por uma declaração de versão entre parênteses." - -#: ../source/specifications/core-metadata.rst:576 -msgid "" -"Because they refer to non-Python software releases, version numbers for this " -"field are **not** required to conform to the format specified in :pep:" -"`440`: they should correspond to the version scheme used by the external " -"dependency." -msgstr "" -"Como eles se referem a lançamentos de software não-Python, os números de " -"versão para este campo **não** são obrigados a estar em conformidade com o " -"formato especificado na :pep:`440`: eles devem corresponder ao esquema de " -"versão usado pela dependência externa." - -#: ../source/specifications/core-metadata.rst:581 -msgid "Notice that there is no particular rule on the strings to be used." -msgstr "" -"Observe que não há uma regra específica sobre as strings a serem usadas." - -#: ../source/specifications/core-metadata.rst:593 -msgid "Project-URL (multiple-use)" -msgstr "Project-URL (vários usos)" - -#: ../source/specifications/core-metadata.rst:597 -msgid "" -"A string containing a browsable URL for the project and a label for it, " -"separated by a comma." -msgstr "" -"Uma string contendo uma URL navegável para o projeto e um rótulo para ele, " -"separados por uma vírgula." - -#: ../source/specifications/core-metadata.rst:604 -msgid "The label is free text limited to 32 characters." -msgstr "O rótulo é um texto livre limitado a 32 caracteres." - -#: ../source/specifications/core-metadata.rst:612 -msgid "Provides-Extra (multiple use)" -msgstr "Provides-Extra (vários usos)" - -#: ../source/specifications/core-metadata.rst:616 -msgid "" -"A string containing the name of an optional feature. Must be a valid Python " -"identifier. May be used to make a dependency conditional on whether the " -"optional feature has been requested." -msgstr "" -"Uma string contendo o nome de um recurso opcional. Deve ser um identificador " -"Python válido. Pode ser usado para tornar uma dependência condicional ao " -"fato de o recurso opcional ter sido solicitado." - -#: ../source/specifications/core-metadata.rst:625 -msgid "" -"A second distribution requires an optional dependency by placing it inside " -"square brackets, and can request multiple features by separating them with a " -"comma (,). The requirements are evaluated for each requested feature and " -"added to the set of requirements for the distribution." -msgstr "" -"Uma segunda distribuição requer uma dependência opcional, colocando-a entre " -"colchetes, e pode solicitar vários recursos, separando-os com uma vírgula (,)" -". Os requisitos são avaliados para cada recurso solicitado e adicionados ao " -"conjunto de requisitos para a distribuição." - -#: ../source/specifications/core-metadata.rst:635 -msgid "" -"Two feature names ``test`` and ``doc`` are reserved to mark dependencies " -"that are needed for running automated tests and generating documentation, " -"respectively." -msgstr "" -"Dois nomes de recursos ``test`` e ``doc`` são reservados para marcar " -"dependências que são necessárias para executar testes automatizados e gerar " -"documentação, respectivamente." - -#: ../source/specifications/core-metadata.rst:639 -msgid "" -"It is legal to specify ``Provides-Extra:`` without referencing it in any " -"``Requires-Dist:``." -msgstr "" -"É válido especificar ``Provides-Extra:`` sem referenciá-lo em qualquer " -"``Requer-Dist:``." - -#: ../source/specifications/core-metadata.rst:644 -msgid "Rarely Used Fields" -msgstr "Campos raramente usados" - -#: ../source/specifications/core-metadata.rst:646 -msgid "" -"The fields in this section are currently rarely used, as their design was " -"inspired by comparable mechanisms in Linux package management systems, and " -"it isn't at all clear how tools should interpret them in the context of an " -"open index server such as `PyPI `__." -msgstr "" -"Os campos nesta seção são raramente usados atualmente, já que seu design foi " -"inspirado por mecanismos comparáveis em sistemas de gerenciamento de pacotes " -"Linux, e não está claro como as ferramentas devem interpretá-los no contexto " -"de um servidor de indexação aberto, como `PyPI `__." - -#: ../source/specifications/core-metadata.rst:651 -msgid "" -"As a result, popular installation tools ignore them completely, which in " -"turn means there is little incentive for package publishers to set them " -"appropriately. However, they're retained in the metadata specification, as " -"they're still potentially useful for informational purposes, and can also be " -"used for their originally intended purpose in combination with a curated " -"package repository." -msgstr "" -"Como resultado, as ferramentas de instalação populares os ignoram " -"completamente, o que significa que há pouco incentivo para os editores de " -"pacotes configurá-los apropriadamente. No entanto, eles são retidos na " -"especificação de metadados, pois ainda são potencialmente úteis para fins " -"informativos e também podem ser usados para o propósito originalmente " -"pretendido em combinação com um repositório de pacotes com curadoria." - -#: ../source/specifications/core-metadata.rst:660 -msgid "Provides-Dist (multiple use)" -msgstr "Provides-Dist (vários usos)" - -#: ../source/specifications/core-metadata.rst:667 -msgid "" -"Each entry contains a string naming a Distutils project which is contained " -"within this distribution. This field *must* include the project identified " -"in the ``Name`` field, followed by the version : Name (Version)." -msgstr "" -"Cada entrada contém uma string nomeando um projeto Distutils que está " -"contido nesta distribuição. Este campo *deve* incluir o projeto identificado " -"no campo ``Name``, seguido da versão: Nome (Versão)." - -#: ../source/specifications/core-metadata.rst:672 -msgid "" -"A distribution may provide additional names, e.g. to indicate that multiple " -"projects have been bundled together. For instance, source distributions of " -"the ``ZODB`` project have historically included the ``transaction`` project, " -"which is now available as a separate distribution. Installing such a source " -"distribution satisfies requirements for both ``ZODB`` and ``transaction``." -msgstr "" -"Uma distribuição pode fornecer nomes adicionais, por exemplo, para indicar " -"que vários projetos foram agrupados. Por exemplo, distribuições de código-" -"fonte do projeto ``ZODB`` historicamente incluíram o projeto ``transaction``" -", que agora está disponível como uma distribuição separada. Instalar tal " -"distribuição de código-fonte satisfaz os requisitos para ``ZODB`` e " -"``transaction``." - -#: ../source/specifications/core-metadata.rst:679 -msgid "" -"A distribution may also provide a \"virtual\" project name, which does not " -"correspond to any separately-distributed project: such a name might be used " -"to indicate an abstract capability which could be supplied by one of " -"multiple projects. E.g., multiple projects might supply RDBMS bindings for " -"use by a given ORM: each project might declare that it provides ``ORM-" -"bindings``, allowing other projects to depend only on having at most one of " -"them installed." -msgstr "" -"Uma distribuição também pode fornecer um nome de projeto \"virtual\", que " -"não corresponde a nenhum projeto distribuído separadamente: tal nome pode " -"ser usado para indicar uma capacidade abstrata que pode ser fornecida por um " -"de vários projetos. Por exemplo, vários projetos podem fornecer ligações " -"*(bindings)* de RDBMS para uso por um determinado ORM: cada projeto pode " -"declarar que fornece ``ORM-bindings``, permitindo que outros projetos " -"dependam apenas de ter no máximo um deles instalado." - -#: ../source/specifications/core-metadata.rst:687 -msgid "" -"A version declaration may be supplied and must follow the rules described " -"in :doc:`version-specifiers`. The distribution's version number will be " -"implied if none is specified." -msgstr "" -"Uma declaração de versão pode ser fornecida e deve seguir as regras " -"descritas em :doc:`version-specifiers`. O número da versão da distribuição " -"estará implícito se nenhum for especificado." - -#: ../source/specifications/core-metadata.rst:701 -msgid "Obsoletes-Dist (multiple use)" -msgstr "Obsoletes-Dist (vários usos)" - -#: ../source/specifications/core-metadata.rst:708 -msgid "" -"Each entry contains a string describing a distutils project's distribution " -"which this distribution renders obsolete, meaning that the two projects " -"should not be installed at the same time." -msgstr "" -"Cada entrada contém uma string que descreve a distribuição de um projeto " -"distutils que esta distribuição torna obsoleta, o que significa que os dois " -"projetos não devem ser instalados ao mesmo tempo." - -#: ../source/specifications/core-metadata.rst:712 -msgid "" -"Version declarations can be supplied. Version numbers must be in the format " -"specified in :doc:`version-specifiers`." -msgstr "" -"Declarações de versão podem ser fornecidas. Os números de versão devem estar " -"no formato especificado em :doc:`version-specifiers`." - -#: ../source/specifications/core-metadata.rst:717 -msgid "" -"The most common use of this field will be in case a project name changes, e." -"g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install " -"Torqued Python, the Gorgon distribution should be removed." -msgstr "" -"O uso mais comum deste campo será no caso de alteração do nome de um " -"projeto, por exemplo, Gorgon 2.3 é incluído no Torqued Python 1.0. Quando " -"você instala o Torqued Python, a distribuição Gorgon deve ser removida." - -#: ../source/specifications/core-metadata.rst:730 -msgid "reStructuredText markup: http://docutils.sourceforge.net/" -msgstr "Marcação reStructuredText: http://docutils.sourceforge.net/" - -#: ../source/specifications/core-metadata.rst:735 -msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" -msgstr "" -"\"Long Header Fields\" do RFC 822: http://www.freesoft.org/CIE/RFC/822/7.htm" - -#: ../source/specifications/declaring-build-dependencies.rst:6 -msgid "Declaring build system dependencies" -msgstr "Declarando dependências do sistema de construção" - -#: ../source/specifications/declaring-build-dependencies.rst:8 -msgid "" -"`pyproject.toml` is a build system independent file format defined in :pep:" -"`518` that projects may provide in order to declare any Python level " -"dependencies that must be installed in order to run the project's build " -"system successfully." -msgstr "" -"`pyproject.toml` é um formato de arquivo independente do sistema de " -"construção definido na :pep:`518` que os projetos podem fornecer para " -"declarar quaisquer dependências de nível Python que devem ser instaladas " -"para executar o sistema de construção do projeto com sucesso." - -#: ../source/specifications/declaring-project-metadata.rst:5 -msgid "Declaring project metadata" -msgstr "Declarando os metadados do projeto" - -#: ../source/specifications/declaring-project-metadata.rst:7 -msgid "" -":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to " -"consume. It defines the following specification as the canonical source for " -"the format used." -msgstr "" -"A :pep:`621` especifica como escrever :ref:`metadados principais ` de um projeto em um arquivo ``pyproject.toml`` para ferramentas " -"relacionadas ao empacotamento consumirem. Ele define a seguinte " -"especificação como a fonte canônica para o formato usado." - -#: ../source/specifications/declaring-project-metadata.rst:12 -msgid "" -"There are two kinds of metadata: *static* and *dynamic*. Static metadata is " -"specified in the ``pyproject.toml`` file directly and cannot be specified or " -"changed by a tool. Dynamic metadata is listed via the ``dynamic`` field " -"(defined later in this specification) and represents metadata that a tool " -"will later provide." -msgstr "" -"Existem dois tipos de metadados: *estáticos* e *dinâmicos*. Metadados " -"estáticos são especificados diretamente no arquivo ``pyproject.toml`` e não " -"podem ser especificados ou alterados por uma ferramenta. Os metadados " -"dinâmicos são listados por meio do campo ``dynamic`` (definido " -"posteriormente nesta especificação) e representam os metadados que uma " -"ferramenta fornecerá posteriormente." - -#: ../source/specifications/declaring-project-metadata.rst:18 -msgid "" -"The fields defined in this specification MUST be in a table named " -"``[project]`` in ``pyproject.toml``. No tools may add fields to this table " -"which are not defined by this specification. For tools wishing to store " -"their own settings in ``pyproject.toml``, they may use the ``[tool]`` table " -"as defined in the :ref:`build dependency declaration specification " -"`. The lack of a ``[project]`` table " -"implicitly means the build back-end will dynamically provide all fields." -msgstr "" -"Os campos definidos nesta especificação DEVEM estar em uma tabela chamada " -"``[project]`` no arquivo ``pyproject.toml``. Nenhuma ferramenta pode " -"adicionar campos a esta tabela que não sejam definidos por esta " -"especificação. Para ferramentas que desejam armazenar suas próprias " -"configurações em ``pyproject.toml``, eles podem usar a tabela ``[tool]`` " -"conforme definido na :ref:`especificação da declaração de dependências de " -"construção `. A falta de uma tabela " -"``[project]`` implicitamente significa que o backend da construção fornecerá " -"dinamicamente todos os campos." - -#: ../source/specifications/declaring-project-metadata.rst:27 -msgid "The only fields required to be statically defined are:" -msgstr "Os únicos campos que precisam ser definidos estaticamente são:" - -#: ../source/specifications/declaring-project-metadata.rst:29 -#: ../source/specifications/declaring-project-metadata.rst:41 -msgid "``name``" -msgstr "``name``" - -#: ../source/specifications/declaring-project-metadata.rst:31 -msgid "" -"The fields which are required but may be specified *either* statically or " -"listed as dynamic are:" -msgstr "" -"Os campos que são obrigatórios, mas podem ser especificados *ou* " -"estaticamente ou listados como dinâmicos são:" - -#: ../source/specifications/declaring-project-metadata.rst:34 -#: ../source/specifications/declaring-project-metadata.rst:54 -msgid "``version``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:36 -msgid "" -"All other fields are considered optional and my be specified statically, " -"listed as dynamic, or left unspecified." -msgstr "" -"Todos os outros campos são considerados opcionais e podem ser especificados " -"estaticamente, listados como dinâmicos ou não especificados." - -#: ../source/specifications/declaring-project-metadata.rst:43 -#: ../source/specifications/declaring-project-metadata.rst:56 -#: ../source/specifications/declaring-project-metadata.rst:68 -#: ../source/specifications/declaring-project-metadata.rst:117 -msgid "TOML_ type: string" -msgstr "Tipo TOML_: string" - -#: ../source/specifications/declaring-project-metadata.rst:44 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Name `" -msgstr "" -"Campo correspondente dos :ref:`metadados principais `: :ref:`" -"Name `" - -#: ../source/specifications/declaring-project-metadata.rst:47 -msgid "The name of the project." -msgstr "O nome do projeto." - -#: ../source/specifications/declaring-project-metadata.rst:49 -msgid "" -"Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it " -"is read for internal consistency." -msgstr "" -"As ferramentas DEVEM normalizar este nome, conforme especificado por " -":pep:`503`, assim que for lido para consistência interna." - -#: ../source/specifications/declaring-project-metadata.rst:57 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Version " -"`" -msgstr "" -"Campo correspondente dos :ref:`metadados principais `: :ref:`" -"Version `" - -#: ../source/specifications/declaring-project-metadata.rst:60 -msgid "The version of the project as supported by :pep:`440`." -msgstr "A versão do projeto conforme suportado pela :pep:`440`." - -#: ../source/specifications/declaring-project-metadata.rst:62 -msgid "Users SHOULD prefer to specify already-normalized versions." -msgstr "Os usuários DEVEM preferir especificar versões já normalizadas." - -#: ../source/specifications/declaring-project-metadata.rst:66 -msgid "``description``" -msgstr "``description``" - -#: ../source/specifications/declaring-project-metadata.rst:69 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Summary " -"`" -msgstr "" -"Campo correspondente dos :ref:`metadados principais `: :ref:`" -"Summary `" - -#: ../source/specifications/declaring-project-metadata.rst:72 -msgid "The summary description of the project." -msgstr "A descrição resumida do projeto." - -#: ../source/specifications/declaring-project-metadata.rst:76 -msgid "``readme``" -msgstr "``readme``" - -#: ../source/specifications/declaring-project-metadata.rst:78 -msgid "TOML_ type: string or table" -msgstr "Tipo TOML_: string ou tabela" - -#: ../source/specifications/declaring-project-metadata.rst:79 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Description " -"` and :ref:`Description-Content-Type `" -msgstr "" -"Campos correspondente dos :ref:`metadados principais `: :ref:`" -"Description ` e :ref:`Description-Content-Type " -"`" - -#: ../source/specifications/declaring-project-metadata.rst:83 -msgid "The full description of the project (i.e. the README)." -msgstr "A descrição completa do projeto (isto é, o README)." - -#: ../source/specifications/declaring-project-metadata.rst:85 -msgid "" -"The field accepts either a string or a table. If it is a string then it is a " -"path relative to ``pyproject.toml`` to a text file containing the full " -"description. Tools MUST assume the file's encoding is UTF-8. If the file " -"path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the " -"content-type is ``text/markdown``. If the file path ends in a case-" -"insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-" -"rst``. If a tool recognizes more extensions than this PEP, they MAY infer " -"the content-type for the user without specifying this field as ``dynamic``. " -"For all unrecognized suffixes when a content-type is not provided, tools " -"MUST raise an error." -msgstr "" -"O campo aceita uma string ou uma tabela. Se for uma string, então é um " -"caminho relativo ao ``pyproject.toml`` para um arquivo texto contendo a " -"descrição completa. As ferramentas DEVEM assumir que a codificação do " -"arquivo é UTF-8. Se o caminho do arquivo termina com um sufixo ``.md``, ou " -"sua versão em caixa alta, então as ferramentas DEVEM presumir que o tipo de " -"conteúdo é ``text/markdown``. Se o caminho do arquivo termina em ``.rst``, " -"então as ferramentas DEVEM presumir que o tipo de conteúdo é ``text/x-rst``. " -"Se uma ferramenta reconhece mais extensões do que esta PEP, elas podem " -"inferir o tipo de conteúdo para o usuário sem especificar este campo como " -"``dunamic``. Para todos os sufixos não reconhecidos quando um tipo de " -"conteúdo não é fornecido, as ferramentas DEVEM levantar um erro." - -#: ../source/specifications/declaring-project-metadata.rst:96 -msgid "" -"The ``readme`` field may also take a table. The ``file`` key has a string " -"value representing a path relative to ``pyproject.toml`` to a file " -"containing the full description. The ``text`` key has a string value which " -"is the full description. These keys are mutually-exclusive, thus tools MUST " -"raise an error if the metadata specifies both keys." -msgstr "" -"O campo ``readme`` também pode receber uma tabela. A chave ``file`` tem um " -"valor string que representa um caminho relativo a ``pyproject.toml`` para um " -"arquivo contendo a descrição completa. A chave ``text`` tem um valor de " -"string que é a descrição completa. Essas chaves são mutuamente exclusivas, " -"portanto, as ferramentas DEVEM levantar um erro se os metadados " -"especificarem ambas as chaves." - -#: ../source/specifications/declaring-project-metadata.rst:103 -msgid "" -"A table specified in the ``readme`` field also has a ``content-type`` field " -"which takes a string specifying the content-type of the full description. A " -"tool MUST raise an error if the metadata does not specify this field in the " -"table. If the metadata does not specify the ``charset`` parameter, then it " -"is assumed to be UTF-8. Tools MAY support other encodings if they choose to. " -"Tools MAY support alternative content-types which they can transform to a " -"content-type as supported by the :ref:`core metadata `. " -"Otherwise tools MUST raise an error for unsupported content-types." -msgstr "" -"Uma tabela especificada no campo ``readme`` também possui um campo ``content-" -"type`` que recebe uma string especificando o tipo de conteúdo da descrição " -"completa. Uma ferramenta DEVE levantar um erro se os metadados não " -"especificarem esse campo na tabela. Se os metadados não especificarem o " -"parâmetro ``charset``, será considerado UTF-8. As ferramentas PODEM oferecer " -"suporte a outras codificações, se assim o desejarem. As ferramentas PODEM " -"oferecer suporte a tipos de conteúdo alternativos que podem transformar em " -"um tipo de conteúdo conforme suportado pelos :ref:`metadados principais " -"`. Caso contrário, as ferramentas DEVEM levantar um erro para " -"tipos de conteúdo não suportados." - -#: ../source/specifications/declaring-project-metadata.rst:115 -msgid "``requires-python``" -msgstr "``requires-python``" - -#: ../source/specifications/declaring-project-metadata.rst:118 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Requires-" -"Python `" -msgstr "" -"Campo correspondente dos :ref:`metadados principais `: :ref" -":`Requires-Python `" - -#: ../source/specifications/declaring-project-metadata.rst:121 -msgid "The Python version requirements of the project." -msgstr "Os requisitos de versão do Python do projeto." - -#: ../source/specifications/declaring-project-metadata.rst:125 -msgid "``license``" -msgstr "``license``" - -#: ../source/specifications/declaring-project-metadata.rst:127 -msgid "TOML_ type: table" -msgstr "Tipo TOML_: tabela" - -#: ../source/specifications/declaring-project-metadata.rst:128 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`License " -"`" -msgstr "" -"Campo correspondente dos :ref:`metadados principais `: :ref:`" -"License `" - -#: ../source/specifications/declaring-project-metadata.rst:131 -msgid "" -"The table may have one of two keys. The ``file`` key has a string value that " -"is a file path relative to ``pyproject.toml`` to the file which contains the " -"license for the project. Tools MUST assume the file's encoding is UTF-8. The " -"``text`` key has a string value which is the license of the project. These " -"keys are mutually exclusive, so a tool MUST raise an error if the metadata " -"specifies both keys." -msgstr "" -"A tabela pode ter uma de duas chaves. A chave ``file`` tem um valor de " -"string que é um caminho de arquivo relativo a ``pyproject.toml`` para o " -"arquivo que contém a licença do projeto. As ferramentas DEVEM presumir que a " -"codificação do arquivo é UTF-8. A chave ``text`` tem um valor de string que " -"é a licença do projeto. Essas chaves são mutuamente exclusivas, portanto, " -"uma ferramenta DEVE levantar um erro se os metadados especificarem ambas as " -"chaves." - -#: ../source/specifications/declaring-project-metadata.rst:140 -msgid "``authors``/``maintainers``" -msgstr "``authors``/``maintainers``" - -#: ../source/specifications/declaring-project-metadata.rst:142 -msgid "TOML_ type: Array of inline tables with string keys and values" -msgstr "Tipo TOML_: Vetor de tabelas em linha com strings de chaves e valores" - -#: ../source/specifications/declaring-project-metadata.rst:143 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:" -"`Maintainer `, and :ref:`Maintainer-email `" -msgstr "" -"Campos correspondentes dos :ref:`metadados principais `: " -":ref:`Author `, :ref:`Author-email `, :ref:`Maintainer ` e :ref" -":`Maintainer-email `" - -#: ../source/specifications/declaring-project-metadata.rst:149 -msgid "" -"The people or organizations considered to be the \"authors\" of the project. " -"The exact meaning is open to interpretation — it may list the original or " -"primary authors, current maintainers, or owners of the package." -msgstr "" -"As pessoas ou organizações consideradas \"autoras\" do projeto. O " -"significado exato está aberto à interpretação -- pode listar os autores " -"originais ou primários, mantenedores atuais ou proprietários do pacote." - -#: ../source/specifications/declaring-project-metadata.rst:154 -msgid "" -"The \"maintainers\" field is similar to \"authors\" in that its exact " -"meaning is open to interpretation." -msgstr "" -"O campo \"maintainers\" é semelhante a \"authors\" no sentido de que seu " -"significado exato está aberto à interpretação." - -#: ../source/specifications/declaring-project-metadata.rst:157 -msgid "" -"These fields accept an array of tables with 2 keys: ``name`` and ``email``. " -"Both values must be strings. The ``name`` value MUST be a valid email name " -"(i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not " -"contain commas. The ``email`` value MUST be a valid email address. Both keys " -"are optional." -msgstr "" -"Estes campos aceitam um vetor de tabelas com 2 chaves: ``name`` e ``email``. " -"Ambos os valores devem ser strings. O valor ``name`` DEVE ser um nome de e-" -"mail válido (ou seja, o que quer que possa ser colocado como um nome, antes " -"de um e-mail, em `RFC 822`_) e não conter vírgulas. O valor ``email`` DEVE " -"ser um endereço de email válido. Ambas as chaves são opcionais." - -#: ../source/specifications/declaring-project-metadata.rst:163 -msgid "" -"Using the data to fill in :ref:`core metadata ` is as follows:" -msgstr "" -"O uso dos dados para preencher :ref:`metadados principais ` " -"deve ser feito da seguinte forma:" - -#: ../source/specifications/declaring-project-metadata.rst:166 -msgid "" -"If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." -msgstr "" -"Se somente ``name`` for fornecido, o valor vai em :ref:`Author ` ou :ref:`Maintainer ` conforme " -"apropriado." - -#: ../source/specifications/declaring-project-metadata.rst:169 -msgid "" -"If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." -msgstr "" -"Se somente ``email`` é fornecido, o valor vai em :ref:`Author-email ` ou :ref:`Maintainer-email ` conforme apropriado." - -#: ../source/specifications/declaring-project-metadata.rst:173 -msgid "" -"If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-" -"email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." -msgstr "" -"Se ``email`` e ``name`` são fornecidos, o valor vai em :ref:`Author-email " -"` ou :ref:`Maintainer-email ` conforme apropriado, com o formado ``{name} <{email}>``." - -#: ../source/specifications/declaring-project-metadata.rst:177 -msgid "Multiple values should be separated by commas." -msgstr "Vários valores devem ser separados por vírgulas." - -#: ../source/specifications/declaring-project-metadata.rst:181 -msgid "``keywords``" -msgstr "``keywords``" - -#: ../source/specifications/declaring-project-metadata.rst:183 -#: ../source/specifications/declaring-project-metadata.rst:193 -msgid "TOML_ type: array of strings" -msgstr "Tipo TOML_: vetor de strings" - -#: ../source/specifications/declaring-project-metadata.rst:184 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Keywords " -"`" -msgstr "" -"Campo correspondente dos :ref:`metadados principais `: :ref:`" -"Keywords `" - -#: ../source/specifications/declaring-project-metadata.rst:187 -msgid "The keywords for the project." -msgstr "As palavras-chave do projeto." - -#: ../source/specifications/declaring-project-metadata.rst:191 -msgid "``classifiers``" -msgstr "``classifiers``" - -#: ../source/specifications/declaring-project-metadata.rst:194 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Classifier " -"`" -msgstr "" -"Campo correspondente dos :ref:`metadados principais `: :ref:`" -"Classifier `" - -#: ../source/specifications/declaring-project-metadata.rst:197 -msgid "Trove classifiers which apply to the project." -msgstr "Classificadores Trove que se aplicam ao projeto." - -#: ../source/specifications/declaring-project-metadata.rst:201 -msgid "``urls``" -msgstr "``urls``" - -#: ../source/specifications/declaring-project-metadata.rst:203 -msgid "TOML_ type: table with keys and values of strings" -msgstr "Tipo TOML_: tabela com chaves e valores de strings" - -#: ../source/specifications/declaring-project-metadata.rst:204 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Project-URL " -"`" -msgstr "" -"Campo correspondente dos :ref:`metadados principais `: :ref" -":`Project-URL `" - -#: ../source/specifications/declaring-project-metadata.rst:207 -msgid "" -"A table of URLs where the key is the URL label and the value is the URL " -"itself." -msgstr "" -"Uma tabela de URLs onde a chave é o rótulo da URL e o valor é a URL em si." - -#: ../source/specifications/declaring-project-metadata.rst:212 -msgid "Entry points" -msgstr "Pontos de entrada" - -#: ../source/specifications/declaring-project-metadata.rst:214 -msgid "" -"TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and " -"``[project.entry-points]``)" -msgstr "" -"Tipo TOML_: tabela (``[project.scripts]``, ``[project.gui-scripts]`` e " -"``[project.entry-points]``)" - -#: ../source/specifications/declaring-project-metadata.rst:216 -msgid ":ref:`Entry points specification `" -msgstr ":ref:`Especificação de pontos de entrada `" - -#: ../source/specifications/declaring-project-metadata.rst:218 -msgid "" -"There are three tables related to entry points. The ``[project.scripts]`` " -"table corresponds to the ``console_scripts`` group in the :ref:`entry points " -"specification `. The key of the table is the name of the entry " -"point and the value is the object reference." -msgstr "" -"Existem três tabelas relacionadas aos pontos de entrada. A tabela ``[project." -"scripts]`` corresponde ao grupo ``console_scripts`` na :ref:`especificação " -"de pontos de entrada `. A chave da tabela é o nome do ponto de " -"entrada e o valor é a referência do objeto." - -#: ../source/specifications/declaring-project-metadata.rst:224 -msgid "" -"The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group " -"in the :ref:`entry points specification `. Its format is the " -"same as ``[project.scripts]``." -msgstr "" -"A tabela ``[project.gui-scripts]`` corresponde ao grupo ``gui_scripts`` na " -":ref:`especificação de pontos de entrada `. Seu formato é o " -"mesmo que ``[project.scripts]``." - -#: ../source/specifications/declaring-project-metadata.rst:228 -msgid "" -"The ``[project.entry-points]`` table is a collection of tables. Each sub-" -"table's name is an entry point group. The key and value semantics are the " -"same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but " -"instead keep the entry point groups to only one level deep." -msgstr "" -"A tabela ``[project.entry-points]`` é uma coleção de tabelas. O nome de cada " -"subtabela é um grupo de pontos de entrada. A chave e a semântica do valor " -"são iguais a ``[project.scripts]``. Os usuários NÃO DEVEM criar subtabelas " -"aninhadas, mas sim manter os grupos de pontos de entrada em apenas um nível " -"de profundidade." - -#: ../source/specifications/declaring-project-metadata.rst:234 -msgid "" -"Build back-ends MUST raise an error if the metadata defines a ``[project." -"entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` " -"table, as they would be ambiguous in the face of ``[project.scripts]`` and " -"``[project.gui-scripts]``, respectively." -msgstr "" -"Backends de construção DEVEM levantar um erro se os metadados definem uma " -"tabela ``[project.entry-points.console_scripts]`` ou ``[project.entry-points." -"gui_scripts]``, pois elas seriam ambíguas perante ``[project.scripts]`` e " -"``[project.gui-scripts]``, respectivamente." - -#: ../source/specifications/declaring-project-metadata.rst:242 -msgid "``dependencies``/``optional-dependencies``" -msgstr "``dependencies``/``optional-dependencies``" - -#: ../source/specifications/declaring-project-metadata.rst:244 -msgid "" -"TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with " -"values of arrays of :pep:`508` strings (``optional-dependencies``)" -msgstr "" -"Tipo TOML_: Vetor de strings da :pep:`508` (``dependencies``) e uma tabela " -"com valores de vetores de strings da :pep:`508` (``optional-dependencies``)" - -#: ../source/specifications/declaring-project-metadata.rst:247 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Requires-" -"Dist ` and :ref:`Provides-Extra `" -msgstr "" -"Campo correspondente dos :ref:`metadados principais `: :ref" -":`Requires-Dist ` e :ref:`Provides-Extra `" - -#: ../source/specifications/declaring-project-metadata.rst:251 -msgid "The (optional) dependencies of the project." -msgstr "As dependências (opcionais) do projeto." - -#: ../source/specifications/declaring-project-metadata.rst:253 -msgid "" -"For ``dependencies``, it is a key whose value is an array of strings. Each " -"string represents a dependency of the project and MUST be formatted as a " -"valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist " -"` entry." -msgstr "" -"Para ``dependencies``, é uma chave cujo valor é um array de strings. Cada " -"string representa uma dependência do projeto e DEVE ser formatada como uma " -"string válida :pep:`508`. Cada string mapeia diretamente para um :ref" -":`Requires-Dist `." - -#: ../source/specifications/declaring-project-metadata.rst:258 -msgid "" -"For ``optional-dependencies``, it is a table where each key specifies an " -"extra and whose value is an array of strings. The strings of the arrays must " -"be valid :pep:`508` strings. The keys MUST be valid values for :ref:" -"`Provides-Extra `. Each value in the array " -"thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." -msgstr "" -"Para ``optional-dependencies``, é uma tabela onde cada chave especifica um " -"extra e cujo valor é um vetor de strings. As strings dos vetores devem ser " -"strings válidas da :pep:`508`. As chaves DEVEM ser valores válidos para :ref" -":`Provides-Extra `. Cada valor no vetor torna-" -"se assim uma entrada correspondente de :ref:`Requer-Dist ` para os metadados correspondentes de :ref:`Provides-Extra " -"`." - -#: ../source/specifications/declaring-project-metadata.rst:269 -msgid "``dynamic``" -msgstr "``dynamic``" - -#: ../source/specifications/declaring-project-metadata.rst:271 -msgid "TOML_ type: array of string" -msgstr "Tipo TOML_: vetor de string" - -#: ../source/specifications/declaring-project-metadata.rst:272 -msgid "" -"A corresponding :ref:`core metadata ` field does not exist" -msgstr "" -"Não há um campo correspondente dos :ref:`metadados principais `" - -#: ../source/specifications/declaring-project-metadata.rst:275 -msgid "" -"Specifies which fields listed by this PEP were intentionally unspecified so " -"another tool can/will provide such metadata dynamically. This clearly " -"delineates which metadata is purposefully unspecified and expected to stay " -"unspecified compared to being provided via tooling later on." -msgstr "" -"Especifica quais campos listados por esta PEP foram intencionalmente não " -"especificados para que outra ferramenta possa/vai fornecer tais metadados " -"dinamicamente. Isso delineia claramente quais metadados são propositalmente " -"não especificados e espera-se que permaneçam não especificados em comparação " -"a serem fornecidos por meio de ferramentas posteriormente." - -#: ../source/specifications/declaring-project-metadata.rst:281 -msgid "" -"A build back-end MUST honour statically-specified metadata (which means the " -"metadata did not list the field in ``dynamic``)." -msgstr "" -"Um backend de construção DEVE respeitar metadados especificados " -"estaticamente (o que significa que os metadados não listam o campo em " -"``dynamic``)." - -#: ../source/specifications/declaring-project-metadata.rst:283 -msgid "" -"A build back-end MUST raise an error if the metadata specifies ``name`` in " -"``dynamic``." -msgstr "" -"Um backend de construção DEVE gerar um erro se os metadados especificarem " -"``name`` em ``dynamic``." - -#: ../source/specifications/declaring-project-metadata.rst:285 -msgid "" -"If the :ref:`core metadata ` specification lists a field as " -"\"Required\", then the metadata MUST specify the field statically or list it " -"in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it " -"should not be possible for a required field to not be listed somehow in the " -"``[project]`` table)." -msgstr "" -"Se a especificação de :ref:`metadados principais ` lista um " -"campo como \"Required\", então os metadados DEVEM especificar o campo " -"estaticamente ou listá-lo em ``dynamic`` (backends de construção DEVEM gerar " -"um erro, caso contrário , ou seja, não deve ser possível que um campo " -"obrigatório não seja listado de alguma forma na tabela ``[project]``)." - -#: ../source/specifications/declaring-project-metadata.rst:290 -msgid "" -"If the :ref:`core metadata ` specification lists a field as " -"\"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is " -"a build back-end will provide the data for the field later." -msgstr "" -"Se a especificação de :ref:`metadados principais ` listar um " -"campo como \"Optional\", os metadados PODEM listá-lo em ``dynamic`` se a " -"expectativa for um backend de construção fornecerá os dados para o campo " -"mais tarde." - -#: ../source/specifications/declaring-project-metadata.rst:294 -msgid "" -"Build back-ends MUST raise an error if the metadata specifies a field " -"statically as well as being listed in ``dynamic``." -msgstr "" -"Os backends de construção DEVEM levantar um erro se os metadados " -"especificarem um campo estaticamente, além de serem listados em `` dynamic``." - -#: ../source/specifications/declaring-project-metadata.rst:296 -msgid "" -"If the metadata does not list a field in ``dynamic``, then a build back-end " -"CANNOT fill in the requisite metadata on behalf of the user (i.e. " -"``dynamic`` is the only way to allow a tool to fill in metadata and the user " -"must opt into the filling in)." -msgstr "" -"Se os metadados não listam um campo em ``dynamic``, então um backend de " -"construção NÃO PODE preencher os metadados necessários em nome do usuário (" -"ou seja, ``dynamic`` é a única maneira de permitir que uma ferramenta " -"preencha metadados e o usuário deve optar pelo preenchimento)." - -#: ../source/specifications/declaring-project-metadata.rst:300 -msgid "" -"Build back-ends MUST raise an error if the metadata specifies a field in " -"``dynamic`` but the build back-end was unable to determine the data for it " -"(omitting the data, if determined to be the accurate value, is acceptable)." -msgstr "" -"Os backends de construção DEVEM levantar um erro se os metadados " -"especificarem um campo em ``dynamic``, mas o backend de construção não foi " -"capaz de determinar os dados para ele (omitir os dados, se determinado como " -"o valor exato, é aceitável) ." - -#: ../source/specifications/dependency-specifiers.rst:6 -msgid "Dependency specifiers" -msgstr "Especificadores de dependência" - -#: ../source/specifications/dependency-specifiers.rst:8 -msgid "" -"The dependency specifier format used to declare a dependency on another " -"component is defined in :pep:`508`." -msgstr "" -"O formato do especificador de dependência usado para declarar uma " -"dependência de outro componente é definido na :pep:`508`." - -#: ../source/specifications/dependency-specifiers.rst:11 -msgid "" -"The environment markers section in this PEP supersedes the environment " -"markers section in :pep:`345`." -msgstr "" -"A seção de marcadores de ambiente nesta PEP substitui a seção de marcadores " -"de ambiente na :pep:`345`." - -#: ../source/specifications/direct-url.rst:6 -msgid "Recording the Direct URL Origin of installed distributions" -msgstr "Gravando a Origem da URL Direta de distribuições instaladas" - -#: ../source/specifications/direct-url.rst:8 -msgid "" -"This document specifies a :file:`direct_url.json` file in the :file:`*.dist-" -"info` directory of an installed distribution, to record the Direct URL " -"Origin of the distribution. The layout of this file was originally specified " -"in :pep:`610` and is formally documented here." -msgstr "" -"Este documento especifica um arquivo :file:`direct_url.json` no diretório " -":file:`*.dist-info` de uma distribuição instalada, para registrar a origem " -"da URL direta da distribuição. O layout deste arquivo foi originalmente " -"especificado na :pep:`610` e está formalmente documentado aqui." - -#: ../source/specifications/direct-url.rst:17 -msgid "Specification" -msgstr "Especificação" - -#: ../source/specifications/direct-url.rst:19 -msgid "" -"The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` " -"directory by installers when installing a distribution from a requirement " -"specifying a direct URL reference (including a VCS URL)." -msgstr "" -"O arquivo :file:`direct_url.json` DEVE ser criado no diretório :file:`*.dist-" -"info` pelos instaladores ao instalar uma distribuição a partir de um " -"requisito especificando uma referência de URL direta (incluindo uma URL de " -"VCS)." - -#: ../source/specifications/direct-url.rst:23 -#: ../source/specifications/recording-installed-packages.rst:206 -msgid "" -"This file MUST NOT be created when installing a distribution from an other " -"type of requirement (i.e. name plus version specifier)." -msgstr "" -"Este arquivo NÃO DEVE ser criado ao instalar uma distribuição de outro tipo " -"de requisito (ou seja, nome mais especificador de versão)." - -#: ../source/specifications/direct-url.rst:26 -msgid "" -"This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." -msgstr "" -"Este arquivo JSON DEVE ser um dicionário compatível com `RFC 8259 " -"`_ e codificado em UTF-8." - -#: ../source/specifications/direct-url.rst:29 -msgid "" -"If present, it MUST contain at least two fields. The first one is ``url``, " -"with type ``string``. Depending on what ``url`` refers to, the second field " -"MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), " -"``archive_info`` (if ``url`` is a source archives or a wheel), or " -"``dir_info`` (if ``url`` is a local directory). These info fields have a " -"(possibly empty) subdictionary as value, with the possible keys defined " -"below." -msgstr "" -"Se presente, DEVE conter pelo menos dois campos. O primeiro é ``url``, com " -"tipo ``string``. Dependendo de qual ``url`` se refere, o segundo campo DEVE " -"ser um de ``vcs_info`` (se ``url`` é uma referência de VCS), ``archive_info``" -" (se ``url`` é um arquivo de código-fonte ou um wheel) ou ``dir_info`` (se " -"``url`` é um diretório local). Estes campos informacionais têm um " -"subdicionário (possivelmente vazio) como valor, com as chaves possíveis " -"definidas abaixo." - -#: ../source/specifications/direct-url.rst:36 -msgid "" -"``url`` MUST be stripped of any sensitive authentication information, for " -"security reasons." -msgstr "" -"``url`` DEVE ser podado a fim de retirar qualquer informação de autenticação " -"sensível, por razões de segurança." - -#: ../source/specifications/direct-url.rst:39 -msgid "" -"The user:password section of the URL MAY however be composed of environment " -"variables, matching the following regular expression::" -msgstr "" -"A seção usuário:senha da URL PODE, entretanto, ser composta de variáveis de " -"ambiente, correspondendo à seguinte expressão regular::" - -#: ../source/specifications/direct-url.rst:45 -msgid "" -"Additionally, the user:password section of the URL MAY be a well-known, non " -"security sensitive string. A typical example is ``git`` in the case of an " -"URL such as ``ssh://git@gitlab.com/user/repo``." -msgstr "" -"Além disso, a seção usuário:senha da URL PODE ser uma string bem conhecida e " -"não sensível à segurança. Um exemplo típico é ``git`` no caso de uma URL " -"como ``ssh://git@gitlab.com/user/repo``." - -#: ../source/specifications/direct-url.rst:49 -msgid "" -"When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be " -"present as a dictionary with the following keys:" -msgstr "" -"Quando a ``url`` faz referência a um repositório VCS, a chave ``vcs_info`` " -"DEVE estar presente como um dicionário com as seguintes chaves:" - -#: ../source/specifications/direct-url.rst:52 -msgid "" -"A ``vcs`` key (type ``string``) MUST be present, containing the name of the " -"VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be " -"registered by writing a PEP to amend this specification. The ``url`` value " -"MUST be compatible with the corresponding VCS, so an installer can hand it " -"off without transformation to a checkout/download command of the VCS." -msgstr "" -"Uma chave ``vcs`` (tipo ``string``) DEVE estar presente, contendo o nome do " -"VCS (ou seja, um de ``git``, ``hg``, ``bzr``, ``svn``). Outros VCS DEVERIAM " -"ser registrados escrevendo uma PEP para alterar esta especificação. O valor " -"``url`` DEVE ser compatível com o VCS correspondente, para que um instalador " -"possa entregá-lo sem transformação em um comando de checkout/download do VCS." - -#: ../source/specifications/direct-url.rst:58 -msgid "" -"A ``requested_revision`` key (type ``string``) MAY be present naming a " -"branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to " -"install." -msgstr "" -"Uma chave ``required_revision`` (tipo ``string``) PODE estar presente " -"nomeando um branch/tag/ref/commit/revisão/etc (em um formato compatível com " -"o VCS) para instalar." - -#: ../source/specifications/direct-url.rst:61 -msgid "" -"A ``commit_id`` key (type ``string``) MUST be present, containing the exact " -"commit/revision number that was installed. If the VCS supports commit-hash " -"based revision identifiers, such commit-hash MUST be used as ``commit_id`` " -"in order to reference the immutable version of the source code that was " -"installed." -msgstr "" -"Uma chave ``commit_id`` (tipo ``string``) DEVE estar presente, contendo o " -"número exato de commit/revisão que foi instalado. Se o VCS oferecer suporte " -"a identificadores de revisão baseados em hash de commit, tal hash de commit " -"DEVE ser usado como ``commit_id`` para referenciar a versão imutável do " -"código-fonte que foi instalado." - -#: ../source/specifications/direct-url.rst:68 -msgid "" -"When ``url`` refers to a source archive or a wheel, the ``archive_info`` key " -"MUST be present as a dictionary with the following key:" -msgstr "" -"Quando ``url`` se refere a um arquivo fonte ou wheel, a chave " -"``archive_info`` DEVE estar presente como um dicionário com a seguinte chave:" - -#: ../source/specifications/direct-url.rst:71 -msgid "" -"A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are " -"unconditionally provided by the latest version of the standard library's " -"``hashlib`` module be used for source archive hashes. At time of writing, " -"that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and " -"'sha512'." -msgstr "" -"Uma chave ``hash`` (tipo ``string``) DEVE estar presente, com o valor " -"``=``. É RECOMENDADO que apenas hashes que " -"são fornecidos incondicionalmente pela última versão do módulo ``hashlib`` " -"da biblioteca padrão sejam usados para hashes de arquivo fonte. No momento " -"da escrita, essa lista consistia em 'md5', 'sha1', 'sha224', 'sha256', " -"'sha384' e 'sha512'." - -#: ../source/specifications/direct-url.rst:78 -msgid "" -"When ``url`` refers to a local directory, the ``dir_info`` key MUST be " -"present as a dictionary with the following key:" -msgstr "" -"Quando ``url`` se refere a um diretório local, a chave ``dir_info`` DEVE " -"estar presente como um dicionário com a seguinte chave:" - -#: ../source/specifications/direct-url.rst:81 -msgid "" -"``editable`` (type: ``boolean``): ``true`` if the distribution was installed " -"in editable mode, ``false`` otherwise. If absent, default to ``false``." -msgstr "" -"``editable`` (tipo: ``boolean``): ``true`` se a distribuição foi instalada " -"em modo editável, ``false`` caso contrário. Se ausente, é usado o padrão " -"``false``." - -#: ../source/specifications/direct-url.rst:84 -msgid "" -"When ``url`` refers to a local directory, it MUST have the ``file`` sheme " -"and be compliant with `RFC 8089 `_. In " -"particular, the path component must be absolute. Symbolic links SHOULD be " -"preserved when making relative paths absolute." -msgstr "" -"Quando ``url`` se refere a um diretório local, ele DEVE ter o esquema `` " -"file`` e ser compatível com `RFC 8089 `" -"_. Em particular, o componente do caminho deve ser absoluto. Links " -"simbólicos DEVERIAM ser preservados ao tornar os caminhos relativos " -"absolutos." - -#: ../source/specifications/direct-url.rst:91 -msgid "" -"When the requested URL has the file:// scheme and points to a local " -"directory that happens to contain a VCS checkout, installers MUST NOT " -"attempt to infer any VCS information and therefore MUST NOT output any VCS " -"related information (such as ``vcs_info``) in :file:`direct_url.json`." -msgstr "" -"Quando a URL solicitada tem o esquema file:// e aponta para um diretório " -"local que contém um checkout VCS, os instaladores NÃO DEVEM tentar inferir " -"nenhuma informação VCS e, portanto, NÃO DEVEM emitir nenhuma informação " -"relacionada ao VCS (como ``vcs_info``) in :file:`direct_url.json`." - -#: ../source/specifications/direct-url.rst:96 -msgid "" -"A top-level ``subdirectory`` field MAY be present containing a directory " -"path, relative to the root of the VCS repository, source archive or local " -"directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." -msgstr "" -"Um campo ``subdirectory`` de nível superior PODE estar presente contendo um " -"caminho de diretório, relativo à raiz do repositório VCS, arquivo fonte ou " -"diretório local, para especificar onde ``pyproject.toml`` ou ``setup.py`` " -"está localizado." - -#: ../source/specifications/direct-url.rst:102 -msgid "" -"As a general rule, installers should as much as possible preserve the " -"information that was provided in the requested URL when generating :file:" -"`direct_url.json`. For example user:password environment variables should be " -"preserved and ``requested_revision`` should reflect the revision that was " -"provided in the requested URL as faithfully as possible. This information is " -"however *enriched* with more precise data, such as ``commit_id``." -msgstr "" -"Como regra geral, os instaladores devem, tanto quanto possível, preservar as " -"informações fornecidas na URL solicitada ao gerar :file:`direct_url.json`. " -"Por exemplo, as variáveis de ambiente usuário:senha devem ser preservadas e " -"``required_revision`` deve refletir a revisão que foi fornecida na URL " -"solicitada o mais fielmente possível. No entanto, essas informações são " -"*enriquecidas* com dados mais precisos, como ``commit_id``." - -#: ../source/specifications/direct-url.rst:110 -msgid "Registered VCS" -msgstr "VCS registrados" - -#: ../source/specifications/direct-url.rst:112 -msgid "" -"This section lists the registered VCS's; expanded, VCS-specific information " -"on how to use the ``vcs``, ``requested_revision``, and other fields of " -"``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY " -"support other VCS's although it is RECOMMENDED to register them by writing a " -"PEP to amend this specification. The ``vcs`` field SHOULD be the command " -"name (lowercased). Additional fields that would be necessary to support such " -"VCS SHOULD be prefixed with the VCS command name." -msgstr "" -"Esta seção lista os VCS registrados; expandidos, informações específicas do " -"VCS sobre como usar ``vcs``, ``required_revision`` e outros campos de " -"``vcs_info``; e, em alguns casos, campos adicionais específicos de VCS. As " -"ferramentas PODEM oferecer suporte a outros VCS, embora seja RECOMENDADO " -"registrá-las escrevendo uma PEP para alterar esta especificação. O campo " -"``vcs`` DEVERIA ser o nome do comando (em letras minúsculas). Os campos " -"adicionais que seriam necessários para oferecer suporte a esse VCS DEVERIAM " -"ser prefixados com o nome do comando VCS." - -#: ../source/specifications/direct-url.rst:122 -msgid "Git" -msgstr "Git" - -#: ../source/specifications/direct-url.rst:124 -#: ../source/specifications/direct-url.rst:156 -#: ../source/specifications/direct-url.rst:179 -#: ../source/specifications/direct-url.rst:202 -msgid "Home page" -msgstr "Site" - -#: ../source/specifications/direct-url.rst:126 -msgid "https://git-scm.com/" -msgstr "https://git-scm.com/" - -#: ../source/specifications/direct-url.rst:128 -#: ../source/specifications/direct-url.rst:160 -#: ../source/specifications/direct-url.rst:183 -#: ../source/specifications/direct-url.rst:206 -msgid "vcs command" -msgstr "Comando vcs" - -#: ../source/specifications/direct-url.rst:130 -#: ../source/specifications/direct-url.rst:134 -msgid "git" -msgstr "git" - -#: ../source/specifications/direct-url.rst:132 -#: ../source/specifications/direct-url.rst:164 -#: ../source/specifications/direct-url.rst:187 -#: ../source/specifications/direct-url.rst:210 -msgid "``vcs`` field" -msgstr "Campo ``vcs``" - -#: ../source/specifications/direct-url.rst:136 -#: ../source/specifications/direct-url.rst:168 -#: ../source/specifications/direct-url.rst:191 -#: ../source/specifications/direct-url.rst:214 -msgid "``requested_revision`` field" -msgstr "Campo ``requested_revision``" - -#: ../source/specifications/direct-url.rst:138 -msgid "" -"A tag name, branch name, Git ref, commit hash, shortened commit hash, or " -"other commit-ish." -msgstr "" -"Um nome de tag, nome de branch, ref Git, hash de commit, hash de commit " -"encurtado ou outra coisa relacionada a commit." - -#: ../source/specifications/direct-url.rst:141 -#: ../source/specifications/direct-url.rst:172 -#: ../source/specifications/direct-url.rst:195 -#: ../source/specifications/direct-url.rst:219 -msgid "``commit_id`` field" -msgstr "Campo ``commit_id``" - -#: ../source/specifications/direct-url.rst:143 -msgid "A commit hash (40 hexadecimal characters sha1)." -msgstr "Um hash de confirmação (40 caracteres hexadecimais sha1)." - -#: ../source/specifications/direct-url.rst:147 -msgid "" -"Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to " -"determine if the ``requested_revision`` corresponds to a Git ref. In turn, a " -"ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning " -"with ``refs/remotes/origin/`` after cloning corresponds to a branch." -msgstr "" -"Os instaladores podem usar os comandos ``git show-ref`` e ``git symbolic-" -"ref`` para determinar se o ``required_revision`` corresponde a um ref Git. " -"Por sua vez, um ref começando com ``refs/tags/`` corresponde a uma tag, e um " -"ref começando com ``refs/remotes/origin/`` após a clonagem corresponde a um " -"branch." - -#: ../source/specifications/direct-url.rst:154 -msgid "Mercurial" -msgstr "Mercurial" - -#: ../source/specifications/direct-url.rst:158 -msgid "https://www.mercurial-scm.org/" -msgstr "https://www.mercurial-scm.org/" - -#: ../source/specifications/direct-url.rst:162 -#: ../source/specifications/direct-url.rst:166 -msgid "hg" -msgstr "hg" - -#: ../source/specifications/direct-url.rst:170 -msgid "A tag name, branch name, changeset ID, shortened changeset ID." -msgstr "" -"Um nome de tag, nome de branch, ID de changeset, ID de changeset abreviado." - -#: ../source/specifications/direct-url.rst:174 -msgid "A changeset ID (40 hexadecimal characters)." -msgstr "Um ID de changeset (40 caracteres hexadecimais)." - -#: ../source/specifications/direct-url.rst:177 -msgid "Bazaar" -msgstr "Bazaar" - -#: ../source/specifications/direct-url.rst:181 -msgid "https://bazaar.canonical.com/" -msgstr "https://bazaar.canonical.com/" - -#: ../source/specifications/direct-url.rst:185 -#: ../source/specifications/direct-url.rst:189 -msgid "bzr" -msgstr "bzr" - -#: ../source/specifications/direct-url.rst:193 -msgid "A tag name, branch name, revision id." -msgstr "Um nome de tag, nome de branch, id de revisão." - -#: ../source/specifications/direct-url.rst:197 -msgid "A revision id." -msgstr "Um id de revisão." - -#: ../source/specifications/direct-url.rst:200 -msgid "Subversion" -msgstr "" - -#: ../source/specifications/direct-url.rst:204 -msgid "https://subversion.apache.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:208 -#: ../source/specifications/direct-url.rst:212 -msgid "svn" -msgstr "svn" - -#: ../source/specifications/direct-url.rst:216 -msgid "" -"``requested_revision`` must be compatible with ``svn checkout`` ``--" -"revision`` option. In Subversion, branch or tag is part of ``url``." -msgstr "" -"``requested_revision`` deve ser compatível com a opção ``--revision`` do ``" -"svn checkout``. No Subversion, branch ou tag é parte de ``url``." - -#: ../source/specifications/direct-url.rst:221 -msgid "" -"Since Subversion does not support globally unique identifiers, this field is " -"the Subversion revision number in the corresponding repository." -msgstr "" -"Visto que o Subversion não oferece suporte a identificadores globalmente " -"únicos, este campo é o número da revisão do Subversion no repositório " -"correspondente." - -#: ../source/specifications/direct-url.rst:229 -msgid "Example direct_url.json" -msgstr "Exemplo de direct_url.json" - -#: ../source/specifications/direct-url.rst:231 -msgid "Source archive:" -msgstr "Arquivo fonte:" - -#: ../source/specifications/direct-url.rst:242 -msgid "Git URL with tag and commit-hash:" -msgstr "URL Git com tag e hash de commit:" - -#: ../source/specifications/direct-url.rst:255 -msgid "Local directory:" -msgstr "Diretório local:" - -#: ../source/specifications/direct-url.rst:264 -msgid "Local directory installed in editable mode:" -msgstr "Diretório local instalado em modo editável:" - -#: ../source/specifications/direct-url.rst:277 -msgid "Example pip commands and their effect on direct_url.json" -msgstr "Exemplo de comandos pip e seus efeitos em direct_url.json" - -#: ../source/specifications/direct-url.rst:279 -msgid "Commands that generate a ``direct_url.json``:" -msgstr "Comandos que geram um ``direct_url.json``:" - -#: ../source/specifications/direct-url.rst:281 -msgid "pip install https://example.com/app-1.0.tgz" -msgstr "pip install https://example.com/app-1.0.tgz" - -#: ../source/specifications/direct-url.rst:282 -msgid "pip install https://example.com/app-1.0.whl" -msgstr "pip install https://example.com/app-1.0.whl" - -#: ../source/specifications/direct-url.rst:283 -msgid "" -"pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup" -"\"" -msgstr "" -"pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=" -"setup\"" - -#: ../source/specifications/direct-url.rst:284 -msgid "pip install ./app" -msgstr "pip install ./app" - -#: ../source/specifications/direct-url.rst:285 -msgid "pip install file:///home/user/app" -msgstr "pip install file:///home/user/app" - -#: ../source/specifications/direct-url.rst:286 -msgid "" -"pip install --editable \"git+https://example.com/repo/app." -"git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local " -"directory where the git repository has been cloned to, and ``dir_info`` will " -"be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" -msgstr "" -"pip install --editable \"git+https://example.com/repo/app." -"git#egg=app&subdirectory=setup\" (caso em que, ``url`` será o diretório " -"local para o qual o repositório git foi clonado e ``dir_info`` estará " -"presente com ``\"editable\": true`` e nenhum ``vcs_info`` será definido)" - -#: ../source/specifications/direct-url.rst:290 -msgid "pip install -e ./app" -msgstr "pip install -e ./app" - -#: ../source/specifications/direct-url.rst:292 -msgid "Commands that *do not* generate a ``direct_url.json``" -msgstr "Comandos que *não* geram um ``direct_url.json``" - -#: ../source/specifications/direct-url.rst:294 -msgid "pip install app" -msgstr "pip install app" - -#: ../source/specifications/direct-url.rst:295 -msgid "pip install app --no-index --find-links https://example.com/" -msgstr "pip install app --no-index --find-links https://example.com/" - -#: ../source/specifications/entry-points.rst:5 -msgid "Entry points specification" -msgstr "Especificação de pontos de entrada" - -#: ../source/specifications/entry-points.rst:7 -msgid "" -"*Entry points* are a mechanism for an installed distribution to advertise " -"components it provides to be discovered and used by other code. For example:" -msgstr "" -"*Pontos de entrada* são um mecanismo para uma distribuição instalada " -"anunciar componentes que ela fornece para serem descobertos e usados por " -"outro código. Por exemplo:" - -#: ../source/specifications/entry-points.rst:11 -msgid "" -"Distributions can specify ``console_scripts`` entry points, each referring " -"to a function. When *pip* (or another console_scripts aware installer) " -"installs the distribution, it will create a command-line wrapper for each " -"entry point." -msgstr "" -"As distribuições podem especificar pontos de entrada ``console_scripts``, " -"cada um referindo-se a uma função. Quando *pip* (ou outro instalador " -"compatível com console_scripts) instala a distribuição, ele cria um wrapper " -"de linha de comando para cada ponto de entrada." - -#: ../source/specifications/entry-points.rst:14 -msgid "" -"Applications can use entry points to load plugins; e.g. Pygments (a syntax " -"highlighting tool) can use additional lexers and styles from separately " -"installed packages. For more about this, see :doc:`/guides/creating-and-" -"discovering-plugins`." -msgstr "" -"As aplicações podem usar pontos de entrada para carregar plug-ins; por " -"exemplo, Pygments (uma ferramenta de realce de sintaxe) pode usar lexers e " -"estilos adicionais de pacotes instalados separadamente. Para mais " -"informações, consulte :doc:`/guides/creating-and-discovering-plugins`." - -#: ../source/specifications/entry-points.rst:19 -msgid "" -"The entry point file format was originally developed to allow packages built " -"with setuptools to provide integration point metadata that would be read at " -"runtime with ``importlib.metadata``. It is now defined as a PyPA " -"interoperability specification in order to allow build tools other than " -"setuptools to publish ``importlib.metadata`` compatible entry point " -"metadata, and runtime libraries other than ``importlib.metadata`` to " -"portably read published entry point metadata (potentially with different " -"caching and conflict resolution strategies)." -msgstr "" -"O formato de arquivo de ponto de entrada foi originalmente desenvolvido para " -"permitir que pacotes construídos com setuptools forneçam metadados de ponto " -"de integração que seriam lidos em tempo de execução com ``importlib." -"metadata``. Ele agora é definido como uma especificação de " -"interoperabilidade PyPA a fim de permitir que outras ferramentas de " -"construção além do setuptools publiquem metadados de ponto de entrada " -"compatíveis com ``importlib.metadata`` e bibliotecas de tempo de execução " -"diferentes de ``importlib.metadata`` para ler portavelmente publicado " -"metadados de ponto de entrada (potencialmente com diferentes estratégias de " -"cache e resolução de conflitos)." - -#: ../source/specifications/entry-points.rst:28 -msgid "Data model" -msgstr "Modelo de dados" - -#: ../source/specifications/entry-points.rst:30 -msgid "Conceptually, an entry point is defined by three required properties:" -msgstr "" -"Conceitualmente, um ponto de entrada é definido por três propriedades " -"necessárias:" - -#: ../source/specifications/entry-points.rst:32 -msgid "" -"The **group** that an entry point belongs to indicates what sort of object " -"it provides. For instance, the group ``console_scripts`` is for entry points " -"referring to functions which can be used as a command, while ``pygments." -"styles`` is the group for classes defining pygments styles. The consumer " -"typically defines the expected interface. To avoid clashes, consumers " -"defining a new group should use names starting with a PyPI name owned by the " -"consumer project, followed by ``.``. Group names must be one or more groups " -"of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w" -"+)*$``)." -msgstr "" -"O **grupo** ao qual um ponto de entrada pertence indica que tipo de objeto " -"ele fornece. Por exemplo, o grupo ``console_scripts`` é para pontos de " -"entrada referentes a funções que podem ser usadas como um comando, enquanto " -"``pygments.styles`` é o grupo para classes que definem estilos de pigmentos. " -"O consumidor normalmente define a interface esperada. Para evitar conflitos, " -"os consumidores que definem um novo grupo devem usar nomes começando com um " -"nome PyPI pertencente ao projeto do consumidor, seguido por ``.``. Os nomes " -"dos grupos devem ser um ou mais grupos de letras, números e sublinhados, " -"separados por pontos (regex ``^\\w+(\\.\\w+)*$``)." - -#: ../source/specifications/entry-points.rst:42 -msgid "" -"The **name** identifies this entry point within its group. The precise " -"meaning of this is up to the consumer. For console scripts, the name of the " -"entry point is the command that will be used to launch it. Within a " -"distribution, entry point names should be unique. If different distributions " -"provide the same name, the consumer decides how to handle such conflicts. " -"The name may contain any characters except ``=``, but it cannot start or end " -"with any whitespace character, or start with ``[``. For new entry points, it " -"is recommended to use only letters, numbers, underscores, dots and dashes " -"(regex ``[\\w.-]+``)." -msgstr "" -"O **nome** identifica este ponto de entrada em seu grupo. O significado " -"preciso disso depende do cliente. Para scripts de console, o nome do ponto " -"de entrada é o comando que será usado para iniciá-lo. Em uma distribuição, " -"os nomes dos pontos de entrada devem ser exclusivos. Se distribuições " -"diferentes fornecerem o mesmo nome, o consumidor decide como lidar com tais " -"conflitos. O nome pode conter quaisquer caracteres, exceto ``=``, mas não " -"pode começar ou terminar com nenhum caractere de espaço em branco, ou " -"começar com ``[``. Para novos pontos de entrada, é recomendado usar apenas " -"letras, números, sublinhados, pontos e travessões (regex ``[\\w.-]+``)." - -#: ../source/specifications/entry-points.rst:51 -msgid "" -"The **object reference** points to a Python object. It is either in the form " -"``importable.module``, or ``importable.module:object.attr``. Each of the " -"parts delimited by dots and the colon is a valid Python identifier. It is " -"intended to be looked up like this::" -msgstr "" -"A **referência de objeto** aponta para um objeto Python. Ele está no formato " -"``importable.module`` ou ``importable.module:object.attr``. Cada uma das " -"partes delimitadas por pontos e dois pontos é um identificador válido " -"Python. Destina-se a ser consultado assim::" - -#: ../source/specifications/entry-points.rst:64 -msgid "" -"Some tools call this kind of object reference by itself an 'entry point', " -"for want of a better term, especially where it points to a function to " -"launch a program." -msgstr "" -"Algumas ferramentas chamam esse tipo de referência de objeto por si só de " -"\"ponto de entrada\", por falta de um termo melhor, especialmente quando " -"aponta para uma função para iniciar um programa." - -#: ../source/specifications/entry-points.rst:68 -msgid "" -"There is also an optional property: the **extras** are a set of strings " -"identifying optional features of the distribution providing the entry point. " -"If these are specified, the entry point requires the dependencies of those " -"'extras'. See the metadata field :ref:`metadata_provides_extra`." -msgstr "" -"Há também uma propriedade opcional: os **extras** são um conjunto de strings " -"que identifica recursos opcionais da distribuição que fornece o ponto de " -"entrada. Se forem especificados, o ponto de entrada requer as dependências " -"desses 'extras'. Veja o campo de metadados :ref:`metadata_provides_extra`." - -#: ../source/specifications/entry-points.rst:73 -msgid "" -"Using extras for an entry point is no longer recommended. Consumers should " -"support parsing them from existing distributions, but may then ignore them. " -"New publishing tools need not support specifying extras. The functionality " -"of handling extras was tied to setuptools' model of managing 'egg' packages, " -"but newer tools such as pip and virtualenv use a different model." -msgstr "" -"Usar extras para um ponto de entrada não é mais recomendado. Os consumidores " -"devem oferecer suporte para analisá-los em distribuições existentes, mas " -"podem então ignorá-los. Novas ferramentas de publicação não precisam " -"suportar especificações extras. A funcionalidade de manipulação de extras " -"estava ligada ao modelo do setuptools de gerenciamento de pacotes \"egg\", " -"mas as ferramentas mais recentes, como pip e virtualenv, usam um modelo " -"diferente." - -#: ../source/specifications/entry-points.rst:80 -msgid "File format" -msgstr "Formato de arquivo" - -#: ../source/specifications/entry-points.rst:82 -msgid "" -"Entry points are defined in a file called :file:`entry_points.txt` in the :" -"file:`*.dist-info` directory of the distribution. This is the directory " -"described in :pep:`376` for installed distributions, and in :pep:`427` for " -"wheels. The file uses the UTF-8 character encoding." -msgstr "" -"Os pontos de entrada são definidos em um arquivo chamado :file:`entry_points." -"txt` no diretório :file:`*.dist-info` da distribuição. Este é o diretório " -"descrito em :pep:`376` para distribuições instaladas e em :pep:`427` para " -"wheels. O arquivo usa a codificação de caracteres UTF-8." - -#: ../source/specifications/entry-points.rst:87 -msgid "" -"The file contents are in INI format, as read by Python's :mod:`configparser` " -"module. However, configparser treats names as case-insensitive by default, " -"whereas entry point names are case sensitive. A case-sensitive config parser " -"can be made like this::" -msgstr "" -"O conteúdo do arquivo está no formato INI, conforme lido pelo módulo " -":mod:`configparser` do Python. No entanto, o configparser trata os nomes " -"como não diferenciando maiúsculas de minúsculas por padrão, enquanto os " -"nomes de pontos de entrada diferenciam maiúsculas de minúsculas. Um " -"analisador de configuração com distinção entre maiúsculas e minúsculas pode " -"ser feito assim::" - -#: ../source/specifications/entry-points.rst:97 -msgid "" -"The entry points file must always use ``=`` to delimit names from values " -"(whereas configparser also allows using ``:``)." -msgstr "" -"O arquivo de pontos de entrada deve sempre usar ``=`` para delimitar nomes " -"de valores (enquanto o configparser também permite o uso de ``:``)." - -#: ../source/specifications/entry-points.rst:100 -msgid "" -"The sections of the config file represent entry point groups, the names are " -"names, and the values encode both the object reference and the optional " -"extras. If extras are used, they are a comma-separated list inside square " -"brackets." -msgstr "" -"As seções do arquivo de configuração representam grupos de pontos de " -"entrada, os nomes são nomes e os valores codificam a referência do objeto e " -"os extras opcionais. Se extras forem usados, eles serão uma lista separada " -"por vírgulas entre colchetes." - -#: ../source/specifications/entry-points.rst:104 -msgid "" -"Within a value, readers must accept and ignore spaces (including multiple " -"consecutive spaces) before or after the colon, between the object reference " -"and the left square bracket, between the extra names and the square brackets " -"and colons delimiting them, and after the right square bracket. The syntax " -"for extras is formally specified as part of :pep:`508` (as ``extras``). For " -"tools writing the file, it is recommended only to insert a space between the " -"object reference and the left square bracket." -msgstr "" -"Dentro de um valor, os leitores devem aceitar e ignorar os espaços (" -"incluindo vários espaços consecutivos) antes ou depois dos dois pontos, " -"entre a referência do objeto e o colchete esquerdo, entre os nomes extras e " -"os colchetes e dois pontos que os delimitam, e depois do quadrado direito " -"suporte. A sintaxe para extras é formalmente especificada como parte de " -":pep:`508` (como ``extras``). Para ferramentas de gravação de arquivo, é " -"recomendável inserir apenas um espaço entre a referência do objeto e o " -"colchete esquerdo." - -#: ../source/specifications/entry-points.rst:112 -msgid "For example::" -msgstr "Por exemplo::" - -#: ../source/specifications/entry-points.rst:124 -msgid "Use for scripts" -msgstr "Uso para scripts" - -#: ../source/specifications/entry-points.rst:126 -msgid "" -"Two groups of entry points have special significance in packaging: " -"``console_scripts`` and ``gui_scripts``. In both groups, the name of the " -"entry point should be usable as a command in a system shell after the " -"package is installed. The object reference points to a function which will " -"be called with no arguments when this command is run. The function may " -"return an integer to be used as a process exit code, and returning ``None`` " -"is equivalent to returning ``0``." -msgstr "" -"Dois grupos de pontos de entrada têm um significado especial no " -"empacotamento: ``console_scripts`` e ``gui_scripts``. Em ambos os grupos, o " -"nome do ponto de entrada deve ser usado como um comando em um shell do " -"sistema após a instalação do pacote. A referência do objeto aponta para uma " -"função que será chamada sem argumentos quando este comando for executado. A " -"função pode retornar um inteiro para ser usado como um código de saída do " -"processo, e retornar ``None`` é equivalente a retornar ``0``." - -#: ../source/specifications/entry-points.rst:134 -msgid "" -"For instance, the entry point ``mycmd = mymod:main`` would create a command " -"``mycmd`` launching a script like this::" -msgstr "" -"Por exemplo, o ponto de entrada ``mycmd = mymod:main`` criaria um comando " -"``mycmd`` lançando um script como este::" - -#: ../source/specifications/entry-points.rst:141 -msgid "" -"The difference between ``console_scripts`` and ``gui_scripts`` only affects " -"Windows systems. ``console_scripts`` are wrapped in a console executable, so " -"they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and " -"``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI " -"executable, so they can be started without a console, but cannot use " -"standard streams unless application code redirects them. Other platforms do " -"not have the same distinction." -msgstr "" -"A diferença entre ``console_scripts`` e ``gui_scripts`` afeta apenas os " -"sistemas Windows. ``console_scripts`` são empacotados em um executável de " -"console, então eles são anexados a um console e podem usar ``sys.stdin``, " -"``sys.stdout`` e ``sys.stderr`` para entrada e saída. ``gui_scripts`` são " -"empacotados em um executável GUI, então eles podem ser iniciados sem um " -"console, mas não podem usar streams padrão a menos que o código da aplicação " -"os redirecione. Outras plataformas não têm a mesma distinção." - -#: ../source/specifications/entry-points.rst:149 -msgid "" -"Install tools are expected to set up wrappers for both ``console_scripts`` " -"and ``gui_scripts`` in the scripts directory of the install scheme. They are " -"not responsible for putting this directory in the ``PATH`` environment " -"variable which defines where command-line tools are found." -msgstr "" -"Espera-se que as ferramentas de instalação configurem wrappers para " -"``console_scripts`` e ``gui_scripts`` no diretório de scripts do esquema de " -"instalação. Eles não são responsáveis por colocar este diretório na variável " -"de ambiente ``PATH`` que define onde as ferramentas de linha de comando são " -"encontradas." - -#: ../source/specifications/entry-points.rst:154 -msgid "" -"As files are created from the names, and some filesystems are case-" -"insensitive, packages should avoid using names in these groups which differ " -"only in case. The behaviour of install tools when names differ only in case " -"is undefined." -msgstr "" -"Como os arquivos são criados a partir dos nomes e alguns sistemas de " -"arquivos não fazem distinção entre maiúsculas e minúsculas, os pacotes devem " -"evitar o uso de nomes nesses grupos que diferem apenas em maiúsculas e " -"minúsculas. O comportamento das ferramentas de instalação quando os nomes " -"diferem apenas no caso de ser indefinido." - -#: ../source/specifications/index.rst:4 -msgid "PyPA specifications" -msgstr "Especificações do PyPA" - -#: ../source/specifications/index.rst:6 -msgid "" -"This is a list of currently active interoperability specifications " -"maintained by the Python Packaging Authority. The process for updating these " -"standards, and for proposing new ones, is documented on `pypa.io `__." -msgstr "" -"Esta é uma lista de especificações de interoperabilidade atualmente ativas " -"mantidas pela Python Packaging Authority. O processo de atualização desses " -"padrões e de proposição de novos está documentado em `pypa.io `__." - -#: ../source/specifications/index.rst:13 -msgid "Package Distribution Metadata" -msgstr "Metadados de distribuição de pacotes" - -#: ../source/specifications/index.rst:30 -msgid "Package Distribution File Formats" -msgstr "Formatos de arquivos de distribuição de pacotes" - -#: ../source/specifications/index.rst:40 -msgid "Package Index Interfaces" -msgstr "Interfaces de índices de pacotes" - -#: ../source/specifications/platform-compatibility-tags.rst:6 -msgid "Platform compatibility tags" -msgstr "Tags de compatibilidade de plataforma" - -#: ../source/specifications/platform-compatibility-tags.rst:8 -msgid "" -"Platform compatibility tags allow build tools to mark distributions as being " -"compatible with specific platforms, and allows installers to understand " -"which distributions are compatible with the system they are running on." -msgstr "" -"As tags de compatibilidade de plataforma permitem que ferramentas de " -"construção marquem as distribuições como sendo compatíveis com plataformas " -"específicas e permitem que os instaladores entendam quais distribuições são " -"compatíveis com o sistema em que estão executando." - -#: ../source/specifications/platform-compatibility-tags.rst:12 -msgid "" -"The platform compatibility tagging model used for the ``wheel`` distribution " -"format is defined in :pep:`425`." -msgstr "" -"O modelo de tag de compatibilidade de plataforma usado para o formato de " -"distribuição ``wheel`` é definido em :pep:`425`." - -#: ../source/specifications/platform-compatibility-tags.rst:16 -msgid "Platform tags for Windows" -msgstr "Tags de plataforma para Windows" - -#: ../source/specifications/platform-compatibility-tags.rst:18 -msgid "" -"The scheme defined in :pep:`425` covers public distribution of wheel files " -"to systems running Windows." -msgstr "" -"O esquema definido em :pep:`425` cobre a distribuição pública de arquivos " -"wheel para sistemas executando Windows." - -#: ../source/specifications/platform-compatibility-tags.rst:22 -msgid "Platform tags for macOS (Mac OS X)" -msgstr "Tags de plataforma para macOS (Mac OS X)" - -#: ../source/specifications/platform-compatibility-tags.rst:24 -msgid "" -"The scheme defined in :pep:`425` covers public distribution of wheel files " -"to systems running macOS (previously known as Mac OS X)." -msgstr "" -"O esquema definido em :pep:`425` cobre a distribuição pública de arquivos " -"wheel para sistemas que executam macOS (anteriormente conhecido como Mac OS " -"X)." - -#: ../source/specifications/platform-compatibility-tags.rst:28 -msgid "Platform tags for common Linux distributions" -msgstr "Tags de plataforma para distribuições Linux comuns" - -#: ../source/specifications/platform-compatibility-tags.rst:32 -msgid "" -"The scheme defined in :pep:`425` is insufficient for public distribution of " -"wheel files (and \\*nix wheel files in general) to Linux platforms, due to " -"the large ecosystem of Linux platforms and subtle differences between them." -msgstr "" -"O esquema definido em :pep:`425` é insuficiente para distribuição pública de " -"arquivos wheel (e arquivos wheel do \\*nix em geral) para plataformas Linux, " -"devido ao grande ecossistema de plataformas Linux e diferenças sutis entre " -"elas." - -#: ../source/specifications/platform-compatibility-tags.rst:36 -msgid "" -"Instead, :pep:`600` defines the ``manylinux`` standard, which represents a " -"common subset of Linux platforms, and allows building wheels tagged with the " -"``manylinux`` platform tag which can be used across most common Linux " -"distributions." -msgstr "" -"Em vez disso, a :pep:`600` define o padrão ``manylinux``, que representa um " -"subconjunto comum de plataformas Linux, e permite a construção de wheels com " -"a tag de plataforma ``manylinux`` que pode ser usada na maioria das " -"distribuições Linux." - -#: ../source/specifications/platform-compatibility-tags.rst:41 -msgid "" -"There were multiple iterations of the ``manylinux`` specification, each " -"representing the common subset of Linux platforms at a given point in time:" -msgstr "" -"Houve várias iterações da especificação ``manylinux``, cada uma " -"representando o subconjunto comum de plataformas Linux em um determinado " -"ponto no tempo:" - -#: ../source/specifications/platform-compatibility-tags.rst:44 -msgid "" -"``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, " -"and is based on a compatible Linux platform from 2007." -msgstr "" -"``manylinux1`` (:pep:`513`) oferece suporte às arquiteturas ``x86_64`` e " -"``i686`` e é baseado em uma plataforma Linux compatível de 2007." - -#: ../source/specifications/platform-compatibility-tags.rst:46 -msgid "" -"``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` " -"architectures. and updates the previous specification to be based on a " -"compatible Linux platform from 2010 instead." -msgstr "" -"``manylinux2010`` (:pep:`571`) oferece suporte às arquiteturas ``x86_64`` e " -"``i686`` e atualiza a especificação anterior para se basear em uma " -"plataforma Linux compatível a partir de 2010." - -#: ../source/specifications/platform-compatibility-tags.rst:49 -msgid "" -"``manylinux2014`` (:pep:`599`) adds support for a number of additional " -"architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and " -"``s390x``) and updates the base platform to a compatible Linux platform from " -"2014." -msgstr "" -"``manylinux2014`` (:pep:`599`) adiciona suporte para várias arquiteturas " -"adicionais (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le`` e ``s390x``) e " -"atualiza a plataforma base para uma plataforma Linux compatível de 2014." - -#: ../source/specifications/platform-compatibility-tags.rst:54 -msgid "" -"``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a " -"future-proof standard. It defines ``x`` and ``y`` as glibc major an minor " -"versions supported (e.g. ``manylinux_2_24`` should work on any distro using " -"glibc 2.24+). Previous tags are still supported for backward compatibility." -msgstr "" -"``manylinux_x_y`` (:pep:`600`) substitui todas as PEPs anteriores para " -"definir um padrão à prova de futuro. Ele define ``x`` e ``y`` como as " -"versões principais e secundárias do glibc suportadas (por exemplo, " -"``manylinux_2_24`` deve funcionar em qualquer distro usando glibc 2.24+). " -"Tags anteriores ainda são suportadas para compatibilidade com versões " -"anteriores." - -#: ../source/specifications/platform-compatibility-tags.rst:59 -msgid "" -"In general, distributions built for older versions of the specification are " -"forwards-compatible (meaning that ``manylinux1`` distributions should " -"continue to work on modern systems) but not backwards-compatible (meaning " -"that ``manylinux2010`` distributions are not expected to work on platforms " -"that existed before 2010)." -msgstr "" -"Em geral, as distribuições construídas para versões mais antigas da " -"especificação são compatíveis com versões futuras (o que significa que as " -"distribuições ``manylinux1`` devem continuar a funcionar em sistemas " -"modernos), mas não compatíveis com versões anteriores (significando que " -"distribuições ``manylinux2010`` não devem trabalhar em plataformas que " -"existiam antes de 2010)." - -#: ../source/specifications/platform-compatibility-tags.rst:65 -msgid "" -"Package maintainers should attempt to target the most compatible " -"specification possible, with the caveat that the provided build environment " -"for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning " -"that these images will no longer receive security updates." -msgstr "" -"Os mantenedores do pacote devem tentar atingir a especificação mais " -"compatível possível, com a ressalva de que o ambiente de compilação " -"fornecido para ``manylinux1`` e ``manylinux2010`` atingiu o fim da vida, o " -"que significa que essas imagens não receberão mais atualizações de segurança." - -#: ../source/specifications/platform-compatibility-tags.rst:71 -msgid "Manylinux compatibility support" -msgstr "Suporte a compatibilidade de manylinux" - -#: ../source/specifications/platform-compatibility-tags.rst:74 -msgid "" -"The ``manylinux2014`` specification is relatively new and is not yet widely " -"recognised by install tools." -msgstr "" -"A especificação de ``manylinux2014`` é relativamente nova e ainda não é " -"amplamente reconhecida pelas ferramentas de instalação." - -#: ../source/specifications/platform-compatibility-tags.rst:76 -msgid "" -"The ``manylinux_x_y`` specification is relatively new and is not yet widely " -"recognised by install tools." -msgstr "" -"A especificação de ``manylinux_x_y`` é relativamente nova e não é amplamente " -"reconhecida pelas ferramentas de instalação." - -#: ../source/specifications/platform-compatibility-tags.rst:79 -msgid "" -"The following table shows the minimum versions of relevant projects to " -"support the various ``manylinux`` standards:" -msgstr "" -"A tabela a seguir mostra as versões mínimas de projetos relevantes para " -"oferecer suporte aos vários padrões ``manylinux``:" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "Tool" -msgstr "Ferramenta" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux1``" -msgstr "``manylinux1``" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2010``" -msgstr "``manylinux2010``" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2014``" -msgstr "``manylinux2014``" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux_x_y``" -msgstr "``manylinux_x_y``" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=8.1.0``" -msgstr "``>=8.1.0``" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.0``" -msgstr "``>=19.0``" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.3``" -msgstr "``>=19.3``" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=20.3``" -msgstr "``>=20.3``" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "auditwheel" -msgstr "auditwheel" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=1.0.0``" -msgstr "``>=1.0.0``" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=2.0.0``" -msgstr "``>=2.0.0``" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.0.0``" -msgstr "``>=3.0.0``" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.3.0`` [#]_" -msgstr "``>=3.3.0`` [#]_" - -#: ../source/specifications/platform-compatibility-tags.rst:90 -msgid "Platform tags for other \\*nix platforms" -msgstr "Tags de plataforma para outras plataformas \\*nix" - -#: ../source/specifications/platform-compatibility-tags.rst:92 -msgid "" -"The scheme defined in :pep:`425` is not generally sufficient for public " -"distribution of wheel files to other \\*nix platforms. Efforts are currently " -"(albeit intermittently) under way to define improved compatibility tagging " -"schemes for AIX and for Alpine Linux." -msgstr "" -"O esquema definido na :pep:`425` geralmente não é suficiente para a " -"distribuição pública de arquivos wheel para outras plataformas \\*nix. " -"Esforços estão atualmente (embora de forma intermitente) em andamento para " -"definir esquemas de marcação de compatibilidade aprimorados para AIX e " -"Alpine Linux." - -#: ../source/specifications/platform-compatibility-tags.rst:98 -msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" -msgstr "" -"Suporte somente para ``manylinux_2_24`` foi adicionado em auditwheel 3.3.0" - -#: ../source/specifications/pypirc.rst:6 -msgid "The :file:`.pypirc` file" -msgstr "O arquivo :file:`.pypirc`" - -#: ../source/specifications/pypirc.rst:8 -msgid "" -"A :file:`.pypirc` file allows you to define the configuration for :term:" -"`package indexes ` (referred to here as \"repositories\"), so " -"that you don't have to enter the URL, username, or password whenever you " -"upload a package with :ref:`twine` or :ref:`flit`." -msgstr "" -"Um arquivo :file:`.pypirc` permite que você defina a configuração para " -":term:`índices de pacotes <Índice de Pacotes>` (referido aqui como " -"\"repositórios\"), para que você não precise inserir a URL, nome de usuário " -"ou senha sempre que você enviar um pacote com :ref:`twine` ou :ref:`flit`." - -#: ../source/specifications/pypirc.rst:13 -msgid "The format (originally defined by the :ref:`distutils` package) is:" -msgstr "O formato (originalmente definido pelo pacote :ref:`distutils`) é:" - -#: ../source/specifications/pypirc.rst:32 -msgid "" -"The ``distutils`` section defines an ``index-servers`` field that lists the " -"name of all sections describing a repository." -msgstr "" -"A seção ``distutils`` define um campo ``index-servers`` que lista o nome de " -"todas as seções descrevendo um repositório." - -#: ../source/specifications/pypirc.rst:35 -msgid "Each section describing a repository defines three fields:" -msgstr "Cada seção descrevendo um repositório define três campos:" - -#: ../source/specifications/pypirc.rst:37 -msgid "``repository``: The URL of the repository." -msgstr "``repository``: A URL do repositório." - -#: ../source/specifications/pypirc.rst:38 -msgid "``username``: The registered username on the repository." -msgstr "``username``: O nome de usuário registrado no repositório." - -#: ../source/specifications/pypirc.rst:39 -msgid "``password``: The password that will used to authenticate the username." -msgstr "``password``: A senha que será usada para autenticar o nome de usuário." - -#: ../source/specifications/pypirc.rst:43 -msgid "" -"Be aware that this stores your password in plain text. For better security, " -"consider an alternative like `keyring`_, setting environment variables, or " -"providing the password on the command line." -msgstr "" -"Esteja ciente de que isso armazena sua senha em texto simples. Para melhor " -"segurança, considere uma alternativa como `chaveiro `_, " -"configurando variáveis de ambiente ou fornecendo a senha na linha de comando." - -#: ../source/specifications/pypirc.rst:47 -msgid "" -"Otherwise, set the permissions on :file:`.pypirc` so that only you can view " -"or modify it. For example, on Linux or macOS, run:" -msgstr "" -"Caso contrário, defina as permissões em :file:`.pypirc` para que somente " -"você possa ver ou modificá-lo. Por exemplo, no Linux ou macOS, execute:" - -#: ../source/specifications/pypirc.rst:57 -msgid "Common configurations" -msgstr "Configurações comuns" - -#: ../source/specifications/pypirc.rst:61 -msgid "" -"These examples apply to :ref:`twine`, and projects like :ref:`hatch` that " -"use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`." -"pypirc`, but with different defaults. Please refer to each project's " -"documentation for more details and usage instructions." -msgstr "" -"Esses exemplos se aplicam a :ref:`twine` e projetos como :ref:`hatch` que o " -"usam sob o capô. Outros projetos (por exemplo, :ref:`flit`) também usam " -":file:`.pypirc`, mas com padrões diferentes. Consulte a documentação de cada " -"projeto para obter mais detalhes e instruções de uso." - -#: ../source/specifications/pypirc.rst:66 -msgid "" -"Twine's default configuration mimics a :file:`.pypirc` with repository " -"sections for PyPI and TestPyPI:" -msgstr "" -"A configuração padrão do Twine imita um :file:`.pypirc` com seções de " -"repositório para PyPI e TestPyPI:" - -#: ../source/specifications/pypirc.rst:82 -msgid "" -"Twine will add additional configuration from :file:`$HOME/.pypirc`, the " -"command line, and environment variables to this default configuration." -msgstr "" -"Twine irá adicionar configuração adicional de :file:`$HOME/.pypirc`, a linha " -"de comando e variáveis de ambiente a esta configuração padrão." - -#: ../source/specifications/pypirc.rst:86 -msgid "Using a PyPI token" -msgstr "Usando um token do PyPI" - -#: ../source/specifications/pypirc.rst:88 -msgid "" -"To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` " -"similar to:" -msgstr "" -"Para definir seu `token de API `_ para PyPI, você pode criar um " -":file:`$HOME/.pypirc` semelhante a:" - -#: ../source/specifications/pypirc.rst:97 -msgid "" -"For :ref:`TestPyPI `, add a ``[testpypi]`` section, using " -"the API token from your TestPyPI account." -msgstr "" -"Para o :ref:`TestPyPI `, adicione a seção ``[testpypi]``, " -"usando o token de API de sua conta do TestPyPI." - -#: ../source/specifications/pypirc.rst:103 -msgid "Using another package index" -msgstr "Usando outro índice de pacotes" - -#: ../source/specifications/pypirc.rst:105 -msgid "" -"To configure an additional repository, you'll need to redefine the ``index-" -"servers`` field to include the repository name. Here is a complete example " -"of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" -msgstr "" -"Para configurar um repositório adicional, você precisará redefinir o campo " -"``index-servers`` para incluir o nome do repositório. Aqui está um exemplo " -"completo de um :file:`$HOME/.pypirc` para PyPI, TestPyPI e um repositório " -"privado:" - -#: ../source/specifications/pypirc.rst:132 -msgid "" -"Instead of using the ``password`` field, consider saving your API tokens and " -"passwords securely using `keyring`_ (which is installed by Twine):" -msgstr "" -"Em vez de usar o campo ``password``, considere salvar seus tokens de API e " -"senhas com segurança usando um `chaveiro `_ (que é instalado pelo " -"Twine):" - -#: ../source/specifications/recording-installed-packages.rst:5 -msgid "Recording installed projects" -msgstr "Gravando projetos instalados" - -#: ../source/specifications/recording-installed-packages.rst:7 -msgid "" -"This document specifies a common format of recording information about " -"Python :term:`projects ` installed in an environment. A common " -"metadata format allows tools to query, manage or uninstall projects, " -"regardless of how they were installed." -msgstr "" -"Este documento especifica um formato comum de gravação de informações sobre " -":term:`projetos ` Python instalados em um ambiente. Um formato de " -"metadados comum permite que as ferramentas consultem, gerenciem ou " -"desinstalem projetos, independentemente de como foram instalados." - -#: ../source/specifications/recording-installed-packages.rst:12 -msgid "" -"Almost all information is optional. This allows tools outside the Python " -"ecosystem, such as Linux package managers, to integrate with Python tooling " -"as much as possible. For example, even if an installer cannot easily provide " -"a list of installed files in a format specific to Python tooling, it should " -"still record the name and version of the installed project." -msgstr "" -"Quase todas as informações são opcionais. Isso permite que ferramentas fora " -"do ecossistema Python, como gerenciadores de pacotes Linux, se integrem com " -"as ferramentas Python tanto quanto possível. Por exemplo, mesmo se um " -"instalador não puder fornecer facilmente uma lista de arquivos instalados em " -"um formato específico para as ferramentas Python, ele ainda deve registrar o " -"nome e a versão do projeto instalado." - -#: ../source/specifications/recording-installed-packages.rst:21 -msgid "History and change workflow" -msgstr "Histórico e fluxo de trabalho de mudança" - -#: ../source/specifications/recording-installed-packages.rst:23 -msgid "" -"The metadata described here was first specified in :pep:`376`, and later " -"amended in :pep:`627`. It was formerly known as *Database of Installed " -"Python Distributions*. Further amendments (except trivial language or " -"typography fixes) must be made through the PEP process (see :pep:`1`)." -msgstr "" -"Os metadados descritos aqui foram especificados primeiro na :pep:`376`, e " -"posteriormente alterados na :pep:`627`. Era conhecido anteriormente como *" -"Banco de dados de distribuições Python instaladas*. Outras alterações (" -"exceto correções triviais de linguagem ou tipografia) devem ser feitas " -"através do processo de PEP (veja :pep:`1`)." - -#: ../source/specifications/recording-installed-packages.rst:29 -msgid "" -"While this document is the normative specification, these PEPs that " -"introduce changes to it may include additional information such as " -"rationales and backwards compatibility considerations." -msgstr "" -"Embora este documento seja a especificação normativa, essas PEPs que " -"introduzem alterações nele podem incluir informações adicionais, como " -"justificativas e considerações de compatibilidade com versões anteriores." - -#: ../source/specifications/recording-installed-packages.rst:37 -msgid "" -"Each project installed from a distribution must, in addition to files, " -"install a \"``.dist-info``\" directory located alongside importable modules " -"and packages (commonly, the ``site-packages`` directory)." -msgstr "" -"Cada projeto instalado de uma distribuição deve, além dos arquivos, instalar " -"um diretório \"``.dist-info``\" localizado junto com os módulos e pacotes " -"importáveis (comumente, o diretório ``site-packages``)." - -#: ../source/specifications/recording-installed-packages.rst:41 -msgid "" -"This directory is named as ``{name}-{version}.dist-info``, with ``name`` and " -"``version`` fields corresponding to :ref:`core-metadata`. Both fields must " -"be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 " -"<440#normalization>` for the definition of normalization for each field " -"respectively), and replace dash (``-``) characters with underscore (``_``) " -"chacaters, so the ``.dist-info`` directory always has exactly one dash (``-" -"``) character in its stem, separating the ``name`` and ``version`` fields." -msgstr "" -"Este diretório é nomeado como ``{name}-{version}.dist-info``, com os campos " -"``name`` e ``version`` correspondendo a :ref:`core-metadata`. Ambos os " -"campos devem ser normalizados (consulte a :pep:`PEP 503 <503#normalized-" -"names>` e a :pep:`PEP 440 <440#normalization>` para a definição de " -"normalização para cada campo respectivamente) e substitua os caracteres de " -"traço (``-``) por caracteres de sublinhado (``_``), então o diretório " -"``.dist-info`` sempre tem exatamente um caractere de traço (``-``) em seu " -"radical, separando os campos ``name`` e ``version``." - -#: ../source/specifications/recording-installed-packages.rst:50 -msgid "" -"Historically, tools have failed to replace dot characters or normalize case " -"in the ``name`` field, or not perform normalization in the ``version`` " -"field. Tools consuming ``.dist-info`` directories should expect those fields " -"to be unnormalized, and treat them as equivalent to their normalized " -"counterparts. New tools that write ``.dist-info`` directories MUST normalize " -"both ``name`` and ``version`` fields using the rules described above, and " -"existing tools are encouraged to start normalizing those fields." -msgstr "" -"Historicamente, as ferramentas falharam em substituir caracteres de ponto ou " -"normalizar maiúsculas e minúsculas no campo ``name``, ou não realizar a " -"normalização no campo ``version``. Ferramentas que consomem diretórios " -"``.dist-info`` devem esperar que esses campos sejam desnormalizados e tratá-" -"los como equivalentes a suas contrapartes normalizadas. Novas ferramentas " -"que escrevem diretórios ``.dist-info`` DEVEM normalizar ambos os campos " -"``name`` e ``version`` usando as regras descritas acima, e as ferramentas " -"existentes são encorajadas a começar a normalizar esses campos." - -#: ../source/specifications/recording-installed-packages.rst:60 -msgid "" -"The ``.dist-info`` directory's name is formatted to unambigiously represent " -"a distribution as a filesystem path. Tools presenting a distribution name to " -"a user should avoid using the normalized name, and instead present the " -"specified name (when needed prior to resolution to an installed package), or " -"read the respective fields in Core Metadata, since values listed there are " -"unescaped and accurately reflect the distribution. Libraries should provide " -"API for such tools to consume, so tools can have access to the unnormalized " -"name when displaying distrubution information." -msgstr "" -"O nome do diretório ``.dist-info`` é formatado para representar " -"inequivocamente uma distribuição como um caminho do sistema de arquivos. As " -"ferramentas que apresentam um nome de distribuição a um usuário devem evitar " -"o uso do nome normalizado e, em vez disso, apresentar o nome especificado (" -"quando necessário antes da resolução de um pacote instalado) ou ler os " -"respectivos campos nos metadados principais, uma vez que os valores listados " -"não têm escape e são precisos refletem a distribuição. As bibliotecas devem " -"fornecer API para o consumo dessas ferramentas, de forma que as ferramentas " -"possam ter acesso ao nome não normalizado ao exibir informações de " -"distribuição." - -#: ../source/specifications/recording-installed-packages.rst:69 -msgid "" -"This ``.dist-info`` directory can contain these files, described in detail " -"below:" -msgstr "" -"Este diretório ``.dist-info`` pode conter esses arquivos, descritos em " -"detalhes abaixo:" - -#: ../source/specifications/recording-installed-packages.rst:72 -msgid "``METADATA``: contains project metadata" -msgstr "``METADATA``: contém metadados do projeto" - -#: ../source/specifications/recording-installed-packages.rst:73 -msgid "``RECORD``: records the list of installed files." -msgstr "``RECORD``: registra a lista de arquivos instalados." - -#: ../source/specifications/recording-installed-packages.rst:74 -msgid "" -"``INSTALLER``: records the name of the tool used to install the project." -msgstr "" -"``INSTALLER``: registra o nome da ferramenta usada para instalar o projeto." - -#: ../source/specifications/recording-installed-packages.rst:76 -msgid "" -"The ``METADATA`` file is mandatory. All other files may be omitted at the " -"installing tool's discretion. Additional installer-specific files may be " -"present." -msgstr "" -"O arquivo ``METADATA`` é obrigatório. Todos os outros arquivos podem ser " -"omitidos a critério da ferramenta de instalação. Arquivos adicionais " -"específicos do instalador podem estar presentes." - -#: ../source/specifications/recording-installed-packages.rst:82 -msgid "" -"The :ref:`binary-distribution-format` specification describes additional " -"files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. " -"Such files may be copied to the ``.dist-info`` directory of an installed " -"project." -msgstr "" -"A especificação :ref:`binary-distribution-format` descreve arquivos " -"adicionais que podem aparecer no diretório ``.dist-info`` de um :term:`Wheel`" -". Esses arquivos podem ser copiados para o diretório ``.dist-info`` de um " -"projeto instalado." - -#: ../source/specifications/recording-installed-packages.rst:87 -msgid "" -"The previous versions of this specification also specified a ``REQUESTED`` " -"file. This file is now considered a tool-specific extension, but may be " -"standardized again in the future. See `PEP 376 `_ for its original meaning." -msgstr "" -"As versões anteriores desta especificação também especificavam um arquivo " -"``REQUESTED``. Este arquivo agora é considerado uma extensão específica da " -"ferramenta, mas pode ser padronizado novamente no futuro. Consulte `PEP 376 " -"`_ para seu significado " -"original." - -#: ../source/specifications/recording-installed-packages.rst:94 -msgid "The METADATA file" -msgstr "O arquivo METADATA" - -#: ../source/specifications/recording-installed-packages.rst:96 -msgid "" -"The ``METADATA`` file contains metadata as described in the :ref:`core-" -"metadata` specification, version 1.1 or greater." -msgstr "" -"O arquivo ``METADATA`` contém metadados conforme descrito na especificação " -":ref:`core-metadata`, versão 1.1 ou superior." - -#: ../source/specifications/recording-installed-packages.rst:99 -msgid "" -"The ``METADATA`` file is mandatory. If it cannot be created, or if required " -"core metadata is not available, installers must report an error and fail to " -"install the project." -msgstr "" -"O arquivo ``METADATA`` é obrigatório. Se não puder ser criado ou se os " -"metadados principais necessários não estiverem disponíveis, os instaladores " -"devem relatar um erro e falhar ao instalar o projeto." - -#: ../source/specifications/recording-installed-packages.rst:105 -msgid "The RECORD file" -msgstr "O arquivo RECORD" - -#: ../source/specifications/recording-installed-packages.rst:107 -msgid "" -"The ``RECORD`` file holds the list of installed files. It is a CSV file " -"containing one record (line) per installed file." -msgstr "" -"O arquivo ``RECORD`` contém a lista de arquivos instalados. É um arquivo CSV " -"contendo um registro (linha) por arquivo instalado." - -#: ../source/specifications/recording-installed-packages.rst:110 -msgid "" -"The CSV dialect must be readable with the default ``reader`` of Python's " -"``csv`` module:" -msgstr "" -"O dialeto CSV deve ser legível com o ``reader`` padrão do módulo ``csv`` do " -"Python:" - -#: ../source/specifications/recording-installed-packages.rst:113 -msgid "field delimiter: ``,`` (comma)," -msgstr "delimitador de campo: ``,`` (vírgula)," - -#: ../source/specifications/recording-installed-packages.rst:114 -msgid "quoting char: ``\"`` (straight double quote)," -msgstr "caractere de aspas: ``\"`` (aspas duplas)," - -#: ../source/specifications/recording-installed-packages.rst:115 -msgid "line terminator: either ``\\r\\n`` or ``\\n``." -msgstr "" -"terminador de linha: ``\\r\\n" -"`` ou ``\\n" -"``." - -#: ../source/specifications/recording-installed-packages.rst:117 -msgid "" -"Each record is composed of three elements: the file's **path**, the **hash** " -"of the contents, and its **size**." -msgstr "" -"Cada registro é composto de três elementos: o **caminho** do arquivo, o " -"**hash** do conteúdo e seu **tamanho**." - -#: ../source/specifications/recording-installed-packages.rst:120 -msgid "" -"The *path* may be either absolute, or relative to the directory containing " -"the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On " -"Windows, directories may be separated either by forward- or backslashes (``/" -"`` or ``\\``)." -msgstr "" -"O *caminho* pode ser absoluto ou relativo ao diretório que contém o " -"diretório ``.dist-info`` (comumente, o diretório ``site-packages``). No " -"Windows, os diretórios podem ser separados por barras ou barras invertidas " -"(``/`` ou ``\\``)." - -#: ../source/specifications/recording-installed-packages.rst:125 -msgid "" -"The *hash* is either an empty string or the name of a hash algorithm from " -"``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` " -"and the digest of the file's contents, encoded with the urlsafe-base64-nopad " -"encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." -msgstr "" -"O *hash* é uma string vazia ou o nome de um algoritmo hash de ``hashlib." -"algorithms_guaranteed``, seguido pelo caractere igual ``=`` e o resumo do " -"conteúdo do arquivo, codificado com a codificação urlsafe-base64-nopad " -"(``base64.urlsafe_b64encode(digest)`` com ``=`` ao final removido)." - -#: ../source/specifications/recording-installed-packages.rst:130 -msgid "" -"The *size* is either the empty string, or file's size in bytes, as a base 10 " -"integer." -msgstr "" -"O *tamanho* é a string vazia ou o tamanho do arquivo em bytes, como um " -"inteiro de base 10." - -#: ../source/specifications/recording-installed-packages.rst:133 -msgid "" -"For any file, either or both of the *hash* and *size* fields may be left " -"empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself " -"have empty *hash* and *size*. For other files, leaving the information out " -"is discouraged, as it prevents verifying the integrity of the installed " -"project." -msgstr "" -"Para qualquer arquivo, um ou ambos os campos de *hash* e *tamanho* podem ser " -"deixados em branco. Normalmente, entradas para arquivos ``.pyc`` e o próprio " -"arquivo ``RECORD`` têm *hash* e *tamanho* vazios. Para os demais arquivos, " -"não é recomendável deixar as informações de fora, pois impede a verificação " -"da integridade do projeto instalado." - -#: ../source/specifications/recording-installed-packages.rst:139 -msgid "" -"If the ``RECORD`` file is present, it must list all installed files of the " -"project, except ``.pyc`` files corresponding to ``.py`` files listed in " -"``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` " -"directory (including the ``RECORD`` file itself) must be listed. Directories " -"should not be listed." -msgstr "" -"Se o arquivo ``RECORD`` estiver presente, ele deve listar todos os arquivos " -"instalados do projeto, exceto os arquivos ``.pyc`` correspondentes aos " -"arquivos ``.py`` listados em ``RECORD``, que são opcionais. Notavelmente, o " -"conteúdo do diretório ``.dist-info`` (incluindo o próprio arquivo ``RECORD``)" -" deve ser listado. Os diretórios não devem ser listados." - -#: ../source/specifications/recording-installed-packages.rst:146 -msgid "" -"To completely uninstall a package, a tool needs to remove all files listed " -"in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding " -"to removed ``.py`` files, and any directories emptied by the uninstallation." -msgstr "" -"Para desinstalar completamente um pacote, uma ferramenta precisa remover " -"todos os arquivos listados em ``RECORD``, todos os arquivos ``.pyc`` (de " -"todos os níveis de otimização) correspondentes aos arquivos ``.py`` " -"removidos e quaisquer diretórios esvaziados pela desinstalação." - -#: ../source/specifications/recording-installed-packages.rst:151 -msgid "Here is an example snippet of a possible ``RECORD`` file::" -msgstr "Aqui está um trecho de exemplo de um possível arquivo ``RECORD``::" - -#: ../source/specifications/recording-installed-packages.rst:170 -msgid "" -"If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must " -"not atempt to uninstall or upgrade the package. (This does not apply to " -"tools that rely on other sources of information, such as system package " -"managers in Linux distros.)" -msgstr "" -"Se o arquivo ``RECORD`` estiver faltando, as ferramentas que dependem de " -"``.dist-info`` não devem tentar desinstalar ou atualizar o pacote. (Isso não " -"se aplica a ferramentas que dependem de outras fontes de informação, como " -"gerenciadores de pacotes do sistema em distros Linux.)" - -#: ../source/specifications/recording-installed-packages.rst:177 -msgid "The INSTALLER file" -msgstr "O arquivo INSTALLER" - -#: ../source/specifications/recording-installed-packages.rst:179 -msgid "" -"If present, ``INSTALLER`` is a single-line text file naming the tool used to " -"install the project. If the installer is executable from the command line, " -"``INSTALLER`` should contain the command name. Otherwise, it should contain " -"a printable ASCII string." -msgstr "" -"Se presente, ``INSTALLER`` é um arquivo de texto de uma linha que nomeia a " -"ferramenta usada para instalar o projeto. Se o instalador for executável a " -"partir da linha de comando, ``INSTALLER`` deve conter o nome do comando. " -"Caso contrário, deve conter uma string ASCII imprimível." - -#: ../source/specifications/recording-installed-packages.rst:185 -msgid "The file can be terminated by zero or more ASCII whitespace characters." -msgstr "" -"O arquivo pode ser encerrado com zero ou mais caracteres de espaço em branco " -"ASCII." - -#: ../source/specifications/recording-installed-packages.rst:187 -msgid "Here are examples of two possible ``INSTALLER`` files::" -msgstr "Aqui estão exemplos de dois possíveis arquivos ``INSTALLER``::" - -#: ../source/specifications/recording-installed-packages.rst:195 -msgid "" -"This value should be used for informational purposes only. For example, if a " -"tool is asked to uninstall a project but finds no ``RECORD`` file, it may " -"suggest that the tool named in ``INSTALLER`` may be able to do the " -"uninstallation." -msgstr "" -"Este valor deve ser usado apenas para fins informativos. Por exemplo, se uma " -"ferramenta é solicitada a desinstalar um projeto, mas não encontra o arquivo " -"``RECORD``, pode sugerir que a ferramenta nomeada em ``INSTALLER`` pode ser " -"capaz de fazer a desinstalação." - -#: ../source/specifications/recording-installed-packages.rst:201 -msgid "The direct_url.json file" -msgstr "O arquivo direct_url.json" - -#: ../source/specifications/recording-installed-packages.rst:203 -msgid "" -"This file MUST be created by installers when installing a distribution from " -"a requirement specifying a direct URL reference (including a VCS URL)." -msgstr "" -"Este arquivo DEVE ser criado por instaladores ao instalar uma distribuição a " -"partir de um requisito que especifica uma referência de URL direta (" -"incluindo uma URL de VCS)." - -#: ../source/specifications/recording-installed-packages.rst:209 -msgid "Its detailed specification is at :ref:`direct-url`." -msgstr "Sua especificação detalhada está em :ref:`direct-url`." - -#: ../source/specifications/simple-repository-api.rst:6 -msgid "Simple repository API" -msgstr "API simples de repositório" - -#: ../source/specifications/simple-repository-api.rst:8 -msgid "" -"The current interface for querying available package versions and retrieving " -"packages from an index server is defined in :pep:`503`, with the addition of " -"\"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` " -"and specifying the interface version provided by an index server in :pep:" -"`629`." -msgstr "" -"A interface atual para consultar versões de pacotes disponíveis e recuperar " -"pacotes de um servidor de indexação é definida em :pep:`503`, com a adição " -"de suporte a retirada ou \"yank\" (que permite um tipo de exclusão de " -"arquivo) conforme definido em :pep:`592` e especificando a versão da " -"interface fornecida por um servidor de indexação em :pep:`629`." - -#: ../source/specifications/source-distribution-format.rst:6 -msgid "Source distribution format" -msgstr "Formato de distribuição fonte" - -#: ../source/specifications/source-distribution-format.rst:8 -msgid "" -"The current standard format of source distribution format is identified by " -"the presence of a :file:`pyproject.toml` file in the distribution archive. " -"The layout of such a distribution was originally specified in :pep:`517` and " -"is formally documented here." -msgstr "" -"O formato padrão atual do formato de distribuição fonte é identificado pela " -"presença de um arquivo :file:`pyproject.toml` no arquivo de distribuição. O " -"layout de tal distribuição foi originalmente especificado na :pep:`517` e " -"está formalmente documentado aqui." - -#: ../source/specifications/source-distribution-format.rst:13 -msgid "" -"There is also the legacy source distribution format, implicitly defined by " -"the behaviour of ``distutils`` module in the standard library, when " -"executing :command:`setup.py sdist`. This document does not attempt to " -"standardise this format, except to note that if a legacy source distribution " -"contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it " -"MUST follow the rules applicable to source distributions defined in the " -"metadata specification." -msgstr "" -"Existe também o formato de distribuição fonte legado, implicitamente " -"definido pelo comportamento do módulo ``distutils`` na biblioteca padrão, ao " -"executar :command:`setup.py sdist`. Este documento não tenta padronizar este " -"formato, exceto para observar que se uma distribuição de fonte legada contém " -"um arquivo ``PKG-INFO`` usando metadados versão 2.2 ou posterior, então ela " -"DEVE seguir as regras aplicáveis às distribuições de fonte definidas nos " -"metadados especificação." - -#: ../source/specifications/source-distribution-format.rst:21 -msgid "Source distributions are also known as *sdists* for short." -msgstr "Distribuições fonte também são conhecidas pela abreviação *sdists*." - -#: ../source/specifications/source-distribution-format.rst:24 -msgid "Source distribution file name" -msgstr "Nome de arquivo da distribuição fonte" - -#: ../source/specifications/source-distribution-format.rst:26 -msgid "" -"The file name of a sdist is not currently standardised, although the *de " -"facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the " -"canonicalized form of the project name (see :pep:`503` for the " -"canonicalization rules) with ``-`` characters replaced with ``_``, and " -"``{version}`` is the project version." -msgstr "" -"O nome do arquivo de um sdist não está padronizado atualmente, embora a " -"forma *de fato* seja ``{name}-{version}.tar.gz``, onde ``{name}`` é a forma " -"canônica do nome do projeto (veja :pep:`503` para as regras de canonização) " -"com caracteres ``-`` substituídos por ``_`` e ``{version}`` é a versão do " -"projeto." - -#: ../source/specifications/source-distribution-format.rst:31 -msgid "" -"The name and version components of the filename MUST match the values stored " -"in the metadata contained in the file." -msgstr "" -"O nome e os componentes da versão do nome do arquivo DEVEM corresponder aos " -"valores armazenados nos metadados contidos no arquivo." - -#: ../source/specifications/source-distribution-format.rst:35 -msgid "Source distribution file format" -msgstr "Formato de arquivo de distribuição fonte" - -#: ../source/specifications/source-distribution-format.rst:37 -msgid "" -"A ``.tar.gz`` source distribution (sdist) contains a single top-level " -"directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the " -"source files of the package. The name and version MUST match the metadata " -"stored in the file. This directory must also contain a :file:`pyproject." -"toml` in the format defined in :ref:`declaring-build-dependencies`, and a " -"``PKG-INFO`` file containing metadata in the format described in the :ref:" -"`core-metadata` specification. The metadata MUST conform to at least version " -"2.2 of the metadata specification." -msgstr "" -"Uma distribuição fonte ``.tar.gz`` (sdist) contém um único diretório de " -"nível superior chamado ``{name}-{version}`` (por exemplo, ``foo-1.0``), " -"contendo os arquivos fonte do pacote. O nome e a versão DEVEM corresponder " -"aos metadados armazenados no arquivo. Este diretório também deve conter um " -":file:`pyproject.toml` no formato definido em :ref:`declaring-build-" -"dependencies` e um arquivo ``PKG-INFO`` contendo metadados no formato " -"descrito na especificação :ref:`core-metadata`. Os metadados DEVEM estar em " -"conformidade com pelo menos a versão 2.2 da especificação de metadados." - -#: ../source/specifications/source-distribution-format.rst:45 -msgid "" -"No other content of a sdist is required or defined. Build systems can store " -"whatever information they need in the sdist to build the project." -msgstr "" -"Nenhum outro conteúdo de um sdist é necessário ou definido. Os sistemas de " -"construção podem armazenar qualquer informação necessária no sdist para " -"construir o projeto." - -#: ../source/specifications/source-distribution-format.rst:48 -msgid "" -"The tarball should use the modern POSIX.1-2001 pax tar format, which " -"specifies UTF-8 based file names." -msgstr "" -"O tarball deve usar o formato tar pax POSIX.1-2001 moderno, que especifica " -"nomes de arquivo baseados em UTF-8." - -#: ../source/specifications/version-specifiers.rst:6 -msgid "Version specifiers" -msgstr "Especificadores de versão" - -#: ../source/specifications/version-specifiers.rst:8 -msgid "" -"Version numbering requirements and the semantics for specifying comparisons " -"between versions are defined in :pep:`440`." -msgstr "" -"Os requisitos de numeração de versão e a semântica para especificar " -"comparações entre as versões são definidos na :pep:`440`." - -#: ../source/specifications/version-specifiers.rst:11 -msgid "" -"The version specifiers section in this PEP supersedes the version specifiers " -"section in :pep:`345`." -msgstr "" -"A seção de especificadores de versão nesta PEP substitui a seção de " -"especificadores de versão na :pep:`345`." - -#: ../source/support.rst:3 -msgid "How to Get Support" -msgstr "Como obter suporte" - -#: ../source/support.rst:5 -msgid "" -"For support related to a specific project, see the links on the :doc:" -"`Projects ` page." -msgstr "" -"Para suporte relacionado a um projeto específico, consulte os links na " -"página :doc:`Projetos `." - -#: ../source/support.rst:8 -msgid "" -"For something more general, or when you're just not sure, please `open an " -"issue `_ on the " -"`packaging-problems `_ " -"repository on GitHub." -msgstr "" -"Para algo mais geral, ou quando você não tiver certeza, por favor `relate um " -"problema `_ no " -"repositório `packaging-problems `" -"_ no GitHub." - -#: ../source/tutorials/creating-documentation.rst:5 -msgid "Creating Documentation" -msgstr "Criando documentação" - -#: ../source/tutorials/creating-documentation.rst:7 -msgid "" -"This section covers the basics of how to create documentation using " -"`Sphinx`_ and host the documentation for free in `Read The Docs`_." -msgstr "" -"Esta seção cobre o básico de como criar documentação usando `Sphinx`_ e " -"hospedar a documentação gratuitamente em `Read The Docs`_." - -#: ../source/tutorials/creating-documentation.rst:13 -msgid "Installing Sphinx" -msgstr "Instalando o Sphinx" - -#: ../source/tutorials/creating-documentation.rst:14 -msgid "Use ``pip`` to install Sphinx:" -msgstr "Use ``pip`` para instalar o Sphinx:" - -#: ../source/tutorials/creating-documentation.rst:28 -msgid "" -"For other installation methods, see this `installation guide`_ by Sphinx." -msgstr "" -"Para outros métodos de instalação, veja esta `guia de instalação`_ do Sphinx." - -#: ../source/tutorials/creating-documentation.rst:33 -msgid "Getting Started With Sphinx" -msgstr "Primeiros passos com Sphinx" - -#: ../source/tutorials/creating-documentation.rst:35 -msgid "" -"Create a ``docs`` directory inside your project to hold your documentation:" -msgstr "" -"Crie um diretório ``docs`` dentro de seu projeto para conter sua " -"documentação:" - -#: ../source/tutorials/creating-documentation.rst:42 -msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" -msgstr "Execute ``sphinx-quickstart`` dentro do diretório ``docs``:" - -#: ../source/tutorials/creating-documentation.rst:49 -msgid "" -"This sets up a source directory, walks you through some basic " -"configurations, and creates an ``index.rst`` file as well as a ``conf.py`` " -"file." -msgstr "" -"Isso configura um diretório fonte, orienta você por algumas configurações " -"básicas e cria um arquivo ``index.rst``, bem como um arquivo ``conf.py``." - -#: ../source/tutorials/creating-documentation.rst:51 -msgid "" -"You can add some information about your project in ``index.rst``, then build " -"them:" -msgstr "" -"Você pode adicionar algumas informações sobre o seu projeto em ``index.rst`` " -"e, em seguida, construí-las:" - -#: ../source/tutorials/creating-documentation.rst:57 -msgid "" -"For more details on the build process, see this `guide`_ by Read The Docs." -msgstr "" -"Para mais detalhes sobre o processo de construção, veja o `guia`_ do Read " -"The Docs." - -#: ../source/tutorials/creating-documentation.rst:62 -msgid "Other Sources" -msgstr "Outras fontes" - -#: ../source/tutorials/creating-documentation.rst:64 -msgid "" -"For a more detailed guide on how to use Sphinx and reStructuredText, please " -"see this `documentation tutorial`_ on Hitchhiker's Guide to Python." -msgstr "" -"Para um guia mais detalhado sobre como usar o Sphinx e o reStructuredText, " -"consulte este `tutorial de documentação`_ no Guia do Mochileiro para Python." - -#: ../source/tutorials/index.rst:4 -msgid "" -"**Tutorials** are opinionated step-by-step guides to help you get familiar " -"with packaging concepts. For more detailed information on specific packaging " -"topics, see :doc:`/guides/index`." -msgstr "" -"**Tutoriais** são guias passo a passo opinativos para ajudá-lo a se " -"familiarizar com os conceitos de empacotamento. Para obter informações mais " -"detalhadas sobre tópicos de empacotamento específicos, consulte :doc:`/" -"guides/index`." - -#: ../source/tutorials/installing-packages.rst:5 -msgid "Installing Packages" -msgstr "Instalando pacotes" - -#: ../source/tutorials/installing-packages.rst:7 -msgid "" -"This section covers the basics of how to install Python :term:`packages " -"`." -msgstr "" -"Esta seção cobre o básico de como instalar :term:`pacotes ` Python." - -#: ../source/tutorials/installing-packages.rst:10 -msgid "" -"It's important to note that the term \"package\" in this context is being " -"used to describe a bundle of software to be installed (i.e. as a synonym for " -"a :term:`distribution `). It does not to refer to the " -"kind of :term:`package ` that you import in your Python " -"source code (i.e. a container of modules). It is common in the Python " -"community to refer to a :term:`distribution ` using " -"the term \"package\". Using the term \"distribution\" is often not " -"preferred, because it can easily be confused with a Linux distribution, or " -"another larger software distribution like Python itself." -msgstr "" -"É importante notar que o termo \"pacote\" neste contexto está sendo usado " -"para descrever um pacote de software a ser instalado (ou seja, como um " -"sinônimo para uma :term:`distribuição `). Não se " -"refere ao tipo de :term:`pacote ` que você importa em " -"seu código-fonte Python (ou seja, um contêiner de módulos). É comum na " -"comunidade Python referir-se a uma :term:`distribuição ` usando o termo \"pacote\". Usar o termo \"distribuição\" " -"geralmente não é preferido, porque pode ser facilmente confundido com uma " -"distribuição Linux ou outra distribuição de software maior como o próprio " -"Python." - -#: ../source/tutorials/installing-packages.rst:28 -msgid "Requirements for Installing Packages" -msgstr "Requisitos para instalar pacotes" - -#: ../source/tutorials/installing-packages.rst:30 -msgid "" -"This section describes the steps to follow before installing other Python " -"packages." -msgstr "" -"Esta seção descreve as etapas a serem seguidas antes de instalar outros " -"pacotes Python." - -#: ../source/tutorials/installing-packages.rst:35 -msgid "Ensure you can run Python from the command line" -msgstr "" -"Certifique-se de que você consegue executar Python a partir da linha de " -"comando" - -#: ../source/tutorials/installing-packages.rst:37 -msgid "" -"Before you go any further, make sure you have Python and that the expected " -"version is available from your command line. You can check this by running:" -msgstr "" -"Antes de prosseguir, certifique-se de ter o Python e de que a versão " -"esperada está disponível em sua linha de comando. Você pode verificar isso " -"executando:" - -#: ../source/tutorials/installing-packages.rst:53 -msgid "" -"You should get some output like ``Python 3.6.3``. If you do not have Python, " -"please install the latest 3.x version from `python.org`_ or refer to the " -"`Installing Python`_ section of the Hitchhiker's Guide to Python." -msgstr "" -"Você deve obter alguma saída como ``Python 3.6.3``. Se você não tiver o " -"Python, instale a versão 3.x mais recente de `python.org`_ ou consulte a " -"seção `Instalando Python`_ do Guia do Mochileiro para Python." - -#: ../source/tutorials/installing-packages.rst:57 -msgid "If you're a newcomer and you get an error like this:" -msgstr "Se você for um novato e receber um erro como este:" - -#: ../source/tutorials/installing-packages.rst:66 -msgid "" -"It's because this command and other suggested commands in this tutorial are " -"intended to be run in a *shell* (also called a *terminal* or *console*). See " -"the Python for Beginners `getting started tutorial`_ for an introduction to " -"using your operating system's shell and interacting with Python." -msgstr "" -"É porque este comando e outros comandos sugeridos neste tutorial devem ser " -"executados em um *shell* (também chamado de *terminal* ou *console*). Veja o " -"`tutorial de introdução`_ para iniciantes do Python para uma introdução " -"sobre como usar o shell do seu sistema operacional e interagir com o Python." - -#: ../source/tutorials/installing-packages.rst:72 -msgid "" -"If you're using an enhanced shell like IPython or the Jupyter notebook, you " -"can run system commands like those in this tutorial by prefacing them with a " -"``!`` character:" -msgstr "" -"Se estiver usando um shell aprimorado como o IPython ou o notebook Jupyter, " -"você pode executar comandos do sistema como os deste tutorial precedendo-os " -"com um caractere ``!``:" - -#: ../source/tutorials/installing-packages.rst:82 -msgid "" -"It's recommended to write ``{sys.executable}`` rather than plain ``python`` " -"in order to ensure that commands are run in the Python installation matching " -"the currently running notebook (which may not be the same Python " -"installation that the ``python`` command refers to)." -msgstr "" -"É recomendado escrever ``{sys.executable}`` em vez de ``python`` simples " -"para garantir que os comandos sejam executados na instalação do Python " -"correspondendo ao ambiente em execução (que pode não ser o mesmo Python " -"instalação à qual o comando ``python`` se refere)." - -#: ../source/tutorials/installing-packages.rst:87 -msgid "" -"Due to the way most Linux distributions are handling the Python 3 migration, " -"Linux users using the system Python without creating a virtual environment " -"first should replace the ``python`` command in this tutorial with " -"``python3`` and the ``python -m pip`` command with ``python3 -m pip --" -"user``. Do *not* run any of the commands in this tutorial with ``sudo``: if " -"you get a permissions error, come back to the section on creating virtual " -"environments, set one up, and then continue with the tutorial as written." -msgstr "" -"Devido à forma como a maioria das distribuições Linux está lidando com a " -"migração Python 3, os usuários Linux usando o sistema Python sem criar um " -"ambiente virtual primeiro devem substituir o comando ``python`` neste " -"tutorial por ``python3`` e o comando ``python -m pip`` com ``python3 -m pip " -"--user``. *Não* execute nenhum dos comandos neste tutorial com ``sudo``: se " -"você receber um erro de permissão, volte para a seção sobre como criar " -"ambientes virtuais, configure um e então continue com o tutorial como " -"escrito." - -#: ../source/tutorials/installing-packages.rst:99 -msgid "Ensure you can run pip from the command line" -msgstr "" -"Certifique-se de que você pode executar o pip a partir da linha de comando" - -#: ../source/tutorials/installing-packages.rst:101 -msgid "" -"Additionally, you'll need to make sure you have :ref:`pip` available. You " -"can check this by running:" -msgstr "" -"Além disso, você precisa ter certeza de ter :ref:`pip` disponível. Você pode " -"verificar isso executando:" - -#: ../source/tutorials/installing-packages.rst:116 -msgid "" -"If you installed Python from source, with an installer from `python.org`_, " -"or via `Homebrew`_ you should already have pip. If you're on Linux and " -"installed using your OS package manager, you may have to install pip " -"separately, see :doc:`/guides/installing-using-linux-tools`." -msgstr "" -"Se você instalou Python a partir do código-fonte, com um instalador de " -"`python.org`_, ou via `Homebrew`_, você já deve ter o pip. Se você estiver " -"no Linux e instalado usando o gerenciador de pacotes do sistema operacional, " -"pode ser necessário instalar o pip separadamente, consulte :doc:`/guides/" -"installing-using-linux-tools`." - -#: ../source/tutorials/installing-packages.rst:124 -msgid "" -"If ``pip`` isn't already installed, then first try to bootstrap it from the " -"standard library:" -msgstr "" -"Se o ``pip`` ainda não estiver instalado, tente primeiro inicializá-lo a " -"partir da biblioteca padrão:" - -#: ../source/tutorials/installing-packages.rst:139 -msgid "If that still doesn't allow you to run ``python -m pip``:" -msgstr "Se isso ainda não permitir que você execute ``python -m pip``:" - -#: ../source/tutorials/installing-packages.rst:141 -msgid "" -"Securely Download `get-pip.py `_ [1]_" -msgstr "" -"Baixe com segurança `get-pip.py `_ [1]_" - -#: ../source/tutorials/installing-packages.rst:144 -msgid "" -"Run ``python get-pip.py``. [2]_ This will install or upgrade pip. " -"Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're " -"not installed already." -msgstr "" -"Execute ``python get-pip.py``. [2]_ Isso vai instalar ou atualizar o pip. " -"Adicionalmente, vai instalar :ref:`setuptools` e :ref:`wheel` se ainda não " -"estiverem instalados." - -#: ../source/tutorials/installing-packages.rst:150 -msgid "" -"Be cautious if you're using a Python install that's managed by your " -"operating system or another package manager. get-pip.py does not coordinate " -"with those tools, and may leave your system in an inconsistent state. You " -"can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/" -"local`` which is designed for locally-installed software." -msgstr "" -"Tenha cuidado se estiver usando uma instalação do Python gerenciada por seu " -"sistema operacional ou outro gerenciador de pacotes. get-pip.py não coordena " -"com essas ferramentas e pode deixar seu sistema em um estado inconsistente. " -"Você pode usar ``python get-pip.py --prefix=/usr/local/`` para instalar em " -"``/usr/local`` que é projetado para software instalado localmente." - -#: ../source/tutorials/installing-packages.rst:159 -msgid "Ensure pip, setuptools, and wheel are up to date" -msgstr "Certifique-se que pip, setuptools e wheel estejam atualizados" - -#: ../source/tutorials/installing-packages.rst:161 -msgid "" -"While ``pip`` alone is sufficient to install from pre-built binary archives, " -"up to date copies of the ``setuptools`` and ``wheel`` projects are useful to " -"ensure you can also install from source archives::" -msgstr "" -"Embora ``pip`` sozinho seja suficiente para instalar a partir de arquivos " -"binários pré-compilados, cópias atualizadas dos projetos ``setuptools`` e " -"``wheel`` são úteis para garantir que você também possa instalar a partir de " -"arquivos fonte::" - -#: ../source/tutorials/installing-packages.rst:169 -msgid "Optionally, create a virtual environment" -msgstr "Opcionalmente, crie um ambiente virtual" - -#: ../source/tutorials/installing-packages.rst:171 -msgid "" -"See :ref:`section below ` for " -"details, but here's the basic `venv`_ [3]_ command to use on a typical Linux " -"system:" -msgstr "" -"Veja a :ref:`seção abaixo ` para " -"detalhes, mas aqui está o comando básico de `venv`_ [3]_ para usar em um " -"sistema Linux típico:" - -#: ../source/tutorials/installing-packages.rst:188 -msgid "" -"This will create a new virtual environment in the ``tutorial_env`` " -"subdirectory, and configure the current shell to use it as the default " -"``python`` environment." -msgstr "" -"Isso criará um novo ambiente virtual no subdiretório ``tutorial_env`` e " -"configurará o shell atual para usá-lo como o ambiente ``python`` padrão." - -#: ../source/tutorials/installing-packages.rst:195 -msgid "Creating Virtual Environments" -msgstr "Criando ambientes virtuais" - -#: ../source/tutorials/installing-packages.rst:197 -msgid "" -"Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular " -"application, rather than being installed globally. If you are looking to " -"safely install global command line tools, see :doc:`/guides/installing-stand-" -"alone-command-line-tools`." -msgstr "" -"\"Ambientes virtuais\" do Python permitem que :term:`pacotes ` Python sejam instalados em um local isolado para uma " -"aplicação em particular, ao invés de serem instalados globalmente. Se você " -"deseja instalar ferramentas de linha de comando globais com segurança, " -"consulte :doc:`/guides/installing-stand-alone-command-line-tools`." - -#: ../source/tutorials/installing-packages.rst:203 -msgid "" -"Imagine you have an application that needs version 1 of LibFoo, but another " -"application requires version 2. How can you use both these applications? If " -"you install everything into /usr/lib/python3.6/site-packages (or whatever " -"your platform’s standard location is), it’s easy to end up in a situation " -"where you unintentionally upgrade an application that shouldn’t be upgraded." -msgstr "" -"Imagine que você tenha uma aplicação que precisa da versão 1 do LibFoo, mas " -"outra aplicação requer a versão 2. Como você pode usar essas duas " -"aplicações? Se você instalar tudo em /usr/lib/python3.6/site-packages (ou " -"qualquer que seja o local padrão de sua plataforma), é fácil acabar em uma " -"situação em que você atualiza acidentalmente uma aplicação que não deveria " -"ser atualizada." - -#: ../source/tutorials/installing-packages.rst:209 -msgid "" -"Or more generally, what if you want to install an application and leave it " -"be? If an application works, any change in its libraries or the versions of " -"those libraries can break the application." -msgstr "" -"Ou, de forma mais geral, e se você quiser instalar uma aplicação e deixá-la " -"como está? Se uma aplicação funcionar, qualquer alteração em suas " -"bibliotecas ou nas versões dessas bibliotecas pode interromper a aplicação." - -#: ../source/tutorials/installing-packages.rst:213 -msgid "" -"Also, what if you can’t install :term:`packages ` into " -"the global site-packages directory? For instance, on a shared host." -msgstr "" -"Além disso, e se você não puder instalar :term:`pacotes ` no diretório global site-packages? Por exemplo, em um host " -"compartilhado." - -#: ../source/tutorials/installing-packages.rst:216 -msgid "" -"In all these cases, virtual environments can help you. They have their own " -"installation directories and they don’t share libraries with other virtual " -"environments." -msgstr "" -"Em todos esses casos, os ambientes virtuais podem lhe ajudar. Eles têm seus " -"próprios diretórios de instalação e não compartilham bibliotecas com outros " -"ambientes virtuais." - -#: ../source/tutorials/installing-packages.rst:220 -msgid "" -"Currently, there are two common tools for creating Python virtual " -"environments:" -msgstr "" -"Atualmente, existem duas ferramentas comuns para a criação de ambientes " -"virtuais Python:" - -#: ../source/tutorials/installing-packages.rst:222 -msgid "" -"`venv`_ is available by default in Python 3.3 and later, and installs :ref:" -"`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 " -"and later." -msgstr "" -"`venv`_ está disponível por padrão no Python 3.3 e posterior, e instala :ref:" -"`pip` e :ref:`setuptools` em ambientes virtuais criados no Python 3.4 e " -"posterior." - -#: ../source/tutorials/installing-packages.rst:225 -msgid "" -":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ " -"and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are " -"always installed into created virtual environments by default (regardless of " -"Python version)." -msgstr "" -":ref:`virtualenv` precisa ser instalado separadamente, mas oferece suporte a " -"Python 2.7+ e Python 3.3+, e :ref:`pip`, :ref:`setuptools` e :ref:`wheel` " -"são sempre instalados em ambientes virtuais criados por padrão " -"(independentemente da versão Python)." - -#: ../source/tutorials/installing-packages.rst:230 -msgid "The basic usage is like so:" -msgstr "O uso básico é assim:" - -#: ../source/tutorials/installing-packages.rst:232 -msgid "Using `venv`_:" -msgstr "Usando `venv`_:" - -#: ../source/tutorials/installing-packages.rst:248 -msgid "Using :ref:`virtualenv`:" -msgstr "Usando :ref:`virtualenv`:" - -#: ../source/tutorials/installing-packages.rst:264 -msgid "" -"For more information, see the `venv`_ docs or the `virtualenv `_ docs." -msgstr "" -"Para mais informações, veja a documentação do `venv`_ ou do`virtualenv " -"`_." - -#: ../source/tutorials/installing-packages.rst:266 -msgid "" -"The use of :command:`source` under Unix shells ensures that the virtual " -"environment's variables are set within the current shell, and not in a " -"subprocess (which then disappears, having no useful effect)." -msgstr "" -"O uso de :command:`source` em shells Unix garante que as variáveis do " -"ambiente virtual sejam definidas dentro do shell atual, e não em um " -"subprocesso (que então desaparece, sem nenhum efeito útil)." - -#: ../source/tutorials/installing-packages.rst:271 -msgid "" -"In both of the above cases, Windows users should _not_ use the :command:" -"`source` command, but should rather run the :command:`activate` script " -"directly from the command shell like so:" -msgstr "" -"Em ambos os casos acima, os usuários Windows não devem _não_ usar o comando :" -"command:`source`, mas devem executar o script :command:`activate` " -"diretamente do shell de comando assim:" - -#: ../source/tutorials/installing-packages.rst:281 -msgid "" -"Managing multiple virtual environments directly can become tedious, so the :" -"ref:`dependency management tutorial ` introduces a " -"higher level tool, :ref:`Pipenv`, that automatically manages a separate " -"virtual environment for each project and application that you work on." -msgstr "" -"Gerenciar vários ambientes virtuais diretamente pode se tornar tedioso, " -"então o :ref:`tutorial de gerenciamento de dependências ` apresenta uma ferramenta de alto nível, :ref:`Pipenv`, que " -"gerencia automaticamente um ambiente virtual separado para cada projeto e " -"aplicação no qual você trabalha." - -#: ../source/tutorials/installing-packages.rst:288 -msgid "Use pip for Installing" -msgstr "Usar pip para instalação" - -#: ../source/tutorials/installing-packages.rst:290 -msgid "" -":ref:`pip` is the recommended installer. Below, we'll cover the most common " -"usage scenarios. For more detail, see the `pip docs `_, " -"which includes a complete `Reference Guide `_." -msgstr "" -":ref:`pip` é o instalador recomendado. A seguir, cobriremos os cenários de " -"uso mais comuns. Para obter mais detalhes, consulte a `documentação do pip " -"`_, que inclui um `Guia de referências `_ completo." - -#: ../source/tutorials/installing-packages.rst:297 -msgid "Installing from PyPI" -msgstr "Instalando a partir do PyPI" - -#: ../source/tutorials/installing-packages.rst:299 -msgid "" -"The most common usage of :ref:`pip` is to install from the :term:`Python " -"Package Index ` using a :term:`requirement " -"specifier `. Generally speaking, a requirement " -"specifier is composed of a project name followed by an optional :term:" -"`version specifier `. :pep:`440` contains a :pep:`full " -"specification <440#version-specifiers>` of the currently supported " -"specifiers. Below are some examples." -msgstr "" -"O uso mais comum do :ref:`pip` é instalar a partir do :term:`Python Package " -"Index ` usando um :term:`especificador de " -"requisitos `. De modo geral, um especificador " -"de requisitos é composto de um nome de projeto seguido por um :term:" -"`especificador de versão ` opcional . :pep:`440` " -"contém uma :pep:`especificação completa <440#version-specifiers>` dos " -"especificadores suportados atualmente. Abaixo estão alguns exemplos." - -#: ../source/tutorials/installing-packages.rst:307 -msgid "To install the latest version of \"SomeProject\":" -msgstr "Para instalar a versão mais recente de \"SomeProject\":" - -#: ../source/tutorials/installing-packages.rst:321 -msgid "To install a specific version:" -msgstr "Para instalar uma versão específica:" - -#: ../source/tutorials/installing-packages.rst:335 -msgid "To install greater than or equal to one version and less than another:" -msgstr "Para instalar maior ou igual a uma versão e menor que outra:" - -#: ../source/tutorials/installing-packages.rst:350 -msgid "" -"To install a version that's :pep:`\"compatible\" <440#compatible-release>` " -"with a certain version: [4]_" -msgstr "" -"Para instalar uma versão que é :pep:`\"compatível\" <440#compatible-" -"release>` com uma determinada versão: [4]_" - -#: ../source/tutorials/installing-packages.rst:365 -msgid "" -"In this case, this means to install any version \"==1.4.*\" version that's " -"also \">=1.4.2\"." -msgstr "" -"Nesse caso, isso significa instalar qualquer versão \"==1.4.*\" que também " -"seja \">=1.4.2\"." - -#: ../source/tutorials/installing-packages.rst:370 -msgid "Source Distributions vs Wheels" -msgstr "Distribuições de fonte vs Wheels" - -#: ../source/tutorials/installing-packages.rst:372 -msgid "" -":ref:`pip` can install from either :term:`Source Distributions (sdist) " -"` or :term:`Wheels `, but if both " -"are present on PyPI, pip will prefer a compatible :term:`wheel `. You " -"can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." -msgstr "" -":ref:`pip` pode instalar a partir de :term:`Distribuições Fonte (sdist) " -"` ou :term:`Wheels `, mas se ambos " -"estiverem presentes no PyPI, pip irá preferir um :term:`wheel ` " -"compatível. Você pode substituir o comportamento padrão do pip, por exemplo " -"usando sua opção :ref:`--no-binary `." - -#: ../source/tutorials/installing-packages.rst:378 -msgid "" -":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source " -"Distributions (sdist) `, especially when " -"a project contains compiled extensions." -msgstr "" -":term:`Wheels ` são um formato de :term:`distribuição ` pré-construído que fornece uma instalação mais rápida em " -"comparação com :term:`Distribuições Fonte (sdist) `, especialmente quando um projeto contém extensões compiladas." - -#: ../source/tutorials/installing-packages.rst:383 -msgid "" -"If :ref:`pip` does not find a wheel to install, it will locally build a " -"wheel and cache it for future installs, instead of rebuilding the source " -"distribution in the future." -msgstr "" -"Se :ref:`pip` não encontrar um wheel para instalar, ele irá construir um " -"wheel localmente e armazená-lo em cache para instalações futuras, ao invés " -"de reconstruir a distribuição fonte no futuro." - -#: ../source/tutorials/installing-packages.rst:391 -msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." -msgstr "Atualize um ``SomeProject`` já instalado para o mais recente do PyPI." - -#: ../source/tutorials/installing-packages.rst:408 -msgid "Installing to the User Site" -msgstr "Instalando para o site do usuário" - -#: ../source/tutorials/installing-packages.rst:410 -msgid "" -"To install :term:`packages ` that are isolated to the " -"current user, use the ``--user`` flag:" -msgstr "" -"Para instalar :term:`pacotes ` que são isolados para " -"o usuário atual, use o sinalizador ``--user``:" - -#: ../source/tutorials/installing-packages.rst:425 -msgid "" -"For more information see the `User Installs `_ section from the pip docs." -msgstr "" -"Para obter mais informações, consulte a seção `User Installs `_ da documentação do " -"pip." - -#: ../source/tutorials/installing-packages.rst:429 -msgid "" -"Note that the ``--user`` flag has no effect when inside a virtual " -"environment - all installation commands will affect the virtual environment." -msgstr "" -"Observe que o sinalizador ``--user`` não tem efeito quando dentro de um " -"ambiente virtual -- todos os comandos de instalação afetarão o ambiente " -"virtual." - -#: ../source/tutorials/installing-packages.rst:432 -msgid "" -"If ``SomeProject`` defines any command-line scripts or console entry points, " -"``--user`` will cause them to be installed inside the `user base`_'s binary " -"directory, which may or may not already be present in your shell's :envvar:" -"`PATH`. (Starting in version 10, pip displays a warning when installing any " -"scripts to a directory outside :envvar:`PATH`.) If the scripts are not " -"available in your shell after installation, you'll need to add the directory " -"to your :envvar:`PATH`:" -msgstr "" -"Se ``SomeProject`` definir quaisquer scripts de linha de comando ou pontos " -"de entrada de console, ``--user`` fará com que sejam instalados dentro do " -"diretório binário da `base do usuário`_, que pode ou não já estar presente " -"em seu :envvar:`PATH` do shell. (A partir da versão 10, pip exibe um aviso " -"ao instalar qualquer script em um diretório fora de :envvar:`PATH`.) Se os " -"scripts não estiverem disponíveis em seu shell após a instalação, você " -"precisará adicionar o diretório ao seu :envvar:`PATH`:" - -#: ../source/tutorials/installing-packages.rst:440 -msgid "" -"On Linux and macOS you can find the user base binary directory by running " -"``python -m site --user-base`` and adding ``bin`` to the end. For example, " -"this will typically print ``~/.local`` (with ``~`` expanded to the absolute " -"path to your home directory) so you'll need to add ``~/.local/bin`` to your " -"``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." -msgstr "" -"No Linux e no macOS você pode encontrar o diretório binário da base do " -"usuário executando ``python -m site --user-base`` e adicionando ``bin`` no " -"final. Por exemplo, isso normalmente imprimirá ``~/.local`` (com ``~`` " -"expandido para o caminho absoluto para o seu diretório inicial), então você " -"precisará adicionar ``~/.local/bin`` para seu ``PATH``. Você pode definir " -"seu ``PATH`` permanentemente `modificando ~/.profile`_." - -#: ../source/tutorials/installing-packages.rst:446 -msgid "" -"On Windows you can find the user base binary directory by running ``py -m " -"site --user-site`` and replacing ``site-packages`` with ``Scripts``. For " -"example, this could return ``C:\\Users\\Username\\AppData\\Roaming" -"\\Python36\\site-packages`` so you would need to set your ``PATH`` to " -"include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You " -"can set your user ``PATH`` permanently in the `Control Panel`_. You may need " -"to log out for the ``PATH`` changes to take effect." -msgstr "" -"No Windows você pode encontrar o diretório binário base do usuário " -"executando ``py -m site --user-site`` e substituindo ``site-packages`` por " -"``Scripts``. Por exemplo, isso poderia retornar ``C:\\Users\\Username" -"\\AppData\\Roaming\\Python36\\site-packages``, então você precisaria definir " -"seu ``PATH`` para incluir ``C:\\Users\\Username\\AppData\\Roaming" -"\\Python36\\Scripts``. Você pode definir seu usuário ``PATH`` " -"permanentemente no `Painel de Controle`_. Você pode precisar encerrar a " -"sessão para que as alterações de ``PATH`` tenham efeito." - -#: ../source/tutorials/installing-packages.rst:462 -msgid "" -"Install a list of requirements specified in a :ref:`Requirements File `." -msgstr "" -"Instale uma lista de requisitos especificados em um :ref:`arquivo de " -"requisitos `." - -#: ../source/tutorials/installing-packages.rst:478 -msgid "Installing from VCS" -msgstr "Instalando a partir de VCS" - -#: ../source/tutorials/installing-packages.rst:480 -msgid "" -"Install a project from VCS in \"editable\" mode. For a full breakdown of " -"the syntax, see pip's section on :ref:`VCS Support `." -msgstr "" -"Instale um projeto a partir de VCS em um modo \"editável\". Para um " -"instrução completa da sintaxe, veja a seção do pip em :ref:`VCS Support `." - -#: ../source/tutorials/installing-packages.rst:502 -msgid "Installing from other Indexes" -msgstr "Instalando a partir de outros índices" - -#: ../source/tutorials/installing-packages.rst:504 -msgid "Install from an alternate index" -msgstr "Instalar a partir de um índice alternativo" - -#: ../source/tutorials/installing-packages.rst:518 -msgid "" -"Search an additional index during install, in addition to :term:`PyPI " -"`" -msgstr "" -"Pesquise um índice adicional durante a instalação, além do :term:`PyPI " -"`" - -#: ../source/tutorials/installing-packages.rst:534 -msgid "Installing from a local src tree" -msgstr "Instalando a partir de uma árvore de fontes local" - -#: ../source/tutorials/installing-packages.rst:537 -msgid "" -"Installing from local src in `Development Mode `_, i.e. in such a " -"way that the project appears to be installed, but yet is still editable from " -"the src tree." -msgstr "" -"Instale a partir dos fontes locais em `Development Mode `_, ou seja, de " -"tal forma que o projeto parece estar instalado, mas ainda seja editável a " -"partir da árvore de fontes." - -#: ../source/tutorials/installing-packages.rst:554 -msgid "You can also install normally from src" -msgstr "Você também pode instalar normalmente a partir dos fontes" - -#: ../source/tutorials/installing-packages.rst:571 -msgid "Install a particular source archive file." -msgstr "Instale um arquivo de pacote fonte em particular." - -#: ../source/tutorials/installing-packages.rst:585 -msgid "" -"Install from a local directory containing archives (and don't check :term:" -"`PyPI `)" -msgstr "" -"Instale de um pacote contendo diretório local (e não verifique o :term:`PyPI " -"`)" - -#: ../source/tutorials/installing-packages.rst:605 -msgid "Installing from other sources" -msgstr "Instalando a partir de outras fontes" - -#: ../source/tutorials/installing-packages.rst:607 -msgid "" -"To install from other data sources (for example Amazon S3 storage) you can " -"create a helper application that presents the data in a :pep:`503` compliant " -"index format, and use the ``--extra-index-url`` flag to direct pip to use " -"that index." -msgstr "" -"Para instalar a partir de outras fontes de dados (por exemplo, armazenamento " -"Amazon S3), você pode criar uma aplicação auxiliar que apresente os dados em " -"um formato de índice compatível com :pep:`503` e usar o sinalizador ``--" -"extra-index-url`` para direcionar o pip para usar esse índice." - -#: ../source/tutorials/installing-packages.rst:619 -msgid "Installing Prereleases" -msgstr "Instalando pré-lançamentos" - -#: ../source/tutorials/installing-packages.rst:621 -msgid "" -"Find pre-release and development versions, in addition to stable versions. " -"By default, pip only finds stable versions." -msgstr "" -"Encontre versões de pré-lançamento e desenvolvimento, além de versões " -"estáveis. Por padrão, pip só encontra versões estáveis." - -#: ../source/tutorials/installing-packages.rst:637 -msgid "Installing Setuptools \"Extras\"" -msgstr "Instalando Setuptools \"extras\"" - -#: ../source/tutorials/installing-packages.rst:639 -msgid "Install `setuptools extras`_." -msgstr "Instale `setuptools extras`_." - -#: ../source/tutorials/installing-packages.rst:659 -msgid "" -"\"Secure\" in this context means using a modern browser or a tool like :" -"command:`curl` that verifies SSL certificates when downloading from https " -"URLs." -msgstr "" -"\"Segurança\" neste contexto significa usar um navegador moderno ou uma " -"ferramenta como :command:`curl` que verifica os certificados SSL ao baixar " -"de URLs https." - -#: ../source/tutorials/installing-packages.rst:668 -msgid "" -"Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:" -"`virtualenv`) will create virtualenv environments with ``pip`` pre-" -"installed, thereby making it an equal alternative to :ref:`virtualenv`." -msgstr "" -"Começando com Python 3.4, ``venv`` (uma alternativa à biblioteca padrão " -"para :ref:`virtualenv`) criará ambientes do virtualenv com ``pip`` pré-" -"instalado, tornando-o uma alternativa igual a :ref:`virtualenv`." - -#: ../source/tutorials/installing-packages.rst:673 -msgid "" -"The compatible release specifier was accepted in :pep:`440` and support was " -"released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" -msgstr "" -"O especificador de versão compatível foi aceito em :pep:`440` e o suporte " -"foi lançado em :ref:`setuptools` v8.0 e :ref:`pip` v6.0" - -#: ../source/tutorials/managing-dependencies.rst:4 -msgid "Managing Application Dependencies" -msgstr "Gerenciando dependências de aplicações" - -#: ../source/tutorials/managing-dependencies.rst:6 -msgid "" -"The :ref:`package installation tutorial ` covered the " -"basics of getting set up to install and update Python packages." -msgstr "" -"O :ref:`tutorial de instalação do pacote ` cobriu os " -"fundamentos da configuração para instalar e atualizar pacotes Python." - -#: ../source/tutorials/managing-dependencies.rst:9 -msgid "" -"However, running these commands interactively can get tedious even for your " -"own personal projects, and things get even more difficult when trying to set " -"up development environments automatically for projects with multiple " -"contributors." -msgstr "" -"No entanto, executar esses comandos interativamente pode se tornar tedioso " -"até mesmo para seus próprios projetos pessoais, e as coisas ficam ainda mais " -"difíceis ao tentar configurar ambientes de desenvolvimento automaticamente " -"para projetos com vários contribuidores." - -#: ../source/tutorials/managing-dependencies.rst:13 -msgid "" -"This tutorial walks you through the use of :ref:`Pipenv` to manage " -"dependencies for an application. It will show you how to install and use the " -"necessary tools and make strong recommendations on best practices." -msgstr "" -"Este tutorial orienta você no uso de :ref:`Pipenv` para gerenciar " -"dependências para uma aplicação. Ele mostrará como instalar e usar as " -"ferramentas necessárias e fará recomendações fortes sobre as melhores " -"práticas." - -#: ../source/tutorials/managing-dependencies.rst:17 -msgid "" -"Keep in mind that Python is used for a great many different purposes, and " -"precisely how you want to manage your dependencies may change based on how " -"you decide to publish your software. The guidance presented here is most " -"directly applicable to the development and deployment of network services " -"(including web applications), but is also very well suited to managing " -"development and testing environments for any kind of project." -msgstr "" -"Lembre-se de que Python é usado para muitos propósitos diferentes e, " -"precisamente, como você deseja gerenciar suas dependências pode mudar com " -"base em como você decide publicar seu software. A orientação apresentada " -"aqui é mais diretamente aplicável ao desenvolvimento e implantação de " -"serviços de rede (incluindo aplicações web), mas também é muito adequada " -"para gerenciar ambientes de desenvolvimento e teste para qualquer tipo de " -"projeto." - -#: ../source/tutorials/managing-dependencies.rst:24 -msgid "" -"Developers of Python libraries, or of applications that support distribution " -"as Python libraries, should also consider the `poetry `_ project as an alternative dependency management " -"solution." -msgstr "" -"Desenvolvedores de bibliotecas Python, ou de aplicações que oferece suporte " -"a distribuição como bibliotecas Python, também devem considerar o projeto `" -"poetry `_ como uma solução " -"alternativa de gerenciamento de dependências." - -#: ../source/tutorials/managing-dependencies.rst:30 -msgid "Installing Pipenv" -msgstr "Instalando Pipenv" - -#: ../source/tutorials/managing-dependencies.rst:32 -msgid "" -":ref:`Pipenv` is a dependency manager for Python projects. If you're " -"familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit " -"to those tools. While :ref:`pip` alone is often sufficient for personal use, " -"Pipenv is recommended for collaborative projects as it's a higher-level tool " -"that simplifies dependency management for common use cases." -msgstr "" -":ref:`Pipenv` é um gerenciador de dependências para projetos Python. Se você " -"está familiarizado com o `npm`_ do Node.js ou o `bundler`_ do Ruby, é " -"semelhante em espírito a essas ferramentas. Enquanto :ref:`pip` por si só " -"costuma ser suficiente para uso pessoal, Pipenv é recomendado para projetos " -"colaborativos por ser uma ferramenta de nível superior que simplifica o " -"gerenciamento de dependências para casos de uso comuns." - -#: ../source/tutorials/managing-dependencies.rst:38 -msgid "Use ``pip`` to install Pipenv:" -msgstr "Use ``pip`` para instalar Pipenv:" - -#: ../source/tutorials/managing-dependencies.rst:54 -msgid "" -"This does a `user installation`_ to prevent breaking any system-wide " -"packages. If ``pipenv`` isn't available in your shell after installation, " -"you'll need to add the `user base`_'s binary directory to your ``PATH``. " -"See :ref:`Installing to the User Site` for more information." -msgstr "" -"Isso faz uma `instalação do usuário`_ para evitar quebrar qualquer pacote do " -"sistema. Se ``pipenv`` não estiver disponível em seu shell após a " -"instalação, você precisará adicionar o diretório binário da `base de " -"usuário`_ ao seu ``PATH``. Veja :ref:`Instalando no Site do Usuário` para " -"mais informações." - -#: ../source/tutorials/managing-dependencies.rst:65 -msgid "Installing packages for your project" -msgstr "Instalando pacotes para seu projeto" - -#: ../source/tutorials/managing-dependencies.rst:67 -msgid "" -"Pipenv manages dependencies on a per-project basis. To install packages, " -"change into your project's directory (or just an empty directory for this " -"tutorial) and run:" -msgstr "" -"O Pipenv gerencia dependências por projeto. Para instalar pacotes, mude para " -"o diretório do seu projeto (ou apenas um diretório vazio para este tutorial) " -"e execute:" - -#: ../source/tutorials/managing-dependencies.rst:76 -msgid "" -"Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you " -"in your project's directory. The :ref:`Pipfile` is used to track which " -"dependencies your project needs in case you need to re-install them, such as " -"when you share your project with others. You should get output similar to " -"this (although the exact paths shown will vary):" -msgstr "" -"Pipenv irá instalar a biblioteca `Requests`_ e criar um ``Pipfile`` para " -"você no diretório do seu projeto. O :ref:`Pipfile` é usado para rastrear " -"quais dependências seu projeto precisa no caso de você precisar reinstalá-" -"las, como quando você compartilha seu projeto com outras pessoas. Você deve " -"obter uma saída semelhante a esta (embora os caminhos exatos mostrados " -"variem):" - -#: ../source/tutorials/managing-dependencies.rst:112 -msgid "Using installed packages" -msgstr "Usando pacotes instalados" - -#: ../source/tutorials/managing-dependencies.rst:114 -msgid "" -"Now that Requests is installed you can create a simple :file:`main.py` file " -"to use it:" -msgstr "" -"Agora que Requests está instalado você pode criar um :file:`main.py` simples " -"para usá-lo:" - -#: ../source/tutorials/managing-dependencies.rst:125 -msgid "Then you can run this script using ``pipenv run``:" -msgstr "Então, você pode executar este script usando ``pipenv run``:" - -#: ../source/tutorials/managing-dependencies.rst:131 -msgid "You should get output similar to this:" -msgstr "Você deve obter uma saída similar a esta:" - -#: ../source/tutorials/managing-dependencies.rst:137 -msgid "" -"Using ``pipenv run`` ensures that your installed packages are available to " -"your script. It's also possible to spawn a new shell that ensures all " -"commands have access to your installed packages with ``pipenv shell``." -msgstr "" -"Usar ``pipenv run`` garante que seus pacotes instalados estejam disponíveis " -"para seu script. Também é possível gerar um novo shell que garante que todos " -"os comandos tenham acesso aos seus pacotes instalados com ``pipenv shell``." - -#: ../source/tutorials/managing-dependencies.rst:143 -#: ../source/tutorials/packaging-projects.rst:594 -msgid "Next steps" -msgstr "Próximos passos" - -#: ../source/tutorials/managing-dependencies.rst:145 -msgid "" -"Congratulations, you now know how to effectively manage dependencies and " -"development environments on a collaborative Python project! ✨ 🍰 ✨" -msgstr "" -"Parabéns, agora você sabe como gerenciar dependências e ambientes de " -"desenvolvimento com eficácia em um projeto colaborativo Python! ✨ 🍰 ✨" - -#: ../source/tutorials/managing-dependencies.rst:148 -msgid "" -"If you're interested in creating and distributing your own Python packages, " -"see the :ref:`tutorial on packaging and distributing packages `." -msgstr "" -"Se você estiver interessado em criar e distribuir seus próprios pacotes " -"Python, veja o :ref:`tutorial sobre empacotamento e distribuição de pacotes " -"`." - -#: ../source/tutorials/managing-dependencies.rst:151 -msgid "" -"Note that when your application includes definitions of Python source " -"packages, they (and their dependencies) can be added to your ``pipenv`` " -"environment with ``pipenv install -e `` " -"(e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." -msgstr "" -"Observe que quando sua aplicação inclui definições de pacotes fonte do " -"Python, elas (e suas dependências) podem ser adicionadas ao seu ambiente de " -"``pipenv`` com ``pipenv install -e `` " -"(por exemplo, ``pipenv install -e .`` ou ``pipenv install -e src``)." - -#: ../source/tutorials/managing-dependencies.rst:160 -msgid "Other Tools for Application Dependency Management" -msgstr "Outras ferramentas para gerenciamento de dependências de aplicações" - -#: ../source/tutorials/managing-dependencies.rst:162 -msgid "" -"If you find this particular approach to managing application dependencies " -"isn't working well for you or your use case, you may want to explore these " -"other tools and techniques to see if one of them is a better fit:" -msgstr "" -"Se você achar que essa abordagem específica para gerenciar dependências de " -"aplicações não está funcionando bem para você ou seu caso de uso, convém " -"explorar essas outras ferramentas e técnicas para ver se uma delas se " -"encaixa melhor:" - -#: ../source/tutorials/managing-dependencies.rst:166 -msgid "" -"`poetry `__ for a tool comparable " -"in scope to ``pipenv`` that focuses more directly on use cases where the " -"repository being managed is structured as a Python project with a valid " -"``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making " -"the assumption that the application being worked on that's depending on " -"components from PyPI will itself support distribution as a ``pip``-" -"installable Python package)." -msgstr "" -"`poetry `__ para uma ferramenta " -"comparável em escopo a ``pipenv`` que se concentra mais diretamente em casos " -"de uso onde o repositório sendo gerenciado é estruturado como um projeto " -"Python com um arquivo ``pyproject.toml`` válido (por outro lado, ``pipenv`` " -"explicitamente evita fazer a suposição de que a aplicação que está sendo " -"trabalhado que depende dos componentes do PyPI será compatível com a " -"distribuição como um pacote Python instalável com ``pip``)." - -#: ../source/tutorials/managing-dependencies.rst:172 -msgid "" -"`hatch `_ for opinionated coverage of even " -"more steps in the project management workflow (such as incrementing " -"versions, tagging releases, and creating new skeleton projects from project " -"templates)" -msgstr "" -"`hatch `_ para uma cobertura opinativa de " -"ainda mais etapas no fluxo de trabalho de gerenciamento de projeto (como " -"incrementar versões, marcar lançamentos e criar novos projetos básicos a " -"partir de modelos de projeto)" - -#: ../source/tutorials/managing-dependencies.rst:175 -msgid "" -"`pip-tools `_ to build your own " -"custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" -msgstr "" -"`pip-tools `_ para construir seu " -"próprio fluxo de trabalho personalizado a partir de peças de nível inferior " -"como ``pip-compile`` e ``pip-sync``" - -#: ../source/tutorials/managing-dependencies.rst:177 -msgid "" -"`micropipenv `_ is a " -"lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry " -"lock files or converting them to pip-tools compatible output. Designed for " -"containerized Python applications but not limited to them." -msgstr "" -"micropipenv `_ é um invólucro " -"leve para pip para oferecer suporte a requirements.txt, arquivos de bloqueio " -"de Pipenv e de Poesia ou convertê-los em saída compatível com pip-tools. " -"Projetado para aplicações em contêineres Python, mas não se limitando a elas." - -#: ../source/tutorials/packaging-projects.rst:2 -msgid "Packaging Python Projects" -msgstr "Empacotando projetos Python" - -#: ../source/tutorials/packaging-projects.rst:4 -msgid "" -"This tutorial walks you through how to package a simple Python project. It " -"will show you how to add the necessary files and structure to create the " -"package, how to build the package, and how to upload it to the Python " -"Package Index." -msgstr "" -"Este tutorial mostra como empacotar um projeto Python simples. Ele mostrará " -"como adicionar os arquivos e a estrutura necessários para criar o pacote, " -"como construir o pacote e como enviá-lo para o Índice de Pacotes do Python." - -#: ../source/tutorials/packaging-projects.rst:10 -msgid "" -"If you have trouble running the commands in this tutoral, please copy the " -"command and its output, then `open an issue`_ on the `packaging-problems`_ " -"repository on GitHub. We'll do our best to help you!" -msgstr "" -"Se você tiver problemas para executar os comandos neste tutorial, copie o " -"comando e sua saída e, em seguida, `relate um problema`_ no repositório " -"`packaging-problems`_ no GitHub. Faremos o nosso melhor para ajudá-lo!" - -#: ../source/tutorials/packaging-projects.rst:18 -msgid "" -"Some of the commands require a newer version of :ref:`pip`, so start by " -"making sure you have the latest version installed:" -msgstr "" -"Alguns comandos exigem uma nova versão de :ref:`pip`, então comece " -"certificando-se de que você tenha a versão mais recente instalada:" - -#: ../source/tutorials/packaging-projects.rst:35 -msgid "A simple project" -msgstr "Um projeto simples" - -#: ../source/tutorials/packaging-projects.rst:37 -msgid "" -"This tutorial uses a simple project named ``example_package``. We recommend " -"following this tutorial as-is using this project, before packaging your own " -"project." -msgstr "" -"Este tutorial usa um projeto simples chamado ``example_package``. " -"Recomendamos seguir este tutorial como está usando este projeto, antes de " -"empacotar seu próprio projeto." - -#: ../source/tutorials/packaging-projects.rst:41 -msgid "Create the following file structure locally:" -msgstr "Crie a seguinte estrutura de arquivos localmente:" - -#: ../source/tutorials/packaging-projects.rst:51 -msgid "" -":file:`__init__.py` is required to import the directory as a package, and " -"should be empty." -msgstr "" -":file:`__init__.py` é necessário para importar o diretório como um pacote, e " -"deve estar vazio." - -#: ../source/tutorials/packaging-projects.rst:54 -msgid "" -":file:`example.py` is an example of a module within the package that could " -"contain the logic (functions, classes, constants, etc.) of your package. " -"Open that file and enter the following content:" -msgstr "" -":file:`example.py` é um exemplo de módulo dentro do pacote que pode conter a " -"lógica (funções, classes, constantes, etc.) do seu pacote. Abra esse arquivo " -"e insira o seguinte conteúdo:" - -#: ../source/tutorials/packaging-projects.rst:63 -msgid "" -"If you are unfamiliar with Python's :term:`modules ` and :term:" -"`import packages `, take a few minutes to read over the " -"`Python documentation for packages and modules`_." -msgstr "" -"Se você não está familiarizado com :term:`módulos ` e :term:`pacotes " -"de importação ` do Python, reserve alguns minutos para " -"ler a `documentação do Python para pacotes e módulos`_." - -#: ../source/tutorials/packaging-projects.rst:67 -msgid "" -"Once you create this structure, you'll want to run all of the commands in " -"this tutorial within the ``packaging_tutorial`` directory." -msgstr "" -"Depois de criar esta estrutura, você desejará executar todos os comandos " -"neste tutorial dentro do diretório ``packaging_tutorial``." - -#: ../source/tutorials/packaging-projects.rst:75 -msgid "Creating the package files" -msgstr "Criando arquivos do pacote" - -#: ../source/tutorials/packaging-projects.rst:77 -msgid "" -"You will now add files that are used to prepare the project for " -"distribution. When you're done, the project structure will look like this:" -msgstr "" -"Agora você adicionará arquivos que são usados para preparar o projeto para " -"distribuição. Quando terminar, a estrutura do projeto ficará assim:" - -#: ../source/tutorials/packaging-projects.rst:95 -msgid "Creating a test directory" -msgstr "Criando um diretório de teste" - -#: ../source/tutorials/packaging-projects.rst:97 -msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." -msgstr "" -":file:`tests/` é um espaço reservado, ou *placeholder*, para arquivos de " -"teste. Deixe-o vazio por enquanto." - -#: ../source/tutorials/packaging-projects.rst:101 -msgid "Creating pyproject.toml" -msgstr "Criando pyproject.toml" - -#: ../source/tutorials/packaging-projects.rst:103 -msgid "" -":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) " -"what is required to build your project. This tutorial uses :ref:" -"`setuptools`, so open :file:`pyproject.toml` and enter the following content:" -msgstr "" -":file:`pyproject.toml` informa as ferramentas de construção (como :ref:`pip` " -"e :ref:`build`) o que é necessário para construir seu projeto. Este tutorial " -"usa :ref:`setuptools`, então abra :file:`pyproject.toml` e insira o seguinte " -"conteúdo:" - -#: ../source/tutorials/packaging-projects.rst:117 -msgid "" -"``build-system.requires`` gives a list of packages that are needed to build " -"your package. Listing something here will *only* make it available during " -"the build, not after it is installed." -msgstr "" -"``build-system.requires`` fornece uma lista de pacotes que são necessários " -"para construir seu pacote. Listar algo aqui *apenas* o tornará disponível " -"durante a construção, não depois de instalado." - -#: ../source/tutorials/packaging-projects.rst:121 -msgid "" -"``build-system.build-backend`` is the name of Python object that will be " -"used to perform the build. If you were to use a different build system, such " -"as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration " -"details would be completely different than the :ref:`setuptools` " -"configuration described below." -msgstr "" -"``build-system.build-backend`` é o nome do objeto Python que será usado para " -"realizar a construção. Se você fosse usar um sistema de construção " -"diferente, como :ref:`flit` ou :ref:`poetry`, eles iriam aqui, e os detalhes " -"de configuração seriam completamente diferentes da configuração do :ref:" -"`setuptools` descrita abaixo." - -#: ../source/tutorials/packaging-projects.rst:127 -msgid "See :pep:`517` and :pep:`518` for background and details." -msgstr "Veja :pep:`517` e :pep:`518` para um informações e detalhes." - -#: ../source/tutorials/packaging-projects.rst:131 -msgid "Configuring metadata" -msgstr "Configurando metadados" - -#: ../source/tutorials/packaging-projects.rst:133 -msgid "There are two types of metadata: static and dynamic." -msgstr "Há dois tipos de metadados: estáticos e dinâmicos." - -#: ../source/tutorials/packaging-projects.rst:135 -msgid "" -"Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. " -"This is simpler, easier to read, and avoids many common errors, like " -"encoding errors." -msgstr "" -"Metadados estáticos (:file:`setup.cfg`): garantidamente os mesmos sempre. " -"Isso é mais simples, fácil de ler e evita muitos erros comuns, como erros de " -"codificação." - -#: ../source/tutorials/packaging-projects.rst:137 -msgid "" -"Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items " -"that are dynamic or determined at install-time, as well as extension modules " -"or extensions to setuptools, need to go into :file:`setup.py`." -msgstr "" -"Metadados dinâmicos (:file:`setup.py`): possivelmente não determinísticos. " -"Quaisquer itens que são dinâmicos ou determinados no momento da instalação, " -"bem como módulos de extensão ou extensões para setuptools, precisam ir para :" -"file:`setup.py`." - -#: ../source/tutorials/packaging-projects.rst:141 -msgid "" -"Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:" -"file:`setup.py`) should be used only as an escape hatch when absolutely " -"necessary. :file:`setup.py` used to be required, but can be omitted with " -"newer versions of setuptools and pip." -msgstr "" -"Metadados estáticos (:file:`setup.cfg`) devem ser preferidos. Metadados " -"dinâmicos (:file:`setup.py`) devem ser usados apenas como uma saída de " -"emergência quando for absolutamente necessário. :file:`setup.py` costumava " -"ser necessário, mas pode ser omitido com as versões mais recentes de " -"setuptools e pip." - -#: ../source/tutorials/packaging-projects.rst:148 -msgid "" -":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells " -"setuptools about your package (such as the name and version) as well as " -"which code files to include. Eventually much of this configuration may be " -"able to move to :file:`pyproject.toml`." -msgstr "" -":file:`setup.cfg` é o arquivo de configuração para :ref:`setuptools`. Ele " -"informa ao setuptools sobre o seu pacote (como o nome e a versão), bem como " -"os arquivos de código a serem incluídos. Eventualmente, grande parte desta " -"configuração pode ser movida para :file:`pyproject.toml`." - -#: ../source/tutorials/packaging-projects.rst:153 -msgid "" -"Open :file:`setup.cfg` and enter the following content. Change the ``name`` " -"to include your username; this ensures that you have a unique package name " -"and that your package doesn't conflict with packages uploaded by other " -"people following this tutorial." -msgstr "" -"Abra :file:`setup.cfg` e insira o seguinte conteúdo. Mude o ``name`` para " -"incluir seu nome de usuário; isso garante que você tenha um nome de pacote " -"exclusivo e que seu pacote não entre em conflito com os pacotes carregados " -"por outras pessoas que seguem este tutorial." - -#: ../source/tutorials/packaging-projects.rst:185 -msgid "" -"There are a `variety of metadata and options `_ supported here. This is " -"in :doc:`configparser ` format; do not place " -"quotes around values. This example package uses a relatively minimal set of " -"``metadata``:" -msgstr "" -"Há uma `variedade de metadados e opções `_ suportados aqui. Isso está no " -"formato :doc:`configparser `; não coloque aspas " -"em torno dos valores. Este pacote de exemplo usa um conjunto relativamente " -"mínimo de ``metadata``:" - -#: ../source/tutorials/packaging-projects.rst:191 -#: ../source/tutorials/packaging-projects.rst:286 -msgid "" -"``name`` is the *distribution name* of your package. This can be any name as " -"long as it only contains letters, numbers, ``_`` , and ``-``. It also must " -"not already be taken on pypi.org. **Be sure to update this with your " -"username,** as this ensures you won't try to upload a package with the same " -"name as one which already exists." -msgstr "" -"``name`` é o *nome da distribuição* do seu pacote. Pode ser qualquer nome, " -"desde que contenha apenas letras, números, ``_`` e ``-``. Também não deve " -"ser feito em pypi.org. **Certifique-se de atualizá-lo com seu nome de " -"usuário**, pois isso garante que você não tentará enviar um pacote com o " -"mesmo nome de um que já existe." - -#: ../source/tutorials/packaging-projects.rst:196 -msgid "" -"``version`` is the package version. See :pep:`440` for more details on " -"versions. You can use ``file:`` or ``attr:`` directives to read from a file " -"or package attribute." -msgstr "" -"``version`` é a versão do pacote. Consulte a :pep:`440` para obter mais " -"detalhes sobre as versões. Você pode usar as diretivas ``file:`` ou ``attr:" -"`` para ler um arquivo ou atributo de pacote." - -#: ../source/tutorials/packaging-projects.rst:199 -#: ../source/tutorials/packaging-projects.rst:293 -msgid "" -"``author`` and ``author_email`` are used to identify the author of the " -"package." -msgstr "" -"``author`` e ``author_email`` são usados para identificar o autor do pacote." - -#: ../source/tutorials/packaging-projects.rst:201 -#: ../source/tutorials/packaging-projects.rst:295 -msgid "``description`` is a short, one-sentence summary of the package." -msgstr "``description`` é um resumo curto do pacote contendo apenas uma frase." - -#: ../source/tutorials/packaging-projects.rst:202 -msgid "" -"``long_description`` is a detailed description of the package. This is shown " -"on the package detail page on the Python Package Index. In this case, the " -"long description is loaded from :file:`README.md` (which is a common " -"pattern) using the ``file:`` directive." -msgstr "" -"``long_description`` é uma descrição detalhada do pacote. Isso é mostrado na " -"página de detalhes do pacote no Índice do Pacotes Python. Neste caso, a " -"descrição longa é carregada de :file:`README.md` (que é um padrão comum) " -"usando a diretiva ``file:``." - -#: ../source/tutorials/packaging-projects.rst:206 -#: ../source/tutorials/packaging-projects.rst:300 -msgid "" -"``long_description_content_type`` tells the index what type of markup is " -"used for the long description. In this case, it's Markdown." -msgstr "" -"``long_description_content_type`` diz ao índice que tipo de marcação é usado " -"para a descrição longa. Neste caso, é Markdown." - -#: ../source/tutorials/packaging-projects.rst:208 -#: ../source/tutorials/packaging-projects.rst:302 -msgid "" -"``url`` is the URL for the homepage of the project. For many projects, this " -"will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting " -"service." -msgstr "" -"``url`` é a URL da página inicial do projeto. Para muitos projetos, será " -"apenas um link para GitHub, GitLab, Bitbucket ou serviço de hospedagem de " -"código semelhante." - -#: ../source/tutorials/packaging-projects.rst:211 -#: ../source/tutorials/packaging-projects.rst:305 -msgid "" -"``project_urls`` lets you list any number of extra links to show on PyPI. " -"Generally this could be to documentation, issue trackers, etc." -msgstr "" -"``project_urls`` permite listar qualquer número de links extras para mostrar " -"no PyPI. Geralmente, isso pode ser para documentação, rastreadores de " -"problemas, etc." - -#: ../source/tutorials/packaging-projects.rst:213 -#: ../source/tutorials/packaging-projects.rst:307 -msgid "" -"``classifiers`` gives the index and :ref:`pip` some additional metadata " -"about your package. In this case, the package is only compatible with Python " -"3, is licensed under the MIT license, and is OS-independent. You should " -"always include at least which version(s) of Python your package works on, " -"which license your package is available under, and which operating systems " -"your package will work on. For a complete list of classifiers, see https://" -"pypi.org/classifiers/." -msgstr "" -"``classifiers`` fornece o índice e :ref:`pip` alguns metadados adicionais " -"sobre seu pacote. Nesse caso, o pacote é compatível apenas com Python 3, " -"está licenciado sob a licença MIT e é independente do sistema operacional. " -"Você deve sempre incluir pelo menos a(s) versão(ões) do Python em que seu " -"pacote funciona, em que licença seu pacote está disponível e em quais " -"sistemas operacionais seu pacote funcionará. Para obter uma lista completa " -"de classificadores, consulte https://pypi.org/classifiers/." - -#: ../source/tutorials/packaging-projects.rst:221 -msgid "In the ``options`` category, we have controls for setuptools itself:" -msgstr "Na categoria ``options``, temos controles para o próprio setuptools:" - -#: ../source/tutorials/packaging-projects.rst:223 -msgid "" -"``package_dir`` is a mapping of package names and directories. An empty " -"package name represents the \"root package\" --- the directory in the " -"project that contains all Python source files for the package --- so in this " -"case the ``src`` directory is designated the root package." -msgstr "" -"``package_dir`` é um mapeamento de nomes e diretórios de pacotes. Um nome de " -"pacote vazio representa o \"pacote raiz\" -- o diretório no projeto que " -"contém todos os arquivos fonte Python para o pacote -- então, neste caso, o " -"diretório ``src`` é designado o pacote raiz." - -#: ../source/tutorials/packaging-projects.rst:227 -msgid "" -"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " -"`. Instead of listing each package manually, we can " -"use the ``find:`` directive to automatically discover all packages and " -"subpackages and ``options.packages.find`` to specify the ``package_dir`` to " -"use. In this case, the list of packages will be ``example_package`` as " -"that's the only package present." -msgstr "" -"``packages`` é uma lista de todos os Python :term:`pacotes de importação " -"` que devem ser incluídos no :term:`pacote de " -"distribuição `. Em vez de listar cada pacote " -"manualmente, podemos usar a diretiva ``find:`` para descobrir " -"automaticamente todos os pacotes e subpacotes e ``options.packages.find`` " -"para especificar o ``package_dir`` a ser usado. Neste caso, a lista de " -"pacotes será ``example_package`` visto que é o único pacote presente." - -#: ../source/tutorials/packaging-projects.rst:234 -msgid "" -"``python_requires`` gives the versions of Python supported by your project. " -"Installers like :ref:`pip` will look back through older versions of packages " -"until it finds one that has a matching Python version." -msgstr "" -"``python_requires`` fornece as versões do Python suportadas pelo seu " -"projeto. Instaladores como :ref:`pip` olharão para as versões anteriores dos " -"pacotes até encontrar um que tenha uma versão correspondente do Python." - -#: ../source/tutorials/packaging-projects.rst:238 -#: ../source/tutorials/packaging-projects.rst:329 -msgid "" -"There are many more than the ones mentioned here. See :doc:`/guides/" -"distributing-packages-using-setuptools` for more details." -msgstr "" -"Existem muitos mais do que os mencionados aqui. Veja :doc:`/guides/" -"distributing-packages-using-setuptools` para mais detalhes." - -#: ../source/tutorials/packaging-projects.rst:244 -msgid "" -":file:`setup.py` is the build script for :ref:`setuptools`. It tells " -"setuptools about your package (such as the name and version) as well as " -"which code files to include." -msgstr "" -":file:`setup.py` é o script de construção para :ref:`setuptools`. Ele " -"informa ao setuptools sobre o seu pacote (como o nome e a versão), bem como " -"os arquivos de código a serem incluídos." - -#: ../source/tutorials/packaging-projects.rst:248 -msgid "" -"Open :file:`setup.py` and enter the following content. Change the ``name`` " -"to include your username; this ensures that you have a unique package name " -"and that your package doesn't conflict with packages uploaded by other " -"people following this tutorial." -msgstr "" -"Abra :file:`setup.py` e insira o seguinte conteúdo. Mude o ``name`` para " -"incluir seu nome de usuário; isso garante que você tenha um nome de pacote " -"exclusivo e que seu pacote não entre em conflito com os pacotes carregados " -"por outras pessoas que seguem este tutorial." - -#: ../source/tutorials/packaging-projects.rst:283 -msgid "" -":func:`setup` takes several arguments. This example package uses a " -"relatively minimal set:" -msgstr "" -":func:`setup` recebe vários argumentos. Este pacote de exemplo usa um " -"conjunto relativamente mínimo:" - -#: ../source/tutorials/packaging-projects.rst:291 -msgid "" -"``version`` is the package version. See :pep:`440` for more details on " -"versions." -msgstr "" -"``version`` é a versão do pacote. Consulte :pep:`440` para obter mais " -"detalhes sobre as versões." - -#: ../source/tutorials/packaging-projects.rst:296 -msgid "" -"``long_description`` is a detailed description of the package. This is shown " -"on the package detail page on the Python Package Index. In this case, the " -"long description is loaded from :file:`README.md`, which is a common pattern." -msgstr "" -"``long_description`` é uma descrição detalhada do pacote. Isso é mostrado na " -"página de detalhes do pacote no Índice do Pacotes do Python. Neste caso, a " -"descrição longa é carregada de :file:`README.md`, que é um padrão comum." - -#: ../source/tutorials/packaging-projects.rst:314 -msgid "" -"``package_dir`` is a dictionary with package names for keys and directories " -"for values. An empty package name represents the \"root package\" --- the " -"directory in the project that contains all Python source files for the " -"package --- so in this case the ``src`` directory is designated the root " -"package." -msgstr "" -"``package_dir`` é um dicionário com nomes de pacotes para chaves e " -"diretórios para valores. Um nome de pacote vazio representa o \"pacote raiz" -"\" -- o diretório no projeto que contém todos os arquivos fonte Python para " -"o pacote -- então, neste caso, o diretório ``src`` é designado o pacote raiz." - -#: ../source/tutorials/packaging-projects.rst:319 -msgid "" -"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " -"`. Instead of listing each package manually, we can " -"use :func:`find_packages` to automatically discover all packages and " -"subpackages under ``package_dir``. In this case, the list of packages will " -"be ``example_package`` as that's the only package present." -msgstr "" -"``packages`` é uma lista de todos os :term:`pacotes de importação ` do Python que devem ser incluídos no :term:`pacote de " -"distribuição `. Em vez de listar cada pacote " -"manualmente, podemos usar :func:`find_packages` para descobrir " -"automaticamente todos os pacotes e subpacotes em ``package_dir``. Neste " -"caso, a lista de pacotes será ``example_package`` visto que é o único pacote " -"presente." - -#: ../source/tutorials/packaging-projects.rst:325 -msgid "" -"``python_requires`` gives the versions of Python supported by your project. " -"Installers like :ref:`pip` will look back though older versions of packages " -"until it finds one that has a matching Python version." -msgstr "" -"``python_requires`` fornece as versões do Python suportadas pelo seu " -"projeto. Instaladores como :ref:`pip` olharão para as versões anteriores dos " -"pacotes até encontrar um que tenha uma versão correspondente do Python." - -#: ../source/tutorials/packaging-projects.rst:333 -msgid "Creating README.md" -msgstr "Criando README.md" - -#: ../source/tutorials/packaging-projects.rst:335 -msgid "" -"Open :file:`README.md` and enter the following content. You can customize " -"this if you'd like." -msgstr "" -"Abra :file:`README.md` e insira o seguinte conteúdo. Você pode personalizar " -"isso se desejar." - -#: ../source/tutorials/packaging-projects.rst:347 -msgid "" -"Because our configuration loads :file:`README.md` to provide a " -"``long_description``, :file:`README.md` must be included along with your " -"code when you :ref:`generate a source distribution `. " -"Newer versions of :ref:`setuptools` will do this automatically." -msgstr "" -"Porque nossa configuração carrega :file:`README.md` para fornecer um " -"``long_description``, :file:`README.md` deve ser incluído junto com seu " -"código quando você :ref:`gerar uma distribuição fonte `. Versões mais recentes de :ref:`setuptools` farão isso " -"automaticamente." - -#: ../source/tutorials/packaging-projects.rst:354 -msgid "Creating a LICENSE" -msgstr "Criando um LICENSE" - -#: ../source/tutorials/packaging-projects.rst:356 -msgid "" -"It's important for every package uploaded to the Python Package Index to " -"include a license. This tells users who install your package the terms under " -"which they can use your package. For help picking a license, see https://" -"choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` " -"and enter the license text. For example, if you had chosen the MIT license:" -msgstr "" -"É importante que cada pacote enviado para o Índice de Pacotes do Python " -"inclua uma licença. Isso informa aos usuários que instalam seu pacote os " -"termos sob os quais eles podem usá-lo. Para obter ajuda na escolha de uma " -"licença, consulte https://choosealicense.com/. Depois de escolher uma " -"licença, abra :file:`LICENSE` e digite o texto da licença. Por exemplo, se " -"você escolheu a licença MIT:" - -#: ../source/tutorials/packaging-projects.rst:387 -msgid "Including other files" -msgstr "Incluindo outros arquivos" - -#: ../source/tutorials/packaging-projects.rst:389 -msgid "" -"The files listed above will be included automatically in your :term:`source " -"distribution `. If you want to control " -"what goes in this explicitly, see :ref:`Using MANIFEST.in`." -msgstr "" -"Os arquivos listados acima serão incluídos automaticamente em sua :term:" -"`distribuição fonte `. Se você deseja " -"controlar o que entra explicitamente, consulte :ref:`Using MANIFEST.in`." - -#: ../source/tutorials/packaging-projects.rst:393 -msgid "" -"The final :term:`built distribution ` will have the " -"Python files in the discovered or listed Python packages. If you want to " -"control what goes here, such as to add data files, see :doc:`Including Data " -"Files ` from the :doc:`setuptools docs " -"`." -msgstr "" -"A :term:`distribuição construída ` final terá os " -"arquivos Python nos pacotes descobertos ou listados Python. Se você deseja " -"controlar o que acontece aqui, como adicionar arquivos de dados, consulte " -":doc:`Incluindo Arquivos de Dados ` da :doc:`" -"documentação do setuptools `." - -#: ../source/tutorials/packaging-projects.rst:402 -msgid "Generating distribution archives" -msgstr "Gerando arquivos de distribuição" - -#: ../source/tutorials/packaging-projects.rst:404 -msgid "" -"The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the " -"Python Package Index and can be installed by :ref:`pip`." -msgstr "" -"O próximo passo é gerar :term:`pacotes de distribuição ` para o pacote. Estes são arquivos que são enviados para o " -"Índice de Pacotes do Python e podem ser instalados pelo :ref:`pip`." - -#: ../source/tutorials/packaging-projects.rst:408 -msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" -msgstr "" -"Certifique-se de que você tenha a versão mais recente da :ref:`construção " -"` do PyPA instalada:" - -#: ../source/tutorials/packaging-projects.rst:422 -msgid "" -"If you have trouble installing these, see the :doc:`installing-packages` " -"tutorial." -msgstr "" -"Se você tiver problemas ao instalá-los, veja o tutorial :doc:`installing-" -"packages`." - -#: ../source/tutorials/packaging-projects.rst:425 -msgid "" -"Now run this command from the same directory where :file:`pyproject.toml` is " -"located:" -msgstr "" -"Agora, execute este comando a partir do mesmo diretório no qual :file:" -"`pyproject.toml` está localizado:" - -#: ../source/tutorials/packaging-projects.rst:439 -msgid "" -"This command should output a lot of text and once completed should generate " -"two files in the :file:`dist` directory:" -msgstr "" -"Este comando deve produzir muito texto e, uma vez concluído, deve gerar dois " -"arquivos no diretório :file:`dist`:" - -#: ../source/tutorials/packaging-projects.rst:449 -msgid "" -"The ``tar.gz`` file is a :term:`source archive ` whereas the " -"``.whl`` file is a :term:`built distribution `. Newer :" -"ref:`pip` versions preferentially install built distributions, but will fall " -"back to source archives if needed. You should always upload a source archive " -"and provide built archives for the platforms your project is compatible " -"with. In this case, our example package is compatible with Python on any " -"platform so only one built distribution is needed." -msgstr "" -"O arquivo ``tar.gz`` é um :term:`arquivo fonte ` enquanto o " -"arquivo ``.whl`` é uma :term:`distribuição construída `. As versões :ref:`pip` mais recentes instalam preferencialmente " -"distribuições construídas, mas irão recorrer aos arquivos fonte se " -"necessário. Você deve sempre enviar um arquivo fonte e fornecer arquivos " -"construídos para as plataformas com as quais seu projeto é compatível. Neste " -"caso, nosso pacote de exemplo é compatível com Python em qualquer " -"plataforma, portanto, apenas uma distribuição construída é necessária." - -#: ../source/tutorials/packaging-projects.rst:458 -msgid "Uploading the distribution archives" -msgstr "Enviando os arquivos de distribuição" - -#: ../source/tutorials/packaging-projects.rst:460 -msgid "Finally, it's time to upload your package to the Python Package Index!" -msgstr "" -"Finalmente, é hora de enviar seu pacote para o Índice de Pacotes do Python!" - -#: ../source/tutorials/packaging-projects.rst:462 -msgid "" -"The first thing you'll need to do is register an account on TestPyPI, which " -"is a separate instance of the package index intended for testing and " -"experimentation. It's great for things like this tutorial where we don't " -"necessarily want to upload to the real index. To register an account, go to " -"https://test.pypi.org/account/register/ and complete the steps on that page. " -"You will also need to verify your email address before you're able to upload " -"any packages. For more details, see :doc:`/guides/using-testpypi`." -msgstr "" -"A primeira coisa que você precisa fazer é registrar uma conta no Test PyPI, " -"que é uma instância separada do índice do pacote destinada a teste e " -"experimentação. É ótimo para coisas como este tutorial, em que não queremos " -"necessariamente enviar para o índice real. Para registrar uma conta, vá em " -"https://test.pypi.org/account/register/ e conclua as etapas nessa página. " -"Você também precisará verificar seu endereço de e-mail antes de enviar " -"qualquer pacote. Para mais detalhes, veja :doc:`/guides/using-testpypi`." - -#: ../source/tutorials/packaging-projects.rst:470 -msgid "" -"To securely upload your project, you'll need a PyPI `API token`_. Create one " -"at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" " -"to \"Entire account\". **Don't close the page until you have copied and " -"saved the token — you won't see that token again.**" -msgstr "" -"Para enviar seu projeto com segurança, você precisará de um `token de API`_ " -"do PyPI. Crie um em https://test.pypi.org/manage/account/#api-tokens, " -"definindo o \"Escopo\" como \"Toda a conta\". **Não feche a página antes de " -"copiar e salvar o token -- você não verá o token novamente.**" - -#: ../source/tutorials/packaging-projects.rst:477 -msgid "" -"Now that you are registered, you can use :ref:`twine` to upload the " -"distribution packages. You'll need to install Twine:" -msgstr "" -"Agora que você está registrado, você pode usar :ref:`twine` para enviar os " -"pacotes de distribuição. Você precisará instalar o Twine:" - -#: ../source/tutorials/packaging-projects.rst:492 -msgid "" -"Once installed, run Twine to upload all of the archives under :file:`dist`:" -msgstr "" -"Uma vez instalado, execute o Twine para enviar de todos os arquivos em :file:" -"`dist`:" - -#: ../source/tutorials/packaging-projects.rst:506 -msgid "" -"You will be prompted for a username and password. For the username, use " -"``__token__``. For the password, use the token value, including the ``pypi-" -"`` prefix." -msgstr "" -"Você será solicitado a fornecer um nome de usuário e uma senha. Para o nome " -"de usuário, use ``__token__``. Para a senha, use o valor do token, incluindo " -"o prefixo ``pypi-``." - -#: ../source/tutorials/packaging-projects.rst:510 -msgid "After the command completes, you should see output similar to this:" -msgstr "" -"Depois que o comando for concluído, você deverá ver uma saída semelhante a " -"esta:" - -#: ../source/tutorials/packaging-projects.rst:523 -msgid "" -"Once uploaded your package should be viewable on TestPyPI, for example, " -"https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" -msgstr "" -"Depois de enviado, seu pacote pode ser visto no Test PyPI, por exemplo, em " -"https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" - -#: ../source/tutorials/packaging-projects.rst:528 -msgid "Installing your newly uploaded package" -msgstr "Instalando seu pacote recém-enviado" - -#: ../source/tutorials/packaging-projects.rst:530 -msgid "" -"You can use :ref:`pip` to install your package and verify that it works. " -"Create a :ref:`virtual environment ` and install your package from TestPyPI:" -msgstr "" -"Você pode usar o :ref:`pip` para instalar seu pacote e verificar se ele " -"funciona. Crie um :ref:`ambiente virtual ` e instale seu pacote a partir do Test PyPI:" - -#: ../source/tutorials/packaging-projects.rst:546 -msgid "Make sure to specify your username in the package name!" -msgstr "Certifique-se de especificar seu nome de usuário no nome do pacote!" - -#: ../source/tutorials/packaging-projects.rst:548 -msgid "" -"pip should install the package from TestPyPI and the output should look " -"something like this:" -msgstr "" -"pip deve instalar o pacote de Test PyPI e a saída deve ser semelhante a esta:" - -#: ../source/tutorials/packaging-projects.rst:558 -msgid "" -"This example uses ``--index-url`` flag to specify TestPyPI instead of live " -"PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have " -"the same packages as the live PyPI, it's possible that attempting to install " -"dependencies may fail or install something unexpected. While our example " -"package doesn't have any dependencies, it's a good practice to avoid " -"installing dependencies when using TestPyPI." -msgstr "" -"Este exemplo usa o sinalizador ``--index-url`` para especificar Test PyPI em " -"vez do PyPI real. Além disso, ele especifica ``--no-deps``. Como o Test PyPI " -"não tem os mesmos pacotes que o PyPI real, é possível que a tentativa de " -"instalação de dependências falhe ou instale algo inesperado. Embora nosso " -"pacote de exemplo não tenha nenhuma dependência, é uma boa prática evitar " -"instalar dependências ao usar o Test PyPI." - -#: ../source/tutorials/packaging-projects.rst:565 -msgid "" -"You can test that it was installed correctly by importing the package. Make " -"sure you're still in your virtual environment, then run Python:" -msgstr "" -"Você pode testar se ele foi instalado corretamente importando o pacote. " -"Certifique-se de que ainda está em seu ambiente virtual e execute o Python:" - -#: ../source/tutorials/packaging-projects.rst:580 -msgid "and import the package:" -msgstr "e importe o pacote:" - -#: ../source/tutorials/packaging-projects.rst:588 -msgid "" -"Note that the :term:`import package ` is ``example_package`` " -"regardless of what ``name`` you gave your :term:`distribution package " -"` in :file:`setup.cfg` or :file:`setup.py` (in this " -"case, ``example-pkg-YOUR-USERNAME-HERE``)." -msgstr "" -"Note que o :term:`pacote de importação ` é " -"``example_package`` independente de qual ``name`` você deu ao seu :term:" -"`pacote de distribuição ` no :file:`setup.cfg` ou :" -"file:`setup.py` (neste caso, ``example-pkg-YOUR-USERNAME-HERE``)." - -#: ../source/tutorials/packaging-projects.rst:596 -msgid "" -"**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" -msgstr "**Parabéns, você empacotou e distribuiu um projeto Python!** ✨ 🍰 ✨" - -#: ../source/tutorials/packaging-projects.rst:599 -msgid "" -"Keep in mind that this tutorial showed you how to upload your package to " -"Test PyPI, which isn't a permanent storage. The Test system occasionally " -"deletes packages and accounts. It is best to use TestPyPI for testing and " -"experiments like this tutorial." -msgstr "" -"Lembre-se de que este tutorial mostrou como enviar o seu pacote para Test " -"PyPI, que não é um armazenamento permanente. O sistema de teste " -"ocasionalmente exclui pacotes e contas. É melhor usar Test PyPI para testes " -"e experimentos como este tutorial." - -#: ../source/tutorials/packaging-projects.rst:604 -msgid "" -"When you are ready to upload a real package to the Python Package Index you " -"can do much the same as you did in this tutorial, but with these important " -"differences:" -msgstr "" -"Quando estiver pronto para carregar um pacote real para o Índice de Pacotes " -"do Python, você pode fazer quase o mesmo que fez neste tutorial, mas com " -"estas diferenças importantes:" - -#: ../source/tutorials/packaging-projects.rst:608 -msgid "" -"Choose a memorable and unique name for your package. You don't have to " -"append your username as you did in the tutorial." -msgstr "" -"Escolha um nome único e memorável para o seu pacote. Você não precisa " -"acrescentar seu nome de usuário como fez no tutorial." - -#: ../source/tutorials/packaging-projects.rst:610 -msgid "" -"Register an account on https://pypi.org - note that these are two separate " -"servers and the login details from the test server are not shared with the " -"main server." -msgstr "" -"Registre uma conta em https://pypi.org -- observe que esses são dois " -"servidores separados e os detalhes de login do servidor de teste não são " -"compartilhados com o servidor principal." - -#: ../source/tutorials/packaging-projects.rst:613 -msgid "" -"Use ``twine upload dist/*`` to upload your package and enter your " -"credentials for the account you registered on the real PyPI. Now that " -"you're uploading the package in production, you don't need to specify ``--" -"repository``; the package will upload to https://pypi.org/ by default." -msgstr "" -"Use ``twine upload dist/*`` para enviar seu pacote e insira suas credenciais " -"para a conta que você registrou no PyPI real. Agora que você está enviando o " -"pacote em produção, você não precisa especificar ``--repository``; o pacote " -"será enviado para https://pypi.org/ por padrão." - -#: ../source/tutorials/packaging-projects.rst:617 -msgid "" -"Install your package from the real PyPI using ``python3 -m pip install [your-" -"package]``." -msgstr "" -"Instale seu pacote a partir do PyPI real usando ``python3 -m pip install " -"[seu-pacote]``." - -#: ../source/tutorials/packaging-projects.rst:619 -msgid "" -"At this point if you want to read more on packaging Python libraries here " -"are some things you can do:" -msgstr "" -"Neste ponto, se você quiser ler mais sobre o empacotamento de bibliotecas " -"Python, aqui estão algumas coisas que você pode fazer:" - -#: ../source/tutorials/packaging-projects.rst:622 -msgid "" -"Read more about using :ref:`setuptools` to package libraries in :doc:`/" -"guides/distributing-packages-using-setuptools`." -msgstr "" -"Leia mais sobre como usar :ref:`setuptools` para empacotar bibliotecas em :" -"doc:`/guides/distributing-packages-using-setuptools`." - -#: ../source/tutorials/packaging-projects.rst:624 -msgid "Read about :doc:`/guides/packaging-binary-extensions`." -msgstr "Leia sobre :doc:`/guides/packaging-binary-extensions`." - -#: ../source/tutorials/packaging-projects.rst:625 -msgid "" -"Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:" -"`hatch`, and :ref:`poetry`." -msgstr "" -"Considere alternativas ao :ref:`setuptools`, tal como :ref:`flit`, :ref:" -"`hatch` e :ref:`poetry`." diff --git a/locales/ro/LC_MESSAGES/messages.po b/locales/ro/LC_MESSAGES/messages.po deleted file mode 100644 index 1f5d56835..000000000 --- a/locales/ro/LC_MESSAGES/messages.po +++ /dev/null @@ -1,9257 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2013–2020, PyPA -# This file is distributed under the same license as the Python Packaging User Guide package. -# GUILHERME FERNANDES NETO , 2021. -msgid "" -msgstr "" -"Project-Id-Version: Python Packaging User Guide\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-08-20 01:32+0000\n" -"Last-Translator: GUILHERME FERNANDES NETO \n" -"Language-Team: Romanian \n" -"Language: ro\n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=UTF-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Plural-Forms: nplurals=3; plural=n==1 ? 0 : (n==0 || (n%100 > 0 && n%100 < " -"20)) ? 1 : 2;\n" -"X-Generator: Weblate 4.8-dev\n" - -#: ../source/contribute.rst:5 -msgid "Contribute to this guide" -msgstr "" - -#: ../source/contribute.rst:7 -msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" -msgstr "" - -#: ../source/contribute.rst:10 -msgid "Reading the guide and giving feedback" -msgstr "" - -#: ../source/contribute.rst:11 -msgid "Reviewing new contributions" -msgstr "" - -#: ../source/contribute.rst:12 -msgid "Revising existing content" -msgstr "" - -#: ../source/contribute.rst:13 -msgid "Writing new content" -msgstr "" - -#: ../source/contribute.rst:15 -msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." -msgstr "" - -#: ../source/contribute.rst:24 -msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." -msgstr "" - -#: ../source/contribute.rst:31 -msgid "Documentation types" -msgstr "" - -#: ../source/contribute.rst:33 -msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." -msgstr "" - -#: ../source/contribute.rst:38 -#: ../source/tutorials/index.rst:2 -msgid "Tutorials" -msgstr "" - -#: ../source/contribute.rst:40 -msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." -msgstr "" - -#: ../source/contribute.rst:47 -#: ../source/guides/index.rst:2 -msgid "Guides" -msgstr "" - -#: ../source/contribute.rst:49 -msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." -msgstr "" - -#: ../source/contribute.rst:56 -#: ../source/discussions/index.rst:2 -msgid "Discussions" -msgstr "" - -#: ../source/contribute.rst:58 -msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." -msgstr "" - -#: ../source/contribute.rst:63 -msgid "Specifications" -msgstr "" - -#: ../source/contribute.rst:65 -msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." -msgstr "" - -#: ../source/contribute.rst:73 -msgid "Building the guide locally" -msgstr "" - -#: ../source/contribute.rst:75 -msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" -msgstr "" - -#: ../source/contribute.rst:79 -msgid "`Nox `_. You can install or upgrade nox using ``pip``::" -msgstr "" - -#: ../source/contribute.rst:84 -msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." -msgstr "" - -#: ../source/contribute.rst:91 -msgid "To build the guide, run the following bash command in the source folder::" -msgstr "" - -#: ../source/contribute.rst:95 -msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." -msgstr "" - -#: ../source/contribute.rst:100 -msgid "You can build the guide and serve it via an HTTP server using the following command::" -msgstr "" - -#: ../source/contribute.rst:105 -msgid "The guide will be browsable via http://localhost:8000." -msgstr "" - -#: ../source/contribute.rst:109 -msgid "Where the guide is deployed" -msgstr "" - -#: ../source/contribute.rst:111 -msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." -msgstr "" - -#: ../source/contribute.rst:117 -msgid "Style guide" -msgstr "" - -#: ../source/contribute.rst:119 -msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." -msgstr "" - -#: ../source/contribute.rst:126 -msgid "Purpose" -msgstr "" - -#: ../source/contribute.rst:128 -msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." -msgstr "" - -#: ../source/contribute.rst:133 -msgid "Scope" -msgstr "" - -#: ../source/contribute.rst:135 -msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." -msgstr "" - -#: ../source/contribute.rst:138 -msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." -msgstr "" - -#: ../source/contribute.rst:146 -msgid "Audience" -msgstr "" - -#: ../source/contribute.rst:148 -msgid "The audience of this guide is anyone who uses Python with packages." -msgstr "" - -#: ../source/contribute.rst:150 -msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." -msgstr "" - -#: ../source/contribute.rst:154 -msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." -msgstr "" - -#: ../source/contribute.rst:160 -msgid "Voice and tone" -msgstr "" - -#: ../source/contribute.rst:162 -msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." -msgstr "" - -#: ../source/contribute.rst:165 -msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." -msgstr "" - -#: ../source/contribute.rst:170 -msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." -msgstr "" - -#: ../source/contribute.rst:177 -msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." -msgstr "" - -#: ../source/contribute.rst:184 -msgid "Conventions and mechanics" -msgstr "" - -#: ../source/contribute.rst:192 -msgid "**Write to the reader**" -msgstr "" - -#: ../source/contribute.rst:187 -msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: To install it, the user runs…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: You can install it by running…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: To install it, run…" -msgstr "" - -#: ../source/contribute.rst:198 -msgid "**State assumptions**" -msgstr "" - -#: ../source/contribute.rst:195 -msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." -msgstr "" - -#: ../source/contribute.rst:203 -msgid "**Cross-reference generously**" -msgstr "" - -#: ../source/contribute.rst:201 -msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." -msgstr "" - -#: ../source/contribute.rst:213 -msgid "**Respect naming practices**" -msgstr "" - -#: ../source/contribute.rst:206 -msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: Pip uses…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: pip uses…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: …hosted on github." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: …hosted on GitHub." -msgstr "" - -#: ../source/contribute.rst:222 -msgid "**Use a gender-neutral style**" -msgstr "" - -#: ../source/contribute.rst:216 -msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: A maintainer uploads the file. Then he…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then they…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then the maintainer…" -msgstr "" - -#: ../source/contribute.rst:234 -msgid "**Headings**" -msgstr "" - -#: ../source/contribute.rst:225 -msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." -msgstr "" - -#: ../source/contribute.rst:230 -msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: Things You Should Know About Python" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: Things you should know about Python" -msgstr "" - -#: ../source/contribute.rst:237 -msgid "**Numbers**" -msgstr "" - -#: ../source/contribute.rst:237 -msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:4 -msgid "Deploying Python applications" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Page Status" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:6 -#: ../source/guides/index-mirrors-and-caches.rst:7 -#: ../source/guides/installing-using-linux-tools.rst:7 -#: ../source/guides/packaging-binary-extensions.rst:7 -#: ../source/guides/supporting-multiple-python-versions.rst:7 -#: ../source/guides/supporting-windows-using-appveyor.rst:5 -msgid "Incomplete" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Last Reviewed" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:7 -msgid "2014-11-11" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:11 -#: ../source/discussions/install-requires-vs-requirements.rst:9 -#: ../source/guides/analyzing-pypi-package-downloads.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:22 -#: ../source/guides/index-mirrors-and-caches.rst:12 -#: ../source/guides/installing-scientific-packages.rst:9 -#: ../source/guides/packaging-binary-extensions.rst:17 -#: ../source/guides/supporting-multiple-python-versions.rst:12 -#: ../source/guides/supporting-windows-using-appveyor.rst:15 -#: ../source/overview.rst:23 -#: ../source/specifications/core-metadata.rst:38 -#: ../source/specifications/direct-url.rst:14 -#: ../source/tutorials/installing-packages.rst:23 -msgid "Contents" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:14 -msgid "Overview" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:18 -msgid "Supporting multiple hardware platforms" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:40 -msgid "OS packaging & installers" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:52 -msgid "Windows" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:61 -msgid "Pynsist" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:63 -msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:70 -msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:74 -msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:80 -msgid "Application bundles" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:91 -msgid "Configuration management" -msgstr "" - -#: ../source/discussions/index.rst:4 -msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:5 -msgid "install_requires vs requirements files" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:382 -msgid "install_requires" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:14 -msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:19 -msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:29 -msgid "Additionally, it's best practice to indicate any known lower or upper bounds." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:31 -msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:41 -msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:51 -msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:56 -msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:64 -#: ../source/tutorials/installing-packages.rst:460 -msgid "Requirements files" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:66 -msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:69 -msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:73 -msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:78 -msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:84 -msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:90 -msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:6 -msgid "pip vs easy_install" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:9 -msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:14 -msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:22 -msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**pip**" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**easy_install**" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -msgid "Installs from :term:`Wheels `" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Yes" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:30 -#: ../source/discussions/pip-vs-easy-install.rst:32 -#: ../source/discussions/pip-vs-easy-install.rst:35 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:51 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "No" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Uninstall Packages" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Yes (``python -m pip uninstall``)" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Dependency Overrides" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Yes (:ref:`Requirements Files `)" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "List Installed Packages" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:38 -msgid ":pep:`438` Support" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Installation format" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "'Flat' packages with :file:`egg-info` metadata." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Encapsulated Egg format" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:44 -msgid "sys.path modification" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:48 -msgid "Installs from :term:`Eggs `" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "`pylauncher support`_" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "Yes [1]_" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:54 -msgid ":ref:`Multi-version Installs`" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Exclude scripts during install" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "per project index" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Only in virtualenv" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Yes, via setup.cfg" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:68 -msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:5 -msgid "Wheel vs Egg" -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:7 -msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:11 -msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:14 -msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:17 -msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:20 -msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:22 -msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:26 -msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:31 -msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:34 -msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:38 -msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:41 -msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:47 -msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." -msgstr "" - -#: ../source/glossary.rst:3 -msgid "Glossary" -msgstr "" - -#: ../source/glossary.rst:8 -msgid "Binary Distribution" -msgstr "" - -#: ../source/glossary.rst:11 -msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." -msgstr "" - -#: ../source/glossary.rst:14 -msgid "Built Distribution" -msgstr "" - -#: ../source/glossary.rst:17 -msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." -msgstr "" - -#: ../source/glossary.rst:26 -msgid "Distribution Package" -msgstr "" - -#: ../source/glossary.rst:29 -msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." -msgstr "" - -#: ../source/glossary.rst:34 -msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." -msgstr "" - -#: ../source/glossary.rst:41 -msgid "Egg" -msgstr "" - -#: ../source/glossary.rst:44 -msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" -msgstr "" - -#: ../source/glossary.rst:49 -msgid "Extension Module" -msgstr "" - -#: ../source/glossary.rst:52 -msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." -msgstr "" - -#: ../source/glossary.rst:59 -msgid "Known Good Set (KGS)" -msgstr "" - -#: ../source/glossary.rst:62 -msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." -msgstr "" - -#: ../source/glossary.rst:68 -msgid "Import Package" -msgstr "" - -#: ../source/glossary.rst:71 -msgid "A Python module which can contain other modules or recursively, other packages." -msgstr "" - -#: ../source/glossary.rst:74 -msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." -msgstr "" - -#: ../source/glossary.rst:78 -msgid "Module" -msgstr "" - -#: ../source/glossary.rst:81 -msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." -msgstr "" - -#: ../source/glossary.rst:84 -msgid "Package Index" -msgstr "" - -#: ../source/glossary.rst:87 -msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." -msgstr "" - -#: ../source/glossary.rst:90 -msgid "Per Project Index" -msgstr "Pe Indexul Proiectului" - -#: ../source/glossary.rst:93 -msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." -msgstr "" - -#: ../source/glossary.rst:97 -msgid "Project" -msgstr "" - -#: ../source/glossary.rst:100 -msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." -msgstr "" - -#: ../source/glossary.rst:104 -msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." -msgstr "" - -#: ../source/glossary.rst:110 -msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." -msgstr "" - -#: ../source/glossary.rst:115 -msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." -msgstr "" - -#: ../source/glossary.rst:121 -msgid "Pure Module" -msgstr "Modul Pur" - -#: ../source/glossary.rst:124 -msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." -msgstr "" - -#: ../source/glossary.rst:127 -msgid "Python Packaging Authority (PyPA)" -msgstr "" - -#: ../source/glossary.rst:130 -msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." -msgstr "" - -#: ../source/glossary.rst:139 -msgid "Python Package Index (PyPI)" -msgstr "" - -#: ../source/glossary.rst:142 -msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." -msgstr "" - -#: ../source/glossary.rst:145 -msgid "pypi.org" -msgstr "" - -#: ../source/glossary.rst:148 -msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." -msgstr "" - -#: ../source/glossary.rst:152 -msgid "pyproject.toml" -msgstr "" - -#: ../source/glossary.rst:155 -msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." -msgstr "" - -#: ../source/glossary.rst:157 -msgid "Release" -msgstr "" - -#: ../source/glossary.rst:160 -msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." -msgstr "" - -#: ../source/glossary.rst:163 -msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." -msgstr "" - -#: ../source/glossary.rst:168 -msgid "Requirement" -msgstr "" - -#: ../source/glossary.rst:171 -msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." -msgstr "" - -#: ../source/glossary.rst:177 -msgid "Requirement Specifier" -msgstr "Specificator Cerință" - -#: ../source/glossary.rst:180 -msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" -msgstr "" - -#: ../source/glossary.rst:187 -msgid "Requirements File" -msgstr "" - -#: ../source/glossary.rst:190 -msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." -msgstr "" - -#: ../source/glossary.rst:194 -#: ../source/guides/distributing-packages-using-setuptools.rst:56 -msgid "setup.py" -msgstr "" - -#: ../source/glossary.rst:195 -#: ../source/guides/distributing-packages-using-setuptools.rst:77 -msgid "setup.cfg" -msgstr "" - -#: ../source/glossary.rst:198 -msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." -msgstr "" - -#: ../source/glossary.rst:201 -msgid "Source Archive" -msgstr "" - -#: ../source/glossary.rst:204 -msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:208 -msgid "Source Distribution (or \"sdist\")" -msgstr "" - -#: ../source/glossary.rst:211 -msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:216 -msgid "System Package" -msgstr "" - -#: ../source/glossary.rst:219 -msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." -msgstr "" - -#: ../source/glossary.rst:222 -msgid "Version Specifier" -msgstr "" - -#: ../source/glossary.rst:225 -msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." -msgstr "" - -#: ../source/glossary.rst:231 -msgid "Virtual Environment" -msgstr "" - -#: ../source/glossary.rst:234 -msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/glossary.rst:238 -msgid "Wheel" -msgstr "" - -#: ../source/glossary.rst:241 -msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." -msgstr "" - -#: ../source/glossary.rst:244 -msgid "Working Set" -msgstr "" - -#: ../source/glossary.rst:247 -msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:3 -msgid "Analyzing PyPI package downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:5 -msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:15 -#: ../source/guides/supporting-windows-using-appveyor.rst:18 -msgid "Background" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:17 -msgid "PyPI does not display download statistics for a number of reasons: [#]_" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:19 -msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:24 -msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:27 -msgid "``pip``'s download cache (lowers download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:28 -msgid "Internal or unofficial mirrors (can both raise or lower download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:29 -msgid "Packages not hosted on PyPI (for comparisons sake)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:30 -msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:32 -msgid "Known historical data quality issues (lowers download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:34 -msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:38 -msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:43 -msgid "Public dataset" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:45 -msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:50 -msgid "Getting set up" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:52 -msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:58 -msgid "Navigate to the `BigQuery web UI`_." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:59 -msgid "Create a new project." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:60 -msgid "Enable the `BigQuery API `__." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:63 -msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:69 -msgid "Data schema" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:71 -msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -msgid "Column" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/guides/using-manifest-in.rst:67 -#: ../source/specifications/core-metadata.rst:185 -msgid "Description" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/specifications/direct-url.rst:226 -msgid "Examples" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "timestamp" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "Date and time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "``2020-03-09 00:33:03 UTC``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "file.project" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "Project name" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "``pipenv``, ``nose``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "file.version" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "Package version" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "``0.1.6``, ``1.4.2``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "details.installer.name" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "Installer" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "pip, `bandersnatch`_" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "details.python" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "Python version" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "``2.7.12``, ``3.6.4``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:93 -msgid "Useful queries" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:95 -msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:97 -msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:102 -msgid "Counting package downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:104 -msgid "The following query counts the total number of downloads for the project \"pytest\"." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:119 -#: ../source/guides/analyzing-pypi-package-downloads.rst:140 -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "num_downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:121 -msgid "26190085" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:124 -msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:142 -msgid "24334215" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:146 -msgid "Package downloads over time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:148 -msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -msgid "month" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "1956741" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "2018-01-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2344692" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2017-12-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "1730398" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "2017-11-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2047310" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2017-10-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "1744443" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "2017-09-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "1916952" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "2017-08-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:184 -msgid "Python versions over time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:186 -msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "python" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "3.7" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "18051328726" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "3.6" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "9635067203" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "3.8" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "7781904681" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "2.7" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "6381252241" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "null" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "2026630299" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "3.5" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "1894153540" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:221 -msgid "Caveats" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:223 -msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:231 -msgid "Additional tools" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:233 -msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:237 -msgid "``google-cloud-bigquery``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:239 -msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:267 -msgid "``pypinfo``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:269 -msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:273 -msgid "Install `pypinfo`_ using pip." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:279 -msgid "Usage:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:295 -msgid "``pandas-gbq``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:297 -msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:301 -#: ../source/specifications/binary-distribution-format.rst:459 -msgid "References" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:303 -msgid "`PyPI Download Counts deprecation email `__" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:304 -msgid "`PyPI BigQuery dataset announcement email `__" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:3 -msgid "Creating and discovering plugins" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:5 -msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:10 -msgid "There are three major approaches to doing automatic plugin discovery:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:12 -msgid "`Using naming convention`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:13 -msgid "`Using namespace packages`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:14 -msgid "`Using package metadata`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:18 -msgid "Using naming convention" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:20 -msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:38 -msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:48 -msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:59 -msgid "Using namespace packages" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:61 -msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:89 -msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:101 -msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:115 -msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:121 -msgid "Using package metadata" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:123 -msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:128 -msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:139 -msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:154 -msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:163 -msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:166 -msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:170 -msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:5 -msgid "Packaging and distributing projects" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:7 -msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:11 -msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:15 -msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:25 -msgid "Requirements for packaging and distributing" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:26 -msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:29 -msgid "Install \"twine\" [1]_:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:43 -msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:49 -msgid "Configuring your project" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:53 -msgid "Initial files" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:58 -msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:63 -msgid ":file:`setup.py` serves two primary functions:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:65 -msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:71 -msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:79 -msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:86 -msgid "README.rst / README.md" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:88 -msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:95 -msgid "For an example, see `README.md `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:99 -msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:108 -msgid "MANIFEST.in" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:110 -msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:115 -msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:119 -msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:122 -msgid "LICENSE.txt" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:124 -msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:130 -msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:135 -msgid "" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:137 -msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:141 -msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:149 -msgid "setup() args" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:151 -msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:155 -msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:164 -msgid "name" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:170 -msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:174 -msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:176 -msgid "Start & end with an ASCII letter or digit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:178 -msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:190 -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "version" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:196 -msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:200 -msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:203 -msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:206 -msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:214 -msgid "description" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:222 -msgid "Give a short and long description for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:224 -msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:229 -msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:235 -msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:245 -msgid "url" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:252 -msgid "Give a homepage URL for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:256 -msgid "author" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:263 -msgid "Provide details about the author." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:267 -msgid "license" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:273 -msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:279 -msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:287 -msgid "classifiers" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:316 -msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:319 -msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:327 -msgid "keywords" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:333 -msgid "List keywords that describe your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:337 -msgid "project_urls" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:349 -msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:355 -msgid "packages" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:361 -msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:370 -msgid "py_modules" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:376 -msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:388 -msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:392 -msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:398 -msgid "python_requires" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:400 -msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:407 -msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:412 -msgid "And so on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:416 -msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:422 -msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:431 -msgid "package_data" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:440 -msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:445 -msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:449 -msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:457 -msgid "data_files" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:463 -msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:469 -msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:479 -msgid "For more information see the distutils section on `Installing Additional Files `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:484 -msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:491 -msgid "scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:493 -msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:500 -msgid "entry_points" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:509 -msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:512 -msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:516 -msgid "The most commonly used entry point is \"console_scripts\" (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:521 -msgid "console_scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:531 -msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:538 -msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:545 -msgid "Choosing a versioning scheme" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:548 -msgid "Standards compliance for interoperability" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:550 -msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:556 -msgid "Here are some examples of compliant version numbers::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:567 -msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:573 -msgid "Scheme choices" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:576 -msgid "Semantic versioning (preferred)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:578 -msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:582 -msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:585 -msgid "MAJOR version when they make incompatible API changes," -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:586 -msgid "MINOR version when they add functionality in a backwards-compatible manner, and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:587 -msgid "MAINTENANCE version when they make backwards-compatible bug fixes." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:589 -msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:594 -msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:598 -msgid "Date based versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:600 -msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:604 -msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:607 -msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:611 -msgid "Serial versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:613 -msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:616 -msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:621 -msgid "Hybrid schemes" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:623 -msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:629 -msgid "Pre-release versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:631 -msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:634 -msgid "zero or more dev releases (denoted with a \".devN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:635 -msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:636 -msgid "zero or more beta releases (denoted with a \".bN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:637 -msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:639 -msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:644 -msgid "Local version identifiers" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:646 -msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:653 -msgid "A local version identifier takes the form ``+``. For example::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:661 -msgid "Working in \"development mode\"" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:663 -msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:667 -msgid "Assuming you're in the root of your project directory, then run:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:674 -msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:680 -msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:688 -msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:692 -msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:697 -msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:701 -msgid "Lastly, if you don't want to install any dependencies at all, you can run::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:706 -msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:713 -msgid "Packaging your project" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:715 -msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:720 -msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:737 -msgid "Source distributions" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:739 -msgid "Minimally, you should create a :term:`Source Distribution `:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:755 -msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:763 -msgid "Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:765 -msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:770 -msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:773 -msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:776 -msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:785 -msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:792 -msgid "Pure Python Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:794 -msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:797 -#: ../source/guides/distributing-packages-using-setuptools.rst:826 -msgid "To build the wheel:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:811 -msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:815 -msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:821 -msgid "Platform Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:823 -msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:841 -msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:847 -msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:855 -msgid "Uploading your Project to PyPI" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:857 -msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:861 -msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:866 -msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:871 -msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:877 -msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:888 -msgid "Create an account" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:890 -msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:894 -msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:897 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:901 -msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:904 -msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:913 -msgid "**Be aware that this stores your token in plaintext.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:915 -#: ../source/guides/migrating-to-pypi-org.rst:70 -#: ../source/guides/migrating-to-pypi-org.rst:109 -#: ../source/guides/using-testpypi.rst:83 -msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:921 -msgid "Upload your distributions" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:923 -msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:926 -msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:930 -msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:937 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:944 -#: ../source/tutorials/installing-packages.rst:663 -msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:950 -msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:5 -msgid "Dropping support for older Python versions" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:7 -msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:9 -msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:12 -msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:14 -msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:17 -msgid "Requirements" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:19 -msgid "This workflow requires that:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:21 -msgid "The publisher is using the latest version of :ref:`setuptools`," -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:22 -msgid "The latest version of :ref:`twine` is used to upload the package," -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:23 -msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:26 -msgid "Dealing with the universal wheels" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:28 -msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:36 -msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:48 -msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:53 -msgid "Defining the Python version required" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:56 -msgid "1. Download the newest version of Setuptools" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:58 -msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:60 -msgid "Steps:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:74 -msgid "`setuptools` version should be above 24.0.0." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:77 -msgid "2. Specify the version ranges for supported Python distributions" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:79 -msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:81 -#: ../source/specifications/core-metadata.rst:139 -#: ../source/specifications/core-metadata.rst:463 -#: ../source/specifications/core-metadata.rst:487 -#: ../source/specifications/core-metadata.rst:527 -#: ../source/specifications/core-metadata.rst:550 -#: ../source/specifications/core-metadata.rst:583 -#: ../source/specifications/core-metadata.rst:693 -#: ../source/specifications/core-metadata.rst:722 -msgid "Examples::" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:86 -msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:101 -msgid "3. Validating the Metadata before publishing" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:103 -msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:105 -msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:108 -msgid "You can see the contents of the generated file like this::" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:112 -msgid "Validate that the following is in place, before publishing the package:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:114 -msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:115 -msgid "The Requires-Python field is set and matches your specification in setup.py." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:118 -msgid "4. Using Twine to publish" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:120 -msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:122 -msgid "Make sure you are using the newest version of Twine, at least 1.9." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:125 -msgid "Dropping a Python release" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:127 -msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:129 -msgid "It must be done in this order for the automated fallback to work." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:131 -msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:133 -msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:5 -msgid "Hosting your own simple repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:8 -msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:13 -msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:29 -msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:35 -msgid "\"Manual\" repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:37 -msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:51 -msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:58 -msgid "For complete documentation of the simple repository protocol, see :pep:`503`." -msgstr "" - -#: ../source/guides/index.rst:8 -#: ../source/guides/index.rst:8 -msgid "Installing Packages:" -msgstr "" - -#: ../source/guides/index.rst:20 -#: ../source/guides/index.rst:20 -msgid "Building and Publishing Projects:" -msgstr "" - -#: ../source/guides/index.rst:38 -#: ../source/guides/index.rst:38 -msgid "Miscellaneous:" -msgstr "" - -#: ../source/guides/index.rst:4 -msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:5 -msgid "Package index mirrors and caches" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:8 -#: ../source/guides/supporting-multiple-python-versions.rst:8 -msgid "2014-12-24" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:14 -msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:17 -msgid "Three options are available in this area:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:19 -msgid "pip provides local caching options," -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:20 -msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:22 -msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:27 -msgid "Caching with pip" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:29 -msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:32 -msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:36 -msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:45 -msgid "Caching with devpi" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:47 -msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:55 -msgid "Complete mirror with bandersnatch" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:57 -msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:63 -msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:5 -msgid "Installing scientific packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:11 -msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:16 -msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:22 -msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:29 -msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:35 -msgid "Building from source" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:37 -msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:45 -msgid "Linux distribution packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:47 -msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:51 -msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:57 -msgid "Windows installers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:59 -msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:64 -msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:67 -msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:73 -msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:79 -msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:86 -msgid "macOS installers and package managers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:88 -msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:92 -msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:99 -msgid "SciPy distributions" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:101 -msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:105 -msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:109 -#: ../source/key_projects.rst:596 -msgid "Spack" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:110 -msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:119 -msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:128 -msgid "The conda cross-platform package manager" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:130 -msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:136 -msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 -msgid "Installing stand alone command line tools" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 -msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 -msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 -msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 -msgid "pipx only works with Python 3.6+." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 -msgid "``pipx`` is installed with ``pip``:" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 -msgid "You may need to restart your terminal for the path updates to take effect." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 -msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 -#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 -msgid "For example" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 -msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 -msgid "To upgrade or uninstall the package" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 -msgid "``pipx`` can be upgraded or uninstalled with pip" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 -msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 -msgid "To see the full list of commands ``pipx`` offers, run" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 -msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:5 -msgid "Installing pip/setuptools/wheel with Linux Package Managers" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:8 -msgid "2015-09-17" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:11 -msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:14 -msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:18 -msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:25 -msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:32 -msgid "Fedora" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:34 -msgid "Fedora 21:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:36 -#: ../source/guides/installing-using-linux-tools.rst:45 -#: ../source/guides/installing-using-linux-tools.rst:124 -#: ../source/guides/installing-using-linux-tools.rst:138 -#: ../source/guides/installing-using-linux-tools.rst:158 -msgid "Python 2::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:41 -msgid "Python 3: ``sudo yum install python3 python3-wheel``" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:43 -msgid "Fedora 22:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:50 -msgid "Python 3: ``sudo dnf install python3 python3-wheel``" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:53 -msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:63 -msgid "CentOS/RHEL" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:65 -msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:68 -msgid "To install pip and wheel for the system Python, there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:70 -msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:77 -msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:81 -msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:85 -msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:92 -msgid "To additionally upgrade setuptools, run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:97 -msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:101 -msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:104 -msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:106 -msgid "For CentOS, see here: https://www.softwarecollections.org/en/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:108 -msgid "Be aware that collections may not contain the most recent versions." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:110 -msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:116 -msgid "For example, for Python 3.4 on CentOS7/RHEL7::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:122 -msgid "openSUSE" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:129 -#: ../source/guides/installing-using-linux-tools.rst:143 -#: ../source/guides/installing-using-linux-tools.rst:162 -msgid "Python 3::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:135 -msgid "Debian/Ubuntu" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:150 -msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:156 -msgid "Arch Linux" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:168 -msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 -msgid "Installing packages using pip and virtual environments" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 -msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 -msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 -msgid "Installing pip" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 -msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 -msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 -msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 -msgid "Afterwards, you should have the newest pip installed in your user site:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 -msgid "The Python installers for Windows include pip. You should be able to access pip using:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 -msgid "You can make sure that pip is up-to-date by running:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 -msgid "Installing virtualenv" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 -msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 -msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 -msgid "Creating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 -msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 -msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 -msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 -msgid "venv will create a virtual Python installation in the ``env`` folder." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 -msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 -msgid "Activating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 -msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 -msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 -msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 -msgid "Leaving the virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 -msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 -msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 -msgid "Installing packages" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 -msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 -msgid "pip should download requests and all of its dependencies and install them:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 -msgid "Installing specific versions" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 -msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 -msgid "To install the latest ``2.x`` release of requests:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 -msgid "To install pre-release versions of packages, use the ``--pre`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 -msgid "Installing extras" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 -msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 -msgid "Installing from source" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 -msgid "pip can install a package directly from source, for example:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 -msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 -msgid "Installing from version control systems" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 -msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 -msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 -#: ../source/tutorials/installing-packages.rst:569 -msgid "Installing from local archives" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 -msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 -msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 -msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 -msgid "Using other package indexes" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 -msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 -msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 -#: ../source/tutorials/installing-packages.rst:389 -msgid "Upgrading packages" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 -msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 -msgid "Using requirements files" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 -msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 -msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 -msgid "Freezing dependencies" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 -msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 -msgid "Which will output a list of package specifiers such as:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 -msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:2 -msgid "Making a PyPI-friendly README" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:4 -msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:9 -msgid "Creating a README file" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:11 -msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:13 -msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:16 -msgid "plain text" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:17 -msgid "`reStructuredText `_ (without Sphinx extensions)" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:18 -msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:21 -msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:25 -msgid "Including your README in your package's metadata" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:27 -msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:33 -msgid ":ref:`description-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:34 -msgid ":ref:`description-content-type-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:36 -msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:39 -msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:45 -msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:60 -msgid "The minimum required versions of the respective tools are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:62 -msgid "``setuptools >= 38.6.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:63 -msgid "``wheel >= 0.31.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:64 -msgid "``twine >= 1.11.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:66 -msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:72 -msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:95 -msgid "Validating reStructuredText markup" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:97 -msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:100 -msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:105 -msgid "You can check your README for markup errors before uploading as follows:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:107 -msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:122 -msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:125 -msgid "Run ``twine check`` on the sdist and wheel::" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:129 -msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:4 -msgid "Migrating to PyPI.org" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:6 -msgid ":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``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:12 -msgid "Publishing releases" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:14 -msgid "``pypi.org`` is the default upload platform as of September 2016." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:16 -msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:19 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:22 -msgid "The default upload settings switched to ``pypi.org`` in the following versions:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:24 -msgid "``twine`` 1.8.0" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:25 -msgid "``setuptools`` 27.0.0" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:26 -msgid "Python 2.7.13 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:27 -msgid "Python 3.4.6 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:28 -msgid "Python 3.5.3 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:29 -msgid "Python 3.6.0 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:31 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:48 -msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:51 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:67 -msgid "(``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.)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:73 -msgid "Registering package names & metadata" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:75 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:79 -msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:84 -msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:89 -#: ../source/guides/using-testpypi.rst:5 -msgid "Using TestPyPI" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:91 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:113 -msgid "Registering new user accounts" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:115 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:121 -msgid "Browsing packages" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:123 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:130 -msgid "Downloading packages" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:132 -msgid "``pypi.org`` is the default host for downloading packages." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:135 -msgid "Managing published packages and releases" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:137 -msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:5 -msgid "Multi-version installs" -msgstr "" - -#: ../source/guides/multi-version-installs.rst:8 -msgid "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``)." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:13 -msgid "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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:19 -msgid "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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:31 -msgid "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 ``python -c ''`` to invoke the application's main entry point directly." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:38 -msgid "Refer to the `pkg_resources documentation `__ for more details." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:5 -msgid "Packaging binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:8 -msgid "2013-12-08" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:10 -msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:20 -msgid "An overview of binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:23 -msgid "Use cases" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:25 -msgid "The typical use cases for binary extensions break down into just three conventional categories:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:28 -msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:39 -msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:47 -msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:56 -msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:61 -msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:71 -msgid "Disadvantages" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:73 -msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:80 -msgid "This means that binary extensions:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:82 -msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:85 -msgid "may not be compatible with different builds of the CPython reference interpreter" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:88 -msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:91 -msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:96 -msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:101 -msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:108 -msgid "Alternatives to handcoded accelerator modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:110 -msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:115 -msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:122 -msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:132 -msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:141 -msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:150 -msgid "Alternatives to handcoded wrapper modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:152 -msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:158 -msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:162 -msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:168 -msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:175 -msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:181 -msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:185 -msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:189 -msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:203 -msgid "Alternatives for low level system access" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:205 -msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:213 -msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:222 -msgid "Implementing binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:224 -msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:241 -msgid "Building binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:244 -msgid "Building extensions for multiple platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:246 -msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:256 -msgid "Binary extensions for Windows" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:258 -msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:263 -msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:269 -msgid "To set up a build environment for binary extensions, the steps are as follows:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:271 -msgid "For Python 2.7" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:273 -msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:276 -msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:278 -#: ../source/guides/packaging-binary-extensions.rst:288 -#: ../source/guides/packaging-binary-extensions.rst:295 -msgid "Done." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:280 -msgid "For Python 3.4" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:282 -msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:285 -msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:287 -msgid "Set DISTUTILS_USE_SDK=1" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:290 -msgid "For Python 3.5" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:292 -msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:297 -msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:301 -msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:305 -msgid "Binary extensions for Linux" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:307 -msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:313 -msgid "Binary extensions for macOS" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:315 -msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:325 -msgid "Publishing binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:327 -msgid "For interim guidance on this topic, see the discussion in `this issue `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:343 -msgid "Additional resources" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:345 -msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:352 -msgid "Cross-platform wheel generation with scikit-build" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:354 -msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:362 -msgid "Introduction to C/C++ extension modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:364 -msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:367 -msgid "`What are (c)python extension modules? `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:368 -msgid "`Releasing the gil `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:369 -msgid "`Writing cpython extension modules using C++ `_" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:3 -msgid "Packaging namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:5 -msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:24 -msgid "And you use this package in your code like so::" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:29 -msgid "Then you can break these sub-packages into two separate distributions:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:46 -msgid "Each sub-package can now be separately installed, used, and versioned." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:48 -msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:58 -msgid "Creating a namespace package" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:60 -msgid "There are currently three different approaches to creating namespace packages:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:62 -msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:66 -msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:69 -msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:73 -msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:80 -msgid "Native namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:82 -msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:97 -msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:102 -msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:117 -msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:123 -msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:129 -msgid "pkgutil-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:131 -msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:136 -msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:148 -#: ../source/guides/packaging-namespace-packages.rst:194 -msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:155 -#: ../source/guides/packaging-namespace-packages.rst:201 -msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:160 -msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:171 -msgid "pkg_resources-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:173 -msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:182 -msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:206 -msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:216 -msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:223 -msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:237 -msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 -msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 -msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 -msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 -msgid "Saving credentials on GitHub" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 -msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 -msgid "Let's begin! 🚀" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 -msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 -msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 -msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 -msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 -msgid "Creating a workflow definition" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 -msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 -msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 -msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 -msgid "Defining a workflow job environment" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 -msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 -msgid "Checking out the project and building distributions" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 -msgid "Then, add the following under the ``build-n-publish`` section:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 -msgid "This will download your repository into the CI runner and then install and activate Python 3.7." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 -msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 -msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 -msgid "So add this to the steps list:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 -msgid "Publishing the distribution to PyPI and TestPyPI" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 -msgid "Finally, add the following steps at the end:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 -msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 -msgid "That's all, folks!" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 -msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:5 -msgid "Single-sourcing the package version" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:8 -msgid "There are many techniques to maintain a single source of truth for the version number of your project:" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:11 -msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:38 -msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:47 -msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:52 -msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:55 -msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:58 -msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:65 -msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:76 -msgid "Example using this technique: `warehouse `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:78 -msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:86 -msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:91 -msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:95 -msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:110 -msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:114 -msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:128 -msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:134 -msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:138 -msgid "Example using this technique: `setuptools `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:141 -msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:155 -msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:161 -msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:5 -msgid "Supporting multiple Python versions" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:37 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:43 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:49 -msgid "Automated testing and continuous integration" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:51 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:56 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:60 -msgid "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:" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:66 -msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:69 -msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:80 -msgid "Both `Travis CI`_ 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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:85 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:89 -msgid "Tools for single-source Python packages" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:91 -msgid "`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_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:100 -msgid "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" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:107 -msgid "a Python 2 (by syntax) module in a Python 3 project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:108 -msgid "a Python 3 (by syntax) module in a *Python 2* project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:110 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:117 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:124 -msgid "What's in which Python?" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:126 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:3 -msgid "Supporting Windows using Appveyor" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:6 -msgid "2015-12-03" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:8 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:20 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:24 -msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:30 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:38 -msgid "Setting up" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:40 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:45 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:49 -msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:54 -msgid "Adding Appveyor support to your project" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:56 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:61 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:69 -msgid "appveyor.yml" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:75 -msgid "This file can be downloaded from `here `__." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:77 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:80 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:88 -msgid "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``)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:94 -msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:97 -msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:100 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:109 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:114 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:119 -msgid "Support script" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:121 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:126 -msgid "`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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:133 -msgid "You can simply download the batch file and include it in your project unchanged." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:137 -msgid "Access to the built wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:139 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:147 -msgid "Additional notes" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:150 -msgid "Testing with tox" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:152 -msgid "Many projects use the `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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:156 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:160 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:165 -msgid "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" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:170 -msgid "``DISTUTILS_USE_SDK``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:171 -msgid "``MSSdk``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:172 -msgid "``INCLUDE``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:173 -msgid "``LIB``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:175 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:181 -msgid "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 Travis or 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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:188 -msgid "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``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:192 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:197 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:203 -msgid "Automatically uploading wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:205 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:210 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:216 -msgid "External dependencies" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:218 -msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:221 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:230 -msgid "Support scripts" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:232 -msgid "For reference, the SDK setup support script is listed here:" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:234 -msgid "``appveyor-sample/build.cmd``" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:5 -msgid "Tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:7 -msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:12 -msgid "Application dependency management" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:14 -msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:18 -msgid "When ``pipenv`` does not meet your use case, consider other tools like:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:20 -msgid ":ref:`pip`" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:22 -msgid "`pip-tools `_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:24 -msgid "`Poetry `_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:27 -msgid "Installation tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:29 -msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:34 -msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:37 -msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:40 -msgid ":ref:`buildout`: primarily focused on the web development community" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:42 -msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:47 -msgid "Packaging tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:49 -msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:52 -msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:56 -msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:61 -msgid "Publishing platform migration" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:63 -msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:67 -msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:72 -msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:77 -msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:82 -msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:88 -msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:93 -msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:102 -msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:107 -msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:5 -msgid "Including files in source distributions with ``MANIFEST.in``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:7 -msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:17 -msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:22 -msgid "How files are included in an sdist" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:24 -msgid "The following files are included in a source distribution by default:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:26 -msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:28 -msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:30 -msgid "scripts specified by the ``scripts`` ``setup()`` argument" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:31 -msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:33 -msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:35 -msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:37 -msgid "all files matching the pattern :file:`test/test*.py`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:38 -msgid ":file:`setup.py` (or whatever you called your setup script)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:39 -msgid ":file:`setup.cfg`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:40 -msgid ":file:`README`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:41 -msgid ":file:`README.txt`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:42 -msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:43 -msgid ":file:`README.md` (setuptools 36.4.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:44 -msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:45 -msgid ":file:`MANIFEST.in`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:47 -msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:52 -msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:60 -msgid ":file:`MANIFEST.in` commands" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:62 -msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:67 -msgid "Command" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:69 -msgid ":samp:`include {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:69 -msgid "Add all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid ":samp:`exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid "Remove all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid ":samp:`global-include {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid "Add all files anywhere in the source tree matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid ":samp:`global-exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid "Remove all files anywhere in the source tree matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid ":samp:`graft {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid "Add all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid ":samp:`prune {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid "Remove all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:79 -msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:87 -msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:91 -msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:95 -msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:101 -msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." -msgstr "" - -#: ../source/guides/using-testpypi.rst:7 -msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" -msgstr "" - -#: ../source/guides/using-testpypi.rst:13 -msgid "Registering your account" -msgstr "" - -#: ../source/guides/using-testpypi.rst:15 -msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." -msgstr "" - -#: ../source/guides/using-testpypi.rst:19 -msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." -msgstr "" - -#: ../source/guides/using-testpypi.rst:24 -msgid "Using TestPyPI with Twine" -msgstr "" - -#: ../source/guides/using-testpypi.rst:26 -msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:33 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." -msgstr "" - -#: ../source/guides/using-testpypi.rst:39 -msgid "Using TestPyPI with pip" -msgstr "" - -#: ../source/guides/using-testpypi.rst:41 -msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:56 -msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" -msgstr "" - -#: ../source/guides/using-testpypi.rst:73 -msgid "Setting up TestPyPI in :file:`.pypirc`" -msgstr "" - -#: ../source/guides/using-testpypi.rst:75 -msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" -msgstr "" - -#: ../source/index.rst:3 -#: ../source/key_projects.rst:181 -msgid "Python Packaging User Guide" -msgstr "" - -#: ../source/index.rst:5 -msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." -msgstr "" - -#: ../source/index.rst:5 -msgid "python, packaging, guide, tutorial" -msgstr "" - -#: ../source/index.rst:24 -msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." -msgstr "" - -#: ../source/index.rst:28 -msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" -msgstr "" - -#: ../source/index.rst:36 -msgid "Get started" -msgstr "" - -#: ../source/index.rst:38 -msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" -msgstr "" - -#: ../source/index.rst:41 -msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" -msgstr "" - -#: ../source/index.rst:43 -msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" -msgstr "" - -#: ../source/index.rst:45 -msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" -msgstr "" - -#: ../source/index.rst:47 -msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" -msgstr "" - -#: ../source/index.rst:52 -msgid "Learn more" -msgstr "" - -#: ../source/index.rst:54 -msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" -msgstr "" - -#: ../source/index.rst:56 -msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." -msgstr "" - -#: ../source/index.rst:58 -msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." -msgstr "" - -#: ../source/index.rst:60 -msgid "The :doc:`specifications/index` section for packaging interoperability specifications." -msgstr "" - -#: ../source/index.rst:62 -msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." -msgstr "" - -#: ../source/key_projects.rst:6 -msgid "Project Summaries" -msgstr "" - -#: ../source/key_projects.rst:8 -msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." -msgstr "" - -#: ../source/key_projects.rst:14 -msgid "PyPA Projects" -msgstr "" - -#: ../source/key_projects.rst:19 -msgid "bandersnatch" -msgstr "" - -#: ../source/key_projects.rst:21 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:25 -msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." -msgstr "" - -#: ../source/key_projects.rst:35 -msgid "build" -msgstr "" - -#: ../source/key_projects.rst:37 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:42 -msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." -msgstr "" - -#: ../source/key_projects.rst:49 -msgid "cibuildwheel" -msgstr "" - -#: ../source/key_projects.rst:51 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" -msgstr "" - -#: ../source/key_projects.rst:58 -msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." -msgstr "" - -#: ../source/key_projects.rst:64 -msgid "distlib" -msgstr "" - -#: ../source/key_projects.rst:66 -msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:71 -msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." -msgstr "" - -#: ../source/key_projects.rst:80 -msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." -msgstr "" - -#: ../source/key_projects.rst:90 -msgid "packaging" -msgstr "" - -#: ../source/key_projects.rst:92 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:97 -msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." -msgstr "" - -#: ../source/key_projects.rst:99 -msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." -msgstr "" - -#: ../source/key_projects.rst:107 -msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." -msgstr "" - -#: ../source/key_projects.rst:119 -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "pip" -msgstr "" - -#: ../source/key_projects.rst:121 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:126 -msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." -msgstr "" - -#: ../source/key_projects.rst:129 -msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." -msgstr "" - -#: ../source/key_projects.rst:137 -msgid "Pipenv" -msgstr "" - -#: ../source/key_projects.rst:139 -msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:144 -msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." -msgstr "" - -#: ../source/key_projects.rst:148 -msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." -msgstr "" - -#: ../source/key_projects.rst:159 -msgid "Pipfile" -msgstr "" - -#: ../source/key_projects.rst:161 -msgid "`Source `__" -msgstr "" - -#: ../source/key_projects.rst:163 -msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." -msgstr "" - -#: ../source/key_projects.rst:170 -msgid "pipx" -msgstr "" - -#: ../source/key_projects.rst:172 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:176 -msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." -msgstr "" - -#: ../source/key_projects.rst:183 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:187 -msgid "This guide!" -msgstr "" - -#: ../source/key_projects.rst:192 -msgid "readme_renderer" -msgstr "" - -#: ../source/key_projects.rst:194 -msgid "`GitHub and docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:197 -msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." -msgstr "" - -#: ../source/key_projects.rst:208 -msgid "setuptools" -msgstr "" - -#: ../source/key_projects.rst:210 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:215 -msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." -msgstr "" - -#: ../source/key_projects.rst:220 -msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." -msgstr "" - -#: ../source/key_projects.rst:227 -msgid "trove-classifiers" -msgstr "" - -#: ../source/key_projects.rst:229 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:233 -msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." -msgstr "" - -#: ../source/key_projects.rst:239 -msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." -msgstr "" - -#: ../source/key_projects.rst:253 -msgid "twine" -msgstr "" - -#: ../source/key_projects.rst:255 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:260 -msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." -msgstr "" - -#: ../source/key_projects.rst:270 -#: ../source/overview.rst:415 -msgid "virtualenv" -msgstr "" - -#: ../source/key_projects.rst:272 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:277 -msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/key_projects.rst:290 -msgid "Warehouse" -msgstr "" - -#: ../source/key_projects.rst:292 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:296 -msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." -msgstr "" - -#: ../source/key_projects.rst:304 -msgid "wheel" -msgstr "" - -#: ../source/key_projects.rst:306 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:311 -msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." -msgstr "" - -#: ../source/key_projects.rst:315 -msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." -msgstr "" - -#: ../source/key_projects.rst:324 -msgid "Non-PyPA Projects" -msgstr "" - -#: ../source/key_projects.rst:329 -msgid "bento" -msgstr "" - -#: ../source/key_projects.rst:331 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:336 -msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." -msgstr "" - -#: ../source/key_projects.rst:344 -msgid "buildout" -msgstr "" - -#: ../source/key_projects.rst:346 -msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:351 -msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." -msgstr "" - -#: ../source/key_projects.rst:358 -msgid "conda" -msgstr "" - -#: ../source/key_projects.rst:360 -msgid "`Docs `__" -msgstr "" - -#: ../source/key_projects.rst:362 -msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." -msgstr "" - -#: ../source/key_projects.rst:369 -msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." -msgstr "" - -#: ../source/key_projects.rst:373 -msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." -msgstr "" - -#: ../source/key_projects.rst:386 -msgid "devpi" -msgstr "" - -#: ../source/key_projects.rst:388 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:392 -msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." -msgstr "" - -#: ../source/key_projects.rst:401 -msgid "flit" -msgstr "" - -#: ../source/key_projects.rst:403 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:407 -msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." -msgstr "" - -#: ../source/key_projects.rst:412 -msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." -msgstr "" - -#: ../source/key_projects.rst:422 -msgid "enscons" -msgstr "" - -#: ../source/key_projects.rst:424 -msgid "`Source `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:428 -msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." -msgstr "" - -#: ../source/key_projects.rst:443 -msgid "Hashdist" -msgstr "" - -#: ../source/key_projects.rst:445 -msgid "`Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:448 -msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." -msgstr "" - -#: ../source/key_projects.rst:460 -msgid "hatch" -msgstr "" - -#: ../source/key_projects.rst:462 -msgid "`GitHub and Docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:465 -msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." -msgstr "" - -#: ../source/key_projects.rst:475 -msgid "multibuild" -msgstr "" - -#: ../source/key_projects.rst:477 -msgid "`GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:479 -msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." -msgstr "" - -#: ../source/key_projects.rst:485 -msgid "pex" -msgstr "" - -#: ../source/key_projects.rst:487 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:491 -msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." -msgstr "" - -#: ../source/key_projects.rst:500 -msgid "pip-tools" -msgstr "" - -#: ../source/key_projects.rst:502 -msgid "`GitHub and Docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:505 -msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." -msgstr "" - -#: ../source/key_projects.rst:517 -msgid "piwheels" -msgstr "" - -#: ../source/key_projects.rst:519 -msgid "`Website `__ | `Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:523 -msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." -msgstr "" - -#: ../source/key_projects.rst:532 -msgid "poetry" -msgstr "" - -#: ../source/key_projects.rst:534 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:538 -msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." -msgstr "" - -#: ../source/key_projects.rst:548 -msgid "pypiserver" -msgstr "" - -#: ../source/key_projects.rst:550 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:554 -msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." -msgstr "" - -#: ../source/key_projects.rst:564 -msgid "scikit-build" -msgstr "" - -#: ../source/key_projects.rst:566 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:570 -msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." -msgstr "" - -#: ../source/key_projects.rst:582 -msgid "shiv" -msgstr "" - -#: ../source/key_projects.rst:584 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:588 -msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." -msgstr "" - -#: ../source/key_projects.rst:598 -msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" -msgstr "" - -#: ../source/key_projects.rst:603 -msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." -msgstr "" - -#: ../source/key_projects.rst:611 -msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." -msgstr "" - -#: ../source/key_projects.rst:617 -msgid "zest.releaser" -msgstr "" - -#: ../source/key_projects.rst:619 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:623 -msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." -msgstr "" - -#: ../source/key_projects.rst:630 -msgid "Standard Library Projects" -msgstr "" - -#: ../source/key_projects.rst:635 -msgid "ensurepip" -msgstr "" - -#: ../source/key_projects.rst:637 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:640 -msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." -msgstr "" - -#: ../source/key_projects.rst:649 -msgid "distutils" -msgstr "" - -#: ../source/key_projects.rst:651 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:654 -msgid "The original Python packaging system, added to the standard library in Python 2.0." -msgstr "" - -#: ../source/key_projects.rst:657 -msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." -msgstr "" - -#: ../source/key_projects.rst:670 -msgid "venv" -msgstr "" - -#: ../source/key_projects.rst:672 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:675 -msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/news.rst:2 -msgid "News" -msgstr "" - -#: ../source/news.rst:5 -msgid "September 2019" -msgstr "" - -#: ../source/news.rst:6 -msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" -msgstr "" - -#: ../source/news.rst:9 -msgid "August 2019" -msgstr "" - -#: ../source/news.rst:10 -msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" -msgstr "" - -#: ../source/news.rst:13 -msgid "July 2019" -msgstr "" - -#: ../source/news.rst:14 -msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" -msgstr "" - -#: ../source/news.rst:15 -msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" -msgstr "" - -#: ../source/news.rst:16 -msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" -msgstr "" - -#: ../source/news.rst:17 -msgid "Updated directory layout examples for consistency. (:pr:`611`)" -msgstr "" - -#: ../source/news.rst:18 -msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" -msgstr "" - -#: ../source/news.rst:21 -msgid "June 2019" -msgstr "" - -#: ../source/news.rst:22 -msgid "Fixed some typos. (:pr:`620`)" -msgstr "" - -#: ../source/news.rst:25 -msgid "May 2019" -msgstr "" - -#: ../source/news.rst:26 -msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" -msgstr "" - -#: ../source/news.rst:27 -msgid "Added a MANIFEST.in guide page. (:pr:`609`)" -msgstr "" - -#: ../source/news.rst:30 -msgid "April 2019" -msgstr "" - -#: ../source/news.rst:31 -msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" -msgstr "" - -#: ../source/news.rst:32 -msgid "Reduced emphasis on virtualenv. (:pr:`606`)" -msgstr "" - -#: ../source/news.rst:35 -msgid "March 2019" -msgstr "" - -#: ../source/news.rst:36 -msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" -msgstr "" - -#: ../source/news.rst:37 -msgid "Covered RTD details for contributing. (:pr:`600`)" -msgstr "" - -#: ../source/news.rst:40 -msgid "February 2019" -msgstr "" - -#: ../source/news.rst:41 -msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" -msgstr "" - -#: ../source/news.rst:42 -msgid "Added instructions to install Python CLI applications. (:pr:`594`)" -msgstr "" - -#: ../source/news.rst:45 -msgid "January 2019" -msgstr "" - -#: ../source/news.rst:46 -msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" -msgstr "" - -#: ../source/news.rst:47 -msgid "Updated Sphinx and Nox. (:pr:`591`)" -msgstr "" - -#: ../source/news.rst:48 -msgid "Referenced Twine from Python3. (:pr:`581`)" -msgstr "" - -#: ../source/news.rst:51 -msgid "December 2018" -msgstr "" - -#: ../source/news.rst:52 -msgid "No programmers in the office!" -msgstr "" - -#: ../source/news.rst:55 -msgid "November 2018" -msgstr "" - -#: ../source/news.rst:56 -msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" -msgstr "" - -#: ../source/news.rst:57 -msgid "Changed bumpversion to bump2version. (:pr:`572`)" -msgstr "" - -#: ../source/news.rst:58 -msgid "Added single-sourcing package version example. (:pr:`573`)" -msgstr "" - -#: ../source/news.rst:59 -msgid "Added a guide for creating documentation. (:pr:`568`)" -msgstr "" - -#: ../source/news.rst:62 -msgid "October 2018" -msgstr "" - -#: ../source/news.rst:63 -msgid "Updated Nox package name. (:pr:`566`)" -msgstr "" - -#: ../source/news.rst:64 -msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" -msgstr "" - -#: ../source/news.rst:67 -msgid "September 2018" -msgstr "" - -#: ../source/news.rst:68 -msgid "Added a section on checking RST markup. (:pr:`554`)" -msgstr "" - -#: ../source/news.rst:69 -msgid "Updated user installs page. (:pr:`558`)" -msgstr "" - -#: ../source/news.rst:70 -msgid "Updated Google BigQuery urls. (:pr:`556`)" -msgstr "" - -#: ../source/news.rst:71 -msgid "Replaced tar command with working command. (:pr:`552`)" -msgstr "" - -#: ../source/news.rst:72 -msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" -msgstr "" - -#: ../source/news.rst:75 -msgid "August 2018" -msgstr "" - -#: ../source/news.rst:76 -msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" -msgstr "" - -#: ../source/news.rst:77 -msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" -msgstr "" - -#: ../source/news.rst:78 -msgid "Updated Python version supported by virtualenv. (:pr:`538`)" -msgstr "" - -#: ../source/news.rst:79 -msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" -msgstr "" - -#: ../source/news.rst:82 -msgid "July 2018" -msgstr "" - -#: ../source/news.rst:84 -msgid "Improved binary extension docs. (:pr:`531`)" -msgstr "" - -#: ../source/news.rst:85 -msgid "Added scikit-build to key projects. (:pr:`530`)" -msgstr "" - -#: ../source/news.rst:88 -msgid "June 2018" -msgstr "" - -#: ../source/news.rst:90 -msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" -msgstr "" - -#: ../source/news.rst:91 -msgid "Updated Markdown descriptions explanation. (:pr:`522`)" -msgstr "" - -#: ../source/news.rst:94 -msgid "May 2018" -msgstr "" - -#: ../source/news.rst:96 -msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" -msgstr "" - -#: ../source/news.rst:97 -msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" -msgstr "" - -#: ../source/news.rst:98 -msgid "Simplified packaging tutorial. (:pr:`498`)" -msgstr "" - -#: ../source/news.rst:99 -msgid "Updated Windows users instructions for clarity. (:pr:`493`)" -msgstr "" - -#: ../source/news.rst:100 -msgid "Updated the license section description for completeness. (:pr:`492`)" -msgstr "" - -#: ../source/news.rst:101 -msgid "Added specification-style document to contributing section. (:pr:`489`)" -msgstr "" - -#: ../source/news.rst:102 -msgid "Added documentation types to contributing guide. (:pr:`485`)" -msgstr "" - -#: ../source/news.rst:105 -msgid "April 2018" -msgstr "" - -#: ../source/news.rst:107 -msgid "Added README guide. (:pr:`461`)" -msgstr "" - -#: ../source/news.rst:108 -msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" -msgstr "" - -#: ../source/news.rst:109 -msgid "Added instructions for Warehouse. (:pr:`471`)" -msgstr "" - -#: ../source/news.rst:110 -msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" -msgstr "" - -#: ../source/news.rst:111 -msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" -msgstr "" - -#: ../source/news.rst:112 -msgid "Added a guide for phasing out Python versions. (:pr:`459`)" -msgstr "" - -#: ../source/news.rst:113 -msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" -msgstr "" - -#: ../source/news.rst:116 -msgid "March 2018" -msgstr "" - -#: ../source/news.rst:118 -msgid "Updated \"installing scientific packages\". (:pr:`455`)" -msgstr "" - -#: ../source/news.rst:119 -msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" -msgstr "" - -#: ../source/news.rst:120 -msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" -msgstr "" - -#: ../source/news.rst:121 -msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" -msgstr "" - -#: ../source/news.rst:124 -msgid "February 2018" -msgstr "" - -#: ../source/news.rst:126 -msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" -msgstr "" - -#: ../source/news.rst:127 -msgid "Updated PyPI migration info. (:pr:`439`)" -msgstr "" - -#: ../source/news.rst:128 -msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" -msgstr "" - -#: ../source/news.rst:129 -msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" -msgstr "" - -#: ../source/news.rst:130 -msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" -msgstr "" - -#: ../source/news.rst:133 -msgid "January 2018" -msgstr "" - -#: ../source/news.rst:135 -msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" -msgstr "" - -#: ../source/news.rst:136 -msgid "Updated README.rst explanation. (:pr:`419`)" -msgstr "" - -#: ../source/news.rst:139 -msgid "December 2017" -msgstr "" - -#: ../source/news.rst:141 -msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" -msgstr "" - -#: ../source/news.rst:142 -msgid "Noted which fields can be used with environment markers. (:pr:`416`)" -msgstr "" - -#: ../source/news.rst:143 -msgid "Updated Requires-Python section. (:pr:`414`)" -msgstr "" - -#: ../source/news.rst:144 -msgid "Added news page. (:pr:`404`)" -msgstr "" - -#: ../source/news.rst:147 -msgid "November 2017" -msgstr "" - -#: ../source/news.rst:149 -msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" -msgstr "" - -#: ../source/news.rst:150 -msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" -msgstr "" - -#: ../source/news.rst:152 -msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" -msgstr "" - -#: ../source/news.rst:153 -msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" -msgstr "" - -#: ../source/news.rst:156 -msgid "October 2017" -msgstr "" - -#: ../source/news.rst:158 -msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" -msgstr "" - -#: ../source/news.rst:159 -msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" -msgstr "" - -#: ../source/news.rst:160 -msgid "Split the specifications page into multiple pages. (:pr:`386`)" -msgstr "" - -#: ../source/news.rst:163 -msgid "September 2017" -msgstr "" - -#: ../source/news.rst:165 -msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" -msgstr "" - -#: ../source/news.rst:167 -msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" -msgstr "" - -#: ../source/news.rst:170 -msgid "August 2017" -msgstr "" - -#: ../source/news.rst:172 -msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" -msgstr "" - -#: ../source/news.rst:173 -msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" -msgstr "" - -#: ../source/news.rst:174 -msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" -msgstr "" - -#: ../source/news.rst:177 -msgid "July 2017" -msgstr "" - -#: ../source/news.rst:179 -msgid "Added ``flit`` to the key projects list. (:pr:`358`)" -msgstr "" - -#: ../source/news.rst:180 -msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" -msgstr "" - -#: ../source/news.rst:181 -msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" -msgstr "" - -#: ../source/news.rst:182 -msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" -msgstr "" - -#: ../source/news.rst:183 -msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" -msgstr "" - -#: ../source/news.rst:186 -msgid "June 2017" -msgstr "" - -#: ../source/news.rst:188 -msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" -msgstr "" - -#: ../source/news.rst:189 -msgid "Added documentation for ``python_requires``. (:pr:`338`)" -msgstr "" - -#: ../source/news.rst:190 -msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" -msgstr "" - -#: ../source/news.rst:191 -msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" -msgstr "" - -#: ../source/news.rst:192 -msgid "Added a license section to the distributing guide. (:pr:`331`)" -msgstr "" - -#: ../source/news.rst:193 -msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" -msgstr "" - -#: ../source/news.rst:194 -msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" -msgstr "" - -#: ../source/news.rst:195 -msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" -msgstr "" - -#: ../source/news.rst:196 -msgid "Switched to the PyPA theme. (:pr:`305`)" -msgstr "" - -#: ../source/news.rst:197 -msgid "Re-organized the documentation into the new structure. (:pr:`318`)" -msgstr "" - -#: ../source/news.rst:200 -msgid "May 2017" -msgstr "" - -#: ../source/news.rst:202 -msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" -msgstr "" - -#: ../source/news.rst:203 -msgid "Added contributor and style guide. (:pr:`307`)" -msgstr "" - -#: ../source/news.rst:204 -msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" -msgstr "" - -#: ../source/news.rst:207 -msgid "April 2017" -msgstr "" - -#: ../source/news.rst:209 -msgid "Added travis configuration for testing pull requests. (:pr:`300`)" -msgstr "" - -#: ../source/news.rst:210 -msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" -msgstr "" - -#: ../source/news.rst:211 -msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" -msgstr "" - -#: ../source/news.rst:212 -msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" -msgstr "" - -#: ../source/news.rst:213 -msgid "Added a topic on namespace packages. (:pr:`290`)" -msgstr "" - -#: ../source/news.rst:214 -msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" -msgstr "" - -#: ../source/news.rst:215 -msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" -msgstr "" - -#: ../source/news.rst:216 -msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" -msgstr "" - -#: ../source/news.rst:217 -msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" -msgstr "" - -#: ../source/news.rst:219 -msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" -msgstr "" - -#: ../source/news.rst:223 -msgid "March 2017" -msgstr "" - -#: ../source/news.rst:225 -msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" -msgstr "" - -#: ../source/news.rst:228 -msgid "February 2017" -msgstr "" - -#: ../source/news.rst:230 -msgid "Added :pep:`518`. (:pr:`281`)" -msgstr "" - -#: ../source/overview.rst:3 -msgid "An Overview of Packaging for Python" -msgstr "" - -#: ../source/overview.rst:7 -msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." -msgstr "" - -#: ../source/overview.rst:12 -msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." -msgstr "" - -#: ../source/overview.rst:18 -msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." -msgstr "" - -#: ../source/overview.rst:26 -msgid "Thinking about deployment" -msgstr "" - -#: ../source/overview.rst:28 -msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" -msgstr "" - -#: ../source/overview.rst:32 -msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" -msgstr "" - -#: ../source/overview.rst:35 -msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" -msgstr "" - -#: ../source/overview.rst:37 -msgid "Is your software installed individually, or in large deployment batches?" -msgstr "" - -#: ../source/overview.rst:39 -msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." -msgstr "" - -#: ../source/overview.rst:46 -msgid "Packaging Python libraries and tools" -msgstr "" - -#: ../source/overview.rst:48 -msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." -msgstr "" - -#: ../source/overview.rst:53 -msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." -msgstr "" - -#: ../source/overview.rst:59 -msgid "Python modules" -msgstr "" - -#: ../source/overview.rst:61 -msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." -msgstr "" - -#: ../source/overview.rst:66 -msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." -msgstr "" - -#: ../source/overview.rst:73 -msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." -msgstr "" - -#: ../source/overview.rst:78 -msgid "Python source distributions" -msgstr "" - -#: ../source/overview.rst:80 -msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." -msgstr "" - -#: ../source/overview.rst:84 -msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." -msgstr "" - -#: ../source/overview.rst:90 -msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." -msgstr "" - -#: ../source/overview.rst:95 -msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." -msgstr "" - -#: ../source/overview.rst:100 -msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." -msgstr "" - -#: ../source/overview.rst:107 -msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" -msgstr "" - -#: ../source/overview.rst:114 -msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." -msgstr "" - -#: ../source/overview.rst:119 -msgid "Python binary distributions" -msgstr "" - -#: ../source/overview.rst:121 -msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." -msgstr "" - -#: ../source/overview.rst:125 -msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." -msgstr "" - -#: ../source/overview.rst:132 -msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." -msgstr "" - -#: ../source/overview.rst:140 -msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." -msgstr "" - -#: ../source/overview.rst:148 -msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." -msgstr "" - -#: ../source/overview.rst:155 -msgid "Packaging Python applications" -msgstr "" - -#: ../source/overview.rst:157 -msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." -msgstr "" - -#: ../source/overview.rst:162 -msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." -msgstr "" - -#: ../source/overview.rst:166 -msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." -msgstr "" - -#: ../source/overview.rst:172 -msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." -msgstr "" - -#: ../source/overview.rst:176 -msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." -msgstr "" - -#: ../source/overview.rst:181 -msgid "Depending on a framework" -msgstr "" - -#: ../source/overview.rst:183 -msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." -msgstr "" - -#: ../source/overview.rst:189 -msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." -msgstr "" - -#: ../source/overview.rst:195 -msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." -msgstr "" - -#: ../source/overview.rst:199 -msgid "Service platforms" -msgstr "" - -#: ../source/overview.rst:201 -msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." -msgstr "" - -#: ../source/overview.rst:205 -msgid "`Heroku `_" -msgstr "" - -#: ../source/overview.rst:206 -msgid "`Google App Engine `_" -msgstr "" - -#: ../source/overview.rst:207 -msgid "`PythonAnywhere `_" -msgstr "" - -#: ../source/overview.rst:208 -msgid "`OpenShift `_" -msgstr "" - -#: ../source/overview.rst:209 -msgid "\"Serverless\" frameworks like `Zappa `_" -msgstr "" - -#: ../source/overview.rst:211 -msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." -msgstr "" - -#: ../source/overview.rst:216 -msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." -msgstr "" - -#: ../source/overview.rst:220 -msgid "Web browsers and mobile applications" -msgstr "" - -#: ../source/overview.rst:222 -msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." -msgstr "" - -#: ../source/overview.rst:227 -msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" -msgstr "" - -#: ../source/overview.rst:231 -msgid "`Kivy `_" -msgstr "" - -#: ../source/overview.rst:232 -msgid "`Beeware `_" -msgstr "" - -#: ../source/overview.rst:233 -msgid "`Brython `_" -msgstr "" - -#: ../source/overview.rst:234 -msgid "`Flexx `_" -msgstr "" - -#: ../source/overview.rst:236 -msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." -msgstr "" - -#: ../source/overview.rst:241 -msgid "Depending on a pre-installed Python" -msgstr "" - -#: ../source/overview.rst:243 -msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." -msgstr "" - -#: ../source/overview.rst:249 -msgid "Technologies which support this model:" -msgstr "" - -#: ../source/overview.rst:251 -msgid "`PEX `_ (Python EXecutable)" -msgstr "" - -#: ../source/overview.rst:252 -msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" -msgstr "" - -#: ../source/overview.rst:253 -msgid "`shiv `_ (requires Python 3)" -msgstr "" - -#: ../source/overview.rst:255 -msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." -msgstr "" - -#: ../source/overview.rst:260 -msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." -msgstr "" - -#: ../source/overview.rst:267 -msgid "Depending on a separate software distribution ecosystem" -msgstr "" - -#: ../source/overview.rst:269 -msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." -msgstr "" - -#: ../source/overview.rst:274 -msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." -msgstr "" - -#: ../source/overview.rst:284 -msgid "Instructions on building and publishing for the Anaconda ecosystem:" -msgstr "" - -#: ../source/overview.rst:286 -msgid "`Building libraries and applications with conda `_" -msgstr "" - -#: ../source/overview.rst:287 -msgid "`Transitioning a native Python package to Anaconda `_" -msgstr "" - -#: ../source/overview.rst:289 -msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" -msgstr "" - -#: ../source/overview.rst:293 -msgid "`Enthought Canopy `_" -msgstr "" - -#: ../source/overview.rst:294 -msgid "`ActiveState ActivePython `_" -msgstr "" - -#: ../source/overview.rst:295 -msgid "`WinPython `_" -msgstr "" - -#: ../source/overview.rst:300 -msgid "Bringing your own Python executable" -msgstr "" - -#: ../source/overview.rst:302 -msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." -msgstr "" - -#: ../source/overview.rst:306 -msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." -msgstr "" - -#: ../source/overview.rst:311 -msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." -msgstr "" - -#: ../source/overview.rst:315 -msgid "A selection of Python freezers:" -msgstr "" - -#: ../source/overview.rst:317 -msgid "`pyInstaller `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:318 -msgid "`cx_Freeze `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:319 -msgid "`constructor `_ - For command-line installers" -msgstr "" - -#: ../source/overview.rst:320 -msgid "`py2exe `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:321 -msgid "`py2app `_ - Mac only" -msgstr "" - -#: ../source/overview.rst:322 -msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" -msgstr "" - -#: ../source/overview.rst:323 -msgid "`osnap `_ - Windows and Mac" -msgstr "" - -#: ../source/overview.rst:324 -msgid "`pynsist `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:326 -msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." -msgstr "" - -#: ../source/overview.rst:332 -msgid "Bringing your own userspace" -msgstr "" - -#: ../source/overview.rst:334 -msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." -msgstr "" - -#: ../source/overview.rst:341 -msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." -msgstr "" - -#: ../source/overview.rst:344 -msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" -msgstr "" - -#: ../source/overview.rst:347 -msgid "`AppImage `_" -msgstr "" - -#: ../source/overview.rst:348 -msgid "`Docker `_" -msgstr "" - -#: ../source/overview.rst:349 -msgid "`Flatpak `_" -msgstr "" - -#: ../source/overview.rst:350 -msgid "`Snapcraft `_" -msgstr "" - -#: ../source/overview.rst:353 -msgid "Bringing your own kernel" -msgstr "" - -#: ../source/overview.rst:355 -msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." -msgstr "" - -#: ../source/overview.rst:360 -msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" -msgstr "" - -#: ../source/overview.rst:364 -msgid "`Vagrant `_" -msgstr "" - -#: ../source/overview.rst:365 -msgid "`VHD `_, `AMI `_, and `other formats `_" -msgstr "" - -#: ../source/overview.rst:366 -msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" -msgstr "" - -#: ../source/overview.rst:369 -msgid "Bringing your own hardware" -msgstr "" - -#: ../source/overview.rst:371 -msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." -msgstr "" - -#: ../source/overview.rst:375 -msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." -msgstr "" - -#: ../source/overview.rst:379 -msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." -msgstr "" - -#: ../source/overview.rst:389 -msgid "The simplified gamut of technologies used to package Python applications." -msgstr "" - -#: ../source/overview.rst:392 -msgid "What about..." -msgstr "" - -#: ../source/overview.rst:394 -msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." -msgstr "" - -#: ../source/overview.rst:398 -msgid "Operating system packages" -msgstr "" - -#: ../source/overview.rst:400 -msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." -msgstr "" - -#: ../source/overview.rst:411 -msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." -msgstr "" - -#: ../source/overview.rst:417 -msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." -msgstr "" - -#: ../source/overview.rst:427 -msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." -msgstr "" - -#: ../source/overview.rst:432 -msgid "Security" -msgstr "" - -#: ../source/overview.rst:434 -msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." -msgstr "" - -#: ../source/overview.rst:437 -msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." -msgstr "" - -#: ../source/overview.rst:446 -msgid "Wrap up" -msgstr "" - -#: ../source/overview.rst:448 -msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:6 -msgid "Binary distribution format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:8 -msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:13 -msgid "Abstract" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:15 -msgid "This PEP describes a built-package format for Python called \"wheel\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:17 -msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:27 -msgid "PEP Acceptance" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:29 -msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:34 -msgid "Rationale" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:36 -msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:43 -msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:52 -msgid "Details" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:55 -msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:57 -msgid "Wheel installation notionally consists of two phases:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:59 -msgid "Unpack." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:61 -msgid "Parse ``distribution-1.0.dist-info/WHEEL``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:62 -msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:64 -msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:66 -msgid "Else unpack archive into platlib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:68 -msgid "Spread." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:70 -msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:72 -msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:78 -msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:80 -msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:82 -msgid "Remove empty ``distribution-1.0.data`` directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:83 -msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:87 -msgid "Recommended installer features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:97 -msgid "Rewrite ``#!python``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:90 -msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:96 -msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:102 -msgid "Generate script wrappers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:100 -msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:105 -msgid "Recommended archiver features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:112 -msgid "Place ``.dist-info`` at the end of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:108 -msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:115 -msgid "File Format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:118 -msgid "File name convention" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:120 -msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "distribution" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "Distribution name, e.g. 'django', 'pyramid'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "Distribution version, e.g. 1.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:135 -msgid "build tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:130 -msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "language implementation and version tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "E.g. 'py27', 'py2', 'py3'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "abi tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "E.g. 'cp33m', 'abi3', 'none'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "platform tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "E.g. 'linux_x86_64', 'any'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:146 -msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:151 -msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:156 -msgid "Escaping and Unicode" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:158 -msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:161 -msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:164 -msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:166 -msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:169 -msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:172 -msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:176 -msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:182 -msgid "File contents" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:184 -msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:188 -msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:191 -msgid "``{distribution}-{version}.dist-info/`` contains metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:192 -msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:196 -msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:200 -msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:202 -msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:212 -msgid "``Wheel-Version`` is the version number of the Wheel specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:213 -msgid "``Generator`` is the name and optionally the version of the software that produced the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:215 -msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:218 -msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:220 -msgid "``Build`` is the build number and is omitted if there is no build number." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:221 -msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:224 -msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:226 -msgid "Wheel does not contain setup.py or setup.cfg." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:228 -msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:235 -#: ../source/specifications/recording-installed-packages.rst:35 -msgid "The .dist-info directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:237 -msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:239 -msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:241 -msgid "WHEEL is the wheel metadata specific to a build of the package." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:242 -msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:248 -msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:249 -msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:251 -msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:254 -msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:261 -msgid "The .data directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:263 -msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:271 -msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:277 -msgid "Signed wheel files" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:279 -msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:290 -msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:295 -msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:302 -msgid "(The hash value is the same format used in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:304 -msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:307 -msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:312 -msgid "See" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:314 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:315 -msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:316 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:317 -msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:321 -msgid "Comparison to .egg" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:323 -msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:328 -msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:331 -msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:337 -msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:341 -msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:344 -msgid "Wheel is a reference to the other Python." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:348 -msgid "FAQ" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:352 -msgid "Wheel defines a .data directory. Should I put all my data there?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:354 -msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:363 -msgid "Why does wheel include attached signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:365 -msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:373 -msgid "Why does wheel allow JWS signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:375 -msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:381 -msgid "Why does wheel also allow S/MIME signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:383 -msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:386 -msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:391 -msgid "What's the deal with \"purelib\" vs. \"platlib\"?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:393 -msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:398 -msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:403 -msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:409 -msgid "Is it possible to import Python code directly from a wheel file?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:411 -msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:417 -msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:426 -msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:443 -msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:450 -msgid "Changes" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:452 -msgid "Since :pep:`427`, this specification has changed as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:454 -msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:461 -msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:466 -msgid "Appendix" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:468 -msgid "Example urlsafe-base64-nopad implementation::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:482 -msgid "Copyright" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:484 -msgid "This document has been placed into the public domain." -msgstr "" - -#: ../source/specifications/core-metadata.rst:5 -msgid "Core metadata specifications" -msgstr "" - -#: ../source/specifications/core-metadata.rst:7 -msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:10 -msgid "``Metadata-Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:11 -msgid "``Name``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:12 -msgid "``Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:14 -msgid "All the other fields are optional." -msgstr "" - -#: ../source/specifications/core-metadata.rst:16 -msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." -msgstr "" - -#: ../source/specifications/core-metadata.rst:25 -msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:30 -msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." -msgstr "" - -#: ../source/specifications/core-metadata.rst:41 -msgid "Metadata-Version" -msgstr "" - -#: ../source/specifications/core-metadata.rst:45 -msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." -msgstr "" - -#: ../source/specifications/core-metadata.rst:48 -msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:54 -msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." -msgstr "" - -#: ../source/specifications/core-metadata.rst:58 -#: ../source/specifications/core-metadata.rst:80 -#: ../source/specifications/core-metadata.rst:95 -#: ../source/specifications/core-metadata.rst:155 -#: ../source/specifications/core-metadata.rst:170 -#: ../source/specifications/core-metadata.rst:208 -#: ../source/specifications/core-metadata.rst:283 -#: ../source/specifications/core-metadata.rst:287 -#: ../source/specifications/core-metadata.rst:291 -#: ../source/specifications/core-metadata.rst:295 -#: ../source/specifications/core-metadata.rst:327 -#: ../source/specifications/core-metadata.rst:347 -#: ../source/specifications/core-metadata.rst:373 -#: ../source/specifications/core-metadata.rst:391 -#: ../source/specifications/core-metadata.rst:416 -#: ../source/specifications/core-metadata.rst:438 -#: ../source/specifications/core-metadata.rst:600 -#: ../source/specifications/core-metadata.rst:620 -#: ../source/specifications/core-metadata.rst:630 -msgid "Example::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:66 -msgid "Name" -msgstr "" - -#: ../source/specifications/core-metadata.rst:69 -msgid "Added additional restrictions on format from :pep:`508`" -msgstr "" - -#: ../source/specifications/core-metadata.rst:72 -msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:88 -msgid "Version" -msgstr "" - -#: ../source/specifications/core-metadata.rst:92 -msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:101 -msgid "Dynamic (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:105 -msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." -msgstr "" - -#: ../source/specifications/core-metadata.rst:108 -msgid "When found in the metadata of a source distribution, the following rules apply:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:111 -msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." -msgstr "" - -#: ../source/specifications/core-metadata.rst:115 -msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:118 -msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:122 -msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." -msgstr "" - -#: ../source/specifications/core-metadata.rst:127 -msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:131 -msgid "Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:135 -msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." -msgstr "" - -#: ../source/specifications/core-metadata.rst:146 -msgid "Supported-Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:150 -msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." -msgstr "" - -#: ../source/specifications/core-metadata.rst:164 -msgid "Summary" -msgstr "" - -#: ../source/specifications/core-metadata.rst:168 -msgid "A one-line summary of what the distribution does." -msgstr "" - -#: ../source/specifications/core-metadata.rst:188 -msgid "This field may be specified in the message body instead." -msgstr "" - -#: ../source/specifications/core-metadata.rst:191 -msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:196 -msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." -msgstr "" - -#: ../source/specifications/core-metadata.rst:202 -msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:219 -msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." -msgstr "" - -#: ../source/specifications/core-metadata.rst:223 -msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:232 -msgid "Description-Content-Type" -msgstr "" - -#: ../source/specifications/core-metadata.rst:236 -msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:239 -msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." -msgstr "" - -#: ../source/specifications/core-metadata.rst:253 -msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:259 -msgid "Format::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:263 -msgid "The ``type/subtype`` part has only a few legal values:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:265 -msgid "``text/plain``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:266 -msgid "``text/x-rst``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:267 -msgid "``text/markdown``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:269 -msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:273 -msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:278 -msgid "``GFM`` for `Github-flavored Markdown `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:280 -msgid "``CommonMark`` for `CommonMark `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:299 -msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." -msgstr "" - -#: ../source/specifications/core-metadata.rst:303 -msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:307 -msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:311 -msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." -msgstr "" - -#: ../source/specifications/core-metadata.rst:320 -msgid "Keywords" -msgstr "" - -#: ../source/specifications/core-metadata.rst:324 -msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." -msgstr "" - -#: ../source/specifications/core-metadata.rst:333 -msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." -msgstr "" - -#: ../source/specifications/core-metadata.rst:341 -msgid "Home-page" -msgstr "" - -#: ../source/specifications/core-metadata.rst:345 -msgid "A string containing the URL for the distribution's home page." -msgstr "" - -#: ../source/specifications/core-metadata.rst:353 -msgid "Download-URL" -msgstr "" - -#: ../source/specifications/core-metadata.rst:357 -msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:366 -msgid "Author" -msgstr "" - -#: ../source/specifications/core-metadata.rst:370 -msgid "A string containing the author's name at a minimum; additional contact information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:383 -msgid "Author-email" -msgstr "" - -#: ../source/specifications/core-metadata.rst:387 -msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:395 -#: ../source/specifications/core-metadata.rst:442 -msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:405 -msgid "Maintainer" -msgstr "" - -#: ../source/specifications/core-metadata.rst:409 -msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:412 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:426 -msgid "Maintainer-email" -msgstr "" - -#: ../source/specifications/core-metadata.rst:430 -msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:434 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:452 -msgid "License" -msgstr "" - -#: ../source/specifications/core-metadata.rst:456 -msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." -msgstr "" - -#: ../source/specifications/core-metadata.rst:476 -msgid "Classifier (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:480 -msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:485 -#: ../source/specifications/core-metadata.rst:574 -#: ../source/specifications/core-metadata.rst:691 -#: ../source/specifications/core-metadata.rst:715 -msgid "This field may be followed by an environment marker after a semicolon." -msgstr "" - -#: ../source/specifications/core-metadata.rst:496 -msgid "Requires-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:499 -#: ../source/specifications/core-metadata.rst:561 -#: ../source/specifications/core-metadata.rst:663 -#: ../source/specifications/core-metadata.rst:704 -msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." -msgstr "" - -#: ../source/specifications/core-metadata.rst:503 -msgid "Each entry contains a string naming some other distutils project required by this distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:506 -msgid "The format of a requirement string contains from one to four parts:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:508 -msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." -msgstr "" - -#: ../source/specifications/core-metadata.rst:510 -msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." -msgstr "" - -#: ../source/specifications/core-metadata.rst:513 -msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:516 -msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." -msgstr "" - -#: ../source/specifications/core-metadata.rst:519 -msgid "See :pep:`508` for full details of the allowed format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:521 -msgid "The project names should correspond to names as found on the `Python Package Index`_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:524 -msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:538 -msgid "Requires-Python" -msgstr "" - -#: ../source/specifications/core-metadata.rst:542 -msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." -msgstr "" - -#: ../source/specifications/core-metadata.rst:546 -msgid "The value must be in the format specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:548 -msgid "This field cannot be followed by an environment marker." -msgstr "" - -#: ../source/specifications/core-metadata.rst:558 -msgid "Requires-External (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:565 -msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:570 -msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:576 -msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." -msgstr "" - -#: ../source/specifications/core-metadata.rst:581 -msgid "Notice that there is no particular rule on the strings to be used." -msgstr "" - -#: ../source/specifications/core-metadata.rst:593 -msgid "Project-URL (multiple-use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:597 -msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." -msgstr "" - -#: ../source/specifications/core-metadata.rst:604 -msgid "The label is free text limited to 32 characters." -msgstr "" - -#: ../source/specifications/core-metadata.rst:612 -msgid "Provides-Extra (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:616 -msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." -msgstr "" - -#: ../source/specifications/core-metadata.rst:625 -msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:635 -msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." -msgstr "" - -#: ../source/specifications/core-metadata.rst:639 -msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:644 -msgid "Rarely Used Fields" -msgstr "" - -#: ../source/specifications/core-metadata.rst:646 -msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:651 -msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." -msgstr "" - -#: ../source/specifications/core-metadata.rst:660 -msgid "Provides-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:667 -msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:672 -msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:679 -msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:687 -msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." -msgstr "" - -#: ../source/specifications/core-metadata.rst:701 -msgid "Obsoletes-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:708 -msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." -msgstr "" - -#: ../source/specifications/core-metadata.rst:712 -msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:717 -msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:730 -msgid "reStructuredText markup: http://docutils.sourceforge.net/" -msgstr "" - -#: ../source/specifications/core-metadata.rst:735 -msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:6 -msgid "Declaring build system dependencies" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:8 -msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:5 -msgid "Declaring project metadata" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:7 -msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:12 -msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:18 -msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:27 -msgid "The only fields required to be statically defined are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:29 -#: ../source/specifications/declaring-project-metadata.rst:41 -msgid "``name``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:31 -msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:34 -#: ../source/specifications/declaring-project-metadata.rst:54 -msgid "``version``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:36 -msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:43 -#: ../source/specifications/declaring-project-metadata.rst:56 -#: ../source/specifications/declaring-project-metadata.rst:68 -#: ../source/specifications/declaring-project-metadata.rst:117 -msgid "TOML_ type: string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:44 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:47 -msgid "The name of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:49 -msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:57 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:60 -msgid "The version of the project as supported by :pep:`440`." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:62 -msgid "Users SHOULD prefer to specify already-normalized versions." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:66 -msgid "``description``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:69 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:72 -msgid "The summary description of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:76 -msgid "``readme``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:78 -msgid "TOML_ type: string or table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:79 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:83 -msgid "The full description of the project (i.e. the README)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:85 -msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:96 -msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:103 -msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:115 -msgid "``requires-python``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:118 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:121 -msgid "The Python version requirements of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:125 -msgid "``license``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:127 -msgid "TOML_ type: table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:128 -msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:131 -msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:140 -msgid "``authors``/``maintainers``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:142 -msgid "TOML_ type: Array of inline tables with string keys and values" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:143 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:149 -msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:154 -msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:157 -msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:163 -msgid "Using the data to fill in :ref:`core metadata ` is as follows:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:166 -msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:169 -msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:173 -msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:177 -msgid "Multiple values should be separated by commas." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:181 -msgid "``keywords``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:183 -#: ../source/specifications/declaring-project-metadata.rst:193 -msgid "TOML_ type: array of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:184 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:187 -msgid "The keywords for the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:191 -msgid "``classifiers``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:194 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:197 -msgid "Trove classifiers which apply to the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:201 -msgid "``urls``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:203 -msgid "TOML_ type: table with keys and values of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:204 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:207 -msgid "A table of URLs where the key is the URL label and the value is the URL itself." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:212 -msgid "Entry points" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:214 -msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:216 -msgid ":ref:`Entry points specification `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:218 -msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:224 -msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:228 -msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:234 -msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:242 -msgid "``dependencies``/``optional-dependencies``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:244 -msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:247 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:251 -msgid "The (optional) dependencies of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:253 -msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:258 -msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:269 -msgid "``dynamic``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:271 -msgid "TOML_ type: array of string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:272 -msgid "A corresponding :ref:`core metadata ` field does not exist" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:275 -msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:281 -msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:283 -msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:285 -msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:290 -msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:294 -msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:296 -msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:300 -msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:6 -msgid "Dependency specifiers" -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:8 -msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:11 -msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." -msgstr "" - -#: ../source/specifications/direct-url.rst:6 -msgid "Recording the Direct URL Origin of installed distributions" -msgstr "" - -#: ../source/specifications/direct-url.rst:8 -msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." -msgstr "" - -#: ../source/specifications/direct-url.rst:17 -msgid "Specification" -msgstr "" - -#: ../source/specifications/direct-url.rst:19 -msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/direct-url.rst:23 -#: ../source/specifications/recording-installed-packages.rst:206 -msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." -msgstr "" - -#: ../source/specifications/direct-url.rst:26 -msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." -msgstr "" - -#: ../source/specifications/direct-url.rst:29 -msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." -msgstr "" - -#: ../source/specifications/direct-url.rst:36 -msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." -msgstr "" - -#: ../source/specifications/direct-url.rst:39 -msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" -msgstr "" - -#: ../source/specifications/direct-url.rst:45 -msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." -msgstr "" - -#: ../source/specifications/direct-url.rst:49 -msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" -msgstr "" - -#: ../source/specifications/direct-url.rst:52 -msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." -msgstr "" - -#: ../source/specifications/direct-url.rst:58 -msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." -msgstr "" - -#: ../source/specifications/direct-url.rst:61 -msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." -msgstr "" - -#: ../source/specifications/direct-url.rst:68 -msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:71 -msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." -msgstr "" - -#: ../source/specifications/direct-url.rst:78 -msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:81 -msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." -msgstr "" - -#: ../source/specifications/direct-url.rst:84 -msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." -msgstr "" - -#: ../source/specifications/direct-url.rst:91 -msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." -msgstr "" - -#: ../source/specifications/direct-url.rst:96 -msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." -msgstr "" - -#: ../source/specifications/direct-url.rst:102 -msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." -msgstr "" - -#: ../source/specifications/direct-url.rst:110 -msgid "Registered VCS" -msgstr "" - -#: ../source/specifications/direct-url.rst:112 -msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." -msgstr "" - -#: ../source/specifications/direct-url.rst:122 -msgid "Git" -msgstr "" - -#: ../source/specifications/direct-url.rst:124 -#: ../source/specifications/direct-url.rst:156 -#: ../source/specifications/direct-url.rst:179 -#: ../source/specifications/direct-url.rst:202 -msgid "Home page" -msgstr "" - -#: ../source/specifications/direct-url.rst:126 -msgid "https://git-scm.com/" -msgstr "" - -#: ../source/specifications/direct-url.rst:128 -#: ../source/specifications/direct-url.rst:160 -#: ../source/specifications/direct-url.rst:183 -#: ../source/specifications/direct-url.rst:206 -msgid "vcs command" -msgstr "" - -#: ../source/specifications/direct-url.rst:130 -#: ../source/specifications/direct-url.rst:134 -msgid "git" -msgstr "" - -#: ../source/specifications/direct-url.rst:132 -#: ../source/specifications/direct-url.rst:164 -#: ../source/specifications/direct-url.rst:187 -#: ../source/specifications/direct-url.rst:210 -msgid "``vcs`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:136 -#: ../source/specifications/direct-url.rst:168 -#: ../source/specifications/direct-url.rst:191 -#: ../source/specifications/direct-url.rst:214 -msgid "``requested_revision`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:138 -msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." -msgstr "" - -#: ../source/specifications/direct-url.rst:141 -#: ../source/specifications/direct-url.rst:172 -#: ../source/specifications/direct-url.rst:195 -#: ../source/specifications/direct-url.rst:219 -msgid "``commit_id`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:143 -msgid "A commit hash (40 hexadecimal characters sha1)." -msgstr "" - -#: ../source/specifications/direct-url.rst:147 -msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." -msgstr "" - -#: ../source/specifications/direct-url.rst:154 -msgid "Mercurial" -msgstr "" - -#: ../source/specifications/direct-url.rst:158 -msgid "https://www.mercurial-scm.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:162 -#: ../source/specifications/direct-url.rst:166 -msgid "hg" -msgstr "" - -#: ../source/specifications/direct-url.rst:170 -msgid "A tag name, branch name, changeset ID, shortened changeset ID." -msgstr "" - -#: ../source/specifications/direct-url.rst:174 -msgid "A changeset ID (40 hexadecimal characters)." -msgstr "" - -#: ../source/specifications/direct-url.rst:177 -msgid "Bazaar" -msgstr "" - -#: ../source/specifications/direct-url.rst:181 -msgid "https://bazaar.canonical.com/" -msgstr "" - -#: ../source/specifications/direct-url.rst:185 -#: ../source/specifications/direct-url.rst:189 -msgid "bzr" -msgstr "" - -#: ../source/specifications/direct-url.rst:193 -msgid "A tag name, branch name, revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:197 -msgid "A revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:200 -msgid "Subversion" -msgstr "" - -#: ../source/specifications/direct-url.rst:204 -msgid "https://subversion.apache.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:208 -#: ../source/specifications/direct-url.rst:212 -msgid "svn" -msgstr "" - -#: ../source/specifications/direct-url.rst:216 -msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." -msgstr "" - -#: ../source/specifications/direct-url.rst:221 -msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." -msgstr "" - -#: ../source/specifications/direct-url.rst:229 -msgid "Example direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:231 -msgid "Source archive:" -msgstr "" - -#: ../source/specifications/direct-url.rst:242 -msgid "Git URL with tag and commit-hash:" -msgstr "" - -#: ../source/specifications/direct-url.rst:255 -msgid "Local directory:" -msgstr "" - -#: ../source/specifications/direct-url.rst:264 -msgid "Local directory installed in editable mode:" -msgstr "" - -#: ../source/specifications/direct-url.rst:277 -msgid "Example pip commands and their effect on direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:279 -msgid "Commands that generate a ``direct_url.json``:" -msgstr "" - -#: ../source/specifications/direct-url.rst:281 -msgid "pip install https://example.com/app-1.0.tgz" -msgstr "" - -#: ../source/specifications/direct-url.rst:282 -msgid "pip install https://example.com/app-1.0.whl" -msgstr "" - -#: ../source/specifications/direct-url.rst:283 -msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" -msgstr "" - -#: ../source/specifications/direct-url.rst:284 -msgid "pip install ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:285 -msgid "pip install file:///home/user/app" -msgstr "" - -#: ../source/specifications/direct-url.rst:286 -msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" -msgstr "" - -#: ../source/specifications/direct-url.rst:290 -msgid "pip install -e ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:292 -msgid "Commands that *do not* generate a ``direct_url.json``" -msgstr "" - -#: ../source/specifications/direct-url.rst:294 -msgid "pip install app" -msgstr "" - -#: ../source/specifications/direct-url.rst:295 -msgid "pip install app --no-index --find-links https://example.com/" -msgstr "" - -#: ../source/specifications/entry-points.rst:5 -msgid "Entry points specification" -msgstr "" - -#: ../source/specifications/entry-points.rst:7 -msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" -msgstr "" - -#: ../source/specifications/entry-points.rst:11 -msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." -msgstr "" - -#: ../source/specifications/entry-points.rst:14 -msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." -msgstr "" - -#: ../source/specifications/entry-points.rst:19 -msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." -msgstr "" - -#: ../source/specifications/entry-points.rst:28 -msgid "Data model" -msgstr "" - -#: ../source/specifications/entry-points.rst:30 -msgid "Conceptually, an entry point is defined by three required properties:" -msgstr "" - -#: ../source/specifications/entry-points.rst:32 -msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:42 -msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:51 -msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:64 -msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." -msgstr "" - -#: ../source/specifications/entry-points.rst:68 -msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." -msgstr "" - -#: ../source/specifications/entry-points.rst:73 -msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." -msgstr "" - -#: ../source/specifications/entry-points.rst:80 -msgid "File format" -msgstr "" - -#: ../source/specifications/entry-points.rst:82 -msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." -msgstr "" - -#: ../source/specifications/entry-points.rst:87 -msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:97 -msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:100 -msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." -msgstr "" - -#: ../source/specifications/entry-points.rst:104 -msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." -msgstr "" - -#: ../source/specifications/entry-points.rst:112 -msgid "For example::" -msgstr "" - -#: ../source/specifications/entry-points.rst:124 -msgid "Use for scripts" -msgstr "" - -#: ../source/specifications/entry-points.rst:126 -msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." -msgstr "" - -#: ../source/specifications/entry-points.rst:134 -msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:141 -msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." -msgstr "" - -#: ../source/specifications/entry-points.rst:149 -msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." -msgstr "" - -#: ../source/specifications/entry-points.rst:154 -msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." -msgstr "" - -#: ../source/specifications/index.rst:4 -msgid "PyPA specifications" -msgstr "" - -#: ../source/specifications/index.rst:6 -msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." -msgstr "" - -#: ../source/specifications/index.rst:13 -msgid "Package Distribution Metadata" -msgstr "" - -#: ../source/specifications/index.rst:30 -msgid "Package Distribution File Formats" -msgstr "" - -#: ../source/specifications/index.rst:40 -msgid "Package Index Interfaces" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:6 -msgid "Platform compatibility tags" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:8 -msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:12 -msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:16 -msgid "Platform tags for Windows" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:18 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:22 -msgid "Platform tags for macOS (Mac OS X)" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:24 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:28 -msgid "Platform tags for common Linux distributions" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:32 -msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:36 -msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:41 -msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:44 -msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:46 -msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:49 -msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:54 -msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:59 -msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:65 -msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:71 -msgid "Manylinux compatibility support" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:74 -msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:76 -msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:79 -msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "Tool" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux1``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2010``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2014``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux_x_y``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=8.1.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=20.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "auditwheel" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=1.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=2.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.3.0`` [#]_" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:90 -msgid "Platform tags for other \\*nix platforms" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:92 -msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:98 -msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" -msgstr "" - -#: ../source/specifications/pypirc.rst:6 -msgid "The :file:`.pypirc` file" -msgstr "" - -#: ../source/specifications/pypirc.rst:8 -msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." -msgstr "" - -#: ../source/specifications/pypirc.rst:13 -msgid "The format (originally defined by the :ref:`distutils` package) is:" -msgstr "" - -#: ../source/specifications/pypirc.rst:32 -msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:35 -msgid "Each section describing a repository defines three fields:" -msgstr "" - -#: ../source/specifications/pypirc.rst:37 -msgid "``repository``: The URL of the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:38 -msgid "``username``: The registered username on the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:39 -msgid "``password``: The password that will used to authenticate the username." -msgstr "" - -#: ../source/specifications/pypirc.rst:43 -msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." -msgstr "" - -#: ../source/specifications/pypirc.rst:47 -msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" -msgstr "" - -#: ../source/specifications/pypirc.rst:57 -msgid "Common configurations" -msgstr "" - -#: ../source/specifications/pypirc.rst:61 -msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." -msgstr "" - -#: ../source/specifications/pypirc.rst:66 -msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" -msgstr "" - -#: ../source/specifications/pypirc.rst:82 -msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." -msgstr "" - -#: ../source/specifications/pypirc.rst:86 -msgid "Using a PyPI token" -msgstr "" - -#: ../source/specifications/pypirc.rst:88 -msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" -msgstr "" - -#: ../source/specifications/pypirc.rst:97 -msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." -msgstr "" - -#: ../source/specifications/pypirc.rst:103 -msgid "Using another package index" -msgstr "" - -#: ../source/specifications/pypirc.rst:105 -msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" -msgstr "" - -#: ../source/specifications/pypirc.rst:132 -msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:5 -msgid "Recording installed projects" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:7 -msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:12 -msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:21 -msgid "History and change workflow" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:23 -msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:29 -msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:37 -msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:41 -msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:50 -msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:60 -msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:69 -msgid "This ``.dist-info`` directory can contain these files, described in detail below:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:72 -msgid "``METADATA``: contains project metadata" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:73 -msgid "``RECORD``: records the list of installed files." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:74 -msgid "``INSTALLER``: records the name of the tool used to install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:76 -msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:82 -msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:87 -msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:94 -msgid "The METADATA file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:96 -msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:99 -msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:105 -msgid "The RECORD file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:107 -msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:110 -msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:113 -msgid "field delimiter: ``,`` (comma)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:114 -msgid "quoting char: ``\"`` (straight double quote)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:115 -msgid "line terminator: either ``\\r\\n`` or ``\\n``." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:117 -msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:120 -msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:125 -msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:130 -msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:133 -msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:139 -msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:146 -msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:151 -msgid "Here is an example snippet of a possible ``RECORD`` file::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:170 -msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:177 -msgid "The INSTALLER file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:179 -msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:185 -msgid "The file can be terminated by zero or more ASCII whitespace characters." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:187 -msgid "Here are examples of two possible ``INSTALLER`` files::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:195 -msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:201 -msgid "The direct_url.json file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:203 -msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:209 -msgid "Its detailed specification is at :ref:`direct-url`." -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:6 -msgid "Simple repository API" -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:8 -msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:6 -msgid "Source distribution format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:8 -msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:13 -msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:21 -msgid "Source distributions are also known as *sdists* for short." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:24 -msgid "Source distribution file name" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:26 -msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:31 -msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:35 -msgid "Source distribution file format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:37 -msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:45 -msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:48 -msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:6 -msgid "Version specifiers" -msgstr "" - -#: ../source/specifications/version-specifiers.rst:8 -msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:11 -msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." -msgstr "" - -#: ../source/support.rst:3 -msgid "How to Get Support" -msgstr "" - -#: ../source/support.rst:5 -msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." -msgstr "" - -#: ../source/support.rst:8 -msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:5 -msgid "Creating Documentation" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:7 -msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:13 -msgid "Installing Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:14 -msgid "Use ``pip`` to install Sphinx:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:28 -msgid "For other installation methods, see this `installation guide`_ by Sphinx." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:33 -msgid "Getting Started With Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:35 -msgid "Create a ``docs`` directory inside your project to hold your documentation:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:42 -msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:49 -msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:51 -msgid "You can add some information about your project in ``index.rst``, then build them:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:57 -msgid "For more details on the build process, see this `guide`_ by Read The Docs." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:62 -msgid "Other Sources" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:64 -msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/index.rst:4 -msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:5 -msgid "Installing Packages" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:7 -msgid "This section covers the basics of how to install Python :term:`packages `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:10 -msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:28 -msgid "Requirements for Installing Packages" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:30 -msgid "This section describes the steps to follow before installing other Python packages." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:35 -msgid "Ensure you can run Python from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:37 -msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:53 -msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:57 -msgid "If you're a newcomer and you get an error like this:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:66 -msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:72 -msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:82 -msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:87 -msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:99 -msgid "Ensure you can run pip from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:101 -msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:116 -msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:124 -msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:139 -msgid "If that still doesn't allow you to run ``python -m pip``:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:141 -msgid "Securely Download `get-pip.py `_ [1]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:144 -msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:150 -msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:159 -msgid "Ensure pip, setuptools, and wheel are up to date" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:161 -msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:169 -msgid "Optionally, create a virtual environment" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:171 -msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:188 -msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:195 -msgid "Creating Virtual Environments" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:197 -msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:203 -msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:209 -msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:213 -msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:216 -msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:220 -msgid "Currently, there are two common tools for creating Python virtual environments:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:222 -msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:225 -msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:230 -msgid "The basic usage is like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:232 -msgid "Using `venv`_:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:248 -msgid "Using :ref:`virtualenv`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:264 -msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:266 -msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:271 -msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:281 -msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:288 -msgid "Use pip for Installing" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:290 -msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:297 -msgid "Installing from PyPI" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:299 -msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:307 -msgid "To install the latest version of \"SomeProject\":" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:321 -msgid "To install a specific version:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:335 -msgid "To install greater than or equal to one version and less than another:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:350 -msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:365 -msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:370 -msgid "Source Distributions vs Wheels" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:372 -msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:378 -msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:383 -msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:391 -msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:408 -msgid "Installing to the User Site" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:410 -msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:425 -msgid "For more information see the `User Installs `_ section from the pip docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:429 -msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:432 -msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:440 -msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:446 -msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:462 -msgid "Install a list of requirements specified in a :ref:`Requirements File `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:478 -msgid "Installing from VCS" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:480 -msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:502 -msgid "Installing from other Indexes" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:504 -msgid "Install from an alternate index" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:518 -msgid "Search an additional index during install, in addition to :term:`PyPI `" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:534 -msgid "Installing from a local src tree" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:537 -msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:554 -msgid "You can also install normally from src" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:571 -msgid "Install a particular source archive file." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:585 -msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:605 -msgid "Installing from other sources" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:607 -msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:619 -msgid "Installing Prereleases" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:621 -msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:637 -msgid "Installing Setuptools \"Extras\"" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:639 -msgid "Install `setuptools extras`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:659 -msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:668 -msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:673 -msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:4 -msgid "Managing Application Dependencies" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:6 -msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:9 -msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:13 -msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:17 -msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:24 -msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:30 -msgid "Installing Pipenv" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:32 -msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:38 -msgid "Use ``pip`` to install Pipenv:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:54 -msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:65 -msgid "Installing packages for your project" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:67 -msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:76 -msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:112 -msgid "Using installed packages" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:114 -msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:125 -msgid "Then you can run this script using ``pipenv run``:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:131 -msgid "You should get output similar to this:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:137 -msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:143 -#: ../source/tutorials/packaging-projects.rst:594 -msgid "Next steps" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:145 -msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:148 -msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:151 -msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:160 -msgid "Other Tools for Application Dependency Management" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:162 -msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:166 -msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:172 -msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:175 -msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:177 -msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:2 -msgid "Packaging Python Projects" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:4 -msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:10 -msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:18 -msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:35 -msgid "A simple project" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:37 -msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:41 -msgid "Create the following file structure locally:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:51 -msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:54 -msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:63 -msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:67 -msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:75 -msgid "Creating the package files" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:77 -msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:95 -msgid "Creating a test directory" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:97 -msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:101 -msgid "Creating pyproject.toml" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:103 -msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:117 -msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:121 -msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:127 -msgid "See :pep:`517` and :pep:`518` for background and details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:131 -msgid "Configuring metadata" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:133 -msgid "There are two types of metadata: static and dynamic." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:135 -msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:137 -msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:141 -msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:148 -msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:153 -msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:185 -msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:191 -#: ../source/tutorials/packaging-projects.rst:286 -msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:196 -msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:199 -#: ../source/tutorials/packaging-projects.rst:293 -msgid "``author`` and ``author_email`` are used to identify the author of the package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:201 -#: ../source/tutorials/packaging-projects.rst:295 -msgid "``description`` is a short, one-sentence summary of the package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:202 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:206 -#: ../source/tutorials/packaging-projects.rst:300 -msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:208 -#: ../source/tutorials/packaging-projects.rst:302 -msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:211 -#: ../source/tutorials/packaging-projects.rst:305 -msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:213 -#: ../source/tutorials/packaging-projects.rst:307 -msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:221 -msgid "In the ``options`` category, we have controls for setuptools itself:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:223 -msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:227 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:234 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:238 -#: ../source/tutorials/packaging-projects.rst:329 -msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:244 -msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:248 -msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:283 -msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:291 -msgid "``version`` is the package version. See :pep:`440` for more details on versions." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:296 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:314 -msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:319 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:325 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:333 -msgid "Creating README.md" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:335 -msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:347 -msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:354 -msgid "Creating a LICENSE" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:356 -msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:387 -msgid "Including other files" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:389 -msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:393 -msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:402 -msgid "Generating distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:404 -msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:408 -msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:422 -msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:425 -msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:439 -msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:449 -msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:458 -msgid "Uploading the distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:460 -msgid "Finally, it's time to upload your package to the Python Package Index!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:462 -msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:470 -msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:477 -msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:492 -msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:506 -msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:510 -msgid "After the command completes, you should see output similar to this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:523 -msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:528 -msgid "Installing your newly uploaded package" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:530 -msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:546 -msgid "Make sure to specify your username in the package name!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:548 -msgid "pip should install the package from TestPyPI and the output should look something like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:558 -msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:565 -msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:580 -msgid "and import the package:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:588 -msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:596 -msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:599 -msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:604 -msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:608 -msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:610 -msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:613 -msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:617 -msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:619 -msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:622 -msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:624 -msgid "Read about :doc:`/guides/packaging-binary-extensions`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:625 -msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." -msgstr "" diff --git a/locales/ru/LC_MESSAGES/messages.po b/locales/ru/LC_MESSAGES/messages.po deleted file mode 100644 index 4a2c2835a..000000000 --- a/locales/ru/LC_MESSAGES/messages.po +++ /dev/null @@ -1,9302 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2013–2020, PyPA -# This file is distributed under the same license as the Python Packaging User Guide package. -# Mingun , 2021. -# Vita Markova , 2021. -msgid "" -msgstr "" -"Project-Id-Version: Python Packaging User Guide\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-10-09 10:22+0000\n" -"Last-Translator: Vita Markova \n" -"Language-Team: Russian \n" -"Language: ru\n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=UTF-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && n" -"%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n" -"X-Generator: Weblate 4.9-dev\n" - -#: ../source/contribute.rst:5 -msgid "Contribute to this guide" -msgstr "Внесение своего вклада в это руководство" - -#: ../source/contribute.rst:7 -msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" -msgstr "" -"|PyPUG| приветствует участников! Существует множество способов нам помочь, в " -"том числе:" - -#: ../source/contribute.rst:10 -msgid "Reading the guide and giving feedback" -msgstr "Чтение руководства и предоставление обратной связи" - -#: ../source/contribute.rst:11 -msgid "Reviewing new contributions" -msgstr "Проверка новых вкладов" - -#: ../source/contribute.rst:12 -msgid "Revising existing content" -msgstr "Пересмотр существующего материала" - -#: ../source/contribute.rst:13 -msgid "Writing new content" -msgstr "Написание нового материала" - -#: ../source/contribute.rst:15 -msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." -msgstr "" - -#: ../source/contribute.rst:24 -msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." -msgstr "" - -#: ../source/contribute.rst:31 -msgid "Documentation types" -msgstr "Типы документации" - -#: ../source/contribute.rst:33 -msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." -msgstr "" -"Проект состоит из четырёх разных типов документации с определённым " -"назначением. Пожалуйста, выбирайте подходящий тип документации, когда " -"предлагаете изменения." - -#: ../source/contribute.rst:38 -#: ../source/tutorials/index.rst:2 -msgid "Tutorials" -msgstr "Учебники" - -#: ../source/contribute.rst:40 -msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." -msgstr "" - -#: ../source/contribute.rst:47 -#: ../source/guides/index.rst:2 -msgid "Guides" -msgstr "Руководства" - -#: ../source/contribute.rst:49 -msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." -msgstr "" - -#: ../source/contribute.rst:56 -#: ../source/discussions/index.rst:2 -msgid "Discussions" -msgstr "Обсуждения" - -#: ../source/contribute.rst:58 -msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." -msgstr "" - -#: ../source/contribute.rst:63 -msgid "Specifications" -msgstr "Спецификации" - -#: ../source/contribute.rst:65 -msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." -msgstr "" - -#: ../source/contribute.rst:73 -msgid "Building the guide locally" -msgstr "" - -#: ../source/contribute.rst:75 -msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" -msgstr "" - -#: ../source/contribute.rst:79 -msgid "`Nox `_. You can install or upgrade nox using ``pip``::" -msgstr "" - -#: ../source/contribute.rst:84 -msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." -msgstr "" - -#: ../source/contribute.rst:91 -msgid "To build the guide, run the following bash command in the source folder::" -msgstr "" -"Для сборки руководства выполните в каталоге с исходными файлами следующую " -"bash-команду::" - -#: ../source/contribute.rst:95 -msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." -msgstr "" - -#: ../source/contribute.rst:100 -msgid "You can build the guide and serve it via an HTTP server using the following command::" -msgstr "" - -#: ../source/contribute.rst:105 -msgid "The guide will be browsable via http://localhost:8000." -msgstr "" -"Руководство будет доступно для просмотра по адресу http://localhost:8000." - -#: ../source/contribute.rst:109 -msgid "Where the guide is deployed" -msgstr "" - -#: ../source/contribute.rst:111 -msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." -msgstr "" - -#: ../source/contribute.rst:117 -msgid "Style guide" -msgstr "" - -#: ../source/contribute.rst:119 -msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." -msgstr "" - -#: ../source/contribute.rst:126 -msgid "Purpose" -msgstr "Цель" - -#: ../source/contribute.rst:128 -msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." -msgstr "" - -#: ../source/contribute.rst:133 -msgid "Scope" -msgstr "Область действия" - -#: ../source/contribute.rst:135 -msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." -msgstr "" - -#: ../source/contribute.rst:138 -msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." -msgstr "" - -#: ../source/contribute.rst:146 -msgid "Audience" -msgstr "Аудитория" - -#: ../source/contribute.rst:148 -msgid "The audience of this guide is anyone who uses Python with packages." -msgstr "" - -#: ../source/contribute.rst:150 -msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." -msgstr "" - -#: ../source/contribute.rst:154 -msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." -msgstr "" - -#: ../source/contribute.rst:160 -msgid "Voice and tone" -msgstr "Голос и тон" - -#: ../source/contribute.rst:162 -msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." -msgstr "" - -#: ../source/contribute.rst:165 -msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." -msgstr "" - -#: ../source/contribute.rst:170 -msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." -msgstr "" - -#: ../source/contribute.rst:177 -msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." -msgstr "" - -#: ../source/contribute.rst:184 -msgid "Conventions and mechanics" -msgstr "Соглашения и механики" - -#: ../source/contribute.rst:192 -msgid "**Write to the reader**" -msgstr "**Пишите читателю**" - -#: ../source/contribute.rst:187 -msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." -msgstr "" -"Давая рекомендации или расписывая шаги, обращайтесь к читателю на *вы* или " -"используйте повелительное наклонение." - -#: ../source/contribute.rst:0 -msgid "Wrong: To install it, the user runs…" -msgstr "Неправильно: Чтобы установить его, пользователь запускает…" - -#: ../source/contribute.rst:0 -msgid "Right: You can install it by running…" -msgstr "Правильно: Вы можете установить его, запустив…" - -#: ../source/contribute.rst:0 -msgid "Right: To install it, run…" -msgstr "Правильно: Чтобы установить его, запустите…" - -#: ../source/contribute.rst:198 -msgid "**State assumptions**" -msgstr "" - -#: ../source/contribute.rst:195 -msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." -msgstr "" - -#: ../source/contribute.rst:203 -msgid "**Cross-reference generously**" -msgstr "" - -#: ../source/contribute.rst:201 -msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." -msgstr "" - -#: ../source/contribute.rst:213 -msgid "**Respect naming practices**" -msgstr "**Следуйте правилам именования**" - -#: ../source/contribute.rst:206 -msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." -msgstr "" -"При указании названий инструментов, сайтов, имён людей и других собственных " -"существительных используйте их предпочтительную капитализацию." - -#: ../source/contribute.rst:0 -msgid "Wrong: Pip uses…" -msgstr "Неправильно: Pip использует…" - -#: ../source/contribute.rst:0 -msgid "Right: pip uses…" -msgstr "Правильно: pip использует…" - -#: ../source/contribute.rst:0 -msgid "Wrong: …hosted on github." -msgstr "Неправильно: …размещён на github." - -#: ../source/contribute.rst:0 -msgid "Right: …hosted on GitHub." -msgstr "Правильно: …размещён на GitHub." - -#: ../source/contribute.rst:222 -msgid "**Use a gender-neutral style**" -msgstr "**Используйте гендерно-нейтральный стиль**" - -#: ../source/contribute.rst:216 -msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: A maintainer uploads the file. Then he…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then they…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then the maintainer…" -msgstr "" - -#: ../source/contribute.rst:234 -msgid "**Headings**" -msgstr "**Заголовки**" - -#: ../source/contribute.rst:225 -msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." -msgstr "" - -#: ../source/contribute.rst:230 -msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: Things You Should Know About Python" -msgstr "Неправильно: Всё, Что Вам Нужно Знать О Python'е" - -#: ../source/contribute.rst:0 -msgid "Right: Things you should know about Python" -msgstr "Правильно: Всё, что вам нужно знать о Python'е" - -#: ../source/contribute.rst:237 -msgid "**Numbers**" -msgstr "**Числа**" - -#: ../source/contribute.rst:237 -msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:4 -msgid "Deploying Python applications" -msgstr "Развёртывание приложений на Python'е" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Page Status" -msgstr "Статус страницы" - -#: ../source/discussions/deploying-python-applications.rst:6 -#: ../source/guides/index-mirrors-and-caches.rst:7 -#: ../source/guides/installing-using-linux-tools.rst:7 -#: ../source/guides/packaging-binary-extensions.rst:7 -#: ../source/guides/supporting-multiple-python-versions.rst:7 -#: ../source/guides/supporting-windows-using-appveyor.rst:5 -msgid "Incomplete" -msgstr "Не завершена" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Last Reviewed" -msgstr "Последняя проверка" - -#: ../source/discussions/deploying-python-applications.rst:7 -msgid "2014-11-11" -msgstr "2014-11-11" - -#: ../source/discussions/deploying-python-applications.rst:11 -#: ../source/discussions/install-requires-vs-requirements.rst:9 -#: ../source/guides/analyzing-pypi-package-downloads.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:22 -#: ../source/guides/index-mirrors-and-caches.rst:12 -#: ../source/guides/installing-scientific-packages.rst:9 -#: ../source/guides/packaging-binary-extensions.rst:17 -#: ../source/guides/supporting-multiple-python-versions.rst:12 -#: ../source/guides/supporting-windows-using-appveyor.rst:15 -#: ../source/overview.rst:23 -#: ../source/specifications/core-metadata.rst:38 -#: ../source/specifications/direct-url.rst:14 -#: ../source/tutorials/installing-packages.rst:23 -msgid "Contents" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:14 -msgid "Overview" -msgstr "Обзор" - -#: ../source/discussions/deploying-python-applications.rst:18 -msgid "Supporting multiple hardware platforms" -msgstr "Поддержка нескольких аппаратных платформ" - -#: ../source/discussions/deploying-python-applications.rst:40 -msgid "OS packaging & installers" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:52 -msgid "Windows" -msgstr "Windows" - -#: ../source/discussions/deploying-python-applications.rst:61 -msgid "Pynsist" -msgstr "Pynsist" - -#: ../source/discussions/deploying-python-applications.rst:63 -msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:70 -msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:74 -msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:80 -msgid "Application bundles" -msgstr "Комплекты приложений" - -#: ../source/discussions/deploying-python-applications.rst:91 -msgid "Configuration management" -msgstr "Управление конфигурацией" - -#: ../source/discussions/index.rst:4 -msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:5 -msgid "install_requires vs requirements files" -msgstr "Файл :file:`install_requires` против файла :file:`requirements`" - -#: ../source/discussions/install-requires-vs-requirements.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:382 -msgid "install_requires" -msgstr "install_requires" - -#: ../source/discussions/install-requires-vs-requirements.rst:14 -msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:19 -msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:29 -msgid "Additionally, it's best practice to indicate any known lower or upper bounds." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:31 -msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:41 -msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:51 -msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:56 -msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:64 -#: ../source/tutorials/installing-packages.rst:460 -msgid "Requirements files" -msgstr "Файлы требований" - -#: ../source/discussions/install-requires-vs-requirements.rst:66 -msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:69 -msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:73 -msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:78 -msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:84 -msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:90 -msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:6 -msgid "pip vs easy_install" -msgstr "``pip`` против ``easy_install``" - -#: ../source/discussions/pip-vs-easy-install.rst:9 -msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:14 -msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:22 -msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**pip**" -msgstr "**pip**" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**easy_install**" -msgstr "**easy_install**" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -msgid "Installs from :term:`Wheels `" -msgstr "Установка из :term:`колёс `" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Yes" -msgstr "Да" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:30 -#: ../source/discussions/pip-vs-easy-install.rst:32 -#: ../source/discussions/pip-vs-easy-install.rst:35 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:51 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "No" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Uninstall Packages" -msgstr "Удаление пакетов" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Yes (``python -m pip uninstall``)" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Dependency Overrides" -msgstr "Переопределение зависимостей" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Yes (:ref:`Requirements Files `)" -msgstr "Да (:ref:`Файлы требований `)" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "List Installed Packages" -msgstr "Перечисление установленных пакетов" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:38 -msgid ":pep:`438` Support" -msgstr "Поддержка :pep:`438`" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Installation format" -msgstr "Формат установки" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "'Flat' packages with :file:`egg-info` metadata." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Encapsulated Egg format" -msgstr "Формат инкапсулированного яйца" - -#: ../source/discussions/pip-vs-easy-install.rst:44 -msgid "sys.path modification" -msgstr "Изменение ``sys.path``" - -#: ../source/discussions/pip-vs-easy-install.rst:48 -msgid "Installs from :term:`Eggs `" -msgstr "Установка из :term:`яиц `" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "`pylauncher support`_" -msgstr "`Поддержка pylauncher`_" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "Yes [1]_" -msgstr "Да [1]_" - -#: ../source/discussions/pip-vs-easy-install.rst:54 -msgid ":ref:`Multi-version Installs`" -msgstr ":ref:`Много-версионные установки `" - -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Exclude scripts during install" -msgstr "Исключение скриптов во время установки" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "per project index" -msgstr "Индекс по проектам" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Only in virtualenv" -msgstr "Только в ``virtualenv``" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Yes, via setup.cfg" -msgstr "Да, через :file:`setup.cfg`" - -#: ../source/discussions/pip-vs-easy-install.rst:68 -msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" -msgstr "" -"https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" -"launcher" - -#: ../source/discussions/wheel-vs-egg.rst:5 -msgid "Wheel vs Egg" -msgstr "Колеса против яиц" - -#: ../source/discussions/wheel-vs-egg.rst:7 -msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:11 -msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:14 -msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:17 -msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:20 -msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:22 -msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:26 -msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:31 -msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:34 -msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:38 -msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:41 -msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:47 -msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." -msgstr "" - -#: ../source/glossary.rst:3 -msgid "Glossary" -msgstr "Словарь терминов" - -#: ../source/glossary.rst:8 -msgid "Binary Distribution" -msgstr "" - -#: ../source/glossary.rst:11 -msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." -msgstr "" - -#: ../source/glossary.rst:14 -msgid "Built Distribution" -msgstr "" - -#: ../source/glossary.rst:17 -msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." -msgstr "" - -#: ../source/glossary.rst:26 -msgid "Distribution Package" -msgstr "" - -#: ../source/glossary.rst:29 -msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." -msgstr "" - -#: ../source/glossary.rst:34 -msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." -msgstr "" - -#: ../source/glossary.rst:41 -msgid "Egg" -msgstr "" - -#: ../source/glossary.rst:44 -msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" -msgstr "" - -#: ../source/glossary.rst:49 -msgid "Extension Module" -msgstr "" - -#: ../source/glossary.rst:52 -msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." -msgstr "" - -#: ../source/glossary.rst:59 -msgid "Known Good Set (KGS)" -msgstr "Known Good Set (KGS, Известный хороший набор)" - -#: ../source/glossary.rst:62 -msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." -msgstr "" - -#: ../source/glossary.rst:68 -msgid "Import Package" -msgstr "Import Package (Импортируемый пакет)" - -#: ../source/glossary.rst:71 -msgid "A Python module which can contain other modules or recursively, other packages." -msgstr "" - -#: ../source/glossary.rst:74 -msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." -msgstr "" - -#: ../source/glossary.rst:78 -msgid "Module" -msgstr "Модуль" - -#: ../source/glossary.rst:81 -msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." -msgstr "" - -#: ../source/glossary.rst:84 -msgid "Package Index" -msgstr "" - -#: ../source/glossary.rst:87 -msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." -msgstr "" - -#: ../source/glossary.rst:90 -msgid "Per Project Index" -msgstr "" - -#: ../source/glossary.rst:93 -msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." -msgstr "" - -#: ../source/glossary.rst:97 -msgid "Project" -msgstr "Проект" - -#: ../source/glossary.rst:100 -msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." -msgstr "" - -#: ../source/glossary.rst:104 -msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." -msgstr "" - -#: ../source/glossary.rst:110 -msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." -msgstr "" - -#: ../source/glossary.rst:115 -msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." -msgstr "" - -#: ../source/glossary.rst:121 -msgid "Pure Module" -msgstr "" - -#: ../source/glossary.rst:124 -msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." -msgstr "" - -#: ../source/glossary.rst:127 -msgid "Python Packaging Authority (PyPA)" -msgstr "" - -#: ../source/glossary.rst:130 -msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." -msgstr "" - -#: ../source/glossary.rst:139 -msgid "Python Package Index (PyPI)" -msgstr "" - -#: ../source/glossary.rst:142 -msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." -msgstr "" - -#: ../source/glossary.rst:145 -msgid "pypi.org" -msgstr "pypi.org" - -#: ../source/glossary.rst:148 -msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." -msgstr "" - -#: ../source/glossary.rst:152 -msgid "pyproject.toml" -msgstr "" - -#: ../source/glossary.rst:155 -msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." -msgstr "" - -#: ../source/glossary.rst:157 -msgid "Release" -msgstr "Выпуск" - -#: ../source/glossary.rst:160 -msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." -msgstr "" - -#: ../source/glossary.rst:163 -msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." -msgstr "" - -#: ../source/glossary.rst:168 -msgid "Requirement" -msgstr "Требование" - -#: ../source/glossary.rst:171 -msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." -msgstr "" - -#: ../source/glossary.rst:177 -msgid "Requirement Specifier" -msgstr "" - -#: ../source/glossary.rst:180 -msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" -msgstr "" - -#: ../source/glossary.rst:187 -msgid "Requirements File" -msgstr "" - -#: ../source/glossary.rst:190 -msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." -msgstr "" - -#: ../source/glossary.rst:194 -#: ../source/guides/distributing-packages-using-setuptools.rst:56 -msgid "setup.py" -msgstr "setup.py" - -#: ../source/glossary.rst:195 -#: ../source/guides/distributing-packages-using-setuptools.rst:77 -msgid "setup.cfg" -msgstr "setup.cfg" - -#: ../source/glossary.rst:198 -msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." -msgstr "" - -#: ../source/glossary.rst:201 -msgid "Source Archive" -msgstr "" - -#: ../source/glossary.rst:204 -msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:208 -msgid "Source Distribution (or \"sdist\")" -msgstr "" - -#: ../source/glossary.rst:211 -msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:216 -msgid "System Package" -msgstr "" - -#: ../source/glossary.rst:219 -msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." -msgstr "" - -#: ../source/glossary.rst:222 -msgid "Version Specifier" -msgstr "" - -#: ../source/glossary.rst:225 -msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." -msgstr "" - -#: ../source/glossary.rst:231 -msgid "Virtual Environment" -msgstr "" - -#: ../source/glossary.rst:234 -msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/glossary.rst:238 -msgid "Wheel" -msgstr "" - -#: ../source/glossary.rst:241 -msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." -msgstr "" - -#: ../source/glossary.rst:244 -msgid "Working Set" -msgstr "" - -#: ../source/glossary.rst:247 -msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:3 -msgid "Analyzing PyPI package downloads" -msgstr "Анализ загрузок пакетов с PyPI" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:5 -msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:15 -#: ../source/guides/supporting-windows-using-appveyor.rst:18 -msgid "Background" -msgstr "Фон" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:17 -msgid "PyPI does not display download statistics for a number of reasons: [#]_" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:19 -msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:24 -msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:27 -msgid "``pip``'s download cache (lowers download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:28 -msgid "Internal or unofficial mirrors (can both raise or lower download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:29 -msgid "Packages not hosted on PyPI (for comparisons sake)" -msgstr "Пакеты, размещённые не на PyPI (для сравнения);" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:30 -msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:32 -msgid "Known historical data quality issues (lowers download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:34 -msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:38 -msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:43 -msgid "Public dataset" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:45 -msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:50 -msgid "Getting set up" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:52 -msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:58 -msgid "Navigate to the `BigQuery web UI`_." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:59 -msgid "Create a new project." -msgstr "Создайте новый проект." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:60 -msgid "Enable the `BigQuery API `__." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:63 -msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:69 -msgid "Data schema" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:71 -msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -msgid "Column" -msgstr "Колонка" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/guides/using-manifest-in.rst:67 -#: ../source/specifications/core-metadata.rst:185 -msgid "Description" -msgstr "Описание" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/specifications/direct-url.rst:226 -msgid "Examples" -msgstr "Примеры" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "timestamp" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "Date and time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "``2020-03-09 00:33:03 UTC``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "file.project" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "Project name" -msgstr "Название проекта" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "``pipenv``, ``nose``" -msgstr "``pipenv``, ``nose``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "file.version" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "Package version" -msgstr "Версия пакета" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "``0.1.6``, ``1.4.2``" -msgstr "``0.1.6``, ``1.4.2``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "details.installer.name" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "Installer" -msgstr "Установщик" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "pip, `bandersnatch`_" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "details.python" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "Python version" -msgstr "Версия Python’а" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "``2.7.12``, ``3.6.4``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:93 -msgid "Useful queries" -msgstr "Полезные запросы" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:95 -msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:97 -msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:102 -msgid "Counting package downloads" -msgstr "Подсчёт количества загрузок пакетов" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:104 -msgid "The following query counts the total number of downloads for the project \"pytest\"." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:119 -#: ../source/guides/analyzing-pypi-package-downloads.rst:140 -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "num_downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:121 -msgid "26190085" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:124 -msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:142 -msgid "24334215" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:146 -msgid "Package downloads over time" -msgstr "Загрузки пакетов с течением времени" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:148 -msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -msgid "month" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "1956741" -msgstr "1956741" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "2018-01-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2344692" -msgstr "2344692" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2017-12-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "1730398" -msgstr "1730398" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "2017-11-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2047310" -msgstr "2047310" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2017-10-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "1744443" -msgstr "1744443" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "2017-09-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "1916952" -msgstr "1916952" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "2017-08-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:184 -msgid "Python versions over time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:186 -msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "python" -msgstr "python" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "3.7" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "18051328726" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "3.6" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "9635067203" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "3.8" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "7781904681" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "2.7" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "6381252241" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "null" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "2026630299" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "3.5" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "1894153540" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:221 -msgid "Caveats" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:223 -msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:231 -msgid "Additional tools" -msgstr "Дополнительные инструменты" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:233 -msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:237 -msgid "``google-cloud-bigquery``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:239 -msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:267 -msgid "``pypinfo``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:269 -msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:273 -msgid "Install `pypinfo`_ using pip." -msgstr "Установите `pypinfo`_ через :program:`pip`." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:279 -msgid "Usage:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:295 -msgid "``pandas-gbq``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:297 -msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:301 -#: ../source/specifications/binary-distribution-format.rst:459 -msgid "References" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:303 -msgid "`PyPI Download Counts deprecation email `__" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:304 -msgid "`PyPI BigQuery dataset announcement email `__" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:3 -msgid "Creating and discovering plugins" -msgstr "Создание и обнаружение плагинов" - -#: ../source/guides/creating-and-discovering-plugins.rst:5 -msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:10 -msgid "There are three major approaches to doing automatic plugin discovery:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:12 -msgid "`Using naming convention`_." -msgstr "`Использование соглашения об именах`_." - -#: ../source/guides/creating-and-discovering-plugins.rst:13 -msgid "`Using namespace packages`_." -msgstr "`Использование пакетов пространства имён`_." - -#: ../source/guides/creating-and-discovering-plugins.rst:14 -msgid "`Using package metadata`_." -msgstr "`Использование метаданных пакета`_." - -#: ../source/guides/creating-and-discovering-plugins.rst:18 -msgid "Using naming convention" -msgstr "Использование соглашения об именах" - -#: ../source/guides/creating-and-discovering-plugins.rst:20 -msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:38 -msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:48 -msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:59 -msgid "Using namespace packages" -msgstr "Использование пакетов пространства имён" - -#: ../source/guides/creating-and-discovering-plugins.rst:61 -msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:89 -msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:101 -msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:115 -msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:121 -msgid "Using package metadata" -msgstr "Использование метаданных пакета" - -#: ../source/guides/creating-and-discovering-plugins.rst:123 -msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:128 -msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:139 -msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:154 -msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:163 -msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:166 -msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:170 -msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:5 -msgid "Packaging and distributing projects" -msgstr "Упаковка и распространение проектов" - -#: ../source/guides/distributing-packages-using-setuptools.rst:7 -msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:11 -msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:15 -msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:25 -msgid "Requirements for packaging and distributing" -msgstr "Требования к упаковке и распространению" - -#: ../source/guides/distributing-packages-using-setuptools.rst:26 -msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." -msgstr "" -"Во-первых, убедитесь, что вы уже выполнили :ref:`требования к установке " -"пакетов `." - -#: ../source/guides/distributing-packages-using-setuptools.rst:29 -msgid "Install \"twine\" [1]_:" -msgstr "Установите «twine» [1]_:" - -#: ../source/guides/distributing-packages-using-setuptools.rst:43 -msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:49 -msgid "Configuring your project" -msgstr "Настройка вашего проекта" - -#: ../source/guides/distributing-packages-using-setuptools.rst:53 -msgid "Initial files" -msgstr "Исходные файлы" - -#: ../source/guides/distributing-packages-using-setuptools.rst:58 -msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:63 -msgid ":file:`setup.py` serves two primary functions:" -msgstr "Файл :file:`setup.py` выполняет две основные функции:" - -#: ../source/guides/distributing-packages-using-setuptools.rst:65 -msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:71 -msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:79 -msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:86 -msgid "README.rst / README.md" -msgstr "README.rst / README.md" - -#: ../source/guides/distributing-packages-using-setuptools.rst:88 -msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:95 -msgid "For an example, see `README.md `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:99 -msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:108 -msgid "MANIFEST.in" -msgstr "MANIFEST.in" - -#: ../source/guides/distributing-packages-using-setuptools.rst:110 -msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:115 -msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:119 -msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:122 -msgid "LICENSE.txt" -msgstr "LICENSE.txt" - -#: ../source/guides/distributing-packages-using-setuptools.rst:124 -msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:130 -msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:135 -msgid "" -msgstr "<ваш пакет>" - -#: ../source/guides/distributing-packages-using-setuptools.rst:137 -msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:141 -msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:149 -msgid "setup() args" -msgstr "Аргументы ``setup()``" - -#: ../source/guides/distributing-packages-using-setuptools.rst:151 -msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:155 -msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:164 -msgid "name" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:170 -msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:174 -msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:176 -msgid "Start & end with an ASCII letter or digit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:178 -msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:190 -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "version" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:196 -msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:200 -msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:203 -msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:206 -msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:214 -msgid "description" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:222 -msgid "Give a short and long description for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:224 -msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:229 -msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:235 -msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:245 -msgid "url" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:252 -msgid "Give a homepage URL for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:256 -msgid "author" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:263 -msgid "Provide details about the author." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:267 -msgid "license" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:273 -msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:279 -msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:287 -msgid "classifiers" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:316 -msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:319 -msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:327 -msgid "keywords" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:333 -msgid "List keywords that describe your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:337 -msgid "project_urls" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:349 -msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:355 -msgid "packages" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:361 -msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:370 -msgid "py_modules" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:376 -msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:388 -msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:392 -msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:398 -msgid "python_requires" -msgstr "python_requires" - -#: ../source/guides/distributing-packages-using-setuptools.rst:400 -msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:407 -msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:412 -msgid "And so on." -msgstr "И так далее." - -#: ../source/guides/distributing-packages-using-setuptools.rst:416 -msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:422 -msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:431 -msgid "package_data" -msgstr "package_data" - -#: ../source/guides/distributing-packages-using-setuptools.rst:440 -msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:445 -msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:449 -msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:457 -msgid "data_files" -msgstr "data_files" - -#: ../source/guides/distributing-packages-using-setuptools.rst:463 -msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:469 -msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:479 -msgid "For more information see the distutils section on `Installing Additional Files `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:484 -msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:491 -msgid "scripts" -msgstr "scripts" - -#: ../source/guides/distributing-packages-using-setuptools.rst:493 -msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:500 -msgid "entry_points" -msgstr "entry_points" - -#: ../source/guides/distributing-packages-using-setuptools.rst:509 -msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:512 -msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:516 -msgid "The most commonly used entry point is \"console_scripts\" (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:521 -msgid "console_scripts" -msgstr "console_scripts" - -#: ../source/guides/distributing-packages-using-setuptools.rst:531 -msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:538 -msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:545 -msgid "Choosing a versioning scheme" -msgstr "Выбор схемы управления версиями" - -#: ../source/guides/distributing-packages-using-setuptools.rst:548 -msgid "Standards compliance for interoperability" -msgstr "Соответствие стандартам совместимости" - -#: ../source/guides/distributing-packages-using-setuptools.rst:550 -msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:556 -msgid "Here are some examples of compliant version numbers::" -msgstr "Вот несколько примеров совместимых номеров версий::" - -#: ../source/guides/distributing-packages-using-setuptools.rst:567 -msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:573 -msgid "Scheme choices" -msgstr "Выбор схемы" - -#: ../source/guides/distributing-packages-using-setuptools.rst:576 -msgid "Semantic versioning (preferred)" -msgstr "Семантическое версионирование (предпочитаемый вариант)" - -#: ../source/guides/distributing-packages-using-setuptools.rst:578 -msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:582 -msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:585 -msgid "MAJOR version when they make incompatible API changes," -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:586 -msgid "MINOR version when they add functionality in a backwards-compatible manner, and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:587 -msgid "MAINTENANCE version when they make backwards-compatible bug fixes." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:589 -msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:594 -msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:598 -msgid "Date based versioning" -msgstr "Версионирование на основе дат" - -#: ../source/guides/distributing-packages-using-setuptools.rst:600 -msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:604 -msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:607 -msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:611 -msgid "Serial versioning" -msgstr "Последовательное версионирование" - -#: ../source/guides/distributing-packages-using-setuptools.rst:613 -msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:616 -msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:621 -msgid "Hybrid schemes" -msgstr "Гибридные схемы" - -#: ../source/guides/distributing-packages-using-setuptools.rst:623 -msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:629 -msgid "Pre-release versioning" -msgstr "Версионирование предварительных выпусков" - -#: ../source/guides/distributing-packages-using-setuptools.rst:631 -msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:634 -msgid "zero or more dev releases (denoted with a \".devN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:635 -msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:636 -msgid "zero or more beta releases (denoted with a \".bN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:637 -msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:639 -msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:644 -msgid "Local version identifiers" -msgstr "Идентификаторы локальных версий" - -#: ../source/guides/distributing-packages-using-setuptools.rst:646 -msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:653 -msgid "A local version identifier takes the form ``+``. For example::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:661 -msgid "Working in \"development mode\"" -msgstr "Работа в «режиме разработки»" - -#: ../source/guides/distributing-packages-using-setuptools.rst:663 -msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:667 -msgid "Assuming you're in the root of your project directory, then run:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:674 -msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:680 -msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:688 -msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:692 -msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:697 -msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:701 -msgid "Lastly, if you don't want to install any dependencies at all, you can run::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:706 -msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:713 -msgid "Packaging your project" -msgstr "Упаковка вашего проекта" - -#: ../source/guides/distributing-packages-using-setuptools.rst:715 -msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:720 -msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:737 -msgid "Source distributions" -msgstr "Распространение в исходных кодах" - -#: ../source/guides/distributing-packages-using-setuptools.rst:739 -msgid "Minimally, you should create a :term:`Source Distribution `:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:755 -msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:763 -msgid "Wheels" -msgstr "Колёса" - -#: ../source/guides/distributing-packages-using-setuptools.rst:765 -msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:770 -msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:773 -msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:776 -msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:785 -msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:792 -msgid "Pure Python Wheels" -msgstr "Колёса чистого Python'а" - -#: ../source/guides/distributing-packages-using-setuptools.rst:794 -msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:797 -#: ../source/guides/distributing-packages-using-setuptools.rst:826 -msgid "To build the wheel:" -msgstr "Для построения колеса выполните:" - -#: ../source/guides/distributing-packages-using-setuptools.rst:811 -msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:815 -msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:821 -msgid "Platform Wheels" -msgstr "Платформо-зависимые колёса" - -#: ../source/guides/distributing-packages-using-setuptools.rst:823 -msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:841 -msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:847 -msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:855 -msgid "Uploading your Project to PyPI" -msgstr "Загрузка вашего проекта на PyPI" - -#: ../source/guides/distributing-packages-using-setuptools.rst:857 -msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:861 -msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:866 -msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:871 -msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:877 -msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:888 -msgid "Create an account" -msgstr "Создание учётной записи" - -#: ../source/guides/distributing-packages-using-setuptools.rst:890 -msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:894 -msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:897 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:901 -msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:904 -msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:913 -msgid "**Be aware that this stores your token in plaintext.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:915 -#: ../source/guides/migrating-to-pypi-org.rst:70 -#: ../source/guides/migrating-to-pypi-org.rst:109 -#: ../source/guides/using-testpypi.rst:83 -msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:921 -msgid "Upload your distributions" -msgstr "Загрузите свои дистрибутивы" - -#: ../source/guides/distributing-packages-using-setuptools.rst:923 -msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:926 -msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:930 -msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:937 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:944 -#: ../source/tutorials/installing-packages.rst:663 -msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:950 -msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:5 -msgid "Dropping support for older Python versions" -msgstr "Удаление поддержки старых версий Python'а" - -#: ../source/guides/dropping-older-python-versions.rst:7 -msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:9 -msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:12 -msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:14 -msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:17 -msgid "Requirements" -msgstr "Требования" - -#: ../source/guides/dropping-older-python-versions.rst:19 -msgid "This workflow requires that:" -msgstr "Этот рабочий процесс требует, чтобы:" - -#: ../source/guides/dropping-older-python-versions.rst:21 -msgid "The publisher is using the latest version of :ref:`setuptools`," -msgstr "Издатель использовал последнюю версию :ref:`setuptools`," - -#: ../source/guides/dropping-older-python-versions.rst:22 -msgid "The latest version of :ref:`twine` is used to upload the package," -msgstr "Для загрузки пакета использовалась последняя версия :ref:`twine`," - -#: ../source/guides/dropping-older-python-versions.rst:23 -msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." -msgstr "" -"У пользователя, устанавливающего пакет, был установлен хотя бы Pip 9.0 или " -"клиент, поддерживающий спецификацию Metadata 1.2." - -#: ../source/guides/dropping-older-python-versions.rst:26 -msgid "Dealing with the universal wheels" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:28 -msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:36 -msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:48 -msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:53 -msgid "Defining the Python version required" -msgstr "Определение требуемой версии Python'а" - -#: ../source/guides/dropping-older-python-versions.rst:56 -msgid "1. Download the newest version of Setuptools" -msgstr "1. Скачайте новейшую версию Setuptools" - -#: ../source/guides/dropping-older-python-versions.rst:58 -msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." -msgstr "" -"Убедитесь, что перед созданием дистрибутивов исходных кодов или двоичных " -"дистрибутивов вы обновили Setuptools и установили twine." - -#: ../source/guides/dropping-older-python-versions.rst:60 -msgid "Steps:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:74 -msgid "`setuptools` version should be above 24.0.0." -msgstr "Версия `setuptools` должна быть выше 24.0.0." - -#: ../source/guides/dropping-older-python-versions.rst:77 -msgid "2. Specify the version ranges for supported Python distributions" -msgstr "2. Укажите диапазоны версий поддерживаемых дистрибутивов Python'а" - -#: ../source/guides/dropping-older-python-versions.rst:79 -msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:81 -#: ../source/specifications/core-metadata.rst:139 -#: ../source/specifications/core-metadata.rst:463 -#: ../source/specifications/core-metadata.rst:487 -#: ../source/specifications/core-metadata.rst:527 -#: ../source/specifications/core-metadata.rst:550 -#: ../source/specifications/core-metadata.rst:583 -#: ../source/specifications/core-metadata.rst:693 -#: ../source/specifications/core-metadata.rst:722 -msgid "Examples::" -msgstr "Примеры::" - -#: ../source/guides/dropping-older-python-versions.rst:86 -msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:101 -msgid "3. Validating the Metadata before publishing" -msgstr "3. Перед публикацией проверьте метаданные" - -#: ../source/guides/dropping-older-python-versions.rst:103 -msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:105 -msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:108 -msgid "You can see the contents of the generated file like this::" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:112 -msgid "Validate that the following is in place, before publishing the package:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:114 -msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:115 -msgid "The Requires-Python field is set and matches your specification in setup.py." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:118 -msgid "4. Using Twine to publish" -msgstr "4. Используйте Twine для публикации" - -#: ../source/guides/dropping-older-python-versions.rst:120 -msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:122 -msgid "Make sure you are using the newest version of Twine, at least 1.9." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:125 -msgid "Dropping a Python release" -msgstr "Удаление выпуска Python'а" - -#: ../source/guides/dropping-older-python-versions.rst:127 -msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:129 -msgid "It must be done in this order for the automated fallback to work." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:131 -msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:133 -msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:5 -msgid "Hosting your own simple repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:8 -msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:13 -msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:29 -msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:35 -msgid "\"Manual\" repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:37 -msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:51 -msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:58 -msgid "For complete documentation of the simple repository protocol, see :pep:`503`." -msgstr "" - -#: ../source/guides/index.rst:8 -#: ../source/guides/index.rst:8 -msgid "Installing Packages:" -msgstr "" - -#: ../source/guides/index.rst:20 -#: ../source/guides/index.rst:20 -msgid "Building and Publishing Projects:" -msgstr "" - -#: ../source/guides/index.rst:38 -#: ../source/guides/index.rst:38 -msgid "Miscellaneous:" -msgstr "" - -#: ../source/guides/index.rst:4 -msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:5 -msgid "Package index mirrors and caches" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:8 -#: ../source/guides/supporting-multiple-python-versions.rst:8 -msgid "2014-12-24" -msgstr "2014-12-24" - -#: ../source/guides/index-mirrors-and-caches.rst:14 -msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:17 -msgid "Three options are available in this area:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:19 -msgid "pip provides local caching options," -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:20 -msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:22 -msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:27 -msgid "Caching with pip" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:29 -msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:32 -msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:36 -msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:45 -msgid "Caching with devpi" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:47 -msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:55 -msgid "Complete mirror with bandersnatch" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:57 -msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:63 -msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:5 -msgid "Installing scientific packages" -msgstr "Установка научных пакетов" - -#: ../source/guides/installing-scientific-packages.rst:11 -msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:16 -msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:22 -msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:29 -msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:35 -msgid "Building from source" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:37 -msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:45 -msgid "Linux distribution packages" -msgstr "Распространяемые пакеты Linux" - -#: ../source/guides/installing-scientific-packages.rst:47 -msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:51 -msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:57 -msgid "Windows installers" -msgstr "Установщики Windows" - -#: ../source/guides/installing-scientific-packages.rst:59 -msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:64 -msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:67 -msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:73 -msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:79 -msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:86 -msgid "macOS installers and package managers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:88 -msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:92 -msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:99 -msgid "SciPy distributions" -msgstr "Дистрибутивы SciPy" - -#: ../source/guides/installing-scientific-packages.rst:101 -msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:105 -msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:109 -#: ../source/key_projects.rst:596 -msgid "Spack" -msgstr "Spack" - -#: ../source/guides/installing-scientific-packages.rst:110 -msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:119 -msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:128 -msgid "The conda cross-platform package manager" -msgstr "Кроссплатформенный менеджер пакетов conda" - -#: ../source/guides/installing-scientific-packages.rst:130 -msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:136 -msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 -msgid "Installing stand alone command line tools" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 -msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 -msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 -msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 -msgid "pipx only works with Python 3.6+." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 -msgid "``pipx`` is installed with ``pip``:" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 -msgid "You may need to restart your terminal for the path updates to take effect." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 -msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 -#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 -msgid "For example" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 -msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 -msgid "To upgrade or uninstall the package" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 -msgid "``pipx`` can be upgraded or uninstalled with pip" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 -msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 -msgid "To see the full list of commands ``pipx`` offers, run" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 -msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:5 -msgid "Installing pip/setuptools/wheel with Linux Package Managers" -msgstr "Установка pip/setuptools/wheel через менеджеры пакетов Linux" - -#: ../source/guides/installing-using-linux-tools.rst:8 -msgid "2015-09-17" -msgstr "2015-09-17" - -#: ../source/guides/installing-using-linux-tools.rst:11 -msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:14 -msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:18 -msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:25 -msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:32 -msgid "Fedora" -msgstr "Fedora" - -#: ../source/guides/installing-using-linux-tools.rst:34 -msgid "Fedora 21:" -msgstr "Fedora 21:" - -#: ../source/guides/installing-using-linux-tools.rst:36 -#: ../source/guides/installing-using-linux-tools.rst:45 -#: ../source/guides/installing-using-linux-tools.rst:124 -#: ../source/guides/installing-using-linux-tools.rst:138 -#: ../source/guides/installing-using-linux-tools.rst:158 -msgid "Python 2::" -msgstr "Python 2::" - -#: ../source/guides/installing-using-linux-tools.rst:41 -msgid "Python 3: ``sudo yum install python3 python3-wheel``" -msgstr "Python 3: ``sudo yum install python3 python3-wheel``" - -#: ../source/guides/installing-using-linux-tools.rst:43 -msgid "Fedora 22:" -msgstr "Fedora 22:" - -#: ../source/guides/installing-using-linux-tools.rst:50 -msgid "Python 3: ``sudo dnf install python3 python3-wheel``" -msgstr "Python 3: ``sudo dnf install python3 python3-wheel``" - -#: ../source/guides/installing-using-linux-tools.rst:53 -msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:63 -msgid "CentOS/RHEL" -msgstr "CentOS/RHEL" - -#: ../source/guides/installing-using-linux-tools.rst:65 -msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:68 -msgid "To install pip and wheel for the system Python, there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:70 -msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:77 -msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:81 -msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:85 -msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:92 -msgid "To additionally upgrade setuptools, run::" -msgstr "Чтобы дополнительно обновить setuptools, запустите::" - -#: ../source/guides/installing-using-linux-tools.rst:97 -msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:101 -msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:104 -msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:106 -msgid "For CentOS, see here: https://www.softwarecollections.org/en/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:108 -msgid "Be aware that collections may not contain the most recent versions." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:110 -msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:116 -msgid "For example, for Python 3.4 on CentOS7/RHEL7::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:122 -msgid "openSUSE" -msgstr "openSUSE" - -#: ../source/guides/installing-using-linux-tools.rst:129 -#: ../source/guides/installing-using-linux-tools.rst:143 -#: ../source/guides/installing-using-linux-tools.rst:162 -msgid "Python 3::" -msgstr "Python 3::" - -#: ../source/guides/installing-using-linux-tools.rst:135 -msgid "Debian/Ubuntu" -msgstr "Debian/Ubuntu" - -#: ../source/guides/installing-using-linux-tools.rst:150 -msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:156 -msgid "Arch Linux" -msgstr "Arch Linux" - -#: ../source/guides/installing-using-linux-tools.rst:168 -msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 -msgid "Installing packages using pip and virtual environments" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 -msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 -msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 -msgid "Installing pip" -msgstr "Установка pip" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 -msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 -msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 -msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 -msgid "Afterwards, you should have the newest pip installed in your user site:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 -msgid "The Python installers for Windows include pip. You should be able to access pip using:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 -msgid "You can make sure that pip is up-to-date by running:" -msgstr "" -"Вы можете убедиться, что pip обновлён до самой последней версии, запустив " -"следующую команду:" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 -msgid "Installing virtualenv" -msgstr "Установка virtualenv" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 -msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 -msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 -msgid "Creating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 -msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 -msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 -msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 -msgid "venv will create a virtual Python installation in the ``env`` folder." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 -msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 -msgid "Activating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 -msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 -msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 -msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 -msgid "Leaving the virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 -msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 -msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 -msgid "Installing packages" -msgstr "Установка пакетов" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 -msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 -msgid "pip should download requests and all of its dependencies and install them:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 -msgid "Installing specific versions" -msgstr "Установка определённых версий" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 -msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 -msgid "To install the latest ``2.x`` release of requests:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 -msgid "To install pre-release versions of packages, use the ``--pre`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 -msgid "Installing extras" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 -msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 -msgid "Installing from source" -msgstr "Установка из исходных кодов" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 -msgid "pip can install a package directly from source, for example:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 -msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 -msgid "Installing from version control systems" -msgstr "Установка из систем управления версиями" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 -msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 -msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 -#: ../source/tutorials/installing-packages.rst:569 -msgid "Installing from local archives" -msgstr "Установка из локальных архивов" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 -msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 -msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 -msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 -msgid "Using other package indexes" -msgstr "Использование других индексов пакетов" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 -msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 -msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 -#: ../source/tutorials/installing-packages.rst:389 -msgid "Upgrading packages" -msgstr "Обновление пакетов" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 -msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 -msgid "Using requirements files" -msgstr "Использование файлов требований" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 -msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 -msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 -msgid "Freezing dependencies" -msgstr "Заморозка зависимостей" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 -msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 -msgid "Which will output a list of package specifiers such as:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 -msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:2 -msgid "Making a PyPI-friendly README" -msgstr "Создание дружественного к PyPI файла README" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:4 -msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:9 -msgid "Creating a README file" -msgstr "Создание файла :file:`README`" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:11 -msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:13 -msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:16 -msgid "plain text" -msgstr "простой текст;" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:17 -msgid "`reStructuredText `_ (without Sphinx extensions)" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:18 -msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" -msgstr "" -"текст в формате Markdown (`GitHub Flavored Markdown `_ по умолчанию или `CommonMark `_)." - -#: ../source/guides/making-a-pypi-friendly-readme.rst:21 -msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:25 -msgid "Including your README in your package's metadata" -msgstr "Включение файла README в метаданные вашего пакета" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:27 -msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:33 -msgid ":ref:`description-optional`" -msgstr ":ref:`description-optional`" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:34 -msgid ":ref:`description-content-type-optional`" -msgstr ":ref:`description-content-type-optional`" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:36 -msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:39 -msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:45 -msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:60 -msgid "The minimum required versions of the respective tools are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:62 -msgid "``setuptools >= 38.6.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:63 -msgid "``wheel >= 0.31.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:64 -msgid "``twine >= 1.11.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:66 -msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:72 -msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:95 -msgid "Validating reStructuredText markup" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:97 -msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:100 -msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:105 -msgid "You can check your README for markup errors before uploading as follows:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:107 -msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:122 -msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:125 -msgid "Run ``twine check`` on the sdist and wheel::" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:129 -msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:4 -msgid "Migrating to PyPI.org" -msgstr "Переход на PyPI.org" - -#: ../source/guides/migrating-to-pypi-org.rst:6 -msgid ":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``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:12 -msgid "Publishing releases" -msgstr "Публикация выпусков" - -#: ../source/guides/migrating-to-pypi-org.rst:14 -msgid "``pypi.org`` is the default upload platform as of September 2016." -msgstr "" -"С сентября 2016 года платформой загрузки по умолчанию является ``pypi.org``." - -#: ../source/guides/migrating-to-pypi-org.rst:16 -msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:19 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:22 -msgid "The default upload settings switched to ``pypi.org`` in the following versions:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:24 -msgid "``twine`` 1.8.0" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:25 -msgid "``setuptools`` 27.0.0" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:26 -msgid "Python 2.7.13 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:27 -msgid "Python 3.4.6 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:28 -msgid "Python 3.5.3 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:29 -msgid "Python 3.6.0 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:31 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:48 -msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:51 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:67 -msgid "(``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.)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:73 -msgid "Registering package names & metadata" -msgstr "Регистрация имён и метаданных пакетов" - -#: ../source/guides/migrating-to-pypi-org.rst:75 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:79 -msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:84 -msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:89 -#: ../source/guides/using-testpypi.rst:5 -msgid "Using TestPyPI" -msgstr "Использование TestPyPI" - -#: ../source/guides/migrating-to-pypi-org.rst:91 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:113 -msgid "Registering new user accounts" -msgstr "Регистрация новых учётных записей пользователей" - -#: ../source/guides/migrating-to-pypi-org.rst:115 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:121 -msgid "Browsing packages" -msgstr "Просмотр пакетов" - -#: ../source/guides/migrating-to-pypi-org.rst:123 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:130 -msgid "Downloading packages" -msgstr "Загрузка пакетов" - -#: ../source/guides/migrating-to-pypi-org.rst:132 -msgid "``pypi.org`` is the default host for downloading packages." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:135 -msgid "Managing published packages and releases" -msgstr "Управление опубликованными пакетами и выпусками" - -#: ../source/guides/migrating-to-pypi-org.rst:137 -msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:5 -msgid "Multi-version installs" -msgstr "Установка нескольких версий" - -#: ../source/guides/multi-version-installs.rst:8 -msgid "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``)." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:13 -msgid "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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:19 -msgid "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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:31 -msgid "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 ``python -c ''`` to invoke the application's main entry point directly." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:38 -msgid "Refer to the `pkg_resources documentation `__ for more details." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:5 -msgid "Packaging binary extensions" -msgstr "Упаковка двоичных расширений" - -#: ../source/guides/packaging-binary-extensions.rst:8 -msgid "2013-12-08" -msgstr "2013-12-08" - -#: ../source/guides/packaging-binary-extensions.rst:10 -msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:20 -msgid "An overview of binary extensions" -msgstr "Обзор двоичных расширений" - -#: ../source/guides/packaging-binary-extensions.rst:23 -msgid "Use cases" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:25 -msgid "The typical use cases for binary extensions break down into just three conventional categories:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:28 -msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:39 -msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:47 -msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:56 -msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:61 -msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:71 -msgid "Disadvantages" -msgstr "Недостатки" - -#: ../source/guides/packaging-binary-extensions.rst:73 -msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:80 -msgid "This means that binary extensions:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:82 -msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:85 -msgid "may not be compatible with different builds of the CPython reference interpreter" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:88 -msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:91 -msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:96 -msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:101 -msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:108 -msgid "Alternatives to handcoded accelerator modules" -msgstr "Альтернативы ручному написанию ускоряющих модулей" - -#: ../source/guides/packaging-binary-extensions.rst:110 -msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:115 -msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:122 -msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:132 -msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:141 -msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:150 -msgid "Alternatives to handcoded wrapper modules" -msgstr "Альтернативы ручному написанию модулей-обёрток" - -#: ../source/guides/packaging-binary-extensions.rst:152 -msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:158 -msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:162 -msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:168 -msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:175 -msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:181 -msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:185 -msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:189 -msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:203 -msgid "Alternatives for low level system access" -msgstr "Альтернативы для низкоуровневого доступа к системе" - -#: ../source/guides/packaging-binary-extensions.rst:205 -msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:213 -msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:222 -msgid "Implementing binary extensions" -msgstr "Реализация двоичных расширений" - -#: ../source/guides/packaging-binary-extensions.rst:224 -msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:241 -msgid "Building binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:244 -msgid "Building extensions for multiple platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:246 -msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:256 -msgid "Binary extensions for Windows" -msgstr "Двоичные расширения для Windows" - -#: ../source/guides/packaging-binary-extensions.rst:258 -msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:263 -msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:269 -msgid "To set up a build environment for binary extensions, the steps are as follows:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:271 -msgid "For Python 2.7" -msgstr "Для Python 2.7" - -#: ../source/guides/packaging-binary-extensions.rst:273 -msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:276 -msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:278 -#: ../source/guides/packaging-binary-extensions.rst:288 -#: ../source/guides/packaging-binary-extensions.rst:295 -msgid "Done." -msgstr "Готово." - -#: ../source/guides/packaging-binary-extensions.rst:280 -msgid "For Python 3.4" -msgstr "Для Python 3.4" - -#: ../source/guides/packaging-binary-extensions.rst:282 -msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:285 -msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:287 -msgid "Set DISTUTILS_USE_SDK=1" -msgstr "Установите DISTUTILS_USE_SDK=1" - -#: ../source/guides/packaging-binary-extensions.rst:290 -msgid "For Python 3.5" -msgstr "Для Python 3.5" - -#: ../source/guides/packaging-binary-extensions.rst:292 -msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:297 -msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:301 -msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:305 -msgid "Binary extensions for Linux" -msgstr "Двоичные расширения для Linux" - -#: ../source/guides/packaging-binary-extensions.rst:307 -msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:313 -msgid "Binary extensions for macOS" -msgstr "Двоичные расширения для macOS" - -#: ../source/guides/packaging-binary-extensions.rst:315 -msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:325 -msgid "Publishing binary extensions" -msgstr "Публикация двоичных расширений" - -#: ../source/guides/packaging-binary-extensions.rst:327 -msgid "For interim guidance on this topic, see the discussion in `this issue `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:343 -msgid "Additional resources" -msgstr "Дополнительные ресурсы" - -#: ../source/guides/packaging-binary-extensions.rst:345 -msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:352 -msgid "Cross-platform wheel generation with scikit-build" -msgstr "Кросс-платформенная генерация колёс при помощи scikit-build" - -#: ../source/guides/packaging-binary-extensions.rst:354 -msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:362 -msgid "Introduction to C/C++ extension modules" -msgstr "Введение в модули расширения на C/C++" - -#: ../source/guides/packaging-binary-extensions.rst:364 -msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:367 -msgid "`What are (c)python extension modules? `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:368 -msgid "`Releasing the gil `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:369 -msgid "`Writing cpython extension modules using C++ `_" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:3 -msgid "Packaging namespace packages" -msgstr "Упаковка пакетов пространства имён" - -#: ../source/guides/packaging-namespace-packages.rst:5 -msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:24 -msgid "And you use this package in your code like so::" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:29 -msgid "Then you can break these sub-packages into two separate distributions:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:46 -msgid "Each sub-package can now be separately installed, used, and versioned." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:48 -msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:58 -msgid "Creating a namespace package" -msgstr "Создание пакета пространства имён" - -#: ../source/guides/packaging-namespace-packages.rst:60 -msgid "There are currently three different approaches to creating namespace packages:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:62 -msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:66 -msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:69 -msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:73 -msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:80 -msgid "Native namespace packages" -msgstr "Родные пакеты пространства имён" - -#: ../source/guides/packaging-namespace-packages.rst:82 -msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:97 -msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:102 -msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:117 -msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:123 -msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:129 -msgid "pkgutil-style namespace packages" -msgstr "Пакеты пространства имён в стиле pkgutil" - -#: ../source/guides/packaging-namespace-packages.rst:131 -msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:136 -msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:148 -#: ../source/guides/packaging-namespace-packages.rst:194 -msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:155 -#: ../source/guides/packaging-namespace-packages.rst:201 -msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:160 -msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:171 -msgid "pkg_resources-style namespace packages" -msgstr "Пакеты пространства имён в стиле pkg_resources" - -#: ../source/guides/packaging-namespace-packages.rst:173 -msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:182 -msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:206 -msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:216 -msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:223 -msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:237 -msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 -msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 -msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 -msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 -msgid "Saving credentials on GitHub" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 -msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 -msgid "Let's begin! 🚀" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 -msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 -msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 -msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 -msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 -msgid "Creating a workflow definition" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 -msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 -msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 -msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 -msgid "Defining a workflow job environment" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 -msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 -msgid "Checking out the project and building distributions" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 -msgid "Then, add the following under the ``build-n-publish`` section:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 -msgid "This will download your repository into the CI runner and then install and activate Python 3.7." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 -msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 -msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 -msgid "So add this to the steps list:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 -msgid "Publishing the distribution to PyPI and TestPyPI" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 -msgid "Finally, add the following steps at the end:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 -msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 -msgid "That's all, folks!" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 -msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:5 -msgid "Single-sourcing the package version" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:8 -msgid "There are many techniques to maintain a single source of truth for the version number of your project:" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:11 -msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:38 -msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:47 -msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:52 -msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:55 -msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:58 -msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:65 -msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:76 -msgid "Example using this technique: `warehouse `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:78 -msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:86 -msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:91 -msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:95 -msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:110 -msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:114 -msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:128 -msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:134 -msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:138 -msgid "Example using this technique: `setuptools `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:141 -msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:155 -msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:161 -msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:5 -msgid "Supporting multiple Python versions" -msgstr "Поддержка нескольких версий Python'а" - -#: ../source/guides/supporting-multiple-python-versions.rst:37 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:43 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:49 -msgid "Automated testing and continuous integration" -msgstr "Автоматическое тестирование и непрерывная интеграция" - -#: ../source/guides/supporting-multiple-python-versions.rst:51 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:56 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:60 -msgid "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:" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:66 -msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:69 -msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:80 -msgid "Both `Travis CI`_ 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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:85 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:89 -msgid "Tools for single-source Python packages" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:91 -msgid "`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_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:100 -msgid "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" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:107 -msgid "a Python 2 (by syntax) module in a Python 3 project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:108 -msgid "a Python 3 (by syntax) module in a *Python 2* project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:110 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:117 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:124 -msgid "What's in which Python?" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:126 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:3 -msgid "Supporting Windows using Appveyor" -msgstr "Поддержка Windows с помощью Appveyor" - -#: ../source/guides/supporting-windows-using-appveyor.rst:6 -msgid "2015-12-03" -msgstr "2015-12-03" - -#: ../source/guides/supporting-windows-using-appveyor.rst:8 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:20 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:24 -msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:30 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:38 -msgid "Setting up" -msgstr "Настройка" - -#: ../source/guides/supporting-windows-using-appveyor.rst:40 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:45 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:49 -msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:54 -msgid "Adding Appveyor support to your project" -msgstr "Добавление поддержки Appveyor в ваш проект" - -#: ../source/guides/supporting-windows-using-appveyor.rst:56 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:61 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:69 -msgid "appveyor.yml" -msgstr ":file:`appveyor.yml`" - -#: ../source/guides/supporting-windows-using-appveyor.rst:75 -msgid "This file can be downloaded from `here `__." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:77 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:80 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:88 -msgid "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``)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:94 -msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:97 -msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:100 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:109 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:114 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:119 -msgid "Support script" -msgstr "Скрипт поддержки" - -#: ../source/guides/supporting-windows-using-appveyor.rst:121 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:126 -msgid "`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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:133 -msgid "You can simply download the batch file and include it in your project unchanged." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:137 -msgid "Access to the built wheels" -msgstr "Доступ к собранным колёсам" - -#: ../source/guides/supporting-windows-using-appveyor.rst:139 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:147 -msgid "Additional notes" -msgstr "Дополнительные замечания" - -#: ../source/guides/supporting-windows-using-appveyor.rst:150 -msgid "Testing with tox" -msgstr "Тестирование с помощью tox" - -#: ../source/guides/supporting-windows-using-appveyor.rst:152 -msgid "Many projects use the `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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:156 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:160 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:165 -msgid "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" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:170 -msgid "``DISTUTILS_USE_SDK``" -msgstr "``DISTUTILS_USE_SDK``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:171 -msgid "``MSSdk``" -msgstr "``MSSdk``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:172 -msgid "``INCLUDE``" -msgstr "``INCLUDE``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:173 -msgid "``LIB``" -msgstr "``LIB``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:175 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:181 -msgid "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 Travis or 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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:188 -msgid "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``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:192 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:197 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:203 -msgid "Automatically uploading wheels" -msgstr "Автоматическая загрузка колёс" - -#: ../source/guides/supporting-windows-using-appveyor.rst:205 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:210 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:216 -msgid "External dependencies" -msgstr "Внешние зависимости" - -#: ../source/guides/supporting-windows-using-appveyor.rst:218 -msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:221 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:230 -msgid "Support scripts" -msgstr "Скрипты поддержки" - -#: ../source/guides/supporting-windows-using-appveyor.rst:232 -msgid "For reference, the SDK setup support script is listed here:" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:234 -msgid "``appveyor-sample/build.cmd``" -msgstr "``appveyor-sample/build.cmd``" - -#: ../source/guides/tool-recommendations.rst:5 -msgid "Tool recommendations" -msgstr "Рекомендации по инструментам" - -#: ../source/guides/tool-recommendations.rst:7 -msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:12 -msgid "Application dependency management" -msgstr "Управление зависимостями приложения" - -#: ../source/guides/tool-recommendations.rst:14 -msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:18 -msgid "When ``pipenv`` does not meet your use case, consider other tools like:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:20 -msgid ":ref:`pip`" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:22 -msgid "`pip-tools `_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:24 -msgid "`Poetry `_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:27 -msgid "Installation tool recommendations" -msgstr "Рекомендации по инструментам установки" - -#: ../source/guides/tool-recommendations.rst:29 -msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:34 -msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:37 -msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:40 -msgid ":ref:`buildout`: primarily focused on the web development community" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:42 -msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:47 -msgid "Packaging tool recommendations" -msgstr "Рекомендации по инструментам упаковки" - -#: ../source/guides/tool-recommendations.rst:49 -msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:52 -msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:56 -msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:61 -msgid "Publishing platform migration" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:63 -msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:67 -msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:72 -msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:77 -msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:82 -msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:88 -msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:93 -msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:102 -msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:107 -msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:5 -msgid "Including files in source distributions with ``MANIFEST.in``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:7 -msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:17 -msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:22 -msgid "How files are included in an sdist" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:24 -msgid "The following files are included in a source distribution by default:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:26 -msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:28 -msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:30 -msgid "scripts specified by the ``scripts`` ``setup()`` argument" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:31 -msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:33 -msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:35 -msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:37 -msgid "all files matching the pattern :file:`test/test*.py`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:38 -msgid ":file:`setup.py` (or whatever you called your setup script)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:39 -msgid ":file:`setup.cfg`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:40 -msgid ":file:`README`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:41 -msgid ":file:`README.txt`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:42 -msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:43 -msgid ":file:`README.md` (setuptools 36.4.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:44 -msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:45 -msgid ":file:`MANIFEST.in`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:47 -msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:52 -msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:60 -msgid ":file:`MANIFEST.in` commands" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:62 -msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:67 -msgid "Command" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:69 -msgid ":samp:`include {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:69 -msgid "Add all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid ":samp:`exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid "Remove all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid ":samp:`global-include {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid "Add all files anywhere in the source tree matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid ":samp:`global-exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid "Remove all files anywhere in the source tree matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid ":samp:`graft {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid "Add all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid ":samp:`prune {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid "Remove all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:79 -msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:87 -msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:91 -msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:95 -msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:101 -msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." -msgstr "" - -#: ../source/guides/using-testpypi.rst:7 -msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" -msgstr "" - -#: ../source/guides/using-testpypi.rst:13 -msgid "Registering your account" -msgstr "Регистрация учётной записи" - -#: ../source/guides/using-testpypi.rst:15 -msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." -msgstr "" - -#: ../source/guides/using-testpypi.rst:19 -msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." -msgstr "" - -#: ../source/guides/using-testpypi.rst:24 -msgid "Using TestPyPI with Twine" -msgstr "Использование TestPyPI вместе с Twine" - -#: ../source/guides/using-testpypi.rst:26 -msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:33 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." -msgstr "" - -#: ../source/guides/using-testpypi.rst:39 -msgid "Using TestPyPI with pip" -msgstr "Использование TestPyPI вместе с pip" - -#: ../source/guides/using-testpypi.rst:41 -msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:56 -msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" -msgstr "" - -#: ../source/guides/using-testpypi.rst:73 -msgid "Setting up TestPyPI in :file:`.pypirc`" -msgstr "" - -#: ../source/guides/using-testpypi.rst:75 -msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" -msgstr "" - -#: ../source/index.rst:3 -#: ../source/key_projects.rst:181 -msgid "Python Packaging User Guide" -msgstr "Руководство пользователя по созданию Python’ьих пакетов" - -#: ../source/index.rst:5 -msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." -msgstr "" - -#: ../source/index.rst:5 -msgid "python, packaging, guide, tutorial" -msgstr "" - -#: ../source/index.rst:24 -msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." -msgstr "" - -#: ../source/index.rst:28 -msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" -msgstr "" - -#: ../source/index.rst:36 -msgid "Get started" -msgstr "Начало работы" - -#: ../source/index.rst:38 -msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" -msgstr "" -"Основные инструменты и концепции для работы в экосистеме разработки Python " -"описаны в нашем разделе :doc:`tutorials/index`:" - -#: ../source/index.rst:41 -msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" -msgstr "" - -#: ../source/index.rst:43 -msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" -msgstr "" - -#: ../source/index.rst:45 -msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" -msgstr "" - -#: ../source/index.rst:47 -msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" -msgstr "" - -#: ../source/index.rst:52 -msgid "Learn more" -msgstr "Подробнее" - -#: ../source/index.rst:54 -msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" -msgstr "" -"Помимо наших :doc:`учебников ` это руководство содержит " -"несколько других ресурсов:" - -#: ../source/index.rst:56 -msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." -msgstr "" - -#: ../source/index.rst:58 -msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." -msgstr "" - -#: ../source/index.rst:60 -msgid "The :doc:`specifications/index` section for packaging interoperability specifications." -msgstr "" - -#: ../source/index.rst:62 -msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." -msgstr "" - -#: ../source/key_projects.rst:6 -msgid "Project Summaries" -msgstr "Обзор проектов" - -#: ../source/key_projects.rst:8 -msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." -msgstr "" - -#: ../source/key_projects.rst:14 -msgid "PyPA Projects" -msgstr "Проекты PyPA" - -#: ../source/key_projects.rst:19 -msgid "bandersnatch" -msgstr "bandersnatch" - -#: ../source/key_projects.rst:21 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:25 -msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." -msgstr "" - -#: ../source/key_projects.rst:35 -msgid "build" -msgstr "" - -#: ../source/key_projects.rst:37 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:42 -msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." -msgstr "" - -#: ../source/key_projects.rst:49 -msgid "cibuildwheel" -msgstr "" - -#: ../source/key_projects.rst:51 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" -msgstr "" - -#: ../source/key_projects.rst:58 -msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." -msgstr "" - -#: ../source/key_projects.rst:64 -msgid "distlib" -msgstr "distlib" - -#: ../source/key_projects.rst:66 -msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:71 -msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." -msgstr "" - -#: ../source/key_projects.rst:80 -msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." -msgstr "" - -#: ../source/key_projects.rst:90 -msgid "packaging" -msgstr "packaging" - -#: ../source/key_projects.rst:92 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:97 -msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." -msgstr "" - -#: ../source/key_projects.rst:99 -msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." -msgstr "" - -#: ../source/key_projects.rst:107 -msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." -msgstr "" - -#: ../source/key_projects.rst:119 -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "pip" -msgstr "pip" - -#: ../source/key_projects.rst:121 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:126 -msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." -msgstr "" - -#: ../source/key_projects.rst:129 -msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." -msgstr "" - -#: ../source/key_projects.rst:137 -msgid "Pipenv" -msgstr "Pipenv" - -#: ../source/key_projects.rst:139 -msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:144 -msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." -msgstr "" - -#: ../source/key_projects.rst:148 -msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." -msgstr "" - -#: ../source/key_projects.rst:159 -msgid "Pipfile" -msgstr "Pipfile" - -#: ../source/key_projects.rst:161 -msgid "`Source `__" -msgstr "`Исходный код `__" - -#: ../source/key_projects.rst:163 -msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." -msgstr "" - -#: ../source/key_projects.rst:170 -msgid "pipx" -msgstr "" - -#: ../source/key_projects.rst:172 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:176 -msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." -msgstr "" - -#: ../source/key_projects.rst:183 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:187 -msgid "This guide!" -msgstr "Это руководство!" - -#: ../source/key_projects.rst:192 -msgid "readme_renderer" -msgstr "" - -#: ../source/key_projects.rst:194 -msgid "`GitHub and docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:197 -msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." -msgstr "" - -#: ../source/key_projects.rst:208 -msgid "setuptools" -msgstr "setuptools" - -#: ../source/key_projects.rst:210 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:215 -msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." -msgstr "" - -#: ../source/key_projects.rst:220 -msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." -msgstr "" - -#: ../source/key_projects.rst:227 -msgid "trove-classifiers" -msgstr "" - -#: ../source/key_projects.rst:229 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:233 -msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." -msgstr "" - -#: ../source/key_projects.rst:239 -msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." -msgstr "" - -#: ../source/key_projects.rst:253 -msgid "twine" -msgstr "twine" - -#: ../source/key_projects.rst:255 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:260 -msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." -msgstr "" - -#: ../source/key_projects.rst:270 -#: ../source/overview.rst:415 -msgid "virtualenv" -msgstr "virtualenv" - -#: ../source/key_projects.rst:272 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:277 -msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/key_projects.rst:290 -msgid "Warehouse" -msgstr "Warehouse" - -#: ../source/key_projects.rst:292 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:296 -msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." -msgstr "" - -#: ../source/key_projects.rst:304 -msgid "wheel" -msgstr "wheel" - -#: ../source/key_projects.rst:306 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:311 -msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." -msgstr "" - -#: ../source/key_projects.rst:315 -msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." -msgstr "" - -#: ../source/key_projects.rst:324 -msgid "Non-PyPA Projects" -msgstr "Проекты, не связанные с PyPA" - -#: ../source/key_projects.rst:329 -msgid "bento" -msgstr "bento" - -#: ../source/key_projects.rst:331 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:336 -msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." -msgstr "" - -#: ../source/key_projects.rst:344 -msgid "buildout" -msgstr "buildout" - -#: ../source/key_projects.rst:346 -msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:351 -msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." -msgstr "" - -#: ../source/key_projects.rst:358 -msgid "conda" -msgstr "conda" - -#: ../source/key_projects.rst:360 -msgid "`Docs `__" -msgstr "`Документация `__" - -#: ../source/key_projects.rst:362 -msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." -msgstr "" - -#: ../source/key_projects.rst:369 -msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." -msgstr "" - -#: ../source/key_projects.rst:373 -msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." -msgstr "" - -#: ../source/key_projects.rst:386 -msgid "devpi" -msgstr "devpi" - -#: ../source/key_projects.rst:388 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:392 -msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." -msgstr "" - -#: ../source/key_projects.rst:401 -msgid "flit" -msgstr "flit" - -#: ../source/key_projects.rst:403 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:407 -msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." -msgstr "" - -#: ../source/key_projects.rst:412 -msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." -msgstr "" - -#: ../source/key_projects.rst:422 -msgid "enscons" -msgstr "enscons" - -#: ../source/key_projects.rst:424 -msgid "`Source `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:428 -msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." -msgstr "" - -#: ../source/key_projects.rst:443 -msgid "Hashdist" -msgstr "Hashdist" - -#: ../source/key_projects.rst:445 -msgid "`Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:448 -msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." -msgstr "" - -#: ../source/key_projects.rst:460 -msgid "hatch" -msgstr "" - -#: ../source/key_projects.rst:462 -msgid "`GitHub and Docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:465 -msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." -msgstr "" - -#: ../source/key_projects.rst:475 -msgid "multibuild" -msgstr "" - -#: ../source/key_projects.rst:477 -msgid "`GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:479 -msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." -msgstr "" - -#: ../source/key_projects.rst:485 -msgid "pex" -msgstr "pex" - -#: ../source/key_projects.rst:487 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:491 -msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." -msgstr "" - -#: ../source/key_projects.rst:500 -msgid "pip-tools" -msgstr "" - -#: ../source/key_projects.rst:502 -msgid "`GitHub and Docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:505 -msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." -msgstr "" - -#: ../source/key_projects.rst:517 -msgid "piwheels" -msgstr "" - -#: ../source/key_projects.rst:519 -msgid "`Website `__ | `Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:523 -msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." -msgstr "" - -#: ../source/key_projects.rst:532 -msgid "poetry" -msgstr "" - -#: ../source/key_projects.rst:534 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:538 -msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." -msgstr "" - -#: ../source/key_projects.rst:548 -msgid "pypiserver" -msgstr "" - -#: ../source/key_projects.rst:550 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:554 -msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." -msgstr "" - -#: ../source/key_projects.rst:564 -msgid "scikit-build" -msgstr "scikit-build" - -#: ../source/key_projects.rst:566 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:570 -msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." -msgstr "" - -#: ../source/key_projects.rst:582 -msgid "shiv" -msgstr "" - -#: ../source/key_projects.rst:584 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:588 -msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." -msgstr "" - -#: ../source/key_projects.rst:598 -msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" -msgstr "" - -#: ../source/key_projects.rst:603 -msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." -msgstr "" - -#: ../source/key_projects.rst:611 -msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." -msgstr "" - -#: ../source/key_projects.rst:617 -msgid "zest.releaser" -msgstr "zest.releaser" - -#: ../source/key_projects.rst:619 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:623 -msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." -msgstr "" - -#: ../source/key_projects.rst:630 -msgid "Standard Library Projects" -msgstr "Проекты в стандартное библиотеке" - -#: ../source/key_projects.rst:635 -msgid "ensurepip" -msgstr "ensurepip" - -#: ../source/key_projects.rst:637 -msgid "`Docs `__ | `Issues `__" -msgstr "" -"`Документация `__ | `" -"Замечания `__" - -#: ../source/key_projects.rst:640 -msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." -msgstr "" - -#: ../source/key_projects.rst:649 -msgid "distutils" -msgstr "distutils" - -#: ../source/key_projects.rst:651 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:654 -msgid "The original Python packaging system, added to the standard library in Python 2.0." -msgstr "" - -#: ../source/key_projects.rst:657 -msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." -msgstr "" - -#: ../source/key_projects.rst:670 -msgid "venv" -msgstr "venv" - -#: ../source/key_projects.rst:672 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:675 -msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/news.rst:2 -msgid "News" -msgstr "Новости" - -#: ../source/news.rst:5 -msgid "September 2019" -msgstr "" - -#: ../source/news.rst:6 -msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" -msgstr "" - -#: ../source/news.rst:9 -msgid "August 2019" -msgstr "" - -#: ../source/news.rst:10 -msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" -msgstr "" - -#: ../source/news.rst:13 -msgid "July 2019" -msgstr "" - -#: ../source/news.rst:14 -msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" -msgstr "" - -#: ../source/news.rst:15 -msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" -msgstr "" - -#: ../source/news.rst:16 -msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" -msgstr "" - -#: ../source/news.rst:17 -msgid "Updated directory layout examples for consistency. (:pr:`611`)" -msgstr "" - -#: ../source/news.rst:18 -msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" -msgstr "" - -#: ../source/news.rst:21 -msgid "June 2019" -msgstr "" - -#: ../source/news.rst:22 -msgid "Fixed some typos. (:pr:`620`)" -msgstr "" - -#: ../source/news.rst:25 -msgid "May 2019" -msgstr "" - -#: ../source/news.rst:26 -msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" -msgstr "" - -#: ../source/news.rst:27 -msgid "Added a MANIFEST.in guide page. (:pr:`609`)" -msgstr "" - -#: ../source/news.rst:30 -msgid "April 2019" -msgstr "" - -#: ../source/news.rst:31 -msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" -msgstr "" - -#: ../source/news.rst:32 -msgid "Reduced emphasis on virtualenv. (:pr:`606`)" -msgstr "" - -#: ../source/news.rst:35 -msgid "March 2019" -msgstr "" - -#: ../source/news.rst:36 -msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" -msgstr "" - -#: ../source/news.rst:37 -msgid "Covered RTD details for contributing. (:pr:`600`)" -msgstr "" - -#: ../source/news.rst:40 -msgid "February 2019" -msgstr "" - -#: ../source/news.rst:41 -msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" -msgstr "" - -#: ../source/news.rst:42 -msgid "Added instructions to install Python CLI applications. (:pr:`594`)" -msgstr "" - -#: ../source/news.rst:45 -msgid "January 2019" -msgstr "Январь 2019" - -#: ../source/news.rst:46 -msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" -msgstr "" - -#: ../source/news.rst:47 -msgid "Updated Sphinx and Nox. (:pr:`591`)" -msgstr "" - -#: ../source/news.rst:48 -msgid "Referenced Twine from Python3. (:pr:`581`)" -msgstr "" - -#: ../source/news.rst:51 -msgid "December 2018" -msgstr "" - -#: ../source/news.rst:52 -msgid "No programmers in the office!" -msgstr "" - -#: ../source/news.rst:55 -msgid "November 2018" -msgstr "" - -#: ../source/news.rst:56 -msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" -msgstr "" - -#: ../source/news.rst:57 -msgid "Changed bumpversion to bump2version. (:pr:`572`)" -msgstr "" - -#: ../source/news.rst:58 -msgid "Added single-sourcing package version example. (:pr:`573`)" -msgstr "" - -#: ../source/news.rst:59 -msgid "Added a guide for creating documentation. (:pr:`568`)" -msgstr "" - -#: ../source/news.rst:62 -msgid "October 2018" -msgstr "" - -#: ../source/news.rst:63 -msgid "Updated Nox package name. (:pr:`566`)" -msgstr "" - -#: ../source/news.rst:64 -msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" -msgstr "" - -#: ../source/news.rst:67 -msgid "September 2018" -msgstr "" - -#: ../source/news.rst:68 -msgid "Added a section on checking RST markup. (:pr:`554`)" -msgstr "" - -#: ../source/news.rst:69 -msgid "Updated user installs page. (:pr:`558`)" -msgstr "" - -#: ../source/news.rst:70 -msgid "Updated Google BigQuery urls. (:pr:`556`)" -msgstr "" - -#: ../source/news.rst:71 -msgid "Replaced tar command with working command. (:pr:`552`)" -msgstr "" - -#: ../source/news.rst:72 -msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" -msgstr "" - -#: ../source/news.rst:75 -msgid "August 2018" -msgstr "" - -#: ../source/news.rst:76 -msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" -msgstr "" - -#: ../source/news.rst:77 -msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" -msgstr "" - -#: ../source/news.rst:78 -msgid "Updated Python version supported by virtualenv. (:pr:`538`)" -msgstr "" - -#: ../source/news.rst:79 -msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" -msgstr "" - -#: ../source/news.rst:82 -msgid "July 2018" -msgstr "Июль 2018" - -#: ../source/news.rst:84 -msgid "Improved binary extension docs. (:pr:`531`)" -msgstr "Улучшена документация по двоичным расширениям (:pr:`531`)." - -#: ../source/news.rst:85 -msgid "Added scikit-build to key projects. (:pr:`530`)" -msgstr "Для ключевых проектов добавлен scikit-build (:pr:`530`)." - -#: ../source/news.rst:88 -msgid "June 2018" -msgstr "Июнь 2018" - -#: ../source/news.rst:90 -msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" -msgstr "" - -#: ../source/news.rst:91 -msgid "Updated Markdown descriptions explanation. (:pr:`522`)" -msgstr "" - -#: ../source/news.rst:94 -msgid "May 2018" -msgstr "Май 2018" - -#: ../source/news.rst:96 -msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" -msgstr "" - -#: ../source/news.rst:97 -msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" -msgstr "" - -#: ../source/news.rst:98 -msgid "Simplified packaging tutorial. (:pr:`498`)" -msgstr "" - -#: ../source/news.rst:99 -msgid "Updated Windows users instructions for clarity. (:pr:`493`)" -msgstr "" - -#: ../source/news.rst:100 -msgid "Updated the license section description for completeness. (:pr:`492`)" -msgstr "" - -#: ../source/news.rst:101 -msgid "Added specification-style document to contributing section. (:pr:`489`)" -msgstr "" - -#: ../source/news.rst:102 -msgid "Added documentation types to contributing guide. (:pr:`485`)" -msgstr "" - -#: ../source/news.rst:105 -msgid "April 2018" -msgstr "Апрель 2018" - -#: ../source/news.rst:107 -msgid "Added README guide. (:pr:`461`)" -msgstr "Добавлено руководство по написанию README (:pr:`461`)." - -#: ../source/news.rst:108 -msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" -msgstr "" - -#: ../source/news.rst:109 -msgid "Added instructions for Warehouse. (:pr:`471`)" -msgstr "" - -#: ../source/news.rst:110 -msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" -msgstr "" - -#: ../source/news.rst:111 -msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" -msgstr "" - -#: ../source/news.rst:112 -msgid "Added a guide for phasing out Python versions. (:pr:`459`)" -msgstr "" - -#: ../source/news.rst:113 -msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" -msgstr "" - -#: ../source/news.rst:116 -msgid "March 2018" -msgstr "Март 2018" - -#: ../source/news.rst:118 -msgid "Updated \"installing scientific packages\". (:pr:`455`)" -msgstr "" - -#: ../source/news.rst:119 -msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" -msgstr "" - -#: ../source/news.rst:120 -msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" -msgstr "" - -#: ../source/news.rst:121 -msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" -msgstr "" - -#: ../source/news.rst:124 -msgid "February 2018" -msgstr "Февраль 2018" - -#: ../source/news.rst:126 -msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" -msgstr "" - -#: ../source/news.rst:127 -msgid "Updated PyPI migration info. (:pr:`439`)" -msgstr "" - -#: ../source/news.rst:128 -msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" -msgstr "" - -#: ../source/news.rst:129 -msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" -msgstr "" - -#: ../source/news.rst:130 -msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" -msgstr "" - -#: ../source/news.rst:133 -msgid "January 2018" -msgstr "Январь 2018" - -#: ../source/news.rst:135 -msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" -msgstr "" - -#: ../source/news.rst:136 -msgid "Updated README.rst explanation. (:pr:`419`)" -msgstr "" - -#: ../source/news.rst:139 -msgid "December 2017" -msgstr "Декабрь 2017" - -#: ../source/news.rst:141 -msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" -msgstr "" - -#: ../source/news.rst:142 -msgid "Noted which fields can be used with environment markers. (:pr:`416`)" -msgstr "" - -#: ../source/news.rst:143 -msgid "Updated Requires-Python section. (:pr:`414`)" -msgstr "" - -#: ../source/news.rst:144 -msgid "Added news page. (:pr:`404`)" -msgstr "Добавлена страница новостей (:pr:`404`)." - -#: ../source/news.rst:147 -msgid "November 2017" -msgstr "Ноябрь 2017" - -#: ../source/news.rst:149 -msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" -msgstr "" - -#: ../source/news.rst:150 -msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" -msgstr "" - -#: ../source/news.rst:152 -msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" -msgstr "" - -#: ../source/news.rst:153 -msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" -msgstr "" - -#: ../source/news.rst:156 -msgid "October 2017" -msgstr "Октябрь 2017" - -#: ../source/news.rst:158 -msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" -msgstr "" - -#: ../source/news.rst:159 -msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" -msgstr "" - -#: ../source/news.rst:160 -msgid "Split the specifications page into multiple pages. (:pr:`386`)" -msgstr "" - -#: ../source/news.rst:163 -msgid "September 2017" -msgstr "Сентябрь 2017" - -#: ../source/news.rst:165 -msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" -msgstr "" - -#: ../source/news.rst:167 -msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" -msgstr "" - -#: ../source/news.rst:170 -msgid "August 2017" -msgstr "Август 2017" - -#: ../source/news.rst:172 -msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" -msgstr "" - -#: ../source/news.rst:173 -msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" -msgstr "" - -#: ../source/news.rst:174 -msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" -msgstr "" - -#: ../source/news.rst:177 -msgid "July 2017" -msgstr "Июль 2017" - -#: ../source/news.rst:179 -msgid "Added ``flit`` to the key projects list. (:pr:`358`)" -msgstr "" - -#: ../source/news.rst:180 -msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" -msgstr "" - -#: ../source/news.rst:181 -msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" -msgstr "" - -#: ../source/news.rst:182 -msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" -msgstr "" - -#: ../source/news.rst:183 -msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" -msgstr "" - -#: ../source/news.rst:186 -msgid "June 2017" -msgstr "Июнь 2017" - -#: ../source/news.rst:188 -msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" -msgstr "" - -#: ../source/news.rst:189 -msgid "Added documentation for ``python_requires``. (:pr:`338`)" -msgstr "" - -#: ../source/news.rst:190 -msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" -msgstr "" - -#: ../source/news.rst:191 -msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" -msgstr "" - -#: ../source/news.rst:192 -msgid "Added a license section to the distributing guide. (:pr:`331`)" -msgstr "" - -#: ../source/news.rst:193 -msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" -msgstr "" - -#: ../source/news.rst:194 -msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" -msgstr "" - -#: ../source/news.rst:195 -msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" -msgstr "Обновление до Sphinx 1.6.2 (:pr:`323`)." - -#: ../source/news.rst:196 -msgid "Switched to the PyPA theme. (:pr:`305`)" -msgstr "Переключение на тему PyPA (:pr:`305`)." - -#: ../source/news.rst:197 -msgid "Re-organized the documentation into the new structure. (:pr:`318`)" -msgstr "" - -#: ../source/news.rst:200 -msgid "May 2017" -msgstr "Май 2017" - -#: ../source/news.rst:202 -msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" -msgstr "" - -#: ../source/news.rst:203 -msgid "Added contributor and style guide. (:pr:`307`)" -msgstr "" - -#: ../source/news.rst:204 -msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" -msgstr "" - -#: ../source/news.rst:207 -msgid "April 2017" -msgstr "Апрель 2017" - -#: ../source/news.rst:209 -msgid "Added travis configuration for testing pull requests. (:pr:`300`)" -msgstr "" - -#: ../source/news.rst:210 -msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" -msgstr "" - -#: ../source/news.rst:211 -msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" -msgstr "" - -#: ../source/news.rst:212 -msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" -msgstr "" - -#: ../source/news.rst:213 -msgid "Added a topic on namespace packages. (:pr:`290`)" -msgstr "" - -#: ../source/news.rst:214 -msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" -msgstr "" - -#: ../source/news.rst:215 -msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" -msgstr "" - -#: ../source/news.rst:216 -msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" -msgstr "" - -#: ../source/news.rst:217 -msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" -msgstr "" - -#: ../source/news.rst:219 -msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" -msgstr "" - -#: ../source/news.rst:223 -msgid "March 2017" -msgstr "Март 2017" - -#: ../source/news.rst:225 -msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" -msgstr "" - -#: ../source/news.rst:228 -msgid "February 2017" -msgstr "Февраль 2017" - -#: ../source/news.rst:230 -msgid "Added :pep:`518`. (:pr:`281`)" -msgstr "Добавлен :pep:`518` (:pr:`281`)." - -#: ../source/overview.rst:3 -msgid "An Overview of Packaging for Python" -msgstr "Обзор создания Python'ьих пакетов" - -#: ../source/overview.rst:7 -msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." -msgstr "" - -#: ../source/overview.rst:12 -msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." -msgstr "" - -#: ../source/overview.rst:18 -msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." -msgstr "" - -#: ../source/overview.rst:26 -msgid "Thinking about deployment" -msgstr "Мысли о развёртывании" - -#: ../source/overview.rst:28 -msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" -msgstr "" - -#: ../source/overview.rst:32 -msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" -msgstr "" - -#: ../source/overview.rst:35 -msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" -msgstr "" - -#: ../source/overview.rst:37 -msgid "Is your software installed individually, or in large deployment batches?" -msgstr "" - -#: ../source/overview.rst:39 -msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." -msgstr "" - -#: ../source/overview.rst:46 -msgid "Packaging Python libraries and tools" -msgstr "Python'ьи библиотеки и инструменты для упаковки" - -#: ../source/overview.rst:48 -msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." -msgstr "" - -#: ../source/overview.rst:53 -msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." -msgstr "" - -#: ../source/overview.rst:59 -msgid "Python modules" -msgstr "Модули Python'а" - -#: ../source/overview.rst:61 -msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." -msgstr "" - -#: ../source/overview.rst:66 -msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." -msgstr "" - -#: ../source/overview.rst:73 -msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." -msgstr "" - -#: ../source/overview.rst:78 -msgid "Python source distributions" -msgstr "" - -#: ../source/overview.rst:80 -msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." -msgstr "" - -#: ../source/overview.rst:84 -msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." -msgstr "" - -#: ../source/overview.rst:90 -msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." -msgstr "" - -#: ../source/overview.rst:95 -msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." -msgstr "" - -#: ../source/overview.rst:100 -msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." -msgstr "" - -#: ../source/overview.rst:107 -msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" -msgstr "" - -#: ../source/overview.rst:114 -msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." -msgstr "" - -#: ../source/overview.rst:119 -msgid "Python binary distributions" -msgstr "" - -#: ../source/overview.rst:121 -msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." -msgstr "" - -#: ../source/overview.rst:125 -msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." -msgstr "" - -#: ../source/overview.rst:132 -msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." -msgstr "" - -#: ../source/overview.rst:140 -msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." -msgstr "" - -#: ../source/overview.rst:148 -msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." -msgstr "" - -#: ../source/overview.rst:155 -msgid "Packaging Python applications" -msgstr "Упаковка Python'ьих приложений" - -#: ../source/overview.rst:157 -msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." -msgstr "" - -#: ../source/overview.rst:162 -msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." -msgstr "" - -#: ../source/overview.rst:166 -msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." -msgstr "" - -#: ../source/overview.rst:172 -msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." -msgstr "" - -#: ../source/overview.rst:176 -msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." -msgstr "" - -#: ../source/overview.rst:181 -msgid "Depending on a framework" -msgstr "В зависимости от фреймворка" - -#: ../source/overview.rst:183 -msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." -msgstr "" - -#: ../source/overview.rst:189 -msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." -msgstr "" - -#: ../source/overview.rst:195 -msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." -msgstr "" - -#: ../source/overview.rst:199 -msgid "Service platforms" -msgstr "Сервисные платформы" - -#: ../source/overview.rst:201 -msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." -msgstr "" - -#: ../source/overview.rst:205 -msgid "`Heroku `_" -msgstr "" -"`Heroku `_" - -#: ../source/overview.rst:206 -msgid "`Google App Engine `_" -msgstr "`Google App Engine `_" - -#: ../source/overview.rst:207 -msgid "`PythonAnywhere `_" -msgstr "`PythonAnywhere `_" - -#: ../source/overview.rst:208 -msgid "`OpenShift `_" -msgstr "`OpenShift `_" - -#: ../source/overview.rst:209 -msgid "\"Serverless\" frameworks like `Zappa `_" -msgstr "" - -#: ../source/overview.rst:211 -msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." -msgstr "" - -#: ../source/overview.rst:216 -msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." -msgstr "" - -#: ../source/overview.rst:220 -msgid "Web browsers and mobile applications" -msgstr "Веб-браузеры и мобильные приложения" - -#: ../source/overview.rst:222 -msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." -msgstr "" - -#: ../source/overview.rst:227 -msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" -msgstr "" - -#: ../source/overview.rst:231 -msgid "`Kivy `_" -msgstr "`Kivy `_" - -#: ../source/overview.rst:232 -msgid "`Beeware `_" -msgstr "`Beeware `_" - -#: ../source/overview.rst:233 -msgid "`Brython `_" -msgstr "`Brython `_" - -#: ../source/overview.rst:234 -msgid "`Flexx `_" -msgstr "`Flexx `_" - -#: ../source/overview.rst:236 -msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." -msgstr "" - -#: ../source/overview.rst:241 -msgid "Depending on a pre-installed Python" -msgstr "В зависимости от предустановленного Python'а" - -#: ../source/overview.rst:243 -msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." -msgstr "" - -#: ../source/overview.rst:249 -msgid "Technologies which support this model:" -msgstr "Технологии, поддерживающие эту модель:" - -#: ../source/overview.rst:251 -msgid "`PEX `_ (Python EXecutable)" -msgstr "" -"`PEX `_ (Python EXecutable --- " -"исполняемый файл Python'а)" - -#: ../source/overview.rst:252 -msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" -msgstr "" -"`zipapp `_ (не помогает " -"управлять зависимостями, требует Python 3.5+)" - -#: ../source/overview.rst:253 -msgid "`shiv `_ (requires Python 3)" -msgstr "`shiv `_ (требует Python 3)" - -#: ../source/overview.rst:255 -msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." -msgstr "" - -#: ../source/overview.rst:260 -msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." -msgstr "" - -#: ../source/overview.rst:267 -msgid "Depending on a separate software distribution ecosystem" -msgstr "" -"В зависимости от отдельной экосистемы распространения программного " -"обеспечения" - -#: ../source/overview.rst:269 -msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." -msgstr "" - -#: ../source/overview.rst:274 -msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." -msgstr "" - -#: ../source/overview.rst:284 -msgid "Instructions on building and publishing for the Anaconda ecosystem:" -msgstr "" - -#: ../source/overview.rst:286 -msgid "`Building libraries and applications with conda `_" -msgstr "" - -#: ../source/overview.rst:287 -msgid "`Transitioning a native Python package to Anaconda `_" -msgstr "" - -#: ../source/overview.rst:289 -msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" -msgstr "" - -#: ../source/overview.rst:293 -msgid "`Enthought Canopy `_" -msgstr "`Enthought Canopy `_" - -#: ../source/overview.rst:294 -msgid "`ActiveState ActivePython `_" -msgstr "`ActiveState ActivePython `_" - -#: ../source/overview.rst:295 -msgid "`WinPython `_" -msgstr "`WinPython `_" - -#: ../source/overview.rst:300 -msgid "Bringing your own Python executable" -msgstr "Поставка собственного исполняемого файла Python'а" - -#: ../source/overview.rst:302 -msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." -msgstr "" - -#: ../source/overview.rst:306 -msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." -msgstr "" - -#: ../source/overview.rst:311 -msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." -msgstr "" - -#: ../source/overview.rst:315 -msgid "A selection of Python freezers:" -msgstr "" - -#: ../source/overview.rst:317 -msgid "`pyInstaller `_ - Cross-platform" -msgstr "`pyInstaller `_ --- кросс-платформенный;" - -#: ../source/overview.rst:318 -msgid "`cx_Freeze `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:319 -msgid "`constructor `_ - For command-line installers" -msgstr "" -"`constructor `_ --- для установщиков " -"командной строки;" - -#: ../source/overview.rst:320 -msgid "`py2exe `_ - Windows only" -msgstr "`py2exe `_ --- только для Windows;" - -#: ../source/overview.rst:321 -msgid "`py2app `_ - Mac only" -msgstr "" -"`py2app `_ --- только для Mac;" - -#: ../source/overview.rst:322 -msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" -msgstr "" -"`bbFreeze `_ --- Windows, Linux, только " -"Python 2;" - -#: ../source/overview.rst:323 -msgid "`osnap `_ - Windows and Mac" -msgstr "`osnap `_ --- Windows и Mac;" - -#: ../source/overview.rst:324 -msgid "`pynsist `_ - Windows only" -msgstr "`pynsist `_ --- Только для Windows." - -#: ../source/overview.rst:326 -msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." -msgstr "" - -#: ../source/overview.rst:332 -msgid "Bringing your own userspace" -msgstr "Поставка собственного пользовательского пространства" - -#: ../source/overview.rst:334 -msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." -msgstr "" - -#: ../source/overview.rst:341 -msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." -msgstr "" - -#: ../source/overview.rst:344 -msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" -msgstr "" - -#: ../source/overview.rst:347 -msgid "`AppImage `_" -msgstr "`AppImage `_" - -#: ../source/overview.rst:348 -msgid "`Docker `_" -msgstr "`Docker `_" - -#: ../source/overview.rst:349 -msgid "`Flatpak `_" -msgstr "`Flatpak `_" - -#: ../source/overview.rst:350 -msgid "`Snapcraft `_" -msgstr "`Snapcraft `_" - -#: ../source/overview.rst:353 -msgid "Bringing your own kernel" -msgstr "Поставка собственного ядра" - -#: ../source/overview.rst:355 -msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." -msgstr "" - -#: ../source/overview.rst:360 -msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" -msgstr "" - -#: ../source/overview.rst:364 -msgid "`Vagrant `_" -msgstr "`Vagrant `_" - -#: ../source/overview.rst:365 -msgid "`VHD `_, `AMI `_, and `other formats `_" -msgstr "" - -#: ../source/overview.rst:366 -msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" -msgstr "" - -#: ../source/overview.rst:369 -msgid "Bringing your own hardware" -msgstr "Поставка собственного оборудования" - -#: ../source/overview.rst:371 -msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." -msgstr "" - -#: ../source/overview.rst:375 -msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." -msgstr "" - -#: ../source/overview.rst:379 -msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." -msgstr "" - -#: ../source/overview.rst:389 -msgid "The simplified gamut of technologies used to package Python applications." -msgstr "" - -#: ../source/overview.rst:392 -msgid "What about..." -msgstr "Как насчёт..." - -#: ../source/overview.rst:394 -msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." -msgstr "" - -#: ../source/overview.rst:398 -msgid "Operating system packages" -msgstr "Пакетов операционной системы" - -#: ../source/overview.rst:400 -msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." -msgstr "" - -#: ../source/overview.rst:411 -msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." -msgstr "" - -#: ../source/overview.rst:417 -msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." -msgstr "" - -#: ../source/overview.rst:427 -msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." -msgstr "" - -#: ../source/overview.rst:432 -msgid "Security" -msgstr "Безопасность" - -#: ../source/overview.rst:434 -msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." -msgstr "" - -#: ../source/overview.rst:437 -msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." -msgstr "" - -#: ../source/overview.rst:446 -msgid "Wrap up" -msgstr "Заключение" - -#: ../source/overview.rst:448 -msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:6 -msgid "Binary distribution format" -msgstr "Формат распространения двоичных пакетов" - -#: ../source/specifications/binary-distribution-format.rst:8 -msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:13 -msgid "Abstract" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:15 -msgid "This PEP describes a built-package format for Python called \"wheel\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:17 -msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:27 -msgid "PEP Acceptance" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:29 -msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:34 -msgid "Rationale" -msgstr "Обоснование" - -#: ../source/specifications/binary-distribution-format.rst:36 -msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:43 -msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:52 -msgid "Details" -msgstr "Подробности" - -#: ../source/specifications/binary-distribution-format.rst:55 -msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:57 -msgid "Wheel installation notionally consists of two phases:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:59 -msgid "Unpack." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:61 -msgid "Parse ``distribution-1.0.dist-info/WHEEL``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:62 -msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:64 -msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:66 -msgid "Else unpack archive into platlib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:68 -msgid "Spread." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:70 -msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:72 -msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:78 -msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:80 -msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:82 -msgid "Remove empty ``distribution-1.0.data`` directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:83 -msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:87 -msgid "Recommended installer features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:97 -msgid "Rewrite ``#!python``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:90 -msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:96 -msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:102 -msgid "Generate script wrappers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:100 -msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:105 -msgid "Recommended archiver features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:112 -msgid "Place ``.dist-info`` at the end of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:108 -msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:115 -msgid "File Format" -msgstr "Формат файла" - -#: ../source/specifications/binary-distribution-format.rst:118 -msgid "File name convention" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:120 -msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "distribution" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "Distribution name, e.g. 'django', 'pyramid'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "Distribution version, e.g. 1.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:135 -msgid "build tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:130 -msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "language implementation and version tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "E.g. 'py27', 'py2', 'py3'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "abi tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "E.g. 'cp33m', 'abi3', 'none'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "platform tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "E.g. 'linux_x86_64', 'any'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:146 -msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:151 -msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:156 -msgid "Escaping and Unicode" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:158 -msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:161 -msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:164 -msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:166 -msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:169 -msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:172 -msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:176 -msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:182 -msgid "File contents" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:184 -msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:188 -msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:191 -msgid "``{distribution}-{version}.dist-info/`` contains metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:192 -msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:196 -msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:200 -msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:202 -msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:212 -msgid "``Wheel-Version`` is the version number of the Wheel specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:213 -msgid "``Generator`` is the name and optionally the version of the software that produced the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:215 -msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:218 -msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:220 -msgid "``Build`` is the build number and is omitted if there is no build number." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:221 -msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:224 -msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:226 -msgid "Wheel does not contain setup.py or setup.cfg." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:228 -msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:235 -#: ../source/specifications/recording-installed-packages.rst:35 -msgid "The .dist-info directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:237 -msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:239 -msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:241 -msgid "WHEEL is the wheel metadata specific to a build of the package." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:242 -msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:248 -msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:249 -msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:251 -msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:254 -msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:261 -msgid "The .data directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:263 -msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:271 -msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:277 -msgid "Signed wheel files" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:279 -msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:290 -msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:295 -msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:302 -msgid "(The hash value is the same format used in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:304 -msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:307 -msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:312 -msgid "See" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:314 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:315 -msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:316 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:317 -msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:321 -msgid "Comparison to .egg" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:323 -msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:328 -msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:331 -msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:337 -msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:341 -msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:344 -msgid "Wheel is a reference to the other Python." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:348 -msgid "FAQ" -msgstr "ЧаВо" - -#: ../source/specifications/binary-distribution-format.rst:352 -msgid "Wheel defines a .data directory. Should I put all my data there?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:354 -msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:363 -msgid "Why does wheel include attached signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:365 -msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:373 -msgid "Why does wheel allow JWS signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:375 -msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:381 -msgid "Why does wheel also allow S/MIME signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:383 -msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:386 -msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:391 -msgid "What's the deal with \"purelib\" vs. \"platlib\"?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:393 -msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:398 -msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:403 -msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:409 -msgid "Is it possible to import Python code directly from a wheel file?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:411 -msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:417 -msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:426 -msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:443 -msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:450 -msgid "Changes" -msgstr "Изменения" - -#: ../source/specifications/binary-distribution-format.rst:452 -msgid "Since :pep:`427`, this specification has changed as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:454 -msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:461 -msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:466 -msgid "Appendix" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:468 -msgid "Example urlsafe-base64-nopad implementation::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:482 -msgid "Copyright" -msgstr "Авторские права" - -#: ../source/specifications/binary-distribution-format.rst:484 -msgid "This document has been placed into the public domain." -msgstr "" - -#: ../source/specifications/core-metadata.rst:5 -msgid "Core metadata specifications" -msgstr "Спецификации основных метаданных" - -#: ../source/specifications/core-metadata.rst:7 -msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:10 -msgid "``Metadata-Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:11 -msgid "``Name``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:12 -msgid "``Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:14 -msgid "All the other fields are optional." -msgstr "Все остальные поля являются необязательными." - -#: ../source/specifications/core-metadata.rst:16 -msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." -msgstr "" - -#: ../source/specifications/core-metadata.rst:25 -msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:30 -msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." -msgstr "" - -#: ../source/specifications/core-metadata.rst:41 -msgid "Metadata-Version" -msgstr "Metadata-Version" - -#: ../source/specifications/core-metadata.rst:45 -msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." -msgstr "" - -#: ../source/specifications/core-metadata.rst:48 -msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:54 -msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." -msgstr "" - -#: ../source/specifications/core-metadata.rst:58 -#: ../source/specifications/core-metadata.rst:80 -#: ../source/specifications/core-metadata.rst:95 -#: ../source/specifications/core-metadata.rst:155 -#: ../source/specifications/core-metadata.rst:170 -#: ../source/specifications/core-metadata.rst:208 -#: ../source/specifications/core-metadata.rst:283 -#: ../source/specifications/core-metadata.rst:287 -#: ../source/specifications/core-metadata.rst:291 -#: ../source/specifications/core-metadata.rst:295 -#: ../source/specifications/core-metadata.rst:327 -#: ../source/specifications/core-metadata.rst:347 -#: ../source/specifications/core-metadata.rst:373 -#: ../source/specifications/core-metadata.rst:391 -#: ../source/specifications/core-metadata.rst:416 -#: ../source/specifications/core-metadata.rst:438 -#: ../source/specifications/core-metadata.rst:600 -#: ../source/specifications/core-metadata.rst:620 -#: ../source/specifications/core-metadata.rst:630 -msgid "Example::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:66 -msgid "Name" -msgstr "Имя" - -#: ../source/specifications/core-metadata.rst:69 -msgid "Added additional restrictions on format from :pep:`508`" -msgstr "" - -#: ../source/specifications/core-metadata.rst:72 -msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:88 -msgid "Version" -msgstr "Версия" - -#: ../source/specifications/core-metadata.rst:92 -msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:101 -msgid "Dynamic (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:105 -msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." -msgstr "" - -#: ../source/specifications/core-metadata.rst:108 -msgid "When found in the metadata of a source distribution, the following rules apply:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:111 -msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." -msgstr "" - -#: ../source/specifications/core-metadata.rst:115 -msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:118 -msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:122 -msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." -msgstr "" - -#: ../source/specifications/core-metadata.rst:127 -msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:131 -msgid "Platform (multiple use)" -msgstr "Platform (можно использовать несколько раз)" - -#: ../source/specifications/core-metadata.rst:135 -msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." -msgstr "" - -#: ../source/specifications/core-metadata.rst:146 -msgid "Supported-Platform (multiple use)" -msgstr "Supported-Platform (можно использовать несколько раз)" - -#: ../source/specifications/core-metadata.rst:150 -msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." -msgstr "" - -#: ../source/specifications/core-metadata.rst:164 -msgid "Summary" -msgstr "Сводка" - -#: ../source/specifications/core-metadata.rst:168 -msgid "A one-line summary of what the distribution does." -msgstr "Однострочная сводка того, что делает дистрибутив." - -#: ../source/specifications/core-metadata.rst:188 -msgid "This field may be specified in the message body instead." -msgstr "" - -#: ../source/specifications/core-metadata.rst:191 -msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:196 -msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." -msgstr "" - -#: ../source/specifications/core-metadata.rst:202 -msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:219 -msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." -msgstr "" - -#: ../source/specifications/core-metadata.rst:223 -msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:232 -msgid "Description-Content-Type" -msgstr "Description-Content-Type" - -#: ../source/specifications/core-metadata.rst:236 -msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:239 -msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." -msgstr "" - -#: ../source/specifications/core-metadata.rst:253 -msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:259 -msgid "Format::" -msgstr "Формат::" - -#: ../source/specifications/core-metadata.rst:263 -msgid "The ``type/subtype`` part has only a few legal values:" -msgstr "Часть ``тип/подтип`` имеет только несколько допустимых значений:" - -#: ../source/specifications/core-metadata.rst:265 -msgid "``text/plain``" -msgstr "``text/plain``" - -#: ../source/specifications/core-metadata.rst:266 -msgid "``text/x-rst``" -msgstr "``text/x-rst``" - -#: ../source/specifications/core-metadata.rst:267 -msgid "``text/markdown``" -msgstr "``text/markdown``" - -#: ../source/specifications/core-metadata.rst:269 -msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:273 -msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:278 -msgid "``GFM`` for `Github-flavored Markdown `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:280 -msgid "``CommonMark`` for `CommonMark `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:299 -msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." -msgstr "" - -#: ../source/specifications/core-metadata.rst:303 -msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:307 -msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:311 -msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." -msgstr "" - -#: ../source/specifications/core-metadata.rst:320 -msgid "Keywords" -msgstr "Keywords" - -#: ../source/specifications/core-metadata.rst:324 -msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." -msgstr "" - -#: ../source/specifications/core-metadata.rst:333 -msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." -msgstr "" - -#: ../source/specifications/core-metadata.rst:341 -msgid "Home-page" -msgstr "Home-page" - -#: ../source/specifications/core-metadata.rst:345 -msgid "A string containing the URL for the distribution's home page." -msgstr "" - -#: ../source/specifications/core-metadata.rst:353 -msgid "Download-URL" -msgstr "Download-URL" - -#: ../source/specifications/core-metadata.rst:357 -msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:366 -msgid "Author" -msgstr "Автор" - -#: ../source/specifications/core-metadata.rst:370 -msgid "A string containing the author's name at a minimum; additional contact information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:383 -msgid "Author-email" -msgstr "Author-email" - -#: ../source/specifications/core-metadata.rst:387 -msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:395 -#: ../source/specifications/core-metadata.rst:442 -msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:405 -msgid "Maintainer" -msgstr "Сопровождающий" - -#: ../source/specifications/core-metadata.rst:409 -msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:412 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:426 -msgid "Maintainer-email" -msgstr "Maintainer-email" - -#: ../source/specifications/core-metadata.rst:430 -msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:434 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:452 -msgid "License" -msgstr "Лицензия" - -#: ../source/specifications/core-metadata.rst:456 -msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." -msgstr "" - -#: ../source/specifications/core-metadata.rst:476 -msgid "Classifier (multiple use)" -msgstr "Classifier (можно использовать несколько раз)" - -#: ../source/specifications/core-metadata.rst:480 -msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:485 -#: ../source/specifications/core-metadata.rst:574 -#: ../source/specifications/core-metadata.rst:691 -#: ../source/specifications/core-metadata.rst:715 -msgid "This field may be followed by an environment marker after a semicolon." -msgstr "" - -#: ../source/specifications/core-metadata.rst:496 -msgid "Requires-Dist (multiple use)" -msgstr "Requires-Dist (можно использовать несколько раз)" - -#: ../source/specifications/core-metadata.rst:499 -#: ../source/specifications/core-metadata.rst:561 -#: ../source/specifications/core-metadata.rst:663 -#: ../source/specifications/core-metadata.rst:704 -msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." -msgstr "" - -#: ../source/specifications/core-metadata.rst:503 -msgid "Each entry contains a string naming some other distutils project required by this distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:506 -msgid "The format of a requirement string contains from one to four parts:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:508 -msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." -msgstr "" - -#: ../source/specifications/core-metadata.rst:510 -msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." -msgstr "" - -#: ../source/specifications/core-metadata.rst:513 -msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:516 -msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." -msgstr "" - -#: ../source/specifications/core-metadata.rst:519 -msgid "See :pep:`508` for full details of the allowed format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:521 -msgid "The project names should correspond to names as found on the `Python Package Index`_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:524 -msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:538 -msgid "Requires-Python" -msgstr "Requires-Python" - -#: ../source/specifications/core-metadata.rst:542 -msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." -msgstr "" - -#: ../source/specifications/core-metadata.rst:546 -msgid "The value must be in the format specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:548 -msgid "This field cannot be followed by an environment marker." -msgstr "" - -#: ../source/specifications/core-metadata.rst:558 -msgid "Requires-External (multiple use)" -msgstr "Requires-External (можно использовать несколько раз)" - -#: ../source/specifications/core-metadata.rst:565 -msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:570 -msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:576 -msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." -msgstr "" - -#: ../source/specifications/core-metadata.rst:581 -msgid "Notice that there is no particular rule on the strings to be used." -msgstr "" - -#: ../source/specifications/core-metadata.rst:593 -msgid "Project-URL (multiple-use)" -msgstr "Project-URL (можно использовать несколько раз)" - -#: ../source/specifications/core-metadata.rst:597 -msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." -msgstr "" - -#: ../source/specifications/core-metadata.rst:604 -msgid "The label is free text limited to 32 characters." -msgstr "" - -#: ../source/specifications/core-metadata.rst:612 -msgid "Provides-Extra (multiple use)" -msgstr "Provides-Extra (можно использовать несколько раз)" - -#: ../source/specifications/core-metadata.rst:616 -msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." -msgstr "" - -#: ../source/specifications/core-metadata.rst:625 -msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:635 -msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." -msgstr "" - -#: ../source/specifications/core-metadata.rst:639 -msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:644 -msgid "Rarely Used Fields" -msgstr "Редко используемые поля" - -#: ../source/specifications/core-metadata.rst:646 -msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:651 -msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." -msgstr "" - -#: ../source/specifications/core-metadata.rst:660 -msgid "Provides-Dist (multiple use)" -msgstr "Provides-Dist (можно использовать несколько раз)" - -#: ../source/specifications/core-metadata.rst:667 -msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:672 -msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:679 -msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:687 -msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." -msgstr "" - -#: ../source/specifications/core-metadata.rst:701 -msgid "Obsoletes-Dist (multiple use)" -msgstr "Obsoletes-Dist (можно использовать несколько раз)" - -#: ../source/specifications/core-metadata.rst:708 -msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." -msgstr "" - -#: ../source/specifications/core-metadata.rst:712 -msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:717 -msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:730 -msgid "reStructuredText markup: http://docutils.sourceforge.net/" -msgstr "Разметка reStructuredText: http://docutils.sourceforge.net/" - -#: ../source/specifications/core-metadata.rst:735 -msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" -msgstr "" -"RFC 822 Длинные поля заголовков: http://www.freesoft.org/CIE/RFC/822/7.htm" - -#: ../source/specifications/declaring-build-dependencies.rst:6 -msgid "Declaring build system dependencies" -msgstr "Объявление зависимостей системы сборки" - -#: ../source/specifications/declaring-build-dependencies.rst:8 -msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:5 -msgid "Declaring project metadata" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:7 -msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:12 -msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:18 -msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:27 -msgid "The only fields required to be statically defined are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:29 -#: ../source/specifications/declaring-project-metadata.rst:41 -msgid "``name``" -msgstr "``name``" - -#: ../source/specifications/declaring-project-metadata.rst:31 -msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:34 -#: ../source/specifications/declaring-project-metadata.rst:54 -msgid "``version``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:36 -msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:43 -#: ../source/specifications/declaring-project-metadata.rst:56 -#: ../source/specifications/declaring-project-metadata.rst:68 -#: ../source/specifications/declaring-project-metadata.rst:117 -msgid "TOML_ type: string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:44 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:47 -msgid "The name of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:49 -msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:57 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:60 -msgid "The version of the project as supported by :pep:`440`." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:62 -msgid "Users SHOULD prefer to specify already-normalized versions." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:66 -msgid "``description``" -msgstr "``description``" - -#: ../source/specifications/declaring-project-metadata.rst:69 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:72 -msgid "The summary description of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:76 -msgid "``readme``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:78 -msgid "TOML_ type: string or table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:79 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:83 -msgid "The full description of the project (i.e. the README)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:85 -msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:96 -msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:103 -msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:115 -msgid "``requires-python``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:118 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:121 -msgid "The Python version requirements of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:125 -msgid "``license``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:127 -msgid "TOML_ type: table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:128 -msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:131 -msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:140 -msgid "``authors``/``maintainers``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:142 -msgid "TOML_ type: Array of inline tables with string keys and values" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:143 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:149 -msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:154 -msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:157 -msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:163 -msgid "Using the data to fill in :ref:`core metadata ` is as follows:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:166 -msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:169 -msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:173 -msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:177 -msgid "Multiple values should be separated by commas." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:181 -msgid "``keywords``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:183 -#: ../source/specifications/declaring-project-metadata.rst:193 -msgid "TOML_ type: array of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:184 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:187 -msgid "The keywords for the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:191 -msgid "``classifiers``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:194 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:197 -msgid "Trove classifiers which apply to the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:201 -msgid "``urls``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:203 -msgid "TOML_ type: table with keys and values of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:204 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:207 -msgid "A table of URLs where the key is the URL label and the value is the URL itself." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:212 -msgid "Entry points" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:214 -msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:216 -msgid ":ref:`Entry points specification `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:218 -msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:224 -msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:228 -msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:234 -msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:242 -msgid "``dependencies``/``optional-dependencies``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:244 -msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:247 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:251 -msgid "The (optional) dependencies of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:253 -msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:258 -msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:269 -msgid "``dynamic``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:271 -msgid "TOML_ type: array of string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:272 -msgid "A corresponding :ref:`core metadata ` field does not exist" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:275 -msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:281 -msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:283 -msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:285 -msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:290 -msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:294 -msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:296 -msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:300 -msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:6 -msgid "Dependency specifiers" -msgstr "Спецификаторы зависимостей" - -#: ../source/specifications/dependency-specifiers.rst:8 -msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:11 -msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." -msgstr "" - -#: ../source/specifications/direct-url.rst:6 -msgid "Recording the Direct URL Origin of installed distributions" -msgstr "" - -#: ../source/specifications/direct-url.rst:8 -msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." -msgstr "" - -#: ../source/specifications/direct-url.rst:17 -msgid "Specification" -msgstr "Спецификация" - -#: ../source/specifications/direct-url.rst:19 -msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/direct-url.rst:23 -#: ../source/specifications/recording-installed-packages.rst:206 -msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." -msgstr "" - -#: ../source/specifications/direct-url.rst:26 -msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." -msgstr "" - -#: ../source/specifications/direct-url.rst:29 -msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." -msgstr "" - -#: ../source/specifications/direct-url.rst:36 -msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." -msgstr "" - -#: ../source/specifications/direct-url.rst:39 -msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" -msgstr "" - -#: ../source/specifications/direct-url.rst:45 -msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." -msgstr "" - -#: ../source/specifications/direct-url.rst:49 -msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" -msgstr "" - -#: ../source/specifications/direct-url.rst:52 -msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." -msgstr "" - -#: ../source/specifications/direct-url.rst:58 -msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." -msgstr "" - -#: ../source/specifications/direct-url.rst:61 -msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." -msgstr "" - -#: ../source/specifications/direct-url.rst:68 -msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:71 -msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." -msgstr "" - -#: ../source/specifications/direct-url.rst:78 -msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:81 -msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." -msgstr "" - -#: ../source/specifications/direct-url.rst:84 -msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." -msgstr "" - -#: ../source/specifications/direct-url.rst:91 -msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." -msgstr "" - -#: ../source/specifications/direct-url.rst:96 -msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." -msgstr "" - -#: ../source/specifications/direct-url.rst:102 -msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." -msgstr "" - -#: ../source/specifications/direct-url.rst:110 -msgid "Registered VCS" -msgstr "" - -#: ../source/specifications/direct-url.rst:112 -msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." -msgstr "" - -#: ../source/specifications/direct-url.rst:122 -msgid "Git" -msgstr "Git" - -#: ../source/specifications/direct-url.rst:124 -#: ../source/specifications/direct-url.rst:156 -#: ../source/specifications/direct-url.rst:179 -#: ../source/specifications/direct-url.rst:202 -msgid "Home page" -msgstr "Домашняя страница" - -#: ../source/specifications/direct-url.rst:126 -msgid "https://git-scm.com/" -msgstr "https://git-scm.com/" - -#: ../source/specifications/direct-url.rst:128 -#: ../source/specifications/direct-url.rst:160 -#: ../source/specifications/direct-url.rst:183 -#: ../source/specifications/direct-url.rst:206 -msgid "vcs command" -msgstr "" - -#: ../source/specifications/direct-url.rst:130 -#: ../source/specifications/direct-url.rst:134 -msgid "git" -msgstr "" - -#: ../source/specifications/direct-url.rst:132 -#: ../source/specifications/direct-url.rst:164 -#: ../source/specifications/direct-url.rst:187 -#: ../source/specifications/direct-url.rst:210 -msgid "``vcs`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:136 -#: ../source/specifications/direct-url.rst:168 -#: ../source/specifications/direct-url.rst:191 -#: ../source/specifications/direct-url.rst:214 -msgid "``requested_revision`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:138 -msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." -msgstr "" - -#: ../source/specifications/direct-url.rst:141 -#: ../source/specifications/direct-url.rst:172 -#: ../source/specifications/direct-url.rst:195 -#: ../source/specifications/direct-url.rst:219 -msgid "``commit_id`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:143 -msgid "A commit hash (40 hexadecimal characters sha1)." -msgstr "" - -#: ../source/specifications/direct-url.rst:147 -msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." -msgstr "" - -#: ../source/specifications/direct-url.rst:154 -msgid "Mercurial" -msgstr "Mercurial" - -#: ../source/specifications/direct-url.rst:158 -msgid "https://www.mercurial-scm.org/" -msgstr "https://www.mercurial-scm.org/" - -#: ../source/specifications/direct-url.rst:162 -#: ../source/specifications/direct-url.rst:166 -msgid "hg" -msgstr "hg" - -#: ../source/specifications/direct-url.rst:170 -msgid "A tag name, branch name, changeset ID, shortened changeset ID." -msgstr "" - -#: ../source/specifications/direct-url.rst:174 -msgid "A changeset ID (40 hexadecimal characters)." -msgstr "" - -#: ../source/specifications/direct-url.rst:177 -msgid "Bazaar" -msgstr "Bazaar" - -#: ../source/specifications/direct-url.rst:181 -msgid "https://bazaar.canonical.com/" -msgstr "" - -#: ../source/specifications/direct-url.rst:185 -#: ../source/specifications/direct-url.rst:189 -msgid "bzr" -msgstr "bzr" - -#: ../source/specifications/direct-url.rst:193 -msgid "A tag name, branch name, revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:197 -msgid "A revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:200 -msgid "Subversion" -msgstr "" - -#: ../source/specifications/direct-url.rst:204 -msgid "https://subversion.apache.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:208 -#: ../source/specifications/direct-url.rst:212 -msgid "svn" -msgstr "svn" - -#: ../source/specifications/direct-url.rst:216 -msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." -msgstr "" - -#: ../source/specifications/direct-url.rst:221 -msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." -msgstr "" - -#: ../source/specifications/direct-url.rst:229 -msgid "Example direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:231 -msgid "Source archive:" -msgstr "" - -#: ../source/specifications/direct-url.rst:242 -msgid "Git URL with tag and commit-hash:" -msgstr "" - -#: ../source/specifications/direct-url.rst:255 -msgid "Local directory:" -msgstr "" - -#: ../source/specifications/direct-url.rst:264 -msgid "Local directory installed in editable mode:" -msgstr "" - -#: ../source/specifications/direct-url.rst:277 -msgid "Example pip commands and their effect on direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:279 -msgid "Commands that generate a ``direct_url.json``:" -msgstr "" - -#: ../source/specifications/direct-url.rst:281 -msgid "pip install https://example.com/app-1.0.tgz" -msgstr "" - -#: ../source/specifications/direct-url.rst:282 -msgid "pip install https://example.com/app-1.0.whl" -msgstr "" - -#: ../source/specifications/direct-url.rst:283 -msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" -msgstr "" - -#: ../source/specifications/direct-url.rst:284 -msgid "pip install ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:285 -msgid "pip install file:///home/user/app" -msgstr "" - -#: ../source/specifications/direct-url.rst:286 -msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" -msgstr "" - -#: ../source/specifications/direct-url.rst:290 -msgid "pip install -e ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:292 -msgid "Commands that *do not* generate a ``direct_url.json``" -msgstr "" - -#: ../source/specifications/direct-url.rst:294 -msgid "pip install app" -msgstr "" - -#: ../source/specifications/direct-url.rst:295 -msgid "pip install app --no-index --find-links https://example.com/" -msgstr "" - -#: ../source/specifications/entry-points.rst:5 -msgid "Entry points specification" -msgstr "Спецификация точек входа" - -#: ../source/specifications/entry-points.rst:7 -msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" -msgstr "" - -#: ../source/specifications/entry-points.rst:11 -msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." -msgstr "" - -#: ../source/specifications/entry-points.rst:14 -msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." -msgstr "" - -#: ../source/specifications/entry-points.rst:19 -msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." -msgstr "" - -#: ../source/specifications/entry-points.rst:28 -msgid "Data model" -msgstr "Модель данных" - -#: ../source/specifications/entry-points.rst:30 -msgid "Conceptually, an entry point is defined by three required properties:" -msgstr "" - -#: ../source/specifications/entry-points.rst:32 -msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:42 -msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:51 -msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:64 -msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." -msgstr "" - -#: ../source/specifications/entry-points.rst:68 -msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." -msgstr "" - -#: ../source/specifications/entry-points.rst:73 -msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." -msgstr "" - -#: ../source/specifications/entry-points.rst:80 -msgid "File format" -msgstr "" - -#: ../source/specifications/entry-points.rst:82 -msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." -msgstr "" - -#: ../source/specifications/entry-points.rst:87 -msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:97 -msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:100 -msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." -msgstr "" - -#: ../source/specifications/entry-points.rst:104 -msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." -msgstr "" - -#: ../source/specifications/entry-points.rst:112 -msgid "For example::" -msgstr "Например::" - -#: ../source/specifications/entry-points.rst:124 -msgid "Use for scripts" -msgstr "" - -#: ../source/specifications/entry-points.rst:126 -msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." -msgstr "" - -#: ../source/specifications/entry-points.rst:134 -msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:141 -msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." -msgstr "" - -#: ../source/specifications/entry-points.rst:149 -msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." -msgstr "" - -#: ../source/specifications/entry-points.rst:154 -msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." -msgstr "" - -#: ../source/specifications/index.rst:4 -msgid "PyPA specifications" -msgstr "" - -#: ../source/specifications/index.rst:6 -msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." -msgstr "" - -#: ../source/specifications/index.rst:13 -msgid "Package Distribution Metadata" -msgstr "" - -#: ../source/specifications/index.rst:30 -msgid "Package Distribution File Formats" -msgstr "" - -#: ../source/specifications/index.rst:40 -msgid "Package Index Interfaces" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:6 -msgid "Platform compatibility tags" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:8 -msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:12 -msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:16 -msgid "Platform tags for Windows" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:18 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:22 -msgid "Platform tags for macOS (Mac OS X)" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:24 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:28 -msgid "Platform tags for common Linux distributions" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:32 -msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:36 -msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:41 -msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:44 -msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:46 -msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:49 -msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:54 -msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:59 -msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:65 -msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:71 -msgid "Manylinux compatibility support" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:74 -msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:76 -msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:79 -msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "Tool" -msgstr "Инструмент" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux1``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2010``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2014``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux_x_y``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=8.1.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=20.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "auditwheel" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=1.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=2.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.3.0`` [#]_" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:90 -msgid "Platform tags for other \\*nix platforms" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:92 -msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:98 -msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" -msgstr "" - -#: ../source/specifications/pypirc.rst:6 -msgid "The :file:`.pypirc` file" -msgstr "" - -#: ../source/specifications/pypirc.rst:8 -msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." -msgstr "" - -#: ../source/specifications/pypirc.rst:13 -msgid "The format (originally defined by the :ref:`distutils` package) is:" -msgstr "" - -#: ../source/specifications/pypirc.rst:32 -msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:35 -msgid "Each section describing a repository defines three fields:" -msgstr "" - -#: ../source/specifications/pypirc.rst:37 -msgid "``repository``: The URL of the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:38 -msgid "``username``: The registered username on the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:39 -msgid "``password``: The password that will used to authenticate the username." -msgstr "" - -#: ../source/specifications/pypirc.rst:43 -msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." -msgstr "" - -#: ../source/specifications/pypirc.rst:47 -msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" -msgstr "" - -#: ../source/specifications/pypirc.rst:57 -msgid "Common configurations" -msgstr "" - -#: ../source/specifications/pypirc.rst:61 -msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." -msgstr "" - -#: ../source/specifications/pypirc.rst:66 -msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" -msgstr "" - -#: ../source/specifications/pypirc.rst:82 -msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." -msgstr "" - -#: ../source/specifications/pypirc.rst:86 -msgid "Using a PyPI token" -msgstr "" - -#: ../source/specifications/pypirc.rst:88 -msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" -msgstr "" - -#: ../source/specifications/pypirc.rst:97 -msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." -msgstr "" - -#: ../source/specifications/pypirc.rst:103 -msgid "Using another package index" -msgstr "" - -#: ../source/specifications/pypirc.rst:105 -msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" -msgstr "" - -#: ../source/specifications/pypirc.rst:132 -msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:5 -msgid "Recording installed projects" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:7 -msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:12 -msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:21 -msgid "History and change workflow" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:23 -msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:29 -msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:37 -msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:41 -msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:50 -msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:60 -msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:69 -msgid "This ``.dist-info`` directory can contain these files, described in detail below:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:72 -msgid "``METADATA``: contains project metadata" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:73 -msgid "``RECORD``: records the list of installed files." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:74 -msgid "``INSTALLER``: records the name of the tool used to install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:76 -msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:82 -msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:87 -msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:94 -msgid "The METADATA file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:96 -msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:99 -msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:105 -msgid "The RECORD file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:107 -msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:110 -msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:113 -msgid "field delimiter: ``,`` (comma)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:114 -msgid "quoting char: ``\"`` (straight double quote)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:115 -msgid "line terminator: either ``\\r\\n`` or ``\\n``." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:117 -msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:120 -msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:125 -msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:130 -msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:133 -msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:139 -msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:146 -msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:151 -msgid "Here is an example snippet of a possible ``RECORD`` file::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:170 -msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:177 -msgid "The INSTALLER file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:179 -msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:185 -msgid "The file can be terminated by zero or more ASCII whitespace characters." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:187 -msgid "Here are examples of two possible ``INSTALLER`` files::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:195 -msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:201 -msgid "The direct_url.json file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:203 -msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:209 -msgid "Its detailed specification is at :ref:`direct-url`." -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:6 -msgid "Simple repository API" -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:8 -msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:6 -msgid "Source distribution format" -msgstr "Формат распространения в исходных кодах" - -#: ../source/specifications/source-distribution-format.rst:8 -msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:13 -msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:21 -msgid "Source distributions are also known as *sdists* for short." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:24 -msgid "Source distribution file name" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:26 -msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:31 -msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:35 -msgid "Source distribution file format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:37 -msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:45 -msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:48 -msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:6 -msgid "Version specifiers" -msgstr "Спецификаторы версии" - -#: ../source/specifications/version-specifiers.rst:8 -msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:11 -msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." -msgstr "" - -#: ../source/support.rst:3 -msgid "How to Get Support" -msgstr "Как получить поддержку" - -#: ../source/support.rst:5 -msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." -msgstr "" - -#: ../source/support.rst:8 -msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:5 -msgid "Creating Documentation" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:7 -msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:13 -msgid "Installing Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:14 -msgid "Use ``pip`` to install Sphinx:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:28 -msgid "For other installation methods, see this `installation guide`_ by Sphinx." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:33 -msgid "Getting Started With Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:35 -msgid "Create a ``docs`` directory inside your project to hold your documentation:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:42 -msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:49 -msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:51 -msgid "You can add some information about your project in ``index.rst``, then build them:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:57 -msgid "For more details on the build process, see this `guide`_ by Read The Docs." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:62 -msgid "Other Sources" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:64 -msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/index.rst:4 -msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:5 -msgid "Installing Packages" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:7 -msgid "This section covers the basics of how to install Python :term:`packages `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:10 -msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:28 -msgid "Requirements for Installing Packages" -msgstr "Требования к установке пакетов" - -#: ../source/tutorials/installing-packages.rst:30 -msgid "This section describes the steps to follow before installing other Python packages." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:35 -msgid "Ensure you can run Python from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:37 -msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:53 -msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:57 -msgid "If you're a newcomer and you get an error like this:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:66 -msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:72 -msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:82 -msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:87 -msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:99 -msgid "Ensure you can run pip from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:101 -msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:116 -msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:124 -msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:139 -msgid "If that still doesn't allow you to run ``python -m pip``:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:141 -msgid "Securely Download `get-pip.py `_ [1]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:144 -msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:150 -msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:159 -msgid "Ensure pip, setuptools, and wheel are up to date" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:161 -msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:169 -msgid "Optionally, create a virtual environment" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:171 -msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:188 -msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:195 -msgid "Creating Virtual Environments" -msgstr "Создание виртуальных окружений" - -#: ../source/tutorials/installing-packages.rst:197 -msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:203 -msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:209 -msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:213 -msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:216 -msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:220 -msgid "Currently, there are two common tools for creating Python virtual environments:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:222 -msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:225 -msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:230 -msgid "The basic usage is like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:232 -msgid "Using `venv`_:" -msgstr "Использование `venv`_:" - -#: ../source/tutorials/installing-packages.rst:248 -msgid "Using :ref:`virtualenv`:" -msgstr "Использование :ref:`virtualenv`:" - -#: ../source/tutorials/installing-packages.rst:264 -msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:266 -msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:271 -msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:281 -msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:288 -msgid "Use pip for Installing" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:290 -msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:297 -msgid "Installing from PyPI" -msgstr "Установка из PyPI" - -#: ../source/tutorials/installing-packages.rst:299 -msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:307 -msgid "To install the latest version of \"SomeProject\":" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:321 -msgid "To install a specific version:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:335 -msgid "To install greater than or equal to one version and less than another:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:350 -msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:365 -msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:370 -msgid "Source Distributions vs Wheels" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:372 -msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:378 -msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:383 -msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:391 -msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:408 -msgid "Installing to the User Site" -msgstr "Установка в пользовательский каталог :file:`site`" - -#: ../source/tutorials/installing-packages.rst:410 -msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:425 -msgid "For more information see the `User Installs `_ section from the pip docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:429 -msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:432 -msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:440 -msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:446 -msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:462 -msgid "Install a list of requirements specified in a :ref:`Requirements File `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:478 -msgid "Installing from VCS" -msgstr "Установка из СКВ" - -#: ../source/tutorials/installing-packages.rst:480 -msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:502 -msgid "Installing from other Indexes" -msgstr "Установка из других индексов" - -#: ../source/tutorials/installing-packages.rst:504 -msgid "Install from an alternate index" -msgstr "Установка из альтернативного индекса" - -#: ../source/tutorials/installing-packages.rst:518 -msgid "Search an additional index during install, in addition to :term:`PyPI `" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:534 -msgid "Installing from a local src tree" -msgstr "Установка из локального дерева исходных кодов" - -#: ../source/tutorials/installing-packages.rst:537 -msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:554 -msgid "You can also install normally from src" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:571 -msgid "Install a particular source archive file." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:585 -msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:605 -msgid "Installing from other sources" -msgstr "Установка из других источников" - -#: ../source/tutorials/installing-packages.rst:607 -msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:619 -msgid "Installing Prereleases" -msgstr "Установка предварительных выпусков" - -#: ../source/tutorials/installing-packages.rst:621 -msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:637 -msgid "Installing Setuptools \"Extras\"" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:639 -msgid "Install `setuptools extras`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:659 -msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:668 -msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:673 -msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:4 -msgid "Managing Application Dependencies" -msgstr "Управление зависимостями приложений" - -#: ../source/tutorials/managing-dependencies.rst:6 -msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:9 -msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:13 -msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:17 -msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:24 -msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:30 -msgid "Installing Pipenv" -msgstr "Установка Pipenv" - -#: ../source/tutorials/managing-dependencies.rst:32 -msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:38 -msgid "Use ``pip`` to install Pipenv:" -msgstr "Используйте ``pip`` для установки Pipenv:" - -#: ../source/tutorials/managing-dependencies.rst:54 -msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:65 -msgid "Installing packages for your project" -msgstr "Установка пакетов для вашего проекта" - -#: ../source/tutorials/managing-dependencies.rst:67 -msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:76 -msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:112 -msgid "Using installed packages" -msgstr "Использование установленных пакетов" - -#: ../source/tutorials/managing-dependencies.rst:114 -msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:125 -msgid "Then you can run this script using ``pipenv run``:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:131 -msgid "You should get output similar to this:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:137 -msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:143 -#: ../source/tutorials/packaging-projects.rst:594 -msgid "Next steps" -msgstr "Следующие шаги" - -#: ../source/tutorials/managing-dependencies.rst:145 -msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:148 -msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:151 -msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:160 -msgid "Other Tools for Application Dependency Management" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:162 -msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:166 -msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:172 -msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:175 -msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:177 -msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:2 -msgid "Packaging Python Projects" -msgstr "Упаковка Python'ьих проектов" - -#: ../source/tutorials/packaging-projects.rst:4 -msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:10 -msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:18 -msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:35 -msgid "A simple project" -msgstr "Простой проект" - -#: ../source/tutorials/packaging-projects.rst:37 -msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:41 -msgid "Create the following file structure locally:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:51 -msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:54 -msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:63 -msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:67 -msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:75 -msgid "Creating the package files" -msgstr "Создание файлов пакета" - -#: ../source/tutorials/packaging-projects.rst:77 -msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:95 -msgid "Creating a test directory" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:97 -msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:101 -msgid "Creating pyproject.toml" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:103 -msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:117 -msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:121 -msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:127 -msgid "See :pep:`517` and :pep:`518` for background and details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:131 -msgid "Configuring metadata" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:133 -msgid "There are two types of metadata: static and dynamic." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:135 -msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:137 -msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:141 -msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:148 -msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:153 -msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:185 -msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:191 -#: ../source/tutorials/packaging-projects.rst:286 -msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:196 -msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:199 -#: ../source/tutorials/packaging-projects.rst:293 -msgid "``author`` and ``author_email`` are used to identify the author of the package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:201 -#: ../source/tutorials/packaging-projects.rst:295 -msgid "``description`` is a short, one-sentence summary of the package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:202 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:206 -#: ../source/tutorials/packaging-projects.rst:300 -msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:208 -#: ../source/tutorials/packaging-projects.rst:302 -msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:211 -#: ../source/tutorials/packaging-projects.rst:305 -msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:213 -#: ../source/tutorials/packaging-projects.rst:307 -msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:221 -msgid "In the ``options`` category, we have controls for setuptools itself:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:223 -msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:227 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:234 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:238 -#: ../source/tutorials/packaging-projects.rst:329 -msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:244 -msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:248 -msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:283 -msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:291 -msgid "``version`` is the package version. See :pep:`440` for more details on versions." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:296 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:314 -msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:319 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:325 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:333 -msgid "Creating README.md" -msgstr "Создание файла :file:`README.md`" - -#: ../source/tutorials/packaging-projects.rst:335 -msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:347 -msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:354 -msgid "Creating a LICENSE" -msgstr "Создание файла :file:`LICENSE`" - -#: ../source/tutorials/packaging-projects.rst:356 -msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:387 -msgid "Including other files" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:389 -msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:393 -msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:402 -msgid "Generating distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:404 -msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:408 -msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:422 -msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:425 -msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:439 -msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:449 -msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:458 -msgid "Uploading the distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:460 -msgid "Finally, it's time to upload your package to the Python Package Index!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:462 -msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:470 -msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:477 -msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:492 -msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:506 -msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:510 -msgid "After the command completes, you should see output similar to this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:523 -msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:528 -msgid "Installing your newly uploaded package" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:530 -msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:546 -msgid "Make sure to specify your username in the package name!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:548 -msgid "pip should install the package from TestPyPI and the output should look something like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:558 -msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:565 -msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:580 -msgid "and import the package:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:588 -msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:596 -msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:599 -msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:604 -msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:608 -msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:610 -msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:613 -msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:617 -msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:619 -msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:622 -msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:624 -msgid "Read about :doc:`/guides/packaging-binary-extensions`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:625 -msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." -msgstr "" diff --git a/locales/si/LC_MESSAGES/messages.po b/locales/si/LC_MESSAGES/messages.po deleted file mode 100644 index e35f7229a..000000000 --- a/locales/si/LC_MESSAGES/messages.po +++ /dev/null @@ -1,9253 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2013–2020, PyPA -# This file is distributed under the same license as the Python Packaging User Guide package. -# HelaBasa , 2021. -msgid "" -msgstr "" -"Project-Id-Version: Python Packaging User Guide\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: Automatically generated\n" -"Language-Team: none\n" -"Language: si\n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=UTF-8\n" -"Content-Transfer-Encoding: 8bit\n" - -#: ../source/contribute.rst:5 -msgid "Contribute to this guide" -msgstr "" - -#: ../source/contribute.rst:7 -msgid "The |PyPUG| welcomes contributors! There are lots of ways to help out, including:" -msgstr "" - -#: ../source/contribute.rst:10 -msgid "Reading the guide and giving feedback" -msgstr "" - -#: ../source/contribute.rst:11 -msgid "Reviewing new contributions" -msgstr "" - -#: ../source/contribute.rst:12 -msgid "Revising existing content" -msgstr "" - -#: ../source/contribute.rst:13 -msgid "Writing new content" -msgstr "" - -#: ../source/contribute.rst:15 -msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." -msgstr "" - -#: ../source/contribute.rst:24 -msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." -msgstr "" - -#: ../source/contribute.rst:31 -msgid "Documentation types" -msgstr "" - -#: ../source/contribute.rst:33 -msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." -msgstr "" - -#: ../source/contribute.rst:38 -#: ../source/tutorials/index.rst:2 -msgid "Tutorials" -msgstr "" - -#: ../source/contribute.rst:40 -msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." -msgstr "" - -#: ../source/contribute.rst:47 -#: ../source/guides/index.rst:2 -msgid "Guides" -msgstr "" - -#: ../source/contribute.rst:49 -msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." -msgstr "" - -#: ../source/contribute.rst:56 -#: ../source/discussions/index.rst:2 -msgid "Discussions" -msgstr "" - -#: ../source/contribute.rst:58 -msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." -msgstr "" - -#: ../source/contribute.rst:63 -msgid "Specifications" -msgstr "" - -#: ../source/contribute.rst:65 -msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." -msgstr "" - -#: ../source/contribute.rst:73 -msgid "Building the guide locally" -msgstr "" - -#: ../source/contribute.rst:75 -msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" -msgstr "" - -#: ../source/contribute.rst:79 -msgid "`Nox `_. You can install or upgrade nox using ``pip``::" -msgstr "" - -#: ../source/contribute.rst:84 -msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." -msgstr "" - -#: ../source/contribute.rst:91 -msgid "To build the guide, run the following bash command in the source folder::" -msgstr "" - -#: ../source/contribute.rst:95 -msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." -msgstr "" - -#: ../source/contribute.rst:100 -msgid "You can build the guide and serve it via an HTTP server using the following command::" -msgstr "" - -#: ../source/contribute.rst:105 -msgid "The guide will be browsable via http://localhost:8000." -msgstr "" - -#: ../source/contribute.rst:109 -msgid "Where the guide is deployed" -msgstr "" - -#: ../source/contribute.rst:111 -msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." -msgstr "" - -#: ../source/contribute.rst:117 -msgid "Style guide" -msgstr "" - -#: ../source/contribute.rst:119 -msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." -msgstr "" - -#: ../source/contribute.rst:126 -msgid "Purpose" -msgstr "" - -#: ../source/contribute.rst:128 -msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." -msgstr "" - -#: ../source/contribute.rst:133 -msgid "Scope" -msgstr "" - -#: ../source/contribute.rst:135 -msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." -msgstr "" - -#: ../source/contribute.rst:138 -msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." -msgstr "" - -#: ../source/contribute.rst:146 -msgid "Audience" -msgstr "" - -#: ../source/contribute.rst:148 -msgid "The audience of this guide is anyone who uses Python with packages." -msgstr "" - -#: ../source/contribute.rst:150 -msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." -msgstr "" - -#: ../source/contribute.rst:154 -msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." -msgstr "" - -#: ../source/contribute.rst:160 -msgid "Voice and tone" -msgstr "" - -#: ../source/contribute.rst:162 -msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." -msgstr "" - -#: ../source/contribute.rst:165 -msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." -msgstr "" - -#: ../source/contribute.rst:170 -msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." -msgstr "" - -#: ../source/contribute.rst:177 -msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." -msgstr "" - -#: ../source/contribute.rst:184 -msgid "Conventions and mechanics" -msgstr "" - -#: ../source/contribute.rst:192 -msgid "**Write to the reader**" -msgstr "" - -#: ../source/contribute.rst:187 -msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: To install it, the user runs…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: You can install it by running…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: To install it, run…" -msgstr "" - -#: ../source/contribute.rst:198 -msgid "**State assumptions**" -msgstr "" - -#: ../source/contribute.rst:195 -msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." -msgstr "" - -#: ../source/contribute.rst:203 -msgid "**Cross-reference generously**" -msgstr "" - -#: ../source/contribute.rst:201 -msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." -msgstr "" - -#: ../source/contribute.rst:213 -msgid "**Respect naming practices**" -msgstr "" - -#: ../source/contribute.rst:206 -msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: Pip uses…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: pip uses…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: …hosted on github." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: …hosted on GitHub." -msgstr "" - -#: ../source/contribute.rst:222 -msgid "**Use a gender-neutral style**" -msgstr "" - -#: ../source/contribute.rst:216 -msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: A maintainer uploads the file. Then he…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then they…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then the maintainer…" -msgstr "" - -#: ../source/contribute.rst:234 -msgid "**Headings**" -msgstr "" - -#: ../source/contribute.rst:225 -msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." -msgstr "" - -#: ../source/contribute.rst:230 -msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: Things You Should Know About Python" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: Things you should know about Python" -msgstr "" - -#: ../source/contribute.rst:237 -msgid "**Numbers**" -msgstr "" - -#: ../source/contribute.rst:237 -msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:4 -msgid "Deploying Python applications" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Page Status" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:6 -#: ../source/guides/index-mirrors-and-caches.rst:7 -#: ../source/guides/installing-using-linux-tools.rst:7 -#: ../source/guides/packaging-binary-extensions.rst:7 -#: ../source/guides/supporting-multiple-python-versions.rst:7 -#: ../source/guides/supporting-windows-using-appveyor.rst:5 -msgid "Incomplete" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Last Reviewed" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:7 -msgid "2014-11-11" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:11 -#: ../source/discussions/install-requires-vs-requirements.rst:9 -#: ../source/guides/analyzing-pypi-package-downloads.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:22 -#: ../source/guides/index-mirrors-and-caches.rst:12 -#: ../source/guides/installing-scientific-packages.rst:9 -#: ../source/guides/packaging-binary-extensions.rst:17 -#: ../source/guides/supporting-multiple-python-versions.rst:12 -#: ../source/guides/supporting-windows-using-appveyor.rst:15 -#: ../source/overview.rst:23 -#: ../source/specifications/core-metadata.rst:38 -#: ../source/specifications/direct-url.rst:14 -#: ../source/tutorials/installing-packages.rst:23 -msgid "Contents" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:14 -msgid "Overview" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:18 -msgid "Supporting multiple hardware platforms" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:40 -msgid "OS packaging & installers" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:52 -msgid "Windows" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:61 -msgid "Pynsist" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:63 -msgid "`Pynsist `__ is a tool that bundles Python programs together with the Python-interpreter into a single installer based on NSIS. In most cases, packaging only requires the user to choose a version of the Python-interpreter and declare the dependencies of the program. The tool downloads the specified Python-interpreter for Windows and packages it with all the dependencies in a single Windows-executable installer." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:70 -msgid "The installed program can be started from a shortcut that the installer adds to the start-menu. It uses a Python interpreter installed within its application directory, independent of any other Python installation on the computer." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:74 -msgid "A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in the `documentation `__. The tool is released under the MIT-licence." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:80 -msgid "Application bundles" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:91 -msgid "Configuration management" -msgstr "" - -#: ../source/discussions/index.rst:4 -msgid "**Discussions** are focused on providing comprehensive information about a specific topic. If you're just trying to get stuff done, see :doc:`/guides/index`." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:5 -msgid "install_requires vs requirements files" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:382 -msgid "install_requires" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:14 -msgid "``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that should be used to specify what a project **minimally** needs to run correctly. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:19 -msgid "For example, if the project requires A and B, your ``install_requires`` would be like so:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:29 -msgid "Additionally, it's best practice to indicate any known lower or upper bounds." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:31 -msgid "For example, it may be known, that your project requires at least v1 of 'A', and v2 of 'B', so it would be like so:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:41 -msgid "It may also be known that project A follows semantic versioning, and that v2 of 'A' will indicate a break in compatibility, so it makes sense to not allow v2:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:51 -msgid "It is not considered best practice to use ``install_requires`` to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:56 -msgid "Lastly, it's important to understand that ``install_requires`` is a listing of \"Abstract\" requirements, i.e just names and version restrictions that don't determine where the dependencies will be fulfilled from (i.e. from what index or source). The where (i.e. how they are to be made \"Concrete\") is to be determined at install time using :ref:`pip` options. [1]_" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:64 -#: ../source/tutorials/installing-packages.rst:460 -msgid "Requirements files" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:66 -msgid ":ref:`Requirements Files ` described most simply, are just a list of :ref:`pip:pip install` arguments placed into a file." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:69 -msgid "Whereas ``install_requires`` defines the dependencies for a single project, :ref:`Requirements Files ` are often used to define the requirements for a complete Python environment." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:73 -msgid "Whereas ``install_requires`` requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving :ref:`repeatable installations ` of a complete environment." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:78 -msgid "Whereas ``install_requires`` requirements are \"Abstract\", i.e. not associated with any particular index, requirements files often contain pip options like ``--index-url`` or ``--find-links`` to make requirements \"Concrete\", i.e. associated with a particular index or directory of packages. [1]_" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:84 -msgid "Whereas ``install_requires`` metadata is automatically analyzed by pip during an install, requirements files are not, and only are used when a user specifically installs them using ``python -m pip install -r``." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:90 -msgid "For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad.io/2013/07/setup-vs-requirement/." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:6 -msgid "pip vs easy_install" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:9 -msgid ":ref:`easy_install `, now `deprecated`_, was released in 2004 as part of :ref:`setuptools`. It was notable at the time for installing :term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing dependencies." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:14 -msgid ":ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still largely built on top of :ref:`setuptools` components. It was notable at the time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' packages from :term:`sdists `), and introducing the idea of :ref:`Requirements Files `, which gave users the power to easily replicate environments." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:22 -msgid "Here's a breakdown of the important differences between pip and the deprecated easy_install:" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**pip**" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**easy_install**" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -msgid "Installs from :term:`Wheels `" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Yes" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:30 -#: ../source/discussions/pip-vs-easy-install.rst:32 -#: ../source/discussions/pip-vs-easy-install.rst:35 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:51 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "No" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Uninstall Packages" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Yes (``python -m pip uninstall``)" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Dependency Overrides" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Yes (:ref:`Requirements Files `)" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "List Installed Packages" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:38 -msgid ":pep:`438` Support" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Installation format" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "'Flat' packages with :file:`egg-info` metadata." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Encapsulated Egg format" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:44 -msgid "sys.path modification" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:48 -msgid "Installs from :term:`Eggs `" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "`pylauncher support`_" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "Yes [1]_" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:54 -msgid ":ref:`Multi-version Installs`" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Exclude scripts during install" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "per project index" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Only in virtualenv" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Yes, via setup.cfg" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:68 -msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:5 -msgid "Wheel vs Egg" -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:7 -msgid ":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the use case of needing an install artifact that doesn't require building or compilation, which can be costly in testing and production workflows." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:11 -msgid "The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the :term:`Wheel` format was introduced by :pep:`427` in 2012." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:14 -msgid ":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:17 -msgid "Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:20 -msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:22 -msgid ":term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime installation format (if left zipped), and was designed to be importable." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:26 -msgid ":term:`Wheel` archives do not include .pyc files. Therefore, when the distribution only contains Python files (i.e. no compiled extensions), and is compatible with Python 2 and 3, it's possible for a wheel to be \"universal\", similar to an :term:`sdist `." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:31 -msgid ":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. Egg used ``.egg-info``." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:34 -msgid ":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:38 -msgid ":term:`Wheel` is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:41 -msgid ":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making it easier to convert to other formats." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:47 -msgid "Circumstantially, in some cases, wheels can be used as an importable runtime format, although :pep:`this is not officially supported at this time <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`." -msgstr "" - -#: ../source/glossary.rst:3 -msgid "Glossary" -msgstr "" - -#: ../source/glossary.rst:8 -msgid "Binary Distribution" -msgstr "" - -#: ../source/glossary.rst:11 -msgid "A specific kind of :term:`Built Distribution` that contains compiled extensions." -msgstr "" - -#: ../source/glossary.rst:14 -msgid "Built Distribution" -msgstr "" - -#: ../source/glossary.rst:17 -msgid "A :term:`Distribution ` format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. :term:`Wheel` is such a format, whereas distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (:term:`Wheel` intentionally does not include compiled Python files)." -msgstr "" - -#: ../source/glossary.rst:26 -msgid "Distribution Package" -msgstr "" - -#: ../source/glossary.rst:29 -msgid "A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used to distribute a :term:`Release`. The archive file is what an end-user will download from the internet and install." -msgstr "" - -#: ../source/glossary.rst:34 -msgid "A distribution package is more commonly referred to with the single words \"package\" or \"distribution\", but this guide may use the expanded term when more clarity is needed to prevent confusion with an :term:`Import Package` (which is also commonly called a \"package\") or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term \"distribution\"." -msgstr "" - -#: ../source/glossary.rst:41 -msgid "Egg" -msgstr "" - -#: ../source/glossary.rst:44 -msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" -msgstr "" - -#: ../source/glossary.rst:49 -msgid "Extension Module" -msgstr "" - -#: ../source/glossary.rst:52 -msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." -msgstr "" - -#: ../source/glossary.rst:59 -msgid "Known Good Set (KGS)" -msgstr "" - -#: ../source/glossary.rst:62 -msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." -msgstr "" - -#: ../source/glossary.rst:68 -msgid "Import Package" -msgstr "" - -#: ../source/glossary.rst:71 -msgid "A Python module which can contain other modules or recursively, other packages." -msgstr "" - -#: ../source/glossary.rst:74 -msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." -msgstr "" - -#: ../source/glossary.rst:78 -msgid "Module" -msgstr "" - -#: ../source/glossary.rst:81 -msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." -msgstr "" - -#: ../source/glossary.rst:84 -msgid "Package Index" -msgstr "" - -#: ../source/glossary.rst:87 -msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." -msgstr "" - -#: ../source/glossary.rst:90 -msgid "Per Project Index" -msgstr "" - -#: ../source/glossary.rst:93 -msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." -msgstr "" - -#: ../source/glossary.rst:97 -msgid "Project" -msgstr "" - -#: ../source/glossary.rst:100 -msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." -msgstr "" - -#: ../source/glossary.rst:104 -msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." -msgstr "" - -#: ../source/glossary.rst:110 -msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." -msgstr "" - -#: ../source/glossary.rst:115 -msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." -msgstr "" - -#: ../source/glossary.rst:121 -msgid "Pure Module" -msgstr "" - -#: ../source/glossary.rst:124 -msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." -msgstr "" - -#: ../source/glossary.rst:127 -msgid "Python Packaging Authority (PyPA)" -msgstr "" - -#: ../source/glossary.rst:130 -msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." -msgstr "" - -#: ../source/glossary.rst:139 -msgid "Python Package Index (PyPI)" -msgstr "" - -#: ../source/glossary.rst:142 -msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." -msgstr "" - -#: ../source/glossary.rst:145 -msgid "pypi.org" -msgstr "" - -#: ../source/glossary.rst:148 -msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." -msgstr "" - -#: ../source/glossary.rst:152 -msgid "pyproject.toml" -msgstr "" - -#: ../source/glossary.rst:155 -msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." -msgstr "" - -#: ../source/glossary.rst:157 -msgid "Release" -msgstr "" - -#: ../source/glossary.rst:160 -msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." -msgstr "" - -#: ../source/glossary.rst:163 -msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." -msgstr "" - -#: ../source/glossary.rst:168 -msgid "Requirement" -msgstr "" - -#: ../source/glossary.rst:171 -msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." -msgstr "" - -#: ../source/glossary.rst:177 -msgid "Requirement Specifier" -msgstr "" - -#: ../source/glossary.rst:180 -msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" -msgstr "" - -#: ../source/glossary.rst:187 -msgid "Requirements File" -msgstr "" - -#: ../source/glossary.rst:190 -msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." -msgstr "" - -#: ../source/glossary.rst:194 -#: ../source/guides/distributing-packages-using-setuptools.rst:56 -msgid "setup.py" -msgstr "" - -#: ../source/glossary.rst:195 -#: ../source/guides/distributing-packages-using-setuptools.rst:77 -msgid "setup.cfg" -msgstr "" - -#: ../source/glossary.rst:198 -msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." -msgstr "" - -#: ../source/glossary.rst:201 -msgid "Source Archive" -msgstr "" - -#: ../source/glossary.rst:204 -msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:208 -msgid "Source Distribution (or \"sdist\")" -msgstr "" - -#: ../source/glossary.rst:211 -msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:216 -msgid "System Package" -msgstr "" - -#: ../source/glossary.rst:219 -msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." -msgstr "" - -#: ../source/glossary.rst:222 -msgid "Version Specifier" -msgstr "" - -#: ../source/glossary.rst:225 -msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." -msgstr "" - -#: ../source/glossary.rst:231 -msgid "Virtual Environment" -msgstr "" - -#: ../source/glossary.rst:234 -msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/glossary.rst:238 -msgid "Wheel" -msgstr "" - -#: ../source/glossary.rst:241 -msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." -msgstr "" - -#: ../source/glossary.rst:244 -msgid "Working Set" -msgstr "" - -#: ../source/glossary.rst:247 -msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:3 -msgid "Analyzing PyPI package downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:5 -msgid "This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:15 -#: ../source/guides/supporting-windows-using-appveyor.rst:18 -msgid "Background" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:17 -msgid "PyPI does not display download statistics for a number of reasons: [#]_" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:19 -msgid "**Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:24 -msgid "**Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:27 -msgid "``pip``'s download cache (lowers download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:28 -msgid "Internal or unofficial mirrors (can both raise or lower download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:29 -msgid "Packages not hosted on PyPI (for comparisons sake)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:30 -msgid "Unofficial scripts or attempts at download count inflation (raises download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:32 -msgid "Known historical data quality issues (lowers download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:34 -msgid "**Not particularly useful:** Just because a project has been downloaded a lot doesn't mean it's good; Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad!" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:38 -msgid "In short, because it's value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:43 -msgid "Public dataset" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:45 -msgid "As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:50 -msgid "Getting set up" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:52 -msgid "In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run the up to 1TB of queries per month `using the BigQuery free tier without a credit card `__" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:58 -msgid "Navigate to the `BigQuery web UI`_." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:59 -msgid "Create a new project." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:60 -msgid "Enable the `BigQuery API `__." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:63 -msgid "For more detailed instructions on how to get started with BigQuery, check out the `BigQuery quickstart guide `__." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:69 -msgid "Data schema" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:71 -msgid "Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the `table schema `__ include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -msgid "Column" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/guides/using-manifest-in.rst:67 -#: ../source/specifications/core-metadata.rst:185 -msgid "Description" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/specifications/direct-url.rst:226 -msgid "Examples" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "timestamp" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "Date and time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "``2020-03-09 00:33:03 UTC``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "file.project" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "Project name" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "``pipenv``, ``nose``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "file.version" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "Package version" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "``0.1.6``, ``1.4.2``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "details.installer.name" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "Installer" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "pip, `bandersnatch`_" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "details.python" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "Python version" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "``2.7.12``, ``3.6.4``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:93 -msgid "Useful queries" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:95 -msgid "Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" button." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:97 -msgid "Note that the rows are stored in a partitioned, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:102 -msgid "Counting package downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:104 -msgid "The following query counts the total number of downloads for the project \"pytest\"." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:119 -#: ../source/guides/analyzing-pypi-package-downloads.rst:140 -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "num_downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:121 -msgid "26190085" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:124 -msgid "To only count downloads from pip, filter on the ``details.installer.name`` column." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:142 -msgid "24334215" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:146 -msgid "Package downloads over time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:148 -msgid "To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also filtering by this column reduces corresponding costs." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -msgid "month" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "1956741" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "2018-01-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2344692" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2017-12-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "1730398" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "2017-11-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2047310" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2017-10-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "1744443" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "2017-09-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "1916952" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "2017-08-01" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:184 -msgid "Python versions over time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:186 -msgid "Extract the Python version from the ``details.python`` column. Warning: This query processes over 500 GB of data." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "python" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "3.7" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "18051328726" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "3.6" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "9635067203" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "3.8" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "7781904681" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "2.7" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "6381252241" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "null" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "2026630299" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "3.5" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "1894153540" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:221 -msgid "Caveats" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:223 -msgid "In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:231 -msgid "Additional tools" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:233 -msgid "Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:237 -msgid "``google-cloud-bigquery``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:239 -msgid "You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the `google-cloud-bigquery`_ project, the official Python client library for BigQuery." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:267 -msgid "``pypinfo``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:269 -msgid "`pypinfo`_ is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command ``pypinfo package_name``." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:273 -msgid "Install `pypinfo`_ using pip." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:279 -msgid "Usage:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:295 -msgid "``pandas-gbq``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:297 -msgid "The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:301 -#: ../source/specifications/binary-distribution-format.rst:459 -msgid "References" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:303 -msgid "`PyPI Download Counts deprecation email `__" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:304 -msgid "`PyPI BigQuery dataset announcement email `__" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:3 -msgid "Creating and discovering plugins" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:5 -msgid "Often when creating a Python application or library you'll want the ability to provide customizations or extra features via **plugins**. Because Python packages can be separately distributed, your application or library may want to automatically **discover** all of the plugins available." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:10 -msgid "There are three major approaches to doing automatic plugin discovery:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:12 -msgid "`Using naming convention`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:13 -msgid "`Using namespace packages`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:14 -msgid "`Using package metadata`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:18 -msgid "Using naming convention" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:20 -msgid "If all of the plugins for your application follow the same naming convention, you can use :func:`pkgutil.iter_modules` to discover all of the top-level modules that match the naming convention. For example, `Flask`_ uses the naming convention ``flask_{plugin_name}``. If you wanted to automatically discover all of the Flask plugins installed:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:38 -msgid "If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed then ``discovered_plugins`` would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:48 -msgid "Using naming convention for plugins also allows you to query the Python Package Index's `simple API`_ for all packages that conform to your naming convention." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:59 -msgid "Using namespace packages" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:61 -msgid ":doc:`Namespace packages ` can be used to provide a convention for where to place plugins and also provides a way to perform discovery. For example, if you make the sub-package ``myapp.plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once installed, you can use :func:`pkgutil.iter_modules` to discover all modules and packages installed under that namespace:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:89 -msgid "Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` causes it to only look for the modules directly under that namespace. For example, if you have installed distributions that provide the modules ``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in this case would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:101 -msgid "This sample uses a sub-package as the namespace package (``myapp.plugins``), but it's also possible to use a top-level package for this purpose (such as ``myapp_plugins``). How to pick the namespace to use is a matter of preference, but it's not recommended to make your project's main top-level package (``myapp`` in this case) a namespace package for the purpose of plugins, as one bad plugin could cause the entire namespace to break which would in turn make your project unimportable. For the \"namespace sub-package\" approach to work, the plugin packages must omit the :file:`__init__.py` for your top-level package directory (``myapp`` in this case) and include the namespace-package style :file:`__init__.py` in the namespace sub-package directory (``myapp/plugins``). This also means that plugins will need to explicitly pass a list of packages to :func:`setup`'s ``packages`` argument instead of using :func:`setuptools.find_packages`." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:115 -msgid "Namespace packages are a complex feature and there are several different ways to create them. It's highly recommended to read the :doc:`packaging-namespace-packages` documentation and clearly document which approach is preferred for plugins to your project." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:121 -msgid "Using package metadata" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:123 -msgid "`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:128 -msgid "For example if you have a package named ``myapp-plugin-a`` and it includes in its :file:`setup.py`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:139 -msgid "Then you can discover and load all of the registered entry points by using :func:`importlib.metadata.entry_points` (or the `backport`_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9):" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:154 -msgid "In this example, ``discovered_plugins`` would be a collection of type :class:`importlib.metadata.EntryPoint`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:163 -msgid "Now the module of your choice can be imported by executing ``discovered_plugins['a'].load()``." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:166 -msgid "The ``entry_point`` specification in :file:`setup.py` is fairly flexible and has a lot of options. It's recommended to read over the entire section on :doc:`entry points ` ." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:170 -msgid "Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools provide support for defining entry points." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:5 -msgid "Packaging and distributing projects" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:7 -msgid "This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the :doc:`/tutorials/installing-packages` page." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:11 -msgid "The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:15 -msgid "For more reference material, see :std:doc:`Building and Distributing Packages ` in the :ref:`setuptools` docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:25 -msgid "Requirements for packaging and distributing" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:26 -msgid "First, make sure you have already fulfilled the :ref:`requirements for installing packages `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:29 -msgid "Install \"twine\" [1]_:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:43 -msgid "You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below `)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:49 -msgid "Configuring your project" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:53 -msgid "Initial files" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:58 -msgid "The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py `_ in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:63 -msgid ":file:`setup.py` serves two primary functions:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:65 -msgid "It's the file where various aspects of your project are configured. The primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined. The most relevant arguments are explained in :ref:`the section below `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:71 -msgid "It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run ``python setup.py --help-commands``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:79 -msgid ":file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:86 -msgid "README.rst / README.md" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:88 -msgid "All projects should contain a readme file that covers the goal of the project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:`long_description_content_type ` argument)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:95 -msgid "For an example, see `README.md `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:99 -msgid "Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:`README.rst`, :file:`README.txt`, or :file:`README`) included in source distributions by default. The built-in :ref:`distutils` library adopts this behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ will include a :file:`README.md` if found. If you are using setuptools, you don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, include it to be explicit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:108 -msgid "MANIFEST.in" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:110 -msgid "A :file:`MANIFEST.in` is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a :file:`MANIFEST.in` file, including a list of what's included by default, see \":ref:`Using MANIFEST.in`\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:115 -msgid "For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:119 -msgid ":file:`MANIFEST.in` does not affect binary distributions such as wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:122 -msgid "LICENSE.txt" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:124 -msgid "Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you're unsure which license to choose, you can use resources such as `GitHub's Choose a License `_ or consult a lawyer." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:130 -msgid "For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:135 -msgid "" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:137 -msgid "Although it's not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same :ref:`name ` as your project, or something very close." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:141 -msgid "For an example, see the `sample `_ package that's included in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:149 -msgid "setup() args" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:151 -msgid "As mentioned above, the primary feature of :file:`setup.py` is that it contains a global ``setup()`` function. The keyword arguments to this function are how specific details of your project are defined." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:155 -msgid "The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py `_ contained in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:164 -msgid "name" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:170 -msgid "This is the name of your project, determining how your project is listed on :term:`PyPI `. Per :pep:`508`, valid project names must:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:174 -msgid "Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), and/or periods (``.``), and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:176 -msgid "Start & end with an ASCII letter or digit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:178 -msgid "Comparison of project names is case insensitive and treats arbitrarily-long runs of underscores, hyphens, and/or periods as equal. For example, if you register a project named ``cool-stuff``, users will be able to download it or declare a dependency on it using any of the following spellings::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:190 -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "version" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:196 -msgid "This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they've tested their own software against." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:200 -msgid "Versions are displayed on :term:`PyPI ` for each release if you publish your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:203 -msgid "See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey compatibility information to your users." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:206 -msgid "If the project code itself needs run-time access to the version, the simplest way is to keep the version in both :file:`setup.py` and your code. If you'd rather not duplicate the value, there are a few ways to manage this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:214 -msgid "description" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:222 -msgid "Give a short and long description for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:224 -msgid "These values will be displayed on :term:`PyPI ` if you publish your project. On ``pypi.org``, the user interface displays ``description`` in the grey banner and ``long_description`` in the section named \"Project Description\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:229 -msgid "``description`` is also displayed in lists of projects. For example, it's visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:235 -msgid "A `content type `_ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, and the Github-flavored Markdown dialect of `Markdown `_ respectively." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:245 -msgid "url" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:252 -msgid "Give a homepage URL for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:256 -msgid "author" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:263 -msgid "Provide details about the author." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:267 -msgid "license" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:273 -msgid "The ``license`` argument doesn't have to indicate the license under which your package is being released, although you may optionally do so if you want. If you're using a standard, well-known license, then your main indication can and should be via the ``classifiers`` argument. Classifiers exist for all major open-source licenses." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:279 -msgid "The \"license\" argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it's a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:287 -msgid "classifiers" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:316 -msgid "Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:319 -msgid "Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:327 -msgid "keywords" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:333 -msgid "List keywords that describe your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:337 -msgid "project_urls" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:349 -msgid "List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:355 -msgid "packages" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:361 -msgid "Set ``packages`` to a list of all :term:`packages ` in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, ``setuptools.find_packages()`` finds them automatically. Use the ``include`` keyword argument to find only the given packages. Use the ``exclude`` keyword argument to omit packages that are not intended to be released and installed." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:370 -msgid "py_modules" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:376 -msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:388 -msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:392 -msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requirements files`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:398 -msgid "python_requires" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:400 -msgid "If your project only runs on certain Python versions, setting the ``python_requires`` argument to the appropriate :pep:`440` version specifier string will prevent :ref:`pip` from installing the project on other Python versions. For example, if your package is for Python 3+ only, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:407 -msgid "If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:412 -msgid "And so on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:416 -msgid "Support for this feature is relatively recent. Your project's source distributions and wheels (see :ref:`Packaging Your Project`) must be built using at least version 24.2.0 of :ref:`setuptools` in order for the ``python_requires`` argument to be recognized and the appropriate metadata generated." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:422 -msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ``python_requires`` metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects' ``python_requires`` values." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:431 -msgid "package_data" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:440 -msgid "Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the package’s implementation, or text files containing documentation that might be of interest to programmers using the package. These files are called \"package data\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:445 -msgid "The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:449 -msgid "For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:457 -msgid "data_files" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:463 -msgid "Although configuring :ref:`Package Data` is sufficient for most needs, in some cases you may need to place data files *outside* of your :term:`packages `. The ``data_files`` directive allows you to do that. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:469 -msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:479 -msgid "For more information see the distutils section on `Installing Additional Files `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:484 -msgid "When installing packages as egg, ``data_files`` is not supported. So, if your project uses :ref:`setuptools`, you must use ``pip`` to install it. Alternatively, if you must use ``python setup.py``, then you need to pass the ``--old-and-unmanageable`` option." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:491 -msgid "scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:493 -msgid "Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:500 -msgid "entry_points" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:509 -msgid "Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:512 -msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:516 -msgid "The most commonly used entry point is \"console_scripts\" (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:521 -msgid "console_scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:531 -msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:538 -msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:545 -msgid "Choosing a versioning scheme" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:548 -msgid "Standards compliance for interoperability" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:550 -msgid "Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible :pep:`public version scheme <440#public-version-identifiers>` specified in :pep:`440` in order to be supported in tools and libraries like ``pip`` and ``setuptools``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:556 -msgid "Here are some examples of compliant version numbers::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:567 -msgid "To further accommodate historical variations in approaches to version numbering, :pep:`440` also defines a comprehensive technique for :pep:`version normalisation <440#normalization>` that maps variant spellings of different version numbers to a standardised canonical form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:573 -msgid "Scheme choices" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:576 -msgid "Semantic versioning (preferred)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:578 -msgid "For new projects, the recommended versioning scheme is based on `Semantic Versioning `_, but adopts a different approach to handling pre-releases and build metadata." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:582 -msgid "The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:585 -msgid "MAJOR version when they make incompatible API changes," -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:586 -msgid "MINOR version when they add functionality in a backwards-compatible manner, and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:587 -msgid "MAINTENANCE version when they make backwards-compatible bug fixes." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:589 -msgid "Adopting this approach as a project author allows users to make use of :pep:`\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= X.Y`` requires at least release X.Y, but also allows any later release with a matching MAJOR version." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:594 -msgid "Python projects adopting semantic versioning should abide by clauses 1-8 of the `Semantic Versioning 2.0.0 specification `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:598 -msgid "Date based versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:600 -msgid "Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:604 -msgid "A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:607 -msgid "Version numbers for date based projects typically take the form of YEAR.MONTH (for example, ``12.04``, ``15.10``)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:611 -msgid "Serial versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:613 -msgid "This is the simplest possible versioning scheme, and consists of a single number which is incremented every release." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:616 -msgid "While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:621 -msgid "Hybrid schemes" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:623 -msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:629 -msgid "Pre-release versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:631 -msgid "Regardless of the base versioning scheme, pre-releases for a given final release may be published as:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:634 -msgid "zero or more dev releases (denoted with a \".devN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:635 -msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:636 -msgid "zero or more beta releases (denoted with a \".bN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:637 -msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:639 -msgid "``pip`` and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:644 -msgid "Local version identifiers" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:646 -msgid "Public version identifiers are designed to support distribution via :term:`PyPI `. Python's software distribution tools also support the notion of a :pep:`local version identifier <440#local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:653 -msgid "A local version identifier takes the form ``+``. For example::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:661 -msgid "Working in \"development mode\"" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:663 -msgid "Although not required, it's common to locally install your project in \"editable\" or \"develop\" mode while you're working on it. This allows your project to be both installed and editable in project form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:667 -msgid "Assuming you're in the root of your project directory, then run:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:674 -msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:680 -msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:688 -msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:692 -msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:697 -msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:701 -msgid "Lastly, if you don't want to install any dependencies at all, you can run::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:706 -msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:713 -msgid "Packaging your project" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:715 -msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:720 -msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:737 -msgid "Source distributions" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:739 -msgid "Minimally, you should create a :term:`Source Distribution `:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:755 -msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:763 -msgid "Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:765 -msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:770 -msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:773 -msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:776 -msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:785 -msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:792 -msgid "Pure Python Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:794 -msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:797 -#: ../source/guides/distributing-packages-using-setuptools.rst:826 -msgid "To build the wheel:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:811 -msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:815 -msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:821 -msgid "Platform Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:823 -msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:841 -msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:847 -msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:855 -msgid "Uploading your Project to PyPI" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:857 -msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:861 -msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:866 -msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:871 -msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:877 -msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:888 -msgid "Create an account" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:890 -msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:894 -msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:897 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:901 -msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:904 -msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:913 -msgid "**Be aware that this stores your token in plaintext.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:915 -#: ../source/guides/migrating-to-pypi-org.rst:70 -#: ../source/guides/migrating-to-pypi-org.rst:109 -#: ../source/guides/using-testpypi.rst:83 -msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:921 -msgid "Upload your distributions" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:923 -msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:926 -msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:930 -msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:937 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:944 -#: ../source/tutorials/installing-packages.rst:663 -msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:950 -msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:5 -msgid "Dropping support for older Python versions" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:7 -msgid "Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:9 -msgid "Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:12 -msgid "This mechanism can be used to drop support for older Python versions, by amending the \"Requires-Python\" attribute in the package metadata." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:14 -msgid "This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:17 -msgid "Requirements" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:19 -msgid "This workflow requires that:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:21 -msgid "The publisher is using the latest version of :ref:`setuptools`," -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:22 -msgid "The latest version of :ref:`twine` is used to upload the package," -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:23 -msgid "The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:26 -msgid "Dealing with the universal wheels" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:28 -msgid "Traditionally, projects providing Python code that is semantically compatible with both Python 2 and Python 3, produce :term:`wheels ` that have a ``py2.py3`` tag in their names. When dropping support for Python 2, it is important not to forget to change this tag to just ``py3``. It is often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` section by setting ``universal = 1`` if they use setuptools." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:36 -msgid "If you use this method, either remove this option or section, or explicitly set ``universal`` to ``0``:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:48 -msgid "Since it is possible to override the :file:`setup.cfg` settings via CLI flags, make sure that your scripts don't have ``--universal`` in your package creation scripts." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:53 -msgid "Defining the Python version required" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:56 -msgid "1. Download the newest version of Setuptools" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:58 -msgid "Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:60 -msgid "Steps:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:74 -msgid "`setuptools` version should be above 24.0.0." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:77 -msgid "2. Specify the version ranges for supported Python distributions" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:79 -msgid "You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:81 -#: ../source/specifications/core-metadata.rst:139 -#: ../source/specifications/core-metadata.rst:463 -#: ../source/specifications/core-metadata.rst:487 -#: ../source/specifications/core-metadata.rst:527 -#: ../source/specifications/core-metadata.rst:550 -#: ../source/specifications/core-metadata.rst:583 -#: ../source/specifications/core-metadata.rst:693 -#: ../source/specifications/core-metadata.rst:722 -msgid "Examples::" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:86 -msgid "The way to set those values is within the call to ``setup`` within your :file:`setup.py` script. This will insert the ``Requires-Python`` metadata values based on the argument you provide in ``python_requires``." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:101 -msgid "3. Validating the Metadata before publishing" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:103 -msgid "Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:105 -msgid "This file is generated by Distutils or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:108 -msgid "You can see the contents of the generated file like this::" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:112 -msgid "Validate that the following is in place, before publishing the package:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:114 -msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:115 -msgid "The Requires-Python field is set and matches your specification in setup.py." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:118 -msgid "4. Using Twine to publish" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:120 -msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:122 -msgid "Make sure you are using the newest version of Twine, at least 1.9." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:125 -msgid "Dropping a Python release" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:127 -msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:129 -msgid "It must be done in this order for the automated fallback to work." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:131 -msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:133 -msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:5 -msgid "Hosting your own simple repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:8 -msgid "If you wish to host your own simple repository [1]_, you can either use a software package like `devpi`_ or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:13 -msgid "In either case, since you'll be hosting a repository that is likely not in your user's default repositories, you should instruct them in your project's description to configure their installer appropriately. For example with pip:" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:29 -msgid "In addition, it is **highly** recommended that you serve your repository with valid HTTPS. At this time, the security of your user's installations depends on all repositories using a valid HTTPS setup." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:35 -msgid "\"Manual\" repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:37 -msgid "The directory layout is fairly simple, within a root directory you need to create a directory for each project. This directory should be the normalized name (as defined by :pep:`503`) of the project. Within each of these directories simply place each of the downloadable files. If you have the projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the version 0.1) You should end up with a structure that looks like::" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:51 -msgid "Once you have this layout, simply configure your webserver to serve the root directory with autoindex enabled. For an example using the built in Web server in `Twisted`_, you would simply run ``twistd -n web --path .`` and then instruct users to add the URL to their installer's configuration." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:58 -msgid "For complete documentation of the simple repository protocol, see :pep:`503`." -msgstr "" - -#: ../source/guides/index.rst:8 -#: ../source/guides/index.rst:8 -msgid "Installing Packages:" -msgstr "" - -#: ../source/guides/index.rst:20 -#: ../source/guides/index.rst:20 -msgid "Building and Publishing Projects:" -msgstr "" - -#: ../source/guides/index.rst:38 -#: ../source/guides/index.rst:38 -msgid "Miscellaneous:" -msgstr "" - -#: ../source/guides/index.rst:4 -msgid "**Guides** are focused on accomplishing a specific task and assume that you are already familiar with the basics of Python packaging. If you're looking for an introduction to packaging, see :doc:`/tutorials/index`." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:5 -msgid "Package index mirrors and caches" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:8 -#: ../source/guides/supporting-multiple-python-versions.rst:8 -msgid "2014-12-24" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:14 -msgid "Mirroring or caching of PyPI can be used to speed up local package installation, allow offline work, handle corporate firewalls or just plain Internet flakiness." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:17 -msgid "Three options are available in this area:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:19 -msgid "pip provides local caching options," -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:20 -msgid "devpi provides higher-level caching option, potentially shared amongst many users or machines, and" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:22 -msgid "bandersnatch provides a local complete mirror of all PyPI :term:`packages `." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:27 -msgid "Caching with pip" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:29 -msgid "pip provides a number of facilities for speeding up installation by using local cached copies of :term:`packages `:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:32 -msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:36 -msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:45 -msgid "Caching with devpi" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:47 -msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:55 -msgid "Complete mirror with bandersnatch" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:57 -msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:63 -msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:5 -msgid "Installing scientific packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:11 -msgid "Scientific software tends to have more complex dependencies than most, and it will often have multiple build options to take advantage of different kinds of hardware, or to interoperate with different pieces of external software." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:16 -msgid "In particular, `NumPy `__, which provides the basis for most of the software in the `scientific Python stack `__ can be configured to interoperate with different FORTRAN libraries, and can take advantage of different levels of vectorised instructions available in modern CPUs." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:22 -msgid "Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built 32-bit and 64-bit binaries in the ``wheel`` format are available for all major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, so they may not provide optimal linear algebra performance." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:29 -msgid "There are a number of alternative options for obtaining scientific Python libraries (or any other Python libraries that require a compilation environment to install from source and don't provide pre-built wheel files on PyPI)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:35 -msgid "Building from source" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:37 -msgid "The same complexity which makes it difficult to distribute NumPy (and many of the projects that depend on it) as wheel files also make them difficult to build from source yourself. However, for intrepid folks that are willing to spend the time wrangling compilers and linkers for both C and FORTRAN, building from source is always an option." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:45 -msgid "Linux distribution packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:47 -msgid "For Linux users, the system package manager will often have pre-compiled versions of various pieces of scientific software, including NumPy and other parts of the scientific Python stack." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:51 -msgid "If using versions which may be several months old is acceptable, then this is likely to be a good option (just make sure to allow access to distributions installed into the system Python when using virtual environments)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:57 -msgid "Windows installers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:59 -msgid "Many Python projects that don't (or can't) currently publish wheel files at least publish Windows installers, either on PyPI or on their project download page. Using these installers allows users to avoid the need to set up a suitable environment to build extensions locally." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:64 -msgid "The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:67 -msgid "For projects which don't provide their own Windows installers (and even some which do), Christoph Gohlke at the University of California provides a `collection of Windows installers `__. Many Python users on Windows have reported a positive experience with these prebuilt versions." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:73 -msgid "As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python when using virtual environments is a common approach to working around this limitation." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:79 -msgid "The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can convert a Windows :command:`bdist_wininst` installer to a wheel." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:86 -msgid "macOS installers and package managers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:88 -msgid "Similar to the situation on Windows, many projects (including NumPy) publish macOS installers that are compatible with the macOS CPython binaries published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:92 -msgid "macOS users also have access to Linux distribution style package managers such as ``MacPorts``. The SciPy site has more details on using MacPorts to install the `scientific Python stack `__" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:99 -msgid "SciPy distributions" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:101 -msgid "The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use and update format." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:105 -msgid "Some of these distributions may not be compatible with the standard ``pip`` and ``virtualenv`` based toolchain." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:109 -#: ../source/key_projects.rst:596 -msgid "Spack" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:110 -msgid "`Spack `_ is a flexible package manager designed to support multiple versions, configurations, platforms, and compilers. It was built to support the needs of large supercomputing centers and scientific application teams, who must often build software many different ways. Spack is not limited to Python; it can install packages for ``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-destructive; installing a new version of one package does not break existing installations, so many configurations can coexist on the same system." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:119 -msgid "Spack offers a simple but powerful syntax that allows users to specify versions and configuration options concisely. Package files are written in pure Python, and they are templated so that it is easy to swap compilers, dependency implementations (like MPI), versions, and build options with a single package file. Spack also generates *module* files so that packages can be loaded and unloaded from the user's environment." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:128 -msgid "The conda cross-platform package manager" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:130 -msgid "`Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use. As of the 5.0 release of Anaconda, about 200 packages are installed by default, and a total of 400-500 can be installed and updated from the Anaconda repository." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:136 -msgid "``conda`` is an open source (BSD licensed) package management system and environment management system included in Anaconda that allows users to install multiple versions of binary software packages and their dependencies, and easily switch between them. It is a cross-platform tool working on Windows, macOS, and Linux. Conda can be used to package up and distribute all kinds of packages, it is not limited to just Python packages. It has full support for native virtual environments. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. It is written in Python, but is Python-agnostic. Conda manages Python itself as a package, so that :command:`conda update python` is possible, in contrast to pip, which only manages Python packages. Conda is available in Anaconda and Miniconda (an easy-to-install download with just Python and conda)." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 -msgid "Installing stand alone command line tools" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 -msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 -msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 -msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 -msgid "pipx only works with Python 3.6+." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 -msgid "``pipx`` is installed with ``pip``:" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 -msgid "You may need to restart your terminal for the path updates to take effect." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 -msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 -#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 -msgid "For example" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 -msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 -msgid "To upgrade or uninstall the package" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 -msgid "``pipx`` can be upgraded or uninstalled with pip" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 -msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 -msgid "To see the full list of commands ``pipx`` offers, run" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 -msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:5 -msgid "Installing pip/setuptools/wheel with Linux Package Managers" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:8 -msgid "2015-09-17" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:11 -msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:14 -msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:18 -msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:25 -msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:32 -msgid "Fedora" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:34 -msgid "Fedora 21:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:36 -#: ../source/guides/installing-using-linux-tools.rst:45 -#: ../source/guides/installing-using-linux-tools.rst:124 -#: ../source/guides/installing-using-linux-tools.rst:138 -#: ../source/guides/installing-using-linux-tools.rst:158 -msgid "Python 2::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:41 -msgid "Python 3: ``sudo yum install python3 python3-wheel``" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:43 -msgid "Fedora 22:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:50 -msgid "Python 3: ``sudo dnf install python3 python3-wheel``" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:53 -msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:63 -msgid "CentOS/RHEL" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:65 -msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:68 -msgid "To install pip and wheel for the system Python, there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:70 -msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:77 -msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:81 -msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:85 -msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:92 -msgid "To additionally upgrade setuptools, run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:97 -msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:101 -msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:104 -msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:106 -msgid "For CentOS, see here: https://www.softwarecollections.org/en/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:108 -msgid "Be aware that collections may not contain the most recent versions." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:110 -msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:116 -msgid "For example, for Python 3.4 on CentOS7/RHEL7::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:122 -msgid "openSUSE" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:129 -#: ../source/guides/installing-using-linux-tools.rst:143 -#: ../source/guides/installing-using-linux-tools.rst:162 -msgid "Python 3::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:135 -msgid "Debian/Ubuntu" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:150 -msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:156 -msgid "Arch Linux" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:168 -msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 -msgid "Installing packages using pip and virtual environments" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 -msgid "This guide discusses how to install packages using :ref:`pip` and a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` for Python 2. These are the lowest-level tools for managing Python packages and are recommended if higher-level tools do not suit your needs." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 -msgid "This doc uses the term **package** to refer to a :term:`Distribution Package` which is different from an :term:`Import Package` that which is used to import modules in your Python source code." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 -msgid "Installing pip" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 -msgid ":ref:`pip` is the reference Python package manager. It's used to install and update packages. You'll need to make sure you have the latest version of pip installed." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 -msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 -msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 -msgid "Afterwards, you should have the newest pip installed in your user site:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 -msgid "The Python installers for Windows include pip. You should be able to access pip using:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 -msgid "You can make sure that pip is up-to-date by running:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 -msgid "Installing virtualenv" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 -msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 -msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 -msgid "Creating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 -msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 -msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 -msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 -msgid "venv will create a virtual Python installation in the ``env`` folder." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 -msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 -msgid "Activating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 -msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 -msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 -msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 -msgid "Leaving the virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 -msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 -msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 -msgid "Installing packages" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 -msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 -msgid "pip should download requests and all of its dependencies and install them:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 -msgid "Installing specific versions" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 -msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 -msgid "To install the latest ``2.x`` release of requests:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 -msgid "To install pre-release versions of packages, use the ``--pre`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 -msgid "Installing extras" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 -msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 -msgid "Installing from source" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 -msgid "pip can install a package directly from source, for example:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 -msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 -msgid "Installing from version control systems" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 -msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 -msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 -#: ../source/tutorials/installing-packages.rst:569 -msgid "Installing from local archives" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 -msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 -msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 -msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 -msgid "Using other package indexes" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 -msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 -msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 -#: ../source/tutorials/installing-packages.rst:389 -msgid "Upgrading packages" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 -msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 -msgid "Using requirements files" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 -msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 -msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 -msgid "Freezing dependencies" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 -msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 -msgid "Which will output a list of package specifiers such as:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 -msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:2 -msgid "Making a PyPI-friendly README" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:4 -msgid "README files can help your users understand your project and can be used to set your project's description on PyPI. This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:9 -msgid "Creating a README file" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:11 -msgid "README files for Python projects are often named ``README``, ``README.txt``, ``README.rst``, or ``README.md``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:13 -msgid "For your README to display properly on PyPI, choose a markup language supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:16 -msgid "plain text" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:17 -msgid "`reStructuredText `_ (without Sphinx extensions)" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:18 -msgid "Markdown (`GitHub Flavored Markdown `_ by default, or `CommonMark `_)" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:21 -msgid "It's customary to save your README file in the root of your project, in the same directory as your :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:25 -msgid "Including your README in your package's metadata" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:27 -msgid "To include your README's contents as your package description, set your project's ``Description`` and ``Description-Content-Type`` metadata, typically in your project's :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:33 -msgid ":ref:`description-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:34 -msgid ":ref:`description-content-type-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:36 -msgid "For example, to set these values in a package's :file:`setup.py` file, use ``setup()``'s ``long_description`` and ``long_description_content_type``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:39 -msgid "Set the value of ``long_description`` to the contents (not the path) of the README file itself. Set the ``long_description_content_type`` to an accepted ``Content-Type``-style value for your README file's markup, such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:45 -msgid "If you're using GitHub-flavored Markdown to write a project's description, ensure you upgrade the following tools:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:60 -msgid "The minimum required versions of the respective tools are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:62 -msgid "``setuptools >= 38.6.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:63 -msgid "``wheel >= 0.31.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:64 -msgid "``twine >= 1.11.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:66 -msgid "It's recommended that you use ``twine`` to upload the project's distribution packages:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:72 -msgid "For example, see this :file:`setup.py` file, which reads the contents of :file:`README.md` as ``long_description`` and identifies the markup as GitHub-flavored Markdown:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:95 -msgid "Validating reStructuredText markup" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:97 -msgid "If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:100 -msgid "Note that Sphinx extensions used in docstrings, such as `directives and roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```\"), are not allowed here and will result in error messages like \"``Error: Unknown interpreted text role \"py:func\".``\"." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:105 -msgid "You can check your README for markup errors before uploading as follows:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:107 -msgid "Install the latest version of `twine `_; version 1.12.0 or higher is required:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:122 -msgid "Build the sdist and wheel for your project as described under :ref:`Packaging Your Project`." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:125 -msgid "Run ``twine check`` on the sdist and wheel::" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:129 -msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:4 -msgid "Migrating to PyPI.org" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:6 -msgid ":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``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:12 -msgid "Publishing releases" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:14 -msgid "``pypi.org`` is the default upload platform as of September 2016." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:16 -msgid "Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:19 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:22 -msgid "The default upload settings switched to ``pypi.org`` in the following versions:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:24 -msgid "``twine`` 1.8.0" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:25 -msgid "``setuptools`` 27.0.0" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:26 -msgid "Python 2.7.13 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:27 -msgid "Python 3.4.6 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:28 -msgid "Python 3.5.3 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:29 -msgid "Python 3.6.0 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:31 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:48 -msgid "Then simply delete the line starting with ``repository`` and you will use your upload tool's default URL." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:51 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:67 -msgid "(``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.)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:73 -msgid "Registering package names & metadata" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:75 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:79 -msgid "As a result, attempting explicit registration after switching to using PyPI.org for uploads will give the following error message::" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:84 -msgid "The solution is to skip the registration step, and proceed directly to uploading artifacts." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:89 -#: ../source/guides/using-testpypi.rst:5 -msgid "Using TestPyPI" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:91 -msgid "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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:113 -msgid "Registering new user accounts" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:115 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:121 -msgid "Browsing packages" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:123 -msgid "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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:130 -msgid "Downloading packages" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:132 -msgid "``pypi.org`` is the default host for downloading packages." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:135 -msgid "Managing published packages and releases" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:137 -msgid "``pypi.org`` provides a fully functional interface for logged in users to manage their published packages and releases." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:5 -msgid "Multi-version installs" -msgstr "" - -#: ../source/guides/multi-version-installs.rst:8 -msgid "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``)." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:13 -msgid "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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:19 -msgid "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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:31 -msgid "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 ``python -c ''`` to invoke the application's main entry point directly." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:38 -msgid "Refer to the `pkg_resources documentation `__ for more details." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:5 -msgid "Packaging binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:8 -msgid "2013-12-08" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:10 -msgid "One of the features of the CPython reference interpreter is that, in addition to allowing the execution of Python code, it also exposes a rich C API for use by other software. One of the most common uses of this C API is to create importable C extensions that allow things which aren't always easy to achieve in pure Python code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:20 -msgid "An overview of binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:23 -msgid "Use cases" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:25 -msgid "The typical use cases for binary extensions break down into just three conventional categories:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:28 -msgid "**accelerator modules**: these modules are completely self-contained, and are created solely to run faster than the equivalent pure Python code runs in CPython. Ideally, accelerator modules will always have a pure Python equivalent to use as a fallback if the accelerated version isn't available on a given system. The CPython standard library makes extensive use of accelerator modules. *Example*: When importing ``datetime``, Python falls back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not available." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:39 -msgid "**wrapper modules**: these modules are created to expose existing C interfaces to Python code. They may either expose the underlying C interface directly, or else expose a more \"Pythonic\" API that makes use of Python language features to make the API easier to use. The CPython standard library makes extensive use of wrapper modules. *Example*: `functools.py `_ is a Python module wrapper for `_functoolsmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:47 -msgid "**low-level system access**: these modules are created to access lower level features of the CPython runtime, the operating system, or the underlying hardware. Through platform specific code, extension modules may achieve things that aren't possible in pure Python code. A number of CPython standard library modules are written in C in order to access interpreter internals that aren't exposed at the language level. *Example*: ``sys``, which comes from `sysmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:56 -msgid "One particularly notable feature of C extensions is that, when they don't need to call back into the interpreter runtime, they can release CPython's global interpreter lock around long-running operations (regardless of whether those operations are CPU or IO bound)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:61 -msgid "Not all extension modules will fit neatly into the above categories. The extension modules included with NumPy, for example, span all three use cases - they move inner loops to C for speed reasons, wrap external libraries written in C, FORTRAN and other languages, and use low level system interfaces for both CPython and the underlying operation system to support concurrent execution of vectorised operations and to tightly control the exact memory layout of created objects." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:71 -msgid "Disadvantages" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:73 -msgid "The main disadvantage of using binary extensions is the fact that it makes subsequent distribution of the software more difficult. One of the advantages of using Python is that it is largely cross platform, and the languages used to write extension modules (typically C or C++, but really any language that can bind to the CPython C API) typically require that custom binaries be created for different platforms." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:80 -msgid "This means that binary extensions:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:82 -msgid "require that end users be able to either build them from source, or else that someone publish pre-built binaries for common platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:85 -msgid "may not be compatible with different builds of the CPython reference interpreter" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:88 -msgid "often will not work correctly with alternative interpreters such as PyPy, IronPython or Jython" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:91 -msgid "if handcoded, make maintenance more difficult by requiring that maintainers be familiar not only with Python, but also with the language used to create the binary extension, as well as with the details of the CPython C API." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:96 -msgid "if a pure Python fallback implementation is provided, make maintenance more difficult by requiring that changes be implemented in two places, and introducing additional complexity in the test suite to ensure both versions are always executed." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:101 -msgid "Another disadvantage of relying on binary extensions is that alternative import mechanisms (such as the ability to import modules directly from zipfiles) often won't work for extension modules (as the dynamic loading mechanisms on most platforms can only load libraries from disk)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:108 -msgid "Alternatives to handcoded accelerator modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:110 -msgid "When extension modules are just being used to make code run faster (after profiling has identified the code where the speed increase is worth additional maintenance effort), a number of other alternatives should also be considered:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:115 -msgid "look for existing optimised alternatives. The CPython standard library includes a number of optimised data structures and algorithms (especially in the builtins and the ``collections`` and ``itertools`` modules). The Python Package Index also offers additional alternatives. Sometimes, the appropriate choice of standard library or third party module can avoid the need to create your own accelerator module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:122 -msgid "for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython runtime. The main barrier to adopting PyPy is typically reliance on other binary extension modules - while PyPy does emulate the CPython C API, modules that rely on that cause problems for the PyPy JIT, and the emulation layer can often expose latent defects in extension modules that CPython currently tolerates (frequently around reference counting errors - an object having one live reference instead of two often won't break anything, but no references instead of one is a major problem)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:132 -msgid "`Cython `__ is a mature static compiler that can compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional opportunities for speed increases. Using Cython still has the disadvantage of increasing the complexity of distributing the resulting application, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:141 -msgid "`Numba `__ is a newer tool, created by members of the scientific Python community, that aims to leverage LLVM to allow selective compilation of pieces of a Python application to native machine code at runtime. It requires that LLVM be available on the system where the code is running, but can provide significant speed increases, especially for operations that are amenable to vectorisation." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:150 -msgid "Alternatives to handcoded wrapper modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:152 -msgid "The C ABI (Application Binary Interface) is a common standard for sharing functionality between multiple applications. One of the strengths of the CPython C API (Application Programming Interface) is allowing Python users to tap into that functionality. However, wrapping modules by hand is quite tedious, so a number of other alternative approaches should be considered." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:158 -msgid "The approaches described below don't simplify the distribution case at all, but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:162 -msgid "In addition to being useful for the creation of accelerator modules, `Cython `__ is also useful for creating wrapper modules for C or C++. It still involves wrapping the interfaces by hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:168 -msgid "`pybind11 `__ is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:175 -msgid "`cffi `__ is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its header files, even if you don't know C yourself." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:181 -msgid "One of the key advantages of ``cffi`` is that it is compatible with the PyPy JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing JIT optimisations." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:185 -msgid "`SWIG `__ is a wrapper interface generator that allows a variety of programming languages, including Python, to interface with C and C++ code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:189 -msgid "The standard library's ``ctypes`` module, while useful for getting access to C level interfaces when header information isn't available, suffers from the fact that it operates solely at the C ABI level, and thus has no automatic consistency checking between the interface actually being exported by the library and the one declared in the Python code. By contrast, the above alternatives are all able to operate at the C *API* level, using C header files to ensure consistency between the interface exported by the library being wrapped and the one expected by the Python wrapper module. While ``cffi`` *can* operate directly at the C ABI level, it suffers from the same interface inconsistency problems as ``ctypes`` when it is used that way." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:203 -msgid "Alternatives for low level system access" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:205 -msgid "For applications that need low level system access (regardless of the reason), a binary extension module often *is* the best way to go about it. This is particularly true for low level access to the CPython runtime itself, since some operations (like releasing the Global Interpreter Lock) are simply invalid when the interpreter is running code, even if a module like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API interfaces." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:213 -msgid "For cases where the extension module is manipulating the underlying operating system or hardware (rather than the CPython runtime), it may sometimes be better to just write an ordinary C library (or a library in another systems programming language like C++ or Rust that can export a C compatible ABI), and then use one of the wrapping techniques described above to make the interface available as an importable Python module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:222 -msgid "Implementing binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:224 -msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:241 -msgid "Building binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:244 -msgid "Building extensions for multiple platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:246 -msgid "If you plan to distribute your extension, you should provide :term:`wheels ` for all the platforms you intend to support. For most extensions, this is at least one package per Python version times the number of OS and architectures you support. These are usually built on continuous integration (CI) systems. There are tools to help you build highly redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:`multibuild`." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:256 -msgid "Binary extensions for Windows" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:258 -msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:263 -msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:269 -msgid "To set up a build environment for binary extensions, the steps are as follows:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:271 -msgid "For Python 2.7" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:273 -msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:276 -msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:278 -#: ../source/guides/packaging-binary-extensions.rst:288 -#: ../source/guides/packaging-binary-extensions.rst:295 -msgid "Done." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:280 -msgid "For Python 3.4" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:282 -msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:285 -msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:287 -msgid "Set DISTUTILS_USE_SDK=1" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:290 -msgid "For Python 3.5" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:292 -msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:297 -msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:301 -msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:305 -msgid "Binary extensions for Linux" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:307 -msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:313 -msgid "Binary extensions for macOS" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:315 -msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:325 -msgid "Publishing binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:327 -msgid "For interim guidance on this topic, see the discussion in `this issue `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:343 -msgid "Additional resources" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:345 -msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:352 -msgid "Cross-platform wheel generation with scikit-build" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:354 -msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:362 -msgid "Introduction to C/C++ extension modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:364 -msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:367 -msgid "`What are (c)python extension modules? `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:368 -msgid "`Releasing the gil `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:369 -msgid "`Writing cpython extension modules using C++ `_" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:3 -msgid "Packaging namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:5 -msgid "Namespace packages allow you to split the sub-packages and modules within a single :term:`package ` across multiple, separate :term:`distribution packages ` (referred to as **distributions** in this document to avoid ambiguity). For example, if you have the following package structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:24 -msgid "And you use this package in your code like so::" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:29 -msgid "Then you can break these sub-packages into two separate distributions:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:46 -msgid "Each sub-package can now be separately installed, used, and versioned." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:48 -msgid "Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases. A simple alternative is to use a prefix on all of your distributions such as ``import mynamespace_subpackage_a`` (you could even use ``import mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:58 -msgid "Creating a namespace package" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:60 -msgid "There are currently three different approaches to creating namespace packages:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:62 -msgid "Use `native namespace packages`_. This type of namespace package is defined in :pep:`420` and is available in Python 3.3 and later. This is recommended if packages in your namespace only ever need to support Python 3 and installation via ``pip``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:66 -msgid "Use `pkgutil-style namespace packages`_. This is recommended for new packages that need to support Python 2 and 3 and installation via both ``pip`` and ``python setup.py install``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:69 -msgid "Use `pkg_resources-style namespace packages`_. This method is recommended if you need compatibility with packages already using this method or if your package needs to be zip-safe." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:73 -msgid "While native namespace packages and pkgutil-style namespace packages are largely compatible, pkg_resources-style namespace packages are not compatible with the other methods. It's inadvisable to use different methods in different distributions that provide packages to the same namespace." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:80 -msgid "Native namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:82 -msgid "Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is required to create a native namespace package is that you just omit :file:`__init__.py` from the namespace package directory. An example file structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:97 -msgid "It is extremely important that every distribution that uses the namespace package omits the :file:`__init__.py` or uses a pkgutil-style :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:102 -msgid "Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:`setuptools.find_packages` won't find the sub-package. You must use :func:`setuptools.find_namespace_packages` instead or explicitly list all packages in your :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:117 -msgid "A complete working example of two native namespace packages can be found in the `native namespace package example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:123 -msgid "Because native and pkgutil-style namespace packages are largely compatible, you can use native namespace packages in the distributions that only support Python 3 and pkgutil-style namespace packages in the distributions that need to support Python 2 and 3." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:129 -msgid "pkgutil-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:131 -msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:136 -msgid "To create a pkgutil-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:148 -#: ../source/guides/packaging-namespace-packages.rst:194 -msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:155 -#: ../source/guides/packaging-namespace-packages.rst:201 -msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:160 -msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:171 -msgid "pkg_resources-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:173 -msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:182 -msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:206 -msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:216 -msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:223 -msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:237 -msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 -msgid "Publishing package distribution releases using GitHub Actions CI/CD workflows" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 -msgid "`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an event occurs on the GitHub platform. One popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 -msgid "This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 -msgid "Saving credentials on GitHub" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 -msgid "In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, meaning that we'll have two separate sets of credentials. And we'll need to save them in the GitHub repository settings." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 -msgid "Let's begin! 🚀" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 -msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_. If you have the project on PyPI already, limit the token scope to just that project. You can call it something like ``GitHub Actions CI/CD — project-org/project-repo`` in order for it to be easily distinguishable in the token list. **Don't close the page just yet — you won't see that token again.**" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 -msgid "In a separate browser tab or window, go to the ``Settings`` tab of your target repository and then click on `Secrets`_ in the left sidebar." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 -msgid "Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from the first step." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 -msgid "Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 -msgid "If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 -msgid "Creating a workflow definition" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 -msgid "GitHub CI/CD workflows are declared in YAML files stored in the ``.github/workflows/`` directory of your repository." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 -msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 -msgid "Start it with a meaningful name and define the event that should make GitHub run this workflow:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 -msgid "Defining a workflow job environment" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 -msgid "Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 -msgid "Checking out the project and building distributions" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 -msgid "Then, add the following under the ``build-n-publish`` section:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 -msgid "This will download your repository into the CI runner and then install and activate Python 3.7." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 -msgid "And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a ``pyproject.toml`` properly set up (see :pep:`517`/:pep:`518`)." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 -msgid "You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 -msgid "So add this to the steps list:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 -msgid "Publishing the distribution to PyPI and TestPyPI" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 -msgid "Finally, add the following steps at the end:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 -msgid "These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to PyPI, but only if the current commit is tagged." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 -msgid "That's all, folks!" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 -msgid "Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy!" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:5 -msgid "Single-sourcing the package version" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:8 -msgid "There are many techniques to maintain a single source of truth for the version number of your project:" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:11 -msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py `_)::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:38 -msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's ``setup.cfg`` file (replacing \"package\" with the import name of the package):" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:47 -msgid "Earlier versions of setuptools implemented the ``attr:`` directive by importing the module, but setuptools 46.4.0 added rudimentary AST analysis so that ``attr:`` can function without having to import any of the package's dependencies." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:52 -msgid "Also, please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to ``setup.py``." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:55 -msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:58 -msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version `_, `changes `_, `commitizen `_, `zest.releaser `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:65 -msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:76 -msgid "Example using this technique: `warehouse `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:78 -msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:86 -msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:91 -msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:95 -msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:110 -msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:114 -msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:128 -msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:134 -msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:138 -msgid "Example using this technique: `setuptools `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:141 -msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:155 -msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:161 -msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm `_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:5 -msgid "Supporting multiple Python versions" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:37 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:43 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:49 -msgid "Automated testing and continuous integration" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:51 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:56 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:60 -msgid "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:" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:66 -msgid "`Travis CI `_ provides both a Linux and a macOS environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit while the macOS is 10.9.2 at the time of writing." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:69 -msgid "`Appveyor `_ provides a Windows environment (Windows Server 2012)." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:80 -msgid "Both `Travis CI`_ 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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:85 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:89 -msgid "Tools for single-source Python packages" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:91 -msgid "`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_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:100 -msgid "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" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:107 -msgid "a Python 2 (by syntax) module in a Python 3 project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:108 -msgid "a Python 3 (by syntax) module in a *Python 2* project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:110 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:117 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:124 -msgid "What's in which Python?" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:126 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:3 -msgid "Supporting Windows using Appveyor" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:6 -msgid "2015-12-03" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:8 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:20 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:24 -msgid "The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:30 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:38 -msgid "Setting up" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:40 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:45 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:49 -msgid "Once you have set up your Appveyor account and added your project, Appveyor will automatically build your project each time a commit occurs. This behaviour will be familiar to users of Travis." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:54 -msgid "Adding Appveyor support to your project" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:56 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:61 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:69 -msgid "appveyor.yml" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:75 -msgid "This file can be downloaded from `here `__." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:77 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:80 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:88 -msgid "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``)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:94 -msgid "The ``build`` section simply switches off builds - there is no build step needed for Python, unlike languages like ``C#``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:97 -msgid "The main sections that will need to be tailored to your project are ``test_script`` and ``after_test``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:100 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:109 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:114 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:119 -msgid "Support script" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:121 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:126 -msgid "`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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:133 -msgid "You can simply download the batch file and include it in your project unchanged." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:137 -msgid "Access to the built wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:139 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:147 -msgid "Additional notes" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:150 -msgid "Testing with tox" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:152 -msgid "Many projects use the `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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:156 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:160 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:165 -msgid "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" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:170 -msgid "``DISTUTILS_USE_SDK``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:171 -msgid "``MSSdk``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:172 -msgid "``INCLUDE``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:173 -msgid "``LIB``" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:175 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:181 -msgid "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 Travis or 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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:188 -msgid "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``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:192 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:197 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:203 -msgid "Automatically uploading wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:205 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:210 -msgid "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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:216 -msgid "External dependencies" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:218 -msgid "The supplied scripts will successfully build any distribution that does not rely on 3rd party external libraries for the build." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:221 -msgid "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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:230 -msgid "Support scripts" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:232 -msgid "For reference, the SDK setup support script is listed here:" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:234 -msgid "``appveyor-sample/build.cmd``" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:5 -msgid "Tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:7 -msgid "If you're familiar with Python packaging and installation, and just want to know what tools are currently recommended, then here it is." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:12 -msgid "Application dependency management" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:14 -msgid "Use :ref:`pipenv` to manage library dependencies when developing Python applications. See :doc:`../tutorials/managing-dependencies` for more details on using ``pipenv``." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:18 -msgid "When ``pipenv`` does not meet your use case, consider other tools like:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:20 -msgid ":ref:`pip`" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:22 -msgid "`pip-tools `_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:24 -msgid "`Poetry `_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:27 -msgid "Installation tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:29 -msgid "Use :ref:`pip` to install Python :term:`packages ` from :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip` is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:34 -msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:37 -msgid "If you're looking for management of fully integrated cross-platform software stacks, consider:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:40 -msgid ":ref:`buildout`: primarily focused on the web development community" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:42 -msgid ":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the scientific community." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:47 -msgid "Packaging tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:49 -msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:52 -msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:56 -msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:61 -msgid "Publishing platform migration" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:63 -msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:67 -msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:72 -msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:77 -msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:82 -msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:88 -msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:93 -msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:102 -msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:107 -msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:5 -msgid "Including files in source distributions with ``MANIFEST.in``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:7 -msgid "When building a :term:`source distribution ` for your package, by default only a minimal set of files are included. You may find yourself wanting to include extra files in the source distribution, such as an authors/contributors file, a :file:`docs/` directory, or a directory of data files used for testing purposes. There may even be extra files that you *need* to include; for example, if your :file:`setup.py` computes your project's ``long_description`` by reading from both a README and a changelog file, you'll need to include both those files in the sdist so that people that build or install from the sdist get the correct results." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:17 -msgid "Adding & removing files to & from the source distribution is done by writing a :file:`MANIFEST.in` file at the project root." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:22 -msgid "How files are included in an sdist" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:24 -msgid "The following files are included in a source distribution by default:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:26 -msgid "all Python source files implied by the ``py_modules`` and ``packages`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:28 -msgid "all C source files mentioned in the ``ext_modules`` or ``libraries`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:30 -msgid "scripts specified by the ``scripts`` ``setup()`` argument" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:31 -msgid "all files specified by the ``package_data`` and ``data_files`` ``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:33 -msgid "the file specified by the ``license_file`` option in :file:`setup.cfg` (setuptools 40.8.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:35 -msgid "all files specified by the ``license_files`` option in :file:`setup.cfg` (setuptools 42.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:37 -msgid "all files matching the pattern :file:`test/test*.py`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:38 -msgid ":file:`setup.py` (or whatever you called your setup script)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:39 -msgid ":file:`setup.cfg`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:40 -msgid ":file:`README`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:41 -msgid ":file:`README.txt`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:42 -msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:43 -msgid ":file:`README.md` (setuptools 36.4.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:44 -msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:45 -msgid ":file:`MANIFEST.in`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:47 -msgid "After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files to & from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:52 -msgid "After processing the :file:`MANIFEST.in` file, setuptools removes the :file:`build/` directory as well as any directories named :file:`RCS`, :file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file and an :file:`*.egg-info` directory. This behavior cannot be changed with :file:`MANIFEST.in`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:60 -msgid ":file:`MANIFEST.in` commands" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:62 -msgid "A :file:`MANIFEST.in` file consists of commands, one per line, instructing setuptools to add or remove some set of files from the sdist. The commands are:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:67 -msgid "Command" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:69 -msgid ":samp:`include {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:69 -msgid "Add all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid ":samp:`exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid "Remove all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid "Add all files under directories matching ``dir-pattern`` that match any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid "Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid ":samp:`global-include {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid "Add all files anywhere in the source tree matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid ":samp:`global-exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid "Remove all files anywhere in the source tree matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid ":samp:`graft {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid "Add all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid ":samp:`prune {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid "Remove all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:79 -msgid "The patterns here are glob-style patterns: ``*`` matches zero or more regular filename characters (on Unix, everything except forward slash; on Windows, everything except backslash and colon); ``?`` matches a single regular filename character, and ``[chars]`` matches any one of the characters between the square brackets (which may contain character ranges, e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented support for ``**`` matching zero or more characters including forward slash, backslash, and colon." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:87 -msgid "Directory patterns are relative to the root of the project directory; e.g., ``graft example*`` will include a directory named :file:`examples` in the project root but will not include :file:`docs/examples/`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:91 -msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; setuptools will automatically convert the slashes to the local platform's appropriate directory separator." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:95 -msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:101 -msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." -msgstr "" - -#: ../source/guides/using-testpypi.rst:7 -msgid "``TestPyPI`` is a separate instance of the :term:`Python Package Index (PyPI)` that allows you to try out the distribution tools and process without worrying about affecting the real index. TestPyPI is hosted at `test.pypi.org `_" -msgstr "" - -#: ../source/guides/using-testpypi.rst:13 -msgid "Registering your account" -msgstr "" - -#: ../source/guides/using-testpypi.rst:15 -msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." -msgstr "" - -#: ../source/guides/using-testpypi.rst:19 -msgid "The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted." -msgstr "" - -#: ../source/guides/using-testpypi.rst:24 -msgid "Using TestPyPI with Twine" -msgstr "" - -#: ../source/guides/using-testpypi.rst:26 -msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:33 -msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://test.pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." -msgstr "" - -#: ../source/guides/using-testpypi.rst:39 -msgid "Using TestPyPI with pip" -msgstr "" - -#: ../source/guides/using-testpypi.rst:41 -msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:56 -msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" -msgstr "" - -#: ../source/guides/using-testpypi.rst:73 -msgid "Setting up TestPyPI in :file:`.pypirc`" -msgstr "" - -#: ../source/guides/using-testpypi.rst:75 -msgid "If you want to avoid entering your username, you can configure TestPyPI in your :file:`$HOME/.pypirc`:" -msgstr "" - -#: ../source/index.rst:3 -#: ../source/key_projects.rst:181 -msgid "Python Packaging User Guide" -msgstr "" - -#: ../source/index.rst:5 -msgid "The Python Packaging User Guide (PyPUG) is a collection of tutorials and guides for packaging Python software." -msgstr "" - -#: ../source/index.rst:5 -msgid "python, packaging, guide, tutorial" -msgstr "" - -#: ../source/index.rst:24 -msgid "Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools." -msgstr "" - -#: ../source/index.rst:28 -msgid "This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We happily accept any :doc:`contributions and feedback `. 😊" -msgstr "" - -#: ../source/index.rst:36 -msgid "Get started" -msgstr "" - -#: ../source/index.rst:38 -msgid "Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section:" -msgstr "" - -#: ../source/index.rst:41 -msgid "To learn how to install packages, see the :doc:`tutorial on installing packages `" -msgstr "" - -#: ../source/index.rst:43 -msgid "To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies `" -msgstr "" - -#: ../source/index.rst:45 -msgid "To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing `" -msgstr "" - -#: ../source/index.rst:47 -msgid "To get an overview of packaging options for Python libraries and applications, see the :doc:`Overview of Python Packaging `" -msgstr "" - -#: ../source/index.rst:52 -msgid "Learn more" -msgstr "" - -#: ../source/index.rst:54 -msgid "Beyond our :doc:`tutorials/index`, this guide has several other resources:" -msgstr "" - -#: ../source/index.rst:56 -msgid "The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." -msgstr "" - -#: ../source/index.rst:58 -msgid "The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`." -msgstr "" - -#: ../source/index.rst:60 -msgid "The :doc:`specifications/index` section for packaging interoperability specifications." -msgstr "" - -#: ../source/index.rst:62 -msgid "Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority." -msgstr "" - -#: ../source/key_projects.rst:6 -msgid "Project Summaries" -msgstr "" - -#: ../source/key_projects.rst:8 -msgid "Summaries and links for the most relevant projects in the space of Python installation and packaging." -msgstr "" - -#: ../source/key_projects.rst:14 -msgid "PyPA Projects" -msgstr "" - -#: ../source/key_projects.rst:19 -msgid "bandersnatch" -msgstr "" - -#: ../source/key_projects.rst:21 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:25 -msgid "``bandersnatch`` is a PyPI mirroring client designed to efficiently create a complete mirror of the contents of PyPI. Organizations thus save bandwidth and latency on package downloads (especially in the context of automated tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." -msgstr "" - -#: ../source/key_projects.rst:35 -msgid "build" -msgstr "" - -#: ../source/key_projects.rst:37 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:42 -msgid "``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to build packages, as well as a Python API." -msgstr "" - -#: ../source/key_projects.rst:49 -msgid "cibuildwheel" -msgstr "" - -#: ../source/key_projects.rst:51 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `Discussions `__ | `Discord #cibuildwheel `__" -msgstr "" - -#: ../source/key_projects.rst:58 -msgid "``cibuildwheel`` is a Python package that builds :term:`wheels ` for all common platforms and Python versions on most CI systems. Also see :ref:`multibuild`." -msgstr "" - -#: ../source/key_projects.rst:64 -msgid "distlib" -msgstr "" - -#: ../source/key_projects.rst:66 -msgid "`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:71 -msgid "``distlib`` is a library which implements low-level functions that relate to packaging and distribution of Python software. ``distlib`` implements several relevant PEPs (Python Enhancement Proposal standards) and is useful for developers of third-party packaging tools to make and upload binary and source :term:`distributions `, achieve interoperability, resolve dependencies, manage package resources, and do other similar functions." -msgstr "" - -#: ../source/key_projects.rst:80 -msgid "Unlike the stricter :ref:`packaging` project (below), which specifically implements modern Python packaging interoperability standards, ``distlib`` also attempts to provide reasonable fallback behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards." -msgstr "" - -#: ../source/key_projects.rst:90 -msgid "packaging" -msgstr "" - -#: ../source/key_projects.rst:92 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:97 -msgid "Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." -msgstr "" - -#: ../source/key_projects.rst:99 -msgid "The core utilities in the packaging library handle version handling, specifiers, markers, requirements, tags, and similar attributes and tasks for Python packages. Most Python users rely on this library without needing to explicitly call it; developers of the other Python packaging, distribution, and installation tools listed here often use its functionality to parse, discover, and otherwise handle dependency attributes." -msgstr "" - -#: ../source/key_projects.rst:107 -msgid "This project specifically focuses on implementing the modern Python packaging interoperability standards defined at :ref:`packaging-specifications`, and will report errors for sufficiently old legacy packages that are incompatible with those standards. In contrast, the :ref:`distlib` project is a more permissive library that attempts to provide a plausible reading of ambiguous metadata in cases where :ref:`packaging` will instead report on error." -msgstr "" - -#: ../source/key_projects.rst:119 -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "pip" -msgstr "" - -#: ../source/key_projects.rst:121 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:126 -msgid "The most popular tool for installing Python packages, and the one included with modern versions of Python." -msgstr "" - -#: ../source/key_projects.rst:129 -msgid "It provides the essential core features for finding, downloading, and installing packages from PyPI and other Python package indexes, and can be incorporated into a wide range of development workflows via its command-line interface (CLI)." -msgstr "" - -#: ../source/key_projects.rst:137 -msgid "Pipenv" -msgstr "" - -#: ../source/key_projects.rst:139 -msgid "`Docs `__ | `Source `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:144 -msgid "Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It features very pretty terminal colors." -msgstr "" - -#: ../source/key_projects.rst:148 -msgid "Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. It is used by Python users and system administrators, but has been less maintained since late 2018." -msgstr "" - -#: ../source/key_projects.rst:159 -msgid "Pipfile" -msgstr "" - -#: ../source/key_projects.rst:161 -msgid "`Source `__" -msgstr "" - -#: ../source/key_projects.rst:163 -msgid ":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level application-centric alternative to :ref:`pip`'s lower-level :file:`requirements.txt` file." -msgstr "" - -#: ../source/key_projects.rst:170 -msgid "pipx" -msgstr "" - -#: ../source/key_projects.rst:172 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:176 -msgid "pipx is a tool to install and run Python command-line applications without causing dependency conflicts with other packages installed on the system." -msgstr "" - -#: ../source/key_projects.rst:183 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:187 -msgid "This guide!" -msgstr "" - -#: ../source/key_projects.rst:192 -msgid "readme_renderer" -msgstr "" - -#: ../source/key_projects.rst:194 -msgid "`GitHub and docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:197 -msgid "``readme_renderer`` is a library that package developers use to render their user documentation (README) files into HTML from markup languages such as Markdown or reStructuredText. Developers call it on its own or via :ref:`twine`, as part of their release management process, to check that their package descriptions will properly display on PyPI." -msgstr "" - -#: ../source/key_projects.rst:208 -msgid "setuptools" -msgstr "" - -#: ../source/key_projects.rst:210 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:215 -msgid "setuptools (which includes ``easy_install``) is a collection of enhancements to the Python distutils that allow you to more easily build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages." -msgstr "" - -#: ../source/key_projects.rst:220 -msgid "`distribute`_ was a fork of setuptools that was merged back into setuptools (in v0.7), thereby making setuptools the primary choice for Python packaging." -msgstr "" - -#: ../source/key_projects.rst:227 -msgid "trove-classifiers" -msgstr "" - -#: ../source/key_projects.rst:229 -msgid "`Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:233 -msgid "trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically describe their projects `_ so that users can better find projects that match their needs on the PyPI." -msgstr "" - -#: ../source/key_projects.rst:239 -msgid "The trove-classifiers package contains a list of valid classifiers and deprecated classifiers (which are paired with the classifiers that replace them). Use this package to validate classifiers used in packages intended for uploading to PyPI. As this list of classifiers is published as code, you can install and import it, giving you a more convenient workflow compared to referring to the `list published on PyPI `_. The `issue tracker `_ for the project hosts discussions on proposed classifiers and requests for new classifiers." -msgstr "" - -#: ../source/key_projects.rst:253 -msgid "twine" -msgstr "" - -#: ../source/key_projects.rst:255 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:260 -msgid "Twine is the primary tool developers use to upload packages to the Python Package Index or other Python package indexes. It is a command-line program that passes program files and metadata to a web API. Developers use it because it's the official PyPI upload tool, it's fast and secure, it's maintained, and it reliably works." -msgstr "" - -#: ../source/key_projects.rst:270 -#: ../source/overview.rst:415 -msgid "virtualenv" -msgstr "" - -#: ../source/key_projects.rst:272 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:277 -msgid "virtualenv is a tool which uses the command-line path environment variable to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional functionality, compared to :ref:`venv`, by supporting Python 2.7 and by providing convenient features for configuring, maintaining, duplicating, and troubleshooting the virtual environments. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/key_projects.rst:290 -msgid "Warehouse" -msgstr "" - -#: ../source/key_projects.rst:292 -msgid "`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:296 -msgid "The current codebase powering the :term:`Python Package Index (PyPI)`. It is hosted at `pypi.org `_. The default source for :ref:`pip` downloads." -msgstr "" - -#: ../source/key_projects.rst:304 -msgid "wheel" -msgstr "" - -#: ../source/key_projects.rst:306 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:311 -msgid "Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` extension for creating :term:`wheel distributions `. Additionally, it offers its own command line utility for creating and installing wheels." -msgstr "" - -#: ../source/key_projects.rst:315 -msgid "See also `auditwheel `__, a tool that package developers use to check and fix Python packages they are making in the binary wheel format. It provides functionality to discover dependencies, check metadata for compliance, and repair the wheel and metadata to properly link and include external shared libraries in a package." -msgstr "" - -#: ../source/key_projects.rst:324 -msgid "Non-PyPA Projects" -msgstr "" - -#: ../source/key_projects.rst:329 -msgid "bento" -msgstr "" - -#: ../source/key_projects.rst:331 -msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:336 -msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." -msgstr "" - -#: ../source/key_projects.rst:344 -msgid "buildout" -msgstr "" - -#: ../source/key_projects.rst:346 -msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:351 -msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." -msgstr "" - -#: ../source/key_projects.rst:358 -msgid "conda" -msgstr "" - -#: ../source/key_projects.rst:360 -msgid "`Docs `__" -msgstr "" - -#: ../source/key_projects.rst:362 -msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." -msgstr "" - -#: ../source/key_projects.rst:369 -msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." -msgstr "" - -#: ../source/key_projects.rst:373 -msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." -msgstr "" - -#: ../source/key_projects.rst:386 -msgid "devpi" -msgstr "" - -#: ../source/key_projects.rst:388 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:392 -msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." -msgstr "" - -#: ../source/key_projects.rst:401 -msgid "flit" -msgstr "" - -#: ../source/key_projects.rst:403 -msgid "`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:407 -msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." -msgstr "" - -#: ../source/key_projects.rst:412 -msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." -msgstr "" - -#: ../source/key_projects.rst:422 -msgid "enscons" -msgstr "" - -#: ../source/key_projects.rst:424 -msgid "`Source `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:428 -msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." -msgstr "" - -#: ../source/key_projects.rst:443 -msgid "Hashdist" -msgstr "" - -#: ../source/key_projects.rst:445 -msgid "`Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:448 -msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." -msgstr "" - -#: ../source/key_projects.rst:460 -msgid "hatch" -msgstr "" - -#: ../source/key_projects.rst:462 -msgid "`GitHub and Docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:465 -msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." -msgstr "" - -#: ../source/key_projects.rst:475 -msgid "multibuild" -msgstr "" - -#: ../source/key_projects.rst:477 -msgid "`GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:479 -msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." -msgstr "" - -#: ../source/key_projects.rst:485 -msgid "pex" -msgstr "" - -#: ../source/key_projects.rst:487 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:491 -msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." -msgstr "" - -#: ../source/key_projects.rst:500 -msgid "pip-tools" -msgstr "" - -#: ../source/key_projects.rst:502 -msgid "`GitHub and Docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:505 -msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." -msgstr "" - -#: ../source/key_projects.rst:517 -msgid "piwheels" -msgstr "" - -#: ../source/key_projects.rst:519 -msgid "`Website `__ | `Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:523 -msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." -msgstr "" - -#: ../source/key_projects.rst:532 -msgid "poetry" -msgstr "" - -#: ../source/key_projects.rst:534 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:538 -msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." -msgstr "" - -#: ../source/key_projects.rst:548 -msgid "pypiserver" -msgstr "" - -#: ../source/key_projects.rst:550 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:554 -msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." -msgstr "" - -#: ../source/key_projects.rst:564 -msgid "scikit-build" -msgstr "" - -#: ../source/key_projects.rst:566 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:570 -msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." -msgstr "" - -#: ../source/key_projects.rst:582 -msgid "shiv" -msgstr "" - -#: ../source/key_projects.rst:584 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:588 -msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." -msgstr "" - -#: ../source/key_projects.rst:598 -msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" -msgstr "" - -#: ../source/key_projects.rst:603 -msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." -msgstr "" - -#: ../source/key_projects.rst:611 -msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." -msgstr "" - -#: ../source/key_projects.rst:617 -msgid "zest.releaser" -msgstr "" - -#: ../source/key_projects.rst:619 -msgid "`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:623 -msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." -msgstr "" - -#: ../source/key_projects.rst:630 -msgid "Standard Library Projects" -msgstr "" - -#: ../source/key_projects.rst:635 -msgid "ensurepip" -msgstr "" - -#: ../source/key_projects.rst:637 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:640 -msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." -msgstr "" - -#: ../source/key_projects.rst:649 -msgid "distutils" -msgstr "" - -#: ../source/key_projects.rst:651 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:654 -msgid "The original Python packaging system, added to the standard library in Python 2.0." -msgstr "" - -#: ../source/key_projects.rst:657 -msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." -msgstr "" - -#: ../source/key_projects.rst:670 -msgid "venv" -msgstr "" - -#: ../source/key_projects.rst:672 -msgid "`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:675 -msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/news.rst:2 -msgid "News" -msgstr "" - -#: ../source/news.rst:5 -msgid "September 2019" -msgstr "" - -#: ../source/news.rst:6 -msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" -msgstr "" - -#: ../source/news.rst:9 -msgid "August 2019" -msgstr "" - -#: ../source/news.rst:10 -msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" -msgstr "" - -#: ../source/news.rst:13 -msgid "July 2019" -msgstr "" - -#: ../source/news.rst:14 -msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" -msgstr "" - -#: ../source/news.rst:15 -msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" -msgstr "" - -#: ../source/news.rst:16 -msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" -msgstr "" - -#: ../source/news.rst:17 -msgid "Updated directory layout examples for consistency. (:pr:`611`)" -msgstr "" - -#: ../source/news.rst:18 -msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" -msgstr "" - -#: ../source/news.rst:21 -msgid "June 2019" -msgstr "" - -#: ../source/news.rst:22 -msgid "Fixed some typos. (:pr:`620`)" -msgstr "" - -#: ../source/news.rst:25 -msgid "May 2019" -msgstr "" - -#: ../source/news.rst:26 -msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" -msgstr "" - -#: ../source/news.rst:27 -msgid "Added a MANIFEST.in guide page. (:pr:`609`)" -msgstr "" - -#: ../source/news.rst:30 -msgid "April 2019" -msgstr "" - -#: ../source/news.rst:31 -msgid "Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" -msgstr "" - -#: ../source/news.rst:32 -msgid "Reduced emphasis on virtualenv. (:pr:`606`)" -msgstr "" - -#: ../source/news.rst:35 -msgid "March 2019" -msgstr "" - -#: ../source/news.rst:36 -msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" -msgstr "" - -#: ../source/news.rst:37 -msgid "Covered RTD details for contributing. (:pr:`600`)" -msgstr "" - -#: ../source/news.rst:40 -msgid "February 2019" -msgstr "" - -#: ../source/news.rst:41 -msgid "Elaborate upon the differences between the tutorial and the real packaging process. (:pr:`602`)" -msgstr "" - -#: ../source/news.rst:42 -msgid "Added instructions to install Python CLI applications. (:pr:`594`)" -msgstr "" - -#: ../source/news.rst:45 -msgid "January 2019" -msgstr "" - -#: ../source/news.rst:46 -msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" -msgstr "" - -#: ../source/news.rst:47 -msgid "Updated Sphinx and Nox. (:pr:`591`)" -msgstr "" - -#: ../source/news.rst:48 -msgid "Referenced Twine from Python3. (:pr:`581`)" -msgstr "" - -#: ../source/news.rst:51 -msgid "December 2018" -msgstr "" - -#: ../source/news.rst:52 -msgid "No programmers in the office!" -msgstr "" - -#: ../source/news.rst:55 -msgid "November 2018" -msgstr "" - -#: ../source/news.rst:56 -msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" -msgstr "" - -#: ../source/news.rst:57 -msgid "Changed bumpversion to bump2version. (:pr:`572`)" -msgstr "" - -#: ../source/news.rst:58 -msgid "Added single-sourcing package version example. (:pr:`573`)" -msgstr "" - -#: ../source/news.rst:59 -msgid "Added a guide for creating documentation. (:pr:`568`)" -msgstr "" - -#: ../source/news.rst:62 -msgid "October 2018" -msgstr "" - -#: ../source/news.rst:63 -msgid "Updated Nox package name. (:pr:`566`)" -msgstr "" - -#: ../source/news.rst:64 -msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" -msgstr "" - -#: ../source/news.rst:67 -msgid "September 2018" -msgstr "" - -#: ../source/news.rst:68 -msgid "Added a section on checking RST markup. (:pr:`554`)" -msgstr "" - -#: ../source/news.rst:69 -msgid "Updated user installs page. (:pr:`558`)" -msgstr "" - -#: ../source/news.rst:70 -msgid "Updated Google BigQuery urls. (:pr:`556`)" -msgstr "" - -#: ../source/news.rst:71 -msgid "Replaced tar command with working command. (:pr:`552`)" -msgstr "" - -#: ../source/news.rst:72 -msgid "Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" -msgstr "" - -#: ../source/news.rst:75 -msgid "August 2018" -msgstr "" - -#: ../source/news.rst:76 -msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" -msgstr "" - -#: ../source/news.rst:77 -msgid "Moved the Overview to a task based lead in along with the others. (:pr:`540`)" -msgstr "" - -#: ../source/news.rst:78 -msgid "Updated Python version supported by virtualenv. (:pr:`538`)" -msgstr "" - -#: ../source/news.rst:79 -msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" -msgstr "" - -#: ../source/news.rst:82 -msgid "July 2018" -msgstr "" - -#: ../source/news.rst:84 -msgid "Improved binary extension docs. (:pr:`531`)" -msgstr "" - -#: ../source/news.rst:85 -msgid "Added scikit-build to key projects. (:pr:`530`)" -msgstr "" - -#: ../source/news.rst:88 -msgid "June 2018" -msgstr "" - -#: ../source/news.rst:90 -msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" -msgstr "" - -#: ../source/news.rst:91 -msgid "Updated Markdown descriptions explanation. (:pr:`522`)" -msgstr "" - -#: ../source/news.rst:94 -msgid "May 2018" -msgstr "" - -#: ../source/news.rst:96 -msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" -msgstr "" - -#: ../source/news.rst:97 -msgid "Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" -msgstr "" - -#: ../source/news.rst:98 -msgid "Simplified packaging tutorial. (:pr:`498`)" -msgstr "" - -#: ../source/news.rst:99 -msgid "Updated Windows users instructions for clarity. (:pr:`493`)" -msgstr "" - -#: ../source/news.rst:100 -msgid "Updated the license section description for completeness. (:pr:`492`)" -msgstr "" - -#: ../source/news.rst:101 -msgid "Added specification-style document to contributing section. (:pr:`489`)" -msgstr "" - -#: ../source/news.rst:102 -msgid "Added documentation types to contributing guide. (:pr:`485`)" -msgstr "" - -#: ../source/news.rst:105 -msgid "April 2018" -msgstr "" - -#: ../source/news.rst:107 -msgid "Added README guide. (:pr:`461`)" -msgstr "" - -#: ../source/news.rst:108 -msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" -msgstr "" - -#: ../source/news.rst:109 -msgid "Added instructions for Warehouse. (:pr:`471`)" -msgstr "" - -#: ../source/news.rst:110 -msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" -msgstr "" - -#: ../source/news.rst:111 -msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" -msgstr "" - -#: ../source/news.rst:112 -msgid "Added a guide for phasing out Python versions. (:pr:`459`)" -msgstr "" - -#: ../source/news.rst:113 -msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" -msgstr "" - -#: ../source/news.rst:116 -msgid "March 2018" -msgstr "" - -#: ../source/news.rst:118 -msgid "Updated \"installing scientific packages\". (:pr:`455`)" -msgstr "" - -#: ../source/news.rst:119 -msgid "Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" -msgstr "" - -#: ../source/news.rst:120 -msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" -msgstr "" - -#: ../source/news.rst:121 -msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" -msgstr "" - -#: ../source/news.rst:124 -msgid "February 2018" -msgstr "" - -#: ../source/news.rst:126 -msgid "Added python3-venv and python3-pip to Debian installation instructions. (:pr:`445`)" -msgstr "" - -#: ../source/news.rst:127 -msgid "Updated PyPI migration info. (:pr:`439`)" -msgstr "" - -#: ../source/news.rst:128 -msgid "Added a warning about managing multiple versions with pipenv. (:pr:`430`)" -msgstr "" - -#: ../source/news.rst:129 -msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" -msgstr "" - -#: ../source/news.rst:130 -msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" -msgstr "" - -#: ../source/news.rst:133 -msgid "January 2018" -msgstr "" - -#: ../source/news.rst:135 -msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" -msgstr "" - -#: ../source/news.rst:136 -msgid "Updated README.rst explanation. (:pr:`419`)" -msgstr "" - -#: ../source/news.rst:139 -msgid "December 2017" -msgstr "" - -#: ../source/news.rst:141 -msgid "Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" -msgstr "" - -#: ../source/news.rst:142 -msgid "Noted which fields can be used with environment markers. (:pr:`416`)" -msgstr "" - -#: ../source/news.rst:143 -msgid "Updated Requires-Python section. (:pr:`414`)" -msgstr "" - -#: ../source/news.rst:144 -msgid "Added news page. (:pr:`404`)" -msgstr "" - -#: ../source/news.rst:147 -msgid "November 2017" -msgstr "" - -#: ../source/news.rst:149 -msgid "Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" -msgstr "" - -#: ../source/news.rst:150 -msgid "Updated the *Single Sourcing Package Version* tutorial to reflect pip's current strategy. (:pr:`400`)" -msgstr "" - -#: ../source/news.rst:152 -msgid "Added documentation about the ``py_modules`` argument to ``setup``. (:pr:`398`)" -msgstr "" - -#: ../source/news.rst:153 -msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" -msgstr "" - -#: ../source/news.rst:156 -msgid "October 2017" -msgstr "" - -#: ../source/news.rst:158 -msgid "Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" -msgstr "" - -#: ../source/news.rst:159 -msgid "Created a new guide for managing packages using ``pip`` and ``virtualenv``. (:pr:`385`)" -msgstr "" - -#: ../source/news.rst:160 -msgid "Split the specifications page into multiple pages. (:pr:`386`)" -msgstr "" - -#: ../source/news.rst:163 -msgid "September 2017" -msgstr "" - -#: ../source/news.rst:165 -msgid "Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:`379`)" -msgstr "" - -#: ../source/news.rst:167 -msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" -msgstr "" - -#: ../source/news.rst:170 -msgid "August 2017" -msgstr "" - -#: ../source/news.rst:172 -msgid "Added a new, experimental tutorial on installing packages using ``Pipenv``. (:pr:`369`)" -msgstr "" - -#: ../source/news.rst:173 -msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" -msgstr "" - -#: ../source/news.rst:174 -msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" -msgstr "" - -#: ../source/news.rst:177 -msgid "July 2017" -msgstr "" - -#: ../source/news.rst:179 -msgid "Added ``flit`` to the key projects list. (:pr:`358`)" -msgstr "" - -#: ../source/news.rst:180 -msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" -msgstr "" - -#: ../source/news.rst:181 -msgid "Updated this guide's ``readme`` with instructions on how to build the guide locally. (:pr:`356`)" -msgstr "" - -#: ../source/news.rst:182 -msgid "Made the new ``TestPyPI`` URL more visible, adding note to homepage about pypi.org. (:pr:`354`)" -msgstr "" - -#: ../source/news.rst:183 -msgid "Added a note about the removal of the explicit registration API. (:pr:`347`)" -msgstr "" - -#: ../source/news.rst:186 -msgid "June 2017" -msgstr "" - -#: ../source/news.rst:188 -msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" -msgstr "" - -#: ../source/news.rst:189 -msgid "Added documentation for ``python_requires``. (:pr:`338`)" -msgstr "" - -#: ../source/news.rst:190 -msgid "Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:pr:`335`)" -msgstr "" - -#: ../source/news.rst:191 -msgid "Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" -msgstr "" - -#: ../source/news.rst:192 -msgid "Added a license section to the distributing guide. (:pr:`331`)" -msgstr "" - -#: ../source/news.rst:193 -msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" -msgstr "" - -#: ../source/news.rst:194 -msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" -msgstr "" - -#: ../source/news.rst:195 -msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" -msgstr "" - -#: ../source/news.rst:196 -msgid "Switched to the PyPA theme. (:pr:`305`)" -msgstr "" - -#: ../source/news.rst:197 -msgid "Re-organized the documentation into the new structure. (:pr:`318`)" -msgstr "" - -#: ../source/news.rst:200 -msgid "May 2017" -msgstr "" - -#: ../source/news.rst:202 -msgid "Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" -msgstr "" - -#: ../source/news.rst:203 -msgid "Added contributor and style guide. (:pr:`307`)" -msgstr "" - -#: ../source/news.rst:204 -msgid "Documented ``pip`` and ``easy_install``'s differences for per-project indexes. (:pr:`233`)" -msgstr "" - -#: ../source/news.rst:207 -msgid "April 2017" -msgstr "" - -#: ../source/news.rst:209 -msgid "Added travis configuration for testing pull requests. (:pr:`300`)" -msgstr "" - -#: ../source/news.rst:210 -msgid "Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:`299`)" -msgstr "" - -#: ../source/news.rst:211 -msgid "Removed the ``twine register`` reference in the *Distributing Packages* tutorial. (:pr:`271`)" -msgstr "" - -#: ../source/news.rst:212 -msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" -msgstr "" - -#: ../source/news.rst:213 -msgid "Added a topic on namespace packages. (:pr:`290`)" -msgstr "" - -#: ../source/news.rst:214 -msgid "Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)" -msgstr "" - -#: ../source/news.rst:215 -msgid "Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)" -msgstr "" - -#: ../source/news.rst:216 -msgid "Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)" -msgstr "" - -#: ../source/news.rst:217 -msgid "Swaped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`)" -msgstr "" - -#: ../source/news.rst:219 -msgid "Explained how to install from unsupported sources using a helper application. (:pr:`289`)" -msgstr "" - -#: ../source/news.rst:223 -msgid "March 2017" -msgstr "" - -#: ../source/news.rst:225 -msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" -msgstr "" - -#: ../source/news.rst:228 -msgid "February 2017" -msgstr "" - -#: ../source/news.rst:230 -msgid "Added :pep:`518`. (:pr:`281`)" -msgstr "" - -#: ../source/overview.rst:3 -msgid "An Overview of Packaging for Python" -msgstr "" - -#: ../source/overview.rst:7 -msgid "As a general-purpose programming language, Python is designed to be used in many ways. You can build web sites or industrial robots or a game for your friends to play, and much more, all using the same core technology." -msgstr "" - -#: ../source/overview.rst:12 -msgid "Python's flexibility is why the first step in every Python project must be to think about the project's audience and the corresponding environment where the project will run. It might seem strange to think about packaging before writing code, but this process does wonders for avoiding future headaches." -msgstr "" - -#: ../source/overview.rst:18 -msgid "This overview provides a general-purpose decision tree for reasoning about Python's plethora of packaging options. Read on to choose the best technology for your next project." -msgstr "" - -#: ../source/overview.rst:26 -msgid "Thinking about deployment" -msgstr "" - -#: ../source/overview.rst:28 -msgid "Packages exist to be installed (or *deployed*), so before you package anything, you'll want to have some answers to the deployment questions below:" -msgstr "" - -#: ../source/overview.rst:32 -msgid "Who are your software's users? Will your software be installed by other developers doing software development, operations people in a datacenter, or a less software-savvy group?" -msgstr "" - -#: ../source/overview.rst:35 -msgid "Is your software intended to run on servers, desktops, mobile clients (phones, tablets, etc.), or embedded in dedicated devices?" -msgstr "" - -#: ../source/overview.rst:37 -msgid "Is your software installed individually, or in large deployment batches?" -msgstr "" - -#: ../source/overview.rst:39 -msgid "Packaging is all about target environment and deployment experience. There are many answers to the questions above and each combination of circumstances has its own solutions. With this information, the following overview will guide you to the packaging technologies best suited to your project." -msgstr "" - -#: ../source/overview.rst:46 -msgid "Packaging Python libraries and tools" -msgstr "" - -#: ../source/overview.rst:48 -msgid "You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are just a few of the tools Python's ecosystem provides for distributing Python code to developers, which you can read about in :doc:`guides/distributing-packages-using-setuptools`." -msgstr "" - -#: ../source/overview.rst:53 -msgid "The following approaches to packaging are meant for libraries and tools used by technical audience in a development setting. If you're looking for ways to package Python for a non-technical audience and/or a production setting, skip ahead to :ref:`packaging-applications`." -msgstr "" - -#: ../source/overview.rst:59 -msgid "Python modules" -msgstr "" - -#: ../source/overview.rst:61 -msgid "A Python file, provided it only relies on the standard library, can be redistributed and reused. You will also need to ensure it's written for the right version of Python, and only relies on the standard library." -msgstr "" - -#: ../source/overview.rst:66 -msgid "This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py `_ and `boltons `_." -msgstr "" - -#: ../source/overview.rst:73 -msgid "However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version of Python, hence the options below." -msgstr "" - -#: ../source/overview.rst:78 -msgid "Python source distributions" -msgstr "" - -#: ../source/overview.rst:80 -msgid "If your code consists of multiple Python files, it's usually organized into a directory structure. Any directory containing Python files can comprise an :term:`Import Package`." -msgstr "" - -#: ../source/overview.rst:84 -msgid "Because packages consist of multiple files, they are harder to distribute. Most protocols support transferring only one file at a time (when was the last time you clicked a link and it downloaded multiple files?). It's easier to get incomplete transfers, and harder to guarantee code integrity at the destination." -msgstr "" - -#: ../source/overview.rst:90 -msgid "So long as your code contains nothing but pure Python code, and you know your deployment environment supports your version of Python, then you can use Python's native packaging tools to create a *source* :term:`Distribution Package`, or *sdist* for short." -msgstr "" - -#: ../source/overview.rst:95 -msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." -msgstr "" - -#: ../source/overview.rst:100 -msgid "If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next section, which also has many advantages for pure-Python libraries." -msgstr "" - -#: ../source/overview.rst:107 -msgid "Python and PyPI support multiple distributions providing different implementations of the same package. For instance the unmaintained-but-seminal `PIL distribution `_ provides the PIL package, and so does `Pillow `_, an actively-maintained fork of PIL!" -msgstr "" - -#: ../source/overview.rst:114 -msgid "This Python packaging superpower makes it possible for Pillow to be a drop-in replacement for PIL, just by changing your project's ``install_requires`` or ``requirements.txt``." -msgstr "" - -#: ../source/overview.rst:119 -msgid "Python binary distributions" -msgstr "" - -#: ../source/overview.rst:121 -msgid "So much of Python's practical power comes from its ability to integrate with the software ecosystem, in particular libraries written in C, C++, Fortran, Rust, and other languages." -msgstr "" - -#: ../source/overview.rst:125 -msgid "Not all developers have the right tools or experiences to build these components written in these compiled languages, so Python created the :term:`Wheel`, a package format designed to ship libraries with compiled artifacts. In fact, Python's package installer, ``pip``, always prefers wheels because installation is always faster, so even pure-Python packages work better with wheels." -msgstr "" - -#: ../source/overview.rst:132 -msgid "Binary distributions are best when they come with source distributions to match. Even if you don't upload wheels of your code for every operating system, by uploading the sdist, you're enabling users of other platforms to still build it for themselves. Default to publishing both sdist and wheel archives together, *unless* you're creating artifacts for a very specific use case where you know the recipient only needs one or the other." -msgstr "" - -#: ../source/overview.rst:140 -msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." -msgstr "" - -#: ../source/overview.rst:148 -msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." -msgstr "" - -#: ../source/overview.rst:155 -msgid "Packaging Python applications" -msgstr "" - -#: ../source/overview.rst:157 -msgid "So far we've only discussed Python's native distribution tools. Based on our introduction, you would be correct to infer these built-in approaches only target environments which have Python, and an audience who knows how to install Python packages." -msgstr "" - -#: ../source/overview.rst:162 -msgid "With the variety of operating systems, configurations, and people out there, this assumption is only safe when targeting a developer audience." -msgstr "" - -#: ../source/overview.rst:166 -msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." -msgstr "" - -#: ../source/overview.rst:172 -msgid "Libraries are building blocks, not complete applications. For distributing applications, there's a whole new world of technologies out there." -msgstr "" - -#: ../source/overview.rst:176 -msgid "The next few sections organize these application packaging options according to their dependencies on the target environment, so you can choose the right one for your project." -msgstr "" - -#: ../source/overview.rst:181 -msgid "Depending on a framework" -msgstr "" - -#: ../source/overview.rst:183 -msgid "Some types of Python applications, like web site backends and other network services, are common enough that they have frameworks to enable their development and packaging. Other types of applications, like dynamic web frontends and mobile clients, are complex enough to target that a framework becomes more than a convenience." -msgstr "" - -#: ../source/overview.rst:189 -msgid "In all these cases, it makes sense to work backwards, from the framework's packaging and deployment story. Some frameworks include a deployment system which wraps the technologies outlined in the rest of the guide. In these cases, you'll want to defer to your framework's packaging guide for the easiest and most reliable production experience." -msgstr "" - -#: ../source/overview.rst:195 -msgid "If you ever wonder how these platforms and frameworks work under the hood, you can always read the sections beyond." -msgstr "" - -#: ../source/overview.rst:199 -msgid "Service platforms" -msgstr "" - -#: ../source/overview.rst:201 -msgid "If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku or Google App Engine, you are going to want to follow their respective packaging guides." -msgstr "" - -#: ../source/overview.rst:205 -msgid "`Heroku `_" -msgstr "" - -#: ../source/overview.rst:206 -msgid "`Google App Engine `_" -msgstr "" - -#: ../source/overview.rst:207 -msgid "`PythonAnywhere `_" -msgstr "" - -#: ../source/overview.rst:208 -msgid "`OpenShift `_" -msgstr "" - -#: ../source/overview.rst:209 -msgid "\"Serverless\" frameworks like `Zappa `_" -msgstr "" - -#: ../source/overview.rst:211 -msgid "In all these setups, the platform takes care of packaging and deployment, as long as you follow their patterns. Most software does not fit one of these templates, hence the existence of all the other options below." -msgstr "" - -#: ../source/overview.rst:216 -msgid "If you're developing software that will be deployed to machines you own, users' personal computers, or any other arrangement, read on." -msgstr "" - -#: ../source/overview.rst:220 -msgid "Web browsers and mobile applications" -msgstr "" - -#: ../source/overview.rst:222 -msgid "Python's steady advances are leading it into new spaces. These days you can write a mobile app or web application frontend in Python. While the language may be familiar, the packaging and deployment practices are brand new." -msgstr "" - -#: ../source/overview.rst:227 -msgid "If you're planning on releasing to these new frontiers, you'll want to check out the following frameworks, and refer to their packaging guides:" -msgstr "" - -#: ../source/overview.rst:231 -msgid "`Kivy `_" -msgstr "" - -#: ../source/overview.rst:232 -msgid "`Beeware `_" -msgstr "" - -#: ../source/overview.rst:233 -msgid "`Brython `_" -msgstr "" - -#: ../source/overview.rst:234 -msgid "`Flexx `_" -msgstr "" - -#: ../source/overview.rst:236 -msgid "If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the frameworks above, continue reading below." -msgstr "" - -#: ../source/overview.rst:241 -msgid "Depending on a pre-installed Python" -msgstr "" - -#: ../source/overview.rst:243 -msgid "Pick an arbitrary computer, and depending on the context, there's a very good chance Python is already installed. Included by default in most Linux and Mac operating systems for many years now, you can reasonably depend on Python preexisting in your data centers or on the personal machines of developers and data scientists." -msgstr "" - -#: ../source/overview.rst:249 -msgid "Technologies which support this model:" -msgstr "" - -#: ../source/overview.rst:251 -msgid "`PEX `_ (Python EXecutable)" -msgstr "" - -#: ../source/overview.rst:252 -msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" -msgstr "" - -#: ../source/overview.rst:253 -msgid "`shiv `_ (requires Python 3)" -msgstr "" - -#: ../source/overview.rst:255 -msgid "Of all the approaches here, depending on a pre-installed Python relies the most on the target environment. Of course, this also makes for the smallest package, as small as single-digit megabytes, or even kilobytes." -msgstr "" - -#: ../source/overview.rst:260 -msgid "In general, decreasing the dependency on the target system increases the size of our package, so the solutions here are roughly arranged by increasing size of output." -msgstr "" - -#: ../source/overview.rst:267 -msgid "Depending on a separate software distribution ecosystem" -msgstr "" - -#: ../source/overview.rst:269 -msgid "For a long time many operating systems, including Mac and Windows, lacked built-in package management. Only recently did these OSes gain so-called \"app stores\", but even those focus on consumer applications and offer little for developers." -msgstr "" - -#: ../source/overview.rst:274 -msgid "Developers long sought remedies, and in this struggle, emerged with their own package management solutions, such as `Homebrew `_. The most relevant alternative for Python developers is a package ecosystem called `Anaconda `_. Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments `_." -msgstr "" - -#: ../source/overview.rst:284 -msgid "Instructions on building and publishing for the Anaconda ecosystem:" -msgstr "" - -#: ../source/overview.rst:286 -msgid "`Building libraries and applications with conda `_" -msgstr "" - -#: ../source/overview.rst:287 -msgid "`Transitioning a native Python package to Anaconda `_" -msgstr "" - -#: ../source/overview.rst:289 -msgid "A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages:" -msgstr "" - -#: ../source/overview.rst:293 -msgid "`Enthought Canopy `_" -msgstr "" - -#: ../source/overview.rst:294 -msgid "`ActiveState ActivePython `_" -msgstr "" - -#: ../source/overview.rst:295 -msgid "`WinPython `_" -msgstr "" - -#: ../source/overview.rst:300 -msgid "Bringing your own Python executable" -msgstr "" - -#: ../source/overview.rst:302 -msgid "Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats of program they can natively execute." -msgstr "" - -#: ../source/overview.rst:306 -msgid "There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the Python interpreter and any other dependencies into a single executable file." -msgstr "" - -#: ../source/overview.rst:311 -msgid "This approach, called *freezing*, offers wide compatibility and seamless user experience, though often requires multiple technologies, and a good amount of effort." -msgstr "" - -#: ../source/overview.rst:315 -msgid "A selection of Python freezers:" -msgstr "" - -#: ../source/overview.rst:317 -msgid "`pyInstaller `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:318 -msgid "`cx_Freeze `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:319 -msgid "`constructor `_ - For command-line installers" -msgstr "" - -#: ../source/overview.rst:320 -msgid "`py2exe `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:321 -msgid "`py2app `_ - Mac only" -msgstr "" - -#: ../source/overview.rst:322 -msgid "`bbFreeze `_ - Windows, Linux, Python 2 only" -msgstr "" - -#: ../source/overview.rst:323 -msgid "`osnap `_ - Windows and Mac" -msgstr "" - -#: ../source/overview.rst:324 -msgid "`pynsist `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:326 -msgid "Most of the above imply single-user deployments. For multi-component server applications, see `Chef Omnibus `_." -msgstr "" - -#: ../source/overview.rst:332 -msgid "Bringing your own userspace" -msgstr "" - -#: ../source/overview.rst:334 -msgid "An increasing number of operating systems -- including Linux, Mac OS, and Windows -- can be set up to run applications packaged as lightweight images, using a relatively modern arrangement often referred to as `operating-system-level virtualization `_, or *containerization*." -msgstr "" - -#: ../source/overview.rst:341 -msgid "These techniques are mostly Python agnostic, because they package whole OS filesystems, not just Python or Python packages." -msgstr "" - -#: ../source/overview.rst:344 -msgid "Adoption is most extensive among Linux servers, where the technology originated and where the technologies below work best:" -msgstr "" - -#: ../source/overview.rst:347 -msgid "`AppImage `_" -msgstr "" - -#: ../source/overview.rst:348 -msgid "`Docker `_" -msgstr "" - -#: ../source/overview.rst:349 -msgid "`Flatpak `_" -msgstr "" - -#: ../source/overview.rst:350 -msgid "`Snapcraft `_" -msgstr "" - -#: ../source/overview.rst:353 -msgid "Bringing your own kernel" -msgstr "" - -#: ../source/overview.rst:355 -msgid "Most operating systems support some form of classical virtualization, running applications packaged as images containing a full operating system of their own. Running these virtual machines, or VMs, is a mature approach, widespread in data center environments." -msgstr "" - -#: ../source/overview.rst:360 -msgid "These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from this packaging. Technologies are Python agnostic, and include:" -msgstr "" - -#: ../source/overview.rst:364 -msgid "`Vagrant `_" -msgstr "" - -#: ../source/overview.rst:365 -msgid "`VHD `_, `AMI `_, and `other formats `_" -msgstr "" - -#: ../source/overview.rst:366 -msgid "`OpenStack `_ - A cloud management system in Python, with extensive VM support" -msgstr "" - -#: ../source/overview.rst:369 -msgid "Bringing your own hardware" -msgstr "" - -#: ../source/overview.rst:371 -msgid "The most all-encompassing way to ship your software would be to ship it already-installed on some hardware. This way, your software's user would require only electricity." -msgstr "" - -#: ../source/overview.rst:375 -msgid "Whereas the virtual machines described above are primarily reserved for the tech-savvy, you can find hardware appliances being used by everyone from the most advanced data centers to the youngest children." -msgstr "" - -#: ../source/overview.rst:379 -msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." -msgstr "" - -#: ../source/overview.rst:389 -msgid "The simplified gamut of technologies used to package Python applications." -msgstr "" - -#: ../source/overview.rst:392 -msgid "What about..." -msgstr "" - -#: ../source/overview.rst:394 -msgid "The sections above can only summarize so much, and you might be wondering about some of the more conspicuous gaps." -msgstr "" - -#: ../source/overview.rst:398 -msgid "Operating system packages" -msgstr "" - -#: ../source/overview.rst:400 -msgid "As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some operating systems have package managers of their own. If you're very sure of the operating system you're targeting, you can depend directly on a format like `deb `_ (for Debian, Ubuntu, etc.) or `RPM `_ (for Red Hat, Fedora, etc.), and use that built-in package manager to take care of installation, and even deployment. You can even use `FPM `_ to generate both deb and RPMs from the same source." -msgstr "" - -#: ../source/overview.rst:411 -msgid "In most deployment pipelines, the OS package manager is just one piece of the puzzle." -msgstr "" - -#: ../source/overview.rst:417 -msgid "`Virtualenvs `_ have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are used as a primitive in `the dh-virtualenv tool `_ and `osnap `_, both of which wrap virtualenvs in a self-contained way." -msgstr "" - -#: ../source/overview.rst:427 -msgid "For production deployments, do not rely on running ``python -m pip install`` from the Internet into a virtualenv, as one might do in a development environment. The overview above is full of much better solutions." -msgstr "" - -#: ../source/overview.rst:432 -msgid "Security" -msgstr "" - -#: ../source/overview.rst:434 -msgid "The further down the gradient you come, the harder it gets to update components of your package. Everything is more tightly bound together." -msgstr "" - -#: ../source/overview.rst:437 -msgid "For example, if a kernel security issue emerges, and you're deploying containers, the host system's kernel can be updated without requiring a new build on behalf of the application. If you deploy VM images, you'll need a new build. Whether or not this dynamic makes one option more secure is still a bit of an old debate, going back to the still-unsettled matter of `static versus dynamic linking `_." -msgstr "" - -#: ../source/overview.rst:446 -msgid "Wrap up" -msgstr "" - -#: ../source/overview.rst:448 -msgid "Packaging in Python has a bit of a reputation for being a bumpy ride. This impression is mostly a byproduct of Python's versatility. Once you understand the natural boundaries between each packaging solution, you begin to realize that the varied landscape is a small price Python programmers pay for using one of the most balanced, flexible languages available." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:6 -msgid "Binary distribution format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:8 -msgid "The binary distribution format (:term:`wheel `) was originally defined in :pep:`427`. The current version of the specification is here." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:13 -msgid "Abstract" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:15 -msgid "This PEP describes a built-package format for Python called \"wheel\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:17 -msgid "A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:27 -msgid "PEP Acceptance" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:29 -msgid "This PEP was accepted, and the defined wheel version updated to 1.0, by Nick Coghlan on 16th February, 2013 [1]_" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:34 -msgid "Rationale" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:36 -msgid "Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:43 -msgid "Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:52 -msgid "Details" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:55 -msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:57 -msgid "Wheel installation notionally consists of two phases:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:59 -msgid "Unpack." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:61 -msgid "Parse ``distribution-1.0.dist-info/WHEEL``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:62 -msgid "Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:64 -msgid "If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:66 -msgid "Else unpack archive into platlib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:68 -msgid "Spread." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:70 -msgid "Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:72 -msgid "Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:78 -msgid "If applicable, update scripts starting with ``#!python`` to point to the correct interpreter." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:80 -msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:82 -msgid "Remove empty ``distribution-1.0.data`` directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:83 -msgid "Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:87 -msgid "Recommended installer features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:97 -msgid "Rewrite ``#!python``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:90 -msgid "In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:96 -msgid "The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI script instead of a console script." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:102 -msgid "Generate script wrappers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:100 -msgid "In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:105 -msgid "Recommended archiver features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:112 -msgid "Place ``.dist-info`` at the end of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:108 -msgid "Archivers are encouraged to place the ``.dist-info`` files physically at the end of the archive. This enables some potentially interesting ZIP tricks including the ability to amend the metadata without rewriting the entire archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:115 -msgid "File Format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:118 -msgid "File name convention" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:120 -msgid "The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "distribution" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "Distribution name, e.g. 'django', 'pyramid'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "Distribution version, e.g. 1.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:135 -msgid "build tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:130 -msgid "Optional build number. Must start with a digit. Acts as a tie-breaker if two wheel file names are the same in all other respects (i.e. name, version, and other tags). Sort as an empty tuple if unspecified, else sort as a two-item tuple with the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "language implementation and version tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "E.g. 'py27', 'py2', 'py3'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "abi tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "E.g. 'cp33m', 'abi3', 'none'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "platform tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "E.g. 'linux_x86_64', 'any'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:146 -msgid "For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:151 -msgid "The last three components of the filename before the extension are called \"compatibility tags.\" The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:156 -msgid "Escaping and Unicode" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:158 -msgid "As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:161 -msgid "In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:164 -msgid "Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:166 -msgid "The remaining components may not contain ``-`` characters, so no escaping is necessary." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:169 -msgid "Tools producing wheels should verify that the filename components do not contain ``-``, as the resulting file may not be processed correctly if they do." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:172 -msgid "The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:176 -msgid "The filenames *inside* the archive are encoded as UTF-8. Although some ZIP clients in common use do not properly display UTF-8 filenames, the encoding is supported by both the ZIP specification and Python's ``zipfile``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:182 -msgid "File contents" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:184 -msgid "The contents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:188 -msgid "``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:191 -msgid "``{distribution}-{version}.dist-info/`` contains metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:192 -msgid "``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:196 -msgid "Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:200 -msgid "``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater format metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:202 -msgid "``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself in the same basic key: value format::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:212 -msgid "``Wheel-Version`` is the version number of the Wheel specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:213 -msgid "``Generator`` is the name and optionally the version of the software that produced the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:215 -msgid "``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:218 -msgid "``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:220 -msgid "``Build`` is the build number and is omitted if there is no build number." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:221 -msgid "A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:224 -msgid "Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:226 -msgid "Wheel does not contain setup.py or setup.cfg." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:228 -msgid "This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:235 -#: ../source/specifications/recording-installed-packages.rst:35 -msgid "The .dist-info directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:237 -msgid "Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:239 -msgid "METADATA is the package metadata, the same format as PKG-INFO as found at the root of sdists." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:241 -msgid "WHEEL is the wheel metadata specific to a build of the package." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:242 -msgid "RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:248 -msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:249 -msgid "RECORD.jws is used for digital signatures. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:251 -msgid "RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME signatures to secure their wheel files. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:254 -msgid "During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:261 -msgid "The .data directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:263 -msgid "Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:271 -msgid "The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:277 -msgid "Signed wheel files" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:279 -msgid "Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include a secure hash ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD which cannot contain its own hash. For example::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:290 -msgid "The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD or the installation will fail." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:295 -msgid "If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the signature's JSON payload::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:302 -msgid "(The hash value is the same format used in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:304 -msgid "If RECORD.p7s is used, it must contain a detached S/MIME format signature of RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:307 -msgid "A wheel installer is not required to understand digital signatures but MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:312 -msgid "See" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:314 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:315 -msgid "http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:316 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:317 -msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:321 -msgid "Comparison to .egg" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:323 -msgid "Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:328 -msgid "Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:331 -msgid "Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:337 -msgid "Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:341 -msgid "Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:344 -msgid "Wheel is a reference to the other Python." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:348 -msgid "FAQ" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:352 -msgid "Wheel defines a .data directory. Should I put all my data there?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:354 -msgid "This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:363 -msgid "Why does wheel include attached signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:365 -msgid "Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature or individual files can be verified without having to download the whole archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:373 -msgid "Why does wheel allow JWS signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:375 -msgid "The JOSE specifications of which JWS is a part are designed to be easy to implement, a feature that is also one of wheel's primary design goals. JWS yields a useful, concise pure-Python implementation." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:381 -msgid "Why does wheel also allow S/MIME signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:383 -msgid "S/MIME signatures are allowed for users who need or want to use existing public key infrastructure with wheel." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:386 -msgid "Signed packages are only a basic building block in a secure package update system. Wheel only provides the building block." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:391 -msgid "What's the deal with \"purelib\" vs. \"platlib\"?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:393 -msgid "Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is significant on some platforms. For example, Fedora installs pure Python packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent packages to '/usr/lib64/pythonX.Y/site-packages'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:398 -msgid "A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: true\" with those same files in the root, and it is legal to have files in both the \"purelib\" and \"platlib\" categories." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:403 -msgid "In practice a wheel should have only one of \"purelib\" or \"platlib\" depending on whether it is pure Python or not and those files should be at the root with the appropriate setting given for \"Root-is-purelib\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:409 -msgid "Is it possible to import Python code directly from a wheel file?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:411 -msgid "Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with ``zipimport``, a subset of wheel files *do* support being placed directly on ``sys.path``. However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:417 -msgid "Firstly, wheel *is* designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:426 -msgid "Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is *not* supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the ``__file__`` attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:443 -msgid "Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you *do* decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:450 -msgid "Changes" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:452 -msgid "Since :pep:`427`, this specification has changed as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:454 -msgid "The rules on escaping in wheel filenames were revised, to bring them into line with what popular tools actually do (February 2021)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:461 -msgid "PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:466 -msgid "Appendix" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:468 -msgid "Example urlsafe-base64-nopad implementation::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:482 -msgid "Copyright" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:484 -msgid "This document has been placed into the public domain." -msgstr "" - -#: ../source/specifications/core-metadata.rst:5 -msgid "Core metadata specifications" -msgstr "" - -#: ../source/specifications/core-metadata.rst:7 -msgid "Fields defined in the following specification should be considered valid, complete and not subject to change. The required fields are:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:10 -msgid "``Metadata-Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:11 -msgid "``Name``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:12 -msgid "``Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:14 -msgid "All the other fields are optional." -msgstr "" - -#: ../source/specifications/core-metadata.rst:16 -msgid "The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats have been revised several times, and exactly which email RFC applies to packaging metadata is not specified. In the absence of a precise definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy." -msgstr "" - -#: ../source/specifications/core-metadata.rst:25 -msgid "Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift to a new format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:30 -msgid "*Interpreting old metadata:* In :pep:`566`, the version specifier field format specification was relaxed to accept the syntax used by popular publishing tools (namely to remove the requirement that version specifiers must be surrounded by parentheses). Metadata consumers may want to use the more relaxed formatting rules even for metadata files that are nominally less than version 2.1." -msgstr "" - -#: ../source/specifications/core-metadata.rst:41 -msgid "Metadata-Version" -msgstr "" - -#: ../source/specifications/core-metadata.rst:45 -msgid "Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", \"2.1\" and \"2.2\"." -msgstr "" - -#: ../source/specifications/core-metadata.rst:48 -msgid "Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if ``metadata_version`` has a greater major version than the highest version they support (as described in :pep:`440`, the major version is the value before the first dot)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:54 -msgid "For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields." -msgstr "" - -#: ../source/specifications/core-metadata.rst:58 -#: ../source/specifications/core-metadata.rst:80 -#: ../source/specifications/core-metadata.rst:95 -#: ../source/specifications/core-metadata.rst:155 -#: ../source/specifications/core-metadata.rst:170 -#: ../source/specifications/core-metadata.rst:208 -#: ../source/specifications/core-metadata.rst:283 -#: ../source/specifications/core-metadata.rst:287 -#: ../source/specifications/core-metadata.rst:291 -#: ../source/specifications/core-metadata.rst:295 -#: ../source/specifications/core-metadata.rst:327 -#: ../source/specifications/core-metadata.rst:347 -#: ../source/specifications/core-metadata.rst:373 -#: ../source/specifications/core-metadata.rst:391 -#: ../source/specifications/core-metadata.rst:416 -#: ../source/specifications/core-metadata.rst:438 -#: ../source/specifications/core-metadata.rst:600 -#: ../source/specifications/core-metadata.rst:620 -#: ../source/specifications/core-metadata.rst:630 -msgid "Example::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:66 -msgid "Name" -msgstr "" - -#: ../source/specifications/core-metadata.rst:69 -msgid "Added additional restrictions on format from :pep:`508`" -msgstr "" - -#: ../source/specifications/core-metadata.rst:72 -msgid "The name of the distribution. The name field is the primary identifier for a distribution. A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. Distribution names are limited to those which match the following regex (run with ``re.IGNORECASE``)::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:88 -msgid "Version" -msgstr "" - -#: ../source/specifications/core-metadata.rst:92 -msgid "A string containing the distribution's version number. This field must be in the format specified in :pep:`440`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:101 -msgid "Dynamic (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:105 -msgid "A string containing the name of another core metadata field. The field names ``Name`` and ``Version`` may not be specified in this field." -msgstr "" - -#: ../source/specifications/core-metadata.rst:108 -msgid "When found in the metadata of a source distribution, the following rules apply:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:111 -msgid "If a field is *not* marked as ``Dynamic``, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT be present in the wheel." -msgstr "" - -#: ../source/specifications/core-metadata.rst:115 -msgid "If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:118 -msgid "If the sdist metadata version is older than version 2.2, then all fields should be treated as if they were specified with ``Dynamic`` (i.e. there are no special restrictions on the metadata of wheels built from the sdist)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:122 -msgid "In any context other than a source distribution, ``Dynamic`` is for information only, and indicates that the field value was calculated at wheel build time, and may not be the same as the value in the sdist or in other wheels for the project." -msgstr "" - -#: ../source/specifications/core-metadata.rst:127 -msgid "Full details of the semantics of ``Dynamic`` are described in :pep:`643`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:131 -msgid "Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:135 -msgid "A Platform specification describing an operating system supported by the distribution which is not listed in the \"Operating System\" Trove classifiers. See \"Classifier\" below." -msgstr "" - -#: ../source/specifications/core-metadata.rst:146 -msgid "Supported-Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:150 -msgid "Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP." -msgstr "" - -#: ../source/specifications/core-metadata.rst:164 -msgid "Summary" -msgstr "" - -#: ../source/specifications/core-metadata.rst:168 -msgid "A one-line summary of what the distribution does." -msgstr "" - -#: ../source/specifications/core-metadata.rst:188 -msgid "This field may be specified in the message body instead." -msgstr "" - -#: ../source/specifications/core-metadata.rst:191 -msgid "A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:196 -msgid "The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use." -msgstr "" - -#: ../source/specifications/core-metadata.rst:202 -msgid "To support empty lines and lines with indentation with respect to the RFC 822 format, any CRLF character has to be suffixed by 7 spaces followed by a pipe (\"|\") char. As a result, the Description field is encoded into a folded field that can be interpreted by RFC822 parser [2]_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:219 -msgid "This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader." -msgstr "" - -#: ../source/specifications/core-metadata.rst:223 -msgid "Alternatively, the distribution's description may instead be provided in the message body (i.e., after a completely blank line following the headers, with no indentation or other special formatting necessary)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:232 -msgid "Description-Content-Type" -msgstr "" - -#: ../source/specifications/core-metadata.rst:236 -msgid "A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:239 -msgid "Historically, PyPI supported descriptions in plain text and `reStructuredText (reST) `_, and could render reST into HTML. However, it is common for distribution authors to write the description in `Markdown `_ (`RFC 7763 `_) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats." -msgstr "" - -#: ../source/specifications/core-metadata.rst:253 -msgid "The format of this field is the same as the ``Content-Type`` header in HTTP (i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then it can optionally have a number of parameters:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:259 -msgid "Format::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:263 -msgid "The ``type/subtype`` part has only a few legal values:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:265 -msgid "``text/plain``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:266 -msgid "``text/x-rst``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:267 -msgid "``text/markdown``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:269 -msgid "The ``charset`` parameter can be used to specify the character encoding of the description. The only legal value is ``UTF-8``. If omitted, it is assumed to be ``UTF-8``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:273 -msgid "Other parameters might be specific to the chosen subtype. For example, for the ``markdown`` subtype, there is an optional ``variant`` parameter that allows specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:278 -msgid "``GFM`` for `Github-flavored Markdown `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:280 -msgid "``CommonMark`` for `CommonMark `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:299 -msgid "If a ``Description-Content-Type`` is not specified, then applications should attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to ``text/plain`` if it is not valid rst." -msgstr "" - -#: ../source/specifications/core-metadata.rst:303 -msgid "If a ``Description-Content-Type`` is an unrecognized value, then the assumed content type is ``text/plain`` (Although PyPI will probably reject anything with an unrecognized value)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:307 -msgid "If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is not specified or is set to an unrecognized value, then the assumed ``variant`` is ``GFM``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:311 -msgid "So for the last example above, the ``charset`` defaults to ``UTF-8`` and the ``variant`` defaults to ``GFM`` and thus it is equivalent to the example before it." -msgstr "" - -#: ../source/specifications/core-metadata.rst:320 -msgid "Keywords" -msgstr "" - -#: ../source/specifications/core-metadata.rst:324 -msgid "A list of additional keywords, separated by commas, to be used to assist searching for the distribution in a larger catalog." -msgstr "" - -#: ../source/specifications/core-metadata.rst:333 -msgid "The specification previously showed keywords separated by spaces, but distutils and setuptools implemented it with commas. These tools have been very widely used for many years, so it was easier to update the specification to match the de facto standard." -msgstr "" - -#: ../source/specifications/core-metadata.rst:341 -msgid "Home-page" -msgstr "" - -#: ../source/specifications/core-metadata.rst:345 -msgid "A string containing the URL for the distribution's home page." -msgstr "" - -#: ../source/specifications/core-metadata.rst:353 -msgid "Download-URL" -msgstr "" - -#: ../source/specifications/core-metadata.rst:357 -msgid "A string containing the URL from which this version of the distribution can be downloaded. (This means that the URL can't be something like \".../BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:366 -msgid "Author" -msgstr "" - -#: ../source/specifications/core-metadata.rst:370 -msgid "A string containing the author's name at a minimum; additional contact information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:383 -msgid "Author-email" -msgstr "" - -#: ../source/specifications/core-metadata.rst:387 -msgid "A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:395 -#: ../source/specifications/core-metadata.rst:442 -msgid "Per RFC-822, this field may contain multiple comma-separated e-mail addresses::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:405 -msgid "Maintainer" -msgstr "" - -#: ../source/specifications/core-metadata.rst:409 -msgid "A string containing the maintainer's name at a minimum; additional contact information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:412 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:426 -msgid "Maintainer-email" -msgstr "" - -#: ../source/specifications/core-metadata.rst:430 -msgid "A string containing the maintainer's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:434 -msgid "Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to ``Author-email``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:452 -msgid "License" -msgstr "" - -#: ../source/specifications/core-metadata.rst:456 -msgid "Text indicating the license covering the distribution where the license is not a selection from the \"License\" Trove classifiers. See :ref:`\"Classifier\" ` below. This field may also be used to specify a particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license." -msgstr "" - -#: ../source/specifications/core-metadata.rst:476 -msgid "Classifier (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:480 -msgid "Each entry is a string giving a single classification value for the distribution. Classifiers are described in :pep:`301`, and the Python Package Index publishes a dynamic list of `currently defined classifiers `__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:485 -#: ../source/specifications/core-metadata.rst:574 -#: ../source/specifications/core-metadata.rst:691 -#: ../source/specifications/core-metadata.rst:715 -msgid "This field may be followed by an environment marker after a semicolon." -msgstr "" - -#: ../source/specifications/core-metadata.rst:496 -msgid "Requires-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:499 -#: ../source/specifications/core-metadata.rst:561 -#: ../source/specifications/core-metadata.rst:663 -#: ../source/specifications/core-metadata.rst:704 -msgid "The field format specification was relaxed to accept the syntax used by popular publishing tools." -msgstr "" - -#: ../source/specifications/core-metadata.rst:503 -msgid "Each entry contains a string naming some other distutils project required by this distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:506 -msgid "The format of a requirement string contains from one to four parts:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:508 -msgid "A project name, in the same format as the ``Name:`` field. The only mandatory part." -msgstr "" - -#: ../source/specifications/core-metadata.rst:510 -msgid "A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may need extra dependencies." -msgstr "" - -#: ../source/specifications/core-metadata.rst:513 -msgid "A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:516 -msgid "An environment marker after a semicolon. This means that the requirement is only needed in the specified conditions." -msgstr "" - -#: ../source/specifications/core-metadata.rst:519 -msgid "See :pep:`508` for full details of the allowed format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:521 -msgid "The project names should correspond to names as found on the `Python Package Index`_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:524 -msgid "Version specifiers must follow the rules described in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:538 -msgid "Requires-Python" -msgstr "" - -#: ../source/specifications/core-metadata.rst:542 -msgid "This field specifies the Python version(s) that the distribution is guaranteed to be compatible with. Installation tools may look at this when picking which version of a project to install." -msgstr "" - -#: ../source/specifications/core-metadata.rst:546 -msgid "The value must be in the format specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:548 -msgid "This field cannot be followed by an environment marker." -msgstr "" - -#: ../source/specifications/core-metadata.rst:558 -msgid "Requires-External (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:565 -msgid "Each entry contains a string describing some dependency in the system that the distribution is to be used. This field is intended to serve as a hint to downstream project maintainers, and has no semantics which are meaningful to the ``distutils`` distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:570 -msgid "The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:576 -msgid "Because they refer to non-Python software releases, version numbers for this field are **not** required to conform to the format specified in :pep:`440`: they should correspond to the version scheme used by the external dependency." -msgstr "" - -#: ../source/specifications/core-metadata.rst:581 -msgid "Notice that there is no particular rule on the strings to be used." -msgstr "" - -#: ../source/specifications/core-metadata.rst:593 -msgid "Project-URL (multiple-use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:597 -msgid "A string containing a browsable URL for the project and a label for it, separated by a comma." -msgstr "" - -#: ../source/specifications/core-metadata.rst:604 -msgid "The label is free text limited to 32 characters." -msgstr "" - -#: ../source/specifications/core-metadata.rst:612 -msgid "Provides-Extra (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:616 -msgid "A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested." -msgstr "" - -#: ../source/specifications/core-metadata.rst:625 -msgid "A second distribution requires an optional dependency by placing it inside square brackets, and can request multiple features by separating them with a comma (,). The requirements are evaluated for each requested feature and added to the set of requirements for the distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:635 -msgid "Two feature names ``test`` and ``doc`` are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively." -msgstr "" - -#: ../source/specifications/core-metadata.rst:639 -msgid "It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:644 -msgid "Rarely Used Fields" -msgstr "" - -#: ../source/specifications/core-metadata.rst:646 -msgid "The fields in this section are currently rarely used, as their design was inspired by comparable mechanisms in Linux package management systems, and it isn't at all clear how tools should interpret them in the context of an open index server such as `PyPI `__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:651 -msgid "As a result, popular installation tools ignore them completely, which in turn means there is little incentive for package publishers to set them appropriately. However, they're retained in the metadata specification, as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository." -msgstr "" - -#: ../source/specifications/core-metadata.rst:660 -msgid "Provides-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:667 -msgid "Each entry contains a string naming a Distutils project which is contained within this distribution. This field *must* include the project identified in the ``Name`` field, followed by the version : Name (Version)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:672 -msgid "A distribution may provide additional names, e.g. to indicate that multiple projects have been bundled together. For instance, source distributions of the ``ZODB`` project have historically included the ``transaction`` project, which is now available as a separate distribution. Installing such a source distribution satisfies requirements for both ``ZODB`` and ``transaction``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:679 -msgid "A distribution may also provide a \"virtual\" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:687 -msgid "A version declaration may be supplied and must follow the rules described in :doc:`version-specifiers`. The distribution's version number will be implied if none is specified." -msgstr "" - -#: ../source/specifications/core-metadata.rst:701 -msgid "Obsoletes-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:708 -msgid "Each entry contains a string describing a distutils project's distribution which this distribution renders obsolete, meaning that the two projects should not be installed at the same time." -msgstr "" - -#: ../source/specifications/core-metadata.rst:712 -msgid "Version declarations can be supplied. Version numbers must be in the format specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:717 -msgid "The most common use of this field will be in case a project name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon distribution should be removed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:730 -msgid "reStructuredText markup: http://docutils.sourceforge.net/" -msgstr "" - -#: ../source/specifications/core-metadata.rst:735 -msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:6 -msgid "Declaring build system dependencies" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:8 -msgid "`pyproject.toml` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:5 -msgid "Declaring project metadata" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:7 -msgid ":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to consume. It defines the following specification as the canonical source for the format used." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:12 -msgid "There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed via the ``dynamic`` field (defined later in this specification) and represents metadata that a tool will later provide." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:18 -msgid "The fields defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add fields to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end will dynamically provide all fields." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:27 -msgid "The only fields required to be statically defined are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:29 -#: ../source/specifications/declaring-project-metadata.rst:41 -msgid "``name``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:31 -msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:34 -#: ../source/specifications/declaring-project-metadata.rst:54 -msgid "``version``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:36 -msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:43 -#: ../source/specifications/declaring-project-metadata.rst:56 -#: ../source/specifications/declaring-project-metadata.rst:68 -#: ../source/specifications/declaring-project-metadata.rst:117 -msgid "TOML_ type: string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:44 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Name `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:47 -msgid "The name of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:49 -msgid "Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:57 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Version `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:60 -msgid "The version of the project as supported by :pep:`440`." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:62 -msgid "Users SHOULD prefer to specify already-normalized versions." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:66 -msgid "``description``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:69 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:72 -msgid "The summary description of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:76 -msgid "``readme``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:78 -msgid "TOML_ type: string or table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:79 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Description ` and :ref:`Description-Content-Type `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:83 -msgid "The full description of the project (i.e. the README)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:85 -msgid "The field accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without specifying this field as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:96 -msgid "The ``readme`` field may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:103 -msgid "A table specified in the ``readme`` field also has a ``content-type`` field which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not specify this field in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:115 -msgid "``requires-python``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:118 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Python `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:121 -msgid "The Python version requirements of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:125 -msgid "``license``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:127 -msgid "TOML_ type: table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:128 -msgid "Corresponding :ref:`core metadata ` field: :ref:`License `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:131 -msgid "The table may have one of two keys. The ``file`` key has a string value that is a file path relative to ``pyproject.toml`` to the file which contains the license for the project. Tools MUST assume the file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:140 -msgid "``authors``/``maintainers``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:142 -msgid "TOML_ type: Array of inline tables with string keys and values" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:143 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:`Maintainer `, and :ref:`Maintainer-email `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:149 -msgid "The people or organizations considered to be the \"authors\" of the project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:154 -msgid "The \"maintainers\" field is similar to \"authors\" in that its exact meaning is open to interpretation." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:157 -msgid "These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not contain commas. The ``email`` value MUST be a valid email address. Both keys are optional." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:163 -msgid "Using the data to fill in :ref:`core metadata ` is as follows:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:166 -msgid "If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:169 -msgid "If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:173 -msgid "If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:177 -msgid "Multiple values should be separated by commas." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:181 -msgid "``keywords``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:183 -#: ../source/specifications/declaring-project-metadata.rst:193 -msgid "TOML_ type: array of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:184 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Keywords `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:187 -msgid "The keywords for the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:191 -msgid "``classifiers``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:194 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:197 -msgid "Trove classifiers which apply to the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:201 -msgid "``urls``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:203 -msgid "TOML_ type: table with keys and values of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:204 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Project-URL `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:207 -msgid "A table of URLs where the key is the URL label and the value is the URL itself." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:212 -msgid "Entry points" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:214 -msgid "TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:216 -msgid ":ref:`Entry points specification `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:218 -msgid "There are three tables related to entry points. The ``[project.scripts]`` table corresponds to the ``console_scripts`` group in the :ref:`entry points specification `. The key of the table is the name of the entry point and the value is the object reference." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:224 -msgid "The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group in the :ref:`entry points specification `. Its format is the same as ``[project.scripts]``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:228 -msgid "The ``[project.entry-points]`` table is a collection of tables. Each sub-table's name is an entry point group. The key and value semantics are the same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but instead keep the entry point groups to only one level deep." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:234 -msgid "Build back-ends MUST raise an error if the metadata defines a ``[project.entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` table, as they would be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:242 -msgid "``dependencies``/``optional-dependencies``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:244 -msgid "TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings (``optional-dependencies``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:247 -msgid "Corresponding :ref:`core metadata ` field: :ref:`Requires-Dist ` and :ref:`Provides-Extra `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:251 -msgid "The (optional) dependencies of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:253 -msgid "For ``dependencies``, it is a key whose value is an array of strings. Each string represents a dependency of the project and MUST be formatted as a valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist ` entry." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:258 -msgid "For ``optional-dependencies``, it is a table where each key specifies an extra and whose value is an array of strings. The strings of the arrays must be valid :pep:`508` strings. The keys MUST be valid values for :ref:`Provides-Extra `. Each value in the array thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:269 -msgid "``dynamic``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:271 -msgid "TOML_ type: array of string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:272 -msgid "A corresponding :ref:`core metadata ` field does not exist" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:275 -msgid "Specifies which fields listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:281 -msgid "A build back-end MUST honour statically-specified metadata (which means the metadata did not list the field in ``dynamic``)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:283 -msgid "A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:285 -msgid "If the :ref:`core metadata ` specification lists a field as \"Required\", then the metadata MUST specify the field statically or list it in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the ``[project]`` table)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:290 -msgid "If the :ref:`core metadata ` specification lists a field as \"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is a build back-end will provide the data for the field later." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:294 -msgid "Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in ``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:296 -msgid "If the metadata does not list a field in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:300 -msgid "Build back-ends MUST raise an error if the metadata specifies a field in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable)." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:6 -msgid "Dependency specifiers" -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:8 -msgid "The dependency specifier format used to declare a dependency on another component is defined in :pep:`508`." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:11 -msgid "The environment markers section in this PEP supersedes the environment markers section in :pep:`345`." -msgstr "" - -#: ../source/specifications/direct-url.rst:6 -msgid "Recording the Direct URL Origin of installed distributions" -msgstr "" - -#: ../source/specifications/direct-url.rst:8 -msgid "This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the Direct URL Origin of the distribution. The layout of this file was originally specified in :pep:`610` and is formally documented here." -msgstr "" - -#: ../source/specifications/direct-url.rst:17 -msgid "Specification" -msgstr "" - -#: ../source/specifications/direct-url.rst:19 -msgid "The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` directory by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/direct-url.rst:23 -#: ../source/specifications/recording-installed-packages.rst:206 -msgid "This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier)." -msgstr "" - -#: ../source/specifications/direct-url.rst:26 -msgid "This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." -msgstr "" - -#: ../source/specifications/direct-url.rst:29 -msgid "If present, it MUST contain at least two fields. The first one is ``url``, with type ``string``. Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a local directory). These info fields have a (possibly empty) subdictionary as value, with the possible keys defined below." -msgstr "" - -#: ../source/specifications/direct-url.rst:36 -msgid "``url`` MUST be stripped of any sensitive authentication information, for security reasons." -msgstr "" - -#: ../source/specifications/direct-url.rst:39 -msgid "The user:password section of the URL MAY however be composed of environment variables, matching the following regular expression::" -msgstr "" - -#: ../source/specifications/direct-url.rst:45 -msgid "Additionally, the user:password section of the URL MAY be a well-known, non security sensitive string. A typical example is ``git`` in the case of an URL such as ``ssh://git@gitlab.com/user/repo``." -msgstr "" - -#: ../source/specifications/direct-url.rst:49 -msgid "When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present as a dictionary with the following keys:" -msgstr "" - -#: ../source/specifications/direct-url.rst:52 -msgid "A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by writing a PEP to amend this specification. The ``url`` value MUST be compatible with the corresponding VCS, so an installer can hand it off without transformation to a checkout/download command of the VCS." -msgstr "" - -#: ../source/specifications/direct-url.rst:58 -msgid "A ``requested_revision`` key (type ``string``) MAY be present naming a branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to install." -msgstr "" - -#: ../source/specifications/direct-url.rst:61 -msgid "A ``commit_id`` key (type ``string``) MUST be present, containing the exact commit/revision number that was installed. If the VCS supports commit-hash based revision identifiers, such commit-hash MUST be used as ``commit_id`` in order to reference the immutable version of the source code that was installed." -msgstr "" - -#: ../source/specifications/direct-url.rst:68 -msgid "When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:71 -msgid "A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are unconditionally provided by the latest version of the standard library's ``hashlib`` module be used for source archive hashes. At time of writing, that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'." -msgstr "" - -#: ../source/specifications/direct-url.rst:78 -msgid "When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:81 -msgid "``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``." -msgstr "" - -#: ../source/specifications/direct-url.rst:84 -msgid "When ``url`` refers to a local directory, it MUST have the ``file`` sheme and be compliant with `RFC 8089 `_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute." -msgstr "" - -#: ../source/specifications/direct-url.rst:91 -msgid "When the requested URL has the file:// scheme and points to a local directory that happens to contain a VCS checkout, installers MUST NOT attempt to infer any VCS information and therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`." -msgstr "" - -#: ../source/specifications/direct-url.rst:96 -msgid "A top-level ``subdirectory`` field MAY be present containing a directory path, relative to the root of the VCS repository, source archive or local directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." -msgstr "" - -#: ../source/specifications/direct-url.rst:102 -msgid "As a general rule, installers should as much as possible preserve the information that was provided in the requested URL when generating :file:`direct_url.json`. For example user:password environment variables should be preserved and ``requested_revision`` should reflect the revision that was provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``." -msgstr "" - -#: ../source/specifications/direct-url.rst:110 -msgid "Registered VCS" -msgstr "" - -#: ../source/specifications/direct-url.rst:112 -msgid "This section lists the registered VCS's; expanded, VCS-specific information on how to use the ``vcs``, ``requested_revision``, and other fields of ``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY support other VCS's although it is RECOMMENDED to register them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name (lowercased). Additional fields that would be necessary to support such VCS SHOULD be prefixed with the VCS command name." -msgstr "" - -#: ../source/specifications/direct-url.rst:122 -msgid "Git" -msgstr "" - -#: ../source/specifications/direct-url.rst:124 -#: ../source/specifications/direct-url.rst:156 -#: ../source/specifications/direct-url.rst:179 -#: ../source/specifications/direct-url.rst:202 -msgid "Home page" -msgstr "" - -#: ../source/specifications/direct-url.rst:126 -msgid "https://git-scm.com/" -msgstr "" - -#: ../source/specifications/direct-url.rst:128 -#: ../source/specifications/direct-url.rst:160 -#: ../source/specifications/direct-url.rst:183 -#: ../source/specifications/direct-url.rst:206 -msgid "vcs command" -msgstr "" - -#: ../source/specifications/direct-url.rst:130 -#: ../source/specifications/direct-url.rst:134 -msgid "git" -msgstr "" - -#: ../source/specifications/direct-url.rst:132 -#: ../source/specifications/direct-url.rst:164 -#: ../source/specifications/direct-url.rst:187 -#: ../source/specifications/direct-url.rst:210 -msgid "``vcs`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:136 -#: ../source/specifications/direct-url.rst:168 -#: ../source/specifications/direct-url.rst:191 -#: ../source/specifications/direct-url.rst:214 -msgid "``requested_revision`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:138 -msgid "A tag name, branch name, Git ref, commit hash, shortened commit hash, or other commit-ish." -msgstr "" - -#: ../source/specifications/direct-url.rst:141 -#: ../source/specifications/direct-url.rst:172 -#: ../source/specifications/direct-url.rst:195 -#: ../source/specifications/direct-url.rst:219 -msgid "``commit_id`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:143 -msgid "A commit hash (40 hexadecimal characters sha1)." -msgstr "" - -#: ../source/specifications/direct-url.rst:147 -msgid "Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to determine if the ``requested_revision`` corresponds to a Git ref. In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning with ``refs/remotes/origin/`` after cloning corresponds to a branch." -msgstr "" - -#: ../source/specifications/direct-url.rst:154 -msgid "Mercurial" -msgstr "" - -#: ../source/specifications/direct-url.rst:158 -msgid "https://www.mercurial-scm.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:162 -#: ../source/specifications/direct-url.rst:166 -msgid "hg" -msgstr "" - -#: ../source/specifications/direct-url.rst:170 -msgid "A tag name, branch name, changeset ID, shortened changeset ID." -msgstr "" - -#: ../source/specifications/direct-url.rst:174 -msgid "A changeset ID (40 hexadecimal characters)." -msgstr "" - -#: ../source/specifications/direct-url.rst:177 -msgid "Bazaar" -msgstr "" - -#: ../source/specifications/direct-url.rst:181 -msgid "https://bazaar.canonical.com/" -msgstr "" - -#: ../source/specifications/direct-url.rst:185 -#: ../source/specifications/direct-url.rst:189 -msgid "bzr" -msgstr "" - -#: ../source/specifications/direct-url.rst:193 -msgid "A tag name, branch name, revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:197 -msgid "A revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:200 -msgid "Subversion" -msgstr "" - -#: ../source/specifications/direct-url.rst:204 -msgid "https://subversion.apache.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:208 -#: ../source/specifications/direct-url.rst:212 -msgid "svn" -msgstr "" - -#: ../source/specifications/direct-url.rst:216 -msgid "``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. In Subversion, branch or tag is part of ``url``." -msgstr "" - -#: ../source/specifications/direct-url.rst:221 -msgid "Since Subversion does not support globally unique identifiers, this field is the Subversion revision number in the corresponding repository." -msgstr "" - -#: ../source/specifications/direct-url.rst:229 -msgid "Example direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:231 -msgid "Source archive:" -msgstr "" - -#: ../source/specifications/direct-url.rst:242 -msgid "Git URL with tag and commit-hash:" -msgstr "" - -#: ../source/specifications/direct-url.rst:255 -msgid "Local directory:" -msgstr "" - -#: ../source/specifications/direct-url.rst:264 -msgid "Local directory installed in editable mode:" -msgstr "" - -#: ../source/specifications/direct-url.rst:277 -msgid "Example pip commands and their effect on direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:279 -msgid "Commands that generate a ``direct_url.json``:" -msgstr "" - -#: ../source/specifications/direct-url.rst:281 -msgid "pip install https://example.com/app-1.0.tgz" -msgstr "" - -#: ../source/specifications/direct-url.rst:282 -msgid "pip install https://example.com/app-1.0.whl" -msgstr "" - -#: ../source/specifications/direct-url.rst:283 -msgid "pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\"" -msgstr "" - -#: ../source/specifications/direct-url.rst:284 -msgid "pip install ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:285 -msgid "pip install file:///home/user/app" -msgstr "" - -#: ../source/specifications/direct-url.rst:286 -msgid "pip install --editable \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" -msgstr "" - -#: ../source/specifications/direct-url.rst:290 -msgid "pip install -e ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:292 -msgid "Commands that *do not* generate a ``direct_url.json``" -msgstr "" - -#: ../source/specifications/direct-url.rst:294 -msgid "pip install app" -msgstr "" - -#: ../source/specifications/direct-url.rst:295 -msgid "pip install app --no-index --find-links https://example.com/" -msgstr "" - -#: ../source/specifications/entry-points.rst:5 -msgid "Entry points specification" -msgstr "" - -#: ../source/specifications/entry-points.rst:7 -msgid "*Entry points* are a mechanism for an installed distribution to advertise components it provides to be discovered and used by other code. For example:" -msgstr "" - -#: ../source/specifications/entry-points.rst:11 -msgid "Distributions can specify ``console_scripts`` entry points, each referring to a function. When *pip* (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point." -msgstr "" - -#: ../source/specifications/entry-points.rst:14 -msgid "Applications can use entry points to load plugins; e.g. Pygments (a syntax highlighting tool) can use additional lexers and styles from separately installed packages. For more about this, see :doc:`/guides/creating-and-discovering-plugins`." -msgstr "" - -#: ../source/specifications/entry-points.rst:19 -msgid "The entry point file format was originally developed to allow packages built with setuptools to provide integration point metadata that would be read at runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability specification in order to allow build tools other than setuptools to publish ``importlib.metadata`` compatible entry point metadata, and runtime libraries other than ``importlib.metadata`` to portably read published entry point metadata (potentially with different caching and conflict resolution strategies)." -msgstr "" - -#: ../source/specifications/entry-points.rst:28 -msgid "Data model" -msgstr "" - -#: ../source/specifications/entry-points.rst:30 -msgid "Conceptually, an entry point is defined by three required properties:" -msgstr "" - -#: ../source/specifications/entry-points.rst:32 -msgid "The **group** that an entry point belongs to indicates what sort of object it provides. For instance, the group ``console_scripts`` is for entry points referring to functions which can be used as a command, while ``pygments.styles`` is the group for classes defining pygments styles. The consumer typically defines the expected interface. To avoid clashes, consumers defining a new group should use names starting with a PyPI name owned by the consumer project, followed by ``.``. Group names must be one or more groups of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w+)*$``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:42 -msgid "The **name** identifies this entry point within its group. The precise meaning of this is up to the consumer. For console scripts, the name of the entry point is the command that will be used to launch it. Within a distribution, entry point names should be unique. If different distributions provide the same name, the consumer decides how to handle such conflicts. The name may contain any characters except ``=``, but it cannot start or end with any whitespace character, or start with ``[``. For new entry points, it is recommended to use only letters, numbers, underscores, dots and dashes (regex ``[\\w.-]+``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:51 -msgid "The **object reference** points to a Python object. It is either in the form ``importable.module``, or ``importable.module:object.attr``. Each of the parts delimited by dots and the colon is a valid Python identifier. It is intended to be looked up like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:64 -msgid "Some tools call this kind of object reference by itself an 'entry point', for want of a better term, especially where it points to a function to launch a program." -msgstr "" - -#: ../source/specifications/entry-points.rst:68 -msgid "There is also an optional property: the **extras** are a set of strings identifying optional features of the distribution providing the entry point. If these are specified, the entry point requires the dependencies of those 'extras'. See the metadata field :ref:`metadata_provides_extra`." -msgstr "" - -#: ../source/specifications/entry-points.rst:73 -msgid "Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools' model of managing 'egg' packages, but newer tools such as pip and virtualenv use a different model." -msgstr "" - -#: ../source/specifications/entry-points.rst:80 -msgid "File format" -msgstr "" - -#: ../source/specifications/entry-points.rst:82 -msgid "Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory described in :pep:`376` for installed distributions, and in :pep:`427` for wheels. The file uses the UTF-8 character encoding." -msgstr "" - -#: ../source/specifications/entry-points.rst:87 -msgid "The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, whereas entry point names are case sensitive. A case-sensitive config parser can be made like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:97 -msgid "The entry points file must always use ``=`` to delimit names from values (whereas configparser also allows using ``:``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:100 -msgid "The sections of the config file represent entry point groups, the names are names, and the values encode both the object reference and the optional extras. If extras are used, they are a comma-separated list inside square brackets." -msgstr "" - -#: ../source/specifications/entry-points.rst:104 -msgid "Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for extras is formally specified as part of :pep:`508` (as ``extras``). For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket." -msgstr "" - -#: ../source/specifications/entry-points.rst:112 -msgid "For example::" -msgstr "" - -#: ../source/specifications/entry-points.rst:124 -msgid "Use for scripts" -msgstr "" - -#: ../source/specifications/entry-points.rst:126 -msgid "Two groups of entry points have special significance in packaging: ``console_scripts`` and ``gui_scripts``. In both groups, the name of the entry point should be usable as a command in a system shell after the package is installed. The object reference points to a function which will be called with no arguments when this command is run. The function may return an integer to be used as a process exit code, and returning ``None`` is equivalent to returning ``0``." -msgstr "" - -#: ../source/specifications/entry-points.rst:134 -msgid "For instance, the entry point ``mycmd = mymod:main`` would create a command ``mycmd`` launching a script like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:141 -msgid "The difference between ``console_scripts`` and ``gui_scripts`` only affects Windows systems. ``console_scripts`` are wrapped in a console executable, so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI executable, so they can be started without a console, but cannot use standard streams unless application code redirects them. Other platforms do not have the same distinction." -msgstr "" - -#: ../source/specifications/entry-points.rst:149 -msgid "Install tools are expected to set up wrappers for both ``console_scripts`` and ``gui_scripts`` in the scripts directory of the install scheme. They are not responsible for putting this directory in the ``PATH`` environment variable which defines where command-line tools are found." -msgstr "" - -#: ../source/specifications/entry-points.rst:154 -msgid "As files are created from the names, and some filesystems are case-insensitive, packages should avoid using names in these groups which differ only in case. The behaviour of install tools when names differ only in case is undefined." -msgstr "" - -#: ../source/specifications/index.rst:4 -msgid "PyPA specifications" -msgstr "" - -#: ../source/specifications/index.rst:6 -msgid "This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on `pypa.io `__." -msgstr "" - -#: ../source/specifications/index.rst:13 -msgid "Package Distribution Metadata" -msgstr "" - -#: ../source/specifications/index.rst:30 -msgid "Package Distribution File Formats" -msgstr "" - -#: ../source/specifications/index.rst:40 -msgid "Package Index Interfaces" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:6 -msgid "Platform compatibility tags" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:8 -msgid "Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:12 -msgid "The platform compatibility tagging model used for the ``wheel`` distribution format is defined in :pep:`425`." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:16 -msgid "Platform tags for Windows" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:18 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running Windows." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:22 -msgid "Platform tags for macOS (Mac OS X)" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:24 -msgid "The scheme defined in :pep:`425` covers public distribution of wheel files to systems running macOS (previously known as Mac OS X)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:28 -msgid "Platform tags for common Linux distributions" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:32 -msgid "The scheme defined in :pep:`425` is insufficient for public distribution of wheel files (and \\*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:36 -msgid "Instead, :pep:`600` defines the ``manylinux`` standard, which represents a common subset of Linux platforms, and allows building wheels tagged with the ``manylinux`` platform tag which can be used across most common Linux distributions." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:41 -msgid "There were multiple iterations of the ``manylinux`` specification, each representing the common subset of Linux platforms at a given point in time:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:44 -msgid "``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, and is based on a compatible Linux platform from 2007." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:46 -msgid "``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` architectures. and updates the previous specification to be based on a compatible Linux platform from 2010 instead." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:49 -msgid "``manylinux2014`` (:pep:`599`) adds support for a number of additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``) and updates the base platform to a compatible Linux platform from 2014." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:54 -msgid "``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a future-proof standard. It defines ``x`` and ``y`` as glibc major an minor versions supported (e.g. ``manylinux_2_24`` should work on any distro using glibc 2.24+). Previous tags are still supported for backward compatibility." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:59 -msgid "In general, distributions built for older versions of the specification are forwards-compatible (meaning that ``manylinux1`` distributions should continue to work on modern systems) but not backwards-compatible (meaning that ``manylinux2010`` distributions are not expected to work on platforms that existed before 2010)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:65 -msgid "Package maintainers should attempt to target the most compatible specification possible, with the caveat that the provided build environment for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that these images will no longer receive security updates." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:71 -msgid "Manylinux compatibility support" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:74 -msgid "The ``manylinux2014`` specification is relatively new and is not yet widely recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:76 -msgid "The ``manylinux_x_y`` specification is relatively new and is not yet widely recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:79 -msgid "The following table shows the minimum versions of relevant projects to support the various ``manylinux`` standards:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "Tool" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux1``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2010``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2014``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux_x_y``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=8.1.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=20.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "auditwheel" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=1.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=2.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.3.0`` [#]_" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:90 -msgid "Platform tags for other \\*nix platforms" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:92 -msgid "The scheme defined in :pep:`425` is not generally sufficient for public distribution of wheel files to other \\*nix platforms. Efforts are currently (albeit intermittently) under way to define improved compatibility tagging schemes for AIX and for Alpine Linux." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:98 -msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" -msgstr "" - -#: ../source/specifications/pypirc.rst:6 -msgid "The :file:`.pypirc` file" -msgstr "" - -#: ../source/specifications/pypirc.rst:8 -msgid "A :file:`.pypirc` file allows you to define the configuration for :term:`package indexes ` (referred to here as \"repositories\"), so that you don't have to enter the URL, username, or password whenever you upload a package with :ref:`twine` or :ref:`flit`." -msgstr "" - -#: ../source/specifications/pypirc.rst:13 -msgid "The format (originally defined by the :ref:`distutils` package) is:" -msgstr "" - -#: ../source/specifications/pypirc.rst:32 -msgid "The ``distutils`` section defines an ``index-servers`` field that lists the name of all sections describing a repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:35 -msgid "Each section describing a repository defines three fields:" -msgstr "" - -#: ../source/specifications/pypirc.rst:37 -msgid "``repository``: The URL of the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:38 -msgid "``username``: The registered username on the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:39 -msgid "``password``: The password that will used to authenticate the username." -msgstr "" - -#: ../source/specifications/pypirc.rst:43 -msgid "Be aware that this stores your password in plain text. For better security, consider an alternative like `keyring`_, setting environment variables, or providing the password on the command line." -msgstr "" - -#: ../source/specifications/pypirc.rst:47 -msgid "Otherwise, set the permissions on :file:`.pypirc` so that only you can view or modify it. For example, on Linux or macOS, run:" -msgstr "" - -#: ../source/specifications/pypirc.rst:57 -msgid "Common configurations" -msgstr "" - -#: ../source/specifications/pypirc.rst:61 -msgid "These examples apply to :ref:`twine`, and projects like :ref:`hatch` that use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions." -msgstr "" - -#: ../source/specifications/pypirc.rst:66 -msgid "Twine's default configuration mimics a :file:`.pypirc` with repository sections for PyPI and TestPyPI:" -msgstr "" - -#: ../source/specifications/pypirc.rst:82 -msgid "Twine will add additional configuration from :file:`$HOME/.pypirc`, the command line, and environment variables to this default configuration." -msgstr "" - -#: ../source/specifications/pypirc.rst:86 -msgid "Using a PyPI token" -msgstr "" - -#: ../source/specifications/pypirc.rst:88 -msgid "To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` similar to:" -msgstr "" - -#: ../source/specifications/pypirc.rst:97 -msgid "For :ref:`TestPyPI `, add a ``[testpypi]`` section, using the API token from your TestPyPI account." -msgstr "" - -#: ../source/specifications/pypirc.rst:103 -msgid "Using another package index" -msgstr "" - -#: ../source/specifications/pypirc.rst:105 -msgid "To configure an additional repository, you'll need to redefine the ``index-servers`` field to include the repository name. Here is a complete example of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" -msgstr "" - -#: ../source/specifications/pypirc.rst:132 -msgid "Instead of using the ``password`` field, consider saving your API tokens and passwords securely using `keyring`_ (which is installed by Twine):" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:5 -msgid "Recording installed projects" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:7 -msgid "This document specifies a common format of recording information about Python :term:`projects ` installed in an environment. A common metadata format allows tools to query, manage or uninstall projects, regardless of how they were installed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:12 -msgid "Almost all information is optional. This allows tools outside the Python ecosystem, such as Linux package managers, to integrate with Python tooling as much as possible. For example, even if an installer cannot easily provide a list of installed files in a format specific to Python tooling, it should still record the name and version of the installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:21 -msgid "History and change workflow" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:23 -msgid "The metadata described here was first specified in :pep:`376`, and later amended in :pep:`627`. It was formerly known as *Database of Installed Python Distributions*. Further amendments (except trivial language or typography fixes) must be made through the PEP process (see :pep:`1`)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:29 -msgid "While this document is the normative specification, these PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:37 -msgid "Each project installed from a distribution must, in addition to files, install a \"``.dist-info``\" directory located alongside importable modules and packages (commonly, the ``site-packages`` directory)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:41 -msgid "This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) chacaters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:50 -msgid "Historically, tools have failed to replace dot characters or normalize case in the ``name`` field, or not perform normalization in the ``version`` field. Tools consuming ``.dist-info`` directories should expect those fields to be unnormalized, and treat them as equivalent to their normalized counterparts. New tools that write ``.dist-info`` directories MUST normalize both ``name`` and ``version`` fields using the rules described above, and existing tools are encouraged to start normalizing those fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:60 -msgid "The ``.dist-info`` directory's name is formatted to unambigiously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:69 -msgid "This ``.dist-info`` directory can contain these files, described in detail below:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:72 -msgid "``METADATA``: contains project metadata" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:73 -msgid "``RECORD``: records the list of installed files." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:74 -msgid "``INSTALLER``: records the name of the tool used to install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:76 -msgid "The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. Additional installer-specific files may be present." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:82 -msgid "The :ref:`binary-distribution-format` specification describes additional files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. Such files may be copied to the ``.dist-info`` directory of an installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:87 -msgid "The previous versions of this specification also specified a ``REQUESTED`` file. This file is now considered a tool-specific extension, but may be standardized again in the future. See `PEP 376 `_ for its original meaning." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:94 -msgid "The METADATA file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:96 -msgid "The ``METADATA`` file contains metadata as described in the :ref:`core-metadata` specification, version 1.1 or greater." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:99 -msgid "The ``METADATA`` file is mandatory. If it cannot be created, or if required core metadata is not available, installers must report an error and fail to install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:105 -msgid "The RECORD file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:107 -msgid "The ``RECORD`` file holds the list of installed files. It is a CSV file containing one record (line) per installed file." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:110 -msgid "The CSV dialect must be readable with the default ``reader`` of Python's ``csv`` module:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:113 -msgid "field delimiter: ``,`` (comma)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:114 -msgid "quoting char: ``\"`` (straight double quote)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:115 -msgid "line terminator: either ``\\r\\n`` or ``\\n``." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:117 -msgid "Each record is composed of three elements: the file's **path**, the **hash** of the contents, and its **size**." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:120 -msgid "The *path* may be either absolute, or relative to the directory containing the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On Windows, directories may be separated either by forward- or backslashes (``/`` or ``\\``)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:125 -msgid "The *hash* is either an empty string or the name of a hash algorithm from ``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and the digest of the file's contents, encoded with the urlsafe-base64-nopad encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:130 -msgid "The *size* is either the empty string, or file's size in bytes, as a base 10 integer." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:133 -msgid "For any file, either or both of the *hash* and *size* fields may be left empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself have empty *hash* and *size*. For other files, leaving the information out is discouraged, as it prevents verifying the integrity of the installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:139 -msgid "If the ``RECORD`` file is present, it must list all installed files of the project, except ``.pyc`` files corresponding to ``.py`` files listed in ``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` directory (including the ``RECORD`` file itself) must be listed. Directories should not be listed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:146 -msgid "To completely uninstall a package, a tool needs to remove all files listed in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding to removed ``.py`` files, and any directories emptied by the uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:151 -msgid "Here is an example snippet of a possible ``RECORD`` file::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:170 -msgid "If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not atempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.)" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:177 -msgid "The INSTALLER file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:179 -msgid "If present, ``INSTALLER`` is a single-line text file naming the tool used to install the project. If the installer is executable from the command line, ``INSTALLER`` should contain the command name. Otherwise, it should contain a printable ASCII string." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:185 -msgid "The file can be terminated by zero or more ASCII whitespace characters." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:187 -msgid "Here are examples of two possible ``INSTALLER`` files::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:195 -msgid "This value should be used for informational purposes only. For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:201 -msgid "The direct_url.json file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:203 -msgid "This file MUST be created by installers when installing a distribution from a requirement specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:209 -msgid "Its detailed specification is at :ref:`direct-url`." -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:6 -msgid "Simple repository API" -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:8 -msgid "The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of \"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` and specifying the interface version provided by an index server in :pep:`629`." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:6 -msgid "Source distribution format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:8 -msgid "The current standard format of source distribution format is identified by the presence of a :file:`pyproject.toml` file in the distribution archive. The layout of such a distribution was originally specified in :pep:`517` and is formally documented here." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:13 -msgid "There is also the legacy source distribution format, implicitly defined by the behaviour of ``distutils`` module in the standard library, when executing :command:`setup.py sdist`. This document does not attempt to standardise this format, except to note that if a legacy source distribution contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it MUST follow the rules applicable to source distributions defined in the metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:21 -msgid "Source distributions are also known as *sdists* for short." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:24 -msgid "Source distribution file name" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:26 -msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:31 -msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:35 -msgid "Source distribution file format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:37 -msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:45 -msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:48 -msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:6 -msgid "Version specifiers" -msgstr "" - -#: ../source/specifications/version-specifiers.rst:8 -msgid "Version numbering requirements and the semantics for specifying comparisons between versions are defined in :pep:`440`." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:11 -msgid "The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`." -msgstr "" - -#: ../source/support.rst:3 -msgid "How to Get Support" -msgstr "" - -#: ../source/support.rst:5 -msgid "For support related to a specific project, see the links on the :doc:`Projects ` page." -msgstr "" - -#: ../source/support.rst:8 -msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:5 -msgid "Creating Documentation" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:7 -msgid "This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:13 -msgid "Installing Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:14 -msgid "Use ``pip`` to install Sphinx:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:28 -msgid "For other installation methods, see this `installation guide`_ by Sphinx." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:33 -msgid "Getting Started With Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:35 -msgid "Create a ``docs`` directory inside your project to hold your documentation:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:42 -msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:49 -msgid "This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:51 -msgid "You can add some information about your project in ``index.rst``, then build them:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:57 -msgid "For more details on the build process, see this `guide`_ by Read The Docs." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:62 -msgid "Other Sources" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:64 -msgid "For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/index.rst:4 -msgid "**Tutorials** are opinionated step-by-step guides to help you get familiar with packaging concepts. For more detailed information on specific packaging topics, see :doc:`/guides/index`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:5 -msgid "Installing Packages" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:7 -msgid "This section covers the basics of how to install Python :term:`packages `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:10 -msgid "It's important to note that the term \"package\" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a :term:`distribution `). It does not to refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term \"package\". Using the term \"distribution\" is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:28 -msgid "Requirements for Installing Packages" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:30 -msgid "This section describes the steps to follow before installing other Python packages." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:35 -msgid "Ensure you can run Python from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:37 -msgid "Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:53 -msgid "You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the `Installing Python`_ section of the Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:57 -msgid "If you're a newcomer and you get an error like this:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:66 -msgid "It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or *console*). See the Python for Beginners `getting started tutorial`_ for an introduction to using your operating system's shell and interacting with Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:72 -msgid "If you're using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ``!`` character:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:82 -msgid "It's recommended to write ``{sys.executable}`` rather than plain ``python`` in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the ``python`` command refers to)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:87 -msgid "Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the ``python`` command in this tutorial with ``python3`` and the ``python -m pip`` command with ``python3 -m pip --user``. Do *not* run any of the commands in this tutorial with ``sudo``: if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:99 -msgid "Ensure you can run pip from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:101 -msgid "Additionally, you'll need to make sure you have :ref:`pip` available. You can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:116 -msgid "If you installed Python from source, with an installer from `python.org`_, or via `Homebrew`_ you should already have pip. If you're on Linux and installed using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:124 -msgid "If ``pip`` isn't already installed, then first try to bootstrap it from the standard library:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:139 -msgid "If that still doesn't allow you to run ``python -m pip``:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:141 -msgid "Securely Download `get-pip.py `_ [1]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:144 -msgid "Run ``python get-pip.py``. [2]_ This will install or upgrade pip. Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're not installed already." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:150 -msgid "Be cautious if you're using a Python install that's managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/local`` which is designed for locally-installed software." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:159 -msgid "Ensure pip, setuptools, and wheel are up to date" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:161 -msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:169 -msgid "Optionally, create a virtual environment" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:171 -msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:188 -msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:195 -msgid "Creating Virtual Environments" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:197 -msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:203 -msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:209 -msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:213 -msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:216 -msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:220 -msgid "Currently, there are two common tools for creating Python virtual environments:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:222 -msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:225 -msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:230 -msgid "The basic usage is like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:232 -msgid "Using `venv`_:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:248 -msgid "Using :ref:`virtualenv`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:264 -msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:266 -msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:271 -msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:281 -msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:288 -msgid "Use pip for Installing" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:290 -msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:297 -msgid "Installing from PyPI" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:299 -msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:307 -msgid "To install the latest version of \"SomeProject\":" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:321 -msgid "To install a specific version:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:335 -msgid "To install greater than or equal to one version and less than another:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:350 -msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:365 -msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:370 -msgid "Source Distributions vs Wheels" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:372 -msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:378 -msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:383 -msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:391 -msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:408 -msgid "Installing to the User Site" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:410 -msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:425 -msgid "For more information see the `User Installs `_ section from the pip docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:429 -msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:432 -msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:440 -msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:446 -msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:462 -msgid "Install a list of requirements specified in a :ref:`Requirements File `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:478 -msgid "Installing from VCS" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:480 -msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:502 -msgid "Installing from other Indexes" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:504 -msgid "Install from an alternate index" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:518 -msgid "Search an additional index during install, in addition to :term:`PyPI `" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:534 -msgid "Installing from a local src tree" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:537 -msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:554 -msgid "You can also install normally from src" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:571 -msgid "Install a particular source archive file." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:585 -msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:605 -msgid "Installing from other sources" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:607 -msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:619 -msgid "Installing Prereleases" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:621 -msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:637 -msgid "Installing Setuptools \"Extras\"" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:639 -msgid "Install `setuptools extras`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:659 -msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:668 -msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:673 -msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:4 -msgid "Managing Application Dependencies" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:6 -msgid "The :ref:`package installation tutorial ` covered the basics of getting set up to install and update Python packages." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:9 -msgid "However, running these commands interactively can get tedious even for your own personal projects, and things get even more difficult when trying to set up development environments automatically for projects with multiple contributors." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:13 -msgid "This tutorial walks you through the use of :ref:`Pipenv` to manage dependencies for an application. It will show you how to install and use the necessary tools and make strong recommendations on best practices." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:17 -msgid "Keep in mind that Python is used for a great many different purposes, and precisely how you want to manage your dependencies may change based on how you decide to publish your software. The guidance presented here is most directly applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:24 -msgid "Developers of Python libraries, or of applications that support distribution as Python libraries, should also consider the `poetry `_ project as an alternative dependency management solution." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:30 -msgid "Installing Pipenv" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:32 -msgid ":ref:`Pipenv` is a dependency manager for Python projects. If you're familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit to those tools. While :ref:`pip` alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it's a higher-level tool that simplifies dependency management for common use cases." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:38 -msgid "Use ``pip`` to install Pipenv:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:54 -msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:65 -msgid "Installing packages for your project" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:67 -msgid "Pipenv manages dependencies on a per-project basis. To install packages, change into your project's directory (or just an empty directory for this tutorial) and run:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:76 -msgid "Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you in your project's directory. The :ref:`Pipfile` is used to track which dependencies your project needs in case you need to re-install them, such as when you share your project with others. You should get output similar to this (although the exact paths shown will vary):" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:112 -msgid "Using installed packages" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:114 -msgid "Now that Requests is installed you can create a simple :file:`main.py` file to use it:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:125 -msgid "Then you can run this script using ``pipenv run``:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:131 -msgid "You should get output similar to this:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:137 -msgid "Using ``pipenv run`` ensures that your installed packages are available to your script. It's also possible to spawn a new shell that ensures all commands have access to your installed packages with ``pipenv shell``." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:143 -#: ../source/tutorials/packaging-projects.rst:594 -msgid "Next steps" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:145 -msgid "Congratulations, you now know how to effectively manage dependencies and development environments on a collaborative Python project! ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:148 -msgid "If you're interested in creating and distributing your own Python packages, see the :ref:`tutorial on packaging and distributing packages `." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:151 -msgid "Note that when your application includes definitions of Python source packages, they (and their dependencies) can be added to your ``pipenv`` environment with ``pipenv install -e `` (e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:160 -msgid "Other Tools for Application Dependency Management" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:162 -msgid "If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques to see if one of them is a better fit:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:166 -msgid "`poetry `__ for a tool comparable in scope to ``pipenv`` that focuses more directly on use cases where the repository being managed is structured as a Python project with a valid ``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making the assumption that the application being worked on that's depending on components from PyPI will itself support distribution as a ``pip``-installable Python package)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:172 -msgid "`hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates)" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:175 -msgid "`pip-tools `_ to build your own custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:177 -msgid "`micropipenv `_ is a lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or converting them to pip-tools compatible output. Designed for containerized Python applications but not limited to them." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:2 -msgid "Packaging Python Projects" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:4 -msgid "This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:10 -msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:18 -msgid "Some of the commands require a newer version of :ref:`pip`, so start by making sure you have the latest version installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:35 -msgid "A simple project" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:37 -msgid "This tutorial uses a simple project named ``example_package``. We recommend following this tutorial as-is using this project, before packaging your own project." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:41 -msgid "Create the following file structure locally:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:51 -msgid ":file:`__init__.py` is required to import the directory as a package, and should be empty." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:54 -msgid ":file:`example.py` is an example of a module within the package that could contain the logic (functions, classes, constants, etc.) of your package. Open that file and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:63 -msgid "If you are unfamiliar with Python's :term:`modules ` and :term:`import packages `, take a few minutes to read over the `Python documentation for packages and modules`_." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:67 -msgid "Once you create this structure, you'll want to run all of the commands in this tutorial within the ``packaging_tutorial`` directory." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:75 -msgid "Creating the package files" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:77 -msgid "You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:95 -msgid "Creating a test directory" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:97 -msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:101 -msgid "Creating pyproject.toml" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:103 -msgid ":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) what is required to build your project. This tutorial uses :ref:`setuptools`, so open :file:`pyproject.toml` and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:117 -msgid "``build-system.requires`` gives a list of packages that are needed to build your package. Listing something here will *only* make it available during the build, not after it is installed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:121 -msgid "``build-system.build-backend`` is the name of Python object that will be used to perform the build. If you were to use a different build system, such as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration details would be completely different than the :ref:`setuptools` configuration described below." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:127 -msgid "See :pep:`517` and :pep:`518` for background and details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:131 -msgid "Configuring metadata" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:133 -msgid "There are two types of metadata: static and dynamic." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:135 -msgid "Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:137 -msgid "Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go into :file:`setup.py`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:141 -msgid "Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to be required, but can be omitted with newer versions of setuptools and pip." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:148 -msgid ":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to :file:`pyproject.toml`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:153 -msgid "Open :file:`setup.cfg` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:185 -msgid "There are a `variety of metadata and options `_ supported here. This is in :doc:`configparser ` format; do not place quotes around values. This example package uses a relatively minimal set of ``metadata``:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:191 -#: ../source/tutorials/packaging-projects.rst:286 -msgid "``name`` is the *distribution name* of your package. This can be any name as long as it only contains letters, numbers, ``_`` , and ``-``. It also must not already be taken on pypi.org. **Be sure to update this with your username,** as this ensures you won't try to upload a package with the same name as one which already exists." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:196 -msgid "``version`` is the package version. See :pep:`440` for more details on versions. You can use ``file:`` or ``attr:`` directives to read from a file or package attribute." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:199 -#: ../source/tutorials/packaging-projects.rst:293 -msgid "``author`` and ``author_email`` are used to identify the author of the package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:201 -#: ../source/tutorials/packaging-projects.rst:295 -msgid "``description`` is a short, one-sentence summary of the package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:202 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md` (which is a common pattern) using the ``file:`` directive." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:206 -#: ../source/tutorials/packaging-projects.rst:300 -msgid "``long_description_content_type`` tells the index what type of markup is used for the long description. In this case, it's Markdown." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:208 -#: ../source/tutorials/packaging-projects.rst:302 -msgid "``url`` is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:211 -#: ../source/tutorials/packaging-projects.rst:305 -msgid "``project_urls`` lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:213 -#: ../source/tutorials/packaging-projects.rst:307 -msgid "``classifiers`` gives the index and :ref:`pip` some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:221 -msgid "In the ``options`` category, we have controls for setuptools itself:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:223 -msgid "``package_dir`` is a mapping of package names and directories. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:227 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use the ``find:`` directive to automatically discover all packages and subpackages and ``options.packages.find`` to specify the ``package_dir`` to use. In this case, the list of packages will be ``example_package`` as that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:234 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:238 -#: ../source/tutorials/packaging-projects.rst:329 -msgid "There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:244 -msgid ":file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools about your package (such as the name and version) as well as which code files to include." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:248 -msgid "Open :file:`setup.py` and enter the following content. Change the ``name`` to include your username; this ensures that you have a unique package name and that your package doesn't conflict with packages uploaded by other people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:283 -msgid ":func:`setup` takes several arguments. This example package uses a relatively minimal set:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:291 -msgid "``version`` is the package version. See :pep:`440` for more details on versions." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:296 -msgid "``long_description`` is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from :file:`README.md`, which is a common pattern." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:314 -msgid "``package_dir`` is a dictionary with package names for keys and directories for values. An empty package name represents the \"root package\" --- the directory in the project that contains all Python source files for the package --- so in this case the ``src`` directory is designated the root package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:319 -msgid "``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package `. Instead of listing each package manually, we can use :func:`find_packages` to automatically discover all packages and subpackages under ``package_dir``. In this case, the list of packages will be ``example_package`` as that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:325 -msgid "``python_requires`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back though older versions of packages until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:333 -msgid "Creating README.md" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:335 -msgid "Open :file:`README.md` and enter the following content. You can customize this if you'd like." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:347 -msgid "Because our configuration loads :file:`README.md` to provide a ``long_description``, :file:`README.md` must be included along with your code when you :ref:`generate a source distribution `. Newer versions of :ref:`setuptools` will do this automatically." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:354 -msgid "Creating a LICENSE" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:356 -msgid "It's important for every package uploaded to the Python Package Index to include a license. This tells users who install your package the terms under which they can use your package. For help picking a license, see https://choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` and enter the license text. For example, if you had chosen the MIT license:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:387 -msgid "Including other files" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:389 -msgid "The files listed above will be included automatically in your :term:`source distribution `. If you want to control what goes in this explicitly, see :ref:`Using MANIFEST.in`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:393 -msgid "The final :term:`built distribution ` will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see :doc:`Including Data Files ` from the :doc:`setuptools docs `." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:402 -msgid "Generating distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:404 -msgid "The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:408 -msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:422 -msgid "If you have trouble installing these, see the :doc:`installing-packages` tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:425 -msgid "Now run this command from the same directory where :file:`pyproject.toml` is located:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:439 -msgid "This command should output a lot of text and once completed should generate two files in the :file:`dist` directory:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:449 -msgid "The ``tar.gz`` file is a :term:`source archive ` whereas the ``.whl`` file is a :term:`built distribution `. Newer :ref:`pip` versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:458 -msgid "Uploading the distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:460 -msgid "Finally, it's time to upload your package to the Python Package Index!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:462 -msgid "The first thing you'll need to do is register an account on TestPyPI, which is a separate instance of the package index intended for testing and experimentation. It's great for things like this tutorial where we don't necessarily want to upload to the real index. To register an account, go to https://test.pypi.org/account/register/ and complete the steps on that page. You will also need to verify your email address before you're able to upload any packages. For more details, see :doc:`/guides/using-testpypi`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:470 -msgid "To securely upload your project, you'll need a PyPI `API token`_. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" to \"Entire account\". **Don't close the page until you have copied and saved the token — you won't see that token again.**" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:477 -msgid "Now that you are registered, you can use :ref:`twine` to upload the distribution packages. You'll need to install Twine:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:492 -msgid "Once installed, run Twine to upload all of the archives under :file:`dist`:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:506 -msgid "You will be prompted for a username and password. For the username, use ``__token__``. For the password, use the token value, including the ``pypi-`` prefix." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:510 -msgid "After the command completes, you should see output similar to this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:523 -msgid "Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:528 -msgid "Installing your newly uploaded package" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:530 -msgid "You can use :ref:`pip` to install your package and verify that it works. Create a :ref:`virtual environment ` and install your package from TestPyPI:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:546 -msgid "Make sure to specify your username in the package name!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:548 -msgid "pip should install the package from TestPyPI and the output should look something like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:558 -msgid "This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have the same packages as the live PyPI, it's possible that attempting to install dependencies may fail or install something unexpected. While our example package doesn't have any dependencies, it's a good practice to avoid installing dependencies when using TestPyPI." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:565 -msgid "You can test that it was installed correctly by importing the package. Make sure you're still in your virtual environment, then run Python:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:580 -msgid "and import the package:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:588 -msgid "Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``)." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:596 -msgid "**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:599 -msgid "Keep in mind that this tutorial showed you how to upload your package to Test PyPI, which isn't a permanent storage. The Test system occasionally deletes packages and accounts. It is best to use TestPyPI for testing and experiments like this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:604 -msgid "When you are ready to upload a real package to the Python Package Index you can do much the same as you did in this tutorial, but with these important differences:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:608 -msgid "Choose a memorable and unique name for your package. You don't have to append your username as you did in the tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:610 -msgid "Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:613 -msgid "Use ``twine upload dist/*`` to upload your package and enter your credentials for the account you registered on the real PyPI. Now that you're uploading the package in production, you don't need to specify ``--repository``; the package will upload to https://pypi.org/ by default." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:617 -msgid "Install your package from the real PyPI using ``python3 -m pip install [your-package]``." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:619 -msgid "At this point if you want to read more on packaging Python libraries here are some things you can do:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:622 -msgid "Read more about using :ref:`setuptools` to package libraries in :doc:`/guides/distributing-packages-using-setuptools`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:624 -msgid "Read about :doc:`/guides/packaging-binary-extensions`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:625 -msgid "Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`." -msgstr "" diff --git a/locales/uk/LC_MESSAGES/messages.po b/locales/uk/LC_MESSAGES/messages.po deleted file mode 100644 index 352d4f221..000000000 --- a/locales/uk/LC_MESSAGES/messages.po +++ /dev/null @@ -1,13763 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2013–2020, PyPA -# This file is distributed under the same license as the Python Packaging User Guide package. -# Alex Solonenko , 2021. -# Sviatoslav Sydorenko , 2021. -# meowmeowmeowcat , 2021. -# Tymofii Lytvynenko , 2021. -# Olexandr , 2021. -msgid "" -msgstr "" -"Project-Id-Version: Python Packaging User Guide\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-11-07 16:11+0000\n" -"Last-Translator: Tymofii Lytvynenko \n" -"Language-Team: Ukrainian \n" -"Language: uk\n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=UTF-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && n" -"%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n" -"X-Generator: Weblate 4.9-dev\n" - -#: ../source/contribute.rst:5 -msgid "Contribute to this guide" -msgstr "Зробіть внесок до керівництва" - -#: ../source/contribute.rst:7 -msgid "" -"The |PyPUG| welcomes contributors! There are lots of ways to help out, " -"including:" -msgstr "" -"|PyPUG| запрошує контриб'юторів! Тут є багато способів, щоб допомогти, " -"зокрема:" - -#: ../source/contribute.rst:10 -msgid "Reading the guide and giving feedback" -msgstr "Читання керівництва і надання відгуку" - -#: ../source/contribute.rst:11 -msgid "Reviewing new contributions" -msgstr "Оцінювання нових вкладів" - -#: ../source/contribute.rst:12 -msgid "Revising existing content" -msgstr "Вивірення існуючого вмісту" - -#: ../source/contribute.rst:13 -msgid "Writing new content" -msgstr "Написання нового вмісту" - -#: ../source/contribute.rst:15 -msgid "" -"Most of the work on the |PyPUG| takes place on the `project's GitHub " -"repository`__. To get started, check out the list of `open issues`__ and " -"`pull requests`__. If you're planning to write or edit the guide, please " -"read the :ref:`style guide `." -msgstr "" -"Переважна більшість роботи над |PyPUG| відбувається у `репозиторії проєкту " -"на GitHub `__. Аби розпочати, ознайомтеся з " -"переліком `відкритих іш'ю `__ та `пул реквестів `" -"__. Якщо ви збираєтеся написати статтю чи відредагувати це керівництво, будь " -"ласка, прочитайте наше :ref:`керівництво зі стилю " -"`." - -#: ../source/contribute.rst:24 -msgid "" -"By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of " -"Conduct`__." -msgstr "" -"Здійснюючи внесок до |PyPUG|, від вас очікуватиметься слідування `кодексу " -"честі `__ PSF." - -#: ../source/contribute.rst:31 -msgid "Documentation types" -msgstr "Типи документації" - -#: ../source/contribute.rst:33 -msgid "" -"This project consists of four distinct documentation types with specific " -"purposes. When proposing new additions to the project please pick the " -"appropriate documentation type." -msgstr "" -"Цей проєкт містить чотири ясно виражені типи документації із чіткими " -"призначеннями. Пропонуючи нові доповнення до проєкту, будь ласка, оберіть " -"відповідний вид документації." - -#: ../source/contribute.rst:38 ../source/tutorials/index.rst:2 -msgid "Tutorials" -msgstr "Навчальні інструкції" - -#: ../source/contribute.rst:40 -msgid "" -"Tutorials are focused on teaching the reader new concepts by accomplishing a " -"goal. They are opinionated step-by-step guides. They do not include " -"extraneous warnings or information. `example tutorial-style document`_." -msgstr "" -"Навчальні інструкції зосереджені на навчанні читача нових концептів шляхом " -"досягнення цілі. Це упевнені керівництва у вигляді крок-за-кроком. Вони не " -"містять додаткових попереджень чи інформації. `приклад документу у стилі " -"навчальної інструкції `_." - -#: ../source/contribute.rst:47 ../source/guides/index.rst:2 -msgid "Guides" -msgstr "Керівництва" - -#: ../source/contribute.rst:49 -msgid "" -"Guides are focused on accomplishing a specific task and can assume some " -"level of pre-requisite knowledge. These are similar to tutorials, but have a " -"narrow and clear focus and can provide lots of caveats and additional " -"information as needed. They may also discuss multiple approaches to " -"accomplishing the task. :doc:`example guide-style document `." -msgstr "" -"Керівництва зосереджені на досягненні конкретного завдання і можуть " -"покладатися на деякий рівень заздалегідь наявних знань. Вони подібні до " -"навчальних інструкцій, але мають вужчий та чіткіший фокус, а також можуть " -"перелічувати багато застережень й додаткової інформації де потрібно. Крім " -"того, керівництва можуть розбирати багато підходів до вирішення цього " -"завдання. :doc:`приклад документу у стилі керівництва `." - -#: ../source/contribute.rst:56 ../source/discussions/index.rst:2 -msgid "Discussions" -msgstr "Обговорення" - -#: ../source/contribute.rst:58 -msgid "" -"Discussions are focused on understanding and information. These explore a " -"specific topic without a specific goal in mind. :doc:`example discussion-" -"style document `." -msgstr "" -"Обговорення зосереджені на роз'ясненні розумінні й інформації. Вони " -"досліджують конкретну тему, не маючи на меті нічого конкретного. :doc:`" -"приклад документу в стилі обговорення `." - -#: ../source/contribute.rst:63 -msgid "Specifications" -msgstr "Специфікації" - -#: ../source/contribute.rst:65 -msgid "" -"Specifications are reference documention focused on comprehensively " -"documenting an agreed-upon interface for interoperability between packaging " -"tools. :doc:`example specification-style document `." -msgstr "" -"Специфікації — це довідкова документація, орієнтована на всебічне " -"документування погодженого інтерфейсу сумісності засобів пакування. :doc:`" -"приклад документу в стилі специфікації `." - -#: ../source/contribute.rst:73 -msgid "Building the guide locally" -msgstr "Збирання цього керівництва локально" - -#: ../source/contribute.rst:75 -msgid "" -"Though not required to contribute, it may be useful to build this guide " -"locally in order to test your changes. In order to build this guide locally, " -"you'll need:" -msgstr "" -"Хоча це й не вимагається для внесення вкладів, збирання цього керівництва " -"локально може бути корисним аби протестувати свої зміни. Щоб зібрати це " -"керівництво локально, вам знадобиться:" - -#: ../source/contribute.rst:79 -msgid "" -"`Nox `_. You can install or upgrade " -"nox using ``pip``::" -msgstr "" -"`Nox `_. Ви можете встановити чи " -"оновити nox за допомогою ``pip``::" - -#: ../source/contribute.rst:84 -msgid "" -"Python 3.6. Our build scripts are designed to work with Python 3.6 only. See " -"the `Hitchhiker's Guide to Python installation instructions`_ to install " -"Python 3.6 on your operating system." -msgstr "" -"Python 3.6. Наші скрипти збирання спроєктовані, щоб працювати лише із Python " -"3.6. Скористайтеся `керівництвом автостопера по інструкціях встановлення " -"Python `_, аби " -"встановити Python 3.6 у вашій операційній системі." - -#: ../source/contribute.rst:91 -msgid "" -"To build the guide, run the following bash command in the source folder::" -msgstr "" -"Для збирання цього керівництва запустіть нижченаведену команду bash у " -"директорії із джерельним кодом::" - -#: ../source/contribute.rst:95 -msgid "" -"After the process has completed you can find the HTML output in the ``./" -"build/html`` directory. You can open the ``index.html`` file to view the " -"guide in web browser, but it's recommended to serve the guide using an HTTP " -"server." -msgstr "" -"По завершенню процесу, ви можете знайти результуючий HTML у теці ``./build/" -"html``. Ви можете відкрити файл ``index.html`` для перегляду цього " -"керівництва у веб-оглядачі, втім рекомендується отримувати доступ до " -"керівництва через HTTP сервер." - -#: ../source/contribute.rst:100 -msgid "" -"You can build the guide and serve it via an HTTP server using the following " -"command::" -msgstr "" -"Ви можете зібрати керівництво і організувати доступ до нього через HTTP " -"сервер за допомогою наведеної команди::" - -#: ../source/contribute.rst:105 -msgid "The guide will be browsable via http://localhost:8000." -msgstr "Керівництво можна буде переглядати через http://localhost:8000." - -#: ../source/contribute.rst:109 -msgid "Where the guide is deployed" -msgstr "Куди це керівництво публікується" - -#: ../source/contribute.rst:111 -msgid "" -"The guide is deployed via ReadTheDocs and the configuration lives at https://" -"readthedocs.org/projects/python-packaging-user-guide/. It's served from a " -"custom domain and fronted by Fast.ly." -msgstr "" -"Це керівництво розгорнуте через ReadTheDocs і конфігурація живе на " -"https://readthedocs.org/projects/python-packaging-user-guide/. Доступ до " -"нього надається із додаткового домену через фронт-енд Fast.ly." - -#: ../source/contribute.rst:117 -msgid "Style guide" -msgstr "Керівництво по стилю" - -#: ../source/contribute.rst:119 -msgid "" -"This style guide has recommendations for how you should write the |PyPUG|. " -"Before you start writing, please review it. By following the style guide, " -"your contributions will help add to a cohesive whole and make it easier for " -"your contributions to be accepted into the project." -msgstr "" -"Це керівництво зі стилю містить поради щодо того, як вам слід писати |PyPUG|" -". Перш, ніж почати, ознайомтеся з ним. Дотримуючись цього керівництва по " -"стилю, ваші внески допоможуть доповнити єдине ціле і спростять їх схвалення " -"для проєкту." - -#: ../source/contribute.rst:126 -msgid "Purpose" -msgstr "Призначення" - -#: ../source/contribute.rst:128 -msgid "" -"The purpose of the |PyPUG| is to be the authoritative resource on how to " -"package, publish, and install Python projects using current tools." -msgstr "" -"|PyPUG| має на меті бути авторитетним ресурсом щодо того як пакувати, " -"публікувати та встановлювати проєкти на Python, використовуючи сучасні " -"засоби." - -#: ../source/contribute.rst:133 -msgid "Scope" -msgstr "Охоплення" - -#: ../source/contribute.rst:135 -msgid "" -"The guide is meant to answer questions and solve problems with accurate and " -"focused recommendations." -msgstr "" -"Керівництво має відповісти на запитання і вирішити проблеми за допомогою " -"точних і влучних порад." - -#: ../source/contribute.rst:138 -msgid "" -"The guide isn't meant to be comprehensive and it's not meant to replace " -"individual projects' documentation. For example, pip has dozens of commands, " -"options, and settings. The pip documentation describes each of them in " -"detail, while this guide describes only the parts of pip that are needed to " -"complete the specific tasks described in this guide." -msgstr "" -"Керівництво не має бути всеосяжним і не має на меті замінити документацію " -"окремих проєктів. Наприклад, pip містить дюжини команд, опцій та " -"налаштувань. Документація pip ретельно описує кожну з них, тоді як це " -"керівництво описує лише частини pip, що необхідні для виконання конкретних " -"завдань, описаних у цьому керівництві." - -#: ../source/contribute.rst:146 -msgid "Audience" -msgstr "Читачі" - -#: ../source/contribute.rst:148 -msgid "The audience of this guide is anyone who uses Python with packages." -msgstr "" -"Цільова аудиторія цього керівництва — усі, хто користується Pythonом із " -"пакунками." - -#: ../source/contribute.rst:150 -msgid "" -"Don't forget that the Python community is big and welcoming. Readers may not " -"share your age, gender, education, culture, and more, but they deserve to " -"learn about packaging just as much as you do." -msgstr "" -"Не забувайте, що Python-спільнота — велика і привітна. Читачі можуть бути " -"іншого віку, статі, мати іншу освіту та належати іншій культурі, ніж ви, але " -"вони так само заслуговують дізнаватися про пакування, як і ви." - -#: ../source/contribute.rst:154 -msgid "" -"In particular, keep in mind that not all people who use Python see " -"themselves as programmers. The audience of this guide includes astronomers " -"or painters or students as well as professional software developers." -msgstr "" -"Зокрема, пам'ятайте, що не усі люди, які використовують Python, вважають " -"себе програмістами. До читачів цього керівництва можуть належати астрономи, " -"художники, учні так само, як і професійні розробники програмного " -"забезпечення." - -#: ../source/contribute.rst:160 -msgid "Voice and tone" -msgstr "Вираження і тон" - -#: ../source/contribute.rst:162 -msgid "" -"When writing this guide, strive to write with a voice that's approachable " -"and humble, even if you have all the answers." -msgstr "" -"Під час написання цього керівництва, намагайтеся виражатися доступно й " -"скромно, навіть якщо у вас є усі відповіді." - -#: ../source/contribute.rst:165 -msgid "" -"Imagine you're working on a Python project with someone you know to be smart " -"and skilled. You like working with them and they like working with you. That " -"person has asked you a question and you know the answer. How do you respond? " -"*That* is how you should write this guide." -msgstr "" -"Уявіть, що ви працюєте над Python-проєктом з кимось, кого знаєте як розумну " -"людину з потужними навичками. Вам подобається працювати з цією людиною, як і " -"їй подобається працювати із вами. Ця людина спитала вас і ви знаєте " -"відповідь. Як би ви відповідали? *Саме так* і варто писати це керівництво." - -#: ../source/contribute.rst:170 -msgid "" -"Here's a quick check: try reading aloud to get a sense for your writing's " -"voice and tone. Does it sound like something you would say or does it sound " -"like you're acting out a part or giving a speech? Feel free to use " -"contractions and don't worry about sticking to fussy grammar rules. You are " -"hereby granted permission to end a sentence in a preposition, if that's what " -"you want to end it with." -msgstr "" -"Ось швидка перевірка: спробуйте прочитати вголос, щоб відчути виразність і " -"тон свого письма. Чи звучить це як щось, що ви б сказали, або ж це звучить " -"так, ніби ви граєте роль чи виголошуєте промову? Не соромтеся скористатися " -"скороченнями і не турбуйтеся про дотримання вимогливих граматичних правил. " -"Цим вам дозволено закінчити речення прийменником, якщо саме так ви бажаєте " -"його закінчити." - -#: ../source/contribute.rst:177 -msgid "" -"When writing the guide, adjust your tone for the seriousness and difficulty " -"of the topic. If you're writing an introductory tutorial, it's OK to make a " -"joke, but if you're covering a sensitive security recommendation, you might " -"want to avoid jokes altogether." -msgstr "" -"Під час написання керівництва, підлаштуйте свій тон на серйозність і " -"складність теми. Якщо ви пишете вступну навчальну інструкцію, можна " -"пожартувати, однак якщо ви покриваєте делікатну рекомендацію щодо безпеки, " -"можливо, вам захочеться взагалі уникнути жартів." - -#: ../source/contribute.rst:184 -msgid "Conventions and mechanics" -msgstr "Домовленості й механіка" - -#: ../source/contribute.rst:192 -msgid "**Write to the reader**" -msgstr "**Звертайтеся до читачів**" - -#: ../source/contribute.rst:187 -msgid "" -"When giving recommendations or steps to take, address the reader as *you* or " -"use the imperative mood." -msgstr "" -"Коли ви даєте рекомендації або вказуєте необхідні кроки, звертайтеся до " -"читачів на *ви* або використовуйте наказовий спосіб." - -#: ../source/contribute.rst:0 -msgid "Wrong: To install it, the user runs…" -msgstr "Неправильно: Для встановлення, користувач запускає …" - -#: ../source/contribute.rst:0 -msgid "Right: You can install it by running…" -msgstr "Правильно: Ви можете встановити це, виконавши …" - -#: ../source/contribute.rst:0 -msgid "Right: To install it, run…" -msgstr "Правильно: Щоб встановити це, виконайте…" - -#: ../source/contribute.rst:198 -msgid "**State assumptions**" -msgstr "**Оголошуйте припущення**" - -#: ../source/contribute.rst:195 -msgid "" -"Avoid making unstated assumptions. Reading on the web means that any page of " -"the guide may be the first page of the guide that the reader ever sees. If " -"you're going to make assumptions, then say what assumptions that you're " -"going to make." -msgstr "" -"Уникайте невисловлених припущень. Читання в Інтернеті означає, що яка " -"завгодно сторінка керівництва може бути найпершою його сторінкою, яку читач " -"побачить узагалі. Якщо ж ви збираєтеся робити припущення, то скажіть, на які " -"саме припущення ви покладаєтесь." - -#: ../source/contribute.rst:203 -msgid "**Cross-reference generously**" -msgstr "**Щедро додавайте перехресні посилання**" - -#: ../source/contribute.rst:201 -msgid "" -"The first time you mention a tool or practice, link to the part of the guide " -"that covers it, or link to a relevant document elsewhere. Save the reader a " -"search." -msgstr "" -"Коли ви вперше згадуєте інструмент або підхід, дайте посилання на ту частину " -"керівництва, яка розповідає про нього, або ж на відповідну документацію " -"деінде. Не змушуйте читачів шукати інформацію." - -#: ../source/contribute.rst:213 -msgid "**Respect naming practices**" -msgstr "**Дотримуйтеся практик іменування**" - -#: ../source/contribute.rst:206 -msgid "" -"When naming tools, sites, people, and other proper nouns, use their " -"preferred capitalization." -msgstr "" -"Згадуючи інструменти, сайти, людей чи інші власні назви, використовуйте їх " -"бажане написання великих літер." - -#: ../source/contribute.rst:0 -msgid "Wrong: Pip uses…" -msgstr "Неправильно: Pip використовує…" - -#: ../source/contribute.rst:0 -msgid "Right: pip uses…" -msgstr "Правильно: pip використовує…" - -#: ../source/contribute.rst:0 -msgid "Wrong: …hosted on github." -msgstr "Неправильно: ...розміщено на github." - -#: ../source/contribute.rst:0 -msgid "Right: …hosted on GitHub." -msgstr "Правильно: ...розміщено на GitHub." - -#: ../source/contribute.rst:222 -msgid "**Use a gender-neutral style**" -msgstr "**Використовуйте ґендерно нейтральний стиль**" - -#: ../source/contribute.rst:216 -msgid "" -"Often, you'll address the reader directly with *you*, *your* and *yours*. " -"Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or " -"avoid pronouns entirely." -msgstr "" -"Часто ви звертатиметеся до читача безпосередньо за допомогою *ви* і *ваш*. В " -"інших випадках використовуйте гендерно-нейтральні займенники *вони* та *їх*, " -"чи повністю уникайте займенників." - -#: ../source/contribute.rst:0 -msgid "Wrong: A maintainer uploads the file. Then he…" -msgstr "Неправильно: Доглядач завантажує файл. А потім він…" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then they…" -msgstr "Правильно: Доглядачі завантажують файл. А потім вони…" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then the maintainer…" -msgstr "Правильно: Доглядачі завантажують файл. А потім ці доглядачі…" - -#: ../source/contribute.rst:234 -msgid "**Headings**" -msgstr "**Заголовки**" - -#: ../source/contribute.rst:225 -msgid "" -"Write headings that use words the reader is searching for. A good way to do " -"this is to have your heading complete an implied question. For example, a " -"reader might want to know *How do I install MyLibrary?* so a good heading " -"might be *Install MyLibrary*." -msgstr "" -"Пишіть заголовки за допомогою слів, які читачі шукатимуть. Хороший спосіб це " -"зробити — скласти заголовок так, щоб він доповнював неявне запитання. " -"Наприклад, читачі можуть хотіти дізнатися *Як я можу встановити MyLibrary?*, " -"тож хорошим заголовком буде *Встановити MyLibrary*." - -#: ../source/contribute.rst:230 -msgid "" -"In section headings, use sentence case. In other words, write headings as " -"you would write a typical sentence." -msgstr "" -"У заголовках розділів, дотримуйтеся регістру речень. Іншими словами, пишіть " -"заголовки так, як ви б написали звичайне речення." - -#: ../source/contribute.rst:0 -msgid "Wrong: Things You Should Know About Python" -msgstr "Неправильно: Речі, Які Вам Слід Знати Про Python" - -#: ../source/contribute.rst:0 -msgid "Right: Things you should know about Python" -msgstr "Правильно: Речі, які вам слід знати про Python" - -#: ../source/contribute.rst:237 -msgid "**Numbers**" -msgstr "**Числа**" - -#: ../source/contribute.rst:237 -msgid "" -"In body text, write numbers one through nine as words. For other numbers or " -"numbers in tables, use numerals." -msgstr "" -"У всередині тексту, пишіть числа від одного до дев'яти словами. Для інших " -"чисел або чисел у таблицях використовуйте цифри." - -#: ../source/discussions/deploying-python-applications.rst:4 -msgid "Deploying Python applications" -msgstr "Розгортання Python-застосунків" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Page Status" -msgstr "Стан сторінки" - -#: ../source/discussions/deploying-python-applications.rst:6 -#: ../source/guides/index-mirrors-and-caches.rst:7 -#: ../source/guides/installing-using-linux-tools.rst:7 -#: ../source/guides/packaging-binary-extensions.rst:7 -#: ../source/guides/supporting-multiple-python-versions.rst:7 -#: ../source/guides/supporting-windows-using-appveyor.rst:5 -msgid "Incomplete" -msgstr "Незавершено" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Last Reviewed" -msgstr "Останнє рецензування" - -#: ../source/discussions/deploying-python-applications.rst:7 -msgid "2014-11-11" -msgstr "11.11.2014" - -#: ../source/discussions/deploying-python-applications.rst:11 -#: ../source/discussions/install-requires-vs-requirements.rst:9 -#: ../source/guides/analyzing-pypi-package-downloads.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:22 -#: ../source/guides/index-mirrors-and-caches.rst:12 -#: ../source/guides/installing-scientific-packages.rst:9 -#: ../source/guides/packaging-binary-extensions.rst:17 -#: ../source/guides/supporting-multiple-python-versions.rst:12 -#: ../source/guides/supporting-windows-using-appveyor.rst:15 -#: ../source/overview.rst:23 ../source/specifications/core-metadata.rst:38 -#: ../source/specifications/direct-url.rst:14 -#: ../source/tutorials/installing-packages.rst:23 -msgid "Contents" -msgstr "Зміст" - -#: ../source/discussions/deploying-python-applications.rst:14 -msgid "Overview" -msgstr "Огляд" - -#: ../source/discussions/deploying-python-applications.rst:18 -msgid "Supporting multiple hardware platforms" -msgstr "Підтримка декількох апаратних платформ" - -#: ../source/discussions/deploying-python-applications.rst:40 -msgid "OS packaging & installers" -msgstr "Пакування на рівні ОС та встановлювачі" - -#: ../source/discussions/deploying-python-applications.rst:52 -msgid "Windows" -msgstr "Windows" - -#: ../source/discussions/deploying-python-applications.rst:61 -msgid "Pynsist" -msgstr "Pynsist" - -#: ../source/discussions/deploying-python-applications.rst:63 -msgid "" -"`Pynsist `__ is a tool that bundles Python " -"programs together with the Python-interpreter into a single installer based " -"on NSIS. In most cases, packaging only requires the user to choose a version " -"of the Python-interpreter and declare the dependencies of the program. The " -"tool downloads the specified Python-interpreter for Windows and packages it " -"with all the dependencies in a single Windows-executable installer." -msgstr "" -"`Pynsist `__ — це інструмент, який укладає " -"Python-програми разом із інтерпретатором Python у єдиний встановлювач на " -"основі NSIS. У більшості випадків пакування вимагає від користувача лише " -"вибору версії Python-інтерпретатора і оголошення залежностей програми. Цей " -"засіб завантажує вказаний інтерпретатор Python для Windows і загортає його з " -"усіма залежностями до єдиного Windows-виконуваного встановлювача." - -#: ../source/discussions/deploying-python-applications.rst:70 -msgid "" -"The installed program can be started from a shortcut that the installer adds " -"to the start-menu. It uses a Python interpreter installed within its " -"application directory, independent of any other Python installation on the " -"computer." -msgstr "" -"Встановлену програму можна запустити черкз ярлик, який встановлювач додає до " -"меню \"Пуск\". Він використовує інтерпретатор Python, що знаходиться у " -"власній теці застосунку, незалежно від будь-якого іншого екземпляра Python " -"на тому ж комп’ютері." - -#: ../source/discussions/deploying-python-applications.rst:74 -msgid "" -"A big advantage of Pynsist is that the Windows packages can be built on " -"Linux. There are several examples for different kinds of programs (console, " -"GUI) in the `documentation `__. The tool is " -"released under the MIT-licence." -msgstr "" -"Значною перевагою Pynsist є те, що пакунки для Windows можуть бути зібрані " -"під Linux. У `документації `__ є кілька " -"прикладів різних видів програм (консольних, графічних). Інструмент доступний " -"під ліцензією MIT." - -#: ../source/discussions/deploying-python-applications.rst:80 -msgid "Application bundles" -msgstr "Колекції програм" - -#: ../source/discussions/deploying-python-applications.rst:91 -msgid "Configuration management" -msgstr "Керування конфігуруванням" - -#: ../source/discussions/index.rst:4 -msgid "" -"**Discussions** are focused on providing comprehensive information about a " -"specific topic. If you're just trying to get stuff done, see :doc:`/guides/" -"index`." -msgstr "" -"**Обговорення** зосереджені на наданні вичерпної інформації щодо певної " -"теми. Якщо ви просто намагаєтеся виконати певну роботу, зверніться до :doc:`/" -"guides/index`." - -#: ../source/discussions/install-requires-vs-requirements.rst:5 -msgid "install_requires vs requirements files" -msgstr "install_requires проти файлів requirements" - -#: ../source/discussions/install-requires-vs-requirements.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:382 -msgid "install_requires" -msgstr "install_requires" - -#: ../source/discussions/install-requires-vs-requirements.rst:14 -msgid "" -"``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that " -"should be used to specify what a project **minimally** needs to run " -"correctly. When the project is installed by :ref:`pip`, this is the " -"specification that is used to install its dependencies." -msgstr "" -"``install_requires`` — ключове слово у :ref:`setuptools`-файлі :file:`setup." -"py`, яке слід використовувати для зазначення того, що проєкт потребує " -"**мінімально**, аби запускатися коректно. Коли проєкт інстальовано за " -"допомогою :ref:`pip`, це специфікація, яка використовується для встановлення " -"його залежностей." - -#: ../source/discussions/install-requires-vs-requirements.rst:19 -msgid "" -"For example, if the project requires A and B, your ``install_requires`` " -"would be like so:" -msgstr "" -"Наприклад, якщо проєкт потребує A чи B, ваш ``install_requires`` виглядатиме " -"ось так:" - -#: ../source/discussions/install-requires-vs-requirements.rst:29 -msgid "" -"Additionally, it's best practice to indicate any known lower or upper bounds." -msgstr "" -"До того ж, позначення будь-яких відомих нижніх чи верхніх меж вважається " -"найкращою практикою." - -#: ../source/discussions/install-requires-vs-requirements.rst:31 -msgid "" -"For example, it may be known, that your project requires at least v1 of 'A', " -"and v2 of 'B', so it would be like so:" -msgstr "" -"Наприклад, може бути відомо, що ваш проєкт потребує щонайменше v1 залежності " -"'A' та v2 залежності 'B', тоді це виглядатиме отак:" - -#: ../source/discussions/install-requires-vs-requirements.rst:41 -msgid "" -"It may also be known that project A follows semantic versioning, and that v2 " -"of 'A' will indicate a break in compatibility, so it makes sense to not " -"allow v2:" -msgstr "" -"Крім того, може бути відомо, що проєкт A використовує семантичне " -"версіонування і що 'A' v2 означає несумісну зміну, тож має сенс не дозволяти " -"v2:" - -#: ../source/discussions/install-requires-vs-requirements.rst:51 -msgid "" -"It is not considered best practice to use ``install_requires`` to pin " -"dependencies to specific versions, or to specify sub-dependencies (i.e. " -"dependencies of your dependencies). This is overly-restrictive, and " -"prevents the user from gaining the benefit of dependency upgrades." -msgstr "" -"Закріплення точних версій залежностей у ``install_requires`` не вважається " -"найкращою практикою, так само, не варто вказувати під-залежності (тобто " -"залежності ваших залежностей). Це надміру обмежувально і перешкоджає " -"користувачам скористатися перевагами оновлення залежностей." - -#: ../source/discussions/install-requires-vs-requirements.rst:56 -msgid "" -"Lastly, it's important to understand that ``install_requires`` is a listing " -"of \"Abstract\" requirements, i.e just names and version restrictions that " -"don't determine where the dependencies will be fulfilled from (i.e. from " -"what index or source). The where (i.e. how they are to be made \"Concrete" -"\") is to be determined at install time using :ref:`pip` options. [1]_" -msgstr "" -"Наостанок, важливо розуміти, що ``install_requires`` перелічує «Абстрактні» " -"залежності, тобто лише обмеження назв і версій, які не визначають звідки ті " -"залежності будуть заповнені (тобто, із якого реєстру чи джерела). Звідки (" -"тобто, яким чином вони мають стати «Конкретними») визначається під час " -"встановлення за допомогою опцій :ref:`pip`. [1]_" - -#: ../source/discussions/install-requires-vs-requirements.rst:64 -#: ../source/tutorials/installing-packages.rst:460 -msgid "Requirements files" -msgstr "Файли requirements" - -#: ../source/discussions/install-requires-vs-requirements.rst:66 -msgid "" -":ref:`Requirements Files ` described most simply, " -"are just a list of :ref:`pip:pip install` arguments placed into a file." -msgstr "" -":ref:`Файли requirements `, описуючи дуже спрощено, " -"це лише перелік аргументів для :ref:`pip:pip install`, записаних у файл." - -#: ../source/discussions/install-requires-vs-requirements.rst:69 -msgid "" -"Whereas ``install_requires`` defines the dependencies for a single project, :" -"ref:`Requirements Files ` are often used to define " -"the requirements for a complete Python environment." -msgstr "" -"У той час як ``install_requires`` визначає залежності для єдиного проєкту, " -":ref:`файли requirements ` часто використовуються " -"для визначення залежностей для певного середовища Python environment." - -#: ../source/discussions/install-requires-vs-requirements.rst:73 -msgid "" -"Whereas ``install_requires`` requirements are minimal, requirements files " -"often contain an exhaustive listing of pinned versions for the purpose of " -"achieving :ref:`repeatable installations ` of a complete " -"environment." -msgstr "" -"У той час як залежності в ``install_requires`` мінімальні, файли " -"requirements часто містіть вичерпний перелік конкретних версій задля " -"досягнення :ref:`повторюваних встановлень ` повного " -"середовища." - -#: ../source/discussions/install-requires-vs-requirements.rst:78 -msgid "" -"Whereas ``install_requires`` requirements are \"Abstract\", i.e. not " -"associated with any particular index, requirements files often contain pip " -"options like ``--index-url`` or ``--find-links`` to make requirements " -"\"Concrete\", i.e. associated with a particular index or directory of " -"packages. [1]_" -msgstr "" -"У той час як залежності в ``install_requires`` «Абстрактні», тобто не " -"пов'язані із жодним конкретним реєстром, файли requirements часто містять " -"опції pip на кшталт ``--index-url`` чи ``--find-links``, щоб зробити " -"залежності «Конкретними», тобто асоційованими із певним реєстром чи " -"каталогом пакунків. [1]_" - -#: ../source/discussions/install-requires-vs-requirements.rst:84 -msgid "" -"Whereas ``install_requires`` metadata is automatically analyzed by pip " -"during an install, requirements files are not, and only are used when a user " -"specifically installs them using ``python -m pip install -r``." -msgstr "" -"У той час як pip автоматично аналізує метадані з ``install_requires`` під " -"час встановлення, цього не відбувається із файлами requirements, вони лиш " -"використовуються коли користувачі явно встановлюють їх через ``python -m pip " -"install -r``." - -#: ../source/discussions/install-requires-vs-requirements.rst:90 -msgid "" -"For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad." -"io/2013/07/setup-vs-requirement/." -msgstr "" -"Щоб дізнатися більше про «Абстрактні» залежності проти «Конкретних», читайте " -"https://caremad.io/2013/07/setup-vs-requirement/." - -#: ../source/discussions/pip-vs-easy-install.rst:6 -msgid "pip vs easy_install" -msgstr "pip проти easy_install" - -#: ../source/discussions/pip-vs-easy-install.rst:9 -msgid "" -":ref:`easy_install `, now `deprecated`_, was released in 2004 " -"as part of :ref:`setuptools`. It was notable at the time for installing :" -"term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing " -"dependencies." -msgstr "" -":ref:`easy_install `, тепер `застарілий `_, було " -"випущено у 2004 як частину :ref:`setuptools`. Він був помітний у ті часи, " -"завдяки встановленням :term:`пакунків ` із :term:`PyPI " -"` з використанням специфікаторів вимог і " -"автоматичному встановленню залежностей." - -#: ../source/discussions/pip-vs-easy-install.rst:14 -msgid "" -":ref:`pip` came later in 2008, as alternative to :ref:`easy_install " -"`, although still largely built on top of :ref:`setuptools` " -"components. It was notable at the time for *not* installing packages as :" -"term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' " -"packages from :term:`sdists `), and " -"introducing the idea of :ref:`Requirements Files `, " -"which gave users the power to easily replicate environments." -msgstr "" -":ref:`pip` з'явився пізніше у 2008 році, як альтернатива :ref:`easy_install " -"`, хоча він все ще був значною мірою створений на базі " -"компонентів :ref:`setuptools`. Він виділявся тим, що *не* встановлював " -"пакунки ні як :term:`Eggs `, ні із :term:`Eggs ` (але натомість як " -"прості «пласкі» пакунки із :term:`sdists `), вводячи ідею :ref:`файлів requirements `, які " -"надавали користувачам можливість легко повторювати середовища." - -#: ../source/discussions/pip-vs-easy-install.rst:22 -msgid "" -"Here's a breakdown of the important differences between pip and the " -"deprecated easy_install:" -msgstr "Ось аналіз важливих розбіжностей між pip та застарілим easy_install:" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**pip**" -msgstr "**pip**" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**easy_install**" -msgstr "**easy_install**" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -msgid "Installs from :term:`Wheels `" -msgstr "Встановлення з :term:`колес `" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Yes" -msgstr "Так" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:30 -#: ../source/discussions/pip-vs-easy-install.rst:32 -#: ../source/discussions/pip-vs-easy-install.rst:35 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:51 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "No" -msgstr "Ні" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Uninstall Packages" -msgstr "Видалення пакунків" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Yes (``python -m pip uninstall``)" -msgstr "Так (``python -m pip uninstall``)" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Dependency Overrides" -msgstr "Перевизначення залежностей" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Yes (:ref:`Requirements Files `)" -msgstr "Так (:ref:`Файли requirements `)" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "List Installed Packages" -msgstr "Перелік встановлених пакунків" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" -msgstr "Так (``python -m pip list`` і ``python -m pip freeze``)" - -#: ../source/discussions/pip-vs-easy-install.rst:38 -msgid ":pep:`438` Support" -msgstr "Підтримка :pep:`438`" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Installation format" -msgstr "Формат встановлення" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "'Flat' packages with :file:`egg-info` metadata." -msgstr "«Пласкі» пакунки із метаданими в :file:`egg-info`." - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Encapsulated Egg format" -msgstr "Інкапсульований формат Egg" - -#: ../source/discussions/pip-vs-easy-install.rst:44 -msgid "sys.path modification" -msgstr "Модифікація sys.path" - -#: ../source/discussions/pip-vs-easy-install.rst:48 -msgid "Installs from :term:`Eggs `" -msgstr "Встановлення із :term:`Eggs `" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "`pylauncher support`_" -msgstr "`підтримка pylauncher `_" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "Yes [1]_" -msgstr "Так [1]_" - -#: ../source/discussions/pip-vs-easy-install.rst:54 -msgid ":ref:`Multi-version Installs`" -msgstr ":ref:`Багатоверсійні встановлення `" - -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Exclude scripts during install" -msgstr "Виключення скриптів під час встановлення" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "per project index" -msgstr "окремі реєстри для проєктів" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Only in virtualenv" -msgstr "Лише у virtualenv" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Yes, via setup.cfg" -msgstr "Так, через setup.cfg" - -#: ../source/discussions/pip-vs-easy-install.rst:68 -msgid "" -"https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" -"launcher" -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:5 -msgid "Wheel vs Egg" -msgstr "Wheel чи Egg" - -#: ../source/discussions/wheel-vs-egg.rst:7 -msgid "" -":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support " -"the use case of needing an install artifact that doesn't require building or " -"compilation, which can be costly in testing and production workflows." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:11 -msgid "" -"The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas " -"the :term:`Wheel` format was introduced by :pep:`427` in 2012." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:14 -msgid "" -":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:17 -msgid "" -"Here's a breakdown of the important differences between :term:`Wheel` and :" -"term:`Egg`." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:20 -msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:22 -msgid "" -":term:`Wheel` is a :term:`distribution ` format, i.e a " -"packaging format. [1]_ :term:`Egg` was both a distribution format and a " -"runtime installation format (if left zipped), and was designed to be " -"importable." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:26 -msgid "" -":term:`Wheel` archives do not include .pyc files. Therefore, when the " -"distribution only contains Python files (i.e. no compiled extensions), and " -"is compatible with Python 2 and 3, it's possible for a wheel to be " -"\"universal\", similar to an :term:`sdist `." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:31 -msgid "" -":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. " -"Egg used ``.egg-info``." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:34 -msgid "" -":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single " -"wheel archive can indicate its compatibility with a number of Python " -"language versions and implementations, ABIs, and system architectures." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:38 -msgid "" -":term:`Wheel` is versioned. Every wheel file contains the version of the " -"wheel specification and the implementation that packaged it." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:41 -msgid "" -":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making " -"it easier to convert to other formats." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:47 -msgid "" -"Circumstantially, in some cases, wheels can be used as an importable runtime " -"format, although :pep:`this is not officially supported at this time <427#is-" -"it-possible-to-import-python-code-directly-from-a-wheel-file>`." -msgstr "" - -#: ../source/glossary.rst:3 -msgid "Glossary" -msgstr "Голосарій" - -#: ../source/glossary.rst:8 -msgid "Binary Distribution" -msgstr "" - -#: ../source/glossary.rst:11 -msgid "" -"A specific kind of :term:`Built Distribution` that contains compiled " -"extensions." -msgstr "" - -#: ../source/glossary.rst:14 -msgid "Built Distribution" -msgstr "" - -#: ../source/glossary.rst:17 -msgid "" -"A :term:`Distribution ` format containing files and " -"metadata that only need to be moved to the correct location on the target " -"system, to be installed. :term:`Wheel` is such a format, whereas distutil's :" -"term:`Source Distribution ` is not, in " -"that it requires a build step before it can be installed. This format does " -"not imply that Python files have to be precompiled (:term:`Wheel` " -"intentionally does not include compiled Python files)." -msgstr "" - -#: ../source/glossary.rst:26 -msgid "Distribution Package" -msgstr "" - -#: ../source/glossary.rst:29 -msgid "" -"A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used " -"to distribute a :term:`Release`. The archive file is what an end-user will " -"download from the internet and install." -msgstr "" - -#: ../source/glossary.rst:34 -msgid "" -"A distribution package is more commonly referred to with the single words " -"\"package\" or \"distribution\", but this guide may use the expanded term " -"when more clarity is needed to prevent confusion with an :term:`Import " -"Package` (which is also commonly called a \"package\") or another kind of " -"distribution (e.g. a Linux distribution or the Python language " -"distribution), which are often referred to with the single term " -"\"distribution\"." -msgstr "" - -#: ../source/glossary.rst:41 -msgid "Egg" -msgstr "" - -#: ../source/glossary.rst:44 -msgid "" -"A :term:`Built Distribution` format introduced by :ref:`setuptools`, which " -"is being replaced by :term:`Wheel`. For details, see `The Internal " -"Structure of Python Eggs `_ and `Python Eggs `_" -msgstr "" - -#: ../source/glossary.rst:49 -msgid "Extension Module" -msgstr "" - -#: ../source/glossary.rst:52 -msgid "" -"A :term:`Module` written in the low-level language of the Python " -"implementation: C/C++ for Python, Java for Jython. Typically contained in a " -"single dynamically loadable pre-compiled file, e.g. a shared object (.so) " -"file for Python extensions on Unix, a DLL (given the .pyd extension) for " -"Python extensions on Windows, or a Java class file for Jython extensions." -msgstr "" - -#: ../source/glossary.rst:59 -msgid "Known Good Set (KGS)" -msgstr "" - -#: ../source/glossary.rst:62 -msgid "" -"A set of distributions at specified versions which are compatible with each " -"other. Typically a test suite will be run which passes all tests before a " -"specific set of packages is declared a known good set. This term is commonly " -"used by frameworks and toolkits which are comprised of multiple individual " -"distributions." -msgstr "" - -#: ../source/glossary.rst:68 -msgid "Import Package" -msgstr "" - -#: ../source/glossary.rst:71 -msgid "" -"A Python module which can contain other modules or recursively, other " -"packages." -msgstr "" - -#: ../source/glossary.rst:74 -msgid "" -"An import package is more commonly referred to with the single word \"package" -"\", but this guide will use the expanded term when more clarity is needed to " -"prevent confusion with a :term:`Distribution Package` which is also commonly " -"called a \"package\"." -msgstr "" - -#: ../source/glossary.rst:78 -msgid "Module" -msgstr "Модуль" - -#: ../source/glossary.rst:81 -msgid "" -"The basic unit of code reusability in Python, existing in one of two types: :" -"term:`Pure Module`, or :term:`Extension Module`." -msgstr "" - -#: ../source/glossary.rst:84 -msgid "Package Index" -msgstr "Реєстр Пакунків" - -#: ../source/glossary.rst:87 -msgid "" -"A repository of distributions with a web interface to automate :term:" -"`package ` discovery and consumption." -msgstr "" - -#: ../source/glossary.rst:90 -msgid "Per Project Index" -msgstr "" - -#: ../source/glossary.rst:93 -msgid "" -"A private or other non-canonical :term:`Package Index` indicated by a " -"specific :term:`Project` as the index preferred or required to resolve " -"dependencies of that project." -msgstr "" - -#: ../source/glossary.rst:97 -msgid "Project" -msgstr "Проєкт" - -#: ../source/glossary.rst:100 -msgid "" -"A library, framework, script, plugin, application, or collection of data or " -"other resources, or some combination thereof that is intended to be packaged " -"into a :term:`Distribution `." -msgstr "" - -#: ../source/glossary.rst:104 -msgid "" -"Since most projects create :term:`Distributions ` " -"using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:" -"`setuptools`, another practical way to define projects currently is " -"something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:" -"`setup.cfg` file at the root of the project source directory." -msgstr "" - -#: ../source/glossary.rst:110 -msgid "" -"Python projects must have unique names, which are registered on :term:`PyPI " -"`. Each project will then contain one or more :" -"term:`Releases `, and each release may comprise one or more :term:" -"`distributions `." -msgstr "" - -#: ../source/glossary.rst:115 -msgid "" -"Note that there is a strong convention to name a project after the name of " -"the package that is imported to run that project. However, this doesn't have " -"to hold true. It's possible to install a distribution from the project 'foo' " -"and have it provide a package importable only as 'bar'." -msgstr "" - -#: ../source/glossary.rst:121 -msgid "Pure Module" -msgstr "" - -#: ../source/glossary.rst:124 -msgid "" -"A :term:`Module` written in Python and contained in a single ``.py`` file " -"(and possibly associated ``.pyc`` and/or ``.pyo`` files)." -msgstr "" - -#: ../source/glossary.rst:127 -msgid "Python Packaging Authority (PyPA)" -msgstr "Управління з пакування Python (PyPA)" - -#: ../source/glossary.rst:130 -msgid "" -"PyPA is a working group that maintains many of the relevant projects in " -"Python packaging. They maintain a site at https://www.pypa.io, host projects " -"on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python " -"Discourse forum `__." -msgstr "" - -#: ../source/glossary.rst:139 -msgid "Python Package Index (PyPI)" -msgstr "Реєстр Python-пакунків (PyPI)" - -#: ../source/glossary.rst:142 -msgid "" -"`PyPI `_ is the default :term:`Package Index` for the " -"Python community. It is open to all Python developers to consume and " -"distribute their distributions." -msgstr "" - -#: ../source/glossary.rst:145 -msgid "pypi.org" -msgstr "pypi.org" - -#: ../source/glossary.rst:148 -msgid "" -"`pypi.org `_ is the domain name for the :term:`Python " -"Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi." -"python.org``, in 2017. It is powered by :ref:`warehouse`." -msgstr "" - -#: ../source/glossary.rst:152 -msgid "pyproject.toml" -msgstr "pyproject.toml" - -#: ../source/glossary.rst:155 -msgid "" -"The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." -msgstr "" - -#: ../source/glossary.rst:157 -msgid "Release" -msgstr "Випуск" - -#: ../source/glossary.rst:160 -msgid "" -"A snapshot of a :term:`Project` at a particular point in time, denoted by a " -"version identifier." -msgstr "" - -#: ../source/glossary.rst:163 -msgid "" -"Making a release may entail the publishing of multiple :term:`Distributions " -"`. For example, if version 1.0 of a project was " -"released, it could be available in both a source distribution format and a " -"Windows installer distribution format." -msgstr "" - -#: ../source/glossary.rst:168 -msgid "Requirement" -msgstr "" - -#: ../source/glossary.rst:171 -msgid "" -"A specification for a :term:`package ` to be " -"installed. :ref:`pip`, the :term:`PYPA ` " -"recommended installer, allows various forms of specification that can all be " -"considered a \"requirement\". For more information, see the :ref:`pip:pip " -"install` reference." -msgstr "" - -#: ../source/glossary.rst:177 -msgid "Requirement Specifier" -msgstr "" - -#: ../source/glossary.rst:180 -msgid "" -"A format used by :ref:`pip` to install packages from a :term:`Package " -"Index`. For an EBNF diagram of the format, see the `pkg_resources." -"Requirement `_ entry in the :ref:`setuptools` docs. For " -"example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the " -"project name, and the \">=1.3\" portion is the :term:`Version Specifier`" -msgstr "" - -#: ../source/glossary.rst:187 -msgid "Requirements File" -msgstr "" - -#: ../source/glossary.rst:190 -msgid "" -"A file containing a list of :term:`Requirements ` that can be " -"installed using :ref:`pip`. For more information, see the :ref:`pip` docs " -"on :ref:`pip:Requirements Files`." -msgstr "" - -#: ../source/glossary.rst:194 -#: ../source/guides/distributing-packages-using-setuptools.rst:56 -msgid "setup.py" -msgstr "setup.py" - -#: ../source/glossary.rst:195 -#: ../source/guides/distributing-packages-using-setuptools.rst:77 -msgid "setup.cfg" -msgstr "setup.cfg" - -#: ../source/glossary.rst:198 -msgid "" -"The project specification files for :ref:`distutils` and :ref:`setuptools`. " -"See also :term:`pyproject.toml`." -msgstr "" - -#: ../source/glossary.rst:201 -msgid "Source Archive" -msgstr "" - -#: ../source/glossary.rst:204 -msgid "" -"An archive containing the raw source code for a :term:`Release`, prior to " -"creation of a :term:`Source Distribution ` or :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:208 -msgid "Source Distribution (or \"sdist\")" -msgstr "" - -#: ../source/glossary.rst:211 -msgid "" -"A :term:`distribution ` format (usually generated " -"using ``python setup.py sdist``) that provides metadata and the essential " -"source files needed for installing by a tool like :ref:`pip`, or for " -"generating a :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:216 -msgid "System Package" -msgstr "" - -#: ../source/glossary.rst:219 -msgid "" -"A package provided in a format native to the operating system, e.g. an rpm " -"or dpkg file." -msgstr "" - -#: ../source/glossary.rst:222 -msgid "Version Specifier" -msgstr "" - -#: ../source/glossary.rst:225 -msgid "" -"The version component of a :term:`Requirement Specifier`. For example, the " -"\">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full " -"specification <440#version-specifiers>` of the specifiers that Python " -"packaging currently supports. Support for PEP440 was implemented in :ref:" -"`setuptools` v8.0 and :ref:`pip` v6.0." -msgstr "" - -#: ../source/glossary.rst:231 -msgid "Virtual Environment" -msgstr "" - -#: ../source/glossary.rst:234 -msgid "" -"An isolated Python environment that allows packages to be installed for use " -"by a particular application, rather than being installed system wide. For " -"more information, see the section on :ref:`Creating and using Virtual " -"Environments`." -msgstr "" - -#: ../source/glossary.rst:238 -msgid "Wheel" -msgstr "" - -#: ../source/glossary.rst:241 -msgid "" -"A :term:`Built Distribution` format introduced by :pep:`427`, which is " -"intended to replace the :term:`Egg` format. Wheel is currently supported " -"by :ref:`pip`." -msgstr "" - -#: ../source/glossary.rst:244 -msgid "Working Set" -msgstr "" - -#: ../source/glossary.rst:247 -msgid "" -"A collection of :term:`distributions ` available for " -"importing. These are the distributions that are on the `sys.path` variable. " -"At most, one :term:`Distribution ` for a project is " -"possible in a working set." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:3 -msgid "Analyzing PyPI package downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:5 -msgid "" -"This section covers how to use the public PyPI download statistics dataset " -"to learn more about downloads of a package (or packages) hosted on PyPI. For " -"example, you can use it to discover the distribution of Python versions used " -"to download a package." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:15 -#: ../source/guides/supporting-windows-using-appveyor.rst:18 -msgid "Background" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:17 -msgid "PyPI does not display download statistics for a number of reasons: [#]_" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:19 -msgid "" -"**Inefficient to make work with a Content Distribution Network (CDN):** " -"Download statistics change constantly. Including them in project pages, " -"which are heavily cached, would require invalidating the cache more often, " -"and reduce the overall effectiveness of the cache." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:24 -msgid "" -"**Highly inaccurate:** A number of things prevent the download counts from " -"being accurate, some of which include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:27 -msgid "``pip``'s download cache (lowers download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:28 -msgid "" -"Internal or unofficial mirrors (can both raise or lower download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:29 -msgid "Packages not hosted on PyPI (for comparisons sake)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:30 -msgid "" -"Unofficial scripts or attempts at download count inflation (raises download " -"counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:32 -msgid "Known historical data quality issues (lowers download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:34 -msgid "" -"**Not particularly useful:** Just because a project has been downloaded a " -"lot doesn't mean it's good; Similarly just because a project hasn't been " -"downloaded a lot doesn't mean it's bad!" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:38 -msgid "" -"In short, because it's value is low for various reasons, and the tradeoffs " -"required to make it work are high, it has been not an effective use of " -"limited resources." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:43 -msgid "Public dataset" -msgstr "Публічний набір даних" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:45 -msgid "" -"As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, " -"where they are stored as a public dataset." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:50 -msgid "Getting set up" -msgstr "Налаштування" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:52 -msgid "" -"In order to use `Google BigQuery`_ to query the `public PyPI download " -"statistics dataset`_, you'll need a Google account and to enable the " -"BigQuery API on a Google Cloud Platform project. You can run the up to 1TB " -"of queries per month `using the BigQuery free tier without a credit card " -"`__" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:58 -msgid "Navigate to the `BigQuery web UI`_." -msgstr "Перейдіть до `веб-інтерфейсу BigQuery `_." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:59 -msgid "Create a new project." -msgstr "Створіть новий проєкт." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:60 -msgid "" -"Enable the `BigQuery API `__." -msgstr "" -"Увімкніть `BigQuery API `__." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:63 -msgid "" -"For more detailed instructions on how to get started with BigQuery, check " -"out the `BigQuery quickstart guide `__." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:69 -msgid "Data schema" -msgstr "Структура даних" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:71 -msgid "" -"Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` " -"table for each download. The table contains information about what file was " -"downloaded and how it was downloaded. Some useful columns from the `table " -"schema `__ include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -msgid "Column" -msgstr "Стовпець" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/guides/using-manifest-in.rst:67 -#: ../source/specifications/core-metadata.rst:185 -msgid "Description" -msgstr "Опис" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/specifications/direct-url.rst:226 -msgid "Examples" -msgstr "Приклади" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "timestamp" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "Date and time" -msgstr "Дата й час" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "``2020-03-09 00:33:03 UTC``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "file.project" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "Project name" -msgstr "Назва проєкту" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "``pipenv``, ``nose``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "file.version" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "Package version" -msgstr "Версія пакунку" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "``0.1.6``, ``1.4.2``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "details.installer.name" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "Installer" -msgstr "Встановлювач" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "pip, `bandersnatch`_" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "details.python" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "Python version" -msgstr "Версія Python" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "``2.7.12``, ``3.6.4``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:93 -msgid "Useful queries" -msgstr "Корисні запити" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:95 -msgid "" -"Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" " -"button." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:97 -msgid "" -"Note that the rows are stored in a partitioned, which helps limit the cost " -"of queries. These example queries analyze downloads from recent history by " -"filtering on the ``timestamp`` column." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:102 -msgid "Counting package downloads" -msgstr "Підрахунок завантажень пакунків" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:104 -msgid "" -"The following query counts the total number of downloads for the project " -"\"pytest\"." -msgstr "" -"Нижченаведений запит підраховує загальну кількість завантажень для проєкту " -"«pytest»." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:119 -#: ../source/guides/analyzing-pypi-package-downloads.rst:140 -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "num_downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:121 -msgid "26190085" -msgstr "26190085" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:124 -msgid "" -"To only count downloads from pip, filter on the ``details.installer.name`` " -"column." -msgstr "" -"Щоб підрахувати лише завантаження з pip, відфільтруйте стовпець ``details." -"installer.name``." - -#: ../source/guides/analyzing-pypi-package-downloads.rst:142 -msgid "24334215" -msgstr "24334215" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:146 -msgid "Package downloads over time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:148 -msgid "" -"To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also " -"filtering by this column reduces corresponding costs." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -msgid "month" -msgstr "month" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "1956741" -msgstr "1956741" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "2018-01-01" -msgstr "2018-01-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2344692" -msgstr "2344692" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2017-12-01" -msgstr "2017-12-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "1730398" -msgstr "1730398" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "2017-11-01" -msgstr "2017-11-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2047310" -msgstr "2047310" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2017-10-01" -msgstr "2017-10-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "1744443" -msgstr "1744443" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "2017-09-01" -msgstr "2017-09-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "1916952" -msgstr "1916952" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "2017-08-01" -msgstr "2017-08-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:184 -msgid "Python versions over time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:186 -msgid "" -"Extract the Python version from the ``details.python`` column. Warning: This " -"query processes over 500 GB of data." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "python" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "3.7" -msgstr "3.7" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "18051328726" -msgstr "18051328726" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "3.6" -msgstr "3.6" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "9635067203" -msgstr "9635067203" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "3.8" -msgstr "3.8" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "7781904681" -msgstr "7781904681" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "2.7" -msgstr "2.7" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "6381252241" -msgstr "6381252241" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "null" -msgstr "null" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "2026630299" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "3.5" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "1894153540" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:221 -msgid "Caveats" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:223 -msgid "" -"In addition to the caveats listed in the background above, Linehaul suffered " -"from a bug which caused it to significantly under-report download statistics " -"prior to July 26, 2018. Downloads before this date are proportionally " -"accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total " -"numbers are lower than actual by an order of magnitude." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:231 -msgid "Additional tools" -msgstr "Додаткові інструменти" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:233 -msgid "" -"Besides using the BigQuery console, there are some additional tools which " -"may be useful when analyzing download statistics." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:237 -msgid "``google-cloud-bigquery``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:239 -msgid "" -"You can also access the public PyPI download statistics dataset " -"programmatically via the BigQuery API and the `google-cloud-bigquery`_ " -"project, the official Python client library for BigQuery." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:267 -msgid "``pypinfo``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:269 -msgid "" -"`pypinfo`_ is a command-line tool which provides access to the dataset and " -"can generate several useful queries. For example, you can query the total " -"number of download for a package with the command ``pypinfo package_name``." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:273 -msgid "Install `pypinfo`_ using pip." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:279 -msgid "Usage:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:295 -msgid "``pandas-gbq``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:297 -msgid "" -"The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:301 -#: ../source/specifications/binary-distribution-format.rst:459 -msgid "References" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:303 -msgid "" -"`PyPI Download Counts deprecation email `__" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:304 -msgid "" -"`PyPI BigQuery dataset announcement email `__" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:3 -msgid "Creating and discovering plugins" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:5 -msgid "" -"Often when creating a Python application or library you'll want the ability " -"to provide customizations or extra features via **plugins**. Because Python " -"packages can be separately distributed, your application or library may want " -"to automatically **discover** all of the plugins available." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:10 -msgid "There are three major approaches to doing automatic plugin discovery:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:12 -msgid "`Using naming convention`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:13 -msgid "`Using namespace packages`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:14 -msgid "`Using package metadata`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:18 -msgid "Using naming convention" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:20 -msgid "" -"If all of the plugins for your application follow the same naming " -"convention, you can use :func:`pkgutil.iter_modules` to discover all of the " -"top-level modules that match the naming convention. For example, `Flask`_ " -"uses the naming convention ``flask_{plugin_name}``. If you wanted to " -"automatically discover all of the Flask plugins installed:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:38 -msgid "" -"If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins " -"installed then ``discovered_plugins`` would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:48 -msgid "" -"Using naming convention for plugins also allows you to query the Python " -"Package Index's `simple API`_ for all packages that conform to your naming " -"convention." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:59 -msgid "Using namespace packages" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:61 -msgid "" -":doc:`Namespace packages ` can be used to " -"provide a convention for where to place plugins and also provides a way to " -"perform discovery. For example, if you make the sub-package ``myapp." -"plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once " -"installed, you can use :func:`pkgutil.iter_modules` to discover all modules " -"and packages installed under that namespace:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:89 -msgid "" -"Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` " -"causes it to only look for the modules directly under that namespace. For " -"example, if you have installed distributions that provide the modules " -"``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in " -"this case would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:101 -msgid "" -"This sample uses a sub-package as the namespace package (``myapp.plugins``), " -"but it's also possible to use a top-level package for this purpose (such as " -"``myapp_plugins``). How to pick the namespace to use is a matter of " -"preference, but it's not recommended to make your project's main top-level " -"package (``myapp`` in this case) a namespace package for the purpose of " -"plugins, as one bad plugin could cause the entire namespace to break which " -"would in turn make your project unimportable. For the \"namespace sub-package" -"\" approach to work, the plugin packages must omit the :file:`__init__.py` " -"for your top-level package directory (``myapp`` in this case) and include " -"the namespace-package style :file:`__init__.py` in the namespace sub-package " -"directory (``myapp/plugins``). This also means that plugins will need to " -"explicitly pass a list of packages to :func:`setup`'s ``packages`` argument " -"instead of using :func:`setuptools.find_packages`." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:115 -msgid "" -"Namespace packages are a complex feature and there are several different " -"ways to create them. It's highly recommended to read the :doc:`packaging-" -"namespace-packages` documentation and clearly document which approach is " -"preferred for plugins to your project." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:121 -msgid "Using package metadata" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:123 -msgid "" -"`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :" -"func:`setup` in :file:`setup.py` plugins can register themselves for " -"discovery." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:128 -msgid "" -"For example if you have a package named ``myapp-plugin-a`` and it includes " -"in its :file:`setup.py`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:139 -msgid "" -"Then you can discover and load all of the registered entry points by using :" -"func:`importlib.metadata.entry_points` (or the `backport`_ " -"``importlib_metadata >= 3.6`` for Python 3.6-3.9):" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:154 -msgid "" -"In this example, ``discovered_plugins`` would be a collection of type :class:" -"`importlib.metadata.EntryPoint`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:163 -msgid "" -"Now the module of your choice can be imported by executing " -"``discovered_plugins['a'].load()``." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:166 -msgid "" -"The ``entry_point`` specification in :file:`setup.py` is fairly flexible and " -"has a lot of options. It's recommended to read over the entire section on :" -"doc:`entry points ` ." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:170 -msgid "" -"Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools " -"provide support for defining entry points." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:5 -msgid "Packaging and distributing projects" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:7 -msgid "" -"This section covers the basics of how to configure, package and distribute " -"your own Python projects. It assumes that you are already familiar with the " -"contents of the :doc:`/tutorials/installing-packages` page." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:11 -msgid "" -"The section does *not* aim to cover best practices for Python project " -"development as a whole. For example, it does not provide guidance or tool " -"recommendations for version control, documentation, or testing." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:15 -msgid "" -"For more reference material, see :std:doc:`Building and Distributing " -"Packages ` in the :ref:`setuptools` docs, but note that " -"some advisory content there may be outdated. In the event of conflicts, " -"prefer the advice in the Python Packaging User Guide." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:25 -msgid "Requirements for packaging and distributing" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:26 -msgid "" -"First, make sure you have already fulfilled the :ref:`requirements for " -"installing packages `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:29 -msgid "Install \"twine\" [1]_:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:43 -msgid "" -"You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below " -"`)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:49 -msgid "Configuring your project" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:53 -msgid "Initial files" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:58 -msgid "" -"The most important file is :file:`setup.py` which exists at the root of your " -"project directory. For an example, see the `setup.py `_ in the `PyPA sample project " -"`_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:63 -msgid ":file:`setup.py` serves two primary functions:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:65 -msgid "" -"It's the file where various aspects of your project are configured. The " -"primary feature of :file:`setup.py` is that it contains a global ``setup()`` " -"function. The keyword arguments to this function are how specific details " -"of your project are defined. The most relevant arguments are explained in :" -"ref:`the section below `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:71 -msgid "" -"It's the command line interface for running various commands that relate to " -"packaging tasks. To get a listing of available commands, run ``python setup." -"py --help-commands``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:79 -msgid "" -":file:`setup.cfg` is an ini file that contains option defaults for :file:" -"`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project " -"`_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:86 -msgid "README.rst / README.md" -msgstr "README.rst / README.md" - -#: ../source/guides/distributing-packages-using-setuptools.rst:88 -msgid "" -"All projects should contain a readme file that covers the goal of the " -"project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not " -"a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:" -"`long_description_content_type ` argument)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:95 -msgid "" -"For an example, see `README.md `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:99 -msgid "" -"Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:" -"`README.rst`, :file:`README.txt`, or :file:`README`) included in source " -"distributions by default. The built-in :ref:`distutils` library adopts this " -"behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ " -"will include a :file:`README.md` if found. If you are using setuptools, you " -"don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, " -"include it to be explicit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:108 -msgid "MANIFEST.in" -msgstr "MANIFEST.in" - -#: ../source/guides/distributing-packages-using-setuptools.rst:110 -msgid "" -"A :file:`MANIFEST.in` is needed when you need to package additional files " -"that are not automatically included in a source distribution. For details " -"on writing a :file:`MANIFEST.in` file, including a list of what's included " -"by default, see \":ref:`Using MANIFEST.in`\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:115 -msgid "" -"For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:119 -msgid "" -":file:`MANIFEST.in` does not affect binary distributions such as wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:122 -msgid "LICENSE.txt" -msgstr "LICENSE.txt" - -#: ../source/guides/distributing-packages-using-setuptools.rst:124 -msgid "" -"Every package should include a license file detailing the terms of " -"distribution. In many jurisdictions, packages without an explicit license " -"can not be legally used or distributed by anyone other than the copyright " -"holder. If you're unsure which license to choose, you can use resources such " -"as `GitHub's Choose a License `_ or consult a " -"lawyer." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:130 -msgid "" -"For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:135 -msgid "" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:137 -msgid "" -"Although it's not required, the most common practice is to include your " -"Python modules and packages under a single top-level package that has the " -"same :ref:`name ` as your project, or something very close." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:141 -msgid "" -"For an example, see the `sample `_ package that's included in the `PyPA sample project " -"`_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:149 -msgid "setup() args" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:151 -msgid "" -"As mentioned above, the primary feature of :file:`setup.py` is that it " -"contains a global ``setup()`` function. The keyword arguments to this " -"function are how specific details of your project are defined." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:155 -msgid "" -"The most relevant arguments are explained below. Most of the snippets given " -"are taken from the `setup.py `_ contained in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:164 -msgid "name" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:170 -msgid "" -"This is the name of your project, determining how your project is listed on :" -"term:`PyPI `. Per :pep:`508`, valid project " -"names must:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:174 -msgid "" -"Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), " -"and/or periods (``.``), and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:176 -msgid "Start & end with an ASCII letter or digit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:178 -msgid "" -"Comparison of project names is case insensitive and treats arbitrarily-long " -"runs of underscores, hyphens, and/or periods as equal. For example, if you " -"register a project named ``cool-stuff``, users will be able to download it " -"or declare a dependency on it using any of the following spellings::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:190 -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "version" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:196 -msgid "" -"This is the current version of your project, allowing your users to " -"determine whether or not they have the latest version, and to indicate which " -"specific versions they've tested their own software against." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:200 -msgid "" -"Versions are displayed on :term:`PyPI ` for " -"each release if you publish your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:203 -msgid "" -"See :ref:`Choosing a versioning scheme` for more information on ways to use " -"versions to convey compatibility information to your users." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:206 -msgid "" -"If the project code itself needs run-time access to the version, the " -"simplest way is to keep the version in both :file:`setup.py` and your code. " -"If you'd rather not duplicate the value, there are a few ways to manage " -"this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:214 -msgid "description" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:222 -msgid "Give a short and long description for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:224 -msgid "" -"These values will be displayed on :term:`PyPI ` " -"if you publish your project. On ``pypi.org``, the user interface displays " -"``description`` in the grey banner and ``long_description`` in the section " -"named \"Project Description\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:229 -msgid "" -"``description`` is also displayed in lists of projects. For example, it's " -"visible in the search results pages such as https://pypi.org/search/?" -"q=jupyter, the front-page lists of trending projects and new releases, and " -"the list of projects you maintain within your account profile (such as " -"https://pypi.org/user/jaraco/)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:235 -msgid "" -"A `content type `_ can be specified with the " -"``long_description_content_type`` argument, which can be one of ``text/" -"plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no " -"formatting, `reStructuredText (reST) `_, and the Github-flavored " -"Markdown dialect of `Markdown `_ respectively." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:245 -msgid "url" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:252 -msgid "Give a homepage URL for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:256 -msgid "author" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:263 -msgid "Provide details about the author." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:267 -msgid "license" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:273 -msgid "" -"The ``license`` argument doesn't have to indicate the license under which " -"your package is being released, although you may optionally do so if you " -"want. If you're using a standard, well-known license, then your main " -"indication can and should be via the ``classifiers`` argument. Classifiers " -"exist for all major open-source licenses." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:279 -msgid "" -"The \"license\" argument is more typically used to indicate differences from " -"well-known licenses, or to include your own, unique license. As a general " -"rule, it's a good idea to use a standard, well-known license, both to avoid " -"confusion and because some organizations avoid software whose license is " -"unapproved." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:287 -msgid "classifiers" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:316 -msgid "" -"Provide a list of classifiers that categorize your project. For a full " -"listing, see https://pypi.org/classifiers/." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:319 -msgid "" -"Although the list of classifiers is often used to declare what Python " -"versions a project supports, this information is only used for searching & " -"browsing projects on PyPI, not for installing projects. To actually " -"restrict what Python versions a project can be installed on, use the :ref:" -"`python_requires` argument." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:327 -msgid "keywords" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:333 -msgid "List keywords that describe your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:337 -msgid "project_urls" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:349 -msgid "" -"List additional relevant URLs about your project. This is the place to link " -"to bug trackers, source repositories, or where to support package " -"development. The string of the key is the exact text that will be displayed " -"on PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:355 -msgid "packages" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:361 -msgid "" -"Set ``packages`` to a list of all :term:`packages ` in your " -"project, including their subpackages, sub-subpackages, etc. Although the " -"packages can be listed manually, ``setuptools.find_packages()`` finds them " -"automatically. Use the ``include`` keyword argument to find only the given " -"packages. Use the ``exclude`` keyword argument to omit packages that are " -"not intended to be released and installed." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:370 -msgid "py_modules" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:376 -msgid "" -"If your project contains any single-file Python modules that aren't part of " -"a package, set ``py_modules`` to a list of the names of the modules (minus " -"the ``.py`` extension) in order to make :ref:`setuptools` aware of them." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:388 -msgid "" -"\"install_requires\" should be used to specify what dependencies a project " -"minimally needs to run. When the project is installed by :ref:`pip`, this is " -"the specification that is used to install its dependencies." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:392 -msgid "" -"For more on using \"install_requires\" see :ref:`install_requires vs " -"Requirements files`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:398 -msgid "python_requires" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:400 -msgid "" -"If your project only runs on certain Python versions, setting the " -"``python_requires`` argument to the appropriate :pep:`440` version specifier " -"string will prevent :ref:`pip` from installing the project on other Python " -"versions. For example, if your package is for Python 3+ only, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:407 -msgid "" -"If your package is for Python 2.6, 2.7, and all versions of Python 3 " -"starting with 3.3, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:412 -msgid "And so on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:416 -msgid "" -"Support for this feature is relatively recent. Your project's source " -"distributions and wheels (see :ref:`Packaging Your Project`) must be built " -"using at least version 24.2.0 of :ref:`setuptools` in order for the " -"``python_requires`` argument to be recognized and the appropriate metadata " -"generated." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:422 -msgid "" -"In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the " -"``python_requires`` metadata. Users with earlier versions of pip will be " -"able to download & install projects on any Python version regardless of the " -"projects' ``python_requires`` values." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:431 -msgid "package_data" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:440 -msgid "" -"Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the " -"package’s implementation, or text files containing documentation that might " -"be of interest to programmers using the package. These files are called " -"\"package data\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:445 -msgid "" -"The value must be a mapping from package name to a list of relative path " -"names that should be copied into the package. The paths are interpreted as " -"relative to the directory containing the package." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:449 -msgid "" -"For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:457 -msgid "data_files" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:463 -msgid "" -"Although configuring :ref:`Package Data` is sufficient for most needs, in " -"some cases you may need to place data files *outside* of your :term:" -"`packages `. The ``data_files`` directive allows you to do " -"that. It is mostly useful if you need to install files which are used by " -"other programs, which may be unaware of Python packages." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:469 -msgid "" -"Each ``(directory, files)`` pair in the sequence specifies the installation " -"directory and the files to install there. The ``directory`` must be a " -"relative path (although this may change in the future, see `wheel Issue #92 " -"`_). and it is interpreted relative " -"to the installation prefix (Python’s ``sys.prefix`` for a default " -"installation; ``site.USER_BASE`` for a user installation). Each file name in " -"``files`` is interpreted relative to the :file:`setup.py` script at the top " -"of the project source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:479 -msgid "" -"For more information see the distutils section on `Installing Additional " -"Files `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:484 -msgid "" -"When installing packages as egg, ``data_files`` is not supported. So, if " -"your project uses :ref:`setuptools`, you must use ``pip`` to install it. " -"Alternatively, if you must use ``python setup.py``, then you need to pass " -"the ``--old-and-unmanageable`` option." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:491 -msgid "scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:493 -msgid "" -"Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made " -"scripts to install, the recommended approach to achieve cross-platform " -"compatibility is to use :ref:`console_scripts` entry points (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:500 -msgid "entry_points" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:509 -msgid "" -"Use this keyword to specify any plugins that your project provides for any " -"named entry points that may be defined by your project or others that you " -"depend on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:512 -msgid "" -"For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:516 -msgid "The most commonly used entry point is \"console_scripts\" (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:521 -msgid "console_scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:531 -msgid "" -"Use \"console_script\" `entry points `_ to " -"register your script interfaces. You can then let the toolchain handle the " -"work of turning these interfaces into actual scripts [2]_. The scripts will " -"be generated during the install of your :term:`distribution `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:538 -msgid "" -"For more information, see `Automatic Script Creation `_ from " -"the `setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:545 -msgid "Choosing a versioning scheme" -msgstr "Вибір схеми версіонування" - -#: ../source/guides/distributing-packages-using-setuptools.rst:548 -msgid "Standards compliance for interoperability" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:550 -msgid "" -"Different Python projects may use different versioning schemes based on the " -"needs of that particular project, but all of them are required to comply " -"with the flexible :pep:`public version scheme <440#public-version-" -"identifiers>` specified in :pep:`440` in order to be supported in tools and " -"libraries like ``pip`` and ``setuptools``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:556 -msgid "Here are some examples of compliant version numbers::" -msgstr "Ось кілька прикладів сумісних номерів версій::" - -#: ../source/guides/distributing-packages-using-setuptools.rst:567 -msgid "" -"To further accommodate historical variations in approaches to version " -"numbering, :pep:`440` also defines a comprehensive technique for :pep:" -"`version normalisation <440#normalization>` that maps variant spellings of " -"different version numbers to a standardised canonical form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:573 -msgid "Scheme choices" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:576 -msgid "Semantic versioning (preferred)" -msgstr "Семантичне версіонування (надається перевага)" - -#: ../source/guides/distributing-packages-using-setuptools.rst:578 -msgid "" -"For new projects, the recommended versioning scheme is based on `Semantic " -"Versioning `_, but adopts a different approach to " -"handling pre-releases and build metadata." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:582 -msgid "" -"The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE " -"numbering scheme, where the project author increments:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:585 -msgid "MAJOR version when they make incompatible API changes," -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:586 -msgid "" -"MINOR version when they add functionality in a backwards-compatible manner, " -"and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:587 -msgid "MAINTENANCE version when they make backwards-compatible bug fixes." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:589 -msgid "" -"Adopting this approach as a project author allows users to make use of :pep:`" -"\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= " -"X.Y`` requires at least release X.Y, but also allows any later release with " -"a matching MAJOR version." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:594 -msgid "" -"Python projects adopting semantic versioning should abide by clauses 1-8 of " -"the `Semantic Versioning 2.0.0 specification `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:598 -msgid "Date based versioning" -msgstr "Версіонування базоване на датах" - -#: ../source/guides/distributing-packages-using-setuptools.rst:600 -msgid "" -"Semantic versioning is not a suitable choice for all projects, such as those " -"with a regular time based release cadence and a deprecation process that " -"provides warnings for a number of releases prior to removal of a feature." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:604 -msgid "" -"A key advantage of date based versioning is that it is straightforward to " -"tell how old the base feature set of a particular release is given just the " -"version number." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:607 -msgid "" -"Version numbers for date based projects typically take the form of YEAR." -"MONTH (for example, ``12.04``, ``15.10``)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:611 -msgid "Serial versioning" -msgstr "Порядкове версіонування" - -#: ../source/guides/distributing-packages-using-setuptools.rst:613 -msgid "" -"This is the simplest possible versioning scheme, and consists of a single " -"number which is incremented every release." -msgstr "" -"Це найпростіша з можливих схем версіонування, яка складається з єдиного " -"числа, яке збільшується при кожній публікації." - -#: ../source/guides/distributing-packages-using-setuptools.rst:616 -msgid "" -"While serial versioning is very easy to manage as a developer, it is the " -"hardest to track as an end user, as serial version numbers convey little or " -"no information regarding API backwards compatibility." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:621 -msgid "Hybrid schemes" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:623 -msgid "" -"Combinations of the above schemes are possible. For example, a project may " -"combine date based versioning with serial versioning to create a YEAR.SERIAL " -"numbering scheme that readily conveys the approximate age of a release, but " -"doesn't otherwise commit to a particular release cadence within the year." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:629 -msgid "Pre-release versioning" -msgstr "Версіонування попередніх випусків" - -#: ../source/guides/distributing-packages-using-setuptools.rst:631 -msgid "" -"Regardless of the base versioning scheme, pre-releases for a given final " -"release may be published as:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:634 -msgid "zero or more dev releases (denoted with a \".devN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:635 -msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:636 -msgid "zero or more beta releases (denoted with a \".bN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:637 -msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:639 -msgid "" -"``pip`` and other modern Python package installers ignore pre-releases by " -"default when deciding which versions of dependencies to install." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:644 -msgid "Local version identifiers" -msgstr "Ідентифікатори місцевих версій" - -#: ../source/guides/distributing-packages-using-setuptools.rst:646 -msgid "" -"Public version identifiers are designed to support distribution via :term:" -"`PyPI `. Python's software distribution tools " -"also support the notion of a :pep:`local version identifier <440#local-" -"version-identifiers>`, which can be used to identify local development " -"builds not intended for publication, or modified variants of a release " -"maintained by a redistributor." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:653 -msgid "" -"A local version identifier takes the form ``" -"+``. For example::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:661 -msgid "Working in \"development mode\"" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:663 -msgid "" -"Although not required, it's common to locally install your project in " -"\"editable\" or \"develop\" mode while you're working on it. This allows " -"your project to be both installed and editable in project form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:667 -msgid "Assuming you're in the root of your project directory, then run:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:674 -msgid "" -"Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` " -"refers to the current working directory, so together, it means to install " -"the current directory (i.e. your project) in editable mode. This will also " -"install any dependencies declared with \"install_requires\" and any scripts " -"declared with \"console_scripts\". Dependencies will be installed in the " -"usual, non-editable mode." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:680 -msgid "" -"It's fairly common to also want to install some of your dependencies in " -"editable mode as well. For example, supposing your project requires \"foo\" " -"and \"bar\", but you want \"bar\" installed from VCS in editable mode, then " -"you could construct a requirements file like so::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:688 -msgid "" -"The first line says to install your project and any dependencies. The second " -"line overrides the \"bar\" dependency, such that it's fulfilled from VCS, " -"not PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:692 -msgid "" -"If, however, you want \"bar\" installed from a local directory in editable " -"mode, the requirements file should look like this, with the local paths at " -"the top of the file::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:697 -msgid "" -"Otherwise, the dependency will be fulfilled from PyPI, due to the " -"installation order of the requirements file. For more on requirements " -"files, see the :ref:`Requirements File ` section in " -"the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:701 -msgid "" -"Lastly, if you don't want to install any dependencies at all, you can run::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:706 -msgid "" -"For more information, see the `Development Mode `_ section of the " -"`setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:713 -msgid "Packaging your project" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:715 -msgid "" -"To have your project installable from a :term:`Package Index` like :term:" -"`PyPI `, you'll need to create a :term:" -"`Distribution ` (aka \":term:`Package `\") for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:720 -msgid "" -"Before you can build wheels and sdists for your project, you'll need to " -"install the ``build`` package:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:737 -msgid "Source distributions" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:739 -msgid "" -"Minimally, you should create a :term:`Source Distribution `:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:755 -msgid "" -"A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built " -"Distribution`), and requires a build step when installed by pip. Even if " -"the distribution is pure Python (i.e. contains no extensions), it still " -"involves a build step to build out the installation metadata from :file:" -"`setup.py` and/or :file:`setup.cfg`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:763 -msgid "Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:765 -msgid "" -"You should also create a wheel for your project. A wheel is a :term:`built " -"package ` that can be installed without needing to go " -"through the \"build\" process. Installing wheels is substantially faster for " -"the end user than installing from a source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:770 -msgid "" -"If your project is pure Python then you'll be creating a :ref:`\"Pure Python " -"Wheel\" (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:773 -msgid "" -"If your project contains compiled extensions, then you'll be creating what's " -"called a :ref:`*Platform Wheel* (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:776 -msgid "" -"If your project also supports Python 2 *and* contains no C extensions, then " -"you should create what's called a *Universal Wheel* by adding the following " -"to your :file:`setup.cfg` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:785 -msgid "" -"Only use this setting if your project does not have any C extensions *and* " -"supports Python 2 and 3." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:792 -msgid "Pure Python Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:794 -msgid "" -"*Pure Python Wheels* contain no compiled extensions, and therefore only " -"require a single Python wheel." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:797 -#: ../source/guides/distributing-packages-using-setuptools.rst:826 -msgid "To build the wheel:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:811 -msgid "" -"The ``wheel`` package will detect that the code is pure Python, and build a " -"wheel that's named such that it's usable on any Python 3 installation. For " -"details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:815 -msgid "" -"If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both " -"files for you; this is useful when you don't need multiple wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:821 -msgid "Platform Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:823 -msgid "" -"*Platform Wheels* are wheels that are specific to a certain platform like " -"Linux, macOS, or Windows, usually due to containing compiled extensions." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:841 -msgid "" -"The ``wheel`` package will detect that the code is not pure Python, and " -"build a wheel that's named such that it's only usable on the platform that " -"it was built on. For details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:847 -msgid "" -":term:`PyPI ` currently supports uploads of " -"platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. " -"Details of the latter are defined in :pep:`513`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:855 -msgid "Uploading your Project to PyPI" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:857 -msgid "" -"When you ran the command to create your distribution, a new directory ``dist/" -"`` was created under your project's root directory. That's where you'll find " -"your distribution file(s) to upload." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:861 -msgid "" -"These files are only created when you run the command to create your " -"distribution. This means that any time you change the source of your project " -"or the configuration in your :file:`setup.py` file, you will need to rebuild " -"these files again before you can distribute the changes to PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:866 -msgid "" -"Before releasing on main PyPI repo, you might prefer training with the `PyPI " -"test site `_ which is cleaned on a semi regular " -"basis. See :ref:`using-test-pypi` on how to setup your configuration in " -"order to use it." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:871 -msgid "" -"In other resources you may encounter references to using ``python setup.py " -"register`` and ``python setup.py upload``. These methods of registering and " -"uploading a package are **strongly discouraged** as it may use a plaintext " -"HTTP or unverified HTTPS connection on some Python versions, allowing your " -"username and password to be intercepted during transmission." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:877 -msgid "" -"The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to " -"ensure safety of all users, certain kinds of URLs and directives are " -"forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** " -"trying to upload your distribution, you should check to see if your brief / " -"long descriptions provided in :file:`setup.py` are valid. You can do this " -"by running :std:doc:`twine check ` on your package files::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:888 -msgid "Create an account" -msgstr "Створіть обліковий запис" - -#: ../source/guides/distributing-packages-using-setuptools.rst:890 -msgid "" -"First, you need a :term:`PyPI ` user account. " -"You can create an account `using the form on the PyPI website `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:894 -msgid "" -"Now you'll create a PyPI `API token`_ so you will be able to securely upload " -"your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:897 -msgid "" -"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " -"token`_; don't limit its scope to a particular project, since you are " -"creating a new project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:901 -msgid "" -"**Don't close the page until you have copied and saved the token — you won't " -"see that token again.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:904 -msgid "" -"To avoid having to copy and paste the token every time you upload, you can " -"create a :file:`$HOME/.pypirc` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:913 -msgid "**Be aware that this stores your token in plaintext.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:915 -#: ../source/guides/migrating-to-pypi-org.rst:70 -#: ../source/guides/migrating-to-pypi-org.rst:109 -#: ../source/guides/using-testpypi.rst:83 -msgid "" -"For more details, see the :ref:`specification ` for :file:`.pypirc`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:921 -msgid "Upload your distributions" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:923 -msgid "" -"Once you have an account you can upload your distributions to :term:`PyPI " -"` using :ref:`twine`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:926 -msgid "" -"The process for uploading a release is the same regardless of whether or not " -"the project already exists on PyPI - if it doesn't exist yet, it will be " -"automatically created when the first release is uploaded." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:930 -msgid "" -"For the second and subsequent releases, PyPI only requires that the version " -"number of the new release differ from any previous releases." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:937 -msgid "" -"You can see if your package has successfully uploaded by navigating to the " -"URL ``https://pypi.org/project/`` where ``sampleproject`` is " -"the name of your project that you uploaded. It may take a minute or two for " -"your project to appear on the site." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:944 -#: ../source/tutorials/installing-packages.rst:663 -msgid "" -"Depending on your platform, this may require root or Administrator access. :" -"ref:`pip` is currently considering changing this by `making user installs " -"the default behavior `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:950 -msgid "" -"Specifically, the \"console_script\" approach generates ``.exe`` files on " -"Windows, which are necessary because the OS special-cases ``.exe`` files. " -"Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for " -"Windows <397>` allow scripts to be used in many cases, but not all." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:5 -msgid "Dropping support for older Python versions" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:7 -msgid "" -"Dropping support for older Python versions is supported by the standard :ref:" -"`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:9 -msgid "" -"Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification " -"by matching the current Python runtime and comparing it with the required " -"version in the package metadata. If they do not match, it will attempt to " -"install the last package distribution that supported that Python runtime." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:12 -msgid "" -"This mechanism can be used to drop support for older Python versions, by " -"amending the \"Requires-Python\" attribute in the package metadata." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:14 -msgid "" -"This guide is specifically for users of :ref:`setuptools`, other packaging " -"tools such as ``flit`` may offer similar functionality but users will need " -"to consult relevant documentation." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:17 -msgid "Requirements" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:19 -msgid "This workflow requires that:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:21 -msgid "The publisher is using the latest version of :ref:`setuptools`," -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:22 -msgid "The latest version of :ref:`twine` is used to upload the package," -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:23 -msgid "" -"The user installing the package has at least Pip 9.0, or a client that " -"supports the Metadata 1.2 specification." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:26 -msgid "Dealing with the universal wheels" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:28 -msgid "" -"Traditionally, projects providing Python code that is semantically " -"compatible with both Python 2 and Python 3, produce :term:`wheels ` " -"that have a ``py2.py3`` tag in their names. When dropping support for Python " -"2, it is important not to forget to change this tag to just ``py3``. It is " -"often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` " -"section by setting ``universal = 1`` if they use setuptools." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:36 -msgid "" -"If you use this method, either remove this option or section, or explicitly " -"set ``universal`` to ``0``:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:48 -msgid "" -"Since it is possible to override the :file:`setup.cfg` settings via CLI " -"flags, make sure that your scripts don't have ``--universal`` in your " -"package creation scripts." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:53 -msgid "Defining the Python version required" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:56 -msgid "1. Download the newest version of Setuptools" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:58 -msgid "" -"Ensure that before you generate source distributions or binary " -"distributions, you update Setuptools and install twine." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:60 -msgid "Steps:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:74 -msgid "`setuptools` version should be above 24.0.0." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:77 -msgid "2. Specify the version ranges for supported Python distributions" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:79 -msgid "" -"You can specify version ranges and exclusion rules, such as at least Python " -"3. Or, Python 2.7, 3.4 and beyond." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:81 -#: ../source/specifications/core-metadata.rst:139 -#: ../source/specifications/core-metadata.rst:463 -#: ../source/specifications/core-metadata.rst:487 -#: ../source/specifications/core-metadata.rst:527 -#: ../source/specifications/core-metadata.rst:550 -#: ../source/specifications/core-metadata.rst:583 -#: ../source/specifications/core-metadata.rst:693 -#: ../source/specifications/core-metadata.rst:722 -msgid "Examples::" -msgstr "Приклади::" - -#: ../source/guides/dropping-older-python-versions.rst:86 -msgid "" -"The way to set those values is within the call to ``setup`` within your :" -"file:`setup.py` script. This will insert the ``Requires-Python`` metadata " -"values based on the argument you provide in ``python_requires``." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:101 -msgid "3. Validating the Metadata before publishing" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:103 -msgid "" -"Within a Python source package (the zip or the tar-gz file you download) is " -"a text file called PKG-INFO." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:105 -msgid "" -"This file is generated by Distutils or :ref:`setuptools` when it generates " -"the source package. The file contains a set of keys and values, the list of " -"keys is part of the PyPa standard metadata format." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:108 -msgid "You can see the contents of the generated file like this::" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:112 -msgid "Validate that the following is in place, before publishing the package:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:114 -msgid "" -"If you have upgraded correctly, the Metadata-Version value should be 1.2 or " -"higher." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:115 -msgid "" -"The Requires-Python field is set and matches your specification in setup.py." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:118 -msgid "4. Using Twine to publish" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:120 -msgid "" -"Twine has a number of advantages, apart from being faster it is now the " -"supported method for publishing packages." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:122 -msgid "Make sure you are using the newest version of Twine, at least 1.9." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:125 -msgid "Dropping a Python release" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:127 -msgid "" -"Once you have published a package with the Requires-Python metadata, you can " -"then make a further update removing that Python runtime from support." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:129 -msgid "It must be done in this order for the automated fallback to work." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:131 -msgid "" -"For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 " -"of your package." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:133 -msgid "" -"If you were then to update the version string to \">=3.5\", and publish a " -"new version 2.0.0 of your package, any users running Pip 9.0+ from version " -"2.7 will have version 1.0.0 of the package installed, and any >=3.5 users " -"will receive version 2.0.0." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:5 -msgid "Hosting your own simple repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:8 -msgid "" -"If you wish to host your own simple repository [1]_, you can either use a " -"software package like `devpi`_ or you can use simply create the proper " -"directory structure and use any web server that can serve static files and " -"generate an autoindex." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:13 -msgid "" -"In either case, since you'll be hosting a repository that is likely not in " -"your user's default repositories, you should instruct them in your project's " -"description to configure their installer appropriately. For example with pip:" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:29 -msgid "" -"In addition, it is **highly** recommended that you serve your repository " -"with valid HTTPS. At this time, the security of your user's installations " -"depends on all repositories using a valid HTTPS setup." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:35 -msgid "\"Manual\" repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:37 -msgid "" -"The directory layout is fairly simple, within a root directory you need to " -"create a directory for each project. This directory should be the normalized " -"name (as defined by :pep:`503`) of the project. Within each of these " -"directories simply place each of the downloadable files. If you have the " -"projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the " -"version 0.1) You should end up with a structure that looks like::" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:51 -msgid "" -"Once you have this layout, simply configure your webserver to serve the root " -"directory with autoindex enabled. For an example using the built in Web " -"server in `Twisted`_, you would simply run ``twistd -n web --path .`` and " -"then instruct users to add the URL to their installer's configuration." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:58 -msgid "" -"For complete documentation of the simple repository protocol, see :pep:`503`." -msgstr "" - -#: ../source/guides/index.rst:8 -msgid "Installing Packages:" -msgstr "" - -#: ../source/guides/index.rst:20 -msgid "Building and Publishing Projects:" -msgstr "" - -#: ../source/guides/index.rst:38 -msgid "Miscellaneous:" -msgstr "" - -#: ../source/guides/index.rst:4 -msgid "" -"**Guides** are focused on accomplishing a specific task and assume that you " -"are already familiar with the basics of Python packaging. If you're looking " -"for an introduction to packaging, see :doc:`/tutorials/index`." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:5 -msgid "Package index mirrors and caches" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:8 -#: ../source/guides/supporting-multiple-python-versions.rst:8 -msgid "2014-12-24" -msgstr "24.12.2014" - -#: ../source/guides/index-mirrors-and-caches.rst:14 -msgid "" -"Mirroring or caching of PyPI can be used to speed up local package " -"installation, allow offline work, handle corporate firewalls or just plain " -"Internet flakiness." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:17 -msgid "Three options are available in this area:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:19 -msgid "pip provides local caching options," -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:20 -msgid "" -"devpi provides higher-level caching option, potentially shared amongst many " -"users or machines, and" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:22 -msgid "" -"bandersnatch provides a local complete mirror of all PyPI :term:`packages " -"`." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:27 -msgid "Caching with pip" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:29 -msgid "" -"pip provides a number of facilities for speeding up installation by using " -"local cached copies of :term:`packages `:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:32 -msgid "" -"`Fast & local installs `_ by downloading all the requirements for a project and " -"then pointing pip at those downloaded files instead of going to PyPI." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:36 -msgid "" -"A variation on the above which pre-builds the installation files for the " -"requirements using `python -m pip wheel `_::" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:45 -msgid "Caching with devpi" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:47 -msgid "" -"devpi is a caching proxy server which you run on your laptop, or some other " -"machine you know will always be available to you. See the `devpi " -"documentation for getting started`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:55 -msgid "Complete mirror with bandersnatch" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:57 -msgid "" -"bandersnatch will set up a complete local mirror of all PyPI :term:`packages " -"` (externally-hosted packages are not mirrored). See " -"the `bandersnatch documentation for getting that going`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:63 -msgid "" -"A benefit of devpi is that it will create a mirror which includes :term:" -"`packages ` that are external to PyPI, unlike " -"bandersnatch which will only cache :term:`packages ` " -"hosted on PyPI." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:5 -msgid "Installing scientific packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:11 -msgid "" -"Scientific software tends to have more complex dependencies than most, and " -"it will often have multiple build options to take advantage of different " -"kinds of hardware, or to interoperate with different pieces of external " -"software." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:16 -msgid "" -"In particular, `NumPy `__, which provides the basis " -"for most of the software in the `scientific Python stack `__ can be configured to interoperate with " -"different FORTRAN libraries, and can take advantage of different levels of " -"vectorised instructions available in modern CPUs." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:22 -msgid "" -"Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built " -"32-bit and 64-bit binaries in the ``wheel`` format are available for all " -"major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, " -"that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, " -"so they may not provide optimal linear algebra performance." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:29 -msgid "" -"There are a number of alternative options for obtaining scientific Python " -"libraries (or any other Python libraries that require a compilation " -"environment to install from source and don't provide pre-built wheel files " -"on PyPI)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:35 -msgid "Building from source" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:37 -msgid "" -"The same complexity which makes it difficult to distribute NumPy (and many " -"of the projects that depend on it) as wheel files also make them difficult " -"to build from source yourself. However, for intrepid folks that are willing " -"to spend the time wrangling compilers and linkers for both C and FORTRAN, " -"building from source is always an option." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:45 -msgid "Linux distribution packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:47 -msgid "" -"For Linux users, the system package manager will often have pre-compiled " -"versions of various pieces of scientific software, including NumPy and other " -"parts of the scientific Python stack." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:51 -msgid "" -"If using versions which may be several months old is acceptable, then this " -"is likely to be a good option (just make sure to allow access to " -"distributions installed into the system Python when using virtual " -"environments)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:57 -msgid "Windows installers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:59 -msgid "" -"Many Python projects that don't (or can't) currently publish wheel files at " -"least publish Windows installers, either on PyPI or on their project " -"download page. Using these installers allows users to avoid the need to set " -"up a suitable environment to build extensions locally." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:64 -msgid "" -"The extensions provided in these installers are typically compatible with " -"the CPython Windows installers published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:67 -msgid "" -"For projects which don't provide their own Windows installers (and even some " -"which do), Christoph Gohlke at the University of California provides a " -"`collection of Windows installers `__. Many Python users on Windows have reported a positive experience with " -"these prebuilt versions." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:73 -msgid "" -"As with Linux system packages, the Windows installers will only install into " -"a system Python installation - they do not support installation in virtual " -"environments. Allowing access to distributions installed into the system " -"Python when using virtual environments is a common approach to working " -"around this limitation." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:79 -msgid "" -"The :term:`Wheel` project also provides a :command:`wheel convert` " -"subcommand that can convert a Windows :command:`bdist_wininst` installer to " -"a wheel." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:86 -msgid "macOS installers and package managers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:88 -msgid "" -"Similar to the situation on Windows, many projects (including NumPy) publish " -"macOS installers that are compatible with the macOS CPython binaries " -"published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:92 -msgid "" -"macOS users also have access to Linux distribution style package managers " -"such as ``MacPorts``. The SciPy site has more details on using MacPorts to " -"install the `scientific Python stack `__" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:99 -msgid "SciPy distributions" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:101 -msgid "" -"The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use " -"and update format." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:105 -msgid "" -"Some of these distributions may not be compatible with the standard ``pip`` " -"and ``virtualenv`` based toolchain." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:109 -#: ../source/key_projects.rst:596 -msgid "Spack" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:110 -msgid "" -"`Spack `_ is a flexible package manager " -"designed to support multiple versions, configurations, platforms, and " -"compilers. It was built to support the needs of large supercomputing centers " -"and scientific application teams, who must often build software many " -"different ways. Spack is not limited to Python; it can install packages for " -"``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-" -"destructive; installing a new version of one package does not break existing " -"installations, so many configurations can coexist on the same system." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:119 -msgid "" -"Spack offers a simple but powerful syntax that allows users to specify " -"versions and configuration options concisely. Package files are written in " -"pure Python, and they are templated so that it is easy to swap compilers, " -"dependency implementations (like MPI), versions, and build options with a " -"single package file. Spack also generates *module* files so that packages " -"can be loaded and unloaded from the user's environment." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:128 -msgid "The conda cross-platform package manager" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:130 -msgid "" -"`Anaconda `_ is a Python distribution " -"published by Anaconda, Inc. It is a stable collection of Open Source " -"packages for big data and scientific use. As of the 5.0 release of " -"Anaconda, about 200 packages are installed by default, and a total of " -"400-500 can be installed and updated from the Anaconda repository." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:136 -msgid "" -"``conda`` is an open source (BSD licensed) package management system and " -"environment management system included in Anaconda that allows users to " -"install multiple versions of binary software packages and their " -"dependencies, and easily switch between them. It is a cross-platform tool " -"working on Windows, macOS, and Linux. Conda can be used to package up and " -"distribute all kinds of packages, it is not limited to just Python packages. " -"It has full support for native virtual environments. Conda makes " -"environments first-class citizens, making it easy to create independent " -"environments even for C libraries. It is written in Python, but is Python-" -"agnostic. Conda manages Python itself as a package, so that :command:`conda " -"update python` is possible, in contrast to pip, which only manages Python " -"packages. Conda is available in Anaconda and Miniconda (an easy-to-install " -"download with just Python and conda)." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 -msgid "Installing stand alone command line tools" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 -msgid "" -"Many packages have command line entry points. Examples of this type of " -"application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 -msgid "" -"Usually you want to be able to access these from anywhere, but installing " -"packages and their dependencies to the same global environment can cause " -"version conflicts and break dependencies the operating system has on Python " -"packages." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 -msgid "" -":ref:`pipx` solves this by creating a virtual environment for each package, " -"while also ensuring that package's applications are accessible through a " -"directory that is on your ``$PATH``. This allows each package to be upgraded " -"or uninstalled without causing conflicts with other packages, and allows you " -"to safely run the program from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 -msgid "pipx only works with Python 3.6+." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 -msgid "``pipx`` is installed with ``pip``:" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 -msgid "" -"You may need to restart your terminal for the path updates to take effect." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 -msgid "" -"Now you can install packages with ``pipx install`` and access the package's " -"entry point(s) from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 -#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 -msgid "For example" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 -msgid "" -"To see a list of packages installed with pipx and which CLI applications are " -"available, use ``pipx list``." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 -msgid "To upgrade or uninstall the package" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 -msgid "``pipx`` can be upgraded or uninstalled with pip" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 -msgid "" -"``pipx`` also allows you to install and run the latest version of a cli tool " -"in a temporary, ephemeral environment." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 -msgid "To see the full list of commands ``pipx`` offers, run" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 -msgid "" -"You can learn more about ``pipx`` at its homepage, https://github.com/pypa/" -"pipx." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:5 -msgid "Installing pip/setuptools/wheel with Linux Package Managers" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:8 -msgid "2015-09-17" -msgstr "17.09.2015" - -#: ../source/guides/installing-using-linux-tools.rst:11 -msgid "" -"This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:" -"`wheel` using Linux package managers." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:14 -msgid "" -"If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:" -"`installing_requirements` section instead." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:18 -msgid "" -"Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, " -"and :ref:`wheel` supported by a specific Linux Distribution to be outdated " -"by the time it's released to the public, and updates generally only occur " -"for security reasons, not for feature updates. For certain Distributions, " -"there are additional repositories that can be enabled to provide newer " -"versions. The repositories we know about are explained below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:25 -msgid "" -"Also note that it's somewhat common for Distributions to apply patches for " -"the sake of security and normalization to their own standards. In some " -"cases, this can lead to bugs or unexpected behaviors that vary from the " -"original unpatched versions. When this is known, we will make note of it " -"below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:32 -msgid "Fedora" -msgstr "Fedora" - -#: ../source/guides/installing-using-linux-tools.rst:34 -msgid "Fedora 21:" -msgstr "Fedora 21:" - -#: ../source/guides/installing-using-linux-tools.rst:36 -#: ../source/guides/installing-using-linux-tools.rst:45 -#: ../source/guides/installing-using-linux-tools.rst:124 -#: ../source/guides/installing-using-linux-tools.rst:138 -#: ../source/guides/installing-using-linux-tools.rst:158 -msgid "Python 2::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:41 -msgid "Python 3: ``sudo yum install python3 python3-wheel``" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:43 -msgid "Fedora 22:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:50 -msgid "Python 3: ``sudo dnf install python3 python3-wheel``" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:53 -msgid "" -"To get newer versions of pip, setuptools, and wheel for Python 2, you can " -"enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:63 -msgid "CentOS/RHEL" -msgstr "CentOS/RHEL" - -#: ../source/guides/installing-using-linux-tools.rst:65 -msgid "" -"CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core " -"repositories, although :ref:`setuptools` is installed by default." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:68 -msgid "To install pip and wheel for the system Python, there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:70 -msgid "" -"Enable the `EPEL repository `_ using " -"`these instructions `__. On EPEL 6 and EPEL7, you can " -"install pip like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:77 -msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:81 -msgid "" -"Since EPEL only offers extra, non-conflicting packages, EPEL does not offer " -"setuptools, since it's in the core repository." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:85 -msgid "" -"Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:92 -msgid "To additionally upgrade setuptools, run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:97 -msgid "" -"To install pip, wheel, and setuptools, in a parallel, non-system environment " -"(using yum) then there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:101 -msgid "" -"Use the \"Software Collections\" feature to enable a parallel collection " -"that includes pip, setuptools, and wheel." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:104 -msgid "" -"For Redhat, see here: http://developers.redhat.com/products/" -"softwarecollections/overview/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:106 -msgid "For CentOS, see here: https://www.softwarecollections.org/en/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:108 -msgid "Be aware that collections may not contain the most recent versions." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:110 -msgid "" -"Enable the `IUS repository `_ and install " -"one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which " -"are kept fairly up to date." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:116 -msgid "For example, for Python 3.4 on CentOS7/RHEL7::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:122 -msgid "openSUSE" -msgstr "openSUSE" - -#: ../source/guides/installing-using-linux-tools.rst:129 -#: ../source/guides/installing-using-linux-tools.rst:143 -#: ../source/guides/installing-using-linux-tools.rst:162 -msgid "Python 3::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:135 -msgid "Debian/Ubuntu" -msgstr "Debian/Ubuntu" - -#: ../source/guides/installing-using-linux-tools.rst:150 -msgid "" -"Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" " -"`_ by default, " -"which is a significant behavior change that can be surprising to some users." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:156 -msgid "Arch Linux" -msgstr "Arch Linux" - -#: ../source/guides/installing-using-linux-tools.rst:168 -msgid "" -"Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the " -"only option is to manually place the repo files as described." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 -msgid "Installing packages using pip and virtual environments" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 -msgid "" -"This guide discusses how to install packages using :ref:`pip` and a virtual " -"environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` " -"for Python 2. These are the lowest-level tools for managing Python packages " -"and are recommended if higher-level tools do not suit your needs." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 -msgid "" -"This doc uses the term **package** to refer to a :term:`Distribution " -"Package` which is different from an :term:`Import Package` that which is " -"used to import modules in your Python source code." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 -msgid "Installing pip" -msgstr "Встановлення pip" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 -msgid "" -":ref:`pip` is the reference Python package manager. It's used to install and " -"update packages. You'll need to make sure you have the latest version of pip " -"installed." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 -msgid "" -"Debian and most other distributions include a `python-pip`_ package, if you " -"want to use the Linux distribution-provided versions of pip see :doc:`/" -"guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 -msgid "" -"You can also install pip yourself to ensure you have the latest version. " -"It's recommended to use the system pip to bootstrap a user installation of " -"pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 -msgid "Afterwards, you should have the newest pip installed in your user site:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 -msgid "" -"The Python installers for Windows include pip. You should be able to access " -"pip using:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 -msgid "You can make sure that pip is up-to-date by running:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 -msgid "Installing virtualenv" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 -msgid "" -"If you are using Python 3.3 or newer, the :mod:`venv` module is the " -"preferred way to create and manage virtual environments. venv is included in " -"the Python standard library and requires no additional installation. If you " -"are using venv, you may skip this section." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 -msgid "" -":ref:`virtualenv` is used to manage Python packages for different projects. " -"Using virtualenv allows you to avoid installing Python packages globally " -"which could break system tools or other projects. You can install virtualenv " -"using pip." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 -msgid "Creating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 -msgid "" -":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to " -"manage separate package installations for different projects. They " -"essentially allow you to create a \"virtual\" isolated Python installation " -"and install packages into that virtual installation. When you switch " -"projects, you can simply create a new virtual environment and not have to " -"worry about breaking the packages installed in the other environments. It is " -"always recommended to use a virtual environment while developing Python " -"applications." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 -msgid "" -"To create a virtual environment, go to your project's directory and run " -"venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the " -"below commands." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 -msgid "" -"The second argument is the location to create the virtual environment. " -"Generally, you can just create this in your project and call it ``env``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 -msgid "venv will create a virtual Python installation in the ``env`` folder." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 -msgid "" -"You should exclude your virtual environment directory from your version " -"control system using ``.gitignore`` or similar." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 -msgid "Activating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 -msgid "" -"Before you can start installing or using packages in your virtual " -"environment you'll need to *activate* it. Activating a virtual environment " -"will put the virtual environment-specific ``python`` and ``pip`` executables " -"into your shell's ``PATH``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 -msgid "" -"You can confirm you're in the virtual environment by checking the location " -"of your Python interpreter, it should point to the ``env`` directory." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 -msgid "" -"As long as your virtual environment is activated pip will install packages " -"into that specific environment and you'll be able to import and use packages " -"in your Python application." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 -msgid "Leaving the virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 -msgid "" -"If you want to switch projects or otherwise leave your virtual environment, " -"simply run:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 -msgid "" -"If you want to re-enter the virtual environment just follow the same " -"instructions above about activating a virtual environment. There's no need " -"to re-create the virtual environment." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 -msgid "Installing packages" -msgstr "Встановлення пакунків" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 -msgid "" -"Now that you're in your virtual environment you can install packages. Let's " -"install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 -msgid "" -"pip should download requests and all of its dependencies and install them:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 -msgid "Installing specific versions" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 -msgid "" -"pip allows you to specify which version of a package to install using :term:" -"`version specifiers `. For example, to install a specific " -"version of ``requests``:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 -msgid "To install the latest ``2.x`` release of requests:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 -msgid "To install pre-release versions of packages, use the ``--pre`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 -msgid "Installing extras" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 -msgid "" -"Some packages have optional `extras`_. You can tell pip to install these by " -"specifying the extra in brackets:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 -msgid "Installing from source" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 -msgid "pip can install a package directly from source, for example:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 -msgid "" -"Additionally, pip can install packages from source in `development mode`_, " -"meaning that changes to the source directory will immediately affect the " -"installed package without needing to re-install:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 -msgid "Installing from version control systems" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 -msgid "" -"pip can install packages directly from their version control system. For " -"example, you can install directly from a git repository:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 -msgid "" -"For more information on supported version control systems and syntax, see " -"pip's documentation on :ref:`VCS Support `." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 -#: ../source/tutorials/installing-packages.rst:569 -msgid "Installing from local archives" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 -msgid "" -"If you have a local copy of a :term:`Distribution Package`'s archive (a zip, " -"wheel, or tar file) you can install it directly with pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 -msgid "" -"If you have a directory containing archives of multiple packages, you can " -"tell pip to look for packages there and not to use the :term:`Python Package " -"Index (PyPI)` at all:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 -msgid "" -"This is useful if you are installing packages on a system with limited " -"connectivity or if you want to strictly control the origin of distribution " -"packages." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 -msgid "Using other package indexes" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 -msgid "" -"If you want to download packages from a different index than the :term:" -"`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 -msgid "" -"If you want to allow packages from both the :term:`Python Package Index " -"(PyPI)` and a separate index, you can use the ``--extra-index-url`` flag " -"instead:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 -#: ../source/tutorials/installing-packages.rst:389 -msgid "Upgrading packages" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 -msgid "" -"pip can upgrade packages in-place using the ``--upgrade`` flag. For example, " -"to install the latest version of ``requests`` and all of its dependencies:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 -msgid "Using requirements files" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 -msgid "" -"Instead of installing packages individually, pip allows you to declare all " -"dependencies in a :ref:`Requirements File `. For " -"example you could create a :file:`requirements.txt` file containing:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 -msgid "" -"And tell pip to install all of the packages in this file using the ``-r`` " -"flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 -msgid "Freezing dependencies" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 -msgid "" -"Pip can export a list of all installed packages and their versions using the " -"``freeze`` command:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 -msgid "Which will output a list of package specifiers such as:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 -msgid "" -"This is useful for creating :ref:`pip:Requirements Files` that can re-create " -"the exact versions of all packages installed in an environment." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:2 -msgid "Making a PyPI-friendly README" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:4 -msgid "" -"README files can help your users understand your project and can be used to " -"set your project's description on PyPI. This guide helps you create a README " -"in a PyPI-friendly format and include your README in your package so it " -"appears on PyPI." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:9 -msgid "Creating a README file" -msgstr "Створення файлу README" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:11 -msgid "" -"README files for Python projects are often named ``README``, ``README.txt``, " -"``README.rst``, or ``README.md``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:13 -msgid "" -"For your README to display properly on PyPI, choose a markup language " -"supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:16 -msgid "plain text" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:17 -msgid "" -"`reStructuredText `_ (without " -"Sphinx extensions)" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:18 -msgid "" -"Markdown (`GitHub Flavored Markdown `_ by " -"default, or `CommonMark `_)" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:21 -msgid "" -"It's customary to save your README file in the root of your project, in the " -"same directory as your :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:25 -msgid "Including your README in your package's metadata" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:27 -msgid "" -"To include your README's contents as your package description, set your " -"project's ``Description`` and ``Description-Content-Type`` metadata, " -"typically in your project's :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:33 -msgid ":ref:`description-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:34 -msgid ":ref:`description-content-type-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:36 -msgid "" -"For example, to set these values in a package's :file:`setup.py` file, use " -"``setup()``'s ``long_description`` and ``long_description_content_type``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:39 -msgid "" -"Set the value of ``long_description`` to the contents (not the path) of the " -"README file itself. Set the ``long_description_content_type`` to an accepted " -"``Content-Type``-style value for your README file's markup, such as ``text/" -"plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:45 -msgid "" -"If you're using GitHub-flavored Markdown to write a project's description, " -"ensure you upgrade the following tools:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:60 -msgid "The minimum required versions of the respective tools are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:62 -msgid "``setuptools >= 38.6.0``" -msgstr "``setuptools >= 38.6.0``" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:63 -msgid "``wheel >= 0.31.0``" -msgstr "``wheel >= 0.31.0``" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:64 -msgid "``twine >= 1.11.0``" -msgstr "``twine >= 1.11.0``" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:66 -msgid "" -"It's recommended that you use ``twine`` to upload the project's distribution " -"packages:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:72 -msgid "" -"For example, see this :file:`setup.py` file, which reads the contents of :" -"file:`README.md` as ``long_description`` and identifies the markup as GitHub-" -"flavored Markdown:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:95 -msgid "Validating reStructuredText markup" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:97 -msgid "" -"If your README is written in reStructuredText, any invalid markup will " -"prevent it from rendering, causing PyPI to instead just show the README's " -"raw source." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:100 -msgid "" -"Note that Sphinx extensions used in docstrings, such as `directives and " -"roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```" -"\"), are not allowed here and will result in error messages like \"``Error: " -"Unknown interpreted text role \"py:func\".``\"." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:105 -msgid "" -"You can check your README for markup errors before uploading as follows:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:107 -msgid "" -"Install the latest version of `twine `_; " -"version 1.12.0 or higher is required:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:122 -msgid "" -"Build the sdist and wheel for your project as described under :ref:" -"`Packaging Your Project`." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:125 -msgid "Run ``twine check`` on the sdist and wheel::" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:129 -msgid "" -"This command will report any problems rendering your README. If your markup " -"renders fine, the command will output ``Checking distribution FILENAME: " -"Passed``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:4 -msgid "Migrating to PyPI.org" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:6 -msgid "" -":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``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:12 -msgid "Publishing releases" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:14 -msgid "``pypi.org`` is the default upload platform as of September 2016." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:16 -msgid "" -"Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. " -"As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:19 -msgid "" -"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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:22 -msgid "" -"The default upload settings switched to ``pypi.org`` in the following " -"versions:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:24 -msgid "``twine`` 1.8.0" -msgstr "``twine`` 1.8.0" - -#: ../source/guides/migrating-to-pypi-org.rst:25 -msgid "``setuptools`` 27.0.0" -msgstr "``setuptools`` 27.0.0" - -#: ../source/guides/migrating-to-pypi-org.rst:26 -msgid "Python 2.7.13 (``distutils`` update)" -msgstr "Python 2.7.13 (оновлення ``distutils``)" - -#: ../source/guides/migrating-to-pypi-org.rst:27 -msgid "Python 3.4.6 (``distutils`` update)" -msgstr "Python 3.4.6 (оновлення ``distutils``)" - -#: ../source/guides/migrating-to-pypi-org.rst:28 -msgid "Python 3.5.3 (``distutils`` update)" -msgstr "Python 3.5.3 (оновлення ``distutils``)" - -#: ../source/guides/migrating-to-pypi-org.rst:29 -msgid "Python 3.6.0 (``distutils`` update)" -msgstr "Python 3.6.0 (оновлення ``distutils``)" - -#: ../source/guides/migrating-to-pypi-org.rst:31 -msgid "" -"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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:48 -msgid "" -"Then simply delete the line starting with ``repository`` and you will use " -"your upload tool's default URL." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:51 -msgid "" -"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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:67 -msgid "" -"(``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.)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:73 -msgid "Registering package names & metadata" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:75 -msgid "" -"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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:79 -msgid "" -"As a result, attempting explicit registration after switching to using PyPI." -"org for uploads will give the following error message::" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:84 -msgid "" -"The solution is to skip the registration step, and proceed directly to " -"uploading artifacts." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:89 -#: ../source/guides/using-testpypi.rst:5 -msgid "Using TestPyPI" -msgstr "Використання TestPyPI" - -#: ../source/guides/migrating-to-pypi-org.rst:91 -msgid "" -"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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:113 -msgid "Registering new user accounts" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:115 -msgid "" -"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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:121 -msgid "Browsing packages" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:123 -msgid "" -"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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:130 -msgid "Downloading packages" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:132 -msgid "``pypi.org`` is the default host for downloading packages." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:135 -msgid "Managing published packages and releases" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:137 -msgid "" -"``pypi.org`` provides a fully functional interface for logged in users to " -"manage their published packages and releases." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:5 -msgid "Multi-version installs" -msgstr "" - -#: ../source/guides/multi-version-installs.rst:8 -msgid "" -"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``)." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:13 -msgid "" -"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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:19 -msgid "" -"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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:31 -msgid "" -"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 ``python -c ''`` to invoke the application's main " -"entry point directly." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:38 -msgid "" -"Refer to the `pkg_resources documentation `__ for more details." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:5 -msgid "Packaging binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:8 -msgid "2013-12-08" -msgstr "08.12.2013" - -#: ../source/guides/packaging-binary-extensions.rst:10 -msgid "" -"One of the features of the CPython reference interpreter is that, in " -"addition to allowing the execution of Python code, it also exposes a rich C " -"API for use by other software. One of the most common uses of this C API is " -"to create importable C extensions that allow things which aren't always easy " -"to achieve in pure Python code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:20 -msgid "An overview of binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:23 -msgid "Use cases" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:25 -msgid "" -"The typical use cases for binary extensions break down into just three " -"conventional categories:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:28 -msgid "" -"**accelerator modules**: these modules are completely self-contained, and " -"are created solely to run faster than the equivalent pure Python code runs " -"in CPython. Ideally, accelerator modules will always have a pure Python " -"equivalent to use as a fallback if the accelerated version isn't available " -"on a given system. The CPython standard library makes extensive use of " -"accelerator modules. *Example*: When importing ``datetime``, Python falls " -"back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not " -"available." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:39 -msgid "" -"**wrapper modules**: these modules are created to expose existing C " -"interfaces to Python code. They may either expose the underlying C interface " -"directly, or else expose a more \"Pythonic\" API that makes use of Python " -"language features to make the API easier to use. The CPython standard " -"library makes extensive use of wrapper modules. *Example*: `functools.py " -"`_ is a " -"Python module wrapper for `_functoolsmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:47 -msgid "" -"**low-level system access**: these modules are created to access lower level " -"features of the CPython runtime, the operating system, or the underlying " -"hardware. Through platform specific code, extension modules may achieve " -"things that aren't possible in pure Python code. A number of CPython " -"standard library modules are written in C in order to access interpreter " -"internals that aren't exposed at the language level. *Example*: ``sys``, " -"which comes from `sysmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:56 -msgid "" -"One particularly notable feature of C extensions is that, when they don't " -"need to call back into the interpreter runtime, they can release CPython's " -"global interpreter lock around long-running operations (regardless of " -"whether those operations are CPU or IO bound)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:61 -msgid "" -"Not all extension modules will fit neatly into the above categories. The " -"extension modules included with NumPy, for example, span all three use cases " -"- they move inner loops to C for speed reasons, wrap external libraries " -"written in C, FORTRAN and other languages, and use low level system " -"interfaces for both CPython and the underlying operation system to support " -"concurrent execution of vectorised operations and to tightly control the " -"exact memory layout of created objects." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:71 -msgid "Disadvantages" -msgstr "Недоліки" - -#: ../source/guides/packaging-binary-extensions.rst:73 -msgid "" -"The main disadvantage of using binary extensions is the fact that it makes " -"subsequent distribution of the software more difficult. One of the " -"advantages of using Python is that it is largely cross platform, and the " -"languages used to write extension modules (typically C or C++, but really " -"any language that can bind to the CPython C API) typically require that " -"custom binaries be created for different platforms." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:80 -msgid "This means that binary extensions:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:82 -msgid "" -"require that end users be able to either build them from source, or else " -"that someone publish pre-built binaries for common platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:85 -msgid "" -"may not be compatible with different builds of the CPython reference " -"interpreter" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:88 -msgid "" -"often will not work correctly with alternative interpreters such as PyPy, " -"IronPython or Jython" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:91 -msgid "" -"if handcoded, make maintenance more difficult by requiring that maintainers " -"be familiar not only with Python, but also with the language used to create " -"the binary extension, as well as with the details of the CPython C API." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:96 -msgid "" -"if a pure Python fallback implementation is provided, make maintenance more " -"difficult by requiring that changes be implemented in two places, and " -"introducing additional complexity in the test suite to ensure both versions " -"are always executed." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:101 -msgid "" -"Another disadvantage of relying on binary extensions is that alternative " -"import mechanisms (such as the ability to import modules directly from " -"zipfiles) often won't work for extension modules (as the dynamic loading " -"mechanisms on most platforms can only load libraries from disk)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:108 -msgid "Alternatives to handcoded accelerator modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:110 -msgid "" -"When extension modules are just being used to make code run faster (after " -"profiling has identified the code where the speed increase is worth " -"additional maintenance effort), a number of other alternatives should also " -"be considered:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:115 -msgid "" -"look for existing optimised alternatives. The CPython standard library " -"includes a number of optimised data structures and algorithms (especially in " -"the builtins and the ``collections`` and ``itertools`` modules). The Python " -"Package Index also offers additional alternatives. Sometimes, the " -"appropriate choice of standard library or third party module can avoid the " -"need to create your own accelerator module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:122 -msgid "" -"for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython " -"runtime. The main barrier to adopting PyPy is typically reliance on other " -"binary extension modules - while PyPy does emulate the CPython C API, " -"modules that rely on that cause problems for the PyPy JIT, and the emulation " -"layer can often expose latent defects in extension modules that CPython " -"currently tolerates (frequently around reference counting errors - an object " -"having one live reference instead of two often won't break anything, but no " -"references instead of one is a major problem)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:132 -msgid "" -"`Cython `__ is a mature static compiler that can compile " -"most Python code to C extension modules. The initial compilation provides " -"some speed increases (by bypassing the CPython interpreter layer), and " -"Cython's optional static typing features can offer additional opportunities " -"for speed increases. Using Cython still has the disadvantage of increasing " -"the complexity of distributing the resulting application, but has the " -"benefit of having a reduced barrier to entry for Python programmers " -"(relative to other languages like C or C++)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:141 -msgid "" -"`Numba `__ is a newer tool, created by members of " -"the scientific Python community, that aims to leverage LLVM to allow " -"selective compilation of pieces of a Python application to native machine " -"code at runtime. It requires that LLVM be available on the system where the " -"code is running, but can provide significant speed increases, especially for " -"operations that are amenable to vectorisation." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:150 -msgid "Alternatives to handcoded wrapper modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:152 -msgid "" -"The C ABI (Application Binary Interface) is a common standard for sharing " -"functionality between multiple applications. One of the strengths of the " -"CPython C API (Application Programming Interface) is allowing Python users " -"to tap into that functionality. However, wrapping modules by hand is quite " -"tedious, so a number of other alternative approaches should be considered." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:158 -msgid "" -"The approaches described below don't simplify the distribution case at all, " -"but they *can* significantly reduce the maintenance burden of keeping " -"wrapper modules up to date." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:162 -msgid "" -"In addition to being useful for the creation of accelerator modules, `Cython " -"`__ is also useful for creating wrapper modules for C or " -"C++. It still involves wrapping the interfaces by hand, however, and is very " -"repetitive, so may not be a good choice for wrapping large APIs." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:168 -msgid "" -"`pybind11 `__ is a pure C++11 library that " -"provides a clean C++ interface to the CPython (and PyPy) C API. It does not " -"require a pre-processing step; it is written entirely in templated C++. " -"Helpers are included for Setuptools or CMake builds. It was based on `Boost." -"Python `__, but doesn't require the Boost libraries or BJam." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:175 -msgid "" -"`cffi `__ is a project created by some of the " -"PyPy developers to make it straightforward for developers that already know " -"both Python and C to expose their C modules to Python applications. It also " -"makes it relatively straightforward to wrap a C module based on its header " -"files, even if you don't know C yourself." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:181 -msgid "" -"One of the key advantages of ``cffi`` is that it is compatible with the PyPy " -"JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing " -"JIT optimisations." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:185 -msgid "" -"`SWIG `__ is a wrapper interface generator that allows " -"a variety of programming languages, including Python, to interface with C " -"and C++ code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:189 -msgid "" -"The standard library's ``ctypes`` module, while useful for getting access to " -"C level interfaces when header information isn't available, suffers from the " -"fact that it operates solely at the C ABI level, and thus has no automatic " -"consistency checking between the interface actually being exported by the " -"library and the one declared in the Python code. By contrast, the above " -"alternatives are all able to operate at the C *API* level, using C header " -"files to ensure consistency between the interface exported by the library " -"being wrapped and the one expected by the Python wrapper module. While " -"``cffi`` *can* operate directly at the C ABI level, it suffers from the same " -"interface inconsistency problems as ``ctypes`` when it is used that way." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:203 -msgid "Alternatives for low level system access" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:205 -msgid "" -"For applications that need low level system access (regardless of the " -"reason), a binary extension module often *is* the best way to go about it. " -"This is particularly true for low level access to the CPython runtime " -"itself, since some operations (like releasing the Global Interpreter Lock) " -"are simply invalid when the interpreter is running code, even if a module " -"like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API " -"interfaces." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:213 -msgid "" -"For cases where the extension module is manipulating the underlying " -"operating system or hardware (rather than the CPython runtime), it may " -"sometimes be better to just write an ordinary C library (or a library in " -"another systems programming language like C++ or Rust that can export a C " -"compatible ABI), and then use one of the wrapping techniques described above " -"to make the interface available as an importable Python module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:222 -msgid "Implementing binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:224 -msgid "" -"The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in " -"C `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:241 -msgid "Building binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:244 -msgid "Building extensions for multiple platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:246 -msgid "" -"If you plan to distribute your extension, you should provide :term:`wheels " -"` for all the platforms you intend to support. For most extensions, " -"this is at least one package per Python version times the number of OS and " -"architectures you support. These are usually built on continuous " -"integration (CI) systems. There are tools to help you build highly " -"redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:" -"`multibuild`." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:256 -msgid "Binary extensions for Windows" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:258 -msgid "" -"Before it is possible to build a binary extension, it is necessary to ensure " -"that you have a suitable compiler available. On Windows, Visual C is used to " -"build the official CPython interpreter, and should be used to build " -"compatible binary extensions." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:263 -msgid "" -"Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio " -"2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older " -"versions of Visual Studio are no longer easily available from Microsoft, so " -"for versions of Python prior to 3.5, the compilers must be obtained " -"differently if you do not already have a copy of the relevant version of " -"Visual Studio." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:269 -msgid "" -"To set up a build environment for binary extensions, the steps are as " -"follows:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:271 -msgid "For Python 2.7" -msgstr "Для Python 2.7" - -#: ../source/guides/packaging-binary-extensions.rst:273 -msgid "" -"Install \"Visual C++ Compiler Package for Python 2.7\", which is available " -"from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:276 -msgid "" -"Use (a recent version of) setuptools in your setup.py (pip will do this for " -"you, in any case)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:278 -#: ../source/guides/packaging-binary-extensions.rst:288 -#: ../source/guides/packaging-binary-extensions.rst:295 -msgid "Done." -msgstr "Готово." - -#: ../source/guides/packaging-binary-extensions.rst:280 -msgid "For Python 3.4" -msgstr "Для Python 3.4" - -#: ../source/guides/packaging-binary-extensions.rst:282 -msgid "" -"Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is " -"available from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:285 -msgid "" -"Work from an SDK command prompt (with the environment variables set, and the " -"SDK on PATH)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:287 -msgid "Set DISTUTILS_USE_SDK=1" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:290 -msgid "For Python 3.5" -msgstr "Для Python 3.5" - -#: ../source/guides/packaging-binary-extensions.rst:292 -msgid "" -"Install `Visual Studio 2015 Community Edition `__ (or any later version, " -"when these are released)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:297 -msgid "" -"Note that from Python 3.5 onwards, Visual Studio works in a backward " -"compatible way, which means that any future version of Visual Studio will be " -"able to build Python extensions for all Python versions from 3.5 onwards." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:301 -msgid "" -"Building with the recommended compiler on Windows ensures that a compatible " -"C library is used throughout the Python process." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:305 -msgid "Binary extensions for Linux" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:307 -msgid "" -"Linux binaries must use a sufficiently old glibc to be compatible with older " -"distributions. The `manylinux `_ Docker " -"images provide a build environment with a glibc old enough to support most " -"current Linux distributions on common architectures." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:313 -msgid "Binary extensions for macOS" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:315 -msgid "" -"Binary compatibility on macOS is determined by the target minimum deployment " -"system, e.g. *10.9*, which is often specified with the " -"``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries " -"on macOS. When building with setuptools / distutils, the deployment target " -"is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For " -"common deployment targets for macOS Python distributions, see the `MacPython " -"Spinning Wheels wiki `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:325 -msgid "Publishing binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:327 -msgid "" -"For interim guidance on this topic, see the discussion in `this issue " -"`_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:343 -msgid "Additional resources" -msgstr "Додаткові матеріали" - -#: ../source/guides/packaging-binary-extensions.rst:345 -msgid "" -"Cross-platform development and distribution of extension modules is a " -"complex topic, so this guide focuses primarily on providing pointers to " -"various tools that automate dealing with the underlying technical " -"challenges. The additional resources in this section are instead intended " -"for developers looking to understand more about the underlying binary " -"interfaces that those systems rely on at runtime." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:352 -msgid "Cross-platform wheel generation with scikit-build" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:354 -msgid "" -"The `scikit-build `_ package " -"helps abstract cross-platform build operations and provides additional " -"capabilities when creating binary extension packages. Additional " -"documentation is also available on the `C runtime, compiler, and build " -"system generator `_ for Python binary extension modules." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:362 -msgid "Introduction to C/C++ extension modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:364 -msgid "" -"For a more in depth explanation of how extension modules are used by CPython " -"on a Debian system, see the following articles:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:367 -msgid "" -"`What are (c)python extension modules? `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:368 -msgid "`Releasing the gil `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:369 -msgid "" -"`Writing cpython extension modules using C++ `_" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:3 -msgid "Packaging namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:5 -msgid "" -"Namespace packages allow you to split the sub-packages and modules within a " -"single :term:`package ` across multiple, separate :term:" -"`distribution packages ` (referred to as " -"**distributions** in this document to avoid ambiguity). For example, if you " -"have the following package structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:24 -msgid "And you use this package in your code like so::" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:29 -msgid "Then you can break these sub-packages into two separate distributions:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:46 -msgid "Each sub-package can now be separately installed, used, and versioned." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:48 -msgid "" -"Namespace packages can be useful for a large collection of loosely-related " -"packages (such as a large corpus of client libraries for multiple products " -"from a single company). However, namespace packages come with several " -"caveats and are not appropriate in all cases. A simple alternative is to use " -"a prefix on all of your distributions such as ``import " -"mynamespace_subpackage_a`` (you could even use ``import " -"mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:58 -msgid "Creating a namespace package" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:60 -msgid "" -"There are currently three different approaches to creating namespace " -"packages:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:62 -msgid "" -"Use `native namespace packages`_. This type of namespace package is defined " -"in :pep:`420` and is available in Python 3.3 and later. This is recommended " -"if packages in your namespace only ever need to support Python 3 and " -"installation via ``pip``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:66 -msgid "" -"Use `pkgutil-style namespace packages`_. This is recommended for new " -"packages that need to support Python 2 and 3 and installation via both " -"``pip`` and ``python setup.py install``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:69 -msgid "" -"Use `pkg_resources-style namespace packages`_. This method is recommended if " -"you need compatibility with packages already using this method or if your " -"package needs to be zip-safe." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:73 -msgid "" -"While native namespace packages and pkgutil-style namespace packages are " -"largely compatible, pkg_resources-style namespace packages are not " -"compatible with the other methods. It's inadvisable to use different methods " -"in different distributions that provide packages to the same namespace." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:80 -msgid "Native namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:82 -msgid "" -"Python 3.3 added **implicit** namespace packages from :pep:`420`. All that " -"is required to create a native namespace package is that you just omit :file:" -"`__init__.py` from the namespace package directory. An example file " -"structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:97 -msgid "" -"It is extremely important that every distribution that uses the namespace " -"package omits the :file:`__init__.py` or uses a pkgutil-style :file:" -"`__init__.py`. If any distribution does not, it will cause the namespace " -"logic to fail and the other sub-packages will not be importable." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:102 -msgid "" -"Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:" -"`setuptools.find_packages` won't find the sub-package. You must use :func:" -"`setuptools.find_namespace_packages` instead or explicitly list all packages " -"in your :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:117 -msgid "" -"A complete working example of two native namespace packages can be found in " -"the `native namespace package example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:123 -msgid "" -"Because native and pkgutil-style namespace packages are largely compatible, " -"you can use native namespace packages in the distributions that only support " -"Python 3 and pkgutil-style namespace packages in the distributions that need " -"to support Python 2 and 3." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:129 -msgid "pkgutil-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:131 -msgid "" -"Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. " -"This can be used to declare namespace packages that need to be compatible " -"with both Python 2.3+ and Python 3. This is the recommended approach for the " -"highest level of compatibility." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:136 -msgid "" -"To create a pkgutil-style namespace package, you need to provide an :file:" -"`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:148 -#: ../source/guides/packaging-namespace-packages.rst:194 -msgid "" -"The :file:`__init__.py` file for the namespace package needs to contain " -"**only** the following:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:155 -#: ../source/guides/packaging-namespace-packages.rst:201 -msgid "" -"**Every** distribution that uses the namespace package must include an " -"identical :file:`__init__.py`. If any distribution does not, it will cause " -"the namespace logic to fail and the other sub-packages will not be " -"importable. Any additional code in :file:`__init__.py` will be inaccessible." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:160 -msgid "" -"A complete working example of two pkgutil-style namespace packages can be " -"found in the `pkgutil namespace example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:171 -msgid "pkg_resources-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:173 -msgid "" -"`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and " -"the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together " -"these can be used to declare namespace packages. While this approach is no " -"longer recommended, it is widely present in most existing namespace " -"packages. If you are creating a new distribution within an existing " -"namespace package that uses this method then it's recommended to continue " -"using this as the different methods are not cross-compatible and it's not " -"advisable to try to migrate an existing package." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:182 -msgid "" -"To create a pkg_resources-style namespace package, you need to provide an :" -"file:`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:206 -msgid "" -"Some older recommendations advise the following in the namespace package :" -"file:`__init__.py`:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:216 -msgid "" -"The idea behind this was that in the rare case that setuptools isn't " -"available packages would fall-back to the pkgutil-style packages. This isn't " -"advisable because pkgutil and pkg_resources-style namespace packages are not " -"cross-compatible. If the presence of setuptools is a concern then the " -"package should just explicitly depend on setuptools via ``install_requires``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:223 -msgid "" -"Finally, every distribution must provide the ``namespace_packages`` argument " -"to :func:`~setuptools.setup` in :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:237 -msgid "" -"A complete working example of two pkg_resources-style namespace packages can " -"be found in the `pkg_resources namespace example project`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 -msgid "" -"Publishing package distribution releases using GitHub Actions CI/CD workflows" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 -msgid "" -"`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an " -"event occurs on the GitHub platform. One popular choice is having a workflow " -"that's triggered by a ``push`` event. This guide shows you how to publish a " -"Python distribution whenever a tagged commit is pushed. It will use the " -"`pypa/gh-action-pypi-publish GitHub Action`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 -msgid "" -"This guide *assumes* that you already have a project that you know how to " -"build distributions for and *it lives on GitHub*." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 -msgid "Saving credentials on GitHub" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 -msgid "" -"In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, " -"meaning that we'll have two separate sets of credentials. And we'll need to " -"save them in the GitHub repository settings." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 -msgid "Let's begin! 🚀" -msgstr "Почнімо! 🚀" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 -msgid "" -"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " -"token`_. If you have the project on PyPI already, limit the token scope to " -"just that project. You can call it something like ``GitHub Actions CI/CD — " -"project-org/project-repo`` in order for it to be easily distinguishable in " -"the token list. **Don't close the page just yet — you won't see that token " -"again.**" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 -msgid "" -"In a separate browser tab or window, go to the ``Settings`` tab of your " -"target repository and then click on `Secrets`_ in the left sidebar." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 -msgid "" -"Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from " -"the first step." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 -msgid "" -"Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the " -"steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 -msgid "" -"If you don't have a TestPyPI account, you'll need to create it. It's not the " -"same as a regular PyPI account." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 -msgid "Creating a workflow definition" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 -msgid "" -"GitHub CI/CD workflows are declared in YAML files stored in the ``.github/" -"workflows/`` directory of your repository." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 -msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 -msgid "" -"Start it with a meaningful name and define the event that should make GitHub " -"run this workflow:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 -msgid "Defining a workflow job environment" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 -msgid "" -"Now, let's add initial setup for our job. It's a process that will execute " -"commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 -msgid "Checking out the project and building distributions" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 -msgid "Then, add the following under the ``build-n-publish`` section:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 -msgid "" -"This will download your repository into the CI runner and then install and " -"activate Python 3.7." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 -msgid "" -"And now we can build dists from source. In this example, we'll use ``build`` " -"package, assuming that your project has a ``pyproject.toml`` properly set up " -"(see :pep:`517`/:pep:`518`)." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 -msgid "" -"You can use any other method for building distributions as long as it " -"produces ready-to-upload artifacts saved into the ``dist/`` folder." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 -msgid "So add this to the steps list:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 -msgid "Publishing the distribution to PyPI and TestPyPI" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 -msgid "Finally, add the following steps at the end:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 -msgid "" -"These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the " -"first one uploads contents of the ``dist/`` folder into TestPyPI " -"unconditionally and the second does that to PyPI, but only if the current " -"commit is tagged." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 -msgid "That's all, folks!" -msgstr "Це все, панове!" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 -msgid "" -"Now, whenever you push a tagged commit to your Git repository remote on " -"GitHub, this workflow will publish it to PyPI. And it'll publish any push to " -"TestPyPI which is useful for providing test builds to your alpha users as " -"well as making sure that your release pipeline remains healthy!" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:5 -msgid "Single-sourcing the package version" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:8 -msgid "" -"There are many techniques to maintain a single source of truth for the " -"version number of your project:" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:11 -msgid "" -"Read the file in :file:`setup.py` and get the version. Example (from `pip " -"setup.py `_)::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:38 -msgid "" -"As of the release of setuptools 46.4.0, one can accomplish the same thing by " -"instead placing the following in the project's ``setup.cfg`` file (replacing " -"\"package\" with the import name of the package):" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:47 -msgid "" -"Earlier versions of setuptools implemented the ``attr:`` directive by " -"importing the module, but setuptools 46.4.0 added rudimentary AST analysis " -"so that ``attr:`` can function without having to import any of the package's " -"dependencies." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:52 -msgid "" -"Also, please be aware that declarative config indicators, including the " -"``attr:`` directive, are not supported in parameters to ``setup.py``." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:55 -msgid "" -"Use an external build tool that either manages updating both locations, or " -"offers an API that both locations can use." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:58 -msgid "" -"Few tools you could use, in no particular order, and not necessarily " -"complete: `bump2version `_, `changes " -"`_, `commitizen `_, `zest.releaser `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:65 -msgid "" -"Set the value to a ``__version__`` global variable in a dedicated module in " -"your project (e.g. :file:`version.py`), then have :file:`setup.py` read and " -"``exec`` the value into a variable." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:76 -msgid "" -"Example using this technique: `warehouse `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:78 -msgid "" -"Place the value in a simple ``VERSION`` text file and have both :file:`setup." -"py` and the project code read it." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:86 -msgid "" -"An advantage with this technique is that it's not specific to Python. Any " -"tool can read the version." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:91 -msgid "" -"With this approach you must make sure that the ``VERSION`` file is included " -"in all your source and binary distributions (e.g. add ``include VERSION`` to " -"your :file:`MANIFEST.in`)." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:95 -msgid "" -"Set the value in :file:`setup.py`, and have the project code use the " -"``importlib.metadata`` API to fetch the value at runtime. (``importlib." -"metadata`` was introduced in Python 3.8 and is available to older versions " -"as the ``importlib-metadata`` project.) An installed project's version can " -"be fetched with the API as follows::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:110 -msgid "" -"Be aware that the ``importlib.metadata`` API only knows about what's in the " -"installation metadata, which is not necessarily the code that's currently " -"imported." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:114 -msgid "" -"If a project uses this method to fetch its version at runtime, then its " -"``install_requires`` value needs to be edited to install ``importlib-" -"metadata`` on pre-3.8 versions of Python like so::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:128 -msgid "" -"An older (and less efficient) alternative to ``importlib.metadata`` is the " -"``pkg_resources`` API provided by ``setuptools``::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:134 -msgid "" -"If a project uses ``pkg_resources`` to fetch its own version at runtime, " -"then ``setuptools`` must be added to the project's ``install_requires`` list." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:138 -msgid "" -"Example using this technique: `setuptools `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:141 -msgid "" -"Set the value to ``__version__`` in ``sample/__init__.py`` and import " -"``sample`` in :file:`setup.py`." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:155 -msgid "" -"Although this technique is common, beware that it will fail if ``sample/" -"__init__.py`` imports packages from ``install_requires`` dependencies, which " -"will very likely not be installed yet when :file:`setup.py` is run." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:161 -msgid "" -"Keep the version number in the tags of a version control system (Git, " -"Mercurial, etc) instead of in the code, and automatically extract it from " -"there using `setuptools_scm `_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:5 -msgid "Supporting multiple Python versions" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:37 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:43 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:49 -msgid "Automated testing and continuous integration" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:51 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:56 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:60 -msgid "" -"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:" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:66 -msgid "" -"`Travis CI `_ provides both a Linux and a macOS " -"environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit " -"while the macOS is 10.9.2 at the time of writing." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:69 -msgid "" -"`Appveyor `_ provides a Windows environment " -"(Windows Server 2012)." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:80 -msgid "" -"Both `Travis CI`_ 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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:85 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:89 -msgid "Tools for single-source Python packages" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:91 -msgid "" -"`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_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:100 -msgid "" -"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" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:107 -msgid "a Python 2 (by syntax) module in a Python 3 project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:108 -msgid "a Python 3 (by syntax) module in a *Python 2* project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:110 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:117 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:124 -msgid "What's in which Python?" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:126 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:3 -msgid "Supporting Windows using Appveyor" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:6 -msgid "2015-12-03" -msgstr "03.12.2015" - -#: ../source/guides/supporting-windows-using-appveyor.rst:8 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:20 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:24 -msgid "" -"The Appveyor service is a continuous integration service, much like the " -"better-known `Travis`_ service that is commonly used for testing by projects " -"hosted on `Github`_. However, unlike Travis, the build workers on Appveyor " -"are Windows hosts and have the necessary compilers installed to build Python " -"extensions." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:30 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:38 -msgid "Setting up" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:40 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:45 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:49 -msgid "" -"Once you have set up your Appveyor account and added your project, Appveyor " -"will automatically build your project each time a commit occurs. This " -"behaviour will be familiar to users of Travis." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:54 -msgid "Adding Appveyor support to your project" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:56 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:61 -msgid "" -"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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:69 -msgid "appveyor.yml" -msgstr "appveyor.yml" - -#: ../source/guides/supporting-windows-using-appveyor.rst:75 -msgid "" -"This file can be downloaded from `here `__." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:77 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:80 -msgid "" -"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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:88 -msgid "" -"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``)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:94 -msgid "" -"The ``build`` section simply switches off builds - there is no build step " -"needed for Python, unlike languages like ``C#``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:97 -msgid "" -"The main sections that will need to be tailored to your project are " -"``test_script`` and ``after_test``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:100 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:109 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:114 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:119 -msgid "Support script" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:121 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:126 -msgid "" -"`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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:133 -msgid "" -"You can simply download the batch file and include it in your project " -"unchanged." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:137 -msgid "Access to the built wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:139 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:147 -msgid "Additional notes" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:150 -msgid "Testing with tox" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:152 -msgid "" -"Many projects use the `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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:156 -msgid "" -"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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:160 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:165 -msgid "" -"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" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:170 -msgid "``DISTUTILS_USE_SDK``" -msgstr "``DISTUTILS_USE_SDK``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:171 -msgid "``MSSdk``" -msgstr "``MSSdk``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:172 -msgid "``INCLUDE``" -msgstr "``INCLUDE``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:173 -msgid "``LIB``" -msgstr "``LIB``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:175 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:181 -msgid "" -"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 Travis or 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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:188 -msgid "" -"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``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:192 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:197 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:203 -msgid "Automatically uploading wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:205 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:210 -msgid "" -"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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:216 -msgid "External dependencies" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:218 -msgid "" -"The supplied scripts will successfully build any distribution that does not " -"rely on 3rd party external libraries for the build." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:221 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:230 -msgid "Support scripts" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:232 -msgid "For reference, the SDK setup support script is listed here:" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:234 -msgid "``appveyor-sample/build.cmd``" -msgstr "``appveyor-sample/build.cmd``" - -#: ../source/guides/tool-recommendations.rst:5 -msgid "Tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:7 -msgid "" -"If you're familiar with Python packaging and installation, and just want to " -"know what tools are currently recommended, then here it is." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:12 -msgid "Application dependency management" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:14 -msgid "" -"Use :ref:`pipenv` to manage library dependencies when developing Python " -"applications. See :doc:`../tutorials/managing-dependencies` for more details " -"on using ``pipenv``." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:18 -msgid "When ``pipenv`` does not meet your use case, consider other tools like:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:20 -msgid ":ref:`pip`" -msgstr ":ref:`pip`" - -#: ../source/guides/tool-recommendations.rst:22 -msgid "`pip-tools `_" -msgstr "`pip-tools `_" - -#: ../source/guides/tool-recommendations.rst:24 -msgid "`Poetry `_" -msgstr "`Poetry `_" - -#: ../source/guides/tool-recommendations.rst:27 -msgid "Installation tool recommendations" -msgstr "Поради щодо засобу встановлення" - -#: ../source/guides/tool-recommendations.rst:29 -msgid "" -"Use :ref:`pip` to install Python :term:`packages ` " -"from :term:`PyPI `. [1]_ [2]_ Depending on how :" -"ref:`pip` is installed, you may need to also install :ref:`wheel` to get the " -"benefit of wheel caching. [3]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:34 -msgid "" -"Use :ref:`virtualenv`, or `venv`_ to isolate application specific " -"dependencies from a shared Python installation. [4]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:37 -msgid "" -"If you're looking for management of fully integrated cross-platform software " -"stacks, consider:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:40 -msgid ":ref:`buildout`: primarily focused on the web development community" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:42 -msgid "" -":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the " -"scientific community." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:47 -msgid "Packaging tool recommendations" -msgstr "Поради щодо засобу пакування" - -#: ../source/guides/tool-recommendations.rst:49 -msgid "" -"Use :ref:`setuptools` to define projects and create :term:`Source " -"Distributions `. [5]_ [6]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:52 -msgid "" -"Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:" -"`wheel project ` to create :term:`wheels `. This is " -"especially beneficial, if your project contains binary extensions." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:56 -msgid "" -"Use `twine `_ for uploading distributions " -"to :term:`PyPI `." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:61 -msgid "Publishing platform migration" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:63 -msgid "" -"The original Python Package Index implementation (previously hosted at `pypi." -"python.org `_) has been phased out in favour of an " -"updated implementation hosted at `pypi.org `_." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:67 -msgid "" -"See :ref:`Migrating to PyPI.org` for more information on the status of the " -"migration, and what settings to change in your clients." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:72 -msgid "" -"There are some cases where you might choose to use ``easy_install`` (from :" -"ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` " -"(which pip doesn't support). For a detailed breakdown, see :ref:`pip vs " -"easy_install`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:77 -msgid "" -"The acceptance of :pep:`453` means that :ref:`pip` will be available by " -"default in most installations of Python 3.4 or later. See the :pep:" -"`rationale section <453#rationale>` from :pep:`453` as for why pip was " -"chosen." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:82 -msgid "" -"`get-pip.py `_ and :ref:" -"`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv " -"` do not currently. Also, the common \"python-pip\" package that's " -"found in various linux distros, does not depend on \"python-wheel\" " -"currently." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:88 -msgid "" -"Beginning with Python 3.4, ``venv`` will create virtualenv environments with " -"``pip`` installed, thereby making it an equal alternative to :ref:" -"`virtualenv`. However, using :ref:`virtualenv` will still be recommended for " -"users that need cross-version consistency." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:93 -msgid "" -"Although you can use pure ``distutils`` for many projects, it does not " -"support defining dependencies on other projects and is missing several " -"convenience utilities for automatically populating distribution metadata " -"correctly that are provided by ``setuptools``. Being outside the standard " -"library, ``setuptools`` also offers a more consistent feature set across " -"different versions of Python, and (unlike ``distutils``), recent versions of " -"``setuptools`` support all of the modern metadata fields described in :ref:" -"`core-metadata`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:102 -msgid "" -"Even for projects that do choose to use ``distutils``, when :ref:`pip` " -"installs such projects directly from source (rather than installing from a " -"prebuilt :term:`wheel ` file), it will actually build your project " -"using :ref:`setuptools` instead." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:107 -msgid "" -"`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` " -"in June 2013, thereby making setuptools the default choice for packaging." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:5 -msgid "Including files in source distributions with ``MANIFEST.in``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:7 -msgid "" -"When building a :term:`source distribution ` for your package, by default only a minimal set of files are " -"included. You may find yourself wanting to include extra files in the " -"source distribution, such as an authors/contributors file, a :file:`docs/` " -"directory, or a directory of data files used for testing purposes. There " -"may even be extra files that you *need* to include; for example, if your :" -"file:`setup.py` computes your project's ``long_description`` by reading from " -"both a README and a changelog file, you'll need to include both those files " -"in the sdist so that people that build or install from the sdist get the " -"correct results." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:17 -msgid "" -"Adding & removing files to & from the source distribution is done by writing " -"a :file:`MANIFEST.in` file at the project root." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:22 -msgid "How files are included in an sdist" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:24 -msgid "The following files are included in a source distribution by default:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:26 -msgid "" -"all Python source files implied by the ``py_modules`` and ``packages`` " -"``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:28 -msgid "" -"all C source files mentioned in the ``ext_modules`` or ``libraries`` " -"``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:30 -msgid "scripts specified by the ``scripts`` ``setup()`` argument" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:31 -msgid "" -"all files specified by the ``package_data`` and ``data_files`` ``setup()`` " -"arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:33 -msgid "" -"the file specified by the ``license_file`` option in :file:`setup.cfg` " -"(setuptools 40.8.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:35 -msgid "" -"all files specified by the ``license_files`` option in :file:`setup.cfg` " -"(setuptools 42.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:37 -msgid "all files matching the pattern :file:`test/test*.py`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:38 -msgid ":file:`setup.py` (or whatever you called your setup script)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:39 -msgid ":file:`setup.cfg`" -msgstr ":file:`setup.cfg`" - -#: ../source/guides/using-manifest-in.rst:40 -msgid ":file:`README`" -msgstr ":file:`README`" - -#: ../source/guides/using-manifest-in.rst:41 -msgid ":file:`README.txt`" -msgstr ":file:`README.txt`" - -#: ../source/guides/using-manifest-in.rst:42 -msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" -msgstr ":file:`README.rst` (Python 3.7+ або setuptools 0.6.27+)" - -#: ../source/guides/using-manifest-in.rst:43 -msgid ":file:`README.md` (setuptools 36.4.0+)" -msgstr ":file:`README.md` (setuptools 36.4.0+)" - -#: ../source/guides/using-manifest-in.rst:44 -msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" -msgstr ":file:`pyproject.toml` (setuptools 43.0.0+)" - -#: ../source/guides/using-manifest-in.rst:45 -msgid ":file:`MANIFEST.in`" -msgstr ":file:`MANIFEST.in`" - -#: ../source/guides/using-manifest-in.rst:47 -msgid "" -"After adding the above files to the sdist, the commands in :file:`MANIFEST." -"in` (if such a file exists) are executed in order to add and remove further " -"files to & from the sdist. Default files can even be removed from the sdist " -"with the appropriate :file:`MANIFEST.in` command." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:52 -msgid "" -"After processing the :file:`MANIFEST.in` file, setuptools removes the :file:" -"`build/` directory as well as any directories named :file:`RCS`, :file:" -"`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file " -"and an :file:`*.egg-info` directory. This behavior cannot be changed with :" -"file:`MANIFEST.in`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:60 -msgid ":file:`MANIFEST.in` commands" -msgstr "Команди в :file:`MANIFEST.in`" - -#: ../source/guides/using-manifest-in.rst:62 -msgid "" -"A :file:`MANIFEST.in` file consists of commands, one per line, instructing " -"setuptools to add or remove some set of files from the sdist. The commands " -"are:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:67 -msgid "Command" -msgstr "Команда" - -#: ../source/guides/using-manifest-in.rst:69 -msgid ":samp:`include {pat1} {pat2} ...`" -msgstr ":samp:`include {pat1} {pat2} ...`" - -#: ../source/guides/using-manifest-in.rst:69 -msgid "Add all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid ":samp:`exclude {pat1} {pat2} ...`" -msgstr ":samp:`exclude {pat1} {pat2} ...`" - -#: ../source/guides/using-manifest-in.rst:70 -msgid "Remove all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" -msgstr ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" - -#: ../source/guides/using-manifest-in.rst:71 -msgid "" -"Add all files under directories matching ``dir-pattern`` that match any of " -"the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" -msgstr ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" - -#: ../source/guides/using-manifest-in.rst:72 -msgid "" -"Remove all files under directories matching ``dir-pattern`` that match any " -"of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid ":samp:`global-include {pat1} {pat2} ...`" -msgstr ":samp:`global-include {pat1} {pat2} ...`" - -#: ../source/guides/using-manifest-in.rst:73 -msgid "" -"Add all files anywhere in the source tree matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid ":samp:`global-exclude {pat1} {pat2} ...`" -msgstr ":samp:`global-exclude {pat1} {pat2} ...`" - -#: ../source/guides/using-manifest-in.rst:74 -msgid "" -"Remove all files anywhere in the source tree matching any of the listed " -"patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid ":samp:`graft {dir-pattern}`" -msgstr ":samp:`graft {dir-pattern}`" - -#: ../source/guides/using-manifest-in.rst:75 -msgid "Add all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid ":samp:`prune {dir-pattern}`" -msgstr ":samp:`prune {dir-pattern}`" - -#: ../source/guides/using-manifest-in.rst:76 -msgid "Remove all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:79 -msgid "" -"The patterns here are glob-style patterns: ``*`` matches zero or more " -"regular filename characters (on Unix, everything except forward slash; on " -"Windows, everything except backslash and colon); ``?`` matches a single " -"regular filename character, and ``[chars]`` matches any one of the " -"characters between the square brackets (which may contain character ranges, " -"e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented " -"support for ``**`` matching zero or more characters including forward slash, " -"backslash, and colon." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:87 -msgid "" -"Directory patterns are relative to the root of the project directory; e.g., " -"``graft example*`` will include a directory named :file:`examples` in the " -"project root but will not include :file:`docs/examples/`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:91 -msgid "" -"File & directory names in :file:`MANIFEST.in` should be ``/``-separated; " -"setuptools will automatically convert the slashes to the local platform's " -"appropriate directory separator." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:95 -msgid "" -"Commands are processed in the order they appear in the :file:`MANIFEST.in` " -"file. For example, given the commands::" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:101 -msgid "" -"the contents of the directory tree :file:`tests` will first be added to the " -"sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, " -"or ``.pyd`` extension will be removed from the sdist. If the commands were " -"in the opposite order, then ``*.pyc`` files etc. would be only be removed " -"from what was already in the sdist before adding :file:`tests`, and if :file:" -"`tests` happened to contain any ``*.pyc`` files, they would end up included " -"in the sdist because the exclusion happened before they were included." -msgstr "" - -#: ../source/guides/using-testpypi.rst:7 -msgid "" -"``TestPyPI`` is a separate instance of the :term:`Python Package Index " -"(PyPI)` that allows you to try out the distribution tools and process " -"without worrying about affecting the real index. TestPyPI is hosted at `test." -"pypi.org `_" -msgstr "" - -#: ../source/guides/using-testpypi.rst:13 -msgid "Registering your account" -msgstr "" - -#: ../source/guides/using-testpypi.rst:15 -msgid "" -"Because TestPyPI has a separate database from the live PyPI, you'll need a " -"separate user account for specifically for TestPyPI. Go to https://test.pypi." -"org/account/register/ to register your account." -msgstr "" - -#: ../source/guides/using-testpypi.rst:19 -msgid "" -"The database for TestPyPI may be periodically pruned, so it is not unusual " -"for user accounts to be deleted." -msgstr "" - -#: ../source/guides/using-testpypi.rst:24 -msgid "Using TestPyPI with Twine" -msgstr "" - -#: ../source/guides/using-testpypi.rst:26 -msgid "" -"You can upload your distributions to TestPyPI using :ref:`twine` by " -"specifying the ``--repository`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:33 -msgid "" -"You can see if your package has successfully uploaded by navigating to the " -"URL ``https://test.pypi.org/project/`` where " -"``sampleproject`` is the name of your project that you uploaded. It may take " -"a minute or two for your project to appear on the site." -msgstr "" - -#: ../source/guides/using-testpypi.rst:39 -msgid "Using TestPyPI with pip" -msgstr "" - -#: ../source/guides/using-testpypi.rst:41 -msgid "" -"You can tell pip to download packages from TestPyPI instead of PyPI by " -"specifying the ``--index-url`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:56 -msgid "" -"If you want to allow pip to also pull other packages from PyPI you can " -"specify ``--extra-index-url`` to point to PyPI. This is useful when the " -"package you're testing has dependencies:" -msgstr "" - -#: ../source/guides/using-testpypi.rst:73 -msgid "Setting up TestPyPI in :file:`.pypirc`" -msgstr "" - -#: ../source/guides/using-testpypi.rst:75 -msgid "" -"If you want to avoid entering your username, you can configure TestPyPI in " -"your :file:`$HOME/.pypirc`:" -msgstr "" - -#: ../source/index.rst:3 ../source/key_projects.rst:181 -msgid "Python Packaging User Guide" -msgstr "Користувацьке керівництво з пакування Python" - -#: ../source/index.rst:5 -msgid "" -"The Python Packaging User Guide (PyPUG) is a collection of tutorials and " -"guides for packaging Python software." -msgstr "" - -#: ../source/index.rst:5 -msgid "python, packaging, guide, tutorial" -msgstr "" - -#: ../source/index.rst:24 -msgid "" -"Welcome to the *Python Packaging User Guide*, a collection of tutorials and " -"references to help you distribute and install Python packages with modern " -"tools." -msgstr "" - -#: ../source/index.rst:28 -msgid "" -"This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. " -"We happily accept any :doc:`contributions and feedback `. 😊" -msgstr "" - -#: ../source/index.rst:36 -msgid "Get started" -msgstr "" - -#: ../source/index.rst:38 -msgid "" -"Essential tools and concepts for working within the Python development " -"ecosystem are covered in our :doc:`tutorials/index` section:" -msgstr "" - -#: ../source/index.rst:41 -msgid "" -"To learn how to install packages, see the :doc:`tutorial on installing " -"packages `" -msgstr "" - -#: ../source/index.rst:43 -msgid "" -"To learn how to manage dependencies in a version controlled project, see " -"the :doc:`tutorial on managing application dependencies `" -msgstr "" - -#: ../source/index.rst:45 -msgid "" -"To learn how to package and distribute your projects, see the :doc:`tutorial " -"on packaging and distributing `" -msgstr "" - -#: ../source/index.rst:47 -msgid "" -"To get an overview of packaging options for Python libraries and " -"applications, see the :doc:`Overview of Python Packaging `" -msgstr "" - -#: ../source/index.rst:52 -msgid "Learn more" -msgstr "Дізнатися більше" - -#: ../source/index.rst:54 -msgid "" -"Beyond our :doc:`tutorials/index`, this guide has several other resources:" -msgstr "" - -#: ../source/index.rst:56 -msgid "" -"The :doc:`guides/index` section for walk throughs, such as :doc:`guides/" -"installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." -msgstr "" - -#: ../source/index.rst:58 -msgid "" -"The :doc:`discussions/index` section for in-depth references on topics such " -"as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-" -"vs-easy-install`." -msgstr "" - -#: ../source/index.rst:60 -msgid "" -"The :doc:`specifications/index` section for packaging interoperability " -"specifications." -msgstr "" - -#: ../source/index.rst:62 -msgid "" -"Additionally, there is a list of :doc:`other projects ` " -"maintained by members of the Python Packaging Authority." -msgstr "" - -#: ../source/key_projects.rst:6 -msgid "Project Summaries" -msgstr "" - -#: ../source/key_projects.rst:8 -msgid "" -"Summaries and links for the most relevant projects in the space of Python " -"installation and packaging." -msgstr "" - -#: ../source/key_projects.rst:14 -msgid "PyPA Projects" -msgstr "Проєкти PyPA" - -#: ../source/key_projects.rst:19 -msgid "bandersnatch" -msgstr "bandersnatch" - -#: ../source/key_projects.rst:21 -msgid "" -"`Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:25 -msgid "" -"``bandersnatch`` is a PyPI mirroring client designed to efficiently create a " -"complete mirror of the contents of PyPI. Organizations thus save bandwidth " -"and latency on package downloads (especially in the context of automated " -"tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." -msgstr "" - -#: ../source/key_projects.rst:35 -msgid "build" -msgstr "build" - -#: ../source/key_projects.rst:37 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI " -"`__" -msgstr "" - -#: ../source/key_projects.rst:42 -msgid "" -"``build`` is a :pep:`517` compatible Python package builder. It provides a " -"CLI to build packages, as well as a Python API." -msgstr "" - -#: ../source/key_projects.rst:49 -msgid "cibuildwheel" -msgstr "cibuildwheel" - -#: ../source/key_projects.rst:51 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | " -"`Discussions `__ | " -"`Discord #cibuildwheel `__" -msgstr "" - -#: ../source/key_projects.rst:58 -msgid "" -"``cibuildwheel`` is a Python package that builds :term:`wheels ` for " -"all common platforms and Python versions on most CI systems. Also see :ref:" -"`multibuild`." -msgstr "" - -#: ../source/key_projects.rst:64 -msgid "distlib" -msgstr "distlib" - -#: ../source/key_projects.rst:66 -msgid "" -"`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:71 -msgid "" -"``distlib`` is a library which implements low-level functions that relate to " -"packaging and distribution of Python software. ``distlib`` implements " -"several relevant PEPs (Python Enhancement Proposal standards) and is useful " -"for developers of third-party packaging tools to make and upload binary and " -"source :term:`distributions `, achieve " -"interoperability, resolve dependencies, manage package resources, and do " -"other similar functions." -msgstr "" - -#: ../source/key_projects.rst:80 -msgid "" -"Unlike the stricter :ref:`packaging` project (below), which specifically " -"implements modern Python packaging interoperability standards, ``distlib`` " -"also attempts to provide reasonable fallback behaviours when asked to handle " -"legacy packages and metadata that predate the modern interoperability " -"standards and fall into the subset of packages that are incompatible with " -"those standards." -msgstr "" - -#: ../source/key_projects.rst:90 -msgid "packaging" -msgstr "пакування" - -#: ../source/key_projects.rst:92 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:97 -msgid "" -"Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." -msgstr "" - -#: ../source/key_projects.rst:99 -msgid "" -"The core utilities in the packaging library handle version handling, " -"specifiers, markers, requirements, tags, and similar attributes and tasks " -"for Python packages. Most Python users rely on this library without needing " -"to explicitly call it; developers of the other Python packaging, " -"distribution, and installation tools listed here often use its functionality " -"to parse, discover, and otherwise handle dependency attributes." -msgstr "" - -#: ../source/key_projects.rst:107 -msgid "" -"This project specifically focuses on implementing the modern Python " -"packaging interoperability standards defined at :ref:`packaging-" -"specifications`, and will report errors for sufficiently old legacy packages " -"that are incompatible with those standards. In contrast, the :ref:`distlib` " -"project is a more permissive library that attempts to provide a plausible " -"reading of ambiguous metadata in cases where :ref:`packaging` will instead " -"report on error." -msgstr "" - -#: ../source/key_projects.rst:119 -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "pip" -msgstr "pip" - -#: ../source/key_projects.rst:121 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:126 -msgid "" -"The most popular tool for installing Python packages, and the one included " -"with modern versions of Python." -msgstr "" - -#: ../source/key_projects.rst:129 -msgid "" -"It provides the essential core features for finding, downloading, and " -"installing packages from PyPI and other Python package indexes, and can be " -"incorporated into a wide range of development workflows via its command-line " -"interface (CLI)." -msgstr "" - -#: ../source/key_projects.rst:137 -msgid "Pipenv" -msgstr "Pipenv" - -#: ../source/key_projects.rst:139 -msgid "" -"`Docs `__ | `Source `__ | `Issues `__ | `PyPI " -"`__" -msgstr "" - -#: ../source/key_projects.rst:144 -msgid "" -"Pipenv is a project that aims to bring the best of all packaging worlds to " -"the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:" -"`virtualenv` into one single toolchain. It features very pretty terminal " -"colors." -msgstr "" - -#: ../source/key_projects.rst:148 -msgid "" -"Pipenv aims to help users manage environments, dependencies, and imported " -"packages on the command line. It also works well on Windows (which other " -"tools often underserve), makes and checkes file hashes, to ensure compliance " -"with hash-locked dependency specifiers, and eases uninstallation of packages " -"and dependencies. It is used by Python users and system administrators, but " -"has been less maintained since late 2018." -msgstr "" - -#: ../source/key_projects.rst:159 -msgid "Pipfile" -msgstr "Pipfile" - -#: ../source/key_projects.rst:161 -msgid "`Source `__" -msgstr "" - -#: ../source/key_projects.rst:163 -msgid "" -":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level " -"application-centric alternative to :ref:`pip`'s lower-level :file:" -"`requirements.txt` file." -msgstr "" - -#: ../source/key_projects.rst:170 -msgid "pipx" -msgstr "pipx" - -#: ../source/key_projects.rst:172 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:176 -msgid "" -"pipx is a tool to install and run Python command-line applications without " -"causing dependency conflicts with other packages installed on the system." -msgstr "" - -#: ../source/key_projects.rst:183 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:187 -msgid "This guide!" -msgstr "Це керівництво!" - -#: ../source/key_projects.rst:192 -msgid "readme_renderer" -msgstr "readme_renderer" - -#: ../source/key_projects.rst:194 -msgid "" -"`GitHub and docs `__ | `PyPI " -"`__" -msgstr "" - -#: ../source/key_projects.rst:197 -msgid "" -"``readme_renderer`` is a library that package developers use to render their " -"user documentation (README) files into HTML from markup languages such as " -"Markdown or reStructuredText. Developers call it on its own or via :ref:" -"`twine`, as part of their release management process, to check that their " -"package descriptions will properly display on PyPI." -msgstr "" - -#: ../source/key_projects.rst:208 -msgid "setuptools" -msgstr "setuptools" - -#: ../source/key_projects.rst:210 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:215 -msgid "" -"setuptools (which includes ``easy_install``) is a collection of enhancements " -"to the Python distutils that allow you to more easily build and distribute " -"Python :term:`distributions `, especially ones that " -"have dependencies on other packages." -msgstr "" - -#: ../source/key_projects.rst:220 -msgid "" -"`distribute`_ was a fork of setuptools that was merged back into setuptools " -"(in v0.7), thereby making setuptools the primary choice for Python packaging." -msgstr "" - -#: ../source/key_projects.rst:227 -msgid "trove-classifiers" -msgstr "trove-classifiers" - -#: ../source/key_projects.rst:229 -msgid "" -"`Issues `__ | `GitHub " -"`__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:233 -msgid "" -"trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically " -"describe their projects `_ so that users can better find projects " -"that match their needs on the PyPI." -msgstr "" - -#: ../source/key_projects.rst:239 -msgid "" -"The trove-classifiers package contains a list of valid classifiers and " -"deprecated classifiers (which are paired with the classifiers that replace " -"them). Use this package to validate classifiers used in packages intended " -"for uploading to PyPI. As this list of classifiers is published as code, you " -"can install and import it, giving you a more convenient workflow compared to " -"referring to the `list published on PyPI `_. " -"The `issue tracker `_ for " -"the project hosts discussions on proposed classifiers and requests for new " -"classifiers." -msgstr "" - -#: ../source/key_projects.rst:253 -msgid "twine" -msgstr "twine" - -#: ../source/key_projects.rst:255 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:260 -msgid "" -"Twine is the primary tool developers use to upload packages to the Python " -"Package Index or other Python package indexes. It is a command-line program " -"that passes program files and metadata to a web API. Developers use it " -"because it's the official PyPI upload tool, it's fast and secure, it's " -"maintained, and it reliably works." -msgstr "" - -#: ../source/key_projects.rst:270 ../source/overview.rst:415 -msgid "virtualenv" -msgstr "virtualenv" - -#: ../source/key_projects.rst:272 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:277 -msgid "" -"virtualenv is a tool which uses the command-line path environment variable " -"to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional " -"functionality, compared to :ref:`venv`, by supporting Python 2.7 and by " -"providing convenient features for configuring, maintaining, duplicating, and " -"troubleshooting the virtual environments. For more information, see the " -"section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/key_projects.rst:290 -msgid "Warehouse" -msgstr "Warehouse" - -#: ../source/key_projects.rst:292 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:296 -msgid "" -"The current codebase powering the :term:`Python Package Index (PyPI)`. It is " -"hosted at `pypi.org `_. The default source for :ref:`pip` " -"downloads." -msgstr "" - -#: ../source/key_projects.rst:304 -msgid "wheel" -msgstr "wheel" - -#: ../source/key_projects.rst:306 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:311 -msgid "" -"Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` " -"extension for creating :term:`wheel distributions `. Additionally, " -"it offers its own command line utility for creating and installing wheels." -msgstr "" - -#: ../source/key_projects.rst:315 -msgid "" -"See also `auditwheel `__, a tool that " -"package developers use to check and fix Python packages they are making in " -"the binary wheel format. It provides functionality to discover dependencies, " -"check metadata for compliance, and repair the wheel and metadata to properly " -"link and include external shared libraries in a package." -msgstr "" - -#: ../source/key_projects.rst:324 -msgid "Non-PyPA Projects" -msgstr "" - -#: ../source/key_projects.rst:329 -msgid "bento" -msgstr "bento" - -#: ../source/key_projects.rst:331 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:336 -msgid "" -"Bento is a packaging tool solution for Python software, targeted as an " -"alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's " -"philosophy is reproducibility, extensibility and simplicity (in that order)." -msgstr "" - -#: ../source/key_projects.rst:344 -msgid "buildout" -msgstr "buildout" - -#: ../source/key_projects.rst:346 -msgid "" -"`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:351 -msgid "" -"Buildout is a Python-based build system for creating, assembling and " -"deploying applications from multiple parts, some of which may be non-Python-" -"based. It lets you create a buildout configuration and reproduce the same " -"software later." -msgstr "" - -#: ../source/key_projects.rst:358 -msgid "conda" -msgstr "conda" - -#: ../source/key_projects.rst:360 -msgid "`Docs `__" -msgstr "" - -#: ../source/key_projects.rst:362 -msgid "" -"conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution " -"from `Anaconda, Inc `__ specifically " -"aimed at the scientific community, and in particular on Windows where the " -"installation of binary extensions is often difficult." -msgstr "" - -#: ../source/key_projects.rst:369 -msgid "" -"Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, " -"but provides many of their combined features in terms of package management, " -"virtual environment management and deployment of binary extensions." -msgstr "" - -#: ../source/key_projects.rst:373 -msgid "" -"Conda does not install packages from PyPI and can install only from the " -"official Anaconda repositories, or anaconda.org (a place for user-" -"contributed *conda* packages), or a local (e.g. intranet) package server. " -"However, note that :ref:`pip` can be installed into, and work side-by-side " -"with conda for managing :term:`distributions ` from " -"PyPI. Also, `conda skeleton `__ is a tool to make " -"Python packages installable by conda by first fetching them from PyPI and " -"modifying their metadata." -msgstr "" - -#: ../source/key_projects.rst:386 -msgid "devpi" -msgstr "devpi" - -#: ../source/key_projects.rst:388 -msgid "" -"`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:392 -msgid "" -"devpi features a powerful PyPI-compatible server and PyPI proxy cache with a " -"complementary command line tool to drive packaging, testing and release " -"activities with Python. devpi also provides a browsable and searchable web " -"interface." -msgstr "" - -#: ../source/key_projects.rst:401 -msgid "flit" -msgstr "flit" - -#: ../source/key_projects.rst:403 -msgid "" -"`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:407 -msgid "" -"Flit provides a simple way to upload pure Python packages and modules to " -"PyPI. It focuses on `making the easy things easy `_ for " -"packaging. Flit can generate a configuration file to quickly set up a simple " -"project, build source distributions and wheels, and upload them to PyPI." -msgstr "" - -#: ../source/key_projects.rst:412 -msgid "" -"Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on " -"tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to " -"upload them to PyPI. Flit requires Python 3, but you can use it to " -"distribute modules for Python 2, so long as they can be imported on Python 3." -msgstr "" - -#: ../source/key_projects.rst:422 -msgid "enscons" -msgstr "enscons" - -#: ../source/key_projects.rst:424 -msgid "" -"`Source `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:428 -msgid "" -"Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-" -"compatible source distributions and wheels without using distutils or " -"setuptools, including distributions with C extensions. Enscons has a " -"different architecture and philosophy than :ref:`distutils`. Rather than " -"adding build features to a Python packaging system, enscons adds Python " -"packaging to a general purpose build system. Enscons helps you to build " -"sdists that can be automatically built by :ref:`pip`, and wheels that are " -"independent of enscons." -msgstr "" - -#: ../source/key_projects.rst:443 -msgid "Hashdist" -msgstr "Hashdist" - -#: ../source/key_projects.rst:445 -msgid "" -"`Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:448 -msgid "" -"Hashdist is a library for building non-root software distributions. Hashdist " -"is trying to be “the Debian of choice for cases where Debian technology " -"doesn’t work”. The best way for Pythonistas to think about Hashdist may be a " -"more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed " -"at solving the problem of installing scientific software, and making package " -"distribution stateless, cached, and branchable. It is used by some " -"researchers but has been lacking in maintenance since 2016." -msgstr "" - -#: ../source/key_projects.rst:460 -msgid "hatch" -msgstr "hatch" - -#: ../source/key_projects.rst:462 -msgid "" -"`GitHub and Docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:465 -msgid "" -"Hatch is a unified command-line tool meant to conveniently manage " -"dependencies and environment isolation for Python developers. Python package " -"developers use Hatch to configure, version, specify dependencies for, and " -"publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload " -"packages to PyPI, and :ref:`pip` to download and install packages." -msgstr "" - -#: ../source/key_projects.rst:475 -msgid "multibuild" -msgstr "multibuild" - -#: ../source/key_projects.rst:477 -msgid "`GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:479 -msgid "" -"Multibuild is a set of CI scripts for building and testing Python :term:" -"`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :" -"ref:`cibuildwheel`." -msgstr "" - -#: ../source/key_projects.rst:485 -msgid "pex" -msgstr "pex" - -#: ../source/key_projects.rst:487 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:491 -msgid "" -"pex is both a library and tool for generating :file:`.pex` (Python " -"EXecutable) files, standalone Python environments in the spirit of :ref:" -"`virtualenv`. :file:`.pex` files are just carefully constructed zip files " -"with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are " -"designed to make deployment of Python applications as simple as ``cp``." -msgstr "" - -#: ../source/key_projects.rst:500 -msgid "pip-tools" -msgstr "pip-tools" - -#: ../source/key_projects.rst:502 -msgid "" -"`GitHub and Docs `__ | `PyPI " -"`__" -msgstr "" - -#: ../source/key_projects.rst:505 -msgid "" -"pip-tools is a suite of tools meant for Python system administrators and " -"release managers who particularly want to keep their builds deterministic " -"yet stay up to date with new versions of their dependencies. Users can " -"specify particular release of their dependencies via hash, conveniently make " -"a properly formatted list of requirements from information in other parts of " -"their program, update all dependencies (a feature :ref:`pip` currently does " -"not provide), and create layers of constraints for the program to obey." -msgstr "" - -#: ../source/key_projects.rst:517 -msgid "piwheels" -msgstr "piwheels" - -#: ../source/key_projects.rst:519 -msgid "" -"`Website `__ | `Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:523 -msgid "" -"piwheels is a website, and software underpinning it, that fetches source " -"code distribution packages from PyPI and compiles them into binary wheels " -"that are optimized for installation onto Raspberry Pi computers. Raspberry " -"Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." -msgstr "" - -#: ../source/key_projects.rst:532 -msgid "poetry" -msgstr "poetry" - -#: ../source/key_projects.rst:534 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:538 -msgid "" -"poetry is a command-line tool to handle dependency installation and " -"isolation as well as building and packaging of Python packages. It uses " -"``pyproject.toml`` and, instead of depending on the resolver functionality " -"within :ref:`pip`, provides its own dependency resolver. It attempts to " -"speed users' experience of installation and dependency resolution by locally " -"caching metadata about dependencies." -msgstr "" - -#: ../source/key_projects.rst:548 -msgid "pypiserver" -msgstr "pypiserver" - -#: ../source/key_projects.rst:550 -msgid "" -"`Docs `__ | " -"`GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:554 -msgid "" -"pypiserver is a minimalist application that serves as a private Python " -"package index within organizations, implementing a simple API and browser " -"interface. You can upload private packages using standard upload tools, and " -"users can download and install them with :ref:`pip`, without publishing them " -"publicly. Organizations who use pypiserver usually download packages both " -"from pypiserver and from PyPI." -msgstr "" - -#: ../source/key_projects.rst:564 -msgid "scikit-build" -msgstr "scikit-build" - -#: ../source/key_projects.rst:566 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:570 -msgid "" -"Scikit-build is an improved build system generator for CPython C/C++/Fortran/" -"Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :" -"ref:`pip`. It internally uses `cmake `__ " -"(available on PyPI) to provide better support for additional compilers, " -"build systems, cross compilation, and locating dependencies and their " -"associated build requirements. To speed up and parallelize the build of " -"large projects, the user can install `ninja `__ (also available on PyPI)." -msgstr "" - -#: ../source/key_projects.rst:582 -msgid "shiv" -msgstr "shiv" - -#: ../source/key_projects.rst:584 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:588 -msgid "" -"shiv is a command line utility for building fully self contained Python " -"zipapps as outlined in :pep:`441`, but with all their dependencies included. " -"Its primary goal is making distributing Python applications and command line " -"tools fast & easy." -msgstr "" - -#: ../source/key_projects.rst:598 -msgid "" -"`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" -msgstr "" - -#: ../source/key_projects.rst:603 -msgid "" -"A flexible package manager designed to support multiple versions, " -"configurations, platforms, and compilers. Spack is like Homebrew, but " -"packages are written in Python and parameterized to allow easy swapping of " -"compilers, library versions, build options, etc. Arbitrarily many versions " -"of packages can coexist on the same system. Spack was designed for rapidly " -"building high performance scientific applications on clusters and " -"supercomputers." -msgstr "" - -#: ../source/key_projects.rst:611 -msgid "" -"Spack is not in PyPI (yet), but it requires no installation and can be used " -"immediately after cloning from GitHub." -msgstr "" - -#: ../source/key_projects.rst:617 -msgid "zest.releaser" -msgstr "zest.releaser" - -#: ../source/key_projects.rst:619 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:623 -msgid "" -"``zest.releaser`` is a Python package release tool providing an abstraction " -"layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to " -"automate incrementing package version numbers, updating changelogs, tagging " -"releases in source control, and uploading new packages to PyPI." -msgstr "" - -#: ../source/key_projects.rst:630 -msgid "Standard Library Projects" -msgstr "" - -#: ../source/key_projects.rst:635 -msgid "ensurepip" -msgstr "ensurepip" - -#: ../source/key_projects.rst:637 -msgid "" -"`Docs `__ | `Issues " -"`__" -msgstr "" - -#: ../source/key_projects.rst:640 -msgid "" -"A package in the Python Standard Library that provides support for " -"bootstrapping :ref:`pip` into an existing Python installation or virtual " -"environment. In most cases, end users won't use this module, but rather it " -"will be used during the build of the Python distribution." -msgstr "" - -#: ../source/key_projects.rst:649 -msgid "distutils" -msgstr "distutils" - -#: ../source/key_projects.rst:651 -msgid "" -"`Docs `__ | `Issues " -"`__" -msgstr "" - -#: ../source/key_projects.rst:654 -msgid "" -"The original Python packaging system, added to the standard library in " -"Python 2.0." -msgstr "" - -#: ../source/key_projects.rst:657 -msgid "" -"Due to the challenges of maintaining a packaging system where feature " -"updates are tightly coupled to language runtime updates, direct usage of :" -"ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being " -"the preferred replacement. :ref:`Setuptools` not only provides features that " -"plain :ref:`distutils` doesn't offer (such as dependency declarations and " -"entry point declarations), it also provides a consistent build interface and " -"feature set across all supported Python versions." -msgstr "" - -#: ../source/key_projects.rst:670 -msgid "venv" -msgstr "venv" - -#: ../source/key_projects.rst:672 -msgid "" -"`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:675 -msgid "" -"A package in the Python Standard Library (starting with Python 3.3) for " -"creating :term:`Virtual Environments `. For more " -"information, see the section on :ref:`Creating and using Virtual " -"Environments`." -msgstr "" - -#: ../source/news.rst:2 -msgid "News" -msgstr "Новини" - -#: ../source/news.rst:5 -msgid "September 2019" -msgstr "вересень 2019" - -#: ../source/news.rst:6 -msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" -msgstr "" - -#: ../source/news.rst:9 -msgid "August 2019" -msgstr "серпень 2019" - -#: ../source/news.rst:10 -msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" -msgstr "" - -#: ../source/news.rst:13 -msgid "July 2019" -msgstr "липень 2019" - -#: ../source/news.rst:14 -msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" -msgstr "" - -#: ../source/news.rst:15 -msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" -msgstr "" - -#: ../source/news.rst:16 -msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" -msgstr "" - -#: ../source/news.rst:17 -msgid "Updated directory layout examples for consistency. (:pr:`611`)" -msgstr "" - -#: ../source/news.rst:18 -msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" -msgstr "" - -#: ../source/news.rst:21 -msgid "June 2019" -msgstr "червень 2019" - -#: ../source/news.rst:22 -msgid "Fixed some typos. (:pr:`620`)" -msgstr "" - -#: ../source/news.rst:25 -msgid "May 2019" -msgstr "травень 2019" - -#: ../source/news.rst:26 -msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" -msgstr "" - -#: ../source/news.rst:27 -msgid "Added a MANIFEST.in guide page. (:pr:`609`)" -msgstr "" - -#: ../source/news.rst:30 -msgid "April 2019" -msgstr "квітень 2019" - -#: ../source/news.rst:31 -msgid "" -"Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" -msgstr "" - -#: ../source/news.rst:32 -msgid "Reduced emphasis on virtualenv. (:pr:`606`)" -msgstr "" - -#: ../source/news.rst:35 -msgid "March 2019" -msgstr "березень 2019" - -#: ../source/news.rst:36 -msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" -msgstr "" - -#: ../source/news.rst:37 -msgid "Covered RTD details for contributing. (:pr:`600`)" -msgstr "" - -#: ../source/news.rst:40 -msgid "February 2019" -msgstr "лютий 2019" - -#: ../source/news.rst:41 -msgid "" -"Elaborate upon the differences between the tutorial and the real packaging " -"process. (:pr:`602`)" -msgstr "" - -#: ../source/news.rst:42 -msgid "Added instructions to install Python CLI applications. (:pr:`594`)" -msgstr "" - -#: ../source/news.rst:45 -msgid "January 2019" -msgstr "січень 2019" - -#: ../source/news.rst:46 -msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" -msgstr "" - -#: ../source/news.rst:47 -msgid "Updated Sphinx and Nox. (:pr:`591`)" -msgstr "" - -#: ../source/news.rst:48 -msgid "Referenced Twine from Python3. (:pr:`581`)" -msgstr "" - -#: ../source/news.rst:51 -msgid "December 2018" -msgstr "грудень 2018" - -#: ../source/news.rst:52 -msgid "No programmers in the office!" -msgstr "" - -#: ../source/news.rst:55 -msgid "November 2018" -msgstr "листопад 2018" - -#: ../source/news.rst:56 -msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" -msgstr "" - -#: ../source/news.rst:57 -msgid "Changed bumpversion to bump2version. (:pr:`572`)" -msgstr "" - -#: ../source/news.rst:58 -msgid "Added single-sourcing package version example. (:pr:`573`)" -msgstr "" - -#: ../source/news.rst:59 -msgid "Added a guide for creating documentation. (:pr:`568`)" -msgstr "" - -#: ../source/news.rst:62 -msgid "October 2018" -msgstr "жовтень 2018" - -#: ../source/news.rst:63 -msgid "Updated Nox package name. (:pr:`566`)" -msgstr "" - -#: ../source/news.rst:64 -msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" -msgstr "" - -#: ../source/news.rst:67 -msgid "September 2018" -msgstr "вересень 2018" - -#: ../source/news.rst:68 -msgid "Added a section on checking RST markup. (:pr:`554`)" -msgstr "" - -#: ../source/news.rst:69 -msgid "Updated user installs page. (:pr:`558`)" -msgstr "" - -#: ../source/news.rst:70 -msgid "Updated Google BigQuery urls. (:pr:`556`)" -msgstr "" - -#: ../source/news.rst:71 -msgid "Replaced tar command with working command. (:pr:`552`)" -msgstr "" - -#: ../source/news.rst:72 -msgid "" -"Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" -msgstr "" - -#: ../source/news.rst:75 -msgid "August 2018" -msgstr "серпень 2018" - -#: ../source/news.rst:76 -msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" -msgstr "" - -#: ../source/news.rst:77 -msgid "" -"Moved the Overview to a task based lead in along with the others. (:pr:`540`)" -msgstr "" - -#: ../source/news.rst:78 -msgid "Updated Python version supported by virtualenv. (:pr:`538`)" -msgstr "" - -#: ../source/news.rst:79 -msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" -msgstr "" - -#: ../source/news.rst:82 -msgid "July 2018" -msgstr "липень 2018" - -#: ../source/news.rst:84 -msgid "Improved binary extension docs. (:pr:`531`)" -msgstr "" - -#: ../source/news.rst:85 -msgid "Added scikit-build to key projects. (:pr:`530`)" -msgstr "" - -#: ../source/news.rst:88 -msgid "June 2018" -msgstr "червень 2018" - -#: ../source/news.rst:90 -msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" -msgstr "" - -#: ../source/news.rst:91 -msgid "Updated Markdown descriptions explanation. (:pr:`522`)" -msgstr "" - -#: ../source/news.rst:94 -msgid "May 2018" -msgstr "травень 2018" - -#: ../source/news.rst:96 -msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" -msgstr "" - -#: ../source/news.rst:97 -msgid "" -"Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" -msgstr "" - -#: ../source/news.rst:98 -msgid "Simplified packaging tutorial. (:pr:`498`)" -msgstr "" - -#: ../source/news.rst:99 -msgid "Updated Windows users instructions for clarity. (:pr:`493`)" -msgstr "" - -#: ../source/news.rst:100 -msgid "Updated the license section description for completeness. (:pr:`492`)" -msgstr "" - -#: ../source/news.rst:101 -msgid "Added specification-style document to contributing section. (:pr:`489`)" -msgstr "" - -#: ../source/news.rst:102 -msgid "Added documentation types to contributing guide. (:pr:`485`)" -msgstr "" - -#: ../source/news.rst:105 -msgid "April 2018" -msgstr "квітень 2018" - -#: ../source/news.rst:107 -msgid "Added README guide. (:pr:`461`)" -msgstr "" - -#: ../source/news.rst:108 -msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" -msgstr "" - -#: ../source/news.rst:109 -msgid "Added instructions for Warehouse. (:pr:`471`)" -msgstr "" - -#: ../source/news.rst:110 -msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" -msgstr "" - -#: ../source/news.rst:111 -msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" -msgstr "" - -#: ../source/news.rst:112 -msgid "Added a guide for phasing out Python versions. (:pr:`459`)" -msgstr "" - -#: ../source/news.rst:113 -msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" -msgstr "" - -#: ../source/news.rst:116 -msgid "March 2018" -msgstr "березень 2018" - -#: ../source/news.rst:118 -msgid "Updated \"installing scientific packages\". (:pr:`455`)" -msgstr "" - -#: ../source/news.rst:119 -msgid "" -"Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" -msgstr "" - -#: ../source/news.rst:120 -msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" -msgstr "" - -#: ../source/news.rst:121 -msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" -msgstr "" - -#: ../source/news.rst:124 -msgid "February 2018" -msgstr "лютий 2018" - -#: ../source/news.rst:126 -msgid "" -"Added python3-venv and python3-pip to Debian installation instructions. (:pr:" -"`445`)" -msgstr "" - -#: ../source/news.rst:127 -msgid "Updated PyPI migration info. (:pr:`439`)" -msgstr "" - -#: ../source/news.rst:128 -msgid "" -"Added a warning about managing multiple versions with pipenv. (:pr:`430`)" -msgstr "" - -#: ../source/news.rst:129 -msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" -msgstr "" - -#: ../source/news.rst:130 -msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" -msgstr "" - -#: ../source/news.rst:133 -msgid "January 2018" -msgstr "січень 2018" - -#: ../source/news.rst:135 -msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" -msgstr "" - -#: ../source/news.rst:136 -msgid "Updated README.rst explanation. (:pr:`419`)" -msgstr "" - -#: ../source/news.rst:139 -msgid "December 2017" -msgstr "грудень 2017" - -#: ../source/news.rst:141 -msgid "" -"Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" -msgstr "" - -#: ../source/news.rst:142 -msgid "Noted which fields can be used with environment markers. (:pr:`416`)" -msgstr "" - -#: ../source/news.rst:143 -msgid "Updated Requires-Python section. (:pr:`414`)" -msgstr "" - -#: ../source/news.rst:144 -msgid "Added news page. (:pr:`404`)" -msgstr "" - -#: ../source/news.rst:147 -msgid "November 2017" -msgstr "листопад 2017" - -#: ../source/news.rst:149 -msgid "" -"Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" -msgstr "" - -#: ../source/news.rst:150 -msgid "" -"Updated the *Single Sourcing Package Version* tutorial to reflect pip's " -"current strategy. (:pr:`400`)" -msgstr "" - -#: ../source/news.rst:152 -msgid "" -"Added documentation about the ``py_modules`` argument to ``setup``. (:pr:" -"`398`)" -msgstr "" - -#: ../source/news.rst:153 -msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" -msgstr "" - -#: ../source/news.rst:156 -msgid "October 2017" -msgstr "жовтень 2017" - -#: ../source/news.rst:158 -msgid "" -"Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" -msgstr "" - -#: ../source/news.rst:159 -msgid "" -"Created a new guide for managing packages using ``pip`` and ``virtualenv``. " -"(:pr:`385`)" -msgstr "" - -#: ../source/news.rst:160 -msgid "Split the specifications page into multiple pages. (:pr:`386`)" -msgstr "" - -#: ../source/news.rst:163 -msgid "September 2017" -msgstr "вересень 2017" - -#: ../source/news.rst:165 -msgid "" -"Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:" -"`379`)" -msgstr "" - -#: ../source/news.rst:167 -msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" -msgstr "" - -#: ../source/news.rst:170 -msgid "August 2017" -msgstr "серпень 2017" - -#: ../source/news.rst:172 -msgid "" -"Added a new, experimental tutorial on installing packages using ``Pipenv``. " -"(:pr:`369`)" -msgstr "" - -#: ../source/news.rst:173 -msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" -msgstr "" - -#: ../source/news.rst:174 -msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" -msgstr "" - -#: ../source/news.rst:177 -msgid "July 2017" -msgstr "липень 2017" - -#: ../source/news.rst:179 -msgid "Added ``flit`` to the key projects list. (:pr:`358`)" -msgstr "" - -#: ../source/news.rst:180 -msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" -msgstr "" - -#: ../source/news.rst:181 -msgid "" -"Updated this guide's ``readme`` with instructions on how to build the guide " -"locally. (:pr:`356`)" -msgstr "" - -#: ../source/news.rst:182 -msgid "" -"Made the new ``TestPyPI`` URL more visible, adding note to homepage about " -"pypi.org. (:pr:`354`)" -msgstr "" - -#: ../source/news.rst:183 -msgid "" -"Added a note about the removal of the explicit registration API. (:pr:`347`)" -msgstr "" - -#: ../source/news.rst:186 -msgid "June 2017" -msgstr "червень 2017" - -#: ../source/news.rst:188 -msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" -msgstr "" - -#: ../source/news.rst:189 -msgid "Added documentation for ``python_requires``. (:pr:`338`)" -msgstr "" - -#: ../source/news.rst:190 -msgid "" -"Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:" -"pr:`335`)" -msgstr "" - -#: ../source/news.rst:191 -msgid "" -"Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" -msgstr "" - -#: ../source/news.rst:192 -msgid "Added a license section to the distributing guide. (:pr:`331`)" -msgstr "" - -#: ../source/news.rst:193 -msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" -msgstr "" - -#: ../source/news.rst:194 -msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" -msgstr "" - -#: ../source/news.rst:195 -msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" -msgstr "" - -#: ../source/news.rst:196 -msgid "Switched to the PyPA theme. (:pr:`305`)" -msgstr "" - -#: ../source/news.rst:197 -msgid "Re-organized the documentation into the new structure. (:pr:`318`)" -msgstr "" - -#: ../source/news.rst:200 -msgid "May 2017" -msgstr "травень 2017" - -#: ../source/news.rst:202 -msgid "" -"Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" -msgstr "" - -#: ../source/news.rst:203 -msgid "Added contributor and style guide. (:pr:`307`)" -msgstr "" - -#: ../source/news.rst:204 -msgid "" -"Documented ``pip`` and ``easy_install``'s differences for per-project " -"indexes. (:pr:`233`)" -msgstr "" - -#: ../source/news.rst:207 -msgid "April 2017" -msgstr "квітень 2017" - -#: ../source/news.rst:209 -msgid "Added travis configuration for testing pull requests. (:pr:`300`)" -msgstr "" - -#: ../source/news.rst:210 -msgid "" -"Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:" -"`299`)" -msgstr "" - -#: ../source/news.rst:211 -msgid "" -"Removed the ``twine register`` reference in the *Distributing Packages* " -"tutorial. (:pr:`271`)" -msgstr "" - -#: ../source/news.rst:212 -msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" -msgstr "" - -#: ../source/news.rst:213 -msgid "Added a topic on namespace packages. (:pr:`290`)" -msgstr "" - -#: ../source/news.rst:214 -msgid "" -"Added documentation explaining prominently how to install ``pip`` in ``/usr/" -"local``. (:pr:`230`)" -msgstr "" - -#: ../source/news.rst:215 -msgid "" -"Updated development mode documentation to mention that order of local " -"packages matters. (:pr:`208`)" -msgstr "" - -#: ../source/news.rst:216 -msgid "" -"Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted " -"projects (:pr:`239`)" -msgstr "" - -#: ../source/news.rst:217 -msgid "" -"Swaped order of :file:`setup.py` arguments for the upload command, as order " -"is significant. (:pr:`260`)" -msgstr "" - -#: ../source/news.rst:219 -msgid "" -"Explained how to install from unsupported sources using a helper " -"application. (:pr:`289`)" -msgstr "" - -#: ../source/news.rst:223 -msgid "March 2017" -msgstr "березень 2017" - -#: ../source/news.rst:225 -msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" -msgstr "" - -#: ../source/news.rst:228 -msgid "February 2017" -msgstr "лютий 2017" - -#: ../source/news.rst:230 -msgid "Added :pep:`518`. (:pr:`281`)" -msgstr "" - -#: ../source/overview.rst:3 -msgid "An Overview of Packaging for Python" -msgstr "" - -#: ../source/overview.rst:7 -msgid "" -"As a general-purpose programming language, Python is designed to be used in " -"many ways. You can build web sites or industrial robots or a game for your " -"friends to play, and much more, all using the same core technology." -msgstr "" - -#: ../source/overview.rst:12 -msgid "" -"Python's flexibility is why the first step in every Python project must be " -"to think about the project's audience and the corresponding environment " -"where the project will run. It might seem strange to think about packaging " -"before writing code, but this process does wonders for avoiding future " -"headaches." -msgstr "" - -#: ../source/overview.rst:18 -msgid "" -"This overview provides a general-purpose decision tree for reasoning about " -"Python's plethora of packaging options. Read on to choose the best " -"technology for your next project." -msgstr "" - -#: ../source/overview.rst:26 -msgid "Thinking about deployment" -msgstr "" - -#: ../source/overview.rst:28 -msgid "" -"Packages exist to be installed (or *deployed*), so before you package " -"anything, you'll want to have some answers to the deployment questions below:" -msgstr "" - -#: ../source/overview.rst:32 -msgid "" -"Who are your software's users? Will your software be installed by other " -"developers doing software development, operations people in a datacenter, or " -"a less software-savvy group?" -msgstr "" - -#: ../source/overview.rst:35 -msgid "" -"Is your software intended to run on servers, desktops, mobile clients " -"(phones, tablets, etc.), or embedded in dedicated devices?" -msgstr "" - -#: ../source/overview.rst:37 -msgid "" -"Is your software installed individually, or in large deployment batches?" -msgstr "" - -#: ../source/overview.rst:39 -msgid "" -"Packaging is all about target environment and deployment experience. There " -"are many answers to the questions above and each combination of " -"circumstances has its own solutions. With this information, the following " -"overview will guide you to the packaging technologies best suited to your " -"project." -msgstr "" - -#: ../source/overview.rst:46 -msgid "Packaging Python libraries and tools" -msgstr "" - -#: ../source/overview.rst:48 -msgid "" -"You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are " -"just a few of the tools Python's ecosystem provides for distributing Python " -"code to developers, which you can read about in :doc:`guides/distributing-" -"packages-using-setuptools`." -msgstr "" - -#: ../source/overview.rst:53 -msgid "" -"The following approaches to packaging are meant for libraries and tools used " -"by technical audience in a development setting. If you're looking for ways " -"to package Python for a non-technical audience and/or a production setting, " -"skip ahead to :ref:`packaging-applications`." -msgstr "" - -#: ../source/overview.rst:59 -msgid "Python modules" -msgstr "" - -#: ../source/overview.rst:61 -msgid "" -"A Python file, provided it only relies on the standard library, can be " -"redistributed and reused. You will also need to ensure it's written for the " -"right version of Python, and only relies on the standard library." -msgstr "" - -#: ../source/overview.rst:66 -msgid "" -"This is great for sharing simple scripts and snippets between people who " -"both have compatible Python versions (such as via email, StackOverflow, or " -"GitHub gists). There are even some entire Python libraries that offer this " -"as an option, such as `bottle.py `_ and " -"`boltons `_." -msgstr "" - -#: ../source/overview.rst:73 -msgid "" -"However, this pattern won't scale for projects that consist of multiple " -"files, need additional libraries, or need a specific version of Python, " -"hence the options below." -msgstr "" - -#: ../source/overview.rst:78 -msgid "Python source distributions" -msgstr "" - -#: ../source/overview.rst:80 -msgid "" -"If your code consists of multiple Python files, it's usually organized into " -"a directory structure. Any directory containing Python files can comprise " -"an :term:`Import Package`." -msgstr "" - -#: ../source/overview.rst:84 -msgid "" -"Because packages consist of multiple files, they are harder to distribute. " -"Most protocols support transferring only one file at a time (when was the " -"last time you clicked a link and it downloaded multiple files?). It's easier " -"to get incomplete transfers, and harder to guarantee code integrity at the " -"destination." -msgstr "" - -#: ../source/overview.rst:90 -msgid "" -"So long as your code contains nothing but pure Python code, and you know " -"your deployment environment supports your version of Python, then you can " -"use Python's native packaging tools to create a *source* :term:`Distribution " -"Package`, or *sdist* for short." -msgstr "" - -#: ../source/overview.rst:95 -msgid "" -"Python's *sdists* are compressed archives (``.tar.gz`` files) containing one " -"or more packages or modules. If your code is pure-Python, and you only " -"depend on other Python packages, you can `go here to learn more `_." -msgstr "" - -#: ../source/overview.rst:100 -msgid "" -"If you rely on any non-Python code, or non-Python packages (such as `libxml2 " -"`_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next " -"section, which also has many advantages for pure-Python libraries." -msgstr "" - -#: ../source/overview.rst:107 -msgid "" -"Python and PyPI support multiple distributions providing different " -"implementations of the same package. For instance the unmaintained-but-" -"seminal `PIL distribution `_ provides the PIL " -"package, and so does `Pillow `_, an " -"actively-maintained fork of PIL!" -msgstr "" - -#: ../source/overview.rst:114 -msgid "" -"This Python packaging superpower makes it possible for Pillow to be a drop-" -"in replacement for PIL, just by changing your project's ``install_requires`` " -"or ``requirements.txt``." -msgstr "" - -#: ../source/overview.rst:119 -msgid "Python binary distributions" -msgstr "" - -#: ../source/overview.rst:121 -msgid "" -"So much of Python's practical power comes from its ability to integrate with " -"the software ecosystem, in particular libraries written in C, C++, Fortran, " -"Rust, and other languages." -msgstr "" - -#: ../source/overview.rst:125 -msgid "" -"Not all developers have the right tools or experiences to build these " -"components written in these compiled languages, so Python created the :term:" -"`Wheel`, a package format designed to ship libraries with compiled " -"artifacts. In fact, Python's package installer, ``pip``, always prefers " -"wheels because installation is always faster, so even pure-Python packages " -"work better with wheels." -msgstr "" - -#: ../source/overview.rst:132 -msgid "" -"Binary distributions are best when they come with source distributions to " -"match. Even if you don't upload wheels of your code for every operating " -"system, by uploading the sdist, you're enabling users of other platforms to " -"still build it for themselves. Default to publishing both sdist and wheel " -"archives together, *unless* you're creating artifacts for a very specific " -"use case where you know the recipient only needs one or the other." -msgstr "" - -#: ../source/overview.rst:140 -msgid "" -"Python and PyPI make it easy to upload both wheels and sdists together. Just " -"follow the :doc:`tutorials/packaging-projects` tutorial." -msgstr "" - -#: ../source/overview.rst:148 -msgid "" -"Python's recommended built-in library and tool packaging technologies. " -"Excerpted from `The Packaging Gradient (2017) `_." -msgstr "" - -#: ../source/overview.rst:155 -msgid "Packaging Python applications" -msgstr "" - -#: ../source/overview.rst:157 -msgid "" -"So far we've only discussed Python's native distribution tools. Based on our " -"introduction, you would be correct to infer these built-in approaches only " -"target environments which have Python, and an audience who knows how to " -"install Python packages." -msgstr "" - -#: ../source/overview.rst:162 -msgid "" -"With the variety of operating systems, configurations, and people out there, " -"this assumption is only safe when targeting a developer audience." -msgstr "" - -#: ../source/overview.rst:166 -msgid "" -"Python's native packaging is mostly built for distributing reusable code, " -"called libraries, between developers. You can piggyback **tools**, or basic " -"applications for developers, on top of Python's library packaging, using " -"technologies like `setuptools entry_points `_." -msgstr "" - -#: ../source/overview.rst:172 -msgid "" -"Libraries are building blocks, not complete applications. For distributing " -"applications, there's a whole new world of technologies out there." -msgstr "" - -#: ../source/overview.rst:176 -msgid "" -"The next few sections organize these application packaging options according " -"to their dependencies on the target environment, so you can choose the right " -"one for your project." -msgstr "" - -#: ../source/overview.rst:181 -msgid "Depending on a framework" -msgstr "" - -#: ../source/overview.rst:183 -msgid "" -"Some types of Python applications, like web site backends and other network " -"services, are common enough that they have frameworks to enable their " -"development and packaging. Other types of applications, like dynamic web " -"frontends and mobile clients, are complex enough to target that a framework " -"becomes more than a convenience." -msgstr "" - -#: ../source/overview.rst:189 -msgid "" -"In all these cases, it makes sense to work backwards, from the framework's " -"packaging and deployment story. Some frameworks include a deployment system " -"which wraps the technologies outlined in the rest of the guide. In these " -"cases, you'll want to defer to your framework's packaging guide for the " -"easiest and most reliable production experience." -msgstr "" - -#: ../source/overview.rst:195 -msgid "" -"If you ever wonder how these platforms and frameworks work under the hood, " -"you can always read the sections beyond." -msgstr "" - -#: ../source/overview.rst:199 -msgid "Service platforms" -msgstr "" - -#: ../source/overview.rst:201 -msgid "" -"If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku " -"or Google App Engine, you are going to want to follow their respective " -"packaging guides." -msgstr "" - -#: ../source/overview.rst:205 -msgid "" -"`Heroku `_" -msgstr "" -"`Heroku `_" - -#: ../source/overview.rst:206 -msgid "`Google App Engine `_" -msgstr "`Google App Engine `_" - -#: ../source/overview.rst:207 -msgid "`PythonAnywhere `_" -msgstr "`PythonAnywhere `_" - -#: ../source/overview.rst:208 -msgid "`OpenShift `_" -msgstr "`OpenShift `_" - -#: ../source/overview.rst:209 -msgid "\"Serverless\" frameworks like `Zappa `_" -msgstr "" - -#: ../source/overview.rst:211 -msgid "" -"In all these setups, the platform takes care of packaging and deployment, as " -"long as you follow their patterns. Most software does not fit one of these " -"templates, hence the existence of all the other options below." -msgstr "" - -#: ../source/overview.rst:216 -msgid "" -"If you're developing software that will be deployed to machines you own, " -"users' personal computers, or any other arrangement, read on." -msgstr "" - -#: ../source/overview.rst:220 -msgid "Web browsers and mobile applications" -msgstr "" - -#: ../source/overview.rst:222 -msgid "" -"Python's steady advances are leading it into new spaces. These days you can " -"write a mobile app or web application frontend in Python. While the language " -"may be familiar, the packaging and deployment practices are brand new." -msgstr "" - -#: ../source/overview.rst:227 -msgid "" -"If you're planning on releasing to these new frontiers, you'll want to check " -"out the following frameworks, and refer to their packaging guides:" -msgstr "" - -#: ../source/overview.rst:231 -msgid "`Kivy `_" -msgstr "`Kivy `_" - -#: ../source/overview.rst:232 -msgid "`Beeware `_" -msgstr "`Beeware `_" - -#: ../source/overview.rst:233 -msgid "`Brython `_" -msgstr "`Brython `_" - -#: ../source/overview.rst:234 -msgid "`Flexx `_" -msgstr "`Flexx `_" - -#: ../source/overview.rst:236 -msgid "" -"If you are *not* interested in using a framework or platform, or just wonder " -"about some of the technologies and techniques utilized by the frameworks " -"above, continue reading below." -msgstr "" - -#: ../source/overview.rst:241 -msgid "Depending on a pre-installed Python" -msgstr "" - -#: ../source/overview.rst:243 -msgid "" -"Pick an arbitrary computer, and depending on the context, there's a very " -"good chance Python is already installed. Included by default in most Linux " -"and Mac operating systems for many years now, you can reasonably depend on " -"Python preexisting in your data centers or on the personal machines of " -"developers and data scientists." -msgstr "" - -#: ../source/overview.rst:249 -msgid "Technologies which support this model:" -msgstr "" - -#: ../source/overview.rst:251 -msgid "`PEX `_ (Python EXecutable)" -msgstr "" - -#: ../source/overview.rst:252 -msgid "" -"`zipapp `_ (does not help " -"manage dependencies, requires Python 3.5+)" -msgstr "" - -#: ../source/overview.rst:253 -msgid "`shiv `_ (requires Python 3)" -msgstr "`shiv `_ (потребує Python 3)" - -#: ../source/overview.rst:255 -msgid "" -"Of all the approaches here, depending on a pre-installed Python relies the " -"most on the target environment. Of course, this also makes for the smallest " -"package, as small as single-digit megabytes, or even kilobytes." -msgstr "" - -#: ../source/overview.rst:260 -msgid "" -"In general, decreasing the dependency on the target system increases the " -"size of our package, so the solutions here are roughly arranged by " -"increasing size of output." -msgstr "" - -#: ../source/overview.rst:267 -msgid "Depending on a separate software distribution ecosystem" -msgstr "" - -#: ../source/overview.rst:269 -msgid "" -"For a long time many operating systems, including Mac and Windows, lacked " -"built-in package management. Only recently did these OSes gain so-called " -"\"app stores\", but even those focus on consumer applications and offer " -"little for developers." -msgstr "" - -#: ../source/overview.rst:274 -msgid "" -"Developers long sought remedies, and in this struggle, emerged with their " -"own package management solutions, such as `Homebrew `_. " -"The most relevant alternative for Python developers is a package ecosystem " -"called `Anaconda `_. Anaconda is built around Python and is " -"increasingly common in academic, analytical, and other data-oriented " -"environments, even making its way `into server-oriented environments " -"`_." -msgstr "" - -#: ../source/overview.rst:284 -msgid "Instructions on building and publishing for the Anaconda ecosystem:" -msgstr "" - -#: ../source/overview.rst:286 -msgid "" -"`Building libraries and applications with conda `_" -msgstr "" - -#: ../source/overview.rst:287 -msgid "" -"`Transitioning a native Python package to Anaconda `_" -msgstr "" - -#: ../source/overview.rst:289 -msgid "" -"A similar model involves installing an alternative Python distribution, but " -"does not support arbitrary operating system-level packages:" -msgstr "" - -#: ../source/overview.rst:293 -msgid "`Enthought Canopy `_" -msgstr "`Enthought Canopy `_" - -#: ../source/overview.rst:294 -msgid "`ActiveState ActivePython `_" -msgstr "`ActiveState ActivePython `_" - -#: ../source/overview.rst:295 -msgid "`WinPython `_" -msgstr "`WinPython `_" - -#: ../source/overview.rst:300 -msgid "Bringing your own Python executable" -msgstr "" - -#: ../source/overview.rst:302 -msgid "" -"Computing as we know it is defined by the ability to execute programs. Every " -"operating system natively supports one or more formats of program they can " -"natively execute." -msgstr "" - -#: ../source/overview.rst:306 -msgid "" -"There are many techniques and technologies which turn your Python program " -"into one of these formats, most of which involve embedding the Python " -"interpreter and any other dependencies into a single executable file." -msgstr "" - -#: ../source/overview.rst:311 -msgid "" -"This approach, called *freezing*, offers wide compatibility and seamless " -"user experience, though often requires multiple technologies, and a good " -"amount of effort." -msgstr "" - -#: ../source/overview.rst:315 -msgid "A selection of Python freezers:" -msgstr "" - -#: ../source/overview.rst:317 -msgid "`pyInstaller `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:318 -msgid "" -"`cx_Freeze `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:319 -msgid "" -"`constructor `_ - For command-line " -"installers" -msgstr "" - -#: ../source/overview.rst:320 -msgid "`py2exe `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:321 -msgid "`py2app `_ - Mac only" -msgstr "" - -#: ../source/overview.rst:322 -msgid "" -"`bbFreeze `_ - Windows, Linux, Python 2 " -"only" -msgstr "" - -#: ../source/overview.rst:323 -msgid "`osnap `_ - Windows and Mac" -msgstr "" - -#: ../source/overview.rst:324 -msgid "`pynsist `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:326 -msgid "" -"Most of the above imply single-user deployments. For multi-component server " -"applications, see `Chef Omnibus `_." -msgstr "" - -#: ../source/overview.rst:332 -msgid "Bringing your own userspace" -msgstr "" - -#: ../source/overview.rst:334 -msgid "" -"An increasing number of operating systems -- including Linux, Mac OS, and " -"Windows -- can be set up to run applications packaged as lightweight images, " -"using a relatively modern arrangement often referred to as `operating-system-" -"level virtualization `_, or *containerization*." -msgstr "" - -#: ../source/overview.rst:341 -msgid "" -"These techniques are mostly Python agnostic, because they package whole OS " -"filesystems, not just Python or Python packages." -msgstr "" - -#: ../source/overview.rst:344 -msgid "" -"Adoption is most extensive among Linux servers, where the technology " -"originated and where the technologies below work best:" -msgstr "" - -#: ../source/overview.rst:347 -msgid "`AppImage `_" -msgstr "`AppImage `_" - -#: ../source/overview.rst:348 -msgid "`Docker `_" -msgstr "`Docker `_" - -#: ../source/overview.rst:349 -msgid "`Flatpak `_" -msgstr "`Flatpak `_" - -#: ../source/overview.rst:350 -msgid "`Snapcraft `_" -msgstr "`Snapcraft `_" - -#: ../source/overview.rst:353 -msgid "Bringing your own kernel" -msgstr "" - -#: ../source/overview.rst:355 -msgid "" -"Most operating systems support some form of classical virtualization, " -"running applications packaged as images containing a full operating system " -"of their own. Running these virtual machines, or VMs, is a mature approach, " -"widespread in data center environments." -msgstr "" - -#: ../source/overview.rst:360 -msgid "" -"These techniques are mostly reserved for larger scale deployments in data " -"centers, though certain complex applications can benefit from this " -"packaging. Technologies are Python agnostic, and include:" -msgstr "" - -#: ../source/overview.rst:364 -msgid "`Vagrant `_" -msgstr "`Vagrant `_" - -#: ../source/overview.rst:365 -msgid "" -"`VHD `_, `AMI `_, and `other formats `_" -msgstr "" - -#: ../source/overview.rst:366 -msgid "" -"`OpenStack `_ - A cloud " -"management system in Python, with extensive VM support" -msgstr "" - -#: ../source/overview.rst:369 -msgid "Bringing your own hardware" -msgstr "" - -#: ../source/overview.rst:371 -msgid "" -"The most all-encompassing way to ship your software would be to ship it " -"already-installed on some hardware. This way, your software's user would " -"require only electricity." -msgstr "" - -#: ../source/overview.rst:375 -msgid "" -"Whereas the virtual machines described above are primarily reserved for the " -"tech-savvy, you can find hardware appliances being used by everyone from the " -"most advanced data centers to the youngest children." -msgstr "" - -#: ../source/overview.rst:379 -msgid "" -"Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the " -"datacenter or your users' homes. They plug and play, and you can call it a " -"day." -msgstr "" - -#: ../source/overview.rst:389 -msgid "" -"The simplified gamut of technologies used to package Python applications." -msgstr "" - -#: ../source/overview.rst:392 -msgid "What about..." -msgstr "А як щодо..." - -#: ../source/overview.rst:394 -msgid "" -"The sections above can only summarize so much, and you might be wondering " -"about some of the more conspicuous gaps." -msgstr "" - -#: ../source/overview.rst:398 -msgid "Operating system packages" -msgstr "" - -#: ../source/overview.rst:400 -msgid "" -"As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some " -"operating systems have package managers of their own. If you're very sure of " -"the operating system you're targeting, you can depend directly on a format " -"like `deb `_ (for Debian, " -"Ubuntu, etc.) or `RPM `_ " -"(for Red Hat, Fedora, etc.), and use that built-in package manager to take " -"care of installation, and even deployment. You can even use `FPM `_ to generate both deb " -"and RPMs from the same source." -msgstr "" - -#: ../source/overview.rst:411 -msgid "" -"In most deployment pipelines, the OS package manager is just one piece of " -"the puzzle." -msgstr "" - -#: ../source/overview.rst:417 -msgid "" -"`Virtualenvs `_ have been an indispensable tool for multiple generations of Python " -"developer, but are slowly fading from view, as they are being wrapped by " -"higher-level tools. With packaging in particular, virtualenvs are used as a " -"primitive in `the dh-virtualenv tool `_ and `osnap `_, " -"both of which wrap virtualenvs in a self-contained way." -msgstr "" - -#: ../source/overview.rst:427 -msgid "" -"For production deployments, do not rely on running ``python -m pip install`` " -"from the Internet into a virtualenv, as one might do in a development " -"environment. The overview above is full of much better solutions." -msgstr "" - -#: ../source/overview.rst:432 -msgid "Security" -msgstr "Безпека" - -#: ../source/overview.rst:434 -msgid "" -"The further down the gradient you come, the harder it gets to update " -"components of your package. Everything is more tightly bound together." -msgstr "" - -#: ../source/overview.rst:437 -msgid "" -"For example, if a kernel security issue emerges, and you're deploying " -"containers, the host system's kernel can be updated without requiring a new " -"build on behalf of the application. If you deploy VM images, you'll need a " -"new build. Whether or not this dynamic makes one option more secure is still " -"a bit of an old debate, going back to the still-unsettled matter of `static " -"versus dynamic linking `_." -msgstr "" - -#: ../source/overview.rst:446 -msgid "Wrap up" -msgstr "Підсумок" - -#: ../source/overview.rst:448 -msgid "" -"Packaging in Python has a bit of a reputation for being a bumpy ride. This " -"impression is mostly a byproduct of Python's versatility. Once you " -"understand the natural boundaries between each packaging solution, you begin " -"to realize that the varied landscape is a small price Python programmers pay " -"for using one of the most balanced, flexible languages available." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:6 -msgid "Binary distribution format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:8 -msgid "" -"The binary distribution format (:term:`wheel `) was originally " -"defined in :pep:`427`. The current version of the specification is here." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:13 -msgid "Abstract" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:15 -msgid "This PEP describes a built-package format for Python called \"wheel\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:17 -msgid "" -"A wheel is a ZIP-format archive with a specially formatted file name and the " -"``.whl`` extension. It contains a single distribution nearly as it would be " -"installed according to PEP 376 with a particular installation scheme. " -"Although a specialized installer is recommended, a wheel file may be " -"installed by simply unpacking into site-packages with the standard 'unzip' " -"tool while preserving enough information to spread its contents out onto " -"their final paths at any later time." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:27 -msgid "PEP Acceptance" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:29 -msgid "" -"This PEP was accepted, and the defined wheel version updated to 1.0, by Nick " -"Coghlan on 16th February, 2013 [1]_" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:34 -msgid "Rationale" -msgstr "Обґрунтування" - -#: ../source/specifications/binary-distribution-format.rst:36 -msgid "" -"Python needs a package format that is easier to install than sdist. Python's " -"sdist packages are defined by and require the distutils and setuptools build " -"systems, running arbitrary code to build-and-install, and re-compile, code " -"just so it can be installed into a new virtualenv. This system of " -"conflating build-install is slow, hard to maintain, and hinders innovation " -"in both build systems and installers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:43 -msgid "" -"Wheel attempts to remedy these problems by providing a simpler interface " -"between the build system and the installer. The wheel binary package format " -"frees installers from having to know about the build system, saves time by " -"amortizing compile time over many installations, and removes the need to " -"install a build system in the target environment." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:52 -msgid "Details" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:55 -msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:57 -msgid "Wheel installation notionally consists of two phases:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:59 -msgid "Unpack." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:61 -msgid "Parse ``distribution-1.0.dist-info/WHEEL``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:62 -msgid "" -"Check that installer is compatible with Wheel-Version. Warn if minor " -"version is greater, abort if major version is greater." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:64 -msgid "" -"If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:66 -msgid "Else unpack archive into platlib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:68 -msgid "Spread." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:70 -msgid "" -"Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is " -"data) ``distribution-1.0.data/``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:72 -msgid "" -"Move each subtree of ``distribution-1.0.data/`` onto its destination path. " -"Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of " -"destination directories, such as ``distribution-1.0.data/(purelib|platlib|" -"headers|scripts|data)``. The initially supported paths are taken from " -"``distutils.command.install``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:78 -msgid "" -"If applicable, update scripts starting with ``#!python`` to point to the " -"correct interpreter." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:80 -msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:82 -msgid "Remove empty ``distribution-1.0.data`` directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:83 -msgid "" -"Compile any installed .py to .pyc. (Uninstallers should be smart enough to " -"remove .pyc even if it is not mentioned in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:87 -msgid "Recommended installer features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:97 -msgid "Rewrite ``#!python``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:90 -msgid "" -"In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/" -"``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!" -"python'``, rewrite to point to the correct interpreter. Unix installers may " -"need to add the +x bit to these files if the archive was created on Windows." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:96 -msgid "" -"The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI " -"script instead of a console script." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:102 -msgid "Generate script wrappers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:100 -msgid "" -"In wheel, scripts packaged on Unix systems will certainly not have " -"accompanying .exe wrappers. Windows installers may want to add them during " -"install." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:105 -msgid "Recommended archiver features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:112 -msgid "Place ``.dist-info`` at the end of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:108 -msgid "" -"Archivers are encouraged to place the ``.dist-info`` files physically at the " -"end of the archive. This enables some potentially interesting ZIP tricks " -"including the ability to amend the metadata without rewriting the entire " -"archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:115 -msgid "File Format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:118 -msgid "File name convention" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:120 -msgid "" -"The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-" -"{abi tag}-{platform tag}.whl``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "distribution" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "Distribution name, e.g. 'django', 'pyramid'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "Distribution version, e.g. 1.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:135 -msgid "build tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:130 -msgid "" -"Optional build number. Must start with a digit. Acts as a tie-breaker if " -"two wheel file names are the same in all other respects (i.e. name, version, " -"and other tags). Sort as an empty tuple if unspecified, else sort as a two-" -"item tuple with the first item being the initial digits as an ``int``, and " -"the second item being the remainder of the tag as a ``str``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "language implementation and version tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "E.g. 'py27', 'py2', 'py3'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "abi tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "E.g. 'cp33m', 'abi3', 'none'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "platform tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "E.g. 'linux_x86_64', 'any'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:146 -msgid "" -"For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of " -"a package called 'distribution', and is compatible with Python 2.7 (any " -"Python 2.7 implementation), with no ABI (pure Python), on any CPU " -"architecture." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:151 -msgid "" -"The last three components of the filename before the extension are called " -"\"compatibility tags.\" The compatibility tags express the package's basic " -"interpreter requirements and are detailed in PEP 425." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:156 -msgid "Escaping and Unicode" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:158 -msgid "" -"As the components of the filename are separated by a dash (``-``, HYPHEN-" -"MINUS), this character cannot appear within any component. This is handled " -"as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:161 -msgid "" -"In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE " -"and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent " -"to :pep:`503` normalisation followed by replacing ``-`` with ``_``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:164 -msgid "" -"Version numbers should be normalised according to :pep:`440`. Normalised " -"version numbers cannot contain ``-``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:166 -msgid "" -"The remaining components may not contain ``-`` characters, so no escaping is " -"necessary." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:169 -msgid "" -"Tools producing wheels should verify that the filename components do not " -"contain ``-``, as the resulting file may not be processed correctly if they " -"do." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:172 -msgid "" -"The archive filename is Unicode. It will be some time before the tools are " -"updated to support non-ASCII filenames, but they are supported in this " -"specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:176 -msgid "" -"The filenames *inside* the archive are encoded as UTF-8. Although some ZIP " -"clients in common use do not properly display UTF-8 filenames, the encoding " -"is supported by both the ZIP specification and Python's ``zipfile``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:182 -msgid "File contents" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:184 -msgid "" -"The contents of a wheel file, where {distribution} is replaced with the name " -"of the package, e.g. ``beaglevote`` and {version} is replaced with its " -"version, e.g. ``1.0.0``, consist of:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:188 -msgid "" -"``/``, the root of the archive, contains all files to be installed in " -"``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and " -"``platlib`` are usually both ``site-packages``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:191 -msgid "``{distribution}-{version}.dist-info/`` contains metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:192 -msgid "" -"``{distribution}-{version}.data/`` contains one subdirectory for each non-" -"empty install scheme key not already covered, where the subdirectory name is " -"an index into a dictionary of install paths (e.g. ``data``, ``scripts``, " -"``include``, ``purelib``, ``platlib``)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:196 -msgid "" -"Python scripts must appear in ``scripts`` and begin with exactly ``b'#!" -"python'`` in order to enjoy script wrapper generation and ``#!python`` " -"rewriting at install time. They may have any or no extension." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:200 -msgid "" -"``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or " -"greater format metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:202 -msgid "" -"``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive " -"itself in the same basic key: value format::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:212 -msgid "``Wheel-Version`` is the version number of the Wheel specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:213 -msgid "" -"``Generator`` is the name and optionally the version of the software that " -"produced the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:215 -msgid "" -"``Root-Is-Purelib`` is true if the top level directory of the archive should " -"be installed into purelib; otherwise the root should be installed into " -"platlib." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:218 -msgid "" -"``Tag`` is the wheel's expanded compatibility tags; in the example the " -"filename would contain ``py2.py3-none-any``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:220 -msgid "" -"``Build`` is the build number and is omitted if there is no build number." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:221 -msgid "" -"A wheel installer should warn if Wheel-Version is greater than the version " -"it supports, and must fail if Wheel-Version has a greater major version than " -"the version it supports." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:224 -msgid "" -"Wheel, being an installation format that is intended to work across multiple " -"versions of Python, does not generally include .pyc files." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:226 -msgid "Wheel does not contain setup.py or setup.cfg." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:228 -msgid "" -"This version of the wheel specification is based on the distutils install " -"schemes and does not define how to install files to other locations. The " -"layout offers a superset of the functionality provided by the existing " -"wininst and egg binary formats." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:235 -#: ../source/specifications/recording-installed-packages.rst:35 -msgid "The .dist-info directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:237 -msgid "" -"Wheel .dist-info directories include at a minimum METADATA, WHEEL, and " -"RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:239 -msgid "" -"METADATA is the package metadata, the same format as PKG-INFO as found at " -"the root of sdists." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:241 -msgid "WHEEL is the wheel metadata specific to a build of the package." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:242 -msgid "" -"RECORD is a list of (almost) all the files in the wheel and their secure " -"hashes. Unlike PEP 376, every file except RECORD, which cannot contain a " -"hash of itself, must include its hash. The hash algorithm must be sha256 or " -"better; specifically, md5 and sha1 are not permitted, as signed wheel files " -"rely on the strong hashes in RECORD to validate the integrity of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:248 -msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:249 -msgid "" -"RECORD.jws is used for digital signatures. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:251 -msgid "" -"RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME " -"signatures to secure their wheel files. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:254 -msgid "" -"During extraction, wheel installers verify all the hashes in RECORD against " -"the file contents. Apart from RECORD and its signatures, installation will " -"fail if any file in the archive is not both mentioned and correctly hashed " -"in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:261 -msgid "The .data directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:263 -msgid "" -"Any file that is not normally installed inside site-packages goes into the ." -"data directory, named as the .dist-info directory but with the .data/ " -"extension::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:271 -msgid "" -"The .data directory contains subdirectories with the scripts, headers, " -"documentation and so forth from the distribution. During installation the " -"contents of these subdirectories are moved onto their destination paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:277 -msgid "Signed wheel files" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:279 -msgid "" -"Wheel files include an extended RECORD that enables digital signatures. PEP " -"376's RECORD is altered to include a secure hash " -"``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with " -"no trailing = characters) as the second column instead of an md5sum. All " -"possible entries are hashed, including any generated files such as .pyc " -"files, but not RECORD which cannot contain its own hash. For example::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:290 -msgid "" -"The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD " -"at all since they can only be added after RECORD is generated. Every other " -"file in the archive must have a correct hash in RECORD or the installation " -"will fail." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:295 -msgid "" -"If JSON web signatures are used, one or more JSON Web Signature JSON " -"Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to " -"RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD " -"as the signature's JSON payload::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:302 -msgid "(The hash value is the same format used in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:304 -msgid "" -"If RECORD.p7s is used, it must contain a detached S/MIME format signature of " -"RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:307 -msgid "" -"A wheel installer is not required to understand digital signatures but MUST " -"verify the hashes in RECORD against the extracted file contents. When the " -"installer checks file hashes against RECORD, a separate signature checker " -"only needs to establish that RECORD matches the signature." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:312 -msgid "See" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:314 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" -msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" - -#: ../source/specifications/binary-distribution-format.rst:315 -msgid "" -"http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" -msgstr "" -"http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" - -#: ../source/specifications/binary-distribution-format.rst:316 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" -msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" - -#: ../source/specifications/binary-distribution-format.rst:317 -msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" -msgstr "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" - -#: ../source/specifications/binary-distribution-format.rst:321 -msgid "Comparison to .egg" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:323 -msgid "" -"Wheel is an installation format; egg is importable. Wheel archives do not " -"need to include .pyc and are less tied to a specific Python version or " -"implementation. Wheel can install (pure Python) packages built with previous " -"versions of Python so you don't always have to wait for the packager to " -"catch up." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:328 -msgid "" -"Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible " -"with the new world of Python packaging and the new concepts it brings." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:331 -msgid "" -"Wheel has a richer file naming convention for today's multi-implementation " -"world. A single wheel archive can indicate its compatibility with a number " -"of Python language versions and implementations, ABIs, and system " -"architectures. Historically the ABI has been specific to a CPython release, " -"wheel is ready for the stable ABI." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:337 -msgid "" -"Wheel is lossless. The first wheel implementation bdist_wheel always " -"generates egg-info, and then converts it to a .whl. It is also possible to " -"convert existing eggs and bdist_wininst distributions." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:341 -msgid "" -"Wheel is versioned. Every wheel file contains the version of the wheel " -"specification and the implementation that packaged it. Hopefully the next " -"migration can simply be to Wheel 2.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:344 -msgid "Wheel is a reference to the other Python." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:348 -msgid "FAQ" -msgstr "ЧаПи" - -#: ../source/specifications/binary-distribution-format.rst:352 -msgid "Wheel defines a .data directory. Should I put all my data there?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:354 -msgid "" -"This specification does not have an opinion on how you should organize your " -"code. The .data directory is just a place for any files that are not " -"normally installed inside ``site-packages`` or on the PYTHONPATH. In other " -"words, you may continue to use ``pkgutil.get_data(package, resource)`` even " -"though *those* files will usually not be distributed in *wheel's* ``.data`` " -"directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:363 -msgid "Why does wheel include attached signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:365 -msgid "" -"Attached signatures are more convenient than detached signatures because " -"they travel with the archive. Since only the individual files are signed, " -"the archive can be recompressed without invalidating the signature or " -"individual files can be verified without having to download the whole " -"archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:373 -msgid "Why does wheel allow JWS signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:375 -msgid "" -"The JOSE specifications of which JWS is a part are designed to be easy to " -"implement, a feature that is also one of wheel's primary design goals. JWS " -"yields a useful, concise pure-Python implementation." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:381 -msgid "Why does wheel also allow S/MIME signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:383 -msgid "" -"S/MIME signatures are allowed for users who need or want to use existing " -"public key infrastructure with wheel." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:386 -msgid "" -"Signed packages are only a basic building block in a secure package update " -"system. Wheel only provides the building block." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:391 -msgid "What's the deal with \"purelib\" vs. \"platlib\"?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:393 -msgid "" -"Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is " -"significant on some platforms. For example, Fedora installs pure Python " -"packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent " -"packages to '/usr/lib64/pythonX.Y/site-packages'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:398 -msgid "" -"A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-" -"{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: " -"true\" with those same files in the root, and it is legal to have files in " -"both the \"purelib\" and \"platlib\" categories." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:403 -msgid "" -"In practice a wheel should have only one of \"purelib\" or \"platlib\" " -"depending on whether it is pure Python or not and those files should be at " -"the root with the appropriate setting given for \"Root-is-purelib\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:409 -msgid "Is it possible to import Python code directly from a wheel file?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:411 -msgid "" -"Technically, due to the combination of supporting installation via simple " -"extraction and using an archive format that is compatible with " -"``zipimport``, a subset of wheel files *do* support being placed directly on " -"``sys.path``. However, while this behaviour is a natural consequence of the " -"format design, actually relying on it is generally discouraged." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:417 -msgid "" -"Firstly, wheel *is* designed primarily as a distribution format, so skipping " -"the installation step also means deliberately avoiding any reliance on " -"features that assume full installation (such as being able to use standard " -"tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in " -"a way that can be properly tracked for auditing and security update " -"purposes, or integrating fully with the standard build machinery for C " -"extensions by publishing header files in the appropriate place)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:426 -msgid "" -"Secondly, while some Python software is written to support running directly " -"from a zip archive, it is still common for code to be written assuming it " -"has been fully installed. When that assumption is broken by trying to run " -"the software from a zip archive, the failures can often be obscure and hard " -"to diagnose (especially when they occur in third party libraries). The two " -"most common sources of problems with this are the fact that importing C " -"extensions from a zip archive is *not* supported by CPython (since doing so " -"is not supported directly by the dynamic loading machinery on any platform) " -"and that when running from a zip archive the ``__file__`` attribute no " -"longer refers to an ordinary filesystem path, but to a combination path that " -"includes both the location of the zip archive on the filesystem and the " -"relative path to the module inside the archive. Even when software correctly " -"uses the abstract resource APIs internally, interfacing with external " -"components may still require the availability of an actual on-disk file." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:443 -msgid "" -"Like metaclasses, monkeypatching and metapath importers, if you're not " -"already sure you need to take advantage of this feature, you almost " -"certainly don't need it. If you *do* decide to use it anyway, be aware that " -"many projects will require a failure to be reproduced with a fully installed " -"package before accepting it as a genuine bug." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:450 -msgid "Changes" -msgstr "Зміни" - -#: ../source/specifications/binary-distribution-format.rst:452 -msgid "Since :pep:`427`, this specification has changed as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:454 -msgid "" -"The rules on escaping in wheel filenames were revised, to bring them into " -"line with what popular tools actually do (February 2021)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:461 -msgid "" -"PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-" -"February/124103.html)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:466 -msgid "Appendix" -msgstr "Додаток" - -#: ../source/specifications/binary-distribution-format.rst:468 -msgid "Example urlsafe-base64-nopad implementation::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:482 -msgid "Copyright" -msgstr "Авторське право" - -#: ../source/specifications/binary-distribution-format.rst:484 -msgid "This document has been placed into the public domain." -msgstr "Цей документ передано у суспільне надбання." - -#: ../source/specifications/core-metadata.rst:5 -msgid "Core metadata specifications" -msgstr "" - -#: ../source/specifications/core-metadata.rst:7 -msgid "" -"Fields defined in the following specification should be considered valid, " -"complete and not subject to change. The required fields are:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:10 -msgid "``Metadata-Version``" -msgstr "``Metadata-Version``" - -#: ../source/specifications/core-metadata.rst:11 -msgid "``Name``" -msgstr "``Name``" - -#: ../source/specifications/core-metadata.rst:12 -msgid "``Version``" -msgstr "``Version``" - -#: ../source/specifications/core-metadata.rst:14 -msgid "All the other fields are optional." -msgstr "Усі інші поля необов'язкові." - -#: ../source/specifications/core-metadata.rst:16 -msgid "" -"The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats " -"have been revised several times, and exactly which email RFC applies to " -"packaging metadata is not specified. In the absence of a precise definition, " -"the practical standard is set by what the standard library :mod:`python:" -"email.parser` module can parse using the :data:`~.python:email.policy." -"compat32` policy." -msgstr "" - -#: ../source/specifications/core-metadata.rst:25 -msgid "" -"Although :pep:`566` defined a way to transform metadata into a JSON-" -"compatible dictionary, this is not yet used as a standard interchange " -"format. The need for tools to work with years worth of existing packages " -"makes it difficult to shift to a new format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:30 -msgid "" -"*Interpreting old metadata:* In :pep:`566`, the version specifier field " -"format specification was relaxed to accept the syntax used by popular " -"publishing tools (namely to remove the requirement that version specifiers " -"must be surrounded by parentheses). Metadata consumers may want to use the " -"more relaxed formatting rules even for metadata files that are nominally " -"less than version 2.1." -msgstr "" - -#: ../source/specifications/core-metadata.rst:41 -msgid "Metadata-Version" -msgstr "" - -#: ../source/specifications/core-metadata.rst:45 -msgid "" -"Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", " -"\"2.1\" and \"2.2\"." -msgstr "" - -#: ../source/specifications/core-metadata.rst:48 -msgid "" -"Automated tools consuming metadata SHOULD warn if ``metadata_version`` is " -"greater than the highest version they support, and MUST fail if " -"``metadata_version`` has a greater major version than the highest version " -"they support (as described in :pep:`440`, the major version is the value " -"before the first dot)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:54 -msgid "" -"For broader compatibility, build tools MAY choose to produce distribution " -"metadata using the lowest metadata version that includes all of the needed " -"fields." -msgstr "" - -#: ../source/specifications/core-metadata.rst:58 -#: ../source/specifications/core-metadata.rst:80 -#: ../source/specifications/core-metadata.rst:95 -#: ../source/specifications/core-metadata.rst:155 -#: ../source/specifications/core-metadata.rst:170 -#: ../source/specifications/core-metadata.rst:208 -#: ../source/specifications/core-metadata.rst:283 -#: ../source/specifications/core-metadata.rst:287 -#: ../source/specifications/core-metadata.rst:291 -#: ../source/specifications/core-metadata.rst:295 -#: ../source/specifications/core-metadata.rst:327 -#: ../source/specifications/core-metadata.rst:347 -#: ../source/specifications/core-metadata.rst:373 -#: ../source/specifications/core-metadata.rst:391 -#: ../source/specifications/core-metadata.rst:416 -#: ../source/specifications/core-metadata.rst:438 -#: ../source/specifications/core-metadata.rst:600 -#: ../source/specifications/core-metadata.rst:620 -#: ../source/specifications/core-metadata.rst:630 -msgid "Example::" -msgstr "Приклад::" - -#: ../source/specifications/core-metadata.rst:66 -msgid "Name" -msgstr "Name" - -#: ../source/specifications/core-metadata.rst:69 -msgid "Added additional restrictions on format from :pep:`508`" -msgstr "" - -#: ../source/specifications/core-metadata.rst:72 -msgid "" -"The name of the distribution. The name field is the primary identifier for a " -"distribution. A valid name consists only of ASCII letters and numbers, " -"period, underscore and hyphen. It must start and end with a letter or " -"number. Distribution names are limited to those which match the following " -"regex (run with ``re.IGNORECASE``)::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:88 -msgid "Version" -msgstr "Version" - -#: ../source/specifications/core-metadata.rst:92 -msgid "" -"A string containing the distribution's version number. This field must be " -"in the format specified in :pep:`440`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:101 -msgid "Dynamic (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:105 -msgid "" -"A string containing the name of another core metadata field. The field names " -"``Name`` and ``Version`` may not be specified in this field." -msgstr "" - -#: ../source/specifications/core-metadata.rst:108 -msgid "" -"When found in the metadata of a source distribution, the following rules " -"apply:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:111 -msgid "" -"If a field is *not* marked as ``Dynamic``, then the value of the field in " -"any wheel built from the sdist MUST match the value in the sdist. If the " -"field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT " -"be present in the wheel." -msgstr "" - -#: ../source/specifications/core-metadata.rst:115 -msgid "" -"If a field is marked as ``Dynamic``, it may contain any valid value in a " -"wheel built from the sdist (including not being present at all)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:118 -msgid "" -"If the sdist metadata version is older than version 2.2, then all fields " -"should be treated as if they were specified with ``Dynamic`` (i.e. there are " -"no special restrictions on the metadata of wheels built from the sdist)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:122 -msgid "" -"In any context other than a source distribution, ``Dynamic`` is for " -"information only, and indicates that the field value was calculated at wheel " -"build time, and may not be the same as the value in the sdist or in other " -"wheels for the project." -msgstr "" - -#: ../source/specifications/core-metadata.rst:127 -msgid "" -"Full details of the semantics of ``Dynamic`` are described in :pep:`643`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:131 -msgid "Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:135 -msgid "" -"A Platform specification describing an operating system supported by the " -"distribution which is not listed in the \"Operating System\" Trove " -"classifiers. See \"Classifier\" below." -msgstr "" - -#: ../source/specifications/core-metadata.rst:146 -msgid "Supported-Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:150 -msgid "" -"Binary distributions containing a PKG-INFO file will use the Supported-" -"Platform field in their metadata to specify the OS and CPU for which the " -"binary distribution was compiled. The semantics of the Supported-Platform " -"field are not specified in this PEP." -msgstr "" - -#: ../source/specifications/core-metadata.rst:164 -msgid "Summary" -msgstr "Підсумок" - -#: ../source/specifications/core-metadata.rst:168 -msgid "A one-line summary of what the distribution does." -msgstr "" - -#: ../source/specifications/core-metadata.rst:188 -msgid "This field may be specified in the message body instead." -msgstr "" - -#: ../source/specifications/core-metadata.rst:191 -msgid "" -"A longer description of the distribution that can run to several " -"paragraphs. Software that deals with metadata should not assume any maximum " -"size for this field, though people shouldn't include their instruction " -"manual as the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:196 -msgid "" -"The contents of this field can be written using reStructuredText markup " -"[1]_. For programs that work with the metadata, supporting markup is " -"optional; programs can also display the contents of the field as-is. This " -"means that authors should be conservative in the markup they use." -msgstr "" - -#: ../source/specifications/core-metadata.rst:202 -msgid "" -"To support empty lines and lines with indentation with respect to the RFC " -"822 format, any CRLF character has to be suffixed by 7 spaces followed by a " -"pipe (\"|\") char. As a result, the Description field is encoded into a " -"folded field that can be interpreted by RFC822 parser [2]_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:219 -msgid "" -"This encoding implies that any occurrences of a CRLF followed by 7 spaces " -"and a pipe char have to be replaced by a single CRLF when the field is " -"unfolded using a RFC822 reader." -msgstr "" - -#: ../source/specifications/core-metadata.rst:223 -msgid "" -"Alternatively, the distribution's description may instead be provided in the " -"message body (i.e., after a completely blank line following the headers, " -"with no indentation or other special formatting necessary)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:232 -msgid "Description-Content-Type" -msgstr "" - -#: ../source/specifications/core-metadata.rst:236 -msgid "" -"A string stating the markup syntax (if any) used in the distribution's " -"description, so that tools can intelligently render the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:239 -msgid "" -"Historically, PyPI supported descriptions in plain text and " -"`reStructuredText (reST) `_, and could render reST into HTML. However, it is " -"common for distribution authors to write the description in `Markdown " -"`_ (`RFC 7763 `_) as many code hosting sites render Markdown " -"READMEs, and authors would reuse the file for the description. PyPI didn't " -"recognize the format and so could not render the description correctly. This " -"resulted in many packages on PyPI with poorly-rendered descriptions when " -"Markdown is left as plain text, or worse, was attempted to be rendered as " -"reST. This field allows the distribution author to specify the format of " -"their description, opening up the possibility for PyPI and other tools to be " -"able to render Markdown and other formats." -msgstr "" - -#: ../source/specifications/core-metadata.rst:253 -msgid "" -"The format of this field is the same as the ``Content-Type`` header in HTTP " -"(i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then " -"it can optionally have a number of parameters:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:259 -msgid "Format::" -msgstr "Формат::" - -#: ../source/specifications/core-metadata.rst:263 -msgid "The ``type/subtype`` part has only a few legal values:" -msgstr "Частина ``type/subtype`` може містити лише кілька прийнятних значень:" - -#: ../source/specifications/core-metadata.rst:265 -msgid "``text/plain``" -msgstr "``text/plain``" - -#: ../source/specifications/core-metadata.rst:266 -msgid "``text/x-rst``" -msgstr "``text/x-rst``" - -#: ../source/specifications/core-metadata.rst:267 -msgid "``text/markdown``" -msgstr "``text/markdown``" - -#: ../source/specifications/core-metadata.rst:269 -msgid "" -"The ``charset`` parameter can be used to specify the character encoding of " -"the description. The only legal value is ``UTF-8``. If omitted, it is " -"assumed to be ``UTF-8``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:273 -msgid "" -"Other parameters might be specific to the chosen subtype. For example, for " -"the ``markdown`` subtype, there is an optional ``variant`` parameter that " -"allows specifying the variant of Markdown in use (defaults to ``GFM`` if not " -"specified). Currently, two variants are recognized:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:278 -msgid "" -"``GFM`` for `Github-flavored Markdown `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:280 -msgid "" -"``CommonMark`` for `CommonMark `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:299 -msgid "" -"If a ``Description-Content-Type`` is not specified, then applications should " -"attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to " -"``text/plain`` if it is not valid rst." -msgstr "" - -#: ../source/specifications/core-metadata.rst:303 -msgid "" -"If a ``Description-Content-Type`` is an unrecognized value, then the assumed " -"content type is ``text/plain`` (Although PyPI will probably reject anything " -"with an unrecognized value)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:307 -msgid "" -"If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is " -"not specified or is set to an unrecognized value, then the assumed " -"``variant`` is ``GFM``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:311 -msgid "" -"So for the last example above, the ``charset`` defaults to ``UTF-8`` and the " -"``variant`` defaults to ``GFM`` and thus it is equivalent to the example " -"before it." -msgstr "" - -#: ../source/specifications/core-metadata.rst:320 -msgid "Keywords" -msgstr "" - -#: ../source/specifications/core-metadata.rst:324 -msgid "" -"A list of additional keywords, separated by commas, to be used to assist " -"searching for the distribution in a larger catalog." -msgstr "" - -#: ../source/specifications/core-metadata.rst:333 -msgid "" -"The specification previously showed keywords separated by spaces, but " -"distutils and setuptools implemented it with commas. These tools have been " -"very widely used for many years, so it was easier to update the " -"specification to match the de facto standard." -msgstr "" - -#: ../source/specifications/core-metadata.rst:341 -msgid "Home-page" -msgstr "" - -#: ../source/specifications/core-metadata.rst:345 -msgid "A string containing the URL for the distribution's home page." -msgstr "" - -#: ../source/specifications/core-metadata.rst:353 -msgid "Download-URL" -msgstr "" - -#: ../source/specifications/core-metadata.rst:357 -msgid "" -"A string containing the URL from which this version of the distribution can " -"be downloaded. (This means that the URL can't be something like \".../" -"BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:366 -msgid "Author" -msgstr "Author" - -#: ../source/specifications/core-metadata.rst:370 -msgid "" -"A string containing the author's name at a minimum; additional contact " -"information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:383 -msgid "Author-email" -msgstr "Author-email" - -#: ../source/specifications/core-metadata.rst:387 -msgid "" -"A string containing the author's e-mail address. It can contain a name and " -"e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:395 -#: ../source/specifications/core-metadata.rst:442 -msgid "" -"Per RFC-822, this field may contain multiple comma-separated e-mail " -"addresses::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:405 -msgid "Maintainer" -msgstr "Доглядач" - -#: ../source/specifications/core-metadata.rst:409 -msgid "" -"A string containing the maintainer's name at a minimum; additional contact " -"information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:412 -msgid "" -"Note that this field is intended for use when a project is being maintained " -"by someone other than the original author: it should be omitted if it is " -"identical to ``Author``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:426 -msgid "Maintainer-email" -msgstr "Maintainer-email" - -#: ../source/specifications/core-metadata.rst:430 -msgid "" -"A string containing the maintainer's e-mail address. It can contain a name " -"and e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:434 -msgid "" -"Note that this field is intended for use when a project is being maintained " -"by someone other than the original author: it should be omitted if it is " -"identical to ``Author-email``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:452 -msgid "License" -msgstr "License" - -#: ../source/specifications/core-metadata.rst:456 -msgid "" -"Text indicating the license covering the distribution where the license is " -"not a selection from the \"License\" Trove classifiers. See :ref:`" -"\"Classifier\" ` below. This field may also be used to " -"specify a particular version of a license which is named via the " -"``Classifier`` field, or to indicate a variation or exception to such a " -"license." -msgstr "" - -#: ../source/specifications/core-metadata.rst:476 -msgid "Classifier (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:480 -msgid "" -"Each entry is a string giving a single classification value for the " -"distribution. Classifiers are described in :pep:`301`, and the Python " -"Package Index publishes a dynamic list of `currently defined classifiers " -"`__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:485 -#: ../source/specifications/core-metadata.rst:574 -#: ../source/specifications/core-metadata.rst:691 -#: ../source/specifications/core-metadata.rst:715 -msgid "This field may be followed by an environment marker after a semicolon." -msgstr "" - -#: ../source/specifications/core-metadata.rst:496 -msgid "Requires-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:499 -#: ../source/specifications/core-metadata.rst:561 -#: ../source/specifications/core-metadata.rst:663 -#: ../source/specifications/core-metadata.rst:704 -msgid "" -"The field format specification was relaxed to accept the syntax used by " -"popular publishing tools." -msgstr "" - -#: ../source/specifications/core-metadata.rst:503 -msgid "" -"Each entry contains a string naming some other distutils project required by " -"this distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:506 -msgid "The format of a requirement string contains from one to four parts:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:508 -msgid "" -"A project name, in the same format as the ``Name:`` field. The only " -"mandatory part." -msgstr "" - -#: ../source/specifications/core-metadata.rst:510 -msgid "" -"A comma-separated list of 'extra' names. These are defined by the required " -"project, referring to specific features which may need extra dependencies." -msgstr "" - -#: ../source/specifications/core-metadata.rst:513 -msgid "" -"A version specifier. Tools parsing the format should accept optional " -"parentheses around this, but tools generating it should not use parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:516 -msgid "" -"An environment marker after a semicolon. This means that the requirement is " -"only needed in the specified conditions." -msgstr "" - -#: ../source/specifications/core-metadata.rst:519 -msgid "See :pep:`508` for full details of the allowed format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:521 -msgid "" -"The project names should correspond to names as found on the `Python Package " -"Index`_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:524 -msgid "" -"Version specifiers must follow the rules described in :doc:`version-" -"specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:538 -msgid "Requires-Python" -msgstr "" - -#: ../source/specifications/core-metadata.rst:542 -msgid "" -"This field specifies the Python version(s) that the distribution is " -"guaranteed to be compatible with. Installation tools may look at this when " -"picking which version of a project to install." -msgstr "" - -#: ../source/specifications/core-metadata.rst:546 -msgid "The value must be in the format specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:548 -msgid "This field cannot be followed by an environment marker." -msgstr "" - -#: ../source/specifications/core-metadata.rst:558 -msgid "Requires-External (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:565 -msgid "" -"Each entry contains a string describing some dependency in the system that " -"the distribution is to be used. This field is intended to serve as a hint " -"to downstream project maintainers, and has no semantics which are meaningful " -"to the ``distutils`` distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:570 -msgid "" -"The format of a requirement string is a name of an external dependency, " -"optionally followed by a version declaration within parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:576 -msgid "" -"Because they refer to non-Python software releases, version numbers for this " -"field are **not** required to conform to the format specified in :pep:" -"`440`: they should correspond to the version scheme used by the external " -"dependency." -msgstr "" - -#: ../source/specifications/core-metadata.rst:581 -msgid "Notice that there is no particular rule on the strings to be used." -msgstr "" - -#: ../source/specifications/core-metadata.rst:593 -msgid "Project-URL (multiple-use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:597 -msgid "" -"A string containing a browsable URL for the project and a label for it, " -"separated by a comma." -msgstr "" - -#: ../source/specifications/core-metadata.rst:604 -msgid "The label is free text limited to 32 characters." -msgstr "" - -#: ../source/specifications/core-metadata.rst:612 -msgid "Provides-Extra (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:616 -msgid "" -"A string containing the name of an optional feature. Must be a valid Python " -"identifier. May be used to make a dependency conditional on whether the " -"optional feature has been requested." -msgstr "" - -#: ../source/specifications/core-metadata.rst:625 -msgid "" -"A second distribution requires an optional dependency by placing it inside " -"square brackets, and can request multiple features by separating them with a " -"comma (,). The requirements are evaluated for each requested feature and " -"added to the set of requirements for the distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:635 -msgid "" -"Two feature names ``test`` and ``doc`` are reserved to mark dependencies " -"that are needed for running automated tests and generating documentation, " -"respectively." -msgstr "" - -#: ../source/specifications/core-metadata.rst:639 -msgid "" -"It is legal to specify ``Provides-Extra:`` without referencing it in any " -"``Requires-Dist:``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:644 -msgid "Rarely Used Fields" -msgstr "" - -#: ../source/specifications/core-metadata.rst:646 -msgid "" -"The fields in this section are currently rarely used, as their design was " -"inspired by comparable mechanisms in Linux package management systems, and " -"it isn't at all clear how tools should interpret them in the context of an " -"open index server such as `PyPI `__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:651 -msgid "" -"As a result, popular installation tools ignore them completely, which in " -"turn means there is little incentive for package publishers to set them " -"appropriately. However, they're retained in the metadata specification, as " -"they're still potentially useful for informational purposes, and can also be " -"used for their originally intended purpose in combination with a curated " -"package repository." -msgstr "" - -#: ../source/specifications/core-metadata.rst:660 -msgid "Provides-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:667 -msgid "" -"Each entry contains a string naming a Distutils project which is contained " -"within this distribution. This field *must* include the project identified " -"in the ``Name`` field, followed by the version : Name (Version)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:672 -msgid "" -"A distribution may provide additional names, e.g. to indicate that multiple " -"projects have been bundled together. For instance, source distributions of " -"the ``ZODB`` project have historically included the ``transaction`` project, " -"which is now available as a separate distribution. Installing such a source " -"distribution satisfies requirements for both ``ZODB`` and ``transaction``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:679 -msgid "" -"A distribution may also provide a \"virtual\" project name, which does not " -"correspond to any separately-distributed project: such a name might be used " -"to indicate an abstract capability which could be supplied by one of " -"multiple projects. E.g., multiple projects might supply RDBMS bindings for " -"use by a given ORM: each project might declare that it provides ``ORM-" -"bindings``, allowing other projects to depend only on having at most one of " -"them installed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:687 -msgid "" -"A version declaration may be supplied and must follow the rules described " -"in :doc:`version-specifiers`. The distribution's version number will be " -"implied if none is specified." -msgstr "" - -#: ../source/specifications/core-metadata.rst:701 -msgid "Obsoletes-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:708 -msgid "" -"Each entry contains a string describing a distutils project's distribution " -"which this distribution renders obsolete, meaning that the two projects " -"should not be installed at the same time." -msgstr "" - -#: ../source/specifications/core-metadata.rst:712 -msgid "" -"Version declarations can be supplied. Version numbers must be in the format " -"specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:717 -msgid "" -"The most common use of this field will be in case a project name changes, e." -"g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install " -"Torqued Python, the Gorgon distribution should be removed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:730 -msgid "reStructuredText markup: http://docutils.sourceforge.net/" -msgstr "" - -#: ../source/specifications/core-metadata.rst:735 -msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:6 -msgid "Declaring build system dependencies" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:8 -msgid "" -"`pyproject.toml` is a build system independent file format defined in :pep:" -"`518` that projects may provide in order to declare any Python level " -"dependencies that must be installed in order to run the project's build " -"system successfully." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:5 -msgid "Declaring project metadata" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:7 -msgid "" -":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to " -"consume. It defines the following specification as the canonical source for " -"the format used." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:12 -msgid "" -"There are two kinds of metadata: *static* and *dynamic*. Static metadata is " -"specified in the ``pyproject.toml`` file directly and cannot be specified or " -"changed by a tool. Dynamic metadata is listed via the ``dynamic`` field " -"(defined later in this specification) and represents metadata that a tool " -"will later provide." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:18 -msgid "" -"The fields defined in this specification MUST be in a table named " -"``[project]`` in ``pyproject.toml``. No tools may add fields to this table " -"which are not defined by this specification. For tools wishing to store " -"their own settings in ``pyproject.toml``, they may use the ``[tool]`` table " -"as defined in the :ref:`build dependency declaration specification " -"`. The lack of a ``[project]`` table " -"implicitly means the build back-end will dynamically provide all fields." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:27 -msgid "The only fields required to be statically defined are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:29 -#: ../source/specifications/declaring-project-metadata.rst:41 -msgid "``name``" -msgstr "``name``" - -#: ../source/specifications/declaring-project-metadata.rst:31 -msgid "" -"The fields which are required but may be specified *either* statically or " -"listed as dynamic are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:34 -#: ../source/specifications/declaring-project-metadata.rst:54 -msgid "``version``" -msgstr "``version``" - -#: ../source/specifications/declaring-project-metadata.rst:36 -msgid "" -"All other fields are considered optional and my be specified statically, " -"listed as dynamic, or left unspecified." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:43 -#: ../source/specifications/declaring-project-metadata.rst:56 -#: ../source/specifications/declaring-project-metadata.rst:68 -#: ../source/specifications/declaring-project-metadata.rst:117 -msgid "TOML_ type: string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:44 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Name `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:47 -msgid "The name of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:49 -msgid "" -"Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it " -"is read for internal consistency." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:57 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Version " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:60 -msgid "The version of the project as supported by :pep:`440`." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:62 -msgid "Users SHOULD prefer to specify already-normalized versions." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:66 -msgid "``description``" -msgstr "``description``" - -#: ../source/specifications/declaring-project-metadata.rst:69 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Summary " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:72 -msgid "The summary description of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:76 -msgid "``readme``" -msgstr "``readme``" - -#: ../source/specifications/declaring-project-metadata.rst:78 -msgid "TOML_ type: string or table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:79 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Description " -"` and :ref:`Description-Content-Type `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:83 -msgid "The full description of the project (i.e. the README)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:85 -msgid "" -"The field accepts either a string or a table. If it is a string then it is a " -"path relative to ``pyproject.toml`` to a text file containing the full " -"description. Tools MUST assume the file's encoding is UTF-8. If the file " -"path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the " -"content-type is ``text/markdown``. If the file path ends in a case-" -"insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-" -"rst``. If a tool recognizes more extensions than this PEP, they MAY infer " -"the content-type for the user without specifying this field as ``dynamic``. " -"For all unrecognized suffixes when a content-type is not provided, tools " -"MUST raise an error." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:96 -msgid "" -"The ``readme`` field may also take a table. The ``file`` key has a string " -"value representing a path relative to ``pyproject.toml`` to a file " -"containing the full description. The ``text`` key has a string value which " -"is the full description. These keys are mutually-exclusive, thus tools MUST " -"raise an error if the metadata specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:103 -msgid "" -"A table specified in the ``readme`` field also has a ``content-type`` field " -"which takes a string specifying the content-type of the full description. A " -"tool MUST raise an error if the metadata does not specify this field in the " -"table. If the metadata does not specify the ``charset`` parameter, then it " -"is assumed to be UTF-8. Tools MAY support other encodings if they choose to. " -"Tools MAY support alternative content-types which they can transform to a " -"content-type as supported by the :ref:`core metadata `. " -"Otherwise tools MUST raise an error for unsupported content-types." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:115 -msgid "``requires-python``" -msgstr "``requires-python``" - -#: ../source/specifications/declaring-project-metadata.rst:118 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Requires-" -"Python `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:121 -msgid "The Python version requirements of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:125 -msgid "``license``" -msgstr "``license``" - -#: ../source/specifications/declaring-project-metadata.rst:127 -msgid "TOML_ type: table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:128 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`License " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:131 -msgid "" -"The table may have one of two keys. The ``file`` key has a string value that " -"is a file path relative to ``pyproject.toml`` to the file which contains the " -"license for the project. Tools MUST assume the file's encoding is UTF-8. The " -"``text`` key has a string value which is the license of the project. These " -"keys are mutually exclusive, so a tool MUST raise an error if the metadata " -"specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:140 -msgid "``authors``/``maintainers``" -msgstr "``authors``/``maintainers``" - -#: ../source/specifications/declaring-project-metadata.rst:142 -msgid "TOML_ type: Array of inline tables with string keys and values" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:143 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:" -"`Maintainer `, and :ref:`Maintainer-email `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:149 -msgid "" -"The people or organizations considered to be the \"authors\" of the project. " -"The exact meaning is open to interpretation — it may list the original or " -"primary authors, current maintainers, or owners of the package." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:154 -msgid "" -"The \"maintainers\" field is similar to \"authors\" in that its exact " -"meaning is open to interpretation." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:157 -msgid "" -"These fields accept an array of tables with 2 keys: ``name`` and ``email``. " -"Both values must be strings. The ``name`` value MUST be a valid email name " -"(i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not " -"contain commas. The ``email`` value MUST be a valid email address. Both keys " -"are optional." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:163 -msgid "" -"Using the data to fill in :ref:`core metadata ` is as follows:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:166 -msgid "" -"If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:169 -msgid "" -"If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:173 -msgid "" -"If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-" -"email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:177 -msgid "Multiple values should be separated by commas." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:181 -msgid "``keywords``" -msgstr "``keywords``" - -#: ../source/specifications/declaring-project-metadata.rst:183 -#: ../source/specifications/declaring-project-metadata.rst:193 -msgid "TOML_ type: array of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:184 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Keywords " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:187 -msgid "The keywords for the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:191 -msgid "``classifiers``" -msgstr "``classifiers``" - -#: ../source/specifications/declaring-project-metadata.rst:194 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Classifier " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:197 -msgid "Trove classifiers which apply to the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:201 -msgid "``urls``" -msgstr "``urls``" - -#: ../source/specifications/declaring-project-metadata.rst:203 -msgid "TOML_ type: table with keys and values of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:204 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Project-URL " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:207 -msgid "" -"A table of URLs where the key is the URL label and the value is the URL " -"itself." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:212 -msgid "Entry points" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:214 -msgid "" -"TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and " -"``[project.entry-points]``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:216 -msgid ":ref:`Entry points specification `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:218 -msgid "" -"There are three tables related to entry points. The ``[project.scripts]`` " -"table corresponds to the ``console_scripts`` group in the :ref:`entry points " -"specification `. The key of the table is the name of the entry " -"point and the value is the object reference." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:224 -msgid "" -"The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group " -"in the :ref:`entry points specification `. Its format is the " -"same as ``[project.scripts]``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:228 -msgid "" -"The ``[project.entry-points]`` table is a collection of tables. Each sub-" -"table's name is an entry point group. The key and value semantics are the " -"same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but " -"instead keep the entry point groups to only one level deep." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:234 -msgid "" -"Build back-ends MUST raise an error if the metadata defines a ``[project." -"entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` " -"table, as they would be ambiguous in the face of ``[project.scripts]`` and " -"``[project.gui-scripts]``, respectively." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:242 -msgid "``dependencies``/``optional-dependencies``" -msgstr "``dependencies``/``optional-dependencies``" - -#: ../source/specifications/declaring-project-metadata.rst:244 -msgid "" -"TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with " -"values of arrays of :pep:`508` strings (``optional-dependencies``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:247 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Requires-" -"Dist ` and :ref:`Provides-Extra `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:251 -msgid "The (optional) dependencies of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:253 -msgid "" -"For ``dependencies``, it is a key whose value is an array of strings. Each " -"string represents a dependency of the project and MUST be formatted as a " -"valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist " -"` entry." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:258 -msgid "" -"For ``optional-dependencies``, it is a table where each key specifies an " -"extra and whose value is an array of strings. The strings of the arrays must " -"be valid :pep:`508` strings. The keys MUST be valid values for :ref:" -"`Provides-Extra `. Each value in the array " -"thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:269 -msgid "``dynamic``" -msgstr "``dynamic``" - -#: ../source/specifications/declaring-project-metadata.rst:271 -msgid "TOML_ type: array of string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:272 -msgid "" -"A corresponding :ref:`core metadata ` field does not exist" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:275 -msgid "" -"Specifies which fields listed by this PEP were intentionally unspecified so " -"another tool can/will provide such metadata dynamically. This clearly " -"delineates which metadata is purposefully unspecified and expected to stay " -"unspecified compared to being provided via tooling later on." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:281 -msgid "" -"A build back-end MUST honour statically-specified metadata (which means the " -"metadata did not list the field in ``dynamic``)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:283 -msgid "" -"A build back-end MUST raise an error if the metadata specifies ``name`` in " -"``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:285 -msgid "" -"If the :ref:`core metadata ` specification lists a field as " -"\"Required\", then the metadata MUST specify the field statically or list it " -"in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it " -"should not be possible for a required field to not be listed somehow in the " -"``[project]`` table)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:290 -msgid "" -"If the :ref:`core metadata ` specification lists a field as " -"\"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is " -"a build back-end will provide the data for the field later." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:294 -msgid "" -"Build back-ends MUST raise an error if the metadata specifies a field " -"statically as well as being listed in ``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:296 -msgid "" -"If the metadata does not list a field in ``dynamic``, then a build back-end " -"CANNOT fill in the requisite metadata on behalf of the user (i.e. " -"``dynamic`` is the only way to allow a tool to fill in metadata and the user " -"must opt into the filling in)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:300 -msgid "" -"Build back-ends MUST raise an error if the metadata specifies a field in " -"``dynamic`` but the build back-end was unable to determine the data for it " -"(omitting the data, if determined to be the accurate value, is acceptable)." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:6 -msgid "Dependency specifiers" -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:8 -msgid "" -"The dependency specifier format used to declare a dependency on another " -"component is defined in :pep:`508`." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:11 -msgid "" -"The environment markers section in this PEP supersedes the environment " -"markers section in :pep:`345`." -msgstr "" - -#: ../source/specifications/direct-url.rst:6 -msgid "Recording the Direct URL Origin of installed distributions" -msgstr "" - -#: ../source/specifications/direct-url.rst:8 -msgid "" -"This document specifies a :file:`direct_url.json` file in the :file:`*.dist-" -"info` directory of an installed distribution, to record the Direct URL " -"Origin of the distribution. The layout of this file was originally specified " -"in :pep:`610` and is formally documented here." -msgstr "" - -#: ../source/specifications/direct-url.rst:17 -msgid "Specification" -msgstr "Специфікація" - -#: ../source/specifications/direct-url.rst:19 -msgid "" -"The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` " -"directory by installers when installing a distribution from a requirement " -"specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/direct-url.rst:23 -#: ../source/specifications/recording-installed-packages.rst:206 -msgid "" -"This file MUST NOT be created when installing a distribution from an other " -"type of requirement (i.e. name plus version specifier)." -msgstr "" - -#: ../source/specifications/direct-url.rst:26 -msgid "" -"This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." -msgstr "" - -#: ../source/specifications/direct-url.rst:29 -msgid "" -"If present, it MUST contain at least two fields. The first one is ``url``, " -"with type ``string``. Depending on what ``url`` refers to, the second field " -"MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), " -"``archive_info`` (if ``url`` is a source archives or a wheel), or " -"``dir_info`` (if ``url`` is a local directory). These info fields have a " -"(possibly empty) subdictionary as value, with the possible keys defined " -"below." -msgstr "" - -#: ../source/specifications/direct-url.rst:36 -msgid "" -"``url`` MUST be stripped of any sensitive authentication information, for " -"security reasons." -msgstr "" - -#: ../source/specifications/direct-url.rst:39 -msgid "" -"The user:password section of the URL MAY however be composed of environment " -"variables, matching the following regular expression::" -msgstr "" - -#: ../source/specifications/direct-url.rst:45 -msgid "" -"Additionally, the user:password section of the URL MAY be a well-known, non " -"security sensitive string. A typical example is ``git`` in the case of an " -"URL such as ``ssh://git@gitlab.com/user/repo``." -msgstr "" - -#: ../source/specifications/direct-url.rst:49 -msgid "" -"When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be " -"present as a dictionary with the following keys:" -msgstr "" - -#: ../source/specifications/direct-url.rst:52 -msgid "" -"A ``vcs`` key (type ``string``) MUST be present, containing the name of the " -"VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be " -"registered by writing a PEP to amend this specification. The ``url`` value " -"MUST be compatible with the corresponding VCS, so an installer can hand it " -"off without transformation to a checkout/download command of the VCS." -msgstr "" - -#: ../source/specifications/direct-url.rst:58 -msgid "" -"A ``requested_revision`` key (type ``string``) MAY be present naming a " -"branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to " -"install." -msgstr "" - -#: ../source/specifications/direct-url.rst:61 -msgid "" -"A ``commit_id`` key (type ``string``) MUST be present, containing the exact " -"commit/revision number that was installed. If the VCS supports commit-hash " -"based revision identifiers, such commit-hash MUST be used as ``commit_id`` " -"in order to reference the immutable version of the source code that was " -"installed." -msgstr "" - -#: ../source/specifications/direct-url.rst:68 -msgid "" -"When ``url`` refers to a source archive or a wheel, the ``archive_info`` key " -"MUST be present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:71 -msgid "" -"A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are " -"unconditionally provided by the latest version of the standard library's " -"``hashlib`` module be used for source archive hashes. At time of writing, " -"that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and " -"'sha512'." -msgstr "" - -#: ../source/specifications/direct-url.rst:78 -msgid "" -"When ``url`` refers to a local directory, the ``dir_info`` key MUST be " -"present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:81 -msgid "" -"``editable`` (type: ``boolean``): ``true`` if the distribution was installed " -"in editable mode, ``false`` otherwise. If absent, default to ``false``." -msgstr "" - -#: ../source/specifications/direct-url.rst:84 -msgid "" -"When ``url`` refers to a local directory, it MUST have the ``file`` sheme " -"and be compliant with `RFC 8089 `_. In " -"particular, the path component must be absolute. Symbolic links SHOULD be " -"preserved when making relative paths absolute." -msgstr "" - -#: ../source/specifications/direct-url.rst:91 -msgid "" -"When the requested URL has the file:// scheme and points to a local " -"directory that happens to contain a VCS checkout, installers MUST NOT " -"attempt to infer any VCS information and therefore MUST NOT output any VCS " -"related information (such as ``vcs_info``) in :file:`direct_url.json`." -msgstr "" - -#: ../source/specifications/direct-url.rst:96 -msgid "" -"A top-level ``subdirectory`` field MAY be present containing a directory " -"path, relative to the root of the VCS repository, source archive or local " -"directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." -msgstr "" - -#: ../source/specifications/direct-url.rst:102 -msgid "" -"As a general rule, installers should as much as possible preserve the " -"information that was provided in the requested URL when generating :file:" -"`direct_url.json`. For example user:password environment variables should be " -"preserved and ``requested_revision`` should reflect the revision that was " -"provided in the requested URL as faithfully as possible. This information is " -"however *enriched* with more precise data, such as ``commit_id``." -msgstr "" - -#: ../source/specifications/direct-url.rst:110 -msgid "Registered VCS" -msgstr "" - -#: ../source/specifications/direct-url.rst:112 -msgid "" -"This section lists the registered VCS's; expanded, VCS-specific information " -"on how to use the ``vcs``, ``requested_revision``, and other fields of " -"``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY " -"support other VCS's although it is RECOMMENDED to register them by writing a " -"PEP to amend this specification. The ``vcs`` field SHOULD be the command " -"name (lowercased). Additional fields that would be necessary to support such " -"VCS SHOULD be prefixed with the VCS command name." -msgstr "" - -#: ../source/specifications/direct-url.rst:122 -msgid "Git" -msgstr "Git" - -#: ../source/specifications/direct-url.rst:124 -#: ../source/specifications/direct-url.rst:156 -#: ../source/specifications/direct-url.rst:179 -#: ../source/specifications/direct-url.rst:202 -msgid "Home page" -msgstr "Домашня сторінка" - -#: ../source/specifications/direct-url.rst:126 -msgid "https://git-scm.com/" -msgstr "https://git-scm.com/" - -#: ../source/specifications/direct-url.rst:128 -#: ../source/specifications/direct-url.rst:160 -#: ../source/specifications/direct-url.rst:183 -#: ../source/specifications/direct-url.rst:206 -msgid "vcs command" -msgstr "" - -#: ../source/specifications/direct-url.rst:130 -#: ../source/specifications/direct-url.rst:134 -msgid "git" -msgstr "git" - -#: ../source/specifications/direct-url.rst:132 -#: ../source/specifications/direct-url.rst:164 -#: ../source/specifications/direct-url.rst:187 -#: ../source/specifications/direct-url.rst:210 -msgid "``vcs`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:136 -#: ../source/specifications/direct-url.rst:168 -#: ../source/specifications/direct-url.rst:191 -#: ../source/specifications/direct-url.rst:214 -msgid "``requested_revision`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:138 -msgid "" -"A tag name, branch name, Git ref, commit hash, shortened commit hash, or " -"other commit-ish." -msgstr "" - -#: ../source/specifications/direct-url.rst:141 -#: ../source/specifications/direct-url.rst:172 -#: ../source/specifications/direct-url.rst:195 -#: ../source/specifications/direct-url.rst:219 -msgid "``commit_id`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:143 -msgid "A commit hash (40 hexadecimal characters sha1)." -msgstr "" - -#: ../source/specifications/direct-url.rst:147 -msgid "" -"Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to " -"determine if the ``requested_revision`` corresponds to a Git ref. In turn, a " -"ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning " -"with ``refs/remotes/origin/`` after cloning corresponds to a branch." -msgstr "" - -#: ../source/specifications/direct-url.rst:154 -msgid "Mercurial" -msgstr "Mercurial" - -#: ../source/specifications/direct-url.rst:158 -msgid "https://www.mercurial-scm.org/" -msgstr "https://www.mercurial-scm.org/" - -#: ../source/specifications/direct-url.rst:162 -#: ../source/specifications/direct-url.rst:166 -msgid "hg" -msgstr "hg" - -#: ../source/specifications/direct-url.rst:170 -msgid "A tag name, branch name, changeset ID, shortened changeset ID." -msgstr "" - -#: ../source/specifications/direct-url.rst:174 -msgid "A changeset ID (40 hexadecimal characters)." -msgstr "" - -#: ../source/specifications/direct-url.rst:177 -msgid "Bazaar" -msgstr "Bazaar" - -#: ../source/specifications/direct-url.rst:181 -msgid "https://bazaar.canonical.com/" -msgstr "https://bazaar.canonical.com/" - -#: ../source/specifications/direct-url.rst:185 -#: ../source/specifications/direct-url.rst:189 -msgid "bzr" -msgstr "bzr" - -#: ../source/specifications/direct-url.rst:193 -msgid "A tag name, branch name, revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:197 -msgid "A revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:200 -msgid "Subversion" -msgstr "Subversion" - -#: ../source/specifications/direct-url.rst:204 -msgid "https://subversion.apache.org/" -msgstr "https://subversion.apache.org/" - -#: ../source/specifications/direct-url.rst:208 -#: ../source/specifications/direct-url.rst:212 -msgid "svn" -msgstr "svn" - -#: ../source/specifications/direct-url.rst:216 -msgid "" -"``requested_revision`` must be compatible with ``svn checkout`` ``--" -"revision`` option. In Subversion, branch or tag is part of ``url``." -msgstr "" - -#: ../source/specifications/direct-url.rst:221 -msgid "" -"Since Subversion does not support globally unique identifiers, this field is " -"the Subversion revision number in the corresponding repository." -msgstr "" - -#: ../source/specifications/direct-url.rst:229 -msgid "Example direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:231 -msgid "Source archive:" -msgstr "" - -#: ../source/specifications/direct-url.rst:242 -msgid "Git URL with tag and commit-hash:" -msgstr "" - -#: ../source/specifications/direct-url.rst:255 -msgid "Local directory:" -msgstr "" - -#: ../source/specifications/direct-url.rst:264 -msgid "Local directory installed in editable mode:" -msgstr "" - -#: ../source/specifications/direct-url.rst:277 -msgid "Example pip commands and their effect on direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:279 -msgid "Commands that generate a ``direct_url.json``:" -msgstr "" - -#: ../source/specifications/direct-url.rst:281 -msgid "pip install https://example.com/app-1.0.tgz" -msgstr "pip install https://example.com/app-1.0.tgz" - -#: ../source/specifications/direct-url.rst:282 -msgid "pip install https://example.com/app-1.0.whl" -msgstr "pip install https://example.com/app-1.0.whl" - -#: ../source/specifications/direct-url.rst:283 -msgid "" -"pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup" -"\"" -msgstr "" -"pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup" -"\"" - -#: ../source/specifications/direct-url.rst:284 -msgid "pip install ./app" -msgstr "pip install ./app" - -#: ../source/specifications/direct-url.rst:285 -msgid "pip install file:///home/user/app" -msgstr "pip install file:///home/user/app" - -#: ../source/specifications/direct-url.rst:286 -msgid "" -"pip install --editable \"git+https://example.com/repo/app." -"git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local " -"directory where the git repository has been cloned to, and ``dir_info`` will " -"be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" -msgstr "" - -#: ../source/specifications/direct-url.rst:290 -msgid "pip install -e ./app" -msgstr "pip install -e ./app" - -#: ../source/specifications/direct-url.rst:292 -msgid "Commands that *do not* generate a ``direct_url.json``" -msgstr "" - -#: ../source/specifications/direct-url.rst:294 -msgid "pip install app" -msgstr "pip install app" - -#: ../source/specifications/direct-url.rst:295 -msgid "pip install app --no-index --find-links https://example.com/" -msgstr "pip install app --no-index --find-links https://example.com/" - -#: ../source/specifications/entry-points.rst:5 -msgid "Entry points specification" -msgstr "" - -#: ../source/specifications/entry-points.rst:7 -msgid "" -"*Entry points* are a mechanism for an installed distribution to advertise " -"components it provides to be discovered and used by other code. For example:" -msgstr "" - -#: ../source/specifications/entry-points.rst:11 -msgid "" -"Distributions can specify ``console_scripts`` entry points, each referring " -"to a function. When *pip* (or another console_scripts aware installer) " -"installs the distribution, it will create a command-line wrapper for each " -"entry point." -msgstr "" - -#: ../source/specifications/entry-points.rst:14 -msgid "" -"Applications can use entry points to load plugins; e.g. Pygments (a syntax " -"highlighting tool) can use additional lexers and styles from separately " -"installed packages. For more about this, see :doc:`/guides/creating-and-" -"discovering-plugins`." -msgstr "" - -#: ../source/specifications/entry-points.rst:19 -msgid "" -"The entry point file format was originally developed to allow packages built " -"with setuptools to provide integration point metadata that would be read at " -"runtime with ``importlib.metadata``. It is now defined as a PyPA " -"interoperability specification in order to allow build tools other than " -"setuptools to publish ``importlib.metadata`` compatible entry point " -"metadata, and runtime libraries other than ``importlib.metadata`` to " -"portably read published entry point metadata (potentially with different " -"caching and conflict resolution strategies)." -msgstr "" - -#: ../source/specifications/entry-points.rst:28 -msgid "Data model" -msgstr "Модель даних" - -#: ../source/specifications/entry-points.rst:30 -msgid "Conceptually, an entry point is defined by three required properties:" -msgstr "" - -#: ../source/specifications/entry-points.rst:32 -msgid "" -"The **group** that an entry point belongs to indicates what sort of object " -"it provides. For instance, the group ``console_scripts`` is for entry points " -"referring to functions which can be used as a command, while ``pygments." -"styles`` is the group for classes defining pygments styles. The consumer " -"typically defines the expected interface. To avoid clashes, consumers " -"defining a new group should use names starting with a PyPI name owned by the " -"consumer project, followed by ``.``. Group names must be one or more groups " -"of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w" -"+)*$``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:42 -msgid "" -"The **name** identifies this entry point within its group. The precise " -"meaning of this is up to the consumer. For console scripts, the name of the " -"entry point is the command that will be used to launch it. Within a " -"distribution, entry point names should be unique. If different distributions " -"provide the same name, the consumer decides how to handle such conflicts. " -"The name may contain any characters except ``=``, but it cannot start or end " -"with any whitespace character, or start with ``[``. For new entry points, it " -"is recommended to use only letters, numbers, underscores, dots and dashes " -"(regex ``[\\w.-]+``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:51 -msgid "" -"The **object reference** points to a Python object. It is either in the form " -"``importable.module``, or ``importable.module:object.attr``. Each of the " -"parts delimited by dots and the colon is a valid Python identifier. It is " -"intended to be looked up like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:64 -msgid "" -"Some tools call this kind of object reference by itself an 'entry point', " -"for want of a better term, especially where it points to a function to " -"launch a program." -msgstr "" - -#: ../source/specifications/entry-points.rst:68 -msgid "" -"There is also an optional property: the **extras** are a set of strings " -"identifying optional features of the distribution providing the entry point. " -"If these are specified, the entry point requires the dependencies of those " -"'extras'. See the metadata field :ref:`metadata_provides_extra`." -msgstr "" - -#: ../source/specifications/entry-points.rst:73 -msgid "" -"Using extras for an entry point is no longer recommended. Consumers should " -"support parsing them from existing distributions, but may then ignore them. " -"New publishing tools need not support specifying extras. The functionality " -"of handling extras was tied to setuptools' model of managing 'egg' packages, " -"but newer tools such as pip and virtualenv use a different model." -msgstr "" - -#: ../source/specifications/entry-points.rst:80 -msgid "File format" -msgstr "" - -#: ../source/specifications/entry-points.rst:82 -msgid "" -"Entry points are defined in a file called :file:`entry_points.txt` in the :" -"file:`*.dist-info` directory of the distribution. This is the directory " -"described in :pep:`376` for installed distributions, and in :pep:`427` for " -"wheels. The file uses the UTF-8 character encoding." -msgstr "" - -#: ../source/specifications/entry-points.rst:87 -msgid "" -"The file contents are in INI format, as read by Python's :mod:`configparser` " -"module. However, configparser treats names as case-insensitive by default, " -"whereas entry point names are case sensitive. A case-sensitive config parser " -"can be made like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:97 -msgid "" -"The entry points file must always use ``=`` to delimit names from values " -"(whereas configparser also allows using ``:``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:100 -msgid "" -"The sections of the config file represent entry point groups, the names are " -"names, and the values encode both the object reference and the optional " -"extras. If extras are used, they are a comma-separated list inside square " -"brackets." -msgstr "" - -#: ../source/specifications/entry-points.rst:104 -msgid "" -"Within a value, readers must accept and ignore spaces (including multiple " -"consecutive spaces) before or after the colon, between the object reference " -"and the left square bracket, between the extra names and the square brackets " -"and colons delimiting them, and after the right square bracket. The syntax " -"for extras is formally specified as part of :pep:`508` (as ``extras``). For " -"tools writing the file, it is recommended only to insert a space between the " -"object reference and the left square bracket." -msgstr "" - -#: ../source/specifications/entry-points.rst:112 -msgid "For example::" -msgstr "Наприклад::" - -#: ../source/specifications/entry-points.rst:124 -msgid "Use for scripts" -msgstr "" - -#: ../source/specifications/entry-points.rst:126 -msgid "" -"Two groups of entry points have special significance in packaging: " -"``console_scripts`` and ``gui_scripts``. In both groups, the name of the " -"entry point should be usable as a command in a system shell after the " -"package is installed. The object reference points to a function which will " -"be called with no arguments when this command is run. The function may " -"return an integer to be used as a process exit code, and returning ``None`` " -"is equivalent to returning ``0``." -msgstr "" - -#: ../source/specifications/entry-points.rst:134 -msgid "" -"For instance, the entry point ``mycmd = mymod:main`` would create a command " -"``mycmd`` launching a script like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:141 -msgid "" -"The difference between ``console_scripts`` and ``gui_scripts`` only affects " -"Windows systems. ``console_scripts`` are wrapped in a console executable, so " -"they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and " -"``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI " -"executable, so they can be started without a console, but cannot use " -"standard streams unless application code redirects them. Other platforms do " -"not have the same distinction." -msgstr "" - -#: ../source/specifications/entry-points.rst:149 -msgid "" -"Install tools are expected to set up wrappers for both ``console_scripts`` " -"and ``gui_scripts`` in the scripts directory of the install scheme. They are " -"not responsible for putting this directory in the ``PATH`` environment " -"variable which defines where command-line tools are found." -msgstr "" - -#: ../source/specifications/entry-points.rst:154 -msgid "" -"As files are created from the names, and some filesystems are case-" -"insensitive, packages should avoid using names in these groups which differ " -"only in case. The behaviour of install tools when names differ only in case " -"is undefined." -msgstr "" - -#: ../source/specifications/index.rst:4 -msgid "PyPA specifications" -msgstr "Специфікації PyPA" - -#: ../source/specifications/index.rst:6 -msgid "" -"This is a list of currently active interoperability specifications " -"maintained by the Python Packaging Authority. The process for updating these " -"standards, and for proposing new ones, is documented on `pypa.io `__." -msgstr "" - -#: ../source/specifications/index.rst:13 -msgid "Package Distribution Metadata" -msgstr "" - -#: ../source/specifications/index.rst:30 -msgid "Package Distribution File Formats" -msgstr "" - -#: ../source/specifications/index.rst:40 -msgid "Package Index Interfaces" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:6 -msgid "Platform compatibility tags" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:8 -msgid "" -"Platform compatibility tags allow build tools to mark distributions as being " -"compatible with specific platforms, and allows installers to understand " -"which distributions are compatible with the system they are running on." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:12 -msgid "" -"The platform compatibility tagging model used for the ``wheel`` distribution " -"format is defined in :pep:`425`." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:16 -msgid "Platform tags for Windows" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:18 -msgid "" -"The scheme defined in :pep:`425` covers public distribution of wheel files " -"to systems running Windows." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:22 -msgid "Platform tags for macOS (Mac OS X)" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:24 -msgid "" -"The scheme defined in :pep:`425` covers public distribution of wheel files " -"to systems running macOS (previously known as Mac OS X)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:28 -msgid "Platform tags for common Linux distributions" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:32 -msgid "" -"The scheme defined in :pep:`425` is insufficient for public distribution of " -"wheel files (and \\*nix wheel files in general) to Linux platforms, due to " -"the large ecosystem of Linux platforms and subtle differences between them." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:36 -msgid "" -"Instead, :pep:`600` defines the ``manylinux`` standard, which represents a " -"common subset of Linux platforms, and allows building wheels tagged with the " -"``manylinux`` platform tag which can be used across most common Linux " -"distributions." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:41 -msgid "" -"There were multiple iterations of the ``manylinux`` specification, each " -"representing the common subset of Linux platforms at a given point in time:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:44 -msgid "" -"``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, " -"and is based on a compatible Linux platform from 2007." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:46 -msgid "" -"``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` " -"architectures. and updates the previous specification to be based on a " -"compatible Linux platform from 2010 instead." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:49 -msgid "" -"``manylinux2014`` (:pep:`599`) adds support for a number of additional " -"architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and " -"``s390x``) and updates the base platform to a compatible Linux platform from " -"2014." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:54 -msgid "" -"``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a " -"future-proof standard. It defines ``x`` and ``y`` as glibc major an minor " -"versions supported (e.g. ``manylinux_2_24`` should work on any distro using " -"glibc 2.24+). Previous tags are still supported for backward compatibility." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:59 -msgid "" -"In general, distributions built for older versions of the specification are " -"forwards-compatible (meaning that ``manylinux1`` distributions should " -"continue to work on modern systems) but not backwards-compatible (meaning " -"that ``manylinux2010`` distributions are not expected to work on platforms " -"that existed before 2010)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:65 -msgid "" -"Package maintainers should attempt to target the most compatible " -"specification possible, with the caveat that the provided build environment " -"for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning " -"that these images will no longer receive security updates." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:71 -msgid "Manylinux compatibility support" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:74 -msgid "" -"The ``manylinux2014`` specification is relatively new and is not yet widely " -"recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:76 -msgid "" -"The ``manylinux_x_y`` specification is relatively new and is not yet widely " -"recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:79 -msgid "" -"The following table shows the minimum versions of relevant projects to " -"support the various ``manylinux`` standards:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "Tool" -msgstr "Інструмент" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux1``" -msgstr "``manylinux1``" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2010``" -msgstr "``manylinux2010``" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2014``" -msgstr "``manylinux2014``" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux_x_y``" -msgstr "``manylinux_x_y``" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=8.1.0``" -msgstr "``>=8.1.0``" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.0``" -msgstr "``>=19.0``" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.3``" -msgstr "``>=19.3``" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=20.3``" -msgstr "``>=20.3``" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "auditwheel" -msgstr "auditwheel" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=1.0.0``" -msgstr "``>=1.0.0``" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=2.0.0``" -msgstr "``>=2.0.0``" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.0.0``" -msgstr "``>=3.0.0``" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.3.0`` [#]_" -msgstr "``>=3.3.0`` [#]_" - -#: ../source/specifications/platform-compatibility-tags.rst:90 -msgid "Platform tags for other \\*nix platforms" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:92 -msgid "" -"The scheme defined in :pep:`425` is not generally sufficient for public " -"distribution of wheel files to other \\*nix platforms. Efforts are currently " -"(albeit intermittently) under way to define improved compatibility tagging " -"schemes for AIX and for Alpine Linux." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:98 -msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" -msgstr "" - -#: ../source/specifications/pypirc.rst:6 -msgid "The :file:`.pypirc` file" -msgstr "Файл :file:`.pypirc`" - -#: ../source/specifications/pypirc.rst:8 -msgid "" -"A :file:`.pypirc` file allows you to define the configuration for :term:" -"`package indexes ` (referred to here as \"repositories\"), so " -"that you don't have to enter the URL, username, or password whenever you " -"upload a package with :ref:`twine` or :ref:`flit`." -msgstr "" - -#: ../source/specifications/pypirc.rst:13 -msgid "The format (originally defined by the :ref:`distutils` package) is:" -msgstr "" - -#: ../source/specifications/pypirc.rst:32 -msgid "" -"The ``distutils`` section defines an ``index-servers`` field that lists the " -"name of all sections describing a repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:35 -msgid "Each section describing a repository defines three fields:" -msgstr "" - -#: ../source/specifications/pypirc.rst:37 -msgid "``repository``: The URL of the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:38 -msgid "``username``: The registered username on the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:39 -msgid "``password``: The password that will used to authenticate the username." -msgstr "" - -#: ../source/specifications/pypirc.rst:43 -msgid "" -"Be aware that this stores your password in plain text. For better security, " -"consider an alternative like `keyring`_, setting environment variables, or " -"providing the password on the command line." -msgstr "" - -#: ../source/specifications/pypirc.rst:47 -msgid "" -"Otherwise, set the permissions on :file:`.pypirc` so that only you can view " -"or modify it. For example, on Linux or macOS, run:" -msgstr "" - -#: ../source/specifications/pypirc.rst:57 -msgid "Common configurations" -msgstr "" - -#: ../source/specifications/pypirc.rst:61 -msgid "" -"These examples apply to :ref:`twine`, and projects like :ref:`hatch` that " -"use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`." -"pypirc`, but with different defaults. Please refer to each project's " -"documentation for more details and usage instructions." -msgstr "" - -#: ../source/specifications/pypirc.rst:66 -msgid "" -"Twine's default configuration mimics a :file:`.pypirc` with repository " -"sections for PyPI and TestPyPI:" -msgstr "" - -#: ../source/specifications/pypirc.rst:82 -msgid "" -"Twine will add additional configuration from :file:`$HOME/.pypirc`, the " -"command line, and environment variables to this default configuration." -msgstr "" - -#: ../source/specifications/pypirc.rst:86 -msgid "Using a PyPI token" -msgstr "" - -#: ../source/specifications/pypirc.rst:88 -msgid "" -"To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` " -"similar to:" -msgstr "" - -#: ../source/specifications/pypirc.rst:97 -msgid "" -"For :ref:`TestPyPI `, add a ``[testpypi]`` section, using " -"the API token from your TestPyPI account." -msgstr "" - -#: ../source/specifications/pypirc.rst:103 -msgid "Using another package index" -msgstr "" - -#: ../source/specifications/pypirc.rst:105 -msgid "" -"To configure an additional repository, you'll need to redefine the ``index-" -"servers`` field to include the repository name. Here is a complete example " -"of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" -msgstr "" - -#: ../source/specifications/pypirc.rst:132 -msgid "" -"Instead of using the ``password`` field, consider saving your API tokens and " -"passwords securely using `keyring`_ (which is installed by Twine):" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:5 -msgid "Recording installed projects" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:7 -msgid "" -"This document specifies a common format of recording information about " -"Python :term:`projects ` installed in an environment. A common " -"metadata format allows tools to query, manage or uninstall projects, " -"regardless of how they were installed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:12 -msgid "" -"Almost all information is optional. This allows tools outside the Python " -"ecosystem, such as Linux package managers, to integrate with Python tooling " -"as much as possible. For example, even if an installer cannot easily provide " -"a list of installed files in a format specific to Python tooling, it should " -"still record the name and version of the installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:21 -msgid "History and change workflow" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:23 -msgid "" -"The metadata described here was first specified in :pep:`376`, and later " -"amended in :pep:`627`. It was formerly known as *Database of Installed " -"Python Distributions*. Further amendments (except trivial language or " -"typography fixes) must be made through the PEP process (see :pep:`1`)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:29 -msgid "" -"While this document is the normative specification, these PEPs that " -"introduce changes to it may include additional information such as " -"rationales and backwards compatibility considerations." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:37 -msgid "" -"Each project installed from a distribution must, in addition to files, " -"install a \"``.dist-info``\" directory located alongside importable modules " -"and packages (commonly, the ``site-packages`` directory)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:41 -msgid "" -"This directory is named as ``{name}-{version}.dist-info``, with ``name`` and " -"``version`` fields corresponding to :ref:`core-metadata`. Both fields must " -"be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 " -"<440#normalization>` for the definition of normalization for each field " -"respectively), and replace dash (``-``) characters with underscore (``_``) " -"chacaters, so the ``.dist-info`` directory always has exactly one dash (``-" -"``) character in its stem, separating the ``name`` and ``version`` fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:50 -msgid "" -"Historically, tools have failed to replace dot characters or normalize case " -"in the ``name`` field, or not perform normalization in the ``version`` " -"field. Tools consuming ``.dist-info`` directories should expect those fields " -"to be unnormalized, and treat them as equivalent to their normalized " -"counterparts. New tools that write ``.dist-info`` directories MUST normalize " -"both ``name`` and ``version`` fields using the rules described above, and " -"existing tools are encouraged to start normalizing those fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:60 -msgid "" -"The ``.dist-info`` directory's name is formatted to unambigiously represent " -"a distribution as a filesystem path. Tools presenting a distribution name to " -"a user should avoid using the normalized name, and instead present the " -"specified name (when needed prior to resolution to an installed package), or " -"read the respective fields in Core Metadata, since values listed there are " -"unescaped and accurately reflect the distribution. Libraries should provide " -"API for such tools to consume, so tools can have access to the unnormalized " -"name when displaying distrubution information." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:69 -msgid "" -"This ``.dist-info`` directory can contain these files, described in detail " -"below:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:72 -msgid "``METADATA``: contains project metadata" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:73 -msgid "``RECORD``: records the list of installed files." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:74 -msgid "" -"``INSTALLER``: records the name of the tool used to install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:76 -msgid "" -"The ``METADATA`` file is mandatory. All other files may be omitted at the " -"installing tool's discretion. Additional installer-specific files may be " -"present." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:82 -msgid "" -"The :ref:`binary-distribution-format` specification describes additional " -"files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. " -"Such files may be copied to the ``.dist-info`` directory of an installed " -"project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:87 -msgid "" -"The previous versions of this specification also specified a ``REQUESTED`` " -"file. This file is now considered a tool-specific extension, but may be " -"standardized again in the future. See `PEP 376 `_ for its original meaning." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:94 -msgid "The METADATA file" -msgstr "Файл METADATA" - -#: ../source/specifications/recording-installed-packages.rst:96 -msgid "" -"The ``METADATA`` file contains metadata as described in the :ref:`core-" -"metadata` specification, version 1.1 or greater." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:99 -msgid "" -"The ``METADATA`` file is mandatory. If it cannot be created, or if required " -"core metadata is not available, installers must report an error and fail to " -"install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:105 -msgid "The RECORD file" -msgstr "Файл RECORD" - -#: ../source/specifications/recording-installed-packages.rst:107 -msgid "" -"The ``RECORD`` file holds the list of installed files. It is a CSV file " -"containing one record (line) per installed file." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:110 -msgid "" -"The CSV dialect must be readable with the default ``reader`` of Python's " -"``csv`` module:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:113 -msgid "field delimiter: ``,`` (comma)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:114 -msgid "quoting char: ``\"`` (straight double quote)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:115 -msgid "line terminator: either ``\\r\\n`` or ``\\n``." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:117 -msgid "" -"Each record is composed of three elements: the file's **path**, the **hash** " -"of the contents, and its **size**." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:120 -msgid "" -"The *path* may be either absolute, or relative to the directory containing " -"the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On " -"Windows, directories may be separated either by forward- or backslashes (``/" -"`` or ``\\``)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:125 -msgid "" -"The *hash* is either an empty string or the name of a hash algorithm from " -"``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` " -"and the digest of the file's contents, encoded with the urlsafe-base64-nopad " -"encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:130 -msgid "" -"The *size* is either the empty string, or file's size in bytes, as a base 10 " -"integer." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:133 -msgid "" -"For any file, either or both of the *hash* and *size* fields may be left " -"empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself " -"have empty *hash* and *size*. For other files, leaving the information out " -"is discouraged, as it prevents verifying the integrity of the installed " -"project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:139 -msgid "" -"If the ``RECORD`` file is present, it must list all installed files of the " -"project, except ``.pyc`` files corresponding to ``.py`` files listed in " -"``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` " -"directory (including the ``RECORD`` file itself) must be listed. Directories " -"should not be listed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:146 -msgid "" -"To completely uninstall a package, a tool needs to remove all files listed " -"in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding " -"to removed ``.py`` files, and any directories emptied by the uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:151 -msgid "Here is an example snippet of a possible ``RECORD`` file::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:170 -msgid "" -"If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must " -"not atempt to uninstall or upgrade the package. (This does not apply to " -"tools that rely on other sources of information, such as system package " -"managers in Linux distros.)" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:177 -msgid "The INSTALLER file" -msgstr "Файл INSTALLER" - -#: ../source/specifications/recording-installed-packages.rst:179 -msgid "" -"If present, ``INSTALLER`` is a single-line text file naming the tool used to " -"install the project. If the installer is executable from the command line, " -"``INSTALLER`` should contain the command name. Otherwise, it should contain " -"a printable ASCII string." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:185 -msgid "The file can be terminated by zero or more ASCII whitespace characters." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:187 -msgid "Here are examples of two possible ``INSTALLER`` files::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:195 -msgid "" -"This value should be used for informational purposes only. For example, if a " -"tool is asked to uninstall a project but finds no ``RECORD`` file, it may " -"suggest that the tool named in ``INSTALLER`` may be able to do the " -"uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:201 -msgid "The direct_url.json file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:203 -msgid "" -"This file MUST be created by installers when installing a distribution from " -"a requirement specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:209 -msgid "Its detailed specification is at :ref:`direct-url`." -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:6 -msgid "Simple repository API" -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:8 -msgid "" -"The current interface for querying available package versions and retrieving " -"packages from an index server is defined in :pep:`503`, with the addition of " -"\"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` " -"and specifying the interface version provided by an index server in :pep:" -"`629`." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:6 -msgid "Source distribution format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:8 -msgid "" -"The current standard format of source distribution format is identified by " -"the presence of a :file:`pyproject.toml` file in the distribution archive. " -"The layout of such a distribution was originally specified in :pep:`517` and " -"is formally documented here." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:13 -msgid "" -"There is also the legacy source distribution format, implicitly defined by " -"the behaviour of ``distutils`` module in the standard library, when " -"executing :command:`setup.py sdist`. This document does not attempt to " -"standardise this format, except to note that if a legacy source distribution " -"contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it " -"MUST follow the rules applicable to source distributions defined in the " -"metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:21 -msgid "Source distributions are also known as *sdists* for short." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:24 -msgid "Source distribution file name" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:26 -msgid "" -"The file name of a sdist is not currently standardised, although the *de " -"facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the " -"canonicalized form of the project name (see :pep:`503` for the " -"canonicalization rules) with ``-`` characters replaced with ``_``, and " -"``{version}`` is the project version." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:31 -msgid "" -"The name and version components of the filename MUST match the values stored " -"in the metadata contained in the file." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:35 -msgid "Source distribution file format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:37 -msgid "" -"A ``.tar.gz`` source distribution (sdist) contains a single top-level " -"directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the " -"source files of the package. The name and version MUST match the metadata " -"stored in the file. This directory must also contain a :file:`pyproject." -"toml` in the format defined in :ref:`declaring-build-dependencies`, and a " -"``PKG-INFO`` file containing metadata in the format described in the :ref:" -"`core-metadata` specification. The metadata MUST conform to at least version " -"2.2 of the metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:45 -msgid "" -"No other content of a sdist is required or defined. Build systems can store " -"whatever information they need in the sdist to build the project." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:48 -msgid "" -"The tarball should use the modern POSIX.1-2001 pax tar format, which " -"specifies UTF-8 based file names." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:6 -msgid "Version specifiers" -msgstr "" - -#: ../source/specifications/version-specifiers.rst:8 -msgid "" -"Version numbering requirements and the semantics for specifying comparisons " -"between versions are defined in :pep:`440`." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:11 -msgid "" -"The version specifiers section in this PEP supersedes the version specifiers " -"section in :pep:`345`." -msgstr "" - -#: ../source/support.rst:3 -msgid "How to Get Support" -msgstr "" - -#: ../source/support.rst:5 -msgid "" -"For support related to a specific project, see the links on the :doc:" -"`Projects ` page." -msgstr "" - -#: ../source/support.rst:8 -msgid "" -"For something more general, or when you're just not sure, please `open an " -"issue `_ on the " -"`packaging-problems `_ " -"repository on GitHub." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:5 -msgid "Creating Documentation" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:7 -msgid "" -"This section covers the basics of how to create documentation using " -"`Sphinx`_ and host the documentation for free in `Read The Docs`_." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:13 -msgid "Installing Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:14 -msgid "Use ``pip`` to install Sphinx:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:28 -msgid "" -"For other installation methods, see this `installation guide`_ by Sphinx." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:33 -msgid "Getting Started With Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:35 -msgid "" -"Create a ``docs`` directory inside your project to hold your documentation:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:42 -msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:49 -msgid "" -"This sets up a source directory, walks you through some basic " -"configurations, and creates an ``index.rst`` file as well as a ``conf.py`` " -"file." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:51 -msgid "" -"You can add some information about your project in ``index.rst``, then build " -"them:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:57 -msgid "" -"For more details on the build process, see this `guide`_ by Read The Docs." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:62 -msgid "Other Sources" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:64 -msgid "" -"For a more detailed guide on how to use Sphinx and reStructuredText, please " -"see this `documentation tutorial`_ on Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/index.rst:4 -msgid "" -"**Tutorials** are opinionated step-by-step guides to help you get familiar " -"with packaging concepts. For more detailed information on specific packaging " -"topics, see :doc:`/guides/index`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:5 -msgid "Installing Packages" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:7 -msgid "" -"This section covers the basics of how to install Python :term:`packages " -"`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:10 -msgid "" -"It's important to note that the term \"package\" in this context is being " -"used to describe a bundle of software to be installed (i.e. as a synonym for " -"a :term:`distribution `). It does not to refer to the " -"kind of :term:`package ` that you import in your Python " -"source code (i.e. a container of modules). It is common in the Python " -"community to refer to a :term:`distribution ` using " -"the term \"package\". Using the term \"distribution\" is often not " -"preferred, because it can easily be confused with a Linux distribution, or " -"another larger software distribution like Python itself." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:28 -msgid "Requirements for Installing Packages" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:30 -msgid "" -"This section describes the steps to follow before installing other Python " -"packages." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:35 -msgid "Ensure you can run Python from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:37 -msgid "" -"Before you go any further, make sure you have Python and that the expected " -"version is available from your command line. You can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:53 -msgid "" -"You should get some output like ``Python 3.6.3``. If you do not have Python, " -"please install the latest 3.x version from `python.org`_ or refer to the " -"`Installing Python`_ section of the Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:57 -msgid "If you're a newcomer and you get an error like this:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:66 -msgid "" -"It's because this command and other suggested commands in this tutorial are " -"intended to be run in a *shell* (also called a *terminal* or *console*). See " -"the Python for Beginners `getting started tutorial`_ for an introduction to " -"using your operating system's shell and interacting with Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:72 -msgid "" -"If you're using an enhanced shell like IPython or the Jupyter notebook, you " -"can run system commands like those in this tutorial by prefacing them with a " -"``!`` character:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:82 -msgid "" -"It's recommended to write ``{sys.executable}`` rather than plain ``python`` " -"in order to ensure that commands are run in the Python installation matching " -"the currently running notebook (which may not be the same Python " -"installation that the ``python`` command refers to)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:87 -msgid "" -"Due to the way most Linux distributions are handling the Python 3 migration, " -"Linux users using the system Python without creating a virtual environment " -"first should replace the ``python`` command in this tutorial with " -"``python3`` and the ``python -m pip`` command with ``python3 -m pip --" -"user``. Do *not* run any of the commands in this tutorial with ``sudo``: if " -"you get a permissions error, come back to the section on creating virtual " -"environments, set one up, and then continue with the tutorial as written." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:99 -msgid "Ensure you can run pip from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:101 -msgid "" -"Additionally, you'll need to make sure you have :ref:`pip` available. You " -"can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:116 -msgid "" -"If you installed Python from source, with an installer from `python.org`_, " -"or via `Homebrew`_ you should already have pip. If you're on Linux and " -"installed using your OS package manager, you may have to install pip " -"separately, see :doc:`/guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:124 -msgid "" -"If ``pip`` isn't already installed, then first try to bootstrap it from the " -"standard library:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:139 -msgid "If that still doesn't allow you to run ``python -m pip``:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:141 -msgid "" -"Securely Download `get-pip.py `_ [1]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:144 -msgid "" -"Run ``python get-pip.py``. [2]_ This will install or upgrade pip. " -"Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're " -"not installed already." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:150 -msgid "" -"Be cautious if you're using a Python install that's managed by your " -"operating system or another package manager. get-pip.py does not coordinate " -"with those tools, and may leave your system in an inconsistent state. You " -"can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/" -"local`` which is designed for locally-installed software." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:159 -msgid "Ensure pip, setuptools, and wheel are up to date" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:161 -msgid "" -"While ``pip`` alone is sufficient to install from pre-built binary archives, " -"up to date copies of the ``setuptools`` and ``wheel`` projects are useful to " -"ensure you can also install from source archives::" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:169 -msgid "Optionally, create a virtual environment" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:171 -msgid "" -"See :ref:`section below ` for " -"details, but here's the basic `venv`_ [3]_ command to use on a typical Linux " -"system:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:188 -msgid "" -"This will create a new virtual environment in the ``tutorial_env`` " -"subdirectory, and configure the current shell to use it as the default " -"``python`` environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:195 -msgid "Creating Virtual Environments" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:197 -msgid "" -"Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular " -"application, rather than being installed globally. If you are looking to " -"safely install global command line tools, see :doc:`/guides/installing-stand-" -"alone-command-line-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:203 -msgid "" -"Imagine you have an application that needs version 1 of LibFoo, but another " -"application requires version 2. How can you use both these applications? If " -"you install everything into /usr/lib/python3.6/site-packages (or whatever " -"your platform’s standard location is), it’s easy to end up in a situation " -"where you unintentionally upgrade an application that shouldn’t be upgraded." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:209 -msgid "" -"Or more generally, what if you want to install an application and leave it " -"be? If an application works, any change in its libraries or the versions of " -"those libraries can break the application." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:213 -msgid "" -"Also, what if you can’t install :term:`packages ` into " -"the global site-packages directory? For instance, on a shared host." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:216 -msgid "" -"In all these cases, virtual environments can help you. They have their own " -"installation directories and they don’t share libraries with other virtual " -"environments." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:220 -msgid "" -"Currently, there are two common tools for creating Python virtual " -"environments:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:222 -msgid "" -"`venv`_ is available by default in Python 3.3 and later, and installs :ref:" -"`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 " -"and later." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:225 -msgid "" -":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ " -"and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are " -"always installed into created virtual environments by default (regardless of " -"Python version)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:230 -msgid "The basic usage is like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:232 -msgid "Using `venv`_:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:248 -msgid "Using :ref:`virtualenv`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:264 -msgid "" -"For more information, see the `venv`_ docs or the `virtualenv `_ docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:266 -msgid "" -"The use of :command:`source` under Unix shells ensures that the virtual " -"environment's variables are set within the current shell, and not in a " -"subprocess (which then disappears, having no useful effect)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:271 -msgid "" -"In both of the above cases, Windows users should _not_ use the :command:" -"`source` command, but should rather run the :command:`activate` script " -"directly from the command shell like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:281 -msgid "" -"Managing multiple virtual environments directly can become tedious, so the :" -"ref:`dependency management tutorial ` introduces a " -"higher level tool, :ref:`Pipenv`, that automatically manages a separate " -"virtual environment for each project and application that you work on." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:288 -msgid "Use pip for Installing" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:290 -msgid "" -":ref:`pip` is the recommended installer. Below, we'll cover the most common " -"usage scenarios. For more detail, see the `pip docs `_, " -"which includes a complete `Reference Guide `_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:297 -msgid "Installing from PyPI" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:299 -msgid "" -"The most common usage of :ref:`pip` is to install from the :term:`Python " -"Package Index ` using a :term:`requirement " -"specifier `. Generally speaking, a requirement " -"specifier is composed of a project name followed by an optional :term:" -"`version specifier `. :pep:`440` contains a :pep:`full " -"specification <440#version-specifiers>` of the currently supported " -"specifiers. Below are some examples." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:307 -msgid "To install the latest version of \"SomeProject\":" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:321 -msgid "To install a specific version:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:335 -msgid "To install greater than or equal to one version and less than another:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:350 -msgid "" -"To install a version that's :pep:`\"compatible\" <440#compatible-release>` " -"with a certain version: [4]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:365 -msgid "" -"In this case, this means to install any version \"==1.4.*\" version that's " -"also \">=1.4.2\"." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:370 -msgid "Source Distributions vs Wheels" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:372 -msgid "" -":ref:`pip` can install from either :term:`Source Distributions (sdist) " -"` or :term:`Wheels `, but if both " -"are present on PyPI, pip will prefer a compatible :term:`wheel `. You " -"can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:378 -msgid "" -":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source " -"Distributions (sdist) `, especially when " -"a project contains compiled extensions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:383 -msgid "" -"If :ref:`pip` does not find a wheel to install, it will locally build a " -"wheel and cache it for future installs, instead of rebuilding the source " -"distribution in the future." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:391 -msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:408 -msgid "Installing to the User Site" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:410 -msgid "" -"To install :term:`packages ` that are isolated to the " -"current user, use the ``--user`` flag:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:425 -msgid "" -"For more information see the `User Installs `_ section from the pip docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:429 -msgid "" -"Note that the ``--user`` flag has no effect when inside a virtual " -"environment - all installation commands will affect the virtual environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:432 -msgid "" -"If ``SomeProject`` defines any command-line scripts or console entry points, " -"``--user`` will cause them to be installed inside the `user base`_'s binary " -"directory, which may or may not already be present in your shell's :envvar:" -"`PATH`. (Starting in version 10, pip displays a warning when installing any " -"scripts to a directory outside :envvar:`PATH`.) If the scripts are not " -"available in your shell after installation, you'll need to add the directory " -"to your :envvar:`PATH`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:440 -msgid "" -"On Linux and macOS you can find the user base binary directory by running " -"``python -m site --user-base`` and adding ``bin`` to the end. For example, " -"this will typically print ``~/.local`` (with ``~`` expanded to the absolute " -"path to your home directory) so you'll need to add ``~/.local/bin`` to your " -"``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:446 -msgid "" -"On Windows you can find the user base binary directory by running ``py -m " -"site --user-site`` and replacing ``site-packages`` with ``Scripts``. For " -"example, this could return ``C:\\Users\\Username\\AppData\\Roaming" -"\\Python36\\site-packages`` so you would need to set your ``PATH`` to " -"include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You " -"can set your user ``PATH`` permanently in the `Control Panel`_. You may need " -"to log out for the ``PATH`` changes to take effect." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:462 -msgid "" -"Install a list of requirements specified in a :ref:`Requirements File `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:478 -msgid "Installing from VCS" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:480 -msgid "" -"Install a project from VCS in \"editable\" mode. For a full breakdown of " -"the syntax, see pip's section on :ref:`VCS Support `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:502 -msgid "Installing from other Indexes" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:504 -msgid "Install from an alternate index" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:518 -msgid "" -"Search an additional index during install, in addition to :term:`PyPI " -"`" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:534 -msgid "Installing from a local src tree" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:537 -msgid "" -"Installing from local src in `Development Mode `_, i.e. in such a " -"way that the project appears to be installed, but yet is still editable from " -"the src tree." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:554 -msgid "You can also install normally from src" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:571 -msgid "Install a particular source archive file." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:585 -msgid "" -"Install from a local directory containing archives (and don't check :term:" -"`PyPI `)" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:605 -msgid "Installing from other sources" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:607 -msgid "" -"To install from other data sources (for example Amazon S3 storage) you can " -"create a helper application that presents the data in a :pep:`503` compliant " -"index format, and use the ``--extra-index-url`` flag to direct pip to use " -"that index." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:619 -msgid "Installing Prereleases" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:621 -msgid "" -"Find pre-release and development versions, in addition to stable versions. " -"By default, pip only finds stable versions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:637 -msgid "Installing Setuptools \"Extras\"" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:639 -msgid "Install `setuptools extras`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:659 -msgid "" -"\"Secure\" in this context means using a modern browser or a tool like :" -"command:`curl` that verifies SSL certificates when downloading from https " -"URLs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:668 -msgid "" -"Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:" -"`virtualenv`) will create virtualenv environments with ``pip`` pre-" -"installed, thereby making it an equal alternative to :ref:`virtualenv`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:673 -msgid "" -"The compatible release specifier was accepted in :pep:`440` and support was " -"released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:4 -msgid "Managing Application Dependencies" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:6 -msgid "" -"The :ref:`package installation tutorial ` covered the " -"basics of getting set up to install and update Python packages." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:9 -msgid "" -"However, running these commands interactively can get tedious even for your " -"own personal projects, and things get even more difficult when trying to set " -"up development environments automatically for projects with multiple " -"contributors." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:13 -msgid "" -"This tutorial walks you through the use of :ref:`Pipenv` to manage " -"dependencies for an application. It will show you how to install and use the " -"necessary tools and make strong recommendations on best practices." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:17 -msgid "" -"Keep in mind that Python is used for a great many different purposes, and " -"precisely how you want to manage your dependencies may change based on how " -"you decide to publish your software. The guidance presented here is most " -"directly applicable to the development and deployment of network services " -"(including web applications), but is also very well suited to managing " -"development and testing environments for any kind of project." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:24 -msgid "" -"Developers of Python libraries, or of applications that support distribution " -"as Python libraries, should also consider the `poetry `_ project as an alternative dependency management " -"solution." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:30 -msgid "Installing Pipenv" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:32 -msgid "" -":ref:`Pipenv` is a dependency manager for Python projects. If you're " -"familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit " -"to those tools. While :ref:`pip` alone is often sufficient for personal use, " -"Pipenv is recommended for collaborative projects as it's a higher-level tool " -"that simplifies dependency management for common use cases." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:38 -msgid "Use ``pip`` to install Pipenv:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:54 -msgid "" -"This does a `user installation`_ to prevent breaking any system-wide " -"packages. If ``pipenv`` isn't available in your shell after installation, " -"you'll need to add the `user base`_'s binary directory to your ``PATH``. " -"See :ref:`Installing to the User Site` for more information." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:65 -msgid "Installing packages for your project" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:67 -msgid "" -"Pipenv manages dependencies on a per-project basis. To install packages, " -"change into your project's directory (or just an empty directory for this " -"tutorial) and run:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:76 -msgid "" -"Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you " -"in your project's directory. The :ref:`Pipfile` is used to track which " -"dependencies your project needs in case you need to re-install them, such as " -"when you share your project with others. You should get output similar to " -"this (although the exact paths shown will vary):" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:112 -msgid "Using installed packages" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:114 -msgid "" -"Now that Requests is installed you can create a simple :file:`main.py` file " -"to use it:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:125 -msgid "Then you can run this script using ``pipenv run``:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:131 -msgid "You should get output similar to this:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:137 -msgid "" -"Using ``pipenv run`` ensures that your installed packages are available to " -"your script. It's also possible to spawn a new shell that ensures all " -"commands have access to your installed packages with ``pipenv shell``." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:143 -#: ../source/tutorials/packaging-projects.rst:594 -msgid "Next steps" -msgstr "Наступні кроки" - -#: ../source/tutorials/managing-dependencies.rst:145 -msgid "" -"Congratulations, you now know how to effectively manage dependencies and " -"development environments on a collaborative Python project! ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:148 -msgid "" -"If you're interested in creating and distributing your own Python packages, " -"see the :ref:`tutorial on packaging and distributing packages `." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:151 -msgid "" -"Note that when your application includes definitions of Python source " -"packages, they (and their dependencies) can be added to your ``pipenv`` " -"environment with ``pipenv install -e `` " -"(e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:160 -msgid "Other Tools for Application Dependency Management" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:162 -msgid "" -"If you find this particular approach to managing application dependencies " -"isn't working well for you or your use case, you may want to explore these " -"other tools and techniques to see if one of them is a better fit:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:166 -msgid "" -"`poetry `__ for a tool comparable " -"in scope to ``pipenv`` that focuses more directly on use cases where the " -"repository being managed is structured as a Python project with a valid " -"``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making " -"the assumption that the application being worked on that's depending on " -"components from PyPI will itself support distribution as a ``pip``-" -"installable Python package)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:172 -msgid "" -"`hatch `_ for opinionated coverage of even " -"more steps in the project management workflow (such as incrementing " -"versions, tagging releases, and creating new skeleton projects from project " -"templates)" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:175 -msgid "" -"`pip-tools `_ to build your own " -"custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:177 -msgid "" -"`micropipenv `_ is a " -"lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry " -"lock files or converting them to pip-tools compatible output. Designed for " -"containerized Python applications but not limited to them." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:2 -msgid "Packaging Python Projects" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:4 -msgid "" -"This tutorial walks you through how to package a simple Python project. It " -"will show you how to add the necessary files and structure to create the " -"package, how to build the package, and how to upload it to the Python " -"Package Index." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:10 -msgid "" -"If you have trouble running the commands in this tutoral, please copy the " -"command and its output, then `open an issue`_ on the `packaging-problems`_ " -"repository on GitHub. We'll do our best to help you!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:18 -msgid "" -"Some of the commands require a newer version of :ref:`pip`, so start by " -"making sure you have the latest version installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:35 -msgid "A simple project" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:37 -msgid "" -"This tutorial uses a simple project named ``example_package``. We recommend " -"following this tutorial as-is using this project, before packaging your own " -"project." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:41 -msgid "Create the following file structure locally:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:51 -msgid "" -":file:`__init__.py` is required to import the directory as a package, and " -"should be empty." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:54 -msgid "" -":file:`example.py` is an example of a module within the package that could " -"contain the logic (functions, classes, constants, etc.) of your package. " -"Open that file and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:63 -msgid "" -"If you are unfamiliar with Python's :term:`modules ` and :term:" -"`import packages `, take a few minutes to read over the " -"`Python documentation for packages and modules`_." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:67 -msgid "" -"Once you create this structure, you'll want to run all of the commands in " -"this tutorial within the ``packaging_tutorial`` directory." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:75 -msgid "Creating the package files" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:77 -msgid "" -"You will now add files that are used to prepare the project for " -"distribution. When you're done, the project structure will look like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:95 -msgid "Creating a test directory" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:97 -msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:101 -msgid "Creating pyproject.toml" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:103 -msgid "" -":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) " -"what is required to build your project. This tutorial uses :ref:" -"`setuptools`, so open :file:`pyproject.toml` and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:117 -msgid "" -"``build-system.requires`` gives a list of packages that are needed to build " -"your package. Listing something here will *only* make it available during " -"the build, not after it is installed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:121 -msgid "" -"``build-system.build-backend`` is the name of Python object that will be " -"used to perform the build. If you were to use a different build system, such " -"as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration " -"details would be completely different than the :ref:`setuptools` " -"configuration described below." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:127 -msgid "See :pep:`517` and :pep:`518` for background and details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:131 -msgid "Configuring metadata" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:133 -msgid "There are two types of metadata: static and dynamic." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:135 -msgid "" -"Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. " -"This is simpler, easier to read, and avoids many common errors, like " -"encoding errors." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:137 -msgid "" -"Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items " -"that are dynamic or determined at install-time, as well as extension modules " -"or extensions to setuptools, need to go into :file:`setup.py`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:141 -msgid "" -"Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:" -"file:`setup.py`) should be used only as an escape hatch when absolutely " -"necessary. :file:`setup.py` used to be required, but can be omitted with " -"newer versions of setuptools and pip." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:148 -msgid "" -":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells " -"setuptools about your package (such as the name and version) as well as " -"which code files to include. Eventually much of this configuration may be " -"able to move to :file:`pyproject.toml`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:153 -msgid "" -"Open :file:`setup.cfg` and enter the following content. Change the ``name`` " -"to include your username; this ensures that you have a unique package name " -"and that your package doesn't conflict with packages uploaded by other " -"people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:185 -msgid "" -"There are a `variety of metadata and options `_ supported here. This is " -"in :doc:`configparser ` format; do not place " -"quotes around values. This example package uses a relatively minimal set of " -"``metadata``:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:191 -#: ../source/tutorials/packaging-projects.rst:286 -msgid "" -"``name`` is the *distribution name* of your package. This can be any name as " -"long as it only contains letters, numbers, ``_`` , and ``-``. It also must " -"not already be taken on pypi.org. **Be sure to update this with your " -"username,** as this ensures you won't try to upload a package with the same " -"name as one which already exists." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:196 -msgid "" -"``version`` is the package version. See :pep:`440` for more details on " -"versions. You can use ``file:`` or ``attr:`` directives to read from a file " -"or package attribute." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:199 -#: ../source/tutorials/packaging-projects.rst:293 -msgid "" -"``author`` and ``author_email`` are used to identify the author of the " -"package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:201 -#: ../source/tutorials/packaging-projects.rst:295 -msgid "``description`` is a short, one-sentence summary of the package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:202 -msgid "" -"``long_description`` is a detailed description of the package. This is shown " -"on the package detail page on the Python Package Index. In this case, the " -"long description is loaded from :file:`README.md` (which is a common " -"pattern) using the ``file:`` directive." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:206 -#: ../source/tutorials/packaging-projects.rst:300 -msgid "" -"``long_description_content_type`` tells the index what type of markup is " -"used for the long description. In this case, it's Markdown." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:208 -#: ../source/tutorials/packaging-projects.rst:302 -msgid "" -"``url`` is the URL for the homepage of the project. For many projects, this " -"will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting " -"service." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:211 -#: ../source/tutorials/packaging-projects.rst:305 -msgid "" -"``project_urls`` lets you list any number of extra links to show on PyPI. " -"Generally this could be to documentation, issue trackers, etc." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:213 -#: ../source/tutorials/packaging-projects.rst:307 -msgid "" -"``classifiers`` gives the index and :ref:`pip` some additional metadata " -"about your package. In this case, the package is only compatible with Python " -"3, is licensed under the MIT license, and is OS-independent. You should " -"always include at least which version(s) of Python your package works on, " -"which license your package is available under, and which operating systems " -"your package will work on. For a complete list of classifiers, see https://" -"pypi.org/classifiers/." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:221 -msgid "In the ``options`` category, we have controls for setuptools itself:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:223 -msgid "" -"``package_dir`` is a mapping of package names and directories. An empty " -"package name represents the \"root package\" --- the directory in the " -"project that contains all Python source files for the package --- so in this " -"case the ``src`` directory is designated the root package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:227 -msgid "" -"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " -"`. Instead of listing each package manually, we can " -"use the ``find:`` directive to automatically discover all packages and " -"subpackages and ``options.packages.find`` to specify the ``package_dir`` to " -"use. In this case, the list of packages will be ``example_package`` as " -"that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:234 -msgid "" -"``python_requires`` gives the versions of Python supported by your project. " -"Installers like :ref:`pip` will look back through older versions of packages " -"until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:238 -#: ../source/tutorials/packaging-projects.rst:329 -msgid "" -"There are many more than the ones mentioned here. See :doc:`/guides/" -"distributing-packages-using-setuptools` for more details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:244 -msgid "" -":file:`setup.py` is the build script for :ref:`setuptools`. It tells " -"setuptools about your package (such as the name and version) as well as " -"which code files to include." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:248 -msgid "" -"Open :file:`setup.py` and enter the following content. Change the ``name`` " -"to include your username; this ensures that you have a unique package name " -"and that your package doesn't conflict with packages uploaded by other " -"people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:283 -msgid "" -":func:`setup` takes several arguments. This example package uses a " -"relatively minimal set:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:291 -msgid "" -"``version`` is the package version. See :pep:`440` for more details on " -"versions." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:296 -msgid "" -"``long_description`` is a detailed description of the package. This is shown " -"on the package detail page on the Python Package Index. In this case, the " -"long description is loaded from :file:`README.md`, which is a common pattern." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:314 -msgid "" -"``package_dir`` is a dictionary with package names for keys and directories " -"for values. An empty package name represents the \"root package\" --- the " -"directory in the project that contains all Python source files for the " -"package --- so in this case the ``src`` directory is designated the root " -"package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:319 -msgid "" -"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " -"`. Instead of listing each package manually, we can " -"use :func:`find_packages` to automatically discover all packages and " -"subpackages under ``package_dir``. In this case, the list of packages will " -"be ``example_package`` as that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:325 -msgid "" -"``python_requires`` gives the versions of Python supported by your project. " -"Installers like :ref:`pip` will look back though older versions of packages " -"until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:333 -msgid "Creating README.md" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:335 -msgid "" -"Open :file:`README.md` and enter the following content. You can customize " -"this if you'd like." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:347 -msgid "" -"Because our configuration loads :file:`README.md` to provide a " -"``long_description``, :file:`README.md` must be included along with your " -"code when you :ref:`generate a source distribution `. " -"Newer versions of :ref:`setuptools` will do this automatically." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:354 -msgid "Creating a LICENSE" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:356 -msgid "" -"It's important for every package uploaded to the Python Package Index to " -"include a license. This tells users who install your package the terms under " -"which they can use your package. For help picking a license, see https://" -"choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` " -"and enter the license text. For example, if you had chosen the MIT license:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:387 -msgid "Including other files" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:389 -msgid "" -"The files listed above will be included automatically in your :term:`source " -"distribution `. If you want to control " -"what goes in this explicitly, see :ref:`Using MANIFEST.in`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:393 -msgid "" -"The final :term:`built distribution ` will have the " -"Python files in the discovered or listed Python packages. If you want to " -"control what goes here, such as to add data files, see :doc:`Including Data " -"Files ` from the :doc:`setuptools docs " -"`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:402 -msgid "Generating distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:404 -msgid "" -"The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the " -"Python Package Index and can be installed by :ref:`pip`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:408 -msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:422 -msgid "" -"If you have trouble installing these, see the :doc:`installing-packages` " -"tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:425 -msgid "" -"Now run this command from the same directory where :file:`pyproject.toml` is " -"located:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:439 -msgid "" -"This command should output a lot of text and once completed should generate " -"two files in the :file:`dist` directory:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:449 -msgid "" -"The ``tar.gz`` file is a :term:`source archive ` whereas the " -"``.whl`` file is a :term:`built distribution `. Newer :" -"ref:`pip` versions preferentially install built distributions, but will fall " -"back to source archives if needed. You should always upload a source archive " -"and provide built archives for the platforms your project is compatible " -"with. In this case, our example package is compatible with Python on any " -"platform so only one built distribution is needed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:458 -msgid "Uploading the distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:460 -msgid "Finally, it's time to upload your package to the Python Package Index!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:462 -msgid "" -"The first thing you'll need to do is register an account on TestPyPI, which " -"is a separate instance of the package index intended for testing and " -"experimentation. It's great for things like this tutorial where we don't " -"necessarily want to upload to the real index. To register an account, go to " -"https://test.pypi.org/account/register/ and complete the steps on that page. " -"You will also need to verify your email address before you're able to upload " -"any packages. For more details, see :doc:`/guides/using-testpypi`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:470 -msgid "" -"To securely upload your project, you'll need a PyPI `API token`_. Create one " -"at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" " -"to \"Entire account\". **Don't close the page until you have copied and " -"saved the token — you won't see that token again.**" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:477 -msgid "" -"Now that you are registered, you can use :ref:`twine` to upload the " -"distribution packages. You'll need to install Twine:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:492 -msgid "" -"Once installed, run Twine to upload all of the archives under :file:`dist`:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:506 -msgid "" -"You will be prompted for a username and password. For the username, use " -"``__token__``. For the password, use the token value, including the ``pypi-" -"`` prefix." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:510 -msgid "After the command completes, you should see output similar to this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:523 -msgid "" -"Once uploaded your package should be viewable on TestPyPI, for example, " -"https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:528 -msgid "Installing your newly uploaded package" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:530 -msgid "" -"You can use :ref:`pip` to install your package and verify that it works. " -"Create a :ref:`virtual environment ` and install your package from TestPyPI:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:546 -msgid "Make sure to specify your username in the package name!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:548 -msgid "" -"pip should install the package from TestPyPI and the output should look " -"something like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:558 -msgid "" -"This example uses ``--index-url`` flag to specify TestPyPI instead of live " -"PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have " -"the same packages as the live PyPI, it's possible that attempting to install " -"dependencies may fail or install something unexpected. While our example " -"package doesn't have any dependencies, it's a good practice to avoid " -"installing dependencies when using TestPyPI." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:565 -msgid "" -"You can test that it was installed correctly by importing the package. Make " -"sure you're still in your virtual environment, then run Python:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:580 -msgid "and import the package:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:588 -msgid "" -"Note that the :term:`import package ` is ``example_package`` " -"regardless of what ``name`` you gave your :term:`distribution package " -"` in :file:`setup.cfg` or :file:`setup.py` (in this " -"case, ``example-pkg-YOUR-USERNAME-HERE``)." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:596 -msgid "" -"**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" -msgstr "**Вітаємо, ви запакували та розповсюдили Python-проєкт!** ✨ 🍰 ✨" - -#: ../source/tutorials/packaging-projects.rst:599 -msgid "" -"Keep in mind that this tutorial showed you how to upload your package to " -"Test PyPI, which isn't a permanent storage. The Test system occasionally " -"deletes packages and accounts. It is best to use TestPyPI for testing and " -"experiments like this tutorial." -msgstr "" -"Майте на увазі, що цей туторіал показав вам, як опублікувати свій пакунок до " -"Test PyPI, який не є постійним сховищем. Тестова система час від часу " -"видаляє пакунки та облікові записи. Краще використовувати TestPyPI для " -"тестування та експериментів, як у цьому туторіалі." - -#: ../source/tutorials/packaging-projects.rst:604 -msgid "" -"When you are ready to upload a real package to the Python Package Index you " -"can do much the same as you did in this tutorial, but with these important " -"differences:" -msgstr "" -"Коли ви будете готові завантажити справжній пакунок до Реєстру Python-" -"пакунків, ви можете зробити те ж саме, що і в цьому туторіалі, але з цими " -"важливими відмінностями:" - -#: ../source/tutorials/packaging-projects.rst:608 -msgid "" -"Choose a memorable and unique name for your package. You don't have to " -"append your username as you did in the tutorial." -msgstr "" -"Оберіть пам'ятну й унікальну назву для свого пакунку. Вам не потрібно " -"додавати своє ім'я користувача, як ви це робили в туторіалі." - -#: ../source/tutorials/packaging-projects.rst:610 -msgid "" -"Register an account on https://pypi.org - note that these are two separate " -"servers and the login details from the test server are not shared with the " -"main server." -msgstr "" -"Зареєструйте обліковий запис на https://pypi.org - зверніть увагу, що це два " -"окремих сервери, а дані для входу для тестового сервера не підходять до " -"основного." - -#: ../source/tutorials/packaging-projects.rst:613 -msgid "" -"Use ``twine upload dist/*`` to upload your package and enter your " -"credentials for the account you registered on the real PyPI. Now that " -"you're uploading the package in production, you don't need to specify ``--" -"repository``; the package will upload to https://pypi.org/ by default." -msgstr "" -"Використайте ``twine upload dist/*`` аби опублікувати свій пакунок і введіть " -"облікові дані запису, який ви зареєстрували на справжньому PyPI. Тепер, " -"коли ви публікуєте пакунок як продакшн-версію, вам не потрібно вказувати " -"``--repository``; пакунок буде опубліковано на https://pypi.org/ за " -"замовчуванням." - -#: ../source/tutorials/packaging-projects.rst:617 -msgid "" -"Install your package from the real PyPI using ``python3 -m pip install [your-" -"package]``." -msgstr "" -"Встановіть свій пакунок зі справжнього PyPI за допомогою ``python3 -m pip " -"install [your-package]``." - -#: ../source/tutorials/packaging-projects.rst:619 -msgid "" -"At this point if you want to read more on packaging Python libraries here " -"are some things you can do:" -msgstr "" -"На цьому етапі, якшо ви бажаєте почитати більше про пакування Python-" -"бібліотек, то ось що ви можете зробити:" - -#: ../source/tutorials/packaging-projects.rst:622 -msgid "" -"Read more about using :ref:`setuptools` to package libraries in :doc:`/" -"guides/distributing-packages-using-setuptools`." -msgstr "" -"Прочитайте більше про використання :ref:`setuptools` для пакування бібліотек " -"в :doc:`/guides/distributing-packages-using-setuptools`." - -#: ../source/tutorials/packaging-projects.rst:624 -msgid "Read about :doc:`/guides/packaging-binary-extensions`." -msgstr "Прочитайте про :doc:`/guides/packaging-binary-extensions`." - -#: ../source/tutorials/packaging-projects.rst:625 -msgid "" -"Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:" -"`hatch`, and :ref:`poetry`." -msgstr "" -"Розгляньте альтернативи до :ref:`setuptools` такі як :ref:`flit`, :ref:" -"`hatch` і :ref:`poetry`." diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po deleted file mode 100644 index 3950c581c..000000000 --- a/locales/zh_Hans/LC_MESSAGES/messages.po +++ /dev/null @@ -1,13922 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2013–2020, PyPA -# This file is distributed under the same license as the Python Packaging User Guide package. -# meowmeowmeowcat , 2021. -# Zuorong Zhang , 2021. -# bluewindde <13548563428@139.com>, 2021. -# Cube Kassaki <2524737581@qq.com>, 2021. -# xlivevil , 2021. -# Eric , 2021. -# YangYulin , 2021. -# 大胖纸 , 2021. -msgid "" -msgstr "" -"Project-Id-Version: Python Packaging User Guide\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-12-02 22:12+0000\n" -"Last-Translator: 大胖纸 \n" -"Language-Team: Chinese (Simplified) \n" -"Language: zh_Hans\n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=UTF-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Plural-Forms: nplurals=1; plural=0;\n" -"X-Generator: Weblate 4.10-dev\n" - -#: ../source/contribute.rst:5 -msgid "Contribute to this guide" -msgstr "为本指南做出贡献" - -#: ../source/contribute.rst:7 -msgid "" -"The |PyPUG| welcomes contributors! There are lots of ways to help out, " -"including:" -msgstr "|PyPUG| 欢迎贡献者！有很多方法可以帮助我们，包括：" - -#: ../source/contribute.rst:10 -msgid "Reading the guide and giving feedback" -msgstr "阅读指南并提供反馈" - -#: ../source/contribute.rst:11 -msgid "Reviewing new contributions" -msgstr "审查新的贡献" - -#: ../source/contribute.rst:12 -msgid "Revising existing content" -msgstr "修改现有内容" - -#: ../source/contribute.rst:13 -msgid "Writing new content" -msgstr "撰写新内容" - -#: ../source/contribute.rst:15 -msgid "" -"Most of the work on the |PyPUG| takes place on the `project's GitHub " -"repository`__. To get started, check out the list of `open issues`__ and " -"`pull requests`__. If you're planning to write or edit the guide, please " -"read the :ref:`style guide `." -msgstr "" -"大部分关于 |PyPUG| 的工作都是在 `项目的GitHub存储库 `__ " -"进行的。要开始工作，请查看 `open issues`__ 和 `pull requests`__ 的列表。如果你打算编写或编辑指南，请阅读 :ref:`" -"style guide `。" - -#: ../source/contribute.rst:24 -msgid "" -"By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of " -"Conduct`__." -msgstr "如果您想为 |PyPUG| 作出贡献，您应该遵守 PSF 的 `行为准则 `__ 。" - -#: ../source/contribute.rst:31 -msgid "Documentation types" -msgstr "文档类型" - -#: ../source/contribute.rst:33 -msgid "" -"This project consists of four distinct documentation types with specific " -"purposes. When proposing new additions to the project please pick the " -"appropriate documentation type." -msgstr "" -"本项目由具有特定目的的四种不同的文档类型组成。当提议对项目进行新的补充时，请" -"选择适当的文档类型。" - -#: ../source/contribute.rst:38 ../source/tutorials/index.rst:2 -msgid "Tutorials" -msgstr "教程" - -#: ../source/contribute.rst:40 -msgid "" -"Tutorials are focused on teaching the reader new concepts by accomplishing a " -"goal. They are opinionated step-by-step guides. They do not include " -"extraneous warnings or information. `example tutorial-style document`_." -msgstr "" -"教程的重点是通过完成一个目标来教导读者新的概念。它们是有观点的分步指南。它们不包括不相干的警告或信息。`示例教程式文件 `_ 。" - -#: ../source/contribute.rst:47 ../source/guides/index.rst:2 -msgid "Guides" -msgstr "指南" - -#: ../source/contribute.rst:49 -msgid "" -"Guides are focused on accomplishing a specific task and can assume some " -"level of pre-requisite knowledge. These are similar to tutorials, but have a " -"narrow and clear focus and can provide lots of caveats and additional " -"information as needed. They may also discuss multiple approaches to " -"accomplishing the task. :doc:`example guide-style document `." -msgstr "" -"指南的重点是完成一项具体的任务，并可以假定有一定程度的前提知识。这类似于教程，但有一个狭窄和明确的重点，并可以根据需要提供大量的注意事项和附加信息。他们还" -"可以讨论完成任务的多种方法。 :doc:`示例指南式文档 `。" - -#: ../source/contribute.rst:56 ../source/discussions/index.rst:2 -msgid "Discussions" -msgstr "讨论" - -#: ../source/contribute.rst:58 -msgid "" -"Discussions are focused on understanding and information. These explore a " -"specific topic without a specific goal in mind. :doc:`example discussion-" -"style document `." -msgstr "" -"讨论 (Discussions) 的重点是理解和信息。这些探索一个特定的主题，没有具体的目标。 :doc:`示例讨论式文件 `。" - -#: ../source/contribute.rst:63 -msgid "Specifications" -msgstr "规格" - -#: ../source/contribute.rst:65 -msgid "" -"Specifications are reference documention focused on comprehensively " -"documenting an agreed-upon interface for interoperability between packaging " -"tools. :doc:`example specification-style document `." -msgstr "" -"规范 (Specifications) 是一种参考文件，侧重于全面记录包装工具之间互操作性的一" -"致接口。 :doc:`范例规范式文件 `。" - -#: ../source/contribute.rst:73 -msgid "Building the guide locally" -msgstr "在本地构建指南" - -#: ../source/contribute.rst:75 -msgid "" -"Though not required to contribute, it may be useful to build this guide " -"locally in order to test your changes. In order to build this guide locally, " -"you'll need:" -msgstr "" -"虽然这不需要做出贡献，但为了测试您的改动，在本地建立本指南可能是有用的。为了" -"在本地构建本指南，你需要：" - -#: ../source/contribute.rst:79 -msgid "" -"`Nox `_. You can install or upgrade " -"nox using ``pip``::" -msgstr "" -"`Nox `_ 。你可以用 ``pip`` 来安装或升" -"级nox::" - -#: ../source/contribute.rst:84 -msgid "" -"Python 3.6. Our build scripts are designed to work with Python 3.6 only. See " -"the `Hitchhiker's Guide to Python installation instructions`_ to install " -"Python 3.6 on your operating system." -msgstr "" -"Python 3.6。我们的构建脚本只为 Python 3.6 而设计。请参阅 `Hitchhiker's Guide to 5Python " -"installation instructions`_ 将 Python 3.6 安装于您的操作系统中。" - -#: ../source/contribute.rst:91 -msgid "" -"To build the guide, run the following bash command in the source folder::" -msgstr "要构建指南，在 source 文件夹中运行以下 bash 命令::" - -#: ../source/contribute.rst:95 -msgid "" -"After the process has completed you can find the HTML output in the ``./" -"build/html`` directory. You can open the ``index.html`` file to view the " -"guide in web browser, but it's recommended to serve the guide using an HTTP " -"server." -msgstr "" -"在该过程完成后，您可以在 ``./build/html`` 目录中找到 HTML 输出。您可以打开 " -"``index.html`` 文件，并在浏览器中查看指南，但我们建议使用 HTTP 服务器为指南服" -"务。" - -#: ../source/contribute.rst:100 -msgid "" -"You can build the guide and serve it via an HTTP server using the following " -"command::" -msgstr "您可以使用以下命令建立指南并通过 HTTP 服务器为其提供服务::" - -#: ../source/contribute.rst:105 -msgid "The guide will be browsable via http://localhost:8000." -msgstr "该指南将可通过 http://localhost:8000 进行浏览。" - -#: ../source/contribute.rst:109 -msgid "Where the guide is deployed" -msgstr "指南的部署地点" - -#: ../source/contribute.rst:111 -msgid "" -"The guide is deployed via ReadTheDocs and the configuration lives at https://" -"readthedocs.org/projects/python-packaging-user-guide/. It's served from a " -"custom domain and fronted by Fast.ly." -msgstr "" -"该指南是通过ReadTheDocs部署的，配置位于 https://readthedocs.org/projects/" -"python-packaging-user-guide/ 。它由一个自定义域名提供服务，并由 Fast.ly 提供" -"支持。" - -#: ../source/contribute.rst:117 -msgid "Style guide" -msgstr "风格指南" - -#: ../source/contribute.rst:119 -msgid "" -"This style guide has recommendations for how you should write the |PyPUG|. " -"Before you start writing, please review it. By following the style guide, " -"your contributions will help add to a cohesive whole and make it easier for " -"your contributions to be accepted into the project." -msgstr "" -"本风格指南提供了关于如何编写 |PyPUG| 的建议。在开始写作之前，请先查看它。通过" -"遵循样式指南，您的贡献将有助于增加一个有凝聚力的整体，并使您的贡献更容易被项" -"目接受。" - -#: ../source/contribute.rst:126 -msgid "Purpose" -msgstr "目的" - -#: ../source/contribute.rst:128 -msgid "" -"The purpose of the |PyPUG| is to be the authoritative resource on how to " -"package, publish, and install Python projects using current tools." -msgstr "" -"|PyPUG| 的目的是成为关于如何使用当前工具打包、发布和安装 Python 项目的权威性" -"资源。" - -#: ../source/contribute.rst:133 -msgid "Scope" -msgstr "范围" - -#: ../source/contribute.rst:135 -msgid "" -"The guide is meant to answer questions and solve problems with accurate and " -"focused recommendations." -msgstr "该指南旨在通过准确和有针对性的建议来回答问题和解决问题。" - -#: ../source/contribute.rst:138 -msgid "" -"The guide isn't meant to be comprehensive and it's not meant to replace " -"individual projects' documentation. For example, pip has dozens of commands, " -"options, and settings. The pip documentation describes each of them in " -"detail, while this guide describes only the parts of pip that are needed to " -"complete the specific tasks described in this guide." -msgstr "" -"本指南并不意味着是全面的，也不意味着可以取代单个项目的文档。例如，pip 有几十" -"个命令、选项和设置。pip 文档详细描述了它们中的每一个，而本指南只描述了完成本" -"指南中描述的特定任务所需的 pip 部分。" - -#: ../source/contribute.rst:146 -msgid "Audience" -msgstr "读者" - -#: ../source/contribute.rst:148 -msgid "The audience of this guide is anyone who uses Python with packages." -msgstr "本指南的受众是任何使用 Python 包的人。" - -#: ../source/contribute.rst:150 -msgid "" -"Don't forget that the Python community is big and welcoming. Readers may not " -"share your age, gender, education, culture, and more, but they deserve to " -"learn about packaging just as much as you do." -msgstr "" -"不要忘记，Python 社区是很大，而且很受欢迎的。读者可能与您的年龄、性别、教育、" -"文化等不尽相同，但他们和您一样值得学习包装知识。" - -#: ../source/contribute.rst:154 -msgid "" -"In particular, keep in mind that not all people who use Python see " -"themselves as programmers. The audience of this guide includes astronomers " -"or painters or students as well as professional software developers." -msgstr "" -"特别是要记住，不是所有使用 Python 的人都把自己看作是程序员。本指南的受众包括" -"天文学家，画家或学生以及专业的软件开发人员。" - -#: ../source/contribute.rst:160 -msgid "Voice and tone" -msgstr "声音和语气" - -#: ../source/contribute.rst:162 -msgid "" -"When writing this guide, strive to write with a voice that's approachable " -"and humble, even if you have all the answers." -msgstr "" -"在撰写本指南时，即使您已经掌握了所有答案，也要努力以平易近人且谦逊的语气写" -"作。" - -#: ../source/contribute.rst:165 -msgid "" -"Imagine you're working on a Python project with someone you know to be smart " -"and skilled. You like working with them and they like working with you. That " -"person has asked you a question and you know the answer. How do you respond? " -"*That* is how you should write this guide." -msgstr "" -"想象一下，您正在和一个您知道是聪明和熟练的人一起做 Python 项目。您喜欢和他们" -"一起工作，他们也喜欢和您一起工作。那个人问了您一个问题，你知道答案。你怎么回" -"答？*这* 就是你应该如何写这个指南的方式。" - -#: ../source/contribute.rst:170 -msgid "" -"Here's a quick check: try reading aloud to get a sense for your writing's " -"voice and tone. Does it sound like something you would say or does it sound " -"like you're acting out a part or giving a speech? Feel free to use " -"contractions and don't worry about sticking to fussy grammar rules. You are " -"hereby granted permission to end a sentence in a preposition, if that's what " -"you want to end it with." -msgstr "" -"这里有一个快速检查：试着大声朗读以了解您写作的声音和语气。它听起来像您会说的" -"话，还是听起来像您在演戏或发表演讲？随意使用缩略语，不要担心拘泥于繁琐的语法" -"规则。您在此允许用介词来结束一个句子，如果这是您想结束它的话。" - -#: ../source/contribute.rst:177 -msgid "" -"When writing the guide, adjust your tone for the seriousness and difficulty " -"of the topic. If you're writing an introductory tutorial, it's OK to make a " -"joke, but if you're covering a sensitive security recommendation, you might " -"want to avoid jokes altogether." -msgstr "" -"在写指南时，根据主题的严肃性和难度调整你的语气。如果你写的是一个介绍性的教" -"程，开个玩笑是可以的，但如果你涉及的是一个敏感的安全建议，你可能要完全避免玩" -"笑。" - -#: ../source/contribute.rst:184 -msgid "Conventions and mechanics" -msgstr "公约和机制" - -#: ../source/contribute.rst:192 -msgid "**Write to the reader**" -msgstr "**写给读者**" - -#: ../source/contribute.rst:187 -msgid "" -"When giving recommendations or steps to take, address the reader as *you* or " -"use the imperative mood." -msgstr "在提出建议或采取的步骤时，您应称呼读者为 *你* 或使用命令语气。" - -#: ../source/contribute.rst:0 -msgid "Wrong: To install it, the user runs…" -msgstr "错误：要安装它，用户运行…" - -#: ../source/contribute.rst:0 -msgid "Right: You can install it by running…" -msgstr "正确：您可以通过运行...来安装它" - -#: ../source/contribute.rst:0 -msgid "Right: To install it, run…" -msgstr "正确：要安装它，请运行…" - -#: ../source/contribute.rst:198 -msgid "**State assumptions**" -msgstr "**陈述假设**" - -#: ../source/contribute.rst:195 -msgid "" -"Avoid making unstated assumptions. Reading on the web means that any page of " -"the guide may be the first page of the guide that the reader ever sees. If " -"you're going to make assumptions, then say what assumptions that you're " -"going to make." -msgstr "" -"避免做出未说明的假设。在网上阅读意味着指南的任何一页都可能是读者所看到的指南" -"的第一页。如果您要做假设，那就要说明您要做什么假设。" - -#: ../source/contribute.rst:203 -msgid "**Cross-reference generously**" -msgstr "**慷慨地交叉参考**" - -#: ../source/contribute.rst:201 -msgid "" -"The first time you mention a tool or practice, link to the part of the guide " -"that covers it, or link to a relevant document elsewhere. Save the reader a " -"search." -msgstr "" -"当你第一次提到一个工具或做法时，请链接到指南中涉及它的部分，或链接到其他地方" -"的相关文件。这样可以为读者省去搜索的麻烦。" - -#: ../source/contribute.rst:213 -msgid "**Respect naming practices**" -msgstr "**尊重命名的做法**" - -#: ../source/contribute.rst:206 -msgid "" -"When naming tools, sites, people, and other proper nouns, use their " -"preferred capitalization." -msgstr "当给工具、网站、人和其他专有名词命名时，请使用它们的首选大写字母。" - -#: ../source/contribute.rst:0 -msgid "Wrong: Pip uses…" -msgstr "错误：Pip 使用…" - -#: ../source/contribute.rst:0 -msgid "Right: pip uses…" -msgstr "正确：pip 使用…" - -#: ../source/contribute.rst:0 -msgid "Wrong: …hosted on github." -msgstr "错误：...托管在 github 上。" - -#: ../source/contribute.rst:0 -msgid "Right: …hosted on GitHub." -msgstr "正确：……托管在 GitHub 上。" - -#: ../source/contribute.rst:222 -msgid "**Use a gender-neutral style**" -msgstr "**使用中性风格**" - -#: ../source/contribute.rst:216 -msgid "" -"Often, you'll address the reader directly with *you*, *your* and *yours*. " -"Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or " -"avoid pronouns entirely." -msgstr "" -"通常，您会用 *you*、*your* 和 *yours* 来直接称呼读者。否则，请使用性别中立的" -"代词 *they*、*their* 和 *theirs* ，或者完全避免使用代词。" - -#: ../source/contribute.rst:0 -msgid "Wrong: A maintainer uploads the file. Then he…" -msgstr "错误：一个维护人员上传了文件。然后他…" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then they…" -msgstr "正确：一个维护人员上传了文件。然后他们…" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then the maintainer…" -msgstr "正确：A maintainer uploads the file. Then the maintainer…" - -#: ../source/contribute.rst:234 -msgid "**Headings**" -msgstr "**标题**" - -#: ../source/contribute.rst:225 -msgid "" -"Write headings that use words the reader is searching for. A good way to do " -"this is to have your heading complete an implied question. For example, a " -"reader might want to know *How do I install MyLibrary?* so a good heading " -"might be *Install MyLibrary*." -msgstr "" -"写标题时要使用读者正在搜索的词。一个好方法是让你的标题完成一个隐含的问题。例" -"如，读者可能想知道 *How do I install MyLibrary?*，所以一个好的标题可能是 " -"*Install MyLibrary* 。" - -#: ../source/contribute.rst:230 -msgid "" -"In section headings, use sentence case. In other words, write headings as " -"you would write a typical sentence." -msgstr "" -"在章节标题中，使用句子大小写。换句话说，要像写一个典型的句子那样写标题。" - -#: ../source/contribute.rst:0 -msgid "Wrong: Things You Should Know About Python" -msgstr "错误：Things You Should Know About Python" - -#: ../source/contribute.rst:0 -msgid "Right: Things you should know about Python" -msgstr "正确：Things you should know about Python" - -#: ../source/contribute.rst:237 -msgid "**Numbers**" -msgstr "**数字**" - -#: ../source/contribute.rst:237 -msgid "" -"In body text, write numbers one through nine as words. For other numbers or " -"numbers in tables, use numerals." -msgstr "在正文中，将数字1到9写成单词。对于其他数字或表格中的数字，使用数字。" - -#: ../source/discussions/deploying-python-applications.rst:4 -msgid "Deploying Python applications" -msgstr "部署 Python 应用程序" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Page Status" -msgstr "页面状态" - -#: ../source/discussions/deploying-python-applications.rst:6 -#: ../source/guides/index-mirrors-and-caches.rst:7 -#: ../source/guides/installing-using-linux-tools.rst:7 -#: ../source/guides/packaging-binary-extensions.rst:7 -#: ../source/guides/supporting-multiple-python-versions.rst:7 -#: ../source/guides/supporting-windows-using-appveyor.rst:5 -msgid "Incomplete" -msgstr "不完全的" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Last Reviewed" -msgstr "最后审查" - -#: ../source/discussions/deploying-python-applications.rst:7 -msgid "2014-11-11" -msgstr "2014-11-11" - -#: ../source/discussions/deploying-python-applications.rst:11 -#: ../source/discussions/install-requires-vs-requirements.rst:9 -#: ../source/guides/analyzing-pypi-package-downloads.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:22 -#: ../source/guides/index-mirrors-and-caches.rst:12 -#: ../source/guides/installing-scientific-packages.rst:9 -#: ../source/guides/packaging-binary-extensions.rst:17 -#: ../source/guides/supporting-multiple-python-versions.rst:12 -#: ../source/guides/supporting-windows-using-appveyor.rst:15 -#: ../source/overview.rst:23 ../source/specifications/core-metadata.rst:38 -#: ../source/specifications/direct-url.rst:14 -#: ../source/tutorials/installing-packages.rst:23 -msgid "Contents" -msgstr "内容" - -#: ../source/discussions/deploying-python-applications.rst:14 -msgid "Overview" -msgstr "总览" - -#: ../source/discussions/deploying-python-applications.rst:18 -msgid "Supporting multiple hardware platforms" -msgstr "支持多种硬件平台" - -#: ../source/discussions/deploying-python-applications.rst:40 -msgid "OS packaging & installers" -msgstr "操作系统包装和安装程序" - -#: ../source/discussions/deploying-python-applications.rst:52 -msgid "Windows" -msgstr "Windows 系统" - -#: ../source/discussions/deploying-python-applications.rst:61 -msgid "Pynsist" -msgstr "Pynsist" - -#: ../source/discussions/deploying-python-applications.rst:63 -msgid "" -"`Pynsist `__ is a tool that bundles Python " -"programs together with the Python-interpreter into a single installer based " -"on NSIS. In most cases, packaging only requires the user to choose a version " -"of the Python-interpreter and declare the dependencies of the program. The " -"tool downloads the specified Python-interpreter for Windows and packages it " -"with all the dependencies in a single Windows-executable installer." -msgstr "" -"`Pynsist `__ 是一个基于NSIS的单一安装程序，" -"并将 Python 程序与 Python 解释器捆绑在一起的工具。在大多数情况下，打包 " -"(packaging) 只需要用户选择 Python 解释器的版本并声明程序的依赖性 " -"(dependencies) 。该工具会下载用于 Windows 的 Python 解释器，并将其与所有依赖" -"项打包成一个可在 Windows 执行的安装程序。" - -#: ../source/discussions/deploying-python-applications.rst:70 -msgid "" -"The installed program can be started from a shortcut that the installer adds " -"to the start-menu. It uses a Python interpreter installed within its " -"application directory, independent of any other Python installation on the " -"computer." -msgstr "" -"安装的程序可以从安装程序添加到开始菜单的快捷方式启动。它使用一个安装在其应用" -"程序目录中的Python解释器，与计算机上的任何其他 Python 安装无关。" - -#: ../source/discussions/deploying-python-applications.rst:74 -msgid "" -"A big advantage of Pynsist is that the Windows packages can be built on " -"Linux. There are several examples for different kinds of programs (console, " -"GUI) in the `documentation `__. The tool is " -"released under the MIT-licence." -msgstr "" -"Pynsist 的一大优势是可以在 Linux 上构建 Windows 软件包。在`文档 `__ 中，有几个不同类型程序（控制台、GUI）的例子。该工" -"具是在 MIT 许可下发布的。" - -#: ../source/discussions/deploying-python-applications.rst:80 -msgid "Application bundles" -msgstr "应用捆绑" - -#: ../source/discussions/deploying-python-applications.rst:91 -msgid "Configuration management" -msgstr "配置管理" - -#: ../source/discussions/index.rst:4 -msgid "" -"**Discussions** are focused on providing comprehensive information about a " -"specific topic. If you're just trying to get stuff done, see :doc:`/guides/" -"index`." -msgstr "" -"**讨论 (Discussions)** 的重点是提供关于特定主题的全面信息。如果您只是想把事情" -"做好，请看 :doc:`/guides/index` 。" - -#: ../source/discussions/install-requires-vs-requirements.rst:5 -msgid "install_requires vs requirements files" -msgstr "install_requires 与 requirements files" - -#: ../source/discussions/install-requires-vs-requirements.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:382 -msgid "install_requires" -msgstr "install_requires" - -#: ../source/discussions/install-requires-vs-requirements.rst:14 -msgid "" -"``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that " -"should be used to specify what a project **minimally** needs to run " -"correctly. When the project is installed by :ref:`pip`, this is the " -"specification that is used to install its dependencies." -msgstr "" -"``install_requires`` 是一个 :ref:`setuptools` :file:`setup.py` 关键字，它应该" -"用来指定一个项目 **最小** 需要正确运行的内容。当项目由 :ref:`pip` 安装时，这" -"就是用来安装其依赖的规范。" - -#: ../source/discussions/install-requires-vs-requirements.rst:19 -msgid "" -"For example, if the project requires A and B, your ``install_requires`` " -"would be like so:" -msgstr "例如，如果项目需要 A 和 B ，您的 ``install_requires`` 会是这样的：" - -#: ../source/discussions/install-requires-vs-requirements.rst:29 -msgid "" -"Additionally, it's best practice to indicate any known lower or upper bounds." -msgstr "此外，最好的做法是指出任何已知的下限或上限。" - -#: ../source/discussions/install-requires-vs-requirements.rst:31 -msgid "" -"For example, it may be known, that your project requires at least v1 of 'A', " -"and v2 of 'B', so it would be like so:" -msgstr "" -"例如，您可能知道您的项目至少需要 'A' 的 v1 ，'B' 的 v2 ，所以它会是这样的：" - -#: ../source/discussions/install-requires-vs-requirements.rst:41 -msgid "" -"It may also be known that project A follows semantic versioning, and that v2 " -"of 'A' will indicate a break in compatibility, so it makes sense to not " -"allow v2:" -msgstr "也可能知道项目 A 遵循语义上的版本管理，而 'A' 的 v2 版将表明兼容性的中断，所以不允许v2版是有意义的：" - -#: ../source/discussions/install-requires-vs-requirements.rst:51 -msgid "" -"It is not considered best practice to use ``install_requires`` to pin " -"dependencies to specific versions, or to specify sub-dependencies (i.e. " -"dependencies of your dependencies). This is overly-restrictive, and " -"prevents the user from gaining the benefit of dependency upgrades." -msgstr "" -"使用 ``install_requires`` 将依赖关系固定在特定的版本上，或者指定子依赖关系（即您的依赖关系的依赖关系），都不是最佳做法。 " -"这是对用户的过度限制，使用户无法获得依赖性升级的好处。" - -#: ../source/discussions/install-requires-vs-requirements.rst:56 -msgid "" -"Lastly, it's important to understand that ``install_requires`` is a listing " -"of \"Abstract\" requirements, i.e just names and version restrictions that " -"don't determine where the dependencies will be fulfilled from (i.e. from " -"what index or source). The where (i.e. how they are to be made \"Concrete" -"\") is to be determined at install time using :ref:`pip` options. [1]_" -msgstr "" -"最后，重要的是要了解 ``install_requires`` " -"是“Abstract”要求的列表，即只是名称和版本限制，并不能确定从哪里满足依赖关系（即从什么索引或来源）。在安装时使用 :ref:`pip` " -"选项确定在哪里（即如何使它们“Concrete”）。 [1]_" - -#: ../source/discussions/install-requires-vs-requirements.rst:64 -#: ../source/tutorials/installing-packages.rst:460 -msgid "Requirements files" -msgstr "Requirements files" - -#: ../source/discussions/install-requires-vs-requirements.rst:66 -msgid "" -":ref:`Requirements Files ` described most simply, " -"are just a list of :ref:`pip:pip install` arguments placed into a file." -msgstr "" -":ref:`Requirements Files ` 最简单的描述，只是放在文件" -"中的 :ref:`pip:pip install` 参数列表。" - -#: ../source/discussions/install-requires-vs-requirements.rst:69 -msgid "" -"Whereas ``install_requires`` defines the dependencies for a single project, :" -"ref:`Requirements Files ` are often used to define " -"the requirements for a complete Python environment." -msgstr "" -"``install_requires`` 定义了单个项目的依赖项， :ref:`Requirements Files ` 通常用于定义完整 Python 环境的要求。" - -#: ../source/discussions/install-requires-vs-requirements.rst:73 -msgid "" -"Whereas ``install_requires`` requirements are minimal, requirements files " -"often contain an exhaustive listing of pinned versions for the purpose of " -"achieving :ref:`repeatable installations ` of a complete " -"environment." -msgstr "" -"尽管 ``install_requires`` 要求是最低限度的，但要求文件通常包含固定版本的详尽列表，目的是实现完整环境的 :ref:`" -"repeatable installations `。" - -#: ../source/discussions/install-requires-vs-requirements.rst:78 -msgid "" -"Whereas ``install_requires`` requirements are \"Abstract\", i.e. not " -"associated with any particular index, requirements files often contain pip " -"options like ``--index-url`` or ``--find-links`` to make requirements " -"\"Concrete\", i.e. associated with a particular index or directory of " -"packages. [1]_" -msgstr "" -"而 ``install_requires`` 需求是“Abstract”的，即不与任何特定索引相关联，需求文件通常包含 pip 选项，如 " -"``--index-url`` 或 ``--find-links`` 使需求“Concrete”，即与包的特定索引或目录相关联。 [1]_" - -#: ../source/discussions/install-requires-vs-requirements.rst:84 -msgid "" -"Whereas ``install_requires`` metadata is automatically analyzed by pip " -"during an install, requirements files are not, and only are used when a user " -"specifically installs them using ``python -m pip install -r``." -msgstr "" -"在安装过程中，``install_requires`` 元数据会被 pip 自动分析，而需求文件则不" -"会，而它只有在用户使用 ``python -m pip install -r`` 专门安装时才会使用。" - -#: ../source/discussions/install-requires-vs-requirements.rst:90 -msgid "" -"For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad." -"io/2013/07/setup-vs-requirement/." -msgstr "" -"关于 \"抽象 (Abstract) \"与 \"具体 (Concrete)\"要求的更多信息，请参阅 " -"https://caremad.io/2013/07/setup-vs-requirement/ 。" - -#: ../source/discussions/pip-vs-easy-install.rst:6 -msgid "pip vs easy_install" -msgstr "pip 与 easy_install" - -#: ../source/discussions/pip-vs-easy-install.rst:9 -msgid "" -":ref:`easy_install `, now `deprecated`_, was released in 2004 " -"as part of :ref:`setuptools`. It was notable at the time for installing :" -"term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing " -"dependencies." -msgstr "" -":ref:`easy_install `，现在已被弃用`_，作为 :ref:`setuptools` 的一部分于 2004 " -"年发布。当时值得注意的是，使用需求说明符从 :term:`PyPI ` 安装 :term:`" -"packages `，并自动安装依赖项。" - -#: ../source/discussions/pip-vs-easy-install.rst:14 -msgid "" -":ref:`pip` came later in 2008, as alternative to :ref:`easy_install " -"`, although still largely built on top of :ref:`setuptools` " -"components. It was notable at the time for *not* installing packages as :" -"term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' " -"packages from :term:`sdists `), and " -"introducing the idea of :ref:`Requirements Files `, " -"which gave users the power to easily replicate environments." -msgstr "" -":ref:`pip` 于 2008 年晚些时候出现，作为 :ref:`easy_install ` 的替代品，" -"尽管仍然主要构建在 :ref:`setuptools` 组件之上。当时值得注意的是*不*将软件包安装为 :term:`Eggs ` 或来自 " -":term:`Eggs `（而是简单地作为来自 :term:`sdists `），并引入 :ref:`Requirements Files ` 的想法，它使用户能够轻松复制环境。" - -#: ../source/discussions/pip-vs-easy-install.rst:22 -msgid "" -"Here's a breakdown of the important differences between pip and the " -"deprecated easy_install:" -msgstr "下面是 pip 和被废弃的 easy_install 之间的重要区别的分类：" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**pip**" -msgstr "**pip**" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**easy_install**" -msgstr "**easy_install**" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -msgid "Installs from :term:`Wheels `" -msgstr "从 :term:`Wheels ` 安装" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Yes" -msgstr "有" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:30 -#: ../source/discussions/pip-vs-easy-install.rst:32 -#: ../source/discussions/pip-vs-easy-install.rst:35 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:51 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "No" -msgstr "没有" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Uninstall Packages" -msgstr "卸载软件包" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Yes (``python -m pip uninstall``)" -msgstr "有(``python -m pip uninstall``)" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Dependency Overrides" -msgstr "依赖性覆盖" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Yes (:ref:`Requirements Files `)" -msgstr "有(:ref:`Requirements Files `)" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "List Installed Packages" -msgstr "列出已安装的软件包" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" -msgstr "有(``python -m pip list`` and ``python -m pip freeze``)" - -#: ../source/discussions/pip-vs-easy-install.rst:38 -msgid ":pep:`438` Support" -msgstr ":pep:`438` 支持" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Installation format" -msgstr "安装格式" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "'Flat' packages with :file:`egg-info` metadata." -msgstr "带有 :file:`egg-info` 元数据的“Flat”包。" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Encapsulated Egg format" -msgstr "封装的 Egg 格式" - -#: ../source/discussions/pip-vs-easy-install.rst:44 -msgid "sys.path modification" -msgstr "sys.path 修改" - -#: ../source/discussions/pip-vs-easy-install.rst:48 -msgid "Installs from :term:`Eggs `" -msgstr "从 :term:`Eggs ` 安装" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "`pylauncher support`_" -msgstr "`pylauncher 支持 `_" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "Yes [1]_" -msgstr "有[1]_" - -#: ../source/discussions/pip-vs-easy-install.rst:54 -msgid ":ref:`Multi-version Installs`" -msgstr ":ref:`Multi-version Installs`" - -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Exclude scripts during install" -msgstr "安装时排除脚本" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "per project index" -msgstr "每个项目索引" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Only in virtualenv" -msgstr "仅在 virtualenv 中" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Yes, via setup.cfg" -msgstr "有，通过 setup.cfg" - -#: ../source/discussions/pip-vs-easy-install.rst:68 -msgid "" -"https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" -"launcher" -msgstr "" -"https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" -"launcher" - -#: ../source/discussions/wheel-vs-egg.rst:5 -msgid "Wheel vs Egg" -msgstr "Wheel 与 Egg" - -#: ../source/discussions/wheel-vs-egg.rst:7 -msgid "" -":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support " -"the use case of needing an install artifact that doesn't require building or " -"compilation, which can be costly in testing and production workflows." -msgstr "" -":term:`Wheel` 和 :term:`Egg` 都是打包格式，旨在支持不需要构建或编译的安装工件" -"的使用情况，这在测试和生产工作流程中可能是昂贵的。" - -#: ../source/discussions/wheel-vs-egg.rst:11 -msgid "" -"The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas " -"the :term:`Wheel` format was introduced by :pep:`427` in 2012." -msgstr "" -":term:`Egg` 格式是由 :ref:`setuptools` 在2004年引入的，而 :term:`Wheel` 格式是由 :pep:`427` " -"在2012年引入。" - -#: ../source/discussions/wheel-vs-egg.rst:14 -msgid "" -":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." -msgstr "" -":term:`Wheel`目前被认为是 :term:`built `和 :term:`binary " -"`打包 Python 的标准。" - -#: ../source/discussions/wheel-vs-egg.rst:17 -msgid "" -"Here's a breakdown of the important differences between :term:`Wheel` and :" -"term:`Egg`." -msgstr "下面是关于 :term:`Wheel` 和 :term:`Egg` 之间的重要区别。" - -#: ../source/discussions/wheel-vs-egg.rst:20 -msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." -msgstr ":term:`Wheel` 有一个 :pep:`official PEP <427>` 。 :term:`Egg` 没有。" - -#: ../source/discussions/wheel-vs-egg.rst:22 -msgid "" -":term:`Wheel` is a :term:`distribution ` format, i.e a " -"packaging format. [1]_ :term:`Egg` was both a distribution format and a " -"runtime installation format (if left zipped), and was designed to be " -"importable." -msgstr "" -":term:`Wheel`是一种 :term:`distribution `格式，也就是一种打包格式。[1]" -"_ :term:`Egg`既是一种发行格式，也是一种运行时的安装格式（如果留下压缩包），并被设计为可导入。" - -#: ../source/discussions/wheel-vs-egg.rst:26 -msgid "" -":term:`Wheel` archives do not include .pyc files. Therefore, when the " -"distribution only contains Python files (i.e. no compiled extensions), and " -"is compatible with Python 2 and 3, it's possible for a wheel to be " -"\"universal\", similar to an :term:`sdist `." -msgstr "" -":term:`Wheel`档案不包括 .pyc 文件。因此，当发行版只包含 Python 文件（即没有编译的扩展），并且与 Python 2 和 3 " -"兼容时，wheel 有可能是 「通用」的，类似于 :term:`sdist `。" - -#: ../source/discussions/wheel-vs-egg.rst:31 -msgid "" -":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. " -"Egg used ``.egg-info``." -msgstr "" -":term:`Wheel` 使用 :pep:`PEP376-compliant <376>```.dist-info`` 目录。 Egg 使" -"用 ``.egg-info`` 。" - -#: ../source/discussions/wheel-vs-egg.rst:34 -msgid "" -":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single " -"wheel archive can indicate its compatibility with a number of Python " -"language versions and implementations, ABIs, and system architectures." -msgstr "" -":term:`Wheel`有一个 :pep:`更丰富的文件命名约定 <425>`。一个单一的 wheel 档案可以表明它与许多 Python " -"语言版本和工具、ABI 以及系统架构的兼容性。" - -#: ../source/discussions/wheel-vs-egg.rst:38 -msgid "" -":term:`Wheel` is versioned. Every wheel file contains the version of the " -"wheel specification and the implementation that packaged it." -msgstr ":term:`Wheel`是有版本的。每个 wheel 文件都包含 wheel 规范的版本和包装它的工具。" - -#: ../source/discussions/wheel-vs-egg.rst:41 -msgid "" -":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making " -"it easier to convert to other formats." -msgstr "" -":term:`Wheel` 在内部是由 `sysconfig 路径类型 `_ 组织的，因此更容易转换为其他格式。" - -#: ../source/discussions/wheel-vs-egg.rst:47 -msgid "" -"Circumstantially, in some cases, wheels can be used as an importable runtime " -"format, although :pep:`this is not officially supported at this time <427#is-" -"it-possible-to-import-python-code-directly-from-a-wheel-file>`." -msgstr "" -"在某些情况下，控制盘可以用作可导入的运行时格式，尽管：pep:`目前还没有正式支持这一格式 <427#is-it-mable-to-import-" -"python-code-directly-from-a-wheel-file>`。" - -#: ../source/glossary.rst:3 -msgid "Glossary" -msgstr "词汇表" - -#: ../source/glossary.rst:8 -msgid "Binary Distribution" -msgstr "二进制分布 （Binary Distribution）" - -#: ../source/glossary.rst:11 -msgid "" -"A specific kind of :term:`Built Distribution` that contains compiled " -"extensions." -msgstr "一种特定的术语：`Build Distribution'，包含编译的扩展。" - -#: ../source/glossary.rst:14 -msgid "Built Distribution" -msgstr "构建分布（Built Distribution）" - -#: ../source/glossary.rst:17 -msgid "" -"A :term:`Distribution ` format containing files and " -"metadata that only need to be moved to the correct location on the target " -"system, to be installed. :term:`Wheel` is such a format, whereas distutil's :" -"term:`Source Distribution ` is not, in " -"that it requires a build step before it can be installed. This format does " -"not imply that Python files have to be precompiled (:term:`Wheel` " -"intentionally does not include compiled Python files)." -msgstr "" -"一个term:`Distribution < Distribution Package >` " -"格式包含只需要移动到目标系统上正确位置的文件和元数据，即可安装。:term:` Wheel ` 是这样一种格式，而 distutil 的 :term:` " -"Source Distribution < Source Distribution (or \"sdist\")>` " -"不是，因为它需要一个构建步骤才能安装。 这种格式并不意味着必须预编译 Python 文件（:term:` Wheel ` 故意不包括编译的 " -"Python 文件）。" - -#: ../source/glossary.rst:26 -msgid "Distribution Package" -msgstr "分发软件包" - -#: ../source/glossary.rst:29 -msgid "" -"A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used " -"to distribute a :term:`Release`. The archive file is what an end-user will " -"download from the internet and install." -msgstr "" -"一个版本化的存档文件包含 Python :term:`packages `、:term:`modules " -"` 和其他用于分发:term:`Release` 的资源文件的版本化存档文件。存档文件是最终用户将从 Internet 下载并安装的文件。" - -#: ../source/glossary.rst:34 -msgid "" -"A distribution package is more commonly referred to with the single words " -"\"package\" or \"distribution\", but this guide may use the expanded term " -"when more clarity is needed to prevent confusion with an :term:`Import " -"Package` (which is also commonly called a \"package\") or another kind of " -"distribution (e.g. a Linux distribution or the Python language " -"distribution), which are often referred to with the single term " -"\"distribution\"." -msgstr "" -"分发包更常被称为“包”或“分发”，但是当需要更清楚地防止与 :term:`Import Package` " -"混淆时，本指南可能会使用扩展术语（通常也称为“包”）或另一种发行版（例如 Linux 发行版或 Python " -"语言发行版），通常用单个术语“发行版”来指代。" - -#: ../source/glossary.rst:41 -msgid "Egg" -msgstr "Egg" - -#: ../source/glossary.rst:44 -msgid "" -"A :term:`Built Distribution` format introduced by :ref:`setuptools`, which " -"is being replaced by :term:`Wheel`. For details, see `The Internal " -"Structure of Python Eggs `_ and `Python Eggs `_" -msgstr "" -":term:`Built Distribution`格式由 :ref:`setuptools`引入，并正在被 :term:`Wheel`取代。 详见`" -"Python Eggs 的内部结构`_ 和 `Python Eggs `_" - -#: ../source/glossary.rst:49 -msgid "Extension Module" -msgstr "扩展模块" - -#: ../source/glossary.rst:52 -msgid "" -"A :term:`Module` written in the low-level language of the Python " -"implementation: C/C++ for Python, Java for Jython. Typically contained in a " -"single dynamically loadable pre-compiled file, e.g. a shared object (.so) " -"file for Python extensions on Unix, a DLL (given the .pyd extension) for " -"Python extensions on Windows, or a Java class file for Jython extensions." -msgstr "" -"用 Python 实现的低级语言编写的 :term:`Module` ：C/C++ for Python，Java for " -"Jython。通常包含在单个可动态加载的预编译文件中，例如 Unix 上 Python 扩展的共享对象 (.so) 文件、Windows 上 " -"Python 扩展的 DLL（给定 .pyd 扩展）或 Jython 扩展的 Java 类文件。" - -#: ../source/glossary.rst:59 -msgid "Known Good Set (KGS)" -msgstr "已知良好集 (KGS)" - -#: ../source/glossary.rst:62 -msgid "" -"A set of distributions at specified versions which are compatible with each " -"other. Typically a test suite will be run which passes all tests before a " -"specific set of packages is declared a known good set. This term is commonly " -"used by frameworks and toolkits which are comprised of multiple individual " -"distributions." -msgstr "" -"一组相互兼容的指定版本的发行版。 通常，将运行一个测试套件，该套件在一组特定的包被声明为已知良好集之前通过所有测试。 " -"该术语通常用于由多个单独发行版组成的框架和工具包。" - -#: ../source/glossary.rst:68 -msgid "Import Package" -msgstr "导入包" - -#: ../source/glossary.rst:71 -msgid "" -"A Python module which can contain other modules or recursively, other " -"packages." -msgstr "一个Python模块，可以包含其他模块或递归地包含其他包。" - -#: ../source/glossary.rst:74 -msgid "" -"An import package is more commonly referred to with the single word \"package" -"\", but this guide will use the expanded term when more clarity is needed to " -"prevent confusion with a :term:`Distribution Package` which is also commonly " -"called a \"package\"." -msgstr "导入包通常用单个词“包”来指代，但本指南将在需要更清楚地说明时使用扩展术语，以防止与通常也称为“包”的 :term:`分发包` 混淆." - -#: ../source/glossary.rst:78 -msgid "Module" -msgstr "模块" - -#: ../source/glossary.rst:81 -msgid "" -"The basic unit of code reusability in Python, existing in one of two types: :" -"term:`Pure Module`, or :term:`Extension Module`." -msgstr "" -"Python 中代码可重用性的基本单元，存在于以下两种类型之一：:term:`Pure Module` 或 :term:`Extension " -"Module`。" - -#: ../source/glossary.rst:84 -msgid "Package Index" -msgstr "包索引 (Package Index)" - -#: ../source/glossary.rst:87 -msgid "" -"A repository of distributions with a web interface to automate :term:" -"`package ` discovery and consumption." -msgstr "一个带有 Web 界面的发行版存储库，用于自动化 :term:`package ` 发现和消费。" - -#: ../source/glossary.rst:90 -msgid "Per Project Index" -msgstr "每个项目索引（Per Project Index）" - -#: ../source/glossary.rst:93 -msgid "" -"A private or other non-canonical :term:`Package Index` indicated by a " -"specific :term:`Project` as the index preferred or required to resolve " -"dependencies of that project." -msgstr "" -"专用或其他非规范的：term:`Package Index`由特定的：term:`Project`表示，作为首选索引或解决该项目依赖关系所需的索引。" - -#: ../source/glossary.rst:97 -msgid "Project" -msgstr "项目 (Project)" - -#: ../source/glossary.rst:100 -msgid "" -"A library, framework, script, plugin, application, or collection of data or " -"other resources, or some combination thereof that is intended to be packaged " -"into a :term:`Distribution `." -msgstr "" -"数据或其他资源的库、框架、脚本、插件、应用程序或集合，或其组合，旨在打包成:term:`Distribution `。" - -#: ../source/glossary.rst:104 -msgid "" -"Since most projects create :term:`Distributions ` " -"using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:" -"`setuptools`, another practical way to define projects currently is " -"something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:" -"`setup.cfg` file at the root of the project source directory." -msgstr "" - -#: ../source/glossary.rst:110 -msgid "" -"Python projects must have unique names, which are registered on :term:`PyPI " -"`. Each project will then contain one or more :" -"term:`Releases `, and each release may comprise one or more :term:" -"`distributions `." -msgstr "" -"Python 项目必须具有独特且唯一的名称，这些名字可以在 :term:`PyPI ` 上注册。" -"然后每个项目将包含一个或多个 :term:`发布 ` ，每个版本可能包括一个或多个 :term:`套件 ` 。" - -#: ../source/glossary.rst:115 -msgid "" -"Note that there is a strong convention to name a project after the name of " -"the package that is imported to run that project. However, this doesn't have " -"to hold true. It's possible to install a distribution from the project 'foo' " -"and have it provide a package importable only as 'bar'." -msgstr "" - -#: ../source/glossary.rst:121 -msgid "Pure Module" -msgstr "纯模块 (Pure Module)" - -#: ../source/glossary.rst:124 -msgid "" -"A :term:`Module` written in Python and contained in a single ``.py`` file " -"(and possibly associated ``.pyc`` and/or ``.pyo`` files)." -msgstr "" -"一个用Python编写的 :term:`模块 `，包含在一个\".py \"文件中（可能还有相关的 ``.pyc`` 和/或者 ``." -"pyo`` 文件）。" - -#: ../source/glossary.rst:127 -msgid "Python Packaging Authority (PyPA)" -msgstr "Python 包装管理局 （PyPA）" - -#: ../source/glossary.rst:130 -msgid "" -"PyPA is a working group that maintains many of the relevant projects in " -"Python packaging. They maintain a site at https://www.pypa.io, host projects " -"on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python " -"Discourse forum `__." -msgstr "" -"PyPA 是一个工作小组，负责维护 Python 包装中的许多相关项目。他们在 https://" -"www.pypa.io，`GitHub `_ 和`Bitbucket `_ 上托管项目，并在 `distutils-sig 邮件列表 `_ 和 `Python Discourse " -"论坛 `__ 上讨论问题。" - -#: ../source/glossary.rst:139 -msgid "Python Package Index (PyPI)" -msgstr "Python 包索引 (PyPI)" - -#: ../source/glossary.rst:142 -msgid "" -"`PyPI `_ is the default :term:`Package Index` for the " -"Python community. It is open to all Python developers to consume and " -"distribute their distributions." -msgstr "" -"`PyPI `_ 是 Python 社区的默认 :term:`包索引 (Package Index) " -"` 。所有 Python 开发人员都可以使用和分发他们的发行版。" - -#: ../source/glossary.rst:145 -msgid "pypi.org" -msgstr "pypi.org" - -#: ../source/glossary.rst:148 -msgid "" -"`pypi.org `_ is the domain name for the :term:`Python " -"Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi." -"python.org``, in 2017. It is powered by :ref:`warehouse`." -msgstr "" -"`pypi.org `_ 是 :term:`Python Package Index (PyPI)` " -"的域名。它在2017年取代了旧的索引域名， ``pypi.python.org`` ，并由 :ref:`warehouse` 提供支持。" - -#: ../source/glossary.rst:152 -msgid "pyproject.toml" -msgstr "pyproject.toml" - -#: ../source/glossary.rst:155 -msgid "" -"The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." -msgstr "" - -#: ../source/glossary.rst:157 -msgid "Release" -msgstr "发行版 （Release）" - -#: ../source/glossary.rst:160 -msgid "" -"A snapshot of a :term:`Project` at a particular point in time, denoted by a " -"version identifier." -msgstr "" - -#: ../source/glossary.rst:163 -msgid "" -"Making a release may entail the publishing of multiple :term:`Distributions " -"`. For example, if version 1.0 of a project was " -"released, it could be available in both a source distribution format and a " -"Windows installer distribution format." -msgstr "" - -#: ../source/glossary.rst:168 -msgid "Requirement" -msgstr "要求 (Requirement)" - -#: ../source/glossary.rst:171 -msgid "" -"A specification for a :term:`package ` to be " -"installed. :ref:`pip`, the :term:`PYPA ` " -"recommended installer, allows various forms of specification that can all be " -"considered a \"requirement\". For more information, see the :ref:`pip:pip " -"install` reference." -msgstr "" - -#: ../source/glossary.rst:177 -msgid "Requirement Specifier" -msgstr "需求说明符" - -#: ../source/glossary.rst:180 -msgid "" -"A format used by :ref:`pip` to install packages from a :term:`Package " -"Index`. For an EBNF diagram of the format, see the `pkg_resources." -"Requirement `_ entry in the :ref:`setuptools` docs. For " -"example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the " -"project name, and the \">=1.3\" portion is the :term:`Version Specifier`" -msgstr "" - -#: ../source/glossary.rst:187 -msgid "Requirements File" -msgstr "需求文件" - -#: ../source/glossary.rst:190 -msgid "" -"A file containing a list of :term:`Requirements ` that can be " -"installed using :ref:`pip`. For more information, see the :ref:`pip` docs " -"on :ref:`pip:Requirements Files`." -msgstr "" - -#: ../source/glossary.rst:194 -#: ../source/guides/distributing-packages-using-setuptools.rst:56 -msgid "setup.py" -msgstr "setup.py" - -#: ../source/glossary.rst:195 -#: ../source/guides/distributing-packages-using-setuptools.rst:77 -msgid "setup.cfg" -msgstr "setup.cfg" - -#: ../source/glossary.rst:198 -msgid "" -"The project specification files for :ref:`distutils` and :ref:`setuptools`. " -"See also :term:`pyproject.toml`." -msgstr "" - -#: ../source/glossary.rst:201 -msgid "Source Archive" -msgstr "" - -#: ../source/glossary.rst:204 -msgid "" -"An archive containing the raw source code for a :term:`Release`, prior to " -"creation of a :term:`Source Distribution ` or :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:208 -msgid "Source Distribution (or \"sdist\")" -msgstr "源代码分发（或“sdist”）" - -#: ../source/glossary.rst:211 -msgid "" -"A :term:`distribution ` format (usually generated " -"using ``python setup.py sdist``) that provides metadata and the essential " -"source files needed for installing by a tool like :ref:`pip`, or for " -"generating a :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:216 -msgid "System Package" -msgstr "系统包 (System Package)" - -#: ../source/glossary.rst:219 -msgid "" -"A package provided in a format native to the operating system, e.g. an rpm " -"or dpkg file." -msgstr "以操作系统本地格式提供的软件包，例如 rpm 或 dpkg 文件。" - -#: ../source/glossary.rst:222 -msgid "Version Specifier" -msgstr "版本说明符 (Version Specifier)" - -#: ../source/glossary.rst:225 -msgid "" -"The version component of a :term:`Requirement Specifier`. For example, the " -"\">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full " -"specification <440#version-specifiers>` of the specifiers that Python " -"packaging currently supports. Support for PEP440 was implemented in :ref:" -"`setuptools` v8.0 and :ref:`pip` v6.0." -msgstr "" - -#: ../source/glossary.rst:231 -msgid "Virtual Environment" -msgstr "虚拟环境 (Virtual Environment)" - -#: ../source/glossary.rst:234 -msgid "" -"An isolated Python environment that allows packages to be installed for use " -"by a particular application, rather than being installed system wide. For " -"more information, see the section on :ref:`Creating and using Virtual " -"Environments`." -msgstr "" -"一个隔离的 Python 环境，允许安装软件包以供特定的应用程序使用，而不是在系统中安装。更多信息，请参见 :ref:`" -"创建和使用虚拟环境`一节。" - -#: ../source/glossary.rst:238 -msgid "Wheel" -msgstr "Wheel" - -#: ../source/glossary.rst:241 -msgid "" -"A :term:`Built Distribution` format introduced by :pep:`427`, which is " -"intended to replace the :term:`Egg` format. Wheel is currently supported " -"by :ref:`pip`." -msgstr "" -":term:`Built Distribution`格式由 :pep:`427`引入，旨在取代 :term:`Egg`格式。 Wheel 目前由 " -":ref:`pip`支持。" - -#: ../source/glossary.rst:244 -msgid "Working Set" -msgstr "工作集 (Working Set)" - -#: ../source/glossary.rst:247 -msgid "" -"A collection of :term:`distributions ` available for " -"importing. These are the distributions that are on the `sys.path` variable. " -"At most, one :term:`Distribution ` for a project is " -"possible in a working set." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:3 -msgid "Analyzing PyPI package downloads" -msgstr "分析 PyPI 软件包的下载情况" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:5 -msgid "" -"This section covers how to use the public PyPI download statistics dataset " -"to learn more about downloads of a package (or packages) hosted on PyPI. For " -"example, you can use it to discover the distribution of Python versions used " -"to download a package." -msgstr "" -"本节介绍了如何使用公共的 PyPI 下载统计数据集来了解PyPI上托管的软件包 " -"(packages) 的下载情况。例如，您可以用它来发现用于下载软件包的 Python 版本的分" -"布。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:15 -#: ../source/guides/supporting-windows-using-appveyor.rst:18 -msgid "Background" -msgstr "背景" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:17 -msgid "PyPI does not display download statistics for a number of reasons: [#]_" -msgstr "由于一些原因，PyPI 不显示下载统计数据。[#]_" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:19 -msgid "" -"**Inefficient to make work with a Content Distribution Network (CDN):** " -"Download statistics change constantly. Including them in project pages, " -"which are heavily cached, would require invalidating the cache more often, " -"and reduce the overall effectiveness of the cache." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:24 -msgid "" -"**Highly inaccurate:** A number of things prevent the download counts from " -"being accurate, some of which include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:27 -msgid "``pip``'s download cache (lowers download counts)" -msgstr "``pip`` 的下载缓存（降低下载次数）" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:28 -msgid "" -"Internal or unofficial mirrors (can both raise or lower download counts)" -msgstr "内部或非官方的镜像（既可以提高也可以降低下载量）" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:29 -msgid "Packages not hosted on PyPI (for comparisons sake)" -msgstr "未在 PyPI 上托管的软件包（为了比较）" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:30 -msgid "" -"Unofficial scripts or attempts at download count inflation (raises download " -"counts)" -msgstr "非官方的脚本或令下载量膨胀的尝试（提高下载量）" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:32 -msgid "Known historical data quality issues (lowers download counts)" -msgstr "已知的历史数据质量问题（降低了下载次数）" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:34 -msgid "" -"**Not particularly useful:** Just because a project has been downloaded a " -"lot doesn't mean it's good; Similarly just because a project hasn't been " -"downloaded a lot doesn't mean it's bad!" -msgstr "**不是特别有用：** 一个项目被下载了很多，并不意味着它是好的；同样，一个项目没有被下载很多，也不意味着它不好！" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:38 -msgid "" -"In short, because it's value is low for various reasons, and the tradeoffs " -"required to make it work are high, it has been not an effective use of " -"limited resources." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:43 -msgid "Public dataset" -msgstr "公共数据集" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:45 -msgid "" -"As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, " -"where they are stored as a public dataset." -msgstr "" -"作为替代方案，`Linehaul 项目`_ 将下载日志从 PyPI 流向 `" -"Google BigQuery`_ [#]_ ，在那里它们被存储为一个公共数据集。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:50 -msgid "Getting set up" -msgstr "开始设置" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:52 -msgid "" -"In order to use `Google BigQuery`_ to query the `public PyPI download " -"statistics dataset`_, you'll need a Google account and to enable the " -"BigQuery API on a Google Cloud Platform project. You can run the up to 1TB " -"of queries per month `using the BigQuery free tier without a credit card " -"`__" -msgstr "" -"为了使用 `Google BigQuery`_ 来查询 `公共PyPI下载统计数据集 `_ ，您需要一个 Google 账户，并在 Google Cloud Platform 上启用 BigQuery API 。" -"您可以每月运行高达 1TB 的查询 `使用 BigQuery 免费套餐，无需信用卡`__" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:58 -msgid "Navigate to the `BigQuery web UI`_." -msgstr "导航到 `BigQuery web UI`_ 。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:59 -msgid "Create a new project." -msgstr "创建一个新的项目。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:60 -msgid "" -"Enable the `BigQuery API `__." -msgstr "" -"启用`BigQuery API `__。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:63 -msgid "" -"For more detailed instructions on how to get started with BigQuery, check " -"out the `BigQuery quickstart guide `__." -msgstr "" -"关于如何开始使用 BigQuery 的更多详细说明，请查看`BigQuery 快速入门指南 `__ 。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:69 -msgid "Data schema" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:71 -msgid "" -"Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` " -"table for each download. The table contains information about what file was " -"downloaded and how it was downloaded. Some useful columns from the `table " -"schema `__ include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -msgid "Column" -msgstr "列" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/guides/using-manifest-in.rst:67 -#: ../source/specifications/core-metadata.rst:185 -msgid "Description" -msgstr "描述" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/specifications/direct-url.rst:226 -msgid "Examples" -msgstr "例子" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "timestamp" -msgstr "时间戳 (timestamp)" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "Date and time" -msgstr "日期和时间 (Date and time)" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "``2020-03-09 00:33:03 UTC``" -msgstr "``2020-03-09 00:33:03 UTC``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "file.project" -msgstr "file.project" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "Project name" -msgstr "项目名称" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "``pipenv``, ``nose``" -msgstr "``pipenv``, ``nose``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "file.version" -msgstr "file.version" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "Package version" -msgstr "包版本" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "``0.1.6``, ``1.4.2``" -msgstr "``0.1.6``, ``1.4.2``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "details.installer.name" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "Installer" -msgstr "安装程序" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "pip, `bandersnatch`_" -msgstr "pip, `bandersnatch`_" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "details.python" -msgstr "details.python" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "Python version" -msgstr "Python 版本" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "``2.7.12``, ``3.6.4``" -msgstr "``2.7.12``, ``3.6.4``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:93 -msgid "Useful queries" -msgstr "有用的查询" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:95 -msgid "" -"Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" " -"button." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:97 -msgid "" -"Note that the rows are stored in a partitioned, which helps limit the cost " -"of queries. These example queries analyze downloads from recent history by " -"filtering on the ``timestamp`` column." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:102 -msgid "Counting package downloads" -msgstr "-计算软件包的下载量" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:104 -msgid "" -"The following query counts the total number of downloads for the project " -"\"pytest\"." -msgstr "下面的查询统计了 \"pytest \" 项目的总下载次数。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:119 -#: ../source/guides/analyzing-pypi-package-downloads.rst:140 -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "num_downloads" -msgstr "num_downloads" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:121 -msgid "26190085" -msgstr "26190085" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:124 -msgid "" -"To only count downloads from pip, filter on the ``details.installer.name`` " -"column." -msgstr "要想只计算来自 pip 的下载量，可以在 ``details.installer.name`` 列上过滤。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:142 -msgid "24334215" -msgstr "24334215" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:146 -msgid "Package downloads over time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:148 -msgid "" -"To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also " -"filtering by this column reduces corresponding costs." -msgstr "要按月下载量分组，请使用 ``TIMESTAMP_TRUNC`` 函数。同时按这一栏过滤可以减少相应的费用。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -msgid "month" -msgstr "month" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "1956741" -msgstr "1956741" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "2018-01-01" -msgstr "2018-01-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2344692" -msgstr "2344692" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2017-12-01" -msgstr "2017-12-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "1730398" -msgstr "1730398" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "2017-11-01" -msgstr "2017-11-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2047310" -msgstr "2047310" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2017-10-01" -msgstr "2017-10-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "1744443" -msgstr "1744443" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "2017-09-01" -msgstr "2017-09-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "1916952" -msgstr "1916952" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "2017-08-01" -msgstr "2017-08-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:184 -msgid "Python versions over time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:186 -msgid "" -"Extract the Python version from the ``details.python`` column. Warning: This " -"query processes over 500 GB of data." -msgstr "从 ``details.python`` 列中提取 Python 版本。警告：这个查询处理超过 500GB 的数据。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "python" -msgstr "python" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "3.7" -msgstr "3.7" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "18051328726" -msgstr "18051328726" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "3.6" -msgstr "3.6" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "9635067203" -msgstr "9635067203" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "3.8" -msgstr "3.8" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "7781904681" -msgstr "7781904681" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "2.7" -msgstr "2.7" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "6381252241" -msgstr "6381252241" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "null" -msgstr "空" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "2026630299" -msgstr "2026630299" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "3.5" -msgstr "3.5" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "1894153540" -msgstr "1894153540" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:221 -msgid "Caveats" -msgstr "注意事项" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:223 -msgid "" -"In addition to the caveats listed in the background above, Linehaul suffered " -"from a bug which caused it to significantly under-report download statistics " -"prior to July 26, 2018. Downloads before this date are proportionally " -"accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total " -"numbers are lower than actual by an order of magnitude." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:231 -msgid "Additional tools" -msgstr "附加工具" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:233 -msgid "" -"Besides using the BigQuery console, there are some additional tools which " -"may be useful when analyzing download statistics." -msgstr "除了使用 BigQuery 控制台，还有一些额外的工具，在分析下载统计数据时可能很有用。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:237 -msgid "``google-cloud-bigquery``" -msgstr "``google-cloud-bigquery``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:239 -msgid "" -"You can also access the public PyPI download statistics dataset " -"programmatically via the BigQuery API and the `google-cloud-bigquery`_ " -"project, the official Python client library for BigQuery." -msgstr "" -"您也可以通过 BigQuery API 和 BigQuery 的官方 Python 客户端库 `google-cloud-bigquery`_ 项目，" -"以编程方式访问公共 PyPI 下载统计数据集。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:267 -msgid "``pypinfo``" -msgstr "``pypinfo``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:269 -msgid "" -"`pypinfo`_ is a command-line tool which provides access to the dataset and " -"can generate several useful queries. For example, you can query the total " -"number of download for a package with the command ``pypinfo package_name``." -msgstr "" -"`pypinfo`_ 是一个命令行工具，它提供对数据集的访问，并可以生成一些有用的查询。例如，你可以用 ``pypinfo package_name`` " -"命令来查询某个软件包的总下载次数。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:273 -msgid "Install `pypinfo`_ using pip." -msgstr "使用 pip 安装 `pypinfo`_ 。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:279 -msgid "Usage:" -msgstr "使用方法：" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:295 -msgid "``pandas-gbq``" -msgstr "``pandas-gbq``" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:297 -msgid "" -"The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." -msgstr "`pandas-gbq`_ 项目允许通过 `Pandas`_ 来访问查询结果。" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:301 -#: ../source/specifications/binary-distribution-format.rst:459 -msgid "References" -msgstr "参考" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:303 -msgid "" -"`PyPI Download Counts deprecation email `__" -msgstr "" -"`PyPI 下载计数的废弃电子邮件 `__" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:304 -msgid "" -"`PyPI BigQuery dataset announcement email `__" -msgstr "" -"`PyPI BigQuery 数据集公告邮件 `__" - -#: ../source/guides/creating-and-discovering-plugins.rst:3 -msgid "Creating and discovering plugins" -msgstr "创建和发现插件" - -#: ../source/guides/creating-and-discovering-plugins.rst:5 -msgid "" -"Often when creating a Python application or library you'll want the ability " -"to provide customizations or extra features via **plugins**. Because Python " -"packages can be separately distributed, your application or library may want " -"to automatically **discover** all of the plugins available." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:10 -msgid "There are three major approaches to doing automatic plugin discovery:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:12 -msgid "`Using naming convention`_." -msgstr "`使用命名惯例 `_ 。" - -#: ../source/guides/creating-and-discovering-plugins.rst:13 -msgid "`Using namespace packages`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:14 -msgid "`Using package metadata`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:18 -msgid "Using naming convention" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:20 -msgid "" -"If all of the plugins for your application follow the same naming " -"convention, you can use :func:`pkgutil.iter_modules` to discover all of the " -"top-level modules that match the naming convention. For example, `Flask`_ " -"uses the naming convention ``flask_{plugin_name}``. If you wanted to " -"automatically discover all of the Flask plugins installed:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:38 -msgid "" -"If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins " -"installed then ``discovered_plugins`` would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:48 -msgid "" -"Using naming convention for plugins also allows you to query the Python " -"Package Index's `simple API`_ for all packages that conform to your naming " -"convention." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:59 -msgid "Using namespace packages" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:61 -msgid "" -":doc:`Namespace packages ` can be used to " -"provide a convention for where to place plugins and also provides a way to " -"perform discovery. For example, if you make the sub-package ``myapp." -"plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once " -"installed, you can use :func:`pkgutil.iter_modules` to discover all modules " -"and packages installed under that namespace:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:89 -msgid "" -"Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` " -"causes it to only look for the modules directly under that namespace. For " -"example, if you have installed distributions that provide the modules " -"``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in " -"this case would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:101 -msgid "" -"This sample uses a sub-package as the namespace package (``myapp.plugins``), " -"but it's also possible to use a top-level package for this purpose (such as " -"``myapp_plugins``). How to pick the namespace to use is a matter of " -"preference, but it's not recommended to make your project's main top-level " -"package (``myapp`` in this case) a namespace package for the purpose of " -"plugins, as one bad plugin could cause the entire namespace to break which " -"would in turn make your project unimportable. For the \"namespace sub-package" -"\" approach to work, the plugin packages must omit the :file:`__init__.py` " -"for your top-level package directory (``myapp`` in this case) and include " -"the namespace-package style :file:`__init__.py` in the namespace sub-package " -"directory (``myapp/plugins``). This also means that plugins will need to " -"explicitly pass a list of packages to :func:`setup`'s ``packages`` argument " -"instead of using :func:`setuptools.find_packages`." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:115 -msgid "" -"Namespace packages are a complex feature and there are several different " -"ways to create them. It's highly recommended to read the :doc:`packaging-" -"namespace-packages` documentation and clearly document which approach is " -"preferred for plugins to your project." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:121 -msgid "Using package metadata" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:123 -msgid "" -"`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :" -"func:`setup` in :file:`setup.py` plugins can register themselves for " -"discovery." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:128 -msgid "" -"For example if you have a package named ``myapp-plugin-a`` and it includes " -"in its :file:`setup.py`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:139 -msgid "" -"Then you can discover and load all of the registered entry points by using :" -"func:`importlib.metadata.entry_points` (or the `backport`_ " -"``importlib_metadata >= 3.6`` for Python 3.6-3.9):" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:154 -msgid "" -"In this example, ``discovered_plugins`` would be a collection of type :class:" -"`importlib.metadata.EntryPoint`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:163 -msgid "" -"Now the module of your choice can be imported by executing " -"``discovered_plugins['a'].load()``." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:166 -msgid "" -"The ``entry_point`` specification in :file:`setup.py` is fairly flexible and " -"has a lot of options. It's recommended to read over the entire section on :" -"doc:`entry points ` ." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:170 -msgid "" -"Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools " -"provide support for defining entry points." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:5 -msgid "Packaging and distributing projects" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:7 -msgid "" -"This section covers the basics of how to configure, package and distribute " -"your own Python projects. It assumes that you are already familiar with the " -"contents of the :doc:`/tutorials/installing-packages` page." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:11 -msgid "" -"The section does *not* aim to cover best practices for Python project " -"development as a whole. For example, it does not provide guidance or tool " -"recommendations for version control, documentation, or testing." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:15 -msgid "" -"For more reference material, see :std:doc:`Building and Distributing " -"Packages ` in the :ref:`setuptools` docs, but note that " -"some advisory content there may be outdated. In the event of conflicts, " -"prefer the advice in the Python Packaging User Guide." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:25 -msgid "Requirements for packaging and distributing" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:26 -msgid "" -"First, make sure you have already fulfilled the :ref:`requirements for " -"installing packages `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:29 -msgid "Install \"twine\" [1]_:" -msgstr "安装 \"twine\" [1]_:" - -#: ../source/guides/distributing-packages-using-setuptools.rst:43 -msgid "" -"You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below " -"`)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:49 -msgid "Configuring your project" -msgstr "配置您的项目" - -#: ../source/guides/distributing-packages-using-setuptools.rst:53 -msgid "Initial files" -msgstr "初始文件" - -#: ../source/guides/distributing-packages-using-setuptools.rst:58 -msgid "" -"The most important file is :file:`setup.py` which exists at the root of your " -"project directory. For an example, see the `setup.py `_ in the `PyPA sample project " -"`_." -msgstr "" -"最重要的文件是 :file:`setup.py` ，它存在于您项目目录的根部。如果您想有一个例子作为参考，请参阅 `PyPA 样本项目 " -"`_ 的 `setup.py `_ 。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:63 -msgid ":file:`setup.py` serves two primary functions:" -msgstr ":file:`setup.py` 有主要有两个功能：" - -#: ../source/guides/distributing-packages-using-setuptools.rst:65 -msgid "" -"It's the file where various aspects of your project are configured. The " -"primary feature of :file:`setup.py` is that it contains a global ``setup()`` " -"function. The keyword arguments to this function are how specific details " -"of your project are defined. The most relevant arguments are explained in :" -"ref:`the section below `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:71 -msgid "" -"It's the command line interface for running various commands that relate to " -"packaging tasks. To get a listing of available commands, run ``python setup." -"py --help-commands``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:79 -msgid "" -":file:`setup.cfg` is an ini file that contains option defaults for :file:" -"`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project " -"`_." -msgstr "" -":file:`setup.cfg`是一个 ini 文件，包含 :file:`setup.py`命令的默认选项。 例如，参阅 `PyPA 样本项目 " -"`_ 中的 `setup.cfg `_ 。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:86 -msgid "README.rst / README.md" -msgstr "README.rst / README.md" - -#: ../source/guides/distributing-packages-using-setuptools.rst:88 -msgid "" -"All projects should contain a readme file that covers the goal of the " -"project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not " -"a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:" -"`long_description_content_type ` argument)." -msgstr "" -"所有项目都应该包含一个涵盖项目目标的 readme 文件。最常见的格式是带有 \"rst \" 扩展名的 `reStructuredText " -"`_ ，尽管这不是必须的；同时也支持 `Markdown " -"`_ 的多种变体（请看 ``setup()`` 的 " -":ref:`long_description_content_type ` 参数）。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:95 -msgid "" -"For an example, see `README.md `_ from the `PyPA sample project `_." -msgstr "" -"有关示例，请参阅来自` PyPA样本项目 `_ 的 `README.md " -"`_ 。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:99 -msgid "" -"Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:" -"`README.rst`, :file:`README.txt`, or :file:`README`) included in source " -"distributions by default. The built-in :ref:`distutils` library adopts this " -"behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ " -"will include a :file:`README.md` if found. If you are using setuptools, you " -"don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, " -"include it to be explicit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:108 -msgid "MANIFEST.in" -msgstr "MANIFEST.in" - -#: ../source/guides/distributing-packages-using-setuptools.rst:110 -msgid "" -"A :file:`MANIFEST.in` is needed when you need to package additional files " -"that are not automatically included in a source distribution. For details " -"on writing a :file:`MANIFEST.in` file, including a list of what's included " -"by default, see \":ref:`Using MANIFEST.in`\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:115 -msgid "" -"For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." -msgstr "" -"例如，请参阅 `PyPA 样本项目`_ 中的 `MANIFEST.in " -"`_ 。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:119 -msgid "" -":file:`MANIFEST.in` does not affect binary distributions such as wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:122 -msgid "LICENSE.txt" -msgstr "LICENSE.txt" - -#: ../source/guides/distributing-packages-using-setuptools.rst:124 -msgid "" -"Every package should include a license file detailing the terms of " -"distribution. In many jurisdictions, packages without an explicit license " -"can not be legally used or distributed by anyone other than the copyright " -"holder. If you're unsure which license to choose, you can use resources such " -"as `GitHub's Choose a License `_ or consult a " -"lawyer." -msgstr "" -"每个软件包都应该包括一个详细说明发行条款的许可证文件。在许多司法管辖区，没有明确许可证的软件包不能被版权持有人以外的任何人合法使用或分发。如果您不确定选择" -"哪种许可证，你可以使用诸如 `GitHub 的选择许可证 `_ 等资源，或者咨询律师。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:130 -msgid "" -"For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." -msgstr "" -"有关示例，请参阅 `PyPA 示例项目 `_ 中的 `" -"LICENSE.txt `" -"_ 。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:135 -msgid "" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:137 -msgid "" -"Although it's not required, the most common practice is to include your " -"Python modules and packages under a single top-level package that has the " -"same :ref:`name ` as your project, or something very close." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:141 -msgid "" -"For an example, see the `sample `_ package that's included in the `PyPA sample project " -"`_." -msgstr "" -"有关示例，请参阅 `PyPA 示例项目 `_ 中包含的 `sample " -"`_ 。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:149 -msgid "setup() args" -msgstr "setup() 参数" - -#: ../source/guides/distributing-packages-using-setuptools.rst:151 -msgid "" -"As mentioned above, the primary feature of :file:`setup.py` is that it " -"contains a global ``setup()`` function. The keyword arguments to this " -"function are how specific details of your project are defined." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:155 -msgid "" -"The most relevant arguments are explained below. Most of the snippets given " -"are taken from the `setup.py `_ contained in the `PyPA sample project `_." -msgstr "" -"最相关的参数解释如下。这里给出的大部分片段来自于 `PyPA样本项目 `_ " -"中的`setup.py `_ 。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:164 -msgid "name" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:170 -msgid "" -"This is the name of your project, determining how your project is listed on :" -"term:`PyPI `. Per :pep:`508`, valid project " -"names must:" -msgstr "" -"这是您的项目名称，这决定了您的项目如何在 :term:`PyPI ` 中列出。 根据 " -":pep:`508`，有效的项目名称必须是：" - -#: ../source/guides/distributing-packages-using-setuptools.rst:174 -msgid "" -"Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), " -"and/or periods (``.``), and" -msgstr "仅由 ASCII 字母、数字、下划线（``_``）、连字符（``-``）和/或句号（``.``）组成，并且" - -#: ../source/guides/distributing-packages-using-setuptools.rst:176 -msgid "Start & end with an ASCII letter or digit." -msgstr "以一个 ASCII 字母或数字开始和结束。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:178 -msgid "" -"Comparison of project names is case insensitive and treats arbitrarily-long " -"runs of underscores, hyphens, and/or periods as equal. For example, if you " -"register a project named ``cool-stuff``, users will be able to download it " -"or declare a dependency on it using any of the following spellings::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:190 -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "version" -msgstr "version" - -#: ../source/guides/distributing-packages-using-setuptools.rst:196 -msgid "" -"This is the current version of your project, allowing your users to " -"determine whether or not they have the latest version, and to indicate which " -"specific versions they've tested their own software against." -msgstr "这是您的项目的当前版本，允许您的用户确定他们是否有最新的版本，并指出他们对自己的软件进行过哪些具体的测试。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:200 -msgid "" -"Versions are displayed on :term:`PyPI ` for " -"each release if you publish your project." -msgstr "如果您发布了您的项目，每个版本都会显示在 :term:`PyPI `上。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:203 -msgid "" -"See :ref:`Choosing a versioning scheme` for more information on ways to use " -"versions to convey compatibility information to your users." -msgstr "" -"请参阅 :ref:`选择版本方案 `以了解更多关于如何使用版本来向您的用户传达兼容性信息。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:206 -msgid "" -"If the project code itself needs run-time access to the version, the " -"simplest way is to keep the version in both :file:`setup.py` and your code. " -"If you'd rather not duplicate the value, there are a few ways to manage " -"this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:214 -msgid "description" -msgstr "description" - -#: ../source/guides/distributing-packages-using-setuptools.rst:222 -msgid "Give a short and long description for your project." -msgstr "为您的项目提供一个简短和长的描述。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:224 -msgid "" -"These values will be displayed on :term:`PyPI ` " -"if you publish your project. On ``pypi.org``, the user interface displays " -"``description`` in the grey banner and ``long_description`` in the section " -"named \"Project Description\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:229 -msgid "" -"``description`` is also displayed in lists of projects. For example, it's " -"visible in the search results pages such as https://pypi.org/search/?" -"q=jupyter, the front-page lists of trending projects and new releases, and " -"the list of projects you maintain within your account profile (such as " -"https://pypi.org/user/jaraco/)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:235 -msgid "" -"A `content type `_ can be specified with the " -"``long_description_content_type`` argument, which can be one of ``text/" -"plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no " -"formatting, `reStructuredText (reST) `_, and the Github-flavored " -"Markdown dialect of `Markdown `_ respectively." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:245 -msgid "url" -msgstr "url" - -#: ../source/guides/distributing-packages-using-setuptools.rst:252 -msgid "Give a homepage URL for your project." -msgstr "为您的项目提供一个主页 URL 。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:256 -msgid "author" -msgstr "作者 (author)" - -#: ../source/guides/distributing-packages-using-setuptools.rst:263 -msgid "Provide details about the author." -msgstr "提供关于作者的详细信息。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:267 -msgid "license" -msgstr "license" - -#: ../source/guides/distributing-packages-using-setuptools.rst:273 -msgid "" -"The ``license`` argument doesn't have to indicate the license under which " -"your package is being released, although you may optionally do so if you " -"want. If you're using a standard, well-known license, then your main " -"indication can and should be via the ``classifiers`` argument. Classifiers " -"exist for all major open-source licenses." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:279 -msgid "" -"The \"license\" argument is more typically used to indicate differences from " -"well-known licenses, or to include your own, unique license. As a general " -"rule, it's a good idea to use a standard, well-known license, both to avoid " -"confusion and because some organizations avoid software whose license is " -"unapproved." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:287 -msgid "classifiers" -msgstr "classifiers" - -#: ../source/guides/distributing-packages-using-setuptools.rst:316 -msgid "" -"Provide a list of classifiers that categorize your project. For a full " -"listing, see https://pypi.org/classifiers/." -msgstr "提供对您的项目进行分类的分类器列表。有关完整列表，请参阅 https://pypi.org/classifiers/ 。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:319 -msgid "" -"Although the list of classifiers is often used to declare what Python " -"versions a project supports, this information is only used for searching & " -"browsing projects on PyPI, not for installing projects. To actually " -"restrict what Python versions a project can be installed on, use the :ref:" -"`python_requires` argument." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:327 -msgid "keywords" -msgstr "keywords" - -#: ../source/guides/distributing-packages-using-setuptools.rst:333 -msgid "List keywords that describe your project." -msgstr "列出描述你的项目的关键词。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:337 -msgid "project_urls" -msgstr "project_urls" - -#: ../source/guides/distributing-packages-using-setuptools.rst:349 -msgid "" -"List additional relevant URLs about your project. This is the place to link " -"to bug trackers, source repositories, or where to support package " -"development. The string of the key is the exact text that will be displayed " -"on PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:355 -msgid "packages" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:361 -msgid "" -"Set ``packages`` to a list of all :term:`packages ` in your " -"project, including their subpackages, sub-subpackages, etc. Although the " -"packages can be listed manually, ``setuptools.find_packages()`` finds them " -"automatically. Use the ``include`` keyword argument to find only the given " -"packages. Use the ``exclude`` keyword argument to omit packages that are " -"not intended to be released and installed." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:370 -msgid "py_modules" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:376 -msgid "" -"If your project contains any single-file Python modules that aren't part of " -"a package, set ``py_modules`` to a list of the names of the modules (minus " -"the ``.py`` extension) in order to make :ref:`setuptools` aware of them." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:388 -msgid "" -"\"install_requires\" should be used to specify what dependencies a project " -"minimally needs to run. When the project is installed by :ref:`pip`, this is " -"the specification that is used to install its dependencies." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:392 -msgid "" -"For more on using \"install_requires\" see :ref:`install_requires vs " -"Requirements files`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:398 -msgid "python_requires" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:400 -msgid "" -"If your project only runs on certain Python versions, setting the " -"``python_requires`` argument to the appropriate :pep:`440` version specifier " -"string will prevent :ref:`pip` from installing the project on other Python " -"versions. For example, if your package is for Python 3+ only, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:407 -msgid "" -"If your package is for Python 2.6, 2.7, and all versions of Python 3 " -"starting with 3.3, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:412 -msgid "And so on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:416 -msgid "" -"Support for this feature is relatively recent. Your project's source " -"distributions and wheels (see :ref:`Packaging Your Project`) must be built " -"using at least version 24.2.0 of :ref:`setuptools` in order for the " -"``python_requires`` argument to be recognized and the appropriate metadata " -"generated." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:422 -msgid "" -"In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the " -"``python_requires`` metadata. Users with earlier versions of pip will be " -"able to download & install projects on any Python version regardless of the " -"projects' ``python_requires`` values." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:431 -msgid "package_data" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:440 -msgid "" -"Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the " -"package’s implementation, or text files containing documentation that might " -"be of interest to programmers using the package. These files are called " -"\"package data\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:445 -msgid "" -"The value must be a mapping from package name to a list of relative path " -"names that should be copied into the package. The paths are interpreted as " -"relative to the directory containing the package." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:449 -msgid "" -"For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:457 -msgid "data_files" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:463 -msgid "" -"Although configuring :ref:`Package Data` is sufficient for most needs, in " -"some cases you may need to place data files *outside* of your :term:" -"`packages `. The ``data_files`` directive allows you to do " -"that. It is mostly useful if you need to install files which are used by " -"other programs, which may be unaware of Python packages." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:469 -msgid "" -"Each ``(directory, files)`` pair in the sequence specifies the installation " -"directory and the files to install there. The ``directory`` must be a " -"relative path (although this may change in the future, see `wheel Issue #92 " -"`_). and it is interpreted relative " -"to the installation prefix (Python’s ``sys.prefix`` for a default " -"installation; ``site.USER_BASE`` for a user installation). Each file name in " -"``files`` is interpreted relative to the :file:`setup.py` script at the top " -"of the project source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:479 -msgid "" -"For more information see the distutils section on `Installing Additional " -"Files `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:484 -msgid "" -"When installing packages as egg, ``data_files`` is not supported. So, if " -"your project uses :ref:`setuptools`, you must use ``pip`` to install it. " -"Alternatively, if you must use ``python setup.py``, then you need to pass " -"the ``--old-and-unmanageable`` option." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:491 -msgid "scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:493 -msgid "" -"Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made " -"scripts to install, the recommended approach to achieve cross-platform " -"compatibility is to use :ref:`console_scripts` entry points (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:500 -msgid "entry_points" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:509 -msgid "" -"Use this keyword to specify any plugins that your project provides for any " -"named entry points that may be defined by your project or others that you " -"depend on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:512 -msgid "" -"For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:516 -msgid "The most commonly used entry point is \"console_scripts\" (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:521 -msgid "console_scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:531 -msgid "" -"Use \"console_script\" `entry points `_ to " -"register your script interfaces. You can then let the toolchain handle the " -"work of turning these interfaces into actual scripts [2]_. The scripts will " -"be generated during the install of your :term:`distribution `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:538 -msgid "" -"For more information, see `Automatic Script Creation `_ from " -"the `setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:545 -msgid "Choosing a versioning scheme" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:548 -msgid "Standards compliance for interoperability" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:550 -msgid "" -"Different Python projects may use different versioning schemes based on the " -"needs of that particular project, but all of them are required to comply " -"with the flexible :pep:`public version scheme <440#public-version-" -"identifiers>` specified in :pep:`440` in order to be supported in tools and " -"libraries like ``pip`` and ``setuptools``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:556 -msgid "Here are some examples of compliant version numbers::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:567 -msgid "" -"To further accommodate historical variations in approaches to version " -"numbering, :pep:`440` also defines a comprehensive technique for :pep:" -"`version normalisation <440#normalization>` that maps variant spellings of " -"different version numbers to a standardised canonical form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:573 -msgid "Scheme choices" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:576 -msgid "Semantic versioning (preferred)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:578 -msgid "" -"For new projects, the recommended versioning scheme is based on `Semantic " -"Versioning `_, but adopts a different approach to " -"handling pre-releases and build metadata." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:582 -msgid "" -"The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE " -"numbering scheme, where the project author increments:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:585 -msgid "MAJOR version when they make incompatible API changes," -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:586 -msgid "" -"MINOR version when they add functionality in a backwards-compatible manner, " -"and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:587 -msgid "MAINTENANCE version when they make backwards-compatible bug fixes." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:589 -msgid "" -"Adopting this approach as a project author allows users to make use of :pep:`" -"\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= " -"X.Y`` requires at least release X.Y, but also allows any later release with " -"a matching MAJOR version." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:594 -msgid "" -"Python projects adopting semantic versioning should abide by clauses 1-8 of " -"the `Semantic Versioning 2.0.0 specification `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:598 -msgid "Date based versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:600 -msgid "" -"Semantic versioning is not a suitable choice for all projects, such as those " -"with a regular time based release cadence and a deprecation process that " -"provides warnings for a number of releases prior to removal of a feature." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:604 -msgid "" -"A key advantage of date based versioning is that it is straightforward to " -"tell how old the base feature set of a particular release is given just the " -"version number." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:607 -msgid "" -"Version numbers for date based projects typically take the form of YEAR." -"MONTH (for example, ``12.04``, ``15.10``)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:611 -msgid "Serial versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:613 -msgid "" -"This is the simplest possible versioning scheme, and consists of a single " -"number which is incremented every release." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:616 -msgid "" -"While serial versioning is very easy to manage as a developer, it is the " -"hardest to track as an end user, as serial version numbers convey little or " -"no information regarding API backwards compatibility." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:621 -msgid "Hybrid schemes" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:623 -msgid "" -"Combinations of the above schemes are possible. For example, a project may " -"combine date based versioning with serial versioning to create a YEAR.SERIAL " -"numbering scheme that readily conveys the approximate age of a release, but " -"doesn't otherwise commit to a particular release cadence within the year." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:629 -msgid "Pre-release versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:631 -msgid "" -"Regardless of the base versioning scheme, pre-releases for a given final " -"release may be published as:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:634 -msgid "zero or more dev releases (denoted with a \".devN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:635 -msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:636 -msgid "zero or more beta releases (denoted with a \".bN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:637 -msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:639 -msgid "" -"``pip`` and other modern Python package installers ignore pre-releases by " -"default when deciding which versions of dependencies to install." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:644 -msgid "Local version identifiers" -msgstr "本地版本标识符" - -#: ../source/guides/distributing-packages-using-setuptools.rst:646 -msgid "" -"Public version identifiers are designed to support distribution via :term:" -"`PyPI `. Python's software distribution tools " -"also support the notion of a :pep:`local version identifier <440#local-" -"version-identifiers>`, which can be used to identify local development " -"builds not intended for publication, or modified variants of a release " -"maintained by a redistributor." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:653 -msgid "" -"A local version identifier takes the form ``" -"+``. For example::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:661 -msgid "Working in \"development mode\"" -msgstr "在 「开发模式」(development mode) 下工作" - -#: ../source/guides/distributing-packages-using-setuptools.rst:663 -msgid "" -"Although not required, it's common to locally install your project in " -"\"editable\" or \"develop\" mode while you're working on it. This allows " -"your project to be both installed and editable in project form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:667 -msgid "Assuming you're in the root of your project directory, then run:" -msgstr "假设您现在在您的项目目录的根部，然后运行：" - -#: ../source/guides/distributing-packages-using-setuptools.rst:674 -msgid "" -"Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` " -"refers to the current working directory, so together, it means to install " -"the current directory (i.e. your project) in editable mode. This will also " -"install any dependencies declared with \"install_requires\" and any scripts " -"declared with \"console_scripts\". Dependencies will be installed in the " -"usual, non-editable mode." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:680 -msgid "" -"It's fairly common to also want to install some of your dependencies in " -"editable mode as well. For example, supposing your project requires \"foo\" " -"and \"bar\", but you want \"bar\" installed from VCS in editable mode, then " -"you could construct a requirements file like so::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:688 -msgid "" -"The first line says to install your project and any dependencies. The second " -"line overrides the \"bar\" dependency, such that it's fulfilled from VCS, " -"not PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:692 -msgid "" -"If, however, you want \"bar\" installed from a local directory in editable " -"mode, the requirements file should look like this, with the local paths at " -"the top of the file::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:697 -msgid "" -"Otherwise, the dependency will be fulfilled from PyPI, due to the " -"installation order of the requirements file. For more on requirements " -"files, see the :ref:`Requirements File ` section in " -"the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:701 -msgid "" -"Lastly, if you don't want to install any dependencies at all, you can run::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:706 -msgid "" -"For more information, see the `Development Mode `_ section of the " -"`setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:713 -msgid "Packaging your project" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:715 -msgid "" -"To have your project installable from a :term:`Package Index` like :term:" -"`PyPI `, you'll need to create a :term:" -"`Distribution ` (aka \":term:`Package `\") for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:720 -msgid "" -"Before you can build wheels and sdists for your project, you'll need to " -"install the ``build`` package:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:737 -msgid "Source distributions" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:739 -msgid "" -"Minimally, you should create a :term:`Source Distribution `:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:755 -msgid "" -"A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built " -"Distribution`), and requires a build step when installed by pip. Even if " -"the distribution is pure Python (i.e. contains no extensions), it still " -"involves a build step to build out the installation metadata from :file:" -"`setup.py` and/or :file:`setup.cfg`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:763 -msgid "Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:765 -msgid "" -"You should also create a wheel for your project. A wheel is a :term:`built " -"package ` that can be installed without needing to go " -"through the \"build\" process. Installing wheels is substantially faster for " -"the end user than installing from a source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:770 -msgid "" -"If your project is pure Python then you'll be creating a :ref:`\"Pure Python " -"Wheel\" (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:773 -msgid "" -"If your project contains compiled extensions, then you'll be creating what's " -"called a :ref:`*Platform Wheel* (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:776 -msgid "" -"If your project also supports Python 2 *and* contains no C extensions, then " -"you should create what's called a *Universal Wheel* by adding the following " -"to your :file:`setup.cfg` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:785 -msgid "" -"Only use this setting if your project does not have any C extensions *and* " -"supports Python 2 and 3." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:792 -msgid "Pure Python Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:794 -msgid "" -"*Pure Python Wheels* contain no compiled extensions, and therefore only " -"require a single Python wheel." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:797 -#: ../source/guides/distributing-packages-using-setuptools.rst:826 -msgid "To build the wheel:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:811 -msgid "" -"The ``wheel`` package will detect that the code is pure Python, and build a " -"wheel that's named such that it's usable on any Python 3 installation. For " -"details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:815 -msgid "" -"If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both " -"files for you; this is useful when you don't need multiple wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:821 -msgid "Platform Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:823 -msgid "" -"*Platform Wheels* are wheels that are specific to a certain platform like " -"Linux, macOS, or Windows, usually due to containing compiled extensions." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:841 -msgid "" -"The ``wheel`` package will detect that the code is not pure Python, and " -"build a wheel that's named such that it's only usable on the platform that " -"it was built on. For details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:847 -msgid "" -":term:`PyPI ` currently supports uploads of " -"platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. " -"Details of the latter are defined in :pep:`513`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:855 -msgid "Uploading your Project to PyPI" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:857 -msgid "" -"When you ran the command to create your distribution, a new directory ``dist/" -"`` was created under your project's root directory. That's where you'll find " -"your distribution file(s) to upload." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:861 -msgid "" -"These files are only created when you run the command to create your " -"distribution. This means that any time you change the source of your project " -"or the configuration in your :file:`setup.py` file, you will need to rebuild " -"these files again before you can distribute the changes to PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:866 -msgid "" -"Before releasing on main PyPI repo, you might prefer training with the `PyPI " -"test site `_ which is cleaned on a semi regular " -"basis. See :ref:`using-test-pypi` on how to setup your configuration in " -"order to use it." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:871 -msgid "" -"In other resources you may encounter references to using ``python setup.py " -"register`` and ``python setup.py upload``. These methods of registering and " -"uploading a package are **strongly discouraged** as it may use a plaintext " -"HTTP or unverified HTTPS connection on some Python versions, allowing your " -"username and password to be intercepted during transmission." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:877 -msgid "" -"The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to " -"ensure safety of all users, certain kinds of URLs and directives are " -"forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** " -"trying to upload your distribution, you should check to see if your brief / " -"long descriptions provided in :file:`setup.py` are valid. You can do this " -"by running :std:doc:`twine check ` on your package files::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:888 -msgid "Create an account" -msgstr "创建一个账户" - -#: ../source/guides/distributing-packages-using-setuptools.rst:890 -msgid "" -"First, you need a :term:`PyPI ` user account. " -"You can create an account `using the form on the PyPI website `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:894 -msgid "" -"Now you'll create a PyPI `API token`_ so you will be able to securely upload " -"your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:897 -msgid "" -"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " -"token`_; don't limit its scope to a particular project, since you are " -"creating a new project." -msgstr "" -"到 https://pypi.org/manage/account/#api-tokens 上创建一个新的 `API token`_ " -"；不要把其范围限制在一个特定的项目上，因为你正在创建一个新的项目。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:901 -msgid "" -"**Don't close the page until you have copied and saved the token — you won't " -"see that token again.**" -msgstr "**在复制和保存令牌之前不要关闭页面──您不会再看到该令牌。**" - -#: ../source/guides/distributing-packages-using-setuptools.rst:904 -msgid "" -"To avoid having to copy and paste the token every time you upload, you can " -"create a :file:`$HOME/.pypirc` file:" -msgstr "为了避免每次上传时都要复制和粘贴令牌，您可以创建一个 :file:`$HOME/.pypirc`文件：" - -#: ../source/guides/distributing-packages-using-setuptools.rst:913 -msgid "**Be aware that this stores your token in plaintext.**" -msgstr "**请注意，这将以明文形式存储您的令牌。**" - -#: ../source/guides/distributing-packages-using-setuptools.rst:915 -#: ../source/guides/migrating-to-pypi-org.rst:70 -#: ../source/guides/migrating-to-pypi-org.rst:109 -#: ../source/guides/using-testpypi.rst:83 -msgid "" -"For more details, see the :ref:`specification ` for :file:`.pypirc`." -msgstr "有关更多详细信息，请参见 :ref:`规格 ` for :file:`.pypirc`。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:921 -msgid "Upload your distributions" -msgstr "上传您的发行版" - -#: ../source/guides/distributing-packages-using-setuptools.rst:923 -msgid "" -"Once you have an account you can upload your distributions to :term:`PyPI " -"` using :ref:`twine`." -msgstr "" -"一旦您有了账户，您就可以使用 :ref:`twine`将你的发行版上传到 :term:`PyPI `。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:926 -msgid "" -"The process for uploading a release is the same regardless of whether or not " -"the project already exists on PyPI - if it doesn't exist yet, it will be " -"automatically created when the first release is uploaded." -msgstr "无论项目是否已经存在于 PyPI 上，上传发布版的过程都是一样的——如果它还不存在，那么在上传第一个发布版时，它将被自动创建。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:930 -msgid "" -"For the second and subsequent releases, PyPI only requires that the version " -"number of the new release differ from any previous releases." -msgstr "对于第二个及以后的版本，PyPI 只要求新版本的版本号与以前的任何版本不同。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:937 -msgid "" -"You can see if your package has successfully uploaded by navigating to the " -"URL ``https://pypi.org/project/`` where ``sampleproject`` is " -"the name of your project that you uploaded. It may take a minute or two for " -"your project to appear on the site." -msgstr "" -"您可以通过浏览 URL ``https://pypi.org/project/`` 来了解您的软件包是否已经成功上传，其中 " -"``sampleproject`` 是您上传项目的名称。您的项目可能需要一两分钟才能出现在网站上。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:944 -#: ../source/tutorials/installing-packages.rst:663 -msgid "" -"Depending on your platform, this may require root or Administrator access. :" -"ref:`pip` is currently considering changing this by `making user installs " -"the default behavior `_." -msgstr "" -"根据你的平台，这可能需要 root 或管理员权限。 :ref:`pip`目前正在考虑通过`使用户安装（user " -"installs）成为默认行为`_ 来改变这一点。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:950 -msgid "" -"Specifically, the \"console_script\" approach generates ``.exe`` files on " -"Windows, which are necessary because the OS special-cases ``.exe`` files. " -"Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for " -"Windows <397>` allow scripts to be used in many cases, but not all." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:5 -msgid "Dropping support for older Python versions" -msgstr "放弃对旧版 Python 的支持" - -#: ../source/guides/dropping-older-python-versions.rst:7 -msgid "" -"Dropping support for older Python versions is supported by the standard :ref:" -"`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:9 -msgid "" -"Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification " -"by matching the current Python runtime and comparing it with the required " -"version in the package metadata. If they do not match, it will attempt to " -"install the last package distribution that supported that Python runtime." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:12 -msgid "" -"This mechanism can be used to drop support for older Python versions, by " -"amending the \"Requires-Python\" attribute in the package metadata." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:14 -msgid "" -"This guide is specifically for users of :ref:`setuptools`, other packaging " -"tools such as ``flit`` may offer similar functionality but users will need " -"to consult relevant documentation." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:17 -msgid "Requirements" -msgstr "要求" - -#: ../source/guides/dropping-older-python-versions.rst:19 -msgid "This workflow requires that:" -msgstr "这个工作流程要求：" - -#: ../source/guides/dropping-older-python-versions.rst:21 -msgid "The publisher is using the latest version of :ref:`setuptools`," -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:22 -msgid "The latest version of :ref:`twine` is used to upload the package," -msgstr ":ref:`twine`的最新版本被用来上传软件包，" - -#: ../source/guides/dropping-older-python-versions.rst:23 -msgid "" -"The user installing the package has at least Pip 9.0, or a client that " -"supports the Metadata 1.2 specification." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:26 -msgid "Dealing with the universal wheels" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:28 -msgid "" -"Traditionally, projects providing Python code that is semantically " -"compatible with both Python 2 and Python 3, produce :term:`wheels ` " -"that have a ``py2.py3`` tag in their names. When dropping support for Python " -"2, it is important not to forget to change this tag to just ``py3``. It is " -"often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` " -"section by setting ``universal = 1`` if they use setuptools." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:36 -msgid "" -"If you use this method, either remove this option or section, or explicitly " -"set ``universal`` to ``0``:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:48 -msgid "" -"Since it is possible to override the :file:`setup.cfg` settings via CLI " -"flags, make sure that your scripts don't have ``--universal`` in your " -"package creation scripts." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:53 -msgid "Defining the Python version required" -msgstr "定义所需的 Python 版本" - -#: ../source/guides/dropping-older-python-versions.rst:56 -msgid "1. Download the newest version of Setuptools" -msgstr "1.下载最新版本的 Setuptools" - -#: ../source/guides/dropping-older-python-versions.rst:58 -msgid "" -"Ensure that before you generate source distributions or binary " -"distributions, you update Setuptools and install twine." -msgstr "确保在生成源码发行版或二进制发行版之前，更新 Setuptools 并安装 twine。" - -#: ../source/guides/dropping-older-python-versions.rst:60 -msgid "Steps:" -msgstr "步骤：" - -#: ../source/guides/dropping-older-python-versions.rst:74 -msgid "`setuptools` version should be above 24.0.0." -msgstr "`setuptools` 版本应该在 24.0.0 以上。" - -#: ../source/guides/dropping-older-python-versions.rst:77 -msgid "2. Specify the version ranges for supported Python distributions" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:79 -msgid "" -"You can specify version ranges and exclusion rules, such as at least Python " -"3. Or, Python 2.7, 3.4 and beyond." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:81 -#: ../source/specifications/core-metadata.rst:139 -#: ../source/specifications/core-metadata.rst:463 -#: ../source/specifications/core-metadata.rst:487 -#: ../source/specifications/core-metadata.rst:527 -#: ../source/specifications/core-metadata.rst:550 -#: ../source/specifications/core-metadata.rst:583 -#: ../source/specifications/core-metadata.rst:693 -#: ../source/specifications/core-metadata.rst:722 -msgid "Examples::" -msgstr "例子::" - -#: ../source/guides/dropping-older-python-versions.rst:86 -msgid "" -"The way to set those values is within the call to ``setup`` within your :" -"file:`setup.py` script. This will insert the ``Requires-Python`` metadata " -"values based on the argument you provide in ``python_requires``." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:101 -msgid "3. Validating the Metadata before publishing" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:103 -msgid "" -"Within a Python source package (the zip or the tar-gz file you download) is " -"a text file called PKG-INFO." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:105 -msgid "" -"This file is generated by Distutils or :ref:`setuptools` when it generates " -"the source package. The file contains a set of keys and values, the list of " -"keys is part of the PyPa standard metadata format." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:108 -msgid "You can see the contents of the generated file like this::" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:112 -msgid "Validate that the following is in place, before publishing the package:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:114 -msgid "" -"If you have upgraded correctly, the Metadata-Version value should be 1.2 or " -"higher." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:115 -msgid "" -"The Requires-Python field is set and matches your specification in setup.py." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:118 -msgid "4. Using Twine to publish" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:120 -msgid "" -"Twine has a number of advantages, apart from being faster it is now the " -"supported method for publishing packages." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:122 -msgid "Make sure you are using the newest version of Twine, at least 1.9." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:125 -msgid "Dropping a Python release" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:127 -msgid "" -"Once you have published a package with the Requires-Python metadata, you can " -"then make a further update removing that Python runtime from support." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:129 -msgid "It must be done in this order for the automated fallback to work." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:131 -msgid "" -"For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 " -"of your package." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:133 -msgid "" -"If you were then to update the version string to \">=3.5\", and publish a " -"new version 2.0.0 of your package, any users running Pip 9.0+ from version " -"2.7 will have version 1.0.0 of the package installed, and any >=3.5 users " -"will receive version 2.0.0." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:5 -msgid "Hosting your own simple repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:8 -msgid "" -"If you wish to host your own simple repository [1]_, you can either use a " -"software package like `devpi`_ or you can use simply create the proper " -"directory structure and use any web server that can serve static files and " -"generate an autoindex." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:13 -msgid "" -"In either case, since you'll be hosting a repository that is likely not in " -"your user's default repositories, you should instruct them in your project's " -"description to configure their installer appropriately. For example with pip:" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:29 -msgid "" -"In addition, it is **highly** recommended that you serve your repository " -"with valid HTTPS. At this time, the security of your user's installations " -"depends on all repositories using a valid HTTPS setup." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:35 -msgid "\"Manual\" repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:37 -msgid "" -"The directory layout is fairly simple, within a root directory you need to " -"create a directory for each project. This directory should be the normalized " -"name (as defined by :pep:`503`) of the project. Within each of these " -"directories simply place each of the downloadable files. If you have the " -"projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the " -"version 0.1) You should end up with a structure that looks like::" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:51 -msgid "" -"Once you have this layout, simply configure your webserver to serve the root " -"directory with autoindex enabled. For an example using the built in Web " -"server in `Twisted`_, you would simply run ``twistd -n web --path .`` and " -"then instruct users to add the URL to their installer's configuration." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:58 -msgid "" -"For complete documentation of the simple repository protocol, see :pep:`503`." -msgstr "" - -#: ../source/guides/index.rst:8 -msgid "Installing Packages:" -msgstr "" - -#: ../source/guides/index.rst:20 -msgid "Building and Publishing Projects:" -msgstr "" - -#: ../source/guides/index.rst:38 -msgid "Miscellaneous:" -msgstr "" - -#: ../source/guides/index.rst:4 -msgid "" -"**Guides** are focused on accomplishing a specific task and assume that you " -"are already familiar with the basics of Python packaging. If you're looking " -"for an introduction to packaging, see :doc:`/tutorials/index`." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:5 -msgid "Package index mirrors and caches" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:8 -#: ../source/guides/supporting-multiple-python-versions.rst:8 -msgid "2014-12-24" -msgstr "2014-12-24" - -#: ../source/guides/index-mirrors-and-caches.rst:14 -msgid "" -"Mirroring or caching of PyPI can be used to speed up local package " -"installation, allow offline work, handle corporate firewalls or just plain " -"Internet flakiness." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:17 -msgid "Three options are available in this area:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:19 -msgid "pip provides local caching options," -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:20 -msgid "" -"devpi provides higher-level caching option, potentially shared amongst many " -"users or machines, and" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:22 -msgid "" -"bandersnatch provides a local complete mirror of all PyPI :term:`packages " -"`." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:27 -msgid "Caching with pip" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:29 -msgid "" -"pip provides a number of facilities for speeding up installation by using " -"local cached copies of :term:`packages `:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:32 -msgid "" -"`Fast & local installs `_ by downloading all the requirements for a project and " -"then pointing pip at those downloaded files instead of going to PyPI." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:36 -msgid "" -"A variation on the above which pre-builds the installation files for the " -"requirements using `python -m pip wheel `_::" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:45 -msgid "Caching with devpi" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:47 -msgid "" -"devpi is a caching proxy server which you run on your laptop, or some other " -"machine you know will always be available to you. See the `devpi " -"documentation for getting started`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:55 -msgid "Complete mirror with bandersnatch" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:57 -msgid "" -"bandersnatch will set up a complete local mirror of all PyPI :term:`packages " -"` (externally-hosted packages are not mirrored). See " -"the `bandersnatch documentation for getting that going`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:63 -msgid "" -"A benefit of devpi is that it will create a mirror which includes :term:" -"`packages ` that are external to PyPI, unlike " -"bandersnatch which will only cache :term:`packages ` " -"hosted on PyPI." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:5 -msgid "Installing scientific packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:11 -msgid "" -"Scientific software tends to have more complex dependencies than most, and " -"it will often have multiple build options to take advantage of different " -"kinds of hardware, or to interoperate with different pieces of external " -"software." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:16 -msgid "" -"In particular, `NumPy `__, which provides the basis " -"for most of the software in the `scientific Python stack `__ can be configured to interoperate with " -"different FORTRAN libraries, and can take advantage of different levels of " -"vectorised instructions available in modern CPUs." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:22 -msgid "" -"Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built " -"32-bit and 64-bit binaries in the ``wheel`` format are available for all " -"major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, " -"that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, " -"so they may not provide optimal linear algebra performance." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:29 -msgid "" -"There are a number of alternative options for obtaining scientific Python " -"libraries (or any other Python libraries that require a compilation " -"environment to install from source and don't provide pre-built wheel files " -"on PyPI)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:35 -msgid "Building from source" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:37 -msgid "" -"The same complexity which makes it difficult to distribute NumPy (and many " -"of the projects that depend on it) as wheel files also make them difficult " -"to build from source yourself. However, for intrepid folks that are willing " -"to spend the time wrangling compilers and linkers for both C and FORTRAN, " -"building from source is always an option." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:45 -msgid "Linux distribution packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:47 -msgid "" -"For Linux users, the system package manager will often have pre-compiled " -"versions of various pieces of scientific software, including NumPy and other " -"parts of the scientific Python stack." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:51 -msgid "" -"If using versions which may be several months old is acceptable, then this " -"is likely to be a good option (just make sure to allow access to " -"distributions installed into the system Python when using virtual " -"environments)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:57 -msgid "Windows installers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:59 -msgid "" -"Many Python projects that don't (or can't) currently publish wheel files at " -"least publish Windows installers, either on PyPI or on their project " -"download page. Using these installers allows users to avoid the need to set " -"up a suitable environment to build extensions locally." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:64 -msgid "" -"The extensions provided in these installers are typically compatible with " -"the CPython Windows installers published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:67 -msgid "" -"For projects which don't provide their own Windows installers (and even some " -"which do), Christoph Gohlke at the University of California provides a " -"`collection of Windows installers `__. Many Python users on Windows have reported a positive experience with " -"these prebuilt versions." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:73 -msgid "" -"As with Linux system packages, the Windows installers will only install into " -"a system Python installation - they do not support installation in virtual " -"environments. Allowing access to distributions installed into the system " -"Python when using virtual environments is a common approach to working " -"around this limitation." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:79 -msgid "" -"The :term:`Wheel` project also provides a :command:`wheel convert` " -"subcommand that can convert a Windows :command:`bdist_wininst` installer to " -"a wheel." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:86 -msgid "macOS installers and package managers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:88 -msgid "" -"Similar to the situation on Windows, many projects (including NumPy) publish " -"macOS installers that are compatible with the macOS CPython binaries " -"published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:92 -msgid "" -"macOS users also have access to Linux distribution style package managers " -"such as ``MacPorts``. The SciPy site has more details on using MacPorts to " -"install the `scientific Python stack `__" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:99 -msgid "SciPy distributions" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:101 -msgid "" -"The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use " -"and update format." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:105 -msgid "" -"Some of these distributions may not be compatible with the standard ``pip`` " -"and ``virtualenv`` based toolchain." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:109 -#: ../source/key_projects.rst:596 -msgid "Spack" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:110 -msgid "" -"`Spack `_ is a flexible package manager " -"designed to support multiple versions, configurations, platforms, and " -"compilers. It was built to support the needs of large supercomputing centers " -"and scientific application teams, who must often build software many " -"different ways. Spack is not limited to Python; it can install packages for " -"``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-" -"destructive; installing a new version of one package does not break existing " -"installations, so many configurations can coexist on the same system." -msgstr "" -"`Spack `_ 是一个灵活的软件包管理器，旨在支持多个版本、配置、平台和编译器。它是为" -"了支持大型超级计算中心和科学应用团队的需要而建立的，因为他们必须经常以多种不同的方式构建软件。Spack 不限于 Python；它可以安装 ``C`` 、" -" ``C++`` 、 ``Fortran`` 、 ``R`` 和其他语言的软件包。 " -"它是非破坏性的；安装一个包的新版本不会破坏现有的安装，因此许多配置可以在同一个系统上共存。" - -#: ../source/guides/installing-scientific-packages.rst:119 -msgid "" -"Spack offers a simple but powerful syntax that allows users to specify " -"versions and configuration options concisely. Package files are written in " -"pure Python, and they are templated so that it is easy to swap compilers, " -"dependency implementations (like MPI), versions, and build options with a " -"single package file. Spack also generates *module* files so that packages " -"can be loaded and unloaded from the user's environment." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:128 -msgid "The conda cross-platform package manager" -msgstr "conda 跨平台软件包管理器" - -#: ../source/guides/installing-scientific-packages.rst:130 -msgid "" -"`Anaconda `_ is a Python distribution " -"published by Anaconda, Inc. It is a stable collection of Open Source " -"packages for big data and scientific use. As of the 5.0 release of " -"Anaconda, about 200 packages are installed by default, and a total of " -"400-500 can be installed and updated from the Anaconda repository." -msgstr "" -"`Anaconda `_ 是由 Anaconda 公司发布的 Python " -"发行版。它是一个稳定的开源软件包集合，用于大数据和科学用途。 在 Anaconda 的5.0版本中，默认安装了大约200个包，总共有400-" -"500个包可以从 Anaconda 仓库中安装和更新。" - -#: ../source/guides/installing-scientific-packages.rst:136 -msgid "" -"``conda`` is an open source (BSD licensed) package management system and " -"environment management system included in Anaconda that allows users to " -"install multiple versions of binary software packages and their " -"dependencies, and easily switch between them. It is a cross-platform tool " -"working on Windows, macOS, and Linux. Conda can be used to package up and " -"distribute all kinds of packages, it is not limited to just Python packages. " -"It has full support for native virtual environments. Conda makes " -"environments first-class citizens, making it easy to create independent " -"environments even for C libraries. It is written in Python, but is Python-" -"agnostic. Conda manages Python itself as a package, so that :command:`conda " -"update python` is possible, in contrast to pip, which only manages Python " -"packages. Conda is available in Anaconda and Miniconda (an easy-to-install " -"download with just Python and conda)." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 -msgid "Installing stand alone command line tools" -msgstr "安装独立命令行工具" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 -msgid "" -"Many packages have command line entry points. Examples of this type of " -"application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." -msgstr "" -"许多软件包都有命令行入口点。这类应用的例子有`mypy `_ ，`flake8 " -"`_ ， :ref:`pipenv`， 和`black `_ 。" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 -msgid "" -"Usually you want to be able to access these from anywhere, but installing " -"packages and their dependencies to the same global environment can cause " -"version conflicts and break dependencies the operating system has on Python " -"packages." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 -msgid "" -":ref:`pipx` solves this by creating a virtual environment for each package, " -"while also ensuring that package's applications are accessible through a " -"directory that is on your ``$PATH``. This allows each package to be upgraded " -"or uninstalled without causing conflicts with other packages, and allows you " -"to safely run the program from anywhere." -msgstr "" -":ref:`pipx`通过为每个软件包创建一个虚拟环境来解决这个问题，同时也确保软件包的应用程序可以通过您的 " -"``$PATH``上的目录访问。这允许每个软件包在升级或卸载时不会与其他软件包产生冲突，并允许您在任何地方安全地运行程序。" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 -msgid "pipx only works with Python 3.6+." -msgstr "pipx 只适用于 Python 3.6 以上版本。" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 -msgid "``pipx`` is installed with ``pip``:" -msgstr "``pipx`` 是用 ``pip`` 安装的：" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 -msgid "" -"You may need to restart your terminal for the path updates to take effect." -msgstr "您可能需要重新启动您的终端以使路径更新生效。" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 -msgid "" -"Now you can install packages with ``pipx install`` and access the package's " -"entry point(s) from anywhere." -msgstr "现在您可以用 ``pipx install`` 来安装软件包，并从任何地方访问软件包的入口点。" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 -#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 -msgid "For example" -msgstr "例如" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 -msgid "" -"To see a list of packages installed with pipx and which CLI applications are " -"available, use ``pipx list``." -msgstr "要查看用 pipx 安装的软件包列表，以及哪些命令行界面 (CLI) 应用程序可用，请使用``pipx list``。" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 -msgid "To upgrade or uninstall the package" -msgstr "要升级或卸载软件包" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 -msgid "``pipx`` can be upgraded or uninstalled with pip" -msgstr "``pipx`` 可以用 pip 升级或卸载" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 -msgid "" -"``pipx`` also allows you to install and run the latest version of a cli tool " -"in a temporary, ephemeral environment." -msgstr "``pipx`` 还允许您在一个临时的、短暂的环境中安装和运行最新版本的命令行 （cli） 工具。" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 -msgid "To see the full list of commands ``pipx`` offers, run" -msgstr "要查看 ``pipx`` 提供的全部命令列表，请运行" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 -msgid "" -"You can learn more about ``pipx`` at its homepage, https://github.com/pypa/" -"pipx." -msgstr "您可以在其主页上了解更多关于 ``pipx `` 的信息，https://github.com/pypa/pipx 。" - -#: ../source/guides/installing-using-linux-tools.rst:5 -msgid "Installing pip/setuptools/wheel with Linux Package Managers" -msgstr "用 Linux 软件包管理器安装 pip/setuptools/wheel" - -#: ../source/guides/installing-using-linux-tools.rst:8 -msgid "2015-09-17" -msgstr "2015-09-17" - -#: ../source/guides/installing-using-linux-tools.rst:11 -msgid "" -"This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:" -"`wheel` using Linux package managers." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:14 -msgid "" -"If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:" -"`installing_requirements` section instead." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:18 -msgid "" -"Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, " -"and :ref:`wheel` supported by a specific Linux Distribution to be outdated " -"by the time it's released to the public, and updates generally only occur " -"for security reasons, not for feature updates. For certain Distributions, " -"there are additional repositories that can be enabled to provide newer " -"versions. The repositories we know about are explained below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:25 -msgid "" -"Also note that it's somewhat common for Distributions to apply patches for " -"the sake of security and normalization to their own standards. In some " -"cases, this can lead to bugs or unexpected behaviors that vary from the " -"original unpatched versions. When this is known, we will make note of it " -"below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:32 -msgid "Fedora" -msgstr "Fedora" - -#: ../source/guides/installing-using-linux-tools.rst:34 -msgid "Fedora 21:" -msgstr "Fedora 21:" - -#: ../source/guides/installing-using-linux-tools.rst:36 -#: ../source/guides/installing-using-linux-tools.rst:45 -#: ../source/guides/installing-using-linux-tools.rst:124 -#: ../source/guides/installing-using-linux-tools.rst:138 -#: ../source/guides/installing-using-linux-tools.rst:158 -msgid "Python 2::" -msgstr "Python 2::" - -#: ../source/guides/installing-using-linux-tools.rst:41 -msgid "Python 3: ``sudo yum install python3 python3-wheel``" -msgstr "Python 3: ``sudo yum install python3 python3-wheel``" - -#: ../source/guides/installing-using-linux-tools.rst:43 -msgid "Fedora 22:" -msgstr "Fedora 22:" - -#: ../source/guides/installing-using-linux-tools.rst:50 -msgid "Python 3: ``sudo dnf install python3 python3-wheel``" -msgstr "Python 3: ``sudo dnf install python3 python3-wheel``" - -#: ../source/guides/installing-using-linux-tools.rst:53 -msgid "" -"To get newer versions of pip, setuptools, and wheel for Python 2, you can " -"enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:63 -msgid "CentOS/RHEL" -msgstr "CentOS/RHEL" - -#: ../source/guides/installing-using-linux-tools.rst:65 -msgid "" -"CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core " -"repositories, although :ref:`setuptools` is installed by default." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:68 -msgid "To install pip and wheel for the system Python, there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:70 -msgid "" -"Enable the `EPEL repository `_ using " -"`these instructions `__. On EPEL 6 and EPEL7, you can " -"install pip like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:77 -msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:81 -msgid "" -"Since EPEL only offers extra, non-conflicting packages, EPEL does not offer " -"setuptools, since it's in the core repository." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:85 -msgid "" -"Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:92 -msgid "To additionally upgrade setuptools, run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:97 -msgid "" -"To install pip, wheel, and setuptools, in a parallel, non-system environment " -"(using yum) then there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:101 -msgid "" -"Use the \"Software Collections\" feature to enable a parallel collection " -"that includes pip, setuptools, and wheel." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:104 -msgid "" -"For Redhat, see here: http://developers.redhat.com/products/" -"softwarecollections/overview/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:106 -msgid "For CentOS, see here: https://www.softwarecollections.org/en/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:108 -msgid "Be aware that collections may not contain the most recent versions." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:110 -msgid "" -"Enable the `IUS repository `_ and install " -"one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which " -"are kept fairly up to date." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:116 -msgid "For example, for Python 3.4 on CentOS7/RHEL7::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:122 -msgid "openSUSE" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:129 -#: ../source/guides/installing-using-linux-tools.rst:143 -#: ../source/guides/installing-using-linux-tools.rst:162 -msgid "Python 3::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:135 -msgid "Debian/Ubuntu" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:150 -msgid "" -"Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" " -"`_ by default, " -"which is a significant behavior change that can be surprising to some users." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:156 -msgid "Arch Linux" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:168 -msgid "" -"Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the " -"only option is to manually place the repo files as described." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 -msgid "Installing packages using pip and virtual environments" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 -msgid "" -"This guide discusses how to install packages using :ref:`pip` and a virtual " -"environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` " -"for Python 2. These are the lowest-level tools for managing Python packages " -"and are recommended if higher-level tools do not suit your needs." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 -msgid "" -"This doc uses the term **package** to refer to a :term:`Distribution " -"Package` which is different from an :term:`Import Package` that which is " -"used to import modules in your Python source code." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 -msgid "Installing pip" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 -msgid "" -":ref:`pip` is the reference Python package manager. It's used to install and " -"update packages. You'll need to make sure you have the latest version of pip " -"installed." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 -msgid "" -"Debian and most other distributions include a `python-pip`_ package, if you " -"want to use the Linux distribution-provided versions of pip see :doc:`/" -"guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 -msgid "" -"You can also install pip yourself to ensure you have the latest version. " -"It's recommended to use the system pip to bootstrap a user installation of " -"pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 -msgid "Afterwards, you should have the newest pip installed in your user site:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 -msgid "" -"The Python installers for Windows include pip. You should be able to access " -"pip using:" -msgstr "Windows 的 Python 安装程序包括 pip。您应该可以用以下方法访问pip：" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 -msgid "You can make sure that pip is up-to-date by running:" -msgstr "您可以通过运行以下命令来确保 pip 是最新的：" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 -msgid "Installing virtualenv" -msgstr "安装 virtualenv" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 -msgid "" -"If you are using Python 3.3 or newer, the :mod:`venv` module is the " -"preferred way to create and manage virtual environments. venv is included in " -"the Python standard library and requires no additional installation. If you " -"are using venv, you may skip this section." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 -msgid "" -":ref:`virtualenv` is used to manage Python packages for different projects. " -"Using virtualenv allows you to avoid installing Python packages globally " -"which could break system tools or other projects. You can install virtualenv " -"using pip." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 -msgid "Creating a virtual environment" -msgstr "创建一个虚拟环境" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 -msgid "" -":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to " -"manage separate package installations for different projects. They " -"essentially allow you to create a \"virtual\" isolated Python installation " -"and install packages into that virtual installation. When you switch " -"projects, you can simply create a new virtual environment and not have to " -"worry about breaking the packages installed in the other environments. It is " -"always recommended to use a virtual environment while developing Python " -"applications." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 -msgid "" -"To create a virtual environment, go to your project's directory and run " -"venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the " -"below commands." -msgstr "" -"要创建一个虚拟环境，进入您的项目目录并运行 venv 。如果您正在使用 Python2，在下面的命令中把 ``venv`` 改为 " -"``virtualenv`` 。" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 -msgid "" -"The second argument is the location to create the virtual environment. " -"Generally, you can just create this in your project and call it ``env``." -msgstr "第二个参数是创建虚拟环境的位置。一般来说，您可以直接在您的项目中创建它，并称之为 ``env`` 。" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 -msgid "venv will create a virtual Python installation in the ``env`` folder." -msgstr "venv 将在 ``env`` 文件夹中创建一个虚拟的 Python 安装。" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 -msgid "" -"You should exclude your virtual environment directory from your version " -"control system using ``.gitignore`` or similar." -msgstr "您应该使用 ``.gitignore`` 或类似的方法将您的虚拟环境目录从你的版本控制系统中排除。" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 -msgid "Activating a virtual environment" -msgstr "激活一个虚拟环境" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 -msgid "" -"Before you can start installing or using packages in your virtual " -"environment you'll need to *activate* it. Activating a virtual environment " -"will put the virtual environment-specific ``python`` and ``pip`` executables " -"into your shell's ``PATH``." -msgstr "" -"在您开始安装或使用虚拟环境中的软件包之前，你需要 *激活* 它。激活虚拟环境将把虚拟环境专用的 ``python`` 和 ``pip`` " -"可执行文件放入你的 shell 的 ``PATH`` 。" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 -msgid "" -"You can confirm you're in the virtual environment by checking the location " -"of your Python interpreter, it should point to the ``env`` directory." -msgstr "您可以通过检查您的 Python 解释器的位置来确认您在虚拟环境中，它应该指向 ``env`` 目录。" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 -msgid "" -"As long as your virtual environment is activated pip will install packages " -"into that specific environment and you'll be able to import and use packages " -"in your Python application." -msgstr "只要您的虚拟环境被激活，pip 就会将软件包安装到该特定环境中，您就可以在您的 Python 应用程序中导入和使用软件包。" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 -msgid "Leaving the virtual environment" -msgstr "离开虚拟环境" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 -msgid "" -"If you want to switch projects or otherwise leave your virtual environment, " -"simply run:" -msgstr "如果您想切换项目或以其他方式离开你的虚拟环境，只需运行：" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 -msgid "" -"If you want to re-enter the virtual environment just follow the same " -"instructions above about activating a virtual environment. There's no need " -"to re-create the virtual environment." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 -msgid "Installing packages" -msgstr "安装软件包" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 -msgid "" -"Now that you're in your virtual environment you can install packages. Let's " -"install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" -msgstr "" -"现在您在您的虚拟环境中，您可以安装软件包。让我们从 :term:`Python Package Index (PyPI)` 中安装 `Requests`" -"_ 库：" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 -msgid "" -"pip should download requests and all of its dependencies and install them:" -msgstr "pip应该下载 request 及其所有的依赖项并安装它们：" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 -msgid "Installing specific versions" -msgstr "安装特定版本" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 -msgid "" -"pip allows you to specify which version of a package to install using :term:" -"`version specifiers `. For example, to install a specific " -"version of ``requests``:" -msgstr "" -"pip 允许您使用 :term:`版本指定器 `来指定安装哪个版本的软件包。例如，要安装一个特定版本的 " -"``requests``：" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 -msgid "To install the latest ``2.x`` release of requests:" -msgstr "要安装最新的 ``2.x`` 版本的 requests：" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 -msgid "To install pre-release versions of packages, use the ``--pre`` flag:" -msgstr "要安装预发布（pre-release）版本的软件包，请使用 ``--pre`` 标志：" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 -msgid "Installing extras" -msgstr "安装附加功能" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 -msgid "" -"Some packages have optional `extras`_. You can tell pip to install these by " -"specifying the extra in brackets:" -msgstr "有些软件包有可选的 `额外功能 `_ 。你可以通过在括号中指定额外的东西来告诉 pip 安装这些东西：" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 -msgid "Installing from source" -msgstr "从源文件安装" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 -msgid "pip can install a package directly from source, for example:" -msgstr "pip 可以直接从源代码安装一个软件包，例如：" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 -msgid "" -"Additionally, pip can install packages from source in `development mode`_, " -"meaning that changes to the source directory will immediately affect the " -"installed package without needing to re-install:" -msgstr "" -"此外，pip 可以在 `开发模式 `_ " -"下从源码安装软件包，这意味着源码目录的变化将立即影响已安装的软件包，而不需要重新安装：" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 -msgid "Installing from version control systems" -msgstr "从版本控制系统进行安装" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 -msgid "" -"pip can install packages directly from their version control system. For " -"example, you can install directly from a git repository:" -msgstr "pip 可以直接从他们的版本控制系统中安装软件包。例如，你可以直接从 git 仓库中安装：" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 -msgid "" -"For more information on supported version control systems and syntax, see " -"pip's documentation on :ref:`VCS Support `." -msgstr "关于支持的版本控制系统和语法的更多信息，请参见 pip 的文档：:ref:`VCS Support ` 。" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 -#: ../source/tutorials/installing-packages.rst:569 -msgid "Installing from local archives" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 -msgid "" -"If you have a local copy of a :term:`Distribution Package`'s archive (a zip, " -"wheel, or tar file) you can install it directly with pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 -msgid "" -"If you have a directory containing archives of multiple packages, you can " -"tell pip to look for packages there and not to use the :term:`Python Package " -"Index (PyPI)` at all:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 -msgid "" -"This is useful if you are installing packages on a system with limited " -"connectivity or if you want to strictly control the origin of distribution " -"packages." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 -msgid "Using other package indexes" -msgstr "使用其他软件包的索引" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 -msgid "" -"If you want to download packages from a different index than the :term:" -"`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" -msgstr "" -"如果您想从不同的索引下载软件包，而不是 :term:`Python 软件包索引（PyPI）` ，您可以使用 ``--index-url`` 标志：" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 -msgid "" -"If you want to allow packages from both the :term:`Python Package Index " -"(PyPI)` and a separate index, you can use the ``--extra-index-url`` flag " -"instead:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 -#: ../source/tutorials/installing-packages.rst:389 -msgid "Upgrading packages" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 -msgid "" -"pip can upgrade packages in-place using the ``--upgrade`` flag. For example, " -"to install the latest version of ``requests`` and all of its dependencies:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 -msgid "Using requirements files" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 -msgid "" -"Instead of installing packages individually, pip allows you to declare all " -"dependencies in a :ref:`Requirements File `. For " -"example you could create a :file:`requirements.txt` file containing:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 -msgid "" -"And tell pip to install all of the packages in this file using the ``-r`` " -"flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 -msgid "Freezing dependencies" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 -msgid "" -"Pip can export a list of all installed packages and their versions using the " -"``freeze`` command:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 -msgid "Which will output a list of package specifiers such as:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 -msgid "" -"This is useful for creating :ref:`pip:Requirements Files` that can re-create " -"the exact versions of all packages installed in an environment." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:2 -msgid "Making a PyPI-friendly README" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:4 -msgid "" -"README files can help your users understand your project and can be used to " -"set your project's description on PyPI. This guide helps you create a README " -"in a PyPI-friendly format and include your README in your package so it " -"appears on PyPI." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:9 -msgid "Creating a README file" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:11 -msgid "" -"README files for Python projects are often named ``README``, ``README.txt``, " -"``README.rst``, or ``README.md``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:13 -msgid "" -"For your README to display properly on PyPI, choose a markup language " -"supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:16 -msgid "plain text" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:17 -msgid "" -"`reStructuredText `_ (without " -"Sphinx extensions)" -msgstr "" -"`reStructuredText `_ (没有 Sphinx 扩展)" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:18 -msgid "" -"Markdown (`GitHub Flavored Markdown `_ by " -"default, or `CommonMark `_)" -msgstr "" -"Markdown（默认情况下 `GitHub Flavored Markdown `_ " -"，或`CommonMark `_ ）" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:21 -msgid "" -"It's customary to save your README file in the root of your project, in the " -"same directory as your :file:`setup.py` file." -msgstr "通常将 README 文件保存在项目的根目录中，与 :file:`setup.py` 文件位于同一目录中。" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:25 -msgid "Including your README in your package's metadata" -msgstr "在软件包的元数据中包含您的 README" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:27 -msgid "" -"To include your README's contents as your package description, set your " -"project's ``Description`` and ``Description-Content-Type`` metadata, " -"typically in your project's :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:33 -msgid ":ref:`description-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:34 -msgid ":ref:`description-content-type-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:36 -msgid "" -"For example, to set these values in a package's :file:`setup.py` file, use " -"``setup()``'s ``long_description`` and ``long_description_content_type``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:39 -msgid "" -"Set the value of ``long_description`` to the contents (not the path) of the " -"README file itself. Set the ``long_description_content_type`` to an accepted " -"``Content-Type``-style value for your README file's markup, such as ``text/" -"plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:45 -msgid "" -"If you're using GitHub-flavored Markdown to write a project's description, " -"ensure you upgrade the following tools:" -msgstr "如果您使用 GitHub 风格的 Markdown 来写项目的描述，请确保您升级了以下工具：" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:60 -msgid "The minimum required versions of the respective tools are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:62 -msgid "``setuptools >= 38.6.0``" -msgstr "``setuptools >= 38.6.0``" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:63 -msgid "``wheel >= 0.31.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:64 -msgid "``twine >= 1.11.0``" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:66 -msgid "" -"It's recommended that you use ``twine`` to upload the project's distribution " -"packages:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:72 -msgid "" -"For example, see this :file:`setup.py` file, which reads the contents of :" -"file:`README.md` as ``long_description`` and identifies the markup as GitHub-" -"flavored Markdown:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:95 -msgid "Validating reStructuredText markup" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:97 -msgid "" -"If your README is written in reStructuredText, any invalid markup will " -"prevent it from rendering, causing PyPI to instead just show the README's " -"raw source." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:100 -msgid "" -"Note that Sphinx extensions used in docstrings, such as `directives and " -"roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```" -"\"), are not allowed here and will result in error messages like \"``Error: " -"Unknown interpreted text role \"py:func\".``\"." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:105 -msgid "" -"You can check your README for markup errors before uploading as follows:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:107 -msgid "" -"Install the latest version of `twine `_; " -"version 1.12.0 or higher is required:" -msgstr "安装最新版本的 `twine `_ ；需要1.12.0版或更高版本：" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:122 -msgid "" -"Build the sdist and wheel for your project as described under :ref:" -"`Packaging Your Project`." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:125 -msgid "Run ``twine check`` on the sdist and wheel::" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:129 -msgid "" -"This command will report any problems rendering your README. If your markup " -"renders fine, the command will output ``Checking distribution FILENAME: " -"Passed``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:4 -msgid "Migrating to PyPI.org" -msgstr "迁移到 PyPI.org" - -#: ../source/guides/migrating-to-pypi-org.rst:6 -msgid "" -":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``." -msgstr "" -":term:`pypi.org` 是新的、重写的 PyPI 版本，取代了传统的 PyPI 代码库。它是人们期望使用的 PyPI 的默认版本。这些是人们与 " -"``PyPI.org`` 互动所需的工具和流程。" - -#: ../source/guides/migrating-to-pypi-org.rst:12 -msgid "Publishing releases" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:14 -msgid "``pypi.org`` is the default upload platform as of September 2016." -msgstr "``pypi.org`` 是2016年9月起的默认上传平台。" - -#: ../source/guides/migrating-to-pypi-org.rst:16 -msgid "" -"Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. " -"As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:19 -msgid "" -"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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:22 -msgid "" -"The default upload settings switched to ``pypi.org`` in the following " -"versions:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:24 -msgid "``twine`` 1.8.0" -msgstr "``twine`` 1.8.0" - -#: ../source/guides/migrating-to-pypi-org.rst:25 -msgid "``setuptools`` 27.0.0" -msgstr "``setuptools`` 27.0.0" - -#: ../source/guides/migrating-to-pypi-org.rst:26 -msgid "Python 2.7.13 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:27 -msgid "Python 3.4.6 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:28 -msgid "Python 3.5.3 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:29 -msgid "Python 3.6.0 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:31 -msgid "" -"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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:48 -msgid "" -"Then simply delete the line starting with ``repository`` and you will use " -"your upload tool's default URL." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:51 -msgid "" -"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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:67 -msgid "" -"(``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.)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:73 -msgid "Registering package names & metadata" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:75 -msgid "" -"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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:79 -msgid "" -"As a result, attempting explicit registration after switching to using PyPI." -"org for uploads will give the following error message::" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:84 -msgid "" -"The solution is to skip the registration step, and proceed directly to " -"uploading artifacts." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:89 -#: ../source/guides/using-testpypi.rst:5 -msgid "Using TestPyPI" -msgstr "使用 TestPyPI" - -#: ../source/guides/migrating-to-pypi-org.rst:91 -msgid "" -"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:" -msgstr "" -"传统的 TestPyPI (testpypi.python.org) 不再可用；请使用 `test.pypi.org `_ 代替。如果您使用 TestPyPI ，您必须更新您的 :file:`$HOME/.pypirc` 以处理 TestPyPI " -"的新位置，例如，用 ``https://test.pypi.org/legacy/`` 替换 ``https://testpypi.python.org/" -"pypi`` ：" - -#: ../source/guides/migrating-to-pypi-org.rst:113 -msgid "Registering new user accounts" -msgstr "注册新的用户账户" - -#: ../source/guides/migrating-to-pypi-org.rst:115 -msgid "" -"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." -msgstr "" -"为了帮助减轻针对 PyPI 的垃圾邮件攻击，通过 ``pypi.python.org`` 的新用户注册已于 **2018年2月20日** " -"**关闭**。在``pypi.org``的新用户注册是开放的。" - -#: ../source/guides/migrating-to-pypi-org.rst:121 -msgid "Browsing packages" -msgstr "浏览软件包" - -#: ../source/guides/migrating-to-pypi-org.rst:123 -msgid "" -"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." -msgstr "" -"虽然 ``pypi.python.org`` 仍可能用于其他 PyPA 文档的链接中使用，但浏览软件包的默认界面是 ``pypi.org`` 。" -"pypi.python.org 这个域名现在会重定向到 pypi.org ，并可能在未来某个时候被禁用。" - -#: ../source/guides/migrating-to-pypi-org.rst:130 -msgid "Downloading packages" -msgstr "下载软件包" - -#: ../source/guides/migrating-to-pypi-org.rst:132 -msgid "``pypi.org`` is the default host for downloading packages." -msgstr "``pypi.org`` 是下载软件包的默认主机。" - -#: ../source/guides/migrating-to-pypi-org.rst:135 -msgid "Managing published packages and releases" -msgstr "管理已发布的软件包和版本" - -#: ../source/guides/migrating-to-pypi-org.rst:137 -msgid "" -"``pypi.org`` provides a fully functional interface for logged in users to " -"manage their published packages and releases." -msgstr "``pypi.org`` 为登录用户提供了一个全功能的界面来管理他们发布的软件包和版本。" - -#: ../source/guides/multi-version-installs.rst:5 -msgid "Multi-version installs" -msgstr "多版本安装" - -#: ../source/guides/multi-version-installs.rst:8 -msgid "" -"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``)." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:13 -msgid "" -"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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:19 -msgid "" -"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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:31 -msgid "" -"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 ``python -c ''`` to invoke the application's main " -"entry point directly." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:38 -msgid "" -"Refer to the `pkg_resources documentation `__ for more details." -msgstr "" -"有关更多详细信息，请参阅 `pkg_resources 文档 `__ 。" - -#: ../source/guides/packaging-binary-extensions.rst:5 -msgid "Packaging binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:8 -msgid "2013-12-08" -msgstr "2013-12-08" - -#: ../source/guides/packaging-binary-extensions.rst:10 -msgid "" -"One of the features of the CPython reference interpreter is that, in " -"addition to allowing the execution of Python code, it also exposes a rich C " -"API for use by other software. One of the most common uses of this C API is " -"to create importable C extensions that allow things which aren't always easy " -"to achieve in pure Python code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:20 -msgid "An overview of binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:23 -msgid "Use cases" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:25 -msgid "" -"The typical use cases for binary extensions break down into just three " -"conventional categories:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:28 -msgid "" -"**accelerator modules**: these modules are completely self-contained, and " -"are created solely to run faster than the equivalent pure Python code runs " -"in CPython. Ideally, accelerator modules will always have a pure Python " -"equivalent to use as a fallback if the accelerated version isn't available " -"on a given system. The CPython standard library makes extensive use of " -"accelerator modules. *Example*: When importing ``datetime``, Python falls " -"back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not " -"available." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:39 -msgid "" -"**wrapper modules**: these modules are created to expose existing C " -"interfaces to Python code. They may either expose the underlying C interface " -"directly, or else expose a more \"Pythonic\" API that makes use of Python " -"language features to make the API easier to use. The CPython standard " -"library makes extensive use of wrapper modules. *Example*: `functools.py " -"`_ is a " -"Python module wrapper for `_functoolsmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:47 -msgid "" -"**low-level system access**: these modules are created to access lower level " -"features of the CPython runtime, the operating system, or the underlying " -"hardware. Through platform specific code, extension modules may achieve " -"things that aren't possible in pure Python code. A number of CPython " -"standard library modules are written in C in order to access interpreter " -"internals that aren't exposed at the language level. *Example*: ``sys``, " -"which comes from `sysmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:56 -msgid "" -"One particularly notable feature of C extensions is that, when they don't " -"need to call back into the interpreter runtime, they can release CPython's " -"global interpreter lock around long-running operations (regardless of " -"whether those operations are CPU or IO bound)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:61 -msgid "" -"Not all extension modules will fit neatly into the above categories. The " -"extension modules included with NumPy, for example, span all three use cases " -"- they move inner loops to C for speed reasons, wrap external libraries " -"written in C, FORTRAN and other languages, and use low level system " -"interfaces for both CPython and the underlying operation system to support " -"concurrent execution of vectorised operations and to tightly control the " -"exact memory layout of created objects." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:71 -msgid "Disadvantages" -msgstr "缺点" - -#: ../source/guides/packaging-binary-extensions.rst:73 -msgid "" -"The main disadvantage of using binary extensions is the fact that it makes " -"subsequent distribution of the software more difficult. One of the " -"advantages of using Python is that it is largely cross platform, and the " -"languages used to write extension modules (typically C or C++, but really " -"any language that can bind to the CPython C API) typically require that " -"custom binaries be created for different platforms." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:80 -msgid "This means that binary extensions:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:82 -msgid "" -"require that end users be able to either build them from source, or else " -"that someone publish pre-built binaries for common platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:85 -msgid "" -"may not be compatible with different builds of the CPython reference " -"interpreter" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:88 -msgid "" -"often will not work correctly with alternative interpreters such as PyPy, " -"IronPython or Jython" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:91 -msgid "" -"if handcoded, make maintenance more difficult by requiring that maintainers " -"be familiar not only with Python, but also with the language used to create " -"the binary extension, as well as with the details of the CPython C API." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:96 -msgid "" -"if a pure Python fallback implementation is provided, make maintenance more " -"difficult by requiring that changes be implemented in two places, and " -"introducing additional complexity in the test suite to ensure both versions " -"are always executed." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:101 -msgid "" -"Another disadvantage of relying on binary extensions is that alternative " -"import mechanisms (such as the ability to import modules directly from " -"zipfiles) often won't work for extension modules (as the dynamic loading " -"mechanisms on most platforms can only load libraries from disk)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:108 -msgid "Alternatives to handcoded accelerator modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:110 -msgid "" -"When extension modules are just being used to make code run faster (after " -"profiling has identified the code where the speed increase is worth " -"additional maintenance effort), a number of other alternatives should also " -"be considered:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:115 -msgid "" -"look for existing optimised alternatives. The CPython standard library " -"includes a number of optimised data structures and algorithms (especially in " -"the builtins and the ``collections`` and ``itertools`` modules). The Python " -"Package Index also offers additional alternatives. Sometimes, the " -"appropriate choice of standard library or third party module can avoid the " -"need to create your own accelerator module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:122 -msgid "" -"for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython " -"runtime. The main barrier to adopting PyPy is typically reliance on other " -"binary extension modules - while PyPy does emulate the CPython C API, " -"modules that rely on that cause problems for the PyPy JIT, and the emulation " -"layer can often expose latent defects in extension modules that CPython " -"currently tolerates (frequently around reference counting errors - an object " -"having one live reference instead of two often won't break anything, but no " -"references instead of one is a major problem)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:132 -msgid "" -"`Cython `__ is a mature static compiler that can compile " -"most Python code to C extension modules. The initial compilation provides " -"some speed increases (by bypassing the CPython interpreter layer), and " -"Cython's optional static typing features can offer additional opportunities " -"for speed increases. Using Cython still has the disadvantage of increasing " -"the complexity of distributing the resulting application, but has the " -"benefit of having a reduced barrier to entry for Python programmers " -"(relative to other languages like C or C++)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:141 -msgid "" -"`Numba `__ is a newer tool, created by members of " -"the scientific Python community, that aims to leverage LLVM to allow " -"selective compilation of pieces of a Python application to native machine " -"code at runtime. It requires that LLVM be available on the system where the " -"code is running, but can provide significant speed increases, especially for " -"operations that are amenable to vectorisation." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:150 -msgid "Alternatives to handcoded wrapper modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:152 -msgid "" -"The C ABI (Application Binary Interface) is a common standard for sharing " -"functionality between multiple applications. One of the strengths of the " -"CPython C API (Application Programming Interface) is allowing Python users " -"to tap into that functionality. However, wrapping modules by hand is quite " -"tedious, so a number of other alternative approaches should be considered." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:158 -msgid "" -"The approaches described below don't simplify the distribution case at all, " -"but they *can* significantly reduce the maintenance burden of keeping " -"wrapper modules up to date." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:162 -msgid "" -"In addition to being useful for the creation of accelerator modules, `Cython " -"`__ is also useful for creating wrapper modules for C or " -"C++. It still involves wrapping the interfaces by hand, however, and is very " -"repetitive, so may not be a good choice for wrapping large APIs." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:168 -msgid "" -"`pybind11 `__ is a pure C++11 library that " -"provides a clean C++ interface to the CPython (and PyPy) C API. It does not " -"require a pre-processing step; it is written entirely in templated C++. " -"Helpers are included for Setuptools or CMake builds. It was based on `Boost." -"Python `__, but doesn't require the Boost libraries or BJam." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:175 -msgid "" -"`cffi `__ is a project created by some of the " -"PyPy developers to make it straightforward for developers that already know " -"both Python and C to expose their C modules to Python applications. It also " -"makes it relatively straightforward to wrap a C module based on its header " -"files, even if you don't know C yourself." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:181 -msgid "" -"One of the key advantages of ``cffi`` is that it is compatible with the PyPy " -"JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing " -"JIT optimisations." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:185 -msgid "" -"`SWIG `__ is a wrapper interface generator that allows " -"a variety of programming languages, including Python, to interface with C " -"and C++ code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:189 -msgid "" -"The standard library's ``ctypes`` module, while useful for getting access to " -"C level interfaces when header information isn't available, suffers from the " -"fact that it operates solely at the C ABI level, and thus has no automatic " -"consistency checking between the interface actually being exported by the " -"library and the one declared in the Python code. By contrast, the above " -"alternatives are all able to operate at the C *API* level, using C header " -"files to ensure consistency between the interface exported by the library " -"being wrapped and the one expected by the Python wrapper module. While " -"``cffi`` *can* operate directly at the C ABI level, it suffers from the same " -"interface inconsistency problems as ``ctypes`` when it is used that way." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:203 -msgid "Alternatives for low level system access" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:205 -msgid "" -"For applications that need low level system access (regardless of the " -"reason), a binary extension module often *is* the best way to go about it. " -"This is particularly true for low level access to the CPython runtime " -"itself, since some operations (like releasing the Global Interpreter Lock) " -"are simply invalid when the interpreter is running code, even if a module " -"like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API " -"interfaces." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:213 -msgid "" -"For cases where the extension module is manipulating the underlying " -"operating system or hardware (rather than the CPython runtime), it may " -"sometimes be better to just write an ordinary C library (or a library in " -"another systems programming language like C++ or Rust that can export a C " -"compatible ABI), and then use one of the wrapping techniques described above " -"to make the interface available as an importable Python module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:222 -msgid "Implementing binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:224 -msgid "" -"The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in " -"C `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:241 -msgid "Building binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:244 -msgid "Building extensions for multiple platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:246 -msgid "" -"If you plan to distribute your extension, you should provide :term:`wheels " -"` for all the platforms you intend to support. For most extensions, " -"this is at least one package per Python version times the number of OS and " -"architectures you support. These are usually built on continuous " -"integration (CI) systems. There are tools to help you build highly " -"redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:" -"`multibuild`." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:256 -msgid "Binary extensions for Windows" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:258 -msgid "" -"Before it is possible to build a binary extension, it is necessary to ensure " -"that you have a suitable compiler available. On Windows, Visual C is used to " -"build the official CPython interpreter, and should be used to build " -"compatible binary extensions." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:263 -msgid "" -"Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio " -"2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older " -"versions of Visual Studio are no longer easily available from Microsoft, so " -"for versions of Python prior to 3.5, the compilers must be obtained " -"differently if you do not already have a copy of the relevant version of " -"Visual Studio." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:269 -msgid "" -"To set up a build environment for binary extensions, the steps are as " -"follows:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:271 -msgid "For Python 2.7" -msgstr "适用于 Python 2.7" - -#: ../source/guides/packaging-binary-extensions.rst:273 -msgid "" -"Install \"Visual C++ Compiler Package for Python 2.7\", which is available " -"from `Microsoft's website `__." -msgstr "" -"安装 \"Visual C++ Compiler Package for Python 2.7\"，它可以从 `微软的网站 `__ 获得。" - -#: ../source/guides/packaging-binary-extensions.rst:276 -msgid "" -"Use (a recent version of) setuptools in your setup.py (pip will do this for " -"you, in any case)." -msgstr "在您的 setup.py 中使用（最新版本的）setuptools（无论如何，pip 会帮你做这个）。" - -#: ../source/guides/packaging-binary-extensions.rst:278 -#: ../source/guides/packaging-binary-extensions.rst:288 -#: ../source/guides/packaging-binary-extensions.rst:295 -msgid "Done." -msgstr "完成了。" - -#: ../source/guides/packaging-binary-extensions.rst:280 -msgid "For Python 3.4" -msgstr "适用于Python 3.4" - -#: ../source/guides/packaging-binary-extensions.rst:282 -msgid "" -"Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is " -"available from `Microsoft's website `__." -msgstr "" -"安装 \"Windows SDK for Windows 7 and .NET Framework 4\"（v7." -"1），可从`微软网站`__ " -"获得。" - -#: ../source/guides/packaging-binary-extensions.rst:285 -msgid "" -"Work from an SDK command prompt (with the environment variables set, and the " -"SDK on PATH)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:287 -msgid "Set DISTUTILS_USE_SDK=1" -msgstr "Set DISTUTILS_USE_SDK=1" - -#: ../source/guides/packaging-binary-extensions.rst:290 -msgid "For Python 3.5" -msgstr "适用于 Python 3.5" - -#: ../source/guides/packaging-binary-extensions.rst:292 -msgid "" -"Install `Visual Studio 2015 Community Edition `__ (or any later version, " -"when these are released)." -msgstr "" -"安装`Visual Studio 2015 社区版 `__ （或任何后来的版本，当这些版本发布时）。" - -#: ../source/guides/packaging-binary-extensions.rst:297 -msgid "" -"Note that from Python 3.5 onwards, Visual Studio works in a backward " -"compatible way, which means that any future version of Visual Studio will be " -"able to build Python extensions for all Python versions from 3.5 onwards." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:301 -msgid "" -"Building with the recommended compiler on Windows ensures that a compatible " -"C library is used throughout the Python process." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:305 -msgid "Binary extensions for Linux" -msgstr "Linux 的二进制扩展" - -#: ../source/guides/packaging-binary-extensions.rst:307 -msgid "" -"Linux binaries must use a sufficiently old glibc to be compatible with older " -"distributions. The `manylinux `_ Docker " -"images provide a build environment with a glibc old enough to support most " -"current Linux distributions on common architectures." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:313 -msgid "Binary extensions for macOS" -msgstr "macOS 的二进制扩展" - -#: ../source/guides/packaging-binary-extensions.rst:315 -msgid "" -"Binary compatibility on macOS is determined by the target minimum deployment " -"system, e.g. *10.9*, which is often specified with the " -"``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries " -"on macOS. When building with setuptools / distutils, the deployment target " -"is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For " -"common deployment targets for macOS Python distributions, see the `MacPython " -"Spinning Wheels wiki `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:325 -msgid "Publishing binary extensions" -msgstr "发布二进制扩展" - -#: ../source/guides/packaging-binary-extensions.rst:327 -msgid "" -"For interim guidance on this topic, see the discussion in `this issue " -"`_." -msgstr "" -"关于这个主题的临时指导，请参见 `这个问题`_ 中的讨论。" - -#: ../source/guides/packaging-binary-extensions.rst:343 -msgid "Additional resources" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:345 -msgid "" -"Cross-platform development and distribution of extension modules is a " -"complex topic, so this guide focuses primarily on providing pointers to " -"various tools that automate dealing with the underlying technical " -"challenges. The additional resources in this section are instead intended " -"for developers looking to understand more about the underlying binary " -"interfaces that those systems rely on at runtime." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:352 -msgid "Cross-platform wheel generation with scikit-build" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:354 -msgid "" -"The `scikit-build `_ package " -"helps abstract cross-platform build operations and provides additional " -"capabilities when creating binary extension packages. Additional " -"documentation is also available on the `C runtime, compiler, and build " -"system generator `_ for Python binary extension modules." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:362 -msgid "Introduction to C/C++ extension modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:364 -msgid "" -"For a more in depth explanation of how extension modules are used by CPython " -"on a Debian system, see the following articles:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:367 -msgid "" -"`What are (c)python extension modules? `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:368 -msgid "`Releasing the gil `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:369 -msgid "" -"`Writing cpython extension modules using C++ `_" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:3 -msgid "Packaging namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:5 -msgid "" -"Namespace packages allow you to split the sub-packages and modules within a " -"single :term:`package ` across multiple, separate :term:" -"`distribution packages ` (referred to as " -"**distributions** in this document to avoid ambiguity). For example, if you " -"have the following package structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:24 -msgid "And you use this package in your code like so::" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:29 -msgid "Then you can break these sub-packages into two separate distributions:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:46 -msgid "Each sub-package can now be separately installed, used, and versioned." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:48 -msgid "" -"Namespace packages can be useful for a large collection of loosely-related " -"packages (such as a large corpus of client libraries for multiple products " -"from a single company). However, namespace packages come with several " -"caveats and are not appropriate in all cases. A simple alternative is to use " -"a prefix on all of your distributions such as ``import " -"mynamespace_subpackage_a`` (you could even use ``import " -"mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:58 -msgid "Creating a namespace package" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:60 -msgid "" -"There are currently three different approaches to creating namespace " -"packages:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:62 -msgid "" -"Use `native namespace packages`_. This type of namespace package is defined " -"in :pep:`420` and is available in Python 3.3 and later. This is recommended " -"if packages in your namespace only ever need to support Python 3 and " -"installation via ``pip``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:66 -msgid "" -"Use `pkgutil-style namespace packages`_. This is recommended for new " -"packages that need to support Python 2 and 3 and installation via both " -"``pip`` and ``python setup.py install``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:69 -msgid "" -"Use `pkg_resources-style namespace packages`_. This method is recommended if " -"you need compatibility with packages already using this method or if your " -"package needs to be zip-safe." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:73 -msgid "" -"While native namespace packages and pkgutil-style namespace packages are " -"largely compatible, pkg_resources-style namespace packages are not " -"compatible with the other methods. It's inadvisable to use different methods " -"in different distributions that provide packages to the same namespace." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:80 -msgid "Native namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:82 -msgid "" -"Python 3.3 added **implicit** namespace packages from :pep:`420`. All that " -"is required to create a native namespace package is that you just omit :file:" -"`__init__.py` from the namespace package directory. An example file " -"structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:97 -msgid "" -"It is extremely important that every distribution that uses the namespace " -"package omits the :file:`__init__.py` or uses a pkgutil-style :file:" -"`__init__.py`. If any distribution does not, it will cause the namespace " -"logic to fail and the other sub-packages will not be importable." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:102 -msgid "" -"Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:" -"`setuptools.find_packages` won't find the sub-package. You must use :func:" -"`setuptools.find_namespace_packages` instead or explicitly list all packages " -"in your :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:117 -msgid "" -"A complete working example of two native namespace packages can be found in " -"the `native namespace package example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:123 -msgid "" -"Because native and pkgutil-style namespace packages are largely compatible, " -"you can use native namespace packages in the distributions that only support " -"Python 3 and pkgutil-style namespace packages in the distributions that need " -"to support Python 2 and 3." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:129 -msgid "pkgutil-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:131 -msgid "" -"Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. " -"This can be used to declare namespace packages that need to be compatible " -"with both Python 2.3+ and Python 3. This is the recommended approach for the " -"highest level of compatibility." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:136 -msgid "" -"To create a pkgutil-style namespace package, you need to provide an :file:" -"`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:148 -#: ../source/guides/packaging-namespace-packages.rst:194 -msgid "" -"The :file:`__init__.py` file for the namespace package needs to contain " -"**only** the following:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:155 -#: ../source/guides/packaging-namespace-packages.rst:201 -msgid "" -"**Every** distribution that uses the namespace package must include an " -"identical :file:`__init__.py`. If any distribution does not, it will cause " -"the namespace logic to fail and the other sub-packages will not be " -"importable. Any additional code in :file:`__init__.py` will be inaccessible." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:160 -msgid "" -"A complete working example of two pkgutil-style namespace packages can be " -"found in the `pkgutil namespace example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:171 -msgid "pkg_resources-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:173 -msgid "" -"`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and " -"the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together " -"these can be used to declare namespace packages. While this approach is no " -"longer recommended, it is widely present in most existing namespace " -"packages. If you are creating a new distribution within an existing " -"namespace package that uses this method then it's recommended to continue " -"using this as the different methods are not cross-compatible and it's not " -"advisable to try to migrate an existing package." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:182 -msgid "" -"To create a pkg_resources-style namespace package, you need to provide an :" -"file:`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:206 -msgid "" -"Some older recommendations advise the following in the namespace package :" -"file:`__init__.py`:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:216 -msgid "" -"The idea behind this was that in the rare case that setuptools isn't " -"available packages would fall-back to the pkgutil-style packages. This isn't " -"advisable because pkgutil and pkg_resources-style namespace packages are not " -"cross-compatible. If the presence of setuptools is a concern then the " -"package should just explicitly depend on setuptools via ``install_requires``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:223 -msgid "" -"Finally, every distribution must provide the ``namespace_packages`` argument " -"to :func:`~setuptools.setup` in :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:237 -msgid "" -"A complete working example of two pkg_resources-style namespace packages can " -"be found in the `pkg_resources namespace example project`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 -msgid "" -"Publishing package distribution releases using GitHub Actions CI/CD workflows" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 -msgid "" -"`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an " -"event occurs on the GitHub platform. One popular choice is having a workflow " -"that's triggered by a ``push`` event. This guide shows you how to publish a " -"Python distribution whenever a tagged commit is pushed. It will use the " -"`pypa/gh-action-pypi-publish GitHub Action`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 -msgid "" -"This guide *assumes* that you already have a project that you know how to " -"build distributions for and *it lives on GitHub*." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 -msgid "Saving credentials on GitHub" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 -msgid "" -"In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, " -"meaning that we'll have two separate sets of credentials. And we'll need to " -"save them in the GitHub repository settings." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 -msgid "Let's begin! 🚀" -msgstr "让我们开始吧！🚀" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 -msgid "" -"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " -"token`_. If you have the project on PyPI already, limit the token scope to " -"just that project. You can call it something like ``GitHub Actions CI/CD — " -"project-org/project-repo`` in order for it to be easily distinguishable in " -"the token list. **Don't close the page just yet — you won't see that token " -"again.**" -msgstr "" -"进入 https://pypi.org/manage/account/#api-tokens ，创建一个新的 `API token`_ 。如果您在 " -"PyPI 上已经有了项目，那么请将令牌的范围限制在该项目上。您可以把它叫做 ``GitHub Actions CI/CD — project-org/" -"project-repo``，以便在 token 列表中容易区分。**先不要关闭页面—您不会再次看到该标记。**" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 -msgid "" -"In a separate browser tab or window, go to the ``Settings`` tab of your " -"target repository and then click on `Secrets`_ in the left sidebar." -msgstr "在一个单独的浏览器标签或窗口中，进入你的目标存储库的 ``Settings`` 标签，然后点击左侧边栏的 `Secrets`_ 。" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 -msgid "" -"Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from " -"the first step." -msgstr "创建一个名为 ``PYPI_API_TOKEN`` 的新 secret ，并复制粘贴第一步中的令牌。" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 -msgid "" -"Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the " -"steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 -msgid "" -"If you don't have a TestPyPI account, you'll need to create it. It's not the " -"same as a regular PyPI account." -msgstr "如果您没有 TestPyPI 账户，那么您就需要创建它。这和普通的 PyPI 账户不一样。" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 -msgid "Creating a workflow definition" -msgstr "创建一个工作流定义" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 -msgid "" -"GitHub CI/CD workflows are declared in YAML files stored in the ``.github/" -"workflows/`` directory of your repository." -msgstr "GitHub CI/CD工作流程是在 YAML 文件中声明的，它们存储在您仓库的 ``.github/workflows/`` 目录下。" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 -msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." -msgstr "让我们创建一个 ``.github/workflows/publish-to-test-pypi.yml`` 文件。" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 -msgid "" -"Start it with a meaningful name and define the event that should make GitHub " -"run this workflow:" -msgstr "用一个有意义的名字开始，并定义让 GitHub 运行这个工作流程的事件：" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 -msgid "Defining a workflow job environment" -msgstr "定义一个工作流程的工作环境" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 -msgid "" -"Now, let's add initial setup for our job. It's a process that will execute " -"commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" -msgstr "现在，让我们为我们的工作添加初始设置。这是一个将执行我们以后定义的命令的过程。在本指南中，我们将使用 Ubuntu 18.04：" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 -msgid "Checking out the project and building distributions" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 -msgid "Then, add the following under the ``build-n-publish`` section:" -msgstr "然后，在 ``build-n-publish`` 部分添加以下内容：" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 -msgid "" -"This will download your repository into the CI runner and then install and " -"activate Python 3.7." -msgstr "这将把您的仓库下载到 CI runner 中，然后安装并激活 Python 3.7。" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 -msgid "" -"And now we can build dists from source. In this example, we'll use ``build`` " -"package, assuming that your project has a ``pyproject.toml`` properly set up " -"(see :pep:`517`/:pep:`518`)." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 -msgid "" -"You can use any other method for building distributions as long as it " -"produces ready-to-upload artifacts saved into the ``dist/`` folder." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 -msgid "So add this to the steps list:" -msgstr "因此，将此加入到步骤列表中：" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 -msgid "Publishing the distribution to PyPI and TestPyPI" -msgstr "在 PyPI 和 TestPyPI 上发布发行版" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 -msgid "Finally, add the following steps at the end:" -msgstr "最后，在结尾添加以下步骤：" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 -msgid "" -"These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the " -"first one uploads contents of the ``dist/`` folder into TestPyPI " -"unconditionally and the second does that to PyPI, but only if the current " -"commit is tagged." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 -msgid "That's all, folks!" -msgstr "就这些了，伙计们!" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 -msgid "" -"Now, whenever you push a tagged commit to your Git repository remote on " -"GitHub, this workflow will publish it to PyPI. And it'll publish any push to " -"TestPyPI which is useful for providing test builds to your alpha users as " -"well as making sure that your release pipeline remains healthy!" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:5 -msgid "Single-sourcing the package version" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:8 -msgid "" -"There are many techniques to maintain a single source of truth for the " -"version number of your project:" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:11 -msgid "" -"Read the file in :file:`setup.py` and get the version. Example (from `pip " -"setup.py `_)::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:38 -msgid "" -"As of the release of setuptools 46.4.0, one can accomplish the same thing by " -"instead placing the following in the project's ``setup.cfg`` file (replacing " -"\"package\" with the import name of the package):" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:47 -msgid "" -"Earlier versions of setuptools implemented the ``attr:`` directive by " -"importing the module, but setuptools 46.4.0 added rudimentary AST analysis " -"so that ``attr:`` can function without having to import any of the package's " -"dependencies." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:52 -msgid "" -"Also, please be aware that declarative config indicators, including the " -"``attr:`` directive, are not supported in parameters to ``setup.py``." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:55 -msgid "" -"Use an external build tool that either manages updating both locations, or " -"offers an API that both locations can use." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:58 -msgid "" -"Few tools you could use, in no particular order, and not necessarily " -"complete: `bump2version `_, `changes " -"`_, `commitizen `_, `zest.releaser `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:65 -msgid "" -"Set the value to a ``__version__`` global variable in a dedicated module in " -"your project (e.g. :file:`version.py`), then have :file:`setup.py` read and " -"``exec`` the value into a variable." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:76 -msgid "" -"Example using this technique: `warehouse `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:78 -msgid "" -"Place the value in a simple ``VERSION`` text file and have both :file:`setup." -"py` and the project code read it." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:86 -msgid "" -"An advantage with this technique is that it's not specific to Python. Any " -"tool can read the version." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:91 -msgid "" -"With this approach you must make sure that the ``VERSION`` file is included " -"in all your source and binary distributions (e.g. add ``include VERSION`` to " -"your :file:`MANIFEST.in`)." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:95 -msgid "" -"Set the value in :file:`setup.py`, and have the project code use the " -"``importlib.metadata`` API to fetch the value at runtime. (``importlib." -"metadata`` was introduced in Python 3.8 and is available to older versions " -"as the ``importlib-metadata`` project.) An installed project's version can " -"be fetched with the API as follows::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:110 -msgid "" -"Be aware that the ``importlib.metadata`` API only knows about what's in the " -"installation metadata, which is not necessarily the code that's currently " -"imported." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:114 -msgid "" -"If a project uses this method to fetch its version at runtime, then its " -"``install_requires`` value needs to be edited to install ``importlib-" -"metadata`` on pre-3.8 versions of Python like so::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:128 -msgid "" -"An older (and less efficient) alternative to ``importlib.metadata`` is the " -"``pkg_resources`` API provided by ``setuptools``::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:134 -msgid "" -"If a project uses ``pkg_resources`` to fetch its own version at runtime, " -"then ``setuptools`` must be added to the project's ``install_requires`` list." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:138 -msgid "" -"Example using this technique: `setuptools `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:141 -msgid "" -"Set the value to ``__version__`` in ``sample/__init__.py`` and import " -"``sample`` in :file:`setup.py`." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:155 -msgid "" -"Although this technique is common, beware that it will fail if ``sample/" -"__init__.py`` imports packages from ``install_requires`` dependencies, which " -"will very likely not be installed yet when :file:`setup.py` is run." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:161 -msgid "" -"Keep the version number in the tags of a version control system (Git, " -"Mercurial, etc) instead of in the code, and automatically extract it from " -"there using `setuptools_scm `_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:5 -msgid "Supporting multiple Python versions" -msgstr "支持多个 Python 版本" - -#: ../source/guides/supporting-multiple-python-versions.rst:37 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:43 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:49 -msgid "Automated testing and continuous integration" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:51 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:56 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:60 -msgid "" -"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:" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:66 -msgid "" -"`Travis CI `_ provides both a Linux and a macOS " -"environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit " -"while the macOS is 10.9.2 at the time of writing." -msgstr "" -"`Travis CI `_ 提供了一个 Linux 和一个 macOS 环境。Linux 环境是 " -"Ubuntu 12.04 LTS 服务器版 64 位，而在撰写本文时 macOS 的版本是 10.9.2。" - -#: ../source/guides/supporting-multiple-python-versions.rst:69 -msgid "" -"`Appveyor `_ provides a Windows environment " -"(Windows Server 2012)." -msgstr "" -"`Appveyor `_ 提供一个 Windows 环境（Windows Server 2012）。" - -#: ../source/guides/supporting-multiple-python-versions.rst:80 -msgid "" -"Both `Travis CI`_ 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." -msgstr "" -"`Travis CI`_ 和 Appveyor_ 都需要一个 `YAML `_ " -"格式的文件作为测试的说明规范。如果任何测试失败，可以检查该特定配置的输出日志。" - -#: ../source/guides/supporting-multiple-python-versions.rst:85 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:89 -msgid "Tools for single-source Python packages" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:91 -msgid "" -"`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_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:100 -msgid "" -"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" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:107 -msgid "a Python 2 (by syntax) module in a Python 3 project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:108 -msgid "a Python 3 (by syntax) module in a *Python 2* project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:110 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:117 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:124 -msgid "What's in which Python?" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:126 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:3 -msgid "Supporting Windows using Appveyor" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:6 -msgid "2015-12-03" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:8 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:20 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:24 -msgid "" -"The Appveyor service is a continuous integration service, much like the " -"better-known `Travis`_ service that is commonly used for testing by projects " -"hosted on `Github`_. However, unlike Travis, the build workers on Appveyor " -"are Windows hosts and have the necessary compilers installed to build Python " -"extensions." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:30 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:38 -msgid "Setting up" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:40 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:45 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:49 -msgid "" -"Once you have set up your Appveyor account and added your project, Appveyor " -"will automatically build your project each time a commit occurs. This " -"behaviour will be familiar to users of Travis." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:54 -msgid "Adding Appveyor support to your project" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:56 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:61 -msgid "" -"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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:69 -msgid "appveyor.yml" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:75 -msgid "" -"This file can be downloaded from `here `__." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:77 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:80 -msgid "" -"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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:88 -msgid "" -"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``)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:94 -msgid "" -"The ``build`` section simply switches off builds - there is no build step " -"needed for Python, unlike languages like ``C#``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:97 -msgid "" -"The main sections that will need to be tailored to your project are " -"``test_script`` and ``after_test``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:100 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:109 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:114 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:119 -msgid "Support script" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:121 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:126 -msgid "" -"`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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:133 -msgid "" -"You can simply download the batch file and include it in your project " -"unchanged." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:137 -msgid "Access to the built wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:139 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:147 -msgid "Additional notes" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:150 -msgid "Testing with tox" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:152 -msgid "" -"Many projects use the `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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:156 -msgid "" -"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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:160 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:165 -msgid "" -"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" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:170 -msgid "``DISTUTILS_USE_SDK``" -msgstr "``DISTUTILS_USE_SDK``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:171 -msgid "``MSSdk``" -msgstr "``MSSdk``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:172 -msgid "``INCLUDE``" -msgstr "``INCLUDE``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:173 -msgid "``LIB``" -msgstr "``LIB``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:175 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:181 -msgid "" -"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 Travis or 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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:188 -msgid "" -"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``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:192 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:197 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:203 -msgid "Automatically uploading wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:205 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:210 -msgid "" -"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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:216 -msgid "External dependencies" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:218 -msgid "" -"The supplied scripts will successfully build any distribution that does not " -"rely on 3rd party external libraries for the build." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:221 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:230 -msgid "Support scripts" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:232 -msgid "For reference, the SDK setup support script is listed here:" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:234 -msgid "``appveyor-sample/build.cmd``" -msgstr "``appveyor-sample/build.cmd``" - -#: ../source/guides/tool-recommendations.rst:5 -msgid "Tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:7 -msgid "" -"If you're familiar with Python packaging and installation, and just want to " -"know what tools are currently recommended, then here it is." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:12 -msgid "Application dependency management" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:14 -msgid "" -"Use :ref:`pipenv` to manage library dependencies when developing Python " -"applications. See :doc:`../tutorials/managing-dependencies` for more details " -"on using ``pipenv``." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:18 -msgid "When ``pipenv`` does not meet your use case, consider other tools like:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:20 -msgid ":ref:`pip`" -msgstr ":ref:`pip`" - -#: ../source/guides/tool-recommendations.rst:22 -msgid "`pip-tools `_" -msgstr "`pip-tools `_" - -#: ../source/guides/tool-recommendations.rst:24 -msgid "`Poetry `_" -msgstr "`Poetry `_" - -#: ../source/guides/tool-recommendations.rst:27 -msgid "Installation tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:29 -msgid "" -"Use :ref:`pip` to install Python :term:`packages ` " -"from :term:`PyPI `. [1]_ [2]_ Depending on how :" -"ref:`pip` is installed, you may need to also install :ref:`wheel` to get the " -"benefit of wheel caching. [3]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:34 -msgid "" -"Use :ref:`virtualenv`, or `venv`_ to isolate application specific " -"dependencies from a shared Python installation. [4]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:37 -msgid "" -"If you're looking for management of fully integrated cross-platform software " -"stacks, consider:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:40 -msgid ":ref:`buildout`: primarily focused on the web development community" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:42 -msgid "" -":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the " -"scientific community." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:47 -msgid "Packaging tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:49 -msgid "" -"Use :ref:`setuptools` to define projects and create :term:`Source " -"Distributions `. [5]_ [6]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:52 -msgid "" -"Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:" -"`wheel project ` to create :term:`wheels `. This is " -"especially beneficial, if your project contains binary extensions." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:56 -msgid "" -"Use `twine `_ for uploading distributions " -"to :term:`PyPI `." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:61 -msgid "Publishing platform migration" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:63 -msgid "" -"The original Python Package Index implementation (previously hosted at `pypi." -"python.org `_) has been phased out in favour of an " -"updated implementation hosted at `pypi.org `_." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:67 -msgid "" -"See :ref:`Migrating to PyPI.org` for more information on the status of the " -"migration, and what settings to change in your clients." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:72 -msgid "" -"There are some cases where you might choose to use ``easy_install`` (from :" -"ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` " -"(which pip doesn't support). For a detailed breakdown, see :ref:`pip vs " -"easy_install`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:77 -msgid "" -"The acceptance of :pep:`453` means that :ref:`pip` will be available by " -"default in most installations of Python 3.4 or later. See the :pep:" -"`rationale section <453#rationale>` from :pep:`453` as for why pip was " -"chosen." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:82 -msgid "" -"`get-pip.py `_ and :ref:" -"`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv " -"` do not currently. Also, the common \"python-pip\" package that's " -"found in various linux distros, does not depend on \"python-wheel\" " -"currently." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:88 -msgid "" -"Beginning with Python 3.4, ``venv`` will create virtualenv environments with " -"``pip`` installed, thereby making it an equal alternative to :ref:" -"`virtualenv`. However, using :ref:`virtualenv` will still be recommended for " -"users that need cross-version consistency." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:93 -msgid "" -"Although you can use pure ``distutils`` for many projects, it does not " -"support defining dependencies on other projects and is missing several " -"convenience utilities for automatically populating distribution metadata " -"correctly that are provided by ``setuptools``. Being outside the standard " -"library, ``setuptools`` also offers a more consistent feature set across " -"different versions of Python, and (unlike ``distutils``), recent versions of " -"``setuptools`` support all of the modern metadata fields described in :ref:" -"`core-metadata`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:102 -msgid "" -"Even for projects that do choose to use ``distutils``, when :ref:`pip` " -"installs such projects directly from source (rather than installing from a " -"prebuilt :term:`wheel ` file), it will actually build your project " -"using :ref:`setuptools` instead." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:107 -msgid "" -"`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` " -"in June 2013, thereby making setuptools the default choice for packaging." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:5 -msgid "Including files in source distributions with ``MANIFEST.in``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:7 -msgid "" -"When building a :term:`source distribution ` for your package, by default only a minimal set of files are " -"included. You may find yourself wanting to include extra files in the " -"source distribution, such as an authors/contributors file, a :file:`docs/` " -"directory, or a directory of data files used for testing purposes. There " -"may even be extra files that you *need* to include; for example, if your :" -"file:`setup.py` computes your project's ``long_description`` by reading from " -"both a README and a changelog file, you'll need to include both those files " -"in the sdist so that people that build or install from the sdist get the " -"correct results." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:17 -msgid "" -"Adding & removing files to & from the source distribution is done by writing " -"a :file:`MANIFEST.in` file at the project root." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:22 -msgid "How files are included in an sdist" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:24 -msgid "The following files are included in a source distribution by default:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:26 -msgid "" -"all Python source files implied by the ``py_modules`` and ``packages`` " -"``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:28 -msgid "" -"all C source files mentioned in the ``ext_modules`` or ``libraries`` " -"``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:30 -msgid "scripts specified by the ``scripts`` ``setup()`` argument" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:31 -msgid "" -"all files specified by the ``package_data`` and ``data_files`` ``setup()`` " -"arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:33 -msgid "" -"the file specified by the ``license_file`` option in :file:`setup.cfg` " -"(setuptools 40.8.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:35 -msgid "" -"all files specified by the ``license_files`` option in :file:`setup.cfg` " -"(setuptools 42.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:37 -msgid "all files matching the pattern :file:`test/test*.py`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:38 -msgid ":file:`setup.py` (or whatever you called your setup script)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:39 -msgid ":file:`setup.cfg`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:40 -msgid ":file:`README`" -msgstr ":file:`README`" - -#: ../source/guides/using-manifest-in.rst:41 -msgid ":file:`README.txt`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:42 -msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:43 -msgid ":file:`README.md` (setuptools 36.4.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:44 -msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:45 -msgid ":file:`MANIFEST.in`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:47 -msgid "" -"After adding the above files to the sdist, the commands in :file:`MANIFEST." -"in` (if such a file exists) are executed in order to add and remove further " -"files to & from the sdist. Default files can even be removed from the sdist " -"with the appropriate :file:`MANIFEST.in` command." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:52 -msgid "" -"After processing the :file:`MANIFEST.in` file, setuptools removes the :file:" -"`build/` directory as well as any directories named :file:`RCS`, :file:" -"`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file " -"and an :file:`*.egg-info` directory. This behavior cannot be changed with :" -"file:`MANIFEST.in`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:60 -msgid ":file:`MANIFEST.in` commands" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:62 -msgid "" -"A :file:`MANIFEST.in` file consists of commands, one per line, instructing " -"setuptools to add or remove some set of files from the sdist. The commands " -"are:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:67 -msgid "Command" -msgstr "命令" - -#: ../source/guides/using-manifest-in.rst:69 -msgid ":samp:`include {pat1} {pat2} ...`" -msgstr ":samp:`include {pat1} {pat2} ...`" - -#: ../source/guides/using-manifest-in.rst:69 -msgid "Add all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid ":samp:`exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid "Remove all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid "" -"Add all files under directories matching ``dir-pattern`` that match any of " -"the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid "" -"Remove all files under directories matching ``dir-pattern`` that match any " -"of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid ":samp:`global-include {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid "" -"Add all files anywhere in the source tree matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid ":samp:`global-exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid "" -"Remove all files anywhere in the source tree matching any of the listed " -"patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid ":samp:`graft {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid "Add all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid ":samp:`prune {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid "Remove all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:79 -msgid "" -"The patterns here are glob-style patterns: ``*`` matches zero or more " -"regular filename characters (on Unix, everything except forward slash; on " -"Windows, everything except backslash and colon); ``?`` matches a single " -"regular filename character, and ``[chars]`` matches any one of the " -"characters between the square brackets (which may contain character ranges, " -"e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented " -"support for ``**`` matching zero or more characters including forward slash, " -"backslash, and colon." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:87 -msgid "" -"Directory patterns are relative to the root of the project directory; e.g., " -"``graft example*`` will include a directory named :file:`examples` in the " -"project root but will not include :file:`docs/examples/`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:91 -msgid "" -"File & directory names in :file:`MANIFEST.in` should be ``/``-separated; " -"setuptools will automatically convert the slashes to the local platform's " -"appropriate directory separator." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:95 -msgid "" -"Commands are processed in the order they appear in the :file:`MANIFEST.in` " -"file. For example, given the commands::" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:101 -msgid "" -"the contents of the directory tree :file:`tests` will first be added to the " -"sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, " -"or ``.pyd`` extension will be removed from the sdist. If the commands were " -"in the opposite order, then ``*.pyc`` files etc. would be only be removed " -"from what was already in the sdist before adding :file:`tests`, and if :file:" -"`tests` happened to contain any ``*.pyc`` files, they would end up included " -"in the sdist because the exclusion happened before they were included." -msgstr "" - -#: ../source/guides/using-testpypi.rst:7 -msgid "" -"``TestPyPI`` is a separate instance of the :term:`Python Package Index " -"(PyPI)` that allows you to try out the distribution tools and process " -"without worrying about affecting the real index. TestPyPI is hosted at `test." -"pypi.org `_" -msgstr "" - -#: ../source/guides/using-testpypi.rst:13 -msgid "Registering your account" -msgstr "注册您的帐户" - -#: ../source/guides/using-testpypi.rst:15 -msgid "" -"Because TestPyPI has a separate database from the live PyPI, you'll need a " -"separate user account for specifically for TestPyPI. Go to https://test.pypi." -"org/account/register/ to register your account." -msgstr "" - -#: ../source/guides/using-testpypi.rst:19 -msgid "" -"The database for TestPyPI may be periodically pruned, so it is not unusual " -"for user accounts to be deleted." -msgstr "" - -#: ../source/guides/using-testpypi.rst:24 -msgid "Using TestPyPI with Twine" -msgstr "" - -#: ../source/guides/using-testpypi.rst:26 -msgid "" -"You can upload your distributions to TestPyPI using :ref:`twine` by " -"specifying the ``--repository`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:33 -msgid "" -"You can see if your package has successfully uploaded by navigating to the " -"URL ``https://test.pypi.org/project/`` where " -"``sampleproject`` is the name of your project that you uploaded. It may take " -"a minute or two for your project to appear on the site." -msgstr "" - -#: ../source/guides/using-testpypi.rst:39 -msgid "Using TestPyPI with pip" -msgstr "" - -#: ../source/guides/using-testpypi.rst:41 -msgid "" -"You can tell pip to download packages from TestPyPI instead of PyPI by " -"specifying the ``--index-url`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:56 -msgid "" -"If you want to allow pip to also pull other packages from PyPI you can " -"specify ``--extra-index-url`` to point to PyPI. This is useful when the " -"package you're testing has dependencies:" -msgstr "" - -#: ../source/guides/using-testpypi.rst:73 -msgid "Setting up TestPyPI in :file:`.pypirc`" -msgstr "在 :file:`.pypirc` 中设置 TestPyPI" - -#: ../source/guides/using-testpypi.rst:75 -msgid "" -"If you want to avoid entering your username, you can configure TestPyPI in " -"your :file:`$HOME/.pypirc`:" -msgstr "" - -#: ../source/index.rst:3 ../source/key_projects.rst:181 -msgid "Python Packaging User Guide" -msgstr "Python 包装用户指南" - -#: ../source/index.rst:5 -msgid "" -"The Python Packaging User Guide (PyPUG) is a collection of tutorials and " -"guides for packaging Python software." -msgstr "Python 打包用户指南 (PyPUG) 是一个打包 Python 软件的教程和指南的集合。" - -#: ../source/index.rst:5 -msgid "python, packaging, guide, tutorial" -msgstr "python, 包装, 指南, 教程" - -#: ../source/index.rst:24 -msgid "" -"Welcome to the *Python Packaging User Guide*, a collection of tutorials and " -"references to help you distribute and install Python packages with modern " -"tools." -msgstr "" - -#: ../source/index.rst:28 -msgid "" -"This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. " -"We happily accept any :doc:`contributions and feedback `. 😊" -msgstr "" -"本指南由 `Python Packaging Authority`_ 在 `GitHub`_ 上维护。我们很乐意接受任何 :doc:`贡献和反馈 " -"`。 😊" - -#: ../source/index.rst:36 -msgid "Get started" -msgstr "开始" - -#: ../source/index.rst:38 -msgid "" -"Essential tools and concepts for working within the Python development " -"ecosystem are covered in our :doc:`tutorials/index` section:" -msgstr "我们的 :doc:`tutorials/index` 部分介绍了在 Python 开发生态系统中工作的基本工具和概念：" - -#: ../source/index.rst:41 -msgid "" -"To learn how to install packages, see the :doc:`tutorial on installing " -"packages `" -msgstr "" -"要学习如何安装软件包，请参阅 :doc:`安装软件包的教程 `" - -#: ../source/index.rst:43 -msgid "" -"To learn how to manage dependencies in a version controlled project, see " -"the :doc:`tutorial on managing application dependencies `" -msgstr "" - -#: ../source/index.rst:45 -msgid "" -"To learn how to package and distribute your projects, see the :doc:`tutorial " -"on packaging and distributing `" -msgstr "" -"要学习如何打包和发布您的项目，请参阅 :doc:`关于打包和发布的教程 `" - -#: ../source/index.rst:47 -msgid "" -"To get an overview of packaging options for Python libraries and " -"applications, see the :doc:`Overview of Python Packaging `" -msgstr "" -"要获得对 Python 库和应用程序打包选项的概述，请参阅 :doc:`Python 打包概述 " -"`" - -#: ../source/index.rst:52 -msgid "Learn more" -msgstr "了解更多" - -#: ../source/index.rst:54 -msgid "" -"Beyond our :doc:`tutorials/index`, this guide has several other resources:" -msgstr "除了我们的 :doc:`tutorials/index` ，本指南还有其他一些资源：" - -#: ../source/index.rst:56 -msgid "" -"The :doc:`guides/index` section for walk throughs, such as :doc:`guides/" -"installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." -msgstr "" -":doc:`guides/index ` 部分用于排练，例如 :doc:`guides/installing-using-linux-tools ` 或 " -":doc:`guides/packaging-binary-extensions`。" - -#: ../source/index.rst:58 -msgid "" -"The :doc:`discussions/index` section for in-depth references on topics such " -"as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-" -"vs-easy-install`." -msgstr "" - -#: ../source/index.rst:60 -msgid "" -"The :doc:`specifications/index` section for packaging interoperability " -"specifications." -msgstr "" - -#: ../source/index.rst:62 -msgid "" -"Additionally, there is a list of :doc:`other projects ` " -"maintained by members of the Python Packaging Authority." -msgstr "" -"此外，还有一个 :doc:`其他项目 ` 的列表，由 Python Packaging Authority 的成员维护。" - -#: ../source/key_projects.rst:6 -msgid "Project Summaries" -msgstr "项目摘要" - -#: ../source/key_projects.rst:8 -msgid "" -"Summaries and links for the most relevant projects in the space of Python " -"installation and packaging." -msgstr "" - -#: ../source/key_projects.rst:14 -msgid "PyPA Projects" -msgstr "PyPA 项目" - -#: ../source/key_projects.rst:19 -msgid "bandersnatch" -msgstr "" - -#: ../source/key_projects.rst:21 -msgid "" -"`Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`Issues `__ | `GitHub " -"`__ | `PyPI `__" - -#: ../source/key_projects.rst:25 -msgid "" -"``bandersnatch`` is a PyPI mirroring client designed to efficiently create a " -"complete mirror of the contents of PyPI. Organizations thus save bandwidth " -"and latency on package downloads (especially in the context of automated " -"tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." -msgstr "" - -#: ../source/key_projects.rst:35 -msgid "build" -msgstr "建造" - -#: ../source/key_projects.rst:37 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI " -"`__" -msgstr "" -"`文档 `__ | `Issues `__ | `GitHub `__ | `PyPI " -"`__" - -#: ../source/key_projects.rst:42 -msgid "" -"``build`` is a :pep:`517` compatible Python package builder. It provides a " -"CLI to build packages, as well as a Python API." -msgstr "" - -#: ../source/key_projects.rst:49 -msgid "cibuildwheel" -msgstr "cibuildwheel" - -#: ../source/key_projects.rst:51 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | " -"`Discussions `__ | " -"`Discord #cibuildwheel `__" -msgstr "" -"`文档 `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | `" -"Discussions `__ | `Discord " -"#cibuildwheel `__" - -#: ../source/key_projects.rst:58 -msgid "" -"``cibuildwheel`` is a Python package that builds :term:`wheels ` for " -"all common platforms and Python versions on most CI systems. Also see :ref:" -"`multibuild`." -msgstr "" - -#: ../source/key_projects.rst:64 -msgid "distlib" -msgstr "distlib" - -#: ../source/key_projects.rst:66 -msgid "" -"`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:71 -msgid "" -"``distlib`` is a library which implements low-level functions that relate to " -"packaging and distribution of Python software. ``distlib`` implements " -"several relevant PEPs (Python Enhancement Proposal standards) and is useful " -"for developers of third-party packaging tools to make and upload binary and " -"source :term:`distributions `, achieve " -"interoperability, resolve dependencies, manage package resources, and do " -"other similar functions." -msgstr "" - -#: ../source/key_projects.rst:80 -msgid "" -"Unlike the stricter :ref:`packaging` project (below), which specifically " -"implements modern Python packaging interoperability standards, ``distlib`` " -"also attempts to provide reasonable fallback behaviours when asked to handle " -"legacy packages and metadata that predate the modern interoperability " -"standards and fall into the subset of packages that are incompatible with " -"those standards." -msgstr "" - -#: ../source/key_projects.rst:90 -msgid "packaging" -msgstr "" - -#: ../source/key_projects.rst:92 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:97 -msgid "" -"Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." -msgstr "" - -#: ../source/key_projects.rst:99 -msgid "" -"The core utilities in the packaging library handle version handling, " -"specifiers, markers, requirements, tags, and similar attributes and tasks " -"for Python packages. Most Python users rely on this library without needing " -"to explicitly call it; developers of the other Python packaging, " -"distribution, and installation tools listed here often use its functionality " -"to parse, discover, and otherwise handle dependency attributes." -msgstr "" - -#: ../source/key_projects.rst:107 -msgid "" -"This project specifically focuses on implementing the modern Python " -"packaging interoperability standards defined at :ref:`packaging-" -"specifications`, and will report errors for sufficiently old legacy packages " -"that are incompatible with those standards. In contrast, the :ref:`distlib` " -"project is a more permissive library that attempts to provide a plausible " -"reading of ambiguous metadata in cases where :ref:`packaging` will instead " -"report on error." -msgstr "" - -#: ../source/key_projects.rst:119 -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "pip" -msgstr "" - -#: ../source/key_projects.rst:121 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`文档 `__ | `Issues `__ | `GitHub `__ | `PyPI " -"`__" - -#: ../source/key_projects.rst:126 -msgid "" -"The most popular tool for installing Python packages, and the one included " -"with modern versions of Python." -msgstr "最流行的安装 Python 软件包的工具，也是现代版本的 Python 所包含的工具。" - -#: ../source/key_projects.rst:129 -msgid "" -"It provides the essential core features for finding, downloading, and " -"installing packages from PyPI and other Python package indexes, and can be " -"incorporated into a wide range of development workflows via its command-line " -"interface (CLI)." -msgstr "" -"它提供了从 PyPI 和其他 Python 包索引中查找、下载和安装包的基本核心功能，并且可以通过其命令行界面 (CLI) 合并到广泛的开发工作流程中。" - -#: ../source/key_projects.rst:137 -msgid "Pipenv" -msgstr "Pipenv" - -#: ../source/key_projects.rst:139 -msgid "" -"`Docs `__ | `Source `__ | `Issues `__ | `PyPI " -"`__" -msgstr "" -"`文档 `__ | `源码 `__ | " -"`Issues `__ | `PyPI `__" - -#: ../source/key_projects.rst:144 -msgid "" -"Pipenv is a project that aims to bring the best of all packaging worlds to " -"the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:" -"`virtualenv` into one single toolchain. It features very pretty terminal " -"colors." -msgstr "" - -#: ../source/key_projects.rst:148 -msgid "" -"Pipenv aims to help users manage environments, dependencies, and imported " -"packages on the command line. It also works well on Windows (which other " -"tools often underserve), makes and checkes file hashes, to ensure compliance " -"with hash-locked dependency specifiers, and eases uninstallation of packages " -"and dependencies. It is used by Python users and system administrators, but " -"has been less maintained since late 2018." -msgstr "" - -#: ../source/key_projects.rst:159 -msgid "Pipfile" -msgstr "Pipfile" - -#: ../source/key_projects.rst:161 -msgid "`Source `__" -msgstr "`源码 `__" - -#: ../source/key_projects.rst:163 -msgid "" -":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level " -"application-centric alternative to :ref:`pip`'s lower-level :file:" -"`requirements.txt` file." -msgstr "" - -#: ../source/key_projects.rst:170 -msgid "pipx" -msgstr "pipx" - -#: ../source/key_projects.rst:172 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`文档< `__ | `GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:176 -msgid "" -"pipx is a tool to install and run Python command-line applications without " -"causing dependency conflicts with other packages installed on the system." -msgstr "pipx 是一个安装和运行 Python 命令行应用程序的工具，它不会与系统上安装的其他软件包产生依赖性冲突。" - -#: ../source/key_projects.rst:183 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" -"`文档 `__ | `Issues `__ | `GitHub `__" - -#: ../source/key_projects.rst:187 -msgid "This guide!" -msgstr "本指南！" - -#: ../source/key_projects.rst:192 -msgid "readme_renderer" -msgstr "readme_renderer" - -#: ../source/key_projects.rst:194 -msgid "" -"`GitHub and docs `__ | `PyPI " -"`__" -msgstr "" -"`GitHub 和文档 `__ | `PyPI " -"`__" - -#: ../source/key_projects.rst:197 -msgid "" -"``readme_renderer`` is a library that package developers use to render their " -"user documentation (README) files into HTML from markup languages such as " -"Markdown or reStructuredText. Developers call it on its own or via :ref:" -"`twine`, as part of their release management process, to check that their " -"package descriptions will properly display on PyPI." -msgstr "" - -#: ../source/key_projects.rst:208 -msgid "setuptools" -msgstr "setuptools" - -#: ../source/key_projects.rst:210 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`文档 `__ | `Issues " -"`__ | `GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:215 -msgid "" -"setuptools (which includes ``easy_install``) is a collection of enhancements " -"to the Python distutils that allow you to more easily build and distribute " -"Python :term:`distributions `, especially ones that " -"have dependencies on other packages." -msgstr "" - -#: ../source/key_projects.rst:220 -msgid "" -"`distribute`_ was a fork of setuptools that was merged back into setuptools " -"(in v0.7), thereby making setuptools the primary choice for Python packaging." -msgstr "" - -#: ../source/key_projects.rst:227 -msgid "trove-classifiers" -msgstr "" - -#: ../source/key_projects.rst:229 -msgid "" -"`Issues `__ | `GitHub " -"`__ | `PyPI `__" -msgstr "" -"`Issues `__ | `GitHub " -"`__ | `PyPI `__" - -#: ../source/key_projects.rst:233 -msgid "" -"trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically " -"describe their projects `_ so that users can better find projects " -"that match their needs on the PyPI." -msgstr "" - -#: ../source/key_projects.rst:239 -msgid "" -"The trove-classifiers package contains a list of valid classifiers and " -"deprecated classifiers (which are paired with the classifiers that replace " -"them). Use this package to validate classifiers used in packages intended " -"for uploading to PyPI. As this list of classifiers is published as code, you " -"can install and import it, giving you a more convenient workflow compared to " -"referring to the `list published on PyPI `_. " -"The `issue tracker `_ for " -"the project hosts discussions on proposed classifiers and requests for new " -"classifiers." -msgstr "" - -#: ../source/key_projects.rst:253 -msgid "twine" -msgstr "twine" - -#: ../source/key_projects.rst:255 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" -"`文档 `__ | `Issues `__ | `GitHub `__ | `" -"PyPI `__" - -#: ../source/key_projects.rst:260 -msgid "" -"Twine is the primary tool developers use to upload packages to the Python " -"Package Index or other Python package indexes. It is a command-line program " -"that passes program files and metadata to a web API. Developers use it " -"because it's the official PyPI upload tool, it's fast and secure, it's " -"maintained, and it reliably works." -msgstr "" - -#: ../source/key_projects.rst:270 ../source/overview.rst:415 -msgid "virtualenv" -msgstr "virtualenv" - -#: ../source/key_projects.rst:272 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`文档 `__ | `Issues `__ | `GitHub `__ " -"| `PyPI `__" - -#: ../source/key_projects.rst:277 -msgid "" -"virtualenv is a tool which uses the command-line path environment variable " -"to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional " -"functionality, compared to :ref:`venv`, by supporting Python 2.7 and by " -"providing convenient features for configuring, maintaining, duplicating, and " -"troubleshooting the virtual environments. For more information, see the " -"section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/key_projects.rst:290 -msgid "Warehouse" -msgstr "Warehouse" - -#: ../source/key_projects.rst:292 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" -"`文档 `__ | `Issues `__ | `GitHub `__" - -#: ../source/key_projects.rst:296 -msgid "" -"The current codebase powering the :term:`Python Package Index (PyPI)`. It is " -"hosted at `pypi.org `_. The default source for :ref:`pip` " -"downloads." -msgstr "" - -#: ../source/key_projects.rst:304 -msgid "wheel" -msgstr "wheel" - -#: ../source/key_projects.rst:306 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" -"`文档 `__ | `Issues `__ | `GitHub `__ | `" -"PyPI `__" - -#: ../source/key_projects.rst:311 -msgid "" -"Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` " -"extension for creating :term:`wheel distributions `. Additionally, " -"it offers its own command line utility for creating and installing wheels." -msgstr "" - -#: ../source/key_projects.rst:315 -msgid "" -"See also `auditwheel `__, a tool that " -"package developers use to check and fix Python packages they are making in " -"the binary wheel format. It provides functionality to discover dependencies, " -"check metadata for compliance, and repair the wheel and metadata to properly " -"link and include external shared libraries in a package." -msgstr "" - -#: ../source/key_projects.rst:324 -msgid "Non-PyPA Projects" -msgstr "非 PyPA 项目" - -#: ../source/key_projects.rst:329 -msgid "bento" -msgstr "bento" - -#: ../source/key_projects.rst:331 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" -"`文档 `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" - -#: ../source/key_projects.rst:336 -msgid "" -"Bento is a packaging tool solution for Python software, targeted as an " -"alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's " -"philosophy is reproducibility, extensibility and simplicity (in that order)." -msgstr "" - -#: ../source/key_projects.rst:344 -msgid "buildout" -msgstr "buildout" - -#: ../source/key_projects.rst:346 -msgid "" -"`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" -msgstr "" -"`文档 `__ | `Issues `__ | `PyPI `__ | `" -"GitHub `__" - -#: ../source/key_projects.rst:351 -msgid "" -"Buildout is a Python-based build system for creating, assembling and " -"deploying applications from multiple parts, some of which may be non-Python-" -"based. It lets you create a buildout configuration and reproduce the same " -"software later." -msgstr "" - -#: ../source/key_projects.rst:358 -msgid "conda" -msgstr "conda" - -#: ../source/key_projects.rst:360 -msgid "`Docs `__" -msgstr "`文档 `__" - -#: ../source/key_projects.rst:362 -msgid "" -"conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution " -"from `Anaconda, Inc `__ specifically " -"aimed at the scientific community, and in particular on Windows where the " -"installation of binary extensions is often difficult." -msgstr "" - -#: ../source/key_projects.rst:369 -msgid "" -"Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, " -"but provides many of their combined features in terms of package management, " -"virtual environment management and deployment of binary extensions." -msgstr "" - -#: ../source/key_projects.rst:373 -msgid "" -"Conda does not install packages from PyPI and can install only from the " -"official Anaconda repositories, or anaconda.org (a place for user-" -"contributed *conda* packages), or a local (e.g. intranet) package server. " -"However, note that :ref:`pip` can be installed into, and work side-by-side " -"with conda for managing :term:`distributions ` from " -"PyPI. Also, `conda skeleton `__ is a tool to make " -"Python packages installable by conda by first fetching them from PyPI and " -"modifying their metadata." -msgstr "" - -#: ../source/key_projects.rst:386 -msgid "devpi" -msgstr "" - -#: ../source/key_projects.rst:388 -msgid "" -"`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" -"`文档 `__ | `Issues `__ | `PyPI `__" - -#: ../source/key_projects.rst:392 -msgid "" -"devpi features a powerful PyPI-compatible server and PyPI proxy cache with a " -"complementary command line tool to drive packaging, testing and release " -"activities with Python. devpi also provides a browsable and searchable web " -"interface." -msgstr "" - -#: ../source/key_projects.rst:401 -msgid "flit" -msgstr "flit" - -#: ../source/key_projects.rst:403 -msgid "" -"`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" -"`文档`__ | `Issues `__ | `PyPI `__" - -#: ../source/key_projects.rst:407 -msgid "" -"Flit provides a simple way to upload pure Python packages and modules to " -"PyPI. It focuses on `making the easy things easy `_ for " -"packaging. Flit can generate a configuration file to quickly set up a simple " -"project, build source distributions and wheels, and upload them to PyPI." -msgstr "" - -#: ../source/key_projects.rst:412 -msgid "" -"Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on " -"tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to " -"upload them to PyPI. Flit requires Python 3, but you can use it to " -"distribute modules for Python 2, so long as they can be imported on Python 3." -msgstr "" - -#: ../source/key_projects.rst:422 -msgid "enscons" -msgstr "enscons" - -#: ../source/key_projects.rst:424 -msgid "" -"`Source `__ | `Issues `__ | `PyPI `__" -msgstr "" -"`源码 `__ | `Issues " -"`__ | `PyPI `__" - -#: ../source/key_projects.rst:428 -msgid "" -"Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-" -"compatible source distributions and wheels without using distutils or " -"setuptools, including distributions with C extensions. Enscons has a " -"different architecture and philosophy than :ref:`distutils`. Rather than " -"adding build features to a Python packaging system, enscons adds Python " -"packaging to a general purpose build system. Enscons helps you to build " -"sdists that can be automatically built by :ref:`pip`, and wheels that are " -"independent of enscons." -msgstr "" - -#: ../source/key_projects.rst:443 -msgid "Hashdist" -msgstr "Hashdist" - -#: ../source/key_projects.rst:445 -msgid "" -"`Docs `__ | `GitHub `__" -msgstr "" -"`文档 `__ | `GitHub `__" - -#: ../source/key_projects.rst:448 -msgid "" -"Hashdist is a library for building non-root software distributions. Hashdist " -"is trying to be “the Debian of choice for cases where Debian technology " -"doesn’t work”. The best way for Pythonistas to think about Hashdist may be a " -"more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed " -"at solving the problem of installing scientific software, and making package " -"distribution stateless, cached, and branchable. It is used by some " -"researchers but has been lacking in maintenance since 2016." -msgstr "" - -#: ../source/key_projects.rst:460 -msgid "hatch" -msgstr "hatch" - -#: ../source/key_projects.rst:462 -msgid "" -"`GitHub and Docs `__ | `PyPI `__" -msgstr "" -"`GitHub 和文档 `__ | `PyPI `__" - -#: ../source/key_projects.rst:465 -msgid "" -"Hatch is a unified command-line tool meant to conveniently manage " -"dependencies and environment isolation for Python developers. Python package " -"developers use Hatch to configure, version, specify dependencies for, and " -"publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload " -"packages to PyPI, and :ref:`pip` to download and install packages." -msgstr "" - -#: ../source/key_projects.rst:475 -msgid "multibuild" -msgstr "multibuild" - -#: ../source/key_projects.rst:477 -msgid "`GitHub `__" -msgstr "`GitHub `__" - -#: ../source/key_projects.rst:479 -msgid "" -"Multibuild is a set of CI scripts for building and testing Python :term:" -"`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :" -"ref:`cibuildwheel`." -msgstr "" - -#: ../source/key_projects.rst:485 -msgid "pex" -msgstr "pex" - -#: ../source/key_projects.rst:487 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`文档 `__ | `GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:491 -msgid "" -"pex is both a library and tool for generating :file:`.pex` (Python " -"EXecutable) files, standalone Python environments in the spirit of :ref:" -"`virtualenv`. :file:`.pex` files are just carefully constructed zip files " -"with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are " -"designed to make deployment of Python applications as simple as ``cp``." -msgstr "" - -#: ../source/key_projects.rst:500 -msgid "pip-tools" -msgstr "pip-tools" - -#: ../source/key_projects.rst:502 -msgid "" -"`GitHub and Docs `__ | `PyPI " -"`__" -msgstr "" -"`GitHub 和文档 `__ | `PyPI `__" - -#: ../source/key_projects.rst:505 -msgid "" -"pip-tools is a suite of tools meant for Python system administrators and " -"release managers who particularly want to keep their builds deterministic " -"yet stay up to date with new versions of their dependencies. Users can " -"specify particular release of their dependencies via hash, conveniently make " -"a properly formatted list of requirements from information in other parts of " -"their program, update all dependencies (a feature :ref:`pip` currently does " -"not provide), and create layers of constraints for the program to obey." -msgstr "" - -#: ../source/key_projects.rst:517 -msgid "piwheels" -msgstr "piwheels" - -#: ../source/key_projects.rst:519 -msgid "" -"`Website `__ | `Docs `__ | `GitHub `__" -msgstr "" -"`网站 `__ | `文档 `" -"__ | `GitHub `__" - -#: ../source/key_projects.rst:523 -msgid "" -"piwheels is a website, and software underpinning it, that fetches source " -"code distribution packages from PyPI and compiles them into binary wheels " -"that are optimized for installation onto Raspberry Pi computers. Raspberry " -"Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." -msgstr "" - -#: ../source/key_projects.rst:532 -msgid "poetry" -msgstr "poetry" - -#: ../source/key_projects.rst:534 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`文档 `__ | `GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:538 -msgid "" -"poetry is a command-line tool to handle dependency installation and " -"isolation as well as building and packaging of Python packages. It uses " -"``pyproject.toml`` and, instead of depending on the resolver functionality " -"within :ref:`pip`, provides its own dependency resolver. It attempts to " -"speed users' experience of installation and dependency resolution by locally " -"caching metadata about dependencies." -msgstr "" -"poetry是一个命令行工具，用于处理依赖性安装和隔离，以及 Python 包的构建和打包。它使用 ``pyproject.toml`` ，并且不依赖 " -":ref:`pip`中的解析器功能，而是提供自己的依赖性解析器。它试图通过本地缓存依赖关系的元数据来加速用户的安装和依赖关系的解决。" - -#: ../source/key_projects.rst:548 -msgid "pypiserver" -msgstr "pypiserver" - -#: ../source/key_projects.rst:550 -msgid "" -"`Docs `__ | " -"`GitHub `__ | `PyPI `__" -msgstr "" -"`文档 `__ | `" -"GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:554 -msgid "" -"pypiserver is a minimalist application that serves as a private Python " -"package index within organizations, implementing a simple API and browser " -"interface. You can upload private packages using standard upload tools, and " -"users can download and install them with :ref:`pip`, without publishing them " -"publicly. Organizations who use pypiserver usually download packages both " -"from pypiserver and from PyPI." -msgstr "" -"pypiserver 是一个简约的应用程序，作为组织内的私有 Python 包索引，实现了一个简单的 API " -"和浏览器界面。您可以使用标准的上传工具上传私有软件包，用户可以使用 :ref:`pip` 下载和安装它们，而不用公开发布。使用 pypiserver " -"的组织通常既从 pypiserver 也从 PyPI 下载软件包。" - -#: ../source/key_projects.rst:564 -msgid "scikit-build" -msgstr "scikit-build" - -#: ../source/key_projects.rst:566 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`文档 `__ | `GitHub " -"`__ | `PyPI `__" - -#: ../source/key_projects.rst:570 -msgid "" -"Scikit-build is an improved build system generator for CPython C/C++/Fortran/" -"Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :" -"ref:`pip`. It internally uses `cmake `__ " -"(available on PyPI) to provide better support for additional compilers, " -"build systems, cross compilation, and locating dependencies and their " -"associated build requirements. To speed up and parallelize the build of " -"large projects, the user can install `ninja `__ (also available on PyPI)." -msgstr "" - -#: ../source/key_projects.rst:582 -msgid "shiv" -msgstr "shiv" - -#: ../source/key_projects.rst:584 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`文档 `__ | `GitHub `__ | `PyPI `__" - -#: ../source/key_projects.rst:588 -msgid "" -"shiv is a command line utility for building fully self contained Python " -"zipapps as outlined in :pep:`441`, but with all their dependencies included. " -"Its primary goal is making distributing Python applications and command line " -"tools fast & easy." -msgstr "" - -#: ../source/key_projects.rst:598 -msgid "" -"`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" -msgstr "" - -#: ../source/key_projects.rst:603 -msgid "" -"A flexible package manager designed to support multiple versions, " -"configurations, platforms, and compilers. Spack is like Homebrew, but " -"packages are written in Python and parameterized to allow easy swapping of " -"compilers, library versions, build options, etc. Arbitrarily many versions " -"of packages can coexist on the same system. Spack was designed for rapidly " -"building high performance scientific applications on clusters and " -"supercomputers." -msgstr "" - -#: ../source/key_projects.rst:611 -msgid "" -"Spack is not in PyPI (yet), but it requires no installation and can be used " -"immediately after cloning from GitHub." -msgstr "Spack 不在 PyPI 中（目前），但它不需要安装，从 GitHub 克隆后可以立即使用。" - -#: ../source/key_projects.rst:617 -msgid "zest.releaser" -msgstr "zest.releaser" - -#: ../source/key_projects.rst:619 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" -"`文档 `__ | `GitHub " -"`__ | `PyPI `__" - -#: ../source/key_projects.rst:623 -msgid "" -"``zest.releaser`` is a Python package release tool providing an abstraction " -"layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to " -"automate incrementing package version numbers, updating changelogs, tagging " -"releases in source control, and uploading new packages to PyPI." -msgstr "" - -#: ../source/key_projects.rst:630 -msgid "Standard Library Projects" -msgstr "" - -#: ../source/key_projects.rst:635 -msgid "ensurepip" -msgstr "ensurepip" - -#: ../source/key_projects.rst:637 -msgid "" -"`Docs `__ | `Issues " -"`__" -msgstr "" -"`文档 `__ | `Issues " -"`__" - -#: ../source/key_projects.rst:640 -msgid "" -"A package in the Python Standard Library that provides support for " -"bootstrapping :ref:`pip` into an existing Python installation or virtual " -"environment. In most cases, end users won't use this module, but rather it " -"will be used during the build of the Python distribution." -msgstr "" - -#: ../source/key_projects.rst:649 -msgid "distutils" -msgstr "distutils" - -#: ../source/key_projects.rst:651 -msgid "" -"`Docs `__ | `Issues " -"`__" -msgstr "" -"`文档 `__ | `Issues " -"`__" - -#: ../source/key_projects.rst:654 -msgid "" -"The original Python packaging system, added to the standard library in " -"Python 2.0." -msgstr "" - -#: ../source/key_projects.rst:657 -msgid "" -"Due to the challenges of maintaining a packaging system where feature " -"updates are tightly coupled to language runtime updates, direct usage of :" -"ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being " -"the preferred replacement. :ref:`Setuptools` not only provides features that " -"plain :ref:`distutils` doesn't offer (such as dependency declarations and " -"entry point declarations), it also provides a consistent build interface and " -"feature set across all supported Python versions." -msgstr "" - -#: ../source/key_projects.rst:670 -msgid "venv" -msgstr "venv" - -#: ../source/key_projects.rst:672 -msgid "" -"`Docs `__ | `Issues `__" -msgstr "" -"`文档 `__ | `Issues `__" - -#: ../source/key_projects.rst:675 -msgid "" -"A package in the Python Standard Library (starting with Python 3.3) for " -"creating :term:`Virtual Environments `. For more " -"information, see the section on :ref:`Creating and using Virtual " -"Environments`." -msgstr "" - -#: ../source/news.rst:2 -msgid "News" -msgstr "新闻" - -#: ../source/news.rst:5 -msgid "September 2019" -msgstr "2019年9月" - -#: ../source/news.rst:6 -msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" -msgstr "" - -#: ../source/news.rst:9 -msgid "August 2019" -msgstr "" - -#: ../source/news.rst:10 -msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" -msgstr "" - -#: ../source/news.rst:13 -msgid "July 2019" -msgstr "" - -#: ../source/news.rst:14 -msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" -msgstr "" - -#: ../source/news.rst:15 -msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" -msgstr "" - -#: ../source/news.rst:16 -msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" -msgstr "" - -#: ../source/news.rst:17 -msgid "Updated directory layout examples for consistency. (:pr:`611`)" -msgstr "" - -#: ../source/news.rst:18 -msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" -msgstr "" - -#: ../source/news.rst:21 -msgid "June 2019" -msgstr "" - -#: ../source/news.rst:22 -msgid "Fixed some typos. (:pr:`620`)" -msgstr "" - -#: ../source/news.rst:25 -msgid "May 2019" -msgstr "" - -#: ../source/news.rst:26 -msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" -msgstr "" - -#: ../source/news.rst:27 -msgid "Added a MANIFEST.in guide page. (:pr:`609`)" -msgstr "" - -#: ../source/news.rst:30 -msgid "April 2019" -msgstr "" - -#: ../source/news.rst:31 -msgid "" -"Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" -msgstr "" - -#: ../source/news.rst:32 -msgid "Reduced emphasis on virtualenv. (:pr:`606`)" -msgstr "" - -#: ../source/news.rst:35 -msgid "March 2019" -msgstr "" - -#: ../source/news.rst:36 -msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" -msgstr "" - -#: ../source/news.rst:37 -msgid "Covered RTD details for contributing. (:pr:`600`)" -msgstr "" - -#: ../source/news.rst:40 -msgid "February 2019" -msgstr "" - -#: ../source/news.rst:41 -msgid "" -"Elaborate upon the differences between the tutorial and the real packaging " -"process. (:pr:`602`)" -msgstr "" - -#: ../source/news.rst:42 -msgid "Added instructions to install Python CLI applications. (:pr:`594`)" -msgstr "" - -#: ../source/news.rst:45 -msgid "January 2019" -msgstr "" - -#: ../source/news.rst:46 -msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" -msgstr "" - -#: ../source/news.rst:47 -msgid "Updated Sphinx and Nox. (:pr:`591`)" -msgstr "" - -#: ../source/news.rst:48 -msgid "Referenced Twine from Python3. (:pr:`581`)" -msgstr "" - -#: ../source/news.rst:51 -msgid "December 2018" -msgstr "" - -#: ../source/news.rst:52 -msgid "No programmers in the office!" -msgstr "" - -#: ../source/news.rst:55 -msgid "November 2018" -msgstr "" - -#: ../source/news.rst:56 -msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" -msgstr "" - -#: ../source/news.rst:57 -msgid "Changed bumpversion to bump2version. (:pr:`572`)" -msgstr "" - -#: ../source/news.rst:58 -msgid "Added single-sourcing package version example. (:pr:`573`)" -msgstr "" - -#: ../source/news.rst:59 -msgid "Added a guide for creating documentation. (:pr:`568`)" -msgstr "" - -#: ../source/news.rst:62 -msgid "October 2018" -msgstr "" - -#: ../source/news.rst:63 -msgid "Updated Nox package name. (:pr:`566`)" -msgstr "" - -#: ../source/news.rst:64 -msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" -msgstr "" - -#: ../source/news.rst:67 -msgid "September 2018" -msgstr "" - -#: ../source/news.rst:68 -msgid "Added a section on checking RST markup. (:pr:`554`)" -msgstr "" - -#: ../source/news.rst:69 -msgid "Updated user installs page. (:pr:`558`)" -msgstr "" - -#: ../source/news.rst:70 -msgid "Updated Google BigQuery urls. (:pr:`556`)" -msgstr "" - -#: ../source/news.rst:71 -msgid "Replaced tar command with working command. (:pr:`552`)" -msgstr "" - -#: ../source/news.rst:72 -msgid "" -"Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" -msgstr "" - -#: ../source/news.rst:75 -msgid "August 2018" -msgstr "" - -#: ../source/news.rst:76 -msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" -msgstr "" - -#: ../source/news.rst:77 -msgid "" -"Moved the Overview to a task based lead in along with the others. (:pr:`540`)" -msgstr "" - -#: ../source/news.rst:78 -msgid "Updated Python version supported by virtualenv. (:pr:`538`)" -msgstr "" - -#: ../source/news.rst:79 -msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" -msgstr "" - -#: ../source/news.rst:82 -msgid "July 2018" -msgstr "" - -#: ../source/news.rst:84 -msgid "Improved binary extension docs. (:pr:`531`)" -msgstr "" - -#: ../source/news.rst:85 -msgid "Added scikit-build to key projects. (:pr:`530`)" -msgstr "" - -#: ../source/news.rst:88 -msgid "June 2018" -msgstr "" - -#: ../source/news.rst:90 -msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" -msgstr "" - -#: ../source/news.rst:91 -msgid "Updated Markdown descriptions explanation. (:pr:`522`)" -msgstr "" - -#: ../source/news.rst:94 -msgid "May 2018" -msgstr "" - -#: ../source/news.rst:96 -msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" -msgstr "" - -#: ../source/news.rst:97 -msgid "" -"Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" -msgstr "" - -#: ../source/news.rst:98 -msgid "Simplified packaging tutorial. (:pr:`498`)" -msgstr "" - -#: ../source/news.rst:99 -msgid "Updated Windows users instructions for clarity. (:pr:`493`)" -msgstr "" - -#: ../source/news.rst:100 -msgid "Updated the license section description for completeness. (:pr:`492`)" -msgstr "" - -#: ../source/news.rst:101 -msgid "Added specification-style document to contributing section. (:pr:`489`)" -msgstr "" - -#: ../source/news.rst:102 -msgid "Added documentation types to contributing guide. (:pr:`485`)" -msgstr "" - -#: ../source/news.rst:105 -msgid "April 2018" -msgstr "" - -#: ../source/news.rst:107 -msgid "Added README guide. (:pr:`461`)" -msgstr "" - -#: ../source/news.rst:108 -msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" -msgstr "" - -#: ../source/news.rst:109 -msgid "Added instructions for Warehouse. (:pr:`471`)" -msgstr "" - -#: ../source/news.rst:110 -msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" -msgstr "" - -#: ../source/news.rst:111 -msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" -msgstr "" - -#: ../source/news.rst:112 -msgid "Added a guide for phasing out Python versions. (:pr:`459`)" -msgstr "" - -#: ../source/news.rst:113 -msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" -msgstr "" - -#: ../source/news.rst:116 -msgid "March 2018" -msgstr "" - -#: ../source/news.rst:118 -msgid "Updated \"installing scientific packages\". (:pr:`455`)" -msgstr "" - -#: ../source/news.rst:119 -msgid "" -"Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" -msgstr "" - -#: ../source/news.rst:120 -msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" -msgstr "" - -#: ../source/news.rst:121 -msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" -msgstr "" - -#: ../source/news.rst:124 -msgid "February 2018" -msgstr "" - -#: ../source/news.rst:126 -msgid "" -"Added python3-venv and python3-pip to Debian installation instructions. (:pr:" -"`445`)" -msgstr "" - -#: ../source/news.rst:127 -msgid "Updated PyPI migration info. (:pr:`439`)" -msgstr "" - -#: ../source/news.rst:128 -msgid "" -"Added a warning about managing multiple versions with pipenv. (:pr:`430`)" -msgstr "" - -#: ../source/news.rst:129 -msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" -msgstr "" - -#: ../source/news.rst:130 -msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" -msgstr "" - -#: ../source/news.rst:133 -msgid "January 2018" -msgstr "2018年1月" - -#: ../source/news.rst:135 -msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" -msgstr "添加了一个指向 PyPI 分类器列表的链接。(:pr:`425`)" - -#: ../source/news.rst:136 -msgid "Updated README.rst explanation. (:pr:`419`)" -msgstr "更新了 README.rst 的解释。(:pr:`419`)" - -#: ../source/news.rst:139 -msgid "December 2017" -msgstr "2017年12月" - -#: ../source/news.rst:141 -msgid "" -"Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" -msgstr "" - -#: ../source/news.rst:142 -msgid "Noted which fields can be used with environment markers. (:pr:`416`)" -msgstr "" - -#: ../source/news.rst:143 -msgid "Updated Requires-Python section. (:pr:`414`)" -msgstr "" - -#: ../source/news.rst:144 -msgid "Added news page. (:pr:`404`)" -msgstr "" - -#: ../source/news.rst:147 -msgid "November 2017" -msgstr "" - -#: ../source/news.rst:149 -msgid "" -"Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" -msgstr "" - -#: ../source/news.rst:150 -msgid "" -"Updated the *Single Sourcing Package Version* tutorial to reflect pip's " -"current strategy. (:pr:`400`)" -msgstr "" - -#: ../source/news.rst:152 -msgid "" -"Added documentation about the ``py_modules`` argument to ``setup``. (:pr:" -"`398`)" -msgstr "" - -#: ../source/news.rst:153 -msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" -msgstr "" - -#: ../source/news.rst:156 -msgid "October 2017" -msgstr "" - -#: ../source/news.rst:158 -msgid "" -"Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" -msgstr "" - -#: ../source/news.rst:159 -msgid "" -"Created a new guide for managing packages using ``pip`` and ``virtualenv``. " -"(:pr:`385`)" -msgstr "" - -#: ../source/news.rst:160 -msgid "Split the specifications page into multiple pages. (:pr:`386`)" -msgstr "" - -#: ../source/news.rst:163 -msgid "September 2017" -msgstr "" - -#: ../source/news.rst:165 -msgid "" -"Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:" -"`379`)" -msgstr "" - -#: ../source/news.rst:167 -msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" -msgstr "" - -#: ../source/news.rst:170 -msgid "August 2017" -msgstr "" - -#: ../source/news.rst:172 -msgid "" -"Added a new, experimental tutorial on installing packages using ``Pipenv``. " -"(:pr:`369`)" -msgstr "" - -#: ../source/news.rst:173 -msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" -msgstr "" - -#: ../source/news.rst:174 -msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" -msgstr "" - -#: ../source/news.rst:177 -msgid "July 2017" -msgstr "" - -#: ../source/news.rst:179 -msgid "Added ``flit`` to the key projects list. (:pr:`358`)" -msgstr "" - -#: ../source/news.rst:180 -msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" -msgstr "" - -#: ../source/news.rst:181 -msgid "" -"Updated this guide's ``readme`` with instructions on how to build the guide " -"locally. (:pr:`356`)" -msgstr "" - -#: ../source/news.rst:182 -msgid "" -"Made the new ``TestPyPI`` URL more visible, adding note to homepage about " -"pypi.org. (:pr:`354`)" -msgstr "" - -#: ../source/news.rst:183 -msgid "" -"Added a note about the removal of the explicit registration API. (:pr:`347`)" -msgstr "" - -#: ../source/news.rst:186 -msgid "June 2017" -msgstr "" - -#: ../source/news.rst:188 -msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" -msgstr "" - -#: ../source/news.rst:189 -msgid "Added documentation for ``python_requires``. (:pr:`338`)" -msgstr "" - -#: ../source/news.rst:190 -msgid "" -"Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:" -"pr:`335`)" -msgstr "" - -#: ../source/news.rst:191 -msgid "" -"Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" -msgstr "" - -#: ../source/news.rst:192 -msgid "Added a license section to the distributing guide. (:pr:`331`)" -msgstr "" - -#: ../source/news.rst:193 -msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" -msgstr "" - -#: ../source/news.rst:194 -msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" -msgstr "" - -#: ../source/news.rst:195 -msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" -msgstr "" - -#: ../source/news.rst:196 -msgid "Switched to the PyPA theme. (:pr:`305`)" -msgstr "" - -#: ../source/news.rst:197 -msgid "Re-organized the documentation into the new structure. (:pr:`318`)" -msgstr "" - -#: ../source/news.rst:200 -msgid "May 2017" -msgstr "" - -#: ../source/news.rst:202 -msgid "" -"Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" -msgstr "" - -#: ../source/news.rst:203 -msgid "Added contributor and style guide. (:pr:`307`)" -msgstr "" - -#: ../source/news.rst:204 -msgid "" -"Documented ``pip`` and ``easy_install``'s differences for per-project " -"indexes. (:pr:`233`)" -msgstr "" - -#: ../source/news.rst:207 -msgid "April 2017" -msgstr "" - -#: ../source/news.rst:209 -msgid "Added travis configuration for testing pull requests. (:pr:`300`)" -msgstr "" - -#: ../source/news.rst:210 -msgid "" -"Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:" -"`299`)" -msgstr "" - -#: ../source/news.rst:211 -msgid "" -"Removed the ``twine register`` reference in the *Distributing Packages* " -"tutorial. (:pr:`271`)" -msgstr "" - -#: ../source/news.rst:212 -msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" -msgstr "" - -#: ../source/news.rst:213 -msgid "Added a topic on namespace packages. (:pr:`290`)" -msgstr "" - -#: ../source/news.rst:214 -msgid "" -"Added documentation explaining prominently how to install ``pip`` in ``/usr/" -"local``. (:pr:`230`)" -msgstr "" - -#: ../source/news.rst:215 -msgid "" -"Updated development mode documentation to mention that order of local " -"packages matters. (:pr:`208`)" -msgstr "" - -#: ../source/news.rst:216 -msgid "" -"Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted " -"projects (:pr:`239`)" -msgstr "" - -#: ../source/news.rst:217 -msgid "" -"Swaped order of :file:`setup.py` arguments for the upload command, as order " -"is significant. (:pr:`260`)" -msgstr "" - -#: ../source/news.rst:219 -msgid "" -"Explained how to install from unsupported sources using a helper " -"application. (:pr:`289`)" -msgstr "" - -#: ../source/news.rst:223 -msgid "March 2017" -msgstr "" - -#: ../source/news.rst:225 -msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" -msgstr "" - -#: ../source/news.rst:228 -msgid "February 2017" -msgstr "" - -#: ../source/news.rst:230 -msgid "Added :pep:`518`. (:pr:`281`)" -msgstr "" - -#: ../source/overview.rst:3 -msgid "An Overview of Packaging for Python" -msgstr "" - -#: ../source/overview.rst:7 -msgid "" -"As a general-purpose programming language, Python is designed to be used in " -"many ways. You can build web sites or industrial robots or a game for your " -"friends to play, and much more, all using the same core technology." -msgstr "" - -#: ../source/overview.rst:12 -msgid "" -"Python's flexibility is why the first step in every Python project must be " -"to think about the project's audience and the corresponding environment " -"where the project will run. It might seem strange to think about packaging " -"before writing code, but this process does wonders for avoiding future " -"headaches." -msgstr "" - -#: ../source/overview.rst:18 -msgid "" -"This overview provides a general-purpose decision tree for reasoning about " -"Python's plethora of packaging options. Read on to choose the best " -"technology for your next project." -msgstr "" - -#: ../source/overview.rst:26 -msgid "Thinking about deployment" -msgstr "" - -#: ../source/overview.rst:28 -msgid "" -"Packages exist to be installed (or *deployed*), so before you package " -"anything, you'll want to have some answers to the deployment questions below:" -msgstr "" - -#: ../source/overview.rst:32 -msgid "" -"Who are your software's users? Will your software be installed by other " -"developers doing software development, operations people in a datacenter, or " -"a less software-savvy group?" -msgstr "" - -#: ../source/overview.rst:35 -msgid "" -"Is your software intended to run on servers, desktops, mobile clients " -"(phones, tablets, etc.), or embedded in dedicated devices?" -msgstr "" - -#: ../source/overview.rst:37 -msgid "" -"Is your software installed individually, or in large deployment batches?" -msgstr "" - -#: ../source/overview.rst:39 -msgid "" -"Packaging is all about target environment and deployment experience. There " -"are many answers to the questions above and each combination of " -"circumstances has its own solutions. With this information, the following " -"overview will guide you to the packaging technologies best suited to your " -"project." -msgstr "" - -#: ../source/overview.rst:46 -msgid "Packaging Python libraries and tools" -msgstr "" - -#: ../source/overview.rst:48 -msgid "" -"You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are " -"just a few of the tools Python's ecosystem provides for distributing Python " -"code to developers, which you can read about in :doc:`guides/distributing-" -"packages-using-setuptools`." -msgstr "" - -#: ../source/overview.rst:53 -msgid "" -"The following approaches to packaging are meant for libraries and tools used " -"by technical audience in a development setting. If you're looking for ways " -"to package Python for a non-technical audience and/or a production setting, " -"skip ahead to :ref:`packaging-applications`." -msgstr "" - -#: ../source/overview.rst:59 -msgid "Python modules" -msgstr "" - -#: ../source/overview.rst:61 -msgid "" -"A Python file, provided it only relies on the standard library, can be " -"redistributed and reused. You will also need to ensure it's written for the " -"right version of Python, and only relies on the standard library." -msgstr "" - -#: ../source/overview.rst:66 -msgid "" -"This is great for sharing simple scripts and snippets between people who " -"both have compatible Python versions (such as via email, StackOverflow, or " -"GitHub gists). There are even some entire Python libraries that offer this " -"as an option, such as `bottle.py `_ and " -"`boltons `_." -msgstr "" - -#: ../source/overview.rst:73 -msgid "" -"However, this pattern won't scale for projects that consist of multiple " -"files, need additional libraries, or need a specific version of Python, " -"hence the options below." -msgstr "" - -#: ../source/overview.rst:78 -msgid "Python source distributions" -msgstr "" - -#: ../source/overview.rst:80 -msgid "" -"If your code consists of multiple Python files, it's usually organized into " -"a directory structure. Any directory containing Python files can comprise " -"an :term:`Import Package`." -msgstr "" - -#: ../source/overview.rst:84 -msgid "" -"Because packages consist of multiple files, they are harder to distribute. " -"Most protocols support transferring only one file at a time (when was the " -"last time you clicked a link and it downloaded multiple files?). It's easier " -"to get incomplete transfers, and harder to guarantee code integrity at the " -"destination." -msgstr "" - -#: ../source/overview.rst:90 -msgid "" -"So long as your code contains nothing but pure Python code, and you know " -"your deployment environment supports your version of Python, then you can " -"use Python's native packaging tools to create a *source* :term:`Distribution " -"Package`, or *sdist* for short." -msgstr "" - -#: ../source/overview.rst:95 -msgid "" -"Python's *sdists* are compressed archives (``.tar.gz`` files) containing one " -"or more packages or modules. If your code is pure-Python, and you only " -"depend on other Python packages, you can `go here to learn more `_." -msgstr "" - -#: ../source/overview.rst:100 -msgid "" -"If you rely on any non-Python code, or non-Python packages (such as `libxml2 " -"`_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next " -"section, which also has many advantages for pure-Python libraries." -msgstr "" - -#: ../source/overview.rst:107 -msgid "" -"Python and PyPI support multiple distributions providing different " -"implementations of the same package. For instance the unmaintained-but-" -"seminal `PIL distribution `_ provides the PIL " -"package, and so does `Pillow `_, an " -"actively-maintained fork of PIL!" -msgstr "" - -#: ../source/overview.rst:114 -msgid "" -"This Python packaging superpower makes it possible for Pillow to be a drop-" -"in replacement for PIL, just by changing your project's ``install_requires`` " -"or ``requirements.txt``." -msgstr "" - -#: ../source/overview.rst:119 -msgid "Python binary distributions" -msgstr "" - -#: ../source/overview.rst:121 -msgid "" -"So much of Python's practical power comes from its ability to integrate with " -"the software ecosystem, in particular libraries written in C, C++, Fortran, " -"Rust, and other languages." -msgstr "" - -#: ../source/overview.rst:125 -msgid "" -"Not all developers have the right tools or experiences to build these " -"components written in these compiled languages, so Python created the :term:" -"`Wheel`, a package format designed to ship libraries with compiled " -"artifacts. In fact, Python's package installer, ``pip``, always prefers " -"wheels because installation is always faster, so even pure-Python packages " -"work better with wheels." -msgstr "" - -#: ../source/overview.rst:132 -msgid "" -"Binary distributions are best when they come with source distributions to " -"match. Even if you don't upload wheels of your code for every operating " -"system, by uploading the sdist, you're enabling users of other platforms to " -"still build it for themselves. Default to publishing both sdist and wheel " -"archives together, *unless* you're creating artifacts for a very specific " -"use case where you know the recipient only needs one or the other." -msgstr "" - -#: ../source/overview.rst:140 -msgid "" -"Python and PyPI make it easy to upload both wheels and sdists together. Just " -"follow the :doc:`tutorials/packaging-projects` tutorial." -msgstr "" - -#: ../source/overview.rst:148 -msgid "" -"Python's recommended built-in library and tool packaging technologies. " -"Excerpted from `The Packaging Gradient (2017) `_." -msgstr "" - -#: ../source/overview.rst:155 -msgid "Packaging Python applications" -msgstr "" - -#: ../source/overview.rst:157 -msgid "" -"So far we've only discussed Python's native distribution tools. Based on our " -"introduction, you would be correct to infer these built-in approaches only " -"target environments which have Python, and an audience who knows how to " -"install Python packages." -msgstr "" - -#: ../source/overview.rst:162 -msgid "" -"With the variety of operating systems, configurations, and people out there, " -"this assumption is only safe when targeting a developer audience." -msgstr "" - -#: ../source/overview.rst:166 -msgid "" -"Python's native packaging is mostly built for distributing reusable code, " -"called libraries, between developers. You can piggyback **tools**, or basic " -"applications for developers, on top of Python's library packaging, using " -"technologies like `setuptools entry_points `_." -msgstr "" - -#: ../source/overview.rst:172 -msgid "" -"Libraries are building blocks, not complete applications. For distributing " -"applications, there's a whole new world of technologies out there." -msgstr "" - -#: ../source/overview.rst:176 -msgid "" -"The next few sections organize these application packaging options according " -"to their dependencies on the target environment, so you can choose the right " -"one for your project." -msgstr "" - -#: ../source/overview.rst:181 -msgid "Depending on a framework" -msgstr "" - -#: ../source/overview.rst:183 -msgid "" -"Some types of Python applications, like web site backends and other network " -"services, are common enough that they have frameworks to enable their " -"development and packaging. Other types of applications, like dynamic web " -"frontends and mobile clients, are complex enough to target that a framework " -"becomes more than a convenience." -msgstr "" - -#: ../source/overview.rst:189 -msgid "" -"In all these cases, it makes sense to work backwards, from the framework's " -"packaging and deployment story. Some frameworks include a deployment system " -"which wraps the technologies outlined in the rest of the guide. In these " -"cases, you'll want to defer to your framework's packaging guide for the " -"easiest and most reliable production experience." -msgstr "" - -#: ../source/overview.rst:195 -msgid "" -"If you ever wonder how these platforms and frameworks work under the hood, " -"you can always read the sections beyond." -msgstr "" - -#: ../source/overview.rst:199 -msgid "Service platforms" -msgstr "" - -#: ../source/overview.rst:201 -msgid "" -"If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku " -"or Google App Engine, you are going to want to follow their respective " -"packaging guides." -msgstr "" - -#: ../source/overview.rst:205 -msgid "" -"`Heroku `_" -msgstr "" - -#: ../source/overview.rst:206 -msgid "`Google App Engine `_" -msgstr "" - -#: ../source/overview.rst:207 -msgid "`PythonAnywhere `_" -msgstr "" - -#: ../source/overview.rst:208 -msgid "`OpenShift `_" -msgstr "`OpenShift `_" - -#: ../source/overview.rst:209 -msgid "\"Serverless\" frameworks like `Zappa `_" -msgstr "" - -#: ../source/overview.rst:211 -msgid "" -"In all these setups, the platform takes care of packaging and deployment, as " -"long as you follow their patterns. Most software does not fit one of these " -"templates, hence the existence of all the other options below." -msgstr "" - -#: ../source/overview.rst:216 -msgid "" -"If you're developing software that will be deployed to machines you own, " -"users' personal computers, or any other arrangement, read on." -msgstr "" - -#: ../source/overview.rst:220 -msgid "Web browsers and mobile applications" -msgstr "" - -#: ../source/overview.rst:222 -msgid "" -"Python's steady advances are leading it into new spaces. These days you can " -"write a mobile app or web application frontend in Python. While the language " -"may be familiar, the packaging and deployment practices are brand new." -msgstr "" - -#: ../source/overview.rst:227 -msgid "" -"If you're planning on releasing to these new frontiers, you'll want to check " -"out the following frameworks, and refer to their packaging guides:" -msgstr "" - -#: ../source/overview.rst:231 -msgid "`Kivy `_" -msgstr "" - -#: ../source/overview.rst:232 -msgid "`Beeware `_" -msgstr "" - -#: ../source/overview.rst:233 -msgid "`Brython `_" -msgstr "" - -#: ../source/overview.rst:234 -msgid "`Flexx `_" -msgstr "" - -#: ../source/overview.rst:236 -msgid "" -"If you are *not* interested in using a framework or platform, or just wonder " -"about some of the technologies and techniques utilized by the frameworks " -"above, continue reading below." -msgstr "" - -#: ../source/overview.rst:241 -msgid "Depending on a pre-installed Python" -msgstr "" - -#: ../source/overview.rst:243 -msgid "" -"Pick an arbitrary computer, and depending on the context, there's a very " -"good chance Python is already installed. Included by default in most Linux " -"and Mac operating systems for many years now, you can reasonably depend on " -"Python preexisting in your data centers or on the personal machines of " -"developers and data scientists." -msgstr "" - -#: ../source/overview.rst:249 -msgid "Technologies which support this model:" -msgstr "" - -#: ../source/overview.rst:251 -msgid "`PEX `_ (Python EXecutable)" -msgstr "" - -#: ../source/overview.rst:252 -msgid "" -"`zipapp `_ (does not help " -"manage dependencies, requires Python 3.5+)" -msgstr "" - -#: ../source/overview.rst:253 -msgid "`shiv `_ (requires Python 3)" -msgstr "" - -#: ../source/overview.rst:255 -msgid "" -"Of all the approaches here, depending on a pre-installed Python relies the " -"most on the target environment. Of course, this also makes for the smallest " -"package, as small as single-digit megabytes, or even kilobytes." -msgstr "" - -#: ../source/overview.rst:260 -msgid "" -"In general, decreasing the dependency on the target system increases the " -"size of our package, so the solutions here are roughly arranged by " -"increasing size of output." -msgstr "" - -#: ../source/overview.rst:267 -msgid "Depending on a separate software distribution ecosystem" -msgstr "" - -#: ../source/overview.rst:269 -msgid "" -"For a long time many operating systems, including Mac and Windows, lacked " -"built-in package management. Only recently did these OSes gain so-called " -"\"app stores\", but even those focus on consumer applications and offer " -"little for developers." -msgstr "" - -#: ../source/overview.rst:274 -msgid "" -"Developers long sought remedies, and in this struggle, emerged with their " -"own package management solutions, such as `Homebrew `_. " -"The most relevant alternative for Python developers is a package ecosystem " -"called `Anaconda `_. Anaconda is built around Python and is " -"increasingly common in academic, analytical, and other data-oriented " -"environments, even making its way `into server-oriented environments " -"`_." -msgstr "" - -#: ../source/overview.rst:284 -msgid "Instructions on building and publishing for the Anaconda ecosystem:" -msgstr "" - -#: ../source/overview.rst:286 -msgid "" -"`Building libraries and applications with conda `_" -msgstr "" - -#: ../source/overview.rst:287 -msgid "" -"`Transitioning a native Python package to Anaconda `_" -msgstr "" - -#: ../source/overview.rst:289 -msgid "" -"A similar model involves installing an alternative Python distribution, but " -"does not support arbitrary operating system-level packages:" -msgstr "" - -#: ../source/overview.rst:293 -msgid "`Enthought Canopy `_" -msgstr "" - -#: ../source/overview.rst:294 -msgid "`ActiveState ActivePython `_" -msgstr "" - -#: ../source/overview.rst:295 -msgid "`WinPython `_" -msgstr "" - -#: ../source/overview.rst:300 -msgid "Bringing your own Python executable" -msgstr "" - -#: ../source/overview.rst:302 -msgid "" -"Computing as we know it is defined by the ability to execute programs. Every " -"operating system natively supports one or more formats of program they can " -"natively execute." -msgstr "" - -#: ../source/overview.rst:306 -msgid "" -"There are many techniques and technologies which turn your Python program " -"into one of these formats, most of which involve embedding the Python " -"interpreter and any other dependencies into a single executable file." -msgstr "" - -#: ../source/overview.rst:311 -msgid "" -"This approach, called *freezing*, offers wide compatibility and seamless " -"user experience, though often requires multiple technologies, and a good " -"amount of effort." -msgstr "" - -#: ../source/overview.rst:315 -msgid "A selection of Python freezers:" -msgstr "" - -#: ../source/overview.rst:317 -msgid "`pyInstaller `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:318 -msgid "" -"`cx_Freeze `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:319 -msgid "" -"`constructor `_ - For command-line " -"installers" -msgstr "" - -#: ../source/overview.rst:320 -msgid "`py2exe `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:321 -msgid "`py2app `_ - Mac only" -msgstr "" - -#: ../source/overview.rst:322 -msgid "" -"`bbFreeze `_ - Windows, Linux, Python 2 " -"only" -msgstr "" - -#: ../source/overview.rst:323 -msgid "`osnap `_ - Windows and Mac" -msgstr "" - -#: ../source/overview.rst:324 -msgid "`pynsist `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:326 -msgid "" -"Most of the above imply single-user deployments. For multi-component server " -"applications, see `Chef Omnibus `_." -msgstr "" - -#: ../source/overview.rst:332 -msgid "Bringing your own userspace" -msgstr "" - -#: ../source/overview.rst:334 -msgid "" -"An increasing number of operating systems -- including Linux, Mac OS, and " -"Windows -- can be set up to run applications packaged as lightweight images, " -"using a relatively modern arrangement often referred to as `operating-system-" -"level virtualization `_, or *containerization*." -msgstr "" - -#: ../source/overview.rst:341 -msgid "" -"These techniques are mostly Python agnostic, because they package whole OS " -"filesystems, not just Python or Python packages." -msgstr "" - -#: ../source/overview.rst:344 -msgid "" -"Adoption is most extensive among Linux servers, where the technology " -"originated and where the technologies below work best:" -msgstr "" - -#: ../source/overview.rst:347 -msgid "`AppImage `_" -msgstr "" - -#: ../source/overview.rst:348 -msgid "`Docker `_" -msgstr "" - -#: ../source/overview.rst:349 -msgid "`Flatpak `_" -msgstr "" - -#: ../source/overview.rst:350 -msgid "`Snapcraft `_" -msgstr "" - -#: ../source/overview.rst:353 -msgid "Bringing your own kernel" -msgstr "" - -#: ../source/overview.rst:355 -msgid "" -"Most operating systems support some form of classical virtualization, " -"running applications packaged as images containing a full operating system " -"of their own. Running these virtual machines, or VMs, is a mature approach, " -"widespread in data center environments." -msgstr "" - -#: ../source/overview.rst:360 -msgid "" -"These techniques are mostly reserved for larger scale deployments in data " -"centers, though certain complex applications can benefit from this " -"packaging. Technologies are Python agnostic, and include:" -msgstr "" - -#: ../source/overview.rst:364 -msgid "`Vagrant `_" -msgstr "" - -#: ../source/overview.rst:365 -msgid "" -"`VHD `_, `AMI `_, and `other formats `_" -msgstr "" - -#: ../source/overview.rst:366 -msgid "" -"`OpenStack `_ - A cloud " -"management system in Python, with extensive VM support" -msgstr "" - -#: ../source/overview.rst:369 -msgid "Bringing your own hardware" -msgstr "" - -#: ../source/overview.rst:371 -msgid "" -"The most all-encompassing way to ship your software would be to ship it " -"already-installed on some hardware. This way, your software's user would " -"require only electricity." -msgstr "" - -#: ../source/overview.rst:375 -msgid "" -"Whereas the virtual machines described above are primarily reserved for the " -"tech-savvy, you can find hardware appliances being used by everyone from the " -"most advanced data centers to the youngest children." -msgstr "" - -#: ../source/overview.rst:379 -msgid "" -"Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the " -"datacenter or your users' homes. They plug and play, and you can call it a " -"day." -msgstr "" - -#: ../source/overview.rst:389 -msgid "" -"The simplified gamut of technologies used to package Python applications." -msgstr "" - -#: ../source/overview.rst:392 -msgid "What about..." -msgstr "" - -#: ../source/overview.rst:394 -msgid "" -"The sections above can only summarize so much, and you might be wondering " -"about some of the more conspicuous gaps." -msgstr "" - -#: ../source/overview.rst:398 -msgid "Operating system packages" -msgstr "" - -#: ../source/overview.rst:400 -msgid "" -"As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some " -"operating systems have package managers of their own. If you're very sure of " -"the operating system you're targeting, you can depend directly on a format " -"like `deb `_ (for Debian, " -"Ubuntu, etc.) or `RPM `_ " -"(for Red Hat, Fedora, etc.), and use that built-in package manager to take " -"care of installation, and even deployment. You can even use `FPM `_ to generate both deb " -"and RPMs from the same source." -msgstr "" - -#: ../source/overview.rst:411 -msgid "" -"In most deployment pipelines, the OS package manager is just one piece of " -"the puzzle." -msgstr "" - -#: ../source/overview.rst:417 -msgid "" -"`Virtualenvs `_ have been an indispensable tool for multiple generations of Python " -"developer, but are slowly fading from view, as they are being wrapped by " -"higher-level tools. With packaging in particular, virtualenvs are used as a " -"primitive in `the dh-virtualenv tool `_ and `osnap `_, " -"both of which wrap virtualenvs in a self-contained way." -msgstr "" - -#: ../source/overview.rst:427 -msgid "" -"For production deployments, do not rely on running ``python -m pip install`` " -"from the Internet into a virtualenv, as one might do in a development " -"environment. The overview above is full of much better solutions." -msgstr "" - -#: ../source/overview.rst:432 -msgid "Security" -msgstr "安全" - -#: ../source/overview.rst:434 -msgid "" -"The further down the gradient you come, the harder it gets to update " -"components of your package. Everything is more tightly bound together." -msgstr "" - -#: ../source/overview.rst:437 -msgid "" -"For example, if a kernel security issue emerges, and you're deploying " -"containers, the host system's kernel can be updated without requiring a new " -"build on behalf of the application. If you deploy VM images, you'll need a " -"new build. Whether or not this dynamic makes one option more secure is still " -"a bit of an old debate, going back to the still-unsettled matter of `static " -"versus dynamic linking `_." -msgstr "" - -#: ../source/overview.rst:446 -msgid "Wrap up" -msgstr "" - -#: ../source/overview.rst:448 -msgid "" -"Packaging in Python has a bit of a reputation for being a bumpy ride. This " -"impression is mostly a byproduct of Python's versatility. Once you " -"understand the natural boundaries between each packaging solution, you begin " -"to realize that the varied landscape is a small price Python programmers pay " -"for using one of the most balanced, flexible languages available." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:6 -msgid "Binary distribution format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:8 -msgid "" -"The binary distribution format (:term:`wheel `) was originally " -"defined in :pep:`427`. The current version of the specification is here." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:13 -msgid "Abstract" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:15 -msgid "This PEP describes a built-package format for Python called \"wheel\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:17 -msgid "" -"A wheel is a ZIP-format archive with a specially formatted file name and the " -"``.whl`` extension. It contains a single distribution nearly as it would be " -"installed according to PEP 376 with a particular installation scheme. " -"Although a specialized installer is recommended, a wheel file may be " -"installed by simply unpacking into site-packages with the standard 'unzip' " -"tool while preserving enough information to spread its contents out onto " -"their final paths at any later time." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:27 -msgid "PEP Acceptance" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:29 -msgid "" -"This PEP was accepted, and the defined wheel version updated to 1.0, by Nick " -"Coghlan on 16th February, 2013 [1]_" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:34 -msgid "Rationale" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:36 -msgid "" -"Python needs a package format that is easier to install than sdist. Python's " -"sdist packages are defined by and require the distutils and setuptools build " -"systems, running arbitrary code to build-and-install, and re-compile, code " -"just so it can be installed into a new virtualenv. This system of " -"conflating build-install is slow, hard to maintain, and hinders innovation " -"in both build systems and installers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:43 -msgid "" -"Wheel attempts to remedy these problems by providing a simpler interface " -"between the build system and the installer. The wheel binary package format " -"frees installers from having to know about the build system, saves time by " -"amortizing compile time over many installations, and removes the need to " -"install a build system in the target environment." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:52 -msgid "Details" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:55 -msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:57 -msgid "Wheel installation notionally consists of two phases:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:59 -msgid "Unpack." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:61 -msgid "Parse ``distribution-1.0.dist-info/WHEEL``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:62 -msgid "" -"Check that installer is compatible with Wheel-Version. Warn if minor " -"version is greater, abort if major version is greater." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:64 -msgid "" -"If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:66 -msgid "Else unpack archive into platlib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:68 -msgid "Spread." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:70 -msgid "" -"Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is " -"data) ``distribution-1.0.data/``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:72 -msgid "" -"Move each subtree of ``distribution-1.0.data/`` onto its destination path. " -"Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of " -"destination directories, such as ``distribution-1.0.data/(purelib|platlib|" -"headers|scripts|data)``. The initially supported paths are taken from " -"``distutils.command.install``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:78 -msgid "" -"If applicable, update scripts starting with ``#!python`` to point to the " -"correct interpreter." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:80 -msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:82 -msgid "Remove empty ``distribution-1.0.data`` directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:83 -msgid "" -"Compile any installed .py to .pyc. (Uninstallers should be smart enough to " -"remove .pyc even if it is not mentioned in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:87 -msgid "Recommended installer features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:97 -msgid "Rewrite ``#!python``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:90 -msgid "" -"In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/" -"``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!" -"python'``, rewrite to point to the correct interpreter. Unix installers may " -"need to add the +x bit to these files if the archive was created on Windows." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:96 -msgid "" -"The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI " -"script instead of a console script." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:102 -msgid "Generate script wrappers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:100 -msgid "" -"In wheel, scripts packaged on Unix systems will certainly not have " -"accompanying .exe wrappers. Windows installers may want to add them during " -"install." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:105 -msgid "Recommended archiver features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:112 -msgid "Place ``.dist-info`` at the end of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:108 -msgid "" -"Archivers are encouraged to place the ``.dist-info`` files physically at the " -"end of the archive. This enables some potentially interesting ZIP tricks " -"including the ability to amend the metadata without rewriting the entire " -"archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:115 -msgid "File Format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:118 -msgid "File name convention" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:120 -msgid "" -"The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-" -"{abi tag}-{platform tag}.whl``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "distribution" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "Distribution name, e.g. 'django', 'pyramid'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "Distribution version, e.g. 1.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:135 -msgid "build tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:130 -msgid "" -"Optional build number. Must start with a digit. Acts as a tie-breaker if " -"two wheel file names are the same in all other respects (i.e. name, version, " -"and other tags). Sort as an empty tuple if unspecified, else sort as a two-" -"item tuple with the first item being the initial digits as an ``int``, and " -"the second item being the remainder of the tag as a ``str``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "language implementation and version tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "E.g. 'py27', 'py2', 'py3'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "abi tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "E.g. 'cp33m', 'abi3', 'none'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "platform tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "E.g. 'linux_x86_64', 'any'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:146 -msgid "" -"For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of " -"a package called 'distribution', and is compatible with Python 2.7 (any " -"Python 2.7 implementation), with no ABI (pure Python), on any CPU " -"architecture." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:151 -msgid "" -"The last three components of the filename before the extension are called " -"\"compatibility tags.\" The compatibility tags express the package's basic " -"interpreter requirements and are detailed in PEP 425." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:156 -msgid "Escaping and Unicode" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:158 -msgid "" -"As the components of the filename are separated by a dash (``-``, HYPHEN-" -"MINUS), this character cannot appear within any component. This is handled " -"as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:161 -msgid "" -"In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE " -"and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent " -"to :pep:`503` normalisation followed by replacing ``-`` with ``_``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:164 -msgid "" -"Version numbers should be normalised according to :pep:`440`. Normalised " -"version numbers cannot contain ``-``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:166 -msgid "" -"The remaining components may not contain ``-`` characters, so no escaping is " -"necessary." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:169 -msgid "" -"Tools producing wheels should verify that the filename components do not " -"contain ``-``, as the resulting file may not be processed correctly if they " -"do." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:172 -msgid "" -"The archive filename is Unicode. It will be some time before the tools are " -"updated to support non-ASCII filenames, but they are supported in this " -"specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:176 -msgid "" -"The filenames *inside* the archive are encoded as UTF-8. Although some ZIP " -"clients in common use do not properly display UTF-8 filenames, the encoding " -"is supported by both the ZIP specification and Python's ``zipfile``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:182 -msgid "File contents" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:184 -msgid "" -"The contents of a wheel file, where {distribution} is replaced with the name " -"of the package, e.g. ``beaglevote`` and {version} is replaced with its " -"version, e.g. ``1.0.0``, consist of:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:188 -msgid "" -"``/``, the root of the archive, contains all files to be installed in " -"``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and " -"``platlib`` are usually both ``site-packages``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:191 -msgid "``{distribution}-{version}.dist-info/`` contains metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:192 -msgid "" -"``{distribution}-{version}.data/`` contains one subdirectory for each non-" -"empty install scheme key not already covered, where the subdirectory name is " -"an index into a dictionary of install paths (e.g. ``data``, ``scripts``, " -"``include``, ``purelib``, ``platlib``)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:196 -msgid "" -"Python scripts must appear in ``scripts`` and begin with exactly ``b'#!" -"python'`` in order to enjoy script wrapper generation and ``#!python`` " -"rewriting at install time. They may have any or no extension." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:200 -msgid "" -"``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or " -"greater format metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:202 -msgid "" -"``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive " -"itself in the same basic key: value format::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:212 -msgid "``Wheel-Version`` is the version number of the Wheel specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:213 -msgid "" -"``Generator`` is the name and optionally the version of the software that " -"produced the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:215 -msgid "" -"``Root-Is-Purelib`` is true if the top level directory of the archive should " -"be installed into purelib; otherwise the root should be installed into " -"platlib." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:218 -msgid "" -"``Tag`` is the wheel's expanded compatibility tags; in the example the " -"filename would contain ``py2.py3-none-any``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:220 -msgid "" -"``Build`` is the build number and is omitted if there is no build number." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:221 -msgid "" -"A wheel installer should warn if Wheel-Version is greater than the version " -"it supports, and must fail if Wheel-Version has a greater major version than " -"the version it supports." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:224 -msgid "" -"Wheel, being an installation format that is intended to work across multiple " -"versions of Python, does not generally include .pyc files." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:226 -msgid "Wheel does not contain setup.py or setup.cfg." -msgstr "Wheel 不包含 setup.py 或 setup.cfg。" - -#: ../source/specifications/binary-distribution-format.rst:228 -msgid "" -"This version of the wheel specification is based on the distutils install " -"schemes and does not define how to install files to other locations. The " -"layout offers a superset of the functionality provided by the existing " -"wininst and egg binary formats." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:235 -#: ../source/specifications/recording-installed-packages.rst:35 -msgid "The .dist-info directory" -msgstr "目录 .dist-info" - -#: ../source/specifications/binary-distribution-format.rst:237 -msgid "" -"Wheel .dist-info directories include at a minimum METADATA, WHEEL, and " -"RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:239 -msgid "" -"METADATA is the package metadata, the same format as PKG-INFO as found at " -"the root of sdists." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:241 -msgid "WHEEL is the wheel metadata specific to a build of the package." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:242 -msgid "" -"RECORD is a list of (almost) all the files in the wheel and their secure " -"hashes. Unlike PEP 376, every file except RECORD, which cannot contain a " -"hash of itself, must include its hash. The hash algorithm must be sha256 or " -"better; specifically, md5 and sha1 are not permitted, as signed wheel files " -"rely on the strong hashes in RECORD to validate the integrity of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:248 -msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:249 -msgid "" -"RECORD.jws is used for digital signatures. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:251 -msgid "" -"RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME " -"signatures to secure their wheel files. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:254 -msgid "" -"During extraction, wheel installers verify all the hashes in RECORD against " -"the file contents. Apart from RECORD and its signatures, installation will " -"fail if any file in the archive is not both mentioned and correctly hashed " -"in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:261 -msgid "The .data directory" -msgstr ".data 目录" - -#: ../source/specifications/binary-distribution-format.rst:263 -msgid "" -"Any file that is not normally installed inside site-packages goes into the ." -"data directory, named as the .dist-info directory but with the .data/ " -"extension::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:271 -msgid "" -"The .data directory contains subdirectories with the scripts, headers, " -"documentation and so forth from the distribution. During installation the " -"contents of these subdirectories are moved onto their destination paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:277 -msgid "Signed wheel files" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:279 -msgid "" -"Wheel files include an extended RECORD that enables digital signatures. PEP " -"376's RECORD is altered to include a secure hash " -"``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with " -"no trailing = characters) as the second column instead of an md5sum. All " -"possible entries are hashed, including any generated files such as .pyc " -"files, but not RECORD which cannot contain its own hash. For example::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:290 -msgid "" -"The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD " -"at all since they can only be added after RECORD is generated. Every other " -"file in the archive must have a correct hash in RECORD or the installation " -"will fail." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:295 -msgid "" -"If JSON web signatures are used, one or more JSON Web Signature JSON " -"Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to " -"RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD " -"as the signature's JSON payload::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:302 -msgid "(The hash value is the same format used in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:304 -msgid "" -"If RECORD.p7s is used, it must contain a detached S/MIME format signature of " -"RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:307 -msgid "" -"A wheel installer is not required to understand digital signatures but MUST " -"verify the hashes in RECORD against the extracted file contents. When the " -"installer checks file hashes against RECORD, a separate signature checker " -"only needs to establish that RECORD matches the signature." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:312 -msgid "See" -msgstr "见" - -#: ../source/specifications/binary-distribution-format.rst:314 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" -msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" - -#: ../source/specifications/binary-distribution-format.rst:315 -msgid "" -"http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" -msgstr "" -"http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" - -#: ../source/specifications/binary-distribution-format.rst:316 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" -msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" - -#: ../source/specifications/binary-distribution-format.rst:317 -msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" -msgstr "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" - -#: ../source/specifications/binary-distribution-format.rst:321 -msgid "Comparison to .egg" -msgstr "与 .egg 的比较" - -#: ../source/specifications/binary-distribution-format.rst:323 -msgid "" -"Wheel is an installation format; egg is importable. Wheel archives do not " -"need to include .pyc and are less tied to a specific Python version or " -"implementation. Wheel can install (pure Python) packages built with previous " -"versions of Python so you don't always have to wait for the packager to " -"catch up." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:328 -msgid "" -"Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible " -"with the new world of Python packaging and the new concepts it brings." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:331 -msgid "" -"Wheel has a richer file naming convention for today's multi-implementation " -"world. A single wheel archive can indicate its compatibility with a number " -"of Python language versions and implementations, ABIs, and system " -"architectures. Historically the ABI has been specific to a CPython release, " -"wheel is ready for the stable ABI." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:337 -msgid "" -"Wheel is lossless. The first wheel implementation bdist_wheel always " -"generates egg-info, and then converts it to a .whl. It is also possible to " -"convert existing eggs and bdist_wininst distributions." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:341 -msgid "" -"Wheel is versioned. Every wheel file contains the version of the wheel " -"specification and the implementation that packaged it. Hopefully the next " -"migration can simply be to Wheel 2.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:344 -msgid "Wheel is a reference to the other Python." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:348 -msgid "FAQ" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:352 -msgid "Wheel defines a .data directory. Should I put all my data there?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:354 -msgid "" -"This specification does not have an opinion on how you should organize your " -"code. The .data directory is just a place for any files that are not " -"normally installed inside ``site-packages`` or on the PYTHONPATH. In other " -"words, you may continue to use ``pkgutil.get_data(package, resource)`` even " -"though *those* files will usually not be distributed in *wheel's* ``.data`` " -"directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:363 -msgid "Why does wheel include attached signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:365 -msgid "" -"Attached signatures are more convenient than detached signatures because " -"they travel with the archive. Since only the individual files are signed, " -"the archive can be recompressed without invalidating the signature or " -"individual files can be verified without having to download the whole " -"archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:373 -msgid "Why does wheel allow JWS signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:375 -msgid "" -"The JOSE specifications of which JWS is a part are designed to be easy to " -"implement, a feature that is also one of wheel's primary design goals. JWS " -"yields a useful, concise pure-Python implementation." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:381 -msgid "Why does wheel also allow S/MIME signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:383 -msgid "" -"S/MIME signatures are allowed for users who need or want to use existing " -"public key infrastructure with wheel." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:386 -msgid "" -"Signed packages are only a basic building block in a secure package update " -"system. Wheel only provides the building block." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:391 -msgid "What's the deal with \"purelib\" vs. \"platlib\"?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:393 -msgid "" -"Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is " -"significant on some platforms. For example, Fedora installs pure Python " -"packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent " -"packages to '/usr/lib64/pythonX.Y/site-packages'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:398 -msgid "" -"A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-" -"{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: " -"true\" with those same files in the root, and it is legal to have files in " -"both the \"purelib\" and \"platlib\" categories." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:403 -msgid "" -"In practice a wheel should have only one of \"purelib\" or \"platlib\" " -"depending on whether it is pure Python or not and those files should be at " -"the root with the appropriate setting given for \"Root-is-purelib\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:409 -msgid "Is it possible to import Python code directly from a wheel file?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:411 -msgid "" -"Technically, due to the combination of supporting installation via simple " -"extraction and using an archive format that is compatible with " -"``zipimport``, a subset of wheel files *do* support being placed directly on " -"``sys.path``. However, while this behaviour is a natural consequence of the " -"format design, actually relying on it is generally discouraged." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:417 -msgid "" -"Firstly, wheel *is* designed primarily as a distribution format, so skipping " -"the installation step also means deliberately avoiding any reliance on " -"features that assume full installation (such as being able to use standard " -"tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in " -"a way that can be properly tracked for auditing and security update " -"purposes, or integrating fully with the standard build machinery for C " -"extensions by publishing header files in the appropriate place)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:426 -msgid "" -"Secondly, while some Python software is written to support running directly " -"from a zip archive, it is still common for code to be written assuming it " -"has been fully installed. When that assumption is broken by trying to run " -"the software from a zip archive, the failures can often be obscure and hard " -"to diagnose (especially when they occur in third party libraries). The two " -"most common sources of problems with this are the fact that importing C " -"extensions from a zip archive is *not* supported by CPython (since doing so " -"is not supported directly by the dynamic loading machinery on any platform) " -"and that when running from a zip archive the ``__file__`` attribute no " -"longer refers to an ordinary filesystem path, but to a combination path that " -"includes both the location of the zip archive on the filesystem and the " -"relative path to the module inside the archive. Even when software correctly " -"uses the abstract resource APIs internally, interfacing with external " -"components may still require the availability of an actual on-disk file." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:443 -msgid "" -"Like metaclasses, monkeypatching and metapath importers, if you're not " -"already sure you need to take advantage of this feature, you almost " -"certainly don't need it. If you *do* decide to use it anyway, be aware that " -"many projects will require a failure to be reproduced with a fully installed " -"package before accepting it as a genuine bug." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:450 -msgid "Changes" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:452 -msgid "Since :pep:`427`, this specification has changed as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:454 -msgid "" -"The rules on escaping in wheel filenames were revised, to bring them into " -"line with what popular tools actually do (February 2021)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:461 -msgid "" -"PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-" -"February/124103.html)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:466 -msgid "Appendix" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:468 -msgid "Example urlsafe-base64-nopad implementation::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:482 -msgid "Copyright" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:484 -msgid "This document has been placed into the public domain." -msgstr "" - -#: ../source/specifications/core-metadata.rst:5 -msgid "Core metadata specifications" -msgstr "" - -#: ../source/specifications/core-metadata.rst:7 -msgid "" -"Fields defined in the following specification should be considered valid, " -"complete and not subject to change. The required fields are:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:10 -msgid "``Metadata-Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:11 -msgid "``Name``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:12 -msgid "``Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:14 -msgid "All the other fields are optional." -msgstr "" - -#: ../source/specifications/core-metadata.rst:16 -msgid "" -"The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats " -"have been revised several times, and exactly which email RFC applies to " -"packaging metadata is not specified. In the absence of a precise definition, " -"the practical standard is set by what the standard library :mod:`python:" -"email.parser` module can parse using the :data:`~.python:email.policy." -"compat32` policy." -msgstr "" - -#: ../source/specifications/core-metadata.rst:25 -msgid "" -"Although :pep:`566` defined a way to transform metadata into a JSON-" -"compatible dictionary, this is not yet used as a standard interchange " -"format. The need for tools to work with years worth of existing packages " -"makes it difficult to shift to a new format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:30 -msgid "" -"*Interpreting old metadata:* In :pep:`566`, the version specifier field " -"format specification was relaxed to accept the syntax used by popular " -"publishing tools (namely to remove the requirement that version specifiers " -"must be surrounded by parentheses). Metadata consumers may want to use the " -"more relaxed formatting rules even for metadata files that are nominally " -"less than version 2.1." -msgstr "" - -#: ../source/specifications/core-metadata.rst:41 -msgid "Metadata-Version" -msgstr "" - -#: ../source/specifications/core-metadata.rst:45 -msgid "" -"Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", " -"\"2.1\" and \"2.2\"." -msgstr "" - -#: ../source/specifications/core-metadata.rst:48 -msgid "" -"Automated tools consuming metadata SHOULD warn if ``metadata_version`` is " -"greater than the highest version they support, and MUST fail if " -"``metadata_version`` has a greater major version than the highest version " -"they support (as described in :pep:`440`, the major version is the value " -"before the first dot)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:54 -msgid "" -"For broader compatibility, build tools MAY choose to produce distribution " -"metadata using the lowest metadata version that includes all of the needed " -"fields." -msgstr "" - -#: ../source/specifications/core-metadata.rst:58 -#: ../source/specifications/core-metadata.rst:80 -#: ../source/specifications/core-metadata.rst:95 -#: ../source/specifications/core-metadata.rst:155 -#: ../source/specifications/core-metadata.rst:170 -#: ../source/specifications/core-metadata.rst:208 -#: ../source/specifications/core-metadata.rst:283 -#: ../source/specifications/core-metadata.rst:287 -#: ../source/specifications/core-metadata.rst:291 -#: ../source/specifications/core-metadata.rst:295 -#: ../source/specifications/core-metadata.rst:327 -#: ../source/specifications/core-metadata.rst:347 -#: ../source/specifications/core-metadata.rst:373 -#: ../source/specifications/core-metadata.rst:391 -#: ../source/specifications/core-metadata.rst:416 -#: ../source/specifications/core-metadata.rst:438 -#: ../source/specifications/core-metadata.rst:600 -#: ../source/specifications/core-metadata.rst:620 -#: ../source/specifications/core-metadata.rst:630 -msgid "Example::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:66 -msgid "Name" -msgstr "名称" - -#: ../source/specifications/core-metadata.rst:69 -msgid "Added additional restrictions on format from :pep:`508`" -msgstr "" - -#: ../source/specifications/core-metadata.rst:72 -msgid "" -"The name of the distribution. The name field is the primary identifier for a " -"distribution. A valid name consists only of ASCII letters and numbers, " -"period, underscore and hyphen. It must start and end with a letter or " -"number. Distribution names are limited to those which match the following " -"regex (run with ``re.IGNORECASE``)::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:88 -msgid "Version" -msgstr "版本" - -#: ../source/specifications/core-metadata.rst:92 -msgid "" -"A string containing the distribution's version number. This field must be " -"in the format specified in :pep:`440`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:101 -msgid "Dynamic (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:105 -msgid "" -"A string containing the name of another core metadata field. The field names " -"``Name`` and ``Version`` may not be specified in this field." -msgstr "" - -#: ../source/specifications/core-metadata.rst:108 -msgid "" -"When found in the metadata of a source distribution, the following rules " -"apply:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:111 -msgid "" -"If a field is *not* marked as ``Dynamic``, then the value of the field in " -"any wheel built from the sdist MUST match the value in the sdist. If the " -"field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT " -"be present in the wheel." -msgstr "" - -#: ../source/specifications/core-metadata.rst:115 -msgid "" -"If a field is marked as ``Dynamic``, it may contain any valid value in a " -"wheel built from the sdist (including not being present at all)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:118 -msgid "" -"If the sdist metadata version is older than version 2.2, then all fields " -"should be treated as if they were specified with ``Dynamic`` (i.e. there are " -"no special restrictions on the metadata of wheels built from the sdist)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:122 -msgid "" -"In any context other than a source distribution, ``Dynamic`` is for " -"information only, and indicates that the field value was calculated at wheel " -"build time, and may not be the same as the value in the sdist or in other " -"wheels for the project." -msgstr "" - -#: ../source/specifications/core-metadata.rst:127 -msgid "" -"Full details of the semantics of ``Dynamic`` are described in :pep:`643`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:131 -msgid "Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:135 -msgid "" -"A Platform specification describing an operating system supported by the " -"distribution which is not listed in the \"Operating System\" Trove " -"classifiers. See \"Classifier\" below." -msgstr "" - -#: ../source/specifications/core-metadata.rst:146 -msgid "Supported-Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:150 -msgid "" -"Binary distributions containing a PKG-INFO file will use the Supported-" -"Platform field in their metadata to specify the OS and CPU for which the " -"binary distribution was compiled. The semantics of the Supported-Platform " -"field are not specified in this PEP." -msgstr "" - -#: ../source/specifications/core-metadata.rst:164 -msgid "Summary" -msgstr "" - -#: ../source/specifications/core-metadata.rst:168 -msgid "A one-line summary of what the distribution does." -msgstr "" - -#: ../source/specifications/core-metadata.rst:188 -msgid "This field may be specified in the message body instead." -msgstr "" - -#: ../source/specifications/core-metadata.rst:191 -msgid "" -"A longer description of the distribution that can run to several " -"paragraphs. Software that deals with metadata should not assume any maximum " -"size for this field, though people shouldn't include their instruction " -"manual as the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:196 -msgid "" -"The contents of this field can be written using reStructuredText markup " -"[1]_. For programs that work with the metadata, supporting markup is " -"optional; programs can also display the contents of the field as-is. This " -"means that authors should be conservative in the markup they use." -msgstr "" - -#: ../source/specifications/core-metadata.rst:202 -msgid "" -"To support empty lines and lines with indentation with respect to the RFC " -"822 format, any CRLF character has to be suffixed by 7 spaces followed by a " -"pipe (\"|\") char. As a result, the Description field is encoded into a " -"folded field that can be interpreted by RFC822 parser [2]_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:219 -msgid "" -"This encoding implies that any occurrences of a CRLF followed by 7 spaces " -"and a pipe char have to be replaced by a single CRLF when the field is " -"unfolded using a RFC822 reader." -msgstr "" - -#: ../source/specifications/core-metadata.rst:223 -msgid "" -"Alternatively, the distribution's description may instead be provided in the " -"message body (i.e., after a completely blank line following the headers, " -"with no indentation or other special formatting necessary)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:232 -msgid "Description-Content-Type" -msgstr "" - -#: ../source/specifications/core-metadata.rst:236 -msgid "" -"A string stating the markup syntax (if any) used in the distribution's " -"description, so that tools can intelligently render the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:239 -msgid "" -"Historically, PyPI supported descriptions in plain text and " -"`reStructuredText (reST) `_, and could render reST into HTML. However, it is " -"common for distribution authors to write the description in `Markdown " -"`_ (`RFC 7763 `_) as many code hosting sites render Markdown " -"READMEs, and authors would reuse the file for the description. PyPI didn't " -"recognize the format and so could not render the description correctly. This " -"resulted in many packages on PyPI with poorly-rendered descriptions when " -"Markdown is left as plain text, or worse, was attempted to be rendered as " -"reST. This field allows the distribution author to specify the format of " -"their description, opening up the possibility for PyPI and other tools to be " -"able to render Markdown and other formats." -msgstr "" - -#: ../source/specifications/core-metadata.rst:253 -msgid "" -"The format of this field is the same as the ``Content-Type`` header in HTTP " -"(i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then " -"it can optionally have a number of parameters:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:259 -msgid "Format::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:263 -msgid "The ``type/subtype`` part has only a few legal values:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:265 -msgid "``text/plain``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:266 -msgid "``text/x-rst``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:267 -msgid "``text/markdown``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:269 -msgid "" -"The ``charset`` parameter can be used to specify the character encoding of " -"the description. The only legal value is ``UTF-8``. If omitted, it is " -"assumed to be ``UTF-8``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:273 -msgid "" -"Other parameters might be specific to the chosen subtype. For example, for " -"the ``markdown`` subtype, there is an optional ``variant`` parameter that " -"allows specifying the variant of Markdown in use (defaults to ``GFM`` if not " -"specified). Currently, two variants are recognized:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:278 -msgid "" -"``GFM`` for `Github-flavored Markdown `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:280 -msgid "" -"``CommonMark`` for `CommonMark `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:299 -msgid "" -"If a ``Description-Content-Type`` is not specified, then applications should " -"attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to " -"``text/plain`` if it is not valid rst." -msgstr "" - -#: ../source/specifications/core-metadata.rst:303 -msgid "" -"If a ``Description-Content-Type`` is an unrecognized value, then the assumed " -"content type is ``text/plain`` (Although PyPI will probably reject anything " -"with an unrecognized value)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:307 -msgid "" -"If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is " -"not specified or is set to an unrecognized value, then the assumed " -"``variant`` is ``GFM``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:311 -msgid "" -"So for the last example above, the ``charset`` defaults to ``UTF-8`` and the " -"``variant`` defaults to ``GFM`` and thus it is equivalent to the example " -"before it." -msgstr "" - -#: ../source/specifications/core-metadata.rst:320 -msgid "Keywords" -msgstr "" - -#: ../source/specifications/core-metadata.rst:324 -msgid "" -"A list of additional keywords, separated by commas, to be used to assist " -"searching for the distribution in a larger catalog." -msgstr "" - -#: ../source/specifications/core-metadata.rst:333 -msgid "" -"The specification previously showed keywords separated by spaces, but " -"distutils and setuptools implemented it with commas. These tools have been " -"very widely used for many years, so it was easier to update the " -"specification to match the de facto standard." -msgstr "" - -#: ../source/specifications/core-metadata.rst:341 -msgid "Home-page" -msgstr "" - -#: ../source/specifications/core-metadata.rst:345 -msgid "A string containing the URL for the distribution's home page." -msgstr "" - -#: ../source/specifications/core-metadata.rst:353 -msgid "Download-URL" -msgstr "" - -#: ../source/specifications/core-metadata.rst:357 -msgid "" -"A string containing the URL from which this version of the distribution can " -"be downloaded. (This means that the URL can't be something like \".../" -"BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:366 -msgid "Author" -msgstr "" - -#: ../source/specifications/core-metadata.rst:370 -msgid "" -"A string containing the author's name at a minimum; additional contact " -"information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:383 -msgid "Author-email" -msgstr "" - -#: ../source/specifications/core-metadata.rst:387 -msgid "" -"A string containing the author's e-mail address. It can contain a name and " -"e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:395 -#: ../source/specifications/core-metadata.rst:442 -msgid "" -"Per RFC-822, this field may contain multiple comma-separated e-mail " -"addresses::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:405 -msgid "Maintainer" -msgstr "维护者" - -#: ../source/specifications/core-metadata.rst:409 -msgid "" -"A string containing the maintainer's name at a minimum; additional contact " -"information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:412 -msgid "" -"Note that this field is intended for use when a project is being maintained " -"by someone other than the original author: it should be omitted if it is " -"identical to ``Author``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:426 -msgid "Maintainer-email" -msgstr "" - -#: ../source/specifications/core-metadata.rst:430 -msgid "" -"A string containing the maintainer's e-mail address. It can contain a name " -"and e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:434 -msgid "" -"Note that this field is intended for use when a project is being maintained " -"by someone other than the original author: it should be omitted if it is " -"identical to ``Author-email``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:452 -msgid "License" -msgstr "" - -#: ../source/specifications/core-metadata.rst:456 -msgid "" -"Text indicating the license covering the distribution where the license is " -"not a selection from the \"License\" Trove classifiers. See :ref:`" -"\"Classifier\" ` below. This field may also be used to " -"specify a particular version of a license which is named via the " -"``Classifier`` field, or to indicate a variation or exception to such a " -"license." -msgstr "" - -#: ../source/specifications/core-metadata.rst:476 -msgid "Classifier (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:480 -msgid "" -"Each entry is a string giving a single classification value for the " -"distribution. Classifiers are described in :pep:`301`, and the Python " -"Package Index publishes a dynamic list of `currently defined classifiers " -"`__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:485 -#: ../source/specifications/core-metadata.rst:574 -#: ../source/specifications/core-metadata.rst:691 -#: ../source/specifications/core-metadata.rst:715 -msgid "This field may be followed by an environment marker after a semicolon." -msgstr "" - -#: ../source/specifications/core-metadata.rst:496 -msgid "Requires-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:499 -#: ../source/specifications/core-metadata.rst:561 -#: ../source/specifications/core-metadata.rst:663 -#: ../source/specifications/core-metadata.rst:704 -msgid "" -"The field format specification was relaxed to accept the syntax used by " -"popular publishing tools." -msgstr "" - -#: ../source/specifications/core-metadata.rst:503 -msgid "" -"Each entry contains a string naming some other distutils project required by " -"this distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:506 -msgid "The format of a requirement string contains from one to four parts:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:508 -msgid "" -"A project name, in the same format as the ``Name:`` field. The only " -"mandatory part." -msgstr "" - -#: ../source/specifications/core-metadata.rst:510 -msgid "" -"A comma-separated list of 'extra' names. These are defined by the required " -"project, referring to specific features which may need extra dependencies." -msgstr "" - -#: ../source/specifications/core-metadata.rst:513 -msgid "" -"A version specifier. Tools parsing the format should accept optional " -"parentheses around this, but tools generating it should not use parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:516 -msgid "" -"An environment marker after a semicolon. This means that the requirement is " -"only needed in the specified conditions." -msgstr "" - -#: ../source/specifications/core-metadata.rst:519 -msgid "See :pep:`508` for full details of the allowed format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:521 -msgid "" -"The project names should correspond to names as found on the `Python Package " -"Index`_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:524 -msgid "" -"Version specifiers must follow the rules described in :doc:`version-" -"specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:538 -msgid "Requires-Python" -msgstr "" - -#: ../source/specifications/core-metadata.rst:542 -msgid "" -"This field specifies the Python version(s) that the distribution is " -"guaranteed to be compatible with. Installation tools may look at this when " -"picking which version of a project to install." -msgstr "" - -#: ../source/specifications/core-metadata.rst:546 -msgid "The value must be in the format specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:548 -msgid "This field cannot be followed by an environment marker." -msgstr "" - -#: ../source/specifications/core-metadata.rst:558 -msgid "Requires-External (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:565 -msgid "" -"Each entry contains a string describing some dependency in the system that " -"the distribution is to be used. This field is intended to serve as a hint " -"to downstream project maintainers, and has no semantics which are meaningful " -"to the ``distutils`` distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:570 -msgid "" -"The format of a requirement string is a name of an external dependency, " -"optionally followed by a version declaration within parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:576 -msgid "" -"Because they refer to non-Python software releases, version numbers for this " -"field are **not** required to conform to the format specified in :pep:" -"`440`: they should correspond to the version scheme used by the external " -"dependency." -msgstr "" - -#: ../source/specifications/core-metadata.rst:581 -msgid "Notice that there is no particular rule on the strings to be used." -msgstr "" - -#: ../source/specifications/core-metadata.rst:593 -msgid "Project-URL (multiple-use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:597 -msgid "" -"A string containing a browsable URL for the project and a label for it, " -"separated by a comma." -msgstr "" - -#: ../source/specifications/core-metadata.rst:604 -msgid "The label is free text limited to 32 characters." -msgstr "" - -#: ../source/specifications/core-metadata.rst:612 -msgid "Provides-Extra (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:616 -msgid "" -"A string containing the name of an optional feature. Must be a valid Python " -"identifier. May be used to make a dependency conditional on whether the " -"optional feature has been requested." -msgstr "" - -#: ../source/specifications/core-metadata.rst:625 -msgid "" -"A second distribution requires an optional dependency by placing it inside " -"square brackets, and can request multiple features by separating them with a " -"comma (,). The requirements are evaluated for each requested feature and " -"added to the set of requirements for the distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:635 -msgid "" -"Two feature names ``test`` and ``doc`` are reserved to mark dependencies " -"that are needed for running automated tests and generating documentation, " -"respectively." -msgstr "" - -#: ../source/specifications/core-metadata.rst:639 -msgid "" -"It is legal to specify ``Provides-Extra:`` without referencing it in any " -"``Requires-Dist:``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:644 -msgid "Rarely Used Fields" -msgstr "" - -#: ../source/specifications/core-metadata.rst:646 -msgid "" -"The fields in this section are currently rarely used, as their design was " -"inspired by comparable mechanisms in Linux package management systems, and " -"it isn't at all clear how tools should interpret them in the context of an " -"open index server such as `PyPI `__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:651 -msgid "" -"As a result, popular installation tools ignore them completely, which in " -"turn means there is little incentive for package publishers to set them " -"appropriately. However, they're retained in the metadata specification, as " -"they're still potentially useful for informational purposes, and can also be " -"used for their originally intended purpose in combination with a curated " -"package repository." -msgstr "" - -#: ../source/specifications/core-metadata.rst:660 -msgid "Provides-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:667 -msgid "" -"Each entry contains a string naming a Distutils project which is contained " -"within this distribution. This field *must* include the project identified " -"in the ``Name`` field, followed by the version : Name (Version)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:672 -msgid "" -"A distribution may provide additional names, e.g. to indicate that multiple " -"projects have been bundled together. For instance, source distributions of " -"the ``ZODB`` project have historically included the ``transaction`` project, " -"which is now available as a separate distribution. Installing such a source " -"distribution satisfies requirements for both ``ZODB`` and ``transaction``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:679 -msgid "" -"A distribution may also provide a \"virtual\" project name, which does not " -"correspond to any separately-distributed project: such a name might be used " -"to indicate an abstract capability which could be supplied by one of " -"multiple projects. E.g., multiple projects might supply RDBMS bindings for " -"use by a given ORM: each project might declare that it provides ``ORM-" -"bindings``, allowing other projects to depend only on having at most one of " -"them installed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:687 -msgid "" -"A version declaration may be supplied and must follow the rules described " -"in :doc:`version-specifiers`. The distribution's version number will be " -"implied if none is specified." -msgstr "" - -#: ../source/specifications/core-metadata.rst:701 -msgid "Obsoletes-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:708 -msgid "" -"Each entry contains a string describing a distutils project's distribution " -"which this distribution renders obsolete, meaning that the two projects " -"should not be installed at the same time." -msgstr "" - -#: ../source/specifications/core-metadata.rst:712 -msgid "" -"Version declarations can be supplied. Version numbers must be in the format " -"specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:717 -msgid "" -"The most common use of this field will be in case a project name changes, e." -"g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install " -"Torqued Python, the Gorgon distribution should be removed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:730 -msgid "reStructuredText markup: http://docutils.sourceforge.net/" -msgstr "" - -#: ../source/specifications/core-metadata.rst:735 -msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:6 -msgid "Declaring build system dependencies" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:8 -msgid "" -"`pyproject.toml` is a build system independent file format defined in :pep:" -"`518` that projects may provide in order to declare any Python level " -"dependencies that must be installed in order to run the project's build " -"system successfully." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:5 -msgid "Declaring project metadata" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:7 -msgid "" -":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to " -"consume. It defines the following specification as the canonical source for " -"the format used." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:12 -msgid "" -"There are two kinds of metadata: *static* and *dynamic*. Static metadata is " -"specified in the ``pyproject.toml`` file directly and cannot be specified or " -"changed by a tool. Dynamic metadata is listed via the ``dynamic`` field " -"(defined later in this specification) and represents metadata that a tool " -"will later provide." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:18 -msgid "" -"The fields defined in this specification MUST be in a table named " -"``[project]`` in ``pyproject.toml``. No tools may add fields to this table " -"which are not defined by this specification. For tools wishing to store " -"their own settings in ``pyproject.toml``, they may use the ``[tool]`` table " -"as defined in the :ref:`build dependency declaration specification " -"`. The lack of a ``[project]`` table " -"implicitly means the build back-end will dynamically provide all fields." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:27 -msgid "The only fields required to be statically defined are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:29 -#: ../source/specifications/declaring-project-metadata.rst:41 -msgid "``name``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:31 -msgid "" -"The fields which are required but may be specified *either* statically or " -"listed as dynamic are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:34 -#: ../source/specifications/declaring-project-metadata.rst:54 -msgid "``version``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:36 -msgid "" -"All other fields are considered optional and my be specified statically, " -"listed as dynamic, or left unspecified." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:43 -#: ../source/specifications/declaring-project-metadata.rst:56 -#: ../source/specifications/declaring-project-metadata.rst:68 -#: ../source/specifications/declaring-project-metadata.rst:117 -msgid "TOML_ type: string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:44 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Name `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:47 -msgid "The name of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:49 -msgid "" -"Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it " -"is read for internal consistency." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:57 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Version " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:60 -msgid "The version of the project as supported by :pep:`440`." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:62 -msgid "Users SHOULD prefer to specify already-normalized versions." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:66 -msgid "``description``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:69 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Summary " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:72 -msgid "The summary description of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:76 -msgid "``readme``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:78 -msgid "TOML_ type: string or table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:79 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Description " -"` and :ref:`Description-Content-Type `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:83 -msgid "The full description of the project (i.e. the README)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:85 -msgid "" -"The field accepts either a string or a table. If it is a string then it is a " -"path relative to ``pyproject.toml`` to a text file containing the full " -"description. Tools MUST assume the file's encoding is UTF-8. If the file " -"path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the " -"content-type is ``text/markdown``. If the file path ends in a case-" -"insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-" -"rst``. If a tool recognizes more extensions than this PEP, they MAY infer " -"the content-type for the user without specifying this field as ``dynamic``. " -"For all unrecognized suffixes when a content-type is not provided, tools " -"MUST raise an error." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:96 -msgid "" -"The ``readme`` field may also take a table. The ``file`` key has a string " -"value representing a path relative to ``pyproject.toml`` to a file " -"containing the full description. The ``text`` key has a string value which " -"is the full description. These keys are mutually-exclusive, thus tools MUST " -"raise an error if the metadata specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:103 -msgid "" -"A table specified in the ``readme`` field also has a ``content-type`` field " -"which takes a string specifying the content-type of the full description. A " -"tool MUST raise an error if the metadata does not specify this field in the " -"table. If the metadata does not specify the ``charset`` parameter, then it " -"is assumed to be UTF-8. Tools MAY support other encodings if they choose to. " -"Tools MAY support alternative content-types which they can transform to a " -"content-type as supported by the :ref:`core metadata `. " -"Otherwise tools MUST raise an error for unsupported content-types." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:115 -msgid "``requires-python``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:118 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Requires-" -"Python `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:121 -msgid "The Python version requirements of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:125 -msgid "``license``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:127 -msgid "TOML_ type: table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:128 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`License " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:131 -msgid "" -"The table may have one of two keys. The ``file`` key has a string value that " -"is a file path relative to ``pyproject.toml`` to the file which contains the " -"license for the project. Tools MUST assume the file's encoding is UTF-8. The " -"``text`` key has a string value which is the license of the project. These " -"keys are mutually exclusive, so a tool MUST raise an error if the metadata " -"specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:140 -msgid "``authors``/``maintainers``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:142 -msgid "TOML_ type: Array of inline tables with string keys and values" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:143 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:" -"`Maintainer `, and :ref:`Maintainer-email `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:149 -msgid "" -"The people or organizations considered to be the \"authors\" of the project. " -"The exact meaning is open to interpretation — it may list the original or " -"primary authors, current maintainers, or owners of the package." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:154 -msgid "" -"The \"maintainers\" field is similar to \"authors\" in that its exact " -"meaning is open to interpretation." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:157 -msgid "" -"These fields accept an array of tables with 2 keys: ``name`` and ``email``. " -"Both values must be strings. The ``name`` value MUST be a valid email name " -"(i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not " -"contain commas. The ``email`` value MUST be a valid email address. Both keys " -"are optional." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:163 -msgid "" -"Using the data to fill in :ref:`core metadata ` is as follows:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:166 -msgid "" -"If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:169 -msgid "" -"If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:173 -msgid "" -"If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-" -"email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:177 -msgid "Multiple values should be separated by commas." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:181 -msgid "``keywords``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:183 -#: ../source/specifications/declaring-project-metadata.rst:193 -msgid "TOML_ type: array of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:184 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Keywords " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:187 -msgid "The keywords for the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:191 -msgid "``classifiers``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:194 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Classifier " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:197 -msgid "Trove classifiers which apply to the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:201 -msgid "``urls``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:203 -msgid "TOML_ type: table with keys and values of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:204 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Project-URL " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:207 -msgid "" -"A table of URLs where the key is the URL label and the value is the URL " -"itself." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:212 -msgid "Entry points" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:214 -msgid "" -"TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and " -"``[project.entry-points]``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:216 -msgid ":ref:`Entry points specification `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:218 -msgid "" -"There are three tables related to entry points. The ``[project.scripts]`` " -"table corresponds to the ``console_scripts`` group in the :ref:`entry points " -"specification `. The key of the table is the name of the entry " -"point and the value is the object reference." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:224 -msgid "" -"The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group " -"in the :ref:`entry points specification `. Its format is the " -"same as ``[project.scripts]``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:228 -msgid "" -"The ``[project.entry-points]`` table is a collection of tables. Each sub-" -"table's name is an entry point group. The key and value semantics are the " -"same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but " -"instead keep the entry point groups to only one level deep." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:234 -msgid "" -"Build back-ends MUST raise an error if the metadata defines a ``[project." -"entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` " -"table, as they would be ambiguous in the face of ``[project.scripts]`` and " -"``[project.gui-scripts]``, respectively." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:242 -msgid "``dependencies``/``optional-dependencies``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:244 -msgid "" -"TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with " -"values of arrays of :pep:`508` strings (``optional-dependencies``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:247 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Requires-" -"Dist ` and :ref:`Provides-Extra `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:251 -msgid "The (optional) dependencies of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:253 -msgid "" -"For ``dependencies``, it is a key whose value is an array of strings. Each " -"string represents a dependency of the project and MUST be formatted as a " -"valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist " -"` entry." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:258 -msgid "" -"For ``optional-dependencies``, it is a table where each key specifies an " -"extra and whose value is an array of strings. The strings of the arrays must " -"be valid :pep:`508` strings. The keys MUST be valid values for :ref:" -"`Provides-Extra `. Each value in the array " -"thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:269 -msgid "``dynamic``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:271 -msgid "TOML_ type: array of string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:272 -msgid "" -"A corresponding :ref:`core metadata ` field does not exist" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:275 -msgid "" -"Specifies which fields listed by this PEP were intentionally unspecified so " -"another tool can/will provide such metadata dynamically. This clearly " -"delineates which metadata is purposefully unspecified and expected to stay " -"unspecified compared to being provided via tooling later on." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:281 -msgid "" -"A build back-end MUST honour statically-specified metadata (which means the " -"metadata did not list the field in ``dynamic``)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:283 -msgid "" -"A build back-end MUST raise an error if the metadata specifies ``name`` in " -"``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:285 -msgid "" -"If the :ref:`core metadata ` specification lists a field as " -"\"Required\", then the metadata MUST specify the field statically or list it " -"in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it " -"should not be possible for a required field to not be listed somehow in the " -"``[project]`` table)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:290 -msgid "" -"If the :ref:`core metadata ` specification lists a field as " -"\"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is " -"a build back-end will provide the data for the field later." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:294 -msgid "" -"Build back-ends MUST raise an error if the metadata specifies a field " -"statically as well as being listed in ``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:296 -msgid "" -"If the metadata does not list a field in ``dynamic``, then a build back-end " -"CANNOT fill in the requisite metadata on behalf of the user (i.e. " -"``dynamic`` is the only way to allow a tool to fill in metadata and the user " -"must opt into the filling in)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:300 -msgid "" -"Build back-ends MUST raise an error if the metadata specifies a field in " -"``dynamic`` but the build back-end was unable to determine the data for it " -"(omitting the data, if determined to be the accurate value, is acceptable)." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:6 -msgid "Dependency specifiers" -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:8 -msgid "" -"The dependency specifier format used to declare a dependency on another " -"component is defined in :pep:`508`." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:11 -msgid "" -"The environment markers section in this PEP supersedes the environment " -"markers section in :pep:`345`." -msgstr "" - -#: ../source/specifications/direct-url.rst:6 -msgid "Recording the Direct URL Origin of installed distributions" -msgstr "" - -#: ../source/specifications/direct-url.rst:8 -msgid "" -"This document specifies a :file:`direct_url.json` file in the :file:`*.dist-" -"info` directory of an installed distribution, to record the Direct URL " -"Origin of the distribution. The layout of this file was originally specified " -"in :pep:`610` and is formally documented here." -msgstr "" - -#: ../source/specifications/direct-url.rst:17 -msgid "Specification" -msgstr "" - -#: ../source/specifications/direct-url.rst:19 -msgid "" -"The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` " -"directory by installers when installing a distribution from a requirement " -"specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/direct-url.rst:23 -#: ../source/specifications/recording-installed-packages.rst:206 -msgid "" -"This file MUST NOT be created when installing a distribution from an other " -"type of requirement (i.e. name plus version specifier)." -msgstr "" - -#: ../source/specifications/direct-url.rst:26 -msgid "" -"This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." -msgstr "" - -#: ../source/specifications/direct-url.rst:29 -msgid "" -"If present, it MUST contain at least two fields. The first one is ``url``, " -"with type ``string``. Depending on what ``url`` refers to, the second field " -"MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), " -"``archive_info`` (if ``url`` is a source archives or a wheel), or " -"``dir_info`` (if ``url`` is a local directory). These info fields have a " -"(possibly empty) subdictionary as value, with the possible keys defined " -"below." -msgstr "" - -#: ../source/specifications/direct-url.rst:36 -msgid "" -"``url`` MUST be stripped of any sensitive authentication information, for " -"security reasons." -msgstr "" - -#: ../source/specifications/direct-url.rst:39 -msgid "" -"The user:password section of the URL MAY however be composed of environment " -"variables, matching the following regular expression::" -msgstr "" - -#: ../source/specifications/direct-url.rst:45 -msgid "" -"Additionally, the user:password section of the URL MAY be a well-known, non " -"security sensitive string. A typical example is ``git`` in the case of an " -"URL such as ``ssh://git@gitlab.com/user/repo``." -msgstr "" - -#: ../source/specifications/direct-url.rst:49 -msgid "" -"When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be " -"present as a dictionary with the following keys:" -msgstr "" - -#: ../source/specifications/direct-url.rst:52 -msgid "" -"A ``vcs`` key (type ``string``) MUST be present, containing the name of the " -"VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be " -"registered by writing a PEP to amend this specification. The ``url`` value " -"MUST be compatible with the corresponding VCS, so an installer can hand it " -"off without transformation to a checkout/download command of the VCS." -msgstr "" - -#: ../source/specifications/direct-url.rst:58 -msgid "" -"A ``requested_revision`` key (type ``string``) MAY be present naming a " -"branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to " -"install." -msgstr "" - -#: ../source/specifications/direct-url.rst:61 -msgid "" -"A ``commit_id`` key (type ``string``) MUST be present, containing the exact " -"commit/revision number that was installed. If the VCS supports commit-hash " -"based revision identifiers, such commit-hash MUST be used as ``commit_id`` " -"in order to reference the immutable version of the source code that was " -"installed." -msgstr "" - -#: ../source/specifications/direct-url.rst:68 -msgid "" -"When ``url`` refers to a source archive or a wheel, the ``archive_info`` key " -"MUST be present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:71 -msgid "" -"A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are " -"unconditionally provided by the latest version of the standard library's " -"``hashlib`` module be used for source archive hashes. At time of writing, " -"that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and " -"'sha512'." -msgstr "" - -#: ../source/specifications/direct-url.rst:78 -msgid "" -"When ``url`` refers to a local directory, the ``dir_info`` key MUST be " -"present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:81 -msgid "" -"``editable`` (type: ``boolean``): ``true`` if the distribution was installed " -"in editable mode, ``false`` otherwise. If absent, default to ``false``." -msgstr "" - -#: ../source/specifications/direct-url.rst:84 -msgid "" -"When ``url`` refers to a local directory, it MUST have the ``file`` sheme " -"and be compliant with `RFC 8089 `_. In " -"particular, the path component must be absolute. Symbolic links SHOULD be " -"preserved when making relative paths absolute." -msgstr "" - -#: ../source/specifications/direct-url.rst:91 -msgid "" -"When the requested URL has the file:// scheme and points to a local " -"directory that happens to contain a VCS checkout, installers MUST NOT " -"attempt to infer any VCS information and therefore MUST NOT output any VCS " -"related information (such as ``vcs_info``) in :file:`direct_url.json`." -msgstr "" - -#: ../source/specifications/direct-url.rst:96 -msgid "" -"A top-level ``subdirectory`` field MAY be present containing a directory " -"path, relative to the root of the VCS repository, source archive or local " -"directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." -msgstr "" - -#: ../source/specifications/direct-url.rst:102 -msgid "" -"As a general rule, installers should as much as possible preserve the " -"information that was provided in the requested URL when generating :file:" -"`direct_url.json`. For example user:password environment variables should be " -"preserved and ``requested_revision`` should reflect the revision that was " -"provided in the requested URL as faithfully as possible. This information is " -"however *enriched* with more precise data, such as ``commit_id``." -msgstr "" - -#: ../source/specifications/direct-url.rst:110 -msgid "Registered VCS" -msgstr "" - -#: ../source/specifications/direct-url.rst:112 -msgid "" -"This section lists the registered VCS's; expanded, VCS-specific information " -"on how to use the ``vcs``, ``requested_revision``, and other fields of " -"``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY " -"support other VCS's although it is RECOMMENDED to register them by writing a " -"PEP to amend this specification. The ``vcs`` field SHOULD be the command " -"name (lowercased). Additional fields that would be necessary to support such " -"VCS SHOULD be prefixed with the VCS command name." -msgstr "" - -#: ../source/specifications/direct-url.rst:122 -msgid "Git" -msgstr "" - -#: ../source/specifications/direct-url.rst:124 -#: ../source/specifications/direct-url.rst:156 -#: ../source/specifications/direct-url.rst:179 -#: ../source/specifications/direct-url.rst:202 -msgid "Home page" -msgstr "" - -#: ../source/specifications/direct-url.rst:126 -msgid "https://git-scm.com/" -msgstr "" - -#: ../source/specifications/direct-url.rst:128 -#: ../source/specifications/direct-url.rst:160 -#: ../source/specifications/direct-url.rst:183 -#: ../source/specifications/direct-url.rst:206 -msgid "vcs command" -msgstr "" - -#: ../source/specifications/direct-url.rst:130 -#: ../source/specifications/direct-url.rst:134 -msgid "git" -msgstr "" - -#: ../source/specifications/direct-url.rst:132 -#: ../source/specifications/direct-url.rst:164 -#: ../source/specifications/direct-url.rst:187 -#: ../source/specifications/direct-url.rst:210 -msgid "``vcs`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:136 -#: ../source/specifications/direct-url.rst:168 -#: ../source/specifications/direct-url.rst:191 -#: ../source/specifications/direct-url.rst:214 -msgid "``requested_revision`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:138 -msgid "" -"A tag name, branch name, Git ref, commit hash, shortened commit hash, or " -"other commit-ish." -msgstr "" - -#: ../source/specifications/direct-url.rst:141 -#: ../source/specifications/direct-url.rst:172 -#: ../source/specifications/direct-url.rst:195 -#: ../source/specifications/direct-url.rst:219 -msgid "``commit_id`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:143 -msgid "A commit hash (40 hexadecimal characters sha1)." -msgstr "" - -#: ../source/specifications/direct-url.rst:147 -msgid "" -"Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to " -"determine if the ``requested_revision`` corresponds to a Git ref. In turn, a " -"ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning " -"with ``refs/remotes/origin/`` after cloning corresponds to a branch." -msgstr "" - -#: ../source/specifications/direct-url.rst:154 -msgid "Mercurial" -msgstr "" - -#: ../source/specifications/direct-url.rst:158 -msgid "https://www.mercurial-scm.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:162 -#: ../source/specifications/direct-url.rst:166 -msgid "hg" -msgstr "" - -#: ../source/specifications/direct-url.rst:170 -msgid "A tag name, branch name, changeset ID, shortened changeset ID." -msgstr "" - -#: ../source/specifications/direct-url.rst:174 -msgid "A changeset ID (40 hexadecimal characters)." -msgstr "" - -#: ../source/specifications/direct-url.rst:177 -msgid "Bazaar" -msgstr "" - -#: ../source/specifications/direct-url.rst:181 -msgid "https://bazaar.canonical.com/" -msgstr "" - -#: ../source/specifications/direct-url.rst:185 -#: ../source/specifications/direct-url.rst:189 -msgid "bzr" -msgstr "" - -#: ../source/specifications/direct-url.rst:193 -msgid "A tag name, branch name, revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:197 -msgid "A revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:200 -msgid "Subversion" -msgstr "" - -#: ../source/specifications/direct-url.rst:204 -msgid "https://subversion.apache.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:208 -#: ../source/specifications/direct-url.rst:212 -msgid "svn" -msgstr "" - -#: ../source/specifications/direct-url.rst:216 -msgid "" -"``requested_revision`` must be compatible with ``svn checkout`` ``--" -"revision`` option. In Subversion, branch or tag is part of ``url``." -msgstr "" - -#: ../source/specifications/direct-url.rst:221 -msgid "" -"Since Subversion does not support globally unique identifiers, this field is " -"the Subversion revision number in the corresponding repository." -msgstr "" - -#: ../source/specifications/direct-url.rst:229 -msgid "Example direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:231 -msgid "Source archive:" -msgstr "" - -#: ../source/specifications/direct-url.rst:242 -msgid "Git URL with tag and commit-hash:" -msgstr "" - -#: ../source/specifications/direct-url.rst:255 -msgid "Local directory:" -msgstr "" - -#: ../source/specifications/direct-url.rst:264 -msgid "Local directory installed in editable mode:" -msgstr "" - -#: ../source/specifications/direct-url.rst:277 -msgid "Example pip commands and their effect on direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:279 -msgid "Commands that generate a ``direct_url.json``:" -msgstr "" - -#: ../source/specifications/direct-url.rst:281 -msgid "pip install https://example.com/app-1.0.tgz" -msgstr "" - -#: ../source/specifications/direct-url.rst:282 -msgid "pip install https://example.com/app-1.0.whl" -msgstr "" - -#: ../source/specifications/direct-url.rst:283 -msgid "" -"pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup" -"\"" -msgstr "" - -#: ../source/specifications/direct-url.rst:284 -msgid "pip install ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:285 -msgid "pip install file:///home/user/app" -msgstr "" - -#: ../source/specifications/direct-url.rst:286 -msgid "" -"pip install --editable \"git+https://example.com/repo/app." -"git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local " -"directory where the git repository has been cloned to, and ``dir_info`` will " -"be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" -msgstr "" - -#: ../source/specifications/direct-url.rst:290 -msgid "pip install -e ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:292 -msgid "Commands that *do not* generate a ``direct_url.json``" -msgstr "" - -#: ../source/specifications/direct-url.rst:294 -msgid "pip install app" -msgstr "" - -#: ../source/specifications/direct-url.rst:295 -msgid "pip install app --no-index --find-links https://example.com/" -msgstr "" - -#: ../source/specifications/entry-points.rst:5 -msgid "Entry points specification" -msgstr "" - -#: ../source/specifications/entry-points.rst:7 -msgid "" -"*Entry points* are a mechanism for an installed distribution to advertise " -"components it provides to be discovered and used by other code. For example:" -msgstr "" - -#: ../source/specifications/entry-points.rst:11 -msgid "" -"Distributions can specify ``console_scripts`` entry points, each referring " -"to a function. When *pip* (or another console_scripts aware installer) " -"installs the distribution, it will create a command-line wrapper for each " -"entry point." -msgstr "" - -#: ../source/specifications/entry-points.rst:14 -msgid "" -"Applications can use entry points to load plugins; e.g. Pygments (a syntax " -"highlighting tool) can use additional lexers and styles from separately " -"installed packages. For more about this, see :doc:`/guides/creating-and-" -"discovering-plugins`." -msgstr "" - -#: ../source/specifications/entry-points.rst:19 -msgid "" -"The entry point file format was originally developed to allow packages built " -"with setuptools to provide integration point metadata that would be read at " -"runtime with ``importlib.metadata``. It is now defined as a PyPA " -"interoperability specification in order to allow build tools other than " -"setuptools to publish ``importlib.metadata`` compatible entry point " -"metadata, and runtime libraries other than ``importlib.metadata`` to " -"portably read published entry point metadata (potentially with different " -"caching and conflict resolution strategies)." -msgstr "" - -#: ../source/specifications/entry-points.rst:28 -msgid "Data model" -msgstr "" - -#: ../source/specifications/entry-points.rst:30 -msgid "Conceptually, an entry point is defined by three required properties:" -msgstr "" - -#: ../source/specifications/entry-points.rst:32 -msgid "" -"The **group** that an entry point belongs to indicates what sort of object " -"it provides. For instance, the group ``console_scripts`` is for entry points " -"referring to functions which can be used as a command, while ``pygments." -"styles`` is the group for classes defining pygments styles. The consumer " -"typically defines the expected interface. To avoid clashes, consumers " -"defining a new group should use names starting with a PyPI name owned by the " -"consumer project, followed by ``.``. Group names must be one or more groups " -"of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w" -"+)*$``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:42 -msgid "" -"The **name** identifies this entry point within its group. The precise " -"meaning of this is up to the consumer. For console scripts, the name of the " -"entry point is the command that will be used to launch it. Within a " -"distribution, entry point names should be unique. If different distributions " -"provide the same name, the consumer decides how to handle such conflicts. " -"The name may contain any characters except ``=``, but it cannot start or end " -"with any whitespace character, or start with ``[``. For new entry points, it " -"is recommended to use only letters, numbers, underscores, dots and dashes " -"(regex ``[\\w.-]+``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:51 -msgid "" -"The **object reference** points to a Python object. It is either in the form " -"``importable.module``, or ``importable.module:object.attr``. Each of the " -"parts delimited by dots and the colon is a valid Python identifier. It is " -"intended to be looked up like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:64 -msgid "" -"Some tools call this kind of object reference by itself an 'entry point', " -"for want of a better term, especially where it points to a function to " -"launch a program." -msgstr "" - -#: ../source/specifications/entry-points.rst:68 -msgid "" -"There is also an optional property: the **extras** are a set of strings " -"identifying optional features of the distribution providing the entry point. " -"If these are specified, the entry point requires the dependencies of those " -"'extras'. See the metadata field :ref:`metadata_provides_extra`." -msgstr "" - -#: ../source/specifications/entry-points.rst:73 -msgid "" -"Using extras for an entry point is no longer recommended. Consumers should " -"support parsing them from existing distributions, but may then ignore them. " -"New publishing tools need not support specifying extras. The functionality " -"of handling extras was tied to setuptools' model of managing 'egg' packages, " -"but newer tools such as pip and virtualenv use a different model." -msgstr "" - -#: ../source/specifications/entry-points.rst:80 -msgid "File format" -msgstr "" - -#: ../source/specifications/entry-points.rst:82 -msgid "" -"Entry points are defined in a file called :file:`entry_points.txt` in the :" -"file:`*.dist-info` directory of the distribution. This is the directory " -"described in :pep:`376` for installed distributions, and in :pep:`427` for " -"wheels. The file uses the UTF-8 character encoding." -msgstr "" - -#: ../source/specifications/entry-points.rst:87 -msgid "" -"The file contents are in INI format, as read by Python's :mod:`configparser` " -"module. However, configparser treats names as case-insensitive by default, " -"whereas entry point names are case sensitive. A case-sensitive config parser " -"can be made like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:97 -msgid "" -"The entry points file must always use ``=`` to delimit names from values " -"(whereas configparser also allows using ``:``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:100 -msgid "" -"The sections of the config file represent entry point groups, the names are " -"names, and the values encode both the object reference and the optional " -"extras. If extras are used, they are a comma-separated list inside square " -"brackets." -msgstr "" - -#: ../source/specifications/entry-points.rst:104 -msgid "" -"Within a value, readers must accept and ignore spaces (including multiple " -"consecutive spaces) before or after the colon, between the object reference " -"and the left square bracket, between the extra names and the square brackets " -"and colons delimiting them, and after the right square bracket. The syntax " -"for extras is formally specified as part of :pep:`508` (as ``extras``). For " -"tools writing the file, it is recommended only to insert a space between the " -"object reference and the left square bracket." -msgstr "" - -#: ../source/specifications/entry-points.rst:112 -msgid "For example::" -msgstr "" - -#: ../source/specifications/entry-points.rst:124 -msgid "Use for scripts" -msgstr "" - -#: ../source/specifications/entry-points.rst:126 -msgid "" -"Two groups of entry points have special significance in packaging: " -"``console_scripts`` and ``gui_scripts``. In both groups, the name of the " -"entry point should be usable as a command in a system shell after the " -"package is installed. The object reference points to a function which will " -"be called with no arguments when this command is run. The function may " -"return an integer to be used as a process exit code, and returning ``None`` " -"is equivalent to returning ``0``." -msgstr "" - -#: ../source/specifications/entry-points.rst:134 -msgid "" -"For instance, the entry point ``mycmd = mymod:main`` would create a command " -"``mycmd`` launching a script like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:141 -msgid "" -"The difference between ``console_scripts`` and ``gui_scripts`` only affects " -"Windows systems. ``console_scripts`` are wrapped in a console executable, so " -"they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and " -"``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI " -"executable, so they can be started without a console, but cannot use " -"standard streams unless application code redirects them. Other platforms do " -"not have the same distinction." -msgstr "" - -#: ../source/specifications/entry-points.rst:149 -msgid "" -"Install tools are expected to set up wrappers for both ``console_scripts`` " -"and ``gui_scripts`` in the scripts directory of the install scheme. They are " -"not responsible for putting this directory in the ``PATH`` environment " -"variable which defines where command-line tools are found." -msgstr "" - -#: ../source/specifications/entry-points.rst:154 -msgid "" -"As files are created from the names, and some filesystems are case-" -"insensitive, packages should avoid using names in these groups which differ " -"only in case. The behaviour of install tools when names differ only in case " -"is undefined." -msgstr "" - -#: ../source/specifications/index.rst:4 -msgid "PyPA specifications" -msgstr "" - -#: ../source/specifications/index.rst:6 -msgid "" -"This is a list of currently active interoperability specifications " -"maintained by the Python Packaging Authority. The process for updating these " -"standards, and for proposing new ones, is documented on `pypa.io `__." -msgstr "" - -#: ../source/specifications/index.rst:13 -msgid "Package Distribution Metadata" -msgstr "" - -#: ../source/specifications/index.rst:30 -msgid "Package Distribution File Formats" -msgstr "" - -#: ../source/specifications/index.rst:40 -msgid "Package Index Interfaces" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:6 -msgid "Platform compatibility tags" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:8 -msgid "" -"Platform compatibility tags allow build tools to mark distributions as being " -"compatible with specific platforms, and allows installers to understand " -"which distributions are compatible with the system they are running on." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:12 -msgid "" -"The platform compatibility tagging model used for the ``wheel`` distribution " -"format is defined in :pep:`425`." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:16 -msgid "Platform tags for Windows" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:18 -msgid "" -"The scheme defined in :pep:`425` covers public distribution of wheel files " -"to systems running Windows." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:22 -msgid "Platform tags for macOS (Mac OS X)" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:24 -msgid "" -"The scheme defined in :pep:`425` covers public distribution of wheel files " -"to systems running macOS (previously known as Mac OS X)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:28 -msgid "Platform tags for common Linux distributions" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:32 -msgid "" -"The scheme defined in :pep:`425` is insufficient for public distribution of " -"wheel files (and \\*nix wheel files in general) to Linux platforms, due to " -"the large ecosystem of Linux platforms and subtle differences between them." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:36 -msgid "" -"Instead, :pep:`600` defines the ``manylinux`` standard, which represents a " -"common subset of Linux platforms, and allows building wheels tagged with the " -"``manylinux`` platform tag which can be used across most common Linux " -"distributions." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:41 -msgid "" -"There were multiple iterations of the ``manylinux`` specification, each " -"representing the common subset of Linux platforms at a given point in time:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:44 -msgid "" -"``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, " -"and is based on a compatible Linux platform from 2007." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:46 -msgid "" -"``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` " -"architectures. and updates the previous specification to be based on a " -"compatible Linux platform from 2010 instead." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:49 -msgid "" -"``manylinux2014`` (:pep:`599`) adds support for a number of additional " -"architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and " -"``s390x``) and updates the base platform to a compatible Linux platform from " -"2014." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:54 -msgid "" -"``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a " -"future-proof standard. It defines ``x`` and ``y`` as glibc major an minor " -"versions supported (e.g. ``manylinux_2_24`` should work on any distro using " -"glibc 2.24+). Previous tags are still supported for backward compatibility." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:59 -msgid "" -"In general, distributions built for older versions of the specification are " -"forwards-compatible (meaning that ``manylinux1`` distributions should " -"continue to work on modern systems) but not backwards-compatible (meaning " -"that ``manylinux2010`` distributions are not expected to work on platforms " -"that existed before 2010)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:65 -msgid "" -"Package maintainers should attempt to target the most compatible " -"specification possible, with the caveat that the provided build environment " -"for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning " -"that these images will no longer receive security updates." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:71 -msgid "Manylinux compatibility support" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:74 -msgid "" -"The ``manylinux2014`` specification is relatively new and is not yet widely " -"recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:76 -msgid "" -"The ``manylinux_x_y`` specification is relatively new and is not yet widely " -"recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:79 -msgid "" -"The following table shows the minimum versions of relevant projects to " -"support the various ``manylinux`` standards:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "Tool" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux1``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2010``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2014``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux_x_y``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=8.1.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=20.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "auditwheel" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=1.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=2.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.3.0`` [#]_" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:90 -msgid "Platform tags for other \\*nix platforms" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:92 -msgid "" -"The scheme defined in :pep:`425` is not generally sufficient for public " -"distribution of wheel files to other \\*nix platforms. Efforts are currently " -"(albeit intermittently) under way to define improved compatibility tagging " -"schemes for AIX and for Alpine Linux." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:98 -msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" -msgstr "" - -#: ../source/specifications/pypirc.rst:6 -msgid "The :file:`.pypirc` file" -msgstr "" - -#: ../source/specifications/pypirc.rst:8 -msgid "" -"A :file:`.pypirc` file allows you to define the configuration for :term:" -"`package indexes ` (referred to here as \"repositories\"), so " -"that you don't have to enter the URL, username, or password whenever you " -"upload a package with :ref:`twine` or :ref:`flit`." -msgstr "" - -#: ../source/specifications/pypirc.rst:13 -msgid "The format (originally defined by the :ref:`distutils` package) is:" -msgstr "" - -#: ../source/specifications/pypirc.rst:32 -msgid "" -"The ``distutils`` section defines an ``index-servers`` field that lists the " -"name of all sections describing a repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:35 -msgid "Each section describing a repository defines three fields:" -msgstr "" - -#: ../source/specifications/pypirc.rst:37 -msgid "``repository``: The URL of the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:38 -msgid "``username``: The registered username on the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:39 -msgid "``password``: The password that will used to authenticate the username." -msgstr "" - -#: ../source/specifications/pypirc.rst:43 -msgid "" -"Be aware that this stores your password in plain text. For better security, " -"consider an alternative like `keyring`_, setting environment variables, or " -"providing the password on the command line." -msgstr "" - -#: ../source/specifications/pypirc.rst:47 -msgid "" -"Otherwise, set the permissions on :file:`.pypirc` so that only you can view " -"or modify it. For example, on Linux or macOS, run:" -msgstr "" - -#: ../source/specifications/pypirc.rst:57 -msgid "Common configurations" -msgstr "" - -#: ../source/specifications/pypirc.rst:61 -msgid "" -"These examples apply to :ref:`twine`, and projects like :ref:`hatch` that " -"use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`." -"pypirc`, but with different defaults. Please refer to each project's " -"documentation for more details and usage instructions." -msgstr "" - -#: ../source/specifications/pypirc.rst:66 -msgid "" -"Twine's default configuration mimics a :file:`.pypirc` with repository " -"sections for PyPI and TestPyPI:" -msgstr "" - -#: ../source/specifications/pypirc.rst:82 -msgid "" -"Twine will add additional configuration from :file:`$HOME/.pypirc`, the " -"command line, and environment variables to this default configuration." -msgstr "" - -#: ../source/specifications/pypirc.rst:86 -msgid "Using a PyPI token" -msgstr "" - -#: ../source/specifications/pypirc.rst:88 -msgid "" -"To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` " -"similar to:" -msgstr "" - -#: ../source/specifications/pypirc.rst:97 -msgid "" -"For :ref:`TestPyPI `, add a ``[testpypi]`` section, using " -"the API token from your TestPyPI account." -msgstr "" - -#: ../source/specifications/pypirc.rst:103 -msgid "Using another package index" -msgstr "" - -#: ../source/specifications/pypirc.rst:105 -msgid "" -"To configure an additional repository, you'll need to redefine the ``index-" -"servers`` field to include the repository name. Here is a complete example " -"of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" -msgstr "" - -#: ../source/specifications/pypirc.rst:132 -msgid "" -"Instead of using the ``password`` field, consider saving your API tokens and " -"passwords securely using `keyring`_ (which is installed by Twine):" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:5 -msgid "Recording installed projects" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:7 -msgid "" -"This document specifies a common format of recording information about " -"Python :term:`projects ` installed in an environment. A common " -"metadata format allows tools to query, manage or uninstall projects, " -"regardless of how they were installed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:12 -msgid "" -"Almost all information is optional. This allows tools outside the Python " -"ecosystem, such as Linux package managers, to integrate with Python tooling " -"as much as possible. For example, even if an installer cannot easily provide " -"a list of installed files in a format specific to Python tooling, it should " -"still record the name and version of the installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:21 -msgid "History and change workflow" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:23 -msgid "" -"The metadata described here was first specified in :pep:`376`, and later " -"amended in :pep:`627`. It was formerly known as *Database of Installed " -"Python Distributions*. Further amendments (except trivial language or " -"typography fixes) must be made through the PEP process (see :pep:`1`)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:29 -msgid "" -"While this document is the normative specification, these PEPs that " -"introduce changes to it may include additional information such as " -"rationales and backwards compatibility considerations." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:37 -msgid "" -"Each project installed from a distribution must, in addition to files, " -"install a \"``.dist-info``\" directory located alongside importable modules " -"and packages (commonly, the ``site-packages`` directory)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:41 -msgid "" -"This directory is named as ``{name}-{version}.dist-info``, with ``name`` and " -"``version`` fields corresponding to :ref:`core-metadata`. Both fields must " -"be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 " -"<440#normalization>` for the definition of normalization for each field " -"respectively), and replace dash (``-``) characters with underscore (``_``) " -"chacaters, so the ``.dist-info`` directory always has exactly one dash (``-" -"``) character in its stem, separating the ``name`` and ``version`` fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:50 -msgid "" -"Historically, tools have failed to replace dot characters or normalize case " -"in the ``name`` field, or not perform normalization in the ``version`` " -"field. Tools consuming ``.dist-info`` directories should expect those fields " -"to be unnormalized, and treat them as equivalent to their normalized " -"counterparts. New tools that write ``.dist-info`` directories MUST normalize " -"both ``name`` and ``version`` fields using the rules described above, and " -"existing tools are encouraged to start normalizing those fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:60 -msgid "" -"The ``.dist-info`` directory's name is formatted to unambigiously represent " -"a distribution as a filesystem path. Tools presenting a distribution name to " -"a user should avoid using the normalized name, and instead present the " -"specified name (when needed prior to resolution to an installed package), or " -"read the respective fields in Core Metadata, since values listed there are " -"unescaped and accurately reflect the distribution. Libraries should provide " -"API for such tools to consume, so tools can have access to the unnormalized " -"name when displaying distrubution information." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:69 -msgid "" -"This ``.dist-info`` directory can contain these files, described in detail " -"below:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:72 -msgid "``METADATA``: contains project metadata" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:73 -msgid "``RECORD``: records the list of installed files." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:74 -msgid "" -"``INSTALLER``: records the name of the tool used to install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:76 -msgid "" -"The ``METADATA`` file is mandatory. All other files may be omitted at the " -"installing tool's discretion. Additional installer-specific files may be " -"present." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:82 -msgid "" -"The :ref:`binary-distribution-format` specification describes additional " -"files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. " -"Such files may be copied to the ``.dist-info`` directory of an installed " -"project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:87 -msgid "" -"The previous versions of this specification also specified a ``REQUESTED`` " -"file. This file is now considered a tool-specific extension, but may be " -"standardized again in the future. See `PEP 376 `_ for its original meaning." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:94 -msgid "The METADATA file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:96 -msgid "" -"The ``METADATA`` file contains metadata as described in the :ref:`core-" -"metadata` specification, version 1.1 or greater." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:99 -msgid "" -"The ``METADATA`` file is mandatory. If it cannot be created, or if required " -"core metadata is not available, installers must report an error and fail to " -"install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:105 -msgid "The RECORD file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:107 -msgid "" -"The ``RECORD`` file holds the list of installed files. It is a CSV file " -"containing one record (line) per installed file." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:110 -msgid "" -"The CSV dialect must be readable with the default ``reader`` of Python's " -"``csv`` module:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:113 -msgid "field delimiter: ``,`` (comma)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:114 -msgid "quoting char: ``\"`` (straight double quote)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:115 -msgid "line terminator: either ``\\r\\n`` or ``\\n``." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:117 -msgid "" -"Each record is composed of three elements: the file's **path**, the **hash** " -"of the contents, and its **size**." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:120 -msgid "" -"The *path* may be either absolute, or relative to the directory containing " -"the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On " -"Windows, directories may be separated either by forward- or backslashes (``/" -"`` or ``\\``)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:125 -msgid "" -"The *hash* is either an empty string or the name of a hash algorithm from " -"``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` " -"and the digest of the file's contents, encoded with the urlsafe-base64-nopad " -"encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:130 -msgid "" -"The *size* is either the empty string, or file's size in bytes, as a base 10 " -"integer." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:133 -msgid "" -"For any file, either or both of the *hash* and *size* fields may be left " -"empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself " -"have empty *hash* and *size*. For other files, leaving the information out " -"is discouraged, as it prevents verifying the integrity of the installed " -"project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:139 -msgid "" -"If the ``RECORD`` file is present, it must list all installed files of the " -"project, except ``.pyc`` files corresponding to ``.py`` files listed in " -"``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` " -"directory (including the ``RECORD`` file itself) must be listed. Directories " -"should not be listed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:146 -msgid "" -"To completely uninstall a package, a tool needs to remove all files listed " -"in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding " -"to removed ``.py`` files, and any directories emptied by the uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:151 -msgid "Here is an example snippet of a possible ``RECORD`` file::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:170 -msgid "" -"If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must " -"not atempt to uninstall or upgrade the package. (This does not apply to " -"tools that rely on other sources of information, such as system package " -"managers in Linux distros.)" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:177 -msgid "The INSTALLER file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:179 -msgid "" -"If present, ``INSTALLER`` is a single-line text file naming the tool used to " -"install the project. If the installer is executable from the command line, " -"``INSTALLER`` should contain the command name. Otherwise, it should contain " -"a printable ASCII string." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:185 -msgid "The file can be terminated by zero or more ASCII whitespace characters." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:187 -msgid "Here are examples of two possible ``INSTALLER`` files::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:195 -msgid "" -"This value should be used for informational purposes only. For example, if a " -"tool is asked to uninstall a project but finds no ``RECORD`` file, it may " -"suggest that the tool named in ``INSTALLER`` may be able to do the " -"uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:201 -msgid "The direct_url.json file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:203 -msgid "" -"This file MUST be created by installers when installing a distribution from " -"a requirement specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:209 -msgid "Its detailed specification is at :ref:`direct-url`." -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:6 -msgid "Simple repository API" -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:8 -msgid "" -"The current interface for querying available package versions and retrieving " -"packages from an index server is defined in :pep:`503`, with the addition of " -"\"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` " -"and specifying the interface version provided by an index server in :pep:" -"`629`." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:6 -msgid "Source distribution format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:8 -msgid "" -"The current standard format of source distribution format is identified by " -"the presence of a :file:`pyproject.toml` file in the distribution archive. " -"The layout of such a distribution was originally specified in :pep:`517` and " -"is formally documented here." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:13 -msgid "" -"There is also the legacy source distribution format, implicitly defined by " -"the behaviour of ``distutils`` module in the standard library, when " -"executing :command:`setup.py sdist`. This document does not attempt to " -"standardise this format, except to note that if a legacy source distribution " -"contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it " -"MUST follow the rules applicable to source distributions defined in the " -"metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:21 -msgid "Source distributions are also known as *sdists* for short." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:24 -msgid "Source distribution file name" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:26 -msgid "" -"The file name of a sdist is not currently standardised, although the *de " -"facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the " -"canonicalized form of the project name (see :pep:`503` for the " -"canonicalization rules) with ``-`` characters replaced with ``_``, and " -"``{version}`` is the project version." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:31 -msgid "" -"The name and version components of the filename MUST match the values stored " -"in the metadata contained in the file." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:35 -msgid "Source distribution file format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:37 -msgid "" -"A ``.tar.gz`` source distribution (sdist) contains a single top-level " -"directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the " -"source files of the package. The name and version MUST match the metadata " -"stored in the file. This directory must also contain a :file:`pyproject." -"toml` in the format defined in :ref:`declaring-build-dependencies`, and a " -"``PKG-INFO`` file containing metadata in the format described in the :ref:" -"`core-metadata` specification. The metadata MUST conform to at least version " -"2.2 of the metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:45 -msgid "" -"No other content of a sdist is required or defined. Build systems can store " -"whatever information they need in the sdist to build the project." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:48 -msgid "" -"The tarball should use the modern POSIX.1-2001 pax tar format, which " -"specifies UTF-8 based file names." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:6 -msgid "Version specifiers" -msgstr "" - -#: ../source/specifications/version-specifiers.rst:8 -msgid "" -"Version numbering requirements and the semantics for specifying comparisons " -"between versions are defined in :pep:`440`." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:11 -msgid "" -"The version specifiers section in this PEP supersedes the version specifiers " -"section in :pep:`345`." -msgstr "" - -#: ../source/support.rst:3 -msgid "How to Get Support" -msgstr "如何获得支持" - -#: ../source/support.rst:5 -msgid "" -"For support related to a specific project, see the links on the :doc:" -"`Projects ` page." -msgstr "" - -#: ../source/support.rst:8 -msgid "" -"For something more general, or when you're just not sure, please `open an " -"issue `_ on the " -"`packaging-problems `_ " -"repository on GitHub." -msgstr "" -"如果您想了解更多的情况，或者只是不确定，请在 GitHub 上的 `packaging-problems `_ 存储库中 `开一个新的 issue `_ 。" - -#: ../source/tutorials/creating-documentation.rst:5 -msgid "Creating Documentation" -msgstr "创建文档" - -#: ../source/tutorials/creating-documentation.rst:7 -msgid "" -"This section covers the basics of how to create documentation using " -"`Sphinx`_ and host the documentation for free in `Read The Docs`_." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:13 -msgid "Installing Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:14 -msgid "Use ``pip`` to install Sphinx:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:28 -msgid "" -"For other installation methods, see this `installation guide`_ by Sphinx." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:33 -msgid "Getting Started With Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:35 -msgid "" -"Create a ``docs`` directory inside your project to hold your documentation:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:42 -msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:49 -msgid "" -"This sets up a source directory, walks you through some basic " -"configurations, and creates an ``index.rst`` file as well as a ``conf.py`` " -"file." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:51 -msgid "" -"You can add some information about your project in ``index.rst``, then build " -"them:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:57 -msgid "" -"For more details on the build process, see this `guide`_ by Read The Docs." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:62 -msgid "Other Sources" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:64 -msgid "" -"For a more detailed guide on how to use Sphinx and reStructuredText, please " -"see this `documentation tutorial`_ on Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/index.rst:4 -msgid "" -"**Tutorials** are opinionated step-by-step guides to help you get familiar " -"with packaging concepts. For more detailed information on specific packaging " -"topics, see :doc:`/guides/index`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:5 -msgid "Installing Packages" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:7 -msgid "" -"This section covers the basics of how to install Python :term:`packages " -"`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:10 -msgid "" -"It's important to note that the term \"package\" in this context is being " -"used to describe a bundle of software to be installed (i.e. as a synonym for " -"a :term:`distribution `). It does not to refer to the " -"kind of :term:`package ` that you import in your Python " -"source code (i.e. a container of modules). It is common in the Python " -"community to refer to a :term:`distribution ` using " -"the term \"package\". Using the term \"distribution\" is often not " -"preferred, because it can easily be confused with a Linux distribution, or " -"another larger software distribution like Python itself." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:28 -msgid "Requirements for Installing Packages" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:30 -msgid "" -"This section describes the steps to follow before installing other Python " -"packages." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:35 -msgid "Ensure you can run Python from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:37 -msgid "" -"Before you go any further, make sure you have Python and that the expected " -"version is available from your command line. You can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:53 -msgid "" -"You should get some output like ``Python 3.6.3``. If you do not have Python, " -"please install the latest 3.x version from `python.org`_ or refer to the " -"`Installing Python`_ section of the Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:57 -msgid "If you're a newcomer and you get an error like this:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:66 -msgid "" -"It's because this command and other suggested commands in this tutorial are " -"intended to be run in a *shell* (also called a *terminal* or *console*). See " -"the Python for Beginners `getting started tutorial`_ for an introduction to " -"using your operating system's shell and interacting with Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:72 -msgid "" -"If you're using an enhanced shell like IPython or the Jupyter notebook, you " -"can run system commands like those in this tutorial by prefacing them with a " -"``!`` character:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:82 -msgid "" -"It's recommended to write ``{sys.executable}`` rather than plain ``python`` " -"in order to ensure that commands are run in the Python installation matching " -"the currently running notebook (which may not be the same Python " -"installation that the ``python`` command refers to)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:87 -msgid "" -"Due to the way most Linux distributions are handling the Python 3 migration, " -"Linux users using the system Python without creating a virtual environment " -"first should replace the ``python`` command in this tutorial with " -"``python3`` and the ``python -m pip`` command with ``python3 -m pip --" -"user``. Do *not* run any of the commands in this tutorial with ``sudo``: if " -"you get a permissions error, come back to the section on creating virtual " -"environments, set one up, and then continue with the tutorial as written." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:99 -msgid "Ensure you can run pip from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:101 -msgid "" -"Additionally, you'll need to make sure you have :ref:`pip` available. You " -"can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:116 -msgid "" -"If you installed Python from source, with an installer from `python.org`_, " -"or via `Homebrew`_ you should already have pip. If you're on Linux and " -"installed using your OS package manager, you may have to install pip " -"separately, see :doc:`/guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:124 -msgid "" -"If ``pip`` isn't already installed, then first try to bootstrap it from the " -"standard library:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:139 -msgid "If that still doesn't allow you to run ``python -m pip``:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:141 -msgid "" -"Securely Download `get-pip.py `_ [1]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:144 -msgid "" -"Run ``python get-pip.py``. [2]_ This will install or upgrade pip. " -"Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're " -"not installed already." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:150 -msgid "" -"Be cautious if you're using a Python install that's managed by your " -"operating system or another package manager. get-pip.py does not coordinate " -"with those tools, and may leave your system in an inconsistent state. You " -"can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/" -"local`` which is designed for locally-installed software." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:159 -msgid "Ensure pip, setuptools, and wheel are up to date" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:161 -msgid "" -"While ``pip`` alone is sufficient to install from pre-built binary archives, " -"up to date copies of the ``setuptools`` and ``wheel`` projects are useful to " -"ensure you can also install from source archives::" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:169 -msgid "Optionally, create a virtual environment" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:171 -msgid "" -"See :ref:`section below ` for " -"details, but here's the basic `venv`_ [3]_ command to use on a typical Linux " -"system:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:188 -msgid "" -"This will create a new virtual environment in the ``tutorial_env`` " -"subdirectory, and configure the current shell to use it as the default " -"``python`` environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:195 -msgid "Creating Virtual Environments" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:197 -msgid "" -"Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular " -"application, rather than being installed globally. If you are looking to " -"safely install global command line tools, see :doc:`/guides/installing-stand-" -"alone-command-line-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:203 -msgid "" -"Imagine you have an application that needs version 1 of LibFoo, but another " -"application requires version 2. How can you use both these applications? If " -"you install everything into /usr/lib/python3.6/site-packages (or whatever " -"your platform’s standard location is), it’s easy to end up in a situation " -"where you unintentionally upgrade an application that shouldn’t be upgraded." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:209 -msgid "" -"Or more generally, what if you want to install an application and leave it " -"be? If an application works, any change in its libraries or the versions of " -"those libraries can break the application." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:213 -msgid "" -"Also, what if you can’t install :term:`packages ` into " -"the global site-packages directory? For instance, on a shared host." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:216 -msgid "" -"In all these cases, virtual environments can help you. They have their own " -"installation directories and they don’t share libraries with other virtual " -"environments." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:220 -msgid "" -"Currently, there are two common tools for creating Python virtual " -"environments:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:222 -msgid "" -"`venv`_ is available by default in Python 3.3 and later, and installs :ref:" -"`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 " -"and later." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:225 -msgid "" -":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ " -"and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are " -"always installed into created virtual environments by default (regardless of " -"Python version)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:230 -msgid "The basic usage is like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:232 -msgid "Using `venv`_:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:248 -msgid "Using :ref:`virtualenv`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:264 -msgid "" -"For more information, see the `venv`_ docs or the `virtualenv `_ docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:266 -msgid "" -"The use of :command:`source` under Unix shells ensures that the virtual " -"environment's variables are set within the current shell, and not in a " -"subprocess (which then disappears, having no useful effect)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:271 -msgid "" -"In both of the above cases, Windows users should _not_ use the :command:" -"`source` command, but should rather run the :command:`activate` script " -"directly from the command shell like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:281 -msgid "" -"Managing multiple virtual environments directly can become tedious, so the :" -"ref:`dependency management tutorial ` introduces a " -"higher level tool, :ref:`Pipenv`, that automatically manages a separate " -"virtual environment for each project and application that you work on." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:288 -msgid "Use pip for Installing" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:290 -msgid "" -":ref:`pip` is the recommended installer. Below, we'll cover the most common " -"usage scenarios. For more detail, see the `pip docs `_, " -"which includes a complete `Reference Guide `_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:297 -msgid "Installing from PyPI" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:299 -msgid "" -"The most common usage of :ref:`pip` is to install from the :term:`Python " -"Package Index ` using a :term:`requirement " -"specifier `. Generally speaking, a requirement " -"specifier is composed of a project name followed by an optional :term:" -"`version specifier `. :pep:`440` contains a :pep:`full " -"specification <440#version-specifiers>` of the currently supported " -"specifiers. Below are some examples." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:307 -msgid "To install the latest version of \"SomeProject\":" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:321 -msgid "To install a specific version:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:335 -msgid "To install greater than or equal to one version and less than another:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:350 -msgid "" -"To install a version that's :pep:`\"compatible\" <440#compatible-release>` " -"with a certain version: [4]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:365 -msgid "" -"In this case, this means to install any version \"==1.4.*\" version that's " -"also \">=1.4.2\"." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:370 -msgid "Source Distributions vs Wheels" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:372 -msgid "" -":ref:`pip` can install from either :term:`Source Distributions (sdist) " -"` or :term:`Wheels `, but if both " -"are present on PyPI, pip will prefer a compatible :term:`wheel `. You " -"can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:378 -msgid "" -":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source " -"Distributions (sdist) `, especially when " -"a project contains compiled extensions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:383 -msgid "" -"If :ref:`pip` does not find a wheel to install, it will locally build a " -"wheel and cache it for future installs, instead of rebuilding the source " -"distribution in the future." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:391 -msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:408 -msgid "Installing to the User Site" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:410 -msgid "" -"To install :term:`packages ` that are isolated to the " -"current user, use the ``--user`` flag:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:425 -msgid "" -"For more information see the `User Installs `_ section from the pip docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:429 -msgid "" -"Note that the ``--user`` flag has no effect when inside a virtual " -"environment - all installation commands will affect the virtual environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:432 -msgid "" -"If ``SomeProject`` defines any command-line scripts or console entry points, " -"``--user`` will cause them to be installed inside the `user base`_'s binary " -"directory, which may or may not already be present in your shell's :envvar:" -"`PATH`. (Starting in version 10, pip displays a warning when installing any " -"scripts to a directory outside :envvar:`PATH`.) If the scripts are not " -"available in your shell after installation, you'll need to add the directory " -"to your :envvar:`PATH`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:440 -msgid "" -"On Linux and macOS you can find the user base binary directory by running " -"``python -m site --user-base`` and adding ``bin`` to the end. For example, " -"this will typically print ``~/.local`` (with ``~`` expanded to the absolute " -"path to your home directory) so you'll need to add ``~/.local/bin`` to your " -"``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:446 -msgid "" -"On Windows you can find the user base binary directory by running ``py -m " -"site --user-site`` and replacing ``site-packages`` with ``Scripts``. For " -"example, this could return ``C:\\Users\\Username\\AppData\\Roaming" -"\\Python36\\site-packages`` so you would need to set your ``PATH`` to " -"include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You " -"can set your user ``PATH`` permanently in the `Control Panel`_. You may need " -"to log out for the ``PATH`` changes to take effect." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:462 -msgid "" -"Install a list of requirements specified in a :ref:`Requirements File `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:478 -msgid "Installing from VCS" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:480 -msgid "" -"Install a project from VCS in \"editable\" mode. For a full breakdown of " -"the syntax, see pip's section on :ref:`VCS Support `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:502 -msgid "Installing from other Indexes" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:504 -msgid "Install from an alternate index" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:518 -msgid "" -"Search an additional index during install, in addition to :term:`PyPI " -"`" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:534 -msgid "Installing from a local src tree" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:537 -msgid "" -"Installing from local src in `Development Mode `_, i.e. in such a " -"way that the project appears to be installed, but yet is still editable from " -"the src tree." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:554 -msgid "You can also install normally from src" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:571 -msgid "Install a particular source archive file." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:585 -msgid "" -"Install from a local directory containing archives (and don't check :term:" -"`PyPI `)" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:605 -msgid "Installing from other sources" -msgstr "从其他来源安装" - -#: ../source/tutorials/installing-packages.rst:607 -msgid "" -"To install from other data sources (for example Amazon S3 storage) you can " -"create a helper application that presents the data in a :pep:`503` compliant " -"index format, and use the ``--extra-index-url`` flag to direct pip to use " -"that index." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:619 -msgid "Installing Prereleases" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:621 -msgid "" -"Find pre-release and development versions, in addition to stable versions. " -"By default, pip only finds stable versions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:637 -msgid "Installing Setuptools \"Extras\"" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:639 -msgid "Install `setuptools extras`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:659 -msgid "" -"\"Secure\" in this context means using a modern browser or a tool like :" -"command:`curl` that verifies SSL certificates when downloading from https " -"URLs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:668 -msgid "" -"Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:" -"`virtualenv`) will create virtualenv environments with ``pip`` pre-" -"installed, thereby making it an equal alternative to :ref:`virtualenv`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:673 -msgid "" -"The compatible release specifier was accepted in :pep:`440` and support was " -"released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:4 -msgid "Managing Application Dependencies" -msgstr "管理应用程序的依赖性" - -#: ../source/tutorials/managing-dependencies.rst:6 -msgid "" -"The :ref:`package installation tutorial ` covered the " -"basics of getting set up to install and update Python packages." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:9 -msgid "" -"However, running these commands interactively can get tedious even for your " -"own personal projects, and things get even more difficult when trying to set " -"up development environments automatically for projects with multiple " -"contributors." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:13 -msgid "" -"This tutorial walks you through the use of :ref:`Pipenv` to manage " -"dependencies for an application. It will show you how to install and use the " -"necessary tools and make strong recommendations on best practices." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:17 -msgid "" -"Keep in mind that Python is used for a great many different purposes, and " -"precisely how you want to manage your dependencies may change based on how " -"you decide to publish your software. The guidance presented here is most " -"directly applicable to the development and deployment of network services " -"(including web applications), but is also very well suited to managing " -"development and testing environments for any kind of project." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:24 -msgid "" -"Developers of Python libraries, or of applications that support distribution " -"as Python libraries, should also consider the `poetry `_ project as an alternative dependency management " -"solution." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:30 -msgid "Installing Pipenv" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:32 -msgid "" -":ref:`Pipenv` is a dependency manager for Python projects. If you're " -"familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit " -"to those tools. While :ref:`pip` alone is often sufficient for personal use, " -"Pipenv is recommended for collaborative projects as it's a higher-level tool " -"that simplifies dependency management for common use cases." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:38 -msgid "Use ``pip`` to install Pipenv:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:54 -msgid "" -"This does a `user installation`_ to prevent breaking any system-wide " -"packages. If ``pipenv`` isn't available in your shell after installation, " -"you'll need to add the `user base`_'s binary directory to your ``PATH``. " -"See :ref:`Installing to the User Site` for more information." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:65 -msgid "Installing packages for your project" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:67 -msgid "" -"Pipenv manages dependencies on a per-project basis. To install packages, " -"change into your project's directory (or just an empty directory for this " -"tutorial) and run:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:76 -msgid "" -"Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you " -"in your project's directory. The :ref:`Pipfile` is used to track which " -"dependencies your project needs in case you need to re-install them, such as " -"when you share your project with others. You should get output similar to " -"this (although the exact paths shown will vary):" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:112 -msgid "Using installed packages" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:114 -msgid "" -"Now that Requests is installed you can create a simple :file:`main.py` file " -"to use it:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:125 -msgid "Then you can run this script using ``pipenv run``:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:131 -msgid "You should get output similar to this:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:137 -msgid "" -"Using ``pipenv run`` ensures that your installed packages are available to " -"your script. It's also possible to spawn a new shell that ensures all " -"commands have access to your installed packages with ``pipenv shell``." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:143 -#: ../source/tutorials/packaging-projects.rst:594 -msgid "Next steps" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:145 -msgid "" -"Congratulations, you now know how to effectively manage dependencies and " -"development environments on a collaborative Python project! ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:148 -msgid "" -"If you're interested in creating and distributing your own Python packages, " -"see the :ref:`tutorial on packaging and distributing packages `." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:151 -msgid "" -"Note that when your application includes definitions of Python source " -"packages, they (and their dependencies) can be added to your ``pipenv`` " -"environment with ``pipenv install -e `` " -"(e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:160 -msgid "Other Tools for Application Dependency Management" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:162 -msgid "" -"If you find this particular approach to managing application dependencies " -"isn't working well for you or your use case, you may want to explore these " -"other tools and techniques to see if one of them is a better fit:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:166 -msgid "" -"`poetry `__ for a tool comparable " -"in scope to ``pipenv`` that focuses more directly on use cases where the " -"repository being managed is structured as a Python project with a valid " -"``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making " -"the assumption that the application being worked on that's depending on " -"components from PyPI will itself support distribution as a ``pip``-" -"installable Python package)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:172 -msgid "" -"`hatch `_ for opinionated coverage of even " -"more steps in the project management workflow (such as incrementing " -"versions, tagging releases, and creating new skeleton projects from project " -"templates)" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:175 -msgid "" -"`pip-tools `_ to build your own " -"custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:177 -msgid "" -"`micropipenv `_ is a " -"lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry " -"lock files or converting them to pip-tools compatible output. Designed for " -"containerized Python applications but not limited to them." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:2 -msgid "Packaging Python Projects" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:4 -msgid "" -"This tutorial walks you through how to package a simple Python project. It " -"will show you how to add the necessary files and structure to create the " -"package, how to build the package, and how to upload it to the Python " -"Package Index." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:10 -msgid "" -"If you have trouble running the commands in this tutoral, please copy the " -"command and its output, then `open an issue`_ on the `packaging-problems`_ " -"repository on GitHub. We'll do our best to help you!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:18 -msgid "" -"Some of the commands require a newer version of :ref:`pip`, so start by " -"making sure you have the latest version installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:35 -msgid "A simple project" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:37 -msgid "" -"This tutorial uses a simple project named ``example_package``. We recommend " -"following this tutorial as-is using this project, before packaging your own " -"project." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:41 -msgid "Create the following file structure locally:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:51 -msgid "" -":file:`__init__.py` is required to import the directory as a package, and " -"should be empty." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:54 -msgid "" -":file:`example.py` is an example of a module within the package that could " -"contain the logic (functions, classes, constants, etc.) of your package. " -"Open that file and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:63 -msgid "" -"If you are unfamiliar with Python's :term:`modules ` and :term:" -"`import packages `, take a few minutes to read over the " -"`Python documentation for packages and modules`_." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:67 -msgid "" -"Once you create this structure, you'll want to run all of the commands in " -"this tutorial within the ``packaging_tutorial`` directory." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:75 -msgid "Creating the package files" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:77 -msgid "" -"You will now add files that are used to prepare the project for " -"distribution. When you're done, the project structure will look like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:95 -msgid "Creating a test directory" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:97 -msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:101 -msgid "Creating pyproject.toml" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:103 -msgid "" -":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) " -"what is required to build your project. This tutorial uses :ref:" -"`setuptools`, so open :file:`pyproject.toml` and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:117 -msgid "" -"``build-system.requires`` gives a list of packages that are needed to build " -"your package. Listing something here will *only* make it available during " -"the build, not after it is installed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:121 -msgid "" -"``build-system.build-backend`` is the name of Python object that will be " -"used to perform the build. If you were to use a different build system, such " -"as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration " -"details would be completely different than the :ref:`setuptools` " -"configuration described below." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:127 -msgid "See :pep:`517` and :pep:`518` for background and details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:131 -msgid "Configuring metadata" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:133 -msgid "There are two types of metadata: static and dynamic." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:135 -msgid "" -"Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. " -"This is simpler, easier to read, and avoids many common errors, like " -"encoding errors." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:137 -msgid "" -"Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items " -"that are dynamic or determined at install-time, as well as extension modules " -"or extensions to setuptools, need to go into :file:`setup.py`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:141 -msgid "" -"Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:" -"file:`setup.py`) should be used only as an escape hatch when absolutely " -"necessary. :file:`setup.py` used to be required, but can be omitted with " -"newer versions of setuptools and pip." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:148 -msgid "" -":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells " -"setuptools about your package (such as the name and version) as well as " -"which code files to include. Eventually much of this configuration may be " -"able to move to :file:`pyproject.toml`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:153 -msgid "" -"Open :file:`setup.cfg` and enter the following content. Change the ``name`` " -"to include your username; this ensures that you have a unique package name " -"and that your package doesn't conflict with packages uploaded by other " -"people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:185 -msgid "" -"There are a `variety of metadata and options `_ supported here. This is " -"in :doc:`configparser ` format; do not place " -"quotes around values. This example package uses a relatively minimal set of " -"``metadata``:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:191 -#: ../source/tutorials/packaging-projects.rst:286 -msgid "" -"``name`` is the *distribution name* of your package. This can be any name as " -"long as it only contains letters, numbers, ``_`` , and ``-``. It also must " -"not already be taken on pypi.org. **Be sure to update this with your " -"username,** as this ensures you won't try to upload a package with the same " -"name as one which already exists." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:196 -msgid "" -"``version`` is the package version. See :pep:`440` for more details on " -"versions. You can use ``file:`` or ``attr:`` directives to read from a file " -"or package attribute." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:199 -#: ../source/tutorials/packaging-projects.rst:293 -msgid "" -"``author`` and ``author_email`` are used to identify the author of the " -"package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:201 -#: ../source/tutorials/packaging-projects.rst:295 -msgid "``description`` is a short, one-sentence summary of the package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:202 -msgid "" -"``long_description`` is a detailed description of the package. This is shown " -"on the package detail page on the Python Package Index. In this case, the " -"long description is loaded from :file:`README.md` (which is a common " -"pattern) using the ``file:`` directive." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:206 -#: ../source/tutorials/packaging-projects.rst:300 -msgid "" -"``long_description_content_type`` tells the index what type of markup is " -"used for the long description. In this case, it's Markdown." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:208 -#: ../source/tutorials/packaging-projects.rst:302 -msgid "" -"``url`` is the URL for the homepage of the project. For many projects, this " -"will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting " -"service." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:211 -#: ../source/tutorials/packaging-projects.rst:305 -msgid "" -"``project_urls`` lets you list any number of extra links to show on PyPI. " -"Generally this could be to documentation, issue trackers, etc." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:213 -#: ../source/tutorials/packaging-projects.rst:307 -msgid "" -"``classifiers`` gives the index and :ref:`pip` some additional metadata " -"about your package. In this case, the package is only compatible with Python " -"3, is licensed under the MIT license, and is OS-independent. You should " -"always include at least which version(s) of Python your package works on, " -"which license your package is available under, and which operating systems " -"your package will work on. For a complete list of classifiers, see https://" -"pypi.org/classifiers/." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:221 -msgid "In the ``options`` category, we have controls for setuptools itself:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:223 -msgid "" -"``package_dir`` is a mapping of package names and directories. An empty " -"package name represents the \"root package\" --- the directory in the " -"project that contains all Python source files for the package --- so in this " -"case the ``src`` directory is designated the root package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:227 -msgid "" -"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " -"`. Instead of listing each package manually, we can " -"use the ``find:`` directive to automatically discover all packages and " -"subpackages and ``options.packages.find`` to specify the ``package_dir`` to " -"use. In this case, the list of packages will be ``example_package`` as " -"that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:234 -msgid "" -"``python_requires`` gives the versions of Python supported by your project. " -"Installers like :ref:`pip` will look back through older versions of packages " -"until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:238 -#: ../source/tutorials/packaging-projects.rst:329 -msgid "" -"There are many more than the ones mentioned here. See :doc:`/guides/" -"distributing-packages-using-setuptools` for more details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:244 -msgid "" -":file:`setup.py` is the build script for :ref:`setuptools`. It tells " -"setuptools about your package (such as the name and version) as well as " -"which code files to include." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:248 -msgid "" -"Open :file:`setup.py` and enter the following content. Change the ``name`` " -"to include your username; this ensures that you have a unique package name " -"and that your package doesn't conflict with packages uploaded by other " -"people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:283 -msgid "" -":func:`setup` takes several arguments. This example package uses a " -"relatively minimal set:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:291 -msgid "" -"``version`` is the package version. See :pep:`440` for more details on " -"versions." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:296 -msgid "" -"``long_description`` is a detailed description of the package. This is shown " -"on the package detail page on the Python Package Index. In this case, the " -"long description is loaded from :file:`README.md`, which is a common pattern." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:314 -msgid "" -"``package_dir`` is a dictionary with package names for keys and directories " -"for values. An empty package name represents the \"root package\" --- the " -"directory in the project that contains all Python source files for the " -"package --- so in this case the ``src`` directory is designated the root " -"package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:319 -msgid "" -"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " -"`. Instead of listing each package manually, we can " -"use :func:`find_packages` to automatically discover all packages and " -"subpackages under ``package_dir``. In this case, the list of packages will " -"be ``example_package`` as that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:325 -msgid "" -"``python_requires`` gives the versions of Python supported by your project. " -"Installers like :ref:`pip` will look back though older versions of packages " -"until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:333 -msgid "Creating README.md" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:335 -msgid "" -"Open :file:`README.md` and enter the following content. You can customize " -"this if you'd like." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:347 -msgid "" -"Because our configuration loads :file:`README.md` to provide a " -"``long_description``, :file:`README.md` must be included along with your " -"code when you :ref:`generate a source distribution `. " -"Newer versions of :ref:`setuptools` will do this automatically." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:354 -msgid "Creating a LICENSE" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:356 -msgid "" -"It's important for every package uploaded to the Python Package Index to " -"include a license. This tells users who install your package the terms under " -"which they can use your package. For help picking a license, see https://" -"choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` " -"and enter the license text. For example, if you had chosen the MIT license:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:387 -msgid "Including other files" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:389 -msgid "" -"The files listed above will be included automatically in your :term:`source " -"distribution `. If you want to control " -"what goes in this explicitly, see :ref:`Using MANIFEST.in`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:393 -msgid "" -"The final :term:`built distribution ` will have the " -"Python files in the discovered or listed Python packages. If you want to " -"control what goes here, such as to add data files, see :doc:`Including Data " -"Files ` from the :doc:`setuptools docs " -"`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:402 -msgid "Generating distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:404 -msgid "" -"The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the " -"Python Package Index and can be installed by :ref:`pip`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:408 -msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" -msgstr "确保您安装了最新版本的 PyPA 的 :ref:`build`：" - -#: ../source/tutorials/packaging-projects.rst:422 -msgid "" -"If you have trouble installing these, see the :doc:`installing-packages` " -"tutorial." -msgstr "如果您在安装这些东西时遇到困难，请查看 :doc:`installing-packages`教程。" - -#: ../source/tutorials/packaging-projects.rst:425 -msgid "" -"Now run this command from the same directory where :file:`pyproject.toml` is " -"located:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:439 -msgid "" -"This command should output a lot of text and once completed should generate " -"two files in the :file:`dist` directory:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:449 -msgid "" -"The ``tar.gz`` file is a :term:`source archive ` whereas the " -"``.whl`` file is a :term:`built distribution `. Newer :" -"ref:`pip` versions preferentially install built distributions, but will fall " -"back to source archives if needed. You should always upload a source archive " -"and provide built archives for the platforms your project is compatible " -"with. In this case, our example package is compatible with Python on any " -"platform so only one built distribution is needed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:458 -msgid "Uploading the distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:460 -msgid "Finally, it's time to upload your package to the Python Package Index!" -msgstr "最后，是时候把您的软件包上传到 Python Package Index 了！" - -#: ../source/tutorials/packaging-projects.rst:462 -msgid "" -"The first thing you'll need to do is register an account on TestPyPI, which " -"is a separate instance of the package index intended for testing and " -"experimentation. It's great for things like this tutorial where we don't " -"necessarily want to upload to the real index. To register an account, go to " -"https://test.pypi.org/account/register/ and complete the steps on that page. " -"You will also need to verify your email address before you're able to upload " -"any packages. For more details, see :doc:`/guides/using-testpypi`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:470 -msgid "" -"To securely upload your project, you'll need a PyPI `API token`_. Create one " -"at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" " -"to \"Entire account\". **Don't close the page until you have copied and " -"saved the token — you won't see that token again.**" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:477 -msgid "" -"Now that you are registered, you can use :ref:`twine` to upload the " -"distribution packages. You'll need to install Twine:" -msgstr "现在您已经注册了，您可以使用 :ref:`twine` 来上传发行包。您需要安装 Twine：" - -#: ../source/tutorials/packaging-projects.rst:492 -msgid "" -"Once installed, run Twine to upload all of the archives under :file:`dist`:" -msgstr "安装完毕后，运行 Twine 以上传 :file:`dist`下的所有档案：" - -#: ../source/tutorials/packaging-projects.rst:506 -msgid "" -"You will be prompted for a username and password. For the username, use " -"``__token__``. For the password, use the token value, including the ``pypi-" -"`` prefix." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:510 -msgid "After the command completes, you should see output similar to this:" -msgstr "命令完成后，您应该会看到类似这样的输出：" - -#: ../source/tutorials/packaging-projects.rst:523 -msgid "" -"Once uploaded your package should be viewable on TestPyPI, for example, " -"https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" -msgstr "" -"一旦上传，您的软件包应该可以在 TestPyPI 上查看，例如，https://test.pypi.org/project/example-pkg-" -"YOUR-USERNAME-HERE" - -#: ../source/tutorials/packaging-projects.rst:528 -msgid "Installing your newly uploaded package" -msgstr "安装您新上传的软件包" - -#: ../source/tutorials/packaging-projects.rst:530 -msgid "" -"You can use :ref:`pip` to install your package and verify that it works. " -"Create a :ref:`virtual environment ` and install your package from TestPyPI:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:546 -msgid "Make sure to specify your username in the package name!" -msgstr "请确保在软件包名称中指定您的用户名!" - -#: ../source/tutorials/packaging-projects.rst:548 -msgid "" -"pip should install the package from TestPyPI and the output should look " -"something like this:" -msgstr "pip应该会安装 TestPyPI 的软件包，输出结果应该是这样的：" - -#: ../source/tutorials/packaging-projects.rst:558 -msgid "" -"This example uses ``--index-url`` flag to specify TestPyPI instead of live " -"PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have " -"the same packages as the live PyPI, it's possible that attempting to install " -"dependencies may fail or install something unexpected. While our example " -"package doesn't have any dependencies, it's a good practice to avoid " -"installing dependencies when using TestPyPI." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:565 -msgid "" -"You can test that it was installed correctly by importing the package. Make " -"sure you're still in your virtual environment, then run Python:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:580 -msgid "and import the package:" -msgstr "并导入该软件包：" - -#: ../source/tutorials/packaging-projects.rst:588 -msgid "" -"Note that the :term:`import package ` is ``example_package`` " -"regardless of what ``name`` you gave your :term:`distribution package " -"` in :file:`setup.cfg` or :file:`setup.py` (in this " -"case, ``example-pkg-YOUR-USERNAME-HERE``)." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:596 -msgid "" -"**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:599 -msgid "" -"Keep in mind that this tutorial showed you how to upload your package to " -"Test PyPI, which isn't a permanent storage. The Test system occasionally " -"deletes packages and accounts. It is best to use TestPyPI for testing and " -"experiments like this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:604 -msgid "" -"When you are ready to upload a real package to the Python Package Index you " -"can do much the same as you did in this tutorial, but with these important " -"differences:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:608 -msgid "" -"Choose a memorable and unique name for your package. You don't have to " -"append your username as you did in the tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:610 -msgid "" -"Register an account on https://pypi.org - note that these are two separate " -"servers and the login details from the test server are not shared with the " -"main server." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:613 -msgid "" -"Use ``twine upload dist/*`` to upload your package and enter your " -"credentials for the account you registered on the real PyPI. Now that " -"you're uploading the package in production, you don't need to specify ``--" -"repository``; the package will upload to https://pypi.org/ by default." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:617 -msgid "" -"Install your package from the real PyPI using ``python3 -m pip install [your-" -"package]``." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:619 -msgid "" -"At this point if you want to read more on packaging Python libraries here " -"are some things you can do:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:622 -msgid "" -"Read more about using :ref:`setuptools` to package libraries in :doc:`/" -"guides/distributing-packages-using-setuptools`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:624 -msgid "Read about :doc:`/guides/packaging-binary-extensions`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:625 -msgid "" -"Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:" -"`hatch`, and :ref:`poetry`." -msgstr "" -"考虑 :ref:`setuptools` 的替代方案，如 :ref:`flit`, :ref:`hatch`, 和 :ref:`poetry`。" diff --git a/locales/zh_Hant/LC_MESSAGES/messages.po b/locales/zh_Hant/LC_MESSAGES/messages.po deleted file mode 100644 index dc363507a..000000000 --- a/locales/zh_Hant/LC_MESSAGES/messages.po +++ /dev/null @@ -1,13545 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2013–2020, PyPA -# This file is distributed under the same license as the Python Packaging User Guide package. -# meowmeowmeowcat , 2021. -msgid "" -msgstr "" -"Project-Id-Version: Python Packaging User Guide\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-08-13 22:32+0000\n" -"Last-Translator: meowmeowmeowcat \n" -"Language-Team: Chinese (Traditional) \n" -"Language: zh_Hant\n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=UTF-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Plural-Forms: nplurals=1; plural=0;\n" -"X-Generator: Weblate 4.8-dev\n" - -#: ../source/contribute.rst:5 -msgid "Contribute to this guide" -msgstr "為本指南做出貢獻" - -#: ../source/contribute.rst:7 -msgid "" -"The |PyPUG| welcomes contributors! There are lots of ways to help out, " -"including:" -msgstr "|PyPUG| 歡迎貢獻者！有很多方法可以提供幫助，包括：" - -#: ../source/contribute.rst:10 -msgid "Reading the guide and giving feedback" -msgstr "閱讀本指南並提供反饋" - -#: ../source/contribute.rst:11 -msgid "Reviewing new contributions" -msgstr "審查新的貢獻" - -#: ../source/contribute.rst:12 -msgid "Revising existing content" -msgstr "修改現有內容" - -#: ../source/contribute.rst:13 -msgid "Writing new content" -msgstr "編寫新內容" - -#: ../source/contribute.rst:15 -msgid "" -"Most of the work on the |PyPUG| takes place on the `project's GitHub " -"repository`__. To get started, check out the list of `open issues`__ and " -"`pull requests`__. If you're planning to write or edit the guide, please " -"read the :ref:`style guide `." -msgstr "" -"大部分關於 |PyPUG| 的工作都是在 `項目的 GitHub 倉庫 ` 進行的。要開始工作，" -"請查看 `open issues`__ 和 `pull requests`__ 的列表。如果你打算編寫或編輯指南，請閱讀 :ref:`風格指南 " -"`。" - -#: ../source/contribute.rst:24 -msgid "" -"By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of " -"Conduct`__." -msgstr "如果你打算為 |PyPUG| 作出貢獻，你就應該遵守 PSF 的 `行為守則`__。" - -#: ../source/contribute.rst:31 -msgid "Documentation types" -msgstr "文件類型" - -#: ../source/contribute.rst:33 -msgid "" -"This project consists of four distinct documentation types with specific " -"purposes. When proposing new additions to the project please pick the " -"appropriate documentation type." -msgstr "" - -#: ../source/contribute.rst:38 ../source/tutorials/index.rst:2 -msgid "Tutorials" -msgstr "教學" - -#: ../source/contribute.rst:40 -msgid "" -"Tutorials are focused on teaching the reader new concepts by accomplishing a " -"goal. They are opinionated step-by-step guides. They do not include " -"extraneous warnings or information. `example tutorial-style document`_." -msgstr "" - -#: ../source/contribute.rst:47 ../source/guides/index.rst:2 -msgid "Guides" -msgstr "指南" - -#: ../source/contribute.rst:49 -msgid "" -"Guides are focused on accomplishing a specific task and can assume some " -"level of pre-requisite knowledge. These are similar to tutorials, but have a " -"narrow and clear focus and can provide lots of caveats and additional " -"information as needed. They may also discuss multiple approaches to " -"accomplishing the task. :doc:`example guide-style document `." -msgstr "" - -#: ../source/contribute.rst:56 ../source/discussions/index.rst:2 -msgid "Discussions" -msgstr "討論" - -#: ../source/contribute.rst:58 -msgid "" -"Discussions are focused on understanding and information. These explore a " -"specific topic without a specific goal in mind. :doc:`example discussion-" -"style document `." -msgstr "" - -#: ../source/contribute.rst:63 -msgid "Specifications" -msgstr "規格" - -#: ../source/contribute.rst:65 -msgid "" -"Specifications are reference documention focused on comprehensively " -"documenting an agreed-upon interface for interoperability between packaging " -"tools. :doc:`example specification-style document `." -msgstr "" - -#: ../source/contribute.rst:73 -msgid "Building the guide locally" -msgstr "在本地構建指南" - -#: ../source/contribute.rst:75 -msgid "" -"Though not required to contribute, it may be useful to build this guide " -"locally in order to test your changes. In order to build this guide locally, " -"you'll need:" -msgstr "" - -#: ../source/contribute.rst:79 -msgid "" -"`Nox `_. You can install or upgrade " -"nox using ``pip``::" -msgstr "" -"`Nox `_。您可以使用 ``pip`` 來安裝或升" -"級 nox::" - -#: ../source/contribute.rst:84 -msgid "" -"Python 3.6. Our build scripts are designed to work with Python 3.6 only. See " -"the `Hitchhiker's Guide to Python installation instructions`_ to install " -"Python 3.6 on your operating system." -msgstr "" -"Python 3.6。我們的構建腳本只為 Python 3.6 而設計。請參閱 `Hitchhiker's Guide " -"to Python installation instructions`_ 以在您的操作系統上安裝Python 3.6。" - -#: ../source/contribute.rst:91 -msgid "" -"To build the guide, run the following bash command in the source folder::" -msgstr "要構建指南，請在 source 資料夾中運行以下 bash 命令::" - -#: ../source/contribute.rst:95 -msgid "" -"After the process has completed you can find the HTML output in the ``./" -"build/html`` directory. You can open the ``index.html`` file to view the " -"guide in web browser, but it's recommended to serve the guide using an HTTP " -"server." -msgstr "" - -#: ../source/contribute.rst:100 -msgid "" -"You can build the guide and serve it via an HTTP server using the following " -"command::" -msgstr "" - -#: ../source/contribute.rst:105 -msgid "The guide will be browsable via http://localhost:8000." -msgstr "該指南將可通過 http://localhost:8000 進行瀏覽。" - -#: ../source/contribute.rst:109 -msgid "Where the guide is deployed" -msgstr "" - -#: ../source/contribute.rst:111 -msgid "" -"The guide is deployed via ReadTheDocs and the configuration lives at https://" -"readthedocs.org/projects/python-packaging-user-guide/. It's served from a " -"custom domain and fronted by Fast.ly." -msgstr "" - -#: ../source/contribute.rst:117 -msgid "Style guide" -msgstr "風格指南" - -#: ../source/contribute.rst:119 -msgid "" -"This style guide has recommendations for how you should write the |PyPUG|. " -"Before you start writing, please review it. By following the style guide, " -"your contributions will help add to a cohesive whole and make it easier for " -"your contributions to be accepted into the project." -msgstr "" - -#: ../source/contribute.rst:126 -msgid "Purpose" -msgstr "目的" - -#: ../source/contribute.rst:128 -msgid "" -"The purpose of the |PyPUG| is to be the authoritative resource on how to " -"package, publish, and install Python projects using current tools." -msgstr "" - -#: ../source/contribute.rst:133 -msgid "Scope" -msgstr "範圍" - -#: ../source/contribute.rst:135 -msgid "" -"The guide is meant to answer questions and solve problems with accurate and " -"focused recommendations." -msgstr "該指南旨在通過準確和有針對性的建議回答問題和解決問題。" - -#: ../source/contribute.rst:138 -msgid "" -"The guide isn't meant to be comprehensive and it's not meant to replace " -"individual projects' documentation. For example, pip has dozens of commands, " -"options, and settings. The pip documentation describes each of them in " -"detail, while this guide describes only the parts of pip that are needed to " -"complete the specific tasks described in this guide." -msgstr "" - -#: ../source/contribute.rst:146 -msgid "Audience" -msgstr "觀眾" - -#: ../source/contribute.rst:148 -msgid "The audience of this guide is anyone who uses Python with packages." -msgstr "本指南的受眾是任何使用 Python 包的人。" - -#: ../source/contribute.rst:150 -msgid "" -"Don't forget that the Python community is big and welcoming. Readers may not " -"share your age, gender, education, culture, and more, but they deserve to " -"learn about packaging just as much as you do." -msgstr "" - -#: ../source/contribute.rst:154 -msgid "" -"In particular, keep in mind that not all people who use Python see " -"themselves as programmers. The audience of this guide includes astronomers " -"or painters or students as well as professional software developers." -msgstr "" - -#: ../source/contribute.rst:160 -msgid "Voice and tone" -msgstr "" - -#: ../source/contribute.rst:162 -msgid "" -"When writing this guide, strive to write with a voice that's approachable " -"and humble, even if you have all the answers." -msgstr "" - -#: ../source/contribute.rst:165 -msgid "" -"Imagine you're working on a Python project with someone you know to be smart " -"and skilled. You like working with them and they like working with you. That " -"person has asked you a question and you know the answer. How do you respond? " -"*That* is how you should write this guide." -msgstr "" - -#: ../source/contribute.rst:170 -msgid "" -"Here's a quick check: try reading aloud to get a sense for your writing's " -"voice and tone. Does it sound like something you would say or does it sound " -"like you're acting out a part or giving a speech? Feel free to use " -"contractions and don't worry about sticking to fussy grammar rules. You are " -"hereby granted permission to end a sentence in a preposition, if that's what " -"you want to end it with." -msgstr "" - -#: ../source/contribute.rst:177 -msgid "" -"When writing the guide, adjust your tone for the seriousness and difficulty " -"of the topic. If you're writing an introductory tutorial, it's OK to make a " -"joke, but if you're covering a sensitive security recommendation, you might " -"want to avoid jokes altogether." -msgstr "" - -#: ../source/contribute.rst:184 -msgid "Conventions and mechanics" -msgstr "" - -#: ../source/contribute.rst:192 -msgid "**Write to the reader**" -msgstr "" - -#: ../source/contribute.rst:187 -msgid "" -"When giving recommendations or steps to take, address the reader as *you* or " -"use the imperative mood." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: To install it, the user runs…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: You can install it by running…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: To install it, run…" -msgstr "" - -#: ../source/contribute.rst:198 -msgid "**State assumptions**" -msgstr "" - -#: ../source/contribute.rst:195 -msgid "" -"Avoid making unstated assumptions. Reading on the web means that any page of " -"the guide may be the first page of the guide that the reader ever sees. If " -"you're going to make assumptions, then say what assumptions that you're " -"going to make." -msgstr "" - -#: ../source/contribute.rst:203 -msgid "**Cross-reference generously**" -msgstr "" - -#: ../source/contribute.rst:201 -msgid "" -"The first time you mention a tool or practice, link to the part of the guide " -"that covers it, or link to a relevant document elsewhere. Save the reader a " -"search." -msgstr "" - -#: ../source/contribute.rst:213 -msgid "**Respect naming practices**" -msgstr "" - -#: ../source/contribute.rst:206 -msgid "" -"When naming tools, sites, people, and other proper nouns, use their " -"preferred capitalization." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: Pip uses…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: pip uses…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: …hosted on github." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: …hosted on GitHub." -msgstr "" - -#: ../source/contribute.rst:222 -msgid "**Use a gender-neutral style**" -msgstr "" - -#: ../source/contribute.rst:216 -msgid "" -"Often, you'll address the reader directly with *you*, *your* and *yours*. " -"Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or " -"avoid pronouns entirely." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: A maintainer uploads the file. Then he…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then they…" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: A maintainer uploads the file. Then the maintainer…" -msgstr "" - -#: ../source/contribute.rst:234 -msgid "**Headings**" -msgstr "" - -#: ../source/contribute.rst:225 -msgid "" -"Write headings that use words the reader is searching for. A good way to do " -"this is to have your heading complete an implied question. For example, a " -"reader might want to know *How do I install MyLibrary?* so a good heading " -"might be *Install MyLibrary*." -msgstr "" - -#: ../source/contribute.rst:230 -msgid "" -"In section headings, use sentence case. In other words, write headings as " -"you would write a typical sentence." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: Things You Should Know About Python" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: Things you should know about Python" -msgstr "" - -#: ../source/contribute.rst:237 -msgid "**Numbers**" -msgstr "" - -#: ../source/contribute.rst:237 -msgid "" -"In body text, write numbers one through nine as words. For other numbers or " -"numbers in tables, use numerals." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:4 -msgid "Deploying Python applications" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Page Status" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:6 -#: ../source/guides/index-mirrors-and-caches.rst:7 -#: ../source/guides/installing-using-linux-tools.rst:7 -#: ../source/guides/packaging-binary-extensions.rst:7 -#: ../source/guides/supporting-multiple-python-versions.rst:7 -#: ../source/guides/supporting-windows-using-appveyor.rst:5 -msgid "Incomplete" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:0 -#: ../source/guides/index-mirrors-and-caches.rst:0 -#: ../source/guides/installing-using-linux-tools.rst:0 -#: ../source/guides/packaging-binary-extensions.rst:0 -#: ../source/guides/supporting-multiple-python-versions.rst:0 -#: ../source/guides/supporting-windows-using-appveyor.rst:0 -msgid "Last Reviewed" -msgstr "上次審核" - -#: ../source/discussions/deploying-python-applications.rst:7 -msgid "2014-11-11" -msgstr "2014-11-11" - -#: ../source/discussions/deploying-python-applications.rst:11 -#: ../source/discussions/install-requires-vs-requirements.rst:9 -#: ../source/guides/analyzing-pypi-package-downloads.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:22 -#: ../source/guides/index-mirrors-and-caches.rst:12 -#: ../source/guides/installing-scientific-packages.rst:9 -#: ../source/guides/packaging-binary-extensions.rst:17 -#: ../source/guides/supporting-multiple-python-versions.rst:12 -#: ../source/guides/supporting-windows-using-appveyor.rst:15 -#: ../source/overview.rst:23 ../source/specifications/core-metadata.rst:38 -#: ../source/specifications/direct-url.rst:14 -#: ../source/tutorials/installing-packages.rst:23 -msgid "Contents" -msgstr "内容" - -#: ../source/discussions/deploying-python-applications.rst:14 -msgid "Overview" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:18 -msgid "Supporting multiple hardware platforms" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:40 -msgid "OS packaging & installers" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:52 -msgid "Windows" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:61 -msgid "Pynsist" -msgstr "Pynsist" - -#: ../source/discussions/deploying-python-applications.rst:63 -msgid "" -"`Pynsist `__ is a tool that bundles Python " -"programs together with the Python-interpreter into a single installer based " -"on NSIS. In most cases, packaging only requires the user to choose a version " -"of the Python-interpreter and declare the dependencies of the program. The " -"tool downloads the specified Python-interpreter for Windows and packages it " -"with all the dependencies in a single Windows-executable installer." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:70 -msgid "" -"The installed program can be started from a shortcut that the installer adds " -"to the start-menu. It uses a Python interpreter installed within its " -"application directory, independent of any other Python installation on the " -"computer." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:74 -msgid "" -"A big advantage of Pynsist is that the Windows packages can be built on " -"Linux. There are several examples for different kinds of programs (console, " -"GUI) in the `documentation `__. The tool is " -"released under the MIT-licence." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:80 -msgid "Application bundles" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:91 -msgid "Configuration management" -msgstr "" - -#: ../source/discussions/index.rst:4 -msgid "" -"**Discussions** are focused on providing comprehensive information about a " -"specific topic. If you're just trying to get stuff done, see :doc:`/guides/" -"index`." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:5 -msgid "install_requires vs requirements files" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:12 -#: ../source/guides/distributing-packages-using-setuptools.rst:382 -msgid "install_requires" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:14 -msgid "" -"``install_requires`` is a :ref:`setuptools` :file:`setup.py` keyword that " -"should be used to specify what a project **minimally** needs to run " -"correctly. When the project is installed by :ref:`pip`, this is the " -"specification that is used to install its dependencies." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:19 -msgid "" -"For example, if the project requires A and B, your ``install_requires`` " -"would be like so:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:29 -msgid "" -"Additionally, it's best practice to indicate any known lower or upper bounds." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:31 -msgid "" -"For example, it may be known, that your project requires at least v1 of 'A', " -"and v2 of 'B', so it would be like so:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:41 -msgid "" -"It may also be known that project A follows semantic versioning, and that v2 " -"of 'A' will indicate a break in compatibility, so it makes sense to not " -"allow v2:" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:51 -msgid "" -"It is not considered best practice to use ``install_requires`` to pin " -"dependencies to specific versions, or to specify sub-dependencies (i.e. " -"dependencies of your dependencies). This is overly-restrictive, and " -"prevents the user from gaining the benefit of dependency upgrades." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:56 -msgid "" -"Lastly, it's important to understand that ``install_requires`` is a listing " -"of \"Abstract\" requirements, i.e just names and version restrictions that " -"don't determine where the dependencies will be fulfilled from (i.e. from " -"what index or source). The where (i.e. how they are to be made \"Concrete" -"\") is to be determined at install time using :ref:`pip` options. [1]_" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:64 -#: ../source/tutorials/installing-packages.rst:460 -msgid "Requirements files" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:66 -msgid "" -":ref:`Requirements Files ` described most simply, " -"are just a list of :ref:`pip:pip install` arguments placed into a file." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:69 -msgid "" -"Whereas ``install_requires`` defines the dependencies for a single project, :" -"ref:`Requirements Files ` are often used to define " -"the requirements for a complete Python environment." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:73 -msgid "" -"Whereas ``install_requires`` requirements are minimal, requirements files " -"often contain an exhaustive listing of pinned versions for the purpose of " -"achieving :ref:`repeatable installations ` of a complete " -"environment." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:78 -msgid "" -"Whereas ``install_requires`` requirements are \"Abstract\", i.e. not " -"associated with any particular index, requirements files often contain pip " -"options like ``--index-url`` or ``--find-links`` to make requirements " -"\"Concrete\", i.e. associated with a particular index or directory of " -"packages. [1]_" -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:84 -msgid "" -"Whereas ``install_requires`` metadata is automatically analyzed by pip " -"during an install, requirements files are not, and only are used when a user " -"specifically installs them using ``python -m pip install -r``." -msgstr "" - -#: ../source/discussions/install-requires-vs-requirements.rst:90 -msgid "" -"For more on \"Abstract\" vs \"Concrete\" requirements, see https://caremad." -"io/2013/07/setup-vs-requirement/." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:6 -msgid "pip vs easy_install" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:9 -msgid "" -":ref:`easy_install `, now `deprecated`_, was released in 2004 " -"as part of :ref:`setuptools`. It was notable at the time for installing :" -"term:`packages ` from :term:`PyPI ` using requirement specifiers, and automatically installing " -"dependencies." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:14 -msgid "" -":ref:`pip` came later in 2008, as alternative to :ref:`easy_install " -"`, although still largely built on top of :ref:`setuptools` " -"components. It was notable at the time for *not* installing packages as :" -"term:`Eggs ` or from :term:`Eggs ` (but rather simply as 'flat' " -"packages from :term:`sdists `), and " -"introducing the idea of :ref:`Requirements Files `, " -"which gave users the power to easily replicate environments." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:22 -msgid "" -"Here's a breakdown of the important differences between pip and the " -"deprecated easy_install:" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**pip**" -msgstr "**pip**" - -#: ../source/discussions/pip-vs-easy-install.rst:25 -msgid "**easy_install**" -msgstr "**easy_install**" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -msgid "Installs from :term:`Wheels `" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Yes" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:27 -#: ../source/discussions/pip-vs-easy-install.rst:30 -#: ../source/discussions/pip-vs-easy-install.rst:32 -#: ../source/discussions/pip-vs-easy-install.rst:35 -#: ../source/discussions/pip-vs-easy-install.rst:38 -#: ../source/discussions/pip-vs-easy-install.rst:44 -#: ../source/discussions/pip-vs-easy-install.rst:48 -#: ../source/discussions/pip-vs-easy-install.rst:51 -#: ../source/discussions/pip-vs-easy-install.rst:54 -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "No" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Uninstall Packages" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:30 -msgid "Yes (``python -m pip uninstall``)" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Dependency Overrides" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:32 -msgid "Yes (:ref:`Requirements Files `)" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "List Installed Packages" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:35 -msgid "Yes (``python -m pip list`` and ``python -m pip freeze``)" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:38 -msgid ":pep:`438` Support" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Installation format" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "'Flat' packages with :file:`egg-info` metadata." -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:41 -msgid "Encapsulated Egg format" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:44 -msgid "sys.path modification" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:48 -msgid "Installs from :term:`Eggs `" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "`pylauncher support`_" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:51 -msgid "Yes [1]_" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:54 -msgid ":ref:`Multi-version Installs`" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:57 -msgid "Exclude scripts during install" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "per project index" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Only in virtualenv" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:60 -msgid "Yes, via setup.cfg" -msgstr "" - -#: ../source/discussions/pip-vs-easy-install.rst:68 -msgid "" -"https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-" -"launcher" -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:5 -msgid "Wheel vs Egg" -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:7 -msgid "" -":term:`Wheel` and :term:`Egg` are both packaging formats that aim to support " -"the use case of needing an install artifact that doesn't require building or " -"compilation, which can be costly in testing and production workflows." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:11 -msgid "" -"The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas " -"the :term:`Wheel` format was introduced by :pep:`427` in 2012." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:14 -msgid "" -":term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:17 -msgid "" -"Here's a breakdown of the important differences between :term:`Wheel` and :" -"term:`Egg`." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:20 -msgid ":term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:22 -msgid "" -":term:`Wheel` is a :term:`distribution ` format, i.e a " -"packaging format. [1]_ :term:`Egg` was both a distribution format and a " -"runtime installation format (if left zipped), and was designed to be " -"importable." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:26 -msgid "" -":term:`Wheel` archives do not include .pyc files. Therefore, when the " -"distribution only contains Python files (i.e. no compiled extensions), and " -"is compatible with Python 2 and 3, it's possible for a wheel to be " -"\"universal\", similar to an :term:`sdist `." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:31 -msgid "" -":term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info`` directories. " -"Egg used ``.egg-info``." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:34 -msgid "" -":term:`Wheel` has a :pep:`richer file naming convention <425>`. A single " -"wheel archive can indicate its compatibility with a number of Python " -"language versions and implementations, ABIs, and system architectures." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:38 -msgid "" -":term:`Wheel` is versioned. Every wheel file contains the version of the " -"wheel specification and the implementation that packaged it." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:41 -msgid "" -":term:`Wheel` is internally organized by `sysconfig path type `_, therefore making " -"it easier to convert to other formats." -msgstr "" - -#: ../source/discussions/wheel-vs-egg.rst:47 -msgid "" -"Circumstantially, in some cases, wheels can be used as an importable runtime " -"format, although :pep:`this is not officially supported at this time <427#is-" -"it-possible-to-import-python-code-directly-from-a-wheel-file>`." -msgstr "" - -#: ../source/glossary.rst:3 -msgid "Glossary" -msgstr "" - -#: ../source/glossary.rst:8 -msgid "Binary Distribution" -msgstr "" - -#: ../source/glossary.rst:11 -msgid "" -"A specific kind of :term:`Built Distribution` that contains compiled " -"extensions." -msgstr "" - -#: ../source/glossary.rst:14 -msgid "Built Distribution" -msgstr "" - -#: ../source/glossary.rst:17 -msgid "" -"A :term:`Distribution ` format containing files and " -"metadata that only need to be moved to the correct location on the target " -"system, to be installed. :term:`Wheel` is such a format, whereas distutil's :" -"term:`Source Distribution ` is not, in " -"that it requires a build step before it can be installed. This format does " -"not imply that Python files have to be precompiled (:term:`Wheel` " -"intentionally does not include compiled Python files)." -msgstr "" - -#: ../source/glossary.rst:26 -msgid "Distribution Package" -msgstr "" - -#: ../source/glossary.rst:29 -msgid "" -"A versioned archive file that contains Python :term:`packages `, :term:`modules `, and other resource files that are used " -"to distribute a :term:`Release`. The archive file is what an end-user will " -"download from the internet and install." -msgstr "" - -#: ../source/glossary.rst:34 -msgid "" -"A distribution package is more commonly referred to with the single words " -"\"package\" or \"distribution\", but this guide may use the expanded term " -"when more clarity is needed to prevent confusion with an :term:`Import " -"Package` (which is also commonly called a \"package\") or another kind of " -"distribution (e.g. a Linux distribution or the Python language " -"distribution), which are often referred to with the single term " -"\"distribution\"." -msgstr "" - -#: ../source/glossary.rst:41 -msgid "Egg" -msgstr "" - -#: ../source/glossary.rst:44 -msgid "" -"A :term:`Built Distribution` format introduced by :ref:`setuptools`, which " -"is being replaced by :term:`Wheel`. For details, see `The Internal " -"Structure of Python Eggs `_ and `Python Eggs `_" -msgstr "" - -#: ../source/glossary.rst:49 -msgid "Extension Module" -msgstr "" - -#: ../source/glossary.rst:52 -msgid "" -"A :term:`Module` written in the low-level language of the Python " -"implementation: C/C++ for Python, Java for Jython. Typically contained in a " -"single dynamically loadable pre-compiled file, e.g. a shared object (.so) " -"file for Python extensions on Unix, a DLL (given the .pyd extension) for " -"Python extensions on Windows, or a Java class file for Jython extensions." -msgstr "" - -#: ../source/glossary.rst:59 -msgid "Known Good Set (KGS)" -msgstr "" - -#: ../source/glossary.rst:62 -msgid "" -"A set of distributions at specified versions which are compatible with each " -"other. Typically a test suite will be run which passes all tests before a " -"specific set of packages is declared a known good set. This term is commonly " -"used by frameworks and toolkits which are comprised of multiple individual " -"distributions." -msgstr "" - -#: ../source/glossary.rst:68 -msgid "Import Package" -msgstr "" - -#: ../source/glossary.rst:71 -msgid "" -"A Python module which can contain other modules or recursively, other " -"packages." -msgstr "" - -#: ../source/glossary.rst:74 -msgid "" -"An import package is more commonly referred to with the single word \"package" -"\", but this guide will use the expanded term when more clarity is needed to " -"prevent confusion with a :term:`Distribution Package` which is also commonly " -"called a \"package\"." -msgstr "" - -#: ../source/glossary.rst:78 -msgid "Module" -msgstr "" - -#: ../source/glossary.rst:81 -msgid "" -"The basic unit of code reusability in Python, existing in one of two types: :" -"term:`Pure Module`, or :term:`Extension Module`." -msgstr "" - -#: ../source/glossary.rst:84 -msgid "Package Index" -msgstr "" - -#: ../source/glossary.rst:87 -msgid "" -"A repository of distributions with a web interface to automate :term:" -"`package ` discovery and consumption." -msgstr "" - -#: ../source/glossary.rst:90 -msgid "Per Project Index" -msgstr "" - -#: ../source/glossary.rst:93 -msgid "" -"A private or other non-canonical :term:`Package Index` indicated by a " -"specific :term:`Project` as the index preferred or required to resolve " -"dependencies of that project." -msgstr "" - -#: ../source/glossary.rst:97 -msgid "Project" -msgstr "" - -#: ../source/glossary.rst:100 -msgid "" -"A library, framework, script, plugin, application, or collection of data or " -"other resources, or some combination thereof that is intended to be packaged " -"into a :term:`Distribution `." -msgstr "" - -#: ../source/glossary.rst:104 -msgid "" -"Since most projects create :term:`Distributions ` " -"using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:" -"`setuptools`, another practical way to define projects currently is " -"something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:" -"`setup.cfg` file at the root of the project source directory." -msgstr "" - -#: ../source/glossary.rst:110 -msgid "" -"Python projects must have unique names, which are registered on :term:`PyPI " -"`. Each project will then contain one or more :" -"term:`Releases `, and each release may comprise one or more :term:" -"`distributions `." -msgstr "" - -#: ../source/glossary.rst:115 -msgid "" -"Note that there is a strong convention to name a project after the name of " -"the package that is imported to run that project. However, this doesn't have " -"to hold true. It's possible to install a distribution from the project 'foo' " -"and have it provide a package importable only as 'bar'." -msgstr "" - -#: ../source/glossary.rst:121 -msgid "Pure Module" -msgstr "" - -#: ../source/glossary.rst:124 -msgid "" -"A :term:`Module` written in Python and contained in a single ``.py`` file " -"(and possibly associated ``.pyc`` and/or ``.pyo`` files)." -msgstr "" - -#: ../source/glossary.rst:127 -msgid "Python Packaging Authority (PyPA)" -msgstr "" - -#: ../source/glossary.rst:130 -msgid "" -"PyPA is a working group that maintains many of the relevant projects in " -"Python packaging. They maintain a site at https://www.pypa.io, host projects " -"on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python " -"Discourse forum `__." -msgstr "" - -#: ../source/glossary.rst:139 -msgid "Python Package Index (PyPI)" -msgstr "" - -#: ../source/glossary.rst:142 -msgid "" -"`PyPI `_ is the default :term:`Package Index` for the " -"Python community. It is open to all Python developers to consume and " -"distribute their distributions." -msgstr "" - -#: ../source/glossary.rst:145 -msgid "pypi.org" -msgstr "" - -#: ../source/glossary.rst:148 -msgid "" -"`pypi.org `_ is the domain name for the :term:`Python " -"Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi." -"python.org``, in 2017. It is powered by :ref:`warehouse`." -msgstr "" - -#: ../source/glossary.rst:152 -msgid "pyproject.toml" -msgstr "" - -#: ../source/glossary.rst:155 -msgid "" -"The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." -msgstr "" - -#: ../source/glossary.rst:157 -msgid "Release" -msgstr "" - -#: ../source/glossary.rst:160 -msgid "" -"A snapshot of a :term:`Project` at a particular point in time, denoted by a " -"version identifier." -msgstr "" - -#: ../source/glossary.rst:163 -msgid "" -"Making a release may entail the publishing of multiple :term:`Distributions " -"`. For example, if version 1.0 of a project was " -"released, it could be available in both a source distribution format and a " -"Windows installer distribution format." -msgstr "" - -#: ../source/glossary.rst:168 -msgid "Requirement" -msgstr "" - -#: ../source/glossary.rst:171 -msgid "" -"A specification for a :term:`package ` to be " -"installed. :ref:`pip`, the :term:`PYPA ` " -"recommended installer, allows various forms of specification that can all be " -"considered a \"requirement\". For more information, see the :ref:`pip:pip " -"install` reference." -msgstr "" - -#: ../source/glossary.rst:177 -msgid "Requirement Specifier" -msgstr "" - -#: ../source/glossary.rst:180 -msgid "" -"A format used by :ref:`pip` to install packages from a :term:`Package " -"Index`. For an EBNF diagram of the format, see the `pkg_resources." -"Requirement `_ entry in the :ref:`setuptools` docs. For " -"example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the " -"project name, and the \">=1.3\" portion is the :term:`Version Specifier`" -msgstr "" - -#: ../source/glossary.rst:187 -msgid "Requirements File" -msgstr "" - -#: ../source/glossary.rst:190 -msgid "" -"A file containing a list of :term:`Requirements ` that can be " -"installed using :ref:`pip`. For more information, see the :ref:`pip` docs " -"on :ref:`pip:Requirements Files`." -msgstr "" - -#: ../source/glossary.rst:194 -#: ../source/guides/distributing-packages-using-setuptools.rst:56 -msgid "setup.py" -msgstr "" - -#: ../source/glossary.rst:195 -#: ../source/guides/distributing-packages-using-setuptools.rst:77 -msgid "setup.cfg" -msgstr "" - -#: ../source/glossary.rst:198 -msgid "" -"The project specification files for :ref:`distutils` and :ref:`setuptools`. " -"See also :term:`pyproject.toml`." -msgstr "" - -#: ../source/glossary.rst:201 -msgid "Source Archive" -msgstr "" - -#: ../source/glossary.rst:204 -msgid "" -"An archive containing the raw source code for a :term:`Release`, prior to " -"creation of a :term:`Source Distribution ` or :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:208 -msgid "Source Distribution (or \"sdist\")" -msgstr "" - -#: ../source/glossary.rst:211 -msgid "" -"A :term:`distribution ` format (usually generated " -"using ``python setup.py sdist``) that provides metadata and the essential " -"source files needed for installing by a tool like :ref:`pip`, or for " -"generating a :term:`Built Distribution`." -msgstr "" - -#: ../source/glossary.rst:216 -msgid "System Package" -msgstr "" - -#: ../source/glossary.rst:219 -msgid "" -"A package provided in a format native to the operating system, e.g. an rpm " -"or dpkg file." -msgstr "" - -#: ../source/glossary.rst:222 -msgid "Version Specifier" -msgstr "" - -#: ../source/glossary.rst:225 -msgid "" -"The version component of a :term:`Requirement Specifier`. For example, the " -"\">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full " -"specification <440#version-specifiers>` of the specifiers that Python " -"packaging currently supports. Support for PEP440 was implemented in :ref:" -"`setuptools` v8.0 and :ref:`pip` v6.0." -msgstr "" - -#: ../source/glossary.rst:231 -msgid "Virtual Environment" -msgstr "" - -#: ../source/glossary.rst:234 -msgid "" -"An isolated Python environment that allows packages to be installed for use " -"by a particular application, rather than being installed system wide. For " -"more information, see the section on :ref:`Creating and using Virtual " -"Environments`." -msgstr "" - -#: ../source/glossary.rst:238 -msgid "Wheel" -msgstr "" - -#: ../source/glossary.rst:241 -msgid "" -"A :term:`Built Distribution` format introduced by :pep:`427`, which is " -"intended to replace the :term:`Egg` format. Wheel is currently supported " -"by :ref:`pip`." -msgstr "" - -#: ../source/glossary.rst:244 -msgid "Working Set" -msgstr "" - -#: ../source/glossary.rst:247 -msgid "" -"A collection of :term:`distributions ` available for " -"importing. These are the distributions that are on the `sys.path` variable. " -"At most, one :term:`Distribution ` for a project is " -"possible in a working set." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:3 -msgid "Analyzing PyPI package downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:5 -msgid "" -"This section covers how to use the public PyPI download statistics dataset " -"to learn more about downloads of a package (or packages) hosted on PyPI. For " -"example, you can use it to discover the distribution of Python versions used " -"to download a package." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:15 -#: ../source/guides/supporting-windows-using-appveyor.rst:18 -msgid "Background" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:17 -msgid "PyPI does not display download statistics for a number of reasons: [#]_" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:19 -msgid "" -"**Inefficient to make work with a Content Distribution Network (CDN):** " -"Download statistics change constantly. Including them in project pages, " -"which are heavily cached, would require invalidating the cache more often, " -"and reduce the overall effectiveness of the cache." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:24 -msgid "" -"**Highly inaccurate:** A number of things prevent the download counts from " -"being accurate, some of which include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:27 -msgid "``pip``'s download cache (lowers download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:28 -msgid "" -"Internal or unofficial mirrors (can both raise or lower download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:29 -msgid "Packages not hosted on PyPI (for comparisons sake)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:30 -msgid "" -"Unofficial scripts or attempts at download count inflation (raises download " -"counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:32 -msgid "Known historical data quality issues (lowers download counts)" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:34 -msgid "" -"**Not particularly useful:** Just because a project has been downloaded a " -"lot doesn't mean it's good; Similarly just because a project hasn't been " -"downloaded a lot doesn't mean it's bad!" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:38 -msgid "" -"In short, because it's value is low for various reasons, and the tradeoffs " -"required to make it work are high, it has been not an effective use of " -"limited resources." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:43 -msgid "Public dataset" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:45 -msgid "" -"As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, " -"where they are stored as a public dataset." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:50 -msgid "Getting set up" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:52 -msgid "" -"In order to use `Google BigQuery`_ to query the `public PyPI download " -"statistics dataset`_, you'll need a Google account and to enable the " -"BigQuery API on a Google Cloud Platform project. You can run the up to 1TB " -"of queries per month `using the BigQuery free tier without a credit card " -"`__" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:58 -msgid "Navigate to the `BigQuery web UI`_." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:59 -msgid "Create a new project." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:60 -msgid "" -"Enable the `BigQuery API `__." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:63 -msgid "" -"For more detailed instructions on how to get started with BigQuery, check " -"out the `BigQuery quickstart guide `__." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:69 -msgid "Data schema" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:71 -msgid "" -"Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` " -"table for each download. The table contains information about what file was " -"downloaded and how it was downloaded. Some useful columns from the `table " -"schema `__ include:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -msgid "Column" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/guides/using-manifest-in.rst:67 -#: ../source/specifications/core-metadata.rst:185 -msgid "Description" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:78 -#: ../source/specifications/direct-url.rst:226 -msgid "Examples" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "timestamp" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "Date and time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:80 -msgid "``2020-03-09 00:33:03 UTC``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "file.project" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "Project name" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:82 -msgid "``pipenv``, ``nose``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "file.version" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "Package version" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:84 -msgid "``0.1.6``, ``1.4.2``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "details.installer.name" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "Installer" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:86 -msgid "pip, `bandersnatch`_" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "details.python" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "Python version" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:88 -msgid "``2.7.12``, ``3.6.4``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:93 -msgid "Useful queries" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:95 -msgid "" -"Run queries in the `BigQuery web UI`_ by clicking the \"Compose query\" " -"button." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:97 -msgid "" -"Note that the rows are stored in a partitioned, which helps limit the cost " -"of queries. These example queries analyze downloads from recent history by " -"filtering on the ``timestamp`` column." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:102 -msgid "Counting package downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:104 -msgid "" -"The following query counts the total number of downloads for the project " -"\"pytest\"." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:119 -#: ../source/guides/analyzing-pypi-package-downloads.rst:140 -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "num_downloads" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:121 -msgid "26190085" -msgstr "26190085" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:124 -msgid "" -"To only count downloads from pip, filter on the ``details.installer.name`` " -"column." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:142 -msgid "24334215" -msgstr "24334215" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:146 -msgid "Package downloads over time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:148 -msgid "" -"To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also " -"filtering by this column reduces corresponding costs." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:168 -msgid "month" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "1956741" -msgstr "1956741" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:170 -msgid "2018-01-01" -msgstr "2018-01-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2344692" -msgstr "2344692" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:172 -msgid "2017-12-01" -msgstr "2017-12-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "1730398" -msgstr "1730398" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:174 -msgid "2017-11-01" -msgstr "2017-11-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2047310" -msgstr "2047310" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:176 -msgid "2017-10-01" -msgstr "2017-10-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "1744443" -msgstr "1744443" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:178 -msgid "2017-09-01" -msgstr "2017-09-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "1916952" -msgstr "1916952" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:180 -msgid "2017-08-01" -msgstr "2017-08-01" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:184 -msgid "Python versions over time" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:186 -msgid "" -"Extract the Python version from the ``details.python`` column. Warning: This " -"query processes over 500 GB of data." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:205 -msgid "python" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "3.7" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:207 -msgid "18051328726" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "3.6" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:209 -msgid "9635067203" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "3.8" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:211 -msgid "7781904681" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "2.7" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:213 -msgid "6381252241" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "null" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:215 -msgid "2026630299" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "3.5" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:217 -msgid "1894153540" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:221 -msgid "Caveats" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:223 -msgid "" -"In addition to the caveats listed in the background above, Linehaul suffered " -"from a bug which caused it to significantly under-report download statistics " -"prior to July 26, 2018. Downloads before this date are proportionally " -"accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total " -"numbers are lower than actual by an order of magnitude." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:231 -msgid "Additional tools" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:233 -msgid "" -"Besides using the BigQuery console, there are some additional tools which " -"may be useful when analyzing download statistics." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:237 -msgid "``google-cloud-bigquery``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:239 -msgid "" -"You can also access the public PyPI download statistics dataset " -"programmatically via the BigQuery API and the `google-cloud-bigquery`_ " -"project, the official Python client library for BigQuery." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:267 -msgid "``pypinfo``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:269 -msgid "" -"`pypinfo`_ is a command-line tool which provides access to the dataset and " -"can generate several useful queries. For example, you can query the total " -"number of download for a package with the command ``pypinfo package_name``." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:273 -msgid "Install `pypinfo`_ using pip." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:279 -msgid "Usage:" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:295 -msgid "``pandas-gbq``" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:297 -msgid "" -"The `pandas-gbq`_ project allows for accessing query results via `Pandas`_." -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:301 -#: ../source/specifications/binary-distribution-format.rst:459 -msgid "References" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:303 -msgid "" -"`PyPI Download Counts deprecation email `__" -msgstr "" - -#: ../source/guides/analyzing-pypi-package-downloads.rst:304 -msgid "" -"`PyPI BigQuery dataset announcement email `__" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:3 -msgid "Creating and discovering plugins" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:5 -msgid "" -"Often when creating a Python application or library you'll want the ability " -"to provide customizations or extra features via **plugins**. Because Python " -"packages can be separately distributed, your application or library may want " -"to automatically **discover** all of the plugins available." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:10 -msgid "There are three major approaches to doing automatic plugin discovery:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:12 -msgid "`Using naming convention`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:13 -msgid "`Using namespace packages`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:14 -msgid "`Using package metadata`_." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:18 -msgid "Using naming convention" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:20 -msgid "" -"If all of the plugins for your application follow the same naming " -"convention, you can use :func:`pkgutil.iter_modules` to discover all of the " -"top-level modules that match the naming convention. For example, `Flask`_ " -"uses the naming convention ``flask_{plugin_name}``. If you wanted to " -"automatically discover all of the Flask plugins installed:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:38 -msgid "" -"If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins " -"installed then ``discovered_plugins`` would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:48 -msgid "" -"Using naming convention for plugins also allows you to query the Python " -"Package Index's `simple API`_ for all packages that conform to your naming " -"convention." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:59 -msgid "Using namespace packages" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:61 -msgid "" -":doc:`Namespace packages ` can be used to " -"provide a convention for where to place plugins and also provides a way to " -"perform discovery. For example, if you make the sub-package ``myapp." -"plugins`` a namespace package then other :term:`distributions ` can provide modules and packages to that namespace. Once " -"installed, you can use :func:`pkgutil.iter_modules` to discover all modules " -"and packages installed under that namespace:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:89 -msgid "" -"Specifying ``myapp.plugins.__path__`` to :func:`~pkgutil.iter_modules` " -"causes it to only look for the modules directly under that namespace. For " -"example, if you have installed distributions that provide the modules " -"``myapp.plugins.a`` and ``myapp.plugins.b`` then ``discovered_plugins`` in " -"this case would be:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:101 -msgid "" -"This sample uses a sub-package as the namespace package (``myapp.plugins``), " -"but it's also possible to use a top-level package for this purpose (such as " -"``myapp_plugins``). How to pick the namespace to use is a matter of " -"preference, but it's not recommended to make your project's main top-level " -"package (``myapp`` in this case) a namespace package for the purpose of " -"plugins, as one bad plugin could cause the entire namespace to break which " -"would in turn make your project unimportable. For the \"namespace sub-package" -"\" approach to work, the plugin packages must omit the :file:`__init__.py` " -"for your top-level package directory (``myapp`` in this case) and include " -"the namespace-package style :file:`__init__.py` in the namespace sub-package " -"directory (``myapp/plugins``). This also means that plugins will need to " -"explicitly pass a list of packages to :func:`setup`'s ``packages`` argument " -"instead of using :func:`setuptools.find_packages`." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:115 -msgid "" -"Namespace packages are a complex feature and there are several different " -"ways to create them. It's highly recommended to read the :doc:`packaging-" -"namespace-packages` documentation and clearly document which approach is " -"preferred for plugins to your project." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:121 -msgid "Using package metadata" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:123 -msgid "" -"`Setuptools`_ provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :" -"func:`setup` in :file:`setup.py` plugins can register themselves for " -"discovery." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:128 -msgid "" -"For example if you have a package named ``myapp-plugin-a`` and it includes " -"in its :file:`setup.py`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:139 -msgid "" -"Then you can discover and load all of the registered entry points by using :" -"func:`importlib.metadata.entry_points` (or the `backport`_ " -"``importlib_metadata >= 3.6`` for Python 3.6-3.9):" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:154 -msgid "" -"In this example, ``discovered_plugins`` would be a collection of type :class:" -"`importlib.metadata.EntryPoint`:" -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:163 -msgid "" -"Now the module of your choice can be imported by executing " -"``discovered_plugins['a'].load()``." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:166 -msgid "" -"The ``entry_point`` specification in :file:`setup.py` is fairly flexible and " -"has a lot of options. It's recommended to read over the entire section on :" -"doc:`entry points ` ." -msgstr "" - -#: ../source/guides/creating-and-discovering-plugins.rst:170 -msgid "" -"Since this specification is part of the :doc:`standard library `, most packaging tools other than setuptools " -"provide support for defining entry points." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:5 -msgid "Packaging and distributing projects" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:7 -msgid "" -"This section covers the basics of how to configure, package and distribute " -"your own Python projects. It assumes that you are already familiar with the " -"contents of the :doc:`/tutorials/installing-packages` page." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:11 -msgid "" -"The section does *not* aim to cover best practices for Python project " -"development as a whole. For example, it does not provide guidance or tool " -"recommendations for version control, documentation, or testing." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:15 -msgid "" -"For more reference material, see :std:doc:`Building and Distributing " -"Packages ` in the :ref:`setuptools` docs, but note that " -"some advisory content there may be outdated. In the event of conflicts, " -"prefer the advice in the Python Packaging User Guide." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:25 -msgid "Requirements for packaging and distributing" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:26 -msgid "" -"First, make sure you have already fulfilled the :ref:`requirements for " -"installing packages `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:29 -msgid "Install \"twine\" [1]_:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:43 -msgid "" -"You'll need this to upload your project :term:`distributions ` to :term:`PyPI ` (see :ref:`below " -"`)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:49 -msgid "Configuring your project" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:53 -msgid "Initial files" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:58 -msgid "" -"The most important file is :file:`setup.py` which exists at the root of your " -"project directory. For an example, see the `setup.py `_ in the `PyPA sample project " -"`_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:63 -msgid ":file:`setup.py` serves two primary functions:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:65 -msgid "" -"It's the file where various aspects of your project are configured. The " -"primary feature of :file:`setup.py` is that it contains a global ``setup()`` " -"function. The keyword arguments to this function are how specific details " -"of your project are defined. The most relevant arguments are explained in :" -"ref:`the section below `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:71 -msgid "" -"It's the command line interface for running various commands that relate to " -"packaging tasks. To get a listing of available commands, run ``python setup." -"py --help-commands``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:79 -msgid "" -":file:`setup.cfg` is an ini file that contains option defaults for :file:" -"`setup.py` commands. For an example, see the `setup.cfg `_ in the `PyPA sample project " -"`_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:86 -msgid "README.rst / README.md" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:88 -msgid "" -"All projects should contain a readme file that covers the goal of the " -"project. The most common format is `reStructuredText `_ with an \"rst\" extension, although this is not " -"a requirement; multiple variants of `Markdown `_ are supported as well (look at ``setup()``'s :ref:" -"`long_description_content_type ` argument)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:95 -msgid "" -"For an example, see `README.md `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:99 -msgid "" -"Projects using :ref:`setuptools` 0.6.27+ have standard readme files (:file:" -"`README.rst`, :file:`README.txt`, or :file:`README`) included in source " -"distributions by default. The built-in :ref:`distutils` library adopts this " -"behavior beginning in Python 3.7. Additionally, :ref:`setuptools` 36.4.0+ " -"will include a :file:`README.md` if found. If you are using setuptools, you " -"don't need to list your readme file in :file:`MANIFEST.in`. Otherwise, " -"include it to be explicit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:108 -msgid "MANIFEST.in" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:110 -msgid "" -"A :file:`MANIFEST.in` is needed when you need to package additional files " -"that are not automatically included in a source distribution. For details " -"on writing a :file:`MANIFEST.in` file, including a list of what's included " -"by default, see \":ref:`Using MANIFEST.in`\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:115 -msgid "" -"For an example, see the `MANIFEST.in `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:119 -msgid "" -":file:`MANIFEST.in` does not affect binary distributions such as wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:122 -msgid "LICENSE.txt" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:124 -msgid "" -"Every package should include a license file detailing the terms of " -"distribution. In many jurisdictions, packages without an explicit license " -"can not be legally used or distributed by anyone other than the copyright " -"holder. If you're unsure which license to choose, you can use resources such " -"as `GitHub's Choose a License `_ or consult a " -"lawyer." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:130 -msgid "" -"For an example, see the `LICENSE.txt `_ from the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:135 -msgid "" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:137 -msgid "" -"Although it's not required, the most common practice is to include your " -"Python modules and packages under a single top-level package that has the " -"same :ref:`name ` as your project, or something very close." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:141 -msgid "" -"For an example, see the `sample `_ package that's included in the `PyPA sample project " -"`_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:149 -msgid "setup() args" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:151 -msgid "" -"As mentioned above, the primary feature of :file:`setup.py` is that it " -"contains a global ``setup()`` function. The keyword arguments to this " -"function are how specific details of your project are defined." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:155 -msgid "" -"The most relevant arguments are explained below. Most of the snippets given " -"are taken from the `setup.py `_ contained in the `PyPA sample project `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:164 -msgid "name" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:170 -msgid "" -"This is the name of your project, determining how your project is listed on :" -"term:`PyPI `. Per :pep:`508`, valid project " -"names must:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:174 -msgid "" -"Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``), " -"and/or periods (``.``), and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:176 -msgid "Start & end with an ASCII letter or digit." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:178 -msgid "" -"Comparison of project names is case insensitive and treats arbitrarily-long " -"runs of underscores, hyphens, and/or periods as equal. For example, if you " -"register a project named ``cool-stuff``, users will be able to download it " -"or declare a dependency on it using any of the following spellings::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:190 -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "version" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:196 -msgid "" -"This is the current version of your project, allowing your users to " -"determine whether or not they have the latest version, and to indicate which " -"specific versions they've tested their own software against." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:200 -msgid "" -"Versions are displayed on :term:`PyPI ` for " -"each release if you publish your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:203 -msgid "" -"See :ref:`Choosing a versioning scheme` for more information on ways to use " -"versions to convey compatibility information to your users." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:206 -msgid "" -"If the project code itself needs run-time access to the version, the " -"simplest way is to keep the version in both :file:`setup.py` and your code. " -"If you'd rather not duplicate the value, there are a few ways to manage " -"this. See the \":ref:`Single sourcing the version`\" Advanced Topics section." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:214 -msgid "description" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:222 -msgid "Give a short and long description for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:224 -msgid "" -"These values will be displayed on :term:`PyPI ` " -"if you publish your project. On ``pypi.org``, the user interface displays " -"``description`` in the grey banner and ``long_description`` in the section " -"named \"Project Description\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:229 -msgid "" -"``description`` is also displayed in lists of projects. For example, it's " -"visible in the search results pages such as https://pypi.org/search/?" -"q=jupyter, the front-page lists of trending projects and new releases, and " -"the list of projects you maintain within your account profile (such as " -"https://pypi.org/user/jaraco/)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:235 -msgid "" -"A `content type `_ can be specified with the " -"``long_description_content_type`` argument, which can be one of ``text/" -"plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no " -"formatting, `reStructuredText (reST) `_, and the Github-flavored " -"Markdown dialect of `Markdown `_ respectively." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:245 -msgid "url" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:252 -msgid "Give a homepage URL for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:256 -msgid "author" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:263 -msgid "Provide details about the author." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:267 -msgid "license" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:273 -msgid "" -"The ``license`` argument doesn't have to indicate the license under which " -"your package is being released, although you may optionally do so if you " -"want. If you're using a standard, well-known license, then your main " -"indication can and should be via the ``classifiers`` argument. Classifiers " -"exist for all major open-source licenses." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:279 -msgid "" -"The \"license\" argument is more typically used to indicate differences from " -"well-known licenses, or to include your own, unique license. As a general " -"rule, it's a good idea to use a standard, well-known license, both to avoid " -"confusion and because some organizations avoid software whose license is " -"unapproved." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:287 -msgid "classifiers" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:316 -msgid "" -"Provide a list of classifiers that categorize your project. For a full " -"listing, see https://pypi.org/classifiers/." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:319 -msgid "" -"Although the list of classifiers is often used to declare what Python " -"versions a project supports, this information is only used for searching & " -"browsing projects on PyPI, not for installing projects. To actually " -"restrict what Python versions a project can be installed on, use the :ref:" -"`python_requires` argument." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:327 -msgid "keywords" -msgstr "keywords" - -#: ../source/guides/distributing-packages-using-setuptools.rst:333 -msgid "List keywords that describe your project." -msgstr "列出描述您的項目的關鍵字。" - -#: ../source/guides/distributing-packages-using-setuptools.rst:337 -msgid "project_urls" -msgstr "project_urls" - -#: ../source/guides/distributing-packages-using-setuptools.rst:349 -msgid "" -"List additional relevant URLs about your project. This is the place to link " -"to bug trackers, source repositories, or where to support package " -"development. The string of the key is the exact text that will be displayed " -"on PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:355 -msgid "packages" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:361 -msgid "" -"Set ``packages`` to a list of all :term:`packages ` in your " -"project, including their subpackages, sub-subpackages, etc. Although the " -"packages can be listed manually, ``setuptools.find_packages()`` finds them " -"automatically. Use the ``include`` keyword argument to find only the given " -"packages. Use the ``exclude`` keyword argument to omit packages that are " -"not intended to be released and installed." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:370 -msgid "py_modules" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:376 -msgid "" -"If your project contains any single-file Python modules that aren't part of " -"a package, set ``py_modules`` to a list of the names of the modules (minus " -"the ``.py`` extension) in order to make :ref:`setuptools` aware of them." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:388 -msgid "" -"\"install_requires\" should be used to specify what dependencies a project " -"minimally needs to run. When the project is installed by :ref:`pip`, this is " -"the specification that is used to install its dependencies." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:392 -msgid "" -"For more on using \"install_requires\" see :ref:`install_requires vs " -"Requirements files`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:398 -msgid "python_requires" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:400 -msgid "" -"If your project only runs on certain Python versions, setting the " -"``python_requires`` argument to the appropriate :pep:`440` version specifier " -"string will prevent :ref:`pip` from installing the project on other Python " -"versions. For example, if your package is for Python 3+ only, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:407 -msgid "" -"If your package is for Python 2.6, 2.7, and all versions of Python 3 " -"starting with 3.3, write::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:412 -msgid "And so on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:416 -msgid "" -"Support for this feature is relatively recent. Your project's source " -"distributions and wheels (see :ref:`Packaging Your Project`) must be built " -"using at least version 24.2.0 of :ref:`setuptools` in order for the " -"``python_requires`` argument to be recognized and the appropriate metadata " -"generated." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:422 -msgid "" -"In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the " -"``python_requires`` metadata. Users with earlier versions of pip will be " -"able to download & install projects on any Python version regardless of the " -"projects' ``python_requires`` values." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:431 -msgid "package_data" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:440 -msgid "" -"Often, additional files need to be installed into a :term:`package `. These files are often data that’s closely related to the " -"package’s implementation, or text files containing documentation that might " -"be of interest to programmers using the package. These files are called " -"\"package data\"." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:445 -msgid "" -"The value must be a mapping from package name to a list of relative path " -"names that should be copied into the package. The paths are interpreted as " -"relative to the directory containing the package." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:449 -msgid "" -"For more information, see :std:doc:`Including Data Files ` from the :std:doc:`setuptools docs `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:457 -msgid "data_files" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:463 -msgid "" -"Although configuring :ref:`Package Data` is sufficient for most needs, in " -"some cases you may need to place data files *outside* of your :term:" -"`packages `. The ``data_files`` directive allows you to do " -"that. It is mostly useful if you need to install files which are used by " -"other programs, which may be unaware of Python packages." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:469 -msgid "" -"Each ``(directory, files)`` pair in the sequence specifies the installation " -"directory and the files to install there. The ``directory`` must be a " -"relative path (although this may change in the future, see `wheel Issue #92 " -"`_). and it is interpreted relative " -"to the installation prefix (Python’s ``sys.prefix`` for a default " -"installation; ``site.USER_BASE`` for a user installation). Each file name in " -"``files`` is interpreted relative to the :file:`setup.py` script at the top " -"of the project source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:479 -msgid "" -"For more information see the distutils section on `Installing Additional " -"Files `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:484 -msgid "" -"When installing packages as egg, ``data_files`` is not supported. So, if " -"your project uses :ref:`setuptools`, you must use ``pip`` to install it. " -"Alternatively, if you must use ``python setup.py``, then you need to pass " -"the ``--old-and-unmanageable`` option." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:491 -msgid "scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:493 -msgid "" -"Although ``setup()`` supports a `scripts `_ keyword for pointing to pre-made " -"scripts to install, the recommended approach to achieve cross-platform " -"compatibility is to use :ref:`console_scripts` entry points (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:500 -msgid "entry_points" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:509 -msgid "" -"Use this keyword to specify any plugins that your project provides for any " -"named entry points that may be defined by your project or others that you " -"depend on." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:512 -msgid "" -"For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:516 -msgid "The most commonly used entry point is \"console_scripts\" (see below)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:521 -msgid "console_scripts" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:531 -msgid "" -"Use \"console_script\" `entry points `_ to " -"register your script interfaces. You can then let the toolchain handle the " -"work of turning these interfaces into actual scripts [2]_. The scripts will " -"be generated during the install of your :term:`distribution `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:538 -msgid "" -"For more information, see `Automatic Script Creation `_ from " -"the `setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:545 -msgid "Choosing a versioning scheme" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:548 -msgid "Standards compliance for interoperability" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:550 -msgid "" -"Different Python projects may use different versioning schemes based on the " -"needs of that particular project, but all of them are required to comply " -"with the flexible :pep:`public version scheme <440#public-version-" -"identifiers>` specified in :pep:`440` in order to be supported in tools and " -"libraries like ``pip`` and ``setuptools``." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:556 -msgid "Here are some examples of compliant version numbers::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:567 -msgid "" -"To further accommodate historical variations in approaches to version " -"numbering, :pep:`440` also defines a comprehensive technique for :pep:" -"`version normalisation <440#normalization>` that maps variant spellings of " -"different version numbers to a standardised canonical form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:573 -msgid "Scheme choices" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:576 -msgid "Semantic versioning (preferred)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:578 -msgid "" -"For new projects, the recommended versioning scheme is based on `Semantic " -"Versioning `_, but adopts a different approach to " -"handling pre-releases and build metadata." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:582 -msgid "" -"The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE " -"numbering scheme, where the project author increments:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:585 -msgid "MAJOR version when they make incompatible API changes," -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:586 -msgid "" -"MINOR version when they add functionality in a backwards-compatible manner, " -"and" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:587 -msgid "MAINTENANCE version when they make backwards-compatible bug fixes." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:589 -msgid "" -"Adopting this approach as a project author allows users to make use of :pep:`" -"\"compatible release\" <440#compatible-release>` specifiers, where ``name ~= " -"X.Y`` requires at least release X.Y, but also allows any later release with " -"a matching MAJOR version." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:594 -msgid "" -"Python projects adopting semantic versioning should abide by clauses 1-8 of " -"the `Semantic Versioning 2.0.0 specification `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:598 -msgid "Date based versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:600 -msgid "" -"Semantic versioning is not a suitable choice for all projects, such as those " -"with a regular time based release cadence and a deprecation process that " -"provides warnings for a number of releases prior to removal of a feature." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:604 -msgid "" -"A key advantage of date based versioning is that it is straightforward to " -"tell how old the base feature set of a particular release is given just the " -"version number." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:607 -msgid "" -"Version numbers for date based projects typically take the form of YEAR." -"MONTH (for example, ``12.04``, ``15.10``)." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:611 -msgid "Serial versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:613 -msgid "" -"This is the simplest possible versioning scheme, and consists of a single " -"number which is incremented every release." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:616 -msgid "" -"While serial versioning is very easy to manage as a developer, it is the " -"hardest to track as an end user, as serial version numbers convey little or " -"no information regarding API backwards compatibility." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:621 -msgid "Hybrid schemes" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:623 -msgid "" -"Combinations of the above schemes are possible. For example, a project may " -"combine date based versioning with serial versioning to create a YEAR.SERIAL " -"numbering scheme that readily conveys the approximate age of a release, but " -"doesn't otherwise commit to a particular release cadence within the year." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:629 -msgid "Pre-release versioning" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:631 -msgid "" -"Regardless of the base versioning scheme, pre-releases for a given final " -"release may be published as:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:634 -msgid "zero or more dev releases (denoted with a \".devN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:635 -msgid "zero or more alpha releases (denoted with a \".aN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:636 -msgid "zero or more beta releases (denoted with a \".bN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:637 -msgid "zero or more release candidates (denoted with a \".rcN\" suffix)" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:639 -msgid "" -"``pip`` and other modern Python package installers ignore pre-releases by " -"default when deciding which versions of dependencies to install." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:644 -msgid "Local version identifiers" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:646 -msgid "" -"Public version identifiers are designed to support distribution via :term:" -"`PyPI `. Python's software distribution tools " -"also support the notion of a :pep:`local version identifier <440#local-" -"version-identifiers>`, which can be used to identify local development " -"builds not intended for publication, or modified variants of a release " -"maintained by a redistributor." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:653 -msgid "" -"A local version identifier takes the form ``" -"+``. For example::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:661 -msgid "Working in \"development mode\"" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:663 -msgid "" -"Although not required, it's common to locally install your project in " -"\"editable\" or \"develop\" mode while you're working on it. This allows " -"your project to be both installed and editable in project form." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:667 -msgid "Assuming you're in the root of your project directory, then run:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:674 -msgid "" -"Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` " -"refers to the current working directory, so together, it means to install " -"the current directory (i.e. your project) in editable mode. This will also " -"install any dependencies declared with \"install_requires\" and any scripts " -"declared with \"console_scripts\". Dependencies will be installed in the " -"usual, non-editable mode." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:680 -msgid "" -"It's fairly common to also want to install some of your dependencies in " -"editable mode as well. For example, supposing your project requires \"foo\" " -"and \"bar\", but you want \"bar\" installed from VCS in editable mode, then " -"you could construct a requirements file like so::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:688 -msgid "" -"The first line says to install your project and any dependencies. The second " -"line overrides the \"bar\" dependency, such that it's fulfilled from VCS, " -"not PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:692 -msgid "" -"If, however, you want \"bar\" installed from a local directory in editable " -"mode, the requirements file should look like this, with the local paths at " -"the top of the file::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:697 -msgid "" -"Otherwise, the dependency will be fulfilled from PyPI, due to the " -"installation order of the requirements file. For more on requirements " -"files, see the :ref:`Requirements File ` section in " -"the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:701 -msgid "" -"Lastly, if you don't want to install any dependencies at all, you can run::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:706 -msgid "" -"For more information, see the `Development Mode `_ section of the " -"`setuptools docs `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:713 -msgid "Packaging your project" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:715 -msgid "" -"To have your project installable from a :term:`Package Index` like :term:" -"`PyPI `, you'll need to create a :term:" -"`Distribution ` (aka \":term:`Package `\") for your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:720 -msgid "" -"Before you can build wheels and sdists for your project, you'll need to " -"install the ``build`` package:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:737 -msgid "Source distributions" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:739 -msgid "" -"Minimally, you should create a :term:`Source Distribution `:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:755 -msgid "" -"A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built " -"Distribution`), and requires a build step when installed by pip. Even if " -"the distribution is pure Python (i.e. contains no extensions), it still " -"involves a build step to build out the installation metadata from :file:" -"`setup.py` and/or :file:`setup.cfg`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:763 -msgid "Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:765 -msgid "" -"You should also create a wheel for your project. A wheel is a :term:`built " -"package ` that can be installed without needing to go " -"through the \"build\" process. Installing wheels is substantially faster for " -"the end user than installing from a source distribution." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:770 -msgid "" -"If your project is pure Python then you'll be creating a :ref:`\"Pure Python " -"Wheel\" (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:773 -msgid "" -"If your project contains compiled extensions, then you'll be creating what's " -"called a :ref:`*Platform Wheel* (see section below) `." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:776 -msgid "" -"If your project also supports Python 2 *and* contains no C extensions, then " -"you should create what's called a *Universal Wheel* by adding the following " -"to your :file:`setup.cfg` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:785 -msgid "" -"Only use this setting if your project does not have any C extensions *and* " -"supports Python 2 and 3." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:792 -msgid "Pure Python Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:794 -msgid "" -"*Pure Python Wheels* contain no compiled extensions, and therefore only " -"require a single Python wheel." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:797 -#: ../source/guides/distributing-packages-using-setuptools.rst:826 -msgid "To build the wheel:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:811 -msgid "" -"The ``wheel`` package will detect that the code is pure Python, and build a " -"wheel that's named such that it's usable on any Python 3 installation. For " -"details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:815 -msgid "" -"If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both " -"files for you; this is useful when you don't need multiple wheels." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:821 -msgid "Platform Wheels" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:823 -msgid "" -"*Platform Wheels* are wheels that are specific to a certain platform like " -"Linux, macOS, or Windows, usually due to containing compiled extensions." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:841 -msgid "" -"The ``wheel`` package will detect that the code is not pure Python, and " -"build a wheel that's named such that it's only usable on the platform that " -"it was built on. For details on the naming of wheel files, see :pep:`425`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:847 -msgid "" -":term:`PyPI ` currently supports uploads of " -"platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. " -"Details of the latter are defined in :pep:`513`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:855 -msgid "Uploading your Project to PyPI" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:857 -msgid "" -"When you ran the command to create your distribution, a new directory ``dist/" -"`` was created under your project's root directory. That's where you'll find " -"your distribution file(s) to upload." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:861 -msgid "" -"These files are only created when you run the command to create your " -"distribution. This means that any time you change the source of your project " -"or the configuration in your :file:`setup.py` file, you will need to rebuild " -"these files again before you can distribute the changes to PyPI." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:866 -msgid "" -"Before releasing on main PyPI repo, you might prefer training with the `PyPI " -"test site `_ which is cleaned on a semi regular " -"basis. See :ref:`using-test-pypi` on how to setup your configuration in " -"order to use it." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:871 -msgid "" -"In other resources you may encounter references to using ``python setup.py " -"register`` and ``python setup.py upload``. These methods of registering and " -"uploading a package are **strongly discouraged** as it may use a plaintext " -"HTTP or unverified HTTPS connection on some Python versions, allowing your " -"username and password to be intercepted during transmission." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:877 -msgid "" -"The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to " -"ensure safety of all users, certain kinds of URLs and directives are " -"forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** " -"trying to upload your distribution, you should check to see if your brief / " -"long descriptions provided in :file:`setup.py` are valid. You can do this " -"by running :std:doc:`twine check ` on your package files::" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:888 -msgid "Create an account" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:890 -msgid "" -"First, you need a :term:`PyPI ` user account. " -"You can create an account `using the form on the PyPI website `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:894 -msgid "" -"Now you'll create a PyPI `API token`_ so you will be able to securely upload " -"your project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:897 -msgid "" -"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " -"token`_; don't limit its scope to a particular project, since you are " -"creating a new project." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:901 -msgid "" -"**Don't close the page until you have copied and saved the token — you won't " -"see that token again.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:904 -msgid "" -"To avoid having to copy and paste the token every time you upload, you can " -"create a :file:`$HOME/.pypirc` file:" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:913 -msgid "**Be aware that this stores your token in plaintext.**" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:915 -#: ../source/guides/migrating-to-pypi-org.rst:70 -#: ../source/guides/migrating-to-pypi-org.rst:109 -#: ../source/guides/using-testpypi.rst:83 -msgid "" -"For more details, see the :ref:`specification ` for :file:`.pypirc`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:921 -msgid "Upload your distributions" -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:923 -msgid "" -"Once you have an account you can upload your distributions to :term:`PyPI " -"` using :ref:`twine`." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:926 -msgid "" -"The process for uploading a release is the same regardless of whether or not " -"the project already exists on PyPI - if it doesn't exist yet, it will be " -"automatically created when the first release is uploaded." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:930 -msgid "" -"For the second and subsequent releases, PyPI only requires that the version " -"number of the new release differ from any previous releases." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:937 -msgid "" -"You can see if your package has successfully uploaded by navigating to the " -"URL ``https://pypi.org/project/`` where ``sampleproject`` is " -"the name of your project that you uploaded. It may take a minute or two for " -"your project to appear on the site." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:944 -#: ../source/tutorials/installing-packages.rst:663 -msgid "" -"Depending on your platform, this may require root or Administrator access. :" -"ref:`pip` is currently considering changing this by `making user installs " -"the default behavior `_." -msgstr "" - -#: ../source/guides/distributing-packages-using-setuptools.rst:950 -msgid "" -"Specifically, the \"console_script\" approach generates ``.exe`` files on " -"Windows, which are necessary because the OS special-cases ``.exe`` files. " -"Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for " -"Windows <397>` allow scripts to be used in many cases, but not all." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:5 -msgid "Dropping support for older Python versions" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:7 -msgid "" -"Dropping support for older Python versions is supported by the standard :ref:" -"`core-metadata` 1.2 specification via a \"Requires-Python\" attribute." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:9 -msgid "" -"Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification " -"by matching the current Python runtime and comparing it with the required " -"version in the package metadata. If they do not match, it will attempt to " -"install the last package distribution that supported that Python runtime." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:12 -msgid "" -"This mechanism can be used to drop support for older Python versions, by " -"amending the \"Requires-Python\" attribute in the package metadata." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:14 -msgid "" -"This guide is specifically for users of :ref:`setuptools`, other packaging " -"tools such as ``flit`` may offer similar functionality but users will need " -"to consult relevant documentation." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:17 -msgid "Requirements" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:19 -msgid "This workflow requires that:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:21 -msgid "The publisher is using the latest version of :ref:`setuptools`," -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:22 -msgid "The latest version of :ref:`twine` is used to upload the package," -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:23 -msgid "" -"The user installing the package has at least Pip 9.0, or a client that " -"supports the Metadata 1.2 specification." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:26 -msgid "Dealing with the universal wheels" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:28 -msgid "" -"Traditionally, projects providing Python code that is semantically " -"compatible with both Python 2 and Python 3, produce :term:`wheels ` " -"that have a ``py2.py3`` tag in their names. When dropping support for Python " -"2, it is important not to forget to change this tag to just ``py3``. It is " -"often configured within :file:`setup.cfg` under the ``[bdist_wheel]`` " -"section by setting ``universal = 1`` if they use setuptools." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:36 -msgid "" -"If you use this method, either remove this option or section, or explicitly " -"set ``universal`` to ``0``:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:48 -msgid "" -"Since it is possible to override the :file:`setup.cfg` settings via CLI " -"flags, make sure that your scripts don't have ``--universal`` in your " -"package creation scripts." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:53 -msgid "Defining the Python version required" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:56 -msgid "1. Download the newest version of Setuptools" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:58 -msgid "" -"Ensure that before you generate source distributions or binary " -"distributions, you update Setuptools and install twine." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:60 -msgid "Steps:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:74 -msgid "`setuptools` version should be above 24.0.0." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:77 -msgid "2. Specify the version ranges for supported Python distributions" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:79 -msgid "" -"You can specify version ranges and exclusion rules, such as at least Python " -"3. Or, Python 2.7, 3.4 and beyond." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:81 -#: ../source/specifications/core-metadata.rst:139 -#: ../source/specifications/core-metadata.rst:463 -#: ../source/specifications/core-metadata.rst:487 -#: ../source/specifications/core-metadata.rst:527 -#: ../source/specifications/core-metadata.rst:550 -#: ../source/specifications/core-metadata.rst:583 -#: ../source/specifications/core-metadata.rst:693 -#: ../source/specifications/core-metadata.rst:722 -msgid "Examples::" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:86 -msgid "" -"The way to set those values is within the call to ``setup`` within your :" -"file:`setup.py` script. This will insert the ``Requires-Python`` metadata " -"values based on the argument you provide in ``python_requires``." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:101 -msgid "3. Validating the Metadata before publishing" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:103 -msgid "" -"Within a Python source package (the zip or the tar-gz file you download) is " -"a text file called PKG-INFO." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:105 -msgid "" -"This file is generated by Distutils or :ref:`setuptools` when it generates " -"the source package. The file contains a set of keys and values, the list of " -"keys is part of the PyPa standard metadata format." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:108 -msgid "You can see the contents of the generated file like this::" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:112 -msgid "Validate that the following is in place, before publishing the package:" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:114 -msgid "" -"If you have upgraded correctly, the Metadata-Version value should be 1.2 or " -"higher." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:115 -msgid "" -"The Requires-Python field is set and matches your specification in setup.py." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:118 -msgid "4. Using Twine to publish" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:120 -msgid "" -"Twine has a number of advantages, apart from being faster it is now the " -"supported method for publishing packages." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:122 -msgid "Make sure you are using the newest version of Twine, at least 1.9." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:125 -msgid "Dropping a Python release" -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:127 -msgid "" -"Once you have published a package with the Requires-Python metadata, you can " -"then make a further update removing that Python runtime from support." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:129 -msgid "It must be done in this order for the automated fallback to work." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:131 -msgid "" -"For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 " -"of your package." -msgstr "" - -#: ../source/guides/dropping-older-python-versions.rst:133 -msgid "" -"If you were then to update the version string to \">=3.5\", and publish a " -"new version 2.0.0 of your package, any users running Pip 9.0+ from version " -"2.7 will have version 1.0.0 of the package installed, and any >=3.5 users " -"will receive version 2.0.0." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:5 -msgid "Hosting your own simple repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:8 -msgid "" -"If you wish to host your own simple repository [1]_, you can either use a " -"software package like `devpi`_ or you can use simply create the proper " -"directory structure and use any web server that can serve static files and " -"generate an autoindex." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:13 -msgid "" -"In either case, since you'll be hosting a repository that is likely not in " -"your user's default repositories, you should instruct them in your project's " -"description to configure their installer appropriately. For example with pip:" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:29 -msgid "" -"In addition, it is **highly** recommended that you serve your repository " -"with valid HTTPS. At this time, the security of your user's installations " -"depends on all repositories using a valid HTTPS setup." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:35 -msgid "\"Manual\" repository" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:37 -msgid "" -"The directory layout is fairly simple, within a root directory you need to " -"create a directory for each project. This directory should be the normalized " -"name (as defined by :pep:`503`) of the project. Within each of these " -"directories simply place each of the downloadable files. If you have the " -"projects \"Foo\" (with the versions 1.0 and 2.0) and \"bar\" (with the " -"version 0.1) You should end up with a structure that looks like::" -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:51 -msgid "" -"Once you have this layout, simply configure your webserver to serve the root " -"directory with autoindex enabled. For an example using the built in Web " -"server in `Twisted`_, you would simply run ``twistd -n web --path .`` and " -"then instruct users to add the URL to their installer's configuration." -msgstr "" - -#: ../source/guides/hosting-your-own-index.rst:58 -msgid "" -"For complete documentation of the simple repository protocol, see :pep:`503`." -msgstr "" - -#: ../source/guides/index.rst:8 -msgid "Installing Packages:" -msgstr "" - -#: ../source/guides/index.rst:20 -msgid "Building and Publishing Projects:" -msgstr "" - -#: ../source/guides/index.rst:38 -msgid "Miscellaneous:" -msgstr "" - -#: ../source/guides/index.rst:4 -msgid "" -"**Guides** are focused on accomplishing a specific task and assume that you " -"are already familiar with the basics of Python packaging. If you're looking " -"for an introduction to packaging, see :doc:`/tutorials/index`." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:5 -msgid "Package index mirrors and caches" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:8 -#: ../source/guides/supporting-multiple-python-versions.rst:8 -msgid "2014-12-24" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:14 -msgid "" -"Mirroring or caching of PyPI can be used to speed up local package " -"installation, allow offline work, handle corporate firewalls or just plain " -"Internet flakiness." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:17 -msgid "Three options are available in this area:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:19 -msgid "pip provides local caching options," -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:20 -msgid "" -"devpi provides higher-level caching option, potentially shared amongst many " -"users or machines, and" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:22 -msgid "" -"bandersnatch provides a local complete mirror of all PyPI :term:`packages " -"`." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:27 -msgid "Caching with pip" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:29 -msgid "" -"pip provides a number of facilities for speeding up installation by using " -"local cached copies of :term:`packages `:" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:32 -msgid "" -"`Fast & local installs `_ by downloading all the requirements for a project and " -"then pointing pip at those downloaded files instead of going to PyPI." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:36 -msgid "" -"A variation on the above which pre-builds the installation files for the " -"requirements using `python -m pip wheel `_::" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:45 -msgid "Caching with devpi" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:47 -msgid "" -"devpi is a caching proxy server which you run on your laptop, or some other " -"machine you know will always be available to you. See the `devpi " -"documentation for getting started`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:55 -msgid "Complete mirror with bandersnatch" -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:57 -msgid "" -"bandersnatch will set up a complete local mirror of all PyPI :term:`packages " -"` (externally-hosted packages are not mirrored). See " -"the `bandersnatch documentation for getting that going`__." -msgstr "" - -#: ../source/guides/index-mirrors-and-caches.rst:63 -msgid "" -"A benefit of devpi is that it will create a mirror which includes :term:" -"`packages ` that are external to PyPI, unlike " -"bandersnatch which will only cache :term:`packages ` " -"hosted on PyPI." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:5 -msgid "Installing scientific packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:11 -msgid "" -"Scientific software tends to have more complex dependencies than most, and " -"it will often have multiple build options to take advantage of different " -"kinds of hardware, or to interoperate with different pieces of external " -"software." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:16 -msgid "" -"In particular, `NumPy `__, which provides the basis " -"for most of the software in the `scientific Python stack `__ can be configured to interoperate with " -"different FORTRAN libraries, and can take advantage of different levels of " -"vectorised instructions available in modern CPUs." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:22 -msgid "" -"Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built " -"32-bit and 64-bit binaries in the ``wheel`` format are available for all " -"major operating systems (Windows, macOS, and Linux) on PyPI. Note, however, " -"that on Windows, NumPy binaries are linked against the `ATLAS `__ BLAS/LAPACK library, restricted to SSE2 instructions, " -"so they may not provide optimal linear algebra performance." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:29 -msgid "" -"There are a number of alternative options for obtaining scientific Python " -"libraries (or any other Python libraries that require a compilation " -"environment to install from source and don't provide pre-built wheel files " -"on PyPI)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:35 -msgid "Building from source" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:37 -msgid "" -"The same complexity which makes it difficult to distribute NumPy (and many " -"of the projects that depend on it) as wheel files also make them difficult " -"to build from source yourself. However, for intrepid folks that are willing " -"to spend the time wrangling compilers and linkers for both C and FORTRAN, " -"building from source is always an option." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:45 -msgid "Linux distribution packages" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:47 -msgid "" -"For Linux users, the system package manager will often have pre-compiled " -"versions of various pieces of scientific software, including NumPy and other " -"parts of the scientific Python stack." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:51 -msgid "" -"If using versions which may be several months old is acceptable, then this " -"is likely to be a good option (just make sure to allow access to " -"distributions installed into the system Python when using virtual " -"environments)." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:57 -msgid "Windows installers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:59 -msgid "" -"Many Python projects that don't (or can't) currently publish wheel files at " -"least publish Windows installers, either on PyPI or on their project " -"download page. Using these installers allows users to avoid the need to set " -"up a suitable environment to build extensions locally." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:64 -msgid "" -"The extensions provided in these installers are typically compatible with " -"the CPython Windows installers published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:67 -msgid "" -"For projects which don't provide their own Windows installers (and even some " -"which do), Christoph Gohlke at the University of California provides a " -"`collection of Windows installers `__. Many Python users on Windows have reported a positive experience with " -"these prebuilt versions." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:73 -msgid "" -"As with Linux system packages, the Windows installers will only install into " -"a system Python installation - they do not support installation in virtual " -"environments. Allowing access to distributions installed into the system " -"Python when using virtual environments is a common approach to working " -"around this limitation." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:79 -msgid "" -"The :term:`Wheel` project also provides a :command:`wheel convert` " -"subcommand that can convert a Windows :command:`bdist_wininst` installer to " -"a wheel." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:86 -msgid "macOS installers and package managers" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:88 -msgid "" -"Similar to the situation on Windows, many projects (including NumPy) publish " -"macOS installers that are compatible with the macOS CPython binaries " -"published on python.org." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:92 -msgid "" -"macOS users also have access to Linux distribution style package managers " -"such as ``MacPorts``. The SciPy site has more details on using MacPorts to " -"install the `scientific Python stack `__" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:99 -msgid "SciPy distributions" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:101 -msgid "" -"The SciPy site lists `several distributions `__ that provide the full SciPy stack to end users in an easy to use " -"and update format." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:105 -msgid "" -"Some of these distributions may not be compatible with the standard ``pip`` " -"and ``virtualenv`` based toolchain." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:109 -#: ../source/key_projects.rst:596 -msgid "Spack" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:110 -msgid "" -"`Spack `_ is a flexible package manager " -"designed to support multiple versions, configurations, platforms, and " -"compilers. It was built to support the needs of large supercomputing centers " -"and scientific application teams, who must often build software many " -"different ways. Spack is not limited to Python; it can install packages for " -"``C``, ``C++``, ``Fortran``, ``R``, and other languages. It is non-" -"destructive; installing a new version of one package does not break existing " -"installations, so many configurations can coexist on the same system." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:119 -msgid "" -"Spack offers a simple but powerful syntax that allows users to specify " -"versions and configuration options concisely. Package files are written in " -"pure Python, and they are templated so that it is easy to swap compilers, " -"dependency implementations (like MPI), versions, and build options with a " -"single package file. Spack also generates *module* files so that packages " -"can be loaded and unloaded from the user's environment." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:128 -msgid "The conda cross-platform package manager" -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:130 -msgid "" -"`Anaconda `_ is a Python distribution " -"published by Anaconda, Inc. It is a stable collection of Open Source " -"packages for big data and scientific use. As of the 5.0 release of " -"Anaconda, about 200 packages are installed by default, and a total of " -"400-500 can be installed and updated from the Anaconda repository." -msgstr "" - -#: ../source/guides/installing-scientific-packages.rst:136 -msgid "" -"``conda`` is an open source (BSD licensed) package management system and " -"environment management system included in Anaconda that allows users to " -"install multiple versions of binary software packages and their " -"dependencies, and easily switch between them. It is a cross-platform tool " -"working on Windows, macOS, and Linux. Conda can be used to package up and " -"distribute all kinds of packages, it is not limited to just Python packages. " -"It has full support for native virtual environments. Conda makes " -"environments first-class citizens, making it easy to create independent " -"environments even for C libraries. It is written in Python, but is Python-" -"agnostic. Conda manages Python itself as a package, so that :command:`conda " -"update python` is possible, in contrast to pip, which only manages Python " -"packages. Conda is available in Anaconda and Miniconda (an easy-to-install " -"download with just Python and conda)." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:2 -msgid "Installing stand alone command line tools" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:4 -msgid "" -"Many packages have command line entry points. Examples of this type of " -"application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:10 -msgid "" -"Usually you want to be able to access these from anywhere, but installing " -"packages and their dependencies to the same global environment can cause " -"version conflicts and break dependencies the operating system has on Python " -"packages." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:15 -msgid "" -":ref:`pipx` solves this by creating a virtual environment for each package, " -"while also ensuring that package's applications are accessible through a " -"directory that is on your ``$PATH``. This allows each package to be upgraded " -"or uninstalled without causing conflicts with other packages, and allows you " -"to safely run the program from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:21 -msgid "pipx only works with Python 3.6+." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:23 -msgid "``pipx`` is installed with ``pip``:" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 -msgid "" -"You may need to restart your terminal for the path updates to take effect." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 -msgid "" -"Now you can install packages with ``pipx install`` and access the package's " -"entry point(s) from anywhere." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 -#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 -msgid "For example" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 -msgid "" -"To see a list of packages installed with pipx and which CLI applications are " -"available, use ``pipx list``." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 -msgid "To upgrade or uninstall the package" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 -msgid "``pipx`` can be upgraded or uninstalled with pip" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 -msgid "" -"``pipx`` also allows you to install and run the latest version of a cli tool " -"in a temporary, ephemeral environment." -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 -msgid "To see the full list of commands ``pipx`` offers, run" -msgstr "" - -#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 -msgid "" -"You can learn more about ``pipx`` at its homepage, https://github.com/pypa/" -"pipx." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:5 -msgid "Installing pip/setuptools/wheel with Linux Package Managers" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:8 -msgid "2015-09-17" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:11 -msgid "" -"This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:" -"`wheel` using Linux package managers." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:14 -msgid "" -"If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:" -"`installing_requirements` section instead." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:18 -msgid "" -"Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, " -"and :ref:`wheel` supported by a specific Linux Distribution to be outdated " -"by the time it's released to the public, and updates generally only occur " -"for security reasons, not for feature updates. For certain Distributions, " -"there are additional repositories that can be enabled to provide newer " -"versions. The repositories we know about are explained below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:25 -msgid "" -"Also note that it's somewhat common for Distributions to apply patches for " -"the sake of security and normalization to their own standards. In some " -"cases, this can lead to bugs or unexpected behaviors that vary from the " -"original unpatched versions. When this is known, we will make note of it " -"below." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:32 -msgid "Fedora" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:34 -msgid "Fedora 21:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:36 -#: ../source/guides/installing-using-linux-tools.rst:45 -#: ../source/guides/installing-using-linux-tools.rst:124 -#: ../source/guides/installing-using-linux-tools.rst:138 -#: ../source/guides/installing-using-linux-tools.rst:158 -msgid "Python 2::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:41 -msgid "Python 3: ``sudo yum install python3 python3-wheel``" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:43 -msgid "Fedora 22:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:50 -msgid "Python 3: ``sudo dnf install python3 python3-wheel``" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:53 -msgid "" -"To get newer versions of pip, setuptools, and wheel for Python 2, you can " -"enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:63 -msgid "CentOS/RHEL" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:65 -msgid "" -"CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core " -"repositories, although :ref:`setuptools` is installed by default." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:68 -msgid "To install pip and wheel for the system Python, there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:70 -msgid "" -"Enable the `EPEL repository `_ using " -"`these instructions `__. On EPEL 6 and EPEL7, you can " -"install pip like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:77 -msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:81 -msgid "" -"Since EPEL only offers extra, non-conflicting packages, EPEL does not offer " -"setuptools, since it's in the core repository." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:85 -msgid "" -"Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:92 -msgid "To additionally upgrade setuptools, run::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:97 -msgid "" -"To install pip, wheel, and setuptools, in a parallel, non-system environment " -"(using yum) then there are two options:" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:101 -msgid "" -"Use the \"Software Collections\" feature to enable a parallel collection " -"that includes pip, setuptools, and wheel." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:104 -msgid "" -"For Redhat, see here: http://developers.redhat.com/products/" -"softwarecollections/overview/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:106 -msgid "For CentOS, see here: https://www.softwarecollections.org/en/" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:108 -msgid "Be aware that collections may not contain the most recent versions." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:110 -msgid "" -"Enable the `IUS repository `_ and install " -"one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which " -"are kept fairly up to date." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:116 -msgid "For example, for Python 3.4 on CentOS7/RHEL7::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:122 -msgid "openSUSE" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:129 -#: ../source/guides/installing-using-linux-tools.rst:143 -#: ../source/guides/installing-using-linux-tools.rst:162 -msgid "Python 3::" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:135 -msgid "Debian/Ubuntu" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:150 -msgid "" -"Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" " -"`_ by default, " -"which is a significant behavior change that can be surprising to some users." -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:156 -msgid "Arch Linux" -msgstr "" - -#: ../source/guides/installing-using-linux-tools.rst:168 -msgid "" -"Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the " -"only option is to manually place the repo files as described." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:2 -msgid "Installing packages using pip and virtual environments" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:4 -msgid "" -"This guide discusses how to install packages using :ref:`pip` and a virtual " -"environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` " -"for Python 2. These are the lowest-level tools for managing Python packages " -"and are recommended if higher-level tools do not suit your needs." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:9 -msgid "" -"This doc uses the term **package** to refer to a :term:`Distribution " -"Package` which is different from an :term:`Import Package` that which is " -"used to import modules in your Python source code." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:15 -msgid "Installing pip" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:17 -msgid "" -":ref:`pip` is the reference Python package manager. It's used to install and " -"update packages. You'll need to make sure you have the latest version of pip " -"installed." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 -msgid "" -"Debian and most other distributions include a `python-pip`_ package, if you " -"want to use the Linux distribution-provided versions of pip see :doc:`/" -"guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 -msgid "" -"You can also install pip yourself to ensure you have the latest version. " -"It's recommended to use the system pip to bootstrap a user installation of " -"pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 -msgid "Afterwards, you should have the newest pip installed in your user site:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 -msgid "" -"The Python installers for Windows include pip. You should be able to access " -"pip using:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 -msgid "You can make sure that pip is up-to-date by running:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 -msgid "Installing virtualenv" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 -msgid "" -"If you are using Python 3.3 or newer, the :mod:`venv` module is the " -"preferred way to create and manage virtual environments. venv is included in " -"the Python standard library and requires no additional installation. If you " -"are using venv, you may skip this section." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 -msgid "" -":ref:`virtualenv` is used to manage Python packages for different projects. " -"Using virtualenv allows you to avoid installing Python packages globally " -"which could break system tools or other projects. You can install virtualenv " -"using pip." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 -msgid "Creating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 -msgid "" -":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to " -"manage separate package installations for different projects. They " -"essentially allow you to create a \"virtual\" isolated Python installation " -"and install packages into that virtual installation. When you switch " -"projects, you can simply create a new virtual environment and not have to " -"worry about breaking the packages installed in the other environments. It is " -"always recommended to use a virtual environment while developing Python " -"applications." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 -msgid "" -"To create a virtual environment, go to your project's directory and run " -"venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the " -"below commands." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 -msgid "" -"The second argument is the location to create the virtual environment. " -"Generally, you can just create this in your project and call it ``env``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 -msgid "venv will create a virtual Python installation in the ``env`` folder." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 -msgid "" -"You should exclude your virtual environment directory from your version " -"control system using ``.gitignore`` or similar." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 -msgid "Activating a virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 -msgid "" -"Before you can start installing or using packages in your virtual " -"environment you'll need to *activate* it. Activating a virtual environment " -"will put the virtual environment-specific ``python`` and ``pip`` executables " -"into your shell's ``PATH``." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 -msgid "" -"You can confirm you're in the virtual environment by checking the location " -"of your Python interpreter, it should point to the ``env`` directory." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 -msgid "" -"As long as your virtual environment is activated pip will install packages " -"into that specific environment and you'll be able to import and use packages " -"in your Python application." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 -msgid "Leaving the virtual environment" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 -msgid "" -"If you want to switch projects or otherwise leave your virtual environment, " -"simply run:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 -msgid "" -"If you want to re-enter the virtual environment just follow the same " -"instructions above about activating a virtual environment. There's no need " -"to re-create the virtual environment." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 -msgid "Installing packages" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 -msgid "" -"Now that you're in your virtual environment you can install packages. Let's " -"install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 -msgid "" -"pip should download requests and all of its dependencies and install them:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 -msgid "Installing specific versions" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 -msgid "" -"pip allows you to specify which version of a package to install using :term:" -"`version specifiers `. For example, to install a specific " -"version of ``requests``:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 -msgid "To install the latest ``2.x`` release of requests:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 -msgid "To install pre-release versions of packages, use the ``--pre`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 -msgid "Installing extras" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 -msgid "" -"Some packages have optional `extras`_. You can tell pip to install these by " -"specifying the extra in brackets:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 -msgid "Installing from source" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 -msgid "pip can install a package directly from source, for example:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 -msgid "" -"Additionally, pip can install packages from source in `development mode`_, " -"meaning that changes to the source directory will immediately affect the " -"installed package without needing to re-install:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 -msgid "Installing from version control systems" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 -msgid "" -"pip can install packages directly from their version control system. For " -"example, you can install directly from a git repository:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 -msgid "" -"For more information on supported version control systems and syntax, see " -"pip's documentation on :ref:`VCS Support `." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 -#: ../source/tutorials/installing-packages.rst:569 -msgid "Installing from local archives" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 -msgid "" -"If you have a local copy of a :term:`Distribution Package`'s archive (a zip, " -"wheel, or tar file) you can install it directly with pip:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 -msgid "" -"If you have a directory containing archives of multiple packages, you can " -"tell pip to look for packages there and not to use the :term:`Python Package " -"Index (PyPI)` at all:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 -msgid "" -"This is useful if you are installing packages on a system with limited " -"connectivity or if you want to strictly control the origin of distribution " -"packages." -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 -msgid "Using other package indexes" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 -msgid "" -"If you want to download packages from a different index than the :term:" -"`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 -msgid "" -"If you want to allow packages from both the :term:`Python Package Index " -"(PyPI)` and a separate index, you can use the ``--extra-index-url`` flag " -"instead:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 -#: ../source/tutorials/installing-packages.rst:389 -msgid "Upgrading packages" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 -msgid "" -"pip can upgrade packages in-place using the ``--upgrade`` flag. For example, " -"to install the latest version of ``requests`` and all of its dependencies:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 -msgid "Using requirements files" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 -msgid "" -"Instead of installing packages individually, pip allows you to declare all " -"dependencies in a :ref:`Requirements File `. For " -"example you could create a :file:`requirements.txt` file containing:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 -msgid "" -"And tell pip to install all of the packages in this file using the ``-r`` " -"flag:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 -msgid "Freezing dependencies" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 -msgid "" -"Pip can export a list of all installed packages and their versions using the " -"``freeze`` command:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 -msgid "Which will output a list of package specifiers such as:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 -msgid "" -"This is useful for creating :ref:`pip:Requirements Files` that can re-create " -"the exact versions of all packages installed in an environment." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:2 -msgid "Making a PyPI-friendly README" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:4 -msgid "" -"README files can help your users understand your project and can be used to " -"set your project's description on PyPI. This guide helps you create a README " -"in a PyPI-friendly format and include your README in your package so it " -"appears on PyPI." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:9 -msgid "Creating a README file" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:11 -msgid "" -"README files for Python projects are often named ``README``, ``README.txt``, " -"``README.rst``, or ``README.md``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:13 -msgid "" -"For your README to display properly on PyPI, choose a markup language " -"supported by PyPI. Formats supported by `PyPI's README renderer `_ are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:16 -msgid "plain text" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:17 -msgid "" -"`reStructuredText `_ (without " -"Sphinx extensions)" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:18 -msgid "" -"Markdown (`GitHub Flavored Markdown `_ by " -"default, or `CommonMark `_)" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:21 -msgid "" -"It's customary to save your README file in the root of your project, in the " -"same directory as your :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:25 -msgid "Including your README in your package's metadata" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:27 -msgid "" -"To include your README's contents as your package description, set your " -"project's ``Description`` and ``Description-Content-Type`` metadata, " -"typically in your project's :file:`setup.py` file." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:33 -msgid ":ref:`description-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:34 -msgid ":ref:`description-content-type-optional`" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:36 -msgid "" -"For example, to set these values in a package's :file:`setup.py` file, use " -"``setup()``'s ``long_description`` and ``long_description_content_type``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:39 -msgid "" -"Set the value of ``long_description`` to the contents (not the path) of the " -"README file itself. Set the ``long_description_content_type`` to an accepted " -"``Content-Type``-style value for your README file's markup, such as ``text/" -"plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdown``." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:45 -msgid "" -"If you're using GitHub-flavored Markdown to write a project's description, " -"ensure you upgrade the following tools:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:60 -msgid "The minimum required versions of the respective tools are:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:62 -msgid "``setuptools >= 38.6.0``" -msgstr "``setuptools >= 38.6.0``" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:63 -msgid "``wheel >= 0.31.0``" -msgstr "``wheel >= 0.31.0``" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:64 -msgid "``twine >= 1.11.0``" -msgstr "``twine >= 1.11.0``" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:66 -msgid "" -"It's recommended that you use ``twine`` to upload the project's distribution " -"packages:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:72 -msgid "" -"For example, see this :file:`setup.py` file, which reads the contents of :" -"file:`README.md` as ``long_description`` and identifies the markup as GitHub-" -"flavored Markdown:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:95 -msgid "Validating reStructuredText markup" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:97 -msgid "" -"If your README is written in reStructuredText, any invalid markup will " -"prevent it from rendering, causing PyPI to instead just show the README's " -"raw source." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:100 -msgid "" -"Note that Sphinx extensions used in docstrings, such as `directives and " -"roles `_ (e.g., \"``:py:func:`getattr```\" or \"``:ref:`my-reference-label```" -"\"), are not allowed here and will result in error messages like \"``Error: " -"Unknown interpreted text role \"py:func\".``\"." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:105 -msgid "" -"You can check your README for markup errors before uploading as follows:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:107 -msgid "" -"Install the latest version of `twine `_; " -"version 1.12.0 or higher is required:" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:122 -msgid "" -"Build the sdist and wheel for your project as described under :ref:" -"`Packaging Your Project`." -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:125 -msgid "Run ``twine check`` on the sdist and wheel::" -msgstr "" - -#: ../source/guides/making-a-pypi-friendly-readme.rst:129 -msgid "" -"This command will report any problems rendering your README. If your markup " -"renders fine, the command will output ``Checking distribution FILENAME: " -"Passed``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:4 -msgid "Migrating to PyPI.org" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:6 -msgid "" -":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``." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:12 -msgid "Publishing releases" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:14 -msgid "``pypi.org`` is the default upload platform as of September 2016." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:16 -msgid "" -"Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. " -"As of April 13th, 2018, ``pypi.org`` is the URL for PyPI." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:19 -msgid "" -"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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:22 -msgid "" -"The default upload settings switched to ``pypi.org`` in the following " -"versions:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:24 -msgid "``twine`` 1.8.0" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:25 -msgid "``setuptools`` 27.0.0" -msgstr "``setuptools`` 27.0.0" - -#: ../source/guides/migrating-to-pypi-org.rst:26 -msgid "Python 2.7.13 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:27 -msgid "Python 3.4.6 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:28 -msgid "Python 3.5.3 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:29 -msgid "Python 3.6.0 (``distutils`` update)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:31 -msgid "" -"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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:48 -msgid "" -"Then simply delete the line starting with ``repository`` and you will use " -"your upload tool's default URL." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:51 -msgid "" -"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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:67 -msgid "" -"(``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.)" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:73 -msgid "Registering package names & metadata" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:75 -msgid "" -"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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:79 -msgid "" -"As a result, attempting explicit registration after switching to using PyPI." -"org for uploads will give the following error message::" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:84 -msgid "" -"The solution is to skip the registration step, and proceed directly to " -"uploading artifacts." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:89 -#: ../source/guides/using-testpypi.rst:5 -msgid "Using TestPyPI" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:91 -msgid "" -"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:" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:113 -msgid "Registering new user accounts" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:115 -msgid "" -"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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:121 -msgid "Browsing packages" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:123 -msgid "" -"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." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:130 -msgid "Downloading packages" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:132 -msgid "``pypi.org`` is the default host for downloading packages." -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:135 -msgid "Managing published packages and releases" -msgstr "" - -#: ../source/guides/migrating-to-pypi-org.rst:137 -msgid "" -"``pypi.org`` provides a fully functional interface for logged in users to " -"manage their published packages and releases." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:5 -msgid "Multi-version installs" -msgstr "" - -#: ../source/guides/multi-version-installs.rst:8 -msgid "" -"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``)." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:13 -msgid "" -"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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:19 -msgid "" -"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." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:31 -msgid "" -"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 ``python -c ''`` to invoke the application's main " -"entry point directly." -msgstr "" - -#: ../source/guides/multi-version-installs.rst:38 -msgid "" -"Refer to the `pkg_resources documentation `__ for more details." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:5 -msgid "Packaging binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:8 -msgid "2013-12-08" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:10 -msgid "" -"One of the features of the CPython reference interpreter is that, in " -"addition to allowing the execution of Python code, it also exposes a rich C " -"API for use by other software. One of the most common uses of this C API is " -"to create importable C extensions that allow things which aren't always easy " -"to achieve in pure Python code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:20 -msgid "An overview of binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:23 -msgid "Use cases" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:25 -msgid "" -"The typical use cases for binary extensions break down into just three " -"conventional categories:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:28 -msgid "" -"**accelerator modules**: these modules are completely self-contained, and " -"are created solely to run faster than the equivalent pure Python code runs " -"in CPython. Ideally, accelerator modules will always have a pure Python " -"equivalent to use as a fallback if the accelerated version isn't available " -"on a given system. The CPython standard library makes extensive use of " -"accelerator modules. *Example*: When importing ``datetime``, Python falls " -"back to the `datetime.py `_ module if the C implementation ( `_datetimemodule.c `_) is not " -"available." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:39 -msgid "" -"**wrapper modules**: these modules are created to expose existing C " -"interfaces to Python code. They may either expose the underlying C interface " -"directly, or else expose a more \"Pythonic\" API that makes use of Python " -"language features to make the API easier to use. The CPython standard " -"library makes extensive use of wrapper modules. *Example*: `functools.py " -"`_ is a " -"Python module wrapper for `_functoolsmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:47 -msgid "" -"**low-level system access**: these modules are created to access lower level " -"features of the CPython runtime, the operating system, or the underlying " -"hardware. Through platform specific code, extension modules may achieve " -"things that aren't possible in pure Python code. A number of CPython " -"standard library modules are written in C in order to access interpreter " -"internals that aren't exposed at the language level. *Example*: ``sys``, " -"which comes from `sysmodule.c `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:56 -msgid "" -"One particularly notable feature of C extensions is that, when they don't " -"need to call back into the interpreter runtime, they can release CPython's " -"global interpreter lock around long-running operations (regardless of " -"whether those operations are CPU or IO bound)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:61 -msgid "" -"Not all extension modules will fit neatly into the above categories. The " -"extension modules included with NumPy, for example, span all three use cases " -"- they move inner loops to C for speed reasons, wrap external libraries " -"written in C, FORTRAN and other languages, and use low level system " -"interfaces for both CPython and the underlying operation system to support " -"concurrent execution of vectorised operations and to tightly control the " -"exact memory layout of created objects." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:71 -msgid "Disadvantages" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:73 -msgid "" -"The main disadvantage of using binary extensions is the fact that it makes " -"subsequent distribution of the software more difficult. One of the " -"advantages of using Python is that it is largely cross platform, and the " -"languages used to write extension modules (typically C or C++, but really " -"any language that can bind to the CPython C API) typically require that " -"custom binaries be created for different platforms." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:80 -msgid "This means that binary extensions:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:82 -msgid "" -"require that end users be able to either build them from source, or else " -"that someone publish pre-built binaries for common platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:85 -msgid "" -"may not be compatible with different builds of the CPython reference " -"interpreter" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:88 -msgid "" -"often will not work correctly with alternative interpreters such as PyPy, " -"IronPython or Jython" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:91 -msgid "" -"if handcoded, make maintenance more difficult by requiring that maintainers " -"be familiar not only with Python, but also with the language used to create " -"the binary extension, as well as with the details of the CPython C API." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:96 -msgid "" -"if a pure Python fallback implementation is provided, make maintenance more " -"difficult by requiring that changes be implemented in two places, and " -"introducing additional complexity in the test suite to ensure both versions " -"are always executed." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:101 -msgid "" -"Another disadvantage of relying on binary extensions is that alternative " -"import mechanisms (such as the ability to import modules directly from " -"zipfiles) often won't work for extension modules (as the dynamic loading " -"mechanisms on most platforms can only load libraries from disk)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:108 -msgid "Alternatives to handcoded accelerator modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:110 -msgid "" -"When extension modules are just being used to make code run faster (after " -"profiling has identified the code where the speed increase is worth " -"additional maintenance effort), a number of other alternatives should also " -"be considered:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:115 -msgid "" -"look for existing optimised alternatives. The CPython standard library " -"includes a number of optimised data structures and algorithms (especially in " -"the builtins and the ``collections`` and ``itertools`` modules). The Python " -"Package Index also offers additional alternatives. Sometimes, the " -"appropriate choice of standard library or third party module can avoid the " -"need to create your own accelerator module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:122 -msgid "" -"for long running applications, the JIT compiled `PyPy interpreter `__ may offer a suitable alternative to the standard CPython " -"runtime. The main barrier to adopting PyPy is typically reliance on other " -"binary extension modules - while PyPy does emulate the CPython C API, " -"modules that rely on that cause problems for the PyPy JIT, and the emulation " -"layer can often expose latent defects in extension modules that CPython " -"currently tolerates (frequently around reference counting errors - an object " -"having one live reference instead of two often won't break anything, but no " -"references instead of one is a major problem)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:132 -msgid "" -"`Cython `__ is a mature static compiler that can compile " -"most Python code to C extension modules. The initial compilation provides " -"some speed increases (by bypassing the CPython interpreter layer), and " -"Cython's optional static typing features can offer additional opportunities " -"for speed increases. Using Cython still has the disadvantage of increasing " -"the complexity of distributing the resulting application, but has the " -"benefit of having a reduced barrier to entry for Python programmers " -"(relative to other languages like C or C++)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:141 -msgid "" -"`Numba `__ is a newer tool, created by members of " -"the scientific Python community, that aims to leverage LLVM to allow " -"selective compilation of pieces of a Python application to native machine " -"code at runtime. It requires that LLVM be available on the system where the " -"code is running, but can provide significant speed increases, especially for " -"operations that are amenable to vectorisation." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:150 -msgid "Alternatives to handcoded wrapper modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:152 -msgid "" -"The C ABI (Application Binary Interface) is a common standard for sharing " -"functionality between multiple applications. One of the strengths of the " -"CPython C API (Application Programming Interface) is allowing Python users " -"to tap into that functionality. However, wrapping modules by hand is quite " -"tedious, so a number of other alternative approaches should be considered." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:158 -msgid "" -"The approaches described below don't simplify the distribution case at all, " -"but they *can* significantly reduce the maintenance burden of keeping " -"wrapper modules up to date." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:162 -msgid "" -"In addition to being useful for the creation of accelerator modules, `Cython " -"`__ is also useful for creating wrapper modules for C or " -"C++. It still involves wrapping the interfaces by hand, however, and is very " -"repetitive, so may not be a good choice for wrapping large APIs." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:168 -msgid "" -"`pybind11 `__ is a pure C++11 library that " -"provides a clean C++ interface to the CPython (and PyPy) C API. It does not " -"require a pre-processing step; it is written entirely in templated C++. " -"Helpers are included for Setuptools or CMake builds. It was based on `Boost." -"Python `__, but doesn't require the Boost libraries or BJam." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:175 -msgid "" -"`cffi `__ is a project created by some of the " -"PyPy developers to make it straightforward for developers that already know " -"both Python and C to expose their C modules to Python applications. It also " -"makes it relatively straightforward to wrap a C module based on its header " -"files, even if you don't know C yourself." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:181 -msgid "" -"One of the key advantages of ``cffi`` is that it is compatible with the PyPy " -"JIT, allowing CFFI wrapper modules to participate fully in PyPy's tracing " -"JIT optimisations." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:185 -msgid "" -"`SWIG `__ is a wrapper interface generator that allows " -"a variety of programming languages, including Python, to interface with C " -"and C++ code." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:189 -msgid "" -"The standard library's ``ctypes`` module, while useful for getting access to " -"C level interfaces when header information isn't available, suffers from the " -"fact that it operates solely at the C ABI level, and thus has no automatic " -"consistency checking between the interface actually being exported by the " -"library and the one declared in the Python code. By contrast, the above " -"alternatives are all able to operate at the C *API* level, using C header " -"files to ensure consistency between the interface exported by the library " -"being wrapped and the one expected by the Python wrapper module. While " -"``cffi`` *can* operate directly at the C ABI level, it suffers from the same " -"interface inconsistency problems as ``ctypes`` when it is used that way." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:203 -msgid "Alternatives for low level system access" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:205 -msgid "" -"For applications that need low level system access (regardless of the " -"reason), a binary extension module often *is* the best way to go about it. " -"This is particularly true for low level access to the CPython runtime " -"itself, since some operations (like releasing the Global Interpreter Lock) " -"are simply invalid when the interpreter is running code, even if a module " -"like ``ctypes`` or ``cffi`` is used to obtain access to the relevant C API " -"interfaces." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:213 -msgid "" -"For cases where the extension module is manipulating the underlying " -"operating system or hardware (rather than the CPython runtime), it may " -"sometimes be better to just write an ordinary C library (or a library in " -"another systems programming language like C++ or Rust that can export a C " -"compatible ABI), and then use one of the wrapping techniques described above " -"to make the interface available as an importable Python module." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:222 -msgid "Implementing binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:224 -msgid "" -"The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in " -"C `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:241 -msgid "Building binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:244 -msgid "Building extensions for multiple platforms" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:246 -msgid "" -"If you plan to distribute your extension, you should provide :term:`wheels " -"` for all the platforms you intend to support. For most extensions, " -"this is at least one package per Python version times the number of OS and " -"architectures you support. These are usually built on continuous " -"integration (CI) systems. There are tools to help you build highly " -"redistributable binaries from CI; these include :ref:`cibuildwheel` and :ref:" -"`multibuild`." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:256 -msgid "Binary extensions for Windows" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:258 -msgid "" -"Before it is possible to build a binary extension, it is necessary to ensure " -"that you have a suitable compiler available. On Windows, Visual C is used to " -"build the official CPython interpreter, and should be used to build " -"compatible binary extensions." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:263 -msgid "" -"Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio " -"2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older " -"versions of Visual Studio are no longer easily available from Microsoft, so " -"for versions of Python prior to 3.5, the compilers must be obtained " -"differently if you do not already have a copy of the relevant version of " -"Visual Studio." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:269 -msgid "" -"To set up a build environment for binary extensions, the steps are as " -"follows:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:271 -msgid "For Python 2.7" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:273 -msgid "" -"Install \"Visual C++ Compiler Package for Python 2.7\", which is available " -"from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:276 -msgid "" -"Use (a recent version of) setuptools in your setup.py (pip will do this for " -"you, in any case)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:278 -#: ../source/guides/packaging-binary-extensions.rst:288 -#: ../source/guides/packaging-binary-extensions.rst:295 -msgid "Done." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:280 -msgid "For Python 3.4" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:282 -msgid "" -"Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is " -"available from `Microsoft's website `__." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:285 -msgid "" -"Work from an SDK command prompt (with the environment variables set, and the " -"SDK on PATH)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:287 -msgid "Set DISTUTILS_USE_SDK=1" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:290 -msgid "For Python 3.5" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:292 -msgid "" -"Install `Visual Studio 2015 Community Edition `__ (or any later version, " -"when these are released)." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:297 -msgid "" -"Note that from Python 3.5 onwards, Visual Studio works in a backward " -"compatible way, which means that any future version of Visual Studio will be " -"able to build Python extensions for all Python versions from 3.5 onwards." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:301 -msgid "" -"Building with the recommended compiler on Windows ensures that a compatible " -"C library is used throughout the Python process." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:305 -msgid "Binary extensions for Linux" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:307 -msgid "" -"Linux binaries must use a sufficiently old glibc to be compatible with older " -"distributions. The `manylinux `_ Docker " -"images provide a build environment with a glibc old enough to support most " -"current Linux distributions on common architectures." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:313 -msgid "Binary extensions for macOS" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:315 -msgid "" -"Binary compatibility on macOS is determined by the target minimum deployment " -"system, e.g. *10.9*, which is often specified with the " -"``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries " -"on macOS. When building with setuptools / distutils, the deployment target " -"is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For " -"common deployment targets for macOS Python distributions, see the `MacPython " -"Spinning Wheels wiki `_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:325 -msgid "Publishing binary extensions" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:327 -msgid "" -"For interim guidance on this topic, see the discussion in `this issue " -"`_." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:343 -msgid "Additional resources" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:345 -msgid "" -"Cross-platform development and distribution of extension modules is a " -"complex topic, so this guide focuses primarily on providing pointers to " -"various tools that automate dealing with the underlying technical " -"challenges. The additional resources in this section are instead intended " -"for developers looking to understand more about the underlying binary " -"interfaces that those systems rely on at runtime." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:352 -msgid "Cross-platform wheel generation with scikit-build" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:354 -msgid "" -"The `scikit-build `_ package " -"helps abstract cross-platform build operations and provides additional " -"capabilities when creating binary extension packages. Additional " -"documentation is also available on the `C runtime, compiler, and build " -"system generator `_ for Python binary extension modules." -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:362 -msgid "Introduction to C/C++ extension modules" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:364 -msgid "" -"For a more in depth explanation of how extension modules are used by CPython " -"on a Debian system, see the following articles:" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:367 -msgid "" -"`What are (c)python extension modules? `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:368 -msgid "`Releasing the gil `_" -msgstr "" - -#: ../source/guides/packaging-binary-extensions.rst:369 -msgid "" -"`Writing cpython extension modules using C++ `_" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:3 -msgid "Packaging namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:5 -msgid "" -"Namespace packages allow you to split the sub-packages and modules within a " -"single :term:`package ` across multiple, separate :term:" -"`distribution packages ` (referred to as " -"**distributions** in this document to avoid ambiguity). For example, if you " -"have the following package structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:24 -msgid "And you use this package in your code like so::" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:29 -msgid "Then you can break these sub-packages into two separate distributions:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:46 -msgid "Each sub-package can now be separately installed, used, and versioned." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:48 -msgid "" -"Namespace packages can be useful for a large collection of loosely-related " -"packages (such as a large corpus of client libraries for multiple products " -"from a single company). However, namespace packages come with several " -"caveats and are not appropriate in all cases. A simple alternative is to use " -"a prefix on all of your distributions such as ``import " -"mynamespace_subpackage_a`` (you could even use ``import " -"mynamespace_subpackage_a as subpackage_a`` to keep the import object short)." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:58 -msgid "Creating a namespace package" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:60 -msgid "" -"There are currently three different approaches to creating namespace " -"packages:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:62 -msgid "" -"Use `native namespace packages`_. This type of namespace package is defined " -"in :pep:`420` and is available in Python 3.3 and later. This is recommended " -"if packages in your namespace only ever need to support Python 3 and " -"installation via ``pip``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:66 -msgid "" -"Use `pkgutil-style namespace packages`_. This is recommended for new " -"packages that need to support Python 2 and 3 and installation via both " -"``pip`` and ``python setup.py install``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:69 -msgid "" -"Use `pkg_resources-style namespace packages`_. This method is recommended if " -"you need compatibility with packages already using this method or if your " -"package needs to be zip-safe." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:73 -msgid "" -"While native namespace packages and pkgutil-style namespace packages are " -"largely compatible, pkg_resources-style namespace packages are not " -"compatible with the other methods. It's inadvisable to use different methods " -"in different distributions that provide packages to the same namespace." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:80 -msgid "Native namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:82 -msgid "" -"Python 3.3 added **implicit** namespace packages from :pep:`420`. All that " -"is required to create a native namespace package is that you just omit :file:" -"`__init__.py` from the namespace package directory. An example file " -"structure:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:97 -msgid "" -"It is extremely important that every distribution that uses the namespace " -"package omits the :file:`__init__.py` or uses a pkgutil-style :file:" -"`__init__.py`. If any distribution does not, it will cause the namespace " -"logic to fail and the other sub-packages will not be importable." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:102 -msgid "" -"Because ``mynamespace`` doesn't contain an :file:`__init__.py`, :func:" -"`setuptools.find_packages` won't find the sub-package. You must use :func:" -"`setuptools.find_namespace_packages` instead or explicitly list all packages " -"in your :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:117 -msgid "" -"A complete working example of two native namespace packages can be found in " -"the `native namespace package example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:123 -msgid "" -"Because native and pkgutil-style namespace packages are largely compatible, " -"you can use native namespace packages in the distributions that only support " -"Python 3 and pkgutil-style namespace packages in the distributions that need " -"to support Python 2 and 3." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:129 -msgid "pkgutil-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:131 -msgid "" -"Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. " -"This can be used to declare namespace packages that need to be compatible " -"with both Python 2.3+ and Python 3. This is the recommended approach for the " -"highest level of compatibility." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:136 -msgid "" -"To create a pkgutil-style namespace package, you need to provide an :file:" -"`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:148 -#: ../source/guides/packaging-namespace-packages.rst:194 -msgid "" -"The :file:`__init__.py` file for the namespace package needs to contain " -"**only** the following:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:155 -#: ../source/guides/packaging-namespace-packages.rst:201 -msgid "" -"**Every** distribution that uses the namespace package must include an " -"identical :file:`__init__.py`. If any distribution does not, it will cause " -"the namespace logic to fail and the other sub-packages will not be " -"importable. Any additional code in :file:`__init__.py` will be inaccessible." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:160 -msgid "" -"A complete working example of two pkgutil-style namespace packages can be " -"found in the `pkgutil namespace example project`_." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:171 -msgid "pkg_resources-style namespace packages" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:173 -msgid "" -"`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and " -"the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together " -"these can be used to declare namespace packages. While this approach is no " -"longer recommended, it is widely present in most existing namespace " -"packages. If you are creating a new distribution within an existing " -"namespace package that uses this method then it's recommended to continue " -"using this as the different methods are not cross-compatible and it's not " -"advisable to try to migrate an existing package." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:182 -msgid "" -"To create a pkg_resources-style namespace package, you need to provide an :" -"file:`__init__.py` file for the namespace package:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:206 -msgid "" -"Some older recommendations advise the following in the namespace package :" -"file:`__init__.py`:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:216 -msgid "" -"The idea behind this was that in the rare case that setuptools isn't " -"available packages would fall-back to the pkgutil-style packages. This isn't " -"advisable because pkgutil and pkg_resources-style namespace packages are not " -"cross-compatible. If the presence of setuptools is a concern then the " -"package should just explicitly depend on setuptools via ``install_requires``." -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:223 -msgid "" -"Finally, every distribution must provide the ``namespace_packages`` argument " -"to :func:`~setuptools.setup` in :file:`setup.py`. For example:" -msgstr "" - -#: ../source/guides/packaging-namespace-packages.rst:237 -msgid "" -"A complete working example of two pkg_resources-style namespace packages can " -"be found in the `pkg_resources namespace example project`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:3 -msgid "" -"Publishing package distribution releases using GitHub Actions CI/CD workflows" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:5 -msgid "" -"`GitHub Actions CI/CD`_ allows you to run a series of commands whenever an " -"event occurs on the GitHub platform. One popular choice is having a workflow " -"that's triggered by a ``push`` event. This guide shows you how to publish a " -"Python distribution whenever a tagged commit is pushed. It will use the " -"`pypa/gh-action-pypi-publish GitHub Action`_." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:15 -msgid "" -"This guide *assumes* that you already have a project that you know how to " -"build distributions for and *it lives on GitHub*." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:19 -msgid "Saving credentials on GitHub" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:21 -msgid "" -"In this guide, we'll demonstrate uploading to both PyPI and TestPyPI, " -"meaning that we'll have two separate sets of credentials. And we'll need to " -"save them in the GitHub repository settings." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:26 -msgid "Let's begin! 🚀" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:28 -msgid "" -"Go to https://pypi.org/manage/account/#api-tokens and create a new `API " -"token`_. If you have the project on PyPI already, limit the token scope to " -"just that project. You can call it something like ``GitHub Actions CI/CD — " -"project-org/project-repo`` in order for it to be easily distinguishable in " -"the token list. **Don't close the page just yet — you won't see that token " -"again.**" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:37 -msgid "" -"In a separate browser tab or window, go to the ``Settings`` tab of your " -"target repository and then click on `Secrets`_ in the left sidebar." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:40 -msgid "" -"Create a new secret called ``PYPI_API_TOKEN`` and copy-paste the token from " -"the first step." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:42 -msgid "" -"Now, go to https://test.pypi.org/manage/account/#api-tokens and repeat the " -"steps. Save that TestPyPI token on GitHub as ``TEST_PYPI_API_TOKEN``." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:48 -msgid "" -"If you don't have a TestPyPI account, you'll need to create it. It's not the " -"same as a regular PyPI account." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:53 -msgid "Creating a workflow definition" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:55 -msgid "" -"GitHub CI/CD workflows are declared in YAML files stored in the ``.github/" -"workflows/`` directory of your repository." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:58 -msgid "Let's create a ``.github/workflows/publish-to-test-pypi.yml`` file." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:61 -msgid "" -"Start it with a meaningful name and define the event that should make GitHub " -"run this workflow:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:70 -msgid "Defining a workflow job environment" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:72 -msgid "" -"Now, let's add initial setup for our job. It's a process that will execute " -"commands that we'll define later. In this guide, we'll use Ubuntu 18.04:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:83 -msgid "Checking out the project and building distributions" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:85 -msgid "Then, add the following under the ``build-n-publish`` section:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 -msgid "" -"This will download your repository into the CI runner and then install and " -"activate Python 3.7." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 -msgid "" -"And now we can build dists from source. In this example, we'll use ``build`` " -"package, assuming that your project has a ``pyproject.toml`` properly set up " -"(see :pep:`517`/:pep:`518`)." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:102 -msgid "" -"You can use any other method for building distributions as long as it " -"produces ready-to-upload artifacts saved into the ``dist/`` folder." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:106 -msgid "So add this to the steps list:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:115 -msgid "Publishing the distribution to PyPI and TestPyPI" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:117 -msgid "Finally, add the following steps at the end:" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:123 -msgid "" -"These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the " -"first one uploads contents of the ``dist/`` folder into TestPyPI " -"unconditionally and the second does that to PyPI, but only if the current " -"commit is tagged." -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:130 -msgid "That's all, folks!" -msgstr "" - -#: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:132 -msgid "" -"Now, whenever you push a tagged commit to your Git repository remote on " -"GitHub, this workflow will publish it to PyPI. And it'll publish any push to " -"TestPyPI which is useful for providing test builds to your alpha users as " -"well as making sure that your release pipeline remains healthy!" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:5 -msgid "Single-sourcing the package version" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:8 -msgid "" -"There are many techniques to maintain a single source of truth for the " -"version number of your project:" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:11 -msgid "" -"Read the file in :file:`setup.py` and get the version. Example (from `pip " -"setup.py `_)::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:38 -msgid "" -"As of the release of setuptools 46.4.0, one can accomplish the same thing by " -"instead placing the following in the project's ``setup.cfg`` file (replacing " -"\"package\" with the import name of the package):" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:47 -msgid "" -"Earlier versions of setuptools implemented the ``attr:`` directive by " -"importing the module, but setuptools 46.4.0 added rudimentary AST analysis " -"so that ``attr:`` can function without having to import any of the package's " -"dependencies." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:52 -msgid "" -"Also, please be aware that declarative config indicators, including the " -"``attr:`` directive, are not supported in parameters to ``setup.py``." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:55 -msgid "" -"Use an external build tool that either manages updating both locations, or " -"offers an API that both locations can use." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:58 -msgid "" -"Few tools you could use, in no particular order, and not necessarily " -"complete: `bump2version `_, `changes " -"`_, `commitizen `_, `zest.releaser `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:65 -msgid "" -"Set the value to a ``__version__`` global variable in a dedicated module in " -"your project (e.g. :file:`version.py`), then have :file:`setup.py` read and " -"``exec`` the value into a variable." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:76 -msgid "" -"Example using this technique: `warehouse `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:78 -msgid "" -"Place the value in a simple ``VERSION`` text file and have both :file:`setup." -"py` and the project code read it." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:86 -msgid "" -"An advantage with this technique is that it's not specific to Python. Any " -"tool can read the version." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:91 -msgid "" -"With this approach you must make sure that the ``VERSION`` file is included " -"in all your source and binary distributions (e.g. add ``include VERSION`` to " -"your :file:`MANIFEST.in`)." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:95 -msgid "" -"Set the value in :file:`setup.py`, and have the project code use the " -"``importlib.metadata`` API to fetch the value at runtime. (``importlib." -"metadata`` was introduced in Python 3.8 and is available to older versions " -"as the ``importlib-metadata`` project.) An installed project's version can " -"be fetched with the API as follows::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:110 -msgid "" -"Be aware that the ``importlib.metadata`` API only knows about what's in the " -"installation metadata, which is not necessarily the code that's currently " -"imported." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:114 -msgid "" -"If a project uses this method to fetch its version at runtime, then its " -"``install_requires`` value needs to be edited to install ``importlib-" -"metadata`` on pre-3.8 versions of Python like so::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:128 -msgid "" -"An older (and less efficient) alternative to ``importlib.metadata`` is the " -"``pkg_resources`` API provided by ``setuptools``::" -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:134 -msgid "" -"If a project uses ``pkg_resources`` to fetch its own version at runtime, " -"then ``setuptools`` must be added to the project's ``install_requires`` list." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:138 -msgid "" -"Example using this technique: `setuptools `_." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:141 -msgid "" -"Set the value to ``__version__`` in ``sample/__init__.py`` and import " -"``sample`` in :file:`setup.py`." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:155 -msgid "" -"Although this technique is common, beware that it will fail if ``sample/" -"__init__.py`` imports packages from ``install_requires`` dependencies, which " -"will very likely not be installed yet when :file:`setup.py` is run." -msgstr "" - -#: ../source/guides/single-sourcing-package-version.rst:161 -msgid "" -"Keep the version number in the tags of a version control system (Git, " -"Mercurial, etc) instead of in the code, and automatically extract it from " -"there using `setuptools_scm `_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:5 -msgid "Supporting multiple Python versions" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:37 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:43 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:49 -msgid "Automated testing and continuous integration" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:51 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:56 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:60 -msgid "" -"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:" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:66 -msgid "" -"`Travis CI `_ provides both a Linux and a macOS " -"environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit " -"while the macOS is 10.9.2 at the time of writing." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:69 -msgid "" -"`Appveyor `_ provides a Windows environment " -"(Windows Server 2012)." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:80 -msgid "" -"Both `Travis CI`_ 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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:85 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:89 -msgid "Tools for single-source Python packages" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:91 -msgid "" -"`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_." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:100 -msgid "" -"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" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:107 -msgid "a Python 2 (by syntax) module in a Python 3 project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:108 -msgid "a Python 3 (by syntax) module in a *Python 2* project." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:110 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:117 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:124 -msgid "What's in which Python?" -msgstr "" - -#: ../source/guides/supporting-multiple-python-versions.rst:126 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:3 -msgid "Supporting Windows using Appveyor" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:6 -msgid "2015-12-03" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:8 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:20 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:24 -msgid "" -"The Appveyor service is a continuous integration service, much like the " -"better-known `Travis`_ service that is commonly used for testing by projects " -"hosted on `Github`_. However, unlike Travis, the build workers on Appveyor " -"are Windows hosts and have the necessary compilers installed to build Python " -"extensions." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:30 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:38 -msgid "Setting up" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:40 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:45 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:49 -msgid "" -"Once you have set up your Appveyor account and added your project, Appveyor " -"will automatically build your project each time a commit occurs. This " -"behaviour will be familiar to users of Travis." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:54 -msgid "Adding Appveyor support to your project" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:56 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:61 -msgid "" -"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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:69 -msgid "appveyor.yml" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:75 -msgid "" -"This file can be downloaded from `here `__." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:77 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:80 -msgid "" -"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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:88 -msgid "" -"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``)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:94 -msgid "" -"The ``build`` section simply switches off builds - there is no build step " -"needed for Python, unlike languages like ``C#``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:97 -msgid "" -"The main sections that will need to be tailored to your project are " -"``test_script`` and ``after_test``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:100 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:109 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:114 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:119 -msgid "Support script" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:121 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:126 -msgid "" -"`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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:133 -msgid "" -"You can simply download the batch file and include it in your project " -"unchanged." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:137 -msgid "Access to the built wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:139 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:147 -msgid "Additional notes" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:150 -msgid "Testing with tox" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:152 -msgid "" -"Many projects use the `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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:156 -msgid "" -"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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:160 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:165 -msgid "" -"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" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:170 -msgid "``DISTUTILS_USE_SDK``" -msgstr "``DISTUTILS_USE_SDK``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:171 -msgid "``MSSdk``" -msgstr "``MSSdk``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:172 -msgid "``INCLUDE``" -msgstr "``INCLUDE``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:173 -msgid "``LIB``" -msgstr "``LIB``" - -#: ../source/guides/supporting-windows-using-appveyor.rst:175 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:181 -msgid "" -"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 Travis or 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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:188 -msgid "" -"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``." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:192 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:197 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:203 -msgid "Automatically uploading wheels" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:205 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:210 -msgid "" -"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)." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:216 -msgid "External dependencies" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:218 -msgid "" -"The supplied scripts will successfully build any distribution that does not " -"rely on 3rd party external libraries for the build." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:221 -msgid "" -"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." -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:230 -msgid "Support scripts" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:232 -msgid "For reference, the SDK setup support script is listed here:" -msgstr "" - -#: ../source/guides/supporting-windows-using-appveyor.rst:234 -msgid "``appveyor-sample/build.cmd``" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:5 -msgid "Tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:7 -msgid "" -"If you're familiar with Python packaging and installation, and just want to " -"know what tools are currently recommended, then here it is." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:12 -msgid "Application dependency management" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:14 -msgid "" -"Use :ref:`pipenv` to manage library dependencies when developing Python " -"applications. See :doc:`../tutorials/managing-dependencies` for more details " -"on using ``pipenv``." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:18 -msgid "When ``pipenv`` does not meet your use case, consider other tools like:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:20 -msgid ":ref:`pip`" -msgstr ":ref:`pip`" - -#: ../source/guides/tool-recommendations.rst:22 -msgid "`pip-tools `_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:24 -msgid "`Poetry `_" -msgstr "`Poetry `_" - -#: ../source/guides/tool-recommendations.rst:27 -msgid "Installation tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:29 -msgid "" -"Use :ref:`pip` to install Python :term:`packages ` " -"from :term:`PyPI `. [1]_ [2]_ Depending on how :" -"ref:`pip` is installed, you may need to also install :ref:`wheel` to get the " -"benefit of wheel caching. [3]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:34 -msgid "" -"Use :ref:`virtualenv`, or `venv`_ to isolate application specific " -"dependencies from a shared Python installation. [4]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:37 -msgid "" -"If you're looking for management of fully integrated cross-platform software " -"stacks, consider:" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:40 -msgid ":ref:`buildout`: primarily focused on the web development community" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:42 -msgid "" -":ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused on the " -"scientific community." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:47 -msgid "Packaging tool recommendations" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:49 -msgid "" -"Use :ref:`setuptools` to define projects and create :term:`Source " -"Distributions `. [5]_ [6]_" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:52 -msgid "" -"Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:" -"`wheel project ` to create :term:`wheels `. This is " -"especially beneficial, if your project contains binary extensions." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:56 -msgid "" -"Use `twine `_ for uploading distributions " -"to :term:`PyPI `." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:61 -msgid "Publishing platform migration" -msgstr "" - -#: ../source/guides/tool-recommendations.rst:63 -msgid "" -"The original Python Package Index implementation (previously hosted at `pypi." -"python.org `_) has been phased out in favour of an " -"updated implementation hosted at `pypi.org `_." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:67 -msgid "" -"See :ref:`Migrating to PyPI.org` for more information on the status of the " -"migration, and what settings to change in your clients." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:72 -msgid "" -"There are some cases where you might choose to use ``easy_install`` (from :" -"ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` " -"(which pip doesn't support). For a detailed breakdown, see :ref:`pip vs " -"easy_install`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:77 -msgid "" -"The acceptance of :pep:`453` means that :ref:`pip` will be available by " -"default in most installations of Python 3.4 or later. See the :pep:" -"`rationale section <453#rationale>` from :pep:`453` as for why pip was " -"chosen." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:82 -msgid "" -"`get-pip.py `_ and :ref:" -"`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv " -"` do not currently. Also, the common \"python-pip\" package that's " -"found in various linux distros, does not depend on \"python-wheel\" " -"currently." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:88 -msgid "" -"Beginning with Python 3.4, ``venv`` will create virtualenv environments with " -"``pip`` installed, thereby making it an equal alternative to :ref:" -"`virtualenv`. However, using :ref:`virtualenv` will still be recommended for " -"users that need cross-version consistency." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:93 -msgid "" -"Although you can use pure ``distutils`` for many projects, it does not " -"support defining dependencies on other projects and is missing several " -"convenience utilities for automatically populating distribution metadata " -"correctly that are provided by ``setuptools``. Being outside the standard " -"library, ``setuptools`` also offers a more consistent feature set across " -"different versions of Python, and (unlike ``distutils``), recent versions of " -"``setuptools`` support all of the modern metadata fields described in :ref:" -"`core-metadata`." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:102 -msgid "" -"Even for projects that do choose to use ``distutils``, when :ref:`pip` " -"installs such projects directly from source (rather than installing from a " -"prebuilt :term:`wheel ` file), it will actually build your project " -"using :ref:`setuptools` instead." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:107 -msgid "" -"`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` " -"in June 2013, thereby making setuptools the default choice for packaging." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:5 -msgid "Including files in source distributions with ``MANIFEST.in``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:7 -msgid "" -"When building a :term:`source distribution ` for your package, by default only a minimal set of files are " -"included. You may find yourself wanting to include extra files in the " -"source distribution, such as an authors/contributors file, a :file:`docs/` " -"directory, or a directory of data files used for testing purposes. There " -"may even be extra files that you *need* to include; for example, if your :" -"file:`setup.py` computes your project's ``long_description`` by reading from " -"both a README and a changelog file, you'll need to include both those files " -"in the sdist so that people that build or install from the sdist get the " -"correct results." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:17 -msgid "" -"Adding & removing files to & from the source distribution is done by writing " -"a :file:`MANIFEST.in` file at the project root." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:22 -msgid "How files are included in an sdist" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:24 -msgid "The following files are included in a source distribution by default:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:26 -msgid "" -"all Python source files implied by the ``py_modules`` and ``packages`` " -"``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:28 -msgid "" -"all C source files mentioned in the ``ext_modules`` or ``libraries`` " -"``setup()`` arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:30 -msgid "scripts specified by the ``scripts`` ``setup()`` argument" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:31 -msgid "" -"all files specified by the ``package_data`` and ``data_files`` ``setup()`` " -"arguments" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:33 -msgid "" -"the file specified by the ``license_file`` option in :file:`setup.cfg` " -"(setuptools 40.8.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:35 -msgid "" -"all files specified by the ``license_files`` option in :file:`setup.cfg` " -"(setuptools 42.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:37 -msgid "all files matching the pattern :file:`test/test*.py`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:38 -msgid ":file:`setup.py` (or whatever you called your setup script)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:39 -msgid ":file:`setup.cfg`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:40 -msgid ":file:`README`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:41 -msgid ":file:`README.txt`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:42 -msgid ":file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:43 -msgid ":file:`README.md` (setuptools 36.4.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:44 -msgid ":file:`pyproject.toml` (setuptools 43.0.0+)" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:45 -msgid ":file:`MANIFEST.in`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:47 -msgid "" -"After adding the above files to the sdist, the commands in :file:`MANIFEST." -"in` (if such a file exists) are executed in order to add and remove further " -"files to & from the sdist. Default files can even be removed from the sdist " -"with the appropriate :file:`MANIFEST.in` command." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:52 -msgid "" -"After processing the :file:`MANIFEST.in` file, setuptools removes the :file:" -"`build/` directory as well as any directories named :file:`RCS`, :file:" -"`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO` file " -"and an :file:`*.egg-info` directory. This behavior cannot be changed with :" -"file:`MANIFEST.in`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:60 -msgid ":file:`MANIFEST.in` commands" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:62 -msgid "" -"A :file:`MANIFEST.in` file consists of commands, one per line, instructing " -"setuptools to add or remove some set of files from the sdist. The commands " -"are:" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:67 -msgid "Command" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:69 -msgid ":samp:`include {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:69 -msgid "Add all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid ":samp:`exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:70 -msgid "Remove all files matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid ":samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:71 -msgid "" -"Add all files under directories matching ``dir-pattern`` that match any of " -"the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid ":samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:72 -msgid "" -"Remove all files under directories matching ``dir-pattern`` that match any " -"of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid ":samp:`global-include {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:73 -msgid "" -"Add all files anywhere in the source tree matching any of the listed patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid ":samp:`global-exclude {pat1} {pat2} ...`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:74 -msgid "" -"Remove all files anywhere in the source tree matching any of the listed " -"patterns" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid ":samp:`graft {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:75 -msgid "Add all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid ":samp:`prune {dir-pattern}`" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:76 -msgid "Remove all files under directories matching ``dir-pattern``" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:79 -msgid "" -"The patterns here are glob-style patterns: ``*`` matches zero or more " -"regular filename characters (on Unix, everything except forward slash; on " -"Windows, everything except backslash and colon); ``?`` matches a single " -"regular filename character, and ``[chars]`` matches any one of the " -"characters between the square brackets (which may contain character ranges, " -"e.g., ``[a-z]`` or ``[a-fA-F0-9]``). Setuptools also has undocumented " -"support for ``**`` matching zero or more characters including forward slash, " -"backslash, and colon." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:87 -msgid "" -"Directory patterns are relative to the root of the project directory; e.g., " -"``graft example*`` will include a directory named :file:`examples` in the " -"project root but will not include :file:`docs/examples/`." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:91 -msgid "" -"File & directory names in :file:`MANIFEST.in` should be ``/``-separated; " -"setuptools will automatically convert the slashes to the local platform's " -"appropriate directory separator." -msgstr "" - -#: ../source/guides/using-manifest-in.rst:95 -msgid "" -"Commands are processed in the order they appear in the :file:`MANIFEST.in` " -"file. For example, given the commands::" -msgstr "" - -#: ../source/guides/using-manifest-in.rst:101 -msgid "" -"the contents of the directory tree :file:`tests` will first be added to the " -"sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, " -"or ``.pyd`` extension will be removed from the sdist. If the commands were " -"in the opposite order, then ``*.pyc`` files etc. would be only be removed " -"from what was already in the sdist before adding :file:`tests`, and if :file:" -"`tests` happened to contain any ``*.pyc`` files, they would end up included " -"in the sdist because the exclusion happened before they were included." -msgstr "" - -#: ../source/guides/using-testpypi.rst:7 -msgid "" -"``TestPyPI`` is a separate instance of the :term:`Python Package Index " -"(PyPI)` that allows you to try out the distribution tools and process " -"without worrying about affecting the real index. TestPyPI is hosted at `test." -"pypi.org `_" -msgstr "" - -#: ../source/guides/using-testpypi.rst:13 -msgid "Registering your account" -msgstr "" - -#: ../source/guides/using-testpypi.rst:15 -msgid "" -"Because TestPyPI has a separate database from the live PyPI, you'll need a " -"separate user account for specifically for TestPyPI. Go to https://test.pypi." -"org/account/register/ to register your account." -msgstr "" - -#: ../source/guides/using-testpypi.rst:19 -msgid "" -"The database for TestPyPI may be periodically pruned, so it is not unusual " -"for user accounts to be deleted." -msgstr "" - -#: ../source/guides/using-testpypi.rst:24 -msgid "Using TestPyPI with Twine" -msgstr "" - -#: ../source/guides/using-testpypi.rst:26 -msgid "" -"You can upload your distributions to TestPyPI using :ref:`twine` by " -"specifying the ``--repository`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:33 -msgid "" -"You can see if your package has successfully uploaded by navigating to the " -"URL ``https://test.pypi.org/project/`` where " -"``sampleproject`` is the name of your project that you uploaded. It may take " -"a minute or two for your project to appear on the site." -msgstr "" - -#: ../source/guides/using-testpypi.rst:39 -msgid "Using TestPyPI with pip" -msgstr "" - -#: ../source/guides/using-testpypi.rst:41 -msgid "" -"You can tell pip to download packages from TestPyPI instead of PyPI by " -"specifying the ``--index-url`` flag" -msgstr "" - -#: ../source/guides/using-testpypi.rst:56 -msgid "" -"If you want to allow pip to also pull other packages from PyPI you can " -"specify ``--extra-index-url`` to point to PyPI. This is useful when the " -"package you're testing has dependencies:" -msgstr "" - -#: ../source/guides/using-testpypi.rst:73 -msgid "Setting up TestPyPI in :file:`.pypirc`" -msgstr "" - -#: ../source/guides/using-testpypi.rst:75 -msgid "" -"If you want to avoid entering your username, you can configure TestPyPI in " -"your :file:`$HOME/.pypirc`:" -msgstr "" - -#: ../source/index.rst:3 ../source/key_projects.rst:181 -msgid "Python Packaging User Guide" -msgstr "" - -#: ../source/index.rst:5 -msgid "" -"The Python Packaging User Guide (PyPUG) is a collection of tutorials and " -"guides for packaging Python software." -msgstr "" - -#: ../source/index.rst:5 -msgid "python, packaging, guide, tutorial" -msgstr "" - -#: ../source/index.rst:24 -msgid "" -"Welcome to the *Python Packaging User Guide*, a collection of tutorials and " -"references to help you distribute and install Python packages with modern " -"tools." -msgstr "" - -#: ../source/index.rst:28 -msgid "" -"This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. " -"We happily accept any :doc:`contributions and feedback `. 😊" -msgstr "" - -#: ../source/index.rst:36 -msgid "Get started" -msgstr "" - -#: ../source/index.rst:38 -msgid "" -"Essential tools and concepts for working within the Python development " -"ecosystem are covered in our :doc:`tutorials/index` section:" -msgstr "" - -#: ../source/index.rst:41 -msgid "" -"To learn how to install packages, see the :doc:`tutorial on installing " -"packages `" -msgstr "" - -#: ../source/index.rst:43 -msgid "" -"To learn how to manage dependencies in a version controlled project, see " -"the :doc:`tutorial on managing application dependencies `" -msgstr "" - -#: ../source/index.rst:45 -msgid "" -"To learn how to package and distribute your projects, see the :doc:`tutorial " -"on packaging and distributing `" -msgstr "" - -#: ../source/index.rst:47 -msgid "" -"To get an overview of packaging options for Python libraries and " -"applications, see the :doc:`Overview of Python Packaging `" -msgstr "" - -#: ../source/index.rst:52 -msgid "Learn more" -msgstr "" - -#: ../source/index.rst:54 -msgid "" -"Beyond our :doc:`tutorials/index`, this guide has several other resources:" -msgstr "" - -#: ../source/index.rst:56 -msgid "" -"The :doc:`guides/index` section for walk throughs, such as :doc:`guides/" -"installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`." -msgstr "" - -#: ../source/index.rst:58 -msgid "" -"The :doc:`discussions/index` section for in-depth references on topics such " -"as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-" -"vs-easy-install`." -msgstr "" - -#: ../source/index.rst:60 -msgid "" -"The :doc:`specifications/index` section for packaging interoperability " -"specifications." -msgstr "" - -#: ../source/index.rst:62 -msgid "" -"Additionally, there is a list of :doc:`other projects ` " -"maintained by members of the Python Packaging Authority." -msgstr "" - -#: ../source/key_projects.rst:6 -msgid "Project Summaries" -msgstr "" - -#: ../source/key_projects.rst:8 -msgid "" -"Summaries and links for the most relevant projects in the space of Python " -"installation and packaging." -msgstr "" - -#: ../source/key_projects.rst:14 -msgid "PyPA Projects" -msgstr "" - -#: ../source/key_projects.rst:19 -msgid "bandersnatch" -msgstr "" - -#: ../source/key_projects.rst:21 -msgid "" -"`Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:25 -msgid "" -"``bandersnatch`` is a PyPI mirroring client designed to efficiently create a " -"complete mirror of the contents of PyPI. Organizations thus save bandwidth " -"and latency on package downloads (especially in the context of automated " -"tests) and to prevent heavily loading PyPI's Content Delivery Network (CDN)." -msgstr "" - -#: ../source/key_projects.rst:35 -msgid "build" -msgstr "" - -#: ../source/key_projects.rst:37 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI " -"`__" -msgstr "" - -#: ../source/key_projects.rst:42 -msgid "" -"``build`` is a :pep:`517` compatible Python package builder. It provides a " -"CLI to build packages, as well as a Python API." -msgstr "" - -#: ../source/key_projects.rst:49 -msgid "cibuildwheel" -msgstr "" - -#: ../source/key_projects.rst:51 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__ | " -"`Discussions `__ | " -"`Discord #cibuildwheel `__" -msgstr "" - -#: ../source/key_projects.rst:58 -msgid "" -"``cibuildwheel`` is a Python package that builds :term:`wheels ` for " -"all common platforms and Python versions on most CI systems. Also see :ref:" -"`multibuild`." -msgstr "" - -#: ../source/key_projects.rst:64 -msgid "distlib" -msgstr "" - -#: ../source/key_projects.rst:66 -msgid "" -"`Docs `__ | `Issues `__ | `Bitbucket `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:71 -msgid "" -"``distlib`` is a library which implements low-level functions that relate to " -"packaging and distribution of Python software. ``distlib`` implements " -"several relevant PEPs (Python Enhancement Proposal standards) and is useful " -"for developers of third-party packaging tools to make and upload binary and " -"source :term:`distributions `, achieve " -"interoperability, resolve dependencies, manage package resources, and do " -"other similar functions." -msgstr "" - -#: ../source/key_projects.rst:80 -msgid "" -"Unlike the stricter :ref:`packaging` project (below), which specifically " -"implements modern Python packaging interoperability standards, ``distlib`` " -"also attempts to provide reasonable fallback behaviours when asked to handle " -"legacy packages and metadata that predate the modern interoperability " -"standards and fall into the subset of packages that are incompatible with " -"those standards." -msgstr "" - -#: ../source/key_projects.rst:90 -msgid "packaging" -msgstr "" - -#: ../source/key_projects.rst:92 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:97 -msgid "" -"Core utilities for Python packaging used by :ref:`pip` and :ref:`setuptools`." -msgstr "" - -#: ../source/key_projects.rst:99 -msgid "" -"The core utilities in the packaging library handle version handling, " -"specifiers, markers, requirements, tags, and similar attributes and tasks " -"for Python packages. Most Python users rely on this library without needing " -"to explicitly call it; developers of the other Python packaging, " -"distribution, and installation tools listed here often use its functionality " -"to parse, discover, and otherwise handle dependency attributes." -msgstr "" - -#: ../source/key_projects.rst:107 -msgid "" -"This project specifically focuses on implementing the modern Python " -"packaging interoperability standards defined at :ref:`packaging-" -"specifications`, and will report errors for sufficiently old legacy packages " -"that are incompatible with those standards. In contrast, the :ref:`distlib` " -"project is a more permissive library that attempts to provide a plausible " -"reading of ambiguous metadata in cases where :ref:`packaging` will instead " -"report on error." -msgstr "" - -#: ../source/key_projects.rst:119 -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "pip" -msgstr "" - -#: ../source/key_projects.rst:121 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:126 -msgid "" -"The most popular tool for installing Python packages, and the one included " -"with modern versions of Python." -msgstr "" - -#: ../source/key_projects.rst:129 -msgid "" -"It provides the essential core features for finding, downloading, and " -"installing packages from PyPI and other Python package indexes, and can be " -"incorporated into a wide range of development workflows via its command-line " -"interface (CLI)." -msgstr "" - -#: ../source/key_projects.rst:137 -msgid "Pipenv" -msgstr "" - -#: ../source/key_projects.rst:139 -msgid "" -"`Docs `__ | `Source `__ | `Issues `__ | `PyPI " -"`__" -msgstr "" - -#: ../source/key_projects.rst:144 -msgid "" -"Pipenv is a project that aims to bring the best of all packaging worlds to " -"the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:" -"`virtualenv` into one single toolchain. It features very pretty terminal " -"colors." -msgstr "" - -#: ../source/key_projects.rst:148 -msgid "" -"Pipenv aims to help users manage environments, dependencies, and imported " -"packages on the command line. It also works well on Windows (which other " -"tools often underserve), makes and checkes file hashes, to ensure compliance " -"with hash-locked dependency specifiers, and eases uninstallation of packages " -"and dependencies. It is used by Python users and system administrators, but " -"has been less maintained since late 2018." -msgstr "" - -#: ../source/key_projects.rst:159 -msgid "Pipfile" -msgstr "" - -#: ../source/key_projects.rst:161 -msgid "`Source `__" -msgstr "" - -#: ../source/key_projects.rst:163 -msgid "" -":file:`Pipfile` and its sister :file:`Pipfile.lock` are a higher-level " -"application-centric alternative to :ref:`pip`'s lower-level :file:" -"`requirements.txt` file." -msgstr "" - -#: ../source/key_projects.rst:170 -msgid "pipx" -msgstr "" - -#: ../source/key_projects.rst:172 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:176 -msgid "" -"pipx is a tool to install and run Python command-line applications without " -"causing dependency conflicts with other packages installed on the system." -msgstr "" - -#: ../source/key_projects.rst:183 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:187 -msgid "This guide!" -msgstr "" - -#: ../source/key_projects.rst:192 -msgid "readme_renderer" -msgstr "" - -#: ../source/key_projects.rst:194 -msgid "" -"`GitHub and docs `__ | `PyPI " -"`__" -msgstr "" - -#: ../source/key_projects.rst:197 -msgid "" -"``readme_renderer`` is a library that package developers use to render their " -"user documentation (README) files into HTML from markup languages such as " -"Markdown or reStructuredText. Developers call it on its own or via :ref:" -"`twine`, as part of their release management process, to check that their " -"package descriptions will properly display on PyPI." -msgstr "" - -#: ../source/key_projects.rst:208 -msgid "setuptools" -msgstr "" - -#: ../source/key_projects.rst:210 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:215 -msgid "" -"setuptools (which includes ``easy_install``) is a collection of enhancements " -"to the Python distutils that allow you to more easily build and distribute " -"Python :term:`distributions `, especially ones that " -"have dependencies on other packages." -msgstr "" - -#: ../source/key_projects.rst:220 -msgid "" -"`distribute`_ was a fork of setuptools that was merged back into setuptools " -"(in v0.7), thereby making setuptools the primary choice for Python packaging." -msgstr "" - -#: ../source/key_projects.rst:227 -msgid "trove-classifiers" -msgstr "" - -#: ../source/key_projects.rst:229 -msgid "" -"`Issues `__ | `GitHub " -"`__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:233 -msgid "" -"trove-classifiers is the canonical source for `classifiers on PyPI `_, which project maintainers use to `systematically " -"describe their projects `_ so that users can better find projects " -"that match their needs on the PyPI." -msgstr "" - -#: ../source/key_projects.rst:239 -msgid "" -"The trove-classifiers package contains a list of valid classifiers and " -"deprecated classifiers (which are paired with the classifiers that replace " -"them). Use this package to validate classifiers used in packages intended " -"for uploading to PyPI. As this list of classifiers is published as code, you " -"can install and import it, giving you a more convenient workflow compared to " -"referring to the `list published on PyPI `_. " -"The `issue tracker `_ for " -"the project hosts discussions on proposed classifiers and requests for new " -"classifiers." -msgstr "" - -#: ../source/key_projects.rst:253 -msgid "twine" -msgstr "" - -#: ../source/key_projects.rst:255 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:260 -msgid "" -"Twine is the primary tool developers use to upload packages to the Python " -"Package Index or other Python package indexes. It is a command-line program " -"that passes program files and metadata to a web API. Developers use it " -"because it's the official PyPI upload tool, it's fast and secure, it's " -"maintained, and it reliably works." -msgstr "" - -#: ../source/key_projects.rst:270 ../source/overview.rst:415 -msgid "virtualenv" -msgstr "" - -#: ../source/key_projects.rst:272 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:277 -msgid "" -"virtualenv is a tool which uses the command-line path environment variable " -"to create isolated Python :term:`Virtual Environments `, much as :ref:`venv` does. virtualenv provides additional " -"functionality, compared to :ref:`venv`, by supporting Python 2.7 and by " -"providing convenient features for configuring, maintaining, duplicating, and " -"troubleshooting the virtual environments. For more information, see the " -"section on :ref:`Creating and using Virtual Environments`." -msgstr "" - -#: ../source/key_projects.rst:290 -msgid "Warehouse" -msgstr "" - -#: ../source/key_projects.rst:292 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:296 -msgid "" -"The current codebase powering the :term:`Python Package Index (PyPI)`. It is " -"hosted at `pypi.org `_. The default source for :ref:`pip` " -"downloads." -msgstr "" - -#: ../source/key_projects.rst:304 -msgid "wheel" -msgstr "" - -#: ../source/key_projects.rst:306 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:311 -msgid "" -"Primarily, the wheel project offers the ``bdist_wheel`` :ref:`setuptools` " -"extension for creating :term:`wheel distributions `. Additionally, " -"it offers its own command line utility for creating and installing wheels." -msgstr "" - -#: ../source/key_projects.rst:315 -msgid "" -"See also `auditwheel `__, a tool that " -"package developers use to check and fix Python packages they are making in " -"the binary wheel format. It provides functionality to discover dependencies, " -"check metadata for compliance, and repair the wheel and metadata to properly " -"link and include external shared libraries in a package." -msgstr "" - -#: ../source/key_projects.rst:324 -msgid "Non-PyPA Projects" -msgstr "" - -#: ../source/key_projects.rst:329 -msgid "bento" -msgstr "" - -#: ../source/key_projects.rst:331 -msgid "" -"`Docs `__ | `Issues `__ | `GitHub `__ | " -"`PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:336 -msgid "" -"Bento is a packaging tool solution for Python software, targeted as an " -"alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's " -"philosophy is reproducibility, extensibility and simplicity (in that order)." -msgstr "" - -#: ../source/key_projects.rst:344 -msgid "buildout" -msgstr "" - -#: ../source/key_projects.rst:346 -msgid "" -"`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:351 -msgid "" -"Buildout is a Python-based build system for creating, assembling and " -"deploying applications from multiple parts, some of which may be non-Python-" -"based. It lets you create a buildout configuration and reproduce the same " -"software later." -msgstr "" - -#: ../source/key_projects.rst:358 -msgid "conda" -msgstr "" - -#: ../source/key_projects.rst:360 -msgid "`Docs `__" -msgstr "" - -#: ../source/key_projects.rst:362 -msgid "" -"conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution " -"from `Anaconda, Inc `__ specifically " -"aimed at the scientific community, and in particular on Windows where the " -"installation of binary extensions is often difficult." -msgstr "" - -#: ../source/key_projects.rst:369 -msgid "" -"Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, " -"but provides many of their combined features in terms of package management, " -"virtual environment management and deployment of binary extensions." -msgstr "" - -#: ../source/key_projects.rst:373 -msgid "" -"Conda does not install packages from PyPI and can install only from the " -"official Anaconda repositories, or anaconda.org (a place for user-" -"contributed *conda* packages), or a local (e.g. intranet) package server. " -"However, note that :ref:`pip` can be installed into, and work side-by-side " -"with conda for managing :term:`distributions ` from " -"PyPI. Also, `conda skeleton `__ is a tool to make " -"Python packages installable by conda by first fetching them from PyPI and " -"modifying their metadata." -msgstr "" - -#: ../source/key_projects.rst:386 -msgid "devpi" -msgstr "" - -#: ../source/key_projects.rst:388 -msgid "" -"`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:392 -msgid "" -"devpi features a powerful PyPI-compatible server and PyPI proxy cache with a " -"complementary command line tool to drive packaging, testing and release " -"activities with Python. devpi also provides a browsable and searchable web " -"interface." -msgstr "" - -#: ../source/key_projects.rst:401 -msgid "flit" -msgstr "" - -#: ../source/key_projects.rst:403 -msgid "" -"`Docs `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:407 -msgid "" -"Flit provides a simple way to upload pure Python packages and modules to " -"PyPI. It focuses on `making the easy things easy `_ for " -"packaging. Flit can generate a configuration file to quickly set up a simple " -"project, build source distributions and wheels, and upload them to PyPI." -msgstr "" - -#: ../source/key_projects.rst:412 -msgid "" -"Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on " -"tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to " -"upload them to PyPI. Flit requires Python 3, but you can use it to " -"distribute modules for Python 2, so long as they can be imported on Python 3." -msgstr "" - -#: ../source/key_projects.rst:422 -msgid "enscons" -msgstr "" - -#: ../source/key_projects.rst:424 -msgid "" -"`Source `__ | `Issues `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:428 -msgid "" -"Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-" -"compatible source distributions and wheels without using distutils or " -"setuptools, including distributions with C extensions. Enscons has a " -"different architecture and philosophy than :ref:`distutils`. Rather than " -"adding build features to a Python packaging system, enscons adds Python " -"packaging to a general purpose build system. Enscons helps you to build " -"sdists that can be automatically built by :ref:`pip`, and wheels that are " -"independent of enscons." -msgstr "" - -#: ../source/key_projects.rst:443 -msgid "Hashdist" -msgstr "" - -#: ../source/key_projects.rst:445 -msgid "" -"`Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:448 -msgid "" -"Hashdist is a library for building non-root software distributions. Hashdist " -"is trying to be “the Debian of choice for cases where Debian technology " -"doesn’t work”. The best way for Pythonistas to think about Hashdist may be a " -"more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed " -"at solving the problem of installing scientific software, and making package " -"distribution stateless, cached, and branchable. It is used by some " -"researchers but has been lacking in maintenance since 2016." -msgstr "" - -#: ../source/key_projects.rst:460 -msgid "hatch" -msgstr "" - -#: ../source/key_projects.rst:462 -msgid "" -"`GitHub and Docs `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:465 -msgid "" -"Hatch is a unified command-line tool meant to conveniently manage " -"dependencies and environment isolation for Python developers. Python package " -"developers use Hatch to configure, version, specify dependencies for, and " -"publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload " -"packages to PyPI, and :ref:`pip` to download and install packages." -msgstr "" - -#: ../source/key_projects.rst:475 -msgid "multibuild" -msgstr "" - -#: ../source/key_projects.rst:477 -msgid "`GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:479 -msgid "" -"Multibuild is a set of CI scripts for building and testing Python :term:" -"`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :" -"ref:`cibuildwheel`." -msgstr "" - -#: ../source/key_projects.rst:485 -msgid "pex" -msgstr "" - -#: ../source/key_projects.rst:487 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:491 -msgid "" -"pex is both a library and tool for generating :file:`.pex` (Python " -"EXecutable) files, standalone Python environments in the spirit of :ref:" -"`virtualenv`. :file:`.pex` files are just carefully constructed zip files " -"with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are " -"designed to make deployment of Python applications as simple as ``cp``." -msgstr "" - -#: ../source/key_projects.rst:500 -msgid "pip-tools" -msgstr "" - -#: ../source/key_projects.rst:502 -msgid "" -"`GitHub and Docs `__ | `PyPI " -"`__" -msgstr "" - -#: ../source/key_projects.rst:505 -msgid "" -"pip-tools is a suite of tools meant for Python system administrators and " -"release managers who particularly want to keep their builds deterministic " -"yet stay up to date with new versions of their dependencies. Users can " -"specify particular release of their dependencies via hash, conveniently make " -"a properly formatted list of requirements from information in other parts of " -"their program, update all dependencies (a feature :ref:`pip` currently does " -"not provide), and create layers of constraints for the program to obey." -msgstr "" - -#: ../source/key_projects.rst:517 -msgid "piwheels" -msgstr "" - -#: ../source/key_projects.rst:519 -msgid "" -"`Website `__ | `Docs `__ | `GitHub `__" -msgstr "" - -#: ../source/key_projects.rst:523 -msgid "" -"piwheels is a website, and software underpinning it, that fetches source " -"code distribution packages from PyPI and compiles them into binary wheels " -"that are optimized for installation onto Raspberry Pi computers. Raspberry " -"Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." -msgstr "" - -#: ../source/key_projects.rst:532 -msgid "poetry" -msgstr "" - -#: ../source/key_projects.rst:534 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:538 -msgid "" -"poetry is a command-line tool to handle dependency installation and " -"isolation as well as building and packaging of Python packages. It uses " -"``pyproject.toml`` and, instead of depending on the resolver functionality " -"within :ref:`pip`, provides its own dependency resolver. It attempts to " -"speed users' experience of installation and dependency resolution by locally " -"caching metadata about dependencies." -msgstr "" - -#: ../source/key_projects.rst:548 -msgid "pypiserver" -msgstr "" - -#: ../source/key_projects.rst:550 -msgid "" -"`Docs `__ | " -"`GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:554 -msgid "" -"pypiserver is a minimalist application that serves as a private Python " -"package index within organizations, implementing a simple API and browser " -"interface. You can upload private packages using standard upload tools, and " -"users can download and install them with :ref:`pip`, without publishing them " -"publicly. Organizations who use pypiserver usually download packages both " -"from pypiserver and from PyPI." -msgstr "" - -#: ../source/key_projects.rst:564 -msgid "scikit-build" -msgstr "" - -#: ../source/key_projects.rst:566 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:570 -msgid "" -"Scikit-build is an improved build system generator for CPython C/C++/Fortran/" -"Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :" -"ref:`pip`. It internally uses `cmake `__ " -"(available on PyPI) to provide better support for additional compilers, " -"build systems, cross compilation, and locating dependencies and their " -"associated build requirements. To speed up and parallelize the build of " -"large projects, the user can install `ninja `__ (also available on PyPI)." -msgstr "" - -#: ../source/key_projects.rst:582 -msgid "shiv" -msgstr "" - -#: ../source/key_projects.rst:584 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:588 -msgid "" -"shiv is a command line utility for building fully self contained Python " -"zipapps as outlined in :pep:`441`, but with all their dependencies included. " -"Its primary goal is making distributing Python applications and command line " -"tools fast & easy." -msgstr "" - -#: ../source/key_projects.rst:598 -msgid "" -"`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" -msgstr "" - -#: ../source/key_projects.rst:603 -msgid "" -"A flexible package manager designed to support multiple versions, " -"configurations, platforms, and compilers. Spack is like Homebrew, but " -"packages are written in Python and parameterized to allow easy swapping of " -"compilers, library versions, build options, etc. Arbitrarily many versions " -"of packages can coexist on the same system. Spack was designed for rapidly " -"building high performance scientific applications on clusters and " -"supercomputers." -msgstr "" - -#: ../source/key_projects.rst:611 -msgid "" -"Spack is not in PyPI (yet), but it requires no installation and can be used " -"immediately after cloning from GitHub." -msgstr "" - -#: ../source/key_projects.rst:617 -msgid "zest.releaser" -msgstr "" - -#: ../source/key_projects.rst:619 -msgid "" -"`Docs `__ | `GitHub `__ | `PyPI `__" -msgstr "" - -#: ../source/key_projects.rst:623 -msgid "" -"``zest.releaser`` is a Python package release tool providing an abstraction " -"layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to " -"automate incrementing package version numbers, updating changelogs, tagging " -"releases in source control, and uploading new packages to PyPI." -msgstr "" - -#: ../source/key_projects.rst:630 -msgid "Standard Library Projects" -msgstr "" - -#: ../source/key_projects.rst:635 -msgid "ensurepip" -msgstr "" - -#: ../source/key_projects.rst:637 -msgid "" -"`Docs `__ | `Issues " -"`__" -msgstr "" - -#: ../source/key_projects.rst:640 -msgid "" -"A package in the Python Standard Library that provides support for " -"bootstrapping :ref:`pip` into an existing Python installation or virtual " -"environment. In most cases, end users won't use this module, but rather it " -"will be used during the build of the Python distribution." -msgstr "" - -#: ../source/key_projects.rst:649 -msgid "distutils" -msgstr "" - -#: ../source/key_projects.rst:651 -msgid "" -"`Docs `__ | `Issues " -"`__" -msgstr "" - -#: ../source/key_projects.rst:654 -msgid "" -"The original Python packaging system, added to the standard library in " -"Python 2.0." -msgstr "" - -#: ../source/key_projects.rst:657 -msgid "" -"Due to the challenges of maintaining a packaging system where feature " -"updates are tightly coupled to language runtime updates, direct usage of :" -"ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being " -"the preferred replacement. :ref:`Setuptools` not only provides features that " -"plain :ref:`distutils` doesn't offer (such as dependency declarations and " -"entry point declarations), it also provides a consistent build interface and " -"feature set across all supported Python versions." -msgstr "" - -#: ../source/key_projects.rst:670 -msgid "venv" -msgstr "" - -#: ../source/key_projects.rst:672 -msgid "" -"`Docs `__ | `Issues `__" -msgstr "" - -#: ../source/key_projects.rst:675 -msgid "" -"A package in the Python Standard Library (starting with Python 3.3) for " -"creating :term:`Virtual Environments `. For more " -"information, see the section on :ref:`Creating and using Virtual " -"Environments`." -msgstr "" - -#: ../source/news.rst:2 -msgid "News" -msgstr "" - -#: ../source/news.rst:5 -msgid "September 2019" -msgstr "" - -#: ../source/news.rst:6 -msgid "Added a guide about publishing dists via GitHub Actions. (:pr:`647`)" -msgstr "" - -#: ../source/news.rst:9 -msgid "August 2019" -msgstr "" - -#: ../source/news.rst:10 -msgid "Updated to use :file:`python3 -m` when installing pipx. (:pr:`631`)" -msgstr "" - -#: ../source/news.rst:13 -msgid "July 2019" -msgstr "" - -#: ../source/news.rst:14 -msgid "Marked all PEP numbers with the :pep: role. (:pr:`629`)" -msgstr "" - -#: ../source/news.rst:15 -msgid "Upgraded Sphinx version and removed pypa.io intersphinx. (:pr:`625`)" -msgstr "" - -#: ../source/news.rst:16 -msgid "Mentioned :file:`find_namespace_packages`. (:pr:`622`)" -msgstr "" - -#: ../source/news.rst:17 -msgid "Updated directory layout examples for consistency. (:pr:`611`)" -msgstr "" - -#: ../source/news.rst:18 -msgid "Updated Bandersnatch link to GitHub. (:pr:`623`)" -msgstr "" - -#: ../source/news.rst:21 -msgid "June 2019" -msgstr "" - -#: ../source/news.rst:22 -msgid "Fixed some typos. (:pr:`620`)" -msgstr "" - -#: ../source/news.rst:25 -msgid "May 2019" -msgstr "" - -#: ../source/news.rst:26 -msgid "Added :file:`python_requires` usage to packaging tutorial. (:pr:`613`)" -msgstr "" - -#: ../source/news.rst:27 -msgid "Added a MANIFEST.in guide page. (:pr:`609`)" -msgstr "" - -#: ../source/news.rst:30 -msgid "April 2019" -msgstr "" - -#: ../source/news.rst:31 -msgid "" -"Added a mention for :file:`shiv` in the key projects section. (:pr:`608`)" -msgstr "" - -#: ../source/news.rst:32 -msgid "Reduced emphasis on virtualenv. (:pr:`606`)" -msgstr "" - -#: ../source/news.rst:35 -msgid "March 2019" -msgstr "" - -#: ../source/news.rst:36 -msgid "Moved single-sourcing guide version option to Python 3. (:pr:`605`)" -msgstr "" - -#: ../source/news.rst:37 -msgid "Covered RTD details for contributing. (:pr:`600`)" -msgstr "" - -#: ../source/news.rst:40 -msgid "February 2019" -msgstr "" - -#: ../source/news.rst:41 -msgid "" -"Elaborate upon the differences between the tutorial and the real packaging " -"process. (:pr:`602`)" -msgstr "" - -#: ../source/news.rst:42 -msgid "Added instructions to install Python CLI applications. (:pr:`594`)" -msgstr "" - -#: ../source/news.rst:45 -msgid "January 2019" -msgstr "" - -#: ../source/news.rst:46 -msgid "Added :file:`--no-deps` to the packaging tutorial. (:pr:`593`)" -msgstr "" - -#: ../source/news.rst:47 -msgid "Updated Sphinx and Nox. (:pr:`591`)" -msgstr "" - -#: ../source/news.rst:48 -msgid "Referenced Twine from Python3. (:pr:`581`)" -msgstr "" - -#: ../source/news.rst:51 -msgid "December 2018" -msgstr "" - -#: ../source/news.rst:52 -msgid "No programmers in the office!" -msgstr "" - -#: ../source/news.rst:55 -msgid "November 2018" -msgstr "" - -#: ../source/news.rst:56 -msgid "Removed landing page link to PyPI migration guide. (:pr:`575`)" -msgstr "" - -#: ../source/news.rst:57 -msgid "Changed bumpversion to bump2version. (:pr:`572`)" -msgstr "" - -#: ../source/news.rst:58 -msgid "Added single-sourcing package version example. (:pr:`573`)" -msgstr "" - -#: ../source/news.rst:59 -msgid "Added a guide for creating documentation. (:pr:`568`)" -msgstr "" - -#: ../source/news.rst:62 -msgid "October 2018" -msgstr "" - -#: ../source/news.rst:63 -msgid "Updated Nox package name. (:pr:`566`)" -msgstr "" - -#: ../source/news.rst:64 -msgid "Mentioned Sphinx extensions in guides. (:pr:`562`)" -msgstr "" - -#: ../source/news.rst:67 -msgid "September 2018" -msgstr "" - -#: ../source/news.rst:68 -msgid "Added a section on checking RST markup. (:pr:`554`)" -msgstr "" - -#: ../source/news.rst:69 -msgid "Updated user installs page. (:pr:`558`)" -msgstr "" - -#: ../source/news.rst:70 -msgid "Updated Google BigQuery urls. (:pr:`556`)" -msgstr "" - -#: ../source/news.rst:71 -msgid "Replaced tar command with working command. (:pr:`552`)" -msgstr "" - -#: ../source/news.rst:72 -msgid "" -"Changed to double quotes in the pip install SomeProject==1.4. (:pr:`550`)" -msgstr "" - -#: ../source/news.rst:75 -msgid "August 2018" -msgstr "" - -#: ../source/news.rst:76 -msgid "Removed the recommendation to store passwords in cleartext. (:pr:`546`)" -msgstr "" - -#: ../source/news.rst:77 -msgid "" -"Moved the Overview to a task based lead in along with the others. (:pr:`540`)" -msgstr "" - -#: ../source/news.rst:78 -msgid "Updated Python version supported by virtualenv. (:pr:`538`)" -msgstr "" - -#: ../source/news.rst:79 -msgid "Added outline/rough draft of new Overview page. (:pr:`519`)" -msgstr "" - -#: ../source/news.rst:82 -msgid "July 2018" -msgstr "" - -#: ../source/news.rst:84 -msgid "Improved binary extension docs. (:pr:`531`)" -msgstr "" - -#: ../source/news.rst:85 -msgid "Added scikit-build to key projects. (:pr:`530`)" -msgstr "" - -#: ../source/news.rst:88 -msgid "June 2018" -msgstr "" - -#: ../source/news.rst:90 -msgid "Fixed categories of interop PEP for pypa.io. (:pr:`527`)" -msgstr "" - -#: ../source/news.rst:91 -msgid "Updated Markdown descriptions explanation. (:pr:`522`)" -msgstr "" - -#: ../source/news.rst:94 -msgid "May 2018" -msgstr "" - -#: ../source/news.rst:96 -msgid "Noted issues with Provides-Dist and Obsoletes-Dist. (:pr:`513`)" -msgstr "" - -#: ../source/news.rst:97 -msgid "" -"Removed outdated warning about Python version mixing with Pipenv. (:pr:`501`)" -msgstr "" - -#: ../source/news.rst:98 -msgid "Simplified packaging tutorial. (:pr:`498`)" -msgstr "" - -#: ../source/news.rst:99 -msgid "Updated Windows users instructions for clarity. (:pr:`493`)" -msgstr "" - -#: ../source/news.rst:100 -msgid "Updated the license section description for completeness. (:pr:`492`)" -msgstr "" - -#: ../source/news.rst:101 -msgid "Added specification-style document to contributing section. (:pr:`489`)" -msgstr "" - -#: ../source/news.rst:102 -msgid "Added documentation types to contributing guide. (:pr:`485`)" -msgstr "" - -#: ../source/news.rst:105 -msgid "April 2018" -msgstr "" - -#: ../source/news.rst:107 -msgid "Added README guide. (:pr:`461`)" -msgstr "" - -#: ../source/news.rst:108 -msgid "Updated instructions and status for PyPI launch. (:pr:`475`)" -msgstr "" - -#: ../source/news.rst:109 -msgid "Added instructions for Warehouse. (:pr:`471`)" -msgstr "" - -#: ../source/news.rst:110 -msgid "Removed GPG references from publishing tutorial. (:pr:`466`)" -msgstr "" - -#: ../source/news.rst:111 -msgid "Added 'What’s in which Python 3.4–3.6?'. (:pr:`468`)" -msgstr "" - -#: ../source/news.rst:112 -msgid "Added a guide for phasing out Python versions. (:pr:`459`)" -msgstr "" - -#: ../source/news.rst:113 -msgid "Made default Description-Content-Type variant GFM. (:pr:`462`)" -msgstr "" - -#: ../source/news.rst:116 -msgid "March 2018" -msgstr "" - -#: ../source/news.rst:118 -msgid "Updated \"installing scientific packages\". (:pr:`455`)" -msgstr "" - -#: ../source/news.rst:119 -msgid "" -"Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)" -msgstr "" - -#: ../source/news.rst:120 -msgid "Clarified a long description classifier on pypi.org. (:pr:`456`)" -msgstr "" - -#: ../source/news.rst:121 -msgid "Updated Core Metadata spec to follw PEP 556. (:pr:`412`)" -msgstr "" - -#: ../source/news.rst:124 -msgid "February 2018" -msgstr "" - -#: ../source/news.rst:126 -msgid "" -"Added python3-venv and python3-pip to Debian installation instructions. (:pr:" -"`445`)" -msgstr "" - -#: ../source/news.rst:127 -msgid "Updated PyPI migration info. (:pr:`439`)" -msgstr "" - -#: ../source/news.rst:128 -msgid "" -"Added a warning about managing multiple versions with pipenv. (:pr:`430`)" -msgstr "" - -#: ../source/news.rst:129 -msgid "Added example of multiple emails to Core Metadata. (:pr:`429`)" -msgstr "" - -#: ../source/news.rst:130 -msgid "Added explanation of \"legacy\" in test.pypi.org/legacy. (:pr:`426`)" -msgstr "" - -#: ../source/news.rst:133 -msgid "January 2018" -msgstr "" - -#: ../source/news.rst:135 -msgid "Added a link to PyPI's list of classifiers. (:pr:`425`)" -msgstr "" - -#: ../source/news.rst:136 -msgid "Updated README.rst explanation. (:pr:`419`)" -msgstr "" - -#: ../source/news.rst:139 -msgid "December 2017" -msgstr "" - -#: ../source/news.rst:141 -msgid "" -"Replaced :file:`~` with :file:`$HOME` in guides and tutorials. (:pr:`418`)" -msgstr "" - -#: ../source/news.rst:142 -msgid "Noted which fields can be used with environment markers. (:pr:`416`)" -msgstr "" - -#: ../source/news.rst:143 -msgid "Updated Requires-Python section. (:pr:`414`)" -msgstr "" - -#: ../source/news.rst:144 -msgid "Added news page. (:pr:`404`)" -msgstr "" - -#: ../source/news.rst:147 -msgid "November 2017" -msgstr "" - -#: ../source/news.rst:149 -msgid "" -"Introduced a new dependency management tutorial based on Pipenv. (:pr:`402`)" -msgstr "" - -#: ../source/news.rst:150 -msgid "" -"Updated the *Single Sourcing Package Version* tutorial to reflect pip's " -"current strategy. (:pr:`400`)" -msgstr "" - -#: ../source/news.rst:152 -msgid "" -"Added documentation about the ``py_modules`` argument to ``setup``. (:pr:" -"`398`)" -msgstr "" - -#: ../source/news.rst:153 -msgid "Simplified the wording for the :file:`manifest.in` section. (:pr:`395`)" -msgstr "" - -#: ../source/news.rst:156 -msgid "October 2017" -msgstr "" - -#: ../source/news.rst:158 -msgid "" -"Added a specification for the :file:`entry_points.txt` file. (:pr:`398`)" -msgstr "" - -#: ../source/news.rst:159 -msgid "" -"Created a new guide for managing packages using ``pip`` and ``virtualenv``. " -"(:pr:`385`)" -msgstr "" - -#: ../source/news.rst:160 -msgid "Split the specifications page into multiple pages. (:pr:`386`)" -msgstr "" - -#: ../source/news.rst:163 -msgid "September 2017" -msgstr "" - -#: ../source/news.rst:165 -msgid "" -"Encouraged using ``readme_renderer`` to validate :file:`README.rst`. (:pr:" -"`379`)" -msgstr "" - -#: ../source/news.rst:167 -msgid "Recommended using the ``--user-base`` option. (:pr:`374`)" -msgstr "" - -#: ../source/news.rst:170 -msgid "August 2017" -msgstr "" - -#: ../source/news.rst:172 -msgid "" -"Added a new, experimental tutorial on installing packages using ``Pipenv``. " -"(:pr:`369`)" -msgstr "" - -#: ../source/news.rst:173 -msgid "Added a new guide on how to use ``TestPyPI``. (:pr:`366`)" -msgstr "" - -#: ../source/news.rst:174 -msgid "Added :file:`pypi.org` as a term. (:pr:`365`)" -msgstr "" - -#: ../source/news.rst:177 -msgid "July 2017" -msgstr "" - -#: ../source/news.rst:179 -msgid "Added ``flit`` to the key projects list. (:pr:`358`)" -msgstr "" - -#: ../source/news.rst:180 -msgid "Added ``enscons`` to the list of key projects. (:pr:`357`)" -msgstr "" - -#: ../source/news.rst:181 -msgid "" -"Updated this guide's ``readme`` with instructions on how to build the guide " -"locally. (:pr:`356`)" -msgstr "" - -#: ../source/news.rst:182 -msgid "" -"Made the new ``TestPyPI`` URL more visible, adding note to homepage about " -"pypi.org. (:pr:`354`)" -msgstr "" - -#: ../source/news.rst:183 -msgid "" -"Added a note about the removal of the explicit registration API. (:pr:`347`)" -msgstr "" - -#: ../source/news.rst:186 -msgid "June 2017" -msgstr "" - -#: ../source/news.rst:188 -msgid "Added a document on migrating uploads to :file:`PyPI.org`. (:pr:`339`)" -msgstr "" - -#: ../source/news.rst:189 -msgid "Added documentation for ``python_requires``. (:pr:`338`)" -msgstr "" - -#: ../source/news.rst:190 -msgid "" -"Added a note about PyPI migration in the *Tool Recommendations* tutorial. (:" -"pr:`335`)" -msgstr "" - -#: ../source/news.rst:191 -msgid "" -"Added a note that :file:`manifest.in` does not affect wheels. (:pr:`332`)" -msgstr "" - -#: ../source/news.rst:192 -msgid "Added a license section to the distributing guide. (:pr:`331`)" -msgstr "" - -#: ../source/news.rst:193 -msgid "Expanded the section on the ``name`` argument. (:pr:`329`)" -msgstr "" - -#: ../source/news.rst:194 -msgid "Adjusted the landing page. (:pr:`327`, :pr:`326`, :pr:`324`)" -msgstr "" - -#: ../source/news.rst:195 -msgid "Updated to Sphinx 1.6.2. (:pr:`323`)" -msgstr "" - -#: ../source/news.rst:196 -msgid "Switched to the PyPA theme. (:pr:`305`)" -msgstr "" - -#: ../source/news.rst:197 -msgid "Re-organized the documentation into the new structure. (:pr:`318`)" -msgstr "" - -#: ../source/news.rst:200 -msgid "May 2017" -msgstr "" - -#: ../source/news.rst:202 -msgid "" -"Added documentation for the ``Description-Content-Type`` field. (:pr:`258`)" -msgstr "" - -#: ../source/news.rst:203 -msgid "Added contributor and style guide. (:pr:`307`)" -msgstr "" - -#: ../source/news.rst:204 -msgid "" -"Documented ``pip`` and ``easy_install``'s differences for per-project " -"indexes. (:pr:`233`)" -msgstr "" - -#: ../source/news.rst:207 -msgid "April 2017" -msgstr "" - -#: ../source/news.rst:209 -msgid "Added travis configuration for testing pull requests. (:pr:`300`)" -msgstr "" - -#: ../source/news.rst:210 -msgid "" -"Mentioned the requirement of the ``wheel`` package for creating wheels (:pr:" -"`299`)" -msgstr "" - -#: ../source/news.rst:211 -msgid "" -"Removed the ``twine register`` reference in the *Distributing Packages* " -"tutorial. (:pr:`271`)" -msgstr "" - -#: ../source/news.rst:212 -msgid "Added a topic on plugin discovery. (:pr:`294`, :pr:`296`)" -msgstr "" - -#: ../source/news.rst:213 -msgid "Added a topic on namespace packages. (:pr:`290`)" -msgstr "" - -#: ../source/news.rst:214 -msgid "" -"Added documentation explaining prominently how to install ``pip`` in ``/usr/" -"local``. (:pr:`230`)" -msgstr "" - -#: ../source/news.rst:215 -msgid "" -"Updated development mode documentation to mention that order of local " -"packages matters. (:pr:`208`)" -msgstr "" - -#: ../source/news.rst:216 -msgid "" -"Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted " -"projects (:pr:`239`)" -msgstr "" - -#: ../source/news.rst:217 -msgid "" -"Swaped order of :file:`setup.py` arguments for the upload command, as order " -"is significant. (:pr:`260`)" -msgstr "" - -#: ../source/news.rst:219 -msgid "" -"Explained how to install from unsupported sources using a helper " -"application. (:pr:`289`)" -msgstr "" - -#: ../source/news.rst:223 -msgid "March 2017" -msgstr "" - -#: ../source/news.rst:225 -msgid "Covered ``manylinux1`` in *Platform Wheels*. (:pr:`283`)" -msgstr "" - -#: ../source/news.rst:228 -msgid "February 2017" -msgstr "" - -#: ../source/news.rst:230 -msgid "Added :pep:`518`. (:pr:`281`)" -msgstr "" - -#: ../source/overview.rst:3 -msgid "An Overview of Packaging for Python" -msgstr "" - -#: ../source/overview.rst:7 -msgid "" -"As a general-purpose programming language, Python is designed to be used in " -"many ways. You can build web sites or industrial robots or a game for your " -"friends to play, and much more, all using the same core technology." -msgstr "" - -#: ../source/overview.rst:12 -msgid "" -"Python's flexibility is why the first step in every Python project must be " -"to think about the project's audience and the corresponding environment " -"where the project will run. It might seem strange to think about packaging " -"before writing code, but this process does wonders for avoiding future " -"headaches." -msgstr "" - -#: ../source/overview.rst:18 -msgid "" -"This overview provides a general-purpose decision tree for reasoning about " -"Python's plethora of packaging options. Read on to choose the best " -"technology for your next project." -msgstr "" - -#: ../source/overview.rst:26 -msgid "Thinking about deployment" -msgstr "" - -#: ../source/overview.rst:28 -msgid "" -"Packages exist to be installed (or *deployed*), so before you package " -"anything, you'll want to have some answers to the deployment questions below:" -msgstr "" - -#: ../source/overview.rst:32 -msgid "" -"Who are your software's users? Will your software be installed by other " -"developers doing software development, operations people in a datacenter, or " -"a less software-savvy group?" -msgstr "" - -#: ../source/overview.rst:35 -msgid "" -"Is your software intended to run on servers, desktops, mobile clients " -"(phones, tablets, etc.), or embedded in dedicated devices?" -msgstr "" - -#: ../source/overview.rst:37 -msgid "" -"Is your software installed individually, or in large deployment batches?" -msgstr "" - -#: ../source/overview.rst:39 -msgid "" -"Packaging is all about target environment and deployment experience. There " -"are many answers to the questions above and each combination of " -"circumstances has its own solutions. With this information, the following " -"overview will guide you to the packaging technologies best suited to your " -"project." -msgstr "" - -#: ../source/overview.rst:46 -msgid "Packaging Python libraries and tools" -msgstr "" - -#: ../source/overview.rst:48 -msgid "" -"You may have heard about PyPI, ``setup.py``, and ``wheel`` files. These are " -"just a few of the tools Python's ecosystem provides for distributing Python " -"code to developers, which you can read about in :doc:`guides/distributing-" -"packages-using-setuptools`." -msgstr "" - -#: ../source/overview.rst:53 -msgid "" -"The following approaches to packaging are meant for libraries and tools used " -"by technical audience in a development setting. If you're looking for ways " -"to package Python for a non-technical audience and/or a production setting, " -"skip ahead to :ref:`packaging-applications`." -msgstr "" - -#: ../source/overview.rst:59 -msgid "Python modules" -msgstr "" - -#: ../source/overview.rst:61 -msgid "" -"A Python file, provided it only relies on the standard library, can be " -"redistributed and reused. You will also need to ensure it's written for the " -"right version of Python, and only relies on the standard library." -msgstr "" - -#: ../source/overview.rst:66 -msgid "" -"This is great for sharing simple scripts and snippets between people who " -"both have compatible Python versions (such as via email, StackOverflow, or " -"GitHub gists). There are even some entire Python libraries that offer this " -"as an option, such as `bottle.py `_ and " -"`boltons `_." -msgstr "" - -#: ../source/overview.rst:73 -msgid "" -"However, this pattern won't scale for projects that consist of multiple " -"files, need additional libraries, or need a specific version of Python, " -"hence the options below." -msgstr "" - -#: ../source/overview.rst:78 -msgid "Python source distributions" -msgstr "" - -#: ../source/overview.rst:80 -msgid "" -"If your code consists of multiple Python files, it's usually organized into " -"a directory structure. Any directory containing Python files can comprise " -"an :term:`Import Package`." -msgstr "" - -#: ../source/overview.rst:84 -msgid "" -"Because packages consist of multiple files, they are harder to distribute. " -"Most protocols support transferring only one file at a time (when was the " -"last time you clicked a link and it downloaded multiple files?). It's easier " -"to get incomplete transfers, and harder to guarantee code integrity at the " -"destination." -msgstr "" - -#: ../source/overview.rst:90 -msgid "" -"So long as your code contains nothing but pure Python code, and you know " -"your deployment environment supports your version of Python, then you can " -"use Python's native packaging tools to create a *source* :term:`Distribution " -"Package`, or *sdist* for short." -msgstr "" - -#: ../source/overview.rst:95 -msgid "" -"Python's *sdists* are compressed archives (``.tar.gz`` files) containing one " -"or more packages or modules. If your code is pure-Python, and you only " -"depend on other Python packages, you can `go here to learn more `_." -msgstr "" - -#: ../source/overview.rst:100 -msgid "" -"If you rely on any non-Python code, or non-Python packages (such as `libxml2 " -"`_ in the case of `lxml `_, or BLAS libraries in the case of `numpy `_), you will need to use the format detailed in the next " -"section, which also has many advantages for pure-Python libraries." -msgstr "" - -#: ../source/overview.rst:107 -msgid "" -"Python and PyPI support multiple distributions providing different " -"implementations of the same package. For instance the unmaintained-but-" -"seminal `PIL distribution `_ provides the PIL " -"package, and so does `Pillow `_, an " -"actively-maintained fork of PIL!" -msgstr "" - -#: ../source/overview.rst:114 -msgid "" -"This Python packaging superpower makes it possible for Pillow to be a drop-" -"in replacement for PIL, just by changing your project's ``install_requires`` " -"or ``requirements.txt``." -msgstr "" - -#: ../source/overview.rst:119 -msgid "Python binary distributions" -msgstr "" - -#: ../source/overview.rst:121 -msgid "" -"So much of Python's practical power comes from its ability to integrate with " -"the software ecosystem, in particular libraries written in C, C++, Fortran, " -"Rust, and other languages." -msgstr "" - -#: ../source/overview.rst:125 -msgid "" -"Not all developers have the right tools or experiences to build these " -"components written in these compiled languages, so Python created the :term:" -"`Wheel`, a package format designed to ship libraries with compiled " -"artifacts. In fact, Python's package installer, ``pip``, always prefers " -"wheels because installation is always faster, so even pure-Python packages " -"work better with wheels." -msgstr "" - -#: ../source/overview.rst:132 -msgid "" -"Binary distributions are best when they come with source distributions to " -"match. Even if you don't upload wheels of your code for every operating " -"system, by uploading the sdist, you're enabling users of other platforms to " -"still build it for themselves. Default to publishing both sdist and wheel " -"archives together, *unless* you're creating artifacts for a very specific " -"use case where you know the recipient only needs one or the other." -msgstr "" - -#: ../source/overview.rst:140 -msgid "" -"Python and PyPI make it easy to upload both wheels and sdists together. Just " -"follow the :doc:`tutorials/packaging-projects` tutorial." -msgstr "" - -#: ../source/overview.rst:148 -msgid "" -"Python's recommended built-in library and tool packaging technologies. " -"Excerpted from `The Packaging Gradient (2017) `_." -msgstr "" - -#: ../source/overview.rst:155 -msgid "Packaging Python applications" -msgstr "" - -#: ../source/overview.rst:157 -msgid "" -"So far we've only discussed Python's native distribution tools. Based on our " -"introduction, you would be correct to infer these built-in approaches only " -"target environments which have Python, and an audience who knows how to " -"install Python packages." -msgstr "" - -#: ../source/overview.rst:162 -msgid "" -"With the variety of operating systems, configurations, and people out there, " -"this assumption is only safe when targeting a developer audience." -msgstr "" - -#: ../source/overview.rst:166 -msgid "" -"Python's native packaging is mostly built for distributing reusable code, " -"called libraries, between developers. You can piggyback **tools**, or basic " -"applications for developers, on top of Python's library packaging, using " -"technologies like `setuptools entry_points `_." -msgstr "" - -#: ../source/overview.rst:172 -msgid "" -"Libraries are building blocks, not complete applications. For distributing " -"applications, there's a whole new world of technologies out there." -msgstr "" - -#: ../source/overview.rst:176 -msgid "" -"The next few sections organize these application packaging options according " -"to their dependencies on the target environment, so you can choose the right " -"one for your project." -msgstr "" - -#: ../source/overview.rst:181 -msgid "Depending on a framework" -msgstr "" - -#: ../source/overview.rst:183 -msgid "" -"Some types of Python applications, like web site backends and other network " -"services, are common enough that they have frameworks to enable their " -"development and packaging. Other types of applications, like dynamic web " -"frontends and mobile clients, are complex enough to target that a framework " -"becomes more than a convenience." -msgstr "" - -#: ../source/overview.rst:189 -msgid "" -"In all these cases, it makes sense to work backwards, from the framework's " -"packaging and deployment story. Some frameworks include a deployment system " -"which wraps the technologies outlined in the rest of the guide. In these " -"cases, you'll want to defer to your framework's packaging guide for the " -"easiest and most reliable production experience." -msgstr "" - -#: ../source/overview.rst:195 -msgid "" -"If you ever wonder how these platforms and frameworks work under the hood, " -"you can always read the sections beyond." -msgstr "" - -#: ../source/overview.rst:199 -msgid "Service platforms" -msgstr "" - -#: ../source/overview.rst:201 -msgid "" -"If you're developing for a \"Platform-as-a-Service\" or \"PaaS\" like Heroku " -"or Google App Engine, you are going to want to follow their respective " -"packaging guides." -msgstr "" - -#: ../source/overview.rst:205 -msgid "" -"`Heroku `_" -msgstr "" - -#: ../source/overview.rst:206 -msgid "`Google App Engine `_" -msgstr "" - -#: ../source/overview.rst:207 -msgid "`PythonAnywhere `_" -msgstr "" - -#: ../source/overview.rst:208 -msgid "`OpenShift `_" -msgstr "" - -#: ../source/overview.rst:209 -msgid "\"Serverless\" frameworks like `Zappa `_" -msgstr "" - -#: ../source/overview.rst:211 -msgid "" -"In all these setups, the platform takes care of packaging and deployment, as " -"long as you follow their patterns. Most software does not fit one of these " -"templates, hence the existence of all the other options below." -msgstr "" - -#: ../source/overview.rst:216 -msgid "" -"If you're developing software that will be deployed to machines you own, " -"users' personal computers, or any other arrangement, read on." -msgstr "" - -#: ../source/overview.rst:220 -msgid "Web browsers and mobile applications" -msgstr "" - -#: ../source/overview.rst:222 -msgid "" -"Python's steady advances are leading it into new spaces. These days you can " -"write a mobile app or web application frontend in Python. While the language " -"may be familiar, the packaging and deployment practices are brand new." -msgstr "" - -#: ../source/overview.rst:227 -msgid "" -"If you're planning on releasing to these new frontiers, you'll want to check " -"out the following frameworks, and refer to their packaging guides:" -msgstr "" - -#: ../source/overview.rst:231 -msgid "`Kivy `_" -msgstr "" - -#: ../source/overview.rst:232 -msgid "`Beeware `_" -msgstr "" - -#: ../source/overview.rst:233 -msgid "`Brython `_" -msgstr "" - -#: ../source/overview.rst:234 -msgid "`Flexx `_" -msgstr "" - -#: ../source/overview.rst:236 -msgid "" -"If you are *not* interested in using a framework or platform, or just wonder " -"about some of the technologies and techniques utilized by the frameworks " -"above, continue reading below." -msgstr "" - -#: ../source/overview.rst:241 -msgid "Depending on a pre-installed Python" -msgstr "" - -#: ../source/overview.rst:243 -msgid "" -"Pick an arbitrary computer, and depending on the context, there's a very " -"good chance Python is already installed. Included by default in most Linux " -"and Mac operating systems for many years now, you can reasonably depend on " -"Python preexisting in your data centers or on the personal machines of " -"developers and data scientists." -msgstr "" - -#: ../source/overview.rst:249 -msgid "Technologies which support this model:" -msgstr "" - -#: ../source/overview.rst:251 -msgid "`PEX `_ (Python EXecutable)" -msgstr "" - -#: ../source/overview.rst:252 -msgid "" -"`zipapp `_ (does not help " -"manage dependencies, requires Python 3.5+)" -msgstr "" - -#: ../source/overview.rst:253 -msgid "`shiv `_ (requires Python 3)" -msgstr "" - -#: ../source/overview.rst:255 -msgid "" -"Of all the approaches here, depending on a pre-installed Python relies the " -"most on the target environment. Of course, this also makes for the smallest " -"package, as small as single-digit megabytes, or even kilobytes." -msgstr "" - -#: ../source/overview.rst:260 -msgid "" -"In general, decreasing the dependency on the target system increases the " -"size of our package, so the solutions here are roughly arranged by " -"increasing size of output." -msgstr "" - -#: ../source/overview.rst:267 -msgid "Depending on a separate software distribution ecosystem" -msgstr "" - -#: ../source/overview.rst:269 -msgid "" -"For a long time many operating systems, including Mac and Windows, lacked " -"built-in package management. Only recently did these OSes gain so-called " -"\"app stores\", but even those focus on consumer applications and offer " -"little for developers." -msgstr "" - -#: ../source/overview.rst:274 -msgid "" -"Developers long sought remedies, and in this struggle, emerged with their " -"own package management solutions, such as `Homebrew `_. " -"The most relevant alternative for Python developers is a package ecosystem " -"called `Anaconda `_. Anaconda is built around Python and is " -"increasingly common in academic, analytical, and other data-oriented " -"environments, even making its way `into server-oriented environments " -"`_." -msgstr "" - -#: ../source/overview.rst:284 -msgid "Instructions on building and publishing for the Anaconda ecosystem:" -msgstr "" - -#: ../source/overview.rst:286 -msgid "" -"`Building libraries and applications with conda `_" -msgstr "" - -#: ../source/overview.rst:287 -msgid "" -"`Transitioning a native Python package to Anaconda `_" -msgstr "" - -#: ../source/overview.rst:289 -msgid "" -"A similar model involves installing an alternative Python distribution, but " -"does not support arbitrary operating system-level packages:" -msgstr "" - -#: ../source/overview.rst:293 -msgid "`Enthought Canopy `_" -msgstr "" - -#: ../source/overview.rst:294 -msgid "`ActiveState ActivePython `_" -msgstr "" - -#: ../source/overview.rst:295 -msgid "`WinPython `_" -msgstr "" - -#: ../source/overview.rst:300 -msgid "Bringing your own Python executable" -msgstr "" - -#: ../source/overview.rst:302 -msgid "" -"Computing as we know it is defined by the ability to execute programs. Every " -"operating system natively supports one or more formats of program they can " -"natively execute." -msgstr "" - -#: ../source/overview.rst:306 -msgid "" -"There are many techniques and technologies which turn your Python program " -"into one of these formats, most of which involve embedding the Python " -"interpreter and any other dependencies into a single executable file." -msgstr "" - -#: ../source/overview.rst:311 -msgid "" -"This approach, called *freezing*, offers wide compatibility and seamless " -"user experience, though often requires multiple technologies, and a good " -"amount of effort." -msgstr "" - -#: ../source/overview.rst:315 -msgid "A selection of Python freezers:" -msgstr "" - -#: ../source/overview.rst:317 -msgid "`pyInstaller `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:318 -msgid "" -"`cx_Freeze `_ - Cross-platform" -msgstr "" - -#: ../source/overview.rst:319 -msgid "" -"`constructor `_ - For command-line " -"installers" -msgstr "" - -#: ../source/overview.rst:320 -msgid "`py2exe `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:321 -msgid "`py2app `_ - Mac only" -msgstr "" - -#: ../source/overview.rst:322 -msgid "" -"`bbFreeze `_ - Windows, Linux, Python 2 " -"only" -msgstr "" - -#: ../source/overview.rst:323 -msgid "`osnap `_ - Windows and Mac" -msgstr "" - -#: ../source/overview.rst:324 -msgid "`pynsist `_ - Windows only" -msgstr "" - -#: ../source/overview.rst:326 -msgid "" -"Most of the above imply single-user deployments. For multi-component server " -"applications, see `Chef Omnibus `_." -msgstr "" - -#: ../source/overview.rst:332 -msgid "Bringing your own userspace" -msgstr "" - -#: ../source/overview.rst:334 -msgid "" -"An increasing number of operating systems -- including Linux, Mac OS, and " -"Windows -- can be set up to run applications packaged as lightweight images, " -"using a relatively modern arrangement often referred to as `operating-system-" -"level virtualization `_, or *containerization*." -msgstr "" - -#: ../source/overview.rst:341 -msgid "" -"These techniques are mostly Python agnostic, because they package whole OS " -"filesystems, not just Python or Python packages." -msgstr "" - -#: ../source/overview.rst:344 -msgid "" -"Adoption is most extensive among Linux servers, where the technology " -"originated and where the technologies below work best:" -msgstr "" - -#: ../source/overview.rst:347 -msgid "`AppImage `_" -msgstr "" - -#: ../source/overview.rst:348 -msgid "`Docker `_" -msgstr "" - -#: ../source/overview.rst:349 -msgid "`Flatpak `_" -msgstr "" - -#: ../source/overview.rst:350 -msgid "`Snapcraft `_" -msgstr "" - -#: ../source/overview.rst:353 -msgid "Bringing your own kernel" -msgstr "" - -#: ../source/overview.rst:355 -msgid "" -"Most operating systems support some form of classical virtualization, " -"running applications packaged as images containing a full operating system " -"of their own. Running these virtual machines, or VMs, is a mature approach, " -"widespread in data center environments." -msgstr "" - -#: ../source/overview.rst:360 -msgid "" -"These techniques are mostly reserved for larger scale deployments in data " -"centers, though certain complex applications can benefit from this " -"packaging. Technologies are Python agnostic, and include:" -msgstr "" - -#: ../source/overview.rst:364 -msgid "`Vagrant `_" -msgstr "" - -#: ../source/overview.rst:365 -msgid "" -"`VHD `_, `AMI `_, and `other formats `_" -msgstr "" - -#: ../source/overview.rst:366 -msgid "" -"`OpenStack `_ - A cloud " -"management system in Python, with extensive VM support" -msgstr "" - -#: ../source/overview.rst:369 -msgid "Bringing your own hardware" -msgstr "" - -#: ../source/overview.rst:371 -msgid "" -"The most all-encompassing way to ship your software would be to ship it " -"already-installed on some hardware. This way, your software's user would " -"require only electricity." -msgstr "" - -#: ../source/overview.rst:375 -msgid "" -"Whereas the virtual machines described above are primarily reserved for the " -"tech-savvy, you can find hardware appliances being used by everyone from the " -"most advanced data centers to the youngest children." -msgstr "" - -#: ../source/overview.rst:379 -msgid "" -"Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the " -"datacenter or your users' homes. They plug and play, and you can call it a " -"day." -msgstr "" - -#: ../source/overview.rst:389 -msgid "" -"The simplified gamut of technologies used to package Python applications." -msgstr "" - -#: ../source/overview.rst:392 -msgid "What about..." -msgstr "" - -#: ../source/overview.rst:394 -msgid "" -"The sections above can only summarize so much, and you might be wondering " -"about some of the more conspicuous gaps." -msgstr "" - -#: ../source/overview.rst:398 -msgid "Operating system packages" -msgstr "" - -#: ../source/overview.rst:400 -msgid "" -"As mentioned in :ref:`depending-on-a-separate-ecosystem` above, some " -"operating systems have package managers of their own. If you're very sure of " -"the operating system you're targeting, you can depend directly on a format " -"like `deb `_ (for Debian, " -"Ubuntu, etc.) or `RPM `_ " -"(for Red Hat, Fedora, etc.), and use that built-in package manager to take " -"care of installation, and even deployment. You can even use `FPM `_ to generate both deb " -"and RPMs from the same source." -msgstr "" - -#: ../source/overview.rst:411 -msgid "" -"In most deployment pipelines, the OS package manager is just one piece of " -"the puzzle." -msgstr "" - -#: ../source/overview.rst:417 -msgid "" -"`Virtualenvs `_ have been an indispensable tool for multiple generations of Python " -"developer, but are slowly fading from view, as they are being wrapped by " -"higher-level tools. With packaging in particular, virtualenvs are used as a " -"primitive in `the dh-virtualenv tool `_ and `osnap `_, " -"both of which wrap virtualenvs in a self-contained way." -msgstr "" - -#: ../source/overview.rst:427 -msgid "" -"For production deployments, do not rely on running ``python -m pip install`` " -"from the Internet into a virtualenv, as one might do in a development " -"environment. The overview above is full of much better solutions." -msgstr "" - -#: ../source/overview.rst:432 -msgid "Security" -msgstr "" - -#: ../source/overview.rst:434 -msgid "" -"The further down the gradient you come, the harder it gets to update " -"components of your package. Everything is more tightly bound together." -msgstr "" - -#: ../source/overview.rst:437 -msgid "" -"For example, if a kernel security issue emerges, and you're deploying " -"containers, the host system's kernel can be updated without requiring a new " -"build on behalf of the application. If you deploy VM images, you'll need a " -"new build. Whether or not this dynamic makes one option more secure is still " -"a bit of an old debate, going back to the still-unsettled matter of `static " -"versus dynamic linking `_." -msgstr "" - -#: ../source/overview.rst:446 -msgid "Wrap up" -msgstr "" - -#: ../source/overview.rst:448 -msgid "" -"Packaging in Python has a bit of a reputation for being a bumpy ride. This " -"impression is mostly a byproduct of Python's versatility. Once you " -"understand the natural boundaries between each packaging solution, you begin " -"to realize that the varied landscape is a small price Python programmers pay " -"for using one of the most balanced, flexible languages available." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:6 -msgid "Binary distribution format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:8 -msgid "" -"The binary distribution format (:term:`wheel `) was originally " -"defined in :pep:`427`. The current version of the specification is here." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:13 -msgid "Abstract" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:15 -msgid "This PEP describes a built-package format for Python called \"wheel\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:17 -msgid "" -"A wheel is a ZIP-format archive with a specially formatted file name and the " -"``.whl`` extension. It contains a single distribution nearly as it would be " -"installed according to PEP 376 with a particular installation scheme. " -"Although a specialized installer is recommended, a wheel file may be " -"installed by simply unpacking into site-packages with the standard 'unzip' " -"tool while preserving enough information to spread its contents out onto " -"their final paths at any later time." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:27 -msgid "PEP Acceptance" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:29 -msgid "" -"This PEP was accepted, and the defined wheel version updated to 1.0, by Nick " -"Coghlan on 16th February, 2013 [1]_" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:34 -msgid "Rationale" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:36 -msgid "" -"Python needs a package format that is easier to install than sdist. Python's " -"sdist packages are defined by and require the distutils and setuptools build " -"systems, running arbitrary code to build-and-install, and re-compile, code " -"just so it can be installed into a new virtualenv. This system of " -"conflating build-install is slow, hard to maintain, and hinders innovation " -"in both build systems and installers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:43 -msgid "" -"Wheel attempts to remedy these problems by providing a simpler interface " -"between the build system and the installer. The wheel binary package format " -"frees installers from having to know about the build system, saves time by " -"amortizing compile time over many installations, and removes the need to " -"install a build system in the target environment." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:52 -msgid "Details" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:55 -msgid "Installing a wheel 'distribution-1.0-py32-none-any.whl'" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:57 -msgid "Wheel installation notionally consists of two phases:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:59 -msgid "Unpack." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:61 -msgid "Parse ``distribution-1.0.dist-info/WHEEL``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:62 -msgid "" -"Check that installer is compatible with Wheel-Version. Warn if minor " -"version is greater, abort if major version is greater." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:64 -msgid "" -"If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:66 -msgid "Else unpack archive into platlib (site-packages)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:68 -msgid "Spread." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:70 -msgid "" -"Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is " -"data) ``distribution-1.0.data/``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:72 -msgid "" -"Move each subtree of ``distribution-1.0.data/`` onto its destination path. " -"Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of " -"destination directories, such as ``distribution-1.0.data/(purelib|platlib|" -"headers|scripts|data)``. The initially supported paths are taken from " -"``distutils.command.install``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:78 -msgid "" -"If applicable, update scripts starting with ``#!python`` to point to the " -"correct interpreter." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:80 -msgid "Update ``distribution-1.0.dist-info/RECORD`` with the installed paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:82 -msgid "Remove empty ``distribution-1.0.data`` directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:83 -msgid "" -"Compile any installed .py to .pyc. (Uninstallers should be smart enough to " -"remove .pyc even if it is not mentioned in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:87 -msgid "Recommended installer features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:97 -msgid "Rewrite ``#!python``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:90 -msgid "" -"In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/" -"``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!" -"python'``, rewrite to point to the correct interpreter. Unix installers may " -"need to add the +x bit to these files if the archive was created on Windows." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:96 -msgid "" -"The ``b'#!pythonw'`` convention is allowed. ``b'#!pythonw'`` indicates a GUI " -"script instead of a console script." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:102 -msgid "Generate script wrappers." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:100 -msgid "" -"In wheel, scripts packaged on Unix systems will certainly not have " -"accompanying .exe wrappers. Windows installers may want to add them during " -"install." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:105 -msgid "Recommended archiver features" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:112 -msgid "Place ``.dist-info`` at the end of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:108 -msgid "" -"Archivers are encouraged to place the ``.dist-info`` files physically at the " -"end of the archive. This enables some potentially interesting ZIP tricks " -"including the ability to amend the metadata without rewriting the entire " -"archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:115 -msgid "File Format" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:118 -msgid "File name convention" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:120 -msgid "" -"The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-" -"{abi tag}-{platform tag}.whl``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "distribution" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:124 -msgid "Distribution name, e.g. 'django', 'pyramid'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "Distribution version, e.g. 1.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:135 -msgid "build tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:130 -msgid "" -"Optional build number. Must start with a digit. Acts as a tie-breaker if " -"two wheel file names are the same in all other respects (i.e. name, version, " -"and other tags). Sort as an empty tuple if unspecified, else sort as a two-" -"item tuple with the first item being the initial digits as an ``int``, and " -"the second item being the remainder of the tag as a ``str``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "language implementation and version tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:138 -msgid "E.g. 'py27', 'py2', 'py3'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "abi tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:141 -msgid "E.g. 'cp33m', 'abi3', 'none'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "platform tag" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:144 -msgid "E.g. 'linux_x86_64', 'any'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:146 -msgid "" -"For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of " -"a package called 'distribution', and is compatible with Python 2.7 (any " -"Python 2.7 implementation), with no ABI (pure Python), on any CPU " -"architecture." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:151 -msgid "" -"The last three components of the filename before the extension are called " -"\"compatibility tags.\" The compatibility tags express the package's basic " -"interpreter requirements and are detailed in PEP 425." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:156 -msgid "Escaping and Unicode" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:158 -msgid "" -"As the components of the filename are separated by a dash (``-``, HYPHEN-" -"MINUS), this character cannot appear within any component. This is handled " -"as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:161 -msgid "" -"In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE " -"and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent " -"to :pep:`503` normalisation followed by replacing ``-`` with ``_``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:164 -msgid "" -"Version numbers should be normalised according to :pep:`440`. Normalised " -"version numbers cannot contain ``-``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:166 -msgid "" -"The remaining components may not contain ``-`` characters, so no escaping is " -"necessary." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:169 -msgid "" -"Tools producing wheels should verify that the filename components do not " -"contain ``-``, as the resulting file may not be processed correctly if they " -"do." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:172 -msgid "" -"The archive filename is Unicode. It will be some time before the tools are " -"updated to support non-ASCII filenames, but they are supported in this " -"specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:176 -msgid "" -"The filenames *inside* the archive are encoded as UTF-8. Although some ZIP " -"clients in common use do not properly display UTF-8 filenames, the encoding " -"is supported by both the ZIP specification and Python's ``zipfile``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:182 -msgid "File contents" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:184 -msgid "" -"The contents of a wheel file, where {distribution} is replaced with the name " -"of the package, e.g. ``beaglevote`` and {version} is replaced with its " -"version, e.g. ``1.0.0``, consist of:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:188 -msgid "" -"``/``, the root of the archive, contains all files to be installed in " -"``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and " -"``platlib`` are usually both ``site-packages``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:191 -msgid "``{distribution}-{version}.dist-info/`` contains metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:192 -msgid "" -"``{distribution}-{version}.data/`` contains one subdirectory for each non-" -"empty install scheme key not already covered, where the subdirectory name is " -"an index into a dictionary of install paths (e.g. ``data``, ``scripts``, " -"``include``, ``purelib``, ``platlib``)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:196 -msgid "" -"Python scripts must appear in ``scripts`` and begin with exactly ``b'#!" -"python'`` in order to enjoy script wrapper generation and ``#!python`` " -"rewriting at install time. They may have any or no extension." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:200 -msgid "" -"``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or " -"greater format metadata." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:202 -msgid "" -"``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive " -"itself in the same basic key: value format::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:212 -msgid "``Wheel-Version`` is the version number of the Wheel specification." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:213 -msgid "" -"``Generator`` is the name and optionally the version of the software that " -"produced the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:215 -msgid "" -"``Root-Is-Purelib`` is true if the top level directory of the archive should " -"be installed into purelib; otherwise the root should be installed into " -"platlib." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:218 -msgid "" -"``Tag`` is the wheel's expanded compatibility tags; in the example the " -"filename would contain ``py2.py3-none-any``." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:220 -msgid "" -"``Build`` is the build number and is omitted if there is no build number." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:221 -msgid "" -"A wheel installer should warn if Wheel-Version is greater than the version " -"it supports, and must fail if Wheel-Version has a greater major version than " -"the version it supports." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:224 -msgid "" -"Wheel, being an installation format that is intended to work across multiple " -"versions of Python, does not generally include .pyc files." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:226 -msgid "Wheel does not contain setup.py or setup.cfg." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:228 -msgid "" -"This version of the wheel specification is based on the distutils install " -"schemes and does not define how to install files to other locations. The " -"layout offers a superset of the functionality provided by the existing " -"wininst and egg binary formats." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:235 -#: ../source/specifications/recording-installed-packages.rst:35 -msgid "The .dist-info directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:237 -msgid "" -"Wheel .dist-info directories include at a minimum METADATA, WHEEL, and " -"RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:239 -msgid "" -"METADATA is the package metadata, the same format as PKG-INFO as found at " -"the root of sdists." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:241 -msgid "WHEEL is the wheel metadata specific to a build of the package." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:242 -msgid "" -"RECORD is a list of (almost) all the files in the wheel and their secure " -"hashes. Unlike PEP 376, every file except RECORD, which cannot contain a " -"hash of itself, must include its hash. The hash algorithm must be sha256 or " -"better; specifically, md5 and sha1 are not permitted, as signed wheel files " -"rely on the strong hashes in RECORD to validate the integrity of the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:248 -msgid "PEP 376's INSTALLER and REQUESTED are not included in the archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:249 -msgid "" -"RECORD.jws is used for digital signatures. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:251 -msgid "" -"RECORD.p7s is allowed as a courtesy to anyone who would prefer to use S/MIME " -"signatures to secure their wheel files. It is not mentioned in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:254 -msgid "" -"During extraction, wheel installers verify all the hashes in RECORD against " -"the file contents. Apart from RECORD and its signatures, installation will " -"fail if any file in the archive is not both mentioned and correctly hashed " -"in RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:261 -msgid "The .data directory" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:263 -msgid "" -"Any file that is not normally installed inside site-packages goes into the ." -"data directory, named as the .dist-info directory but with the .data/ " -"extension::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:271 -msgid "" -"The .data directory contains subdirectories with the scripts, headers, " -"documentation and so forth from the distribution. During installation the " -"contents of these subdirectories are moved onto their destination paths." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:277 -msgid "Signed wheel files" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:279 -msgid "" -"Wheel files include an extended RECORD that enables digital signatures. PEP " -"376's RECORD is altered to include a secure hash " -"``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with " -"no trailing = characters) as the second column instead of an md5sum. All " -"possible entries are hashed, including any generated files such as .pyc " -"files, but not RECORD which cannot contain its own hash. For example::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:290 -msgid "" -"The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD " -"at all since they can only be added after RECORD is generated. Every other " -"file in the archive must have a correct hash in RECORD or the installation " -"will fail." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:295 -msgid "" -"If JSON web signatures are used, one or more JSON Web Signature JSON " -"Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent to " -"RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD " -"as the signature's JSON payload::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:302 -msgid "(The hash value is the same format used in RECORD.)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:304 -msgid "" -"If RECORD.p7s is used, it must contain a detached S/MIME format signature of " -"RECORD." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:307 -msgid "" -"A wheel installer is not required to understand digital signatures but MUST " -"verify the hashes in RECORD against the extracted file contents. When the " -"installer checks file hashes against RECORD, a separate signature checker " -"only needs to establish that RECORD matches the signature." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:312 -msgid "See" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:314 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:315 -msgid "" -"http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:316 -msgid "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" -msgstr "http://self-issued.info/docs/draft-ietf-jose-json-web-key.html" - -#: ../source/specifications/binary-distribution-format.rst:317 -msgid "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" -msgstr "http://self-issued.info/docs/draft-jones-jose-json-private-key.html" - -#: ../source/specifications/binary-distribution-format.rst:321 -msgid "Comparison to .egg" -msgstr "與 .egg 的比較" - -#: ../source/specifications/binary-distribution-format.rst:323 -msgid "" -"Wheel is an installation format; egg is importable. Wheel archives do not " -"need to include .pyc and are less tied to a specific Python version or " -"implementation. Wheel can install (pure Python) packages built with previous " -"versions of Python so you don't always have to wait for the packager to " -"catch up." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:328 -msgid "" -"Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible " -"with the new world of Python packaging and the new concepts it brings." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:331 -msgid "" -"Wheel has a richer file naming convention for today's multi-implementation " -"world. A single wheel archive can indicate its compatibility with a number " -"of Python language versions and implementations, ABIs, and system " -"architectures. Historically the ABI has been specific to a CPython release, " -"wheel is ready for the stable ABI." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:337 -msgid "" -"Wheel is lossless. The first wheel implementation bdist_wheel always " -"generates egg-info, and then converts it to a .whl. It is also possible to " -"convert existing eggs and bdist_wininst distributions." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:341 -msgid "" -"Wheel is versioned. Every wheel file contains the version of the wheel " -"specification and the implementation that packaged it. Hopefully the next " -"migration can simply be to Wheel 2.0." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:344 -msgid "Wheel is a reference to the other Python." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:348 -msgid "FAQ" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:352 -msgid "Wheel defines a .data directory. Should I put all my data there?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:354 -msgid "" -"This specification does not have an opinion on how you should organize your " -"code. The .data directory is just a place for any files that are not " -"normally installed inside ``site-packages`` or on the PYTHONPATH. In other " -"words, you may continue to use ``pkgutil.get_data(package, resource)`` even " -"though *those* files will usually not be distributed in *wheel's* ``.data`` " -"directory." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:363 -msgid "Why does wheel include attached signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:365 -msgid "" -"Attached signatures are more convenient than detached signatures because " -"they travel with the archive. Since only the individual files are signed, " -"the archive can be recompressed without invalidating the signature or " -"individual files can be verified without having to download the whole " -"archive." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:373 -msgid "Why does wheel allow JWS signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:375 -msgid "" -"The JOSE specifications of which JWS is a part are designed to be easy to " -"implement, a feature that is also one of wheel's primary design goals. JWS " -"yields a useful, concise pure-Python implementation." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:381 -msgid "Why does wheel also allow S/MIME signatures?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:383 -msgid "" -"S/MIME signatures are allowed for users who need or want to use existing " -"public key infrastructure with wheel." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:386 -msgid "" -"Signed packages are only a basic building block in a secure package update " -"system. Wheel only provides the building block." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:391 -msgid "What's the deal with \"purelib\" vs. \"platlib\"?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:393 -msgid "" -"Wheel preserves the \"purelib\" vs. \"platlib\" distinction, which is " -"significant on some platforms. For example, Fedora installs pure Python " -"packages to '/usr/lib/pythonX.Y/site-packages' and platform dependent " -"packages to '/usr/lib64/pythonX.Y/site-packages'." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:398 -msgid "" -"A wheel with \"Root-Is-Purelib: false\" with all its files in ``{name}-" -"{version}.data/purelib`` is equivalent to a wheel with \"Root-Is-Purelib: " -"true\" with those same files in the root, and it is legal to have files in " -"both the \"purelib\" and \"platlib\" categories." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:403 -msgid "" -"In practice a wheel should have only one of \"purelib\" or \"platlib\" " -"depending on whether it is pure Python or not and those files should be at " -"the root with the appropriate setting given for \"Root-is-purelib\"." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:409 -msgid "Is it possible to import Python code directly from a wheel file?" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:411 -msgid "" -"Technically, due to the combination of supporting installation via simple " -"extraction and using an archive format that is compatible with " -"``zipimport``, a subset of wheel files *do* support being placed directly on " -"``sys.path``. However, while this behaviour is a natural consequence of the " -"format design, actually relying on it is generally discouraged." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:417 -msgid "" -"Firstly, wheel *is* designed primarily as a distribution format, so skipping " -"the installation step also means deliberately avoiding any reliance on " -"features that assume full installation (such as being able to use standard " -"tools like ``pip`` and ``virtualenv`` to capture and manage dependencies in " -"a way that can be properly tracked for auditing and security update " -"purposes, or integrating fully with the standard build machinery for C " -"extensions by publishing header files in the appropriate place)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:426 -msgid "" -"Secondly, while some Python software is written to support running directly " -"from a zip archive, it is still common for code to be written assuming it " -"has been fully installed. When that assumption is broken by trying to run " -"the software from a zip archive, the failures can often be obscure and hard " -"to diagnose (especially when they occur in third party libraries). The two " -"most common sources of problems with this are the fact that importing C " -"extensions from a zip archive is *not* supported by CPython (since doing so " -"is not supported directly by the dynamic loading machinery on any platform) " -"and that when running from a zip archive the ``__file__`` attribute no " -"longer refers to an ordinary filesystem path, but to a combination path that " -"includes both the location of the zip archive on the filesystem and the " -"relative path to the module inside the archive. Even when software correctly " -"uses the abstract resource APIs internally, interfacing with external " -"components may still require the availability of an actual on-disk file." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:443 -msgid "" -"Like metaclasses, monkeypatching and metapath importers, if you're not " -"already sure you need to take advantage of this feature, you almost " -"certainly don't need it. If you *do* decide to use it anyway, be aware that " -"many projects will require a failure to be reproduced with a fully installed " -"package before accepting it as a genuine bug." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:450 -msgid "Changes" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:452 -msgid "Since :pep:`427`, this specification has changed as follows:" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:454 -msgid "" -"The rules on escaping in wheel filenames were revised, to bring them into " -"line with what popular tools actually do (February 2021)." -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:461 -msgid "" -"PEP acceptance (https://mail.python.org/pipermail/python-dev/2013-" -"February/124103.html)" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:466 -msgid "Appendix" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:468 -msgid "Example urlsafe-base64-nopad implementation::" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:482 -msgid "Copyright" -msgstr "" - -#: ../source/specifications/binary-distribution-format.rst:484 -msgid "This document has been placed into the public domain." -msgstr "" - -#: ../source/specifications/core-metadata.rst:5 -msgid "Core metadata specifications" -msgstr "" - -#: ../source/specifications/core-metadata.rst:7 -msgid "" -"Fields defined in the following specification should be considered valid, " -"complete and not subject to change. The required fields are:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:10 -msgid "``Metadata-Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:11 -msgid "``Name``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:12 -msgid "``Version``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:14 -msgid "All the other fields are optional." -msgstr "" - -#: ../source/specifications/core-metadata.rst:16 -msgid "" -"The standard file format for metadata (including in :doc:`wheels ` and :doc:`installed projects `) is based on the format of email headers. However, email formats " -"have been revised several times, and exactly which email RFC applies to " -"packaging metadata is not specified. In the absence of a precise definition, " -"the practical standard is set by what the standard library :mod:`python:" -"email.parser` module can parse using the :data:`~.python:email.policy." -"compat32` policy." -msgstr "" - -#: ../source/specifications/core-metadata.rst:25 -msgid "" -"Although :pep:`566` defined a way to transform metadata into a JSON-" -"compatible dictionary, this is not yet used as a standard interchange " -"format. The need for tools to work with years worth of existing packages " -"makes it difficult to shift to a new format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:30 -msgid "" -"*Interpreting old metadata:* In :pep:`566`, the version specifier field " -"format specification was relaxed to accept the syntax used by popular " -"publishing tools (namely to remove the requirement that version specifiers " -"must be surrounded by parentheses). Metadata consumers may want to use the " -"more relaxed formatting rules even for metadata files that are nominally " -"less than version 2.1." -msgstr "" - -#: ../source/specifications/core-metadata.rst:41 -msgid "Metadata-Version" -msgstr "" - -#: ../source/specifications/core-metadata.rst:45 -msgid "" -"Version of the file format; legal values are \"1.0\", \"1.1\", \"1.2\", " -"\"2.1\" and \"2.2\"." -msgstr "" - -#: ../source/specifications/core-metadata.rst:48 -msgid "" -"Automated tools consuming metadata SHOULD warn if ``metadata_version`` is " -"greater than the highest version they support, and MUST fail if " -"``metadata_version`` has a greater major version than the highest version " -"they support (as described in :pep:`440`, the major version is the value " -"before the first dot)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:54 -msgid "" -"For broader compatibility, build tools MAY choose to produce distribution " -"metadata using the lowest metadata version that includes all of the needed " -"fields." -msgstr "" - -#: ../source/specifications/core-metadata.rst:58 -#: ../source/specifications/core-metadata.rst:80 -#: ../source/specifications/core-metadata.rst:95 -#: ../source/specifications/core-metadata.rst:155 -#: ../source/specifications/core-metadata.rst:170 -#: ../source/specifications/core-metadata.rst:208 -#: ../source/specifications/core-metadata.rst:283 -#: ../source/specifications/core-metadata.rst:287 -#: ../source/specifications/core-metadata.rst:291 -#: ../source/specifications/core-metadata.rst:295 -#: ../source/specifications/core-metadata.rst:327 -#: ../source/specifications/core-metadata.rst:347 -#: ../source/specifications/core-metadata.rst:373 -#: ../source/specifications/core-metadata.rst:391 -#: ../source/specifications/core-metadata.rst:416 -#: ../source/specifications/core-metadata.rst:438 -#: ../source/specifications/core-metadata.rst:600 -#: ../source/specifications/core-metadata.rst:620 -#: ../source/specifications/core-metadata.rst:630 -msgid "Example::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:66 -msgid "Name" -msgstr "" - -#: ../source/specifications/core-metadata.rst:69 -msgid "Added additional restrictions on format from :pep:`508`" -msgstr "" - -#: ../source/specifications/core-metadata.rst:72 -msgid "" -"The name of the distribution. The name field is the primary identifier for a " -"distribution. A valid name consists only of ASCII letters and numbers, " -"period, underscore and hyphen. It must start and end with a letter or " -"number. Distribution names are limited to those which match the following " -"regex (run with ``re.IGNORECASE``)::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:88 -msgid "Version" -msgstr "" - -#: ../source/specifications/core-metadata.rst:92 -msgid "" -"A string containing the distribution's version number. This field must be " -"in the format specified in :pep:`440`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:101 -msgid "Dynamic (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:105 -msgid "" -"A string containing the name of another core metadata field. The field names " -"``Name`` and ``Version`` may not be specified in this field." -msgstr "" - -#: ../source/specifications/core-metadata.rst:108 -msgid "" -"When found in the metadata of a source distribution, the following rules " -"apply:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:111 -msgid "" -"If a field is *not* marked as ``Dynamic``, then the value of the field in " -"any wheel built from the sdist MUST match the value in the sdist. If the " -"field is not in the sdist, and not marked as ``Dynamic``, then it MUST NOT " -"be present in the wheel." -msgstr "" - -#: ../source/specifications/core-metadata.rst:115 -msgid "" -"If a field is marked as ``Dynamic``, it may contain any valid value in a " -"wheel built from the sdist (including not being present at all)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:118 -msgid "" -"If the sdist metadata version is older than version 2.2, then all fields " -"should be treated as if they were specified with ``Dynamic`` (i.e. there are " -"no special restrictions on the metadata of wheels built from the sdist)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:122 -msgid "" -"In any context other than a source distribution, ``Dynamic`` is for " -"information only, and indicates that the field value was calculated at wheel " -"build time, and may not be the same as the value in the sdist or in other " -"wheels for the project." -msgstr "" - -#: ../source/specifications/core-metadata.rst:127 -msgid "" -"Full details of the semantics of ``Dynamic`` are described in :pep:`643`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:131 -msgid "Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:135 -msgid "" -"A Platform specification describing an operating system supported by the " -"distribution which is not listed in the \"Operating System\" Trove " -"classifiers. See \"Classifier\" below." -msgstr "" - -#: ../source/specifications/core-metadata.rst:146 -msgid "Supported-Platform (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:150 -msgid "" -"Binary distributions containing a PKG-INFO file will use the Supported-" -"Platform field in their metadata to specify the OS and CPU for which the " -"binary distribution was compiled. The semantics of the Supported-Platform " -"field are not specified in this PEP." -msgstr "" - -#: ../source/specifications/core-metadata.rst:164 -msgid "Summary" -msgstr "" - -#: ../source/specifications/core-metadata.rst:168 -msgid "A one-line summary of what the distribution does." -msgstr "" - -#: ../source/specifications/core-metadata.rst:188 -msgid "This field may be specified in the message body instead." -msgstr "" - -#: ../source/specifications/core-metadata.rst:191 -msgid "" -"A longer description of the distribution that can run to several " -"paragraphs. Software that deals with metadata should not assume any maximum " -"size for this field, though people shouldn't include their instruction " -"manual as the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:196 -msgid "" -"The contents of this field can be written using reStructuredText markup " -"[1]_. For programs that work with the metadata, supporting markup is " -"optional; programs can also display the contents of the field as-is. This " -"means that authors should be conservative in the markup they use." -msgstr "" - -#: ../source/specifications/core-metadata.rst:202 -msgid "" -"To support empty lines and lines with indentation with respect to the RFC " -"822 format, any CRLF character has to be suffixed by 7 spaces followed by a " -"pipe (\"|\") char. As a result, the Description field is encoded into a " -"folded field that can be interpreted by RFC822 parser [2]_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:219 -msgid "" -"This encoding implies that any occurrences of a CRLF followed by 7 spaces " -"and a pipe char have to be replaced by a single CRLF when the field is " -"unfolded using a RFC822 reader." -msgstr "" - -#: ../source/specifications/core-metadata.rst:223 -msgid "" -"Alternatively, the distribution's description may instead be provided in the " -"message body (i.e., after a completely blank line following the headers, " -"with no indentation or other special formatting necessary)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:232 -msgid "Description-Content-Type" -msgstr "" - -#: ../source/specifications/core-metadata.rst:236 -msgid "" -"A string stating the markup syntax (if any) used in the distribution's " -"description, so that tools can intelligently render the description." -msgstr "" - -#: ../source/specifications/core-metadata.rst:239 -msgid "" -"Historically, PyPI supported descriptions in plain text and " -"`reStructuredText (reST) `_, and could render reST into HTML. However, it is " -"common for distribution authors to write the description in `Markdown " -"`_ (`RFC 7763 `_) as many code hosting sites render Markdown " -"READMEs, and authors would reuse the file for the description. PyPI didn't " -"recognize the format and so could not render the description correctly. This " -"resulted in many packages on PyPI with poorly-rendered descriptions when " -"Markdown is left as plain text, or worse, was attempted to be rendered as " -"reST. This field allows the distribution author to specify the format of " -"their description, opening up the possibility for PyPI and other tools to be " -"able to render Markdown and other formats." -msgstr "" - -#: ../source/specifications/core-metadata.rst:253 -msgid "" -"The format of this field is the same as the ``Content-Type`` header in HTTP " -"(i.e.: `RFC 1341 `_). Briefly, this means that it has a ``type/subtype`` part and then " -"it can optionally have a number of parameters:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:259 -msgid "Format::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:263 -msgid "The ``type/subtype`` part has only a few legal values:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:265 -msgid "``text/plain``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:266 -msgid "``text/x-rst``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:267 -msgid "``text/markdown``" -msgstr "" - -#: ../source/specifications/core-metadata.rst:269 -msgid "" -"The ``charset`` parameter can be used to specify the character encoding of " -"the description. The only legal value is ``UTF-8``. If omitted, it is " -"assumed to be ``UTF-8``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:273 -msgid "" -"Other parameters might be specific to the chosen subtype. For example, for " -"the ``markdown`` subtype, there is an optional ``variant`` parameter that " -"allows specifying the variant of Markdown in use (defaults to ``GFM`` if not " -"specified). Currently, two variants are recognized:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:278 -msgid "" -"``GFM`` for `Github-flavored Markdown `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:280 -msgid "" -"``CommonMark`` for `CommonMark `_" -msgstr "" - -#: ../source/specifications/core-metadata.rst:299 -msgid "" -"If a ``Description-Content-Type`` is not specified, then applications should " -"attempt to render it as ``text/x-rst; charset=UTF-8`` and fall back to " -"``text/plain`` if it is not valid rst." -msgstr "" - -#: ../source/specifications/core-metadata.rst:303 -msgid "" -"If a ``Description-Content-Type`` is an unrecognized value, then the assumed " -"content type is ``text/plain`` (Although PyPI will probably reject anything " -"with an unrecognized value)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:307 -msgid "" -"If the ``Description-Content-Type`` is ``text/markdown`` and ``variant`` is " -"not specified or is set to an unrecognized value, then the assumed " -"``variant`` is ``GFM``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:311 -msgid "" -"So for the last example above, the ``charset`` defaults to ``UTF-8`` and the " -"``variant`` defaults to ``GFM`` and thus it is equivalent to the example " -"before it." -msgstr "" - -#: ../source/specifications/core-metadata.rst:320 -msgid "Keywords" -msgstr "" - -#: ../source/specifications/core-metadata.rst:324 -msgid "" -"A list of additional keywords, separated by commas, to be used to assist " -"searching for the distribution in a larger catalog." -msgstr "" - -#: ../source/specifications/core-metadata.rst:333 -msgid "" -"The specification previously showed keywords separated by spaces, but " -"distutils and setuptools implemented it with commas. These tools have been " -"very widely used for many years, so it was easier to update the " -"specification to match the de facto standard." -msgstr "" - -#: ../source/specifications/core-metadata.rst:341 -msgid "Home-page" -msgstr "" - -#: ../source/specifications/core-metadata.rst:345 -msgid "A string containing the URL for the distribution's home page." -msgstr "" - -#: ../source/specifications/core-metadata.rst:353 -msgid "Download-URL" -msgstr "" - -#: ../source/specifications/core-metadata.rst:357 -msgid "" -"A string containing the URL from which this version of the distribution can " -"be downloaded. (This means that the URL can't be something like \".../" -"BeagleVote-latest.tgz\", but instead must be \".../BeagleVote-0.45.tgz\".)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:366 -msgid "Author" -msgstr "" - -#: ../source/specifications/core-metadata.rst:370 -msgid "" -"A string containing the author's name at a minimum; additional contact " -"information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:383 -msgid "Author-email" -msgstr "" - -#: ../source/specifications/core-metadata.rst:387 -msgid "" -"A string containing the author's e-mail address. It can contain a name and " -"e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:395 -#: ../source/specifications/core-metadata.rst:442 -msgid "" -"Per RFC-822, this field may contain multiple comma-separated e-mail " -"addresses::" -msgstr "" - -#: ../source/specifications/core-metadata.rst:405 -msgid "Maintainer" -msgstr "" - -#: ../source/specifications/core-metadata.rst:409 -msgid "" -"A string containing the maintainer's name at a minimum; additional contact " -"information may be provided." -msgstr "" - -#: ../source/specifications/core-metadata.rst:412 -msgid "" -"Note that this field is intended for use when a project is being maintained " -"by someone other than the original author: it should be omitted if it is " -"identical to ``Author``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:426 -msgid "Maintainer-email" -msgstr "" - -#: ../source/specifications/core-metadata.rst:430 -msgid "" -"A string containing the maintainer's e-mail address. It can contain a name " -"and e-mail address in the legal forms for a RFC-822 ``From:`` header." -msgstr "" - -#: ../source/specifications/core-metadata.rst:434 -msgid "" -"Note that this field is intended for use when a project is being maintained " -"by someone other than the original author: it should be omitted if it is " -"identical to ``Author-email``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:452 -msgid "License" -msgstr "" - -#: ../source/specifications/core-metadata.rst:456 -msgid "" -"Text indicating the license covering the distribution where the license is " -"not a selection from the \"License\" Trove classifiers. See :ref:`" -"\"Classifier\" ` below. This field may also be used to " -"specify a particular version of a license which is named via the " -"``Classifier`` field, or to indicate a variation or exception to such a " -"license." -msgstr "" - -#: ../source/specifications/core-metadata.rst:476 -msgid "Classifier (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:480 -msgid "" -"Each entry is a string giving a single classification value for the " -"distribution. Classifiers are described in :pep:`301`, and the Python " -"Package Index publishes a dynamic list of `currently defined classifiers " -"`__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:485 -#: ../source/specifications/core-metadata.rst:574 -#: ../source/specifications/core-metadata.rst:691 -#: ../source/specifications/core-metadata.rst:715 -msgid "This field may be followed by an environment marker after a semicolon." -msgstr "" - -#: ../source/specifications/core-metadata.rst:496 -msgid "Requires-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:499 -#: ../source/specifications/core-metadata.rst:561 -#: ../source/specifications/core-metadata.rst:663 -#: ../source/specifications/core-metadata.rst:704 -msgid "" -"The field format specification was relaxed to accept the syntax used by " -"popular publishing tools." -msgstr "" - -#: ../source/specifications/core-metadata.rst:503 -msgid "" -"Each entry contains a string naming some other distutils project required by " -"this distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:506 -msgid "The format of a requirement string contains from one to four parts:" -msgstr "" - -#: ../source/specifications/core-metadata.rst:508 -msgid "" -"A project name, in the same format as the ``Name:`` field. The only " -"mandatory part." -msgstr "" - -#: ../source/specifications/core-metadata.rst:510 -msgid "" -"A comma-separated list of 'extra' names. These are defined by the required " -"project, referring to specific features which may need extra dependencies." -msgstr "" - -#: ../source/specifications/core-metadata.rst:513 -msgid "" -"A version specifier. Tools parsing the format should accept optional " -"parentheses around this, but tools generating it should not use parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:516 -msgid "" -"An environment marker after a semicolon. This means that the requirement is " -"only needed in the specified conditions." -msgstr "" - -#: ../source/specifications/core-metadata.rst:519 -msgid "See :pep:`508` for full details of the allowed format." -msgstr "" - -#: ../source/specifications/core-metadata.rst:521 -msgid "" -"The project names should correspond to names as found on the `Python Package " -"Index`_." -msgstr "" - -#: ../source/specifications/core-metadata.rst:524 -msgid "" -"Version specifiers must follow the rules described in :doc:`version-" -"specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:538 -msgid "Requires-Python" -msgstr "" - -#: ../source/specifications/core-metadata.rst:542 -msgid "" -"This field specifies the Python version(s) that the distribution is " -"guaranteed to be compatible with. Installation tools may look at this when " -"picking which version of a project to install." -msgstr "" - -#: ../source/specifications/core-metadata.rst:546 -msgid "The value must be in the format specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:548 -msgid "This field cannot be followed by an environment marker." -msgstr "" - -#: ../source/specifications/core-metadata.rst:558 -msgid "Requires-External (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:565 -msgid "" -"Each entry contains a string describing some dependency in the system that " -"the distribution is to be used. This field is intended to serve as a hint " -"to downstream project maintainers, and has no semantics which are meaningful " -"to the ``distutils`` distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:570 -msgid "" -"The format of a requirement string is a name of an external dependency, " -"optionally followed by a version declaration within parentheses." -msgstr "" - -#: ../source/specifications/core-metadata.rst:576 -msgid "" -"Because they refer to non-Python software releases, version numbers for this " -"field are **not** required to conform to the format specified in :pep:" -"`440`: they should correspond to the version scheme used by the external " -"dependency." -msgstr "" - -#: ../source/specifications/core-metadata.rst:581 -msgid "Notice that there is no particular rule on the strings to be used." -msgstr "" - -#: ../source/specifications/core-metadata.rst:593 -msgid "Project-URL (multiple-use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:597 -msgid "" -"A string containing a browsable URL for the project and a label for it, " -"separated by a comma." -msgstr "" - -#: ../source/specifications/core-metadata.rst:604 -msgid "The label is free text limited to 32 characters." -msgstr "" - -#: ../source/specifications/core-metadata.rst:612 -msgid "Provides-Extra (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:616 -msgid "" -"A string containing the name of an optional feature. Must be a valid Python " -"identifier. May be used to make a dependency conditional on whether the " -"optional feature has been requested." -msgstr "" - -#: ../source/specifications/core-metadata.rst:625 -msgid "" -"A second distribution requires an optional dependency by placing it inside " -"square brackets, and can request multiple features by separating them with a " -"comma (,). The requirements are evaluated for each requested feature and " -"added to the set of requirements for the distribution." -msgstr "" - -#: ../source/specifications/core-metadata.rst:635 -msgid "" -"Two feature names ``test`` and ``doc`` are reserved to mark dependencies " -"that are needed for running automated tests and generating documentation, " -"respectively." -msgstr "" - -#: ../source/specifications/core-metadata.rst:639 -msgid "" -"It is legal to specify ``Provides-Extra:`` without referencing it in any " -"``Requires-Dist:``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:644 -msgid "Rarely Used Fields" -msgstr "" - -#: ../source/specifications/core-metadata.rst:646 -msgid "" -"The fields in this section are currently rarely used, as their design was " -"inspired by comparable mechanisms in Linux package management systems, and " -"it isn't at all clear how tools should interpret them in the context of an " -"open index server such as `PyPI `__." -msgstr "" - -#: ../source/specifications/core-metadata.rst:651 -msgid "" -"As a result, popular installation tools ignore them completely, which in " -"turn means there is little incentive for package publishers to set them " -"appropriately. However, they're retained in the metadata specification, as " -"they're still potentially useful for informational purposes, and can also be " -"used for their originally intended purpose in combination with a curated " -"package repository." -msgstr "" - -#: ../source/specifications/core-metadata.rst:660 -msgid "Provides-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:667 -msgid "" -"Each entry contains a string naming a Distutils project which is contained " -"within this distribution. This field *must* include the project identified " -"in the ``Name`` field, followed by the version : Name (Version)." -msgstr "" - -#: ../source/specifications/core-metadata.rst:672 -msgid "" -"A distribution may provide additional names, e.g. to indicate that multiple " -"projects have been bundled together. For instance, source distributions of " -"the ``ZODB`` project have historically included the ``transaction`` project, " -"which is now available as a separate distribution. Installing such a source " -"distribution satisfies requirements for both ``ZODB`` and ``transaction``." -msgstr "" - -#: ../source/specifications/core-metadata.rst:679 -msgid "" -"A distribution may also provide a \"virtual\" project name, which does not " -"correspond to any separately-distributed project: such a name might be used " -"to indicate an abstract capability which could be supplied by one of " -"multiple projects. E.g., multiple projects might supply RDBMS bindings for " -"use by a given ORM: each project might declare that it provides ``ORM-" -"bindings``, allowing other projects to depend only on having at most one of " -"them installed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:687 -msgid "" -"A version declaration may be supplied and must follow the rules described " -"in :doc:`version-specifiers`. The distribution's version number will be " -"implied if none is specified." -msgstr "" - -#: ../source/specifications/core-metadata.rst:701 -msgid "Obsoletes-Dist (multiple use)" -msgstr "" - -#: ../source/specifications/core-metadata.rst:708 -msgid "" -"Each entry contains a string describing a distutils project's distribution " -"which this distribution renders obsolete, meaning that the two projects " -"should not be installed at the same time." -msgstr "" - -#: ../source/specifications/core-metadata.rst:712 -msgid "" -"Version declarations can be supplied. Version numbers must be in the format " -"specified in :doc:`version-specifiers`." -msgstr "" - -#: ../source/specifications/core-metadata.rst:717 -msgid "" -"The most common use of this field will be in case a project name changes, e." -"g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install " -"Torqued Python, the Gorgon distribution should be removed." -msgstr "" - -#: ../source/specifications/core-metadata.rst:730 -msgid "reStructuredText markup: http://docutils.sourceforge.net/" -msgstr "" - -#: ../source/specifications/core-metadata.rst:735 -msgid "RFC 822 Long Header Fields: http://www.freesoft.org/CIE/RFC/822/7.htm" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:6 -msgid "Declaring build system dependencies" -msgstr "" - -#: ../source/specifications/declaring-build-dependencies.rst:8 -msgid "" -"`pyproject.toml` is a build system independent file format defined in :pep:" -"`518` that projects may provide in order to declare any Python level " -"dependencies that must be installed in order to run the project's build " -"system successfully." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:5 -msgid "Declaring project metadata" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:7 -msgid "" -":pep:`621` specifies how to write a project's :ref:`core metadata ` in a ``pyproject.toml`` file for packaging-related tools to " -"consume. It defines the following specification as the canonical source for " -"the format used." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:12 -msgid "" -"There are two kinds of metadata: *static* and *dynamic*. Static metadata is " -"specified in the ``pyproject.toml`` file directly and cannot be specified or " -"changed by a tool. Dynamic metadata is listed via the ``dynamic`` field " -"(defined later in this specification) and represents metadata that a tool " -"will later provide." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:18 -msgid "" -"The fields defined in this specification MUST be in a table named " -"``[project]`` in ``pyproject.toml``. No tools may add fields to this table " -"which are not defined by this specification. For tools wishing to store " -"their own settings in ``pyproject.toml``, they may use the ``[tool]`` table " -"as defined in the :ref:`build dependency declaration specification " -"`. The lack of a ``[project]`` table " -"implicitly means the build back-end will dynamically provide all fields." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:27 -msgid "The only fields required to be statically defined are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:29 -#: ../source/specifications/declaring-project-metadata.rst:41 -msgid "``name``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:31 -msgid "" -"The fields which are required but may be specified *either* statically or " -"listed as dynamic are:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:34 -#: ../source/specifications/declaring-project-metadata.rst:54 -msgid "``version``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:36 -msgid "" -"All other fields are considered optional and my be specified statically, " -"listed as dynamic, or left unspecified." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:43 -#: ../source/specifications/declaring-project-metadata.rst:56 -#: ../source/specifications/declaring-project-metadata.rst:68 -#: ../source/specifications/declaring-project-metadata.rst:117 -msgid "TOML_ type: string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:44 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Name `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:47 -msgid "The name of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:49 -msgid "" -"Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it " -"is read for internal consistency." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:57 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Version " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:60 -msgid "The version of the project as supported by :pep:`440`." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:62 -msgid "Users SHOULD prefer to specify already-normalized versions." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:66 -msgid "``description``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:69 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Summary " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:72 -msgid "The summary description of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:76 -msgid "``readme``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:78 -msgid "TOML_ type: string or table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:79 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Description " -"` and :ref:`Description-Content-Type `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:83 -msgid "The full description of the project (i.e. the README)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:85 -msgid "" -"The field accepts either a string or a table. If it is a string then it is a " -"path relative to ``pyproject.toml`` to a text file containing the full " -"description. Tools MUST assume the file's encoding is UTF-8. If the file " -"path ends in a case-insensitive ``.md`` suffix, then tools MUST assume the " -"content-type is ``text/markdown``. If the file path ends in a case-" -"insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-" -"rst``. If a tool recognizes more extensions than this PEP, they MAY infer " -"the content-type for the user without specifying this field as ``dynamic``. " -"For all unrecognized suffixes when a content-type is not provided, tools " -"MUST raise an error." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:96 -msgid "" -"The ``readme`` field may also take a table. The ``file`` key has a string " -"value representing a path relative to ``pyproject.toml`` to a file " -"containing the full description. The ``text`` key has a string value which " -"is the full description. These keys are mutually-exclusive, thus tools MUST " -"raise an error if the metadata specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:103 -msgid "" -"A table specified in the ``readme`` field also has a ``content-type`` field " -"which takes a string specifying the content-type of the full description. A " -"tool MUST raise an error if the metadata does not specify this field in the " -"table. If the metadata does not specify the ``charset`` parameter, then it " -"is assumed to be UTF-8. Tools MAY support other encodings if they choose to. " -"Tools MAY support alternative content-types which they can transform to a " -"content-type as supported by the :ref:`core metadata `. " -"Otherwise tools MUST raise an error for unsupported content-types." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:115 -msgid "``requires-python``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:118 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Requires-" -"Python `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:121 -msgid "The Python version requirements of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:125 -msgid "``license``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:127 -msgid "TOML_ type: table" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:128 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`License " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:131 -msgid "" -"The table may have one of two keys. The ``file`` key has a string value that " -"is a file path relative to ``pyproject.toml`` to the file which contains the " -"license for the project. Tools MUST assume the file's encoding is UTF-8. The " -"``text`` key has a string value which is the license of the project. These " -"keys are mutually exclusive, so a tool MUST raise an error if the metadata " -"specifies both keys." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:140 -msgid "``authors``/``maintainers``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:142 -msgid "TOML_ type: Array of inline tables with string keys and values" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:143 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Author `, :ref:`Author-email `, :ref:" -"`Maintainer `, and :ref:`Maintainer-email `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:149 -msgid "" -"The people or organizations considered to be the \"authors\" of the project. " -"The exact meaning is open to interpretation — it may list the original or " -"primary authors, current maintainers, or owners of the package." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:154 -msgid "" -"The \"maintainers\" field is similar to \"authors\" in that its exact " -"meaning is open to interpretation." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:157 -msgid "" -"These fields accept an array of tables with 2 keys: ``name`` and ``email``. " -"Both values must be strings. The ``name`` value MUST be a valid email name " -"(i.e. whatever can be put as a name, before an email, in `RFC 822`_) and not " -"contain commas. The ``email`` value MUST be a valid email address. Both keys " -"are optional." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:163 -msgid "" -"Using the data to fill in :ref:`core metadata ` is as follows:" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:166 -msgid "" -"If only ``name`` is provided, the value goes in :ref:`Author ` or :ref:`Maintainer ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:169 -msgid "" -"If only ``email`` is provided, the value goes in :ref:`Author-email ` or :ref:`Maintainer-email ` as appropriate." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:173 -msgid "" -"If both ``email`` and ``name`` are provided, the value goes in :ref:`Author-" -"email ` or :ref:`Maintainer-email ` as appropriate, with the format ``{name} <{email}>``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:177 -msgid "Multiple values should be separated by commas." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:181 -msgid "``keywords``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:183 -#: ../source/specifications/declaring-project-metadata.rst:193 -msgid "TOML_ type: array of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:184 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Keywords " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:187 -msgid "The keywords for the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:191 -msgid "``classifiers``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:194 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Classifier " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:197 -msgid "Trove classifiers which apply to the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:201 -msgid "``urls``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:203 -msgid "TOML_ type: table with keys and values of strings" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:204 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Project-URL " -"`" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:207 -msgid "" -"A table of URLs where the key is the URL label and the value is the URL " -"itself." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:212 -msgid "Entry points" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:214 -msgid "" -"TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and " -"``[project.entry-points]``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:216 -msgid ":ref:`Entry points specification `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:218 -msgid "" -"There are three tables related to entry points. The ``[project.scripts]`` " -"table corresponds to the ``console_scripts`` group in the :ref:`entry points " -"specification `. The key of the table is the name of the entry " -"point and the value is the object reference." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:224 -msgid "" -"The ``[project.gui-scripts]`` table corresponds to the ``gui_scripts`` group " -"in the :ref:`entry points specification `. Its format is the " -"same as ``[project.scripts]``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:228 -msgid "" -"The ``[project.entry-points]`` table is a collection of tables. Each sub-" -"table's name is an entry point group. The key and value semantics are the " -"same as ``[project.scripts]``. Users MUST NOT create nested sub-tables but " -"instead keep the entry point groups to only one level deep." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:234 -msgid "" -"Build back-ends MUST raise an error if the metadata defines a ``[project." -"entry-points.console_scripts]`` or ``[project.entry-points.gui_scripts]`` " -"table, as they would be ambiguous in the face of ``[project.scripts]`` and " -"``[project.gui-scripts]``, respectively." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:242 -msgid "``dependencies``/``optional-dependencies``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:244 -msgid "" -"TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with " -"values of arrays of :pep:`508` strings (``optional-dependencies``)" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:247 -msgid "" -"Corresponding :ref:`core metadata ` field: :ref:`Requires-" -"Dist ` and :ref:`Provides-Extra `" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:251 -msgid "The (optional) dependencies of the project." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:253 -msgid "" -"For ``dependencies``, it is a key whose value is an array of strings. Each " -"string represents a dependency of the project and MUST be formatted as a " -"valid :pep:`508` string. Each string maps directly to a :ref:`Requires-Dist " -"` entry." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:258 -msgid "" -"For ``optional-dependencies``, it is a table where each key specifies an " -"extra and whose value is an array of strings. The strings of the arrays must " -"be valid :pep:`508` strings. The keys MUST be valid values for :ref:" -"`Provides-Extra `. Each value in the array " -"thus becomes a corresponding :ref:`Requires-Dist ` entry for the matching :ref:`Provides-Extra ` metadata." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:269 -msgid "``dynamic``" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:271 -msgid "TOML_ type: array of string" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:272 -msgid "" -"A corresponding :ref:`core metadata ` field does not exist" -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:275 -msgid "" -"Specifies which fields listed by this PEP were intentionally unspecified so " -"another tool can/will provide such metadata dynamically. This clearly " -"delineates which metadata is purposefully unspecified and expected to stay " -"unspecified compared to being provided via tooling later on." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:281 -msgid "" -"A build back-end MUST honour statically-specified metadata (which means the " -"metadata did not list the field in ``dynamic``)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:283 -msgid "" -"A build back-end MUST raise an error if the metadata specifies ``name`` in " -"``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:285 -msgid "" -"If the :ref:`core metadata ` specification lists a field as " -"\"Required\", then the metadata MUST specify the field statically or list it " -"in ``dynamic`` (build back-ends MUST raise an error otherwise, i.e. it " -"should not be possible for a required field to not be listed somehow in the " -"``[project]`` table)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:290 -msgid "" -"If the :ref:`core metadata ` specification lists a field as " -"\"Optional\", the metadata MAY list it in ``dynamic`` if the expectation is " -"a build back-end will provide the data for the field later." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:294 -msgid "" -"Build back-ends MUST raise an error if the metadata specifies a field " -"statically as well as being listed in ``dynamic``." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:296 -msgid "" -"If the metadata does not list a field in ``dynamic``, then a build back-end " -"CANNOT fill in the requisite metadata on behalf of the user (i.e. " -"``dynamic`` is the only way to allow a tool to fill in metadata and the user " -"must opt into the filling in)." -msgstr "" - -#: ../source/specifications/declaring-project-metadata.rst:300 -msgid "" -"Build back-ends MUST raise an error if the metadata specifies a field in " -"``dynamic`` but the build back-end was unable to determine the data for it " -"(omitting the data, if determined to be the accurate value, is acceptable)." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:6 -msgid "Dependency specifiers" -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:8 -msgid "" -"The dependency specifier format used to declare a dependency on another " -"component is defined in :pep:`508`." -msgstr "" - -#: ../source/specifications/dependency-specifiers.rst:11 -msgid "" -"The environment markers section in this PEP supersedes the environment " -"markers section in :pep:`345`." -msgstr "" - -#: ../source/specifications/direct-url.rst:6 -msgid "Recording the Direct URL Origin of installed distributions" -msgstr "" - -#: ../source/specifications/direct-url.rst:8 -msgid "" -"This document specifies a :file:`direct_url.json` file in the :file:`*.dist-" -"info` directory of an installed distribution, to record the Direct URL " -"Origin of the distribution. The layout of this file was originally specified " -"in :pep:`610` and is formally documented here." -msgstr "" - -#: ../source/specifications/direct-url.rst:17 -msgid "Specification" -msgstr "" - -#: ../source/specifications/direct-url.rst:19 -msgid "" -"The :file:`direct_url.json` file MUST be created in the :file:`*.dist-info` " -"directory by installers when installing a distribution from a requirement " -"specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/direct-url.rst:23 -#: ../source/specifications/recording-installed-packages.rst:206 -msgid "" -"This file MUST NOT be created when installing a distribution from an other " -"type of requirement (i.e. name plus version specifier)." -msgstr "" - -#: ../source/specifications/direct-url.rst:26 -msgid "" -"This JSON file MUST be a dictionary, compliant with `RFC 8259 `_ and UTF-8 encoded." -msgstr "" - -#: ../source/specifications/direct-url.rst:29 -msgid "" -"If present, it MUST contain at least two fields. The first one is ``url``, " -"with type ``string``. Depending on what ``url`` refers to, the second field " -"MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), " -"``archive_info`` (if ``url`` is a source archives or a wheel), or " -"``dir_info`` (if ``url`` is a local directory). These info fields have a " -"(possibly empty) subdictionary as value, with the possible keys defined " -"below." -msgstr "" - -#: ../source/specifications/direct-url.rst:36 -msgid "" -"``url`` MUST be stripped of any sensitive authentication information, for " -"security reasons." -msgstr "" - -#: ../source/specifications/direct-url.rst:39 -msgid "" -"The user:password section of the URL MAY however be composed of environment " -"variables, matching the following regular expression::" -msgstr "" - -#: ../source/specifications/direct-url.rst:45 -msgid "" -"Additionally, the user:password section of the URL MAY be a well-known, non " -"security sensitive string. A typical example is ``git`` in the case of an " -"URL such as ``ssh://git@gitlab.com/user/repo``." -msgstr "" - -#: ../source/specifications/direct-url.rst:49 -msgid "" -"When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be " -"present as a dictionary with the following keys:" -msgstr "" - -#: ../source/specifications/direct-url.rst:52 -msgid "" -"A ``vcs`` key (type ``string``) MUST be present, containing the name of the " -"VCS (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be " -"registered by writing a PEP to amend this specification. The ``url`` value " -"MUST be compatible with the corresponding VCS, so an installer can hand it " -"off without transformation to a checkout/download command of the VCS." -msgstr "" - -#: ../source/specifications/direct-url.rst:58 -msgid "" -"A ``requested_revision`` key (type ``string``) MAY be present naming a " -"branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) to " -"install." -msgstr "" - -#: ../source/specifications/direct-url.rst:61 -msgid "" -"A ``commit_id`` key (type ``string``) MUST be present, containing the exact " -"commit/revision number that was installed. If the VCS supports commit-hash " -"based revision identifiers, such commit-hash MUST be used as ``commit_id`` " -"in order to reference the immutable version of the source code that was " -"installed." -msgstr "" - -#: ../source/specifications/direct-url.rst:68 -msgid "" -"When ``url`` refers to a source archive or a wheel, the ``archive_info`` key " -"MUST be present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:71 -msgid "" -"A ``hash`` key (type ``string``) SHOULD be present, with value ``=``. It is RECOMMENDED that only hashes which are " -"unconditionally provided by the latest version of the standard library's " -"``hashlib`` module be used for source archive hashes. At time of writing, " -"that list consists of 'md5', 'sha1', 'sha224', 'sha256', 'sha384', and " -"'sha512'." -msgstr "" - -#: ../source/specifications/direct-url.rst:78 -msgid "" -"When ``url`` refers to a local directory, the ``dir_info`` key MUST be " -"present as a dictionary with the following key:" -msgstr "" - -#: ../source/specifications/direct-url.rst:81 -msgid "" -"``editable`` (type: ``boolean``): ``true`` if the distribution was installed " -"in editable mode, ``false`` otherwise. If absent, default to ``false``." -msgstr "" - -#: ../source/specifications/direct-url.rst:84 -msgid "" -"When ``url`` refers to a local directory, it MUST have the ``file`` sheme " -"and be compliant with `RFC 8089 `_. In " -"particular, the path component must be absolute. Symbolic links SHOULD be " -"preserved when making relative paths absolute." -msgstr "" - -#: ../source/specifications/direct-url.rst:91 -msgid "" -"When the requested URL has the file:// scheme and points to a local " -"directory that happens to contain a VCS checkout, installers MUST NOT " -"attempt to infer any VCS information and therefore MUST NOT output any VCS " -"related information (such as ``vcs_info``) in :file:`direct_url.json`." -msgstr "" - -#: ../source/specifications/direct-url.rst:96 -msgid "" -"A top-level ``subdirectory`` field MAY be present containing a directory " -"path, relative to the root of the VCS repository, source archive or local " -"directory, to specify where ``pyproject.toml`` or ``setup.py`` is located." -msgstr "" - -#: ../source/specifications/direct-url.rst:102 -msgid "" -"As a general rule, installers should as much as possible preserve the " -"information that was provided in the requested URL when generating :file:" -"`direct_url.json`. For example user:password environment variables should be " -"preserved and ``requested_revision`` should reflect the revision that was " -"provided in the requested URL as faithfully as possible. This information is " -"however *enriched* with more precise data, such as ``commit_id``." -msgstr "" - -#: ../source/specifications/direct-url.rst:110 -msgid "Registered VCS" -msgstr "" - -#: ../source/specifications/direct-url.rst:112 -msgid "" -"This section lists the registered VCS's; expanded, VCS-specific information " -"on how to use the ``vcs``, ``requested_revision``, and other fields of " -"``vcs_info``; and in some cases additional VCS-specific fields. Tools MAY " -"support other VCS's although it is RECOMMENDED to register them by writing a " -"PEP to amend this specification. The ``vcs`` field SHOULD be the command " -"name (lowercased). Additional fields that would be necessary to support such " -"VCS SHOULD be prefixed with the VCS command name." -msgstr "" - -#: ../source/specifications/direct-url.rst:122 -msgid "Git" -msgstr "" - -#: ../source/specifications/direct-url.rst:124 -#: ../source/specifications/direct-url.rst:156 -#: ../source/specifications/direct-url.rst:179 -#: ../source/specifications/direct-url.rst:202 -msgid "Home page" -msgstr "" - -#: ../source/specifications/direct-url.rst:126 -msgid "https://git-scm.com/" -msgstr "" - -#: ../source/specifications/direct-url.rst:128 -#: ../source/specifications/direct-url.rst:160 -#: ../source/specifications/direct-url.rst:183 -#: ../source/specifications/direct-url.rst:206 -msgid "vcs command" -msgstr "" - -#: ../source/specifications/direct-url.rst:130 -#: ../source/specifications/direct-url.rst:134 -msgid "git" -msgstr "" - -#: ../source/specifications/direct-url.rst:132 -#: ../source/specifications/direct-url.rst:164 -#: ../source/specifications/direct-url.rst:187 -#: ../source/specifications/direct-url.rst:210 -msgid "``vcs`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:136 -#: ../source/specifications/direct-url.rst:168 -#: ../source/specifications/direct-url.rst:191 -#: ../source/specifications/direct-url.rst:214 -msgid "``requested_revision`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:138 -msgid "" -"A tag name, branch name, Git ref, commit hash, shortened commit hash, or " -"other commit-ish." -msgstr "" - -#: ../source/specifications/direct-url.rst:141 -#: ../source/specifications/direct-url.rst:172 -#: ../source/specifications/direct-url.rst:195 -#: ../source/specifications/direct-url.rst:219 -msgid "``commit_id`` field" -msgstr "" - -#: ../source/specifications/direct-url.rst:143 -msgid "A commit hash (40 hexadecimal characters sha1)." -msgstr "" - -#: ../source/specifications/direct-url.rst:147 -msgid "" -"Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands to " -"determine if the ``requested_revision`` corresponds to a Git ref. In turn, a " -"ref beginning with ``refs/tags/`` corresponds to a tag, and a ref beginning " -"with ``refs/remotes/origin/`` after cloning corresponds to a branch." -msgstr "" - -#: ../source/specifications/direct-url.rst:154 -msgid "Mercurial" -msgstr "" - -#: ../source/specifications/direct-url.rst:158 -msgid "https://www.mercurial-scm.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:162 -#: ../source/specifications/direct-url.rst:166 -msgid "hg" -msgstr "" - -#: ../source/specifications/direct-url.rst:170 -msgid "A tag name, branch name, changeset ID, shortened changeset ID." -msgstr "" - -#: ../source/specifications/direct-url.rst:174 -msgid "A changeset ID (40 hexadecimal characters)." -msgstr "" - -#: ../source/specifications/direct-url.rst:177 -msgid "Bazaar" -msgstr "" - -#: ../source/specifications/direct-url.rst:181 -msgid "https://bazaar.canonical.com/" -msgstr "" - -#: ../source/specifications/direct-url.rst:185 -#: ../source/specifications/direct-url.rst:189 -msgid "bzr" -msgstr "" - -#: ../source/specifications/direct-url.rst:193 -msgid "A tag name, branch name, revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:197 -msgid "A revision id." -msgstr "" - -#: ../source/specifications/direct-url.rst:200 -msgid "Subversion" -msgstr "" - -#: ../source/specifications/direct-url.rst:204 -msgid "https://subversion.apache.org/" -msgstr "" - -#: ../source/specifications/direct-url.rst:208 -#: ../source/specifications/direct-url.rst:212 -msgid "svn" -msgstr "" - -#: ../source/specifications/direct-url.rst:216 -msgid "" -"``requested_revision`` must be compatible with ``svn checkout`` ``--" -"revision`` option. In Subversion, branch or tag is part of ``url``." -msgstr "" - -#: ../source/specifications/direct-url.rst:221 -msgid "" -"Since Subversion does not support globally unique identifiers, this field is " -"the Subversion revision number in the corresponding repository." -msgstr "" - -#: ../source/specifications/direct-url.rst:229 -msgid "Example direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:231 -msgid "Source archive:" -msgstr "" - -#: ../source/specifications/direct-url.rst:242 -msgid "Git URL with tag and commit-hash:" -msgstr "" - -#: ../source/specifications/direct-url.rst:255 -msgid "Local directory:" -msgstr "" - -#: ../source/specifications/direct-url.rst:264 -msgid "Local directory installed in editable mode:" -msgstr "" - -#: ../source/specifications/direct-url.rst:277 -msgid "Example pip commands and their effect on direct_url.json" -msgstr "" - -#: ../source/specifications/direct-url.rst:279 -msgid "Commands that generate a ``direct_url.json``:" -msgstr "" - -#: ../source/specifications/direct-url.rst:281 -msgid "pip install https://example.com/app-1.0.tgz" -msgstr "" - -#: ../source/specifications/direct-url.rst:282 -msgid "pip install https://example.com/app-1.0.whl" -msgstr "" - -#: ../source/specifications/direct-url.rst:283 -msgid "" -"pip install \"git+https://example.com/repo/app.git#egg=app&subdirectory=setup" -"\"" -msgstr "" - -#: ../source/specifications/direct-url.rst:284 -msgid "pip install ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:285 -msgid "pip install file:///home/user/app" -msgstr "" - -#: ../source/specifications/direct-url.rst:286 -msgid "" -"pip install --editable \"git+https://example.com/repo/app." -"git#egg=app&subdirectory=setup\" (in which case, ``url`` will be the local " -"directory where the git repository has been cloned to, and ``dir_info`` will " -"be present with ``\"editable\": true`` and no ``vcs_info`` will be set)" -msgstr "" - -#: ../source/specifications/direct-url.rst:290 -msgid "pip install -e ./app" -msgstr "" - -#: ../source/specifications/direct-url.rst:292 -msgid "Commands that *do not* generate a ``direct_url.json``" -msgstr "" - -#: ../source/specifications/direct-url.rst:294 -msgid "pip install app" -msgstr "" - -#: ../source/specifications/direct-url.rst:295 -msgid "pip install app --no-index --find-links https://example.com/" -msgstr "" - -#: ../source/specifications/entry-points.rst:5 -msgid "Entry points specification" -msgstr "" - -#: ../source/specifications/entry-points.rst:7 -msgid "" -"*Entry points* are a mechanism for an installed distribution to advertise " -"components it provides to be discovered and used by other code. For example:" -msgstr "" - -#: ../source/specifications/entry-points.rst:11 -msgid "" -"Distributions can specify ``console_scripts`` entry points, each referring " -"to a function. When *pip* (or another console_scripts aware installer) " -"installs the distribution, it will create a command-line wrapper for each " -"entry point." -msgstr "" - -#: ../source/specifications/entry-points.rst:14 -msgid "" -"Applications can use entry points to load plugins; e.g. Pygments (a syntax " -"highlighting tool) can use additional lexers and styles from separately " -"installed packages. For more about this, see :doc:`/guides/creating-and-" -"discovering-plugins`." -msgstr "" - -#: ../source/specifications/entry-points.rst:19 -msgid "" -"The entry point file format was originally developed to allow packages built " -"with setuptools to provide integration point metadata that would be read at " -"runtime with ``importlib.metadata``. It is now defined as a PyPA " -"interoperability specification in order to allow build tools other than " -"setuptools to publish ``importlib.metadata`` compatible entry point " -"metadata, and runtime libraries other than ``importlib.metadata`` to " -"portably read published entry point metadata (potentially with different " -"caching and conflict resolution strategies)." -msgstr "" - -#: ../source/specifications/entry-points.rst:28 -msgid "Data model" -msgstr "" - -#: ../source/specifications/entry-points.rst:30 -msgid "Conceptually, an entry point is defined by three required properties:" -msgstr "" - -#: ../source/specifications/entry-points.rst:32 -msgid "" -"The **group** that an entry point belongs to indicates what sort of object " -"it provides. For instance, the group ``console_scripts`` is for entry points " -"referring to functions which can be used as a command, while ``pygments." -"styles`` is the group for classes defining pygments styles. The consumer " -"typically defines the expected interface. To avoid clashes, consumers " -"defining a new group should use names starting with a PyPI name owned by the " -"consumer project, followed by ``.``. Group names must be one or more groups " -"of letters, numbers and underscores, separated by dots (regex ``^\\w+(\\.\\w" -"+)*$``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:42 -msgid "" -"The **name** identifies this entry point within its group. The precise " -"meaning of this is up to the consumer. For console scripts, the name of the " -"entry point is the command that will be used to launch it. Within a " -"distribution, entry point names should be unique. If different distributions " -"provide the same name, the consumer decides how to handle such conflicts. " -"The name may contain any characters except ``=``, but it cannot start or end " -"with any whitespace character, or start with ``[``. For new entry points, it " -"is recommended to use only letters, numbers, underscores, dots and dashes " -"(regex ``[\\w.-]+``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:51 -msgid "" -"The **object reference** points to a Python object. It is either in the form " -"``importable.module``, or ``importable.module:object.attr``. Each of the " -"parts delimited by dots and the colon is a valid Python identifier. It is " -"intended to be looked up like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:64 -msgid "" -"Some tools call this kind of object reference by itself an 'entry point', " -"for want of a better term, especially where it points to a function to " -"launch a program." -msgstr "" - -#: ../source/specifications/entry-points.rst:68 -msgid "" -"There is also an optional property: the **extras** are a set of strings " -"identifying optional features of the distribution providing the entry point. " -"If these are specified, the entry point requires the dependencies of those " -"'extras'. See the metadata field :ref:`metadata_provides_extra`." -msgstr "" - -#: ../source/specifications/entry-points.rst:73 -msgid "" -"Using extras for an entry point is no longer recommended. Consumers should " -"support parsing them from existing distributions, but may then ignore them. " -"New publishing tools need not support specifying extras. The functionality " -"of handling extras was tied to setuptools' model of managing 'egg' packages, " -"but newer tools such as pip and virtualenv use a different model." -msgstr "" - -#: ../source/specifications/entry-points.rst:80 -msgid "File format" -msgstr "" - -#: ../source/specifications/entry-points.rst:82 -msgid "" -"Entry points are defined in a file called :file:`entry_points.txt` in the :" -"file:`*.dist-info` directory of the distribution. This is the directory " -"described in :pep:`376` for installed distributions, and in :pep:`427` for " -"wheels. The file uses the UTF-8 character encoding." -msgstr "" - -#: ../source/specifications/entry-points.rst:87 -msgid "" -"The file contents are in INI format, as read by Python's :mod:`configparser` " -"module. However, configparser treats names as case-insensitive by default, " -"whereas entry point names are case sensitive. A case-sensitive config parser " -"can be made like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:97 -msgid "" -"The entry points file must always use ``=`` to delimit names from values " -"(whereas configparser also allows using ``:``)." -msgstr "" - -#: ../source/specifications/entry-points.rst:100 -msgid "" -"The sections of the config file represent entry point groups, the names are " -"names, and the values encode both the object reference and the optional " -"extras. If extras are used, they are a comma-separated list inside square " -"brackets." -msgstr "" - -#: ../source/specifications/entry-points.rst:104 -msgid "" -"Within a value, readers must accept and ignore spaces (including multiple " -"consecutive spaces) before or after the colon, between the object reference " -"and the left square bracket, between the extra names and the square brackets " -"and colons delimiting them, and after the right square bracket. The syntax " -"for extras is formally specified as part of :pep:`508` (as ``extras``). For " -"tools writing the file, it is recommended only to insert a space between the " -"object reference and the left square bracket." -msgstr "" - -#: ../source/specifications/entry-points.rst:112 -msgid "For example::" -msgstr "" - -#: ../source/specifications/entry-points.rst:124 -msgid "Use for scripts" -msgstr "" - -#: ../source/specifications/entry-points.rst:126 -msgid "" -"Two groups of entry points have special significance in packaging: " -"``console_scripts`` and ``gui_scripts``. In both groups, the name of the " -"entry point should be usable as a command in a system shell after the " -"package is installed. The object reference points to a function which will " -"be called with no arguments when this command is run. The function may " -"return an integer to be used as a process exit code, and returning ``None`` " -"is equivalent to returning ``0``." -msgstr "" - -#: ../source/specifications/entry-points.rst:134 -msgid "" -"For instance, the entry point ``mycmd = mymod:main`` would create a command " -"``mycmd`` launching a script like this::" -msgstr "" - -#: ../source/specifications/entry-points.rst:141 -msgid "" -"The difference between ``console_scripts`` and ``gui_scripts`` only affects " -"Windows systems. ``console_scripts`` are wrapped in a console executable, so " -"they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and " -"``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI " -"executable, so they can be started without a console, but cannot use " -"standard streams unless application code redirects them. Other platforms do " -"not have the same distinction." -msgstr "" - -#: ../source/specifications/entry-points.rst:149 -msgid "" -"Install tools are expected to set up wrappers for both ``console_scripts`` " -"and ``gui_scripts`` in the scripts directory of the install scheme. They are " -"not responsible for putting this directory in the ``PATH`` environment " -"variable which defines where command-line tools are found." -msgstr "" - -#: ../source/specifications/entry-points.rst:154 -msgid "" -"As files are created from the names, and some filesystems are case-" -"insensitive, packages should avoid using names in these groups which differ " -"only in case. The behaviour of install tools when names differ only in case " -"is undefined." -msgstr "" - -#: ../source/specifications/index.rst:4 -msgid "PyPA specifications" -msgstr "" - -#: ../source/specifications/index.rst:6 -msgid "" -"This is a list of currently active interoperability specifications " -"maintained by the Python Packaging Authority. The process for updating these " -"standards, and for proposing new ones, is documented on `pypa.io `__." -msgstr "" - -#: ../source/specifications/index.rst:13 -msgid "Package Distribution Metadata" -msgstr "" - -#: ../source/specifications/index.rst:30 -msgid "Package Distribution File Formats" -msgstr "" - -#: ../source/specifications/index.rst:40 -msgid "Package Index Interfaces" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:6 -msgid "Platform compatibility tags" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:8 -msgid "" -"Platform compatibility tags allow build tools to mark distributions as being " -"compatible with specific platforms, and allows installers to understand " -"which distributions are compatible with the system they are running on." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:12 -msgid "" -"The platform compatibility tagging model used for the ``wheel`` distribution " -"format is defined in :pep:`425`." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:16 -msgid "Platform tags for Windows" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:18 -msgid "" -"The scheme defined in :pep:`425` covers public distribution of wheel files " -"to systems running Windows." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:22 -msgid "Platform tags for macOS (Mac OS X)" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:24 -msgid "" -"The scheme defined in :pep:`425` covers public distribution of wheel files " -"to systems running macOS (previously known as Mac OS X)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:28 -msgid "Platform tags for common Linux distributions" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:32 -msgid "" -"The scheme defined in :pep:`425` is insufficient for public distribution of " -"wheel files (and \\*nix wheel files in general) to Linux platforms, due to " -"the large ecosystem of Linux platforms and subtle differences between them." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:36 -msgid "" -"Instead, :pep:`600` defines the ``manylinux`` standard, which represents a " -"common subset of Linux platforms, and allows building wheels tagged with the " -"``manylinux`` platform tag which can be used across most common Linux " -"distributions." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:41 -msgid "" -"There were multiple iterations of the ``manylinux`` specification, each " -"representing the common subset of Linux platforms at a given point in time:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:44 -msgid "" -"``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686`` architectures, " -"and is based on a compatible Linux platform from 2007." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:46 -msgid "" -"``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686`` " -"architectures. and updates the previous specification to be based on a " -"compatible Linux platform from 2010 instead." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:49 -msgid "" -"``manylinux2014`` (:pep:`599`) adds support for a number of additional " -"architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``, and " -"``s390x``) and updates the base platform to a compatible Linux platform from " -"2014." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:54 -msgid "" -"``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a " -"future-proof standard. It defines ``x`` and ``y`` as glibc major an minor " -"versions supported (e.g. ``manylinux_2_24`` should work on any distro using " -"glibc 2.24+). Previous tags are still supported for backward compatibility." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:59 -msgid "" -"In general, distributions built for older versions of the specification are " -"forwards-compatible (meaning that ``manylinux1`` distributions should " -"continue to work on modern systems) but not backwards-compatible (meaning " -"that ``manylinux2010`` distributions are not expected to work on platforms " -"that existed before 2010)." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:65 -msgid "" -"Package maintainers should attempt to target the most compatible " -"specification possible, with the caveat that the provided build environment " -"for ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning " -"that these images will no longer receive security updates." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:71 -msgid "Manylinux compatibility support" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:74 -msgid "" -"The ``manylinux2014`` specification is relatively new and is not yet widely " -"recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:76 -msgid "" -"The ``manylinux_x_y`` specification is relatively new and is not yet widely " -"recognised by install tools." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:79 -msgid "" -"The following table shows the minimum versions of relevant projects to " -"support the various ``manylinux`` standards:" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "Tool" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux1``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2010``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux2014``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:83 -msgid "``manylinux_x_y``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=8.1.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=19.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:85 -msgid "``>=20.3``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "auditwheel" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=1.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=2.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.0.0``" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:86 -msgid "``>=3.3.0`` [#]_" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:90 -msgid "Platform tags for other \\*nix platforms" -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:92 -msgid "" -"The scheme defined in :pep:`425` is not generally sufficient for public " -"distribution of wheel files to other \\*nix platforms. Efforts are currently " -"(albeit intermittently) under way to define improved compatibility tagging " -"schemes for AIX and for Alpine Linux." -msgstr "" - -#: ../source/specifications/platform-compatibility-tags.rst:98 -msgid "Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0" -msgstr "" - -#: ../source/specifications/pypirc.rst:6 -msgid "The :file:`.pypirc` file" -msgstr "" - -#: ../source/specifications/pypirc.rst:8 -msgid "" -"A :file:`.pypirc` file allows you to define the configuration for :term:" -"`package indexes ` (referred to here as \"repositories\"), so " -"that you don't have to enter the URL, username, or password whenever you " -"upload a package with :ref:`twine` or :ref:`flit`." -msgstr "" - -#: ../source/specifications/pypirc.rst:13 -msgid "The format (originally defined by the :ref:`distutils` package) is:" -msgstr "" - -#: ../source/specifications/pypirc.rst:32 -msgid "" -"The ``distutils`` section defines an ``index-servers`` field that lists the " -"name of all sections describing a repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:35 -msgid "Each section describing a repository defines three fields:" -msgstr "" - -#: ../source/specifications/pypirc.rst:37 -msgid "``repository``: The URL of the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:38 -msgid "``username``: The registered username on the repository." -msgstr "" - -#: ../source/specifications/pypirc.rst:39 -msgid "``password``: The password that will used to authenticate the username." -msgstr "" - -#: ../source/specifications/pypirc.rst:43 -msgid "" -"Be aware that this stores your password in plain text. For better security, " -"consider an alternative like `keyring`_, setting environment variables, or " -"providing the password on the command line." -msgstr "" - -#: ../source/specifications/pypirc.rst:47 -msgid "" -"Otherwise, set the permissions on :file:`.pypirc` so that only you can view " -"or modify it. For example, on Linux or macOS, run:" -msgstr "" - -#: ../source/specifications/pypirc.rst:57 -msgid "Common configurations" -msgstr "" - -#: ../source/specifications/pypirc.rst:61 -msgid "" -"These examples apply to :ref:`twine`, and projects like :ref:`hatch` that " -"use it under the hood. Other projects (e.g. :ref:`flit`) also use :file:`." -"pypirc`, but with different defaults. Please refer to each project's " -"documentation for more details and usage instructions." -msgstr "" - -#: ../source/specifications/pypirc.rst:66 -msgid "" -"Twine's default configuration mimics a :file:`.pypirc` with repository " -"sections for PyPI and TestPyPI:" -msgstr "" - -#: ../source/specifications/pypirc.rst:82 -msgid "" -"Twine will add additional configuration from :file:`$HOME/.pypirc`, the " -"command line, and environment variables to this default configuration." -msgstr "" - -#: ../source/specifications/pypirc.rst:86 -msgid "Using a PyPI token" -msgstr "" - -#: ../source/specifications/pypirc.rst:88 -msgid "" -"To set your `API token`_ for PyPI, you can create a :file:`$HOME/.pypirc` " -"similar to:" -msgstr "" - -#: ../source/specifications/pypirc.rst:97 -msgid "" -"For :ref:`TestPyPI `, add a ``[testpypi]`` section, using " -"the API token from your TestPyPI account." -msgstr "" - -#: ../source/specifications/pypirc.rst:103 -msgid "Using another package index" -msgstr "" - -#: ../source/specifications/pypirc.rst:105 -msgid "" -"To configure an additional repository, you'll need to redefine the ``index-" -"servers`` field to include the repository name. Here is a complete example " -"of a :file:`$HOME/.pypirc` for PyPI, TestPyPI, and a private repository:" -msgstr "" - -#: ../source/specifications/pypirc.rst:132 -msgid "" -"Instead of using the ``password`` field, consider saving your API tokens and " -"passwords securely using `keyring`_ (which is installed by Twine):" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:5 -msgid "Recording installed projects" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:7 -msgid "" -"This document specifies a common format of recording information about " -"Python :term:`projects ` installed in an environment. A common " -"metadata format allows tools to query, manage or uninstall projects, " -"regardless of how they were installed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:12 -msgid "" -"Almost all information is optional. This allows tools outside the Python " -"ecosystem, such as Linux package managers, to integrate with Python tooling " -"as much as possible. For example, even if an installer cannot easily provide " -"a list of installed files in a format specific to Python tooling, it should " -"still record the name and version of the installed project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:21 -msgid "History and change workflow" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:23 -msgid "" -"The metadata described here was first specified in :pep:`376`, and later " -"amended in :pep:`627`. It was formerly known as *Database of Installed " -"Python Distributions*. Further amendments (except trivial language or " -"typography fixes) must be made through the PEP process (see :pep:`1`)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:29 -msgid "" -"While this document is the normative specification, these PEPs that " -"introduce changes to it may include additional information such as " -"rationales and backwards compatibility considerations." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:37 -msgid "" -"Each project installed from a distribution must, in addition to files, " -"install a \"``.dist-info``\" directory located alongside importable modules " -"and packages (commonly, the ``site-packages`` directory)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:41 -msgid "" -"This directory is named as ``{name}-{version}.dist-info``, with ``name`` and " -"``version`` fields corresponding to :ref:`core-metadata`. Both fields must " -"be normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 " -"<440#normalization>` for the definition of normalization for each field " -"respectively), and replace dash (``-``) characters with underscore (``_``) " -"chacaters, so the ``.dist-info`` directory always has exactly one dash (``-" -"``) character in its stem, separating the ``name`` and ``version`` fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:50 -msgid "" -"Historically, tools have failed to replace dot characters or normalize case " -"in the ``name`` field, or not perform normalization in the ``version`` " -"field. Tools consuming ``.dist-info`` directories should expect those fields " -"to be unnormalized, and treat them as equivalent to their normalized " -"counterparts. New tools that write ``.dist-info`` directories MUST normalize " -"both ``name`` and ``version`` fields using the rules described above, and " -"existing tools are encouraged to start normalizing those fields." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:60 -msgid "" -"The ``.dist-info`` directory's name is formatted to unambigiously represent " -"a distribution as a filesystem path. Tools presenting a distribution name to " -"a user should avoid using the normalized name, and instead present the " -"specified name (when needed prior to resolution to an installed package), or " -"read the respective fields in Core Metadata, since values listed there are " -"unescaped and accurately reflect the distribution. Libraries should provide " -"API for such tools to consume, so tools can have access to the unnormalized " -"name when displaying distrubution information." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:69 -msgid "" -"This ``.dist-info`` directory can contain these files, described in detail " -"below:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:72 -msgid "``METADATA``: contains project metadata" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:73 -msgid "``RECORD``: records the list of installed files." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:74 -msgid "" -"``INSTALLER``: records the name of the tool used to install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:76 -msgid "" -"The ``METADATA`` file is mandatory. All other files may be omitted at the " -"installing tool's discretion. Additional installer-specific files may be " -"present." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:82 -msgid "" -"The :ref:`binary-distribution-format` specification describes additional " -"files that may appear in the ``.dist-info`` directory of a :term:`Wheel`. " -"Such files may be copied to the ``.dist-info`` directory of an installed " -"project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:87 -msgid "" -"The previous versions of this specification also specified a ``REQUESTED`` " -"file. This file is now considered a tool-specific extension, but may be " -"standardized again in the future. See `PEP 376 `_ for its original meaning." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:94 -msgid "The METADATA file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:96 -msgid "" -"The ``METADATA`` file contains metadata as described in the :ref:`core-" -"metadata` specification, version 1.1 or greater." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:99 -msgid "" -"The ``METADATA`` file is mandatory. If it cannot be created, or if required " -"core metadata is not available, installers must report an error and fail to " -"install the project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:105 -msgid "The RECORD file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:107 -msgid "" -"The ``RECORD`` file holds the list of installed files. It is a CSV file " -"containing one record (line) per installed file." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:110 -msgid "" -"The CSV dialect must be readable with the default ``reader`` of Python's " -"``csv`` module:" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:113 -msgid "field delimiter: ``,`` (comma)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:114 -msgid "quoting char: ``\"`` (straight double quote)," -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:115 -msgid "line terminator: either ``\\r\\n`` or ``\\n``." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:117 -msgid "" -"Each record is composed of three elements: the file's **path**, the **hash** " -"of the contents, and its **size**." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:120 -msgid "" -"The *path* may be either absolute, or relative to the directory containing " -"the ``.dist-info`` directory (commonly, the ``site-packages`` directory). On " -"Windows, directories may be separated either by forward- or backslashes (``/" -"`` or ``\\``)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:125 -msgid "" -"The *hash* is either an empty string or the name of a hash algorithm from " -"``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` " -"and the digest of the file's contents, encoded with the urlsafe-base64-nopad " -"encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:130 -msgid "" -"The *size* is either the empty string, or file's size in bytes, as a base 10 " -"integer." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:133 -msgid "" -"For any file, either or both of the *hash* and *size* fields may be left " -"empty. Commonly, entries for ``.pyc`` files and the ``RECORD`` file itself " -"have empty *hash* and *size*. For other files, leaving the information out " -"is discouraged, as it prevents verifying the integrity of the installed " -"project." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:139 -msgid "" -"If the ``RECORD`` file is present, it must list all installed files of the " -"project, except ``.pyc`` files corresponding to ``.py`` files listed in " -"``RECORD``, which are optional. Notably, the contents of the ``.dist-info`` " -"directory (including the ``RECORD`` file itself) must be listed. Directories " -"should not be listed." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:146 -msgid "" -"To completely uninstall a package, a tool needs to remove all files listed " -"in ``RECORD``, all ``.pyc`` files (of all optimization levels) corresponding " -"to removed ``.py`` files, and any directories emptied by the uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:151 -msgid "Here is an example snippet of a possible ``RECORD`` file::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:170 -msgid "" -"If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must " -"not atempt to uninstall or upgrade the package. (This does not apply to " -"tools that rely on other sources of information, such as system package " -"managers in Linux distros.)" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:177 -msgid "The INSTALLER file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:179 -msgid "" -"If present, ``INSTALLER`` is a single-line text file naming the tool used to " -"install the project. If the installer is executable from the command line, " -"``INSTALLER`` should contain the command name. Otherwise, it should contain " -"a printable ASCII string." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:185 -msgid "The file can be terminated by zero or more ASCII whitespace characters." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:187 -msgid "Here are examples of two possible ``INSTALLER`` files::" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:195 -msgid "" -"This value should be used for informational purposes only. For example, if a " -"tool is asked to uninstall a project but finds no ``RECORD`` file, it may " -"suggest that the tool named in ``INSTALLER`` may be able to do the " -"uninstallation." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:201 -msgid "The direct_url.json file" -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:203 -msgid "" -"This file MUST be created by installers when installing a distribution from " -"a requirement specifying a direct URL reference (including a VCS URL)." -msgstr "" - -#: ../source/specifications/recording-installed-packages.rst:209 -msgid "Its detailed specification is at :ref:`direct-url`." -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:6 -msgid "Simple repository API" -msgstr "" - -#: ../source/specifications/simple-repository-api.rst:8 -msgid "" -"The current interface for querying available package versions and retrieving " -"packages from an index server is defined in :pep:`503`, with the addition of " -"\"yank\" support (allowing a kind of file deletion) as defined in :pep:`592` " -"and specifying the interface version provided by an index server in :pep:" -"`629`." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:6 -msgid "Source distribution format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:8 -msgid "" -"The current standard format of source distribution format is identified by " -"the presence of a :file:`pyproject.toml` file in the distribution archive. " -"The layout of such a distribution was originally specified in :pep:`517` and " -"is formally documented here." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:13 -msgid "" -"There is also the legacy source distribution format, implicitly defined by " -"the behaviour of ``distutils`` module in the standard library, when " -"executing :command:`setup.py sdist`. This document does not attempt to " -"standardise this format, except to note that if a legacy source distribution " -"contains a ``PKG-INFO`` file using metadata version 2.2 or later, then it " -"MUST follow the rules applicable to source distributions defined in the " -"metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:21 -msgid "Source distributions are also known as *sdists* for short." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:24 -msgid "Source distribution file name" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:26 -msgid "" -"The file name of a sdist is not currently standardised, although the *de " -"facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the " -"canonicalized form of the project name (see :pep:`503` for the " -"canonicalization rules) with ``-`` characters replaced with ``_``, and " -"``{version}`` is the project version." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:31 -msgid "" -"The name and version components of the filename MUST match the values stored " -"in the metadata contained in the file." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:35 -msgid "Source distribution file format" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:37 -msgid "" -"A ``.tar.gz`` source distribution (sdist) contains a single top-level " -"directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the " -"source files of the package. The name and version MUST match the metadata " -"stored in the file. This directory must also contain a :file:`pyproject." -"toml` in the format defined in :ref:`declaring-build-dependencies`, and a " -"``PKG-INFO`` file containing metadata in the format described in the :ref:" -"`core-metadata` specification. The metadata MUST conform to at least version " -"2.2 of the metadata specification." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:45 -msgid "" -"No other content of a sdist is required or defined. Build systems can store " -"whatever information they need in the sdist to build the project." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:48 -msgid "" -"The tarball should use the modern POSIX.1-2001 pax tar format, which " -"specifies UTF-8 based file names." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:6 -msgid "Version specifiers" -msgstr "" - -#: ../source/specifications/version-specifiers.rst:8 -msgid "" -"Version numbering requirements and the semantics for specifying comparisons " -"between versions are defined in :pep:`440`." -msgstr "" - -#: ../source/specifications/version-specifiers.rst:11 -msgid "" -"The version specifiers section in this PEP supersedes the version specifiers " -"section in :pep:`345`." -msgstr "" - -#: ../source/support.rst:3 -msgid "How to Get Support" -msgstr "" - -#: ../source/support.rst:5 -msgid "" -"For support related to a specific project, see the links on the :doc:" -"`Projects ` page." -msgstr "" - -#: ../source/support.rst:8 -msgid "" -"For something more general, or when you're just not sure, please `open an " -"issue `_ on the " -"`packaging-problems `_ " -"repository on GitHub." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:5 -msgid "Creating Documentation" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:7 -msgid "" -"This section covers the basics of how to create documentation using " -"`Sphinx`_ and host the documentation for free in `Read The Docs`_." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:13 -msgid "Installing Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:14 -msgid "Use ``pip`` to install Sphinx:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:28 -msgid "" -"For other installation methods, see this `installation guide`_ by Sphinx." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:33 -msgid "Getting Started With Sphinx" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:35 -msgid "" -"Create a ``docs`` directory inside your project to hold your documentation:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:42 -msgid "Run ``sphinx-quickstart`` inside the ``docs`` directory:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:49 -msgid "" -"This sets up a source directory, walks you through some basic " -"configurations, and creates an ``index.rst`` file as well as a ``conf.py`` " -"file." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:51 -msgid "" -"You can add some information about your project in ``index.rst``, then build " -"them:" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:57 -msgid "" -"For more details on the build process, see this `guide`_ by Read The Docs." -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:62 -msgid "Other Sources" -msgstr "" - -#: ../source/tutorials/creating-documentation.rst:64 -msgid "" -"For a more detailed guide on how to use Sphinx and reStructuredText, please " -"see this `documentation tutorial`_ on Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/index.rst:4 -msgid "" -"**Tutorials** are opinionated step-by-step guides to help you get familiar " -"with packaging concepts. For more detailed information on specific packaging " -"topics, see :doc:`/guides/index`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:5 -msgid "Installing Packages" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:7 -msgid "" -"This section covers the basics of how to install Python :term:`packages " -"`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:10 -msgid "" -"It's important to note that the term \"package\" in this context is being " -"used to describe a bundle of software to be installed (i.e. as a synonym for " -"a :term:`distribution `). It does not to refer to the " -"kind of :term:`package ` that you import in your Python " -"source code (i.e. a container of modules). It is common in the Python " -"community to refer to a :term:`distribution ` using " -"the term \"package\". Using the term \"distribution\" is often not " -"preferred, because it can easily be confused with a Linux distribution, or " -"another larger software distribution like Python itself." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:28 -msgid "Requirements for Installing Packages" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:30 -msgid "" -"This section describes the steps to follow before installing other Python " -"packages." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:35 -msgid "Ensure you can run Python from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:37 -msgid "" -"Before you go any further, make sure you have Python and that the expected " -"version is available from your command line. You can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:53 -msgid "" -"You should get some output like ``Python 3.6.3``. If you do not have Python, " -"please install the latest 3.x version from `python.org`_ or refer to the " -"`Installing Python`_ section of the Hitchhiker's Guide to Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:57 -msgid "If you're a newcomer and you get an error like this:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:66 -msgid "" -"It's because this command and other suggested commands in this tutorial are " -"intended to be run in a *shell* (also called a *terminal* or *console*). See " -"the Python for Beginners `getting started tutorial`_ for an introduction to " -"using your operating system's shell and interacting with Python." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:72 -msgid "" -"If you're using an enhanced shell like IPython or the Jupyter notebook, you " -"can run system commands like those in this tutorial by prefacing them with a " -"``!`` character:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:82 -msgid "" -"It's recommended to write ``{sys.executable}`` rather than plain ``python`` " -"in order to ensure that commands are run in the Python installation matching " -"the currently running notebook (which may not be the same Python " -"installation that the ``python`` command refers to)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:87 -msgid "" -"Due to the way most Linux distributions are handling the Python 3 migration, " -"Linux users using the system Python without creating a virtual environment " -"first should replace the ``python`` command in this tutorial with " -"``python3`` and the ``python -m pip`` command with ``python3 -m pip --" -"user``. Do *not* run any of the commands in this tutorial with ``sudo``: if " -"you get a permissions error, come back to the section on creating virtual " -"environments, set one up, and then continue with the tutorial as written." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:99 -msgid "Ensure you can run pip from the command line" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:101 -msgid "" -"Additionally, you'll need to make sure you have :ref:`pip` available. You " -"can check this by running:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:116 -msgid "" -"If you installed Python from source, with an installer from `python.org`_, " -"or via `Homebrew`_ you should already have pip. If you're on Linux and " -"installed using your OS package manager, you may have to install pip " -"separately, see :doc:`/guides/installing-using-linux-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:124 -msgid "" -"If ``pip`` isn't already installed, then first try to bootstrap it from the " -"standard library:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:139 -msgid "If that still doesn't allow you to run ``python -m pip``:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:141 -msgid "" -"Securely Download `get-pip.py `_ [1]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:144 -msgid "" -"Run ``python get-pip.py``. [2]_ This will install or upgrade pip. " -"Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're " -"not installed already." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:150 -msgid "" -"Be cautious if you're using a Python install that's managed by your " -"operating system or another package manager. get-pip.py does not coordinate " -"with those tools, and may leave your system in an inconsistent state. You " -"can use ``python get-pip.py --prefix=/usr/local/`` to install in ``/usr/" -"local`` which is designed for locally-installed software." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:159 -msgid "Ensure pip, setuptools, and wheel are up to date" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:161 -msgid "" -"While ``pip`` alone is sufficient to install from pre-built binary archives, " -"up to date copies of the ``setuptools`` and ``wheel`` projects are useful to " -"ensure you can also install from source archives::" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:169 -msgid "Optionally, create a virtual environment" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:171 -msgid "" -"See :ref:`section below ` for " -"details, but here's the basic `venv`_ [3]_ command to use on a typical Linux " -"system:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:188 -msgid "" -"This will create a new virtual environment in the ``tutorial_env`` " -"subdirectory, and configure the current shell to use it as the default " -"``python`` environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:195 -msgid "Creating Virtual Environments" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:197 -msgid "" -"Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular " -"application, rather than being installed globally. If you are looking to " -"safely install global command line tools, see :doc:`/guides/installing-stand-" -"alone-command-line-tools`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:203 -msgid "" -"Imagine you have an application that needs version 1 of LibFoo, but another " -"application requires version 2. How can you use both these applications? If " -"you install everything into /usr/lib/python3.6/site-packages (or whatever " -"your platform’s standard location is), it’s easy to end up in a situation " -"where you unintentionally upgrade an application that shouldn’t be upgraded." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:209 -msgid "" -"Or more generally, what if you want to install an application and leave it " -"be? If an application works, any change in its libraries or the versions of " -"those libraries can break the application." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:213 -msgid "" -"Also, what if you can’t install :term:`packages ` into " -"the global site-packages directory? For instance, on a shared host." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:216 -msgid "" -"In all these cases, virtual environments can help you. They have their own " -"installation directories and they don’t share libraries with other virtual " -"environments." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:220 -msgid "" -"Currently, there are two common tools for creating Python virtual " -"environments:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:222 -msgid "" -"`venv`_ is available by default in Python 3.3 and later, and installs :ref:" -"`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 " -"and later." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:225 -msgid "" -":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ " -"and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are " -"always installed into created virtual environments by default (regardless of " -"Python version)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:230 -msgid "The basic usage is like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:232 -msgid "Using `venv`_:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:248 -msgid "Using :ref:`virtualenv`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:264 -msgid "" -"For more information, see the `venv`_ docs or the `virtualenv `_ docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:266 -msgid "" -"The use of :command:`source` under Unix shells ensures that the virtual " -"environment's variables are set within the current shell, and not in a " -"subprocess (which then disappears, having no useful effect)." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:271 -msgid "" -"In both of the above cases, Windows users should _not_ use the :command:" -"`source` command, but should rather run the :command:`activate` script " -"directly from the command shell like so:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:281 -msgid "" -"Managing multiple virtual environments directly can become tedious, so the :" -"ref:`dependency management tutorial ` introduces a " -"higher level tool, :ref:`Pipenv`, that automatically manages a separate " -"virtual environment for each project and application that you work on." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:288 -msgid "Use pip for Installing" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:290 -msgid "" -":ref:`pip` is the recommended installer. Below, we'll cover the most common " -"usage scenarios. For more detail, see the `pip docs `_, " -"which includes a complete `Reference Guide `_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:297 -msgid "Installing from PyPI" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:299 -msgid "" -"The most common usage of :ref:`pip` is to install from the :term:`Python " -"Package Index ` using a :term:`requirement " -"specifier `. Generally speaking, a requirement " -"specifier is composed of a project name followed by an optional :term:" -"`version specifier `. :pep:`440` contains a :pep:`full " -"specification <440#version-specifiers>` of the currently supported " -"specifiers. Below are some examples." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:307 -msgid "To install the latest version of \"SomeProject\":" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:321 -msgid "To install a specific version:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:335 -msgid "To install greater than or equal to one version and less than another:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:350 -msgid "" -"To install a version that's :pep:`\"compatible\" <440#compatible-release>` " -"with a certain version: [4]_" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:365 -msgid "" -"In this case, this means to install any version \"==1.4.*\" version that's " -"also \">=1.4.2\"." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:370 -msgid "Source Distributions vs Wheels" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:372 -msgid "" -":ref:`pip` can install from either :term:`Source Distributions (sdist) " -"` or :term:`Wheels `, but if both " -"are present on PyPI, pip will prefer a compatible :term:`wheel `. You " -"can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:378 -msgid "" -":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source " -"Distributions (sdist) `, especially when " -"a project contains compiled extensions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:383 -msgid "" -"If :ref:`pip` does not find a wheel to install, it will locally build a " -"wheel and cache it for future installs, instead of rebuilding the source " -"distribution in the future." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:391 -msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:408 -msgid "Installing to the User Site" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:410 -msgid "" -"To install :term:`packages ` that are isolated to the " -"current user, use the ``--user`` flag:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:425 -msgid "" -"For more information see the `User Installs `_ section from the pip docs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:429 -msgid "" -"Note that the ``--user`` flag has no effect when inside a virtual " -"environment - all installation commands will affect the virtual environment." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:432 -msgid "" -"If ``SomeProject`` defines any command-line scripts or console entry points, " -"``--user`` will cause them to be installed inside the `user base`_'s binary " -"directory, which may or may not already be present in your shell's :envvar:" -"`PATH`. (Starting in version 10, pip displays a warning when installing any " -"scripts to a directory outside :envvar:`PATH`.) If the scripts are not " -"available in your shell after installation, you'll need to add the directory " -"to your :envvar:`PATH`:" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:440 -msgid "" -"On Linux and macOS you can find the user base binary directory by running " -"``python -m site --user-base`` and adding ``bin`` to the end. For example, " -"this will typically print ``~/.local`` (with ``~`` expanded to the absolute " -"path to your home directory) so you'll need to add ``~/.local/bin`` to your " -"``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:446 -msgid "" -"On Windows you can find the user base binary directory by running ``py -m " -"site --user-site`` and replacing ``site-packages`` with ``Scripts``. For " -"example, this could return ``C:\\Users\\Username\\AppData\\Roaming" -"\\Python36\\site-packages`` so you would need to set your ``PATH`` to " -"include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You " -"can set your user ``PATH`` permanently in the `Control Panel`_. You may need " -"to log out for the ``PATH`` changes to take effect." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:462 -msgid "" -"Install a list of requirements specified in a :ref:`Requirements File `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:478 -msgid "Installing from VCS" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:480 -msgid "" -"Install a project from VCS in \"editable\" mode. For a full breakdown of " -"the syntax, see pip's section on :ref:`VCS Support `." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:502 -msgid "Installing from other Indexes" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:504 -msgid "Install from an alternate index" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:518 -msgid "" -"Search an additional index during install, in addition to :term:`PyPI " -"`" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:534 -msgid "Installing from a local src tree" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:537 -msgid "" -"Installing from local src in `Development Mode `_, i.e. in such a " -"way that the project appears to be installed, but yet is still editable from " -"the src tree." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:554 -msgid "You can also install normally from src" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:571 -msgid "Install a particular source archive file." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:585 -msgid "" -"Install from a local directory containing archives (and don't check :term:" -"`PyPI `)" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:605 -msgid "Installing from other sources" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:607 -msgid "" -"To install from other data sources (for example Amazon S3 storage) you can " -"create a helper application that presents the data in a :pep:`503` compliant " -"index format, and use the ``--extra-index-url`` flag to direct pip to use " -"that index." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:619 -msgid "Installing Prereleases" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:621 -msgid "" -"Find pre-release and development versions, in addition to stable versions. " -"By default, pip only finds stable versions." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:637 -msgid "Installing Setuptools \"Extras\"" -msgstr "" - -#: ../source/tutorials/installing-packages.rst:639 -msgid "Install `setuptools extras`_." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:659 -msgid "" -"\"Secure\" in this context means using a modern browser or a tool like :" -"command:`curl` that verifies SSL certificates when downloading from https " -"URLs." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:668 -msgid "" -"Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:" -"`virtualenv`) will create virtualenv environments with ``pip`` pre-" -"installed, thereby making it an equal alternative to :ref:`virtualenv`." -msgstr "" - -#: ../source/tutorials/installing-packages.rst:673 -msgid "" -"The compatible release specifier was accepted in :pep:`440` and support was " -"released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:4 -msgid "Managing Application Dependencies" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:6 -msgid "" -"The :ref:`package installation tutorial ` covered the " -"basics of getting set up to install and update Python packages." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:9 -msgid "" -"However, running these commands interactively can get tedious even for your " -"own personal projects, and things get even more difficult when trying to set " -"up development environments automatically for projects with multiple " -"contributors." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:13 -msgid "" -"This tutorial walks you through the use of :ref:`Pipenv` to manage " -"dependencies for an application. It will show you how to install and use the " -"necessary tools and make strong recommendations on best practices." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:17 -msgid "" -"Keep in mind that Python is used for a great many different purposes, and " -"precisely how you want to manage your dependencies may change based on how " -"you decide to publish your software. The guidance presented here is most " -"directly applicable to the development and deployment of network services " -"(including web applications), but is also very well suited to managing " -"development and testing environments for any kind of project." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:24 -msgid "" -"Developers of Python libraries, or of applications that support distribution " -"as Python libraries, should also consider the `poetry `_ project as an alternative dependency management " -"solution." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:30 -msgid "Installing Pipenv" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:32 -msgid "" -":ref:`Pipenv` is a dependency manager for Python projects. If you're " -"familiar with Node.js' `npm`_ or Ruby's `bundler`_, it is similar in spirit " -"to those tools. While :ref:`pip` alone is often sufficient for personal use, " -"Pipenv is recommended for collaborative projects as it's a higher-level tool " -"that simplifies dependency management for common use cases." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:38 -msgid "Use ``pip`` to install Pipenv:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:54 -msgid "" -"This does a `user installation`_ to prevent breaking any system-wide " -"packages. If ``pipenv`` isn't available in your shell after installation, " -"you'll need to add the `user base`_'s binary directory to your ``PATH``. " -"See :ref:`Installing to the User Site` for more information." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:65 -msgid "Installing packages for your project" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:67 -msgid "" -"Pipenv manages dependencies on a per-project basis. To install packages, " -"change into your project's directory (or just an empty directory for this " -"tutorial) and run:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:76 -msgid "" -"Pipenv will install the `Requests`_ library and create a ``Pipfile`` for you " -"in your project's directory. The :ref:`Pipfile` is used to track which " -"dependencies your project needs in case you need to re-install them, such as " -"when you share your project with others. You should get output similar to " -"this (although the exact paths shown will vary):" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:112 -msgid "Using installed packages" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:114 -msgid "" -"Now that Requests is installed you can create a simple :file:`main.py` file " -"to use it:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:125 -msgid "Then you can run this script using ``pipenv run``:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:131 -msgid "You should get output similar to this:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:137 -msgid "" -"Using ``pipenv run`` ensures that your installed packages are available to " -"your script. It's also possible to spawn a new shell that ensures all " -"commands have access to your installed packages with ``pipenv shell``." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:143 -#: ../source/tutorials/packaging-projects.rst:594 -msgid "Next steps" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:145 -msgid "" -"Congratulations, you now know how to effectively manage dependencies and " -"development environments on a collaborative Python project! ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:148 -msgid "" -"If you're interested in creating and distributing your own Python packages, " -"see the :ref:`tutorial on packaging and distributing packages `." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:151 -msgid "" -"Note that when your application includes definitions of Python source " -"packages, they (and their dependencies) can be added to your ``pipenv`` " -"environment with ``pipenv install -e `` " -"(e.g. ``pipenv install -e .`` or ``pipenv install -e src``)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:160 -msgid "Other Tools for Application Dependency Management" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:162 -msgid "" -"If you find this particular approach to managing application dependencies " -"isn't working well for you or your use case, you may want to explore these " -"other tools and techniques to see if one of them is a better fit:" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:166 -msgid "" -"`poetry `__ for a tool comparable " -"in scope to ``pipenv`` that focuses more directly on use cases where the " -"repository being managed is structured as a Python project with a valid " -"``pyproject.toml`` file (by contrast, ``pipenv`` explicitly avoids making " -"the assumption that the application being worked on that's depending on " -"components from PyPI will itself support distribution as a ``pip``-" -"installable Python package)." -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:172 -msgid "" -"`hatch `_ for opinionated coverage of even " -"more steps in the project management workflow (such as incrementing " -"versions, tagging releases, and creating new skeleton projects from project " -"templates)" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:175 -msgid "" -"`pip-tools `_ to build your own " -"custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``" -msgstr "" - -#: ../source/tutorials/managing-dependencies.rst:177 -msgid "" -"`micropipenv `_ is a " -"lightweight wrapper for pip to support requirements.txt, Pipenv and Poetry " -"lock files or converting them to pip-tools compatible output. Designed for " -"containerized Python applications but not limited to them." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:2 -msgid "Packaging Python Projects" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:4 -msgid "" -"This tutorial walks you through how to package a simple Python project. It " -"will show you how to add the necessary files and structure to create the " -"package, how to build the package, and how to upload it to the Python " -"Package Index." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:10 -msgid "" -"If you have trouble running the commands in this tutoral, please copy the " -"command and its output, then `open an issue`_ on the `packaging-problems`_ " -"repository on GitHub. We'll do our best to help you!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:18 -msgid "" -"Some of the commands require a newer version of :ref:`pip`, so start by " -"making sure you have the latest version installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:35 -msgid "A simple project" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:37 -msgid "" -"This tutorial uses a simple project named ``example_package``. We recommend " -"following this tutorial as-is using this project, before packaging your own " -"project." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:41 -msgid "Create the following file structure locally:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:51 -msgid "" -":file:`__init__.py` is required to import the directory as a package, and " -"should be empty." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:54 -msgid "" -":file:`example.py` is an example of a module within the package that could " -"contain the logic (functions, classes, constants, etc.) of your package. " -"Open that file and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:63 -msgid "" -"If you are unfamiliar with Python's :term:`modules ` and :term:" -"`import packages `, take a few minutes to read over the " -"`Python documentation for packages and modules`_." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:67 -msgid "" -"Once you create this structure, you'll want to run all of the commands in " -"this tutorial within the ``packaging_tutorial`` directory." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:75 -msgid "Creating the package files" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:77 -msgid "" -"You will now add files that are used to prepare the project for " -"distribution. When you're done, the project structure will look like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:95 -msgid "Creating a test directory" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:97 -msgid ":file:`tests/` is a placeholder for test files. Leave it empty for now." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:101 -msgid "Creating pyproject.toml" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:103 -msgid "" -":file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) " -"what is required to build your project. This tutorial uses :ref:" -"`setuptools`, so open :file:`pyproject.toml` and enter the following content:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:117 -msgid "" -"``build-system.requires`` gives a list of packages that are needed to build " -"your package. Listing something here will *only* make it available during " -"the build, not after it is installed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:121 -msgid "" -"``build-system.build-backend`` is the name of Python object that will be " -"used to perform the build. If you were to use a different build system, such " -"as :ref:`flit` or :ref:`poetry`, those would go here, and the configuration " -"details would be completely different than the :ref:`setuptools` " -"configuration described below." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:127 -msgid "See :pep:`517` and :pep:`518` for background and details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:131 -msgid "Configuring metadata" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:133 -msgid "There are two types of metadata: static and dynamic." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:135 -msgid "" -"Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. " -"This is simpler, easier to read, and avoids many common errors, like " -"encoding errors." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:137 -msgid "" -"Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items " -"that are dynamic or determined at install-time, as well as extension modules " -"or extensions to setuptools, need to go into :file:`setup.py`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:141 -msgid "" -"Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:" -"file:`setup.py`) should be used only as an escape hatch when absolutely " -"necessary. :file:`setup.py` used to be required, but can be omitted with " -"newer versions of setuptools and pip." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:148 -msgid "" -":file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells " -"setuptools about your package (such as the name and version) as well as " -"which code files to include. Eventually much of this configuration may be " -"able to move to :file:`pyproject.toml`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:153 -msgid "" -"Open :file:`setup.cfg` and enter the following content. Change the ``name`` " -"to include your username; this ensures that you have a unique package name " -"and that your package doesn't conflict with packages uploaded by other " -"people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:185 -msgid "" -"There are a `variety of metadata and options `_ supported here. This is " -"in :doc:`configparser ` format; do not place " -"quotes around values. This example package uses a relatively minimal set of " -"``metadata``:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:191 -#: ../source/tutorials/packaging-projects.rst:286 -msgid "" -"``name`` is the *distribution name* of your package. This can be any name as " -"long as it only contains letters, numbers, ``_`` , and ``-``. It also must " -"not already be taken on pypi.org. **Be sure to update this with your " -"username,** as this ensures you won't try to upload a package with the same " -"name as one which already exists." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:196 -msgid "" -"``version`` is the package version. See :pep:`440` for more details on " -"versions. You can use ``file:`` or ``attr:`` directives to read from a file " -"or package attribute." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:199 -#: ../source/tutorials/packaging-projects.rst:293 -msgid "" -"``author`` and ``author_email`` are used to identify the author of the " -"package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:201 -#: ../source/tutorials/packaging-projects.rst:295 -msgid "``description`` is a short, one-sentence summary of the package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:202 -msgid "" -"``long_description`` is a detailed description of the package. This is shown " -"on the package detail page on the Python Package Index. In this case, the " -"long description is loaded from :file:`README.md` (which is a common " -"pattern) using the ``file:`` directive." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:206 -#: ../source/tutorials/packaging-projects.rst:300 -msgid "" -"``long_description_content_type`` tells the index what type of markup is " -"used for the long description. In this case, it's Markdown." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:208 -#: ../source/tutorials/packaging-projects.rst:302 -msgid "" -"``url`` is the URL for the homepage of the project. For many projects, this " -"will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting " -"service." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:211 -#: ../source/tutorials/packaging-projects.rst:305 -msgid "" -"``project_urls`` lets you list any number of extra links to show on PyPI. " -"Generally this could be to documentation, issue trackers, etc." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:213 -#: ../source/tutorials/packaging-projects.rst:307 -msgid "" -"``classifiers`` gives the index and :ref:`pip` some additional metadata " -"about your package. In this case, the package is only compatible with Python " -"3, is licensed under the MIT license, and is OS-independent. You should " -"always include at least which version(s) of Python your package works on, " -"which license your package is available under, and which operating systems " -"your package will work on. For a complete list of classifiers, see https://" -"pypi.org/classifiers/." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:221 -msgid "In the ``options`` category, we have controls for setuptools itself:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:223 -msgid "" -"``package_dir`` is a mapping of package names and directories. An empty " -"package name represents the \"root package\" --- the directory in the " -"project that contains all Python source files for the package --- so in this " -"case the ``src`` directory is designated the root package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:227 -msgid "" -"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " -"`. Instead of listing each package manually, we can " -"use the ``find:`` directive to automatically discover all packages and " -"subpackages and ``options.packages.find`` to specify the ``package_dir`` to " -"use. In this case, the list of packages will be ``example_package`` as " -"that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:234 -msgid "" -"``python_requires`` gives the versions of Python supported by your project. " -"Installers like :ref:`pip` will look back through older versions of packages " -"until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:238 -#: ../source/tutorials/packaging-projects.rst:329 -msgid "" -"There are many more than the ones mentioned here. See :doc:`/guides/" -"distributing-packages-using-setuptools` for more details." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:244 -msgid "" -":file:`setup.py` is the build script for :ref:`setuptools`. It tells " -"setuptools about your package (such as the name and version) as well as " -"which code files to include." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:248 -msgid "" -"Open :file:`setup.py` and enter the following content. Change the ``name`` " -"to include your username; this ensures that you have a unique package name " -"and that your package doesn't conflict with packages uploaded by other " -"people following this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:283 -msgid "" -":func:`setup` takes several arguments. This example package uses a " -"relatively minimal set:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:291 -msgid "" -"``version`` is the package version. See :pep:`440` for more details on " -"versions." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:296 -msgid "" -"``long_description`` is a detailed description of the package. This is shown " -"on the package detail page on the Python Package Index. In this case, the " -"long description is loaded from :file:`README.md`, which is a common pattern." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:314 -msgid "" -"``package_dir`` is a dictionary with package names for keys and directories " -"for values. An empty package name represents the \"root package\" --- the " -"directory in the project that contains all Python source files for the " -"package --- so in this case the ``src`` directory is designated the root " -"package." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:319 -msgid "" -"``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package " -"`. Instead of listing each package manually, we can " -"use :func:`find_packages` to automatically discover all packages and " -"subpackages under ``package_dir``. In this case, the list of packages will " -"be ``example_package`` as that's the only package present." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:325 -msgid "" -"``python_requires`` gives the versions of Python supported by your project. " -"Installers like :ref:`pip` will look back though older versions of packages " -"until it finds one that has a matching Python version." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:333 -msgid "Creating README.md" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:335 -msgid "" -"Open :file:`README.md` and enter the following content. You can customize " -"this if you'd like." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:347 -msgid "" -"Because our configuration loads :file:`README.md` to provide a " -"``long_description``, :file:`README.md` must be included along with your " -"code when you :ref:`generate a source distribution `. " -"Newer versions of :ref:`setuptools` will do this automatically." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:354 -msgid "Creating a LICENSE" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:356 -msgid "" -"It's important for every package uploaded to the Python Package Index to " -"include a license. This tells users who install your package the terms under " -"which they can use your package. For help picking a license, see https://" -"choosealicense.com/. Once you have chosen a license, open :file:`LICENSE` " -"and enter the license text. For example, if you had chosen the MIT license:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:387 -msgid "Including other files" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:389 -msgid "" -"The files listed above will be included automatically in your :term:`source " -"distribution `. If you want to control " -"what goes in this explicitly, see :ref:`Using MANIFEST.in`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:393 -msgid "" -"The final :term:`built distribution ` will have the " -"Python files in the discovered or listed Python packages. If you want to " -"control what goes here, such as to add data files, see :doc:`Including Data " -"Files ` from the :doc:`setuptools docs " -"`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:402 -msgid "Generating distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:404 -msgid "" -"The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the " -"Python Package Index and can be installed by :ref:`pip`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:408 -msgid "Make sure you have the latest version of PyPA's :ref:`build` installed:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:422 -msgid "" -"If you have trouble installing these, see the :doc:`installing-packages` " -"tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:425 -msgid "" -"Now run this command from the same directory where :file:`pyproject.toml` is " -"located:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:439 -msgid "" -"This command should output a lot of text and once completed should generate " -"two files in the :file:`dist` directory:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:449 -msgid "" -"The ``tar.gz`` file is a :term:`source archive ` whereas the " -"``.whl`` file is a :term:`built distribution `. Newer :" -"ref:`pip` versions preferentially install built distributions, but will fall " -"back to source archives if needed. You should always upload a source archive " -"and provide built archives for the platforms your project is compatible " -"with. In this case, our example package is compatible with Python on any " -"platform so only one built distribution is needed." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:458 -msgid "Uploading the distribution archives" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:460 -msgid "Finally, it's time to upload your package to the Python Package Index!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:462 -msgid "" -"The first thing you'll need to do is register an account on TestPyPI, which " -"is a separate instance of the package index intended for testing and " -"experimentation. It's great for things like this tutorial where we don't " -"necessarily want to upload to the real index. To register an account, go to " -"https://test.pypi.org/account/register/ and complete the steps on that page. " -"You will also need to verify your email address before you're able to upload " -"any packages. For more details, see :doc:`/guides/using-testpypi`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:470 -msgid "" -"To securely upload your project, you'll need a PyPI `API token`_. Create one " -"at https://test.pypi.org/manage/account/#api-tokens, setting the \"Scope\" " -"to \"Entire account\". **Don't close the page until you have copied and " -"saved the token — you won't see that token again.**" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:477 -msgid "" -"Now that you are registered, you can use :ref:`twine` to upload the " -"distribution packages. You'll need to install Twine:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:492 -msgid "" -"Once installed, run Twine to upload all of the archives under :file:`dist`:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:506 -msgid "" -"You will be prompted for a username and password. For the username, use " -"``__token__``. For the password, use the token value, including the ``pypi-" -"`` prefix." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:510 -msgid "After the command completes, you should see output similar to this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:523 -msgid "" -"Once uploaded your package should be viewable on TestPyPI, for example, " -"https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:528 -msgid "Installing your newly uploaded package" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:530 -msgid "" -"You can use :ref:`pip` to install your package and verify that it works. " -"Create a :ref:`virtual environment ` and install your package from TestPyPI:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:546 -msgid "Make sure to specify your username in the package name!" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:548 -msgid "" -"pip should install the package from TestPyPI and the output should look " -"something like this:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:558 -msgid "" -"This example uses ``--index-url`` flag to specify TestPyPI instead of live " -"PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't have " -"the same packages as the live PyPI, it's possible that attempting to install " -"dependencies may fail or install something unexpected. While our example " -"package doesn't have any dependencies, it's a good practice to avoid " -"installing dependencies when using TestPyPI." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:565 -msgid "" -"You can test that it was installed correctly by importing the package. Make " -"sure you're still in your virtual environment, then run Python:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:580 -msgid "and import the package:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:588 -msgid "" -"Note that the :term:`import package ` is ``example_package`` " -"regardless of what ``name`` you gave your :term:`distribution package " -"` in :file:`setup.cfg` or :file:`setup.py` (in this " -"case, ``example-pkg-YOUR-USERNAME-HERE``)." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:596 -msgid "" -"**Congratulations, you've packaged and distributed a Python project!** ✨ 🍰 ✨" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:599 -msgid "" -"Keep in mind that this tutorial showed you how to upload your package to " -"Test PyPI, which isn't a permanent storage. The Test system occasionally " -"deletes packages and accounts. It is best to use TestPyPI for testing and " -"experiments like this tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:604 -msgid "" -"When you are ready to upload a real package to the Python Package Index you " -"can do much the same as you did in this tutorial, but with these important " -"differences:" -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:608 -msgid "" -"Choose a memorable and unique name for your package. You don't have to " -"append your username as you did in the tutorial." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:610 -msgid "" -"Register an account on https://pypi.org - note that these are two separate " -"servers and the login details from the test server are not shared with the " -"main server." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:613 -msgid "" -"Use ``twine upload dist/*`` to upload your package and enter your " -"credentials for the account you registered on the real PyPI. Now that " -"you're uploading the package in production, you don't need to specify ``--" -"repository``; the package will upload to https://pypi.org/ by default." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:617 -msgid "" -"Install your package from the real PyPI using ``python3 -m pip install [your-" -"package]``." -msgstr "" -"使用 ``python3 -m pip install [your-package]`` 以從真正的PyPI安裝您的套件。" - -#: ../source/tutorials/packaging-projects.rst:619 -msgid "" -"At this point if you want to read more on packaging Python libraries here " -"are some things you can do:" -msgstr "此時，如果您想閱讀有關打包 Python 庫的更多信息，您可以執行以下操作：" - -#: ../source/tutorials/packaging-projects.rst:622 -msgid "" -"Read more about using :ref:`setuptools` to package libraries in :doc:`/" -"guides/distributing-packages-using-setuptools`." -msgstr "" - -#: ../source/tutorials/packaging-projects.rst:624 -msgid "Read about :doc:`/guides/packaging-binary-extensions`." -msgstr "閱讀 :doc:`/guides/packaging-binary-extensions`。" - -#: ../source/tutorials/packaging-projects.rst:625 -msgid "" -"Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:" -"`hatch`, and :ref:`poetry`." -msgstr "" From c31f90038239f6a7c8e4e6c7b35b3710babdcc6c Mon Sep 17 00:00:00 2001 From: Nick Coghlan Date: Sun, 10 Nov 2019 14:29:22 +1000 Subject: [PATCH 0215/1072] Closes #667: advise against using distutils directly --- source/tutorials/packaging-projects.rst | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index acc854032..22611c379 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -329,6 +329,15 @@ be required, but can be omitted with newer versions of setuptools and pip. There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details. +.. note:: + + You may see some existing projects or other Python packaging tutorials that + import their ``setup`` function from ``distutils.core`` rather than + ``setuptools``. This is a legacy approach that installers [1]_ still support + for backwards compatibility purposes, but using the legacy ``distutils`` API + directly in new projects is strongly discouraged, as it means that newer + build commands, like ``setup.py bdist_wheel``, won't work. + Creating README.md ------------------ @@ -624,3 +633,14 @@ some things you can do: * Read about :doc:`/guides/packaging-binary-extensions`. * Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, and :ref:`poetry`. + +---- + +.. [1] Some legacy Python environments may not have ``setuptools`` + pre-installed, and the operators of those environments may still be + requiring users to install packages by running ``setup.py install`` + commands, rather than providing an installer like ``pip`` that + automatically installes required build dependendencies. These + environments will not be able to use many published packages until the + environment is updated to provide an up to date Python package + installation client (e.g. by running ``python -m ensurepip``). From c888ab2c7bb911a23695675f3f8870e983b60112 Mon Sep 17 00:00:00 2001 From: Nick Coghlan Date: Sun, 10 Nov 2019 14:38:47 +1000 Subject: [PATCH 0216/1072] Link to stdlib distutils deprecation page --- source/guides/distributing-packages-using-setuptools.rst | 8 +++++--- source/tutorials/packaging-projects.rst | 4 +++- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index c7b5d9d7d..572244099 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -4,9 +4,11 @@ Packaging and distributing projects =================================== -This section covers the basics of how to configure, package and distribute your -own Python projects. It assumes that you are already familiar with the contents -of the :doc:`/tutorials/installing-packages` page. +This section covers some additional details on configuring, packaging and +distributing Python projects with ``setuptools`` that aren't covered by the +introductory tutorial in :doc:`/tutorials/packaging-projects`. It still assumes +that you are already familiar with the contents of the +:doc:`/tutorials/installing-packages` page. The section does *not* aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index 22611c379..10bc95d83 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -333,11 +333,13 @@ be required, but can be omitted with newer versions of setuptools and pip. You may see some existing projects or other Python packaging tutorials that import their ``setup`` function from ``distutils.core`` rather than - ``setuptools``. This is a legacy approach that installers [1]_ still support + ``setuptools``. This is a `legacy approach`_ that installers [1]_ support for backwards compatibility purposes, but using the legacy ``distutils`` API directly in new projects is strongly discouraged, as it means that newer build commands, like ``setup.py bdist_wheel``, won't work. +.. _legacy approach: https://docs.python.org/3/library/distutils.html + Creating README.md ------------------ From ab037f32a4a09afbb94ab15bb57d824070d2705f Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Thu, 2 Sep 2021 20:06:04 +0200 Subject: [PATCH 0217/1072] Fix a typo s/installes/installs/ Co-authored-by: Dustin Ingram --- source/tutorials/packaging-projects.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index 10bc95d83..073ffe87a 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -642,7 +642,7 @@ some things you can do: pre-installed, and the operators of those environments may still be requiring users to install packages by running ``setup.py install`` commands, rather than providing an installer like ``pip`` that - automatically installes required build dependendencies. These + automatically installs required build dependendencies. These environments will not be able to use many published packages until the environment is updated to provide an up to date Python package installation client (e.g. by running ``python -m ensurepip``). From 92c6de7a76e2727526129d66529258aff4aa7041 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Juan=20Luis=20Cano=20Rodr=C3=ADguez?= Date: Tue, 7 Dec 2021 19:32:36 +0100 Subject: [PATCH 0218/1072] Update text with distutils deprecation --- source/tutorials/packaging-projects.rst | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index 073ffe87a..feb06094d 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -329,16 +329,17 @@ be required, but can be omitted with newer versions of setuptools and pip. There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details. -.. note:: +.. warning:: You may see some existing projects or other Python packaging tutorials that import their ``setup`` function from ``distutils.core`` rather than ``setuptools``. This is a `legacy approach`_ that installers [1]_ support for backwards compatibility purposes, but using the legacy ``distutils`` API - directly in new projects is strongly discouraged, as it means that newer - build commands, like ``setup.py bdist_wheel``, won't work. + directly in new projects is strongly discouraged, since ``distutils`` is + deprecated as per :pep:`632` and will be removed from the standard library + in Python 3.12. -.. _legacy approach: https://docs.python.org/3/library/distutils.html +.. _legacy approach: https://docs.python.org/3.10/library/distutils.html Creating README.md ------------------ From 7e62d4cfd1526d53371baa4f34c0560a0f1f6796 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Juan=20Luis=20Cano=20Rodr=C3=ADguez?= Date: Thu, 9 Dec 2021 03:07:43 +0100 Subject: [PATCH 0219/1072] Style Co-authored-by: Brian Rutledge --- source/tutorials/packaging-projects.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index feb06094d..a66df5601 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -333,8 +333,8 @@ be required, but can be omitted with newer versions of setuptools and pip. You may see some existing projects or other Python packaging tutorials that import their ``setup`` function from ``distutils.core`` rather than - ``setuptools``. This is a `legacy approach`_ that installers [1]_ support - for backwards compatibility purposes, but using the legacy ``distutils`` API + ``setuptools``. This is a `legacy approach`_ that installers support + for backwards compatibility purposes [1]_, but using the legacy ``distutils`` API directly in new projects is strongly discouraged, since ``distutils`` is deprecated as per :pep:`632` and will be removed from the standard library in Python 3.12. From 295f112a1bab80883e699e6740c4f9305fcf7570 Mon Sep 17 00:00:00 2001 From: Henry Schreiner Date: Sat, 11 Dec 2021 21:10:14 -0500 Subject: [PATCH 0220/1072] Move Flit into PyPA (#1029) --- source/key_projects.rst | 43 ++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 22 deletions(-) diff --git a/source/key_projects.rst b/source/key_projects.rst index 39b1ab7ce..39ebfab03 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -84,6 +84,27 @@ behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards. +.. _flit: + +flit +==== + +`Docs `__ | +`Issues `__ | +`PyPI `__ + +Flit provides a simple way to create and upload pure Python packages and +modules to PyPI. It focuses on `making the easy things easy `_ +for packaging. Flit can generate a configuration file to quickly set up a +simple project, build source distributions and wheels, and upload them to PyPI. + +Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools +such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them +to PyPI. Flit requires Python 3, but you can use it to distribute modules for +Python 2, so long as they can be imported on Python 3. + +.. _flit-rationale: https://flit.readthedocs.io/en/latest/rationale.html + .. _packaging: packaging @@ -379,28 +400,6 @@ with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface. - -.. _flit: - -flit -==== - -`Docs `__ | -`Issues `__ | -`PyPI `__ - -Flit provides a simple way to upload pure Python packages and modules to PyPI. -It focuses on `making the easy things easy `_ for packaging. -Flit can generate a configuration file to quickly set up a simple project, build -source distributions and wheels, and upload them to PyPI. - -Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools -such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them -to PyPI. Flit requires Python 3, but you can use it to distribute modules for -Python 2, so long as they can be imported on Python 3. - -.. _flit-rationale: https://flit.readthedocs.io/en/latest/rationale.html - .. _enscons: enscons From 6d4efbc12ea8220a2b78136a0ab13ca2857bf38a Mon Sep 17 00:00:00 2001 From: Thomas Kluyver Date: Sun, 12 Dec 2021 17:27:29 +0000 Subject: [PATCH 0221/1072] Say that distribution names should be lowercase in wheel filenames --- source/specifications/binary-distribution-format.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst index 1bcd55010..d45b76485 100644 --- a/source/specifications/binary-distribution-format.rst +++ b/source/specifications/binary-distribution-format.rst @@ -159,8 +159,9 @@ As the components of the filename are separated by a dash (``-``, HYPHEN-MINUS), this character cannot appear within any component. This is handled as follows: - In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE - and FULL STOP) should be replaced with ``_`` (LOW LINE). This is equivalent - to :pep:`503` normalisation followed by replacing ``-`` with ``_``. + and FULL STOP) should be replaced with ``_`` (LOW LINE), and uppercase + characters should be replaced with corresponding lowercase ones. This is + equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``. - Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``. - The remaining components may not contain ``-`` characters, so no escaping From 263a8c2bbd825661ac2c2a3b0f0dbdfeb919674a Mon Sep 17 00:00:00 2001 From: Thomas Kluyver Date: Wed, 15 Dec 2021 10:59:38 +0000 Subject: [PATCH 0222/1072] Mention that tools cannot assume normalised names in existing wheels --- source/specifications/binary-distribution-format.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst index d45b76485..6036cf40d 100644 --- a/source/specifications/binary-distribution-format.rst +++ b/source/specifications/binary-distribution-format.rst @@ -162,6 +162,9 @@ this character cannot appear within any component. This is handled as follows: and FULL STOP) should be replaced with ``_`` (LOW LINE), and uppercase characters should be replaced with corresponding lowercase ones. This is equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``. + Tools consuming wheels must be prepared to accept ``.`` (FULL STOP) and + uppercase letters, however, as these were allowed by an earlier version of + this specification. - Version numbers should be normalised according to :pep:`440`. Normalised version numbers cannot contain ``-``. - The remaining components may not contain ``-`` characters, so no escaping From a7eae09302a942670413f061dc2b0e4fd5a15712 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Juan=20Luis=20Cano=20Rodr=C3=ADguez?= Date: Thu, 16 Dec 2021 15:40:07 +0100 Subject: [PATCH 0223/1072] Move warning to appropriate inline tab --- source/tutorials/packaging-projects.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index a66df5601..8fbffe033 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -329,17 +329,17 @@ be required, but can be omitted with newer versions of setuptools and pip. There are many more than the ones mentioned here. See :doc:`/guides/distributing-packages-using-setuptools` for more details. -.. warning:: + .. warning:: - You may see some existing projects or other Python packaging tutorials that - import their ``setup`` function from ``distutils.core`` rather than - ``setuptools``. This is a `legacy approach`_ that installers support - for backwards compatibility purposes [1]_, but using the legacy ``distutils`` API - directly in new projects is strongly discouraged, since ``distutils`` is - deprecated as per :pep:`632` and will be removed from the standard library - in Python 3.12. + You may see some existing projects or other Python packaging tutorials that + import their ``setup`` function from ``distutils.core`` rather than + ``setuptools``. This is a `legacy approach`_ that installers support + for backwards compatibility purposes [1]_, but using the legacy ``distutils`` API + directly in new projects is strongly discouraged, since ``distutils`` is + deprecated as per :pep:`632` and will be removed from the standard library + in Python 3.12. -.. _legacy approach: https://docs.python.org/3.10/library/distutils.html + .. _legacy approach: https://docs.python.org/3.10/library/distutils.html Creating README.md ------------------ From c05dfa4a205e881aa57c72b79826940e5a6c6693 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Juan=20Luis=20Cano=20Rodr=C3=ADguez?= Date: Thu, 16 Dec 2021 15:41:18 +0100 Subject: [PATCH 0224/1072] Remove excessively distracting link --- source/tutorials/packaging-projects.rst | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index 8fbffe033..22ca08e6e 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -333,14 +333,12 @@ be required, but can be omitted with newer versions of setuptools and pip. You may see some existing projects or other Python packaging tutorials that import their ``setup`` function from ``distutils.core`` rather than - ``setuptools``. This is a `legacy approach`_ that installers support + ``setuptools``. This is a legacy approach that installers support for backwards compatibility purposes [1]_, but using the legacy ``distutils`` API directly in new projects is strongly discouraged, since ``distutils`` is deprecated as per :pep:`632` and will be removed from the standard library in Python 3.12. - .. _legacy approach: https://docs.python.org/3.10/library/distutils.html - Creating README.md ------------------ From 3b2196426e16ec37ef3f90369c7bfb1d7a06ee91 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Juan=20Luis=20Cano=20Rodr=C3=ADguez?= Date: Thu, 16 Dec 2021 15:58:01 +0100 Subject: [PATCH 0225/1072] Upgrade expected Python version --- source/contribute.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/contribute.rst b/source/contribute.rst index 155945d23..c5edb0792 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -131,9 +131,9 @@ need: python -m pip install --user nox -2. Python 3.6. Our build scripts are designed to work with Python 3.6 only. +2. Python 3.8. Our build scripts are usually tested with Python 3.8 only. See the :doc:`Hitchhiker's Guide to Python installation instructions ` - to install Python 3.6 on your operating system. + to install Python 3.8 on your operating system. To build the guide, run the following bash command in the source folder: From 575687b3539dbdc06713919064cb24abf683e7f7 Mon Sep 17 00:00:00 2001 From: daxamin Date: Sat, 15 Jan 2022 11:39:41 -0500 Subject: [PATCH 0226/1072] update filename in packaging-project --- .gitignore | 1 + source/tutorials/packaging-projects.rst | 28 ++++++++++++------------- 2 files changed, 15 insertions(+), 14 deletions(-) diff --git a/.gitignore b/.gitignore index 301e238bb..27b53a54e 100644 --- a/.gitignore +++ b/.gitignore @@ -5,3 +5,4 @@ build/ __pycache__ .DS_Store /locales/ +.vscode diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index 22ca08e6e..5e7fef717 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -158,7 +158,7 @@ be required, but can be omitted with newer versions of setuptools and pip. .. code-block:: python [metadata] - name = example-pkg-YOUR-USERNAME-HERE + name = example-package-YOUR-USERNAME-HERE version = 0.0.1 author = Example Author author_email = author@example.com @@ -258,7 +258,7 @@ be required, but can be omitted with newer versions of setuptools and pip. long_description = fh.read() setuptools.setup( - name="example-pkg-YOUR-USERNAME-HERE", + name="example-package-YOUR-USERNAME-HERE", version="0.0.1", author="Example Author", author_email="author@example.com", @@ -452,8 +452,8 @@ files in the :file:`dist` directory: .. code-block:: text dist/ - example_package_YOUR_USERNAME_HERE-0.0.1-py3-none-any.whl - example_package_YOUR_USERNAME_HERE-0.0.1.tar.gz + example-package-YOUR-USERNAME-HERE-0.0.1-py3-none-any.whl + example-package-YOUR-USERNAME-HERE-0.0.1.tar.gz The ``tar.gz`` file is a :term:`source archive ` whereas the @@ -524,14 +524,14 @@ After the command completes, you should see output similar to this: Uploading distributions to https://test.pypi.org/legacy/ Enter your username: [your username] Enter your password: - Uploading example_package_YOUR_USERNAME_HERE-0.0.1-py3-none-any.whl + Uploading example-package-YOUR-USERNAME-HERE-0.0.1-py3-none-any.whl 100%|█████████████████████| 4.65k/4.65k [00:01<00:00, 2.88kB/s] - Uploading example_package_YOUR_USERNAME_HERE-0.0.1.tar.gz + Uploading example-package-YOUR-USERNAME-HERE-0.0.1.tar.gz 100%|█████████████████████| 4.25k/4.25k [00:01<00:00, 3.05kB/s] Once uploaded your package should be viewable on TestPyPI, for example, -https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE +https://test.pypi.org/project/example-package-YOUR-USERNAME-HERE Installing your newly uploaded package @@ -545,13 +545,13 @@ and install your package from TestPyPI: .. code-block:: bash - python3 -m pip install --index-url https://test.pypi.org/simple/ --no-deps example-pkg-YOUR-USERNAME-HERE + python3 -m pip install --index-url https://test.pypi.org/simple/ --no-deps example-package-YOUR-USERNAME-HERE .. tab:: Windows .. code-block:: bat - py -m pip install --index-url https://test.pypi.org/simple/ --no-deps example-pkg-YOUR-USERNAME-HERE + py -m pip install --index-url https://test.pypi.org/simple/ --no-deps example-package-YOUR-USERNAME-HERE Make sure to specify your username in the package name! @@ -560,10 +560,10 @@ something like this: .. code-block:: text - Collecting example-pkg-YOUR-USERNAME-HERE - Downloading https://test-files.pythonhosted.org/packages/.../example-pkg-YOUR-USERNAME-HERE-0.0.1-py3-none-any.whl - Installing collected packages: example-pkg-YOUR-USERNAME-HERE - Successfully installed example-pkg-YOUR-USERNAME-HERE-0.0.1 + Collecting example-package-YOUR-USERNAME-HERE + Downloading https://test-files.pythonhosted.org/packages/.../example-package-YOUR-USERNAME-HERE-0.0.1-py3-none-any.whl + Installing collected packages: example-package-YOUR-USERNAME-HERE + Successfully installed example-package-YOUR-USERNAME-HERE-0.0.1 .. note:: This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't @@ -598,7 +598,7 @@ and import the package: Note that the :term:`import package ` is ``example_package`` regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, -``example-pkg-YOUR-USERNAME-HERE``). +``example-package-YOUR-USERNAME-HERE``). Next steps ---------- From 5ff4c1c0797d9f3992fea40139cb463cb0fe9a9f Mon Sep 17 00:00:00 2001 From: daxamin Date: Sun, 16 Jan 2022 09:56:36 -0500 Subject: [PATCH 0227/1072] address PR comments --- .gitignore | 1 - source/conf.py | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/.gitignore b/.gitignore index 27b53a54e..301e238bb 100644 --- a/.gitignore +++ b/.gitignore @@ -5,4 +5,3 @@ build/ __pycache__ .DS_Store /locales/ -.vscode diff --git a/source/conf.py b/source/conf.py index 67cdf5f12..600c451c4 100644 --- a/source/conf.py +++ b/source/conf.py @@ -390,7 +390,7 @@ linkcheck_ignore = [ "http://localhost:\d+", # This is an example that showing to the reader - "https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE", + "https://test.pypi.org/project/example-package-YOUR-USERNAME-HERE", # Ignoring it as it will redirect to login page if reader hasn't logged in. "https://pypi.org/manage/*", "https://test.pypi.org/manage/*", From b24f57881e5bf6924a02a950216f6949324c76bc Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Sun, 16 Jan 2022 14:42:19 -0500 Subject: [PATCH 0228/1072] Replace broken pyinstaller link --- source/overview.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/overview.rst b/source/overview.rst index d8878534c..5b233bbef 100644 --- a/source/overview.rst +++ b/source/overview.rst @@ -313,7 +313,7 @@ and a good amount of effort. A selection of Python freezers: -* `pyInstaller `_ - Cross-platform +* `pyInstaller `_ - Cross-platform * `cx_Freeze `_ - Cross-platform * `constructor `_ - For command-line installers * `py2exe `_ - Windows only From b63d5f6d0b5df8b6b3be8df9b2ef68406a1c0124 Mon Sep 17 00:00:00 2001 From: Joseph Fox-Rabinovitz Date: Thu, 20 Jan 2022 08:06:25 -0500 Subject: [PATCH 0229/1072] Tiny fixup to wording in MAINFEST.in guide (#1042) --- source/guides/using-manifest-in.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/using-manifest-in.rst b/source/guides/using-manifest-in.rst index e23c0cbfd..1eaf42c18 100644 --- a/source/guides/using-manifest-in.rst +++ b/source/guides/using-manifest-in.rst @@ -46,7 +46,7 @@ The following files are included in a source distribution by default: After adding the above files to the sdist, the commands in :file:`MANIFEST.in` (if such a file exists) are executed in order to add and remove further files -to & from the sdist. Default files can even be removed from the sdist with the +to and from the sdist. Default files can even be removed from the sdist with the appropriate :file:`MANIFEST.in` command. After processing the :file:`MANIFEST.in` file, setuptools removes the From a79d72d08deb3b209ddae636d222ca548a25b9c5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Timoth=C3=A9e=20Mazzucotelli?= Date: Sun, 23 Jan 2022 15:23:42 +0100 Subject: [PATCH 0230/1072] Add PDM to the list of alternatives to Pipenv (#1036) * Add PDM to the list of alternatives to Pipenv * Update source/tutorials/managing-dependencies.rst Co-authored-by: Brian Rutledge * Update source/tutorials/managing-dependencies.rst Co-authored-by: Brian Rutledge * Update source/tutorials/managing-dependencies.rst Co-authored-by: Brian Rutledge * Update source/tutorials/managing-dependencies.rst Co-authored-by: Brian Rutledge * apply suggestions Co-authored-by: Brian Rutledge Co-authored-by: Brian Rutledge --- source/tutorials/managing-dependencies.rst | 41 +++++++++++----------- 1 file changed, 21 insertions(+), 20 deletions(-) diff --git a/source/tutorials/managing-dependencies.rst b/source/tutorials/managing-dependencies.rst index ac8535410..61d2634dd 100644 --- a/source/tutorials/managing-dependencies.rst +++ b/source/tutorials/managing-dependencies.rst @@ -21,10 +21,7 @@ applicable to the development and deployment of network services (including web applications), but is also very well suited to managing development and testing environments for any kind of project. -Developers of Python libraries, or of applications that support distribution -as Python libraries, should also consider the -`poetry `_ project as an alternative dependency -management solution. +For alternatives, see `Other Tools for Application Dependency Management`_. Installing Pipenv ----------------- @@ -161,20 +158,24 @@ Other Tools for Application Dependency Management If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools -and techniques to see if one of them is a better fit: - -* `poetry `__ for a tool comparable in scope - to ``pipenv`` that focuses more directly on use cases where the repository being - managed is structured as a Python project with a valid ``pyproject.toml`` file - (by contrast, ``pipenv`` explicitly avoids making the assumption that the - application being worked on that's depending on components from PyPI will - itself support distribution as a ``pip``-installable Python package). +and techniques, listed in alphabetical order, to see if one of them is a better fit: + * `hatch `_ for opinionated coverage of even - more steps in the project management workflow (such as incrementing versions, - tagging releases, and creating new skeleton projects from project templates) -* `pip-tools `_ to build your own - custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync`` -* `micropipenv `_ is a lightweight - wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or - converting them to pip-tools compatible output. Designed for containerized - Python applications but not limited to them. + more steps in the project management workflow, such as incrementing versions, + tagging releases, and creating new skeleton projects from project templates. +* `micropipenv `_ for a lightweight + wrapper around pip that supports ``requirements.txt``, Pipenv and Poetry lock files, + or converting them to pip-tools compatible output. Designed for containerized + Python applications, but not limited to them. +* `PDM `_ for a modern Python package management + tool supporting :pep:`582` (replacing virtual environments with ``__pypackages__`` + directory for package installation) and relying on standards such as :pep:`517` and + :pep:`621`. +* `pip-tools `_ for creating a lock file of all + dependencies from a list of packages directly used in a project, and ensuring that + only those dependencies are installed. +* `Poetry `__ for a tool comparable in scope + to Pipenv that focuses more directly on use cases where the project being managed is + structured as a distributable Python package with a valid ``pyproject.toml`` file. + By contrast, Pipenv explicitly avoids making the assumption that the application + being worked on will support distribution as a ``pip``-installable Python package. From 80efe9215d8627c746670f3ec6862cd7328823bb Mon Sep 17 00:00:00 2001 From: Steven Silvester Date: Sat, 12 Feb 2022 13:00:08 -0600 Subject: [PATCH 0231/1072] Add concurrency limit to CI --- .github/workflows/test.yml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index 8c7151432..09b428e16 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -2,6 +2,10 @@ name: Test on: [push, pull_request] +concurrency: + group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.sha }} + cancel-in-progress: true + jobs: build: name: ${{ matrix.noxenv }} From 3561fe5ef550c67464330ca5b1af9763763fbbba Mon Sep 17 00:00:00 2001 From: Silvio Traversaro Date: Sun, 13 Feb 2022 18:57:51 +0100 Subject: [PATCH 0232/1072] Fix chacaters typo --- source/specifications/recording-installed-packages.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/recording-installed-packages.rst b/source/specifications/recording-installed-packages.rst index 782902687..6d5eb839c 100644 --- a/source/specifications/recording-installed-packages.rst +++ b/source/specifications/recording-installed-packages.rst @@ -43,7 +43,7 @@ This directory is named as ``{name}-{version}.dist-info``, with ``name`` and normalized (see :pep:`PEP 503 <503#normalized-names>` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with -underscore (``_``) chacaters, so the ``.dist-info`` directory always has +underscore (``_``) characters, so the ``.dist-info`` directory always has exactly one dash (``-``) character in its stem, separating the ``name`` and ``version`` fields. From 736c3b0bac89d76de819aa58cc4340f2321fcbea Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Tue, 15 Feb 2022 16:43:48 -0800 Subject: [PATCH 0233/1072] Update a stale link to Debian's pip package (#1047) --- .../installing-using-pip-and-virtual-environments.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst index eabc0796a..1ea79be5b 100644 --- a/source/guides/installing-using-pip-and-virtual-environments.rst +++ b/source/guides/installing-using-pip-and-virtual-environments.rst @@ -41,7 +41,7 @@ installed. pip 21.1.3 from $HOME/.local/lib/python3.9/site-packages (python 3.9) - .. _python-pip: https://packages.debian.org/stable/python-pip + .. _python-pip: https://packages.debian.org/stable/python/python3-pip .. tab:: Windows @@ -162,7 +162,7 @@ Python interpreter: .. code-block:: bat where python - + It should be in the ``env`` directory: .. tab:: Unix/macOS @@ -174,7 +174,7 @@ It should be in the ``env`` directory: .. tab:: Windows .. code-block:: bat - + ...\env\Scripts\python.exe From 3bb21ec25325c3b5257eae5469e3e857d041075f Mon Sep 17 00:00:00 2001 From: Paul Moore Date: Wed, 16 Feb 2022 02:01:49 +0000 Subject: [PATCH 0234/1072] Require metadata to be serialised using UTF-8 (#1046) Co-authored-by: Brian Rutledge --- source/specifications/core-metadata.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst index 5a4d9b354..86eaa1373 100644 --- a/source/specifications/core-metadata.rst +++ b/source/specifications/core-metadata.rst @@ -22,6 +22,9 @@ definition, the practical standard is set by what the standard library :mod:`python:email.parser` module can parse using the :data:`~.python:email.policy.compat32` policy. +Whenever metadata is serialised to a byte stream (for example, to save +to a file), strings must be serialised using the UTF-8 encoding. + Although :pep:`566` defined a way to transform metadata into a JSON-compatible dictionary, this is not yet used as a standard interchange format. The need for tools to work with years worth of existing packages makes it difficult to shift From 8a19e5070a54a7771038a91b00a66e0ede9418ce Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Tue, 8 Mar 2022 17:11:17 -0800 Subject: [PATCH 0235/1072] Fix spec for `Dynamic` to disallow `Metadata-Version` (#1057) * Fix spec for `Dynamic to disallow `Metadata-Version` It accidentally listed `Version` which various tools already set dynamically (e.g. Flit). * Clarify that `Version` cannot be specified in `Dynamic` for wheels * Fix broken links due to an expired SSL cert * Update core-metadata.rst --- source/specifications/binary-distribution-format.rst | 8 ++++---- source/specifications/core-metadata.rst | 3 ++- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst index 6036cf40d..c7658e4b0 100644 --- a/source/specifications/binary-distribution-format.rst +++ b/source/specifications/binary-distribution-format.rst @@ -315,10 +315,10 @@ checker only needs to establish that RECORD matches the signature. See -- https://self-issued.info/docs/draft-ietf-jose-json-web-signature.html -- https://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html -- https://self-issued.info/docs/draft-ietf-jose-json-web-key.html -- https://self-issued.info/docs/draft-jones-jose-json-private-key.html +- https://datatracker.ietf.org/doc/html/rfc7515 +- https://tools.ietf.org/id/draft-jones-json-web-signature-json-serialization-01.html +- https://datatracker.ietf.org/doc/html/rfc7517 +- https://tools.ietf.org/id/draft-jones-jose-json-private-key-01.html Comparison to .egg diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst index 86eaa1373..ef28081cc 100644 --- a/source/specifications/core-metadata.rst +++ b/source/specifications/core-metadata.rst @@ -106,7 +106,8 @@ Dynamic (multiple use) .. versionadded:: 2.2 A string containing the name of another core metadata field. The field -names ``Name`` and ``Version`` may not be specified in this field. +names ``Name``, ``Version``, and ``Metadata-Version`` may not be specified +in this field. When found in the metadata of a source distribution, the following rules apply: From 7a529c66990d334f2df7a4b2d29b1d5adb5aeaf2 Mon Sep 17 00:00:00 2001 From: Hugo van Kemenade Date: Wed, 9 Mar 2022 03:15:29 +0200 Subject: [PATCH 0236/1072] Document the 'Private ::' classifier prefix (#1056) Co-authored-by: Brian Rutledge --- source/guides/distributing-packages-using-setuptools.rst | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index 572244099..c457a1e3b 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -325,6 +325,10 @@ projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the :ref:`python_requires` argument. +To prevent a package from being uploaded to PyPI, use the special +``'Private :: Do Not Upload'`` classifier. PyPI will always reject packages with +classifiers beginning with ``"Private ::'``. + ``keywords`` ~~~~~~~~~~~~ From f3e1dd51583162ca57cb2027613f9711a9e3c54c Mon Sep 17 00:00:00 2001 From: Pradyun Gedam Date: Fri, 11 Mar 2022 10:35:26 +0000 Subject: [PATCH 0237/1072] Update the "Application dependency management" recommendations (#1055) * Update the "Application dependency management" recommendations This is a more detailed recommendation that breaks up the recommendation into multiple parts, to reflect that multiple tools need to be used in workflows today to maximise compatibility with existing platforms. It also recommends that deployed applications be isolated from the system packages, as was implied but not explicitly noted. The move away from Pipenv as the primary recommendation is a reflection of the change that application development workflows have a greater diversity in mature tooling available for them. Co-authored-by: Brian Rutledge * Normalize commas and hyphens Co-authored-by: Pradyun Gedam Co-authored-by: Brian Rutledge Co-authored-by: Brian Rutledge --- source/guides/tool-recommendations.rst | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst index 54acc1e33..21030cab7 100644 --- a/source/guides/tool-recommendations.rst +++ b/source/guides/tool-recommendations.rst @@ -11,17 +11,18 @@ what tools are currently recommended, then here it is. Application dependency management ================================= -Use :ref:`pipenv` to manage library dependencies when developing Python -applications. See :doc:`../tutorials/managing-dependencies` for more details -on using ``pipenv``. +* Use :ref:`pip` in a `secure manner`_ to install a Python application and its + dependencies during deployment. -When ``pipenv`` does not meet your use case, consider other tools like: +* Use :ref:`virtualenv` or :doc:`venv ` to isolate + application-specific dependencies from a shared Python installation. [4]_ -* :ref:`pip` +* Use `pip-tools`_, :ref:`pipenv`, or `poetry`_ to generate the fully-specified + application-specific dependencies, when developing Python applications. -* `pip-tools `_ - -* `Poetry `_ +.. _secure manner: https://pip.pypa.io/en/latest/topics/secure-installs/ +.. _pip-tools: https://github.com/jazzband/pip-tools +.. _Poetry: https://python-poetry.org/ Installation tool recommendations ================================= @@ -31,8 +32,8 @@ Installation tool recommendations is installed, you may need to also install :ref:`wheel` to get the benefit of wheel caching. [3]_ -* Use :ref:`virtualenv`, or :doc:`venv ` to isolate application - specific dependencies from a shared Python installation. [4]_ +* Use :ref:`virtualenv` or :doc:`venv ` to isolate + application-specific dependencies from a shared Python installation. [4]_ * If you're looking for management of fully integrated cross-platform software stacks, consider: From bd26de935784d6d13f4fb009d1eef91baa9243fd Mon Sep 17 00:00:00 2001 From: Henry Schreiner Date: Fri, 11 Mar 2022 13:02:22 -0500 Subject: [PATCH 0238/1072] =?UTF-8?q?No=20longer=20suggest=20`wheel`=C2=A0?= =?UTF-8?q?in=20build-requires=20for=20PEP=20517=20builds=20(#1050)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- source/tutorials/packaging-projects.rst | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index 5e7fef717..36c83135a 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -107,10 +107,7 @@ so open :file:`pyproject.toml` and enter the following content: .. code-block:: toml [build-system] - requires = [ - "setuptools>=42", - "wheel" - ] + requires = ["setuptools>=42"] build-backend = "setuptools.build_meta" From a44a309ed44de9849799f407064c687a4510e4f6 Mon Sep 17 00:00:00 2001 From: scoder Date: Fri, 11 Mar 2022 20:31:39 +0100 Subject: [PATCH 0239/1072] Avoid negative wording when describing Cython. (#1059) * Avoid negative wording when describing Cython. * Apply suggestions from code review Co-authored-by: Brian Rutledge Co-authored-by: Brian Rutledge --- source/guides/packaging-binary-extensions.rst | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/source/guides/packaging-binary-extensions.rst b/source/guides/packaging-binary-extensions.rst index 6f9088333..e9130119a 100644 --- a/source/guides/packaging-binary-extensions.rst +++ b/source/guides/packaging-binary-extensions.rst @@ -133,8 +133,8 @@ also be considered: compile most Python code to C extension modules. The initial compilation provides some speed increases (by bypassing the CPython interpreter layer), and Cython's optional static typing features can offer additional - opportunities for speed increases. Using Cython still has the disadvantage - of increasing the complexity of distributing the resulting application, + opportunities for speed increases. Using Cython still carries the + `disadvantages`_ associated with using binary extensions, but has the benefit of having a reduced barrier to entry for Python programmers (relative to other languages like C or C++). @@ -160,10 +160,15 @@ but they *can* significantly reduce the maintenance burden of keeping wrapper modules up to date. * In addition to being useful for the creation of accelerator modules, - `Cython `__ is also useful for creating wrapper - modules for C or C++. It still involves wrapping the interfaces by - hand, however, and is very repetitive, so may not be a good choice for - wrapping large APIs. + `Cython `__ is also widely used for creating wrapper + modules for C or C++ APIs. It involves wrapping the interfaces by + hand, which gives a wide range of freedom in designing and optimising + the wrapper code, but may not be a good choice for wrapping very + large APIs quickly. See the + `list of third-party tools `_ + for automatic wrapping with Cython. It also supports performance-oriented + Python implementations that provide a CPython-like C-API, such as PyPy + and Pyston. * :doc:`pybind11 ` is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It From 1ebb57b7a7bdb38e5fec5e80262aa4bb8473d020 Mon Sep 17 00:00:00 2001 From: Wouterkoorn <54982288+Wouterkoorn@users.noreply.github.com> Date: Mon, 14 Mar 2022 14:32:54 +0100 Subject: [PATCH 0240/1072] Including pep658 in the simple API description (#1061) * Included pep658 in the simple API description * bhrutledge update source/specifications/simple-repository-api.rst Co-authored-by: Brian Rutledge Co-authored-by: Brian Rutledge --- source/specifications/simple-repository-api.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/source/specifications/simple-repository-api.rst b/source/specifications/simple-repository-api.rst index 93955a247..f54713d99 100644 --- a/source/specifications/simple-repository-api.rst +++ b/source/specifications/simple-repository-api.rst @@ -8,5 +8,6 @@ Simple repository API The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of "yank" support (allowing a kind of file deletion) -as defined in :pep:`592` and specifying the interface version provided -by an index server in :pep:`629`. +in :pep:`592`, specifying the interface version provided +by an index server in :pep:`629`, and providing package metadata +independently from a package in :pep:`658`. From d00c7c9e2a4e431d917580c58e3f30a824b8c067 Mon Sep 17 00:00:00 2001 From: Pradyun Gedam Date: Sat, 19 Mar 2022 12:40:54 +0000 Subject: [PATCH 0241/1072] Change "application" to "project" in installer recommendation (#1064) Not all projects that need to be installed are applications. Libraries should also fall into this recommendation, of what installer tools should be used when working on them. --- source/guides/tool-recommendations.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst index 21030cab7..fc0afd1df 100644 --- a/source/guides/tool-recommendations.rst +++ b/source/guides/tool-recommendations.rst @@ -33,7 +33,7 @@ Installation tool recommendations of wheel caching. [3]_ * Use :ref:`virtualenv` or :doc:`venv ` to isolate - application-specific dependencies from a shared Python installation. [4]_ + project-specific dependencies from a shared Python installation. [4]_ * If you're looking for management of fully integrated cross-platform software stacks, consider: From e59950e0ea05f198e1fd26e60ddb6ccc2567eeb9 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Tue, 29 Mar 2022 02:30:43 -0700 Subject: [PATCH 0242/1072] Have sdists normalize the version in the file name (#1066) --- source/specifications/source-distribution-format.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/source/specifications/source-distribution-format.rst b/source/specifications/source-distribution-format.rst index 52bb856fc..3d6546502 100644 --- a/source/specifications/source-distribution-format.rst +++ b/source/specifications/source-distribution-format.rst @@ -36,7 +36,8 @@ Source distribution file name The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` -characters replaced with ``_``, and ``{version}`` is the project version. +characters replaced with ``_``, and ``{version}`` is the canonicalized form of +the project version (see :ref:`version-specifiers`). The name and version components of the filename MUST match the values stored in the metadata contained in the file. From cab5cfd4ddb5428bb1125d9e588dc2c2efaa62a9 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Fri, 1 Apr 2022 16:49:47 -0700 Subject: [PATCH 0243/1072] Add changes introduced by PEP 685 --- source/specifications/core-metadata.rst | 41 ++++++++++++++++--- .../specifications/dependency-specifiers.rst | 2 + source/specifications/entry-points.rst | 3 +- 3 files changed, 39 insertions(+), 7 deletions(-) diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst index ef28081cc..7187e7784 100644 --- a/source/specifications/core-metadata.rst +++ b/source/specifications/core-metadata.rst @@ -45,8 +45,8 @@ Metadata-Version .. versionadded:: 1.0 -Version of the file format; legal values are "1.0", "1.1", "1.2", "2.1" -and "2.2". +Version of the file format; legal values are "1.0", "1.1", "1.2", "2.1", +"2.2", and "2.3". Automated tools consuming metadata SHOULD warn if ``metadata_version`` is greater than the highest version they support, and MUST fail if @@ -60,7 +60,7 @@ all of the needed fields. Example:: - Metadata-Version: 2.2 + Metadata-Version: 2.3 .. _core-metadata-name: @@ -84,6 +84,12 @@ Example:: Name: BeagleVote +To normalize a distribution name for comparison purposes, it should be +lowercased with all runs of the characters ``.``, ``-``, or ``_`` replaced with +a single ``-`` character. This can be done using the following snippet of code +(as specified in :pep:`503`):: + + re.sub(r"[-_.]+", "-", name).lower() .. _core-metadata-version: @@ -510,7 +516,8 @@ The format of a requirement string contains from one to four parts: The only mandatory part. * A comma-separated list of 'extra' names. These are defined by the required project, referring to specific features which may - need extra dependencies. + need extra dependencies. The names MUST conform to the restrictions + specified by the ``Provides-Extra:`` field. * A version specifier. Tools parsing the format should accept optional parentheses around this, but tools generating it should not use parentheses. @@ -613,9 +620,20 @@ Provides-Extra (multiple use) ============================= .. versionadded:: 2.1 +.. versionchanged:: 2.3 + :pep:`685` restricted valid values to be unambiguous (i.e. no normalization + required). For older metadata versions, value restrictions were brought into + line with ``Name:`` and normalization rules were introduced. + +A string containing the name of an optional feature. A valid name consists only +of lowercase ASCII letters, ASCII numbers, and hyphen. It must start and end +with a letter or number. Hyphens cannot be followed by another hyphen. Names are +limited to those which match the following regex (which guarantees unambiguity):: + + ^([a-z0-9]|[a-z0-9]([a-z0-9-](?!-))*[a-z0-9])$ -A string containing the name of an optional feature. Must be a valid Python -identifier. May be used to make a dependency conditional on whether the + +The specified name may be used to make a dependency conditional on whether the optional feature has been requested. Example:: @@ -640,6 +658,17 @@ respectively. It is legal to specify ``Provides-Extra:`` without referencing it in any ``Requires-Dist:``. +When writing data for older metadata versions, names MUST be normalized +following the same rules used for the ``Name:`` field when performing +comparisons. Tools writing metadata MUST raise an error if two +``Provides-Extra:`` entries would clash after being normalized. + +When reading data for older metadata versions, tools SHOULD warn when values +for this field would be invalid under newer metadata versions. If a value would +be invalid following the rules for ``Name:`` in any core metadata version, the +user SHOULD be warned and the value ignored to avoid ambiguity. Tools MAY choose +to raise an error when reading an invalid name for older metadata versions. + Rarely Used Fields ================== diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst index d2046e911..ab33de726 100644 --- a/source/specifications/dependency-specifiers.rst +++ b/source/specifications/dependency-specifiers.rst @@ -10,3 +10,5 @@ component is defined in :pep:`508`. The environment markers section in this PEP supersedes the environment markers section in :pep:`345`. + +Restrictions on names for extras is defined in :pep:`685`. diff --git a/source/specifications/entry-points.rst b/source/specifications/entry-points.rst index eab99b41a..6c94a25fb 100644 --- a/source/specifications/entry-points.rst +++ b/source/specifications/entry-points.rst @@ -105,7 +105,8 @@ Within a value, readers must accept and ignore spaces (including multiple consecutive spaces) before or after the colon, between the object reference and the left square bracket, between the extra names and the square brackets and colons delimiting them, and after the right square bracket. The syntax for -extras is formally specified as part of :pep:`508` (as ``extras``). +extras is formally specified as part of :pep:`508` (as ``extras``) and +restrictions on values specified in :pep:`685`. For tools writing the file, it is recommended only to insert a space between the object reference and the left square bracket. From d7f6aa91912b2e698e164c8fb260111064919cdb Mon Sep 17 00:00:00 2001 From: Tzu-ping Chung Date: Tue, 19 Apr 2022 17:59:59 +0800 Subject: [PATCH 0244/1072] In wheel spec, 'include' should be 'headers' (#1072) Co-authored-by: Brian Rutledge --- source/specifications/binary-distribution-format.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst index c7658e4b0..62cee7d1a 100644 --- a/source/specifications/binary-distribution-format.rst +++ b/source/specifications/binary-distribution-format.rst @@ -196,7 +196,7 @@ its version, e.g. ``1.0.0``, consist of: #. ``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths - (e.g. ``data``, ``scripts``, ``include``, ``purelib``, ``platlib``). + (e.g. ``data``, ``scripts``, ``headers``, ``purelib``, ``platlib``). #. Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no From 059e8154a329be6b617de9c100764dfd9ff055da Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Sun, 8 May 2022 07:58:44 -0700 Subject: [PATCH 0245/1072] Fix the regular expression validating extra names (#1076) --- source/specifications/core-metadata.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst index 7187e7784..2e85d0909 100644 --- a/source/specifications/core-metadata.rst +++ b/source/specifications/core-metadata.rst @@ -630,7 +630,7 @@ of lowercase ASCII letters, ASCII numbers, and hyphen. It must start and end with a letter or number. Hyphens cannot be followed by another hyphen. Names are limited to those which match the following regex (which guarantees unambiguity):: - ^([a-z0-9]|[a-z0-9]([a-z0-9-](?!-))*[a-z0-9])$ + ^([a-z0-9]|[a-z0-9]([a-z0-9-](?!--))*[a-z0-9])$ The specified name may be used to make a dependency conditional on whether the From eb42238e227c8474aaa51585440732bebd9e032c Mon Sep 17 00:00:00 2001 From: Ofek Lev Date: Mon, 9 May 2022 08:22:52 -0400 Subject: [PATCH 0246/1072] Update description of Hatch (#1074) * Update description of Hatch * this too * fix typo * update link * update link --- source/key_projects.rst | 29 +++++++++++----------- source/specifications/pypirc.rst | 3 +-- source/tutorials/managing-dependencies.rst | 6 ++--- 3 files changed, 18 insertions(+), 20 deletions(-) diff --git a/source/key_projects.rst b/source/key_projects.rst index 39ebfab03..be5500085 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -105,6 +105,20 @@ Python 2, so long as they can be imported on Python 3. .. _flit-rationale: https://flit.readthedocs.io/en/latest/rationale.html +.. _hatch: + +hatch +===== + +`GitHub and Docs `__ | +`PyPI `__ + +Hatch is a unified command-line tool meant to conveniently manage +dependencies and environment isolation for Python developers. Python +package developers use Hatch and its build backend Hatchling to +configure, version, specify dependencies for, and publish packages +to PyPI. Its plugin system allows for easily extending functionality. + .. _packaging: packaging @@ -438,21 +452,6 @@ problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016. -.. _hatch: - -hatch -===== - -`GitHub and Docs `__ | -`PyPI `__ - -Hatch is a unified command-line tool meant to conveniently manage -dependencies and environment isolation for Python developers. Python -package developers use Hatch to configure, version, specify -dependencies for, and publish packages to PyPI. Under the hood, it -uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and -install packages. - .. _multibuild: multibuild diff --git a/source/specifications/pypirc.rst b/source/specifications/pypirc.rst index 7f0c558a2..aeba72b0d 100644 --- a/source/specifications/pypirc.rst +++ b/source/specifications/pypirc.rst @@ -58,8 +58,7 @@ Common configurations .. note:: - These examples apply to :ref:`twine`, and projects like :ref:`hatch` that - use it under the hood. Other projects (e.g. :ref:`flit`) also use + These examples apply to :ref:`twine`. Other projects (e.g. :ref:`flit`) also use :file:`.pypirc`, but with different defaults. Please refer to each project's documentation for more details and usage instructions. diff --git a/source/tutorials/managing-dependencies.rst b/source/tutorials/managing-dependencies.rst index 61d2634dd..eaa32f7ef 100644 --- a/source/tutorials/managing-dependencies.rst +++ b/source/tutorials/managing-dependencies.rst @@ -160,9 +160,9 @@ If you find this particular approach to managing application dependencies isn't working well for you or your use case, you may want to explore these other tools and techniques, listed in alphabetical order, to see if one of them is a better fit: -* `hatch `_ for opinionated coverage of even - more steps in the project management workflow, such as incrementing versions, - tagging releases, and creating new skeleton projects from project templates. +* `hatch `_ for opinionated coverage of even + more steps in the project management workflow, such as incrementing versions + and creating new skeleton projects from project templates. * `micropipenv `_ for a lightweight wrapper around pip that supports ``requirements.txt``, Pipenv and Poetry lock files, or converting them to pip-tools compatible output. Designed for containerized From 9e839b0f28c0eab0da0d7ad39d61a88325f184e6 Mon Sep 17 00:00:00 2001 From: Henry Schreiner Date: Mon, 20 Jun 2022 15:43:35 -0400 Subject: [PATCH 0247/1072] feat: add PEP 621 config only (#1031) * feat: add PEP 621 config only * Apply suggestions from code review Co-authored-by: Brett Cannon * fix: minor fixes * refactor: include (future) setuptools * fix: stripping a bit more * fix: one more change as requested * chore: include hatch and experimental setuptools * fix: more positive setuptools mention * chore: use setuptools 61, mark experimental Signed-off-by: Henry Schreiner * refactor: place hatchling first * Apply suggestions from code review Co-authored-by: Brett Cannon * Update source/tutorials/packaging-projects.rst Co-authored-by: Ofek Lev * refactor: addressing review feedback Signed-off-by: Henry Schreiner * refactor: reorder backends and add recommendation Signed-off-by: Henry Schreiner * Edit for accuracy/simplicity, add TODOs * Refer to distributions instead of archives * Fix typo, add TODO * Fix typos * Rework build backend section * refactor: match package name Signed-off-by: Henry Schreiner * Update source/tutorials/packaging-projects.rst Co-authored-by: Ezio Melotti * fix: linkcheck, Py 3.7+, and periods are valid Signed-off-by: Henry Schreiner * Make changes based on discussion thread * Remove placeholder link * Minor copy-edits Co-authored-by: Brett Cannon Co-authored-by: Ofek Lev Co-authored-by: Brian Rutledge Co-authored-by: Ezio Melotti --- source/tutorials/packaging-projects.rst | 449 +++++++++--------------- 1 file changed, 162 insertions(+), 287 deletions(-) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index 36c83135a..23da5c88d 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -3,7 +3,7 @@ Packaging Python Projects This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how -to build the package, and how to upload it to the Python Package Index. +to build the package, and how to upload it to the Python Package Index (PyPI). .. tip:: @@ -34,9 +34,12 @@ sure you have the latest version installed: A simple project ---------------- -This tutorial uses a simple project named ``example_package``. We recommend -following this tutorial as-is using this project, before packaging your own -project. +This tutorial uses a simple project named +``example_package_YOUR_USERNAME_HERE``. If your username is ``me``, then the +package would be ``example_package_me``; this ensures that you have a unique +package name that doesn't conflict with packages uploaded by other people +following this tutorial. We recommend following this tutorial as-is using this +project, before packaging your own project. Create the following file structure locally: @@ -44,10 +47,13 @@ Create the following file structure locally: packaging_tutorial/ └── src/ - └── example_package/ + └── example_package_YOUR_USERNAME_HERE/ ├── __init__.py └── example.py +The directory containing the Python files should match the project name. This +simplifies the configuration and is more obvious to users who install the package. + :file:`__init__.py` is required to import the directory as a package, and should be empty. @@ -77,17 +83,17 @@ Creating the package files You will now add files that are used to prepare the project for distribution. When you're done, the project structure will look like this: + .. code-block:: text packaging_tutorial/ ├── LICENSE ├── pyproject.toml ├── README.md - ├── setup.cfg ├── src/ - │   └── example_package/ - │   ├── __init__.py - │   └── example.py + │ └── example_package_YOUR_USERNAME_HERE/ + │ ├── __init__.py + │ └── example.py └── tests/ @@ -100,241 +106,133 @@ Creating a test directory Creating pyproject.toml ----------------------- -:file:`pyproject.toml` tells build tools (like :ref:`pip` and :ref:`build`) -what is required to build your project. This tutorial uses :ref:`setuptools`, -so open :file:`pyproject.toml` and enter the following content: +.. TODO: Add an intro sentence about pyproject.toml, and a sub-heading for + "Configuring build tools" -.. code-block:: toml +:file:`pyproject.toml` tells tools "frontend" build tools like :ref:`pip` and +:ref:`build` what "backend" tool to use to create +:term:`distribution packages ` for your project. +You can choose from a number of backends; this tutorial uses :ref:`Hatchling +` by default, but it will work identically with :ref:`setuptools`, +:ref:`Flit `, :ref:`PDM `, and others that support the ``[project]`` +table for :ref:`metadata `. + +.. note:: + + Some build backends are part of larger tools that provide a command-line + interface with additional features like project initialization and version + management, as well as building, uploading, and installing packages. This + tutorial uses single-purpose tools that work independently. + +Open :file:`pyproject.toml` and enter one of these ``[build-system]`` tables: + +.. tab:: Hatchling + + .. code-block:: toml + + [build-system] + requires = ["hatchling"] + build-backend = "hatchling.build" + +.. tab:: setuptools + + .. code-block:: toml + + [build-system] + requires = ["setuptools>=61.0"] + build-backend = "setuptools.build_meta" + +.. tab:: Flit - [build-system] - requires = ["setuptools>=42"] - build-backend = "setuptools.build_meta" + .. code-block:: toml + [build-system] + requires = ["flit_core>=3.2"] + build-backend = "flit_core.buildapi" -``build-system.requires`` gives a list of packages that are needed to build your -package. Listing something here will *only* make it available during the build, -not after it is installed. +.. tab:: PDM -``build-system.build-backend`` is the name of Python object that will be used to -perform the build. If you were to use a different build system, such as -:ref:`flit` or :ref:`poetry`, those would go here, and the configuration details -would be completely different than the :ref:`setuptools` configuration described -below. + .. code-block:: toml -See :pep:`517` and :pep:`518` for background and details. + [build-system] + requires = ["pdm-pep517"] + build-backend = "pdm.pep517.api" +- ``requires`` is a list of packages that are needed to build your package. You + don't need to install them; build frontends like :ref:`pip` will install them + automatically in a temporary, isolated virtual environment for use during the + build process. +- ``build-backend`` is the name of the Python object that frontends will use to + perform the build. + +.. TODO: Add note to check the tools' documentation for the current snippet? + +.. _configuring metadata: + Configuring metadata --------------------- - -There are two types of metadata: static and dynamic. - -* Static metadata (:file:`setup.cfg`): guaranteed to be the same every time. This is - simpler, easier to read, and avoids many common errors, like encoding errors. -* Dynamic metadata (:file:`setup.py`): possibly non-deterministic. Any items that are - dynamic or determined at install-time, as well as extension modules or - extensions to setuptools, need to go into :file:`setup.py`. - -Static metadata (:file:`setup.cfg`) should be preferred. Dynamic metadata (:file:`setup.py`) -should be used only as an escape hatch when absolutely necessary. :file:`setup.py` used to -be required, but can be omitted with newer versions of setuptools and pip. - - -.. tab:: :file:`setup.cfg` (static) - - :file:`setup.cfg` is the configuration file for :ref:`setuptools`. It tells - setuptools about your package (such as the name and version) as well as which - code files to include. Eventually much of this configuration may be able to move - to :file:`pyproject.toml`. - - Open :file:`setup.cfg` and enter the following content. Change the ``name`` - to include your username; this ensures that you have a unique package name - and that your package doesn't conflict with packages uploaded by other - people following this tutorial. - - .. code-block:: python - - [metadata] - name = example-package-YOUR-USERNAME-HERE - version = 0.0.1 - author = Example Author - author_email = author@example.com - description = A small example package - long_description = file: README.md - long_description_content_type = text/markdown - url = https://github.com/pypa/sampleproject - project_urls = - Bug Tracker = https://github.com/pypa/sampleproject/issues - classifiers = - Programming Language :: Python :: 3 - License :: OSI Approved :: MIT License - Operating System :: OS Independent - - [options] - package_dir = - = src - packages = find: - python_requires = >=3.6 - - [options.packages.find] - where = src - - There are a `variety of metadata and options - `_ - supported here. This is in :doc:`configparser ` - format; do not place quotes around values. This example package uses a - relatively minimal set of ``metadata``: - - - ``name`` is the *distribution name* of your package. This can be any name as - long as it only contains letters, numbers, ``_`` , and ``-``. It also must not - already be taken on pypi.org. **Be sure to update this with your username,** - as this ensures you won't try to upload a package with the same name as one - which already exists. - - ``version`` is the package version. See :pep:`440` for more details on - versions. You can use ``file:`` or ``attr:`` directives to read from a file or - package attribute. - - ``author`` and ``author_email`` are used to identify the author of the - package. - - ``description`` is a short, one-sentence summary of the package. - - ``long_description`` is a detailed description of the package. This is - shown on the package detail page on the Python Package Index. In - this case, the long description is loaded from :file:`README.md` (which is - a common pattern) using the ``file:`` directive. - - ``long_description_content_type`` tells the index what type of markup is - used for the long description. In this case, it's Markdown. - - ``url`` is the URL for the homepage of the project. For many projects, this - will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting - service. - - ``project_urls`` lets you list any number of extra links to show on PyPI. - Generally this could be to documentation, issue trackers, etc. - - ``classifiers`` gives the index and :ref:`pip` some additional metadata - about your package. In this case, the package is only compatible with Python - 3, is licensed under the MIT license, and is OS-independent. You should - always include at least which version(s) of Python your package works on, - which license your package is available under, and which operating systems - your package will work on. For a complete list of classifiers, see - https://pypi.org/classifiers/. - - In the ``options`` category, we have controls for setuptools itself: - - - ``package_dir`` is a mapping of package names and directories. - An empty package name represents the "root package" --- the directory in - the project that contains all Python source files for the package --- so - in this case the ``src`` directory is designated the root package. - - ``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package - `. Instead of listing each package manually, we can - use the ``find:`` directive to automatically discover all packages and - subpackages and ``options.packages.find`` to specify the ``package_dir`` - to use. In this case, the list of packages will be ``example_package`` as - that's the only package present. - - ``python_requires`` gives the versions of Python supported by your - project. Installers like :ref:`pip` will look back through older versions of - packages until it finds one that has a matching Python version. - - There are many more than the ones mentioned here. See - :doc:`/guides/distributing-packages-using-setuptools` for more details. - - -.. tab:: :file:`setup.py` (dynamic) - - :file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools - about your package (such as the name and version) as well as which code files - to include. - - Open :file:`setup.py` and enter the following content. Change the ``name`` - to include your username; this ensures that you have a unique package name - and that your package doesn't conflict with packages uploaded by other - people following this tutorial. - - .. code-block:: python - - import setuptools - - with open("README.md", "r", encoding="utf-8") as fh: - long_description = fh.read() - - setuptools.setup( - name="example-package-YOUR-USERNAME-HERE", - version="0.0.1", - author="Example Author", - author_email="author@example.com", - description="A small example package", - long_description=long_description, - long_description_content_type="text/markdown", - url="https://github.com/pypa/sampleproject", - project_urls={ - "Bug Tracker": "https://github.com/pypa/sampleproject/issues", - }, - classifiers=[ - "Programming Language :: Python :: 3", - "License :: OSI Approved :: MIT License", - "Operating System :: OS Independent", - ], - package_dir={"": "src"}, - packages=setuptools.find_packages(where="src"), - python_requires=">=3.6", - ) - - - :func:`setup` takes several arguments. This example package uses a relatively - minimal set: - - - ``name`` is the *distribution name* of your package. This can be any name as - long as it only contains letters, numbers, ``_`` , and ``-``. It also must not - already be taken on pypi.org. **Be sure to update this with your username,** - as this ensures you won't try to upload a package with the same name as one - which already exists. - - ``version`` is the package version. See :pep:`440` for more details on - versions. - - ``author`` and ``author_email`` are used to identify the author of the - package. - - ``description`` is a short, one-sentence summary of the package. - - ``long_description`` is a detailed description of the package. This is - shown on the package detail page on the Python Package Index. In - this case, the long description is loaded from :file:`README.md`, which is - a common pattern. - - ``long_description_content_type`` tells the index what type of markup is - used for the long description. In this case, it's Markdown. - - ``url`` is the URL for the homepage of the project. For many projects, this - will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting - service. - - ``project_urls`` lets you list any number of extra links to show on PyPI. - Generally this could be to documentation, issue trackers, etc. - - ``classifiers`` gives the index and :ref:`pip` some additional metadata - about your package. In this case, the package is only compatible with Python - 3, is licensed under the MIT license, and is OS-independent. You should - always include at least which version(s) of Python your package works on, - which license your package is available under, and which operating systems - your package will work on. For a complete list of classifiers, see - https://pypi.org/classifiers/. - - ``package_dir`` is a dictionary with package names for keys and directories - for values. An empty package name represents the "root package" --- the - directory in the project that contains all Python source files for the - package --- so in this case the ``src`` directory is designated the root - package. - - ``packages`` is a list of all Python :term:`import packages ` that should be included in the :term:`distribution package - `. Instead of listing each package manually, we can - use :func:`find_packages` to automatically discover all packages and - subpackages under ``package_dir``. In this case, the list of packages will - be ``example_package`` as that's the only package present. - - ``python_requires`` gives the versions of Python supported by your - project. Installers like :ref:`pip` will look back though older versions of - packages until it finds one that has a matching Python version. - - There are many more than the ones mentioned here. See - :doc:`/guides/distributing-packages-using-setuptools` for more details. - - .. warning:: - - You may see some existing projects or other Python packaging tutorials that - import their ``setup`` function from ``distutils.core`` rather than - ``setuptools``. This is a legacy approach that installers support - for backwards compatibility purposes [1]_, but using the legacy ``distutils`` API - directly in new projects is strongly discouraged, since ``distutils`` is - deprecated as per :pep:`632` and will be removed from the standard library - in Python 3.12. +^^^^^^^^^^^^^^^^^^^^ + +Open :file:`pyproject.toml` and enter the following content. Change the ``name`` +to include your username; this ensures that you have a unique +package name that doesn't conflict with packages uploaded by other people +following this tutorial. + +.. code-block:: toml + + [project] + name = "example_package_YOUR_USERNAME_HERE" + version = "0.0.1" + authors = [ + { name="Example Author", email="author@example.com" }, + ] + description = "A small example package" + readme = "README.md" + requires-python = ">=3.7" + classifiers = [ + "Programming Language :: Python :: 3", + "License :: OSI Approved :: MIT License", + "Operating System :: OS Independent", + ] + + [project.urls] + "Homepage" = "https://github.com/pypa/sampleproject" + "Bug Tracker" = "https://github.com/pypa/sampleproject/issues" + +- ``name`` is the *distribution name* of your package. This can be any name as + long as it only contains letters, numbers, ``.``, ``_`` , and ``-``. It also + must not already be taken on PyPI. **Be sure to update this with your + username** for this tutorial, as this ensures you won't try to upload a + package with the same name as one which already exists. +- ``version`` is the package version. See the :ref:`version specifier specification ` + for more details on versions. Some build backends allow it to be specified + another way, such as from a file or a git tag. +- ``authors`` is used to identify the author of the package; you specify a name + and an email for each author. You can also list ``maintainers`` in the same + format. +- ``description`` is a short, one-sentence summary of the package. +- ``readme`` is a path to a file containing a detailed description of the + package. This is shown on the package detail page on PyPI. + In this case, the description is loaded from :file:`README.md` (which is a + common pattern). There also is a more advanced table form described in the + :ref:`project metadata specification `. +- ``requires-python`` gives the versions of Python supported by your + project. Installers like :ref:`pip` will look back through older versions of + packages until it finds one that has a matching Python version. +- ``classifiers`` gives the index and :ref:`pip` some additional metadata + about your package. In this case, the package is only compatible with Python + 3, is licensed under the MIT license, and is OS-independent. You should + always include at least which version(s) of Python your package works on, + which license your package is available under, and which operating systems + your package will work on. For a complete list of classifiers, see + https://pypi.org/classifiers/. +- ``urls`` lets you list any number of extra links to show on PyPI. + Generally this could be to the source, documentation, issue trackers, etc. + +See the :ref:`project metadata specification ` for +details on these and other fields that can be defined in the ``[project]`` +table. Other common fields are ``keywords`` to improve discoverability and the +``dependencies`` that are required to install your package. Creating README.md ------------------ @@ -351,12 +249,6 @@ if you'd like. to write your content. -Because our configuration loads :file:`README.md` to provide a -``long_description``, :file:`README.md` must be included along with your -code when you :ref:`generate a source distribution `. -Newer versions of :ref:`setuptools` will do this automatically. - - Creating a LICENSE ------------------ @@ -395,21 +287,15 @@ Including other files The files listed above will be included automatically in your :term:`source distribution `. If you want to -control what goes in this explicitly, see :ref:`Using MANIFEST.in`. - -The final :term:`built distribution ` will have the Python -files in the discovered or listed Python packages. If you want to control what -goes here, such as to add data files, see -:doc:`Including Data Files ` -from the :doc:`setuptools docs `. +include additional files, see the documentation for your build backend. .. _generating archives: Generating distribution archives -------------------------------- -The next step is to generate :term:`distribution packages ` for the package. These are archives that are uploaded to the Python +The next step is to generate :term:`distribution packages ` +for the package. These are archives that are uploaded to the Python Package Index and can be installed by :ref:`pip`. Make sure you have the latest version of PyPA's :ref:`build` installed: @@ -449,17 +335,17 @@ files in the :file:`dist` directory: .. code-block:: text dist/ - example-package-YOUR-USERNAME-HERE-0.0.1-py3-none-any.whl - example-package-YOUR-USERNAME-HERE-0.0.1.tar.gz + example_package_YOUR_USERNAME_HERE-0.0.1-py3-none-any.whl + example_package_YOUR_USERNAME_HERE-0.0.1.tar.gz -The ``tar.gz`` file is a :term:`source archive ` whereas the -``.whl`` file is a :term:`built distribution `. Newer -:ref:`pip` versions preferentially install built distributions, but will fall -back to source archives if needed. You should always upload a source archive and -provide built archives for the platforms your project is compatible with. In -this case, our example package is compatible with Python on any platform so only -one built distribution is needed. +The ``tar.gz`` file is a :term:`source distribution ` +whereas the ``.whl`` file is a :term:`built distribution `. +Newer :ref:`pip` versions preferentially install built distributions, but will +fall back to source distributions if needed. You should always upload a source +distribution and provide built distributions for the platforms your project is +compatible with. In this case, our example package is compatible with Python on +any platform so only one built distribution is needed. Uploading the distribution archives ----------------------------------- @@ -521,14 +407,14 @@ After the command completes, you should see output similar to this: Uploading distributions to https://test.pypi.org/legacy/ Enter your username: [your username] Enter your password: - Uploading example-package-YOUR-USERNAME-HERE-0.0.1-py3-none-any.whl + Uploading example_package_YOUR_USERNAME_HERE-0.0.1-py3-none-any.whl 100%|█████████████████████| 4.65k/4.65k [00:01<00:00, 2.88kB/s] - Uploading example-package-YOUR-USERNAME-HERE-0.0.1.tar.gz + Uploading example_package_YOUR_USERNAME_HERE-0.0.1.tar.gz 100%|█████████████████████| 4.25k/4.25k [00:01<00:00, 3.05kB/s] -Once uploaded your package should be viewable on TestPyPI, for example, -https://test.pypi.org/project/example-package-YOUR-USERNAME-HERE +Once uploaded your package should be viewable on TestPyPI; for example: +``https://test.pypi.org/project/example_package_YOUR_USERNAME_HERE``. Installing your newly uploaded package @@ -558,9 +444,9 @@ something like this: .. code-block:: text Collecting example-package-YOUR-USERNAME-HERE - Downloading https://test-files.pythonhosted.org/packages/.../example-package-YOUR-USERNAME-HERE-0.0.1-py3-none-any.whl - Installing collected packages: example-package-YOUR-USERNAME-HERE - Successfully installed example-package-YOUR-USERNAME-HERE-0.0.1 + Downloading https://test-files.pythonhosted.org/packages/.../example_package_YOUR_USERNAME_HERE_0.0.1-py3-none-any.whl + Installing collected packages: example_package_YOUR_USERNAME_HERE + Successfully installed example_package_YOUR_USERNAME_HERE-0.0.1 .. note:: This example uses ``--index-url`` flag to specify TestPyPI instead of live PyPI. Additionally, it specifies ``--no-deps``. Since TestPyPI doesn't @@ -588,14 +474,10 @@ and import the package: .. code-block:: python - >>> from example_package import example + >>> from example_package_YOUR_USERNAME_HERE import example >>> example.add_one(2) 3 -Note that the :term:`import package ` is ``example_package`` -regardless of what ``name`` you gave your :term:`distribution package ` in :file:`setup.cfg` or :file:`setup.py` (in this case, -``example-package-YOUR-USERNAME-HERE``). Next steps ---------- @@ -613,7 +495,7 @@ do much the same as you did in this tutorial, but with these important differences: * Choose a memorable and unique name for your package. You don't have to append - your username as you did in the tutorial. + your username as you did in the tutorial, but you can't use an existing name. * Register an account on https://pypi.org - note that these are two separate servers and the login details from the test server are not shared with the main server. @@ -626,19 +508,12 @@ differences: At this point if you want to read more on packaging Python libraries here are some things you can do: -* Read more about using :ref:`setuptools` to package libraries in - :doc:`/guides/distributing-packages-using-setuptools`. +.. TODO: Add links to other guides +.. TODO: Add links to backend configuration docs + +* Consider packaging tools that provide a single command-line interface for + project management and packaging, such as :ref:`hatch`, :ref:`flit`, + :ref:`pdm`, and :ref:`poetry`. +* Read :pep:`517` and :pep:`518` for background and details on build tool configuration. * Read about :doc:`/guides/packaging-binary-extensions`. -* Consider alternatives to :ref:`setuptools` such as :ref:`flit`, :ref:`hatch`, - and :ref:`poetry`. - ----- - -.. [1] Some legacy Python environments may not have ``setuptools`` - pre-installed, and the operators of those environments may still be - requiring users to install packages by running ``setup.py install`` - commands, rather than providing an installer like ``pip`` that - automatically installs required build dependendencies. These - environments will not be able to use many published packages until the - environment is updated to provide an up to date Python package - installation client (e.g. by running ``python -m ensurepip``). + From 07638cdee829b94014f0cfb8f2ddace09b360988 Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Wed, 22 Jun 2022 08:43:09 -0400 Subject: [PATCH 0248/1072] Fix tutorial 'frontend' typo (#1091) --- source/tutorials/packaging-projects.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index 23da5c88d..c35267531 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -109,7 +109,7 @@ Creating pyproject.toml .. TODO: Add an intro sentence about pyproject.toml, and a sub-heading for "Configuring build tools" -:file:`pyproject.toml` tells tools "frontend" build tools like :ref:`pip` and +:file:`pyproject.toml` tells "frontend" build tools like :ref:`pip` and :ref:`build` what "backend" tool to use to create :term:`distribution packages ` for your project. You can choose from a number of backends; this tutorial uses :ref:`Hatchling From 24e37cc610fd0fd3c7da192536fbc333549a78b2 Mon Sep 17 00:00:00 2001 From: Ewout ter Hoeven Date: Thu, 23 Jun 2022 11:33:13 +0200 Subject: [PATCH 0249/1072] GHA publish to TestPyPI guide: Update actions, environment and Python (#1087) A bit of maintenance on the Publishing package distribution releases using GitHub Actions CI/CD workflows guide: - Update the host OS to ubuntu-latest - Update the actions/setup-python to v3 - Use Python 3.10 Co-authored-by: Brian Rutledge --- .../github-actions-ci-cd-sample/publish-to-test-pypi.yml | 8 ++++---- ...tion-releases-using-github-actions-ci-cd-workflows.rst | 7 ++++--- 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index c24d08091..cffc65c71 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -5,14 +5,14 @@ on: push jobs: build-n-publish: name: Build and publish Python 🐍 distributions 📦 to PyPI and TestPyPI - runs-on: ubuntu-18.04 + runs-on: ubuntu-latest steps: - uses: actions/checkout@master - - name: Set up Python 3.9 - uses: actions/setup-python@v1 + - name: Set up Python 3.10 + uses: actions/setup-python@v3 with: - python-version: 3.9 + python-version: "3.10" - name: Install pypa/build run: >- python -m diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index 55e251826..730098587 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -71,7 +71,8 @@ Defining a workflow job environment Now, let's add initial setup for our job. It's a process that will execute commands that we'll define later. -In this guide, we'll use Ubuntu 18.04: +In this guide, we'll use the latest stable Ubuntu LTS version +provided by GitHub Actions: .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml @@ -90,7 +91,7 @@ Then, add the following under the ``build-n-publish`` section: :end-before: Install pypa/build This will download your repository into the CI runner and then -install and activate Python 3.9. +install and activate Python 3.10. And now we can build dists from source. In this example, we'll use ``build`` package, assuming that your project has a @@ -107,7 +108,7 @@ So add this to the steps list: .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml - :start-after: version: 3.9 + :start-after: version: "3.10" :end-before: Actually publish to PyPI/TestPyPI From 3f972e3faad4ada36a0c215d84e89de62124be54 Mon Sep 17 00:00:00 2001 From: Henry Schreiner Date: Thu, 23 Jun 2022 13:59:31 -0400 Subject: [PATCH 0250/1072] chore: remove obsolete pages from the ToC (#1094) Signed-off-by: Henry Schreiner --- source/guides/index.rst | 4 ---- source/guides/migrating-to-pypi-org.rst | 4 ++++ source/guides/multi-version-installs.rst | 3 +++ source/guides/supporting-multiple-python-versions.rst | 4 +++- source/guides/supporting-windows-using-appveyor.rst | 4 +++- 5 files changed, 13 insertions(+), 6 deletions(-) diff --git a/source/guides/index.rst b/source/guides/index.rst index bd977ff04..10c189a17 100644 --- a/source/guides/index.rst +++ b/source/guides/index.rst @@ -13,7 +13,6 @@ introduction to packaging, see :doc:`/tutorials/index`. installing-stand-alone-command-line-tools installing-using-linux-tools installing-scientific-packages - multi-version-installs index-mirrors-and-caches hosting-your-own-index @@ -24,13 +23,10 @@ introduction to packaging, see :doc:`/tutorials/index`. distributing-packages-using-setuptools using-manifest-in single-sourcing-package-version - supporting-multiple-python-versions dropping-older-python-versions packaging-binary-extensions - supporting-windows-using-appveyor packaging-namespace-packages creating-and-discovering-plugins - migrating-to-pypi-org using-testpypi making-a-pypi-friendly-readme publishing-package-distribution-releases-using-github-actions-ci-cd-workflows diff --git a/source/guides/migrating-to-pypi-org.rst b/source/guides/migrating-to-pypi-org.rst index bb019fff0..2b565e8ee 100644 --- a/source/guides/migrating-to-pypi-org.rst +++ b/source/guides/migrating-to-pypi-org.rst @@ -1,8 +1,12 @@ +: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 diff --git a/source/guides/multi-version-installs.rst b/source/guides/multi-version-installs.rst index 15ca1f382..0c2929fbb 100644 --- a/source/guides/multi-version-installs.rst +++ b/source/guides/multi-version-installs.rst @@ -1,9 +1,12 @@ +: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 diff --git a/source/guides/supporting-multiple-python-versions.rst b/source/guides/supporting-multiple-python-versions.rst index 42d8efab1..23c1f51c0 100644 --- a/source/guides/supporting-multiple-python-versions.rst +++ b/source/guides/supporting-multiple-python-versions.rst @@ -1,10 +1,12 @@ +:orphan: + .. _`Supporting multiple Python versions`: =================================== Supporting multiple Python versions =================================== -:Page Status: Incomplete +:Page Status: Obsolete :Last Reviewed: 2014-12-24 .. contents:: Contents diff --git a/source/guides/supporting-windows-using-appveyor.rst b/source/guides/supporting-windows-using-appveyor.rst index 3a2d944a7..79242510c 100644 --- a/source/guides/supporting-windows-using-appveyor.rst +++ b/source/guides/supporting-windows-using-appveyor.rst @@ -1,8 +1,10 @@ +:orphan: + ================================= Supporting Windows using Appveyor ================================= -:Page Status: Incomplete +:Page Status: Obsolete :Last Reviewed: 2015-12-03 This section covers how to use the free `Appveyor`_ continuous integration From 813584b4a6f54b59efc5e031db519474babea0b9 Mon Sep 17 00:00:00 2001 From: Laurie O Date: Tue, 28 Jun 2022 10:52:07 +1000 Subject: [PATCH 0251/1072] Declare license file in packaging tutorial (#1098) * Declare license file in packaging tutorial Set and document `license.file` in project metadata in the packaging tutorial Fixes #1097 * Fix license doc in packaging tutorial * Update source/tutorials/packaging-projects.rst Co-authored-by: Brian Rutledge --- source/tutorials/packaging-projects.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index c35267531..bfb774335 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -188,6 +188,7 @@ following this tutorial. ] description = "A small example package" readme = "README.md" + license = { file="LICENSE" } requires-python = ">=3.7" classifiers = [ "Programming Language :: Python :: 3", @@ -216,6 +217,7 @@ following this tutorial. In this case, the description is loaded from :file:`README.md` (which is a common pattern). There also is a more advanced table form described in the :ref:`project metadata specification `. +- ``license`` is the path to the :file:`LICENSE` file, described below. - ``requires-python`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version. From c4f8407bbebc890ab7ab6e3a1d12ff009ec75cef Mon Sep 17 00:00:00 2001 From: Ofek Lev Date: Tue, 28 Jun 2022 21:31:53 -0400 Subject: [PATCH 0252/1072] Add docs link to Hatch section (#1102) --- source/key_projects.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/source/key_projects.rst b/source/key_projects.rst index be5500085..d404cbcef 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -110,7 +110,8 @@ Python 2, so long as they can be imported on Python 3. hatch ===== -`GitHub and Docs `__ | +`Docs `__ | +`GitHub `__ | `PyPI `__ Hatch is a unified command-line tool meant to conveniently manage From a256a5017d829c633940ea5dbb331f87bb6ca5e3 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Fri, 1 Jul 2022 05:53:47 -0700 Subject: [PATCH 0253/1072] Clarify requirements for `authors`/`maintainers` project metadata (#1103) It's a bit ambiguous as to whether leaving out both `name` and `email` is okay, an error, etc. The original intent was that _at least_ one key would be specified, but no specific key is required. --- source/specifications/declaring-project-metadata.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/source/specifications/declaring-project-metadata.rst b/source/specifications/declaring-project-metadata.rst index ccd058ad1..51f46bd94 100644 --- a/source/specifications/declaring-project-metadata.rst +++ b/source/specifications/declaring-project-metadata.rst @@ -158,7 +158,8 @@ These fields accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in :rfc:`822`) and not contain commas. The ``email`` value MUST be a -valid email address. Both keys are optional. +valid email address. Both keys are optional, but at least one of the +keys must be specified in the table. Using the data to fill in :ref:`core metadata ` is as follows: From 056adad6445ef87f573b68e22322582dc652c266 Mon Sep 17 00:00:00 2001 From: Dustin Ingram Date: Wed, 6 Jul 2022 19:18:26 +0000 Subject: [PATCH 0254/1072] Add section on getting absolute URLs via BigQuery dataset --- .../analyzing-pypi-package-downloads.rst | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/source/guides/analyzing-pypi-package-downloads.rst b/source/guides/analyzing-pypi-package-downloads.rst index f66cd5132..0d08a4e0f 100644 --- a/source/guides/analyzing-pypi-package-downloads.rst +++ b/source/guides/analyzing-pypi-package-downloads.rst @@ -217,6 +217,40 @@ query processes over 500 GB of data. | 3.5 | 1894153540 | +--------+---------------+ + +Getting absolute links to artifacts +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It's sometimes helpful to be able to get the absolute links to download +artifacts from PyPI based on their hashes, e.g. if a particular project or +release has been deleted from PyPI. The metadata table includes the ``path`` +column, which includes the hash and artifact filename. + +:: + + SELECT + CONCAT('https://files.pythonhosted.org/packages', path) as url + FROM + `bigquery-public-data.pypi.distribution_metadata` + WHERE + filename LIKE 'sampleproject%' + + ++-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| url | ++===================================================================================================================================================================+ +| https://files.pythonhosted.org/packages/eb/45/79be82bdeafcecb9dca474cad4003e32ef8e4a0dec6abbd4145ccb02abe1/sampleproject-1.2.0.tar.gz | ++-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| https://files.pythonhosted.org/packages/56/0a/178e8bbb585ec5b13af42dae48b1d7425d6575b3ff9b02e5ec475e38e1d6/sampleproject_nomura-1.2.0-py2.py3-none-any.whl | ++-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| https://files.pythonhosted.org/packages/63/88/3200eeaf22571f18d2c41e288862502e33365ccbdc12b892db23f51f8e70/sampleproject_nomura-1.2.0.tar.gz | ++-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| https://files.pythonhosted.org/packages/21/e9/2743311822e71c0756394b6c5ab15cb64ca66c78c6c6a5cd872c9ed33154/sampleproject_doubleyoung18-1.3.0-py2.py3-none-any.whl | ++-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| https://files.pythonhosted.org/packages/6f/5b/2f3fe94e1c02816fe23c7ceee5292fb186912929e1972eee7fb729fa27af/sampleproject-1.3.1.tar.gz | ++-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + + Caveats ======= From 17ec57f173dc05a490d1f9797babdd13400ac368 Mon Sep 17 00:00:00 2001 From: Dustin Ingram Date: Wed, 6 Jul 2022 16:18:54 -0400 Subject: [PATCH 0255/1072] Update source/guides/analyzing-pypi-package-downloads.rst --- source/guides/analyzing-pypi-package-downloads.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/source/guides/analyzing-pypi-package-downloads.rst b/source/guides/analyzing-pypi-package-downloads.rst index 0d08a4e0f..38f06e305 100644 --- a/source/guides/analyzing-pypi-package-downloads.rst +++ b/source/guides/analyzing-pypi-package-downloads.rst @@ -226,6 +226,7 @@ artifacts from PyPI based on their hashes, e.g. if a particular project or release has been deleted from PyPI. The metadata table includes the ``path`` column, which includes the hash and artifact filename. +Note that the URL generated here is not guaranteed to be stable, but currently aligns with the URL where PyPI artifacts are hosted. :: SELECT From 4e6407536957f0bddfb9eae4b62c0b6a3d0006a7 Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Thu, 21 Jul 2022 12:41:55 -0400 Subject: [PATCH 0256/1072] Fix ActiveState link (#1109) --- source/overview.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/overview.rst b/source/overview.rst index 5b233bbef..7031327b2 100644 --- a/source/overview.rst +++ b/source/overview.rst @@ -290,7 +290,7 @@ A similar model involves installing an alternative Python distribution, but does not support arbitrary operating system-level packages: -* `ActiveState ActivePython `_ +* `ActiveState ActivePython `_ * `WinPython `_ .. _bringing-your-own-python: From 1f35bc32d10c525f212d021b5d579158988f22be Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Mon, 25 Jul 2022 23:19:33 +0200 Subject: [PATCH 0257/1072] Use the release-branch in GHA publish snippets Resolves #1108 --- .../github-actions-ci-cd-sample/publish-to-test-pypi.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index cffc65c71..ebbc70c28 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -29,12 +29,12 @@ jobs: . # Actually publish to PyPI/TestPyPI - name: Publish distribution 📦 to Test PyPI - uses: pypa/gh-action-pypi-publish@master + uses: pypa/gh-action-pypi-publish@release/v1 with: password: ${{ secrets.TEST_PYPI_API_TOKEN }} repository_url: https://test.pypi.org/legacy/ - name: Publish distribution 📦 to PyPI if: startsWith(github.ref, 'refs/tags') - uses: pypa/gh-action-pypi-publish@master + uses: pypa/gh-action-pypi-publish@release/v1 with: password: ${{ secrets.PYPI_API_TOKEN }} From 5734dde65d1ddaf5ad164bd91aeafb8f35bfed38 Mon Sep 17 00:00:00 2001 From: Cameron Simpson Date: Fri, 29 Jul 2022 08:37:22 +1000 Subject: [PATCH 0258/1072] adding a "packaging flow" overview document (#1100) * add initial translation of the flow document from the MarkDown original * source/index.rst: add the flow to the toctree * source/flow.rst: minor formatting and typo fixes * flow.rst: some suggestions from @ abravalheri * flow.rst: small clarification that this is about distribution packages, suggestion from @sinoroc * undo previous commit - this isn't just about distribution packages * flow.rst: I was wrong, restoring @sinoroc's suggestion * flow.rst: The Configuration File: be less prescriptive - suggestion by @abravalheri * flow.rst: The Build System: small elaboration suggested by @pfmoore * flow.rst: use :pep: roles for PEP references * flow.rst: convert in tree refs to :doc: * flow.rst: small fixups * Lots of copy edits and TODOs * Set 78 character line length * Condense build-system description * Tweak project links * flow.rst: restore mention of "pip" in the end user steps * flow.rst: no, the PEP links are indeed not useful; I've mentioned a PEP elsewhere in context though * flow.rst: replace tool links with references to the key projects file * flow.rst: mention build frontends and backends * flow.rst: mention all 3 of setuptools, flit and hatchling * flow.rst: add a paragraph about end user systems how wheel tags can denote them * Reformat and add TODOs * Link more key projects * Rework wheel section * Rework frontend and backend * Simplify example build-system * Always use ref for tools * Link other install tools * Tweak pip reference Co-authored-by: Brian Rutledge --- source/flow.rst | 177 +++++++++++++++++++++++++++++++++++++++++++++++ source/index.rst | 3 + 2 files changed, 180 insertions(+) create mode 100644 source/flow.rst diff --git a/source/flow.rst b/source/flow.rst new file mode 100644 index 000000000..d1d82b190 --- /dev/null +++ b/source/flow.rst @@ -0,0 +1,177 @@ +================== +The Packaging Flow +================== + +The document aims to outline the flow involved in publishing/distributing a +:term:`distribution package `, usually to the `Python +Package Index (PyPI)`_. It is written for package publishers, who are assumed +to be the package author. + +.. _Python Package Index (PyPI): https://pypi.org/ + +While the :doc:`tutorial ` walks through the +process of preparing a simple package for release, it does not fully enumerate +what steps and files are required, and for what purpose. + +Publishing a package requires a flow from the author's source code to an end +user's Python environment. The steps to achieve this are: + +- Have a source tree containing the package. This is typically a checkout from + a version control system (VCS). + +- Prepare a configuration file describing the package metadata (name, version + and so forth) and how to create the build artifacts. For most packages, this + will be a :file:`pyproject.toml` file, maintained maunally in the source + tree. + +- Create build artifacts to be sent to the package distribution service + (usually PyPI); these will normally be a + :term:`source distribution ("sdist") ` + and one or more :term:`built distributions ("wheels") `. + These are made by a build tool using the configuration file from the + previous step. Often there is just one generic wheel for a pure Python + package. + +- Upload the build artifacts to the package distribution service. + +At that point, the package is present on the package distribution service. +To use the package, end users must: + +- Download one of the package's build artifacts from the package distribution + service. + +- Install it in their Python environment, usually in its ``site-packages`` + directory. This step may involve a build/compile step which, if needed, must + be described by the package metadata. + +These last 2 steps are typically performed by :ref:`pip` when an end user runs +``pip install``. + +The steps above are described in more detail below. + +The source tree +=============== + +The source tree contains the package source code, usually a checkout from a +VCS. The particular version of the code used to create the build artifacts +will typically be a checkout based on a tag associated with the version. + +The configuration file +====================== + +The configuration file depends on the tool used to create the build artifacts. +The standard practice is to use a :file:`pyproject.toml` file in the `TOML +format`_. + +.. _TOML format: https://github.com/toml-lang/toml + +At a minimum, the :file:`pyproject.toml` file needs a ``[build-system]`` table +specifying your build tool. There are many build tools available, including +but not limited to :ref:`flit`, :ref:`hatch`, :ref:`pdm`, :ref:`poetry`, +:ref:`setuptools`, `trampolim`_, and `whey`_. Each tool's documentation will +show what to put in the ``[build-system]`` table. + +.. _trampolim: https://pypi.org/project/trampolim/ +.. _whey: https://pypi.org/project/whey/ + +For example, here is a table for using :ref:`hatch`: + +.. code-block:: toml + + [build-system] + requires = ["hatchling"] + build-backend = "hatchling.build" + +With such a table in the :file:`pyproject.toml` file, a "frontend" tool like +:ref:`build` can run your chosen build tool's "backend" to create the build +artifacts. Your build tool may also provide its own frontend. An install tool +like :ref:`pip` also acts as a frontend when it runs your build tool's backend +to install from a source distribution. + +The particular build tool you choose dictates what additional information is +required in the :file:`pyproject.toml` file. For example, you might specify: + +* a ``[project]`` table containing project + :doc:`Core Metadata ` + (name, version, author and so forth); see + :doc:`Declaring project metadata ` + for more detail + +* a ``[tool]`` table containing tool-specific configuration options + +Build artifacts +=============== + +The source distribution (sdist) +------------------------------- + +A source distribution contains enough to install the package from source in an +end user's Python environment. As such, it needs the package source, and may +also include tests and documentation. These are useful for end users wanting +to develop your sources, and for end user systems where some local compilation +step is required (such as a C extension). + +The :ref:`build` package knows how to invoke your build tool to create one of +these: + +.. code-block:: bash + + python3 -m build --sdist source-tree-directory + +Or, your build tool may provide its own interface for creating an sdist. + + +The built distributions (wheels) +-------------------------------- + +A built distribution contains only the files needed for an end user's Python +environment. No compilation steps are required during the install, and the +wheel file can simply be unpacked into the ``site-packages`` directory. This +makes the install faster and more convenient for end users. + +A pure Python package typically needs only one "generic" wheel. A package with +compiled binary extensions needs a wheel for each supported combination of +Python interprerter, operating system, and CPU architecture that it supports. +If a suitable wheel file is not available, tools like :ref:`pip` will fall +back to installing the source distribtion. + +The :ref:`build` package knows how to invoke your build tool to create one of +these: + +.. code-block:: bash + + python3 -m build --wheel source-tree-directory + +Or, your build tool may provide its own interface for creating a wheel. + +.. note:: + + The default behaviour of :ref:`build` is to make both an sdist and a wheel + from the source in the current directory; the above examples are + deliberately specific. + +Upload to the package distribution service +========================================== + +The :ref:`twine` tool can upload build artifacts to PyPI for distribution, +using a command like: + +.. code-block:: bash + + twine upload dist/package-name-version.tar.gz dist/package-name-version-py3-none-any.whl + +Or, your build tool may provide its own interface for uploading. + +Download and install +==================== + +Now that the package is published, end users can download and install the +package into their Python environment. Typically this is done with :ref:`pip`, +using a command like: + +.. code-block:: bash + + python3 -m pip install package-name + +End users may also use other tools like :ref:`pipenv`, :ref:`poetry`, or +:ref:`pdm`. diff --git a/source/index.rst b/source/index.rst index 20e74d918..4cd8c8425 100644 --- a/source/index.rst +++ b/source/index.rst @@ -11,6 +11,7 @@ Python Packaging User Guide :hidden: overview + flow tutorials/index guides/index discussions/index @@ -37,6 +38,8 @@ Get started Essential tools and concepts for working within the Python development ecosystem are covered in our :doc:`tutorials/index` section: +* To get an overview of the flow used to publish your code, see the + :doc:`packaging flow ` * To learn how to install packages, see the :doc:`tutorial on installing packages ` * To learn how to manage dependencies in a version controlled project, see the From 70f3a3a07398922cbc4589cf0cded4de921288ba Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Sat, 30 Jul 2022 07:21:15 -0400 Subject: [PATCH 0259/1072] Upgrade python-docs-theme to fix directory trees --- requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements.txt b/requirements.txt index c4113b12b..807482a2c 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,6 +1,6 @@ sphinx==4.3.1 sphinx-autobuild==0.7.1 sphinx-inline-tabs==2021.4.11b9 -python-docs-theme==2021.5 +python-docs-theme==2022.1 sphinx-copybutton==0.4.0 git+https://github.com/pypa/pypa-docs-theme.git#egg=pypa-docs-theme From fc6b0647ba9f62d0a44f6c798294fd643fa82fbe Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Sat, 30 Jul 2022 07:21:28 -0400 Subject: [PATCH 0260/1072] Normalize directory tree --- source/tutorials/packaging-projects.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index bfb774335..07b5939b4 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -337,8 +337,8 @@ files in the :file:`dist` directory: .. code-block:: text dist/ - example_package_YOUR_USERNAME_HERE-0.0.1-py3-none-any.whl - example_package_YOUR_USERNAME_HERE-0.0.1.tar.gz + ├── example_package_YOUR_USERNAME_HERE-0.0.1-py3-none-any.whl + └── example_package_YOUR_USERNAME_HERE-0.0.1.tar.gz The ``tar.gz`` file is a :term:`source distribution ` From 54d49225f5bed7ae03eb5a52f8f9a4a7418c7beb Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Sat, 30 Jul 2022 07:40:55 -0400 Subject: [PATCH 0261/1072] Upgrade copybutton --- requirements.txt | 2 +- source/_static/overrides.css | 8 -------- source/conf.py | 4 +--- 3 files changed, 2 insertions(+), 12 deletions(-) delete mode 100644 source/_static/overrides.css diff --git a/requirements.txt b/requirements.txt index c4113b12b..426f0abbb 100644 --- a/requirements.txt +++ b/requirements.txt @@ -2,5 +2,5 @@ sphinx==4.3.1 sphinx-autobuild==0.7.1 sphinx-inline-tabs==2021.4.11b9 python-docs-theme==2021.5 -sphinx-copybutton==0.4.0 +sphinx-copybutton==0.5.0 git+https://github.com/pypa/pypa-docs-theme.git#egg=pypa-docs-theme diff --git a/source/_static/overrides.css b/source/_static/overrides.css deleted file mode 100644 index 53293aaf1..000000000 --- a/source/_static/overrides.css +++ /dev/null @@ -1,8 +0,0 @@ -/* Overrides for theme and plugin styles */ - -/* https://github.com/executablebooks/sphinx-copybutton/blob/v0.4.0/sphinx_copybutton/_static/copybutton.css */ - -button.copybtn img { - /* Fix alignment for pypa_theme */ - padding: 0; -} diff --git a/source/conf.py b/source/conf.py index 600c451c4..2dc8b6419 100644 --- a/source/conf.py +++ b/source/conf.py @@ -187,9 +187,7 @@ # Add any paths that contain custom static files (such as style sheets) here, # relative to this directory. They are copied after the builtin static files, # so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['_static'] - -html_css_files = ['overrides.css'] +# html_static_path = ['_static'] # Add any extra paths that contain custom files (such as robots.txt or # .htaccess) here, relative to this directory. These files are copied From 7591a0f16ecb1d3205d62218b1aaf4dce424ca74 Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Sat, 30 Jul 2022 16:35:57 -0400 Subject: [PATCH 0262/1072] Update Twine output (#1118) --- source/tutorials/packaging-projects.rst | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index 07b5939b4..3627fa3f1 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -404,18 +404,16 @@ the ``pypi-`` prefix. After the command completes, you should see output similar to this: -.. code-block:: bash +.. code-block:: Uploading distributions to https://test.pypi.org/legacy/ - Enter your username: [your username] - Enter your password: + Enter your username: __token__ Uploading example_package_YOUR_USERNAME_HERE-0.0.1-py3-none-any.whl - 100%|█████████████████████| 4.65k/4.65k [00:01<00:00, 2.88kB/s] + 100% ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 8.2/8.2 kB • 00:01 • ? Uploading example_package_YOUR_USERNAME_HERE-0.0.1.tar.gz - 100%|█████████████████████| 4.25k/4.25k [00:01<00:00, 3.05kB/s] + 100% ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 6.8/6.8 kB • 00:00 • ? - -Once uploaded your package should be viewable on TestPyPI; for example: +Once uploaded, your package should be viewable on TestPyPI; for example: ``https://test.pypi.org/project/example_package_YOUR_USERNAME_HERE``. From 02fb258cdafe1c1a4ca38e4a14d730ff5999ee25 Mon Sep 17 00:00:00 2001 From: arl Date: Mon, 1 Aug 2022 05:48:48 -0400 Subject: [PATCH 0263/1072] update the linehaul link to point to new repo (#1119) --- source/guides/analyzing-pypi-package-downloads.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/analyzing-pypi-package-downloads.rst b/source/guides/analyzing-pypi-package-downloads.rst index f66cd5132..55bdf370b 100644 --- a/source/guides/analyzing-pypi-package-downloads.rst +++ b/source/guides/analyzing-pypi-package-downloads.rst @@ -42,7 +42,7 @@ limited resources. Public dataset ============== -As an alternative, the `Linehaul project `__ +As an alternative, the `Linehaul project `__ streams download logs from PyPI to `Google BigQuery`_ [#]_, where they are stored as a public dataset. From a2e67878fb373e4ec03d6567f4ee8d663925d766 Mon Sep 17 00:00:00 2001 From: Otto Liljalaakso Date: Wed, 3 Aug 2022 21:46:46 +0300 Subject: [PATCH 0264/1072] Fix typo 'atempt' (#1122) --- source/specifications/recording-installed-packages.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/recording-installed-packages.rst b/source/specifications/recording-installed-packages.rst index 6d5eb839c..9085807f3 100644 --- a/source/specifications/recording-installed-packages.rst +++ b/source/specifications/recording-installed-packages.rst @@ -168,7 +168,7 @@ Here is an example snippet of a possible ``RECORD`` file:: blib2to3/pytree.py,sha256=RWj3IL4U-Ljhkn4laN0C3p7IRdfvT3aIRjTV-x9hK1c,28530 If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not -atempt to uninstall or upgrade the package. +attempt to uninstall or upgrade the package. (This does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.) From 4bfd160a2e520f1033785f4d51c890e4c9e558fe Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Thu, 4 Aug 2022 18:14:44 -0400 Subject: [PATCH 0265/1072] Upgrade to Sphinx 4.5.0. (#1123) This is quick fix to address broken `:rfc:` links, which seem to have been addreseds in [4.4.0](https://www.sphinx-doc.org/en/master/changes.html#release-4-4-0-released-jan-17-2022). Not upgrading to 5.x because that should include investigation of possible breaking changes. --- requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements.txt b/requirements.txt index 3a5ecdfca..57fd523b0 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,4 +1,4 @@ -sphinx==4.3.1 +sphinx==4.5.0 sphinx-autobuild==0.7.1 sphinx-inline-tabs==2021.4.11b9 python-docs-theme==2022.1 From 605bb169a903f1daaf10f711418590635a3a0221 Mon Sep 17 00:00:00 2001 From: Oz N Tiram Date: Fri, 5 Aug 2022 00:18:07 +0200 Subject: [PATCH 0266/1072] Update status of Pipenv - is actively maintained (#1121) Pipenv is currently actively maintained by @matteius and myself (@oz123). The project has seen multiple releases this year, and many bugs fixed. The activity on the project has even attracted new contributions. Additionally, the project is actively backed the Python foundation and tidelift. Co-authored-by: Brian Rutledge --- source/key_projects.rst | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/source/key_projects.rst b/source/key_projects.rst index d404cbcef..31fca457d 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -179,15 +179,14 @@ Pipenv Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` -into one single toolchain. It features very pretty terminal colors. +into one single toolchain. It can autoimport ``requirements.txt`` and also +check for CVEs in `Pipfile` using `safety `_. Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows (which other tools often underserve), makes and checkes file hashes, to ensure compliance with hash-locked dependency specifiers, and eases -uninstallation of packages and dependencies. It is used by Python -users and system administrators, but has been less maintained since -late 2018. +uninstallation of packages and dependencies. .. _Pipfile: From 5b9e0639fbabeae72b7c8712e3482f19a1921186 Mon Sep 17 00:00:00 2001 From: Andrey Rybakov Date: Tue, 9 Aug 2022 15:50:03 +0200 Subject: [PATCH 0267/1072] Fix broken links (#1127) --- source/specifications/binary-distribution-format.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst index 62cee7d1a..1f4bd89fa 100644 --- a/source/specifications/binary-distribution-format.rst +++ b/source/specifications/binary-distribution-format.rst @@ -316,9 +316,9 @@ checker only needs to establish that RECORD matches the signature. See - https://datatracker.ietf.org/doc/html/rfc7515 -- https://tools.ietf.org/id/draft-jones-json-web-signature-json-serialization-01.html +- https://datatracker.ietf.org/doc/html/draft-jones-json-web-signature-json-serialization-01 - https://datatracker.ietf.org/doc/html/rfc7517 -- https://tools.ietf.org/id/draft-jones-jose-json-private-key-01.html +- https://datatracker.ietf.org/doc/html/draft-jones-jose-json-private-key-01 Comparison to .egg From 4946f4d222d4057608d60ac3286ffafaec4fdbbc Mon Sep 17 00:00:00 2001 From: Andrey Rybakov Date: Tue, 9 Aug 2022 17:32:33 +0200 Subject: [PATCH 0268/1072] Correct spelling mistakes (#1126) --- source/flow.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/source/flow.rst b/source/flow.rst index d1d82b190..8a7d390b8 100644 --- a/source/flow.rst +++ b/source/flow.rst @@ -21,7 +21,7 @@ user's Python environment. The steps to achieve this are: - Prepare a configuration file describing the package metadata (name, version and so forth) and how to create the build artifacts. For most packages, this - will be a :file:`pyproject.toml` file, maintained maunally in the source + will be a :file:`pyproject.toml` file, maintained manually in the source tree. - Create build artifacts to be sent to the package distribution service @@ -131,9 +131,9 @@ makes the install faster and more convenient for end users. A pure Python package typically needs only one "generic" wheel. A package with compiled binary extensions needs a wheel for each supported combination of -Python interprerter, operating system, and CPU architecture that it supports. +Python interpreter, operating system, and CPU architecture that it supports. If a suitable wheel file is not available, tools like :ref:`pip` will fall -back to installing the source distribtion. +back to installing the source distribution. The :ref:`build` package knows how to invoke your build tool to create one of these: From c282845689047c2171818e6cd257ded2070ac0a1 Mon Sep 17 00:00:00 2001 From: fluesvamp <105884371+fluesvamp@users.noreply.github.com> Date: Fri, 19 Aug 2022 10:13:06 -0500 Subject: [PATCH 0269/1072] update url (#1129) --- source/key_projects.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/key_projects.rst b/source/key_projects.rst index 31fca457d..ba4461792 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -685,7 +685,7 @@ venv ==== `Docs `__ | -`Issues `__ +`Issues `__ A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more From 73e12eab9489e515a8c11317b44704a430fa5150 Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Wed, 24 Aug 2022 05:18:38 -0400 Subject: [PATCH 0270/1072] Fix SciPy docs link (#1133) --- source/guides/installing-scientific-packages.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst index a5feb4ad5..04f555731 100644 --- a/source/guides/installing-scientific-packages.rst +++ b/source/guides/installing-scientific-packages.rst @@ -91,7 +91,7 @@ published on python.org. macOS users also have access to Linux distribution style package managers such as ``Homebrew``. The SciPy site has more details on using Homebrew to -`install SciPy on macOS `_. +`install SciPy on macOS `_. SciPy distributions From 1834a857c1faf4080d29a93bb1628909d4a126a9 Mon Sep 17 00:00:00 2001 From: Mike Fiedler Date: Wed, 24 Aug 2022 05:22:18 -0400 Subject: [PATCH 0271/1072] docs: update references to specific pages (#1131) I noticed that the link was taking the reader to the main index page. Change the links to be more specific to target the actual pages in question. Signed-off-by: Mike Fiedler Signed-off-by: Mike Fiedler --- source/guides/making-a-pypi-friendly-readme.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/making-a-pypi-friendly-readme.rst b/source/guides/making-a-pypi-friendly-readme.rst index 326c6b93c..5e6eef4c7 100644 --- a/source/guides/making-a-pypi-friendly-readme.rst +++ b/source/guides/making-a-pypi-friendly-readme.rst @@ -97,7 +97,7 @@ If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source. Note that Sphinx extensions used in docstrings, such as -:doc:`directives and roles ` +:doc:`directives ` and :doc:`roles ` (e.g., "``:py:func:`getattr```" or "``:ref:`my-reference-label```"), are not allowed here and will result in error messages like "``Error: Unknown interpreted text role "py:func".``". From d530ba1a0021e8f2f7753cc29274b72d9101f14e Mon Sep 17 00:00:00 2001 From: Henry Schreiner Date: Wed, 24 Aug 2022 05:32:55 -0400 Subject: [PATCH 0272/1072] chore: nicer nox help text (#1128) Signed-off-by: Henry Schreiner Signed-off-by: Henry Schreiner Co-authored-by: Brian Rutledge --- noxfile.py | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) diff --git a/noxfile.py b/noxfile.py index 225433b50..fe7872995 100644 --- a/noxfile.py +++ b/noxfile.py @@ -6,8 +6,15 @@ import shutil import nox -@nox.session(py="3") + +nox.options.sessions = [] + + +@nox.session() def translation(session): + """ + Build the gettext .pot files. + """ session.install("-r", "requirements.txt") target_dir = "locales" session.run( @@ -18,8 +25,11 @@ def translation(session): target_dir, # where to put the .pot file ) -@nox.session(py="3") +@nox.session() def build(session, autobuild=False): + """ + Make the website. + """ session.install("-r", "requirements.txt") target_build_dir = "build" @@ -49,14 +59,20 @@ def build(session, autobuild=False): ) -@nox.session(py="3") +@nox.session() def preview(session): + """ + Make and preview the website. + """ session.install("sphinx-autobuild") build(session, autobuild=True) -@nox.session(py="3") +@nox.session() def linkcheck(session): + """ + Check for broken links. + """ session.install("-r", "requirements.txt") session.run( "sphinx-build", From 64b6a1fce15bf82012964382da668518dad1cc63 Mon Sep 17 00:00:00 2001 From: Julian Berman Date: Wed, 24 Aug 2022 05:36:46 -0400 Subject: [PATCH 0273/1072] Divorce the section on pip installing extras from setuptools (#1130) Per more recent PEPs (e.g. 621), extras may be produced by build tools other than setuptools if the packager isn't using setuptools as the build system. In this document, which is mostly about installing, it seems simpler then to avoid mentioning that setuptools defines the extras and to simply show the user how to do the install without mentioning what tool is involved in defining them. Co-authored-by: Brian Rutledge --- source/tutorials/installing-packages.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst index c68ea6c18..577d719cd 100644 --- a/source/tutorials/installing-packages.rst +++ b/source/tutorials/installing-packages.rst @@ -641,10 +641,13 @@ default, pip only finds stable versions. py -m pip install --pre SomeProject -Installing Setuptools "Extras" -============================== +Installing "Extras" +=================== -Install `setuptools extras`_. +Extras are optional "variants" of a package, which may include +additional dependencies, and thereby enable additional functionality +from the package. If you wish to install an extra for a package which +you know publishes one, you can include it in the pip installation command: .. tab:: Unix/macOS @@ -681,5 +684,3 @@ Install `setuptools extras`_. .. [4] The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0 - -.. _setuptools extras: https://setuptools.readthedocs.io/en/latest/userguide/dependency_management.html#optional-dependencies From 108ac27b6086ae38ce9d9b34a5040954d5c3fdc0 Mon Sep 17 00:00:00 2001 From: Bastian Venthur Date: Wed, 31 Aug 2022 11:51:22 +0200 Subject: [PATCH 0274/1072] replaced direct link with intersphinx reference (#1136) --- source/guides/distributing-packages-using-setuptools.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index c457a1e3b..057393c0b 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -542,8 +542,7 @@ work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `. -For more information, see `Automatic Script Creation -`_ +For more information, see :doc:`Entry Points ` from the :doc:`setuptools docs `. .. _`Choosing a versioning scheme`: From 9ee3a1303582183a583bccd113674a8a7398cf63 Mon Sep 17 00:00:00 2001 From: Bastian Venthur Date: Wed, 31 Aug 2022 12:21:27 +0200 Subject: [PATCH 0275/1072] Don't highlight TODO lists as code (#1137) closes: #447 --- source/guides/packaging-binary-extensions.rst | 32 ++++++++++--------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/source/guides/packaging-binary-extensions.rst b/source/guides/packaging-binary-extensions.rst index e9130119a..f27eb4730 100644 --- a/source/guides/packaging-binary-extensions.rst +++ b/source/guides/packaging-binary-extensions.rst @@ -230,16 +230,18 @@ The CPython :doc:`Extending and Embedding ` guide includes an introduction to writing a :doc:`custom extension module in C `. -:: +.. - mention the stable ABI (3.2+, link to the CPython C API docs) - mention the module lifecycle - mention the challenges of shared static state and subinterpreters - mention the implications of the GIL for extension modules - mention the memory allocation APIs in 3.4+ + FIXME + + * mention the stable ABI (3.2+, link to the CPython C API docs) + * mention the module lifecycle + * mention the challenges of shared static state and subinterpreters + * mention the implications of the GIL for extension modules + * mention the memory allocation APIs in 3.4+ - mention again that all this is one of the reasons why you probably - *don't* want to handcode your extension modules :) + * mention again that all this is one of the reasons why you probably *don't* + want to handcode your extension modules :) Building binary extensions @@ -311,16 +313,16 @@ Publishing binary extensions For interim guidance on this topic, see the discussion in :issue:`this issue <284>`. -:: +.. FIXME - cover publishing as wheel files on PyPI or a custom index server - cover creation of Windows and macOS installers - cover weak linking - mention the fact that Linux distros have a requirement to build from - source in their own build systems, so binary-only releases are strongly - discouraged + * cover publishing as wheel files on PyPI or a custom index server + * cover creation of Windows and macOS installers + * cover weak linking + * mention the fact that Linux distros have a requirement to build from + source in their own build systems, so binary-only releases are strongly + discouraged Additional resources From 9b0bc495a5ed6338160a2c7fcba9749a883a0c3f Mon Sep 17 00:00:00 2001 From: Bastian Venthur Date: Wed, 31 Aug 2022 12:23:51 +0200 Subject: [PATCH 0276/1072] Added obsolete fields: requires, provides and obsoletes closes: #1107 --- source/specifications/core-metadata.rst | 86 +++++++++++++++++++++++++ 1 file changed, 86 insertions(+) diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst index 2e85d0909..4a335ec10 100644 --- a/source/specifications/core-metadata.rst +++ b/source/specifications/core-metadata.rst @@ -755,6 +755,92 @@ Examples:: Obsoletes-Dist: OtherProject (<3.0) Obsoletes-Dist: Foo; os_name == "posix" + +Deprecated Fields +================= + +Requires +-------- + +.. versionadded:: 1.1 +.. deprecated:: 1.2 + in favour of ``Requires-Dist`` + +Each entry contains a string describing some other module or package required +by this package. + +The format of a requirement string is identical to that of a module or package +name usable with the ‘import’ statement, optionally followed by a version +declaration within parentheses. + +A version declaration is a series of conditional operators and version numbers, +separated by commas. Conditional operators must be one of "<", ">"', "<=", +">=", "==", and "!=". Version numbers must be in the format accepted by the +``distutils.version.StrictVersion`` class: two or three dot-separated numeric +components, with an optional "pre-release" tag on the end consisting of the +letter 'a' or 'b' followed by a number. Example version numbers are "1.0", +"2.3a2", "1.3.99", + +Any number of conditional operators can be specified, e.g. the string ">1.0, +!=1.3.4, <2.0" is a legal version declaration. + +All of the following are possible requirement strings: "rfc822", "zlib +(>=1.1.4)", "zope". + +There’s no canonical list of what strings should be used; the Python community +is left to choose its own standards. + +Examples:: + + Requires: re + Requires: sys + Requires: zlib + Requires: xml.parsers.expat (>1.0) + Requires: psycopg + + +Provides +-------- + +.. versionadded:: 1.1 +.. deprecated:: 1.2 + in favour of ``Provides-Dist`` + +Each entry contains a string describing a package or module that will be +provided by this package once it is installed. These strings should match the +ones used in Requirements fields. A version declaration may be supplied +(without a comparison operator); the package’s version number will be implied +if none is specified. + +Examples:: + + Provides: xml + Provides: xml.utils + Provides: xml.utils.iso8601 + Provides: xml.dom + Provides: xmltools (1.3) + + +Obsoletes +--------- + +.. versionadded:: 1.1 +.. deprecated:: 1.2 + in favour of ``Obsoletes-Dist`` + +Each entry contains a string describing a package or module that this package +renders obsolete, meaning that the two packages should not be installed at the +same time. Version declarations can be supplied. + +The most common use of this field will be in case a package name changes, e.g. +Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued +Python, the Gorgon package should be removed. + +Example:: + + Obsoletes: Gorgon + + ---- .. [1] reStructuredText markup: From 83273697207c007398351d0e02cbbff2d17b4b9d Mon Sep 17 00:00:00 2001 From: arl Date: Tue, 6 Sep 2022 18:05:23 -0400 Subject: [PATCH 0277/1072] fix a typo in pep 621 specifications, my -> may (#1140) --- source/specifications/declaring-project-metadata.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/declaring-project-metadata.rst b/source/specifications/declaring-project-metadata.rst index 51f46bd94..193f32f19 100644 --- a/source/specifications/declaring-project-metadata.rst +++ b/source/specifications/declaring-project-metadata.rst @@ -33,7 +33,7 @@ or listed as dynamic are: - ``version`` -All other fields are considered optional and my be specified +All other fields are considered optional and may be specified statically, listed as dynamic, or left unspecified. From 21e5dc134f2911b53991e807b8d64dcb2e7a142d Mon Sep 17 00:00:00 2001 From: Paul Moore Date: Sat, 17 Sep 2022 14:50:49 +0100 Subject: [PATCH 0278/1072] Update sdist spec to reflect PEP 625 (#1141) --- .../source-distribution-format.rst | 21 +++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/source/specifications/source-distribution-format.rst b/source/specifications/source-distribution-format.rst index 3d6546502..385828e31 100644 --- a/source/specifications/source-distribution-format.rst +++ b/source/specifications/source-distribution-format.rst @@ -33,15 +33,23 @@ deemed a source tree. Source distribution file name ============================= -The file name of a sdist is not currently standardised, although the *de facto* -form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form -of the project name (see :pep:`503` for the canonicalization rules) with ``-`` -characters replaced with ``_``, and ``{version}`` is the canonicalized form of -the project version (see :ref:`version-specifiers`). +The file name of a sdist was standardised in :pep:`625`. The file name must be in +the form ``{name}-{version}.tar.gz``, where ``{name}`` is normalised according to +the same rules as for binary distributions (see :ref:`binary-distribution-format`), +and ``{version}`` is the canonicalized form of the project version (see +:ref:`version-specifiers`). The name and version components of the filename MUST match the values stored in the metadata contained in the file. +Code that produces a source distribution file MUST give the file a name that matches +this specification. This includes the ``build_sdist`` hook of a build backend. + +Code that processes source distribution files MAY recognise source distribution files +by the ``.tar.gz`` suffix and the presence of precisely *one* hyphen in the filename. +Code that does this may then use the distribution name and version from the filename +without further verification. + Source distribution file format =============================== @@ -57,4 +65,5 @@ No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project. The tarball should use the modern POSIX.1-2001 pax tar format, which specifies -UTF-8 based file names. +UTF-8 based file names. In particular, source distribution files must be readable +using the standard library tarfile module with the open flag 'r:gz'. From 41eb7473a230dfb38f1df8e195524dc8cd328e72 Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Sat, 24 Sep 2022 20:33:34 -0400 Subject: [PATCH 0279/1072] Revert "Declare license file in packaging tutorial" (#1143) * Revert "Declare license file in packaging tutorial (#1098)" This reverts commit 813584b4a6f54b59efc5e031db519474babea0b9. * Document backend license inclusion behavioud (#1147) Co-authored-by: Laurie O --- source/tutorials/packaging-projects.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index 3627fa3f1..b65866c63 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -188,7 +188,6 @@ following this tutorial. ] description = "A small example package" readme = "README.md" - license = { file="LICENSE" } requires-python = ">=3.7" classifiers = [ "Programming Language :: Python :: 3", @@ -217,7 +216,6 @@ following this tutorial. In this case, the description is loaded from :file:`README.md` (which is a common pattern). There also is a more advanced table form described in the :ref:`project metadata specification `. -- ``license`` is the path to the :file:`LICENSE` file, described below. - ``requires-python`` gives the versions of Python supported by your project. Installers like :ref:`pip` will look back through older versions of packages until it finds one that has a matching Python version. @@ -283,6 +281,9 @@ MIT license: OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. +Most build backends automatically include license files in packages. See your +backend's documentation for more details. + Including other files --------------------- From 537d0550ba64745062044d8547928a66767845f5 Mon Sep 17 00:00:00 2001 From: Pradyun Gedam Date: Mon, 3 Oct 2022 20:44:35 +0100 Subject: [PATCH 0280/1072] Add initial draft of src vs flat layout discussion (#1150) --- source/discussions/index.rst | 1 + .../discussions/src-layout-vs-flat-layout.rst | 79 +++++++++++++++++++ 2 files changed, 80 insertions(+) create mode 100644 source/discussions/src-layout-vs-flat-layout.rst diff --git a/source/discussions/index.rst b/source/discussions/index.rst index ab35c93e1..bc1154507 100644 --- a/source/discussions/index.rst +++ b/source/discussions/index.rst @@ -12,3 +12,4 @@ specific topic. If you're just trying to get stuff done, see pip-vs-easy-install install-requires-vs-requirements wheel-vs-egg + src-layout-vs-flat-layout diff --git a/source/discussions/src-layout-vs-flat-layout.rst b/source/discussions/src-layout-vs-flat-layout.rst new file mode 100644 index 000000000..2bf9fcdb9 --- /dev/null +++ b/source/discussions/src-layout-vs-flat-layout.rst @@ -0,0 +1,79 @@ +========================= +src layout vs flat layout +========================= + +The "flat layout" refers to organising a project's files in a folder or +repository, such that the various configuration files and +:term:`import packages ` are all in the top-level directory. + +:: + + . + ├── README.md + ├── noxfile.py + ├── pyproject.toml + ├── setup.py + ├── awesome_package/ + │ ├── __init__.py + │ └── module.py + └── tools/ + ├── generate_awesomeness.py + └── decrease_world_suck.py + +The "src layout" deviates from the flat layout by moving the code that is +intended to be importable (i.e. ``import awesome_package``, also known as +:term:`import packages `) into a subdirectory. This +subdirectory is typically named ``src/``, hence "src layout". + +:: + + . + ├── README.md + ├── noxfile.py + ├── pyproject.toml + ├── setup.py + ├── src/ + │ └── awesome_package/ + │ ├── __init__.py + │ └── module.py + └── tools/ + ├── generate_awesomeness.py + └── decrease_world_suck.py + +Here's a breakdown of the important behaviour differences between the src +layout and the flat layout: + +* The src layout requires installation of the project to be able to run its + code, and the flat layout does not. + + This means that the src layout involves an additional step in the + development workflow of a project (typically, an + :doc:`editable installation ` + is used for development and a regular installation is used for testing). + +* The src layout helps prevent accidental usage of the in-development copy of + the code. + + This is relevant since the Python interpreter includes the current working + directory as the first item on the import path. This means that if an import + package exists in the current working directory with the same name as an + installed import package, the variant from the current working directory will + be used. This can lead to subtle misconfiguration of the project's packaging + tooling, which could result in files not being included in a distribution. + + The src layout helps avoid this by keeping import packages in a directory + separate from the root directory of the project, ensuring that the installed + copy is used. + +* The src layout helps enforce that an + :doc:`editable installation ` is only + able to import files that were meant to be importable. + + This is especially relevant when the editable installation is implemented + using a `path configuration file `_ + that adds the directory to the import path. + + The flat layout would add the other project files (eg: ``README.md``, + ``tox.ini``) and packaging/tooling configuration files (eg: ``setup.py``, + ``noxfile.py``) on the import path. This would make certain imports work + in editable installations but not regular installations. From 5bb954c4d295852bf615faabed7e4bbbc205129a Mon Sep 17 00:00:00 2001 From: Sumit Singh Date: Thu, 20 Oct 2022 00:18:36 +0530 Subject: [PATCH 0281/1072] bugfix(docs): fix typo :bug: (#1152) --- source/guides/analyzing-pypi-package-downloads.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/analyzing-pypi-package-downloads.rst b/source/guides/analyzing-pypi-package-downloads.rst index 55bdf370b..a8fa65aa2 100644 --- a/source/guides/analyzing-pypi-package-downloads.rst +++ b/source/guides/analyzing-pypi-package-downloads.rst @@ -51,7 +51,7 @@ Getting set up In order to use `Google BigQuery`_ to query the `public PyPI download statistics dataset`_, you'll need a Google account and to enable the BigQuery -API on a Google Cloud Platform project. You can run the up to 1TB of queries +API on a Google Cloud Platform project. You can run up to 1TB of queries per month `using the BigQuery free tier without a credit card `__ From 759a78d6bf812913d5cd5c2e3b3c50c51464ec9b Mon Sep 17 00:00:00 2001 From: pushfoo <36696816+pushfoo@users.noreply.github.com> Date: Wed, 19 Oct 2022 18:20:43 -0400 Subject: [PATCH 0282/1072] Link Python 3 doc instead of Python 2 (#1153) --- source/conf.py | 1 - 1 file changed, 1 deletion(-) diff --git a/source/conf.py b/source/conf.py index 2dc8b6419..d92aa8d0d 100644 --- a/source/conf.py +++ b/source/conf.py @@ -416,7 +416,6 @@ 'pypa': ('https://www.pypa.io/en/latest/', None), 'python': ('https://docs.python.org/3', None), 'python-guide': ('https://docs.python-guide.org', None), - 'python2': ('https://docs.python.org/2', None), 'setuptools': ('https://setuptools.readthedocs.io/en/latest/', None), 'spack': ('https://spack.readthedocs.io/en/latest/', None), 'sphinx': ('https://www.sphinx-doc.org/en/master', None), From b967145cb56854a0d26c8bebf9b1effe015a509f Mon Sep 17 00:00:00 2001 From: partev Date: Fri, 21 Oct 2022 21:05:48 -0400 Subject: [PATCH 0283/1072] update distlib links (#1155) distlib has been migrated from BitBucket to GitHub. update the links accordingly --- source/key_projects.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/key_projects.rst b/source/key_projects.rst index ba4461792..ac790b59a 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -64,8 +64,8 @@ distlib ======= :doc:`Docs ` | -`Issues `__ | -`Bitbucket `__ | +`Issues `__ | +`GitHub `__ | `PyPI `__ ``distlib`` is a library which implements low-level functions that From f5358541dd1507ab717a95788fb5b8dfdb348c4c Mon Sep 17 00:00:00 2001 From: arl Date: Mon, 24 Oct 2022 12:00:18 -0400 Subject: [PATCH 0284/1072] add pip-tools docs link (#1151) Co-authored-by: Brian Rutledge --- source/key_projects.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/source/key_projects.rst b/source/key_projects.rst index ac790b59a..ab4eb398d 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -496,7 +496,8 @@ make deployment of Python applications as simple as ``cp``. pip-tools ========= -`GitHub and Docs `__ | +`Docs `__ | +`GitHub `__ | `PyPI `__ pip-tools is a suite of tools meant for Python system administrators From d580a571dd8dc205fb33b5320c13a8e305bab8ba Mon Sep 17 00:00:00 2001 From: Rafael Fontenelle Date: Sun, 23 Oct 2022 23:05:18 -0300 Subject: [PATCH 0285/1072] Update versions of github actions --- .github/workflows/translation.yml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml index 7b1bf40d4..d2ac8db35 100644 --- a/.github/workflows/translation.yml +++ b/.github/workflows/translation.yml @@ -18,14 +18,14 @@ jobs: steps: - name: Grab the repo src - uses: actions/checkout@v2 + uses: actions/checkout@v3 with: fetch-depth: 0 # To reach the common commit - name: Set up git user as [bot] # Refs: # * https://github.community/t/github-actions-bot-email-address/17204/6 # * https://github.com/actions/checkout/issues/13#issuecomment-724415212 - uses: fregante/setup-git-user@v1.0.1 + uses: fregante/setup-git-user@v1.1.0 - name: Switch to the translation source branch run: | @@ -50,7 +50,7 @@ jobs: git merge '${{ github.event.repository.default_branch }}' - name: Set up Python - uses: actions/setup-python@v2 + uses: actions/setup-python@v4 with: python-version: >- 3.10 From 6cb33fe2df48e591eafd7cd99f0ab873b4918c44 Mon Sep 17 00:00:00 2001 From: Rafael Fontenelle Date: Sun, 23 Oct 2022 23:09:00 -0300 Subject: [PATCH 0286/1072] Update versions of github versions --- .github/workflows/test.yml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index 09b428e16..96b214e16 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -17,15 +17,15 @@ jobs: - linkcheck steps: - - uses: actions/checkout@v2 + - uses: actions/checkout@v3 - name: Set up Python - uses: actions/setup-python@v2 + uses: actions/setup-python@v4 with: python-version: 3.9 - name: pip cache - uses: actions/cache@v2 + uses: actions/cache@v3 with: path: ~/.cache/pip key: From bb29e9a981bb2c7bb868075cee694e6e66d8a1e1 Mon Sep 17 00:00:00 2001 From: Rafael Fontenelle Date: Sun, 23 Oct 2022 23:23:45 -0300 Subject: [PATCH 0287/1072] Use setup-python v4 pip caching feature --- .github/workflows/test.yml | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index 96b214e16..684cfc310 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -23,15 +23,8 @@ jobs: uses: actions/setup-python@v4 with: python-version: 3.9 - - - name: pip cache - uses: actions/cache@v3 - with: - path: ~/.cache/pip - key: - ${{ matrix.os }}-${{ matrix.python-version }}-${{ hashFiles('**/requirements.txt') }}-${{ hashFiles('noxfile.py') }} - restore-keys: | - ${{ matrix.os }}-${{ matrix.python-version }}- + cache: 'pip' + cache-dependency-path: 'requirements.txt' - name: Install dependencies run: | From 7c2270892172241ca851895d894a74dbda0e21bd Mon Sep 17 00:00:00 2001 From: pushfoo <36696816+pushfoo@users.noreply.github.com> Date: Tue, 25 Oct 2022 09:44:56 -0400 Subject: [PATCH 0288/1072] Fix misleading phrasing in local build guide (#1159) (#1160) --- source/contribute.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/contribute.rst b/source/contribute.rst index c5edb0792..10ea0c025 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -135,7 +135,7 @@ need: See the :doc:`Hitchhiker's Guide to Python installation instructions ` to install Python 3.8 on your operating system. -To build the guide, run the following bash command in the source folder: +To build the guide, run the following shell command in the project's root folder: .. code-block:: bash From f89a5f4162780a17e77c4c846d7e3225183e7356 Mon Sep 17 00:00:00 2001 From: Dustin Ingram Date: Thu, 1 Dec 2022 10:59:26 -0500 Subject: [PATCH 0289/1072] Update source/guides/analyzing-pypi-package-downloads.rst Co-authored-by: Sviatoslav Sydorenko --- source/guides/analyzing-pypi-package-downloads.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/source/guides/analyzing-pypi-package-downloads.rst b/source/guides/analyzing-pypi-package-downloads.rst index 2426d73df..d5c8c81d6 100644 --- a/source/guides/analyzing-pypi-package-downloads.rst +++ b/source/guides/analyzing-pypi-package-downloads.rst @@ -226,7 +226,8 @@ artifacts from PyPI based on their hashes, e.g. if a particular project or release has been deleted from PyPI. The metadata table includes the ``path`` column, which includes the hash and artifact filename. -Note that the URL generated here is not guaranteed to be stable, but currently aligns with the URL where PyPI artifacts are hosted. +.. note:: + The URL generated here is not guaranteed to be stable, but currently aligns with the URL where PyPI artifacts are hosted. :: SELECT From 292129b447b004239daae5e7b2d651b91249b494 Mon Sep 17 00:00:00 2001 From: Dustin Ingram Date: Thu, 1 Dec 2022 11:37:54 -0500 Subject: [PATCH 0290/1072] Update source/guides/analyzing-pypi-package-downloads.rst --- source/guides/analyzing-pypi-package-downloads.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/source/guides/analyzing-pypi-package-downloads.rst b/source/guides/analyzing-pypi-package-downloads.rst index d5c8c81d6..d13a14efe 100644 --- a/source/guides/analyzing-pypi-package-downloads.rst +++ b/source/guides/analyzing-pypi-package-downloads.rst @@ -228,6 +228,7 @@ column, which includes the hash and artifact filename. .. note:: The URL generated here is not guaranteed to be stable, but currently aligns with the URL where PyPI artifacts are hosted. + :: SELECT From 12b38c4c873fb71590253d5cdb4cb17c0467023c Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Sun, 4 Dec 2022 18:18:33 -0500 Subject: [PATCH 0291/1072] Fix broken links to setup.py and .cfg (#1172) --- source/guides/distributing-packages-using-setuptools.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index 057393c0b..e0fb94a67 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -59,7 +59,7 @@ setup.py The most important file is :file:`setup.py` which exists at the root of your project directory. For an example, see the `setup.py -`_ in the `PyPA +`_ in the `PyPA sample project `_. :file:`setup.py` serves two primary functions: @@ -80,7 +80,7 @@ setup.cfg :file:`setup.cfg` is an ini file that contains option defaults for :file:`setup.py` commands. For an example, see the `setup.cfg -`_ in the `PyPA +`_ in the `PyPA sample project `_. @@ -157,7 +157,7 @@ specific details of your project are defined. The most relevant arguments are explained below. Most of the snippets given are taken from the `setup.py -`_ contained in the +`_ contained in the `PyPA sample project `_. @@ -669,7 +669,7 @@ Working in "development mode" You can install a project in "editable" or "develop" mode while you're working on it. When installed as editable, a project can be -edited in-place without reinstallation: +edited in-place without reinstallation: changes to Python source files in projects installed as editable will be reflected the next time an interpreter process is started. To install a Python package in "editable"/"development" mode From 91b599b7a8bfcb8b04f686226a1ebd63b1d31461 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Sun, 4 Dec 2022 15:21:23 -0800 Subject: [PATCH 0292/1072] Add an example and list of keys to the project metadata spec (#1168) * Add an example to the project metadata spec Copied from PEP 621 and then slightly updated. * Fix indentation * Add an anchor for `Dynamic` * Add a list of acceptable keys (and start using the term "key" instead of "field") Co-authored-by: Brian Rutledge --- source/specifications/core-metadata.rst | 3 + .../declaring-project-metadata.rst | 160 +++++++++++++----- 2 files changed, 125 insertions(+), 38 deletions(-) diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst index 2e85d0909..aa0d44c8a 100644 --- a/source/specifications/core-metadata.rst +++ b/source/specifications/core-metadata.rst @@ -91,6 +91,7 @@ a single ``-`` character. This can be done using the following snippet of code re.sub(r"[-_.]+", "-", name).lower() + .. _core-metadata-version: Version @@ -106,6 +107,8 @@ Example:: Version: 1.0a2 +.. _core-metadata-dynamic: + Dynamic (multiple use) ====================== diff --git a/source/specifications/declaring-project-metadata.rst b/source/specifications/declaring-project-metadata.rst index 193f32f19..13d225d36 100644 --- a/source/specifications/declaring-project-metadata.rst +++ b/source/specifications/declaring-project-metadata.rst @@ -9,36 +9,60 @@ Declaring project metadata packaging-related tools to consume. It defines the following specification as the canonical source for the format used. + +Specification +============= + There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and cannot be specified or changed by a tool. Dynamic metadata is listed -via the ``dynamic`` field (defined later in this specification) and +via the ``dynamic`` key (defined later in this specification) and represents metadata that a tool will later provide. -The fields defined in this specification MUST be in a table named -``[project]`` in ``pyproject.toml``. No tools may add fields to this +The keys defined in this specification MUST be in a table named +``[project]`` in ``pyproject.toml``. No tools may add keys to this table which are not defined by this specification. For tools wishing to store their own settings in ``pyproject.toml``, they may use the ``[tool]`` table as defined in the :ref:`build dependency declaration specification `. The lack of a ``[project]`` table implicitly means the build back-end -will dynamically provide all fields. +will dynamically provide all keys. -The only fields required to be statically defined are: +The only keys required to be statically defined are: - ``name`` -The fields which are required but may be specified *either* statically +The keys which are required but may be specified *either* statically or listed as dynamic are: - ``version`` -All other fields are considered optional and may be specified +All other keys are considered optional and may be specified statically, listed as dynamic, or left unspecified. +The complete list of keys allowed in the ``[project]`` table are: + +- ``authors`` +- ``classifiers`` +- ``dependencies`` +- ``description`` +- ``dynamic`` +- ``entry-points`` +- ``gui-scripts`` +- ``keywords`` +- ``license`` +- ``maintainers`` +- ``name`` +- ``optional-dependencies`` +- ``readme`` +- ``requires-python`` +- ``scripts`` +- ``urls`` +- ``version`` + ``name`` -======== +-------- - TOML_ type: string - Corresponding :ref:`core metadata ` field: @@ -51,7 +75,7 @@ as it is read for internal consistency. ``version`` -=========== +----------- - TOML_ type: string - Corresponding :ref:`core metadata ` field: @@ -63,7 +87,7 @@ Users SHOULD prefer to specify already-normalized versions. ``description`` -=============== +--------------- - TOML_ type: string - Corresponding :ref:`core metadata ` field: @@ -73,7 +97,7 @@ The summary description of the project. ``readme`` -========== +---------- - TOML_ type: string or table - Corresponding :ref:`core metadata ` field: @@ -82,7 +106,7 @@ The summary description of the project. The full description of the project (i.e. the README). -The field accepts either a string or a table. If it is a string then +The key accepts either a string or a table. If it is a string then it is a path relative to ``pyproject.toml`` to a text file containing the full description. Tools MUST assume the file's encoding is UTF-8. If the file path ends in a case-insensitive ``.md`` suffix, then tools @@ -90,20 +114,20 @@ MUST assume the content-type is ``text/markdown``. If the file path ends in a case-insensitive ``.rst``, then tools MUST assume the content-type is ``text/x-rst``. If a tool recognizes more extensions than this PEP, they MAY infer the content-type for the user without -specifying this field as ``dynamic``. For all unrecognized suffixes +specifying this key as ``dynamic``. For all unrecognized suffixes when a content-type is not provided, tools MUST raise an error. -The ``readme`` field may also take a table. The ``file`` key has a +The ``readme`` key may also take a table. The ``file`` key has a string value representing a path relative to ``pyproject.toml`` to a file containing the full description. The ``text`` key has a string value which is the full description. These keys are mutually-exclusive, thus tools MUST raise an error if the metadata specifies both keys. -A table specified in the ``readme`` field also has a ``content-type`` -field which takes a string specifying the content-type of the full +A table specified in the ``readme`` key also has a ``content-type`` +key which takes a string specifying the content-type of the full description. A tool MUST raise an error if the metadata does not -specify this field in the table. If the metadata does not specify the +specify this key in the table. If the metadata does not specify the ``charset`` parameter, then it is assumed to be UTF-8. Tools MAY support other encodings if they choose to. Tools MAY support alternative content-types which they can transform to a content-type @@ -112,7 +136,7 @@ tools MUST raise an error for unsupported content-types. ``requires-python`` -=================== +------------------- - TOML_ type: string - Corresponding :ref:`core metadata ` field: @@ -122,7 +146,7 @@ The Python version requirements of the project. ``license`` -=========== +----------- - TOML_ type: table - Corresponding :ref:`core metadata ` field: @@ -137,7 +161,7 @@ tool MUST raise an error if the metadata specifies both keys. ``authors``/``maintainers`` -=========================== +--------------------------- - TOML_ type: Array of inline tables with string keys and values - Corresponding :ref:`core metadata ` field: @@ -151,10 +175,10 @@ project. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package. -The "maintainers" field is similar to "authors" in that its exact +The "maintainers" key is similar to "authors" in that its exact meaning is open to interpretation. -These fields accept an array of tables with 2 keys: ``name`` and +These keys accept an array of tables with 2 keys: ``name`` and ``email``. Both values must be strings. The ``name`` value MUST be a valid email name (i.e. whatever can be put as a name, before an email, in :rfc:`822`) and not contain commas. The ``email`` value MUST be a @@ -179,7 +203,7 @@ follows: ``keywords`` -============ +------------ - TOML_ type: array of strings - Corresponding :ref:`core metadata ` field: @@ -189,7 +213,7 @@ The keywords for the project. ``classifiers`` -=============== +--------------- - TOML_ type: array of strings - Corresponding :ref:`core metadata ` field: @@ -199,7 +223,7 @@ Trove classifiers which apply to the project. ``urls`` -======== +-------- - TOML_ type: table with keys and values of strings - Corresponding :ref:`core metadata ` field: @@ -210,7 +234,7 @@ URL itself. Entry points -============ +------------ - TOML_ type: table (``[project.scripts]``, ``[project.gui-scripts]``, and ``[project.entry-points]``) @@ -240,7 +264,7 @@ be ambiguous in the face of ``[project.scripts]`` and ``dependencies``/``optional-dependencies`` -========================================== +------------------------------------------ - TOML_ type: Array of :pep:`508` strings (``dependencies``), and a table with values of arrays of :pep:`508` strings @@ -267,41 +291,101 @@ metadata. ``dynamic`` -=========== +----------- - TOML_ type: array of string -- A corresponding :ref:`core metadata ` field does not - exist +- Corresponding :ref:`core metadata ` field: + :ref:`Dynamic ` -Specifies which fields listed by this PEP were intentionally +Specifies which keys listed by this PEP were intentionally unspecified so another tool can/will provide such metadata dynamically. This clearly delineates which metadata is purposefully unspecified and expected to stay unspecified compared to being provided via tooling later on. - A build back-end MUST honour statically-specified metadata (which - means the metadata did not list the field in ``dynamic``). + means the metadata did not list the key in ``dynamic``). - A build back-end MUST raise an error if the metadata specifies ``name`` in ``dynamic``. - If the :ref:`core metadata ` specification lists a - field as "Required", then the metadata MUST specify the field + field as "Required", then the metadata MUST specify the key statically or list it in ``dynamic`` (build back-ends MUST raise an - error otherwise, i.e. it should not be possible for a required field + error otherwise, i.e. it should not be possible for a required key to not be listed somehow in the ``[project]`` table). - If the :ref:`core metadata ` specification lists a field as "Optional", the metadata MAY list it in ``dynamic`` if the - expectation is a build back-end will provide the data for the field + expectation is a build back-end will provide the data for the key later. - Build back-ends MUST raise an error if the metadata specifies a - field statically as well as being listed in ``dynamic``. -- If the metadata does not list a field in ``dynamic``, then a build + key statically as well as being listed in ``dynamic``. +- If the metadata does not list a key in ``dynamic``, then a build back-end CANNOT fill in the requisite metadata on behalf of the user (i.e. ``dynamic`` is the only way to allow a tool to fill in metadata and the user must opt into the filling in). - Build back-ends MUST raise an error if the metadata specifies a - field in ``dynamic`` but the build back-end was unable to determine + key in ``dynamic`` but the build back-end was unable to determine the data for it (omitting the data, if determined to be the accurate value, is acceptable). +Example +======= + +.. code-block:: toml + + [project] + name = "spam" + version = "2020.0.0" + description = "Lovely Spam! Wonderful Spam!" + readme = "README.rst" + requires-python = ">=3.8" + license = {file = "LICENSE.txt"} + keywords = ["egg", "bacon", "sausage", "tomatoes", "Lobster Thermidor"] + authors = [ + {email = "pradyun@example.com"}, + {name = "Tzu-Ping Chung"} + ] + maintainers = [ + {name = "Brett Cannon", email = "brett@python.org"} + ] + classifiers = [ + "Development Status :: 4 - Beta", + "Programming Language :: Python" + ] + + dependencies = [ + "httpx", + "gidgethub[httpx]>4.0.0", + "django>2.1; os_name != 'nt'", + "django>2.0; os_name == 'nt'" + ] + + # dynamic = ["version", "description"] + + [project.optional-dependencies] + test = [ + "pytest > 5.0.0", + "pytest-cov[all]" + ] + doc = [ + "sphinx", + "furo" + ] + + [project.urls] + homepage = "https://example.com" + documentation = "https://readthedocs.org" + repository = "https://github.com/me/spam.git" + changelog = "https://github.com/me/spam/blob/master/CHANGELOG.md" + + [project.scripts] + spam-cli = "spam:main_cli" + + [project.gui-scripts] + spam-gui = "spam:main_gui" + + [project.entry-points."spam.magical"] + tomatoes = "spam:main_tomatoes" + + .. _TOML: https://toml.io From 90027de9087c18b289ba7b2d2550dc99fdd41fb7 Mon Sep 17 00:00:00 2001 From: Philipp A Date: Mon, 5 Dec 2022 00:31:11 +0100 Subject: [PATCH 0293/1072] Add PEP 621 tab for entry points docs (#1115) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Add PEP 621 tab for entry points * Maybe fix ref * maybe it can’t handle links in tab headers? * remove tabs again * Better explanation * fix link Co-authored-by: Brian Rutledge --- .../creating-and-discovering-plugins.rst | 20 ++++++++----------- 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/source/guides/creating-and-discovering-plugins.rst b/source/guides/creating-and-discovering-plugins.rst index 2928d22e2..386b09c87 100644 --- a/source/guides/creating-and-discovering-plugins.rst +++ b/source/guides/creating-and-discovering-plugins.rst @@ -120,24 +120,20 @@ a list of packages to :func:`setup`'s ``packages`` argument instead of using Using package metadata ====================== -:doc:`Setuptools ` provides :doc:`special support -` for plugins. By providing the -``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can -register themselves for discovery. +Packages can have metadata for plugins described in the :ref:`entry-points`. +By specifying them, a package announces that it contains a specific kind of plugin. +Another package supporting this kind of plugin can use the metadata to discover that plugin. For example if you have a package named ``myapp-plugin-a`` and it includes -in its :file:`setup.py`: +the following in its ``pyproject.toml``: -.. code-block:: python +.. code-block:: toml - setup( - ... - entry_points={'myapp.plugins': 'a = myapp_plugin_a'}, - ... - ) + [project.entry-points.'myapp.plugins'] + a = 'myapp_plugin_a' Then you can discover and load all of the registered entry points by using -:func:`importlib.metadata.entry_points` (or the `backport`_ +:func:`importlib.metadata.entry_points` (or the backport_ ``importlib_metadata >= 3.6`` for Python 3.6-3.9): .. code-block:: python From e89d5f2d1bbd6b8d4a7262058443ab2d3aa4f9ba Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Mon, 5 Dec 2022 09:35:39 -0500 Subject: [PATCH 0294/1072] Update source/specifications/core-metadata.rst --- source/specifications/core-metadata.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst index 4a335ec10..04213aedc 100644 --- a/source/specifications/core-metadata.rst +++ b/source/specifications/core-metadata.rst @@ -770,7 +770,7 @@ Each entry contains a string describing some other module or package required by this package. The format of a requirement string is identical to that of a module or package -name usable with the ‘import’ statement, optionally followed by a version +name usable with the ``import`` statement, optionally followed by a version declaration within parentheses. A version declaration is a series of conditional operators and version numbers, From 57af93f65f41e7ae26867e50fb4d8ca1ec38199d Mon Sep 17 00:00:00 2001 From: Mariatta Wijaya Date: Mon, 5 Dec 2022 12:26:34 -0800 Subject: [PATCH 0295/1072] Doc: remove extra backtick in Glossary There's an extra backtick that's not needed in the glossary entry for "egg" --- source/glossary.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/glossary.rst b/source/glossary.rst index 0d740bf39..7eaeef6bc 100644 --- a/source/glossary.rst +++ b/source/glossary.rst @@ -42,7 +42,7 @@ Glossary Egg A :term:`Built Distribution` format introduced by :ref:`setuptools`, - which is being replaced by :term:`Wheel`. For details, see ` + which is being replaced by :term:`Wheel`. For details, see :doc:`The Internal Structure of Python Eggs ` and `Python Eggs `_ From 88ee23e4fad76352637b9e56fdb44d54b314784d Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Mon, 5 Dec 2022 16:55:17 -0500 Subject: [PATCH 0296/1072] Run test workflow daily (#1175) --- .github/workflows/test.yml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index 684cfc310..245c71833 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -1,6 +1,10 @@ name: Test -on: [push, pull_request] +on: + push: + pull_request: + schedule: + - cron: "0 6 * * *" # daily at 6am concurrency: group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.sha }} From 0b2d1bc9adfd0f6f67292fbc2fa103c51ab494a8 Mon Sep 17 00:00:00 2001 From: Justin Chu Date: Tue, 6 Dec 2022 05:03:21 -0800 Subject: [PATCH 0297/1072] Single-sourcing the package version: Add instructions for setuptools using pyproject.toml (#1167) * Add instructions for setuptools using pyproject.toml * Copy-edit __version__ note Co-authored-by: Brian Rutledge --- .../single-sourcing-package-version.rst | 25 +++++++++++++------ 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/source/guides/single-sourcing-package-version.rst b/source/guides/single-sourcing-package-version.rst index 1f6caa70e..ec85d084d 100644 --- a/source/guides/single-sourcing-package-version.rst +++ b/source/guides/single-sourcing-package-version.rst @@ -36,21 +36,30 @@ number of your project: .. note:: As of the release of setuptools 46.4.0, one can accomplish the same - thing by instead placing the following in the project's ``setup.cfg`` - file (replacing "package" with the import name of the package): + thing by instead placing the following in the project's + :file:`setup.cfg` file (replacing "package" with the import name of the + package): .. code-block:: ini [metadata] version = attr: package.__version__ - Earlier versions of setuptools implemented the ``attr:`` directive by - importing the module, but setuptools 46.4.0 added rudimentary AST - analysis so that ``attr:`` can function without having to import any of - the package's dependencies. + As of the release of setuptools 61.0.0, one can specify the + version dynamically in the project's :file:`pyproject.toml` file. - Also, please be aware that declarative config indicators, including the - ``attr:`` directive, are not supported in parameters to ``setup.py``. + .. code-block:: toml + + [project] + name = "package" + dynamic = ["version"] + + [tool.setuptools.dynamic] + version = {attr = "package.__version__"} + + Please be aware that declarative config indicators, including the + ``attr:`` directive, are not supported in parameters to + :file:`setup.py`. #. Use an external build tool that either manages updating both locations, or offers an API that both locations can use. From bb7b1185cb82420168c430d652fce4d15a713216 Mon Sep 17 00:00:00 2001 From: konstin Date: Wed, 7 Dec 2022 23:04:30 +0100 Subject: [PATCH 0298/1072] Add specification for dependency specifiers (#1177) Co-authored-by: Brett Cannon --- .../specifications/dependency-specifiers.rst | 487 +++++++++++++++++- 1 file changed, 482 insertions(+), 5 deletions(-) diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst index ab33de726..a5bc52bc7 100644 --- a/source/specifications/dependency-specifiers.rst +++ b/source/specifications/dependency-specifiers.rst @@ -1,14 +1,491 @@ - .. _dependency-specifiers: ===================== Dependency specifiers ===================== -The dependency specifier format used to declare a dependency on another -component is defined in :pep:`508`. +This document describes the dependency specifiers format as originally specified +in :pep:`508`. -The environment markers section in this PEP supersedes the environment markers -section in :pep:`345`. +The job of a dependency is to enable tools like pip [#pip]_ to find the right +package to install. Sometimes this is very loose - just specifying a name, and +sometimes very specific - referring to a specific file to install. Sometimes +dependencies are only relevant in one platform, or only some versions are +acceptable, so the language permits describing all these cases. + +The language defined is a compact line based format which is already in +widespread use in pip requirements files, though we do not specify the command +line option handling that those files permit. There is one caveat - the +URL reference form, specified in :pep:`440` is not actually +implemented in pip, but since :pep:`440` is accepted, we use that format rather +than pip's current native format. + +Specification +============= + +Examples +-------- + +All features of the language shown with a name based lookup:: + + requests [security,tests] >= 2.8.1, == 2.8.* ; python_version < "2.7" + +A minimal URL based lookup:: + + pip @ https://github.com/pypa/pip/archive/1.3.1.zip#sha1=da9234ee9982d4bbb3c72346a6de940a148ea686 + +Concepts +-------- + +A dependency specification always specifies a distribution name. It may +include extras, which expand the dependencies of the named distribution to +enable optional features. The version installed can be controlled using +version limits, or giving the URL to a specific artifact to install. Finally +the dependency can be made conditional using environment markers. + +Grammar +------- + +We first cover the grammar briefly and then drill into the semantics of each +section later. + +A distribution specification is written in ASCII text. We use a parsley +[#parsley]_ grammar to provide a precise grammar. It is expected that the +specification will be embedded into a larger system which offers framing such +as comments, multiple line support via continuations, or other such features. + +The full grammar including annotations to build a useful parse tree is +included at the end of this document. + +Versions may be specified according to the :pep:`440` rules. (Note: +URI is defined in :rfc:`std-66 <3986>`):: + + version_cmp = wsp* '<' | '<=' | '!=' | '==' | '>=' | '>' | '~=' | '===' + version = wsp* ( letterOrDigit | '-' | '_' | '.' | '*' | '+' | '!' )+ + version_one = version_cmp version wsp* + version_many = version_one (wsp* ',' version_one)* + versionspec = ( '(' version_many ')' ) | version_many + urlspec = '@' wsp* + +Environment markers allow making a specification only take effect in some +environments:: + + marker_op = version_cmp | (wsp* 'in') | (wsp* 'not' wsp+ 'in') + python_str_c = (wsp | letter | digit | '(' | ')' | '.' | '{' | '}' | + '-' | '_' | '*' | '#' | ':' | ';' | ',' | '/' | '?' | + '[' | ']' | '!' | '~' | '`' | '@' | '$' | '%' | '^' | + '&' | '=' | '+' | '|' | '<' | '>' ) + dquote = '"' + squote = '\\'' + python_str = (squote (python_str_c | dquote)* squote | + dquote (python_str_c | squote)* dquote) + env_var = ('python_version' | 'python_full_version' | + 'os_name' | 'sys_platform' | 'platform_release' | + 'platform_system' | 'platform_version' | + 'platform_machine' | 'platform_python_implementation' | + 'implementation_name' | 'implementation_version' | + 'extra' # ONLY when defined by a containing layer + ) + marker_var = wsp* (env_var | python_str) + marker_expr = marker_var marker_op marker_var + | wsp* '(' marker wsp* ')' + marker_and = marker_expr wsp* 'and' marker_expr + | marker_expr + marker_or = marker_and wsp* 'or' marker_and + | marker_and + marker = marker_or + quoted_marker = ';' wsp* marker + +Optional components of a distribution may be specified using the extras +field:: + + identifier_end = letterOrDigit | (('-' | '_' | '.' )* letterOrDigit) + identifier = letterOrDigit identifier_end* + name = identifier + extras_list = identifier (wsp* ',' wsp* identifier)* + extras = '[' wsp* extras_list? wsp* ']' Restrictions on names for extras is defined in :pep:`685`. + +Giving us a rule for name based requirements:: + + name_req = name wsp* extras? wsp* versionspec? wsp* quoted_marker? + +And a rule for direct reference specifications:: + + url_req = name wsp* extras? wsp* urlspec wsp+ quoted_marker? + +Leading to the unified rule that can specify a dependency.:: + + specification = wsp* ( url_req | name_req ) wsp* + +Whitespace +---------- + +Non line-breaking whitespace is mostly optional with no semantic meaning. The +sole exception is detecting the end of a URL requirement. + +Names +----- + +Python distribution names are currently defined in :pep:`345`. Names +act as the primary identifier for distributions. They are present in all +dependency specifications, and are sufficient to be a specification on their +own. However, PyPI places strict restrictions on names - they must match a +case insensitive regex or they won't be accepted. Accordingly, in this +document we limit the acceptable values for identifiers to that regex. A full +redefinition of name may take place in a future metadata PEP. The regex (run +with re.IGNORECASE) is:: + + ^([A-Z0-9]|[A-Z0-9][A-Z0-9._-]*[A-Z0-9])$ + +Extras +------ + +An extra is an optional part of a distribution. Distributions can specify as +many extras as they wish, and each extra results in the declaration of +additional dependencies of the distribution **when** the extra is used in a +dependency specification. For instance:: + + requests[security] + +Extras union in the dependencies they define with the dependencies of the +distribution they are attached to. The example above would result in requests +being installed, and requests own dependencies, and also any dependencies that +are listed in the "security" extra of requests. + +If multiple extras are listed, all the dependencies are unioned together. + +Versions +-------- + +See :pep:`440` for more detail on both version numbers and version +comparisons. Version specifications limit the versions of a distribution that +can be used. They only apply to distributions looked up by name, rather than +via a URL. Version comparison are also used in the markers feature. The +optional brackets around a version are present for compatibility with :pep:`345` +but should not be generated, only accepted. + +Environment Markers +------------------- + +Environment markers allow a dependency specification to provide a rule that +describes when the dependency should be used. For instance, consider a package +that needs argparse. In Python 2.7 argparse is always present. On older Python +versions it has to be installed as a dependency. This can be expressed as so:: + + argparse;python_version<"2.7" + +A marker expression evaluates to either True or False. When it evaluates to +False, the dependency specification should be ignored. + +The marker language is inspired by Python itself, chosen for the ability to +safely evaluate it without running arbitrary code that could become a security +vulnerability. Markers were first standardised in :pep:`345`. This document +fixes some issues that were observed in the design described in :pep:`426`. + +Comparisons in marker expressions are typed by the comparison operator. The + operators that are not in perform the same as they +do for strings in Python. The operators use the :pep:`440` +version comparison rules when those are defined (that is when both +sides have a valid version specifier). If there is no defined :pep:`440` +behaviour and the operator exists in Python, then the operator falls back to +the Python behaviour. Otherwise an error should be raised. e.g. the following +will result in errors:: + + "dog" ~= "fred" + python_version ~= "surprise" + +User supplied constants are always encoded as strings with either ``'`` or +``"`` quote marks. Note that backslash escapes are not defined, but existing +implementations do support them. They are not included in this +specification because they add complexity and there is no observable need for +them today. Similarly we do not define non-ASCII character support: all the +runtime variables we are referencing are expected to be ASCII-only. + +The variables in the marker grammar such as "os_name" resolve to values looked +up in the Python runtime. With the exception of "extra" all values are defined +on all Python versions today - it is an error in the implementation of markers +if a value is not defined. + +Unknown variables must raise an error rather than resulting in a comparison +that evaluates to True or False. + +Variables whose value cannot be calculated on a given Python implementation +should evaluate to ``0`` for versions, and an empty string for all other +variables. + +The "extra" variable is special. It is used by wheels to signal which +specifications apply to a given extra in the wheel ``METADATA`` file, but +since the ``METADATA`` file is based on a draft version of :pep:`426`, there is +no current specification for this. Regardless, outside of a context where this +special handling is taking place, the "extra" variable should result in an +error like all other unknown variables. + +.. list-table:: + :header-rows: 1 + + * - Marker + - Python equivalent + - Sample values + * - ``os_name`` + - ``os.name`` + - ``posix``, ``java`` + * - ``sys_platform`` + - ``sys.platform`` + - ``linux``, ``linux2``, ``darwin``, ``java1.8.0_51`` (note that "linux" + is from Python3 and "linux2" from Python2) + * - ``platform_machine`` + - ``platform.machine()`` + - ``x86_64`` + * - ``platform_python_implementation`` + - ``platform.python_implementation()`` + - ``CPython``, ``Jython`` + * - ``platform_release`` + - ``platform.release()`` + - ``3.14.1-x86_64-linode39``, ``14.5.0``, ``1.8.0_51`` + * - ``platform_system`` + - ``platform.system()`` + - ``Linux``, ``Windows``, ``Java`` + * - ``platform_version`` + - ``platform.version()`` + - ``#1 SMP Fri Apr 25 13:07:35 EDT 2014`` + ``Java HotSpot(TM) 64-Bit Server VM, 25.51-b03, Oracle Corporation`` + ``Darwin Kernel Version 14.5.0: Wed Jul 29 02:18:53 PDT 2015; root:xnu-2782.40.9~2/RELEASE_X86_64`` + * - ``python_version`` + - ``'.'.join(platform.python_version_tuple()[:2])`` + - ``3.4``, ``2.7`` + * - ``python_full_version`` + - ``platform.python_version()`` + - ``3.4.0``, ``3.5.0b1`` + * - ``implementation_name`` + - ``sys.implementation.name`` + - ``cpython`` + * - ``implementation_version`` + - see definition below + - ``3.4.0``, ``3.5.0b1`` + * - ``extra`` + - An error except when defined by the context interpreting the + specification. + - ``test`` + +The ``implementation_version`` marker variable is derived from +``sys.implementation.version``:: + + def format_full_version(info): + version = '{0.major}.{0.minor}.{0.micro}'.format(info) + kind = info.releaselevel + if kind != 'final': + version += kind[0] + str(info.serial) + return version + + if hasattr(sys, 'implementation'): + implementation_version = format_full_version(sys.implementation.version) + else: + implementation_version = "0" + +This environment markers section, initially defined through :pep:`508`, supersedes the environment markers +section in :pep:`345`. + +Complete Grammar +================ + +The complete parsley grammar:: + + wsp = ' ' | '\t' + version_cmp = wsp* <'<=' | '<' | '!=' | '==' | '>=' | '>' | '~=' | '==='> + version = wsp* <( letterOrDigit | '-' | '_' | '.' | '*' | '+' | '!' )+> + version_one = version_cmp:op version:v wsp* -> (op, v) + version_many = version_one:v1 (wsp* ',' version_one)*:v2 -> [v1] + v2 + versionspec = ('(' version_many:v ')' ->v) | version_many + urlspec = '@' wsp* + marker_op = version_cmp | (wsp* 'in') | (wsp* 'not' wsp+ 'in') + python_str_c = (wsp | letter | digit | '(' | ')' | '.' | '{' | '}' | + '-' | '_' | '*' | '#' | ':' | ';' | ',' | '/' | '?' | + '[' | ']' | '!' | '~' | '`' | '@' | '$' | '%' | '^' | + '&' | '=' | '+' | '|' | '<' | '>' ) + dquote = '"' + squote = '\\'' + python_str = (squote <(python_str_c | dquote)*>:s squote | + dquote <(python_str_c | squote)*>:s dquote) -> s + env_var = ('python_version' | 'python_full_version' | + 'os_name' | 'sys_platform' | 'platform_release' | + 'platform_system' | 'platform_version' | + 'platform_machine' | 'platform_python_implementation' | + 'implementation_name' | 'implementation_version' | + 'extra' # ONLY when defined by a containing layer + ):varname -> lookup(varname) + marker_var = wsp* (env_var | python_str) + marker_expr = marker_var:l marker_op:o marker_var:r -> (o, l, r) + | wsp* '(' marker:m wsp* ')' -> m + marker_and = marker_expr:l wsp* 'and' marker_expr:r -> ('and', l, r) + | marker_expr:m -> m + marker_or = marker_and:l wsp* 'or' marker_and:r -> ('or', l, r) + | marker_and:m -> m + marker = marker_or + quoted_marker = ';' wsp* marker + identifier_end = letterOrDigit | (('-' | '_' | '.' )* letterOrDigit) + identifier = < letterOrDigit identifier_end* > + name = identifier + extras_list = identifier:i (wsp* ',' wsp* identifier)*:ids -> [i] + ids + extras = '[' wsp* extras_list?:e wsp* ']' -> e + name_req = (name:n wsp* extras?:e wsp* versionspec?:v wsp* quoted_marker?:m + -> (n, e or [], v or [], m)) + url_req = (name:n wsp* extras?:e wsp* urlspec:v (wsp+ | end) quoted_marker?:m + -> (n, e or [], v, m)) + specification = wsp* ( url_req | name_req ):s wsp* -> s + # The result is a tuple - name, list-of-extras, + # list-of-version-constraints-or-a-url, marker-ast or None + + + URI_reference = + URI = scheme ':' hier_part ('?' query )? ( '#' fragment)? + hier_part = ('//' authority path_abempty) | path_absolute | path_rootless | path_empty + absolute_URI = scheme ':' hier_part ( '?' query )? + relative_ref = relative_part ( '?' query )? ( '#' fragment )? + relative_part = '//' authority path_abempty | path_absolute | path_noscheme | path_empty + scheme = letter ( letter | digit | '+' | '-' | '.')* + authority = ( userinfo '@' )? host ( ':' port )? + userinfo = ( unreserved | pct_encoded | sub_delims | ':')* + host = IP_literal | IPv4address | reg_name + port = digit* + IP_literal = '[' ( IPv6address | IPvFuture) ']' + IPvFuture = 'v' hexdig+ '.' ( unreserved | sub_delims | ':')+ + IPv6address = ( + ( h16 ':'){6} ls32 + | '::' ( h16 ':'){5} ls32 + | ( h16 )? '::' ( h16 ':'){4} ls32 + | ( ( h16 ':')? h16 )? '::' ( h16 ':'){3} ls32 + | ( ( h16 ':'){0,2} h16 )? '::' ( h16 ':'){2} ls32 + | ( ( h16 ':'){0,3} h16 )? '::' h16 ':' ls32 + | ( ( h16 ':'){0,4} h16 )? '::' ls32 + | ( ( h16 ':'){0,5} h16 )? '::' h16 + | ( ( h16 ':'){0,6} h16 )? '::' ) + h16 = hexdig{1,4} + ls32 = ( h16 ':' h16) | IPv4address + IPv4address = dec_octet '.' dec_octet '.' dec_octet '.' dec_octet + nz = ~'0' digit + dec_octet = ( + digit # 0-9 + | nz digit # 10-99 + | '1' digit{2} # 100-199 + | '2' ('0' | '1' | '2' | '3' | '4') digit # 200-249 + | '25' ('0' | '1' | '2' | '3' | '4' | '5') )# %250-255 + reg_name = ( unreserved | pct_encoded | sub_delims)* + path = ( + path_abempty # begins with '/' or is empty + | path_absolute # begins with '/' but not '//' + | path_noscheme # begins with a non-colon segment + | path_rootless # begins with a segment + | path_empty ) # zero characters + path_abempty = ( '/' segment)* + path_absolute = '/' ( segment_nz ( '/' segment)* )? + path_noscheme = segment_nz_nc ( '/' segment)* + path_rootless = segment_nz ( '/' segment)* + path_empty = pchar{0} + segment = pchar* + segment_nz = pchar+ + segment_nz_nc = ( unreserved | pct_encoded | sub_delims | '@')+ + # non-zero-length segment without any colon ':' + pchar = unreserved | pct_encoded | sub_delims | ':' | '@' + query = ( pchar | '/' | '?')* + fragment = ( pchar | '/' | '?')* + pct_encoded = '%' hexdig + unreserved = letter | digit | '-' | '.' | '_' | '~' + reserved = gen_delims | sub_delims + gen_delims = ':' | '/' | '?' | '#' | '(' | ')?' | '@' + sub_delims = '!' | '$' | '&' | '\\'' | '(' | ')' | '*' | '+' | ',' | ';' | '=' + hexdig = digit | 'a' | 'A' | 'b' | 'B' | 'c' | 'C' | 'd' | 'D' | 'e' | 'E' | 'f' | 'F' + +A test program - if the grammar is in a string ``grammar``:: + + import os + import sys + import platform + + from parsley import makeGrammar + + grammar = """ + wsp ... + """ + tests = [ + "A", + "A.B-C_D", + "aa", + "name", + "name<=1", + "name>=3", + "name>=3,<2", + "name@http://foo.com", + "name [fred,bar] @ http://foo.com ; python_version=='2.7'", + "name[quux, strange];python_version<'2.7' and platform_version=='2'", + "name; os_name=='a' or os_name=='b'", + # Should parse as (a and b) or c + "name; os_name=='a' and os_name=='b' or os_name=='c'", + # Overriding precedence -> a and (b or c) + "name; os_name=='a' and (os_name=='b' or os_name=='c')", + # should parse as a or (b and c) + "name; os_name=='a' or os_name=='b' and os_name=='c'", + # Overriding precedence -> (a or b) and c + "name; (os_name=='a' or os_name=='b') and os_name=='c'", + ] + + def format_full_version(info): + version = '{0.major}.{0.minor}.{0.micro}'.format(info) + kind = info.releaselevel + if kind != 'final': + version += kind[0] + str(info.serial) + return version + + if hasattr(sys, 'implementation'): + implementation_version = format_full_version(sys.implementation.version) + implementation_name = sys.implementation.name + else: + implementation_version = '0' + implementation_name = '' + bindings = { + 'implementation_name': implementation_name, + 'implementation_version': implementation_version, + 'os_name': os.name, + 'platform_machine': platform.machine(), + 'platform_python_implementation': platform.python_implementation(), + 'platform_release': platform.release(), + 'platform_system': platform.system(), + 'platform_version': platform.version(), + 'python_full_version': platform.python_version(), + 'python_version': '.'.join(platform.python_version_tuple()[:2]), + 'sys_platform': sys.platform, + } + + compiled = makeGrammar(grammar, {'lookup': bindings.__getitem__}) + for test in tests: + parsed = compiled(test).specification() + print("%s -> %s" % (test, parsed)) + + +Summary of changes to PEP 508 +============================= + +The following changes were made based on feedback after its initial +implementation: + +- The definition of ``python_version`` was changed from + ``platform.python_version()[:3]`` to + ``'.'.join(platform.python_version_tuple()[:2])``, to accommodate potential + future versions of Python with 2-digit major and minor versions + (e.g. 3.10). [#future_versions]_ + + +References +========== + +.. [#pip] pip, the recommended installer for Python packages + (http://pip.readthedocs.org/en/stable/) + +.. [#parsley] The parsley PEG library. + (https://pypi.python.org/pypi/parsley/) + +.. [#future_versions] Future Python versions might be problematic with the + definition of Environment Marker Variable ``python_version`` + (https://github.com/python/peps/issues/560) + From 3ab0328dbd8208c4dae3aad9a5182ef6052a0b3a Mon Sep 17 00:00:00 2001 From: konstin Date: Mon, 12 Dec 2022 00:13:22 +0100 Subject: [PATCH 0299/1072] Dependency Specifiers: Don't require whitespace after URL otherwise would `numpy @ https://example.org/numpy` is not a valid specifier (missing whitespace after the URL). This already what pip and packaging do and also what the parsley grammar says --- source/specifications/dependency-specifiers.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst index a5bc52bc7..5453e367c 100644 --- a/source/specifications/dependency-specifiers.rst +++ b/source/specifications/dependency-specifiers.rst @@ -113,7 +113,7 @@ Giving us a rule for name based requirements:: And a rule for direct reference specifications:: - url_req = name wsp* extras? wsp* urlspec wsp+ quoted_marker? + url_req = name wsp* extras? wsp* urlspec (wsp+ quoted_marker?)? Leading to the unified rule that can specify a dependency.:: From 4193e048f5bac6b5e996000e329cddc069a0a40a Mon Sep 17 00:00:00 2001 From: konstin Date: Mon, 12 Dec 2022 00:17:35 +0100 Subject: [PATCH 0300/1072] Dependency Specifiers: Require whitespace before `in` and `not in` Otherwise `numpy; os_namein 'posix'` would be a valid specifier which it isn't --- source/specifications/dependency-specifiers.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst index 5453e367c..9b29669d9 100644 --- a/source/specifications/dependency-specifiers.rst +++ b/source/specifications/dependency-specifiers.rst @@ -70,7 +70,7 @@ URI is defined in :rfc:`std-66 <3986>`):: Environment markers allow making a specification only take effect in some environments:: - marker_op = version_cmp | (wsp* 'in') | (wsp* 'not' wsp+ 'in') + marker_op = version_cmp | (wsp+ 'in') | (wsp+ 'not' wsp+ 'in') python_str_c = (wsp | letter | digit | '(' | ')' | '.' | '{' | '}' | '-' | '_' | '*' | '#' | ':' | ';' | ',' | '/' | '?' | '[' | ']' | '!' | '~' | '`' | '@' | '$' | '%' | '^' | From f91e32f29244fb8a9d313a9701b81036de25842e Mon Sep 17 00:00:00 2001 From: konstin Date: Mon, 12 Dec 2022 00:19:24 +0100 Subject: [PATCH 0301/1072] Dependency Specifiers: Require whitespace after `in` and `not in` Otherwise `numpy; os_name in'posix'` and `numpy; os_name inos_name` would be valid. pypa/packaging 22.0 actually allows currently `numpy; os_name in'posix'` --- source/specifications/dependency-specifiers.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst index 9b29669d9..8fc445013 100644 --- a/source/specifications/dependency-specifiers.rst +++ b/source/specifications/dependency-specifiers.rst @@ -70,7 +70,7 @@ URI is defined in :rfc:`std-66 <3986>`):: Environment markers allow making a specification only take effect in some environments:: - marker_op = version_cmp | (wsp+ 'in') | (wsp+ 'not' wsp+ 'in') + marker_op = version_cmp | (wsp+ 'in' wsp+) | (wsp+ 'not' wsp+ 'in' wsp+) python_str_c = (wsp | letter | digit | '(' | ')' | '.' | '{' | '}' | '-' | '_' | '*' | '#' | ':' | ';' | ',' | '/' | '?' | '[' | ']' | '!' | '~' | '`' | '@' | '$' | '%' | '^' | From 7ebb12fa35b86aef643c62b4f679d2c499083a1b Mon Sep 17 00:00:00 2001 From: Pradyun Gedam Date: Fri, 23 Dec 2022 22:54:38 +0000 Subject: [PATCH 0302/1072] Partially flesh out the "Implementing binary extensions" section This makes the bullet points into proper headings and fleshes out the section on the stable ABI. --- source/guides/packaging-binary-extensions.rst | 57 +++++++++++++++---- 1 file changed, 47 insertions(+), 10 deletions(-) diff --git a/source/guides/packaging-binary-extensions.rst b/source/guides/packaging-binary-extensions.rst index f27eb4730..e7bf37c03 100644 --- a/source/guides/packaging-binary-extensions.rst +++ b/source/guides/packaging-binary-extensions.rst @@ -169,7 +169,7 @@ wrapper modules up to date. for automatic wrapping with Cython. It also supports performance-oriented Python implementations that provide a CPython-like C-API, such as PyPy and Pyston. - + * :doc:`pybind11 ` is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in @@ -230,18 +230,55 @@ The CPython :doc:`Extending and Embedding ` guide includes an introduction to writing a :doc:`custom extension module in C `. -.. +FIXME: Elaborate that all this is one of the reasons why you probably +*don't* want to handcode your extension modules :) - FIXME - * mention the stable ABI (3.2+, link to the CPython C API docs) - * mention the module lifecycle - * mention the challenges of shared static state and subinterpreters - * mention the implications of the GIL for extension modules - * mention the memory allocation APIs in 3.4+ +Extension module lifecycle +-------------------------- + +FIXME: This section needs to be fleshed out. + + +Implications of shared static state and subinterpreters +------------------------------------------------------- + +FIXME: This section needs to be fleshed out. + + +Implications of the GIL +----------------------- + +FIXME: This section needs to be fleshed out. + + +Memory allocation APIs +---------------------- + +FIXME: This section needs to be fleshed out. + + +.. _cpython-stable-abi: + +ABI Compatibility +----------------- + +The CPython C API does not guarantee ABI stability between minor releases +(3.2, 3.3, 3.4, etc.). This means that, typically, if you build an +extension module against one version of Python, it is only guaranteed to +work with the same minor version of Python and not with any other minor +versions. + +Python 3.2 introduced the Limited API, with is a well-defined subset of +Python's C API. The symbols needed for the Limited API form the +"Stable ABI" which is guaranteed to be compatible across all Python 3.x +versions. Wheels containing extensions built against the stable ABI use +the ``abi3`` ABI tag, to reflect that they're compatible with all Python +3.x versions. - * mention again that all this is one of the reasons why you probably *don't* - want to handcode your extension modules :) +CPython's :doc:`C API stability` page provides +detailed information about the API / ABI stability guarantees, how to use +the Limited API and the exact contents of the "Limited API". Building binary extensions From b18fd614fb5ad43bc4468396bf2d98410ea2d11a Mon Sep 17 00:00:00 2001 From: Pradyun Gedam Date: Fri, 23 Dec 2022 23:01:15 +0000 Subject: [PATCH 0303/1072] Clarify how building extensions for multiple platforms scales This also mentions the use-case for the stable ABI for reducing the wheel compatibility matrix sizes. --- source/guides/packaging-binary-extensions.rst | 23 +++++++++++++------ 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/source/guides/packaging-binary-extensions.rst b/source/guides/packaging-binary-extensions.rst index e7bf37c03..6a4ba6c52 100644 --- a/source/guides/packaging-binary-extensions.rst +++ b/source/guides/packaging-binary-extensions.rst @@ -288,13 +288,22 @@ Building extensions for multiple platforms ------------------------------------------ If you plan to distribute your extension, you should provide -:term:`wheels ` for all the platforms you intend to support. For most -extensions, this is at least one package per Python version times the number of -OS and architectures you support. These are usually built on continuous -integration (CI) systems. There are tools to help you build highly -redistributable binaries from CI; these include :ref:`cibuildwheel` and -:ref:`multibuild`. - +:term:`wheels ` for all the platforms you intend to support. These +are usually built on continuous integration (CI) systems. There are tools +to help you build highly redistributable binaries from CI; these include +:ref:`cibuildwheel` and :ref:`multibuild`. + +For most extensions, you will need to build wheels for all the platforms +you intend to support. This means that the number of wheels you need to +build is the product of:: + + count(Python minor versions) * count(OS) * count(architectures) + +Using CPython's :ref:`Stable ABI ` can help significantly +reduce the number of wheels you need to provide, since a single wheel on a +platform can be used with all Python minor versions; eliminating one dimension +of the matrix. It also removes the need to generate new wheels for each new +minor version of Python. Binary extensions for Windows ----------------------------- From 04bf1bbe261b3a5323280ca637229cfe0b3d57b5 Mon Sep 17 00:00:00 2001 From: Pradyun Gedam Date: Fri, 23 Dec 2022 23:03:40 +0000 Subject: [PATCH 0304/1072] Partially flesh out "Publishing binary extensions" section This converts the items from the existing FIXME that are still relevant while fleshing out the topic of binary-only releases. --- source/guides/packaging-binary-extensions.rst | 24 +++++++++++-------- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/source/guides/packaging-binary-extensions.rst b/source/guides/packaging-binary-extensions.rst index 6a4ba6c52..eebbb10d6 100644 --- a/source/guides/packaging-binary-extensions.rst +++ b/source/guides/packaging-binary-extensions.rst @@ -356,20 +356,24 @@ Spinning Wheels wiki Publishing binary extensions ============================ -For interim guidance on this topic, see the discussion in -:issue:`this issue <284>`. +Publishing binary extensions through PyPI uses the same upload mechanisms as +publishing pure Python packages. You build a wheel file for your extension +using the build-backend and upload it to PyPI using +`twine `_. -.. +Avoid binary-only releases +-------------------------- - FIXME +It is strongly recommended that you publish your binary extensions as +well as the source code that was used to build them. This allows users to +build the extension from source if they need to. Notably, this is required +for certain Linux distributions that build from source within their +own build systems for the distro package repositories. - * cover publishing as wheel files on PyPI or a custom index server - * cover creation of Windows and macOS installers - * cover weak linking - * mention the fact that Linux distros have a requirement to build from - source in their own build systems, so binary-only releases are strongly - discouraged +Weak linking +------------ +FIXME: This section needs to be fleshed out. Additional resources ==================== From 42ba363fc32c34ccb053b18582e9cbfa9d66632b Mon Sep 17 00:00:00 2001 From: Pradyun Gedam Date: Fri, 23 Dec 2022 23:04:03 +0000 Subject: [PATCH 0305/1072] Add a FIXME for covering build-backends for extension building --- source/guides/packaging-binary-extensions.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/source/guides/packaging-binary-extensions.rst b/source/guides/packaging-binary-extensions.rst index eebbb10d6..0c6187c29 100644 --- a/source/guides/packaging-binary-extensions.rst +++ b/source/guides/packaging-binary-extensions.rst @@ -284,6 +284,8 @@ the Limited API and the exact contents of the "Limited API". Building binary extensions ========================== +FIXME: Cover the build-backends available for building extensions. + Building extensions for multiple platforms ------------------------------------------ From 91fefaa70e2ad1db8c5623dbe7c43ee2f888119c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Filipe=20La=C3=ADns?= Date: Mon, 26 Dec 2022 22:48:25 +0000 Subject: [PATCH 0306/1072] key_projects: add meson-python MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Filipe Laíns --- source/key_projects.rst | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/source/key_projects.rst b/source/key_projects.rst index ab4eb398d..4ffdd6688 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -452,6 +452,21 @@ problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016. +.. _meson-python: + +meson-python +============ + +`Docs `__ | +`GitHub `__ + +``meson-python`` is a build backend that uses the Meson_ build system. It enables +Python package authors to use Meson_ as the build system for their package. It +supports a wide variety of languages, including C, and is able to fill the needs +of most complex build configurations. + +.. _Meson: https://github.com/mesonbuild/meson + .. _multibuild: multibuild From 33bc2a8685b137079b5cb7df8d37ad7c17154428 Mon Sep 17 00:00:00 2001 From: Pradyun Gedam Date: Sat, 31 Dec 2022 12:50:50 +0000 Subject: [PATCH 0307/1072] Add a dedicated specification page for name normalization --- .../declaring-project-metadata.rst | 2 +- source/specifications/index.rst | 1 + source/specifications/name-normalization.rst | 39 +++++++++++++++++++ 3 files changed, 41 insertions(+), 1 deletion(-) create mode 100644 source/specifications/name-normalization.rst diff --git a/source/specifications/declaring-project-metadata.rst b/source/specifications/declaring-project-metadata.rst index 13d225d36..fd890b976 100644 --- a/source/specifications/declaring-project-metadata.rst +++ b/source/specifications/declaring-project-metadata.rst @@ -70,7 +70,7 @@ The complete list of keys allowed in the ``[project]`` table are: The name of the project. -Tools SHOULD normalize this name, as specified by :pep:`503`, as soon +Tools SHOULD :ref:`normalize ` this name, as soon as it is read for internal consistency. diff --git a/source/specifications/index.rst b/source/specifications/index.rst index 6a282b243..3265ce56f 100644 --- a/source/specifications/index.rst +++ b/source/specifications/index.rst @@ -15,6 +15,7 @@ Package Distribution Metadata .. toctree:: :maxdepth: 1 + name-normalization core-metadata version-specifiers dependency-specifiers diff --git a/source/specifications/name-normalization.rst b/source/specifications/name-normalization.rst new file mode 100644 index 000000000..4fd885afc --- /dev/null +++ b/source/specifications/name-normalization.rst @@ -0,0 +1,39 @@ +.. _name-normalization: + +========================== +Package name normalization +========================== + +Project names are "normalized" for use in various contexts. This document describes how project names should be normalized. + +Valid non-normalized names +-------------------------- + +A valid name consists only of ASCII letters and numbers, period, +underscore and hyphen. It must start and end with a letter or number. +This means that valid project names are limited to those which match the +following regex (run with ``re.IGNORECASE``):: + + ^([A-Z0-9]|[A-Z0-9][A-Z0-9._-]*[A-Z0-9])$ + +Normalization +------------- + +The name should be lowercased with all runs of the characters ``.``, ``-``, or ``_`` replaced with a single ``-`` character. This can be implemented in Python with the re module: + +.. code-block:: python + + import re + + def normalize(name): + return re.sub(r"[-_.]+", "-", name).lower() + +This means that the following names are all equivalent: + +* ``friendly-bard`` (normalized form) +* ``Friendly-Bard`` +* ``FRIENDLY-BARD`` +* ``friendly.bard`` +* ``friendly_bard`` +* ``friendly--bard`` +* ``FrIeNdLy-._.-bArD`` (a _terrible_ way to write a name, but it is valid) From cf8dea06ec08279139e04d9608ed52a294c63834 Mon Sep 17 00:00:00 2001 From: Pradyun Gedam Date: Sat, 31 Dec 2022 12:55:57 +0000 Subject: [PATCH 0308/1072] Add cross-references to newly-added name normalization page --- source/guides/hosting-your-own-index.rst | 3 +-- source/specifications/binary-distribution-format.rst | 2 +- source/specifications/core-metadata.rst | 8 +------- source/specifications/recording-installed-packages.rst | 2 +- 4 files changed, 4 insertions(+), 11 deletions(-) diff --git a/source/guides/hosting-your-own-index.rst b/source/guides/hosting-your-own-index.rst index a4ff2b35c..f9d2d74c4 100644 --- a/source/guides/hosting-your-own-index.rst +++ b/source/guides/hosting-your-own-index.rst @@ -35,8 +35,7 @@ all repositories using a valid HTTPS setup. =================== The directory layout is fairly simple, within a root directory you need to -create a directory for each project. This directory should be the normalized -name (as defined by :pep:`503`) of the project. Within each of these directories +create a directory for each project. This directory should be the :ref:`normalized name ` of the project. Within each of these directories simply place each of the downloadable files. If you have the projects "Foo" (with the versions 1.0 and 2.0) and "bar" (with the version 0.1) You should end up with a structure that looks like:: diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst index 1f4bd89fa..277792658 100644 --- a/source/specifications/binary-distribution-format.rst +++ b/source/specifications/binary-distribution-format.rst @@ -161,7 +161,7 @@ this character cannot appear within any component. This is handled as follows: - In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with ``_`` (LOW LINE), and uppercase characters should be replaced with corresponding lowercase ones. This is - equivalent to :pep:`503` normalisation followed by replacing ``-`` with ``_``. + equivalent to regular :ref:`name normalization ` followed by replacing ``-`` with ``_``. Tools consuming wheels must be prepared to accept ``.`` (FULL STOP) and uppercase letters, however, as these were allowed by an earlier version of this specification. diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst index aa0d44c8a..644380962 100644 --- a/source/specifications/core-metadata.rst +++ b/source/specifications/core-metadata.rst @@ -84,13 +84,7 @@ Example:: Name: BeagleVote -To normalize a distribution name for comparison purposes, it should be -lowercased with all runs of the characters ``.``, ``-``, or ``_`` replaced with -a single ``-`` character. This can be done using the following snippet of code -(as specified in :pep:`503`):: - - re.sub(r"[-_.]+", "-", name).lower() - +For comparison purposes, the names should be :ref:`normalized ` before comparing. .. _core-metadata-version: diff --git a/source/specifications/recording-installed-packages.rst b/source/specifications/recording-installed-packages.rst index 9085807f3..6a01544d5 100644 --- a/source/specifications/recording-installed-packages.rst +++ b/source/specifications/recording-installed-packages.rst @@ -40,7 +40,7 @@ packages (commonly, the ``site-packages`` directory). This directory is named as ``{name}-{version}.dist-info``, with ``name`` and ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be -normalized (see :pep:`PEP 503 <503#normalized-names>` and +normalized (see :ref:`name-normalization` and :pep:`PEP 440 <440#normalization>` for the definition of normalization for each field respectively), and replace dash (``-``) characters with underscore (``_``) characters, so the ``.dist-info`` directory always has From d0509af9749fad49713ee79c3643637c93e1cd70 Mon Sep 17 00:00:00 2001 From: Pradyun Gedam Date: Sat, 31 Dec 2022 12:58:46 +0000 Subject: [PATCH 0309/1072] Use a clearer example in the authors list This avoids confusion for people who don't know that Pradyun and Tzu-Ping are different humans. :) --- source/specifications/declaring-project-metadata.rst | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/source/specifications/declaring-project-metadata.rst b/source/specifications/declaring-project-metadata.rst index 13d225d36..42659ee33 100644 --- a/source/specifications/declaring-project-metadata.rst +++ b/source/specifications/declaring-project-metadata.rst @@ -342,8 +342,10 @@ Example license = {file = "LICENSE.txt"} keywords = ["egg", "bacon", "sausage", "tomatoes", "Lobster Thermidor"] authors = [ - {email = "pradyun@example.com"}, - {name = "Tzu-Ping Chung"} + {name = "Pradyun Gedam", email = "pradyun@example.com"}, + {name = "Tzu-Ping Chung", email = "tzu-ping@example.com"}, + {name = "Another person"}, + {email = "different.person@example.com"}, ] maintainers = [ {name = "Brett Cannon", email = "brett@python.org"} From 5dcb943b856290867742ce1925dcca3af7f60f8f Mon Sep 17 00:00:00 2001 From: Pradyun Gedam Date: Sat, 31 Dec 2022 18:40:32 +0000 Subject: [PATCH 0310/1072] Add examples to each field in the pyproject.toml project table spec This makes it an easier reference section for readers, since this serves as the primary user-facing documentation around the `project` table today. --- .../declaring-project-metadata.rst | 103 ++++++++++++++++-- 1 file changed, 95 insertions(+), 8 deletions(-) diff --git a/source/specifications/declaring-project-metadata.rst b/source/specifications/declaring-project-metadata.rst index 42659ee33..23e73d065 100644 --- a/source/specifications/declaring-project-metadata.rst +++ b/source/specifications/declaring-project-metadata.rst @@ -73,6 +73,10 @@ The name of the project. Tools SHOULD normalize this name, as specified by :pep:`503`, as soon as it is read for internal consistency. +.. code-block:: toml + + [project] + name = "spam" ``version`` ----------- @@ -85,6 +89,10 @@ The version of the project as supported by :pep:`440`. Users SHOULD prefer to specify already-normalized versions. +.. code-block:: toml + + [project] + version = "2020.0.0" ``description`` --------------- @@ -95,6 +103,10 @@ Users SHOULD prefer to specify already-normalized versions. The summary description of the project. +.. code-block:: toml + + [project] + description = "Lovely Spam! Wonderful Spam!" ``readme`` ---------- @@ -134,6 +146,13 @@ alternative content-types which they can transform to a content-type as supported by the :ref:`core metadata `. Otherwise tools MUST raise an error for unsupported content-types. +.. code-block:: toml + + [project] + # A single pyproject.toml file can only have one of the following. + readme = "README.md" + readme = "README.rst" + readme = {file = "README.txt", content-type = "text/markdown"} ``requires-python`` ------------------- @@ -144,6 +163,10 @@ tools MUST raise an error for unsupported content-types. The Python version requirements of the project. +.. code-block:: toml + + [project] + requires-python = ">=3.8" ``license`` ----------- @@ -159,6 +182,12 @@ file's encoding is UTF-8. The ``text`` key has a string value which is the license of the project. These keys are mutually exclusive, so a tool MUST raise an error if the metadata specifies both keys. +.. code-block:: toml + + [project] + # A single pyproject.toml file can only have one of the following. + license = {file = "LICENSE"} + license = {text = "MIT License"} ``authors``/``maintainers`` --------------------------- @@ -201,6 +230,19 @@ follows: as appropriate, with the format ``{name} <{email}>``. 4. Multiple values should be separated by commas. +.. code-block:: toml + + [project] + authors = [ + {name = "Pradyun Gedam", email = "pradyun@example.com"}, + {name = "Tzu-Ping Chung", email = "tzu-ping@example.com"}, + {name = "Another person"}, + {email = "different.person@example.com"}, + ] + maintainers = [ + {name = "Brett Cannon", email = "brett@python.org"} + ] + ``keywords`` ------------ @@ -211,6 +253,10 @@ follows: The keywords for the project. +.. code-block:: toml + + [project] + keywords = ["egg", "bacon", "sausage", "tomatoes", "Lobster Thermidor"] ``classifiers`` --------------- @@ -221,6 +267,12 @@ The keywords for the project. Trove classifiers which apply to the project. +.. code-block:: toml + + classifiers = [ + "Development Status :: 4 - Beta", + "Programming Language :: Python" + ] ``urls`` -------- @@ -232,6 +284,13 @@ Trove classifiers which apply to the project. A table of URLs where the key is the URL label and the value is the URL itself. +.. code-block:: toml + + [project.urls] + homepage = "https://example.com" + documentation = "https://readthedocs.org" + repository = "https://github.com/me/spam.git" + changelog = "https://github.com/me/spam/blob/master/CHANGELOG.md" Entry points ------------ @@ -262,6 +321,17 @@ Build back-ends MUST raise an error if the metadata defines a be ambiguous in the face of ``[project.scripts]`` and ``[project.gui-scripts]``, respectively. +.. code-block:: toml + + [project.scripts] + spam-cli = "spam:main_cli" + + [project.gui-scripts] + spam-gui = "spam:main_gui" + + [project.entry-points."spam.magical"] + tomatoes = "spam:main_tomatoes" + ``dependencies``/``optional-dependencies`` ------------------------------------------ @@ -289,6 +359,22 @@ in the array thus becomes a corresponding matching :ref:`Provides-Extra ` metadata. +.. code-block:: toml + + [project] + dependencies = [ + "httpx", + "gidgethub[httpx]>4.0.0", + "django>2.1; os_name != 'nt'", + "django>2.0; os_name == 'nt'", + ] + + [project.optional-dependencies] + gui = ["PyQt5"] + cli = [ + "rich", + "click", + ] ``dynamic`` ----------- @@ -327,6 +413,10 @@ provided via tooling later on. the data for it (omitting the data, if determined to be the accurate value, is acceptable). +.. code-block:: toml + + dynamic = ["version", "description", "optional-dependencies"] + Example ======= @@ -359,19 +449,16 @@ Example "httpx", "gidgethub[httpx]>4.0.0", "django>2.1; os_name != 'nt'", - "django>2.0; os_name == 'nt'" + "django>2.0; os_name == 'nt'", ] # dynamic = ["version", "description"] [project.optional-dependencies] - test = [ - "pytest > 5.0.0", - "pytest-cov[all]" - ] - doc = [ - "sphinx", - "furo" + gui = ["PyQt5"] + cli = [ + "rich", + "click", ] [project.urls] From d84c44b27edbad9afe83df9f129838c80e43a02e Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Wed, 11 Jan 2023 19:33:09 -0500 Subject: [PATCH 0311/1072] Remove defunct list of Windows installers. (#1192) Listed as "Archived" at https://www.cgohlke.com/. --- source/guides/installing-scientific-packages.rst | 6 ------ 1 file changed, 6 deletions(-) diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst index 04f555731..404fed83b 100644 --- a/source/guides/installing-scientific-packages.rst +++ b/source/guides/installing-scientific-packages.rst @@ -64,12 +64,6 @@ up a suitable environment to build extensions locally. The extensions provided in these installers are typically compatible with the CPython Windows installers published on python.org. -For projects which don't provide their own Windows installers (and even -some which do), Christoph Gohlke at the University of California provides -a `collection of Windows installers -`__. Many Python users on -Windows have reported a positive experience with these prebuilt versions. - As with Linux system packages, the Windows installers will only install into a system Python installation - they do not support installation in virtual environments. Allowing access to distributions installed into the system Python From c8db4beafa3c4e6d6aa102421a4f655dd1c79273 Mon Sep 17 00:00:00 2001 From: Shantanu <12621235+hauntsaninja@users.noreply.github.com> Date: Sun, 22 Jan 2023 12:00:54 -0800 Subject: [PATCH 0312/1072] Update the flit_core lower bound (#1193) Version 3.4 added PEP 660 support. Version 3.3 added PEP 621 support. https://flit.pypa.io/en/stable/history.html --- source/tutorials/packaging-projects.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index b65866c63..9a3e4c9cf 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -147,7 +147,7 @@ Open :file:`pyproject.toml` and enter one of these ``[build-system]`` tables: .. code-block:: toml [build-system] - requires = ["flit_core>=3.2"] + requires = ["flit_core>=3.4"] build-backend = "flit_core.buildapi" .. tab:: PDM From 8d3a5524374289f091abf8424a8f3fe9a339281e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20Bidoul?= Date: Mon, 30 Jan 2023 11:13:40 +0100 Subject: [PATCH 0313/1072] Add a hashes key to the direct URL data structure (#1199) --- source/specifications/direct-url.rst | 50 ++++++++++++++++++++++------ 1 file changed, 39 insertions(+), 11 deletions(-) diff --git a/source/specifications/direct-url.rst b/source/specifications/direct-url.rst index 9b8180c47..7dd9efa99 100644 --- a/source/specifications/direct-url.rst +++ b/source/specifications/direct-url.rst @@ -7,8 +7,7 @@ Recording the Direct URL Origin of installed distributions This document specifies a :file:`direct_url.json` file in the :file:`*.dist-info` directory of an installed distribution, to record the -Direct URL Origin of the distribution. The layout of this file was originally -specified in :pep:`610` and is formally documented here. +Direct URL Origin of the distribution. .. contents:: Contents :local: @@ -65,14 +64,33 @@ as a dictionary with the following keys: version of the source code that was installed. When ``url`` refers to a source archive or a wheel, the ``archive_info`` key -MUST be present as a dictionary with the following key: - -- A ``hash`` key (type ``string``) SHOULD be present, with value - ``=``. - It is RECOMMENDED that only hashes which are unconditionally provided by - the latest version of the standard library's ``hashlib`` module be used for - source archive hashes. At time of writing, that list consists of 'md5', - 'sha1', 'sha224', 'sha256', 'sha384', and 'sha512'. +MUST be present as a dictionary with the following keys: + +- A ``hashes`` key SHOULD be present as a dictionary mapping a hash name to a hex + encoded digest of the file. + + Multiple hashes can be included, and it is up to the consumer to decide what to do + with multiple hashes (it may validate all of them or a subset of them, or nothing at + all). + + These hash names SHOULD always be normalized to be lowercase. + + Any hash algorithm available via ``hashlib`` (specifically any that can be passed to + ``hashlib.new()`` and do not require additional parameters) can be used as a key for + the hashes dictionary. At least one secure algorithm from + ``hashlib.algorithms_guaranteed`` SHOULD always be included. At time of writing, + ``sha256`` specifically is recommended. + +- A deprecated ``hash`` key (type ``string``) MAY be present for backwards compatibility + purposes, with value ``=``. + +Producers of the data structure SHOULD emit the ``hashes`` key whether one or multiple +hashes are available. Producers SHOULD continue to emit the ``hash`` key in contexts +where they did so before, so as to keep backwards compatibility for existing clients. + +When both the ``hash`` and ``hashes`` keys are present, the hash represented in the +``hash`` key MUST also be present in the ``hashes`` dictionary, so consumers can +consider the ``hashes`` key only if it is present, and fall back to ``hash`` otherwise. When ``url`` refers to a local directory, the ``dir_info`` key MUST be present as a dictionary with the following key: @@ -234,7 +252,9 @@ Source archive: { "url": "https://github.com/pypa/pip/archive/1.3.1.zip", "archive_info": { - "hash": "sha256=2dc6b5a470a1bde68946f263f1af1515a2574a150a30d6ce02c6ff742fcc0db8" + "hashes": { + "sha256": "2dc6b5a470a1bde68946f263f1af1515a2574a150a30d6ce02c6ff742fcc0db8" + } } } @@ -292,3 +312,11 @@ Commands that *do not* generate a ``direct_url.json`` * ``pip install app`` * ``pip install app --no-index --find-links https://example.com/`` + +History +======= + +- March 2020: the ``direct_url.json`` metadata file was originally specified in + :pep:`610` and is formally documented here. +- January 2023: Added the ``archive_info.hashes`` key + (`discussion `__). From d36954f27f8ac9302c7b0da8f49f2a021265619b Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Mon, 13 Feb 2023 05:40:37 -0600 Subject: [PATCH 0314/1072] Use `req @ url` syntax to install from remote VCS (#1207) This form is deprecated and due for removal in a future pip release. --- requirements.txt | 2 +- .../distributing-packages-using-setuptools.rst | 2 +- ...alling-using-pip-and-virtual-environments.rst | 2 +- source/specifications/direct-url.rst | 4 ++-- source/tutorials/installing-packages.rst | 16 ++++++++-------- 5 files changed, 13 insertions(+), 13 deletions(-) diff --git a/requirements.txt b/requirements.txt index 57fd523b0..125f0cf33 100644 --- a/requirements.txt +++ b/requirements.txt @@ -3,4 +3,4 @@ sphinx-autobuild==0.7.1 sphinx-inline-tabs==2021.4.11b9 python-docs-theme==2022.1 sphinx-copybutton==0.5.0 -git+https://github.com/pypa/pypa-docs-theme.git#egg=pypa-docs-theme +pypa-docs-theme @ git+https://github.com/pypa/pypa-docs-theme.git diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index e0fb94a67..d843a51a6 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -693,7 +693,7 @@ you want "bar" installed from VCS in editable mode, then you could construct a requirements file like so:: -e . - -e git+https://somerepo/bar.git#egg=bar + -e bar @ git+https://somerepo/bar.git The first line says to install your project and any dependencies. The second line overrides the "bar" dependency, such that it's fulfilled from VCS, not diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst index 1ea79be5b..e43e20e27 100644 --- a/source/guides/installing-using-pip-and-virtual-environments.rst +++ b/source/guides/installing-using-pip-and-virtual-environments.rst @@ -349,7 +349,7 @@ example, you can install directly from a git repository: .. code-block:: bash - git+https://github.com/GoogleCloudPlatform/google-auth-library-python.git#egg=google-auth + google-auth @ git+https://github.com/GoogleCloudPlatform/google-auth-library-python.git For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `. diff --git a/source/specifications/direct-url.rst b/source/specifications/direct-url.rst index 7dd9efa99..bf93dfd9b 100644 --- a/source/specifications/direct-url.rst +++ b/source/specifications/direct-url.rst @@ -299,10 +299,10 @@ Commands that generate a ``direct_url.json``: * ``pip install https://example.com/app-1.0.tgz`` * ``pip install https://example.com/app-1.0.whl`` -* ``pip install "git+https://example.com/repo/app.git#egg=app&subdirectory=setup"`` +* ``pip install "app&subdirectory=setup @ git+https://example.com/repo/app.git"`` * ``pip install ./app`` * ``pip install file:///home/user/app`` -* ``pip install --editable "git+https://example.com/repo/app.git#egg=app&subdirectory=setup"`` +* ``pip install --editable "app&subdirectory=setup @ git+https://example.com/repo/app.git"`` (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``"editable": true`` and no ``vcs_info`` will be set) diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst index 577d719cd..cc66abef6 100644 --- a/source/tutorials/installing-packages.rst +++ b/source/tutorials/installing-packages.rst @@ -492,19 +492,19 @@ syntax, see pip's section on :ref:`VCS Support `. .. code-block:: bash - python3 -m pip install -e git+https://git.repo/some_pkg.git#egg=SomeProject # from git - python3 -m pip install -e hg+https://hg.repo/some_pkg#egg=SomeProject # from mercurial - python3 -m pip install -e svn+svn://svn.repo/some_pkg/trunk/#egg=SomeProject # from svn - python3 -m pip install -e git+https://git.repo/some_pkg.git@feature#egg=SomeProject # from a branch + python3 -m pip install -e SomeProject @ git+https://git.repo/some_pkg.git # from git + python3 -m pip install -e SomeProject @ hg+https://hg.repo/some_pkg # from mercurial + python3 -m pip install -e SomeProject @ svn+svn://svn.repo/some_pkg/trunk/ # from svn + python3 -m pip install -e SomeProject @ git+https://git.repo/some_pkg.git@feature # from a branch .. tab:: Windows .. code-block:: bat - py -m pip install -e git+https://git.repo/some_pkg.git#egg=SomeProject # from git - py -m pip install -e hg+https://hg.repo/some_pkg#egg=SomeProject # from mercurial - py -m pip install -e svn+svn://svn.repo/some_pkg/trunk/#egg=SomeProject # from svn - py -m pip install -e git+https://git.repo/some_pkg.git@feature#egg=SomeProject # from a branch + py -m pip install -e SomeProject @ git+https://git.repo/some_pkg.git # from git + py -m pip install -e SomeProject @ hg+https://hg.repo/some_pkg # from mercurial + py -m pip install -e SomeProject @ svn+svn://svn.repo/some_pkg/trunk/ # from svn + py -m pip install -e SomeProject @ git+https://git.repo/some_pkg.git@feature # from a branch Installing from other Indexes ============================= From a103b5699eba73f0266044eeb8eecc6835642a3e Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Tue, 14 Feb 2023 14:54:03 -0600 Subject: [PATCH 0315/1072] fix: Use proper subdirectory syntax for pip url fragments (#1208) * Use the correct syntax for url fragments with pip of the form python -m pip install "pkg @ vcs+protocol://repo_url/#subdirectory=pkg_dir" - c.f. https://pip.pypa.io/en/stable/topics/vcs-support/#url-fragments * Revises PR #1207 Co-authored-by: sinoroc --- source/specifications/direct-url.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/specifications/direct-url.rst b/source/specifications/direct-url.rst index bf93dfd9b..fc00fa132 100644 --- a/source/specifications/direct-url.rst +++ b/source/specifications/direct-url.rst @@ -299,10 +299,10 @@ Commands that generate a ``direct_url.json``: * ``pip install https://example.com/app-1.0.tgz`` * ``pip install https://example.com/app-1.0.whl`` -* ``pip install "app&subdirectory=setup @ git+https://example.com/repo/app.git"`` +* ``pip install "app @ git+https://example.com/repo/app.git#subdirectory=setup"`` * ``pip install ./app`` * ``pip install file:///home/user/app`` -* ``pip install --editable "app&subdirectory=setup @ git+https://example.com/repo/app.git"`` +* ``pip install --editable "app @ git+https://example.com/repo/app.git#subdirectory=setup"`` (in which case, ``url`` will be the local directory where the git repository has been cloned to, and ``dir_info`` will be present with ``"editable": true`` and no ``vcs_info`` will be set) From 0c93c184280e069a59a043ea334b3bc55cc355b1 Mon Sep 17 00:00:00 2001 From: Nick Coghlan Date: Mon, 6 Mar 2023 22:02:15 +1000 Subject: [PATCH 0316/1072] Clarify specs for external installer interactions (#1215) Co-authored-by: Paul Moore --- source/specifications/direct-url.rst | 5 +- source/specifications/entry-points.rst | 5 +- .../externally-managed-environments.rst | 22 +++++++ source/specifications/index.rst | 10 +++- .../recording-installed-packages.rst | 59 ++++++++++++++++--- .../specifications/virtual-environments.rst | 50 ++++++++++++++++ 6 files changed, 139 insertions(+), 12 deletions(-) create mode 100644 source/specifications/externally-managed-environments.rst create mode 100644 source/specifications/virtual-environments.rst diff --git a/source/specifications/direct-url.rst b/source/specifications/direct-url.rst index fc00fa132..7a1560e87 100644 --- a/source/specifications/direct-url.rst +++ b/source/specifications/direct-url.rst @@ -6,8 +6,9 @@ Recording the Direct URL Origin of installed distributions ========================================================== This document specifies a :file:`direct_url.json` file in the -:file:`*.dist-info` directory of an installed distribution, to record the -Direct URL Origin of the distribution. +``*.dist-info`` directory of an installed distribution, to record the +Direct URL Origin of the distribution. The general structure and usage of +``*.dist-info`` directories is described in :ref:`recording-installed-packages`. .. contents:: Contents :local: diff --git a/source/specifications/entry-points.rst b/source/specifications/entry-points.rst index 6c94a25fb..a11f3ca93 100644 --- a/source/specifications/entry-points.rst +++ b/source/specifications/entry-points.rst @@ -81,8 +81,9 @@ File format Entry points are defined in a file called :file:`entry_points.txt` in the :file:`*.dist-info` directory of the distribution. This is the directory -described in :pep:`376` for installed distributions, and in :pep:`427` for -wheels. The file uses the UTF-8 character encoding. +described in :ref:`recording-installed-packages` for installed distributions, +and in :ref:`binary-distribution-format` for wheels. +The file uses the UTF-8 character encoding. The file contents are in INI format, as read by Python's :mod:`configparser` module. However, configparser treats names as case-insensitive by default, diff --git a/source/specifications/externally-managed-environments.rst b/source/specifications/externally-managed-environments.rst new file mode 100644 index 000000000..3876d8e34 --- /dev/null +++ b/source/specifications/externally-managed-environments.rst @@ -0,0 +1,22 @@ + +.. _externally-managed-environments: + +=============================== +Externally Managed Environments +=============================== + +While some Python installations are entirely managed by the user that installed +Python, others may be provided and managed by another means (such as the +operating system package manager in a Linux distribution, or as a bundled +Python environment in an application with a dedicated installer). + +Attempting to use conventional Python packaging tools to manipulate such +environments can be confusing at best and outright break the entire underlying +operating system at worst. Documentation and interoperability guides only go +so far in resolving such problems. + +:pep:`668` defined an ``EXTERNALLY-MANAGED`` marker file that allows a Python +installation to indicate to Python-specific tools such as ``pip`` that they +neither install nor remove packages into the interpreter’s default installation +environment, and should instead guide the end user towards using +:ref:`virtual-environments`. diff --git a/source/specifications/index.rst b/source/specifications/index.rst index 3265ce56f..f4a290e29 100644 --- a/source/specifications/index.rst +++ b/source/specifications/index.rst @@ -22,10 +22,18 @@ Package Distribution Metadata declaring-build-dependencies declaring-project-metadata platform-compatibility-tags + +Package Installation Environment Metadata +----------------------------------------- + +.. toctree:: + :maxdepth: 1 + recording-installed-packages entry-points direct-url - + virtual-environments + externally-managed-environments Package Distribution File Formats --------------------------------- diff --git a/source/specifications/recording-installed-packages.rst b/source/specifications/recording-installed-packages.rst index 6a01544d5..bac887b2b 100644 --- a/source/specifications/recording-installed-packages.rst +++ b/source/specifications/recording-installed-packages.rst @@ -21,12 +21,14 @@ History and change workflow =========================== The metadata described here was first specified in :pep:`376`, and later -amended in :pep:`627`. +amended in :pep:`627` (and other PEPs). It was formerly known as *Database of Installed Python Distributions*. -Further amendments (except trivial language or typography fixes) must be made -through the PEP process (see :pep:`1`). +As with other PyPA specifications, editorial amendments with no functional +impact may be made through the GitHub pull request workflow. Proposals for +functional changes that would require amendments to package building and/or +installation tools must be made through the PEP process (see :pep:`1`). -While this document is the normative specification, these PEPs that introduce +While this document is the normative specification, the PEPs that introduce changes to it may include additional information such as rationales and backwards compatibility considerations. @@ -66,12 +68,14 @@ encouraged to start normalizing those fields. provide API for such tools to consume, so tools can have access to the unnormalized name when displaying distrubution information. -This ``.dist-info`` directory can contain these files, described in detail -below: +This ``.dist-info`` directory may contain the following files, described in +detail below: * ``METADATA``: contains project metadata * ``RECORD``: records the list of installed files. * ``INSTALLER``: records the name of the tool used to install the project. +* ``entry_points.txt``: see :ref:`entry-points` for details +* ``direct_url.json``: see :ref:`direct-url` for details The ``METADATA`` file is mandatory. All other files may be omitted at the installing tool's discretion. @@ -169,7 +173,7 @@ Here is an example snippet of a possible ``RECORD`` file:: If the ``RECORD`` file is missing, tools that rely on ``.dist-info`` must not attempt to uninstall or upgrade the package. -(This does not apply to tools that rely on other sources of information, +(This restriction does not apply to tools that rely on other sources of information, such as system package managers in Linux distros.) @@ -197,6 +201,18 @@ For example, if a tool is asked to uninstall a project but finds no ``RECORD`` file, it may suggest that the tool named in ``INSTALLER`` may be able to do the uninstallation. + +The entry_points.txt file +========================= + +This file MAY be created by installers to indicate when packages contain +components intended for discovery and use by other code, including console +scripts and other applications that the installer has made available for +execution. + +Its detailed specification is at :ref:`entry-points`. + + The direct_url.json file ======================== @@ -207,3 +223,32 @@ This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier). Its detailed specification is at :ref:`direct-url`. + + +Intentionally preventing changes to installed packages +====================================================== + +In some cases (such as when needing to manage external dependencies in addition +to Python ecosystem dependencies), it is desirable for a tool that installs +packages into a Python environment to ensure that other tools are not used to +uninstall or otherwise modify that installed package, as doing so may cause +compatibility problems with the wider environment. + +To achieve this, affected tools should take the folllowing steps: + +* Rename or remove the ``RECORD`` file to prevent changes via other tools (e.g. + appending a suffix to create a non-standard ``RECORD.tool`` file if the tool + itself needs the information, or omitting the file entirely if the package + contents are tracked and managed via other means) +* Write an ``INSTALLER`` file indicating the name of the tool that should be used + to manage the package (this allows ``RECORD``-aware tools to provide better + error notices when asked to modify affected packages) + +Python runtime providers may also prevent inadvertent modification of platform +provided packages by modifying the default Python package installation scheme +to use a location other than that used by platform provided packages (while also +ensuring both locations appear on the default Python import path). + +In some circumstances, it may be desirable to block even installation of +additional packages via Python-specific tools. For these cases refer to +:ref:`externally-managed-environments` \ No newline at end of file diff --git a/source/specifications/virtual-environments.rst b/source/specifications/virtual-environments.rst new file mode 100644 index 000000000..c38c2faeb --- /dev/null +++ b/source/specifications/virtual-environments.rst @@ -0,0 +1,50 @@ + +.. _virtual-environments: + +=========================== +Python Virtual Environments +=========================== + +For Python 3.3 and later versions, :pep:`405` introduced interpreter level support +for the concept of "Python Virtual Environments". Each virtual environment has +its own Python binary (allowing creation of environments with various Python +versions) and can have its own independent set of installed Python packages in +its site directories, but shares the standard library with the base installed +Python. While the concept of virtual environments existed prior to this update, +there was no previously standardised mechanism for declaring or discovering them. + + +Runtime detection of virtual environments +========================================= + +At runtime, virtual environments can be identified by virtue of ``sys.prefix`` +(the filesystem location of the running interpreter) having a different value +from ``sys.base_prefix`` (the default filesytem location of the standard library +directories). + +:ref:`venv-explanation` in the Python standard library documentation for the +:py:mod:`venv` module covers this along with the concept of "activating" a +virtual environment in an interactive operating system shell (this activation +step is optional and hence the changes it makes can't be reliably used to +detect whether a Python program is running in a virtual environment or not). + + +Declaring installation environments as Python virtual environments +================================================================== + +As described in :pep:`405`, a Python virtual environment in its simplest form +consists of nothing more than a copy or symlink of the Python binary accompanied +by a ``site-packages`` directory and a ``pyvenv.cfg`` file with a ``home`` key +that indicates where to find the Python standard library modules. + +While designed to meet the needs of the standard :py:mod:`venv` module, this +split installation and ``pyvenv.cfg`` file approach can be used by *any* +Python installation provider that desires Python-specific tools to be aware that +they are already operating in a virtual environment and no further environment +nesting is required or desired. + +Even in the absence of a ``pyvenv.cfg`` file, any approach (e.g. +``sitecustomize.py``, patching the installed Python runtime) that results in +``sys.prefix`` and ``sys.base_prefix`` having different values, while still +providing a matching default package installation scheme in ``sysconfig``, will +be detected and behave as a Python virtual environment. From 976cb3987d59960736d6d0a35d6ec52bd74b00c5 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Mon, 6 Mar 2023 04:07:10 -0800 Subject: [PATCH 0317/1072] Move PEP 425 over (#1206) Also update to say spaces are not allowed in wheel tags (see https://github.com/pypa/packaging/issues/652 ) --- .../platform-compatibility-tags.rst | 244 ++++++++++++++++-- 1 file changed, 224 insertions(+), 20 deletions(-) diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst index 5020d2cd9..c7c9812f1 100644 --- a/source/specifications/platform-compatibility-tags.rst +++ b/source/specifications/platform-compatibility-tags.rst @@ -9,27 +9,103 @@ Platform compatibility tags allow build tools to mark distributions as being compatible with specific platforms, and allows installers to understand which distributions are compatible with the system they are running on. -The platform compatibility tagging model used for the ``wheel`` distribution -format is defined in :pep:`425`. +The following PEPs contributed to this spec: -Platform tags for Windows -------------------------- +1. :pep:`425` +2. :pep:`513` +3. :pep:`571` +4. :pep:`599` +5. :pep:`600` -The scheme defined in :pep:`425` covers public distribution of wheel files to -systems running Windows. +Overview +======== -Platform tags for macOS (Mac OS X) ----------------------------------- +The tag format is ``{python tag}-{abi tag}-{platform tag}``. -The scheme defined in :pep:`425` covers public distribution of wheel files to -systems running macOS (previously known as Mac OS X). +python tag + 'py27', 'cp33' +abi tag + 'cp32dmu', 'none' +platform tag + 'linux_x86_64', 'any' -Platform tags for common Linux distributions --------------------------------------------- +For example, the tag ``py27-none-any`` indicates compatibility with Python 2.7 +(any Python 2.7 implementation) with no abi requirement, on any platform. +Use +=== + +The ``wheel`` built package format includes these tags in its filenames, +of the form +``{distribution}-{version}(-{build tag})?-{python tag}-{abitag}-{platform tag}.whl``. +Other package formats may have their own conventions. + +Any potential spaces in any tag should be replaced with ``_``. + +Details +======= + +Python Tag +---------- + +The Python tag indicates the implementation and version required by +a distribution. Major implementations have abbreviated codes, initially: + +* py: Generic Python (does not require implementation-specific features) +* cp: CPython +* ip: IronPython +* pp: PyPy +* jy: Jython + +Other Python implementations should use ``sys.implementation.name``. + +The version is ``py_version_nodot``. CPython gets away with no dot, +but if one is needed the underscore ``_`` is used instead. PyPy should +probably use its own versions here ``pp18``, ``pp19``. + +The version can be just the major version ``2`` or ``3`` ``py2``, ``py3`` for +many pure-Python distributions. + +Importantly, major-version-only tags like ``py2`` and ``py3`` are not +shorthand for ``py20`` and ``py30``. Instead, these tags mean the packager +intentionally released a cross-version-compatible distribution. + +A single-source Python 2/3 compatible distribution can use the compound +tag ``py2.py3``. See `Compressed Tag Sets`_, below. + +ABI Tag +------- + +The ABI tag indicates which Python ABI is required by any included +extension modules. For implementation-specific ABIs, the implementation +is abbreviated in the same way as the Python Tag, e.g. ``cp33d`` would be +the CPython 3.3 ABI with debugging. + +The CPython stable ABI is ``abi3`` as in the shared library suffix. + +Implementations with a very unstable ABI may use the first 6 bytes (as +8 base64-encoded characters) of the SHA-256 hash of their source code +revision and compiler flags, etc, but will probably not have a great need +to distribute binary distributions. Each implementation's community may +decide how to best use the ABI tag. + +Platform Tag +------------ + +The platform tag is simply ``distutils.util.get_platform()`` with all +hyphens ``-`` and periods ``.`` replaced with underscore ``_``. + +* win32 +* linux_i386 +* linux_x86_64 + + +------------- +``manylinux`` +------------- .. _manylinux: -The scheme defined in :pep:`425` is insufficient for public distribution of +The scheme defined in :pep:`425` was insufficient for public distribution of wheel files (and \*nix wheel files in general) to Linux platforms, due to the large ecosystem of Linux platforms and subtle differences between them. @@ -86,13 +162,141 @@ pip ``>=8.1.0`` ``>=19.0`` ``>=19.3`` ``>=20.3`` auditwheel ``>=1.0.0`` ``>=2.0.0`` ``>=3.0.0`` ``>=3.3.0`` [#]_ ========== ============== ================= ================= ================= -Platform tags for other \*nix platforms ---------------------------------------- +.. [#] Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0 -The scheme defined in :pep:`425` is not generally sufficient for public -distribution of wheel files to other \*nix platforms. Efforts are currently -(albeit intermittently) under way to define improved compatibility tagging -schemes for AIX and for Alpine Linux. +Use +=== +The tags are used by installers to decide which built distribution +(if any) to download from a list of potential built distributions. +The installer maintains a list of (pyver, abi, arch) tuples that it +will support. If the built distribution's tag is ``in`` the list, then +it can be installed. -.. [#] Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0 +It is recommended that installers try to choose the most feature complete +built distribution available (the one most specific to the installation +environment) by default before falling back to pure Python versions +published for older Python releases. Installers are also recommended to +provide a way to configure and re-order the list of allowed compatibility +tags; for example, a user might accept only the ``*-none-any`` tags to only +download built packages that advertise themselves as being pure Python. + +Another desirable installer feature might be to include "re-compile from +source if possible" as more preferable than some of the compatible but +legacy pre-built options. + +This example list is for an installer running under CPython 3.3 on a +linux_x86_64 system. It is in order from most-preferred (a distribution +with a compiled extension module, built for the current version of +Python) to least-preferred (a pure-Python distribution built with an +older version of Python): + +1. cp33-cp33m-linux_x86_64 +2. cp33-abi3-linux_x86_64 +3. cp3-abi3-linux_x86_64 +4. cp33-none-linux_x86_64* +5. cp3-none-linux_x86_64* +6. py33-none-linux_x86_64* +7. py3-none-linux_x86_64* +8. cp33-none-any +9. cp3-none-any +10. py33-none-any +11. py3-none-any +12. py32-none-any +13. py31-none-any +14. py30-none-any + +* Built distributions may be platform specific for reasons other than C + extensions, such as by including a native executable invoked as + a subprocess. + +Sometimes there will be more than one supported built distribution for a +particular version of a package. For example, a packager could release +a package tagged ``cp33-abi3-linux_x86_64`` that contains an optional C +extension and the same distribution tagged ``py3-none-any`` that does not. +The index of the tag in the supported tags list breaks the tie, and the +package with the C extension is installed in preference to the package +without because that tag appears first in the list. + +Compressed Tag Sets +=================== + +To allow for compact filenames of bdists that work with more than +one compatibility tag triple, each tag in a filename can instead be a +'.'-separated, sorted, set of tags. For example, pip, a pure-Python +package that is written to run under Python 2 and 3 with the same source +code, could distribute a bdist with the tag ``py2.py3-none-any``. +The full list of simple tags is:: + + for x in pytag.split('.'): + for y in abitag.split('.'): + for z in archtag.split('.'): + yield '-'.join((x, y, z)) + +A bdist format that implements this scheme should include the expanded +tags in bdist-specific metadata. This compression scheme can generate +large numbers of unsupported tags and "impossible" tags that are supported +by no Python implementation e.g. "cp33-cp31u-win64", so use it sparingly. + +FAQ +=== + +What tags are used by default? + Tools should use the most-preferred architecture dependent tag + e.g. ``cp33-cp33m-win32`` or the most-preferred pure python tag + e.g. ``py33-none-any`` by default. If the packager overrides the + default it indicates that they intended to provide cross-Python + compatibility. + +What tag do I use if my distribution uses a feature exclusive to the newest version of Python? + Compatibility tags aid installers in selecting the *most compatible* + build of a *single version* of a distribution. For example, when + there is no Python 3.3 compatible build of ``beaglevote-1.2.0`` + (it uses a Python 3.4 exclusive feature) it may still use the + ``py3-none-any`` tag instead of the ``py34-none-any`` tag. A Python + 3.3 user must combine other qualifiers, such as a requirement for the + older release ``beaglevote-1.1.0`` that does not use the new feature, + to get a compatible build. + +Why isn't there a ``.`` in the Python version number? + CPython has lasted 20+ years without a 3-digit major release. This + should continue for some time. Other implementations may use _ as + a delimiter, since both - and . delimit the surrounding filename. + +Why normalise hyphens and other non-alphanumeric characters to underscores? + To avoid conflicting with the ``.`` and ``-`` characters that separate + components of the filename, and for better compatibility with the + widest range of filesystem limitations for filenames (including + being usable in URL paths without quoting). + +Why not use special character rather than ``.`` or ``-``? + Either because that character is inconvenient or potentially confusing + in some contexts (for example, ``+`` must be quoted in URLs, ``~`` is + used to denote the user's home directory in POSIX), or because the + advantages weren't sufficiently compelling to justify changing the + existing reference implementation for the wheel format defined in :pep:427 + (for example, using ``,`` rather than ``.`` to separate components + in a compressed tag). + +Who will maintain the registry of abbreviated implementations? + New two-letter abbreviations can be requested on the python-dev + mailing list. As a rule of thumb, abbreviations are reserved for + the current 4 most prominent implementations. + +Does the compatibility tag go into METADATA or PKG-INFO? + No. The compatibility tag is part of the built distribution's + metadata. METADATA / PKG-INFO should be valid for an entire + distribution, not a single build of that distribution. + +Why didn't you mention my favorite Python implementation? + The abbreviated tags facilitate sharing compiled Python code in a + public index. Your Python implementation can use this specification + too, but with longer tags. + Recall that all "pure Python" built distributions just use ``py``. + +Why is the ABI tag (the second tag) sometimes "none" in the reference implementation? + Since Python 2 does not have an easy way to get to the SOABI + (the concept comes from newer versions of Python 3) the reference + implementation at the time of writing guesses "none". Ideally it + would detect "py27(d|m|u)" analogous to newer versions of Python, + but in the meantime "none" is a good enough way to say "don't know". From 1b8038dfdade511f123011c2d8181fd1a75955a1 Mon Sep 17 00:00:00 2001 From: Jiayang Date: Tue, 7 Mar 2023 05:29:09 -0600 Subject: [PATCH 0318/1072] Fix: python -> pyton3 to match the python3 --version's not found error (#1217) Co-authored-by: Jiayang Sun --- source/tutorials/installing-packages.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst index cc66abef6..e03e43732 100644 --- a/source/tutorials/installing-packages.rst +++ b/source/tutorials/installing-packages.rst @@ -58,10 +58,10 @@ please install the latest 3.x version from `python.org`_ or refer to the .. code-block:: python - >>> python --version + >>> python3 --version Traceback (most recent call last): File "", line 1, in - NameError: name 'python' is not defined + NameError: name 'python3' is not defined It's because this command and other suggested commands in this tutorial are intended to be run in a *shell* (also called a *terminal* or From d45e1e998bc4b849dae59c40e73cb24018f1886e Mon Sep 17 00:00:00 2001 From: Hugo van Kemenade Date: Mon, 13 Mar 2023 19:35:43 +0200 Subject: [PATCH 0319/1072] Fix linkcheck (#1221) --- source/guides/analyzing-pypi-package-downloads.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/analyzing-pypi-package-downloads.rst b/source/guides/analyzing-pypi-package-downloads.rst index d13a14efe..9c2cffa34 100644 --- a/source/guides/analyzing-pypi-package-downloads.rst +++ b/source/guides/analyzing-pypi-package-downloads.rst @@ -343,7 +343,7 @@ References .. _public PyPI download statistics dataset: https://console.cloud.google.com/bigquery?p=bigquery-public-data&d=pypi&page=dataset .. _Google BigQuery: https://cloud.google.com/bigquery .. _BigQuery web UI: https://console.cloud.google.com/bigquery -.. _pypinfo: https://github.com/ofek/pypinfo/blob/master/README.rst +.. _pypinfo: https://github.com/ofek/pypinfo .. _google-cloud-bigquery: https://cloud.google.com/bigquery/docs/reference/libraries .. _pandas-gbq: https://pandas-gbq.readthedocs.io/en/latest/ .. _Pandas: https://pandas.pydata.org/ From 5cca66a312ca96ad4d10d2bc806864f63944b870 Mon Sep 17 00:00:00 2001 From: Henry Schreiner Date: Tue, 14 Mar 2023 15:21:44 -0700 Subject: [PATCH 0320/1072] chore: update name of PDM backend (#1220) * chore: update name of PDM backend Signed-off-by: Henry Schreiner * Update source/tutorials/packaging-projects.rst --------- Signed-off-by: Henry Schreiner --- source/tutorials/packaging-projects.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index 9a3e4c9cf..89e1d073d 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -155,8 +155,8 @@ Open :file:`pyproject.toml` and enter one of these ``[build-system]`` tables: .. code-block:: toml [build-system] - requires = ["pdm-pep517"] - build-backend = "pdm.pep517.api" + requires = ["pdm-backend"] + build-backend = "pdm.backend" - ``requires`` is a list of packages that are needed to build your package. You From fcecd11351b87d6238b2c0d83f097d9dc4399d9d Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Wed, 15 Mar 2023 16:34:18 -0500 Subject: [PATCH 0321/1072] Quote extras to guard shells with glob qualifiers (#1216) * Shells like zsh have glob qualifiers that will error if an extra is not quoted. While the glob qualifiers can be disabled, adding quotes guards against errors if people are copy-pasting or do not know that they can disable the behavior. * Use single quotes for Linux/Mac and use double quotes for Windows to follow existing style conventions. --- ...installing-using-pip-and-virtual-environments.rst | 4 ++-- source/tutorials/installing-packages.rst | 12 ++++++------ 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst index e43e20e27..174dbc8c7 100644 --- a/source/guides/installing-using-pip-and-virtual-environments.rst +++ b/source/guides/installing-using-pip-and-virtual-environments.rst @@ -292,13 +292,13 @@ specifying the extra in brackets: .. code-block:: bash - python3 -m pip install requests[security] + python3 -m pip install 'requests[security]' .. tab:: Windows .. code-block:: bat - py -m pip install requests[security] + py -m pip install "requests[security]" .. _extras: https://setuptools.readthedocs.io/en/latest/userguide/dependency_management.html#optional-dependencies diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst index e03e43732..6fd267112 100644 --- a/source/tutorials/installing-packages.rst +++ b/source/tutorials/installing-packages.rst @@ -653,17 +653,17 @@ you know publishes one, you can include it in the pip installation command: .. code-block:: bash - python3 -m pip install SomePackage[PDF] - python3 -m pip install SomePackage[PDF]==3.0 - python3 -m pip install -e .[PDF] # editable project in current directory + python3 -m pip install 'SomePackage[PDF]' + python3 -m pip install 'SomePackage[PDF]==3.0' + python3 -m pip install -e '.[PDF]' # editable project in current directory .. tab:: Windows .. code-block:: bat - py -m pip install SomePackage[PDF] - py -m pip install SomePackage[PDF]==3.0 - py -m pip install -e .[PDF] # editable project in current directory + py -m pip install "SomePackage[PDF]" + py -m pip install "SomePackage[PDF]==3.0" + py -m pip install -e ".[PDF]" # editable project in current directory ---- From 05dc55f28d975071b29ba9e9ce5232871e500122 Mon Sep 17 00:00:00 2001 From: Matthew Feickert Date: Wed, 15 Mar 2023 17:16:55 -0500 Subject: [PATCH 0322/1072] Quote guard version requirements for pip installs * As pointed out by Henry in PR 1216, adding quotes to version information on packages provides safeguards against common mistakes. Additionally this matches style with https://github.com/pypa/pip/pull/11842. --- .../installing-using-pip-and-virtual-environments.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst index 174dbc8c7..9d2e7ea06 100644 --- a/source/guides/installing-using-pip-and-virtual-environments.rst +++ b/source/guides/installing-using-pip-and-virtual-environments.rst @@ -245,13 +245,13 @@ a specific version of ``requests``: .. code-block:: bash - python3 -m pip install requests==2.18.4 + python3 -m pip install 'requests==2.18.4' .. tab:: Windows .. code-block:: bat - py -m pip install requests==2.18.4 + py -m pip install "requests==2.18.4" To install the latest ``2.x`` release of requests: @@ -259,13 +259,13 @@ To install the latest ``2.x`` release of requests: .. code-block:: bash - python3 -m pip install requests>=2.0.0,<3.0.0 + python3 -m pip install 'requests>=2.0.0,<3.0.0' .. tab:: Windows .. code-block:: bat - py -m pip install requests>=2.0.0,<3.0.0 + py -m pip install "requests>=2.0.0,<3.0.0" To install pre-release versions of packages, use the ``--pre`` flag: From 7f438b02d9cafd8d1ae549e275b66105beaa6712 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20Bidoul?= Date: Fri, 17 Mar 2023 21:45:08 +0100 Subject: [PATCH 0323/1072] Extract the Direct URL data structure into a standalone document (#1200) * Standalone spec of the direct URL data structure * Minor edits of the direct url data structure specification Minor edits so the text reads better as a standalone document. * Fix typo in direct-url-data-structure.rst Co-authored-by: Anderson Bravalheri --------- Co-authored-by: Pradyun Gedam Co-authored-by: Anderson Bravalheri --- .../direct-url-data-structure.rst | 290 ++++++++++++++++++ source/specifications/direct-url.rst | 258 +--------------- source/specifications/index.rst | 1 + 3 files changed, 294 insertions(+), 255 deletions(-) create mode 100644 source/specifications/direct-url-data-structure.rst diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst new file mode 100644 index 000000000..9ba703e9a --- /dev/null +++ b/source/specifications/direct-url-data-structure.rst @@ -0,0 +1,290 @@ + +.. _direct-url-data-structure: + +========================= +Direct URL Data Structure +========================= + +This document specifies a JSON-serializable abstract data structure that can represent +URLs to python projects and distribution artifacts such as VCS source trees, local +source trees, source distributions and wheels. + +The representation of the components of this data structure as a :rfc:`1738` URL +is not formally specified at time of writing. A common representation is the pip URL +format. Other examples are provided in :pep:`440`. + +.. contents:: Contents + :local: + +Specification +============= + +The Direct URL Data Structure MUST be a dictionary, serializable to JSON according to +:rfc:`8259`. + +It MUST contain at least two fields. The first one is ``url``, with +type ``string``. Depending on what ``url`` refers to, the second field MUST be +one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if +``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a +local directory). These info fields have a (possibly empty) subdictionary as +value, with the possible keys defined below. + +When persisted, ``url`` MUST be stripped of any sensitive authentication information, +for security reasons. + +The user:password section of the URL MAY however +be composed of environment variables, matching the following regular +expression:: + + \$\{[A-Za-z0-9-_]+\}(:\$\{[A-Za-z0-9-_]+\})? + +Additionally, the user:password section of the URL MAY be a +well-known, non security sensitive string. A typical example is ``git`` +in the case of an URL such as ``ssh://git@gitlab.com/user/repo``. + +VCS URLs +-------- + +When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present +as a dictionary with the following keys: + +- A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS + (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by + writing a PEP to amend this specification. + The ``url`` value MUST be compatible with the corresponding VCS, + so an installer can hand it off without transformation to a + checkout/download command of the VCS. +- A ``requested_revision`` key (type ``string``) MAY be present naming a + branch/tag/ref/commit/revision/etc (in a format compatible with the VCS). +- A ``commit_id`` key (type ``string``) MUST be present, containing the + exact commit/revision number that was/is to be installed. + If the VCS supports commit-hash + based revision identifiers, such commit-hash MUST be used as + ``commit_id`` in order to reference an immutable + version of the source code. + +Archive URLs +------------ + +When ``url`` refers to a source archive or a wheel, the ``archive_info`` key +MUST be present as a dictionary with the following keys: + +- A ``hashes`` key SHOULD be present as a dictionary mapping a hash name to a hex + encoded digest of the file. + + Multiple hashes can be included, and it is up to the consumer to decide what to do + with multiple hashes (it may validate all of them or a subset of them, or nothing at + all). + + These hash names SHOULD always be normalized to be lowercase. + + Any hash algorithm available via ``hashlib`` (specifically any that can be passed to + ``hashlib.new()`` and do not require additional parameters) can be used as a key for + the hashes dictionary. At least one secure algorithm from + ``hashlib.algorithms_guaranteed`` SHOULD always be included. At time of writing, + ``sha256`` specifically is recommended. + +- A deprecated ``hash`` key (type ``string``) MAY be present for backwards compatibility + purposes, with value ``=``. + +Producers of the data structure SHOULD emit the ``hashes`` key whether one or multiple +hashes are available. Producers SHOULD continue to emit the ``hash`` key in contexts +where they did so before, so as to keep backwards compatibility for existing clients. + +When both the ``hash`` and ``hashes`` keys are present, the hash represented in the +``hash`` key MUST also be present in the ``hashes`` dictionary, so consumers can +consider the ``hashes`` key only if it is present, and fall back to ``hash`` otherwise. + +Local directories +----------------- + +When ``url`` refers to a local directory, the ``dir_info`` key MUST be +present as a dictionary with the following key: + +- ``editable`` (type: ``boolean``): ``true`` if the distribution was/is to be installed + in editable mode, ``false`` otherwise. If absent, default to ``false``. + +When ``url`` refers to a local directory, it MUST have the ``file`` scheme and +be compliant with :rfc:`8089`. In +particular, the path component must be absolute. Symbolic links SHOULD be +preserved when making relative paths absolute. + +Projects in subdirectories +-------------------------- + +A top-level ``subdirectory`` field MAY be present containing a directory path, +relative to the root of the VCS repository, source archive or local directory, +to specify where ``pyproject.toml`` or ``setup.py`` is located. + +Registered VCS +============== + +This section lists the registered VCS's; expanded, VCS-specific information +on how to use the ``vcs``, ``requested_revision``, and other fields of +``vcs_info``; and in +some cases additional VCS-specific fields. +Tools MAY support other VCS's although it is RECOMMENDED to register +them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name +(lowercased). Additional fields that would be necessary to +support such VCS SHOULD be prefixed with the VCS command name. + +Git +--- + +Home page + + https://git-scm.com/ + +vcs command + + git + +``vcs`` field + + git + +``requested_revision`` field + + A tag name, branch name, Git ref, commit hash, shortened commit hash, + or other commit-ish. + +``commit_id`` field + + A commit hash (40 hexadecimal characters sha1). + +.. note:: + + Tools can use the ``git show-ref`` and ``git symbolic-ref`` commands + to determine if the ``requested_revision`` corresponds to a Git ref. + In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and + a ref beginning with ``refs/remotes/origin/`` after cloning corresponds + to a branch. + +Mercurial +--------- + +Home page + + https://www.mercurial-scm.org/ + +vcs command + + hg + +``vcs`` field + + hg + +``requested_revision`` field + + A tag name, branch name, changeset ID, shortened changeset ID. + +``commit_id`` field + + A changeset ID (40 hexadecimal characters). + +Bazaar +------ + +Home page + + https://bazaar.canonical.com + +vcs command + + bzr + +``vcs`` field + + bzr + +``requested_revision`` field + + A tag name, branch name, revision id. + +``commit_id`` field + + A revision id. + +Subversion +---------- + +Home page + + https://subversion.apache.org/ + +vcs command + + svn + +``vcs`` field + + svn + +``requested_revision`` field + + ``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. + In Subversion, branch or tag is part of ``url``. + +``commit_id`` field + + Since Subversion does not support globally unique identifiers, + this field is the Subversion revision number in the corresponding + repository. + +Examples +======== + +Source archive: + +.. code:: + + { + "url": "https://github.com/pypa/pip/archive/1.3.1.zip", + "archive_info": { + "hashes": { + "sha256": "2dc6b5a470a1bde68946f263f1af1515a2574a150a30d6ce02c6ff742fcc0db8" + } + } + } + +Git URL with tag and commit-hash: + +.. code:: + + { + "url": "https://github.com/pypa/pip.git", + "vcs_info": { + "vcs": "git", + "requested_revision": "1.3.1", + "commit_id": "7921be1537eac1e97bc40179a57f0349c2aee67d" + } + } + +Local directory: + +.. code:: + + { + "url": "file:///home/user/project", + "dir_info": {} + } + +Local directory in editable mode: + +.. code:: + + { + "url": "file:///home/user/project", + "dir_info": { + "editable": true + } + } + +History +======= + +- March 2020: this data structure was originally specified as part of the + ``direct_url.json`` metadata file in :pep:`610` and is formally documented here. +- January 2023: Added the ``archive_info.hashes`` key + ([discussion](https://discuss.python.org/t/22299)). diff --git a/source/specifications/direct-url.rst b/source/specifications/direct-url.rst index 7a1560e87..aa9a48e9b 100644 --- a/source/specifications/direct-url.rst +++ b/source/specifications/direct-url.rst @@ -23,86 +23,8 @@ specifying a direct URL reference (including a VCS URL). This file MUST NOT be created when installing a distribution from an other type of requirement (i.e. name plus version specifier). -This JSON file MUST be a dictionary, compliant with :rfc:`8259` and UTF-8 encoded. - -If present, it MUST contain at least two fields. The first one is ``url``, with -type ``string``. Depending on what ``url`` refers to, the second field MUST be -one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if -``url`` is a source archives or a wheel), or ``dir_info`` (if ``url`` is a -local directory). These info fields have a (possibly empty) subdictionary as -value, with the possible keys defined below. - -``url`` MUST be stripped of any sensitive authentication information, -for security reasons. - -The user:password section of the URL MAY however -be composed of environment variables, matching the following regular -expression:: - - \$\{[A-Za-z0-9-_]+\}(:\$\{[A-Za-z0-9-_]+\})? - -Additionally, the user:password section of the URL MAY be a -well-known, non security sensitive string. A typical example is ``git`` -in the case of an URL such as ``ssh://git@gitlab.com/user/repo``. - -When ``url`` refers to a VCS repository, the ``vcs_info`` key MUST be present -as a dictionary with the following keys: - -- A ``vcs`` key (type ``string``) MUST be present, containing the name of the VCS - (i.e. one of ``git``, ``hg``, ``bzr``, ``svn``). Other VCS's SHOULD be registered by - writing a PEP to amend this specification. - The ``url`` value MUST be compatible with the corresponding VCS, - so an installer can hand it off without transformation to a - checkout/download command of the VCS. -- A ``requested_revision`` key (type ``string``) MAY be present naming a - branch/tag/ref/commit/revision/etc (in a format compatible with the VCS) - to install. -- A ``commit_id`` key (type ``string``) MUST be present, containing the - exact commit/revision number that was installed. - If the VCS supports commit-hash - based revision identifiers, such commit-hash MUST be used as - ``commit_id`` in order to reference the immutable - version of the source code that was installed. - -When ``url`` refers to a source archive or a wheel, the ``archive_info`` key -MUST be present as a dictionary with the following keys: - -- A ``hashes`` key SHOULD be present as a dictionary mapping a hash name to a hex - encoded digest of the file. - - Multiple hashes can be included, and it is up to the consumer to decide what to do - with multiple hashes (it may validate all of them or a subset of them, or nothing at - all). - - These hash names SHOULD always be normalized to be lowercase. - - Any hash algorithm available via ``hashlib`` (specifically any that can be passed to - ``hashlib.new()`` and do not require additional parameters) can be used as a key for - the hashes dictionary. At least one secure algorithm from - ``hashlib.algorithms_guaranteed`` SHOULD always be included. At time of writing, - ``sha256`` specifically is recommended. - -- A deprecated ``hash`` key (type ``string``) MAY be present for backwards compatibility - purposes, with value ``=``. - -Producers of the data structure SHOULD emit the ``hashes`` key whether one or multiple -hashes are available. Producers SHOULD continue to emit the ``hash`` key in contexts -where they did so before, so as to keep backwards compatibility for existing clients. - -When both the ``hash`` and ``hashes`` keys are present, the hash represented in the -``hash`` key MUST also be present in the ``hashes`` dictionary, so consumers can -consider the ``hashes`` key only if it is present, and fall back to ``hash`` otherwise. - -When ``url`` refers to a local directory, the ``dir_info`` key MUST be -present as a dictionary with the following key: - -- ``editable`` (type: ``boolean``): ``true`` if the distribution was installed - in editable mode, ``false`` otherwise. If absent, default to ``false``. - -When ``url`` refers to a local directory, it MUST have the ``file`` sheme and -be compliant with :rfc:`8089`. In -particular, the path component must be absolute. Symbolic links SHOULD be -preserved when making relative paths absolute. +This JSON file MUST be a UTF-8 encoded, :rfc:`8259` compliant, serialization of the +:doc:`direct-url-data-structure`. .. note:: @@ -111,10 +33,6 @@ preserved when making relative paths absolute. therefore MUST NOT output any VCS related information (such as ``vcs_info``) in :file:`direct_url.json`. -A top-level ``subdirectory`` field MAY be present containing a directory path, -relative to the root of the VCS repository, source archive or local directory, -to specify where ``pyproject.toml`` or ``setup.py`` is located. - .. note:: As a general rule, installers should as much as possible preserve the @@ -124,177 +42,9 @@ to specify where ``pyproject.toml`` or ``setup.py`` is located. provided in the requested URL as faithfully as possible. This information is however *enriched* with more precise data, such as ``commit_id``. -Registered VCS -============== - -This section lists the registered VCS's; expanded, VCS-specific information -on how to use the ``vcs``, ``requested_revision``, and other fields of -``vcs_info``; and in -some cases additional VCS-specific fields. -Tools MAY support other VCS's although it is RECOMMENDED to register -them by writing a PEP to amend this specification. The ``vcs`` field SHOULD be the command name -(lowercased). Additional fields that would be necessary to -support such VCS SHOULD be prefixed with the VCS command name. - -Git ---- - -Home page - - https://git-scm.com/ - -vcs command - - git - -``vcs`` field - - git - -``requested_revision`` field - - A tag name, branch name, Git ref, commit hash, shortened commit hash, - or other commit-ish. - -``commit_id`` field - - A commit hash (40 hexadecimal characters sha1). - -.. note:: - - Installers can use the ``git show-ref`` and ``git symbolic-ref`` commands - to determine if the ``requested_revision`` corresponds to a Git ref. - In turn, a ref beginning with ``refs/tags/`` corresponds to a tag, and - a ref beginning with ``refs/remotes/origin/`` after cloning corresponds - to a branch. - -Mercurial ---------- - -Home page - - https://www.mercurial-scm.org/ - -vcs command - - hg - -``vcs`` field - - hg - -``requested_revision`` field - - A tag name, branch name, changeset ID, shortened changeset ID. - -``commit_id`` field - - A changeset ID (40 hexadecimal characters). - -Bazaar ------- - -Home page - - https://bazaar.canonical.com - -vcs command - - bzr - -``vcs`` field - - bzr - -``requested_revision`` field - - A tag name, branch name, revision id. - -``commit_id`` field - - A revision id. - -Subversion ----------- - -Home page - - https://subversion.apache.org/ - -vcs command - - svn - -``vcs`` field - - svn - -``requested_revision`` field - - ``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option. - In Subversion, branch or tag is part of ``url``. - -``commit_id`` field - - Since Subversion does not support globally unique identifiers, - this field is the Subversion revision number in the corresponding - repository. - -Examples -======== - -Example direct_url.json ------------------------ - -Source archive: - -.. code:: - - { - "url": "https://github.com/pypa/pip/archive/1.3.1.zip", - "archive_info": { - "hashes": { - "sha256": "2dc6b5a470a1bde68946f263f1af1515a2574a150a30d6ce02c6ff742fcc0db8" - } - } - } - -Git URL with tag and commit-hash: - -.. code:: - - { - "url": "https://github.com/pypa/pip.git", - "vcs_info": { - "vcs": "git", - "requested_revision": "1.3.1", - "commit_id": "7921be1537eac1e97bc40179a57f0349c2aee67d" - } - } - -Local directory: - -.. code:: - - { - "url": "file:///home/user/project", - "dir_info": {} - } - -Local directory installed in editable mode: - -.. code:: - - { - "url": "file:///home/user/project", - "dir_info": { - "editable": true - } - } - Example pip commands and their effect on direct_url.json --------------------------------------------------------- +======================================================== Commands that generate a ``direct_url.json``: @@ -319,5 +69,3 @@ History - March 2020: the ``direct_url.json`` metadata file was originally specified in :pep:`610` and is formally documented here. -- January 2023: Added the ``archive_info.hashes`` key - (`discussion `__). diff --git a/source/specifications/index.rst b/source/specifications/index.rst index f4a290e29..4f622d845 100644 --- a/source/specifications/index.rst +++ b/source/specifications/index.rst @@ -32,6 +32,7 @@ Package Installation Environment Metadata recording-installed-packages entry-points direct-url + direct-url-data-structure virtual-environments externally-managed-environments From 60a494c3bf7911a0c3ac4aad0f3438fab5765221 Mon Sep 17 00:00:00 2001 From: Moshe Kaplan Date: Wed, 22 Mar 2023 15:17:29 -0400 Subject: [PATCH 0324/1072] repository_url is deprecated, use repository-url repository_url is deprecated, use repository-url instead , per https://github.com/pypa/gh-action-pypi-publish/blob/a3a3bafbb3e5a75a854ae1bc53ae128cf22c4af4/action.yml#L15 --- .../guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index ebbc70c28..c378a4298 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -32,7 +32,7 @@ jobs: uses: pypa/gh-action-pypi-publish@release/v1 with: password: ${{ secrets.TEST_PYPI_API_TOKEN }} - repository_url: https://test.pypi.org/legacy/ + repository-url: https://test.pypi.org/legacy/ - name: Publish distribution 📦 to PyPI if: startsWith(github.ref, 'refs/tags') uses: pypa/gh-action-pypi-publish@release/v1 From 88ce3aa297f37ce7e61af447507c079d4ac0d839 Mon Sep 17 00:00:00 2001 From: Henry Schreiner Date: Tue, 21 Jun 2022 16:16:24 -0400 Subject: [PATCH 0325/1072] chore: update GHA guide Signed-off-by: Henry Schreiner --- .../github-actions-ci-cd-sample/publish-to-test-pypi.yml | 8 ++++---- ...tion-releases-using-github-actions-ci-cd-workflows.rst | 6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index c378a4298..da6e213cf 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -8,11 +8,11 @@ jobs: runs-on: ubuntu-latest steps: - - uses: actions/checkout@master - - name: Set up Python 3.10 - uses: actions/setup-python@v3 + - uses: actions/checkout@v3 + - name: Set up Python + uses: actions/setup-python@v4 with: - python-version: "3.10" + python-version: "3.x" - name: Install pypa/build run: >- python -m diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index 730098587..080d74786 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -14,6 +14,8 @@ It will use the `pypa/gh-action-pypi-publish GitHub Action`_. This guide *assumes* that you already have a project that you know how to build distributions for and *it lives on GitHub*. + This guide also assumes you have a pure Python project. If you + have binary compoents, check out :ref:`cibuildwheel`. Saving credentials on GitHub ============================ @@ -94,9 +96,7 @@ This will download your repository into the CI runner and then install and activate Python 3.10. And now we can build dists from source. In this example, we'll -use ``build`` package, assuming that your project has a -``pyproject.toml`` properly set up (see -:pep:`517`/:pep:`518`). +use ``build`` package. .. tip:: From a4f8a0e8be9413e43ce55ff1e53da1a0c0b9f36c Mon Sep 17 00:00:00 2001 From: Henry Schreiner Date: Thu, 23 Jun 2022 14:30:50 -0400 Subject: [PATCH 0326/1072] fix: partial review update Signed-off-by: Henry Schreiner --- ...es-using-github-actions-ci-cd-workflows.rst | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index 080d74786..412ee25d8 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -12,10 +12,10 @@ It will use the `pypa/gh-action-pypi-publish GitHub Action`_. .. attention:: - This guide *assumes* that you already have a project that - you know how to build distributions for and *it lives on GitHub*. - This guide also assumes you have a pure Python project. If you - have binary compoents, check out :ref:`cibuildwheel`. + This guide *assumes* that you already have a project that you know how to + build distributions for and *it lives on GitHub*. This guide also avoids + details of building platform specific projects. If you have binary + components, check out :ref:`cibuildwheel`'s GitHub Action examples. Saving credentials on GitHub ============================ @@ -102,13 +102,15 @@ use ``build`` package. You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the - ``dist/`` folder. + ``dist/`` folder. You can even use ``actions/upload-artifact`` and + ``actions/download-artifact`` to tranfer files between jobs or make them + accessable for download from the web CI interface. So add this to the steps list: .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml - :start-after: version: "3.10" + :start-after: version: "3.x" :end-before: Actually publish to PyPI/TestPyPI @@ -124,7 +126,9 @@ Finally, add the following steps at the end: These two steps use the `pypa/gh-action-pypi-publish`_ GitHub Action: the first one uploads contents of the ``dist/`` folder into TestPyPI unconditionally and the second does that to -PyPI, but only if the current commit is tagged. +PyPI, but only if the current commit is tagged. It is recommended +you use the latest release tag; a tool like GitHub's dependabot can keep +these updated regularly. That's all, folks! From 73c36d5045ac683f63427ccaba883dfcce24e225 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Tue, 28 Mar 2023 14:08:50 -0700 Subject: [PATCH 0327/1072] Clarify that static metadata include external data that is referenced (#1232) --- source/specifications/declaring-project-metadata.rst | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/source/specifications/declaring-project-metadata.rst b/source/specifications/declaring-project-metadata.rst index 83fac600d..a8c4479c8 100644 --- a/source/specifications/declaring-project-metadata.rst +++ b/source/specifications/declaring-project-metadata.rst @@ -15,9 +15,11 @@ Specification There are two kinds of metadata: *static* and *dynamic*. Static metadata is specified in the ``pyproject.toml`` file directly and -cannot be specified or changed by a tool. Dynamic metadata is listed -via the ``dynamic`` key (defined later in this specification) and -represents metadata that a tool will later provide. +cannot be specified or changed by a tool (this includes data +*referred* to by the metadata, e.g. the contents of files referenced +by the metadata). Dynamic metadata is listed via the ``dynamic`` key +(defined later in this specification) and represents metadata that a +tool will later provide. The keys defined in this specification MUST be in a table named ``[project]`` in ``pyproject.toml``. No tools may add keys to this From ef94b123ef6b3be064a375578e55a89842f44dec Mon Sep 17 00:00:00 2001 From: Dan Date: Tue, 4 Apr 2023 09:01:21 -0400 Subject: [PATCH 0328/1072] fixed typo (#1234) --- source/guides/creating-and-discovering-plugins.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/creating-and-discovering-plugins.rst b/source/guides/creating-and-discovering-plugins.rst index 386b09c87..f4b36f735 100644 --- a/source/guides/creating-and-discovering-plugins.rst +++ b/source/guides/creating-and-discovering-plugins.rst @@ -41,7 +41,7 @@ then ``discovered_plugins`` would be: .. code-block:: python { - 'flask_sqlachemy': , + 'flask_sqlalchemy': , 'flask_talisman': , } From 5c4820feed14237e0af85baf9235e956b16b81c9 Mon Sep 17 00:00:00 2001 From: sinoroc <5529267+sinoroc@users.noreply.github.com> Date: Thu, 27 Apr 2023 11:59:00 +0200 Subject: [PATCH 0329/1072] Fix link to specifications page on `pypa.io` (#1239) GitHub: fixes https://github.com/pypa/packaging.python.org/issues/1238 --- source/specifications/index.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/index.rst b/source/specifications/index.rst index 4f622d845..d7b787b47 100644 --- a/source/specifications/index.rst +++ b/source/specifications/index.rst @@ -6,7 +6,7 @@ PyPA specifications This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on -`pypa.io `__. +`pypa.io `__. Package Distribution Metadata From 0b9086b7a1b91fd0281df408930c9fcff14f9885 Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Thu, 27 Apr 2023 06:24:54 -0400 Subject: [PATCH 0330/1072] Fix broken Software Collections link (#1242) --- source/guides/installing-using-linux-tools.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/installing-using-linux-tools.rst b/source/guides/installing-using-linux-tools.rst index c91ce7924..c67367762 100644 --- a/source/guides/installing-using-linux-tools.rst +++ b/source/guides/installing-using-linux-tools.rst @@ -90,7 +90,7 @@ To install pip, wheel, and setuptools, in a parallel, non-system environment * For Redhat, see here: https://developers.redhat.com/products/softwarecollections/overview - * For CentOS, see here: https://www.softwarecollections.org/en/ + * For CentOS, see here: https://github.com/sclorg Be aware that collections may not contain the most recent versions. From 66b3a2b051521969aad3f55b6842c0e7301489f6 Mon Sep 17 00:00:00 2001 From: Chris Pryer <14341145+cnpryer@users.noreply.github.com> Date: Fri, 28 Apr 2023 16:47:52 -0400 Subject: [PATCH 0331/1072] Fix typos in overview (#1243) --- source/overview.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/overview.rst b/source/overview.rst index 7031327b2..a19d5d2c0 100644 --- a/source/overview.rst +++ b/source/overview.rst @@ -300,7 +300,7 @@ Bringing your own Python executable Computing as we know it is defined by the ability to execute programs. Every operating system natively supports one or more formats -of program they can natively execute. +of programs they can natively execute. There are many techniques and technologies which turn your Python program into one of these formats, most of which involve embedding the @@ -357,7 +357,7 @@ mature approach, widespread in data center environments. These techniques are mostly reserved for larger scale deployments in data centers, though certain complex applications can benefit from -this packaging. Technologies are Python agnostic, and include: +this packaging. The technologies are Python agnostic, and include: * `Vagrant `_ * `VHD `_, `AMI `_, and :doc:`other formats ` From 299428ba4255f0660d4d4c69e3dc1bf963648254 Mon Sep 17 00:00:00 2001 From: chrysle Date: Sun, 30 Apr 2023 12:10:31 +0200 Subject: [PATCH 0332/1072] Clarified pip `--upgrade` option and fixed output (#1240) --- .../guides/installing-stand-alone-command-line-tools.rst | 8 +++++--- source/tutorials/creating-documentation.rst | 4 ++-- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/source/guides/installing-stand-alone-command-line-tools.rst b/source/guides/installing-stand-alone-command-line-tools.rst index 958699d42..78e18fccb 100644 --- a/source/guides/installing-stand-alone-command-line-tools.rst +++ b/source/guides/installing-stand-alone-command-line-tools.rst @@ -66,8 +66,10 @@ For example: \ ^__^ (oo)\_______ - (__)\ )\/ ||----w | + (__)\ )\/ || || + ||----w | + To see a list of packages installed with pipx and which applications are available, use ``pipx list``: @@ -103,14 +105,14 @@ pipx can be upgraded or uninstalled with pip: .. code-block:: bash - python3 -m pip install -U pipx + python3 -m pip install --upgrade pipx python3 -m pip uninstall pipx .. tab:: Windows .. code-block:: bat - py -m pip install -U pipx + py -m pip install --upgrade pipx py -m pip uninstall pipx pipx also allows you to install and run the latest version of an application diff --git a/source/tutorials/creating-documentation.rst b/source/tutorials/creating-documentation.rst index de47c7013..26cffb383 100644 --- a/source/tutorials/creating-documentation.rst +++ b/source/tutorials/creating-documentation.rst @@ -18,13 +18,13 @@ Use ``pip`` to install Sphinx: .. code-block:: bash - python3 -m pip install -U sphinx + python3 -m pip install --upgrade sphinx .. tab:: Windows .. code-block:: bat - py -m pip install -U sphinx + py -m pip install --upgrade sphinx For other installation methods, see this :doc:`installation guide ` by Sphinx. From 48cf2266dd11188a43c1cb78fd1b329fe96213b5 Mon Sep 17 00:00:00 2001 From: chrysle Date: Sat, 6 May 2023 22:56:10 +0200 Subject: [PATCH 0333/1072] Replace link to bottle project page with pypi (#1247) --- .readthedocs.yaml | 6 +++++- source/overview.rst | 2 +- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/.readthedocs.yaml b/.readthedocs.yaml index fe012dd98..90e9a9bbc 100644 --- a/.readthedocs.yaml +++ b/.readthedocs.yaml @@ -9,7 +9,11 @@ sphinx: # https://github.com/pyca/cryptography/issues/5863#issuecomment-792343136 builder: dirhtml +build: + os: ubuntu-22.04 + tools: + python: "3.11" + python: - version: 3.8 install: - requirements: requirements.txt diff --git a/source/overview.rst b/source/overview.rst index a19d5d2c0..daf7130eb 100644 --- a/source/overview.rst +++ b/source/overview.rst @@ -67,7 +67,7 @@ This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py -`_ and :doc:`boltons +`_ and :doc:`boltons `. However, this pattern won't scale for projects that consist of From 2d171a907abf0cb5b0871f28e72a1e6d65d4f44f Mon Sep 17 00:00:00 2001 From: Hugo van Kemenade Date: Mon, 8 May 2023 13:23:23 +0300 Subject: [PATCH 0334/1072] CI: Don't run cron for forks (#1248) * Don't run cron for forks * Simplify logic Co-authored-by: Brian Rutledge --------- Co-authored-by: Brian Rutledge --- .github/workflows/test.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index 245c71833..b0fc5300c 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -13,6 +13,7 @@ concurrency: jobs: build: name: ${{ matrix.noxenv }} + if: ${{ github.repository_owner == 'pypa' || github.event_name != 'schedule' }} runs-on: ubuntu-latest strategy: matrix: From 9b83ad0851eef3c5e66c76fefbe8899150382229 Mon Sep 17 00:00:00 2001 From: chrysle Date: Mon, 8 May 2023 16:20:45 +0200 Subject: [PATCH 0335/1072] Homepage of bottlepy is running again --- source/overview.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/overview.rst b/source/overview.rst index daf7130eb..a19d5d2c0 100644 --- a/source/overview.rst +++ b/source/overview.rst @@ -67,7 +67,7 @@ This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py -`_ and :doc:`boltons +`_ and :doc:`boltons `. However, this pattern won't scale for projects that consist of From b2bf39b8bc8811f8c39d673728c850e9757e19c2 Mon Sep 17 00:00:00 2001 From: chrysle Date: Mon, 8 May 2023 20:46:07 +0200 Subject: [PATCH 0336/1072] Configured intersphinx mapping and fixed inventory --- source/conf.py | 7 ++++--- source/overview.rst | 4 ++-- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/source/conf.py b/source/conf.py index d92aa8d0d..7ff60c18c 100644 --- a/source/conf.py +++ b/source/conf.py @@ -397,6 +397,7 @@ # Example configuration for intersphinx: refer to the Python standard library. intersphinx_mapping = { 'boltons': ('https://boltons.readthedocs.io/en/latest/', None), + 'bottle': ('https://bottlepy.org/docs/dev/', None), 'build': ('https://pypa-build.readthedocs.io/en/stable/', None), 'cffi': ('https://cffi.readthedocs.io/en/latest/', None), 'conda': ('https://conda.io/en/latest/', None), @@ -407,7 +408,7 @@ 'nox': ('https://nox.thea.codes/en/latest/', None), 'openstack': ('https://docs.openstack.org/glance/latest/', None), 'packaging': ('https://packaging.pypa.io/en/latest/', None), - 'packaging.python.org': ('https://packaging.python.org/', None), + 'packaging.python.org': ('https://packaging.python.org/en/latest/', None), 'pip': ('https://pip.pypa.io/en/latest/', None), 'pipenv': ('https://pipenv.pypa.io/en/latest/', None), 'piwheels': ('https://piwheels.readthedocs.io/en/latest/', None), @@ -416,10 +417,10 @@ 'pypa': ('https://www.pypa.io/en/latest/', None), 'python': ('https://docs.python.org/3', None), 'python-guide': ('https://docs.python-guide.org', None), - 'setuptools': ('https://setuptools.readthedocs.io/en/latest/', None), + 'setuptools': ('https://setuptools.pypa.io/en/latest/', None), 'spack': ('https://spack.readthedocs.io/en/latest/', None), 'sphinx': ('https://www.sphinx-doc.org/en/master', None), - 'tox': ('https://tox.readthedocs.io/en/latest/', None), + 'tox': ('https://tox.wiki/en/latest/', None), 'twine': ('https://twine.readthedocs.io/en/stable/', None), 'virtualenv': ('https://virtualenv.pypa.io/en/stable/', None), } diff --git a/source/overview.rst b/source/overview.rst index a19d5d2c0..f0f7cdbce 100644 --- a/source/overview.rst +++ b/source/overview.rst @@ -66,8 +66,8 @@ library. This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python -libraries that offer this as an option, such as `bottle.py -`_ and :doc:`boltons +libraries that offer this as an option, such as +:doc:`bottle.py` and :doc:`boltons `. However, this pattern won't scale for projects that consist of From 305aba01bcc85039608dfa3eeb8df10296104c2c Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Sat, 20 May 2023 06:13:30 -0400 Subject: [PATCH 0337/1072] Fix failing Bazaar URL (#1254) --- source/specifications/direct-url-data-structure.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst index 9ba703e9a..2fa567a62 100644 --- a/source/specifications/direct-url-data-structure.rst +++ b/source/specifications/direct-url-data-structure.rst @@ -188,7 +188,7 @@ Bazaar Home page - https://bazaar.canonical.com + _`https://bazaar.canonical.com` *(Not responding as of 5/2023)* vcs command From 7815c8005e3af16824e5912ee293d691553eb8f2 Mon Sep 17 00:00:00 2001 From: chrysle Date: Sat, 20 May 2023 12:20:02 +0200 Subject: [PATCH 0338/1072] Improve heading and remove space in commands (#1241) * Removed space * Improved heading * Added anchor for changed heading --------- Co-authored-by: Brian Rutledge --- source/guides/dropping-older-python-versions.rst | 4 ++-- source/guides/installing-using-linux-tools.rst | 7 +++++-- .../installing-using-pip-and-virtual-environments.rst | 2 -- 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/source/guides/dropping-older-python-versions.rst b/source/guides/dropping-older-python-versions.rst index 080f7282b..ecb4e59c6 100644 --- a/source/guides/dropping-older-python-versions.rst +++ b/source/guides/dropping-older-python-versions.rst @@ -63,13 +63,13 @@ Steps: .. code-block:: bash - python3 -m pip install  --upgrade setuptools twine + python3 -m pip install --upgrade setuptools twine .. tab:: Windows .. code-block:: bat - py -m pip install  --upgrade setuptools twine + py -m pip install --upgrade setuptools twine `setuptools` version should be above 24.0.0. diff --git a/source/guides/installing-using-linux-tools.rst b/source/guides/installing-using-linux-tools.rst index c67367762..772bbfcbc 100644 --- a/source/guides/installing-using-linux-tools.rst +++ b/source/guides/installing-using-linux-tools.rst @@ -114,8 +114,11 @@ openSUSE sudo zypper install python3-pip python3-setuptools python3-wheel -Debian/Ubuntu -~~~~~~~~~~~~~ + +.. _debian-ubuntu: + +Debian/Ubuntu and derivatives +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Firstly, update and refresh repository lists by running this command: diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst index 9d2e7ea06..287c059f5 100644 --- a/source/guides/installing-using-pip-and-virtual-environments.rst +++ b/source/guides/installing-using-pip-and-virtual-environments.rst @@ -31,7 +31,6 @@ installed. .. code-block:: bash python3 -m pip install --user --upgrade pip - python3 -m pip --version Afterwards, you should have the latest version of pip installed in your @@ -51,7 +50,6 @@ installed. .. code-block:: bat py -m pip install --upgrade pip - py -m pip --version Afterwards, you should have the latest version of pip: From fd9c6f13a39e019fb3e394b15b882baa4af36c85 Mon Sep 17 00:00:00 2001 From: Chris Kuehl Date: Sat, 20 May 2023 05:22:00 -0500 Subject: [PATCH 0339/1072] Replace outdated reference to Python 3.10 as the latest 3.x release (#1251) Co-authored-by: Brian Rutledge --- ...stribution-releases-using-github-actions-ci-cd-workflows.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index 412ee25d8..8945821cb 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -93,7 +93,7 @@ Then, add the following under the ``build-n-publish`` section: :end-before: Install pypa/build This will download your repository into the CI runner and then -install and activate Python 3.10. +install and activate the newest available Python 3 release. And now we can build dists from source. In this example, we'll use ``build`` package. From 4d3825ad2a8c80e9263f6387622dc52e79082366 Mon Sep 17 00:00:00 2001 From: Jeff Hale Date: Sat, 20 May 2023 06:25:24 -0400 Subject: [PATCH 0340/1072] fix typo and improve grammar in analyzing-pypi-package-downloads (#1237) Co-authored-by: Brian Rutledge --- source/guides/analyzing-pypi-package-downloads.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/guides/analyzing-pypi-package-downloads.rst b/source/guides/analyzing-pypi-package-downloads.rst index 9c2cffa34..debe62ce5 100644 --- a/source/guides/analyzing-pypi-package-downloads.rst +++ b/source/guides/analyzing-pypi-package-downloads.rst @@ -94,7 +94,7 @@ Useful queries Run queries in the `BigQuery web UI`_ by clicking the "Compose query" button. -Note that the rows are stored in a partitioned, which helps +Note that the rows are stored in a partitioned table, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the ``timestamp`` column. @@ -121,7 +121,7 @@ The following query counts the total number of downloads for the project | 26190085 | +---------------+ -To only count downloads from pip, filter on the ``details.installer.name`` +To count downloads from pip only, filter on the ``details.installer.name`` column. :: From 0a78421e14cea2f310616da9a1d9f44330b01d89 Mon Sep 17 00:00:00 2001 From: sinoroc <5529267+sinoroc@users.noreply.github.com> Date: Sat, 20 May 2023 12:27:43 +0200 Subject: [PATCH 0341/1072] Fix or replace references to PEP 427 (#1229) PEP 427 is about the binary distribution format *wheel*. The full standard specification is available in the guide so we should link to it instead of the PEP. The PEP is rather a historical document, PEPs are part of the process, they are not the specification document. Co-authored-by: Brian Rutledge --- source/discussions/wheel-vs-egg.rst | 8 +++++--- source/glossary.rst | 4 +++- source/specifications/binary-distribution-format.rst | 2 ++ source/specifications/platform-compatibility-tags.rst | 2 +- 4 files changed, 11 insertions(+), 5 deletions(-) diff --git a/source/discussions/wheel-vs-egg.rst b/source/discussions/wheel-vs-egg.rst index 8368fd2c0..9e1bcf3dc 100644 --- a/source/discussions/wheel-vs-egg.rst +++ b/source/discussions/wheel-vs-egg.rst @@ -17,7 +17,9 @@ Distribution>` and :term:`binary ` packaging for Python. Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`. -* :term:`Wheel` has an :pep:`official PEP <427>`. :term:`Egg` did not. +* :term:`Wheel` has an :doc:`official standard specification + `. + :term:`Egg` did not. * :term:`Wheel` is a :term:`distribution ` format, i.e a packaging format. [1]_ :term:`Egg` was both a distribution format and a runtime @@ -45,5 +47,5 @@ Here's a breakdown of the important differences between :term:`Wheel` and :term: ---- .. [1] Circumstantially, in some cases, wheels can be used as an importable - runtime format, although :pep:`this is not officially supported at this time - <427#is-it-possible-to-import-python-code-directly-from-a-wheel-file>`. + runtime format, although :ref:`this is not officially supported at this time + `. diff --git a/source/glossary.rst b/source/glossary.rst index 7eaeef6bc..2cbde7bed 100644 --- a/source/glossary.rst +++ b/source/glossary.rst @@ -237,7 +237,9 @@ Glossary Wheel - A :term:`Built Distribution` format introduced by :pep:`427`, + A :term:`Built Distribution` format introduced by an official + :doc:`standard specification + `, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`. diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst index 277792658..317626b18 100644 --- a/source/specifications/binary-distribution-format.rst +++ b/source/specifications/binary-distribution-format.rst @@ -409,6 +409,8 @@ What's the deal with "purelib" vs. "platlib"? be at the root with the appropriate setting given for "Root-is-purelib". +.. _binary-distribution-format-import-wheel: + Is it possible to import Python code directly from a wheel file? ---------------------------------------------------------------- diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst index c7c9812f1..5ef47f9af 100644 --- a/source/specifications/platform-compatibility-tags.rst +++ b/source/specifications/platform-compatibility-tags.rst @@ -274,7 +274,7 @@ Why not use special character rather than ``.`` or ``-``? in some contexts (for example, ``+`` must be quoted in URLs, ``~`` is used to denote the user's home directory in POSIX), or because the advantages weren't sufficiently compelling to justify changing the - existing reference implementation for the wheel format defined in :pep:427 + existing reference implementation for the wheel format defined in :pep:`427` (for example, using ``,`` rather than ``.`` to separate components in a compressed tag). From f65104c7ae51d4e3ac48a971fe06a43ffead00f2 Mon Sep 17 00:00:00 2001 From: sinoroc <5529267+sinoroc@users.noreply.github.com> Date: Sat, 20 May 2023 12:34:45 +0200 Subject: [PATCH 0342/1072] Remove reference to SemVer to justify upper bound (#1224) GitHub: fixes https://github.com/pypa/packaging.python.org/issues/1223 Co-authored-by: Brian Rutledge --- source/discussions/install-requires-vs-requirements.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/source/discussions/install-requires-vs-requirements.rst b/source/discussions/install-requires-vs-requirements.rst index 95578bca8..418785c9b 100644 --- a/source/discussions/install-requires-vs-requirements.rst +++ b/source/discussions/install-requires-vs-requirements.rst @@ -38,8 +38,9 @@ v2 of 'B', so it would be like so: 'B>=2' ] -It may also be known that project A follows semantic versioning, and that v2 of -'A' will indicate a break in compatibility, so it makes sense to not allow v2: +It may also be known that project 'A' introduced a change in its v2 +that breaks the compatibility of your project with v2 of 'A' and later, +so it makes sense to not allow v2: :: From 26b65e6b29ac0ddad02a1dc8cd6d509cd7cc2ccf Mon Sep 17 00:00:00 2001 From: Savannah Ostrowski Date: Sat, 20 May 2023 03:59:39 -0700 Subject: [PATCH 0343/1072] Update extras example to use unioned dependencies (#1244) Co-authored-by: Brian Rutledge --- source/specifications/dependency-specifiers.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst index a5bc52bc7..43b362109 100644 --- a/source/specifications/dependency-specifiers.rst +++ b/source/specifications/dependency-specifiers.rst @@ -147,7 +147,7 @@ many extras as they wish, and each extra results in the declaration of additional dependencies of the distribution **when** the extra is used in a dependency specification. For instance:: - requests[security] + requests[security,tests] Extras union in the dependencies they define with the dependencies of the distribution they are attached to. The example above would result in requests From 9b0df6962a18c20c30da578f226e394ea6a70bf8 Mon Sep 17 00:00:00 2001 From: Marti Raudsepp Date: Sat, 20 May 2023 14:58:14 +0300 Subject: [PATCH 0344/1072] Project URLs keys should be capitalized in pyproject.toml (#1250) In pretty much all other places, the project URLs mapping keys are capitalized, including the "setuptools" guide page. Update `pyproject.toml` too for consistency and current practices. Co-authored-by: Brian Rutledge --- .../declaring-project-metadata.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/source/specifications/declaring-project-metadata.rst b/source/specifications/declaring-project-metadata.rst index a8c4479c8..4f1d4199d 100644 --- a/source/specifications/declaring-project-metadata.rst +++ b/source/specifications/declaring-project-metadata.rst @@ -289,10 +289,10 @@ URL itself. .. code-block:: toml [project.urls] - homepage = "https://example.com" - documentation = "https://readthedocs.org" - repository = "https://github.com/me/spam.git" - changelog = "https://github.com/me/spam/blob/master/CHANGELOG.md" + Homepage = "https://example.com" + Documentation = "https://readthedocs.org" + Repository = "https://github.com/me/spam.git" + Changelog = "https://github.com/me/spam/blob/master/CHANGELOG.md" Entry points ------------ @@ -464,10 +464,10 @@ Example ] [project.urls] - homepage = "https://example.com" - documentation = "https://readthedocs.org" - repository = "https://github.com/me/spam.git" - changelog = "https://github.com/me/spam/blob/master/CHANGELOG.md" + Homepage = "https://example.com" + Documentation = "https://readthedocs.org" + Repository = "https://github.com/me/spam.git" + Changelog = "https://github.com/me/spam/blob/master/CHANGELOG.md" [project.scripts] spam-cli = "spam:main_cli" From a1ecd5e78a35c2b3718790445de9cde5f5800e89 Mon Sep 17 00:00:00 2001 From: chrysle Date: Sat, 20 May 2023 14:06:57 +0200 Subject: [PATCH 0345/1072] Replaced `python` interpreter with `python3` (#1214) Co-authored-by: Brian Rutledge --- source/guides/analyzing-pypi-package-downloads.rst | 2 +- source/guides/distributing-packages-using-setuptools.rst | 8 ++++---- .../github-actions-ci-cd-sample/publish-to-test-pypi.yml | 4 ++-- source/guides/index-mirrors-and-caches.rst | 6 +++--- source/guides/multi-version-installs.rst | 2 +- 5 files changed, 11 insertions(+), 11 deletions(-) diff --git a/source/guides/analyzing-pypi-package-downloads.rst b/source/guides/analyzing-pypi-package-downloads.rst index debe62ce5..5ee038587 100644 --- a/source/guides/analyzing-pypi-package-downloads.rst +++ b/source/guides/analyzing-pypi-package-downloads.rst @@ -311,7 +311,7 @@ Install `pypinfo`_ using pip. .. code-block:: bash - python -m pip install pypinfo + python3 -m pip install pypinfo Usage: diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index d843a51a6..a704dd048 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -72,7 +72,7 @@ sample project `_. 2. It's the command line interface for running various commands that relate to packaging tasks. To get a listing of available commands, run - ``python setup.py --help-commands``. + ``python3 setup.py --help-commands``. setup.cfg @@ -677,7 +677,7 @@ Change directory to the root of the project directory and run: .. code-block:: bash - python -m pip install -e . + python3 -m pip install -e . The pip command-line flag ``-e`` is short for ``--editable``, and ``.`` refers @@ -712,7 +712,7 @@ Lastly, if you don't want to install any dependencies at all, you can run: .. code-block:: bash - python -m pip install -e . --no-deps + python3 -m pip install -e . --no-deps For more information, see the @@ -812,7 +812,7 @@ To build the wheel: .. code-block:: bash - python -m build --wheel + python3 -m build --wheel .. tab:: Windows diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index da6e213cf..35a2f653d 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -15,13 +15,13 @@ jobs: python-version: "3.x" - name: Install pypa/build run: >- - python -m + python3 -m pip install build --user - name: Build a binary wheel and a source tarball run: >- - python -m + python3 -m build --sdist --wheel diff --git a/source/guides/index-mirrors-and-caches.rst b/source/guides/index-mirrors-and-caches.rst index 18dc3463e..c186b64a9 100644 --- a/source/guides/index-mirrors-and-caches.rst +++ b/source/guides/index-mirrors-and-caches.rst @@ -33,12 +33,12 @@ cached copies of :term:`packages `: by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI. 2. A variation on the above which pre-builds the installation files for - the requirements using :ref:`python -m pip wheel `: + the requirements using :ref:`python3 -m pip wheel `: .. code-block:: bash - python -m pip wheel --wheel-dir=/tmp/wheelhouse SomeProject - python -m pip install --no-index --find-links=/tmp/wheelhouse SomeProject + python3 -m pip wheel --wheel-dir=/tmp/wheelhouse SomeProject + python3 -m pip install --no-index --find-links=/tmp/wheelhouse SomeProject Caching with devpi diff --git a/source/guides/multi-version-installs.rst b/source/guides/multi-version-installs.rst index 0c2929fbb..a09bc900a 100644 --- a/source/guides/multi-version-installs.rst +++ b/source/guides/multi-version-installs.rst @@ -35,7 +35,7 @@ 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 ``python -c ''`` to invoke the application's +wrapper script or use ``python3 -c ''`` to invoke the application's main entry point directly. Refer to the `pkg_resources documentation From a1deee19dd37c9581cf5ee470f27c0d5e11a739b Mon Sep 17 00:00:00 2001 From: sinoroc <5529267+sinoroc@users.noreply.github.com> Date: Sat, 20 May 2023 14:28:17 +0200 Subject: [PATCH 0346/1072] Replace refs to PEP-503 with simple repository API (#1213) Co-authored-by: Brian Rutledge --- source/guides/creating-and-discovering-plugins.rst | 7 +++---- source/guides/hosting-your-own-index.rst | 2 +- source/tutorials/installing-packages.rst | 8 ++++---- 3 files changed, 8 insertions(+), 9 deletions(-) diff --git a/source/guides/creating-and-discovering-plugins.rst b/source/guides/creating-and-discovering-plugins.rst index f4b36f735..eceebc843 100644 --- a/source/guides/creating-and-discovering-plugins.rst +++ b/source/guides/creating-and-discovering-plugins.rst @@ -45,14 +45,13 @@ then ``discovered_plugins`` would be: 'flask_talisman': , } -Using naming convention for plugins also allows you to query the -Python Package Index's `simple API`_ for all packages that conform to your -naming convention. +Using naming convention for plugins also allows you to query +the Python Package Index's :ref:`simple repository API ` +for all packages that conform to your naming convention. .. _Flask: https://pypi.org/project/Flask/ .. _Flask-SQLAlchemy: https://pypi.org/project/Flask-SQLAlchemy/ .. _Flask-Talisman: https://pypi.org/project/flask-talisman -.. _simple API: https://www.python.org/dev/peps/pep-0503/#specification Using namespace packages diff --git a/source/guides/hosting-your-own-index.rst b/source/guides/hosting-your-own-index.rst index f9d2d74c4..26ffe2b8c 100644 --- a/source/guides/hosting-your-own-index.rst +++ b/source/guides/hosting-your-own-index.rst @@ -55,7 +55,7 @@ instruct users to add the URL to their installer's configuration. ---- .. [1] For complete documentation of the simple repository protocol, see - :pep:`503`. + :ref:`simple repository API `. .. _Twisted: https://twistedmatrix.com/ diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst index 6fd267112..23645459a 100644 --- a/source/tutorials/installing-packages.rst +++ b/source/tutorials/installing-packages.rst @@ -612,10 +612,10 @@ Install from a local directory containing archives (and don't check :term:`PyPI Installing from other sources ============================= -To install from other data sources (for example Amazon S3 storage) you can -create a helper application that presents the data in a :pep:`503` compliant -index format, and use the ``--extra-index-url`` flag to direct pip to use -that index. +To install from other data sources (for example Amazon S3 storage) +you can create a helper application that presents the data +in a format compliant with the :ref:`simple repository API `:, +and use the ``--extra-index-url`` flag to direct pip to use that index. .. code-block:: bash From 1a61586f7d4b35e745623e0f57cdb8fcbeccc7f0 Mon Sep 17 00:00:00 2001 From: Bastian Venthur Date: Mon, 22 May 2023 19:48:27 +0200 Subject: [PATCH 0347/1072] removed references to PEP 582 which has been rejected. (#1258) * removed references to PEP 582 which has been rejected. * removed now obsolete reference to npm --- source/key_projects.rst | 4 +--- source/tutorials/managing-dependencies.rst | 6 ++---- 2 files changed, 3 insertions(+), 7 deletions(-) diff --git a/source/key_projects.rst b/source/key_projects.rst index 4ffdd6688..a1c2cac7b 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -486,9 +486,7 @@ pdm `GitHub `__ | `PyPI `__ -PDM is a modern Python package manager with :pep:`582` support. It installs and -manages packages in a similar way to ``npm`` that doesn't need to create a -:term:`virtual environment` at all. It also uses :term:`pyproject.toml` to store +PDM is a modern Python package manager. It uses :term:`pyproject.toml` to store project metadata as defined in :pep:`621`. .. _pex: diff --git a/source/tutorials/managing-dependencies.rst b/source/tutorials/managing-dependencies.rst index eaa32f7ef..db3b82533 100644 --- a/source/tutorials/managing-dependencies.rst +++ b/source/tutorials/managing-dependencies.rst @@ -167,10 +167,8 @@ and techniques, listed in alphabetical order, to see if one of them is a better wrapper around pip that supports ``requirements.txt``, Pipenv and Poetry lock files, or converting them to pip-tools compatible output. Designed for containerized Python applications, but not limited to them. -* `PDM `_ for a modern Python package management - tool supporting :pep:`582` (replacing virtual environments with ``__pypackages__`` - directory for package installation) and relying on standards such as :pep:`517` and - :pep:`621`. +* `PDM `_ for a modern Python package + management relying on standards such as :pep:`517` and :pep:`621`. * `pip-tools `_ for creating a lock file of all dependencies from a list of packages directly used in a project, and ensuring that only those dependencies are installed. From 34a2f84bf94e5d590e8f9bd32f67fee33582e836 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=A9mie=20Tarot?= Date: Fri, 9 Jun 2023 14:09:17 +0200 Subject: [PATCH 0348/1072] Fix typos in Recording installed packages spec --- source/specifications/recording-installed-packages.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/specifications/recording-installed-packages.rst b/source/specifications/recording-installed-packages.rst index bac887b2b..fe33df438 100644 --- a/source/specifications/recording-installed-packages.rst +++ b/source/specifications/recording-installed-packages.rst @@ -234,7 +234,7 @@ packages into a Python environment to ensure that other tools are not used to uninstall or otherwise modify that installed package, as doing so may cause compatibility problems with the wider environment. -To achieve this, affected tools should take the folllowing steps: +To achieve this, affected tools should take the following steps: * Rename or remove the ``RECORD`` file to prevent changes via other tools (e.g. appending a suffix to create a non-standard ``RECORD.tool`` file if the tool @@ -246,7 +246,7 @@ To achieve this, affected tools should take the folllowing steps: Python runtime providers may also prevent inadvertent modification of platform provided packages by modifying the default Python package installation scheme -to use a location other than that used by platform provided packages (while also +to use a location other than that used by distribution packages (while also ensuring both locations appear on the default Python import path). In some circumstances, it may be desirable to block even installation of From 7451a0b16e7c01517ec061d78d9fffdd66ab690f Mon Sep 17 00:00:00 2001 From: chrysle Date: Fri, 16 Jun 2023 15:53:59 +0200 Subject: [PATCH 0349/1072] Integrate pre-commit and add trailing-whitespace hook --- .github/workflows/test.yml | 2 +- .pre-commit-config.yaml | 5 +++++ noxfile.py | 19 ++++++++++++++++-- .../deploying-python-applications.rst | 20 +++++++++---------- source/glossary.rst | 2 +- .../guides/dropping-older-python-versions.rst | 8 ++++---- ...talling-stand-alone-command-line-tools.rst | 2 +- .../guides/installing-using-linux-tools.rst | 6 +++--- .../guides/making-a-pypi-friendly-readme.rst | 2 +- source/guides/packaging-binary-extensions.rst | 2 +- .../guides/packaging-namespace-packages.rst | 4 ++-- ...s-using-github-actions-ci-cd-workflows.rst | 2 +- .../direct-url-data-structure.rst | 14 ++++++------- .../specifications/simple-repository-api.rst | 2 +- source/tutorials/creating-documentation.rst | 2 +- 15 files changed, 56 insertions(+), 36 deletions(-) create mode 100644 .pre-commit-config.yaml diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index b0fc5300c..58505e1a5 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -1,6 +1,6 @@ name: Test -on: +on: push: pull_request: schedule: diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml new file mode 100644 index 000000000..1c21dbb04 --- /dev/null +++ b/.pre-commit-config.yaml @@ -0,0 +1,5 @@ +repos: + - repo: https://github.com/pre-commit/pre-commit-hooks + rev: v4.4.0 + hooks: + - id: trailing-whitespace diff --git a/noxfile.py b/noxfile.py index fe7872995..884b6ad08 100644 --- a/noxfile.py +++ b/noxfile.py @@ -18,13 +18,14 @@ def translation(session): session.install("-r", "requirements.txt") target_dir = "locales" session.run( - "sphinx-build", + "sphinx-build", "-b", "gettext", # build gettext-style message catalogs (.pot file) "-d", ".nox/.doctrees/", # path to put the cache "source/", # where the rst files are located target_dir, # where to put the .pot file ) + @nox.session() def build(session, autobuild=False): """ @@ -75,10 +76,24 @@ def linkcheck(session): """ session.install("-r", "requirements.txt") session.run( - "sphinx-build", + "sphinx-build", "-b", "linkcheck", # use linkcheck builder "--color", "-n", "-W", "--keep-going", # be strict "source", # where the rst files are located "build", # where to put the check output ) + + +@nox.session() +def checkqa(session): + """ + Format the guide using pre-commit. + """ + session.install("pre-commit") + session.run( + "pre-commit", + "run", + "--all-files", + "--show-diff-on-failure", + ) diff --git a/source/discussions/deploying-python-applications.rst b/source/discussions/deploying-python-applications.rst index de781d9fd..62e29448f 100644 --- a/source/discussions/deploying-python-applications.rst +++ b/source/discussions/deploying-python-applications.rst @@ -92,12 +92,12 @@ py2exe ^^^^^^ `py2exe `__ is a distutils extension which -allows to build standalone Windows executable programs (32-bit and 64-bit) -from Python scripts. Python versions included in the official development +allows to build standalone Windows executable programs (32-bit and 64-bit) +from Python scripts. Python versions included in the official development cycle are supported (refers to `Status of Python branches`__). py2exe can build console executables and windows (GUI) executables. Building windows services, and DLL/EXE COM servers might work but it is not actively supported. -The distutils extension is released under the MIT-licence and Mozilla +The distutils extension is released under the MIT-licence and Mozilla Public License 2.0. .. __: https://devguide.python.org/#status-of-python-branches @@ -108,8 +108,8 @@ macOS py2app ^^^^^^ -`py2app `__ is a Python setuptools -command which will allow you to make standalone macOS application +`py2app `__ is a Python setuptools +command which will allow you to make standalone macOS application bundles and plugins from Python scripts. Note that py2app MUST be used on macOS to build applications, it cannot create Mac applications on other platforms. py2app is released under the MIT-license. @@ -120,11 +120,11 @@ Unix (including Linux and macOS) pex ^^^ -`pex `__ is a library for generating .pex -(Python EXecutable) files which are executable Python environments in the -spirit of virtualenvs. pex is an expansion upon the ideas outlined in :pep:`441` -and makes the deployment of Python applications as simple as cp. pex files may -even include multiple platform-specific Python distributions, meaning that a +`pex `__ is a library for generating .pex +(Python EXecutable) files which are executable Python environments in the +spirit of virtualenvs. pex is an expansion upon the ideas outlined in :pep:`441` +and makes the deployment of Python applications as simple as cp. pex files may +even include multiple platform-specific Python distributions, meaning that a single pex file can be portable across Linux and macOS. pex is released under the Apache License 2.0. diff --git a/source/glossary.rst b/source/glossary.rst index 2cbde7bed..f8392dbd0 100644 --- a/source/glossary.rst +++ b/source/glossary.rst @@ -42,7 +42,7 @@ Glossary Egg A :term:`Built Distribution` format introduced by :ref:`setuptools`, - which is being replaced by :term:`Wheel`. For details, see + which is being replaced by :term:`Wheel`. For details, see :doc:`The Internal Structure of Python Eggs ` and `Python Eggs `_ diff --git a/source/guides/dropping-older-python-versions.rst b/source/guides/dropping-older-python-versions.rst index ecb4e59c6..d4fc83c81 100644 --- a/source/guides/dropping-older-python-versions.rst +++ b/source/guides/dropping-older-python-versions.rst @@ -6,7 +6,7 @@ Dropping support for older Python versions Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a "Requires-Python" attribute. -Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version +Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime. This mechanism can be used to drop support for older Python versions, by amending the "Requires-Python" attribute in the package metadata. @@ -102,8 +102,8 @@ metadata values based on the argument you provide in ``python_requires``. Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO. -This file is generated by Distutils or :ref:`setuptools` when it generates the source package. -The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format. +This file is generated by Distutils or :ref:`setuptools` when it generates the source package. +The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format. You can see the contents of the generated file like this: @@ -113,7 +113,7 @@ You can see the contents of the generated file like this: Validate that the following is in place, before publishing the package: -- If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher. +- If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher. - The Requires-Python field is set and matches your specification in setup.py. 4. Using Twine to publish diff --git a/source/guides/installing-stand-alone-command-line-tools.rst b/source/guides/installing-stand-alone-command-line-tools.rst index 78e18fccb..f584cf996 100644 --- a/source/guides/installing-stand-alone-command-line-tools.rst +++ b/source/guides/installing-stand-alone-command-line-tools.rst @@ -66,7 +66,7 @@ For example: \ ^__^ (oo)\_______ - (__)\ )\/ + (__)\ )\/ || || ||----w | diff --git a/source/guides/installing-using-linux-tools.rst b/source/guides/installing-using-linux-tools.rst index 772bbfcbc..8c1fd3f00 100644 --- a/source/guides/installing-using-linux-tools.rst +++ b/source/guides/installing-using-linux-tools.rst @@ -38,7 +38,7 @@ Fedora sudo dnf install python3-pip python3-wheel To learn more about Python in Fedora, please visit the `official Fedora docs`_, -`Python Classroom`_ or `Fedora Loves Python`_. +`Python Classroom`_ or `Fedora Loves Python`_. .. _official Fedora docs: https://developer.fedoraproject.org/tech/languages/python/python-installation.html .. _Python Classroom: https://labs.fedoraproject.org/en/python-classroom/ @@ -54,7 +54,7 @@ To install pip and wheel for the system Python, there are two options: 1. Enable the `EPEL repository `_ using `these instructions - `__. + `__. On EPEL 7, you can install pip and wheel like so: .. code-block:: bash @@ -111,7 +111,7 @@ openSUSE ~~~~~~~~ .. code-block:: bash - + sudo zypper install python3-pip python3-setuptools python3-wheel diff --git a/source/guides/making-a-pypi-friendly-readme.rst b/source/guides/making-a-pypi-friendly-readme.rst index 5e6eef4c7..4f85d5054 100644 --- a/source/guides/making-a-pypi-friendly-readme.rst +++ b/source/guides/making-a-pypi-friendly-readme.rst @@ -58,7 +58,7 @@ such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdow py -m pip install --user --upgrade setuptools wheel twine The minimum required versions of the respective tools are: - + - ``setuptools >= 38.6.0`` - ``wheel >= 0.31.0`` - ``twine >= 1.11.0`` diff --git a/source/guides/packaging-binary-extensions.rst b/source/guides/packaging-binary-extensions.rst index f27eb4730..29d3de303 100644 --- a/source/guides/packaging-binary-extensions.rst +++ b/source/guides/packaging-binary-extensions.rst @@ -169,7 +169,7 @@ wrapper modules up to date. for automatic wrapping with Cython. It also supports performance-oriented Python implementations that provide a CPython-like C-API, such as PyPy and Pyston. - + * :doc:`pybind11 ` is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in diff --git a/source/guides/packaging-namespace-packages.rst b/source/guides/packaging-namespace-packages.rst index 64bce312c..301b53d63 100644 --- a/source/guides/packaging-namespace-packages.rst +++ b/source/guides/packaging-namespace-packages.rst @@ -9,7 +9,7 @@ single :term:`package ` across multiple, separate have the following package structure: .. code-block:: text - + mynamespace/ __init__.py subpackage_a/ @@ -29,7 +29,7 @@ And you use this package in your code like so:: Then you can break these sub-packages into two separate distributions: .. code-block:: text - + mynamespace-subpackage-a/ setup.py mynamespace/ diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index 8945821cb..19f70f040 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -138,7 +138,7 @@ Now, whenever you push a tagged commit to your Git repository remote on GitHub, this workflow will publish it to PyPI. And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making -sure that your release pipeline remains healthy! +sure that your release pipeline remains healthy! .. _API token: https://pypi.org/help/#apitoken diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst index 2fa567a62..eced739c2 100644 --- a/source/specifications/direct-url-data-structure.rst +++ b/source/specifications/direct-url-data-structure.rst @@ -70,20 +70,20 @@ When ``url`` refers to a source archive or a wheel, the ``archive_info`` key MUST be present as a dictionary with the following keys: - A ``hashes`` key SHOULD be present as a dictionary mapping a hash name to a hex - encoded digest of the file. - + encoded digest of the file. + Multiple hashes can be included, and it is up to the consumer to decide what to do with multiple hashes (it may validate all of them or a subset of them, or nothing at - all). - - These hash names SHOULD always be normalized to be lowercase. - + all). + + These hash names SHOULD always be normalized to be lowercase. + Any hash algorithm available via ``hashlib`` (specifically any that can be passed to ``hashlib.new()`` and do not require additional parameters) can be used as a key for the hashes dictionary. At least one secure algorithm from ``hashlib.algorithms_guaranteed`` SHOULD always be included. At time of writing, ``sha256`` specifically is recommended. - + - A deprecated ``hash`` key (type ``string``) MAY be present for backwards compatibility purposes, with value ``=``. diff --git a/source/specifications/simple-repository-api.rst b/source/specifications/simple-repository-api.rst index f54713d99..164290310 100644 --- a/source/specifications/simple-repository-api.rst +++ b/source/specifications/simple-repository-api.rst @@ -9,5 +9,5 @@ The current interface for querying available package versions and retrieving packages from an index server is defined in :pep:`503`, with the addition of "yank" support (allowing a kind of file deletion) in :pep:`592`, specifying the interface version provided -by an index server in :pep:`629`, and providing package metadata +by an index server in :pep:`629`, and providing package metadata independently from a package in :pep:`658`. diff --git a/source/tutorials/creating-documentation.rst b/source/tutorials/creating-documentation.rst index 26cffb383..ec960ada0 100644 --- a/source/tutorials/creating-documentation.rst +++ b/source/tutorials/creating-documentation.rst @@ -61,7 +61,7 @@ For more details on the build process, see this `guide`_ by Read The Docs. Other Sources ------------- -For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python. +For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python. .. _documentation tutorial: https://docs.python-guide.org/writing/documentation/ From 2902232cfbfa5880c822002933488ac39c3bcaf7 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Sat, 17 Jun 2023 00:58:33 +0200 Subject: [PATCH 0350/1072] Update .pre-commit-config.yaml --- .pre-commit-config.yaml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index 1c21dbb04..a1a5f58c8 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -1,5 +1,5 @@ repos: - - repo: https://github.com/pre-commit/pre-commit-hooks - rev: v4.4.0 - hooks: - - id: trailing-whitespace +- repo: https://github.com/pre-commit/pre-commit-hooks + rev: v4.4.0 + hooks: + - id: trailing-whitespace From 036656aff5de261968e89f70624be0d0064222bb Mon Sep 17 00:00:00 2001 From: Seth Michael Larson Date: Thu, 20 Jul 2023 11:10:22 -0500 Subject: [PATCH 0351/1072] Add warning about reference interop for build numbers --- source/specifications/binary-distribution-format.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst index 317626b18..8f0cb541f 100644 --- a/source/specifications/binary-distribution-format.rst +++ b/source/specifications/binary-distribution-format.rst @@ -134,6 +134,18 @@ build tag the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``. + .. warning:: + + Build numbers are not a part of the distribution version and thus are difficult + to reference externally, especially so outside the Python ecosystem of tools and standards. + A common case where a distribution would need to referenced externally is when + resolving a security vulnerability. + + Due to this limitation new distributions which need to be referenced externally + **should not** use build numbers when building the new distribution. + Instead a **new distribution version** should be created for such cases. + + language implementation and version tag E.g. 'py27', 'py2', 'py3'. From 4d2e9ddfd4231fba822fce40d6e5d8be5fb25d37 Mon Sep 17 00:00:00 2001 From: Seth Michael Larson Date: Sat, 22 Jul 2023 21:09:13 -0500 Subject: [PATCH 0352/1072] Update source/specifications/binary-distribution-format.rst Co-authored-by: Brett Cannon --- source/specifications/binary-distribution-format.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst index 8f0cb541f..0428f15a4 100644 --- a/source/specifications/binary-distribution-format.rst +++ b/source/specifications/binary-distribution-format.rst @@ -141,7 +141,7 @@ build tag A common case where a distribution would need to referenced externally is when resolving a security vulnerability. - Due to this limitation new distributions which need to be referenced externally + Due to this limitation, new distributions which need to be referenced externally **should not** use build numbers when building the new distribution. Instead a **new distribution version** should be created for such cases. From b348a341ffa7a2be530cf76b333a04d58ea47f69 Mon Sep 17 00:00:00 2001 From: Seth Michael Larson Date: Wed, 26 Jul 2023 13:28:15 -0500 Subject: [PATCH 0353/1072] Add comment about use-case for build numbers --- source/specifications/binary-distribution-format.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst index 0428f15a4..9855ad8ff 100644 --- a/source/specifications/binary-distribution-format.rst +++ b/source/specifications/binary-distribution-format.rst @@ -134,6 +134,11 @@ build tag the first item being the initial digits as an ``int``, and the second item being the remainder of the tag as a ``str``. + A common use-case for build numbers is rebuilding a binary + distribution due to a change in the build environment, + like when using the manylinux image to build + distributions using pre-release CPython versions. + .. warning:: Build numbers are not a part of the distribution version and thus are difficult From 62072b70d7be5a3b5bc8f236b8183524d07000bd Mon Sep 17 00:00:00 2001 From: Dustin Ingram Date: Tue, 1 Aug 2023 11:31:35 -0400 Subject: [PATCH 0354/1072] Fix broken links (#1279) --- source/guides/single-sourcing-package-version.rst | 2 +- source/specifications/index.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/source/guides/single-sourcing-package-version.rst b/source/guides/single-sourcing-package-version.rst index ec85d084d..97a9cb026 100644 --- a/source/guides/single-sourcing-package-version.rst +++ b/source/guides/single-sourcing-package-version.rst @@ -9,7 +9,7 @@ There are many techniques to maintain a single source of truth for the version number of your project: #. Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py - `_):: + `_):: import codecs import os.path diff --git a/source/specifications/index.rst b/source/specifications/index.rst index d7b787b47..4f622d845 100644 --- a/source/specifications/index.rst +++ b/source/specifications/index.rst @@ -6,7 +6,7 @@ PyPA specifications This is a list of currently active interoperability specifications maintained by the Python Packaging Authority. The process for updating these standards, and for proposing new ones, is documented on -`pypa.io `__. +`pypa.io `__. Package Distribution Metadata From c022989c310d0bbeda55afce2234b03fb76a02d0 Mon Sep 17 00:00:00 2001 From: Mike Fiedler Date: Tue, 1 Aug 2023 11:33:44 -0400 Subject: [PATCH 0355/1072] docs: add notice about PEP 715 (#1278) Refs: https://peps.python.org/pep-0715/ Signed-off-by: Mike Fiedler --- source/discussions/wheel-vs-egg.rst | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/source/discussions/wheel-vs-egg.rst b/source/discussions/wheel-vs-egg.rst index 9e1bcf3dc..d4a1114fb 100644 --- a/source/discussions/wheel-vs-egg.rst +++ b/source/discussions/wheel-vs-egg.rst @@ -44,6 +44,10 @@ Here's a breakdown of the important differences between :term:`Wheel` and :term: `_, therefore making it easier to convert to other formats. +* :term:`Egg` uploads have been disabled for upload to PyPI, per :pep:`715`. + Read the `deprecation notice `_ + for more information. + ---- .. [1] Circumstantially, in some cases, wheels can be used as an importable From 137713c5be94adb6e4985f2b01bd0d2cc6c7f7c9 Mon Sep 17 00:00:00 2001 From: Petr Viktorin Date: Thu, 3 Aug 2023 13:27:34 +0200 Subject: [PATCH 0356/1072] Add Source distribution archive features (PEP 721) --- .../source-distribution-format.rst | 70 +++++++++++++++++++ 1 file changed, 70 insertions(+) diff --git a/source/specifications/source-distribution-format.rst b/source/specifications/source-distribution-format.rst index 385828e31..a2fad4873 100644 --- a/source/specifications/source-distribution-format.rst +++ b/source/specifications/source-distribution-format.rst @@ -67,3 +67,73 @@ whatever information they need in the sdist to build the project. The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names. In particular, source distribution files must be readable using the standard library tarfile module with the open flag 'r:gz'. + + +.. _sdist-archive-features: + +Source distribution archive features +==================================== + +Because extracting tar files as-is is dangerous, and the results are +platform-specific, archive features of source distributions are limited. + +Unpacking with the data filter +------------------------------ + +When extracting a source distribution, tools MUST either use +``tarfile.data_filter`` (e.g. ``TarFile.extractall(..., filter='data')``), OR +follow the *Unpacking without the data filter* section below. + +As an exception, on Python interpreters without ``hasattr(tarfile, 'data_filter')`` +(:pep:`706`), tools that normally use that filter (directly on indirectly) +MAY warn the user and ignore this specification. +The trade-off between usability (e.g. fully trusting the archive) and +security (e.g. refusing to unpack) is left up to the tool in this case. + + +Unpacking without the data filter +--------------------------------- + +Tools that do not use the ``data`` filter directly (e.g. for backwards +compatibility, allowing additional features, or not using Python) MUST follow +this section. +(At the time of this writing, the ``data`` filter also follows this section, +but it may get out of sync in the future.) + +The following files are invalid in an ``sdist`` archive. +Upon encountering such an entry, tools SHOULD notify the user, +MUST NOT unpack the entry, and MAY abort with a failure: + +- Files that would be placed outside the destination directory. +- Links (symbolic or hard) pointing outside the destination directory. +- Device files (including pipes). + +The following are also invalid. Tools MAY treat them as above, +but are NOT REQUIRED to do so: + +- Files with a ``..`` component in the filename or link target. +- Links pointing to a file that is not part of the archive. + +Tools MAY unpack links (symbolic or hard) as regular files, +using content from the archive. + +When extracting ``sdist`` archives: + +- Leading slashes in file names MUST be dropped. + (This is nowadays standard behaviour for ``tar`` unpacking.) +- For each ``mode`` (Unix permission) bit, tools MUST either: + + - use the platform's default for a new file/directory (respectively), + - set the bit according to the archive, or + - use the bit from ``rw-r--r--`` (``0o644``) for non-executable files or + ``rwxr-xr-x`` (``0o755``) for executable files and directories. + +- High ``mode`` bits (setuid, setgid, sticky) MUST be cleared. +- It is RECOMMENDED to preserve the user *executable* bit. + + +Further hints +------------- + +Tool authors are encouraged to consider how *hints for further +verification* in ``tarfile`` documentation apply for their tool. From 215f801d7bdc0fb3d0bfd0c664db791c6dd62007 Mon Sep 17 00:00:00 2001 From: Petr Viktorin Date: Thu, 3 Aug 2023 15:55:32 +0200 Subject: [PATCH 0357/1072] Add a history section See: https://github.com/pypa/packaging.python.org/issues/1203 --- source/specifications/source-distribution-format.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/source/specifications/source-distribution-format.rst b/source/specifications/source-distribution-format.rst index a2fad4873..9706051c6 100644 --- a/source/specifications/source-distribution-format.rst +++ b/source/specifications/source-distribution-format.rst @@ -137,3 +137,13 @@ Further hints Tool authors are encouraged to consider how *hints for further verification* in ``tarfile`` documentation apply for their tool. + + +History +======= + +* August 2023: Stanardized the source distribution archive features (:pep:`721`) +* September 2022: Stanardized the filename of a source distribution (:pep:`625`) +* July 2021: Defined what a source tree is +* November 2020: PEP 643 converted to this specification +* December 2000: Source distributions standardized in :pep:`643` From d07e055f817d63e500768d52f33677a28c6f5397 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Sun, 6 Aug 2023 16:38:04 -0700 Subject: [PATCH 0358/1072] Add missing anchors for core metadata --- source/specifications/core-metadata.rst | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst index 644380962..3873090c7 100644 --- a/source/specifications/core-metadata.rst +++ b/source/specifications/core-metadata.rst @@ -40,6 +40,8 @@ to a new format. .. contents:: Contents :local: +.. _core-metadata-metadata-version: + Metadata-Version ================ @@ -133,6 +135,7 @@ project. Full details of the semantics of ``Dynamic`` are described in :pep:`643`. +.. _core-metadata-platform: Platform (multiple use) ======================= @@ -148,6 +151,7 @@ Examples:: Platform: ObscureUnix Platform: RareDOS +.. _core-metadata-supported-platform: Supported-Platform (multiple use) ================================= @@ -340,6 +344,7 @@ Example:: easier to update the specification to match the de facto standard. .. _home-page-optional: +.. _core-metadata-home-page: Home-page ========= @@ -352,6 +357,7 @@ Example:: Home-page: http://www.example.com/~cschultz/bvote/ +.. _core-metadata-download-url: Download-URL ============ @@ -558,6 +564,7 @@ Examples:: Requires-Python: >2.6,!=3.0.*,!=3.1.* Requires-Python: ~=2.6 +.. _core-metadata-requires-external Requires-External (multiple use) ================================ @@ -682,6 +689,7 @@ as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository. +.. _core-metadata-provides-dist Provides-Dist (multiple use) ---------------------------- @@ -723,6 +731,7 @@ Examples:: Provides-Dist: AnotherProject (3.4) Provides-Dist: virtual_package; python_version >= "3.4" +.. _core-metadata-obsoletes-dist Obsoletes-Dist (multiple use) ----------------------------- From 943e90e7e46f1cdbfd9fe6d62ba85ca2dbb4f9c6 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Sun, 6 Aug 2023 16:41:30 -0700 Subject: [PATCH 0359/1072] Fix malformed hyperlink targets --- source/specifications/core-metadata.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst index 3873090c7..453f9d30c 100644 --- a/source/specifications/core-metadata.rst +++ b/source/specifications/core-metadata.rst @@ -564,7 +564,7 @@ Examples:: Requires-Python: >2.6,!=3.0.*,!=3.1.* Requires-Python: ~=2.6 -.. _core-metadata-requires-external +.. _core-metadata-requires-external: Requires-External (multiple use) ================================ @@ -689,7 +689,7 @@ as they're still potentially useful for informational purposes, and can also be used for their originally intended purpose in combination with a curated package repository. -.. _core-metadata-provides-dist +.. _core-metadata-provides-dist: Provides-Dist (multiple use) ---------------------------- @@ -731,7 +731,7 @@ Examples:: Provides-Dist: AnotherProject (3.4) Provides-Dist: virtual_package; python_version >= "3.4" -.. _core-metadata-obsoletes-dist +.. _core-metadata-obsoletes-dist: Obsoletes-Dist (multiple use) ----------------------------- From 0544c45594eee545b25faa4721e1e3a4ea86cdc7 Mon Sep 17 00:00:00 2001 From: Petr Viktorin Date: Mon, 7 Aug 2023 14:40:34 +0200 Subject: [PATCH 0360/1072] Links & typo fixes Co-authored-by: Sviatoslav Sydorenko --- source/specifications/source-distribution-format.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/source/specifications/source-distribution-format.rst b/source/specifications/source-distribution-format.rst index 9706051c6..e154e2952 100644 --- a/source/specifications/source-distribution-format.rst +++ b/source/specifications/source-distribution-format.rst @@ -81,10 +81,10 @@ Unpacking with the data filter ------------------------------ When extracting a source distribution, tools MUST either use -``tarfile.data_filter`` (e.g. ``TarFile.extractall(..., filter='data')``), OR +:py:func:`tarfile.data_filter` (e.g. :py:meth:`TarFile.extractall(..., filter='data') `), OR follow the *Unpacking without the data filter* section below. -As an exception, on Python interpreters without ``hasattr(tarfile, 'data_filter')`` +As an exception, on Python interpreters without :py:func:`hasattr(tarfile, 'data_filter') ` (:pep:`706`), tools that normally use that filter (directly on indirectly) MAY warn the user and ignore this specification. The trade-off between usability (e.g. fully trusting the archive) and @@ -136,14 +136,14 @@ Further hints ------------- Tool authors are encouraged to consider how *hints for further -verification* in ``tarfile`` documentation apply for their tool. +verification* in ``tarfile`` documentation apply to their tool. History ======= -* August 2023: Stanardized the source distribution archive features (:pep:`721`) -* September 2022: Stanardized the filename of a source distribution (:pep:`625`) +* August 2023: Standardized the source distribution archive features (:pep:`721`) +* September 2022: Standardized the filename of a source distribution (:pep:`625`) * July 2021: Defined what a source tree is -* November 2020: PEP 643 converted to this specification +* November 2020: :pep:`643` converted to this specification * December 2000: Source distributions standardized in :pep:`643` From 1416a463fd1ca398e7d87f3692abcd2b9adc47cc Mon Sep 17 00:00:00 2001 From: Petr Viktorin Date: Mon, 7 Aug 2023 14:43:03 +0200 Subject: [PATCH 0361/1072] Mark up *sdist* as it's marked up in the definition above --- source/specifications/source-distribution-format.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/specifications/source-distribution-format.rst b/source/specifications/source-distribution-format.rst index e154e2952..93531430f 100644 --- a/source/specifications/source-distribution-format.rst +++ b/source/specifications/source-distribution-format.rst @@ -100,7 +100,7 @@ this section. (At the time of this writing, the ``data`` filter also follows this section, but it may get out of sync in the future.) -The following files are invalid in an ``sdist`` archive. +The following files are invalid in an *sdist* archive. Upon encountering such an entry, tools SHOULD notify the user, MUST NOT unpack the entry, and MAY abort with a failure: @@ -117,7 +117,7 @@ but are NOT REQUIRED to do so: Tools MAY unpack links (symbolic or hard) as regular files, using content from the archive. -When extracting ``sdist`` archives: +When extracting *sdist* archives: - Leading slashes in file names MUST be dropped. (This is nowadays standard behaviour for ``tar`` unpacking.) From c1718eeb07ca18c93543b25632eeb63de958e5e5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=BCrgen=20Gmach?= Date: Thu, 10 Aug 2023 09:14:51 +0200 Subject: [PATCH 0362/1072] Add current URL for Bazaar Both the development of Bazaar and the project's URL `https://bazaar.canonical.com` have been discontinued. Breezy is the community maintained continuation. --- source/specifications/direct-url-data-structure.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst index eced739c2..eae9d3071 100644 --- a/source/specifications/direct-url-data-structure.rst +++ b/source/specifications/direct-url-data-structure.rst @@ -188,7 +188,7 @@ Bazaar Home page - _`https://bazaar.canonical.com` *(Not responding as of 5/2023)* + https://www.breezy-vcs.org/ vcs command From d441b5b423f9e67754b4817ca956cddd41a265ca Mon Sep 17 00:00:00 2001 From: Bastian Venthur Date: Thu, 17 Aug 2023 10:42:12 +0200 Subject: [PATCH 0363/1072] fixed broken link this is unrelated to the pr but satisfies the CI pipeline... --- source/key_projects.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/key_projects.rst b/source/key_projects.rst index a1c2cac7b..0c7b97fa8 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -558,7 +558,7 @@ resolution by locally caching metadata about dependencies. pypiserver ========== -`Docs `__ | +`Docs `__ | `GitHub `__ | `PyPI `__ From ffce75bc903f80ffbc9c33eddcb6def4b2636e49 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Fri, 18 Aug 2023 17:42:23 -0700 Subject: [PATCH 0364/1072] Add references to PEPs 691, 700, and 714 to the simple repository API spec page --- .../specifications/simple-repository-api.rst | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/source/specifications/simple-repository-api.rst b/source/specifications/simple-repository-api.rst index 164290310..70c0040d2 100644 --- a/source/specifications/simple-repository-api.rst +++ b/source/specifications/simple-repository-api.rst @@ -5,9 +5,16 @@ Simple repository API ===================== -The current interface for querying available package versions and -retrieving packages from an index server is defined in :pep:`503`, -with the addition of "yank" support (allowing a kind of file deletion) -in :pep:`592`, specifying the interface version provided -by an index server in :pep:`629`, and providing package metadata -independently from a package in :pep:`658`. +The interface for querying available package versions and +retrieving packages from an index server comes in two forms: +HTML and JSON. + +The HTML format is defined in :pep:`503`, with the addition of "yank" +support (allowing a kind of file deletion) in :pep:`592`, specifying +the interface version provided by an index server in :pep:`629`, and +providing package metadata independently from a package in +:pep:`658` and revised in :pep:`714`. + +The JSON format is defined in :pep:`691`, with additional fields +added in :pep:`700`, and revisions around providing package metadata +independently from a package in :pep:`714`. From 718e7ef0378027af1f7f2354e754ca071ca7780c Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Mon, 21 Aug 2023 12:58:56 -0700 Subject: [PATCH 0365/1072] Fix an unrelated URL to get CI passing --- source/key_projects.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/key_projects.rst b/source/key_projects.rst index a1c2cac7b..0c7b97fa8 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -558,7 +558,7 @@ resolution by locally caching metadata about dependencies. pypiserver ========== -`Docs `__ | +`Docs `__ | `GitHub `__ | `PyPI `__ From e6c97407c135764387b4d6f17db9bd83ca2e640f Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Wed, 23 Aug 2023 12:11:30 -0700 Subject: [PATCH 0366/1072] Drop a redundant link --- source/key_projects.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/source/key_projects.rst b/source/key_projects.rst index 0c7b97fa8..d7cf57f4d 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -558,7 +558,6 @@ resolution by locally caching metadata about dependencies. pypiserver ========== -`Docs `__ | `GitHub `__ | `PyPI `__ From b869257a3b4011f4c26df89a8758305f03764c7f Mon Sep 17 00:00:00 2001 From: chrysle Date: Wed, 24 May 2023 16:11:08 +0200 Subject: [PATCH 0367/1072] Add guidance for trusted publishing --- ...s-using-github-actions-ci-cd-workflows.rst | 26 +++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index 19f70f040..9b4d93dac 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -51,6 +51,31 @@ Let's begin! 🚀 create it. It's not the same as a regular PyPI account. +Using trusted publishing +------------------------ + +It is also possible to authenticate to PyPI without having to provide +an `API token`_. This can be done using +PyPI's `trusted publishing`_ implementation. This is recommended +also for security reasons, since the generated tokens are created for each of your projects +individually and expire automatically. + +The following steps will lead you through creating a "pending" publisher. + +1. Go to https://pypi.org/manage/account/publishing/ +2. Now fill in the name you wish to publish your new project under, + your repository data and the name of the release workflow file + under the ``.github/`` folder, see :ref:`workflow-definition`. + Finally add the name of the GitHub Actions environment + running under your repository. + Add the trusted publisher. +3. Your "pending" publisher is no ready for its first use and will + create your project automatically once you use it + for the first time. + + +.. _workflow-definition: + Creating a workflow definition ============================== @@ -150,3 +175,4 @@ sure that your release pipeline remains healthy! https://github.com/marketplace/actions/pypi-publish .. _Secrets: https://docs.github.com/en/actions/reference/encrypted-secrets +.. _trusted publishing: https://docs.pypi.org/trusted-publishers/ From 17993ef46a407c576722645554277d1115991298 Mon Sep 17 00:00:00 2001 From: chrysle Date: Thu, 25 May 2023 10:24:39 +0200 Subject: [PATCH 0368/1072] Remove steps to generate and use API token --- .../publish-to-test-pypi.yml | 5 +- ...s-using-github-actions-ci-cd-workflows.rst | 68 +++++++------------ 2 files changed, 25 insertions(+), 48 deletions(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index 35a2f653d..527cf4a82 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -6,6 +6,8 @@ jobs: build-n-publish: name: Build and publish Python 🐍 distributions 📦 to PyPI and TestPyPI runs-on: ubuntu-latest + permissions: + id-token: write steps: - uses: actions/checkout@v3 @@ -31,10 +33,7 @@ jobs: - name: Publish distribution 📦 to Test PyPI uses: pypa/gh-action-pypi-publish@release/v1 with: - password: ${{ secrets.TEST_PYPI_API_TOKEN }} repository-url: https://test.pypi.org/legacy/ - name: Publish distribution 📦 to PyPI if: startsWith(github.ref, 'refs/tags') uses: pypa/gh-action-pypi-publish@release/v1 - with: - password: ${{ secrets.PYPI_API_TOKEN }} diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index 9b4d93dac..95b83886d 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -17,62 +17,40 @@ It will use the `pypa/gh-action-pypi-publish GitHub Action`_. details of building platform specific projects. If you have binary components, check out :ref:`cibuildwheel`'s GitHub Action examples. -Saving credentials on GitHub -============================ - -In this guide, we'll demonstrate uploading to both -PyPI and TestPyPI, meaning that we'll have two separate sets -of credentials. And we'll need to save them in the GitHub repository -settings. - -Let's begin! 🚀 - -1. Go to https://pypi.org/manage/account/#api-tokens and - create a new `API token`_. If you have the project on PyPI - already, limit the token scope to just that project. - You can call it something like - ``GitHub Actions CI/CD — project-org/project-repo`` - in order for it to be easily distinguishable in the token - list. - **Don't close the page just yet — you won't see that token - again.** -2. In a separate browser tab or window, go to the ``Settings`` - tab of your target repository and then click on `Secrets`_ - in the left sidebar. -3. Create a new secret called ``PYPI_API_TOKEN`` and copy-paste - the token from the first step. -4. Now, go to https://test.pypi.org/manage/account/#api-tokens - and repeat the steps. Save that TestPyPI token on GitHub - as ``TEST_PYPI_API_TOKEN``. - - .. attention:: - - If you don't have a TestPyPI account, you'll need to - create it. It's not the same as a regular PyPI account. - +Configuring trusted publishing +============================== -Using trusted publishing ------------------------- +This guide relies on PyPI's `trusted publishing`_ implementation to connect +to `GitHub Actions CI/CD`_. This is recommended for security reasons, since +the generated tokens are created for each of your projects +individually and expire automatically. Otherwise you'll need to generate an +`API token`_ or provide a username/password combination for both PyPI and +TestPyPI. -It is also possible to authenticate to PyPI without having to provide -an `API token`_. This can be done using -PyPI's `trusted publishing`_ implementation. This is recommended -also for security reasons, since the generated tokens are created for each of your projects -individually and expire automatically. +Since this guide will demonstrate uploading to both +PyPI and TestPyPI, we'll need two trusted publishers configured. +The following steps will lead you through creating the "pending" publishers. -The following steps will lead you through creating a "pending" publisher. +Let's begin! 🚀 1. Go to https://pypi.org/manage/account/publishing/ -2. Now fill in the name you wish to publish your new project under, +2. Fill in the name you wish to publish your new project under, your repository data and the name of the release workflow file under the ``.github/`` folder, see :ref:`workflow-definition`. Finally add the name of the GitHub Actions environment running under your repository. - Add the trusted publisher. -3. Your "pending" publisher is no ready for its first use and will - create your project automatically once you use it + Register the trusted publisher. +3. Now, go to https://test.pypi.org/manage/account/publishing/ and repeat + the second step. +4. Your "pending" publishers are now ready for their first use and will + create your projects automatically once you use them for the first time. + .. attention:: + + If you don't have a TestPyPI account, you'll need to + create it. It's not the same as a regular PyPI account. + .. _workflow-definition: From 4c5786743a9fe1fcb0cf8c57ef6713bef33ae372 Mon Sep 17 00:00:00 2001 From: chrysle Date: Mon, 29 May 2023 09:28:11 +0200 Subject: [PATCH 0369/1072] Apply feedback from code review --- .../publish-to-test-pypi.yml | 44 +++++++++++-- ...s-using-github-actions-ci-cd-workflows.rst | 63 ++++++++++++------- 2 files changed, 80 insertions(+), 27 deletions(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index 527cf4a82..f71b44f27 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -3,9 +3,45 @@ name: Publish Python 🐍 distributions 📦 to PyPI and TestPyPI on: push jobs: - build-n-publish: - name: Build and publish Python 🐍 distributions 📦 to PyPI and TestPyPI + build-n-publish-pypi: + name: Build and publish Python 🐍 distributions 📦 to PyPI runs-on: ubuntu-latest + environment: + name: pypi + url: https://pypi.org/p/ + permissions: + id-token: write + + steps: + - uses: actions/checkout@v3 + - name: Set up Python + uses: actions/setup-python@v4 + with: + python-version: "3.x" + - name: Install pypa/build + run: >- + python3 -m + pip install + build + --user + - name: Build a binary wheel and a source tarball + run: >- + python3 -m + build + --sdist + --wheel + --outdir dist/ + . + # Actually publish to PyPI + - name: Publish distribution 📦 to PyPI + if: startsWith(github.ref, 'refs/tags') + uses: pypa/gh-action-pypi-publish@release/v1 + build-n-publish-testpypi: + name: Build and publish Python 🐍 distributions 📦 to TestPyPI + runs-on: ubuntu-latest + environment: + name: testpypi + url: https://test.pypi.org/p/ permissions: id-token: write @@ -29,11 +65,7 @@ jobs: --wheel --outdir dist/ . - # Actually publish to PyPI/TestPyPI - name: Publish distribution 📦 to Test PyPI uses: pypa/gh-action-pypi-publish@release/v1 with: repository-url: https://test.pypi.org/legacy/ - - name: Publish distribution 📦 to PyPI - if: startsWith(github.ref, 'refs/tags') - uses: pypa/gh-action-pypi-publish@release/v1 diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index 95b83886d..d8b6b7d2f 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -24,19 +24,23 @@ This guide relies on PyPI's `trusted publishing`_ implementation to connect to `GitHub Actions CI/CD`_. This is recommended for security reasons, since the generated tokens are created for each of your projects individually and expire automatically. Otherwise you'll need to generate an -`API token`_ or provide a username/password combination for both PyPI and -TestPyPI. +`API token`_ for both PyPI and TestPyPI. In case of publishing to third-party +indexes like :doc:`devpi `, you will need to provide a +username/password combination. Since this guide will demonstrate uploading to both PyPI and TestPyPI, we'll need two trusted publishers configured. -The following steps will lead you through creating the "pending" publishers. +The following steps will lead you through creating the "pending" publishers +for your new project. However it is also possible to add `trusted publishing`_ +to any pre-existing project, if you are its owner. Let's begin! 🚀 -1. Go to https://pypi.org/manage/account/publishing/ +1. Go to https://pypi.org/manage/account/publishing/. 2. Fill in the name you wish to publish your new project under, - your repository data and the name of the release workflow file - under the ``.github/`` folder, see :ref:`workflow-definition`. + your GitHub username and repository name and + the name of the release workflow file under + the ``.github/`` folder, see :ref:`workflow-definition`. Finally add the name of the GitHub Actions environment running under your repository. Register the trusted publisher. @@ -74,21 +78,24 @@ should make GitHub run this workflow: Defining a workflow job environment =================================== -Now, let's add initial setup for our job. It's a process that -will execute commands that we'll define later. +We will have to define two jobs to publish to PyPI +and TestPyPI respectively. + +Now, let's add initial setup for our job that will publish to PyPI. +It's a process that will execute commands that we'll define later. In this guide, we'll use the latest stable Ubuntu LTS version provided by GitHub Actions: .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml :start-after: on: - :end-before: steps: + :end-before: environment: Checking out the project and building distributions =================================================== -Then, add the following under the ``build-n-publish`` section: +Then, add the following under the ``build-n-publish-pypi`` section: .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml @@ -96,7 +103,10 @@ Then, add the following under the ``build-n-publish`` section: :end-before: Install pypa/build This will download your repository into the CI runner and then -install and activate the newest available Python 3 release. +install and activate the newest available Python 3 release. It +also defines the package index to publish to, PyPI, and grants +a permission to the action that is mandatory for trusted +publishing. And now we can build dists from source. In this example, we'll use ``build`` package. @@ -114,25 +124,36 @@ So add this to the steps list: .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml :start-after: version: "3.x" - :end-before: Actually publish to PyPI/TestPyPI + :end-before: Actually publish to PyPI -Publishing the distribution to PyPI and TestPyPI -================================================ +Publishing the distribution to PyPI +=================================== Finally, add the following steps at the end: .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml - :start-after: Actually publish to PyPI/TestPyPI - -These two steps use the `pypa/gh-action-pypi-publish`_ GitHub -Action: the first one uploads contents of the ``dist/`` folder -into TestPyPI unconditionally and the second does that to -PyPI, but only if the current commit is tagged. It is recommended -you use the latest release tag; a tool like GitHub's dependabot can keep + :start-after: Actually publish to PyPI + :end-before: build-n-publish-testpypi + +This step uses the `pypa/gh-action-pypi-publish`_ GitHub +Action: It uploads the contents of the ``dist/`` folder +into PyPI unconditionally, but only if the current commit +is tagged. It is recommended you use the latest release +tag; a tool like GitHub's dependabot can keep these updated regularly. +Separate workflow for publishing to TestPyPI +============================================ + +Now, repeat these steps and create another job for +publishing to the TestPyPI package index under the ``jobs`` +section: + +.. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml + :language: yaml + :start-after: uses: pypa/gh-action-pypi-publish@release/v1 That's all, folks! ================== From b998292a30a71ecbf2cc68de58148ef752d2e996 Mon Sep 17 00:00:00 2001 From: chrysle Date: Fri, 2 Jun 2023 16:40:04 +0200 Subject: [PATCH 0370/1072] Temporary state --- .../publish-to-test-pypi.yml | 57 +++++++++---------- ...s-using-github-actions-ci-cd-workflows.rst | 3 +- 2 files changed, 28 insertions(+), 32 deletions(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index f71b44f27..c6e7c5091 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -3,15 +3,10 @@ name: Publish Python 🐍 distributions 📦 to PyPI and TestPyPI on: push jobs: - build-n-publish-pypi: - name: Build and publish Python 🐍 distributions 📦 to PyPI + build: + name: Build the source package runs-on: ubuntu-latest - environment: - name: pypi - url: https://pypi.org/p/ - permissions: - id-token: write - + steps: - uses: actions/checkout@v3 - name: Set up Python @@ -28,11 +23,25 @@ jobs: run: >- python3 -m build - --sdist - --wheel - --outdir dist/ - . - # Actually publish to PyPI + - name: Store the distribution packages + uses: actions/upload-artifact@v3 + with: + name: python-package-distributions + build-n-publish-pypi: + name: Build and publish Python 🐍 distributions 📦 to PyPI + runs-on: ubuntu-latest + environment: + name: pypi + url: https://pypi.org/p/ + permissions: + id-token: write + + steps: + - name: Download all the dists + uses: actions/download-artifact@v3 + with: + name: python-package-distributions + path: dist/ - name: Publish distribution 📦 to PyPI if: startsWith(github.ref, 'refs/tags') uses: pypa/gh-action-pypi-publish@release/v1 @@ -46,25 +55,11 @@ jobs: id-token: write steps: - - uses: actions/checkout@v3 - - name: Set up Python - uses: actions/setup-python@v4 + - name: Download all the dists + uses: actions/download-artifact@v3 with: - python-version: "3.x" - - name: Install pypa/build - run: >- - python3 -m - pip install - build - --user - - name: Build a binary wheel and a source tarball - run: >- - python3 -m - build - --sdist - --wheel - --outdir dist/ - . + name: python-package-distributions + path: dist/ - name: Publish distribution 📦 to Test PyPI uses: pypa/gh-action-pypi-publish@release/v1 with: diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index d8b6b7d2f..e9b4666da 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -79,7 +79,8 @@ Defining a workflow job environment =================================== We will have to define two jobs to publish to PyPI -and TestPyPI respectively. +and TestPyPI respectively, and an additional job to +build the distribution packages. Now, let's add initial setup for our job that will publish to PyPI. It's a process that will execute commands that we'll define later. From 6c43bf4c6b61dbfb3a9128b7cbe75c26edd63142 Mon Sep 17 00:00:00 2001 From: chrysle Date: Tue, 6 Jun 2023 17:36:26 +0200 Subject: [PATCH 0371/1072] Move build steps into separate job --- ...s-using-github-actions-ci-cd-workflows.rst | 78 +++++++++---------- 1 file changed, 36 insertions(+), 42 deletions(-) diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index e9b4666da..44e626385 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -8,7 +8,9 @@ popular choice is having a workflow that's triggered by a ``push`` event. This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. -It will use the `pypa/gh-action-pypi-publish GitHub Action`_. +It will use the `pypa/gh-action-pypi-publish GitHub Action`_ for +publishing and `upload-artifact`_ and `download-artifact`_ actions +for temporarily storing and downloading the source packages. .. attention:: @@ -74,59 +76,47 @@ should make GitHub run this workflow: :language: yaml :end-before: jobs: - -Defining a workflow job environment -=================================== +Checking out the project and building distributions +=================================================== We will have to define two jobs to publish to PyPI and TestPyPI respectively, and an additional job to build the distribution packages. -Now, let's add initial setup for our job that will publish to PyPI. -It's a process that will execute commands that we'll define later. -In this guide, we'll use the latest stable Ubuntu LTS version -provided by GitHub Actions: - -.. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml - :language: yaml - :start-after: on: - :end-before: environment: - - -Checking out the project and building distributions -=================================================== - -Then, add the following under the ``build-n-publish-pypi`` section: +First, we'll define the job for building the dist packages of +your project and storing them for later use: .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml - :start-after: runs-on: + :start-after: jobs: :end-before: Install pypa/build This will download your repository into the CI runner and then -install and activate the newest available Python 3 release. It -also defines the package index to publish to, PyPI, and grants -a permission to the action that is mandatory for trusted -publishing. - -And now we can build dists from source. In this example, we'll -use ``build`` package. - -.. tip:: - - You can use any other method for building distributions as long as - it produces ready-to-upload artifacts saved into the - ``dist/`` folder. You can even use ``actions/upload-artifact`` and - ``actions/download-artifact`` to tranfer files between jobs or make them - accessable for download from the web CI interface. +install and activate the newest available Python 3 release. +And now we can build the dists from source and store them. +In this example, we'll use the ``build`` package. So add this to the steps list: .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml :start-after: version: "3.x" - :end-before: Actually publish to PyPI + :end-before: build-n-publish-pypi + +Defining a workflow job environment +=================================== +Now, let's add initial setup for our job that will publish to PyPI. +It's a process that will execute commands that we'll define later. +In this guide, we'll use the latest stable Ubuntu LTS version +provided by GitHub Actions. This also defines the package index +to publish to, PyPI, and grants a permission to the action that +is mandatory for trusted publishing. + +.. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml + :language: yaml + :start-after: name: python-package-distributions + :end-before: steps: Publishing the distribution to PyPI =================================== @@ -135,14 +125,14 @@ Finally, add the following steps at the end: .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml - :start-after: Actually publish to PyPI - :end-before: build-n-publish-testpypi + :lines: 39-47 This step uses the `pypa/gh-action-pypi-publish`_ GitHub -Action: It uploads the contents of the ``dist/`` folder -into PyPI unconditionally, but only if the current commit -is tagged. It is recommended you use the latest release -tag; a tool like GitHub's dependabot can keep +Action: After the stored distribution package has been +downloaded by the `download-artifact`_ action, it uploads +the contents of the ``dist/`` folder into PyPI unconditionally, +but only if the current commit is tagged. It is recommended you +use the latest release tag; a tool like GitHub's dependabot can keep these updated regularly. Separate workflow for publishing to TestPyPI @@ -173,6 +163,10 @@ sure that your release pipeline remains healthy! https://github.com/pypa/gh-action-pypi-publish .. _`pypa/gh-action-pypi-publish GitHub Action`: https://github.com/marketplace/actions/pypi-publish +.. _`download-artifact`: + https://github.com/actions/download-artifact +.. _`upload-artifact`: + https://github.com/actions/upload-artifact .. _Secrets: https://docs.github.com/en/actions/reference/encrypted-secrets .. _trusted publishing: https://docs.pypi.org/trusted-publishers/ From 9fe96b6955da3331e86f9c9068d28c249aad68e9 Mon Sep 17 00:00:00 2001 From: chrysle Date: Tue, 13 Jun 2023 17:10:59 +0200 Subject: [PATCH 0372/1072] Apply suggestions from code review Co-authored-by: Sviatoslav Sydorenko --- .../publish-to-test-pypi.yml | 7 +++---- ...n-releases-using-github-actions-ci-cd-workflows.rst | 10 +++++----- 2 files changed, 8 insertions(+), 9 deletions(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index c6e7c5091..f82ab400a 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -6,7 +6,6 @@ jobs: build: name: Build the source package runs-on: ubuntu-latest - steps: - uses: actions/checkout@v3 - name: Set up Python @@ -26,8 +25,8 @@ jobs: - name: Store the distribution packages uses: actions/upload-artifact@v3 with: - name: python-package-distributions - build-n-publish-pypi: + name: python-package-distributions + publish-to-pypi: name: Build and publish Python 🐍 distributions 📦 to PyPI runs-on: ubuntu-latest environment: @@ -45,7 +44,7 @@ jobs: - name: Publish distribution 📦 to PyPI if: startsWith(github.ref, 'refs/tags') uses: pypa/gh-action-pypi-publish@release/v1 - build-n-publish-testpypi: + publish-to-testpypi: name: Build and publish Python 🐍 distributions 📦 to TestPyPI runs-on: ubuntu-latest environment: diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index 44e626385..d917ca21b 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -9,7 +9,7 @@ popular choice is having a workflow that's triggered by a This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_ for -publishing and `upload-artifact`_ and `download-artifact`_ actions +publishing. It also uses GitHub's `upload-artifact`_ and `download-artifact`_ actions for temporarily storing and downloading the source packages. .. attention:: @@ -40,11 +40,11 @@ Let's begin! 🚀 1. Go to https://pypi.org/manage/account/publishing/. 2. Fill in the name you wish to publish your new project under, - your GitHub username and repository name and - the name of the release workflow file under - the ``.github/`` folder, see :ref:`workflow-definition`. + your GitHub username and repository name and + the name of the release workflow file under + the ``.github/`` folder, see :ref:`workflow-definition`. Finally add the name of the GitHub Actions environment - running under your repository. + set up under your repository. Register the trusted publisher. 3. Now, go to https://test.pypi.org/manage/account/publishing/ and repeat the second step. From 25ef74516bd1f90289e1aba59cc28b46005dd220 Mon Sep 17 00:00:00 2001 From: chrysle Date: Tue, 13 Jun 2023 17:45:10 +0200 Subject: [PATCH 0373/1072] Apply more suggestions and fix included fragments --- .../publish-to-test-pypi.yml | 4 +++- ...s-using-github-actions-ci-cd-workflows.rst | 19 +++++++++++-------- 2 files changed, 14 insertions(+), 9 deletions(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index f82ab400a..d9812596d 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -2,6 +2,9 @@ name: Publish Python 🐍 distributions 📦 to PyPI and TestPyPI on: push +# Only trigger this for tag changes. +if: startsWith(github.ref, 'refs/tags/') + jobs: build: name: Build the source package @@ -42,7 +45,6 @@ jobs: name: python-package-distributions path: dist/ - name: Publish distribution 📦 to PyPI - if: startsWith(github.ref, 'refs/tags') uses: pypa/gh-action-pypi-publish@release/v1 publish-to-testpypi: name: Build and publish Python 🐍 distributions 📦 to TestPyPI diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index d917ca21b..76aba47b6 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -44,10 +44,11 @@ Let's begin! 🚀 the name of the release workflow file under the ``.github/`` folder, see :ref:`workflow-definition`. Finally add the name of the GitHub Actions environment - set up under your repository. + (``pypi``) we're going set up under your repository. Register the trusted publisher. 3. Now, go to https://test.pypi.org/manage/account/publishing/ and repeat - the second step. + the second step, but now enter ``testpypi`` as the name of the + GitHub Actions environment. 4. Your "pending" publishers are now ready for their first use and will create your projects automatically once you use them for the first time. @@ -76,6 +77,11 @@ should make GitHub run this workflow: :language: yaml :end-before: jobs: +This will also assure that the release workflow is only triggered +if the current commit is tagged. It is recommended you use the +latest release tag; a tool like GitHub's dependabot can keep +these updated regularly. + Checking out the project and building distributions =================================================== @@ -101,7 +107,7 @@ So add this to the steps list: .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml :start-after: version: "3.x" - :end-before: build-n-publish-pypi + :end-before: publish-to-pypi Defining a workflow job environment =================================== @@ -125,15 +131,12 @@ Finally, add the following steps at the end: .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml - :lines: 39-47 + :lines: 41-48 This step uses the `pypa/gh-action-pypi-publish`_ GitHub Action: After the stored distribution package has been downloaded by the `download-artifact`_ action, it uploads -the contents of the ``dist/`` folder into PyPI unconditionally, -but only if the current commit is tagged. It is recommended you -use the latest release tag; a tool like GitHub's dependabot can keep -these updated regularly. +the contents of the ``dist/`` folder into PyPI unconditionally. Separate workflow for publishing to TestPyPI ============================================ From 1851d9f5d7841b68dd4384d69b281c56885dee84 Mon Sep 17 00:00:00 2001 From: chrysle Date: Fri, 30 Jun 2023 08:56:18 +0200 Subject: [PATCH 0374/1072] Apply suggestions from code review Co-authored-by: Sviatoslav Sydorenko --- .../publish-to-test-pypi.yml | 28 +++++++++++++------ ...s-using-github-actions-ci-cd-workflows.rst | 17 ++++++----- 2 files changed, 30 insertions(+), 15 deletions(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index d9812596d..3c418017f 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -2,13 +2,11 @@ name: Publish Python 🐍 distributions 📦 to PyPI and TestPyPI on: push -# Only trigger this for tag changes. -if: startsWith(github.ref, 'refs/tags/') - jobs: build: name: Build the source package runs-on: ubuntu-latest + steps: - uses: actions/checkout@v3 - name: Set up Python @@ -22,15 +20,19 @@ jobs: build --user - name: Build a binary wheel and a source tarball - run: >- - python3 -m - build + run: python3 -m build - name: Store the distribution packages uses: actions/upload-artifact@v3 with: name: python-package-distributions + path: dist/ + publish-to-pypi: - name: Build and publish Python 🐍 distributions 📦 to PyPI + name: >- + Publish Python 🐍 distributions 📦 to PyPI + and sign them with Sigstore + needs: + - build runs-on: ubuntu-latest environment: name: pypi @@ -46,8 +48,18 @@ jobs: path: dist/ - name: Publish distribution 📦 to PyPI uses: pypa/gh-action-pypi-publish@release/v1 + - name: Sign the dists with Sigstore + uses: sigstore/gh-action-sigstore-python@v1.2.3 + with: + inputs: >- + ./dist/*.tar.gz + ./dist/*.whl + publish-to-testpypi: name: Build and publish Python 🐍 distributions 📦 to TestPyPI + if: startsWith(github.ref, 'refs/tags/') # only publish to PyPI on tag pushes + needs: + - build runs-on: ubuntu-latest environment: name: testpypi @@ -61,7 +73,7 @@ jobs: with: name: python-package-distributions path: dist/ - - name: Publish distribution 📦 to Test PyPI + - name: Publish distribution 📦 to TestPyPI uses: pypa/gh-action-pypi-publish@release/v1 with: repository-url: https://test.pypi.org/legacy/ diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index 76aba47b6..94f35a0dd 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -25,9 +25,9 @@ Configuring trusted publishing This guide relies on PyPI's `trusted publishing`_ implementation to connect to `GitHub Actions CI/CD`_. This is recommended for security reasons, since the generated tokens are created for each of your projects -individually and expire automatically. Otherwise you'll need to generate an +individually and expire automatically. Otherwise, you'll need to generate an `API token`_ for both PyPI and TestPyPI. In case of publishing to third-party -indexes like :doc:`devpi `, you will need to provide a +indexes like :doc:`devpi `, you may need to provide a username/password combination. Since this guide will demonstrate uploading to both @@ -77,7 +77,7 @@ should make GitHub run this workflow: :language: yaml :end-before: jobs: -This will also assure that the release workflow is only triggered +This will also ensure that the release workflow is only triggered if the current commit is tagged. It is recommended you use the latest release tag; a tool like GitHub's dependabot can keep these updated regularly. @@ -115,9 +115,11 @@ Defining a workflow job environment Now, let's add initial setup for our job that will publish to PyPI. It's a process that will execute commands that we'll define later. In this guide, we'll use the latest stable Ubuntu LTS version -provided by GitHub Actions. This also defines the package index -to publish to, PyPI, and grants a permission to the action that -is mandatory for trusted publishing. +provided by GitHub Actions. This also defines a GitHub Environment +for the job to run in its context and a URL to be displayed in GitHub's +UI nicely. Additionally, it allows aqcuiring an OpenID Connect token +which is mandartory that the ``pypi-publish`` actions needs to +implement secretless trusted publishing to PyPI. .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml @@ -134,9 +136,10 @@ Finally, add the following steps at the end: :lines: 41-48 This step uses the `pypa/gh-action-pypi-publish`_ GitHub -Action: After the stored distribution package has been +Action: after the stored distribution package has been downloaded by the `download-artifact`_ action, it uploads the contents of the ``dist/`` folder into PyPI unconditionally. +This job also signs the artifacts with Sigstore right after publishing them to PyPI. Separate workflow for publishing to TestPyPI ============================================ From 3653382278caaf4a9bc49801545d1a24e4973d2c Mon Sep 17 00:00:00 2001 From: chrysle Date: Fri, 30 Jun 2023 14:39:48 +0200 Subject: [PATCH 0375/1072] Apply further improvements --- .../publish-to-test-pypi.yml | 6 +-- ...s-using-github-actions-ci-cd-workflows.rst | 42 ++++++++++++++----- 2 files changed, 35 insertions(+), 13 deletions(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index 3c418017f..898da663e 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -1,10 +1,10 @@ -name: Publish Python 🐍 distributions 📦 to PyPI and TestPyPI +name: Publish Python 🐍 distribution packages 📦 to PyPI and TestPyPI on: push jobs: build: - name: Build the source package + name: Build distribution packages runs-on: ubuntu-latest steps: @@ -29,7 +29,7 @@ jobs: publish-to-pypi: name: >- - Publish Python 🐍 distributions 📦 to PyPI + Publish Python 🐍 distribution packages 📦 to PyPI and sign them with Sigstore needs: - build diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index 94f35a0dd..51a3ea598 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -33,13 +33,25 @@ username/password combination. Since this guide will demonstrate uploading to both PyPI and TestPyPI, we'll need two trusted publishers configured. The following steps will lead you through creating the "pending" publishers -for your new project. However it is also possible to add `trusted publishing`_ -to any pre-existing project, if you are its owner. +for your new :term:`PyPI project `. +However it is also possible to add `trusted publishing`_ to any +pre-existing project, if you are its owner. + + .. attention:: + + If you followed earlier versions of this guide, you will + have created the secrets ``PYPI_API_TOKEN`` and ``TEST_PYPI_API_TOKEN`` + for direct PyPI and TestPyPI access. These are obsolete now and + you should remove them from your GitHub repository and revoke + them in your PyPI and TestPyPI account settings. + Let's begin! 🚀 1. Go to https://pypi.org/manage/account/publishing/. -2. Fill in the name you wish to publish your new project under, +2. Fill in the name you wish to publish your new + :term:`PyPI project ` under + (the ``name`` value in your ``setup.cfg`` or ``pyproject.toml``), your GitHub username and repository name and the name of the release workflow file under the ``.github/`` folder, see :ref:`workflow-definition`. @@ -53,12 +65,18 @@ Let's begin! 🚀 create your projects automatically once you use them for the first time. - .. attention:: + .. note:: If you don't have a TestPyPI account, you'll need to create it. It's not the same as a regular PyPI account. + .. hint:: + + For security reasons, you should require manual approval + on each run for the ``pypi`` environment. + + .. _workflow-definition: Creating a workflow definition @@ -79,8 +97,7 @@ should make GitHub run this workflow: This will also ensure that the release workflow is only triggered if the current commit is tagged. It is recommended you use the -latest release tag; a tool like GitHub's dependabot can keep -these updated regularly. +latest release tag. Checking out the project and building distributions =================================================== @@ -123,7 +140,7 @@ implement secretless trusted publishing to PyPI. .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml - :start-after: name: python-package-distributions + :start-after: path: dist/ :end-before: steps: Publishing the distribution to PyPI @@ -133,13 +150,15 @@ Finally, add the following steps at the end: .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml - :lines: 41-48 + :start-after: id-token: write + :end-before: publish-to-testpypi: This step uses the `pypa/gh-action-pypi-publish`_ GitHub Action: after the stored distribution package has been downloaded by the `download-artifact`_ action, it uploads the contents of the ``dist/`` folder into PyPI unconditionally. -This job also signs the artifacts with Sigstore right after publishing them to PyPI. +This job also signs the artifacts with the `sigstore/gh-action-sigstore-python`_ +GitHub Action publishing them to PyPI. Separate workflow for publishing to TestPyPI ============================================ @@ -150,7 +169,8 @@ section: .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml - :start-after: uses: pypa/gh-action-pypi-publish@release/v1 + :start-after: ./dist/*.whl + That's all, folks! ================== @@ -173,6 +193,8 @@ sure that your release pipeline remains healthy! https://github.com/actions/download-artifact .. _`upload-artifact`: https://github.com/actions/upload-artifact +.. _`sigstore/gh-action-sigstore-python`: + https://github.com/marketplace/actions/gh-action-sigstore-python .. _Secrets: https://docs.github.com/en/actions/reference/encrypted-secrets .. _trusted publishing: https://docs.pypi.org/trusted-publishers/ From 4580825dae3209228331334c3d7cd2d57134e533 Mon Sep 17 00:00:00 2001 From: chrysle Date: Mon, 24 Jul 2023 16:22:54 +0200 Subject: [PATCH 0376/1072] Apply suggestions from code review Co-authored-by: Sviatoslav Sydorenko --- .../github-actions-ci-cd-sample/publish-to-test-pypi.yml | 4 ++-- ...bution-releases-using-github-actions-ci-cd-workflows.rst | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index 898da663e..7026aad5f 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -1,4 +1,4 @@ -name: Publish Python 🐍 distribution packages 📦 to PyPI and TestPyPI +name: Publish Python 🐍 distributions 📦 to PyPI and TestPyPI on: push @@ -29,7 +29,7 @@ jobs: publish-to-pypi: name: >- - Publish Python 🐍 distribution packages 📦 to PyPI + Publish Python 🐍 distribution 📦 to PyPI and sign them with Sigstore needs: - build diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index 51a3ea598..234593670 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -39,11 +39,11 @@ pre-existing project, if you are its owner. .. attention:: - If you followed earlier versions of this guide, you will + If you followed earlier versions of this guide, you have created the secrets ``PYPI_API_TOKEN`` and ``TEST_PYPI_API_TOKEN`` for direct PyPI and TestPyPI access. These are obsolete now and you should remove them from your GitHub repository and revoke - them in your PyPI and TestPyPI account settings. + them in your PyPI and TestPyPI account settings in case you are replacing your old setup with the new one. Let's begin! 🚀 @@ -135,7 +135,7 @@ In this guide, we'll use the latest stable Ubuntu LTS version provided by GitHub Actions. This also defines a GitHub Environment for the job to run in its context and a URL to be displayed in GitHub's UI nicely. Additionally, it allows aqcuiring an OpenID Connect token -which is mandartory that the ``pypi-publish`` actions needs to +which is mandatory that the ``pypi-publish`` actions needs to implement secretless trusted publishing to PyPI. .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml From 1f4a242fc383e276422af9f7168e682d237d3d91 Mon Sep 17 00:00:00 2001 From: chrysle Date: Sat, 26 Aug 2023 11:18:49 +0200 Subject: [PATCH 0377/1072] Apply further suggestions and improvements Add `sphinx-toolbox` dependency. --- requirements.txt | 1 + source/conf.py | 1 + .../publish-to-test-pypi.yml | 52 +++++++++----- ...s-using-github-actions-ci-cd-workflows.rst | 67 ++++++++++++------- 4 files changed, 79 insertions(+), 42 deletions(-) diff --git a/requirements.txt b/requirements.txt index 125f0cf33..17492e03c 100644 --- a/requirements.txt +++ b/requirements.txt @@ -4,3 +4,4 @@ sphinx-inline-tabs==2021.4.11b9 python-docs-theme==2022.1 sphinx-copybutton==0.5.0 pypa-docs-theme @ git+https://github.com/pypa/pypa-docs-theme.git +sphinx-toolbox==3.5.0 diff --git a/source/conf.py b/source/conf.py index 7ff60c18c..9113b8c68 100644 --- a/source/conf.py +++ b/source/conf.py @@ -36,6 +36,7 @@ 'sphinx.ext.todo', 'sphinx_inline_tabs', 'sphinx_copybutton', + 'sphinx_toolbox.collapse', ] # config for copy button diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index 7026aad5f..28663d51f 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -1,10 +1,10 @@ -name: Publish Python 🐍 distributions 📦 to PyPI and TestPyPI +name: Publish Python 🐍 distribution 📦 to PyPI and TestPyPI on: push jobs: build: - name: Build distribution packages + name: Build distribution 📦 runs-on: ubuntu-latest steps: @@ -30,34 +30,52 @@ jobs: publish-to-pypi: name: >- Publish Python 🐍 distribution 📦 to PyPI - and sign them with Sigstore + if: startsWith(github.ref, 'refs/tags/') # only publish to PyPI on tag pushes needs: - build runs-on: ubuntu-latest environment: name: pypi + # Fill in your project (e.g. repository) name + # for url: https://pypi.org/p/ permissions: id-token: write steps: - name: Download all the dists - uses: actions/download-artifact@v3 - with: - name: python-package-distributions - path: dist/ - - name: Publish distribution 📦 to PyPI - uses: pypa/gh-action-pypi-publish@release/v1 - - name: Sign the dists with Sigstore - uses: sigstore/gh-action-sigstore-python@v1.2.3 - with: - inputs: >- - ./dist/*.tar.gz - ./dist/*.whl + uses: actions/download-artifact@v3 + with: + name: python-package-distributions + path: dist/ + - name: Publish distribution 📦 to PyPI + uses: pypa/gh-action-pypi-publish@release/v1 + + github-release: + name: >- + Sign the Python 🐍 distribution 📦 with Sigstore + and upload them to GitHub Release + needs: + - publish-to-pypi + steps: + - name: Sign the dists with Sigstore + uses: sigstore/gh-action-sigstore-python@v1.2.3 + with: + inputs: >- + ./dist/*.tar.gz + ./dist/*.whl + - name: Upload artifact signatures to GitHub Release + # Confusingly, this action also supports updating releases, not + # just creating them. This is what we want here, since we've manually + # created the release above. + uses: softprops/action-gh-release@v1 + with: + # dist/ contains the built packages, which smoketest-artifacts/ + # contains the signatures and certificates. + files: dist/** publish-to-testpypi: - name: Build and publish Python 🐍 distributions 📦 to TestPyPI - if: startsWith(github.ref, 'refs/tags/') # only publish to PyPI on tag pushes + name: Publish Python 🐍 distribution 📦 to TestPyPI needs: - build runs-on: ubuntu-latest diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index 234593670..500379c9f 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -9,7 +9,7 @@ popular choice is having a workflow that's triggered by a This guide shows you how to publish a Python distribution whenever a tagged commit is pushed. It will use the `pypa/gh-action-pypi-publish GitHub Action`_ for -publishing. It also uses GitHub's `upload-artifact`_ and `download-artifact`_ actions +publishing. It also uses GitHub's `upload-artifact`_ and `download-artifact`_ actions for temporarily storing and downloading the source packages. .. attention:: @@ -23,7 +23,7 @@ Configuring trusted publishing ============================== This guide relies on PyPI's `trusted publishing`_ implementation to connect -to `GitHub Actions CI/CD`_. This is recommended for security reasons, since +to `GitHub Actions CI/CD`_. This is recommended for security reasons, since the generated tokens are created for each of your projects individually and expire automatically. Otherwise, you'll need to generate an `API token`_ for both PyPI and TestPyPI. In case of publishing to third-party @@ -31,7 +31,7 @@ indexes like :doc:`devpi `, you may need to provide a username/password combination. Since this guide will demonstrate uploading to both -PyPI and TestPyPI, we'll need two trusted publishers configured. +PyPI and TestPyPI, we'll need two trusted publishers configured. The following steps will lead you through creating the "pending" publishers for your new :term:`PyPI project `. However it is also possible to add `trusted publishing`_ to any @@ -52,8 +52,8 @@ Let's begin! 🚀 2. Fill in the name you wish to publish your new :term:`PyPI project ` under (the ``name`` value in your ``setup.cfg`` or ``pyproject.toml``), - your GitHub username and repository name and - the name of the release workflow file under + the GitHub repository owner's name (org or user) + and repository name and the name of the release workflow file under the ``.github/`` folder, see :ref:`workflow-definition`. Finally add the name of the GitHub Actions environment (``pypi``) we're going set up under your repository. @@ -61,8 +61,8 @@ Let's begin! 🚀 3. Now, go to https://test.pypi.org/manage/account/publishing/ and repeat the second step, but now enter ``testpypi`` as the name of the GitHub Actions environment. -4. Your "pending" publishers are now ready for their first use and will - create your projects automatically once you use them +4. Your "pending" publishers are now ready for their first use and will + create your projects automatically once you use them for the first time. .. note:: @@ -95,23 +95,19 @@ should make GitHub run this workflow: :language: yaml :end-before: jobs: -This will also ensure that the release workflow is only triggered -if the current commit is tagged. It is recommended you use the -latest release tag. - Checking out the project and building distributions =================================================== -We will have to define two jobs to publish to PyPI -and TestPyPI respectively, and an additional job to +We will have to define two jobs to publish to PyPI +and TestPyPI respectively, and an additional job to build the distribution packages. -First, we'll define the job for building the dist packages of +First, we'll define the job for building the dist packages of your project and storing them for later use: .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml - :start-after: jobs: + :start-at: jobs: :end-before: Install pypa/build This will download your repository into the CI runner and then @@ -123,7 +119,7 @@ So add this to the steps list: .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml - :start-after: version: "3.x" + :start-at: Install pypa/build :end-before: publish-to-pypi Defining a workflow job environment @@ -135,14 +131,18 @@ In this guide, we'll use the latest stable Ubuntu LTS version provided by GitHub Actions. This also defines a GitHub Environment for the job to run in its context and a URL to be displayed in GitHub's UI nicely. Additionally, it allows aqcuiring an OpenID Connect token -which is mandatory that the ``pypi-publish`` actions needs to -implement secretless trusted publishing to PyPI. +that the ``pypi-publish`` actions needs to implement secretless +trusted publishing to PyPI. .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml :start-after: path: dist/ :end-before: steps: +This will also ensure that the PyPI publishing workflow is only triggered +if the current commit is tagged. It is recommended you use the +latest release tag. + Publishing the distribution to PyPI =================================== @@ -151,14 +151,24 @@ Finally, add the following steps at the end: .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml :start-after: id-token: write - :end-before: publish-to-testpypi: + :end-before: github-release: This step uses the `pypa/gh-action-pypi-publish`_ GitHub -Action: after the stored distribution package has been -downloaded by the `download-artifact`_ action, it uploads +Action: after the stored distribution package has been +downloaded by the `download-artifact`_ action, it uploads the contents of the ``dist/`` folder into PyPI unconditionally. -This job also signs the artifacts with the `sigstore/gh-action-sigstore-python`_ -GitHub Action publishing them to PyPI. + +Signing the distribution packages +================================= + +This additional job signs the distribution packages with the +`sigstore/gh-action-sigstore-python GitHub Action`_ and then uploads +them to GitHub Release. + +.. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml + :language: yaml + :start-at: github-release: + :end-before: publish-to-testpypi Separate workflow for publishing to TestPyPI ============================================ @@ -169,8 +179,15 @@ section: .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml - :start-after: ./dist/*.whl + :start-at: publish-to-testpypi + +The whole CD workflow +===================== + +.. collapse:: Load file + .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml + :language: yaml That's all, folks! ================== @@ -193,7 +210,7 @@ sure that your release pipeline remains healthy! https://github.com/actions/download-artifact .. _`upload-artifact`: https://github.com/actions/upload-artifact -.. _`sigstore/gh-action-sigstore-python`: +.. _`sigstore/gh-action-sigstore-python GitHub Action`: https://github.com/marketplace/actions/gh-action-sigstore-python .. _Secrets: https://docs.github.com/en/actions/reference/encrypted-secrets From eca62e47aba879690e081ed47ef0a50096eda7f6 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Wed, 6 Sep 2023 22:17:41 +0200 Subject: [PATCH 0378/1072] Enable testing merge queues @ GitHub Actions CI/CD --- .github/workflows/test.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index 58505e1a5..81ba983f6 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -1,6 +1,7 @@ name: Test on: + merge_group: push: pull_request: schedule: From ac29d07bed72418d4f5e4fda883a260f9423cb39 Mon Sep 17 00:00:00 2001 From: Dimitri Papadopoulos <3234522+DimitriPapadopoulos@users.noreply.github.com> Date: Mon, 17 Jul 2023 10:51:17 +0200 Subject: [PATCH 0379/1072] Fix typos found by codespell --- source/contribute.rst | 2 +- ...tion-releases-using-github-actions-ci-cd-workflows.rst | 4 ++-- source/key_projects.rst | 2 +- source/news.rst | 4 ++-- source/specifications/recording-installed-packages.rst | 8 ++++---- source/specifications/virtual-environments.rst | 2 +- 6 files changed, 11 insertions(+), 11 deletions(-) diff --git a/source/contribute.rst b/source/contribute.rst index 10ea0c025..0c538aaec 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -63,7 +63,7 @@ document `. Specifications -------------- -Specifications are reference documention focused on comprehensively documenting +Specifications are reference documentation focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `. diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index 19f70f040..382fb9fd8 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -103,8 +103,8 @@ use ``build`` package. You can use any other method for building distributions as long as it produces ready-to-upload artifacts saved into the ``dist/`` folder. You can even use ``actions/upload-artifact`` and - ``actions/download-artifact`` to tranfer files between jobs or make them - accessable for download from the web CI interface. + ``actions/download-artifact`` to transfer files between jobs or make them + accessible for download from the web CI interface. So add this to the steps list: diff --git a/source/key_projects.rst b/source/key_projects.rst index d7cf57f4d..7648f3b65 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -184,7 +184,7 @@ check for CVEs in `Pipfile` using `safety `_. Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows -(which other tools often underserve), makes and checkes file hashes, +(which other tools often underserve), makes and checks file hashes, to ensure compliance with hash-locked dependency specifiers, and eases uninstallation of packages and dependencies. diff --git a/source/news.rst b/source/news.rst index f6bdbbf27..09415fddd 100644 --- a/source/news.rst +++ b/source/news.rst @@ -118,7 +118,7 @@ March 2018 - Updated "installing scientific packages". (:pr:`455`) - Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`) - Clarified a long description classifier on pypi.org. (:pr:`456`) -- Updated Core Metadata spec to follw PEP 556. (:pr:`412`) +- Updated Core Metadata spec to follow PEP 556. (:pr:`412`) February 2018 ------------- @@ -214,7 +214,7 @@ April 2017 - Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`) - Updated development mode documentation to mention that order of local packages matters. (:pr:`208`) - Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`) -- Swaped order of :file:`setup.py` arguments for the upload command, as order +- Swapped order of :file:`setup.py` arguments for the upload command, as order is significant. (:pr:`260`) - Explained how to install from unsupported sources using a helper application. (:pr:`289`) diff --git a/source/specifications/recording-installed-packages.rst b/source/specifications/recording-installed-packages.rst index bac887b2b..11d2c3bfa 100644 --- a/source/specifications/recording-installed-packages.rst +++ b/source/specifications/recording-installed-packages.rst @@ -59,14 +59,14 @@ encouraged to start normalizing those fields. .. note:: - The ``.dist-info`` directory's name is formatted to unambigiously represent + The ``.dist-info`` directory's name is formatted to unambiguously represent a distribution as a filesystem path. Tools presenting a distribution name to a user should avoid using the normalized name, and instead present the specified name (when needed prior to resolution to an installed package), or read the respective fields in Core Metadata, since values listed there are unescaped and accurately reflect the distribution. Libraries should provide API for such tools to consume, so tools can have access to the - unnormalized name when displaying distrubution information. + unnormalized name when displaying distribution information. This ``.dist-info`` directory may contain the following files, described in detail below: @@ -234,7 +234,7 @@ packages into a Python environment to ensure that other tools are not used to uninstall or otherwise modify that installed package, as doing so may cause compatibility problems with the wider environment. -To achieve this, affected tools should take the folllowing steps: +To achieve this, affected tools should take the following steps: * Rename or remove the ``RECORD`` file to prevent changes via other tools (e.g. appending a suffix to create a non-standard ``RECORD.tool`` file if the tool @@ -251,4 +251,4 @@ ensuring both locations appear on the default Python import path). In some circumstances, it may be desirable to block even installation of additional packages via Python-specific tools. For these cases refer to -:ref:`externally-managed-environments` \ No newline at end of file +:ref:`externally-managed-environments` diff --git a/source/specifications/virtual-environments.rst b/source/specifications/virtual-environments.rst index c38c2faeb..77c8c3627 100644 --- a/source/specifications/virtual-environments.rst +++ b/source/specifications/virtual-environments.rst @@ -19,7 +19,7 @@ Runtime detection of virtual environments At runtime, virtual environments can be identified by virtue of ``sys.prefix`` (the filesystem location of the running interpreter) having a different value -from ``sys.base_prefix`` (the default filesytem location of the standard library +from ``sys.base_prefix`` (the default filesystem location of the standard library directories). :ref:`venv-explanation` in the Python standard library documentation for the From 04c2d07f0dda985e7f6164eca6735fff518cdd1b Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Wed, 6 Sep 2023 22:24:32 +0200 Subject: [PATCH 0380/1072] Add a gate job to GHA CI/CD --- .github/workflows/test.yml | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index 81ba983f6..a5095d774 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -39,3 +39,21 @@ jobs: - name: Nox ${{ matrix.noxenv }} run: | python -m nox -s ${{ matrix.noxenv }} + + + check: + # This job does nothing and is only used for the branch protection + # or multi-stage CI jobs, like making sure that all tests pass before + # a publishing job is started. + if: always() + + needs: + - build + + runs-on: ubuntu-latest + + steps: + - name: Decide whether the needed jobs succeeded or failed + uses: re-actors/alls-green@release/v1 + with: + jobs: ${{ toJSON(needs) }} From 8f959b0661d170a7bc243731d6477d9f1539436d Mon Sep 17 00:00:00 2001 From: Mike Fiedler Date: Mon, 4 Sep 2023 10:36:13 -0400 Subject: [PATCH 0381/1072] chore: update python versions used Updated in different places at different times. Make consistent for now. Refs: https://github.com/pypa/packaging.python.org/pull/820/commits/675acbb5eb3f9ebfa954bf603ecdc3d24b202533 Refs: https://github.com/pypa/packaging.python.org/pull/1247/commits/90a1d075646846a3a56dbbc0164ec7efaf729d5b Signed-off-by: Mike Fiedler --- .github/workflows/test.yml | 2 +- source/contribute.rst | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index a5095d774..5da04a342 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -28,7 +28,7 @@ jobs: - name: Set up Python uses: actions/setup-python@v4 with: - python-version: 3.9 + python-version: "3.11" cache: 'pip' cache-dependency-path: 'requirements.txt' diff --git a/source/contribute.rst b/source/contribute.rst index 0c538aaec..0dbdc1adc 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -131,9 +131,9 @@ need: python -m pip install --user nox -2. Python 3.8. Our build scripts are usually tested with Python 3.8 only. +2. Python 3.11. Our build scripts are usually tested with Python 3.11 only. See the :doc:`Hitchhiker's Guide to Python installation instructions ` - to install Python 3.8 on your operating system. + to install Python 3.11 on your operating system. To build the guide, run the following shell command in the project's root folder: From 7b86e9c2d1e6c8cd27f3d3930261526e8ca96b97 Mon Sep 17 00:00:00 2001 From: chrysle Date: Tue, 12 Sep 2023 18:19:47 +0200 Subject: [PATCH 0382/1072] Apply suggestions from code review Co-authored-by: Sviatoslav Sydorenko --- .../publish-to-test-pypi.yml | 30 ++++++++++++------- 1 file changed, 19 insertions(+), 11 deletions(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index 28663d51f..4021ac585 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -40,16 +40,16 @@ jobs: # for url: https://pypi.org/p/ permissions: - id-token: write + id-token: write # IMPORTANT: mandatory for trusted publishing steps: - - name: Download all the dists - uses: actions/download-artifact@v3 - with: - name: python-package-distributions - path: dist/ - - name: Publish distribution 📦 to PyPI - uses: pypa/gh-action-pypi-publish@release/v1 + - name: Download all the dists + uses: actions/download-artifact@v3 + with: + name: python-package-distributions + path: dist/ + - name: Publish distribution 📦 to PyPI + uses: pypa/gh-action-pypi-publish@release/v1 github-release: name: >- @@ -57,6 +57,12 @@ jobs: and upload them to GitHub Release needs: - publish-to-pypi + runs-on: ubuntu-latest + + permissions: + contents: write # IMPORTANT: mandatory for making GitHub Releases + id-token: write # IMPORTANT: mandatory for sigstore + steps: - name: Sign the dists with Sigstore uses: sigstore/gh-action-sigstore-python@v1.2.3 @@ -70,8 +76,8 @@ jobs: # created the release above. uses: softprops/action-gh-release@v1 with: - # dist/ contains the built packages, which smoketest-artifacts/ - # contains the signatures and certificates. + # `dist/` contains the built packages, and the + # sigstore-produced signatures and certificates. files: dist/** publish-to-testpypi: @@ -79,11 +85,13 @@ jobs: needs: - build runs-on: ubuntu-latest + environment: name: testpypi url: https://test.pypi.org/p/ + permissions: - id-token: write + id-token: write # IMPORTANT: mandatory for trusted publishing steps: - name: Download all the dists From 73725c7cda299a0a60ac783362ae22f777e9bfcf Mon Sep 17 00:00:00 2001 From: chrysle Date: Tue, 12 Sep 2023 19:02:42 +0200 Subject: [PATCH 0383/1072] Address more review comments --- .../publish-to-test-pypi.yml | 36 ++++++++++--------- ...s-using-github-actions-ci-cd-workflows.rst | 16 +++++++-- 2 files changed, 32 insertions(+), 20 deletions(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index 4021ac585..5592f7bae 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -36,8 +36,7 @@ jobs: runs-on: ubuntu-latest environment: name: pypi - # Fill in your project (e.g. repository) name - # for + # Fill in your project (e.g. repository) name for url: https://pypi.org/p/ permissions: id-token: write # IMPORTANT: mandatory for trusted publishing @@ -64,21 +63,24 @@ jobs: id-token: write # IMPORTANT: mandatory for sigstore steps: - - name: Sign the dists with Sigstore - uses: sigstore/gh-action-sigstore-python@v1.2.3 - with: - inputs: >- - ./dist/*.tar.gz - ./dist/*.whl - - name: Upload artifact signatures to GitHub Release - # Confusingly, this action also supports updating releases, not - # just creating them. This is what we want here, since we've manually - # created the release above. - uses: softprops/action-gh-release@v1 - with: - # `dist/` contains the built packages, and the - # sigstore-produced signatures and certificates. - files: dist/** + - name: Download all the dists + uses: actions/download-artifact@v3 + with: + name: python-package-distributions + path: dist/ + - name: Sign the dists with Sigstore + uses: sigstore/gh-action-sigstore-python@v1.2.3 + with: + inputs: >- + ./dist/*.tar.gz + ./dist/*.whl + - name: Upload artifact signatures to GitHub Release + env: + GH_TOKEN: ${{ github.token }} + # Upload to GitHub Release using the `gh` CLI. + # `dist/` contains the built packages, and the + # sigstore-produced signatures and certificates. + run: gh release upload "${{ github.ref_name }}" dist/** --repo "${{ github.repository }}" publish-to-testpypi: name: Publish Python 🐍 distribution 📦 to TestPyPI diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index 500379c9f..0c54f282f 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -170,6 +170,14 @@ them to GitHub Release. :start-at: github-release: :end-before: publish-to-testpypi + +.. note:: + + This is a replacement for GPG signatures, for which support has been + `removed `_ by PyPI. + However, this job is not mandatory for defining the workflow. + + Separate workflow for publishing to TestPyPI ============================================ @@ -181,10 +189,12 @@ section: :language: yaml :start-at: publish-to-testpypi -The whole CD workflow -===================== +The whole CI/CD workflow +======================== + +This paragraph showcases the whole workflow after following the above guide. -.. collapse:: Load file +.. collapse:: Click here to display the entire GitHub Actions CI/CD workflow definition .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml From 234b18c1523cd7d0c0780962530d9ab8361eadb4 Mon Sep 17 00:00:00 2001 From: chrysle Date: Wed, 13 Sep 2023 10:54:53 +0200 Subject: [PATCH 0384/1072] Address more review comments Co-authored-by: Stephen Rosen <1300022+sirosen@users.noreply.github.com> Co-authored-by: Sviatoslav Sydorenko --- .../publish-to-test-pypi.yml | 8 ++--- ...s-using-github-actions-ci-cd-workflows.rst | 33 +++++++++++-------- 2 files changed, 24 insertions(+), 17 deletions(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index 5592f7bae..70f4d39c7 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -8,7 +8,7 @@ jobs: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v3 + - uses: actions/checkout@v4 - name: Set up Python uses: actions/setup-python@v4 with: @@ -36,7 +36,7 @@ jobs: runs-on: ubuntu-latest environment: name: pypi - # Fill in your project (e.g. repository) name for + # Replace below with your PyPI project name: url: https://pypi.org/p/ permissions: id-token: write # IMPORTANT: mandatory for trusted publishing @@ -76,11 +76,11 @@ jobs: ./dist/*.whl - name: Upload artifact signatures to GitHub Release env: - GH_TOKEN: ${{ github.token }} + GITHUB_TOKEN: ${{ github.token }} # Upload to GitHub Release using the `gh` CLI. # `dist/` contains the built packages, and the # sigstore-produced signatures and certificates. - run: gh release upload "${{ github.ref_name }}" dist/** --repo "${{ github.repository }}" + run: gh release upload "${{ github.ref_name }}" dist/** publish-to-testpypi: name: Publish Python 🐍 distribution 📦 to TestPyPI diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index 719de7455..df9173b5f 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -52,15 +52,15 @@ Let's begin! 🚀 2. Fill in the name you wish to publish your new :term:`PyPI project ` under (the ``name`` value in your ``setup.cfg`` or ``pyproject.toml``), - the GitHub repository owner's name (org or user) - and repository name and the name of the release workflow file under + the GitHub repository owner's name (org or user), + and repository name, and the name of the release workflow file under the ``.github/`` folder, see :ref:`workflow-definition`. - Finally add the name of the GitHub Actions environment + Finally, add the name of the GitHub Environment (``pypi``) we're going set up under your repository. Register the trusted publisher. 3. Now, go to https://test.pypi.org/manage/account/publishing/ and repeat - the second step, but now enter ``testpypi`` as the name of the - GitHub Actions environment. + the second step, but this time, enter ``testpypi`` as the name of the + GitHub Environment. 4. Your "pending" publishers are now ready for their first use and will create your projects automatically once you use them for the first time. @@ -71,9 +71,9 @@ Let's begin! 🚀 create it. It's not the same as a regular PyPI account. - .. hint:: + .. attention:: - For security reasons, you should require manual approval + For security reasons, you must require `manual approval `_ on each run for the ``pypi`` environment. @@ -140,7 +140,7 @@ trusted publishing to PyPI. :end-before: steps: This will also ensure that the PyPI publishing workflow is only triggered -if the current commit is tagged. It is recommended you use the +if the current commit is tagged. It is recommended that you commit using the latest release tag. Publishing the distribution to PyPI @@ -161,9 +161,11 @@ the contents of the ``dist/`` folder into PyPI unconditionally. Signing the distribution packages ================================= -This additional job signs the distribution packages with `Sigstore`_, -using the `sigstore/gh-action-sigstore-python GitHub Action`_, -and then uploads them to GitHub Release. +The following job signs the distribution packages with `Sigstore`_, +the same artifact signing system `used to sign CPython `_. + +It uses the `sigstore/gh-action-sigstore-python GitHub Action`_, +and then uploads them to a GitHub Release. .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml @@ -174,8 +176,8 @@ and then uploads them to GitHub Release. .. note:: This is a replacement for GPG signatures, for which support has been - `removed `_ by PyPI. - However, this job is not mandatory for defining the workflow. + `removed from PyPI `_. + However, this job is not mandatory for uploading to PyPI and can be omitted. Separate workflow for publishing to TestPyPI @@ -189,6 +191,11 @@ section: :language: yaml :start-at: publish-to-testpypi +.. tip:: + + Requiring manual approvals in the ``testpypi`` GitHub Environment is typically unnecessary as it's designed to run on each commit to the main branch and is often used to indicate a healthy release publishing pipeline. + + The whole CI/CD workflow ======================== From 0d71546dfb04d91b61faef06381099082614fbc3 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Wed, 13 Sep 2023 17:45:02 +0200 Subject: [PATCH 0385/1072] Move the env URL comment inline @ pypi job --- .../github-actions-ci-cd-sample/publish-to-test-pypi.yml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index 70f4d39c7..aa207f429 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -36,8 +36,7 @@ jobs: runs-on: ubuntu-latest environment: name: pypi - # Replace below with your PyPI project name: - url: https://pypi.org/p/ + url: https://pypi.org/p/ # Replace with your PyPI project name permissions: id-token: write # IMPORTANT: mandatory for trusted publishing From 63f738a9ef7a8b0c4e5de54ece427ddd2316563a Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Wed, 13 Sep 2023 17:47:54 +0200 Subject: [PATCH 0386/1072] Restore passing `--repo` to `gh` @ sigstore job --- .../github-actions-ci-cd-sample/publish-to-test-pypi.yml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index aa207f429..20ed37740 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -79,7 +79,10 @@ jobs: # Upload to GitHub Release using the `gh` CLI. # `dist/` contains the built packages, and the # sigstore-produced signatures and certificates. - run: gh release upload "${{ github.ref_name }}" dist/** + run: >- + gh release upload + '${{ github.ref_name }}' dist/** + --repo '${{ github.repository }}' publish-to-testpypi: name: Publish Python 🐍 distribution 📦 to TestPyPI From 922208b72c6b1f1fec8a4c08ce82598271c7ab08 Mon Sep 17 00:00:00 2001 From: chrysle Date: Thu, 14 Sep 2023 08:16:55 +0200 Subject: [PATCH 0387/1072] Move suggestion to update actions to note block --- ...tion-releases-using-github-actions-ci-cd-workflows.rst | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index df9173b5f..f5ba918db 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -140,8 +140,7 @@ trusted publishing to PyPI. :end-before: steps: This will also ensure that the PyPI publishing workflow is only triggered -if the current commit is tagged. It is recommended that you commit using the -latest release tag. +if the current commit is tagged. Publishing the distribution to PyPI =================================== @@ -215,6 +214,11 @@ And it'll publish any push to TestPyPI which is useful for providing test builds to your alpha users as well as making sure that your release pipeline remains healthy! +.. note:: + + It is recommended to keep the integrated GitHub Actions at their latest + versions, updating them frequently. + .. _API token: https://pypi.org/help/#apitoken .. _GitHub Actions CI/CD: https://github.com/features/actions From 53632e4b6915d82cc37ccc4b9049b3c869ab7e99 Mon Sep 17 00:00:00 2001 From: Bastian Venthur Date: Fri, 15 Sep 2023 12:42:18 +0200 Subject: [PATCH 0388/1072] empty commit to trigger ci-pipeline From eba15849b684ce3b361f61cad137fa22e9efbd16 Mon Sep 17 00:00:00 2001 From: Bastian Venthur Date: Fri, 15 Sep 2023 12:49:48 +0200 Subject: [PATCH 0389/1072] another empty commit From 9b4342f1ef70cb3f7821ed74678af2d43e271314 Mon Sep 17 00:00:00 2001 From: Bastian Venthur Date: Wed, 31 Aug 2022 12:23:51 +0200 Subject: [PATCH 0390/1072] Added obsolete fields: requires, provides and obsoletes closes: #1107 --- source/specifications/core-metadata.rst | 86 +++++++++++++++++++++++++ 1 file changed, 86 insertions(+) diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst index 453f9d30c..9b5e2cb51 100644 --- a/source/specifications/core-metadata.rst +++ b/source/specifications/core-metadata.rst @@ -761,6 +761,92 @@ Examples:: Obsoletes-Dist: OtherProject (<3.0) Obsoletes-Dist: Foo; os_name == "posix" + +Deprecated Fields +================= + +Requires +-------- + +.. versionadded:: 1.1 +.. deprecated:: 1.2 + in favour of ``Requires-Dist`` + +Each entry contains a string describing some other module or package required +by this package. + +The format of a requirement string is identical to that of a module or package +name usable with the ‘import’ statement, optionally followed by a version +declaration within parentheses. + +A version declaration is a series of conditional operators and version numbers, +separated by commas. Conditional operators must be one of "<", ">"', "<=", +">=", "==", and "!=". Version numbers must be in the format accepted by the +``distutils.version.StrictVersion`` class: two or three dot-separated numeric +components, with an optional "pre-release" tag on the end consisting of the +letter 'a' or 'b' followed by a number. Example version numbers are "1.0", +"2.3a2", "1.3.99", + +Any number of conditional operators can be specified, e.g. the string ">1.0, +!=1.3.4, <2.0" is a legal version declaration. + +All of the following are possible requirement strings: "rfc822", "zlib +(>=1.1.4)", "zope". + +There’s no canonical list of what strings should be used; the Python community +is left to choose its own standards. + +Examples:: + + Requires: re + Requires: sys + Requires: zlib + Requires: xml.parsers.expat (>1.0) + Requires: psycopg + + +Provides +-------- + +.. versionadded:: 1.1 +.. deprecated:: 1.2 + in favour of ``Provides-Dist`` + +Each entry contains a string describing a package or module that will be +provided by this package once it is installed. These strings should match the +ones used in Requirements fields. A version declaration may be supplied +(without a comparison operator); the package’s version number will be implied +if none is specified. + +Examples:: + + Provides: xml + Provides: xml.utils + Provides: xml.utils.iso8601 + Provides: xml.dom + Provides: xmltools (1.3) + + +Obsoletes +--------- + +.. versionadded:: 1.1 +.. deprecated:: 1.2 + in favour of ``Obsoletes-Dist`` + +Each entry contains a string describing a package or module that this package +renders obsolete, meaning that the two packages should not be installed at the +same time. Version declarations can be supplied. + +The most common use of this field will be in case a package name changes, e.g. +Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued +Python, the Gorgon package should be removed. + +Example:: + + Obsoletes: Gorgon + + ---- .. [1] reStructuredText markup: From 057ce0a9ee5907df05900a073af0c94f80fbcc90 Mon Sep 17 00:00:00 2001 From: Brian Rutledge Date: Mon, 5 Dec 2022 09:35:39 -0500 Subject: [PATCH 0391/1072] Update source/specifications/core-metadata.rst --- source/specifications/core-metadata.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst index 9b5e2cb51..0c4f4b490 100644 --- a/source/specifications/core-metadata.rst +++ b/source/specifications/core-metadata.rst @@ -776,7 +776,7 @@ Each entry contains a string describing some other module or package required by this package. The format of a requirement string is identical to that of a module or package -name usable with the ‘import’ statement, optionally followed by a version +name usable with the ``import`` statement, optionally followed by a version declaration within parentheses. A version declaration is a series of conditional operators and version numbers, From 61663e324ed741de2d1b225f269396729bfa5988 Mon Sep 17 00:00:00 2001 From: Bastian Venthur Date: Fri, 15 Sep 2023 12:56:54 +0200 Subject: [PATCH 0392/1072] fixed broken link this is unrelated to the pr but satisfies the CI pipeline... --- source/key_projects.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/source/key_projects.rst b/source/key_projects.rst index 7648f3b65..bbdf4edfc 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -558,6 +558,7 @@ resolution by locally caching metadata about dependencies. pypiserver ========== +`Docs `__ | `GitHub `__ | `PyPI `__ From 4f465dc077417572437af1de991add2f14226711 Mon Sep 17 00:00:00 2001 From: Bastian Venthur Date: Fri, 15 Sep 2023 12:42:18 +0200 Subject: [PATCH 0393/1072] empty commit to trigger ci-pipeline From b6e4c768cd8a810190cf5c158ff00a4174d0c165 Mon Sep 17 00:00:00 2001 From: Bastian Venthur Date: Fri, 15 Sep 2023 12:49:48 +0200 Subject: [PATCH 0394/1072] another empty commit From c439a75609907287c3f7210f37220e3d28ad2497 Mon Sep 17 00:00:00 2001 From: Dimitri Papadopoulos <3234522+DimitriPapadopoulos@users.noreply.github.com> Date: Sun, 17 Sep 2023 15:44:02 +0200 Subject: [PATCH 0395/1072] Fix a typo found by codespell --- ...stribution-releases-using-github-actions-ci-cd-workflows.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index f5ba918db..f572e4096 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -130,7 +130,7 @@ It's a process that will execute commands that we'll define later. In this guide, we'll use the latest stable Ubuntu LTS version provided by GitHub Actions. This also defines a GitHub Environment for the job to run in its context and a URL to be displayed in GitHub's -UI nicely. Additionally, it allows aqcuiring an OpenID Connect token +UI nicely. Additionally, it allows acquiring an OpenID Connect token that the ``pypi-publish`` actions needs to implement secretless trusted publishing to PyPI. From b42e89ffcc3d5b842d6f640194bca02babb4201e Mon Sep 17 00:00:00 2001 From: Bastian Venthur Date: Mon, 18 Sep 2023 09:02:11 +0200 Subject: [PATCH 0396/1072] Revert "fixed broken link" This reverts commit 61663e324ed741de2d1b225f269396729bfa5988. --- source/key_projects.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/source/key_projects.rst b/source/key_projects.rst index bbdf4edfc..7648f3b65 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -558,7 +558,6 @@ resolution by locally caching metadata about dependencies. pypiserver ========== -`Docs `__ | `GitHub `__ | `PyPI `__ From a19593997203e5af96b2eaad71781fed4de6cc5c Mon Sep 17 00:00:00 2001 From: Eric Ti Yu Chiang Date: Wed, 14 Jun 2023 09:18:51 +0800 Subject: [PATCH 0397/1072] Add history to package name normalization spec. --- source/specifications/name-normalization.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/source/specifications/name-normalization.rst b/source/specifications/name-normalization.rst index 4fd885afc..7a1a0e083 100644 --- a/source/specifications/name-normalization.rst +++ b/source/specifications/name-normalization.rst @@ -37,3 +37,9 @@ This means that the following names are all equivalent: * ``friendly_bard`` * ``friendly--bard`` * ``FrIeNdLy-._.-bArD`` (a _terrible_ way to write a name, but it is valid) + +History +======= + +- `September 2015 `_: normalized name was originally specified in :pep:`503#normalized-names`. +- `November 2015 `_: valid non-normalized name was originally specified in :pep:`508#names`. \ No newline at end of file From d14e4e6ff08e303e2369344f370eb05994e1c617 Mon Sep 17 00:00:00 2001 From: chrysle Date: Fri, 29 Sep 2023 17:49:32 +0200 Subject: [PATCH 0398/1072] Add step to create empty GH Release before upload --- .../github-actions-ci-cd-sample/publish-to-test-pypi.yml | 5 +++++ ...ion-releases-using-github-actions-ci-cd-workflows.rst | 9 +++++++-- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index 20ed37740..71aca9881 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -73,6 +73,11 @@ jobs: inputs: >- ./dist/*.tar.gz ./dist/*.whl + - name: Create GitHub Release + run: >- + gh release create + '${{ github.ref_name }}' + --notes "" - name: Upload artifact signatures to GitHub Release env: GITHUB_TOKEN: ${{ github.token }} diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst index f572e4096..33cc88017 100644 --- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst +++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @@ -163,8 +163,13 @@ Signing the distribution packages The following job signs the distribution packages with `Sigstore`_, the same artifact signing system `used to sign CPython `_. -It uses the `sigstore/gh-action-sigstore-python GitHub Action`_, -and then uploads them to a GitHub Release. +Firstly, it uses the `sigstore/gh-action-sigstore-python GitHub Action`_ +to sign the distribution packages. In the next step, an empty GitHub Release +from the current tag is created using the ``gh`` CLI. Note this step can be further +customised. See the `gh release documentation `_ +as a reference. + +Finally, the signed distributions are uploaded to the GitHub Release. .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml :language: yaml From 1f856d86512ff5a30a4dd967d982bac2da0ea531 Mon Sep 17 00:00:00 2001 From: Eric Ti Yu Chiang Date: Tue, 3 Oct 2023 17:14:40 -0400 Subject: [PATCH 0399/1072] Add history section to externally managed environments spec. --- source/specifications/externally-managed-environments.rst | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/source/specifications/externally-managed-environments.rst b/source/specifications/externally-managed-environments.rst index 3876d8e34..e4ee921d2 100644 --- a/source/specifications/externally-managed-environments.rst +++ b/source/specifications/externally-managed-environments.rst @@ -20,3 +20,7 @@ installation to indicate to Python-specific tools such as ``pip`` that they neither install nor remove packages into the interpreter’s default installation environment, and should instead guide the end user towards using :ref:`virtual-environments`. + +History +======= +- `June 2022 `_: ``EXTERNALLY-MANAGED`` marker file was originally specified in :pep:`668#marking-an-interpreter-as-using-an-external-package-manager`. \ No newline at end of file From 28dd1afdf79a7f16ee4354533994c695430c49ca Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Juan=20Luis=20Cano=20Rodr=C3=ADguez?= Date: Thu, 5 Oct 2023 12:13:48 +0200 Subject: [PATCH 0400/1072] Remove `setup.py` direct invocation in glossary https://pypa-build.readthedocs.io/en/latest/#python--m-build---sdist --- source/glossary.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/glossary.rst b/source/glossary.rst index f8392dbd0..707bc4756 100644 --- a/source/glossary.rst +++ b/source/glossary.rst @@ -208,7 +208,7 @@ Glossary Source Distribution (or "sdist") A :term:`distribution ` format (usually generated - using ``python setup.py sdist``) that provides metadata and the + using ``python -m build --sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`. From 42268c4ac44447237698727eb9584d3c18968c4b Mon Sep 17 00:00:00 2001 From: ValentinMerlet Date: Sat, 7 Oct 2023 12:24:18 +0200 Subject: [PATCH 0401/1072] Fix typo --- source/tutorials/installing-packages.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst index 23645459a..5d4957519 100644 --- a/source/tutorials/installing-packages.rst +++ b/source/tutorials/installing-packages.rst @@ -9,7 +9,7 @@ This section covers the basics of how to install Python :term:`packages It's important to note that the term "package" in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a -:term:`distribution `). It does not to refer to the kind +:term:`distribution `). It does not refer to the kind of :term:`package ` that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a :term:`distribution ` using the term "package". Using From 174b29bc691149f80894de377472ea9688db430f Mon Sep 17 00:00:00 2001 From: wim glenn Date: Wed, 6 Sep 2023 19:29:45 -0500 Subject: [PATCH 0402/1072] Change wording of Requires-Python and offer a lower bound example. This should better demonstrate that usage of this field is more commonly about _excluding known incompatible versions_ than it is about specifying _guaranteed compatible versions_. Remove the multiple example code-block because it is not a (multiple use) field, and the other examples seem to exist only to show further usage of PEP 440 version specifiers (which are explained better elsewhere) rather than Requires-Python itself. --- source/specifications/core-metadata.rst | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst index 0c4f4b490..5749e618e 100644 --- a/source/specifications/core-metadata.rst +++ b/source/specifications/core-metadata.rst @@ -551,18 +551,17 @@ Requires-Python .. versionadded:: 1.2 This field specifies the Python version(s) that the distribution is -guaranteed to be compatible with. Installation tools may look at this when +compatible with. Installation tools may look at this when picking which version of a project to install. The value must be in the format specified in :doc:`version-specifiers`. -This field cannot be followed by an environment marker. +For example, if a distribution uses `f-strings `_ +then it may prevent installation on Python < 3.6 by specifying: -Examples:: + Requires-Python: >=3.6 - Requires-Python: >=3 - Requires-Python: >2.6,!=3.0.*,!=3.1.* - Requires-Python: ~=2.6 +This field cannot be followed by an environment marker. .. _core-metadata-requires-external: From e604f4360bea19bd5f6025ecee44450d23113b1a Mon Sep 17 00:00:00 2001 From: wim glenn Date: Sat, 7 Oct 2023 13:58:02 -0500 Subject: [PATCH 0403/1072] review suggestions --- source/specifications/core-metadata.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst index 5749e618e..cccd611e0 100644 --- a/source/specifications/core-metadata.rst +++ b/source/specifications/core-metadata.rst @@ -556,8 +556,8 @@ picking which version of a project to install. The value must be in the format specified in :doc:`version-specifiers`. -For example, if a distribution uses `f-strings `_ -then it may prevent installation on Python < 3.6 by specifying: +For example, if a distribution uses :ref:`f-strings ` +then it may prevent installation on Python < 3.6 by specifying:: Requires-Python: >=3.6 From 513c97819c3cbaf7da3eb38b4e07c6dd0bb69a68 Mon Sep 17 00:00:00 2001 From: chrysle Date: Tue, 10 Oct 2023 17:12:32 +0200 Subject: [PATCH 0404/1072] Address `distutils` removal from Python stdlib --- source/guides/distributing-packages-using-setuptools.rst | 4 ++-- source/guides/dropping-older-python-versions.rst | 2 +- source/guides/tool-recommendations.rst | 2 +- source/key_projects.rst | 7 +++---- source/overview.rst | 2 +- source/specifications/platform-compatibility-tags.rst | 4 +++- 6 files changed, 11 insertions(+), 10 deletions(-) diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index a704dd048..eb99b3ff0 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -484,7 +484,7 @@ Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution. For more information see the distutils section on :ref:`Installing Additional Files -`. +`. .. note:: @@ -498,7 +498,7 @@ For more information see the distutils section on :ref:`Installing Additional Fi ~~~~~~~~~~~ Although ``setup()`` supports a :ref:`scripts -` +` keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below). diff --git a/source/guides/dropping-older-python-versions.rst b/source/guides/dropping-older-python-versions.rst index d4fc83c81..aec65b48d 100644 --- a/source/guides/dropping-older-python-versions.rst +++ b/source/guides/dropping-older-python-versions.rst @@ -102,7 +102,7 @@ metadata values based on the argument you provide in ``python_requires``. Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO. -This file is generated by Distutils or :ref:`setuptools` when it generates the source package. +This file is generated by :ref:`distutils` or :ref:`setuptools` when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format. You can see the contents of the generated file like this: diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst index fc0afd1df..1a59201fa 100644 --- a/source/guides/tool-recommendations.rst +++ b/source/guides/tool-recommendations.rst @@ -93,7 +93,7 @@ migration, and what settings to change in your clients. :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency. -.. [5] Although you can use pure ``distutils`` for many projects, it does not +.. [5] Although you can use pure :ref:`distutils` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the diff --git a/source/key_projects.rst b/source/key_projects.rst index 7648f3b65..8d1d42b40 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -676,21 +676,20 @@ build of the Python distribution. distutils ========= -`Docs `__ | -`Issues `__ - The original Python packaging system, added to the standard library in Python 2.0. Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, -direct usage of :ref:`distutils` is now actively discouraged, with +direct usage of :ref:`distutils` has been actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions. +Consequently, :ref:`distutils` was deprecated in Python 3.10 by :pep:`632` and +has been :doc:`removed ` from the standard library in Python 3.12. .. _venv: diff --git a/source/overview.rst b/source/overview.rst index f0f7cdbce..256510bb8 100644 --- a/source/overview.rst +++ b/source/overview.rst @@ -95,7 +95,7 @@ you can use Python's native packaging tools to create a *source* Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can -:doc:`go here to learn more `. +go to the :ref:`source-distribution-format` specification to learn more. If you rely on any non-Python code, or non-Python packages (such as `libxml2 `_ in the case of diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst index 5ef47f9af..df7da59c5 100644 --- a/source/specifications/platform-compatibility-tags.rst +++ b/source/specifications/platform-compatibility-tags.rst @@ -92,8 +92,10 @@ decide how to best use the ABI tag. Platform Tag ------------ -The platform tag is simply ``distutils.util.get_platform()`` with all +The platform tag is simply ``sysconfig.get_platform()`` with all hyphens ``-`` and periods ``.`` replaced with underscore ``_``. +Until the removal of :ref:`distutils` in Python 3.12, this +was ``distutils.util.get_platform()``. * win32 * linux_i386 From 23c38bed6edfe23c9b6a38b8626460a822356875 Mon Sep 17 00:00:00 2001 From: Peter Hill Date: Wed, 18 Oct 2023 15:33:18 +0100 Subject: [PATCH 0405/1072] Bump version of python-docs-theme --- requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements.txt b/requirements.txt index 17492e03c..7ee85ca01 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,7 +1,7 @@ sphinx==4.5.0 sphinx-autobuild==0.7.1 sphinx-inline-tabs==2021.4.11b9 -python-docs-theme==2022.1 +python-docs-theme==2023.9 sphinx-copybutton==0.5.0 pypa-docs-theme @ git+https://github.com/pypa/pypa-docs-theme.git sphinx-toolbox==3.5.0 From fd73358924a4a5d9a14239958cefa533f10307c5 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Tue, 24 Oct 2023 01:52:14 +0200 Subject: [PATCH 0406/1072] Unduplicate GHA runs for merge queues and pushes --- .github/workflows/test.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index 5da04a342..581b644ca 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -3,6 +3,8 @@ name: Test on: merge_group: push: + branches-ignore: + - gh-readonly-queue/** # Temporary merge queue-related GH-made branches pull_request: schedule: - cron: "0 6 * * *" # daily at 6am From 9301fb75b9bb32862a1d3ad376263089cadb331f Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Tue, 24 Oct 2023 01:56:49 +0200 Subject: [PATCH 0407/1072] Temporarily ignore www.breezy-vcs.org @ linkcheck Ref: * https://github.com/pypa/packaging.python.org/pull/1308#issuecomment-1775347690 --- source/conf.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/source/conf.py b/source/conf.py index 9113b8c68..16a231133 100644 --- a/source/conf.py +++ b/source/conf.py @@ -393,6 +393,9 @@ # Ignoring it as it will redirect to login page if reader hasn't logged in. "https://pypi.org/manage/*", "https://test.pypi.org/manage/*", + # Temporarily ignored. Ref: + # https://github.com/pypa/packaging.python.org/pull/1308#issuecomment-1775347690 + "https://www.breezy-vcs.org/*", ] # Example configuration for intersphinx: refer to the Python standard library. From 750e4b0bf0e4d42e64fbf3c3edba716b05fd6132 Mon Sep 17 00:00:00 2001 From: Henrik Finsberg Date: Wed, 25 Oct 2023 10:10:32 +0200 Subject: [PATCH 0408/1072] Update packaging-projects.rst Set lower bound on `requires-python` to 3.8 since 3.7 is EOL. --- source/tutorials/packaging-projects.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index 89e1d073d..78baf6b06 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -188,7 +188,7 @@ following this tutorial. ] description = "A small example package" readme = "README.md" - requires-python = ">=3.7" + requires-python = ">=3.8" classifiers = [ "Programming Language :: Python :: 3", "License :: OSI Approved :: MIT License", From be1c9798428fd711aafaccd820146a89aed54118 Mon Sep 17 00:00:00 2001 From: Matthias Bussonnier Date: Wed, 25 Oct 2023 12:00:32 +0200 Subject: [PATCH 0409/1072] say that flit is lifted and by whom --- source/key_projects.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/source/key_projects.rst b/source/key_projects.rst index 8d1d42b40..8267883aa 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -103,6 +103,11 @@ such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3. +The flit packaged is lifted by `Matthias Bussonnier +`__ since October 2023 on the `tidelift paltform +` Date: Wed, 25 Oct 2023 05:51:42 -0700 Subject: [PATCH 0410/1072] Apply suggestions from code review Co-authored-by: Paul Moore --- source/key_projects.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/key_projects.rst b/source/key_projects.rst index 8267883aa..1e9b58e51 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -103,8 +103,8 @@ such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3. -The flit packaged is lifted by `Matthias Bussonnier -`__ since October 2023 on the `tidelift paltform +The flit package is lifted by `Matthias Bussonnier +`__ since October 2023 on the `tidelift platform ` Date: Thu, 26 Oct 2023 11:25:35 -0700 Subject: [PATCH 0411/1072] Fix issue with creation of GitHub release caused by missing cli switch Reference: #1307 The command added, `gh release create`, fails without the `--repo` siwtch. This change adds it. Here is an Action run that fails without it https://github.com/uclahs-cds/BL_Python/actions/runs/6658063247/job/18094142825 And a successful Action run that succeeds with it. https://github.com/uclahs-cds/BL_Python/actions/runs/6658181985/job/18094515444 --- .../guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index 71aca9881..a77aac1c1 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -77,6 +77,7 @@ jobs: run: >- gh release create '${{ github.ref_name }}' + --repo '${{ github.repository }}' --notes "" - name: Upload artifact signatures to GitHub Release env: From ba7a8d9a38a694b8d1f13141739366ada3bce80f Mon Sep 17 00:00:00 2001 From: Aaron Holmes Date: Thu, 26 Oct 2023 12:23:28 -0700 Subject: [PATCH 0412/1072] Fix authorization issue when creating a GitHub release. The envvar `GITHUB_TOKEN` that is defined for the step that runs `gh release up` must also be defined for the step that runs `gh release create`. This change removes the definition from the step, and adds it to the job so that the envvar is available to all steps in the job. This fixes the authorization issue that can be seen [here](https://github.com/uclahs-cds/BL_Python/actions/runs/6658013371/job/18093994984). Note: the output of the Action specifies `GH_TOKEN`, but in fact either `GH_TOKEN` or `GITHUB_TOKEN` can be defined per [gh environment](https://cli.github.com/manual/gh_help_environment). --- .../github-actions-ci-cd-sample/publish-to-test-pypi.yml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml index a77aac1c1..02d1f8e84 100644 --- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml +++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml @@ -61,6 +61,9 @@ jobs: contents: write # IMPORTANT: mandatory for making GitHub Releases id-token: write # IMPORTANT: mandatory for sigstore + env: + GITHUB_TOKEN: ${{ github.token }} + steps: - name: Download all the dists uses: actions/download-artifact@v3 @@ -80,8 +83,6 @@ jobs: --repo '${{ github.repository }}' --notes "" - name: Upload artifact signatures to GitHub Release - env: - GITHUB_TOKEN: ${{ github.token }} # Upload to GitHub Release using the `gh` CLI. # `dist/` contains the built packages, and the # sigstore-produced signatures and certificates. From c6b8bbde182dd68a81ba3e0af558d6c8b1ebc47f Mon Sep 17 00:00:00 2001 From: Steve Dower Date: Wed, 1 Nov 2023 20:28:02 +0000 Subject: [PATCH 0413/1072] Update Choosing a build backend section --- source/tutorials/packaging-projects.rst | 43 +++++++++++++++++-------- 1 file changed, 29 insertions(+), 14 deletions(-) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index 89e1d073d..fe0f4c414 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -103,15 +103,17 @@ Creating a test directory :file:`tests/` is a placeholder for test files. Leave it empty for now. -Creating pyproject.toml +Choosing a build backend ----------------------- -.. TODO: Add an intro sentence about pyproject.toml, and a sub-heading for - "Configuring build tools" +Tools like :ref:`pip` and :ref:`build` do not actually convert your sources +into a :term:`distribution package `; +that job is performed by a _build backend_. The build backend determines how +your project will specify its configuration, including metadata (information +about the project, for example, the name and tags that are displayed on PyPI) +and input files. Build backends have different levels of functionality, and +you should choose one that suits your needs, but also meets your preferences. -:file:`pyproject.toml` tells "frontend" build tools like :ref:`pip` and -:ref:`build` what "backend" tool to use to create -:term:`distribution packages ` for your project. You can choose from a number of backends; this tutorial uses :ref:`Hatchling ` by default, but it will work identically with :ref:`setuptools`, :ref:`Flit `, :ref:`PDM `, and others that support the ``[project]`` @@ -124,7 +126,10 @@ table for :ref:`metadata `. management, as well as building, uploading, and installing packages. This tutorial uses single-purpose tools that work independently. -Open :file:`pyproject.toml` and enter one of these ``[build-system]`` tables: +The :file:`pyproject.toml` tells "front end" build tools like :ref:`pip` and +:ref:`build` which backend to use for your project. Below are some +examples for common build backends, but check your backend's own documentation +for more details. .. tab:: Hatchling @@ -159,14 +164,24 @@ Open :file:`pyproject.toml` and enter one of these ``[build-system]`` tables: build-backend = "pdm.backend" -- ``requires`` is a list of packages that are needed to build your package. You - don't need to install them; build frontends like :ref:`pip` will install them - automatically in a temporary, isolated virtual environment for use during the - build process. -- ``build-backend`` is the name of the Python object that frontends will use to - perform the build. +The ``requires`` key is a list of packages that are needed to build your package. +The front end should install them automatically when building your package. +There will always be your build backend package, and potentially other build-time +dependencies. -.. TODO: Add note to check the tools' documentation for the current snippet? +The ``build-backend`` key is the name of the Python object that frontends will use +to perform the build. + +Both of these values will be given to you by the documentation for your build +backend, or generated by its command line interface. There should be no need for +you to customize these settings. + +Additional configuration of the build tool will either be in a ``tool`` section +of the ``pyproject.toml``, or in a special file defined by the build tool. For +example, when using ``setuptools`` as your build backend, additional configuration +may be added to a ``setup.py`` or ``setup.cfg`` file, and specifying +``setuptools.build_meta`` in your build allows the tools to locate and use these +automatically. .. _configuring metadata: From 0049ff80e608cb5137a2dc49c73e8e97520bbb60 Mon Sep 17 00:00:00 2001 From: Steve Dower Date: Wed, 1 Nov 2023 20:34:48 +0000 Subject: [PATCH 0414/1072] Apply suggestions from code review --- source/tutorials/packaging-projects.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index fe0f4c414..943136705 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -166,13 +166,13 @@ for more details. The ``requires`` key is a list of packages that are needed to build your package. The front end should install them automatically when building your package. -There will always be your build backend package, and potentially other build-time +This should always include your backend's package, and might have other build-time dependencies. The ``build-backend`` key is the name of the Python object that frontends will use to perform the build. -Both of these values will be given to you by the documentation for your build +Both of these values will be provided by the documentation for your build backend, or generated by its command line interface. There should be no need for you to customize these settings. From c8fafd8d3f56851e7fd3cf498493985bbbd38f13 Mon Sep 17 00:00:00 2001 From: Steve Dower Date: Wed, 1 Nov 2023 21:36:06 +0000 Subject: [PATCH 0415/1072] Apply suggestions from code review --- source/tutorials/packaging-projects.rst | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index 943136705..0fc2e65d6 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -107,12 +107,13 @@ Choosing a build backend ----------------------- Tools like :ref:`pip` and :ref:`build` do not actually convert your sources -into a :term:`distribution package `; +into a :term:`distribution package ` (like a wheel); that job is performed by a _build backend_. The build backend determines how your project will specify its configuration, including metadata (information about the project, for example, the name and tags that are displayed on PyPI) -and input files. Build backends have different levels of functionality, and -you should choose one that suits your needs, but also meets your preferences. +and input files. Build backends have different levels of functionality, such as +whether they support building :term:`extension modules `, and +you should choose one that suits your needs and preferences. You can choose from a number of backends; this tutorial uses :ref:`Hatchling ` by default, but it will work identically with :ref:`setuptools`, @@ -165,7 +166,9 @@ for more details. The ``requires`` key is a list of packages that are needed to build your package. -The front end should install them automatically when building your package. +The frontend should install them automatically when building your package. +Frontends usually run builds in isolated environments, so omitting dependencies +here may cause build-time errors. This should always include your backend's package, and might have other build-time dependencies. From dae7a5561cc03ab89a801a7f62551b35c9c15aee Mon Sep 17 00:00:00 2001 From: Henry Schreiner Date: Thu, 2 Nov 2023 10:23:47 -0400 Subject: [PATCH 0416/1072] chore: add and update some backends Signed-off-by: Henry Schreiner --- source/key_projects.rst | 75 +++++++++++++++++++++++++++++------------ 1 file changed, 54 insertions(+), 21 deletions(-) diff --git a/source/key_projects.rst b/source/key_projects.rst index 8d1d42b40..73c3aefa5 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -84,6 +84,30 @@ behaviours when asked to handle legacy packages and metadata that predate the modern interoperability standards and fall into the subset of packages that are incompatible with those standards. + +.. _distutils: + +distutils +========= + +The original Python packaging system, added to the standard library in +Python 2.0 and removed in 3.12. + +Due to the challenges of maintaining a packaging system +where feature updates are tightly coupled to language runtime updates, +direct usage of :ref:`distutils` has been actively discouraged, with +:ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` +not only provides features that plain :ref:`distutils` doesn't offer +(such as dependency declarations and entry point declarations), it +also provides a consistent build interface and feature set across all +supported Python versions. + +Consequently, :ref:`distutils` was deprecated in Python 3.10 by :pep:`632` and +has been :doc:`removed ` from the standard library in +Python 3.12. Setuptools bundles the standalone copy of distutils, and it is +injected even on Python < 3.12 if you import setuptools first or use pip. + + .. _flit: flit @@ -452,6 +476,19 @@ problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016. +.. _maturin: + +Maturin +======= + +`Docs `__ | +`GitHub `__ + +Maturin is a PEP 517 build backend for Rust extension modules, also written in +Rust. It supports building wheels for python 3.7+ on Windows, Linux, macOS and +FreeBSD, can upload them to PyPI and has basic PyPy and GraalPy support. + + .. _meson-python: meson-python @@ -472,7 +509,7 @@ of most complex build configurations. multibuild ========== -`GitHub `__ +`GitHub `__ Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`. @@ -604,6 +641,22 @@ build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI). +.. _scikit-build-core: + +scikit-build-core +================= + +`Docs `__ | +`GitHub `__ | +`PyPI `__ + +Scikit-build-core is a PEP 517 backend for CPython C/C++/Fortran/Cython +extensions. It enables users to write extensions with `cmake +`__ (available on PyPI) to provide better +support for additional compilers, build systems, cross compilation, and +locating dependencies and their associated build requirements. CMake/Ninja +are automatically downloaded from PyPI if not available on the system. + .. _shiv: shiv @@ -671,26 +724,6 @@ cases, end users won't use this module, but rather it will be used during the build of the Python distribution. -.. _distutils: - -distutils -========= - -The original Python packaging system, added to the standard library in -Python 2.0. - -Due to the challenges of maintaining a packaging system -where feature updates are tightly coupled to language runtime updates, -direct usage of :ref:`distutils` has been actively discouraged, with -:ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` -not only provides features that plain :ref:`distutils` doesn't offer -(such as dependency declarations and entry point declarations), it -also provides a consistent build interface and feature set across all -supported Python versions. - -Consequently, :ref:`distutils` was deprecated in Python 3.10 by :pep:`632` and -has been :doc:`removed ` from the standard library in Python 3.12. - .. _venv: venv From a1a3c7f49104ea0c2b8ca168bd6f059e8a9e666d Mon Sep 17 00:00:00 2001 From: Henry Schreiner Date: Thu, 2 Nov 2023 10:50:59 -0400 Subject: [PATCH 0417/1072] chore: add some more pre-commit checks Signed-off-by: Henry Schreiner --- .pre-commit-config.yaml | 28 +++++++++++++++++++ source/contribute.rst | 4 +-- .../deploying-python-applications.rst | 2 +- ...distributing-packages-using-setuptools.rst | 2 +- .../guides/dropping-older-python-versions.rst | 4 +-- .../supporting-multiple-python-versions.rst | 2 +- .../supporting-windows-using-appveyor.rst | 6 ++-- source/key_projects.rst | 4 +-- source/specifications/core-metadata.rst | 2 +- .../declaring-build-dependencies.rst | 2 +- .../specifications/dependency-specifiers.rst | 1 - .../externally-managed-environments.rst | 2 +- source/specifications/name-normalization.rst | 2 +- source/tutorials/creating-documentation.rst | 4 --- source/tutorials/packaging-projects.rst | 3 +- 15 files changed, 45 insertions(+), 23 deletions(-) diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index a1a5f58c8..4c70a3f63 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -2,4 +2,32 @@ repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v4.4.0 hooks: + - id: check-added-large-files + - id: check-case-conflict + - id: check-merge-conflict + - id: check-symlinks + - id: check-yaml + - id: end-of-file-fixer + - id: mixed-line-ending - id: trailing-whitespace + +- repo: https://github.com/codespell-project/codespell + rev: v2.2.6 + hooks: + - id: codespell + args: ["-L", "ned"] + +- repo: local + hooks: + - id: disallow-caps + name: Disallow improper capitalization + language: pygrep + entry: PyBind|Numpy|Cmake|CCache|Github|PyTest + exclude: .pre-commit-config.yaml + +- repo: https://github.com/pre-commit/pygrep-hooks + rev: v1.10.0 + hooks: + - id: rst-backticks + - id: rst-directive-colons + - id: rst-inline-touching-normal diff --git a/source/contribute.rst b/source/contribute.rst index 0dbdc1adc..afac9e4f7 100644 --- a/source/contribute.rst +++ b/source/contribute.rst @@ -75,7 +75,7 @@ We use `Weblate`_ to manage translations of this project. Please visit the `packaging.python.org`_ project on Weblate to contribute. If you are experiencing issues while you are working on translations, -please open an issue on `Github`_. +please open an issue on `GitHub`_. .. tip:: @@ -83,7 +83,7 @@ please open an issue on `Github`_. .. _Weblate: https://weblate.org/ .. _packaging.python.org: https://hosted.weblate.org/projects/pypa/packaging-python-org/ -.. _Github: https://github.com/pypa/packaging.python.org/issues +.. _GitHub: https://github.com/pypa/packaging.python.org/issues .. _reStructuredText syntax: https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html Adding a language diff --git a/source/discussions/deploying-python-applications.rst b/source/discussions/deploying-python-applications.rst index 62e29448f..d9246d563 100644 --- a/source/discussions/deploying-python-applications.rst +++ b/source/discussions/deploying-python-applications.rst @@ -73,7 +73,7 @@ directory, independent of any other Python installation on the computer. A big advantage of Pynsist is that the Windows packages can be built on Linux. There are several examples for different kinds of programs (console, GUI) in -the `documentation `. The tool is released +the :any:`documentation `. The tool is released under the MIT-licence. Application bundles diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index eb99b3ff0..db982071d 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -241,7 +241,7 @@ can be specified with the ``long_description_content_type`` argument, which can be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding to no formatting, `reStructuredText (reST) `_, -and the Github-flavored Markdown dialect of `Markdown +and the GitHub-flavored Markdown dialect of `Markdown `_ respectively. ``url`` diff --git a/source/guides/dropping-older-python-versions.rst b/source/guides/dropping-older-python-versions.rst index aec65b48d..2ac193b4c 100644 --- a/source/guides/dropping-older-python-versions.rst +++ b/source/guides/dropping-older-python-versions.rst @@ -41,7 +41,7 @@ explicitly set ``universal`` to ``0``: # setup.cfg [bdist_wheel] - universal = 0 # Make the generated wheels have `py3` tag + universal = 0 # Make the generated wheels have "py3" tag .. tip:: @@ -71,7 +71,7 @@ Steps: py -m pip install --upgrade setuptools twine -`setuptools` version should be above 24.0.0. +``setuptools`` version should be above 24.0.0. 2. Specify the version ranges for supported Python distributions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/source/guides/supporting-multiple-python-versions.rst b/source/guides/supporting-multiple-python-versions.rst index 23c1f51c0..0471a1f2f 100644 --- a/source/guides/supporting-multiple-python-versions.rst +++ b/source/guides/supporting-multiple-python-versions.rst @@ -52,7 +52,7 @@ 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 `_) +`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 diff --git a/source/guides/supporting-windows-using-appveyor.rst b/source/guides/supporting-windows-using-appveyor.rst index 79242510c..1f43c443b 100644 --- a/source/guides/supporting-windows-using-appveyor.rst +++ b/source/guides/supporting-windows-using-appveyor.rst @@ -25,7 +25,7 @@ non-trivial, and may require buying software licenses. The Appveyor service is a continuous integration service, much like the better-known `Travis`_ service that is commonly used for testing by projects -hosted on `Github`_. However, unlike Travis, the build workers on Appveyor are +hosted on `GitHub`_. However, unlike Travis, the build workers on Appveyor are Windows hosts and have the necessary compilers installed to build Python extensions. @@ -44,7 +44,7 @@ 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 +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. @@ -241,5 +241,5 @@ For reference, the SDK setup support script is listed here: .. _Appveyor: https://www.appveyor.com/ .. _Travis: https://travis-ci.org/ -.. _Github: https://github.com +.. _GitHub: https://github.com .. _Bitbucket: https://bitbucket.org/ diff --git a/source/key_projects.rst b/source/key_projects.rst index 8d1d42b40..03c736e6b 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -34,7 +34,7 @@ Content Delivery Network (CDN). build ===== -`Docs ` | +:any:`Docs ` | `Issues `__ | `GitHub `__ | `PyPI `__ @@ -180,7 +180,7 @@ Pipenv Pipenv is a project that aims to bring the best of all packaging worlds to the Python world. It harnesses :ref:`Pipfile`, :ref:`pip`, and :ref:`virtualenv` into one single toolchain. It can autoimport ``requirements.txt`` and also -check for CVEs in `Pipfile` using `safety `_. +check for CVEs in `Pipfile`_ using `safety `_. Pipenv aims to help users manage environments, dependencies, and imported packages on the command line. It also works well on Windows diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst index 0c4f4b490..cefd68950 100644 --- a/source/specifications/core-metadata.rst +++ b/source/specifications/core-metadata.rst @@ -285,7 +285,7 @@ Other parameters might be specific to the chosen subtype. For example, for the specifying the variant of Markdown in use (defaults to ``GFM`` if not specified). Currently, two variants are recognized: -- ``GFM`` for :rfc:`Github-flavored Markdown <7764#section-3.2>` +- ``GFM`` for :rfc:`GitHub-flavored Markdown <7764#section-3.2>` - ``CommonMark`` for :rfc:`CommonMark <7764#section-3.5>` Example:: diff --git a/source/specifications/declaring-build-dependencies.rst b/source/specifications/declaring-build-dependencies.rst index 74f9c3ca2..9e5b72308 100644 --- a/source/specifications/declaring-build-dependencies.rst +++ b/source/specifications/declaring-build-dependencies.rst @@ -5,6 +5,6 @@ Declaring build system dependencies =================================== -`pyproject.toml` is a build system independent file format defined in :pep:`518` +``pyproject.toml`` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully. diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst index 43b362109..009b8a592 100644 --- a/source/specifications/dependency-specifiers.rst +++ b/source/specifications/dependency-specifiers.rst @@ -488,4 +488,3 @@ References .. [#future_versions] Future Python versions might be problematic with the definition of Environment Marker Variable ``python_version`` (https://github.com/python/peps/issues/560) - diff --git a/source/specifications/externally-managed-environments.rst b/source/specifications/externally-managed-environments.rst index e4ee921d2..979b72aec 100644 --- a/source/specifications/externally-managed-environments.rst +++ b/source/specifications/externally-managed-environments.rst @@ -23,4 +23,4 @@ environment, and should instead guide the end user towards using History ======= -- `June 2022 `_: ``EXTERNALLY-MANAGED`` marker file was originally specified in :pep:`668#marking-an-interpreter-as-using-an-external-package-manager`. \ No newline at end of file +- `June 2022 `_: ``EXTERNALLY-MANAGED`` marker file was originally specified in :pep:`668#marking-an-interpreter-as-using-an-external-package-manager`. diff --git a/source/specifications/name-normalization.rst b/source/specifications/name-normalization.rst index 7a1a0e083..4756d1631 100644 --- a/source/specifications/name-normalization.rst +++ b/source/specifications/name-normalization.rst @@ -42,4 +42,4 @@ History ======= - `September 2015 `_: normalized name was originally specified in :pep:`503#normalized-names`. -- `November 2015 `_: valid non-normalized name was originally specified in :pep:`508#names`. \ No newline at end of file +- `November 2015 `_: valid non-normalized name was originally specified in :pep:`508#names`. diff --git a/source/tutorials/creating-documentation.rst b/source/tutorials/creating-documentation.rst index ec960ada0..483fb0d72 100644 --- a/source/tutorials/creating-documentation.rst +++ b/source/tutorials/creating-documentation.rst @@ -64,7 +64,3 @@ Other Sources For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python. .. _documentation tutorial: https://docs.python-guide.org/writing/documentation/ - - - - diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index 89e1d073d..e92870030 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -245,7 +245,7 @@ if you'd like. # Example Package This is a simple example package. You can use - [Github-flavored Markdown](https://guides.github.com/features/mastering-markdown/) + [GitHub-flavored Markdown](https://guides.github.com/features/mastering-markdown/) to write your content. @@ -517,4 +517,3 @@ some things you can do: :ref:`pdm`, and :ref:`poetry`. * Read :pep:`517` and :pep:`518` for background and details on build tool configuration. * Read about :doc:`/guides/packaging-binary-extensions`. - From aa364050b2312651ece11ee32eb13722bc47a1de Mon Sep 17 00:00:00 2001 From: Henry Schreiner Date: Thu, 2 Nov 2023 11:38:39 -0400 Subject: [PATCH 0418/1072] refactor: address feedback Signed-off-by: Henry Schreiner --- source/key_projects.rst | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/source/key_projects.rst b/source/key_projects.rst index 73c3aefa5..6bee5b7f1 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -484,7 +484,7 @@ Maturin `Docs `__ | `GitHub `__ -Maturin is a PEP 517 build backend for Rust extension modules, also written in +Maturin is a build backend for Rust extension modules, also written in Rust. It supports building wheels for python 3.7+ on Windows, Linux, macOS and FreeBSD, can upload them to PyPI and has basic PyPy and GraalPy support. @@ -632,14 +632,13 @@ scikit-build `GitHub `__ | `PyPI `__ -Scikit-build is an improved build system generator for CPython -C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` -and :ref:`pip`. It internally uses `cmake `__ (available -on PyPI) to provide better support for additional compilers, build systems, -cross compilation, and locating dependencies and their associated -build requirements. To speed up and parallelize the build of large projects, -the user can install `ninja `__ (also available -on PyPI). +Scikit-build is a :ref:`setuptools` wrapper for CPython that builds +C/C++/Fortran/Cython extensions It uses +`cmake `__ (available on PyPI) to provide +better support for additional compilers, build systems, cross compilation, and +locating dependencies and their associated build requirements. To speed up and +parallelize the build of large projects, the user can install `ninja +`__ (also available on PyPI). .. _scikit-build-core: @@ -650,7 +649,7 @@ scikit-build-core `GitHub `__ | `PyPI `__ -Scikit-build-core is a PEP 517 backend for CPython C/C++/Fortran/Cython +Scikit-build-core is a build backend for CPython C/C++/Fortran/Cython extensions. It enables users to write extensions with `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and From 5c774716bd0c8671d376e47a6d7c3e8222226fec Mon Sep 17 00:00:00 2001 From: Steve Dower Date: Thu, 2 Nov 2023 16:25:54 +0000 Subject: [PATCH 0419/1072] Apply suggestions from code review Co-authored-by: Henry Schreiner --- source/tutorials/packaging-projects.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst index 0fc2e65d6..77211f876 100644 --- a/source/tutorials/packaging-projects.rst +++ b/source/tutorials/packaging-projects.rst @@ -104,11 +104,11 @@ Creating a test directory Choosing a build backend ------------------------ +------------------------ Tools like :ref:`pip` and :ref:`build` do not actually convert your sources into a :term:`distribution package ` (like a wheel); -that job is performed by a _build backend_. The build backend determines how +that job is performed by a *build backend*. The build backend determines how your project will specify its configuration, including metadata (information about the project, for example, the name and tags that are displayed on PyPI) and input files. Build backends have different levels of functionality, such as From b4da615f09c846e3cbf976ca4aba3f259c87d816 Mon Sep 17 00:00:00 2001 From: Carol Willing Date: Thu, 2 Nov 2023 13:40:31 -0700 Subject: [PATCH 0420/1072] Update sphinx-autobuild version --- requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements.txt b/requirements.txt index 7ee85ca01..d6e0d750f 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,5 +1,5 @@ sphinx==4.5.0 -sphinx-autobuild==0.7.1 +sphinx-autobuild==2021.3.14 sphinx-inline-tabs==2021.4.11b9 python-docs-theme==2023.9 sphinx-copybutton==0.5.0 From b4c0c7a627e3c19e712b8d93dba2c97808f55181 Mon Sep 17 00:00:00 2001 From: Carol Willing Date: Thu, 2 Nov 2023 13:52:59 -0700 Subject: [PATCH 0421/1072] Update CLI arg for sphinx-autobuild host --- noxfile.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/noxfile.py b/noxfile.py index 884b6ad08..b5d994701 100644 --- a/noxfile.py +++ b/noxfile.py @@ -39,7 +39,7 @@ def build(session, autobuild=False): if autobuild: command = "sphinx-autobuild" - extra_args = "-H", "0.0.0.0" + extra_args = "--host", "0.0.0.0" else: # NOTE: This branch adds options that are unsupported by autobuild command = "sphinx-build" From c1abfc2a8351655b5cbc9a082c1b1ea698e139f6 Mon Sep 17 00:00:00 2001 From: Carol Willing Date: Thu, 2 Nov 2023 14:06:35 -0700 Subject: [PATCH 0422/1072] Sort index to diataxis areas --- source/index.rst | 42 ++++++++++++++++++++++++++++-------------- 1 file changed, 28 insertions(+), 14 deletions(-) diff --git a/source/index.rst b/source/index.rst index 4cd8c8425..2c36d3570 100644 --- a/source/index.rst +++ b/source/index.rst @@ -32,34 +32,48 @@ happily accept any :doc:`contributions and feedback `. 😊 .. _GitHub: https://github.com/pypa/packaging.python.org -Get started -=========== +Overview +======== + +* To get an overview of packaging options for Python libraries and + applications, see the :doc:`Overview of Python Packaging ` + +Tutorials +========= Essential tools and concepts for working within the Python -development ecosystem are covered in our :doc:`tutorials/index` section: +development ecosystem are covered in our :doc:`tutorials/index` section. -* To get an overview of the flow used to publish your code, see the - :doc:`packaging flow ` * To learn how to install packages, see the :doc:`tutorial on installing packages ` * To learn how to manage dependencies in a version controlled project, see the :doc:`tutorial on managing application dependencies ` * To learn how to package and distribute your projects, see the :doc:`tutorial on packaging and distributing ` -* To get an overview of packaging options for Python libraries and - applications, see the :doc:`Overview of Python Packaging ` - -Learn more -========== - -Beyond our :doc:`tutorials/index`, this guide has several other resources: +Guides +====== * The :doc:`guides/index` section for walk throughs, such as :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`. + +Explanations and Discussions +============================ + +* To get an overview of the flow used to publish your code, see the + :doc:`packaging flow ` * The :doc:`discussions/index` section for in-depth references on topics such as :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`. -* The :doc:`specifications/index` section for packaging interoperability specifications. -Additionally, there is a list of :doc:`other projects ` maintained +Reference +========= + +* The :doc:`specifications/index` section for packaging interoperability specifications. +* Additionally, there is a list of :doc:`other projects ` maintained by members of the Python Packaging Authority. + +Get started +=========== + + + From 356dabd9f6bb9d31c77530b85ae6ae0036382b87 Mon Sep 17 00:00:00 2001 From: Carol Willing Date: Thu, 2 Nov 2023 18:04:53 -0700 Subject: [PATCH 0423/1072] Add prose for readability --- source/index.rst | 68 +++++++++++++++++++++++++++++------------------- 1 file changed, 41 insertions(+), 27 deletions(-) diff --git a/source/index.rst b/source/index.rst index 2c36d3570..c00ed0ad8 100644 --- a/source/index.rst +++ b/source/index.rst @@ -27,53 +27,67 @@ references to help you distribute and install Python packages with modern tools. This guide is maintained on `GitHub`_ by the :doc:`Python Packaging Authority `. We -happily accept any :doc:`contributions and feedback `. 😊 +happily accept :doc:`contributions and feedback `. 😊 .. _GitHub: https://github.com/pypa/packaging.python.org -Overview -======== +Overview and Flow +================= -* To get an overview of packaging options for Python libraries and - applications, see the :doc:`Overview of Python Packaging ` +.. note:: + + Building your understanding of Python packaging is a journey. Patience and + continuous improvement are key to success. The overview and flow sections + provide a starting point for understanding the Python packaging ecosystem. + +The :doc:`Overview of Python Packaging ` explains Python packaging +and its use when preparing and distributing projects. +This section helps you build understanding about selecting the tools and +processes that are most suitable for your use case. +It includes what packaging is, the problems that it solves, and +key considerations. + +To get an overview of the workflow used to publish your code, see +:doc:`packaging flow `. Tutorials ========= -Essential tools and concepts for working within the Python -development ecosystem are covered in our :doc:`tutorials/index` section. +Tutorials walk through the steps needed to complete a project for the first time. +Tutorials aim to help you succeed and provide a starting point for future +exploration. +The :doc:`tutorials/index` section includes: -* To learn how to install packages, see the - :doc:`tutorial on installing packages ` -* To learn how to manage dependencies in a version controlled project, see the - :doc:`tutorial on managing application dependencies ` -* To learn how to package and distribute your projects, see the - :doc:`tutorial on packaging and distributing ` +* A :doc:`tutorial on installing packages ` +* A :doc:`tutorial on managing application dependencies ` + in a version controlled project +* A :doc:`tutorial on packaging and distributing ` + your project Guides ====== -* The :doc:`guides/index` section for walk throughs, such as - :doc:`guides/installing-using-linux-tools` or :doc:`guides/packaging-binary-extensions`. +Guides provide steps to perform a specific task. Guides are more focused on +users who are already familiar with Python packaging and are looking for +specific information. + +The :doc:`guides/index` section provides "how to" instructions in three major +areas: package installation; building and distributing packages; miscellaneous +topics. Explanations and Discussions ============================ -* To get an overview of the flow used to publish your code, see the - :doc:`packaging flow ` -* The :doc:`discussions/index` section for in-depth references on topics such as - :doc:`discussions/deploying-python-applications` or :doc:`discussions/pip-vs-easy-install`. +The :doc:`discussions/index` section for in-depth explanations and discussion +about topics, such as: + +* :doc:`discussions/deploying-python-applications` +* :doc:`discussions/pip-vs-easy-install` Reference ========= * The :doc:`specifications/index` section for packaging interoperability specifications. -* Additionally, there is a list of :doc:`other projects ` maintained -by members of the Python Packaging Authority. - -Get started -=========== - - - +* The list of :doc:`other projects ` maintained by members of the Python Packaging Authority. +* The :doc:`glossary` for definitions of terms used in Python packaging. From 98cfc01a2db3fa80a87026b629c984511608278a Mon Sep 17 00:00:00 2001 From: Jean Abou Samra Date: Fri, 3 Nov 2023 18:03:32 +0100 Subject: [PATCH 0424/1072] Import PEP 518 text unchanged --- .../declaring-build-dependencies.rst | 561 ++++++++++++++++++ 1 file changed, 561 insertions(+) diff --git a/source/specifications/declaring-build-dependencies.rst b/source/specifications/declaring-build-dependencies.rst index 9e5b72308..fd882373c 100644 --- a/source/specifications/declaring-build-dependencies.rst +++ b/source/specifications/declaring-build-dependencies.rst @@ -8,3 +8,564 @@ Declaring build system dependencies ``pyproject.toml`` is a build system independent file format defined in :pep:`518` that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully. + + +PEP: 518 +Title: Specifying Minimum Build System Requirements for Python Projects +Author: Brett Cannon , + Nathaniel J. Smith , + Donald Stufft +BDFL-Delegate: Alyssa Coghlan +Discussions-To: distutils-sig@python.org +Status: Final +Type: Standards Track +Topic: Packaging +Content-Type: text/x-rst +Created: 10-May-2016 +Post-History: 10-May-2016, + 11-May-2016, + 13-May-2016 +Resolution: https://mail.python.org/pipermail/distutils-sig/2016-May/028969.html + + +Abstract +======== + +This PEP specifies how Python software packages should specify what +build dependencies they have in order to execute their chosen build +system. As part of this specification, a new configuration file is +introduced for software packages to use to specify their build +dependencies (with the expectation that the same configuration file +will be used for future configuration details). + + +Rationale +========= + +When Python first developed its tooling for building distributions of +software for projects, distutils [#distutils]_ was the chosen +solution. As time went on, setuptools [#setuptools]_ gained popularity +to add some features on top of distutils. Both used the concept of a +``setup.py`` file that project maintainers executed to build +distributions of their software (as well as users to install said +distribution). + +Using an executable file to specify build requirements under distutils +isn't an issue as distutils is part of Python's standard library. +Having the build tool as part of Python means that a ``setup.py`` has +no external dependency that a project maintainer needs to worry about +to build a distribution of their project. There was no need to specify +any dependency information as the only dependency is Python. + +But when a project chooses to use setuptools, the use of an executable +file like ``setup.py`` becomes an issue. You can't execute a +``setup.py`` file without knowing its dependencies, but currently +there is no standard way to know what those dependencies are in an +automated fashion without executing the ``setup.py`` file where that +information is stored. It's a catch-22 of a file not being runnable +without knowing its own contents which can't be known programmatically +unless you run the file. + +Setuptools tried to solve this with a ``setup_requires`` argument to +its ``setup()`` function [#setup_args]_. This solution has a number +of issues, such as: + +* No tooling (besides setuptools itself) can access this information + without executing the ``setup.py``, but ``setup.py`` can't be + executed without having these items installed. +* While setuptools itself will install anything listed in this, they + won't be installed until *during* the execution of the ``setup()`` + function, which means that the only way to actually use anything + added here is through increasingly complex machinations that delay + the import and usage of these modules until later on in the + execution of the ``setup()`` function. +* This cannot include ``setuptools`` itself nor can it include a + replacement to ``setuptools``, which means that projects such as + ``numpy.distutils`` are largely incapable of utilizing it and + projects cannot take advantage of newer setuptools features until + their users naturally upgrade the version of setuptools to a newer + one. +* The items listed in ``setup_requires`` get implicitly installed + whenever you execute the ``setup.py`` but one of the common ways + that the ``setup.py`` is executed is via another tool, such as + ``pip``, who is already managing dependencies. This means that + a command like ``pip install spam`` might end up having both + pip and setuptools downloading and installing packages and end + users needing to configure *both* tools (and for ``setuptools`` + without being in control of the invocation) to change settings + like which repository it installs from. It also means that users + need to be aware of the discovery rules for both tools, as one + may support different package formats or determine the latest + version differently. + +This has culminated in a situation where use of ``setup_requires`` +is rare, where projects tend to either simply copy and paste snippets +between ``setup.py`` files or they eschew it all together in favor +of simply documenting elsewhere what they expect the user to have +manually installed prior to attempting to build or install their +project. + +All of this has led pip [#pip]_ to simply assume that setuptools is +necessary when executing a ``setup.py`` file. The problem with this, +though, is it doesn't scale if another project began to gain traction +in the community as setuptools has. It also prevents other projects +from gaining traction due to the friction required to use it with a +project when pip can't infer the fact that something other than +setuptools is required. + +This PEP attempts to rectify the situation by specifying a way to list +the minimal dependencies of the build system of a project in a +declarative fashion in a specific file. This allows a project to list +what build dependencies it has to go from e.g. source checkout to +wheel, while not falling into the catch-22 trap that a ``setup.py`` +has where tooling can't infer what a project needs to build itself. +Implementing this PEP will allow projects to specify what build system +they depend on upfront so that tools like pip can make sure that they +are installed in order to run the build system to build the project. + +To provide more context and motivation for this PEP, think of the +(rough) steps required to produce a built artifact for a project: + +1. The source checkout of the project. +2. Installation of the build system. +3. Execute the build system. + +This PEP covers step #2. :pep:`517` covers step #3, including how to have +the build system dynamically specify more dependencies that the build +system requires to perform its job. The purpose of this PEP though, is +to specify the minimal set of requirements for the build system to +simply begin execution. + + +Specification +============= + +File Format +----------- + +The build system dependencies will be stored in a file named +``pyproject.toml`` that is written in the TOML format [#toml]_. + +This format was chosen as it is human-usable (unlike JSON [#json]_), +it is flexible enough (unlike configparser [#configparser]_), stems +from a standard (also unlike configparser [#configparser]_), and it +is not overly complex (unlike YAML [#yaml]_). The TOML format is +already in use by the Rust community as part of their +Cargo package manager [#cargo]_ and in private email stated they have +been quite happy with their choice of TOML. A more thorough +discussion as to why various alternatives were not chosen can be read +in the `Other file formats`_ section. The authors do realize, though, +that choice of configuration file format is ultimately subjective and +a choice had to be made and the authors prefer TOML for this situation. + +Below we list the tables that tools are expected to recognize/respect. +Tables not specified in this PEP are reserved for future use by other +PEPs. + +build-system table +------------------ + +The ``[build-system]`` table is used to store build-related data. +Initially only one key of the table will be valid and is mandatory +for the table: ``requires``. This key must have a value of a list +of strings representing :pep:`508` dependencies required to execute the +build system (currently that means what dependencies are required to +execute a ``setup.py`` file). + +For the vast majority of Python projects that rely upon setuptools, +the ``pyproject.toml`` file will be:: + + [build-system] + # Minimum requirements for the build system to execute. + requires = ["setuptools", "wheel"] # PEP 508 specifications. + +Because the use of setuptools and wheel are so expansive in the +community at the moment, build tools are expected to use the example +configuration file above as their default semantics when a +``pyproject.toml`` file is not present. + +Tools should not require the existence of the ``[build-system]`` table. +A ``pyproject.toml`` file may be used to store configuration details +other than build-related data and thus lack a ``[build-system]`` table +legitimately. If the file exists but is lacking the ``[build-system]`` +table then the default values as specified above should be used. +If the table is specified but is missing required fields then the tool +should consider it an error. + + +tool table +---------- + +The ``[tool]`` table is where any tool related to your Python +project, not just build tools, can have users specify configuration +data as long as they use a sub-table within ``[tool]``, e.g. the +`flit `_ tool would store its +configuration in ``[tool.flit]``. + +We need some mechanism to allocate names within the ``tool.*`` +namespace, to make sure that different projects don't attempt to use +the same sub-table and collide. Our rule is that a project can use +the subtable ``tool.$NAME`` if, and only if, they own the entry for +``$NAME`` in the Cheeseshop/PyPI. + +JSON Schema +----------- + +To provide a type-specific representation of the resulting data from +the TOML file for illustrative purposes only, the following JSON +Schema [#jsonschema]_ would match the data format:: + + { + "$schema": "http://json-schema.org/schema#", + + "type": "object", + "additionalProperties": false, + + "properties": { + "build-system": { + "type": "object", + "additionalProperties": false, + + "properties": { + "requires": { + "type": "array", + "items": { + "type": "string" + } + } + }, + "required": ["requires"] + }, + + "tool": { + "type": "object" + } + } + } + + +Rejected Ideas +============== + +A semantic version key +---------------------- + +For future-proofing the structure of the configuration file, a +``semantics-version`` key was initially proposed. Defaulting to ``1``, +the idea was that if any semantics changes to previously defined keys +or tables occurred which were not backwards-compatible, then the +``semantics-version`` would be incremented to a new number. + +In the end, though, it was decided that this was a premature +optimization. The expectation is that changes to what is pre-defined +semantically in the configuration file will be rather conservative. +And in the instances where a backwards-incompatible change would have +occurred, different names can be used for the new semantics to avoid +breaking older tools. + + +A more nested namespace +----------------------- + +An earlier draft of this PEP had a top-level ``[package]`` table. The +idea was to impose some scoping for a semantics versioning scheme +(see `A semantic version key`_ for why that idea was rejected). +With the need for scoping removed, the point of having a top-level +table became superfluous. + + +Other table names +----------------- + +Another name proposed for the ``[build-system]`` table was +``[build]``. The alternative name is shorter, but doesn't convey as +much of the intention of what information is stored in the table. After +a vote on the distutils-sig mailing list, the current name won out. + + +Other file formats +------------------ + +Several other file formats were put forward for consideration, all +rejected for various reasons. Key requirements were that the format +be editable by human beings and have an implementation that can be +vendored easily by projects. This outright excluded certain formats +like XML which are not friendly towards human beings and were never +seriously discussed. + +Overview of file formats considered +''''''''''''''''''''''''''''''''''' + +The key reasons for rejecting the other alternatives considered are +summarised in the following sections, while the full review (including +positive arguments in favour of TOML) can be found at [#file_formats]_. + +TOML was ultimately selected as it provided all the features we +were interested in, while avoiding the downsides introduced by +the alternatives. + +======================= ==== ==== ==== ======= +Feature TOML YAML JSON CFG/INI +======================= ==== ==== ==== ======= +Well-defined yes yes yes +Real data types yes yes yes +Reliable Unicode yes yes yes +Reliable comments yes yes +Easy for humans to edit yes ?? ?? +Easy for tools to edit yes ?? yes ?? +In standard library yes yes +Easy for pip to vendor yes n/a n/a +======================= ==== ==== ==== ======= + +("??" in the table indicates items where most folks would be +inclined to answer "yes", but there turn out to be a lot of +quirks and edge cases that arise in practice due to either +the lack of a clear specification, or else the underlying +file format specification being surprisingly complicated) + +The ``pytoml`` TOML parser is ~300 lines of pure Python code, +so being outside the standard library didn't count heavily +against it. + +Python literals were also discussed as a potential format, but +weren't considered in the file format review (since they're not +a common pre-existing file format). + + +JSON +'''' + +The JSON format [#json]_ was initially considered but quickly +rejected. While great as a human-readable, string-based data exchange +format, the syntax does not lend itself to easy editing by a human +being (e.g. the syntax is more verbose than necessary while not +allowing for comments). + +An example JSON file for the proposed data would be:: + + { + "build": { + "requires": [ + "setuptools", + "wheel>=0.27" + ] + } + } + + +YAML +'''' + +The YAML format [#yaml]_ was designed to be a superset of JSON +[#json]_ while being easier to work with by hand. There are three main +issues with YAML. + +One is that the specification is large: 86 pages if printed on +letter-sized paper. That leaves the possibility that someone may use a +feature of YAML that works with one parser but not another. It has +been suggested to standardize on a subset, but that basically means +creating a new standard specific to this file which is not tractable +long-term. + +Two is that YAML itself is not safe by default. The specification +allows for the arbitrary execution of code which is best avoided when +dealing with configuration data. It is of course possible to avoid +this behavior -- for example, PyYAML provides a ``safe_load`` operation +-- but if any tool carelessly uses ``load`` instead then they open +themselves up to arbitrary code execution. While this PEP is focused on +the building of projects which inherently involves code execution, +other configuration data such as project name and version number may +end up in the same file someday where arbitrary code execution is not +desired. + +And finally, the most popular Python implementation of YAML is +PyYAML [#pyyaml]_ which is a large project of a few thousand lines of +code and an optional C extension module. While in and of itself this +isn't necessarily an issue, this becomes more of a problem for +projects like pip where they would most likely need to vendor PyYAML +as a dependency so as to be fully self-contained (otherwise you end +up with your install tool needing an install tool to work). A +proof-of-concept re-working of PyYAML has been done to see how easy +it would be to potentially vendor a simpler version of the library +which shows it is a possibility. + +An example YAML file is:: + + build: + requires: + - setuptools + - wheel>=0.27 + + +configparser +'''''''''''' + +An INI-style configuration file based on what +configparser [#configparser]_ accepts was considered. Unfortunately +there is no specification of what configparser accepts, leading to +support skew between versions. For instance, what ConfigParser in +Python 2.7 accepts is not the same as what configparser in Python 3 +accepts. While one could standardize on what Python 3 accepts and +simply vendor the backport of the configparser module, that does mean +this PEP would have to codify that the backport of configparser must +be used by all project wishes to consume the metadata specified by +this PEP. This is overly restrictive and could lead to confusion if +someone is not aware of that a specific version of configparser is +expected. + +An example INI file is:: + + [build] + requires = + setuptools + wheel>=0.27 + + +Python literals +''''''''''''''' + +Someone proposed using Python literals as the configuration format. +The file would contain one dict at the top level, with the data all +inside that dict, with sections defined by the keys. All Python +programmers would be used to the format, there would implicitly be no +third-party dependency to read the configuration data, and it can be +safe if parsed by ``ast.literal_eval()`` [#ast_literal_eval]_. +Python literals can be identical to JSON, with the added benefit of +supporting trailing commas and comments. In addition, Python's richer +data model may be useful for some future configuration needs (e.g. non-string +dict keys, floating point vs. integer values). + +On the other hand, python literals are a Python-specific format, and +it is anticipated that these data may need to be read by packaging +tools, etc. that are not written in Python. + +An example Python literal file for the proposed data would be:: + + # The build configuration + {"build": {"requires": ["setuptools", + "wheel>=0.27", # note the trailing comma + # "numpy>=1.10" # a commented out data line + ] + # and here is an arbitrary comment. + } + } + + +Sticking with ``setup.cfg`` +--------------------------- + +There are two issues with ``setup.cfg`` used by setuptools as a general +format. One is that they are ``.ini`` files which have issues as mentioned +in the configparser_ discussion above. The other is that the schema for +that file has never been rigorously defined and thus it's unknown which +format would be safe to use going forward without potentially confusing +setuptools installations. + + + +Other file names +---------------- + +Several other file names were considered and rejected (although this +is very much a bikeshedding topic, and so the decision comes down to +mostly taste). + +pysettings.toml + Most reasonable alternative. + +pypa.toml + While it makes sense to reference the PyPA [#pypa]_, it is a + somewhat niche term. It's better to have the file name make sense + without having domain-specific knowledge. + +pybuild.toml + From the restrictive perspective of this PEP this filename makes + sense, but if any non-build metadata ever gets added to the file + then the name ceases to make sense. + +pip.toml + Too tool-specific. + +meta.toml + Too generic; project may want to have its own metadata file. + +setup.toml + While keeping with traditional thanks to ``setup.py``, it does not + necessarily match what the file may contain in the future (e.g. is + knowing the name of a project inherently part of its setup?). + +pymeta.toml + Not obvious to newcomers to programming and/or Python. + +pypackage.toml & pypackaging.toml + Name conflation of what a "package" is (project versus namespace). + +pydevelop.toml + The file may contain details not specific to development. + +pysource.toml + Not directly related to source code. + +pytools.toml + Misleading as the file is (currently) aimed at project management. + +dstufft.toml + Too person-specific. ;) + + +References +========== + +.. [#distutils] distutils + (https://docs.python.org/3/library/distutils.html#module-distutils) + +.. [#setuptools] setuptools + (https://pypi.python.org/pypi/setuptools) + +.. [#setup_args] setuptools: New and Changed setup() Keywords + (http://pythonhosted.org/setuptools/setuptools.html#new-and-changed-setup-keywords) + +.. [#pip] pip + (https://pypi.python.org/pypi/pip) + +.. [#wheel] wheel + (https://pypi.python.org/pypi/wheel) + +.. [#toml] TOML + (https://github.com/toml-lang/toml) + +.. [#json] JSON + (http://json.org/) + +.. [#yaml] YAML + (http://yaml.org/) + +.. [#configparser] configparser + (https://docs.python.org/3/library/configparser.html#module-configparser) + +.. [#pyyaml] PyYAML + (https://pypi.python.org/pypi/PyYAML) + +.. [#pypa] PyPA + (https://www.pypa.io) + +.. [#bazel] Bazel + (http://bazel.io/) + +.. [#ast_literal_eval] ``ast.literal_eval()`` + (https://docs.python.org/3/library/ast.html#ast.literal_eval) + +.. [#cargo] Cargo, Rust's package manager + (http://doc.crates.io/) + +.. [#jsonschema] JSON Schema + (http://json-schema.org/) + +.. [#file_formats] Nathaniel J. Smith's file format review + (https://gist.github.com/njsmith/78f68204c5d969f8c8bc645ef77d4a8f) + + +Copyright +========= + +This document has been placed in the public domain. From 001a68f7cf9008b8cfe820abadacf1487cb8c6d7 Mon Sep 17 00:00:00 2001 From: Jean Abou Samra Date: Fri, 3 Nov 2023 18:06:44 +0100 Subject: [PATCH 0425/1072] PEP 518: Trim rationale and boilerplate parts --- .../declaring-build-dependencies.rst | 441 ------------------ 1 file changed, 441 deletions(-) diff --git a/source/specifications/declaring-build-dependencies.rst b/source/specifications/declaring-build-dependencies.rst index fd882373c..d66597d43 100644 --- a/source/specifications/declaring-build-dependencies.rst +++ b/source/specifications/declaring-build-dependencies.rst @@ -10,24 +10,6 @@ that projects may provide in order to declare any Python level dependencies that must be installed in order to run the project's build system successfully. -PEP: 518 -Title: Specifying Minimum Build System Requirements for Python Projects -Author: Brett Cannon , - Nathaniel J. Smith , - Donald Stufft -BDFL-Delegate: Alyssa Coghlan -Discussions-To: distutils-sig@python.org -Status: Final -Type: Standards Track -Topic: Packaging -Content-Type: text/x-rst -Created: 10-May-2016 -Post-History: 10-May-2016, - 11-May-2016, - 13-May-2016 -Resolution: https://mail.python.org/pipermail/distutils-sig/2016-May/028969.html - - Abstract ======== @@ -39,104 +21,6 @@ dependencies (with the expectation that the same configuration file will be used for future configuration details). -Rationale -========= - -When Python first developed its tooling for building distributions of -software for projects, distutils [#distutils]_ was the chosen -solution. As time went on, setuptools [#setuptools]_ gained popularity -to add some features on top of distutils. Both used the concept of a -``setup.py`` file that project maintainers executed to build -distributions of their software (as well as users to install said -distribution). - -Using an executable file to specify build requirements under distutils -isn't an issue as distutils is part of Python's standard library. -Having the build tool as part of Python means that a ``setup.py`` has -no external dependency that a project maintainer needs to worry about -to build a distribution of their project. There was no need to specify -any dependency information as the only dependency is Python. - -But when a project chooses to use setuptools, the use of an executable -file like ``setup.py`` becomes an issue. You can't execute a -``setup.py`` file without knowing its dependencies, but currently -there is no standard way to know what those dependencies are in an -automated fashion without executing the ``setup.py`` file where that -information is stored. It's a catch-22 of a file not being runnable -without knowing its own contents which can't be known programmatically -unless you run the file. - -Setuptools tried to solve this with a ``setup_requires`` argument to -its ``setup()`` function [#setup_args]_. This solution has a number -of issues, such as: - -* No tooling (besides setuptools itself) can access this information - without executing the ``setup.py``, but ``setup.py`` can't be - executed without having these items installed. -* While setuptools itself will install anything listed in this, they - won't be installed until *during* the execution of the ``setup()`` - function, which means that the only way to actually use anything - added here is through increasingly complex machinations that delay - the import and usage of these modules until later on in the - execution of the ``setup()`` function. -* This cannot include ``setuptools`` itself nor can it include a - replacement to ``setuptools``, which means that projects such as - ``numpy.distutils`` are largely incapable of utilizing it and - projects cannot take advantage of newer setuptools features until - their users naturally upgrade the version of setuptools to a newer - one. -* The items listed in ``setup_requires`` get implicitly installed - whenever you execute the ``setup.py`` but one of the common ways - that the ``setup.py`` is executed is via another tool, such as - ``pip``, who is already managing dependencies. This means that - a command like ``pip install spam`` might end up having both - pip and setuptools downloading and installing packages and end - users needing to configure *both* tools (and for ``setuptools`` - without being in control of the invocation) to change settings - like which repository it installs from. It also means that users - need to be aware of the discovery rules for both tools, as one - may support different package formats or determine the latest - version differently. - -This has culminated in a situation where use of ``setup_requires`` -is rare, where projects tend to either simply copy and paste snippets -between ``setup.py`` files or they eschew it all together in favor -of simply documenting elsewhere what they expect the user to have -manually installed prior to attempting to build or install their -project. - -All of this has led pip [#pip]_ to simply assume that setuptools is -necessary when executing a ``setup.py`` file. The problem with this, -though, is it doesn't scale if another project began to gain traction -in the community as setuptools has. It also prevents other projects -from gaining traction due to the friction required to use it with a -project when pip can't infer the fact that something other than -setuptools is required. - -This PEP attempts to rectify the situation by specifying a way to list -the minimal dependencies of the build system of a project in a -declarative fashion in a specific file. This allows a project to list -what build dependencies it has to go from e.g. source checkout to -wheel, while not falling into the catch-22 trap that a ``setup.py`` -has where tooling can't infer what a project needs to build itself. -Implementing this PEP will allow projects to specify what build system -they depend on upfront so that tools like pip can make sure that they -are installed in order to run the build system to build the project. - -To provide more context and motivation for this PEP, think of the -(rough) steps required to produce a built artifact for a project: - -1. The source checkout of the project. -2. Installation of the build system. -3. Execute the build system. - -This PEP covers step #2. :pep:`517` covers step #3, including how to have -the build system dynamically specify more dependencies that the build -system requires to perform its job. The purpose of this PEP though, is -to specify the minimal set of requirements for the build system to -simply begin execution. - - Specification ============= @@ -146,18 +30,6 @@ File Format The build system dependencies will be stored in a file named ``pyproject.toml`` that is written in the TOML format [#toml]_. -This format was chosen as it is human-usable (unlike JSON [#json]_), -it is flexible enough (unlike configparser [#configparser]_), stems -from a standard (also unlike configparser [#configparser]_), and it -is not overly complex (unlike YAML [#yaml]_). The TOML format is -already in use by the Rust community as part of their -Cargo package manager [#cargo]_ and in private email stated they have -been quite happy with their choice of TOML. A more thorough -discussion as to why various alternatives were not chosen can be read -in the `Other file formats`_ section. The authors do realize, though, -that choice of configuration file format is ultimately subjective and -a choice had to be made and the authors prefer TOML for this situation. - Below we list the tables that tools are expected to recognize/respect. Tables not specified in this PEP are reserved for future use by other PEPs. @@ -244,328 +116,15 @@ Schema [#jsonschema]_ would match the data format:: } -Rejected Ideas -============== - -A semantic version key ----------------------- - -For future-proofing the structure of the configuration file, a -``semantics-version`` key was initially proposed. Defaulting to ``1``, -the idea was that if any semantics changes to previously defined keys -or tables occurred which were not backwards-compatible, then the -``semantics-version`` would be incremented to a new number. - -In the end, though, it was decided that this was a premature -optimization. The expectation is that changes to what is pre-defined -semantically in the configuration file will be rather conservative. -And in the instances where a backwards-incompatible change would have -occurred, different names can be used for the new semantics to avoid -breaking older tools. - - -A more nested namespace ------------------------ - -An earlier draft of this PEP had a top-level ``[package]`` table. The -idea was to impose some scoping for a semantics versioning scheme -(see `A semantic version key`_ for why that idea was rejected). -With the need for scoping removed, the point of having a top-level -table became superfluous. - - -Other table names ------------------ - -Another name proposed for the ``[build-system]`` table was -``[build]``. The alternative name is shorter, but doesn't convey as -much of the intention of what information is stored in the table. After -a vote on the distutils-sig mailing list, the current name won out. - - -Other file formats ------------------- - -Several other file formats were put forward for consideration, all -rejected for various reasons. Key requirements were that the format -be editable by human beings and have an implementation that can be -vendored easily by projects. This outright excluded certain formats -like XML which are not friendly towards human beings and were never -seriously discussed. - -Overview of file formats considered -''''''''''''''''''''''''''''''''''' - -The key reasons for rejecting the other alternatives considered are -summarised in the following sections, while the full review (including -positive arguments in favour of TOML) can be found at [#file_formats]_. - -TOML was ultimately selected as it provided all the features we -were interested in, while avoiding the downsides introduced by -the alternatives. - -======================= ==== ==== ==== ======= -Feature TOML YAML JSON CFG/INI -======================= ==== ==== ==== ======= -Well-defined yes yes yes -Real data types yes yes yes -Reliable Unicode yes yes yes -Reliable comments yes yes -Easy for humans to edit yes ?? ?? -Easy for tools to edit yes ?? yes ?? -In standard library yes yes -Easy for pip to vendor yes n/a n/a -======================= ==== ==== ==== ======= - -("??" in the table indicates items where most folks would be -inclined to answer "yes", but there turn out to be a lot of -quirks and edge cases that arise in practice due to either -the lack of a clear specification, or else the underlying -file format specification being surprisingly complicated) - -The ``pytoml`` TOML parser is ~300 lines of pure Python code, -so being outside the standard library didn't count heavily -against it. - -Python literals were also discussed as a potential format, but -weren't considered in the file format review (since they're not -a common pre-existing file format). - - -JSON -'''' - -The JSON format [#json]_ was initially considered but quickly -rejected. While great as a human-readable, string-based data exchange -format, the syntax does not lend itself to easy editing by a human -being (e.g. the syntax is more verbose than necessary while not -allowing for comments). - -An example JSON file for the proposed data would be:: - - { - "build": { - "requires": [ - "setuptools", - "wheel>=0.27" - ] - } - } - - -YAML -'''' - -The YAML format [#yaml]_ was designed to be a superset of JSON -[#json]_ while being easier to work with by hand. There are three main -issues with YAML. - -One is that the specification is large: 86 pages if printed on -letter-sized paper. That leaves the possibility that someone may use a -feature of YAML that works with one parser but not another. It has -been suggested to standardize on a subset, but that basically means -creating a new standard specific to this file which is not tractable -long-term. - -Two is that YAML itself is not safe by default. The specification -allows for the arbitrary execution of code which is best avoided when -dealing with configuration data. It is of course possible to avoid -this behavior -- for example, PyYAML provides a ``safe_load`` operation --- but if any tool carelessly uses ``load`` instead then they open -themselves up to arbitrary code execution. While this PEP is focused on -the building of projects which inherently involves code execution, -other configuration data such as project name and version number may -end up in the same file someday where arbitrary code execution is not -desired. - -And finally, the most popular Python implementation of YAML is -PyYAML [#pyyaml]_ which is a large project of a few thousand lines of -code and an optional C extension module. While in and of itself this -isn't necessarily an issue, this becomes more of a problem for -projects like pip where they would most likely need to vendor PyYAML -as a dependency so as to be fully self-contained (otherwise you end -up with your install tool needing an install tool to work). A -proof-of-concept re-working of PyYAML has been done to see how easy -it would be to potentially vendor a simpler version of the library -which shows it is a possibility. - -An example YAML file is:: - - build: - requires: - - setuptools - - wheel>=0.27 - - -configparser -'''''''''''' - -An INI-style configuration file based on what -configparser [#configparser]_ accepts was considered. Unfortunately -there is no specification of what configparser accepts, leading to -support skew between versions. For instance, what ConfigParser in -Python 2.7 accepts is not the same as what configparser in Python 3 -accepts. While one could standardize on what Python 3 accepts and -simply vendor the backport of the configparser module, that does mean -this PEP would have to codify that the backport of configparser must -be used by all project wishes to consume the metadata specified by -this PEP. This is overly restrictive and could lead to confusion if -someone is not aware of that a specific version of configparser is -expected. - -An example INI file is:: - - [build] - requires = - setuptools - wheel>=0.27 - - -Python literals -''''''''''''''' - -Someone proposed using Python literals as the configuration format. -The file would contain one dict at the top level, with the data all -inside that dict, with sections defined by the keys. All Python -programmers would be used to the format, there would implicitly be no -third-party dependency to read the configuration data, and it can be -safe if parsed by ``ast.literal_eval()`` [#ast_literal_eval]_. -Python literals can be identical to JSON, with the added benefit of -supporting trailing commas and comments. In addition, Python's richer -data model may be useful for some future configuration needs (e.g. non-string -dict keys, floating point vs. integer values). - -On the other hand, python literals are a Python-specific format, and -it is anticipated that these data may need to be read by packaging -tools, etc. that are not written in Python. - -An example Python literal file for the proposed data would be:: - - # The build configuration - {"build": {"requires": ["setuptools", - "wheel>=0.27", # note the trailing comma - # "numpy>=1.10" # a commented out data line - ] - # and here is an arbitrary comment. - } - } - - -Sticking with ``setup.cfg`` ---------------------------- - -There are two issues with ``setup.cfg`` used by setuptools as a general -format. One is that they are ``.ini`` files which have issues as mentioned -in the configparser_ discussion above. The other is that the schema for -that file has never been rigorously defined and thus it's unknown which -format would be safe to use going forward without potentially confusing -setuptools installations. - - - -Other file names ----------------- - -Several other file names were considered and rejected (although this -is very much a bikeshedding topic, and so the decision comes down to -mostly taste). - -pysettings.toml - Most reasonable alternative. - -pypa.toml - While it makes sense to reference the PyPA [#pypa]_, it is a - somewhat niche term. It's better to have the file name make sense - without having domain-specific knowledge. - -pybuild.toml - From the restrictive perspective of this PEP this filename makes - sense, but if any non-build metadata ever gets added to the file - then the name ceases to make sense. - -pip.toml - Too tool-specific. - -meta.toml - Too generic; project may want to have its own metadata file. - -setup.toml - While keeping with traditional thanks to ``setup.py``, it does not - necessarily match what the file may contain in the future (e.g. is - knowing the name of a project inherently part of its setup?). - -pymeta.toml - Not obvious to newcomers to programming and/or Python. - -pypackage.toml & pypackaging.toml - Name conflation of what a "package" is (project versus namespace). - -pydevelop.toml - The file may contain details not specific to development. - -pysource.toml - Not directly related to source code. - -pytools.toml - Misleading as the file is (currently) aimed at project management. - -dstufft.toml - Too person-specific. ;) - References ========== -.. [#distutils] distutils - (https://docs.python.org/3/library/distutils.html#module-distutils) - -.. [#setuptools] setuptools - (https://pypi.python.org/pypi/setuptools) - -.. [#setup_args] setuptools: New and Changed setup() Keywords - (http://pythonhosted.org/setuptools/setuptools.html#new-and-changed-setup-keywords) - -.. [#pip] pip - (https://pypi.python.org/pypi/pip) - -.. [#wheel] wheel - (https://pypi.python.org/pypi/wheel) - .. [#toml] TOML (https://github.com/toml-lang/toml) -.. [#json] JSON - (http://json.org/) - .. [#yaml] YAML (http://yaml.org/) -.. [#configparser] configparser - (https://docs.python.org/3/library/configparser.html#module-configparser) - -.. [#pyyaml] PyYAML - (https://pypi.python.org/pypi/PyYAML) - -.. [#pypa] PyPA - (https://www.pypa.io) - -.. [#bazel] Bazel - (http://bazel.io/) - -.. [#ast_literal_eval] ``ast.literal_eval()`` - (https://docs.python.org/3/library/ast.html#ast.literal_eval) - -.. [#cargo] Cargo, Rust's package manager - (http://doc.crates.io/) - .. [#jsonschema] JSON Schema (http://json-schema.org/) - -.. [#file_formats] Nathaniel J. Smith's file format review - (https://gist.github.com/njsmith/78f68204c5d969f8c8bc645ef77d4a8f) - - -Copyright -========= - -This document has been placed in the public domain. From 2ac05b5d801ba198bbe9d586ee4ac44d7d8c251c Mon Sep 17 00:00:00 2001 From: Jean Abou Samra Date: Fri, 3 Nov 2023 18:21:38 +0100 Subject: [PATCH 0426/1072] PEP 518: Light editing to fit packaging.python.org --- .../declaring-build-dependencies.rst | 139 +++++++----------- 1 file changed, 55 insertions(+), 84 deletions(-) diff --git a/source/specifications/declaring-build-dependencies.rst b/source/specifications/declaring-build-dependencies.rst index d66597d43..faa8542c6 100644 --- a/source/specifications/declaring-build-dependencies.rst +++ b/source/specifications/declaring-build-dependencies.rst @@ -5,56 +5,37 @@ Declaring build system dependencies =================================== -``pyproject.toml`` is a build system independent file format defined in :pep:`518` -that projects may provide in order to declare any Python level dependencies that -must be installed in order to run the project's build system successfully. +The ``pyproject.toml`` file is written in `TOML `_. +Among other metadata (such as :ref:`project metadata `), +it declares any Python level dependencies that must be installed in order to +run the project's build system successfully. +.. TODO: move this sentence elsewhere -Abstract -======== +Tables not defined by PyPA specifications are reserved for future use. -This PEP specifies how Python software packages should specify what -build dependencies they have in order to execute their chosen build -system. As part of this specification, a new configuration file is -introduced for software packages to use to specify their build -dependencies (with the expectation that the same configuration file -will be used for future configuration details). - - -Specification -============= - -File Format ------------ - -The build system dependencies will be stored in a file named -``pyproject.toml`` that is written in the TOML format [#toml]_. - -Below we list the tables that tools are expected to recognize/respect. -Tables not specified in this PEP are reserved for future use by other -PEPs. build-system table ------------------ The ``[build-system]`` table is used to store build-related data. -Initially only one key of the table will be valid and is mandatory +Currently, only one key of the table is be valid and is mandatory for the table: ``requires``. This key must have a value of a list -of strings representing :pep:`508` dependencies required to execute the -build system (currently that means what dependencies are required to -execute a ``setup.py`` file). +of strings representing dependencies required to execute the +build system. The strings in this list follow the :ref:`version specifier +specification `. + +An example ``build-system`` table for a project built with +``setuptools`` is: -For the vast majority of Python projects that rely upon setuptools, -the ``pyproject.toml`` file will be:: +.. code-block:: toml - [build-system] - # Minimum requirements for the build system to execute. - requires = ["setuptools", "wheel"] # PEP 508 specifications. + [build-system] + # Minimum requirements for the build system to execute. + requires = ["setuptools", "wheel"] -Because the use of setuptools and wheel are so expansive in the -community at the moment, build tools are expected to use the example -configuration file above as their default semantics when a -``pyproject.toml`` file is not present. +Build tools are expected to use the example configuration file above as +their default semantics when a ``pyproject.toml`` file is not present. Tools should not require the existence of the ``[build-system]`` table. A ``pyproject.toml`` file may be used to store configuration details @@ -65,6 +46,8 @@ If the table is specified but is missing required fields then the tool should consider it an error. +.. TODO: move elsewhere + tool table ---------- @@ -74,8 +57,8 @@ data as long as they use a sub-table within ``[tool]``, e.g. the `flit `_ tool would store its configuration in ``[tool.flit]``. -We need some mechanism to allocate names within the ``tool.*`` -namespace, to make sure that different projects don't attempt to use +A mechanism is needed to allocate names within the ``tool.*`` +namespace, to make sure that different projects do not attempt to use the same sub-table and collide. Our rule is that a project can use the subtable ``tool.$NAME`` if, and only if, they own the entry for ``$NAME`` in the Cheeseshop/PyPI. @@ -84,47 +67,35 @@ JSON Schema ----------- To provide a type-specific representation of the resulting data from -the TOML file for illustrative purposes only, the following JSON -Schema [#jsonschema]_ would match the data format:: - - { - "$schema": "http://json-schema.org/schema#", - - "type": "object", - "additionalProperties": false, - - "properties": { - "build-system": { - "type": "object", - "additionalProperties": false, - - "properties": { - "requires": { - "type": "array", - "items": { - "type": "string" - } - } - }, - "required": ["requires"] - }, - - "tool": { - "type": "object" - } - } - } - - - -References -========== - -.. [#toml] TOML - (https://github.com/toml-lang/toml) - -.. [#yaml] YAML - (http://yaml.org/) - -.. [#jsonschema] JSON Schema - (http://json-schema.org/) +the TOML file for illustrative purposes only, the following +`JSON Schema `_ would match the data format: + +.. code-block:: json + + { + "$schema": "http://json-schema.org/schema#", + + "type": "object", + "additionalProperties": false, + + "properties": { + "build-system": { + "type": "object", + "additionalProperties": false, + + "properties": { + "requires": { + "type": "array", + "items": { + "type": "string" + } + } + }, + "required": ["requires"] + }, + + "tool": { + "type": "object" + } + } + } From df0126e2daf96aa3da9b0d9bce1768dbe20171fe Mon Sep 17 00:00:00 2001 From: Jean Abou Samra Date: Fri, 3 Nov 2023 23:17:26 +0100 Subject: [PATCH 0427/1072] PEP 518: Remove wheel from the example requirements since it's a dependency of setuptools --- source/specifications/declaring-build-dependencies.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/declaring-build-dependencies.rst b/source/specifications/declaring-build-dependencies.rst index faa8542c6..5b4b73053 100644 --- a/source/specifications/declaring-build-dependencies.rst +++ b/source/specifications/declaring-build-dependencies.rst @@ -32,7 +32,7 @@ An example ``build-system`` table for a project built with [build-system] # Minimum requirements for the build system to execute. - requires = ["setuptools", "wheel"] + requires = ["setuptools"] Build tools are expected to use the example configuration file above as their default semantics when a ``pyproject.toml`` file is not present. From 3155ba410ebb10b1edc6f0d5e5c974a77ab11a04 Mon Sep 17 00:00:00 2001 From: Jean Abou Samra Date: Fri, 3 Nov 2023 23:18:37 +0100 Subject: [PATCH 0428/1072] =?UTF-8?q?Currently=20=E2=86=92=20Initially,=20?= =?UTF-8?q?+=20comment?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- source/specifications/declaring-build-dependencies.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/source/specifications/declaring-build-dependencies.rst b/source/specifications/declaring-build-dependencies.rst index 5b4b73053..3ac94b0b3 100644 --- a/source/specifications/declaring-build-dependencies.rst +++ b/source/specifications/declaring-build-dependencies.rst @@ -18,8 +18,10 @@ Tables not defined by PyPA specifications are reserved for future use. build-system table ------------------ +.. TODO: merge with PEP 517 + The ``[build-system]`` table is used to store build-related data. -Currently, only one key of the table is be valid and is mandatory +Initially, only one key of the table is valid and is mandatory for the table: ``requires``. This key must have a value of a list of strings representing dependencies required to execute the build system. The strings in this list follow the :ref:`version specifier From c665d9ad43fb6e370285609317ce87cd23a7cf11 Mon Sep 17 00:00:00 2001 From: Jean Abou Samra Date: Fri, 3 Nov 2023 23:56:20 +0100 Subject: [PATCH 0429/1072] Revert "PEP 518: Remove wheel from the example requirements since it's a dependency of setuptools" This reverts commit df0126e2daf96aa3da9b0d9bce1768dbe20171fe. --- source/specifications/declaring-build-dependencies.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/declaring-build-dependencies.rst b/source/specifications/declaring-build-dependencies.rst index 3ac94b0b3..c9a1aac9e 100644 --- a/source/specifications/declaring-build-dependencies.rst +++ b/source/specifications/declaring-build-dependencies.rst @@ -34,7 +34,7 @@ An example ``build-system`` table for a project built with [build-system] # Minimum requirements for the build system to execute. - requires = ["setuptools"] + requires = ["setuptools", "wheel"] Build tools are expected to use the example configuration file above as their default semantics when a ``pyproject.toml`` file is not present. From f8d3a40a19457d3d2585a53829d1df19df549031 Mon Sep 17 00:00:00 2001 From: Carol Willing Date: Fri, 3 Nov 2023 20:57:46 -0700 Subject: [PATCH 0430/1072] Update how to guide for installing using pip and venv --- ...ing-using-pip-and-virtual-environments.rst | 188 +++++++++--------- 1 file changed, 93 insertions(+), 95 deletions(-) diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst index 287c059f5..ce65d971a 100644 --- a/source/guides/installing-using-pip-and-virtual-environments.rst +++ b/source/guides/installing-using-pip-and-virtual-environments.rst @@ -1,22 +1,32 @@ -Installing packages using pip and virtual environments -====================================================== +Installing packages using pip and venv +====================================== This guide discusses how to install packages using :ref:`pip` and -a virtual environment manager: either :ref:`venv` for Python 3 or :ref:`virtualenv` -for Python 2. These are the lowest-level tools for managing Python -packages and are recommended if higher-level tools do not suit your needs. +the standard library's virtual environment manager :ref:`venv`. The guide +covers how to: -.. note:: This doc uses the term **package** to refer to a - :term:`Distribution Package` which is different from an :term:`Import - Package` that which is used to import modules in your Python source code. +* Install and update pip +* Create and use a virtual environment +* Install packages into a virtual environment using the ``pip`` command +* Use and create a requirements file -Installing pip --------------- +.. note:: This guide applies to Python 3.3 and higher. If using a + legacy version of Python 2.x, consider using :ref:`virtualenv`. -:ref:`pip` is the reference Python package manager. It's used to install and -update packages. You'll need to make sure you have the latest version of pip -installed. + +.. note:: This guide uses the term **package** to refer to a + :term:`Distribution Package`, which commonly is installed from an external + host. This differs from the term :term:`Import Package` which refers to + import modules in your Python source code. + + +Install and update pip +---------------------- + +:ref:`pip` is the reference Python package manager. +It's used to install and update packages. +Make sure you have the latest version of pip installed. .. tab:: Unix/macOS @@ -59,94 +69,68 @@ installed. pip 21.1.3 from c:\python39\lib\site-packages (Python 3.9.4) +Create and Use Virtual Environments +----------------------------------- -Installing virtualenv ---------------------- - -.. Note:: If you are using Python 3.3 or newer, the :mod:`venv` module is - the preferred way to create and manage virtual environments. - venv is included in the Python standard library and requires no additional installation. - If you are using venv, you may skip this section. - - -:ref:`virtualenv` is used to manage Python packages for different projects. -Using virtualenv allows you to avoid installing Python packages globally -which could break system tools or other projects. You can install virtualenv -using pip. +Create a new virtual environment +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +:ref:`venv` (for Python 3) allows you to manage separate package installations for +different projects. It creates a "virtual" isolated Python installation. When +you switch projects, you can create a new virtual environment which is isolated +from other virtual environments. You benefit from the virtual environment +since packages can be installed confidently and will not interfere with the +other project environments. -.. tab:: Unix/macOS - - .. code-block:: bash - - python3 -m pip install --user virtualenv - -.. tab:: Windows - - .. code-block:: bat - - py -m pip install --user virtualenv - - - -Creating a virtual environment ------------------------------- - -:ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow -you to manage separate package installations for -different projects. They essentially allow you to create a "virtual" isolated -Python installation and install packages into that virtual installation. When -you switch projects, you can simply create a new virtual environment and not -have to worry about breaking the packages installed in the other environments. -It is always recommended to use a virtual environment while developing Python -applications. +.. tip:: + It is always recommended to use a virtual environment while developing Python + applications. To create a virtual environment, go to your project's directory and run -venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` -in the below commands. +``venv``. .. tab:: Unix/macOS .. code-block:: bash - python3 -m venv env + python3 -m venv .venv .. tab:: Windows .. code-block:: bat - py -m venv env + py -m venv .venv The second argument is the location to create the virtual environment. Generally, you -can just create this in your project and call it ``env``. +can just create this in your project and call it ``.venv``. -venv will create a virtual Python installation in the ``env`` folder. +``venv`` will create a virtual Python installation in the ``.venv`` folder. .. Note:: You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar. -Activating a virtual environment --------------------------------- +Activate a virtual environment +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Before you can start installing or using packages in your virtual environment you'll -need to *activate* it. Activating a virtual environment will put the -virtual environment-specific -``python`` and ``pip`` executables into your shell's ``PATH``. +need to ``activate`` it. Activating a virtual environment will put the +virtual environment-specific ``python`` and ``pip`` executables into your +shell's ``PATH``. .. tab:: Unix/macOS .. code-block:: bash - source env/bin/activate + source .venv/bin/activate .. tab:: Windows .. code-block:: bat - .\env\Scripts\activate + .\.venv\Scripts\activate -You can confirm you're in the virtual environment by checking the location of your +To confirm the virtual environment is activated, check the location of your Python interpreter: .. tab:: Unix/macOS @@ -161,43 +145,56 @@ Python interpreter: where python -It should be in the ``env`` directory: +When the virtual environment is activated, the location will include +the ``.venv`` directory: .. tab:: Unix/macOS .. code-block:: bash - .../env/bin/python + .../.venv/bin/python .. tab:: Windows .. code-block:: bat - ...\env\Scripts\python.exe + ...\.venv\Scripts\python.exe -As long as your virtual environment is activated pip will install packages into that -specific environment and you'll be able to import and use packages in your +While a virtual environment is activated, pip will install packages into that +specific environment. This enables you to import and use packages in your Python application. -Leaving the virtual environment -------------------------------- +Deactivate a virtual environment +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -If you want to switch projects or otherwise leave your virtual environment, simply run: +If you want to switch projects or leave your virtual environment, +``deactivate`` the environment: .. code-block:: bash deactivate -If you want to re-enter the virtual environment just follow the same instructions above -about activating a virtual environment. There's no need to re-create the virtual environment. + +Reactivate a virtual environment +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you want to reactivate an existing virtual environment, follow the same +instructions about activating a virtual environment. There's no need to create +a new virtual environment. -Installing packages -------------------- +Install packages using pip +-------------------------- -Now that you're in your virtual environment you can install packages. Let's install the +When your virtual environment is activated, you can install packages. Use the +``pip install`` command to install packages. + +Install a package +~~~~~~~~~~~~~~~~~ + +For example,let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`: .. tab:: Unix/macOS @@ -232,8 +229,8 @@ pip should download requests and all of its dependencies and install them: .. _Requests: https://pypi.org/project/requests/ -Installing specific versions ------------------------------ +Install a specific package version +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install @@ -280,8 +277,8 @@ To install pre-release versions of packages, use the ``--pre`` flag: py -m pip install --pre requests -Installing extras ------------------ +Install extras +~~~~~~~~~~~~~~ Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets: @@ -302,10 +299,11 @@ specifying the extra in brackets: https://setuptools.readthedocs.io/en/latest/userguide/dependency_management.html#optional-dependencies -Installing from source ----------------------- +Install a package from source +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -pip can install a package directly from source, for example: +pip can install a package directly from its source code. For example, to install +the source code in the ``google-auth`` directory: .. tab:: Unix/macOS @@ -339,8 +337,8 @@ installed package without needing to re-install: py -m pip install --editable . -Installing from version control systems ---------------------------------------- +Install from version control systems +------------------------------------ pip can install packages directly from their version control system. For example, you can install directly from a git repository: @@ -353,8 +351,8 @@ For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `. -Installing from local archives ------------------------------- +Install from local archives +~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip: @@ -392,8 +390,8 @@ connectivity or if you want to strictly control the origin of distribution packages. -Using other package indexes ---------------------------- +Install from other package indexes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag: @@ -444,8 +442,8 @@ install the latest version of ``requests`` and all of its dependencies: py -m pip install --upgrade requests -Using requirements files ------------------------- +Using a requirements file +------------------------- Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For @@ -504,5 +502,5 @@ Which will output a list of package specifiers such as: six==1.11.0 urllib3==1.22 -This is useful for creating :ref:`pip:Requirements Files` that can re-create -the exact versions of all packages installed in an environment. +The ``pip freeze`` command is useful for creating :ref:`pip:Requirements Files` +that can re-create the exact versions of all packages installed in an environment. From 83e8fc644c6607c40610c24142b80e99de4e192e Mon Sep 17 00:00:00 2001 From: Carol Willing Date: Fri, 3 Nov 2023 21:04:41 -0700 Subject: [PATCH 0431/1072] fix formatting --- source/guides/installing-using-pip-and-virtual-environments.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst index ce65d971a..af2a1cad5 100644 --- a/source/guides/installing-using-pip-and-virtual-environments.rst +++ b/source/guides/installing-using-pip-and-virtual-environments.rst @@ -338,7 +338,7 @@ installed package without needing to re-install: Install from version control systems ------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ pip can install packages directly from their version control system. For example, you can install directly from a git repository: From 3d8231b000708d100b5b592cc84946b3e6a5da75 Mon Sep 17 00:00:00 2001 From: Jean Abou Samra Date: Fri, 3 Nov 2023 23:17:26 +0100 Subject: [PATCH 0432/1072] =?UTF-8?q?Re-apply=20=E2=80=9CPEP=20518:=20Remo?= =?UTF-8?q?ve=20wheel=20from=20the=20example=20requirements=20since=20it's?= =?UTF-8?q?=20a=20dependency=20of=20setuptools=E2=80=9D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- source/specifications/declaring-build-dependencies.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/declaring-build-dependencies.rst b/source/specifications/declaring-build-dependencies.rst index c9a1aac9e..3ac94b0b3 100644 --- a/source/specifications/declaring-build-dependencies.rst +++ b/source/specifications/declaring-build-dependencies.rst @@ -34,7 +34,7 @@ An example ``build-system`` table for a project built with [build-system] # Minimum requirements for the build system to execute. - requires = ["setuptools", "wheel"] + requires = ["setuptools"] Build tools are expected to use the example configuration file above as their default semantics when a ``pyproject.toml`` file is not present. From 84820945b5287ca5cb23ed19ae2e3fbb4ba91c08 Mon Sep 17 00:00:00 2001 From: Jean Abou Samra Date: Sat, 4 Nov 2023 11:21:21 +0100 Subject: [PATCH 0433/1072] Import PEP 440 verbatim --- source/specifications/version-specifiers.rst | 1661 ++++++++++++++++++ 1 file changed, 1661 insertions(+) diff --git a/source/specifications/version-specifiers.rst b/source/specifications/version-specifiers.rst index 66a709a1f..0c18f8c66 100644 --- a/source/specifications/version-specifiers.rst +++ b/source/specifications/version-specifiers.rst @@ -10,3 +10,1664 @@ between versions are defined in :pep:`440`. The version specifiers section in this PEP supersedes the version specifiers section in :pep:`345`. + + +PEP: 440 +Title: Version Identification and Dependency Specification +Author: Alyssa Coghlan , + Donald Stufft +BDFL-Delegate: Alyssa Coghlan +Discussions-To: distutils-sig@python.org +Status: Final +Type: Standards Track +Topic: Packaging +Content-Type: text/x-rst +Created: 18-Mar-2013 +Post-History: 30-Mar-2013, 27-May-2013, 20-Jun-2013, + 21-Dec-2013, 28-Jan-2014, 08-Aug-2014, + 22-Aug-2014 +Replaces: 386 +Resolution: https://mail.python.org/pipermail/distutils-sig/2014-August/024673.html + + +Abstract +======== + +This PEP describes a scheme for identifying versions of Python software +distributions, and declaring dependencies on particular versions. + +This document addresses several limitations of the previous attempt at a +standardized approach to versioning, as described in :pep:`345` and :pep:`386`. + + +Definitions +=========== + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", +"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this +document are to be interpreted as described in :rfc:`2119`. + +"Projects" are software components that are made available for integration. +Projects include Python libraries, frameworks, scripts, plugins, +applications, collections of data or other resources, and various +combinations thereof. Public Python projects are typically registered on +the `Python Package Index `__. + +"Releases" are uniquely identified snapshots of a project. + +"Distributions" are the packaged files which are used to publish +and distribute a release. + +"Build tools" are automated tools intended to run on development systems, +producing source and binary distribution archives. Build tools may also be +invoked by integration tools in order to build software distributed as +sdists rather than prebuilt binary archives. + +"Index servers" are active distribution registries which publish version and +dependency metadata and place constraints on the permitted metadata. + +"Publication tools" are automated tools intended to run on development +systems and upload source and binary distribution archives to index servers. + +"Installation tools" are integration tools specifically intended to run on +deployment targets, consuming source and binary distribution archives from +an index server or other designated location and deploying them to the target +system. + +"Automated tools" is a collective term covering build tools, index servers, +publication tools, integration tools and any other software that produces +or consumes distribution version and dependency metadata. + +Version scheme +============== + +Distributions are identified by a public version identifier which +supports all defined version comparison operations + +The version scheme is used both to describe the distribution version +provided by a particular distribution archive, as well as to place +constraints on the version of dependencies needed in order to build or +run the software. + + +Public version identifiers +-------------------------- + +The canonical public version identifiers MUST comply with the following +scheme:: + + [N!]N(.N)*[{a|b|rc}N][.postN][.devN] + +Public version identifiers MUST NOT include leading or trailing whitespace. + +Public version identifiers MUST be unique within a given distribution. + +Installation tools SHOULD ignore any public versions which do not comply with +this scheme but MUST also include the normalizations specified below. +Installation tools MAY warn the user when non-compliant or ambiguous versions +are detected. + +See also ``Appendix B : Parsing version strings with regular expressions`` +which provides a regular expression to check strict conformance with the +canonical format, as well as a more permissive regular expression accepting +inputs that may require subsequent normalization. + +Public version identifiers are separated into up to five segments: + +* Epoch segment: ``N!`` +* Release segment: ``N(.N)*`` +* Pre-release segment: ``{a|b|rc}N`` +* Post-release segment: ``.postN`` +* Development release segment: ``.devN`` + +Any given release will be a "final release", "pre-release", "post-release" or +"developmental release" as defined in the following sections. + +All numeric components MUST be non-negative integers represented as sequences +of ASCII digits. + +All numeric components MUST be interpreted and ordered according to their +numeric value, not as text strings. + +All numeric components MAY be zero. Except as described below for the +release segment, a numeric component of zero has no special significance +aside from always being the lowest possible value in the version ordering. + +.. note:: + + Some hard to read version identifiers are permitted by this scheme in + order to better accommodate the wide range of versioning practices + across existing public and private Python projects. + + Accordingly, some of the versioning practices which are technically + permitted by the PEP are strongly discouraged for new projects. Where + this is the case, the relevant details are noted in the following + sections. + + +Local version identifiers +------------------------- + +Local version identifiers MUST comply with the following scheme:: + + [+] + +They consist of a normal public version identifier (as defined in the +previous section), along with an arbitrary "local version label", separated +from the public version identifier by a plus. Local version labels have +no specific semantics assigned, but some syntactic restrictions are imposed. + +Local version identifiers are used to denote fully API (and, if applicable, +ABI) compatible patched versions of upstream projects. For example, these +may be created by application developers and system integrators by applying +specific backported bug fixes when upgrading to a new upstream release would +be too disruptive to the application or other integrated system (such as a +Linux distribution). + +The inclusion of the local version label makes it possible to differentiate +upstream releases from potentially altered rebuilds by downstream +integrators. The use of a local version identifier does not affect the kind +of a release but, when applied to a source distribution, does indicate that +it may not contain the exact same code as the corresponding upstream release. + +To ensure local version identifiers can be readily incorporated as part of +filenames and URLs, and to avoid formatting inconsistencies in hexadecimal +hash representations, local version labels MUST be limited to the following +set of permitted characters: + +* ASCII letters (``[a-zA-Z]``) +* ASCII digits (``[0-9]``) +* periods (``.``) + +Local version labels MUST start and end with an ASCII letter or digit. + +Comparison and ordering of local versions considers each segment of the local +version (divided by a ``.``) separately. If a segment consists entirely of +ASCII digits then that section should be considered an integer for comparison +purposes and if a segment contains any ASCII letters then that segment is +compared lexicographically with case insensitivity. When comparing a numeric +and lexicographic segment, the numeric section always compares as greater than +the lexicographic segment. Additionally a local version with a great number of +segments will always compare as greater than a local version with fewer +segments, as long as the shorter local version's segments match the beginning +of the longer local version's segments exactly. + +An "upstream project" is a project that defines its own public versions. A +"downstream project" is one which tracks and redistributes an upstream project, +potentially backporting security and bug fixes from later versions of the +upstream project. + +Local version identifiers SHOULD NOT be used when publishing upstream +projects to a public index server, but MAY be used to identify private +builds created directly from the project source. Local +version identifiers SHOULD be used by downstream projects when releasing a +version that is API compatible with the version of the upstream project +identified by the public version identifier, but contains additional changes +(such as bug fixes). As the Python Package Index is intended solely for +indexing and hosting upstream projects, it MUST NOT allow the use of local +version identifiers. + +Source distributions using a local version identifier SHOULD provide the +``python.integrator`` extension metadata (as defined in :pep:`459`). + + +Final releases +-------------- + +A version identifier that consists solely of a release segment and optionally +an epoch identifier is termed a "final release". + +The release segment consists of one or more non-negative integer +values, separated by dots:: + + N(.N)* + +Final releases within a project MUST be numbered in a consistently +increasing fashion, otherwise automated tools will not be able to upgrade +them correctly. + +Comparison and ordering of release segments considers the numeric value +of each component of the release segment in turn. When comparing release +segments with different numbers of components, the shorter segment is +padded out with additional zeros as necessary. + +While any number of additional components after the first are permitted +under this scheme, the most common variants are to use two components +("major.minor") or three components ("major.minor.micro"). + +For example:: + + 0.9 + 0.9.1 + 0.9.2 + ... + 0.9.10 + 0.9.11 + 1.0 + 1.0.1 + 1.1 + 2.0 + 2.0.1 + ... + +A release series is any set of final release numbers that start with a +common prefix. For example, ``3.3.1``, ``3.3.5`` and ``3.3.9.45`` are all +part of the ``3.3`` release series. + +.. note:: + + ``X.Y`` and ``X.Y.0`` are not considered distinct release numbers, as + the release segment comparison rules implicit expand the two component + form to ``X.Y.0`` when comparing it to any release segment that includes + three components. + +Date based release segments are also permitted. An example of a date based +release scheme using the year and month of the release:: + + 2012.4 + 2012.7 + 2012.10 + 2013.1 + 2013.6 + ... + + +Pre-releases +------------ + +Some projects use an "alpha, beta, release candidate" pre-release cycle to +support testing by their users prior to a final release. + +If used as part of a project's development cycle, these pre-releases are +indicated by including a pre-release segment in the version identifier:: + + X.YaN # Alpha release + X.YbN # Beta release + X.YrcN # Release Candidate + X.Y # Final release + +A version identifier that consists solely of a release segment and a +pre-release segment is termed a "pre-release". + +The pre-release segment consists of an alphabetical identifier for the +pre-release phase, along with a non-negative integer value. Pre-releases for +a given release are ordered first by phase (alpha, beta, release candidate) +and then by the numerical component within that phase. + +Installation tools MAY accept both ``c`` and ``rc`` releases for a common +release segment in order to handle some existing legacy distributions. + +Installation tools SHOULD interpret ``c`` versions as being equivalent to +``rc`` versions (that is, ``c1`` indicates the same version as ``rc1``). + +Build tools, publication tools and index servers SHOULD disallow the creation +of both ``rc`` and ``c`` releases for a common release segment. + + +Post-releases +------------- + +Some projects use post-releases to address minor errors in a final release +that do not affect the distributed software (for example, correcting an error +in the release notes). + +If used as part of a project's development cycle, these post-releases are +indicated by including a post-release segment in the version identifier:: + + X.Y.postN # Post-release + +A version identifier that includes a post-release segment without a +developmental release segment is termed a "post-release". + +The post-release segment consists of the string ``.post``, followed by a +non-negative integer value. Post-releases are ordered by their +numerical component, immediately following the corresponding release, +and ahead of any subsequent release. + +.. note:: + + The use of post-releases to publish maintenance releases containing + actual bug fixes is strongly discouraged. In general, it is better + to use a longer release number and increment the final component + for each maintenance release. + +Post-releases are also permitted for pre-releases:: + + X.YaN.postM # Post-release of an alpha release + X.YbN.postM # Post-release of a beta release + X.YrcN.postM # Post-release of a release candidate + +.. note:: + + Creating post-releases of pre-releases is strongly discouraged, as + it makes the version identifier difficult to parse for human readers. + In general, it is substantially clearer to simply create a new + pre-release by incrementing the numeric component. + + +Developmental releases +---------------------- + +Some projects make regular developmental releases, and system packagers +(especially for Linux distributions) may wish to create early releases +directly from source control which do not conflict with later project +releases. + +If used as part of a project's development cycle, these developmental +releases are indicated by including a developmental release segment in the +version identifier:: + + X.Y.devN # Developmental release + +A version identifier that includes a developmental release segment is +termed a "developmental release". + +The developmental release segment consists of the string ``.dev``, +followed by a non-negative integer value. Developmental releases are ordered +by their numerical component, immediately before the corresponding release +(and before any pre-releases with the same release segment), and following +any previous release (including any post-releases). + +Developmental releases are also permitted for pre-releases and +post-releases:: + + X.YaN.devM # Developmental release of an alpha release + X.YbN.devM # Developmental release of a beta release + X.YrcN.devM # Developmental release of a release candidate + X.Y.postN.devM # Developmental release of a post-release + +.. note:: + + While they may be useful for continuous integration purposes, publishing + developmental releases of pre-releases to general purpose public index + servers is strongly discouraged, as it makes the version identifier + difficult to parse for human readers. If such a release needs to be + published, it is substantially clearer to instead create a new + pre-release by incrementing the numeric component. + + Developmental releases of post-releases are also strongly discouraged, + but they may be appropriate for projects which use the post-release + notation for full maintenance releases which may include code changes. + + +Version epochs +-------------- + +If included in a version identifier, the epoch appears before all other +components, separated from the release segment by an exclamation mark:: + + E!X.Y # Version identifier with epoch + +If no explicit epoch is given, the implicit epoch is ``0``. + +Most version identifiers will not include an epoch, as an explicit epoch is +only needed if a project *changes* the way it handles version numbering in +a way that means the normal version ordering rules will give the wrong +answer. For example, if a project is using date based versions like +``2014.04`` and would like to switch to semantic versions like ``1.0``, then +the new releases would be identified as *older* than the date based releases +when using the normal sorting scheme:: + + 1.0 + 1.1 + 2.0 + 2013.10 + 2014.04 + +However, by specifying an explicit epoch, the sort order can be changed +appropriately, as all versions from a later epoch are sorted after versions +from an earlier epoch:: + + 2013.10 + 2014.04 + 1!1.0 + 1!1.1 + 1!2.0 + +Normalization +------------- + +In order to maintain better compatibility with existing versions there are a +number of "alternative" syntaxes that MUST be taken into account when parsing +versions. These syntaxes MUST be considered when parsing a version, however +they should be "normalized" to the standard syntax defined above. + + +Case sensitivity +~~~~~~~~~~~~~~~~ + +All ascii letters should be interpreted case insensitively within a version and +the normal form is lowercase. This allows versions such as ``1.1RC1`` which +would be normalized to ``1.1rc1``. + + +Integer Normalization +~~~~~~~~~~~~~~~~~~~~~ + +All integers are interpreted via the ``int()`` built in and normalize to the +string form of the output. This means that an integer version of ``00`` would +normalize to ``0`` while ``09000`` would normalize to ``9000``. This does not +hold true for integers inside of an alphanumeric segment of a local version +such as ``1.0+foo0100`` which is already in its normalized form. + + +Pre-release separators +~~~~~~~~~~~~~~~~~~~~~~ + +Pre-releases should allow a ``.``, ``-``, or ``_`` separator between the +release segment and the pre-release segment. The normal form for this is +without a separator. This allows versions such as ``1.1.a1`` or ``1.1-a1`` +which would be normalized to ``1.1a1``. It should also allow a separator to +be used between the pre-release signifier and the numeral. This allows versions +such as ``1.0a.1`` which would be normalized to ``1.0a1``. + + +Pre-release spelling +~~~~~~~~~~~~~~~~~~~~ + +Pre-releases allow the additional spellings of ``alpha``, ``beta``, ``c``, +``pre``, and ``preview`` for ``a``, ``b``, ``rc``, ``rc``, and ``rc`` +respectively. This allows versions such as ``1.1alpha1``, ``1.1beta2``, or +``1.1c3`` which normalize to ``1.1a1``, ``1.1b2``, and ``1.1rc3``. In every +case the additional spelling should be considered equivalent to their normal +forms. + + +Implicit pre-release number +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Pre releases allow omitting the numeral in which case it is implicitly assumed +to be ``0``. The normal form for this is to include the ``0`` explicitly. This +allows versions such as ``1.2a`` which is normalized to ``1.2a0``. + + +Post release separators +~~~~~~~~~~~~~~~~~~~~~~~ + +Post releases allow a ``.``, ``-``, or ``_`` separator as well as omitting the +separator all together. The normal form of this is with the ``.`` separator. +This allows versions such as ``1.2-post2`` or ``1.2post2`` which normalize to +``1.2.post2``. Like the pre-release separator this also allows an optional +separator between the post release signifier and the numeral. This allows +versions like ``1.2.post-2`` which would normalize to ``1.2.post2``. + + +Post release spelling +~~~~~~~~~~~~~~~~~~~~~ + +Post-releases allow the additional spellings of ``rev`` and ``r``. This allows +versions such as ``1.0-r4`` which normalizes to ``1.0.post4``. As with the +pre-releases the additional spellings should be considered equivalent to their +normal forms. + + +Implicit post release number +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Post releases allow omitting the numeral in which case it is implicitly assumed +to be ``0``. The normal form for this is to include the ``0`` explicitly. This +allows versions such as ``1.2.post`` which is normalized to ``1.2.post0``. + + +Implicit post releases +~~~~~~~~~~~~~~~~~~~~~~ + +Post releases allow omitting the ``post`` signifier all together. When using +this form the separator MUST be ``-`` and no other form is allowed. This allows +versions such as ``1.0-1`` to be normalized to ``1.0.post1``. This particular +normalization MUST NOT be used in conjunction with the implicit post release +number rule. In other words, ``1.0-`` is *not* a valid version and it does *not* +normalize to ``1.0.post0``. + + +Development release separators +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Development releases allow a ``.``, ``-``, or a ``_`` separator as well as +omitting the separator all together. The normal form of this is with the ``.`` +separator. This allows versions such as ``1.2-dev2`` or ``1.2dev2`` which +normalize to ``1.2.dev2``. + + +Implicit development release number +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Development releases allow omitting the numeral in which case it is implicitly +assumed to be ``0``. The normal form for this is to include the ``0`` +explicitly. This allows versions such as ``1.2.dev`` which is normalized to +``1.2.dev0``. + + +Local version segments +~~~~~~~~~~~~~~~~~~~~~~ + +With a local version, in addition to the use of ``.`` as a separator of +segments, the use of ``-`` and ``_`` is also acceptable. The normal form is +using the ``.`` character. This allows versions such as ``1.0+ubuntu-1`` to be +normalized to ``1.0+ubuntu.1``. + + +Preceding v character +~~~~~~~~~~~~~~~~~~~~~ + +In order to support the common version notation of ``v1.0`` versions may be +preceded by a single literal ``v`` character. This character MUST be ignored +for all purposes and should be omitted from all normalized forms of the +version. The same version with and without the ``v`` is considered equivalent. + + +Leading and Trailing Whitespace +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Leading and trailing whitespace must be silently ignored and removed from all +normalized forms of a version. This includes ``" "``, ``\t``, ``\n``, ``\r``, +``\f``, and ``\v``. This allows accidental whitespace to be handled sensibly, +such as a version like ``1.0\n`` which normalizes to ``1.0``. + + +Examples of compliant version schemes +------------------------------------- + +The standard version scheme is designed to encompass a wide range of +identification practices across public and private Python projects. In +practice, a single project attempting to use the full flexibility offered +by the scheme would create a situation where human users had difficulty +figuring out the relative order of versions, even though the rules above +ensure all compliant tools will order them consistently. + +The following examples illustrate a small selection of the different +approaches projects may choose to identify their releases, while still +ensuring that the "latest release" and the "latest stable release" can +be easily determined, both by human users and automated tools. + +Simple "major.minor" versioning:: + + 0.1 + 0.2 + 0.3 + 1.0 + 1.1 + ... + +Simple "major.minor.micro" versioning:: + + 1.1.0 + 1.1.1 + 1.1.2 + 1.2.0 + ... + +"major.minor" versioning with alpha, beta and candidate +pre-releases:: + + 0.9 + 1.0a1 + 1.0a2 + 1.0b1 + 1.0rc1 + 1.0 + 1.1a1 + ... + +"major.minor" versioning with developmental releases, release candidates +and post-releases for minor corrections:: + + 0.9 + 1.0.dev1 + 1.0.dev2 + 1.0.dev3 + 1.0.dev4 + 1.0c1 + 1.0c2 + 1.0 + 1.0.post1 + 1.1.dev1 + ... + +Date based releases, using an incrementing serial within each year, skipping +zero:: + + 2012.1 + 2012.2 + 2012.3 + ... + 2012.15 + 2013.1 + 2013.2 + ... + + +Summary of permitted suffixes and relative ordering +--------------------------------------------------- + +.. note:: + + This section is intended primarily for authors of tools that + automatically process distribution metadata, rather than developers + of Python distributions deciding on a versioning scheme. + +The epoch segment of version identifiers MUST be sorted according to the +numeric value of the given epoch. If no epoch segment is present, the +implicit numeric value is ``0``. + +The release segment of version identifiers MUST be sorted in +the same order as Python's tuple sorting when the normalized release segment is +parsed as follows:: + + tuple(map(int, release_segment.split("."))) + +All release segments involved in the comparison MUST be converted to a +consistent length by padding shorter segments with zeros as needed. + +Within a numeric release (``1.0``, ``2.7.3``), the following suffixes +are permitted and MUST be ordered as shown:: + + .devN, aN, bN, rcN, , .postN + +Note that ``c`` is considered to be semantically equivalent to ``rc`` and must +be sorted as if it were ``rc``. Tools MAY reject the case of having the same +``N`` for both a ``c`` and a ``rc`` in the same release segment as ambiguous +and remain in compliance with the PEP. + +Within an alpha (``1.0a1``), beta (``1.0b1``), or release candidate +(``1.0rc1``, ``1.0c1``), the following suffixes are permitted and MUST be +ordered as shown:: + + .devN, , .postN + +Within a post-release (``1.0.post1``), the following suffixes are permitted +and MUST be ordered as shown:: + + .devN, + +Note that ``devN`` and ``postN`` MUST always be preceded by a dot, even +when used immediately following a numeric version (e.g. ``1.0.dev456``, +``1.0.post1``). + +Within a pre-release, post-release or development release segment with a +shared prefix, ordering MUST be by the value of the numeric component. + +The following example covers many of the possible combinations:: + + 1.dev0 + 1.0.dev456 + 1.0a1 + 1.0a2.dev456 + 1.0a12.dev456 + 1.0a12 + 1.0b1.dev456 + 1.0b2 + 1.0b2.post345.dev456 + 1.0b2.post345 + 1.0rc1.dev456 + 1.0rc1 + 1.0 + 1.0+abc.5 + 1.0+abc.7 + 1.0+5 + 1.0.post456.dev34 + 1.0.post456 + 1.0.15 + 1.1.dev1 + + +Version ordering across different metadata versions +--------------------------------------------------- + +Metadata v1.0 (:pep:`241`) and metadata v1.1 (:pep:`314`) do not specify a standard +version identification or ordering scheme. However metadata v1.2 (:pep:`345`) +does specify a scheme which is defined in :pep:`386`. + +Due to the nature of the simple installer API it is not possible for an +installer to be aware of which metadata version a particular distribution was +using. Additionally installers required the ability to create a reasonably +prioritized list that includes all, or as many as possible, versions of +a project to determine which versions it should install. These requirements +necessitate a standardization across one parsing mechanism to be used for all +versions of a project. + +Due to the above, this PEP MUST be used for all versions of metadata and +supersedes :pep:`386` even for metadata v1.2. Tools SHOULD ignore any versions +which cannot be parsed by the rules in this PEP, but MAY fall back to +implementation defined version parsing and ordering schemes if no versions +complying with this PEP are available. + +Distribution users may wish to explicitly remove non-compliant versions from +any private package indexes they control. + + +Compatibility with other version schemes +---------------------------------------- + +Some projects may choose to use a version scheme which requires +translation in order to comply with the public version scheme defined in +this PEP. In such cases, the project specific version can be stored in the +metadata while the translated public version is published in the version field. + +This allows automated distribution tools to provide consistently correct +ordering of published releases, while still allowing developers to use +the internal versioning scheme they prefer for their projects. + + +Semantic versioning +~~~~~~~~~~~~~~~~~~~ + +`Semantic versioning`_ is a popular version identification scheme that is +more prescriptive than this PEP regarding the significance of different +elements of a release number. Even if a project chooses not to abide by +the details of semantic versioning, the scheme is worth understanding as +it covers many of the issues that can arise when depending on other +distributions, and when publishing a distribution that others rely on. + +The "Major.Minor.Patch" (described in this PEP as "major.minor.micro") +aspects of semantic versioning (clauses 1-8 in the 2.0.0 specification) +are fully compatible with the version scheme defined in this PEP, and abiding +by these aspects is encouraged. + +Semantic versions containing a hyphen (pre-releases - clause 10) or a +plus sign (builds - clause 11) are *not* compatible with this PEP +and are not permitted in the public version field. + +One possible mechanism to translate such semantic versioning based source +labels to compatible public versions is to use the ``.devN`` suffix to +specify the appropriate version order. + +Specific build information may also be included in local version labels. + +.. _Semantic versioning: https://semver.org/ + + +DVCS based version labels +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Many build tools integrate with distributed version control systems like +Git and Mercurial in order to add an identifying hash to the version +identifier. As hashes cannot be ordered reliably such versions are not +permitted in the public version field. + +As with semantic versioning, the public ``.devN`` suffix may be used to +uniquely identify such releases for publication, while the original DVCS based +label can be stored in the project metadata. + +Identifying hash information may also be included in local version labels. + + +Olson database versioning +~~~~~~~~~~~~~~~~~~~~~~~~~ + +The ``pytz`` project inherits its versioning scheme from the corresponding +Olson timezone database versioning scheme: the year followed by a lowercase +character indicating the version of the database within that year. + +This can be translated to a compliant public version identifier as +``.``, where the serial starts at zero or one (for the +'a' release) and is incremented with each subsequent database +update within the year. + +As with other translated version identifiers, the corresponding Olson +database version could be recorded in the project metadata. + + +Version specifiers +================== + +A version specifier consists of a series of version clauses, separated by +commas. For example:: + + ~= 0.9, >= 1.0, != 1.3.4.*, < 2.0 + +The comparison operator determines the kind of version clause: + +* ``~=``: `Compatible release`_ clause +* ``==``: `Version matching`_ clause +* ``!=``: `Version exclusion`_ clause +* ``<=``, ``>=``: `Inclusive ordered comparison`_ clause +* ``<``, ``>``: `Exclusive ordered comparison`_ clause +* ``===``: `Arbitrary equality`_ clause. + +The comma (",") is equivalent to a logical **and** operator: a candidate +version must match all given version clauses in order to match the +specifier as a whole. + +Whitespace between a conditional operator and the following version +identifier is optional, as is the whitespace around the commas. + +When multiple candidate versions match a version specifier, the preferred +version SHOULD be the latest version as determined by the consistent +ordering defined by the standard `Version scheme`_. Whether or not +pre-releases are considered as candidate versions SHOULD be handled as +described in `Handling of pre-releases`_. + +Except where specifically noted below, local version identifiers MUST NOT be +permitted in version specifiers, and local version labels MUST be ignored +entirely when checking if candidate versions match a given version +specifier. + + +Compatible release +------------------ + +A compatible release clause consists of the compatible release operator ``~=`` +and a version identifier. It matches any candidate version that is expected +to be compatible with the specified version. + +The specified version identifier must be in the standard format described in +`Version scheme`_. Local version identifiers are NOT permitted in this +version specifier. + +For a given release identifier ``V.N``, the compatible release clause is +approximately equivalent to the pair of comparison clauses:: + + >= V.N, == V.* + +This operator MUST NOT be used with a single segment version number such as +``~=1``. + +For example, the following groups of version clauses are equivalent:: + + ~= 2.2 + >= 2.2, == 2.* + + ~= 1.4.5 + >= 1.4.5, == 1.4.* + +If a pre-release, post-release or developmental release is named in a +compatible release clause as ``V.N.suffix``, then the suffix is ignored +when determining the required prefix match:: + + ~= 2.2.post3 + >= 2.2.post3, == 2.* + + ~= 1.4.5a4 + >= 1.4.5a4, == 1.4.* + +The padding rules for release segment comparisons means that the assumed +degree of forward compatibility in a compatible release clause can be +controlled by appending additional zeros to the version specifier:: + + ~= 2.2.0 + >= 2.2.0, == 2.2.* + + ~= 1.4.5.0 + >= 1.4.5.0, == 1.4.5.* + + +Version matching +---------------- + +A version matching clause includes the version matching operator ``==`` +and a version identifier. + +The specified version identifier must be in the standard format described in +`Version scheme`_, but a trailing ``.*`` is permitted on public version +identifiers as described below. + +By default, the version matching operator is based on a strict equality +comparison: the specified version must be exactly the same as the requested +version. The *only* substitution performed is the zero padding of the +release segment to ensure the release segments are compared with the same +length. + +Whether or not strict version matching is appropriate depends on the specific +use case for the version specifier. Automated tools SHOULD at least issue +warnings and MAY reject them entirely when strict version matches are used +inappropriately. + +Prefix matching may be requested instead of strict comparison, by appending +a trailing ``.*`` to the version identifier in the version matching clause. +This means that additional trailing segments will be ignored when +determining whether or not a version identifier matches the clause. If the +specified version includes only a release segment, than trailing components +(or the lack thereof) in the release segment are also ignored. + +For example, given the version ``1.1.post1``, the following clauses would +match or not as shown:: + + == 1.1 # Not equal, so 1.1.post1 does not match clause + == 1.1.post1 # Equal, so 1.1.post1 matches clause + == 1.1.* # Same prefix, so 1.1.post1 matches clause + +For purposes of prefix matching, the pre-release segment is considered to +have an implied preceding ``.``, so given the version ``1.1a1``, the +following clauses would match or not as shown:: + + == 1.1 # Not equal, so 1.1a1 does not match clause + == 1.1a1 # Equal, so 1.1a1 matches clause + == 1.1.* # Same prefix, so 1.1a1 matches clause if pre-releases are requested + +An exact match is also considered a prefix match (this interpretation is +implied by the usual zero padding rules for the release segment of version +identifiers). Given the version ``1.1``, the following clauses would +match or not as shown:: + + == 1.1 # Equal, so 1.1 matches clause + == 1.1.0 # Zero padding expands 1.1 to 1.1.0, so it matches clause + == 1.1.dev1 # Not equal (dev-release), so 1.1 does not match clause + == 1.1a1 # Not equal (pre-release), so 1.1 does not match clause + == 1.1.post1 # Not equal (post-release), so 1.1 does not match clause + == 1.1.* # Same prefix, so 1.1 matches clause + +It is invalid to have a prefix match containing a development or local release +such as ``1.0.dev1.*`` or ``1.0+foo1.*``. If present, the development release +segment is always the final segment in the public version, and the local version +is ignored for comparison purposes, so using either in a prefix match wouldn't +make any sense. + +The use of ``==`` (without at least the wildcard suffix) when defining +dependencies for published distributions is strongly discouraged as it +greatly complicates the deployment of security fixes. The strict version +comparison operator is intended primarily for use when defining +dependencies for repeatable *deployments of applications* while using +a shared distribution index. + +If the specified version identifier is a public version identifier (no +local version label), then the local version label of any candidate versions +MUST be ignored when matching versions. + +If the specified version identifier is a local version identifier, then the +local version labels of candidate versions MUST be considered when matching +versions, with the public version identifier being matched as described +above, and the local version label being checked for equivalence using a +strict string equality comparison. + + +Version exclusion +----------------- + +A version exclusion clause includes the version exclusion operator ``!=`` +and a version identifier. + +The allowed version identifiers and comparison semantics are the same as +those of the `Version matching`_ operator, except that the sense of any +match is inverted. + +For example, given the version ``1.1.post1``, the following clauses would +match or not as shown:: + + != 1.1 # Not equal, so 1.1.post1 matches clause + != 1.1.post1 # Equal, so 1.1.post1 does not match clause + != 1.1.* # Same prefix, so 1.1.post1 does not match clause + + +Inclusive ordered comparison +---------------------------- + +An inclusive ordered comparison clause includes a comparison operator and a +version identifier, and will match any version where the comparison is correct +based on the relative position of the candidate version and the specified +version given the consistent ordering defined by the standard +`Version scheme`_. + +The inclusive ordered comparison operators are ``<=`` and ``>=``. + +As with version matching, the release segment is zero padded as necessary to +ensure the release segments are compared with the same length. + +Local version identifiers are NOT permitted in this version specifier. + + +Exclusive ordered comparison +---------------------------- + +The exclusive ordered comparisons ``>`` and ``<`` are similar to the inclusive +ordered comparisons in that they rely on the relative position of the candidate +version and the specified version given the consistent ordering defined by the +standard `Version scheme`_. However, they specifically exclude pre-releases, +post-releases, and local versions of the specified version. + +The exclusive ordered comparison ``>V`` **MUST NOT** allow a post-release +of the given version unless ``V`` itself is a post release. You may mandate +that releases are later than a particular post release, including additional +post releases, by using ``>V.postN``. For example, ``>1.7`` will allow +``1.7.1`` but not ``1.7.0.post1`` and ``>1.7.post2`` will allow ``1.7.1`` +and ``1.7.0.post3`` but not ``1.7.0``. + +The exclusive ordered comparison ``>V`` **MUST NOT** match a local version of +the specified version. + +The exclusive ordered comparison ``=`` entry as +part of the URL fragment. + +For version control references, the ``VCS+protocol`` scheme SHOULD be +used to identify both the version control system and the secure transport, +and a version control system with hash based commit identifiers SHOULD be +used. Automated tools MAY omit warnings about missing hashes for version +control systems that do not provide hash based commit identifiers. + +To handle version control systems that do not support including commit or +tag references directly in the URL, that information may be appended to the +end of the URL using the ``@`` or the ``@#`` +notation. + +.. note:: + + This isn't *quite* the same as the existing VCS reference notation + supported by pip. Firstly, the distribution name is moved in front rather + than embedded as part of the URL. Secondly, the commit hash is included + even when retrieving based on a tag, in order to meet the requirement + above that *every* link should include a hash to make things harder to + forge (creating a malicious repo with a particular tag is easy, creating + one with a specific *hash*, less so). + +Remote URL examples:: + + pip @ https://github.com/pypa/pip/archive/1.3.1.zip#sha1=da9234ee9982d4bbb3c72346a6de940a148ea686 + pip @ git+https://github.com/pypa/pip.git@7921be1537eac1e97bc40179a57f0349c2aee67d + pip @ git+https://github.com/pypa/pip.git@1.3.1#7921be1537eac1e97bc40179a57f0349c2aee67d + + +File URLs +--------- + +File URLs take the form of ``file:///``. If the ```` is +omitted it is assumed to be ``localhost`` and even if the ```` is omitted +the third slash MUST still exist. The ```` defines what the file path on +the filesystem that is to be accessed. + +On the various \*nix operating systems the only allowed values for ```` +is for it to be omitted, ``localhost``, or another FQDN that the current +machine believes matches its own host. In other words, on \*nix the ``file://`` +scheme can only be used to access paths on the local machine. + +On Windows the file format should include the drive letter if applicable as +part of the ```` (e.g. ``file:///c:/path/to/a/file``). Unlike \*nix on +Windows the ```` parameter may be used to specify a file residing on a +network share. In other words, in order to translate ``\\machine\volume\file`` +to a ``file://`` url, it would end up as ``file://machine/volume/file``. For +more information on ``file://`` URLs on Windows see MSDN [4]_. + + +Updating the versioning specification +===================================== + +The versioning specification may be updated with clarifications without +requiring a new PEP or a change to the metadata version. + +Any technical changes that impact the version identification and comparison +syntax and semantics would require an updated versioning scheme to be +defined in a new PEP. + + +Summary of differences from pkg_resources.parse_version +======================================================= + +* Note: this comparison is to ``pkg_resourses.parse_version`` as it existed at + the time the PEP was written. After the PEP was accepted, setuptools 6.0 and + later versions adopted the behaviour described in this PEP. + +* Local versions sort differently, this PEP requires that they sort as greater + than the same version without a local version, whereas + ``pkg_resources.parse_version`` considers it a pre-release marker. + +* This PEP purposely restricts the syntax which constitutes a valid version + while ``pkg_resources.parse_version`` attempts to provide some meaning from + *any* arbitrary string. + +* ``pkg_resources.parse_version`` allows arbitrarily deeply nested version + signifiers like ``1.0.dev1.post1.dev5``. This PEP however allows only a + single use of each type and they must exist in a certain order. + + +Summary of differences from PEP 386 +=================================== + +* Moved the description of version specifiers into the versioning PEP + +* Added the "direct reference" concept as a standard notation for direct + references to resources (rather than each tool needing to invent its own) + +* Added the "local version identifier" and "local version label" concepts to + allow system integrators to indicate patched builds in a way that is + supported by the upstream tools, as well as to allow the incorporation of + build tags into the versioning of binary distributions. + +* Added the "compatible release" clause + +* Added the trailing wildcard syntax for prefix based version matching + and exclusion + +* Changed the top level sort position of the ``.devN`` suffix + +* Allowed single value version numbers + +* Explicit exclusion of leading or trailing whitespace + +* Explicit support for date based versions + +* Explicit normalisation rules to improve compatibility with + existing version metadata on PyPI where it doesn't introduce + ambiguity + +* Implicitly exclude pre-releases unless they're already present or + needed to satisfy a dependency + +* Treat post releases the same way as unqualified releases + +* Discuss ordering and dependencies across metadata versions + +* Switch from preferring ``c`` to ``rc``. + +The rationale for major changes is given in the following sections. + + +Changing the version scheme +--------------------------- + +One key change in the version scheme in this PEP relative to that in +:pep:`386` is to sort top level developmental releases like ``X.Y.devN`` ahead +of alpha releases like ``X.Ya1``. This is a far more logical sort order, as +projects already using both development releases and alphas/betas/release +candidates do not want their developmental releases sorted in +between their release candidates and their final releases. There is no +rationale for using ``dev`` releases in that position rather than +merely creating additional release candidates. + +The updated sort order also means the sorting of ``dev`` versions is now +consistent between the metadata standard and the pre-existing behaviour +of ``pkg_resources`` (and hence the behaviour of current installation +tools). + +Making this change should make it easier for affected existing projects to +migrate to the latest version of the metadata standard. + +Another change to the version scheme is to allow single number +versions, similar to those used by non-Python projects like Mozilla +Firefox, Google Chrome and the Fedora Linux distribution. This is actually +expected to be more useful for version specifiers, but it is easier to +allow it for both version specifiers and release numbers, rather than +splitting the two definitions. + +The exclusion of leading and trailing whitespace was made explicit after +a couple of projects with version identifiers differing only in a +trailing ``\n`` character were found on PyPI. + +Various other normalisation rules were also added as described in the +separate section on version normalisation below. + +``Appendix A`` shows detailed results of an analysis of PyPI distribution +version information, as collected on 8th August, 2014. This analysis +compares the behavior of the explicitly ordered version scheme defined in +this PEP with the de facto standard defined by the behavior of setuptools. +These metrics are useful, as the intent of this PEP is to follow existing +setuptools behavior as closely as is feasible, while still throwing +exceptions for unorderable versions (rather than trying to guess an +appropriate order as setuptools does). + + +A more opinionated description of the versioning scheme +------------------------------------------------------- + +As in :pep:`386`, the primary focus is on codifying existing practices to make +them more amenable to automation, rather than demanding that existing +projects make non-trivial changes to their workflow. However, the +standard scheme allows significantly more flexibility than is needed +for the vast majority of simple Python packages (which often don't even +need maintenance releases - many users are happy with needing to upgrade to a +new feature release to get bug fixes). + +For the benefit of novice developers, and for experienced developers +wishing to better understand the various use cases, the specification +now goes into much greater detail on the components of the defined +version scheme, including examples of how each component may be used +in practice. + +The PEP also explicitly guides developers in the direction of +semantic versioning (without requiring it), and discourages the use of +several aspects of the full versioning scheme that have largely been +included in order to cover esoteric corner cases in the practices of +existing projects and in repackaging software for Linux distributions. + + +Describing version specifiers alongside the versioning scheme +------------------------------------------------------------- + +The main reason to even have a standardised version scheme in the first place +is to make it easier to do reliable automated dependency analysis. It makes +more sense to describe the primary use case for version identifiers alongside +their definition. + + +Changing the interpretation of version specifiers +------------------------------------------------- + +The previous interpretation of version specifiers made it very easy to +accidentally download a pre-release version of a dependency. This in +turn made it difficult for developers to publish pre-release versions +of software to the Python Package Index, as even marking the package as +hidden wasn't enough to keep automated tools from downloading it, and also +made it harder for users to obtain the test release manually through the +main PyPI web interface. + +The previous interpretation also excluded post-releases from some version +specifiers for no adequately justified reason. + +The updated interpretation is intended to make it difficult to accidentally +accept a pre-release version as satisfying a dependency, while still +allowing pre-release versions to be retrieved automatically when that's the +only way to satisfy a dependency. + +The "some forward compatibility assumed" version constraint is derived from the +Ruby community's "pessimistic version constraint" operator [2]_ to allow +projects to take a cautious approach to forward compatibility promises, while +still easily setting a minimum required version for their dependencies. The +spelling of the compatible release clause (``~=``) is inspired by the Ruby +(``~>``) and PHP (``~``) equivalents. + +Further improvements are also planned to the handling of parallel +installation of multiple versions of the same library, but these will +depend on updates to the installation database definition along with +improved tools for dynamic path manipulation. + +The trailing wildcard syntax to request prefix based version matching was +added to make it possible to sensibly define compatible release clauses. + + +Support for date based version identifiers +------------------------------------------ + +Excluding date based versions caused significant problems in migrating +``pytz`` to the new metadata standards. It also caused concerns for the +OpenStack developers, as they use a date based versioning scheme and would +like to be able to migrate to the new metadata standards without changing +it. + + +Adding version epochs +--------------------- + +Version epochs are added for the same reason they are part of other +versioning schemes, such as those of the Fedora and Debian Linux +distributions: to allow projects to gracefully change their approach to +numbering releases, without having a new release appear to have a lower +version number than previous releases and without having to change the name +of the project. + +In particular, supporting version epochs allows a project that was previously +using date based versioning to switch to semantic versioning by specifying +a new version epoch. + +The ``!`` character was chosen to delimit an epoch version rather than the +``:`` character, which is commonly used in other systems, due to the fact that +``:`` is not a valid character in a Windows directory name. + + +Adding direct references +------------------------ + +Direct references are added as an "escape clause" to handle messy real +world situations that don't map neatly to the standard distribution model. +This includes dependencies on unpublished software for internal use, as well +as handling the more complex compatibility issues that may arise when +wrapping third party libraries as C extensions (this is of especial concern +to the scientific community). + +Index servers are deliberately given a lot of freedom to disallow direct +references, since they're intended primarily as a tool for integrators +rather than publishers. PyPI in particular is currently going through the +process of *eliminating* dependencies on external references, as unreliable +external services have the effect of slowing down installation operations, +as well as reducing PyPI's own apparent reliability. + + +Adding arbitrary equality +------------------------- + +Arbitrary equality is added as an "escape clause" to handle the case where +someone needs to install a project which uses a non compliant version. Although +this PEP is able to attain ~97% compatibility with the versions that are +already on PyPI there are still ~3% of versions which cannot be parsed. This +operator gives a simple and effective way to still depend on them without +having to "guess" at the semantics of what they mean (which would be required +if anything other than strict string based equality was supported). + + +Adding local version identifiers +-------------------------------- + +It's a fact of life that downstream integrators often need to backport +upstream bug fixes to older versions. It's one of the services that gets +Linux distro vendors paid, and application developers may also apply patches +they need to bundled dependencies. + +Historically, this practice has been invisible to cross-platform language +specific distribution tools - the reported "version" in the upstream +metadata is the same as for the unmodified code. This inaccuracy can then +cause problems when attempting to work with a mixture of integrator +provided code and unmodified upstream code, or even just attempting to +identify exactly which version of the software is installed. + +The introduction of local version identifiers and "local version labels" +into the versioning scheme, with the corresponding ``python.integrator`` +metadata extension allows this kind of activity to be represented +accurately, which should improve interoperability between the upstream +tools and various integrated platforms. + +The exact scheme chosen is largely modeled on the existing behavior of +``pkg_resources.parse_version`` and ``pkg_resources.parse_requirements``, +with the main distinction being that where ``pkg_resources`` currently always +takes the suffix into account when comparing versions for exact matches, +the PEP requires that the local version label of the candidate version be +ignored when no local version label is present in the version specifier +clause. Furthermore, the PEP does not attempt to impose any structure on +the local version labels (aside from limiting the set of permitted +characters and defining their ordering). + +This change is designed to ensure that an integrator provided version like +``pip 1.5+1`` or ``pip 1.5+1.git.abc123de`` will still satisfy a version +specifier like ``pip>=1.5``. + +The plus is chosen primarily for readability of local version identifiers. +It was chosen instead of the hyphen to prevent +``pkg_resources.parse_version`` from parsing it as a prerelease, which is +important for enabling a successful migration to the new, more structured, +versioning scheme. The plus was chosen instead of a tilde because of the +significance of the tilde in Debian's version ordering algorithm. + + +Providing explicit version normalization rules +---------------------------------------------- + +Historically, the de facto standard for parsing versions in Python has been the +``pkg_resources.parse_version`` command from the setuptools project. This does +not attempt to reject *any* version and instead tries to make something +meaningful, with varying levels of success, out of whatever it is given. It has +a few simple rules but otherwise it more or less relies largely on string +comparison. + +The normalization rules provided in this PEP exist primarily to either increase +the compatibility with ``pkg_resources.parse_version``, particularly in +documented use cases such as ``rev``, ``r``, ``pre``, etc or to do something +more reasonable with versions that already exist on PyPI. + +All possible normalization rules were weighed against whether or not they were +*likely* to cause any ambiguity (e.g. while someone might devise a scheme where +``v1.0`` and ``1.0`` are considered distinct releases, the likelihood of anyone +actually doing that, much less on any scale that is noticeable, is fairly low). +They were also weighed against how ``pkg_resources.parse_version`` treated a +particular version string, especially with regards to how it was sorted. Finally +each rule was weighed against the kinds of additional versions it allowed, how +"ugly" those versions looked, how hard there were to parse (both mentally and +mechanically) and how much additional compatibility it would bring. + +The breadth of possible normalizations were kept to things that could easily +be implemented as part of the parsing of the version and not pre-parsing +transformations applied to the versions. This was done to limit the side +effects of each transformation as simple search and replace style transforms +increase the likelihood of ambiguous or "junk" versions. + +For an extended discussion on the various types of normalizations that were +considered, please see the proof of concept for :pep:`440` within pip [5]_. + + +Allowing Underscore in Normalization +------------------------------------ + +There are not a lot of projects on PyPI which utilize a ``_`` in the version +string. However this PEP allows its use anywhere that ``-`` is acceptable. The +reason for this is that the Wheel normalization scheme specifies that ``-`` +gets normalized to a ``_`` to enable easier parsing of the filename. + + +Summary of changes to PEP 440 +============================= + +The following changes were made to this PEP based on feedback received after +the initial reference implementation was released in setuptools 8.0 and pip +6.0: + +* The exclusive ordered comparisons were updated to no longer imply a ``!=V.*`` + which was deemed to be surprising behavior which was too hard to accurately + describe. Instead the exclusive ordered comparisons will simply disallow + matching pre-releases, post-releases, and local versions of the specified + version (unless the specified version is itself a pre-release, post-release + or local version). For an extended discussion see the threads on + distutils-sig [6]_ [7]_. + +* The normalized form for release candidates was updated from 'c' to 'rc'. + This change was based on user feedback received when setuptools 8.0 + started applying normalisation to the release metadata generated when + preparing packages for publication on PyPI [8]_. + +* The PEP text and the ``is_canonical`` regex were updated to be explicit + that numeric components are specifically required to be represented as + sequences of ASCII digits, not arbitrary Unicode [Nd] code points. This + was previously implied by the version parsing regex in Appendix B, but + not stated explicitly [10]_. + + + +References +========== + +The initial attempt at a standardised version scheme, along with the +justifications for needing such a standard can be found in :pep:`386`. + +.. [2] `Version compatibility analysis script + `__ + +.. [4] `File URIs in Windows + `__ + +.. [5] `Proof of Concept: PEP 440 within pip + `__ + +.. [6] `PEP440: foo-X.Y.Z does not satisfy "foo>X.Y" + `__ + +.. [7] `PEP440: >1.7 vs >=1.7 + `__ + +.. [8] `Amend PEP 440 with Wider Feedback on Release Candidates + `__ + +.. [10] `PEP 440: regex should not permit Unicode [Nd] characters + `__ + +* `Reference Implementation of PEP 440 Versions and Specifiers + `__ + +* `Pessimistic version constraint + `__ + +* `Changing the status of PEP 440 to Provisional + `__ + +Appendix A +========== + +Metadata v2.0 guidelines versus setuptools:: + + $ invoke check.pep440 + Total Version Compatibility: 245806/250521 (98.12%) + Total Sorting Compatibility (Unfiltered): 45441/47114 (96.45%) + Total Sorting Compatibility (Filtered): 47057/47114 (99.88%) + Projects with No Compatible Versions: 498/47114 (1.06%) + Projects with Differing Latest Version: 688/47114 (1.46%) + +Appendix B : Parsing version strings with regular expressions +============================================================= + +As noted earlier in the ``Public version identifiers`` section, published +version identifiers SHOULD use the canonical format. This section provides +regular expressions that can be used to test whether a version is already +in that form, and if it's not, extract the various components for subsequent +normalization. + +To test whether a version identifier is in the canonical format, you can use +the following function:: + + import re + def is_canonical(version): + return re.match(r'^([1-9][0-9]*!)?(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*))*((a|b|rc)(0|[1-9][0-9]*))?(\.post(0|[1-9][0-9]*))?(\.dev(0|[1-9][0-9]*))?$', version) is not None + +To extract the components of a version identifier, use the following regular +expression (as defined by the `packaging `_ +project):: + + VERSION_PATTERN = r""" + v? + (?: + (?:(?P[0-9]+)!)? # epoch + (?P[0-9]+(?:\.[0-9]+)*) # release segment + (?P
                                          # pre-release
+                [-_\.]?
+                (?P(a|b|c|rc|alpha|beta|pre|preview))
+                [-_\.]?
+                (?P[0-9]+)?
+            )?
+            (?P                                         # post release
+                (?:-(?P[0-9]+))
+                |
+                (?:
+                    [-_\.]?
+                    (?Ppost|rev|r)
+                    [-_\.]?
+                    (?P[0-9]+)?
+                )
+            )?
+            (?P                                          # dev release
+                [-_\.]?
+                (?Pdev)
+                [-_\.]?
+                (?P[0-9]+)?
+            )?
+        )
+        (?:\+(?P[a-z0-9]+(?:[-_\.][a-z0-9]+)*))?       # local version
+    """
+
+    _regex = re.compile(
+        r"^\s*" + VERSION_PATTERN + r"\s*$",
+        re.VERBOSE | re.IGNORECASE,
+    )
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.

From 8997a3ad04df67bad4a8cf8222d139331e5d9190 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sat, 4 Nov 2023 11:52:12 +0100
Subject: [PATCH 0434/1072] PEP 440: Editing to fit packaging.python.org

---
 source/specifications/version-specifiers.rst | 472 ++-----------------
 1 file changed, 29 insertions(+), 443 deletions(-)

diff --git a/source/specifications/version-specifiers.rst b/source/specifications/version-specifiers.rst
index 0c18f8c66..52ef5aca5 100644
--- a/source/specifications/version-specifiers.rst
+++ b/source/specifications/version-specifiers.rst
@@ -1,44 +1,16 @@
-
 .. _version-specifiers:
 
 ==================
 Version specifiers
 ==================
 
-Version numbering requirements and the semantics for specifying comparisons
-between versions are defined in :pep:`440`.
-
-The version specifiers section in this PEP supersedes the version specifiers
-section in :pep:`345`.
-
-
-PEP: 440
-Title: Version Identification and Dependency Specification
-Author: Alyssa Coghlan ,
-        Donald Stufft 
-BDFL-Delegate: Alyssa Coghlan 
-Discussions-To: distutils-sig@python.org
-Status: Final
-Type: Standards Track
-Topic: Packaging
-Content-Type: text/x-rst
-Created: 18-Mar-2013
-Post-History: 30-Mar-2013, 27-May-2013, 20-Jun-2013,
-              21-Dec-2013, 28-Jan-2014, 08-Aug-2014,
-              22-Aug-2014
-Replaces: 386
-Resolution: https://mail.python.org/pipermail/distutils-sig/2014-August/024673.html
-
 
 Abstract
 ========
 
-This PEP describes a scheme for identifying versions of Python software
+This specification describes a scheme for identifying versions of Python software
 distributions, and declaring dependencies on particular versions.
 
-This document addresses several limitations of the previous attempt at a
-standardized approach to versioning, as described in :pep:`345` and :pep:`386`.
-
 
 Definitions
 ===========
@@ -47,17 +19,6 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in :rfc:`2119`.
 
-"Projects" are software components that are made available for integration.
-Projects include Python libraries, frameworks, scripts, plugins,
-applications, collections of data or other resources, and various
-combinations thereof. Public Python projects are typically registered on
-the `Python Package Index `__.
-
-"Releases" are uniquely identified snapshots of a project.
-
-"Distributions" are the packaged files which are used to publish
-and distribute a release.
-
 "Build tools" are automated tools intended to run on development systems,
 producing source and binary distribution archives. Build tools may also be
 invoked by integration tools in order to build software distributed as
@@ -78,6 +39,7 @@ system.
 publication tools, integration tools and any other software that produces
 or consumes distribution version and dependency metadata.
 
+
 Version scheme
 ==============
 
@@ -90,6 +52,8 @@ constraints on the version of dependencies needed in order to build or
 run the software.
 
 
+.. _public-version-identifiers:
+
 Public version identifiers
 --------------------------
 
@@ -107,10 +71,10 @@ this scheme but MUST also include the normalizations specified below.
 Installation tools MAY warn the user when non-compliant or ambiguous versions
 are detected.
 
-See also ``Appendix B : Parsing version strings with regular expressions``
-which provides a regular expression to check strict conformance with the
-canonical format, as well as a more permissive regular expression accepting
-inputs that may require subsequent normalization.
+See also :ref:`version-specifiers-regex` which provides a regular
+expression to check strict conformance with the canonical format, as
+well as a more permissive regular expression accepting inputs that may
+require subsequent normalization.
 
 Public version identifiers are separated into up to five segments:
 
@@ -726,7 +690,7 @@ a project to determine which versions it should install. These requirements
 necessitate a standardization across one parsing mechanism to be used for all
 versions of a project.
 
-Due to the above, this PEP MUST be used for all versions of metadata and
+Due to the above, this specification MUST be used for all versions of metadata and
 supersedes :pep:`386` even for metadata v1.2. Tools SHOULD ignore any versions
 which cannot be parsed by the rules in this PEP, but MAY fall back to
 implementation defined version parsing and ordering schemes if no versions
@@ -765,7 +729,7 @@ are fully compatible with the version scheme defined in this PEP, and abiding
 by these aspects is encouraged.
 
 Semantic versions containing a hyphen (pre-releases - clause 10) or a
-plus sign (builds - clause 11) are *not* compatible with this PEP
+plus sign (builds - clause 11) are *not* compatible with this specification
 and are not permitted in the public version field.
 
 One possible mechanism to translate such semantic versioning based source
@@ -1200,26 +1164,17 @@ part of the ```` (e.g. ``file:///c:/path/to/a/file``). Unlike \*nix on
 Windows the ```` parameter may be used to specify a file residing on a
 network share. In other words, in order to translate ``\\machine\volume\file``
 to a ``file://`` url, it would end up as ``file://machine/volume/file``. For
-more information on ``file://`` URLs on Windows see MSDN [4]_.
-
+more information on ``file://`` URLs on Windows see
+`MSDN `_.
 
-Updating the versioning specification
-=====================================
-
-The versioning specification may be updated with clarifications without
-requiring a new PEP or a change to the metadata version.
-
-Any technical changes that impact the version identification and comparison
-syntax and semantics would require an updated versioning scheme to be
-defined in a new PEP.
 
 
 Summary of differences from pkg_resources.parse_version
 =======================================================
 
 * Note: this comparison is to ``pkg_resourses.parse_version`` as it existed at
-  the time the PEP was written. After the PEP was accepted, setuptools 6.0 and
-  later versions adopted the behaviour described in this PEP.
+  the time :pep:`440` was written. After the PEP was accepted, setuptools 6.0 and
+  later versions adopted the behaviour described here.
 
 * Local versions sort differently, this PEP requires that they sort as greater
   than the same version without a local version, whereas
@@ -1234,390 +1189,17 @@ Summary of differences from pkg_resources.parse_version
   single use of each type and they must exist in a certain order.
 
 
-Summary of differences from PEP 386
-===================================
-
-* Moved the description of version specifiers into the versioning PEP
-
-* Added the "direct reference" concept as a standard notation for direct
-  references to resources (rather than each tool needing to invent its own)
-
-* Added the "local version identifier" and "local version label" concepts to
-  allow system integrators to indicate patched builds in a way that is
-  supported by the upstream tools, as well as to allow the incorporation of
-  build tags into the versioning of binary distributions.
-
-* Added the "compatible release" clause
-
-* Added the trailing wildcard syntax for prefix based version matching
-  and exclusion
-
-* Changed the top level sort position of the ``.devN`` suffix
-
-* Allowed single value version numbers
-
-* Explicit exclusion of leading or trailing whitespace
-
-* Explicit support for date based versions
-
-* Explicit normalisation rules to improve compatibility with
-  existing version metadata on PyPI where it doesn't introduce
-  ambiguity
-
-* Implicitly exclude pre-releases unless they're already present or
-  needed to satisfy a dependency
-
-* Treat post releases the same way as unqualified releases
-
-* Discuss ordering and dependencies across metadata versions
-
-* Switch from preferring ``c`` to ``rc``.
-
-The rationale for major changes is given in the following sections.
-
-
-Changing the version scheme
----------------------------
-
-One key change in the version scheme in this PEP relative to that in
-:pep:`386` is to sort top level developmental releases like ``X.Y.devN`` ahead
-of alpha releases like ``X.Ya1``. This is a far more logical sort order, as
-projects already using both development releases and alphas/betas/release
-candidates do not want their developmental releases sorted in
-between their release candidates and their final releases. There is no
-rationale for using ``dev`` releases in that position rather than
-merely creating additional release candidates.
-
-The updated sort order also means the sorting of ``dev`` versions is now
-consistent between the metadata standard and the pre-existing behaviour
-of ``pkg_resources`` (and hence the behaviour of current installation
-tools).
-
-Making this change should make it easier for affected existing projects to
-migrate to the latest version of the metadata standard.
-
-Another change to the version scheme is to allow single number
-versions, similar to those used by non-Python projects like Mozilla
-Firefox, Google Chrome and the Fedora Linux distribution. This is actually
-expected to be more useful for version specifiers, but it is easier to
-allow it for both version specifiers and release numbers, rather than
-splitting the two definitions.
-
-The exclusion of leading and trailing whitespace was made explicit after
-a couple of projects with version identifiers differing only in a
-trailing ``\n`` character were found on PyPI.
-
-Various other normalisation rules were also added as described in the
-separate section on version normalisation below.
-
-``Appendix A`` shows detailed results of an analysis of PyPI distribution
-version information, as collected on 8th August, 2014. This analysis
-compares the behavior of the explicitly ordered version scheme defined in
-this PEP with the de facto standard defined by the behavior of setuptools.
-These metrics are useful, as the intent of this PEP is to follow existing
-setuptools behavior as closely as is feasible, while still throwing
-exceptions for unorderable versions (rather than trying to guess an
-appropriate order as setuptools does).
-
-
-A more opinionated description of the versioning scheme
--------------------------------------------------------
-
-As in :pep:`386`, the primary focus is on codifying existing practices to make
-them more amenable to automation, rather than demanding that existing
-projects make non-trivial changes to their workflow. However, the
-standard scheme allows significantly more flexibility than is needed
-for the vast majority of simple Python packages (which often don't even
-need maintenance releases - many users are happy with needing to upgrade to a
-new feature release to get bug fixes).
-
-For the benefit of novice developers, and for experienced developers
-wishing to better understand the various use cases, the specification
-now goes into much greater detail on the components of the defined
-version scheme, including examples of how each component may be used
-in practice.
-
-The PEP also explicitly guides developers in the direction of
-semantic versioning (without requiring it), and discourages the use of
-several aspects of the full versioning scheme that have largely been
-included in order to cover esoteric corner cases in the practices of
-existing projects and in repackaging software for Linux distributions.
-
-
-Describing version specifiers alongside the versioning scheme
--------------------------------------------------------------
-
-The main reason to even have a standardised version scheme in the first place
-is to make it easier to do reliable automated dependency analysis. It makes
-more sense to describe the primary use case for version identifiers alongside
-their definition.
-
-
-Changing the interpretation of version specifiers
--------------------------------------------------
 
-The previous interpretation of version specifiers made it very easy to
-accidentally download a pre-release version of a dependency. This in
-turn made it difficult for developers to publish pre-release versions
-of software to the Python Package Index, as even marking the package as
-hidden wasn't enough to keep automated tools from downloading it, and also
-made it harder for users to obtain the test release manually through the
-main PyPI web interface.
+.. _version-specifiers-regex:
 
-The previous interpretation also excluded post-releases from some version
-specifiers for no adequately justified reason.
+Appendix: Parsing version strings with regular expressions
+==========================================================
 
-The updated interpretation is intended to make it difficult to accidentally
-accept a pre-release version as satisfying a dependency, while still
-allowing pre-release versions to be retrieved automatically when that's the
-only way to satisfy a dependency.
-
-The "some forward compatibility assumed" version constraint is derived from the
-Ruby community's "pessimistic version constraint" operator [2]_ to allow
-projects to take a cautious approach to forward compatibility promises, while
-still easily setting a minimum required version for their dependencies. The
-spelling of the compatible release clause (``~=``) is inspired by the Ruby
-(``~>``) and PHP (``~``) equivalents.
-
-Further improvements are also planned to the handling of parallel
-installation of multiple versions of the same library, but these will
-depend on updates to the installation database definition along with
-improved tools for dynamic path manipulation.
-
-The trailing wildcard syntax to request prefix based version matching was
-added to make it possible to sensibly define compatible release clauses.
-
-
-Support for date based version identifiers
-------------------------------------------
-
-Excluding date based versions caused significant problems in migrating
-``pytz`` to the new metadata standards. It also caused concerns for the
-OpenStack developers, as they use a date based versioning scheme and would
-like to be able to migrate to the new metadata standards without changing
-it.
-
-
-Adding version epochs
----------------------
-
-Version epochs are added for the same reason they are part of other
-versioning schemes, such as those of the Fedora and Debian Linux
-distributions: to allow projects to gracefully change their approach to
-numbering releases, without having a new release appear to have a lower
-version number than previous releases and without having to change the name
-of the project.
-
-In particular, supporting version epochs allows a project that was previously
-using date based versioning to switch to semantic versioning by specifying
-a new version epoch.
-
-The ``!`` character was chosen to delimit an epoch version rather than the
-``:`` character, which is commonly used in other systems, due to the fact that
-``:`` is not a valid character in a Windows directory name.
-
-
-Adding direct references
-------------------------
-
-Direct references are added as an "escape clause" to handle messy real
-world situations that don't map neatly to the standard distribution model.
-This includes dependencies on unpublished software for internal use, as well
-as handling the more complex compatibility issues that may arise when
-wrapping third party libraries as C extensions (this is of especial concern
-to the scientific community).
-
-Index servers are deliberately given a lot of freedom to disallow direct
-references, since they're intended primarily as a tool for integrators
-rather than publishers. PyPI in particular is currently going through the
-process of *eliminating* dependencies on external references, as unreliable
-external services have the effect of slowing down installation operations,
-as well as reducing PyPI's own apparent reliability.
-
-
-Adding arbitrary equality
--------------------------
-
-Arbitrary equality is added as an "escape clause" to handle the case where
-someone needs to install a project which uses a non compliant version. Although
-this PEP is able to attain ~97% compatibility with the versions that are
-already on PyPI there are still ~3% of versions which cannot be parsed. This
-operator gives a simple and effective way to still depend on them without
-having to "guess" at the semantics of what they mean (which would be required
-if anything other than strict string based equality was supported).
-
-
-Adding local version identifiers
---------------------------------
-
-It's a fact of life that downstream integrators often need to backport
-upstream bug fixes to older versions. It's one of the services that gets
-Linux distro vendors paid, and application developers may also apply patches
-they need to bundled dependencies.
-
-Historically, this practice has been invisible to cross-platform language
-specific distribution tools - the reported "version" in the upstream
-metadata is the same as for the unmodified code. This inaccuracy can then
-cause problems when attempting to work with a mixture of integrator
-provided code and unmodified upstream code, or even just attempting to
-identify exactly which version of the software is installed.
-
-The introduction of local version identifiers and "local version labels"
-into the versioning scheme, with the corresponding ``python.integrator``
-metadata extension allows this kind of activity to be represented
-accurately, which should improve interoperability between the upstream
-tools and various integrated platforms.
-
-The exact scheme chosen is largely modeled on the existing behavior of
-``pkg_resources.parse_version`` and ``pkg_resources.parse_requirements``,
-with the main distinction being that where ``pkg_resources`` currently always
-takes the suffix into account when comparing versions for exact matches,
-the PEP requires that the local version label of the candidate version be
-ignored when no local version label is present in the version specifier
-clause. Furthermore, the PEP does not attempt to impose any structure on
-the local version labels (aside from limiting the set of permitted
-characters and defining their ordering).
-
-This change is designed to ensure that an integrator provided version like
-``pip 1.5+1`` or ``pip 1.5+1.git.abc123de`` will still satisfy a version
-specifier like ``pip>=1.5``.
-
-The plus is chosen primarily for readability of local version identifiers.
-It was chosen instead of the hyphen to prevent
-``pkg_resources.parse_version`` from parsing it as a prerelease, which is
-important for enabling a successful migration to the new, more structured,
-versioning scheme. The plus was chosen instead of a tilde because of the
-significance of the tilde in Debian's version ordering algorithm.
-
-
-Providing explicit version normalization rules
-----------------------------------------------
-
-Historically, the de facto standard for parsing versions in Python has been the
-``pkg_resources.parse_version`` command from the setuptools project. This does
-not attempt to reject *any* version and instead tries to make something
-meaningful, with varying levels of success, out of whatever it is given. It has
-a few simple rules but otherwise it more or less relies largely on string
-comparison.
-
-The normalization rules provided in this PEP exist primarily to either increase
-the compatibility with ``pkg_resources.parse_version``, particularly in
-documented use cases such as ``rev``, ``r``, ``pre``, etc or to do something
-more reasonable with versions that already exist on PyPI.
-
-All possible normalization rules were weighed against whether or not they were
-*likely* to cause any ambiguity (e.g. while someone might devise a scheme where
-``v1.0`` and ``1.0`` are considered distinct releases, the likelihood of anyone
-actually doing that, much less on any scale that is noticeable, is fairly low).
-They were also weighed against how ``pkg_resources.parse_version`` treated a
-particular version string, especially with regards to how it was sorted. Finally
-each rule was weighed against the kinds of additional versions it allowed, how
-"ugly" those versions looked, how hard there were to parse (both mentally and
-mechanically) and how much additional compatibility it would bring.
-
-The breadth of possible normalizations were kept to things that could easily
-be implemented as part of the parsing of the version and not pre-parsing
-transformations applied to the versions. This was done to limit the side
-effects of each transformation as simple search and replace style transforms
-increase the likelihood of ambiguous or "junk" versions.
-
-For an extended discussion on the various types of normalizations that were
-considered, please see the proof of concept for :pep:`440` within pip [5]_.
-
-
-Allowing Underscore in Normalization
-------------------------------------
-
-There are not a lot of projects on PyPI which utilize a ``_`` in the version
-string. However this PEP allows its use anywhere that ``-`` is acceptable. The
-reason for this is that the Wheel normalization scheme specifies that ``-``
-gets normalized to a ``_`` to enable easier parsing of the filename.
-
-
-Summary of changes to PEP 440
-=============================
-
-The following changes were made to this PEP based on feedback received after
-the initial reference implementation was released in setuptools 8.0 and pip
-6.0:
-
-* The exclusive ordered comparisons were updated to no longer imply a ``!=V.*``
-  which was deemed to be surprising behavior which was too hard to accurately
-  describe. Instead the exclusive ordered comparisons will simply disallow
-  matching pre-releases, post-releases, and local versions of the specified
-  version (unless the specified version is itself a pre-release, post-release
-  or local version). For an extended discussion see the threads on
-  distutils-sig [6]_ [7]_.
-
-* The normalized form for release candidates was updated from 'c' to 'rc'.
-  This change was based on user feedback received when setuptools 8.0
-  started applying normalisation to the release metadata generated when
-  preparing packages for publication on PyPI [8]_.
-
-* The PEP text and the ``is_canonical`` regex were updated to be explicit
-  that numeric components are specifically required to be represented as
-  sequences of ASCII digits, not arbitrary Unicode [Nd] code points. This
-  was previously implied by the version parsing regex in Appendix B, but
-  not stated explicitly [10]_.
-
-
-
-References
-==========
-
-The initial attempt at a standardised version scheme, along with the
-justifications for needing such a standard can be found in :pep:`386`.
-
-.. [2] `Version compatibility analysis script
-   `__
-
-.. [4] `File URIs in Windows
-   `__
-
-.. [5] `Proof of Concept: PEP 440 within pip
-    `__
-
-.. [6] `PEP440: foo-X.Y.Z does not satisfy "foo>X.Y"
-    `__
-
-.. [7] `PEP440: >1.7 vs >=1.7
-    `__
-
-.. [8] `Amend PEP 440 with Wider Feedback on Release Candidates
-   `__
-
-.. [10] `PEP 440: regex should not permit Unicode [Nd] characters
-   `__
-
-* `Reference Implementation of PEP 440 Versions and Specifiers
-  `__
-
-* `Pessimistic version constraint
-  `__
-
-* `Changing the status of PEP 440 to Provisional
-  `__
-
-Appendix A
-==========
-
-Metadata v2.0 guidelines versus setuptools::
-
-    $ invoke check.pep440
-    Total Version Compatibility:              245806/250521 (98.12%)
-    Total Sorting Compatibility (Unfiltered): 45441/47114 (96.45%)
-    Total Sorting Compatibility (Filtered):   47057/47114 (99.88%)
-    Projects with No Compatible Versions:     498/47114 (1.06%)
-    Projects with Differing Latest Version:   688/47114 (1.46%)
-
-Appendix B : Parsing version strings with regular expressions
-=============================================================
-
-As noted earlier in the ``Public version identifiers`` section, published
-version identifiers SHOULD use the canonical format. This section provides
-regular expressions that can be used to test whether a version is already
-in that form, and if it's not, extract the various components for subsequent
-normalization.
+As noted earlier in the :ref:`public-version-identifiers` section,
+published version identifiers SHOULD use the canonical format. This
+section provides regular expressions that can be used to test whether a
+version is already in that form, and if it's not, extract the various
+components for subsequent normalization.
 
 To test whether a version identifier is in the canonical format, you can use
 the following function::
@@ -1667,7 +1249,11 @@ project)::
     )
 
 
-Copyright
-=========
 
-This document has been placed in the public domain.
+History
+=======
+
+This specification was originally approved as :pep:`440`,
+addressing several limitations of the previous attempt
+at standardized versioning, as described in :pep:`345`
+and :pep:`386`.

From 085a016b75110b33c3ae6eaa685a516229b12878 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sat, 4 Nov 2023 12:30:53 +0100
Subject: [PATCH 0435/1072] PEP 440: Remove "Abstract" heading

---
 source/specifications/version-specifiers.rst | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/source/specifications/version-specifiers.rst b/source/specifications/version-specifiers.rst
index 52ef5aca5..1b2507eeb 100644
--- a/source/specifications/version-specifiers.rst
+++ b/source/specifications/version-specifiers.rst
@@ -5,9 +5,6 @@ Version specifiers
 ==================
 
 
-Abstract
-========
-
 This specification describes a scheme for identifying versions of Python software
 distributions, and declaring dependencies on particular versions.
 

From 367e5e8471b236d6a92da47054d08cea5fe8ab01 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sat, 4 Nov 2023 12:50:11 +0100
Subject: [PATCH 0436/1072] Update references to PEP 440

---
 source/glossary.rst                           |  9 +++----
 .../binary-distribution-format.rst            |  4 +--
 source/specifications/core-metadata.rst       | 12 +++++----
 .../declaring-project-metadata.rst            |  3 ++-
 .../specifications/dependency-specifiers.rst  | 27 ++++++++++---------
 .../direct-url-data-structure.rst             |  2 +-
 .../recording-installed-packages.rst          | 11 ++++----
 source/specifications/version-specifiers.rst  |  5 ++++
 source/tutorials/installing-packages.rst      |  8 +++---
 9 files changed, 45 insertions(+), 36 deletions(-)

diff --git a/source/glossary.rst b/source/glossary.rst
index 707bc4756..70ad4ccda 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -222,11 +222,10 @@ Glossary
     Version Specifier
 
        The version component of a :term:`Requirement Specifier`. For example,
-       the ">=1.3" portion of "foo>=1.3".  :pep:`440` contains
-       a :pep:`full specification
-       <440#version-specifiers>` of the
-       specifiers that Python packaging currently supports.  Support for PEP440
-       was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0.
+       the ">=1.3" portion of "foo>=1.3".  Read the :ref:`Version specifier specification
+       ` for a full description of the
+       specifiers that Python packaging currently supports.  Support for this
+       specification was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0.
 
     Virtual Environment
 
diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst
index 9855ad8ff..04367cc85 100644
--- a/source/specifications/binary-distribution-format.rst
+++ b/source/specifications/binary-distribution-format.rst
@@ -182,8 +182,8 @@ this character cannot appear within any component. This is handled as follows:
   Tools consuming wheels must be prepared to accept ``.`` (FULL STOP) and
   uppercase letters, however, as these were allowed by an earlier version of
   this specification.
-- Version numbers should be normalised according to :pep:`440`. Normalised
-  version numbers cannot contain ``-``.
+- Version numbers should be normalised according to the :ref:`Version specifier
+  specification `. Normalised version numbers cannot contain ``-``.
 - The remaining components may not contain ``-`` characters, so no escaping
   is necessary.
 
diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index cefd68950..2c2cf96cb 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -53,8 +53,9 @@ Version of the file format; legal values are "1.0", "1.1", "1.2", "2.1",
 Automated tools consuming metadata SHOULD warn if ``metadata_version`` is
 greater than the highest version they support, and MUST fail if
 ``metadata_version`` has a greater major version than the highest
-version they support (as described in :pep:`440`, the major version is the
-value before the first dot).
+version they support (as described in the
+:ref:`Version specifier specification `,
+the major version is the value before the first dot).
 
 For broader compatibility, build tools MAY choose to produce
 distribution metadata using the lowest metadata version that includes
@@ -96,7 +97,8 @@ Version
 .. versionadded:: 1.0
 
 A string containing the distribution's version number.  This
-field  must be in the format specified in :pep:`440`.
+field  must be in the format specified in the
+:ref:`Version specifier specification `.
 
 Example::
 
@@ -587,8 +589,8 @@ This field may be followed by an environment marker after a semicolon.
 
 Because they refer to non-Python software releases, version numbers
 for this field are **not** required to conform to the format
-specified in :pep:`440`:  they should correspond to the
-version scheme used by the external dependency.
+specified in the :ref:`Version specifier specification `:
+they should correspond to the version scheme used by the external dependency.
 
 Notice that there is no particular rule on the strings to be used.
 
diff --git a/source/specifications/declaring-project-metadata.rst b/source/specifications/declaring-project-metadata.rst
index 4f1d4199d..1c4ce7ce2 100644
--- a/source/specifications/declaring-project-metadata.rst
+++ b/source/specifications/declaring-project-metadata.rst
@@ -87,7 +87,8 @@ as it is read for internal consistency.
 - Corresponding :ref:`core metadata ` field:
   :ref:`Version `
 
-The version of the project as supported by :pep:`440`.
+The version of the project, as defined in the
+:ref:`Version specifier specification `.
 
 Users SHOULD prefer to specify already-normalized versions.
 
diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst
index 009b8a592..0389ce3cb 100644
--- a/source/specifications/dependency-specifiers.rst
+++ b/source/specifications/dependency-specifiers.rst
@@ -16,8 +16,8 @@ acceptable, so the language permits describing all these cases.
 The language defined is a compact line based format which is already in
 widespread use in pip requirements files, though we do not specify the command
 line option handling that those files permit. There is one caveat - the
-URL reference form, specified in :pep:`440` is not actually
-implemented in pip, but since :pep:`440` is accepted, we use that format rather
+URL reference form, specified in :ref:`Versioning specifier specification `
+is not actually implemented in pip, but we use that format rather
 than pip's current native format.
 
 Specification
@@ -57,7 +57,8 @@ as comments, multiple line support via continuations, or other such features.
 The full grammar including annotations to build a useful parse tree is
 included at the end of this document.
 
-Versions may be specified according to the :pep:`440` rules. (Note:
+Versions may be specified according to the rules of the
+:ref:`Version specifier specification `. (Note:
 URI is defined in :rfc:`std-66 <3986>`)::
 
     version_cmp   = wsp* '<' | '<=' | '!=' | '==' | '>=' | '>' | '~=' | '==='
@@ -159,12 +160,13 @@ If multiple extras are listed, all the dependencies are unioned together.
 Versions
 --------
 
-See :pep:`440` for more detail on both version numbers and version
-comparisons. Version specifications limit the versions of a distribution that
-can be used. They only apply to distributions looked up by name, rather than
+See the :ref:`Version specifier specification ` for
+more detail on both version numbers and version comparisons. Version
+specifications limit the versions of a distribution that can be
+used. They only apply to distributions looked up by name, rather than
 via a URL. Version comparison are also used in the markers feature. The
-optional brackets around a version are present for compatibility with :pep:`345`
-but should not be generated, only accepted.
+optional brackets around a version are present for compatibility with
+:pep:`345` but should not be generated, only accepted.
 
 Environment Markers
 -------------------
@@ -186,10 +188,11 @@ fixes some issues that were observed in the design described in :pep:`426`.
 
 Comparisons in marker expressions are typed by the comparison operator.  The
  operators that are not in  perform the same as they
-do for strings in Python. The  operators use the :pep:`440`
-version comparison rules when those are defined (that is when both
-sides have a valid version specifier). If there is no defined :pep:`440`
-behaviour and the operator exists in Python, then the operator falls back to
+do for strings in Python. The  operators use the version comparison
+rules of the :ref:`Version specifier specification `
+when those are defined (that is when both sides have a valid
+version specifier). If there is no defined behaviour of this specification
+and the operator exists in Python, then the operator falls back to
 the Python behaviour. Otherwise an error should be raised. e.g. the following
 will result in  errors::
 
diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index eae9d3071..3983b8520 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -11,7 +11,7 @@ source trees, source distributions and wheels.
 
 The representation of the components of this data structure as a :rfc:`1738` URL
 is not formally specified at time of writing. A common representation is the pip URL
-format. Other examples are provided in :pep:`440`.
+format. Other examples are provided in the :ref:`Version specifier specification `.
 
 .. contents:: Contents
    :local:
diff --git a/source/specifications/recording-installed-packages.rst b/source/specifications/recording-installed-packages.rst
index 11d2c3bfa..2610717d6 100644
--- a/source/specifications/recording-installed-packages.rst
+++ b/source/specifications/recording-installed-packages.rst
@@ -42,12 +42,11 @@ packages (commonly, the ``site-packages`` directory).
 
 This directory is named as ``{name}-{version}.dist-info``, with ``name`` and
 ``version`` fields corresponding to :ref:`core-metadata`. Both fields must be
-normalized (see :ref:`name-normalization` and
-:pep:`PEP 440 <440#normalization>` for the definition of normalization for
-each field respectively), and replace dash (``-``) characters with
-underscore (``_``) characters, so the ``.dist-info`` directory always has
-exactly one dash (``-``) character in its stem, separating the ``name`` and
-``version`` fields.
+normalized (see the :ref:`name normalization specification `
+and the :ref:`version normalization specification `),
+and replace dash (``-``) characters with underscore (``_``) characters,
+so the ``.dist-info`` directory always has exactly one dash (``-``) character in
+its stem, separating the ``name`` and ``version`` fields.
 
 Historically, tools have failed to replace dot characters or normalize case in
 the ``name`` field, or not perform normalization in the ``version`` field.
diff --git a/source/specifications/version-specifiers.rst b/source/specifications/version-specifiers.rst
index 1b2507eeb..0d8b22334 100644
--- a/source/specifications/version-specifiers.rst
+++ b/source/specifications/version-specifiers.rst
@@ -385,6 +385,9 @@ from an earlier epoch::
     1!1.1
     1!2.0
 
+
+.. _version-specifiers-normalization:
+
 Normalization
 -------------
 
@@ -805,6 +808,8 @@ entirely when checking if candidate versions match a given version
 specifier.
 
 
+.. _version-specifiers-compatible-release:
+
 Compatible release
 ------------------
 
diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst
index 5d4957519..233a7c41b 100644
--- a/source/tutorials/installing-packages.rst
+++ b/source/tutorials/installing-packages.rst
@@ -308,9 +308,9 @@ The most common usage of :ref:`pip` is to install from the :term:`Python Package
 Index ` using a :term:`requirement specifier
 `. Generally speaking, a requirement specifier is
 composed of a project name followed by an optional :term:`version specifier
-`.  :pep:`440` contains a :pep:`full
-specification <440#version-specifiers>`
-of the currently supported specifiers. Below are some examples.
+`.  A full description of the supported specifiers can be
+found in the :ref:`Version specifier specification `.
+Below are some examples.
 
 To install the latest version of "SomeProject":
 
@@ -355,7 +355,7 @@ To install greater than or equal to one version and less than another:
         py -m pip install "SomeProject>=1,<2"
 
 
-To install a version that's :pep:`"compatible" <440#compatible-release>`
+To install a version that's :ref:`compatible `
 with a certain version: [4]_
 
 .. tab:: Unix/macOS

From 64a7c8ed96d241e137a562e0ea927e8d87f2c2a2 Mon Sep 17 00:00:00 2001
From: sinoroc 
Date: Thu, 2 Nov 2023 12:02:40 +0100
Subject: [PATCH 0437/1072] Add build backend and frontend to the glossary

GitHub: fixes https://github.com/pypa/packaging.python.org/issues/1327
---
 source/flow.rst                               |  9 ++++--
 source/glossary.rst                           | 30 +++++++++++++++++++
 source/key_projects.rst                       |  2 +-
 .../declaring-project-metadata.rst            |  2 +-
 .../source-distribution-format.rst            |  3 +-
 source/tutorials/packaging-projects.rst       |  8 ++---
 6 files changed, 44 insertions(+), 10 deletions(-)

diff --git a/source/flow.rst b/source/flow.rst
index 8a7d390b8..974cfd6e9 100644
--- a/source/flow.rst
+++ b/source/flow.rst
@@ -82,9 +82,12 @@ For example, here is a table for using :ref:`hatch`:
     requires = ["hatchling"]
     build-backend = "hatchling.build"
 
-With such a table in the :file:`pyproject.toml` file, a "frontend" tool like
-:ref:`build` can run your chosen build tool's "backend" to create the build
-artifacts. Your build tool may also provide its own frontend. An install tool
+With such a table in the :file:`pyproject.toml` file,
+a ":term:`frontend `" tool like
+:ref:`build` can run your chosen
+build tool's ":term:`backend `"
+to create the build artifacts.
+Your build tool may also provide its own frontend. An install tool
 like :ref:`pip` also acts as a frontend when it runs your build tool's backend
 to install from a source distribution.
 
diff --git a/source/glossary.rst b/source/glossary.rst
index 707bc4756..5b1ca8951 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -12,6 +12,36 @@ Glossary
         extensions.
 
 
+    Build Backend
+
+        A library that takes a source tree or
+        :term:`source distribution `
+        and builds a source distribution or :term:`wheel ` from it.
+        The build is delegated to the backend by a
+        :term:`frontend `.
+        All backends offer a standardized interface.
+
+        Examples of build backends are
+        :ref:`flit's flit-core `,
+        :ref:`hatch's hatchling `,
+        :ref:`maturin`,
+        :ref:`meson-python`,
+        :ref:`scikit-build-core`,
+        and :ref:`setuptools`.
+
+
+    Build Frontend
+
+        A tool that users might run
+        that takes arbitrary source trees or
+        :term:`source distributions `
+        and builds source distributions or :term:`wheels ` from them.
+        The actual building is delegated to each source tree's
+        :term:`build backend `.
+
+        Examples of build frontends are :ref:`pip` and :ref:`build`.
+
+
     Built Distribution
 
         A :term:`Distribution ` format containing files
diff --git a/source/key_projects.rst b/source/key_projects.rst
index b81dccd2f..dfb46b9a5 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -140,7 +140,7 @@ hatch
 
 Hatch is a unified command-line tool meant to conveniently manage
 dependencies and environment isolation for Python developers. Python
-package developers use Hatch and its build backend Hatchling to
+package developers use Hatch and its :term:`build backend ` Hatchling to
 configure, version, specify dependencies for, and publish packages
 to PyPI. Its plugin system allows for easily extending functionality.
 
diff --git a/source/specifications/declaring-project-metadata.rst b/source/specifications/declaring-project-metadata.rst
index 4f1d4199d..119635087 100644
--- a/source/specifications/declaring-project-metadata.rst
+++ b/source/specifications/declaring-project-metadata.rst
@@ -27,7 +27,7 @@ table which are not defined by this specification. For tools wishing
 to store their own settings in ``pyproject.toml``, they may use the
 ``[tool]`` table as defined in the
 :ref:`build dependency declaration specification `.
-The lack of a ``[project]`` table implicitly means the build back-end
+The lack of a ``[project]`` table implicitly means the :term:`build backend `
 will dynamically provide all keys.
 
 The only keys required to be statically defined are:
diff --git a/source/specifications/source-distribution-format.rst b/source/specifications/source-distribution-format.rst
index 93531430f..8ef55df96 100644
--- a/source/specifications/source-distribution-format.rst
+++ b/source/specifications/source-distribution-format.rst
@@ -43,7 +43,8 @@ The name and version components of the filename MUST match the values stored
 in the metadata contained in the file.
 
 Code that produces a source distribution file MUST give the file a name that matches
-this specification. This includes the ``build_sdist`` hook of a build backend.
+this specification. This includes the ``build_sdist`` hook of a
+:term:`build backend `.
 
 Code that processes source distribution files MAY recognise source distribution files
 by the ``.tar.gz`` suffix and the presence of precisely *one* hyphen in the filename.
diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst
index 0b6b60d81..8901a2281 100644
--- a/source/tutorials/packaging-projects.rst
+++ b/source/tutorials/packaging-projects.rst
@@ -107,8 +107,8 @@ Choosing a build backend
 ------------------------
 
 Tools like :ref:`pip` and :ref:`build` do not actually convert your sources
-into a :term:`distribution package ` (like a wheel); 
-that job is performed by a *build backend*. The build backend determines how
+into a :term:`distribution package ` (like a wheel);
+that job is performed by a :term:`build backend `. The build backend determines how
 your project will specify its configuration, including metadata (information
 about the project, for example, the name and tags that are displayed on PyPI)
 and input files. Build backends have different levels of functionality, such as
@@ -127,7 +127,7 @@ table for :ref:`metadata `.
    management, as well as building, uploading, and installing packages. This
    tutorial uses single-purpose tools that work independently.
 
-The :file:`pyproject.toml` tells "front end" build tools like :ref:`pip` and
+The :file:`pyproject.toml` tells :term:`build frontend ` tools like :ref:`pip` and
 :ref:`build` which backend to use for your project. Below are some
 examples for common build backends, but check your backend's own documentation
 for more details.
@@ -166,7 +166,7 @@ for more details.
 
 
 The ``requires`` key is a list of packages that are needed to build your package.
-The frontend should install them automatically when building your package.
+The :term:`frontend ` should install them automatically when building your package.
 Frontends usually run builds in isolated environments, so omitting dependencies
 here may cause build-time errors.
 This should always include your backend's package, and might have other build-time

From 9e0b14b4605a869f2bd985786ea267fb14d4a444 Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Sat, 4 Nov 2023 07:49:24 -0700
Subject: [PATCH 0438/1072] Apply @sinoroc review suggestions

---
 .../installing-using-pip-and-virtual-environments.rst       | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst
index af2a1cad5..c475ca299 100644
--- a/source/guides/installing-using-pip-and-virtual-environments.rst
+++ b/source/guides/installing-using-pip-and-virtual-environments.rst
@@ -2,7 +2,7 @@ Installing packages using pip and venv
 ======================================
 
 This guide discusses how to install packages using :ref:`pip` and
-the standard library's virtual environment manager :ref:`venv`. The guide
+the standard library's virtual environment :ref:`venv`. The guide
 covers how to:
 
 * Install and update pip
@@ -83,8 +83,8 @@ since packages can be installed confidently and will not interfere with the
 other project environments.
 
 .. tip::
-   It is always recommended to use a virtual environment while developing Python
-   applications.
+   It is recommended to use a virtual environment when working with third
+   party packages.
 
 To create a virtual environment, go to your project's directory and run
 ``venv``.

From 0671716efede7103c3f80e10b642dc4fe036dd40 Mon Sep 17 00:00:00 2001
From: sinoroc 
Date: Sat, 4 Nov 2023 20:28:31 +0100
Subject: [PATCH 0439/1072] Clarify sentence about empty __init__.py

GitHub: fixes https://github.com/pypa/packaging.python.org/issues/1292
---
 source/tutorials/packaging-projects.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst
index 0b6b60d81..5da846c9c 100644
--- a/source/tutorials/packaging-projects.rst
+++ b/source/tutorials/packaging-projects.rst
@@ -54,8 +54,8 @@ Create the following file structure locally:
 The directory containing the Python files should match the project name. This
 simplifies the configuration and is more obvious to users who install the package.
 
-:file:`__init__.py` is required to import the directory as a package, and
-should be empty.
+:file:`__init__.py` is required to import the directory as a package,
+even if as is our case for this tutorial that file is empty.
 
 :file:`example.py` is an example of a module within the package that could
 contain the logic (functions, classes, constants, etc.) of your package.
@@ -107,7 +107,7 @@ Choosing a build backend
 ------------------------
 
 Tools like :ref:`pip` and :ref:`build` do not actually convert your sources
-into a :term:`distribution package ` (like a wheel); 
+into a :term:`distribution package ` (like a wheel);
 that job is performed by a *build backend*. The build backend determines how
 your project will specify its configuration, including metadata (information
 about the project, for example, the name and tags that are displayed on PyPI)

From d6fd58451784f6e1c773420e60f4d3841a065e45 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sat, 4 Nov 2023 21:16:44 +0100
Subject: [PATCH 0440/1072] Use correct reST syntax for emphasis

xref: https://github.com/sphinx-contrib/sphinx-lint/issues/98
---
 source/specifications/name-normalization.rst | 2 +-
 source/tutorials/installing-packages.rst     | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/specifications/name-normalization.rst b/source/specifications/name-normalization.rst
index 4756d1631..64be4a1d1 100644
--- a/source/specifications/name-normalization.rst
+++ b/source/specifications/name-normalization.rst
@@ -36,7 +36,7 @@ This means that the following names are all equivalent:
 * ``friendly.bard``
 * ``friendly_bard``
 * ``friendly--bard``
-* ``FrIeNdLy-._.-bArD`` (a _terrible_ way to write a name, but it is valid)
+* ``FrIeNdLy-._.-bArD`` (a *terrible* way to write a name, but it is valid)
 
 History
 =======
diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst
index 5d4957519..46957f93b 100644
--- a/source/tutorials/installing-packages.rst
+++ b/source/tutorials/installing-packages.rst
@@ -277,7 +277,7 @@ that the virtual environment's variables are set within the current
 shell, and not in a subprocess (which then disappears, having no
 useful effect).
 
-In both of the above cases, Windows users should _not_ use the
+In both of the above cases, Windows users should *not* use the
 :command:`source` command, but should rather run the :command:`activate`
 script directly from the command shell like so:
 

From aff0be6437f8455d712610eee311c1e3701ab147 Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Sat, 4 Nov 2023 13:58:48 -0700
Subject: [PATCH 0441/1072] Apply @Kwpolska suggestion to scope to using pip in
 a virtual environment

---
 ...ing-using-pip-and-virtual-environments.rst | 133 +++++++++++-------
 1 file changed, 79 insertions(+), 54 deletions(-)

diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst
index c475ca299..a5d6533c3 100644
--- a/source/guides/installing-using-pip-and-virtual-environments.rst
+++ b/source/guides/installing-using-pip-and-virtual-environments.rst
@@ -1,12 +1,12 @@
-Installing packages using pip and venv
-======================================
+Install packages in a virtual environment using pip and venv
+============================================================
 
-This guide discusses how to install packages using :ref:`pip` and
-the standard library's virtual environment :ref:`venv`. The guide
-covers how to:
+This guide discusses how to create and activate a virtual environment using
+the standard library's virtual environment :ref:`venv` and install packages.
+The guide covers how to:
 
-* Install and update pip
-* Create and use a virtual environment
+* Create and activate a virtual environment
+* Prepare pip
 * Install packages into a virtual environment using the ``pip`` command
 * Use and create a requirements file
 
@@ -21,52 +21,11 @@ covers how to:
     import modules in your Python source code.
 
 
-Install and update pip
-----------------------
-
-:ref:`pip` is the reference Python package manager.
-It's used to install and update packages.
-Make sure you have the latest version of pip installed.
-
-
-.. tab:: Unix/macOS
-
-    Debian and most other distributions include a `python-pip`_ package; if you
-    want to use the Linux distribution-provided versions of pip, see
-    :doc:`/guides/installing-using-linux-tools`.
-
-    You can also install pip yourself to ensure you have the latest version. It's
-    recommended to use the system pip to bootstrap a user installation of pip:
-
-    .. code-block:: bash
-
-        python3 -m pip install --user --upgrade pip
-        python3 -m pip --version
-
-    Afterwards, you should have the latest version of pip installed in your
-    user site:
-
-    .. code-block:: text
-
-        pip 21.1.3 from $HOME/.local/lib/python3.9/site-packages (python 3.9)
-
-    .. _python-pip: https://packages.debian.org/stable/python/python3-pip
-
-.. tab:: Windows
-
-    The Python installers for Windows include pip. You can make sure that pip is
-    up-to-date by running:
-
-    .. code-block:: bat
-
-        py -m pip install --upgrade pip
-        py -m pip --version
-
-    Afterwards, you should have the latest version of pip:
-
-    .. code-block:: text
-
-        pip 21.1.3 from c:\python39\lib\site-packages (Python 3.9.4)
+.. important::
+    This guide has the prerequisite that an official Python version from
+    . If you are using your operating
+    system's package manager to install Python, please ensure that Python is
+    installed before proceeding with these steps.
 
 
 Create and Use Virtual Environments
@@ -80,7 +39,7 @@ different projects. It creates a "virtual" isolated Python installation. When
 you switch projects, you can create a new virtual environment which is isolated
 from other virtual environments. You benefit from the virtual environment
 since packages can be installed confidently and will not interfere with the
-other project environments.
+another project's environment.
 
 .. tip::
    It is recommended to use a virtual environment when working with third
@@ -185,6 +144,72 @@ instructions about activating a virtual environment. There's no need to create
 a new virtual environment.
 
 
+Prepare pip
+-----------
+
+:ref:`pip` is the reference Python package manager.
+It's used to install and update packages into a virtual environment.
+
+
+.. tab:: Unix
+
+    Debian and most other distributions include a `python-pip`_ package; if you
+    want to use the Linux distribution-provided versions of pip, see
+    :doc:`/guides/installing-using-linux-tools`.
+
+    You can also install pip yourself to ensure you have the latest version. It's
+    recommended to use the system pip to bootstrap a user installation of pip:
+
+    .. code-block:: bash
+
+        python3 -m pip install --user --upgrade pip
+        python3 -m pip --version
+
+    Afterwards, you should have the latest version of pip installed in your
+    user site:
+
+    .. code-block:: text
+
+        pip 21.1.3 from $HOME/.local/lib/python3.9/site-packages (python 3.9)
+
+    .. _python-pip: https://packages.debian.org/stable/python/python3-pip
+
+.. tab:: macOS
+
+    The Python installers for macOS include pip. You can make sure that pip is
+    up-to-date by running:
+
+    .. code-block:: bash
+
+        python3 -m pip install --upgrade pip
+        python3 -m pip --version
+
+    Afterwards, you should have the latest version of pip installed in your
+    user site:
+
+    .. code-block:: text
+
+        pip 21.1.3 from $HOME/.local/lib/python3.9/site-packages (python 3.9)
+
+    .. _python-pip: https://packages.debian.org/stable/python/python3-pip
+
+.. tab:: Windows
+
+    The Python installers for Windows include pip. You can make sure that pip is
+    up-to-date by running:
+
+    .. code-block:: bat
+
+        py -m pip install --upgrade pip
+        py -m pip --version
+
+    Afterwards, you should have the latest version of pip:
+
+    .. code-block:: text
+
+        pip 21.1.3 from c:\python39\lib\site-packages (Python 3.9.4)
+
+
 Install packages using pip
 --------------------------
 

From eba4e49b088e9dae8fddc25cbd3b8ae2c3cc2e9d Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Sat, 4 Nov 2023 14:01:31 -0700
Subject: [PATCH 0442/1072] add missing sentence fragment

---
 source/guides/installing-using-pip-and-virtual-environments.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst
index a5d6533c3..bd43a919b 100644
--- a/source/guides/installing-using-pip-and-virtual-environments.rst
+++ b/source/guides/installing-using-pip-and-virtual-environments.rst
@@ -23,7 +23,7 @@ The guide covers how to:
 
 .. important::
     This guide has the prerequisite that an official Python version from
-    . If you are using your operating
+     is installed. If you are using your operating
     system's package manager to install Python, please ensure that Python is
     installed before proceeding with these steps.
 

From 660d634149c6c1b07eedfd1286c4fea4138e080f Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Sat, 4 Nov 2023 16:14:10 -0700
Subject: [PATCH 0443/1072] Update
 source/guides/installing-using-pip-and-virtual-environments.rst

Co-authored-by: sinoroc <5529267+sinoroc@users.noreply.github.com>
---
 source/guides/installing-using-pip-and-virtual-environments.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst
index bd43a919b..9601a47c4 100644
--- a/source/guides/installing-using-pip-and-virtual-environments.rst
+++ b/source/guides/installing-using-pip-and-virtual-environments.rst
@@ -2,7 +2,7 @@ Install packages in a virtual environment using pip and venv
 ============================================================
 
 This guide discusses how to create and activate a virtual environment using
-the standard library's virtual environment :ref:`venv` and install packages.
+the standard library's virtual environment tool :ref:`venv` and install packages.
 The guide covers how to:
 
 * Create and activate a virtual environment

From 6e705b64b5a344a0185adab6be70955416369c6d Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Sat, 4 Nov 2023 16:14:31 -0700
Subject: [PATCH 0444/1072] Update
 source/guides/installing-using-pip-and-virtual-environments.rst

Co-authored-by: sinoroc <5529267+sinoroc@users.noreply.github.com>
---
 source/guides/installing-using-pip-and-virtual-environments.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst
index 9601a47c4..28c562373 100644
--- a/source/guides/installing-using-pip-and-virtual-environments.rst
+++ b/source/guides/installing-using-pip-and-virtual-environments.rst
@@ -22,7 +22,7 @@ The guide covers how to:
 
 
 .. important::
-    This guide has the prerequisite that an official Python version from
+    This guide has the prerequisite that you are using an official Python version obtained from
      is installed. If you are using your operating
     system's package manager to install Python, please ensure that Python is
     installed before proceeding with these steps.

From bb47ed25456d01e886d2c8be82333033347f27a9 Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Sat, 4 Nov 2023 17:09:24 -0700
Subject: [PATCH 0445/1072] remove debian specific content and add mention
 closing shell deactivates

---
 ...ing-using-pip-and-virtual-environments.rst | 31 ++++++++-----------
 1 file changed, 13 insertions(+), 18 deletions(-)

diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst
index 28c562373..893db6ce1 100644
--- a/source/guides/installing-using-pip-and-virtual-environments.rst
+++ b/source/guides/installing-using-pip-and-virtual-environments.rst
@@ -23,7 +23,7 @@ The guide covers how to:
 
 .. important::
     This guide has the prerequisite that you are using an official Python version obtained from
-     is installed. If you are using your operating
+    . If you are using your operating
     system's package manager to install Python, please ensure that Python is
     installed before proceeding with these steps.
 
@@ -46,7 +46,7 @@ another project's environment.
    party packages.
 
 To create a virtual environment, go to your project's directory and run
-``venv``.
+``venv``. This will create a new virtual environment in a local folder ``.venv``:
 
 .. tab:: Unix/macOS
 
@@ -87,7 +87,7 @@ shell's ``PATH``.
 
     .. code-block:: bat
 
-        .\.venv\Scripts\activate
+        .venv\bin\Activate.bat
 
 To confirm the virtual environment is activated, check the location of your
 Python interpreter:
@@ -117,7 +117,7 @@ the ``.venv`` directory:
 
     .. code-block:: bat
 
-        ...\.venv\Scripts\python.exe
+        ...\.venv\bin\python.exe
 
 
 While a virtual environment is activated, pip will install packages into that
@@ -135,6 +135,10 @@ If you want to switch projects or leave your virtual environment,
 
     deactivate
 
+.. note::
+    Closing your shell will deactivate the virtual environment. If
+    you open a new shell window and want to use the virtual environment,
+    reactivate it.
 
 Reactivate a virtual environment
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -153,16 +157,11 @@ It's used to install and update packages into a virtual environment.
 
 .. tab:: Unix
 
-    Debian and most other distributions include a `python-pip`_ package; if you
-    want to use the Linux distribution-provided versions of pip, see
-    :doc:`/guides/installing-using-linux-tools`.
-
-    You can also install pip yourself to ensure you have the latest version. It's
-    recommended to use the system pip to bootstrap a user installation of pip:
+    You can make sure that pip is up-to-date by running:
 
     .. code-block:: bash
 
-        python3 -m pip install --user --upgrade pip
+        python3 -m pip install --upgrade pip
         python3 -m pip --version
 
     Afterwards, you should have the latest version of pip installed in your
@@ -170,9 +169,7 @@ It's used to install and update packages into a virtual environment.
 
     .. code-block:: text
 
-        pip 21.1.3 from $HOME/.local/lib/python3.9/site-packages (python 3.9)
-
-    .. _python-pip: https://packages.debian.org/stable/python/python3-pip
+        pip 21.1.3 from ../.venv/lib/python3.9/site-packages (python 3.9)
 
 .. tab:: macOS
 
@@ -189,9 +186,7 @@ It's used to install and update packages into a virtual environment.
 
     .. code-block:: text
 
-        pip 21.1.3 from $HOME/.local/lib/python3.9/site-packages (python 3.9)
-
-    .. _python-pip: https://packages.debian.org/stable/python/python3-pip
+        pip 23.3.1 from $HOME/.venv/lib/python3.9/site-packages (python 3.9)
 
 .. tab:: Windows
 
@@ -207,7 +202,7 @@ It's used to install and update packages into a virtual environment.
 
     .. code-block:: text
 
-        pip 21.1.3 from c:\python39\lib\site-packages (Python 3.9.4)
+        pip 23.3.1 from .venv\lib\site-packages (Python 3.9.4)
 
 
 Install packages using pip

From e05aad7762e416cad1d66c82eddfeebe946f906b Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Sat, 4 Nov 2023 17:14:36 -0700
Subject: [PATCH 0446/1072] make output consistent

---
 .../guides/installing-using-pip-and-virtual-environments.rst  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst
index 893db6ce1..07ef2d26a 100644
--- a/source/guides/installing-using-pip-and-virtual-environments.rst
+++ b/source/guides/installing-using-pip-and-virtual-environments.rst
@@ -169,7 +169,7 @@ It's used to install and update packages into a virtual environment.
 
     .. code-block:: text
 
-        pip 21.1.3 from ../.venv/lib/python3.9/site-packages (python 3.9)
+        pip 23.3.1 from .../.venv/lib/python3.9/site-packages (python 3.9)
 
 .. tab:: macOS
 
@@ -186,7 +186,7 @@ It's used to install and update packages into a virtual environment.
 
     .. code-block:: text
 
-        pip 23.3.1 from $HOME/.venv/lib/python3.9/site-packages (python 3.9)
+        pip 23.3.1 from .../.venv/lib/python3.9/site-packages (python 3.9)
 
 .. tab:: Windows
 

From 18ddb70dbf81da59494192ce46781ebf34fe0d4b Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Sat, 4 Nov 2023 17:23:08 -0700
Subject: [PATCH 0447/1072] remove the creating documentation tutorial

---
 source/tutorials/creating-documentation.rst | 66 ---------------------
 source/tutorials/index.rst                  |  1 -
 2 files changed, 67 deletions(-)
 delete mode 100644 source/tutorials/creating-documentation.rst

diff --git a/source/tutorials/creating-documentation.rst b/source/tutorials/creating-documentation.rst
deleted file mode 100644
index 483fb0d72..000000000
--- a/source/tutorials/creating-documentation.rst
+++ /dev/null
@@ -1,66 +0,0 @@
-.. _creating-documentation:
-
-======================
-Creating Documentation
-======================
-
-This section covers the basics of how to create documentation using `Sphinx`_ and
-host the documentation for free in `Read The Docs`_.
-
-.. _Sphinx: https://www.sphinx-doc.org
-.. _Read The Docs: https://readthedocs.org/
-
-Installing Sphinx
------------------
-Use ``pip`` to install Sphinx:
-
-.. tab:: Unix/macOS
-
-    .. code-block:: bash
-
-        python3 -m pip install --upgrade sphinx
-
-.. tab:: Windows
-
-    .. code-block:: bat
-
-        py -m pip install --upgrade sphinx
-
-For other installation methods, see this :doc:`installation guide ` by Sphinx.
-
-
-Getting Started With Sphinx
----------------------------
-
-Create a ``docs`` directory inside your project to hold your documentation:
-
-.. code-block:: bash
-
-	cd /path/to/project
-	mkdir docs
-
-Run ``sphinx-quickstart`` inside the ``docs`` directory:
-
-.. code-block:: bash
-
-	cd docs
-	sphinx-quickstart
-
-This sets up a source directory, walks you through some basic configurations, and creates an ``index.rst`` file as well as a ``conf.py`` file.
-
-You can add some information about your project in ``index.rst``, then build them:
-
-.. code-block:: bash
-
-	make html
-
-For more details on the build process, see this `guide`_ by Read The Docs.
-
-.. _guide: https://docs.readthedocs.io/en/latest/intro/import-guide.html
-
-Other Sources
--------------
-
-For a more detailed guide on how to use Sphinx and reStructuredText, please see this `documentation tutorial`_ on Hitchhiker's Guide to Python.
-
-.. _documentation tutorial: https://docs.python-guide.org/writing/documentation/
diff --git a/source/tutorials/index.rst b/source/tutorials/index.rst
index 40b0620f3..33ab4f98a 100644
--- a/source/tutorials/index.rst
+++ b/source/tutorials/index.rst
@@ -11,4 +11,3 @@ topics, see :doc:`/guides/index`.
     installing-packages
     managing-dependencies
     packaging-projects
-    creating-documentation

From 264ccc6b59a353b8f60ac132191afd6b21f01997 Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Sat, 4 Nov 2023 17:33:30 -0700
Subject: [PATCH 0448/1072] Add diataxis reference in contributing doc

---
 source/contribute.rst | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/source/contribute.rst b/source/contribute.rst
index afac9e4f7..a246751e4 100644
--- a/source/contribute.rst
+++ b/source/contribute.rst
@@ -32,9 +32,12 @@ Documentation types
 ===================
 
 This project consists of four distinct documentation types with specific
-purposes. When proposing new additions to the project please pick the
+purposes. The project aspires to follow the `Diátaxis process`_
+for creating quality documentation. When proposing new additions to the project please pick the
 appropriate documentation type.
 
+.. _Diátaxis process: https://diataxis.fr/
+
 Tutorials
 ---------
 

From 51ca36eebe4c1305f71a2e94e6e808db5d33639a Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Sat, 4 Nov 2023 17:48:28 -0700
Subject: [PATCH 0449/1072] Add another category in guide index to put more
 advanced hosting/mirrors

---
 source/guides/index.rst | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/source/guides/index.rst b/source/guides/index.rst
index 10c189a17..4634dcc23 100644
--- a/source/guides/index.rst
+++ b/source/guides/index.rst
@@ -13,8 +13,6 @@ introduction to packaging, see :doc:`/tutorials/index`.
    installing-stand-alone-command-line-tools
    installing-using-linux-tools
    installing-scientific-packages
-   index-mirrors-and-caches
-   hosting-your-own-index
 
 .. toctree::
    :maxdepth: 1
@@ -31,6 +29,13 @@ introduction to packaging, see :doc:`/tutorials/index`.
    making-a-pypi-friendly-readme
    publishing-package-distribution-releases-using-github-actions-ci-cd-workflows
 
+.. toctree::
+   :maxdepth: 1
+   :caption: Hosting
+
+   index-mirrors-and-caches
+   hosting-your-own-index
+
 .. toctree::
    :maxdepth: 1
    :caption: Miscellaneous:

From 789d02b14297cae24c58a7155df36b7c4d569559 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sun, 5 Nov 2023 16:16:21 +0100
Subject: [PATCH 0450/1072] Split a pyproject.toml guide out of the "Declaring
 project metadata" specification

Fixes #1349
---
 .../creating-and-discovering-plugins.rst      |   2 +
 source/guides/index.rst                       |   1 +
 source/guides/writing-pyproject-toml.rst      | 383 ++++++++++++++++++
 .../declaring-project-metadata.rst            | 155 +------
 4 files changed, 392 insertions(+), 149 deletions(-)
 create mode 100644 source/guides/writing-pyproject-toml.rst

diff --git a/source/guides/creating-and-discovering-plugins.rst b/source/guides/creating-and-discovering-plugins.rst
index eceebc843..601f2b4a6 100644
--- a/source/guides/creating-and-discovering-plugins.rst
+++ b/source/guides/creating-and-discovering-plugins.rst
@@ -116,6 +116,8 @@ a list of packages to :func:`setup`'s ``packages`` argument instead of using
     :doc:`packaging-namespace-packages` documentation and clearly document
     which approach is preferred for plugins to your project.
 
+.. _plugin-entry-points:
+
 Using package metadata
 ======================
 
diff --git a/source/guides/index.rst b/source/guides/index.rst
index 4634dcc23..9854eb8b3 100644
--- a/source/guides/index.rst
+++ b/source/guides/index.rst
@@ -18,6 +18,7 @@ introduction to packaging, see :doc:`/tutorials/index`.
    :maxdepth: 1
    :caption: Building and Publishing Projects:
 
+   writing-pyproject-toml
    distributing-packages-using-setuptools
    using-manifest-in
    single-sourcing-package-version
diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
new file mode 100644
index 000000000..af5c2fe18
--- /dev/null
+++ b/source/guides/writing-pyproject-toml.rst
@@ -0,0 +1,383 @@
+.. _writing-pyproject-toml:
+
+===============================
+Writing your ``pyproject.toml``
+===============================
+
+.. TODO: link :term:`build backends` when that's merged
+
+``pyproject.toml`` is a configuration file used by packaging tools. Most
+build backends [#poetry-special]_ allow you to specify your project's
+basic metadata, such as the dependencies, your name, etc., in the ``[project]``
+table of your ``pyproject.toml``.
+
+.. note::
+
+   You may have heard of ``setup.py`` and ``setup.cfg`` for the setuptools_
+   build backend. For new projects, it is recommended to use ``pyproject.toml``
+   for basic metadata, and keep ``setup.py`` only if some programmatic configuration
+   is needed (especially building C extensions). However, putting basic project
+   metadata in ``setup.py`` or ``setup.cfg`` is still valid.
+
+.. TODO: link to "is setup.py deprecated?" page when merged
+
+Static vs. dynamic metadata
+===========================
+
+Most of the time, you will directly write the value of a field in
+``pyproject.toml``.  For example: ``requires-python = ">= 3.8"``, or
+``version = "1.0"``.
+
+However, in some cases, it is useful to let your build backend compute
+the metadata for you. For example: many build backends can read the
+version from a ``__version__`` attribute in your code, or similar.
+In such cases, you should mark the field as dynamic using, e.g.,
+
+.. code-block:: toml
+
+   [project]
+   dynamic = ["version"]
+
+
+When a field is dynamic, it is the build backend's responsibility to
+fill it.  Consult your build backend's documentation to learn how it
+does it.
+
+
+Basic information
+=================
+
+``name``
+--------
+
+Put the name of your project on PyPI. This field is required and is the
+only field that cannot be marked as dynamic.
+
+.. code-block:: toml
+
+   [project]
+   name = "spam"
+
+
+``version``
+-----------
+
+Put the version of your project.
+
+.. code-block:: toml
+
+    [project]
+    version = "2020.0.0"
+
+This field is required, although it is often marked as dynamic using
+
+.. code-block:: toml
+
+   [project]
+   dynamic = ["version"]
+
+
+
+Dependencies and requirements
+=============================
+
+``dependencies``/``optional-dependencies``
+------------------------------------------
+
+If your project has dependencies, list them like this:
+
+.. code-block:: toml
+
+   [project]
+   dependencies = [
+     "httpx",
+     "gidgethub[httpx]>4.0.0",
+     "django>2.1; os_name != 'nt'",
+     "django>2.0; os_name == 'nt'",
+   ]
+
+See :ref:`Dependency specifiers ` for the full
+syntax you can use to constrain versions.
+
+You may want to make some of your dependencies optional, if they are
+only needed for a specific feature of your package. In that case, put
+them in ``optional-dependencies``.
+
+.. code-block:: toml
+
+    [project.optional-dependencies]
+    gui = ["PyQt5"]
+    cli = [
+      "rich",
+      "click",
+    ]
+
+Each of the keys defines a "packaging extra". In the example above, one
+could use, e.g., ``pip install your-project-name[gui]`` to install your
+project with GUI support, adding the PyQt5 dependency.
+
+
+``python-requires``
+-------------------
+
+This lets you declare the minimum version of Python that you support
+[#requires-python-upper-bounds]_.
+
+.. code-block:: toml
+
+   [project]
+   requires-python = ">= 3.8"
+
+
+
+Creating executable scripts
+===========================
+
+To install a command as part of your package, declare it in the
+``[project.scripts]`` table.
+
+.. code-block:: toml
+
+   [project.scripts]
+   spam-cli = "spam:main_cli"
+
+In this example, after installing your project, a ``spam-cli`` command
+will be available. Executing this command will do the equivalent of
+``from spam import main_cli; main_cli()``.
+
+On Windows, scripts packaged this way need a terminal, so if you launch
+them from within a graphical application, they will make a terminal pop
+up. To prevent this from happening, use the ``[project.gui-scripts]``
+table instead of ``[project.scripts]``.
+
+.. code-block:: toml
+
+   [project.gui-scripts]
+   spam-gui = "spam:main_gui"
+
+In that case, launching your script from the command line will give back
+control immediately, leaving the script to run in the background.
+
+The difference between ``[project.scripts]`` and
+``[project.gui-scripts]`` is only relevant on Windows.
+
+
+
+About your project
+==================
+
+``authors``/``maintainers``
+---------------------------
+
+Both of these fields contain lists of people identified by a name and/or
+an email address.
+
+.. code-block:: toml
+
+    [project]
+    authors = [
+      {name = "Pradyun Gedam", email = "pradyun@example.com"},
+      {name = "Tzu-Ping Chung", email = "tzu-ping@example.com"},
+      {name = "Another person"},
+      {email = "different.person@example.com"},
+    ]
+    maintainers = [
+      {name = "Brett Cannon", email = "brett@python.org"}
+    ]
+
+
+``description``
+---------------
+
+This should be a one-line description of your project, to show as the
+"headline" of your project page on PyPI (`example `_).
+
+.. code-block:: toml
+
+    [project]
+    description = "Lovely Spam! Wonderful Spam!"
+
+
+``readme``
+----------
+
+This is a longer description of your project, to display on your project
+page on PyPI. Typically, your project will have a ``README.md`` or
+``README.rst`` file and you just put its file name here.
+
+.. code-block:: toml
+
+    [project]
+    readme = "README.md"
+
+The README's format is auto-detected from the extension:
+
+- ``README.md`` → Markdown,
+- ``README.rst`` → reStructuredText (without Sphinx extensions).
+
+You can also specify the format explicitly, like this:
+
+.. code-block:: toml
+
+   [project]
+   readme = {file = "README.txt", content-type = "text/markdown"}
+   # or
+   readme = {file = "README.txt", content-type = "text/x-rst"}
+
+
+``license``
+-----------
+
+This can take two forms. You can put your license in a file, typically
+``LICENSE`` or ``LICENSE.txt``, and link that file here:
+
+.. code-block:: toml
+
+    [project]
+    license = {file = "LICENSE"}
+
+or you can write the name of the license:
+
+
+.. code-block:: toml
+
+    [project]
+    license = {text = "MIT License"}
+
+
+
+``keywords``
+------------
+
+This will help PyPI's search box to suggest your project when people
+search for these keywords.
+
+.. code-block:: toml
+
+    [project]
+    keywords = ["egg", "bacon", "sausage", "tomatoes", "Lobster Thermidor"]
+
+
+``classifiers``
+---------------
+
+A list of PyPI classifiers that apply to your project. Check the
+`full list of possibilities `_.
+
+.. code-block:: toml
+
+    classifiers = [
+      "Development Status :: 4 - Beta",
+      "Programming Language :: Python"
+    ]
+
+
+``urls``
+--------
+
+A list of URLs associated with your project, displayed on the left
+sidebar of your PyPI project page. If the key contains spaces, don't
+forget to quote it.
+
+.. code-block:: toml
+
+    [project.urls]
+    Homepage = "https://example.com"
+    Documentation = "https://readthedocs.org"
+    Repository = "https://github.com/me/spam.git"
+    "Bug Tracker" = "https://github.com/me/spam/issues"
+    Changelog = "https://github.com/me/spam/blob/master/CHANGELOG.md"
+
+
+Advanced plugins
+================
+
+Some packages can be extended through plugins. Examples include Pytest_
+and Pygments_. To create such a plugin, you need to declare it in a subtable
+of ``[project.entry-points]`` like this:
+
+.. code-block:: toml
+
+   [project.entry-points."spam.magical"]
+   tomatoes = "spam:main_tomatoes"
+
+See the :ref:`Plugin guide ` for more information.
+
+
+
+A full example
+==============
+
+.. code-block:: toml
+
+   [project]
+   name = "spam"
+   version = "2020.0.0"
+   dependencies = [
+     "httpx",
+     "gidgethub[httpx]>4.0.0",
+     "django>2.1; os_name != 'nt'",
+     "django>2.0; os_name == 'nt'",
+   ]
+   requires-python = ">=3.8"
+   authors = [
+     {name = "Pradyun Gedam", email = "pradyun@example.com"},
+     {name = "Tzu-Ping Chung", email = "tzu-ping@example.com"},
+     {name = "Another person"},
+     {email = "different.person@example.com"},
+   ]
+   maintainers = [
+     {name = "Brett Cannon", email = "brett@python.org"}
+   ]
+   description = "Lovely Spam! Wonderful Spam!"
+   readme = "README.rst"
+   license = {file = "LICENSE.txt"}
+   keywords = ["egg", "bacon", "sausage", "tomatoes", "Lobster Thermidor"]
+   classifiers = [
+     "Development Status :: 4 - Beta",
+     "Programming Language :: Python"
+   ]
+
+   # dynamic = ["version", "description"]
+
+   [project.optional-dependencies]
+   gui = ["PyQt5"]
+   cli = [
+     "rich",
+     "click",
+   ]
+
+   [project.urls]
+   Homepage = "https://example.com"
+   Documentation = "https://readthedocs.org"
+   Repository = "https://github.com/me/spam.git"
+   "Bug Tracker" = "https://github.com/me/spam/issues"
+   Changelog = "https://github.com/me/spam/blob/master/CHANGELOG.md"
+
+   [project.scripts]
+   spam-cli = "spam:main_cli"
+
+   [project.gui-scripts]
+   spam-gui = "spam:main_gui"
+
+   [project.entry-points."spam.magical"]
+   tomatoes = "spam:main_tomatoes"
+
+
+------------------
+
+.. [#poetry-special] At the time of this writing (November 2023), Poetry_
+   is a notable exception.  It uses its own format for this metadata, in
+   the ``[tool.poetry]`` table.
+
+.. [#requires-python-upper-bounds] Think twice before applying an upper bound
+   like ``requires-python = "<= 3.10"`` here. `This blog post `_
+   contains some information regarding possible problems.
+
+.. _setuptools: https://setuptools.pypa.io
+.. _poetry: https://python-poetry.org
+.. _pypi-pip: https://pypi.org/project/pip
+.. _classifier-list: https://pypi.org/classifiers
+.. _requires-python-blog-post: https://iscinumpy.dev/post/bound-version-constraints/#pinning-the-python-version-is-special
+.. _pytest: https://pytest.org
+.. _pygments: https://pygments.org
diff --git a/source/specifications/declaring-project-metadata.rst b/source/specifications/declaring-project-metadata.rst
index 4f1d4199d..c7e7e3040 100644
--- a/source/specifications/declaring-project-metadata.rst
+++ b/source/specifications/declaring-project-metadata.rst
@@ -9,6 +9,12 @@ Declaring project metadata
 packaging-related tools to consume. It defines the following
 specification as the canonical source for the format used.
 
+.. warning::
+
+   This is a **technical, formal specification**. For a gentle,
+   user-friendly guide to ``pyproject.toml``, see
+   :ref:`writing-pyproject-toml`.
+
 
 Specification
 =============
@@ -75,11 +81,6 @@ The name of the project.
 Tools SHOULD :ref:`normalize ` this name, as soon
 as it is read for internal consistency.
 
-.. code-block:: toml
-
-    [project]
-    name = "spam"
-
 ``version``
 -----------
 
@@ -91,10 +92,6 @@ The version of the project as supported by :pep:`440`.
 
 Users SHOULD prefer to specify already-normalized versions.
 
-.. code-block:: toml
-
-    [project]
-    version = "2020.0.0"
 
 ``description``
 ---------------
@@ -105,10 +102,6 @@ Users SHOULD prefer to specify already-normalized versions.
 
 The summary description of the project.
 
-.. code-block:: toml
-
-    [project]
-    description = "Lovely Spam! Wonderful Spam!"
 
 ``readme``
 ----------
@@ -148,13 +141,6 @@ alternative content-types which they can transform to a content-type
 as supported by the :ref:`core metadata `. Otherwise
 tools MUST raise an error for unsupported content-types.
 
-.. code-block:: toml
-
-    [project]
-    # A single pyproject.toml file can only have one of the following.
-    readme = "README.md"
-    readme = "README.rst"
-    readme = {file = "README.txt", content-type = "text/markdown"}
 
 ``requires-python``
 -------------------
@@ -165,10 +151,6 @@ tools MUST raise an error for unsupported content-types.
 
 The Python version requirements of the project.
 
-.. code-block:: toml
-
-    [project]
-    requires-python = ">=3.8"
 
 ``license``
 -----------
@@ -184,12 +166,6 @@ file's encoding is UTF-8. The ``text`` key has a string value which is
 the license of the project.  These keys are mutually exclusive, so a
 tool MUST raise an error if the metadata specifies both keys.
 
-.. code-block:: toml
-
-    [project]
-    # A single pyproject.toml file can only have one of the following.
-    license = {file = "LICENSE"}
-    license = {text = "MIT License"}
 
 ``authors``/``maintainers``
 ---------------------------
@@ -232,19 +208,6 @@ follows:
    as appropriate, with the format ``{name} <{email}>``.
 4. Multiple values should be separated by commas.
 
-.. code-block:: toml
-
-    [project]
-    authors = [
-      {name = "Pradyun Gedam", email = "pradyun@example.com"},
-      {name = "Tzu-Ping Chung", email = "tzu-ping@example.com"},
-      {name = "Another person"},
-      {email = "different.person@example.com"},
-    ]
-    maintainers = [
-      {name = "Brett Cannon", email = "brett@python.org"}
-    ]
-
 
 ``keywords``
 ------------
@@ -255,10 +218,6 @@ follows:
 
 The keywords for the project.
 
-.. code-block:: toml
-
-    [project]
-    keywords = ["egg", "bacon", "sausage", "tomatoes", "Lobster Thermidor"]
 
 ``classifiers``
 ---------------
@@ -269,12 +228,6 @@ The keywords for the project.
 
 Trove classifiers which apply to the project.
 
-.. code-block:: toml
-
-    classifiers = [
-      "Development Status :: 4 - Beta",
-      "Programming Language :: Python"
-    ]
 
 ``urls``
 --------
@@ -286,13 +239,6 @@ Trove classifiers which apply to the project.
 A table of URLs where the key is the URL label and the value is the
 URL itself.
 
-.. code-block:: toml
-
-    [project.urls]
-    Homepage = "https://example.com"
-    Documentation = "https://readthedocs.org"
-    Repository = "https://github.com/me/spam.git"
-    Changelog = "https://github.com/me/spam/blob/master/CHANGELOG.md"
 
 Entry points
 ------------
@@ -323,17 +269,6 @@ Build back-ends MUST raise an error if the metadata defines a
 be ambiguous in the face of ``[project.scripts]`` and
 ``[project.gui-scripts]``, respectively.
 
-.. code-block:: toml
-
-    [project.scripts]
-    spam-cli = "spam:main_cli"
-
-    [project.gui-scripts]
-    spam-gui = "spam:main_gui"
-
-    [project.entry-points."spam.magical"]
-    tomatoes = "spam:main_tomatoes"
-
 
 ``dependencies``/``optional-dependencies``
 ------------------------------------------
@@ -361,22 +296,6 @@ in the array thus becomes a corresponding
 matching :ref:`Provides-Extra `
 metadata.
 
-.. code-block:: toml
-
-    [project]
-    dependencies = [
-      "httpx",
-      "gidgethub[httpx]>4.0.0",
-      "django>2.1; os_name != 'nt'",
-      "django>2.0; os_name == 'nt'",
-    ]
-
-    [project.optional-dependencies]
-    gui = ["PyQt5"]
-    cli = [
-      "rich",
-      "click",
-    ]
 
 ``dynamic``
 -----------
@@ -415,68 +334,6 @@ provided via tooling later on.
   the data for it (omitting the data, if determined to be the accurate
   value, is acceptable).
 
-.. code-block:: toml
-
-    dynamic = ["version", "description", "optional-dependencies"]
-
-
-Example
-=======
-
-.. code-block:: toml
-
-    [project]
-    name = "spam"
-    version = "2020.0.0"
-    description = "Lovely Spam! Wonderful Spam!"
-    readme = "README.rst"
-    requires-python = ">=3.8"
-    license = {file = "LICENSE.txt"}
-    keywords = ["egg", "bacon", "sausage", "tomatoes", "Lobster Thermidor"]
-    authors = [
-      {name = "Pradyun Gedam", email = "pradyun@example.com"},
-      {name = "Tzu-Ping Chung", email = "tzu-ping@example.com"},
-      {name = "Another person"},
-      {email = "different.person@example.com"},
-    ]
-    maintainers = [
-      {name = "Brett Cannon", email = "brett@python.org"}
-    ]
-    classifiers = [
-      "Development Status :: 4 - Beta",
-      "Programming Language :: Python"
-    ]
-
-    dependencies = [
-      "httpx",
-      "gidgethub[httpx]>4.0.0",
-      "django>2.1; os_name != 'nt'",
-      "django>2.0; os_name == 'nt'",
-    ]
-
-    # dynamic = ["version", "description"]
-
-    [project.optional-dependencies]
-    gui = ["PyQt5"]
-    cli = [
-      "rich",
-      "click",
-    ]
-
-    [project.urls]
-    Homepage = "https://example.com"
-    Documentation = "https://readthedocs.org"
-    Repository = "https://github.com/me/spam.git"
-    Changelog = "https://github.com/me/spam/blob/master/CHANGELOG.md"
-
-    [project.scripts]
-    spam-cli = "spam:main_cli"
-
-    [project.gui-scripts]
-    spam-gui = "spam:main_gui"
-
-    [project.entry-points."spam.magical"]
-    tomatoes = "spam:main_tomatoes"
 
 
 .. _TOML: https://toml.io

From 45d0b24e73dbcca6c98eaa4f934267b8593d5b52 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sun, 5 Nov 2023 18:19:23 +0100
Subject: [PATCH 0451/1072] Bump requirements

- Upgrade to latest version of Sphinx (and other dependencies),
- Use "language = 'en'" in configuration since recent Sphinx versions
  do not accept "language = None" anymore,
- Add now required "%s" in extlinks config,
- Refer to setuptools explicitly in :std:doc: because Sphinx no longer
  implicitly uses intersphinx (by default) for this role. See
  https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html#confval-intersphinx_disabled_reftypes

The generated HTML can be compared using

$ diff -u build-old/ build-new | colordiff | diff-highlight

The only visible change is "Permalink to this headling" becoming "Link to this heading".
---
 requirements.txt                                     |  6 +++---
 source/conf.py                                       | 12 ++++++------
 .../distributing-packages-using-setuptools.rst       |  4 ++--
 source/overview.rst                                  |  2 +-
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/requirements.txt b/requirements.txt
index d6e0d750f..6cdad44d2 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1,7 +1,7 @@
-sphinx==4.5.0
+sphinx==7.2.6
 sphinx-autobuild==2021.3.14
-sphinx-inline-tabs==2021.4.11b9
+sphinx-inline-tabs==2023.4.21
 python-docs-theme==2023.9
-sphinx-copybutton==0.5.0
+sphinx-copybutton==0.5.2
 pypa-docs-theme @ git+https://github.com/pypa/pypa-docs-theme.git
 sphinx-toolbox==3.5.0
diff --git a/source/conf.py b/source/conf.py
index 9113b8c68..c4d7a5ccc 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -88,7 +88,7 @@
 #
 # This is also used if you do content translation via gettext catalogs.
 # Usually you set "language" from the command line for these cases.
-language = None
+language = 'en'
 
 locale_dirs = ['../locales']
 
@@ -379,11 +379,11 @@
 
 # -- Options for extlinks extension ---------------------------------------
 extlinks = {
-    'issue': (f'{github_repo_issues_url}/%s', '#'),  # noqa: WPS323
-    'pr': (f'{github_repo_url}/pull/%s', 'PR #'),  # noqa: WPS323
-    'commit': (f'{github_repo_url}/commit/%s', ''),  # noqa: WPS323
-    'gh': (f'{github_url}/%s', 'GitHub: '),  # noqa: WPS323
-    'user': (f'{github_sponsors_url}/%s', '@'),  # noqa: WPS323
+    'issue': (f'{github_repo_issues_url}/%s', '#%s'),  # noqa: WPS323
+    'pr': (f'{github_repo_url}/pull/%s', 'PR #%s'),  # noqa: WPS323
+    'commit': (f'{github_repo_url}/commit/%s', '%s'),  # noqa: WPS323
+    'gh': (f'{github_url}/%s', 'GitHub: %s'),  # noqa: WPS323
+    'user': (f'{github_sponsors_url}/%s', '@%s'),  # noqa: WPS323
 }
 
 linkcheck_ignore = [
diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst
index db982071d..f860cad06 100644
--- a/source/guides/distributing-packages-using-setuptools.rst
+++ b/source/guides/distributing-packages-using-setuptools.rst
@@ -15,7 +15,7 @@ development as a whole.  For example, it does not provide guidance or tool
 recommendations for version control, documentation, or testing.
 
 For more reference material, see :std:doc:`Building and Distributing
-Packages ` in the :ref:`setuptools` docs, but note
+Packages ` in the :ref:`setuptools` docs, but note
 that some advisory content there may be outdated. In the event of
 conflicts, prefer the advice in the Python Packaging User Guide.
 
@@ -717,7 +717,7 @@ Lastly, if you don't want to install any dependencies at all, you can run:
 
 For more information, see the
 :doc:`Development Mode ` section
-of the :doc:`setuptools docs `.
+of the :ref:`setuptools` docs.
 
 .. _`Packaging your project`:
 
diff --git a/source/overview.rst b/source/overview.rst
index 256510bb8..2f3f44007 100644
--- a/source/overview.rst
+++ b/source/overview.rst
@@ -167,7 +167,7 @@ Python's native packaging is mostly built for distributing reusable
 code, called libraries, between developers. You can piggyback
 **tools**, or basic applications for developers, on top of Python's
 library packaging, using technologies like
-:doc:`setuptools entry_points `.
+:doc:`setuptools entry_points `.
 
 Libraries are building blocks, not complete applications. For
 distributing applications, there's a whole new world of technologies

From 2ccba195df7fa75684efeb453c44d2912fdf33a7 Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Sun, 5 Nov 2023 11:57:49 -0800
Subject: [PATCH 0452/1072] remove reference to Python 2 and virtualenv

---
 .../guides/installing-using-pip-and-virtual-environments.rst  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst
index 07ef2d26a..cb54fe189 100644
--- a/source/guides/installing-using-pip-and-virtual-environments.rst
+++ b/source/guides/installing-using-pip-and-virtual-environments.rst
@@ -11,8 +11,8 @@ The guide covers how to:
 * Use and create a requirements file
 
 
-.. note:: This guide applies to Python 3.3 and higher. If using a
-    legacy version of Python 2.x, consider using :ref:`virtualenv`.
+.. note:: This guide applies to supported versions of Python, currently 3.8
+    and higher.
 
 
 .. note:: This guide uses the term **package** to refer to a

From aa57f2edab29f48ca60458ba29adabae60bf23c2 Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Sun, 5 Nov 2023 12:14:06 -0800
Subject: [PATCH 0453/1072] add stub how-to guide for virtualenv

---
 source/guides/index.rst                       |  1 +
 source/guides/installing-using-virtualenv.rst | 17 +++++++++++++++++
 2 files changed, 18 insertions(+)
 create mode 100644 source/guides/installing-using-virtualenv.rst

diff --git a/source/guides/index.rst b/source/guides/index.rst
index 4634dcc23..2f6f1a217 100644
--- a/source/guides/index.rst
+++ b/source/guides/index.rst
@@ -10,6 +10,7 @@ introduction to packaging, see :doc:`/tutorials/index`.
    :caption: Installing Packages:
 
    installing-using-pip-and-virtual-environments
+   installing-using-virtualenv
    installing-stand-alone-command-line-tools
    installing-using-linux-tools
    installing-scientific-packages
diff --git a/source/guides/installing-using-virtualenv.rst b/source/guides/installing-using-virtualenv.rst
new file mode 100644
index 000000000..d498677f0
--- /dev/null
+++ b/source/guides/installing-using-virtualenv.rst
@@ -0,0 +1,17 @@
+Installing packages using virtualenv
+====================================
+
+This guide discusses how to install packages using :ref:`pip` and
+:ref:`virtualenv`, a tool to create isolated Python environments.
+
+.. important::
+    This "how to" guide on installing packages and using :ref:`virtualenv` is
+    under development. Please refer to the `virtualenv's documentation`_ for
+    details on installation and usage.
+
+    .. virtualenv's documentation:: https://virtualenv.pypa.io/
+
+
+.. note:: This doc uses the term **package** to refer to a
+    :term:`Distribution Package`  which is different from an :term:`Import
+    Package` that which is used to import modules in your Python source code.

From 4c6680f58dada4609a337cd0044978fd5f6be8b7 Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Sun, 5 Nov 2023 12:21:35 -0800
Subject: [PATCH 0454/1072] Create an orphan page per @pradyunsg review

---
 source/tutorials/creating-documentation.rst | 7 +++++++
 1 file changed, 7 insertions(+)
 create mode 100644 source/tutorials/creating-documentation.rst

diff --git a/source/tutorials/creating-documentation.rst b/source/tutorials/creating-documentation.rst
new file mode 100644
index 000000000..5d9dae787
--- /dev/null
+++ b/source/tutorials/creating-documentation.rst
@@ -0,0 +1,7 @@
+:orphan:
+
+Creating documentation
+======================
+
+This tutorial has been removed since it is not related to packaging and was unmaintained.
+Please see the `Sphinx tutorial `_ instead.

From 6f9034105928e552689c7378fd91b13fb647be2c Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Sun, 5 Nov 2023 12:24:40 -0800
Subject: [PATCH 0455/1072] remove colon

---
 source/guides/installing-using-virtualenv.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/installing-using-virtualenv.rst b/source/guides/installing-using-virtualenv.rst
index d498677f0..f29dcd845 100644
--- a/source/guides/installing-using-virtualenv.rst
+++ b/source/guides/installing-using-virtualenv.rst
@@ -9,7 +9,7 @@ This guide discusses how to install packages using :ref:`pip` and
     under development. Please refer to the `virtualenv's documentation`_ for
     details on installation and usage.
 
-    .. virtualenv's documentation:: https://virtualenv.pypa.io/
+    .. virtualenv's documentation: https://virtualenv.pypa.io/
 
 
 .. note:: This doc uses the term **package** to refer to a

From 85512268afa5b3bd2d0edf472a864fddd12fa1d2 Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Sun, 5 Nov 2023 12:33:04 -0800
Subject: [PATCH 0456/1072] use existing ref

---
 source/guides/installing-using-virtualenv.rst | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/source/guides/installing-using-virtualenv.rst b/source/guides/installing-using-virtualenv.rst
index f29dcd845..a584b89d5 100644
--- a/source/guides/installing-using-virtualenv.rst
+++ b/source/guides/installing-using-virtualenv.rst
@@ -6,11 +6,9 @@ This guide discusses how to install packages using :ref:`pip` and
 
 .. important::
     This "how to" guide on installing packages and using :ref:`virtualenv` is
-    under development. Please refer to the `virtualenv's documentation`_ for
+    under development. Please refer to the :ref:`virtualenv` documentation for
     details on installation and usage.
 
-    .. virtualenv's documentation: https://virtualenv.pypa.io/
-
 
 .. note:: This doc uses the term **package** to refer to a
     :term:`Distribution Package`  which is different from an :term:`Import

From d10c3cfccb32db03fe941b79311843fab7ff4535 Mon Sep 17 00:00:00 2001
From: Sviatoslav Sydorenko 
Date: Mon, 6 Nov 2023 03:22:41 +0100
Subject: [PATCH 0457/1072] Fix the external flit lift page link RST syntax

Co-authored-by: chrysle 
---
 source/key_projects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index 1e9b58e51..a9b57fac4 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -105,7 +105,7 @@ Python 2, so long as they can be imported on Python 3.
 
 The flit package is lifted by `Matthias Bussonnier
 `__ since October 2023 on the `tidelift platform
-``__, and funds sent to the PSF and
 earmarked for PyPA usage.
 
 .. _flit-rationale: https://flit.readthedocs.io/en/latest/rationale.html

From 0b59fc4fa1d897c1d348d5d12eabf0673a0a8803 Mon Sep 17 00:00:00 2001
From: Pradyun Gedam 
Date: Mon, 6 Nov 2023 10:57:46 +0000
Subject: [PATCH 0458/1072] Use a ref to the twine index page

Co-authored-by: Sviatoslav Sydorenko 
---
 source/guides/packaging-binary-extensions.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/packaging-binary-extensions.rst b/source/guides/packaging-binary-extensions.rst
index 0c6187c29..73f25fc03 100644
--- a/source/guides/packaging-binary-extensions.rst
+++ b/source/guides/packaging-binary-extensions.rst
@@ -361,7 +361,7 @@ Publishing binary extensions
 Publishing binary extensions through PyPI uses the same upload mechanisms as
 publishing pure Python packages. You build a wheel file for your extension
 using the build-backend and upload it to PyPI using
-`twine `_.
+:doc:`twine `.
 
 Avoid binary-only releases
 --------------------------

From f52d232186ec487fdf489c516d413a25637d4295 Mon Sep 17 00:00:00 2001
From: Sviatoslav Sydorenko 
Date: Mon, 16 Nov 2020 19:25:49 +0100
Subject: [PATCH 0459/1072] =?UTF-8?q?=F0=9F=92=84=20Change=20Sphinx=20them?=
 =?UTF-8?q?e=20to=20furo?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 requirements.txt     |   3 +--
 source/assets/py.png | Bin 0 -> 695 bytes
 source/conf.py       |  20 +++++++++-----------
 3 files changed, 10 insertions(+), 13 deletions(-)
 create mode 100644 source/assets/py.png

diff --git a/requirements.txt b/requirements.txt
index 6cdad44d2..077adb580 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1,7 +1,6 @@
+furo==2023.9.10
 sphinx==7.2.6
 sphinx-autobuild==2021.3.14
 sphinx-inline-tabs==2023.4.21
-python-docs-theme==2023.9
 sphinx-copybutton==0.5.2
-pypa-docs-theme @ git+https://github.com/pypa/pypa-docs-theme.git
 sphinx-toolbox==3.5.0
diff --git a/source/assets/py.png b/source/assets/py.png
new file mode 100644
index 0000000000000000000000000000000000000000..93e4a02c3d321c545898a2ebb8873c26dd8a9e5b
GIT binary patch
literal 695
zcmV;o0!aOdP)Px#24YJ`L;(K){{a7>y{D4^000SaNLh0L01FcU01FcV0GgZ_00007bV*G`2iOD~
z5jY_RGbdgE00K8jL_t(I%Vm>KNL4`;hrfH@vv+$Uln|xSCTLTOHmzE;5FTwpDtJ)a
zz)exE-2_34AR^i+ZCXeh7m*-F5k*FrmbSHs%rX_!{PXUec{69`w(#D(>Vd<+%=bIz
zH_V)XUD5sE?K5ebbKaSDu}#Dnq^Y!3`tis9>wSO*T+WBP3wS3NNBU~*PAtw^yjZ+<
zQ5yK0z%d{y@_Pz6YdL>s7$6Y^hI$}5GUX?Ns>+iCUiRP
z7h|*&%kQa?wQA%pYzqpaf*4?WM!x_ygY0K@07rplx^QhGhnE)r4wbx0x11<&3V?63
z=F8ch)p6iQ88E;iumPmSZif%JIwIgKh$T3)*ab8ImGLVf;IoYtVAb11Z&@wm>96=S
z)!B&hojbAPoik&f)Lp;=N!HK;X~5oyfJ49$pbcorTyADv
dm$H!t;2#0MumAjv0Ga>*002ovPDHLkV1gIiH5UK?

literal 0
HcmV?d00001

diff --git a/source/conf.py b/source/conf.py
index c4d7a5ccc..a55343737 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -133,7 +133,7 @@
 # show_authors = False
 
 # The name of the Pygments (syntax highlighting) style to use.
-pygments_style = 'sphinx'
+#pygments_style = 'sphinx'
 
 # A list of ignored prefixes for module index sorting.
 # modindex_common_prefix = []
@@ -150,16 +150,14 @@
 # The theme to use for HTML and HTML Help pages.  See the documentation for
 # a list of builtin themes.
 #
-html_theme = 'pypa_theme'
+html_theme = 'furo'
 
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the
 # documentation.
 html_theme_options = {
-    'collapsiblesidebar': True,
-    'externalrefs': True,
-    'navigation_depth': 2,
-    'issues_url': github_repo_issues_url,
+    "sidebar_hide_name": True,
+    # 'issues_url': github_repo_issues_url,  # FIXME: support this in furo?
 }
 
 # Add any paths that contain custom themes here, relative to this directory.
@@ -177,7 +175,7 @@
 # The name of an image file (relative to this directory) to place at the top
 # of the sidebar.
 #
-# html_logo = None
+html_logo = 'assets/py.png'
 
 # The name of an image file (relative to this directory) to use as a favicon of
 # the docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
@@ -211,10 +209,10 @@
 #
 
 # Custom sidebar templates, filenames relative to this file.
-html_sidebars = {
-    '**': ['globaltoc.html', 'relations.html'],
-    'index': ['globaltoc.html']
-}
+# html_sidebars = {
+#     '**': ['globaltoc.html', 'relations.html'],
+#     'index': ['globaltoc.html']
+# }
 
 # Additional templates that should be rendered to pages, maps page names to
 # template names.

From 46c4d048c5beb789144618231df1a9f936128d36 Mon Sep 17 00:00:00 2001
From: Anderson Bravalheri 
Date: Mon, 6 Nov 2023 17:22:32 +0000
Subject: [PATCH 0460/1072] Clarify that packages don't need __init__.py

But still recommend people that are getting started with Python
packaging to add them.
---
 source/tutorials/packaging-projects.rst | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst
index 251280144..0a5212f77 100644
--- a/source/tutorials/packaging-projects.rst
+++ b/source/tutorials/packaging-projects.rst
@@ -54,8 +54,8 @@ Create the following file structure locally:
 The directory containing the Python files should match the project name. This
 simplifies the configuration and is more obvious to users who install the package.
 
-:file:`__init__.py` is required to import the directory as a package,
-even if as is our case for this tutorial that file is empty.
+:file:`__init__.py` is recommended to import the directory as a regular package,
+even if as is our case for this tutorial that file is empty [#namespace-packages]_.
 
 :file:`example.py` is an example of a module within the package that could
 contain the logic (functions, classes, constants, etc.) of your package.
@@ -535,3 +535,15 @@ some things you can do:
   :ref:`pdm`, and :ref:`poetry`.
 * Read :pep:`517` and :pep:`518` for background and details on build tool configuration.
 * Read about :doc:`/guides/packaging-binary-extensions`.
+
+
+----
+
+.. rubric:: Notes
+
+.. [#namespace-packages]
+   Technically, you can also create Python packages without an ``__init__.py`` file,
+   but those are called :doc:`namespace packages `
+   and considered an **advanced topic** (not covered in this tutorial).
+   If you are only getting started with Python packaging, it is recommended to
+   stick with *regular packages* and ``__init__.py`` (even if the file is empty).

From d1ca49bedc0c453b17d7d49f9e6f96b2e339d86e Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Mon, 6 Nov 2023 09:39:57 -0800
Subject: [PATCH 0461/1072] Add @chrysle correction

Co-authored-by: chrysle 
---
 source/guides/installing-using-pip-and-virtual-environments.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst
index cb54fe189..2544aa40a 100644
--- a/source/guides/installing-using-pip-and-virtual-environments.rst
+++ b/source/guides/installing-using-pip-and-virtual-environments.rst
@@ -38,7 +38,7 @@ Create a new virtual environment
 different projects. It creates a "virtual" isolated Python installation. When
 you switch projects, you can create a new virtual environment which is isolated
 from other virtual environments. You benefit from the virtual environment
-since packages can be installed confidently and will not interfere with the
+since packages can be installed confidently and will not interfere with
 another project's environment.
 
 .. tip::

From f1c623c35d4613489ce0853fe1891287cba8882c Mon Sep 17 00:00:00 2001
From: Aaron Holmes 
Date: Mon, 6 Nov 2023 10:40:18 -0800
Subject: [PATCH 0462/1072] Move exposure of github token to only the steps
 that need it.

---
 .../github-actions-ci-cd-sample/publish-to-test-pypi.yml   | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
index 02d1f8e84..72a3eb7b2 100644
--- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
+++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
@@ -61,9 +61,6 @@ jobs:
       contents: write  # IMPORTANT: mandatory for making GitHub Releases
       id-token: write  # IMPORTANT: mandatory for sigstore
 
-    env:
-      GITHUB_TOKEN: ${{ github.token }}
-
     steps:
     - name: Download all the dists
       uses: actions/download-artifact@v3
@@ -77,12 +74,16 @@ jobs:
           ./dist/*.tar.gz
           ./dist/*.whl
     - name: Create GitHub Release
+      env:
+        GITHUB_TOKEN: ${{ github.token }}
       run: >-
         gh release create
         '${{ github.ref_name }}'
         --repo '${{ github.repository }}'
         --notes ""
     - name: Upload artifact signatures to GitHub Release
+      env:
+        GITHUB_TOKEN: ${{ github.token }}
       # Upload to GitHub Release using the `gh` CLI.
       # `dist/` contains the built packages, and the
       # sigstore-produced signatures and certificates.

From cc78e34b90c1ead565e49968b12ed0d308456632 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Mon, 6 Nov 2023 20:42:37 +0100
Subject: [PATCH 0463/1072] Remove outcommented example of dynamic metadata

---
 source/guides/writing-pyproject-toml.rst | 2 --
 1 file changed, 2 deletions(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index af5c2fe18..8e28e305b 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -338,8 +338,6 @@ A full example
      "Programming Language :: Python"
    ]
 
-   # dynamic = ["version", "description"]
-
    [project.optional-dependencies]
    gui = ["PyQt5"]
    cli = [

From cccaa25bc216efd07ccd5940d4a27d630fb78150 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Mon, 6 Nov 2023 21:26:06 +0100
Subject: [PATCH 0464/1072] Remove contents directives

They're not useful with Furo, which has a right sidebar with the local
TOC, and they make it generate warnings in the rendered documentation.
---
 source/discussions/deploying-python-applications.rst     | 3 ---
 source/discussions/install-requires-vs-requirements.rst  | 3 ---
 source/guides/analyzing-pypi-package-downloads.rst       | 3 ---
 source/guides/distributing-packages-using-setuptools.rst | 2 --
 source/guides/index-mirrors-and-caches.rst               | 3 ---
 source/guides/installing-scientific-packages.rst         | 3 ---
 source/guides/installing-using-linux-tools.rst           | 3 ---
 source/guides/packaging-binary-extensions.rst            | 2 --
 source/guides/supporting-multiple-python-versions.rst    | 3 ---
 source/guides/supporting-windows-using-appveyor.rst      | 3 ---
 source/overview.rst                                      | 3 ---
 source/specifications/core-metadata.rst                  | 2 --
 source/specifications/direct-url-data-structure.rst      | 2 --
 source/specifications/direct-url.rst                     | 2 --
 source/tutorials/installing-packages.rst                 | 4 ----
 15 files changed, 41 deletions(-)

diff --git a/source/discussions/deploying-python-applications.rst b/source/discussions/deploying-python-applications.rst
index d9246d563..19ecd398e 100644
--- a/source/discussions/deploying-python-applications.rst
+++ b/source/discussions/deploying-python-applications.rst
@@ -6,9 +6,6 @@ Deploying Python applications
 :Page Status: Incomplete
 :Last Reviewed: 2021-8-24
 
-.. contents:: Contents
-   :local:
-
 
 Overview
 ========
diff --git a/source/discussions/install-requires-vs-requirements.rst b/source/discussions/install-requires-vs-requirements.rst
index 418785c9b..99e1552b8 100644
--- a/source/discussions/install-requires-vs-requirements.rst
+++ b/source/discussions/install-requires-vs-requirements.rst
@@ -4,9 +4,6 @@
 install_requires vs requirements files
 ======================================
 
-.. contents:: Contents
-   :local:
-
 
 install_requires
 ----------------
diff --git a/source/guides/analyzing-pypi-package-downloads.rst b/source/guides/analyzing-pypi-package-downloads.rst
index 5ee038587..4d2993479 100644
--- a/source/guides/analyzing-pypi-package-downloads.rst
+++ b/source/guides/analyzing-pypi-package-downloads.rst
@@ -7,9 +7,6 @@ to learn more about downloads of a package (or packages) hosted on PyPI. For
 example, you can use it to discover the distribution of Python versions used to
 download a package.
 
-.. contents:: Contents
-   :local:
-
 
 Background
 ==========
diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst
index f860cad06..4b570e17b 100644
--- a/source/guides/distributing-packages-using-setuptools.rst
+++ b/source/guides/distributing-packages-using-setuptools.rst
@@ -19,8 +19,6 @@ Packages ` in the :ref:`setuptools` docs, but note
 that some advisory content there may be outdated. In the event of
 conflicts, prefer the advice in the Python Packaging User Guide.
 
-.. contents:: Contents
-   :local:
 
 
 Requirements for packaging and distributing
diff --git a/source/guides/index-mirrors-and-caches.rst b/source/guides/index-mirrors-and-caches.rst
index c186b64a9..9fdea0a1d 100644
--- a/source/guides/index-mirrors-and-caches.rst
+++ b/source/guides/index-mirrors-and-caches.rst
@@ -7,9 +7,6 @@ Package index mirrors and caches
 :Page Status: Incomplete
 :Last Reviewed: 2014-12-24
 
-.. contents:: Contents
-   :local:
-
 
 Mirroring or caching of PyPI can be used to speed up local package installation,
 allow offline work, handle corporate firewalls or just plain Internet flakiness.
diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst
index 404fed83b..5677d382a 100644
--- a/source/guides/installing-scientific-packages.rst
+++ b/source/guides/installing-scientific-packages.rst
@@ -4,9 +4,6 @@
 Installing scientific packages
 ==============================
 
-.. contents:: Contents
-   :local:
-
 
 Scientific software tends to have more complex dependencies than most, and
 it will often have multiple build options to take advantage of different
diff --git a/source/guides/installing-using-linux-tools.rst b/source/guides/installing-using-linux-tools.rst
index 8c1fd3f00..b3d37675f 100644
--- a/source/guides/installing-using-linux-tools.rst
+++ b/source/guides/installing-using-linux-tools.rst
@@ -7,9 +7,6 @@ Installing pip/setuptools/wheel with Linux Package Managers
 :Page Status: Incomplete
 :Last Reviewed: 2021-07-26
 
-.. contents:: Contents
-  :local:
-
 This section covers how to install :ref:`pip`, :ref:`setuptools`, and
 :ref:`wheel` using Linux package managers.
 
diff --git a/source/guides/packaging-binary-extensions.rst b/source/guides/packaging-binary-extensions.rst
index 73f25fc03..589ed89c8 100644
--- a/source/guides/packaging-binary-extensions.rst
+++ b/source/guides/packaging-binary-extensions.rst
@@ -13,8 +13,6 @@ C API for use by other software. One of the most common uses of this C API
 is to create importable C extensions that allow things which aren't
 always easy to achieve in pure Python code.
 
-.. contents:: Contents
-   :local:
 
 An overview of binary extensions
 ================================
diff --git a/source/guides/supporting-multiple-python-versions.rst b/source/guides/supporting-multiple-python-versions.rst
index 0471a1f2f..8c128ed91 100644
--- a/source/guides/supporting-multiple-python-versions.rst
+++ b/source/guides/supporting-multiple-python-versions.rst
@@ -9,9 +9,6 @@ Supporting multiple Python versions
 :Page Status: Obsolete
 :Last Reviewed: 2014-12-24
 
-.. contents:: Contents
-   :local:
-
 
 ::
 
diff --git a/source/guides/supporting-windows-using-appveyor.rst b/source/guides/supporting-windows-using-appveyor.rst
index 1f43c443b..0044d8c5e 100644
--- a/source/guides/supporting-windows-using-appveyor.rst
+++ b/source/guides/supporting-windows-using-appveyor.rst
@@ -12,9 +12,6 @@ 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.
 
-.. contents:: Contents
-   :local:
-
 
 Background
 ==========
diff --git a/source/overview.rst b/source/overview.rst
index 2f3f44007..0bd4393db 100644
--- a/source/overview.rst
+++ b/source/overview.rst
@@ -19,9 +19,6 @@ This overview provides a general-purpose decision tree for reasoning
 about Python's plethora of packaging options. Read on to choose the best
 technology for your next project.
 
-.. contents:: Contents
-   :local:
-
 Thinking about deployment
 -------------------------
 
diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index cefd68950..1099bb685 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -37,8 +37,6 @@ to a new format.
    more relaxed formatting rules even for metadata files that are nominally
    less than version 2.1.
 
-.. contents:: Contents
-   :local:
 
 .. _core-metadata-metadata-version:
 
diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index eae9d3071..fe1eae008 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -13,8 +13,6 @@ The representation of the components of this data structure as a :rfc:`1738` URL
 is not formally specified at time of writing. A common representation is the pip URL
 format. Other examples are provided in :pep:`440`.
 
-.. contents:: Contents
-   :local:
 
 Specification
 =============
diff --git a/source/specifications/direct-url.rst b/source/specifications/direct-url.rst
index aa9a48e9b..5c0bd1b21 100644
--- a/source/specifications/direct-url.rst
+++ b/source/specifications/direct-url.rst
@@ -10,8 +10,6 @@ This document specifies a :file:`direct_url.json` file in the
 Direct URL Origin of the distribution. The general structure and usage of
 ``*.dist-info`` directories is described in :ref:`recording-installed-packages`.
 
-.. contents:: Contents
-   :local:
 
 Specification
 =============
diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst
index 46957f93b..4cfcf3f3e 100644
--- a/source/tutorials/installing-packages.rst
+++ b/source/tutorials/installing-packages.rst
@@ -18,10 +18,6 @@ confused with a Linux distribution, or another larger software distribution
 like Python itself.
 
 
-.. contents:: Contents
-   :local:
-
-
 .. _installing_requirements:
 
 Requirements for Installing Packages

From 1415c8dae4485dae3cc4bd434b8a36d81db838ed Mon Sep 17 00:00:00 2001
From: sinoroc 
Date: Thu, 2 Nov 2023 15:40:39 +0100
Subject: [PATCH 0465/1072] Add discussion "Is setup.py deprecated?"

---
 source/discussions/index.rst               |   1 +
 source/discussions/setup-py-deprecated.rst | 149 +++++++++++++++++++++
 2 files changed, 150 insertions(+)
 create mode 100644 source/discussions/setup-py-deprecated.rst

diff --git a/source/discussions/index.rst b/source/discussions/index.rst
index bc1154507..e5411ece3 100644
--- a/source/discussions/index.rst
+++ b/source/discussions/index.rst
@@ -13,3 +13,4 @@ specific topic. If you're just trying to get stuff done, see
    install-requires-vs-requirements
    wheel-vs-egg
    src-layout-vs-flat-layout
+   setup-py-deprecated
diff --git a/source/discussions/setup-py-deprecated.rst b/source/discussions/setup-py-deprecated.rst
new file mode 100644
index 000000000..29eac241d
--- /dev/null
+++ b/source/discussions/setup-py-deprecated.rst
@@ -0,0 +1,149 @@
+.. _setup-py-deprecated:
+
+
+===========================
+Is ``setup.py`` deprecated?
+===========================
+
+No, :term:`setup.py` is not deprecated,
+it is a valid configuration file for :ref:`setuptools`
+that happens to be written in Python, instead of in *TOML* for example
+(a similar practice is used by other tools
+like *nox* and its :file:`nox.py` configuration file,
+or *pytest* and :file:`conftest.py`).
+
+And of course *setuptools* itself is not deprecated either.
+
+It is however deprecated to run ``python setup.py`` as a command line tool.
+
+This means for example that the following commands **MUST NOT** be run anymore:
+
+* ``python setup.py install``
+* ``python setup.py develop``
+* ``python setup.py sdist``
+* ``python setup.py bdist_wheel``
+
+
+What commands should be used instead?
+=====================================
+
++---------------------------------+----------------------------------------+
+| Deprecated                      | Current recommendation                 |
++=================================+========================================+
+| ``python setup.py install``     | ``python -m pip install .``            |
++---------------------------------+----------------------------------------+
+| ``python setup.py develop``     | ``python -m pip install --editable .`` |
++---------------------------------+----------------------------------------+
+| ``python setup.py sdist``       | ``python -m build`` [#needs-build]_    |
++---------------------------------+                                        |
+| ``python setup.py bdist_wheel`` |                                        |
++---------------------------------+----------------------------------------+
+
+
+.. [#needs-build] This requires the :ref:`build` dependency.
+    It is recommended to always build and publish both the source distribution
+    and wheel of a project, which is what ``python -m build`` does.
+    If necessary the ``--sdist`` and ``--wheel`` options can be used
+    to generate only one or the other.
+
+
+In order to install a setuptools based project,
+it was common to run :file:`setup.py`'s ``install`` command such as:
+``python setup.py install``.
+Nowadays, the recommended method is to use :ref:`pip` directly
+with a command like this one: ``python -m pip install .``.
+Where the dot ``.`` is actually a file system path,
+it is the path notation for the current directory.
+Indeed, *pip* accepts a path to
+a project's source tree directory on the local filesystem
+as argument to its ``install`` sub-command.
+So this would also be a valid command:
+``python -m pip install path/to/project``.
+
+As for the installation in *develop* mode aka *editable* mode,
+instead of ``python setup.py develop``
+one can use the ``--editable`` option of pip's *install* sub-command:
+``python -m pip install --editable .``.
+
+One recommended, simple, and straightforward method of building
+:term:`source distributions `
+and :term:`wheels `
+is to use the :ref:`build` tool with a command like
+``python -m build``
+which triggers the generation of both distribution formats.
+If necessary the ``--sdist`` and ``--wheel`` options can be used
+to generate only one or the other.
+Note that the build tool needs to be installed separately.
+
+The command ``python setup.py install`` was deprecated
+in setuptools version *58.3.0*.
+
+
+What about custom commands?
+===========================
+
+Likewise, custom :file:`setup.py` commands are deprecated.
+The recommendation is to migrate those custom commands
+to a task runner tool or any other similar tool.
+Some examples of such tools are:
+chuy, make, nox or tox, pydoit, pyinvoke, taskipy, and thx.
+
+
+What about custom build steps?
+==============================
+
+Custom build steps that for example
+either overwrite existing steps such as ``build_py``, ``build_ext``, and ``bdist_wheel``
+or add new build steps are not deprecated.
+Those will be automatically called as expected.
+
+
+Should ``setup.py`` be deleted?
+===============================
+
+Although the usage of :file:`setup.py` as an executable script is deprecated,
+its usage as a configuration file for setuptools is absolutely fine.
+There is likely no modification needed in :file:`setup.py`.
+
+.. todo::
+
+    Link to a "How to modernize a setup.py based project?"
+
+
+Is ``pyproject.toml`` mandatory?
+================================
+
+While it is not technically necessary yet,
+it is **STRONGLY RECOMMENDED** for a project to have a :file:`pyproject.toml` file
+at the root of its source tree with a content like this:
+
+.. code:: toml
+
+    [build-system]
+    requires = ["setuptools"]
+    build-backend = "setuptools.build_meta"
+
+
+.. todo::
+
+    Link to "How to modernize a setup.py based project?"
+
+
+The standard fallback behavior for a :term:`build frontend `
+in the absence of a :file:`pyproject.toml` file and its ``[build-system]`` table
+is to assume that the :term:`build backend ` is setuptools.
+
+
+Why? What does it all mean?
+===========================
+
+One way to look at it is that the scope of setuptools
+has now been reduced to the role of a build backend.
+
+
+Where to read more about this?
+==============================
+
+* https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html
+
+* :doc:`setuptools:deprecated/commands`

From b16b99a3f8595361aacd5341af12a18e6c057040 Mon Sep 17 00:00:00 2001
From: Pradyun Gedam 
Date: Mon, 6 Nov 2023 22:31:46 +0000
Subject: [PATCH 0466/1072] Use a favicon instead of a logo

---
 source/conf.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/conf.py b/source/conf.py
index a55343737..b3e4d1bd3 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -175,13 +175,13 @@
 # The name of an image file (relative to this directory) to place at the top
 # of the sidebar.
 #
-html_logo = 'assets/py.png'
+# html_logo = None
 
 # The name of an image file (relative to this directory) to use as a favicon of
 # the docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
 # pixels large.
 #
-# html_favicon = None
+html_favicon = 'assets/py.png'
 
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,

From 3d5a5ef36753d7bc609a2550c2300d965a8d1bdd Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Tue, 7 Nov 2023 19:40:53 +0100
Subject: [PATCH 0467/1072] Allow Sphinx to do incremental builds

Fixes #1363
---
 noxfile.py | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/noxfile.py b/noxfile.py
index b5d994701..b0ade2c49 100644
--- a/noxfile.py
+++ b/noxfile.py
@@ -33,10 +33,6 @@ def build(session, autobuild=False):
     """
     session.install("-r", "requirements.txt")
 
-    target_build_dir = "build"
-
-    shutil.rmtree(target_build_dir, ignore_errors=True)
-
     if autobuild:
         command = "sphinx-autobuild"
         extra_args = "--host", "0.0.0.0"
@@ -56,7 +52,7 @@ def build(session, autobuild=False):
         "-W",  # Treat warnings as errors.
         *session.posargs,
         "source",  # where the rst files are located
-        target_build_dir,  # where to put the html output
+        "build",  # where to put the html output
     )
 
 

From 5020425702336030ad7c4b975b7843d27f4ab7c1 Mon Sep 17 00:00:00 2001
From: Pradyun Gedam 
Date: Tue, 7 Nov 2023 21:35:18 +0000
Subject: [PATCH 0468/1072] Use a shared cache directory for Sphinx builds
 across nox sessions

This enables incremental build with Sphinx.
---
 noxfile.py | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/noxfile.py b/noxfile.py
index b5d994701..83f890262 100644
--- a/noxfile.py
+++ b/noxfile.py
@@ -4,8 +4,8 @@
 #   http://creativecommons.org/licenses/by-sa/3.0.
 
 import shutil
-import nox
 
+import nox
 
 nox.options.sessions = []
 
@@ -20,7 +20,7 @@ def translation(session):
     session.run(
         "sphinx-build",
         "-b", "gettext",  # build gettext-style message catalogs (.pot file)
-        "-d", ".nox/.doctrees/", # path to put the cache
+        "-d", session.cache_dir / ".doctrees", # path to put the cache
         "source/",  # where the rst files are located
         target_dir, # where to put the .pot file
     )
@@ -52,6 +52,7 @@ def build(session, autobuild=False):
         command, *extra_args,
         "-j", "auto",  # parallelize the build
         "-b", "html",  # use HTML builder
+        "-d", session.cache_dir / ".doctrees", # path to put the cache
         "-n",  # nitpicky warn about all missing references
         "-W",  # Treat warnings as errors.
         *session.posargs,
@@ -78,6 +79,7 @@ def linkcheck(session):
     session.run(
         "sphinx-build",
         "-b", "linkcheck", # use linkcheck builder
+        "-d", session.cache_dir / ".doctrees", # path to put the cache
         "--color",
         "-n", "-W", "--keep-going",  # be strict
         "source", # where the rst files are located

From 233bb5138e75acf180c19d20167e7c355ca1d47f Mon Sep 17 00:00:00 2001
From: Laurie O 
Date: Wed, 8 Nov 2023 15:32:18 +1000
Subject: [PATCH 0469/1072] Add more package index projects

---
 source/guides/hosting-your-own-index.rst   |  71 +++++++++++
 source/guides/index-mirrors-and-caches.rst | 118 +++++++++++++-----
 source/key_projects.rst                    | 135 ++++++++++++++++++++-
 3 files changed, 291 insertions(+), 33 deletions(-)

diff --git a/source/guides/hosting-your-own-index.rst b/source/guides/hosting-your-own-index.rst
index 26ffe2b8c..f469c2a2e 100644
--- a/source/guides/hosting-your-own-index.rst
+++ b/source/guides/hosting-your-own-index.rst
@@ -52,10 +52,81 @@ directory with autoindex enabled. For an example using the built in Web server
 in `Twisted`_, you would simply run ``twistd -n web --path .`` and then
 instruct users to add the URL to their installer's configuration.
 
+
+Existing projects
+=================
+
+.. list-table::
+   :header-rows: 1
+
+   * - Project
+     - Package upload
+     - PyPI fall-through [2]_
+     - Additional notes
+
+   * - :ref:`devpi`
+     - ✔
+     - ✔
+     - multiple indexes with inheritance, with syncing, replication, fail-over;
+       mirroring
+
+   * - :ref:`simpleindex`
+     -
+     - ✔
+     -
+
+   * - :ref:`pypiserver`
+     - ✔
+     -
+     -
+
+   * - :ref:`pypiprivate`
+     -
+     -
+     -
+
+   * - :ref:`pypicloud`
+     -
+     -
+     - unmaintained; also cached proxying; authentication, authorisation
+
+   * - :ref:`pywharf`
+     -
+     -
+     - unmaintained; serve files in GitHub
+
+   * - :ref:`pulppython`
+     - ✔
+     -
+     - also mirroring, proxying; plugin for Pulp
+
+   * - :ref:`pip2pi`
+     -
+     -
+     - also mirroring; manual synchronisation
+
+   * - :ref:`httpserver`
+     -
+     -
+     - standard-library
+
+   * - `Apache `_
+     -
+     - ✔
+     - using
+       `mod_rewrite
+       `_
+       and
+       `mod_cache_disk
+       `_,
+       you can cache requests to package indexes through an Apache server
+
 ----
 
 .. [1] For complete documentation of the simple repository protocol, see
        :ref:`simple repository API `.
 
+.. [2] Can be configured to fall-back to PyPI (or another package index)
+       if a requested package is missing.
 
 .. _Twisted: https://twistedmatrix.com/
diff --git a/source/guides/index-mirrors-and-caches.rst b/source/guides/index-mirrors-and-caches.rst
index 9fdea0a1d..f3b7bd243 100644
--- a/source/guides/index-mirrors-and-caches.rst
+++ b/source/guides/index-mirrors-and-caches.rst
@@ -5,19 +5,24 @@ Package index mirrors and caches
 ================================
 
 :Page Status: Incomplete
-:Last Reviewed: 2014-12-24
+:Last Reviewed: 2023-11-08
 
-
-Mirroring or caching of PyPI can be used to speed up local package installation,
+Mirroring or caching of PyPI (and other
+:term:`package indexes `) can be used to speed up local
+package installation,
 allow offline work, handle corporate firewalls or just plain Internet flakiness.
 
-Three options are available in this area:
+There are multiple classes of options in this area:
+
+1. local/hosted caching of package indexes.
+
+2. local/hosted mirroring of a package index. A mirror is a (whole or
+   partial) copy of a package index, which can be used in place of the
+   original index.
 
-1. pip provides local caching options,
-2. devpi provides higher-level caching option, potentially shared amongst
-   many users or machines, and
-3. bandersnatch provides a local complete mirror of all PyPI :term:`packages
-   `.
+3. private package index with fall-through to public package indexes (for
+   example, to mitigate dependency confusion attacks), also known as a
+   proxy.
 
 
 Caching with pip
@@ -38,26 +43,75 @@ cached copies of :term:`packages `:
       python3 -m pip install --no-index --find-links=/tmp/wheelhouse SomeProject
 
 
-Caching with devpi
-------------------
-
-devpi is a caching proxy server which you run on your laptop, or some other
-machine you know will always be available to you. See the `devpi
-documentation for getting started`__.
-
-__ https://devpi.net/docs/devpi/devpi/latest/+d/quickstart-pypimirror.html
-
-
-Complete mirror with bandersnatch
-----------------------------------
-
-bandersnatch will set up a complete local mirror of all PyPI :term:`packages
-` (externally-hosted packages are not mirrored). See
-the `bandersnatch documentation for getting that going`__.
-
-__ https://github.com/pypa/bandersnatch/
-
-A benefit of devpi is that it will create a mirror which includes
-:term:`packages ` that are external to PyPI, unlike
-bandersnatch which will only cache :term:`packages `
-hosted on PyPI.
+Existing projects
+-----------------
+
+.. list-table::
+   :header-rows: 1
+
+   * - Project
+     - Cache
+     - Mirror
+     - Proxy
+     - Additional notes
+
+   * - :ref:`devpi`
+     - ✔
+     - ✔
+     -
+     - multiple indexes with inheritance; syncing, replication, fail-over;
+       package upload
+
+   * - :ref:`bandersnatch`
+     - ✔
+     - ✔
+     -
+     -
+
+   * - :ref:`simpleindex`
+     -
+     -
+     - ✔
+     - custom plugin enables caching; re-routing to other package indexes
+
+   * - :ref:`pypicloud`
+     - ✔
+     -
+     - ✔
+     - unmaintained; authentication, authorisation
+
+   * - :ref:`pulppython`
+     -
+     - ✔
+     - ✔
+     - plugin for Pulp; multiple proxied indexes; package upload
+
+   * - :ref:`proxpi`
+     - ✔
+     -
+     - ✔
+     - multiple proxied indexes
+
+   * - :ref:`nginx_pypi_cache`
+     - ✔
+     -
+     - ✔
+     - multiple proxied indexes
+
+   * - :ref:`flaskpypiproxy`
+     - ✔
+     -
+     - ✔
+     - unmaintained
+
+   * - `Apache `_
+     - ✔
+     -
+     - ✔
+     - using
+       `mod_rewrite
+       `_
+       and
+       `mod_cache_disk
+       `_,
+       you can cache requests to package indexes through an Apache server
diff --git a/source/key_projects.rst b/source/key_projects.rst
index ea5730683..b386a8f2d 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -18,6 +18,7 @@ PyPA Projects
 bandersnatch
 ============
 
+`Docs `__ |
 `Issues `__ |
 `GitHub `__ |
 `PyPI `__
@@ -27,6 +28,7 @@ create a complete mirror of the contents of PyPI. Organizations thus
 save bandwidth and latency on package downloads (especially in the
 context of automated tests) and to prevent heavily loading PyPI's
 Content Delivery Network (CDN).
+Files can be served from a local directory or `AWS S3`_.
 
 
 .. _build:
@@ -442,6 +444,9 @@ devpi features a powerful PyPI-compatible server and PyPI proxy cache
 with a complementary command line tool to drive packaging, testing and
 release activities with Python. devpi also provides a browsable and
 searchable web interface.
+devpi supports mirroring PyPI, multiple
+:term:`package indexes ` with inheritance, syncing between
+these indexes, index replication and fail-over, and package upload.
 
 .. _enscons:
 
@@ -464,6 +469,20 @@ enscons.
 
 .. _SCons: https://scons.org/
 
+.. _flaskpypiproxy:
+
+Flask-Pypi-Proxy
+================
+
+`Docs `__ |
+:gh:`GitHub ` |
+`PyPI `__
+
+.. warning:: Not maintained, project archived
+
+Flask-Pypi-Proxy is a :term:`package index ` as a cached
+proxy for PyPI.
+
 .. _hashdist:
 
 Hashdist
@@ -519,6 +538,16 @@ multibuild
 Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for
 Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`.
 
+.. _nginx_pypi_cache:
+
+nginx_pypi_cache
+================
+
+:gh:`GitHub `
+
+nginx_pypi_cache is a :term:`package index ` caching proxy
+using `nginx `_.
+
 .. _pdm:
 
 pdm
@@ -564,6 +593,17 @@ requirements from information in other parts of their program, update
 all dependencies (a feature :ref:`pip` currently does not provide), and
 create layers of constraints for the program to obey.
 
+.. _pip2pi:
+
+pip2pi
+=========
+
+:gh:`GitHub ` |
+`PyPI `__
+
+pip2pi is a :term:`package index ` server where specific
+packages are manually synchronised.
+
 .. _piwheels:
 
 piwheels
@@ -595,6 +635,58 @@ functionality within :ref:`pip`, provides its own dependency resolver.
 It attempts to speed users' experience of installation and dependency
 resolution by locally caching metadata about dependencies.
 
+.. _proxpi:
+
+proxpi
+======
+
+:gh:`GitHub ` |
+`PyPI `__
+
+proxpi is a simple :term:`package index ` which proxies PyPI
+and other indexes with caching.
+
+.. _pulppython:
+
+Pulp-python
+===========
+
+`Docs `__ |
+:gh:`GitHub ` |
+`PyPI `__
+
+Pulp-python is the Python :term:`package index ` plugin for
+`Pulp `_. Pulp-python supports mirrors backed by
+local or `AWS S3`_, package upload, and proxying to multiple package
+indexes.
+
+.. _pypicloud:
+
+PyPI Cloud
+==========
+
+`Docs `__ |
+:gh:`GitHub ` |
+`PyPI `__
+
+.. warning:: Not maintained, project archived
+
+PyPI Cloud is a :term:`package index ` server, backed by
+`AWS S3`_ or another cloud storage service, or local files. PyPI Cloud
+supports redirect/cached proxying for PyPI, as well as authentication and
+authorisation.
+
+.. _pypiprivate:
+
+pypiprivate
+===========
+
+:gh:`GitHub ` |
+`PyPI `__
+
+pypiprivate serves a local (or `AWS S3`_-hosted) directory of packages as a
+:term:`package index `.
+
 .. _pypiserver:
 
 pypiserver
@@ -604,7 +696,8 @@ pypiserver
 `PyPI `__
 
 pypiserver is a minimalist application that serves as a private Python
-package index within organizations, implementing a simple API and
+:term:`package index ` (from a local directory) within
+organizations, implementing a simple API and
 browser interface. You can upload private packages using standard
 upload tools, and users can download and install them with :ref:`pip`,
 without publishing them publicly. Organizations who use pypiserver
@@ -627,6 +720,18 @@ environment so developers can start coding right away.
 PyScaffold can also be used with existing projects to make packaging
 easier.
 
+.. _pywharf:
+
+pywharf
+=======
+
+:gh:`GitHub ` |
+`PyPI `__
+
+.. warning:: Not maintained, project archived
+
+pywharf is a :term:`package index ` server, serving files
+locally or from `GitHub `_.
 
 .. _scikit-build:
 
@@ -675,6 +780,19 @@ Python zipapps as outlined in :pep:`441`, but with all their
 dependencies included. Its primary goal is making distributing Python
 applications and command line tools fast & easy.
 
+.. _simpleindex:
+
+simpleindex
+===========
+
+:gh:`GitHub ` |
+`PyPI `__
+
+simpleindex is a :term:`package index ` which routes URLs to
+multiple package indexes (including PyPI), serves local (or cloud-hosted,
+for example `AWS S3`_, with a custom plugin) directory of packages, and
+supports custom plugins.
+
 .. _spack:
 
 Spack
@@ -727,6 +845,20 @@ A package in the Python Standard Library that provides support for bootstrapping
 cases, end users won't use this module, but rather it will be used during the
 build of the Python distribution.
 
+.. _httpserver:
+
+http.server
+===========
+
+`Docs `__ |
+`Issues `__
+
+A package and command-line interface which can host a directory as a
+website, for example as a :term:`package index ` (see
+:ref:`Hosting your Own Simple Repository`).
+A package in the Python Standard Library (starting with Python 3.3) for
+creating :term:`Virtual Environments `.  For more
+information, see the section on :ref:`Creating and using Virtual Environments`.
 
 .. _venv:
 
@@ -746,3 +878,4 @@ information, see the section on :ref:`Creating and using Virtual Environments`.
 .. _distribute: https://pypi.org/project/distribute
 .. _Sphinx: https://www.sphinx-doc.org/en/master/
 .. _pytest: https://docs.pytest.org/en/stable/
+.. _`AWS S3`: https://aws.amazon.com/s3/

From 1afb5966a89cc8817117507f1bc0f76f9b3332ba Mon Sep 17 00:00:00 2001
From: Pradyun Gedam 
Date: Mon, 6 Nov 2023 22:34:28 +0000
Subject: [PATCH 0470/1072] Bump pre-commit-hooks

---
 .pre-commit-config.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index 4c70a3f63..b517864da 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -1,6 +1,6 @@
 repos:
 - repo: https://github.com/pre-commit/pre-commit-hooks
-  rev: v4.4.0
+  rev: v4.5.0
   hooks:
   - id: check-added-large-files
   - id: check-case-conflict

From 07a8f01521ed1e4938eb5e62a4457f503d92f1b3 Mon Sep 17 00:00:00 2001
From: Pradyun Gedam 
Date: Wed, 8 Nov 2023 18:21:54 +0000
Subject: [PATCH 0471/1072] Add ruff as a linter

---
 .pre-commit-config.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index b517864da..88494c690 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -31,3 +31,9 @@ repos:
   - id: rst-backticks
   - id: rst-directive-colons
   - id: rst-inline-touching-normal
+
+- repo: https://github.com/astral-sh/ruff-pre-commit
+  rev: v0.1.4
+  hooks:
+    - id: ruff
+    - id: ruff-format

From 1d7b1abd152e4cb5e6a46e52e6b7e3bf8d366486 Mon Sep 17 00:00:00 2001
From: Pradyun Gedam 
Date: Wed, 8 Nov 2023 18:22:03 +0000
Subject: [PATCH 0472/1072] Reformat Python code with ruff

---
 noxfile.py     |  35 +++++----
 source/conf.py | 193 +++++++++++++++++++++++++------------------------
 2 files changed, 122 insertions(+), 106 deletions(-)

diff --git a/noxfile.py b/noxfile.py
index 23dcb977f..698e82f9d 100644
--- a/noxfile.py
+++ b/noxfile.py
@@ -3,7 +3,6 @@
 # Attribution-ShareAlike license:
 #   http://creativecommons.org/licenses/by-sa/3.0.
 
-import shutil
 
 import nox
 
@@ -19,10 +18,12 @@ def translation(session):
     target_dir = "locales"
     session.run(
         "sphinx-build",
-        "-b", "gettext",  # build gettext-style message catalogs (.pot file)
-        "-d", session.cache_dir / ".doctrees", # path to put the cache
+        "-b",
+        "gettext",  # build gettext-style message catalogs (.pot file)
+        "-d",
+        session.cache_dir / ".doctrees",  # path to put the cache
         "source/",  # where the rst files are located
-        target_dir, # where to put the .pot file
+        target_dir,  # where to put the .pot file
     )
 
 
@@ -45,10 +46,14 @@ def build(session, autobuild=False):
         )
 
     session.run(
-        command, *extra_args,
-        "-j", "auto",  # parallelize the build
-        "-b", "html",  # use HTML builder
-        "-d", session.cache_dir / ".doctrees", # path to put the cache
+        command,
+        *extra_args,
+        "-j",
+        "auto",  # parallelize the build
+        "-b",
+        "html",  # use HTML builder
+        "-d",
+        session.cache_dir / ".doctrees",  # path to put the cache
         "-n",  # nitpicky warn about all missing references
         "-W",  # Treat warnings as errors.
         *session.posargs,
@@ -74,12 +79,16 @@ def linkcheck(session):
     session.install("-r", "requirements.txt")
     session.run(
         "sphinx-build",
-        "-b", "linkcheck", # use linkcheck builder
-        "-d", session.cache_dir / ".doctrees", # path to put the cache
+        "-b",
+        "linkcheck",  # use linkcheck builder
+        "-d",
+        session.cache_dir / ".doctrees",  # path to put the cache
         "--color",
-        "-n", "-W", "--keep-going",  # be strict
-        "source", # where the rst files are located
-        "build", # where to put the check output
+        "-n",
+        "-W",
+        "--keep-going",  # be strict
+        "source",  # where the rst files are located
+        "build",  # where to put the check output
     )
 
 
diff --git a/source/conf.py b/source/conf.py
index b3e4d1bd3..64b99d0b2 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -31,12 +31,12 @@
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
 # ones.
 extensions = [
-    'sphinx.ext.extlinks',
-    'sphinx.ext.intersphinx',
-    'sphinx.ext.todo',
-    'sphinx_inline_tabs',
-    'sphinx_copybutton',
-    'sphinx_toolbox.collapse',
+    "sphinx.ext.extlinks",
+    "sphinx.ext.intersphinx",
+    "sphinx.ext.todo",
+    "sphinx_inline_tabs",
+    "sphinx_copybutton",
+    "sphinx_toolbox.collapse",
 ]
 
 # config for copy button
@@ -44,53 +44,53 @@
 copybutton_prompt_is_regexp = True
 
 # Add any paths that contain templates here, relative to this directory.
-templates_path = ['_templates']
+templates_path = ["_templates"]
 
 # The suffix(es) of source filenames.
 # You can specify multiple suffix as a list of string:
 #
 # source_suffix = ['.rst', '.md']
-source_suffix = '.rst'
+source_suffix = ".rst"
 
 # The encoding of source files.
 #
 # source_encoding = 'utf-8-sig'
 
 # The master toctree document.
-master_doc = 'index'
+master_doc = "index"
 
 # -- Project information -----------------------------------------------------
 
-github_url = 'https://github.com'
-github_repo_org = 'pypa'
-github_repo_name = 'packaging.python.org'
-github_repo_slug = f'{github_repo_org}/{github_repo_name}'
-github_repo_url = f'{github_url}/{github_repo_slug}'
-github_repo_issues_url = f'{github_url}/{github_repo_slug}/issues'
-github_sponsors_url = f'{github_url}/sponsors'
+github_url = "https://github.com"
+github_repo_org = "pypa"
+github_repo_name = "packaging.python.org"
+github_repo_slug = f"{github_repo_org}/{github_repo_name}"
+github_repo_url = f"{github_url}/{github_repo_slug}"
+github_repo_issues_url = f"{github_url}/{github_repo_slug}/issues"
+github_sponsors_url = f"{github_url}/sponsors"
 
 # General information about the project.
-project = u'Python Packaging User Guide'
-copyright = u'2013–2020, PyPA'
-author = 'Python Packaging Authority'
+project = "Python Packaging User Guide"
+copyright = "2013–2020, PyPA"
+author = "Python Packaging Authority"
 
 # The version info for the project you're documenting, acts as replacement for
 # |version| and |release|, also used in various other places throughout the
 # built documents.
 #
 # The short X.Y version.
-version = ''
+version = ""
 # The full version, including alpha/beta/rc tags.
-release = ''
+release = ""
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.
 #
 # This is also used if you do content translation via gettext catalogs.
 # Usually you set "language" from the command line for these cases.
-language = 'en'
+language = "en"
 
-locale_dirs = ['../locales']
+locale_dirs = ["../locales"]
 
 gettext_auto_build = True  # Build MO files from PO on each build
 
@@ -111,12 +111,12 @@
 # List of patterns, relative to source directory, that match files and
 # directories to ignore when looking for source files.
 # This patterns also effect to html_static_path and html_extra_path
-exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
+exclude_patterns = ["_build", "Thumbs.db", ".DS_Store"]
 
 # The reST default role (used for this markup: `text`) to use for all
 # documents.
 # Ref: python-attrs/attrs#571
-default_role = 'any'  # makes single backticks autofind targets
+default_role = "any"  # makes single backticks autofind targets
 
 # If true, '()' will be appended to :func: etc. cross-reference text.
 #
@@ -133,7 +133,7 @@
 # show_authors = False
 
 # The name of the Pygments (syntax highlighting) style to use.
-#pygments_style = 'sphinx'
+# pygments_style = 'sphinx'
 
 # A list of ignored prefixes for module index sorting.
 # modindex_common_prefix = []
@@ -150,7 +150,7 @@
 # The theme to use for HTML and HTML Help pages.  See the documentation for
 # a list of builtin themes.
 #
-html_theme = 'furo'
+html_theme = "furo"
 
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the
@@ -166,7 +166,7 @@
 # The name for this set of Sphinx documents.
 # " v documentation" by default.
 #
-html_title = 'Python Packaging User Guide'
+html_title = "Python Packaging User Guide"
 
 # A shorter title for the navigation bar.  Default is the same as html_title.
 #
@@ -181,7 +181,7 @@
 # the docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
 # pixels large.
 #
-html_favicon = 'assets/py.png'
+html_favicon = "assets/py.png"
 
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,
@@ -198,7 +198,7 @@
 # bottom, using the given strftime format.
 # The empty string is equivalent to '%b %d, %Y'.
 #
-html_last_updated_fmt = ''
+html_last_updated_fmt = ""
 
 # If true, SmartyPants will be used to convert quotes and dashes to
 # typographically correct entities.
@@ -271,34 +271,36 @@
 # html_search_scorer = 'scorer.js'
 
 # Output file base name for HTML help builder.
-htmlhelp_basename = 'pythonpackagingguide-authdoc'
+htmlhelp_basename = "pythonpackagingguide-authdoc"
 
 # -- Options for LaTeX output ---------------------------------------------
 
 latex_elements = {
-     # The paper size ('letterpaper' or 'a4paper').
-     #
-     # 'papersize': 'letterpaper',
-
-     # The font size ('10pt', '11pt' or '12pt').
-     #
-     # 'pointsize': '10pt',
-
-     # Additional stuff for the LaTeX preamble.
-     #
-     # 'preamble': '',
-
-     # Latex figure (float) alignment
-     #
-     # 'figure_align': 'htbp',
+    # The paper size ('letterpaper' or 'a4paper').
+    #
+    # 'papersize': 'letterpaper',
+    # The font size ('10pt', '11pt' or '12pt').
+    #
+    # 'pointsize': '10pt',
+    # Additional stuff for the LaTeX preamble.
+    #
+    # 'preamble': '',
+    # Latex figure (float) alignment
+    #
+    # 'figure_align': 'htbp',
 }
 
 # Grouping the document tree into LaTeX files. List of tuples
 # (source start file, target name, title,
 #  author, documentclass [howto, manual, or own class]).
 latex_documents = [
-    (master_doc, 'pythonpackagingguide.tex', 'Python Packaging User Guide',
-     'Python Packaging Authority', 'manual'),
+    (
+        master_doc,
+        "pythonpackagingguide.tex",
+        "Python Packaging User Guide",
+        "Python Packaging Authority",
+        "manual",
+    ),
 ]
 
 # The name of an image file (relative to this directory) to place at the top of
@@ -339,8 +341,7 @@
 # One entry per manual page. List of tuples
 # (source start file, name, description, authors, manual section).
 man_pages = [
-    (master_doc, 'pythonpackagingguide', 'Python Packaging User Guide',
-     [author], 1)
+    (master_doc, "pythonpackagingguide", "Python Packaging User Guide", [author], 1)
 ]
 
 # If true, show URL addresses after external links.
@@ -354,9 +355,15 @@
 # (source start file, target name, title, author,
 #  dir menu entry, description, category)
 texinfo_documents = [
-    (master_doc, 'pythonpackagingguide', 'Python Packaging User Guide',
-     author, 'pythonpackagingguide', 'One line description of project.',
-     'Miscellaneous'),
+    (
+        master_doc,
+        "pythonpackagingguide",
+        "Python Packaging User Guide",
+        author,
+        "pythonpackagingguide",
+        "One line description of project.",
+        "Miscellaneous",
+    ),
 ]
 
 # Documents to append as an appendix to all manuals.
@@ -377,11 +384,11 @@
 
 # -- Options for extlinks extension ---------------------------------------
 extlinks = {
-    'issue': (f'{github_repo_issues_url}/%s', '#%s'),  # noqa: WPS323
-    'pr': (f'{github_repo_url}/pull/%s', 'PR #%s'),  # noqa: WPS323
-    'commit': (f'{github_repo_url}/commit/%s', '%s'),  # noqa: WPS323
-    'gh': (f'{github_url}/%s', 'GitHub: %s'),  # noqa: WPS323
-    'user': (f'{github_sponsors_url}/%s', '@%s'),  # noqa: WPS323
+    "issue": (f"{github_repo_issues_url}/%s", "#%s"),  # noqa: WPS323
+    "pr": (f"{github_repo_url}/pull/%s", "PR #%s"),  # noqa: WPS323
+    "commit": (f"{github_repo_url}/commit/%s", "%s"),  # noqa: WPS323
+    "gh": (f"{github_url}/%s", "GitHub: %s"),  # noqa: WPS323
+    "user": (f"{github_sponsors_url}/%s", "@%s"),  # noqa: WPS323
 }
 
 linkcheck_ignore = [
@@ -395,33 +402,33 @@
 
 # Example configuration for intersphinx: refer to the Python standard library.
 intersphinx_mapping = {
-    'boltons': ('https://boltons.readthedocs.io/en/latest/', None),
-    'bottle': ('https://bottlepy.org/docs/dev/', None),
-    'build': ('https://pypa-build.readthedocs.io/en/stable/', None),
-    'cffi': ('https://cffi.readthedocs.io/en/latest/', None),
-    'conda': ('https://conda.io/en/latest/', None),
-    'devpi': ('https://devpi.net/docs/devpi/devpi/latest/+doc', None),
-    'dh-virtualenv': ('https://dh-virtualenv.readthedocs.io/en/latest/', None),
-    'distlib': ('https://distlib.readthedocs.io/en/latest/', None),
-    'flexx': ('https://flexx.readthedocs.io/en/latest/', None),
-    'nox': ('https://nox.thea.codes/en/latest/', None),
-    'openstack': ('https://docs.openstack.org/glance/latest/', None),
-    'packaging': ('https://packaging.pypa.io/en/latest/', None),
-    'packaging.python.org': ('https://packaging.python.org/en/latest/', None),
-    'pip': ('https://pip.pypa.io/en/latest/', None),
-    'pipenv': ('https://pipenv.pypa.io/en/latest/', None),
-    'piwheels': ('https://piwheels.readthedocs.io/en/latest/', None),
-    'pybind11': ('https://pybind11.readthedocs.io/en/stable/', None),
-    'pynsist': ('https://pynsist.readthedocs.io/en/latest/', None),
-    'pypa': ('https://www.pypa.io/en/latest/', None),
-    'python': ('https://docs.python.org/3', None),
-    'python-guide': ('https://docs.python-guide.org', None),
-    'setuptools': ('https://setuptools.pypa.io/en/latest/', None),
-    'spack': ('https://spack.readthedocs.io/en/latest/', None),
-    'sphinx': ('https://www.sphinx-doc.org/en/master', None),
-    'tox': ('https://tox.wiki/en/latest/', None),
-    'twine': ('https://twine.readthedocs.io/en/stable/', None),
-    'virtualenv': ('https://virtualenv.pypa.io/en/stable/', None),
+    "boltons": ("https://boltons.readthedocs.io/en/latest/", None),
+    "bottle": ("https://bottlepy.org/docs/dev/", None),
+    "build": ("https://pypa-build.readthedocs.io/en/stable/", None),
+    "cffi": ("https://cffi.readthedocs.io/en/latest/", None),
+    "conda": ("https://conda.io/en/latest/", None),
+    "devpi": ("https://devpi.net/docs/devpi/devpi/latest/+doc", None),
+    "dh-virtualenv": ("https://dh-virtualenv.readthedocs.io/en/latest/", None),
+    "distlib": ("https://distlib.readthedocs.io/en/latest/", None),
+    "flexx": ("https://flexx.readthedocs.io/en/latest/", None),
+    "nox": ("https://nox.thea.codes/en/latest/", None),
+    "openstack": ("https://docs.openstack.org/glance/latest/", None),
+    "packaging": ("https://packaging.pypa.io/en/latest/", None),
+    "packaging.python.org": ("https://packaging.python.org/en/latest/", None),
+    "pip": ("https://pip.pypa.io/en/latest/", None),
+    "pipenv": ("https://pipenv.pypa.io/en/latest/", None),
+    "piwheels": ("https://piwheels.readthedocs.io/en/latest/", None),
+    "pybind11": ("https://pybind11.readthedocs.io/en/stable/", None),
+    "pynsist": ("https://pynsist.readthedocs.io/en/latest/", None),
+    "pypa": ("https://www.pypa.io/en/latest/", None),
+    "python": ("https://docs.python.org/3", None),
+    "python-guide": ("https://docs.python-guide.org", None),
+    "setuptools": ("https://setuptools.pypa.io/en/latest/", None),
+    "spack": ("https://spack.readthedocs.io/en/latest/", None),
+    "sphinx": ("https://www.sphinx-doc.org/en/master", None),
+    "tox": ("https://tox.wiki/en/latest/", None),
+    "twine": ("https://twine.readthedocs.io/en/stable/", None),
+    "virtualenv": ("https://virtualenv.pypa.io/en/stable/", None),
 }
 
 
@@ -435,12 +442,12 @@
 # NOTE: consider having a separate ignore file
 # Ref: https://stackoverflow.com/a/30624034/595220
 nitpick_ignore = [
-    ('envvar', 'PATH'),
-    ('py:func', 'find_packages'),
-    ('py:func', 'setup'),
-    ('py:func', 'importlib.metadata.entry_points'),  # remove when 3.10 is released
-    ('py:class', 'importlib.metadata.EntryPoint'),  # remove when 3.10 is released
-    ('py:func', 'setuptools.find_namespace_packages'),
-    ('py:func', 'setuptools.find_packages'),
-    ('py:func', 'setuptools.setup'),
+    ("envvar", "PATH"),
+    ("py:func", "find_packages"),
+    ("py:func", "setup"),
+    ("py:func", "importlib.metadata.entry_points"),  # remove when 3.10 is released
+    ("py:class", "importlib.metadata.EntryPoint"),  # remove when 3.10 is released
+    ("py:func", "setuptools.find_namespace_packages"),
+    ("py:func", "setuptools.find_packages"),
+    ("py:func", "setuptools.setup"),
 ]

From b3057119c8a9d82f18fc506973ddcdccae36e8ea Mon Sep 17 00:00:00 2001
From: Pradyun Gedam 
Date: Wed, 8 Nov 2023 18:22:55 +0000
Subject: [PATCH 0473/1072] Ignore the ruff reformatting change

---
 .git-blame-ignore-revs | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 .git-blame-ignore-revs

diff --git a/.git-blame-ignore-revs b/.git-blame-ignore-revs
new file mode 100644
index 000000000..6b26875f1
--- /dev/null
+++ b/.git-blame-ignore-revs
@@ -0,0 +1 @@
+1d7b1abd152e4cb5e6a46e52e6b7e3bf8d366486

From 40b0a8f357c6a71fa1e286cd9ce214e578b3630e Mon Sep 17 00:00:00 2001
From: Pradyun Gedam 
Date: Mon, 6 Nov 2023 23:02:11 +0000
Subject: [PATCH 0474/1072] Modernise the conf.py file

This follows the style of the Sphinx 5+ configuration file template,
removing commented out sections and content duplicated from the
documentation.

This also removes a few unused values and uses the newer `root_doc`
name.
---
 source/conf.py | 431 +++++++++----------------------------------------
 1 file changed, 76 insertions(+), 355 deletions(-)

diff --git a/source/conf.py b/source/conf.py
index 64b99d0b2..35eb7ee4c 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -1,35 +1,16 @@
-#!/usr/bin/env python3
-# -*- coding: utf-8 -*-
-#
-# The Python Packaging Guide documentation build configuration file, created by
-# sphinx-quickstart on Sun Dec 13 14:07:23 2009.
-#
-# This file is execfile()d with the current directory set to its containing
-# dir.
-#
-# Note that not all possible configuration values are present in this
-# autogenerated file.
-#
-# All configuration values have a default; values that are commented out
-# serve to show the default.
-
-# If extensions (or modules to document with autodoc) are in another directory,
-# add these directories to sys.path here. If the directory is relative to the
-# documentation root, use os.path.abspath to make it absolute, like shown here.
-#
-# import os
-# import sys
-# sys.path.insert(0, os.path.abspath('.'))
-
-# -- General configuration ------------------------------------------------
-
-# If your documentation needs a minimal Sphinx version, state it here.
-#
-# needs_sphinx = '1.0'
-
-# Add any Sphinx extension module names here, as strings. They can be
-# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
-# ones.
+# -- Project information ---------------------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/configuration.html#project-information
+
+project = "Python Packaging User Guide"
+
+copyright = "2013–2020, PyPA"
+author = "Python Packaging Authority"
+
+# -- General configuration -------------------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/configuration.html#general-configuration
+
+root_doc = "index"
+
 extensions = [
     "sphinx.ext.extlinks",
     "sphinx.ext.intersphinx",
@@ -39,263 +20,57 @@
     "sphinx_toolbox.collapse",
 ]
 
-# config for copy button
-copybutton_prompt_text = r">>> |\.\.\. |\$ |> "
-copybutton_prompt_is_regexp = True
-
-# Add any paths that contain templates here, relative to this directory.
-templates_path = ["_templates"]
-
-# The suffix(es) of source filenames.
-# You can specify multiple suffix as a list of string:
-#
-# source_suffix = ['.rst', '.md']
-source_suffix = ".rst"
-
-# The encoding of source files.
-#
-# source_encoding = 'utf-8-sig'
-
-# The master toctree document.
-master_doc = "index"
-
-# -- Project information -----------------------------------------------------
+nitpicky = True
+nitpick_ignore = [
+    ("envvar", "PATH"),
+    ("py:func", "find_packages"),
+    ("py:func", "setup"),
+    ("py:func", "importlib.metadata.entry_points"),
+    ("py:class", "importlib.metadata.EntryPoint"),
+    ("py:func", "setuptools.find_namespace_packages"),
+    ("py:func", "setuptools.find_packages"),
+    ("py:func", "setuptools.setup"),
+]
 
-github_url = "https://github.com"
-github_repo_org = "pypa"
-github_repo_name = "packaging.python.org"
-github_repo_slug = f"{github_repo_org}/{github_repo_name}"
-github_repo_url = f"{github_url}/{github_repo_slug}"
-github_repo_issues_url = f"{github_url}/{github_repo_slug}/issues"
-github_sponsors_url = f"{github_url}/sponsors"
+default_role = "any"
+exclude_patterns = ["_build", "Thumbs.db", ".DS_Store"]
 
-# General information about the project.
-project = "Python Packaging User Guide"
-copyright = "2013–2020, PyPA"
-author = "Python Packaging Authority"
+# -- Options for internationalization --------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-internationalization
 
-# The version info for the project you're documenting, acts as replacement for
-# |version| and |release|, also used in various other places throughout the
-# built documents.
-#
-# The short X.Y version.
-version = ""
-# The full version, including alpha/beta/rc tags.
-release = ""
-
-# The language for content autogenerated by Sphinx. Refer to documentation
-# for a list of supported languages.
-#
-# This is also used if you do content translation via gettext catalogs.
-# Usually you set "language" from the command line for these cases.
 language = "en"
 
 locale_dirs = ["../locales"]
 
-gettext_auto_build = True  # Build MO files from PO on each build
-
-# making all documents use single text domain
+gettext_auto_build = True
 gettext_compact = "messages"
+gettext_location = True
 
-gettext_location = True  # Include location info in the translation files
-
-# There are two options for replacing |today|: either, you set today to some
-# non-false value, then it is used:
-#
-# today = ''
-#
-# Else, today_fmt is used as the format for a strftime call.
-#
-# today_fmt = '%B %d, %Y'
+# -- Options for HTML output -----------------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-html-output
 
-# List of patterns, relative to source directory, that match files and
-# directories to ignore when looking for source files.
-# This patterns also effect to html_static_path and html_extra_path
-exclude_patterns = ["_build", "Thumbs.db", ".DS_Store"]
-
-# The reST default role (used for this markup: `text`) to use for all
-# documents.
-# Ref: python-attrs/attrs#571
-default_role = "any"  # makes single backticks autofind targets
-
-# If true, '()' will be appended to :func: etc. cross-reference text.
-#
-# add_function_parentheses = True
-
-# If true, the current module name will be prepended to all description
-# unit titles (such as .. function::).
-#
-# add_module_names = False
-
-# If true, sectionauthor and moduleauthor directives will be shown in the
-# output. They are ignored by default.
-#
-# show_authors = False
-
-# The name of the Pygments (syntax highlighting) style to use.
-# pygments_style = 'sphinx'
-
-# A list of ignored prefixes for module index sorting.
-# modindex_common_prefix = []
-
-# If true, keep warnings as "system message" paragraphs in the built documents.
-# keep_warnings = False
-
-# If true, `todo` and `todoList` produce output, else they produce nothing.
-# todo_include_todos = False
-
-
-# -- Options for HTML output ----------------------------------------------
+html_title = "Python Packaging User Guide"
 
-# The theme to use for HTML and HTML Help pages.  See the documentation for
-# a list of builtin themes.
-#
 html_theme = "furo"
-
-# Theme options are theme-specific and customize the look and feel of a theme
-# further.  For a list of options available for each theme, see the
-# documentation.
 html_theme_options = {
     "sidebar_hide_name": True,
-    # 'issues_url': github_repo_issues_url,  # FIXME: support this in furo?
 }
 
-# Add any paths that contain custom themes here, relative to this directory.
-# html_theme_path = ['themes']
-
-# The name for this set of Sphinx documents.
-# " v documentation" by default.
-#
-html_title = "Python Packaging User Guide"
-
-# A shorter title for the navigation bar.  Default is the same as html_title.
-#
-# html_short_title = None
-
-# The name of an image file (relative to this directory) to place at the top
-# of the sidebar.
-#
-# html_logo = None
-
-# The name of an image file (relative to this directory) to use as a favicon of
-# the docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
-# pixels large.
-#
 html_favicon = "assets/py.png"
-
-# Add any paths that contain custom static files (such as style sheets) here,
-# relative to this directory. They are copied after the builtin static files,
-# so a file named "default.css" will overwrite the builtin "default.css".
-# html_static_path = ['_static']
-
-# Add any extra paths that contain custom files (such as robots.txt or
-# .htaccess) here, relative to this directory. These files are copied
-# directly to the root of the documentation.
-#
-# html_extra_path = []
-
-# If not None, a 'Last updated on:' timestamp is inserted at every page
-# bottom, using the given strftime format.
-# The empty string is equivalent to '%b %d, %Y'.
-#
 html_last_updated_fmt = ""
 
-# If true, SmartyPants will be used to convert quotes and dashes to
-# typographically correct entities.
-#
-# html_use_smartypants = True
-
-# Custom sidebar templates, maps document names to template names.
-#
-
-# Custom sidebar templates, filenames relative to this file.
-# html_sidebars = {
-#     '**': ['globaltoc.html', 'relations.html'],
-#     'index': ['globaltoc.html']
-# }
-
-# Additional templates that should be rendered to pages, maps page names to
-# template names.
-#
-# html_additional_pages = {}
-
-# If false, no module index is generated.
-#
-# html_domain_indices = True
-
-# If false, no index is generated.
-#
-# html_use_index = True
-
-# If true, the index is split into individual pages for each letter.
-#
-# html_split_index = False
-
-# If true, links to the reST sources are added to the pages.
-#
-# html_show_sourcelink = True
-
-# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
-#
-# html_show_sphinx = True
-
-# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
-#
-# html_show_copyright = True
-
-# If true, an OpenSearch description file will be output, and all pages will
-# contain a  tag referring to it.  The value of this option must be the
-# base URL from which the finished HTML is served.
-#
-# html_use_opensearch = ''
-
-# This is the file name suffix for HTML files (e.g. ".xhtml").
-# html_file_suffix = None
-
-# Language to be used for generating the HTML full-text search index.
-# Sphinx supports the following languages:
-#   'da', 'de', 'en', 'es', 'fi', 'fr', 'h', 'it', 'ja'
-#   'nl', 'no', 'pt', 'ro', 'r', 'sv', 'tr', 'zh'
-#
-# html_search_language = 'en'
-
-# A dictionary with options for the search language support, empty by default.
-# 'ja' uses this config value.
-# 'zh' user can custom change `jieba` dictionary path.
-#
-# html_search_options = {'type': 'default'}
-
-# The name of a javascript file (relative to the configuration directory) that
-# implements a search results scorer. If empty, the default will be used.
-#
-# html_search_scorer = 'scorer.js'
-
-# Output file base name for HTML help builder.
+# -- Options for HTML help output ------------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-html-help-output
+
 htmlhelp_basename = "pythonpackagingguide-authdoc"
 
-# -- Options for LaTeX output ---------------------------------------------
-
-latex_elements = {
-    # The paper size ('letterpaper' or 'a4paper').
-    #
-    # 'papersize': 'letterpaper',
-    # The font size ('10pt', '11pt' or '12pt').
-    #
-    # 'pointsize': '10pt',
-    # Additional stuff for the LaTeX preamble.
-    #
-    # 'preamble': '',
-    # Latex figure (float) alignment
-    #
-    # 'figure_align': 'htbp',
-}
+# -- Options for LaTeX output ----------------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-latex-output
 
-# Grouping the document tree into LaTeX files. List of tuples
-# (source start file, target name, title,
-#  author, documentclass [howto, manual, or own class]).
+latex_elements = {}
 latex_documents = [
     (
-        master_doc,
+        root_doc,
         "pythonpackagingguide.tex",
         "Python Packaging User Guide",
         "Python Packaging Authority",
@@ -303,60 +78,19 @@
     ),
 ]
 
-# The name of an image file (relative to this directory) to place at the top of
-# the title page.
-#
-# latex_logo = None
-
-# For "manual" documents, if this is true, then toplevel headings are parts,
-# not chapters.
-#
-# latex_use_parts = False
-
-# If true, show page references after internal links.
-#
-# latex_show_pagerefs = False
-
-# If true, show URL addresses after external links.
-#
-# latex_show_urls = False
-
-# Documents to append as an appendix to all manuals.
-#
-# latex_appendices = []
-
-# It false, will not define \strong, \code,     itleref, \crossref ... but only
-# \sphinxstrong, ..., \sphinxtitleref, ... To help avoid clash with user added
-# packages.
-#
-# latex_keep_old_macro_names = True
+# -- Options for manual page output ----------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-manual-page-output
 
-# If false, no module index is generated.
-#
-# latex_domain_indices = True
-
-
-# -- Options for manual page output ---------------------------------------
-
-# One entry per manual page. List of tuples
-# (source start file, name, description, authors, manual section).
 man_pages = [
-    (master_doc, "pythonpackagingguide", "Python Packaging User Guide", [author], 1)
+    (root_doc, "pythonpackagingguide", "Python Packaging User Guide", [author], 1)
 ]
 
-# If true, show URL addresses after external links.
-#
-# man_show_urls = False
+# -- Options for Texinfo output --------------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-texinfo-output
 
-
-# -- Options for Texinfo output -------------------------------------------
-
-# Grouping the document tree into Texinfo files. List of tuples
-# (source start file, target name, title, author,
-#  dir menu entry, description, category)
 texinfo_documents = [
     (
-        master_doc,
+        root_doc,
         "pythonpackagingguide",
         "Python Packaging User Guide",
         author,
@@ -366,41 +100,38 @@
     ),
 ]
 
-# Documents to append as an appendix to all manuals.
-#
-# texinfo_appendices = []
-
-# If false, no module index is generated.
-#
-# texinfo_domain_indices = True
-
-# How to display URL addresses: 'footnote', 'no', or 'inline'.
-#
-# texinfo_show_urls = 'footnote'
-
-# If true, do not generate a @detailmenu in the "Top" node's menu.
-#
-# texinfo_no_detailmenu = False
-
-# -- Options for extlinks extension ---------------------------------------
-extlinks = {
-    "issue": (f"{github_repo_issues_url}/%s", "#%s"),  # noqa: WPS323
-    "pr": (f"{github_repo_url}/pull/%s", "PR #%s"),  # noqa: WPS323
-    "commit": (f"{github_repo_url}/commit/%s", "%s"),  # noqa: WPS323
-    "gh": (f"{github_url}/%s", "GitHub: %s"),  # noqa: WPS323
-    "user": (f"{github_sponsors_url}/%s", "@%s"),  # noqa: WPS323
-}
+# -- Options for the linkcheck builder -------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-the-linkcheck-builder
 
 linkcheck_ignore = [
     "http://localhost:\d+",
-    # This is an example that showing to the reader
     "https://test.pypi.org/project/example-package-YOUR-USERNAME-HERE",
-    # Ignoring it as it will redirect to login page if reader hasn't logged in.
     "https://pypi.org/manage/*",
     "https://test.pypi.org/manage/*",
 ]
 
-# Example configuration for intersphinx: refer to the Python standard library.
+# -- Options for extlinks ----------------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/extensions/extlinks.html#configuration
+
+github_url = "https://github.com"
+github_repo_org = "pypa"
+github_repo_name = "packaging.python.org"
+github_repo_slug = f"{github_repo_org}/{github_repo_name}"
+github_repo_url = f"{github_url}/{github_repo_slug}"
+github_repo_issues_url = f"{github_url}/{github_repo_slug}/issues"
+github_sponsors_url = f"{github_url}/sponsors"
+
+extlinks = {
+    "issue": (f"{github_repo_issues_url}/%s", "#%s"),
+    "pr": (f"{github_repo_url}/pull/%s", "PR #%s"),
+    "commit": (f"{github_repo_url}/commit/%s", "%s"),
+    "gh": (f"{github_url}/%s", "GitHub: %s"),
+    "user": (f"{github_sponsors_url}/%s", "@%s"),
+}
+
+# -- Options for intersphinx ----------------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html#configuration
+
 intersphinx_mapping = {
     "boltons": ("https://boltons.readthedocs.io/en/latest/", None),
     "bottle": ("https://bottlepy.org/docs/dev/", None),
@@ -431,23 +162,13 @@
     "virtualenv": ("https://virtualenv.pypa.io/en/stable/", None),
 }
 
-
-# If this is True, todo and todolist produce output, else they produce nothing.
-# The default is False.
+# -- Options for todo extension --------------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/extensions/todo.html#configuration
 
 todo_include_todos = True
 
-nitpicky = True
+# -- Options for sphinx-copybutton -----------------------------------------------------
+# https://sphinx-copybutton.readthedocs.io/en/latest/use.html
 
-# NOTE: consider having a separate ignore file
-# Ref: https://stackoverflow.com/a/30624034/595220
-nitpick_ignore = [
-    ("envvar", "PATH"),
-    ("py:func", "find_packages"),
-    ("py:func", "setup"),
-    ("py:func", "importlib.metadata.entry_points"),  # remove when 3.10 is released
-    ("py:class", "importlib.metadata.EntryPoint"),  # remove when 3.10 is released
-    ("py:func", "setuptools.find_namespace_packages"),
-    ("py:func", "setuptools.find_packages"),
-    ("py:func", "setuptools.setup"),
-]
+copybutton_prompt_text = r">>> |\.\.\. |\$ |> "
+copybutton_prompt_is_regexp = True

From 328b812d605de9b6c12743f5bedefcbbb530522a Mon Sep 17 00:00:00 2001
From: Pradyun Gedam 
Date: Mon, 6 Nov 2023 23:04:26 +0000
Subject: [PATCH 0475/1072] Properly escape `\d`

This raises a SyntaxWarning on new-enough Python versions.
---
 source/conf.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/conf.py b/source/conf.py
index 35eb7ee4c..f191445b9 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -104,7 +104,7 @@
 # https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-the-linkcheck-builder
 
 linkcheck_ignore = [
-    "http://localhost:\d+",
+    "http://localhost:\\d+",
     "https://test.pypi.org/project/example-package-YOUR-USERNAME-HERE",
     "https://pypi.org/manage/*",
     "https://test.pypi.org/manage/*",

From e989371ea9e909b65662557a7d0734d9edf3c13d Mon Sep 17 00:00:00 2001
From: Pradyun Gedam 
Date: Wed, 8 Nov 2023 18:34:41 +0000
Subject: [PATCH 0476/1072] Stop hiding the name in the sidebar

This makes the homepage accessible via the sidebar.
---
 source/conf.py | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/source/conf.py b/source/conf.py
index f191445b9..3ce306397 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -50,11 +50,7 @@
 # https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-html-output
 
 html_title = "Python Packaging User Guide"
-
 html_theme = "furo"
-html_theme_options = {
-    "sidebar_hide_name": True,
-}
 
 html_favicon = "assets/py.png"
 html_last_updated_fmt = ""

From d90ae924dffefb74175869a9b343b266fda0f5ec Mon Sep 17 00:00:00 2001
From: Pradyun Gedam 
Date: Wed, 8 Nov 2023 09:30:53 +0000
Subject: [PATCH 0477/1072] Retitle overview.rst for a shorter sidebar entry

This is the phrase used in the landing page for referencing this page.
---
 source/overview.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/source/overview.rst b/source/overview.rst
index 0bd4393db..3627e8122 100644
--- a/source/overview.rst
+++ b/source/overview.rst
@@ -1,6 +1,6 @@
-===================================
-An Overview of Packaging for Python
-===================================
+============================
+Overview of Python Packaging
+============================
 
 .. Editors, see notes at the bottom of the document for maintenance info.
 

From bbd1cd2c699c68ae2dfe36ab66ff39ba33721551 Mon Sep 17 00:00:00 2001
From: Pradyun Gedam 
Date: Wed, 8 Nov 2023 09:32:02 +0000
Subject: [PATCH 0478/1072] Simplify the reference to `overview` from `index`

The page title now matches the provided name at this reference.
---
 source/index.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/index.rst b/source/index.rst
index c00ed0ad8..32f85b206 100644
--- a/source/index.rst
+++ b/source/index.rst
@@ -41,7 +41,7 @@ Overview and Flow
    continuous improvement are key to success. The overview and flow sections
    provide a starting point for understanding the Python packaging ecosystem.
 
-The :doc:`Overview of Python Packaging ` explains Python packaging
+The :doc:`overview` explains Python packaging
 and its use when preparing and distributing projects.
 This section helps you build understanding about selecting the tools and
 processes that are most suitable for your use case.

From 7773243af520043c01d8eba3cb6a2dd912276276 Mon Sep 17 00:00:00 2001
From: Pradyun Gedam 
Date: Wed, 8 Nov 2023 18:39:13 +0000
Subject: [PATCH 0479/1072] Add a document heirarchy for presenting guides

This makes their presentation in the sidebar easier to navigate.
---
 source/guides/index.rst                     | 38 +++------------------
 source/guides/section-build-and-publish.rst | 17 +++++++++
 source/guides/section-hosting.rst           |  9 +++++
 source/guides/section-install.rst           | 12 +++++++
 4 files changed, 42 insertions(+), 34 deletions(-)
 create mode 100644 source/guides/section-build-and-publish.rst
 create mode 100644 source/guides/section-hosting.rst
 create mode 100644 source/guides/section-install.rst

diff --git a/source/guides/index.rst b/source/guides/index.rst
index 2f6f1a217..b87d0b1a8 100644
--- a/source/guides/index.rst
+++ b/source/guides/index.rst
@@ -6,40 +6,10 @@ already familiar with the basics of Python packaging. If you're looking for an
 introduction to packaging, see :doc:`/tutorials/index`.
 
 .. toctree::
-   :maxdepth: 1
-   :caption: Installing Packages:
-
-   installing-using-pip-and-virtual-environments
-   installing-using-virtualenv
-   installing-stand-alone-command-line-tools
-   installing-using-linux-tools
-   installing-scientific-packages
-
-.. toctree::
-   :maxdepth: 1
-   :caption: Building and Publishing Projects:
-
-   distributing-packages-using-setuptools
-   using-manifest-in
-   single-sourcing-package-version
-   dropping-older-python-versions
-   packaging-binary-extensions
-   packaging-namespace-packages
-   creating-and-discovering-plugins
-   using-testpypi
-   making-a-pypi-friendly-readme
-   publishing-package-distribution-releases-using-github-actions-ci-cd-workflows
-
-.. toctree::
-   :maxdepth: 1
-   :caption: Hosting
-
-   index-mirrors-and-caches
-   hosting-your-own-index
-
-.. toctree::
-   :maxdepth: 1
-   :caption: Miscellaneous:
+   :titlesonly:
 
+   section-install
+   section-build-and-publish
+   section-hosting
    tool-recommendations
    analyzing-pypi-package-downloads
diff --git a/source/guides/section-build-and-publish.rst b/source/guides/section-build-and-publish.rst
new file mode 100644
index 000000000..9bb5f08fe
--- /dev/null
+++ b/source/guides/section-build-and-publish.rst
@@ -0,0 +1,17 @@
+=======================
+Building and Publishing
+=======================
+
+.. toctree::
+   :titlesonly:
+
+   distributing-packages-using-setuptools
+   using-manifest-in
+   single-sourcing-package-version
+   dropping-older-python-versions
+   packaging-binary-extensions
+   packaging-namespace-packages
+   creating-and-discovering-plugins
+   using-testpypi
+   making-a-pypi-friendly-readme
+   publishing-package-distribution-releases-using-github-actions-ci-cd-workflows
diff --git a/source/guides/section-hosting.rst b/source/guides/section-hosting.rst
new file mode 100644
index 000000000..f8f708c18
--- /dev/null
+++ b/source/guides/section-hosting.rst
@@ -0,0 +1,9 @@
+=======
+Hosting
+=======
+
+.. toctree::
+   :titlesonly:
+
+   index-mirrors-and-caches
+   hosting-your-own-index
diff --git a/source/guides/section-install.rst b/source/guides/section-install.rst
new file mode 100644
index 000000000..515092b4d
--- /dev/null
+++ b/source/guides/section-install.rst
@@ -0,0 +1,12 @@
+============
+Installation
+============
+
+.. toctree::
+   :titlesonly:
+
+   installing-using-pip-and-virtual-environments
+   installing-using-virtualenv
+   installing-stand-alone-command-line-tools
+   installing-using-linux-tools
+   installing-scientific-packages

From 7ea3f68b33be2721bcb09e7b9d5a441fa318bb0b Mon Sep 17 00:00:00 2001
From: Pradyun Gedam 
Date: Wed, 8 Nov 2023 18:58:11 +0000
Subject: [PATCH 0480/1072] Add a GitHub Action to inject preview links in PRs

This makes easier to review pull requests by providing the preview links
in the PR description.
---
 .github/workflows/pr-preview-links.yml | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 .github/workflows/pr-preview-links.yml

diff --git a/.github/workflows/pr-preview-links.yml b/.github/workflows/pr-preview-links.yml
new file mode 100644
index 000000000..90ea9cc73
--- /dev/null
+++ b/.github/workflows/pr-preview-links.yml
@@ -0,0 +1,22 @@
+name: Read the Docs PR preview
+
+on:
+  pull_request_target:
+    types:
+      - opened
+
+permissions:
+  contents: read
+  pull-requests: write
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+  cancel-in-progress: true
+
+jobs:
+  documentation-links:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: readthedocs/actions/preview@v1
+        with:
+          project-slug: "python-packaging-user-guide"

From b2830611416f030e1211a7e754848a959673f85b Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sat, 4 Nov 2023 23:30:25 +0100
Subject: [PATCH 0481/1072] Import PEP 668 verbatim

---
 .../externally-managed-environments.rst       | 1096 +++++++++++++++++
 1 file changed, 1096 insertions(+)

diff --git a/source/specifications/externally-managed-environments.rst b/source/specifications/externally-managed-environments.rst
index 979b72aec..8cd3b840a 100644
--- a/source/specifications/externally-managed-environments.rst
+++ b/source/specifications/externally-managed-environments.rst
@@ -21,6 +21,1102 @@ neither install nor remove packages into the interpreter’s default installatio
 environment, and should instead guide the end user towards using
 :ref:`virtual-environments`.
 
+PEP: 668
+Title: Marking Python base environments as “externally managed”
+Author: Geoffrey Thomas ,
+        Matthias Klose ,
+        Filipe Laíns ,
+        Donald Stufft ,
+        Tzu-ping Chung ,
+        Stefano Rivera ,
+        Elana Hashman ,
+        Pradyun Gedam 
+PEP-Delegate: Paul Moore 
+Discussions-To: https://discuss.python.org/t/10302
+Status: Accepted
+Type: Standards Track
+Topic: Packaging
+Content-Type: text/x-rst
+Created: 18-May-2021
+Post-History: 28-May-2021
+Resolution: https://discuss.python.org/t/10302/44
+
+Abstract
+========
+
+A long-standing practical problem for Python users has been conflicts
+between OS package managers and Python-specific package management
+tools like pip. These conflicts include both Python-level API
+incompatibilities and conflicts over file ownership.
+
+Historically, Python-specific package management tools have defaulted
+to installing packages into an implicit global context. With the
+standardization and popularity of virtual environments, a better
+solution for most (but not all) use cases is to use Python-specific
+package management tools only within a virtual environment.
+
+This PEP proposes a mechanism for a Python installation to communicate
+to tools like pip that its global package installation context is
+managed by some means external to Python, such as an OS package
+manager. It specifies that Python-specific package management tools
+should neither install nor remove packages into the interpreter's
+global context, by default, and should instead guide the end user
+towards using a virtual environment.
+
+It also standardizes an interpretation of the ``sysconfig`` schemes so
+that, if a Python-specific package manager is about to install a
+package in an interpreter-wide context, it can do so in a manner that
+will avoid conflicting with the external package manager and reduces
+the risk of breaking software shipped by the external package manager.
+
+Terminology
+===========
+
+A few terms used in this PEP have multiple meanings in the contexts
+that it spans. For clarity, this PEP uses the following terms in
+specific ways:
+
+distro
+    Short for "distribution," a collection of various sorts of
+    software, ideally designed to work properly together, including
+    (in contexts relevant to this document) the Python interpreter
+    itself, software written in Python, and software written in other
+    languages. That is, this is the sense used in phrases such as
+    "Linux distro" or "Berkeley Software Distribution."
+
+    A distro can be an operating system (OS) of its own, such as
+    Debian, Fedora, or FreeBSD. It can also be an overlay distribution
+    that installs on top of an existing OS, such as Homebrew or
+    MacPorts.
+
+    This document uses the short term "distro," because the term
+    "distribution" has another meaning in Python packaging contexts: a
+    source or binary distribution package of a single piece of Python
+    language software, that is, in the sense of
+    ``setuptools.dist.Distribution`` or "sdist". To avoid confusion,
+    this document does not use the plain term "distribution" at all.
+    In the Python packaging sense, it uses the full phrase
+    "distribution package" or just "package" (see below).
+
+    The provider of a distro - the team or company that collects and
+    publishes the software and makes any needed modifications - is its
+    **distributor**.
+package
+    A unit of software that can be installed and used within Python.
+    That is, this refers to what Python-specific packaging tools tend
+    to call a "`distribution package`_" or simply a "distribution";
+    the colloquial abbreviation "package" is used in the sense of the
+    Python Package Index.
+
+    .. _`distribution package`: https://packaging.python.org/glossary/#term-Distribution-Package
+
+    This document does not use "package" in the sense of an importable
+    name that contains Python modules, though in many cases, a
+    distribution package consists of a single importable package of
+    the same name.
+
+    This document generally does not use the term "package" to refer
+    to units of installation by a distro's package manager (such as
+    ``.deb`` or ``.rpm`` files). When needed, it uses phrasing such as
+    "a distro's package." (Again, in many cases, a Python package is
+    shipped inside a distro's package named something like ``python-``
+    plus the Python package name.)
+Python-specific package manager
+    A tool for installing, upgrading, and/or removing Python packages
+    in a manner that conforms to Python packaging standards (such as
+    :pep:`376` and :pep:`427`). The most popular Python-specific package
+    manager is pip [#pip]_; other examples include the old Easy
+    Install command [#easy-install]_ as well as direct usage of a
+    ``setup.py`` command.
+
+    (Conda [#conda]_ is a bit of a special case, as the ``conda``
+    command can install much more than just Python packages, making it
+    more like a distro package manager in some senses. Since the
+    ``conda`` command generally only operates on Conda-created
+    environments, most of the concerns in this document do not apply
+    to ``conda`` when acting as a Python-specific package manager.)
+distro package manager
+    A tool for installing, upgrading, and/or removing a distro's
+    packages in an installed instance of that distro, which is capable
+    of installing Python packages as well as non-Python packages, and
+    therefore generally has its own database of installed software
+    unrelated to :pep:`376`. Examples include ``apt``, ``dpkg``, ``dnf``,
+    ``rpm``, ``pacman``, and ``brew``. The salient feature is that if
+    a package was installed by a distro package manager, removing or
+    upgrading it in a way that would satisfy a Python-specific package
+    manager will generally leave a distro package manager in an
+    inconsistent state.
+
+    This document also uses phrases like "external package manager" or
+    "system's package manager" to refer to a distro package manager in
+    certain contexts.
+shadow
+    To shadow an installed Python package is to cause some other
+    package to be preferred for imports without removing any files
+    from the shadowed package. This requires multiple entries on
+    ``sys.path``: if package A 2.0 installs module ``a.py`` in one
+    ``sys.path`` entry, and package A 1.0 installs module ``a.py`` in
+    a later ``sys.path`` entry, then ``import a`` returns the module
+    from the former, and we say that A 2.0 shadows A 1.0.
+
+Motivation
+==========
+
+Thanks to Python's immense popularity, software distros (by which we
+mean Linux and other OS distros as well as overlay distros like
+Homebrew and MacPorts) generally ship Python for two purposes: as a
+software package to be used in its own right by end users, and as a
+language dependency for other software in the distro.
+
+For example, Fedora and Debian (and their downstream distros, as well
+as many others) ship a ``/usr/bin/python3`` binary which provides the
+``python3`` command available to end users as well as the
+``#!/usr/bin/python3`` shebang for Python-language software included
+in the distro. Because there are no official binary releases of Python
+for Linux/UNIX, almost all Python end users on these OSes use the
+Python interpreter built and shipped with their distro.
+
+The ``python3`` executable available to the users of the distro and
+the ``python3`` executable available as a dependency for other
+software in the distro are typically the same binary. This means that
+if an end user installs a Python package using a tool like ``pip``
+outside the context of a virtual environment, that package is visible
+to Python-language software shipped by the distro. If the
+newly-installed package (or one of its dependencies) is a newer,
+backwards-incompatible version of a package that was installed through
+the distro, it may break software shipped by the distro.
+
+This may pose a critical problem for the integrity of distros, which
+often have package-management tools that are themselves written in
+Python. For example, it's possible to unintentionally break Fedora's
+``dnf`` command with a ``pip install`` command, making it hard to
+recover.
+
+This applies both to system-wide installs (``sudo pip install``) as
+well as user home directory installs (``pip install --user``), since
+packages in either location show up on the ``sys.path`` of
+``/usr/bin/python3``.
+
+There is a worse problem with system-wide installs: if you attempt to
+recover from this situation with ``sudo pip uninstall``, you may end
+up removing packages that are shipped by the system's package manager.
+In fact, this can even happen if you simply upgrade a package - pip
+will try to remove the old version of the package, as shipped by the
+OS. At this point it may not be possible to recover the system to a
+consistent state using just the software remaining on the system.
+
+Over the past many years, a consensus has emerged that the best way to
+install Python libraries or applications (when not using a distro's
+package) is to use a virtual environment. This approach was
+popularized by the PyPA `virtualenv`_ project, and a simple version of
+that approach is now available in the Python standard library as
+``venv``. Installing a Python package into a virtualenv prevents it
+from being visible to the unqualified ``/usr/bin/python3`` interpreter
+and prevents breaking system software.
+
+.. _virtualenv: https://virtualenv.pypa.io/en/latest/
+
+In some cases, however, it's useful and intentional to install a
+Python package from outside of the distro that influences the behavior
+of distro-shipped commands. This is common in the case of software
+like Sphinx or Ansible which have a mechanism for writing
+Python-language extensions. A user may want to use their distro's
+version of the base software (for reasons of paid support or security
+updates) but install a small extension from PyPI, and they'd want that
+extension to be importable by the software in their base system.
+
+While this continues to carry the risk of installing a newer version
+of a dependency than the operating system expects or otherwise
+negatively affecting the behavior of an application, it does not need
+to carry the risk of removing files from the operating system. A tool
+like pip should be able to install packages in some directory on the
+default ``sys.path``, if specifically requested, without deleting
+files owned by the system's package manager.
+
+Therefore, this PEP proposes two things.
+
+First, it proposes **a way for distributors of a Python interpreter to
+mark that interpreter as having its packages managed by means external
+to Python**, such that Python-specific tools like pip should not
+change the installed packages in the interpreter's global ``sys.path``
+in any way (add, upgrade/downgrade, or remove) unless specifically
+overridden. It also provides a means for the distributor to indicate
+how to use a virtual environment as an alternative.
+
+This is an opt-in mechanism: by default, the Python interpreter
+compiled from upstream sources will not be so marked, and so running
+``pip install`` with a self-compiled interpreter, or with a distro
+that has not explicitly marked its interpreter, will work as it always
+has worked.
+
+Second, it sets the rule that when installing packages to an
+interpreter's global context (either to an unmarked interpreter, or if
+overriding the marking), **Python-specific package managers should
+modify or delete files only within the directories of the sysconfig
+scheme in which they would create files**. This permits a distributor
+of a Python interpreter to set up two directories, one for its own
+managed packages, and one for unmanaged packages installed by the end
+user, and ensure that installing unmanaged packages will not delete
+(or overwrite) files owned by the external package manager.
+
+Rationale
+=========
+
+As described in detail in the next section, the first behavior change
+involves creating a marker file named ``EXTERNALLY-MANAGED``, whose
+presence indicates that non-virtual-environment package installations
+are managed by some means external to Python, such as a distro's
+package manager. This file is specified to live in the ``stdlib``
+directory in the default ``sysconfig`` scheme, which marks the
+interpreter / installation as a whole, not a particular location on
+``sys.path``. The reason for this is that, as identified above, there
+are two related problems that risk breaking an externally-managed
+Python: you can install an incompatible new version of a package
+system-wide (e.g., with ``sudo pip install``), and you can install one
+in your user account alone, but in a location that is on the standard
+Python command's ``sys.path`` (e.g., with ``pip install --user``). If
+the marker file were in the system-wide ``site-packages`` directory,
+it would not clearly apply to the second case. The `Alternatives`_
+section has further discussion of possible locations.
+
+The second behavior change takes advantage of the existing
+``sysconfig`` setup in distros that have already encountered this
+class of problem, and specifically addresses the problem of a
+Python-specific package manager deleting or overwriting files that are
+owned by an external package manager.
+
+Use cases
+---------
+
+The changed behavior in this PEP is intended to "do the right thing"
+for as many use cases as possible. In this section, we consider the
+changes specified by this PEP for several representative use cases /
+contexts. Specifically, we ask about the two behaviors that could be
+changed by this PEP:
+
+1. Will a Python-specific installer tool like ``pip install`` permit
+   installations by default, after implementation of this PEP?
+
+2. If you do run such a tool, should it be willing to delete packages
+   shipped by the external (non-Python-specific) package manager for
+   that context, such as a distro package manager?
+
+(For simplicity, this section discusses pip as the Python-specific
+installer tool, though the analysis should apply equally to any other
+Python-specific package management tool.)
+
+This table summarizes the use cases discussed in detail below:
+
+==== ================================= =========================== ===================================================
+Case Description                       ``pip install`` permitted   Deleting externally-installed packages permitted
+==== ================================= =========================== ===================================================
+1    Unpatched CPython                 Currently yes; stays yes    Currently yes; stays yes
+2    Distro ``/usr/bin/python3``       Currently yes; becomes no   Currently yes (except on Debian); becomes no
+                                       (assuming the distro
+                                       adds a marker file)
+3    Distro Python in venv             Currently yes; stays yes    There are no externally-installed packages
+4    Distro Python in venv             Currently yes; stays yes    Currently no; stays no
+     with ``--system-site-packages``
+5    Distro Python in Docker           Currently yes; becomes no    Currently yes; becomes no
+                                       (assuming the distro
+                                       adds a marker file)
+6    Conda environment                 Currently yes; stays yes    Currently yes; stays yes
+7    Dev-facing distro                 Currently yes; becomes no   Currently often yes; becomes no
+                                       (assuming they add a        (assuming they configure ``sysconfig`` as needed)
+                                       marker file)
+8    Distro building packages          Currently yes; can stay yes Currently yes; becomes no
+9    ``PYTHONHOME`` copied from        Currently yes; becomes no   Currently yes; becomes no
+     a distro Python stdlib
+10   ``PYTHONHOME`` copied from        Currently yes; stays yes    Currently yes; stays yes
+     upstream Python stdlib
+==== ================================= =========================== ===================================================
+
+In more detail, the use cases above are:
+
+1. A standard unpatched CPython, without any special configuration of
+   or patches to ``sysconfig`` and without a marker file. This PEP
+   does not change its behavior.
+
+   Such a CPython should (regardless of this PEP) not be installed in
+   a way that overlaps any distro-installed Python on the same system.
+   For instance, on an OS that ships Python in ``/usr/bin``, you
+   should not install a custom CPython built with ``./configure
+   --prefix=/usr``, or it will overwrite some files from the distro
+   and the distro will eventually overwrite some files from your
+   installation. Instead, your installation should be in a separate
+   directory (perhaps ``/usr/local``, ``/opt``, or your home
+   directory).
+
+   Therefore, we can assume that such a CPython has its own ``stdlib``
+   directory and its own ``sysconfig`` schemes that do not overlap any
+   distro-installed Python. So any OS-installed packages are not
+   visible or relevant here.
+
+   If there is a concept of "externally-installed" packages in this
+   case, it's something outside the OS and generally managed by
+   whoever built and installed this CPython. Because the installer
+   chose not to add a marker file or modify ``sysconfig`` schemes,
+   they're choosing the current behavior, and ``pip install`` can
+   remove any packages available in this CPython.
+
+2. A distro's ``/usr/bin/python3``, either when running ``pip
+   install`` as root or ``pip install --user``, following our
+   `Recommendations for distros`_.
+
+   These recommendations include shipping a marker file in the
+   ``stdlib`` directory, to prevent ``pip install`` by default, and
+   placing distro-shipped packages in a location other than the
+   default ``sysconfig`` scheme, so that ``pip`` as root does not
+   write to that location.
+
+   Many distros (including Debian, Fedora, and their derivatives) are
+   already doing the latter.
+
+   On Debian and derivatives, ``pip install`` does not currently
+   delete distro-installed packages, because Debian carries a `patch
+   to pip to prevent this`__. So, for those distros, this PEP is not a
+   behavior change; it simply standardizes that behavior in a way that
+   is no longer Debian-specific and can be included into upstream pip.
+
+   .. __: https://sources.debian.org/src/python-pip/20.3.4-2/debian/patches/hands-off-system-packages.patch/
+
+   (We have seen user reports of externally-installed packages being
+   deleted on Debian or a derivative. We suspect this is because the
+   user has previously run ``sudo pip install --upgrade pip`` and
+   therefore now has a version of ``/usr/bin/pip`` without the Debian
+   patch; standardizing this behavior in upstream package installers
+   would address this problem.)
+
+3. A distro Python when used inside a virtual environment (either from
+   ``venv`` or ``virtualenv``).
+
+   Inside a virtual environment, all packages are owned by that
+   environment. Even when ``pip``, ``setuptools``, etc. are installed
+   into the environment, they are and should be managed by tools
+   specific to that environment; they are not system-managed.
+
+4. A distro Python when used inside a virtual environment with
+   ``--system-site-packages``. This is like the previous case, but
+   worth calling out explicitly, because anything on the global
+   ``sys.path`` is visible.
+
+   Currently, the answer to "Will ``pip`` delete externally-installed
+   packages" is no, because pip has a special case for running in a
+   virtual environment and attempting to delete packages outside it.
+   After this PEP, the answer remains no, but the reasoning becomes
+   more general: system site packages will be outside any of the
+   ``sysconfig`` schemes used for package management in the
+   environment.
+
+5. A distro Python when used in a single-application container image
+   (e.g., a Docker container). In this use case, the risk of breaking
+   system software is lower, since generally only a single application
+   runs in the container, and the impact is lower, since you can
+   rebuild the container and you don't have to struggle to recover a
+   running machine. There are also a large number of existing
+   Dockerfiles with an unqualified ``RUN pip install ...`` statement,
+   etc., and it would be good not to break those. So, builders of base
+   container images may want to ensure that the marker file is not
+   present, even if the underlying OS ships one by default.
+
+   There is a small behavior change: currently, ``pip`` run as root
+   will delete externally-installed packages, but after this PEP it
+   will not. We don't propose a way to override this. However, since
+   the base image is generally minimal, there shouldn't be much of a
+   use case for simply uninstalling packages (especially without using
+   the distro's own tools). The common case is when pip wants to
+   upgrade a package, which previously would have deleted the old
+   version (except on Debian). After this change, the old version will
+   still be on disk, but pip will still *shadow* externally-installed
+   packages, and we believe this to be sufficient for this not to be a
+   breaking change in practice - a Python ``import`` statement will
+   still get you the newly-installed package.
+
+   If it becomes necessary to have a way to do this, we suggest that
+   the distro should document a way for the installer tool to access
+   the ``sysconfig`` scheme used by the distro itself. See the
+   `Recommendations for distros`_ section for more discussion.
+
+   It is the view of the authors of this PEP that it's still a good
+   idea to use virtual environments with distro-installed Python
+   interpreters, even in single-application container images. Even
+   though they run a single *application*, that application may run
+   commands from the OS that are implemented in Python, and if you've
+   installed or upgraded the distro-shipped Python packages using
+   Python-specific tools, those commands may break.
+
+6. Conda specifically supports the use of non-``conda`` tools like pip
+   to install software not available in the Conda repositories. In
+   this context, Conda acts as the external package manager / distro
+   and pip as the Python-specific one.
+
+   In some sense, this is similar to the first case, since Conda
+   provides its own installation of the Python interpreter.
+
+   We don't believe this PEP requires any changes to Conda, and
+   versions of pip that have implemented the changes in this PEP will
+   continue to behave as they currently do inside Conda environments.
+   (That said, it may be worth considering whether to use separate
+   ``sysconfig`` schemes for pip-installed and Conda-installed
+   software, for the same reasons it's a good idea for other distros.)
+
+7. By a "developer-facing distro," we mean a specific type of distro
+   where direct users of Python or other languages in the distro are
+   expected or encouraged to make changes to the distro itself if they
+   wish to add libraries. Common examples include private "monorepos"
+   at software development companies, where a single repository builds
+   both third-party and in-house software, and the direct users of the
+   distro's Python interpreter are generally software developers
+   writing said in-house software. User-level package managers like
+   Nixpkgs_ may also count, because they encourage users of Nix who
+   are Python developers to `package their software for Nix`__.
+
+   In these cases, the distro may want to respond to an attempted
+   ``pip install`` with guidance encouraging use of the distro's own
+   facilities for adding new packages, along with a link to
+   documentation.
+
+   If the distro supports/encourages creating a virtual environment
+   from the distro's Python interpreter, there may also be custom
+   instructions for how to properly set up a virtual environment (as
+   for example Nixpkgs does).
+
+   .. _Nixpkgs: https://github.com/NixOS/nixpkgs
+
+   .. __: https://nixos.wiki/wiki/Python
+
+8. When building distro Python packages for a distro Python (case 2),
+   it may be useful to have ``pip install`` be usable as part of the
+   distro's package build process. (Consider, for instance, building a
+   ``python-xyz`` RPM by using ``pip install .`` inside an sdist /
+   source tarball for ``xyz``.) The distro may also want to use a more
+   targeted but still Python-specific installation tool such as
+   installer_.
+
+   .. _installer: https://installer.rtfd.io/
+
+   For this case, the build process will need to find some way to
+   suppress the marker file to allow ``pip install`` to work, and will
+   probably need to point the Python-specific tool at the distro's
+   ``sysconfig`` scheme instead of the shipped default. See the
+   `Recommendations for distros`_ section for more discussion on how
+   to implement this.
+
+   As a result of this PEP, pip will no longer be able to remove
+   packages already on the system. However, this behavior change is
+   fine because a package build process should not (and generally
+   cannot) include instructions to delete some other files on the
+   system; it can only package up its own files.
+
+9. A distro Python used with ``PYTHONHOME`` to set up an alternative
+   Python environment (as opposed to a virtual environment), where
+   ``PYTHONHOME`` is set to some directory copied directly from the
+   distro Python (e.g., ``cp -a /usr/lib/python3.x pyhome/lib``).
+
+   Assuming there are no modifications, then the behavior is just like
+   the underlying distro Python (case 2). So there are behavior
+   changes - you can no longer ``pip install`` by default, and if you
+   override it, it will no longer delete externally-installed packages
+   (i.e., Python packages that were copied from the OS and live in the
+   OS-managed ``sys.path`` entry).
+
+   This behavior change seems to be defensible, in that if your
+   ``PYTHONHOME`` is a straight copy of the distro's Python, it should
+   behave like the distro's Python.
+
+10. A distro Python (or any Python interpreter) used with a
+    ``PYTHONHOME`` taken from a compatible unmodified upstream Python.
+
+    Because the behavior changes in this PEP are keyed off of files in
+    the standard library (the marker file in ``stdlib`` and the
+    behavior of the ``sysconfig`` module), the behavior is just like
+    an unmodified upstream CPython (case 1).
+
+Specification
+=============
+
+Marking an interpreter as using an external package manager
+-----------------------------------------------------------
+
+Before a Python-specific package installer (that is, a tool such as
+pip - not an external tool such as apt) installs a package into a
+certain Python context, it should make the following checks by
+default:
+
+1. Is it running outside of a virtual environment? It can determine
+   this by whether ``sys.prefix == sys.base_prefix`` (but see
+   `Backwards Compatibility`_).
+
+2. Is there an ``EXTERNALLY-MANAGED`` file in the directory identified
+   by ``sysconfig.get_path("stdlib",
+   sysconfig.get_default_scheme())``?
+
+If both of these conditions are true, the installer should exit with
+an error message indicating that package installation into this Python
+interpreter's directory are disabled outside of a virtual environment.
+
+The installer should have a way for the user to override these rules,
+such as a command-line flag ``--break-system-packages``. This option
+should not be enabled by default and should carry some connotation
+that its use is risky.
+
+The ``EXTERNALLY-MANAGED`` file is an INI-style metadata file intended
+to be parsable by the standard library configparser_ module. If the
+file can be parsed by
+``configparser.ConfigParser(interpolation=None)`` using the UTF-8
+encoding, and it contains a section ``[externally-managed]``, then the
+installer should look for an error message specified in the file and
+output it as part of its error. If the first element of the tuple
+returned by ``locale.getlocale(locale.LC_MESSAGES)``, i.e., the
+language code, is not ``None``, it should look for the error message
+as the value of a key named ``Error-`` followed by the language code.
+If that key does not exist, and if the language code contains
+underscore or hyphen, it should look for a key named ``Error-``
+followed by the portion of the language code before the underscore or
+hyphen. If it cannot find either of those, or if the language code is
+``None``, it should look for a key simply named ``Error``.
+
+.. _configparser: https://docs.python.org/3/library/configparser.html
+
+If the installer cannot find an error message in the file (either
+because the file cannot be parsed or because no suitable error key
+exists), then the installer should just use a pre-defined error
+message of its own, which should suggest that the user create a
+virtual environment to install packages.
+
+Software distributors who have a non-Python-specific package manager
+that manages libraries in the ``sys.path`` of their Python package
+should, in general, ship a ``EXTERNALLY-MANAGED`` file in their
+standard library directory. For instance, Debian may ship a file in
+``/usr/lib/python3.9/EXTERNALLY-MANAGED`` consisting of something like
+
+::
+
+    [externally-managed]
+    Error=To install Python packages system-wide, try apt install
+     python3-xyz, where xyz is the package you are trying to
+     install.
+
+     If you wish to install a non-Debian-packaged Python package,
+     create a virtual environment using python3 -m venv path/to/venv.
+     Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
+     sure you have python3-full installed.
+
+     If you wish to install a non-Debian packaged Python application,
+     it may be easiest to use pipx install xyz, which will manage a
+     virtual environment for you. Make sure you have pipx installed.
+
+     See /usr/share/doc/python3.9/README.venv for more information.
+
+which provides useful and distro-relevant information
+to a user trying to install a package. Optionally,
+translations can be provided in the same file:
+
+::
+
+    Error-de_DE=Wenn ist das Nunstück git und Slotermeyer?
+
+     Ja! Beiherhund das Oder die Virtualenvironment gersput!
+
+In certain contexts, such as single-application container images that
+aren't updated after creation, a distributor may choose not to ship an
+``EXTERNALLY-MANAGED`` file, so that users can install whatever they
+like (as they can today) without having to manually override this
+rule.
+
+Writing to only the target ``sysconfig`` scheme
+-----------------------------------------------
+
+Usually, a Python package installer installs to directories in a
+scheme returned by the ``sysconfig`` standard library package.
+Ordinarily, this is the scheme returned by
+``sysconfig.get_default_scheme()``, but based on configuration (e.g.
+``pip install --user``), it may use a different scheme.
+
+Whenever the installer is installing to a ``sysconfig`` scheme, this
+PEP specifies that the installer should never modify or delete files
+outside of that scheme. For instance, if it's upgrading a package, and
+the package is already installed in a directory outside that scheme
+(perhaps in a directory from another scheme), it should leave the
+existing files alone.
+
+If the installer does end up shadowing an existing installation during
+an upgrade, we recommend that it produces a warning at the end of its
+run.
+
+If the installer is installing to a location outside of a
+``sysconfig`` scheme (e.g., ``pip install --target``), then this
+subsection does not apply.
+
+Recommendations for distros
+===========================
+
+This section is non-normative. It provides best practices we believe
+distros should follow unless they have a specific reason otherwise.
+
+Mark the installation as externally managed
+-------------------------------------------
+
+Distros should create an ``EXTERNALLY-MANAGED`` file in their
+``stdlib`` directory.
+
+Guide users towards virtual environments
+----------------------------------------
+
+The file should contain a useful and distro-relevant error message
+indicating both how to install system-wide packages via the distro's
+package manager and how to set up a virtual environment. If your
+distro is often used by users in a state where the ``python3`` command
+is available (and especially where ``pip`` or ``get-pip`` is
+available) but ``python3 -m venv`` does not work, the message should
+indicate clearly how to make ``python3 -m venv`` work properly.
+
+Consider packaging pipx_, a tool for installing Python-language
+applications, and suggesting it in the error. pipx automatically
+creates a virtual environment for that application alone, which is a
+much better default for end users who want to install some
+Python-language software (which isn't available in the distro) but are
+not themselves Python users. Packaging pipx in the distro avoids the
+irony of instructing users to ``pip install --user
+--break-system-packages pipx`` to *avoid* breaking system packages.
+Consider arranging things so your distro's package / environment for
+Python for end users (e.g., ``python3`` on Fedora or ``python3-full``
+on Debian) depends on pipx.
+
+.. _pipx: https://github.com/pypa/pipx
+
+Keep the marker file in container images
+----------------------------------------
+
+Distros that produce official images for single-application containers
+(e.g., Docker container images) should keep the
+``EXTERNALLY-MANAGED`` file, preferably in a way that makes it not
+go away if a user of that image installs package updates inside
+their image (think ``RUN apt-get dist-upgrade``).
+
+Create separate distro and local directories
+--------------------------------------------
+
+Distros should place two separate paths on the system interpreter's
+``sys.path``, one for distro-installed packages and one for packages
+installed by the local system administrator, and configure
+``sysconfig.get_default_scheme()`` to point at the latter path. This
+ensures that tools like pip will not modify distro-installed packages.
+The path for the local system administrator should come before the
+distro path on ``sys.path`` so that local installs take preference
+over distro packages.
+
+For example, Fedora and Debian (and their derivatives) both implement
+this split by using ``/usr/local`` for locally-installed packages and
+``/usr`` for distro-installed packages. Fedora uses
+``/usr/local/lib/python3.x/site-packages`` vs.
+``/usr/lib/python3.x/site-packages``. (Debian uses
+``/usr/local/lib/python3/dist-packages`` vs.
+``/usr/lib/python3/dist-packages`` as an additional layer of
+separation from a locally-compiled Python interpreter: if you build
+and install upstream CPython in ``/usr/local/bin``, it will look at
+``/usr/local/lib/python3/site-packages``, and Debian wishes to make
+sure that packages installed via the locally-built interpreter don't
+show up on ``sys.path`` for the distro interpreter.)
+
+Note that the ``/usr/local`` vs. ``/usr`` split is analogous to how
+the ``PATH`` environment variable typically includes
+``/usr/local/bin:/usr/bin`` and non-distro software installs to
+``/usr/local`` by default. This split is `recommended by the
+Filesystem Hierarchy Standard`__.
+
+.. __: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html
+
+There are two ways you could do this. One is, if you are building and
+packaging Python libraries directly (e.g., your packaging helpers
+unpack a :pep:`517`-built wheel or call ``setup.py install``), arrange
+for those tools to use a directory that is not in a ``sysconfig``
+scheme but is still on ``sys.path``.
+
+The other is to arrange for the default ``sysconfig`` scheme to change
+when running inside a package build versus when running on an
+installed system. The ``sysconfig`` customization hooks from
+bpo-43976_ should make this easy (once accepted and implemented):
+make your packaging tool set an
+environment variable or some other detectable configuration, and
+define a ``get_preferred_schemes`` function to return a different
+scheme when called from inside a package build. Then you can use ``pip
+install`` as part of your distro packaging.
+
+.. _bpo-43976: https://bugs.python.org/issue43976
+
+We propose adding a ``--scheme=...`` option to instruct pip to run
+against a specific scheme. (See `Implementation Notes`_ below for how
+pip currently determines schemes.) Once that's available, for local
+testing and possibly for actual packaging, you would be able to run
+something like ``pip install --scheme=posix_distro`` to explicitly
+install a package into your distro's location (bypassing
+``get_preferred_schemes``). One could also, if absolutely needed, use
+``pip uninstall --scheme=posix_distro`` to use pip to remove packages
+from the system-managed directory, which addresses the (hopefully
+theoretical) regression in use case 5 in Rationale_.
+
+To install packages with pip, you would also need to either suppress
+the ``EXTERNALLY-MANAGED`` marker file to allow pip to run or to
+override it on the command line. You may want to use the same means
+for suppressing the marker file in build chroots as you do in
+container images.
+
+The advantage of setting these up to be automatic (suppressing the
+marker file in your build environment and having
+``get_preferred_schemes`` automatically return your distro's scheme)
+is that an unadorned ``pip install`` will work inside a package build,
+which generally means that an unmodified upstream build script that
+happens to internally call ``pip install`` will do the right thing.
+You can, of course, just ensure that your packaging process always
+calls ``pip install --scheme=posix_distro --break-system-packages``,
+which would work too.
+
+The best approach here depends a lot on your distro's conventions and
+mechanisms for packaging.
+
+Similarly, the ``sysconfig`` paths that are not for importable Python
+code - that is, ``include``, ``platinclude``, ``scripts``, and
+``data`` - should also have two variants, one for use by
+distro-packaged software and one for use for locally-installed
+software, and the distro should be set up such that both are usable.
+For instance, a typical FHS-compliant distro will use
+``/usr/local/include`` for the default scheme's ``include`` and
+``/usr/include`` for distro-packaged headers and place both on the
+compiler's search path, and it will use ``/usr/local/bin`` for the
+default scheme's ``scripts`` and ``/usr/bin`` for distro-packaged
+entry points and place both on ``$PATH``.
+
+Backwards Compatibility
+=======================
+
+All of these mechanisms are proposed for new distro releases and new
+versions of tools like pip only.
+
+In particular, we strongly recommend that distros with a concept of
+major versions only add the marker file or change ``sysconfig``
+schemes in a new major version; otherwise there is a risk that, on an
+existing system, software installed via a Python-specific package
+manager now becomes unmanageable (without an override option). For a
+rolling-release distro, if possible, only add the marker file or
+change ``sysconfig`` schemes in a new Python minor version.
+
+One particular backwards-compatibility difficulty for package
+installation tools is likely to be managing environments created by
+old versions of ``virtualenv`` which have the latest version of the
+tool installed. A "virtual environment" now has a fairly precise
+definition: it uses the ``pyvenv.cfg`` mechanism, which causes
+``sys.base_prefix != sys.prefix``. It is possible, however, that a
+user may have an old virtual environment created by an older version
+of ``virtualenv``; as of this writing, pip supports Python 3.6
+onwards, which is in turn supported by ``virtualenv`` 15.1.0 onwards,
+so this scenario is possible. In older versions of ``virtualenv``, the
+mechanism is instead to set a new attribute, ``sys.real_prefix``, and
+it does not use the standard library support for virtual environments,
+so ``sys.base_prefix`` is the same as ``sys.prefix``. So the logic for
+robustly detecting a virtual environment is something like::
+
+    def is_virtual_environment():
+        return sys.base_prefix != sys.prefix or hasattr(sys, "real_prefix")
+
+Security Implications
+=====================
+
+The purpose of this feature is not to implement a security boundary;
+it is to discourage well-intended changes from unexpectedly breaking a
+user's environment. That is to say, the reason this PEP restricts
+``pip install`` outside a virtual environment is not that it's a
+security risk to be able to do so; it's that "There should be one--
+and preferably only one --obvious way to do it," and that way should
+be using a virtual environment. ``pip install`` outside a virtual
+environment is rather too obvious for what is almost always the wrong
+way to do it.
+
+If there is a case where a user should not be able to ``sudo pip
+install`` or ``pip install --user`` and add files to ``sys.path`` *for
+security reasons*, that needs to be implemented either via access
+control rules on what files the user can write to or an explicitly
+secured ``sys.path`` for the program in question. Neither of the
+mechanisms in this PEP should be interpreted as a way to address such
+a scenario.
+
+For those reasons, an attempted install with a marker file present is
+not a security incident, and there is no need to raise an auditing
+event for it. If the calling user legitimately has access to ``sudo
+pip install`` or ``pip install --user``, they can accomplish the same
+installation entirely outside of Python; if they do not legitimately
+have such access, that's a problem outside the scope of this PEP.
+
+The marker file itself is located in the standard library directory,
+which is a trusted location (i.e., anyone who can write to the marker
+file used by a particular installer could, presumably, run arbitrary
+code inside the installer). Therefore, there is generally no need to
+filter out terminal escape sequences or other potentially-malicious
+content in the error message.
+
+Alternatives
+==============
+
+There are a number of similar proposals we considered that this PEP
+rejects or defers, largely to preserve the behavior in the
+case-by-case analysis in Rationale_.
+
+Marker file
+-----------
+
+Should the marker file be in ``sys.path``, marking a particular
+directory as not to be written to by a Python-specific package
+manager? This would help with the second problem addressed by this PEP
+(not overwriting deleting distro-owned files) but not the first
+(incompatible installs). A directory-specific marker in
+``/usr/lib/python3.x/site-packages`` would not discourage
+installations into either ``/usr/local/lib/python3.x/site-packages``
+or ``~/.local/lib/python3.x/site-packages``, both of which are on
+``sys.path`` for ``/usr/bin/python3``. In other words, the marker file
+should not be interpreted as marking a single *directory* as
+externally managed (even though it happens to be in a directory on
+``sys.path``); it marks the entire *Python installation* as externally
+managed.
+
+Another variant of the above: should the marker file be in
+``sys.path``, where if it can be found in any directory in
+``sys.path``, it marks the installation as externally managed? An
+apparent advantage of this approach is that it automatically disables
+itself in virtual environments. Unfortunately, This has the wrong
+behavior with a ``--system-site-packages`` virtual environment, where
+the system-wide ``sys.path`` is visible but package installations are
+allowed. (It could work if the rule of exempting virtual environments
+is preserved, but that seems to have no advantage over the current
+scheme.)
+
+Should the marker just be a new attribute of a ``sysconfig`` scheme?
+There is some conceptual cleanliness to this, except that it's hard to
+override. We want to make it easy for container images, package build
+environments, etc. to suppress the marker file. A file that you can
+remove is easy; code in ``sysconfig`` is much harder to modify.
+
+Should the file be in ``/etc``? No, because again, it refers to a
+specific Python installation. A user who installs their own Python may
+well want to install packages within the global context of that
+interpreter.
+
+Should the configuration setting be in ``pip.conf`` or
+``distutils.cfg``? Apart from the above objections about marking an
+installation, this mechanism isn't specific to either of those tools.
+(It seems reasonable for pip to *also* implement a configuration flag
+for users to prevent themselves from performing accidental
+non-virtual-environment installs in any Python installation, but that
+is outside the scope of this PEP.)
+
+Should the file be TOML? TOML is gaining popularity for packaging (see
+e.g. :pep:`517`) but does not yet have an implementation in the standard
+library. Strictly speaking, this isn't a blocker - distros need only
+write the file, not read it, so they don't need a TOML library (the
+file will probably be written by hand, regardless of format), and
+packaging tools likely have a TOML reader already. However, the INI
+format is currently used for various other forms of packaging metadata
+(e.g., ``pydistutils.cfg`` and ``setup.cfg``), meets our needs, and is
+parsable by the standard library, and the pip maintainers expressed a
+preference to avoid using TOML for this yet.
+
+Should the file be ``email.message``-style? While this format is also
+used for packaging metadata (e.g. sdist and wheel metadata) and is
+also parsable by the standard library, it doesn't handle multi-line
+entries quite as clearly, and that is our primary use case.
+
+Should the marker file be executable Python code that evaluates
+whether installation should be allowed or not? Apart from the concerns
+above about having the file in ``sys.path``, we have a concern that
+making it executable is committing to too powerful of an API and risks
+making behavior harder to understand. (Note that the
+``get_default_scheme`` hook of bpo-43976_ is in fact executable, but
+that code needs to be supplied when the interpreter builds; it isn't
+intended to be supplied post-build.)
+
+When overriding the marker, should a Python-specific package manager
+be disallowed from shadowing a package installed by the external
+package manager (i.e., installing modules of the same name)? This
+would minimize the risk of breaking system software, but it's not
+clear it's worth the additional user experience complexity. There are
+legitimate use cases for shadowing system packages, and an additional
+command-line option to permit it would be more confusing. Meanwhile,
+not passing that option wouldn't eliminate the risk of breaking system
+software, which may be relying on a ``try: import xyz`` failing,
+finding a limited set of entry points, etc. Communicating this
+distinction seems difficult. We think it's a good idea for
+Python-specific package managers to print a warning if they shadow a
+package, but we think it's not worth disabling it by default.
+
+Why not use the ``INSTALLER`` file from :pep:`376` to determine who
+installed a package and whether it can be removed? First, it's
+specific to a particular package (it's in the package's ``dist-info``
+directory), so like some of the alternatives above, it doesn't provide
+information on an entire environment and whether package installations
+are permissible. :pep:`627` also updates :pep:`376` to prevent programmatic
+use of ``INSTALLER``, specifying that the file is "to be used for
+informational purposes only. [...] Our goal is supporting
+interoperating tools, and basing any action on which tool happened to
+install a package runs counter to that goal." Finally, as :pep:`627`
+envisions, there are legitimate use cases for one tool knowing how to
+handle packages installed by another tool; for instance, ``conda`` can
+safely remove a package installed by ``pip`` into a Conda environment.
+
+Why does the specification give no means for disabling package
+installations inside a virtual environment? We can't see a
+particularly strong use case for it (at least not one related to the
+purposes of this PEP). If you need it, it's simple enough to ``pip
+uninstall pip`` inside that environment, which should discourage at
+least unintentional changes to the environment (and this specification
+makes no provision to disable *intentional* changes, since after all
+the marker file can be easily removed).
+
+System Python
+-------------
+
+Shouldn't distro software just run with the distro ``site-packages``
+directory alone on ``sys.path`` and ignore the local system
+administrator's ``site-packages`` as well as the user-specific one?
+This is a worthwhile idea, and various versions of it have been
+circulating for a while under the name of "system Python" or "platform
+Python" (with a separate "user Python" for end users writing Python or
+installing Python software separate from the system). However, it's
+much more involved of a change. First, it would be a
+backwards-incompatible change. As mentioned in the Motivation_
+section, there are valid use cases for running distro-installed Python
+applications like Sphinx or Ansible with locally-installed Python
+libraries available on their ``sys.path``. A wholesale switch to
+ignoring local packages would break these use cases, and a distro
+would have to make a case-by-case analysis of whether an application
+ought to see locally-installed libraries or not.
+
+Furthermore, `Fedora attempted this change and reverted it`_, finding,
+ironically, that their implementation of the change `broke their
+package manager`_. Given that experience, there are clearly details to
+be worked out before distros can reliably implement that approach, and
+a PEP recommending it would be premature.
+
+.. _`Fedora attempted this change and reverted it`: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/SEFUWW4XZBTVOAQ36XOJQ72PIICMFOSN/
+.. _`broke their package manager`: https://bugzilla.redhat.com/show_bug.cgi?id=1483342
+
+This PEP is intended to be a complete and self-contained change that
+is independent of a distributor's decision for or against "system
+Python" or similar proposals. It is not incompatible with a distro
+implementing "system Python" in the future, and even though both
+proposals address the same class of problems, there are still
+arguments in favor of implementing something like "system Python" even
+after implementing this PEP. At the same time, though, this PEP
+specifically tries to make a more targeted and minimal change, such
+that it can be implemented by distributors who don't expect to adopt
+"system Python" (or don't expect to implement it immediately). The
+changes in this PEP stand on their own merits and are not an
+intermediate step for some future proposal. This PEP reduces (but does
+not eliminate) the risk of breaking system software while minimizing
+(but not completely avoiding) breaking changes, which should therefore
+be much easier to implement than the full "system Python" idea, which
+comes with the downsides mentioned above.
+
+We expect that the guidance in this PEP - that users should use
+virtual environments whenever possible and that distros should have
+separate ``sys.path`` directories for distro-managed and
+locally-managed modules - should make further experiments easier in
+the future. These may include distributing wholly separate "system"
+and "user" Python interpreters, running system software out of a
+distro-owned virtual environment or ``PYTHONHOME`` (but shipping a
+single interpreter), or modifying the entry points for certain
+software (such as the distro's package manager) to use a ``sys.path``
+that only sees distro-managed directories. Those ideas themselves,
+however, remain outside the scope of this PEP.
+
+Implementation Notes
+====================
+
+This section is non-normative and contains notes relevant to both the
+specification and potential implementations.
+
+Currently, pip does not directly expose a way to choose a target
+``sysconfig`` scheme, but it has three ways of looking up schemes when
+installing:
+
+``pip install``
+    Calls ``sysconfig.get_default_scheme()``, which is usually (in
+    upstream CPython and most current distros) the same as
+    ``get_preferred_scheme('prefix')``.
+
+``pip install --prefix=/some/path``
+    Calls ``sysconfig.get_preferred_scheme('prefix')``.
+
+``pip install --user``
+    Calls ``sysconfig.get_preferred_scheme('user')``.
+
+Finally, ``pip install --target=/some/path`` writes directly to
+``/some/path`` without looking up any schemes.
+
+Debian currently carries a `patch to change the default install
+location inside a virtual environment`__, using a few heuristics
+(including checking for the ``VIRTUAL_ENV`` environment variable),
+largely so that the directory used in a virtual environment remains
+``site-packages`` and not ``dist-packages``. This does not
+particularly affect this proposal, because the implementation of that
+patch does not actually change the default ``sysconfig`` scheme, and
+notably does not change the result of
+``sysconfig.get_path("stdlib")``.
+
+.. __: https://sources.debian.org/src/python3.7/3.7.3-2+deb10u3/debian/patches/distutils-install-layout.diff/
+
+Fedora currently carries a `patch to change the default install
+location when not running inside rpmbuild`__, which they use to
+implement the two-system-wide-directories approach. This is
+conceptually the sort of hook envisioned by bpo-43976_, except
+implemented as a code patch to ``distutils`` instead of as a changed
+``sysconfig`` scheme.
+
+.. __: https://src.fedoraproject.org/rpms/python3.9/blob/f34/f/00251-change-user-install-location.patch
+
+The implementation of ``is_virtual_environment`` above, as well as the
+logic to load the ``EXTERNALLY-MANAGED`` file and find the error
+message from it, may as well get added to the standard library
+(``sys`` and ``sysconfig``, respectively), to centralize their
+implementations, but they don't need to be added yet.
+
+References
+==========
+
+For additional background on these problems and previous attempts to
+solve them, see `Debian bug 771794`_ "pip silently removes/updates
+system provided python packages" from 2014, Fedora's 2018 article
+`Making sudo pip safe`_ about pointing ``sudo pip`` at /usr/local
+(which acknowledges that the changes still do not make ``sudo pip``
+completely safe), pip issues 5605_ ("Disable upgrades to existing
+python modules which were not installed via pip") and 5722_ ("pip
+should respect /usr/local") from 2018, and the post-PyCon US 2019
+discussion thread `Playing nice with external package managers`_.
+
+.. _`Debian bug 771794`: https://bugs.debian.org/771794
+
+.. _`Making sudo pip safe`: https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe
+
+.. _5605: https://github.com/pypa/pip/issues/5605
+
+.. _5722: https://github.com/pypa/pip/issues/5722
+
+.. _`Playing nice with external package managers`: https://discuss.python.org/t/playing-nice-with-external-package-managers/1968
+
+.. [#pip] https://pip.pypa.io/en/stable/
+
+.. [#easy-install] https://setuptools.readthedocs.io/en/latest/deprecated/easy_install.html
+   (Note that the ``easy_install`` command was removed in
+   setuptools version 52, released 23 January 2021.)
+
+.. [#Conda] https://conda.io
+
+Copyright
+=========
+
+This document is placed in the public domain or under the
+CC0-1.0-Universal license, whichever is more permissive.
+
+
+
 History
 =======
 - `June 2022 `_: ``EXTERNALLY-MANAGED`` marker file was originally specified in :pep:`668#marking-an-interpreter-as-using-an-external-package-manager`.

From b590452e5ee3949f043e2ecd8bba990046b97729 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sun, 5 Nov 2023 00:18:28 +0100
Subject: [PATCH 0482/1072] PEP 668: Editing to fit the PUG

---
 .../externally-managed-environments.rst       | 738 ++----------------
 1 file changed, 45 insertions(+), 693 deletions(-)

diff --git a/source/specifications/externally-managed-environments.rst b/source/specifications/externally-managed-environments.rst
index 8cd3b840a..f6845e737 100644
--- a/source/specifications/externally-managed-environments.rst
+++ b/source/specifications/externally-managed-environments.rst
@@ -15,66 +15,25 @@ environments can be confusing at best and outright break the entire underlying
 operating system at worst. Documentation and interoperability guides only go
 so far in resolving such problems.
 
-:pep:`668` defined an ``EXTERNALLY-MANAGED`` marker file that allows a Python
-installation to indicate to Python-specific tools such as ``pip`` that they
+This specification defines an ``EXTERNALLY-MANAGED`` marker file that allows a
+Python installation to indicate to Python-specific tools such as ``pip`` that they
 neither install nor remove packages into the interpreter’s default installation
 environment, and should instead guide the end user towards using
 :ref:`virtual-environments`.
 
-PEP: 668
-Title: Marking Python base environments as “externally managed”
-Author: Geoffrey Thomas ,
-        Matthias Klose ,
-        Filipe Laíns ,
-        Donald Stufft ,
-        Tzu-ping Chung ,
-        Stefano Rivera ,
-        Elana Hashman ,
-        Pradyun Gedam 
-PEP-Delegate: Paul Moore 
-Discussions-To: https://discuss.python.org/t/10302
-Status: Accepted
-Type: Standards Track
-Topic: Packaging
-Content-Type: text/x-rst
-Created: 18-May-2021
-Post-History: 28-May-2021
-Resolution: https://discuss.python.org/t/10302/44
-
-Abstract
-========
-
-A long-standing practical problem for Python users has been conflicts
-between OS package managers and Python-specific package management
-tools like pip. These conflicts include both Python-level API
-incompatibilities and conflicts over file ownership.
-
-Historically, Python-specific package management tools have defaulted
-to installing packages into an implicit global context. With the
-standardization and popularity of virtual environments, a better
-solution for most (but not all) use cases is to use Python-specific
-package management tools only within a virtual environment.
-
-This PEP proposes a mechanism for a Python installation to communicate
-to tools like pip that its global package installation context is
-managed by some means external to Python, such as an OS package
-manager. It specifies that Python-specific package management tools
-should neither install nor remove packages into the interpreter's
-global context, by default, and should instead guide the end user
-towards using a virtual environment.
-
 It also standardizes an interpretation of the ``sysconfig`` schemes so
 that, if a Python-specific package manager is about to install a
 package in an interpreter-wide context, it can do so in a manner that
 will avoid conflicting with the external package manager and reduces
 the risk of breaking software shipped by the external package manager.
 
+
 Terminology
 ===========
 
-A few terms used in this PEP have multiple meanings in the contexts
-that it spans. For clarity, this PEP uses the following terms in
-specific ways:
+A few terms used in this specification have multiple meanings in the
+contexts that it spans. For clarity, this specification uses the following
+terms in specific ways:
 
 distro
     Short for "distribution," a collection of various sorts of
@@ -104,12 +63,10 @@ distro
 package
     A unit of software that can be installed and used within Python.
     That is, this refers to what Python-specific packaging tools tend
-    to call a "`distribution package`_" or simply a "distribution";
+    to call a :term:`distribution package` or simply a "distribution";
     the colloquial abbreviation "package" is used in the sense of the
     Python Package Index.
 
-    .. _`distribution package`: https://packaging.python.org/glossary/#term-Distribution-Package
-
     This document does not use "package" in the sense of an importable
     name that contains Python modules, though in many cases, a
     distribution package consists of a single importable package of
@@ -123,26 +80,36 @@ package
     plus the Python package name.)
 Python-specific package manager
     A tool for installing, upgrading, and/or removing Python packages
-    in a manner that conforms to Python packaging standards (such as
-    :pep:`376` and :pep:`427`). The most popular Python-specific package
-    manager is pip [#pip]_; other examples include the old Easy
-    Install command [#easy-install]_ as well as direct usage of a
+    in a manner that conforms to Python packaging standards.
+    The most popular Python-specific package
+    manager is pip_; other examples include the old `Easy
+    Install command `_ as well as direct usage of a
     ``setup.py`` command.
 
-    (Conda [#conda]_ is a bit of a special case, as the ``conda``
+    .. _pip: https://pip.pypa.io/en/stable/
+    .. _easy-install: https://setuptools.readthedocs.io/en/latest/deprecated/easy_install.html
+
+    (Note that the ``easy_install`` command was removed in
+    setuptools version 52, released 23 January 2021.)
+
+
+    (Conda_ is a bit of a special case, as the ``conda``
     command can install much more than just Python packages, making it
     more like a distro package manager in some senses. Since the
     ``conda`` command generally only operates on Conda-created
     environments, most of the concerns in this document do not apply
     to ``conda`` when acting as a Python-specific package manager.)
+
+    .. _conda: https://conda.io
 distro package manager
     A tool for installing, upgrading, and/or removing a distro's
     packages in an installed instance of that distro, which is capable
     of installing Python packages as well as non-Python packages, and
     therefore generally has its own database of installed software
-    unrelated to :pep:`376`. Examples include ``apt``, ``dpkg``, ``dnf``,
-    ``rpm``, ``pacman``, and ``brew``. The salient feature is that if
-    a package was installed by a distro package manager, removing or
+    unrelated to the :ref:`database of installed distributions
+    `. Examples include ``apt``, ``dpkg``,
+    ``dnf``, ``rpm``, ``pacman``, and ``brew``. The salient feature is
+    that if a package was installed by a distro package manager, removing or
     upgrading it in a way that would satisfy a Python-specific package
     manager will generally leave a distro package manager in an
     inconsistent state.
@@ -159,83 +126,12 @@ shadow
     a later ``sys.path`` entry, then ``import a`` returns the module
     from the former, and we say that A 2.0 shadows A 1.0.
 
-Motivation
-==========
-
-Thanks to Python's immense popularity, software distros (by which we
-mean Linux and other OS distros as well as overlay distros like
-Homebrew and MacPorts) generally ship Python for two purposes: as a
-software package to be used in its own right by end users, and as a
-language dependency for other software in the distro.
-
-For example, Fedora and Debian (and their downstream distros, as well
-as many others) ship a ``/usr/bin/python3`` binary which provides the
-``python3`` command available to end users as well as the
-``#!/usr/bin/python3`` shebang for Python-language software included
-in the distro. Because there are no official binary releases of Python
-for Linux/UNIX, almost all Python end users on these OSes use the
-Python interpreter built and shipped with their distro.
-
-The ``python3`` executable available to the users of the distro and
-the ``python3`` executable available as a dependency for other
-software in the distro are typically the same binary. This means that
-if an end user installs a Python package using a tool like ``pip``
-outside the context of a virtual environment, that package is visible
-to Python-language software shipped by the distro. If the
-newly-installed package (or one of its dependencies) is a newer,
-backwards-incompatible version of a package that was installed through
-the distro, it may break software shipped by the distro.
-
-This may pose a critical problem for the integrity of distros, which
-often have package-management tools that are themselves written in
-Python. For example, it's possible to unintentionally break Fedora's
-``dnf`` command with a ``pip install`` command, making it hard to
-recover.
-
-This applies both to system-wide installs (``sudo pip install``) as
-well as user home directory installs (``pip install --user``), since
-packages in either location show up on the ``sys.path`` of
-``/usr/bin/python3``.
-
-There is a worse problem with system-wide installs: if you attempt to
-recover from this situation with ``sudo pip uninstall``, you may end
-up removing packages that are shipped by the system's package manager.
-In fact, this can even happen if you simply upgrade a package - pip
-will try to remove the old version of the package, as shipped by the
-OS. At this point it may not be possible to recover the system to a
-consistent state using just the software remaining on the system.
-
-Over the past many years, a consensus has emerged that the best way to
-install Python libraries or applications (when not using a distro's
-package) is to use a virtual environment. This approach was
-popularized by the PyPA `virtualenv`_ project, and a simple version of
-that approach is now available in the Python standard library as
-``venv``. Installing a Python package into a virtualenv prevents it
-from being visible to the unqualified ``/usr/bin/python3`` interpreter
-and prevents breaking system software.
-
-.. _virtualenv: https://virtualenv.pypa.io/en/latest/
-
-In some cases, however, it's useful and intentional to install a
-Python package from outside of the distro that influences the behavior
-of distro-shipped commands. This is common in the case of software
-like Sphinx or Ansible which have a mechanism for writing
-Python-language extensions. A user may want to use their distro's
-version of the base software (for reasons of paid support or security
-updates) but install a small extension from PyPI, and they'd want that
-extension to be importable by the software in their base system.
-
-While this continues to carry the risk of installing a newer version
-of a dependency than the operating system expects or otherwise
-negatively affecting the behavior of an application, it does not need
-to carry the risk of removing files from the operating system. A tool
-like pip should be able to install packages in some directory on the
-default ``sys.path``, if specifically requested, without deleting
-files owned by the system's package manager.
-
-Therefore, this PEP proposes two things.
-
-First, it proposes **a way for distributors of a Python interpreter to
+Overview
+========
+
+This specification is twofold.
+
+First, it describes **a way for distributors of a Python interpreter to
 mark that interpreter as having its packages managed by means external
 to Python**, such that Python-specific tools like pip should not
 change the installed packages in the interpreter's global ``sys.path``
@@ -259,284 +155,9 @@ managed packages, and one for unmanaged packages installed by the end
 user, and ensure that installing unmanaged packages will not delete
 (or overwrite) files owned by the external package manager.
 
-Rationale
-=========
-
-As described in detail in the next section, the first behavior change
-involves creating a marker file named ``EXTERNALLY-MANAGED``, whose
-presence indicates that non-virtual-environment package installations
-are managed by some means external to Python, such as a distro's
-package manager. This file is specified to live in the ``stdlib``
-directory in the default ``sysconfig`` scheme, which marks the
-interpreter / installation as a whole, not a particular location on
-``sys.path``. The reason for this is that, as identified above, there
-are two related problems that risk breaking an externally-managed
-Python: you can install an incompatible new version of a package
-system-wide (e.g., with ``sudo pip install``), and you can install one
-in your user account alone, but in a location that is on the standard
-Python command's ``sys.path`` (e.g., with ``pip install --user``). If
-the marker file were in the system-wide ``site-packages`` directory,
-it would not clearly apply to the second case. The `Alternatives`_
-section has further discussion of possible locations.
-
-The second behavior change takes advantage of the existing
-``sysconfig`` setup in distros that have already encountered this
-class of problem, and specifically addresses the problem of a
-Python-specific package manager deleting or overwriting files that are
-owned by an external package manager.
-
-Use cases
----------
-
-The changed behavior in this PEP is intended to "do the right thing"
-for as many use cases as possible. In this section, we consider the
-changes specified by this PEP for several representative use cases /
-contexts. Specifically, we ask about the two behaviors that could be
-changed by this PEP:
-
-1. Will a Python-specific installer tool like ``pip install`` permit
-   installations by default, after implementation of this PEP?
-
-2. If you do run such a tool, should it be willing to delete packages
-   shipped by the external (non-Python-specific) package manager for
-   that context, such as a distro package manager?
-
-(For simplicity, this section discusses pip as the Python-specific
-installer tool, though the analysis should apply equally to any other
-Python-specific package management tool.)
-
-This table summarizes the use cases discussed in detail below:
-
-==== ================================= =========================== ===================================================
-Case Description                       ``pip install`` permitted   Deleting externally-installed packages permitted
-==== ================================= =========================== ===================================================
-1    Unpatched CPython                 Currently yes; stays yes    Currently yes; stays yes
-2    Distro ``/usr/bin/python3``       Currently yes; becomes no   Currently yes (except on Debian); becomes no
-                                       (assuming the distro
-                                       adds a marker file)
-3    Distro Python in venv             Currently yes; stays yes    There are no externally-installed packages
-4    Distro Python in venv             Currently yes; stays yes    Currently no; stays no
-     with ``--system-site-packages``
-5    Distro Python in Docker           Currently yes; becomes no    Currently yes; becomes no
-                                       (assuming the distro
-                                       adds a marker file)
-6    Conda environment                 Currently yes; stays yes    Currently yes; stays yes
-7    Dev-facing distro                 Currently yes; becomes no   Currently often yes; becomes no
-                                       (assuming they add a        (assuming they configure ``sysconfig`` as needed)
-                                       marker file)
-8    Distro building packages          Currently yes; can stay yes Currently yes; becomes no
-9    ``PYTHONHOME`` copied from        Currently yes; becomes no   Currently yes; becomes no
-     a distro Python stdlib
-10   ``PYTHONHOME`` copied from        Currently yes; stays yes    Currently yes; stays yes
-     upstream Python stdlib
-==== ================================= =========================== ===================================================
-
-In more detail, the use cases above are:
-
-1. A standard unpatched CPython, without any special configuration of
-   or patches to ``sysconfig`` and without a marker file. This PEP
-   does not change its behavior.
-
-   Such a CPython should (regardless of this PEP) not be installed in
-   a way that overlaps any distro-installed Python on the same system.
-   For instance, on an OS that ships Python in ``/usr/bin``, you
-   should not install a custom CPython built with ``./configure
-   --prefix=/usr``, or it will overwrite some files from the distro
-   and the distro will eventually overwrite some files from your
-   installation. Instead, your installation should be in a separate
-   directory (perhaps ``/usr/local``, ``/opt``, or your home
-   directory).
-
-   Therefore, we can assume that such a CPython has its own ``stdlib``
-   directory and its own ``sysconfig`` schemes that do not overlap any
-   distro-installed Python. So any OS-installed packages are not
-   visible or relevant here.
-
-   If there is a concept of "externally-installed" packages in this
-   case, it's something outside the OS and generally managed by
-   whoever built and installed this CPython. Because the installer
-   chose not to add a marker file or modify ``sysconfig`` schemes,
-   they're choosing the current behavior, and ``pip install`` can
-   remove any packages available in this CPython.
-
-2. A distro's ``/usr/bin/python3``, either when running ``pip
-   install`` as root or ``pip install --user``, following our
-   `Recommendations for distros`_.
-
-   These recommendations include shipping a marker file in the
-   ``stdlib`` directory, to prevent ``pip install`` by default, and
-   placing distro-shipped packages in a location other than the
-   default ``sysconfig`` scheme, so that ``pip`` as root does not
-   write to that location.
-
-   Many distros (including Debian, Fedora, and their derivatives) are
-   already doing the latter.
-
-   On Debian and derivatives, ``pip install`` does not currently
-   delete distro-installed packages, because Debian carries a `patch
-   to pip to prevent this`__. So, for those distros, this PEP is not a
-   behavior change; it simply standardizes that behavior in a way that
-   is no longer Debian-specific and can be included into upstream pip.
-
-   .. __: https://sources.debian.org/src/python-pip/20.3.4-2/debian/patches/hands-off-system-packages.patch/
-
-   (We have seen user reports of externally-installed packages being
-   deleted on Debian or a derivative. We suspect this is because the
-   user has previously run ``sudo pip install --upgrade pip`` and
-   therefore now has a version of ``/usr/bin/pip`` without the Debian
-   patch; standardizing this behavior in upstream package installers
-   would address this problem.)
-
-3. A distro Python when used inside a virtual environment (either from
-   ``venv`` or ``virtualenv``).
-
-   Inside a virtual environment, all packages are owned by that
-   environment. Even when ``pip``, ``setuptools``, etc. are installed
-   into the environment, they are and should be managed by tools
-   specific to that environment; they are not system-managed.
-
-4. A distro Python when used inside a virtual environment with
-   ``--system-site-packages``. This is like the previous case, but
-   worth calling out explicitly, because anything on the global
-   ``sys.path`` is visible.
-
-   Currently, the answer to "Will ``pip`` delete externally-installed
-   packages" is no, because pip has a special case for running in a
-   virtual environment and attempting to delete packages outside it.
-   After this PEP, the answer remains no, but the reasoning becomes
-   more general: system site packages will be outside any of the
-   ``sysconfig`` schemes used for package management in the
-   environment.
-
-5. A distro Python when used in a single-application container image
-   (e.g., a Docker container). In this use case, the risk of breaking
-   system software is lower, since generally only a single application
-   runs in the container, and the impact is lower, since you can
-   rebuild the container and you don't have to struggle to recover a
-   running machine. There are also a large number of existing
-   Dockerfiles with an unqualified ``RUN pip install ...`` statement,
-   etc., and it would be good not to break those. So, builders of base
-   container images may want to ensure that the marker file is not
-   present, even if the underlying OS ships one by default.
-
-   There is a small behavior change: currently, ``pip`` run as root
-   will delete externally-installed packages, but after this PEP it
-   will not. We don't propose a way to override this. However, since
-   the base image is generally minimal, there shouldn't be much of a
-   use case for simply uninstalling packages (especially without using
-   the distro's own tools). The common case is when pip wants to
-   upgrade a package, which previously would have deleted the old
-   version (except on Debian). After this change, the old version will
-   still be on disk, but pip will still *shadow* externally-installed
-   packages, and we believe this to be sufficient for this not to be a
-   breaking change in practice - a Python ``import`` statement will
-   still get you the newly-installed package.
-
-   If it becomes necessary to have a way to do this, we suggest that
-   the distro should document a way for the installer tool to access
-   the ``sysconfig`` scheme used by the distro itself. See the
-   `Recommendations for distros`_ section for more discussion.
-
-   It is the view of the authors of this PEP that it's still a good
-   idea to use virtual environments with distro-installed Python
-   interpreters, even in single-application container images. Even
-   though they run a single *application*, that application may run
-   commands from the OS that are implemented in Python, and if you've
-   installed or upgraded the distro-shipped Python packages using
-   Python-specific tools, those commands may break.
-
-6. Conda specifically supports the use of non-``conda`` tools like pip
-   to install software not available in the Conda repositories. In
-   this context, Conda acts as the external package manager / distro
-   and pip as the Python-specific one.
-
-   In some sense, this is similar to the first case, since Conda
-   provides its own installation of the Python interpreter.
-
-   We don't believe this PEP requires any changes to Conda, and
-   versions of pip that have implemented the changes in this PEP will
-   continue to behave as they currently do inside Conda environments.
-   (That said, it may be worth considering whether to use separate
-   ``sysconfig`` schemes for pip-installed and Conda-installed
-   software, for the same reasons it's a good idea for other distros.)
-
-7. By a "developer-facing distro," we mean a specific type of distro
-   where direct users of Python or other languages in the distro are
-   expected or encouraged to make changes to the distro itself if they
-   wish to add libraries. Common examples include private "monorepos"
-   at software development companies, where a single repository builds
-   both third-party and in-house software, and the direct users of the
-   distro's Python interpreter are generally software developers
-   writing said in-house software. User-level package managers like
-   Nixpkgs_ may also count, because they encourage users of Nix who
-   are Python developers to `package their software for Nix`__.
-
-   In these cases, the distro may want to respond to an attempted
-   ``pip install`` with guidance encouraging use of the distro's own
-   facilities for adding new packages, along with a link to
-   documentation.
-
-   If the distro supports/encourages creating a virtual environment
-   from the distro's Python interpreter, there may also be custom
-   instructions for how to properly set up a virtual environment (as
-   for example Nixpkgs does).
-
-   .. _Nixpkgs: https://github.com/NixOS/nixpkgs
-
-   .. __: https://nixos.wiki/wiki/Python
-
-8. When building distro Python packages for a distro Python (case 2),
-   it may be useful to have ``pip install`` be usable as part of the
-   distro's package build process. (Consider, for instance, building a
-   ``python-xyz`` RPM by using ``pip install .`` inside an sdist /
-   source tarball for ``xyz``.) The distro may also want to use a more
-   targeted but still Python-specific installation tool such as
-   installer_.
-
-   .. _installer: https://installer.rtfd.io/
-
-   For this case, the build process will need to find some way to
-   suppress the marker file to allow ``pip install`` to work, and will
-   probably need to point the Python-specific tool at the distro's
-   ``sysconfig`` scheme instead of the shipped default. See the
-   `Recommendations for distros`_ section for more discussion on how
-   to implement this.
-
-   As a result of this PEP, pip will no longer be able to remove
-   packages already on the system. However, this behavior change is
-   fine because a package build process should not (and generally
-   cannot) include instructions to delete some other files on the
-   system; it can only package up its own files.
-
-9. A distro Python used with ``PYTHONHOME`` to set up an alternative
-   Python environment (as opposed to a virtual environment), where
-   ``PYTHONHOME`` is set to some directory copied directly from the
-   distro Python (e.g., ``cp -a /usr/lib/python3.x pyhome/lib``).
-
-   Assuming there are no modifications, then the behavior is just like
-   the underlying distro Python (case 2). So there are behavior
-   changes - you can no longer ``pip install`` by default, and if you
-   override it, it will no longer delete externally-installed packages
-   (i.e., Python packages that were copied from the OS and live in the
-   OS-managed ``sys.path`` entry).
-
-   This behavior change seems to be defensible, in that if your
-   ``PYTHONHOME`` is a straight copy of the distro's Python, it should
-   behave like the distro's Python.
-
-10. A distro Python (or any Python interpreter) used with a
-    ``PYTHONHOME`` taken from a compatible unmodified upstream Python.
-
-    Because the behavior changes in this PEP are keyed off of files in
-    the standard library (the marker file in ``stdlib`` and the
-    behavior of the ``sysconfig`` module), the behavior is just like
-    an unmodified upstream CPython (case 1).
-
-Specification
-=============
 
 Marking an interpreter as using an external package manager
------------------------------------------------------------
+===========================================================
 
 Before a Python-specific package installer (that is, a tool such as
 pip - not an external tool such as apt) installs a package into a
@@ -544,12 +165,10 @@ certain Python context, it should make the following checks by
 default:
 
 1. Is it running outside of a virtual environment? It can determine
-   this by whether ``sys.prefix == sys.base_prefix`` (but see
-   `Backwards Compatibility`_).
+   this by whether ``sys.prefix == sys.base_prefix``.
 
 2. Is there an ``EXTERNALLY-MANAGED`` file in the directory identified
-   by ``sysconfig.get_path("stdlib",
-   sysconfig.get_default_scheme())``?
+   by ``sysconfig.get_path("stdlib", sysconfig.get_default_scheme())``?
 
 If both of these conditions are true, the installer should exit with
 an error message indicating that package installation into this Python
@@ -590,7 +209,7 @@ should, in general, ship a ``EXTERNALLY-MANAGED`` file in their
 standard library directory. For instance, Debian may ship a file in
 ``/usr/lib/python3.9/EXTERNALLY-MANAGED`` consisting of something like
 
-::
+.. code-block:: ini
 
     [externally-managed]
     Error=To install Python packages system-wide, try apt install
@@ -612,7 +231,7 @@ which provides useful and distro-relevant information
 to a user trying to install a package. Optionally,
 translations can be provided in the same file:
 
-::
+.. code-block:: ini
 
     Error-de_DE=Wenn ist das Nunstück git und Slotermeyer?
 
@@ -625,7 +244,7 @@ like (as they can today) without having to manually override this
 rule.
 
 Writing to only the target ``sysconfig`` scheme
------------------------------------------------
+===============================================
 
 Usually, a Python package installer installs to directories in a
 scheme returned by the ``sysconfig`` standard library package.
@@ -634,7 +253,7 @@ Ordinarily, this is the scheme returned by
 ``pip install --user``), it may use a different scheme.
 
 Whenever the installer is installing to a ``sysconfig`` scheme, this
-PEP specifies that the installer should never modify or delete files
+specification declares that the installer should never modify or delete files
 outside of that scheme. For instance, if it's upgrading a package, and
 the package is already installed in a directory outside that scheme
 (perhaps in a directory from another scheme), it should leave the
@@ -729,7 +348,7 @@ Filesystem Hierarchy Standard`__.
 
 There are two ways you could do this. One is, if you are building and
 packaging Python libraries directly (e.g., your packaging helpers
-unpack a :pep:`517`-built wheel or call ``setup.py install``), arrange
+unpack a wheel or call ``setup.py install``), arrange
 for those tools to use a directory that is not in a ``sysconfig``
 scheme but is still on ``sys.path``.
 
@@ -753,8 +372,7 @@ something like ``pip install --scheme=posix_distro`` to explicitly
 install a package into your distro's location (bypassing
 ``get_preferred_schemes``). One could also, if absolutely needed, use
 ``pip uninstall --scheme=posix_distro`` to use pip to remove packages
-from the system-managed directory, which addresses the (hopefully
-theoretical) regression in use case 5 in Rationale_.
+from the system-managed directory.
 
 To install packages with pip, you would also need to either suppress
 the ``EXTERNALLY-MANAGED`` marker file to allow pip to run or to
@@ -787,245 +405,6 @@ compiler's search path, and it will use ``/usr/local/bin`` for the
 default scheme's ``scripts`` and ``/usr/bin`` for distro-packaged
 entry points and place both on ``$PATH``.
 
-Backwards Compatibility
-=======================
-
-All of these mechanisms are proposed for new distro releases and new
-versions of tools like pip only.
-
-In particular, we strongly recommend that distros with a concept of
-major versions only add the marker file or change ``sysconfig``
-schemes in a new major version; otherwise there is a risk that, on an
-existing system, software installed via a Python-specific package
-manager now becomes unmanageable (without an override option). For a
-rolling-release distro, if possible, only add the marker file or
-change ``sysconfig`` schemes in a new Python minor version.
-
-One particular backwards-compatibility difficulty for package
-installation tools is likely to be managing environments created by
-old versions of ``virtualenv`` which have the latest version of the
-tool installed. A "virtual environment" now has a fairly precise
-definition: it uses the ``pyvenv.cfg`` mechanism, which causes
-``sys.base_prefix != sys.prefix``. It is possible, however, that a
-user may have an old virtual environment created by an older version
-of ``virtualenv``; as of this writing, pip supports Python 3.6
-onwards, which is in turn supported by ``virtualenv`` 15.1.0 onwards,
-so this scenario is possible. In older versions of ``virtualenv``, the
-mechanism is instead to set a new attribute, ``sys.real_prefix``, and
-it does not use the standard library support for virtual environments,
-so ``sys.base_prefix`` is the same as ``sys.prefix``. So the logic for
-robustly detecting a virtual environment is something like::
-
-    def is_virtual_environment():
-        return sys.base_prefix != sys.prefix or hasattr(sys, "real_prefix")
-
-Security Implications
-=====================
-
-The purpose of this feature is not to implement a security boundary;
-it is to discourage well-intended changes from unexpectedly breaking a
-user's environment. That is to say, the reason this PEP restricts
-``pip install`` outside a virtual environment is not that it's a
-security risk to be able to do so; it's that "There should be one--
-and preferably only one --obvious way to do it," and that way should
-be using a virtual environment. ``pip install`` outside a virtual
-environment is rather too obvious for what is almost always the wrong
-way to do it.
-
-If there is a case where a user should not be able to ``sudo pip
-install`` or ``pip install --user`` and add files to ``sys.path`` *for
-security reasons*, that needs to be implemented either via access
-control rules on what files the user can write to or an explicitly
-secured ``sys.path`` for the program in question. Neither of the
-mechanisms in this PEP should be interpreted as a way to address such
-a scenario.
-
-For those reasons, an attempted install with a marker file present is
-not a security incident, and there is no need to raise an auditing
-event for it. If the calling user legitimately has access to ``sudo
-pip install`` or ``pip install --user``, they can accomplish the same
-installation entirely outside of Python; if they do not legitimately
-have such access, that's a problem outside the scope of this PEP.
-
-The marker file itself is located in the standard library directory,
-which is a trusted location (i.e., anyone who can write to the marker
-file used by a particular installer could, presumably, run arbitrary
-code inside the installer). Therefore, there is generally no need to
-filter out terminal escape sequences or other potentially-malicious
-content in the error message.
-
-Alternatives
-==============
-
-There are a number of similar proposals we considered that this PEP
-rejects or defers, largely to preserve the behavior in the
-case-by-case analysis in Rationale_.
-
-Marker file
------------
-
-Should the marker file be in ``sys.path``, marking a particular
-directory as not to be written to by a Python-specific package
-manager? This would help with the second problem addressed by this PEP
-(not overwriting deleting distro-owned files) but not the first
-(incompatible installs). A directory-specific marker in
-``/usr/lib/python3.x/site-packages`` would not discourage
-installations into either ``/usr/local/lib/python3.x/site-packages``
-or ``~/.local/lib/python3.x/site-packages``, both of which are on
-``sys.path`` for ``/usr/bin/python3``. In other words, the marker file
-should not be interpreted as marking a single *directory* as
-externally managed (even though it happens to be in a directory on
-``sys.path``); it marks the entire *Python installation* as externally
-managed.
-
-Another variant of the above: should the marker file be in
-``sys.path``, where if it can be found in any directory in
-``sys.path``, it marks the installation as externally managed? An
-apparent advantage of this approach is that it automatically disables
-itself in virtual environments. Unfortunately, This has the wrong
-behavior with a ``--system-site-packages`` virtual environment, where
-the system-wide ``sys.path`` is visible but package installations are
-allowed. (It could work if the rule of exempting virtual environments
-is preserved, but that seems to have no advantage over the current
-scheme.)
-
-Should the marker just be a new attribute of a ``sysconfig`` scheme?
-There is some conceptual cleanliness to this, except that it's hard to
-override. We want to make it easy for container images, package build
-environments, etc. to suppress the marker file. A file that you can
-remove is easy; code in ``sysconfig`` is much harder to modify.
-
-Should the file be in ``/etc``? No, because again, it refers to a
-specific Python installation. A user who installs their own Python may
-well want to install packages within the global context of that
-interpreter.
-
-Should the configuration setting be in ``pip.conf`` or
-``distutils.cfg``? Apart from the above objections about marking an
-installation, this mechanism isn't specific to either of those tools.
-(It seems reasonable for pip to *also* implement a configuration flag
-for users to prevent themselves from performing accidental
-non-virtual-environment installs in any Python installation, but that
-is outside the scope of this PEP.)
-
-Should the file be TOML? TOML is gaining popularity for packaging (see
-e.g. :pep:`517`) but does not yet have an implementation in the standard
-library. Strictly speaking, this isn't a blocker - distros need only
-write the file, not read it, so they don't need a TOML library (the
-file will probably be written by hand, regardless of format), and
-packaging tools likely have a TOML reader already. However, the INI
-format is currently used for various other forms of packaging metadata
-(e.g., ``pydistutils.cfg`` and ``setup.cfg``), meets our needs, and is
-parsable by the standard library, and the pip maintainers expressed a
-preference to avoid using TOML for this yet.
-
-Should the file be ``email.message``-style? While this format is also
-used for packaging metadata (e.g. sdist and wheel metadata) and is
-also parsable by the standard library, it doesn't handle multi-line
-entries quite as clearly, and that is our primary use case.
-
-Should the marker file be executable Python code that evaluates
-whether installation should be allowed or not? Apart from the concerns
-above about having the file in ``sys.path``, we have a concern that
-making it executable is committing to too powerful of an API and risks
-making behavior harder to understand. (Note that the
-``get_default_scheme`` hook of bpo-43976_ is in fact executable, but
-that code needs to be supplied when the interpreter builds; it isn't
-intended to be supplied post-build.)
-
-When overriding the marker, should a Python-specific package manager
-be disallowed from shadowing a package installed by the external
-package manager (i.e., installing modules of the same name)? This
-would minimize the risk of breaking system software, but it's not
-clear it's worth the additional user experience complexity. There are
-legitimate use cases for shadowing system packages, and an additional
-command-line option to permit it would be more confusing. Meanwhile,
-not passing that option wouldn't eliminate the risk of breaking system
-software, which may be relying on a ``try: import xyz`` failing,
-finding a limited set of entry points, etc. Communicating this
-distinction seems difficult. We think it's a good idea for
-Python-specific package managers to print a warning if they shadow a
-package, but we think it's not worth disabling it by default.
-
-Why not use the ``INSTALLER`` file from :pep:`376` to determine who
-installed a package and whether it can be removed? First, it's
-specific to a particular package (it's in the package's ``dist-info``
-directory), so like some of the alternatives above, it doesn't provide
-information on an entire environment and whether package installations
-are permissible. :pep:`627` also updates :pep:`376` to prevent programmatic
-use of ``INSTALLER``, specifying that the file is "to be used for
-informational purposes only. [...] Our goal is supporting
-interoperating tools, and basing any action on which tool happened to
-install a package runs counter to that goal." Finally, as :pep:`627`
-envisions, there are legitimate use cases for one tool knowing how to
-handle packages installed by another tool; for instance, ``conda`` can
-safely remove a package installed by ``pip`` into a Conda environment.
-
-Why does the specification give no means for disabling package
-installations inside a virtual environment? We can't see a
-particularly strong use case for it (at least not one related to the
-purposes of this PEP). If you need it, it's simple enough to ``pip
-uninstall pip`` inside that environment, which should discourage at
-least unintentional changes to the environment (and this specification
-makes no provision to disable *intentional* changes, since after all
-the marker file can be easily removed).
-
-System Python
--------------
-
-Shouldn't distro software just run with the distro ``site-packages``
-directory alone on ``sys.path`` and ignore the local system
-administrator's ``site-packages`` as well as the user-specific one?
-This is a worthwhile idea, and various versions of it have been
-circulating for a while under the name of "system Python" or "platform
-Python" (with a separate "user Python" for end users writing Python or
-installing Python software separate from the system). However, it's
-much more involved of a change. First, it would be a
-backwards-incompatible change. As mentioned in the Motivation_
-section, there are valid use cases for running distro-installed Python
-applications like Sphinx or Ansible with locally-installed Python
-libraries available on their ``sys.path``. A wholesale switch to
-ignoring local packages would break these use cases, and a distro
-would have to make a case-by-case analysis of whether an application
-ought to see locally-installed libraries or not.
-
-Furthermore, `Fedora attempted this change and reverted it`_, finding,
-ironically, that their implementation of the change `broke their
-package manager`_. Given that experience, there are clearly details to
-be worked out before distros can reliably implement that approach, and
-a PEP recommending it would be premature.
-
-.. _`Fedora attempted this change and reverted it`: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/SEFUWW4XZBTVOAQ36XOJQ72PIICMFOSN/
-.. _`broke their package manager`: https://bugzilla.redhat.com/show_bug.cgi?id=1483342
-
-This PEP is intended to be a complete and self-contained change that
-is independent of a distributor's decision for or against "system
-Python" or similar proposals. It is not incompatible with a distro
-implementing "system Python" in the future, and even though both
-proposals address the same class of problems, there are still
-arguments in favor of implementing something like "system Python" even
-after implementing this PEP. At the same time, though, this PEP
-specifically tries to make a more targeted and minimal change, such
-that it can be implemented by distributors who don't expect to adopt
-"system Python" (or don't expect to implement it immediately). The
-changes in this PEP stand on their own merits and are not an
-intermediate step for some future proposal. This PEP reduces (but does
-not eliminate) the risk of breaking system software while minimizing
-(but not completely avoiding) breaking changes, which should therefore
-be much easier to implement than the full "system Python" idea, which
-comes with the downsides mentioned above.
-
-We expect that the guidance in this PEP - that users should use
-virtual environments whenever possible and that distros should have
-separate ``sys.path`` directories for distro-managed and
-locally-managed modules - should make further experiments easier in
-the future. These may include distributing wholly separate "system"
-and "user" Python interpreters, running system software out of a
-distro-owned virtual environment or ``PYTHONHOME`` (but shipping a
-single interpreter), or modifying the entry points for certain
-software (such as the distro's package manager) to use a ``sys.path``
-that only sees distro-managed directories. Those ideas themselves,
-however, remain outside the scope of this PEP.
 
 Implementation Notes
 ====================
@@ -1033,9 +412,9 @@ Implementation Notes
 This section is non-normative and contains notes relevant to both the
 specification and potential implementations.
 
-Currently, pip does not directly expose a way to choose a target
-``sysconfig`` scheme, but it has three ways of looking up schemes when
-installing:
+Currently (as of May 2021), pip does not directly expose a way to choose
+a target ``sysconfig`` scheme, but it has three ways of looking up schemes
+when installing:
 
 ``pip install``
     Calls ``sysconfig.get_default_scheme()``, which is usually (in
@@ -1078,36 +457,8 @@ message from it, may as well get added to the standard library
 (``sys`` and ``sysconfig``, respectively), to centralize their
 implementations, but they don't need to be added yet.
 
-References
-==========
-
-For additional background on these problems and previous attempts to
-solve them, see `Debian bug 771794`_ "pip silently removes/updates
-system provided python packages" from 2014, Fedora's 2018 article
-`Making sudo pip safe`_ about pointing ``sudo pip`` at /usr/local
-(which acknowledges that the changes still do not make ``sudo pip``
-completely safe), pip issues 5605_ ("Disable upgrades to existing
-python modules which were not installed via pip") and 5722_ ("pip
-should respect /usr/local") from 2018, and the post-PyCon US 2019
-discussion thread `Playing nice with external package managers`_.
-
-.. _`Debian bug 771794`: https://bugs.debian.org/771794
-
-.. _`Making sudo pip safe`: https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe
 
-.. _5605: https://github.com/pypa/pip/issues/5605
 
-.. _5722: https://github.com/pypa/pip/issues/5722
-
-.. _`Playing nice with external package managers`: https://discuss.python.org/t/playing-nice-with-external-package-managers/1968
-
-.. [#pip] https://pip.pypa.io/en/stable/
-
-.. [#easy-install] https://setuptools.readthedocs.io/en/latest/deprecated/easy_install.html
-   (Note that the ``easy_install`` command was removed in
-   setuptools version 52, released 23 January 2021.)
-
-.. [#Conda] https://conda.io
 
 Copyright
 =========
@@ -1119,4 +470,5 @@ CC0-1.0-Universal license, whichever is more permissive.
 
 History
 =======
-- `June 2022 `_: ``EXTERNALLY-MANAGED`` marker file was originally specified in :pep:`668#marking-an-interpreter-as-using-an-external-package-manager`.
+
+This specification was originally approved as :pep:`668`.

From eaf379c830380c9f8ff4b01e8b8a747b08dbf18a Mon Sep 17 00:00:00 2001
From: Laurie O 
Date: Thu, 9 Nov 2023 10:49:26 +1000
Subject: [PATCH 0483/1072] Better http.server links

Docs link uses intersphinx, issues link uses GitHub role

Co-authored-by: chrysle 
---
 source/key_projects.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index b386a8f2d..7a56f0b8b 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -850,8 +850,8 @@ build of the Python distribution.
 http.server
 ===========
 
-`Docs `__ |
-`Issues `__
+`Docs `__ |
+:gh:`Issues `
 
 A package and command-line interface which can host a directory as a
 website, for example as a :term:`package index ` (see

From 4c0a016ed268de9e0036e38186bc9faea64343fb Mon Sep 17 00:00:00 2001
From: Laurie O 
Date: Thu, 9 Nov 2023 10:50:18 +1000
Subject: [PATCH 0484/1072] Document simpleindex use of multiple directories

Co-authored-by: chrysle 
---
 source/key_projects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index 7a56f0b8b..414ebc28f 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -790,7 +790,7 @@ simpleindex
 
 simpleindex is a :term:`package index ` which routes URLs to
 multiple package indexes (including PyPI), serves local (or cloud-hosted,
-for example `AWS S3`_, with a custom plugin) directory of packages, and
+for example `AWS S3`_, with a custom plugin) directories of packages, and
 supports custom plugins.
 
 .. _spack:

From 646f612a84434964dd411b6be5650360a8f267c3 Mon Sep 17 00:00:00 2001
From: Laurie O 
Date: Thu, 9 Nov 2023 18:14:07 +1000
Subject: [PATCH 0485/1072] Fix Python std-lib doc link

---
 source/key_projects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index 414ebc28f..f9f7dcbea 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -850,7 +850,7 @@ build of the Python distribution.
 http.server
 ===========
 
-`Docs `__ |
+:doc:`Docs ` |
 :gh:`Issues `
 
 A package and command-line interface which can host a directory as a

From ffff0a33d8b434f99620ef732a4a0d620c49cb1b Mon Sep 17 00:00:00 2001
From: Hugo van Kemenade 
Date: Thu, 9 Nov 2023 16:13:31 +0200
Subject: [PATCH 0486/1072] Replace 'PEP' with 'specification'

---
 source/specifications/version-specifiers.rst | 28 ++++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/source/specifications/version-specifiers.rst b/source/specifications/version-specifiers.rst
index 0d8b22334..acf3167c7 100644
--- a/source/specifications/version-specifiers.rst
+++ b/source/specifications/version-specifiers.rst
@@ -101,7 +101,7 @@ aside from always being the lowest possible value in the version ordering.
    across existing public and private Python projects.
 
    Accordingly, some of the versioning practices which are technically
-   permitted by the PEP are strongly discouraged for new projects. Where
+   permitted by the specification are strongly discouraged for new projects. Where
    this is the case, the relevant details are noted in the following
    sections.
 
@@ -631,7 +631,7 @@ are permitted and MUST be ordered as shown::
 Note that ``c`` is considered to be semantically equivalent to ``rc`` and must
 be sorted as if it were ``rc``. Tools MAY reject the case of having the same
 ``N`` for both a ``c`` and a ``rc`` in the same release segment as ambiguous
-and remain in compliance with the PEP.
+and remain in compliance with the specification.
 
 Within an alpha (``1.0a1``), beta (``1.0b1``), or release candidate
 (``1.0rc1``, ``1.0c1``), the following suffixes are permitted and MUST be
@@ -692,9 +692,9 @@ versions of a project.
 
 Due to the above, this specification MUST be used for all versions of metadata and
 supersedes :pep:`386` even for metadata v1.2. Tools SHOULD ignore any versions
-which cannot be parsed by the rules in this PEP, but MAY fall back to
+which cannot be parsed by the rules in this specification, but MAY fall back to
 implementation defined version parsing and ordering schemes if no versions
-complying with this PEP are available.
+complying with this specification are available.
 
 Distribution users may wish to explicitly remove non-compliant versions from
 any private package indexes they control.
@@ -705,7 +705,7 @@ Compatibility with other version schemes
 
 Some projects may choose to use a version scheme which requires
 translation in order to comply with the public version scheme defined in
-this PEP. In such cases, the project specific version can be stored in the
+this specification. In such cases, the project specific version can be stored in the
 metadata while the translated public version is published in the version field.
 
 This allows automated distribution tools to provide consistently correct
@@ -717,15 +717,15 @@ Semantic versioning
 ~~~~~~~~~~~~~~~~~~~
 
 `Semantic versioning`_ is a popular version identification scheme that is
-more prescriptive than this PEP regarding the significance of different
+more prescriptive than this specification regarding the significance of different
 elements of a release number. Even if a project chooses not to abide by
 the details of semantic versioning, the scheme is worth understanding as
 it covers many of the issues that can arise when depending on other
 distributions, and when publishing a distribution that others rely on.
 
-The "Major.Minor.Patch" (described in this PEP as "major.minor.micro")
+The "Major.Minor.Patch" (described in this specification as "major.minor.micro")
 aspects of semantic versioning (clauses 1-8 in the 2.0.0 specification)
-are fully compatible with the version scheme defined in this PEP, and abiding
+are fully compatible with the version scheme defined in this specification, and abiding
 by these aspects is encouraged.
 
 Semantic versions containing a hyphen (pre-releases - clause 10) or a
@@ -1011,10 +1011,10 @@ local versions. This operator also does not support prefix matching as the
 ``==`` operator does.
 
 The primary use case for arbitrary equality is to allow for specifying a
-version which cannot otherwise be represented by this PEP. This operator is
+version which cannot otherwise be represented by this specification. This operator is
 special and acts as an escape hatch to allow someone using a tool which
-implements this PEP to still install a legacy version which is otherwise
-incompatible with this PEP.
+implements this specification to still install a legacy version which is otherwise
+incompatible with this specification.
 
 An example would be ``===foobar`` which would match a version of ``foobar``.
 
@@ -1178,16 +1178,16 @@ Summary of differences from pkg_resources.parse_version
   the time :pep:`440` was written. After the PEP was accepted, setuptools 6.0 and
   later versions adopted the behaviour described here.
 
-* Local versions sort differently, this PEP requires that they sort as greater
+* Local versions sort differently, this specification requires that they sort as greater
   than the same version without a local version, whereas
   ``pkg_resources.parse_version`` considers it a pre-release marker.
 
-* This PEP purposely restricts the syntax which constitutes a valid version
+* This specification purposely restricts the syntax which constitutes a valid version
   while ``pkg_resources.parse_version`` attempts to provide some meaning from
   *any* arbitrary string.
 
 * ``pkg_resources.parse_version`` allows arbitrarily deeply nested version
-  signifiers like ``1.0.dev1.post1.dev5``. This PEP however allows only a
+  signifiers like ``1.0.dev1.post1.dev5``. This specification however allows only a
   single use of each type and they must exist in a certain order.
 
 

From aa0439a134a62f56f60e548e617f759f40cf9e70 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Thu, 9 Nov 2023 20:06:35 +0100
Subject: [PATCH 0487/1072] Address review comments

---
 source/guides/writing-pyproject-toml.rst | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index 8e28e305b..c01f2b51e 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -4,12 +4,10 @@
 Writing your ``pyproject.toml``
 ===============================
 
-.. TODO: link :term:`build backends` when that's merged
-
 ``pyproject.toml`` is a configuration file used by packaging tools. Most
-build backends [#poetry-special]_ allow you to specify your project's
-basic metadata, such as the dependencies, your name, etc., in the ``[project]``
-table of your ``pyproject.toml``.
+:term:`build backends ` [#poetry-special]_ allow you to specify
+your project's basic metadata, such as the dependencies, your name, etc.,
+in the ``[project]`` table of your ``pyproject.toml``.
 
 .. note::
 
@@ -17,9 +15,9 @@ table of your ``pyproject.toml``.
    build backend. For new projects, it is recommended to use ``pyproject.toml``
    for basic metadata, and keep ``setup.py`` only if some programmatic configuration
    is needed (especially building C extensions). However, putting basic project
-   metadata in ``setup.py`` or ``setup.cfg`` is still valid.
+   metadata in ``setup.py`` or ``setup.cfg`` is still valid. See
+   :ref:`setup-py-deprecated`.
 
-.. TODO: link to "is setup.py deprecated?" page when merged
 
 Static vs. dynamic metadata
 ===========================

From cc029092cdf6639ace2efeb4346c1c0b13e74687 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Thu, 9 Nov 2023 20:06:42 +0100
Subject: [PATCH 0488/1072] =?UTF-8?q?Typo:=20python-requires=20=E2=86=92?=
 =?UTF-8?q?=20requires-python?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 source/guides/writing-pyproject-toml.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index c01f2b51e..a0b6a1efc 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -115,7 +115,7 @@ could use, e.g., ``pip install your-project-name[gui]`` to install your
 project with GUI support, adding the PyQt5 dependency.
 
 
-``python-requires``
+``requires-python``
 -------------------
 
 This lets you declare the minimum version of Python that you support

From ae74041636cf75466672ecd894b64cef3cba544c Mon Sep 17 00:00:00 2001
From: sinoroc 
Date: Sat, 4 Nov 2023 18:56:59 +0100
Subject: [PATCH 0489/1072] Add page "How to modernize a setup.py project?"

GitHub: refs https://github.com/pypa/packaging.python.org/issues/1334
---
 source/discussions/setup-py-deprecated.rst    |   9 +-
 source/guides/modernize-setup-py-project.rst  | 249 ++++++++++++++++++
 source/guides/section-build-and-publish.rst   |   1 +
 .../declaring-project-metadata.rst            |   3 +
 4 files changed, 254 insertions(+), 8 deletions(-)
 create mode 100644 source/guides/modernize-setup-py-project.rst

diff --git a/source/discussions/setup-py-deprecated.rst b/source/discussions/setup-py-deprecated.rst
index 29eac241d..25bba70a9 100644
--- a/source/discussions/setup-py-deprecated.rst
+++ b/source/discussions/setup-py-deprecated.rst
@@ -105,10 +105,6 @@ Although the usage of :file:`setup.py` as an executable script is deprecated,
 its usage as a configuration file for setuptools is absolutely fine.
 There is likely no modification needed in :file:`setup.py`.
 
-.. todo::
-
-    Link to a "How to modernize a setup.py based project?"
-
 
 Is ``pyproject.toml`` mandatory?
 ================================
@@ -124,10 +120,7 @@ at the root of its source tree with a content like this:
     build-backend = "setuptools.build_meta"
 
 
-.. todo::
-
-    Link to "How to modernize a setup.py based project?"
-
+The guide :ref:`modernize-setup-py-project` has more details about this.
 
 The standard fallback behavior for a :term:`build frontend `
 in the absence of a :file:`pyproject.toml` file and its ``[build-system]`` table
diff --git a/source/guides/modernize-setup-py-project.rst b/source/guides/modernize-setup-py-project.rst
new file mode 100644
index 000000000..1ecd4d6ff
--- /dev/null
+++ b/source/guides/modernize-setup-py-project.rst
@@ -0,0 +1,249 @@
+.. _modernize-setup-py-project:
+
+
+==============================================
+How to modernize a ``setup.py`` based project?
+==============================================
+
+
+Should ``pyproject.toml`` be added?
+===================================
+
+A :term:`pyproject.toml` file is strongly recommended.
+The presence of a :file:`pyproject.toml` file itself does not bring much. [#]_
+What is actually strongly recommended is the ``[build-system]`` table in :file:`pyproject.toml`.
+
+.. [#] Note that it has influence on the build isolation feature of *pip*,
+    see below.
+
+
+Should ``setup.py`` be deleted?
+===============================
+
+No, :file:`setup.py` can exist in a modern :ref:`setuptools` based project.
+The :term:`setup.py` file is a valid configuration file for setuptools
+that happens to be written in Python.
+However, the following commands are deprecated and **MUST NOT** be run anymore,
+and their recommended replacement commands can be used instead:
+
++---------------------------------+----------------------------------------+
+| Deprecated                      | Current recommendation                 |
++=================================+========================================+
+| ``python setup.py install``     | ``python -m pip install .``            |
++---------------------------------+----------------------------------------+
+| ``python setup.py develop``     | ``python -m pip install --editable .`` |
++---------------------------------+----------------------------------------+
+| ``python setup.py sdist``       | ``python -m build``                    |
++---------------------------------+                                        |
+| ``python setup.py bdist_wheel`` |                                        |
++---------------------------------+----------------------------------------+
+
+
+For more details:
+
+* :ref:`setup-py-deprecated`
+
+
+Where to start?
+===============
+
+The :term:`project` must contain a :file:`pyproject.toml` file at the root of its source tree
+that contains a ``[build-system]`` table like so:
+
+.. code:: toml
+
+    [build-system]
+    requires = ["setuptools"]
+    build-backend = "setuptools.build_meta"
+
+
+This is the standardized method of letting :term:`build frontends ` know
+that :ref:`setuptools` is the :term:`build backend ` for this project.
+
+Note that the presence of a :file:`pyproject.toml` file (even if empty)
+triggers :ref:`pip` to change its default behavior to use *build isolation*.
+
+For more details:
+
+* :ref:`distributing-packages`
+* :ref:`declaring-build-dependencies`
+* :doc:`pip:reference/build-system/pyproject-toml`
+
+
+How to handle additional build-time dependencies?
+=================================================
+
+On top of setuptools itself,
+if :file:`setup.py` depends on other third-party libraries (outside of Python's standard library),
+those must be listed in the ``requires`` list of the ``[build-system]`` table,
+so that the build frontend knows to install them
+when building the :term:`distributions `.
+
+For example, a :file:`setup.py` file such as this:
+
+.. code:: python
+
+    import setuptools
+    import some_build_toolkit  # comes from the `some-build-toolkit` library
+
+    def get_version():
+        version = some_build_toolkit.compute_version()
+        return version
+
+    setuptools.setup(
+        name="my-project",
+        version=get_version(),
+    )
+
+
+requires a :file:`pyproject.toml` file like this (:file:`setup.py` stays unchanged):
+
+.. code:: toml
+
+    [build-system]
+    requires = [
+        "setuptools",
+        "some-build-toolkit",
+    ]
+    build-backend = "setuptools.build_meta"
+
+
+For more details:
+
+* :ref:`declaring-build-dependencies`
+
+
+What is the build isolation feature?
+====================================
+
+Build frontends typically create an ephemeral virtual environment
+where they install only the build dependencies (and their dependencies)
+that are listed under ``build-sytem.requires``
+and trigger the build in that environment.
+
+For some projects this isolation is unwanted and it can be deactivated as follows:
+
+* ``python -m build --no-isolation``
+* ``python -m install --no-build-isolation``
+
+For more details:
+
+* :doc:`pip:reference/build-system/pyproject-toml`
+
+
+How to handle packaging metadata?
+=================================
+
+All static metadata can optionally be moved to a ``[project]`` table in :file:`pyproject.toml`.
+
+For example, a :file:`setup.py` file such as this:
+
+.. code:: python
+
+    import setuptools
+
+    setuptools.setup(
+        name="my-project",
+        version="1.2.3",
+    )
+
+
+can be entirely replaced by a :file:`pyproject.toml` file like this:
+
+.. code:: toml
+
+    [build-system]
+    requires = ["setuptools"]
+    build-backend = "setuptools.build_meta"
+
+    [project]
+    name = "my-project"
+    version = "1.2.3"
+
+
+Read :ref:`declaring-project-metadata` for the full specification
+of the content allowed in the ``[project]`` table.
+
+
+How to handle dynamic metadata?
+===============================
+
+If some packaging metadata fields are not static
+they need to be listed as ``dynamic`` in this ``[project]`` table.
+
+For example, a :file:`setup.py` file such as this:
+
+.. code:: python
+
+    import setuptools
+    import some_build_toolkit
+
+    def get_version():
+        version = some_build_toolkit.compute_version()
+        return version
+
+    setuptools.setup(
+        name="my-project",
+        version=get_version(),
+    )
+
+
+can be modernized as follows:
+
+.. code:: toml
+
+    [build-system]
+    requires = [
+        "setuptools",
+        "some-build-toolkit",
+    ]
+    build-backend = "setuptools.build_meta"
+
+    [project]
+    name = "my-project"
+    dynamic = ["version"]
+
+
+.. code:: python
+
+    import setuptools
+    import some_build_toolkit
+
+    def get_version():
+        version = some_build_toolkit.compute_version()
+        return version
+
+    setuptools.setup(
+        version=get_version(),
+    )
+
+
+For more details:
+
+* :ref:`declaring-project-metadata-dynamic`
+
+
+What if something that can not be changed expects a ``setup.py`` file?
+======================================================================
+
+For example, a process exists that can not be changed easily
+and it needs to execute a command such as ``python setup.py --name``.
+
+It is perfectly fine to leave a :file:`setup.py` file in the project source tree
+even after all its content has been moved to :file:`pyproject.toml`.
+This file can be as minimalistic as this:
+
+.. code:: python
+
+    import setuptools
+
+    setuptools.setup()
+
+
+Where to read more about this?
+==============================
+
+* :ref:`declaring-build-dependencies`
+* :ref:`declaring-project-metadata`
+* :doc:`pip:reference/build-system/pyproject-toml`
+* :doc:`setuptools:build_meta`
diff --git a/source/guides/section-build-and-publish.rst b/source/guides/section-build-and-publish.rst
index 9bb5f08fe..b20c27249 100644
--- a/source/guides/section-build-and-publish.rst
+++ b/source/guides/section-build-and-publish.rst
@@ -15,3 +15,4 @@ Building and Publishing
    using-testpypi
    making-a-pypi-friendly-readme
    publishing-package-distribution-releases-using-github-actions-ci-cd-workflows
+   modernize-setup-py-project
diff --git a/source/specifications/declaring-project-metadata.rst b/source/specifications/declaring-project-metadata.rst
index df6c9ee89..c7247865b 100644
--- a/source/specifications/declaring-project-metadata.rst
+++ b/source/specifications/declaring-project-metadata.rst
@@ -379,6 +379,9 @@ metadata.
       "click",
     ]
 
+
+.. _declaring-project-metadata-dynamic:
+
 ``dynamic``
 -----------
 

From 3cadeb61326a43c4ffe0553df1c80e956e54181b Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Fri, 10 Nov 2023 23:54:40 +0100
Subject: [PATCH 0490/1072] Change "Bug Tracker" to Issues (closes #1183)

---
 source/guides/writing-pyproject-toml.rst | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index a0b6a1efc..03aa25612 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -274,8 +274,7 @@ A list of PyPI classifiers that apply to your project. Check the
 --------
 
 A list of URLs associated with your project, displayed on the left
-sidebar of your PyPI project page. If the key contains spaces, don't
-forget to quote it.
+sidebar of your PyPI project page.
 
 .. code-block:: toml
 
@@ -283,9 +282,14 @@ forget to quote it.
     Homepage = "https://example.com"
     Documentation = "https://readthedocs.org"
     Repository = "https://github.com/me/spam.git"
-    "Bug Tracker" = "https://github.com/me/spam/issues"
+    Issues = "https://github.com/me/spam/issues"
     Changelog = "https://github.com/me/spam/blob/master/CHANGELOG.md"
 
+Note that if the key contains spaces, it needs to be quoted, e.g.,
+``Website = "https://example.com"`` but
+``"Official Website" = "https://example.com"``.
+
+
 
 Advanced plugins
 ================

From f491267f1d10fe61b5ce300f92349666432fd6fa Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Sat, 11 Nov 2023 05:45:59 +0100
Subject: [PATCH 0491/1072] Update
 source/specifications/recording-installed-packages.rst

---
 source/specifications/recording-installed-packages.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/recording-installed-packages.rst b/source/specifications/recording-installed-packages.rst
index fe33df438..ffef1f93e 100644
--- a/source/specifications/recording-installed-packages.rst
+++ b/source/specifications/recording-installed-packages.rst
@@ -246,7 +246,7 @@ To achieve this, affected tools should take the following steps:
 
 Python runtime providers may also prevent inadvertent modification of platform
 provided packages by modifying the default Python package installation scheme
-to use a location other than that used by distribution packages (while also
+to use a location other than that used by platform provided packages (while also
 ensuring both locations appear on the default Python import path).
 
 In some circumstances, it may be desirable to block even installation of

From ada01ea280118a76dd879a981981370bc0fbc176 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sat, 11 Nov 2023 20:33:10 +0100
Subject: [PATCH 0492/1072] Remove "Using MANIFEST.in" guide, moved to
 setuptools docs

---
 source/guides/section-build-and-publish.rst |   1 -
 source/guides/using-manifest-in.rst         | 111 --------------------
 2 files changed, 112 deletions(-)
 delete mode 100644 source/guides/using-manifest-in.rst

diff --git a/source/guides/section-build-and-publish.rst b/source/guides/section-build-and-publish.rst
index b20c27249..ccb18749e 100644
--- a/source/guides/section-build-and-publish.rst
+++ b/source/guides/section-build-and-publish.rst
@@ -6,7 +6,6 @@ Building and Publishing
    :titlesonly:
 
    distributing-packages-using-setuptools
-   using-manifest-in
    single-sourcing-package-version
    dropping-older-python-versions
    packaging-binary-extensions
diff --git a/source/guides/using-manifest-in.rst b/source/guides/using-manifest-in.rst
deleted file mode 100644
index 1eaf42c18..000000000
--- a/source/guides/using-manifest-in.rst
+++ /dev/null
@@ -1,111 +0,0 @@
-.. _`Using MANIFEST.in`:
-
-============================================================
-Including files in source distributions with ``MANIFEST.in``
-============================================================
-
-When building a :term:`source distribution `
-for your package, by default only a minimal set of files are included.  You may
-find yourself wanting to include extra files in the source distribution, such
-as an authors/contributors file, a :file:`docs/` directory, or a directory of
-data files used for testing purposes.  There may even be extra files that you
-*need* to include; for example, if your :file:`setup.py` computes your
-project's ``long_description`` by reading from both a README and a changelog
-file, you'll need to include both those files in the sdist so that people that
-build or install from the sdist get the correct results.
-
-Adding & removing files to & from the source distribution is done by writing a
-:file:`MANIFEST.in` file at the project root.
-
-
-How files are included in an sdist
-==================================
-
-The following files are included in a source distribution by default:
-
-- all Python source files implied by the ``py_modules`` and ``packages``
-  ``setup()`` arguments
-- all C source files mentioned in the ``ext_modules`` or ``libraries``
-  ``setup()`` arguments
-- scripts specified by the ``scripts`` ``setup()`` argument
-- all files specified by the ``package_data`` and ``data_files`` ``setup()``
-  arguments
-- the file specified by the ``license_file`` option in :file:`setup.cfg`
-  (setuptools 40.8.0+)
-- all files specified by the ``license_files`` option in :file:`setup.cfg`
-  (setuptools 42.0.0+)
-- all files matching the pattern :file:`test/test*.py`
-- :file:`setup.py` (or whatever you called your setup script)
-- :file:`setup.cfg`
-- :file:`README`
-- :file:`README.txt`
-- :file:`README.rst` (Python 3.7+ or setuptools 0.6.27+)
-- :file:`README.md` (setuptools 36.4.0+)
-- :file:`pyproject.toml` (setuptools 43.0.0+)
-- :file:`MANIFEST.in`
-
-After adding the above files to the sdist, the commands in :file:`MANIFEST.in`
-(if such a file exists) are executed in order to add and remove further files
-to and from the sdist.  Default files can even be removed from the sdist with the
-appropriate :file:`MANIFEST.in` command.
-
-After processing the :file:`MANIFEST.in` file, setuptools removes the
-:file:`build/` directory as well as any directories named :file:`RCS`,
-:file:`CVS`, or :file:`.svn` from the sdist, and it adds a :file:`PKG-INFO`
-file and an :file:`*.egg-info` directory.  This behavior cannot be changed with
-:file:`MANIFEST.in`.
-
-
-:file:`MANIFEST.in` commands
-============================
-
-A :file:`MANIFEST.in` file consists of commands, one per line, instructing
-setuptools to add or remove some set of files from the sdist.  The commands
-are:
-
-=========================================================  ==================================================================================================
-Command                                                    Description
-=========================================================  ==================================================================================================
-:samp:`include {pat1} {pat2} ...`                          Add all files matching any of the listed patterns
-                                                           (Files must be given as paths relative to the root of the project)
-:samp:`exclude {pat1} {pat2} ...`                          Remove all files matching any of the listed patterns
-                                                           (Files must be given as paths relative to the root of the project)
-:samp:`recursive-include {dir-pattern} {pat1} {pat2} ...`  Add all files under directories matching ``dir-pattern`` that match any of the listed patterns
-:samp:`recursive-exclude {dir-pattern} {pat1} {pat2} ...`  Remove all files under directories matching ``dir-pattern`` that match any of the listed patterns
-:samp:`global-include {pat1} {pat2} ...`                   Add all files anywhere in the source tree matching any of the listed patterns
-:samp:`global-exclude {pat1} {pat2} ...`                   Remove all files anywhere in the source tree matching any of the listed patterns
-:samp:`graft {dir-pattern}`                                Add all files under directories matching ``dir-pattern``
-:samp:`prune {dir-pattern}`                                Remove all files under directories matching ``dir-pattern``
-=========================================================  ==================================================================================================
-
-The patterns here are glob-style patterns: ``*`` matches zero or more regular
-filename characters (on Unix, everything except forward slash; on Windows,
-everything except backslash and colon); ``?`` matches a single regular filename
-character, and ``[chars]`` matches any one of the characters between the square
-brackets (which may contain character ranges, e.g., ``[a-z]`` or
-``[a-fA-F0-9]``).  Setuptools also has undocumented support for ``**`` matching
-zero or more characters including forward slash, backslash, and colon.
-
-Directory patterns are relative to the root of the project directory; e.g.,
-``graft example*`` will include a directory named :file:`examples` in the
-project root but will not include :file:`docs/examples/`.
-
-File & directory names in :file:`MANIFEST.in` should be ``/``-separated;
-setuptools will automatically convert the slashes to the local platform's
-appropriate directory separator.
-
-Commands are processed in the order they appear in the :file:`MANIFEST.in`
-file.  For example, given the commands:
-
-.. code-block:: bash
-
-    graft tests
-    global-exclude *.py[cod]
-
-the contents of the directory tree :file:`tests` will first be added to the
-sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or
-``.pyd`` extension will be removed from the sdist.  If the commands were in the
-opposite order, then ``*.pyc`` files etc. would be only be removed from what
-was already in the sdist before adding :file:`tests`, and if :file:`tests`
-happened to contain any ``*.pyc`` files, they would end up included in the
-sdist because the exclusion happened before they were included.

From d79ae4ada0a2289114d2e5a3691d0aa0f6e8371e Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sat, 11 Nov 2023 20:41:53 +0100
Subject: [PATCH 0493/1072] Consistent tabs in
 installing-using-pip-and-virtual-environments.rst

Fixes #1375
---
 ...ing-using-pip-and-virtual-environments.rst | 21 +++----------------
 1 file changed, 3 insertions(+), 18 deletions(-)

diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst
index 2544aa40a..2f6b154bc 100644
--- a/source/guides/installing-using-pip-and-virtual-environments.rst
+++ b/source/guides/installing-using-pip-and-virtual-environments.rst
@@ -155,25 +155,10 @@ Prepare pip
 It's used to install and update packages into a virtual environment.
 
 
-.. tab:: Unix
-
-    You can make sure that pip is up-to-date by running:
-
-    .. code-block:: bash
-
-        python3 -m pip install --upgrade pip
-        python3 -m pip --version
-
-    Afterwards, you should have the latest version of pip installed in your
-    user site:
-
-    .. code-block:: text
-
-        pip 23.3.1 from .../.venv/lib/python3.9/site-packages (python 3.9)
-
-.. tab:: macOS
+.. tab:: Unix/macOS
 
-    The Python installers for macOS include pip. You can make sure that pip is
+    The Python installers for macOS include pip. On Linux, you may have to install
+    an additional package such as ``python3-pip``. You can make sure that pip is
     up-to-date by running:
 
     .. code-block:: bash

From 1c2467e5223d9546008853a952292a442d4232d9 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sat, 11 Nov 2023 23:41:02 +0100
Subject: [PATCH 0494/1072] =?UTF-8?q?brett@python.org=20=E2=86=92=20brett@?=
 =?UTF-8?q?example.com?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 source/guides/writing-pyproject-toml.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index 03aa25612..70028856c 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -180,7 +180,7 @@ an email address.
       {email = "different.person@example.com"},
     ]
     maintainers = [
-      {name = "Brett Cannon", email = "brett@python.org"}
+      {name = "Brett Cannon", email = "brett@example.com"}
     ]
 
 
@@ -329,7 +329,7 @@ A full example
      {email = "different.person@example.com"},
    ]
    maintainers = [
-     {name = "Brett Cannon", email = "brett@python.org"}
+     {name = "Brett Cannon", email = "brett@example.com"}
    ]
    description = "Lovely Spam! Wonderful Spam!"
    readme = "README.rst"

From 4397751692a895eedf7d60e4fb585fa4bad5a3b8 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sun, 12 Nov 2023 00:04:32 +0100
Subject: [PATCH 0495/1072] Import PEP 723 verbatim

---
 .../specifications/inline-script-metadata.rst | 835 ++++++++++++++++++
 1 file changed, 835 insertions(+)
 create mode 100644 source/specifications/inline-script-metadata.rst

diff --git a/source/specifications/inline-script-metadata.rst b/source/specifications/inline-script-metadata.rst
new file mode 100644
index 000000000..04fb0d238
--- /dev/null
+++ b/source/specifications/inline-script-metadata.rst
@@ -0,0 +1,835 @@
+PEP: 723
+Title: Inline script metadata
+Author: Ofek Lev 
+Sponsor: Adam Turner 
+PEP-Delegate: Brett Cannon 
+Discussions-To: https://discuss.python.org/t/31151
+Status: Provisional
+Type: Standards Track
+Topic: Packaging
+Content-Type: text/x-rst
+Created: 04-Aug-2023
+Post-History: `04-Aug-2023 `__,
+              `06-Aug-2023 `__,
+              `23-Aug-2023 `__,
+Replaces: 722
+Resolution: https://discuss.python.org/t/36763
+
+
+Abstract
+========
+
+This PEP specifies a metadata format that can be embedded in single-file Python
+scripts to assist launchers, IDEs and other external tools which may need to
+interact with such scripts.
+
+
+Motivation
+==========
+
+Python is routinely used as a scripting language, with Python scripts as a
+(better) alternative to shell scripts, batch files, etc. When Python code is
+structured as a script, it is usually stored as a single file and does not
+expect the availability of any other local code that may be used for imports.
+As such, it is possible to share with others over arbitrary text-based means
+such as email, a URL to the script, or even a chat window. Code that is
+structured like this may live as a single file forever, never becoming a
+full-fledged project with its own directory and ``pyproject.toml`` file.
+
+An issue that users encounter with this approach is that there is no standard
+mechanism to define metadata for tools whose job it is to execute such scripts.
+For example, a tool that runs a script may need to know which dependencies are
+required or the supported version(s) of Python.
+
+There is currently no standard tool that addresses this issue, and this PEP
+does *not* attempt to define one. However, any tool that *does* address this
+issue will need to know what the runtime requirements of scripts are. By
+defining a standard format for storing such metadata, existing tools, as well
+as any future tools, will be able to obtain that information without requiring
+users to include tool-specific metadata in their scripts.
+
+
+Rationale
+=========
+
+This PEP defines a mechanism for embedding metadata *within the script itself*,
+and not in an external file.
+
+We choose to follow the latest developments of other modern packaging
+ecosystems (namely `Go`__ and provisionally `Rust`__) by embedding the existing
+file used to describe projects, in our case ``pyproject.toml``.
+
+__ https://github.com/erning/gorun
+__ https://rust-lang.github.io/rfcs/3424-cargo-script.html
+
+The format is intended to bridge the gap between different types of users
+of Python. Users will benefit from seamless interoperability with tools that
+already work with TOML.
+
+One of the central themes we discovered from the recent
+`packaging survey `__ is that users have
+begun getting frustrated with the lack of unification regarding both tooling
+and specs. Adding yet another metadata format (like :pep:`722` syntax for a
+list of dependencies), even for a currently unsatisfied use case, would
+further fragment the community.
+
+The following are some of the use cases that this PEP wishes to support:
+
+* A user facing CLI that is capable of executing scripts. If we take Hatch as
+  an example, the interface would be simply
+  ``hatch run /path/to/script.py [args]`` and Hatch will manage the
+  environment for that script. Such tools could be used as shebang lines on
+  non-Windows systems e.g. ``#!/usr/bin/env hatch run``.
+* A script that desires to transition to a directory-type project. A user may
+  be rapidly prototyping locally or in a remote REPL environment and then
+  decide to transition to a more formal project layout if their idea works
+  out. This intermediate script stage would be very useful to have fully
+  reproducible bug reports. By using the same format, the user can simply copy
+  and paste the metadata into a ``pyproject.toml`` file and continue working
+  without having to learn a new format. More likely, even, is that tooling will
+  eventually support this transformation with a single command.
+* Users that wish to avoid manual dependency management. For example, package
+  managers that have commands to add/remove dependencies or dependency update
+  automation in CI that triggers based on new versions or in response to
+  CVEs [1]_.
+
+
+Specification
+=============
+
+This PEP defines a metadata comment block format loosely inspired [2]_ by
+`reStructuredText Directives`__.
+
+__ https://docutils.sourceforge.io/docs/ref/rst/directives.html
+
+Any Python script may have top-level comment blocks that MUST start with the
+line ``# /// TYPE`` where ``TYPE`` determines how to process the content. That
+is: a single ``#``, followed by a single space, followed by three forward
+slashes, followed by a single space, followed by the type of metadata. Block
+MUST end with the line ``# ///``. That is: a single ``#``, followed by a single
+space, followed by three forward slashes. The ``TYPE`` MUST only consist of
+ASCII letters, numbers and hyphens.
+
+Every line between these two lines (``# /// TYPE`` and ``# ///``) MUST be a
+comment starting with ``#``. If there are characters after the ``#`` then the
+first character MUST be a space. The embedded content is formed by taking away
+the first two characters of each line if the second character is a space,
+otherwise just the first character (which means the line consists of only a
+single ``#``).
+
+Precedence for an ending line ``# ///`` is given when the next line is not
+a valid embedded content line as described above. For example, the following
+is a single fully valid block:
+
+.. code:: python
+
+    # /// some-toml
+    # embedded-csharp = """
+    # /// 
+    # /// text
+    # ///
+    # /// 
+    # public class MyClass { }
+    # """
+    # ///
+
+A starting line MUST NOT be placed between another starting line and its ending
+line. In such cases tools MAY produce an error. Unclosed blocks MUST be ignored.
+
+When there are multiple comment blocks of the same ``TYPE`` defined, tools MUST
+produce an error.
+
+Tools reading embedded metadata MAY respect the standard Python encoding
+declaration. If they choose not to do so, they MUST process the file as UTF-8.
+
+This is the canonical regular expression that MAY be used to parse the
+metadata:
+
+.. code:: text
+
+    (?m)^# /// (?P[a-zA-Z0-9-]+)$\s(?P(^#(| .*)$\s)+)^# ///$
+
+In circumstances where there is a discrepancy between the text specification
+and the regular expression, the text specification takes precedence.
+
+Tools MUST NOT read from metadata blocks with types that have not been
+standardized by this PEP or future ones.
+
+pyproject type
+--------------
+
+The first type of metadata block is named ``pyproject`` which represents
+content similar to [3]_ what one would see in a ``pyproject.toml`` file.
+
+This document MAY include the ``[run]`` and ``[tool]`` tables.
+
+The :pep:`tool table <518#tool-table>` MAY be used by any tool, script runner
+or otherwise, to configure behavior.
+
+The ``[run]`` table MAY include the following optional fields:
+
+* ``dependencies``: A list of strings that specifies the runtime dependencies
+  of the script. Each entry MUST be a valid :pep:`508` dependency.
+* ``requires-python``: A string that specifies the Python version(s) with which
+  the script is compatible. The value of this field MUST be a valid
+  :pep:`version specifier <440#version-specifiers>`.
+
+Any future PEPs that define additional fields for the ``[run]`` table when used
+in a ``pyproject.toml`` file MUST include the aforementioned fields exactly as
+specified. The fields defined by this PEP are equally as applicable to
+full-fledged projects as they are to single-file scripts.
+
+Script runners MUST error if the specified ``dependencies`` cannot be provided.
+Script runners SHOULD error if no version of Python that satisfies the specified
+``requires-python`` can be provided.
+
+Example
+-------
+
+The following is an example of a script with an embedded ``pyproject.toml``:
+
+.. code:: python
+
+    # /// pyproject
+    # [run]
+    # requires-python = ">=3.11"
+    # dependencies = [
+    #   "requests<3",
+    #   "rich",
+    # ]
+    # ///
+
+    import requests
+    from rich.pretty import pprint
+
+    resp = requests.get("https://peps.python.org/api/peps.json")
+    data = resp.json()
+    pprint([(k, v["title"]) for k, v in data.items()][:10])
+
+The following [4]_ is an example of a proposed syntax for single-file Rust
+projects that embeds their equivalent of ``pyproject.toml``, which is called
+``Cargo.toml``:
+
+.. code:: rust
+
+    #!/usr/bin/env cargo
+
+    //! ```cargo
+    //! [dependencies]
+    //! regex = "1.8.0"
+    //! ```
+
+    fn main() {
+        let re = Regex::new(r"^\d{4}-\d{2}-\d{2}$").unwrap();
+        println!("Did our date match? {}", re.is_match("2014-01-01"));
+    }
+
+Reference Implementation
+========================
+
+The following is an example of how to read the metadata on Python 3.11 or
+higher.
+
+.. code:: python
+
+   import re
+   import tomllib
+
+   REGEX = r'(?m)^# /// (?P[a-zA-Z0-9-]+)$\s(?P(^#(| .*)$\s)+)^# ///$'
+
+   def read(script: str) -> dict | None:
+       name = 'pyproject'
+       matches = list(
+           filter(lambda m: m.group('type') == name, re.finditer(REGEX, script))
+       )
+       if len(matches) > 1:
+           raise ValueError(f'Multiple {name} blocks found')
+       elif len(matches) == 1:
+           content = ''.join(
+               line[2:] if line.startswith('# ') else line[1:]
+               for line in matches[0].group('content').splitlines(keepends=True)
+           )
+           return tomllib.loads(content)
+       else:
+           return None
+
+Often tools will edit dependencies like package managers or dependency update
+automation in CI. The following is a crude example of modifying the content
+using the ``tomlkit`` library__.
+
+__ https://tomlkit.readthedocs.io/en/latest/
+
+.. code:: python
+
+   import re
+
+   import tomlkit
+
+   REGEX = r'(?m)^# /// (?P[a-zA-Z0-9-]+)$\s(?P(^#(| .*)$\s)+)^# ///$'
+
+   def add(script: str, dependency: str) -> str:
+       match = re.search(REGEX, script)
+       content = ''.join(
+           line[2:] if line.startswith('# ') else line[1:]
+           for line in match.group('content').splitlines(keepends=True)
+       )
+
+       config = tomlkit.parse(content)
+       config['project']['dependencies'].append(dependency)
+       new_content = ''.join(
+           f'# {line}' if line.strip() else f'#{line}'
+           for line in tomlkit.dumps(config).splitlines(keepends=True)
+       )
+
+       start, end = match.span('content')
+       return script[:start] + new_content + script[end:]
+
+Note that this example used a library that preserves TOML formatting. This is
+not a requirement for editing by any means but rather is a "nice to have"
+feature.
+
+The following is an example of how to read a stream of arbitrary metadata
+blocks.
+
+.. code:: python
+
+   import re
+   from typing import Iterator
+
+   REGEX = r'(?m)^# /// (?P[a-zA-Z0-9-]+)$\s(?P(^#(| .*)$\s)+)^# ///$'
+
+   def stream(script: str) -> Iterator[tuple[str, str]]:
+       for match in re.finditer(REGEX, script):
+           yield match.group('type'), ''.join(
+               line[2:] if line.startswith('# ') else line[1:]
+               for line in match.group('content').splitlines(keepends=True)
+           )
+
+
+Backwards Compatibility
+=======================
+
+At the time of writing, the ``# /// pyproject`` block comment starter does not
+appear `on GitHub`__. Therefore, there is little risk of existing scripts being
+broken by this PEP.
+
+__ https://github.com/search?q=%22%23+%2F%2F%2F+pyproject%22&type=code
+
+
+Security Implications
+=====================
+
+If a script containing embedded metadata is ran using a tool that automatically
+installs dependencies, this could cause arbitrary code to be downloaded and
+installed in the user's environment.
+
+The risk here is part of the functionality of the tool being used to run the
+script, and as such should already be addressed by the tool itself. The only
+additional risk introduced by this PEP is if an untrusted script with a
+embedded metadata is run, when a potentially malicious dependency or transitive
+dependency might be installed.
+
+This risk is addressed by the normal good practice of reviewing code
+before running it. Additionally, tools may be able to provide
+`locking functionality <723-tool-configuration_>`__ to ameliorate this risk.
+
+
+How to Teach This
+=================
+
+To embed metadata in a script, define a comment block that starts with the
+line ``# /// pyproject`` and ends with the line ``# ///``. Every line between
+those two lines must be a comment and the full content is derived by removing
+the first two characters. The ``pyproject`` type indicates that the content
+is TOML and resembles a ``pyproject.toml`` file.
+
+.. code:: python
+
+    # /// pyproject
+    # [run]
+    # dependencies = [
+    #   "requests<3",
+    #   "rich",
+    # ]
+    # requires-python = ">=3.11"
+    # ///
+
+The two allowed tables are ``[run]`` and ``[tool]``. The ``[run]`` table may
+contain the following fields:
+
+.. list-table::
+
+   * - Field
+     - Description
+     - Tool behavior
+
+   * - ``dependencies``
+     - A list of strings that specifies the runtime dependencies of the script.
+       Each entry must be a valid :pep:`508` dependency.
+     - Tools will error if the specified dependencies cannot be provided.
+
+   * - ``requires-python``
+     - A string that specifies the Python version(s)
+       with which the script is compatible.
+       The value of this field must be a valid
+       :pep:`version specifier <440#version-specifiers>`.
+     - Tools might error if no version of Python that satisfies
+       the constraint can be executed.
+
+It is up to individual tools whether or not their behavior is altered based on
+the embedded metadata. For example, every script runner may not be able to
+provide an environment for specific Python versions as defined by the
+``requires-python`` field.
+
+The :pep:`tool table <518#tool-table>` may be used by any tool, script runner
+or otherwise, to configure behavior.
+
+
+Recommendations
+===============
+
+Tools that support managing different versions of Python should attempt to use
+the highest available version of Python that is compatible with the script's
+``requires-python`` metadata, if defined.
+
+
+Tooling buy-in
+==============
+
+The following is a list of tools that have expressed support for this PEP or
+have committed to implementing support should it be accepted:
+
+* `Pantsbuild and Pex `__:  expressed
+  support for any way to define dependencies and also features that this PEP
+  considers as valid use cases such as building packages from scripts and
+  embedding tool configuration
+* `Mypy `__ and
+  `Ruff `__: strongly expressed support
+  for embedding tool configuration as it would solve existing pain points for
+  users
+* `Hatch `__: (author of this PEP)
+  expressed support for all aspects of this PEP, and will be one of the first
+  tools to support running scripts with specifically configured Python versions
+
+
+Rejected Ideas
+==============
+
+.. _723-comment-block:
+
+Why not use a comment block resembling requirements.txt?
+--------------------------------------------------------
+
+This PEP considers there to be different types of users for whom Python code
+would live as single-file scripts:
+
+* Non-programmers who are just using Python as a scripting language to achieve
+  a specific task. These users are unlikely to be familiar with concepts of
+  operating systems like shebang lines or the ``PATH`` environment variable.
+  Some examples:
+
+  * The average person, perhaps at a workplace, who wants to write a script to
+    automate something for efficiency or to reduce tedium
+  * Someone doing data science or machine learning in industry or academia who
+    wants to write a script to analyze some data or for research purposes.
+    These users are special in that, although they have limited programming
+    knowledge, they learn from sources like StackOverflow and blogs that have a
+    programming bent and are increasingly likely to be part of communities that
+    share knowledge and code. Therefore, a non-trivial number of these users
+    will have some familiarity with things like Git(Hub), Jupyter, HuggingFace,
+    etc.
+* Non-programmers who manage operating systems e.g. a sysadmin. These users are
+  able to set up ``PATH``, for example, but are unlikely to be familiar with
+  Python concepts like virtual environments. These users often operate in
+  isolation and have limited need to gain exposure to tools intended for
+  sharing like Git.
+* Programmers who manage operating systems/infrastructure e.g. SREs. These
+  users are not very likely to be familiar with Python concepts like virtual
+  environments, but are likely to be familiar with Git and most often use it
+  to version control everything required to manage infrastructure like Python
+  scripts and Kubernetes config.
+* Programmers who write scripts primarily for themselves. These users over time
+  accumulate a great number of scripts in various languages that they use to
+  automate their workflow and often store them in a single directory, that is
+  potentially version controlled for persistence. Non-Windows users may set
+  up each Python script with a shebang line pointing to the desired Python
+  executable or script runner.
+
+This PEP argues that reusing our TOML-based metadata format is the best for
+each category of user and that the requirements-like block comment is only
+approachable for those who have familiarity with ``requirements.txt``, which
+represents a small subset of users.
+
+* For the average person automating a task or the data scientist, they are
+  already starting with zero context and are unlikely to be familiar with
+  TOML nor ``requirements.txt``. These users will very likely rely on
+  snippets found online via a search engine or utilize AI in the form
+  of a chat bot or direct code completion software. Searching for Python
+  metadata formatting will lead them to the TOML-based format that already
+  exists which they can reuse. The author tested GitHub Copilot with this
+  PEP and it already supports auto-completion of ``dependencies``. In contrast,
+  a new format may take years of being trained on the Internet for models to
+  learn.
+
+  Additionally, these users are most susceptible to formatting quirks and
+  syntax errors. TOML is a well-defined format with existing online
+  validators that features assignment that is compatible with Python
+  expressions and has no strict indenting rules. The block comment format
+  on the other hand could be easily malformed by forgetting the colon, for
+  example, and debugging why it's not working with a search engine would be
+  a difficult task for such a user.
+* For the sysadmin types, they are equally unlikely as the previously described
+  users to be familiar with TOML or ``requirements.txt``. For either format
+  they would have to read documentation. They would likely be more comfortable
+  with TOML since they are used to structured data formats and there would be
+  less perceived magic in their systems.
+
+  Additionally, for maintenance of their systems ``/// pyproject`` would be
+  much easier to search for from a shell than a block comment with potentially
+  numerous extensions over time.
+* For the SRE types, they are likely to be familiar with TOML already from
+  other projects that they might have to work with like configuring the
+  `GitLab Runner`__ or `Cloud Native Buildpacks`__.
+
+  __ https://docs.gitlab.com/runner/configuration/advanced-configuration.html
+  __ https://buildpacks.io/docs/reference/config/
+
+  These users are responsible for the security of their systems and most likely
+  have security scanners set up to automatically open PRs to update versions
+  of dependencies. Such automated tools like Dependabot would have a much
+  easier time using existing TOML libraries than writing their own custom
+  parser for a block comment format.
+* For the programmer types, they are more likely to be familiar with TOML
+  than they have ever seen a ``requirements.txt`` file, unless they are a
+  Python programmer who has had previous experience with writing applications.
+  In the case of experience with the requirements format, it necessarily means
+  that they are at least somewhat familiar with the ecosystem and therefore
+  it is safe to assume they know what TOML is.
+
+  Another benefit of this PEP to these users is that their IDEs like Visual
+  Studio Code would be able to provide TOML syntax highlighting much more
+  easily than each writing custom logic for this feature.
+
+Additionally, since the original block comment alternative format (double
+``#``) went against the recommendation of :pep:`8` and as a result linters
+and IDE auto-formatters that respected the recommendation would
+`fail by default `__, the final
+proposal uses standard comments starting with a single ``#`` character without
+any obvious start nor end sequence.
+
+The concept of regular comments that do not appear to be intended for machines
+(i.e. `encoding declarations`__) affecting behavior would not be customary to
+users of Python and goes directly against the "explicit is better than
+implicit" foundational principle.
+
+__ https://docs.python.org/3/reference/lexical_analysis.html#encoding-declarations
+
+Users typing what to them looks like prose could alter runtime behavior. This
+PEP takes the view that the possibility of that happening, even when a tool
+has been set up as such (maybe by a sysadmin), is unfriendly to users.
+
+Finally, and critically, the alternatives to this PEP like :pep:`722` do not
+satisfy the use cases enumerated herein, such as setting the supported Python
+versions, the eventual building of scripts into packages, and the ability to
+have machines edit metadata on behalf of users. It is very likely that the
+requests for such features persist and conceivable that another PEP in the
+future would allow for the embedding of such metadata. At that point there
+would be multiple ways to achieve the same thing which goes against our
+foundational principle of "there should be one - and preferably only one -
+obvious way to do it".
+
+Why not use a multi-line string?
+--------------------------------
+
+A previous version of this PEP proposed that the metadata be stored as follows:
+
+.. code:: python
+
+    __pyproject__ = """
+    ...
+    """
+
+The most significant problem with this proposal is that the embedded TOML would
+be limited in the following ways:
+
+* It would not be possible to use multi-line double-quoted strings in the TOML
+  as that would conflict with the Python string containing the document. Many
+  TOML writers do not preserve style and may potentially produce output that
+  would be malformed.
+* The way in which character escaping works in Python strings is not quite the
+  way it works in TOML strings. It would be possible to preserve a one-to-one
+  character mapping by enforcing raw strings, but this ``r`` prefix requirement
+  may be potentially confusing to users.
+
+Why not reuse core metadata fields?
+-----------------------------------
+
+A previous version of this PEP proposed to reuse the existing
+`metadata standard `_ that is used to describe projects.
+
+There are two significant problems with this proposal:
+
+* The ``name`` and ``version`` fields are required and changing that would
+  require its own PEP
+* Reusing the data is `fundamentally a misuse of it`__
+
+  __ https://snarky.ca/differentiating-between-writing-down-dependencies-to-use-packages-and-for-packages-themselves/
+
+Why not limit to specific metadata fields?
+------------------------------------------
+
+By limiting the metadata to just ``dependencies``, we would prevent the known
+use case of tools that support managing Python installations, which would
+allows users to target specific versions of Python for new syntax or standard
+library functionality.
+
+.. _723-tool-configuration:
+
+Why not limit tool configuration?
+---------------------------------
+
+By not allowing the ``[tool]`` table, we would prevent known functionality
+that would benefit users. For example:
+
+* A script runner may support injecting of dependency resolution data for an
+  embedded lock file (this is what Go's ``gorun`` can do).
+* A script runner may support configuration instructing to run scripts in
+  containers for situations in which there is no cross-platform support for a
+  dependency or if the setup is too complex for the average user like when
+  requiring Nvidia drivers. Situations like this would allow users to proceed
+  with what they want to do whereas otherwise they may stop at that point
+  altogether.
+* Tools may wish to experiment with features to ease development burden for
+  users such as the building of single-file scripts into packages. We received
+  `feedback `__ stating that there are
+  already tools that exist in the wild that build wheels and source
+  distributions from single files.
+
+  The author of the Rust RFC for embedding metadata
+  `mentioned to us `__ that they are
+  actively looking into that as well based on user feedback saying that there
+  is unnecessary friction with managing small projects.
+
+  There has been `a commitment `__ to
+  support this by at least one major build system.
+
+Why not limit tool behavior?
+----------------------------
+
+A previous version of this PEP proposed that non-script running tools SHOULD
+NOT modify their behavior when the script is not the sole input to the tool.
+For example, if a linter is invoked with the path to a directory, it SHOULD
+behave the same as if zero files had embedded metadata.
+
+This was done as a precaution to avoid tool behavior confusion and generating
+various feature requests for tools to support this PEP. However, during
+discussion we received `feedback `__
+from maintainers of tools that this would be undesirable and potentially
+confusing to users. Additionally, this may allow for a universally easier
+way to configure tools in certain circumstances and solve existing issues.
+
+Why not just set up a Python project with a ``pyproject.toml``?
+---------------------------------------------------------------
+
+Again, a key issue here is that the target audience for this proposal is people
+writing scripts which aren't intended for distribution. Sometimes scripts will
+be "shared", but this is far more informal than "distribution" - it typically
+involves sending a script via an email with some written instructions on how to
+run it, or passing someone a link to a GitHub gist.
+
+Expecting such users to learn the complexities of Python packaging is a
+significant step up in complexity, and would almost certainly give the
+impression that "Python is too hard for scripts".
+
+In addition, if the expectation here is that the ``pyproject.toml`` will
+somehow be designed for running scripts in place, that's a new feature of the
+standard that doesn't currently exist. At a minimum, this isn't a reasonable
+suggestion until the `current discussion on Discourse
+`_ about using ``pyproject.toml`` for projects that
+won't be distributed as wheels is resolved. And even then, it doesn't address
+the "sending someone a script in a gist or email" use case.
+
+Why not infer the requirements from import statements?
+------------------------------------------------------
+
+The idea would be to automatically recognize ``import`` statements in the source
+file and turn them into a list of requirements.
+
+However, this is infeasible for several reasons. First, the points above about
+the necessity to keep the syntax easily parsable, for all Python versions, also
+by tools written in other languages, apply equally here.
+
+Second, PyPI and other package repositories conforming to the Simple Repository
+API do not provide a mechanism to resolve package names from the module names
+that are imported (see also `this related discussion`__).
+
+__ https://discuss.python.org/t/record-the-top-level-names-of-a-wheel-in-metadata/29494
+
+Third, even if repositories did offer this information, the same import name may
+correspond to several packages on PyPI. One might object that disambiguating
+which package is wanted would only be needed if there are several projects
+providing the same import name. However, this would make it easy for anyone to
+unintentionally or malevolently break working scripts, by uploading a package to
+PyPI providing an import name that is the same as an existing project. The
+alternative where, among the candidates, the first package to have been
+registered on the index is chosen, would be confusing in case a popular package
+is developed with the same import name as an existing obscure package, and even
+harmful if the existing package is malware intentionally uploaded with a
+sufficiently generic import name that has a high probability of being reused.
+
+A related idea would be to attach the requirements as comments to the import
+statements instead of gathering them in a block, with a syntax such as::
+
+  import numpy as np # requires: numpy
+  import rich # requires: rich
+
+This still suffers from parsing difficulties. Also, where to place the comment
+in the case of multiline imports is ambiguous and may look ugly::
+
+   from PyQt5.QtWidgets import (
+       QCheckBox, QComboBox, QDialog, QDialogButtonBox,
+       QGridLayout, QLabel, QSpinBox, QTextEdit
+   ) # requires: PyQt5
+
+Furthermore, this syntax cannot behave as might be intuitively expected
+in all situations. Consider::
+
+  import platform
+  if platform.system() == "Windows":
+      import pywin32 # requires: pywin32
+
+Here, the user's intent is that the package is only required on Windows, but
+this cannot be understood by the script runner (the correct way to write
+it would be ``requires: pywin32 ; sys_platform == 'win32'``).
+
+(Thanks to Jean Abou-Samra for the clear discussion of this point)
+
+Why not use a requirements file for dependencies?
+-------------------------------------------------
+
+Putting your requirements in a requirements file, doesn't require a PEP. You
+can do that right now, and in fact it's quite likely that many adhoc solutions
+do this. However, without a standard, there's no way of knowing how to locate a
+script's dependency data. And furthermore, the requirements file format is
+pip-specific, so tools relying on it are depending on a pip implementation
+detail.
+
+So in order to make a standard, two things would be required:
+
+1. A standardised replacement for the requirements file format.
+2. A standard for how to locate the requirements file for a given script.
+
+The first item is a significant undertaking. It has been discussed on a number
+of occasions, but so far no-one has attempted to actually do it. The most
+likely approach would be for standards to be developed for individual use cases
+currently addressed with requirements files. One option here would be for this
+PEP to simply define a new file format which is simply a text file containing
+:pep:`508` requirements, one per line. That would just leave the question of
+how to locate that file.
+
+The "obvious" solution here would be to do something like name the file the
+same as the script, but with a ``.reqs`` extension (or something similar).
+However, this still requires *two* files, where currently only a single file is
+needed, and as such, does not match the "better batch file" model (shell
+scripts and batch files are typically self-contained). It requires the
+developer to remember to keep the two files together, and this may not always
+be possible. For example, system administration policies may require that *all*
+files in a certain directory are executable (the Linux filesystem standards
+require this of ``/usr/bin``, for example). And some methods of sharing a
+script (for example, publishing it on a text file sharing service like Github's
+gist, or a corporate intranet) may not allow for deriving the location of an
+associated requirements file from the script's location (tools like ``pipx``
+support running a script directly from a URL, so "download and unpack a zip of
+the script and its dependencies" may not be an appropriate requirement).
+
+Essentially, though, the issue here is that there is an explicitly stated
+requirement that the format supports storing dependency data *in the script
+file itself*. Solutions that don't do that are simply ignoring that
+requirement.
+
+Why not use (possibly restricted) Python syntax?
+------------------------------------------------
+
+This would typically involve storing metadata as multiple special variables,
+such as the following.
+
+.. code:: python
+
+    __requires_python__ = ">=3.11"
+    __dependencies__ = [
+        "requests",
+        "click",
+    ]
+
+The most significant problem with this proposal is that it requires all
+consumers of the dependency data to implement a Python parser. Even if the
+syntax is restricted, the *rest* of the script will use the full Python syntax,
+and trying to define a syntax which can be successfully parsed in isolation
+from the surrounding code is likely to be extremely difficult and error-prone.
+
+Furthermore, Python's syntax changes in every release. If extracting dependency
+data needs a Python parser, the parser will need to know which version of
+Python the script is written for, and the overhead for a generic tool of having
+a parser that can handle *multiple* versions of Python is unsustainable.
+
+With this approach there is the potential to clutter scripts with many
+variables as new extensions get added. Additionally, intuiting which metadata
+fields correspond to which variable names would cause confusion for users.
+
+It is worth noting, though, that the ``pip-run`` utility does implement (an
+extended form of) this approach. `Further discussion `_ of
+the ``pip-run`` design is available on the project's issue tracker.
+
+What about local dependencies?
+------------------------------
+
+These can be handled without needing special metadata and tooling, simply by
+adding the location of the dependencies to ``sys.path``. This PEP simply isn't
+needed for this case. If, on the other hand, the "local dependencies" are
+actual distributions which are published locally, they can be specified as
+usual with a :pep:`508` requirement, and the local package index specified when
+running a tool by using the tool's UI for that.
+
+Open Issues
+===========
+
+None at this point.
+
+
+References
+==========
+
+.. _pyproject metadata: https://packaging.python.org/en/latest/specifications/declaring-project-metadata/
+.. _pip-run issue: https://github.com/jaraco/pip-run/issues/44
+.. _pyproject without wheels: https://discuss.python.org/t/projects-that-arent-meant-to-generate-a-wheel-and-pyproject-toml/29684
+
+
+Footnotes
+=========
+
+.. [1] A large number of users use scripts that are version controlled. For
+   example, `the SREs that were mentioned <723-comment-block_>`_ or
+   projects that require special maintenance like the
+   `AWS CLI `__
+   or `Calibre `__.
+.. [2] The syntax is taken directly from the final resolution of the
+   `Blocks extension`__ to `Python Markdown`__.
+
+   __ https://github.com/facelessuser/pymdown-extensions/discussions/1973
+   __ https://github.com/Python-Markdown/markdown
+.. [3] A future PEP that officially introduces the ``[run]`` table to
+   ``pyproject.toml`` files will make this PEP not just similar but a strict
+   subset.
+.. [4] One important thing to note is that the metadata is embedded in a
+   `doc-comment`__ (their equivalent of docstrings). `Other syntaxes`__ are
+   under consideration within the Rust project.
+
+   __ https://doc.rust-lang.org/stable/book/ch14-02-publishing-to-crates-io.html#making-useful-documentation-comments
+   __ https://github.com/epage/cargo-script-mvs/blob/main/0000-cargo-script.md#embedded-manifest-format
+
+
+Copyright
+=========
+
+This document is placed in the public domain or under the
+CC0-1.0-Universal license, whichever is more permissive.

From ff9926fd8c6c9ad71224513bfa563719f07950a4 Mon Sep 17 00:00:00 2001
From: chrysle 
Date: Sun, 12 Nov 2023 10:24:47 +0100
Subject: [PATCH 0496/1072] Warn of exceeding PyPI project size limit in GHA
 guide

---
 ...tion-releases-using-github-actions-ci-cd-workflows.rst | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
index 33cc88017..db7c88973 100644
--- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
+++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
@@ -219,6 +219,14 @@ And it'll publish any push to TestPyPI which is useful for
 providing test builds to your alpha users as well as making
 sure that your release pipeline remains healthy!
 
+.. attention::
+
+  If your repository has frequent commit activity and every push is uploaded
+  to TestPyPI as described, the project might exceed the
+  `PyPI project size limit `_.
+  The limit could be increased, but a better solution may constitute to
+  use a PyPI-compatible server like :ref:`pypiserver` in the CI for testing purposes.
+
 .. note::
 
    It is recommended to keep the integrated GitHub Actions at their latest

From 52db69f91b6d3f3e390761b428dbb5de6d59816e Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sun, 12 Nov 2023 22:11:25 +0100
Subject: [PATCH 0497/1072] Add ref to version-specifiers

---
 source/guides/writing-pyproject-toml.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index 70028856c..9d3634f10 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -67,6 +67,10 @@ Put the version of your project.
     [project]
     version = "2020.0.0"
 
+Some more complicated version specifiers like ``2020.0.0a1`` (for an alpha
+release) are possible; see the :ref:`specification `
+for full details.
+
 This field is required, although it is often marked as dynamic using
 
 .. code-block:: toml

From b4ffccd73ea4466ea32010f8da67fda19c0768de Mon Sep 17 00:00:00 2001
From: chrysle 
Date: Sun, 12 Nov 2023 10:02:39 +0100
Subject: [PATCH 0498/1072] Improve namespace packaging guide

---
 .../guides/packaging-namespace-packages.rst   | 84 +++++++++++++------
 1 file changed, 58 insertions(+), 26 deletions(-)

diff --git a/source/guides/packaging-namespace-packages.rst b/source/guides/packaging-namespace-packages.rst
index 301b53d63..d2b05a701 100644
--- a/source/guides/packaging-namespace-packages.rst
+++ b/source/guides/packaging-namespace-packages.rst
@@ -57,24 +57,15 @@ import object short).
 Creating a namespace package
 ============================
 
-There are currently three different approaches to creating namespace packages:
+There are currently two different approaches to creating namespace packages,
+from which the latter is discouraged:
 
 #. Use `native namespace packages`_. This type of namespace package is defined
    in :pep:`420` and is available in Python 3.3 and later. This is recommended if
    packages in your namespace only ever need to support Python 3 and
    installation via ``pip``.
-#. Use `pkgutil-style namespace packages`_. This is recommended for new
-   packages that need to support Python 2 and 3 and installation via both
-   ``pip`` and ``python setup.py install``.
-#. Use `pkg_resources-style namespace packages`_. This method is recommended if
-   you need compatibility with packages already using this method or if your
-   package needs to be zip-safe.
-
-.. warning:: While native namespace packages and pkgutil-style namespace
-    packages are largely compatible, pkg_resources-style namespace packages
-    are not compatible with the other methods. It's inadvisable to use
-    different methods in different distributions that provide packages to the
-    same namespace.
+#. Use `legacy namespace packages`_. This comprises `pkgutil-style namespace packages`_
+   and `pkg_resources-style namespace packages`_.
 
 Native namespace packages
 -------------------------
@@ -86,13 +77,14 @@ structure:
 
 .. code-block:: text
 
-    setup.py
-    mynamespace/
+    mynamespace-subpackage-a/
+        setup.py # AND/OR pyproject.toml, setup.cfg
+        mynamespace/ # namespace package
         # No __init__.py here.
-        subpackage_a/
-            # Sub-packages have __init__.py.
-            __init__.py
-            module.py
+            subpackage_a/
+                # Sub-packages have an __init__.py.
+                __init__.py
+                module.py
 
 It is extremely important that every distribution that uses the namespace
 package omits the :file:`__init__.py` or uses a pkgutil-style
@@ -112,8 +104,31 @@ list all packages in your :file:`setup.py`. For example:
         name='mynamespace-subpackage-a',
         ...
         packages=find_namespace_packages(include=['mynamespace.*'])
+        # or list a single package explicitly:
+        # packages=['mynamespace.subpackage_a'],
     )
 
+The same can be accomplished by replacing the :file:`setup.py` in the
+namespace packages' parent directory with a :file:`pyproject.toml`,
+with the following contents:
+
+.. code-block:: toml
+
+    [build-system]
+    requires = ["setuptools", "setuptools-scm"]
+    build-backend = "setuptools.build_meta"
+
+    [tool.setuptools.packages.find]
+    where = ["."]
+    include = ["mynamespace.*"]
+
+    [project]
+    name = "mynamespace-subpackage-a"
+    ...
+
+:ref:`setuptools` will search the directory structure for implicit namespace
+packages by default.
+
 A complete working example of two native namespace packages can be found in
 the `native namespace package example project`_.
 
@@ -125,8 +140,25 @@ the `native namespace package example project`_.
     only support Python 3 and pkgutil-style namespace packages in the
     distributions that need to support Python 2 and 3.
 
+
+Legacy namespace packages
+-------------------------
+
+These to methods, that were used to create namespace packages prior to :pep:`420`,
+are now considered to be obsolete and should not be used unless you need compatibility
+with packages already using this method. Also, :doc:`pkg_resources `
+has been deprecated.
+
+To migrate an existing package, all packages sharing the namespace must be migrated simultaneously.
+
+.. warning:: While native namespace packages and pkgutil-style namespace
+    packages are largely compatible, pkg_resources-style namespace packages
+    are not compatible with the other methods. It's inadvisable to use
+    different methods in different distributions that provide packages to the
+    same namespace.
+
 pkgutil-style namespace packages
---------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Python 2.3 introduced the :doc:`pkgutil ` module and the
 :py:func:`python:pkgutil.extend_path` function. This can be used to declare namespace
@@ -138,7 +170,7 @@ To create a pkgutil-style namespace package, you need to provide an
 
 .. code-block:: text
 
-    setup.py
+    setup.py # AND/OR pyproject.toml, setup.cfg
     mynamespace/
         __init__.py  # Namespace package __init__.py
         subpackage_a/
@@ -146,14 +178,14 @@ To create a pkgutil-style namespace package, you need to provide an
             module.py
 
 The :file:`__init__.py` file for the namespace package needs to contain
-**only** the following:
+the following:
 
 .. code-block:: python
 
     __path__ = __import__('pkgutil').extend_path(__path__, __name__)
 
-**Every** distribution that uses the namespace package must include an
-identical :file:`__init__.py`. If any distribution does not, it will cause the
+**Every** distribution that uses the namespace package must include such
+an :file:`__init__.py`. If any distribution does not, it will cause the
 namespace logic to fail and the other sub-packages will not be importable.  Any
 additional code in :file:`__init__.py` will be inaccessible.
 
@@ -167,7 +199,7 @@ in the `pkgutil namespace example project`_.
 
 
 pkg_resources-style namespace packages
---------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 :doc:`Setuptools ` provides the `pkg_resources.declare_namespace`_ function and
 the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together
@@ -183,7 +215,7 @@ To create a pkg_resources-style namespace package, you need to provide an
 
 .. code-block:: text
 
-    setup.py
+    setup.py # AND/OR pyproject.toml, setup.cfg
     mynamespace/
         __init__.py  # Namespace package __init__.py
         subpackage_a/

From 5b845361c57b9c27e6f26de2308be6e03a5d9594 Mon Sep 17 00:00:00 2001
From: chrysle 
Date: Sun, 12 Nov 2023 16:07:32 +0100
Subject: [PATCH 0499/1072] Migrate examples to ``src-layout``

And de-emphasize ``setup.py`` in favor of ``pyproject.toml``.
---
 .../guides/packaging-namespace-packages.rst   | 126 ++++++++++--------
 1 file changed, 71 insertions(+), 55 deletions(-)

diff --git a/source/guides/packaging-namespace-packages.rst b/source/guides/packaging-namespace-packages.rst
index d2b05a701..2200c130e 100644
--- a/source/guides/packaging-namespace-packages.rst
+++ b/source/guides/packaging-namespace-packages.rst
@@ -19,7 +19,7 @@ have the following package structure:
             __init__.py
             ...
         module_b.py
-    setup.py
+    pyproject.toml
 
 And you use this package in your code like so::
 
@@ -31,17 +31,19 @@ Then you can break these sub-packages into two separate distributions:
 .. code-block:: text
 
     mynamespace-subpackage-a/
-        setup.py
-        mynamespace/
-            subpackage_a/
-                __init__.py
+        pyproject.toml
+        src/
+            mynamespace/
+                subpackage_a/
+                    __init__.py
 
     mynamespace-subpackage-b/
-        setup.py
-        mynamespace/
-            subpackage_b/
-                __init__.py
-            module_b.py
+        pyproject.toml
+        src/
+            mynamespace/
+                subpackage_b/
+                    __init__.py
+                module_b.py
 
 Each sub-package can now be separately installed, used, and versioned.
 
@@ -73,44 +75,29 @@ Native namespace packages
 Python 3.3 added **implicit** namespace packages from :pep:`420`. All that is
 required to create a native namespace package is that you just omit
 :file:`__init__.py` from the namespace package directory. An example file
-structure:
+structure (following :ref:`src-layout `):
 
 .. code-block:: text
 
     mynamespace-subpackage-a/
-        setup.py # AND/OR pyproject.toml, setup.cfg
-        mynamespace/ # namespace package
-        # No __init__.py here.
-            subpackage_a/
-                # Sub-packages have an __init__.py.
-                __init__.py
-                module.py
+        pyproject.toml # AND/OR setup.py, setup.cfg
+        src/
+            mynamespace/ # namespace package
+            # No __init__.py here.
+                subpackage_a/
+                    # Sub-packages have an __init__.py.
+                    __init__.py
+                    module.py
 
 It is extremely important that every distribution that uses the namespace
 package omits the :file:`__init__.py` or uses a pkgutil-style
 :file:`__init__.py`. If any distribution does not, it will cause the namespace
 logic to fail and the other sub-packages will not be importable.
 
-Because ``mynamespace`` doesn't contain an :file:`__init__.py`,
-:func:`setuptools.find_packages` won't find the sub-package. You must
-use :func:`setuptools.find_namespace_packages` instead or explicitly
-list all packages in your :file:`setup.py`. For example:
-
-.. code-block:: python
-
-    from setuptools import setup, find_namespace_packages
-
-    setup(
-        name='mynamespace-subpackage-a',
-        ...
-        packages=find_namespace_packages(include=['mynamespace.*'])
-        # or list a single package explicitly:
-        # packages=['mynamespace.subpackage_a'],
-    )
-
-The same can be accomplished by replacing the :file:`setup.py` in the
-namespace packages' parent directory with a :file:`pyproject.toml`,
-with the following contents:
+The ``src-layout`` directory structure allows automatic discovery of packages
+by most :term:`build backends `. If however you want to manage
+exclusions or inclusions of packages yourself, this is possible to be configured
+in the top-level :file:`pyproject.toml`:
 
 .. code-block:: toml
 
@@ -119,13 +106,38 @@ with the following contents:
     build-backend = "setuptools.build_meta"
 
     [tool.setuptools.packages.find]
-    where = ["."]
-    include = ["mynamespace.*"]
+    where = ["src/"]
+    include = ["mynamespace.subpackage_a"]
 
     [project]
     name = "mynamespace-subpackage-a"
     ...
 
+The same can be accomplished with a :file:`setup.cfg`:
+
+.. code-block:: ini
+
+   [options]
+    package_dir =
+        =src
+    packages = find_namespace:
+
+    [options.packages.find]
+    where = src
+
+Or :file:`setup.py`:
+
+.. code-block:: python
+
+    from setuptools import setup, find_namespace_packages
+
+    setup(
+        name='mynamespace-subpackage-a',
+        ...
+        packages=find_namespace_packages(where='src/', include=['mynamespace.subpackage_a']),
+        package_dir={"": "src"},
+    )
+
 :ref:`setuptools` will search the directory structure for implicit namespace
 packages by default.
 
@@ -170,12 +182,14 @@ To create a pkgutil-style namespace package, you need to provide an
 
 .. code-block:: text
 
-    setup.py # AND/OR pyproject.toml, setup.cfg
-    mynamespace/
-        __init__.py  # Namespace package __init__.py
-        subpackage_a/
-            __init__.py  # Sub-package __init__.py
-            module.py
+    mynamespace-subpackage-a/
+        src/
+            pyproject.toml # AND/OR setup.cfg, setup.py
+            mynamespace/
+                __init__.py  # Namespace package __init__.py
+                subpackage_a/
+                    __init__.py  # Sub-package __init__.py
+                    module.py
 
 The :file:`__init__.py` file for the namespace package needs to contain
 the following:
@@ -215,22 +229,24 @@ To create a pkg_resources-style namespace package, you need to provide an
 
 .. code-block:: text
 
-    setup.py # AND/OR pyproject.toml, setup.cfg
-    mynamespace/
-        __init__.py  # Namespace package __init__.py
-        subpackage_a/
-            __init__.py  # Sub-package __init__.py
-            module.py
+    mynamespace-subpackage-a/
+        src/
+            pyproject.toml # AND/OR setup.cfg, setup.py
+            mynamespace/
+                __init__.py  # Namespace package __init__.py
+                subpackage_a/
+                    __init__.py  # Sub-package __init__.py
+                    module.py
 
 The :file:`__init__.py` file for the namespace package needs to contain
-**only** the following:
+the following:
 
 .. code-block:: python
 
     __import__('pkg_resources').declare_namespace(__name__)
 
-**Every** distribution that uses the namespace package must include an
-identical :file:`__init__.py`. If any distribution does not, it will cause the
+**Every** distribution that uses the namespace package must include such an
+:file:`__init__.py`. If any distribution does not, it will cause the
 namespace logic to fail and the other sub-packages will not be importable.  Any
 additional code in :file:`__init__.py` will be inaccessible.
 

From 927d5f6fd9e6eaec7f15979013880f86bc5c4e04 Mon Sep 17 00:00:00 2001
From: chrysle 
Date: Sun, 12 Nov 2023 16:29:12 +0100
Subject: [PATCH 0500/1072] Fix a typo

Co-authored-by: sinoroc <5529267+sinoroc@users.noreply.github.com>
---
 source/guides/packaging-namespace-packages.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/packaging-namespace-packages.rst b/source/guides/packaging-namespace-packages.rst
index 2200c130e..653530561 100644
--- a/source/guides/packaging-namespace-packages.rst
+++ b/source/guides/packaging-namespace-packages.rst
@@ -156,7 +156,7 @@ the `native namespace package example project`_.
 Legacy namespace packages
 -------------------------
 
-These to methods, that were used to create namespace packages prior to :pep:`420`,
+These two methods, that were used to create namespace packages prior to :pep:`420`,
 are now considered to be obsolete and should not be used unless you need compatibility
 with packages already using this method. Also, :doc:`pkg_resources `
 has been deprecated.

From d5e97d8fde3d7ec34ed8a646b55855e8922e4118 Mon Sep 17 00:00:00 2001
From: chrysle 
Date: Mon, 13 Nov 2023 10:15:37 +0100
Subject: [PATCH 0501/1072] Link to `src-layout vs flat-layout` discussion

---
 source/discussions/src-layout-vs-flat-layout.rst | 2 ++
 source/guides/packaging-namespace-packages.rst   | 6 +++---
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/source/discussions/src-layout-vs-flat-layout.rst b/source/discussions/src-layout-vs-flat-layout.rst
index 2bf9fcdb9..bfa405729 100644
--- a/source/discussions/src-layout-vs-flat-layout.rst
+++ b/source/discussions/src-layout-vs-flat-layout.rst
@@ -1,3 +1,5 @@
+.. _src-layout-vs-flat-layout:
+
 =========================
 src layout vs flat layout
 =========================
diff --git a/source/guides/packaging-namespace-packages.rst b/source/guides/packaging-namespace-packages.rst
index 653530561..7ff158888 100644
--- a/source/guides/packaging-namespace-packages.rst
+++ b/source/guides/packaging-namespace-packages.rst
@@ -95,9 +95,9 @@ package omits the :file:`__init__.py` or uses a pkgutil-style
 logic to fail and the other sub-packages will not be importable.
 
 The ``src-layout`` directory structure allows automatic discovery of packages
-by most :term:`build backends `. If however you want to manage
-exclusions or inclusions of packages yourself, this is possible to be configured
-in the top-level :file:`pyproject.toml`:
+by most :term:`build backends `. See :ref:`src-layout-vs-flat-layout`
+for more information. If however you want to manage exclusions or inclusions of packages 
+yourself, this is possible to be configured in the top-level :file:`pyproject.toml`:
 
 .. code-block:: toml
 

From ab57c779fecb731e4d20164afe8653dac240aee1 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 13 Nov 2023 09:21:10 +0000
Subject: [PATCH 0502/1072] [pre-commit.ci] auto fixes from pre-commit.com
 hooks

for more information, see https://pre-commit.ci
---
 source/guides/packaging-namespace-packages.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/packaging-namespace-packages.rst b/source/guides/packaging-namespace-packages.rst
index 7ff158888..5fa984260 100644
--- a/source/guides/packaging-namespace-packages.rst
+++ b/source/guides/packaging-namespace-packages.rst
@@ -96,7 +96,7 @@ logic to fail and the other sub-packages will not be importable.
 
 The ``src-layout`` directory structure allows automatic discovery of packages
 by most :term:`build backends `. See :ref:`src-layout-vs-flat-layout`
-for more information. If however you want to manage exclusions or inclusions of packages 
+for more information. If however you want to manage exclusions or inclusions of packages
 yourself, this is possible to be configured in the top-level :file:`pyproject.toml`:
 
 .. code-block:: toml

From f78f75f254df5a71645b928fc03d1fc67d864bb6 Mon Sep 17 00:00:00 2001
From: chrysle 
Date: Mon, 13 Nov 2023 10:23:12 +0100
Subject: [PATCH 0503/1072] Format code snippets

Co-authored-by: sinoroc <5529267+sinoroc@users.noreply.github.com>
---
 source/guides/packaging-namespace-packages.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/source/guides/packaging-namespace-packages.rst b/source/guides/packaging-namespace-packages.rst
index 5fa984260..e48ba873b 100644
--- a/source/guides/packaging-namespace-packages.rst
+++ b/source/guides/packaging-namespace-packages.rst
@@ -83,7 +83,7 @@ structure (following :ref:`src-layout `):
         pyproject.toml # AND/OR setup.py, setup.cfg
         src/
             mynamespace/ # namespace package
-            # No __init__.py here.
+                # No __init__.py here.
                 subpackage_a/
                     # Sub-packages have an __init__.py.
                     __init__.py
@@ -117,7 +117,7 @@ The same can be accomplished with a :file:`setup.cfg`:
 
 .. code-block:: ini
 
-   [options]
+    [options]
     package_dir =
         =src
     packages = find_namespace:
@@ -135,7 +135,7 @@ Or :file:`setup.py`:
         name='mynamespace-subpackage-a',
         ...
         packages=find_namespace_packages(where='src/', include=['mynamespace.subpackage_a']),
-        package_dir={"": "src"},
+        package_dir={'': 'src'},
     )
 
 :ref:`setuptools` will search the directory structure for implicit namespace

From 44e5ff02f620d14c63a5d7912ef67710ab02fa16 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 13 Nov 2023 18:39:55 +0000
Subject: [PATCH 0504/1072] [pre-commit.ci] pre-commit autoupdate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

updates:
- [github.com/astral-sh/ruff-pre-commit: v0.1.4 → v0.1.5](https://github.com/astral-sh/ruff-pre-commit/compare/v0.1.4...v0.1.5)
---
 .pre-commit-config.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index 88494c690..7b47351d3 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -33,7 +33,7 @@ repos:
   - id: rst-inline-touching-normal
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.1.4
+  rev: v0.1.5
   hooks:
     - id: ruff
     - id: ruff-format

From e34cf795c2c76b70baa18ba319be0b224151f9a9 Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Mon, 13 Nov 2023 19:07:55 -0500
Subject: [PATCH 0505/1072] add german words to codespell ignore

---
 .pre-commit-config.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index 88494c690..7337a6c21 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -15,7 +15,7 @@ repos:
   rev: v2.2.6
   hooks:
   - id: codespell
-    args: ["-L", "ned"]
+    args: ["-L", "ned,ist,oder"]
 
 - repo: local
   hooks:

From a8389a1972d48e576a97fb755cb480146723b605 Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Mon, 13 Nov 2023 19:27:05 -0500
Subject: [PATCH 0506/1072] Add note that News doc is not currently being
 updated

---
 source/news.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/source/news.rst b/source/news.rst
index 09415fddd..a8c70dc1b 100644
--- a/source/news.rst
+++ b/source/news.rst
@@ -1,6 +1,10 @@
 News
 ====
 
+.. note:: This document is not currently updated. Previously, the document
+  highlighted changes in Python packaging.
+
+
 September 2019
 --------------
 - Added a guide about publishing dists via GitHub Actions. (:pr:`647`)

From 8ea57348aef4b73fe2efe03a6063dcf3ae11aea1 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Tue, 14 Nov 2023 01:46:31 +0100
Subject: [PATCH 0507/1072] Change example name from spam to spam-eggs

---
 source/guides/writing-pyproject-toml.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index 9d3634f10..3c3c741c9 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -54,7 +54,7 @@ only field that cannot be marked as dynamic.
 .. code-block:: toml
 
    [project]
-   name = "spam"
+   name = "spam-eggs"
 
 
 ``version``
@@ -317,7 +317,7 @@ A full example
 .. code-block:: toml
 
    [project]
-   name = "spam"
+   name = "spam-eggs"
    version = "2020.0.0"
    dependencies = [
      "httpx",

From 1e7385dd8b49d553e4fd0788653b77d140f4d72c Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sun, 12 Nov 2023 00:16:12 +0100
Subject: [PATCH 0508/1072] PEP 723: Editing to fit the PUG

---
 .../declaring-build-dependencies.rst          |   2 +
 source/specifications/index.rst               |   1 +
 .../specifications/inline-script-metadata.rst | 654 +-----------------
 3 files changed, 33 insertions(+), 624 deletions(-)

diff --git a/source/specifications/declaring-build-dependencies.rst b/source/specifications/declaring-build-dependencies.rst
index 3ac94b0b3..1d8045eda 100644
--- a/source/specifications/declaring-build-dependencies.rst
+++ b/source/specifications/declaring-build-dependencies.rst
@@ -50,6 +50,8 @@ should consider it an error.
 
 .. TODO: move elsewhere
 
+.. _pyproject-tool-table:
+
 tool table
 ----------
 
diff --git a/source/specifications/index.rst b/source/specifications/index.rst
index 4f622d845..fb1a1fee2 100644
--- a/source/specifications/index.rst
+++ b/source/specifications/index.rst
@@ -21,6 +21,7 @@ Package Distribution Metadata
    dependency-specifiers
    declaring-build-dependencies
    declaring-project-metadata
+   inline-script-metadata
    platform-compatibility-tags
 
 Package Installation Environment Metadata
diff --git a/source/specifications/inline-script-metadata.rst b/source/specifications/inline-script-metadata.rst
index 04fb0d238..021c316fe 100644
--- a/source/specifications/inline-script-metadata.rst
+++ b/source/specifications/inline-script-metadata.rst
@@ -1,104 +1,24 @@
-PEP: 723
-Title: Inline script metadata
-Author: Ofek Lev 
-Sponsor: Adam Turner 
-PEP-Delegate: Brett Cannon 
-Discussions-To: https://discuss.python.org/t/31151
-Status: Provisional
-Type: Standards Track
-Topic: Packaging
-Content-Type: text/x-rst
-Created: 04-Aug-2023
-Post-History: `04-Aug-2023 `__,
-              `06-Aug-2023 `__,
-              `23-Aug-2023 `__,
-Replaces: 722
-Resolution: https://discuss.python.org/t/36763
-
-
-Abstract
-========
-
-This PEP specifies a metadata format that can be embedded in single-file Python
-scripts to assist launchers, IDEs and other external tools which may need to
-interact with such scripts.
-
-
-Motivation
-==========
-
-Python is routinely used as a scripting language, with Python scripts as a
-(better) alternative to shell scripts, batch files, etc. When Python code is
-structured as a script, it is usually stored as a single file and does not
-expect the availability of any other local code that may be used for imports.
-As such, it is possible to share with others over arbitrary text-based means
-such as email, a URL to the script, or even a chat window. Code that is
-structured like this may live as a single file forever, never becoming a
-full-fledged project with its own directory and ``pyproject.toml`` file.
-
-An issue that users encounter with this approach is that there is no standard
-mechanism to define metadata for tools whose job it is to execute such scripts.
-For example, a tool that runs a script may need to know which dependencies are
-required or the supported version(s) of Python.
-
-There is currently no standard tool that addresses this issue, and this PEP
-does *not* attempt to define one. However, any tool that *does* address this
-issue will need to know what the runtime requirements of scripts are. By
-defining a standard format for storing such metadata, existing tools, as well
-as any future tools, will be able to obtain that information without requiring
-users to include tool-specific metadata in their scripts.
-
-
-Rationale
-=========
-
-This PEP defines a mechanism for embedding metadata *within the script itself*,
-and not in an external file.
-
-We choose to follow the latest developments of other modern packaging
-ecosystems (namely `Go`__ and provisionally `Rust`__) by embedding the existing
-file used to describe projects, in our case ``pyproject.toml``.
-
-__ https://github.com/erning/gorun
-__ https://rust-lang.github.io/rfcs/3424-cargo-script.html
-
-The format is intended to bridge the gap between different types of users
-of Python. Users will benefit from seamless interoperability with tools that
-already work with TOML.
-
-One of the central themes we discovered from the recent
-`packaging survey `__ is that users have
-begun getting frustrated with the lack of unification regarding both tooling
-and specs. Adding yet another metadata format (like :pep:`722` syntax for a
-list of dependencies), even for a currently unsatisfied use case, would
-further fragment the community.
-
-The following are some of the use cases that this PEP wishes to support:
-
-* A user facing CLI that is capable of executing scripts. If we take Hatch as
-  an example, the interface would be simply
-  ``hatch run /path/to/script.py [args]`` and Hatch will manage the
-  environment for that script. Such tools could be used as shebang lines on
-  non-Windows systems e.g. ``#!/usr/bin/env hatch run``.
-* A script that desires to transition to a directory-type project. A user may
-  be rapidly prototyping locally or in a remote REPL environment and then
-  decide to transition to a more formal project layout if their idea works
-  out. This intermediate script stage would be very useful to have fully
-  reproducible bug reports. By using the same format, the user can simply copy
-  and paste the metadata into a ``pyproject.toml`` file and continue working
-  without having to learn a new format. More likely, even, is that tooling will
-  eventually support this transformation with a single command.
-* Users that wish to avoid manual dependency management. For example, package
-  managers that have commands to add/remove dependencies or dependency update
-  automation in CI that triggers based on new versions or in response to
-  CVEs [1]_.
+======================
+Inline script metadata
+======================
+
+.. warning::
+   This specification has been **provisionally accepted**. It is subject
+   to being changed or abandoned. See the
+   `PEP 723 conditional acceptance thread `_ for details.
+
+.. _pep723-thread: https://discuss.python.org/t/36763
+
+This specification defines a metadata format that can be embedded in single-file
+Python scripts to assist launchers, IDEs and other external tools which may need
+to interact with such scripts.
 
 
 Specification
 =============
 
-This PEP defines a metadata comment block format loosely inspired [2]_ by
-`reStructuredText Directives`__.
+This specification defines a metadata comment block format (loosely inspired by
+`reStructuredText Directives`__).
 
 __ https://docutils.sourceforge.io/docs/ref/rst/directives.html
 
@@ -159,25 +79,26 @@ pyproject type
 --------------
 
 The first type of metadata block is named ``pyproject`` which represents
-content similar to [3]_ what one would see in a ``pyproject.toml`` file.
+content similar to what one would see in a ``pyproject.toml`` file.
 
 This document MAY include the ``[run]`` and ``[tool]`` tables.
 
-The :pep:`tool table <518#tool-table>` MAY be used by any tool, script runner
-or otherwise, to configure behavior.
+The :ref:`tool table ` MAY be used by any tool,
+script runner or otherwise, to configure behavior.
 
 The ``[run]`` table MAY include the following optional fields:
 
 * ``dependencies``: A list of strings that specifies the runtime dependencies
-  of the script. Each entry MUST be a valid :pep:`508` dependency.
+  of the script. Each entry MUST be a valid
+  :ref:`dependency specifier `.
 * ``requires-python``: A string that specifies the Python version(s) with which
   the script is compatible. The value of this field MUST be a valid
-  :pep:`version specifier <440#version-specifiers>`.
+  :ref:`version specifier `.
 
-Any future PEPs that define additional fields for the ``[run]`` table when used
-in a ``pyproject.toml`` file MUST include the aforementioned fields exactly as
-specified. The fields defined by this PEP are equally as applicable to
-full-fledged projects as they are to single-file scripts.
+Any future specifications that define additional fields for the ``[run]`` table
+when used in a ``pyproject.toml`` file MUST include the aforementioned fields
+exactly as specified. The fields defined by this specification are equally as
+applicable to full-fledged projects as they are to single-file scripts.
 
 Script runners MUST error if the specified ``dependencies`` cannot be provided.
 Script runners SHOULD error if no version of Python that satisfies the specified
@@ -206,7 +127,7 @@ The following is an example of a script with an embedded ``pyproject.toml``:
     data = resp.json()
     pprint([(k, v["title"]) for k, v in data.items()][:10])
 
-The following [4]_ is an example of a proposed syntax for single-file Rust
+The following is an example of a proposed syntax for single-file Rust
 projects that embeds their equivalent of ``pyproject.toml``, which is called
 ``Cargo.toml``:
 
@@ -306,85 +227,6 @@ blocks.
            )
 
 
-Backwards Compatibility
-=======================
-
-At the time of writing, the ``# /// pyproject`` block comment starter does not
-appear `on GitHub`__. Therefore, there is little risk of existing scripts being
-broken by this PEP.
-
-__ https://github.com/search?q=%22%23+%2F%2F%2F+pyproject%22&type=code
-
-
-Security Implications
-=====================
-
-If a script containing embedded metadata is ran using a tool that automatically
-installs dependencies, this could cause arbitrary code to be downloaded and
-installed in the user's environment.
-
-The risk here is part of the functionality of the tool being used to run the
-script, and as such should already be addressed by the tool itself. The only
-additional risk introduced by this PEP is if an untrusted script with a
-embedded metadata is run, when a potentially malicious dependency or transitive
-dependency might be installed.
-
-This risk is addressed by the normal good practice of reviewing code
-before running it. Additionally, tools may be able to provide
-`locking functionality <723-tool-configuration_>`__ to ameliorate this risk.
-
-
-How to Teach This
-=================
-
-To embed metadata in a script, define a comment block that starts with the
-line ``# /// pyproject`` and ends with the line ``# ///``. Every line between
-those two lines must be a comment and the full content is derived by removing
-the first two characters. The ``pyproject`` type indicates that the content
-is TOML and resembles a ``pyproject.toml`` file.
-
-.. code:: python
-
-    # /// pyproject
-    # [run]
-    # dependencies = [
-    #   "requests<3",
-    #   "rich",
-    # ]
-    # requires-python = ">=3.11"
-    # ///
-
-The two allowed tables are ``[run]`` and ``[tool]``. The ``[run]`` table may
-contain the following fields:
-
-.. list-table::
-
-   * - Field
-     - Description
-     - Tool behavior
-
-   * - ``dependencies``
-     - A list of strings that specifies the runtime dependencies of the script.
-       Each entry must be a valid :pep:`508` dependency.
-     - Tools will error if the specified dependencies cannot be provided.
-
-   * - ``requires-python``
-     - A string that specifies the Python version(s)
-       with which the script is compatible.
-       The value of this field must be a valid
-       :pep:`version specifier <440#version-specifiers>`.
-     - Tools might error if no version of Python that satisfies
-       the constraint can be executed.
-
-It is up to individual tools whether or not their behavior is altered based on
-the embedded metadata. For example, every script runner may not be able to
-provide an environment for specific Python versions as defined by the
-``requires-python`` field.
-
-The :pep:`tool table <518#tool-table>` may be used by any tool, script runner
-or otherwise, to configure behavior.
-
-
 Recommendations
 ===============
 
@@ -393,443 +235,7 @@ the highest available version of Python that is compatible with the script's
 ``requires-python`` metadata, if defined.
 
 
-Tooling buy-in
-==============
-
-The following is a list of tools that have expressed support for this PEP or
-have committed to implementing support should it be accepted:
-
-* `Pantsbuild and Pex `__:  expressed
-  support for any way to define dependencies and also features that this PEP
-  considers as valid use cases such as building packages from scripts and
-  embedding tool configuration
-* `Mypy `__ and
-  `Ruff `__: strongly expressed support
-  for embedding tool configuration as it would solve existing pain points for
-  users
-* `Hatch `__: (author of this PEP)
-  expressed support for all aspects of this PEP, and will be one of the first
-  tools to support running scripts with specifically configured Python versions
-
-
-Rejected Ideas
-==============
-
-.. _723-comment-block:
-
-Why not use a comment block resembling requirements.txt?
---------------------------------------------------------
-
-This PEP considers there to be different types of users for whom Python code
-would live as single-file scripts:
-
-* Non-programmers who are just using Python as a scripting language to achieve
-  a specific task. These users are unlikely to be familiar with concepts of
-  operating systems like shebang lines or the ``PATH`` environment variable.
-  Some examples:
-
-  * The average person, perhaps at a workplace, who wants to write a script to
-    automate something for efficiency or to reduce tedium
-  * Someone doing data science or machine learning in industry or academia who
-    wants to write a script to analyze some data or for research purposes.
-    These users are special in that, although they have limited programming
-    knowledge, they learn from sources like StackOverflow and blogs that have a
-    programming bent and are increasingly likely to be part of communities that
-    share knowledge and code. Therefore, a non-trivial number of these users
-    will have some familiarity with things like Git(Hub), Jupyter, HuggingFace,
-    etc.
-* Non-programmers who manage operating systems e.g. a sysadmin. These users are
-  able to set up ``PATH``, for example, but are unlikely to be familiar with
-  Python concepts like virtual environments. These users often operate in
-  isolation and have limited need to gain exposure to tools intended for
-  sharing like Git.
-* Programmers who manage operating systems/infrastructure e.g. SREs. These
-  users are not very likely to be familiar with Python concepts like virtual
-  environments, but are likely to be familiar with Git and most often use it
-  to version control everything required to manage infrastructure like Python
-  scripts and Kubernetes config.
-* Programmers who write scripts primarily for themselves. These users over time
-  accumulate a great number of scripts in various languages that they use to
-  automate their workflow and often store them in a single directory, that is
-  potentially version controlled for persistence. Non-Windows users may set
-  up each Python script with a shebang line pointing to the desired Python
-  executable or script runner.
-
-This PEP argues that reusing our TOML-based metadata format is the best for
-each category of user and that the requirements-like block comment is only
-approachable for those who have familiarity with ``requirements.txt``, which
-represents a small subset of users.
-
-* For the average person automating a task or the data scientist, they are
-  already starting with zero context and are unlikely to be familiar with
-  TOML nor ``requirements.txt``. These users will very likely rely on
-  snippets found online via a search engine or utilize AI in the form
-  of a chat bot or direct code completion software. Searching for Python
-  metadata formatting will lead them to the TOML-based format that already
-  exists which they can reuse. The author tested GitHub Copilot with this
-  PEP and it already supports auto-completion of ``dependencies``. In contrast,
-  a new format may take years of being trained on the Internet for models to
-  learn.
-
-  Additionally, these users are most susceptible to formatting quirks and
-  syntax errors. TOML is a well-defined format with existing online
-  validators that features assignment that is compatible with Python
-  expressions and has no strict indenting rules. The block comment format
-  on the other hand could be easily malformed by forgetting the colon, for
-  example, and debugging why it's not working with a search engine would be
-  a difficult task for such a user.
-* For the sysadmin types, they are equally unlikely as the previously described
-  users to be familiar with TOML or ``requirements.txt``. For either format
-  they would have to read documentation. They would likely be more comfortable
-  with TOML since they are used to structured data formats and there would be
-  less perceived magic in their systems.
-
-  Additionally, for maintenance of their systems ``/// pyproject`` would be
-  much easier to search for from a shell than a block comment with potentially
-  numerous extensions over time.
-* For the SRE types, they are likely to be familiar with TOML already from
-  other projects that they might have to work with like configuring the
-  `GitLab Runner`__ or `Cloud Native Buildpacks`__.
-
-  __ https://docs.gitlab.com/runner/configuration/advanced-configuration.html
-  __ https://buildpacks.io/docs/reference/config/
-
-  These users are responsible for the security of their systems and most likely
-  have security scanners set up to automatically open PRs to update versions
-  of dependencies. Such automated tools like Dependabot would have a much
-  easier time using existing TOML libraries than writing their own custom
-  parser for a block comment format.
-* For the programmer types, they are more likely to be familiar with TOML
-  than they have ever seen a ``requirements.txt`` file, unless they are a
-  Python programmer who has had previous experience with writing applications.
-  In the case of experience with the requirements format, it necessarily means
-  that they are at least somewhat familiar with the ecosystem and therefore
-  it is safe to assume they know what TOML is.
-
-  Another benefit of this PEP to these users is that their IDEs like Visual
-  Studio Code would be able to provide TOML syntax highlighting much more
-  easily than each writing custom logic for this feature.
-
-Additionally, since the original block comment alternative format (double
-``#``) went against the recommendation of :pep:`8` and as a result linters
-and IDE auto-formatters that respected the recommendation would
-`fail by default `__, the final
-proposal uses standard comments starting with a single ``#`` character without
-any obvious start nor end sequence.
-
-The concept of regular comments that do not appear to be intended for machines
-(i.e. `encoding declarations`__) affecting behavior would not be customary to
-users of Python and goes directly against the "explicit is better than
-implicit" foundational principle.
-
-__ https://docs.python.org/3/reference/lexical_analysis.html#encoding-declarations
-
-Users typing what to them looks like prose could alter runtime behavior. This
-PEP takes the view that the possibility of that happening, even when a tool
-has been set up as such (maybe by a sysadmin), is unfriendly to users.
-
-Finally, and critically, the alternatives to this PEP like :pep:`722` do not
-satisfy the use cases enumerated herein, such as setting the supported Python
-versions, the eventual building of scripts into packages, and the ability to
-have machines edit metadata on behalf of users. It is very likely that the
-requests for such features persist and conceivable that another PEP in the
-future would allow for the embedding of such metadata. At that point there
-would be multiple ways to achieve the same thing which goes against our
-foundational principle of "there should be one - and preferably only one -
-obvious way to do it".
-
-Why not use a multi-line string?
---------------------------------
-
-A previous version of this PEP proposed that the metadata be stored as follows:
-
-.. code:: python
-
-    __pyproject__ = """
-    ...
-    """
-
-The most significant problem with this proposal is that the embedded TOML would
-be limited in the following ways:
-
-* It would not be possible to use multi-line double-quoted strings in the TOML
-  as that would conflict with the Python string containing the document. Many
-  TOML writers do not preserve style and may potentially produce output that
-  would be malformed.
-* The way in which character escaping works in Python strings is not quite the
-  way it works in TOML strings. It would be possible to preserve a one-to-one
-  character mapping by enforcing raw strings, but this ``r`` prefix requirement
-  may be potentially confusing to users.
-
-Why not reuse core metadata fields?
------------------------------------
-
-A previous version of this PEP proposed to reuse the existing
-`metadata standard `_ that is used to describe projects.
-
-There are two significant problems with this proposal:
-
-* The ``name`` and ``version`` fields are required and changing that would
-  require its own PEP
-* Reusing the data is `fundamentally a misuse of it`__
-
-  __ https://snarky.ca/differentiating-between-writing-down-dependencies-to-use-packages-and-for-packages-themselves/
-
-Why not limit to specific metadata fields?
-------------------------------------------
-
-By limiting the metadata to just ``dependencies``, we would prevent the known
-use case of tools that support managing Python installations, which would
-allows users to target specific versions of Python for new syntax or standard
-library functionality.
-
-.. _723-tool-configuration:
-
-Why not limit tool configuration?
----------------------------------
-
-By not allowing the ``[tool]`` table, we would prevent known functionality
-that would benefit users. For example:
-
-* A script runner may support injecting of dependency resolution data for an
-  embedded lock file (this is what Go's ``gorun`` can do).
-* A script runner may support configuration instructing to run scripts in
-  containers for situations in which there is no cross-platform support for a
-  dependency or if the setup is too complex for the average user like when
-  requiring Nvidia drivers. Situations like this would allow users to proceed
-  with what they want to do whereas otherwise they may stop at that point
-  altogether.
-* Tools may wish to experiment with features to ease development burden for
-  users such as the building of single-file scripts into packages. We received
-  `feedback `__ stating that there are
-  already tools that exist in the wild that build wheels and source
-  distributions from single files.
-
-  The author of the Rust RFC for embedding metadata
-  `mentioned to us `__ that they are
-  actively looking into that as well based on user feedback saying that there
-  is unnecessary friction with managing small projects.
-
-  There has been `a commitment `__ to
-  support this by at least one major build system.
-
-Why not limit tool behavior?
-----------------------------
-
-A previous version of this PEP proposed that non-script running tools SHOULD
-NOT modify their behavior when the script is not the sole input to the tool.
-For example, if a linter is invoked with the path to a directory, it SHOULD
-behave the same as if zero files had embedded metadata.
-
-This was done as a precaution to avoid tool behavior confusion and generating
-various feature requests for tools to support this PEP. However, during
-discussion we received `feedback `__
-from maintainers of tools that this would be undesirable and potentially
-confusing to users. Additionally, this may allow for a universally easier
-way to configure tools in certain circumstances and solve existing issues.
-
-Why not just set up a Python project with a ``pyproject.toml``?
----------------------------------------------------------------
-
-Again, a key issue here is that the target audience for this proposal is people
-writing scripts which aren't intended for distribution. Sometimes scripts will
-be "shared", but this is far more informal than "distribution" - it typically
-involves sending a script via an email with some written instructions on how to
-run it, or passing someone a link to a GitHub gist.
-
-Expecting such users to learn the complexities of Python packaging is a
-significant step up in complexity, and would almost certainly give the
-impression that "Python is too hard for scripts".
-
-In addition, if the expectation here is that the ``pyproject.toml`` will
-somehow be designed for running scripts in place, that's a new feature of the
-standard that doesn't currently exist. At a minimum, this isn't a reasonable
-suggestion until the `current discussion on Discourse
-`_ about using ``pyproject.toml`` for projects that
-won't be distributed as wheels is resolved. And even then, it doesn't address
-the "sending someone a script in a gist or email" use case.
-
-Why not infer the requirements from import statements?
-------------------------------------------------------
-
-The idea would be to automatically recognize ``import`` statements in the source
-file and turn them into a list of requirements.
-
-However, this is infeasible for several reasons. First, the points above about
-the necessity to keep the syntax easily parsable, for all Python versions, also
-by tools written in other languages, apply equally here.
-
-Second, PyPI and other package repositories conforming to the Simple Repository
-API do not provide a mechanism to resolve package names from the module names
-that are imported (see also `this related discussion`__).
-
-__ https://discuss.python.org/t/record-the-top-level-names-of-a-wheel-in-metadata/29494
-
-Third, even if repositories did offer this information, the same import name may
-correspond to several packages on PyPI. One might object that disambiguating
-which package is wanted would only be needed if there are several projects
-providing the same import name. However, this would make it easy for anyone to
-unintentionally or malevolently break working scripts, by uploading a package to
-PyPI providing an import name that is the same as an existing project. The
-alternative where, among the candidates, the first package to have been
-registered on the index is chosen, would be confusing in case a popular package
-is developed with the same import name as an existing obscure package, and even
-harmful if the existing package is malware intentionally uploaded with a
-sufficiently generic import name that has a high probability of being reused.
-
-A related idea would be to attach the requirements as comments to the import
-statements instead of gathering them in a block, with a syntax such as::
-
-  import numpy as np # requires: numpy
-  import rich # requires: rich
-
-This still suffers from parsing difficulties. Also, where to place the comment
-in the case of multiline imports is ambiguous and may look ugly::
-
-   from PyQt5.QtWidgets import (
-       QCheckBox, QComboBox, QDialog, QDialogButtonBox,
-       QGridLayout, QLabel, QSpinBox, QTextEdit
-   ) # requires: PyQt5
-
-Furthermore, this syntax cannot behave as might be intuitively expected
-in all situations. Consider::
-
-  import platform
-  if platform.system() == "Windows":
-      import pywin32 # requires: pywin32
-
-Here, the user's intent is that the package is only required on Windows, but
-this cannot be understood by the script runner (the correct way to write
-it would be ``requires: pywin32 ; sys_platform == 'win32'``).
-
-(Thanks to Jean Abou-Samra for the clear discussion of this point)
-
-Why not use a requirements file for dependencies?
--------------------------------------------------
-
-Putting your requirements in a requirements file, doesn't require a PEP. You
-can do that right now, and in fact it's quite likely that many adhoc solutions
-do this. However, without a standard, there's no way of knowing how to locate a
-script's dependency data. And furthermore, the requirements file format is
-pip-specific, so tools relying on it are depending on a pip implementation
-detail.
-
-So in order to make a standard, two things would be required:
-
-1. A standardised replacement for the requirements file format.
-2. A standard for how to locate the requirements file for a given script.
-
-The first item is a significant undertaking. It has been discussed on a number
-of occasions, but so far no-one has attempted to actually do it. The most
-likely approach would be for standards to be developed for individual use cases
-currently addressed with requirements files. One option here would be for this
-PEP to simply define a new file format which is simply a text file containing
-:pep:`508` requirements, one per line. That would just leave the question of
-how to locate that file.
-
-The "obvious" solution here would be to do something like name the file the
-same as the script, but with a ``.reqs`` extension (or something similar).
-However, this still requires *two* files, where currently only a single file is
-needed, and as such, does not match the "better batch file" model (shell
-scripts and batch files are typically self-contained). It requires the
-developer to remember to keep the two files together, and this may not always
-be possible. For example, system administration policies may require that *all*
-files in a certain directory are executable (the Linux filesystem standards
-require this of ``/usr/bin``, for example). And some methods of sharing a
-script (for example, publishing it on a text file sharing service like Github's
-gist, or a corporate intranet) may not allow for deriving the location of an
-associated requirements file from the script's location (tools like ``pipx``
-support running a script directly from a URL, so "download and unpack a zip of
-the script and its dependencies" may not be an appropriate requirement).
-
-Essentially, though, the issue here is that there is an explicitly stated
-requirement that the format supports storing dependency data *in the script
-file itself*. Solutions that don't do that are simply ignoring that
-requirement.
-
-Why not use (possibly restricted) Python syntax?
-------------------------------------------------
-
-This would typically involve storing metadata as multiple special variables,
-such as the following.
-
-.. code:: python
-
-    __requires_python__ = ">=3.11"
-    __dependencies__ = [
-        "requests",
-        "click",
-    ]
-
-The most significant problem with this proposal is that it requires all
-consumers of the dependency data to implement a Python parser. Even if the
-syntax is restricted, the *rest* of the script will use the full Python syntax,
-and trying to define a syntax which can be successfully parsed in isolation
-from the surrounding code is likely to be extremely difficult and error-prone.
-
-Furthermore, Python's syntax changes in every release. If extracting dependency
-data needs a Python parser, the parser will need to know which version of
-Python the script is written for, and the overhead for a generic tool of having
-a parser that can handle *multiple* versions of Python is unsustainable.
-
-With this approach there is the potential to clutter scripts with many
-variables as new extensions get added. Additionally, intuiting which metadata
-fields correspond to which variable names would cause confusion for users.
-
-It is worth noting, though, that the ``pip-run`` utility does implement (an
-extended form of) this approach. `Further discussion `_ of
-the ``pip-run`` design is available on the project's issue tracker.
-
-What about local dependencies?
-------------------------------
-
-These can be handled without needing special metadata and tooling, simply by
-adding the location of the dependencies to ``sys.path``. This PEP simply isn't
-needed for this case. If, on the other hand, the "local dependencies" are
-actual distributions which are published locally, they can be specified as
-usual with a :pep:`508` requirement, and the local package index specified when
-running a tool by using the tool's UI for that.
-
-Open Issues
-===========
-
-None at this point.
-
-
-References
-==========
-
-.. _pyproject metadata: https://packaging.python.org/en/latest/specifications/declaring-project-metadata/
-.. _pip-run issue: https://github.com/jaraco/pip-run/issues/44
-.. _pyproject without wheels: https://discuss.python.org/t/projects-that-arent-meant-to-generate-a-wheel-and-pyproject-toml/29684
-
-
-Footnotes
-=========
-
-.. [1] A large number of users use scripts that are version controlled. For
-   example, `the SREs that were mentioned <723-comment-block_>`_ or
-   projects that require special maintenance like the
-   `AWS CLI `__
-   or `Calibre `__.
-.. [2] The syntax is taken directly from the final resolution of the
-   `Blocks extension`__ to `Python Markdown`__.
-
-   __ https://github.com/facelessuser/pymdown-extensions/discussions/1973
-   __ https://github.com/Python-Markdown/markdown
-.. [3] A future PEP that officially introduces the ``[run]`` table to
-   ``pyproject.toml`` files will make this PEP not just similar but a strict
-   subset.
-.. [4] One important thing to note is that the metadata is embedded in a
-   `doc-comment`__ (their equivalent of docstrings). `Other syntaxes`__ are
-   under consideration within the Rust project.
-
-   __ https://doc.rust-lang.org/stable/book/ch14-02-publishing-to-crates-io.html#making-useful-documentation-comments
-   __ https://github.com/epage/cargo-script-mvs/blob/main/0000-cargo-script.md#embedded-manifest-format
-
-
-Copyright
-=========
+History
+=======
 
-This document is placed in the public domain or under the
-CC0-1.0-Universal license, whichever is more permissive.
+This specification was originally defined as :pep:`723`.

From 766b8b9390838f78c83c1582f0d138588d5f2b46 Mon Sep 17 00:00:00 2001
From: chrysle 
Date: Tue, 14 Nov 2023 16:43:16 +0100
Subject: [PATCH 0509/1072] Highlight regular package as opposite to namespace
 package

And shorten `[build-system]` table.

Co-authored-by: sinoroc <5529267+sinoroc@users.noreply.github.com>
---
 source/guides/packaging-namespace-packages.rst | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/source/guides/packaging-namespace-packages.rst b/source/guides/packaging-namespace-packages.rst
index e48ba873b..548020239 100644
--- a/source/guides/packaging-namespace-packages.rst
+++ b/source/guides/packaging-namespace-packages.rst
@@ -85,7 +85,7 @@ structure (following :ref:`src-layout `):
             mynamespace/ # namespace package
                 # No __init__.py here.
                 subpackage_a/
-                    # Sub-packages have an __init__.py.
+                    # Regular import packages have an __init__.py.
                     __init__.py
                     module.py
 
@@ -102,8 +102,7 @@ yourself, this is possible to be configured in the top-level :file:`pyproject.to
 .. code-block:: toml
 
     [build-system]
-    requires = ["setuptools", "setuptools-scm"]
-    build-backend = "setuptools.build_meta"
+    ...
 
     [tool.setuptools.packages.find]
     where = ["src/"]
@@ -188,7 +187,7 @@ To create a pkgutil-style namespace package, you need to provide an
             mynamespace/
                 __init__.py  # Namespace package __init__.py
                 subpackage_a/
-                    __init__.py  # Sub-package __init__.py
+                    __init__.py  # Regular package __init__.py
                     module.py
 
 The :file:`__init__.py` file for the namespace package needs to contain
@@ -235,7 +234,7 @@ To create a pkg_resources-style namespace package, you need to provide an
             mynamespace/
                 __init__.py  # Namespace package __init__.py
                 subpackage_a/
-                    __init__.py  # Sub-package __init__.py
+                    __init__.py  # Regular package __init__.py
                     module.py
 
 The :file:`__init__.py` file for the namespace package needs to contain

From 2a71cb9a6e8db17876c69d08281ca9dee6d4d184 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Tue, 14 Nov 2023 20:34:25 +0100
Subject: [PATCH 0510/1072] Expand pyproject.toml guide to also cover the
 [build-system] table

---
 source/guides/writing-pyproject-toml.rst | 103 +++++++++++++++++++----
 1 file changed, 87 insertions(+), 16 deletions(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index 3c3c741c9..0e1eeef55 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -4,27 +4,98 @@
 Writing your ``pyproject.toml``
 ===============================
 
-``pyproject.toml`` is a configuration file used by packaging tools. Most
-:term:`build backends ` [#poetry-special]_ allow you to specify
-your project's basic metadata, such as the dependencies, your name, etc.,
-in the ``[project]`` table of your ``pyproject.toml``.
+``pyproject.toml`` is a configuration file used by packaging tools, as
+well as other tools such as linters, type checkers, etc. There are
+three possible TOML tables in this file.
+
+- The ``[build-system]`` table is **strongly recommended**. It allows
+  you to declare which :term:`build backend` you use and which other
+  dependencies are needed to build your project.
+
+- The ``[project]`` table is the format that most build backends use to specify
+  your project's basic metadata, such as the dependencies, your name, etc.
+
+- The ``[tool]`` table has arbitrary subtables corresponding to tools, whether
+  packaging-related or not, e.g., ``[tool.hatch]``, ``[tool.black]``,
+  ``[tool.mypy]``. We only touch upon this table here because its contents are
+  entirely tool-specific. Consult each tool's documentation to know what it can
+  contain.
 
 .. note::
 
-   You may have heard of ``setup.py`` and ``setup.cfg`` for the setuptools_
-   build backend. For new projects, it is recommended to use ``pyproject.toml``
-   for basic metadata, and keep ``setup.py`` only if some programmatic configuration
-   is needed (especially building C extensions). However, putting basic project
-   metadata in ``setup.py`` or ``setup.cfg`` is still valid. See
+   There is a significant difference between the ``[build-system]`` and
+   ``[project]`` tables. The former should always be present, regardless of
+   which build backend you use (since it *defines* the tool you use). The latter
+   is understood by *most* build backends, but some build backends use a
+   different format.
+
+   At the time of this writing (November 2023), Poetry_ is a notable build
+   backend that does not use the ``[project]`` table (it uses the
+   ``[tool.poetry]`` table instead).
+
+   Also, the setuptools_ build backend supports both the ``[project]`` table,
+   and the older format in ``setup.cfg`` or ``setup.py``. For new projects, it
+   is recommended to use the ``[project]`` table, and keep ``setup.py`` only if
+   some programmatic configuration is needed (especially building C extensions),
+   but the ``setup.cfg`` and ``setup.py`` formats are still valid. See
    :ref:`setup-py-deprecated`.
 
 
+
+Declaring the build backend
+===========================
+
+The ``[build-system]`` table contains a ``build-backend`` key, which specifies
+the build backend to be used. It also contains a ``requires`` key, which is a
+list of dependencies needed to build the project -- this is typically just the
+build backend package, but it may also contain additional dependencies. You can
+also constrain the versions, e.g., ``requires = ["setuptools >= 61.0"]``.
+
+Usually, you'll just copy what your build backend's documentation suggests. Here
+are the values for some common build backends:
+
+.. tab:: Hatchling
+
+    .. code-block:: toml
+
+        [build-system]
+        requires = ["hatchling"]
+        build-backend = "hatchling.build"
+
+.. tab:: setuptools
+
+    .. code-block:: toml
+
+        [build-system]
+        requires = ["setuptools>=61.0"]
+        build-backend = "setuptools.build_meta"
+
+.. tab:: Flit
+
+    .. code-block:: toml
+
+        [build-system]
+        requires = ["flit_core>=3.4"]
+        build-backend = "flit_core.buildapi"
+
+.. tab:: PDM
+
+    .. code-block:: toml
+
+        [build-system]
+        requires = ["pdm-backend"]
+        build-backend = "pdm.backend"
+
+
+The rest of this guide is devoted to the ``[project]`` table.
+
+
 Static vs. dynamic metadata
 ===========================
 
-Most of the time, you will directly write the value of a field in
-``pyproject.toml``.  For example: ``requires-python = ">= 3.8"``, or
-``version = "1.0"``.
+Most of the time, you will directly write the value of a ``[project]``
+field. For example: ``requires-python = ">= 3.8"``, or ``version =
+"1.0"``.
 
 However, in some cases, it is useful to let your build backend compute
 the metadata for you. For example: many build backends can read the
@@ -316,6 +387,10 @@ A full example
 
 .. code-block:: toml
 
+   [build-system]
+   requires = ["hatchling"]
+   build-backend = "hatchling.build"
+
    [project]
    name = "spam-eggs"
    version = "2020.0.0"
@@ -370,10 +445,6 @@ A full example
 
 ------------------
 
-.. [#poetry-special] At the time of this writing (November 2023), Poetry_
-   is a notable exception.  It uses its own format for this metadata, in
-   the ``[tool.poetry]`` table.
-
 .. [#requires-python-upper-bounds] Think twice before applying an upper bound
    like ``requires-python = "<= 3.10"`` here. `This blog post `_
    contains some information regarding possible problems.

From 77c643c4d2be6ec26d4a88f260524ac67e64100b Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Tue, 14 Nov 2023 20:07:12 +0100
Subject: [PATCH 0511/1072] Link to pyproject.toml guide in "Packaging Python
 projects" tutorial

Replace links to the "Declaring project metadata" specification with
links to the "Writing pyproject.toml guide" since this is more likely
what the user wants after a tutorial. Also harmonize with the guide
slightly and leave link to version specifier specification (advanced
reading) for the guide.
---
 source/guides/writing-pyproject-toml.rst |  4 ++--
 source/tutorials/packaging-projects.rst  | 22 +++++++++++-----------
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index 3c3c741c9..22f232eda 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -28,8 +28,8 @@ Most of the time, you will directly write the value of a field in
 
 However, in some cases, it is useful to let your build backend compute
 the metadata for you. For example: many build backends can read the
-version from a ``__version__`` attribute in your code, or similar.
-In such cases, you should mark the field as dynamic using, e.g.,
+version from a ``__version__`` attribute in your code, a Git tag, or
+similar. In such cases, you should mark the field as dynamic using, e.g.,
 
 .. code-block:: toml
 
diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst
index 2678c97b9..8f4076bf4 100644
--- a/source/tutorials/packaging-projects.rst
+++ b/source/tutorials/packaging-projects.rst
@@ -214,17 +214,16 @@ following this tutorial.
     ]
 
     [project.urls]
-    "Homepage" = "https://github.com/pypa/sampleproject"
-    "Bug Tracker" = "https://github.com/pypa/sampleproject/issues"
+    Homepage = "https://github.com/pypa/sampleproject"
+    Issues = "https://github.com/pypa/sampleproject/issues"
 
 - ``name`` is the *distribution name* of your package. This can be any name as
   long as it only contains letters, numbers, ``.``, ``_`` , and ``-``. It also
   must not already be taken on PyPI. **Be sure to update this with your
   username** for this tutorial, as this ensures you won't try to upload a
   package with the same name as one which already exists.
-- ``version`` is the package version. See the :ref:`version specifier specification `
-  for more details on versions. Some build backends allow it to be specified
-  another way, such as from a file or a git tag.
+- ``version`` is the package version. (Some build backends allow it to be
+  specified another way, such as from a file or Git tag.)
 - ``authors`` is used to identify the author of the package; you specify a name
   and an email for each author. You can also list ``maintainers`` in the same
   format.
@@ -233,9 +232,9 @@ following this tutorial.
   package. This is shown on the package detail page on PyPI.
   In this case, the description is loaded from :file:`README.md` (which is a
   common pattern). There also is a more advanced table form described in the
-  :ref:`project metadata specification `.
+  :ref:`pyproject.toml guide `.
 - ``requires-python`` gives the versions of Python supported by your
-  project. Installers like :ref:`pip` will look back through older versions of
+  project. An installer like :ref:`pip` will look back through older versions of
   packages until it finds one that has a matching Python version.
 - ``classifiers`` gives the index and :ref:`pip` some additional metadata
   about your package. In this case, the package is only compatible with Python
@@ -247,10 +246,11 @@ following this tutorial.
 - ``urls`` lets you list any number of extra links to show on PyPI.
   Generally this could be to the source, documentation, issue trackers, etc.
 
-See the :ref:`project metadata specification ` for
-details on these and other fields that can be defined in the ``[project]``
-table. Other common fields are ``keywords`` to improve discoverability and the
-``dependencies`` that are required to install your package.
+See the :ref:`pyproject.toml guide ` for details
+on these and other fields that can be defined in the ``[project]``
+table. Other common fields are ``keywords`` to improve discoverability
+and the ``dependencies`` that are required to install your package.
+
 
 Creating README.md
 ------------------

From 7607fab1a42d3027206da4eec9ec5c37beef6058 Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Tue, 14 Nov 2023 21:29:28 +0100
Subject: [PATCH 0512/1072] Spaces around >=

Co-authored-by: chrysle 
---
 source/guides/writing-pyproject-toml.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index 0e1eeef55..6ec8a9d8c 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -67,7 +67,7 @@ are the values for some common build backends:
     .. code-block:: toml
 
         [build-system]
-        requires = ["setuptools>=61.0"]
+        requires = ["setuptools >= 61.0"]
         build-backend = "setuptools.build_meta"
 
 .. tab:: Flit
@@ -75,7 +75,7 @@ are the values for some common build backends:
     .. code-block:: toml
 
         [build-system]
-        requires = ["flit_core>=3.4"]
+        requires = ["flit_core >= 3.4"]
         build-backend = "flit_core.buildapi"
 
 .. tab:: PDM

From 4bbc74ccc26f8172d9626c3556a281c338d5bc6f Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Tue, 14 Nov 2023 20:45:55 +0100
Subject: [PATCH 0513/1072] Improve sidebar presentation in specifications
 section

---
 source/specifications/index.rst               | 49 ++-----------------
 .../section-distribution-formats.rst          |  8 +++
 .../section-distribution-metadata.rst         | 14 ++++++
 .../section-installation-metadata.rst         | 13 +++++
 .../section-package-indices.rst               |  8 +++
 5 files changed, 47 insertions(+), 45 deletions(-)
 create mode 100644 source/specifications/section-distribution-formats.rst
 create mode 100644 source/specifications/section-distribution-metadata.rst
 create mode 100644 source/specifications/section-installation-metadata.rst
 create mode 100644 source/specifications/section-package-indices.rst

diff --git a/source/specifications/index.rst b/source/specifications/index.rst
index fb1a1fee2..8f44e69bb 100644
--- a/source/specifications/index.rst
+++ b/source/specifications/index.rst
@@ -8,50 +8,9 @@ by the Python Packaging Authority. The process for updating these standards,
 and for proposing new ones, is documented on
 `pypa.io `__.
 
-
-Package Distribution Metadata
------------------------------
-
-.. toctree::
-   :maxdepth: 1
-
-   name-normalization
-   core-metadata
-   version-specifiers
-   dependency-specifiers
-   declaring-build-dependencies
-   declaring-project-metadata
-   inline-script-metadata
-   platform-compatibility-tags
-
-Package Installation Environment Metadata
------------------------------------------
-
-.. toctree::
-   :maxdepth: 1
-
-   recording-installed-packages
-   entry-points
-   direct-url
-   direct-url-data-structure
-   virtual-environments
-   externally-managed-environments
-
-Package Distribution File Formats
----------------------------------
-
-.. toctree::
-   :maxdepth: 1
-
-   source-distribution-format
-   binary-distribution-format
-
-
-Package Index Interfaces
-------------------------
-
 .. toctree::
-   :maxdepth: 1
 
-   pypirc
-   simple-repository-api
+   section-distribution-metadata
+   section-installation-metadata
+   section-distribution-formats
+   section-package-indices
diff --git a/source/specifications/section-distribution-formats.rst b/source/specifications/section-distribution-formats.rst
new file mode 100644
index 000000000..94256945d
--- /dev/null
+++ b/source/specifications/section-distribution-formats.rst
@@ -0,0 +1,8 @@
+=================================
+Package Distribution File Formats
+=================================
+
+.. toctree::
+
+   source-distribution-format
+   binary-distribution-format
diff --git a/source/specifications/section-distribution-metadata.rst b/source/specifications/section-distribution-metadata.rst
new file mode 100644
index 000000000..fe1e207f2
--- /dev/null
+++ b/source/specifications/section-distribution-metadata.rst
@@ -0,0 +1,14 @@
+=============================
+Package Distribution Metadata
+=============================
+
+.. toctree::
+
+   name-normalization
+   core-metadata
+   version-specifiers
+   dependency-specifiers
+   declaring-build-dependencies
+   declaring-project-metadata
+   inline-script-metadata
+   platform-compatibility-tags
diff --git a/source/specifications/section-installation-metadata.rst b/source/specifications/section-installation-metadata.rst
new file mode 100644
index 000000000..685a5aac4
--- /dev/null
+++ b/source/specifications/section-installation-metadata.rst
@@ -0,0 +1,13 @@
+=============================
+Package Installation Metadata
+=============================
+
+.. toctree::
+   :titlesonly:
+
+   recording-installed-packages
+   entry-points
+   direct-url
+   direct-url-data-structure
+   virtual-environments
+   externally-managed-environments
diff --git a/source/specifications/section-package-indices.rst b/source/specifications/section-package-indices.rst
new file mode 100644
index 000000000..9da3e30fe
--- /dev/null
+++ b/source/specifications/section-package-indices.rst
@@ -0,0 +1,8 @@
+========================
+Package Index Interfaces
+========================
+
+.. toctree::
+
+   pypirc
+   simple-repository-api

From 26d3fb9ed056deb62e912c720eb8b864fe0244b6 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Tue, 14 Nov 2023 21:37:24 +0100
Subject: [PATCH 0514/1072] Link to "Choosing a build backend"

---
 source/guides/writing-pyproject-toml.rst | 5 +++--
 source/tutorials/packaging-projects.rst  | 2 ++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index 6ec8a9d8c..ae2bdbc77 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -51,8 +51,9 @@ list of dependencies needed to build the project -- this is typically just the
 build backend package, but it may also contain additional dependencies. You can
 also constrain the versions, e.g., ``requires = ["setuptools >= 61.0"]``.
 
-Usually, you'll just copy what your build backend's documentation suggests. Here
-are the values for some common build backends:
+Usually, you'll just copy what your build backend's documentation
+suggests (after :ref:`choosing your build backend `).
+Here are the values for some common build backends:
 
 .. tab:: Hatchling
 
diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst
index 2678c97b9..1bc2f77ba 100644
--- a/source/tutorials/packaging-projects.rst
+++ b/source/tutorials/packaging-projects.rst
@@ -103,6 +103,8 @@ Creating a test directory
 :file:`tests/` is a placeholder for test files. Leave it empty for now.
 
 
+.. _choosing-build-backend:
+
 Choosing a build backend
 ------------------------
 

From d9203698145fb3f079327c2a51006d1e9f91afa5 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 8 Nov 2023 16:36:18 +0100
Subject: [PATCH 0515/1072] Move declaring-build-dependencies.rst verbatim into
 declaring-project-metadata.rst

---
 .../declaring-build-dependencies.rst          | 105 ------------------
 .../declaring-project-metadata.rst            | 104 +++++++++++++++++
 source/specifications/index.rst               |   1 -
 3 files changed, 104 insertions(+), 106 deletions(-)
 delete mode 100644 source/specifications/declaring-build-dependencies.rst

diff --git a/source/specifications/declaring-build-dependencies.rst b/source/specifications/declaring-build-dependencies.rst
deleted file mode 100644
index 1d8045eda..000000000
--- a/source/specifications/declaring-build-dependencies.rst
+++ /dev/null
@@ -1,105 +0,0 @@
-
-.. _declaring-build-dependencies:
-
-===================================
-Declaring build system dependencies
-===================================
-
-The ``pyproject.toml`` file is written in `TOML `_.
-Among other metadata (such as :ref:`project metadata `),
-it declares any Python level dependencies that must be installed in order to
-run the project's build system successfully.
-
-.. TODO: move this sentence elsewhere
-
-Tables not defined by PyPA specifications are reserved for future use.
-
-
-build-system table
-------------------
-
-.. TODO: merge with PEP 517
-
-The ``[build-system]`` table is used to store build-related data.
-Initially,  only one key of the table is valid and is mandatory
-for the table: ``requires``. This key must have a value of a list
-of strings representing dependencies required to execute the
-build system. The strings in this list follow the :ref:`version specifier
-specification `.
-
-An example ``build-system`` table for a project built with
-``setuptools`` is:
-
-.. code-block:: toml
-
-   [build-system]
-   # Minimum requirements for the build system to execute.
-   requires = ["setuptools"]
-
-Build tools are expected to use the example configuration file above as
-their default semantics when a ``pyproject.toml`` file is not present.
-
-Tools should not require the existence of the ``[build-system]`` table.
-A ``pyproject.toml`` file may be used to store configuration details
-other than build-related data and thus lack a ``[build-system]`` table
-legitimately. If the file exists but is lacking the ``[build-system]``
-table then the default values as specified above should be used.
-If the table is specified but is missing required fields then the tool
-should consider it an error.
-
-
-.. TODO: move elsewhere
-
-.. _pyproject-tool-table:
-
-tool table
-----------
-
-The ``[tool]`` table is where any tool related to your Python
-project, not just build tools, can have users specify configuration
-data as long as they use a sub-table within ``[tool]``, e.g. the
-`flit `_ tool would store its
-configuration in ``[tool.flit]``.
-
-A mechanism is needed to allocate names within the ``tool.*``
-namespace, to make sure that different projects do not attempt to use
-the same sub-table and collide. Our rule is that a project can use
-the subtable ``tool.$NAME`` if, and only if, they own the entry for
-``$NAME`` in the Cheeseshop/PyPI.
-
-JSON Schema
------------
-
-To provide a type-specific representation of the resulting data from
-the TOML file for illustrative purposes only, the following
-`JSON Schema `_ would match the data format:
-
-.. code-block:: json
-
-   {
-       "$schema": "http://json-schema.org/schema#",
-
-       "type": "object",
-       "additionalProperties": false,
-
-       "properties": {
-           "build-system": {
-               "type": "object",
-               "additionalProperties": false,
-
-               "properties": {
-                   "requires": {
-                       "type": "array",
-                       "items": {
-                           "type": "string"
-                       }
-                   }
-               },
-               "required": ["requires"]
-           },
-
-           "tool": {
-               "type": "object"
-           }
-       }
-   }
diff --git a/source/specifications/declaring-project-metadata.rst b/source/specifications/declaring-project-metadata.rst
index 0c1070b68..8d7186a46 100644
--- a/source/specifications/declaring-project-metadata.rst
+++ b/source/specifications/declaring-project-metadata.rst
@@ -16,6 +16,110 @@ specification as the canonical source for the format used.
    :ref:`writing-pyproject-toml`.
 
 
+.. _declaring-build-dependencies:
+
+===================================
+Declaring build system dependencies
+===================================
+
+The ``pyproject.toml`` file is written in `TOML `_.
+Among other metadata (such as :ref:`project metadata `),
+it declares any Python level dependencies that must be installed in order to
+run the project's build system successfully.
+
+.. TODO: move this sentence elsewhere
+
+Tables not defined by PyPA specifications are reserved for future use.
+
+build-system table
+------------------
+
+.. TODO: merge with PEP 517
+
+The ``[build-system]`` table is used to store build-related data.
+Initially,  only one key of the table is valid and is mandatory
+for the table: ``requires``. This key must have a value of a list
+of strings representing dependencies required to execute the
+build system. The strings in this list follow the :ref:`version specifier
+specification `.
+
+An example ``build-system`` table for a project built with
+``setuptools`` is:
+
+.. code-block:: toml
+
+   [build-system]
+   # Minimum requirements for the build system to execute.
+   requires = ["setuptools"]
+
+Build tools are expected to use the example configuration file above as
+their default semantics when a ``pyproject.toml`` file is not present.
+
+Tools should not require the existence of the ``[build-system]`` table.
+A ``pyproject.toml`` file may be used to store configuration details
+other than build-related data and thus lack a ``[build-system]`` table
+legitimately. If the file exists but is lacking the ``[build-system]``
+table then the default values as specified above should be used.
+If the table is specified but is missing required fields then the tool
+should consider it an error.
+
+
+.. TODO: move elsewhere
+
+.. _pyproject-tool-table:
+
+tool table
+----------
+
+The ``[tool]`` table is where any tool related to your Python
+project, not just build tools, can have users specify configuration
+data as long as they use a sub-table within ``[tool]``, e.g. the
+`flit `_ tool would store its
+configuration in ``[tool.flit]``.
+
+A mechanism is needed to allocate names within the ``tool.*``
+namespace, to make sure that different projects do not attempt to use
+the same sub-table and collide. Our rule is that a project can use
+the subtable ``tool.$NAME`` if, and only if, they own the entry for
+``$NAME`` in the Cheeseshop/PyPI.
+
+JSON Schema
+-----------
+
+To provide a type-specific representation of the resulting data from
+the TOML file for illustrative purposes only, the following
+`JSON Schema `_ would match the data format:
+
+.. code-block:: json
+
+   {
+       "$schema": "http://json-schema.org/schema#",
+
+       "type": "object",
+       "additionalProperties": false,
+
+       "properties": {
+           "build-system": {
+               "type": "object",
+               "additionalProperties": false,
+
+               "properties": {
+                   "requires": {
+                       "type": "array",
+                       "items": {
+                           "type": "string"
+                       }
+                   }
+               },
+               "required": ["requires"]
+           },
+
+           "tool": {
+               "type": "object"
+           }
+       }
+   }
+
 Specification
 =============
 
diff --git a/source/specifications/index.rst b/source/specifications/index.rst
index fb1a1fee2..a68dd11db 100644
--- a/source/specifications/index.rst
+++ b/source/specifications/index.rst
@@ -19,7 +19,6 @@ Package Distribution Metadata
    core-metadata
    version-specifiers
    dependency-specifiers
-   declaring-build-dependencies
    declaring-project-metadata
    inline-script-metadata
    platform-compatibility-tags

From 54cb4157d0f8d2f3d2ddf9f92b5f643caf0953c4 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Tue, 14 Nov 2023 22:06:56 +0100
Subject: [PATCH 0516/1072] Link to pyproject.toml guide (instead of
 specification) in packaging flow doc

---
 source/flow.rst | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/source/flow.rst b/source/flow.rst
index 974cfd6e9..947c399db 100644
--- a/source/flow.rst
+++ b/source/flow.rst
@@ -96,11 +96,13 @@ required in the :file:`pyproject.toml` file. For example, you might specify:
 
 * a ``[project]`` table containing project
   :doc:`Core Metadata `
-  (name, version, author and so forth); see
-  :doc:`Declaring project metadata `
-  for more detail
+  (name, version, author and so forth),
+
+* a ``[tool]`` table containing tool-specific configuration options.
+
+Refer to the :ref:`pyproject.toml guide ` for a
+complete guide to ``pyproject.toml`` configuration.
 
-* a ``[tool]`` table containing tool-specific configuration options
 
 Build artifacts
 ===============

From 39d6b779b58156fee3d194e41c96c2b217b46aee Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Tue, 14 Nov 2023 22:08:56 +0100
Subject: [PATCH 0517/1072] Rename "Declaring project metadata" to
 "pyproject.toml specification" to match new content

Adjust references accordingly.
---
 source/specifications/index.rst                           | 2 +-
 ...{declaring-project-metadata.rst => pyproject-toml.rst} | 8 ++++----
 source/specifications/source-distribution-format.rst      | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)
 rename source/specifications/{declaring-project-metadata.rst => pyproject-toml.rst} (99%)

diff --git a/source/specifications/index.rst b/source/specifications/index.rst
index a68dd11db..6e8af699e 100644
--- a/source/specifications/index.rst
+++ b/source/specifications/index.rst
@@ -19,9 +19,9 @@ Package Distribution Metadata
    core-metadata
    version-specifiers
    dependency-specifiers
-   declaring-project-metadata
    inline-script-metadata
    platform-compatibility-tags
+   pyproject-toml
 
 Package Installation Environment Metadata
 -----------------------------------------
diff --git a/source/specifications/declaring-project-metadata.rst b/source/specifications/pyproject-toml.rst
similarity index 99%
rename from source/specifications/declaring-project-metadata.rst
rename to source/specifications/pyproject-toml.rst
index 8d7186a46..2d6200ffb 100644
--- a/source/specifications/declaring-project-metadata.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -1,8 +1,8 @@
-.. _declaring-project-metadata:
+.. _pyproject-toml-spec:
 
-==========================
-Declaring project metadata
-==========================
+================================
+``pyproject.toml`` specification
+================================
 
 :pep:`621` specifies how to write a project's
 :ref:`core metadata ` in a ``pyproject.toml`` file for
diff --git a/source/specifications/source-distribution-format.rst b/source/specifications/source-distribution-format.rst
index 8ef55df96..55737dc07 100644
--- a/source/specifications/source-distribution-format.rst
+++ b/source/specifications/source-distribution-format.rst
@@ -58,7 +58,7 @@ A ``.tar.gz`` source distribution (sdist) contains a single top-level directory
 called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of
 the package. The name and version MUST match the metadata stored in the file.
 This directory must also contain a :file:`pyproject.toml` in the format defined in
-:ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing
+:ref:`pyproject-toml-spec`, and a ``PKG-INFO`` file containing
 metadata in the format described in the :ref:`core-metadata` specification. The
 metadata MUST conform to at least version 2.2 of the metadata specification.
 

From 66460e3661beb2128d7169f42e3b90b16524600c Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Tue, 14 Nov 2023 22:11:11 +0100
Subject: [PATCH 0518/1072] pyproject.toml spec: Update history and move to the
 end

---
 source/specifications/pyproject-toml.rst | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 2d6200ffb..7f9907a29 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -4,17 +4,14 @@
 ``pyproject.toml`` specification
 ================================
 
-:pep:`621` specifies how to write a project's
-:ref:`core metadata ` in a ``pyproject.toml`` file for
-packaging-related tools to consume. It defines the following
-specification as the canonical source for the format used.
-
 .. warning::
 
    This is a **technical, formal specification**. For a gentle,
    user-friendly guide to ``pyproject.toml``, see
    :ref:`writing-pyproject-toml`.
 
+The ``pyproject.toml`` file acts as a configuration file for packaging-related
+tools (as well as other tools).
 
 .. _declaring-build-dependencies:
 
@@ -444,4 +441,12 @@ provided via tooling later on.
 
 
 
+History
+=======
+
+This specification was originally defined in :pep:`518` (``[build-system]``
+and ``[tool]`` tables) and :pep:`621` (``[project]`` table).
+
+
+
 .. _TOML: https://toml.io

From 441d38e535a2e16e16b7b1293d5c5634e84ab27d Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Tue, 14 Nov 2023 22:16:03 +0100
Subject: [PATCH 0519/1072] pyproject.toml specification: Harmonize structure

Move the description of the tool table to its own section, and use
consistent titles and labels.
---
 source/specifications/pyproject-toml.rst | 59 +++++++++++-------------
 1 file changed, 28 insertions(+), 31 deletions(-)

diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 7f9907a29..03e617d97 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -13,11 +13,11 @@
 The ``pyproject.toml`` file acts as a configuration file for packaging-related
 tools (as well as other tools).
 
-.. _declaring-build-dependencies:
 
-===================================
-Declaring build system dependencies
-===================================
+.. _pyproject-build-system-table:
+
+Declaring build system dependencies: the ``[build-system]`` table
+=================================================================
 
 The ``pyproject.toml`` file is written in `TOML `_.
 Among other metadata (such as :ref:`project metadata `),
@@ -28,9 +28,6 @@ run the project's build system successfully.
 
 Tables not defined by PyPA specifications are reserved for future use.
 
-build-system table
-------------------
-
 .. TODO: merge with PEP 517
 
 The ``[build-system]`` table is used to store build-related data.
@@ -61,28 +58,6 @@ If the table is specified but is missing required fields then the tool
 should consider it an error.
 
 
-.. TODO: move elsewhere
-
-.. _pyproject-tool-table:
-
-tool table
-----------
-
-The ``[tool]`` table is where any tool related to your Python
-project, not just build tools, can have users specify configuration
-data as long as they use a sub-table within ``[tool]``, e.g. the
-`flit `_ tool would store its
-configuration in ``[tool.flit]``.
-
-A mechanism is needed to allocate names within the ``tool.*``
-namespace, to make sure that different projects do not attempt to use
-the same sub-table and collide. Our rule is that a project can use
-the subtable ``tool.$NAME`` if, and only if, they own the entry for
-``$NAME`` in the Cheeseshop/PyPI.
-
-JSON Schema
------------
-
 To provide a type-specific representation of the resulting data from
 the TOML file for illustrative purposes only, the following
 `JSON Schema `_ would match the data format:
@@ -117,8 +92,11 @@ the TOML file for illustrative purposes only, the following
        }
    }
 
-Specification
-=============
+
+.. _pyproject-project-table:
+
+Declaring project metadata: the ``[project]`` table
+===================================================
 
 There are two kinds of metadata: *static* and *dynamic*. Static
 metadata is specified in the ``pyproject.toml`` file directly and
@@ -441,6 +419,25 @@ provided via tooling later on.
 
 
 
+.. _pyproject-tool-table:
+
+Arbitrary tool configuration: the ``[tool]`` table
+==================================================
+
+The ``[tool]`` table is where any tool related to your Python
+project, not just build tools, can have users specify configuration
+data as long as they use a sub-table within ``[tool]``, e.g. the
+`flit `_ tool would store its
+configuration in ``[tool.flit]``.
+
+A mechanism is needed to allocate names within the ``tool.*``
+namespace, to make sure that different projects do not attempt to use
+the same sub-table and collide. Our rule is that a project can use
+the subtable ``tool.$NAME`` if, and only if, they own the entry for
+``$NAME`` in the Cheeseshop/PyPI.
+
+
+
 History
 =======
 

From d1a760af196df564fc943980823983ad130e8e1a Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Tue, 14 Nov 2023 22:20:16 +0100
Subject: [PATCH 0520/1072] pyproject.toml spec: Further harmonize

---
 source/specifications/pyproject-toml.rst | 27 +++++++++++-------------
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 03e617d97..d484ad040 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -13,20 +13,21 @@
 The ``pyproject.toml`` file acts as a configuration file for packaging-related
 tools (as well as other tools).
 
+The ``pyproject.toml`` file is written in `TOML `_. Three
+tables are currently specified, namely
+:ref:`[build-system] `,
+:ref:`[project] ` and
+:ref:`[tool] `. Other tables are reserved for future
+use (tool-specific configuration should use the ``[tool]`` table).
 
 .. _pyproject-build-system-table:
 
 Declaring build system dependencies: the ``[build-system]`` table
 =================================================================
 
-The ``pyproject.toml`` file is written in `TOML `_.
-Among other metadata (such as :ref:`project metadata `),
-it declares any Python level dependencies that must be installed in order to
-run the project's build system successfully.
-
-.. TODO: move this sentence elsewhere
-
-Tables not defined by PyPA specifications are reserved for future use.
+The ``[build-system]`` table declares any Python level dependencies that
+must be installed in order to run the project's build system
+successfully.
 
 .. TODO: merge with PEP 517
 
@@ -37,7 +38,7 @@ of strings representing dependencies required to execute the
 build system. The strings in this list follow the :ref:`version specifier
 specification `.
 
-An example ``build-system`` table for a project built with
+An example ``[build-system]`` table for a project built with
 ``setuptools`` is:
 
 .. code-block:: toml
@@ -98,6 +99,8 @@ the TOML file for illustrative purposes only, the following
 Declaring project metadata: the ``[project]`` table
 ===================================================
 
+The ``[project]`` table specifies the project's :ref:`core metadata `.
+
 There are two kinds of metadata: *static* and *dynamic*. Static
 metadata is specified in the ``pyproject.toml`` file directly and
 cannot be specified or changed by a tool (this includes data
@@ -106,12 +109,6 @@ by the metadata). Dynamic metadata is listed via the ``dynamic`` key
 (defined later in this specification) and represents metadata that a
 tool will later provide.
 
-The keys defined in this specification MUST be in a table named
-``[project]`` in ``pyproject.toml``. No tools may add keys to this
-table which are not defined by this specification. For tools wishing
-to store their own settings in ``pyproject.toml``, they may use the
-``[tool]`` table as defined in the
-:ref:`build dependency declaration specification `.
 The lack of a ``[project]`` table implicitly means the :term:`build backend `
 will dynamically provide all keys.
 

From 6513f06d2636c96f8275884da27d650c3e7d3125 Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Wed, 15 Nov 2023 11:53:41 +0100
Subject: [PATCH 0521/1072] Stray space

Co-authored-by: Carol Willing 
---
 source/specifications/pyproject-toml.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index d484ad040..91ad8e4ce 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -32,7 +32,7 @@ successfully.
 .. TODO: merge with PEP 517
 
 The ``[build-system]`` table is used to store build-related data.
-Initially,  only one key of the table is valid and is mandatory
+Initially, only one key of the table is valid and is mandatory
 for the table: ``requires``. This key must have a value of a list
 of strings representing dependencies required to execute the
 build system. The strings in this list follow the :ref:`version specifier

From d80aea34f16b560d12a7d1d5847a7d7fde14703d Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 15 Nov 2023 12:22:28 +0100
Subject: [PATCH 0522/1072] Address @willingc's review

---
 source/guides/writing-pyproject-toml.rst | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index ae2bdbc77..12fadd730 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -15,11 +15,10 @@ three possible TOML tables in this file.
 - The ``[project]`` table is the format that most build backends use to specify
   your project's basic metadata, such as the dependencies, your name, etc.
 
-- The ``[tool]`` table has arbitrary subtables corresponding to tools, whether
-  packaging-related or not, e.g., ``[tool.hatch]``, ``[tool.black]``,
-  ``[tool.mypy]``. We only touch upon this table here because its contents are
-  entirely tool-specific. Consult each tool's documentation to know what it can
-  contain.
+- The ``[tool]`` table has tool-specific subtables, e.g., ``[tool.hatch]``,
+  ``[tool.black]``, ``[tool.mypy]``. We only touch upon this table here because
+  its contents are defined by each tool. Consult the particular tool's
+  documentation to know what it can contain.
 
 .. note::
 
@@ -36,7 +35,7 @@ three possible TOML tables in this file.
    Also, the setuptools_ build backend supports both the ``[project]`` table,
    and the older format in ``setup.cfg`` or ``setup.py``. For new projects, it
    is recommended to use the ``[project]`` table, and keep ``setup.py`` only if
-   some programmatic configuration is needed (especially building C extensions),
+   some programmatic configuration is needed (such as building C extensions),
    but the ``setup.cfg`` and ``setup.py`` formats are still valid. See
    :ref:`setup-py-deprecated`.
 
@@ -88,12 +87,12 @@ Here are the values for some common build backends:
         build-backend = "pdm.backend"
 
 
-The rest of this guide is devoted to the ``[project]`` table.
-
 
 Static vs. dynamic metadata
 ===========================
 
+The rest of this guide is devoted to the ``[project]`` table.
+
 Most of the time, you will directly write the value of a ``[project]``
 field. For example: ``requires-python = ">= 3.8"``, or ``version =
 "1.0"``.

From 17eacbada0c5321fb3c3782f683b128b4e714d9c Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Thu, 16 Nov 2023 00:30:50 +0100
Subject: [PATCH 0523/1072] Add note about original PEPs

---
 source/specifications/pyproject-toml.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 91ad8e4ce..21cd2340d 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -13,6 +13,8 @@
 The ``pyproject.toml`` file acts as a configuration file for packaging-related
 tools (as well as other tools).
 
+.. note:: This specification was originally defined in :pep:`518` and :pep:`621`.
+
 The ``pyproject.toml`` file is written in `TOML `_. Three
 tables are currently specified, namely
 :ref:`[build-system] `,

From d475cf531d7dea0c0460d2cd4672728108900031 Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Thu, 16 Nov 2023 01:04:16 +0100
Subject: [PATCH 0524/1072] Add :titlesonly: option throughout

Co-authored-by: Pradyun Gedam 
---
 source/specifications/index.rst                         | 1 +
 source/specifications/section-distribution-formats.rst  | 1 +
 source/specifications/section-distribution-metadata.rst | 1 +
 source/specifications/section-package-indices.rst       | 1 +
 4 files changed, 4 insertions(+)

diff --git a/source/specifications/index.rst b/source/specifications/index.rst
index 8f44e69bb..c8d2a3bed 100644
--- a/source/specifications/index.rst
+++ b/source/specifications/index.rst
@@ -9,6 +9,7 @@ and for proposing new ones, is documented on
 `pypa.io `__.
 
 .. toctree::
+   :titlesonly:
 
    section-distribution-metadata
    section-installation-metadata
diff --git a/source/specifications/section-distribution-formats.rst b/source/specifications/section-distribution-formats.rst
index 94256945d..b2c09f8db 100644
--- a/source/specifications/section-distribution-formats.rst
+++ b/source/specifications/section-distribution-formats.rst
@@ -3,6 +3,7 @@ Package Distribution File Formats
 =================================
 
 .. toctree::
+   :titlesonly:
 
    source-distribution-format
    binary-distribution-format
diff --git a/source/specifications/section-distribution-metadata.rst b/source/specifications/section-distribution-metadata.rst
index fe1e207f2..585cbc511 100644
--- a/source/specifications/section-distribution-metadata.rst
+++ b/source/specifications/section-distribution-metadata.rst
@@ -3,6 +3,7 @@ Package Distribution Metadata
 =============================
 
 .. toctree::
+   :titlesonly:
 
    name-normalization
    core-metadata
diff --git a/source/specifications/section-package-indices.rst b/source/specifications/section-package-indices.rst
index 9da3e30fe..13ba98113 100644
--- a/source/specifications/section-package-indices.rst
+++ b/source/specifications/section-package-indices.rst
@@ -3,6 +3,7 @@ Package Index Interfaces
 ========================
 
 .. toctree::
+   :titlesonly:
 
    pypirc
    simple-repository-api

From 344da81ccacd0c7d7d12eb565db90e9ef968ec71 Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Thu, 16 Nov 2023 17:18:54 +0100
Subject: [PATCH 0525/1072] Be less formal

Co-authored-by: chrysle 
---
 source/guides/writing-pyproject-toml.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index 12fadd730..e0f02ddf2 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -28,7 +28,7 @@ three possible TOML tables in this file.
    is understood by *most* build backends, but some build backends use a
    different format.
 
-   At the time of this writing (November 2023), Poetry_ is a notable build
+   At the time of writing this (November 2023), Poetry_ is a notable build
    backend that does not use the ``[project]`` table (it uses the
    ``[tool.poetry]`` table instead).
 

From a3eeeef768b94dd65632e47cde6943a18723a22a Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Thu, 16 Nov 2023 10:12:28 -0800
Subject: [PATCH 0526/1072] Exclude precommit codespell check for translation
 po files

---
 .pre-commit-config.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index c7c9f234a..311332c8a 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -15,7 +15,7 @@ repos:
   rev: v2.2.6
   hooks:
   - id: codespell
-    args: ["-L", "ned,ist,oder"]
+    args: ["-L", "ned,ist,oder","--skip","*.po"]
 
 - repo: local
   hooks:

From 4d2191e3b35a68765f897ba05af070955b0a6f2b Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Thu, 16 Nov 2023 11:06:15 -0800
Subject: [PATCH 0527/1072] Add hugovk suggestions

Co-authored-by: Hugo van Kemenade 
---
 .pre-commit-config.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index 311332c8a..a181cd2c4 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -15,7 +15,7 @@ repos:
   rev: v2.2.6
   hooks:
   - id: codespell
-    args: ["-L", "ned,ist,oder","--skip","*.po"]
+    args: ["-L", "ned,ist,oder", "--skip", "*.po"]
 
 - repo: local
   hooks:

From d848d89f9ffbc11066553b2d5403545a77d0ab25 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Fri, 17 Nov 2023 20:06:47 +0100
Subject: [PATCH 0528/1072] Make the page an orphan stub instead of removing it

---
 source/guides/using-manifest-in.rst | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 source/guides/using-manifest-in.rst

diff --git a/source/guides/using-manifest-in.rst b/source/guides/using-manifest-in.rst
new file mode 100644
index 000000000..24bf154a1
--- /dev/null
+++ b/source/guides/using-manifest-in.rst
@@ -0,0 +1,9 @@
+: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.

From 381c6c435daf80230736415c078521804109d062 Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Fri, 17 Nov 2023 11:22:55 -0800
Subject: [PATCH 0529/1072] Ignore .po files for caps pre-commit hook

---
 .pre-commit-config.yaml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index a181cd2c4..c4a3ab93e 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -22,7 +22,7 @@ repos:
   - id: disallow-caps
     name: Disallow improper capitalization
     language: pygrep
-    entry: PyBind|Numpy|Cmake|CCache|Github|PyTest
+    entry: PyBind|Numpy|Cmake|CCache|Github|PyTest|*.po
     exclude: .pre-commit-config.yaml
 
 - repo: https://github.com/pre-commit/pygrep-hooks
@@ -33,7 +33,7 @@ repos:
   - id: rst-inline-touching-normal
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.1.5
+  rev: v0.1.6
   hooks:
     - id: ruff
     - id: ruff-format

From 5e883f5fc4a402fab7c79f2f4b0ab87d070efe68 Mon Sep 17 00:00:00 2001
From: Karl Knechtel 
Date: Fri, 17 Nov 2023 19:05:31 -0500
Subject: [PATCH 0530/1072] Inline doc link

The previous version resulted in a hover tooltip on the link stating
"(in virtualenv 0.1)". This comment makes little sense; virtualenv
is now at version 20.24.6, and at any rate the documentation should
be describing current versions.
---
 source/key_projects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index ea5730683..a66c4f3ff 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -333,7 +333,7 @@ it's fast and secure, it's maintained, and it reliably works.
 virtualenv
 ==========
 
-:doc:`Docs ` |
+`Docs `__ |
 `Issues `__ |
 `GitHub `__ |
 `PyPI `__

From e88199c214446afbd1aea0d6606f07169fd43fff Mon Sep 17 00:00:00 2001
From: Karl Knechtel 
Date: Fri, 17 Nov 2023 19:16:32 -0500
Subject: [PATCH 0531/1072] Clarify prose

This change clearly explains the role that the PATH environment variable
has in creating virtual environments using virtualenv, and contrasts
that behaviour with that of venv (which only uses the Python it was run
with).
---
 source/key_projects.rst | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index a66c4f3ff..9d6a68cfd 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -338,9 +338,10 @@ virtualenv
 `GitHub `__ |
 `PyPI `__
 
-virtualenv is a tool which uses the command-line path environment
-variable to create isolated Python :term:`Virtual Environments
-`, much as :ref:`venv` does. virtualenv provides
+virtualenv is a tool for creating isolated Python :term:`Virtual Environments
+`, like :ref:`venv`. Unlike :ref:`venv`, virtualenv can
+create virtual environments for other versions of Python, which it locates
+using the PATH environment variable. It also provides
 additional functionality, compared to :ref:`venv`, by supporting Python
 2.7 and by providing convenient features for configuring, maintaining,
 duplicating, and troubleshooting the virtual environments. For more

From 2af6a8762064fa9fd69595006418239225dd34bd Mon Sep 17 00:00:00 2001
From: Karl Knechtel 
Date: Fri, 17 Nov 2023 19:19:07 -0500
Subject: [PATCH 0532/1072] Remove redundancy and outdated information

Current versions of virtualenv do not in fact support Python 2.7 and
have not since (per my investigation) version 20.16, released more than
a year ago. At any rate it seems inappropriate to advertise 2.x support
as a feature this late in the game.

This edit also cleans up a redundant description of how virtualenv
"provides additional functionality... by providing convenient features",
and eliminates an apparently extraneous "the".
---
 source/key_projects.rst | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index 9d6a68cfd..4269e2da3 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -341,11 +341,9 @@ virtualenv
 virtualenv is a tool for creating isolated Python :term:`Virtual Environments
 `, like :ref:`venv`. Unlike :ref:`venv`, virtualenv can
 create virtual environments for other versions of Python, which it locates
-using the PATH environment variable. It also provides
-additional functionality, compared to :ref:`venv`, by supporting Python
-2.7 and by providing convenient features for configuring, maintaining,
-duplicating, and troubleshooting the virtual environments. For more
-information, see the section on :ref:`Creating and using Virtual
+using the PATH environment variable. It also provides convenient features for
+configuring, maintaining, duplicating, and troubleshooting virtual environments.
+For more information, see the section on :ref:`Creating and using Virtual
 Environments`.
 
 

From e15b7f489d868288f4d013e34ade99a952e1a5d2 Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Sat, 18 Nov 2023 12:15:13 -0800
Subject: [PATCH 0533/1072] exclude po file types

---
 .pre-commit-config.yaml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index c4a3ab93e..fcc1b0d0f 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -22,8 +22,9 @@ repos:
   - id: disallow-caps
     name: Disallow improper capitalization
     language: pygrep
-    entry: PyBind|Numpy|Cmake|CCache|Github|PyTest|*.po
+    entry: PyBind|Numpy|Cmake|CCache|Github|PyTest
     exclude: .pre-commit-config.yaml
+    exclude_types: ["pofile"]
 
 - repo: https://github.com/pre-commit/pygrep-hooks
   rev: v1.10.0

From b7fb8fca1d26fcef577d24b0d72048a2dca29e72 Mon Sep 17 00:00:00 2001
From: Hugo van Kemenade 
Date: Sun, 19 Nov 2023 12:12:34 +0200
Subject: [PATCH 0534/1072] Remove outdated distribute fork info

---
 source/key_projects.rst | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index 4269e2da3..7de8d9743 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -281,10 +281,6 @@ enhancements to the Python distutils that allow you to more easily
 build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages.
 
-`distribute`_ was a fork of setuptools that was merged back into setuptools (in
-v0.7), thereby making setuptools the primary choice for Python packaging.
-
-
 .. _trove-classifiers:
 
 trove-classifiers
@@ -742,6 +738,5 @@ information, see the section on :ref:`Creating and using Virtual Environments`.
 
 ----
 
-.. _distribute: https://pypi.org/project/distribute
 .. _Sphinx: https://www.sphinx-doc.org/en/master/
 .. _pytest: https://docs.pytest.org/en/stable/

From 3843f857e5d945b4741651020b81137a35187c6e Mon Sep 17 00:00:00 2001
From: Hugo van Kemenade 
Date: Sun, 19 Nov 2023 12:27:04 +0200
Subject: [PATCH 0535/1072] Setuptools capitalised at start of sentence/title

---
 source/key_projects.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index 7de8d9743..a1fda4601 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -268,7 +268,7 @@ display on PyPI.
 .. _setuptools:
 .. _easy_install:
 
-setuptools
+Setuptools
 ==========
 
 `Docs `__ |
@@ -276,7 +276,7 @@ setuptools
 `GitHub `__ |
 `PyPI `__
 
-setuptools (which includes ``easy_install``) is a collection of
+Setuptools (which includes ``easy_install``) is a collection of
 enhancements to the Python distutils that allow you to more easily
 build and distribute Python :term:`distributions `, especially ones that have dependencies on other packages.

From 47b9fa541dc239ba0cbbb809bb3bfbd1e4000dc5 Mon Sep 17 00:00:00 2001
From: Hugo van Kemenade 
Date: Sun, 19 Nov 2023 12:33:19 +0200
Subject: [PATCH 0536/1072] Proofread 'How to modernize a setup.py based
 project'

---
 source/guides/modernize-setup-py-project.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/source/guides/modernize-setup-py-project.rst b/source/guides/modernize-setup-py-project.rst
index 1ecd4d6ff..98f0d78c0 100644
--- a/source/guides/modernize-setup-py-project.rst
+++ b/source/guides/modernize-setup-py-project.rst
@@ -13,7 +13,7 @@ A :term:`pyproject.toml` file is strongly recommended.
 The presence of a :file:`pyproject.toml` file itself does not bring much. [#]_
 What is actually strongly recommended is the ``[build-system]`` table in :file:`pyproject.toml`.
 
-.. [#] Note that it has influence on the build isolation feature of *pip*,
+.. [#] Note that it has influence on the build isolation feature of pip,
     see below.
 
 
@@ -24,10 +24,10 @@ No, :file:`setup.py` can exist in a modern :ref:`setuptools` based project.
 The :term:`setup.py` file is a valid configuration file for setuptools
 that happens to be written in Python.
 However, the following commands are deprecated and **MUST NOT** be run anymore,
-and their recommended replacement commands can be used instead:
+and their recommended replacement commands should be used instead:
 
 +---------------------------------+----------------------------------------+
-| Deprecated                      | Current recommendation                 |
+| Deprecated                      | Recommendation                         |
 +=================================+========================================+
 | ``python setup.py install``     | ``python -m pip install .``            |
 +---------------------------------+----------------------------------------+
@@ -118,7 +118,7 @@ What is the build isolation feature?
 
 Build frontends typically create an ephemeral virtual environment
 where they install only the build dependencies (and their dependencies)
-that are listed under ``build-sytem.requires``
+that are listed under ``build-system.requires``
 and trigger the build in that environment.
 
 For some projects this isolation is unwanted and it can be deactivated as follows:

From e5048ad200f2c5fa6ce99bfd5c19923597e92e52 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 20 Nov 2023 18:21:34 +0000
Subject: [PATCH 0537/1072] [pre-commit.ci] pre-commit autoupdate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

updates:
- [github.com/astral-sh/ruff-pre-commit: v0.1.5 → v0.1.6](https://github.com/astral-sh/ruff-pre-commit/compare/v0.1.5...v0.1.6)
---
 .pre-commit-config.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index a181cd2c4..41f45cdb7 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -33,7 +33,7 @@ repos:
   - id: rst-inline-touching-normal
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.1.5
+  rev: v0.1.6
   hooks:
     - id: ruff
     - id: ruff-format

From 4e8769a87df9bb5c2b09e7d5b37f33365d6f5c72 Mon Sep 17 00:00:00 2001
From: wyattscarpenter 
Date: Mon, 20 Nov 2023 17:53:30 -0800
Subject: [PATCH 0538/1072] verbiage tweak in
 installing-using-pip-and-virtual-environments.rst

---
 .../installing-using-pip-and-virtual-environments.rst     | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst
index 2f6b154bc..4743e773a 100644
--- a/source/guides/installing-using-pip-and-virtual-environments.rst
+++ b/source/guides/installing-using-pip-and-virtual-environments.rst
@@ -104,20 +104,20 @@ Python interpreter:
 
         where python
 
-When the virtual environment is activated, the location will include
-the ``.venv`` directory:
+While the virtual environment is active, the above command will output a
+filepath that includes the ``.venv`` directory, by ending with the following:
 
 .. tab:: Unix/macOS
 
     .. code-block:: bash
 
-        .../.venv/bin/python
+        .venv/bin/python
 
 .. tab:: Windows
 
     .. code-block:: bat
 
-        ...\.venv\bin\python.exe
+        .venv\bin\python.exe
 
 
 While a virtual environment is activated, pip will install packages into that

From b200a38badc8ad478e76b646d14a21c3f8287ba6 Mon Sep 17 00:00:00 2001
From: sinoroc 
Date: Sun, 26 Nov 2023 11:45:19 +0100
Subject: [PATCH 0539/1072] Improve discussion "Is `setup.py` deprecated?"

Add alternative solutions for more commands.

GitHub: relates to https://github.com/pypa/packaging.python.org/pull/1415
---
 source/discussions/setup-py-deprecated.rst | 85 ++++++++++++++++++++--
 1 file changed, 78 insertions(+), 7 deletions(-)

diff --git a/source/discussions/setup-py-deprecated.rst b/source/discussions/setup-py-deprecated.rst
index 25bba70a9..01339595a 100644
--- a/source/discussions/setup-py-deprecated.rst
+++ b/source/discussions/setup-py-deprecated.rst
@@ -5,18 +5,20 @@
 Is ``setup.py`` deprecated?
 ===========================
 
-No, :term:`setup.py` is not deprecated,
-it is a valid configuration file for :ref:`setuptools`
+No, :term:`setup.py` and :ref:`setuptools` are not deprecated.
+
+Setuptools is perfectly usable as a :term:`build backend`
+for packaging Python projects.
+And :file:`setup.py` is a valid configuration file for :ref:`setuptools`
 that happens to be written in Python, instead of in *TOML* for example
 (a similar practice is used by other tools
 like *nox* and its :file:`nox.py` configuration file,
 or *pytest* and :file:`conftest.py`).
 
-And of course *setuptools* itself is not deprecated either.
-
-It is however deprecated to run ``python setup.py`` as a command line tool.
+However, ``python setup.py`` and the use of :file:`setup.py`
+as a command line tool are deprecated.
 
-This means for example that the following commands **MUST NOT** be run anymore:
+This means that commands such as the following **MUST NOT** be run anymore:
 
 * ``python setup.py install``
 * ``python setup.py develop``
@@ -28,7 +30,7 @@ What commands should be used instead?
 =====================================
 
 +---------------------------------+----------------------------------------+
-| Deprecated                      | Current recommendation                 |
+| Deprecated                      | Recommendation                         |
 +=================================+========================================+
 | ``python setup.py install``     | ``python -m pip install .``            |
 +---------------------------------+----------------------------------------+
@@ -79,6 +81,75 @@ The command ``python setup.py install`` was deprecated
 in setuptools version *58.3.0*.
 
 
+What about other commands?
+==========================
+
+What are some replacements for the other ``python setup.py`` commands?
+
+
+``python setup.py test``
+------------------------
+
+The recommendation is to use a test runner such as pytest_.
+
+.. _pytest: https://docs.pytest.org/
+
+
+``python setup.py check``, ``python setup.py register``, and ``python setup.py upload``
+---------------------------------------------------------------------------------------
+
+A trusted replacement is :ref:`twine`:
+
+* ``python -m twine check``
+* ``python -m twine register``
+* ``python -m twine upload``
+
+
+``python setup.py --version``
+-----------------------------
+
+A possible replacement solution (among others) is to rely on setuptools-scm_:
+
+* ``python -m setuptools-scm``
+
+.. _setuptools-scm: https://setuptools-scm.readthedocs.io/en/latest/usage/#as-cli-tool
+
+
+Remaining commands
+------------------
+
+This guide does not make suggestions of replacement solutions for those commands:
+
+.. hlist::
+    :columns: 4
+
+    * ``alias``
+    * ``bdist``
+    * ``bdist_dumb``
+    * ``bdist_egg``
+    * ``bdist_rpm``
+    * ``build``
+    * ``build_clib``
+    * ``build_ext``
+    * ``build_py``
+    * ``build_scripts``
+    * ``clean``
+    * ``dist_info``
+    * ``easy_install``
+    * ``editable_wheel``
+    * ``egg_info``
+    * ``install``
+    * ``install_data``
+    * ``install_egg_info``
+    * ``install_headers``
+    * ``install_lib``
+    * ``install_scripts``
+    * ``rotate``
+    * ``saveopts``
+    * ``setopt``
+    * ``upload_docs``
+
+
 What about custom commands?
 ===========================
 

From e338def2791e1092050e75552c911af6f571bbe7 Mon Sep 17 00:00:00 2001
From: Eric Larson 
Date: Thu, 30 Nov 2023 11:33:31 -0500
Subject: [PATCH 0540/1072] DOC: Document RECORD modification

---
 source/specifications/recording-installed-packages.rst | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/source/specifications/recording-installed-packages.rst b/source/specifications/recording-installed-packages.rst
index 2610717d6..cbe0f0dbe 100644
--- a/source/specifications/recording-installed-packages.rst
+++ b/source/specifications/recording-installed-packages.rst
@@ -175,6 +175,14 @@ attempt to uninstall or upgrade the package.
 (This restriction does not apply to tools that rely on other sources of information,
 such as system package managers in Linux distros.)
 
+.. warning::
+
+   If your package dynamically generates files at runtime, you will need to update
+   the ``RECORD`` file to reflect the new files. If you do not, the files will be
+   retained during uninstallation (e.g., by ``pip uninstall my_package``) likely leading
+   to issues such as the package remaining importable but errantly appearing as a
+   namespace package. See :gh:`pypa/pip/issues/11835` for discussion.
+
 
 The INSTALLER file
 ==================

From 3518185b813b405a1a4d654a54bd2797092666bf Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Fri, 1 Dec 2023 11:08:57 +0100
Subject: [PATCH 0541/1072] Add discussion "Distribution package vs. import
 package"

Resolves #1425
---
 ...distribution-package-vs-import-package.rst | 90 +++++++++++++++++++
 source/discussions/index.rst                  |  1 +
 source/glossary.rst                           |  6 +-
 .../guides/packaging-namespace-packages.rst   |  2 +
 4 files changed, 97 insertions(+), 2 deletions(-)
 create mode 100644 source/discussions/distribution-package-vs-import-package.rst

diff --git a/source/discussions/distribution-package-vs-import-package.rst b/source/discussions/distribution-package-vs-import-package.rst
new file mode 100644
index 000000000..9ec708624
--- /dev/null
+++ b/source/discussions/distribution-package-vs-import-package.rst
@@ -0,0 +1,90 @@
+.. _distribution-package-vs-import-package:
+
+=======================================
+Distribution package vs. import package
+=======================================
+
+A number of different concepts are commonly referred to by the word
+"package". This page clarifies the differences between two distinct but
+related meanings in Python packaging, "distribution package" and "import
+package".
+
+What's a distribution package?
+==============================
+
+A distribution package is a piece of software that you can install.
+Most of the time, this is synonymous with "project". When you type ``pip
+install pkg``, or when you write ``dependencies = ["pkg"]`` in your
+``pyproject.toml``, ``pkg`` is the name of a distribution package. When
+you search or browse PyPI_, the most widely known centralized source for
+installing Python software, what you see is a list of distribution
+packages. Alternatively, the term "distribution package" can be used to
+refer to a specific file that contains a certain version of a project.
+
+Note that in the Linux world, "distribution package" refers to a package
+provided by the system package manager, which is a different meaning.
+
+
+What's an import package?
+=========================
+
+An import package is a Python module. Thus, when you write ``import
+pkg`` or ``from pkg import func`` in your Python code, ``pkg`` is the
+name of an import package. More precisely, import packages are special
+Python modules that can contain submodules. For example, the ``numpy``
+package contains modules like ``numpy.linalg`` and
+``numpy.fft``. Usually, an import package is a directory on the file
+system, containing modules as ``.py`` files and subpackages as
+subdirectories.
+
+You can use an import package as soon as you have installed a distribution
+package that provides it.
+
+
+What are the links between distribution packages and import packages?
+=====================================================================
+
+By convention, a distribution package usually provides one single import
+package (or non-package module), with a matching name. For example,
+``pip install numpy`` lets you ``import numpy``.
+
+However, this is only a convention. PyPI and other package indices do
+not enforce any relationship between the name of a distribution package
+and the import packages it provides.
+
+A distribution package could provide an import package with a different
+name. An example of this is the popular Pillow_ library for image
+processing. Its distribution package name is ``Pillow``, but it provides
+the import package ``PIL``. This is for historical reasons: Pillow
+started as a fork of the PIL library, thus it kept the import name
+``PIL`` so that existing PIL users could switch to Pillow with little
+effort. More generally, a fork of an existing library is a common reason
+for differing names between the distribution package and the import
+package.
+
+On a given package index (like PyPI), distribution package names must be
+unique. On the other hand, import packages have no such requirement.
+Import packages with the same name can be provided by several
+distribution packages. Again, forks are a common reason for this.
+
+Conversely, a distribution package can provide several import packages,
+although this is less common.
+
+
+How do distribution package names and import package names compare?
+===================================================================
+
+Import packages should have valid Python identifiers as their name.  In
+particular, they use underscores ``_`` as word separator and they are
+case-sensitive.
+
+On the other hand, distribution packages can use hyphens ``-`` or
+underscores ``.``. They can also contain dots ``.``, which is sometimes
+used for packaging a subpackage of a :ref:`namespace package
+`. For most purposes, they are insensitive
+to case and to ``-`` vs.  ``_`` differences, e.g., ``pip install
+Awesome_Package`` is the same as ``pip install awesome-package``.
+
+
+.. _PyPI: https://pypi.org
+.. _Pillow: https://pypi.org/project/Pillow
diff --git a/source/discussions/index.rst b/source/discussions/index.rst
index e5411ece3..b378ed810 100644
--- a/source/discussions/index.rst
+++ b/source/discussions/index.rst
@@ -12,5 +12,6 @@ specific topic. If you're just trying to get stuff done, see
    pip-vs-easy-install
    install-requires-vs-requirements
    wheel-vs-egg
+   distribution-package-vs-import-package
    src-layout-vs-flat-layout
    setup-py-deprecated
diff --git a/source/glossary.rst b/source/glossary.rst
index f9f2abc29..9bfcbbd3f 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -67,7 +67,8 @@ Glossary
         :term:`Import Package` (which is also commonly called a "package") or
         another kind of distribution (e.g. a Linux distribution or the Python
         language distribution), which are often referred to with the single term
-        "distribution".
+        "distribution". See :ref:`distribution-package-vs-import-package`
+        for a breakdown of the differences.
 
     Egg
 
@@ -103,7 +104,8 @@ Glossary
         An import package is more commonly referred to with the single word
         "package", but this guide will use the expanded term when more clarity
         is needed to prevent confusion with a :term:`Distribution Package` which
-        is also commonly called a "package".
+        is also commonly called a "package". See :ref:`distribution-package-vs-import-package`
+        for a breakdown of the differences.
 
     Module
 
diff --git a/source/guides/packaging-namespace-packages.rst b/source/guides/packaging-namespace-packages.rst
index 548020239..3d929d527 100644
--- a/source/guides/packaging-namespace-packages.rst
+++ b/source/guides/packaging-namespace-packages.rst
@@ -1,3 +1,5 @@
+.. _packaging-namespace-packages:
+
 ============================
 Packaging namespace packages
 ============================

From 176f95637e0a0a1d4574da25e75fe135d95da9e7 Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Fri, 1 Dec 2023 16:22:02 +0100
Subject: [PATCH 0542/1072] Update
 source/discussions/distribution-package-vs-import-package.rst

Co-authored-by: sinoroc <5529267+sinoroc@users.noreply.github.com>
---
 source/discussions/distribution-package-vs-import-package.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/distribution-package-vs-import-package.rst b/source/discussions/distribution-package-vs-import-package.rst
index 9ec708624..c54bcb523 100644
--- a/source/discussions/distribution-package-vs-import-package.rst
+++ b/source/discussions/distribution-package-vs-import-package.rst
@@ -79,7 +79,7 @@ particular, they use underscores ``_`` as word separator and they are
 case-sensitive.
 
 On the other hand, distribution packages can use hyphens ``-`` or
-underscores ``.``. They can also contain dots ``.``, which is sometimes
+underscores ``_``. They can also contain dots ``.``, which is sometimes
 used for packaging a subpackage of a :ref:`namespace package
 `. For most purposes, they are insensitive
 to case and to ``-`` vs.  ``_`` differences, e.g., ``pip install

From 790e7cf6674c9761d204a2930673c0a1418efb8b Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Fri, 1 Dec 2023 16:26:51 +0100
Subject: [PATCH 0543/1072] Update
 source/discussions/distribution-package-vs-import-package.rst

---
 source/discussions/distribution-package-vs-import-package.rst | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/source/discussions/distribution-package-vs-import-package.rst b/source/discussions/distribution-package-vs-import-package.rst
index c54bcb523..129eec926 100644
--- a/source/discussions/distribution-package-vs-import-package.rst
+++ b/source/discussions/distribution-package-vs-import-package.rst
@@ -83,7 +83,9 @@ underscores ``_``. They can also contain dots ``.``, which is sometimes
 used for packaging a subpackage of a :ref:`namespace package
 `. For most purposes, they are insensitive
 to case and to ``-`` vs.  ``_`` differences, e.g., ``pip install
-Awesome_Package`` is the same as ``pip install awesome-package``.
+Awesome_Package`` is the same as ``pip install awesome-package`` (the precise rules
+are given in the :ref:`name normalization
+specification `).
 
 
 .. _PyPI: https://pypi.org

From 6d8be6882828599d3dbc83dcec501ebbda72a40e Mon Sep 17 00:00:00 2001
From: Eric Larson 
Date: Fri, 1 Dec 2023 13:43:42 -0500
Subject: [PATCH 0544/1072] DOC: Discourage

---
 .../recording-installed-packages.rst              | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/source/specifications/recording-installed-packages.rst b/source/specifications/recording-installed-packages.rst
index cbe0f0dbe..53ba6b2b9 100644
--- a/source/specifications/recording-installed-packages.rst
+++ b/source/specifications/recording-installed-packages.rst
@@ -175,14 +175,15 @@ attempt to uninstall or upgrade the package.
 (This restriction does not apply to tools that rely on other sources of information,
 such as system package managers in Linux distros.)
 
-.. warning::
-
-   If your package dynamically generates files at runtime, you will need to update
-   the ``RECORD`` file to reflect the new files. If you do not, the files will be
-   retained during uninstallation (e.g., by ``pip uninstall my_package``) likely leading
-   to issues such as the package remaining importable but errantly appearing as a
-   namespace package. See :gh:`pypa/pip/issues/11835` for discussion.
+.. note::
 
+   It is *strongly discouraged* for an installed package to modify itself
+   (e.g., store cache files under its namespace in ``site-packages``).
+   Changes inside ``site-packages`` should be left to specialized installer
+   tools such as pip. If a package is nevertheless modified in this way,
+   then the ``RECORD`` must be updated, otherwise uninstalling the package
+   will leave unlisted files in place (possibly resulting in a zombie
+   namespace package).
 
 The INSTALLER file
 ==================

From e8c91cf4b8a99b6e10d1252fdc7aa8aeee45f146 Mon Sep 17 00:00:00 2001
From: Laurent Lyaudet 
Date: Sun, 3 Dec 2023 14:06:50 +0100
Subject: [PATCH 0545/1072] LL : correction of two code-blocks python -> pycon
 after suggestion from #1424 and command `grep -r 'code-block:: python' -A 3
 .`.

---
 source/tutorials/installing-packages.rst | 2 +-
 source/tutorials/packaging-projects.rst  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst
index fc4218980..cb995103b 100644
--- a/source/tutorials/installing-packages.rst
+++ b/source/tutorials/installing-packages.rst
@@ -52,7 +52,7 @@ please install the latest 3.x version from `python.org`_ or refer to the
 
 .. Note:: If you're a newcomer and you get an error like this:
 
-    .. code-block:: python
+    .. code-block:: pycon
 
         >>> python3 --version
         Traceback (most recent call last):
diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst
index 23742c7d8..8d13d7b69 100644
--- a/source/tutorials/packaging-projects.rst
+++ b/source/tutorials/packaging-projects.rst
@@ -493,7 +493,7 @@ Make sure you're still in your virtual environment, then run Python:
 
 and import the package:
 
-.. code-block:: python
+.. code-block:: pycon
 
     >>> from example_package_YOUR_USERNAME_HERE import example
     >>> example.add_one(2)

From e58cfbd9b9345de05f9ec1676571eaa2c437900c Mon Sep 17 00:00:00 2001
From: sinoroc 
Date: Sun, 3 Dec 2023 17:02:33 +0100
Subject: [PATCH 0546/1072] Fix bits of "Is `setup.py` deprecated?" discussion

GitHub: refs https://github.com/pypa/packaging.python.org/pull/1418
---
 source/discussions/setup-py-deprecated.rst | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/source/discussions/setup-py-deprecated.rst b/source/discussions/setup-py-deprecated.rst
index 01339595a..279e4abce 100644
--- a/source/discussions/setup-py-deprecated.rst
+++ b/source/discussions/setup-py-deprecated.rst
@@ -100,9 +100,12 @@ The recommendation is to use a test runner such as pytest_.
 
 A trusted replacement is :ref:`twine`:
 
-* ``python -m twine check``
-* ``python -m twine register``
-* ``python -m twine upload``
+* ``python -m twine check --strict dist/*``
+* ``python -m twine register dist/*.whl`` [#not-pypi]_
+* ``python -m twine upload dist/*``
+
+.. [#not-pypi] Not necessary, nor supported on :term:`PyPI `.
+    But might be necessary on other :term:`package indexes `.
 
 
 ``python setup.py --version``
@@ -110,7 +113,7 @@ A trusted replacement is :ref:`twine`:
 
 A possible replacement solution (among others) is to rely on setuptools-scm_:
 
-* ``python -m setuptools-scm``
+* ``python -m setuptools_scm``
 
 .. _setuptools-scm: https://setuptools-scm.readthedocs.io/en/latest/usage/#as-cli-tool
 

From fe9378a1935acf57149a7dd1d6c9137192939a8f Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sun, 3 Dec 2023 17:24:59 +0100
Subject: [PATCH 0547/1072] Mention attrs as a distribution package which
 provides several import packages

---
 .../discussions/distribution-package-vs-import-package.rst   | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/source/discussions/distribution-package-vs-import-package.rst b/source/discussions/distribution-package-vs-import-package.rst
index 129eec926..09f61668a 100644
--- a/source/discussions/distribution-package-vs-import-package.rst
+++ b/source/discussions/distribution-package-vs-import-package.rst
@@ -68,7 +68,9 @@ Import packages with the same name can be provided by several
 distribution packages. Again, forks are a common reason for this.
 
 Conversely, a distribution package can provide several import packages,
-although this is less common.
+although this is less common. An example is the attrs_ distribution
+package, which provides both an ``attrs`` import package with a newer
+API, and an ``attr`` import package with an older but supported API.
 
 
 How do distribution package names and import package names compare?
@@ -90,3 +92,4 @@ specification `).
 
 .. _PyPI: https://pypi.org
 .. _Pillow: https://pypi.org/project/Pillow
+.. _attrs: https://pypi.org/project/attrs

From 92380eca023d5fe22f5404b022b28eb3eb224713 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sun, 3 Dec 2023 17:25:20 +0100
Subject: [PATCH 0548/1072] Link to Python docs for exact rules on valid
 identifiers

---
 .../discussions/distribution-package-vs-import-package.rst | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/source/discussions/distribution-package-vs-import-package.rst b/source/discussions/distribution-package-vs-import-package.rst
index 09f61668a..f10dced75 100644
--- a/source/discussions/distribution-package-vs-import-package.rst
+++ b/source/discussions/distribution-package-vs-import-package.rst
@@ -76,9 +76,10 @@ API, and an ``attr`` import package with an older but supported API.
 How do distribution package names and import package names compare?
 ===================================================================
 
-Import packages should have valid Python identifiers as their name.  In
-particular, they use underscores ``_`` as word separator and they are
-case-sensitive.
+Import packages should have valid Python identifiers as their name (the
+:ref:`exact rules ` are found in the Python
+documentation). In particular, they use underscores ``_`` as word
+separator and they are case-sensitive.
 
 On the other hand, distribution packages can use hyphens ``-`` or
 underscores ``_``. They can also contain dots ``.``, which is sometimes

From a7592e8aa6b4e619a80352bfbb19ba2334f74773 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sun, 3 Dec 2023 17:37:06 +0100
Subject: [PATCH 0549/1072] Rewrap

---
 .../discussions/distribution-package-vs-import-package.rst  | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/source/discussions/distribution-package-vs-import-package.rst b/source/discussions/distribution-package-vs-import-package.rst
index f10dced75..967328620 100644
--- a/source/discussions/distribution-package-vs-import-package.rst
+++ b/source/discussions/distribution-package-vs-import-package.rst
@@ -86,9 +86,9 @@ underscores ``_``. They can also contain dots ``.``, which is sometimes
 used for packaging a subpackage of a :ref:`namespace package
 `. For most purposes, they are insensitive
 to case and to ``-`` vs.  ``_`` differences, e.g., ``pip install
-Awesome_Package`` is the same as ``pip install awesome-package`` (the precise rules
-are given in the :ref:`name normalization
-specification `).
+Awesome_Package`` is the same as ``pip install awesome-package`` (the
+precise rules are given in the :ref:`name normalization specification
+`).
 
 
 .. _PyPI: https://pypi.org

From d7fda402dc3e8b96cb679c9f7b4bf8ef32823de3 Mon Sep 17 00:00:00 2001
From: Rafael Fontenelle 
Date: Sun, 3 Dec 2023 17:16:26 -0300
Subject: [PATCH 0550/1072] Create test-translations.yml

---
 .github/workflows/test-translations.yml | 71 +++++++++++++++++++++++++
 1 file changed, 71 insertions(+)
 create mode 100644 .github/workflows/test-translations.yml

diff --git a/.github/workflows/test-translations.yml b/.github/workflows/test-translations.yml
new file mode 100644
index 000000000..03df0ee70
--- /dev/null
+++ b/.github/workflows/test-translations.yml
@@ -0,0 +1,71 @@
+name: Test translations
+
+on:
+  workflow_dispatch:
+  pull_request:
+    paths:
+    - '**.po'
+    branches:
+    - translation/source
+  push:
+    paths:
+    - '**.po'
+    branches:
+    - translation/source
+
+permissions:
+  contents: read
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.sha }}
+  cancel-in-progress: true
+
+env:
+  I18N_BRANCH: translation/source
+
+jobs:
+  matrix:
+    runs-on: ubuntu-latest
+    outputs:
+      languages: ${{ steps.languages.outputs.languages }}
+
+    steps:
+    - name: Grab the repo src
+      uses: actions/checkout@v4
+      with:
+        ref: ${{ env.I18N_BRANCH }}
+    
+    - name: List languages
+      id: languages
+      working-directory: locales
+      run: |
+        dirs=$(find * -maxdepth 0 -type d)
+        list="$(echo $dirs | sed "s|^|['|;s|$|']|;s| |', '|g")"
+        echo "languages=$list" >> $GITHUB_OUTPUT
+
+
+  test-translation:
+    runs-on: ubuntu-latest
+    needs: matrix
+    strategy:
+      fail-fast: false
+      matrix:
+        language: ${{fromJson(needs.matrix.outputs.languages)}}
+
+    steps:
+    - name: Grab the repo src
+      uses: actions/checkout@v4
+      with:
+        ref: ${{ env.I18N_BRANCH }}
+
+    - name: Set up Python
+      uses: actions/setup-python@v4
+      with:
+        python-version: >-
+          3.10
+
+    - name: Install Python tooling
+      run: python -m pip install --upgrade nox virtualenv
+
+    - name: Build translated docs in ${{ matrix.language }}
+      run: nox -s build -- -D language=${{ matrix.language }}

From 6526d6fdd71b36353d0bf706ca5d4a0c1ed44a87 Mon Sep 17 00:00:00 2001
From: Rafael Fontenelle 
Date: Sun, 3 Dec 2023 17:20:17 -0300
Subject: [PATCH 0551/1072] Add sphinx-lint, make sphinx quiet

---
 .github/workflows/test-translations.yml | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/.github/workflows/test-translations.yml b/.github/workflows/test-translations.yml
index 03df0ee70..9b1ad5c6f 100644
--- a/.github/workflows/test-translations.yml
+++ b/.github/workflows/test-translations.yml
@@ -34,7 +34,7 @@ jobs:
       uses: actions/checkout@v4
       with:
         ref: ${{ env.I18N_BRANCH }}
-    
+
     - name: List languages
       id: languages
       working-directory: locales
@@ -65,7 +65,10 @@ jobs:
           3.10
 
     - name: Install Python tooling
-      run: python -m pip install --upgrade nox virtualenv
+      run: python -m pip install --upgrade nox virtualenv sphinx-lint
 
     - name: Build translated docs in ${{ matrix.language }}
-      run: nox -s build -- -D language=${{ matrix.language }}
+      run: nox -s build -- -q -D language=${{ matrix.language }}
+
+    - name: Lint translation file
+      run: sphinx-lint locales/${{ matrix.language }}/LC_MESSAGES/message.po

From 9d1ba3147aab978e9d6834853b6d32742eec10a7 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Mon, 4 Dec 2023 08:12:02 +0100
Subject: [PATCH 0552/1072] Improve "further reading" at end of "packaging
 projects" tutorial

- Add links to advanced configuration for each build backend
- Replace link to "Packaging binary extensions" guide (an advanced topic,
  probably not what newcomers want to read) with links to the TOCs for
  guides and discussions
- Remove links to PEP 517 and PEP 518, which are technical standards,
  not user-facing documentation
---
 source/conf.py                          |  1 +
 source/tutorials/packaging-projects.rst | 16 +++++++++++-----
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/source/conf.py b/source/conf.py
index 75bf14be0..6c50b0ad0 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -141,6 +141,7 @@
     "dh-virtualenv": ("https://dh-virtualenv.readthedocs.io/en/latest/", None),
     "distlib": ("https://distlib.readthedocs.io/en/latest/", None),
     "flexx": ("https://flexx.readthedocs.io/en/latest/", None),
+    "flit": ("https://flit.pypa.io/en/stable/", None),
     "nox": ("https://nox.thea.codes/en/latest/", None),
     "openstack": ("https://docs.openstack.org/glance/latest/", None),
     "packaging": ("https://packaging.pypa.io/en/latest/", None),
diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst
index 23742c7d8..f1098590b 100644
--- a/source/tutorials/packaging-projects.rst
+++ b/source/tutorials/packaging-projects.rst
@@ -529,14 +529,16 @@ differences:
 At this point if you want to read more on packaging Python libraries here are
 some things you can do:
 
-.. TODO: Add links to other guides
-.. TODO: Add links to backend configuration docs
-
+* Read about advanced configuration for your chosen build backend:
+  `Hatchling `_,
+  :doc:`setuptools `,
+  :doc:`Flit `, `PDM `_.
+* Look at the :doc:`guides ` on this site for more advanced
+  practical information, or the :doc:`discussions `
+  for explanations and background on specific topics.
 * Consider packaging tools that provide a single command-line interface for
   project management and packaging, such as :ref:`hatch`, :ref:`flit`,
   :ref:`pdm`, and :ref:`poetry`.
-* Read :pep:`517` and :pep:`518` for background and details on build tool configuration.
-* Read about :doc:`/guides/packaging-binary-extensions`.
 
 
 ----
@@ -549,3 +551,7 @@ some things you can do:
    and considered an **advanced topic** (not covered in this tutorial).
    If you are only getting started with Python packaging, it is recommended to
    stick with *regular packages* and ``__init__.py`` (even if the file is empty).
+
+
+.. _hatchling-config: https://hatch.pypa.io/latest/config/metadata/
+.. _pdm-config: https://pdm-project.org/latest/reference/pep621/

From 995d2b7847c51dc7766d69df3c4a29d4c5286261 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Mon, 4 Dec 2023 20:54:48 +0100
Subject: [PATCH 0553/1072] Update references in modernize-setup-py-project
 guide

In parallel PRs, these references were added and the labels got renamed.
---
 source/guides/modernize-setup-py-project.rst | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/source/guides/modernize-setup-py-project.rst b/source/guides/modernize-setup-py-project.rst
index 98f0d78c0..bea636ca4 100644
--- a/source/guides/modernize-setup-py-project.rst
+++ b/source/guides/modernize-setup-py-project.rst
@@ -66,7 +66,7 @@ triggers :ref:`pip` to change its default behavior to use *build isolation*.
 For more details:
 
 * :ref:`distributing-packages`
-* :ref:`declaring-build-dependencies`
+* :ref:`pyproject-build-system-table`
 * :doc:`pip:reference/build-system/pyproject-toml`
 
 
@@ -110,7 +110,7 @@ requires a :file:`pyproject.toml` file like this (:file:`setup.py` stays unchang
 
 For more details:
 
-* :ref:`declaring-build-dependencies`
+* :ref:`pyproject-build-system-table`
 
 
 What is the build isolation feature?
@@ -161,7 +161,7 @@ can be entirely replaced by a :file:`pyproject.toml` file like this:
     version = "1.2.3"
 
 
-Read :ref:`declaring-project-metadata` for the full specification
+Read :ref:`pyproject-project-table` for the full specification
 of the content allowed in the ``[project]`` table.
 
 
@@ -243,7 +243,6 @@ This file can be as minimalistic as this:
 Where to read more about this?
 ==============================
 
-* :ref:`declaring-build-dependencies`
-* :ref:`declaring-project-metadata`
+* :ref:`pyproject-toml-spec`
 * :doc:`pip:reference/build-system/pyproject-toml`
 * :doc:`setuptools:build_meta`

From ef609d0581f4cdb67d328007ce962d1a413c0a8a Mon Sep 17 00:00:00 2001
From: Hugo van Kemenade 
Date: Mon, 4 Dec 2023 14:26:38 -0700
Subject: [PATCH 0554/1072] Keep old reference to unbreak intersphinx

---
 source/specifications/pyproject-toml.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 21cd2340d..92811958b 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -1,3 +1,4 @@
+.. _declaring-project-metadata:
 .. _pyproject-toml-spec:
 
 ================================

From cc61ec77d6f4c3c7981b4e75425947561dec5f7c Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Tue, 5 Dec 2023 16:13:52 +0100
Subject: [PATCH 0555/1072] Update pipx link

---
 source/guides/installing-stand-alone-command-line-tools.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/installing-stand-alone-command-line-tools.rst b/source/guides/installing-stand-alone-command-line-tools.rst
index f584cf996..ecc44a487 100644
--- a/source/guides/installing-stand-alone-command-line-tools.rst
+++ b/source/guides/installing-stand-alone-command-line-tools.rst
@@ -128,4 +128,4 @@ To see the full list of commands pipx offers, run:
 
   pipx --help
 
-You can learn more about pipx at https://pypa.github.io/pipx/.
+You can learn more about pipx at https://pipx.pypa.io/.

From 589d9ddb51dec3d2d4ab266ea3d4eeae788b904f Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Tue, 5 Dec 2023 16:19:39 +0100
Subject: [PATCH 0556/1072] Also update key_projects.rst

---
 source/key_projects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index a1fda4601..a71c219d4 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -233,7 +233,7 @@ application-centric alternative to :ref:`pip`'s lower-level
 pipx
 ====
 
-`Docs `__ |
+`Docs `__ |
 `GitHub `__ |
 `PyPI `__
 

From b53baf2057fecb077a3af765c33cc9c0542df4bc Mon Sep 17 00:00:00 2001
From: sinoroc <5529267+sinoroc@users.noreply.github.com>
Date: Tue, 5 Dec 2023 17:44:03 +0100
Subject: [PATCH 0557/1072] Update source/discussions/setup-py-deprecated.rst

Co-authored-by: chrysle 
---
 source/discussions/setup-py-deprecated.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/setup-py-deprecated.rst b/source/discussions/setup-py-deprecated.rst
index 279e4abce..c4d7258b4 100644
--- a/source/discussions/setup-py-deprecated.rst
+++ b/source/discussions/setup-py-deprecated.rst
@@ -105,7 +105,7 @@ A trusted replacement is :ref:`twine`:
 * ``python -m twine upload dist/*``
 
 .. [#not-pypi] Not necessary, nor supported on :term:`PyPI `.
-    But might be necessary on other :term:`package indexes `.
+    But might be necessary on other :term:`package indexes ` (for example :ref:`devpi`).
 
 
 ``python setup.py --version``

From 74554f1a104957229dc7c8d2b505fa9048a1209f Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Tue, 5 Dec 2023 21:25:36 +0100
Subject: [PATCH 0558/1072] Prevent workflow failures on forks

---
 .github/workflows/test.yml        | 2 +-
 .github/workflows/translation.yml | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
index 581b644ca..9ca602b2a 100644
--- a/.github/workflows/test.yml
+++ b/.github/workflows/test.yml
@@ -47,7 +47,7 @@ jobs:
     # This job does nothing and is only used for the branch protection
     # or multi-stage CI jobs, like making sure that all tests pass before
     # a publishing job is started.
-    if: always()
+    if: ${{ github.repository_owner == 'pypa' || github.event_name != 'schedule' }}
 
     needs:
     - build
diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml
index d2ac8db35..85152af5b 100644
--- a/.github/workflows/translation.yml
+++ b/.github/workflows/translation.yml
@@ -15,6 +15,7 @@ env:
 jobs:
   build:
     runs-on: ubuntu-latest
+    if: $${ github.repository_owner == 'pypa' }}
 
     steps:
     - name: Grab the repo src

From 0bf1014cbb481e648fedd24e0d1010ba8379f212 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Tue, 5 Dec 2023 22:08:33 +0100
Subject: [PATCH 0559/1072] Remove the guide from its own Intersphinx mapping

Fixes #1438

Also replace a few hyperlinks inside packaging.python.org with normal
references.
---
 source/conf.py                                           | 1 -
 source/guides/distributing-packages-using-setuptools.rst | 3 +--
 source/key_projects.rst                                  | 5 ++---
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/source/conf.py b/source/conf.py
index 6c50b0ad0..0e3a93d5e 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -145,7 +145,6 @@
     "nox": ("https://nox.thea.codes/en/latest/", None),
     "openstack": ("https://docs.openstack.org/glance/latest/", None),
     "packaging": ("https://packaging.pypa.io/en/latest/", None),
-    "packaging.python.org": ("https://packaging.python.org/en/latest/", None),
     "pip": ("https://pip.pypa.io/en/latest/", None),
     "pipenv": ("https://pipenv.pypa.io/en/latest/", None),
     "piwheels": ("https://piwheels.readthedocs.io/en/latest/", None),
diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst
index 4b570e17b..7bc7db646 100644
--- a/source/guides/distributing-packages-using-setuptools.rst
+++ b/source/guides/distributing-packages-using-setuptools.rst
@@ -233,8 +233,7 @@ the front-page lists of trending projects and new releases, and the list of
 projects you maintain within your account profile (such as
 https://pypi.org/user/jaraco/).
 
-A `content type
-`_
+A :ref:`content type `
 can be specified with the ``long_description_content_type`` argument, which can
 be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding
 to no formatting, `reStructuredText (reST)
diff --git a/source/key_projects.rst b/source/key_projects.rst
index a71c219d4..671675641 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -244,7 +244,7 @@ causing dependency conflicts with other packages installed on the system.
 Python Packaging User Guide
 ===========================
 
-:doc:`Docs ` |
+:doc:`Docs ` |
 `Issues `__ |
 `GitHub `__
 
@@ -292,8 +292,7 @@ trove-classifiers
 
 trove-classifiers is the canonical source for `classifiers on PyPI
 `_, which project maintainers use to
-`systematically describe their projects
-`_
+:ref:`systematically describe their projects `
 so that users can better find projects that match their needs on the PyPI.
 
 The trove-classifiers package contains a list of valid classifiers and

From cd52365f8a96e9cf9840ea3f4f9cab0bb2a0a1d7 Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Tue, 5 Dec 2023 22:14:27 +0100
Subject: [PATCH 0560/1072] Update .github/workflows/test.yml

Co-authored-by: Sviatoslav Sydorenko 
---
 .github/workflows/test.yml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
index 9ca602b2a..7645d7fcc 100644
--- a/.github/workflows/test.yml
+++ b/.github/workflows/test.yml
@@ -47,7 +47,9 @@ jobs:
     # This job does nothing and is only used for the branch protection
     # or multi-stage CI jobs, like making sure that all tests pass before
     # a publishing job is started.
-    if: ${{ github.repository_owner == 'pypa' || github.event_name != 'schedule' }}
+    if: >-
+      github.repository_owner == 'pypa'
+      || github.event_name != 'schedule'
 
     needs:
     - build

From 539d2917ad6568f6789af48f7929c599ae750e97 Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Tue, 5 Dec 2023 22:14:34 +0100
Subject: [PATCH 0561/1072] Update .github/workflows/translation.yml

Co-authored-by: Sviatoslav Sydorenko 
---
 .github/workflows/translation.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml
index 85152af5b..ffb2a9d05 100644
--- a/.github/workflows/translation.yml
+++ b/.github/workflows/translation.yml
@@ -15,7 +15,7 @@ env:
 jobs:
   build:
     runs-on: ubuntu-latest
-    if: $${ github.repository_owner == 'pypa' }}
+    if: github.repository_owner == 'pypa'
 
     steps:
     - name: Grab the repo src

From 8c00635f8489316e6f1aada153859e650f97d2c5 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 6 Dec 2023 21:38:48 +0100
Subject: [PATCH 0562/1072] Fix reST syntax for definition lists in
 direct-url-data-structure.rst

---
 .../direct-url-data-structure.rst             | 20 -------------------
 1 file changed, 20 deletions(-)

diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index e7c494111..608ed6963 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -130,24 +130,19 @@ Git
 ---
 
 Home page
-
    https://git-scm.com/
 
 vcs command
-
    git
 
 ``vcs`` field
-
    git
 
 ``requested_revision`` field
-
    A tag name, branch name, Git ref, commit hash, shortened commit hash,
    or other commit-ish.
 
 ``commit_id`` field
-
    A commit hash (40 hexadecimal characters sha1).
 
 .. note::
@@ -162,70 +157,55 @@ Mercurial
 ---------
 
 Home page
-
    https://www.mercurial-scm.org/
 
 vcs command
-
    hg
 
 ``vcs`` field
-
    hg
 
 ``requested_revision`` field
-
    A tag name, branch name, changeset ID, shortened changeset ID.
 
 ``commit_id`` field
-
    A changeset ID (40 hexadecimal characters).
 
 Bazaar
 ------
 
 Home page
-
    https://www.breezy-vcs.org/
 
 vcs command
-
    bzr
 
 ``vcs`` field
-
    bzr
 
 ``requested_revision`` field
-
    A tag name, branch name, revision id.
 
 ``commit_id`` field
-
    A revision id.
 
 Subversion
 ----------
 
 Home page
-
    https://subversion.apache.org/
 
 vcs command
-
    svn
 
 ``vcs`` field
-
    svn
 
 ``requested_revision`` field
-
    ``requested_revision`` must be compatible with ``svn checkout`` ``--revision`` option.
    In Subversion, branch or tag is part of ``url``.
 
 ``commit_id`` field
-
    Since Subversion does not support globally unique identifiers,
    this field is the Subversion revision number in the corresponding
    repository.

From 1b20810809654c18f8e67670a402b5e44809add4 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 6 Dec 2023 21:47:31 +0100
Subject: [PATCH 0563/1072] Wheel spec: Remove some remnants of the PEP format

---
 .../binary-distribution-format.rst            | 57 +++----------------
 1 file changed, 8 insertions(+), 49 deletions(-)

diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst
index 04367cc85..d0de03989 100644
--- a/source/specifications/binary-distribution-format.rst
+++ b/source/specifications/binary-distribution-format.rst
@@ -5,14 +5,8 @@
 Binary distribution format
 ==========================
 
-The binary distribution format (:term:`wheel `) was originally defined
-in :pep:`427`. The current version of the specification is here.
-
-
-Abstract
-========
-
-This PEP describes a built-package format for Python called "wheel".
+This page specifies the binary distribution format for Python packages,
+also called the wheel format.
 
 A wheel is a ZIP-format archive with a specially formatted file name and
 the ``.whl`` extension.  It contains a single distribution nearly as it
@@ -23,31 +17,6 @@ may be installed by simply unpacking into site-packages with the standard
 out onto their final paths at any later time.
 
 
-PEP Acceptance
-==============
-
-This PEP was accepted, and the defined wheel version updated to 1.0, by
-Nick Coghlan on 16th February, 2013 [1]_
-
-
-Rationale
-=========
-
-Python needs a package format that is easier to install than sdist.
-Python's sdist packages are defined by and require the distutils and
-setuptools build systems, running arbitrary code to build-and-install,
-and re-compile, code just so it can be installed into a new
-virtualenv.  This system of conflating build-install is slow, hard to
-maintain, and hinders innovation in both build systems and installers.
-
-Wheel attempts to remedy these problems by providing a simpler
-interface between the build system and the installer.  The wheel
-binary package format frees installers from having to know about the
-build system, saves time by amortizing compile time over many
-installations, and removes the need to install a build system in the
-target environment.
-
-
 Details
 =======
 
@@ -469,20 +438,16 @@ Is it possible to import Python code directly from a wheel file?
     aware that many projects will require a failure to be reproduced with
     a fully installed package before accepting it as a genuine bug.
 
-Changes
-=======
-
-Since :pep:`427`, this specification has changed as follows:
 
-- The rules on escaping in wheel filenames were revised, to bring them into line
-  with what popular tools actually do (February 2021).
+History
+=======
 
+This specification was originally approved as :pep:`427`.
 
-References
-==========
+The following changes were applied since the initial version:
 
-.. [1] PEP acceptance
-   (https://mail.python.org/pipermail/python-dev/2013-February/124103.html)
+- The rules on escaping in wheel filenames were revised, to bring them
+  into line with what popular tools actually do (February 2021).
 
 
 Appendix
@@ -499,9 +464,3 @@ Example urlsafe-base64-nopad implementation::
     def urlsafe_b64decode_nopad(data):
         pad = b'=' * (4 - (len(data) & 3))
         return base64.urlsafe_b64decode(data + pad)
-
-
-Copyright
-=========
-
-This document has been placed into the public domain.

From 10f40c8aae0841b795f171b5096d5916dcb3181d Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 6 Dec 2023 21:49:44 +0100
Subject: [PATCH 0564/1072] Wheel spec: Remove comparison to .egg

This is duplicated with source/guides/wheel-vs-egg.rst.
---
 .../binary-distribution-format.rst            | 27 -------------------
 1 file changed, 27 deletions(-)

diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst
index d0de03989..a66e3c2a6 100644
--- a/source/specifications/binary-distribution-format.rst
+++ b/source/specifications/binary-distribution-format.rst
@@ -307,33 +307,6 @@ See
 - https://datatracker.ietf.org/doc/html/draft-jones-jose-json-private-key-01
 
 
-Comparison to .egg
-------------------
-
-#. Wheel is an installation format; egg is importable.  Wheel archives
-   do not need to include .pyc and are less tied to a specific Python
-   version or implementation. Wheel can install (pure Python) packages
-   built with previous versions of Python so you don't always have to
-   wait for the packager to catch up.
-#. Wheel uses .dist-info directories; egg uses .egg-info.  Wheel is
-   compatible with the new world of Python packaging and the new
-   concepts it brings.
-#. Wheel has a richer file naming convention for today's
-   multi-implementation world.  A single wheel archive can indicate
-   its compatibility with a number of Python language versions and
-   implementations, ABIs, and system architectures.  Historically the
-   ABI has been specific to a CPython release, wheel is ready for the
-   stable ABI.
-#. Wheel is lossless.  The first wheel implementation bdist_wheel
-   always generates egg-info, and then converts it to a .whl.  It is
-   also possible to convert existing eggs and bdist_wininst
-   distributions.
-#. Wheel is versioned.  Every wheel file contains the version of the
-   wheel specification and the implementation that packaged it.
-   Hopefully the next migration can simply be to Wheel 2.0.
-#. Wheel is a reference to the other Python.
-
-
 FAQ
 ===
 

From 26d5c49b5b34afdcd482d10623b750beaaa8a80b Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 6 Dec 2023 23:00:11 +0100
Subject: [PATCH 0565/1072] Fix many spurious block quotes and wrong syntax
 highlighting languages

---
 .../guides/dropping-older-python-versions.rst |  4 ++-
 .../guides/installing-using-linux-tools.rst   |  8 +++---
 .../guides/making-a-pypi-friendly-readme.rst  |  6 ++---
 ...s-using-github-actions-ci-cd-workflows.rst | 12 ++++-----
 source/guides/using-testpypi.rst              |  2 +-
 .../binary-distribution-format.rst            |  5 +++-
 source/specifications/core-metadata.rst       |  2 ++
 .../specifications/dependency-specifiers.rst  | 10 +++++--
 .../direct-url-data-structure.rst             |  5 +++-
 source/specifications/entry-points.rst        |  4 ++-
 .../recording-installed-packages.rst          |  2 ++
 source/specifications/version-specifiers.rst  | 10 +++++--
 source/tutorials/installing-packages.rst      | 26 +++++++++----------
 13 files changed, 61 insertions(+), 35 deletions(-)

diff --git a/source/guides/dropping-older-python-versions.rst b/source/guides/dropping-older-python-versions.rst
index 2ac193b4c..c0c2b4434 100644
--- a/source/guides/dropping-older-python-versions.rst
+++ b/source/guides/dropping-older-python-versions.rst
@@ -78,7 +78,9 @@ Steps:
 
 You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond.
 
-Examples::
+Examples:
+
+.. code-block:: text
 
     Requires-Python: ">=3"
     Requires-Python: ">2.7,!=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*"
diff --git a/source/guides/installing-using-linux-tools.rst b/source/guides/installing-using-linux-tools.rst
index b3d37675f..f0914f8dc 100644
--- a/source/guides/installing-using-linux-tools.rst
+++ b/source/guides/installing-using-linux-tools.rst
@@ -107,9 +107,9 @@ To install pip, wheel, and setuptools, in a parallel, non-system environment
 openSUSE
 ~~~~~~~~
 
-  .. code-block:: bash
+.. code-block:: bash
 
-    sudo zypper install python3-pip python3-setuptools python3-wheel
+   sudo zypper install python3-pip python3-setuptools python3-wheel
 
 
 .. _debian-ubuntu:
@@ -134,9 +134,9 @@ Firstly, update and refresh repository lists by running this command:
 Arch Linux
 ~~~~~~~~~~
 
-  .. code-block:: bash
+.. code-block:: bash
 
-    sudo pacman -S python-pip
+   sudo pacman -S python-pip
 
 ----
 
diff --git a/source/guides/making-a-pypi-friendly-readme.rst b/source/guides/making-a-pypi-friendly-readme.rst
index 4f85d5054..4a3a20670 100644
--- a/source/guides/making-a-pypi-friendly-readme.rst
+++ b/source/guides/making-a-pypi-friendly-readme.rst
@@ -59,9 +59,9 @@ such as ``text/plain``, ``text/x-rst`` (for reStructuredText), or ``text/markdow
 
    The minimum required versions of the respective tools are:
 
-    - ``setuptools >= 38.6.0``
-    - ``wheel >= 0.31.0``
-    - ``twine >= 1.11.0``
+   - ``setuptools >= 38.6.0``
+   - ``wheel >= 0.31.0``
+   - ``twine >= 1.11.0``
 
    It's recommended that you use ``twine`` to upload the project's distribution packages:
 
diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
index db7c88973..ca75d159b 100644
--- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
+++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
@@ -37,13 +37,13 @@ for your new :term:`PyPI project `.
 However it is also possible to add `trusted publishing`_ to any
 pre-existing project, if you are its owner.
 
-   .. attention::
+.. attention::
 
-      If you followed earlier versions of this guide, you
-      have created the secrets ``PYPI_API_TOKEN`` and ``TEST_PYPI_API_TOKEN``
-      for direct PyPI and TestPyPI access. These are obsolete now and
-      you should remove them from your GitHub repository and revoke
-      them in your PyPI and TestPyPI account settings in case you are replacing your old setup with the new one.
+   If you followed earlier versions of this guide, you
+   have created the secrets ``PYPI_API_TOKEN`` and ``TEST_PYPI_API_TOKEN``
+   for direct PyPI and TestPyPI access. These are obsolete now and
+   you should remove them from your GitHub repository and revoke
+   them in your PyPI and TestPyPI account settings in case you are replacing your old setup with the new one.
 
 
 Let's begin! 🚀
diff --git a/source/guides/using-testpypi.rst b/source/guides/using-testpypi.rst
index 1d466e4ea..f2c4f07c6 100644
--- a/source/guides/using-testpypi.rst
+++ b/source/guides/using-testpypi.rst
@@ -75,7 +75,7 @@ Setting up TestPyPI in :file:`.pypirc`
 If you want to avoid entering your username, you can configure TestPyPI in
 your :file:`$HOME/.pypirc`:
 
-.. code::
+.. code:: ini
 
     [testpypi]
     username = 
diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst
index a66e3c2a6..6637fed2e 100644
--- a/source/specifications/binary-distribution-format.rst
+++ b/source/specifications/binary-distribution-format.rst
@@ -1,3 +1,4 @@
+.. highlight:: text
 
 .. _binary-distribution-format:
 
@@ -285,7 +286,9 @@ or the installation will fail.
 If JSON web signatures are used, one or more JSON Web Signature JSON
 Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent
 to RECORD.  JWS is used to sign RECORD by including the SHA-256 hash of
-RECORD as the signature's JSON payload::
+RECORD as the signature's JSON payload:
+
+.. code-block:: json
 
     { "hash": "sha256=ADD-r2urObZHcxBW3Cr-vDCu5RJwT4CaRTHiFmbcIYY" }
 
diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index c8a0ca41c..b8cd5326e 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -1,3 +1,5 @@
+.. highlight:: text
+
 .. _`core-metadata`:
 
 ============================
diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst
index 0389ce3cb..6287f3815 100644
--- a/source/specifications/dependency-specifiers.rst
+++ b/source/specifications/dependency-specifiers.rst
@@ -1,3 +1,5 @@
+.. highlight:: text
+
 .. _dependency-specifiers:
 
 =====================
@@ -273,7 +275,9 @@ error like all other unknown variables.
      - ``test``
 
 The ``implementation_version`` marker variable is derived from
-``sys.implementation.version``::
+``sys.implementation.version``:
+
+.. code-block:: python
 
     def format_full_version(info):
         version = '{0.major}.{0.minor}.{0.micro}'.format(info)
@@ -400,7 +404,9 @@ The complete parsley grammar::
     sub_delims    = '!' | '$' | '&' | '\\'' | '(' | ')' | '*' | '+' | ',' | ';' | '='
     hexdig        = digit | 'a' | 'A' | 'b' | 'B' | 'c' | 'C' | 'd' | 'D' | 'e' | 'E' | 'f' | 'F'
 
-A test program - if the grammar is in a string ``grammar``::
+A test program - if the grammar is in a string ``grammar``:
+
+.. code-block:: python
 
     import os
     import sys
diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index 608ed6963..22900636c 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -1,3 +1,4 @@
+.. highlight:: json
 
 .. _direct-url-data-structure:
 
@@ -32,7 +33,9 @@ for security reasons.
 
 The user:password section of the URL MAY however
 be composed of environment variables, matching the following regular
-expression::
+expression:
+
+.. code-block:: text
 
     \$\{[A-Za-z0-9-_]+\}(:\$\{[A-Za-z0-9-_]+\})?
 
diff --git a/source/specifications/entry-points.rst b/source/specifications/entry-points.rst
index a11f3ca93..90a18a0bc 100644
--- a/source/specifications/entry-points.rst
+++ b/source/specifications/entry-points.rst
@@ -111,7 +111,9 @@ restrictions on values specified in :pep:`685`.
 For tools writing the file, it is recommended only to insert a space between the
 object reference and the left square bracket.
 
-For example::
+For example:
+
+.. code-block:: ini
 
     [console_scripts]
     foo = foomod:main
diff --git a/source/specifications/recording-installed-packages.rst b/source/specifications/recording-installed-packages.rst
index 53ba6b2b9..ca8d5f0d5 100644
--- a/source/specifications/recording-installed-packages.rst
+++ b/source/specifications/recording-installed-packages.rst
@@ -1,3 +1,5 @@
+.. highlight:: text
+
 .. _recording-installed-packages:
 
 ============================
diff --git a/source/specifications/version-specifiers.rst b/source/specifications/version-specifiers.rst
index acf3167c7..92131da0e 100644
--- a/source/specifications/version-specifiers.rst
+++ b/source/specifications/version-specifiers.rst
@@ -1,3 +1,5 @@
+.. highlight:: text
+
 .. _version-specifiers:
 
 ==================
@@ -1204,7 +1206,9 @@ version is already in that form, and if it's not, extract the various
 components for subsequent normalization.
 
 To test whether a version identifier is in the canonical format, you can use
-the following function::
+the following function:
+
+.. code-block:: python
 
     import re
     def is_canonical(version):
@@ -1212,7 +1216,9 @@ the following function::
 
 To extract the components of a version identifier, use the following regular
 expression (as defined by the `packaging `_
-project)::
+project):
+
+.. code-block:: python
 
     VERSION_PATTERN = r"""
         v?
diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst
index fc4218980..9491f5808 100644
--- a/source/tutorials/installing-packages.rst
+++ b/source/tutorials/installing-packages.rst
@@ -69,7 +69,7 @@ please install the latest 3.x version from `python.org`_ or refer to the
    notebook, you can run system commands like those in this tutorial by
    prefacing them with a ``!`` character:
 
-    ::
+   .. code-block:: text
 
         In [1]: import sys
                 !{sys.executable} --version
@@ -133,21 +133,21 @@ standard library:
 
 If that still doesn't allow you to run ``python -m pip``:
 
- * Securely Download `get-pip.py
-   `_ [1]_
+* Securely Download `get-pip.py
+  `_ [1]_
 
- * Run ``python get-pip.py``. [2]_  This will install or upgrade pip.
-   Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're
-   not installed already.
+* Run ``python get-pip.py``. [2]_  This will install or upgrade pip.
+  Additionally, it will install :ref:`setuptools` and :ref:`wheel` if they're
+  not installed already.
 
-   .. warning::
+  .. warning::
 
-      Be cautious if you're using a Python install that's managed by your
-      operating system or another package manager. get-pip.py does not
-      coordinate with those tools, and may leave your system in an
-      inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/``
-      to install in ``/usr/local`` which is designed for locally-installed
-      software.
+     Be cautious if you're using a Python install that's managed by your
+     operating system or another package manager. get-pip.py does not
+     coordinate with those tools, and may leave your system in an
+     inconsistent state. You can use ``python get-pip.py --prefix=/usr/local/``
+     to install in ``/usr/local`` which is designed for locally-installed
+     software.
 
 
 Ensure pip, setuptools, and wheel are up to date

From f9f3594e65aadff80cca4e019b7ea737cead6590 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 6 Dec 2023 23:47:39 +0100
Subject: [PATCH 0566/1072] Platform tags: Adjust to centralize history

Move history to a dedicated section (consistent with other specs). In
the main text, do not reference PEPs but just describe the current spec.
Also sketch out a few missing details.
---
 .../platform-compatibility-tags.rst           | 67 ++++++++++---------
 1 file changed, 37 insertions(+), 30 deletions(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index df7da59c5..4864f5bdd 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -9,13 +9,6 @@ Platform compatibility tags allow build tools to mark distributions as being
 compatible with specific platforms, and allows installers to understand which
 distributions are compatible with the system they are running on.
 
-The following PEPs contributed to this spec:
-
-1. :pep:`425`
-2. :pep:`513`
-3. :pep:`571`
-4. :pep:`599`
-5. :pep:`600`
 
 Overview
 ========
@@ -92,10 +85,14 @@ decide how to best use the ABI tag.
 Platform Tag
 ------------
 
-The platform tag is simply ``sysconfig.get_platform()`` with all
-hyphens ``-`` and periods ``.`` replaced with underscore ``_``.
+-------------------
+Basic platform tags
+-------------------
+
+In its simplest form, the platform tag is ``sysconfig.get_platform()`` with
+all hyphens ``-`` and periods ``.`` replaced with underscore ``_``.
 Until the removal of :ref:`distutils` in Python 3.12, this
-was ``distutils.util.get_platform()``.
+was ``distutils.util.get_platform()``. For example:
 
 * win32
 * linux_i386
@@ -107,32 +104,30 @@ was ``distutils.util.get_platform()``.
 -------------
 .. _manylinux:
 
-The scheme defined in :pep:`425` was insufficient for public distribution of
-wheel files (and \*nix wheel files in general) to Linux platforms, due to the
-large ecosystem of Linux platforms and subtle differences between them.
+The simple scheme above is insufficient for public distribution of wheel files
+to Linux platforms, due to the large ecosystem of Linux platforms and subtle
+differences between them.
 
-Instead, :pep:`600` defines the ``manylinux`` standard, which represents a
-common subset of Linux platforms, and allows building wheels tagged with the
+Instead, for those platforms, the ``manylinux`` standard represents a common
+subset of Linux platforms, and allows building wheels tagged with the
 ``manylinux`` platform tag which can be used across most common Linux
 distributions.
 
-There were multiple iterations of the ``manylinux`` specification, each
-representing the common subset of Linux platforms at a given point in time:
+The current standard is the future-proof ``manylinux_x_y`` standard. It defines
+tags of the form ``manylinux_x_y_arch``, where ``x`` and ``y`` are glibc major
+and minor versions supported (e.g. ``manylinux_2_24_xxx`` should work on any
+distro using glibc 2.24+), and ``arch`` is the architecture, matching the value
+of ``sysconfig.get_platform()`` on the system as in the "simple" form above.
 
-* ``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686``
-  architectures, and is based on a compatible Linux platform from 2007.
-* ``manylinux2010`` (:pep:`571`) supports ``x86_64`` and ``i686``
-  architectures. and updates the previous specification to be based on a
-  compatible Linux platform from 2010 instead.
-* ``manylinux2014`` (:pep:`599`) adds support for a number of
-  additional architectures (``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``,
-  and ``s390x``) and updates the base platform to a compatible Linux platform
-  from 2014.
+The following older tags are still supported for backward compatibility:
 
-``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a
-future-proof standard. It defines ``x`` and ``y`` as glibc major an minor
-versions supported (e.g. ``manylinux_2_24`` should work on any distro using
-glibc 2.24+). Previous tags are still supported for backward compatibility.
+* ``manylinux1`` is based on a compatible Linux platform from 2007,
+  and supports ``x86_64`` and ``i686`` architectures.
+* ``manylinux2010`` is based on a platform from 2010 and supports ``x86_64``
+  and ``i686``.
+* ``manylinux2014`` is based on a platform from 2014 and supports
+  ``x86_64``, ``i686``, ``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``,
+  and ``s390x``.
 
 In general, distributions built for older versions of the specification are
 forwards-compatible (meaning that ``manylinux1`` distributions should continue
@@ -302,3 +297,15 @@ Why is the ABI tag (the second tag) sometimes "none" in the reference implementa
     implementation at the time of writing guesses "none".  Ideally it
     would detect "py27(d|m|u)" analogous to newer versions of Python,
     but in the meantime "none" is a good enough way to say "don't know".
+
+
+History
+=======
+
+The following PEPs contributed to this spec:
+
+- :pep:`425`: initial definition of platform tags
+- :pep:`513`: defined ``manylinux1``
+- :pep:`571`: defined ``manylinux2010``
+- :pep:`599`: defined ``manylinux2014``
+- :pep:`600`: defined the ``manylinux_x_y`` scheme

From ecc391f25c30f540ec112b6822df3ccb838943de Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 6 Dec 2023 23:49:31 +0100
Subject: [PATCH 0567/1072] Remove note about manylinux_x_y being a new
 standard

It's been 4 years now.
---
 source/specifications/platform-compatibility-tags.rst | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 4864f5bdd..6e3f052fe 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -143,12 +143,6 @@ these images will no longer receive security updates.
 Manylinux compatibility support
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. Note::
-  * The ``manylinux2014`` specification is relatively new and is not yet widely
-    recognised by install tools.
-  * The ``manylinux_x_y`` specification is relatively new and is not yet widely
-    recognised by install tools.
-
 The following table shows the minimum versions of relevant projects to support
 the various ``manylinux`` standards:
 

From 74b071bcc1107c01118a4c4816c5375d0ded4bf6 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Thu, 7 Dec 2023 00:30:21 +0100
Subject: [PATCH 0568/1072] Platform tags: Flatten deeply nested headers

---
 .../platform-compatibility-tags.rst           | 22 +++++++------------
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 6e3f052fe..c374c1bad 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -25,9 +25,6 @@ platform tag
 For example, the tag ``py27-none-any`` indicates compatibility with Python 2.7
 (any Python 2.7 implementation) with no abi requirement, on any platform.
 
-Use
-===
-
 The ``wheel`` built package format includes these tags in its filenames,
 of the form
 ``{distribution}-{version}(-{build tag})?-{python tag}-{abitag}-{platform tag}.whl``.
@@ -35,11 +32,9 @@ Other package formats may have their own conventions.
 
 Any potential spaces in any tag should be replaced with ``_``.
 
-Details
-=======
 
 Python Tag
-----------
+==========
 
 The Python tag indicates the implementation and version required by
 a distribution.  Major implementations have abbreviated codes, initially:
@@ -66,8 +61,9 @@ intentionally released a cross-version-compatible distribution.
 A single-source Python 2/3 compatible distribution can use the compound
 tag ``py2.py3``.  See `Compressed Tag Sets`_, below.
 
+
 ABI Tag
--------
+=======
 
 The ABI tag indicates which Python ABI is required by any included
 extension modules.  For implementation-specific ABIs, the implementation
@@ -82,10 +78,10 @@ revision and compiler flags, etc, but will probably not have a great need
 to distribute binary distributions. Each implementation's community may
 decide how to best use the ABI tag.
 
+
 Platform Tag
-------------
+============
 
--------------------
 Basic platform tags
 -------------------
 
@@ -99,10 +95,10 @@ was ``distutils.util.get_platform()``. For example:
 * linux_x86_64
 
 
--------------
+.. _manylinux:
+
 ``manylinux``
 -------------
-.. _manylinux:
 
 The simple scheme above is insufficient for public distribution of wheel files
 to Linux platforms, due to the large ecosystem of Linux platforms and subtle
@@ -140,9 +136,6 @@ possible, with the caveat that the provided build environment for
 ``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that
 these images will no longer receive security updates.
 
-Manylinux compatibility support
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
 The following table shows the minimum versions of relevant projects to support
 the various ``manylinux`` standards:
 
@@ -155,6 +148,7 @@ auditwheel  ``>=1.0.0``     ``>=2.0.0``        ``>=3.0.0``        ``>=3.3.0`` [#
 
 .. [#] Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0
 
+
 Use
 ===
 

From b258ce28340c4a8fb42b70de257a778247cd30dc Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Thu, 7 Dec 2023 00:23:20 +0100
Subject: [PATCH 0569/1072] Add musllinux platform tags from PEP 656

---
 .../platform-compatibility-tags.rst           | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index c374c1bad..391845950 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -149,6 +149,50 @@ auditwheel  ``>=1.0.0``     ``>=2.0.0``        ``>=3.0.0``        ``>=3.3.0`` [#
 .. [#] Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0
 
 
+``musllinux``
+-------------
+
+The ``musllinux`` family of tags is similar to ``manylinux``, but for Linux
+platforms that use the musl_ libc rather than glibc (a prime example being Alpine
+Linux). The schema is ``musllinux_x_y_arch``, supporting musl ``x.y`` and higher
+on the architecture ``arch``.
+
+The musl version values can be obtained by executing the musl libc shared
+library the Python interpreter is currently running on, and parsing the output:
+
+.. code-block:: python
+
+   import re
+   import subprocess
+
+   def get_musl_major_minor(so: str) -> tuple[int, int] | None:
+       """Detect musl runtime version.
+
+       Returns a two-tuple ``(major, minor)`` that indicates musl
+       library's version, or ``None`` if the given libc .so does not
+       output expected information.
+
+       The libc library should output something like this to stderr::
+
+           musl libc (x86_64)
+           Version 1.2.2
+           Dynamic Program Loader
+       """
+       proc = subprocess.run([so], stderr=subprocess.PIPE, text=True)
+       lines = (line.strip() for line in proc.stderr.splitlines())
+       lines = [line for line in lines if line]
+       if len(lines) < 2 or lines[0][:4] != "musl":
+           return None
+       match = re.match(r"Version (\d+)\.(\d+)", lines[1])
+       if match:
+           return (int(match.group(1)), int(match.group(2)))
+       return None
+
+There are currently two possible ways to find the musl library’s location that a
+Python interpreter is running on, either with the system ldd_ command, or by
+parsing the ``PT_INTERP`` section’s value from the executable’s ELF_ header.
+
+
 Use
 ===
 
@@ -297,3 +341,10 @@ The following PEPs contributed to this spec:
 - :pep:`571`: defined ``manylinux2010``
 - :pep:`599`: defined ``manylinux2014``
 - :pep:`600`: defined the ``manylinux_x_y`` scheme
+- :pep:`656`: defined ``musllinux_x_y``
+
+
+
+.. _musl: https://musl.libc.org
+.. _ldd: https://www.unix.com/man-page/posix/1/ldd/
+.. _elf: https://refspecs.linuxfoundation.org/elf/elf.pdf

From b978b7da7b92e861ebb64262ac36541b80e45b10 Mon Sep 17 00:00:00 2001
From: Rafael Fontenelle 
Date: Tue, 5 Dec 2023 07:50:50 -0300
Subject: [PATCH 0570/1072] Do not fail when there's nothing to commit

---
 .github/workflows/translation.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml
index d2ac8db35..c2ac3272c 100644
--- a/.github/workflows/translation.yml
+++ b/.github/workflows/translation.yml
@@ -65,6 +65,7 @@ jobs:
       run: |
         git_hash=$(git rev-parse --short "${GITHUB_SHA}")
         git add --force locales/messages.pot
+        git diff-index --quiet HEAD || \
         git commit \
           -m "Update messages.pot as of version ${git_hash}" \
           locales/messages.pot

From 7ca45200b064e1f95f1532466f3e5d254b015af0 Mon Sep 17 00:00:00 2001
From: Michael Deutsch 
Date: Sun, 10 Dec 2023 07:48:38 +0200
Subject: [PATCH 0571/1072] Update analyzing-pypi-package-downloads.rst

Fixing very minor typo: `it's` should be `its`
---
 source/guides/analyzing-pypi-package-downloads.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/analyzing-pypi-package-downloads.rst b/source/guides/analyzing-pypi-package-downloads.rst
index 4d2993479..62efea7ab 100644
--- a/source/guides/analyzing-pypi-package-downloads.rst
+++ b/source/guides/analyzing-pypi-package-downloads.rst
@@ -32,7 +32,7 @@ PyPI does not display download statistics for a number of reasons: [#]_
   doesn't mean it's good; Similarly just because a project hasn't been
   downloaded a lot doesn't mean it's bad!
 
-In short, because it's value is low for various reasons, and the tradeoffs
+In short, because its value is low for various reasons, and the tradeoffs
 required to make it work are high, it has been not an effective use of
 limited resources.
 

From 9f11a8a94ce8643aae74c47c2f9f0c2e05033a1b Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 11 Dec 2023 18:37:50 +0000
Subject: [PATCH 0572/1072] [pre-commit.ci] pre-commit autoupdate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

updates:
- [github.com/astral-sh/ruff-pre-commit: v0.1.6 → v0.1.7](https://github.com/astral-sh/ruff-pre-commit/compare/v0.1.6...v0.1.7)
---
 .pre-commit-config.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index fcc1b0d0f..ee15601ec 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -34,7 +34,7 @@ repos:
   - id: rst-inline-touching-normal
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.1.6
+  rev: v0.1.7
   hooks:
     - id: ruff
     - id: ruff-format

From 9368064ae5897ddfae0876b094e8e8c646cbb55f Mon Sep 17 00:00:00 2001
From: Graham Ashton 
Date: Tue, 12 Dec 2023 10:59:03 +0000
Subject: [PATCH 0573/1072] Clarify docs for creating virtual environment

I just watched a streamer on Twitch get stuck on this paragraph.

The docs said you should run `venv`, as if it's a command.

Which it isn't.
---
 .../guides/installing-using-pip-and-virtual-environments.rst | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst
index 4743e773a..e6aa88471 100644
--- a/source/guides/installing-using-pip-and-virtual-environments.rst
+++ b/source/guides/installing-using-pip-and-virtual-environments.rst
@@ -45,8 +45,9 @@ another project's environment.
    It is recommended to use a virtual environment when working with third
    party packages.
 
-To create a virtual environment, go to your project's directory and run
-``venv``. This will create a new virtual environment in a local folder ``.venv``:
+To create a virtual environment, go to your project's directory and run the
+following command. This will create a new virtual environment in a local folder
+named ``.venv``:
 
 .. tab:: Unix/macOS
 

From 10006824edc01a9546c7ed2ae7bcff192805fc8c Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Mon, 11 Dec 2023 20:16:33 +0100
Subject: [PATCH 0574/1072] Start updating
 distributing-packages-using-setuptools guide

---
 ...distributing-packages-using-setuptools.rst | 277 +-----------------
 .../single-sourcing-package-version.rst       |   1 +
 source/guides/writing-pyproject-toml.rst      |  81 ++++-
 3 files changed, 79 insertions(+), 280 deletions(-)

diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst
index 7bc7db646..e0ab11cc0 100644
--- a/source/guides/distributing-packages-using-setuptools.rst
+++ b/source/guides/distributing-packages-using-setuptools.rst
@@ -4,6 +4,10 @@
 Packaging and distributing projects
 ===================================
 
+.. warning::
+   As of December 2023, this page is largely outdated
+   and currently being revised.
+
 This section covers some additional details on configuring, packaging and
 distributing Python projects with ``setuptools`` that aren't covered by the
 introductory tutorial in :doc:`/tutorials/packaging-projects`.  It still assumes
@@ -153,206 +157,21 @@ As mentioned above, the primary feature of :file:`setup.py` is that it contains
 a global ``setup()`` function.  The keyword arguments to this function are how
 specific details of your project are defined.
 
-The most relevant arguments are explained below. Most of the snippets given are
+Some are temporarily explained below until their information is moved elsewhere.
+The full list can be found :doc:`in the setuptools documentation
+`.
+
+Most of the snippets given are
 taken from the `setup.py
 `_ contained in the
 `PyPA sample project `_.
 
 
-.. _`setup() name`:
-
-``name``
-~~~~~~~~
-
-::
-
-  name='sample',
-
-This is the name of your project, determining how your project is listed on
-:term:`PyPI `.  Per :pep:`508`, valid project
-names must:
-
-- Consist only of ASCII letters, digits, underscores (``_``), hyphens (``-``),
-  and/or periods (``.``), and
-- Start & end with an ASCII letter or digit.
-
-Comparison of project names is case insensitive and treats arbitrarily-long
-runs of underscores, hyphens, and/or periods as equal.  For example, if you
-register a project named ``cool-stuff``, users will be able to download it or
-declare a dependency on it using any of the following spellings::
-
-    Cool-Stuff
-    cool.stuff
-    COOL_STUFF
-    CoOl__-.-__sTuFF
-
-
-``version``
-~~~~~~~~~~~
-
-::
-
-  version='1.2.0',
-
-This is the current version of your project, allowing your users to determine whether or not
-they have the latest version, and to indicate which specific versions they've tested their own
-software against.
-
-Versions are displayed on :term:`PyPI ` for each release if you
-publish your project.
 
 See :ref:`Choosing a versioning scheme` for more information on ways to use versions to convey
 compatibility information to your users.
 
-If the project code itself needs run-time access to the version, the simplest
-way is to keep the version in both :file:`setup.py` and your code. If you'd
-rather not duplicate the value, there are a few ways to manage this. See the
-":ref:`Single sourcing the version`" Advanced Topics section.
-
-.. _`description`:
-
-``description``
-~~~~~~~~~~~~~~~
-
-::
-
-  description='A sample Python project',
-  long_description=long_description,
-  long_description_content_type='text/x-rst',
-
-Give a short and long description for your project.
-
-These values will be displayed on :term:`PyPI `
-if you publish your project. On ``pypi.org``, the user interface displays
-``description`` in the grey banner and ``long_description`` in the section
-named "Project Description".
-
-``description`` is also displayed in lists of projects. For example, it's
-visible in the search results pages such as https://pypi.org/search/?q=jupyter,
-the front-page lists of trending projects and new releases, and the list of
-projects you maintain within your account profile (such as
-https://pypi.org/user/jaraco/).
-
-A :ref:`content type `
-can be specified with the ``long_description_content_type`` argument, which can
-be one of ``text/plain``, ``text/x-rst``, or ``text/markdown``, corresponding
-to no formatting, `reStructuredText (reST)
-`_,
-and the GitHub-flavored Markdown dialect of `Markdown
-`_ respectively.
-
-``url``
-~~~~~~~
-
-::
-
-  url='https://github.com/pypa/sampleproject',
-
-
-Give a homepage URL for your project.
-
-
-``author``
-~~~~~~~~~~
-
-::
-
-  author='A. Random Developer',
-  author_email='author@example.com',
-
-Provide details about the author.
-
-
-``license``
-~~~~~~~~~~~
-
-::
-
-  license='MIT',
-
-The ``license`` argument doesn't have to indicate the license under
-which your package is being released, although you may optionally do
-so if you want.  If you're using a standard, well-known license, then
-your main indication can and should be via the ``classifiers``
-argument. Classifiers exist for all major open-source licenses.
-
-The ``license`` argument is more typically used to indicate differences
-from well-known licenses, or to include your own, unique license. As a
-general rule, it's a good idea to use a standard, well-known license,
-both to avoid confusion and because some organizations avoid software
-whose license is unapproved.
-
-
-``classifiers``
-~~~~~~~~~~~~~~~
-
-::
-
-  classifiers=[
-      # How mature is this project? Common values are
-      #   3 - Alpha
-      #   4 - Beta
-      #   5 - Production/Stable
-      'Development Status :: 3 - Alpha',
-
-      # Indicate who your project is intended for
-      'Intended Audience :: Developers',
-      'Topic :: Software Development :: Build Tools',
-
-      # Pick your license as you wish (should match "license" above)
-      'License :: OSI Approved :: MIT License',
-
-      # Specify the Python versions you support here. In particular, ensure
-      # that you indicate whether you support Python 2, Python 3 or both.
-      'Programming Language :: Python :: 2',
-      'Programming Language :: Python :: 2.7',
-      'Programming Language :: Python :: 3',
-      'Programming Language :: Python :: 3.6',
-      'Programming Language :: Python :: 3.7',
-      'Programming Language :: Python :: 3.8',
-      'Programming Language :: Python :: 3.9',
-  ],
-
-Provide a list of classifiers that categorize your project. For a full listing,
-see https://pypi.org/classifiers/.
-
-Although the list of classifiers is often used to declare what Python versions
-a project supports, this information is only used for searching & browsing
-projects on PyPI, not for installing projects.  To actually restrict what
-Python versions a project can be installed on, use the :ref:`python_requires`
-argument.
-
-To prevent a package from being uploaded to PyPI, use the special
-``'Private :: Do Not Upload'`` classifier. PyPI will always reject packages with
-classifiers beginning with ``"Private ::'``.
-
-
-``keywords``
-~~~~~~~~~~~~
-
-::
 
-  keywords='sample setuptools development',
-
-List keywords that describe your project.
-
-
-``project_urls``
-~~~~~~~~~~~~~~~~
-
-::
-
-  project_urls={
-      'Documentation': 'https://packaging.python.org/tutorials/distributing-packages/',
-      'Funding': 'https://donate.pypi.org',
-      'Say Thanks!': 'http://saythanks.io/to/example',
-      'Source': 'https://github.com/pypa/sampleproject/',
-      'Tracker': 'https://github.com/pypa/sampleproject/issues',
-  },
-
-List additional relevant URLs about your project. This is the place to link to
-bug trackers, source repositories, or where to support package development.
-The string of the key is the exact text that will be displayed on PyPI.
 
 
 ``packages``
@@ -396,38 +215,6 @@ specification that is used to install its dependencies.
 For more on using "install_requires" see :ref:`install_requires vs Requirements files`.
 
 
-.. _python_requires:
-
-``python_requires``
-~~~~~~~~~~~~~~~~~~~
-
-If your project only runs on certain Python versions, setting the
-``python_requires`` argument to the appropriate :pep:`440` version specifier
-string will prevent :ref:`pip` from installing the project on other Python
-versions.  For example, if your package is for Python 3+ only, write::
-
-    python_requires='>=3',
-
-If your package is for Python 2.6, 2.7, and all versions of Python 3 starting
-with 3.3, write::
-
-    python_requires='>=2.6, !=3.0.*, !=3.1.*, !=3.2.*',
-
-And so on.
-
-.. note::
-
-    Support for this feature is relatively recent.  Your project's source
-    distributions and wheels (see :ref:`Packaging Your Project`) must be built
-    using at least version 24.2.0 of :ref:`setuptools` in order for the
-    ``python_requires`` argument to be recognized and the appropriate metadata
-    generated.
-
-    In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the
-    ``python_requires`` metadata.  Users with earlier versions of pip will be
-    able to download & install projects on any Python version regardless of the
-    projects' ``python_requires`` values.
-
 
 .. _`Package Data`:
 
@@ -500,47 +287,8 @@ keyword for pointing to pre-made scripts to install, the recommended approach to
 achieve cross-platform compatibility is to use :ref:`console_scripts` entry
 points (see below).
 
-``entry_points``
-~~~~~~~~~~~~~~~~
-
-::
-
-  entry_points={
-    ...
-  },
 
 
-Use this keyword to specify any plugins that your project provides for any named
-entry points that may be defined by your project or others that you depend on.
-
-For more information, see the section on
-:ref:`Advertising Behavior `
-from the :ref:`setuptools` docs.
-
-The most commonly used entry point is "console_scripts" (see below).
-
-.. _`console_scripts`:
-
-``console_scripts``
-*******************
-
-::
-
-  entry_points={
-      'console_scripts': [
-          'sample=sample:main',
-      ],
-  },
-
-Use ``console_script``
-:ref:`entry points `
-to register your script interfaces. You can then let the toolchain handle the
-work of turning these interfaces into actual scripts [2]_.  The scripts will be
-generated during the install of your :term:`distribution `.
-
-For more information, see :doc:`Entry Points `
-from the :doc:`setuptools docs `.
 
 .. _`Choosing a versioning scheme`:
 
@@ -956,10 +704,3 @@ your project to appear on the site.
        access. :ref:`pip` is currently considering changing this by `making user
        installs the default behavior
        `_.
-
-
-.. [2] Specifically, the "console_script" approach generates ``.exe`` files on
-       Windows, which are necessary because the OS special-cases ``.exe`` files.
-       Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for
-       Windows <397>` allow scripts to
-       be used in many cases, but not all.
diff --git a/source/guides/single-sourcing-package-version.rst b/source/guides/single-sourcing-package-version.rst
index 97a9cb026..e487e41e1 100644
--- a/source/guides/single-sourcing-package-version.rst
+++ b/source/guides/single-sourcing-package-version.rst
@@ -4,6 +4,7 @@
 Single-sourcing the package version
 ===================================
 
+.. todo:: Update this page for build backends other than setuptools.
 
 There are many techniques to maintain a single source of truth for the version
 number of your project:
diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index 41456da08..187a44d50 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -116,6 +116,8 @@ does it.
 Basic information
 =================
 
+.. _`setup() name`:
+
 ``name``
 --------
 
@@ -127,6 +129,16 @@ only field that cannot be marked as dynamic.
    [project]
    name = "spam-eggs"
 
+The project name must consists of ASCII letters, digits, underscores "``_``",
+hyphens "``-``" and periods "``.``". It must not start or end with an
+underscore, hyphen or period.
+
+Comparison of project names is case insensitive and treats arbitrarily long runs
+of underscores, hyphens, and/or periods as equal.  For example, if you register
+a project named ``cool-stuff``, users will be able to download it or declare a
+dependency on it using any of the following spellings: ``Cool-Stuff``,
+``cool.stuff``, ``COOL_STUFF``, ``CoOl__-.-__sTuFF``.
+
 
 ``version``
 -----------
@@ -149,6 +161,9 @@ This field is required, although it is often marked as dynamic using
    [project]
    dynamic = ["version"]
 
+This allows use cases such as filling the version from a ``__version__``
+attribute or a Git tag. Consult :ref:`Single sourcing the version` for more
+details.
 
 
 Dependencies and requirements
@@ -190,6 +205,9 @@ could use, e.g., ``pip install your-project-name[gui]`` to install your
 project with GUI support, adding the PyQt5 dependency.
 
 
+.. _requires-python:
+.. _python_requires:
+
 ``requires-python``
 -------------------
 
@@ -202,6 +220,7 @@ This lets you declare the minimum version of Python that you support
    requires-python = ">= 3.8"
 
 
+.. _`console_scripts`:
 
 Creating executable scripts
 ===========================
@@ -259,11 +278,14 @@ an email address.
     ]
 
 
+.. _description:
+
 ``description``
 ---------------
 
-This should be a one-line description of your project, to show as the
-"headline" of your project page on PyPI (`example `_).
+This should be a one-line description of your project, to show as the "headline"
+of your project page on PyPI (`example `_), and other places such as
+lists of search results (`example `_).
 
 .. code-block:: toml
 
@@ -285,8 +307,8 @@ page on PyPI. Typically, your project will have a ``README.md`` or
 
 The README's format is auto-detected from the extension:
 
-- ``README.md`` → Markdown,
-- ``README.rst`` → reStructuredText (without Sphinx extensions).
+- ``README.md`` → `GitHub-flavored Markdown `_,
+- ``README.rst`` → `reStructuredText `_ (without Sphinx extensions).
 
 You can also specify the format explicitly, like this:
 
@@ -311,12 +333,16 @@ This can take two forms. You can put your license in a file, typically
 
 or you can write the name of the license:
 
-
 .. code-block:: toml
 
     [project]
     license = {text = "MIT License"}
 
+If you are using a standard, well-known license, it is not necessary to use this
+field. Instead, you should one of the :ref:`classifiers` starting with ``License
+::``. (As a general rule, it is a good idea to use a standard, well-known
+license, both to avoid confusion and because some organizations avoid software
+whose license is unapproved.)
 
 
 ``keywords``
@@ -331,6 +357,8 @@ search for these keywords.
     keywords = ["egg", "bacon", "sausage", "tomatoes", "Lobster Thermidor"]
 
 
+.. _classifiers:
+
 ``classifiers``
 ---------------
 
@@ -340,10 +368,36 @@ A list of PyPI classifiers that apply to your project. Check the
 .. code-block:: toml
 
     classifiers = [
+      # How mature is this project? Common values are
+      #   3 - Alpha
+      #   4 - Beta
+      #   5 - Production/Stable
       "Development Status :: 4 - Beta",
-      "Programming Language :: Python"
+
+      # Indicate who your project is intended for
+      "Intended Audience :: Developers",
+      "Topic :: Software Development :: Build Tools",
+
+      # Pick your license as you wish (see also "license" above)
+      "License :: OSI Approved :: MIT License",
+
+      # Specify the Python versions you support here.
+      "Programming Language :: Python :: 3",
+      "Programming Language :: Python :: 3.6",
+      "Programming Language :: Python :: 3.7",
+      "Programming Language :: Python :: 3.8",
+      "Programming Language :: Python :: 3.9",
     ]
 
+Although the list of classifiers is often used to declare what Python versions a
+project supports, this information is only used for searching and browsing
+projects on PyPI, not for installing projects. To actually restrict what Python
+versions a project can be installed on, use the :ref:`requires-python` argument.
+
+To prevent a package from being uploaded to PyPI, use the special ``Private ::
+Do Not Upload`` classifier. PyPI will always reject packages with classifiers
+beginning with ``Private ::``.
+
 
 ``urls``
 --------
@@ -353,12 +407,12 @@ sidebar of your PyPI project page.
 
 .. code-block:: toml
 
-    [project.urls]
-    Homepage = "https://example.com"
-    Documentation = "https://readthedocs.org"
-    Repository = "https://github.com/me/spam.git"
-    Issues = "https://github.com/me/spam/issues"
-    Changelog = "https://github.com/me/spam/blob/master/CHANGELOG.md"
+   [project.urls]
+   Homepage = "https://example.com"
+   Documentation = "https://readthedocs.org"
+   Repository = "https://github.com/me/spam.git"
+   Issues = "https://github.com/me/spam/issues"
+   Changelog = "https://github.com/me/spam/blob/master/CHANGELOG.md"
 
 Note that if the key contains spaces, it needs to be quoted, e.g.,
 ``Website = "https://example.com"`` but
@@ -449,10 +503,13 @@ A full example
    like ``requires-python = "<= 3.10"`` here. `This blog post `_
    contains some information regarding possible problems.
 
+.. _gfm: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax
 .. _setuptools: https://setuptools.pypa.io
 .. _poetry: https://python-poetry.org
 .. _pypi-pip: https://pypi.org/project/pip
+.. _pypi-search-pip: https://pypi.org/search?q=pip
 .. _classifier-list: https://pypi.org/classifiers
 .. _requires-python-blog-post: https://iscinumpy.dev/post/bound-version-constraints/#pinning-the-python-version-is-special
 .. _pytest: https://pytest.org
 .. _pygments: https://pygments.org
+.. _rest: https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html

From 7ce88369411e819ee141692e7d1ba190e1d3873a Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Thu, 14 Dec 2023 13:48:47 +0100
Subject: [PATCH 0575/1072] Typo fix (closes #1416)

---
 source/specifications/version-specifiers.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/version-specifiers.rst b/source/specifications/version-specifiers.rst
index acf3167c7..91b6fa60b 100644
--- a/source/specifications/version-specifiers.rst
+++ b/source/specifications/version-specifiers.rst
@@ -883,7 +883,7 @@ Prefix matching may be requested instead of strict comparison, by appending
 a trailing ``.*`` to the version identifier in the version matching clause.
 This means that additional trailing segments will be ignored when
 determining whether or not a version identifier matches the clause. If the
-specified version includes only a release segment, than trailing components
+specified version includes only a release segment, then trailing components
 (or the lack thereof) in the release segment are also ignored.
 
 For example, given the version ``1.1.post1``, the following clauses would

From 034a9f2ff988b9a614398cf7cd4661ae9be97034 Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Thu, 14 Dec 2023 18:53:19 +0100
Subject: [PATCH 0576/1072] Use reST document metadata

Co-authored-by: chrysle 
---
 source/guides/distributing-packages-using-setuptools.rst | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst
index e0ab11cc0..2c1a0a7c0 100644
--- a/source/guides/distributing-packages-using-setuptools.rst
+++ b/source/guides/distributing-packages-using-setuptools.rst
@@ -4,10 +4,8 @@
 Packaging and distributing projects
 ===================================
 
-.. warning::
-   As of December 2023, this page is largely outdated
-   and currently being revised.
-
+:Page Status: Outdated
+:Last Reviewed: 2023-12-14
 This section covers some additional details on configuring, packaging and
 distributing Python projects with ``setuptools`` that aren't covered by the
 introductory tutorial in :doc:`/tutorials/packaging-projects`.  It still assumes

From 1e6f244c580b1ff86497c8057a4b05614d89c386 Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Thu, 14 Dec 2023 18:56:29 +0100
Subject: [PATCH 0577/1072] Add missing newline

---
 source/guides/distributing-packages-using-setuptools.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst
index 2c1a0a7c0..e14048126 100644
--- a/source/guides/distributing-packages-using-setuptools.rst
+++ b/source/guides/distributing-packages-using-setuptools.rst
@@ -5,6 +5,7 @@ Packaging and distributing projects
 ===================================
 
 :Page Status: Outdated
+
 :Last Reviewed: 2023-12-14
 This section covers some additional details on configuring, packaging and
 distributing Python projects with ``setuptools`` that aren't covered by the

From 00b7bfc7796ddeb80f461878b9a3946ec82eef58 Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Thu, 14 Dec 2023 19:01:29 +0100
Subject: [PATCH 0578/1072] Add the newline at the right place...

Co-authored-by: chrysle 
---
 source/guides/distributing-packages-using-setuptools.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst
index e14048126..f6e41075d 100644
--- a/source/guides/distributing-packages-using-setuptools.rst
+++ b/source/guides/distributing-packages-using-setuptools.rst
@@ -5,8 +5,8 @@ Packaging and distributing projects
 ===================================
 
 :Page Status: Outdated
-
 :Last Reviewed: 2023-12-14
+
 This section covers some additional details on configuring, packaging and
 distributing Python projects with ``setuptools`` that aren't covered by the
 introductory tutorial in :doc:`/tutorials/packaging-projects`.  It still assumes

From 38675a15eeb7d1b03a1f1d16617d7ccef164179c Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Thu, 14 Dec 2023 22:19:00 +0100
Subject: [PATCH 0579/1072] Address review comments

---
 .../distribution-package-vs-import-package.rst         | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/source/discussions/distribution-package-vs-import-package.rst b/source/discussions/distribution-package-vs-import-package.rst
index 967328620..36f11d963 100644
--- a/source/discussions/distribution-package-vs-import-package.rst
+++ b/source/discussions/distribution-package-vs-import-package.rst
@@ -44,13 +44,15 @@ package that provides it.
 What are the links between distribution packages and import packages?
 =====================================================================
 
-By convention, a distribution package usually provides one single import
+Most of the time, a distribution package provides one single import
 package (or non-package module), with a matching name. For example,
 ``pip install numpy`` lets you ``import numpy``.
 
-However, this is only a convention. PyPI and other package indices do
-not enforce any relationship between the name of a distribution package
-and the import packages it provides.
+However, this is only a convention. PyPI and other package indices *do not
+enforce any relationship* between the name of a distribution package and the
+import packages it provides. (A consequence of this is that you cannot blindly
+install the PyPI package ``foo`` if you see ``import foo``; this may install an
+unintended, and potentially even malicious package.)
 
 A distribution package could provide an import package with a different
 name. An example of this is the popular Pillow_ library for image

From 071b8105da399c2382542e0648b0d594c9bc3638 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Skytt=C3=A4?= 
Date: Fri, 15 Dec 2023 16:51:37 +0200
Subject: [PATCH 0580/1072] Update nox config filename

`noxfile.py` since
https://github.com/wntrblm/nox/releases/tag/2018.8.23
---
 source/discussions/setup-py-deprecated.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/setup-py-deprecated.rst b/source/discussions/setup-py-deprecated.rst
index c4d7258b4..4993d8a0d 100644
--- a/source/discussions/setup-py-deprecated.rst
+++ b/source/discussions/setup-py-deprecated.rst
@@ -12,7 +12,7 @@ for packaging Python projects.
 And :file:`setup.py` is a valid configuration file for :ref:`setuptools`
 that happens to be written in Python, instead of in *TOML* for example
 (a similar practice is used by other tools
-like *nox* and its :file:`nox.py` configuration file,
+like *nox* and its :file:`noxfile.py` configuration file,
 or *pytest* and :file:`conftest.py`).
 
 However, ``python setup.py`` and the use of :file:`setup.py`

From d4164d2d1b8b2f04f2c5961af5e388ef42974c2b Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Sat, 16 Dec 2023 08:26:54 +0100
Subject: [PATCH 0581/1072] The PyPI
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/discussions/distribution-package-vs-import-package.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/distribution-package-vs-import-package.rst b/source/discussions/distribution-package-vs-import-package.rst
index 36f11d963..005f65d14 100644
--- a/source/discussions/distribution-package-vs-import-package.rst
+++ b/source/discussions/distribution-package-vs-import-package.rst
@@ -16,7 +16,7 @@ A distribution package is a piece of software that you can install.
 Most of the time, this is synonymous with "project". When you type ``pip
 install pkg``, or when you write ``dependencies = ["pkg"]`` in your
 ``pyproject.toml``, ``pkg`` is the name of a distribution package. When
-you search or browse PyPI_, the most widely known centralized source for
+you search or browse the PyPI_, the most widely known centralized source for
 installing Python software, what you see is a list of distribution
 packages. Alternatively, the term "distribution package" can be used to
 refer to a specific file that contains a certain version of a project.

From 62273fef03a2a6e678f5bd5af3478914233191d7 Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Sat, 16 Dec 2023 08:28:42 +0100
Subject: [PATCH 0582/1072] Python software -> Python libraries and tools

---
 source/discussions/distribution-package-vs-import-package.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/distribution-package-vs-import-package.rst b/source/discussions/distribution-package-vs-import-package.rst
index 005f65d14..8d847cca7 100644
--- a/source/discussions/distribution-package-vs-import-package.rst
+++ b/source/discussions/distribution-package-vs-import-package.rst
@@ -17,7 +17,7 @@ Most of the time, this is synonymous with "project". When you type ``pip
 install pkg``, or when you write ``dependencies = ["pkg"]`` in your
 ``pyproject.toml``, ``pkg`` is the name of a distribution package. When
 you search or browse the PyPI_, the most widely known centralized source for
-installing Python software, what you see is a list of distribution
+installing Python libraries and tools, what you see is a list of distribution
 packages. Alternatively, the term "distribution package" can be used to
 refer to a specific file that contains a certain version of a project.
 

From bbbab1a4bee5c1332ce9326015a2108429a7f8ac Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Sat, 16 Dec 2023 08:47:11 +0100
Subject: [PATCH 0583/1072] Clarify reference to Linux distro packages

---
 .../discussions/distribution-package-vs-import-package.rst | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/source/discussions/distribution-package-vs-import-package.rst b/source/discussions/distribution-package-vs-import-package.rst
index 8d847cca7..b00e3bde2 100644
--- a/source/discussions/distribution-package-vs-import-package.rst
+++ b/source/discussions/distribution-package-vs-import-package.rst
@@ -21,8 +21,10 @@ installing Python libraries and tools, what you see is a list of distribution
 packages. Alternatively, the term "distribution package" can be used to
 refer to a specific file that contains a certain version of a project.
 
-Note that in the Linux world, "distribution package" refers to a package
-provided by the system package manager, which is a different meaning.
+Note that in the Linux world, a "distribution package",
+most commonly abbreviated as "distro package" or just "package",
+is something provided by the system package manager of the `Linux distribution `_,
+which is a different meaning.
 
 
 What's an import package?
@@ -93,6 +95,7 @@ precise rules are given in the :ref:`name normalization specification
 `).
 
 
+.. _distro: https://en.wikipedia.org/wiki/Linux_distribution
 .. _PyPI: https://pypi.org
 .. _Pillow: https://pypi.org/project/Pillow
 .. _attrs: https://pypi.org/project/attrs

From 0335a1fbca21752135619e689ecc580dc78737d0 Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Sat, 16 Dec 2023 08:55:29 +0100
Subject: [PATCH 0584/1072] Add importlib pointer

---
 .../distribution-package-vs-import-package.rst       | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/source/discussions/distribution-package-vs-import-package.rst b/source/discussions/distribution-package-vs-import-package.rst
index b00e3bde2..663225bcc 100644
--- a/source/discussions/distribution-package-vs-import-package.rst
+++ b/source/discussions/distribution-package-vs-import-package.rst
@@ -82,7 +82,7 @@ How do distribution package names and import package names compare?
 
 Import packages should have valid Python identifiers as their name (the
 :ref:`exact rules ` are found in the Python
-documentation). In particular, they use underscores ``_`` as word
+documentation) #[non-identifier-mod-name]_. In particular, they use underscores ``_`` as word
 separator and they are case-sensitive.
 
 On the other hand, distribution packages can use hyphens ``-`` or
@@ -95,6 +95,16 @@ precise rules are given in the :ref:`name normalization specification
 `).
 
 
+
+-
+---------------------------
+
+.. [#non-identifier-mod-name] Although is technically possible
+   to import packages/modules that do not have a valid Python identifier as
+   their name, using :doc:`importlib `,
+   this is vanishingly rare and strongly discouraged.
+
+
 .. _distro: https://en.wikipedia.org/wiki/Linux_distribution
 .. _PyPI: https://pypi.org
 .. _Pillow: https://pypi.org/project/Pillow

From 3b42e3f98a9737a2e26ddd78f0a4569539bc6a45 Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Sat, 16 Dec 2023 09:02:50 +0100
Subject: [PATCH 0585/1072] Syntax fixes

---
 source/discussions/distribution-package-vs-import-package.rst | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/source/discussions/distribution-package-vs-import-package.rst b/source/discussions/distribution-package-vs-import-package.rst
index 663225bcc..d4a754310 100644
--- a/source/discussions/distribution-package-vs-import-package.rst
+++ b/source/discussions/distribution-package-vs-import-package.rst
@@ -82,7 +82,7 @@ How do distribution package names and import package names compare?
 
 Import packages should have valid Python identifiers as their name (the
 :ref:`exact rules ` are found in the Python
-documentation) #[non-identifier-mod-name]_. In particular, they use underscores ``_`` as word
+documentation) [#non-identifier-mod-name]_. In particular, they use underscores ``_`` as word
 separator and they are case-sensitive.
 
 On the other hand, distribution packages can use hyphens ``-`` or
@@ -96,7 +96,6 @@ precise rules are given in the :ref:`name normalization specification
 
 
 
--
 ---------------------------
 
 .. [#non-identifier-mod-name] Although is technically possible

From 9b3655c495b0ca8f8634b48d5b558b8625bd8999 Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Sat, 16 Dec 2023 09:08:02 +0100
Subject: [PATCH 0586/1072] Missing word

---
 source/discussions/distribution-package-vs-import-package.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/distribution-package-vs-import-package.rst b/source/discussions/distribution-package-vs-import-package.rst
index d4a754310..65e7019c6 100644
--- a/source/discussions/distribution-package-vs-import-package.rst
+++ b/source/discussions/distribution-package-vs-import-package.rst
@@ -98,7 +98,7 @@ precise rules are given in the :ref:`name normalization specification
 
 ---------------------------
 
-.. [#non-identifier-mod-name] Although is technically possible
+.. [#non-identifier-mod-name] Although it is technically possible
    to import packages/modules that do not have a valid Python identifier as
    their name, using :doc:`importlib `,
    this is vanishingly rare and strongly discouraged.

From 3820102558ba6b26c25f3348608a03c3b12c66d4 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sun, 17 Dec 2023 13:10:26 +0100
Subject: [PATCH 0587/1072] Create a discussion on versioning

Move content on versioning schemes from
distributing-packages-using-setuptools.rst to a new discussion on
versioning, and update it.
---
 source/discussions/index.rst                  |   1 +
 source/discussions/versioning.rst             | 139 ++++++++++++++++++
 ...distributing-packages-using-setuptools.rst | 119 ---------------
 source/specifications/version-specifiers.rst  |   2 +
 4 files changed, 142 insertions(+), 119 deletions(-)
 create mode 100644 source/discussions/versioning.rst

diff --git a/source/discussions/index.rst b/source/discussions/index.rst
index b378ed810..4a14fbfba 100644
--- a/source/discussions/index.rst
+++ b/source/discussions/index.rst
@@ -8,6 +8,7 @@ specific topic. If you're just trying to get stuff done, see
 .. toctree::
    :maxdepth: 1
 
+   versioning
    deploying-python-applications
    pip-vs-easy-install
    install-requires-vs-requirements
diff --git a/source/discussions/versioning.rst b/source/discussions/versioning.rst
new file mode 100644
index 000000000..c901ff345
--- /dev/null
+++ b/source/discussions/versioning.rst
@@ -0,0 +1,139 @@
+.. _versioning:
+.. _`Choosing a versioning scheme`:
+
+==========
+Versioning
+==========
+
+This discussion covers all aspects of versioning Python packages.
+
+
+Valid version numbers
+=====================
+
+Different Python projects may use different versioning schemes based on the
+needs of that particular project, but in order to be compatible with tools like
+:ref:`pip`, all of them are required to comply with a flexible format for
+version identifiers, for which the authoritative reference is the
+:ref:`specification of version specifiers `. Here are some
+examples of version numbers:
+
+.. code-block:: text
+
+  1.2.0.dev1  # Development release
+  1.2.0a1     # Alpha Release
+  1.2.0b1     # Beta Release
+  1.2.0rc1    # Release Candidate
+  1.2.0       # Final Release
+  1.2.0.post1 # Post Release
+  15.10       # Date based release
+  23          # Serial release
+
+
+Semantic versioning vs. calendar versioning
+===========================================
+
+A versioning scheme is a way to interpret version numbers of a package, and to
+decide which should be the next version number for a new release of a package.
+Two versioning schemes are commonly used for Python packages, semantic
+versioning and calendar versioning.
+
+Semantic versioning is recommended for most new projects.
+
+Semantic versioning
+-------------------
+
+The idea of *semantic versioning* is to use 3-part version numbers,
+*major.minor.maintenance*, where the project author increments:
+
+- *major* when they make incompatible API changes,
+- *minor* when they add functionality in a backwards-compatible manner, and
+- *maintenance*, when they make backwards-compatible bug fixes.
+
+Note that many projects, especially larger ones, do not use strict semantic
+versioning since many changes are technically breaking changes but affect only a
+small fraction of users. Such projects tend to increment the major number when
+the incompatibility is high, rather than for any tiny incompatibility, or to
+signal a shift in the project.
+
+For those projects that do adhere to semantic versioning strictly, this approach
+allows users to make use of :ref:`compatible release version specifiers
+`, with the ``~=`` operator.  For
+example, ``name ~= X.Y`` is roughly equivalent to ``name >= X.Y, == X.*``, i.e.,
+it requires at least release X.Y, and allows any later release with greater Y as
+long as X is the same. Likewise, ``name ~= X.Y.Z`` is roughly equivalent to
+``name >= X.Y.Z, == X.Y.*``, i.e., it requires at least X.Y.Z and allows a later
+release with same X and Y but higher Z.
+
+Python projects adopting semantic versioning should abide by clauses 1-8 of the
+`Semantic Versioning 2.0.0 specification `_.
+
+
+Calendar versioning
+-------------------
+
+Semantic versioning is not a suitable choice for all projects, such as those
+with a regular time based release cadence and a deprecation process that
+provides warnings for a number of releases prior to removal of a feature.
+
+A key advantage of date-based versioning, or `calendar versioning `_,
+is that it is straightforward to tell how old the base feature set of a
+particular release is given just the version number.
+
+Calendar version numbers typically take the form *year.month* (for example,
+23.10 for December 2023).
+
+
+Other schemes
+-------------
+
+Serial versioning refers to the simplest possible versioning scheme, which
+consists of a single number incremented every release. While serial versioning
+is very easy to manage as a developer, it is the hardest to track as an end
+user, as serial version numbers convey little or no information regarding API
+backwards compatibility.
+
+Combinations of the above schemes are possible. For example, a project may
+combine date based versioning with serial versioning to create a *year.serial*
+numbering scheme that readily conveys the approximate age of a release, but
+doesn't otherwise commit to a particular release cadence within the year.
+
+
+
+Pre-release versioning
+======================
+
+Regardless of the base versioning scheme, pre-releases for a given final release
+may be published as:
+
+* Zero or more dev releases, denoted with a ".devN" suffix,
+* Zero or more alpha releases, denoted with a ".aN" suffix,
+* Zero or more beta releases, denoted with a ".bN" suffix,
+* Zero or more release candidates, denoted with a ".rcN" suffix.
+
+Pip and other modern Python package installers ignore pre-releases by default
+when deciding which versions of dependencies to install.
+
+
+Local version identifiers
+=========================
+
+Public version identifiers are designed to support distribution via :term:`PyPI
+`. Python packaging tools also support the notion
+of a :ref:`local version identifier `, which can be
+used to identify local development builds not intended for publication, or
+modified variants of a release maintained by a redistributor.
+
+A local version identifier takes the form of a public version identifier,
+followed by "+" and a local version label. For example:
+
+.. code-block:: text
+
+   1.2.0.dev1+hg.5.b11e5e6f0b0b  # 5th VCS commit since 1.2.0.dev1 release
+   1.2.1+fedora.4                # Package with downstream Fedora patches applied
+
+
+
+
+.. _calver: https://calver.org
+.. _semver: https://semver.org
diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst
index f6e41075d..8e9ed564b 100644
--- a/source/guides/distributing-packages-using-setuptools.rst
+++ b/source/guides/distributing-packages-using-setuptools.rst
@@ -288,125 +288,6 @@ points (see below).
 
 
 
-
-.. _`Choosing a versioning scheme`:
-
-Choosing a versioning scheme
-----------------------------
-
-Standards compliance for interoperability
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Different Python projects may use different versioning schemes based on the needs of that
-particular project, but all of them are required to comply with the flexible :pep:`public version
-scheme <440#public-version-identifiers>` specified
-in :pep:`440` in order to be supported in tools and libraries like ``pip``
-and ``setuptools``.
-
-Here are some examples of compliant version numbers::
-
-  1.2.0.dev1  # Development release
-  1.2.0a1     # Alpha Release
-  1.2.0b1     # Beta Release
-  1.2.0rc1    # Release Candidate
-  1.2.0       # Final Release
-  1.2.0.post1 # Post Release
-  15.10       # Date based release
-  23          # Serial release
-
-To further accommodate historical variations in approaches to version numbering,
-:pep:`440` also defines a comprehensive technique for :pep:`version
-normalisation <440#normalization>` that maps
-variant spellings of different version numbers to a standardised canonical form.
-
-Scheme choices
-~~~~~~~~~~~~~~
-
-Semantic versioning (preferred)
-*******************************
-
-For new projects, the recommended versioning scheme is based on `Semantic Versioning
-`_, but adopts a different approach to handling pre-releases and
-build metadata.
-
-The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme,
-where the project author increments:
-
-1. MAJOR version when they make incompatible API changes,
-2. MINOR version when they add functionality in a backwards-compatible manner, and
-3. MAINTENANCE version when they make backwards-compatible bug fixes.
-
-Adopting this approach as a project author allows users to make use of :pep:`"compatible release"
-<440#compatible-release>` specifiers, where
-``name ~= X.Y`` requires at least release X.Y, but also allows any later release with
-a matching MAJOR version.
-
-Python projects adopting semantic versioning should abide by clauses 1-8 of the
-`Semantic Versioning 2.0.0 specification `_.
-
-Date based versioning
-*********************
-
-Semantic versioning is not a suitable choice for all projects, such as those with a regular
-time based release cadence and a deprecation process that provides warnings for a number of
-releases prior to removal of a feature.
-
-A key advantage of date based versioning is that it is straightforward to tell how old the
-base feature set of a particular release is given just the version number.
-
-Version numbers for date based projects typically take the form of YEAR.MONTH (for example,
-``12.04``, ``15.10``).
-
-Serial versioning
-*****************
-
-This is the simplest possible versioning scheme, and consists of a single number which is
-incremented every release.
-
-While serial versioning is very easy to manage as a developer, it is the hardest to track
-as an end user, as serial version numbers convey little or no information regarding API
-backwards compatibility.
-
-Hybrid schemes
-**************
-
-Combinations of the above schemes are possible. For example, a project may combine date
-based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that
-readily conveys the approximate age of a release, but doesn't otherwise commit to a particular
-release cadence within the year.
-
-Pre-release versioning
-~~~~~~~~~~~~~~~~~~~~~~
-
-Regardless of the base versioning scheme, pre-releases for a given final release may be
-published as:
-
-* zero or more dev releases (denoted with a ".devN" suffix)
-* zero or more alpha releases (denoted with a ".aN" suffix)
-* zero or more beta releases (denoted with a ".bN" suffix)
-* zero or more release candidates (denoted with a ".rcN" suffix)
-
-``pip`` and other modern Python package installers ignore pre-releases by default when
-deciding which versions of dependencies to install.
-
-
-Local version identifiers
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Public version identifiers are designed to support distribution via
-:term:`PyPI `. Python's software distribution tools also support
-the notion of a :pep:`local version identifier
-<440#local-version-identifiers>`, which can be used to
-identify local development builds not intended for publication, or modified variants of a release
-maintained by a redistributor.
-
-A local version identifier takes the form ``+``.
-For example::
-
-   1.2.0.dev1+hg.5.b11e5e6f0b0b  # 5th VCS commit since 1.2.0.dev1 release
-   1.2.1+fedora.4                # Package with downstream Fedora patches applied
-
-
 Working in "development mode"
 =============================
 
diff --git a/source/specifications/version-specifiers.rst b/source/specifications/version-specifiers.rst
index 202031758..6fe9ffccd 100644
--- a/source/specifications/version-specifiers.rst
+++ b/source/specifications/version-specifiers.rst
@@ -108,6 +108,8 @@ aside from always being the lowest possible value in the version ordering.
    sections.
 
 
+.. _local-version-identifiers:
+
 Local version identifiers
 -------------------------
 

From b5d2d8d658779aa1e9587f1afc319bfeee8ad45a Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sun, 17 Dec 2023 20:39:14 +0100
Subject: [PATCH 0588/1072] Address review comments

---
 source/conf.py                                |   1 +
 source/discussions/versioning.rst             | 102 ++++++++++++------
 ...distributing-packages-using-setuptools.rst |   6 ++
 3 files changed, 74 insertions(+), 35 deletions(-)

diff --git a/source/conf.py b/source/conf.py
index 0e3a93d5e..e61a32451 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -143,6 +143,7 @@
     "flexx": ("https://flexx.readthedocs.io/en/latest/", None),
     "flit": ("https://flit.pypa.io/en/stable/", None),
     "nox": ("https://nox.thea.codes/en/latest/", None),
+    "numpy": ("https://numpy.org/doc/stable/", None),
     "openstack": ("https://docs.openstack.org/glance/latest/", None),
     "packaging": ("https://packaging.pypa.io/en/latest/", None),
     "pip": ("https://pip.pypa.io/en/latest/", None),
diff --git a/source/discussions/versioning.rst b/source/discussions/versioning.rst
index c901ff345..082dd1716 100644
--- a/source/discussions/versioning.rst
+++ b/source/discussions/versioning.rst
@@ -18,27 +18,47 @@ version identifiers, for which the authoritative reference is the
 :ref:`specification of version specifiers `. Here are some
 examples of version numbers:
 
-.. code-block:: text
-
-  1.2.0.dev1  # Development release
-  1.2.0a1     # Alpha Release
-  1.2.0b1     # Beta Release
-  1.2.0rc1    # Release Candidate
-  1.2.0       # Final Release
-  1.2.0.post1 # Post Release
-  15.10       # Date based release
-  23          # Serial release
+- A simple version (final release): 1.2.0
+- A development release: 1.2.0.dev1
+- An alpha release: 1.2.0a1
+- A beta release: 1.2.0b1
+- A release candidate: 1.2.0rc1
+- A post-release: 1.2.0.post1
+- A post-release of an alpha release (possible, but discouraged): 1.2.0a1.post1
+- A simple version with only two components: 23.12
+- A simple version with just one component (possible, but discouraged): 42
+- A version with an epoch: 1!1.0
+
+Projects can use a cycle of pre-releases to support testing by their users
+before a final release. In order, the steps are: alpha releases, beta releases,
+release candidates, final release.
+
+The purpose of development releases is to support releases made early during a
+development cycle, for example, a nightly build, or a build from the latest
+source in a Linux distribution.
+
+Post-releases are used to address minor errors in a final release that do not
+affect the distributed software, such as correcting an error in the release
+notes. They should not be used for bug fixes; these should be done with a new
+final release (e.g., incrementing the third component when using semantic
+versioning).
+
+Finally, epochs, a rarely used feature, serve to fix the sorting order when
+changing the versioning scheme. For example, if a project is using calendar
+versioning, with versions like 23.12, and switches to semantic versioning, with
+versions like 1.0, the comparison between 1.0 and 23.12 will go the wrong way.
+To correct this, the new version numbers should have an explicit epoch, as in
+"1!1.0", in order to be treated as more recent than the old version numbers.
 
 
 Semantic versioning vs. calendar versioning
 ===========================================
 
-A versioning scheme is a way to interpret version numbers of a package, and to
-decide which should be the next version number for a new release of a package.
-Two versioning schemes are commonly used for Python packages, semantic
-versioning and calendar versioning.
+A versioning scheme is a formalized way to interpret the segments of a version
+number, and to decide which should be the next version number for a new release
+of a package. Two versioning schemes are commonly used for Python packages,
+semantic versioning and calendar versioning.
 
-Semantic versioning is recommended for most new projects.
 
 Semantic versioning
 -------------------
@@ -50,14 +70,15 @@ The idea of *semantic versioning* is to use 3-part version numbers,
 - *minor* when they add functionality in a backwards-compatible manner, and
 - *maintenance*, when they make backwards-compatible bug fixes.
 
-Note that many projects, especially larger ones, do not use strict semantic
-versioning since many changes are technically breaking changes but affect only a
-small fraction of users. Such projects tend to increment the major number when
-the incompatibility is high, rather than for any tiny incompatibility, or to
-signal a shift in the project.
+A majority of Python projects use a scheme that resembles semantic
+versioning. However, most projects, especially larger ones, do not strictly
+adhere to semantic versioning, since many changes are technically breaking
+changes but affect only a small fraction of users. Such projects tend to
+increment the major number when the incompatibility is high, or to signal a
+shift in the project, rather than for any tiny incompatibility,
 
-For those projects that do adhere to semantic versioning strictly, this approach
-allows users to make use of :ref:`compatible release version specifiers
+For those projects that do use strict semantic versioning, this approach allows
+users to make use of :ref:`compatible release version specifiers
 `, with the ``~=`` operator.  For
 example, ``name ~= X.Y`` is roughly equivalent to ``name >= X.Y, == X.*``, i.e.,
 it requires at least release X.Y, and allows any later release with greater Y as
@@ -68,6 +89,13 @@ release with same X and Y but higher Z.
 Python projects adopting semantic versioning should abide by clauses 1-8 of the
 `Semantic Versioning 2.0.0 specification `_.
 
+The popular :doc:`Sphinx ` documentation generator is an example
+project that uses strict semantic versioning (:doc:`Sphinx versioning policy
+`). The famous :doc:`NumPy `
+scientific computing package explicitly uses "loose" semantic versioning, where
+releases incrementing the minor version can contain backwards-incompatible API
+changes (:doc:`NumPy versioning policy `).
+
 
 Calendar versioning
 -------------------
@@ -81,7 +109,10 @@ is that it is straightforward to tell how old the base feature set of a
 particular release is given just the version number.
 
 Calendar version numbers typically take the form *year.month* (for example,
-23.10 for December 2023).
+23.12 for December 2023).
+
+:doc:`Pip `, the standard Python package installer, uses calendar
+versioning.
 
 
 Other schemes
@@ -107,12 +138,13 @@ Regardless of the base versioning scheme, pre-releases for a given final release
 may be published as:
 
 * Zero or more dev releases, denoted with a ".devN" suffix,
-* Zero or more alpha releases, denoted with a ".aN" suffix,
-* Zero or more beta releases, denoted with a ".bN" suffix,
-* Zero or more release candidates, denoted with a ".rcN" suffix.
+* Zero or more alpha releases, denoted with a "aN" suffix,
+* Zero or more beta releases, denoted with a "bN" suffix,
+* Zero or more release candidates, denoted with a "rcN" suffix.
 
 Pip and other modern Python package installers ignore pre-releases by default
-when deciding which versions of dependencies to install.
+when deciding which versions of dependencies to install, unless explicitly
+requested, e.g., with ``pip install pkg==1.1a3``.
 
 
 Local version identifiers
@@ -125,15 +157,15 @@ used to identify local development builds not intended for publication, or
 modified variants of a release maintained by a redistributor.
 
 A local version identifier takes the form of a public version identifier,
-followed by "+" and a local version label. For example:
-
-.. code-block:: text
-
-   1.2.0.dev1+hg.5.b11e5e6f0b0b  # 5th VCS commit since 1.2.0.dev1 release
-   1.2.1+fedora.4                # Package with downstream Fedora patches applied
-
-
+followed by "+" and a local version label. For example, a package with
+Fedora-specific patches applied could have the version "1.2.1+fedora.4".
+Another example is versions computed by setuptools-scm_, a setuptools plugin
+that reads the version from Git data. In a Git repository with some commits
+since the latest release, setuptools-scm generates a version like
+"0.5.dev1+gd00980f", or if the repository has untracked changes, like
+"0.5.dev1+gd00980f.d20231217".
 
 
 .. _calver: https://calver.org
 .. _semver: https://semver.org
+.. _setuptools-scm: https://setuptools-scm.readthedocs.io
diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst
index 8e9ed564b..bf4227aae 100644
--- a/source/guides/distributing-packages-using-setuptools.rst
+++ b/source/guides/distributing-packages-using-setuptools.rst
@@ -287,6 +287,12 @@ achieve cross-platform compatibility is to use :ref:`console_scripts` entry
 points (see below).
 
 
+Choosing a versioning scheme
+----------------------------
+
+See :ref:`versioning` for information on common version schemes and how to
+choose between them.
+
 
 Working in "development mode"
 =============================

From e99d27dfce0f6d8b93c019bb723e20a55871041e Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sun, 17 Dec 2023 20:45:15 +0100
Subject: [PATCH 0589/1072] Merge "Pre-release versioning" into "Valid version
 numbers"

---
 source/discussions/versioning.rst | 22 +++++-----------------
 1 file changed, 5 insertions(+), 17 deletions(-)

diff --git a/source/discussions/versioning.rst b/source/discussions/versioning.rst
index 082dd1716..a63d269bc 100644
--- a/source/discussions/versioning.rst
+++ b/source/discussions/versioning.rst
@@ -31,7 +31,10 @@ examples of version numbers:
 
 Projects can use a cycle of pre-releases to support testing by their users
 before a final release. In order, the steps are: alpha releases, beta releases,
-release candidates, final release.
+release candidates, final release. Pip and other modern Python package
+installers ignore pre-releases by default when deciding which versions of
+dependencies to install, unless explicitly requested (e.g., with
+``pip install pkg==1.1a3``).
 
 The purpose of development releases is to support releases made early during a
 development cycle, for example, a nightly build, or a build from the latest
@@ -51,6 +54,7 @@ To correct this, the new version numbers should have an explicit epoch, as in
 "1!1.0", in order to be treated as more recent than the old version numbers.
 
 
+
 Semantic versioning vs. calendar versioning
 ===========================================
 
@@ -131,22 +135,6 @@ doesn't otherwise commit to a particular release cadence within the year.
 
 
 
-Pre-release versioning
-======================
-
-Regardless of the base versioning scheme, pre-releases for a given final release
-may be published as:
-
-* Zero or more dev releases, denoted with a ".devN" suffix,
-* Zero or more alpha releases, denoted with a "aN" suffix,
-* Zero or more beta releases, denoted with a "bN" suffix,
-* Zero or more release candidates, denoted with a "rcN" suffix.
-
-Pip and other modern Python package installers ignore pre-releases by default
-when deciding which versions of dependencies to install, unless explicitly
-requested, e.g., with ``pip install pkg==1.1a3``.
-
-
 Local version identifiers
 =========================
 

From ece6b79a75f79df76c4cdffbd94d01c3f078e957 Mon Sep 17 00:00:00 2001
From: Noam Yorav-Raphael 
Date: Mon, 18 Dec 2023 11:19:47 +0200
Subject: [PATCH 0590/1072] Update glossary.rst: Update link to requirement
 specifier syntax to PEP 508

The current link doesn't actually give the syntax of the requirement specifier. PEP 508 is much better.
---
 source/glossary.rst | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/source/glossary.rst b/source/glossary.rst
index 9bfcbbd3f..d19c2f743 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -209,10 +209,8 @@ Glossary
     Requirement Specifier
 
        A format used by :ref:`pip` to install packages from a :term:`Package
-       Index`. For an EBNF diagram of the format, see the
-       `pkg_resources.Requirement
-       `_
-       entry in the :ref:`setuptools` docs. For example, "foo>=1.3" is a
+       Index`. For an EBNF diagram of the format, see `PEP 508
+       `_. For example, "foo>=1.3" is a
        requirement specifier, where "foo" is the project name, and the ">=1.3"
        portion is the :term:`Version Specifier`
 

From 21c754c1b978256162996cef6fe6052c8bcb5747 Mon Sep 17 00:00:00 2001
From: Noam Yorav-Raphael 
Date: Mon, 18 Dec 2023 15:09:30 +0200
Subject: [PATCH 0591/1072] Update glossary.rst - refer to
 `dependency-specifiers`

---
 source/glossary.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/glossary.rst b/source/glossary.rst
index d19c2f743..1f55871fa 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -209,8 +209,8 @@ Glossary
     Requirement Specifier
 
        A format used by :ref:`pip` to install packages from a :term:`Package
-       Index`. For an EBNF diagram of the format, see `PEP 508
-       `_. For example, "foo>=1.3" is a
+       Index`. For an EBNF diagram of the format, see :ref:`dependency-specifiers`.
+       For example, "foo>=1.3" is a
        requirement specifier, where "foo" is the project name, and the ">=1.3"
        portion is the :term:`Version Specifier`
 

From d1e7ac4729662c727803291a7738c480f077807d Mon Sep 17 00:00:00 2001
From: Mike Fiedler 
Date: Mon, 18 Dec 2023 12:52:47 -0500
Subject: [PATCH 0592/1072] docs: update testpypi guide for api token

With the upcoming change to require 2FA for all users (already enforced
on TestPyPI), update guidance to point the user in the right direction.

Signed-off-by: Mike Fiedler 
---
 source/guides/using-testpypi.rst | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/source/guides/using-testpypi.rst b/source/guides/using-testpypi.rst
index f2c4f07c6..1dbc82130 100644
--- a/source/guides/using-testpypi.rst
+++ b/source/guides/using-testpypi.rst
@@ -72,12 +72,13 @@ you're testing has dependencies:
 Setting up TestPyPI in :file:`.pypirc`
 --------------------------------------
 
-If you want to avoid entering your username, you can configure TestPyPI in
-your :file:`$HOME/.pypirc`:
+If you want to avoid being prompted for your username and password every time,
+you can configure TestPyPI in your :file:`$HOME/.pypirc`:
 
 .. code:: ini
 
     [testpypi]
-    username = 
+    username = __token__
+    password = 
 
 For more details, see the :ref:`specification ` for :file:`.pypirc`.

From d7f6d641e7ec677be4ad6d9fffe842912c12a302 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 18 Dec 2023 18:41:42 +0000
Subject: [PATCH 0593/1072] [pre-commit.ci] pre-commit autoupdate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

updates:
- [github.com/astral-sh/ruff-pre-commit: v0.1.7 → v0.1.8](https://github.com/astral-sh/ruff-pre-commit/compare/v0.1.7...v0.1.8)
---
 .pre-commit-config.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index ee15601ec..20eeadb57 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -34,7 +34,7 @@ repos:
   - id: rst-inline-touching-normal
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.1.7
+  rev: v0.1.8
   hooks:
     - id: ruff
     - id: ruff-format

From 390d4a8ce1dc1107ed3d1c803faf1e150d6afb9f Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Tue, 19 Dec 2023 12:07:48 +0100
Subject: [PATCH 0594/1072] Correct path to venv scripts on Windows

Fixes #1459
---
 .../guides/installing-using-pip-and-virtual-environments.rst  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst
index e6aa88471..e33615157 100644
--- a/source/guides/installing-using-pip-and-virtual-environments.rst
+++ b/source/guides/installing-using-pip-and-virtual-environments.rst
@@ -88,7 +88,7 @@ shell's ``PATH``.
 
     .. code-block:: bat
 
-        .venv\bin\Activate.bat
+        .venv\Scripts\Activate.bat
 
 To confirm the virtual environment is activated, check the location of your
 Python interpreter:
@@ -118,7 +118,7 @@ filepath that includes the ``.venv`` directory, by ending with the following:
 
     .. code-block:: bat
 
-        .venv\bin\python.exe
+        .venv\Scripts\python.exe
 
 
 While a virtual environment is activated, pip will install packages into that

From b3ce0245bc3f0fe8f36bffa4c48dcdaf00159f9c Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 15 Nov 2023 23:34:09 +0100
Subject: [PATCH 0595/1072] Add discussion of package formats, expanding "Wheel
 vs Egg" discussion

---
 source/discussions/index.rst                  |   2 +-
 source/discussions/package-formats.rst        | 193 ++++++++++++++++++
 source/discussions/wheel-vs-egg.rst           |  55 -----
 .../binary-distribution-format.rst            |   2 +
 4 files changed, 196 insertions(+), 56 deletions(-)
 create mode 100644 source/discussions/package-formats.rst
 delete mode 100644 source/discussions/wheel-vs-egg.rst

diff --git a/source/discussions/index.rst b/source/discussions/index.rst
index b378ed810..5033bf703 100644
--- a/source/discussions/index.rst
+++ b/source/discussions/index.rst
@@ -11,7 +11,7 @@ specific topic. If you're just trying to get stuff done, see
    deploying-python-applications
    pip-vs-easy-install
    install-requires-vs-requirements
-   wheel-vs-egg
    distribution-package-vs-import-package
+   package-formats
    src-layout-vs-flat-layout
    setup-py-deprecated
diff --git a/source/discussions/package-formats.rst b/source/discussions/package-formats.rst
new file mode 100644
index 000000000..6d4dee35c
--- /dev/null
+++ b/source/discussions/package-formats.rst
@@ -0,0 +1,193 @@
+.. _package-formats:
+
+===============
+Package Formats
+===============
+
+This page discusses the file formats that are used to distribute Python packages
+and the differences between them.
+
+You will find files in two formats on package indices such as PyPI_: **source
+distributions**, or **sdists** for short, and **binary distributions**, commonly
+called **wheels**.  For example, the `PyPI page for pip 23.3.1 `_
+lets you download two files, ``pip-23.3.1.tar.gz`` and
+``pip-23.3.1-py3-none-any.whl``.  The former is an sdist, the latter is a
+wheel. As explained below, these serve different purposes. When publishing a
+package on PyPI (or elsewhere), you should always upload both an sdist and one
+or more wheel.
+
+
+What is a source distribution?
+==============================
+
+Conceptually, a source distribution is an archive of the source code in raw
+form. Concretely, an sdist is a ``.tar.gz`` archive containing the source code
+plus an additional special file called ``PKG-INFO``, which holds the project
+metadata. The presence of this file helps packaging tools to be more efficient
+by not needing to compute the metadata themselves. The ``PKG-INFO`` file follows
+the format specified in :ref:`core-metadata` and is not intended to be written
+by hand [#core-metadata-format]_.
+
+You can thus inspect the contents of an sdist by unpacking it using standard
+tools to work with tar archives, such as ``tar -xvf`` on UNIX platforms (like
+Linux and macOS), or :ref:`the command line interface of Python's tarfile module
+` on any platform.
+
+Sdists serve several purposes in the packaging ecosystem. When :ref:`pip`, the
+standard Python package installer, cannot find a wheel to install, it will fall
+back on downloading a source distribution, compiling a wheel from it, and
+installing the wheel. Furthermore, sdists are often used as the package source
+by downstream packagers (such as Linux distributions, Conda, Homebrew and
+MacPorts on macOS, ...), who, for various reasons, may prefer them over, e.g.,
+pulling from a Git repository.
+
+A source distribution is recognized by its file name, which has the form
+:samp:`{package_name}-{version}.tar.gz`, e.g., ``pip-23.3.1.tar.gz``.
+
+.. TODO: provide clear guidance on whether sdists should contain docs and tests.
+   Discussion: https://discuss.python.org/t/should-sdists-include-docs-and-tests/14578
+
+If you want technical details on the sdist format, read the :ref:`sdist
+specification `.
+
+
+What is a wheel?
+================
+
+Conceptually, a wheel contains exactly the files that need to be copied when
+installing the package.
+
+There is a big difference between sdists and wheels for packages with
+:term:`extension modules `, written in compiled languages like
+C, C++ and Rust, which need to be compiled into platform-dependent machine code.
+With these packages, wheels do not contain source code (like C source files) but
+compiled, executable code (like ``.so`` files on Linux or DLLs on Windows).
+
+Furthermore, while there is only one sdist per version of a project, there may
+be many wheels. Again, this is most relevant in the context of extension
+modules. The compiled code of an extension module is tied to an operating system
+and processor architecture, and often also to the version of the Python
+interpreter (unless the :ref:`Python stable ABI ` is used).
+
+For pure-Python packages, the difference between sdists and wheels is less
+marked. There is normally one single wheel, for all platforms and Python
+versions.  Python is an interpreted language, which does not need ahead-of-time
+compilation, so wheels contain ``.py`` files just like sdists.
+
+If you are wondering about ``.pyc`` bytecode files: they are not included in
+wheels, since they are cheap to generate, and including them would unnecessarily
+force a huge number of packages to distribute one wheel per Python version
+instead of one single wheel. Instead, installers like :ref:`pip` generate them
+while installing the package.
+
+With that being said, there are still important differences between sdists and
+wheels, even for pure Python projects. Wheels are meant to contain exactly what
+is to be installed, and nothing more. In particular, wheels should never include
+tests and documentation, while sdists commonly do.  Also, the wheel format is
+more complex than sdist. For example, it includes a special file -- called
+``RECORD`` -- that lists all files in the wheel along with a hash of their
+content, as a safety check of the download's integrity.
+
+At a glance, you might wonder if wheels are really needed for "plain and basic"
+pure Python projects. Keep in mind that due to the flexibility of sdists,
+installers like pip cannot install from sdists directly -- they need to first
+build a wheel, by invoking the :term:`build backend` that the sdist specifies
+(the build backend may do all sorts of transformations while building the wheel,
+such as compiling C extensions). For this reason, even for a pure Python
+project, you should always upload *both* an sdist and a wheel to PyPI or other
+package indices. This makes installation much faster for your users, since a
+wheel is directly installable. By only including files that must be installed,
+wheels also make for smaller downloads.
+
+On the technical level, a wheel is a ZIP archive (unlike sdists which are TAR
+archives). You can inspect its contents by unpacking it as a normal ZIP archive,
+e.g., using ``unzip`` on UNIX platforms like Linux and macOS, ``Expand-Archive``
+in Powershell on Windows, or :ref:`the command line interface of Python's
+zipfile module `. This can be very useful to check
+that the wheel includes all the files you need it to.
+
+Inside a wheel, you will find the package's files, plus an additional directory
+called :samp:`{package_name}-{version}.dist-info`. This directory contains
+various files, including a ``METADATA`` file which is the equivalent of
+``PKG-INFO`` in sdists, as well as ``RECORD``. This can be useful to ensure no
+files are missing from your wheels.
+
+The file name of a wheel (ignoring some rarely used features) looks like this:
+:samp:`{package_name}-{version}-{python_tag}-{abi_tag}-{platform_tag}.whl`.
+This naming convention identifies which platforms and Python versions the wheel
+is compatible with. For example, the name ``pip-23.3.1-py3-none-any.whl`` means
+that:
+
+- (``py3``) This wheel can be installed on any implementation of Python 3,
+  whether CPython, the most widely used Python implementation, or an alternative
+  implementation like PyPy_;
+- (``none``) It does not depend on the Python version;
+- (``any``) It does not depend on the platform.
+
+The pattern ``py3-none-any`` is common for pure Python projects. Packages with
+extension modules typically ship multiple wheels with more complex tags.
+
+All technical details on the wheel format can be found in the :ref:`wheel
+specification `.
+
+
+.. _egg-format:
+.. _`Wheel vs Egg`:
+
+What about eggs?
+================
+
+"Egg" is an old package format that has been replaced with the wheel format.  It
+should not be used anymore. Since August 2023, PyPI `rejects egg uploads
+`_.
+
+Here's a breakdown of the important differences between wheel and egg.
+
+* The egg format was introduced by :ref:`setuptools` in 2004, whereas the wheel
+  format was introduced by :pep:`427` in 2012.
+
+* Wheel has an :doc:`official standard specification
+  `. Egg did not.
+
+* Wheel is a :term:`distribution ` format, i.e a packaging
+  format. [#wheel-importable]_ Egg was both a distribution format and a runtime
+  installation format (if left zipped), and was designed to be importable.
+
+* Wheel archives do not include ``.pyc`` files. Therefore, when the distribution
+  only contains Python files (i.e. no compiled extensions), and is compatible
+  with Python 2 and 3, it's possible for a wheel to be "universal", similar to
+  an :term:`sdist `.
+
+* Wheel uses standard :ref:`.dist-info directories
+  `.  Egg used ``.egg-info``.
+
+* Wheel has a :ref:`richer file naming convention `. A
+  single wheel archive can indicate its compatibility with a number of Python
+  language versions and implementations, ABIs, and system architectures.
+
+* Wheel is versioned. Every wheel file contains the version of the wheel
+  specification and the implementation that packaged it.
+
+* Wheel is internally organized by `sysconfig path type
+  `_,
+  therefore making it easier to convert to other formats.
+
+--------------------------------------------------------------------------------
+
+.. [#core-metadata-format] This format is email-based. Although this would
+   be unlikely to be chosen today, backwards compatibility considerations lead to
+   it being kept as the canonical format. From the user point of view, this
+   is mostly invisible, since the metadata is specified by the user in a way
+   understood by the build backend, typically ``[project]`` in ``pyproject.toml``,
+   and translated by the build backend into ``PKG-INFO``.
+
+.. [#wheel-importable] Circumstantially, in some cases, wheels can be used
+   as an importable runtime format, although :ref:`this is not officially supported
+   at this time `.
+
+
+
+.. _pip-pypi: https://pypi.org/project/pip/23.3.1/#files
+.. _pypi: https://pypi.org
+.. _pypi-eggs-deprecation: https://blog.pypi.org/posts/2023-06-26-deprecate-egg-uploads/
+.. _pypy: https://pypy.org
diff --git a/source/discussions/wheel-vs-egg.rst b/source/discussions/wheel-vs-egg.rst
deleted file mode 100644
index d4a1114fb..000000000
--- a/source/discussions/wheel-vs-egg.rst
+++ /dev/null
@@ -1,55 +0,0 @@
-.. _`Wheel vs Egg`:
-
-============
-Wheel vs Egg
-============
-
-:term:`Wheel` and :term:`Egg` are both packaging formats that aim to support the
-use case of needing an install artifact that doesn't require building or
-compilation, which can be costly in testing and production workflows.
-
-The :term:`Egg` format was introduced by :ref:`setuptools` in 2004, whereas the
-:term:`Wheel` format was introduced by :pep:`427` in 2012.
-
-:term:`Wheel` is currently considered the standard for :term:`built ` and :term:`binary ` packaging for Python.
-
-Here's a breakdown of the important differences between :term:`Wheel` and :term:`Egg`.
-
-
-* :term:`Wheel` has an :doc:`official standard specification
-  `.
-  :term:`Egg` did not.
-
-* :term:`Wheel` is a :term:`distribution ` format, i.e a packaging
-  format. [1]_ :term:`Egg` was both a distribution format and a runtime
-  installation format (if left zipped), and was designed to be importable.
-
-* :term:`Wheel` archives do not include .pyc files. Therefore, when the
-  distribution only contains Python files (i.e. no compiled extensions), and is
-  compatible with Python 2 and 3, it's possible for a wheel to be "universal",
-  similar to an :term:`sdist `.
-
-* :term:`Wheel` uses :pep:`PEP376-compliant <376>` ``.dist-info``
-  directories. Egg used ``.egg-info``.
-
-* :term:`Wheel` has a :pep:`richer file naming convention <425>`. A single
-  wheel archive can indicate its compatibility with a number of Python language
-  versions and implementations, ABIs, and system architectures.
-
-* :term:`Wheel` is versioned. Every wheel file contains the version of the wheel
-  specification and the implementation that packaged it.
-
-* :term:`Wheel` is internally organized by `sysconfig path type
-  `_,
-  therefore making it easier to convert to other formats.
-
-* :term:`Egg` uploads have been disabled for upload to PyPI, per :pep:`715`.
-  Read the `deprecation notice `_
-  for more information.
-
-----
-
-.. [1] Circumstantially, in some cases, wheels can be used as an importable
-       runtime format, although :ref:`this is not officially supported at this time
-       `.
diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst
index 6637fed2e..7d2c4e2a0 100644
--- a/source/specifications/binary-distribution-format.rst
+++ b/source/specifications/binary-distribution-format.rst
@@ -84,6 +84,8 @@ Place ``.dist-info`` at the end of the archive.
 File Format
 -----------
 
+.. _wheel-file-name-spec:
+
 File name convention
 ''''''''''''''''''''
 

From 5af20bf30596aa9e00254377c11aa408538d8a6e Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 15 Nov 2023 23:42:45 +0100
Subject: [PATCH 0596/1072] Update glossary with references to the new "Package
 formats" discussion

---
 source/glossary.rst | 19 ++++++++-----------
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/source/glossary.rst b/source/glossary.rst
index 1f55871fa..218c21168 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -47,11 +47,11 @@ Glossary
         A :term:`Distribution ` format containing files
         and metadata that only need to be moved to the correct location on the
         target system, to be installed. :term:`Wheel` is such a format, whereas
-        distutil's :term:`Source Distribution ` is not, in that it requires a build step before it can be
         installed.  This format does not imply that Python files have to be
         precompiled (:term:`Wheel` intentionally does not include compiled
-        Python files).
+        Python files). See :ref:`package-formats` for more information.
 
 
     Distribution Package
@@ -73,9 +73,8 @@ Glossary
     Egg
 
         A :term:`Built Distribution` format introduced by :ref:`setuptools`,
-        which is being replaced by :term:`Wheel`.  For details, see
-        :doc:`The Internal Structure of Python Eggs ` and
-        `Python Eggs `_
+        which has been replaced by :term:`Wheel`.  For details, see
+        :ref:`egg-format`.
 
     Extension Module
 
@@ -240,7 +239,8 @@ Glossary
         A :term:`distribution ` format (usually generated
         using ``python -m build --sdist``) that provides metadata and the
         essential source files needed for installing by a tool like :ref:`pip`,
-        or for generating a :term:`Built Distribution`.
+        or for generating a :term:`Built Distribution`. See :ref:`package-formats`
+        for more information.
 
 
     System Package
@@ -266,11 +266,8 @@ Glossary
 
     Wheel
 
-        A :term:`Built Distribution` format introduced by an official
-        :doc:`standard specification
-        `,
-        which is intended to replace the :term:`Egg` format.  Wheel is currently
-        supported by :ref:`pip`.
+        The standard :term:`Built Distribution` format.
+        See :ref:`package-formats` for more information.
 
     Working Set
 

From 67f169ff1f2f26ba46eee3f7609381da6334b0ee Mon Sep 17 00:00:00 2001
From: Rafael Fontenelle 
Date: Wed, 20 Dec 2023 09:43:56 -0300
Subject: [PATCH 0597/1072] Fix po filename in test-translations.yml

---
 .github/workflows/test-translations.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/test-translations.yml b/.github/workflows/test-translations.yml
index 9b1ad5c6f..cdb40b1aa 100644
--- a/.github/workflows/test-translations.yml
+++ b/.github/workflows/test-translations.yml
@@ -71,4 +71,4 @@ jobs:
       run: nox -s build -- -q -D language=${{ matrix.language }}
 
     - name: Lint translation file
-      run: sphinx-lint locales/${{ matrix.language }}/LC_MESSAGES/message.po
+      run: sphinx-lint locales/${{ matrix.language }}/LC_MESSAGES/messages.po

From b55365166533622f9c5fd6549dcbbe6f746aca07 Mon Sep 17 00:00:00 2001
From: Rafael Fontenelle 
Date: Wed, 20 Dec 2023 09:45:23 -0300
Subject: [PATCH 0598/1072] Make the matrix input generation more simpler

Co-authored-by: Jean Abou-Samra 
---
 .github/workflows/test-translations.yml | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/.github/workflows/test-translations.yml b/.github/workflows/test-translations.yml
index cdb40b1aa..50f2dd067 100644
--- a/.github/workflows/test-translations.yml
+++ b/.github/workflows/test-translations.yml
@@ -39,8 +39,7 @@ jobs:
       id: languages
       working-directory: locales
       run: |
-        dirs=$(find * -maxdepth 0 -type d)
-        list="$(echo $dirs | sed "s|^|['|;s|$|']|;s| |', '|g")"
+        list=$(find * -maxdepth 0 -type d | jq -nRc '[inputs]')
         echo "languages=$list" >> $GITHUB_OUTPUT
 
 

From 954a81bb8e14a09dfc3d2ed6e1d9f32b689c519c Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Wed, 20 Dec 2023 18:51:00 +0100
Subject: [PATCH 0599/1072] Use "universal" activate command

Co-authored-by: chrysle 
---
 source/guides/installing-using-pip-and-virtual-environments.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst
index e33615157..eb28f7458 100644
--- a/source/guides/installing-using-pip-and-virtual-environments.rst
+++ b/source/guides/installing-using-pip-and-virtual-environments.rst
@@ -88,7 +88,7 @@ shell's ``PATH``.
 
     .. code-block:: bat
 
-        .venv\Scripts\Activate.bat
+        .venv\Scripts\activate
 
 To confirm the virtual environment is activated, check the location of your
 Python interpreter:

From e1ed4d7ac4a027483f48b178bf5485876bfd3c32 Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Wed, 20 Dec 2023 18:51:16 +0100
Subject: [PATCH 0600/1072] Use "universal" Python commmand

Co-authored-by: chrysle 
---
 source/guides/installing-using-pip-and-virtual-environments.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst
index eb28f7458..64fdf9382 100644
--- a/source/guides/installing-using-pip-and-virtual-environments.rst
+++ b/source/guides/installing-using-pip-and-virtual-environments.rst
@@ -118,7 +118,7 @@ filepath that includes the ``.venv`` directory, by ending with the following:
 
     .. code-block:: bat
 
-        .venv\Scripts\python.exe
+        .venv\Scripts\python
 
 
 While a virtual environment is activated, pip will install packages into that

From 4d0108284aedcde4a89ad4e1c829b0277f9c281a Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 20 Dec 2023 19:43:52 +0100
Subject: [PATCH 0601/1072] Link 0ver + blog posts on semver limitations

---
 source/discussions/versioning.rst | 27 ++++++++++++++++++++++-----
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/source/discussions/versioning.rst b/source/discussions/versioning.rst
index a63d269bc..a2d818e87 100644
--- a/source/discussions/versioning.rst
+++ b/source/discussions/versioning.rst
@@ -67,7 +67,7 @@ semantic versioning and calendar versioning.
 Semantic versioning
 -------------------
 
-The idea of *semantic versioning* is to use 3-part version numbers,
+The idea of *semantic versioning* (or SemVer) is to use 3-part version numbers,
 *major.minor.maintenance*, where the project author increments:
 
 - *major* when they make incompatible API changes,
@@ -79,7 +79,8 @@ versioning. However, most projects, especially larger ones, do not strictly
 adhere to semantic versioning, since many changes are technically breaking
 changes but affect only a small fraction of users. Such projects tend to
 increment the major number when the incompatibility is high, or to signal a
-shift in the project, rather than for any tiny incompatibility,
+shift in the project, rather than for any tiny incompatibility
+[#semver-strictness]_.
 
 For those projects that do use strict semantic versioning, this approach allows
 users to make use of :ref:`compatible release version specifiers
@@ -108,9 +109,9 @@ Semantic versioning is not a suitable choice for all projects, such as those
 with a regular time based release cadence and a deprecation process that
 provides warnings for a number of releases prior to removal of a feature.
 
-A key advantage of date-based versioning, or `calendar versioning `_,
-is that it is straightforward to tell how old the base feature set of a
-particular release is given just the version number.
+A key advantage of date-based versioning, or `calendar versioning `_
+(CalVer), is that it is straightforward to tell how old the base feature set of
+a particular release is given just the version number.
 
 Calendar version numbers typically take the form *year.month* (for example,
 23.12 for December 2023).
@@ -154,6 +155,22 @@ since the latest release, setuptools-scm generates a version like
 "0.5.dev1+gd00980f.d20231217".
 
 
+--------------------------------------------------------------------------------
+
+
+.. [#semver-strictness] For some personal viewpoints on this issue, see these
+   blog posts: `by Hynek Schlawak `_, `by Donald Stufft
+   `_, `by Bernát Gábor `_, `by
+   Brett Cannon `_. For a humoristic take, read about
+   ZeroVer_.
+
+
+
+.. _zerover: https://0ver.org
 .. _calver: https://calver.org
 .. _semver: https://semver.org
+.. _semver-bernat-gabor: https://bernat.tech/posts/version-numbers/
+.. _semver-brett-cannon: https://snarky.ca/why-i-dont-like-semver/
+.. _semver-donald-stufft: https://caremad.io/posts/2016/02/versioning-software/
+.. _semver-hynek-schlawack: https://hynek.me/articles/semver-will-not-save-you/
 .. _setuptools-scm: https://setuptools-scm.readthedocs.io

From 0288ec010b37533d53eb66a391e3ecb2c5238932 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Felix=20Kr=C3=B6ner?=
 <36126706+Crown0815@users.noreply.github.com>
Date: Thu, 21 Dec 2023 12:04:06 +0100
Subject: [PATCH 0602/1072] Remove unnecessary word from documentation

---
 source/guides/hosting-your-own-index.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/hosting-your-own-index.rst b/source/guides/hosting-your-own-index.rst
index 26ffe2b8c..bce4e0807 100644
--- a/source/guides/hosting-your-own-index.rst
+++ b/source/guides/hosting-your-own-index.rst
@@ -6,7 +6,7 @@ Hosting your own simple repository
 
 
 If you wish to host your own simple repository [1]_, you can either use a
-software package like :doc:`devpi ` or you can use simply create the proper
+software package like :doc:`devpi ` or you can simply create the proper
 directory structure and use any web server that can serve static files and
 generate an autoindex.
 

From 3a90a886056e8030cdef7f82deaffaaf8e73e9ff Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Fri, 22 Dec 2023 14:55:33 +0100
Subject: [PATCH 0603/1072] Deduplicate specification of valid package names

- Rename the "Package name normalization" specification into "Package
  name grammar and normalization", to make it explicitly about the
  format of valid names too.

- Link to this spec in the core metadata specification instead of
  duplicating the part about valid names.
---
 source/specifications/core-metadata.rst      |  9 ++----
 source/specifications/name-normalization.rst | 30 +++++++++++++-------
 2 files changed, 21 insertions(+), 18 deletions(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index b8cd5326e..6b5efd13a 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -73,15 +73,10 @@ Name
 
 .. versionadded:: 1.0
 .. versionchanged:: 2.1
-   Added additional restrictions on format from :pep:`508`
+   Added restrictions on format from the :ref:`name grammar `.
 
 The name of the distribution. The name field is the primary identifier for a
-distribution. A valid name consists only of ASCII letters and numbers, period,
-underscore and hyphen. It must start and end with a letter or number.
-Distribution names are limited to those which match the following
-regex (run with ``re.IGNORECASE``)::
-
-    ^([A-Z0-9]|[A-Z0-9][A-Z0-9._-]*[A-Z0-9])$
+distribution. It must conform to the :ref:`package name grammar `.
 
 Example::
 
diff --git a/source/specifications/name-normalization.rst b/source/specifications/name-normalization.rst
index 64be4a1d1..fb6d22a09 100644
--- a/source/specifications/name-normalization.rst
+++ b/source/specifications/name-normalization.rst
@@ -1,13 +1,16 @@
-.. _name-normalization:
+======================================
+Package name grammar and normalization
+======================================
+
+Project names obey a restricted format, and are "normalized" for use in various
+contexts. This document describes what the valid project names are, and how
+project names should be normalized.
 
-==========================
-Package name normalization
-==========================
 
-Project names are "normalized" for use in various contexts. This document describes how project names should be normalized.
+.. _name-grammar:
 
-Valid non-normalized names
---------------------------
+Name grammar
+============
 
 A valid name consists only of ASCII letters and numbers, period,
 underscore and hyphen. It must start and end with a letter or number.
@@ -16,10 +19,15 @@ following regex (run with ``re.IGNORECASE``)::
 
     ^([A-Z0-9]|[A-Z0-9][A-Z0-9._-]*[A-Z0-9])$
 
-Normalization
--------------
 
-The name should be lowercased with all runs of the characters ``.``, ``-``, or ``_`` replaced with a single ``-`` character. This can be implemented in Python with the re module:
+.. _name-normalization:
+
+Name normalization
+==================
+
+The name should be lowercased with all runs of the characters ``.``, ``-``, or
+``_`` replaced with a single ``-`` character. This can be implemented in Python
+with the re module:
 
 .. code-block:: python
 
@@ -30,7 +38,7 @@ The name should be lowercased with all runs of the characters ``.``, ``-``, or `
 
 This means that the following names are all equivalent:
 
-* ``friendly-bard``  (normalized form)
+* ``friendly-bard`` (normalized form)
 * ``Friendly-Bard``
 * ``FRIENDLY-BARD``
 * ``friendly.bard``

From c0f078d293ac7b30981a2f78bd6ccfe3ebad69df Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Fri, 22 Dec 2023 16:44:37 +0100
Subject: [PATCH 0604/1072] Consistent changelogs for all specs

Fixes #1203
---
 .../binary-distribution-format.rst            |  9 ++----
 source/specifications/core-metadata.rst       | 20 +++++++++++++
 .../specifications/dependency-specifiers.rst  | 16 +++++-----
 .../direct-url-data-structure.rst             | 13 ++++++---
 source/specifications/direct-url.rst          |  4 +--
 source/specifications/entry-points.rst        | 11 +++++++
 .../externally-managed-environments.rst       |  2 +-
 .../specifications/inline-script-metadata.rst |  2 +-
 source/specifications/name-normalization.rst  |  6 ++--
 .../platform-compatibility-tags.rst           | 19 +++++++-----
 source/specifications/pyproject-toml.rst      |  8 +++--
 .../recording-installed-packages.rst          | 29 +++++++++----------
 .../source-distribution-format.rst            | 12 ++++----
 source/specifications/version-specifiers.rst  |  5 +---
 .../specifications/virtual-environments.rst   |  6 ++++
 15 files changed, 105 insertions(+), 57 deletions(-)

diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst
index 6637fed2e..3ca3cc785 100644
--- a/source/specifications/binary-distribution-format.rst
+++ b/source/specifications/binary-distribution-format.rst
@@ -418,12 +418,9 @@ Is it possible to import Python code directly from a wheel file?
 History
 =======
 
-This specification was originally approved as :pep:`427`.
-
-The following changes were applied since the initial version:
-
-- The rules on escaping in wheel filenames were revised, to bring them
-  into line with what popular tools actually do (February 2021).
+- February 2013: This specification was approved through :pep:`427`.
+- February 2021: The rules on escaping in wheel filenames were revised, to bring
+  them into line with what popular tools actually do.
 
 
 Appendix
diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index b8cd5326e..2fb83206c 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -848,6 +848,26 @@ Example::
     Obsoletes: Gorgon
 
 
+History
+=======
+
+- March 2001: Core metadata 1.0 was approved through :pep:`241`.
+- April 2003: Core metadata 1.1 was approved through :pep:`314`:
+- February 2010: Core metadata 1.2 was approved through :pep:`345`.
+- February 2018: Core metadata 2.1 was approved through :pep:`566`.
+
+  - Added ``Description-Content-Type`` and ``Provides-Extra``.
+  - Added canonical method for transforming metadata to JSON.
+  - Restricted the grammar of the ``Name`` field.
+
+- October 2020: Core metadata 2.2 was approved through :pep:`643`.
+
+  - Added the ``Dynamic`` field.
+
+- March 2022: Core metadata 2.3 was approved through :pep:`685`.
+
+  - Restricted extra names to be normalized.
+
 ----
 
 .. [1] reStructuredText markup:
diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst
index 6287f3815..85216d655 100644
--- a/source/specifications/dependency-specifiers.rst
+++ b/source/specifications/dependency-specifiers.rst
@@ -472,14 +472,12 @@ A test program - if the grammar is in a string ``grammar``:
         print("%s -> %s" % (test, parsed))
 
 
-Summary of changes to PEP 508
-=============================
+History
+=======
 
-The following changes were made based on feedback after its initial
-implementation:
-
-- The definition of ``python_version`` was changed from
-  ``platform.python_version()[:3]`` to
+- November 2015: This specification was approved through :pep:`508`.
+- July 2019: The definition of ``python_version`` was `changed
+  `_ from ``platform.python_version()[:3]`` to
   ``'.'.join(platform.python_version_tuple()[:2])``, to accommodate potential
   future versions of Python with 2-digit major and minor versions
   (e.g. 3.10). [#future_versions]_
@@ -497,3 +495,7 @@ References
 .. [#future_versions] Future Python versions might be problematic with the
    definition of Environment Marker Variable ``python_version``
    (https://github.com/python/peps/issues/560)
+
+
+
+.. _python-version-change: https://mail.python.org/pipermail/distutils-sig/2018-January/031920.html
diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index 22900636c..f0ab2e447 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -262,10 +262,15 @@ Local directory in editable mode:
        }
    }
 
+
 History
 =======
 
-- March 2020: this data structure was originally specified as part of the
-  ``direct_url.json`` metadata file in :pep:`610` and is formally documented here.
-- January 2023: Added the ``archive_info.hashes`` key
-  ([discussion](https://discuss.python.org/t/22299)).
+- March 2020: This specification was approved through :pep:`610`, defining
+  the ``direct_url.json`` metadata file.
+- January 2023: Added the ``archive_info.hashes`` key (`discussion
+  `_).
+
+
+
+.. _archive-info-hashes: https://discuss.python.org/t/22299
diff --git a/source/specifications/direct-url.rst b/source/specifications/direct-url.rst
index 5c0bd1b21..babecd842 100644
--- a/source/specifications/direct-url.rst
+++ b/source/specifications/direct-url.rst
@@ -62,8 +62,8 @@ Commands that *do not* generate a ``direct_url.json``
 * ``pip install app``
 * ``pip install app --no-index --find-links https://example.com/``
 
+
 History
 =======
 
-- March 2020: the ``direct_url.json`` metadata file was originally specified in
-  :pep:`610` and is formally documented here.
+- March 2020: This specification was approved through :pep:`610`.
diff --git a/source/specifications/entry-points.rst b/source/specifications/entry-points.rst
index 90a18a0bc..6a601c977 100644
--- a/source/specifications/entry-points.rst
+++ b/source/specifications/entry-points.rst
@@ -158,3 +158,14 @@ which defines where command-line tools are found.
 As files are created from the names, and some filesystems are case-insensitive,
 packages should avoid using names in these groups which differ only in case.
 The behaviour of install tools when names differ only in case is undefined.
+
+
+History
+=======
+
+- October 2017: This specification was written to formalize the existing
+  entry points feature of setuptools (discussion_).
+
+
+
+.. _discussion: https://mail.python.org/pipermail/distutils-sig/2017-October/031585.html
diff --git a/source/specifications/externally-managed-environments.rst b/source/specifications/externally-managed-environments.rst
index f6845e737..2944eb3da 100644
--- a/source/specifications/externally-managed-environments.rst
+++ b/source/specifications/externally-managed-environments.rst
@@ -471,4 +471,4 @@ CC0-1.0-Universal license, whichever is more permissive.
 History
 =======
 
-This specification was originally approved as :pep:`668`.
+- June 2022: This specification was approved through :pep:`668`.
diff --git a/source/specifications/inline-script-metadata.rst b/source/specifications/inline-script-metadata.rst
index 021c316fe..f18f4f17e 100644
--- a/source/specifications/inline-script-metadata.rst
+++ b/source/specifications/inline-script-metadata.rst
@@ -238,4 +238,4 @@ the highest available version of Python that is compatible with the script's
 History
 =======
 
-This specification was originally defined as :pep:`723`.
+- October 2023: This specification was conditionally approved through :pep:`723`.
diff --git a/source/specifications/name-normalization.rst b/source/specifications/name-normalization.rst
index 64be4a1d1..18a59e1cc 100644
--- a/source/specifications/name-normalization.rst
+++ b/source/specifications/name-normalization.rst
@@ -41,5 +41,7 @@ This means that the following names are all equivalent:
 History
 =======
 
-- `September 2015 `_: normalized name was originally specified in :pep:`503#normalized-names`.
-- `November 2015 `_: valid non-normalized name was originally specified in :pep:`508#names`.
+- September 2015: The specification of name normalized was approved through
+  :pep:`503 <503#normalized-names>`.
+- November 2015: The specification of valid names was approved through
+  :pep:`508 <508#names>`.
diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index df7da59c5..52ffadfa3 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -9,13 +9,6 @@ Platform compatibility tags allow build tools to mark distributions as being
 compatible with specific platforms, and allows installers to understand which
 distributions are compatible with the system they are running on.
 
-The following PEPs contributed to this spec:
-
-1. :pep:`425`
-2. :pep:`513`
-3. :pep:`571`
-4. :pep:`599`
-5. :pep:`600`
 
 Overview
 ========
@@ -302,3 +295,15 @@ Why is the ABI tag (the second tag) sometimes "none" in the reference implementa
     implementation at the time of writing guesses "none".  Ideally it
     would detect "py27(d|m|u)" analogous to newer versions of Python,
     but in the meantime "none" is a good enough way to say "don't know".
+
+
+History
+=======
+
+- February 2013: The original version of this specification was approved through
+  :pep:`425`.
+- January 2016: The ``manylinux1`` tag was approved through :pep:`513`.
+- April 2018: The ``manylinux2010`` tag was approved through :pep:`571`.
+- July 2019: The ``manylinux2014`` tag was approved through :pep:`599`.
+- November 2019: The ``manylinux_x_y`` perennial tag was approved through
+  :pep:`600`.
diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 92811958b..1580b3772 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -441,8 +441,12 @@ the subtable ``tool.$NAME`` if, and only if, they own the entry for
 History
 =======
 
-This specification was originally defined in :pep:`518` (``[build-system]``
-and ``[tool]`` tables) and :pep:`621` (``[project]`` table).
+- May 2016: The initial specification of the ``pyproject.toml`` file, with just
+  a ``[build-system]`` containing a ``requires`` key and a ``[tool]`` table, was
+  approved through :pep:`518`.
+
+- November 2020: The specification of the ``[project]`` table was approved
+  through :pep:`621`.
 
 
 
diff --git a/source/specifications/recording-installed-packages.rst b/source/specifications/recording-installed-packages.rst
index ca8d5f0d5..957e4f36a 100644
--- a/source/specifications/recording-installed-packages.rst
+++ b/source/specifications/recording-installed-packages.rst
@@ -19,22 +19,6 @@ files in a format specific to Python tooling, it should still record the name
 and version of the installed project.
 
 
-History and change workflow
-===========================
-
-The metadata described here was first specified in :pep:`376`, and later
-amended in :pep:`627` (and other PEPs).
-It was formerly known as *Database of Installed Python Distributions*.
-As with other PyPA specifications, editorial amendments with no functional
-impact may be made through the GitHub pull request workflow. Proposals for
-functional changes that would require amendments to package building and/or
-installation tools must be made through the PEP process (see :pep:`1`).
-
-While this document is the normative specification, the PEPs that introduce
-changes to it may include additional information such as rationales and
-backwards compatibility considerations.
-
-
 The .dist-info directory
 ========================
 
@@ -262,3 +246,16 @@ ensuring both locations appear on the default Python import path).
 In some circumstances, it may be desirable to block even installation of
 additional packages via Python-specific tools. For these cases refer to
 :ref:`externally-managed-environments`
+
+
+History
+=======
+
+- June 2009: The original version of this specification was approved through
+  :pep:`376`.  At the time, it was known as the *Database of Installed Python
+  Distributions*.
+- March 2020: The specification of the ``direct_url.json`` file was approved
+  through :pep:`610`. It is only mentioned on this page; see :ref:`direct-url`
+  for the full definition.
+- September 2020: Various amendments and clarifications were approved through
+  :pep:`627`.
diff --git a/source/specifications/source-distribution-format.rst b/source/specifications/source-distribution-format.rst
index 55737dc07..bae618df1 100644
--- a/source/specifications/source-distribution-format.rst
+++ b/source/specifications/source-distribution-format.rst
@@ -143,8 +143,10 @@ verification* in ``tarfile`` documentation apply to their tool.
 History
 =======
 
-* August 2023: Standardized the source distribution archive features (:pep:`721`)
-* September 2022: Standardized the filename of a source distribution (:pep:`625`)
-* July 2021: Defined what a source tree is
-* November 2020: :pep:`643` converted to this specification
-* December 2000: Source distributions standardized in :pep:`643`
+* November 2020: The original version of this specification was approved through
+  :pep:`643`.
+* July 2021: Defined what a source tree is.
+* September 2022: The filename of a source distribution was standardized through
+  :pep:`625`.
+* August 2023: Source distribution archive features were standardized through
+  :pep:`721`.
diff --git a/source/specifications/version-specifiers.rst b/source/specifications/version-specifiers.rst
index 202031758..8129fd53d 100644
--- a/source/specifications/version-specifiers.rst
+++ b/source/specifications/version-specifiers.rst
@@ -1261,7 +1261,4 @@ project):
 History
 =======
 
-This specification was originally approved as :pep:`440`,
-addressing several limitations of the previous attempt
-at standardized versioning, as described in :pep:`345`
-and :pep:`386`.
+- August 2014: This specification was approved through :pep:`440`.
diff --git a/source/specifications/virtual-environments.rst b/source/specifications/virtual-environments.rst
index 77c8c3627..6c8eee530 100644
--- a/source/specifications/virtual-environments.rst
+++ b/source/specifications/virtual-environments.rst
@@ -48,3 +48,9 @@ Even in the absence of a ``pyvenv.cfg`` file, any approach (e.g.
 ``sys.prefix`` and ``sys.base_prefix`` having different values, while still
 providing a matching default package installation scheme in ``sysconfig``, will
 be detected and behave as a Python virtual environment.
+
+
+History
+=======
+
+- May 2012: This specification was approved through :pep:`405`.

From ce62b3abbb6770bd4dfd4e0f4e64f79d0821a45e Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Fri, 22 Dec 2023 16:54:02 +0100
Subject: [PATCH 0605/1072] Increase number of linkcheck retries

We're getting frequent flaky CI failures due to the huge number of links
that have to be checked, making the check sensitive to random connection
errors.
---
 source/conf.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/source/conf.py b/source/conf.py
index 0e3a93d5e..6daeba245 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -108,6 +108,7 @@
     # https://github.com/pypa/packaging.python.org/pull/1308#issuecomment-1775347690
     "https://www.breezy-vcs.org/*",
 ]
+linkcheck_retries = 5
 
 # -- Options for extlinks ----------------------------------------------------------
 # https://www.sphinx-doc.org/en/master/usage/extensions/extlinks.html#configuration

From 74e6ac8b980c5a2f399af31bde2c22022395a373 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Fri, 22 Dec 2023 22:14:06 +0100
Subject: [PATCH 0606/1072] Give exact glibc versions for legacy manylinux tags

---
 source/specifications/platform-compatibility-tags.rst | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 391845950..208ecde1f 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -117,13 +117,10 @@ of ``sysconfig.get_platform()`` on the system as in the "simple" form above.
 
 The following older tags are still supported for backward compatibility:
 
-* ``manylinux1`` is based on a compatible Linux platform from 2007,
-  and supports ``x86_64`` and ``i686`` architectures.
-* ``manylinux2010`` is based on a platform from 2010 and supports ``x86_64``
-  and ``i686``.
-* ``manylinux2014`` is based on a platform from 2014 and supports
-  ``x86_64``, ``i686``, ``aarch64``, ``armv7l``, ``ppc64``, ``ppc64le``,
-  and ``s390x``.
+* ``manylinux1`` supports glibc 2.5 on ``x86_64`` and ``i686`` architectures.
+* ``manylinux2010`` supports glibc 2.12 on ``x86_64`` and ``i686``.
+* ``manylinux2014`` supports glibc 2.17 on ``x86_64``, ``i686``, ``aarch64``,
+  ``armv7l``, ``ppc64``, ``ppc64le``, and ``s390x``.
 
 In general, distributions built for older versions of the specification are
 forwards-compatible (meaning that ``manylinux1`` distributions should continue

From 2341590e1c1475dd43ee9989c91c7f88979fb911 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sat, 23 Dec 2023 00:02:26 +0100
Subject: [PATCH 0607/1072] Address @pradyunsg's review

---
 source/specifications/core-metadata.rst      |  3 ++-
 source/specifications/name-normalization.rst | 18 +++++++++---------
 2 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 6b5efd13a..5248c7122 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -76,7 +76,8 @@ Name
    Added restrictions on format from the :ref:`name grammar `.
 
 The name of the distribution. The name field is the primary identifier for a
-distribution. It must conform to the :ref:`package name grammar `.
+distribution. It must conform to the :ref:`name format specification
+`.
 
 Example::
 
diff --git a/source/specifications/name-normalization.rst b/source/specifications/name-normalization.rst
index fb6d22a09..227b9692c 100644
--- a/source/specifications/name-normalization.rst
+++ b/source/specifications/name-normalization.rst
@@ -1,16 +1,16 @@
-======================================
-Package name grammar and normalization
-======================================
+=======================
+Names and normalization
+=======================
 
-Project names obey a restricted format, and are "normalized" for use in various
-contexts. This document describes what the valid project names are, and how
-project names should be normalized.
+This specification defines the format that names for packages and extras are
+required to follow. It also describes how to normalize them, which should be
+done before lookups and comparisons.
 
 
-.. _name-grammar:
+.. _name-format:
 
-Name grammar
-============
+Name format
+===========
 
 A valid name consists only of ASCII letters and numbers, period,
 underscore and hyphen. It must start and end with a letter or number.

From 1ca542eeabe5538849a6045620e08afb6251c634 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sat, 23 Dec 2023 00:05:07 +0100
Subject: [PATCH 0608/1072] Fix missing label update

---
 source/specifications/core-metadata.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 5248c7122..1040c2c5d 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -73,7 +73,7 @@ Name
 
 .. versionadded:: 1.0
 .. versionchanged:: 2.1
-   Added restrictions on format from the :ref:`name grammar `.
+   Added restrictions on format from the :ref:`name format `.
 
 The name of the distribution. The name field is the primary identifier for a
 distribution. It must conform to the :ref:`name format specification

From 99beaa9b751d932df323a9144c228bf85fd10dca Mon Sep 17 00:00:00 2001
From: Rafael Fontenelle 
Date: Sat, 23 Dec 2023 00:15:49 -0300
Subject: [PATCH 0609/1072] Add problem matcher for test-translations.yml

---
 .github/sphinx_lint_matcher.json        | 15 +++++++++++++++
 .github/workflows/test-translations.yml |  9 +++++++--
 2 files changed, 22 insertions(+), 2 deletions(-)
 create mode 100644 .github/sphinx_lint_matcher.json

diff --git a/.github/sphinx_lint_matcher.json b/.github/sphinx_lint_matcher.json
new file mode 100644
index 000000000..41896d8f1
--- /dev/null
+++ b/.github/sphinx_lint_matcher.json
@@ -0,0 +1,15 @@
+{
+    "problemMatcher": [
+        {
+            "owner": "sphinx-lint-problem-matcher",
+            "pattern": [
+                {
+                    "regexp": "^(.*):(\\d+):\\s+(.*)$",
+                    "file": 1,
+                    "line": 2,
+                    "message": 3
+                }
+            ]
+        }
+    ]
+}
diff --git a/.github/workflows/test-translations.yml b/.github/workflows/test-translations.yml
index 50f2dd067..d6feddac0 100644
--- a/.github/workflows/test-translations.yml
+++ b/.github/workflows/test-translations.yml
@@ -58,7 +58,7 @@ jobs:
         ref: ${{ env.I18N_BRANCH }}
 
     - name: Set up Python
-      uses: actions/setup-python@v4
+      uses: actions/setup-python@v5
       with:
         python-version: >-
           3.10
@@ -66,8 +66,13 @@ jobs:
     - name: Install Python tooling
       run: python -m pip install --upgrade nox virtualenv sphinx-lint
 
+    - name: Set Sphinx problem matcher
+      uses: sphinx-doc/github-problem-matcher@master
+
     - name: Build translated docs in ${{ matrix.language }}
       run: nox -s build -- -q -D language=${{ matrix.language }}
 
     - name: Lint translation file
-      run: sphinx-lint locales/${{ matrix.language }}/LC_MESSAGES/messages.po
+      run: |
+        echo '::add-matcher::.github/sphinx_lint_matcher.json'
+        sphinx-lint locales/${{ matrix.language }}/LC_MESSAGES/messages.po

From 10430a101c20725f96b2bb94ee4f78317885efbf Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 25 Dec 2023 18:33:07 +0000
Subject: [PATCH 0610/1072] [pre-commit.ci] pre-commit autoupdate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

updates:
- [github.com/astral-sh/ruff-pre-commit: v0.1.8 → v0.1.9](https://github.com/astral-sh/ruff-pre-commit/compare/v0.1.8...v0.1.9)
---
 .pre-commit-config.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index 20eeadb57..baba00ea3 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -34,7 +34,7 @@ repos:
   - id: rst-inline-touching-normal
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.1.8
+  rev: v0.1.9
   hooks:
     - id: ruff
     - id: ruff-format

From 92759ce47302a9a6be09d157967eff7684e5021f Mon Sep 17 00:00:00 2001
From: Sviatoslav Sydorenko 
Date: Sun, 31 Dec 2023 18:34:42 +0100
Subject: [PATCH 0611/1072] Revert "Merge pull request #1436 from jeanas/gh-ci"

This partially reverts commit 9cd20c6c756b1b2c22ecab93e4cdb0c50bd15885,
reversing changes made to 45c22c2f33063c505f2f61895904b29127161a8a.
---
 .github/workflows/test.yml | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
index 7645d7fcc..581b644ca 100644
--- a/.github/workflows/test.yml
+++ b/.github/workflows/test.yml
@@ -47,9 +47,7 @@ jobs:
     # This job does nothing and is only used for the branch protection
     # or multi-stage CI jobs, like making sure that all tests pass before
     # a publishing job is started.
-    if: >-
-      github.repository_owner == 'pypa'
-      || github.event_name != 'schedule'
+    if: always()
 
     needs:
     - build

From 617f04be2d66496d584349e51d1171559e8e34d8 Mon Sep 17 00:00:00 2001
From: Sviatoslav Sydorenko 
Date: Sun, 31 Dec 2023 18:36:43 +0100
Subject: [PATCH 0612/1072] =?UTF-8?q?=F0=9F=A7=AA=F0=9F=94=A7=20Move=20cro?=
 =?UTF-8?q?n=20trigger=20to=20separate=20GHA=20workflow?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .github/workflows/cron.yml | 14 ++++++++++++++
 .github/workflows/test.yml |  3 +--
 2 files changed, 15 insertions(+), 2 deletions(-)
 create mode 100644 .github/workflows/cron.yml

diff --git a/.github/workflows/cron.yml b/.github/workflows/cron.yml
new file mode 100644
index 000000000..8870bb70b
--- /dev/null
+++ b/.github/workflows/cron.yml
@@ -0,0 +1,14 @@
+---
+
+name: Cron
+
+on:
+  schedule:
+  - cron: "0 6 * * *"  # daily at 6am
+
+jobs:
+  test:
+    if: github.repository_owner == 'pypa'  # suppress noise in forks
+    uses: ./.github/workflows/test.yml
+
+...
diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
index 581b644ca..8503ca720 100644
--- a/.github/workflows/test.yml
+++ b/.github/workflows/test.yml
@@ -6,8 +6,7 @@ on:
     branches-ignore:
     - gh-readonly-queue/**  # Temporary merge queue-related GH-made branches
   pull_request:
-  schedule:
-    - cron: "0 6 * * *" # daily at 6am
+  workflow_call:
 
 concurrency:
   group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.sha }}

From 86eb51d6662362cbbf0c2dd70b26a9587977cf41 Mon Sep 17 00:00:00 2001
From: Rafael Fontenelle 
Date: Wed, 3 Jan 2024 10:11:00 -0300
Subject: [PATCH 0613/1072] Pin github-problem-matcher version to v1.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 .github/workflows/test-translations.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/test-translations.yml b/.github/workflows/test-translations.yml
index d6feddac0..5a61b431b 100644
--- a/.github/workflows/test-translations.yml
+++ b/.github/workflows/test-translations.yml
@@ -67,7 +67,7 @@ jobs:
       run: python -m pip install --upgrade nox virtualenv sphinx-lint
 
     - name: Set Sphinx problem matcher
-      uses: sphinx-doc/github-problem-matcher@master
+      uses: sphinx-doc/github-problem-matcher@v1.0
 
     - name: Build translated docs in ${{ matrix.language }}
       run: nox -s build -- -q -D language=${{ matrix.language }}

From 0145ba51be2b610acfc1408beb97f02b53fca7f7 Mon Sep 17 00:00:00 2001
From: Rafael Fontenelle 
Date: Wed, 3 Jan 2024 10:24:54 -0300
Subject: [PATCH 0614/1072] Split steps for add-matcher and lint commands

---
 .github/workflows/test-translations.yml | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/.github/workflows/test-translations.yml b/.github/workflows/test-translations.yml
index 5a61b431b..45dc60aa3 100644
--- a/.github/workflows/test-translations.yml
+++ b/.github/workflows/test-translations.yml
@@ -72,7 +72,10 @@ jobs:
     - name: Build translated docs in ${{ matrix.language }}
       run: nox -s build -- -q -D language=${{ matrix.language }}
 
+    - name: Set Sphinx Lint problem matcher
+      if: always()
+      run: echo '::add-matcher::.github/sphinx_lint_matcher.json'
+
     - name: Lint translation file
-      run: |
-        echo '::add-matcher::.github/sphinx_lint_matcher.json'
-        sphinx-lint locales/${{ matrix.language }}/LC_MESSAGES/messages.po
+      if: always()
+      run: sphinx-lint locales/${{ matrix.language }}/LC_MESSAGES/messages.po

From a3d3a813baf1c88126525e52696b3a97155c451c Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Thu, 4 Jan 2024 11:21:44 -0800
Subject: [PATCH 0615/1072] Remove the explicit list of PaaS platforms

It can be misconstrued as an endorsement and we can't keep up w/ all PaaS platforms which support Python to make the list comprehensive/impartial.
---
 source/overview.rst | 20 ++++++--------------
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/source/overview.rst b/source/overview.rst
index 3627e8122..8c68036a7 100644
--- a/source/overview.rst
+++ b/source/overview.rst
@@ -195,20 +195,12 @@ hood, you can always read the sections beyond.
 Service platforms
 *****************
 
-If you're developing for a "Platform-as-a-Service" or "PaaS" like
-Heroku or Google App Engine, you are going to want to follow their
-respective packaging guides.
-
-* `Heroku `_
-* `Google App Engine `_
-* `PythonAnywhere `_
-* `OpenShift `_
-* "Serverless" frameworks like :gh:`Zappa `
-
-In all these setups, the platform takes care of packaging and
-deployment, as long as you follow their patterns. Most software does
-not fit one of these templates, hence the existence of all the other
-options below.
+If you're developing for a
+"`Platform-as-a-Service `_"
+or "PaaS", you are going to want to follow their respective packaging
+guides. These types of platforms take care of packaging and deployment,
+as long as you follow their patterns. Most software does not fit one of
+these templates, hence the existence of all the other options below.
 
 If you're developing software that will be deployed to machines you
 own, users' personal computers, or any other arrangement, read on.

From c84d3a62d27a30c251a61e20043c105774eab55b Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sun, 14 Jan 2024 13:36:11 +0100
Subject: [PATCH 0616/1072] Fix linkcheck

Apparently, GitHub now adds the README HTML on a project page
dynamically through JS, which prevents Sphinx's link checker from
finding anchors into the README.
---
 source/conf.py | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/source/conf.py b/source/conf.py
index 6daeba245..315aa8c52 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -109,6 +109,12 @@
     "https://www.breezy-vcs.org/*",
 ]
 linkcheck_retries = 5
+# Ignore anchors for links to GitHub project pages -- GitHub adds anchors from
+# README.md headings through JavaScript, so Sphinx's linkcheck can't find them
+# in the HTML.
+linkcheck_anchors_ignore_for_url = [
+    r"https://github\.com/",
+]
 
 # -- Options for extlinks ----------------------------------------------------------
 # https://www.sphinx-doc.org/en/master/usage/extensions/extlinks.html#configuration

From c730a82dd1df1911ed17f519c4ca934ff568cecb Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sat, 13 Jan 2024 22:56:27 +0100
Subject: [PATCH 0617/1072] Update inline script metadata spec with latest PEP
 723 changes

---
 .../specifications/inline-script-metadata.rst | 56 +++++++------------
 1 file changed, 19 insertions(+), 37 deletions(-)

diff --git a/source/specifications/inline-script-metadata.rst b/source/specifications/inline-script-metadata.rst
index f18f4f17e..ad667e94a 100644
--- a/source/specifications/inline-script-metadata.rst
+++ b/source/specifications/inline-script-metadata.rst
@@ -2,13 +2,6 @@
 Inline script metadata
 ======================
 
-.. warning::
-   This specification has been **provisionally accepted**. It is subject
-   to being changed or abandoned. See the
-   `PEP 723 conditional acceptance thread `_ for details.
-
-.. _pep723-thread: https://discuss.python.org/t/36763
-
 This specification defines a metadata format that can be embedded in single-file
 Python scripts to assist launchers, IDEs and other external tools which may need
 to interact with such scripts.
@@ -73,20 +66,22 @@ In circumstances where there is a discrepancy between the text specification
 and the regular expression, the text specification takes precedence.
 
 Tools MUST NOT read from metadata blocks with types that have not been
-standardized by this PEP or future ones.
+standardized by this specification.
 
-pyproject type
---------------
+script type
+-----------
 
-The first type of metadata block is named ``pyproject`` which represents
-content similar to what one would see in a ``pyproject.toml`` file.
+The first type of metadata block is named ``script`` which contains
+script metadata (dependency data and tool configuration).
 
-This document MAY include the ``[run]`` and ``[tool]`` tables.
+This document MAY include top-level fields ``dependencies`` and ``requires-python``,
+and MAY optionally include a ``[tool]`` table.
 
-The :ref:`tool table ` MAY be used by any tool,
-script runner or otherwise, to configure behavior.
+The ``[tool]`` MAY be used by any tool, script runner or otherwise, to configure
+behavior. It has the same semantics as the :ref:`[tool] table in pyproject.toml
+`
 
-The ``[run]`` table MAY include the following optional fields:
+The top-level fields are:
 
 * ``dependencies``: A list of strings that specifies the runtime dependencies
   of the script. Each entry MUST be a valid
@@ -107,11 +102,11 @@ Script runners SHOULD error if no version of Python that satisfies the specified
 Example
 -------
 
-The following is an example of a script with an embedded ``pyproject.toml``:
+The following is an example of a script with embedded metadata:
 
 .. code:: python
 
-    # /// pyproject
+    # /// script
     # [run]
     # requires-python = ">=3.11"
     # dependencies = [
@@ -127,23 +122,6 @@ The following is an example of a script with an embedded ``pyproject.toml``:
     data = resp.json()
     pprint([(k, v["title"]) for k, v in data.items()][:10])
 
-The following is an example of a proposed syntax for single-file Rust
-projects that embeds their equivalent of ``pyproject.toml``, which is called
-``Cargo.toml``:
-
-.. code:: rust
-
-    #!/usr/bin/env cargo
-
-    //! ```cargo
-    //! [dependencies]
-    //! regex = "1.8.0"
-    //! ```
-
-    fn main() {
-        let re = Regex::new(r"^\d{4}-\d{2}-\d{2}$").unwrap();
-        println!("Did our date match? {}", re.is_match("2014-01-01"));
-    }
 
 Reference Implementation
 ========================
@@ -159,7 +137,7 @@ higher.
    REGEX = r'(?m)^# /// (?P[a-zA-Z0-9-]+)$\s(?P(^#(| .*)$\s)+)^# ///$'
 
    def read(script: str) -> dict | None:
-       name = 'pyproject'
+       name = 'script'
        matches = list(
            filter(lambda m: m.group('type') == name, re.finditer(REGEX, script))
        )
@@ -196,7 +174,7 @@ __ https://tomlkit.readthedocs.io/en/latest/
        )
 
        config = tomlkit.parse(content)
-       config['project']['dependencies'].append(dependency)
+       config['dependencies'].append(dependency)
        new_content = ''.join(
            f'# {line}' if line.strip() else f'#{line}'
            for line in tomlkit.dumps(config).splitlines(keepends=True)
@@ -239,3 +217,7 @@ History
 =======
 
 - October 2023: This specification was conditionally approved through :pep:`723`.
+- January 2024: Through amendments to :pep:`723`, the ``pyproject`` metadata
+  block type was renamed to ``script``, and the ``[run]`` table was dropped,
+  making the ``dependencies`` and ``requires-python`` keys
+  top-level. Additionally, the specification is no longer provisional.

From b33317c71c997f134ee31c56be6de7706f63236e Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sun, 14 Jan 2024 13:20:20 +0100
Subject: [PATCH 0618/1072] Fixes

---
 source/specifications/inline-script-metadata.rst | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/source/specifications/inline-script-metadata.rst b/source/specifications/inline-script-metadata.rst
index ad667e94a..dee1c2634 100644
--- a/source/specifications/inline-script-metadata.rst
+++ b/source/specifications/inline-script-metadata.rst
@@ -90,11 +90,6 @@ The top-level fields are:
   the script is compatible. The value of this field MUST be a valid
   :ref:`version specifier `.
 
-Any future specifications that define additional fields for the ``[run]`` table
-when used in a ``pyproject.toml`` file MUST include the aforementioned fields
-exactly as specified. The fields defined by this specification are equally as
-applicable to full-fledged projects as they are to single-file scripts.
-
 Script runners MUST error if the specified ``dependencies`` cannot be provided.
 Script runners SHOULD error if no version of Python that satisfies the specified
 ``requires-python`` can be provided.
@@ -107,7 +102,6 @@ The following is an example of a script with embedded metadata:
 .. code:: python
 
     # /// script
-    # [run]
     # requires-python = ">=3.11"
     # dependencies = [
     #   "requests<3",

From 4a83dbac2a8c8fe80b4d53340b0beafe9887515b Mon Sep 17 00:00:00 2001
From: Laurie O 
Date: Tue, 2 Jan 2024 11:02:01 +1000
Subject: [PATCH 0619/1072] Add simple repo API specs from PEPs

---
 .../specifications/simple-repository-api.rst  | 917 ++++++++++++++++++
 1 file changed, 917 insertions(+)

diff --git a/source/specifications/simple-repository-api.rst b/source/specifications/simple-repository-api.rst
index 70c0040d2..14644fa27 100644
--- a/source/specifications/simple-repository-api.rst
+++ b/source/specifications/simple-repository-api.rst
@@ -18,3 +18,920 @@ providing package metadata independently from a package in
 The JSON format is defined in :pep:`691`, with additional fields
 added in :pep:`700`, and revisions around providing package metadata
 independently from a package in :pep:`714`.
+
+Base HTML API
+=============
+
+A repository that implements the simple API is defined by its base URL, this is
+the top level URL that all additional URLs are below. The API is named the
+"simple" repository due to the fact that PyPI's base URL is
+``https://pypi.org/simple/``.
+
+.. note:: All subsequent URLs in this document will be relative to this base
+          URL (so given PyPI's URL, a URL of ``/foo/`` would be
+          ``https://pypi.org/simple/foo/``.
+
+
+Within a repository, the root URL (``/`` for this PEP which represents the base
+URL) **MUST** be a valid HTML5 page with a single anchor element per project in
+the repository. The text of the anchor tag **MUST** be the name of
+the project and the href attribute **MUST** link to the URL for that particular
+project. As an example::
+
+   
+   
+     
+       frob
+       spamspamspam
+     
+   
+
+Below the root URL is another URL for each individual project contained within
+a repository. The format of this URL is ``//`` where the ````
+is replaced by the normalized name for that project, so a project named
+"HolyGrail" would have a URL like ``/holygrail/``. This URL must respond with
+a valid HTML5 page with a single anchor element per file for the project. The
+href attribute **MUST** be a URL that links to the location of the file for
+download, and the text of the anchor tag **MUST** match the final path
+component (the filename) of the URL. The URL **SHOULD** include a hash in the
+form of a URL fragment with the following syntax: ``#=``,
+where ```` is the lowercase name of the hash function (such as
+``sha256``) and ```` is the hex encoded digest.
+
+In addition to the above, the following constraints are placed on the API:
+
+* All URLs which respond with an HTML5 page **MUST** end with a ``/`` and the
+  repository **SHOULD** redirect the URLs without a ``/`` to add a ``/`` to the
+  end.
+
+* URLs may be either absolute or relative as long as they point to the correct
+  location.
+
+* There are no constraints on where the files must be hosted relative to the
+  repository.
+
+* There may be any other HTML elements on the API pages as long as the required
+  anchor elements exist.
+
+* Repositories **MAY** redirect unnormalized URLs to the canonical normalized
+  URL (e.g. ``/Foobar/`` may redirect to ``/foobar/``), however clients
+  **MUST NOT** rely on this redirection and **MUST** request the normalized
+  URL.
+
+* Repositories **SHOULD** choose a hash function from one of the ones
+  guaranteed to be available via the ``hashlib`` module in the Python standard
+  library (currently ``md5``, ``sha1``, ``sha224``, ``sha256``, ``sha384``,
+  ``sha512``). The current recommendation is to use ``sha256``.
+
+* If there is a GPG signature for a particular distribution file it **MUST**
+  live alongside that file with the same name with a ``.asc`` appended to it.
+  So if the file ``/packages/HolyGrail-1.0.tar.gz`` existed and had an
+  associated signature, the signature would be located at
+  ``/packages/HolyGrail-1.0.tar.gz.asc``.
+
+* A repository **MAY** include a ``data-gpg-sig`` attribute on a file link with
+  a value of either ``true`` or ``false`` to indicate whether or not there is a
+  GPG signature. Repositories that do this **SHOULD** include it on every link.
+
+* A repository **MAY** include a ``data-requires-python`` attribute on a file
+  link. This exposes the *Requires-Python* metadata field, specified in :pep:`345`,
+  for the corresponding release. Where this is present, installer tools
+  **SHOULD** ignore the download when installing to a Python version that
+  doesn't satisfy the requirement. For example::
+
+      ...
+
+  In the attribute value, < and > have to be HTML encoded as ``<`` and
+  ``>``, respectively.
+
+Normalized Names
+----------------
+
+This PEP references the concept of a "normalized" project name. As per :pep:`426`
+the only valid characters in a name are the ASCII alphabet, ASCII numbers,
+``.``, ``-``, and ``_``. The name should be lowercased with all runs of the
+characters ``.``, ``-``, or ``_`` replaced with a single ``-`` character. This
+can be implemented in Python with the ``re`` module::
+
+   import re
+
+   def normalize(name):
+       return re.sub(r"[-_.]+", "-", name).lower()
+
+Adding "Yank" Support to the Simple API
+=======================================
+
+Links in the simple repository **MAY** have a ``data-yanked`` attribute
+which may have no value, or may have an arbitrary string as a value. The
+presence of a ``data-yanked`` attribute **SHOULD** be interpreted as
+indicating that the file pointed to by this particular link has been
+"Yanked", and should not generally be selected by an installer, except
+under specific scenarios.
+
+The value of the ``data-yanked`` attribute, if present, is an arbitrary
+string that represents the reason for why the file has been yanked. Tools
+that process the simple repository API **MAY** surface this string to
+end users.
+
+The yanked attribute is not immutable once set, and may be rescinded in
+the future (and once rescinded, may be reset as well). Thus API users
+**MUST** be able to cope with a yanked file being "unyanked" (and even
+yanked again).
+
+
+Installers
+----------
+
+The desirable experience for users is that once a file is yanked, when
+a human being is currently trying to directly install a yanked file, that
+it fails as if that file had been deleted. However, when a human did that
+awhile ago, and now a computer is just continuing to mechanically follow
+the original order to install the now yanked file, then it acts as if it
+had not been yanked.
+
+An installer **MUST** ignore yanked releases, if the selection constraints
+can be satisfied with a non-yanked version, and **MAY** refuse to use a
+yanked release even if it means that the request cannot be satisfied at all.
+An implementation **SHOULD** choose a policy that follows the spirit of the
+intention above, and that prevents "new" dependencies on yanked
+releases/files.
+
+What this means is left up to the specific installer, to decide how to best
+fit into the overall usage of their installer. However, there are two
+suggested approaches to take:
+
+1. Yanked files are always ignored, unless they are the only file that
+   matches a version specifier that "pins" to an exact version using
+   either ``==`` (without any modifiers that make it a range, such as
+   ``.*``) or ``===``. Matching this version specifier should otherwise
+   be done as per :pep:`440` for things like local versions, zero padding,
+   etc.
+2. Yanked files are always ignored, unless they are the only file that
+   matches what a lock file (such as ``Pipfile.lock`` or ``poetry.lock``)
+   specifies to be installed. In this case, a yanked file **SHOULD** not
+   be used when creating or updating a lock file from some input file or
+   command.
+
+Regardless of the specific strategy that an installer chooses for deciding
+when to install yanked files, an installer **SHOULD** emit a warning when
+it does decide to install a yanked file. That warning **MAY** utilize the
+value of the ``data-yanked`` attribute (if it has a value) to provide more
+specific feedback to the user about why that file had been yanked.
+
+
+Mirrors
+-------
+
+Mirrors can generally treat yanked files one of two ways:
+
+1. They may choose to omit them from their simple repository API completely,
+   providing a view over the repository that shows only "active", unyanked
+   files.
+2. They may choose to include yanked files, and additionally mirror the
+   ``data-yanked`` attribute as well.
+
+Mirrors **MUST NOT** mirror a yanked file without also mirroring the
+``data-yanked`` attribute for it.
+
+Versioning PyPI's Simple API
+============================
+
+This PEP proposes the inclusion of a meta tag on the responses of every
+successful request to a simple API page, which contains a name attribute
+of "pypi:repository-version", and a content that is a :pep:`440` compatible
+version number, which is further constrained to ONLY be Major.Minor, and
+none of the additional features supported by :pep:`440`.
+
+This would end up looking like::
+
+  
+
+When interpreting the repository version:
+
+* Incrementing the major version is used to signal a backwards
+  incompatible change such that existing clients would no longer be
+  expected to be able to meaningfully use the API.
+* Incrementing the minor version is used to signal a backwards
+  compatible change such that existing clients would still be
+  expected to be able to meaningfully use the API.
+
+It is left up to the discretion of any future PEPs as to what
+specifically constitutes a backwards incompatible vs compatible change
+beyond the broad suggestion that existing clients will be able to
+"meaningfully" continue to use the API, and can include adding,
+modifying, or removing existing features.
+
+It is expectation of this PEP that the major version will never be
+incremented, and any future major API evolutions would utilize a
+different mechanism for API evolution. However the major version
+is included to disambiguate with future versions (e.g. a hypothetical
+simple api v2 that lived at /v2/, but which would be confusing if the
+repository-version was set to a version >= 2).
+
+This PEP sets the current API version to "1.0", and expects that
+future PEPs that further evolve the simple API will increment the
+minor version number.
+
+
+Clients
+-------
+
+Clients interacting with the simple API **SHOULD** introspect each
+response for the repository version, and if that data does not exist
+**MUST** assume that it is version 1.0.
+
+When encountering a major version greater than expected, clients
+**MUST** hard fail with an appropriate error message for the user.
+
+When encountering a minor version greater than expected, clients
+**SHOULD** warn users with an appropriate message.
+
+Clients **MAY** still continue to use feature detection in order to
+determine what features a repository uses.
+
+Serve Distribution Metadata in the Simple Repository API
+========================================================
+
+In a simple repository's project page, each anchor tag pointing to a
+distribution **MAY** have a ``data-dist-info-metadata`` attribute. The
+presence of the attribute indicates the distribution represented by
+the anchor tag **MUST** contain a Core Metadata file that will not be
+modified when the distribution is processed and/or installed.
+
+If a ``data-dist-info-metadata`` attribute is present, the repository
+**MUST** serve the distribution's Core Metadata file alongside the
+distribution with a ``.metadata`` appended to the distribution's file
+name. For example, the Core Metadata of a distribution served at
+``/files/distribution-1.0-py3.none.any.whl`` would be located at
+``/files/distribution-1.0-py3.none.any.whl.metadata``. This is similar
+to how :pep:`503` specifies the GPG signature file's location.
+
+The repository **SHOULD** provide the hash of the Core Metadata file
+as the ``data-dist-info-metadata`` attribute's value using the syntax
+``=``, where ```` is the lower cased
+name of the hash function used, and ```` is the hex encoded
+digest. The repository **MAY** use ``true`` as the attribute's value
+if a hash is unavailable.
+
+Backwards Compatibility
+-----------------------
+
+If an anchor tag lacks the ``data-dist-info-metadata`` attribute,
+tools are expected to revert to their current behaviour of downloading
+the distribution to inspect the metadata.
+
+Older tools not supporting the new ``data-dist-info-metadata``
+attribute are expected to ignore the attribute and maintain their
+current behaviour of downloading the distribution to inspect the
+metadata. This is similar to how prior ``data-`` attribute additions
+expect existing tools to operate.
+
+JSON-based Simple API for Python Package Indexes
+================================================
+
+To enable response parsing with only the standard library, this PEP specifies that
+all responses (besides the files themselves, and the HTML responses from
+:pep:`503`) should be serialized using `JSON `_.
+
+To enable zero configuration discovery and to minimize the amount of additional HTTP
+requests, this PEP extends :pep:`503` such that all of the API endpoints (other than the
+files themselves) will utilize HTTP content negotiation to allow client and server to
+select the correct serialization format to serve, i.e. either HTML or JSON.
+
+
+Versioning
+----------
+
+Versioning will adhere to :pep:`629` format (``Major.Minor``), which has defined the
+existing HTML responses to be ``1.0``. Since this PEP does not introduce new features
+into the API, rather it describes a different serialization format for the existing
+features, this PEP does not change the existing ``1.0`` version, and instead just
+describes how to serialize that into JSON.
+
+Similar to :pep:`629`, the major version number **MUST** be incremented if any
+changes to the new format would result in no longer being able to expect existing
+clients to meaningfully understand the format.
+
+Likewise, the minor version **MUST** be incremented if features are
+added or removed from the format, but existing clients would be expected to continue
+to meaningfully understand the format.
+
+Changes that would not result in existing clients being unable to meaningfully
+understand the format and which do not represent features being added or removed
+may occur without changing the version number.
+
+This is intentionally vague, as this PEP believes it is best left up to future PEPs
+that make any changes to the API to investigate and decide whether or not that
+change should increment the major or minor version.
+
+Future versions of the API may add things that can only be represented in a subset
+of the available serializations of that version. All serializations version numbers,
+within a major version, **SHOULD** be kept in sync, but the specifics of how a
+feature serializes into each format may differ, including whether or not that feature
+is present at all.
+
+It is the intent of this PEP that the API should be thought of as URL endpoints that
+return data, whose interpretation is defined by the version of that data, and then
+serialized into the target serialization format.
+
+
+.. _json-serialization:
+
+JSON Serialization
+------------------
+
+The URL structure from :pep:`503` still applies, as this PEP only adds an additional
+serialization format for the already existing API.
+
+The following constraints apply to all JSON serialized responses described in this
+PEP:
+
+* All JSON responses will *always* be a JSON object rather than an array or other
+  type.
+
+* While JSON doesn't natively support an URL type, any value that represents an
+  URL in this API may be either absolute or relative as long as they point to
+  the correct location. If relative, they are relative to the current URL as if
+  it were HTML.
+
+* Additional keys may be added to any dictionary objects in the API responses
+  and clients **MUST** ignore keys that they don't understand.
+
+* All JSON responses will have a ``meta`` key, which contains information related to
+  the response itself, rather than the content of the response.
+
+* All JSON responses will have a ``meta.api-version`` key, which will be a string that
+  contains the :pep:`629` ``Major.Minor`` version number, with the same fail/warn
+  semantics as defined in :pep:`629`.
+
+* All requirements of :pep:`503` that are not HTML specific still apply.
+
+
+Project List
+~~~~~~~~~~~~
+
+The root URL ``/`` for this PEP (which represents the base URL) will be a JSON encoded
+dictionary which has a two keys:
+
+- ``projects``: An array where each entry is a dictionary with a single key, ``name``, which represents string of the project name.
+- ``meta``: The general response metadata as `described earlier `__.
+
+As an example:
+
+.. code-block:: json
+
+    {
+      "meta": {
+        "api-version": "1.0"
+      },
+      "projects": [
+        {"name": "Frob"},
+        {"name": "spamspamspam"}
+      ]
+    }
+
+
+.. note::
+
+  The ``name`` field is the same as the one from :pep:`503`, which does not specify
+  whether it is the non-normalized display name or the normalized name. In practice
+  different implementations of these PEPs are choosing differently here, so relying
+  on it being either non-normalized or normalized is relying on an implementation
+  detail of the repository in question.
+
+
+.. note::
+
+  While the ``projects`` key is an array, and thus is required to be in some kind
+  of an order, neither :pep:`503` nor this PEP requires any specific ordering nor
+  that the ordering is consistent from one request to the next. Mentally this is
+  best thought of as a set, but both JSON and HTML lack the functionality to have
+  sets.
+
+
+Project Detail
+~~~~~~~~~~~~~~
+
+The format of this URL is ``//`` where the ```` is replaced by the
+:pep:`503` normalized name for that project, so a project named "Silly_Walk" would
+have a URL like ``/silly-walk/``.
+
+This URL must respond with a JSON encoded dictionary that has three keys:
+
+- ``name``: The normalized name of the project.
+- ``files``: A list of dictionaries, each one representing an individual file.
+- ``meta``: The general response metadata as `described earlier `__.
+
+Each individual file dictionary has the following keys:
+
+- ``filename``: The filename that is being represented.
+- ``url``: The URL that the file can be fetched from.
+- ``hashes``: A dictionary mapping a hash name to a hex encoded digest of the file.
+  Multiple hashes can be included, and it is up to the client to decide what to do
+  with multiple hashes (it may validate all of them or a subset of them, or nothing
+  at all). These hash names **SHOULD** always be normalized to be lowercase.
+
+  The ``hashes`` dictionary **MUST** be present, even if no hashes are available
+  for the file, however it is **HIGHLY** recommended that at least one secure,
+  guaranteed-to-be-available hash is always included.
+
+  By default, any hash algorithm available via `hashlib
+  `_ (specifically any that can
+  be passed to ``hashlib.new()`` and do not require additional parameters) can
+  be used as a key for the hashes dictionary. At least one secure algorithm from
+  ``hashlib.algorithms_guaranteed`` **SHOULD** always be included. At the time
+  of this PEP, ``sha256`` specifically is recommended.
+- ``requires-python``: An **optional** key that exposes the *Requires-Python*
+  metadata field, specified in :pep:`345`. Where this is present, installer tools
+  **SHOULD** ignore the download when installing to a Python version that
+  doesn't satisfy the requirement.
+
+  Unlike ``data-requires-python`` in :pep:`503`, the ``requires-python`` key does not
+  require any special escaping other than anything JSON does naturally.
+- ``dist-info-metadata``: An **optional** key that indicates
+  that metadata for this file is available, via the same location as specified in
+  :pep:`658` (``{file_url}.metadata``). Where this is present, it **MUST** be
+  either a boolean to indicate if the file has an associated metadata file, or a
+  dictionary mapping hash names to a hex encoded digest of the metadata's hash.
+
+  When this is a dictionary of hashes instead of a boolean, then all the same
+  requirements and recommendations as the ``hashes`` key hold true for this key as
+  well.
+
+  If this key is missing then the metadata file may or may not exist. If the key
+  value is truthy, then the metadata file is present, and if it is falsey then it
+  is not.
+
+  It is recommended that servers make the hashes of the metadata file available if
+  possible.
+- ``gpg-sig``: An **optional** key that acts a boolean to indicate if the file has
+  an associated GPG signature or not. The URL for the signature file follows what
+  is specified in :pep:`503` (``{file_url}.asc``). If this key does not exist, then
+  the signature may or may not exist.
+- ``yanked``: An **optional** key which may be either a boolean to indicate if the
+  file has been yanked, or a non empty, but otherwise arbitrary, string to indicate
+  that a file has been yanked with a specific reason. If the ``yanked`` key is present
+  and is a truthy value, then it **SHOULD** be interpreted as indicating that the
+  file pointed to by the ``url`` field has been "Yanked" as per :pep:`592`.
+
+As an example:
+
+.. code-block:: json
+
+    {
+      "meta": {
+        "api-version": "1.0"
+      },
+      "name": "holygrail",
+      "files": [
+        {
+          "filename": "holygrail-1.0.tar.gz",
+          "url": "https://example.com/files/holygrail-1.0.tar.gz",
+          "hashes": {"sha256": "...", "blake2b": "..."},
+          "requires-python": ">=3.7",
+          "yanked": "Had a vulnerability"
+        },
+        {
+          "filename": "holygrail-1.0-py3-none-any.whl",
+          "url": "https://example.com/files/holygrail-1.0-py3-none-any.whl",
+          "hashes": {"sha256": "...", "blake2b": "..."},
+          "requires-python": ">=3.7",
+          "dist-info-metadata": true
+        }
+      ]
+    }
+
+
+.. note::
+
+  While the ``files`` key is an array, and thus is required to be in some kind
+  of an order, neither :pep:`503` nor this PEP requires any specific ordering nor
+  that the ordering is consistent from one request to the next. Mentally this is
+  best thought of as a set, but both JSON and HTML lack the functionality to have
+  sets.
+
+
+Content-Types
+-------------
+
+This PEP proposes that all responses from the Simple API will have a standard
+content type that describes what the response is (a Simple API response), what
+version of the API it represents, and what serialization format has been used.
+
+The structure of this content type will be:
+
+.. code-block:: text
+
+    application/vnd.pypi.simple.$version+format
+
+Since only major versions should be disruptive to clients attempting to
+understand one of these API responses, only the major version will be included
+in the content type, and will be prefixed with a ``v`` to clarify that it is a
+version number.
+
+Which means that for the existing 1.0 API, the content types would be:
+
+- **JSON:** ``application/vnd.pypi.simple.v1+json``
+- **HTML:** ``application/vnd.pypi.simple.v1+html``
+
+In addition to the above, a special "meta" version is supported named ``latest``,
+whose purpose is to allow clients to request the absolute latest version, without
+having to know ahead of time what that version is. It is recommended however,
+that clients be explicit about what versions they support.
+
+To support existing clients which expect the existing :pep:`503` API responses to
+use the ``text/html`` content type, this PEP further defines ``text/html`` as an alias
+for the ``application/vnd.pypi.simple.v1+html`` content type.
+
+
+Version + Format Selection
+--------------------------
+
+Now that there is multiple possible serializations, we need a mechanism to allow
+clients to indicate what serialization formats they're able to understand. In
+addition, it would be beneficial if any possible new major version to the API can
+be added without disrupting existing clients expecting the previous API version.
+
+To enable this, this PEP standardizes on the use of HTTP's
+`Server-Driven Content Negotiation `_.
+
+While this PEP won't fully describe the entirety of server-driven content
+negotiation, the flow is roughly:
+
+1. The client makes an HTTP request containing an ``Accept`` header listing all
+   of the version+format content types that they are able to understand.
+2. The server inspects that header, selects one of the listed content types,
+   then returns a response using that content type (treating the absence of
+   an ``Accept`` header as ``Accept: */*``).
+3. If the server does not support any of the content types in the ``Accept``
+   header then they are able to choose between 3 different options for how to
+   respond:
+
+   a. Select a default content type other than what the client has requested
+      and return a response with that.
+   b. Return a HTTP ``406 Not Acceptable`` response to indicate that none of
+      the requested content types were available, and the server was unable
+      or unwilling to select a default content type to respond with.
+   c. Return a HTTP ``300 Multiple Choices`` response that contains a list of
+      all of the possible responses that could have been chosen.
+4. The client interprets the response, handling the different types of responses
+   that the server may have responded with.
+
+This PEP does not specify which choices the server makes in regards to handling
+a content type that it isn't able to return, and clients **SHOULD** be prepared
+to handle all of the possible responses in whatever way makes the most sense for
+that client.
+
+However, as there is no standard format for how a ``300 Multiple Choices``
+response can be interpreted, this PEP highly discourages servers from utilizing
+that option, as clients will have no way to understand and select a different
+content-type to request. In addition, it's unlikely that the client *could*
+understand a different content type anyways, so at best this response would
+likely just be treated the same as a ``406 Not Acceptable`` error.
+
+This PEP **does** require that if the meta version ``latest`` is being used, the
+server **MUST** respond with the content type for the actual version that is
+contained in the response
+(i.e. A ``Accept: application/vnd.pypi.simple.latest+json`` request that returns
+a ``v1.x`` response should have a ``Content-Type`` of
+``application/vnd.pypi.simple.v1+json``).
+
+The ``Accept`` header is a comma separated list of content types that the client
+understands and is able to process. It supports three different formats for each
+content type that is being requested:
+
+- ``$type/$subtype``
+- ``$type/*``
+- ``*/*``
+
+For the use of selecting a version+format, the most useful of these is
+``$type/$subtype``, as that is the only way to actually specify the version
+and format you want.
+
+The order of the content types listed in the ``Accept`` header does not have any
+specific meaning, and the server **SHOULD** consider all of them to be equally
+valid to respond with. If a client wishes to specify that they prefer a specific
+content type over another, they may use the ``Accept`` header's
+`quality value `_
+syntax.
+
+This allows a client to specify a priority for a specific entry in their
+``Accept`` header, by appending a ``;q=`` followed by a value between ``0`` and
+``1`` inclusive, with up to 3 decimal digits. When interpreting this value,
+an entry with a higher quality has priority over an entry with a lower quality,
+and any entry without a quality present will default to a quality of ``1``.
+
+However, clients should keep in mind that a server is free to select **any** of
+the content types they've asked for, regardless of their requested priority, and
+it may even return a content type that they did **not** ask for.
+
+To aid clients in determining the content type of the response that they have
+received from an API request, this PEP requires that servers always include a
+``Content-Type`` header indicating the content type of the response. This is
+technically a backwards incompatible change, however in practice
+`pip has been enforcing this requirement `_
+so the risks for actual breakages is low.
+
+An example of how a client can operate would look like:
+
+.. code-block:: python
+
+    import email.message
+    import requests
+
+    def parse_content_type(header: str) -> str:
+        m = email.message.Message()
+        m["content-type"] = header
+        return m.get_content_type()
+
+    # Construct our list of acceptable content types, we want to prefer
+    # that we get a v1 response serialized using JSON, however we also
+    # can support a v1 response serialized using HTML. For compatibility
+    # we also request text/html, but we prefer it least of all since we
+    # don't know if it's actually a Simple API response, or just some
+    # random HTML page that we've gotten due to a misconfiguration.
+    CONTENT_TYPES = [
+        "application/vnd.pypi.simple.v1+json",
+        "application/vnd.pypi.simple.v1+html;q=0.2",
+        "text/html;q=0.01",  # For legacy compatibility
+    ]
+    ACCEPT = ", ".join(CONTENT_TYPES)
+
+
+    # Actually make our request to the API, requesting all of the content
+    # types that we find acceptable, and letting the server select one of
+    # them out of the list.
+    resp = requests.get("https://pypi.org/simple/", headers={"Accept": ACCEPT})
+
+    # If the server does not support any of the content types you requested,
+    # AND it has chosen to return a HTTP 406 error instead of a default
+    # response then this will raise an exception for the 406 error.
+    resp.raise_for_status()
+
+
+    # Determine what kind of response we've gotten to ensure that it is one
+    # that we can support, and if it is, dispatch to a function that will
+    # understand how to interpret that particular version+serialization. If
+    # we don't understand the content type we've gotten, then we'll raise
+    # an exception.
+    content_type = parse_content_type(resp.headers.get("content-type", ""))
+    match content_type:
+        case "application/vnd.pypi.simple.v1+json":
+            handle_v1_json(resp)
+        case "application/vnd.pypi.simple.v1+html" | "text/html":
+            handle_v1_html(resp)
+        case _:
+            raise Exception(f"Unknown content type: {content_type}")
+
+If a client wishes to only support HTML or only support JSON, then they would
+just remove the content types that they do not want from the ``Accept`` header,
+and turn receiving them into an error.
+
+
+Alternative Negotiation Mechanisms
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+While using HTTP's Content negotiation is considered the standard way for a client
+and server to coordinate to ensure that the client is getting an HTTP response that
+it is able to understand, there are situations where that mechanism may not be
+sufficient. For those cases this PEP has alternative negotiation mechanisms that
+may *optionally* be used instead.
+
+
+URL Parameter
+^^^^^^^^^^^^^
+
+Servers that implement the Simple API may choose to support an URL parameter named
+``format`` to allow the clients to request a specific version of the URL.
+
+The value of the ``format`` parameter should be **one** of the valid content types.
+Passing multiple content types, wild cards, quality values, etc... is **not**
+supported.
+
+Supporting this parameter is optional, and clients **SHOULD NOT** rely on it for
+interacting with the API. This negotiation mechanism is intended to allow for easier
+human based exploration of the API within a browser, or to allow documentation or
+notes to link to a specific version+format.
+
+Servers that do not support this parameter may choose to return an error when it is
+present, or they may simple ignore its presence.
+
+When a server does implement this parameter, it **SHOULD** take precedence over any
+values in the client's ``Accept`` header, and if the server does not support the
+requested format, it may choose to fall back to the ``Accept`` header, or choose any
+of the error conditions that standard server-driven content negotiation typically
+has (e.g. ``406 Not Available``, ``303 Multiple Choices``, or selecting a default
+type to return).
+
+
+Endpoint Configuration
+^^^^^^^^^^^^^^^^^^^^^^
+
+This option technically is not a special option at all, it is just a natural
+consequence of using content negotiation and allowing servers to select which of the
+available content types is their default.
+
+If a server is unwilling or unable to implement the server-driven content negotiation,
+and would instead rather require users to explicitly configure their client to select
+the version they want, then that is a supported configuration.
+
+To enable this, a server should make multiple endpoints (for instance,
+``/simple/v1+html/`` and/or ``/simple/v1+json/``) for each version+format that they
+wish to support. Under that endpoint, they can host a copy of their repository that
+only supports one (or a subset) of the content-types. When a client makes a request
+using the ``Accept`` header, the server can ignore it and return the content type
+that corresponds to that endpoint.
+
+For clients that wish to require specific configuration, they can keep track of
+which version+format a specific repository URL was configured for, and when making
+a request to that server, emit an ``Accept`` header that *only* includes the correct
+content type.
+
+
+TUF Support - PEP 458
+---------------------
+
+:pep:`458` requires that all API responses are hashable and that they can be uniquely
+identified by a path relative to the repository root. For a Simple API repository, the
+target path is the Root of our API (e.g. ``/simple/`` on PyPI). This creates
+challenges when accessing the API using a TUF client instead of directly using a
+standard HTTP client, as the TUF client cannot handle the fact that a target could
+have multiple different representations that all hash differently.
+
+:pep:`458` does not specify what the target path should be for the Simple API, but
+TUF requires that the target paths be "file-like", in other words, a path like
+``simple/PROJECT/`` is not acceptable, because it technically points to a
+directory.
+
+The saving grace is that the target path does not *have* to actually match the URL
+being fetched from the Simple API, and it can just be a sigil that the fetching code
+knows how to transform into the actual URL that needs to be fetched. This same thing
+can hold true for other aspects of the actual HTTP request, such as the ``Accept``
+header.
+
+Ultimately figuring out how to map a directory to a filename is out of scope for this
+PEP (but it would be in scope for :pep:`458`), and this PEP defers making a decision
+about how exactly to represent this inside of :pep:`458` metadata.
+
+However, it appears that the current WIP branch against pip that attempts to implement
+:pep:`458` is using a target path like ``simple/PROJECT/index.html``. This could be
+modified to include the API version and serialization format using something like
+``simple/PROJECT/vnd.pypi.simple.vN.FORMAT``. So the v1 HTML format would be
+``simple/PROJECT/vnd.pypi.simple.v1.html`` and the v1 JSON format would be
+``simple/PROJECT/vnd.pypi.simple.v1.json``.
+
+In this case, since ``text/html`` is an alias to ``application/vnd.pypi.simple.v1+html``
+when interacting through TUF, it likely will make the most sense to normalize to the
+more explicit name.
+
+Likewise the ``latest`` metaversion should not be included in the targets, only
+explicitly declared versions should be supported.
+
+Recommendations
+---------------
+
+This section is non-normative, and represents what the PEP authors believe to be
+the best default implementation decisions for something implementing this PEP, but
+it does **not** represent any sort of requirement to match these decisions.
+
+These decisions have been chosen to maximize the number of requests that can be
+moved onto the newest version of an API, while maintaining the greatest amount
+of compatibility. In addition, they've also tried to make using the API provide
+guardrails that attempt to push clients into making the best choices it can.
+
+It is recommended that servers:
+
+- Support all 3 content types described in this PEP, using server-driven
+  content negotiation, for as long as they reasonably can, or at least as
+  long as they're receiving non trivial traffic that uses the HTML responses.
+
+- When encountering an ``Accept`` header that does not contain any content types
+  that it knows how to work with, the server should not ever return a
+  ``300 Multiple Choice`` response, and instead return a ``406 Not Acceptable``
+  response.
+
+  - However, if choosing to use the endpoint configuration, you should prefer to
+    return a ``200 OK`` response in the expected content type for that endpoint.
+
+- When selecting an acceptable version, the server should choose the highest version
+  that the client supports, with the most expressive/featureful serialization format,
+  taking into account the specificity of the client requests as well as any
+  quality priority values they have expressed, and it should only use the
+  ``text/html`` content type as a last resort.
+
+It is recommended that clients:
+
+- Support all 3 content types described in this PEP, using server-driven
+  content negotiation, for as long as they reasonably can.
+
+- When constructing an ``Accept`` header, include all of the content types
+  that you support.
+
+  You should generally *not* include a quality priority value for your content
+  types, unless you have implementation specific reasons that you want the
+  server to take into account (for example, if you're using the standard library
+  HTML parser and you're worried that there may be some kinds of HTML responses
+  that you're unable to parse in some edge cases).
+
+  The one exception to this recommendation is that it is recommended that you
+  *should* include a ``;q=0.01`` value on the legacy ``text/html`` content type,
+  unless it is the only content type that you are requesting.
+
+- Explicitly select what versions they are looking for, rather than using the
+  ``latest`` meta version during normal operation.
+
+- Check the ``Content-Type`` of the response and ensure it matches something
+  that you were expecting.
+
+Additional Fields for the Simple API for Package Indexes
+========================================================
+
+This specification defines version 1.1 of the simple repository API. For the
+HTML version of the API, there is no change from version 1.0. For the JSON
+version of the API, the following changes are made:
+
+- The ``api-version`` must specify version 1.1 or later.
+- A new ``versions`` key is added at the top level.
+- Two new "file information" keys, ``size`` and ``upload-time``, are added to
+  the ``files`` data.
+- Keys (at any level) with a leading underscore are reserved as private for
+  index server use. No future standard will assign a meaning to any such key.
+
+The ``versions`` and ``size`` keys are mandatory. The ``upload-time`` key is
+optional.
+
+Versions
+--------
+
+An additional key, ``versions`` MUST be present at the top level, in addition to
+the keys ``name``, ``files`` and ``meta`` defined in :pep:`691`. This key MUST
+contain a list of version strings specifying all of the project versions uploaded
+for this project. The value is logically a set, and as such may not contain
+duplicates, and the order of the values is not significant.
+
+All of the files listed in the ``files`` key MUST be associated with one of the
+versions in the ``versions`` key. The ``versions`` key MAY contain versions with
+no associated files (to represent versions with no files uploaded, if the server
+has such a concept).
+
+Note that because servers may hold "legacy" data from before the adoption of
+:pep:`440`, version strings currently cannot be required to be valid :pep:`440`
+versions, and therefore cannot be assumed to be orderable using the :pep:`440`
+rules. However, servers SHOULD use normalised :pep:`440` versions where
+possible.
+
+
+Additional file information
+---------------------------
+
+Two new keys are added to the ``files`` key.
+
+- ``size``: This field is mandatory. It MUST contain an integer which is the
+  file size in bytes.
+- ``upload-time``: This field is optional. If present, it MUST contain a valid
+  ISO 8601 date/time string, in the format ``yyyy-mm-ddThh:mm:ss.ffffffZ``,
+  which represents the time the file was uploaded to the index. As indicated by
+  the ``Z`` suffix, the upload time MUST use the UTC timezone. The fractional
+  seconds part of the timestamp (the ``.ffffff`` part) is optional, and if
+  present may contain up to 6 digits of precision. If a server does not record
+  upload time information for a file, it MAY omit the ``upload-time`` key.
+
+Rename dist-info-metadata in the Simple API
+===========================================
+
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+
+Servers
+-------
+
+The :pep:`658` metadata, when used in the HTML representation of the Simple API,
+**MUST** be emitted using the attribute name ``data-core-metadata``, with the
+supported values remaining the same.
+
+The :pep:`658` metadata, when used in the :pep:`691` JSON representation of the
+Simple API, **MUST** be emitted using the key ``core-metadata``, with the
+supported values remaining the same.
+
+To support clients that used the previous key names, the HTML representation
+**MAY** also be emitted using the ``data-dist-info-metadata``, and if it does
+so it **MUST** match the value of ``data-core-metadata``.
+
+
+
+Clients
+-------
+
+Clients consuming any of the HTML representations of the Simple API **MUST**
+read the :pep:`658` metadata from the key ``data-core-metadata`` if it is
+present. They **MAY** optionally use the legacy ``data-dist-info-metadata`` if
+it is present but ``data-core-metadata`` is not.
+
+Clients consuming the JSON representation of the Simple API **MUST** read the
+:pep:`658` metadata from the key ``core-metadata`` if it is present. They
+**MAY** optionally use the legacy ``dist-info-metadata`` key if it is present
+but ``core-metadata`` is not.

From 301b99f2ecf547628829bfd61f46f016696659b5 Mon Sep 17 00:00:00 2001
From: Laurie O 
Date: Tue, 2 Jan 2024 11:02:54 +1000
Subject: [PATCH 0620/1072] Convert simple repo API spec history to list

---
 .../specifications/simple-repository-api.rst  | 27 ++++++++++++-------
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/source/specifications/simple-repository-api.rst b/source/specifications/simple-repository-api.rst
index 14644fa27..e3bd344a8 100644
--- a/source/specifications/simple-repository-api.rst
+++ b/source/specifications/simple-repository-api.rst
@@ -9,16 +9,6 @@ The interface for querying available package versions and
 retrieving packages from an index server comes in two forms:
 HTML and JSON.
 
-The HTML format is defined in :pep:`503`, with the addition of "yank"
-support (allowing a kind of file deletion) in :pep:`592`, specifying
-the interface version provided by an index server in :pep:`629`, and
-providing package metadata independently from a package in
-:pep:`658` and revised in :pep:`714`.
-
-The JSON format is defined in :pep:`691`, with additional fields
-added in :pep:`700`, and revisions around providing package metadata
-independently from a package in :pep:`714`.
-
 Base HTML API
 =============
 
@@ -935,3 +925,20 @@ Clients consuming the JSON representation of the Simple API **MUST** read the
 :pep:`658` metadata from the key ``core-metadata`` if it is present. They
 **MAY** optionally use the legacy ``dist-info-metadata`` key if it is present
 but ``core-metadata`` is not.
+
+History
+=======
+
+* September 2015: initial form of the HTML format, in :pep:`503`
+* July 2016: Requires-Python metadata, in an update to :pep:`503`
+* May 2019: "yank" support, in :pep:`592`
+* July 2020: API versioning convention and metadata, and declaring the HTML
+  format as API v1, in :pep:`629`
+* May 2021: providing package metadata independently from a package, in
+  :pep:`658`
+* May 2022: initial form of the JSON format, with a mechanism for clients to
+  choose between them, and declaring both formats as API v1, in :pep:`691`
+* October 2022: project versions and file size and upload-time in the JSON
+  format, in :pep:`700`
+* June 2023: renaming the field which provides package metadata independently
+  from a package, in :pep:`714`

From 0ad7a84808640599a4ed55f031855c6abfbb3997 Mon Sep 17 00:00:00 2001
From: Laurie O 
Date: Tue, 2 Jan 2024 11:52:50 +1000
Subject: [PATCH 0621/1072] Replace PEP references in simple repo API spec

---
 .../specifications/simple-repository-api.rst  | 169 +++++++++++-------
 1 file changed, 107 insertions(+), 62 deletions(-)

diff --git a/source/specifications/simple-repository-api.rst b/source/specifications/simple-repository-api.rst
index e3bd344a8..702e587ad 100644
--- a/source/specifications/simple-repository-api.rst
+++ b/source/specifications/simple-repository-api.rst
@@ -9,6 +9,8 @@ The interface for querying available package versions and
 retrieving packages from an index server comes in two forms:
 HTML and JSON.
 
+.. _simple-repository-api-base:
+
 Base HTML API
 =============
 
@@ -22,7 +24,7 @@ the top level URL that all additional URLs are below. The API is named the
           ``https://pypi.org/simple/foo/``.
 
 
-Within a repository, the root URL (``/`` for this PEP which represents the base
+Within a repository, the root URL (``/`` for this spec which represents the base
 URL) **MUST** be a valid HTML5 page with a single anchor element per project in
 the repository. The text of the anchor tag **MUST** be the name of
 the project and the href attribute **MUST** link to the URL for that particular
@@ -84,7 +86,7 @@ In addition to the above, the following constraints are placed on the API:
   GPG signature. Repositories that do this **SHOULD** include it on every link.
 
 * A repository **MAY** include a ``data-requires-python`` attribute on a file
-  link. This exposes the *Requires-Python* metadata field, specified in :pep:`345`,
+  link. This exposes the :ref:`core-metadata-requires-python` metadata field
   for the corresponding release. Where this is present, installer tools
   **SHOULD** ignore the download when installing to a Python version that
   doesn't satisfy the requirement. For example::
@@ -97,7 +99,8 @@ In addition to the above, the following constraints are placed on the API:
 Normalized Names
 ----------------
 
-This PEP references the concept of a "normalized" project name. As per :pep:`426`
+This spec references the concept of a "normalized" project name. As per
+:ref:`the name normalization specification `
 the only valid characters in a name are the ASCII alphabet, ASCII numbers,
 ``.``, ``-``, and ``_``. The name should be lowercased with all runs of the
 characters ``.``, ``-``, or ``_`` replaced with a single ``-`` character. This
@@ -108,6 +111,8 @@ can be implemented in Python with the ``re`` module::
    def normalize(name):
        return re.sub(r"[-_.]+", "-", name).lower()
 
+.. _simple-repository-api-yank:
+
 Adding "Yank" Support to the Simple API
 =======================================
 
@@ -154,7 +159,8 @@ suggested approaches to take:
    matches a version specifier that "pins" to an exact version using
    either ``==`` (without any modifiers that make it a range, such as
    ``.*``) or ``===``. Matching this version specifier should otherwise
-   be done as per :pep:`440` for things like local versions, zero padding,
+   be done as per :ref:`the version specifiers specification
+   ` for things like local versions, zero padding,
    etc.
 2. Yanked files are always ignored, unless they are the only file that
    matches what a lock file (such as ``Pipfile.lock`` or ``poetry.lock``)
@@ -183,14 +189,18 @@ Mirrors can generally treat yanked files one of two ways:
 Mirrors **MUST NOT** mirror a yanked file without also mirroring the
 ``data-yanked`` attribute for it.
 
+.. _simple-repository-api-versioning:
+
 Versioning PyPI's Simple API
 ============================
 
-This PEP proposes the inclusion of a meta tag on the responses of every
+This spec proposes the inclusion of a meta tag on the responses of every
 successful request to a simple API page, which contains a name attribute
-of "pypi:repository-version", and a content that is a :pep:`440` compatible
+of "pypi:repository-version", and a content that is a :ref:`version specifiers
+specification ` compatible
 version number, which is further constrained to ONLY be Major.Minor, and
-none of the additional features supported by :pep:`440`.
+none of the additional features supported by :ref:`the version specifiers
+specification `.
 
 This would end up looking like::
 
@@ -205,21 +215,21 @@ When interpreting the repository version:
   compatible change such that existing clients would still be
   expected to be able to meaningfully use the API.
 
-It is left up to the discretion of any future PEPs as to what
+It is left up to the discretion of any future specs as to what
 specifically constitutes a backwards incompatible vs compatible change
 beyond the broad suggestion that existing clients will be able to
 "meaningfully" continue to use the API, and can include adding,
 modifying, or removing existing features.
 
-It is expectation of this PEP that the major version will never be
+It is expectation of this spec that the major version will never be
 incremented, and any future major API evolutions would utilize a
 different mechanism for API evolution. However the major version
 is included to disambiguate with future versions (e.g. a hypothetical
 simple api v2 that lived at /v2/, but which would be confusing if the
 repository-version was set to a version >= 2).
 
-This PEP sets the current API version to "1.0", and expects that
-future PEPs that further evolve the simple API will increment the
+This spec sets the current API version to "1.0", and expects that
+future specs that further evolve the simple API will increment the
 minor version number.
 
 
@@ -239,6 +249,8 @@ When encountering a minor version greater than expected, clients
 Clients **MAY** still continue to use feature detection in order to
 determine what features a repository uses.
 
+.. _simple-repository-api-metadata-file:
+
 Serve Distribution Metadata in the Simple Repository API
 ========================================================
 
@@ -254,7 +266,8 @@ distribution with a ``.metadata`` appended to the distribution's file
 name. For example, the Core Metadata of a distribution served at
 ``/files/distribution-1.0-py3.none.any.whl`` would be located at
 ``/files/distribution-1.0-py3.none.any.whl.metadata``. This is similar
-to how :pep:`503` specifies the GPG signature file's location.
+to how :ref:`the base HTML API specification `
+specifies the GPG signature file's location.
 
 The repository **SHOULD** provide the hash of the Core Metadata file
 as the ``data-dist-info-metadata`` attribute's value using the syntax
@@ -276,15 +289,19 @@ current behaviour of downloading the distribution to inspect the
 metadata. This is similar to how prior ``data-`` attribute additions
 expect existing tools to operate.
 
+.. _simple-repository-api-json:
+
 JSON-based Simple API for Python Package Indexes
 ================================================
 
-To enable response parsing with only the standard library, this PEP specifies that
+To enable response parsing with only the standard library, this spec specifies that
 all responses (besides the files themselves, and the HTML responses from
-:pep:`503`) should be serialized using `JSON `_.
+:ref:`the base HTML API specification `) should be
+serialized using `JSON `_.
 
 To enable zero configuration discovery and to minimize the amount of additional HTTP
-requests, this PEP extends :pep:`503` such that all of the API endpoints (other than the
+requests, this spec extends :ref:`the base HTML API specification
+` such that all of the API endpoints (other than the
 files themselves) will utilize HTTP content negotiation to allow client and server to
 select the correct serialization format to serve, i.e. either HTML or JSON.
 
@@ -292,13 +309,16 @@ select the correct serialization format to serve, i.e. either HTML or JSON.
 Versioning
 ----------
 
-Versioning will adhere to :pep:`629` format (``Major.Minor``), which has defined the
-existing HTML responses to be ``1.0``. Since this PEP does not introduce new features
+Versioning will adhere to :ref:`the API versioning specification
+` format (``Major.Minor``), which has defined the
+existing HTML responses to be ``1.0``. Since this spec does not introduce new features
 into the API, rather it describes a different serialization format for the existing
-features, this PEP does not change the existing ``1.0`` version, and instead just
+features, this spec does not change the existing ``1.0`` version, and instead just
 describes how to serialize that into JSON.
 
-Similar to :pep:`629`, the major version number **MUST** be incremented if any
+Similar to :ref:`the API versioning specification
+`, the major version number **MUST** be
+incremented if any
 changes to the new format would result in no longer being able to expect existing
 clients to meaningfully understand the format.
 
@@ -310,7 +330,7 @@ Changes that would not result in existing clients being unable to meaningfully
 understand the format and which do not represent features being added or removed
 may occur without changing the version number.
 
-This is intentionally vague, as this PEP believes it is best left up to future PEPs
+This is intentionally vague, as this spec believes it is best left up to future specs
 that make any changes to the API to investigate and decide whether or not that
 change should increment the major or minor version.
 
@@ -320,7 +340,7 @@ within a major version, **SHOULD** be kept in sync, but the specifics of how a
 feature serializes into each format may differ, including whether or not that feature
 is present at all.
 
-It is the intent of this PEP that the API should be thought of as URL endpoints that
+It is the intent of this spec that the API should be thought of as URL endpoints that
 return data, whose interpretation is defined by the version of that data, and then
 serialized into the target serialization format.
 
@@ -330,11 +350,12 @@ serialized into the target serialization format.
 JSON Serialization
 ------------------
 
-The URL structure from :pep:`503` still applies, as this PEP only adds an additional
+The URL structure from :ref:`the base HTML API specification
+` still applies, as this spec only adds an additional
 serialization format for the already existing API.
 
 The following constraints apply to all JSON serialized responses described in this
-PEP:
+spec:
 
 * All JSON responses will *always* be a JSON object rather than an array or other
   type.
@@ -351,16 +372,19 @@ PEP:
   the response itself, rather than the content of the response.
 
 * All JSON responses will have a ``meta.api-version`` key, which will be a string that
-  contains the :pep:`629` ``Major.Minor`` version number, with the same fail/warn
-  semantics as defined in :pep:`629`.
+  contains the :ref:`API versioning specification
+  ` ``Major.Minor`` version number, with the
+  same fail/warn semantics as defined in :ref:`the API versioning specification
+  `.
 
-* All requirements of :pep:`503` that are not HTML specific still apply.
+* All requirements of :ref:`the base HTML API specification
+  ` that are not HTML specific still apply.
 
 
 Project List
 ~~~~~~~~~~~~
 
-The root URL ``/`` for this PEP (which represents the base URL) will be a JSON encoded
+The root URL ``/`` for this spec (which represents the base URL) will be a JSON encoded
 dictionary which has a two keys:
 
 - ``projects``: An array where each entry is a dictionary with a single key, ``name``, which represents string of the project name.
@@ -383,9 +407,10 @@ As an example:
 
 .. note::
 
-  The ``name`` field is the same as the one from :pep:`503`, which does not specify
+  The ``name`` field is the same as the one from :ref:`the base HTML API
+  specification `, which does not specify
   whether it is the non-normalized display name or the normalized name. In practice
-  different implementations of these PEPs are choosing differently here, so relying
+  different implementations of these specs are choosing differently here, so relying
   on it being either non-normalized or normalized is relying on an implementation
   detail of the repository in question.
 
@@ -393,7 +418,8 @@ As an example:
 .. note::
 
   While the ``projects`` key is an array, and thus is required to be in some kind
-  of an order, neither :pep:`503` nor this PEP requires any specific ordering nor
+  of an order, neither :ref:`the base HTML API specification
+  ` nor this spec requires any specific ordering nor
   that the ordering is consistent from one request to the next. Mentally this is
   best thought of as a set, but both JSON and HTML lack the functionality to have
   sets.
@@ -403,7 +429,8 @@ Project Detail
 ~~~~~~~~~~~~~~
 
 The format of this URL is ``//`` where the ```` is replaced by the
-:pep:`503` normalized name for that project, so a project named "Silly_Walk" would
+:ref:`the base HTML API specification ` normalized
+name for that project, so a project named "Silly_Walk" would
 have a URL like ``/silly-walk/``.
 
 This URL must respond with a JSON encoded dictionary that has three keys:
@@ -430,17 +457,21 @@ Each individual file dictionary has the following keys:
   be passed to ``hashlib.new()`` and do not require additional parameters) can
   be used as a key for the hashes dictionary. At least one secure algorithm from
   ``hashlib.algorithms_guaranteed`` **SHOULD** always be included. At the time
-  of this PEP, ``sha256`` specifically is recommended.
-- ``requires-python``: An **optional** key that exposes the *Requires-Python*
-  metadata field, specified in :pep:`345`. Where this is present, installer tools
+  of this spec, ``sha256`` specifically is recommended.
+- ``requires-python``: An **optional** key that exposes the
+  :ref:`core-metadata-requires-python`
+  metadata field. Where this is present, installer tools
   **SHOULD** ignore the download when installing to a Python version that
   doesn't satisfy the requirement.
 
-  Unlike ``data-requires-python`` in :pep:`503`, the ``requires-python`` key does not
+  Unlike ``data-requires-python`` in :ref:`the base HTML API specification
+  `, the ``requires-python`` key does not
   require any special escaping other than anything JSON does naturally.
 - ``dist-info-metadata``: An **optional** key that indicates
   that metadata for this file is available, via the same location as specified in
-  :pep:`658` (``{file_url}.metadata``). Where this is present, it **MUST** be
+  :ref:`the API metadata file specification
+  ` (``{file_url}.metadata``). Where this
+  is present, it **MUST** be
   either a boolean to indicate if the file has an associated metadata file, or a
   dictionary mapping hash names to a hex encoded digest of the metadata's hash.
 
@@ -456,13 +487,15 @@ Each individual file dictionary has the following keys:
   possible.
 - ``gpg-sig``: An **optional** key that acts a boolean to indicate if the file has
   an associated GPG signature or not. The URL for the signature file follows what
-  is specified in :pep:`503` (``{file_url}.asc``). If this key does not exist, then
+  is specified in :ref:`the base HTML API specification
+  ` (``{file_url}.asc``). If this key does not exist, then
   the signature may or may not exist.
 - ``yanked``: An **optional** key which may be either a boolean to indicate if the
   file has been yanked, or a non empty, but otherwise arbitrary, string to indicate
   that a file has been yanked with a specific reason. If the ``yanked`` key is present
   and is a truthy value, then it **SHOULD** be interpreted as indicating that the
-  file pointed to by the ``url`` field has been "Yanked" as per :pep:`592`.
+  file pointed to by the ``url`` field has been "Yanked" as per :ref:`the API
+  yank specification `.
 
 As an example:
 
@@ -495,7 +528,8 @@ As an example:
 .. note::
 
   While the ``files`` key is an array, and thus is required to be in some kind
-  of an order, neither :pep:`503` nor this PEP requires any specific ordering nor
+  of an order, neither :ref:`the base HTML API specification
+  ` nor this spec requires any specific ordering nor
   that the ordering is consistent from one request to the next. Mentally this is
   best thought of as a set, but both JSON and HTML lack the functionality to have
   sets.
@@ -504,7 +538,7 @@ As an example:
 Content-Types
 -------------
 
-This PEP proposes that all responses from the Simple API will have a standard
+This spec proposes that all responses from the Simple API will have a standard
 content type that describes what the response is (a Simple API response), what
 version of the API it represents, and what serialization format has been used.
 
@@ -529,8 +563,9 @@ whose purpose is to allow clients to request the absolute latest version, withou
 having to know ahead of time what that version is. It is recommended however,
 that clients be explicit about what versions they support.
 
-To support existing clients which expect the existing :pep:`503` API responses to
-use the ``text/html`` content type, this PEP further defines ``text/html`` as an alias
+To support existing clients which expect the existing :ref:`the base HTML API
+specification ` API responses to
+use the ``text/html`` content type, this spec further defines ``text/html`` as an alias
 for the ``application/vnd.pypi.simple.v1+html`` content type.
 
 
@@ -542,10 +577,10 @@ clients to indicate what serialization formats they're able to understand. In
 addition, it would be beneficial if any possible new major version to the API can
 be added without disrupting existing clients expecting the previous API version.
 
-To enable this, this PEP standardizes on the use of HTTP's
+To enable this, this spec standardizes on the use of HTTP's
 `Server-Driven Content Negotiation `_.
 
-While this PEP won't fully describe the entirety of server-driven content
+While this spec won't fully describe the entirety of server-driven content
 negotiation, the flow is roughly:
 
 1. The client makes an HTTP request containing an ``Accept`` header listing all
@@ -567,19 +602,19 @@ negotiation, the flow is roughly:
 4. The client interprets the response, handling the different types of responses
    that the server may have responded with.
 
-This PEP does not specify which choices the server makes in regards to handling
+This spec does not specify which choices the server makes in regards to handling
 a content type that it isn't able to return, and clients **SHOULD** be prepared
 to handle all of the possible responses in whatever way makes the most sense for
 that client.
 
 However, as there is no standard format for how a ``300 Multiple Choices``
-response can be interpreted, this PEP highly discourages servers from utilizing
+response can be interpreted, this spec highly discourages servers from utilizing
 that option, as clients will have no way to understand and select a different
 content-type to request. In addition, it's unlikely that the client *could*
 understand a different content type anyways, so at best this response would
 likely just be treated the same as a ``406 Not Acceptable`` error.
 
-This PEP **does** require that if the meta version ``latest`` is being used, the
+This spec **does** require that if the meta version ``latest`` is being used, the
 server **MUST** respond with the content type for the actual version that is
 contained in the response
 (i.e. A ``Accept: application/vnd.pypi.simple.latest+json`` request that returns
@@ -616,7 +651,7 @@ the content types they've asked for, regardless of their requested priority, and
 it may even return a content type that they did **not** ask for.
 
 To aid clients in determining the content type of the response that they have
-received from an API request, this PEP requires that servers always include a
+received from an API request, this spec requires that servers always include a
 ``Content-Type`` header indicating the content type of the response. This is
 technically a backwards incompatible change, however in practice
 `pip has been enforcing this requirement `_
@@ -684,7 +719,7 @@ Alternative Negotiation Mechanisms
 While using HTTP's Content negotiation is considered the standard way for a client
 and server to coordinate to ensure that the client is getting an HTTP response that
 it is able to understand, there are situations where that mechanism may not be
-sufficient. For those cases this PEP has alternative negotiation mechanisms that
+sufficient. For those cases this spec has alternative negotiation mechanisms that
 may *optionally* be used instead.
 
 
@@ -760,7 +795,7 @@ can hold true for other aspects of the actual HTTP request, such as the ``Accept
 header.
 
 Ultimately figuring out how to map a directory to a filename is out of scope for this
-PEP (but it would be in scope for :pep:`458`), and this PEP defers making a decision
+spec (but it would be in scope for :pep:`458`), and this spec defers making a decision
 about how exactly to represent this inside of :pep:`458` metadata.
 
 However, it appears that the current WIP branch against pip that attempts to implement
@@ -780,8 +815,8 @@ explicitly declared versions should be supported.
 Recommendations
 ---------------
 
-This section is non-normative, and represents what the PEP authors believe to be
-the best default implementation decisions for something implementing this PEP, but
+This section is non-normative, and represents what the spec authors believe to be
+the best default implementation decisions for something implementing this spec, but
 it does **not** represent any sort of requirement to match these decisions.
 
 These decisions have been chosen to maximize the number of requests that can be
@@ -791,7 +826,7 @@ guardrails that attempt to push clients into making the best choices it can.
 
 It is recommended that servers:
 
-- Support all 3 content types described in this PEP, using server-driven
+- Support all 3 content types described in this spec, using server-driven
   content negotiation, for as long as they reasonably can, or at least as
   long as they're receiving non trivial traffic that uses the HTML responses.
 
@@ -811,7 +846,7 @@ It is recommended that servers:
 
 It is recommended that clients:
 
-- Support all 3 content types described in this PEP, using server-driven
+- Support all 3 content types described in this spec, using server-driven
   content negotiation, for as long as they reasonably can.
 
 - When constructing an ``Accept`` header, include all of the content types
@@ -854,7 +889,8 @@ Versions
 --------
 
 An additional key, ``versions`` MUST be present at the top level, in addition to
-the keys ``name``, ``files`` and ``meta`` defined in :pep:`691`. This key MUST
+the keys ``name``, ``files`` and ``meta`` defined in :ref:`the JSON API
+specification `. This key MUST
 contain a list of version strings specifying all of the project versions uploaded
 for this project. The value is logically a set, and as such may not contain
 duplicates, and the order of the values is not significant.
@@ -865,9 +901,10 @@ no associated files (to represent versions with no files uploaded, if the server
 has such a concept).
 
 Note that because servers may hold "legacy" data from before the adoption of
-:pep:`440`, version strings currently cannot be required to be valid :pep:`440`
-versions, and therefore cannot be assumed to be orderable using the :pep:`440`
-rules. However, servers SHOULD use normalised :pep:`440` versions where
+:ref:`the version specifiers specification (VSS) `, version
+strings currently cannot be required to be valid VSS versions, and therefore
+cannot be assumed to be orderable using the VSS rules. However, servers SHOULD
+use normalised VSS versions where
 possible.
 
 
@@ -899,11 +936,15 @@ and "**OPTIONAL**"" in this document are to be interpreted as described in
 Servers
 -------
 
-The :pep:`658` metadata, when used in the HTML representation of the Simple API,
+The :ref:`the API metadata file specification
+` metadata, when used in the HTML
+representation of the Simple API,
 **MUST** be emitted using the attribute name ``data-core-metadata``, with the
 supported values remaining the same.
 
-The :pep:`658` metadata, when used in the :pep:`691` JSON representation of the
+The :ref:`the API metadata file specification
+` metadata, when used in the :ref:`the
+JSON API specification ` JSON representation of the
 Simple API, **MUST** be emitted using the key ``core-metadata``, with the
 supported values remaining the same.
 
@@ -917,12 +958,16 @@ Clients
 -------
 
 Clients consuming any of the HTML representations of the Simple API **MUST**
-read the :pep:`658` metadata from the key ``data-core-metadata`` if it is
+read the :ref:`the API metadata file specification
+` metadata from the key
+``data-core-metadata`` if it is
 present. They **MAY** optionally use the legacy ``data-dist-info-metadata`` if
 it is present but ``data-core-metadata`` is not.
 
 Clients consuming the JSON representation of the Simple API **MUST** read the
-:pep:`658` metadata from the key ``core-metadata`` if it is present. They
+:ref:`the API metadata file specification
+` metadata from the key ``core-metadata``
+if it is present. They
 **MAY** optionally use the legacy ``dist-info-metadata`` key if it is present
 but ``core-metadata`` is not.
 

From 912579b177c309104563790092d1bac2ff6f38b2 Mon Sep 17 00:00:00 2001
From: John Sirois 
Date: Wed, 17 Jan 2024 14:41:07 -0800
Subject: [PATCH 0622/1072] Update pex entry.

Pex long ago stopped offering a programmatic API in favor of its CLI
API. I was remiss in not updating this description. Note is made of the
more expansive features Pex and PEX files have grown in the meantime,
including a nod to Pex multi-platform lock support (RIP PEP 665 - you
live on in Pex).
---
 source/key_projects.rst | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index 671675641..d6a4ad7e1 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -534,11 +534,14 @@ pex
 `GitHub `__ |
 `PyPI `__
 
-pex is both a library and tool for generating :file:`.pex` (Python EXecutable)
+Pex is a tool for generating :file:`.pex` (Python EXecutable)
 files, standalone Python environments in the spirit of :ref:`virtualenv`.
-:file:`.pex` files are just carefully constructed zip files with a
-``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to
-make deployment of Python applications as simple as ``cp``.
+PEX files are zipapps as outlined :pep:`441` that
+make deployment of Python applications as simple as ``cp``. A single PEX
+file can support multiple target platforms and can be created from standard
+:ref:`pip`-resolvable requirements, a lockfile generated with `pex3 lock ...`
+or even another PEX. PEX files can optionally have tools embedded that support
+turning the PEX file into a standard venv, graphing dependencies and more.
 
 .. _pip-tools:
 

From aefbb1359f85e4a181614c0084d0a214e6c7359f Mon Sep 17 00:00:00 2001
From: John Sirois 
Date: Wed, 17 Jan 2024 14:43:23 -0800
Subject: [PATCH 0623/1072] Fix code ticks for RST.

---
 source/key_projects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index d6a4ad7e1..55383c06e 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -539,7 +539,7 @@ files, standalone Python environments in the spirit of :ref:`virtualenv`.
 PEX files are zipapps as outlined :pep:`441` that
 make deployment of Python applications as simple as ``cp``. A single PEX
 file can support multiple target platforms and can be created from standard
-:ref:`pip`-resolvable requirements, a lockfile generated with `pex3 lock ...`
+:ref:`pip`-resolvable requirements, a lockfile generated with ``pex3 lock ...``
 or even another PEX. PEX files can optionally have tools embedded that support
 turning the PEX file into a standard venv, graphing dependencies and more.
 

From eed8161c9878160e0a8378111a36a4585cf61abc Mon Sep 17 00:00:00 2001
From: John Sirois 
Date: Thu, 18 Jan 2024 13:20:17 -0800
Subject: [PATCH 0624/1072] @sinroc's feedback.

Co-authored-by: sinoroc <5529267+sinoroc@users.noreply.github.com>
---
 source/key_projects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index 55383c06e..c0b6b383c 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -536,7 +536,7 @@ pex
 
 Pex is a tool for generating :file:`.pex` (Python EXecutable)
 files, standalone Python environments in the spirit of :ref:`virtualenv`.
-PEX files are zipapps as outlined :pep:`441` that
+PEX files are zipapps as outlined in :pep:`441` that
 make deployment of Python applications as simple as ``cp``. A single PEX
 file can support multiple target platforms and can be created from standard
 :ref:`pip`-resolvable requirements, a lockfile generated with ``pex3 lock ...``

From 0e0aa42ca4370dc8c9d6fb1f4a161329729e01b8 Mon Sep 17 00:00:00 2001
From: John Sirois 
Date: Fri, 19 Jan 2024 05:52:53 -0800
Subject: [PATCH 0625/1072] @jeanas's feedback.

Co-authored-by: Jean Abou-Samra 
---
 source/key_projects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index c0b6b383c..eb24e13dd 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -536,7 +536,7 @@ pex
 
 Pex is a tool for generating :file:`.pex` (Python EXecutable)
 files, standalone Python environments in the spirit of :ref:`virtualenv`.
-PEX files are zipapps as outlined in :pep:`441` that
+PEX files are :ref:`zipapps ` that
 make deployment of Python applications as simple as ``cp``. A single PEX
 file can support multiple target platforms and can be created from standard
 :ref:`pip`-resolvable requirements, a lockfile generated with ``pex3 lock ...``

From dce257ca127ccdf966652c4f04d5ccb7f108a1a7 Mon Sep 17 00:00:00 2001
From: John Sirois 
Date: Fri, 19 Jan 2024 13:07:13 -0800
Subject: [PATCH 0626/1072] @chrysle's fix.

Co-authored-by: chrysle 
---
 source/key_projects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index eb24e13dd..a00502cb8 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -536,7 +536,7 @@ pex
 
 Pex is a tool for generating :file:`.pex` (Python EXecutable)
 files, standalone Python environments in the spirit of :ref:`virtualenv`.
-PEX files are :ref:`zipapps ` that
+PEX files are :doc:`zipapps ` that
 make deployment of Python applications as simple as ``cp``. A single PEX
 file can support multiple target platforms and can be created from standard
 :ref:`pip`-resolvable requirements, a lockfile generated with ``pex3 lock ...``

From 61968c5f1f1a6524913a8a6e41bf72a7d6528a07 Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Sat, 20 Jan 2024 21:15:23 +0100
Subject: [PATCH 0627/1072] Apply suggestions from code review

Co-authored-by: chrysle 
---
 source/specifications/inline-script-metadata.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/source/specifications/inline-script-metadata.rst b/source/specifications/inline-script-metadata.rst
index dee1c2634..352614e81 100644
--- a/source/specifications/inline-script-metadata.rst
+++ b/source/specifications/inline-script-metadata.rst
@@ -71,15 +71,15 @@ standardized by this specification.
 script type
 -----------
 
-The first type of metadata block is named ``script`` which contains
+The first type of metadata block is named ``script``, which contains
 script metadata (dependency data and tool configuration).
 
-This document MAY include top-level fields ``dependencies`` and ``requires-python``,
+This document MAY include the top-level fields ``dependencies`` and ``requires-python``,
 and MAY optionally include a ``[tool]`` table.
 
 The ``[tool]`` MAY be used by any tool, script runner or otherwise, to configure
 behavior. It has the same semantics as the :ref:`[tool] table in pyproject.toml
-`
+`.
 
 The top-level fields are:
 

From ae45509df539d51adc4a46c850ccdd2b311c0c56 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 22 Jan 2024 18:20:32 +0000
Subject: [PATCH 0628/1072] [pre-commit.ci] pre-commit autoupdate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

updates:
- [github.com/astral-sh/ruff-pre-commit: v0.1.9 → v0.1.14](https://github.com/astral-sh/ruff-pre-commit/compare/v0.1.9...v0.1.14)
---
 .pre-commit-config.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index baba00ea3..f46125add 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -34,7 +34,7 @@ repos:
   - id: rst-inline-touching-normal
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.1.9
+  rev: v0.1.14
   hooks:
     - id: ruff
     - id: ruff-format

From 8b02e7f478b58f8c730ba193ae827af482862a5f Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 24 Jan 2024 23:58:45 +0100
Subject: [PATCH 0629/1072] @sinoroc's review

---
 source/discussions/versioning.rst | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/source/discussions/versioning.rst b/source/discussions/versioning.rst
index a2d818e87..b66553c19 100644
--- a/source/discussions/versioning.rst
+++ b/source/discussions/versioning.rst
@@ -34,7 +34,7 @@ before a final release. In order, the steps are: alpha releases, beta releases,
 release candidates, final release. Pip and other modern Python package
 installers ignore pre-releases by default when deciding which versions of
 dependencies to install, unless explicitly requested (e.g., with
-``pip install pkg==1.1a3``).
+``pip install pkg==1.1a3`` or ``pip install --pre pkg``).
 
 The purpose of development releases is to support releases made early during a
 development cycle, for example, a nightly build, or a build from the latest
@@ -80,7 +80,9 @@ adhere to semantic versioning, since many changes are technically breaking
 changes but affect only a small fraction of users. Such projects tend to
 increment the major number when the incompatibility is high, or to signal a
 shift in the project, rather than for any tiny incompatibility
-[#semver-strictness]_.
+[#semver-strictness]_. Conversely, a bump of the major version number
+is sometimes used to signal significant but backwards-compatible new
+features.
 
 For those projects that do use strict semantic versioning, this approach allows
 users to make use of :ref:`compatible release version specifiers

From 177b5db3a3efd016a520ac17f23fe35855e7dd80 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edgar=20Ram=C3=ADrez=20Mondrag=C3=B3n?=
 
Date: Wed, 24 Jan 2024 23:45:33 -0600
Subject: [PATCH 0630/1072] Use intersphinx to link to `hashlib` docs

---
 source/specifications/direct-url-data-structure.rst    | 6 +++---
 source/specifications/recording-installed-packages.rst | 2 +-
 source/specifications/simple-repository-api.rst        | 9 ++++-----
 source/specifications/version-specifiers.rst           | 2 +-
 4 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index f0ab2e447..993f40f59 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -79,10 +79,10 @@ MUST be present as a dictionary with the following keys:
 
   These hash names SHOULD always be normalized to be lowercase.
 
-  Any hash algorithm available via ``hashlib`` (specifically any that can be passed to
-  ``hashlib.new()`` and do not require additional parameters) can be used as a key for
+  Any hash algorithm available via :py:mod:`hashlib` (specifically any that can be passed to
+  :py:func:`hashlib.new()` and do not require additional parameters) can be used as a key for
   the hashes dictionary. At least one secure algorithm from
-  ``hashlib.algorithms_guaranteed`` SHOULD always be included. At time of writing,
+  :py:data:`hashlib.algorithms_guaranteed` SHOULD always be included. At time of writing,
   ``sha256`` specifically is recommended.
 
 - A deprecated ``hash`` key (type ``string``) MAY be present for backwards compatibility
diff --git a/source/specifications/recording-installed-packages.rst b/source/specifications/recording-installed-packages.rst
index 957e4f36a..41b8bc6ce 100644
--- a/source/specifications/recording-installed-packages.rst
+++ b/source/specifications/recording-installed-packages.rst
@@ -112,7 +112,7 @@ On Windows, directories may be separated either by forward- or backslashes
 (``/`` or ``\``).
 
 The *hash* is either an empty string or the name of a hash algorithm from
-``hashlib.algorithms_guaranteed``, followed by the equals character ``=`` and
+:py:data:`hashlib.algorithms_guaranteed`, followed by the equals character ``=`` and
 the digest of the file's contents, encoded with the urlsafe-base64-nopad
 encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed).
 
diff --git a/source/specifications/simple-repository-api.rst b/source/specifications/simple-repository-api.rst
index 702e587ad..b9f87ce7b 100644
--- a/source/specifications/simple-repository-api.rst
+++ b/source/specifications/simple-repository-api.rst
@@ -71,7 +71,7 @@ In addition to the above, the following constraints are placed on the API:
   URL.
 
 * Repositories **SHOULD** choose a hash function from one of the ones
-  guaranteed to be available via the ``hashlib`` module in the Python standard
+  guaranteed to be available via the :py:mod:`hashlib` module in the Python standard
   library (currently ``md5``, ``sha1``, ``sha224``, ``sha256``, ``sha384``,
   ``sha512``). The current recommendation is to use ``sha256``.
 
@@ -452,11 +452,10 @@ Each individual file dictionary has the following keys:
   for the file, however it is **HIGHLY** recommended that at least one secure,
   guaranteed-to-be-available hash is always included.
 
-  By default, any hash algorithm available via `hashlib
-  `_ (specifically any that can
-  be passed to ``hashlib.new()`` and do not require additional parameters) can
+  By default, any hash algorithm available via :py:mod:`hashlib` (specifically any that can
+  be passed to :py:func:`hashlib.new()` and do not require additional parameters) can
   be used as a key for the hashes dictionary. At least one secure algorithm from
-  ``hashlib.algorithms_guaranteed`` **SHOULD** always be included. At the time
+  :py:data:`hashlib.algorithms_guaranteed` **SHOULD** always be included. At the time
   of this spec, ``sha256`` specifically is recommended.
 - ``requires-python``: An **optional** key that exposes the
   :ref:`core-metadata-requires-python`
diff --git a/source/specifications/version-specifiers.rst b/source/specifications/version-specifiers.rst
index 8129fd53d..e5b73ce71 100644
--- a/source/specifications/version-specifiers.rst
+++ b/source/specifications/version-specifiers.rst
@@ -1113,7 +1113,7 @@ and MAY refuse to rely on the URL. If such a direct reference also uses an
 insecure transport, automated tools SHOULD NOT rely on the URL.
 
 It is RECOMMENDED that only hashes which are unconditionally provided by
-the latest version of the standard library's ``hashlib`` module be used
+the latest version of the standard library's :py:mod:`hashlib` module be used
 for source archive hashes. At time of writing, that list consists of
 ``'md5'``, ``'sha1'``, ``'sha224'``, ``'sha256'``, ``'sha384'``, and
 ``'sha512'``.

From 70ec8b195efc1d0a786f43dabd8c9457ddae615c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edgar=20Ram=C3=ADrez=20Mondrag=C3=B3n?=
 
Date: Thu, 25 Jan 2024 19:40:49 -0600
Subject: [PATCH 0631/1072] Use intersphinx to link to other Python docs

---
 .../specifications/dependency-specifiers.rst  | 20 +++++++++----------
 source/specifications/entry-points.rst        | 18 ++++++++---------
 source/specifications/name-normalization.rst  |  2 +-
 .../platform-compatibility-tags.rst           |  6 +++---
 .../recording-installed-packages.rst          |  2 +-
 .../specifications/virtual-environments.rst   | 14 ++++++-------
 6 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst
index 85216d655..51c0b3645 100644
--- a/source/specifications/dependency-specifiers.rst
+++ b/source/specifications/dependency-specifiers.rst
@@ -234,26 +234,26 @@ error like all other unknown variables.
      - Python equivalent
      - Sample values
    * - ``os_name``
-     - ``os.name``
+     - :py:data:`os.name`
      - ``posix``, ``java``
    * - ``sys_platform``
-     - ``sys.platform``
+     - :py:data:`sys.platform`
      - ``linux``, ``linux2``, ``darwin``, ``java1.8.0_51`` (note that "linux"
        is from Python3 and "linux2" from Python2)
    * - ``platform_machine``
-     - ``platform.machine()``
+     - :py:func:`platform.machine()`
      - ``x86_64``
    * - ``platform_python_implementation``
-     - ``platform.python_implementation()``
+     - :py:func:`platform.python_implementation()`
      - ``CPython``, ``Jython``
    * - ``platform_release``
-     - ``platform.release()``
+     - :py:func:`platform.release()`
      - ``3.14.1-x86_64-linode39``, ``14.5.0``, ``1.8.0_51``
    * - ``platform_system``
-     - ``platform.system()``
+     - :py:func:`platform.system()`
      - ``Linux``, ``Windows``, ``Java``
    * - ``platform_version``
-     - ``platform.version()``
+     - :py:func:`platform.version()`
      - ``#1 SMP Fri Apr 25 13:07:35 EDT 2014``
        ``Java HotSpot(TM) 64-Bit Server VM, 25.51-b03, Oracle Corporation``
        ``Darwin Kernel Version 14.5.0: Wed Jul 29 02:18:53 PDT 2015; root:xnu-2782.40.9~2/RELEASE_X86_64``
@@ -261,10 +261,10 @@ error like all other unknown variables.
      - ``'.'.join(platform.python_version_tuple()[:2])``
      - ``3.4``, ``2.7``
    * - ``python_full_version``
-     - ``platform.python_version()``
+     - :py:func:`platform.python_version()`
      - ``3.4.0``, ``3.5.0b1``
    * - ``implementation_name``
-     - ``sys.implementation.name``
+     - :py:data:`sys.implementation.name `
      - ``cpython``
    * - ``implementation_version``
      - see definition below
@@ -275,7 +275,7 @@ error like all other unknown variables.
      - ``test``
 
 The ``implementation_version`` marker variable is derived from
-``sys.implementation.version``:
+:py:data:`sys.implementation.version `:
 
 .. code-block:: python
 
diff --git a/source/specifications/entry-points.rst b/source/specifications/entry-points.rst
index 6a601c977..dea039492 100644
--- a/source/specifications/entry-points.rst
+++ b/source/specifications/entry-points.rst
@@ -18,10 +18,10 @@ example:
 
 The entry point file format was originally developed to allow packages built
 with setuptools to provide integration point metadata that would be read at
-runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability
-specification in order to allow build tools other than setuptools to publish
-``importlib.metadata`` compatible entry point metadata, and runtime libraries other
-than ``importlib.metadata`` to portably read published entry point metadata
+runtime with :py:mod:`importlib.metadata`. It is now defined as a PyPA interoperability
+specification in order to allow build tools other than ``setuptools`` to publish
+:py:mod:`importlib.metadata` compatible entry point metadata, and runtime libraries other
+than :py:mod:`importlib.metadata` to portably read published entry point metadata
 (potentially with different caching and conflict resolution strategies).
 
 Data model
@@ -144,11 +144,11 @@ For instance, the entry point ``mycmd = mymod:main`` would create a command
 
 The difference between ``console_scripts`` and ``gui_scripts`` only affects
 Windows systems. ``console_scripts`` are wrapped in a console executable,
-so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and
-``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI
-executable, so they can be started without a console, but cannot use standard
-streams unless application code redirects them. Other platforms do not have the
-same distinction.
+so they are attached to a console and can use :py:data:`sys.stdin`,
+:py:data:`sys.stdout` and :py:data:`sys.stderr` for input and output.
+``gui_scripts`` are wrapped in a GUI executable, so they can be started without
+a console, but cannot use standard streams unless application code redirects them.
+Other platforms do not have the same distinction.
 
 Install tools are expected to set up wrappers for both ``console_scripts`` and
 ``gui_scripts`` in the scripts directory of the install scheme. They are not
diff --git a/source/specifications/name-normalization.rst b/source/specifications/name-normalization.rst
index efe60e12d..ba3246b63 100644
--- a/source/specifications/name-normalization.rst
+++ b/source/specifications/name-normalization.rst
@@ -15,7 +15,7 @@ Name format
 A valid name consists only of ASCII letters and numbers, period,
 underscore and hyphen. It must start and end with a letter or number.
 This means that valid project names are limited to those which match the
-following regex (run with ``re.IGNORECASE``)::
+following regex (run with :py:data:`re.IGNORECASE`)::
 
     ^([A-Z0-9]|[A-Z0-9][A-Z0-9._-]*[A-Z0-9])$
 
diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 10f0c4698..381b84ca9 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -45,7 +45,7 @@ a distribution.  Major implementations have abbreviated codes, initially:
 * pp: PyPy
 * jy: Jython
 
-Other Python implementations should use ``sys.implementation.name``.
+Other Python implementations should use :py:data:`sys.implementation.name `.
 
 The version is ``py_version_nodot``.  CPython gets away with no dot,
 but if one is needed the underscore ``_`` is used instead.  PyPy should
@@ -85,7 +85,7 @@ Platform Tag
 Basic platform tags
 -------------------
 
-In its simplest form, the platform tag is ``sysconfig.get_platform()`` with
+In its simplest form, the platform tag is :py:func:`sysconfig.get_platform()` with
 all hyphens ``-`` and periods ``.`` replaced with underscore ``_``.
 Until the removal of :ref:`distutils` in Python 3.12, this
 was ``distutils.util.get_platform()``. For example:
@@ -113,7 +113,7 @@ The current standard is the future-proof ``manylinux_x_y`` standard. It defines
 tags of the form ``manylinux_x_y_arch``, where ``x`` and ``y`` are glibc major
 and minor versions supported (e.g. ``manylinux_2_24_xxx`` should work on any
 distro using glibc 2.24+), and ``arch`` is the architecture, matching the value
-of ``sysconfig.get_platform()`` on the system as in the "simple" form above.
+of :py:func:`sysconfig.get_platform()` on the system as in the "simple" form above.
 
 The following older tags are still supported for backward compatibility:
 
diff --git a/source/specifications/recording-installed-packages.rst b/source/specifications/recording-installed-packages.rst
index 41b8bc6ce..ee8e69f79 100644
--- a/source/specifications/recording-installed-packages.rst
+++ b/source/specifications/recording-installed-packages.rst
@@ -114,7 +114,7 @@ On Windows, directories may be separated either by forward- or backslashes
 The *hash* is either an empty string or the name of a hash algorithm from
 :py:data:`hashlib.algorithms_guaranteed`, followed by the equals character ``=`` and
 the digest of the file's contents, encoded with the urlsafe-base64-nopad
-encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed).
+encoding (:py:func:`base64.urlsafe_b64encode(digest) ` with trailing ``=`` removed).
 
 The *size* is either the empty string, or file's size in bytes,
 as a base 10 integer.
diff --git a/source/specifications/virtual-environments.rst b/source/specifications/virtual-environments.rst
index 6c8eee530..c73a28c27 100644
--- a/source/specifications/virtual-environments.rst
+++ b/source/specifications/virtual-environments.rst
@@ -17,10 +17,10 @@ there was no previously standardised mechanism for declaring or discovering them
 Runtime detection of virtual environments
 =========================================
 
-At runtime, virtual environments can be identified by virtue of ``sys.prefix``
-(the filesystem location of the running interpreter) having a different value
-from ``sys.base_prefix`` (the default filesystem location of the standard library
-directories).
+At runtime, virtual environments can be identified by virtue of
+:py:data:`sys.prefix` (the filesystem location of the running interpreter)
+having a different value from :py:data:`sys.base_prefix` (the default filesystem
+location of the standard library directories).
 
 :ref:`venv-explanation` in the Python standard library documentation for the
 :py:mod:`venv` module covers this along with the concept of "activating" a
@@ -45,9 +45,9 @@ nesting is required or desired.
 
 Even in the absence of a ``pyvenv.cfg`` file, any approach (e.g.
 ``sitecustomize.py``, patching the installed Python runtime) that results in
-``sys.prefix`` and ``sys.base_prefix`` having different values, while still
-providing a matching default package installation scheme in ``sysconfig``, will
-be detected and behave as a Python virtual environment.
+:py:data:`sys.prefix` and :py:data:`sys.base_prefix` having different values,
+while still providing a matching default package installation scheme in
+:py:mod:`sysconfig`, will be detected and behave as a Python virtual environment.
 
 
 History

From 75728d629fb8b4a81def031a15b37af3c3d0999a Mon Sep 17 00:00:00 2001
From: Dos Moonen 
Date: Fri, 26 Jan 2024 14:10:42 +0100
Subject: [PATCH 0632/1072] Replace regex which allows dubble hyphens by one
 that does not.

The current version disallows tripple hyphens but allows dubble hyphens. (It also seems overcomplicated)

Alternatively we can make it a negative lookbehind instead of a negative lookahead, but the complexity is much higher.

See https://regex101.com/r/Xyu0bt/1 for proof the current version matches double hyphens
---
 source/specifications/core-metadata.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 7ea0ccf3b..90793c791 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -631,7 +631,7 @@ of lowercase ASCII letters, ASCII numbers, and hyphen. It must start and end
 with a letter or number. Hyphens cannot be followed by another hyphen. Names are
 limited to those which match the following regex (which guarantees unambiguity)::
 
-    ^([a-z0-9]|[a-z0-9]([a-z0-9-](?!--))*[a-z0-9])$
+    ^[a-z0-9]+(-[a-z0-9]+)*$
 
 
 The specified name may be used to make a dependency conditional on whether the

From 78b83a225117fe33a4dc71494edf6387ba026d2c Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sat, 27 Jan 2024 18:36:17 +0100
Subject: [PATCH 0633/1072] Address review comments from @webknjaz

---
 source/discussions/versioning.rst | 31 +++++++++++++++++--------------
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/source/discussions/versioning.rst b/source/discussions/versioning.rst
index b66553c19..8a738f866 100644
--- a/source/discussions/versioning.rst
+++ b/source/discussions/versioning.rst
@@ -16,18 +16,18 @@ needs of that particular project, but in order to be compatible with tools like
 :ref:`pip`, all of them are required to comply with a flexible format for
 version identifiers, for which the authoritative reference is the
 :ref:`specification of version specifiers `. Here are some
-examples of version numbers:
-
-- A simple version (final release): 1.2.0
-- A development release: 1.2.0.dev1
-- An alpha release: 1.2.0a1
-- A beta release: 1.2.0b1
-- A release candidate: 1.2.0rc1
-- A post-release: 1.2.0.post1
-- A post-release of an alpha release (possible, but discouraged): 1.2.0a1.post1
-- A simple version with only two components: 23.12
-- A simple version with just one component (possible, but discouraged): 42
-- A version with an epoch: 1!1.0
+examples of version numbers [#version-examples]_:
+
+- A simple version (final release): ``1.2.0``
+- A development release: ``1.2.0.dev1``
+- An alpha release: ``1.2.0a1``
+- A beta release: ``1.2.0b1``
+- A release candidate: ``1.2.0rc1``
+- A post-release: ``1.2.0.post1``
+- A post-release of an alpha release (possible, but discouraged): ``1.2.0a1.post1``
+- A simple version with only two components: ``23.12``
+- A simple version with just one component: ``42``
+- A version with an epoch: ``1!1.0``
 
 Projects can use a cycle of pre-releases to support testing by their users
 before a final release. In order, the steps are: alpha releases, beta releases,
@@ -68,11 +68,11 @@ Semantic versioning
 -------------------
 
 The idea of *semantic versioning* (or SemVer) is to use 3-part version numbers,
-*major.minor.maintenance*, where the project author increments:
+*major.minor.patch*, where the project author increments:
 
 - *major* when they make incompatible API changes,
 - *minor* when they add functionality in a backwards-compatible manner, and
-- *maintenance*, when they make backwards-compatible bug fixes.
+- *patch*, when they make backwards-compatible bug fixes.
 
 A majority of Python projects use a scheme that resembles semantic
 versioning. However, most projects, especially larger ones, do not strictly
@@ -159,6 +159,8 @@ since the latest release, setuptools-scm generates a version like
 
 --------------------------------------------------------------------------------
 
+.. [#version-examples] Some more examples of unusual version numbers are
+   given in a `blog post `_ by Seth Larson.
 
 .. [#semver-strictness] For some personal viewpoints on this issue, see these
    blog posts: `by Hynek Schlawak `_, `by Donald Stufft
@@ -176,3 +178,4 @@ since the latest release, setuptools-scm generates a version like
 .. _semver-donald-stufft: https://caremad.io/posts/2016/02/versioning-software/
 .. _semver-hynek-schlawack: https://hynek.me/articles/semver-will-not-save-you/
 .. _setuptools-scm: https://setuptools-scm.readthedocs.io
+.. _versions-seth-larson: https://sethmlarson.dev/pep-440

From bd555c5f759c7be146a31497e8eaa701ecc35e15 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sat, 27 Jan 2024 18:42:44 +0100
Subject: [PATCH 0634/1072] Fix reST syntax

---
 source/discussions/versioning.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/versioning.rst b/source/discussions/versioning.rst
index 8a738f866..c91273310 100644
--- a/source/discussions/versioning.rst
+++ b/source/discussions/versioning.rst
@@ -160,7 +160,7 @@ since the latest release, setuptools-scm generates a version like
 --------------------------------------------------------------------------------
 
 .. [#version-examples] Some more examples of unusual version numbers are
-   given in a `blog post `_ by Seth Larson.
+   given in a `blog post `_ by Seth Larson.
 
 .. [#semver-strictness] For some personal viewpoints on this issue, see these
    blog posts: `by Hynek Schlawak `_, `by Donald Stufft

From 2241c5039af75a4199b2645c8dc9f61d1d0b9017 Mon Sep 17 00:00:00 2001
From: Laurie O 
Date: Mon, 29 Jan 2024 11:36:54 +1000
Subject: [PATCH 0635/1072] Add 'dumb-pypi'

---
 source/guides/hosting-your-own-index.rst |  5 +++++
 source/key_projects.rst                  | 12 ++++++++++++
 2 files changed, 17 insertions(+)

diff --git a/source/guides/hosting-your-own-index.rst b/source/guides/hosting-your-own-index.rst
index 94ffb5d71..9b3c20069 100644
--- a/source/guides/hosting-your-own-index.rst
+++ b/source/guides/hosting-your-own-index.rst
@@ -105,6 +105,11 @@ Existing projects
      -
      - also mirroring; manual synchronisation
 
+   * - :ref:`dumb-pypi`
+     -
+     -
+     - not a server, but a static file site generator
+
    * - :ref:`httpserver`
      -
      -
diff --git a/source/key_projects.rst b/source/key_projects.rst
index ccd6ee883..853d4e065 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -442,6 +442,18 @@ devpi supports mirroring PyPI, multiple
 :term:`package indexes ` with inheritance, syncing between
 these indexes, index replication and fail-over, and package upload.
 
+.. _dumb-pypi:
+
+dumb-pypi
+=========
+
+`GitHub `__ |
+`PyPI `__
+
+dumb-pypi is a simple :term:`package index ` static file site
+generator, which then must be hosted by a static file webserver to become the
+package index. It supports serving the hash, core-metadata, and yank-status.
+
 .. _enscons:
 
 enscons

From b3e7b65f3f6bbc291a24b73e726684e50e300cc7 Mon Sep 17 00:00:00 2001
From: Laurie O 
Date: Wed, 31 Jan 2024 15:39:12 +1000
Subject: [PATCH 0636/1072] Remove duplicated-from-venv https.server
 description

---
 source/key_projects.rst | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index 853d4e065..531c28066 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -865,9 +865,6 @@ http.server
 A package and command-line interface which can host a directory as a
 website, for example as a :term:`package index ` (see
 :ref:`Hosting your Own Simple Repository`).
-A package in the Python Standard Library (starting with Python 3.3) for
-creating :term:`Virtual Environments `.  For more
-information, see the section on :ref:`Creating and using Virtual Environments`.
 
 .. _venv:
 

From 35c7f84c6ff6b2b530c9a781ab296786465b6e8e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sviatoslav=20Sydorenko=20=28=D0=A1=D0=B2=D1=8F=D1=82=D0=BE?=
 =?UTF-8?q?=D1=81=D0=BB=D0=B0=D0=B2=20=D0=A1=D0=B8=D0=B4=D0=BE=D1=80=D0=B5?=
 =?UTF-8?q?=D0=BD=D0=BA=D0=BE=29?= 
Date: Thu, 1 Feb 2024 03:09:57 +0100
Subject: [PATCH 0637/1072] Spell "fall back" as a verb with a whitespace

---
 source/guides/hosting-your-own-index.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/hosting-your-own-index.rst b/source/guides/hosting-your-own-index.rst
index 9b3c20069..ebcd228ee 100644
--- a/source/guides/hosting-your-own-index.rst
+++ b/source/guides/hosting-your-own-index.rst
@@ -131,7 +131,7 @@ Existing projects
 .. [1] For complete documentation of the simple repository protocol, see
        :ref:`simple repository API `.
 
-.. [2] Can be configured to fall-back to PyPI (or another package index)
+.. [2] Can be configured to fall back to PyPI (or another package index)
        if a requested package is missing.
 
 .. _Twisted: https://twistedmatrix.com/

From e28aa45e05fdfb1d3942a6919d7d1f55a8a4c34c Mon Sep 17 00:00:00 2001
From: wim glenn 
Date: Sat, 3 Feb 2024 15:55:42 -0600
Subject: [PATCH 0638/1072] Update modernize-setup-py-project.rst

---
 source/guides/modernize-setup-py-project.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/modernize-setup-py-project.rst b/source/guides/modernize-setup-py-project.rst
index bea636ca4..5b6ab3c26 100644
--- a/source/guides/modernize-setup-py-project.rst
+++ b/source/guides/modernize-setup-py-project.rst
@@ -124,7 +124,7 @@ and trigger the build in that environment.
 For some projects this isolation is unwanted and it can be deactivated as follows:
 
 * ``python -m build --no-isolation``
-* ``python -m install --no-build-isolation``
+* ``python -m pip install --no-build-isolation``
 
 For more details:
 

From 1935669329cd121dbe87e84f7f311805184d8c8b Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 7 Feb 2024 17:44:55 +0100
Subject: [PATCH 0639/1072] Apply suggestion from @webknjaz
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/discussions/versioning.rst | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/source/discussions/versioning.rst b/source/discussions/versioning.rst
index c91273310..49fbbf0de 100644
--- a/source/discussions/versioning.rst
+++ b/source/discussions/versioning.rst
@@ -63,6 +63,22 @@ number, and to decide which should be the next version number for a new release
 of a package. Two versioning schemes are commonly used for Python packages,
 semantic versioning and calendar versioning.
 
+.. caution::
+
+   The decision which version number to choose is up to a
+   project's maintainer. This effectively means that version
+   bumps reflect the maintainer's view. That view may differ
+   from the end-users' perception of what said formalized
+   versioning scheme promises them.
+
+   There are known exceptions for selecting the next version
+   number. The maintainers may consciously choose to break the
+   assumption that the last version segment only contains
+   backwards-compatible changes.
+   One such case is when security vulnerability needs to be
+   addressed. Security releases often come in patch versions
+   but contain breaking changes inevitably.
+
 
 Semantic versioning
 -------------------

From f937c9b765b2301e5931a83682fa06ac02539d4a Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 12 Feb 2024 21:47:09 +0000
Subject: [PATCH 0640/1072] [pre-commit.ci] pre-commit autoupdate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

updates:
- [github.com/astral-sh/ruff-pre-commit: v0.1.14 → v0.2.1](https://github.com/astral-sh/ruff-pre-commit/compare/v0.1.14...v0.2.1)
---
 .pre-commit-config.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index f46125add..3c24cfc46 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -34,7 +34,7 @@ repos:
   - id: rst-inline-touching-normal
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.1.14
+  rev: v0.2.1
   hooks:
     - id: ruff
     - id: ruff-format

From b9878e6f3c6b61cb9278d44d9dcbfb742561037d Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sat, 30 Dec 2023 14:38:36 +0100
Subject: [PATCH 0641/1072] Update tool recommendations

Fixes #1468
---
 source/guides/tool-recommendations.rst   | 183 +++++++++++++----------
 source/guides/writing-pyproject-toml.rst |   1 +
 2 files changed, 107 insertions(+), 77 deletions(-)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index 1a59201fa..2e7c64173 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -4,111 +4,140 @@
 Tool recommendations
 ====================
 
-If you're familiar with Python packaging and installation, and just want to know
-what tools are currently recommended, then here it is.
+The Python packaging landscape consists of many different tools. For many tasks,
+the Python Packaging Authority (PyPA, the umbrella organization which
+encompasses many packaging tools and maintains this guide) purposefully does not
+make a blanket recommendation; for example, the reason there exist many build
+backends is that the landscape was opened in order to enable the development of
+new backends serving certain users' needs better than the previously unique
+backend, setuptools. This guide does point to some tools that are widely
+recognized, and also makes some recommendations of tools that you should *not*
+use because they are deprecated or insecure.
+
+
+Virtual environments
+====================
+
+The standard tools to create and use virtual environments manually are
+:ref:`virtualenv` (PyPA project) and :doc:`venv ` (part of
+the Python standard library, though missing some features of virtualenv).
+
+
+Installing packages
+===================
+
+:ref:`Pip` is a standard tool to install packages from :term:`PyPI `. It can install into the global environment or into
+virtual environments. You may want to read pip's recommendations for
+:doc:`secure installs `. Pip is available by default
+in most Python installations.
+
+Alternatively, for installing Python command line applications specifically,
+consider :ref:`pipx`, which is a wrapper around pip that installs each
+application into a dedicated virtual environment in order to avoid conflicts
+with other applications and, on Linux, conflicts with the system.
+
+For scientific software specifically, consider :ref:`Conda` or :ref:`Spack`.
+
+.. todo:: Write a "pip vs. Conda" comparison, here or in a new discussion.
+
+Do **not** use ``easy_install`` (part of :ref:`setuptools`), which is deprecated
+in favor of pip (see :ref:`pip vs easy_install` for details). Likewise, do
+**not** use ``python setup.py install`` or ``python setup.py develop``, which
+are also deprecated (see :ref:`setup-py-deprecated` for background and
+:ref:`modernize-setup-py-project` for migration advice).
+
+
+Lock files
+==========
 
+:ref:`pip-tools` and :ref:`Pipenv` are two recognized tools to create lock
+files, which contain the exact versions of all packages installed into an
+environment, for reproducibility purposes.
 
-Application dependency management
-=================================
 
-* Use :ref:`pip` in a `secure manner`_ to install a Python application and its
-  dependencies during deployment.
+Build backends
+==============
 
-* Use :ref:`virtualenv` or :doc:`venv ` to isolate
-  application-specific dependencies from a shared Python installation. [4]_
+Popular :term:`build backends ` for pure-Python packages include:
 
-* Use `pip-tools`_, :ref:`pipenv`, or `poetry`_ to generate the fully-specified
-  application-specific dependencies, when developing Python applications.
+- Hatchling, which is part of :ref:`Hatch` (but can be used without
+  Hatch as well). Hatchling is extensible through a plugin system.
 
-.. _secure manner: https://pip.pypa.io/en/latest/topics/secure-installs/
-.. _pip-tools: https://github.com/jazzband/pip-tools
-.. _Poetry: https://python-poetry.org/
+- :ref:`setuptools`, the historical build backend. It can be configured
+  programmatically through the :file:`setup.py` file.
 
-Installation tool recommendations
-=================================
+  If you use setuptools, please be aware that it contains many deprecated
+  features which are currently kept for compatibility, but should not be used.
+  For example, do not use ``python setup.py`` invocations
+  (cf. :ref:`setup-py-deprecated`), the ``python_requires`` argument to
+  ``setup()`` (use the :ref:`[build-system] table
+  ` of :file:`pyproject.toml` instead), or
+  the ``easy_install`` command (cf. :ref:`pip vs easy_install`).
 
-* Use :ref:`pip` to install Python :term:`packages ` from
-  :term:`PyPI `. [1]_ [2]_ Depending on how :ref:`pip`
-  is installed, you may need to also install :ref:`wheel` to get the benefit
-  of wheel caching. [3]_
+- Flit-core, part of :ref:`Flit` (but usable standalone). It is meant to be a
+  minimal and opinionated build backend. It is not extensible.
 
-* Use :ref:`virtualenv` or :doc:`venv ` to isolate
-  project-specific dependencies from a shared Python installation. [4]_
+- PDM-backend_, part of :ref:`PDM` (but usable standalone). It provides build
+  hooks for extensibility.
 
-* If you're looking for management of fully integrated cross-platform software
-  stacks, consider:
+- Poetry-core, part of :ref:`Poetry` (but usable standalone). It is extensible
+  through plugins.
 
-  * :ref:`buildout`: primarily focused on the web development community
+Do **not** use distutils, which is deprecated, and has been removed from the
+standard library in Python 3.12, although it still remains available from
+setuptools.
 
-  * :ref:`spack`, :ref:`hashdist`, or :ref:`conda`: primarily focused
-    on the scientific community.
+For packages with :term:`extension modules `, you may use
+setuptools, but consider using a build system dedicated to the language the
+extension is written in, such as Meson or CMake for C/C++, or Cargo for Rust,
+and bridging this build system to Python using a dedicated build backend:
 
+- :ref:`meson-python` for Meson,
 
-Packaging tool recommendations
-==============================
+- :ref:`scikit-build-core` for CMake,
 
-* Use :ref:`setuptools` to define projects. [5]_ [6]_
+- :ref:`maturin` for Cargo.
 
-* Use :ref:`build` to create :term:`Source Distributions
-  ` and :term:`wheels `.
 
-If you have binary extensions and want to distribute wheels for multiple
-platforms, use :ref:`cibuildwheel` as part of your CI setup to build
-distributable wheels.
+Building distributions
+======================
 
-* Use `twine `_ for uploading distributions
-  to :term:`PyPI `.
+The standard tool to build :term:`source distributions ` and :term:`wheels ` for uploading to PyPI is :ref:`build`.  It
+will invoke whichever build backend you :ref:`declared
+` in :file:`pyproject.toml`.
 
+Do **not** use ``python setup.py sdist`` and ``python setup.py bdist_wheel`` for
+this task. All direct invocations of :file:`setup.py` are :ref:`deprecated
+`.
 
-Publishing platform migration
-=============================
+If you have :term:`extension modules ` and want to distribute
+wheels for multiple platforms, use :ref:`cibuildwheel` as part of your CI setup
+to build distributable wheels.
 
-The original Python Package Index implementation (previously hosted at
-`pypi.python.org `_) has been phased out in favour
-of an updated implementation hosted at `pypi.org `_.
 
-See :ref:`Migrating to PyPI.org` for more information on the status of the
-migration, and what settings to change in your clients.
+Uploading to PyPI
+=================
 
-----
+The standard tool for this task is :ref:`twine`.
 
-.. [1] There are some cases where you might choose to use ``easy_install`` (from
-       :ref:`setuptools`), e.g. if you need to install from :term:`Eggs `
-       (which pip doesn't support).  For a detailed breakdown, see :ref:`pip vs
-       easy_install`.
+**Never** use ``python setup.py upload`` for this task. In addition to being
+:ref:`deprecated `, it is insecure.
 
-.. [2] The acceptance of :pep:`453` means that :ref:`pip`
-       will be available by default in most installations of Python 3.4 or
-       later.  See the :pep:`rationale section <453#rationale>` from :pep:`453`
-       as for why pip was chosen.
 
-.. [3] `get-pip.py `_ and
-       :ref:`virtualenv` install
-       :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not
-       currently.  Also, the common "python-pip" package that's found in various
-       linux distros, does not depend on "python-wheel" currently.
+Integrated workflow tools
+=========================
 
-.. [4] Beginning with Python 3.4, ``venv`` will create virtualenv environments
-       with ``pip`` installed, thereby making it an equal alternative to
-       :ref:`virtualenv`. However, using :ref:`virtualenv` will still be
-       recommended for users that need cross-version consistency.
+These are tools that combine many features in one command line application, such
+as automatically managing virtual environments for a project, building
+distributions, uploading to PyPI, or creating and using lock files.
 
-.. [5] Although you can use pure :ref:`distutils` for many projects, it does not
-       support defining dependencies on other projects and is missing several
-       convenience utilities for automatically populating distribution metadata
-       correctly that are provided by ``setuptools``. Being outside the
-       standard library, ``setuptools`` also offers a more consistent feature
-       set across different versions of Python, and (unlike ``distutils``),
-       recent versions of ``setuptools`` support all of the modern metadata
-       fields described in :ref:`core-metadata`.
+- :ref:`Hatch`,
+- :ref:`Flit`,
+- :ref:`PDM`,
+- :ref:`Poetry`.
 
-       Even for projects that do choose to use ``distutils``, when :ref:`pip`
-       installs such projects directly from source (rather than installing
-       from a prebuilt :term:`wheel ` file), it will actually build
-       your project using :ref:`setuptools` instead.
 
-.. [6] `distribute`_ (a fork of setuptools) was merged back into
-       :ref:`setuptools` in June 2013, thereby making setuptools the default
-       choice for packaging.
 
-.. _distribute: https://pypi.org/project/distribute
+.. _pdm-backend: https://backend.pdm-project.org
diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index 187a44d50..938ebbb93 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -40,6 +40,7 @@ three possible TOML tables in this file.
    :ref:`setup-py-deprecated`.
 
 
+.. _pyproject-guide-build-system-table:
 
 Declaring the build backend
 ===========================

From dc4ff6692806bb4aa35b00eeb630b2fa6bd142ee Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Sat, 30 Dec 2023 16:20:14 +0100
Subject: [PATCH 0642/1072] Address @chrysle's review

---
 source/guides/tool-recommendations.rst | 34 ++++++++++++++------------
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index 2e7c64173..a34df5d65 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -5,14 +5,15 @@ Tool recommendations
 ====================
 
 The Python packaging landscape consists of many different tools. For many tasks,
-the Python Packaging Authority (PyPA, the umbrella organization which
-encompasses many packaging tools and maintains this guide) purposefully does not
-make a blanket recommendation; for example, the reason there exist many build
-backends is that the landscape was opened in order to enable the development of
-new backends serving certain users' needs better than the previously unique
-backend, setuptools. This guide does point to some tools that are widely
-recognized, and also makes some recommendations of tools that you should *not*
-use because they are deprecated or insecure.
+the :term:`Python Packaging Authority `
+(PyPA, the umbrella organization which encompasses many packaging tools and
+maintains this guide) purposefully does not make a blanket recommendation; for
+example, the reason there exist many build backends is that the landscape was
+opened in order to enable the development of new backends serving certain users'
+needs better than the previously unique backend, setuptools. This guide does
+point to some tools that are widely recognized, and also makes some
+recommendations of tools that you should *not* use because they are deprecated
+or insecure.
 
 
 Virtual environments
@@ -26,7 +27,7 @@ the Python standard library, though missing some features of virtualenv).
 Installing packages
 ===================
 
-:ref:`Pip` is a standard tool to install packages from :term:`PyPI `. It can install into the global environment or into
 virtual environments. You may want to read pip's recommendations for
 :doc:`secure installs `. Pip is available by default
@@ -34,8 +35,10 @@ in most Python installations.
 
 Alternatively, for installing Python command line applications specifically,
 consider :ref:`pipx`, which is a wrapper around pip that installs each
-application into a dedicated virtual environment in order to avoid conflicts
-with other applications and, on Linux, conflicts with the system.
+application into a dedicated virtual environment. This avoids conflicts between
+the dependencies of different applications. On Linux, pipx is especially
+important because it also avoids conflicts with the system (which are the reason
+for :ref:`externally managed environments `).
 
 For scientific software specifically, consider :ref:`Conda` or :ref:`Spack`.
 
@@ -65,11 +68,12 @@ Popular :term:`build backends ` for pure-Python packages include:
   Hatch as well). Hatchling is extensible through a plugin system.
 
 - :ref:`setuptools`, the historical build backend. It can be configured
-  programmatically through the :file:`setup.py` file.
+  programmatically through the :file:`setup.py` file (but for basic metadata,
+  :file:`pyproject.toml` is preferred).
 
   If you use setuptools, please be aware that it contains many deprecated
   features which are currently kept for compatibility, but should not be used.
-  For example, do not use ``python setup.py`` invocations
+  For example, do **not** use ``python setup.py`` invocations
   (cf. :ref:`setup-py-deprecated`), the ``python_requires`` argument to
   ``setup()`` (use the :ref:`[build-system] table
   ` of :file:`pyproject.toml` instead), or
@@ -84,8 +88,8 @@ Popular :term:`build backends ` for pure-Python packages include:
 - Poetry-core, part of :ref:`Poetry` (but usable standalone). It is extensible
   through plugins.
 
-Do **not** use distutils, which is deprecated, and has been removed from the
-standard library in Python 3.12, although it still remains available from
+Do **not** use :ref:`distutils`, which is deprecated, and has been removed from
+the standard library in Python 3.12, although it still remains available from
 setuptools.
 
 For packages with :term:`extension modules `, you may use

From f5df94159862516cad4d4d0adf379a644fa8ed61 Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Sun, 31 Dec 2023 14:12:27 +0100
Subject: [PATCH 0643/1072] Fix brain fart

---
 source/guides/tool-recommendations.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index a34df5d65..11c57aa7d 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -74,7 +74,7 @@ Popular :term:`build backends ` for pure-Python packages include:
   If you use setuptools, please be aware that it contains many deprecated
   features which are currently kept for compatibility, but should not be used.
   For example, do **not** use ``python setup.py`` invocations
-  (cf. :ref:`setup-py-deprecated`), the ``python_requires`` argument to
+  (cf. :ref:`setup-py-deprecated`), the ``setup_requires`` argument to
   ``setup()`` (use the :ref:`[build-system] table
   ` of :file:`pyproject.toml` instead), or
   the ``easy_install`` command (cf. :ref:`pip vs easy_install`).

From 620222cb291413358d6860f33f76210e74fe3456 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 3 Jan 2024 12:38:37 +0100
Subject: [PATCH 0644/1072] Address review comments from @webknjaz and
 @eli-schwartz

---
 source/guides/tool-recommendations.rst | 47 +++++++++++++++-----------
 1 file changed, 27 insertions(+), 20 deletions(-)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index 11c57aa7d..1778851d5 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -6,10 +6,10 @@ Tool recommendations
 
 The Python packaging landscape consists of many different tools. For many tasks,
 the :term:`Python Packaging Authority `
-(PyPA, the umbrella organization which encompasses many packaging tools and
+(PyPA, the working group which encompasses many packaging tools and
 maintains this guide) purposefully does not make a blanket recommendation; for
-example, the reason there exist many build backends is that the landscape was
-opened in order to enable the development of new backends serving certain users'
+example, the reason there are many build backends is that the landscape was
+opened up in order to enable the development of new backends serving certain users'
 needs better than the previously unique backend, setuptools. This guide does
 point to some tools that are widely recognized, and also makes some
 recommendations of tools that you should *not* use because they are deprecated
@@ -31,14 +31,15 @@ Installing packages
 Package Index (PyPI)>`. It can install into the global environment or into
 virtual environments. You may want to read pip's recommendations for
 :doc:`secure installs `. Pip is available by default
-in most Python installations.
+in most Python installations through the standard library package
+:doc:`ensurepip `.
 
-Alternatively, for installing Python command line applications specifically,
-consider :ref:`pipx`, which is a wrapper around pip that installs each
+Alternatively, consider :ref:`pipx` for the specific use case of installing Python
+command line applications that are distributed through PyPI.
+Pipx is a wrapper around pip and venv that installs each
 application into a dedicated virtual environment. This avoids conflicts between
-the dependencies of different applications. On Linux, pipx is especially
-important because it also avoids conflicts with the system (which are the reason
-for :ref:`externally managed environments `).
+the dependencies of different applications, and also with the system
+(especially on Linux).
 
 For scientific software specifically, consider :ref:`Conda` or :ref:`Spack`.
 
@@ -64,10 +65,10 @@ Build backends
 
 Popular :term:`build backends ` for pure-Python packages include:
 
-- Hatchling, which is part of :ref:`Hatch` (but can be used without
-  Hatch as well). Hatchling is extensible through a plugin system.
+- Hatchling_, which is developed along with :ref:`Hatch`, but is separate and can
+  be used without Hatch. Hatchling is extensible through a plugin system.
 
-- :ref:`setuptools`, the historical build backend. It can be configured
+- :ref:`setuptools` (which used to be the only build backend). It can be configured
   programmatically through the :file:`setup.py` file (but for basic metadata,
   :file:`pyproject.toml` is preferred).
 
@@ -79,13 +80,13 @@ Popular :term:`build backends ` for pure-Python packages include:
   ` of :file:`pyproject.toml` instead), or
   the ``easy_install`` command (cf. :ref:`pip vs easy_install`).
 
-- Flit-core, part of :ref:`Flit` (but usable standalone). It is meant to be a
+- Flit-core_ (developed with but separate from :ref:`Flit`). It is meant to be a
   minimal and opinionated build backend. It is not extensible.
 
-- PDM-backend_, part of :ref:`PDM` (but usable standalone). It provides build
+- PDM-backend_ (developed with but separate from :ref:`PDM`). It provides build
   hooks for extensibility.
 
-- Poetry-core, part of :ref:`Poetry` (but usable standalone). It is extensible
+- Poetry-core_ (developed with but separate from :ref:`Poetry`). It is extensible
   through plugins.
 
 Do **not** use :ref:`distutils`, which is deprecated, and has been removed from
@@ -93,9 +94,11 @@ the standard library in Python 3.12, although it still remains available from
 setuptools.
 
 For packages with :term:`extension modules `, you may use
-setuptools, but consider using a build system dedicated to the language the
-extension is written in, such as Meson or CMake for C/C++, or Cargo for Rust,
-and bridging this build system to Python using a dedicated build backend:
+setuptools. However, you can also use a build system with dedicated support for
+the language the extension is written in. For example, you could choose Meson or
+CMake for C, C++, Fortran and many other compiled languages; or Cargo for Rust
+specifically. You can then bridge this build system to Python using a dedicated
+build backend:
 
 - :ref:`meson-python` for Meson,
 
@@ -135,13 +138,17 @@ Integrated workflow tools
 
 These are tools that combine many features in one command line application, such
 as automatically managing virtual environments for a project, building
-distributions, uploading to PyPI, or creating and using lock files.
+distributions, uploading to PyPI, or creating and using (tool-specific) lock
+files. They often call the tools mentioned above under the hood.
 
 - :ref:`Hatch`,
 - :ref:`Flit`,
 - :ref:`PDM`,
 - :ref:`Poetry`.
+- :ref:`Pipenv`
 
 
-
+.. _flit-core: https://pypi.org/project/flit-core/
+.. _hatchling: https://pypi.org/project/hatchling/
 .. _pdm-backend: https://backend.pdm-project.org
+.. _poetry-core: https://pypi.org/project/poetry-core/

From fc6f4207a65a0d4bb7db5ae72f54f2c2bb1ce32b Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 3 Jan 2024 12:40:15 +0100
Subject: [PATCH 0645/1072] Sort tools alphabetically

---
 source/guides/tool-recommendations.rst | 28 ++++++++++++++------------
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index 1778851d5..b883b60cc 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -63,11 +63,21 @@ environment, for reproducibility purposes.
 Build backends
 ==============
 
-Popular :term:`build backends ` for pure-Python packages include:
+Popular :term:`build backends ` for pure-Python packages include,
+in alphabetical order:
+
+- Flit-core_ (developed with but separate from :ref:`Flit`). It is meant to be a
+  minimal and opinionated build backend. It is not extensible.
 
 - Hatchling_, which is developed along with :ref:`Hatch`, but is separate and can
   be used without Hatch. Hatchling is extensible through a plugin system.
 
+- PDM-backend_ (developed with but separate from :ref:`PDM`). It provides build
+  hooks for extensibility.
+
+- Poetry-core_ (developed with but separate from :ref:`Poetry`). It is extensible
+  through plugins.
+
 - :ref:`setuptools` (which used to be the only build backend). It can be configured
   programmatically through the :file:`setup.py` file (but for basic metadata,
   :file:`pyproject.toml` is preferred).
@@ -80,15 +90,6 @@ Popular :term:`build backends ` for pure-Python packages include:
   ` of :file:`pyproject.toml` instead), or
   the ``easy_install`` command (cf. :ref:`pip vs easy_install`).
 
-- Flit-core_ (developed with but separate from :ref:`Flit`). It is meant to be a
-  minimal and opinionated build backend. It is not extensible.
-
-- PDM-backend_ (developed with but separate from :ref:`PDM`). It provides build
-  hooks for extensibility.
-
-- Poetry-core_ (developed with but separate from :ref:`Poetry`). It is extensible
-  through plugins.
-
 Do **not** use :ref:`distutils`, which is deprecated, and has been removed from
 the standard library in Python 3.12, although it still remains available from
 setuptools.
@@ -139,13 +140,14 @@ Integrated workflow tools
 These are tools that combine many features in one command line application, such
 as automatically managing virtual environments for a project, building
 distributions, uploading to PyPI, or creating and using (tool-specific) lock
-files. They often call the tools mentioned above under the hood.
+files. They often call the tools mentioned above under the hood. In alphabetical
+order:
 
-- :ref:`Hatch`,
 - :ref:`Flit`,
+- :ref:`Hatch`,
 - :ref:`PDM`,
+- :ref:`Pipenv`,
 - :ref:`Poetry`.
-- :ref:`Pipenv`
 
 
 .. _flit-core: https://pypi.org/project/flit-core/

From 52e7eac7b7bba631a505f05b7d924a0d53622d6b Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Wed, 3 Jan 2024 17:40:00 +0100
Subject: [PATCH 0646/1072] Suggestions from @abravalheri

Co-authored-by: Anderson Bravalheri 
---
 source/guides/tool-recommendations.rst | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index b883b60cc..3a6ec813c 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -79,6 +79,8 @@ in alphabetical order:
   through plugins.
 
 - :ref:`setuptools` (which used to be the only build backend). It can be configured
+  using modern standards like `pyproject.toml`, but can also be extended
+  and supports customisation via `setup.py`.
   programmatically through the :file:`setup.py` file (but for basic metadata,
   :file:`pyproject.toml` is preferred).
 
@@ -95,11 +97,13 @@ the standard library in Python 3.12, although it still remains available from
 setuptools.
 
 For packages with :term:`extension modules `, you may use
-setuptools. However, you can also use a build system with dedicated support for
-the language the extension is written in. For example, you could choose Meson or
-CMake for C, C++, Fortran and many other compiled languages; or Cargo for Rust
-specifically. You can then bridge this build system to Python using a dedicated
-build backend:
+a build system with dedicated support for the language the extension is written in,
+for example:
+
+- :ref:`setuptools` - natively supports C/C++ (with 3rd-party plugins for Go and Rust);
+- :ref:`meson-python` - C, C++, Fortran, and Rust and other languages supported by Meson;
+- :ref:`scikit-build-core` - C, C++, Fortran and other languages supported by CMake;
+- :ref:`maturin` - Rust, via Cargo.
 
 - :ref:`meson-python` for Meson,
 

From 874ebbc35ed3fac5c9669c379387364c59927acc Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 3 Jan 2024 17:44:02 +0100
Subject: [PATCH 0647/1072] Minor fixes/improvements

---
 source/guides/tool-recommendations.rst | 23 ++++++++---------------
 1 file changed, 8 insertions(+), 15 deletions(-)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index 3a6ec813c..de7cd9e70 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -78,11 +78,10 @@ in alphabetical order:
 - Poetry-core_ (developed with but separate from :ref:`Poetry`). It is extensible
   through plugins.
 
-- :ref:`setuptools` (which used to be the only build backend). It can be configured
-  using modern standards like `pyproject.toml`, but can also be extended
-  and supports customisation via `setup.py`.
-  programmatically through the :file:`setup.py` file (but for basic metadata,
-  :file:`pyproject.toml` is preferred).
+- :ref:`setuptools` (which used to be the only build backend). It can be
+  configured using modern standards like the :ref:`[project] table in
+  pyproject.toml `, but can also be extended and
+  customized via :file:`setup.py`.
 
   If you use setuptools, please be aware that it contains many deprecated
   features which are currently kept for compatibility, but should not be used.
@@ -100,16 +99,10 @@ For packages with :term:`extension modules `, you may use
 a build system with dedicated support for the language the extension is written in,
 for example:
 
-- :ref:`setuptools` - natively supports C/C++ (with 3rd-party plugins for Go and Rust);
-- :ref:`meson-python` - C, C++, Fortran, and Rust and other languages supported by Meson;
-- :ref:`scikit-build-core` - C, C++, Fortran and other languages supported by CMake;
-- :ref:`maturin` - Rust, via Cargo.
-
-- :ref:`meson-python` for Meson,
-
-- :ref:`scikit-build-core` for CMake,
-
-- :ref:`maturin` for Cargo.
+- :ref:`setuptools` -- natively supports C and C++ (with third-party plugins for Go and Rust),
+- :ref:`meson-python` -- C, C++, Fortran, Rust, and other languages supported by Meson,
+- :ref:`scikit-build-core` -- C, C++, Fortran, and other languages supported by CMake,
+- :ref:`maturin` -- Rust, via Cargo.
 
 
 Building distributions

From 6d285fe3ea64f6cda14879e5b5e2d7e950adae6b Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 3 Jan 2024 17:58:31 +0100
Subject: [PATCH 0648/1072] Mention tox and nox

---
 source/guides/tool-recommendations.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index de7cd9e70..0c7be1f54 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -131,6 +131,15 @@ The standard tool for this task is :ref:`twine`.
 :ref:`deprecated `, it is insecure.
 
 
+Task runners
+============
+
+These tools allow you to define and invoke "tasks", such as running tests,
+compiling documentation, regenerating some files, etc. Each task can be executed
+in a dedicated virtual environment with the dependencies it requires. The most
+common tools for this are :ref:`tox` and :ref:`nox`.
+
+
 Integrated workflow tools
 =========================
 

From 8c34a17ed313c188d1ef3dee81c9962edb7270dd Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 3 Jan 2024 18:03:07 +0100
Subject: [PATCH 0649/1072] Fix tox/nox links

---
 source/guides/tool-recommendations.rst | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index 0c7be1f54..80769f331 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -137,7 +137,7 @@ Task runners
 These tools allow you to define and invoke "tasks", such as running tests,
 compiling documentation, regenerating some files, etc. Each task can be executed
 in a dedicated virtual environment with the dependencies it requires. The most
-common tools for this are :ref:`tox` and :ref:`nox`.
+common tools for this are tox_ and nox_.
 
 
 Integrated workflow tools
@@ -158,5 +158,7 @@ order:
 
 .. _flit-core: https://pypi.org/project/flit-core/
 .. _hatchling: https://pypi.org/project/hatchling/
+.. _nox: https://nox.thea.codes
 .. _pdm-backend: https://backend.pdm-project.org
 .. _poetry-core: https://pypi.org/project/poetry-core/
+.. _tox: https://tox.wiki

From dc02b6d8a361809bb8ab96920f7876d678b6b4e8 Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Thu, 4 Jan 2024 00:01:00 +0100
Subject: [PATCH 0650/1072] Rewording from @abravalheri

Co-authored-by: Anderson Bravalheri 
---
 source/guides/tool-recommendations.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index 80769f331..c9b15d164 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -83,8 +83,8 @@ in alphabetical order:
   pyproject.toml `, but can also be extended and
   customized via :file:`setup.py`.
 
-  If you use setuptools, please be aware that it contains many deprecated
-  features which are currently kept for compatibility, but should not be used.
+  If you use setuptools, please be aware that some features that predate
+  standardisation efforts are now deprecated and only *temporarily kept* for compatibility.
   For example, do **not** use ``python setup.py`` invocations
   (cf. :ref:`setup-py-deprecated`), the ``setup_requires`` argument to
   ``setup()`` (use the :ref:`[build-system] table

From 9671ddbd04576dd068d332780d516b41bfd6da3d Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Tue, 16 Jan 2024 19:09:39 +0100
Subject: [PATCH 0651/1072] Various minor rewordings

---
 source/guides/tool-recommendations.rst | 43 +++++++++++++++-----------
 1 file changed, 25 insertions(+), 18 deletions(-)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index c9b15d164..cb5bb549a 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -66,36 +66,43 @@ Build backends
 Popular :term:`build backends ` for pure-Python packages include,
 in alphabetical order:
 
-- Flit-core_ (developed with but separate from :ref:`Flit`). It is meant to be a
-  minimal and opinionated build backend. It is not extensible.
+- Flit-core_ -- developed with but separate from :ref:`Flit`. A minimal and
+  opinionated build backend. It does not support plugins.
 
-- Hatchling_, which is developed along with :ref:`Hatch`, but is separate and can
-  be used without Hatch. Hatchling is extensible through a plugin system.
+- Hatchling_ -- developed with but separate from :ref:`Hatch`. Supports plugins.
 
-- PDM-backend_ (developed with but separate from :ref:`PDM`). It provides build
-  hooks for extensibility.
+- PDM-backend_ -- developed with but separate from :ref:`PDM`. Supports plugins.
 
-- Poetry-core_ (developed with but separate from :ref:`Poetry`). It is extensible
-  through plugins.
+- Poetry-core_ -- developed with but separate from :ref:`Poetry`. Supports
+  plugins.
 
-- :ref:`setuptools` (which used to be the only build backend). It can be
-  configured using modern standards like the :ref:`[project] table in
-  pyproject.toml `, but can also be extended and
-  customized via :file:`setup.py`.
+  Unlike other backends on this list, Poetry-core does not support the standard
+  :ref:`[project] table ` (it uses a different format,
+  in the ``[tool.poetry]`` table).
+
+- :ref:`setuptools`, which used to be the only build backend. Supports plugins.
 
   If you use setuptools, please be aware that some features that predate
-  standardisation efforts are now deprecated and only *temporarily kept* for compatibility.
-  For example, do **not** use ``python setup.py`` invocations
-  (cf. :ref:`setup-py-deprecated`), the ``setup_requires`` argument to
-  ``setup()`` (use the :ref:`[build-system] table
-  ` of :file:`pyproject.toml` instead), or
+  standardisation efforts are now deprecated and only *temporarily kept*
+  for compatibility.
+
+  In particular, do **not** use direct ``python setup.py`` invocations. On the
+  other hand, configuring setuptools with a :file:`setup.py` file is still fully
+  supported, although it is recommended to use the modern :ref:`[project] table
+  in pyproject.toml ` whenever possible and keep
+  :file:`setup.py` only if programmatic configuration is needed. See
+  :ref:`setup-py-deprecated`.
+
+  Other examples of deprecated features you should **not** use include the
+  ``setup_requires`` argument to ``setup()`` (use the :ref:`[build-system] table
+  ` in :file:`pyproject.toml` instead), and
   the ``easy_install`` command (cf. :ref:`pip vs easy_install`).
 
 Do **not** use :ref:`distutils`, which is deprecated, and has been removed from
 the standard library in Python 3.12, although it still remains available from
 setuptools.
 
-For packages with :term:`extension modules `, you may use
+For packages with :term:`extension modules `, it is best to use
 a build system with dedicated support for the language the extension is written in,
 for example:
 

From 80a18861ec58883f54d77263727d058202ae7e78 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Thu, 25 Jan 2024 10:42:44 +0100
Subject: [PATCH 0652/1072] Address review comments

---
 source/guides/tool-recommendations.rst | 43 +++++++++++++-------------
 1 file changed, 21 insertions(+), 22 deletions(-)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index cb5bb549a..788e51b09 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -35,11 +35,11 @@ in most Python installations through the standard library package
 :doc:`ensurepip `.
 
 Alternatively, consider :ref:`pipx` for the specific use case of installing Python
-command line applications that are distributed through PyPI.
+applications that are distributed through PyPI and run from the command line.
 Pipx is a wrapper around pip and venv that installs each
 application into a dedicated virtual environment. This avoids conflicts between
-the dependencies of different applications, and also with the system
-(especially on Linux).
+the dependencies of different applications, and also with system-wide applications
+making use of the same Python interpreter (especially on Linux).
 
 For scientific software specifically, consider :ref:`Conda` or :ref:`Spack`.
 
@@ -66,8 +66,8 @@ Build backends
 Popular :term:`build backends ` for pure-Python packages include,
 in alphabetical order:
 
-- Flit-core_ -- developed with but separate from :ref:`Flit`. A minimal and
-  opinionated build backend. It does not support plugins.
+- :doc:`Flit-core ` -- developed with but separate from :ref:`Flit`.
+  A minimal and opinionated build backend. It does not support plugins.
 
 - Hatchling_ -- developed with but separate from :ref:`Hatch`. Supports plugins.
 
@@ -82,21 +82,23 @@ in alphabetical order:
 
 - :ref:`setuptools`, which used to be the only build backend. Supports plugins.
 
-  If you use setuptools, please be aware that some features that predate
-  standardisation efforts are now deprecated and only *temporarily kept*
-  for compatibility.
+  .. caution::
 
-  In particular, do **not** use direct ``python setup.py`` invocations. On the
-  other hand, configuring setuptools with a :file:`setup.py` file is still fully
-  supported, although it is recommended to use the modern :ref:`[project] table
-  in pyproject.toml ` whenever possible and keep
-  :file:`setup.py` only if programmatic configuration is needed. See
-  :ref:`setup-py-deprecated`.
+     If you use setuptools, please be aware that some features that predate
+     standardisation efforts are now deprecated and only *temporarily kept*
+     for compatibility.
 
-  Other examples of deprecated features you should **not** use include the
-  ``setup_requires`` argument to ``setup()`` (use the :ref:`[build-system] table
-  ` in :file:`pyproject.toml` instead), and
-  the ``easy_install`` command (cf. :ref:`pip vs easy_install`).
+     In particular, do **not** use direct ``python setup.py`` invocations. On the
+     other hand, configuring setuptools with a :file:`setup.py` file is still fully
+     supported, although it is recommended to use the modern :ref:`[project] table
+     in pyproject.toml ` whenever possible and keep
+     :file:`setup.py` only if programmatic configuration is needed. See
+     :ref:`setup-py-deprecated`.
+
+     Other examples of deprecated features you should **not** use include the
+     ``setup_requires`` argument to ``setup()`` (use the :ref:`[build-system] table
+     ` in :file:`pyproject.toml` instead), and
+     the ``easy_install`` command (cf. :ref:`pip vs easy_install`).
 
 Do **not** use :ref:`distutils`, which is deprecated, and has been removed from
 the standard library in Python 3.12, although it still remains available from
@@ -144,7 +146,7 @@ Task runners
 These tools allow you to define and invoke "tasks", such as running tests,
 compiling documentation, regenerating some files, etc. Each task can be executed
 in a dedicated virtual environment with the dependencies it requires. The most
-common tools for this are tox_ and nox_.
+common tools for this are :doc:`tox ` and :doc:`nox `.
 
 
 Integrated workflow tools
@@ -163,9 +165,6 @@ order:
 - :ref:`Poetry`.
 
 
-.. _flit-core: https://pypi.org/project/flit-core/
 .. _hatchling: https://pypi.org/project/hatchling/
-.. _nox: https://nox.thea.codes
 .. _pdm-backend: https://backend.pdm-project.org
 .. _poetry-core: https://pypi.org/project/poetry-core/
-.. _tox: https://tox.wiki

From b5cdeb9228b3b7b18e88f06b3834fe006531ac28 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Thu, 25 Jan 2024 20:46:31 +0100
Subject: [PATCH 0653/1072] Mention PyPI trusted publishing

---
 ...ution-releases-using-github-actions-ci-cd-workflows.rst | 2 ++
 source/guides/tool-recommendations.rst                     | 7 ++++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
index ca75d159b..99ac3a9e2 100644
--- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
+++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
@@ -1,3 +1,5 @@
+.. _trusted-publishing:
+
 =============================================================================
 Publishing package distribution releases using GitHub Actions CI/CD workflows
 =============================================================================
diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index 788e51b09..594191182 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -134,7 +134,12 @@ to build distributable wheels.
 Uploading to PyPI
 =================
 
-The standard tool for this task is :ref:`twine`.
+For projects hosted on GitHub, PyPI recommends using :ref:`trusted publishing
+`, which allows the package to be securely uploaded to PyPI
+from a GitHub Actions job. (This is not yet supported on software forges other
+than GitHub.)
+
+The other available method is to upload the package manually using :ref:`twine`.
 
 **Never** use ``python setup.py upload`` for this task. In addition to being
 :ref:`deprecated `, it is insecure.

From eab0fd88be7c7a1c2e04601e81f95a4b5f629ef3 Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Thu, 25 Jan 2024 20:48:05 +0100
Subject: [PATCH 0654/1072] Mention setup.cfg
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/guides/tool-recommendations.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index 594191182..cfbd7d59f 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -91,7 +91,7 @@ in alphabetical order:
      In particular, do **not** use direct ``python setup.py`` invocations. On the
      other hand, configuring setuptools with a :file:`setup.py` file is still fully
      supported, although it is recommended to use the modern :ref:`[project] table
-     in pyproject.toml ` whenever possible and keep
+     in pyproject.toml ` (or :file:`setup.cfg`) whenever possible and keep
      :file:`setup.py` only if programmatic configuration is needed. See
      :ref:`setup-py-deprecated`.
 

From c08cee83b22c4b7aea99a5b3ba62a5c63ae628dc Mon Sep 17 00:00:00 2001
From: Jean Abou-Samra 
Date: Thu, 25 Jan 2024 20:56:24 +0100
Subject: [PATCH 0655/1072] =?UTF-8?q?PyPI=20recommends=20=E2=86=92=20it=20?=
 =?UTF-8?q?is=20recommended?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/guides/tool-recommendations.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index cfbd7d59f..88ff6884c 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -134,7 +134,7 @@ to build distributable wheels.
 Uploading to PyPI
 =================
 
-For projects hosted on GitHub, PyPI recommends using :ref:`trusted publishing
+For projects hosted on GitHub, it is recommended to use the :ref:`trusted publishing
 `, which allows the package to be securely uploaded to PyPI
 from a GitHub Actions job. (This is not yet supported on software forges other
 than GitHub.)

From 44f086f8b82694f22a7bd8f9d9b0568da92b529a Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Thu, 25 Jan 2024 22:01:24 +0100
Subject: [PATCH 0656/1072] Remove sentence about global/virtual environments

---
 source/guides/tool-recommendations.rst | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index 88ff6884c..9ba538b9d 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -28,8 +28,7 @@ Installing packages
 ===================
 
 :ref:`Pip` is the standard tool to install packages from :term:`PyPI `. It can install into the global environment or into
-virtual environments. You may want to read pip's recommendations for
+Package Index (PyPI)>`. You may want to read pip's recommendations for
 :doc:`secure installs `. Pip is available by default
 in most Python installations through the standard library package
 :doc:`ensurepip `.

From 330d33ccfa7277900da6f76f1ba16d78b8196d99 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Tue, 30 Jan 2024 11:43:51 +0100
Subject: [PATCH 0657/1072] Present tox/nox along workflow tools

---
 source/guides/tool-recommendations.rst | 29 +++++++++++---------------
 1 file changed, 12 insertions(+), 17 deletions(-)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index 9ba538b9d..fb394deca 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -144,29 +144,24 @@ The other available method is to upload the package manually using :ref:`twine`.
 :ref:`deprecated `, it is insecure.
 
 
-Task runners
-============
-
-These tools allow you to define and invoke "tasks", such as running tests,
-compiling documentation, regenerating some files, etc. Each task can be executed
-in a dedicated virtual environment with the dependencies it requires. The most
-common tools for this are :doc:`tox ` and :doc:`nox `.
-
-
-Integrated workflow tools
-=========================
+Workflow tools
+==============
 
-These are tools that combine many features in one command line application, such
-as automatically managing virtual environments for a project, building
-distributions, uploading to PyPI, or creating and using (tool-specific) lock
-files. They often call the tools mentioned above under the hood. In alphabetical
-order:
+These tools are environment managers that automatically manage virtual
+environments for a project. They also act as "task runners", allowing you to
+define and invoke tasks such as running tests, compiling documentation,
+regenerating some files, etc. Some of them provide shortcuts for building
+distributions and uploading to PyPI, and some support lock files for
+applications. They often call the tools mentioned above under the hood. In
+alphabetical order:
 
 - :ref:`Flit`,
 - :ref:`Hatch`,
+- :doc:`nox `,
 - :ref:`PDM`,
 - :ref:`Pipenv`,
-- :ref:`Poetry`.
+- :ref:`Poetry`,
+- :doc:`tox `.
 
 
 .. _hatchling: https://pypi.org/project/hatchling/

From 8bd667683c54f24ac99a161db3e206ed960dfc4c Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Thu, 1 Feb 2024 12:11:33 +0100
Subject: [PATCH 0658/1072] Add reminder about not steering to a particular
 tool

---
 source/guides/tool-recommendations.rst | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index fb394deca..3903232b9 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -62,6 +62,12 @@ environment, for reproducibility purposes.
 Build backends
 ==============
 
+.. important::
+
+   Please, remember: this document does not seek to steer the reader towards
+   a particular tool, only to enumerate common tools. Different use cases often
+   need specialized workflows.
+
 Popular :term:`build backends ` for pure-Python packages include,
 in alphabetical order:
 

From eb73c32e8b39d7661d34dae4566c4ea0e390711d Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Sun, 25 Feb 2024 19:22:28 -0800
Subject: [PATCH 0659/1072] Add stack overflow to linkcheck ignore list

---
 source/conf.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/source/conf.py b/source/conf.py
index 786e67dd3..12885af3b 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -107,6 +107,8 @@
     # Temporarily ignored. Ref:
     # https://github.com/pypa/packaging.python.org/pull/1308#issuecomment-1775347690
     "https://www.breezy-vcs.org/*",
+    # Blocked due to https://github.com/pypa/packaging.python.org/pull/1474
+    "https://stackoverflow.com/*",
 ]
 linkcheck_retries = 5
 # Ignore anchors for links to GitHub project pages -- GitHub adds anchors from

From 087aa93a0c6663477f5c0ce6009d290d2305730e Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Mon, 26 Feb 2024 16:40:37 -0800
Subject: [PATCH 0660/1072] Clarify comment per review

---
 source/conf.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/source/conf.py b/source/conf.py
index 12885af3b..831f9c9ea 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -107,7 +107,8 @@
     # Temporarily ignored. Ref:
     # https://github.com/pypa/packaging.python.org/pull/1308#issuecomment-1775347690
     "https://www.breezy-vcs.org/*",
-    # Blocked due to https://github.com/pypa/packaging.python.org/pull/1474
+    # Ignore while StackOverflow is blocking GitHub CI. Ref:
+    # https://github.com/pypa/packaging.python.org/pull/1474
     "https://stackoverflow.com/*",
 ]
 linkcheck_retries = 5

From a45329c9a2e78ab80d74716e37e01f6ef0819ec2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edgar=20Ram=C3=ADrez-Mondrag=C3=B3n?= 
Date: Tue, 27 Feb 2024 23:43:49 -0600
Subject: [PATCH 0661/1072] Document the JSON schema of `direct_url.json`

---
 .../direct-url-data-structure.rst             | 122 ++++++++++++++++++
 1 file changed, 122 insertions(+)

diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index 993f40f59..da4d959e4 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -213,6 +213,128 @@ vcs command
    this field is the Subversion revision number in the corresponding
    repository.
 
+JSON Schema
+===========
+
+The following JSON Schema can be used to validate the contents of ``direct_url.json``:
+
+.. code-block::
+
+     {
+       "$schema": "https://json-schema.org/draft/2019-09/schema",
+       "title": "Direct URL Data",
+       "description": "Data structure that can represent URLs to python projects and distribution artifacts such as VCS source trees, local source trees, source distributions and wheels.",
+       "definitions": {
+         "URL": {
+           "type": "string",
+           "format": "uri"
+         },
+         "DirInfo": {
+           "type": "object",
+           "properties": {
+             "editable": {
+               "type": ["boolean", "null"]
+             }
+           }
+         },
+         "VCSInfo": {
+           "type": "object",
+           "properties": {
+             "vcs": {
+               "type": "string",
+               "enum": [
+                 "git",
+                 "hg",
+                 "bzr",
+                 "svn"
+               ]
+             },
+             "requested_revision": {
+               "type": "string"
+             },
+             "commit_id": {
+               "type": "string"
+             },
+             "resolved_revision": {
+               "type": "string"
+             }
+           },
+           "required": [
+             "vcs",
+             "commit_id"
+           ]
+         },
+         "ArchiveInfo": {
+           "type": "object",
+           "properties": {
+             "hash": {
+               "type": "string",
+               "pattern": "^\\w+=[a-f0-9]+$",
+               "deprecated": true
+             },
+             "hashes": {
+               "type": "object",
+               "patternProperties": {
+                 "^[a-f0-9]+$": {
+                   "type": "string"
+                 }
+               }
+             }
+           }
+         }
+       },
+       "allOf": [
+         {
+           "type": "object",
+           "properties": {
+             "url": {
+               "$ref": "#/definitions/URL"
+             }
+           },
+           "required": [
+             "url"
+           ]
+         },
+         {
+           "anyOf": [
+             {
+               "type": "object",
+               "properties": {
+                 "dir_info": {
+                   "$ref": "#/definitions/DirInfo"
+                 }
+               },
+               "required": [
+                 "dir_info"
+               ]
+             },
+             {
+               "type": "object",
+               "properties": {
+                 "vcs_info": {
+                   "$ref": "#/definitions/VCSInfo"
+                 }
+               },
+               "required": [
+                 "vcs_info"
+               ]
+             },
+             {
+               "type": "object",
+               "properties": {
+                 "archive_info": {
+                   "$ref": "#/definitions/ArchiveInfo"
+                 }
+               },
+               "required": [
+                 "archive_info"
+               ]
+             }
+           ]
+         }
+       ]
+     }
+
 Examples
 ========
 

From 3e65739d8078603eec17bc2a38a1bab1a74ccb37 Mon Sep 17 00:00:00 2001
From: Carol Willing 
Date: Thu, 29 Feb 2024 10:26:30 -0800
Subject: [PATCH 0662/1072] Remove example for a different failing link as pip
 has removed setup.py

---
 source/guides/single-sourcing-package-version.rst | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/source/guides/single-sourcing-package-version.rst b/source/guides/single-sourcing-package-version.rst
index e487e41e1..e300fa8f7 100644
--- a/source/guides/single-sourcing-package-version.rst
+++ b/source/guides/single-sourcing-package-version.rst
@@ -9,8 +9,7 @@ Single-sourcing the package version
 There are many techniques to maintain a single source of truth for the version
 number of your project:
 
-#.  Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py
-    `_)::
+#.  Read the file in :file:`setup.py` and get the version. Example::
 
         import codecs
         import os.path

From 527fadf228812a4ec3780a69134b4e30d90d3e3f Mon Sep 17 00:00:00 2001
From: Sviatoslav Sydorenko 
Date: Thu, 29 Feb 2024 19:42:31 +0100
Subject: [PATCH 0663/1072] Point pip's `setup.py` link to its latest version

This file no longer exists on the `main` branch as of
https://github.com/pypa/pip/pull/12537 /
https://github.com/pypa/pip/commit/0ad4c94b.
---
 source/guides/single-sourcing-package-version.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/source/guides/single-sourcing-package-version.rst b/source/guides/single-sourcing-package-version.rst
index e300fa8f7..5c8af21e0 100644
--- a/source/guides/single-sourcing-package-version.rst
+++ b/source/guides/single-sourcing-package-version.rst
@@ -9,7 +9,8 @@ Single-sourcing the package version
 There are many techniques to maintain a single source of truth for the version
 number of your project:
 
-#.  Read the file in :file:`setup.py` and get the version. Example::
+#.  Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py
+    `_)::
 
         import codecs
         import os.path

From 421bb9157a7cc3050f1e245f2465ba8eef6e617b Mon Sep 17 00:00:00 2001
From: konstin 
Date: Wed, 21 Feb 2024 10:16:16 +0100
Subject: [PATCH 0664/1072] RFC: Clarify that the direct_url.json url field
 must be a spec-compliant url

Clarify that the `url` field in `direct_url.json` must be a valid url.
---
 source/specifications/direct-url-data-structure.rst | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index da4d959e4..01687ded2 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -10,11 +10,6 @@ This document specifies a JSON-serializable abstract data structure that can rep
 URLs to python projects and distribution artifacts such as VCS source trees, local
 source trees, source distributions and wheels.
 
-The representation of the components of this data structure as a :rfc:`1738` URL
-is not formally specified at time of writing. A common representation is the pip URL
-format. Other examples are provided in the :ref:`Version specifier specification `.
-
-
 Specification
 =============
 
@@ -22,8 +17,9 @@ The Direct URL Data Structure MUST be a dictionary, serializable to JSON accordi
 :rfc:`8259`.
 
 It MUST contain at least two fields. The first one is ``url``, with
-type ``string``. Depending on what ``url`` refers to, the second field MUST be
-one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if
+type ``string``. Its content must be a valid URL according to the
+`WHATWG URL Standard `_. Depending on what ``url`` refers to,
+the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if
 ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url``  is a
 local directory). These info fields have a (possibly empty) subdictionary as
 value, with the possible keys defined below.
@@ -396,3 +392,4 @@ History
 
 
 .. _archive-info-hashes: https://discuss.python.org/t/22299
+.. _whatwg-url-standard: https://url.spec.whatwg.org/

From 9e976ee1e0867453dfc667df55787c3d03220536 Mon Sep 17 00:00:00 2001
From: konstin 
Date: Wed, 21 Feb 2024 10:56:12 +0100
Subject: [PATCH 0665/1072] Clarify merging direct_url.json into urls paragraph

---
 source/specifications/direct-url-data-structure.rst | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index 01687ded2..26dc39eaa 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -10,6 +10,11 @@ This document specifies a JSON-serializable abstract data structure that can rep
 URLs to python projects and distribution artifacts such as VCS source trees, local
 source trees, source distributions and wheels.
 
+At time of writing, it is not formally specified how to merge the parts of this
+file into single URL that can be passed to tools. A common representation is the
+pip URL format, other examples are provided in the
+:ref:`Version specifier specification `.
+
 Specification
 =============
 

From a8d19777dbe28ce08192e30847485240f8ce6004 Mon Sep 17 00:00:00 2001
From: konstin 
Date: Wed, 21 Feb 2024 19:36:51 +0100
Subject: [PATCH 0666/1072] Link to pip docs

---
 source/specifications/direct-url-data-structure.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index 26dc39eaa..d9972dc37 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -12,7 +12,7 @@ source trees, source distributions and wheels.
 
 At time of writing, it is not formally specified how to merge the parts of this
 file into single URL that can be passed to tools. A common representation is the
-pip URL format, other examples are provided in the
+pip URL format (`VCS Support `_), other examples are provided in the
 :ref:`Version specifier specification `.
 
 Specification
@@ -397,4 +397,5 @@ History
 
 
 .. _archive-info-hashes: https://discuss.python.org/t/22299
+.. _pip-vcs-support: https://pip.pypa.io/en/stable/topics/vcs-support/
 .. _whatwg-url-standard: https://url.spec.whatwg.org/

From aad6bf5921e355deeb0f6bf3e8466f077581a35b Mon Sep 17 00:00:00 2001
From: konstin 
Date: Wed, 21 Feb 2024 19:36:59 +0100
Subject: [PATCH 0667/1072] New paragraph

---
 source/specifications/direct-url-data-structure.rst | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index d9972dc37..a14ebba98 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -23,8 +23,10 @@ The Direct URL Data Structure MUST be a dictionary, serializable to JSON accordi
 
 It MUST contain at least two fields. The first one is ``url``, with
 type ``string``. Its content must be a valid URL according to the
-`WHATWG URL Standard `_. Depending on what ``url`` refers to,
-the second field MUST be one of ``vcs_info`` (if ``url`` is a VCS reference), ``archive_info`` (if
+`WHATWG URL Standard `_.
+
+Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info``
+(if ``url`` is a VCS reference), ``archive_info`` (if
 ``url`` is a source archives or a wheel), or ``dir_info`` (if ``url``  is a
 local directory). These info fields have a (possibly empty) subdictionary as
 value, with the possible keys defined below.

From bba849252c4bed9e7a615375eece739496852d02 Mon Sep 17 00:00:00 2001
From: konsti 
Date: Thu, 22 Feb 2024 10:50:50 +0100
Subject: [PATCH 0668/1072] Update
 source/specifications/direct-url-data-structure.rst
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Stéphane Bidoul 
---
 source/specifications/direct-url-data-structure.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index a14ebba98..9afe5acd5 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -11,7 +11,7 @@ URLs to python projects and distribution artifacts such as VCS source trees, loc
 source trees, source distributions and wheels.
 
 At time of writing, it is not formally specified how to merge the parts of this
-file into single URL that can be passed to tools. A common representation is the
+data structure into single URL that can be passed to tools. A common representation is the
 pip URL format (`VCS Support `_), other examples are provided in the
 :ref:`Version specifier specification `.
 

From 66c29296dfe8a0276b05f733eb0bd0d2d8c3e8c4 Mon Sep 17 00:00:00 2001
From: konsti 
Date: Sat, 2 Mar 2024 16:18:34 +0100
Subject: [PATCH 0669/1072] Update
 source/specifications/direct-url-data-structure.rst

Co-authored-by: chrysle 
---
 source/specifications/direct-url-data-structure.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index 9afe5acd5..d73eea4ae 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -11,7 +11,7 @@ URLs to python projects and distribution artifacts such as VCS source trees, loc
 source trees, source distributions and wheels.
 
 At time of writing, it is not formally specified how to merge the parts of this
-data structure into single URL that can be passed to tools. A common representation is the
+data structure into a single URL that can be passed to tools. A common representation is the
 pip URL format (`VCS Support `_), other examples are provided in the
 :ref:`Version specifier specification `.
 

From 0f441406f49b28bd8eca6c6258ab743b75f0d342 Mon Sep 17 00:00:00 2001
From: konsti 
Date: Sat, 2 Mar 2024 16:18:41 +0100
Subject: [PATCH 0670/1072] typo

Co-authored-by: chrysle 
---
 source/specifications/direct-url-data-structure.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index d73eea4ae..2dbcdae91 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -27,7 +27,7 @@ type ``string``. Its content must be a valid URL according to the
 
 Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info``
 (if ``url`` is a VCS reference), ``archive_info`` (if
-``url`` is a source archives or a wheel), or ``dir_info`` (if ``url``  is a
+``url`` is a source archive or a wheel), or ``dir_info`` (if ``url``  is a
 local directory). These info fields have a (possibly empty) subdictionary as
 value, with the possible keys defined below.
 

From 35dbd1efa5b46fba1971bcdf01f4ef24351acf2b Mon Sep 17 00:00:00 2001
From: Guen Prawiroatmodjo 
Date: Wed, 6 Mar 2024 12:33:08 -0800
Subject: [PATCH 0671/1072] Update
 publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst

---
 ...tribution-releases-using-github-actions-ci-cd-workflows.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
index 99ac3a9e2..10c45b219 100644
--- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
+++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
@@ -169,7 +169,8 @@ Firstly, it uses the `sigstore/gh-action-sigstore-python GitHub Action`_
 to sign the distribution packages. In the next step, an empty GitHub Release
 from the current tag is created using the ``gh`` CLI. Note this step can be further
 customised. See the `gh release documentation `_
-as a reference.
+as a reference. To enable writing to GitHub Release you may need to manage your ``GITHUB_TOKEN``
+permissions, see the `GitHub documentation `_.
 
 Finally, the signed distributions are uploaded to the GitHub Release.
 

From fa39abdfb542f8f19d40a35476d0b5d66c600071 Mon Sep 17 00:00:00 2001
From: Guen Prawiroatmodjo 
Date: Wed, 6 Mar 2024 15:00:51 -0800
Subject: [PATCH 0672/1072] Add GITHUB_TOKEN instructions to tip admonition

---
 ...ution-releases-using-github-actions-ci-cd-workflows.rst | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
index 10c45b219..1f3d66ac8 100644
--- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
+++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
@@ -169,8 +169,11 @@ Firstly, it uses the `sigstore/gh-action-sigstore-python GitHub Action`_
 to sign the distribution packages. In the next step, an empty GitHub Release
 from the current tag is created using the ``gh`` CLI. Note this step can be further
 customised. See the `gh release documentation `_
-as a reference. To enable writing to GitHub Release you may need to manage your ``GITHUB_TOKEN``
-permissions, see the `GitHub documentation `_.
+as a reference.
+
+.. tip::
+
+   You may need to manage your ``GITHUB_TOKEN`` permissions to enable creating the GitHub Release. See the `GitHub documentation `_ for instructions. Specifically, the token needs `content.write` permissions.
 
 Finally, the signed distributions are uploaded to the GitHub Release.
 

From ac0a64aabb95135525284a5f90b62055c4a74c2b Mon Sep 17 00:00:00 2001
From: Guen Prawiroatmodjo 
Date: Wed, 6 Mar 2024 15:05:14 -0800
Subject: [PATCH 0673/1072] rst ``code`` is two backticks

---
 ...stribution-releases-using-github-actions-ci-cd-workflows.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
index 1f3d66ac8..6456dd182 100644
--- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
+++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
@@ -173,7 +173,7 @@ as a reference.
 
 .. tip::
 
-   You may need to manage your ``GITHUB_TOKEN`` permissions to enable creating the GitHub Release. See the `GitHub documentation `_ for instructions. Specifically, the token needs `content.write` permissions.
+   You may need to manage your ``GITHUB_TOKEN`` permissions to enable creating the GitHub Release. See the `GitHub documentation `_ for instructions. Specifically, the token needs ``content.write`` permissions.
 
 Finally, the signed distributions are uploaded to the GitHub Release.
 

From c766f090ee923b739fb0b29d004f90e418268f53 Mon Sep 17 00:00:00 2001
From: Guen Prawiroatmodjo 
Date: Wed, 6 Mar 2024 15:07:38 -0800
Subject: [PATCH 0674/1072] Fix typo: it should be ``contents: write``

---
 ...stribution-releases-using-github-actions-ci-cd-workflows.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
index 6456dd182..006b39f8b 100644
--- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
+++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
@@ -173,7 +173,7 @@ as a reference.
 
 .. tip::
 
-   You may need to manage your ``GITHUB_TOKEN`` permissions to enable creating the GitHub Release. See the `GitHub documentation `_ for instructions. Specifically, the token needs ``content.write`` permissions.
+   You may need to manage your ``GITHUB_TOKEN`` permissions to enable creating the GitHub Release. See the `GitHub documentation `_ for instructions. Specifically, the token needs ``contents: write`` permissions.
 
 Finally, the signed distributions are uploaded to the GitHub Release.
 

From 643b211ea2795937d208fdb055b203a8c0e1aa1e Mon Sep 17 00:00:00 2001
From: Guen Prawiroatmodjo 
Date: Wed, 6 Mar 2024 22:48:27 -0800
Subject: [PATCH 0675/1072] Apply suggestions from code review
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 ...bution-releases-using-github-actions-ci-cd-workflows.rst | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
index 006b39f8b..049fba15c 100644
--- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
+++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
@@ -173,7 +173,11 @@ as a reference.
 
 .. tip::
 
-   You may need to manage your ``GITHUB_TOKEN`` permissions to enable creating the GitHub Release. See the `GitHub documentation `_ for instructions. Specifically, the token needs ``contents: write`` permissions.
+   You may need to manage your ``GITHUB_TOKEN`` permissions to
+   enable creating the GitHub Release. See the `GitHub
+   documentation `_
+   for instructions. Specifically, the token needs the
+   ``contents: write`` permission.
 
 Finally, the signed distributions are uploaded to the GitHub Release.
 

From d68a810030f1daffad6387142f1cf01a4a5a112b Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 19 Feb 2024 19:35:39 +0000
Subject: [PATCH 0676/1072] [pre-commit.ci] pre-commit autoupdate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

updates:
- [github.com/astral-sh/ruff-pre-commit: v0.2.1 → v0.2.2](https://github.com/astral-sh/ruff-pre-commit/compare/v0.2.1...v0.2.2)
---
 .pre-commit-config.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index 3c24cfc46..af1c55010 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -34,7 +34,7 @@ repos:
   - id: rst-inline-touching-normal
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.2.1
+  rev: v0.2.2
   hooks:
     - id: ruff
     - id: ruff-format

From a0bdc2f1eb5e9dd561c49714e5103947464cbb52 Mon Sep 17 00:00:00 2001
From: Brad Campbell 
Date: Tue, 12 Mar 2024 14:43:37 -0400
Subject: [PATCH 0677/1072] guides: stand-alone-tools: update in 2024

The `cowsay` package now requires a `-t` argument. I also noticed the output from pipx has changed a bit over time, so I updated the output to match the current format.
---
 ...talling-stand-alone-command-line-tools.rst | 23 +++++++++++--------
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/source/guides/installing-stand-alone-command-line-tools.rst b/source/guides/installing-stand-alone-command-line-tools.rst
index ecc44a487..8578a3b28 100644
--- a/source/guides/installing-stand-alone-command-line-tools.rst
+++ b/source/guides/installing-stand-alone-command-line-tools.rst
@@ -54,11 +54,11 @@ For example:
 .. code-block:: console
 
   $ pipx install cowsay
-    installed package cowsay 2.0, Python 3.6.2+
-    These binaries are now globally available
+    installed package cowsay 6.1, installed using Python 3.12.2
+    These apps are now globally available
       - cowsay
   done! ✨ 🌟 ✨
-  $ cowsay moo
+  $ cowsay -t moo
     ___
   < moo >
     ===
@@ -77,18 +77,21 @@ available, use ``pipx list``:
 .. code-block:: console
 
   $ pipx list
-  venvs are in /Users/user/.local/pipx/venvs
-  symlinks to binaries are in /Users/user/.local/bin
-     package black 18.9b0, Python 3.6.2+
+  venvs are in /Users/user/Library/Application Support/pipx/venvs
+  apps are exposed on your $PATH at /Users/user/.local/bin
+  manual pages are exposed at /Users/user/.local/share/man
+     package black 24.2.0, installed using Python 3.12.2
       - black
       - blackd
-     package cowsay 2.0, Python 3.6.2+
+     package cowsay 6.1, installed using Python 3.12.2
       - cowsay
-     package mypy 0.660, Python 3.6.2+
+     package mypy 1.9.0, installed using Python 3.12.2
       - dmypy
       - mypy
+      - mypyc
       - stubgen
-     package nox 2018.10.17, Python 3.6.2+
+      - stubtest
+     package nox 2024.3.2, installed using Python 3.12.2
       - nox
       - tox-to-nox
 
@@ -120,7 +123,7 @@ in a temporary, ephemeral environment. For example:
 
 .. code-block:: bash
 
-  pipx run cowsay moooo
+  pipx run cowsay -t moooo
 
 To see the full list of commands pipx offers, run:
 

From 2572190c9841373b8763af9948262862ae1a090a Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Tue, 12 Mar 2024 22:23:06 +0000
Subject: [PATCH 0678/1072] [pre-commit.ci] pre-commit autoupdate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

updates:
- [github.com/astral-sh/ruff-pre-commit: v0.2.2 → v0.3.2](https://github.com/astral-sh/ruff-pre-commit/compare/v0.2.2...v0.3.2)
---
 .pre-commit-config.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index af1c55010..7e6d4359a 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -34,7 +34,7 @@ repos:
   - id: rst-inline-touching-normal
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.2.2
+  rev: v0.3.2
   hooks:
     - id: ruff
     - id: ruff-format

From 0b4a494425ba208a07cb2f8acfd3f0ea107d20d0 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 8 Apr 2024 19:55:56 +0000
Subject: [PATCH 0679/1072] [pre-commit.ci] pre-commit autoupdate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

updates:
- [github.com/pre-commit/pre-commit-hooks: v4.5.0 → v4.6.0](https://github.com/pre-commit/pre-commit-hooks/compare/v4.5.0...v4.6.0)
- [github.com/astral-sh/ruff-pre-commit: v0.3.2 → v0.3.5](https://github.com/astral-sh/ruff-pre-commit/compare/v0.3.2...v0.3.5)
---
 .pre-commit-config.yaml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index 7e6d4359a..d5b2fe281 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -1,6 +1,6 @@
 repos:
 - repo: https://github.com/pre-commit/pre-commit-hooks
-  rev: v4.5.0
+  rev: v4.6.0
   hooks:
   - id: check-added-large-files
   - id: check-case-conflict
@@ -34,7 +34,7 @@ repos:
   - id: rst-inline-touching-normal
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.3.2
+  rev: v0.3.5
   hooks:
     - id: ruff
     - id: ruff-format

From 88449eb3c36f9a834b041fd08cf0052dccaf9313 Mon Sep 17 00:00:00 2001
From: Clemens Brunner 
Date: Thu, 11 Apr 2024 10:32:48 +0200
Subject: [PATCH 0680/1072] Update packages installed in venv

---
 source/tutorials/installing-packages.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst
index 0e80642ae..817148d06 100644
--- a/source/tutorials/installing-packages.rst
+++ b/source/tutorials/installing-packages.rst
@@ -224,8 +224,8 @@ environments.
 Currently, there are two common tools for creating Python virtual environments:
 
 * :doc:`venv ` is available by default in Python 3.3 and later, and installs
-  :ref:`pip` and :ref:`setuptools` into created virtual environments in
-  Python 3.4 and later.
+  :ref:`pip` into created virtual environments in Python 3.4 and later
+  (Python versions prior to 3.12 also installed :ref:`setuptools`).
 * :ref:`virtualenv` needs to be installed separately, but supports Python 2.7+
   and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are
   always installed into created virtual environments by default (regardless of

From c5a697f68873a904373353173696715b67db9e1d Mon Sep 17 00:00:00 2001
From: Ofek Lev 
Date: Fri, 12 Apr 2024 11:23:07 -0400
Subject: [PATCH 0681/1072] Update language for the direct URL data structure

---
 source/specifications/direct-url-data-structure.rst | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index 2dbcdae91..231198ee8 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -59,7 +59,9 @@ as a dictionary with the following keys:
   so an installer can hand it off without transformation to a
   checkout/download command of the VCS.
 - A ``requested_revision`` key (type ``string``) MAY be present naming a
-  branch/tag/ref/commit/revision/etc (in a format compatible with the VCS).
+  branch/tag/ref/commit/revision/etc (in a format compatible with the VCS). This field
+  MUST match the revision requested by the user and MUST NOT exist when the user did
+  not select a specific revision.
 - A ``commit_id`` key (type ``string``) MUST be present, containing the
   exact commit/revision number that was/is to be installed.
   If the VCS supports commit-hash

From 547a95ab3e34416441d414ee3cca8111737e0682 Mon Sep 17 00:00:00 2001
From: Henry Schreiner 
Date: Mon, 15 Apr 2024 23:29:19 -0400
Subject: [PATCH 0682/1072] pyproject.toml: specify description is one line

---
 source/specifications/pyproject-toml.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 1580b3772..efa562a73 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -180,7 +180,8 @@ Users SHOULD prefer to specify already-normalized versions.
 - Corresponding :ref:`core metadata ` field:
   :ref:`Summary `
 
-The summary description of the project.
+The summary description of the project in one line. Tools MAY error
+if this includes multiple lines.
 
 
 ``readme``

From cb6808acf09642401e5a06b3f56516b2a05d3fa2 Mon Sep 17 00:00:00 2001
From: sam rodriguez 
Date: Tue, 30 Apr 2024 12:17:34 +0200
Subject: [PATCH 0683/1072] Update glossary.rst

fix seeming typo and add link to the correct term
---
 source/glossary.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/glossary.rst b/source/glossary.rst
index 218c21168..bff0b0426 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -16,7 +16,7 @@ Glossary
 
         A library that takes a source tree or
         :term:`source distribution `
-        and builds a source distribution or :term:`wheel ` from it.
+        and builds a :term:`built distribution ` or :term:`wheel ` from it.
         The build is delegated to the backend by a
         :term:`frontend `.
         All backends offer a standardized interface.

From 05f231be5237e616cc861312c33974a318e11491 Mon Sep 17 00:00:00 2001
From: sam rodriguez 
Date: Thu, 2 May 2024 12:26:10 +0200
Subject: [PATCH 0684/1072] Clearer phrasing

---
 source/glossary.rst | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/source/glossary.rst b/source/glossary.rst
index bff0b0426..297398255 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -14,9 +14,8 @@ Glossary
 
     Build Backend
 
-        A library that takes a source tree or
-        :term:`source distribution `
-        and builds a :term:`built distribution ` or :term:`wheel ` from it.
+        A library that takes a source tree
+        and builds a :term:`source distribution ` or :term:`built distribution ` from it.
         The build is delegated to the backend by a
         :term:`frontend `.
         All backends offer a standardized interface.

From d8f425f264409951ac037b2e0500624249c6f71c Mon Sep 17 00:00:00 2001
From: wyattscarpenter 
Date: Fri, 3 May 2024 00:02:42 -0400
Subject: [PATCH 0685/1072] Update packaging-projects.rst: rephrase first
 explanation of __init.py__

---
 source/tutorials/packaging-projects.rst | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst
index 761b2748f..095abd19f 100644
--- a/source/tutorials/packaging-projects.rst
+++ b/source/tutorials/packaging-projects.rst
@@ -54,8 +54,10 @@ Create the following file structure locally:
 The directory containing the Python files should match the project name. This
 simplifies the configuration and is more obvious to users who install the package.
 
-:file:`__init__.py` is recommended to import the directory as a regular package,
-even if as is our case for this tutorial that file is empty [#namespace-packages]_.
+Creating the file :file:`__init__.py` is recommended because the existence of a
+:file:`__init__.py` file allows users to import the directory as a regular package,
+even if (as is the case for this tutorial) :file:`__init__.py` is empty.
+[#namespace-packages]_
 
 :file:`example.py` is an example of a module within the package that could
 contain the logic (functions, classes, constants, etc.) of your package.

From 9808d5d06c77d0a25b0c86433212116d34d8ae8f Mon Sep 17 00:00:00 2001
From: wyattscarpenter 
Date: Fri, 3 May 2024 00:06:26 -0400
Subject: [PATCH 0686/1072] Update packaging-projects.rst: you know, I reckon
 people say "a*n* __init__.py file"

---
 source/tutorials/packaging-projects.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst
index 095abd19f..4c205e28f 100644
--- a/source/tutorials/packaging-projects.rst
+++ b/source/tutorials/packaging-projects.rst
@@ -54,9 +54,9 @@ Create the following file structure locally:
 The directory containing the Python files should match the project name. This
 simplifies the configuration and is more obvious to users who install the package.
 
-Creating the file :file:`__init__.py` is recommended because the existence of a
+Creating the file :file:`__init__.py` is recommended because the existence of an
 :file:`__init__.py` file allows users to import the directory as a regular package,
-even if (as is the case for this tutorial) :file:`__init__.py` is empty.
+even if (as is the case in this tutorial) :file:`__init__.py` is empty.
 [#namespace-packages]_
 
 :file:`example.py` is an example of a module within the package that could

From 3f2c72d68e5aa4ab4785831531c590adf6d2006d Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Sun, 5 May 2024 13:43:45 -0400
Subject: [PATCH 0687/1072] publish-to-test-pypi: bump action versions

---
 .../github-actions-ci-cd-sample/publish-to-test-pypi.yml      | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
index 72a3eb7b2..3bd06cccc 100644
--- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
+++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
@@ -10,7 +10,7 @@ jobs:
     steps:
     - uses: actions/checkout@v4
     - name: Set up Python
-      uses: actions/setup-python@v4
+      uses: actions/setup-python@v5
       with:
         python-version: "3.x"
     - name: Install pypa/build
@@ -68,7 +68,7 @@ jobs:
         name: python-package-distributions
         path: dist/
     - name: Sign the dists with Sigstore
-      uses: sigstore/gh-action-sigstore-python@v1.2.3
+      uses: sigstore/gh-action-sigstore-python@v2.1.1
       with:
         inputs: >-
           ./dist/*.tar.gz

From 167ef2d7345c420e0b48602bdc3e3d3b682b31e7 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 6 May 2024 19:42:56 +0000
Subject: [PATCH 0688/1072] [pre-commit.ci] pre-commit autoupdate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

updates:
- [github.com/astral-sh/ruff-pre-commit: v0.3.5 → v0.4.3](https://github.com/astral-sh/ruff-pre-commit/compare/v0.3.5...v0.4.3)
---
 .pre-commit-config.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index d5b2fe281..b1cc54c6e 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -34,7 +34,7 @@ repos:
   - id: rst-inline-touching-normal
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.3.5
+  rev: v0.4.3
   hooks:
     - id: ruff
     - id: ruff-format

From 9ddfba16ad4954e17efdbf2e55a63f66f12c6010 Mon Sep 17 00:00:00 2001
From: Karolina Surma 
Date: Mon, 6 May 2024 16:20:17 +0200
Subject: [PATCH 0689/1072] Add glossary definitions of packaging and metadata
 terms

The definitions were originally included in PEP 639, refining and
extending the existing glossary terms.
Having the unified vocabulary in place is essential to accurately
describe the complex Python packaging landscape.

Co-Authored-By: C.A.M. Gerlach 
---
 source/glossary.rst | 109 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 107 insertions(+), 2 deletions(-)

diff --git a/source/glossary.rst b/source/glossary.rst
index 218c21168..e2e7b6334 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -54,6 +54,39 @@ Glossary
         Python files). See :ref:`package-formats` for more information.
 
 
+    Built Metadata
+
+        The concrete form :term:`Core Metadata` takes
+        when included inside an installed :term:`Project` (``METADATA`` file)
+        or a :term:`Distribution Archive`
+        (``PKG-INFO`` in a
+        :term:`Sdist `
+        and ``METADATA`` in a :term:`Wheel`).
+
+
+    Core Metadata
+
+        The :ref:`specification `
+        and the set of :term:`Core Metadata Field`\s it defines
+        that describe key static attributes of
+        a :term:`Distribution Package` or :term:`Installed Project`.
+
+
+    Core Metadata Field
+
+        A single key-value pair
+        (or sequence of such with the same name, for multiple-use fields)
+        defined in the :term:`Core Metadata` spec
+        and stored in the :term:`Built Metadata`.
+        Notably, distinct from a :term:`Pyproject Metadata Key`.
+
+
+    Distribution Archive
+
+        The physical distribution artifact (i.e. a file on disk)
+        for a :term:`Distribution Package`.
+
+
     Distribution Package
 
         A versioned archive file that contains Python :term:`packages ` is located.
+
+
+    Project Source Tree
+
+        The on-disk format of a :term:`Project` used for development,
+        containing its raw source code before being packaged
+        into a
+        :term:`Source Distribution `
+        or :term:`Built Distribution`.
+
+
+    Project Source Metadata
+
+        Metadata defined by the package author
+        in a :term:`Project`'s :term:`source tree `,
+        to be transformed into :term:`Core Metadata field`\s
+        in the :term:`Built Metadata`
+        by the project's build backend.
+        Can be written as :term:`Pyproject Metadata`,
+        or in a tool-specific format
+        (under the ``[tool]`` table in ``pyproject.toml``,
+        or in a tool's own configuration file).
+
+
     Pure Module
 
         A :term:`Module` written in Python and contained in a single ``.py`` file (and
         possibly associated ``.pyc`` and/or ``.pyo`` files).
 
 
+    Pyproject Metadata
+
+        The :term:`Project Source Metadata` format
+        defined by the :ref:`declaring-project-metadata` specification
+        and originally introduced in :pep:`621`,
+        stored as :term:`Pyproject Metadata Key`\s
+        under the ``[project]`` table of a :term:`pyproject.toml` file.
+        Notably, *not* a tool-specific source metadata format
+        under the ``[tool]`` table in ``pyproject.toml``.
+
+
+    Pyproject Metadata Key
+
+        A top-level TOML key in the ``[project]`` table in ``pyproject.toml``;
+        part of the :term:`Pyproject Metadata`.
+        Notably, distinct from a :term:`Core Metadata Field`.
+
+
+    Pyproject Metadata Subkey
+
+        A second-level TOML key under a table-valued
+        :term:`Pyproject Metadata Key`.
+
+
     Python Packaging Authority (PyPA)
 
         PyPA is a working group that maintains many of the relevant
@@ -236,7 +329,7 @@ Glossary
 
     Source Distribution (or "sdist")
 
-        A :term:`distribution ` format (usually generated
+        A :term:`distribution ` format (usually generated
         using ``python -m build --sdist``) that provides metadata and the
         essential source files needed for installing by a tool like :ref:`pip`,
         or for generating a :term:`Built Distribution`. See :ref:`package-formats`
@@ -264,10 +357,22 @@ Glossary
         wide. For more information, see the section on :ref:`Creating and using
         Virtual Environments`.
 
+
+    Wheel Format
     Wheel
 
-        The standard :term:`Built Distribution` format.
+        The standard :term:`Built Distribution` format
+        originally introduced in :pep:`427`
+        and defined by the :ref:`binary-distribution-format` specification.
         See :ref:`package-formats` for more information.
+        Not to be confused with its reference implementation,
+        the :term:`Wheel Project`.
+
+
+    Wheel Project
+
+        The PyPA reference implementation of the :term:`Wheel Format`.
+
 
     Working Set
 

From 25426b36dd702c43e4c6f78b75cc42d3c740e6ec Mon Sep 17 00:00:00 2001
From: Karolina Surma <33810531+befeleme@users.noreply.github.com>
Date: Tue, 7 May 2024 09:57:20 +0200
Subject: [PATCH 0690/1072] Apply suggestions from code review

Co-authored-by: chrysle <96722107+chrysle@users.noreply.github.com>
---
 source/glossary.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/glossary.rst b/source/glossary.rst
index e2e7b6334..f6675fef9 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -211,7 +211,7 @@ Glossary
         in a :term:`Project`'s :term:`source tree `,
         to be transformed into :term:`Core Metadata field`\s
         in the :term:`Built Metadata`
-        by the project's build backend.
+        by the project's :term:`build backend `.
         Can be written as :term:`Pyproject Metadata`,
         or in a tool-specific format
         (under the ``[tool]`` table in ``pyproject.toml``,
@@ -371,7 +371,7 @@ Glossary
 
     Wheel Project
 
-        The PyPA reference implementation of the :term:`Wheel Format`.
+        The PyPA reference implementation of the :term:`Wheel Format`; see :ref:`wheel`.
 
 
     Working Set

From 706b0f157bab3935d53ec9a7700985e09c2563d8 Mon Sep 17 00:00:00 2001
From: Ofek Lev 
Date: Wed, 8 May 2024 09:39:04 -0400
Subject: [PATCH 0691/1072] Add reference for inline script metadata spec

---
 source/specifications/inline-script-metadata.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/source/specifications/inline-script-metadata.rst b/source/specifications/inline-script-metadata.rst
index 352614e81..f40b9ac4a 100644
--- a/source/specifications/inline-script-metadata.rst
+++ b/source/specifications/inline-script-metadata.rst
@@ -1,3 +1,5 @@
+.. _inline-script-metadata:
+
 ======================
 Inline script metadata
 ======================

From abf27b61cd8ccad51a9c4f04609a5573d54c1f35 Mon Sep 17 00:00:00 2001
From: sam rodriguez 
Date: Mon, 13 May 2024 04:40:41 +0200
Subject: [PATCH 0692/1072] Update source/glossary.rst

Co-authored-by: chrysle <96722107+chrysle@users.noreply.github.com>
---
 source/glossary.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/source/glossary.rst b/source/glossary.rst
index 297398255..9d53e40eb 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -15,7 +15,8 @@ Glossary
     Build Backend
 
         A library that takes a source tree
-        and builds a :term:`source distribution ` or :term:`built distribution ` from it.
+        and builds a :term:`source distribution ` or 
+        :term:`built distribution ` from it.
         The build is delegated to the backend by a
         :term:`frontend `.
         All backends offer a standardized interface.

From 627ed17bb001aeda664ee6e82493703b99706b7b Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 13 May 2024 02:40:46 +0000
Subject: [PATCH 0693/1072] [pre-commit.ci] auto fixes from pre-commit.com
 hooks

for more information, see https://pre-commit.ci
---
 source/glossary.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/glossary.rst b/source/glossary.rst
index 9d53e40eb..58b096f46 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -15,7 +15,7 @@ Glossary
     Build Backend
 
         A library that takes a source tree
-        and builds a :term:`source distribution ` or 
+        and builds a :term:`source distribution ` or
         :term:`built distribution ` from it.
         The build is delegated to the backend by a
         :term:`frontend `.

From 01a03ce0c4ddb6a503c808bf4202f763131adba7 Mon Sep 17 00:00:00 2001
From: Geoffrey Thomas 
Date: Wed, 22 May 2024 16:40:15 -0400
Subject: [PATCH 0694/1072] binary-distribution-format: Update a mention of
 distutils

---
 source/specifications/binary-distribution-format.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst
index e2f65411b..211019f85 100644
--- a/source/specifications/binary-distribution-format.rst
+++ b/source/specifications/binary-distribution-format.rst
@@ -43,8 +43,8 @@ Wheel installation notionally consists of two phases:
      destination path. Each subdirectory of ``distribution-1.0.data/``
      is a key into a dict of destination directories, such as
      ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``.
-     The initially supported paths are taken from
-     ``distutils.command.install``.
+     These subdirectories are `installation paths defined by sysconfig
+     `_.
   c. If applicable, update scripts starting with ``#!python`` to point
      to the correct interpreter.
   d. Update ``distribution-1.0.dist-info/RECORD`` with the installed

From 5901ab5d4489328e1be14e62b2b0f3bda17860ae Mon Sep 17 00:00:00 2001
From: Victor Blomqvist 
Date: Sun, 26 May 2024 21:16:25 +0200
Subject: [PATCH 0695/1072] Create considerations_for_binary_wheels.rst

---
 .../discussions/considerations_for_binary_wheels.rst | 12 ++++++++++++
 1 file changed, 12 insertions(+)
 create mode 100644 source/discussions/considerations_for_binary_wheels.rst

diff --git a/source/discussions/considerations_for_binary_wheels.rst b/source/discussions/considerations_for_binary_wheels.rst
new file mode 100644
index 000000000..f5e1e20f8
--- /dev/null
+++ b/source/discussions/considerations_for_binary_wheels.rst
@@ -0,0 +1,12 @@
+================================
+Considerations for binary wheels
+================================
+
+Python packages with native code have a set of unique challenges not present 
+in pure packages. The more complex the native code, the more complex the 
+packaging can become. Issues arrise around topics such as non-Python compiled 
+dependencies ("native dependencies"), the importance of the ABI (Application 
+Binary Interface) of native code, dependency on SIMD code and cross 
+compilation. In depth dicussion of these and many more topics and issues around
+ native packaging is available at 
+ `pypackaging-native`.

From 413893d0c1af1e33707232d9f0b48e29b421bac4 Mon Sep 17 00:00:00 2001
From: Victor Blomqvist 
Date: Sun, 26 May 2024 21:17:47 +0200
Subject: [PATCH 0696/1072] And binary wheel discussion to index

---
 source/discussions/index.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/source/discussions/index.rst b/source/discussions/index.rst
index d262bcff2..02ceba602 100644
--- a/source/discussions/index.rst
+++ b/source/discussions/index.rst
@@ -16,3 +16,4 @@ specific topic. If you're just trying to get stuff done, see
    package-formats
    src-layout-vs-flat-layout
    setup-py-deprecated
+   considerations_for_binary_wheels

From a548da992ffd394699873f9a9359dc22df61b9ab Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Sun, 26 May 2024 19:19:46 +0000
Subject: [PATCH 0697/1072] [pre-commit.ci] auto fixes from pre-commit.com
 hooks

for more information, see https://pre-commit.ci
---
 .../discussions/considerations_for_binary_wheels.rst | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/source/discussions/considerations_for_binary_wheels.rst b/source/discussions/considerations_for_binary_wheels.rst
index f5e1e20f8..861e7794e 100644
--- a/source/discussions/considerations_for_binary_wheels.rst
+++ b/source/discussions/considerations_for_binary_wheels.rst
@@ -2,11 +2,11 @@
 Considerations for binary wheels
 ================================
 
-Python packages with native code have a set of unique challenges not present 
-in pure packages. The more complex the native code, the more complex the 
-packaging can become. Issues arrise around topics such as non-Python compiled 
-dependencies ("native dependencies"), the importance of the ABI (Application 
-Binary Interface) of native code, dependency on SIMD code and cross 
+Python packages with native code have a set of unique challenges not present
+in pure packages. The more complex the native code, the more complex the
+packaging can become. Issues arrise around topics such as non-Python compiled
+dependencies ("native dependencies"), the importance of the ABI (Application
+Binary Interface) of native code, dependency on SIMD code and cross
 compilation. In depth dicussion of these and many more topics and issues around
- native packaging is available at 
+ native packaging is available at
  `pypackaging-native`.

From 380b8d19be61104df65dac7c547d180ab056ef58 Mon Sep 17 00:00:00 2001
From: Victor Blomqvist 
Date: Sun, 26 May 2024 21:27:21 +0200
Subject: [PATCH 0698/1072] Fix link in considerations_for_binary_wheels.rst

---
 source/discussions/considerations_for_binary_wheels.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/considerations_for_binary_wheels.rst b/source/discussions/considerations_for_binary_wheels.rst
index 861e7794e..4158de1ea 100644
--- a/source/discussions/considerations_for_binary_wheels.rst
+++ b/source/discussions/considerations_for_binary_wheels.rst
@@ -9,4 +9,4 @@ dependencies ("native dependencies"), the importance of the ABI (Application
 Binary Interface) of native code, dependency on SIMD code and cross
 compilation. In depth dicussion of these and many more topics and issues around
  native packaging is available at
- `pypackaging-native`.
+ `pypackaging-native`_.

From 203c79d9527f66ae90cb385929f537616c845223 Mon Sep 17 00:00:00 2001
From: Victor Blomqvist 
Date: Mon, 27 May 2024 21:29:08 +0200
Subject: [PATCH 0699/1072] Update
 source/discussions/considerations_for_binary_wheels.rst

Co-authored-by: chrysle <96722107+chrysle@users.noreply.github.com>
---
 source/discussions/considerations_for_binary_wheels.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/considerations_for_binary_wheels.rst b/source/discussions/considerations_for_binary_wheels.rst
index 4158de1ea..49d89e394 100644
--- a/source/discussions/considerations_for_binary_wheels.rst
+++ b/source/discussions/considerations_for_binary_wheels.rst
@@ -7,6 +7,6 @@ in pure packages. The more complex the native code, the more complex the
 packaging can become. Issues arrise around topics such as non-Python compiled
 dependencies ("native dependencies"), the importance of the ABI (Application
 Binary Interface) of native code, dependency on SIMD code and cross
-compilation. In depth dicussion of these and many more topics and issues around
+compilation. In depth discussion of these and many more topics and issues around
  native packaging is available at
  `pypackaging-native`_.

From 639ef8a21f07da1bfc4010da2247a3412bf25d04 Mon Sep 17 00:00:00 2001
From: Victor Blomqvist 
Date: Mon, 27 May 2024 21:29:20 +0200
Subject: [PATCH 0700/1072] Update
 source/discussions/considerations_for_binary_wheels.rst

Co-authored-by: chrysle <96722107+chrysle@users.noreply.github.com>
---
 source/discussions/considerations_for_binary_wheels.rst | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/source/discussions/considerations_for_binary_wheels.rst b/source/discussions/considerations_for_binary_wheels.rst
index 49d89e394..cfca706c7 100644
--- a/source/discussions/considerations_for_binary_wheels.rst
+++ b/source/discussions/considerations_for_binary_wheels.rst
@@ -8,5 +8,4 @@ packaging can become. Issues arrise around topics such as non-Python compiled
 dependencies ("native dependencies"), the importance of the ABI (Application
 Binary Interface) of native code, dependency on SIMD code and cross
 compilation. In depth discussion of these and many more topics and issues around
- native packaging is available at
- `pypackaging-native`_.
+native packaging is available at `pypackaging-native `_.

From 5a89e74e83b92cfaa455dbedf87869ed4641ada9 Mon Sep 17 00:00:00 2001
From: Victor Blomqvist 
Date: Sat, 1 Jun 2024 21:35:50 +0200
Subject: [PATCH 0701/1072] Added link to pypackaging-native on packaging
 binary extensions page

---
 .../discussions/considerations_for_binary_wheels.rst | 11 -----------
 source/discussions/index.rst                         |  1 -
 source/guides/packaging-binary-extensions.rst        | 12 ++++++++++++
 3 files changed, 12 insertions(+), 12 deletions(-)
 delete mode 100644 source/discussions/considerations_for_binary_wheels.rst

diff --git a/source/discussions/considerations_for_binary_wheels.rst b/source/discussions/considerations_for_binary_wheels.rst
deleted file mode 100644
index cfca706c7..000000000
--- a/source/discussions/considerations_for_binary_wheels.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-================================
-Considerations for binary wheels
-================================
-
-Python packages with native code have a set of unique challenges not present
-in pure packages. The more complex the native code, the more complex the
-packaging can become. Issues arrise around topics such as non-Python compiled
-dependencies ("native dependencies"), the importance of the ABI (Application
-Binary Interface) of native code, dependency on SIMD code and cross
-compilation. In depth discussion of these and many more topics and issues around
-native packaging is available at `pypackaging-native `_.
diff --git a/source/discussions/index.rst b/source/discussions/index.rst
index 02ceba602..d262bcff2 100644
--- a/source/discussions/index.rst
+++ b/source/discussions/index.rst
@@ -16,4 +16,3 @@ specific topic. If you're just trying to get stuff done, see
    package-formats
    src-layout-vs-flat-layout
    setup-py-deprecated
-   considerations_for_binary_wheels
diff --git a/source/guides/packaging-binary-extensions.rst b/source/guides/packaging-binary-extensions.rst
index 589ed89c8..b664d68a4 100644
--- a/source/guides/packaging-binary-extensions.rst
+++ b/source/guides/packaging-binary-extensions.rst
@@ -403,3 +403,15 @@ a Debian system, see the following articles:
 * `What are (c)python extension modules? `_
 * `Releasing the gil `_
 * `Writing cpython extension modules using C++ `_
+
+Additional considerations for binary wheels
+-------------------------------------------
+
+The `pypackaging-native `_ website has 
+additional coverage of packaging Python packages with native code. It aims to 
+provide an overview of the most important packaging issues for such projects, 
+with in-depth explanations and references.
+
+Topics cover for example non-Python compiled dependencies ("native dependencies"), 
+the importance of the ABI (Application Binary Interface) of native code, 
+dependency on SIMD code and cross compilation. 

From fb2192df714ec14879ec2ef7e37050481339512b Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Sat, 1 Jun 2024 19:36:03 +0000
Subject: [PATCH 0702/1072] [pre-commit.ci] auto fixes from pre-commit.com
 hooks

for more information, see https://pre-commit.ci
---
 source/guides/packaging-binary-extensions.rst | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/source/guides/packaging-binary-extensions.rst b/source/guides/packaging-binary-extensions.rst
index b664d68a4..ff7298658 100644
--- a/source/guides/packaging-binary-extensions.rst
+++ b/source/guides/packaging-binary-extensions.rst
@@ -407,11 +407,11 @@ a Debian system, see the following articles:
 Additional considerations for binary wheels
 -------------------------------------------
 
-The `pypackaging-native `_ website has 
-additional coverage of packaging Python packages with native code. It aims to 
-provide an overview of the most important packaging issues for such projects, 
+The `pypackaging-native `_ website has
+additional coverage of packaging Python packages with native code. It aims to
+provide an overview of the most important packaging issues for such projects,
 with in-depth explanations and references.
 
-Topics cover for example non-Python compiled dependencies ("native dependencies"), 
-the importance of the ABI (Application Binary Interface) of native code, 
-dependency on SIMD code and cross compilation. 
+Topics cover for example non-Python compiled dependencies ("native dependencies"),
+the importance of the ABI (Application Binary Interface) of native code,
+dependency on SIMD code and cross compilation.

From bd9956a0f90865ce704bb19587ab6c1129bb4c80 Mon Sep 17 00:00:00 2001
From: Victor Blomqvist 
Date: Sat, 1 Jun 2024 21:57:05 +0200
Subject: [PATCH 0703/1072] Minor improvement of text

---
 source/guides/packaging-binary-extensions.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/packaging-binary-extensions.rst b/source/guides/packaging-binary-extensions.rst
index b664d68a4..25a897d2e 100644
--- a/source/guides/packaging-binary-extensions.rst
+++ b/source/guides/packaging-binary-extensions.rst
@@ -412,6 +412,6 @@ additional coverage of packaging Python packages with native code. It aims to
 provide an overview of the most important packaging issues for such projects, 
 with in-depth explanations and references.
 
-Topics cover for example non-Python compiled dependencies ("native dependencies"), 
+Example of topics are non-Python compiled dependencies ("native dependencies"), 
 the importance of the ABI (Application Binary Interface) of native code, 
 dependency on SIMD code and cross compilation. 

From ce3653dc5f0f7376cc240954ecac71528ce2022e Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Sat, 1 Jun 2024 19:58:24 +0000
Subject: [PATCH 0704/1072] [pre-commit.ci] auto fixes from pre-commit.com
 hooks

for more information, see https://pre-commit.ci
---
 source/guides/packaging-binary-extensions.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/guides/packaging-binary-extensions.rst b/source/guides/packaging-binary-extensions.rst
index 4a3be2cc3..de8a9d2d6 100644
--- a/source/guides/packaging-binary-extensions.rst
+++ b/source/guides/packaging-binary-extensions.rst
@@ -412,6 +412,6 @@ additional coverage of packaging Python packages with native code. It aims to
 provide an overview of the most important packaging issues for such projects,
 with in-depth explanations and references.
 
-Examples of topics covered are non-Python compiled dependencies ("native 
-dependencies"), the importance of the ABI (Application Binary Interface) of 
+Examples of topics covered are non-Python compiled dependencies ("native
+dependencies"), the importance of the ABI (Application Binary Interface) of
 native code, dependency on SIMD code and cross compilation.

From f70787f91f8e8eee48365e60b576f0ff70285ab2 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 17 Jun 2024 19:46:45 +0000
Subject: [PATCH 0705/1072] [pre-commit.ci] pre-commit autoupdate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

updates:
- [github.com/codespell-project/codespell: v2.2.6 → v2.3.0](https://github.com/codespell-project/codespell/compare/v2.2.6...v2.3.0)
- [github.com/astral-sh/ruff-pre-commit: v0.4.3 → v0.4.9](https://github.com/astral-sh/ruff-pre-commit/compare/v0.4.3...v0.4.9)
---
 .pre-commit-config.yaml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index b1cc54c6e..de44b7a34 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -12,7 +12,7 @@ repos:
   - id: trailing-whitespace
 
 - repo: https://github.com/codespell-project/codespell
-  rev: v2.2.6
+  rev: v2.3.0
   hooks:
   - id: codespell
     args: ["-L", "ned,ist,oder", "--skip", "*.po"]
@@ -34,7 +34,7 @@ repos:
   - id: rst-inline-touching-normal
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.4.3
+  rev: v0.4.9
   hooks:
     - id: ruff
     - id: ruff-format

From 82280c02107fa1b3f946de89325f1575cdd8287b Mon Sep 17 00:00:00 2001
From: Alyssa Coghlan 
Date: Wed, 19 Jun 2024 21:37:22 +1000
Subject: [PATCH 0706/1072] Add HTML snippet for Plausible metrics

Metrics are only collected for the main packaging.python.org
documentation deployments.

Closes #1561
---
 source/conf.py | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/source/conf.py b/source/conf.py
index 831f9c9ea..be5f7f149 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -1,6 +1,14 @@
 # -- Project information ---------------------------------------------------------------
 # https://www.sphinx-doc.org/en/master/usage/configuration.html#project-information
 
+import os
+
+# Some options are only enabled for the main packaging.python.org deployment builds
+RTD_BUILD = bool(os.getenv("READTHEDOCS"))
+RTD_PR_BUILD = RTD_BUILD and os.getenv("READTHEDOCS_VERSION_TYPE") == "external"
+RTD_URL = os.getenv("READTHEDOCS_CANONICAL_URL")
+RTD_CANONICAL_BUILD = RTD_BUILD and not RTD_PR_BUILD and "packaging.python.org" in RTD_URL
+
 project = "Python Packaging User Guide"
 
 copyright = "2013–2020, PyPA"
@@ -55,6 +63,15 @@
 html_favicon = "assets/py.png"
 html_last_updated_fmt = ""
 
+_metrics_js_files = [
+    ("https://plausible.io/js/script.js", {"data-domain": "packaging.python.org"})
+]
+html_js_files = []
+if RTD_CANONICAL_BUILD:
+    # Enable collection of the visitor metrics reported at
+    # https://plausible.io/packaging.python.org
+    html_js_files.extend(_metrics_js_files)
+
 # -- Options for HTML help output ------------------------------------------------------
 # https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-html-help-output
 

From 5bf53f3eba538f4e8953ca66f36ddb5d3e8963d9 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Wed, 19 Jun 2024 11:37:57 +0000
Subject: [PATCH 0707/1072] [pre-commit.ci] auto fixes from pre-commit.com
 hooks

for more information, see https://pre-commit.ci
---
 source/conf.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/source/conf.py b/source/conf.py
index be5f7f149..3817ce1d3 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -7,7 +7,9 @@
 RTD_BUILD = bool(os.getenv("READTHEDOCS"))
 RTD_PR_BUILD = RTD_BUILD and os.getenv("READTHEDOCS_VERSION_TYPE") == "external"
 RTD_URL = os.getenv("READTHEDOCS_CANONICAL_URL")
-RTD_CANONICAL_BUILD = RTD_BUILD and not RTD_PR_BUILD and "packaging.python.org" in RTD_URL
+RTD_CANONICAL_BUILD = (
+    RTD_BUILD and not RTD_PR_BUILD and "packaging.python.org" in RTD_URL
+)
 
 project = "Python Packaging User Guide"
 

From c37de0523ac61c8b2a9608a9e7b2314c88d293b0 Mon Sep 17 00:00:00 2001
From: Alyssa Coghlan 
Date: Wed, 19 Jun 2024 23:22:36 +1000
Subject: [PATCH 0708/1072] Defer loading metrics JS

---
 source/conf.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/conf.py b/source/conf.py
index 3817ce1d3..92c1290cc 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -66,7 +66,7 @@
 html_last_updated_fmt = ""
 
 _metrics_js_files = [
-    ("https://plausible.io/js/script.js", {"data-domain": "packaging.python.org"})
+    ("https://plausible.io/js/script.js", {"data-domain": "packaging.python.org", "defer": "defer"})
 ]
 html_js_files = []
 if RTD_CANONICAL_BUILD:

From db35d2764a9ad62dedf231b75bab05d1046ead4c Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Wed, 19 Jun 2024 13:22:48 +0000
Subject: [PATCH 0709/1072] [pre-commit.ci] auto fixes from pre-commit.com
 hooks

for more information, see https://pre-commit.ci
---
 source/conf.py | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/source/conf.py b/source/conf.py
index 92c1290cc..cd459ffb2 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -66,7 +66,10 @@
 html_last_updated_fmt = ""
 
 _metrics_js_files = [
-    ("https://plausible.io/js/script.js", {"data-domain": "packaging.python.org", "defer": "defer"})
+    (
+        "https://plausible.io/js/script.js",
+        {"data-domain": "packaging.python.org", "defer": "defer"},
+    )
 ]
 html_js_files = []
 if RTD_CANONICAL_BUILD:

From 4af7da079f97a91fdb8f53155be84258bf1f524d Mon Sep 17 00:00:00 2001
From: Alyssa Coghlan 
Date: Thu, 20 Jun 2024 02:26:34 +1000
Subject: [PATCH 0710/1072] Use intersphinx reference

---
 source/specifications/binary-distribution-format.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst
index 211019f85..692e6f642 100644
--- a/source/specifications/binary-distribution-format.rst
+++ b/source/specifications/binary-distribution-format.rst
@@ -43,8 +43,8 @@ Wheel installation notionally consists of two phases:
      destination path. Each subdirectory of ``distribution-1.0.data/``
      is a key into a dict of destination directories, such as
      ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``.
-     These subdirectories are `installation paths defined by sysconfig
-     `_.
+     These subdirectories are :ref:`installation paths defined by sysconfig
+     `_.
   c. If applicable, update scripts starting with ``#!python`` to point
      to the correct interpreter.
   d. Update ``distribution-1.0.dist-info/RECORD`` with the installed

From 5c432f6a043a0988ab5814f978c6387daf28765a Mon Sep 17 00:00:00 2001
From: Alyssa Coghlan 
Date: Thu, 20 Jun 2024 02:29:44 +1000
Subject: [PATCH 0711/1072] Fix ref syntax and target name

---
 source/specifications/binary-distribution-format.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst
index 692e6f642..8da38357a 100644
--- a/source/specifications/binary-distribution-format.rst
+++ b/source/specifications/binary-distribution-format.rst
@@ -44,7 +44,7 @@ Wheel installation notionally consists of two phases:
      is a key into a dict of destination directories, such as
      ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``.
      These subdirectories are :ref:`installation paths defined by sysconfig
-     `_.
+     `.
   c. If applicable, update scripts starting with ``#!python`` to point
      to the correct interpreter.
   d. Update ``distribution-1.0.dist-info/RECORD`` with the installed

From 77a87f2f6ce25f38e3672d05bd7ee378157de0b5 Mon Sep 17 00:00:00 2001
From: Daniel Schultz 
Date: Thu, 20 Jun 2024 14:27:13 -0400
Subject: [PATCH 0712/1072] Fix a typo

---
 source/guides/writing-pyproject-toml.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index 938ebbb93..e82bd893d 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -340,7 +340,7 @@ or you can write the name of the license:
     license = {text = "MIT License"}
 
 If you are using a standard, well-known license, it is not necessary to use this
-field. Instead, you should one of the :ref:`classifiers` starting with ``License
+field. Instead, you should use one of the :ref:`classifiers` starting with ``License
 ::``. (As a general rule, it is a good idea to use a standard, well-known
 license, both to avoid confusion and because some organizations avoid software
 whose license is unapproved.)

From c0953f394e467281a77afa9c42a41ee7d8bcbdb2 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 24 Jun 2024 19:47:21 +0000
Subject: [PATCH 0713/1072] [pre-commit.ci] pre-commit autoupdate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

updates:
- [github.com/astral-sh/ruff-pre-commit: v0.4.9 → v0.4.10](https://github.com/astral-sh/ruff-pre-commit/compare/v0.4.9...v0.4.10)
---
 .pre-commit-config.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index de44b7a34..c6372ec30 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -34,7 +34,7 @@ repos:
   - id: rst-inline-touching-normal
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.4.9
+  rev: v0.4.10
   hooks:
     - id: ruff
     - id: ruff-format

From 3a4616755d742e8c7c29b88e2e686e50ce6452b4 Mon Sep 17 00:00:00 2001
From: Matthew Donoughe 
Date: Tue, 21 May 2024 09:26:36 -0400
Subject: [PATCH 0714/1072] allow trailing comma in version_many

---
 source/specifications/dependency-specifiers.rst | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst
index b6c867084..e35d22b14 100644
--- a/source/specifications/dependency-specifiers.rst
+++ b/source/specifications/dependency-specifiers.rst
@@ -66,7 +66,7 @@ URI is defined in :rfc:`std-66 <3986>`)::
     version_cmp   = wsp* '<' | '<=' | '!=' | '==' | '>=' | '>' | '~=' | '==='
     version       = wsp* ( letterOrDigit | '-' | '_' | '.' | '*' | '+' | '!' )+
     version_one   = version_cmp version wsp*
-    version_many  = version_one (wsp* ',' version_one)*
+    version_many  = version_one (',' version_one)* (',' wsp*)?
     versionspec   = ( '(' version_many ')' ) | version_many
     urlspec       = '@' wsp* 
 
@@ -303,7 +303,7 @@ The complete parsley grammar::
     version_cmp   = wsp* <'<=' | '<' | '!=' | '==' | '>=' | '>' | '~=' | '==='>
     version       = wsp* <( letterOrDigit | '-' | '_' | '.' | '*' | '+' | '!' )+>
     version_one   = version_cmp:op version:v wsp* -> (op, v)
-    version_many  = version_one:v1 (wsp* ',' version_one)*:v2 -> [v1] + v2
+    version_many  = version_one:v1 (',' version_one)*:v2 (',' wsp*)? -> [v1] + v2
     versionspec   = ('(' version_many:v ')' ->v) | version_many
     urlspec       = '@' wsp* 
     marker_op     = version_cmp | (wsp* 'in') | (wsp* 'not' wsp+ 'in')
@@ -424,6 +424,7 @@ A test program - if the grammar is in a string ``grammar``:
         "name",
         "name<=1",
         "name>=3",
+        "name>=3,",
         "name>=3,<2",
         "name@http://foo.com",
         "name [fred,bar] @ http://foo.com ; python_version=='2.7'",
@@ -481,6 +482,9 @@ History
   ``'.'.join(platform.python_version_tuple()[:2])``, to accommodate potential
   future versions of Python with 2-digit major and minor versions
   (e.g. 3.10). [#future_versions]_
+- May 2024: The definition of ``version_many`` was changed to allow trailing
+  commas, matching with the behavior of the Python implementation that has been
+  in use since late 2022.
 
 
 References

From e496a99cb2b89fd496b4522e4fea40aa4311bfd7 Mon Sep 17 00:00:00 2001
From: Matthew Donoughe 
Date: Wed, 26 Jun 2024 08:10:26 -0400
Subject: [PATCH 0715/1072] update month

---
 source/specifications/dependency-specifiers.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst
index e35d22b14..d6713f713 100644
--- a/source/specifications/dependency-specifiers.rst
+++ b/source/specifications/dependency-specifiers.rst
@@ -482,7 +482,7 @@ History
   ``'.'.join(platform.python_version_tuple()[:2])``, to accommodate potential
   future versions of Python with 2-digit major and minor versions
   (e.g. 3.10). [#future_versions]_
-- May 2024: The definition of ``version_many`` was changed to allow trailing
+- June 2024: The definition of ``version_many`` was changed to allow trailing
   commas, matching with the behavior of the Python implementation that has been
   in use since late 2022.
 

From ade43fa7f52f091994a7ec578332e4c842f8e99c Mon Sep 17 00:00:00 2001
From: Christopher Covington 
Date: Fri, 12 Jul 2024 10:51:10 +0000
Subject: [PATCH 0716/1072] Fix conflicting classification of install

The first paragraph says the command must not be run anymore.
---
 source/discussions/setup-py-deprecated.rst | 1 -
 1 file changed, 1 deletion(-)

diff --git a/source/discussions/setup-py-deprecated.rst b/source/discussions/setup-py-deprecated.rst
index 4993d8a0d..1c2eae3fa 100644
--- a/source/discussions/setup-py-deprecated.rst
+++ b/source/discussions/setup-py-deprecated.rst
@@ -141,7 +141,6 @@ This guide does not make suggestions of replacement solutions for those commands
     * ``easy_install``
     * ``editable_wheel``
     * ``egg_info``
-    * ``install``
     * ``install_data``
     * ``install_egg_info``
     * ``install_headers``

From 8891fa5417c7ed0b60fab07c276d237cce8624ff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?K=C3=A2muran=20=C4=B0mran?=
 <73625486+kamurani@users.noreply.github.com>
Date: Mon, 29 Jul 2024 15:45:21 +1000
Subject: [PATCH 0717/1072] fix typo

---
 source/guides/writing-pyproject-toml.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index e82bd893d..18a717a55 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -130,7 +130,7 @@ only field that cannot be marked as dynamic.
    [project]
    name = "spam-eggs"
 
-The project name must consists of ASCII letters, digits, underscores "``_``",
+The project name must consist of ASCII letters, digits, underscores "``_``",
 hyphens "``-``" and periods "``.``". It must not start or end with an
 underscore, hyphen or period.
 

From 4a5cbf920c6a7c7a37e155ff4c74c27a118d3e0b Mon Sep 17 00:00:00 2001
From: chrysle 
Date: Sat, 23 Dec 2023 15:21:43 +0100
Subject: [PATCH 0718/1072] Update "Dropping older Python versions" guide

---
 .../guides/dropping-older-python-versions.rst | 93 +++++++++++--------
 1 file changed, 53 insertions(+), 40 deletions(-)

diff --git a/source/guides/dropping-older-python-versions.rst b/source/guides/dropping-older-python-versions.rst
index c0c2b4434..1804f35c2 100644
--- a/source/guides/dropping-older-python-versions.rst
+++ b/source/guides/dropping-older-python-versions.rst
@@ -4,23 +4,17 @@
 Dropping support for older Python versions
 ==========================================
 
-Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a "Requires-Python" attribute.
+Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a :ref:`"Requires-Python" ` attribute.
 
 Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version
 in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime.
 
-This mechanism can be used to drop support for older Python versions, by amending the "Requires-Python" attribute in the package metadata.
-
-This guide is specifically for users of :ref:`setuptools`, other packaging tools such as ``flit`` may offer similar functionality but users will need to consult relevant documentation.
+This mechanism can be used to drop support for older Python versions, by amending the ``Requires-Python`` attribute in the package metadata.
 
 Requirements
 ------------
 
-This workflow requires that:
-
-1. The publisher is using the latest version of :ref:`setuptools`,
-2. The latest version of :ref:`twine` is used to upload the package,
-3. The user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification.
+This workflow requires that the user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification.
 
 Dealing with the universal wheels
 ---------------------------------
@@ -52,42 +46,50 @@ explicitly set ``universal`` to ``0``:
 Defining the Python version required
 ------------------------------------
 
-1. Download the newest version of Setuptools
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Ensure that before you generate source distributions or binary distributions, you update Setuptools and install twine.
+1. Install twine
+~~~~~~~~~~~~~~~~
 
+Ensure that you have twine available at its latest version.
 Steps:
 
 .. tab:: Unix/macOS
 
     .. code-block:: bash
 
-        python3 -m pip install --upgrade setuptools twine
+        python3 -m pip install --upgrade twine
 
 .. tab:: Windows
 
     .. code-block:: bat
 
-        py -m pip install --upgrade setuptools twine
-
-``setuptools`` version should be above 24.0.0.
+        py -m pip install --upgrade twine
 
 2. Specify the version ranges for supported Python distributions
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-You can specify version ranges and exclusion rules, such as at least Python 3. Or, Python 2.7, 3.4 and beyond.
-
-Examples:
+You can specify version ranges and exclusion rules (complying with the :ref:`version-specifiers` specification),
+such as at least Python 3. Or, Python 2.7, 3.4 and beyond:
 
 .. code-block:: text
 
-    Requires-Python: ">=3"
-    Requires-Python: ">2.7,!=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*"
+    Requires-Python: ">= 3"
+    Requires-Python: ">= 2.7, != 3.0.*, != 3.1.*, != 3.2.*, != 3.3.*"
+
+
+The way to set those values is within your :file:`pyproject.toml`. The :ref:`requires-python` field of the
+``[project]`` table corresponds to the ``Requires-Python`` metadata field.
+
+.. code-block:: toml
 
-The way to set those values is within the call to ``setup`` within your
-:file:`setup.py` script. This will insert the ``Requires-Python``
-metadata values based on the argument you provide in ``python_requires``.
+   [build-system]
+   ...
+
+   [project]
+   requires-python = ">= 3.8" # At least Python 3.8
+
+
+For :ref:`setuptools` users, another way to achieve this is using the ``python_requires`` parameter
+in the call to ``setup`` within your :file:`setup.py` script.
 
 .. code-block:: python
 
@@ -96,43 +98,54 @@ metadata values based on the argument you provide in ``python_requires``.
 
     setup(
         # Your setup arguments
-        python_requires='>=2.7',  # Your supported Python ranges
+        python_requires='>= 3.8',
     )
 
+It is warned against adding upper bounds to the version ranges, e. g. ``">= 3.8 < 3.10"``. This can cause different errors
+and version conflicts. See the `discourse discussion`_ for more information.
+
 3. Validating the Metadata before publishing
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO.
 
-This file is generated by :ref:`distutils` or :ref:`setuptools` when it generates the source package.
-The file contains a set of keys and values, the list of keys is part of the PyPa standard metadata format.
+This file is generated by the build backend when it generates the source package.
+The file contains a set of keys and values, the list of keys is part of the PyPA standard metadata format.
 
 You can see the contents of the generated file like this:
 
 .. code-block:: bash
 
-    tar xfO dist/my-package-1.0.0.tar.gz my-package-1.0.0/PKG-INFO
+    tar xf dist/my-package-1.0.0.tar.gz my-package-1.0.0/PKG-INFO -O
 
 Validate that the following is in place, before publishing the package:
 
 - If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher.
-- The Requires-Python field is set and matches your specification in setup.py.
+- The ``Requires-Python`` field is set and matches your specification in the configuration file.
 
-4. Using Twine to publish
+4. Publishing the package
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages.
+Proceed as suggested in :ref:`Uploading your Project to PyPI`.
 
-Make sure you are using the newest version of Twine, at least 1.9.
-
-Dropping a Python release
+Dropping a Python version
 -------------------------
 
-Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support.
+In principle, at least metadata support for Python versions should be kept as long as possible, because
+once that has been dropped, people still depending on a version will be forced to downgrade.
+If however supporting a specific version becomes a blocker for a new feature or other issues occur, the metadata
+``Requires-Python`` should be amended. Of course this also depends on whether the project needs to be stable and
+well-covered for a wider range of users.
+
+Each version compatibility change should have an own release.
+
+For example, you published version 1.0.0 of your package with ``Requires-Python: ">= 2.7"`` metadata.
+
+If you then update the version string to ``">= 3.5"``, and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any ``>= 3.5`` users will receive version 2.0.0.
 
-It must be done in this order for the automated fallback to work.
+It may be a good idea to create a minor release, stating that it is the last one compatible with the Python version to be removed, just before dropping that version.
 
-For example, you published the Requires-Python: ">=2.7" as version 1.0.0 of your package.
+When dropping a Python version, it might also be rewarding to upgrade the project's code syntax generally, apart from updating the versions used in visible places (like the testing environment). Tools like pyupgrade_ can simplify this task.
 
-If you were then to update the version string to ">=3.5", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will
-have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0.
+.. _discourse discussion: https://discuss.python.org/t/requires-python-upper-limits/12663
+.. _pyupgrade: https://pypi.org/project/pyupgrade/

From a02e0691a89d59d128302ff4223e443d7476c439 Mon Sep 17 00:00:00 2001
From: chrysle <96722107+chrysle@users.noreply.github.com>
Date: Fri, 5 Jul 2024 16:11:49 +0200
Subject: [PATCH 0719/1072] Apply review comments
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) <578543+webknjaz@users.noreply.github.com>
Co-authored-by: Jean Abou Samra <37271310+jeanas@users.noreply.github.com>
Co-authored-by: Edgar Ramírez Mondragón <16805946+edgarrmondragon@users.noreply.github.com>
---
 .../guides/dropping-older-python-versions.rst | 64 ++++++++-----------
 1 file changed, 28 insertions(+), 36 deletions(-)

diff --git a/source/guides/dropping-older-python-versions.rst b/source/guides/dropping-older-python-versions.rst
index 1804f35c2..9fdc35fa8 100644
--- a/source/guides/dropping-older-python-versions.rst
+++ b/source/guides/dropping-older-python-versions.rst
@@ -4,9 +4,9 @@
 Dropping support for older Python versions
 ==========================================
 
-Dropping support for older Python versions is supported by the standard :ref:`core-metadata` 1.2 specification via a :ref:`"Requires-Python" ` attribute.
+The ability to drop support for older Python versions is enabled by the standard :ref:`core-metadata` 1.2 specification via the :ref:`"Requires-Python" ` attribute.
 
-Metadata 1.2+ clients, such as Pip 9.0+, will adhere to this specification by matching the current Python runtime and comparing it with the required version
+Metadata 1.2+ clients, such as Pip, will adhere to this specification by matching the current Python runtime and comparing it with the required version
 in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime.
 
 This mechanism can be used to drop support for older Python versions, by amending the ``Requires-Python`` attribute in the package metadata.
@@ -14,18 +14,17 @@ This mechanism can be used to drop support for older Python versions, by amendin
 Requirements
 ------------
 
-This workflow requires that the user installing the package has at least Pip 9.0, or a client that supports the Metadata 1.2 specification.
+This workflow requires that the user installing the package uses Pip [#]_, or another client that supports the Metadata 1.2 specification.
 
 Dealing with the universal wheels
 ---------------------------------
 
-Traditionally, projects providing Python code that is semantically
+Traditionally, :ref:`setuptools` projects providing Python code that is semantically
 compatible with both Python 2 and Python 3, produce :term:`wheels
 ` that have a ``py2.py3`` tag in their names. When dropping
 support for Python 2, it is important not to forget to change this tag
 to just ``py3``. It is often configured within :file:`setup.cfg` under
-the ``[bdist_wheel]`` section by setting ``universal = 1`` if they
-use setuptools.
+the ``[bdist_wheel]`` section by setting ``universal = 1``.
 
 If you use this method, either remove this option or section, or
 explicitly set ``universal`` to ``0``:
@@ -37,11 +36,10 @@ explicitly set ``universal`` to ``0``:
    [bdist_wheel]
    universal = 0  # Make the generated wheels have "py3" tag
 
-.. tip::
+.. hint::
 
-   Since it is possible to override the :file:`setup.cfg` settings via
-   CLI flags, make sure that your scripts don't have ``--universal`` in
-   your package creation scripts.
+   Regarding :ref:`deprecated ` direct ``setup.py`` invocations,
+   passing the ``--universal`` flag on the command line could override this setting.
 
 Defining the Python version required
 ------------------------------------
@@ -68,16 +66,16 @@ Steps:
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 You can specify version ranges and exclusion rules (complying with the :ref:`version-specifiers` specification),
-such as at least Python 3. Or, Python 2.7, 3.4 and beyond:
+such as at least Python 3. Or, Python 3.7, 3.8, 3.13 and beyond:
 
 .. code-block:: text
 
     Requires-Python: ">= 3"
-    Requires-Python: ">= 2.7, != 3.0.*, != 3.1.*, != 3.2.*, != 3.3.*"
+    Requires-Python: ">= 3.7, != 3.9.*, != 3.10.*, != 3.11.*, != 3.12.*"
 
 
-The way to set those values is within your :file:`pyproject.toml`. The :ref:`requires-python` field of the
-``[project]`` table corresponds to the ``Requires-Python`` metadata field.
+Those values can be set within your :file:`pyproject.toml`. The :ref:`requires-python` configuration field
+corresponds to the ``Requires-Python`` metadata field.
 
 .. code-block:: toml
 
@@ -89,34 +87,29 @@ The way to set those values is within your :file:`pyproject.toml`. The :ref:`req
 
 
 For :ref:`setuptools` users, another way to achieve this is using the ``python_requires`` parameter
-in the call to ``setup`` within your :file:`setup.py` script.
-
-.. code-block:: python
-
-    from setuptools import setup
-
+in your :file:`setup.cfg` config or the :file:`setup.py` script. ``setuptools < 61`` does not support
+declaring the package metadata in :file:`pyproject.toml`.
 
-    setup(
-        # Your setup arguments
-        python_requires='>= 3.8',
-    )
+Consult the ``setuptools`` `dependency-management`_ documentation for information about the appropriate
+way to configure each of these files.
 
-It is warned against adding upper bounds to the version ranges, e. g. ``">= 3.8 < 3.10"``. This can cause different errors
-and version conflicts. See the `discourse discussion`_ for more information.
+.. caution::
+        It is warned against adding upper bounds to the version ranges, e. g. ``">= 3.8 < 3.10"``. This can cause different errors
+        and version conflicts. See the `discourse-discussion`_ for more information.
 
 3. Validating the Metadata before publishing
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Within a Python source package (the zip or the tar-gz file you download) is a text file called PKG-INFO.
 
-This file is generated by the build backend when it generates the source package.
+This file is generated by the :term:`build backend ` when it generates the source package.
 The file contains a set of keys and values, the list of keys is part of the PyPA standard metadata format.
 
 You can see the contents of the generated file like this:
 
 .. code-block:: bash
 
-    tar xf dist/my-package-1.0.0.tar.gz my-package-1.0.0/PKG-INFO -O
+    tar xfO dist/my-package-1.0.0.tar.gz my-package-1.0.0/PKG-INFO
 
 Validate that the following is in place, before publishing the package:
 
@@ -137,15 +130,14 @@ If however supporting a specific version becomes a blocker for a new feature or
 ``Requires-Python`` should be amended. Of course this also depends on whether the project needs to be stable and
 well-covered for a wider range of users.
 
-Each version compatibility change should have an own release.
+Each version compatibility change should have its own release.
 
-For example, you published version 1.0.0 of your package with ``Requires-Python: ">= 2.7"`` metadata.
-
-If you then update the version string to ``">= 3.5"``, and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any ``>= 3.5`` users will receive version 2.0.0.
-
-It may be a good idea to create a minor release, stating that it is the last one compatible with the Python version to be removed, just before dropping that version.
+.. tip::
 
-When dropping a Python version, it might also be rewarding to upgrade the project's code syntax generally, apart from updating the versions used in visible places (like the testing environment). Tools like pyupgrade_ can simplify this task.
+        When dropping a Python version, it might also be rewarding to upgrade the project's code syntax generally, apart from updating the versions used in visible         places (like the testing environment). Tools like pyupgrade_ can simplify this task.
 
-.. _discourse discussion: https://discuss.python.org/t/requires-python-upper-limits/12663
+.. _discourse-discussion: https://discuss.python.org/t/requires-python-upper-limits/12663
 .. _pyupgrade: https://pypi.org/project/pyupgrade/
+.. _dependency-management: https://setuptools.pypa.io/en/latest/userguide/dependency_management.html#python-requirement
+
+.. [#] Support for the Metadata 1.2 specification has been added in Pip 9.0.

From c5723dfac9563d5885ee667c358dbaad3cea92e6 Mon Sep 17 00:00:00 2001
From: chrysle <96722107+chrysle@users.noreply.github.com>
Date: Sat, 20 Jul 2024 17:59:53 +0200
Subject: [PATCH 0720/1072] Use `pyproject.toml` instead of core metadata
 syntax

Better version range examples, tweak grammar, mention `ruff`
as helper tool for Python version upgrade

Co-authored-by: Jason R. Coombs <308610+jaraco@users.noreply.github.com>
---
 .../guides/dropping-older-python-versions.rst | 37 ++++++++-----------
 1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/source/guides/dropping-older-python-versions.rst b/source/guides/dropping-older-python-versions.rst
index 9fdc35fa8..f3945dd6f 100644
--- a/source/guides/dropping-older-python-versions.rst
+++ b/source/guides/dropping-older-python-versions.rst
@@ -6,7 +6,7 @@ Dropping support for older Python versions
 
 The ability to drop support for older Python versions is enabled by the standard :ref:`core-metadata` 1.2 specification via the :ref:`"Requires-Python" ` attribute.
 
-Metadata 1.2+ clients, such as Pip, will adhere to this specification by matching the current Python runtime and comparing it with the required version
+Metadata 1.2+ installers, such as Pip, will adhere to this specification by matching the current Python runtime and comparing it with the required version
 in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime.
 
 This mechanism can be used to drop support for older Python versions, by amending the ``Requires-Python`` attribute in the package metadata.
@@ -14,7 +14,7 @@ This mechanism can be used to drop support for older Python versions, by amendin
 Requirements
 ------------
 
-This workflow requires that the user installing the package uses Pip [#]_, or another client that supports the Metadata 1.2 specification.
+This workflow requires that the user installing the package uses Pip [#]_, or another installer that supports the Metadata 1.2 specification.
 
 Dealing with the universal wheels
 ---------------------------------
@@ -65,17 +65,9 @@ Steps:
 2. Specify the version ranges for supported Python distributions
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-You can specify version ranges and exclusion rules (complying with the :ref:`version-specifiers` specification),
-such as at least Python 3. Or, Python 3.7, 3.8, 3.13 and beyond:
-
-.. code-block:: text
-
-    Requires-Python: ">= 3"
-    Requires-Python: ">= 3.7, != 3.9.*, != 3.10.*, != 3.11.*, != 3.12.*"
-
-
-Those values can be set within your :file:`pyproject.toml`. The :ref:`requires-python` configuration field
-corresponds to the ``Requires-Python`` metadata field.
+Set the version ranges declaring which Python distributions are supported  
+within your project's :file:`pyproject.toml`. The :ref:`requires-python` configuration field
+corresponds to the :ref:`Requires-Python ` core metadata field:
 
 .. code-block:: toml
 
@@ -85,16 +77,19 @@ corresponds to the ``Requires-Python`` metadata field.
    [project]
    requires-python = ">= 3.8" # At least Python 3.8
 
+You can specify version ranges and exclusion rules (complying with the :ref:`version-specifiers` specification),
+such as at least Python 3.9. Or, at least Python 3.7 and beyond, skipping the 3.7.0 and 3.7.1 point releases:
+
+.. code-block:: toml
+
+    requires-python = ">= 3.9"
+    requires-python = ">= 3.7, != 3.7.0, != 3.7.1"
 
-For :ref:`setuptools` users, another way to achieve this is using the ``python_requires`` parameter
-in your :file:`setup.cfg` config or the :file:`setup.py` script. ``setuptools < 61`` does not support
-declaring the package metadata in :file:`pyproject.toml`.
 
-Consult the ``setuptools`` `dependency-management`_ documentation for information about the appropriate
-way to configure each of these files.
+If using the :ref:`setuptools` build backend, consult the `dependency-management`_ documentation for more options.
 
 .. caution::
-        It is warned against adding upper bounds to the version ranges, e. g. ``">= 3.8 < 3.10"``. This can cause different errors
+        Avoid adding upper bounds to the version ranges, e. g. ``">= 3.8, < 3.10"``. Doing so can cause different errors
         and version conflicts. See the `discourse-discussion`_ for more information.
 
 3. Validating the Metadata before publishing
@@ -113,7 +108,7 @@ You can see the contents of the generated file like this:
 
 Validate that the following is in place, before publishing the package:
 
-- If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher.
+- If you have upgraded correctly, the ``Metadata-Version`` value should be 1.2 or higher.
 - The ``Requires-Python`` field is set and matches your specification in the configuration file.
 
 4. Publishing the package
@@ -134,7 +129,7 @@ Each version compatibility change should have its own release.
 
 .. tip::
 
-        When dropping a Python version, it might also be rewarding to upgrade the project's code syntax generally, apart from updating the versions used in visible         places (like the testing environment). Tools like pyupgrade_ can simplify this task.
+        When dropping a Python version, it might also be rewarding to upgrade the project's code syntax generally, apart from updating the versions used in visible places (like the testing environment). Tools like pyupgrade_ or `ruff `_ can automate some of this work.
 
 .. _discourse-discussion: https://discuss.python.org/t/requires-python-upper-limits/12663
 .. _pyupgrade: https://pypi.org/project/pyupgrade/

From 2b6bc988c5f7867de72fb6278b95f745bbf2712f Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Sat, 20 Jul 2024 16:05:06 +0000
Subject: [PATCH 0721/1072] [pre-commit.ci] auto fixes from pre-commit.com
 hooks

for more information, see https://pre-commit.ci
---
 source/guides/dropping-older-python-versions.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/dropping-older-python-versions.rst b/source/guides/dropping-older-python-versions.rst
index f3945dd6f..267d7b923 100644
--- a/source/guides/dropping-older-python-versions.rst
+++ b/source/guides/dropping-older-python-versions.rst
@@ -65,7 +65,7 @@ Steps:
 2. Specify the version ranges for supported Python distributions
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Set the version ranges declaring which Python distributions are supported  
+Set the version ranges declaring which Python distributions are supported
 within your project's :file:`pyproject.toml`. The :ref:`requires-python` configuration field
 corresponds to the :ref:`Requires-Python ` core metadata field:
 

From f6d6e5ce3165c7ce6b92c8d6b6f2bd9341154565 Mon Sep 17 00:00:00 2001
From: chrysle <96722107+chrysle@users.noreply.github.com>
Date: Mon, 29 Jul 2024 10:41:44 +0200
Subject: [PATCH 0722/1072] Temporarily ignore https://pyscaffold.org, fix
 Fedora link

---
 source/conf.py                                 | 1 +
 source/guides/installing-using-linux-tools.rst | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/source/conf.py b/source/conf.py
index cd459ffb2..c777550ce 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -132,6 +132,7 @@
     # Ignore while StackOverflow is blocking GitHub CI. Ref:
     # https://github.com/pypa/packaging.python.org/pull/1474
     "https://stackoverflow.com/*",
+    "https://pyscaffold.org/*",
 ]
 linkcheck_retries = 5
 # Ignore anchors for links to GitHub project pages -- GitHub adds anchors from
diff --git a/source/guides/installing-using-linux-tools.rst b/source/guides/installing-using-linux-tools.rst
index f0914f8dc..56647f3e9 100644
--- a/source/guides/installing-using-linux-tools.rst
+++ b/source/guides/installing-using-linux-tools.rst
@@ -51,7 +51,7 @@ To install pip and wheel for the system Python, there are two options:
 
 1. Enable the `EPEL repository `_ using
    `these instructions
-   `__.
+   `__.
    On EPEL 7, you can install pip and wheel like so:
 
    .. code-block:: bash

From 85dc060158e2e2f0764033bf9fb4a4ceea0bc0ae Mon Sep 17 00:00:00 2001
From: chrysle <96722107+chrysle@users.noreply.github.com>
Date: Sat, 25 May 2024 20:19:01 +0200
Subject: [PATCH 0723/1072] Add guide on packaging command-line tooling

---
 .../analyzing-pypi-package-downloads.rst      |   2 +
 source/guides/creating-command-line-tools.rst | 213 ++++++++++++++++++
 ...talling-stand-alone-command-line-tools.rst |   2 +
 source/guides/section-build-and-publish.rst   |   1 +
 4 files changed, 218 insertions(+)
 create mode 100644 source/guides/creating-command-line-tools.rst

diff --git a/source/guides/analyzing-pypi-package-downloads.rst b/source/guides/analyzing-pypi-package-downloads.rst
index 62efea7ab..5fecc99c1 100644
--- a/source/guides/analyzing-pypi-package-downloads.rst
+++ b/source/guides/analyzing-pypi-package-downloads.rst
@@ -1,3 +1,5 @@
+.. _analyzing-pypi-package-downloads:
+
 ================================
 Analyzing PyPI package downloads
 ================================
diff --git a/source/guides/creating-command-line-tools.rst b/source/guides/creating-command-line-tools.rst
new file mode 100644
index 000000000..80aaf30a1
--- /dev/null
+++ b/source/guides/creating-command-line-tools.rst
@@ -0,0 +1,213 @@
+.. _creating-command-line-tools:
+
+=========================================
+Creating and packaging command-line tools
+=========================================
+
+This guide will walk you through creating and packaging a standalone command-line application
+that can be installed with :ref:`pipx`, a tool creating and managing :term:`Python Virtual Environments `
+and exposing the executable scripts of packages (and available manual pages) for use on the command-line.
+
+Creating the package
+====================
+
+First of all, we'll need to create a source tree for the :term:`project `. For the sake of an example, we'll
+create a simple tool outputting a greeting (a string) for a person based on arguments given on the command-line.
+
+.. todo:: Advise on the optimal structure of a Python package in another guide or discussion and link to it here.
+
+This project will adhere to :ref:`src-layout ` and in the end be alike this file tree,
+with the top-level folder and package name ``greetings``:
+
+::
+
+    .
+    ├── pyproject.toml
+    └── src
+        └── greetings
+            ├── cli.py
+            ├── greet.py
+            ├── __init__.py
+            └── __main__.py
+
+The actual code responsible for the tool's functionality will be stored in the file :file:`greet.py`,
+named after the main module:
+
+.. code-block:: python
+
+	def greet(name="", gender="", knight=False, count=1):
+	    greeting = "Greetings, dear "
+	    masculine = gender == "masculine"
+	    feminine = gender == "feminine"
+	    if gender or knight:
+	        salutation = ""
+	        if knight:
+	            salutation = "Sir "
+	        elif masculine:
+	            salutation = "Mr. "
+	        elif feminine:
+	            salutation = "Ms. "
+	        greeting += salutation
+	        if name:
+	            greeting += f"{name}!"
+	        else:
+	            pronoun = "her" if feminine else "his" if masculine or knight else "its"
+	            greeting += f"what's-{pronoun}-name!"
+	    else:
+	        if name:
+	            greeting += f"{name}!"
+	        elif not gender:
+	            greeting += "friend!"
+	    for i in range(0, count):
+	        print(greeting)
+
+The above function receives several keyword arguments that determine how the greeting to output is constructed.
+Now, the command-line interface to provision it with the same needs to be constructed, which is done
+in :file:`cli.py`:
+
+.. code-block:: python
+
+	import argparse
+	import sys
+
+	from .greet import greet
+
+	_arg_spec = {
+	    '--name': {
+	        'metavar': 'STRING',
+	        'type': str,
+	        'help': 'The (last, if "gender" is given) name of the person to greet',
+	    },
+	    '--count': {
+	        'metavar': 'INT',
+	        'type': int,
+	        'default': 1,
+	        'help': 'Number of times to greet the person',
+	    },
+
+	}
+	_arg_spec_mutually_exclusive = {
+	    '--gender': {
+	        'metavar': 'STRING',
+	        'type': str,
+	        'help': 'The gender of the person to greet',
+	    },
+	    '--knight': {
+	        'action': 'store_true',
+	        'default': False,
+	        'help': 'Whether the person is a knight',
+	    },
+	}
+
+
+	def main():
+	    parser = argparse.ArgumentParser(
+	        description="Greet a person (semi-)formally."
+	    )
+	    group = parser.add_mutually_exclusive_group()
+	    for arg, spec in _arg_spec.items():
+	        parser.add_argument(arg, **spec)
+	    for arg, spec in _arg_spec_mutually_exclusive.items():
+	        group.add_argument(arg, **spec)
+	    parsed_args = parser.parse_args()
+	    args = {
+	        arg: value
+	        for arg, value in vars(parsed_args).items()
+	        if value is not None
+	    }
+        # Run the function with the command-line arguments as keyword arguments.
+        # A more complex setup is normally initialized at this point.
+	    greet(**args)
+
+
+	if __name__ == "__main__":
+	    sys.exit(main())
+
+The command-line interface is built with :py:mod:`argparse`, a command-line parser which is included in Python's
+standard library. It is a bit rudimentary but sufficient for most needs. Another easy-to-use alternative is docopt_;
+advanced users are encouraged to make use of click_.
+
+We'll add an empty :file:`__init__.py` file, too, to define the project as a regular :term:`import package `.
+
+The file :file:`__main__.py` marks the main entry point for the application when running it via ``python -m greetings``,
+so we'll just initizalize the command-line interface here. The first condition isn't necessary, but may be added in order
+to make the package runnable directly from the source tree, by prepending the package folder to Python's :py:data:`sys.path`:
+
+.. code-block:: python
+
+	import os
+	import sys
+
+	if not __package__:
+        # Make package runnable from source tree with
+        #    python src/greetings
+	    package_source_path = os.path.dirname(os.path.dirname(__file__))
+	    sys.path.insert(0, package_source_path)
+
+	if __name__ == "__main__":
+	    from greetings.cli import main
+	    sys.exit(main())
+
+
+``pyproject.toml``
+------------------
+
+The project's :term:`metadata ` is placed in :term:`pyproject.toml`. The :term:`pyproject metadata keys ` and the ``[build-system]`` table may be filled in as described in :ref:`writing-pyproject-toml`.
+
+For the project to be recognised as a command-line tool, additionally a ``console_scripts`` :ref:`entry point ` (see :ref:`console_scripts`) needs to be added as a :term:`subkey `:
+
+.. code-block:: toml
+
+	[project.scripts]
+	greet = "greetings.cli:main"
+
+Besides, it could prove rewarding to add a ``pipx``-specific entry point, the meaning of which is described below:
+
+.. code-block:: toml
+
+	[project.entry-points."pipx.run"]
+	greetings = "greetings.cli:main"
+
+
+Now, the project's source tree is ready to be transformed into a :term:`distribution package `,
+which makes it installable.
+
+
+Installing the package with ``pipx``
+====================================
+
+After installing ``pipx`` as described in :ref:`installing-stand-alone-command-line-tools`, you're ready to install your project:
+
+.. code-block:: console
+
+	$ pipx install ./greetings/
+
+This will expose the executable script we defined as an entry point and make the command ``greet`` available to you.
+Let's test it:
+
+.. code-block:: console
+
+	$ greet --knight --name Lancelot
+	Greetings, dear Sir Lancelot!
+	$ greet --gender feminine --name Parks
+	Greetings, dear Ms. Parks!
+	$ greet --gender masculine
+	Greetings, dear Mr. what's-his-name!
+
+To just run the program without installing it permanently, you could use ``pipx run``, which will create a temporary (but cached) virtual environment for it:
+
+.. code-block:: console
+
+	$ pipx run ./greetings/ --knight
+
+Thanks to the entry point we defined above (which *must* match the package name), ``pipx`` will pick up the executable script as the
+default one and run it; otherwise, you'd need to specify the entry point's name explicitly with ``pipx run --spec ./greetings/ greet --knight``.
+
+Conclusion
+==========
+
+You know by now how to package a command-line application written in Python. A further step could be to distribute you package,
+meaning uploading it to a :term:`package index `, most commonly :term:`PyPI `. To do that, follow the instructions at :ref:`Packaging your project`. And once you're done, don't forget to :ref:`do some research ` on how your package is received!
+
+.. _click: https://click.palletsprojects.com/
+.. _docopt: https://docopt.readthedocs.io/en/latest/
diff --git a/source/guides/installing-stand-alone-command-line-tools.rst b/source/guides/installing-stand-alone-command-line-tools.rst
index 8578a3b28..c078fd1e4 100644
--- a/source/guides/installing-stand-alone-command-line-tools.rst
+++ b/source/guides/installing-stand-alone-command-line-tools.rst
@@ -1,3 +1,5 @@
+.. _installing-stand-alone-command-line-tools:
+
 Installing stand alone command line tools
 =========================================
 
diff --git a/source/guides/section-build-and-publish.rst b/source/guides/section-build-and-publish.rst
index 2af29d763..8e0c9ab3b 100644
--- a/source/guides/section-build-and-publish.rst
+++ b/source/guides/section-build-and-publish.rst
@@ -11,6 +11,7 @@ Building and Publishing
    dropping-older-python-versions
    packaging-binary-extensions
    packaging-namespace-packages
+   creating-command-line-tools
    creating-and-discovering-plugins
    using-testpypi
    making-a-pypi-friendly-readme

From 6729b3d1f6fbcf3950fd18b6a37c6ffc4291ee5b Mon Sep 17 00:00:00 2001
From: chrysle <96722107+chrysle@users.noreply.github.com>
Date: Mon, 24 Jun 2024 17:08:42 +0200
Subject: [PATCH 0724/1072] Refine structure

Make the guide more easily comprehensible, mention difference between
src and flat layout concerning `runpy` behaviour, mention typer CLI
parser, tighten language

Co-authored-by: Jason R. Coombs <308610+jaraco@users.noreply.github.com>
---
 .../discussions/src-layout-vs-flat-layout.rst | 24 +++++++
 source/guides/creating-command-line-tools.rst | 69 +++++++++++--------
 2 files changed, 63 insertions(+), 30 deletions(-)

diff --git a/source/discussions/src-layout-vs-flat-layout.rst b/source/discussions/src-layout-vs-flat-layout.rst
index bfa405729..c38968345 100644
--- a/source/discussions/src-layout-vs-flat-layout.rst
+++ b/source/discussions/src-layout-vs-flat-layout.rst
@@ -79,3 +79,27 @@ layout and the flat layout:
   ``tox.ini``) and packaging/tooling configuration files (eg: ``setup.py``,
   ``noxfile.py``) on the import path. This would make certain imports work
   in editable installations but not regular installations.
+
+.. _running-cli-from-source-src-layout:
+
+Running a command-line interface from source with src-layout
+============================================================
+
+Due to the firstly mentioned specialty of the src layout, a command-line
+interface can not be run directly from the :term:`source tree `,
+but requires installation of the package in
+:doc:`Development Mode `
+for testing purposes. Since this can be unpractical in some situations,
+a workaround could be to prepend the package folder to  Python's
+:py:data:`sys.path` when called via its :file:`__main__.py` file:
+
+.. code-block:: python
+
+    import os
+    import sys
+
+    if not __package__:
+        # Make CLI runnable from source tree with
+        #    python src/package
+        package_source_path = os.path.dirname(os.path.dirname(__file__))
+        sys.path.insert(0, package_source_path)
diff --git a/source/guides/creating-command-line-tools.rst b/source/guides/creating-command-line-tools.rst
index 80aaf30a1..f7c3fc74a 100644
--- a/source/guides/creating-command-line-tools.rst
+++ b/source/guides/creating-command-line-tools.rst
@@ -11,8 +11,8 @@ and exposing the executable scripts of packages (and available manual pages) for
 Creating the package
 ====================
 
-First of all, we'll need to create a source tree for the :term:`project `. For the sake of an example, we'll
-create a simple tool outputting a greeting (a string) for a person based on arguments given on the command-line.
+First of all, create a source tree for the :term:`project `. For the sake of an example, we'll
+build a simple tool outputting a greeting (a string) for a person based on arguments given on the command-line.
 
 .. todo:: Advise on the optimal structure of a Python package in another guide or discussion and link to it here.
 
@@ -62,7 +62,7 @@ named after the main module:
 	        print(greeting)
 
 The above function receives several keyword arguments that determine how the greeting to output is constructed.
-Now, the command-line interface to provision it with the same needs to be constructed, which is done
+Now, construct the command-line interface to provision it with the same, which is done
 in :file:`cli.py`:
 
 .. code-block:: python
@@ -125,29 +125,28 @@ in :file:`cli.py`:
 
 The command-line interface is built with :py:mod:`argparse`, a command-line parser which is included in Python's
 standard library. It is a bit rudimentary but sufficient for most needs. Another easy-to-use alternative is docopt_;
-advanced users are encouraged to make use of click_.
+advanced users are encouraged to make use of click_ or typer_.
 
-We'll add an empty :file:`__init__.py` file, too, to define the project as a regular :term:`import package `.
+Now, add an empty :file:`__init__.py` file, to define the project as a regular :term:`import package `.
 
-The file :file:`__main__.py` marks the main entry point for the application when running it via ``python -m greetings``,
-so we'll just initizalize the command-line interface here. The first condition isn't necessary, but may be added in order
-to make the package runnable directly from the source tree, by prepending the package folder to Python's :py:data:`sys.path`:
+The file :file:`__main__.py` marks the main entry point for the application when running it via :mod:`runpy`
+(i.e. ``python -m greetings``, which works immediately with flat layout, but requires installation of the package with src layout),
+so initizalize the command-line interface here:
 
 .. code-block:: python
 
-	import os
 	import sys
 
-	if not __package__:
-        # Make package runnable from source tree with
-        #    python src/greetings
-	    package_source_path = os.path.dirname(os.path.dirname(__file__))
-	    sys.path.insert(0, package_source_path)
-
 	if __name__ == "__main__":
 	    from greetings.cli import main
 	    sys.exit(main())
 
+.. note::
+
+    In order to enable calling the command-line interface directly from the :term:`source tree `,
+    i.e. as ``python src/greetings``, a certain hack could be placed in this file; read more at
+    :ref:`running-cli-from-source-src-layout`.
+
 
 ``pyproject.toml``
 ------------------
@@ -161,14 +160,6 @@ For the project to be recognised as a command-line tool, additionally a ``consol
 	[project.scripts]
 	greet = "greetings.cli:main"
 
-Besides, it could prove rewarding to add a ``pipx``-specific entry point, the meaning of which is described below:
-
-.. code-block:: toml
-
-	[project.entry-points."pipx.run"]
-	greetings = "greetings.cli:main"
-
-
 Now, the project's source tree is ready to be transformed into a :term:`distribution package `,
 which makes it installable.
 
@@ -176,13 +167,14 @@ which makes it installable.
 Installing the package with ``pipx``
 ====================================
 
-After installing ``pipx`` as described in :ref:`installing-stand-alone-command-line-tools`, you're ready to install your project:
+After installing ``pipx`` as described in :ref:`installing-stand-alone-command-line-tools`, install your project:
 
 .. code-block:: console
 
-	$ pipx install ./greetings/
+    $ cd path/to/greetings/
+    $ pipx install .
 
-This will expose the executable script we defined as an entry point and make the command ``greet`` available to you.
+This will expose the executable script we defined as an entry point and make the command ``greet`` available.
 Let's test it:
 
 .. code-block:: console
@@ -194,14 +186,30 @@ Let's test it:
 	$ greet --gender masculine
 	Greetings, dear Mr. what's-his-name!
 
-To just run the program without installing it permanently, you could use ``pipx run``, which will create a temporary (but cached) virtual environment for it:
+To just run the program without installing it permanently, use ``pipx run``, which will create a temporary (but cached) virtual environment for it:
 
 .. code-block:: console
 
-	$ pipx run ./greetings/ --knight
+	$ pipx run --spec . greet --knight
+
+This syntax is a bit unpractical, however; as the name of the entry point we defined above does not match the package name,
+we need to state explicitly which executable script to run (even though there is only on in existence).
+
+There is, however, a more practical solution to this problem, in the form of an entry point specific to ``pipx run``.
+The same can be defined as follows in :file:`pyproject.toml`:
+
+.. code-block:: toml
+
+    [project.entry-points."pipx.run"]
+    greetings = "greetings.cli:main"
+
+
+Thanks to this entry point (which *must* match the package name), ``pipx`` will pick up the executable script as the
+default one and run it, which makes this command possible:
+
+.. code-block:: console
 
-Thanks to the entry point we defined above (which *must* match the package name), ``pipx`` will pick up the executable script as the
-default one and run it; otherwise, you'd need to specify the entry point's name explicitly with ``pipx run --spec ./greetings/ greet --knight``.
+    $ pipx run . --knight
 
 Conclusion
 ==========
@@ -211,3 +219,4 @@ meaning uploading it to a :term:`package index `, most commonly :
 
 .. _click: https://click.palletsprojects.com/
 .. _docopt: https://docopt.readthedocs.io/en/latest/
+.. _typer: https://typer.tiangolo.com/

From 2d7be49b8c179a94eb773bbc702e07df763189ce Mon Sep 17 00:00:00 2001
From: chrysle <96722107+chrysle@users.noreply.github.com>
Date: Thu, 4 Jul 2024 17:22:55 +0200
Subject: [PATCH 0725/1072] Use `typer` for command-line interface creation

---
 source/guides/creating-command-line-tools.rst | 152 +++++++-----------
 1 file changed, 61 insertions(+), 91 deletions(-)

diff --git a/source/guides/creating-command-line-tools.rst b/source/guides/creating-command-line-tools.rst
index f7c3fc74a..9f040ce7d 100644
--- a/source/guides/creating-command-line-tools.rst
+++ b/source/guides/creating-command-line-tools.rst
@@ -35,31 +35,40 @@ named after the main module:
 
 .. code-block:: python
 
-	def greet(name="", gender="", knight=False, count=1):
-	    greeting = "Greetings, dear "
-	    masculine = gender == "masculine"
-	    feminine = gender == "feminine"
-	    if gender or knight:
-	        salutation = ""
-	        if knight:
-	            salutation = "Sir "
-	        elif masculine:
-	            salutation = "Mr. "
-	        elif feminine:
-	            salutation = "Ms. "
-	        greeting += salutation
-	        if name:
-	            greeting += f"{name}!"
-	        else:
-	            pronoun = "her" if feminine else "his" if masculine or knight else "its"
-	            greeting += f"what's-{pronoun}-name!"
-	    else:
-	        if name:
-	            greeting += f"{name}!"
-	        elif not gender:
-	            greeting += "friend!"
-	    for i in range(0, count):
-	        print(greeting)
+    import typer
+    from typing_extensions import Annotated
+
+
+    def greet(
+        name: Annotated[str, typer.Argument(help="The (last, if --gender is given) name of the person to greet")] = "",
+        gender: Annotated[str, typer.Option(help="The gender of the person to greet")] = "",
+        knight: Annotated[bool, typer.Option(help="Whether the person is a knight")] = False,
+        count: Annotated[int, typer.Option(help="Number of times to greet the person")] = 1
+    ):
+        greeting = "Greetings, dear "
+        masculine = gender == "masculine"
+        feminine = gender == "feminine"
+        if gender or knight:
+            salutation = ""
+            if knight:
+                salutation = "Sir "
+            elif masculine:
+                salutation = "Mr. "
+            elif feminine:
+                salutation = "Ms. "
+            greeting += salutation
+            if name:
+                greeting += f"{name}!"
+            else:
+                pronoun = "her" if feminine else "his" if masculine or knight else "its"
+                greeting += f"what's-{pronoun}-name"
+        else:
+            if name:
+                greeting += f"{name}!"
+            elif not gender:
+                greeting += "friend!"
+        for i in range(0, count):
+            print(greeting)
 
 The above function receives several keyword arguments that determine how the greeting to output is constructed.
 Now, construct the command-line interface to provision it with the same, which is done
@@ -67,65 +76,23 @@ in :file:`cli.py`:
 
 .. code-block:: python
 
-	import argparse
-	import sys
-
-	from .greet import greet
-
-	_arg_spec = {
-	    '--name': {
-	        'metavar': 'STRING',
-	        'type': str,
-	        'help': 'The (last, if "gender" is given) name of the person to greet',
-	    },
-	    '--count': {
-	        'metavar': 'INT',
-	        'type': int,
-	        'default': 1,
-	        'help': 'Number of times to greet the person',
-	    },
-
-	}
-	_arg_spec_mutually_exclusive = {
-	    '--gender': {
-	        'metavar': 'STRING',
-	        'type': str,
-	        'help': 'The gender of the person to greet',
-	    },
-	    '--knight': {
-	        'action': 'store_true',
-	        'default': False,
-	        'help': 'Whether the person is a knight',
-	    },
-	}
-
-
-	def main():
-	    parser = argparse.ArgumentParser(
-	        description="Greet a person (semi-)formally."
-	    )
-	    group = parser.add_mutually_exclusive_group()
-	    for arg, spec in _arg_spec.items():
-	        parser.add_argument(arg, **spec)
-	    for arg, spec in _arg_spec_mutually_exclusive.items():
-	        group.add_argument(arg, **spec)
-	    parsed_args = parser.parse_args()
-	    args = {
-	        arg: value
-	        for arg, value in vars(parsed_args).items()
-	        if value is not None
-	    }
-        # Run the function with the command-line arguments as keyword arguments.
-        # A more complex setup is normally initialized at this point.
-	    greet(**args)
+    import typer
 
+    from .hello import greet
+
+
+    app = typer.Typer()
+    app.command()(greet)
 
-	if __name__ == "__main__":
-	    sys.exit(main())
 
-The command-line interface is built with :py:mod:`argparse`, a command-line parser which is included in Python's
-standard library. It is a bit rudimentary but sufficient for most needs. Another easy-to-use alternative is docopt_;
-advanced users are encouraged to make use of click_ or typer_.
+    if __name__ == "__main__":
+        app()
+
+The command-line interface is built with typer_, an easy-to-use CLI parser based on Python type hints. It provides
+auto-completion and nicely styled command-line help out of the box. Another option would be :py:mod:`argparse`,
+a command-line parser which is included in Python's standard library. It is sufficient for most needs, but requires
+a lot of code, usually in ``cli.py``, to function properly. Alternatively, docopt_ makes it possible to create CLI
+interfaces based solely on docstrings; advanced users are encouraged to make use of click_ (on which ``typer`` is based).
 
 Now, add an empty :file:`__init__.py` file, to define the project as a regular :term:`import package `.
 
@@ -135,11 +102,9 @@ so initizalize the command-line interface here:
 
 .. code-block:: python
 
-	import sys
-
 	if __name__ == "__main__":
-	    from greetings.cli import main
-	    sys.exit(main())
+	    from greetings.cli import app
+	    app()
 
 .. note::
 
@@ -151,14 +116,15 @@ so initizalize the command-line interface here:
 ``pyproject.toml``
 ------------------
 
-The project's :term:`metadata ` is placed in :term:`pyproject.toml`. The :term:`pyproject metadata keys ` and the ``[build-system]`` table may be filled in as described in :ref:`writing-pyproject-toml`.
+The project's :term:`metadata ` is placed in :term:`pyproject.toml`. The :term:`pyproject metadata keys ` and the ``[build-system]`` table may be filled in as described in :ref:`writing-pyproject-toml`, adding a dependency
+on ``typer`` (this tutorial uses version *0.12.3*).
 
 For the project to be recognised as a command-line tool, additionally a ``console_scripts`` :ref:`entry point ` (see :ref:`console_scripts`) needs to be added as a :term:`subkey `:
 
 .. code-block:: toml
 
 	[project.scripts]
-	greet = "greetings.cli:main"
+	greet = "greetings.cli:app"
 
 Now, the project's source tree is ready to be transformed into a :term:`distribution package `,
 which makes it installable.
@@ -179,14 +145,18 @@ Let's test it:
 
 .. code-block:: console
 
-	$ greet --knight --name Lancelot
+	$ greet --knight Lancelot
 	Greetings, dear Sir Lancelot!
-	$ greet --gender feminine --name Parks
+	$ greet --gender feminine Parks
 	Greetings, dear Ms. Parks!
 	$ greet --gender masculine
 	Greetings, dear Mr. what's-his-name!
 
-To just run the program without installing it permanently, use ``pipx run``, which will create a temporary (but cached) virtual environment for it:
+Since this example uses ``typer``, you could now also get an overview of the program's usage by calling it with
+the ``--help`` option, or configure completions via the ``--install-completion`` option.
+
+To just run the program without installing it permanently, use ``pipx run``, which will create a temporary
+(but cached) virtual environment for it:
 
 .. code-block:: console
 
@@ -201,7 +171,7 @@ The same can be defined as follows in :file:`pyproject.toml`:
 .. code-block:: toml
 
     [project.entry-points."pipx.run"]
-    greetings = "greetings.cli:main"
+    greetings = "greetings.cli:app"
 
 
 Thanks to this entry point (which *must* match the package name), ``pipx`` will pick up the executable script as the

From 0bdccb0898cd38058722523fead9278e4ead354e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Skytt=C3=A4?= 
Date: Mon, 15 Jul 2024 23:35:06 +0300
Subject: [PATCH 0726/1072] Spelling and grammar fixes

---
 source/specifications/direct-url-data-structure.rst       | 2 +-
 source/specifications/externally-managed-environments.rst | 2 +-
 source/specifications/simple-repository-api.rst           | 6 +++---
 source/specifications/version-specifiers.rst              | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index 231198ee8..9ec8e2e34 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -44,7 +44,7 @@ expression:
 
 Additionally, the user:password section of the URL MAY be a
 well-known, non security sensitive string. A typical example is ``git``
-in the case of an URL such as ``ssh://git@gitlab.com/user/repo``.
+in the case of a URL such as ``ssh://git@gitlab.com/user/repo``.
 
 VCS URLs
 --------
diff --git a/source/specifications/externally-managed-environments.rst b/source/specifications/externally-managed-environments.rst
index 2944eb3da..65fc14a62 100644
--- a/source/specifications/externally-managed-environments.rst
+++ b/source/specifications/externally-managed-environments.rst
@@ -205,7 +205,7 @@ virtual environment to install packages.
 
 Software distributors who have a non-Python-specific package manager
 that manages libraries in the ``sys.path`` of their Python package
-should, in general, ship a ``EXTERNALLY-MANAGED`` file in their
+should, in general, ship an ``EXTERNALLY-MANAGED`` file in their
 standard library directory. For instance, Debian may ship a file in
 ``/usr/lib/python3.9/EXTERNALLY-MANAGED`` consisting of something like
 
diff --git a/source/specifications/simple-repository-api.rst b/source/specifications/simple-repository-api.rst
index b9f87ce7b..0d65a58aa 100644
--- a/source/specifications/simple-repository-api.rst
+++ b/source/specifications/simple-repository-api.rst
@@ -360,7 +360,7 @@ spec:
 * All JSON responses will *always* be a JSON object rather than an array or other
   type.
 
-* While JSON doesn't natively support an URL type, any value that represents an
+* While JSON doesn't natively support a URL type, any value that represents an
   URL in this API may be either absolute or relative as long as they point to
   the correct location. If relative, they are relative to the current URL as if
   it were HTML.
@@ -616,7 +616,7 @@ likely just be treated the same as a ``406 Not Acceptable`` error.
 This spec **does** require that if the meta version ``latest`` is being used, the
 server **MUST** respond with the content type for the actual version that is
 contained in the response
-(i.e. A ``Accept: application/vnd.pypi.simple.latest+json`` request that returns
+(i.e. an ``Accept: application/vnd.pypi.simple.latest+json`` request that returns
 a ``v1.x`` response should have a ``Content-Type`` of
 ``application/vnd.pypi.simple.v1+json``).
 
@@ -725,7 +725,7 @@ may *optionally* be used instead.
 URL Parameter
 ^^^^^^^^^^^^^
 
-Servers that implement the Simple API may choose to support an URL parameter named
+Servers that implement the Simple API may choose to support a URL parameter named
 ``format`` to allow the clients to request a specific version of the URL.
 
 The value of the ``format`` parameter should be **one** of the valid content types.
diff --git a/source/specifications/version-specifiers.rst b/source/specifications/version-specifiers.rst
index cde0bc49a..a5ba36498 100644
--- a/source/specifications/version-specifiers.rst
+++ b/source/specifications/version-specifiers.rst
@@ -1178,7 +1178,7 @@ more information on ``file://`` URLs on Windows see
 Summary of differences from pkg_resources.parse_version
 =======================================================
 
-* Note: this comparison is to ``pkg_resourses.parse_version`` as it existed at
+* Note: this comparison is to ``pkg_resources.parse_version`` as it existed at
   the time :pep:`440` was written. After the PEP was accepted, setuptools 6.0 and
   later versions adopted the behaviour described here.
 

From 342f9eb0a597d33f9c0b0e7cd5d9192c0521e34f Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Thu, 25 Jul 2024 09:34:31 -0700
Subject: [PATCH 0727/1072] updated single_source_version with a much simpler
 page -- essentially refering folks to their build system of choice.

---
 source/single_source_version.rst | 51 ++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 source/single_source_version.rst

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
new file mode 100644
index 000000000..206ff5020
--- /dev/null
+++ b/source/single_source_version.rst
@@ -0,0 +1,51 @@
+.. _`Single sourcing the version`:
+
+===================================
+Single-sourcing the Project Version
+===================================
+
+:Page Status: Complete
+:Last Reviewed: 2015-09-08
+
+One of the challenges in building packages is that the version string can be required in multiple places.
+
+* It needs to be specified when building the package (e.g. in pyproject.toml)
+   - That will assure that it is properly assigned in the distribution file name, and in teh installed package.
+
+* Some projects require that there be a version string available as an attribute in the importable module, e.g::
+
+    import a_package
+    print(a_package.__version__)
+
+While different projects have different needs, it's important to make sure that there is a single source of truth for the version number.
+
+In general, the options are:
+
+1) If the code is in a version control system (VCS), e.g. git, then the version can be extracted from the VCS.
+
+2) The version can be hard-coded into the `pyproject.toml` file -- and the build system can copy it into other locations it may be required.
+
+3) The version string can be hard-coded into the source code -- either in a special purpose file, such as `_version.txt`, or as a attribute in the `__init__.py`, and the build system can extract it at build time.
+
+If the version string is not in the source, it can be extracted at runtime with code in `__init__.py`, such as::
+
+    import importlib.metadata
+    __version__ = importlib.metadata.version('the_distribution_name')
+
+
+Consult your build system documentation for how to implement your preferred method.
+
+Put links in to build system docs?
+-- I have no idea which are currently robust and maintained -- do we want to get into seeming endorsing particular tools in this doc?
+
+
+* setuptools:
+
+* hatch:
+
+* poetry:
+
+* PyBuilder:
+
+* Others?
+

From ce0d4bc9951776e01c55189868dac892b3045c56 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Thu, 25 Jul 2024 11:17:19 -0700
Subject: [PATCH 0728/1072] Update source/single_source_version.rst
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 206ff5020..766247711 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -9,7 +9,7 @@ Single-sourcing the Project Version
 
 One of the challenges in building packages is that the version string can be required in multiple places.
 
-* It needs to be specified when building the package (e.g. in pyproject.toml)
+* It needs to be specified when building the package (e.g. in :file:`pyproject.toml`)
    - That will assure that it is properly assigned in the distribution file name, and in teh installed package.
 
 * Some projects require that there be a version string available as an attribute in the importable module, e.g::

From 6cd1b9bb78a9819cab9e74bb6ca735c613e1d983 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Thu, 25 Jul 2024 11:20:08 -0700
Subject: [PATCH 0729/1072] Update source/single_source_version.rst

Co-authored-by: Thomas A Caswell 
---
 source/single_source_version.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 766247711..c075e56a9 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -16,6 +16,7 @@ One of the challenges in building packages is that the version string can be req
 
     import a_package
     print(a_package.__version__)
+* In the metadata of the artifacts for each of the packaging ecosystems    
 
 While different projects have different needs, it's important to make sure that there is a single source of truth for the version number.
 

From dbac2356e9d71ee70dc8f3813d44370e0dbffd45 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Thu, 25 Jul 2024 14:51:07 -0700
Subject: [PATCH 0730/1072] Added links to build tools

---
 source/single_source_version.rst | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index c075e56a9..e307dd5a7 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -10,12 +10,13 @@ Single-sourcing the Project Version
 One of the challenges in building packages is that the version string can be required in multiple places.
 
 * It needs to be specified when building the package (e.g. in :file:`pyproject.toml`)
-   - That will assure that it is properly assigned in the distribution file name, and in teh installed package.
+   - That will assure that it is properly assigned in the distribution file name, and in the installed package.
 
 * Some projects require that there be a version string available as an attribute in the importable module, e.g::
 
     import a_package
     print(a_package.__version__)
+
 * In the metadata of the artifacts for each of the packaging ecosystems    
 
 While different projects have different needs, it's important to make sure that there is a single source of truth for the version number.
@@ -36,17 +37,15 @@ If the version string is not in the source, it can be extracted at runtime with
 
 Consult your build system documentation for how to implement your preferred method.
 
-Put links in to build system docs?
--- I have no idea which are currently robust and maintained -- do we want to get into seeming endorsing particular tools in this doc?
-
+Here are the common ones:
 
-* setuptools:
+* `Hatch `_
 
-* hatch:
+* `Setuptools `_
 
-* poetry:
+  -  `setuptools_scm `_
 
-* PyBuilder:
+* `Flit `_
 
-* Others?
+* `PDM `_
 

From 438198fafd7fccc1bf76f2fb6191e244961be1ad Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Thu, 25 Jul 2024 14:53:58 -0700
Subject: [PATCH 0731/1072] swap prefer for require

---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index e307dd5a7..46954a8e2 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -12,7 +12,7 @@ One of the challenges in building packages is that the version string can be req
 * It needs to be specified when building the package (e.g. in :file:`pyproject.toml`)
    - That will assure that it is properly assigned in the distribution file name, and in the installed package.
 
-* Some projects require that there be a version string available as an attribute in the importable module, e.g::
+* Some projects prefer that there be a version string available as an attribute in the importable module, e.g::
 
     import a_package
     print(a_package.__version__)

From 51e2c23fa69792d318e388bdf96cbb8c00eafa65 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Thu, 25 Jul 2024 15:11:36 -0700
Subject: [PATCH 0732/1072] replace text about __version__

---
 source/single_source_version.rst | 22 +++++++++-------------
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 46954a8e2..8a2eb5cf8 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -9,15 +9,13 @@ Single-sourcing the Project Version
 
 One of the challenges in building packages is that the version string can be required in multiple places.
 
-* It needs to be specified when building the package (e.g. in :file:`pyproject.toml`)
+* It needs to be specified when building the package (e.g. in :file:``pyproject.toml``)
    - That will assure that it is properly assigned in the distribution file name, and in the installed package.
 
-* Some projects prefer that there be a version string available as an attribute in the importable module, e.g::
+* A package may, if the maintainers think it useful, to be able to determine the version of the package from Python code without relying on a package manager's metadata, set a top level ``__version__`` attribute.
+The value of ``__version__`` attribute and that passed to the build system can (and should) be kept in sync in :ref:`the build systems's recommended way `.
 
-    import a_package
-    print(a_package.__version__)
-
-* In the metadata of the artifacts for each of the packaging ecosystems    
+Should a package not set a top level ``__version__`` attribute, the version can still be accessed using ``importlib.metadata.version("distribution_name")``.
 
 While different projects have different needs, it's important to make sure that there is a single source of truth for the version number.
 
@@ -27,17 +25,15 @@ In general, the options are:
 
 2) The version can be hard-coded into the `pyproject.toml` file -- and the build system can copy it into other locations it may be required.
 
-3) The version string can be hard-coded into the source code -- either in a special purpose file, such as `_version.txt`, or as a attribute in the `__init__.py`, and the build system can extract it at build time.
-
-If the version string is not in the source, it can be extracted at runtime with code in `__init__.py`, such as::
-
-    import importlib.metadata
-    __version__ = importlib.metadata.version('the_distribution_name')
+3) The version string can be hard-coded into the source code -- either in a special purpose file, such as ``_version.txt``, or as a attribute in the ``__init__.py``, and the build system can extract it at build time.
 
 
 Consult your build system documentation for how to implement your preferred method.
 
-Here are the common ones:
+.. _how_to_set_version_links:
+
+Build System Version Handling
+----------------------------
 
 * `Hatch `_
 

From 6d4aeb3b602f5987843cec7db024a725364f1ed9 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Fri, 26 Jul 2024 09:39:32 -0700
Subject: [PATCH 0733/1072] Update source/single_source_version.rst
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Brénainn Woodsend 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 8a2eb5cf8..2f5f0bc60 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -28,7 +28,7 @@ In general, the options are:
 3) The version string can be hard-coded into the source code -- either in a special purpose file, such as ``_version.txt``, or as a attribute in the ``__init__.py``, and the build system can extract it at build time.
 
 
-Consult your build system documentation for how to implement your preferred method.
+Consult your build system's documentation for their recommended method.
 
 .. _how_to_set_version_links:
 

From 49e743d1b91866b7ab22677ae88c87dfc7a362c5 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Fri, 26 Jul 2024 10:01:56 -0700
Subject: [PATCH 0734/1072] Update source/single_source_version.rst

Co-authored-by: Thomas A Caswell 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 2f5f0bc60..431b8ec62 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -15,7 +15,7 @@ One of the challenges in building packages is that the version string can be req
 * A package may, if the maintainers think it useful, to be able to determine the version of the package from Python code without relying on a package manager's metadata, set a top level ``__version__`` attribute.
 The value of ``__version__`` attribute and that passed to the build system can (and should) be kept in sync in :ref:`the build systems's recommended way `.
 
-Should a package not set a top level ``__version__`` attribute, the version can still be accessed using ``importlib.metadata.version("distribution_name")``.
+In the cases where a package does not set a top level ``__version__`` attribute, the version may still be accessible using ``importlib.metadata.version("distribution_name")``.
 
 While different projects have different needs, it's important to make sure that there is a single source of truth for the version number.
 

From 0598c698d133c4679d2535907119f82eb66c0f00 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Fri, 26 Jul 2024 10:02:18 -0700
Subject: [PATCH 0735/1072] Update source/single_source_version.rst

Co-authored-by: Thomas A Caswell 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 431b8ec62..ac5c62445 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -17,7 +17,7 @@ The value of ``__version__`` attribute and that passed to the build system can (
 
 In the cases where a package does not set a top level ``__version__`` attribute, the version may still be accessible using ``importlib.metadata.version("distribution_name")``.
 
-While different projects have different needs, it's important to make sure that there is a single source of truth for the version number.
+To ensure that version numbers do not get out of sync, it is recommended that there is a single source of truth for the version number.
 
 In general, the options are:
 

From 2a3249985cc35c9ed6f5b632cb2071bf804bdbd7 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Fri, 26 Jul 2024 10:31:38 -0700
Subject: [PATCH 0736/1072] updated the __version__ description

---
 source/single_source_version.rst | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index ac5c62445..682ab8d22 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -12,8 +12,7 @@ One of the challenges in building packages is that the version string can be req
 * It needs to be specified when building the package (e.g. in :file:``pyproject.toml``)
    - That will assure that it is properly assigned in the distribution file name, and in the installed package.
 
-* A package may, if the maintainers think it useful, to be able to determine the version of the package from Python code without relying on a package manager's metadata, set a top level ``__version__`` attribute.
-The value of ``__version__`` attribute and that passed to the build system can (and should) be kept in sync in :ref:`the build systems's recommended way `.
+* A package may set a top level ``__version__`` attribute to provide runtime access to the version of the installed package. If this is done, the value of ``__version__`` attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way `.
 
 In the cases where a package does not set a top level ``__version__`` attribute, the version may still be accessible using ``importlib.metadata.version("distribution_name")``.
 

From d1cbce9c0d6acb5caeee8d59811c4b96cfebe652 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Tue, 30 Jul 2024 13:08:40 -0700
Subject: [PATCH 0737/1072] a few suggestions from the PR discussion

---
 source/single_source_version.rst | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 682ab8d22..63bc3f870 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -5,7 +5,7 @@ Single-sourcing the Project Version
 ===================================
 
 :Page Status: Complete
-:Last Reviewed: 2015-09-08
+:Last Reviewed: 2024-??
 
 One of the challenges in building packages is that the version string can be required in multiple places.
 
@@ -34,13 +34,15 @@ Consult your build system's documentation for their recommended method.
 Build System Version Handling
 ----------------------------
 
-* `Hatch `_
+* `Flit `_
+
+* `Hatchling `_
+
+* `PDM `_
 
 * `Setuptools `_
 
   -  `setuptools_scm `_
 
-* `Flit `_
 
-* `PDM `_
 

From 0fc5aca7f34220df01f482412dd59d89371877ff Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Tue, 30 Jul 2024 11:14:57 -0700
Subject: [PATCH 0738/1072] Update source/single_source_version.rst
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 63bc3f870..866073ab9 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -22,7 +22,7 @@ In general, the options are:
 
 1) If the code is in a version control system (VCS), e.g. git, then the version can be extracted from the VCS.
 
-2) The version can be hard-coded into the `pyproject.toml` file -- and the build system can copy it into other locations it may be required.
+2) The version can be hard-coded into the :file:`pyproject.toml` file -- and the build system can copy it into other locations it may be required.
 
 3) The version string can be hard-coded into the source code -- either in a special purpose file, such as ``_version.txt``, or as a attribute in the ``__init__.py``, and the build system can extract it at build time.
 

From 7d60695531dc8adbe65f42cd27d36bd3a988c9cb Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Tue, 30 Jul 2024 11:15:18 -0700
Subject: [PATCH 0739/1072] Update source/single_source_version.rst
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 866073ab9..0fa7488c7 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -10,7 +10,7 @@ Single-sourcing the Project Version
 One of the challenges in building packages is that the version string can be required in multiple places.
 
 * It needs to be specified when building the package (e.g. in :file:``pyproject.toml``)
-   - That will assure that it is properly assigned in the distribution file name, and in the installed package.
+   - That will assure that it is properly assigned in the distribution file name, and in the installed package metadata.
 
 * A package may set a top level ``__version__`` attribute to provide runtime access to the version of the installed package. If this is done, the value of ``__version__`` attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way `.
 

From 28c8bcbd0e05edc8c728750327b81d3f0f356827 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Tue, 30 Jul 2024 11:59:12 -0700
Subject: [PATCH 0740/1072] Update source/single_source_version.rst
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 0fa7488c7..a77183a27 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -9,7 +9,7 @@ Single-sourcing the Project Version
 
 One of the challenges in building packages is that the version string can be required in multiple places.
 
-* It needs to be specified when building the package (e.g. in :file:``pyproject.toml``)
+* It needs to be specified when building the package (e.g. in :file:`pyproject.toml`)
    - That will assure that it is properly assigned in the distribution file name, and in the installed package metadata.
 
 * A package may set a top level ``__version__`` attribute to provide runtime access to the version of the installed package. If this is done, the value of ``__version__`` attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way `.

From 00d86455f7cacd33ebf3798e6973d0b1b8ee4246 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Tue, 30 Jul 2024 11:59:28 -0700
Subject: [PATCH 0741/1072] Update source/single_source_version.rst
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index a77183a27..0e5034b5d 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -24,7 +24,7 @@ In general, the options are:
 
 2) The version can be hard-coded into the :file:`pyproject.toml` file -- and the build system can copy it into other locations it may be required.
 
-3) The version string can be hard-coded into the source code -- either in a special purpose file, such as ``_version.txt``, or as a attribute in the ``__init__.py``, and the build system can extract it at build time.
+3) The version string can be hard-coded into the source code -- either in a special purpose file, such as :file:`_version.txt`, or as a attribute in the :file:`__init__.py`, and the build system can extract it at build time.
 
 
 Consult your build system's documentation for their recommended method.

From 50a588f3b8ba35be43fb5090f436bd71d45d9de8 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Tue, 30 Jul 2024 12:15:02 -0700
Subject: [PATCH 0742/1072] Update source/single_source_version.rst
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 0e5034b5d..974a09a68 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -20,7 +20,7 @@ To ensure that version numbers do not get out of sync, it is recommended that th
 
 In general, the options are:
 
-1) If the code is in a version control system (VCS), e.g. git, then the version can be extracted from the VCS.
+1) If the code is in a version control system (VCS), e.g. Git, then the version can be extracted from the VCS.
 
 2) The version can be hard-coded into the :file:`pyproject.toml` file -- and the build system can copy it into other locations it may be required.
 

From db4e9884b67e10e9f08aac7955c41d7116650bc9 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Tue, 30 Jul 2024 13:13:49 -0700
Subject: [PATCH 0743/1072] minor formatting edit

---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 974a09a68..28d963858 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -32,7 +32,7 @@ Consult your build system's documentation for their recommended method.
 .. _how_to_set_version_links:
 
 Build System Version Handling
-----------------------------
+-----------------------------
 
 * `Flit `_
 

From 83c7f246e1889b5156d8ff1fd95f375ab0fa727e Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Wed, 31 Jul 2024 15:04:58 -0700
Subject: [PATCH 0744/1072] Update source/single_source_version.rst

Co-authored-by: Thomas A Caswell 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 28d963858..0a3c234be 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -12,7 +12,7 @@ One of the challenges in building packages is that the version string can be req
 * It needs to be specified when building the package (e.g. in :file:`pyproject.toml`)
    - That will assure that it is properly assigned in the distribution file name, and in the installed package metadata.
 
-* A package may set a top level ``__version__`` attribute to provide runtime access to the version of the installed package. If this is done, the value of ``__version__`` attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way `.
+* A package may set a top level ``__version__`` attribute to provide runtime access to the version of the imported package. If this is done, the value of ``__version__`` attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way `.
 
 In the cases where a package does not set a top level ``__version__`` attribute, the version may still be accessible using ``importlib.metadata.version("distribution_name")``.
 

From a1df94c25b95c482a5b9a62b5b6e632eff12fe85 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Wed, 31 Jul 2024 15:25:49 -0700
Subject: [PATCH 0745/1072] a few more edits from the PR comments, and adding
 it back to the index (in the right place?)

---
 source/single_source_version.rst | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 0a3c234be..3eea6af50 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -12,9 +12,9 @@ One of the challenges in building packages is that the version string can be req
 * It needs to be specified when building the package (e.g. in :file:`pyproject.toml`)
    - That will assure that it is properly assigned in the distribution file name, and in the installed package metadata.
 
-* A package may set a top level ``__version__`` attribute to provide runtime access to the version of the imported package. If this is done, the value of ``__version__`` attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way `.
+* A package may set a top level ``__version__`` attribute to provide runtime access to the version of the imported package. If this is done, the value of ``__version__`` attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way `.
 
-In the cases where a package does not set a top level ``__version__`` attribute, the version may still be accessible using ``importlib.metadata.version("distribution_name")``.
+In any case, The installed distribution version should be accessible using ``importlib.metadata.version("distribution_name")``.
 
 To ensure that version numbers do not get out of sync, it is recommended that there is a single source of truth for the version number.
 
@@ -29,11 +29,13 @@ In general, the options are:
 
 Consult your build system's documentation for their recommended method.
 
-.. _how_to_set_version_links:
+.. _Build system version handling:
 
 Build System Version Handling
 -----------------------------
 
+The following are links to some build system's documentation for handling version strings.
+
 * `Flit `_
 
 * `Hatchling `_

From ba32cc627044665cccab4d3fe0ac30bf716ac85c Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Wed, 31 Jul 2024 16:58:17 -0700
Subject: [PATCH 0746/1072] added single_source page back in -- not sure if
 it's the right section.

---
 source/discussions/index.rst                       | 1 +
 source/{ => discussions}/single_source_version.rst | 0
 2 files changed, 1 insertion(+)
 rename source/{ => discussions}/single_source_version.rst (100%)

diff --git a/source/discussions/index.rst b/source/discussions/index.rst
index bc1154507..907b61403 100644
--- a/source/discussions/index.rst
+++ b/source/discussions/index.rst
@@ -13,3 +13,4 @@ specific topic. If you're just trying to get stuff done, see
    install-requires-vs-requirements
    wheel-vs-egg
    src-layout-vs-flat-layout
+   single_source_version
diff --git a/source/single_source_version.rst b/source/discussions/single_source_version.rst
similarity index 100%
rename from source/single_source_version.rst
rename to source/discussions/single_source_version.rst

From 476f9160889801d91a6d1e6cf2fa6aba14070c97 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Thu, 25 Jul 2024 09:34:31 -0700
Subject: [PATCH 0747/1072] updated single_source_version with a much simpler
 page -- essentially refering folks to their build system of choice.

---
 source/single_source_version.rst | 51 ++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 source/single_source_version.rst

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
new file mode 100644
index 000000000..206ff5020
--- /dev/null
+++ b/source/single_source_version.rst
@@ -0,0 +1,51 @@
+.. _`Single sourcing the version`:
+
+===================================
+Single-sourcing the Project Version
+===================================
+
+:Page Status: Complete
+:Last Reviewed: 2015-09-08
+
+One of the challenges in building packages is that the version string can be required in multiple places.
+
+* It needs to be specified when building the package (e.g. in pyproject.toml)
+   - That will assure that it is properly assigned in the distribution file name, and in teh installed package.
+
+* Some projects require that there be a version string available as an attribute in the importable module, e.g::
+
+    import a_package
+    print(a_package.__version__)
+
+While different projects have different needs, it's important to make sure that there is a single source of truth for the version number.
+
+In general, the options are:
+
+1) If the code is in a version control system (VCS), e.g. git, then the version can be extracted from the VCS.
+
+2) The version can be hard-coded into the `pyproject.toml` file -- and the build system can copy it into other locations it may be required.
+
+3) The version string can be hard-coded into the source code -- either in a special purpose file, such as `_version.txt`, or as a attribute in the `__init__.py`, and the build system can extract it at build time.
+
+If the version string is not in the source, it can be extracted at runtime with code in `__init__.py`, such as::
+
+    import importlib.metadata
+    __version__ = importlib.metadata.version('the_distribution_name')
+
+
+Consult your build system documentation for how to implement your preferred method.
+
+Put links in to build system docs?
+-- I have no idea which are currently robust and maintained -- do we want to get into seeming endorsing particular tools in this doc?
+
+
+* setuptools:
+
+* hatch:
+
+* poetry:
+
+* PyBuilder:
+
+* Others?
+

From 0512c222a23ca9118657dc70d20e519c6840f804 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Thu, 25 Jul 2024 11:17:19 -0700
Subject: [PATCH 0748/1072] Update source/single_source_version.rst
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 206ff5020..766247711 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -9,7 +9,7 @@ Single-sourcing the Project Version
 
 One of the challenges in building packages is that the version string can be required in multiple places.
 
-* It needs to be specified when building the package (e.g. in pyproject.toml)
+* It needs to be specified when building the package (e.g. in :file:`pyproject.toml`)
    - That will assure that it is properly assigned in the distribution file name, and in teh installed package.
 
 * Some projects require that there be a version string available as an attribute in the importable module, e.g::

From 892d0454094b85fcfb09db855223a2178215143a Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Thu, 25 Jul 2024 11:20:08 -0700
Subject: [PATCH 0749/1072] Update source/single_source_version.rst

Co-authored-by: Thomas A Caswell 
---
 source/single_source_version.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 766247711..c075e56a9 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -16,6 +16,7 @@ One of the challenges in building packages is that the version string can be req
 
     import a_package
     print(a_package.__version__)
+* In the metadata of the artifacts for each of the packaging ecosystems    
 
 While different projects have different needs, it's important to make sure that there is a single source of truth for the version number.
 

From 6db49ef0cda4b869604679895024fe39f54882b7 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Thu, 25 Jul 2024 14:51:07 -0700
Subject: [PATCH 0750/1072] Added links to build tools

---
 source/single_source_version.rst | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index c075e56a9..e307dd5a7 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -10,12 +10,13 @@ Single-sourcing the Project Version
 One of the challenges in building packages is that the version string can be required in multiple places.
 
 * It needs to be specified when building the package (e.g. in :file:`pyproject.toml`)
-   - That will assure that it is properly assigned in the distribution file name, and in teh installed package.
+   - That will assure that it is properly assigned in the distribution file name, and in the installed package.
 
 * Some projects require that there be a version string available as an attribute in the importable module, e.g::
 
     import a_package
     print(a_package.__version__)
+
 * In the metadata of the artifacts for each of the packaging ecosystems    
 
 While different projects have different needs, it's important to make sure that there is a single source of truth for the version number.
@@ -36,17 +37,15 @@ If the version string is not in the source, it can be extracted at runtime with
 
 Consult your build system documentation for how to implement your preferred method.
 
-Put links in to build system docs?
--- I have no idea which are currently robust and maintained -- do we want to get into seeming endorsing particular tools in this doc?
-
+Here are the common ones:
 
-* setuptools:
+* `Hatch `_
 
-* hatch:
+* `Setuptools `_
 
-* poetry:
+  -  `setuptools_scm `_
 
-* PyBuilder:
+* `Flit `_
 
-* Others?
+* `PDM `_
 

From afa38c49a3f65d1c364021a46400ded3f4ac9b19 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Thu, 25 Jul 2024 14:53:58 -0700
Subject: [PATCH 0751/1072] swap prefer for require

---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index e307dd5a7..46954a8e2 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -12,7 +12,7 @@ One of the challenges in building packages is that the version string can be req
 * It needs to be specified when building the package (e.g. in :file:`pyproject.toml`)
    - That will assure that it is properly assigned in the distribution file name, and in the installed package.
 
-* Some projects require that there be a version string available as an attribute in the importable module, e.g::
+* Some projects prefer that there be a version string available as an attribute in the importable module, e.g::
 
     import a_package
     print(a_package.__version__)

From b9bb45d3fd7d9c6ce47fb44407f59dba3a66d1c2 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Thu, 25 Jul 2024 15:11:36 -0700
Subject: [PATCH 0752/1072] replace text about __version__

---
 source/single_source_version.rst | 22 +++++++++-------------
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 46954a8e2..8a2eb5cf8 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -9,15 +9,13 @@ Single-sourcing the Project Version
 
 One of the challenges in building packages is that the version string can be required in multiple places.
 
-* It needs to be specified when building the package (e.g. in :file:`pyproject.toml`)
+* It needs to be specified when building the package (e.g. in :file:``pyproject.toml``)
    - That will assure that it is properly assigned in the distribution file name, and in the installed package.
 
-* Some projects prefer that there be a version string available as an attribute in the importable module, e.g::
+* A package may, if the maintainers think it useful, to be able to determine the version of the package from Python code without relying on a package manager's metadata, set a top level ``__version__`` attribute.
+The value of ``__version__`` attribute and that passed to the build system can (and should) be kept in sync in :ref:`the build systems's recommended way `.
 
-    import a_package
-    print(a_package.__version__)
-
-* In the metadata of the artifacts for each of the packaging ecosystems    
+Should a package not set a top level ``__version__`` attribute, the version can still be accessed using ``importlib.metadata.version("distribution_name")``.
 
 While different projects have different needs, it's important to make sure that there is a single source of truth for the version number.
 
@@ -27,17 +25,15 @@ In general, the options are:
 
 2) The version can be hard-coded into the `pyproject.toml` file -- and the build system can copy it into other locations it may be required.
 
-3) The version string can be hard-coded into the source code -- either in a special purpose file, such as `_version.txt`, or as a attribute in the `__init__.py`, and the build system can extract it at build time.
-
-If the version string is not in the source, it can be extracted at runtime with code in `__init__.py`, such as::
-
-    import importlib.metadata
-    __version__ = importlib.metadata.version('the_distribution_name')
+3) The version string can be hard-coded into the source code -- either in a special purpose file, such as ``_version.txt``, or as a attribute in the ``__init__.py``, and the build system can extract it at build time.
 
 
 Consult your build system documentation for how to implement your preferred method.
 
-Here are the common ones:
+.. _how_to_set_version_links:
+
+Build System Version Handling
+----------------------------
 
 * `Hatch `_
 

From 635908378ba7759579afcf509d50cf9166df67b2 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Fri, 26 Jul 2024 09:39:32 -0700
Subject: [PATCH 0753/1072] Update source/single_source_version.rst
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Brénainn Woodsend 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 8a2eb5cf8..2f5f0bc60 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -28,7 +28,7 @@ In general, the options are:
 3) The version string can be hard-coded into the source code -- either in a special purpose file, such as ``_version.txt``, or as a attribute in the ``__init__.py``, and the build system can extract it at build time.
 
 
-Consult your build system documentation for how to implement your preferred method.
+Consult your build system's documentation for their recommended method.
 
 .. _how_to_set_version_links:
 

From e6b0ed9b9cc471eef860670e38f8526e617b7a2a Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Fri, 26 Jul 2024 10:01:56 -0700
Subject: [PATCH 0754/1072] Update source/single_source_version.rst

Co-authored-by: Thomas A Caswell 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 2f5f0bc60..431b8ec62 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -15,7 +15,7 @@ One of the challenges in building packages is that the version string can be req
 * A package may, if the maintainers think it useful, to be able to determine the version of the package from Python code without relying on a package manager's metadata, set a top level ``__version__`` attribute.
 The value of ``__version__`` attribute and that passed to the build system can (and should) be kept in sync in :ref:`the build systems's recommended way `.
 
-Should a package not set a top level ``__version__`` attribute, the version can still be accessed using ``importlib.metadata.version("distribution_name")``.
+In the cases where a package does not set a top level ``__version__`` attribute, the version may still be accessible using ``importlib.metadata.version("distribution_name")``.
 
 While different projects have different needs, it's important to make sure that there is a single source of truth for the version number.
 

From 54906dae953b022672c13f6645d4273326a0e22f Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Fri, 26 Jul 2024 10:02:18 -0700
Subject: [PATCH 0755/1072] Update source/single_source_version.rst

Co-authored-by: Thomas A Caswell 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 431b8ec62..ac5c62445 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -17,7 +17,7 @@ The value of ``__version__`` attribute and that passed to the build system can (
 
 In the cases where a package does not set a top level ``__version__`` attribute, the version may still be accessible using ``importlib.metadata.version("distribution_name")``.
 
-While different projects have different needs, it's important to make sure that there is a single source of truth for the version number.
+To ensure that version numbers do not get out of sync, it is recommended that there is a single source of truth for the version number.
 
 In general, the options are:
 

From 398b4fbc5d5f92d8fee80bffb8b724b90b96e4f3 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Fri, 26 Jul 2024 10:31:38 -0700
Subject: [PATCH 0756/1072] updated the __version__ description

---
 source/single_source_version.rst | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index ac5c62445..682ab8d22 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -12,8 +12,7 @@ One of the challenges in building packages is that the version string can be req
 * It needs to be specified when building the package (e.g. in :file:``pyproject.toml``)
    - That will assure that it is properly assigned in the distribution file name, and in the installed package.
 
-* A package may, if the maintainers think it useful, to be able to determine the version of the package from Python code without relying on a package manager's metadata, set a top level ``__version__`` attribute.
-The value of ``__version__`` attribute and that passed to the build system can (and should) be kept in sync in :ref:`the build systems's recommended way `.
+* A package may set a top level ``__version__`` attribute to provide runtime access to the version of the installed package. If this is done, the value of ``__version__`` attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way `.
 
 In the cases where a package does not set a top level ``__version__`` attribute, the version may still be accessible using ``importlib.metadata.version("distribution_name")``.
 

From e7d23699b39f4cffcc8a1619f375334f88a207a0 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Tue, 30 Jul 2024 13:08:40 -0700
Subject: [PATCH 0757/1072] a few suggestions from the PR discussion

---
 source/single_source_version.rst | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 682ab8d22..63bc3f870 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -5,7 +5,7 @@ Single-sourcing the Project Version
 ===================================
 
 :Page Status: Complete
-:Last Reviewed: 2015-09-08
+:Last Reviewed: 2024-??
 
 One of the challenges in building packages is that the version string can be required in multiple places.
 
@@ -34,13 +34,15 @@ Consult your build system's documentation for their recommended method.
 Build System Version Handling
 ----------------------------
 
-* `Hatch `_
+* `Flit `_
+
+* `Hatchling `_
+
+* `PDM `_
 
 * `Setuptools `_
 
   -  `setuptools_scm `_
 
-* `Flit `_
 
-* `PDM `_
 

From 0ff8c16eb5605d4350b9ae0c3c4f93e0f450dcb9 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Tue, 30 Jul 2024 11:14:57 -0700
Subject: [PATCH 0758/1072] Update source/single_source_version.rst
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 63bc3f870..866073ab9 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -22,7 +22,7 @@ In general, the options are:
 
 1) If the code is in a version control system (VCS), e.g. git, then the version can be extracted from the VCS.
 
-2) The version can be hard-coded into the `pyproject.toml` file -- and the build system can copy it into other locations it may be required.
+2) The version can be hard-coded into the :file:`pyproject.toml` file -- and the build system can copy it into other locations it may be required.
 
 3) The version string can be hard-coded into the source code -- either in a special purpose file, such as ``_version.txt``, or as a attribute in the ``__init__.py``, and the build system can extract it at build time.
 

From 8529adad95a8e095bf39736918384874306556db Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Tue, 30 Jul 2024 11:15:18 -0700
Subject: [PATCH 0759/1072] Update source/single_source_version.rst
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 866073ab9..0fa7488c7 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -10,7 +10,7 @@ Single-sourcing the Project Version
 One of the challenges in building packages is that the version string can be required in multiple places.
 
 * It needs to be specified when building the package (e.g. in :file:``pyproject.toml``)
-   - That will assure that it is properly assigned in the distribution file name, and in the installed package.
+   - That will assure that it is properly assigned in the distribution file name, and in the installed package metadata.
 
 * A package may set a top level ``__version__`` attribute to provide runtime access to the version of the installed package. If this is done, the value of ``__version__`` attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way `.
 

From 840474d649b870236722c9bf72e1341a3b9eaee8 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Tue, 30 Jul 2024 11:59:12 -0700
Subject: [PATCH 0760/1072] Update source/single_source_version.rst
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 0fa7488c7..a77183a27 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -9,7 +9,7 @@ Single-sourcing the Project Version
 
 One of the challenges in building packages is that the version string can be required in multiple places.
 
-* It needs to be specified when building the package (e.g. in :file:``pyproject.toml``)
+* It needs to be specified when building the package (e.g. in :file:`pyproject.toml`)
    - That will assure that it is properly assigned in the distribution file name, and in the installed package metadata.
 
 * A package may set a top level ``__version__`` attribute to provide runtime access to the version of the installed package. If this is done, the value of ``__version__`` attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way `.

From 61dc0b8a1bdffd1f5700126ffab11d4b772f9975 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Tue, 30 Jul 2024 11:59:28 -0700
Subject: [PATCH 0761/1072] Update source/single_source_version.rst
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index a77183a27..0e5034b5d 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -24,7 +24,7 @@ In general, the options are:
 
 2) The version can be hard-coded into the :file:`pyproject.toml` file -- and the build system can copy it into other locations it may be required.
 
-3) The version string can be hard-coded into the source code -- either in a special purpose file, such as ``_version.txt``, or as a attribute in the ``__init__.py``, and the build system can extract it at build time.
+3) The version string can be hard-coded into the source code -- either in a special purpose file, such as :file:`_version.txt`, or as a attribute in the :file:`__init__.py`, and the build system can extract it at build time.
 
 
 Consult your build system's documentation for their recommended method.

From f93293500062f2b1a86923b1132ea344052dad02 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Tue, 30 Jul 2024 12:15:02 -0700
Subject: [PATCH 0762/1072] Update source/single_source_version.rst
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 0e5034b5d..974a09a68 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -20,7 +20,7 @@ To ensure that version numbers do not get out of sync, it is recommended that th
 
 In general, the options are:
 
-1) If the code is in a version control system (VCS), e.g. git, then the version can be extracted from the VCS.
+1) If the code is in a version control system (VCS), e.g. Git, then the version can be extracted from the VCS.
 
 2) The version can be hard-coded into the :file:`pyproject.toml` file -- and the build system can copy it into other locations it may be required.
 

From ae2ad095a85cebe23395e7554fa5ec47a42a28a8 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Tue, 30 Jul 2024 13:13:49 -0700
Subject: [PATCH 0763/1072] minor formatting edit

---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 974a09a68..28d963858 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -32,7 +32,7 @@ Consult your build system's documentation for their recommended method.
 .. _how_to_set_version_links:
 
 Build System Version Handling
-----------------------------
+-----------------------------
 
 * `Flit `_
 

From 01f66a96054e5164a766238705d7fac3eb1d381b Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Wed, 31 Jul 2024 15:04:58 -0700
Subject: [PATCH 0764/1072] Update source/single_source_version.rst

Co-authored-by: Thomas A Caswell 
---
 source/single_source_version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 28d963858..0a3c234be 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -12,7 +12,7 @@ One of the challenges in building packages is that the version string can be req
 * It needs to be specified when building the package (e.g. in :file:`pyproject.toml`)
    - That will assure that it is properly assigned in the distribution file name, and in the installed package metadata.
 
-* A package may set a top level ``__version__`` attribute to provide runtime access to the version of the installed package. If this is done, the value of ``__version__`` attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way `.
+* A package may set a top level ``__version__`` attribute to provide runtime access to the version of the imported package. If this is done, the value of ``__version__`` attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way `.
 
 In the cases where a package does not set a top level ``__version__`` attribute, the version may still be accessible using ``importlib.metadata.version("distribution_name")``.
 

From 9d353a75cc6b3b4171ca5dda95fb2e59a85afa64 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Wed, 31 Jul 2024 15:25:49 -0700
Subject: [PATCH 0765/1072] a few more edits from the PR comments, and adding
 it back to the index (in the right place?)

---
 source/single_source_version.rst | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/source/single_source_version.rst b/source/single_source_version.rst
index 0a3c234be..3eea6af50 100644
--- a/source/single_source_version.rst
+++ b/source/single_source_version.rst
@@ -12,9 +12,9 @@ One of the challenges in building packages is that the version string can be req
 * It needs to be specified when building the package (e.g. in :file:`pyproject.toml`)
    - That will assure that it is properly assigned in the distribution file name, and in the installed package metadata.
 
-* A package may set a top level ``__version__`` attribute to provide runtime access to the version of the imported package. If this is done, the value of ``__version__`` attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way `.
+* A package may set a top level ``__version__`` attribute to provide runtime access to the version of the imported package. If this is done, the value of ``__version__`` attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way `.
 
-In the cases where a package does not set a top level ``__version__`` attribute, the version may still be accessible using ``importlib.metadata.version("distribution_name")``.
+In any case, The installed distribution version should be accessible using ``importlib.metadata.version("distribution_name")``.
 
 To ensure that version numbers do not get out of sync, it is recommended that there is a single source of truth for the version number.
 
@@ -29,11 +29,13 @@ In general, the options are:
 
 Consult your build system's documentation for their recommended method.
 
-.. _how_to_set_version_links:
+.. _Build system version handling:
 
 Build System Version Handling
 -----------------------------
 
+The following are links to some build system's documentation for handling version strings.
+
 * `Flit `_
 
 * `Hatchling `_

From 1aae700cd7adf7e2c387c1af9ca0b25ad7c3bb16 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Wed, 31 Jul 2024 16:58:17 -0700
Subject: [PATCH 0766/1072] added single_source page back in -- not sure if
 it's the right section.

---
 source/discussions/index.rst                       | 1 +
 source/{ => discussions}/single_source_version.rst | 0
 2 files changed, 1 insertion(+)
 rename source/{ => discussions}/single_source_version.rst (100%)

diff --git a/source/discussions/index.rst b/source/discussions/index.rst
index d262bcff2..531e5c126 100644
--- a/source/discussions/index.rst
+++ b/source/discussions/index.rst
@@ -16,3 +16,4 @@ specific topic. If you're just trying to get stuff done, see
    package-formats
    src-layout-vs-flat-layout
    setup-py-deprecated
+   single_source_version
diff --git a/source/single_source_version.rst b/source/discussions/single_source_version.rst
similarity index 100%
rename from source/single_source_version.rst
rename to source/discussions/single_source_version.rst

From f130e816f962320ba847efc43c0221477a0c923d Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Thu, 1 Aug 2024 00:21:18 +0000
Subject: [PATCH 0767/1072] [pre-commit.ci] auto fixes from pre-commit.com
 hooks

for more information, see https://pre-commit.ci
---
 source/discussions/single_source_version.rst | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/source/discussions/single_source_version.rst b/source/discussions/single_source_version.rst
index 3eea6af50..5fbb89b00 100644
--- a/source/discussions/single_source_version.rst
+++ b/source/discussions/single_source_version.rst
@@ -45,6 +45,3 @@ The following are links to some build system's documentation for handling versio
 * `Setuptools `_
 
   -  `setuptools_scm `_
-
-
-

From 5b40e9c6745650c86facb37c1b6eca9aec181178 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Wed, 31 Jul 2024 17:40:25 -0700
Subject: [PATCH 0768/1072] updated notes on conda.

---
 source/key_projects.rst | 40 ++++++++++++++++++++++------------------
 1 file changed, 22 insertions(+), 18 deletions(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index 531c28066..6c8e5d16a 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -404,26 +404,30 @@ conda
 
 :doc:`Docs `
 
-conda is the package management tool for `Anaconda
-`__ Python installations.
-Anaconda Python is a distribution from `Anaconda, Inc
-`__ specifically aimed at the scientific
-community, and in particular on Windows where the installation of binary
-extensions is often difficult.
+Conda is a package, dependency, and environment management system for any language — Python, R,
+Ruby, C/C++, Fortran, and more. It is written in Python and
+widely used in the Python scientific computing community, due to its support for non-Python
+compiled libraries and extensions. It is used as the basis of the `Anaconda
+`__ Python distribution from `Anaconda, Inc.specifically
+aimed at the scientific community, community, but can also be used on its own, or with the
+:doc:`miniconda `, `miniforge `_ or
+`pixi `_ systems. It is available for Windows, Mac and Linux systems.
 
 Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides
-many of their combined features in terms of package management, virtual environment
-management and deployment of binary extensions.
-
-Conda does not install packages from PyPI and can install only from
-the official Anaconda repositories, or anaconda.org (a place for
-user-contributed *conda* packages), or a local (e.g. intranet) package
-server.  However, note that :ref:`pip` can be installed into, and work
-side-by-side with conda for managing :term:`distributions
-` from PyPI. Also, `conda skeleton
-`__
-is a tool to make Python packages installable by conda by first
-fetching them from PyPI and modifying their metadata.
+many of their combined features, such as package management, virtual environment
+management and deployment of binary extensions and other binary code.
+
+Conda does not install packages from PyPI -- it can only manage packages built specifically
+for conda, which can be made available on a "conda channel", such as those hosted on
+`anaconda.org `__ or a local (e.g. intranet) package server.
+In addition to the "default" channels managed by `Anaconda, Inc. `__, there are a wide variety of packages from the community supported
+`conda-forge project `__
+
+Note that :ref:`pip` can be installed into, and work side-by-side with conda
+for managing :term:`distributions ` from PyPI. It is also possible
+to build conda packages from Python source packages using tools such as
+`conda skeleton
+`__: a tool to automatically make conda packages from Python packages available on PyPI.
 
 .. _devpi:
 

From 934e11b5fda9dafaad0cb1c3c3a4ae9db1b2ecc6 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Wed, 31 Jul 2024 17:53:50 -0700
Subject: [PATCH 0769/1072] added updated conda info to the scientific packages
 page.

---
 source/guides/installing-scientific-packages.rst | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst
index 5677d382a..654db3d62 100644
--- a/source/guides/installing-scientific-packages.rst
+++ b/source/guides/installing-scientific-packages.rst
@@ -134,5 +134,10 @@ native virtual environments. Conda makes environments first-class citizens,
 making it easy to create independent environments even for C libraries. It is
 written in Python, but is Python-agnostic. Conda manages Python itself as a
 package, so that :command:`conda update python` is possible, in contrast to
-pip, which only manages Python packages. Conda is available in Anaconda and
-Miniconda (an easy-to-install download with just Python and conda).
+pip, which only manages Python packages.
+
+The conda package manager is available in `Anaconda `_, `miniconda `_, `miniforge `_, and `pixi `_.
+
+Conda packages are available on multiple channels on Anaconda.org, including the
+default channel supported by Anaconda, Inc, and the community supported conda-forge
+channel, which provides a wide variety of pre-built packages.

From a08ca8023c0ecb924edb26098ea753b7c7cbb416 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Skytt=C3=A4?= 
Date: Mon, 15 Jul 2024 23:31:13 +0300
Subject: [PATCH 0770/1072] Refer to platform tag as such in use example

There's no arch tag.
---
 source/specifications/platform-compatibility-tags.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 381b84ca9..740a28a1a 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -256,7 +256,7 @@ The full list of simple tags is::
 
     for x in pytag.split('.'):
         for y in abitag.split('.'):
-            for z in archtag.split('.'):
+            for z in platformtag.split('.'):
                 yield '-'.join((x, y, z))
 
 A bdist format that implements this scheme should include the expanded

From 3d9aced31ab5cf68777fd57dea7a3d22ddc7d84d Mon Sep 17 00:00:00 2001
From: Alyssa Coghlan 
Date: Thu, 8 Aug 2024 18:25:00 +1000
Subject: [PATCH 0771/1072] Add Direct URL security heading

No changes to the spec, just adding a heading to
highlight the notes on avoiding credential leaks.
---
 source/specifications/direct-url-data-structure.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index 9ec8e2e34..6a4e8fe01 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -31,6 +31,9 @@ Depending on what ``url`` refers to, the second field MUST be one of ``vcs_info`
 local directory). These info fields have a (possibly empty) subdictionary as
 value, with the possible keys defined below.
 
+Security Considerations
+-----------------------
+
 When persisted, ``url`` MUST be stripped of any sensitive authentication information,
 for security reasons.
 

From c6a145509b9acc17121bb619ef7265d12bf3b4a7 Mon Sep 17 00:00:00 2001
From: "Eden Ross Duff, MSc" 
Date: Sun, 11 Aug 2024 21:42:12 -0500
Subject: [PATCH 0772/1072] clarify ``Provides-Dist`` example to match
 warehouse wheel metadata validation

---
 source/specifications/core-metadata.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 90793c791..fb6570fbb 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -725,7 +725,7 @@ This field may be followed by an environment marker after a semicolon.
 Examples::
 
     Provides-Dist: OtherProject
-    Provides-Dist: AnotherProject (3.4)
+    Provides-Dist: AnotherProject==3.4
     Provides-Dist: virtual_package; python_version >= "3.4"
 
 .. _core-metadata-obsoletes-dist:

From e9713306df7753e9fe7397ff559cbbcb9d4cae00 Mon Sep 17 00:00:00 2001
From: Stephen Nixon <45946693+arrowtype@users.noreply.github.com>
Date: Fri, 16 Aug 2024 22:48:58 -0400
Subject: [PATCH 0773/1072] Update creating-command-line-tools.rst to fix typo
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The import statement, as written, fails. It doesn’t match the name of the file that is set up with the greet() function.
---
 source/guides/creating-command-line-tools.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/creating-command-line-tools.rst b/source/guides/creating-command-line-tools.rst
index 9f040ce7d..49ce0c9ed 100644
--- a/source/guides/creating-command-line-tools.rst
+++ b/source/guides/creating-command-line-tools.rst
@@ -78,7 +78,7 @@ in :file:`cli.py`:
 
     import typer
 
-    from .hello import greet
+    from .greet import greet
 
 
     app = typer.Typer()

From c864782b753b81e88fe55e586566d28bbf5e9543 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Mon, 19 Aug 2024 17:06:58 -0400
Subject: [PATCH 0774/1072] Update source/key_projects.rst

Co-authored-by: Alyssa Coghlan 
---
 source/key_projects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index 6c8e5d16a..7af8996a2 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -408,7 +408,7 @@ Conda is a package, dependency, and environment management system for any langua
 Ruby, C/C++, Fortran, and more. It is written in Python and
 widely used in the Python scientific computing community, due to its support for non-Python
 compiled libraries and extensions. It is used as the basis of the `Anaconda
-`__ Python distribution from `Anaconda, Inc.specifically
+`__ Python distribution from Anaconda, Inc. It waas originally
 aimed at the scientific community, community, but can also be used on its own, or with the
 :doc:`miniconda `, `miniforge `_ or
 `pixi `_ systems. It is available for Windows, Mac and Linux systems.

From 049603c58dab76dcb44b6f6226d934dfa3d84032 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Mon, 19 Aug 2024 17:07:45 -0400
Subject: [PATCH 0775/1072] Update source/key_projects.rst

Co-authored-by: Alyssa Coghlan 
---
 source/key_projects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index 7af8996a2..67bac3a54 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -409,7 +409,7 @@ Ruby, C/C++, Fortran, and more. It is written in Python and
 widely used in the Python scientific computing community, due to its support for non-Python
 compiled libraries and extensions. It is used as the basis of the `Anaconda
 `__ Python distribution from Anaconda, Inc. It waas originally
-aimed at the scientific community, community, but can also be used on its own, or with the
+aimed at the scientific community, but can also be used on its own, or with the
 :doc:`miniconda `, `miniforge `_ or
 `pixi `_ systems. It is available for Windows, Mac and Linux systems.
 

From e0c0e7ae3c627437e8430a2743ac71798768cca9 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Mon, 19 Aug 2024 17:08:09 -0400
Subject: [PATCH 0776/1072] Update source/key_projects.rst

Co-authored-by: Alyssa Coghlan 
---
 source/key_projects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index 67bac3a54..d8312e327 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -419,7 +419,7 @@ management and deployment of binary extensions and other binary code.
 
 Conda does not install packages from PyPI -- it can only manage packages built specifically
 for conda, which can be made available on a "conda channel", such as those hosted on
-`anaconda.org `__ or a local (e.g. intranet) package server.
+`anaconda.org `__, or a local (e.g. intranet) package server.
 In addition to the "default" channels managed by `Anaconda, Inc. `__, there are a wide variety of packages from the community supported
 `conda-forge project `__
 

From f62b5b5b51a6927dc6bf26627b35735dd351d9fd Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Mon, 19 Aug 2024 17:20:23 -0400
Subject: [PATCH 0777/1072] reworked intro paragraph to address duplicate
 links, and cleaner entry into conda vs. Anaconda.

---
 .../guides/installing-scientific-packages.rst | 20 ++++++++-----------
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst
index 654db3d62..2d3e99920 100644
--- a/source/guides/installing-scientific-packages.rst
+++ b/source/guides/installing-scientific-packages.rst
@@ -14,7 +14,7 @@ In particular, `NumPy `__, which provides the basis
 for most of the software in the `scientific Python stack
 `_ can be configured
 to interoperate with different FORTRAN libraries, and can take advantage
-of different levels of vectorised instructions available in modern CPUs.
+of different levels of vectorized instructions available in modern CPUs.
 
 Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built
 32-bit and 64-bit binaries in the ``wheel`` format are available for all major
@@ -118,17 +118,11 @@ be loaded and unloaded from the user's environment.
 The conda cross-platform package manager
 ----------------------------------------
 
-`Anaconda `_ is a Python distribution
-published by Anaconda, Inc. It is a stable collection of Open Source
-packages for big data and scientific use.  As of the 5.0 release of Anaconda,
-about 200 packages are installed by default, and a total of 400-500 can be
-installed and updated from the Anaconda repository.
-
 ``conda`` is an open source (BSD licensed) package management system and
-environment management system included in Anaconda that allows users to install
+environment management system that allows users to install
 multiple versions of binary software packages and their dependencies, and
 easily switch between them. It is a cross-platform tool working on Windows,
-macOS, and Linux. Conda can be used to package up and distribute all kinds of
+MacOS, and Linux. Conda can be used to package up and distribute all kinds of
 packages, it is not limited to just Python packages. It has full support for
 native virtual environments. Conda makes environments first-class citizens,
 making it easy to create independent environments even for C libraries. It is
@@ -136,8 +130,10 @@ written in Python, but is Python-agnostic. Conda manages Python itself as a
 package, so that :command:`conda update python` is possible, in contrast to
 pip, which only manages Python packages.
 
-The conda package manager is available in `Anaconda `_, `miniconda `_, `miniforge `_, and `pixi `_.
+Anaconda `Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use, and a collection of Graphical Interface utilities for managing conda environments.
+
+In addition to the full distribution provided by Anaconda, the conda package manager itself is available in  `miniconda `_, `miniforge `_, and `pixi `_.
+
 
 Conda packages are available on multiple channels on Anaconda.org, including the
-default channel supported by Anaconda, Inc, and the community supported conda-forge
-channel, which provides a wide variety of pre-built packages.
+default channel supported by Anaconda, Inc, the community supported conda-forge channel, which provides a wide variety of pre-built packages, and some domain-specific package collections.

From fd59cbedc028170f531d2b5c68f131c7154bf6b6 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Mon, 19 Aug 2024 17:24:01 -0400
Subject: [PATCH 0778/1072] Update source/key_projects.rst

Co-authored-by: sinoroc <5529267+sinoroc@users.noreply.github.com>
---
 source/key_projects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index d8312e327..315897593 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -408,7 +408,7 @@ Conda is a package, dependency, and environment management system for any langua
 Ruby, C/C++, Fortran, and more. It is written in Python and
 widely used in the Python scientific computing community, due to its support for non-Python
 compiled libraries and extensions. It is used as the basis of the `Anaconda
-`__ Python distribution from Anaconda, Inc. It waas originally
+`__ Python distribution from Anaconda, Inc. It was originally
 aimed at the scientific community, but can also be used on its own, or with the
 :doc:`miniconda `, `miniforge `_ or
 `pixi `_ systems. It is available for Windows, Mac and Linux systems.

From e3e561f475a05a4fd5175d13082ca2dc0e1abee0 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Mon, 19 Aug 2024 17:27:57 -0400
Subject: [PATCH 0779/1072] fixed netlib link

---
 source/guides/installing-scientific-packages.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst
index 2d3e99920..eded4fa5b 100644
--- a/source/guides/installing-scientific-packages.rst
+++ b/source/guides/installing-scientific-packages.rst
@@ -20,7 +20,7 @@ Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built
 32-bit and 64-bit binaries in the ``wheel`` format are available for all major
 operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on
 Windows, NumPy binaries are linked against the `ATLAS
-`__ BLAS/LAPACK library, restricted to SSE2
+`__ BLAS/LAPACK library, restricted to SSE2
 instructions, so they may not provide optimal linear algebra performance.
 
 There are a number of alternative options for obtaining scientific Python

From bf026f9978ada745dac68b658f31382cf3f1aab3 Mon Sep 17 00:00:00 2001
From: hutcho 
Date: Tue, 20 Aug 2024 16:40:15 +1000
Subject: [PATCH 0780/1072] Clarified note on [build-system] and [project]

Used clearer wording, instead of referring to tables as 'former' and 'latter'.
Grammar cleanup.
---
 source/guides/writing-pyproject-toml.rst | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index 18a717a55..a705fde1e 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -22,19 +22,19 @@ three possible TOML tables in this file.
 
 .. note::
 
-   There is a significant difference between the ``[build-system]`` and
-   ``[project]`` tables. The former should always be present, regardless of
-   which build backend you use (since it *defines* the tool you use). The latter
-   is understood by *most* build backends, but some build backends use a
-   different format.
+   The ``[build-system]`` table should always be present,
+   regardless of which build backend you use (``[build-system]`` *defines* the
+   build tool you use). 
 
-   At the time of writing this (November 2023), Poetry_ is a notable build
-   backend that does not use the ``[project]`` table (it uses the
-   ``[tool.poetry]`` table instead).
+   On the other hand, the ``[project]`` table is understood by *most* build 
+   backends, but some build backends use a different format.
 
+   As of August 2024, Poetry_ is a notable build backend that does not use 
+   the ``[project]`` table, it uses the ``[tool.poetry]`` table instead. 
    Also, the setuptools_ build backend supports both the ``[project]`` table,
-   and the older format in ``setup.cfg`` or ``setup.py``. For new projects, it
-   is recommended to use the ``[project]`` table, and keep ``setup.py`` only if
+   and the older format in ``setup.cfg`` or ``setup.py``. 
+
+   For new projects, use the ``[project]`` table, and keep ``setup.py`` only if
    some programmatic configuration is needed (such as building C extensions),
    but the ``setup.cfg`` and ``setup.py`` formats are still valid. See
    :ref:`setup-py-deprecated`.

From 854030bc7c34f852c07f413afc051a8f1f685181 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Tue, 20 Aug 2024 06:42:43 +0000
Subject: [PATCH 0781/1072] [pre-commit.ci] auto fixes from pre-commit.com
 hooks

for more information, see https://pre-commit.ci
---
 source/guides/writing-pyproject-toml.rst | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index a705fde1e..d11b8a87c 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -24,15 +24,15 @@ three possible TOML tables in this file.
 
    The ``[build-system]`` table should always be present,
    regardless of which build backend you use (``[build-system]`` *defines* the
-   build tool you use). 
+   build tool you use).
 
-   On the other hand, the ``[project]`` table is understood by *most* build 
+   On the other hand, the ``[project]`` table is understood by *most* build
    backends, but some build backends use a different format.
 
-   As of August 2024, Poetry_ is a notable build backend that does not use 
-   the ``[project]`` table, it uses the ``[tool.poetry]`` table instead. 
+   As of August 2024, Poetry_ is a notable build backend that does not use
+   the ``[project]`` table, it uses the ``[tool.poetry]`` table instead.
    Also, the setuptools_ build backend supports both the ``[project]`` table,
-   and the older format in ``setup.cfg`` or ``setup.py``. 
+   and the older format in ``setup.cfg`` or ``setup.py``.
 
    For new projects, use the ``[project]`` table, and keep ``setup.py`` only if
    some programmatic configuration is needed (such as building C extensions),

From 0aefb9e6df908047a3c0323e7e488c82294e88df Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Wed, 21 Aug 2024 16:48:49 -0700
Subject: [PATCH 0782/1072] Update source/discussions/single_source_version.rst

Co-authored-by: Philipp A. 
---
 source/discussions/single_source_version.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/source/discussions/single_source_version.rst b/source/discussions/single_source_version.rst
index 5fbb89b00..f08dc19cc 100644
--- a/source/discussions/single_source_version.rst
+++ b/source/discussions/single_source_version.rst
@@ -10,11 +10,11 @@ Single-sourcing the Project Version
 One of the challenges in building packages is that the version string can be required in multiple places.
 
 * It needs to be specified when building the package (e.g. in :file:`pyproject.toml`)
-   - That will assure that it is properly assigned in the distribution file name, and in the installed package metadata.
+   This will make it available in the installed package’s metadata, from where it will be accessible at runtime using ``importlib.metadata.version("distribution_name")``.
 
-* A package may set a top level ``__version__`` attribute to provide runtime access to the version of the imported package. If this is done, the value of ``__version__`` attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way `.
+* A package may set a top level ``__version__`` attribute to provide an alternative means of runtime access to the version of the imported package. If this is done, the value of ``__version__`` attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way `.
 
-In any case, The installed distribution version should be accessible using ``importlib.metadata.version("distribution_name")``.
+* If the code is in in a version control system (VCS), e.g. Git, the version may appear in a *tag* such as ``v1.2.3``.
 
 To ensure that version numbers do not get out of sync, it is recommended that there is a single source of truth for the version number.
 

From 3b05459a595a4cbf83f6ea007436a7182a4bdd4a Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Wed, 21 Aug 2024 17:18:22 -0700
Subject: [PATCH 0783/1072] normalized the page file name

---
 source/discussions/index.rst                                    | 2 +-
 .../{single_source_version.rst => single-source-version.rst}    | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename source/discussions/{single_source_version.rst => single-source-version.rst} (100%)

diff --git a/source/discussions/index.rst b/source/discussions/index.rst
index 531e5c126..1f5ff1f2b 100644
--- a/source/discussions/index.rst
+++ b/source/discussions/index.rst
@@ -16,4 +16,4 @@ specific topic. If you're just trying to get stuff done, see
    package-formats
    src-layout-vs-flat-layout
    setup-py-deprecated
-   single_source_version
+   single-source-version
diff --git a/source/discussions/single_source_version.rst b/source/discussions/single-source-version.rst
similarity index 100%
rename from source/discussions/single_source_version.rst
rename to source/discussions/single-source-version.rst

From c335757c2783a9a6245bb1955c3f107f62e9d602 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Thu, 22 Aug 2024 12:17:03 -0700
Subject: [PATCH 0784/1072] Update source/discussions/single-source-version.rst

Co-authored-by: Anderson Bravalheri 
---
 source/discussions/single-source-version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/single-source-version.rst b/source/discussions/single-source-version.rst
index f08dc19cc..74ecb6989 100644
--- a/source/discussions/single-source-version.rst
+++ b/source/discussions/single-source-version.rst
@@ -12,7 +12,7 @@ One of the challenges in building packages is that the version string can be req
 * It needs to be specified when building the package (e.g. in :file:`pyproject.toml`)
    This will make it available in the installed package’s metadata, from where it will be accessible at runtime using ``importlib.metadata.version("distribution_name")``.
 
-* A package may set a top level ``__version__`` attribute to provide an alternative means of runtime access to the version of the imported package. If this is done, the value of ``__version__`` attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way `.
+* A package may set a module attribute (e.g., ``__version__``) to provide an alternative means of runtime access to the version of the imported package. If this is done, the value of the attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way `.
 
 * If the code is in in a version control system (VCS), e.g. Git, the version may appear in a *tag* such as ``v1.2.3``.
 

From b35bd14a3ce8a8081aee7f51d45c84b061b2a7f6 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Thu, 22 Aug 2024 12:23:21 -0700
Subject: [PATCH 0785/1072] Update source/discussions/single-source-version.rst

Co-authored-by: Anderson Bravalheri 
---
 source/discussions/single-source-version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/single-source-version.rst b/source/discussions/single-source-version.rst
index 74ecb6989..05c2f962e 100644
--- a/source/discussions/single-source-version.rst
+++ b/source/discussions/single-source-version.rst
@@ -24,7 +24,7 @@ In general, the options are:
 
 2) The version can be hard-coded into the :file:`pyproject.toml` file -- and the build system can copy it into other locations it may be required.
 
-3) The version string can be hard-coded into the source code -- either in a special purpose file, such as :file:`_version.txt`, or as a attribute in the :file:`__init__.py`, and the build system can extract it at build time.
+3) The version string can be hard-coded into the source code -- either in a special purpose file, such as :file:`_version.txt`, or as a attribute in a module, such as :file:`__init__.py`, and the build system can extract it at build time.
 
 
 Consult your build system's documentation for their recommended method.

From e0cb805e371e7144d8398f8e301ab345a3ffaf0f Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Thu, 22 Aug 2024 12:26:05 -0700
Subject: [PATCH 0786/1072] Update source/discussions/single-source-version.rst

Co-authored-by: Anderson Bravalheri 
---
 source/discussions/single-source-version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/single-source-version.rst b/source/discussions/single-source-version.rst
index 05c2f962e..2e7241cd7 100644
--- a/source/discussions/single-source-version.rst
+++ b/source/discussions/single-source-version.rst
@@ -42,6 +42,6 @@ The following are links to some build system's documentation for handling versio
 
 * `PDM `_
 
-* `Setuptools `_
+* `Setuptools `_
 
   -  `setuptools_scm `_

From b120a516ed3a986ae68149112cd8ad3fff98d5af Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sviatoslav=20Sydorenko=20=28=D0=A1=D0=B2=D1=8F=D1=82=D0=BE?=
 =?UTF-8?q?=D1=81=D0=BB=D0=B0=D0=B2=20=D0=A1=D0=B8=D0=B4=D0=BE=D1=80=D0=B5?=
 =?UTF-8?q?=D0=BD=D0=BA=D0=BE=29?= 
Date: Sat, 24 Aug 2024 02:15:25 +0200
Subject: [PATCH 0787/1072] Make the single-sourcing discussion label unique

---
 source/discussions/single-source-version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/single-source-version.rst b/source/discussions/single-source-version.rst
index 2e7241cd7..115b8ded4 100644
--- a/source/discussions/single-source-version.rst
+++ b/source/discussions/single-source-version.rst
@@ -1,4 +1,4 @@
-.. _`Single sourcing the version`:
+.. _`Single sourcing the version discussion`:
 
 ===================================
 Single-sourcing the Project Version

From 4d7e33a875adb9fae0295f5d2995df7b3d41cf0c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sviatoslav=20Sydorenko=20=28=D0=A1=D0=B2=D1=8F=D1=82=D0=BE?=
 =?UTF-8?q?=D1=81=D0=BB=D0=B0=D0=B2=20=D0=A1=D0=B8=D0=B4=D0=BE=D1=80=D0=B5?=
 =?UTF-8?q?=D0=BD=D0=BA=D0=BE=29?= 
Date: Sat, 24 Aug 2024 02:16:42 +0200
Subject: [PATCH 0788/1072] =?UTF-8?q?=F0=9F=87=BA=F0=9F=87=A6=20Set=20the?=
 =?UTF-8?q?=20last-reviewed=20date=20in=20the=20single-sourced=20version?=
 =?UTF-8?q?=20discussion?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 source/discussions/single-source-version.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/single-source-version.rst b/source/discussions/single-source-version.rst
index 115b8ded4..9bcab6291 100644
--- a/source/discussions/single-source-version.rst
+++ b/source/discussions/single-source-version.rst
@@ -5,7 +5,7 @@ Single-sourcing the Project Version
 ===================================
 
 :Page Status: Complete
-:Last Reviewed: 2024-??
+:Last Reviewed: 2024-08-24
 
 One of the challenges in building packages is that the version string can be required in multiple places.
 

From f7891eb22c50db1ae39d259ab0851f3486cbaaba Mon Sep 17 00:00:00 2001
From: Ee Durbin 
Date: Tue, 3 Sep 2024 09:45:08 -0400
Subject: [PATCH 0789/1072] add documentation for PEP 639, License-Expression
 and License-Field

---
 source/specifications/core-metadata.rst | 53 ++++++++++++++++++++++++-
 1 file changed, 51 insertions(+), 2 deletions(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index fb6570fbb..66218b178 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -48,7 +48,7 @@ Metadata-Version
 .. versionadded:: 1.0
 
 Version of the file format; legal values are "1.0", "1.1", "1.2", "2.1",
-"2.2", and "2.3".
+"2.2", "2.3", and "2.4".
 
 Automated tools consuming metadata SHOULD warn if ``metadata_version`` is
 greater than the highest version they support, and MUST fail if
@@ -63,7 +63,7 @@ all of the needed fields.
 
 Example::
 
-    Metadata-Version: 2.3
+    Metadata-Version: 2.4
 
 
 .. _core-metadata-name:
@@ -477,6 +477,50 @@ Examples::
     License: GPL version 3, excluding DRM provisions
 
 
+.. _license-expression-optional:
+.. _core-metadata-license-expression:
+
+License-Expression
+==================
+
+.. versionadded:: 2.4
+
+Text string that is a valid SPDX
+`license expression `__
+as `defined in PEP 639 `__.
+
+Examples::
+
+    License-Expression: MIT
+    License-Expression: BSD-3-Clause
+    License-Expression: MIT AND (Apache-2.0 OR BSD-2-Clause)
+    License-Expression: MIT OR GPL-2.0-or-later OR (FSFUL AND BSD-2-Clause)
+    License-Expression: GPL-3.0-only WITH Classpath-Exception-2.0 OR BSD-3-Clause
+    License-Expression: LicenseRef-Special-License OR CC0-1.0 OR Unlicense
+    License-Expression: LicenseRef-Proprietary
+
+
+.. _license-file-optional:
+.. _core-metadata-license-file:
+
+License-File (multiple use)
+===========================
+
+.. versionadded:: 2.4
+
+Each entry is a string representation of the path of a license-related file.
+The path is located within the project source tree, relative to the project
+root directory.
+
+Examples::
+
+    License-File: LICENSE
+    License-File: AUTHORS
+    License-File: LICENSE.txt
+    License-File: licenses/LICENSE.MIT
+    License-File: licenses/LICENSE.CC0
+
+
 .. _metadata-classifier:
 .. _core-metadata-classifier:
 
@@ -864,6 +908,11 @@ History
 
   - Restricted extra names to be normalized.
 
+- August 2024: Core metadata 2.4 was approved through :pep:`639`.
+
+  - Added the ``License-Expression`` field.
+  - Added the ``License-File`` field.
+
 ----
 
 .. [1] reStructuredText markup:

From 5821db4e1e59447e57602eaea23f3983bafd4581 Mon Sep 17 00:00:00 2001
From: Markus Grotz 
Date: Tue, 3 Sep 2024 23:45:46 -0700
Subject: [PATCH 0790/1072] Update download-artifact plugin in
 publish-to-test-pypi.yml to fix vulnerability

Versions of actions/download-artifact before 4.1.7 are vulnerable to arbitrary file write when downloading and extracting a specifically crafted artifact that contains path traversal filenames.

Fore more details see: https://github.com/advisories/GHSA-6q32-hq47-5qq3
---
 .../github-actions-ci-cd-sample/publish-to-test-pypi.yml  | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
index 3bd06cccc..3c0192b53 100644
--- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
+++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
@@ -22,7 +22,7 @@ jobs:
     - name: Build a binary wheel and a source tarball
       run: python3 -m build
     - name: Store the distribution packages
-      uses: actions/upload-artifact@v3
+      uses: actions/upload-artifact@v4
       with:
         name: python-package-distributions
         path: dist/
@@ -42,7 +42,7 @@ jobs:
 
     steps:
     - name: Download all the dists
-      uses: actions/download-artifact@v3
+      uses: actions/download-artifact@v4
       with:
         name: python-package-distributions
         path: dist/
@@ -63,7 +63,7 @@ jobs:
 
     steps:
     - name: Download all the dists
-      uses: actions/download-artifact@v3
+      uses: actions/download-artifact@v4
       with:
         name: python-package-distributions
         path: dist/
@@ -107,7 +107,7 @@ jobs:
 
     steps:
     - name: Download all the dists
-      uses: actions/download-artifact@v3
+      uses: actions/download-artifact@v4
       with:
         name: python-package-distributions
         path: dist/

From a222c4a83b8f13f79f1e709772f1db447cad250d Mon Sep 17 00:00:00 2001
From: Ee Durbin 
Date: Sun, 15 Sep 2024 20:52:26 -0400
Subject: [PATCH 0791/1072] document deprecations and conflicts

---
 source/specifications/core-metadata.rst | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 66218b178..97686c543 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -460,6 +460,14 @@ License
 =======
 
 .. versionadded:: 1.0
+.. deprecated:: 2.4
+   in favour of ``License-Expression``.
+
+.. warning::
+    As of Metadata 2.4, ``License`` and ``License-Expression`` are mutually
+    exclusive. If both are specified, tools which parse metadata will disregard
+    ``License`` and PyPI will reject uploads.
+    See `PEP 639 `__.
 
 Text indicating the license covering the distribution where the license
 is not a selection from the "License" Trove classifiers. See
@@ -510,7 +518,7 @@ License-File (multiple use)
 
 Each entry is a string representation of the path of a license-related file.
 The path is located within the project source tree, relative to the project
-root directory.
+root directory. For details see :pep:`639`.
 
 Examples::
 
@@ -534,6 +542,11 @@ for the distribution.  Classifiers are described in :pep:`301`,
 and the Python Package Index publishes a dynamic list of
 `currently defined classifiers `__.
 
+.. note::
+    The use of ``License ::`` classifiers  is deprecated as of Metadata 2.4,
+    use ``License-Expression`` instead. See
+    `PEP 639 `_.
+
 This field may be followed by an environment marker after a semicolon.
 
 Examples::

From 30450630fc30a76c03a4ef9bba4d86911a846170 Mon Sep 17 00:00:00 2001
From: Ee Durbin 
Date: Thu, 19 Sep 2024 08:48:07 -0400
Subject: [PATCH 0792/1072] fix broken link

---
 source/specifications/platform-compatibility-tags.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 740a28a1a..3679cf4ad 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -343,5 +343,5 @@ History
 
 
 .. _musl: https://musl.libc.org
-.. _ldd: https://www.unix.com/man-page/posix/1/ldd/
+.. _ldd: https://www.man7.org/linux/man-pages/man1/ldd.1.html
 .. _elf: https://refspecs.linuxfoundation.org/elf/elf.pdf

From fdc8df8ebdd13b589b5643c7b7634ac59fbfd410 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Fri, 11 Oct 2024 14:24:15 +0100
Subject: [PATCH 0793/1072] guides, specifications: update for PEP 753

Signed-off-by: William Woodruff 
---
 source/guides/writing-pyproject-toml.rst      |  12 +-
 source/specifications/core-metadata.rst       |  64 ++++---
 source/specifications/pyproject-toml.rst      |   3 +-
 .../section-distribution-metadata.rst         |   1 +
 .../well-known-project-urls.rst               | 176 ++++++++++++++++++
 5 files changed, 226 insertions(+), 30 deletions(-)
 create mode 100644 source/specifications/well-known-project-urls.rst

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index d11b8a87c..cb1639f50 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -399,6 +399,7 @@ To prevent a package from being uploaded to PyPI, use the special ``Private ::
 Do Not Upload`` classifier. PyPI will always reject packages with classifiers
 beginning with ``Private ::``.
 
+.. _writing-pyproject-toml-urls:
 
 ``urls``
 --------
@@ -406,6 +407,13 @@ beginning with ``Private ::``.
 A list of URLs associated with your project, displayed on the left
 sidebar of your PyPI project page.
 
+.. note::
+
+    See :ref:`well-known-labels` for a listing
+    of labels that PyPI and other packaging tools are specifically aware of,
+    and `PyPI's project metadata docs `_
+    for PyPI-specific URL processing.
+
 .. code-block:: toml
 
    [project.urls]
@@ -415,12 +423,10 @@ sidebar of your PyPI project page.
    Issues = "https://github.com/me/spam/issues"
    Changelog = "https://github.com/me/spam/blob/master/CHANGELOG.md"
 
-Note that if the key contains spaces, it needs to be quoted, e.g.,
+Note that if the label contains spaces, it needs to be quoted, e.g.,
 ``Website = "https://example.com"`` but
 ``"Official Website" = "https://example.com"``.
 
-
-
 Advanced plugins
 ================
 
diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 97686c543..c1ce528e7 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -341,32 +341,6 @@ Example::
    These tools have been very widely used for many years, so it was
    easier to update the specification to match the de facto standard.
 
-.. _home-page-optional:
-.. _core-metadata-home-page:
-
-Home-page
-=========
-
-.. versionadded:: 1.0
-
-A string containing the URL for the distribution's home page.
-
-Example::
-
-    Home-page: http://www.example.com/~cschultz/bvote/
-
-.. _core-metadata-download-url:
-
-Download-URL
-============
-
-.. versionadded:: 1.1
-
-A string containing the URL from which this version of the distribution
-can be downloaded.  (This means that the URL can't be something like
-".../BeagleVote-latest.tgz", but instead must be ".../BeagleVote-0.45.tgz".)
-
-
 .. _author-optional:
 .. _core-metadata-author:
 
@@ -669,6 +643,10 @@ Example::
 
 The label is free text limited to 32 characters.
 
+Starting with :pep:`753`, project metadata consumers (such as the Python
+Package Index) can use a standard normalization process to discover "well-known"
+labels, which can then be given special presentations when being rendered
+for human consumption. See :ref:`well-known-project-urls`.
 
 .. _metadata_provides_extra:
 .. _core-metadata-provides-extra:
@@ -819,6 +797,40 @@ Examples::
 Deprecated Fields
 =================
 
+.. _home-page-optional:
+.. _core-metadata-home-page:
+
+Home-page
+---------
+
+.. versionadded:: 1.0
+
+.. deprecated:: 1.2
+
+    Per :pep:`753`, use :ref:`core-metadata-project-url` instead.
+
+A string containing the URL for the distribution's home page.
+
+Example::
+
+    Home-page: http://www.example.com/~cschultz/bvote/
+
+.. _core-metadata-download-url:
+
+Download-URL
+------------
+
+.. versionadded:: 1.1
+
+.. deprecated:: 1.2
+
+    Per :pep:`753`, use :ref:`core-metadata-project-url` instead.
+
+A string containing the URL from which this version of the distribution
+can be downloaded.  (This means that the URL can't be something like
+"``.../BeagleVote-latest.tgz``", but instead must be
+"``.../BeagleVote-0.45.tgz``".)
+
 Requires
 --------
 
diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index efa562a73..400e43105 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -318,7 +318,8 @@ Trove classifiers which apply to the project.
   :ref:`Project-URL `
 
 A table of URLs where the key is the URL label and the value is the
-URL itself.
+URL itself. See :ref:`well-known-project-urls` for normalization rules
+and well-known rules when processing metadata for presentation.
 
 
 Entry points
diff --git a/source/specifications/section-distribution-metadata.rst b/source/specifications/section-distribution-metadata.rst
index 7fd3361a0..0c0a8aaba 100644
--- a/source/specifications/section-distribution-metadata.rst
+++ b/source/specifications/section-distribution-metadata.rst
@@ -12,3 +12,4 @@ Package Distribution Metadata
    pyproject-toml
    inline-script-metadata
    platform-compatibility-tags
+   well-known-project-urls
diff --git a/source/specifications/well-known-project-urls.rst b/source/specifications/well-known-project-urls.rst
new file mode 100644
index 000000000..9ce2d8ba2
--- /dev/null
+++ b/source/specifications/well-known-project-urls.rst
@@ -0,0 +1,176 @@
+.. _`well-known-project-urls`:
+
+===================================
+Well-known Project URLs in Metadata
+===================================
+
+.. important::
+
+    This document is primarily of interest to metadata *consumers*,
+    who should use the normalization rules and well-known list below
+    to make their presentation of project URLs consistent across the
+    Python ecosystem.
+
+    Metadata *producers* (such as build tools and individual package
+    maintainers) may continue to use any labels they please, within the
+    overall ``Project-URL`` length restrictions. However, users are
+    *encouraged* to pick meaningful labels that normalize to well-known
+    labels.
+
+.. note::
+
+    See :ref:`Writing your pyproject.toml - urls `
+    for user-oriented guidance on choosing project URL labels in your package's
+    metadata.
+
+.. note:: This specification was originally defined in :pep:`753`.
+
+:pep:`753` deprecates the :ref:`core-metadata-home-page` and
+:ref:`core-metadata-download-url` metadata fields in favor of
+:ref:`core-metadata-project-url`, and defines a normalization and
+lookup procedure for determining whether a ``Project-URL`` is
+"well-known," i.e. has the semantics assigned to ``Home-page``,
+``Download-URL``, or other common project URLs.
+
+This allows indices (such as the Python Package Index) and other downstream
+metadata consumers to specialize their presentations of project URLs in a
+consistent manner.
+
+.. _project-url-label-normalization:
+
+Label normalization
+===================
+
+.. note::
+
+    Label normalization is performed by metadata *consumers*, not metadata
+    producers.
+
+To determine whether a ``Project-URL`` label is "well-known," metadata
+consumers should first normalize the label before comparing it to the
+:ref:`list of well-known labels `.
+
+The normalization procedure for ``Project-URL`` labels is defined
+by the following Python function:
+
+.. code-block:: python
+
+    import string
+
+    def normalize_label(label: str) -> str:
+        chars_to_remove = string.punctuation + string.whitespace
+        removal_map = str.maketrans("", "", chars_to_remove)
+        return label.translate(removal_map).lower()
+
+In plain language: a label is *normalized* by deleting all ASCII punctuation
+and whitespace, and then converting the result to lowercase.
+
+The following table shows examples of labels before (raw) and after
+normalization:
+
+.. list-table::
+    :header-rows: 1
+
+    * - Raw
+      - Normalized
+    * - ``Homepage``
+      - ``homepage``
+    * - ``Home-page``
+      - ``homepage``
+    * - ``Home page``
+      - ``homepage``
+    * - ``Change_Log``
+      - ``changelog``
+    * - ``What's New?``
+      - ``whatsnew``
+    * - ``github``
+      - ``github``
+
+.. _well-known-labels:
+
+Well-known labels
+=================
+
+.. note::
+
+    The list of well-known labels is a living standard, maintained as part of
+    this document.
+
+The following table lists labels that are well-known for the purpose of
+specializing the presentation of ``Project-URL`` metadata:
+
+.. list-table::
+   :header-rows: 1
+
+   * - Label (Human-readable equivalent)
+     - Description
+     - Aliases
+   * - ``homepage`` (Homepage)
+     - The project's home page
+     - *(none)*
+   * - ``source`` (Source Code)
+     - The project's hosted source code or repository
+     - ``repository``, ``sourcecode``, ``github``
+   * - ``download`` (Download)
+     - A download URL for the current distribution, equivalent to ``Download-URL``
+     - *(none)*
+   * - ``changelog`` (Changelog)
+     - The project's comprehensive changelog
+     - ``changes``, ``whatsnew``, ``history``
+   * - ``releasenotes`` (Release Notes)
+     - The project's curated release notes
+     - *(none)*
+   * - ``documentation`` (Documentation)
+     - The project's online documentation
+     - ``docs``
+   * - ``issues`` (Issue Tracker)
+     - The project's bug tracker
+     - ``bugs``, ``issue``, ``tracker``, ``issuetracker``, ``bugtracker``
+   * - ``funding`` (Funding)
+     - Funding Information
+     - ``sponsor``, ``donate``, ``donation``
+
+Package metadata consumers may choose to render aliased labels the same as
+their "parent" well known label, or further specialize them.
+
+Example behavior
+================
+
+The following shows the flow of project URL metadata from
+``pyproject.toml`` to core metadata to a potential index presentation:
+
+.. code-block:: toml
+    :caption: Example project URLs in standard configuration
+
+    [project.urls]
+    "Home Page" = "https://example.com"
+    DOCUMENTATION = "https://readthedocs.org"
+    Repository = "https://upstream.example.com/me/spam.git"
+    GitHub = "https://github.com/example/spam"
+
+.. code-block:: email
+    :caption: Core metadata representation
+
+    Project-URL: Home page, https://example.com
+    Project-URL: DOCUMENTATION, https://readthedocs.org
+    Project-URL: Repository, https://upstream.example.com/me/spam.git
+    Project-URL: GitHub, https://github.com/example/spam
+
+.. code-block:: text
+    :caption: Potential rendering
+
+    Homepage: https://example.com
+    Documentation: https://readthedocs.org
+    Source Code: https://upstream.example.com/me/spam.git
+    Source Code (GitHub): https://github.com/example/spam
+
+Observe that the core metadata appears in the form provided by the user
+(since metadata *producers* do not perform normalization), but the
+metadata *consumer* correctly normalizes and identifies appropriate
+human-readable equivalents based on the normalized form:
+
+* ``Home page`` becomes ``homepage``, which is rendered as ``Homepage``
+* ``DOCUMENTATION`` becomes ``documentation``, which is rendered as ``Documentation``
+* ``Repository`` becomes ``repository``, which is rendered as ``Source Code``
+* ``GitHub`` becomes ``github``, which is rendered as ``Source Code (GitHub)``
+  (as a specialization of ``Source Code``)

From daa5daf39c08518963ae8e314027b4f82d39eef4 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Fri, 11 Oct 2024 15:03:57 +0100
Subject: [PATCH 0794/1072] Update well-known-project-urls.rst

Co-authored-by: Paul Moore 
---
 source/specifications/well-known-project-urls.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/well-known-project-urls.rst b/source/specifications/well-known-project-urls.rst
index 9ce2d8ba2..efaeb35c2 100644
--- a/source/specifications/well-known-project-urls.rst
+++ b/source/specifications/well-known-project-urls.rst
@@ -166,7 +166,7 @@ The following shows the flow of project URL metadata from
 
 Observe that the core metadata appears in the form provided by the user
 (since metadata *producers* do not perform normalization), but the
-metadata *consumer* correctly normalizes and identifies appropriate
+metadata *consumer* normalizes and identifies appropriate
 human-readable equivalents based on the normalized form:
 
 * ``Home page`` becomes ``homepage``, which is rendered as ``Homepage``

From 5a6c37d56c032a0bdbc96d0c62883594edf7bbc4 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Fri, 11 Oct 2024 15:08:56 +0100
Subject: [PATCH 0795/1072] don't say guidance

Signed-off-by: William Woodruff 
---
 source/specifications/well-known-project-urls.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/specifications/well-known-project-urls.rst b/source/specifications/well-known-project-urls.rst
index efaeb35c2..c2df976b5 100644
--- a/source/specifications/well-known-project-urls.rst
+++ b/source/specifications/well-known-project-urls.rst
@@ -20,8 +20,8 @@ Well-known Project URLs in Metadata
 .. note::
 
     See :ref:`Writing your pyproject.toml - urls `
-    for user-oriented guidance on choosing project URL labels in your package's
-    metadata.
+    for user-oriented documentation on setting project URL labels in your
+    package's metadata.
 
 .. note:: This specification was originally defined in :pep:`753`.
 

From 032153630e04fde4749af3e9b25b61b50d57bbb6 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Fri, 11 Oct 2024 16:52:45 +0100
Subject: [PATCH 0796/1072] Revert "don't say guidance"

This reverts commit 5a6c37d56c032a0bdbc96d0c62883594edf7bbc4.
---
 source/specifications/well-known-project-urls.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/specifications/well-known-project-urls.rst b/source/specifications/well-known-project-urls.rst
index c2df976b5..efaeb35c2 100644
--- a/source/specifications/well-known-project-urls.rst
+++ b/source/specifications/well-known-project-urls.rst
@@ -20,8 +20,8 @@ Well-known Project URLs in Metadata
 .. note::
 
     See :ref:`Writing your pyproject.toml - urls `
-    for user-oriented documentation on setting project URL labels in your
-    package's metadata.
+    for user-oriented guidance on choosing project URL labels in your package's
+    metadata.
 
 .. note:: This specification was originally defined in :pep:`753`.
 

From b24d423c743e5a4398f03b74935bc94d80a60ad5 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Fri, 11 Oct 2024 17:15:08 +0100
Subject: [PATCH 0797/1072] guide: make URL guidance more guide-y

Signed-off-by: William Woodruff 
---
 source/guides/writing-pyproject-toml.rst | 25 ++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index cb1639f50..833bac23a 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -427,6 +427,31 @@ Note that if the label contains spaces, it needs to be quoted, e.g.,
 ``Website = "https://example.com"`` but
 ``"Official Website" = "https://example.com"``.
 
+Users are advised to use :ref:`well-known-labels` for their project URLs
+where appropriate, since consumers of metadata (like package indices) can
+specialize their presentation.
+
+For example in the following metadata, neither ``MyHomepage`` nor
+``"Download Link"`` is a well-known label, so they will be rendered verbatim:
+
+.. code-block:: toml
+
+   [project.urls]
+   MyHomepage = "https://example.com"
+   "Download Link" = "https://example.com/abc.tar.gz"
+
+
+Whereas in this metadata ``HomePage`` and ``DOWNLOAD`` both have
+well-known equivalents (``homepage`` and ``download``), and can be presented
+with those semantics in mind (the project's home page and its external
+download location, respectively).
+
+.. code-block:: toml
+
+   [project.urls]
+   HomePage = "https://example.com"
+   DOWNLOAD = "https://example.com/abc.tar.gz"
+
 Advanced plugins
 ================
 

From e0699855a36e3cd0521f43f1fe4f901021cf99eb Mon Sep 17 00:00:00 2001
From: Alyssa Coghlan 
Date: Sun, 6 Oct 2024 17:38:18 +1000
Subject: [PATCH 0798/1072] Add notes on runtime version access
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Also redirects the obsolete single-source version guide to the
updated single-source version discussion.

Co-authored-by: Éric 
Co-authored-by: wim glenn 
---
 source/discussions/single-source-version.rst  |  41 ++--
 source/discussions/versioning.rst             |  59 +++++-
 source/guides/section-build-and-publish.rst   |   1 -
 .../single-sourcing-package-version.rst       | 175 +-----------------
 source/guides/writing-pyproject-toml.rst      |   4 +-
 5 files changed, 93 insertions(+), 187 deletions(-)

diff --git a/source/discussions/single-source-version.rst b/source/discussions/single-source-version.rst
index 9bcab6291..c7dc8d1e1 100644
--- a/source/discussions/single-source-version.rst
+++ b/source/discussions/single-source-version.rst
@@ -1,34 +1,49 @@
-.. _`Single sourcing the version discussion`:
+.. _single-source-version:
 
 ===================================
 Single-sourcing the Project Version
 ===================================
 
 :Page Status: Complete
-:Last Reviewed: 2024-08-24
+:Last Reviewed: 2024-10-07
 
-One of the challenges in building packages is that the version string can be required in multiple places.
+Many Python :term:`distribution packages ` publish a single
+Python :term:`import package ` where it is desired that the runtime
+``__version__`` attribute on the import package report the same version specifier
+as :func:`importlib.metadata.version` reports for the distribution package
+(as described in :ref:`runtime-version-access`).
 
-* It needs to be specified when building the package (e.g. in :file:`pyproject.toml`)
-   This will make it available in the installed package’s metadata, from where it will be accessible at runtime using ``importlib.metadata.version("distribution_name")``.
+It is also frequently desired that this version information be derived from a version
+control system *tag* (such as ``v1.2.3``) rather than being manually updated in the
+source code.
 
-* A package may set a module attribute (e.g., ``__version__``) to provide an alternative means of runtime access to the version of the imported package. If this is done, the value of the attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way `.
+Some projects may choose to simply live with the data entry duplication, and rely
+on automated testing to ensure the different values do not diverge.
 
-* If the code is in in a version control system (VCS), e.g. Git, the version may appear in a *tag* such as ``v1.2.3``.
-
-To ensure that version numbers do not get out of sync, it is recommended that there is a single source of truth for the version number.
+Alternatively, a project's chosen build system may offer a way to define a single
+source of truth for the version number.
 
 In general, the options are:
 
-1) If the code is in a version control system (VCS), e.g. Git, then the version can be extracted from the VCS.
-
-2) The version can be hard-coded into the :file:`pyproject.toml` file -- and the build system can copy it into other locations it may be required.
+1) If the code is in a version control system (VCS), such as Git, then the version can be extracted from the VCS.
 
-3) The version string can be hard-coded into the source code -- either in a special purpose file, such as :file:`_version.txt`, or as a attribute in a module, such as :file:`__init__.py`, and the build system can extract it at build time.
+2) The version can be hard-coded into the :file:`pyproject.toml` file -- and the build system can copy it
+   into other locations it may be required.
 
+3) The version string can be hard-coded into the source code -- either in a special purpose file,
+   such as :file:`_version.txt` (which must then be shipped as part of the project's source distribution
+   package), or as an attribute in a particular module, such as :file:`__init__.py`. The build
+   system can then extract it from the runtime location at build time.
 
 Consult your build system's documentation for their recommended method.
 
+When the intention is that a distribution package and its associated import package
+share the same version, it is recommended that the project include an automated test
+case that ensures ``import_name.__version__`` and ``importlib.metadata.version("dist-name")``
+report the same value (note: for many projects, ``import_name`` and ``dist-name`` will
+be the same name).
+
+
 .. _Build system version handling:
 
 Build System Version Handling
diff --git a/source/discussions/versioning.rst b/source/discussions/versioning.rst
index 49fbbf0de..8f318bae9 100644
--- a/source/discussions/versioning.rst
+++ b/source/discussions/versioning.rst
@@ -153,7 +153,6 @@ numbering scheme that readily conveys the approximate age of a release, but
 doesn't otherwise commit to a particular release cadence within the year.
 
 
-
 Local version identifiers
 =========================
 
@@ -172,6 +171,55 @@ since the latest release, setuptools-scm generates a version like
 "0.5.dev1+gd00980f", or if the repository has untracked changes, like
 "0.5.dev1+gd00980f.d20231217".
 
+.. _runtime-version-access:
+
+Accessing version information at runtime
+========================================
+
+Version information for all :term:`distribution packages `
+that are locally available in the current environment can be obtained at runtime
+using the standard library's :func:`importlib.metadata.version` function::
+
+   >>> importlib.metadata.version("cryptography")
+   '41.0.7'
+
+Many projects also choose to version their top level
+:term:`import packages ` by providing a package level
+``__version__`` attribute::
+
+   >>> import cryptography
+   >>> cryptography.__version__
+   '41.0.7'
+
+This technique can be particularly valuable for CLI applications which want
+to ensure that version query invocations (such as ``pip -V``) run as quickly
+as possible.
+
+Package publishers wishing to ensure their reported distribution package and
+import package versions are consistent with each other can review the
+:ref:`single-source-version` discussion for potential approaches to doing so.
+
+As import packages and modules are not *required* to publish runtime
+version information in this way (see the rejected proposal in
+:pep:`PEP 396 <396>`), the ``__version__`` attribute should either only be
+queried with interfaces that are known to provide it (such as a project
+querying its own version or the version of one of its direct dependencies),
+or else the querying code should be designed to handle the case where the
+attribute is missing [#fallback-to-dist-version]_.
+
+Some projects may need to publish version information for external APIs
+that don't meet the requirements for Python distribution package
+:ref:`version specifiers `. Such projects should
+define their own project-specific ways of obtaining the relevant information
+at runtime. For example, the standard library's :mod:`ssl` module offers
+multiple ways to access the underlying OpenSSL library version::
+
+   >>> ssl.OPENSSL_VERSION
+   'OpenSSL 3.2.2 4 Jun 2024'
+   >>> ssl.OPENSSL_VERSION_INFO
+   (3, 2, 0, 2, 0)
+   >>> hex(ssl.OPENSSL_VERSION_NUMBER)
+   '0x30200020'
 
 --------------------------------------------------------------------------------
 
@@ -184,6 +232,15 @@ since the latest release, setuptools-scm generates a version like
    Brett Cannon `_. For a humoristic take, read about
    ZeroVer_.
 
+.. [#fallback-to-dist-version] A full list mapping the top level names available
+   for import to the distribution packages that provide those import packages and
+   modules may be obtained through the standard library's
+   :func:`importlib.metadata.packages_distributions` function. This means that
+   even code that is attempting to infer a version to report for all importable
+   top-level names has a means to fall back to reporting the distribution
+   version information if no ``__version__`` attribute is defined. Only standard
+   library modules, and modules added via means other than Python package
+   installation would fail to have version information reported in that case.
 
 
 .. _zerover: https://0ver.org
diff --git a/source/guides/section-build-and-publish.rst b/source/guides/section-build-and-publish.rst
index 8e0c9ab3b..eb10c389f 100644
--- a/source/guides/section-build-and-publish.rst
+++ b/source/guides/section-build-and-publish.rst
@@ -7,7 +7,6 @@ Building and Publishing
 
    writing-pyproject-toml
    distributing-packages-using-setuptools
-   single-sourcing-package-version
    dropping-older-python-versions
    packaging-binary-extensions
    packaging-namespace-packages
diff --git a/source/guides/single-sourcing-package-version.rst b/source/guides/single-sourcing-package-version.rst
index 5c8af21e0..7ed3d87da 100644
--- a/source/guides/single-sourcing-package-version.rst
+++ b/source/guides/single-sourcing-package-version.rst
@@ -1,173 +1,8 @@
-.. _`Single sourcing the version`:
+:orphan:
 
-===================================
-Single-sourcing the package version
-===================================
+.. meta::
+   :http-equiv=refresh: 0; url=../../discussions/single-source-version/
 
-.. todo:: Update this page for build backends other than setuptools.
+Redirecting stale single-source package version link...
 
-There are many techniques to maintain a single source of truth for the version
-number of your project:
-
-#.  Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py
-    `_)::
-
-        import codecs
-        import os.path
-
-        def read(rel_path):
-            here = os.path.abspath(os.path.dirname(__file__))
-            with codecs.open(os.path.join(here, rel_path), 'r') as fp:
-                return fp.read()
-
-        def get_version(rel_path):
-            for line in read(rel_path).splitlines():
-                if line.startswith('__version__'):
-                    delim = '"' if '"' in line else "'"
-                    return line.split(delim)[1]
-            else:
-                raise RuntimeError("Unable to find version string.")
-
-        setup(
-           ...
-           version=get_version("package/__init__.py")
-           ...
-        )
-
-    .. note::
-
-       As of the release of setuptools 46.4.0, one can accomplish the same
-       thing by instead placing the following in the project's
-       :file:`setup.cfg` file (replacing "package" with the import name of the
-       package):
-
-       .. code-block:: ini
-
-           [metadata]
-           version = attr: package.__version__
-
-       As of the release of setuptools 61.0.0, one can specify the
-       version dynamically in the project's :file:`pyproject.toml` file.
-
-       .. code-block:: toml
-
-            [project]
-            name = "package"
-            dynamic = ["version"]
-
-            [tool.setuptools.dynamic]
-            version = {attr = "package.__version__"}
-
-       Please be aware that declarative config indicators, including the
-       ``attr:`` directive, are not supported in parameters to
-       :file:`setup.py`.
-
-#.  Use an external build tool that either manages updating both locations, or
-    offers an API that both locations can use.
-
-    Few tools you could use, in no particular order, and not necessarily complete:
-    `bump2version `_,
-    `changes `_,
-    `commitizen `_,
-    `zest.releaser `_.
-
-
-#.  Set the value to a ``__version__`` global variable in a dedicated module in
-    your project (e.g. :file:`version.py`), then have :file:`setup.py` read and
-    ``exec`` the value into a variable.
-
-    ::
-
-        version = {}
-        with open("...sample/version.py") as fp:
-            exec(fp.read(), version)
-        # later on we use: version['__version__']
-
-    Example using this technique: `warehouse `_.
-
-#.  Place the value in a simple ``VERSION`` text file and have both
-    :file:`setup.py` and the project code read it.
-
-    ::
-
-        with open(os.path.join(mypackage_root_dir, 'VERSION')) as version_file:
-            version = version_file.read().strip()
-
-    An advantage with this technique is that it's not specific to Python.  Any
-    tool can read the version.
-
-    .. warning::
-
-        With this approach you must make sure that the ``VERSION`` file is included in
-        all your source and binary distributions (e.g. add ``include VERSION`` to your
-        :file:`MANIFEST.in`).
-
-#.  Set the value in :file:`setup.py`, and have the project code use the
-    ``importlib.metadata`` API to fetch the value at runtime.
-    (``importlib.metadata`` was introduced in Python 3.8 and is available to
-    older versions as the ``importlib-metadata`` project.)  An installed
-    project's version can be fetched with the API as follows::
-
-        import sys
-
-        if sys.version_info >= (3, 8):
-            from importlib import metadata
-        else:
-            import importlib_metadata as metadata
-
-        assert metadata.version('pip') == '1.2.0'
-
-    Be aware that the ``importlib.metadata`` API only knows about what's in the
-    installation metadata, which is not necessarily the code that's currently
-    imported.
-
-    If a project uses this method to fetch its version at runtime, then its
-    ``install_requires`` value needs to be edited to install
-    ``importlib-metadata`` on pre-3.8 versions of Python like so::
-
-        setup(
-            ...
-            install_requires=[
-                ...
-                'importlib-metadata >= 1.0 ; python_version < "3.8"',
-                ...
-            ],
-            ...
-        )
-
-    An older (and less efficient) alternative to ``importlib.metadata`` is the
-    ``pkg_resources`` API provided by ``setuptools``::
-
-        import pkg_resources
-        assert pkg_resources.get_distribution('pip').version == '1.2.0'
-
-    If a project uses ``pkg_resources`` to fetch its own version at runtime,
-    then ``setuptools`` must be added to the project's ``install_requires``
-    list.
-
-    Example using this technique: `setuptools `_.
-
-
-#.  Set the value to ``__version__`` in ``sample/__init__.py`` and import
-    ``sample`` in :file:`setup.py`.
-
-    ::
-
-        import sample
-        setup(
-            ...
-            version=sample.__version__
-            ...
-        )
-
-    .. warning::
-
-        Although this technique is common, beware that it will fail if
-        ``sample/__init__.py`` imports packages from ``install_requires``
-        dependencies, which will very likely not be installed yet when
-        :file:`setup.py` is run.
-
-
-#.  Keep the version number in the tags of a version control system (Git, Mercurial, etc)
-    instead of in the code, and automatically extract it from there using
-    `setuptools_scm `_.
+If the page doesn't automatically refresh, see :ref:`single-source-version`.
diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index d11b8a87c..144cc3525 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -163,8 +163,8 @@ This field is required, although it is often marked as dynamic using
    dynamic = ["version"]
 
 This allows use cases such as filling the version from a ``__version__``
-attribute or a Git tag. Consult :ref:`Single sourcing the version` for more
-details.
+attribute or a Git tag. Consult the :ref:`single-source-version`
+discussion for more details.
 
 
 Dependencies and requirements

From 0c94fea4f5b4e95f3fcfc6ef26ff0bc8f4f7d9f7 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Sat, 12 Oct 2024 21:00:41 +0100
Subject: [PATCH 0799/1072] Apply suggestions from code review

Co-authored-by: Carol Willing 
---
 source/specifications/well-known-project-urls.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/source/specifications/well-known-project-urls.rst b/source/specifications/well-known-project-urls.rst
index efaeb35c2..30fefd12b 100644
--- a/source/specifications/well-known-project-urls.rst
+++ b/source/specifications/well-known-project-urls.rst
@@ -13,7 +13,7 @@ Well-known Project URLs in Metadata
 
     Metadata *producers* (such as build tools and individual package
     maintainers) may continue to use any labels they please, within the
-    overall ``Project-URL`` length restrictions. However, users are
+    overall ``Project-URL`` length restrictions. However, when possible, users are
     *encouraged* to pick meaningful labels that normalize to well-known
     labels.
 
@@ -33,7 +33,7 @@ lookup procedure for determining whether a ``Project-URL`` is
 ``Download-URL``, or other common project URLs.
 
 This allows indices (such as the Python Package Index) and other downstream
-metadata consumers to specialize their presentations of project URLs in a
+metadata consumers to present project URLs in a
 consistent manner.
 
 .. _project-url-label-normalization:
@@ -47,7 +47,7 @@ Label normalization
     producers.
 
 To determine whether a ``Project-URL`` label is "well-known," metadata
-consumers should first normalize the label before comparing it to the
+consumers should normalize the label before comparing it to the
 :ref:`list of well-known labels `.
 
 The normalization procedure for ``Project-URL`` labels is defined

From 7e848422448d19489cb113dfb5d956d6d46616fa Mon Sep 17 00:00:00 2001
From: shenxianpeng 
Date: Sun, 13 Oct 2024 13:25:57 +0000
Subject: [PATCH 0800/1072] fix: upgrade gh-action-sigstore-python to v3.0.0

---
 .../guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
index 3c0192b53..152597d49 100644
--- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
+++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
@@ -68,7 +68,7 @@ jobs:
         name: python-package-distributions
         path: dist/
     - name: Sign the dists with Sigstore
-      uses: sigstore/gh-action-sigstore-python@v2.1.1
+      uses: sigstore/gh-action-sigstore-python@v3.0.0
       with:
         inputs: >-
           ./dist/*.tar.gz

From f80aff3c5990b7c0bccca5c6c079f47236d6ebb8 Mon Sep 17 00:00:00 2001
From: csteiner <47841949+clintonsteiner@users.noreply.github.com>
Date: Thu, 17 Oct 2024 18:16:13 -0500
Subject: [PATCH 0801/1072] Update contribute.rst reference to out of date
 django documentation version

Point at dev dependency, which should always stay up to date
---
 source/contribute.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/contribute.rst b/source/contribute.rst
index a246751e4..95d127837 100644
--- a/source/contribute.rst
+++ b/source/contribute.rst
@@ -45,7 +45,7 @@ Tutorials are focused on teaching the reader new concepts by accomplishing a
 goal. They are opinionated step-by-step guides. They do not include extraneous
 warnings or information. `example tutorial-style document`_.
 
-.. _example tutorial-style document: https://docs.djangoproject.com/en/1.11/intro/
+.. _example tutorial-style document: https://docs.djangoproject.com/en/dev/intro/
 
 Guides
 ------

From 27b919dd934338a1fa95141f8860610eb00457d4 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 21 Oct 2024 20:18:24 +0000
Subject: [PATCH 0802/1072] [pre-commit.ci] pre-commit autoupdate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

updates:
- [github.com/pre-commit/pre-commit-hooks: v4.6.0 → v5.0.0](https://github.com/pre-commit/pre-commit-hooks/compare/v4.6.0...v5.0.0)
- [github.com/astral-sh/ruff-pre-commit: v0.4.10 → v0.7.0](https://github.com/astral-sh/ruff-pre-commit/compare/v0.4.10...v0.7.0)
---
 .pre-commit-config.yaml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index c6372ec30..d8ac1c6eb 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -1,6 +1,6 @@
 repos:
 - repo: https://github.com/pre-commit/pre-commit-hooks
-  rev: v4.6.0
+  rev: v5.0.0
   hooks:
   - id: check-added-large-files
   - id: check-case-conflict
@@ -34,7 +34,7 @@ repos:
   - id: rst-inline-touching-normal
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.4.10
+  rev: v0.7.0
   hooks:
     - id: ruff
     - id: ruff-format

From ff4f1f16fb065672eee8b67e8b261746bd93061e Mon Sep 17 00:00:00 2001
From: Alyssa Coghlan 
Date: Thu, 24 Oct 2024 01:01:17 +1000
Subject: [PATCH 0803/1072] PEP 396 was reclassifed as Withdrawn

---
 source/discussions/versioning.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/versioning.rst b/source/discussions/versioning.rst
index 8f318bae9..6d9ef5af7 100644
--- a/source/discussions/versioning.rst
+++ b/source/discussions/versioning.rst
@@ -200,7 +200,7 @@ import package versions are consistent with each other can review the
 :ref:`single-source-version` discussion for potential approaches to doing so.
 
 As import packages and modules are not *required* to publish runtime
-version information in this way (see the rejected proposal in
+version information in this way (see the withdrawn proposal in
 :pep:`PEP 396 <396>`), the ``__version__`` attribute should either only be
 queried with interfaces that are known to provide it (such as a project
 querying its own version or the version of one of its direct dependencies),

From 7d2a208782613f4b27e4b9ceffe2c1fe35221b04 Mon Sep 17 00:00:00 2001
From: Alyssa Coghlan 
Date: Thu, 24 Oct 2024 01:04:16 +1000
Subject: [PATCH 0804/1072] Fix another bit of wording that irked me

---
 source/discussions/versioning.rst | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/source/discussions/versioning.rst b/source/discussions/versioning.rst
index 6d9ef5af7..a7fb51f8b 100644
--- a/source/discussions/versioning.rst
+++ b/source/discussions/versioning.rst
@@ -208,8 +208,7 @@ or else the querying code should be designed to handle the case where the
 attribute is missing [#fallback-to-dist-version]_.
 
 Some projects may need to publish version information for external APIs
-that don't meet the requirements for Python distribution package
-:ref:`version specifiers `. Such projects should
+that aren't the version of the module itself. Such projects should
 define their own project-specific ways of obtaining the relevant information
 at runtime. For example, the standard library's :mod:`ssl` module offers
 multiple ways to access the underlying OpenSSL library version::

From d4ea4c1f5278c0fdb0803f8f174af9de6d65c9dc Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 28 Oct 2024 20:29:58 +0000
Subject: [PATCH 0805/1072] [pre-commit.ci] pre-commit autoupdate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

updates:
- [github.com/astral-sh/ruff-pre-commit: v0.7.0 → v0.7.1](https://github.com/astral-sh/ruff-pre-commit/compare/v0.7.0...v0.7.1)
---
 .pre-commit-config.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index d8ac1c6eb..785b392ab 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -34,7 +34,7 @@ repos:
   - id: rst-inline-touching-normal
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.7.0
+  rev: v0.7.1
   hooks:
     - id: ruff
     - id: ruff-format

From a9110fdce5c76bcc45b8491c223ae32c9b66ac29 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Mon, 28 Oct 2024 18:15:44 -0400
Subject: [PATCH 0806/1072] version-specifiers: add a custom anchor for
 `Pre-releases` section

Signed-off-by: William Woodruff 
---
 source/specifications/version-specifiers.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/source/specifications/version-specifiers.rst b/source/specifications/version-specifiers.rst
index a5ba36498..d18596ee0 100644
--- a/source/specifications/version-specifiers.rst
+++ b/source/specifications/version-specifiers.rst
@@ -237,6 +237,8 @@ release scheme using the year and month of the release::
     ...
 
 
+.. _pre-release-versions:
+
 Pre-releases
 ------------
 

From 6c7c95a4090c9699af6287f9f892c3f2167bbdb9 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Wed, 31 Jul 2024 17:40:25 -0700
Subject: [PATCH 0807/1072] updated notes on conda.

---
 source/key_projects.rst | 40 ++++++++++++++++++++++------------------
 1 file changed, 22 insertions(+), 18 deletions(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index 531c28066..6c8e5d16a 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -404,26 +404,30 @@ conda
 
 :doc:`Docs `
 
-conda is the package management tool for `Anaconda
-`__ Python installations.
-Anaconda Python is a distribution from `Anaconda, Inc
-`__ specifically aimed at the scientific
-community, and in particular on Windows where the installation of binary
-extensions is often difficult.
+Conda is a package, dependency, and environment management system for any language — Python, R,
+Ruby, C/C++, Fortran, and more. It is written in Python and
+widely used in the Python scientific computing community, due to its support for non-Python
+compiled libraries and extensions. It is used as the basis of the `Anaconda
+`__ Python distribution from `Anaconda, Inc.specifically
+aimed at the scientific community, community, but can also be used on its own, or with the
+:doc:`miniconda `, `miniforge `_ or
+`pixi `_ systems. It is available for Windows, Mac and Linux systems.
 
 Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides
-many of their combined features in terms of package management, virtual environment
-management and deployment of binary extensions.
-
-Conda does not install packages from PyPI and can install only from
-the official Anaconda repositories, or anaconda.org (a place for
-user-contributed *conda* packages), or a local (e.g. intranet) package
-server.  However, note that :ref:`pip` can be installed into, and work
-side-by-side with conda for managing :term:`distributions
-` from PyPI. Also, `conda skeleton
-`__
-is a tool to make Python packages installable by conda by first
-fetching them from PyPI and modifying their metadata.
+many of their combined features, such as package management, virtual environment
+management and deployment of binary extensions and other binary code.
+
+Conda does not install packages from PyPI -- it can only manage packages built specifically
+for conda, which can be made available on a "conda channel", such as those hosted on
+`anaconda.org `__ or a local (e.g. intranet) package server.
+In addition to the "default" channels managed by `Anaconda, Inc. `__, there are a wide variety of packages from the community supported
+`conda-forge project `__
+
+Note that :ref:`pip` can be installed into, and work side-by-side with conda
+for managing :term:`distributions ` from PyPI. It is also possible
+to build conda packages from Python source packages using tools such as
+`conda skeleton
+`__: a tool to automatically make conda packages from Python packages available on PyPI.
 
 .. _devpi:
 

From 7763ab9db0afa386cf992eb55e5054c7b5d0eda7 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Wed, 31 Jul 2024 17:53:50 -0700
Subject: [PATCH 0808/1072] added updated conda info to the scientific packages
 page.

---
 source/guides/installing-scientific-packages.rst | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst
index 5677d382a..654db3d62 100644
--- a/source/guides/installing-scientific-packages.rst
+++ b/source/guides/installing-scientific-packages.rst
@@ -134,5 +134,10 @@ native virtual environments. Conda makes environments first-class citizens,
 making it easy to create independent environments even for C libraries. It is
 written in Python, but is Python-agnostic. Conda manages Python itself as a
 package, so that :command:`conda update python` is possible, in contrast to
-pip, which only manages Python packages. Conda is available in Anaconda and
-Miniconda (an easy-to-install download with just Python and conda).
+pip, which only manages Python packages.
+
+The conda package manager is available in `Anaconda `_, `miniconda `_, `miniforge `_, and `pixi `_.
+
+Conda packages are available on multiple channels on Anaconda.org, including the
+default channel supported by Anaconda, Inc, and the community supported conda-forge
+channel, which provides a wide variety of pre-built packages.

From 43d4f09f319c43163f7f13aba9c41cbe4874acf1 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Mon, 19 Aug 2024 17:06:58 -0400
Subject: [PATCH 0809/1072] Update source/key_projects.rst

Co-authored-by: Alyssa Coghlan 
---
 source/key_projects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index 6c8e5d16a..7af8996a2 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -408,7 +408,7 @@ Conda is a package, dependency, and environment management system for any langua
 Ruby, C/C++, Fortran, and more. It is written in Python and
 widely used in the Python scientific computing community, due to its support for non-Python
 compiled libraries and extensions. It is used as the basis of the `Anaconda
-`__ Python distribution from `Anaconda, Inc.specifically
+`__ Python distribution from Anaconda, Inc. It waas originally
 aimed at the scientific community, community, but can also be used on its own, or with the
 :doc:`miniconda `, `miniforge `_ or
 `pixi `_ systems. It is available for Windows, Mac and Linux systems.

From b605abf5e715c4d1ad43a2c78ff2abe722c26afa Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Mon, 19 Aug 2024 17:07:45 -0400
Subject: [PATCH 0810/1072] Update source/key_projects.rst

Co-authored-by: Alyssa Coghlan 
---
 source/key_projects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index 7af8996a2..67bac3a54 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -409,7 +409,7 @@ Ruby, C/C++, Fortran, and more. It is written in Python and
 widely used in the Python scientific computing community, due to its support for non-Python
 compiled libraries and extensions. It is used as the basis of the `Anaconda
 `__ Python distribution from Anaconda, Inc. It waas originally
-aimed at the scientific community, community, but can also be used on its own, or with the
+aimed at the scientific community, but can also be used on its own, or with the
 :doc:`miniconda `, `miniforge `_ or
 `pixi `_ systems. It is available for Windows, Mac and Linux systems.
 

From fee8b5a054487347bdade0ffbfc26deeb355fe64 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Mon, 19 Aug 2024 17:08:09 -0400
Subject: [PATCH 0811/1072] Update source/key_projects.rst

Co-authored-by: Alyssa Coghlan 
---
 source/key_projects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index 67bac3a54..d8312e327 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -419,7 +419,7 @@ management and deployment of binary extensions and other binary code.
 
 Conda does not install packages from PyPI -- it can only manage packages built specifically
 for conda, which can be made available on a "conda channel", such as those hosted on
-`anaconda.org `__ or a local (e.g. intranet) package server.
+`anaconda.org `__, or a local (e.g. intranet) package server.
 In addition to the "default" channels managed by `Anaconda, Inc. `__, there are a wide variety of packages from the community supported
 `conda-forge project `__
 

From 485460ab87cd94dc00758b945ac23051988db090 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Mon, 19 Aug 2024 17:20:23 -0400
Subject: [PATCH 0812/1072] reworked intro paragraph to address duplicate
 links, and cleaner entry into conda vs. Anaconda.

---
 .../guides/installing-scientific-packages.rst | 20 ++++++++-----------
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst
index 654db3d62..2d3e99920 100644
--- a/source/guides/installing-scientific-packages.rst
+++ b/source/guides/installing-scientific-packages.rst
@@ -14,7 +14,7 @@ In particular, `NumPy `__, which provides the basis
 for most of the software in the `scientific Python stack
 `_ can be configured
 to interoperate with different FORTRAN libraries, and can take advantage
-of different levels of vectorised instructions available in modern CPUs.
+of different levels of vectorized instructions available in modern CPUs.
 
 Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built
 32-bit and 64-bit binaries in the ``wheel`` format are available for all major
@@ -118,17 +118,11 @@ be loaded and unloaded from the user's environment.
 The conda cross-platform package manager
 ----------------------------------------
 
-`Anaconda `_ is a Python distribution
-published by Anaconda, Inc. It is a stable collection of Open Source
-packages for big data and scientific use.  As of the 5.0 release of Anaconda,
-about 200 packages are installed by default, and a total of 400-500 can be
-installed and updated from the Anaconda repository.
-
 ``conda`` is an open source (BSD licensed) package management system and
-environment management system included in Anaconda that allows users to install
+environment management system that allows users to install
 multiple versions of binary software packages and their dependencies, and
 easily switch between them. It is a cross-platform tool working on Windows,
-macOS, and Linux. Conda can be used to package up and distribute all kinds of
+MacOS, and Linux. Conda can be used to package up and distribute all kinds of
 packages, it is not limited to just Python packages. It has full support for
 native virtual environments. Conda makes environments first-class citizens,
 making it easy to create independent environments even for C libraries. It is
@@ -136,8 +130,10 @@ written in Python, but is Python-agnostic. Conda manages Python itself as a
 package, so that :command:`conda update python` is possible, in contrast to
 pip, which only manages Python packages.
 
-The conda package manager is available in `Anaconda `_, `miniconda `_, `miniforge `_, and `pixi `_.
+Anaconda `Anaconda `_ is a Python distribution published by Anaconda, Inc. It is a stable collection of Open Source packages for big data and scientific use, and a collection of Graphical Interface utilities for managing conda environments.
+
+In addition to the full distribution provided by Anaconda, the conda package manager itself is available in  `miniconda `_, `miniforge `_, and `pixi `_.
+
 
 Conda packages are available on multiple channels on Anaconda.org, including the
-default channel supported by Anaconda, Inc, and the community supported conda-forge
-channel, which provides a wide variety of pre-built packages.
+default channel supported by Anaconda, Inc, the community supported conda-forge channel, which provides a wide variety of pre-built packages, and some domain-specific package collections.

From 2fee517b06a5c80af1fb6550b19c05c309f24974 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Mon, 19 Aug 2024 17:24:01 -0400
Subject: [PATCH 0813/1072] Update source/key_projects.rst

Co-authored-by: sinoroc <5529267+sinoroc@users.noreply.github.com>
---
 source/key_projects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index d8312e327..315897593 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -408,7 +408,7 @@ Conda is a package, dependency, and environment management system for any langua
 Ruby, C/C++, Fortran, and more. It is written in Python and
 widely used in the Python scientific computing community, due to its support for non-Python
 compiled libraries and extensions. It is used as the basis of the `Anaconda
-`__ Python distribution from Anaconda, Inc. It waas originally
+`__ Python distribution from Anaconda, Inc. It was originally
 aimed at the scientific community, but can also be used on its own, or with the
 :doc:`miniconda `, `miniforge `_ or
 `pixi `_ systems. It is available for Windows, Mac and Linux systems.

From 0f301cee5856a16238f573a69a8114dd9849e2f9 Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Mon, 19 Aug 2024 17:27:57 -0400
Subject: [PATCH 0814/1072] fixed netlib link

---
 source/guides/installing-scientific-packages.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst
index 2d3e99920..eded4fa5b 100644
--- a/source/guides/installing-scientific-packages.rst
+++ b/source/guides/installing-scientific-packages.rst
@@ -20,7 +20,7 @@ Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built
 32-bit and 64-bit binaries in the ``wheel`` format are available for all major
 operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on
 Windows, NumPy binaries are linked against the `ATLAS
-`__ BLAS/LAPACK library, restricted to SSE2
+`__ BLAS/LAPACK library, restricted to SSE2
 instructions, so they may not provide optimal linear algebra performance.
 
 There are a number of alternative options for obtaining scientific Python

From bc813837dae0650e22f5e276faa0afb864decd23 Mon Sep 17 00:00:00 2001
From: shenxianpeng 
Date: Wed, 30 Oct 2024 12:30:21 +0000
Subject: [PATCH 0815/1072] change pre-commit.ci autoupdate_schedule to
 quarterly

---
 .pre-commit-config.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index 785b392ab..db8b1131a 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -1,3 +1,6 @@
+ci:
+  autoupdate_schedule: quarterly
+
 repos:
 - repo: https://github.com/pre-commit/pre-commit-hooks
   rev: v5.0.0

From 5a59ab3ac44d50d83569ee48771f4dfc53dea18e Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Mon, 4 Nov 2024 09:31:43 -0800
Subject: [PATCH 0816/1072] slight edit to anaconda.org link

---
 source/key_projects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/key_projects.rst b/source/key_projects.rst
index 315897593..e4501fe0e 100644
--- a/source/key_projects.rst
+++ b/source/key_projects.rst
@@ -419,7 +419,7 @@ management and deployment of binary extensions and other binary code.
 
 Conda does not install packages from PyPI -- it can only manage packages built specifically
 for conda, which can be made available on a "conda channel", such as those hosted on
-`anaconda.org `__, or a local (e.g. intranet) package server.
+`anaconda.org `__, or a local (e.g. intranet) package server.
 In addition to the "default" channels managed by `Anaconda, Inc. `__, there are a wide variety of packages from the community supported
 `conda-forge project `__
 

From 4e1e75d28af15fc6cc095657654ec9e500d9bc2a Mon Sep 17 00:00:00 2001
From: Chris Barker 
Date: Mon, 4 Nov 2024 09:38:28 -0800
Subject: [PATCH 0817/1072] added https://anaconda.org to linkcheck-ignore --
 the link checker doesn't like it, but it's valid.

---
 source/conf.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/source/conf.py b/source/conf.py
index c777550ce..f4ec55093 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -133,6 +133,7 @@
     # https://github.com/pypa/packaging.python.org/pull/1474
     "https://stackoverflow.com/*",
     "https://pyscaffold.org/*",
+    "https://anaconda.org",
 ]
 linkcheck_retries = 5
 # Ignore anchors for links to GitHub project pages -- GitHub adds anchors from

From 3d0c2afb906cbb54a70848295b88e83ad73f78e7 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Fri, 8 Nov 2024 12:06:44 -0500
Subject: [PATCH 0818/1072] specifications: create living copy of PEP 740

Signed-off-by: William Woodruff 
---
 source/conf.py                                |   1 +
 .../index-hosted-attestations.rst             | 368 ++++++++++++++++++
 .../section-package-indices.rst               |   1 +
 .../specifications/simple-repository-api.rst  |  17 +-
 4 files changed, 386 insertions(+), 1 deletion(-)
 create mode 100644 source/specifications/index-hosted-attestations.rst

diff --git a/source/conf.py b/source/conf.py
index c777550ce..cd0f41302 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -193,6 +193,7 @@
     "tox": ("https://tox.wiki/en/latest/", None),
     "twine": ("https://twine.readthedocs.io/en/stable/", None),
     "virtualenv": ("https://virtualenv.pypa.io/en/stable/", None),
+    "warehouse": ("https://warehouse.pypa.io/", None),
 }
 
 # -- Options for todo extension --------------------------------------------------------
diff --git a/source/specifications/index-hosted-attestations.rst b/source/specifications/index-hosted-attestations.rst
new file mode 100644
index 000000000..395ffc10c
--- /dev/null
+++ b/source/specifications/index-hosted-attestations.rst
@@ -0,0 +1,368 @@
+
+.. _index-hosted-attestations:
+
+=========================
+Index hosted attestations
+=========================
+
+.. note:: This specification was originally defined in :pep:`740`.
+
+.. note::
+
+    :pep:`740` includes changes to the HTML and JSON index APIs.
+    These changes are documented in the :ref:`simple-repository-api`
+    under :ref:`simple-repository-api-base` and :ref:`json-serialization`.
+
+Specification
+=============
+
+.. _upload-endpoint:
+
+Upload endpoint changes
+-----------------------
+
+.. important::
+
+    The "legacy" upload API is not standardized.
+    See :ref:`Warehouse's Upload API documentation
+    ` for how attestations are uploaded.
+
+.. _attestation-object:
+
+Attestation objects
+-------------------
+
+An attestation object is a JSON object with several required keys; applications
+or signers may include additional keys so long as all explicitly
+listed keys are provided. The required layout of an attestation
+object is provided as pseudocode below.
+
+.. code-block:: python
+
+  @dataclass
+  class Attestation:
+      version: Literal[1]
+      """
+      The attestation object's version, which is always 1.
+      """
+
+      verification_material: VerificationMaterial
+      """
+      Cryptographic materials used to verify `envelope`.
+      """
+
+      envelope: Envelope
+      """
+      The enveloped attestation statement and signature.
+      """
+
+
+  @dataclass
+  class Envelope:
+      statement: bytes
+      """
+      The attestation statement.
+
+      This is represented as opaque bytes on the wire (encoded as base64),
+      but it MUST be an JSON in-toto v1 Statement.
+      """
+
+      signature: bytes
+      """
+      A signature for the above statement, encoded as base64.
+      """
+
+  @dataclass
+  class VerificationMaterial:
+      certificate: str
+      """
+      The signing certificate, as `base64(DER(cert))`.
+      """
+
+      transparency_entries: list[object]
+      """
+      One or more transparency log entries for this attestation's signature
+      and certificate.
+      """
+
+A full data model for each object in ``transparency_entries`` is provided in
+:ref:`appendix`. Attestation objects **SHOULD** include one or more
+transparency log entries, and **MAY** include additional keys for other
+sources of signed time (such as an :rfc:`3161` Time Stamping Authority or a
+`Roughtime `__ server).
+
+Attestation objects are versioned; this PEP specifies version 1. Each version
+is tied to a single cryptographic suite to minimize unnecessary cryptographic
+agility. In version 1, the suite is as follows:
+
+* Certificates are specified as X.509 certificates, and comply with the
+  profile in :rfc:`5280`.
+* The message signature algorithm is ECDSA, with the P-256 curve for public keys
+  and SHA-256 as the cryptographic digest function.
+
+Future PEPs may change this suite (and the overall shape of the attestation
+object) by selecting a new version number.
+
+.. _payload-and-signature-generation:
+
+Attestation statement and signature generation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The *attestation statement* is the actual claim that is cryptographically signed
+over within the attestation object (i.e., the ``envelope.statement``).
+
+The attestation statement is encoded as a
+`v1 in-toto Statement object `__,
+in JSON form. When serialized the statement is treated as an opaque binary blob,
+avoiding the need for canonicalization.
+
+In addition to being a v1 in-toto Statement, the attestation statement is constrained
+in the following ways:
+
+* The in-toto ``subject`` **MUST** contain only a single subject.
+* ``subject[0].name`` is the distribution's filename, which **MUST** be
+  a valid :ref:`source distribution ` or
+  :ref:`wheel distribution ` filename.
+* ``subject[0].digest`` **MUST** contain a SHA-256 digest. Other digests
+  **MAY** be present. The digests **MUST** be represented as hexadecimal strings.
+* The following ``predicateType`` values are supported:
+
+  * `SLSA Provenance `__: ``https://slsa.dev/provenance/v1``
+  * `PyPI Publish Attestation `__: ``https://docs.pypi.org/attestations/publish/v1``
+
+The signature over this statement is constructed using the
+`v1 DSSE signature protocol `__,
+with a ``PAYLOAD_TYPE`` of ``application/vnd.in-toto+json`` and a ``PAYLOAD_BODY`` of the JSON-encoded
+statement above. No other ``PAYLOAD_TYPE`` is permitted.
+
+.. _provenance-object:
+
+Provenance objects
+------------------
+
+The index will serve uploaded attestations along with metadata that can assist
+in verifying them in the form of JSON serialized objects.
+
+These *provenance objects* will be available via both the Simple Index
+and JSON-based Simple API as described above, and will have the following layout:
+
+.. code-block:: json
+
+    {
+        "version": 1,
+        "attestation_bundles": [
+          {
+            "publisher": {
+              "kind": "important-ci-service",
+              "claims": {},
+              "vendor-property": "foo",
+              "another-property": 123
+            },
+            "attestations": [
+              { /* attestation 1 ... */ },
+              { /* attestation 2 ... */ }
+            ]
+          }
+        ]
+    }
+
+or, as pseudocode:
+
+.. code-block:: python
+
+  @dataclass
+  class Publisher:
+      kind: string
+      """
+      The kind of Trusted Publisher.
+      """
+
+      claims: object | None
+      """
+      Any context-specific claims retained by the index during Trusted Publisher
+      authentication.
+      """
+
+      _rest: object
+      """
+      Each publisher object is open-ended, meaning that it MAY contain additional
+      fields beyond the ones specified explicitly above. This field signals that,
+      but is not itself present.
+      """
+
+  @dataclass
+  class AttestationBundle:
+      publisher: Publisher
+      """
+      The publisher associated with this set of attestations.
+      """
+
+      attestations: list[Attestation]
+      """
+      The set of attestations included in this bundle.
+      """
+
+  @dataclass
+  class Provenance:
+      version: Literal[1]
+      """
+      The provenance object's version, which is always 1.
+      """
+
+      attestation_bundles: list[AttestationBundle]
+      """
+      One or more attestation "bundles".
+      """
+
+* ``version`` is ``1``. Like attestation objects, provenance objects are
+  versioned, and this PEP only defines version ``1``.
+* ``attestation_bundles`` is a **required** JSON array, containing one
+  or more "bundles" of attestations. Each bundle corresponds to a
+  signing identity (such as a Trusted Publishing identity), and contains
+  one or more attestation objects.
+
+  As noted in the ``Publisher`` model,
+  each ``AttestationBundle.publisher`` object is specific to its Trusted Publisher
+  but must include at minimum:
+
+  * A ``kind`` key, which **MUST** be a JSON string that uniquely identifies the
+    kind of Trusted Publisher.
+  * A ``claims`` key, which **MUST** be a JSON object containing any context-specific
+    claims retained by the index during Trusted Publisher authentication.
+
+  All other keys in the publisher object are publisher-specific.
+
+  Each array of attestation objects is a superset of the ``attestations``
+  array supplied by the uploaded through the ``attestations`` field at upload
+  time, as described in :ref:`upload-endpoint` and
+  :ref:`changes-to-provenance-objects`.
+
+.. _changes-to-provenance-objects:
+
+Changes to provenance objects
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Provenance objects are *not* immutable, and may change over time. Reasons
+for changes to the provenance object include but are not limited to:
+
+* Addition of new attestations for a pre-existing signing identity: the index
+  **MAY** choose to allow additional attestations by pre-existing signing
+  identities, such as newer attestation versions for already uploaded
+  files.
+
+* Addition of new signing identities and associated attestations: the index
+  **MAY** choose to support attestations from sources other than the file's
+  uploader, such as third-party auditors or the index itself. These attestations
+  may be performed asynchronously, requiring the index to insert them into
+  the provenance object *post facto*.
+
+.. _attestation-verification:
+
+Attestation verification
+------------------------
+
+Verifying an attestation object against a distribution file requires verification of each of the
+following:
+
+* ``version`` is ``1``. The verifier **MUST** reject any other version.
+* ``verification_material.certificate`` is a valid signing certificate, as
+  issued by an *a priori* trusted authority (such as a root of trust already
+  present within the verifying client).
+* ``verification_material.certificate`` identifies an appropriate signing
+  subject, such as the machine identity of the Trusted Publisher that published
+  the package.
+* ``envelope.statement`` is a valid in-toto v1 Statement, with a subject
+  and digest that **MUST** match the distribution's filename and contents.
+  For the distribution's filename, matching **MUST** be performed by parsing
+  using the appropriate source distribution or wheel filename format, as
+  the statement's subject may be equivalent but normalized.
+* ``envelope.signature`` is a valid signature for ``envelope.statement``
+  corresponding to ``verification_material.certificate``,
+  as reconstituted via the
+  `v1 DSSE signature protocol `__.
+
+In addition to the above required steps, a verifier **MAY** additionally verify
+``verification_material.transparency_entries`` on a policy basis, e.g. requiring
+at least one transparency log entry or a threshold of entries. When verifying
+transparency entries, the verifier **MUST** confirm that the inclusion time for
+each entry lies within the signing certificate's validity period.
+
+.. _appendix:
+
+Appendix: Data models for Transparency Log Entries
+====================================================
+
+This appendix contains pseudocoded data models for transparency log entries
+in attestation objects. Each transparency log entry serves as a source
+of signed inclusion time, and can be verified either online or offline.
+
+.. code-block:: python
+
+  @dataclass
+  class TransparencyLogEntry:
+      log_index: int
+      """
+      The global index of the log entry, used when querying the log.
+      """
+
+      log_id: str
+      """
+      An opaque, unique identifier for the log.
+      """
+
+      entry_kind: str
+      """
+      The kind (type) of log entry.
+      """
+
+      entry_version: str
+      """
+      The version of the log entry's submitted format.
+      """
+
+      integrated_time: int
+      """
+      The UNIX timestamp from the log from when the entry was persisted.
+      """
+
+      inclusion_proof: InclusionProof
+      """
+      The actual inclusion proof of the log entry.
+      """
+
+
+  @dataclass
+  class InclusionProof:
+      log_index: int
+      """
+      The index of the entry in the tree it was written to.
+      """
+
+      root_hash: str
+      """
+      The digest stored at the root of the Merkle tree at the time of proof
+      generation.
+      """
+
+      tree_size: int
+      """
+      The size of the Merkle tree at the time of proof generation.
+      """
+
+      hashes: list[str]
+      """
+      A list of hashes required to complete the inclusion proof, sorted
+      in order from leaf to root. The leaf and root hashes are not themselves
+      included in this list; the root is supplied via `root_hash` and the client
+      must calculate the leaf hash.
+      """
+
+      checkpoint: str
+      """
+      The signed tree head's signature, at the time of proof generation.
+      """
+
+      cosigned_checkpoints: list[str]
+      """
+      Cosigned checkpoints from zero or more log witnesses.
+      """
diff --git a/source/specifications/section-package-indices.rst b/source/specifications/section-package-indices.rst
index 13ba98113..73004b4d3 100644
--- a/source/specifications/section-package-indices.rst
+++ b/source/specifications/section-package-indices.rst
@@ -7,3 +7,4 @@ Package Index Interfaces
 
    pypirc
    simple-repository-api
+   index-hosted-attestations
diff --git a/source/specifications/simple-repository-api.rst b/source/specifications/simple-repository-api.rst
index 0d65a58aa..9ec8e4bf2 100644
--- a/source/specifications/simple-repository-api.rst
+++ b/source/specifications/simple-repository-api.rst
@@ -96,6 +96,15 @@ In addition to the above, the following constraints are placed on the API:
   In the attribute value, < and > have to be HTML encoded as ``<`` and
   ``>``, respectively.
 
+* A repository **MAY** include a ``data-provenance`` attribute on a file link.
+  The value of this attribute **MUST** be a fully qualified URL, signaling that
+  the file's provenance can be found at that URL. This URL **MUST** represent
+  a `secure origin `_.
+
+  .. note::
+
+    The format of the linked provenance is defined in :ref:`index-hosted-attestations`.
+
 Normalized Names
 ----------------
 
@@ -495,6 +504,10 @@ Each individual file dictionary has the following keys:
   and is a truthy value, then it **SHOULD** be interpreted as indicating that the
   file pointed to by the ``url`` field has been "Yanked" as per :ref:`the API
   yank specification `.
+- ``provenance``: An **optional** key which, if present **MUST** be either a JSON
+  string or ``null``. If not ``null``, it **MUST** be a URL to the file's
+  associated provenance, with the same rules as ``data-provenance`` in the
+  :ref:`base HTML API specification `.
 
 As an example:
 
@@ -518,7 +531,8 @@ As an example:
           "url": "https://example.com/files/holygrail-1.0-py3-none-any.whl",
           "hashes": {"sha256": "...", "blake2b": "..."},
           "requires-python": ">=3.7",
-          "dist-info-metadata": true
+          "dist-info-metadata": true,
+          "provenance": "https://example.com/files/holygrail-1.0-py3-none-any.whl.provenance"
         }
       ]
     }
@@ -986,3 +1000,4 @@ History
   format, in :pep:`700`
 * June 2023: renaming the field which provides package metadata independently
   from a package, in :pep:`714`
+* November 2024: provenance metadata in the HTML and JSON formats, in :pep:`740`

From b8439b2cf6235ff8310df39b9a52b92983c01344 Mon Sep 17 00:00:00 2001
From: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Date: Sun, 10 Nov 2024 22:00:02 +0200
Subject: [PATCH 0819/1072] Use syntax highlighting for BigQuery queries

---
 source/guides/analyzing-pypi-package-downloads.rst | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/source/guides/analyzing-pypi-package-downloads.rst b/source/guides/analyzing-pypi-package-downloads.rst
index 5fecc99c1..2ad02fed5 100644
--- a/source/guides/analyzing-pypi-package-downloads.rst
+++ b/source/guides/analyzing-pypi-package-downloads.rst
@@ -103,7 +103,7 @@ Counting package downloads
 The following query counts the total number of downloads for the project
 "pytest".
 
-::
+.. code-block:: sql
 
     #standardSQL
     SELECT COUNT(*) AS num_downloads
@@ -123,7 +123,7 @@ The following query counts the total number of downloads for the project
 To count downloads from pip only, filter on the ``details.installer.name``
 column.
 
-::
+.. code-block:: sql
 
     #standardSQL
     SELECT COUNT(*) AS num_downloads
@@ -147,7 +147,7 @@ Package downloads over time
 To group by monthly downloads, use the ``TIMESTAMP_TRUNC`` function. Also
 filtering by this column reduces corresponding costs.
 
-::
+.. code-block:: sql
 
     #standardSQL
     SELECT
@@ -185,7 +185,7 @@ Python versions over time
 Extract the Python version from the ``details.python`` column. Warning: This
 query processes over 500 GB of data.
 
-::
+.. code-block:: sql
 
     #standardSQL
     SELECT
@@ -228,7 +228,7 @@ column, which includes the hash and artifact filename.
 .. note::
    The URL generated here is not guaranteed to be stable, but currently aligns with the URL where PyPI artifacts are hosted.
 
-::
+.. code-block:: sql
 
     SELECT
       CONCAT('https://files.pythonhosted.org/packages', path) as url

From b54b35da4af6f3eb56f24cee3076d9d14e39421d Mon Sep 17 00:00:00 2001
From: Anderson Bravalheri 
Date: Wed, 13 Nov 2024 16:50:49 +0000
Subject: [PATCH 0820/1072] Add simple issue template

---
 .github/ISSUE_TEMPLATE/config.yml  |  6 ++++++
 .github/ISSUE_TEMPLATE/general.yml | 25 +++++++++++++++++++++++++
 2 files changed, 31 insertions(+)
 create mode 100644 .github/ISSUE_TEMPLATE/config.yml
 create mode 100644 .github/ISSUE_TEMPLATE/general.yml

diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml
new file mode 100644
index 000000000..bd4d53ae7
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/config.yml
@@ -0,0 +1,6 @@
+blank_issues_enabled: false
+contact_links:
+  - name: "Community Guidelines"
+    url: "https://github.com/pypa/.github/blob/main/CODE_OF_CONDUCT.md"
+    about: "Please make sure to follow the PSF Code of Conduct when participating in this repository."
+
diff --git a/.github/ISSUE_TEMPLATE/general.yml b/.github/ISSUE_TEMPLATE/general.yml
new file mode 100644
index 000000000..356520c15
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/general.yml
@@ -0,0 +1,25 @@
+name: General Issue
+description: Please fill out the form below to submit an issue.
+labels: []
+assignees: []
+
+body:
+  - type: textarea
+    id: issue_description
+    attributes:
+      label: "Issue Description"
+      description: "Please provide a detailed description of your issue."
+      placeholder: "Describe your issue here..."
+      value: ""
+
+  - type: checkboxes
+    id: code_of_conduct
+    attributes:
+      label: Code of Conduct
+      description: |
+        **Please read the [PSF Code of Conduct][CoC] first.**
+        [CoC]: https://github.com/pypa/.github/blob/main/CODE_OF_CONDUCT.md
+      options:
+        - label: "I am aware that participants in this repository must follow the PSF Code of Conduct."
+          required: true
+

From 17c228847d8b6fa87a70b36d94c5c99895fe7522 Mon Sep 17 00:00:00 2001
From: Anderson Bravalheri 
Date: Wed, 13 Nov 2024 16:57:42 +0000
Subject: [PATCH 0821/1072] Make issue description mandatory

---
 .github/ISSUE_TEMPLATE/general.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.github/ISSUE_TEMPLATE/general.yml b/.github/ISSUE_TEMPLATE/general.yml
index 356520c15..8d75b88ef 100644
--- a/.github/ISSUE_TEMPLATE/general.yml
+++ b/.github/ISSUE_TEMPLATE/general.yml
@@ -11,6 +11,7 @@ body:
       description: "Please provide a detailed description of your issue."
       placeholder: "Describe your issue here..."
       value: ""
+      required: true
 
   - type: checkboxes
     id: code_of_conduct

From 8869f451492cdd32b7e483fcca6df1eb6b9eb43d Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Wed, 13 Nov 2024 17:04:09 +0000
Subject: [PATCH 0822/1072] [pre-commit.ci] auto fixes from pre-commit.com
 hooks

for more information, see https://pre-commit.ci
---
 .github/ISSUE_TEMPLATE/config.yml  | 1 -
 .github/ISSUE_TEMPLATE/general.yml | 1 -
 2 files changed, 2 deletions(-)

diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml
index bd4d53ae7..fbc581cd6 100644
--- a/.github/ISSUE_TEMPLATE/config.yml
+++ b/.github/ISSUE_TEMPLATE/config.yml
@@ -3,4 +3,3 @@ contact_links:
   - name: "Community Guidelines"
     url: "https://github.com/pypa/.github/blob/main/CODE_OF_CONDUCT.md"
     about: "Please make sure to follow the PSF Code of Conduct when participating in this repository."
-
diff --git a/.github/ISSUE_TEMPLATE/general.yml b/.github/ISSUE_TEMPLATE/general.yml
index 8d75b88ef..47fa75d7d 100644
--- a/.github/ISSUE_TEMPLATE/general.yml
+++ b/.github/ISSUE_TEMPLATE/general.yml
@@ -23,4 +23,3 @@ body:
       options:
         - label: "I am aware that participants in this repository must follow the PSF Code of Conduct."
           required: true
-

From c4195ad83188f0259501e0439084a3dc8997ba23 Mon Sep 17 00:00:00 2001
From: Anderson Bravalheri 
Date: Wed, 13 Nov 2024 22:45:38 +0000
Subject: [PATCH 0823/1072] Implement suggestions from code review

---
 .github/ISSUE_TEMPLATE/general.yml | 32 ++++++++++++++++++++----------
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/.github/ISSUE_TEMPLATE/general.yml b/.github/ISSUE_TEMPLATE/general.yml
index 47fa75d7d..4cfc57efb 100644
--- a/.github/ISSUE_TEMPLATE/general.yml
+++ b/.github/ISSUE_TEMPLATE/general.yml
@@ -4,22 +4,34 @@ labels: []
 assignees: []
 
 body:
+  - type: markdown
+    attributes:
+      value: |
+        **Thanks for taking a minute to file an issue!**
+
+        Read the [PSF Code of Conduct][CoC] first.
+        [CoC]: https://github.com/pypa/.github/blob/main/CODE_OF_CONDUCT.md
+
+        ⚠
+        Verify first that your issue is not [already reported on
+        GitHub][issue search].
+
+        _Please fill out the form below with as many precise
+        details as possible._
+
+        [issue search]: ../search?q=is%3Aissue&type=issues
+
   - type: textarea
-    id: issue_description
     attributes:
-      label: "Issue Description"
-      description: "Please provide a detailed description of your issue."
-      placeholder: "Describe your issue here..."
-      value: ""
+      label: Issue Description
+      description: Please provide a detailed description of your issue.
+      placeholder: Describe your issue here...
+    validations:
       required: true
 
   - type: checkboxes
-    id: code_of_conduct
     attributes:
       label: Code of Conduct
-      description: |
-        **Please read the [PSF Code of Conduct][CoC] first.**
-        [CoC]: https://github.com/pypa/.github/blob/main/CODE_OF_CONDUCT.md
       options:
-        - label: "I am aware that participants in this repository must follow the PSF Code of Conduct."
+        - label: I am aware that participants in this repository must follow the PSF Code of Conduct.
           required: true

From 3486a240d0e3e5235cc508284e430f69aff8de28 Mon Sep 17 00:00:00 2001
From: Anderson Bravalheri 
Date: Wed, 13 Nov 2024 22:46:50 +0000
Subject: [PATCH 0824/1072] Fix URL linking

---
 .github/ISSUE_TEMPLATE/general.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/ISSUE_TEMPLATE/general.yml b/.github/ISSUE_TEMPLATE/general.yml
index 4cfc57efb..d41731613 100644
--- a/.github/ISSUE_TEMPLATE/general.yml
+++ b/.github/ISSUE_TEMPLATE/general.yml
@@ -10,7 +10,6 @@ body:
         **Thanks for taking a minute to file an issue!**
 
         Read the [PSF Code of Conduct][CoC] first.
-        [CoC]: https://github.com/pypa/.github/blob/main/CODE_OF_CONDUCT.md
 
         ⚠
         Verify first that your issue is not [already reported on
@@ -19,6 +18,7 @@ body:
         _Please fill out the form below with as many precise
         details as possible._
 
+        [CoC]: https://github.com/pypa/.github/blob/main/CODE_OF_CONDUCT.md
         [issue search]: ../search?q=is%3Aissue&type=issues
 
   - type: textarea

From 11861f8c61bfa4d0a888226ec72ea25dbf93a981 Mon Sep 17 00:00:00 2001
From: Evan Kohilas 
Date: Fri, 15 Nov 2024 23:17:03 +1100
Subject: [PATCH 0825/1072] Update packaging-projects.rst for entering API
 token

---
 source/tutorials/packaging-projects.rst | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst
index 4c205e28f..93826321d 100644
--- a/source/tutorials/packaging-projects.rst
+++ b/source/tutorials/packaging-projects.rst
@@ -421,16 +421,15 @@ Once installed, run Twine to upload all of the archives under :file:`dist`:
 
         py -m twine upload --repository testpypi dist/*
 
-You will be prompted for a username and password. For the username,
-use ``__token__``. For the password, use the token value, including
-the ``pypi-`` prefix.
+You will be prompted for an API token. Use the token value, including the ``pypi-``
+prefix. Note that the input will be hidden, so be sure to paste correctly.
 
 After the command completes, you should see output similar to this:
 
 .. code-block::
 
     Uploading distributions to https://test.pypi.org/legacy/
-    Enter your username: __token__
+    Enter your API token:
     Uploading example_package_YOUR_USERNAME_HERE-0.0.1-py3-none-any.whl
     100% ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 8.2/8.2 kB • 00:01 • ?
     Uploading example_package_YOUR_USERNAME_HERE-0.0.1.tar.gz

From 685b68092eec6beecbccdaa996fb6b1128712a9f Mon Sep 17 00:00:00 2001
From: Karolina Surma 
Date: Mon, 18 Nov 2024 13:59:30 +0100
Subject: [PATCH 0826/1072] Fix the alphabetic order of terms in Glossary

---
 source/glossary.rst | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/source/glossary.rst b/source/glossary.rst
index 00d798e39..dc6211833 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -119,15 +119,6 @@ Glossary
         extensions.
 
 
-    Known Good Set (KGS)
-
-        A set of distributions at specified versions which are compatible with
-        each other. Typically a test suite will be run which passes all tests
-        before a specific set of packages is declared a known good set. This
-        term is commonly used by frameworks and toolkits which are comprised of
-        multiple individual distributions.
-
-
     Import Package
 
         A Python module which can contain other modules or recursively, other
@@ -147,6 +138,15 @@ Glossary
         as described in the specicifcation :ref:`recording-installed-packages`.
 
 
+    Known Good Set (KGS)
+
+        A set of distributions at specified versions which are compatible with
+        each other. Typically a test suite will be run which passes all tests
+        before a specific set of packages is declared a known good set. This
+        term is commonly used by frameworks and toolkits which are comprised of
+        multiple individual distributions.
+
+
     Module
 
         The basic unit of code reusability in Python, existing in one of two

From 1f4a641730e99a3c1df997ae94e1fc6219a74f6d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sviatoslav=20Sydorenko=20=28=D0=A1=D0=B2=D1=8F=D1=82=D0=BE?=
 =?UTF-8?q?=D1=81=D0=BB=D0=B0=D0=B2=20=D0=A1=D0=B8=D0=B4=D0=BE=D1=80=D0=B5?=
 =?UTF-8?q?=D0=BD=D0=BA=D0=BE=29?= 
Date: Thu, 10 Oct 2024 14:17:32 +0200
Subject: [PATCH 0827/1072] Add a label to pganssle's post link on deprecating
 `setup.py`

I noticed it as it ended up in the translation strings.
---
 source/discussions/setup-py-deprecated.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/setup-py-deprecated.rst b/source/discussions/setup-py-deprecated.rst
index 1c2eae3fa..a9fc70aa3 100644
--- a/source/discussions/setup-py-deprecated.rst
+++ b/source/discussions/setup-py-deprecated.rst
@@ -210,6 +210,6 @@ has now been reduced to the role of a build backend.
 Where to read more about this?
 ==============================
 
-* https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html
+* `Why you shouldn't invoke setup.py directly by Paul Ganssle `__
 
 * :doc:`setuptools:deprecated/commands`

From 39033e24c16bca7f7bd781bb00adee9f90f22bf8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sviatoslav=20Sydorenko=20=28=D0=A1=D0=B2=D1=8F=D1=82=D0=BE?=
 =?UTF-8?q?=D1=81=D0=BB=D0=B0=D0=B2=20=D0=A1=D0=B8=D0=B4=D0=BE=D1=80=D0=B5?=
 =?UTF-8?q?=D0=BD=D0=BA=D0=BE=29?= 
Date: Fri, 11 Oct 2024 00:54:38 +0200
Subject: [PATCH 0828/1072] Move Paul out of the link label

Co-authored-by: Pradyun Gedam 
---
 source/discussions/setup-py-deprecated.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/setup-py-deprecated.rst b/source/discussions/setup-py-deprecated.rst
index a9fc70aa3..6bcd15b58 100644
--- a/source/discussions/setup-py-deprecated.rst
+++ b/source/discussions/setup-py-deprecated.rst
@@ -210,6 +210,6 @@ has now been reduced to the role of a build backend.
 Where to read more about this?
 ==============================
 
-* `Why you shouldn't invoke setup.py directly by Paul Ganssle `__
+* `Why you shouldn't invoke setup.py directly `__ by Paul Ganssle
 
 * :doc:`setuptools:deprecated/commands`

From dcd35fd41dd3d7c29ead52084d75167b715aaed5 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Mon, 25 Nov 2024 09:39:23 -0500
Subject: [PATCH 0829/1072] fix upload API URL

Signed-off-by: William Woodruff 
---
 source/specifications/index-hosted-attestations.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/specifications/index-hosted-attestations.rst b/source/specifications/index-hosted-attestations.rst
index 395ffc10c..d078e87bd 100644
--- a/source/specifications/index-hosted-attestations.rst
+++ b/source/specifications/index-hosted-attestations.rst
@@ -24,8 +24,8 @@ Upload endpoint changes
 .. important::
 
     The "legacy" upload API is not standardized.
-    See :ref:`Warehouse's Upload API documentation
-    ` for how attestations are uploaded.
+    See `PyPI's Upload API documentation `_
+    for how attestations are uploaded.
 
 .. _attestation-object:
 

From 0655509a966c7641c473c32e5e85fe016d4885f2 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Mon, 25 Nov 2024 15:02:48 -0500
Subject: [PATCH 0830/1072] tool-recommendations: update Trusted Publisher
 providers

Signed-off-by: William Woodruff 
---
 source/guides/tool-recommendations.rst | 22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index 3903232b9..ece067993 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -139,15 +139,25 @@ to build distributable wheels.
 Uploading to PyPI
 =================
 
-For projects hosted on GitHub, it is recommended to use the :ref:`trusted publishing
-`, which allows the package to be securely uploaded to PyPI
-from a GitHub Actions job. (This is not yet supported on software forges other
-than GitHub.)
+For projects hosted on or published via supported CI/CD platforms, it is
+recommended to use the :ref:`Trusted Publishing `, which
+allows the package to be securely uploaded to PyPI from a CI/CD workflow
+without a manually configured API token.
+
+As of November 2024, PyPI supports the following platforms as Trusted Publishing
+providers:
+
+* GitHub Actions (on ``https://github.com``)
+* GitLab CI/CD (on ``https://gitlab.com``)
+* ActiveState
+* Google Cloud
 
 The other available method is to upload the package manually using :ref:`twine`.
 
-**Never** use ``python setup.py upload`` for this task. In addition to being
-:ref:`deprecated `, it is insecure.
+.. warning::
+
+    **Never** use ``python setup.py upload`` for this task. In addition to being
+    :ref:`deprecated `, it is insecure.
 
 
 Workflow tools

From e8193e1ce6e6d6dc77a80569ae20cf711e9a2ab1 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Mon, 25 Nov 2024 16:37:01 -0500
Subject: [PATCH 0831/1072] Update source/guides/tool-recommendations.rst
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: 🇺🇦 Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/guides/tool-recommendations.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index ece067993..1ba36ed61 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -154,7 +154,7 @@ providers:
 
 The other available method is to upload the package manually using :ref:`twine`.
 
-.. warning::
+.. danger::
 
     **Never** use ``python setup.py upload`` for this task. In addition to being
     :ref:`deprecated `, it is insecure.

From f86b4d08bce2febb2f65c627c0fb34bcfbfd90e0 Mon Sep 17 00:00:00 2001
From: Olavo Bacelar 
Date: Thu, 28 Nov 2024 23:42:38 +0100
Subject: [PATCH 0832/1072] fix: typo in installed project glossary

---
 source/glossary.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/glossary.rst b/source/glossary.rst
index dc6211833..43db5413a 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -135,7 +135,7 @@ Glossary
 
         A :term:`Project` that is installed for use with
         a Python interpreter or :term:`Virtual Environment`,
-        as described in the specicifcation :ref:`recording-installed-packages`.
+        as described in the specification :ref:`recording-installed-packages`.
 
 
     Known Good Set (KGS)

From 38f9bfb7c714931eb02b208cdaba0901bee710a7 Mon Sep 17 00:00:00 2001
From: konstin 
Date: Fri, 6 Dec 2024 10:24:12 +0100
Subject: [PATCH 0833/1072] Clarify that the scripts directory is for files
 only

Following https://github.com/astral-sh/uv/issues/9656 and the discussion in the pypa discord (https://discord.com/channels/803025117553754132/837243676814999553/1314391181656064040), add a clarifying sentence that the scripts directory in wheels if for files only.

A future specification may want to extend this to "regular files and symlinks", for not it's limited to regular for clear rewrite semantics.
---
 source/specifications/binary-distribution-format.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst
index 8da38357a..7b07dee81 100644
--- a/source/specifications/binary-distribution-format.rst
+++ b/source/specifications/binary-distribution-format.rst
@@ -189,7 +189,7 @@ its version, e.g. ``1.0.0``, consist of:
 #. Python scripts must appear in ``scripts`` and begin with exactly
    ``b'#!python'`` in order to enjoy script wrapper generation and
    ``#!python`` rewriting at install time.  They may have any or no
-   extension.
+   extension.  The ``scripts`` directory may only contain regular files.
 #. ``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1
    or greater format metadata.
 #. ``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive

From 40842ab77bd8d54db9f0d6e946ba90552e37a173 Mon Sep 17 00:00:00 2001
From: Alyssa Coghlan 
Date: Sun, 8 Dec 2024 14:37:24 +1000
Subject: [PATCH 0834/1072] Add a History note about the clarification

---
 source/specifications/binary-distribution-format.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst
index 7b07dee81..68f62639d 100644
--- a/source/specifications/binary-distribution-format.rst
+++ b/source/specifications/binary-distribution-format.rst
@@ -423,6 +423,10 @@ History
 - February 2013: This specification was approved through :pep:`427`.
 - February 2021: The rules on escaping in wheel filenames were revised, to bring
   them into line with what popular tools actually do.
+- December 2024: Clarified that the ``scripts`` folder should only contain
+  regular files (the expected behaviour of consuming tools when encountering
+  symlinks or subdirectories in this folder is not formally defined, and hence
+  may vary between tools).
 
 
 Appendix

From e45233770ba92fb1eff6bd4fee1baeca601f3686 Mon Sep 17 00:00:00 2001
From: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Date: Tue, 26 Nov 2024 11:14:07 +0200
Subject: [PATCH 0835/1072] Add view and edit buttons

---
 requirements.txt | 2 +-
 source/conf.py   | 5 +++++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/requirements.txt b/requirements.txt
index 077adb580..a3269a025 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1,4 +1,4 @@
-furo==2023.9.10
+furo==2024.8.6
 sphinx==7.2.6
 sphinx-autobuild==2021.3.14
 sphinx-inline-tabs==2023.4.21
diff --git a/source/conf.py b/source/conf.py
index ab14e315a..f08f6e836 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -62,6 +62,11 @@
 html_title = "Python Packaging User Guide"
 html_theme = "furo"
 
+html_theme_options = {
+    "source_edit_link": "https://github.com/pypa/packaging.python.org/edit/main/source/{filename}",
+    "source_view_link": "https://github.com/pypa/packaging.python.org/blob/main/source/{filename}?plain=true",
+}
+
 html_favicon = "assets/py.png"
 html_last_updated_fmt = ""
 

From 99af225ab240808564fb9c9967aba346d4742199 Mon Sep 17 00:00:00 2001
From: Stephen Rosen 
Date: Mon, 16 Dec 2024 12:55:56 -0600
Subject: [PATCH 0836/1072] Add doc for dependency-groups, import from PEP

This content is copied from the PEP, with the following
characteristics:
- the initial overview and examples are new
- the "History" footer is new
- all of the other sections are copied from the PEP verbatim
---
 source/specifications/dependency-groups.rst   | 272 ++++++++++++++++++
 .../section-distribution-metadata.rst         |   1 +
 2 files changed, 273 insertions(+)
 create mode 100644 source/specifications/dependency-groups.rst

diff --git a/source/specifications/dependency-groups.rst b/source/specifications/dependency-groups.rst
new file mode 100644
index 000000000..8206a7063
--- /dev/null
+++ b/source/specifications/dependency-groups.rst
@@ -0,0 +1,272 @@
+.. _dependency-groups:
+
+=================
+Dependency Groups
+=================
+
+This specification defines Dependency Groups, a mechanism for storing package
+requirements in ``pyproject.toml`` files such that they are not included in
+project metadata when it is built.
+
+Dependency Groups are suitable for internal development use-cases like linting
+and testing, as well as for projects which are not built for distribution, like
+collections of related scripts.
+
+Fundamentally, Dependency Groups should be thought of as being a standardized
+subset of the capabilities of ``requirements.txt`` files (which are
+``pip``-specific).
+
+Specification
+=============
+
+Examples
+--------
+
+This is a simple table which shows a ``test`` group::
+
+    [dependency-groups]
+    test = ["pytest>7", "coverage"]
+
+and a similar table which defines ``test`` and ``coverage`` groups::
+
+    [dependency-groups]
+    coverage = ["coverage[toml]"]
+    test = ["pytest>7", {include-group = "coverage"}]
+
+The ``[dependency-groups]`` Table
+---------------------------------
+
+This PEP defines a new section (table) in ``pyproject.toml`` files named
+``dependency-groups``. The ``dependency-groups`` table contains an arbitrary
+number of user-defined keys, each of which has, as its value, a list of
+requirements (defined below). These keys must be
+`valid non-normalized names `__,
+and must be
+`normalized `__
+before comparisons.
+
+Tools SHOULD prefer to present the original, non-normalized name to users by
+default. If duplicate names, after normalization, are encountered, tools SHOULD
+emit an error.
+
+Requirement lists under ``dependency-groups`` may contain strings, tables
+("dicts" in Python), or a mix of strings and tables.
+
+Strings in requirement lists must be valid
+`Dependency Specifiers `__,
+as defined in :pep:`508`.
+
+Tables in requirement lists must be valid Dependency Object Specifiers.
+
+Dependency Object Specifiers
+----------------------------
+
+Dependency Object Specifiers are tables which define zero or more dependencies.
+
+This PEP standardizes only one type of Dependency Object Specifier, a
+"Dependency Group Include". Other types may be added in future standards.
+
+Dependency Group Include
+''''''''''''''''''''''''
+
+A Dependency Group Include includes the dependencies of another Dependency
+Group in the current Dependency Group.
+
+An include is defined as a table with exactly one key, ``"include-group"``,
+whose value is a string, the name of another Dependency Group.
+
+For example, ``{include-group = "test"}`` is an include which expands to the
+contents of the ``test`` Dependency Group.
+
+Includes are defined to be exactly equivalent to the contents of the named
+Dependency Group, inserted into the current group at the location of the include.
+For example, if ``foo = ["a", "b"]`` is one group, and
+``bar = ["c", {include-group = "foo"}, "d"]`` is another, then ``bar`` should
+evaluate to ``["c", "a", "b", "d"]`` when Dependency Group Includes are expanded.
+
+Dependency Group Includes may specify the same package multiple times. Tools
+SHOULD NOT deduplicate or otherwise alter the list contents produced by the
+include. For example, given the following table:
+
+.. code:: toml
+
+    [dependency-groups]
+    group-a = ["foo"]
+    group-b = ["foo>1.0"]
+    group-c = ["foo<1.0"]
+    all = ["foo", {include-group = "group-a"}, {include-group = "group-b"}, {include-group = "group-c"}]
+
+The resolved value of ``all`` SHOULD be ``["foo", "foo", "foo>1.0", "foo<1.0"]``.
+Tools should handle such a list exactly as they would handle any other case in
+which they are asked to process the same requirement multiple times with
+different version constraints.
+
+Dependency Group Includes may include lists containing Dependency Group
+Includes, in which case those includes should be expanded as well. Dependency
+Group Includes MUST NOT include cycles, and tools SHOULD report an error if
+they detect a cycle.
+
+Package Building
+----------------
+
+Build backends MUST NOT include Dependency Group data in built distributions as
+package metadata. This means that PKG-INFO in sdists and METADATA in wheels
+do not include any referencable fields containing Dependency Groups.
+
+It is valid to use Dependency Groups in the evaluation of dynamic metadata, and
+``pyproject.toml`` files included in sdists will naturally still contain the
+``[dependency-groups]`` table. However, the table contents are not part of a
+published package's interfaces.
+
+Installing Dependency Groups
+----------------------------
+
+Tools which support Dependency Groups are expected to provide new options and
+interfaces to allow users to install from Dependency Groups.
+
+No syntax is defined for expressing the Dependency Group of a package, for two
+reasons:
+
+* it would not be valid to refer to the Dependency Groups of a third-party
+  package from PyPI (because the data is defined to be unpublished)
+
+* there is not guaranteed to be a current package for Dependency Groups -- part
+  of their purpose is to support non-package projects
+
+For example, a possible pip interface for installing Dependency Groups
+would be:
+
+.. code:: shell
+
+    pip install --dependency-groups=test,typing
+
+Note that this is only an example. This PEP does not declare any requirements
+for how tools support the installation of Dependency Groups.
+
+Overlapping Install UX with Extras
+''''''''''''''''''''''''''''''''''
+
+Tools MAY choose to provide the same interfaces for installing Dependency
+Groups as they do for installing extras.
+
+Note that this specification does not forbid having an extra whose name matches
+a Dependency Group.
+
+Users are advised to avoid creating Dependency Groups whose names match extras.
+Tools MAY treat such matching as an error.
+
+Validation and Compatibility
+----------------------------
+
+Tools supporting Dependency Groups may want to validate data before using it.
+However, tools implementing such validation behavior should be careful to allow
+for future expansions to this spec, so that they do not unnecessarily emit
+errors or warnings in the presence of new syntax.
+
+Tools SHOULD error when evaluating or processing unrecognized data in
+Dependency Groups.
+
+Tools SHOULD NOT eagerly validate the list contents of **all** Dependency
+Groups.
+
+This means that in the presence of the following data, most tools will allow
+the ``foo`` group to be used, and will only error when the ``bar`` group is
+used:
+
+Reference Implementation
+========================
+
+The following Reference Implementation prints the contents of a Dependency
+Group to stdout, newline delimited.
+The output is therefore valid ``requirements.txt`` data.
+
+.. code-block:: python
+
+    import re
+    import sys
+    import tomllib
+    from collections import defaultdict
+
+    from packaging.requirements import Requirement
+
+
+    def _normalize_name(name: str) -> str:
+        return re.sub(r"[-_.]+", "-", name).lower()
+
+
+    def _normalize_group_names(dependency_groups: dict) -> dict:
+        original_names = defaultdict(list)
+        normalized_groups = {}
+
+        for group_name, value in dependency_groups.items():
+            normed_group_name = _normalize_name(group_name)
+            original_names[normed_group_name].append(group_name)
+            normalized_groups[normed_group_name] = value
+
+        errors = []
+        for normed_name, names in original_names.items():
+            if len(names) > 1:
+                errors.append(f"{normed_name} ({', '.join(names)})")
+        if errors:
+            raise ValueError(f"Duplicate dependency group names: {', '.join(errors)}")
+
+        return normalized_groups
+
+
+    def _resolve_dependency_group(
+        dependency_groups: dict, group: str, past_groups: tuple[str, ...] = ()
+    ) -> list[str]:
+        if group in past_groups:
+            raise ValueError(f"Cyclic dependency group include: {group} -> {past_groups}")
+
+        if group not in dependency_groups:
+            raise LookupError(f"Dependency group '{group}' not found")
+
+        raw_group = dependency_groups[group]
+        if not isinstance(raw_group, list):
+            raise ValueError(f"Dependency group '{group}' is not a list")
+
+        realized_group = []
+        for item in raw_group:
+            if isinstance(item, str):
+                # packaging.requirements.Requirement parsing ensures that this is a valid
+                # PEP 508 Dependency Specifier
+                # raises InvalidRequirement on failure
+                Requirement(item)
+                realized_group.append(item)
+            elif isinstance(item, dict):
+                if tuple(item.keys()) != ("include-group",):
+                    raise ValueError(f"Invalid dependency group item: {item}")
+
+                include_group = _normalize_name(next(iter(item.values())))
+                realized_group.extend(
+                    _resolve_dependency_group(
+                        dependency_groups, include_group, past_groups + (group,)
+                    )
+                )
+            else:
+                raise ValueError(f"Invalid dependency group item: {item}")
+
+        return realized_group
+
+
+    def resolve(dependency_groups: dict, group: str) -> list[str]:
+        if not isinstance(dependency_groups, dict):
+            raise TypeError("Dependency Groups table is not a dict")
+        if not isinstance(group, str):
+            raise TypeError("Dependency group name is not a str")
+        return _resolve_dependency_group(dependency_groups, group)
+
+
+    if __name__ == "__main__":
+        with open("pyproject.toml", "rb") as fp:
+            pyproject = tomllib.load(fp)
+
+        dependency_groups_raw = pyproject["dependency-groups"]
+        dependency_groups = _normalize_group_names(dependency_groups_raw)
+        print("\n".join(resolve(pyproject["dependency-groups"], sys.argv[1])))
+
+History
+=======
+
+- October 2024: This specification was approved through :pep:`735`.
diff --git a/source/specifications/section-distribution-metadata.rst b/source/specifications/section-distribution-metadata.rst
index 0c0a8aaba..af7c1c3e6 100644
--- a/source/specifications/section-distribution-metadata.rst
+++ b/source/specifications/section-distribution-metadata.rst
@@ -10,6 +10,7 @@ Package Distribution Metadata
    version-specifiers
    dependency-specifiers
    pyproject-toml
+   dependency-groups
    inline-script-metadata
    platform-compatibility-tags
    well-known-project-urls

From bb6f6cc042950bc052fe98bdba8768acd1b19563 Mon Sep 17 00:00:00 2001
From: Stephen Rosen 
Date: Mon, 16 Dec 2024 13:00:44 -0600
Subject: [PATCH 0837/1072] Refine dependency-groups documentation

This is a significant revision from the PEP content to make the
content appropriate for the packaging specs. In particular, the
following changes are made:

- references to "this PEP" are all removed
- "Dependency Object Specifiers" are a layer of indirection around
  includes, and are removed from the documentation -- instead, the doc
  jumps straight to the (only) specific case now: the includes
- the section on install UX and extras has been rewritten for brevity,
  removing the hypothetical example `pip` interface and folding
  together the install notes and the notes about extras
- the section on validation/linting has been reorganized around an
  example, and the note on linters has been moved to a `note`
  admonition block
---
 source/specifications/dependency-groups.rst | 154 +++++++++-----------
 1 file changed, 66 insertions(+), 88 deletions(-)

diff --git a/source/specifications/dependency-groups.rst b/source/specifications/dependency-groups.rst
index 8206a7063..b6a3e6fad 100644
--- a/source/specifications/dependency-groups.rst
+++ b/source/specifications/dependency-groups.rst
@@ -36,47 +36,33 @@ and a similar table which defines ``test`` and ``coverage`` groups::
 The ``[dependency-groups]`` Table
 ---------------------------------
 
-This PEP defines a new section (table) in ``pyproject.toml`` files named
+Dependency Groups are defined as a table in ``pyproject.toml`` named
 ``dependency-groups``. The ``dependency-groups`` table contains an arbitrary
 number of user-defined keys, each of which has, as its value, a list of
-requirements (defined below). These keys must be
-`valid non-normalized names `__,
-and must be
-`normalized `__
-before comparisons.
+requirements.
 
-Tools SHOULD prefer to present the original, non-normalized name to users by
-default. If duplicate names, after normalization, are encountered, tools SHOULD
-emit an error.
+``[dependency-groups]`` keys, sometimes also called "group names", must be
+:ref:`valid non-normalized names `. Tools which handle Dependency
+Groups MUST :ref:`normalize ` these names before
+comparisons.
 
-Requirement lists under ``dependency-groups`` may contain strings, tables
-("dicts" in Python), or a mix of strings and tables.
+Tools SHOULD prefer to present the original, non-normalized name to users, and
+if duplicate names are detected after normalization, tools SHOULD emit an
+error.
 
-Strings in requirement lists must be valid
-`Dependency Specifiers `__,
-as defined in :pep:`508`.
-
-Tables in requirement lists must be valid Dependency Object Specifiers.
-
-Dependency Object Specifiers
-----------------------------
-
-Dependency Object Specifiers are tables which define zero or more dependencies.
-
-This PEP standardizes only one type of Dependency Object Specifier, a
-"Dependency Group Include". Other types may be added in future standards.
+Requirement lists, the values in ``[dependency-groups]``, may contain strings,
+tables (``dict`` in Python), or a mix of strings and tables. Strings must be
+valid :ref:`dependency specifiers `, and tables must be
+valid Dependency Group Includes.
 
 Dependency Group Include
-''''''''''''''''''''''''
-
-A Dependency Group Include includes the dependencies of another Dependency
-Group in the current Dependency Group.
+------------------------
 
-An include is defined as a table with exactly one key, ``"include-group"``,
-whose value is a string, the name of another Dependency Group.
+A Dependency Group Include includes another Dependency Group in the current
+group.
 
-For example, ``{include-group = "test"}`` is an include which expands to the
-contents of the ``test`` Dependency Group.
+An include is a table with exactly one key, ``"include-group"``, whose value is
+a string, the name of another Dependency Group.
 
 Includes are defined to be exactly equivalent to the contents of the named
 Dependency Group, inserted into the current group at the location of the include.
@@ -84,94 +70,86 @@ For example, if ``foo = ["a", "b"]`` is one group, and
 ``bar = ["c", {include-group = "foo"}, "d"]`` is another, then ``bar`` should
 evaluate to ``["c", "a", "b", "d"]`` when Dependency Group Includes are expanded.
 
-Dependency Group Includes may specify the same package multiple times. Tools
-SHOULD NOT deduplicate or otherwise alter the list contents produced by the
+Dependency Group Includes may specify the same package multiple times.
+Tools SHOULD NOT deduplicate or otherwise alter the list contents produced by the
 include. For example, given the following table:
 
-.. code:: toml
+.. code-block:: toml
 
     [dependency-groups]
     group-a = ["foo"]
     group-b = ["foo>1.0"]
     group-c = ["foo<1.0"]
-    all = ["foo", {include-group = "group-a"}, {include-group = "group-b"}, {include-group = "group-c"}]
+    all = [
+        "foo",
+        {include-group = "group-a"},
+        {include-group = "group-b"},
+        {include-group = "group-c"},
+    ]
 
 The resolved value of ``all`` SHOULD be ``["foo", "foo", "foo>1.0", "foo<1.0"]``.
 Tools should handle such a list exactly as they would handle any other case in
 which they are asked to process the same requirement multiple times with
 different version constraints.
 
-Dependency Group Includes may include lists containing Dependency Group
-Includes, in which case those includes should be expanded as well. Dependency
-Group Includes MUST NOT include cycles, and tools SHOULD report an error if
-they detect a cycle.
+Dependency Group Includes may include groups containing Dependency Group Includes,
+in which case those includes should be expanded as well. Dependency Group Includes
+MUST NOT include cycles, and tools SHOULD report an error if they detect a cycle.
 
 Package Building
 ----------------
 
 Build backends MUST NOT include Dependency Group data in built distributions as
-package metadata. This means that PKG-INFO in sdists and METADATA in wheels
-do not include any referencable fields containing Dependency Groups.
-
-It is valid to use Dependency Groups in the evaluation of dynamic metadata, and
-``pyproject.toml`` files included in sdists will naturally still contain the
-``[dependency-groups]`` table. However, the table contents are not part of a
-published package's interfaces.
-
-Installing Dependency Groups
-----------------------------
-
-Tools which support Dependency Groups are expected to provide new options and
-interfaces to allow users to install from Dependency Groups.
-
-No syntax is defined for expressing the Dependency Group of a package, for two
-reasons:
+package metadata. This means that sdist ``PKG-INFO`` and wheel ``METADATA``
+files should not include referenceable fields containing Dependency Groups.
 
-* it would not be valid to refer to the Dependency Groups of a third-party
-  package from PyPI (because the data is defined to be unpublished)
+It is, however, valid to use Dependency Groups in the evaluation of dynamic
+metadata, and ``pyproject.toml`` files included in sdists will still contain
+``[dependency-groups]``. However, the table's contents are not part of a built
+package's interfaces.
 
-* there is not guaranteed to be a current package for Dependency Groups -- part
-  of their purpose is to support non-package projects
+Installing Dependency Groups & Extras
+-------------------------------------
 
-For example, a possible pip interface for installing Dependency Groups
-would be:
+There is no syntax or specification-defined interface for installing or
+referring to Dependency Groups. Tools are expected to provide dedicated
+interfaces for this purpose.
 
-.. code:: shell
-
-    pip install --dependency-groups=test,typing
-
-Note that this is only an example. This PEP does not declare any requirements
-for how tools support the installation of Dependency Groups.
-
-Overlapping Install UX with Extras
-''''''''''''''''''''''''''''''''''
-
-Tools MAY choose to provide the same interfaces for installing Dependency
-Groups as they do for installing extras.
-
-Note that this specification does not forbid having an extra whose name matches
-a Dependency Group.
-
-Users are advised to avoid creating Dependency Groups whose names match extras.
-Tools MAY treat such matching as an error.
+Tools MAY choose to provide the same or similar interfaces for interacting
+with Dependency Groups as they do for managing extras. Tools authors are
+advised that the specification does not forbid having an extra whose name
+matches a Dependency Group. Separately, users are advised to avoid creating
+Dependency Groups whose names match extras, and tools MAY treat such matching
+as an error.
 
 Validation and Compatibility
 ----------------------------
 
 Tools supporting Dependency Groups may want to validate data before using it.
-However, tools implementing such validation behavior should be careful to allow
-for future expansions to this spec, so that they do not unnecessarily emit
-errors or warnings in the presence of new syntax.
+When implementing such validation, authors should be aware of the possibility
+of future extensions to the specification, so that they do not unnecessarily
+emit errors or warnings.
 
 Tools SHOULD error when evaluating or processing unrecognized data in
 Dependency Groups.
 
-Tools SHOULD NOT eagerly validate the list contents of **all** Dependency
-Groups.
+Tools SHOULD NOT eagerly validate the contents of *all* Dependency Groups
+unless they have a need to do so.
+
+This means that in the presence of the following data, most tools should allow
+the ``foo`` group to be used and only error if the ``bar`` group is used:
+
+.. code-block:: toml
+
+    [dependency-groups]
+    foo = ["pyparsing"]
+    bar = [{set-phasers-to = "stun"}]
+
+.. note::
 
-This means that in the presence of the following data, most tools will allow
-the ``foo`` group to be used, and will only error when the ``bar`` group is
-used:
+    There are several known cases of tools which have good cause to be
+    stricter. Linters and validators are an example, as their purpose is to
+    validate the contents of all Dependency Groups.
 
 Reference Implementation
 ========================

From 5e4e015fb665cd7d2d748705a4266a702c30b046 Mon Sep 17 00:00:00 2001
From: Alex Tomkins 
Date: Sun, 22 Dec 2024 20:32:57 +0000
Subject: [PATCH 0838/1072] Use environment variables instead of contexts

Fixes potential issues found by zizmor: https://github.com/woodruffw/zizmor
---
 .../github-actions-ci-cd-sample/publish-to-test-pypi.yml  | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
index 152597d49..5c4b3edcf 100644
--- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
+++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
@@ -78,8 +78,8 @@ jobs:
         GITHUB_TOKEN: ${{ github.token }}
       run: >-
         gh release create
-        '${{ github.ref_name }}'
-        --repo '${{ github.repository }}'
+        "$GITHUB_REF_NAME"
+        --repo "$GITHUB_REPOSITORY"
         --notes ""
     - name: Upload artifact signatures to GitHub Release
       env:
@@ -89,8 +89,8 @@ jobs:
       # sigstore-produced signatures and certificates.
       run: >-
         gh release upload
-        '${{ github.ref_name }}' dist/**
-        --repo '${{ github.repository }}'
+        "$GITHUB_REF_NAME" dist/**
+        --repo "$GITHUB_REPOSITORY"
 
   publish-to-testpypi:
     name: Publish Python 🐍 distribution 📦 to TestPyPI

From 6a1376f1e2c823e969cf608f712dbfa6b3d6e64d Mon Sep 17 00:00:00 2001
From: Alex Tomkins 
Date: Sun, 22 Dec 2024 20:49:10 +0000
Subject: [PATCH 0839/1072] Don't persist GitHub credentials after checkout

Fixes potential issue found by zizmor: https://github.com/woodruffw/zizmor
---
 .../guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
index 5c4b3edcf..7051540ef 100644
--- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
+++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
@@ -9,6 +9,8 @@ jobs:
 
     steps:
     - uses: actions/checkout@v4
+      with:
+        persist-credentials: false
     - name: Set up Python
       uses: actions/setup-python@v5
       with:

From 085b29c2604695cfd7f30c47f220a98c0cbad69c Mon Sep 17 00:00:00 2001
From: Alyssa Coghlan 
Date: Mon, 23 Dec 2024 13:02:10 +1000
Subject: [PATCH 0840/1072] Ignore PyPI anchors when checking links

Closes #1744
---
 source/conf.py | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/source/conf.py b/source/conf.py
index f08f6e836..c73dabdf2 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -141,11 +141,13 @@
     "https://anaconda.org",
 ]
 linkcheck_retries = 5
-# Ignore anchors for links to GitHub project pages -- GitHub adds anchors from
-# README.md headings through JavaScript, so Sphinx's linkcheck can't find them
-# in the HTML.
+# Ignore anchors for common targets when we know they likely won't be found
 linkcheck_anchors_ignore_for_url = [
+    # GitHub synthesises anchors in JavaScript, so Sphinx can't find them in the HTML
     r"https://github\.com/",
+    # While PyPI has its botscraping defenses active, Sphinx can't resolve the anchors
+    # https://github.com/pypa/packaging.python.org/issues/1744
+    r"https://pypi\.org/",
 ]
 
 # -- Options for extlinks ----------------------------------------------------------

From 8eb247b5501362eb763e5939c91b50aa54a1407b Mon Sep 17 00:00:00 2001
From: Dustin Ingram 
Date: Thu, 2 Jan 2025 18:23:49 +0000
Subject: [PATCH 0841/1072] Add and configure zizmor

---
 .github/workflows/zizmor.yml | 38 ++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)
 create mode 100644 .github/workflows/zizmor.yml

diff --git a/.github/workflows/zizmor.yml b/.github/workflows/zizmor.yml
new file mode 100644
index 000000000..d99b6473c
--- /dev/null
+++ b/.github/workflows/zizmor.yml
@@ -0,0 +1,38 @@
+# From https://woodruffw.github.io/zizmor/usage/#use-in-github-actions
+
+name: GitHub Actions Security Analysis with zizmor 🌈
+
+on:
+  push:
+    branches: ["main"]
+  pull_request:
+    branches: ["**"]
+
+jobs:
+  zizmor:
+    name: zizmor latest via PyPI
+    runs-on: ubuntu-latest
+    permissions:
+      security-events: write
+      # required for workflows in private repositories
+      contents: read
+      actions: read
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+        with:
+          persist-credentials: false
+
+      - name: Install the latest version of uv
+        uses: astral-sh/setup-uv@v5
+
+      - name: Run zizmor 🌈
+        run: uvx zizmor --format sarif source/guides/github-actions-ci-cd-sample/* > results.sarif
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Upload SARIF file
+        uses: github/codeql-action/upload-sarif@v3
+        with:
+          sarif_file: results.sarif
+          category: zizmor

From 5889433636e4e51a4ed54b0f9cd2ca63569d929d Mon Sep 17 00:00:00 2001
From: Gregory Bell 
Date: Sat, 4 Jan 2025 14:37:36 -0700
Subject: [PATCH 0842/1072] Correct typo in docs for project.scripts

---
 source/guides/writing-pyproject-toml.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index a497842a1..63aac1010 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -236,7 +236,7 @@ To install a command as part of your package, declare it in the
 
 In this example, after installing your project, a ``spam-cli`` command
 will be available. Executing this command will do the equivalent of
-``from spam import main_cli; main_cli()``.
+``from spam import main_cli; exit(main_cli())``.
 
 On Windows, scripts packaged this way need a terminal, so if you launch
 them from within a graphical application, they will make a terminal pop

From 1ce29502ec3d942267041f56ae69a2c191322e2d Mon Sep 17 00:00:00 2001
From: Dustin Ingram 
Date: Mon, 6 Jan 2025 16:46:49 -0500
Subject: [PATCH 0843/1072] Fix link with missing anchor tag

This page has changed significantly, linking to the entire page probably makes more sense instead now.
---
 source/guides/installing-scientific-packages.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst
index eded4fa5b..a1aeae567 100644
--- a/source/guides/installing-scientific-packages.rst
+++ b/source/guides/installing-scientific-packages.rst
@@ -89,7 +89,7 @@ SciPy distributions
 -------------------
 
 The SciPy site lists `several distributions
-`_
+`_
 that provide the full SciPy stack to
 end users in an easy to use and update format.
 

From e5fe84238d578a65d9cc1a64066877dc1ecaf231 Mon Sep 17 00:00:00 2001
From: Karolina Surma 
Date: Mon, 18 Nov 2024 13:58:21 +0100
Subject: [PATCH 0844/1072] Introduce licensing terms in Glossary

Copied and adapted from PEP 639.
---
 source/glossary.rst | 51 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/source/glossary.rst b/source/glossary.rst
index dc6211833..2ce4b1bfd 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -147,6 +147,40 @@ Glossary
         multiple individual distributions.
 
 
+    License Classifier
+
+        A PyPI Trove classifier
+        (as :ref:`described `
+        in the :term:`Core Metadata` specification)
+        which begins with ``License ::``.
+
+
+    License Expression
+    SPDX Expression
+
+        A string with valid SPDX license expression syntax,
+        including one or more SPDX :term:`License Identifier`\(s),
+        which describes a :term:`Project`'s license(s)
+        and how they inter-relate.
+        Examples:
+        ``GPL-3.0-or-later``,
+        ``MIT AND (Apache-2.0 OR BSD-2-Clause)``
+
+
+    License Identifier
+    SPDX Identifier
+
+        A valid SPDX short-form license identifier,
+        originally specified in :pep:`639`.
+        This includes all valid SPDX identifiers and
+        the custom ``LicenseRef-[idstring]`` strings conforming to the
+        SPDX specification.
+        Examples:
+        ``MIT``,
+        ``GPL-3.0-only``,
+        ``LicenseRef-My-Custom-License``
+
+
     Module
 
         The basic unit of code reusability in Python, existing in one of two
@@ -313,6 +347,23 @@ Glossary
        docs on :ref:`pip:Requirements Files`.
 
 
+    Root License Directory
+    License Directory
+
+        The directory under which license files are stored in a
+        :term:`Project Source Tree`, :term:`Distribution Archive`
+        or :term:`Installed Project`.
+        For a :term:`Project Source Tree` or
+        :term:`Source Distribution (or "sdist")`, this is the
+        :term:`Project Root Directory`.
+        For a :term:`Built Distribution` or :term:`Installed Project`,
+        this is the :file:`.dist-info/licenses/` directory of
+        the wheel archive or project folder respectively.
+        Also, the root directory that paths
+        recorded in the ``License-File``
+        :term:`Core Metadata Field` are relative to.
+
+
     setup.py
     setup.cfg
 

From b55403272c274eef06f6003992c35a9358c5da06 Mon Sep 17 00:00:00 2001
From: Karolina Surma 
Date: Mon, 18 Nov 2024 14:56:02 +0100
Subject: [PATCH 0845/1072] Update pyproject.toml specification according to
 PEP 639

Redefine the license key, add license-files, mention that license
classifiers are deprecated now.
---
 source/specifications/pyproject-toml.rst | 79 +++++++++++++++++++++---
 1 file changed, 71 insertions(+), 8 deletions(-)

diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 400e43105..7e575b9aa 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -138,6 +138,7 @@ The complete list of keys allowed in the ``[project]`` table are:
 - ``gui-scripts``
 - ``keywords``
 - ``license``
+- ``license-files``
 - ``maintainers``
 - ``name``
 - ``optional-dependencies``
@@ -236,16 +237,70 @@ The Python version requirements of the project.
 ``license``
 -----------
 
-- TOML_ type: table
+- TOML_ type: string
+- Corresponding :ref:`core metadata ` field:
+  :ref:`License-Expression `
+
+Text string that is a valid SPDX license expression as defined in :pep:`639`.
+Tools SHOULD validate and perform case normalization of the expression.
+
+The table subkeys of the ``license`` key are deprecated.
+
+
+``license-files``
+-----------------
+
+- TOML_ type: array of strings
 - Corresponding :ref:`core metadata ` field:
-  :ref:`License `
+  :ref:`License-Expression `
+
+An array specifying paths in the project source tree relative to the project
+root directory (i.e. directory containing :file:`pyproject.toml` or legacy project
+configuration files, e.g. :file:`setup.py`, :file:`setup.cfg`, etc.)
+to file(s) containing licenses and other legal notices to be
+distributed with the package.
+
+The strings MUST contain valid glob patterns, as specified below:
 
-The table may have one of two keys. The ``file`` key has a string
-value that is a file path relative to ``pyproject.toml`` to the file
-which contains the license for the project. Tools MUST assume the
-file's encoding is UTF-8. The ``text`` key has a string value which is
-the license of the project.  These keys are mutually exclusive, so a
-tool MUST raise an error if the metadata specifies both keys.
+- Alphanumeric characters, underscores (``_``), hyphens (``-``) and dots (``.``)
+  MUST be matched verbatim.
+
+- Special glob characters: ``*``, ``?``, ``**`` and character ranges: ``[]``
+  containing only the verbatim matched characters MUST be supported.
+  Within ``[...]``, the hyphen indicates a locale-agnostic range (e.g. ``a-z``,
+  order based on Unicode code points).
+  Hyphens at the start or end are matched literally.
+
+- Path delimiters MUST be the forward slash character (``/``).
+  Patterns are relative to the directory containing :file:`pyproject.toml`,
+  therefore the leading slash character MUST NOT be used.
+
+- Parent directory indicators (``..``) MUST NOT be used.
+
+Any characters or character sequences not covered by this specification are
+invalid. Projects MUST NOT use such values.
+Tools consuming this field SHOULD reject invalid values with an error.
+
+Tools MUST assume that license file content is valid UTF-8 encoded text,
+and SHOULD validate this and raise an error if it is not.
+
+Literal paths (e.g. :file:`LICENSE`) are valid globs which means they
+can also be defined.
+
+Build tools:
+
+- MUST treat each value as a glob pattern, and MUST raise an error if the
+  pattern contains invalid glob syntax.
+- MUST include all files matched by a listed pattern in all distribution
+  archives.
+- MUST list each matched file path under a License-File field in the
+  Core Metadata.
+- MUST raise an error if any individual user-specified pattern does not match
+  at least one file.
+
+If the ``license-files`` key is present and
+is set to a value of an empty array, then tools MUST NOT include any
+license files and MUST NOT raise an error.
 
 
 ``authors``/``maintainers``
@@ -309,6 +364,12 @@ The keywords for the project.
 
 Trove classifiers which apply to the project.
 
+The use of ``License ::`` classifiers is deprecated and tools MAY issue a
+warning informing users about that.
+Build tools MAY raise an error if both the ``license`` string value
+(translating to ``License-Expression`` metadata field) and the ``License ::``
+classifiers are used.
+
 
 ``urls``
 --------
@@ -450,6 +511,8 @@ History
 - November 2020: The specification of the ``[project]`` table was approved
   through :pep:`621`.
 
+- December 2024: The ``license`` key was redefined, the ``license-files`` key was
+  added and ``License::`` classifiers were deprecated through :pep:`639`.
 
 
 .. _TOML: https://toml.io

From b466436ad03bbe8446619b47e1069fef8acedeec Mon Sep 17 00:00:00 2001
From: Karolina Surma 
Date: Tue, 19 Nov 2024 09:41:48 +0100
Subject: [PATCH 0846/1072] Document inclusion of license files in the sdist
 per PEP 639

---
 source/specifications/source-distribution-format.rst | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/source/specifications/source-distribution-format.rst b/source/specifications/source-distribution-format.rst
index bae618df1..5e4d608b4 100644
--- a/source/specifications/source-distribution-format.rst
+++ b/source/specifications/source-distribution-format.rst
@@ -58,10 +58,15 @@ A ``.tar.gz`` source distribution (sdist) contains a single top-level directory
 called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of
 the package. The name and version MUST match the metadata stored in the file.
 This directory must also contain a :file:`pyproject.toml` in the format defined in
-:ref:`pyproject-toml-spec`, and a ``PKG-INFO`` file containing
+:ref:`pyproject-toml-spec`, and a :file:`PKG-INFO` file containing
 metadata in the format described in the :ref:`core-metadata` specification. The
 metadata MUST conform to at least version 2.2 of the metadata specification.
 
+If the metadata version is 2.4 or greater, the source distribution MUST contain
+any license files specified by the ``License-File`` field in the :file:`PKG-INFO`
+at their respective paths relative to the root directory of the sdist
+(containing the :file:`pyproject.toml` and the :file:`PKG-INFO` metadata).
+
 No other content of a sdist is required or defined. Build systems can store
 whatever information they need in the sdist to build the project.
 
@@ -150,3 +155,5 @@ History
   :pep:`625`.
 * August 2023: Source distribution archive features were standardized through
   :pep:`721`.
+* December 2024: License files inclusion into source distribution was standardized
+  through :pep:`639`.

From f999ef0a220b23ac1c6f5041a43bd682f1aad6af Mon Sep 17 00:00:00 2001
From: Karolina Surma 
Date: Tue, 19 Nov 2024 11:50:44 +0100
Subject: [PATCH 0847/1072] Document inclusion of license files in the
 .dist-info/licenses per PEP 639
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: 🇺🇦 Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 .../specifications/binary-distribution-format.rst   | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst
index 68f62639d..be21aedcd 100644
--- a/source/specifications/binary-distribution-format.rst
+++ b/source/specifications/binary-distribution-format.rst
@@ -182,6 +182,7 @@ its version, e.g. ``1.0.0``, consist of:
    ``purelib`` or ``platlib`` as specified in ``WHEEL``.  ``purelib`` and
    ``platlib`` are usually both ``site-packages``.
 #. ``{distribution}-{version}.dist-info/`` contains metadata.
+#. :file:`{distribution}-{version}.dist-info/licenses/` contains license files.
 #. ``{distribution}-{version}.data/`` contains one subdirectory
    for each non-empty install scheme key not already covered, where
    the subdirectory name is an index into a dictionary of install paths
@@ -250,6 +251,16 @@ The .dist-info directory
    mentioned and correctly hashed in RECORD.
 
 
+The :file:`.dist-info/licenses/` directory
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If the metadata version is 2.4 or greater and one or more ``License-File``
+fields is specified, the :file:`.dist-info/` directory MUST contain a
+:file:`licenses/` subdirectory, which MUST contain the files listed in the
+``License-File`` fields in the :file:`METADATA` file at their respective paths
+relative to the :file:`licenses/` directory.
+
+
 The .data directory
 ^^^^^^^^^^^^^^^^^^^
 
@@ -427,6 +438,8 @@ History
   regular files (the expected behaviour of consuming tools when encountering
   symlinks or subdirectories in this folder is not formally defined, and hence
   may vary between tools).
+- December 2024: The :file:`.dist-info/licenses/` directory was specified through
+  :pep:`639`.
 
 
 Appendix

From cdf84bacf4ba20ff29af8ef080ea1bf345be13c5 Mon Sep 17 00:00:00 2001
From: Karolina Surma 
Date: Tue, 19 Nov 2024 12:58:10 +0100
Subject: [PATCH 0848/1072] Document how to install .dist-info/licenses per PEP
 639
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: 🇺🇦 Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 .../recording-installed-packages.rst          | 20 ++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/source/specifications/recording-installed-packages.rst b/source/specifications/recording-installed-packages.rst
index ee8e69f79..9e01ef6f1 100644
--- a/source/specifications/recording-installed-packages.rst
+++ b/source/specifications/recording-installed-packages.rst
@@ -66,6 +66,11 @@ The ``METADATA`` file is mandatory.
 All other files may be omitted at the installing tool's discretion.
 Additional installer-specific files may be present.
 
+This :file:`.dist-info/` directory may contain the following directory, described in
+detail below:
+
+* :file:`licenses/`: contains license files.
+
 .. note::
 
    The :ref:`binary-distribution-format` specification describes additional
@@ -144,7 +149,7 @@ Here is an example snippet of a possible ``RECORD`` file::
     __pycache__/black.cpython-38.pyc,,
     __pycache__/blackd.cpython-38.pyc,,
     black-19.10b0.dist-info/INSTALLER,sha256=zuuue4knoyJ-UwPPXg8fezS7VCrXJQrAP7zeNuwvFQg,4
-    black-19.10b0.dist-info/LICENSE,sha256=nAQo8MO0d5hQz1vZbhGqqK_HLUqG1KNiI9erouWNbgA,1080
+    black-19.10b0.dist-info/licenses/LICENSE,sha256=nAQo8MO0d5hQz1vZbhGqqK_HLUqG1KNiI9erouWNbgA,1080
     black-19.10b0.dist-info/METADATA,sha256=UN40nGoVVTSpvLrTBwNsXgZdZIwoKFSrrDDHP6B7-A0,58841
     black-19.10b0.dist-info/RECORD,,
     black.py,sha256=45IF72OgNfF8WpeNHnxV2QGfbCLubV5Xjl55cI65kYs,140161
@@ -219,6 +224,17 @@ of requirement (i.e. name plus version specifier).
 Its detailed specification is at :ref:`direct-url`.
 
 
+The :file:`licenses/` subdirectory
+==================================
+
+If the metadata version is 2.4 or greater and one or more ``License-File``
+fields is specified, the :file:`.dist-info/` directory MUST contain a :file:`licenses/`
+subdirectory which MUST contain the files listed in the ``License-File`` fields in
+the :file:`METADATA` file at their respective paths relative to the
+:file:`licenses/` directory.
+Any files in this directory MUST be copied from wheels by the install tools.
+
+
 Intentionally preventing changes to installed packages
 ======================================================
 
@@ -259,3 +275,5 @@ History
   for the full definition.
 - September 2020: Various amendments and clarifications were approved through
   :pep:`627`.
+- December 2024: The :file:`.dist-info/licenses/` directory was specified through
+  :pep:`639`.

From a8f6ba6c2b691e6d2d4047bda6c669686a485359 Mon Sep 17 00:00:00 2001
From: Karolina Surma 
Date: Tue, 19 Nov 2024 15:13:34 +0100
Subject: [PATCH 0849/1072] Update the Writing pyproject.toml guide with new
 licensing guidelines

---
 source/guides/writing-pyproject-toml.rst | 61 ++++++++++++++++++------
 1 file changed, 47 insertions(+), 14 deletions(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index a497842a1..dd962d5f1 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -324,26 +324,59 @@ You can also specify the format explicitly, like this:
 ``license``
 -----------
 
-This can take two forms. You can put your license in a file, typically
-``LICENSE`` or ``LICENSE.txt``, and link that file here:
+This is a valid :term:`SPDX license expression ` consisting
+of one or more :term:`license identifiers `.
+The full license list is available at the
+`SPDX license list page `_. The supported list version is
+3.17 or any later compatible one.
 
 .. code-block:: toml
 
     [project]
-    license = {file = "LICENSE"}
+    license = "GPL-3.0-or-later"
+    # or
+    license = "MIT AND (Apache-2.0 OR BSD-2-Clause)"
 
-or you can write the name of the license:
+As a general rule, it is a good idea to use a standard, well-known
+license, both to avoid confusion and because some organizations avoid software
+whose license is unapproved.
+
+If your project is licensed with a license that doesn't have an existing SPDX
+identifier, you can create a custom one in format ``LicenseRef-[idstring]``.
+The custom identifiers must follow the SPDX specification,
+`clause 10.1 `_ of the version 2.2 or any later compatible one.
 
 .. code-block:: toml
 
     [project]
-    license = {text = "MIT License"}
+    license = "LicenseRef-My-Custom-License"
 
-If you are using a standard, well-known license, it is not necessary to use this
-field. Instead, you should use one of the :ref:`classifiers` starting with ``License
-::``. (As a general rule, it is a good idea to use a standard, well-known
-license, both to avoid confusion and because some organizations avoid software
-whose license is unapproved.)
+
+``license-files``
+-----------------
+
+This is a list of license files and files containing other legal
+information you want to distribute with your package.
+
+.. code-block:: toml
+
+    [project]
+    license-files = ["LICEN[CS]E*", "vendored/licenses/*.txt", "AUTHORS.md"]
+
+The glob patterns must follow the specification:
+
+- Alphanumeric characters, underscores (``_``), hyphens (``-``) and dots (``.``)
+  will be matched verbatim.
+- Special characters: ``*``, ``?``, ``**`` and character ranges: [] are supported.
+- Path delimiters must be the forward slash character (``/``).
+- Patterns are relative to the directory containing :file:`pyproject.toml`, and
+  thus may not start with a slash character.
+- Parent directory indicators (``..``) must not be used.
+- Each glob must match at least one file.
+
+Literal paths are valid globs.
+Any characters or character sequences not covered by this specification are
+invalid.
 
 
 ``keywords``
@@ -379,9 +412,6 @@ A list of PyPI classifiers that apply to your project. Check the
       "Intended Audience :: Developers",
       "Topic :: Software Development :: Build Tools",
 
-      # Pick your license as you wish (see also "license" above)
-      "License :: OSI Approved :: MIT License",
-
       # Specify the Python versions you support here.
       "Programming Language :: Python :: 3",
       "Programming Language :: Python :: 3.6",
@@ -498,7 +528,8 @@ A full example
    ]
    description = "Lovely Spam! Wonderful Spam!"
    readme = "README.rst"
-   license = {file = "LICENSE.txt"}
+   license = "MIT"
+   license-files = ["LICEN[CS]E.*"]
    keywords = ["egg", "bacon", "sausage", "tomatoes", "Lobster Thermidor"]
    classifiers = [
      "Development Status :: 4 - Beta",
@@ -545,3 +576,5 @@ A full example
 .. _pytest: https://pytest.org
 .. _pygments: https://pygments.org
 .. _rest: https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html
+.. _spdxcustomids: https://spdx.github.io/spdx-spec/v2.2.2/other-licensing-information-detected/
+.. _spdxlicenselist: https://spdx.org/licenses/

From dd5ed07f3ceea67e396e182d516af5d29d6d92e2 Mon Sep 17 00:00:00 2001
From: Karolina Surma 
Date: Tue, 19 Nov 2024 15:32:08 +0100
Subject: [PATCH 0850/1072] Add the licensing examples and user scenarios
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Adapted from:
- https://peps.python.org/pep-0639/appendix-examples/
- https://peps.python.org/pep-0639/appendix-user-scenarios/

Co-authored-by: 🇺🇦 Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 .../licensing-examples-and-user-scenarios.rst | 356 ++++++++++++++++++
 source/guides/section-build-and-publish.rst   |   1 +
 2 files changed, 357 insertions(+)
 create mode 100644 source/guides/licensing-examples-and-user-scenarios.rst

diff --git a/source/guides/licensing-examples-and-user-scenarios.rst b/source/guides/licensing-examples-and-user-scenarios.rst
new file mode 100644
index 000000000..5b05d97ea
--- /dev/null
+++ b/source/guides/licensing-examples-and-user-scenarios.rst
@@ -0,0 +1,356 @@
+.. _licensing-examples-and-user-scenarios:
+
+
+=====================================
+Licensing examples and user scenarios
+=====================================
+
+
+:pep:`639` has specified the way to declare a project's license and paths to
+license files and other legally required information.
+This document aims to provide clear guidance how to migrate from the legacy
+to the standardized way of declaring licenses.
+
+
+Licensing Examples
+==================
+
+.. _licensing-example-basic:
+
+Basic example
+-------------
+
+The Setuptools project itself, as of `version 75.6.0 `__,
+does not use the ``License`` field in its own project source metadata.
+Further, it no longer explicitly specifies ``license_file``/``license_files``
+as it did previously, since Setuptools relies on its own automatic
+inclusion of license-related files matching common patterns,
+such as the :file:`LICENSE` file it uses.
+
+It includes the following license-related metadata in its
+:file:`pyproject.toml`:
+
+.. code-block:: toml
+
+    [project]
+    classifiers = [
+        "License :: OSI Approved :: MIT License"
+    ]
+
+The simplest migration to PEP 639 would consist of using this instead:
+
+.. code-block:: toml
+
+    [project]
+    license = "MIT"
+
+Or, if the project used :file:`setup.cfg`, in its ``[metadata]`` table:
+
+.. code-block:: ini
+
+    [metadata]
+    license = MIT
+
+The output Core Metadata for the distribution packages would then be:
+
+.. code-block:: email
+
+    License-Expression: MIT
+    License-File: LICENSE
+
+The :file:`LICENSE` file would be stored at :file:`/setuptools-{VERSION}/LICENSE`
+in the sdist and :file:`/setuptools-{VERSION}.dist-info/licenses/LICENSE`
+in the wheel, and unpacked from there into the site directory (e.g.
+:file:`site-packages/`) on installation; :file:`/` is the root of the respective archive
+and ``{VERSION}`` the version of the Setuptools release in the Core Metadata.
+
+
+.. _licensing-example-advanced:
+
+Advanced example
+----------------
+
+Suppose Setuptools were to include the licenses of the third-party projects
+that are vendored in the :file:`setuptools/_vendor/` and :file:`pkg_resources/_vendor/`
+directories; specifically:
+
+.. code-block:: text
+
+    packaging==21.2
+    pyparsing==2.2.1
+    ordered-set==3.1.1
+    more_itertools==8.8.0
+
+The license expressions for these projects are:
+
+.. code-block:: text
+
+    packaging: Apache-2.0 OR BSD-2-Clause
+    pyparsing: MIT
+    ordered-set: MIT
+    more_itertools: MIT
+
+A comprehensive license expression covering both Setuptools
+proper and its vendored dependencies would contain these metadata,
+combining all the license expressions into one. Such an expression might be:
+
+.. code-block:: text
+
+    MIT AND (Apache-2.0 OR BSD-2-Clause)
+
+In addition, per the requirements of the licenses, the relevant license files
+must be included in the package. Suppose the :file:`LICENSE` file contains the text
+of the MIT license and the copyrights used by Setuptools, ``pyparsing``,
+``more_itertools`` and ``ordered-set``; and the :file:`LICENSE*` files in the
+:file:`setuptools/_vendor/packaging/` directory contain the Apache 2.0 and
+2-clause BSD license text, and the Packaging copyright statement and
+`license choice notice `__.
+
+Specifically, we assume the license files are located at the following
+paths in the project source tree (relative to the project root and
+:file:`pyproject.toml`):
+
+.. code-block:: text
+
+    LICENSE
+    setuptools/_vendor/packaging/LICENSE
+    setuptools/_vendor/packaging/LICENSE.APACHE
+    setuptools/_vendor/packaging/LICENSE.BSD
+
+Putting it all together, our :file:`pyproject.toml` would be:
+
+.. code-block:: toml
+
+    [project]
+    license = "MIT AND (Apache-2.0 OR BSD-2-Clause)"
+    license-files = [
+        "LICENSE*",
+        "setuptools/_vendor/LICENSE*",
+    ]
+
+Or alternatively, the license files can be specified explicitly (paths will be
+interpreted as glob patterns):
+
+.. code-block:: toml
+
+    [project]
+    license = "MIT AND (Apache-2.0 OR BSD-2-Clause)"
+    license-files = [
+        "LICENSE",
+        "setuptools/_vendor/LICENSE",
+        "setuptools/_vendor/LICENSE.APACHE",
+        "setuptools/_vendor/LICENSE.BSD",
+    ]
+
+If our project used :file:`setup.cfg`, we could define this in :
+
+.. code-block:: ini
+
+    [metadata]
+    license = MIT AND (Apache-2.0 OR BSD-2-Clause)
+    license_files =
+        LICENSE
+        setuptools/_vendor/packaging/LICENSE
+        setuptools/_vendor/packaging/LICENSE.APACHE
+        setuptools/_vendor/packaging/LICENSE.BSD
+
+With either approach, the output Core Metadata in the distribution
+would be:
+
+.. code-block:: email
+
+    License-Expression: MIT AND (Apache-2.0 OR BSD-2-Clause)
+    License-File: LICENSE
+    License-File: setuptools/_vendor/packaging/LICENSE
+    License-File: setuptools/_vendor/packaging/LICENSE.APACHE
+    License-File: setuptools/_vendor/packaging/LICENSE.BSD
+
+In the resulting sdist, with :file:`/` as the root of the archive and ``{VERSION}``
+the version of the Setuptools release specified in the Core Metadata,
+the license files would be located at the paths:
+
+.. code-block:: text
+
+    /setuptools-{VERSION}/LICENSE
+    /setuptools-{VERSION}/setuptools/_vendor/packaging/LICENSE
+    /setuptools-{VERSION}/setuptools/_vendor/packaging/LICENSE.APACHE
+    /setuptools-{VERSION}/setuptools/_vendor/packaging/LICENSE.BSD
+
+In the built wheel, with :file:`/` being the root of the archive and
+``{VERSION}`` as the previous, the license files would be stored at:
+
+.. code-block:: text
+
+    /setuptools-{VERSION}.dist-info/licenses/LICENSE
+    /setuptools-{VERSION}.dist-info/licenses/setuptools/_vendor/packaging/LICENSE
+    /setuptools-{VERSION}.dist-info/licenses/setuptools/_vendor/packaging/LICENSE.APACHE
+    /setuptools-{VERSION}.dist-info/licenses/setuptools/_vendor/packaging/LICENSE.BSD
+
+Finally, in the installed project, with :file:`site-packages/` being the site dir
+and ``{VERSION}`` as the previous, the license files would be installed to:
+
+.. code-block:: text
+
+    site-packages/setuptools-{VERSION}.dist-info/licenses/LICENSE
+    site-packages/setuptools-{VERSION}.dist-info/licenses/setuptools/_vendor/packaging/LICENSE
+    site-packages/setuptools-{VERSION}.dist-info/licenses/setuptools/_vendor/packaging/LICENSE.APACHE
+    site-packages/setuptools-{VERSION}.dist-info/licenses/setuptools/_vendor/packaging/LICENSE.BSD
+
+
+Expression examples
+'''''''''''''''''''
+
+Some additional examples of valid ``License-Expression`` values:
+
+.. code-block:: email
+
+    License-Expression: MIT
+    License-Expression: BSD-3-Clause
+    License-Expression: MIT AND (Apache-2.0 OR BSD-2-Clause)
+    License-Expression: MIT OR GPL-2.0-or-later OR (FSFUL AND BSD-2-Clause)
+    License-Expression: GPL-3.0-only WITH Classpath-Exception-2.0 OR BSD-3-Clause
+    License-Expression: LicenseRef-Public-Domain OR CC0-1.0 OR Unlicense
+    License-Expression: LicenseRef-Proprietary
+    License-Expression: LicenseRef-Custom-License
+
+
+User Scenarios
+==============
+
+The following covers the range of common use cases from a user perspective,
+providing guidance for each. Do note that the following
+should **not** be considered legal advice, and readers should consult a
+licensed legal practitioner in their jurisdiction if they are unsure about
+the specifics for their situation.
+
+
+I have a private package that won't be distributed
+--------------------------------------------------
+
+If your package isn't shared publicly, i.e. outside your company,
+organization or household, it *usually* isn't strictly necessary to include
+a formal license, so you wouldn't necessarily have to do anything extra here.
+
+However, it is still a good idea to include ``LicenseRef-Proprietary``
+as a license expression in your package configuration, and/or a
+copyright statement and any legal notices in a :file:`LICENSE.txt` file
+in the root of your project directory, which will be automatically
+included by packaging tools.
+
+
+I just want to share my own work without legal restrictions
+-----------------------------------------------------------
+
+While you aren't required to include a license, if you don't, no one has
+`any permission to download, use or improve your work `__,
+so that's probably the *opposite* of what you actually want.
+The `MIT license `__ is a great choice instead, as it's simple,
+widely used and allows anyone to do whatever they want with your work
+(other than sue you, which you probably also don't want).
+
+To apply it, just paste `the text `__ into a file named
+:file:`LICENSE.txt` at the root of your repo, and add the year and your name to
+the copyright line. Then, just add ``license = "MIT"`` under
+``[project]`` in your :file:`pyproject.toml` if your packaging tool supports it,
+or in its config file/section. You're done!
+
+
+I want to distribute my project under a specific license
+--------------------------------------------------------
+
+To use a particular license, simply paste its text into a :file:`LICENSE.txt`
+file at the root of your repo, if you don't have it in a file starting with
+:file:`LICENSE` or :file:`COPYING` already, and add
+``license = "LICENSE-ID"`` under ``[project]`` in your
+:file:`pyproject.toml` if your packaging tool supports it, or else in its
+config file. You can find the ``LICENSE-ID``
+and copyable license text on sites like
+`ChooseALicense `__ or `SPDX `__.
+
+Many popular code hosts, project templates and packaging tools can add the
+license file for you, and may support the expression as well in the future.
+
+
+I maintain an existing package that's already licensed
+------------------------------------------------------
+
+If you already have license files and metadata in your project, you
+should only need to make a couple of tweaks to take advantage of the new
+functionality.
+
+In your project config file, enter your license expression under
+``license`` (``[project]`` table in :file:`pyproject.toml`),
+or the equivalent for your packaging tool,
+and make sure to remove any legacy ``license`` table subkeys or
+``License ::`` classifiers. Your existing ``license`` value may already
+be valid as one (e.g. ``MIT``, ``Apache-2.0 OR BSD-2-Clause``, etc);
+otherwise, check the `SPDX license list `__ for the identifier
+that matches the license used in your project.
+
+Make sure to list your license files under ``license-files``
+under ``[project]`` in :file:`pyproject.toml`
+or else in your tool's configuration file.
+
+See the :ref:`licensing-example-basic` for a simple but complete real-world demo
+of how this works in practice.
+See also the best-effort guidance on how to translate license classifiers
+into license expression provided by the :pep:`639` authors:
+`Mapping License Classifiers to SPDX Identifiers `__.
+Packaging tools may support automatically converting legacy licensing
+metadata; check your tool's documentation for more information.
+
+
+My package includes other code under different licenses
+-------------------------------------------------------
+
+If your project includes code from others covered by different licenses,
+such as vendored dependencies or files copied from other open source
+software, you can construct a license expression
+to describe the licenses involved and the relationship
+between them.
+
+In short, ``License-1 AND License-2`` mean that *both* licenses apply
+to your project, or parts of it (for example, you included a file
+under another license), and ``License-1 OR License-2`` means that
+*either* of the licenses can be used, at the user's option (for example,
+you want to allow users a choice of multiple licenses). You can use
+parenthesis (``()``) for grouping to form expressions that cover even the most
+complex situations.
+
+In your project config file, enter your license expression under
+``license`` (``[project]`` table of :file:`pyproject.toml`),
+or the equivalent for your packaging tool,
+and make sure to remove any legacy ``license`` table subkeys
+or ``License ::`` classifiers.
+
+Also, make sure you add the full license text of all the licenses as files
+somewhere in your project repository. List the
+relative path or glob patterns to each of them under ``license-files``
+under ``[project]`` in :file:`pyproject.toml`
+(if your tool supports it), or else in your tool's configuration file.
+
+As an example, if your project was licensed MIT but incorporated
+a vendored dependency (say, ``packaging``) that was licensed under
+either Apache 2.0 or the 2-clause BSD, your license expression would
+be ``MIT AND (Apache-2.0 OR BSD-2-Clause)``. You might have a
+:file:`LICENSE.txt` in your repo root, and a :file:`LICENSE-APACHE.txt` and
+:file:`LICENSE-BSD.txt` in the :file:`_vendor/` subdirectory, so to include
+all of them, you'd specify ``["LICENSE.txt", "_vendor/packaging/LICENSE*"]``
+as glob patterns, or
+``["LICENSE.txt", "_vendor/LICENSE-APACHE.txt", "_vendor/LICENSE-BSD.txt"]``
+as literal file paths.
+
+See a fully worked out :ref:`licensing-example-advanced` for an end-to-end
+application of this to a real-world complex project, with many technical
+details, and consult a `tutorial `__ for more help and examples
+using SPDX identifiers and expressions.
+
+
+.. _chooseamitlicense: https://choosealicense.com/licenses/mit/
+.. _choosealicenselist: https://choosealicense.com/licenses/
+.. _dontchoosealicense: https://choosealicense.com/no-permission/
+.. _mappingclassifierstospdx: https://peps.python.org/pep-0639/appendix-mapping-classifiers/
+.. _packaginglicense: https://github.com/pypa/packaging/blob/21.2/LICENSE
+.. _setuptools7560: https://github.com/pypa/setuptools/blob/v75.6.0/pyproject.toml
+.. _spdxlist: https://spdx.org/licenses/
+.. _spdxtutorial: https://github.com/david-a-wheeler/spdx-tutorial
diff --git a/source/guides/section-build-and-publish.rst b/source/guides/section-build-and-publish.rst
index eb10c389f..52f827553 100644
--- a/source/guides/section-build-and-publish.rst
+++ b/source/guides/section-build-and-publish.rst
@@ -16,3 +16,4 @@ Building and Publishing
    making-a-pypi-friendly-readme
    publishing-package-distribution-releases-using-github-actions-ci-cd-workflows
    modernize-setup-py-project
+   licensing-examples-and-user-scenarios

From 32d55c847afd46c300fd4e256067b7e4b923c939 Mon Sep 17 00:00:00 2001
From: Karolina Surma 
Date: Tue, 26 Nov 2024 12:53:51 +0100
Subject: [PATCH 0851/1072] Update the packaging tutorial according to PEP 639

---
 source/tutorials/packaging-projects.rst | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst
index 93826321d..9357fdfa2 100644
--- a/source/tutorials/packaging-projects.rst
+++ b/source/tutorials/packaging-projects.rst
@@ -213,9 +213,10 @@ following this tutorial.
     requires-python = ">=3.8"
     classifiers = [
         "Programming Language :: Python :: 3",
-        "License :: OSI Approved :: MIT License",
         "Operating System :: OS Independent",
     ]
+    license = "MIT"
+    license-files = ["LICEN[CS]E*"]
 
     [project.urls]
     Homepage = "https://github.com/pypa/sampleproject"
@@ -242,11 +243,15 @@ following this tutorial.
   packages until it finds one that has a matching Python version.
 - ``classifiers`` gives the index and :ref:`pip` some additional metadata
   about your package. In this case, the package is only compatible with Python
-  3, is licensed under the MIT license, and is OS-independent. You should
-  always include at least which version(s) of Python your package works on,
-  which license your package is available under, and which operating systems
+  3 and is OS-independent. You should
+  always include at least which version(s) of Python your package works on
+  and which operating systems
   your package will work on. For a complete list of classifiers, see
   https://pypi.org/classifiers/.
+- ``license`` is the :term:`SPDX license expression ` of
+  your package.
+- ``license-files`` is the list of glob paths to the license files,
+  relative to the directory where :file:`pyproject.toml` is located.
 - ``urls`` lets you list any number of extra links to show on PyPI.
   Generally this could be to the source, documentation, issue trackers, etc.
 
@@ -305,6 +310,9 @@ MIT license:
 
 Most build backends automatically include license files in packages. See your
 backend's documentation for more details.
+If you include the path to license in the ``license-files`` key of
+:file:`pyproject.toml`, and your build backend supports :pep:`639`,
+the file will be automatically included in the package.
 
 
 Including other files

From 0fba2a92f158ff9553e5f0c71d87c3c20619f10c Mon Sep 17 00:00:00 2001
From: Karolina Surma 
Date: Fri, 13 Dec 2024 18:26:17 +0100
Subject: [PATCH 0852/1072] When license-files are not defined, tools are free
 to choose

---
 source/specifications/pyproject-toml.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 7e575b9aa..c82fdd936 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -301,6 +301,9 @@ Build tools:
 If the ``license-files`` key is present and
 is set to a value of an empty array, then tools MUST NOT include any
 license files and MUST NOT raise an error.
+If the ``license-files`` key is not defined, tools can decide how to handle
+license files. For example they can choose not to include any files or use
+their own logic to discover the appropriate files in the distribution.
 
 
 ``authors``/``maintainers``

From 27e9e5d0e342a3491e691c3671e96536c8bf73aa Mon Sep 17 00:00:00 2001
From: Julian Berman 
Date: Tue, 7 Jan 2025 10:17:57 -0500
Subject: [PATCH 0853/1072] Minor fix to a missing in the inline script
 metadata doc.

---
 source/specifications/inline-script-metadata.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/inline-script-metadata.rst b/source/specifications/inline-script-metadata.rst
index f40b9ac4a..6fa832a3e 100644
--- a/source/specifications/inline-script-metadata.rst
+++ b/source/specifications/inline-script-metadata.rst
@@ -79,7 +79,7 @@ script metadata (dependency data and tool configuration).
 This document MAY include the top-level fields ``dependencies`` and ``requires-python``,
 and MAY optionally include a ``[tool]`` table.
 
-The ``[tool]`` MAY be used by any tool, script runner or otherwise, to configure
+The ``[tool]`` table MAY be used by any tool, script runner or otherwise, to configure
 behavior. It has the same semantics as the :ref:`[tool] table in pyproject.toml
 `.
 

From 98216cf9f70fc98d40beb0f106d7f9357c6a0e43 Mon Sep 17 00:00:00 2001
From: Gregory Bell 
Date: Tue, 7 Jan 2025 12:52:13 -0700
Subject: [PATCH 0854/1072] Update writing-pyproject-toml.rst

---
 source/guides/writing-pyproject-toml.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index 63aac1010..636429abb 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -236,7 +236,7 @@ To install a command as part of your package, declare it in the
 
 In this example, after installing your project, a ``spam-cli`` command
 will be available. Executing this command will do the equivalent of
-``from spam import main_cli; exit(main_cli())``.
+``import sys; from spam import main_cli; sys.exit(main_cli())``.
 
 On Windows, scripts packaged this way need a terminal, so if you launch
 them from within a graphical application, they will make a terminal pop

From 26fb5aa44cb6ecbfb4ee860c27efdeb99a4fb8cb Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Tue, 7 Jan 2025 15:58:13 -0800
Subject: [PATCH 0855/1072] Add labels to dependency-specifiers.rst for
 cross-referencing

---
 source/specifications/dependency-specifiers.rst | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst
index d6713f713..06897da27 100644
--- a/source/specifications/dependency-specifiers.rst
+++ b/source/specifications/dependency-specifiers.rst
@@ -128,6 +128,8 @@ Whitespace
 Non line-breaking whitespace is mostly optional with no semantic meaning. The
 sole exception is detecting the end of a URL requirement.
 
+.. _dependency-specifiers-names:
+
 Names
 -----
 
@@ -142,6 +144,8 @@ with re.IGNORECASE) is::
 
     ^([A-Z0-9]|[A-Z0-9][A-Z0-9._-]*[A-Z0-9])$
 
+.. _dependency-specifiers-extras:
+
 Extras
 ------
 
@@ -159,6 +163,8 @@ are listed in the "security" extra of requests.
 
 If multiple extras are listed, all the dependencies are unioned together.
 
+.. _dependency-specifiers-versions:
+
 Versions
 --------
 
@@ -170,6 +176,8 @@ via a URL. Version comparison are also used in the markers feature. The
 optional brackets around a version are present for compatibility with
 :pep:`345` but should not be generated, only accepted.
 
+.. _dependency-specifiers-environment-markers:
+
 Environment Markers
 -------------------
 
@@ -294,6 +302,8 @@ The ``implementation_version`` marker variable is derived from
 This environment markers section, initially defined through :pep:`508`, supersedes the environment markers
 section in :pep:`345`.
 
+.. _dependency-specifiers-grammar:
+
 Complete Grammar
 ================
 

From 05fb0b06f51c5602f68b89cd4af152d3c516ffb5 Mon Sep 17 00:00:00 2001
From: Ilya Popov 
Date: Wed, 8 Jan 2025 12:11:53 +0100
Subject: [PATCH 0856/1072] Add a note that Poetry supports [project] now

Fixes #1771
---
 source/guides/writing-pyproject-toml.rst | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index 636429abb..b86d11827 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -29,8 +29,9 @@ three possible TOML tables in this file.
    On the other hand, the ``[project]`` table is understood by *most* build
    backends, but some build backends use a different format.
 
-   As of August 2024, Poetry_ is a notable build backend that does not use
-   the ``[project]`` table, it uses the ``[tool.poetry]`` table instead.
+   A notable exception is Poetry_, which before version 2.0 (released January
+   5, 2025) did not use the ``[project]`` table, it used the ``[tool.poetry]``
+   table instead. With version 2.0, it supports both.
    Also, the setuptools_ build backend supports both the ``[project]`` table,
    and the older format in ``setup.cfg`` or ``setup.py``.
 

From 1f6b6ad4eb05e99df50fe04f905ceae82cfaed8b Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Wed, 8 Jan 2025 13:54:37 -0800
Subject: [PATCH 0857/1072] Add labels to source-distribution-format.rst for
 cross-referencing

Specifically cover source trees and sdist as files.
---
 source/specifications/source-distribution-format.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/source/specifications/source-distribution-format.rst b/source/specifications/source-distribution-format.rst
index bae618df1..a1c310244 100644
--- a/source/specifications/source-distribution-format.rst
+++ b/source/specifications/source-distribution-format.rst
@@ -20,6 +20,8 @@ specification.
 
 Source distributions are also known as *sdists* for short.
 
+.. _source-distribution-format-source-tree:
+
 Source trees
 ============
 
@@ -30,6 +32,8 @@ directories. :pep:`517` and :pep:`518` specify what is required to meet the
 definition of what :file:`pyproject.toml` must contain for something to be
 deemed a source tree.
 
+.. _source-distribution-format-sdist:
+
 Source distribution file name
 =============================
 

From 51487e890322197ad15c305fc175dd49d2dea012 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Wed, 8 Jan 2025 14:00:42 -0800
Subject: [PATCH 0858/1072] Add labels to direct-url-data-structure.rst for
 cross-referencing

---
 source/specifications/direct-url-data-structure.rst | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index 6a4e8fe01..0d243652d 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -49,6 +49,8 @@ Additionally, the user:password section of the URL MAY be a
 well-known, non security sensitive string. A typical example is ``git``
 in the case of a URL such as ``ssh://git@gitlab.com/user/repo``.
 
+.. _direct-url-data-structure-vcs:
+
 VCS URLs
 --------
 
@@ -72,6 +74,8 @@ as a dictionary with the following keys:
   ``commit_id`` in order to reference an immutable
   version of the source code.
 
+.. _direct-url-data-structure-archive:
+
 Archive URLs
 ------------
 
@@ -104,6 +108,8 @@ When both the ``hash`` and ``hashes`` keys are present, the hash represented in
 ``hash`` key MUST also be present in the ``hashes`` dictionary, so consumers can
 consider the ``hashes`` key only if it is present, and fall back to ``hash`` otherwise.
 
+.. _direct-url-data-structure-local-directory:
+
 Local directories
 -----------------
 
@@ -118,6 +124,8 @@ be compliant with :rfc:`8089`. In
 particular, the path component must be absolute. Symbolic links SHOULD be
 preserved when making relative paths absolute.
 
+.. _direct-url-data-structure-subdirectories:
+
 Projects in subdirectories
 --------------------------
 
@@ -125,6 +133,8 @@ A top-level ``subdirectory`` field MAY be present containing a directory path,
 relative to the root of the VCS repository, source archive or local directory,
 to specify where ``pyproject.toml`` or ``setup.py`` is located.
 
+.. _direct-url-data-structure-registered-vcs:
+
 Registered VCS
 ==============
 

From 499a91dbb0e0448947660e6936949ec229e68890 Mon Sep 17 00:00:00 2001
From: Dustin Ingram 
Date: Tue, 14 Jan 2025 15:25:29 +0000
Subject: [PATCH 0859/1072] Update Dynamic specification to include deprecated
 fields

---
 source/specifications/core-metadata.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index c1ce528e7..316736ff0 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -110,7 +110,7 @@ Dynamic (multiple use)
 
 A string containing the name of another core metadata field. The field
 names ``Name``, ``Version``, and ``Metadata-Version`` may not be specified
-in this field.
+in this field. Deprecated fields MAY be specified in this field.
 
 When found in the metadata of a source distribution, the following
 rules apply:

From 8c9fb25dd07c41e0edb14e1fac40a3d1d5d56a57 Mon Sep 17 00:00:00 2001
From: Dustin Ingram 
Date: Tue, 14 Jan 2025 17:28:16 +0000
Subject: [PATCH 0860/1072] Revert "Update Dynamic specification to include
 deprecated fields"

This reverts commit 499a91dbb0e0448947660e6936949ec229e68890.
---
 source/specifications/core-metadata.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 316736ff0..c1ce528e7 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -110,7 +110,7 @@ Dynamic (multiple use)
 
 A string containing the name of another core metadata field. The field
 names ``Name``, ``Version``, and ``Metadata-Version`` may not be specified
-in this field. Deprecated fields MAY be specified in this field.
+in this field.
 
 When found in the metadata of a source distribution, the following
 rules apply:

From 8dfac8d1f0a811987f84966ce737a8f253de7da0 Mon Sep 17 00:00:00 2001
From: Dustin Ingram 
Date: Tue, 14 Jan 2025 17:29:14 +0000
Subject: [PATCH 0861/1072] Add a definition of 'deprecated' instead

---
 source/specifications/core-metadata.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index c1ce528e7..422d30cd4 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -800,6 +800,10 @@ Deprecated Fields
 .. _home-page-optional:
 .. _core-metadata-home-page:
 
+Deprecated fields are valid metadata fields for any metadata version. Tools
+MUST attempt to convert deprecated fields to non-deprecated fields when
+appropriate. Tools SHOULD warn users when deprecated fields are used.
+
 Home-page
 ---------
 

From f2904b3d752daba59b834c7005e3631285135ef9 Mon Sep 17 00:00:00 2001
From: Dustin Ingram 
Date: Tue, 14 Jan 2025 17:43:27 +0000
Subject: [PATCH 0862/1072] Don't require conversion

---
 source/specifications/core-metadata.rst | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 422d30cd4..832c25bb4 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -801,8 +801,7 @@ Deprecated Fields
 .. _core-metadata-home-page:
 
 Deprecated fields are valid metadata fields for any metadata version. Tools
-MUST attempt to convert deprecated fields to non-deprecated fields when
-appropriate. Tools SHOULD warn users when deprecated fields are used.
+SHOULD warn users when deprecated fields are used.
 
 Home-page
 ---------

From 017f3d6995546d1dfd1c384e78d47c9d18170f45 Mon Sep 17 00:00:00 2001
From: Dustin Ingram 
Date: Tue, 14 Jan 2025 17:44:03 +0000
Subject: [PATCH 0863/1072] Move text before link targets

---
 source/specifications/core-metadata.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 832c25bb4..f410eca09 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -797,12 +797,12 @@ Examples::
 Deprecated Fields
 =================
 
-.. _home-page-optional:
-.. _core-metadata-home-page:
-
 Deprecated fields are valid metadata fields for any metadata version. Tools
 SHOULD warn users when deprecated fields are used.
 
+.. _home-page-optional:
+.. _core-metadata-home-page:
+
 Home-page
 ---------
 

From 55f3ddeae1e91be40bf1ae4f50271b0e020cf840 Mon Sep 17 00:00:00 2001
From: Dustin Ingram 
Date: Tue, 14 Jan 2025 20:15:00 +0000
Subject: [PATCH 0864/1072] Commit suggestion

---
 source/specifications/core-metadata.rst | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index f410eca09..2129be541 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -797,8 +797,10 @@ Examples::
 Deprecated Fields
 =================
 
-Deprecated fields are valid metadata fields for any metadata version. Tools
-SHOULD warn users when deprecated fields are used.
+Deprecated fields should be avoided, but they are valid metadata fields. They
+may be removed in future versions of the core metadata standard (at which point
+they will only be valid in files that specify a metadata version prior to the
+removal). Tools SHOULD warn users when deprecated fields are used.
 
 .. _home-page-optional:
 .. _core-metadata-home-page:

From f14dab6c4b4801c40df6fc27cad4d43f748de1e7 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Wed, 15 Jan 2025 13:14:05 -0800
Subject: [PATCH 0865/1072] Clearly specify that the name and version should be
 normalized for `.dist-info` and `.data` directories in wheels

It's implied by https://packaging.python.org/en/latest/specifications/recording-installed-packages/#the-dist-info-directory as the resulting directory upon unpacking is supposed to be normalized.
---
 source/specifications/binary-distribution-format.rst | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst
index be21aedcd..9b1678c0a 100644
--- a/source/specifications/binary-distribution-format.rst
+++ b/source/specifications/binary-distribution-format.rst
@@ -175,8 +175,10 @@ File contents
 '''''''''''''
 
 The contents of a wheel file, where {distribution} is replaced with the
-name of the package, e.g. ``beaglevote`` and {version} is replaced with
-its version, e.g. ``1.0.0``, consist of:
+:ref:`normalized name ` of the package, e.g. 
+``beaglevote`` and {version} is replaced
+with its :ref:`normalized version `,
+e.g. ``1.0.0``, consist of:
 
 #. ``/``, the root of the archive, contains all files to be installed in
    ``purelib`` or ``platlib`` as specified in ``WHEEL``.  ``purelib`` and

From 5b0cb92e8a690d8797284a687f443ad1382aa3e5 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Wed, 15 Jan 2025 21:14:59 +0000
Subject: [PATCH 0866/1072] [pre-commit.ci] auto fixes from pre-commit.com
 hooks

for more information, see https://pre-commit.ci
---
 source/specifications/binary-distribution-format.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst
index 9b1678c0a..bcb73b0a2 100644
--- a/source/specifications/binary-distribution-format.rst
+++ b/source/specifications/binary-distribution-format.rst
@@ -175,7 +175,7 @@ File contents
 '''''''''''''
 
 The contents of a wheel file, where {distribution} is replaced with the
-:ref:`normalized name ` of the package, e.g. 
+:ref:`normalized name ` of the package, e.g.
 ``beaglevote`` and {version} is replaced
 with its :ref:`normalized version `,
 e.g. ``1.0.0``, consist of:

From f132c2ffe0da00359ac3debd4212a25f50c709b7 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Wed, 15 Jan 2025 14:46:18 -0800
Subject: [PATCH 0867/1072] Update
 source/specifications/binary-distribution-format.rst

Co-authored-by: Paul Moore 
---
 source/specifications/binary-distribution-format.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst
index bcb73b0a2..f16c191d7 100644
--- a/source/specifications/binary-distribution-format.rst
+++ b/source/specifications/binary-distribution-format.rst
@@ -178,7 +178,7 @@ The contents of a wheel file, where {distribution} is replaced with the
 :ref:`normalized name ` of the package, e.g.
 ``beaglevote`` and {version} is replaced
 with its :ref:`normalized version `,
-e.g. ``1.0.0``, consist of:
+e.g. ``1.0.0``, (with dash (`-`) characters replaced with underscore (`_`) characters in both fields) consist of:
 
 #. ``/``, the root of the archive, contains all files to be installed in
    ``purelib`` or ``platlib`` as specified in ``WHEEL``.  ``purelib`` and

From dbbc9b14e53f5912fcb1c08ef3fba7ec1b2d1011 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Thu, 16 Jan 2025 13:27:46 -0800
Subject: [PATCH 0868/1072] Add an entry to the History section

---
 .../specifications/binary-distribution-format.rst   | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst
index f16c191d7..4d94e1052 100644
--- a/source/specifications/binary-distribution-format.rst
+++ b/source/specifications/binary-distribution-format.rst
@@ -150,10 +150,10 @@ this character cannot appear within any component. This is handled as follows:
 - In distribution names, any run of ``-_.`` characters (HYPHEN-MINUS, LOW LINE
   and FULL STOP) should be replaced with ``_`` (LOW LINE), and uppercase
   characters should be replaced with corresponding lowercase ones. This is
-  equivalent to regular :ref:`name normalization ` followed by replacing ``-`` with ``_``.
-  Tools consuming wheels must be prepared to accept ``.`` (FULL STOP) and
-  uppercase letters, however, as these were allowed by an earlier version of
-  this specification.
+  equivalent to regular :ref:`name normalization ` followed
+  by replacing ``-`` with ``_``. Tools consuming wheels must be prepared to accept
+  ``.`` (FULL STOP) and uppercase letters, however, as these were allowed by an earlier
+  version of this specification.
 - Version numbers should be normalised according to the :ref:`Version specifier
   specification `. Normalised version numbers cannot contain ``-``.
 - The remaining components may not contain ``-`` characters, so no escaping
@@ -178,7 +178,8 @@ The contents of a wheel file, where {distribution} is replaced with the
 :ref:`normalized name ` of the package, e.g.
 ``beaglevote`` and {version} is replaced
 with its :ref:`normalized version `,
-e.g. ``1.0.0``, (with dash (`-`) characters replaced with underscore (`_`) characters in both fields) consist of:
+e.g. ``1.0.0``, (with dash/``-`` characters replaced with underscore/``_`` characters
+in both fields) consist of:
 
 #. ``/``, the root of the archive, contains all files to be installed in
    ``purelib`` or ``platlib`` as specified in ``WHEEL``.  ``purelib`` and
@@ -442,6 +443,8 @@ History
   may vary between tools).
 - December 2024: The :file:`.dist-info/licenses/` directory was specified through
   :pep:`639`.
+- January 2025: Clarified that name and version needs to be normalized for
+  ``.dist-info`` and ``.data`` directories.
 
 
 Appendix

From 96058cc8d3b42c00c26fb04cc5bb2c530dc67d4e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Mon, 27 Jan 2025 18:08:49 +0100
Subject: [PATCH 0869/1072] Start a discussion on helping downstream packaging

Start the discussion aimed at making downstream packaging easier.
The first section focuses on providing source distributions.

Also related to bug #1494, though it's focused on why having these
extra files is helpful to downstreams, rather than setting a hard
standard on what should be included.
---
 source/discussions/downstream-packaging.rst | 84 +++++++++++++++++++++
 source/discussions/index.rst                |  1 +
 2 files changed, 85 insertions(+)
 create mode 100644 source/discussions/downstream-packaging.rst

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
new file mode 100644
index 000000000..1573bca06
--- /dev/null
+++ b/source/discussions/downstream-packaging.rst
@@ -0,0 +1,84 @@
+.. _downstream-packaging:
+
+========================================
+How to make downstream packaging easier?
+========================================
+
+:Page Status: Draft
+:Last Reviewed: 2025-?
+
+While PyPI and the Python packaging tools such as :ref:`pip` are the primary
+means of distributing your packages, they are often also made available as part
+of other packaging ecosystems. These repackaging efforts are collectively called
+*downstream* packaging (your own efforts are called *upstream* packaging),
+and include such projects as Linux distributions, Conda, Homebrew and MacPorts.
+They often aim to provide good support for use cases that cannot be handled
+via Python packaging tools alone, such as good integration with non-Python
+software.
+
+This discussion attempts to explain how downstream packaging is usually done,
+and what challenges are downstream packagers facing. It ultimately aims to give
+you some hints on how you can make downstream packaging easier.
+
+Please note that downstream builds include not only binary redistribution,
+but also source builds done on user systems, in source-first distributions
+such as Gentoo Linux.
+
+
+.. _Provide complete source distributions:
+
+Provide complete source distributions
+-------------------------------------
+The vast majority of downstream packagers prefer to build packages from source,
+rather than use the upstream-provided binary packages. This is also true
+of pure Python packages that provide universal wheels. The reasons for using
+source distributions may include:
+
+- being able to audit the source code of all packages
+
+- being able to run the test suite and build documentation
+
+- being able to easily apply patches, including backporting commits from your
+  repository and sending patches back to you
+
+- being able to build against a specific platform that is not covered
+  by upstream builds
+
+- being able to build against specific versions of system libraries
+
+- having a consistent build process across all Python packages
+
+Ideally, a source distribution archive should include all the files necessary
+to build the package itself, run its test suite, build and install its
+documentation, and any other files that may be useful to end users, such
+as shell completions, editor support files, and so on.
+
+Some projects are concerned about increasing the size of source distribution,
+or do not wish Python packaging tools to fall back to source distributions
+automatically.  In these cases, a good compromise may be to publish a separate
+source archive for downstream use, for example by attaching it to a GitHub
+release.
+
+While it is usually possible to build packages from a git repository, there are
+a few important reasons to provide a static archive file instead:
+
+- Fetching a single file is often more efficient, more reliable and better
+  supported than e.g. using a git clone. This can help users with a shoddy
+  Internet connection.
+
+- Downstreams often use checksums to verify the authenticity of source files
+  on subsequent builds, which require that they remain bitwise identical over
+  time. For example, automatically generated git archives do not guarantee
+  that.
+
+- Archive files can be mirrored, reducing both upstream and downstream
+  bandwidth use. The actual builds can afterwards be performed in firewalled
+  or offline environments, that can only access source files provided
+  by the local mirror or redistributed earlier.
+
+A good idea is to use a release workflow that starts by building a source
+distribution, and then performs all the remaining release steps (such as
+running tests and building wheels) from the unpacked source distribution. This
+ensures that the source distribution is actually tested, and reduces the risk
+that users installing from it will hit build failures or install an incomplete
+package.
diff --git a/source/discussions/index.rst b/source/discussions/index.rst
index 1f5ff1f2b..b1b84f97a 100644
--- a/source/discussions/index.rst
+++ b/source/discussions/index.rst
@@ -17,3 +17,4 @@ specific topic. If you're just trying to get stuff done, see
    src-layout-vs-flat-layout
    setup-py-deprecated
    single-source-version
+   downstream-packaging

From b4cb7d2d6bed24af2f6831d07fb7d8fb5edf3f12 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Mon, 27 Jan 2025 20:50:17 +0100
Subject: [PATCH 0870/1072] Add a section on Internet access

---
 source/discussions/downstream-packaging.rst | 39 +++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index 1573bca06..f40fafac8 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -82,3 +82,42 @@ running tests and building wheels) from the unpacked source distribution. This
 ensures that the source distribution is actually tested, and reduces the risk
 that users installing from it will hit build failures or install an incomplete
 package.
+
+
+.. _Do not use the Internet during the build process:
+
+Do not use the Internet during the build process
+------------------------------------------------
+Downstream builds are frequently done in sandboxed environments that cannot
+access the Internet. Therefore, it is important that your source distribution
+includes all the files needed for the package to build or allows provisioning
+them externally, and can build successfully without Internet access.
+
+Ideally, it should not even attempt to access the Internet at all, unless
+explicitly requested to. If that is not possible to achieve, the next best
+thing is to provide an opt-out switch to disable all Internet access, and fail
+if some of the required files are missing instead of trying to fetch them. This
+could be done e.g. by checking whether a ``NO_NETWORK`` environment variable is
+to a non-empty value. Please also remember that if you are fetching remote
+resources, you should verify their authenticity, e.g.  against a checksum, to
+protect against the file being substituted by a malicious party.
+
+Even if downloads are properly authenticated, using the Internet is discouraged
+for a number of reasons:
+
+- The Internet connection may be unstable (e.g. poor reception) or suffer from
+  temporary problems that could cause the downloads to fail or hang.
+
+- The remote resources may become temporarily or even permanently unavailable,
+  making the build no longer possible. This is especially problematic when
+  someone needs to build an old package version.
+
+- Accessing remote servers poses a privacy issue and a potential security issue,
+  as it exposes information about the system building the package.
+
+- The user may be using a service with a limited data plan, in which
+  uncontrolled Internet access may result in additional charges or other
+  inconveniences.
+
+Since downstreams frequently also run tests and build documentation, the above
+should ideally extend to these processes as well.

From df7081cea024faf99a4c1e95f457e42cf8f8ecb6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Mon, 27 Jan 2025 20:51:23 +0100
Subject: [PATCH 0871/1072] Also suggest the option of splitting test data into
 separate archive

---
 source/discussions/downstream-packaging.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index f40fafac8..f8f4d9d42 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -57,7 +57,8 @@ Some projects are concerned about increasing the size of source distribution,
 or do not wish Python packaging tools to fall back to source distributions
 automatically.  In these cases, a good compromise may be to publish a separate
 source archive for downstream use, for example by attaching it to a GitHub
-release.
+release. Alternatively, large files, such as test data, can be split into
+separate archives.
 
 While it is usually possible to build packages from a git repository, there are
 a few important reasons to provide a static archive file instead:

From cff76df08c13f83b5a8bb4d25192e957c516d108 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Tue, 28 Jan 2025 15:14:02 +0100
Subject: [PATCH 0872/1072] Add a section on system dependencies

---
 source/discussions/downstream-packaging.rst | 70 +++++++++++++++++++++
 1 file changed, 70 insertions(+)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index f8f4d9d42..50e00ac91 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -122,3 +122,73 @@ for a number of reasons:
 
 Since downstreams frequently also run tests and build documentation, the above
 should ideally extend to these processes as well.
+
+
+.. _Support building against system dependencies:
+
+Support building against system dependencies
+--------------------------------------------
+Some Python projects have non-Python dependencies, such as libraries written
+in C or C++. Trying to use the system versions of these dependencies
+in upstream packaging may cause a number of problems for end users:
+
+- The published wheels require a binary-compatible version of the used library
+  to be present on the user's system. If the library is missing or installed
+  in incompatible version, the Python package may fail with errors that
+  are not clear to inexperienced users, or even misbehave at runtime.
+
+- Building from source distribution requires a source-compatible version
+  of the dependency to be present, along with its development headers and other
+  auxiliary files that some systems package separately from the library itself.
+
+- Even for an experienced user, installing a compatible dependency version
+  may be very hard. For example, the used Linux distribution may not provide
+  the required version, or some other package may require an incompatible
+  version.
+
+- The linkage between the Python package and its system dependency is not
+  recorded by the packaging system. The next system update may upgrade
+  the library to a newer version that breaks binary compatibility with
+  the Python package, and requires user intervention to fix.
+
+For these reasons, you may reasonable to decide to either link statically
+to your dependencies, or to provide a local copies in the installed package.
+You may also vendor the dependency in your source distribution.  Sometimes
+these dependencies are also repackaged on PyPI, and can be installed
+like a regular Python packages.
+
+However, none of these issues apply to downstream packaging, and downstreams
+have good reasons to prefer dynamically linking to system dependencies.
+In particular:
+
+- Static linking and vendoring obscures the use of external dependencies,
+  making source auditing harder.
+
+- Dynamic linking makes it possible to easily and quickly replace the used
+  libraries, which can be particularly important when they turn out to
+  be vulnerable or buggy.
+
+- Using system dependencies makes the package benefit from downstream
+  customization that can improve the user experience on a particular platform,
+  without the downstream maintainers having to consistently patch
+  the dependencies vendored in different packages. This can include
+  compatibility improvements and security hardening.
+
+- Static linking and vendoring could result in multiple different versions
+  of the same library being loaded in the same process (e.g. when you use two
+  Python packages that link to different versions of the same library).
+  This can cause no problems, but it could also lead to anything from subtle
+  bugs to catastrophic failures.
+
+- Last but not least, static linking and vendoring results in duplication,
+  and may increase the use of both the disk space and memory.
+
+A good compromise between the needs of both parties is to provide a switch
+between using vendored and system dependencies. Ideally, if the package has
+multiple vendored dependencies, it should provide both individual switches
+for each dependency, and a general switch, for example using
+a  ``USE_SYSTEM_DEPS`` environment variable to control the default. If switched
+on, and a particular dependency is either missing or incompatible, the build
+should fail with an explanatory message, giving the packager an explicit
+indication of the problem and a chance to consciously decide on the preferred
+course of action.

From be242a80635933692d238bb7e74c3ea962b480df Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Tue, 28 Jan 2025 16:52:12 +0100
Subject: [PATCH 0873/1072] Add a section on downstream testing

---
 source/discussions/downstream-packaging.rst | 79 +++++++++++++++++++++
 1 file changed, 79 insertions(+)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index 50e00ac91..7d09bdb73 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -192,3 +192,82 @@ on, and a particular dependency is either missing or incompatible, the build
 should fail with an explanatory message, giving the packager an explicit
 indication of the problem and a chance to consciously decide on the preferred
 course of action.
+
+
+.. _Support downstream testing:
+
+Support downstream testing
+--------------------------
+A variety of downstream projects run some degree of testing on the packaged
+Python projects. Depending on the particular case, this can range from minimal
+smoke testing to comprehensive runs of the complete test suite. There can
+be various reasons for doing this, for example:
+
+- Verifying that the downstream packaging did not introduce any bugs.
+
+- Testing on a platform that is not covered by upstream testing.
+
+- Finding subtle bugs that can only be reproduced on a particular hardware,
+  system package versions, and so on.
+
+- Testing the released package against newer dependency version than the ones
+  present during upstream release testing.
+
+- Testing the package in an environment closely resembling the production
+  setup. This can detect issues caused by nontrivial interactions between
+  different installed packages, including packages that are not dependencies
+  of your package, but nevertheless can cause issues.
+
+- Testing the released package against newer Python versions (including newer
+  point releases), or less tested Python implementations such as PyPy.
+
+Admittedly, sometimes downstream testing may yield false positives or
+inconvenience you about scenarios that you are not interested in supporting.
+However, perhaps even more often it does provide early notice of problems,
+or find nontrivial bugs that would otherwise cause issues for your users
+in production. And believe me, the majority of downstream packagers are doing
+their best to double-check their results, and help you triage and fix the bugs
+that they report.
+
+There is a number of things that you can do to help us test your package
+better. Some of them were already mentioned in this discussion. Some examples
+are:
+
+- Include the test files and fixtures in the source distribution, or make it
+  possible to easily download them separately.
+
+- Do not write to the package during testing. Downstream test setups sometimes
+  run tests on top of the installed package, and test-time modifications can
+  end up being part of the production package!
+
+- Make the test suite work offline. Mock network interactions, using packages
+  such as responses_ or vcrpy_. If that is not possible, make it possible
+  to easily disable the tests using Internet access, e.g. via a pytest marker.
+  Use pytest-socket_ to verify that your tests work offline.
+
+- Make your tests work without a specialized setup, or perform the necessary
+  setup as part of test fixtures. Do not ever assume that you can connect
+  to system services such as databases — in an extreme case, you could crash
+  a production service!
+
+- Do not assume that the test suite will be run with ``-Werror``. Downstreams
+  often need to disable that, as it causes false positives, e.g. due to newer
+  dependency versions. Assert for warnings using ``pytest.warns()`` rather
+  than ``pytest.raises()``!
+
+- Aim to make your test suite reliable. Avoid flaky tests. Avoid depending
+  on specific platform details, don't rely on exact results of floating-point
+  computation, or timing of operations, and so on. Fuzzing has its advantages,
+  but you want to have static test cases for completeness as well.
+
+- Split tests by their purpose, and make it easy to skip categories that are
+  irrelevant or problematic. Since the primary purpose of downstream testing is
+  to ensure that the package itself works, we generally are not interested
+  in e.g. checking code coverage, code formatting, typing or running
+  benchmarks. These tests can fail as dependencies are upgraded or the system
+  is under load, without actually affecting the package itself.
+
+
+.. _responses: https://pypi.org/project/responses/
+.. _vcrpy: https://pypi.org/project/vcrpy/
+.. _pytest-socket: https://pypi.org/project/pytest-socket/

From 9f9af53be8e3fe63af9449481b588f6642e71627 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Wed, 29 Jan 2025 20:49:45 +0100
Subject: [PATCH 0874/1072] Expand on downstream testing, and add emphasis for
 readability

---
 source/discussions/downstream-packaging.rst | 60 +++++++++++++++------
 1 file changed, 43 insertions(+), 17 deletions(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index 7d09bdb73..fe909b9cd 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -233,41 +233,67 @@ There is a number of things that you can do to help us test your package
 better. Some of them were already mentioned in this discussion. Some examples
 are:
 
-- Include the test files and fixtures in the source distribution, or make it
+- **Include the test files and fixtures in the source distribution**, or make it
   possible to easily download them separately.
 
-- Do not write to the package during testing. Downstream test setups sometimes
-  run tests on top of the installed package, and test-time modifications can
-  end up being part of the production package!
+- **Do not write to the package directories during testing.** Downstream test
+  setups sometimes run tests on top of the installed package, and modifications
+  performed during testing and temporary test files may end up being part
+  of the installed package!
 
-- Make the test suite work offline. Mock network interactions, using packages
-  such as responses_ or vcrpy_. If that is not possible, make it possible
-  to easily disable the tests using Internet access, e.g. via a pytest marker.
-  Use pytest-socket_ to verify that your tests work offline.
+- **Make the test suite work offline.** Mock network interactions, using
+  packages such as responses_ or vcrpy_. If that is not possible, make it
+  possible to easily disable the tests using Internet access, e.g. via a pytest
+  marker.  Use pytest-socket_ to verify that your tests work offline. This
+  often makes your own test workflows faster and more reliable as well.
 
-- Make your tests work without a specialized setup, or perform the necessary
+- **Make your tests work without a specialized setup**, or perform the necessary
   setup as part of test fixtures. Do not ever assume that you can connect
   to system services such as databases — in an extreme case, you could crash
   a production service!
 
-- Do not assume that the test suite will be run with ``-Werror``. Downstreams
+- **If your package has optional dependencies, make their tests optional as
+  well.** Either skip them if the needed packages are not installed, or add
+  markers to make deselecting easy.
+
+- More generally, **add markers to tests with special requirements**. These can
+  include e.g. significant space usage, significant memory usage, long runtime,
+  incompatibility with parallel testing.
+
+- **Do not assume that the test suite will be run with -Werror.** Downstreams
   often need to disable that, as it causes false positives, e.g. due to newer
   dependency versions. Assert for warnings using ``pytest.warns()`` rather
   than ``pytest.raises()``!
 
-- Aim to make your test suite reliable. Avoid flaky tests. Avoid depending
-  on specific platform details, don't rely on exact results of floating-point
-  computation, or timing of operations, and so on. Fuzzing has its advantages,
-  but you want to have static test cases for completeness as well.
+- **Aim to make your test suite reliable and reproducible.** Avoid flaky tests.
+  Avoid depending on specific platform details, don't rely on exact results
+  of floating-point computation, or timing of operations, and so on. Fuzzing
+  has its advantages, but you want to have static test cases for completeness
+  as well.
 
-- Split tests by their purpose, and make it easy to skip categories that are
-  irrelevant or problematic. Since the primary purpose of downstream testing is
-  to ensure that the package itself works, we generally are not interested
+- **Split tests by their purpose, and make it easy to skip categories that are
+  irrelevant or problematic.** Since the primary purpose of downstream testing
+  is to ensure that the package itself works, we generally are not interested
   in e.g. checking code coverage, code formatting, typing or running
   benchmarks. These tests can fail as dependencies are upgraded or the system
   is under load, without actually affecting the package itself.
 
+- If your test suite takes significant time to run, **support testing
+  in parallel.** Downstreams often maintain a large number of packages,
+  and testing them all takes a lot of time. Using pytest-xdist_ can help them
+  avoid bottlenecks.
+
+- Ideally, **support running your test suite via PyTest**. PyTest_ has many
+  command-line arguments that are truly helpful to downstreams, such as
+  the ability to conveniently deselect tests, rerun flaky tests
+  (via pytest-rerunfailures_), add a timeout to prevent tests from hanging
+  (via pytest-timeout_) or run tests in parallel (via pytest-xdist_).
+
 
 .. _responses: https://pypi.org/project/responses/
 .. _vcrpy: https://pypi.org/project/vcrpy/
 .. _pytest-socket: https://pypi.org/project/pytest-socket/
+.. _pytest-xdist: https://pypi.org/project/pytest-xdist/
+.. _pytest: https://pytest.org/
+.. _pytest-rerunfailures: https://pypi.org/project/pytest-rerunfailures/
+.. _pytest-timeout: https://pypi.org/project/pytest-timeout/

From 00f39e5a434e7dd17ba9743072c9c33222b6c378 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Wed, 29 Jan 2025 21:19:40 +0100
Subject: [PATCH 0875/1072] Reorganize into why/how sections, and add emphasis

Hopefully, this will make it easier for people who aren't interested
in reading all the rationale to find the important details -- and for
people who read it once to quickly find the point they need later.
---
 source/discussions/downstream-packaging.rst | 212 +++++++++++---------
 1 file changed, 117 insertions(+), 95 deletions(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index fe909b9cd..71d02e7d0 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -29,97 +29,108 @@ such as Gentoo Linux.
 
 Provide complete source distributions
 -------------------------------------
+Why?
+~~~~
 The vast majority of downstream packagers prefer to build packages from source,
 rather than use the upstream-provided binary packages. This is also true
 of pure Python packages that provide universal wheels. The reasons for using
 source distributions may include:
 
-- being able to audit the source code of all packages
+- being able to **audit the source code** of all packages
 
-- being able to run the test suite and build documentation
+- being able to **run the test suite and build documentation**
 
-- being able to easily apply patches, including backporting commits from your
-  repository and sending patches back to you
+- being able to **easily apply patches**, including backporting commits
+  from your repository and sending patches back to you
 
-- being able to build against a specific platform that is not covered
+- being able to **build on a specific platform** that is not covered
   by upstream builds
 
-- being able to build against specific versions of system libraries
+- being able to **build against specific versions of system libraries**
 
 - having a consistent build process across all Python packages
 
-Ideally, a source distribution archive should include all the files necessary
-to build the package itself, run its test suite, build and install its
-documentation, and any other files that may be useful to end users, such
-as shell completions, editor support files, and so on.
-
-Some projects are concerned about increasing the size of source distribution,
-or do not wish Python packaging tools to fall back to source distributions
-automatically.  In these cases, a good compromise may be to publish a separate
-source archive for downstream use, for example by attaching it to a GitHub
-release. Alternatively, large files, such as test data, can be split into
-separate archives.
-
 While it is usually possible to build packages from a git repository, there are
 a few important reasons to provide a static archive file instead:
 
-- Fetching a single file is often more efficient, more reliable and better
-  supported than e.g. using a git clone. This can help users with a shoddy
+- Fetching a single file is often **more efficient, more reliable and better
+  supported** than e.g. using a git clone. This can help users with a shoddy
   Internet connection.
 
-- Downstreams often use checksums to verify the authenticity of source files
+- Downstreams often **use checksums to verify the authenticity** of source files
   on subsequent builds, which require that they remain bitwise identical over
   time. For example, automatically generated git archives do not guarantee
   that.
 
-- Archive files can be mirrored, reducing both upstream and downstream
+- Archive files can be **mirrored**, reducing both upstream and downstream
   bandwidth use. The actual builds can afterwards be performed in firewalled
   or offline environments, that can only access source files provided
   by the local mirror or redistributed earlier.
 
-A good idea is to use a release workflow that starts by building a source
-distribution, and then performs all the remaining release steps (such as
-running tests and building wheels) from the unpacked source distribution. This
-ensures that the source distribution is actually tested, and reduces the risk
-that users installing from it will hit build failures or install an incomplete
-package.
+How?
+~~~~
+Ideally, **a source distribution archive should include all the files**
+necessary to build the package itself, run its test suite, build and install
+its documentation, and any other files that may be useful to end users, such as
+shell completions, editor support files, and so on.
+
+Some projects are concerned about increasing the size of source distribution,
+or do not wish Python packaging tools to fall back to source distributions
+automatically.  In these cases, a good compromise may be to publish a separate
+source archive for downstream use, for example by attaching it to a GitHub
+release. Alternatively, large files, such as test data, can be split into
+separate archives.
+
+A good idea is to **use your source distribution in the release workflow**.
+That is, build it first, then unpack it and perform all the remaining steps
+using the unpacked distribution rather than the git repostiry — run tests,
+build documentation, build wheels. This ensures that it is well-tested,
+and reduces the risk that some users would hit build failures or install
+an incomplete package.
 
 
 .. _Do not use the Internet during the build process:
 
 Do not use the Internet during the build process
 ------------------------------------------------
-Downstream builds are frequently done in sandboxed environments that cannot
-access the Internet. Therefore, it is important that your source distribution
-includes all the files needed for the package to build or allows provisioning
-them externally, and can build successfully without Internet access.
-
-Ideally, it should not even attempt to access the Internet at all, unless
-explicitly requested to. If that is not possible to achieve, the next best
-thing is to provide an opt-out switch to disable all Internet access, and fail
-if some of the required files are missing instead of trying to fetch them. This
-could be done e.g. by checking whether a ``NO_NETWORK`` environment variable is
-to a non-empty value. Please also remember that if you are fetching remote
-resources, you should verify their authenticity, e.g.  against a checksum, to
-protect against the file being substituted by a malicious party.
-
-Even if downloads are properly authenticated, using the Internet is discouraged
-for a number of reasons:
+Why?
+~~~~
+Downstream builds are frequently done in sandboxed environments that **cannot
+access the Internet**. Even if this is not the case, and assuming that you took
+sufficient care to **properly authenticate downloads**, using the Internet
+is discouraged for a number of reasons:
 
-- The Internet connection may be unstable (e.g. poor reception) or suffer from
-  temporary problems that could cause the downloads to fail or hang.
+- The Internet **connection may be unstable** (e.g. due to poor reception)
+  or suffer from temporary problems that could cause the process to fail
+  or hang.
 
-- The remote resources may become temporarily or even permanently unavailable,
-  making the build no longer possible. This is especially problematic when
-  someone needs to build an old package version.
+- The remote resources may **become temporarily or even permanently
+  unavailable**, making the build no longer possible. This is especially
+  problematic when someone needs to build an old package version.
 
-- Accessing remote servers poses a privacy issue and a potential security issue,
-  as it exposes information about the system building the package.
+- Accessing remote servers poses a **privacy** issue and a potential
+  **security** issue, as it exposes information about the system building
+  the package.
 
 - The user may be using a service with a limited data plan, in which
-  uncontrolled Internet access may result in additional charges or other
+  uncontrolled Internet access may result in **additional charges** or other
   inconveniences.
 
+How?
+~~~~
+Your source distribution should either **include all the files needed
+for the package to build**, or allow provisioning them externally. Ideally,
+it should not even attempt to access the Internet at all, unless explicitly
+requested to. If that is not possible to achieve, the next best thing
+is to **provide an opt-out switch to disable all Internet access**.
+
+When such a switch is used, the build process should fail if some
+of the required files are missing, rather than try to fetch them automatically.
+This could be done e.g. by checking whether a ``NO_NETWORK`` environment
+variable is set to a non-empty value. Please also remember that if you are
+fetching remote resources, you must **verify their authenticity**, e.g. against
+a checksum, to protect against the file being substituted by a malicious party.
+
 Since downstreams frequently also run tests and build documentation, the above
 should ideally extend to these processes as well.
 
@@ -128,107 +139,118 @@ should ideally extend to these processes as well.
 
 Support building against system dependencies
 --------------------------------------------
+Why?
+~~~~
 Some Python projects have non-Python dependencies, such as libraries written
 in C or C++. Trying to use the system versions of these dependencies
 in upstream packaging may cause a number of problems for end users:
 
-- The published wheels require a binary-compatible version of the used library
-  to be present on the user's system. If the library is missing or installed
-  in incompatible version, the Python package may fail with errors that
-  are not clear to inexperienced users, or even misbehave at runtime.
+- The published wheels **require a binary-compatible version of the used
+  library** to be present on the user's system. If the library is missing
+  or installed in incompatible version, the Python package may fail with errors
+  that are not clear to inexperienced users, or even misbehave at runtime.
 
-- Building from source distribution requires a source-compatible version
-  of the dependency to be present, along with its development headers and other
-  auxiliary files that some systems package separately from the library itself.
+- Building from source distribution **requires a source-compatible version
+  of the dependency** to be present, along with its development headers
+  and other auxiliary files that some systems package separately
+  from the library itself.
 
 - Even for an experienced user, installing a compatible dependency version
   may be very hard. For example, the used Linux distribution may not provide
-  the required version, or some other package may require an incompatible
-  version.
+  the required version, or some **other package may require an incompatible
+  version**.
 
 - The linkage between the Python package and its system dependency is not
-  recorded by the packaging system. The next system update may upgrade
-  the library to a newer version that breaks binary compatibility with
+  recorded by the packaging system. The next system update may **upgrade
+  the library to a newer version that breaks binary compatibility** with
   the Python package, and requires user intervention to fix.
 
-For these reasons, you may reasonable to decide to either link statically
+For these reasons, you may reasonable to decide to either **link statically**
 to your dependencies, or to provide a local copies in the installed package.
-You may also vendor the dependency in your source distribution.  Sometimes
+You may also **vendor the dependency** in your source distribution.  Sometimes
 these dependencies are also repackaged on PyPI, and can be installed
 like a regular Python packages.
 
 However, none of these issues apply to downstream packaging, and downstreams
-have good reasons to prefer dynamically linking to system dependencies.
+have good reasons to prefer **dynamically linking to system dependencies**.
 In particular:
 
 - Static linking and vendoring obscures the use of external dependencies,
-  making source auditing harder.
+  **making source auditing harder**.
 
-- Dynamic linking makes it possible to easily and quickly replace the used
-  libraries, which can be particularly important when they turn out to
+- Dynamic linking makes it possible to easily and **quickly replace the used
+  libraries**, which can be particularly important when they turn out to
   be vulnerable or buggy.
 
-- Using system dependencies makes the package benefit from downstream
-  customization that can improve the user experience on a particular platform,
+- Using system dependencies makes the package benefit from **downstream
+  customization** that can improve the user experience on a particular platform,
   without the downstream maintainers having to consistently patch
   the dependencies vendored in different packages. This can include
-  compatibility improvements and security hardening.
+  **compatibility improvements and security hardening**.
 
-- Static linking and vendoring could result in multiple different versions
-  of the same library being loaded in the same process (e.g. when you use two
+- Static linking and vendoring could result in **multiple different versions
+  of the same library being loaded in the same process** (e.g. when you use two
   Python packages that link to different versions of the same library).
   This can cause no problems, but it could also lead to anything from subtle
   bugs to catastrophic failures.
 
 - Last but not least, static linking and vendoring results in duplication,
-  and may increase the use of both the disk space and memory.
+  and may increase the **use of both the disk space and memory**.
 
-A good compromise between the needs of both parties is to provide a switch
-between using vendored and system dependencies. Ideally, if the package has
+How?
+~~~~
+A good compromise between the needs of both parties is to **provide a switch
+between using vendored and system dependencies**. Ideally, if the package has
 multiple vendored dependencies, it should provide both individual switches
-for each dependency, and a general switch, for example using
-a  ``USE_SYSTEM_DEPS`` environment variable to control the default. If switched
-on, and a particular dependency is either missing or incompatible, the build
-should fail with an explanatory message, giving the packager an explicit
-indication of the problem and a chance to consciously decide on the preferred
-course of action.
+for each dependency, and a general switch to control the default for them,
+e.g. via a ``USE_SYSTEM_DEPS`` environment variable.
+
+If the user requests using system dependencies, and **a particular dependency
+is either missing or incompatible, the build should fail** with an explanatory
+message rather than fall back to a vendored version. This gives the packager
+the opportunity to notice their mistake and a chance to consciously decide
+how to solve it.
 
 
 .. _Support downstream testing:
 
 Support downstream testing
 --------------------------
+Why?
+~~~~
 A variety of downstream projects run some degree of testing on the packaged
 Python projects. Depending on the particular case, this can range from minimal
 smoke testing to comprehensive runs of the complete test suite. There can
 be various reasons for doing this, for example:
 
-- Verifying that the downstream packaging did not introduce any bugs.
+- Verifying that the downstream **packaging did not introduce any bugs**.
 
-- Testing on a platform that is not covered by upstream testing.
+- Testing on **additional platforms** that are not covered by upstream testing.
 
-- Finding subtle bugs that can only be reproduced on a particular hardware,
-  system package versions, and so on.
+- Finding subtle bugs that can only be reproduced on a **particular hardware,
+  system package versions**, and so on.
 
-- Testing the released package against newer dependency version than the ones
-  present during upstream release testing.
+- Testing the released package against **newer dependency versions** than
+  the ones present during upstream release testing.
 
-- Testing the package in an environment closely resembling the production
-  setup. This can detect issues caused by nontrivial interactions between
+- Testing the package in an environment closely resembling **the production
+  setup**. This can detect issues caused by nontrivial interactions between
   different installed packages, including packages that are not dependencies
   of your package, but nevertheless can cause issues.
 
-- Testing the released package against newer Python versions (including newer
-  point releases), or less tested Python implementations such as PyPy.
+- Testing the released package against **newer Python versions** (including
+  newer point releases), or less tested Python implementations such as PyPy.
 
 Admittedly, sometimes downstream testing may yield false positives or
 inconvenience you about scenarios that you are not interested in supporting.
 However, perhaps even more often it does provide early notice of problems,
 or find nontrivial bugs that would otherwise cause issues for your users
-in production. And believe me, the majority of downstream packagers are doing
+in production. And believe me, the majority of **downstream packagers are doing
 their best to double-check their results, and help you triage and fix the bugs
-that they report.
+that they report**.
 
+How?
+~~~~
 There is a number of things that you can do to help us test your package
 better. Some of them were already mentioned in this discussion. Some examples
 are:

From 08c70e87a763d40832d177be70968e7280af821d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Wed, 29 Jan 2025 21:32:26 +0100
Subject: [PATCH 0876/1072] Elaborate a bit more on why it's good to help
 downstreams

---
 source/discussions/downstream-packaging.rst | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index 71d02e7d0..d3f33668f 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -13,12 +13,22 @@ of other packaging ecosystems. These repackaging efforts are collectively called
 *downstream* packaging (your own efforts are called *upstream* packaging),
 and include such projects as Linux distributions, Conda, Homebrew and MacPorts.
 They often aim to provide good support for use cases that cannot be handled
-via Python packaging tools alone, such as good integration with non-Python
-software.
+via Python packaging tools alone, such as **good integration with non-Python
+software**.
 
 This discussion attempts to explain how downstream packaging is usually done,
 and what challenges are downstream packagers facing. It ultimately aims to give
-you some hints on how you can make downstream packaging easier.
+you some hints on how you can **make downstream packaging easier**.
+
+Establishing a good relationship between software maintainers and downstream
+packagers can bring mutual benefits. Downstreams are often willing to **share
+their experience, time and hardware** to improve your package. They are
+sometimes in a better position to see **the bigger picture**, and to provide
+you with **information about other packages** that would otherwise require you
+to put significant effort to obtain. Packagers often can **find bugs** before
+your users hit them on production, **provide bug reports of good quality**
+and **supply patches** whenever they can. For example, they are often
+in the vanguard when **a new Python version** comes out.
 
 Please note that downstream builds include not only binary redistribution,
 but also source builds done on user systems, in source-first distributions

From 24f552e00ca448d4f6389d3422d8222bbd90224f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Wed, 29 Jan 2025 21:36:12 +0100
Subject: [PATCH 0877/1072] Correct "pytest" capitalization

---
 source/discussions/downstream-packaging.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index d3f33668f..6ea05a348 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -315,7 +315,7 @@ are:
   and testing them all takes a lot of time. Using pytest-xdist_ can help them
   avoid bottlenecks.
 
-- Ideally, **support running your test suite via PyTest**. PyTest_ has many
+- Ideally, **support running your test suite via pytest**. pytest_ has many
   command-line arguments that are truly helpful to downstreams, such as
   the ability to conveniently deselect tests, rerun flaky tests
   (via pytest-rerunfailures_), add a timeout to prevent tests from hanging

From 24b03467f59ba59e154b75fef77a86d250bd03d0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Thu, 30 Jan 2025 13:10:07 +0000
Subject: [PATCH 0878/1072] Apply suggestions from code review

Co-authored-by: Alyssa Coghlan 
---
 source/discussions/downstream-packaging.rst | 242 +++++++++++---------
 1 file changed, 137 insertions(+), 105 deletions(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index 6ea05a348..25740ba29 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -1,84 +1,96 @@
 .. _downstream-packaging:
 
-========================================
-How to make downstream packaging easier?
-========================================
+=================================
+Simplifying downstream packaging
+=================================
 
 :Page Status: Draft
 :Last Reviewed: 2025-?
 
 While PyPI and the Python packaging tools such as :ref:`pip` are the primary
-means of distributing your packages, they are often also made available as part
+means of distributing Python packages, they are also often made available as part
 of other packaging ecosystems. These repackaging efforts are collectively called
 *downstream* packaging (your own efforts are called *upstream* packaging),
 and include such projects as Linux distributions, Conda, Homebrew and MacPorts.
-They often aim to provide good support for use cases that cannot be handled
-via Python packaging tools alone, such as **good integration with non-Python
-software**.
+They generally aim to provide improved support for use cases that cannot be handled
+via Python packaging tools alone, such as native integration with a specific operating
+system, or assured compatibility with specific versions of non-Python software.
 
 This discussion attempts to explain how downstream packaging is usually done,
-and what challenges are downstream packagers facing. It ultimately aims to give
-you some hints on how you can **make downstream packaging easier**.
+and what additional challenges downstream packagers typically face. It aims
+to provide some optional guidelines that project maintainers may choose to
+follow which help make downstream packaging *significantly* easier
+(without imposing any major maintenance hassles on the upstream project).
 
 Establishing a good relationship between software maintainers and downstream
-packagers can bring mutual benefits. Downstreams are often willing to **share
-their experience, time and hardware** to improve your package. They are
-sometimes in a better position to see **the bigger picture**, and to provide
-you with **information about other packages** that would otherwise require you
-to put significant effort to obtain. Packagers often can **find bugs** before
-your users hit them on production, **provide bug reports of good quality**
-and **supply patches** whenever they can. For example, they are often
-in the vanguard when **a new Python version** comes out.
+packagers can bring mutual benefits. Downstreams are often willing to share
+their experience, time and hardware to improve your package. They are
+sometimes in a better position to see how your package is used in practice,
+and to provide information about its relationships with other packages that
+would otherwise require significant effort to obtain.
+Packagers can often find bugs before your users hit them in production,
+provide bug reports of good quality, and supply patches whenever they can.
+For example, they are regularly active in ensuring the packages they redistribute
+are updated for any compatibility issues that arise when a new Python version
+is released.
 
 Please note that downstream builds include not only binary redistribution,
-but also source builds done on user systems, in source-first distributions
-such as Gentoo Linux.
+but also source builds done on user systems (in source-first distributions
+such as Gentoo Linux, for example).
 
 
-.. _Provide complete source distributions:
+.. _provide-complete-source-distributions:
 
 Provide complete source distributions
 -------------------------------------
+
 Why?
 ~~~~
+
 The vast majority of downstream packagers prefer to build packages from source,
 rather than use the upstream-provided binary packages. This is also true
 of pure Python packages that provide universal wheels. The reasons for using
 source distributions may include:
 
-- being able to **audit the source code** of all packages
+- being able to audit the source code of all packages
 
-- being able to **run the test suite and build documentation**
+- being able to run the test suite and build documentation
 
-- being able to **easily apply patches**, including backporting commits
-  from your repository and sending patches back to you
+- being able to easily apply patches, including backporting commits
+  from the project's repository and sending patches back to the project
 
-- being able to **build on a specific platform** that is not covered
+- being able to build on a specific platform that is not covered
   by upstream builds
 
-- being able to **build against specific versions of system libraries**
+- being able to build against specific versions of system libraries
 
 - having a consistent build process across all Python packages
 
 While it is usually possible to build packages from a git repository, there are
 a few important reasons to provide a static archive file instead:
 
-- Fetching a single file is often **more efficient, more reliable and better
-  supported** than e.g. using a git clone. This can help users with a shoddy
-  Internet connection.
+- Fetching a single file is often more efficient, more reliable and better
+  supported than e.g. using a git clone. This can help users with poor
+  Internet connectivity.
 
 - Downstreams often **use checksums to verify the authenticity** of source files
   on subsequent builds, which require that they remain bitwise identical over
   time. For example, automatically generated git archives do not guarantee
   that.
 
-- Archive files can be **mirrored**, reducing both upstream and downstream
+- Archive files can be mirrored, reducing both upstream and downstream
   bandwidth use. The actual builds can afterwards be performed in firewalled
   or offline environments, that can only access source files provided
   by the local mirror or redistributed earlier.
 
+- Explicitly publishing archive files can ensure that any dependencies on version control
+  system metadata are resolved when creating the source archive. For example, automatically
+  generated git archives omit all of the commit tag information, potentially resulting in
+  incorrect version details in the resulting builds.
+
 How?
 ~~~~
+
 Ideally, **a source distribution archive should include all the files**
 necessary to build the package itself, run its test suite, build and install
 its documentation, and any other files that may be useful to end users, such as
@@ -99,23 +111,25 @@ and reduces the risk that some users would hit build failures or install
 an incomplete package.
 
 
-.. _Do not use the Internet during the build process:
+.. _no-internet-access-in-builds:
 
 Do not use the Internet during the build process
 ------------------------------------------------
+
 Why?
 ~~~~
-Downstream builds are frequently done in sandboxed environments that **cannot
-access the Internet**. Even if this is not the case, and assuming that you took
-sufficient care to **properly authenticate downloads**, using the Internet
+
+Downstream builds are frequently done in sandboxed environments that cannot
+access the Internet. Even if this is not the case, and assuming that you took
+sufficient care to properly authenticate downloads, using the Internet
 is discouraged for a number of reasons:
 
-- The Internet **connection may be unstable** (e.g. due to poor reception)
+- The Internet connection may be unstable (e.g. due to poor reception)
   or suffer from temporary problems that could cause the process to fail
   or hang.
 
-- The remote resources may **become temporarily or even permanently
-  unavailable**, making the build no longer possible. This is especially
+- The remote resources may become temporarily or even permanently
+  unavailable, making the build no longer possible. This is especially
   problematic when someone needs to build an old package version.
 
 - Accessing remote servers poses a **privacy** issue and a potential
@@ -123,16 +137,17 @@ is discouraged for a number of reasons:
   the package.
 
 - The user may be using a service with a limited data plan, in which
-  uncontrolled Internet access may result in **additional charges** or other
+  uncontrolled Internet access may result in additional charges or other
   inconveniences.
 
 How?
 ~~~~
-Your source distribution should either **include all the files needed
-for the package to build**, or allow provisioning them externally. Ideally,
+
+Your source distribution should either include all the files needed
+for the package to build, or allow provisioning them externally. Ideally,
 it should not even attempt to access the Internet at all, unless explicitly
 requested to. If that is not possible to achieve, the next best thing
-is to **provide an opt-out switch to disable all Internet access**.
+is to provide an opt-out switch to disable all Internet access.
 
 When such a switch is used, the build process should fail if some
 of the required files are missing, rather than try to fetch them automatically.
@@ -145,114 +160,128 @@ Since downstreams frequently also run tests and build documentation, the above
 should ideally extend to these processes as well.
 
 
-.. _Support building against system dependencies:
+.. _support-system-dependencies-in-builds:
 
 Support building against system dependencies
 --------------------------------------------
+
 Why?
 ~~~~
+
 Some Python projects have non-Python dependencies, such as libraries written
 in C or C++. Trying to use the system versions of these dependencies
 in upstream packaging may cause a number of problems for end users:
 
-- The published wheels **require a binary-compatible version of the used
-  library** to be present on the user's system. If the library is missing
-  or installed in incompatible version, the Python package may fail with errors
+- The published wheels require a binary-compatible version of the used
+  library to be present on the user's system. If the library is missing
+  or an incompatible version is installed, the Python package may fail with errors
   that are not clear to inexperienced users, or even misbehave at runtime.
 
-- Building from source distribution **requires a source-compatible version
-  of the dependency** to be present, along with its development headers
+- Building from a source distribution requires a source-compatible version
+  of the dependency to be present, along with its development headers
   and other auxiliary files that some systems package separately
   from the library itself.
 
 - Even for an experienced user, installing a compatible dependency version
   may be very hard. For example, the used Linux distribution may not provide
-  the required version, or some **other package may require an incompatible
-  version**.
+  the required version, or some other package may require an incompatible
+  version.
 
 - The linkage between the Python package and its system dependency is not
-  recorded by the packaging system. The next system update may **upgrade
-  the library to a newer version that breaks binary compatibility** with
+  recorded by the packaging system. The next system update may upgrade
+  the library to a newer version that breaks binary compatibility with
   the Python package, and requires user intervention to fix.
 
-For these reasons, you may reasonable to decide to either **link statically**
-to your dependencies, or to provide a local copies in the installed package.
-You may also **vendor the dependency** in your source distribution.  Sometimes
-these dependencies are also repackaged on PyPI, and can be installed
-like a regular Python packages.
+For these reasons, you may reasonably decide to either statically link
+your dependencies, or to provide local copies in the installed package.
+You may also vendor the dependency in your source distribution.  Sometimes
+these dependencies are also repackaged on PyPI, and can be declared as
+project dependencies like any other Python package.
 
 However, none of these issues apply to downstream packaging, and downstreams
-have good reasons to prefer **dynamically linking to system dependencies**.
+have good reasons to prefer dynamically linking to system dependencies.
 In particular:
 
+- in many cases, reliably sharing dynamic dependencies between components is a large part
+  of the *purpose* of a downstream packaging ecosystem. Helping to support that makes it
+  easier for users of those systems to access upstream projects in their preferred format.
+
 - Static linking and vendoring obscures the use of external dependencies,
-  **making source auditing harder**.
+  making source auditing harder.
 
-- Dynamic linking makes it possible to easily and **quickly replace the used
-  libraries**, which can be particularly important when they turn out to
-  be vulnerable or buggy.
+- Dynamic linking makes it possible to quickly and systematically replace the used
+  libraries across an entire downstream packaging ecosystem, which can be particularly
+  important when they turn out to contain a security vulnerability or critical bug.
 
-- Using system dependencies makes the package benefit from **downstream
-  customization** that can improve the user experience on a particular platform,
+- Using system dependencies makes the package benefit from downstream
+  customization that can improve the user experience on a particular platform,
   without the downstream maintainers having to consistently patch
   the dependencies vendored in different packages. This can include
-  **compatibility improvements and security hardening**.
+  compatibility improvements and security hardening.
 
-- Static linking and vendoring could result in **multiple different versions
-  of the same library being loaded in the same process** (e.g. when you use two
-  Python packages that link to different versions of the same library).
-  This can cause no problems, but it could also lead to anything from subtle
-  bugs to catastrophic failures.
+- Static linking and vendoring can result in multiple different versions of the
+  same library being loaded in the same process (for example, attempting to
+  import two Python packages that link to different versions of the same library).
+  This sometimes works without incident, but it can also lead to anything from library
+  loading errors, to subtle runtime bugs, to catastrophic system failures.
 
 - Last but not least, static linking and vendoring results in duplication,
-  and may increase the **use of both the disk space and memory**.
+  and may increase the use of both disk space and memory.
 
 How?
 ~~~~
-A good compromise between the needs of both parties is to **provide a switch
-between using vendored and system dependencies**. Ideally, if the package has
+
+A good compromise between the needs of both parties is to provide a switch
+between using vendored and system dependencies. Ideally, if the package has
 multiple vendored dependencies, it should provide both individual switches
 for each dependency, and a general switch to control the default for them,
 e.g. via a ``USE_SYSTEM_DEPS`` environment variable.
 
-If the user requests using system dependencies, and **a particular dependency
-is either missing or incompatible, the build should fail** with an explanatory
+If the user requests using system dependencies, and a particular dependency
+is either missing or incompatible, the build should fail with an explanatory
 message rather than fall back to a vendored version. This gives the packager
 the opportunity to notice their mistake and a chance to consciously decide
 how to solve it.
 
+Note that it is reasonable for upstream projects to leave *testing* of building with
+system dependencies to their downstream repackagers. The goal of these guidelines
+is to facilitate more effective collaboration between upstream projects and downstream
+repackagers, not to suggest upstream projects take on tasks that downstream repackagers
+are better equipped to handle.
 
-.. _Support downstream testing:
+.. _support-downstream-testing:
 
 Support downstream testing
 --------------------------
+
 Why?
 ~~~~
+
 A variety of downstream projects run some degree of testing on the packaged
 Python projects. Depending on the particular case, this can range from minimal
 smoke testing to comprehensive runs of the complete test suite. There can
 be various reasons for doing this, for example:
 
-- Verifying that the downstream **packaging did not introduce any bugs**.
+- Verifying that the downstream packaging did not introduce any bugs.
 
-- Testing on **additional platforms** that are not covered by upstream testing.
+- Testing on additional platforms that are not covered by upstream testing.
 
-- Finding subtle bugs that can only be reproduced on a **particular hardware,
-  system package versions**, and so on.
+- Finding subtle bugs that can only be reproduced with particular hardware,
+  system package versions, and so on.
 
-- Testing the released package against **newer dependency versions** than
+- Testing the released package against newer (or older) dependency versions than
   the ones present during upstream release testing.
 
-- Testing the package in an environment closely resembling **the production
-  setup**. This can detect issues caused by nontrivial interactions between
+- Testing the package in an environment closely resembling the production
+  setup. This can detect issues caused by nontrivial interactions between
   different installed packages, including packages that are not dependencies
   of your package, but nevertheless can cause issues.
 
-- Testing the released package against **newer Python versions** (including
+- Testing the released package against newer Python versions (including
   newer point releases), or less tested Python implementations such as PyPy.
 
-Admittedly, sometimes downstream testing may yield false positives or
-inconvenience you about scenarios that you are not interested in supporting.
+Admittedly, sometimes downstream testing may yield false positives or bug
+reports about scenarios the upstream project is not interested in supporting.
 However, perhaps even more often it does provide early notice of problems,
 or find nontrivial bugs that would otherwise cause issues for your users
 in production. And believe me, the majority of **downstream packagers are doing
@@ -261,61 +290,64 @@ that they report**.
 
 How?
 ~~~~
-There is a number of things that you can do to help us test your package
-better. Some of them were already mentioned in this discussion. Some examples
-are:
 
-- **Include the test files and fixtures in the source distribution**, or make it
+There are a number of things that upstream projects can do to help downstream
+repackagers test their packages efficiently and effectively, including some of the suggestions
+already mentioned above. These are typically improvements that make the test suite more
+reliable and easier to use for everyone, not just downstream packagers.
+Some specific suggestions are:
+
+- Include the test files and fixtures in the source distribution, or make it
   possible to easily download them separately.
 
-- **Do not write to the package directories during testing.** Downstream test
+- Do not write to the package directories during testing. Downstream test
   setups sometimes run tests on top of the installed package, and modifications
   performed during testing and temporary test files may end up being part
   of the installed package!
 
-- **Make the test suite work offline.** Mock network interactions, using
+- Make the test suite work offline. Mock network interactions, using
   packages such as responses_ or vcrpy_. If that is not possible, make it
-  possible to easily disable the tests using Internet access, e.g. via a pytest
+  possible to easily disable the tests using Internet access, e.g. via a pytest_
   marker.  Use pytest-socket_ to verify that your tests work offline. This
   often makes your own test workflows faster and more reliable as well.
 
-- **Make your tests work without a specialized setup**, or perform the necessary
+- Make your tests work without a specialized setup, or perform the necessary
   setup as part of test fixtures. Do not ever assume that you can connect
   to system services such as databases — in an extreme case, you could crash
   a production service!
 
-- **If your package has optional dependencies, make their tests optional as
-  well.** Either skip them if the needed packages are not installed, or add
+- If your package has optional dependencies, make their tests optional as
+  well. Either skip them if the needed packages are not installed, or add
   markers to make deselecting easy.
 
-- More generally, **add markers to tests with special requirements**. These can
+- More generally, add markers to tests with special requirements. These can
   include e.g. significant space usage, significant memory usage, long runtime,
   incompatibility with parallel testing.
 
-- **Do not assume that the test suite will be run with -Werror.** Downstreams
+- Do not assume that the test suite will be run with ``-Werror``. Downstreams
   often need to disable that, as it causes false positives, e.g. due to newer
   dependency versions. Assert for warnings using ``pytest.warns()`` rather
   than ``pytest.raises()``!
 
-- **Aim to make your test suite reliable and reproducible.** Avoid flaky tests.
+- Aim to make your test suite reliable and reproducible. Avoid flaky tests.
   Avoid depending on specific platform details, don't rely on exact results
   of floating-point computation, or timing of operations, and so on. Fuzzing
   has its advantages, but you want to have static test cases for completeness
   as well.
 
-- **Split tests by their purpose, and make it easy to skip categories that are
-  irrelevant or problematic.** Since the primary purpose of downstream testing
-  is to ensure that the package itself works, we generally are not interested
-  in e.g. checking code coverage, code formatting, typing or running
+- Split tests by their purpose, and make it easy to skip categories that are
+  irrelevant or problematic. Since the primary purpose of downstream testing
+  is to ensure that the package itself works, downstreams are not generally interested
+  in tasks such as checking code coverage, code formatting, typechecking or running
   benchmarks. These tests can fail as dependencies are upgraded or the system
   is under load, without actually affecting the package itself.
 
-- If your test suite takes significant time to run, **support testing
-  in parallel.** Downstreams often maintain a large number of packages,
+- If your test suite takes significant time to run, support testing
+  in parallel. Downstreams often maintain a large number of packages,
   and testing them all takes a lot of time. Using pytest-xdist_ can help them
   avoid bottlenecks.
 
-- Ideally, **support running your test suite via pytest**. pytest_ has many
+- Ideally, support running your test suite via ``pytest``. pytest_ has many
   command-line arguments that are truly helpful to downstreams, such as
   the ability to conveniently deselect tests, rerun flaky tests
   (via pytest-rerunfailures_), add a timeout to prevent tests from hanging

From 16288af66e9877d1bb8a3812d6c74adfc2db19f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Thu, 30 Jan 2025 13:12:57 +0000
Subject: [PATCH 0879/1072] Apply more suggestions from code review

Co-authored-by: Alyssa Coghlan 
---
 source/discussions/downstream-packaging.rst | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index 25740ba29..984816c14 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -165,9 +165,11 @@ should ideally extend to these processes as well.
 Support building against system dependencies
 --------------------------------------------
 
+
 Why?
 ~~~~
 
+
 Some Python projects have non-Python dependencies, such as libraries written
 in C or C++. Trying to use the system versions of these dependencies
 in upstream packaging may cause a number of problems for end users:
@@ -202,6 +204,10 @@ However, none of these issues apply to downstream packaging, and downstreams
 have good reasons to prefer dynamically linking to system dependencies.
 In particular:
 
+- in many cases, reliably sharing dynamic dependencies between components is a large part
+  of the *purpose* of a downstream packaging ecosystem. Helping to support that makes it
+  easier for users of those systems to access upstream projects in their preferred format.
+
 - in many cases, reliably sharing dynamic dependencies between components is a large part
   of the *purpose* of a downstream packaging ecosystem. Helping to support that makes it
   easier for users of those systems to access upstream projects in their preferred format.
@@ -231,6 +237,7 @@ In particular:
 How?
 ~~~~
 
+
 A good compromise between the needs of both parties is to provide a switch
 between using vendored and system dependencies. Ideally, if the package has
 multiple vendored dependencies, it should provide both individual switches
@@ -243,6 +250,11 @@ message rather than fall back to a vendored version. This gives the packager
 the opportunity to notice their mistake and a chance to consciously decide
 how to solve it.
 
+Note that it is reasonable for upstream projects to leave *testing* of building with
+system dependencies to their downstream repackagers. The goal of these guidelines
+is to facilitate more effective collaboration between upstream projects and downstream
+repackagers, not to suggest upstream projects take on tasks that downstream repackagers
+are better equipped to handle.
 Note that it is reasonable for upstream projects to leave *testing* of building with
 system dependencies to their downstream repackagers. The goal of these guidelines
 is to facilitate more effective collaboration between upstream projects and downstream
@@ -254,9 +266,11 @@ are better equipped to handle.
 Support downstream testing
 --------------------------
 
+
 Why?
 ~~~~
 
+
 A variety of downstream projects run some degree of testing on the packaged
 Python projects. Depending on the particular case, this can range from minimal
 smoke testing to comprehensive runs of the complete test suite. There can
@@ -291,6 +305,7 @@ that they report**.
 How?
 ~~~~
 
+
 There are a number of things that upstream projects can do to help downstream
 repackagers test their packages efficiently and effectively, including some of the suggestions
 already mentioned above. These are typically improvements that make the test suite more

From b4c7485665311525bf50951f6ecf50ff541caa18 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Thu, 30 Jan 2025 16:28:40 +0100
Subject: [PATCH 0880/1072] Attempt addressing the remaining review comments

---
 source/discussions/downstream-packaging.rst | 32 ++++++++++-----------
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index 984816c14..fc9514ade 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -73,10 +73,10 @@ a few important reasons to provide a static archive file instead:
   supported than e.g. using a git clone. This can help users with poor
   Internet connectivity.
 
-- Downstreams often **use checksums to verify the authenticity** of source files
+- Downstreams often use hashes to verify the authenticity of source files
   on subsequent builds, which require that they remain bitwise identical over
   time. For example, automatically generated git archives do not guarantee
-  that.
+  this, as the compressed data may change if gzip is upgraded on the server.
 
 - Archive files can be mirrored, reducing both upstream and downstream
   bandwidth use. The actual builds can afterwards be performed in firewalled
@@ -132,8 +132,8 @@ is discouraged for a number of reasons:
   unavailable, making the build no longer possible. This is especially
   problematic when someone needs to build an old package version.
 
-- Accessing remote servers poses a **privacy** issue and a potential
-  **security** issue, as it exposes information about the system building
+- Accessing remote servers poses a privacy issue and a potential
+  security issue, as it exposes information about the system building
   the package.
 
 - The user may be using a service with a limited data plan, in which
@@ -153,8 +153,8 @@ When such a switch is used, the build process should fail if some
 of the required files are missing, rather than try to fetch them automatically.
 This could be done e.g. by checking whether a ``NO_NETWORK`` environment
 variable is set to a non-empty value. Please also remember that if you are
-fetching remote resources, you must **verify their authenticity**, e.g. against
-a checksum, to protect against the file being substituted by a malicious party.
+fetching remote resources, you must *verify their authenticity* (usually against
+a hash), to protect against the file being substituted by a malicious party.
 
 Since downstreams frequently also run tests and build documentation, the above
 should ideally extend to these processes as well.
@@ -165,11 +165,9 @@ should ideally extend to these processes as well.
 Support building against system dependencies
 --------------------------------------------
 
-
 Why?
 ~~~~
 
-
 Some Python projects have non-Python dependencies, such as libraries written
 in C or C++. Trying to use the system versions of these dependencies
 in upstream packaging may cause a number of problems for end users:
@@ -237,7 +235,6 @@ In particular:
 How?
 ~~~~
 
-
 A good compromise between the needs of both parties is to provide a switch
 between using vendored and system dependencies. Ideally, if the package has
 multiple vendored dependencies, it should provide both individual switches
@@ -266,11 +263,9 @@ are better equipped to handle.
 Support downstream testing
 --------------------------
 
-
 Why?
 ~~~~
 
-
 A variety of downstream projects run some degree of testing on the packaged
 Python projects. Depending on the particular case, this can range from minimal
 smoke testing to comprehensive runs of the complete test suite. There can
@@ -287,7 +282,7 @@ be various reasons for doing this, for example:
   the ones present during upstream release testing.
 
 - Testing the package in an environment closely resembling the production
-  setup. This can detect issues caused by nontrivial interactions between
+  setup. This can detect issues caused by non-trivial interactions between
   different installed packages, including packages that are not dependencies
   of your package, but nevertheless can cause issues.
 
@@ -297,15 +292,14 @@ be various reasons for doing this, for example:
 Admittedly, sometimes downstream testing may yield false positives or bug
 reports about scenarios the upstream project is not interested in supporting.
 However, perhaps even more often it does provide early notice of problems,
-or find nontrivial bugs that would otherwise cause issues for your users
-in production. And believe me, the majority of **downstream packagers are doing
-their best to double-check their results, and help you triage and fix the bugs
-that they report**.
+or find non-trivial bugs that would otherwise cause issues for the upstream
+project's users. While mistakes do happen, the majority of downstream packagers
+are doing their best to double-check their results, and help upstream
+maintainers triage and fix the bugs that they reported.
 
 How?
 ~~~~
 
-
 There are a number of things that upstream projects can do to help downstream
 repackagers test their packages efficiently and effectively, including some of the suggestions
 already mentioned above. These are typically improvements that make the test suite more
@@ -367,6 +361,10 @@ Some specific suggestions are:
   the ability to conveniently deselect tests, rerun flaky tests
   (via pytest-rerunfailures_), add a timeout to prevent tests from hanging
   (via pytest-timeout_) or run tests in parallel (via pytest-xdist_).
+  Note that test suites don't need to be *written* with ``pytest`` to be
+  *executed* with ``pytest``: ``pytest`` is able to find and execute almost
+  all test cases that are compatible with the standard library's ``unittest``
+  test discovery.
 
 
 .. _responses: https://pypi.org/project/responses/

From df0c91a6f379ef4139b632c3f5aebdcb46e8ea58 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Thu, 30 Jan 2025 20:20:01 +0100
Subject: [PATCH 0881/1072] Add a section on stable channels

---
 source/discussions/downstream-packaging.rst | 66 +++++++++++++++++++++
 1 file changed, 66 insertions(+)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index fc9514ade..edb21dcc9 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -367,6 +367,71 @@ Some specific suggestions are:
   test discovery.
 
 
+.. _aim-for-stable-releases:
+
+Aim for stable releases
+-----------------------
+
+Why?
+~~~~
+
+Many downstreams provide stable release channels in addition to the main
+package streams. The goal of these channels is to provide more conservative
+upgrades to users with higher stability needs. These users often prefer
+to trade having the newest features available for lower risk of issues.
+
+While the exact policies differ, an important criterion for including a new
+package version in a stable release channel is for it to be available in testing
+for some time already, and have no known major regressions. For example,
+in Gentoo Linux a package is usually marked stable after being available
+in testing for a month, and being tested against the versions of its
+dependencies that are marked stable at the time.
+
+However, there are circumstances which demand more prompt action. For example,
+if a security vulnerability or a major bug is found in the version that is
+currently available in the stable channel, the downstream is facing a need
+to resolve it. In this case, they need to consider various options, such as:
+
+- putting a new version in the stable channel early,
+
+- adding patches to the version currently published,
+
+- or even downgrading the stable channel to an earlier release.
+
+Each of these options involves certain risks and a certain amount of work,
+and packagers needs to weigh them to determine the course of action.
+
+How?
+~~~~
+
+There are some things that upstreams can do to tailor their workflow to stable
+release channels. These actions often are beneficial to the package's users
+as well. Some specific suggestions are:
+
+- Adjust the release frequency to the rate of code changes. Packages that
+  are released rarely often bring significant changes with every release,
+  and a higher risk of accidental regressions.
+
+- Avoid mixing bug fixes and new features, if possible. In particular, if there
+  are known bug fixes merged already, consider making a new release before
+  merging feature branches.
+
+- Consider making prereleases after major changes, to provide more testing
+  opportunities for users and downstreams willing to opt-in.
+
+- If your project is subject to very intense development, consider splitting
+  one or more branches that include a more conservative subset of commits,
+  and are released separately. For example, Django_ currently maintains three
+  release branches in addition to main.
+
+- Even if you don't wish to maintain additional branches permanently, consider
+  making additional patch releases with minimal changes to the previous
+  version, especially when a security vulnerability is discovered.
+
+- Split your changes into focused commits that address one problem at a time,
+  to make it easier to cherry-pick changes to earlier releases when necessary.
+
+
 .. _responses: https://pypi.org/project/responses/
 .. _vcrpy: https://pypi.org/project/vcrpy/
 .. _pytest-socket: https://pypi.org/project/pytest-socket/
@@ -374,3 +439,4 @@ Some specific suggestions are:
 .. _pytest: https://pytest.org/
 .. _pytest-rerunfailures: https://pypi.org/project/pytest-rerunfailures/
 .. _pytest-timeout: https://pypi.org/project/pytest-timeout/
+.. _Django: https://www.djangoproject.com/

From fc72a38cc39b1590e752d1181118c5a073bcb813 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Fri, 31 Jan 2025 15:41:16 +0100
Subject: [PATCH 0882/1072] Retitle as "Supporting downstream packaging"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Thanks to @pfmoore for the suggestion.

Signed-off-by: Michał Górny 
---
 source/discussions/downstream-packaging.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index edb21dcc9..1ff735e99 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -1,8 +1,8 @@
 .. _downstream-packaging:
 
-=================================
-Simplifying downstream packaging
-=================================
+===============================
+Supporting downstream packaging
+===============================
 
 :Page Status: Draft
 :Last Reviewed: 2025-?

From 24462f4b05c838219b1fe9327caff32bbdd05a61 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Fri, 31 Jan 2025 15:42:51 +0100
Subject: [PATCH 0883/1072] Add a "not all-or-nothing" sentence
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Suggested by @pfmoore on https://discuss.python.org/t/request-for-feedback-packaging-p-o-discussion-on-helping-downstream-packaging/78985/2

Signed-off-by: Michał Górny 
---
 source/discussions/downstream-packaging.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index 1ff735e99..d3df25ad1 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -21,6 +21,8 @@ and what additional challenges downstream packagers typically face. It aims
 to provide some optional guidelines that project maintainers may choose to
 follow which help make downstream packaging *significantly* easier
 (without imposing any major maintenance hassles on the upstream project).
+Note that this is not an all-or-nothing proposal — anything that upstream
+maintainers can do is useful, even if it's only a small part.
 
 Establishing a good relationship between software maintainers and downstream
 packagers can bring mutual benefits. Downstreams are often willing to share

From 29cc38acf6ac0649b88ec00d68165b3ec8dc25b2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Fri, 31 Jan 2025 15:53:41 +0100
Subject: [PATCH 0884/1072] Add a note that downstreams can send patches to fix
 these issues

---
 source/discussions/downstream-packaging.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index d3df25ad1..c4934b802 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -22,7 +22,8 @@ to provide some optional guidelines that project maintainers may choose to
 follow which help make downstream packaging *significantly* easier
 (without imposing any major maintenance hassles on the upstream project).
 Note that this is not an all-or-nothing proposal — anything that upstream
-maintainers can do is useful, even if it's only a small part.
+maintainers can do is useful, even if it's only a small part. Downstream
+maintainers are also willing to prepare patches to resolve these issues.
 
 Establishing a good relationship between software maintainers and downstream
 packagers can bring mutual benefits. Downstreams are often willing to share

From 9d5fbe6d212f0e50b6963594aec0128a1b0d999f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Sat, 1 Feb 2025 15:44:41 +0100
Subject: [PATCH 0885/1072] Capitalize Git, per @pawamoy

---
 source/discussions/downstream-packaging.rst | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index c4934b802..bc5edbf4d 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -69,16 +69,16 @@ source distributions may include:
 
 - having a consistent build process across all Python packages
 
-While it is usually possible to build packages from a git repository, there are
+While it is usually possible to build packages from a Git repository, there are
 a few important reasons to provide a static archive file instead:
 
 - Fetching a single file is often more efficient, more reliable and better
-  supported than e.g. using a git clone. This can help users with poor
+  supported than e.g. using a Git clone. This can help users with poor
   Internet connectivity.
 
 - Downstreams often use hashes to verify the authenticity of source files
   on subsequent builds, which require that they remain bitwise identical over
-  time. For example, automatically generated git archives do not guarantee
+  time. For example, automatically generated Git archives do not guarantee
   this, as the compressed data may change if gzip is upgraded on the server.
 
 - Archive files can be mirrored, reducing both upstream and downstream
@@ -88,7 +88,7 @@ a few important reasons to provide a static archive file instead:
 
 - Explicitly publishing archive files can ensure that any dependencies on version control
   system metadata are resolved when creating the source archive. For example, automatically
-  generated git archives omit all of the commit tag information, potentially resulting in
+  generated Git archives omit all of the commit tag information, potentially resulting in
   incorrect version details in the resulting builds.
 
 How?
@@ -108,7 +108,7 @@ separate archives.
 
 A good idea is to **use your source distribution in the release workflow**.
 That is, build it first, then unpack it and perform all the remaining steps
-using the unpacked distribution rather than the git repostiry — run tests,
+using the unpacked distribution rather than the Git repostiry — run tests,
 build documentation, build wheels. This ensures that it is well-tested,
 and reduces the risk that some users would hit build failures or install
 an incomplete package.

From 4d95da2cf538aec9f8eb81cc239a0a7279e9aee0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Sat, 1 Feb 2025 15:46:23 +0100
Subject: [PATCH 0886/1072] Fix inconsistent case in bullet points and remove
 duplicate

Thanks to @pawamoy
---
 source/discussions/downstream-packaging.rst | 22 +++++++++------------
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index bc5edbf4d..9110b1f82 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -55,19 +55,19 @@ rather than use the upstream-provided binary packages. This is also true
 of pure Python packages that provide universal wheels. The reasons for using
 source distributions may include:
 
-- being able to audit the source code of all packages
+- Being able to audit the source code of all packages.
 
-- being able to run the test suite and build documentation
+- Being able to run the test suite and build documentation.
 
-- being able to easily apply patches, including backporting commits
-  from the project's repository and sending patches back to the project
+- Being able to easily apply patches, including backporting commits
+  from the project's repository and sending patches back to the project.
 
-- being able to build on a specific platform that is not covered
-  by upstream builds
+- Being able to build on a specific platform that is not covered
+  by upstream builds.
 
-- being able to build against specific versions of system libraries
+- Being able to build against specific versions of system libraries.
 
-- having a consistent build process across all Python packages
+- Having a consistent build process across all Python packages.
 
 While it is usually possible to build packages from a Git repository, there are
 a few important reasons to provide a static archive file instead:
@@ -205,11 +205,7 @@ However, none of these issues apply to downstream packaging, and downstreams
 have good reasons to prefer dynamically linking to system dependencies.
 In particular:
 
-- in many cases, reliably sharing dynamic dependencies between components is a large part
-  of the *purpose* of a downstream packaging ecosystem. Helping to support that makes it
-  easier for users of those systems to access upstream projects in their preferred format.
-
-- in many cases, reliably sharing dynamic dependencies between components is a large part
+- In many cases, reliably sharing dynamic dependencies between components is a large part
   of the *purpose* of a downstream packaging ecosystem. Helping to support that makes it
   easier for users of those systems to access upstream projects in their preferred format.
 

From 6f557097a422beb7d81a3bcb245a3e5569a16c8e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Sat, 1 Feb 2025 15:52:59 +0100
Subject: [PATCH 0887/1072] Apply typo fixes, thanks to @pawamoy

---
 source/discussions/downstream-packaging.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index 9110b1f82..3aef888f4 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -99,7 +99,7 @@ necessary to build the package itself, run its test suite, build and install
 its documentation, and any other files that may be useful to end users, such as
 shell completions, editor support files, and so on.
 
-Some projects are concerned about increasing the size of source distribution,
+Some projects are concerned about increasing the size of source distributions,
 or do not wish Python packaging tools to fall back to source distributions
 automatically.  In these cases, a good compromise may be to publish a separate
 source archive for downstream use, for example by attaching it to a GitHub
@@ -108,7 +108,7 @@ separate archives.
 
 A good idea is to **use your source distribution in the release workflow**.
 That is, build it first, then unpack it and perform all the remaining steps
-using the unpacked distribution rather than the Git repostiry — run tests,
+using the unpacked distribution rather than the Git repository — run tests,
 build documentation, build wheels. This ensures that it is well-tested,
 and reduces the risk that some users would hit build failures or install
 an incomplete package.

From 548ab343b608b6885190f23d75d6f29bbf0ff1e3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Sat, 1 Feb 2025 16:09:41 +0100
Subject: [PATCH 0888/1072] Clarify that source distribution needs only
 package's files

Let's add some clarification to the "complete source distribution" part
to make it clear that we're talking only of package's files, and not
requiring people to vendor all the dependencies.
---
 source/discussions/downstream-packaging.rst | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index 3aef888f4..ae4dc5235 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -94,10 +94,19 @@ a few important reasons to provide a static archive file instead:
 How?
 ~~~~
 
-Ideally, **a source distribution archive should include all the files**
-necessary to build the package itself, run its test suite, build and install
-its documentation, and any other files that may be useful to end users, such as
-shell completions, editor support files, and so on.
+Ideally, **a source distribution archive should include all the files
+from the package's Git repository** that are necessary to build the package
+itself, run its test suite, build and install its documentation, and any other
+files that may be useful to end users, such as shell completions, editor
+support files, and so on.
+
+This point applies only to the files belonging to the package itself.
+The downstream packaging process, much like Python package managers, will
+provision the necessary Python dependencies, system tools and external
+libraries that are needed by your package and its build scripts. However,
+the files listing these dependencies (for example, ``requirements*.txt`` files)
+should also be included, to help downstreams determine the needed dependencies,
+and check for changes in them.
 
 Some projects are concerned about increasing the size of source distributions,
 or do not wish Python packaging tools to fall back to source distributions

From e925da1d066140ee628068f9438ec43def11556d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Sat, 1 Feb 2025 16:10:39 +0100
Subject: [PATCH 0889/1072] Fix inconsistent whitespace between sentences

---
 source/discussions/downstream-packaging.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index ae4dc5235..ec6b782d3 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -110,7 +110,7 @@ and check for changes in them.
 
 Some projects are concerned about increasing the size of source distributions,
 or do not wish Python packaging tools to fall back to source distributions
-automatically.  In these cases, a good compromise may be to publish a separate
+automatically. In these cases, a good compromise may be to publish a separate
 source archive for downstream use, for example by attaching it to a GitHub
 release. Alternatively, large files, such as test data, can be split into
 separate archives.
@@ -206,7 +206,7 @@ in upstream packaging may cause a number of problems for end users:
 
 For these reasons, you may reasonably decide to either statically link
 your dependencies, or to provide local copies in the installed package.
-You may also vendor the dependency in your source distribution.  Sometimes
+You may also vendor the dependency in your source distribution. Sometimes
 these dependencies are also repackaged on PyPI, and can be declared as
 project dependencies like any other Python package.
 
@@ -325,7 +325,7 @@ Some specific suggestions are:
 - Make the test suite work offline. Mock network interactions, using
   packages such as responses_ or vcrpy_. If that is not possible, make it
   possible to easily disable the tests using Internet access, e.g. via a pytest_
-  marker.  Use pytest-socket_ to verify that your tests work offline. This
+  marker. Use pytest-socket_ to verify that your tests work offline. This
   often makes your own test workflows faster and more reliable as well.
 
 - Make your tests work without a specialized setup, or perform the necessary

From 0eb407c94d61a253cfe5a89fb0868ed0e4eb9d02 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Sat, 1 Feb 2025 16:28:51 +0100
Subject: [PATCH 0890/1072] Make the point of reusing source distribution
 lighter

Split the reuse of source distribution into two parts: the easier part
of building a wheel from sdist (which is what build tool does),
and the harder part of using it in all workflows. For the latter,
suggest it's fine to let downstreams worry about that.
---
 source/discussions/downstream-packaging.rst | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index ec6b782d3..5ec53a354 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -115,12 +115,16 @@ source archive for downstream use, for example by attaching it to a GitHub
 release. Alternatively, large files, such as test data, can be split into
 separate archives.
 
-A good idea is to **use your source distribution in the release workflow**.
-That is, build it first, then unpack it and perform all the remaining steps
-using the unpacked distribution rather than the Git repository — run tests,
-build documentation, build wheels. This ensures that it is well-tested,
-and reduces the risk that some users would hit build failures or install
-an incomplete package.
+A good idea is to use your source distribution in the release workflow.
+For example, the :ref:`build` tool does exactly that — it first builds a source
+distribution, and then uses it to build a wheel. This ensures that the source
+distribution actually works, and that it won't accidentally install fewer files
+than the official wheels.
+
+Ideally, use the source distribution also run tests, build documentation,
+and so on, or add specific tests to make sure that all necessary files were
+actually included. Understandably, this requires more effort, so it's fine
+not do that — downstream packagers will report any missing files promptly.
 
 
 .. _no-internet-access-in-builds:

From 94743f973b2b68af2c3d16614e8aa4ab4edc52c4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Sat, 1 Feb 2025 16:45:34 +0100
Subject: [PATCH 0891/1072] Clarify the Internet part

Clarify the "do not use the Internet" part to make it clearer that we're
talking about backend actions, and custom build scripts in particular.
We're not talking of Python dependencies that are fetched and installed
by frontends.  Also, reflow the text to be more logical.
---
 source/discussions/downstream-packaging.rst | 40 +++++++++++++--------
 1 file changed, 26 insertions(+), 14 deletions(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index 5ec53a354..67ed491bf 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -136,9 +136,12 @@ Why?
 ~~~~
 
 Downstream builds are frequently done in sandboxed environments that cannot
-access the Internet. Even if this is not the case, and assuming that you took
-sufficient care to properly authenticate downloads, using the Internet
-is discouraged for a number of reasons:
+access the Internet. The package sources are unpacked into this environment,
+and all the necessary dependencies are installed.
+
+Even if this is not the case, and assuming that you took sufficient care to
+properly authenticate downloads, using the Internet is discouraged for a number
+of reasons:
 
 - The Internet connection may be unstable (e.g. due to poor reception)
   or suffer from temporary problems that could cause the process to fail
@@ -159,22 +162,31 @@ is discouraged for a number of reasons:
 How?
 ~~~~
 
-Your source distribution should either include all the files needed
-for the package to build, or allow provisioning them externally. Ideally,
-it should not even attempt to access the Internet at all, unless explicitly
-requested to. If that is not possible to achieve, the next best thing
-is to provide an opt-out switch to disable all Internet access.
+If the package is implementing any custom build *backend* actions that use
+the Internet, for example by automatically downloading vendored dependencies
+or fetching Git submodules, its source distribution should either include all
+of these files or allow provisioning them externally, and the Internet must not
+be used if the files are already present.
+
+Note that this point does not apply to Python dependencies that are specified
+in the package metadata, and are fetched during the build and installation
+process by *frontends* (such as :ref:`build` or :ref:`pip`). Downstreams use
+frontends that use local provisioning for Python dependencies.
 
-When such a switch is used, the build process should fail if some
-of the required files are missing, rather than try to fetch them automatically.
-This could be done e.g. by checking whether a ``NO_NETWORK`` environment
-variable is set to a non-empty value. Please also remember that if you are
-fetching remote resources, you must *verify their authenticity* (usually against
-a hash), to protect against the file being substituted by a malicious party.
+Ideally, custom build scripts should not even attempt to access the Internet
+at all, unless explicitly requested to. If any resources are missing and need
+to be fetched, they should ask the user for permission first. If that is not
+feasible, the next best thing is to provide an opt-out switch to disable
+all Internet access. This could be done e.g. by checking whether
+a ``NO_NETWORK`` environment variable is set to a non-empty value.
 
 Since downstreams frequently also run tests and build documentation, the above
 should ideally extend to these processes as well.
 
+Please also remember that if you are fetching remote resources, you absolutely
+must *verify their authenticity* (usually against a hash), to protect against
+the file being substituted by a malicious party.
+
 
 .. _support-system-dependencies-in-builds:
 

From 704d1a575d0950d6bedd9722dcf73b439c325c89 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Sat, 1 Feb 2025 19:38:29 +0000
Subject: [PATCH 0892/1072] Apply suggestions from code review

Co-authored-by: Jelle Zijlstra 
---
 source/discussions/downstream-packaging.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index 67ed491bf..118d04a4c 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -121,7 +121,7 @@ distribution, and then uses it to build a wheel. This ensures that the source
 distribution actually works, and that it won't accidentally install fewer files
 than the official wheels.
 
-Ideally, use the source distribution also run tests, build documentation,
+Ideally, also use the source distribution to run tests, build documentation,
 and so on, or add specific tests to make sure that all necessary files were
 actually included. Understandably, this requires more effort, so it's fine
 not do that — downstream packagers will report any missing files promptly.
@@ -271,7 +271,7 @@ message rather than fall back to a vendored version. This gives the packager
 the opportunity to notice their mistake and a chance to consciously decide
 how to solve it.
 
-Note that it is reasonable for upstream projects to leave *testing* of building with
+It is reasonable for upstream projects to leave *testing* of building with
 system dependencies to their downstream repackagers. The goal of these guidelines
 is to facilitate more effective collaboration between upstream projects and downstream
 repackagers, not to suggest upstream projects take on tasks that downstream repackagers

From e5966091ec6981157255f1a4651d05e7c9f5d7f7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Sat, 1 Feb 2025 20:57:23 +0100
Subject: [PATCH 0893/1072] Remove duplicate paragraph

---
 source/discussions/downstream-packaging.rst | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index 118d04a4c..e29cf08fe 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -276,11 +276,6 @@ system dependencies to their downstream repackagers. The goal of these guideline
 is to facilitate more effective collaboration between upstream projects and downstream
 repackagers, not to suggest upstream projects take on tasks that downstream repackagers
 are better equipped to handle.
-Note that it is reasonable for upstream projects to leave *testing* of building with
-system dependencies to their downstream repackagers. The goal of these guidelines
-is to facilitate more effective collaboration between upstream projects and downstream
-repackagers, not to suggest upstream projects take on tasks that downstream repackagers
-are better equipped to handle.
 
 .. _support-downstream-testing:
 

From 169281d98494cc662ae0b00243d454dc394ec2b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Sat, 1 Feb 2025 20:57:35 +0100
Subject: [PATCH 0894/1072] Clarify source distributions

Clarify that "source distributions" generally refer to the files
published on PyPI, and when we are referring to publishing them
elsewhere.  While at it, expand on the size/fallback argument,
and mention that some projects install tests as part of the Python
package.
---
 source/discussions/downstream-packaging.rst | 27 +++++++++++++++------
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index e29cf08fe..6e69ca4af 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -94,7 +94,7 @@ a few important reasons to provide a static archive file instead:
 How?
 ~~~~
 
-Ideally, **a source distribution archive should include all the files
+Ideally, **a source distribution archive published on PyPI should include all the files
 from the package's Git repository** that are necessary to build the package
 itself, run its test suite, build and install its documentation, and any other
 files that may be useful to end users, such as shell completions, editor
@@ -108,12 +108,22 @@ the files listing these dependencies (for example, ``requirements*.txt`` files)
 should also be included, to help downstreams determine the needed dependencies,
 and check for changes in them.
 
-Some projects are concerned about increasing the size of source distributions,
-or do not wish Python packaging tools to fall back to source distributions
-automatically. In these cases, a good compromise may be to publish a separate
-source archive for downstream use, for example by attaching it to a GitHub
-release. Alternatively, large files, such as test data, can be split into
-separate archives.
+Some projects have concerns related to Python package managers using source
+distributions from PyPI. They do not wish to increase their size with files
+that are not used by these tools, or they do not wish to publish source
+distributions at all, as they enable a problematic or outright nonfunctional
+fallback to building the particular project from source. In these cases, a good
+compromise may be to publish a separate source archive for downstream use
+elsewhere, for example by attaching it to a GitHub release. Alternatively,
+large files, such as test data, can be split into separate archives.
+
+On the other hand, some projects (NumPy_, for instance) decide to install tests
+in their Python packages. This has the added advantage of permitting users to
+run tests after installing them, for example to check for regressions
+after upgrading a dependency. Yet another approach is to split tests or test
+data into a separate Python package. Such an approach was taken by
+the cryptography_ project, with the large test vectors being split
+to cryptography-vectors_ package.
 
 A good idea is to use your source distribution in the release workflow.
 For example, the :ref:`build` tool does exactly that — it first builds a source
@@ -459,3 +469,6 @@ as well. Some specific suggestions are:
 .. _pytest-rerunfailures: https://pypi.org/project/pytest-rerunfailures/
 .. _pytest-timeout: https://pypi.org/project/pytest-timeout/
 .. _Django: https://www.djangoproject.com/
+.. _NumPy: https://numpy.org/
+.. _cryptography: https://pypi.org/project/cryptography/
+.. _cryptography-vectors: https://pypi.org/project/cryptography-vectors/

From bb8ac35a866e807823770e4effab785cdb39f444 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Sat, 1 Feb 2025 20:58:38 +0100
Subject: [PATCH 0895/1072] Add non-reproducibility argument for changing
 resources

---
 source/discussions/downstream-packaging.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index 6e69ca4af..5fbab130f 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -161,6 +161,8 @@ of reasons:
   unavailable, making the build no longer possible. This is especially
   problematic when someone needs to build an old package version.
 
+- The remote resources may change, making the build not reproducible.
+
 - Accessing remote servers poses a privacy issue and a potential
   security issue, as it exposes information about the system building
   the package.

From addf891979a8600e75a111568b04cdf058087b5b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Sun, 2 Feb 2025 14:51:50 +0100
Subject: [PATCH 0896/1072] Mention removing duplication of patches and
 inconsistency

---
 source/discussions/downstream-packaging.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index 5fbab130f..3a08cf2a7 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -24,6 +24,9 @@ follow which help make downstream packaging *significantly* easier
 Note that this is not an all-or-nothing proposal — anything that upstream
 maintainers can do is useful, even if it's only a small part. Downstream
 maintainers are also willing to prepare patches to resolve these issues.
+Having these patches merged can be very helpful, since it removes the need
+for different downstreams to carry and keep rebasing the same patches,
+and the risk of applying inconsistent solutions to the same problem.
 
 Establishing a good relationship between software maintainers and downstream
 packagers can bring mutual benefits. Downstreams are often willing to share

From 8a3a56c4e4d9f030962ca3b5fb89704ebd302ffc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Sun, 2 Feb 2025 14:52:10 +0100
Subject: [PATCH 0897/1072] Reword installing tests to make it clearer

---
 source/discussions/downstream-packaging.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index 3a08cf2a7..723b3fe75 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -120,8 +120,8 @@ compromise may be to publish a separate source archive for downstream use
 elsewhere, for example by attaching it to a GitHub release. Alternatively,
 large files, such as test data, can be split into separate archives.
 
-On the other hand, some projects (NumPy_, for instance) decide to install tests
-in their Python packages. This has the added advantage of permitting users to
+On the other hand, some projects (NumPy_, for instance) decide to include tests
+in their installed packages. This has the added advantage of permitting users to
 run tests after installing them, for example to check for regressions
 after upgrading a dependency. Yet another approach is to split tests or test
 data into a separate Python package. Such an approach was taken by

From 58eaf854f6b53dff449d3bf93bef8f70854428df Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Sun, 2 Feb 2025 14:52:28 +0100
Subject: [PATCH 0898/1072] Give an example of "catastrophic failure"

---
 source/discussions/downstream-packaging.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index 723b3fe75..d25845e47 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -266,7 +266,8 @@ In particular:
   same library being loaded in the same process (for example, attempting to
   import two Python packages that link to different versions of the same library).
   This sometimes works without incident, but it can also lead to anything from library
-  loading errors, to subtle runtime bugs, to catastrophic system failures.
+  loading errors, to subtle runtime bugs, to catastrophic failures (like suddenly
+  crashing and losing data).
 
 - Last but not least, static linking and vendoring results in duplication,
   and may increase the use of both disk space and memory.

From 54c2002d5f9dd6fca7069568782cfd2ea346954c Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Tue, 4 Feb 2025 21:18:09 +0100
Subject: [PATCH 0899/1072] simple-repository-api: bump, explain api-version

Signed-off-by: William Woodruff 
---
 source/specifications/simple-repository-api.rst | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/source/specifications/simple-repository-api.rst b/source/specifications/simple-repository-api.rst
index 9ec8e4bf2..a96e4e7a8 100644
--- a/source/specifications/simple-repository-api.rst
+++ b/source/specifications/simple-repository-api.rst
@@ -101,6 +101,10 @@ In addition to the above, the following constraints are placed on the API:
   the file's provenance can be found at that URL. This URL **MUST** represent
   a `secure origin `_.
 
+  .. note::
+
+    The ``data-provenance`` attribute was added with API version 1.3.
+
   .. note::
 
     The format of the linked provenance is defined in :ref:`index-hosted-attestations`.
@@ -213,7 +217,7 @@ specification `.
 
 This would end up looking like::
 
-  
+  
 
 When interpreting the repository version:
 
@@ -405,7 +409,7 @@ As an example:
 
     {
       "meta": {
-        "api-version": "1.0"
+        "api-version": "1.3"
       },
       "projects": [
         {"name": "Frob"},
@@ -509,13 +513,17 @@ Each individual file dictionary has the following keys:
   associated provenance, with the same rules as ``data-provenance`` in the
   :ref:`base HTML API specification `.
 
+  .. note::
+
+    The ``provenance`` field was added with API version 1.3.
+
 As an example:
 
 .. code-block:: json
 
     {
       "meta": {
-        "api-version": "1.0"
+        "api-version": "1.3"
       },
       "name": "holygrail",
       "files": [

From 620404673b387f45be3c4ab51720ec21bcda6671 Mon Sep 17 00:00:00 2001
From: Russell Keith-Magee 
Date: Wed, 5 Feb 2025 09:46:06 +0800
Subject: [PATCH 0900/1072] Document iOS, Android and macOS platform tag
 schemes.

---
 .../platform-compatibility-tags.rst           | 67 +++++++++++++++++--
 1 file changed, 63 insertions(+), 4 deletions(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 3679cf4ad..08ea9e4ce 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -109,8 +109,8 @@ subset of Linux platforms, and allows building wheels tagged with the
 ``manylinux`` platform tag which can be used across most common Linux
 distributions.
 
-The current standard is the future-proof ``manylinux_x_y`` standard. It defines
-tags of the form ``manylinux_x_y_arch``, where ``x`` and ``y`` are glibc major
+The current standard is the future-proof ``manylinux__`` standard. It defines
+tags of the form ``manylinux___``, where ``x`` and ``y`` are glibc major
 and minor versions supported (e.g. ``manylinux_2_24_xxx`` should work on any
 distro using glibc 2.24+), and ``arch`` is the architecture, matching the value
 of :py:func:`sysconfig.get_platform()` on the system as in the "simple" form above.
@@ -151,7 +151,7 @@ auditwheel  ``>=1.0.0``     ``>=2.0.0``        ``>=3.0.0``        ``>=3.3.0`` [#
 
 The ``musllinux`` family of tags is similar to ``manylinux``, but for Linux
 platforms that use the musl_ libc rather than glibc (a prime example being Alpine
-Linux). The schema is ``musllinux_x_y_arch``, supporting musl ``x.y`` and higher
+Linux). The schema is ``musllinux___``, supporting musl ``x.y`` and higher
 on the architecture ``arch``.
 
 The musl version values can be obtained by executing the musl libc shared
@@ -189,6 +189,64 @@ There are currently two possible ways to find the musl library’s location that
 Python interpreter is running on, either with the system ldd_ command, or by
 parsing the ``PT_INTERP`` section’s value from the executable’s ELF_ header.
 
+.. _macos:
+
+macOS
+-----
+
+macOS uses the ``macosx`` family of tags (the ``x`` suffix is a historical
+artefact of Apple's official macOS naming scheme). The schema for compatibility
+tags is ``macosx___``, indicating that the wheel is compatible with
+macOS ``x.y`` or later on the architecture ``arch``. The version number always
+includes a major and minor version, even if Apple's official version numbering
+only refers to the major value. For example, a ``macosx_11_0_arm64`` indicates
+compatibility with macOS 11 or later, on arm64 (i.e., Apple Silicon) hardware.
+
+Recent macOS binaries distributed on Python.org are compiled with a minimum
+macOS compatibility version of 11.0, as macOS 11 (Big Sur) was the first release
+to support the ARM64 Apple Silicon architecture. Python binaries obtained from
+other sources may have a different compatibility version.
+
+macOS also supports the use of a combined, or "fat" architecture specification.
+For example, specifying an architecture of ``universal2`` indicates that
+binaries support *both* x86_64 *and* arm64.
+
+.. _android:
+
+android
+-------
+
+Android uses the schema ``android__``, indicating compatibility with
+Android SDK ``sdk`` or later, on the architecture ``arch``. Android makes no
+distinction between physical devices and emulated devices.
+
+Note that this tag schema uses the *SDK* version, not the Android OS version
+number. The Android release known publicly as Android 12 (code named "Snow
+Cone") uses SDK 31 or 32, depending on the specific Android version in use.
+Android's release documentation contains the `full list of Android versions and
+their corresponding SDK versions
+`__.
+
+By default, Python 3.13 is compiled using SDK 24 (i.e, Android 7); Python 3.14
+uses SDK 27 (i.e, Android 8.1).
+
+.. _ios:
+
+iOS
+---
+
+iOS uses the schema ``ios____``, indicating compatibility with
+iOS ``x.y`` or later, on the ``arch`` architecture, using the ``sdk`` SDK. The
+version number always includes a major and minor version, even if Apple's
+official version numbering only refers to the major value.
+
+The iOS platform has two SDKs: ``iphoneos`` for physical devices; and
+``iphonesimulator`` for simulated devices. These SDKs have the same API surface,
+but are incompatible at the binary level, even if they are running on the same
+architecture. Code compiled for an arm64 simulator will not run on an arm64
+device.
+
+By default, Python is compiled with a minimum iOS compatibility version of 13.0.
 
 Use
 ===
@@ -339,7 +397,8 @@ History
 - November 2019: The ``manylinux_x_y`` perennial tag was approved through
   :pep:`600`.
 - April 2021: The ``musllinux_x_y`` tag was approved through :pep:`656`.
-
+- December 2023: The tags for iOS were approved through :pep:`730`.
+- March 2024: The tags for Android were approved through :pep:`738`.
 
 
 .. _musl: https://musl.libc.org

From 0347e3f8c3b58f06159a52da2364ad1d9e580bca Mon Sep 17 00:00:00 2001
From: Russell Keith-Magee 
Date: Wed, 5 Feb 2025 11:27:17 +0800
Subject: [PATCH 0901/1072] Add explicit details about supported architectures.

---
 source/specifications/platform-compatibility-tags.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 08ea9e4ce..6146aa86f 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -227,6 +227,12 @@ Android's release documentation contains the `full list of Android versions and
 their corresponding SDK versions
 `__.
 
+There are 4 supported architectures:
+* ``armeabi_v7a``
+* ``arm64_v8a``
+* ``x86``
+* ``x86_64``
+
 By default, Python 3.13 is compiled using SDK 24 (i.e, Android 7); Python 3.14
 uses SDK 27 (i.e, Android 8.1).
 
@@ -246,6 +252,9 @@ but are incompatible at the binary level, even if they are running on the same
 architecture. Code compiled for an arm64 simulator will not run on an arm64
 device.
 
+The ``iphonesimulator`` SDK supports 2 architectures: ``arm64`` and ``x86_64``.
+The ``iphoneos`` SDK only supports the ``arm64`` architecture.
+
 By default, Python is compiled with a minimum iOS compatibility version of 13.0.
 
 Use

From 4ad0c82ce969deac613ebc67319410c2b5c3a155 Mon Sep 17 00:00:00 2001
From: Russell Keith-Magee 
Date: Wed, 5 Feb 2025 13:44:56 +0800
Subject: [PATCH 0902/1072] Clarified details around macOS version
 compatibility.

---
 source/specifications/platform-compatibility-tags.rst | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 6146aa86f..17c51647f 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -202,15 +202,13 @@ includes a major and minor version, even if Apple's official version numbering
 only refers to the major value. For example, a ``macosx_11_0_arm64`` indicates
 compatibility with macOS 11 or later, on arm64 (i.e., Apple Silicon) hardware.
 
-Recent macOS binaries distributed on Python.org are compiled with a minimum
-macOS compatibility version of 11.0, as macOS 11 (Big Sur) was the first release
-to support the ARM64 Apple Silicon architecture. Python binaries obtained from
-other sources may have a different compatibility version.
-
 macOS also supports the use of a combined, or "fat" architecture specification.
 For example, specifying an architecture of ``universal2`` indicates that
 binaries support *both* x86_64 *and* arm64.
 
+The minimum supported macOS version may also be constrained by architecture. For
+example, macOS 11 (Big Sur) was the first release to support arm64.
+
 .. _android:
 
 android

From ac29cb8f701ee37568b9b457c37a9ce7a10867f2 Mon Sep 17 00:00:00 2001
From: Russell Keith-Magee 
Date: Wed, 5 Feb 2025 13:59:50 +0800
Subject: [PATCH 0903/1072] Additional note about macOS architecture
 constraints.

---
 source/specifications/platform-compatibility-tags.rst | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 17c51647f..6a25fa6ab 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -207,7 +207,9 @@ For example, specifying an architecture of ``universal2`` indicates that
 binaries support *both* x86_64 *and* arm64.
 
 The minimum supported macOS version may also be constrained by architecture. For
-example, macOS 11 (Big Sur) was the first release to support arm64.
+example, macOS 11 (Big Sur) was the first release to support arm64. These
+additional constraints are enforced transparently by the macOS compilation
+toolchain when building a ``universal2`` binary.
 
 .. _android:
 

From 70698ad90b058a9d02494b46a6e685ce1cb65378 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Filipe=20La=C3=ADns?= 
Date: Wed, 5 Feb 2025 16:28:19 +0000
Subject: [PATCH 0904/1072] specifications: add build-details.json (PEP 739)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Filipe Laíns 
---
 .github/CODEOWNERS                            |   4 +
 requirements.txt                              |   1 +
 source/conf.py                                |   2 +
 .../examples/build-details-v1.0.json          |  51 ++++
 source/specifications/build-details/index.rst |  52 ++++
 source/specifications/build-details/v1.0.rst  |  18 ++
 source/specifications/index.rst               |   1 +
 .../schemas/build-details-v1.0.schema.json    | 261 ++++++++++++++++++
 .../section-python-description-formats.rst    |   8 +
 9 files changed, 398 insertions(+)
 create mode 100644 source/specifications/build-details/examples/build-details-v1.0.json
 create mode 100644 source/specifications/build-details/index.rst
 create mode 100644 source/specifications/build-details/v1.0.rst
 create mode 100644 source/specifications/schemas/build-details-v1.0.schema.json
 create mode 100644 source/specifications/section-python-description-formats.rst

diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
index 2d3e69fe8..ecd85064f 100644
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@@ -1,2 +1,6 @@
 source/guides/github-actions-ci-cd-sample/* @webknjaz
 source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @webknjaz
+
+# build-details.json
+source/specifications/build-details/ @FFY00
+source/specifications/specs/build-details-*.json @FFY00
diff --git a/requirements.txt b/requirements.txt
index a3269a025..5c710c86b 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -4,3 +4,4 @@ sphinx-autobuild==2021.3.14
 sphinx-inline-tabs==2023.4.21
 sphinx-copybutton==0.5.2
 sphinx-toolbox==3.5.0
+sphinx-jsonschema==1.19.1
diff --git a/source/conf.py b/source/conf.py
index c73dabdf2..317c89dbf 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -28,6 +28,7 @@
     "sphinx_inline_tabs",
     "sphinx_copybutton",
     "sphinx_toolbox.collapse",
+    "sphinx-jsonschema",
 ]
 
 nitpicky = True
@@ -128,6 +129,7 @@
 
 linkcheck_ignore = [
     "http://localhost:\\d+",
+    "https://packaging.python.org/en/latest/specifications/schemas/*",
     "https://test.pypi.org/project/example-package-YOUR-USERNAME-HERE",
     "https://pypi.org/manage/*",
     "https://test.pypi.org/manage/*",
diff --git a/source/specifications/build-details/examples/build-details-v1.0.json b/source/specifications/build-details/examples/build-details-v1.0.json
new file mode 100644
index 000000000..dd08b230f
--- /dev/null
+++ b/source/specifications/build-details/examples/build-details-v1.0.json
@@ -0,0 +1,51 @@
+{
+  "schema_version": "1.0",
+  "base_prefix": "/usr",
+  "base_interpreter": "/usr/bin/python",
+  "platform": "linux-x86_64",
+  "language": {
+    "version": "3.14",
+    "version_info": {
+      "major": 3,
+      "minor": 14,
+      "micro": 0,
+      "releaselevel": "alpha",
+      "serial": 0
+    }
+  },
+  "implementation": {
+    "name": "cpython",
+    "version": {
+      "major": 3,
+      "minor": 14,
+      "micro": 0,
+      "releaselevel": "alpha",
+      "serial": 0
+    },
+    "hexversion": 51249312,
+    "cache_tag": "cpython-314",
+    "_multiarch": "x86_64-linux-gnu"
+  },
+  "abi": {
+    "flags": ["t", "d"],
+    "extension_suffix": ".cpython-314-x86_64-linux-gnu.so",
+    "stable_abi_suffix": ".abi3.so"
+  },
+  "suffixes": {
+    "source": [".py"],
+    "bytecode": [".pyc"],
+    "optimized_bytecode": [".pyc"],
+    "debug_bytecode": [".pyc"],
+    "extensions": [".cpython-314-x86_64-linux-gnu.so", ".abi3.so", ".so"]
+  },
+  "libpython": {
+    "dynamic": "/usr/lib/libpython3.14.so.1.0",
+    "dynamic_stableabi": "/usr/lib/libpython3.so",
+    "static": "/usr/lib/python3.14/config-3.14-x86_64-linux-gnu/libpython3.14.a",
+    "link_extensions": true
+  },
+  "c_api": {
+    "headers": "/usr/include/python3.14",
+    "pkgconfig_path": "/usr/lib/pkgconfig"
+  }
+}
diff --git a/source/specifications/build-details/index.rst b/source/specifications/build-details/index.rst
new file mode 100644
index 000000000..bda4e0ba4
--- /dev/null
+++ b/source/specifications/build-details/index.rst
@@ -0,0 +1,52 @@
+.. _build-details:
+
+======================
+``build-details.json``
+======================
+
+.. toctree::
+   :hidden:
+
+   v1.0 
+
+
+The ``build-details.json`` file is a standardized file format that provides
+build-specfic information of a Python installation, such as its version,
+extension ABI details, and other information that is specific to that particular
+build of Python.
+
+Starting from Python 3.14, a ``build-details.json`` file is installed in the
+platform-independent standard library directory (``stdlib``, eg.
+``/usr/lib/python3.14/build-details.json``).
+
+Please refer to the :ref:`latest version ` for its
+specification.
+
+..
+   Update to point to the latest version!
+
+.. literalinclude:: examples/build-details-v1.0.json
+   :caption: Example
+   :language: json
+   :linenos:
+
+
+Changelog
+---------
+
+..
+   Order in decreasing order.
+
+v1.0
+~~~~
+
+.. list-table::
+
+    * - Specification
+      - :ref:`build-details-v1.0`
+
+    * - Schema
+      - https://packaging.python.org/en/latest/specifications/schemas/python-build-info-v1.0.schema.json
+
+
+- Initial version, introduced by :pep:`739`.
diff --git a/source/specifications/build-details/v1.0.rst b/source/specifications/build-details/v1.0.rst
new file mode 100644
index 000000000..cfe902e1e
--- /dev/null
+++ b/source/specifications/build-details/v1.0.rst
@@ -0,0 +1,18 @@
+.. _build-details-v1.0:
+
+===========================
+``build-details.json`` v1.0
+===========================
+
+
+Specification
+-------------
+
+.. jsonschema:: ../schemas/build-details-v1.0.schema.json
+    :lift_title: false
+
+
+Example
+-------
+
+.. literalinclude:: examples/build-details-v1.0.json
diff --git a/source/specifications/index.rst b/source/specifications/index.rst
index c8d2a3bed..c69605927 100644
--- a/source/specifications/index.rst
+++ b/source/specifications/index.rst
@@ -15,3 +15,4 @@ and for proposing new ones, is documented on
    section-installation-metadata
    section-distribution-formats
    section-package-indices
+   section-python-description-formats
diff --git a/source/specifications/schemas/build-details-v1.0.schema.json b/source/specifications/schemas/build-details-v1.0.schema.json
new file mode 100644
index 000000000..b088431b5
--- /dev/null
+++ b/source/specifications/schemas/build-details-v1.0.schema.json
@@ -0,0 +1,261 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://packaging.python.org/en/latest/specifications/schemas/python-build-info-v1.0.schema.json",
+  "type": "object",
+  "title": "build-details.json — a static description file with build details of Python installations",
+  "required": [
+    "schema_version",
+    "base_prefix",
+    "platform",
+    "language",
+    "implementation"
+  ],
+  "additionalProperties": false,
+  "properties": {
+    "schema_version": {
+      "type": "string",
+      "description": "Schema version.\n\nThis is a string following the format ``.``, where ```` and ```` are unpaded numbers and represent the **major** and **minor** components of the version. Versions may be arithmetically compared by intrepreting the version string as a decimal number.\n\nFor this specification version, this value is constant and **MUST** be ``1.0``.\n\nFuture versions of this schema **MUST** use a higher version number. Future versions of this schema **MUST NOT** use the same **major** version component as other schema version unless its specification is deemed backwards-compatible with them — it can't change, or extend, any parts of the current specification in such a way as the semantics of the interpreted data differ, or that data valid under the new specification is invalid under the older specification, with the exception of additional properties (errors caused by ``additionalProperties``).",
+      "const": "1.0"
+    },
+    "base_prefix": {
+      "type": "string",
+      "description": "Base prefix of the Python installation.\n\nEither an absolute path, or a path relative to directory where this file is contained.",
+      "examples": [
+        "/usr",
+        "../.."
+      ]
+    },
+    "base_interpreter": {
+        "type": "string",
+        "description": "The path to the Python interprer of the base installation.\n\nEither an absolute path, or a path relative to ``base_prefix``.\n\nThis field **MUST** be present if the installation provides an interpreter executable.",
+        "examples": [
+          "/usr/bin/python",
+          "bin/python"
+        ]
+    },
+    "platform": {
+      "type": "string",
+      "description": "System platform string.\n\nThis field **SHOULD** be equivalent to ``sysconfig.get_platform()``.",
+      "examples": [
+        "linux-x86_64"
+      ]
+    },
+    "language": {
+      "type": "object",
+      "description": "Object containing details related to the Python language specification.",
+      "required": [
+        "version"
+      ],
+      "additionalProperties": false,
+      "properties": {
+        "version": {
+          "type": "string",
+          "description": "String representation the Python language version — a version string consisting only of the *major* and *minor* components.\n\nThis field **SHOULD** be equivalent to ``sysconfig.get_python_version()``.",
+          "examples": ["3.14"]
+        },
+        "version_info": {
+          "type": "object",
+          "description": "Object in the format of :py:data:`sys.version_info`.\n\nThis section **SHOULD** be equivalent to :py:data:`sys.version_info`.",
+          "required": ["major", "minor", "micro", "releaselevel", "serial"],
+          "additionalProperties": false,
+          "examples": [
+            {
+              "major": 3,
+              "minor": 14,
+              "micro": 1,
+              "releaselevel": "final",
+              "serial": 0
+            }
+          ],
+          "properties": {
+            "major": {
+              "type": "number"
+            },
+            "minor": {
+              "type": "number"
+            },
+            "micro": {
+              "type": "number"
+            },
+            "releaselevel": {
+              "type": "string",
+              "enum": ["alpha", "beta", "candidate", "final"]
+            },
+            "serial": {
+              "type": "number"
+            }
+          }
+        }
+      }
+    },
+    "implementation": {
+      "type": "object",
+      "description": "Object containing details related to Python implementation.\n\nThis section **SHOULD** be equivalent to :py:data:`sys.implementation`. It follows specification defined in PEP 421, meaning that on top of the required keys, implementation-specific keys can also exist, but must be prefixed with an underscore.",
+      "required": [
+        "name",
+        "version",
+        "hexversion",
+        "cache_tag"
+      ],
+      "additionalProperties": true,
+      "properties": {
+        "name": {
+          "type": "string",
+          "description": "Lower-case name of the Python implementation.",
+          "examples": ["cpython", "pypy"]
+        },
+        "version": {
+          "type": "object",
+          "description": "Object in the format of :py:data:`sys.version_info`, containing the implementation version.",
+          "required": ["major", "minor", "micro", "releaselevel", "serial"],
+          "additionalProperties": false,
+          "examples": [
+            {
+              "major": 3,
+              "minor": 14,
+              "micro": 1,
+              "releaselevel": "final",
+              "serial": 0
+            },
+            {
+              "major": 7,
+              "minor": 3,
+              "micro": 16,
+              "releaselevel": "final",
+              "serial": 0
+            }
+          ],
+          "properties": {
+            "major": {
+              "type": "number"
+            },
+            "minor": {
+              "type": "number"
+            },
+            "micro": {
+              "type": "number"
+            },
+            "releaselevel": {
+              "type": "string",
+              "enum": ["alpha", "beta", "candidate", "final"]
+            },
+            "serial": {
+              "type": "number"
+            }
+          }
+        }
+      }
+    },
+    "abi": {
+      "type": "object",
+      "description": "Object containing details related to ABI.",
+      "required": [
+        "flags"
+      ],
+      "additionalProperties": false,
+      "properties": {
+        "flags": {
+          "type": "array",
+          "description": "Build configuration flags, used to calculate the extension suffix.\n\nThe flags **MUST** be defined in the order they appear on the extension suffix.",
+          "additionalProperties": true,
+          "examples": [
+            ["t", "d"]
+          ]
+        },
+        "extension_suffix": {
+          "type": "string",
+          "description": "Suffix used for extensions built against the current implementation version.\n\nThis field **MUST** be present if the Python implementation supports extensions, otherwise this entry will be missing.",
+          "examples": [
+            ".cpython-314-x86_64-linux-gnu.so"
+          ]
+        },
+        "stable_abi_suffix": {
+          "type": "string",
+          "description": "Suffix used for extensions built against the stable ABI.\n\nThis field **MUST** be present if the Python implementation has a stable ABI extension suffix, otherwise this entry will be missing.",
+          "examples": [
+            ".abi3.so"
+          ]
+        }
+      }
+    },
+    "suffixes": {
+      "type": "object",
+      "description": "Valid module suffixes grouped by type.\n\nThis section **MUST** be present if the Python installation supports importing external files, and it **SHOULD** be equivalent to the ``importlib.machinery.*_SUFFIXES`` attributes.\n\nAdditionally, if a Python implementation provides extension kinds other than the ones listed on ``importlib.machinery`` module, they **MAY** add a sub-section for them.",
+      "examples": [
+        {
+          "source": [".py"],
+          "bytecode": [".pyc"],
+          "optimized_bytecode": [".pyc"],
+          "debug_bytecode": [".pyc"],
+          "extensions": [".cpython-313-x86_64-linux-gnu.so", ".abi3.so", ".so"]
+        }
+      ]
+    },
+    "libpython": {
+      "type": "object",
+      "description": "Object containing details related to the ``libpython`` library.\n\nThis section **MUST** by present if Python installation provides a ``libpython`` library, otherwise this section will be missing.",
+      "additionalProperties": false,
+      "properties": {
+        "dynamic": {
+          "type": "string",
+          "description": "The path to the dynamic ``libpython`` library.\n\nEither an absolute path, or a path relative to ``base_prefix``.\n\nThis field **MUST** be present if the Python installation provides a dynamic ``libpython`` library, otherwise this entry will be missing.",
+          "examples": [
+            "/usr/lib/libpython3.14.so.1.0",
+            "lib/libpython3.14.so.1.0"
+          ]
+        },
+        "dynamic_stableabi": {
+          "type": "string",
+          "description": "The path to the dynamic ``libpython`` library for the stable ABI.\n\nEither an absolute path, or a path relative to ``base_prefix``.\n\nThis field **MUST** be present if the Python installation provides a dynamic ``libpython`` library targeting the Stable ABI, otherwise this entry will be missing.\n\nIf this key is present ``dynamic`` **MUST** also be set.",
+          "examples": [
+            "/usr/lib/libpython3.so",
+            "lib/libpython3.so"
+          ]
+        },
+        "static": {
+          "type": "string",
+          "description": "The path to the static ``libpython`` library.\n\nEither an absolute path, or a path relative to ``base_prefix``.\n\nThis field **MUST** be present if the Python installation provides a static ``libpython`` library, otherwise this entry will be missing.",
+          "examples": [
+            "/usr/lib/python3.14/config-3.14-x86_64-linux-gnu/libpython3.14.a",
+            "lib/python3.14/config-3.14-x86_64-linux-gnu/libpython3.14.a"
+          ]
+        },
+        "link_extensions": {
+          "type": "boolean",
+          "description": "Should extensions built against a dynamic ``libpython`` link to it?\n\nThis field **MUST** be present if the Python installation provides a dynamic ``libpython`` library, otherwise this entry will be missing."
+        }
+      }
+    },
+    "c_api": {
+      "type": "object",
+      "description": "Object containing details related to the Python C API.\n\nThis section **MUST** be present if the Python implementation provides a C API, otherwise this section will be missing.",
+      "required": [
+        "headers"
+      ],
+      "additionalProperties": false,
+      "properties": {
+        "headers": {
+          "type": "string",
+          "description": "The path to the C API headers.\n\nEither an absolute path, or a path relative to ``base_prefix``.",
+          "examples": [
+            "/usr/include/python3.14",
+            "include/python3.14"
+          ]
+        },
+        "pkgconfig_path": {
+          "type": "string",
+          "description": "The path to the pkg-config definition files.\n\nEither an absolute path, or a path relative to ``base_prefix``.\n\nThis field **MUST** be present if the Python implementation provides pkg-config definition files, otherwise this section will be missing.",
+          "examples": [
+            "/usr/lib/pkgconfig",
+            "lib/pkgconfig"
+          ]
+        }
+      }
+    },
+    "arbitrary_data": {
+      "type": "object",
+      "description": "Object containing extra arbitrary data.\n\nThis is meant to be used as an escape-hatch, to include any relevant data that is not covered by this specification. Implementations may choose what data to provide in this section.",
+      "additionalProperties": true
+    }
+  }
+}
diff --git a/source/specifications/section-python-description-formats.rst b/source/specifications/section-python-description-formats.rst
new file mode 100644
index 000000000..5a56c3968
--- /dev/null
+++ b/source/specifications/section-python-description-formats.rst
@@ -0,0 +1,8 @@
+==========================
+Python Description Formats
+==========================
+
+.. toctree::
+   :titlesonly:
+
+   build-details/index

From 8e89d1553e55959ee9e403eb2b3f23a8eca7adeb Mon Sep 17 00:00:00 2001
From: Russell Keith-Magee 
Date: Thu, 6 Feb 2025 08:27:58 +0800
Subject: [PATCH 0905/1072] Clarify the Android schema definition

Co-authored-by: Malcolm Smith 
---
 .../platform-compatibility-tags.rst              | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 6a25fa6ab..2415f03de 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -216,18 +216,20 @@ toolchain when building a ``universal2`` binary.
 android
 -------
 
-Android uses the schema ``android__``, indicating compatibility with
-Android SDK ``sdk`` or later, on the architecture ``arch``. Android makes no
+Android uses the schema ``android__``, indicating compatibility
+with the given Android API level or later, on the given ABI. Android makes no
 distinction between physical devices and emulated devices.
 
-Note that this tag schema uses the *SDK* version, not the Android OS version
-number. The Android release known publicly as Android 12 (code named "Snow
-Cone") uses SDK 31 or 32, depending on the specific Android version in use.
+Note that this tag schema uses the API level, which is a positive integer, not
+the user-facing Android version. The release known as Android 12 (code named "Snow
+Cone") uses API level 31 or 32, depending on the specific Android version in use.
 Android's release documentation contains the `full list of Android versions and
-their corresponding SDK versions
+their corresponding API levels
 `__.
 
-There are 4 supported architectures:
+There are 4 `supported ABIs `__. 
+Normalized according to the rules above, they are:
+
 * ``armeabi_v7a``
 * ``arm64_v8a``
 * ``x86``

From 84010c1fc70058e130bddb29a34654b9ca157b12 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Thu, 6 Feb 2025 00:28:05 +0000
Subject: [PATCH 0906/1072] [pre-commit.ci] auto fixes from pre-commit.com
 hooks

for more information, see https://pre-commit.ci
---
 source/specifications/platform-compatibility-tags.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 2415f03de..f67c29c5e 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -227,7 +227,7 @@ Android's release documentation contains the `full list of Android versions and
 their corresponding API levels
 `__.
 
-There are 4 `supported ABIs `__. 
+There are 4 `supported ABIs `__.
 Normalized according to the rules above, they are:
 
 * ``armeabi_v7a``

From 608a6bbb69afe74d9637a96725aa908dac281117 Mon Sep 17 00:00:00 2001
From: Russell Keith-Magee 
Date: Thu, 6 Feb 2025 07:55:57 +0800
Subject: [PATCH 0907/1072] Use the file role for tags to allow for variable
 markup.

---
 source/specifications/platform-compatibility-tags.rst | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index f67c29c5e..5487cc796 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -109,8 +109,8 @@ subset of Linux platforms, and allows building wheels tagged with the
 ``manylinux`` platform tag which can be used across most common Linux
 distributions.
 
-The current standard is the future-proof ``manylinux__`` standard. It defines
-tags of the form ``manylinux___``, where ``x`` and ``y`` are glibc major
+The current standard is the future-proof :file:`manylinux_{x}_{y}` standard. It defines
+tags of the form :file:`manylinux_{x}_{y}_{arch}`, where ``x`` and ``y`` are glibc major
 and minor versions supported (e.g. ``manylinux_2_24_xxx`` should work on any
 distro using glibc 2.24+), and ``arch`` is the architecture, matching the value
 of :py:func:`sysconfig.get_platform()` on the system as in the "simple" form above.
@@ -151,7 +151,7 @@ auditwheel  ``>=1.0.0``     ``>=2.0.0``        ``>=3.0.0``        ``>=3.3.0`` [#
 
 The ``musllinux`` family of tags is similar to ``manylinux``, but for Linux
 platforms that use the musl_ libc rather than glibc (a prime example being Alpine
-Linux). The schema is ``musllinux___``, supporting musl ``x.y`` and higher
+Linux). The schema is :file:`musllinux_{x}_{y}_{arch}``, supporting musl ``x.y`` and higher
 on the architecture ``arch``.
 
 The musl version values can be obtained by executing the musl libc shared
@@ -196,7 +196,7 @@ macOS
 
 macOS uses the ``macosx`` family of tags (the ``x`` suffix is a historical
 artefact of Apple's official macOS naming scheme). The schema for compatibility
-tags is ``macosx___``, indicating that the wheel is compatible with
+tags is :file:`macosx_{x}_{y}_{arch}``, indicating that the wheel is compatible with
 macOS ``x.y`` or later on the architecture ``arch``. The version number always
 includes a major and minor version, even if Apple's official version numbering
 only refers to the major value. For example, a ``macosx_11_0_arm64`` indicates
@@ -243,7 +243,7 @@ uses SDK 27 (i.e, Android 8.1).
 iOS
 ---
 
-iOS uses the schema ``ios____``, indicating compatibility with
+iOS uses the schema :file:`ios_{x}_{y}_{arch}_{sdk}`, indicating compatibility with
 iOS ``x.y`` or later, on the ``arch`` architecture, using the ``sdk`` SDK. The
 version number always includes a major and minor version, even if Apple's
 official version numbering only refers to the major value.

From 77ab2013751c8de1941e47706590fc9ac2fedb0f Mon Sep 17 00:00:00 2001
From: Russell Keith-Magee 
Date: Thu, 6 Feb 2025 08:40:17 +0800
Subject: [PATCH 0908/1072] Clarify macOS version number and arch
 specifications.

---
 .../platform-compatibility-tags.rst           | 38 ++++++++++++++-----
 1 file changed, 28 insertions(+), 10 deletions(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 5487cc796..82f491487 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -196,20 +196,38 @@ macOS
 
 macOS uses the ``macosx`` family of tags (the ``x`` suffix is a historical
 artefact of Apple's official macOS naming scheme). The schema for compatibility
-tags is :file:`macosx_{x}_{y}_{arch}``, indicating that the wheel is compatible with
-macOS ``x.y`` or later on the architecture ``arch``. The version number always
-includes a major and minor version, even if Apple's official version numbering
-only refers to the major value. For example, a ``macosx_11_0_arm64`` indicates
-compatibility with macOS 11 or later, on arm64 (i.e., Apple Silicon) hardware.
-
-macOS also supports the use of a combined, or "fat" architecture specification.
-For example, specifying an architecture of ``universal2`` indicates that
-binaries support *both* x86_64 *and* arm64.
+tags is :file:`macosx_{x}_{y}_{arch}``, indicating that the wheel is compatible
+with macOS ``x.y`` or later on the architecture ``arch``.
+
+The value of ``x`` and ``y`` correspond to the major and minor version number of
+the macOS release, respectively. They must both be positive integers, with the
+``x`` value being ``>= 10``. The version number always includes a major *and*
+minor version, even if Apple's official version numbering only refers to
+the major value. For example, a ``macosx_11_0_arm64`` indicates compatibility
+with macOS 11 or later.
+
+macOS binaries can be compiled for a single architecture, or can include support
+for multiple architectures in the same binary (sometimes called "fat" binaries).
+To indicate support for a single architecture, the value of ``arch`` must match
+the value of :py:func:`sysconfig.get_platform()` on the system. To indicate
+support multiple architectures, the ``arch`` tag should be an identifier from
+the following list that describes the set of supported architectures:
+
+============== ========================================
+``arch``       Architectures supported
+============== ========================================
+``universal2`` ``arm64``, ``x86-64``
+``universal``  ``ppc64``, ``i386``, ``x86-64``
+``intel``      ``i386``, ``x86-64``
+``fat``        ``ppc``, ``ppc64``, ``i386``, ``x86-64``
+``fat32``      ``ppc``, ``i386``
+``fat64``      ``ppc64``, ``x86-64``
+============== ========================================
 
 The minimum supported macOS version may also be constrained by architecture. For
 example, macOS 11 (Big Sur) was the first release to support arm64. These
 additional constraints are enforced transparently by the macOS compilation
-toolchain when building a ``universal2`` binary.
+toolchain when building binaries that support multiple architectures.
 
 .. _android:
 

From 37625a372720a92a692a0294c177896209ab662f Mon Sep 17 00:00:00 2001
From: Russell Keith-Magee 
Date: Thu, 6 Feb 2025 08:44:51 +0800
Subject: [PATCH 0909/1072] Clarify the Android specification.

---
 .../platform-compatibility-tags.rst           | 20 ++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 82f491487..4b18cc7c3 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -231,18 +231,18 @@ toolchain when building binaries that support multiple architectures.
 
 .. _android:
 
-android
+Android
 -------
 
-Android uses the schema ``android__``, indicating compatibility
+Android uses the schema :file:`android_{api_level}_{abi}`, indicating compatibility
 with the given Android API level or later, on the given ABI. Android makes no
 distinction between physical devices and emulated devices.
 
-Note that this tag schema uses the API level, which is a positive integer, not
-the user-facing Android version. The release known as Android 12 (code named "Snow
-Cone") uses API level 31 or 32, depending on the specific Android version in use.
-Android's release documentation contains the `full list of Android versions and
-their corresponding API levels
+The API level should be a positive integer. Note that this value is the API
+level, and *not* the user-facing Android version. The release known as Android
+12 (code named "Snow Cone") uses API level 31 or 32, depending on the specific
+Android version in use. Android's release documentation contains the `full list
+of Android versions and their corresponding API levels
 `__.
 
 There are 4 `supported ABIs `__.
@@ -253,8 +253,10 @@ Normalized according to the rules above, they are:
 * ``x86``
 * ``x86_64``
 
-By default, Python 3.13 is compiled using SDK 24 (i.e, Android 7); Python 3.14
-uses SDK 27 (i.e, Android 8.1).
+Virtually all current physical devices use one of the ARM architectures. ``x86``
+and ``x86_64`` are supported for use in the emulator. ``x86`` has not been
+supported as a development platform since 2020, and no new emulator images have
+been released since then.
 
 .. _ios:
 

From 1f36a155264cd2e9322d4b99ce8ebd0fae83410f Mon Sep 17 00:00:00 2001
From: Russell Keith-Magee 
Date: Thu, 6 Feb 2025 09:12:23 +0800
Subject: [PATCH 0910/1072] Clarify iOS specification.

---
 .../platform-compatibility-tags.rst           | 49 ++++++++++++-------
 1 file changed, 30 insertions(+), 19 deletions(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 4b18cc7c3..99b7cdffe 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -209,19 +209,19 @@ with macOS 11 or later.
 macOS binaries can be compiled for a single architecture, or can include support
 for multiple architectures in the same binary (sometimes called "fat" binaries).
 To indicate support for a single architecture, the value of ``arch`` must match
-the value of :py:func:`sysconfig.get_platform()` on the system. To indicate
+the value of :py:func:`platform.machine()` on the system. To indicate
 support multiple architectures, the ``arch`` tag should be an identifier from
 the following list that describes the set of supported architectures:
 
 ============== ========================================
 ``arch``       Architectures supported
 ============== ========================================
-``universal2`` ``arm64``, ``x86-64``
-``universal``  ``ppc64``, ``i386``, ``x86-64``
-``intel``      ``i386``, ``x86-64``
-``fat``        ``ppc``, ``ppc64``, ``i386``, ``x86-64``
+``universal2`` ``arm64``, ``x86_64``
+``universal``  ``ppc64``, ``i386``, ``x86_64``
+``intel``      ``i386``, ``x86_64``
+``fat``        ``ppc``, ``ppc64``, ``i386``, ``x86_64``
 ``fat32``      ``ppc``, ``i386``
-``fat64``      ``ppc64``, ``x86-64``
+``fat64``      ``ppc64``, ``x86_64``
 ============== ========================================
 
 The minimum supported macOS version may also be constrained by architecture. For
@@ -264,20 +264,31 @@ iOS
 ---
 
 iOS uses the schema :file:`ios_{x}_{y}_{arch}_{sdk}`, indicating compatibility with
-iOS ``x.y`` or later, on the ``arch`` architecture, using the ``sdk`` SDK. The
-version number always includes a major and minor version, even if Apple's
-official version numbering only refers to the major value.
+iOS ``x.y`` or later, on the ``arch`` architecture, using the ``sdk`` SDK.
 
-The iOS platform has two SDKs: ``iphoneos`` for physical devices; and
-``iphonesimulator`` for simulated devices. These SDKs have the same API surface,
-but are incompatible at the binary level, even if they are running on the same
-architecture. Code compiled for an arm64 simulator will not run on an arm64
-device.
-
-The ``iphonesimulator`` SDK supports 2 architectures: ``arm64`` and ``x86_64``.
-The ``iphoneos`` SDK only supports the ``arm64`` architecture.
-
-By default, Python is compiled with a minimum iOS compatibility version of 13.0.
+The value of ``x`` and ``y`` correspond to the major and minor version number of
+the iOS release, respectively. They must both be positive integers. The version
+number always includes a major *and* minor version, even if Apple's official
+version numbering only refers to the major value. For example, a
+``ios_13_0_arm64_iphonesimulator`` indicates compatibility with iOS 13 or later.
+
+The value of ``arch`` must match the value of :py:func:`platform.machine()` on
+the system.
+
+The value of ``sdk`` must be either ``iphoneos`` (for physical devices), or
+``iphonesimulator`` (for device simulators). These SDKs have the same API
+surface, but are incompatible at the binary level, even if they are running on
+the same CPU architecture. Code compiled for an arm64 simulator will not run on
+an arm64 device.
+
+The combination of :file:`{arch}_{sdk}` is referred to as the "multiarch". There
+are three possible values for multiarch:
+
+* ``arm64_iphoneos``, for physical iPhone/iPad devices. This includes every
+  iOS device manufactured since ~2015;
+* ``arm64_iphonesimulator``, for simulators running on Apple Silicon macOS
+  hardware; and
+* ``x86_64_iphonesimulator``, for simulators running on x86_64 hardware.
 
 Use
 ===

From 90638f828194d1fbc2dd251850078f738be21de1 Mon Sep 17 00:00:00 2001
From: Russell Keith-Magee 
Date: Thu, 6 Feb 2025 12:10:40 +0800
Subject: [PATCH 0911/1072] Update macOS tag table to use canonical values.

---
 source/specifications/platform-compatibility-tags.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 99b7cdffe..8c4697d27 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -217,10 +217,10 @@ the following list that describes the set of supported architectures:
 ``arch``       Architectures supported
 ============== ========================================
 ``universal2`` ``arm64``, ``x86_64``
-``universal``  ``ppc64``, ``i386``, ``x86_64``
+``universal``  ``i386``, ``ppc``, ``ppc64``, ``x86_64``
 ``intel``      ``i386``, ``x86_64``
-``fat``        ``ppc``, ``ppc64``, ``i386``, ``x86_64``
-``fat32``      ``ppc``, ``i386``
+``fat``        ``i386``, ``ppc``
+``fat3``       ``i386``, ``ppc``, ``x86_64``
 ``fat64``      ``ppc64``, ``x86_64``
 ============== ========================================
 

From caf1140041f66daaaaf00fde118dbad7cbf36fc2 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Thu, 6 Feb 2025 14:03:18 -0500
Subject: [PATCH 0912/1072] simple-repository-api: clean up, add API history

Signed-off-by: William Woodruff 
---
 .../specifications/simple-repository-api.rst  | 151 +++++++++---------
 1 file changed, 79 insertions(+), 72 deletions(-)

diff --git a/source/specifications/simple-repository-api.rst b/source/specifications/simple-repository-api.rst
index a96e4e7a8..e05e3854a 100644
--- a/source/specifications/simple-repository-api.rst
+++ b/source/specifications/simple-repository-api.rst
@@ -5,6 +5,11 @@
 Simple repository API
 =====================
 
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`2119`.
+
 The interface for querying available package versions and
 retrieving packages from an index server comes in two forms:
 HTML and JSON.
@@ -28,7 +33,9 @@ Within a repository, the root URL (``/`` for this spec which represents the base
 URL) **MUST** be a valid HTML5 page with a single anchor element per project in
 the repository. The text of the anchor tag **MUST** be the name of
 the project and the href attribute **MUST** link to the URL for that particular
-project. As an example::
+project. As an example:
+
+.. code-block:: html
 
    
    
@@ -89,7 +96,9 @@ In addition to the above, the following constraints are placed on the API:
   link. This exposes the :ref:`core-metadata-requires-python` metadata field
   for the corresponding release. Where this is present, installer tools
   **SHOULD** ignore the download when installing to a Python version that
-  doesn't satisfy the requirement. For example::
+  doesn't satisfy the requirement. For example:
+
+  .. code-block:: html
 
       ...
 
@@ -209,13 +218,15 @@ Versioning PyPI's Simple API
 
 This spec proposes the inclusion of a meta tag on the responses of every
 successful request to a simple API page, which contains a name attribute
-of "pypi:repository-version", and a content that is a :ref:`version specifiers
+of ``pypi:repository-version``, and a content that is a :ref:`version specifiers
 specification ` compatible
 version number, which is further constrained to ONLY be Major.Minor, and
 none of the additional features supported by :ref:`the version specifiers
 specification `.
 
-This would end up looking like::
+This would end up looking like:
+
+.. code-block:: html
 
   
 
@@ -241,10 +252,18 @@ is included to disambiguate with future versions (e.g. a hypothetical
 simple api v2 that lived at /v2/, but which would be confusing if the
 repository-version was set to a version >= 2).
 
-This spec sets the current API version to "1.0", and expects that
-future specs that further evolve the simple API will increment the
-minor version number.
+API Version History
+-------------------
+
+This section contains only an abbreviated history of changes,
+as marked by the API version number. For a full history of changes including
+changes made before API versioning, see :ref:`History `.
 
+- API version 1.0: Initial version of the API, declared with :pep:`629`.
+- API version 1.1: Added ``versions``, ``files[].size``, and ``files[].upload-time`` metadata
+  to the JSON serialization, declared with :pep:`700`.
+- API version 1.2: Added repository "tracks" metadata, declared with :pep:`708`.
+- API version 1.3: Added provenance metadata, declared with :pep:`740`.
 
 Clients
 -------
@@ -393,6 +412,8 @@ spec:
 * All requirements of :ref:`the base HTML API specification
   ` that are not HTML specific still apply.
 
+* Keys (at any level) with a leading underscore are reserved as private for
+  index server use. No future standard will assign a meaning to any such key.
 
 Project List
 ~~~~~~~~~~~~
@@ -446,11 +467,34 @@ The format of this URL is ``//`` where the ```` is replaced by
 name for that project, so a project named "Silly_Walk" would
 have a URL like ``/silly-walk/``.
 
-This URL must respond with a JSON encoded dictionary that has three keys:
+This URL must respond with a JSON encoded dictionary that has four keys:
 
 - ``name``: The normalized name of the project.
 - ``files``: A list of dictionaries, each one representing an individual file.
 - ``meta``: The general response metadata as `described earlier `__.
+- ``versions``: A list of version strings specifying all of the project versions
+  uploaded for this project. The value of ``versions`` is logically a set,
+  and as such may not contain duplicates, and the order of the versions is
+  not significant.
+
+  .. note::
+
+    All of the files listed in the ``files`` key MUST be associated with one of the
+    versions in the ``versions`` key. The ``versions`` key MAY contain versions with
+    no associated files (to represent versions with no files uploaded, if the server
+    has such a concept).
+
+  .. note::
+
+    Because servers may hold "legacy" data from before the adoption of
+    :ref:`the version specifiers specification (VSS) `, version
+    strings currently cannot be required to be valid VSS versions, and therefore
+    cannot be assumed to be orderable using the VSS rules. However, servers **SHOULD**
+    use normalized VSS versions where possible.
+
+  .. note::
+
+    The ``versions`` key was added with API version 1.1.
 
 Each individual file dictionary has the following keys:
 
@@ -508,6 +552,25 @@ Each individual file dictionary has the following keys:
   and is a truthy value, then it **SHOULD** be interpreted as indicating that the
   file pointed to by the ``url`` field has been "Yanked" as per :ref:`the API
   yank specification `.
+- ``size``: A **mandatory** key. It **MUST** contain an integer which is the file size in bytes.
+
+  .. note::
+
+    The ``size`` key was added with API version 1.1.
+
+- ``upload-time``: An **optional** key that, if present, **MUST** contain a valid
+  ISO 8601 date/time string in the format ``yyyy-mm-ddThh:mm:ss.ffffffZ``
+  which represents the time the file was uploaded to the index.
+
+  As indicated by the ``Z`` suffix, the upload time **MUST** use the UTC timezone.
+  The fractional seconds part of the timestamp (the ``.ffffff`` part) is optional,
+  and if present may contain up to 6 digits of precision. If a server does not record
+  upload time information for a file, it **MAY** omit the ``upload-time`` key.
+
+  .. note::
+
+    The ``upload-time`` key was added with API version 1.1.
+
 - ``provenance``: An **optional** key which, if present **MUST** be either a JSON
   string or ``null``. If not ``null``, it **MUST** be a URL to the file's
   associated provenance, with the same rules as ``data-provenance`` in the
@@ -532,7 +595,8 @@ As an example:
           "url": "https://example.com/files/holygrail-1.0.tar.gz",
           "hashes": {"sha256": "...", "blake2b": "..."},
           "requires-python": ">=3.7",
-          "yanked": "Had a vulnerability"
+          "yanked": "Had a vulnerability",
+          "size": 123456
         },
         {
           "filename": "holygrail-1.0-py3-none-any.whl",
@@ -540,9 +604,11 @@ As an example:
           "hashes": {"sha256": "...", "blake2b": "..."},
           "requires-python": ">=3.7",
           "dist-info-metadata": true,
-          "provenance": "https://example.com/files/holygrail-1.0-py3-none-any.whl.provenance"
+          "provenance": "https://example.com/files/holygrail-1.0-py3-none-any.whl.provenance",
+          "size": 1337
         }
-      ]
+      ],
+      "versions": ["1.0"]
     }
 
 
@@ -889,71 +955,10 @@ It is recommended that clients:
 - Check the ``Content-Type`` of the response and ensure it matches something
   that you were expecting.
 
-Additional Fields for the Simple API for Package Indexes
-========================================================
-
-This specification defines version 1.1 of the simple repository API. For the
-HTML version of the API, there is no change from version 1.0. For the JSON
-version of the API, the following changes are made:
-
-- The ``api-version`` must specify version 1.1 or later.
-- A new ``versions`` key is added at the top level.
-- Two new "file information" keys, ``size`` and ``upload-time``, are added to
-  the ``files`` data.
-- Keys (at any level) with a leading underscore are reserved as private for
-  index server use. No future standard will assign a meaning to any such key.
-
-The ``versions`` and ``size`` keys are mandatory. The ``upload-time`` key is
-optional.
-
-Versions
---------
-
-An additional key, ``versions`` MUST be present at the top level, in addition to
-the keys ``name``, ``files`` and ``meta`` defined in :ref:`the JSON API
-specification `. This key MUST
-contain a list of version strings specifying all of the project versions uploaded
-for this project. The value is logically a set, and as such may not contain
-duplicates, and the order of the values is not significant.
-
-All of the files listed in the ``files`` key MUST be associated with one of the
-versions in the ``versions`` key. The ``versions`` key MAY contain versions with
-no associated files (to represent versions with no files uploaded, if the server
-has such a concept).
-
-Note that because servers may hold "legacy" data from before the adoption of
-:ref:`the version specifiers specification (VSS) `, version
-strings currently cannot be required to be valid VSS versions, and therefore
-cannot be assumed to be orderable using the VSS rules. However, servers SHOULD
-use normalised VSS versions where
-possible.
-
-
-Additional file information
----------------------------
-
-Two new keys are added to the ``files`` key.
-
-- ``size``: This field is mandatory. It MUST contain an integer which is the
-  file size in bytes.
-- ``upload-time``: This field is optional. If present, it MUST contain a valid
-  ISO 8601 date/time string, in the format ``yyyy-mm-ddThh:mm:ss.ffffffZ``,
-  which represents the time the file was uploaded to the index. As indicated by
-  the ``Z`` suffix, the upload time MUST use the UTC timezone. The fractional
-  seconds part of the timestamp (the ``.ffffff`` part) is optional, and if
-  present may contain up to 6 digits of precision. If a server does not record
-  upload time information for a file, it MAY omit the ``upload-time`` key.
 
 Rename dist-info-metadata in the Simple API
 ===========================================
 
-
-The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
-"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
-and "**OPTIONAL**"" in this document are to be interpreted as described in
-:rfc:`RFC 2119 <2119>`.
-
-
 Servers
 -------
 
@@ -992,6 +997,8 @@ if it is present. They
 **MAY** optionally use the legacy ``dist-info-metadata`` key if it is present
 but ``core-metadata`` is not.
 
+.. _simple-repository-history:
+
 History
 =======
 

From 48052a05260b37b9e2e92fbdfc9960de0754c88a Mon Sep 17 00:00:00 2001
From: Russell Keith-Magee 
Date: Fri, 7 Feb 2025 11:30:44 +0800
Subject: [PATCH 0913/1072] Minor tweaks from code review.

Co-authored-by: Malcolm Smith 
---
 source/specifications/platform-compatibility-tags.rst | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 8c4697d27..45746c4ba 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -196,14 +196,14 @@ macOS
 
 macOS uses the ``macosx`` family of tags (the ``x`` suffix is a historical
 artefact of Apple's official macOS naming scheme). The schema for compatibility
-tags is :file:`macosx_{x}_{y}_{arch}``, indicating that the wheel is compatible
+tags is :file:`macosx_{x}_{y}_{arch}`, indicating that the wheel is compatible
 with macOS ``x.y`` or later on the architecture ``arch``.
 
-The value of ``x`` and ``y`` correspond to the major and minor version number of
+The values of ``x`` and ``y`` correspond to the major and minor version number of
 the macOS release, respectively. They must both be positive integers, with the
 ``x`` value being ``>= 10``. The version number always includes a major *and*
 minor version, even if Apple's official version numbering only refers to
-the major value. For example, a ``macosx_11_0_arm64`` indicates compatibility
+the major value. For example, ``macosx_11_0_arm64`` indicates compatibility
 with macOS 11 or later.
 
 macOS binaries can be compiled for a single architecture, or can include support
@@ -238,8 +238,8 @@ Android uses the schema :file:`android_{api_level}_{abi}`, indicating compatibil
 with the given Android API level or later, on the given ABI. Android makes no
 distinction between physical devices and emulated devices.
 
-The API level should be a positive integer. Note that this value is the API
-level, and *not* the user-facing Android version. The release known as Android
+The API level should be a positive integer. This is *not* the same thing as
+the user-facing Android version. For example, the release known as Android
 12 (code named "Snow Cone") uses API level 31 or 32, depending on the specific
 Android version in use. Android's release documentation contains the `full list
 of Android versions and their corresponding API levels

From 2d26d3afecb7ff062ff9146fc37fe488a1109222 Mon Sep 17 00:00:00 2001
From: Russell Keith-Magee 
Date: Fri, 7 Feb 2025 11:39:04 +0800
Subject: [PATCH 0914/1072] Clarified android tagging markup, and added an
 example.

---
 source/specifications/platform-compatibility-tags.rst | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 45746c4ba..d617323d4 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -234,9 +234,11 @@ toolchain when building binaries that support multiple architectures.
 Android
 -------
 
-Android uses the schema :file:`android_{api_level}_{abi}`, indicating compatibility
-with the given Android API level or later, on the given ABI. Android makes no
-distinction between physical devices and emulated devices.
+Android uses the schema :file:`android_{apilevel}_{abi}`, indicating
+compatibility with the given Android API level or later, on the given ABI. For
+example, ``android_27_arm64_v8a`` indicates support for API level 27 or later,
+on ``arm64_v8a`` devices. Android makes no distinction between physical devices
+and emulated devices.
 
 The API level should be a positive integer. This is *not* the same thing as
 the user-facing Android version. For example, the release known as Android

From 61bdcafaeb042c37a13443d79744213d39bf6e5d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Filipe=20La=C3=ADns=20=F0=9F=87=B5=F0=9F=87=B8?=
 
Date: Mon, 10 Feb 2025 18:08:40 +0000
Subject: [PATCH 0915/1072] Update
 source/specifications/build-details/index.rst

Co-authored-by: Zanie Blue 
---
 source/specifications/build-details/index.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/build-details/index.rst b/source/specifications/build-details/index.rst
index bda4e0ba4..369b74f20 100644
--- a/source/specifications/build-details/index.rst
+++ b/source/specifications/build-details/index.rst
@@ -16,7 +16,7 @@ extension ABI details, and other information that is specific to that particular
 build of Python.
 
 Starting from Python 3.14, a ``build-details.json`` file is installed in the
-platform-independent standard library directory (``stdlib``, eg.
+platform-independent standard library directory (``stdlib``, e.g.
 ``/usr/lib/python3.14/build-details.json``).
 
 Please refer to the :ref:`latest version ` for its

From 68d342c0fbcd32233c4ea53af9fc29c280473669 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Mon, 10 Feb 2025 13:50:57 -0500
Subject: [PATCH 0916/1072] simple-repository-api: clean up PEP 658/PEP 714
 bits

Signed-off-by: William Woodruff 
---
 .../specifications/simple-repository-api.rst  | 76 ++++++++-----------
 1 file changed, 33 insertions(+), 43 deletions(-)

diff --git a/source/specifications/simple-repository-api.rst b/source/specifications/simple-repository-api.rst
index e05e3854a..d18c425db 100644
--- a/source/specifications/simple-repository-api.rst
+++ b/source/specifications/simple-repository-api.rst
@@ -88,6 +88,26 @@ In addition to the above, the following constraints are placed on the API:
   associated signature, the signature would be located at
   ``/packages/HolyGrail-1.0.tar.gz.asc``.
 
+* A repository **MAY** include a ``data-core-metadata`` attribute on a file
+  link.
+
+  The repository **SHOULD** provide the hash of the Core Metadata file as the
+  ``data-core-metadata`` attribute's value using the syntax
+  ``=``, where ```` is the lower cased name of
+  the hash function used, and ```` is the hex encoded digest. The
+  repository **MAY** use ``true`` as the attribute's value if a hash is unavailable.
+
+* A repository **MAY** include a ``data-dist-info-metadata`` attribute on a
+  file link.
+
+  Index clients **MAY** consume this key if present, as a legacy fallback
+  for ``data-core-metadata``.
+
+  .. important::
+
+    ``data-dist-info-metadata`` was standardized with :pep:`658` and renamed to
+    ``data-core-metadata`` with :pep:`714`.
+
 * A repository **MAY** include a ``data-gpg-sig`` attribute on a file link with
   a value of either ``true`` or ``false`` to indicate whether or not there is a
   GPG signature. Repositories that do this **SHOULD** include it on every link.
@@ -523,7 +543,7 @@ Each individual file dictionary has the following keys:
   Unlike ``data-requires-python`` in :ref:`the base HTML API specification
   `, the ``requires-python`` key does not
   require any special escaping other than anything JSON does naturally.
-- ``dist-info-metadata``: An **optional** key that indicates
+- ``core-metadata``: An **optional** key that indicates
   that metadata for this file is available, via the same location as specified in
   :ref:`the API metadata file specification
   ` (``{file_url}.metadata``). Where this
@@ -541,11 +561,23 @@ Each individual file dictionary has the following keys:
 
   It is recommended that servers make the hashes of the metadata file available if
   possible.
+
+- ``dist-info-metadata``: An **optional**, deprecated alias for ``core-metadata``.
+
+  Index clients **MAY** consume this key if present, as a legacy fallback
+  for ``core-metadata``.
+
+  .. important::
+
+    ``dist-info-metadata`` was standardized with :pep:`658` and renamed to
+    ``core-metadata`` with :pep:`714`.
+
 - ``gpg-sig``: An **optional** key that acts a boolean to indicate if the file has
   an associated GPG signature or not. The URL for the signature file follows what
   is specified in :ref:`the base HTML API specification
   ` (``{file_url}.asc``). If this key does not exist, then
   the signature may or may not exist.
+
 - ``yanked``: An **optional** key which may be either a boolean to indicate if the
   file has been yanked, or a non empty, but otherwise arbitrary, string to indicate
   that a file has been yanked with a specific reason. If the ``yanked`` key is present
@@ -955,48 +987,6 @@ It is recommended that clients:
 - Check the ``Content-Type`` of the response and ensure it matches something
   that you were expecting.
 
-
-Rename dist-info-metadata in the Simple API
-===========================================
-
-Servers
--------
-
-The :ref:`the API metadata file specification
-` metadata, when used in the HTML
-representation of the Simple API,
-**MUST** be emitted using the attribute name ``data-core-metadata``, with the
-supported values remaining the same.
-
-The :ref:`the API metadata file specification
-` metadata, when used in the :ref:`the
-JSON API specification ` JSON representation of the
-Simple API, **MUST** be emitted using the key ``core-metadata``, with the
-supported values remaining the same.
-
-To support clients that used the previous key names, the HTML representation
-**MAY** also be emitted using the ``data-dist-info-metadata``, and if it does
-so it **MUST** match the value of ``data-core-metadata``.
-
-
-
-Clients
--------
-
-Clients consuming any of the HTML representations of the Simple API **MUST**
-read the :ref:`the API metadata file specification
-` metadata from the key
-``data-core-metadata`` if it is
-present. They **MAY** optionally use the legacy ``data-dist-info-metadata`` if
-it is present but ``data-core-metadata`` is not.
-
-Clients consuming the JSON representation of the Simple API **MUST** read the
-:ref:`the API metadata file specification
-` metadata from the key ``core-metadata``
-if it is present. They
-**MAY** optionally use the legacy ``dist-info-metadata`` key if it is present
-but ``core-metadata`` is not.
-
 .. _simple-repository-history:
 
 History

From 8a67950de7ef72c6b10ea85f63d280dc71d8af85 Mon Sep 17 00:00:00 2001
From: Karolina Surma 
Date: Mon, 17 Feb 2025 10:55:02 +0100
Subject: [PATCH 0917/1072] Fix the reference to License-File core metadata
 field

---
 source/specifications/pyproject-toml.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index c82fdd936..802f50959 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -252,7 +252,7 @@ The table subkeys of the ``license`` key are deprecated.
 
 - TOML_ type: array of strings
 - Corresponding :ref:`core metadata ` field:
-  :ref:`License-Expression `
+  :ref:`License-File `
 
 An array specifying paths in the project source tree relative to the project
 root directory (i.e. directory containing :file:`pyproject.toml` or legacy project

From faf4c7d882ef2be310d5dc46d54ca666aa18821c Mon Sep 17 00:00:00 2001
From: Karolina Surma 
Date: Mon, 17 Feb 2025 11:52:21 +0100
Subject: [PATCH 0918/1072] Document the legacy way of declaring pyproject.toml
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: 🇺🇦 Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 .../licensing-examples-and-user-scenarios.rst |  4 ++
 source/guides/writing-pyproject-toml.rst      | 41 ++++++++++-
 source/tutorials/packaging-projects.rst       | 70 +++++++++++++------
 3 files changed, 92 insertions(+), 23 deletions(-)

diff --git a/source/guides/licensing-examples-and-user-scenarios.rst b/source/guides/licensing-examples-and-user-scenarios.rst
index 5b05d97ea..ae0066581 100644
--- a/source/guides/licensing-examples-and-user-scenarios.rst
+++ b/source/guides/licensing-examples-and-user-scenarios.rst
@@ -10,6 +10,10 @@ Licensing examples and user scenarios
 license files and other legally required information.
 This document aims to provide clear guidance how to migrate from the legacy
 to the standardized way of declaring licenses.
+Make sure your preferred build backend supports :pep:`639` before
+trying to apply the newer guidelines.
+As of February 2025, :doc:`setuptools `
+and :ref:`flit ` don't support :pep:`639` yet.
 
 
 Licensing Examples
diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index f65ab28da..cfde063aa 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -325,6 +325,15 @@ You can also specify the format explicitly, like this:
 ``license``
 -----------
 
+:pep:`639` (accepted in August 2024) has changed the way the ``license`` field
+is declared. Make sure your preferred build backend supports :pep:`639` before
+trying to apply the newer guidelines.
+As of February 2025, :doc:`setuptools `
+and :ref:`flit ` don't support :pep:`639` yet.
+
+:pep:`639` license declaration
+''''''''''''''''''''''''''''''
+
 This is a valid :term:`SPDX license expression ` consisting
 of one or more :term:`license identifiers `.
 The full license list is available at the
@@ -352,10 +361,40 @@ The custom identifiers must follow the SPDX specification,
     [project]
     license = "LicenseRef-My-Custom-License"
 
+Legacy license declaration
+''''''''''''''''''''''''''
+
+This can take two forms. You can put your license in a file, typically
+:file:`LICENSE` or :file:`LICENSE.txt`, and link that file here:
+
+.. code-block:: toml
+
+    [project]
+    license = {file = "LICENSE"}
+
+or you can write the name of the license:
+
+.. code-block:: toml
+
+    [project]
+    license = {text = "MIT License"}
+
+If you are using a standard, well-known license, it is not necessary to use this
+field. Instead, you should use one of the :ref:`classifiers` starting with ``License
+::``. (As a general rule, it is a good idea to use a standard, well-known
+license, both to avoid confusion and because some organizations avoid software
+whose license is unapproved.)
+
 
 ``license-files``
 -----------------
 
+:pep:`639` (accepted in August 2024) has introduced the ``license-files`` field.
+Make sure your preferred build backend supports :pep:`639` before declaring the
+field.
+As of February 2025, :doc:`setuptools `
+and :ref:`flit ` don't support :pep:`639` yet.
+
 This is a list of license files and files containing other legal
 information you want to distribute with your package.
 
@@ -529,7 +568,7 @@ A full example
    ]
    description = "Lovely Spam! Wonderful Spam!"
    readme = "README.rst"
-   license = "MIT"
+   license = "MIT"  # or license = {file = "LICENSE.txt"} for legacy declaration
    license-files = ["LICEN[CS]E.*"]
    keywords = ["egg", "bacon", "sausage", "tomatoes", "Lobster Thermidor"]
    classifiers = [
diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst
index 9357fdfa2..8992fffb0 100644
--- a/source/tutorials/packaging-projects.rst
+++ b/source/tutorials/packaging-projects.rst
@@ -200,27 +200,52 @@ to include your username; this ensures that you have a unique
 package name that doesn't conflict with packages uploaded by other people
 following this tutorial.
 
-.. code-block:: toml
-
-    [project]
-    name = "example_package_YOUR_USERNAME_HERE"
-    version = "0.0.1"
-    authors = [
-      { name="Example Author", email="author@example.com" },
-    ]
-    description = "A small example package"
-    readme = "README.md"
-    requires-python = ">=3.8"
-    classifiers = [
-        "Programming Language :: Python :: 3",
-        "Operating System :: OS Independent",
-    ]
-    license = "MIT"
-    license-files = ["LICEN[CS]E*"]
-
-    [project.urls]
-    Homepage = "https://github.com/pypa/sampleproject"
-    Issues = "https://github.com/pypa/sampleproject/issues"
+.. tab:: hatchling/pdm
+
+  .. code-block:: toml
+
+      [project]
+      name = "example_package_YOUR_USERNAME_HERE"
+      version = "0.0.1"
+      authors = [
+        { name="Example Author", email="author@example.com" },
+      ]
+      description = "A small example package"
+      readme = "README.md"
+      requires-python = ">=3.8"
+      classifiers = [
+          "Programming Language :: Python :: 3",
+          "Operating System :: OS Independent",
+      ]
+      license = "MIT"
+      license-files = ["LICEN[CS]E*"]
+
+      [project.urls]
+      Homepage = "https://github.com/pypa/sampleproject"
+      Issues = "https://github.com/pypa/sampleproject/issues"
+
+.. tab:: setuptools/flit
+
+  .. code-block:: toml
+
+      [project]
+      name = "example_package_YOUR_USERNAME_HERE"
+      version = "0.0.1"
+      authors = [
+        { name="Example Author", email="author@example.com" },
+      ]
+      description = "A small example package"
+      readme = "README.md"
+      requires-python = ">=3.8"
+      classifiers = [
+          "Programming Language :: Python :: 3",
+          "Operating System :: OS Independent",
+          "License :: OSI Approved :: MIT License",
+      ]
+
+      [project.urls]
+      Homepage = "https://github.com/pypa/sampleproject"
+      Issues = "https://github.com/pypa/sampleproject/issues"
 
 - ``name`` is the *distribution name* of your package. This can be any name as
   long as it only contains letters, numbers, ``.``, ``_`` , and ``-``. It also
@@ -249,9 +274,10 @@ following this tutorial.
   your package will work on. For a complete list of classifiers, see
   https://pypi.org/classifiers/.
 - ``license`` is the :term:`SPDX license expression ` of
-  your package.
+  your package. Not supported by all the build backends yet.
 - ``license-files`` is the list of glob paths to the license files,
   relative to the directory where :file:`pyproject.toml` is located.
+  Not supported by all the build backends yet.
 - ``urls`` lets you list any number of extra links to show on PyPI.
   Generally this could be to the source, documentation, issue trackers, etc.
 

From 2a94f3ae763798cc195fc90bca928765025cf7f7 Mon Sep 17 00:00:00 2001
From: Marc Mueller <30130371+cdce8p@users.noreply.github.com>
Date: Tue, 18 Feb 2025 14:57:31 +0100
Subject: [PATCH 0919/1072] Add anchor links for license and license-files

---
 source/guides/writing-pyproject-toml.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index cfde063aa..f77b83b7f 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -322,6 +322,8 @@ You can also specify the format explicitly, like this:
    readme = {file = "README.txt", content-type = "text/x-rst"}
 
 
+.. _license:
+
 ``license``
 -----------
 
@@ -386,6 +388,8 @@ license, both to avoid confusion and because some organizations avoid software
 whose license is unapproved.)
 
 
+.. _license-files:
+
 ``license-files``
 -----------------
 

From 76aaf7919aaad728d094a8990943217def9fcaf4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= 
Date: Sat, 22 Feb 2025 12:12:26 +0100
Subject: [PATCH 0920/1072] Indicate that some distributions require building
 from sources

---
 source/discussions/downstream-packaging.rst | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/source/discussions/downstream-packaging.rst b/source/discussions/downstream-packaging.rst
index d25845e47..3f4795fa8 100644
--- a/source/discussions/downstream-packaging.rst
+++ b/source/discussions/downstream-packaging.rst
@@ -54,9 +54,10 @@ Why?
 ~~~~
 
 The vast majority of downstream packagers prefer to build packages from source,
-rather than use the upstream-provided binary packages. This is also true
-of pure Python packages that provide universal wheels. The reasons for using
-source distributions may include:
+rather than use the upstream-provided binary packages. In some cases, using
+sources is actually required for the package to be included in the distribution.
+This is also true of pure Python packages that provide universal wheels.
+The reasons for using source distributions may include:
 
 - Being able to audit the source code of all packages.
 

From dadfc521d7d9f6022d77376d06c4b028a482fdef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Filipe=20La=C3=ADns=20=F0=9F=87=B5=F0=9F=87=B8?=
 
Date: Thu, 27 Feb 2025 18:01:55 +0000
Subject: [PATCH 0921/1072] Update
 source/specifications/build-details/index.rst
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: 🇺🇦 Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/specifications/build-details/index.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/source/specifications/build-details/index.rst b/source/specifications/build-details/index.rst
index 369b74f20..5da5a7f03 100644
--- a/source/specifications/build-details/index.rst
+++ b/source/specifications/build-details/index.rst
@@ -1,8 +1,8 @@
 .. _build-details:
 
-======================
-``build-details.json``
-======================
+==========================
+:file:`build-details.json`
+==========================
 
 .. toctree::
    :hidden:

From 9a188f226a6f0fc5f849108585fb7269d560b8fd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Filipe=20La=C3=ADns?= 
Date: Thu, 27 Feb 2025 18:05:03 +0000
Subject: [PATCH 0922/1072] Fix linkcheck_ignore regex
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Filipe Laíns 
---
 source/conf.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/conf.py b/source/conf.py
index 317c89dbf..e10132578 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -129,7 +129,7 @@
 
 linkcheck_ignore = [
     "http://localhost:\\d+",
-    "https://packaging.python.org/en/latest/specifications/schemas/*",
+    "https://packaging.python.org/en/latest/specifications/schemas/.*",
     "https://test.pypi.org/project/example-package-YOUR-USERNAME-HERE",
     "https://pypi.org/manage/*",
     "https://test.pypi.org/manage/*",

From 0a5fbefc3e460f7a4b9405bb066ed35045bcbeb1 Mon Sep 17 00:00:00 2001
From: Anderson Bravalheri 
Date: Tue, 11 Mar 2025 11:57:26 +0000
Subject: [PATCH 0923/1072] Extract glob specification to a separated document
 and add reference implementation

---
 source/specifications/glob-patterns.rst       | 115 ++++++++++++++++++
 source/specifications/pyproject-toml.rst      |  31 +----
 .../section-distribution-metadata.rst         |   1 +
 3 files changed, 121 insertions(+), 26 deletions(-)
 create mode 100644 source/specifications/glob-patterns.rst

diff --git a/source/specifications/glob-patterns.rst b/source/specifications/glob-patterns.rst
new file mode 100644
index 000000000..abdb15b0f
--- /dev/null
+++ b/source/specifications/glob-patterns.rst
@@ -0,0 +1,115 @@
+=================
+``glob`` patterns
+=================
+
+Some PyPA specifications, e.g. :ref:`pyproject.toml's license-files
+`, accept certain types of *glob patterns*
+to match a given string containing wildcards and character ranges against
+files and directories. This specification defines which patterns are acceptable
+and how they should be handled.
+
+
+Valid glob patterns
+===================
+
+For PyPA purposes, a *valid glob pattern* MUST be a string matched against
+filesystem entries as specified below:
+
+- Alphanumeric characters, underscores (``_``), hyphens (``-``) and dots (``.``)
+  MUST be matched verbatim.
+
+- Special glob characters: ``*``, ``?``, ``**`` and character ranges: ``[]``
+  containing only the verbatim matched characters MUST be supported.
+  Within ``[...]``, the hyphen indicates a locale-agnostic range (e.g. ``a-z``,
+  order based on Unicode code points).
+  Hyphens at the start or end are matched literally.
+
+- Path delimiters MUST be the forward slash character (``/``).
+
+- Patterns always refer to *relative paths*,
+  e.g., when used in :file:`pyproject.toml`, patterns should always be
+  relative to the directory containing that file.
+  Therefore the leading slash character MUST NOT be used.
+
+- Parent directory indicators (``..``) MUST NOT be used.
+
+Any characters or character sequences not covered by this specification are
+invalid. Projects MUST NOT use such values.
+Tools consuming glob patterns SHOULD reject invalid values with an error.
+
+Literal paths (e.g. :file:`LICENSE`) are valid globs which means they
+can also be defined.
+
+Tools consuming glob patterns:
+
+- MUST treat each value as a glob pattern, and MUST raise an error if the
+  pattern contains invalid glob syntax.
+- MUST raise an error if any individual user-specified pattern does not match
+  at least one file.
+
+Examples of valid glob patterns:
+
+.. code-block:: python
+
+   "LICEN[CS]E*"
+   "AUTHORS*"
+   "licenses/LICENSE.MIT"
+   "licenses/LICENSE.CC0"
+   "LICENSE.txt"
+   "licenses/*"
+
+Examples of invalid glob patterns:
+
+.. code-block:: python
+
+   "..\LICENSE.MIT"
+   # .. must not be used.
+   # \ is an invalid path delimiter, / must be used.
+
+   "LICEN{CSE*"
+   # the { character is not allowed
+
+
+Reference implementation in Python
+==================================
+
+It is possible to defer the majority of the pattern matching against the file
+system to the :mod:`glob` module in Python's standard library. It is necessary
+however to perform additional validations.
+
+The code below is as a simple reference implementation:
+
+.. code-block:: python
+
+   import os
+   import re
+   from glob import glob
+
+
+   def find_pattern(pattern: str) -> list[str]:
+       """
+       >>> find_pattern("/LICENSE.MIT")
+       Traceback (most recent call last):
+       ...
+       ValueError: Pattern '/LICENSE.MIT' should be relative...
+       >>> find_pattern("../LICENSE.MIT")
+       Traceback (most recent call last):
+       ...
+       ValueError: Pattern '../LICENSE.MIT' cannot contain '..'...
+       >>> find_pattern("LICEN{CSE*")
+       Traceback (most recent call last):
+       ...
+       ValueError: Pattern 'LICEN{CSE*' contains invalid characters...
+       """
+       if ".." in pattern:
+           raise ValueError(f"Pattern {pattern!r} cannot contain '..'")
+       if pattern.startswith((os.sep, "/")) or ":\\" in pattern:
+           raise ValueError(
+               f"Pattern {pattern!r} should be relative and must not start with '/'"
+           )
+       if re.match(r'^[\w\-\.\/\*\?\[\]]+$', pattern) is None:
+           raise ValueError(f"Pattern '{pattern}' contains invalid characters.")
+       found = glob(pattern, recursive=True)
+       if not found:
+           raise ValueError(f"Pattern '{pattern}' did not match any files.")
+       return found
diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 802f50959..25cf75bc8 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -247,6 +247,8 @@ Tools SHOULD validate and perform case normalization of the expression.
 The table subkeys of the ``license`` key are deprecated.
 
 
+.. _pyproject-toml-license-files:
+
 ``license-files``
 -----------------
 
@@ -260,43 +262,20 @@ configuration files, e.g. :file:`setup.py`, :file:`setup.cfg`, etc.)
 to file(s) containing licenses and other legal notices to be
 distributed with the package.
 
-The strings MUST contain valid glob patterns, as specified below:
-
-- Alphanumeric characters, underscores (``_``), hyphens (``-``) and dots (``.``)
-  MUST be matched verbatim.
-
-- Special glob characters: ``*``, ``?``, ``**`` and character ranges: ``[]``
-  containing only the verbatim matched characters MUST be supported.
-  Within ``[...]``, the hyphen indicates a locale-agnostic range (e.g. ``a-z``,
-  order based on Unicode code points).
-  Hyphens at the start or end are matched literally.
+The strings MUST contain valid glob patterns, as specified in
+:doc:`/specifications/glob-patterns`.
 
-- Path delimiters MUST be the forward slash character (``/``).
-  Patterns are relative to the directory containing :file:`pyproject.toml`,
-  therefore the leading slash character MUST NOT be used.
-
-- Parent directory indicators (``..``) MUST NOT be used.
-
-Any characters or character sequences not covered by this specification are
-invalid. Projects MUST NOT use such values.
-Tools consuming this field SHOULD reject invalid values with an error.
+Patterns are relative to the directory containing :file:`pyproject.toml`,
 
 Tools MUST assume that license file content is valid UTF-8 encoded text,
 and SHOULD validate this and raise an error if it is not.
 
-Literal paths (e.g. :file:`LICENSE`) are valid globs which means they
-can also be defined.
-
 Build tools:
 
-- MUST treat each value as a glob pattern, and MUST raise an error if the
-  pattern contains invalid glob syntax.
 - MUST include all files matched by a listed pattern in all distribution
   archives.
 - MUST list each matched file path under a License-File field in the
   Core Metadata.
-- MUST raise an error if any individual user-specified pattern does not match
-  at least one file.
 
 If the ``license-files`` key is present and
 is set to a value of an empty array, then tools MUST NOT include any
diff --git a/source/specifications/section-distribution-metadata.rst b/source/specifications/section-distribution-metadata.rst
index af7c1c3e6..4f3a67777 100644
--- a/source/specifications/section-distribution-metadata.rst
+++ b/source/specifications/section-distribution-metadata.rst
@@ -14,3 +14,4 @@ Package Distribution Metadata
    inline-script-metadata
    platform-compatibility-tags
    well-known-project-urls
+   glob-patterns

From a81a2d00f7ec46a7587d77b39bbf13de2aca36c1 Mon Sep 17 00:00:00 2001
From: Anderson Bravalheri 
Date: Fri, 21 Mar 2025 12:17:30 +0000
Subject: [PATCH 0924/1072] Allow referencing/linking to individual fields in
 pyproject.toml

---
 source/specifications/pyproject-toml.rst | 31 +++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 25cf75bc8..1adf9e686 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -149,6 +149,8 @@ The complete list of keys allowed in the ``[project]`` table are:
 - ``version``
 
 
+.. _pyproject-toml-name:
+
 ``name``
 --------
 
@@ -161,6 +163,9 @@ The name of the project.
 Tools SHOULD :ref:`normalize ` this name, as soon
 as it is read for internal consistency.
 
+
+.. _pyproject-toml-version:
+
 ``version``
 -----------
 
@@ -174,6 +179,8 @@ The version of the project, as defined in the
 Users SHOULD prefer to specify already-normalized versions.
 
 
+.. _pyproject-toml-description:
+
 ``description``
 ---------------
 
@@ -185,6 +192,8 @@ The summary description of the project in one line. Tools MAY error
 if this includes multiple lines.
 
 
+.. _pyproject-toml-readme:
+
 ``readme``
 ----------
 
@@ -224,6 +233,8 @@ as supported by the :ref:`core metadata `. Otherwise
 tools MUST raise an error for unsupported content-types.
 
 
+.. _pyproject-toml-requires-python:
+
 ``requires-python``
 -------------------
 
@@ -234,6 +245,8 @@ tools MUST raise an error for unsupported content-types.
 The Python version requirements of the project.
 
 
+.. _pyproject-toml-license:
+
 ``license``
 -----------
 
@@ -285,6 +298,9 @@ license files. For example they can choose not to include any files or use
 their own logic to discover the appropriate files in the distribution.
 
 
+.. _pyproject-toml-authors:
+.. _pyproject-toml-maintainers:
+
 ``authors``/``maintainers``
 ---------------------------
 
@@ -327,6 +343,8 @@ follows:
 4. Multiple values should be separated by commas.
 
 
+.. _pyproject-toml-keywords:
+
 ``keywords``
 ------------
 
@@ -337,6 +355,8 @@ follows:
 The keywords for the project.
 
 
+.. _pyproject-toml-classifiers:
+
 ``classifiers``
 ---------------
 
@@ -353,6 +373,8 @@ Build tools MAY raise an error if both the ``license`` string value
 classifiers are used.
 
 
+.. _pyproject-toml-urls:
+
 ``urls``
 --------
 
@@ -365,6 +387,10 @@ URL itself. See :ref:`well-known-project-urls` for normalization rules
 and well-known rules when processing metadata for presentation.
 
 
+.. _pyproject-toml-scripts:
+.. _pyproject-toml-gui-scripts:
+.. _pyproject-toml-entry-points:
+
 Entry points
 ------------
 
@@ -395,6 +421,9 @@ be ambiguous in the face of ``[project.scripts]`` and
 ``[project.gui-scripts]``, respectively.
 
 
+.. _pyproject-toml-dependencies:
+.. _pyproject-toml-optional-dependencies:
+
 ``dependencies``/``optional-dependencies``
 ------------------------------------------
 
@@ -422,7 +451,7 @@ matching :ref:`Provides-Extra `
 metadata.
 
 
-
+.. _pyproject-toml-dynamic:
 .. _declaring-project-metadata-dynamic:
 
 ``dynamic``

From 59b55cf05a7bd89c452b544fa6bebff631d15617 Mon Sep 17 00:00:00 2001
From: Karolina Surma 
Date: Wed, 26 Mar 2025 13:57:51 +0100
Subject: [PATCH 0925/1072] Specify the valid SPDX license expressions (closes
 #1828)

---
 source/specifications/core-metadata.rst       |  4 +-
 source/specifications/license-expression.rst  | 56 +++++++++++++++++++
 source/specifications/pyproject-toml.rst      |  4 +-
 .../section-distribution-metadata.rst         |  1 +
 4 files changed, 62 insertions(+), 3 deletions(-)
 create mode 100644 source/specifications/license-expression.rst

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 2129be541..39ee7c4cd 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -468,8 +468,8 @@ License-Expression
 .. versionadded:: 2.4
 
 Text string that is a valid SPDX
-`license expression `__
-as `defined in PEP 639 `__.
+:term:`license expression `,
+as specified in :doc:`/specifications/license-expression`.
 
 Examples::
 
diff --git a/source/specifications/license-expression.rst b/source/specifications/license-expression.rst
new file mode 100644
index 000000000..50860b7aa
--- /dev/null
+++ b/source/specifications/license-expression.rst
@@ -0,0 +1,56 @@
+==================
+License Expression
+==================
+
+:pep:`639` defined a new :ref:`pyproject.toml's license `
+value and added a corresponding :ref:`core metadata License-Expression field
+`.
+This specification defines which license expressions are acceptable.
+
+
+Specification
+=============
+
+License can be defined as a text string that is a valid SPDX
+:term:`license expression `,
+as documented in the `SPDX specification `__,
+either Version 2.2 or a later compatible version.
+
+A license expression can use the following license identifiers:
+
+- Any SPDX-listed license short-form identifiers that are published in
+  the `SPDX License List `__,
+  version 3.17 or any later compatible version.
+
+- The custom ``LicenseRef-[idstring]`` string(s), where ``[idstring]`` is
+  a unique string containing letters, numbers, ``.`` and/or ``-``,
+  to identify licenses that are not included in the SPDX license list.
+  The custom identifiers must follow the SPDX specification,
+  `clause 10.1 `__ of the given specification version.
+
+
+Examples of valid license expressions:
+
+.. code-block:: yaml
+
+    MIT
+    BSD-3-Clause
+    MIT AND (Apache-2.0 OR BSD-2-Clause)
+    MIT OR GPL-2.0-or-later OR (FSFUL AND BSD-2-Clause)
+    GPL-3.0-only WITH Classpath-Exception-2.0 OR BSD-3-Clause
+    LicenseRef-Special-License OR CC0-1.0 OR Unlicense
+    LicenseRef-Proprietary
+
+
+Examples of invalid license expressions:
+
+.. code-block:: yaml
+
+    Use-it-after-midnight  # No `LicenseRef` prefix
+    Apache-2.0 OR 2-BSD-Clause  # 2-BSD-Clause is not a valid SPDX identifier
+    LicenseRef-License with spaces  # spaces are not allowed
+    LicenseRef-License_with_underscores  # underscore are not allowed
+
+.. _spdxcustom: https://spdx.github.io/spdx-spec/v2.2.2/other-licensing-information-detected/
+.. _spdxlist: https://spdx.org/licenses/
+.. _spdxpression: https://spdx.github.io/spdx-spec/v2.2.2/SPDX-license-expressions/
diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 1adf9e686..9af16582f 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -254,7 +254,9 @@ The Python version requirements of the project.
 - Corresponding :ref:`core metadata ` field:
   :ref:`License-Expression `
 
-Text string that is a valid SPDX license expression as defined in :pep:`639`.
+Text string that is a valid SPDX
+:term:`license expression `,
+as specified in :doc:`/specifications/license-expression`.
 Tools SHOULD validate and perform case normalization of the expression.
 
 The table subkeys of the ``license`` key are deprecated.
diff --git a/source/specifications/section-distribution-metadata.rst b/source/specifications/section-distribution-metadata.rst
index 4f3a67777..551e6b730 100644
--- a/source/specifications/section-distribution-metadata.rst
+++ b/source/specifications/section-distribution-metadata.rst
@@ -15,3 +15,4 @@ Package Distribution Metadata
    platform-compatibility-tags
    well-known-project-urls
    glob-patterns
+   license-expression

From 28e262b43f28c9fc1cd8f3625e245a32217fcb02 Mon Sep 17 00:00:00 2001
From: Karolina Surma 
Date: Wed, 26 Mar 2025 13:58:20 +0100
Subject: [PATCH 0926/1072] Document legacy pyproject.toml license
 specification

Cleary mark it as legacy and replaced by PEP 639.
---
 source/specifications/pyproject-toml.rst | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 9af16582f..321a63a81 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -259,8 +259,21 @@ Text string that is a valid SPDX
 as specified in :doc:`/specifications/license-expression`.
 Tools SHOULD validate and perform case normalization of the expression.
 
-The table subkeys of the ``license`` key are deprecated.
+Legacy specification
+''''''''''''''''''''
 
+- TOML_ type: table
+- Corresponding :ref:`core metadata ` field:
+  :ref:`License `
+
+The table may have one of two keys. The ``file`` key has a string
+value that is a file path relative to ``pyproject.toml`` to the file
+which contains the license for the project. Tools MUST assume the
+file's encoding is UTF-8. The ``text`` key has a string value which is
+the license of the project.  These keys are mutually exclusive, so a
+tool MUST raise an error if the metadata specifies both keys.
+
+The table subkeys were deprecated by :pep:`639` in favor of the string value.
 
 .. _pyproject-toml-license-files:
 

From 3ccd14f0422e455fda75bec3e8680113eba59b47 Mon Sep 17 00:00:00 2001
From: Karolina Surma <33810531+befeleme@users.noreply.github.com>
Date: Wed, 26 Mar 2025 15:42:50 +0100
Subject: [PATCH 0927/1072] Update source/specifications/pyproject-toml.rst
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: 🇺🇦 Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/specifications/pyproject-toml.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 321a63a81..4ce9b7484 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -267,7 +267,7 @@ Legacy specification
   :ref:`License `
 
 The table may have one of two keys. The ``file`` key has a string
-value that is a file path relative to ``pyproject.toml`` to the file
+value that is a file path relative to :file:`pyproject.toml` to the file
 which contains the license for the project. Tools MUST assume the
 file's encoding is UTF-8. The ``text`` key has a string value which is
 the license of the project.  These keys are mutually exclusive, so a

From 1415b22466bf489397404ec3473d00aaa4df513a Mon Sep 17 00:00:00 2001
From: Martin Fischer 
Date: Thu, 27 Mar 2025 06:13:22 +0100
Subject: [PATCH 0928/1072] refactor: include build system tabs from shared
 file instead of duplicating them

---
 source/guides/writing-pyproject-toml.rst | 33 +-----------------------
 source/shared/build-backend-tabs.rst     | 33 ++++++++++++++++++++++++
 source/tutorials/packaging-projects.rst  | 33 +-----------------------
 3 files changed, 35 insertions(+), 64 deletions(-)
 create mode 100644 source/shared/build-backend-tabs.rst

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index f77b83b7f..03b402084 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -56,38 +56,7 @@ Usually, you'll just copy what your build backend's documentation
 suggests (after :ref:`choosing your build backend `).
 Here are the values for some common build backends:
 
-.. tab:: Hatchling
-
-    .. code-block:: toml
-
-        [build-system]
-        requires = ["hatchling"]
-        build-backend = "hatchling.build"
-
-.. tab:: setuptools
-
-    .. code-block:: toml
-
-        [build-system]
-        requires = ["setuptools >= 61.0"]
-        build-backend = "setuptools.build_meta"
-
-.. tab:: Flit
-
-    .. code-block:: toml
-
-        [build-system]
-        requires = ["flit_core >= 3.4"]
-        build-backend = "flit_core.buildapi"
-
-.. tab:: PDM
-
-    .. code-block:: toml
-
-        [build-system]
-        requires = ["pdm-backend"]
-        build-backend = "pdm.backend"
-
+.. include:: ../shared/build-backend-tabs.rst
 
 
 Static vs. dynamic metadata
diff --git a/source/shared/build-backend-tabs.rst b/source/shared/build-backend-tabs.rst
new file mode 100644
index 000000000..7177317be
--- /dev/null
+++ b/source/shared/build-backend-tabs.rst
@@ -0,0 +1,33 @@
+.. (comment) This file is included in guides/writing-pyproject-toml.rst and tutorials/packaging-projects.rst.
+
+.. tab:: Hatchling
+
+    .. code-block:: toml
+
+        [build-system]
+        requires = ["hatchling"]
+        build-backend = "hatchling.build"
+
+.. tab:: setuptools
+
+    .. code-block:: toml
+
+        [build-system]
+        requires = ["setuptools >= 61.0"]
+        build-backend = "setuptools.build_meta"
+
+.. tab:: Flit
+
+    .. code-block:: toml
+
+        [build-system]
+        requires = ["flit_core >= 3.4"]
+        build-backend = "flit_core.buildapi"
+
+.. tab:: PDM
+
+    .. code-block:: toml
+
+        [build-system]
+        requires = ["pdm-backend"]
+        build-backend = "pdm.backend"
diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst
index 8992fffb0..2888fef89 100644
--- a/source/tutorials/packaging-projects.rst
+++ b/source/tutorials/packaging-projects.rst
@@ -136,38 +136,7 @@ The :file:`pyproject.toml` tells :term:`build frontend ` tools l
 examples for common build backends, but check your backend's own documentation
 for more details.
 
-.. tab:: Hatchling
-
-    .. code-block:: toml
-
-        [build-system]
-        requires = ["hatchling"]
-        build-backend = "hatchling.build"
-
-.. tab:: setuptools
-
-    .. code-block:: toml
-
-        [build-system]
-        requires = ["setuptools>=61.0"]
-        build-backend = "setuptools.build_meta"
-
-.. tab:: Flit
-
-    .. code-block:: toml
-
-        [build-system]
-        requires = ["flit_core>=3.4"]
-        build-backend = "flit_core.buildapi"
-
-.. tab:: PDM
-
-    .. code-block:: toml
-
-        [build-system]
-        requires = ["pdm-backend"]
-        build-backend = "pdm.backend"
-
+.. include:: ../shared/build-backend-tabs.rst
 
 The ``requires`` key is a list of packages that are needed to build your package.
 The :term:`frontend ` should install them automatically when building your package.

From 6d0b21a4d9362bc0ca635aef15ec354852a78fce Mon Sep 17 00:00:00 2001
From: Martin Fischer 
Date: Tue, 25 Mar 2025 08:12:03 +0100
Subject: [PATCH 0929/1072] Latest setuptools and flit now support PEP 639

This updates the now outdated notes added in
faf4c7d882ef2be310d5dc46d54ca666aa18821c.

Closes #1831.
---
 .../licensing-examples-and-user-scenarios.rst |  2 -
 source/guides/writing-pyproject-toml.rst      | 88 +++++++++----------
 source/shared/build-backend-tabs.rst          |  9 +-
 source/tutorials/packaging-projects.rst       | 72 +++++----------
 4 files changed, 73 insertions(+), 98 deletions(-)

diff --git a/source/guides/licensing-examples-and-user-scenarios.rst b/source/guides/licensing-examples-and-user-scenarios.rst
index ae0066581..2c25ddfb0 100644
--- a/source/guides/licensing-examples-and-user-scenarios.rst
+++ b/source/guides/licensing-examples-and-user-scenarios.rst
@@ -12,8 +12,6 @@ This document aims to provide clear guidance how to migrate from the legacy
 to the standardized way of declaring licenses.
 Make sure your preferred build backend supports :pep:`639` before
 trying to apply the newer guidelines.
-As of February 2025, :doc:`setuptools `
-and :ref:`flit ` don't support :pep:`639` yet.
 
 
 Licensing Examples
diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index 03b402084..318fe0d51 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -291,22 +291,43 @@ You can also specify the format explicitly, like this:
    readme = {file = "README.txt", content-type = "text/x-rst"}
 
 
-.. _license:
+.. _license-and-license-files:
 
-``license``
------------
+``license`` and ``license-files``
+---------------------------------
+
+As per :pep:`639` licenses should be declared with two fields:
+
+- ``license`` is an :term:`SPDX license expression ` consisting
+  of one or more :term:`license identifiers `.
+- ``license-files`` is a list of license file glob patterns.
+
+A previous PEP had specified ``license`` to be a table with a ``file`` or a
+``text`` key, this format is now deprecated. Most :term:`build backends` now support the new format as shown in the following table.
+
+.. list-table:: build backend versions that introduced :pep:`639` support
+   :header-rows: 1
 
-:pep:`639` (accepted in August 2024) has changed the way the ``license`` field
-is declared. Make sure your preferred build backend supports :pep:`639` before
-trying to apply the newer guidelines.
-As of February 2025, :doc:`setuptools `
-and :ref:`flit ` don't support :pep:`639` yet.
+   * - hatchling
+     - setuptools
+     - flit-core [#flit-core-pep639]_
+     - pdm-backend
+     - poetry-core
+   * - 1.27.0
+     - 77.0.3
+     - 3.12
+     - 2.4.0
+     - `not yet `_
 
-:pep:`639` license declaration
-''''''''''''''''''''''''''''''
 
-This is a valid :term:`SPDX license expression ` consisting
-of one or more :term:`license identifiers `.
+.. _license:
+
+``license``
+'''''''''''
+
+The new format for ``license`` is a valid :term:`SPDX license expression `
+consisting of one or more :term:`license identifiers `.
 The full license list is available at the
 `SPDX license list page `_. The supported list version is
 3.17 or any later compatible one.
@@ -318,6 +339,11 @@ The full license list is available at the
     # or
     license = "MIT AND (Apache-2.0 OR BSD-2-Clause)"
 
+.. note:: If you get a build error that ``license`` should be a dict/table,
+   your build backend doesn't yet support the new format. See the
+   `above section `_ for more context.
+   The now deprecated format is `described in PEP 621 `__.
+
 As a general rule, it is a good idea to use a standard, well-known
 license, both to avoid confusion and because some organizations avoid software
 whose license is unapproved.
@@ -332,41 +358,11 @@ The custom identifiers must follow the SPDX specification,
     [project]
     license = "LicenseRef-My-Custom-License"
 
-Legacy license declaration
-''''''''''''''''''''''''''
-
-This can take two forms. You can put your license in a file, typically
-:file:`LICENSE` or :file:`LICENSE.txt`, and link that file here:
-
-.. code-block:: toml
-
-    [project]
-    license = {file = "LICENSE"}
-
-or you can write the name of the license:
-
-.. code-block:: toml
-
-    [project]
-    license = {text = "MIT License"}
-
-If you are using a standard, well-known license, it is not necessary to use this
-field. Instead, you should use one of the :ref:`classifiers` starting with ``License
-::``. (As a general rule, it is a good idea to use a standard, well-known
-license, both to avoid confusion and because some organizations avoid software
-whose license is unapproved.)
-
 
 .. _license-files:
 
 ``license-files``
------------------
-
-:pep:`639` (accepted in August 2024) has introduced the ``license-files`` field.
-Make sure your preferred build backend supports :pep:`639` before declaring the
-field.
-As of February 2025, :doc:`setuptools `
-and :ref:`flit ` don't support :pep:`639` yet.
+'''''''''''''''''
 
 This is a list of license files and files containing other legal
 information you want to distribute with your package.
@@ -541,7 +537,7 @@ A full example
    ]
    description = "Lovely Spam! Wonderful Spam!"
    readme = "README.rst"
-   license = "MIT"  # or license = {file = "LICENSE.txt"} for legacy declaration
+   license = "MIT"
    license-files = ["LICEN[CS]E.*"]
    keywords = ["egg", "bacon", "sausage", "tomatoes", "Lobster Thermidor"]
    classifiers = [
@@ -579,6 +575,9 @@ A full example
    like ``requires-python = "<= 3.10"`` here. `This blog post `_
    contains some information regarding possible problems.
 
+.. [#flit-core-pep639] flit-core `does not yet `_ support WITH in SPDX license expressions.
+
+.. _flit-issue-735: https://github.com/pypa/flit/issues/735
 .. _gfm: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax
 .. _setuptools: https://setuptools.pypa.io
 .. _poetry: https://python-poetry.org
@@ -586,6 +585,7 @@ A full example
 .. _pypi-search-pip: https://pypi.org/search?q=pip
 .. _classifier-list: https://pypi.org/classifiers
 .. _requires-python-blog-post: https://iscinumpy.dev/post/bound-version-constraints/#pinning-the-python-version-is-special
+.. _poetry-pep639-issue: https://github.com/python-poetry/poetry/issues/9670
 .. _pytest: https://pytest.org
 .. _pygments: https://pygments.org
 .. _rest: https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html
diff --git a/source/shared/build-backend-tabs.rst b/source/shared/build-backend-tabs.rst
index 7177317be..0e5bd6190 100644
--- a/source/shared/build-backend-tabs.rst
+++ b/source/shared/build-backend-tabs.rst
@@ -1,11 +1,12 @@
 .. (comment) This file is included in guides/writing-pyproject-toml.rst and tutorials/packaging-projects.rst.
+.. The minimum versions here are the versions that introduced support for PEP 639.
 
 .. tab:: Hatchling
 
     .. code-block:: toml
 
         [build-system]
-        requires = ["hatchling"]
+        requires = ["hatchling >= 1.26"]
         build-backend = "hatchling.build"
 
 .. tab:: setuptools
@@ -13,7 +14,7 @@
     .. code-block:: toml
 
         [build-system]
-        requires = ["setuptools >= 61.0"]
+        requires = ["setuptools >= 77.0.3"]
         build-backend = "setuptools.build_meta"
 
 .. tab:: Flit
@@ -21,7 +22,7 @@
     .. code-block:: toml
 
         [build-system]
-        requires = ["flit_core >= 3.4"]
+        requires = ["flit_core >= 3.12.0"]
         build-backend = "flit_core.buildapi"
 
 .. tab:: PDM
@@ -29,5 +30,5 @@
     .. code-block:: toml
 
         [build-system]
-        requires = ["pdm-backend"]
+        requires = ["pdm-backend >= 2.4.0"]
         build-backend = "pdm.backend"
diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst
index 2888fef89..6d0a95d5c 100644
--- a/source/tutorials/packaging-projects.rst
+++ b/source/tutorials/packaging-projects.rst
@@ -144,6 +144,8 @@ Frontends usually run builds in isolated environments, so omitting dependencies
 here may cause build-time errors.
 This should always include your backend's package, and might have other build-time
 dependencies.
+The minimum version specified in the above code block is the one that introduced support
+for :ref:`the new license metadata `.
 
 The ``build-backend`` key is the name of the Python object that frontends will use
 to perform the build.
@@ -169,52 +171,27 @@ to include your username; this ensures that you have a unique
 package name that doesn't conflict with packages uploaded by other people
 following this tutorial.
 
-.. tab:: hatchling/pdm
-
-  .. code-block:: toml
-
-      [project]
-      name = "example_package_YOUR_USERNAME_HERE"
-      version = "0.0.1"
-      authors = [
-        { name="Example Author", email="author@example.com" },
-      ]
-      description = "A small example package"
-      readme = "README.md"
-      requires-python = ">=3.8"
-      classifiers = [
-          "Programming Language :: Python :: 3",
-          "Operating System :: OS Independent",
-      ]
-      license = "MIT"
-      license-files = ["LICEN[CS]E*"]
-
-      [project.urls]
-      Homepage = "https://github.com/pypa/sampleproject"
-      Issues = "https://github.com/pypa/sampleproject/issues"
-
-.. tab:: setuptools/flit
-
-  .. code-block:: toml
-
-      [project]
-      name = "example_package_YOUR_USERNAME_HERE"
-      version = "0.0.1"
-      authors = [
-        { name="Example Author", email="author@example.com" },
-      ]
-      description = "A small example package"
-      readme = "README.md"
-      requires-python = ">=3.8"
-      classifiers = [
-          "Programming Language :: Python :: 3",
-          "Operating System :: OS Independent",
-          "License :: OSI Approved :: MIT License",
-      ]
-
-      [project.urls]
-      Homepage = "https://github.com/pypa/sampleproject"
-      Issues = "https://github.com/pypa/sampleproject/issues"
+.. code-block:: toml
+
+    [project]
+    name = "example_package_YOUR_USERNAME_HERE"
+    version = "0.0.1"
+    authors = [
+      { name="Example Author", email="author@example.com" },
+    ]
+    description = "A small example package"
+    readme = "README.md"
+    requires-python = ">=3.8"
+    classifiers = [
+        "Programming Language :: Python :: 3",
+        "Operating System :: OS Independent",
+    ]
+    license = "MIT"
+    license-files = ["LICEN[CS]E*"]
+
+    [project.urls]
+    Homepage = "https://github.com/pypa/sampleproject"
+    Issues = "https://github.com/pypa/sampleproject/issues"
 
 - ``name`` is the *distribution name* of your package. This can be any name as
   long as it only contains letters, numbers, ``.``, ``_`` , and ``-``. It also
@@ -243,10 +220,9 @@ following this tutorial.
   your package will work on. For a complete list of classifiers, see
   https://pypi.org/classifiers/.
 - ``license`` is the :term:`SPDX license expression ` of
-  your package. Not supported by all the build backends yet.
+  your package.
 - ``license-files`` is the list of glob paths to the license files,
   relative to the directory where :file:`pyproject.toml` is located.
-  Not supported by all the build backends yet.
 - ``urls`` lets you list any number of extra links to show on PyPI.
   Generally this could be to the source, documentation, issue trackers, etc.
 

From 8a64c523640afe3791419687c6a59feeed1f7c6e Mon Sep 17 00:00:00 2001
From: Martin Fischer 
Date: Sat, 29 Mar 2025 06:37:51 +0100
Subject: [PATCH 0930/1072] Add <4 to require as recommended by Flit docs

As per https://flit.pypa.io/en/stable/pyproject_toml.html#build-system-section:

> For now, all packages should specify <4, so they won't be
> impacted by changes in the next major version.
---
 source/shared/build-backend-tabs.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/shared/build-backend-tabs.rst b/source/shared/build-backend-tabs.rst
index 0e5bd6190..7fc3a61da 100644
--- a/source/shared/build-backend-tabs.rst
+++ b/source/shared/build-backend-tabs.rst
@@ -22,7 +22,7 @@
     .. code-block:: toml
 
         [build-system]
-        requires = ["flit_core >= 3.12.0"]
+        requires = ["flit_core >= 3.12.0, <4"]
         build-backend = "flit_core.buildapi"
 
 .. tab:: PDM

From ef7502a2e58855d06ef3f5cc320b17992a15bd16 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Filipe=20La=C3=ADns?= 
Date: Sun, 30 Mar 2025 12:52:56 +0100
Subject: [PATCH 0931/1072] Set html_extra_path
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Filipe Laíns 
---
 source/conf.py | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/source/conf.py b/source/conf.py
index e10132578..b4565afe4 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -83,6 +83,10 @@
     # https://plausible.io/packaging.python.org
     html_js_files.extend(_metrics_js_files)
 
+html_extra_path = [
+    "specifications/schemas",
+]
+
 # -- Options for HTML help output ------------------------------------------------------
 # https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-html-help-output
 

From 76a2f55024e4188eb65ac71996af8a0824488acb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Filipe=20La=C3=ADns?= 
Date: Sun, 30 Mar 2025 12:53:25 +0100
Subject: [PATCH 0932/1072] Fix schema ID
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Filipe Laíns 
---
 source/specifications/schemas/build-details-v1.0.schema.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/schemas/build-details-v1.0.schema.json b/source/specifications/schemas/build-details-v1.0.schema.json
index b088431b5..9954ddab7 100644
--- a/source/specifications/schemas/build-details-v1.0.schema.json
+++ b/source/specifications/schemas/build-details-v1.0.schema.json
@@ -1,6 +1,6 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "$id": "https://packaging.python.org/en/latest/specifications/schemas/python-build-info-v1.0.schema.json",
+  "$id": "https://packaging.python.org/en/latest/specifications/schemas/build-details-v1.0.schema.json",
   "type": "object",
   "title": "build-details.json — a static description file with build details of Python installations",
   "required": [

From 7b72c11d5409a7262ac94ad4ae275ef3619af2eb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Filipe=20La=C3=ADns?= 
Date: Sun, 30 Mar 2025 12:53:40 +0100
Subject: [PATCH 0933/1072] Use download role for schema
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Filipe Laíns 
---
 source/specifications/build-details/index.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/build-details/index.rst b/source/specifications/build-details/index.rst
index 5da5a7f03..1d4470aef 100644
--- a/source/specifications/build-details/index.rst
+++ b/source/specifications/build-details/index.rst
@@ -46,7 +46,7 @@ v1.0
       - :ref:`build-details-v1.0`
 
     * - Schema
-      - https://packaging.python.org/en/latest/specifications/schemas/python-build-info-v1.0.schema.json
+      - :download:`https://packaging.python.org/en/latest/specifications/schemas/build-details-v1.0.schema.json <../schemas/build-details-v1.0.schema.json>`
 
 
 - Initial version, introduced by :pep:`739`.

From 486e6842e7c17522293f1f43a871bc18b4e1582e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Filipe=20La=C3=ADns?= 
Date: Thu, 3 Apr 2025 03:49:38 +0100
Subject: [PATCH 0934/1072] specifications: fix build-details-v1.0.schema.json
 location
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Filipe Laíns 
---
 .../specifications/schemas/build-details-v1.0.schema.json       | 0
 source/conf.py                                                  | 2 +-
 source/specifications/build-details/index.rst                   | 2 +-
 source/specifications/build-details/v1.0.rst                    | 2 +-
 4 files changed, 3 insertions(+), 3 deletions(-)
 rename {source => extra}/specifications/schemas/build-details-v1.0.schema.json (100%)

diff --git a/source/specifications/schemas/build-details-v1.0.schema.json b/extra/specifications/schemas/build-details-v1.0.schema.json
similarity index 100%
rename from source/specifications/schemas/build-details-v1.0.schema.json
rename to extra/specifications/schemas/build-details-v1.0.schema.json
diff --git a/source/conf.py b/source/conf.py
index b4565afe4..b0c468df7 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -84,7 +84,7 @@
     html_js_files.extend(_metrics_js_files)
 
 html_extra_path = [
-    "specifications/schemas",
+    "../extra",
 ]
 
 # -- Options for HTML help output ------------------------------------------------------
diff --git a/source/specifications/build-details/index.rst b/source/specifications/build-details/index.rst
index 1d4470aef..0cd5b5fe5 100644
--- a/source/specifications/build-details/index.rst
+++ b/source/specifications/build-details/index.rst
@@ -46,7 +46,7 @@ v1.0
       - :ref:`build-details-v1.0`
 
     * - Schema
-      - :download:`https://packaging.python.org/en/latest/specifications/schemas/build-details-v1.0.schema.json <../schemas/build-details-v1.0.schema.json>`
+      - https://packaging.python.org/en/latest/specifications/schemas/build-details-v1.0.schema.json
 
 
 - Initial version, introduced by :pep:`739`.
diff --git a/source/specifications/build-details/v1.0.rst b/source/specifications/build-details/v1.0.rst
index cfe902e1e..3a8cfe277 100644
--- a/source/specifications/build-details/v1.0.rst
+++ b/source/specifications/build-details/v1.0.rst
@@ -8,7 +8,7 @@
 Specification
 -------------
 
-.. jsonschema:: ../schemas/build-details-v1.0.schema.json
+.. jsonschema:: ../../../extra/specifications/schemas/build-details-v1.0.schema.json
     :lift_title: false
 
 

From 5413e625561c719e2ac15b8c9c0313141524d73e Mon Sep 17 00:00:00 2001
From: Ee Durbin 
Date: Tue, 8 Apr 2025 03:16:27 -0400
Subject: [PATCH 0935/1072] Add psfhosted plausbile instance to analytics

I'm evaluating the self-hosted option on the psf infrastructure.
---
 source/conf.py | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/source/conf.py b/source/conf.py
index b0c468df7..b3ebd0502 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -75,7 +75,11 @@
     (
         "https://plausible.io/js/script.js",
         {"data-domain": "packaging.python.org", "defer": "defer"},
-    )
+    ),
+    (
+        "https://analytics.python.org/js/script.js",
+        {"data-domain": "packaging.python.org", "defer": "defer"},
+    ),
 ]
 html_js_files = []
 if RTD_CANONICAL_BUILD:

From 11de88c7397fb99781ba090fad148c665607ddc1 Mon Sep 17 00:00:00 2001
From: Douglas Silva 
Date: Mon, 14 Apr 2025 10:44:54 -0300
Subject: [PATCH 0936/1072] Update packaging-projects.rst: set requires-python
 to 3.9

See https://github.com/pypa/packaging.python.org/issues/1845
---
 source/tutorials/packaging-projects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst
index 6d0a95d5c..f2c0851ba 100644
--- a/source/tutorials/packaging-projects.rst
+++ b/source/tutorials/packaging-projects.rst
@@ -181,7 +181,7 @@ following this tutorial.
     ]
     description = "A small example package"
     readme = "README.md"
-    requires-python = ">=3.8"
+    requires-python = ">=3.9"
     classifiers = [
         "Programming Language :: Python :: 3",
         "Operating System :: OS Independent",

From b8cfd1cf129d0648260126740d7c6aa4905f8cbf Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Mon, 14 Apr 2025 16:26:36 -0700
Subject: [PATCH 0937/1072] Add PEP 751

---
 .../specifications/dependency-specifiers.rst  |  53 +-
 source/specifications/index.rst               |   1 +
 source/specifications/pylock-toml.rst         | 772 ++++++++++++++++++
 .../section-reproducible-environments.rst     |   8 +
 4 files changed, 823 insertions(+), 11 deletions(-)
 create mode 100644 source/specifications/pylock-toml.rst
 create mode 100644 source/specifications/section-reproducible-environments.rst

diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst
index 06897da27..332dbe6e7 100644
--- a/source/specifications/dependency-specifiers.rst
+++ b/source/specifications/dependency-specifiers.rst
@@ -87,7 +87,7 @@ environments::
                      'platform_system' | 'platform_version' |
                      'platform_machine' | 'platform_python_implementation' |
                      'implementation_name' | 'implementation_version' |
-                     'extra' # ONLY when defined by a containing layer
+                     'extra' | 'extras' | 'dependency_groups' # ONLY when defined by a containing layer
                      )
     marker_var    = wsp* (env_var | python_str)
     marker_expr   = marker_var marker_op marker_var
@@ -196,15 +196,16 @@ safely evaluate it without running arbitrary code that could become a security
 vulnerability. Markers were first standardised in :pep:`345`. This document
 fixes some issues that were observed in the design described in :pep:`426`.
 
-Comparisons in marker expressions are typed by the comparison operator.  The
- operators that are not in  perform the same as they
-do for strings in Python. The  operators use the version comparison
-rules of the :ref:`Version specifier specification `
-when those are defined (that is when both sides have a valid
-version specifier). If there is no defined behaviour of this specification
-and the operator exists in Python, then the operator falls back to
-the Python behaviour. Otherwise an error should be raised. e.g. the following
-will result in  errors::
+Comparisons in marker expressions are typed by the comparison operator and the
+type of the marker value. The  operators that are not in
+ perform the same as they do for strings or sets in Python based on
+whether the marker value is a string or set itself. The  operators
+use the version comparison rules of the
+:ref:`Version specifier specification ` when those are
+defined (that is when both sides have a valid version specifier). If there is no
+defined behaviour of this specification and the operator exists in Python, then
+the operator falls back to the Python behaviour for the types involved.
+Otherwise an error should be raised. e.g. the following will result in errors::
 
     "dog" ~= "fred"
     python_version ~= "surprise"
@@ -235,52 +236,80 @@ no current specification for this. Regardless, outside of a context where this
 special handling is taking place, the "extra" variable should result in an
 error like all other unknown variables.
 
+The "extras" and "dependency_groups" variables are also special. They are used
+to specify any requested extras or dependency groups when installing from a lock
+file. Outside of the context of lock files, these two variables should result in
+an error like all other unknown variables.
+
 .. list-table::
    :header-rows: 1
 
    * - Marker
      - Python equivalent
+     - Type
      - Sample values
    * - ``os_name``
      - :py:data:`os.name`
+     - String
      - ``posix``, ``java``
    * - ``sys_platform``
      - :py:data:`sys.platform`
+     - String
      - ``linux``, ``linux2``, ``darwin``, ``java1.8.0_51`` (note that "linux"
        is from Python3 and "linux2" from Python2)
    * - ``platform_machine``
      - :py:func:`platform.machine()`
+     - String
      - ``x86_64``
    * - ``platform_python_implementation``
      - :py:func:`platform.python_implementation()`
+     - String
      - ``CPython``, ``Jython``
    * - ``platform_release``
      - :py:func:`platform.release()`
+     - String
      - ``3.14.1-x86_64-linode39``, ``14.5.0``, ``1.8.0_51``
    * - ``platform_system``
      - :py:func:`platform.system()`
+     - String
      - ``Linux``, ``Windows``, ``Java``
    * - ``platform_version``
      - :py:func:`platform.version()`
+     - String
      - ``#1 SMP Fri Apr 25 13:07:35 EDT 2014``
        ``Java HotSpot(TM) 64-Bit Server VM, 25.51-b03, Oracle Corporation``
        ``Darwin Kernel Version 14.5.0: Wed Jul 29 02:18:53 PDT 2015; root:xnu-2782.40.9~2/RELEASE_X86_64``
    * - ``python_version``
      - ``'.'.join(platform.python_version_tuple()[:2])``
+     - Version
      - ``3.4``, ``2.7``
    * - ``python_full_version``
      - :py:func:`platform.python_version()`
+     - Version
      - ``3.4.0``, ``3.5.0b1``
    * - ``implementation_name``
      - :py:data:`sys.implementation.name `
+     - String
      - ``cpython``
    * - ``implementation_version``
      - see definition below
+     - Version
      - ``3.4.0``, ``3.5.0b1``
    * - ``extra``
      - An error except when defined by the context interpreting the
        specification.
+     - String
      - ``test``
+   * - ``extras``
+     - An error except when defined by the context interpreting the
+       specification.
+     - Set of strings
+     - ``{"test"}``
+   * - ``dependency_groups``
+     - An error except when defined by the context interpreting the
+       specification.
+     - Set of strings
+     - ``{"test"}``
 
 The ``implementation_version`` marker variable is derived from
 :py:data:`sys.implementation.version `:
@@ -330,7 +359,7 @@ The complete parsley grammar::
                      'platform_system' | 'platform_version' |
                      'platform_machine' | 'platform_python_implementation' |
                      'implementation_name' | 'implementation_version' |
-                     'extra' # ONLY when defined by a containing layer
+                     'extra' | 'extras' | 'dependency_groups' # ONLY when defined by a containing layer
                      ):varname -> lookup(varname)
     marker_var    = wsp* (env_var | python_str)
     marker_expr   = marker_var:l marker_op:o marker_var:r -> (o, l, r)
@@ -495,6 +524,8 @@ History
 - June 2024: The definition of ``version_many`` was changed to allow trailing
   commas, matching with the behavior of the Python implementation that has been
   in use since late 2022.
+- April 2025: Added ``extras`` and ``dependency_groups`` for lock-file-spec_ as
+  approved through :pep:`751`.
 
 
 References
diff --git a/source/specifications/index.rst b/source/specifications/index.rst
index c69605927..68d95ab98 100644
--- a/source/specifications/index.rst
+++ b/source/specifications/index.rst
@@ -16,3 +16,4 @@ and for proposing new ones, is documented on
    section-distribution-formats
    section-package-indices
    section-python-description-formats
+   section-reproducible-environments
diff --git a/source/specifications/pylock-toml.rst b/source/specifications/pylock-toml.rst
new file mode 100644
index 000000000..700aac3a4
--- /dev/null
+++ b/source/specifications/pylock-toml.rst
@@ -0,0 +1,772 @@
+.. _pylock-toml-spec:
+.. _lock-files:
+
+=============================
+``pylock.toml`` Specification
+=============================
+
+The ``pylock.toml`` file format is for specifying dependencies to enable
+reproducible installation in a Python environment.
+
+.. note:: This specification was originally defined in :pep:`751`.
+
+
+---------
+File Name
+---------
+
+A lock file MUST be named :file:`pylock.toml` or match the regular expression
+``r"^pylock\.([^.]+)\.toml$"`` if a name for the lock file is desired or if
+multiple lock files exist (i.e. the regular expression
+``r"^pylock\.([^.]+\.)?toml$"`` for any file name). The prefix and suffix of a
+named file MUST be lowercase when possible, for easy detection and removal,
+e.g.:
+
+.. code-block:: Python
+
+  if len(filename) > 11 and filename.startswith("pylock.") and filename.endswith(".toml"):
+      name = filename.removeprefix("pylock.").removesuffix(".toml")
+
+The expectation is that services that automatically install from lock files will
+search for:
+
+1. The lock file with the service's name and doing the default install
+2. A multi-use ``pylock.toml`` with a dependency group with the name of the service
+3. The default install of ``pylock.toml``
+
+E.g. a cloud host service named "spam" would first look for
+``pylock.spam.toml`` to install from, and if that file didn't exist then install
+from ``pylock.toml`` and look for a dependency group named "spam" to use if
+present.
+
+The lock file(s) SHOULD be located in the directory as appropriate for the scope
+of the lock file. Locking against a single ``pyproject.toml``, for instance,
+would place the ``pylock.toml`` in the same directory. If the lock file covered
+multiple projects in a monorepo, then the expectation is the ``pylock.toml``
+file would be in the directory that held all the projects being locked.
+
+
+-----------
+File Format
+-----------
+
+The format of the file is TOML_.
+
+Tools SHOULD write their lock files in a consistent way to minimize noise in
+diff output. Keys in tables -- including the top-level table -- SHOULD be
+recorded in a consistent order (if inspiration is desired, this PEP has tried to
+write down keys in a logical order). As well, tools SHOULD sort arrays in
+consistent order. Usage of inline tables SHOULD also be kept consistent.
+
+.. File details
+
+``lock-version``
+================
+
+- **Type**: string; value of ``"1.0"``
+- **Required?**: yes
+- **Inspiration**: :ref:`core-metadata-metadata-version`
+- Record the file format version that the file adheres to.
+- This PEP specifies the initial version -- and only valid value until future
+  updates to the standard change it -- as ``"1.0"``.
+- If a tool supports the major version but not the minor version, a tool
+  SHOULD warn when an unknown key is seen.
+- If a tool doesn't support a major version, it MUST raise an error.
+
+
+``environments``
+================
+
+- **Type**: Array of strings
+- **Required?**: no
+- **Inspiration**: uv_
+- A list of :ref:`dependency-specifiers-environment-markers` for
+  which the lock file is considered compatible with.
+- Tools SHOULD write exclusive/non-overlapping environment markers to ease in
+  understanding.
+
+
+``requires-python``
+===================
+
+- **Type**: string
+- **Required?**: no
+- **Inspiration**: PDM_, Poetry_, uv_
+- Specifies the :ref:`core-metadata-requires-python` for the minimum
+  Python version compatible for any environment supported by the lock file
+  (i.e. the minimum viable Python version for the lock file).
+
+
+``extras``
+==========
+
+- **Type**: Array of strings
+- **Required?**: no; defaults to ``[]``
+- **Inspiration**: :ref:`core-metadata-provides-extra`
+- The list of :ref:`extras ` supported
+  by this lock file.
+- Lockers MAY choose to not support writing lock files that support extras and
+  dependency groups (i.e. tools may only support exporting a single-use lock
+  file).
+- Tools supporting extras MUST also support dependency groups.
+- Tools should explicitly set this key to an empty array to signal that the
+  inputs used to generate the lock file had no extras (e.g. a ``pyproject.toml``
+  file had no ``[project.optional-dependencies]`` table), signalling that the
+  lock file is, in effect, multi-use even if it only looks to be single-use.
+
+
+``dependency-groups``
+=====================
+
+- **Type**: Array of strings
+- **Required?**: no; defaults to ``[]``
+- **Inspiration**: :ref:`pyproject-tool-table`
+- The list of :ref:`dependency-groups` publicly supported by this lock
+  file (i.e. dependency groups users are expected to be able to specify via a
+  tool's UI).
+- Lockers MAY choose to not support writing lock files that support extras and
+  dependency groups (i.e. tools may only support exporting a single-use lock
+  file).
+- Tools supporting dependency groups MUST also support extras.
+- Tools SHOULD explicitly set this key to an empty array to signal that the
+  inputs used to generate the lock file had no dependency groups (e.g. a ``pyproject.toml``
+  file had no ``[dependency-groups]`` table), signalling that the lock file
+  is, in effect, multi-use even if it only looks to be single-use.
+
+
+``default-groups``
+==================
+
+- **Type**: Array of strings
+- **Required?**: no; defaults to ``[]``
+- **Inspiration**: Poetry_, PDM_
+- The name of synthetic dependency groups to represent what should be installed
+  by default (e.g. what ``project.dependencies`` implicitly represents).
+- Meant to be used in situations where ``packages.marker`` necessitates such a
+  group to exist.
+- The groups listed by this key SHOULD NOT be listed in ``dependency-groups`` as
+  the groups are not meant to be directly exposed to users by name but instead
+  via an installer's UI.
+
+
+``created-by``
+==============
+
+- **Type**: string
+- **Required?**: yes
+- **Inspiration**: Tools with their name in their lock file name
+- Records the name of the tool used to create the lock file.
+- Tools MAY use the ``[tool]`` table to record enough details that it can be
+  inferred what inputs were used to create the lock file.
+- Tools SHOULD record the normalized name of the tool if it is available as a
+  Python package to facilitate finding the tool.
+
+
+``[[packages]]``
+================
+
+- **Type**: array of tables
+- **Required?**: yes
+- **Inspiration**: PDM_, Poetry_, uv_
+- An array containing all packages that *may* be installed.
+- Packages MAY be listed multiple times with varying data, but all packages to
+  be installed MUST narrow down to a single entry at install time.
+
+
+.. Identification
+
+``packages.name``
+-----------------
+
+- **Type**: string
+- **Required?**: yes
+- **Inspiration**: :ref:`core-metadata-name`
+- The name of the package :ref:`normalized `.
+
+
+``packages.version``
+--------------------
+
+- **Type**: string
+- **Required?**: no
+- **Inspiration**: :ref:`core-metadata-version`
+- The version of the package.
+- The version SHOULD be specified when the version is known to be stable
+  (i.e. when an :ref:`sdist ` or
+  :ref:`wheels ` are specified).
+- The version MUST NOT be included when it cannot be guaranteed to be consistent
+  with the code used (i.e. when a
+  :ref:`source tree ` is
+  used).
+
+
+.. Requirements
+
+``packages.marker``
+-------------------
+
+- **Type**: string
+- **Required?**: no
+- **Inspiration**: PDM_
+- The
+  :ref:`environment marker `
+  which specify when the package should be installed.
+
+
+``packages.requires-python``
+----------------------------
+
+- **Type**: string
+- **Required?**: no
+- **Inspiration**: :ref:`core-metadata-requires-python`
+- Holds the :ref:`version-specifiers` for Python version compatibility
+  for the package.
+
+
+``[[packages.dependencies]]``
+-----------------------------
+
+- **Type**: array of tables
+- **Required?**: no
+- **Inspiration**: PDM_, Poetry_, uv_
+- Records the other entries in ``[[packages]]`` which are direct dependencies of
+  this package.
+- Each entry is a table which contains the minimum information required to tell
+  which other package entry it corresponds to where doing a key-by-key
+  comparison would find the appropriate package with no ambiguity (e.g. if there
+  are two entries for the ``spam`` package, then you can include the version
+  number like ``{name = "spam", version = "1.0.0"}``, or by source like
+  ``{name = "spam", vcs = { url = "..."}``).
+- Tools MUST NOT use this information when doing installation; it is purely
+  informational for auditing purposes.
+
+
+.. Source
+
+``[packages.vcs]``
+-------------------
+
+- **Type**: table
+- **Required?**: no; mutually-exclusive with ``packages.directory``,
+  ``packages.archive``, ``packages.sdist``, and ``packages.wheels``
+- **Inspiration**: :ref:`direct-url-data-structure`
+- Record the version control system details for the
+  :ref:`source tree ` it
+  contains.
+- Tools MAY choose to not support version control systems, both from a locking
+  and/or installation perspective.
+- Tools MAY choose to only support a subset of the available VCS types.
+- Tools SHOULD provide a way for users to opt in/out of using version control
+  systems.
+- Installation from a version control system is considered originating from a
+  :ref:`direct URL reference `.
+
+
+``packages.vcs.type``
+''''''''''''''''''''''
+
+- **Type**: string; supported values specified in
+  :ref:`direct-url-data-structure-registered-vcs`
+- **Required?**: yes
+- **Inspiration**: :ref:`direct-url-data-structure-vcs`
+- The type of version control system used.
+
+
+``packages.vcs.url``
+'''''''''''''''''''''
+
+- **Type**: string
+- **Required?**: if ``path`` is not specified
+- **Inspiration**: :ref:`direct-url-data-structure-vcs`
+- The URL to the source tree.
+
+
+``packages.vcs.path``
+''''''''''''''''''''''
+
+- **Type**: string
+- **Required?**: if ``url`` is not specified
+- **Inspiration**: :ref:`direct-url-data-structure-vcs`
+- The path to the local directory of the source tree.
+- If a relative path is used it MUST be relative to the location of this file.
+- If the path is relative it MAY use POSIX-style path separators explicitly
+  for portability.
+
+
+``packages.vcs.requested-revision``
+''''''''''''''''''''''''''''''''''''
+
+- **Type**: string
+- **Required?**: no
+- **Inspiration**: :ref:`direct-url-data-structure-vcs`
+- The branch/tag/ref/commit/revision/etc. that the user requested.
+- This is purely informational and to facilitate writing the
+  :ref:`direct-url-data-structure`; it MUST NOT be used to checkout
+  the repository.
+
+
+``packages.vcs.commit-id``
+'''''''''''''''''''''''''''
+
+- **Type**: string
+- **Required?**: yes
+- **Inspiration**: :ref:`direct-url-data-structure-vcs`
+- The exact commit/revision number that is to be installed.
+- If the VCS supports commit-hash based revision identifiers, such a commit-hash
+  MUST be used as the commit ID in order to reference an immutable version of
+  the source code.
+
+
+``packages.vcs.subdirectory``
+''''''''''''''''''''''''''''''
+
+- **Type**: string
+- **Required?**: no
+- **Inspiration**: :ref:`direct-url-data-structure-subdirectories`
+- The subdirectory within the
+  :ref:`source tree ` where
+  the project root of the project is (e.g. the location of the
+  ``pyproject.toml`` file).
+- The path MUST be relative to the root of the source tree structure.
+
+
+``[packages.directory]``
+-------------------------
+
+- **Type**: table
+- **Required?**: no; mutually-exclusive with ``packages.vcs``,
+  ``packages.archive``, ``packages.sdist``, and ``packages.wheels``
+- **Inspiration**: :ref:`direct-url-data-structure-local-directory`
+- Record the local directory details for the
+  :ref:`source tree ` it
+  contains.
+- Tools MAY choose to not support local directories, both from a locking
+  and/or installation perspective.
+- Tools SHOULD provide a way for users to opt in/out of using local directories.
+- Installation from a directory is considered originating from a
+  :ref:`direct URL reference `.
+
+
+``packages.directory.path``
+''''''''''''''''''''''''''''
+
+- **Type**: string
+- **Required?**: yes
+- **Inspiration**: :ref:`direct-url-data-structure-local-directory`
+- The local directory where the source tree is.
+- If the path is relative it MUST be relative to the location of the lock file.
+- If the path is relative it MAY use POSIX-style path separators for
+  portability.
+
+
+``packages.directory.editable``
+''''''''''''''''''''''''''''''''
+
+- **Type**: boolean
+- **Required?**: no; defaults to ``false``
+- **Inspiration**: :ref:`direct-url-data-structure-local-directory`
+- A flag representing whether the source tree was an editable install at lock
+  time.
+- An installer MAY choose to ignore this flag if user actions or context would
+  make an editable install unnecessary or undesirable (e.g. a container image
+  that will not be mounted for development purposes but instead deployed to
+  production where it would be treated at read-only).
+
+
+``packages.directory.subdirectory``
+''''''''''''''''''''''''''''''''''''
+
+See ``packages.vcs.subdirectory``.
+
+
+``[packages.archive]``
+-----------------------
+
+- **Type**: table
+- **Required?**: no
+- **Inspiration**: :ref:`direct-url-data-structure-archive`
+- A direct reference to an archive file to install from
+  (this can include wheels and sdists, as well as other archive formats
+  containing a source tree).
+- Tools MAY choose to not support archive files, both from a locking
+  and/or installation perspective.
+- Tools SHOULD provide a way for users to opt in/out of using archive files.
+- Installation from an archive file is considered originating from a
+  :ref:`direct URL reference `.
+
+
+``packages.archive.url``
+'''''''''''''''''''''''''
+
+See ``packages.vcs.url``.
+
+
+``packages.archive.path``
+''''''''''''''''''''''''''
+
+See ``packages.vcs.path``.
+
+
+``packages.archive.size``
+''''''''''''''''''''''''''
+
+- **Type**: integer
+- **Required?**: no
+- **Inspiration**: uv_, :ref:`simple-repository-api`
+- The size of the archive file.
+- Tools SHOULD provide the file size when reasonably possible (e.g. the file
+  size is available via the Content-Length_ header from a HEAD_ HTTP request).
+
+
+``packages.archive.upload-time``
+''''''''''''''''''''''''''''''''
+
+- **Type**: datetime
+- **Required?**: no
+- **Inspiration**: :ref:`simple-repository-api`
+- The time the file was uploaded.
+- The date and time MUST be recorded in UTC.
+
+
+``[packages.archive.hashes]``
+''''''''''''''''''''''''''''''
+
+- **Type**: Table of strings
+- **Required?**: yes
+- **Inspiration**: PDM_, Poetry_, uv_, :ref:`simple-repository-api`
+- A table listing known hash values of the file where the key is the hash
+  algorithm and the value is the hash value.
+- The table MUST contain at least one entry.
+- Hash algorithm keys SHOULD be lowercase.
+- At least one secure algorithm from :py:data:`hashlib.algorithms_guaranteed`
+  SHOULD always be included (at time of writing, sha256 specifically is
+  recommended.
+
+
+``packages.archive.subdirectory``
+''''''''''''''''''''''''''''''''''
+
+See ``packages.vcs.subdirectory``.
+
+
+``packages.index``
+------------------
+
+- **Type**: string
+- **Required?**: no
+- **Inspiration**: uv_
+- The base URL for the package index from :ref:`simple-repository-api`
+  where the sdist and/or wheels were found (e.g. ``https://pypi.org/simple/``).
+- When possible, this SHOULD be specified to assist with generating
+  `software bill of materials`_ -- aka SBOMs -- and to assist in finding a file
+  if a URL ceases to be valid.
+- Tools MAY support installing from an index if the URL recorded for a specific
+  file is no longer valid (e.g. returns a 404 HTTP error code).
+
+
+``[packages.sdist]``
+--------------------
+
+- **Type**: table
+- **Required?**: no; mutually-exclusive with ``packages.vcs``,
+  ``packages.directory``, and ``packages.archive``
+- **Inspiration**: uv_
+- Details of a :ref:`source-distribution-format-sdist` for the
+  package.
+- Tools MAY choose to not support sdist files, both from a locking
+  and/or installation perspective.
+- Tools SHOULD provide a way for users to opt in/out of using sdist files.
+
+
+``packages.sdist.name``
+'''''''''''''''''''''''
+
+- **Type**: string
+- **Required?**: no, not when the last component of ``path``/ ``url`` would be
+  the same value
+- **Inspiration**: PDM_, Poetry_, uv_
+- The file name of the :ref:`source-distribution-format-sdist` file.
+
+
+``packages.sdist.upload-time``
+''''''''''''''''''''''''''''''
+
+See ``packages.archive.upload-time``.
+
+
+``packages.sdist.url``
+''''''''''''''''''''''
+
+See ``packages.archive.url``.
+
+
+``packages.sdist.path``
+'''''''''''''''''''''''
+
+See ``packages.archive.path``.
+
+
+``packages.sdist.size``
+'''''''''''''''''''''''
+
+See ``packages.archive.size``.
+
+
+``packages.sdist.hashes``
+'''''''''''''''''''''''''
+
+See ``packages.archive.hashes``.
+
+
+
+``[[packages.wheels]]``
+-----------------------
+
+- **Type**: array of tables
+- **Required?**: no; mutually-exclusive with ``packages.vcs``,
+  ``packages.directory``, and ``packages.archive``
+- **Inspiration**: PDM_, Poetry_, uv_
+- For recording the wheel files as specified by
+  :ref:`  binary-distribution-format` for the package.
+- Tools MUST support wheel files, both from a locking and installation
+  perspective.
+
+
+``packages.wheels.name``
+''''''''''''''''''''''''
+
+- **Type**: string
+- **Required?**: no, not when the last component of ``path``/ ``url`` would be
+  the same value
+- **Inspiration**: PDM_, Poetry_, uv_
+- The file name of the :ref:`  binary-distribution-format` file.
+
+
+``packages.wheels.upload-time``
+'''''''''''''''''''''''''''''''
+
+See ``packages.archive.upload-time``.
+
+
+``packages.wheels.url``
+'''''''''''''''''''''''
+
+See ``packages.archive.url``.
+
+
+``packages.wheels.path``
+''''''''''''''''''''''''
+
+See ``packages.archive.path``.
+
+
+``packages.wheels.size``
+''''''''''''''''''''''''
+
+See ``packages.archive.size``.
+
+
+``packages.wheels.hashes``
+''''''''''''''''''''''''''
+
+See ``packages.archive.hashes``.
+
+
+``[[packages.attestation-identities]]``
+---------------------------------------
+
+- **Type**: array of tables
+- **Required?**: no
+- **Inspiration**: :ref:`  provenance-object`
+- A recording of the attestations for **any** file recorded for this package.
+- If available, tools SHOULD include the attestation identities found.
+- Publisher-specific keys are to be included in the table as-is
+  (i.e. top-level), following the spec at
+  :ref:`  index-hosted-attestations`.
+
+
+``packages.attestation-identities.kind``
+''''''''''''''''''''''''''''''''''''''''
+
+- **Type**: string
+- **Required?**: yes
+- **Inspiration**: :ref:`  provenance-object`
+- The unique identity of the Trusted Publisher.
+
+
+``[packages.tool]``
+-------------------
+
+- **Type**: table
+- **Required?**: no
+- **Inspiration**: :ref:`  pyproject-tool-table`
+- Similar usage as that of the ``[tool]`` table from the
+  :ref:`  pyproject-toml-spec`, but at the package version level instead
+  of at the lock file level (which is also available via ``[tool]``).
+- Data recorded in the table MUST be disposable (i.e. it MUST NOT affect
+  installation).
+
+
+``[tool]``
+==========
+
+- **Type**: table
+- **Required?**: no
+- **Inspiration**: :ref:`  pyproject-tool-table`
+- See ``packages.tool``.
+
+
+-------
+Example
+-------
+
+.. code-block:: TOML
+
+  lock-version = '1.0'
+  environments = ["sys_platform == 'win32'", "sys_platform == 'linux'"]
+  requires-python = '==3.12'
+  created-by = 'mousebender'
+
+  [[packages]]
+  name = 'attrs'
+  version = '25.1.0'
+  requires-python = '>=3.8'
+  wheels = [
+    {name = 'attrs-25.1.0-py3-none-any.whl', upload-time = 2025-01-25T11:30:10.164985+00:00, url = 'https://files.pythonhosted.org/packages/fc/30/d4986a882011f9df997a55e6becd864812ccfcd821d64aac8570ee39f719/attrs-25.1.0-py3-none-any.whl', size = 63152, hashes = {sha256 = 'c75a69e28a550a7e93789579c22aa26b0f5b83b75dc4e08fe092980051e1090a'}},
+  ]
+  [[packages.attestation-identities]]
+  environment = 'release-pypi'
+  kind = 'GitHub'
+  repository = 'python-attrs/attrs'
+  workflow = 'pypi-package.yml'
+
+  [[packages]]
+  name = 'cattrs'
+  version = '24.1.2'
+  requires-python = '>=3.8'
+  dependencies = [
+      {name = 'attrs'},
+  ]
+  wheels = [
+    {name = 'cattrs-24.1.2-py3-none-any.whl', upload-time = 2024-09-22T14:58:34.812643+00:00, url = 'https://files.pythonhosted.org/packages/c8/d5/867e75361fc45f6de75fe277dd085627a9db5ebb511a87f27dc1396b5351/cattrs-24.1.2-py3-none-any.whl', size = 66446, hashes = {sha256 = '67c7495b760168d931a10233f979b28dc04daf853b30752246f4f8471c6d68d0'}},
+  ]
+
+  [[packages]]
+  name = 'numpy'
+  version = '2.2.3'
+  requires-python = '>=3.10'
+  wheels = [
+    {name = 'numpy-2.2.3-cp312-cp312-win_amd64.whl', upload-time = 2025-02-13T16:51:21.821880+00:00, url = 'https://files.pythonhosted.org/packages/42/6e/55580a538116d16ae7c9aa17d4edd56e83f42126cb1dfe7a684da7925d2c/numpy-2.2.3-cp312-cp312-win_amd64.whl', size = 12626357, hashes = {sha256 = '83807d445817326b4bcdaaaf8e8e9f1753da04341eceec705c001ff342002e5d'}},
+    {name = 'numpy-2.2.3-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl', upload-time = 2025-02-13T16:50:00.079662+00:00, url = 'https://files.pythonhosted.org/packages/39/04/78d2e7402fb479d893953fb78fa7045f7deb635ec095b6b4f0260223091a/numpy-2.2.3-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl', size = 16116679, hashes = {sha256 = '3b787adbf04b0db1967798dba8da1af07e387908ed1553a0d6e74c084d1ceafe'}},
+  ]
+
+  [tool.mousebender]
+  command = ['.', 'lock', '--platform', 'cpython3.12-windows-x64', '--platform', 'cpython3.12-manylinux2014-x64', 'cattrs', 'numpy']
+  run-on = 2025-03-06T12:28:57.760769
+
+
+------------
+Installation
+------------
+
+The following outlines the steps to be taken to install from a lock file
+(while the requirements are prescriptive, the general steps and order are
+a suggestion):
+
+#. Gather the extras and dependency groups to install and set ``extras`` and
+   ``dependency_groups`` for marker evaluation, respectively.
+
+   #. ``extras`` SHOULD be set to the empty set by default.
+   #. ``dependency_groups`` SHOULD be the set created from ``default-groups`` by
+      default.
+
+#. Check if the metadata version specified by ``lock-version`` is supported;
+   an error or warning MUST be raised as appropriate.
+#. If ``requires-python`` is specified, check that the environment being
+   installed for meets the requirement; an error MUST be raised if it is not
+   met.
+#. If ``environments`` is specified, check that at least one of the environment
+   marker expressions is satisfied; an error MUST be raised if no expression is
+   satisfied.
+#. For each package listed in ``[[packages]]``:
+
+   #. If ``marker`` is specified, check if it is satisfied; if it isn't,
+      skip to the next package.
+   #. If ``requires-python`` is specified, check if it is satisfied; an error
+      MUST be raised if it isn't.
+   #. Check that no other conflicting instance of the package has been slated to
+      be installed; an error about the ambiguity MUST be raised otherwise.
+   #. Check that the source of the package is specified appropriately (i.e.
+      there are no conflicting sources in the package entry);
+      an error MUST be raised if any issues are found.
+   #. Add the package to the set of packages to install.
+
+#. For each package to be installed:
+
+   - If ``vcs`` is set:
+
+     #. Clone the repository to the commit ID specified in ``commit-id``.
+     #. Build the package, respecting ``subdirectory``.
+     #. Install.
+
+   - Else if ``directory`` is set:
+
+     #. Build the package, respecting ``subdirectory``.
+     #. Install.
+
+   - Else if ``archive`` is set:
+
+     #. Get the file.
+     #. Validate the file size and hash.
+     #. Build the package, respecting ``subdirectory``.
+     #. Install.
+
+   - Else if there are entries for ``wheels``:
+
+     #. Look for the appropriate wheel file based on ``name``; if one is not
+        found then move on to ``sdist`` or an error MUST be raised about a
+        lack of source for the project.
+     #. Get the file:
+
+        - If ``path`` is set, use it.
+        - If ``url`` is set, try to use it; optionally tools MAY use
+          ``packages.index`` or some tool-specific mechanism to download the
+          selected wheel file (tools MUST NOT try to change what wheel file to
+          download based on what's available; what file to install should be
+          determined in an offline fashion for reproducibility).
+
+     #. Validate the file size and hash.
+     #. Install.
+
+   - Else if no ``wheel`` file is found or ``sdist`` is solely set:
+
+     #. Get the file.
+
+        - If ``path`` is set, use it.
+        - If ``url`` is set, try to use it; tools MAY use
+          ``packages.index`` or some tool-specific mechanism to download the
+          file.
+
+     #. Validate the file size and hash.
+     #. Build the package.
+     #. Install.
+
+
+-------
+History
+-------
+
+- April 2025: Initial version, approved via :pep:`751`.
+
+
+.. _Content-Length: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Length
+.. _Dependabot: https://docs.github.com/en/code-security/dependabot
+.. _HEAD: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/HEAD
+.. _PDM: https://pypi.org/project/pdm/
+.. _pip-tools: https://pypi.org/project/pip-tools/
+.. _Poetry: https://python-poetry.org/
+.. _requirements file:
+.. _requirements files: https://pip.pypa.io/en/stable/reference/requirements-file-format/
+.. _software bill of materials: https://www.cisa.gov/sbom
+.. _TOML: https://toml.io/
+.. _uv: https://github.com/astral-sh/uv
diff --git a/source/specifications/section-reproducible-environments.rst b/source/specifications/section-reproducible-environments.rst
new file mode 100644
index 000000000..1f83f3673
--- /dev/null
+++ b/source/specifications/section-reproducible-environments.rst
@@ -0,0 +1,8 @@
+=========================
+Reproducible Environments
+=========================
+
+.. toctree::
+   :titlesonly:
+
+   pylock-toml

From e06f55b0d8edeba0705a58db0e9f477f786dd394 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Mon, 14 Apr 2025 16:32:43 -0700
Subject: [PATCH 0938/1072] Fix a reference

---
 source/specifications/pylock-toml.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/pylock-toml.rst b/source/specifications/pylock-toml.rst
index 700aac3a4..c214f4c18 100644
--- a/source/specifications/pylock-toml.rst
+++ b/source/specifications/pylock-toml.rst
@@ -1,5 +1,5 @@
 .. _pylock-toml-spec:
-.. _lock-files:
+.. _lock-files-spec:
 
 =============================
 ``pylock.toml`` Specification

From effb0611f926b6ae7eea678f767d3fb137e40e87 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Mon, 14 Apr 2025 16:34:17 -0700
Subject: [PATCH 0939/1072] Fix a reference (again)

---
 source/specifications/pylock-toml.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/pylock-toml.rst b/source/specifications/pylock-toml.rst
index c214f4c18..75449e4d1 100644
--- a/source/specifications/pylock-toml.rst
+++ b/source/specifications/pylock-toml.rst
@@ -1,5 +1,5 @@
 .. _pylock-toml-spec:
-.. _lock-files-spec:
+.. _lock-file-spec:
 
 =============================
 ``pylock.toml`` Specification

From 8db327530dadfe3e28da0e4f3bfb227589eee2d8 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Mon, 14 Apr 2025 16:36:05 -0700
Subject: [PATCH 0940/1072] Use a reference arrpropriately

---
 source/specifications/dependency-specifiers.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst
index 332dbe6e7..c8701b795 100644
--- a/source/specifications/dependency-specifiers.rst
+++ b/source/specifications/dependency-specifiers.rst
@@ -524,8 +524,8 @@ History
 - June 2024: The definition of ``version_many`` was changed to allow trailing
   commas, matching with the behavior of the Python implementation that has been
   in use since late 2022.
-- April 2025: Added ``extras`` and ``dependency_groups`` for lock-file-spec_ as
-  approved through :pep:`751`.
+- April 2025: Added ``extras`` and ``dependency_groups`` for
+  :ref:`lock-file-spec` as approved through :pep:`751`.
 
 
 References

From 0750cbef78336297bc2b21a2da0898e9d6c83bc1 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Tue, 15 Apr 2025 12:46:54 -0700
Subject: [PATCH 0941/1072] Apply suggestions from code review
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Filipe Laíns 🇵🇸 
---
 .../specifications/dependency-specifiers.rst  |   6 +-
 source/specifications/pylock-toml.rst         | 111 +++++++++++++-----
 2 files changed, 84 insertions(+), 33 deletions(-)

diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst
index c8701b795..62731ffbb 100644
--- a/source/specifications/dependency-specifiers.rst
+++ b/source/specifications/dependency-specifiers.rst
@@ -281,11 +281,11 @@ an error like all other unknown variables.
        ``Darwin Kernel Version 14.5.0: Wed Jul 29 02:18:53 PDT 2015; root:xnu-2782.40.9~2/RELEASE_X86_64``
    * - ``python_version``
      - ``'.'.join(platform.python_version_tuple()[:2])``
-     - Version
+     - :ref:`Version `
      - ``3.4``, ``2.7``
    * - ``python_full_version``
      - :py:func:`platform.python_version()`
-     - Version
+     - :ref:`Version `
      - ``3.4.0``, ``3.5.0b1``
    * - ``implementation_name``
      - :py:data:`sys.implementation.name `
@@ -293,7 +293,7 @@ an error like all other unknown variables.
      - ``cpython``
    * - ``implementation_version``
      - see definition below
-     - Version
+     - :ref:`Version `
      - ``3.4.0``, ``3.5.0b1``
    * - ``extra``
      - An error except when defined by the context interpreting the
diff --git a/source/specifications/pylock-toml.rst b/source/specifications/pylock-toml.rst
index 75449e4d1..24347a95c 100644
--- a/source/specifications/pylock-toml.rst
+++ b/source/specifications/pylock-toml.rst
@@ -60,6 +60,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 
 .. File details
 
+.. _pylock-lock-version:
 ``lock-version``
 ================
 
@@ -74,6 +75,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 - If a tool doesn't support a major version, it MUST raise an error.
 
 
+.. _pylock-environments:
 ``environments``
 ================
 
@@ -86,6 +88,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   understanding.
 
 
+.. _pylock-requires-python:
 ``requires-python``
 ===================
 
@@ -97,6 +100,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   (i.e. the minimum viable Python version for the lock file).
 
 
+.. _pylock-extras:
 ``extras``
 ==========
 
@@ -115,6 +119,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   lock file is, in effect, multi-use even if it only looks to be single-use.
 
 
+.. _pylock-dependency-groups:
 ``dependency-groups``
 =====================
 
@@ -134,6 +139,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   is, in effect, multi-use even if it only looks to be single-use.
 
 
+.. _pylock-default-groups:
 ``default-groups``
 ==================
 
@@ -142,13 +148,14 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 - **Inspiration**: Poetry_, PDM_
 - The name of synthetic dependency groups to represent what should be installed
   by default (e.g. what ``project.dependencies`` implicitly represents).
-- Meant to be used in situations where ``packages.marker`` necessitates such a
+- Meant to be used in situations where :ref:`pylock-packages.marker` necessitates such a
   group to exist.
-- The groups listed by this key SHOULD NOT be listed in ``dependency-groups`` as
+- The groups listed by this key SHOULD NOT be listed in :ref:`pylock-dependency-groups` as
   the groups are not meant to be directly exposed to users by name but instead
   via an installer's UI.
 
 
+.. _pylock-created-by:
 ``created-by``
 ==============
 
@@ -156,12 +163,13 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 - **Required?**: yes
 - **Inspiration**: Tools with their name in their lock file name
 - Records the name of the tool used to create the lock file.
-- Tools MAY use the ``[tool]`` table to record enough details that it can be
+- Tools MAY use the :ref:`pylock-tool` table to record enough details that it can be
   inferred what inputs were used to create the lock file.
 - Tools SHOULD record the normalized name of the tool if it is available as a
   Python package to facilitate finding the tool.
 
 
+.. _pylock-packages:
 ``[[packages]]``
 ================
 
@@ -175,6 +183,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 
 .. Identification
 
+.. _pylock-packages-name:
 ``packages.name``
 -----------------
 
@@ -184,6 +193,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 - The name of the package :ref:`normalized `.
 
 
+.. _pylock-packages-version:
 ``packages.version``
 --------------------
 
@@ -202,6 +212,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 
 .. Requirements
 
+.. _pylock-packages-marker:
 ``packages.marker``
 -------------------
 
@@ -213,6 +224,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   which specify when the package should be installed.
 
 
+.. _pylock-packages-requires-python:
 ``packages.requires-python``
 ----------------------------
 
@@ -223,13 +235,14 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   for the package.
 
 
+.. _pylock-packages-dependencies:
 ``[[packages.dependencies]]``
 -----------------------------
 
 - **Type**: array of tables
 - **Required?**: no
 - **Inspiration**: PDM_, Poetry_, uv_
-- Records the other entries in ``[[packages]]`` which are direct dependencies of
+- Records the other entries in :ref:`pylock-packages` which are direct dependencies of
   this package.
 - Each entry is a table which contains the minimum information required to tell
   which other package entry it corresponds to where doing a key-by-key
@@ -243,6 +256,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 
 .. Source
 
+.. _pylock-packages-vcs:
 ``[packages.vcs]``
 -------------------
 
@@ -262,6 +276,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   :ref:`direct URL reference `.
 
 
+.. _pylock-packages-vcs-type:
 ``packages.vcs.type``
 ''''''''''''''''''''''
 
@@ -272,15 +287,17 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 - The type of version control system used.
 
 
+.. _pylock-packages-vcs-url:
 ``packages.vcs.url``
 '''''''''''''''''''''
 
 - **Type**: string
 - **Required?**: if ``path`` is not specified
 - **Inspiration**: :ref:`direct-url-data-structure-vcs`
-- The URL to the source tree.
+- The URL_ to the source tree.
 
 
+.. _pylock-packages-vcs-path:
 ``packages.vcs.path``
 ''''''''''''''''''''''
 
@@ -293,6 +310,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   for portability.
 
 
+.. _pylock-packages-vcs-requested-revision:
 ``packages.vcs.requested-revision``
 ''''''''''''''''''''''''''''''''''''
 
@@ -305,6 +323,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   the repository.
 
 
+.. _pylock-packages-vcs-commit-id:
 ``packages.vcs.commit-id``
 '''''''''''''''''''''''''''
 
@@ -312,11 +331,12 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 - **Required?**: yes
 - **Inspiration**: :ref:`direct-url-data-structure-vcs`
 - The exact commit/revision number that is to be installed.
-- If the VCS supports commit-hash based revision identifiers, such a commit-hash
-  MUST be used as the commit ID in order to reference an immutable version of
+- If the VCS supports commit-hash based revision identifiers, such a commit-hash,
+  it MUST be used as the commit ID in order to reference an immutable version of
   the source code.
 
 
+.. _pylock-packages-vcs-subdirectory:
 ``packages.vcs.subdirectory``
 ''''''''''''''''''''''''''''''
 
@@ -330,12 +350,13 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 - The path MUST be relative to the root of the source tree structure.
 
 
+.. _pylock-packages-directory:
 ``[packages.directory]``
 -------------------------
 
 - **Type**: table
-- **Required?**: no; mutually-exclusive with ``packages.vcs``,
-  ``packages.archive``, ``packages.sdist``, and ``packages.wheels``
+- **Required?**: no; mutually-exclusive with :ref:`pylock-packages-vcs`,
+  :ref:`pylock-packages-archive`, :ref:`pylock-packages-sdist`, and :ref:`pylock-packages.wheels`
 - **Inspiration**: :ref:`direct-url-data-structure-local-directory`
 - Record the local directory details for the
   :ref:`source tree ` it
@@ -347,6 +368,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   :ref:`direct URL reference `.
 
 
+.. _pylock-packages-directory-path:
 ``packages.directory.path``
 ''''''''''''''''''''''''''''
 
@@ -359,6 +381,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   portability.
 
 
+.. _pylock-packages-directory-editable:
 ``packages.directory.editable``
 ''''''''''''''''''''''''''''''''
 
@@ -373,12 +396,14 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   production where it would be treated at read-only).
 
 
+.. _pylock-packages-directory-subdirectory:
 ``packages.directory.subdirectory``
 ''''''''''''''''''''''''''''''''''''
 
 See ``packages.vcs.subdirectory``.
 
 
+.. _pylock-packages-archive:
 ``[packages.archive]``
 -----------------------
 
@@ -395,18 +420,21 @@ See ``packages.vcs.subdirectory``.
   :ref:`direct URL reference `.
 
 
+.. _pylock-packages-archive-url:
 ``packages.archive.url``
 '''''''''''''''''''''''''
 
-See ``packages.vcs.url``.
+See :ref:`pylock-packages-vcs-url`.
 
 
+.. _pylock-packages-archive-path:
 ``packages.archive.path``
 ''''''''''''''''''''''''''
 
-See ``packages.vcs.path``.
+See :ref:`pylock-packages-vcs-path`.
 
 
+.. _pylock-packages-archive-size:
 ``packages.archive.size``
 ''''''''''''''''''''''''''
 
@@ -418,6 +446,7 @@ See ``packages.vcs.path``.
   size is available via the Content-Length_ header from a HEAD_ HTTP request).
 
 
+.. _pylock-packages-archive-upload-time:
 ``packages.archive.upload-time``
 ''''''''''''''''''''''''''''''''
 
@@ -428,6 +457,7 @@ See ``packages.vcs.path``.
 - The date and time MUST be recorded in UTC.
 
 
+.. _pylock-packages-archive-hashes:
 ``[packages.archive.hashes]``
 ''''''''''''''''''''''''''''''
 
@@ -443,12 +473,14 @@ See ``packages.vcs.path``.
   recommended.
 
 
+.. _pylock-packages-archive-subdirectory:
 ``packages.archive.subdirectory``
 ''''''''''''''''''''''''''''''''''
 
-See ``packages.vcs.subdirectory``.
+See :ref:`pylock-packages-vcs-subdirectory`.
 
 
+.. _pylock-packages-index:
 ``packages.index``
 ------------------
 
@@ -464,12 +496,13 @@ See ``packages.vcs.subdirectory``.
   file is no longer valid (e.g. returns a 404 HTTP error code).
 
 
+.. _pylock-packages-sdist:
 ``[packages.sdist]``
 --------------------
 
 - **Type**: table
-- **Required?**: no; mutually-exclusive with ``packages.vcs``,
-  ``packages.directory``, and ``packages.archive``
+- **Required?**: no; mutually-exclusive with :ref:`pylock-packages-vcs`,
+  :ref:`pylock-packages-directory`, and :ref:`pylock-packages-archive`
 - **Inspiration**: uv_
 - Details of a :ref:`source-distribution-format-sdist` for the
   package.
@@ -478,53 +511,60 @@ See ``packages.vcs.subdirectory``.
 - Tools SHOULD provide a way for users to opt in/out of using sdist files.
 
 
+.. _pylock-packages-sdist-name:
 ``packages.sdist.name``
 '''''''''''''''''''''''
 
 - **Type**: string
-- **Required?**: no, not when the last component of ``path``/ ``url`` would be
+- **Required?**: no, not when the last component of :ref:`pylock-sdist-path`/ :ref:`pylock-sdist-url` would be
   the same value
 - **Inspiration**: PDM_, Poetry_, uv_
 - The file name of the :ref:`source-distribution-format-sdist` file.
 
 
+.. _pylock-packages-sdist-upload-time:
 ``packages.sdist.upload-time``
 ''''''''''''''''''''''''''''''
 
-See ``packages.archive.upload-time``.
+See :ref:`pylock-packages-archive-upload-time`.
 
 
+.. _pylock-packages-sdist-url:
 ``packages.sdist.url``
 ''''''''''''''''''''''
 
-See ``packages.archive.url``.
+See :ref:`pylock-packages-archive-url`.
 
 
+.. _pylock-packages-sdist-path:
 ``packages.sdist.path``
 '''''''''''''''''''''''
 
-See ``packages.archive.path``.
+See :ref:`pylock-packages-archive-path`.
 
 
+.. _pylock-packages-sdist-size:
 ``packages.sdist.size``
 '''''''''''''''''''''''
 
-See ``packages.archive.size``.
+See :ref:`pylock-packages-archive-size`.
 
 
+.. _pylock-packages-sdist-hashes:
 ``packages.sdist.hashes``
 '''''''''''''''''''''''''
 
-See ``packages.archive.hashes``.
+See :ref:`pylock-packages-archive-hashes`.
 
 
 
+.. _pylock-packages-wheels:
 ``[[packages.wheels]]``
 -----------------------
 
 - **Type**: array of tables
-- **Required?**: no; mutually-exclusive with ``packages.vcs``,
-  ``packages.directory``, and ``packages.archive``
+- **Required?**: no; mutually-exclusive with :ref:`pylock-packages-vcs`,
+  :ref:`pylock-packages-directory`, and :ref:`pylock-packages-archive`
 - **Inspiration**: PDM_, Poetry_, uv_
 - For recording the wheel files as specified by
   :ref:`  binary-distribution-format` for the package.
@@ -532,46 +572,53 @@ See ``packages.archive.hashes``.
   perspective.
 
 
+.. _pylock-packages-wheels-name:
 ``packages.wheels.name``
 ''''''''''''''''''''''''
 
 - **Type**: string
-- **Required?**: no, not when the last component of ``path``/ ``url`` would be
+- **Required?**: no, not when the last component of :ref:`pylock-wheels-path`/ :ref:`pylock-wheels-url` would be
   the same value
 - **Inspiration**: PDM_, Poetry_, uv_
 - The file name of the :ref:`  binary-distribution-format` file.
 
 
+.. _pylock-packages-wheels-upload-time:
 ``packages.wheels.upload-time``
 '''''''''''''''''''''''''''''''
 
-See ``packages.archive.upload-time``.
+See :ref:`pylock-packages-archive-upload-time`.
 
 
+.. _pylock-packages-wheels-url:
 ``packages.wheels.url``
 '''''''''''''''''''''''
 
-See ``packages.archive.url``.
+See :ref:`pylock-packages-archive-url`.
 
 
+.. _pylock-packages-wheels-path:
 ``packages.wheels.path``
 ''''''''''''''''''''''''
 
-See ``packages.archive.path``.
+See :ref:`pylock-packages-archive-path`.
 
 
+.. _pylock-packages-wheels-size:
 ``packages.wheels.size``
 ''''''''''''''''''''''''
 
-See ``packages.archive.size``.
+See :ref:`pylock-packages-archive-size`.
 
 
+.. _pylock-packages-wheels-hashes:
 ``packages.wheels.hashes``
 ''''''''''''''''''''''''''
 
-See ``packages.archive.hashes``.
+See :ref:`pylock-packages-archive-hashes`.
 
 
+.. _pylock-packages-attestation-identities:
 ``[[packages.attestation-identities]]``
 ---------------------------------------
 
@@ -585,6 +632,7 @@ See ``packages.archive.hashes``.
   :ref:`  index-hosted-attestations`.
 
 
+.. _pylock-packages-attestation-identities-kind:
 ``packages.attestation-identities.kind``
 ''''''''''''''''''''''''''''''''''''''''
 
@@ -594,6 +642,7 @@ See ``packages.archive.hashes``.
 - The unique identity of the Trusted Publisher.
 
 
+.. _pylock-packages.tool:
 ``[packages.tool]``
 -------------------
 
@@ -602,18 +651,19 @@ See ``packages.archive.hashes``.
 - **Inspiration**: :ref:`  pyproject-tool-table`
 - Similar usage as that of the ``[tool]`` table from the
   :ref:`  pyproject-toml-spec`, but at the package version level instead
-  of at the lock file level (which is also available via ``[tool]``).
+  of at the lock file level (which is also available via :ref:`pylock-tool`).
 - Data recorded in the table MUST be disposable (i.e. it MUST NOT affect
   installation).
 
 
+.. _pylock-tool:
 ``[tool]``
 ==========
 
 - **Type**: table
 - **Required?**: no
 - **Inspiration**: :ref:`  pyproject-tool-table`
-- See ``packages.tool``.
+- See :ref:`pylock-packages-tool`.
 
 
 -------
@@ -770,3 +820,4 @@ History
 .. _software bill of materials: https://www.cisa.gov/sbom
 .. _TOML: https://toml.io/
 .. _uv: https://github.com/astral-sh/uv
+.. _URL: https://url.spec.whatwg.org/

From 2f1dc98c3b8231513408681b4c1ef6d3d45ca687 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Tue, 15 Apr 2025 12:48:20 -0700
Subject: [PATCH 0942/1072] Update source/specifications/pylock-toml.rst
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Filipe Laíns 🇵🇸 
---
 source/specifications/pylock-toml.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/source/specifications/pylock-toml.rst b/source/specifications/pylock-toml.rst
index 24347a95c..3418976fc 100644
--- a/source/specifications/pylock-toml.rst
+++ b/source/specifications/pylock-toml.rst
@@ -821,3 +821,4 @@ History
 .. _TOML: https://toml.io/
 .. _uv: https://github.com/astral-sh/uv
 .. _URL: https://url.spec.whatwg.org/
+.. _URL: https://url.spec.whatwg.org/

From 5f4d218b9dc90c17d19b995467825df77d93956e Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Tue, 15 Apr 2025 12:50:17 -0700
Subject: [PATCH 0943/1072] Apply suggestions from code review
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Filipe Laíns 🇵🇸 
---
 source/specifications/pylock-toml.rst | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/source/specifications/pylock-toml.rst b/source/specifications/pylock-toml.rst
index 3418976fc..7fe04898c 100644
--- a/source/specifications/pylock-toml.rst
+++ b/source/specifications/pylock-toml.rst
@@ -480,6 +480,7 @@ See :ref:`pylock-packages-vcs-path`.
 See :ref:`pylock-packages-vcs-subdirectory`.
 
 
+.. _pylock-packages-index:
 .. _pylock-packages-index:
 ``packages.index``
 ------------------
@@ -496,6 +497,7 @@ See :ref:`pylock-packages-vcs-subdirectory`.
   file is no longer valid (e.g. returns a 404 HTTP error code).
 
 
+.. _pylock-packages-sdist:
 .. _pylock-packages-sdist:
 ``[packages.sdist]``
 --------------------
@@ -511,6 +513,7 @@ See :ref:`pylock-packages-vcs-subdirectory`.
 - Tools SHOULD provide a way for users to opt in/out of using sdist files.
 
 
+.. _pylock-packages-sdist-name:
 .. _pylock-packages-sdist-name:
 ``packages.sdist.name``
 '''''''''''''''''''''''
@@ -522,6 +525,7 @@ See :ref:`pylock-packages-vcs-subdirectory`.
 - The file name of the :ref:`source-distribution-format-sdist` file.
 
 
+.. _pylock-packages-sdist-upload-time:
 .. _pylock-packages-sdist-upload-time:
 ``packages.sdist.upload-time``
 ''''''''''''''''''''''''''''''
@@ -529,6 +533,7 @@ See :ref:`pylock-packages-vcs-subdirectory`.
 See :ref:`pylock-packages-archive-upload-time`.
 
 
+.. _pylock-packages-sdist-url:
 .. _pylock-packages-sdist-url:
 ``packages.sdist.url``
 ''''''''''''''''''''''
@@ -536,6 +541,7 @@ See :ref:`pylock-packages-archive-upload-time`.
 See :ref:`pylock-packages-archive-url`.
 
 
+.. _pylock-packages-sdist-path:
 .. _pylock-packages-sdist-path:
 ``packages.sdist.path``
 '''''''''''''''''''''''
@@ -543,6 +549,7 @@ See :ref:`pylock-packages-archive-url`.
 See :ref:`pylock-packages-archive-path`.
 
 
+.. _pylock-packages-sdist-size:
 .. _pylock-packages-sdist-size:
 ``packages.sdist.size``
 '''''''''''''''''''''''
@@ -550,6 +557,7 @@ See :ref:`pylock-packages-archive-path`.
 See :ref:`pylock-packages-archive-size`.
 
 
+.. _pylock-packages-sdist-hashes:
 .. _pylock-packages-sdist-hashes:
 ``packages.sdist.hashes``
 '''''''''''''''''''''''''
@@ -558,6 +566,7 @@ See :ref:`pylock-packages-archive-hashes`.
 
 
 
+.. _pylock-packages-wheels:
 .. _pylock-packages-wheels:
 ``[[packages.wheels]]``
 -----------------------
@@ -572,6 +581,7 @@ See :ref:`pylock-packages-archive-hashes`.
   perspective.
 
 
+.. _pylock-packages-wheels-name:
 .. _pylock-packages-wheels-name:
 ``packages.wheels.name``
 ''''''''''''''''''''''''
@@ -583,6 +593,7 @@ See :ref:`pylock-packages-archive-hashes`.
 - The file name of the :ref:`  binary-distribution-format` file.
 
 
+.. _pylock-packages-wheels-upload-time:
 .. _pylock-packages-wheels-upload-time:
 ``packages.wheels.upload-time``
 '''''''''''''''''''''''''''''''
@@ -590,6 +601,7 @@ See :ref:`pylock-packages-archive-hashes`.
 See :ref:`pylock-packages-archive-upload-time`.
 
 
+.. _pylock-packages-wheels-url:
 .. _pylock-packages-wheels-url:
 ``packages.wheels.url``
 '''''''''''''''''''''''
@@ -597,6 +609,7 @@ See :ref:`pylock-packages-archive-upload-time`.
 See :ref:`pylock-packages-archive-url`.
 
 
+.. _pylock-packages-wheels-path:
 .. _pylock-packages-wheels-path:
 ``packages.wheels.path``
 ''''''''''''''''''''''''
@@ -604,6 +617,7 @@ See :ref:`pylock-packages-archive-url`.
 See :ref:`pylock-packages-archive-path`.
 
 
+.. _pylock-packages-wheels-size:
 .. _pylock-packages-wheels-size:
 ``packages.wheels.size``
 ''''''''''''''''''''''''
@@ -611,6 +625,7 @@ See :ref:`pylock-packages-archive-path`.
 See :ref:`pylock-packages-archive-size`.
 
 
+.. _pylock-packages-wheels-hashes:
 .. _pylock-packages-wheels-hashes:
 ``packages.wheels.hashes``
 ''''''''''''''''''''''''''
@@ -618,6 +633,7 @@ See :ref:`pylock-packages-archive-size`.
 See :ref:`pylock-packages-archive-hashes`.
 
 
+.. _pylock-packages-attestation-identities:
 .. _pylock-packages-attestation-identities:
 ``[[packages.attestation-identities]]``
 ---------------------------------------
@@ -632,6 +648,7 @@ See :ref:`pylock-packages-archive-hashes`.
   :ref:`  index-hosted-attestations`.
 
 
+.. _pylock-packages-attestation-identities-kind:
 .. _pylock-packages-attestation-identities-kind:
 ``packages.attestation-identities.kind``
 ''''''''''''''''''''''''''''''''''''''''
@@ -642,6 +659,7 @@ See :ref:`pylock-packages-archive-hashes`.
 - The unique identity of the Trusted Publisher.
 
 
+.. _pylock-packages.tool:
 .. _pylock-packages.tool:
 ``[packages.tool]``
 -------------------
@@ -656,6 +674,7 @@ See :ref:`pylock-packages-archive-hashes`.
   installation).
 
 
+.. _pylock-tool:
 .. _pylock-tool:
 ``[tool]``
 ==========

From 740354d7f996655fdeb003ab9325a9b012d0a20b Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Tue, 15 Apr 2025 13:36:30 -0700
Subject: [PATCH 0944/1072] Fix and add more references

---
 source/specifications/pylock-toml.rst | 249 +++++++++++++++-----------
 1 file changed, 149 insertions(+), 100 deletions(-)

diff --git a/source/specifications/pylock-toml.rst b/source/specifications/pylock-toml.rst
index 7fe04898c..66eb92a14 100644
--- a/source/specifications/pylock-toml.rst
+++ b/source/specifications/pylock-toml.rst
@@ -61,6 +61,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 .. File details
 
 .. _pylock-lock-version:
+
 ``lock-version``
 ================
 
@@ -76,6 +77,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 
 
 .. _pylock-environments:
+
 ``environments``
 ================
 
@@ -89,6 +91,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 
 
 .. _pylock-requires-python:
+
 ``requires-python``
 ===================
 
@@ -101,6 +104,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 
 
 .. _pylock-extras:
+
 ``extras``
 ==========
 
@@ -114,12 +118,15 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   file).
 - Tools supporting extras MUST also support dependency groups.
 - Tools should explicitly set this key to an empty array to signal that the
-  inputs used to generate the lock file had no extras (e.g. a ``pyproject.toml``
-  file had no ``[project.optional-dependencies]`` table), signalling that the
-  lock file is, in effect, multi-use even if it only looks to be single-use.
+  inputs used to generate the lock file had no extras (e.g. a
+  :ref:`pyproject.toml ` file had no
+  :ref:`[project.optional-dependencies] `
+  table), signalling that the lock file is, in effect, multi-use even if it only
+  looks to be single-use.
 
 
 .. _pylock-dependency-groups:
+
 ``dependency-groups``
 =====================
 
@@ -134,12 +141,14 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   file).
 - Tools supporting dependency groups MUST also support extras.
 - Tools SHOULD explicitly set this key to an empty array to signal that the
-  inputs used to generate the lock file had no dependency groups (e.g. a ``pyproject.toml``
-  file had no ``[dependency-groups]`` table), signalling that the lock file
-  is, in effect, multi-use even if it only looks to be single-use.
+  inputs used to generate the lock file had no dependency groups (e.g. a
+  :ref:`pyproject.toml ` file had no
+  :ref:`[dependency-groups] ` table), signalling that the
+  lock file is, in effect, multi-use even if it only looks to be single-use.
 
 
 .. _pylock-default-groups:
+
 ``default-groups``
 ==================
 
@@ -147,15 +156,18 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 - **Required?**: no; defaults to ``[]``
 - **Inspiration**: Poetry_, PDM_
 - The name of synthetic dependency groups to represent what should be installed
-  by default (e.g. what ``project.dependencies`` implicitly represents).
-- Meant to be used in situations where :ref:`pylock-packages.marker` necessitates such a
-  group to exist.
-- The groups listed by this key SHOULD NOT be listed in :ref:`pylock-dependency-groups` as
-  the groups are not meant to be directly exposed to users by name but instead
-  via an installer's UI.
+  by default (e.g. what
+  :ref:`[project.dependencies] ` implicitly
+  represents).
+- Meant to be used in situations where :ref:`pylock-packages-marker`
+  necessitates such a group to exist.
+- The groups listed by this key SHOULD NOT be listed in
+  :ref:`pylock-dependency-groups` as the groups are not meant to be directly
+  exposed to users by name but instead via an installer's UI.
 
 
 .. _pylock-created-by:
+
 ``created-by``
 ==============
 
@@ -163,13 +175,14 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 - **Required?**: yes
 - **Inspiration**: Tools with their name in their lock file name
 - Records the name of the tool used to create the lock file.
-- Tools MAY use the :ref:`pylock-tool` table to record enough details that it can be
-  inferred what inputs were used to create the lock file.
+- Tools MAY use the :ref:`pylock-tool` table to record enough details that it
+  can be inferred what inputs were used to create the lock file.
 - Tools SHOULD record the normalized name of the tool if it is available as a
   Python package to facilitate finding the tool.
 
 
 .. _pylock-packages:
+
 ``[[packages]]``
 ================
 
@@ -184,6 +197,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 .. Identification
 
 .. _pylock-packages-name:
+
 ``packages.name``
 -----------------
 
@@ -194,6 +208,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 
 
 .. _pylock-packages-version:
+
 ``packages.version``
 --------------------
 
@@ -206,13 +221,13 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   :ref:`wheels ` are specified).
 - The version MUST NOT be included when it cannot be guaranteed to be consistent
   with the code used (i.e. when a
-  :ref:`source tree ` is
-  used).
+  :ref:`source tree ` is used).
 
 
 .. Requirements
 
 .. _pylock-packages-marker:
+
 ``packages.marker``
 -------------------
 
@@ -225,6 +240,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 
 
 .. _pylock-packages-requires-python:
+
 ``packages.requires-python``
 ----------------------------
 
@@ -236,14 +252,15 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 
 
 .. _pylock-packages-dependencies:
+
 ``[[packages.dependencies]]``
 -----------------------------
 
 - **Type**: array of tables
 - **Required?**: no
 - **Inspiration**: PDM_, Poetry_, uv_
-- Records the other entries in :ref:`pylock-packages` which are direct dependencies of
-  this package.
+- Records the other entries in :ref:`pylock-packages` which are direct
+  dependencies of this package.
 - Each entry is a table which contains the minimum information required to tell
   which other package entry it corresponds to where doing a key-by-key
   comparison would find the appropriate package with no ambiguity (e.g. if there
@@ -257,12 +274,14 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 .. Source
 
 .. _pylock-packages-vcs:
+
 ``[packages.vcs]``
 -------------------
 
 - **Type**: table
-- **Required?**: no; mutually-exclusive with ``packages.directory``,
-  ``packages.archive``, ``packages.sdist``, and ``packages.wheels``
+- **Required?**: no; mutually-exclusive with :ref:`pylock-packages-directory`,
+  :ref:`pylock-packages-archive`, :ref:`pylock-packages-sdist`, and
+  :ref:`pylock-packages-wheels`
 - **Inspiration**: :ref:`direct-url-data-structure`
 - Record the version control system details for the
   :ref:`source tree ` it
@@ -277,6 +296,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 
 
 .. _pylock-packages-vcs-type:
+
 ``packages.vcs.type``
 ''''''''''''''''''''''
 
@@ -288,21 +308,23 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 
 
 .. _pylock-packages-vcs-url:
+
 ``packages.vcs.url``
 '''''''''''''''''''''
 
 - **Type**: string
-- **Required?**: if ``path`` is not specified
+- **Required?**: if :ref:`pylock-packages-vcs-path` is not specified
 - **Inspiration**: :ref:`direct-url-data-structure-vcs`
 - The URL_ to the source tree.
 
 
 .. _pylock-packages-vcs-path:
+
 ``packages.vcs.path``
 ''''''''''''''''''''''
 
 - **Type**: string
-- **Required?**: if ``url`` is not specified
+- **Required?**: if :ref:`pylock-packages-vcs-url` is not specified
 - **Inspiration**: :ref:`direct-url-data-structure-vcs`
 - The path to the local directory of the source tree.
 - If a relative path is used it MUST be relative to the location of this file.
@@ -311,6 +333,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 
 
 .. _pylock-packages-vcs-requested-revision:
+
 ``packages.vcs.requested-revision``
 ''''''''''''''''''''''''''''''''''''
 
@@ -324,6 +347,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 
 
 .. _pylock-packages-vcs-commit-id:
+
 ``packages.vcs.commit-id``
 '''''''''''''''''''''''''''
 
@@ -331,12 +355,13 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 - **Required?**: yes
 - **Inspiration**: :ref:`direct-url-data-structure-vcs`
 - The exact commit/revision number that is to be installed.
-- If the VCS supports commit-hash based revision identifiers, such a commit-hash,
-  it MUST be used as the commit ID in order to reference an immutable version of
-  the source code.
+- If the VCS supports commit-hash based revision identifiers, such a
+  commit-hash, it MUST be used as the commit ID in order to reference an
+  immutable version of the source code.
 
 
 .. _pylock-packages-vcs-subdirectory:
+
 ``packages.vcs.subdirectory``
 ''''''''''''''''''''''''''''''
 
@@ -346,17 +371,19 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 - The subdirectory within the
   :ref:`source tree ` where
   the project root of the project is (e.g. the location of the
-  ``pyproject.toml`` file).
+  :ref:`pyproject.toml ` file).
 - The path MUST be relative to the root of the source tree structure.
 
 
 .. _pylock-packages-directory:
+
 ``[packages.directory]``
 -------------------------
 
 - **Type**: table
 - **Required?**: no; mutually-exclusive with :ref:`pylock-packages-vcs`,
-  :ref:`pylock-packages-archive`, :ref:`pylock-packages-sdist`, and :ref:`pylock-packages.wheels`
+  :ref:`pylock-packages-archive`, :ref:`pylock-packages-sdist`, and
+  :ref:`pylock-packages-wheels`
 - **Inspiration**: :ref:`direct-url-data-structure-local-directory`
 - Record the local directory details for the
   :ref:`source tree ` it
@@ -369,6 +396,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 
 
 .. _pylock-packages-directory-path:
+
 ``packages.directory.path``
 ''''''''''''''''''''''''''''
 
@@ -382,6 +410,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 
 
 .. _pylock-packages-directory-editable:
+
 ``packages.directory.editable``
 ''''''''''''''''''''''''''''''''
 
@@ -397,13 +426,15 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 
 
 .. _pylock-packages-directory-subdirectory:
+
 ``packages.directory.subdirectory``
 ''''''''''''''''''''''''''''''''''''
 
-See ``packages.vcs.subdirectory``.
+See :ref:`pylock-packages-vcs-subdirectory`.
 
 
 .. _pylock-packages-archive:
+
 ``[packages.archive]``
 -----------------------
 
@@ -421,6 +452,7 @@ See ``packages.vcs.subdirectory``.
 
 
 .. _pylock-packages-archive-url:
+
 ``packages.archive.url``
 '''''''''''''''''''''''''
 
@@ -428,6 +460,7 @@ See :ref:`pylock-packages-vcs-url`.
 
 
 .. _pylock-packages-archive-path:
+
 ``packages.archive.path``
 ''''''''''''''''''''''''''
 
@@ -435,6 +468,7 @@ See :ref:`pylock-packages-vcs-path`.
 
 
 .. _pylock-packages-archive-size:
+
 ``packages.archive.size``
 ''''''''''''''''''''''''''
 
@@ -447,6 +481,7 @@ See :ref:`pylock-packages-vcs-path`.
 
 
 .. _pylock-packages-archive-upload-time:
+
 ``packages.archive.upload-time``
 ''''''''''''''''''''''''''''''''
 
@@ -458,6 +493,7 @@ See :ref:`pylock-packages-vcs-path`.
 
 
 .. _pylock-packages-archive-hashes:
+
 ``[packages.archive.hashes]``
 ''''''''''''''''''''''''''''''
 
@@ -474,6 +510,7 @@ See :ref:`pylock-packages-vcs-path`.
 
 
 .. _pylock-packages-archive-subdirectory:
+
 ``packages.archive.subdirectory``
 ''''''''''''''''''''''''''''''''''
 
@@ -481,7 +518,7 @@ See :ref:`pylock-packages-vcs-subdirectory`.
 
 
 .. _pylock-packages-index:
-.. _pylock-packages-index:
+
 ``packages.index``
 ------------------
 
@@ -498,7 +535,7 @@ See :ref:`pylock-packages-vcs-subdirectory`.
 
 
 .. _pylock-packages-sdist:
-.. _pylock-packages-sdist:
+
 ``[packages.sdist]``
 --------------------
 
@@ -514,19 +551,20 @@ See :ref:`pylock-packages-vcs-subdirectory`.
 
 
 .. _pylock-packages-sdist-name:
-.. _pylock-packages-sdist-name:
+
 ``packages.sdist.name``
 '''''''''''''''''''''''
 
 - **Type**: string
-- **Required?**: no, not when the last component of :ref:`pylock-sdist-path`/ :ref:`pylock-sdist-url` would be
+- **Required?**: no, not when the last component of
+  :ref:`pylock-packages-sdist-path`/ :ref:`pylock-packages-sdist-url` would be
   the same value
 - **Inspiration**: PDM_, Poetry_, uv_
 - The file name of the :ref:`source-distribution-format-sdist` file.
 
 
 .. _pylock-packages-sdist-upload-time:
-.. _pylock-packages-sdist-upload-time:
+
 ``packages.sdist.upload-time``
 ''''''''''''''''''''''''''''''
 
@@ -534,7 +572,7 @@ See :ref:`pylock-packages-archive-upload-time`.
 
 
 .. _pylock-packages-sdist-url:
-.. _pylock-packages-sdist-url:
+
 ``packages.sdist.url``
 ''''''''''''''''''''''
 
@@ -542,7 +580,7 @@ See :ref:`pylock-packages-archive-url`.
 
 
 .. _pylock-packages-sdist-path:
-.. _pylock-packages-sdist-path:
+
 ``packages.sdist.path``
 '''''''''''''''''''''''
 
@@ -550,7 +588,7 @@ See :ref:`pylock-packages-archive-path`.
 
 
 .. _pylock-packages-sdist-size:
-.. _pylock-packages-sdist-size:
+
 ``packages.sdist.size``
 '''''''''''''''''''''''
 
@@ -558,7 +596,7 @@ See :ref:`pylock-packages-archive-size`.
 
 
 .. _pylock-packages-sdist-hashes:
-.. _pylock-packages-sdist-hashes:
+
 ``packages.sdist.hashes``
 '''''''''''''''''''''''''
 
@@ -567,7 +605,7 @@ See :ref:`pylock-packages-archive-hashes`.
 
 
 .. _pylock-packages-wheels:
-.. _pylock-packages-wheels:
+
 ``[[packages.wheels]]``
 -----------------------
 
@@ -582,19 +620,20 @@ See :ref:`pylock-packages-archive-hashes`.
 
 
 .. _pylock-packages-wheels-name:
-.. _pylock-packages-wheels-name:
+
 ``packages.wheels.name``
 ''''''''''''''''''''''''
 
 - **Type**: string
-- **Required?**: no, not when the last component of :ref:`pylock-wheels-path`/ :ref:`pylock-wheels-url` would be
+- **Required?**: no, not when the last component of
+  :ref:`pylock-packages-wheels-path`/ :ref:`pylock-packages-wheels-url` would be
   the same value
 - **Inspiration**: PDM_, Poetry_, uv_
-- The file name of the :ref:`  binary-distribution-format` file.
+- The file name of the :ref:`binary-distribution-format` file.
 
 
 .. _pylock-packages-wheels-upload-time:
-.. _pylock-packages-wheels-upload-time:
+
 ``packages.wheels.upload-time``
 '''''''''''''''''''''''''''''''
 
@@ -602,7 +641,7 @@ See :ref:`pylock-packages-archive-upload-time`.
 
 
 .. _pylock-packages-wheels-url:
-.. _pylock-packages-wheels-url:
+
 ``packages.wheels.url``
 '''''''''''''''''''''''
 
@@ -610,7 +649,7 @@ See :ref:`pylock-packages-archive-url`.
 
 
 .. _pylock-packages-wheels-path:
-.. _pylock-packages-wheels-path:
+
 ``packages.wheels.path``
 ''''''''''''''''''''''''
 
@@ -618,7 +657,7 @@ See :ref:`pylock-packages-archive-path`.
 
 
 .. _pylock-packages-wheels-size:
-.. _pylock-packages-wheels-size:
+
 ``packages.wheels.size``
 ''''''''''''''''''''''''
 
@@ -626,7 +665,7 @@ See :ref:`pylock-packages-archive-size`.
 
 
 .. _pylock-packages-wheels-hashes:
-.. _pylock-packages-wheels-hashes:
+
 ``packages.wheels.hashes``
 ''''''''''''''''''''''''''
 
@@ -634,7 +673,7 @@ See :ref:`pylock-packages-archive-hashes`.
 
 
 .. _pylock-packages-attestation-identities:
-.. _pylock-packages-attestation-identities:
+
 ``[[packages.attestation-identities]]``
 ---------------------------------------
 
@@ -649,7 +688,7 @@ See :ref:`pylock-packages-archive-hashes`.
 
 
 .. _pylock-packages-attestation-identities-kind:
-.. _pylock-packages-attestation-identities-kind:
+
 ``packages.attestation-identities.kind``
 ''''''''''''''''''''''''''''''''''''''''
 
@@ -659,15 +698,15 @@ See :ref:`pylock-packages-archive-hashes`.
 - The unique identity of the Trusted Publisher.
 
 
-.. _pylock-packages.tool:
-.. _pylock-packages.tool:
+.. _pylock-packages-tool:
+
 ``[packages.tool]``
 -------------------
 
 - **Type**: table
 - **Required?**: no
 - **Inspiration**: :ref:`  pyproject-tool-table`
-- Similar usage as that of the ``[tool]`` table from the
+- Similar usage as that of the :ref:`pylock-tool` table from the
   :ref:`  pyproject-toml-spec`, but at the package version level instead
   of at the lock file level (which is also available via :ref:`pylock-tool`).
 - Data recorded in the table MUST be disposable (i.e. it MUST NOT affect
@@ -675,13 +714,13 @@ See :ref:`pylock-packages-archive-hashes`.
 
 
 .. _pylock-tool:
-.. _pylock-tool:
+
 ``[tool]``
 ==========
 
 - **Type**: table
 - **Required?**: no
-- **Inspiration**: :ref:`  pyproject-tool-table`
+- **Inspiration**: :ref:`pyproject-tool-table`
 - See :ref:`pylock-packages-tool`.
 
 
@@ -746,23 +785,23 @@ a suggestion):
    ``dependency_groups`` for marker evaluation, respectively.
 
    #. ``extras`` SHOULD be set to the empty set by default.
-   #. ``dependency_groups`` SHOULD be the set created from ``default-groups`` by
-      default.
-
-#. Check if the metadata version specified by ``lock-version`` is supported;
-   an error or warning MUST be raised as appropriate.
-#. If ``requires-python`` is specified, check that the environment being
-   installed for meets the requirement; an error MUST be raised if it is not
-   met.
-#. If ``environments`` is specified, check that at least one of the environment
-   marker expressions is satisfied; an error MUST be raised if no expression is
-   satisfied.
-#. For each package listed in ``[[packages]]``:
-
-   #. If ``marker`` is specified, check if it is satisfied; if it isn't,
-      skip to the next package.
-   #. If ``requires-python`` is specified, check if it is satisfied; an error
-      MUST be raised if it isn't.
+   #. ``dependency_groups`` SHOULD be the set created from
+      :ref:`pylock-default-groups` by default.
+
+#. Check if the metadata version specified by :ref:`pylock-lock-version` is
+   supported; an error or warning MUST be raised as appropriate.
+#. If :ref:`pylock-requires-python` is specified, check that the environment
+   being installed for meets the requirement; an error MUST be raised if it is
+   not met.
+#. If :ref:`pylock-environments` is specified, check that at least one of the
+   environment marker expressions is satisfied; an error MUST be raised if no
+   expression is satisfied.
+#. For each package listed in :ref:`pylock-packages`:
+
+   #. If :ref:`pylock-packages-marker` is specified, check if it is satisfied;
+      if it isn't, skip to the next package.
+   #. If :ref:`pylock-packages-requires-python` is specified, check if it is
+      satisfied; an error MUST be raised if it isn't.
    #. Check that no other conflicting instance of the package has been slated to
       be installed; an error about the ambiguity MUST be raised otherwise.
    #. Check that the source of the package is specified appropriately (i.e.
@@ -772,53 +811,63 @@ a suggestion):
 
 #. For each package to be installed:
 
-   - If ``vcs`` is set:
+   - If :ref:`pylock-packages-vcs` is set:
 
-     #. Clone the repository to the commit ID specified in ``commit-id``.
-     #. Build the package, respecting ``subdirectory``.
-     #. Install.
+     #. Clone the repository to the commit ID specified in
+        :ref:`pylock-packages-vcs-commit-id`.
+     #. :ref:`Build ` the package,
+        respecting :ref:`pylock-packages-vcs-subdirectory`.
+     #. :ref:`Install `.
 
-   - Else if ``directory`` is set:
+   - Else if :ref:`pylock-packages-directory` is set:
 
-     #. Build the package, respecting ``subdirectory``.
-     #. Install.
+     #. :ref:`Build ` the package,
+        respecting :ref:`pylock-packages-directory-subdirectory`.
+     #. :ref:`Install `.
 
-   - Else if ``archive`` is set:
+   - Else if :ref:`pylock-packages-archive` is set:
 
      #. Get the file.
-     #. Validate the file size and hash.
-     #. Build the package, respecting ``subdirectory``.
-     #. Install.
+     #. Validate using :ref:`pylock-packages-archive-size` and
+        :ref:`pylock-packages-archive-hashes`.
+     #. :ref:`Build ` the package,
+        respecting :ref:`pylock-packages-archive-subdirectory`.
+     #. :ref:`Install `.
 
-   - Else if there are entries for ``wheels``:
+   - Else if there are entries for :ref:`pylock-packages-wheels`:
 
-     #. Look for the appropriate wheel file based on ``name``; if one is not
-        found then move on to ``sdist`` or an error MUST be raised about a
+     #. Look for the appropriate wheel file based on
+        :ref:`pylock-packages-wheels-name`; if one is not found then move on to
+        :ref:`pylock-packages-sdist` or an error MUST be raised about a
         lack of source for the project.
      #. Get the file:
 
-        - If ``path`` is set, use it.
-        - If ``url`` is set, try to use it; optionally tools MAY use
-          ``packages.index`` or some tool-specific mechanism to download the
-          selected wheel file (tools MUST NOT try to change what wheel file to
-          download based on what's available; what file to install should be
-          determined in an offline fashion for reproducibility).
+        - If :ref:`pylock-packages-wheels-path` is set, use it.
+        - Else if :ref:`pylock-packages-wheels-url` is set, try to use it;
+          optionally tools MAY use :ref:`pylock-packages-index` or some
+          tool-specific mechanism to download the selected wheel file (tools
+          MUST NOT try to change what wheel file to download based on what's
+          available; what file to install should be determined in an offline
+          fashion for reproducibility).
 
-     #. Validate the file size and hash.
-     #. Install.
+     #. Validate using :ref:`pylock-packages-wheels-size` and
+        :ref:`pylock-packages-wheels-hashes`.
+     #. :ref:`Install `.
 
-   - Else if no ``wheel`` file is found or ``sdist`` is solely set:
+   - Else if no :ref:`pylock-packages-wheels` file is found or
+     :ref:`pylock-packages-sdist` is solely set:
 
      #. Get the file.
 
-        - If ``path`` is set, use it.
-        - If ``url`` is set, try to use it; tools MAY use
-          ``packages.index`` or some tool-specific mechanism to download the
-          file.
+        - If :ref:`pylock-packages-sdist-path` is set, use it.
+        - Else if :ref:`pylock-packages-sdist-url` is set, try to use it; tools
+          MAY use :ref:`pylock-packages-index` or some tool-specific mechanism
+          to download the file.
 
-     #. Validate the file size and hash.
-     #. Build the package.
-     #. Install.
+     #. Validate using :ref:`pylock-packages-sdist-size` and
+        :ref:`pylock-packages-sdist-hashes`.
+     #. :ref:`Build ` the package.
+     #. :ref:`Install `.
 
 
 -------

From 95f181f26423a24ae9cf1810dfd96160f84d0d09 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Wed, 16 Apr 2025 13:36:03 -0700
Subject: [PATCH 0945/1072] Move `pylock.toml` example to an external file
 Along the way, ignore a troublesome URL that's slowing down link checking
 significantly.

---
 source/conf.py                                |  1 +
 source/specifications/pylock-toml.rst         | 48 +--------------
 .../pylock-toml/pylock.example.toml           | 60 +++++++++++++++++++
 3 files changed, 64 insertions(+), 45 deletions(-)
 create mode 100644 source/specifications/pylock-toml/pylock.example.toml

diff --git a/source/conf.py b/source/conf.py
index b3ebd0502..321d07f2b 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -149,6 +149,7 @@
     "https://stackoverflow.com/*",
     "https://pyscaffold.org/*",
     "https://anaconda.org",
+    "https://www.cisa.gov/sbom",
 ]
 linkcheck_retries = 5
 # Ignore anchors for common targets when we know they likely won't be found
diff --git a/source/specifications/pylock-toml.rst b/source/specifications/pylock-toml.rst
index 66eb92a14..3208874ed 100644
--- a/source/specifications/pylock-toml.rst
+++ b/source/specifications/pylock-toml.rst
@@ -728,49 +728,7 @@ See :ref:`pylock-packages-archive-hashes`.
 Example
 -------
 
-.. code-block:: TOML
-
-  lock-version = '1.0'
-  environments = ["sys_platform == 'win32'", "sys_platform == 'linux'"]
-  requires-python = '==3.12'
-  created-by = 'mousebender'
-
-  [[packages]]
-  name = 'attrs'
-  version = '25.1.0'
-  requires-python = '>=3.8'
-  wheels = [
-    {name = 'attrs-25.1.0-py3-none-any.whl', upload-time = 2025-01-25T11:30:10.164985+00:00, url = 'https://files.pythonhosted.org/packages/fc/30/d4986a882011f9df997a55e6becd864812ccfcd821d64aac8570ee39f719/attrs-25.1.0-py3-none-any.whl', size = 63152, hashes = {sha256 = 'c75a69e28a550a7e93789579c22aa26b0f5b83b75dc4e08fe092980051e1090a'}},
-  ]
-  [[packages.attestation-identities]]
-  environment = 'release-pypi'
-  kind = 'GitHub'
-  repository = 'python-attrs/attrs'
-  workflow = 'pypi-package.yml'
-
-  [[packages]]
-  name = 'cattrs'
-  version = '24.1.2'
-  requires-python = '>=3.8'
-  dependencies = [
-      {name = 'attrs'},
-  ]
-  wheels = [
-    {name = 'cattrs-24.1.2-py3-none-any.whl', upload-time = 2024-09-22T14:58:34.812643+00:00, url = 'https://files.pythonhosted.org/packages/c8/d5/867e75361fc45f6de75fe277dd085627a9db5ebb511a87f27dc1396b5351/cattrs-24.1.2-py3-none-any.whl', size = 66446, hashes = {sha256 = '67c7495b760168d931a10233f979b28dc04daf853b30752246f4f8471c6d68d0'}},
-  ]
-
-  [[packages]]
-  name = 'numpy'
-  version = '2.2.3'
-  requires-python = '>=3.10'
-  wheels = [
-    {name = 'numpy-2.2.3-cp312-cp312-win_amd64.whl', upload-time = 2025-02-13T16:51:21.821880+00:00, url = 'https://files.pythonhosted.org/packages/42/6e/55580a538116d16ae7c9aa17d4edd56e83f42126cb1dfe7a684da7925d2c/numpy-2.2.3-cp312-cp312-win_amd64.whl', size = 12626357, hashes = {sha256 = '83807d445817326b4bcdaaaf8e8e9f1753da04341eceec705c001ff342002e5d'}},
-    {name = 'numpy-2.2.3-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl', upload-time = 2025-02-13T16:50:00.079662+00:00, url = 'https://files.pythonhosted.org/packages/39/04/78d2e7402fb479d893953fb78fa7045f7deb635ec095b6b4f0260223091a/numpy-2.2.3-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl', size = 16116679, hashes = {sha256 = '3b787adbf04b0db1967798dba8da1af07e387908ed1553a0d6e74c084d1ceafe'}},
-  ]
-
-  [tool.mousebender]
-  command = ['.', 'lock', '--platform', 'cpython3.12-windows-x64', '--platform', 'cpython3.12-manylinux2014-x64', 'cattrs', 'numpy']
-  run-on = 2025-03-06T12:28:57.760769
+.. literalinclude:: pylock-toml/pylock.example.toml
 
 
 ------------
@@ -882,11 +840,11 @@ History
 .. _HEAD: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/HEAD
 .. _PDM: https://pypi.org/project/pdm/
 .. _pip-tools: https://pypi.org/project/pip-tools/
-.. _Poetry: https://python-poetry.org/
+.. _Poetry: https://pypi.org/project/poetry/
 .. _requirements file:
 .. _requirements files: https://pip.pypa.io/en/stable/reference/requirements-file-format/
 .. _software bill of materials: https://www.cisa.gov/sbom
 .. _TOML: https://toml.io/
-.. _uv: https://github.com/astral-sh/uv
+.. _uv: https://pypi.org/project/uv/
 .. _URL: https://url.spec.whatwg.org/
 .. _URL: https://url.spec.whatwg.org/
diff --git a/source/specifications/pylock-toml/pylock.example.toml b/source/specifications/pylock-toml/pylock.example.toml
new file mode 100644
index 000000000..60982f1d3
--- /dev/null
+++ b/source/specifications/pylock-toml/pylock.example.toml
@@ -0,0 +1,60 @@
+lock-version = '1.0'
+environments = ["sys_platform == 'win32'", "sys_platform == 'linux'"]
+requires-python = '==3.12'
+created-by = 'mousebender'
+
+[[packages]]
+name = 'attrs'
+version = '25.1.0'
+requires-python = '>=3.8'
+
+    [[packages.wheels]]
+    name = 'attrs-25.1.0-py3-none-any.whl'
+    upload-time = 2025-01-25T11:30:10.164985+00:00
+    url = 'https://files.pythonhosted.org/packages/fc/30/d4986a882011f9df997a55e6becd864812ccfcd821d64aac8570ee39f719/attrs-25.1.0-py3-none-any.whl'
+    size = 63152
+    hashes = {sha256 = 'c75a69e28a550a7e93789579c22aa26b0f5b83b75dc4e08fe092980051e1090a'}
+
+    [[packages.attestation-identities]]
+    environment = 'release-pypi'
+    kind = 'GitHub'
+    repository = 'python-attrs/attrs'
+    workflow = 'pypi-package.yml'
+
+[[packages]]
+name = 'cattrs'
+version = '24.1.2'
+requires-python = '>=3.8'
+dependencies = [
+    {name = 'attrs'},
+]
+
+    [[packages.wheels]]
+    name = 'cattrs-24.1.2-py3-none-any.whl'
+    upload-time = 2024-09-22T14:58:34.812643+00:00
+    url = 'https://files.pythonhosted.org/packages/c8/d5/867e75361fc45f6de75fe277dd085627a9db5ebb511a87f27dc1396b5351/cattrs-24.1.2-py3-none-any.whl'
+    size = 66446
+    hashes = {sha256 = '67c7495b760168d931a10233f979b28dc04daf853b30752246f4f8471c6d68d0'}
+
+[[packages]]
+name = 'numpy'
+version = '2.2.3'
+requires-python = '>=3.10'
+
+    [[packages.wheels]]
+    name = 'numpy-2.2.3-cp312-cp312-win_amd64.whl'
+    upload-time = 2025-02-13T16:51:21.821880+00:00
+    url = 'https://files.pythonhosted.org/packages/42/6e/55580a538116d16ae7c9aa17d4edd56e83f42126cb1dfe7a684da7925d2c/numpy-2.2.3-cp312-cp312-win_amd64.whl'
+    size = 12626357
+    hashes = {sha256 = '83807d445817326b4bcdaaaf8e8e9f1753da04341eceec705c001ff342002e5d'}
+
+    [[packages.wheels]]
+    name = 'numpy-2.2.3-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl'
+    upload-time = 2025-02-13T16:50:00.079662+00:00
+    url = 'https://files.pythonhosted.org/packages/39/04/78d2e7402fb479d893953fb78fa7045f7deb635ec095b6b4f0260223091a/numpy-2.2.3-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl'
+    size = 16116679
+    hashes = {sha256 = '3b787adbf04b0db1967798dba8da1af07e387908ed1553a0d6e74c084d1ceafe'}
+
+[tool.mousebender]
+command = ['.', 'lock', '--platform', 'cpython3.12-windows-x64', '--platform', 'cpython3.12-manylinux2014-x64', 'cattrs', 'numpy']
+run-on = 2025-03-06T12:28:57.760769

From b63bf5a83f847e19ff376aa3db0fa4249ec83a5c Mon Sep 17 00:00:00 2001
From: Ee Durbin 
Date: Thu, 17 Apr 2025 13:45:16 -0400
Subject: [PATCH 0946/1072] remove plausible.io

we're going to be migrating to self-hosted plausbile entirely now.

drop plausible.io script, and enable outbound links
---
 source/conf.py | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/source/conf.py b/source/conf.py
index b3ebd0502..bda71103a 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -73,11 +73,7 @@
 
 _metrics_js_files = [
     (
-        "https://plausible.io/js/script.js",
-        {"data-domain": "packaging.python.org", "defer": "defer"},
-    ),
-    (
-        "https://analytics.python.org/js/script.js",
+        "https://analytics.python.org/js/script.outbound-links.js",
         {"data-domain": "packaging.python.org", "defer": "defer"},
     ),
 ]

From 5fcf8fad9aee32c083198e7fbb0730f641dce790 Mon Sep 17 00:00:00 2001
From: shenxianpeng 
Date: Mon, 21 Apr 2025 16:03:30 +0300
Subject: [PATCH 0947/1072] docs: fix installing-packages.rst

---
 source/tutorials/installing-packages.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst
index 817148d06..afe51c941 100644
--- a/source/tutorials/installing-packages.rst
+++ b/source/tutorials/installing-packages.rst
@@ -228,8 +228,8 @@ Currently, there are two common tools for creating Python virtual environments:
   (Python versions prior to 3.12 also installed :ref:`setuptools`).
 * :ref:`virtualenv` needs to be installed separately, but supports Python 2.7+
   and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are
-  always installed into created virtual environments by default (regardless of
-  Python version).
+  installed into created virtual environments by default. Note that ``setuptools`` is no longer 
+  included by default starting with Python 3.12 (and ``virtualenv`` follows this behavior).
 
 The basic usage is like so:
 

From 77d04bf0880fb6fad515ebbb9d9200fba29bac22 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 21 Apr 2025 13:05:04 +0000
Subject: [PATCH 0948/1072] [pre-commit.ci] auto fixes from pre-commit.com
 hooks

for more information, see https://pre-commit.ci
---
 source/tutorials/installing-packages.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst
index afe51c941..3a9aa23bb 100644
--- a/source/tutorials/installing-packages.rst
+++ b/source/tutorials/installing-packages.rst
@@ -228,7 +228,7 @@ Currently, there are two common tools for creating Python virtual environments:
   (Python versions prior to 3.12 also installed :ref:`setuptools`).
 * :ref:`virtualenv` needs to be installed separately, but supports Python 2.7+
   and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are
-  installed into created virtual environments by default. Note that ``setuptools`` is no longer 
+  installed into created virtual environments by default. Note that ``setuptools`` is no longer
   included by default starting with Python 3.12 (and ``virtualenv`` follows this behavior).
 
 The basic usage is like so:

From 4bb1a536de94bbe89b4eb86bc424e8595f6115d7 Mon Sep 17 00:00:00 2001
From: Seth Michael Larson 
Date: Thu, 24 Apr 2025 07:51:52 -0500
Subject: [PATCH 0949/1072] Add PEP 770 to specifications

---
 .../binary-distribution-format.rst            | 20 +++++++++++++++++++
 .../recording-installed-packages.rst          | 12 ++++++++++-
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst
index 4d94e1052..38d80163e 100644
--- a/source/specifications/binary-distribution-format.rst
+++ b/source/specifications/binary-distribution-format.rst
@@ -253,6 +253,20 @@ The .dist-info directory
    installation will fail if any file in the archive is not both
    mentioned and correctly hashed in RECORD.
 
+Subdirectories in :file:`.dist-info/`
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Subdirectories under `.dist-info` are reserved for future use.
+The following subdirectory names under `.dist-info` are reserved for specific usage:
+
+================= ==============
+Subdirectory name PEP / Standard
+================= ==============
+``licenses``      :pep:`639`
+``license_files`` :pep:`639`
+``LICENSES``      `REUSE licensing framework `__
+``sboms``         :pep:`770`
+================= ==============
 
 The :file:`.dist-info/licenses/` directory
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -263,6 +277,12 @@ fields is specified, the :file:`.dist-info/` directory MUST contain a
 ``License-File`` fields in the :file:`METADATA` file at their respective paths
 relative to the :file:`licenses/` directory.
 
+The :file:`.dist-info/sboms/` directory
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+All files contained within the :file:`.dist-info/sboms` directory MUST
+be Software Bill-of-Materials (SBOM) files that describe software contained
+within the distribution archive.
 
 The .data directory
 ^^^^^^^^^^^^^^^^^^^
diff --git a/source/specifications/recording-installed-packages.rst b/source/specifications/recording-installed-packages.rst
index 9e01ef6f1..c750fd03e 100644
--- a/source/specifications/recording-installed-packages.rst
+++ b/source/specifications/recording-installed-packages.rst
@@ -66,10 +66,11 @@ The ``METADATA`` file is mandatory.
 All other files may be omitted at the installing tool's discretion.
 Additional installer-specific files may be present.
 
-This :file:`.dist-info/` directory may contain the following directory, described in
+This :file:`.dist-info/` directory may contain the following directories, described in
 detail below:
 
 * :file:`licenses/`: contains license files.
+* :file:`sboms/`: contains Software Bill-of-Materials files (SBOMs).
 
 .. note::
 
@@ -235,6 +236,15 @@ the :file:`METADATA` file at their respective paths relative to the
 Any files in this directory MUST be copied from wheels by the install tools.
 
 
+The :file:`sboms/` subdirectory
+==================================
+
+All files contained within the :file:`.dist-info/sboms` directory MUST
+be Software Bill-of-Materials (SBOM) files that describe software contained
+within the installed package.
+Any files in this directory MUST be copied from wheels by the install tools.
+
+
 Intentionally preventing changes to installed packages
 ======================================================
 

From cd5925c5e55de12e649f533103191db9065930ff Mon Sep 17 00:00:00 2001
From: Seth Michael Larson 
Date: Thu, 24 Apr 2025 09:06:35 -0500
Subject: [PATCH 0950/1072] Fix reference issue

---
 source/specifications/binary-distribution-format.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst
index 38d80163e..f9bd4b1d5 100644
--- a/source/specifications/binary-distribution-format.rst
+++ b/source/specifications/binary-distribution-format.rst
@@ -256,8 +256,8 @@ The .dist-info directory
 Subdirectories in :file:`.dist-info/`
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Subdirectories under `.dist-info` are reserved for future use.
-The following subdirectory names under `.dist-info` are reserved for specific usage:
+Subdirectories under :file:`.dist-info` are reserved for future use.
+The following subdirectory names under :file:`.dist-info` are reserved for specific usage:
 
 ================= ==============
 Subdirectory name PEP / Standard

From cff79d775af203ed023102fd365e31357e5ddf22 Mon Sep 17 00:00:00 2001
From: Seth Michael Larson 
Date: Sat, 26 Apr 2025 11:32:43 -0500
Subject: [PATCH 0951/1072] Apply suggestions from code review
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: 🇺🇦 Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/specifications/binary-distribution-format.rst   | 6 +++---
 source/specifications/recording-installed-packages.rst | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/source/specifications/binary-distribution-format.rst b/source/specifications/binary-distribution-format.rst
index f9bd4b1d5..8bb41ab40 100644
--- a/source/specifications/binary-distribution-format.rst
+++ b/source/specifications/binary-distribution-format.rst
@@ -256,8 +256,8 @@ The .dist-info directory
 Subdirectories in :file:`.dist-info/`
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Subdirectories under :file:`.dist-info` are reserved for future use.
-The following subdirectory names under :file:`.dist-info` are reserved for specific usage:
+Subdirectories under :file:`.dist-info/` are reserved for future use.
+The following subdirectory names under :file:`.dist-info/` are reserved for specific usage:
 
 ================= ==============
 Subdirectory name PEP / Standard
@@ -280,7 +280,7 @@ relative to the :file:`licenses/` directory.
 The :file:`.dist-info/sboms/` directory
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-All files contained within the :file:`.dist-info/sboms` directory MUST
+All files contained within the :file:`.dist-info/sboms/` directory MUST
 be Software Bill-of-Materials (SBOM) files that describe software contained
 within the distribution archive.
 
diff --git a/source/specifications/recording-installed-packages.rst b/source/specifications/recording-installed-packages.rst
index c750fd03e..a689fa7fd 100644
--- a/source/specifications/recording-installed-packages.rst
+++ b/source/specifications/recording-installed-packages.rst
@@ -239,7 +239,7 @@ Any files in this directory MUST be copied from wheels by the install tools.
 The :file:`sboms/` subdirectory
 ==================================
 
-All files contained within the :file:`.dist-info/sboms` directory MUST
+All files contained within the :file:`.dist-info/sboms/` directory MUST
 be Software Bill-of-Materials (SBOM) files that describe software contained
 within the installed package.
 Any files in this directory MUST be copied from wheels by the install tools.

From b56b6c7c81fa36f9382f4ecc1b5cdfc2f05a28e3 Mon Sep 17 00:00:00 2001
From: Ned Batchelder 
Date: Thu, 1 May 2025 13:25:53 +0000
Subject: [PATCH 0952/1072] minor copy-editing fixes

---
 source/contribute.rst                                     | 2 +-
 source/discussions/deploying-python-applications.rst      | 2 +-
 source/discussions/pip-vs-easy-install.rst                | 2 +-
 source/discussions/versioning.rst                         | 6 +++---
 source/glossary.rst                                       | 2 +-
 source/guides/creating-command-line-tools.rst             | 8 ++++----
 .../installing-using-pip-and-virtual-environments.rst     | 2 +-
 source/index.rst                                          | 2 +-
 source/specifications/source-distribution-format.rst      | 4 ++--
 source/specifications/version-specifiers.rst              | 2 +-
 10 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/source/contribute.rst b/source/contribute.rst
index 95d127837..cf5314b8d 100644
--- a/source/contribute.rst
+++ b/source/contribute.rst
@@ -11,7 +11,7 @@ including:
 * Reviewing new contributions
 * Revising existing content
 * Writing new content
-* Translate the guide
+* Translating the guide
 
 Most of the work on the |PyPUG| takes place on the
 `project's GitHub repository`__. To get started, check out the list of
diff --git a/source/discussions/deploying-python-applications.rst b/source/discussions/deploying-python-applications.rst
index 19ecd398e..e10f36f9c 100644
--- a/source/discussions/deploying-python-applications.rst
+++ b/source/discussions/deploying-python-applications.rst
@@ -23,7 +23,7 @@ Supporting multiple hardware platforms
   For Python-only distributions, it *should* be straightforward to deploy on all
   platforms where Python can run.
 
-  For distributions with binary extensions, deployment is major headache.  Not only
+  For distributions with binary extensions, deployment is a major headache.  Not only
   must the extensions be built on all the combinations of operating system and
   hardware platform, but they must also be tested, preferably on continuous
   integration platforms.  The issues are similar to the "multiple Python
diff --git a/source/discussions/pip-vs-easy-install.rst b/source/discussions/pip-vs-easy-install.rst
index 4fa590cf3..2bb75d3be 100644
--- a/source/discussions/pip-vs-easy-install.rst
+++ b/source/discussions/pip-vs-easy-install.rst
@@ -11,7 +11,7 @@ It was notable at the time for installing :term:`packages 
 :term:`PyPI ` using requirement specifiers, and
 automatically installing dependencies.
 
-:ref:`pip` came later in 2008, as alternative to :ref:`easy_install `, although still
+:ref:`pip` came later in 2008, as an alternative to :ref:`easy_install `, although still
 largely built on top of :ref:`setuptools` components.  It was notable at the
 time for *not* installing packages as :term:`Eggs ` or from :term:`Eggs ` (but
 rather simply as 'flat' packages from :term:`sdists `_
@@ -148,7 +148,7 @@ user, as serial version numbers convey little or no information regarding API
 backwards compatibility.
 
 Combinations of the above schemes are possible. For example, a project may
-combine date based versioning with serial versioning to create a *year.serial*
+combine date-based versioning with serial versioning to create a *year.serial*
 numbering scheme that readily conveys the approximate age of a release, but
 doesn't otherwise commit to a particular release cadence within the year.
 
diff --git a/source/glossary.rst b/source/glossary.rst
index 6a592125f..73a192daa 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -291,7 +291,7 @@ Glossary
         `_, and discuss issues on the
         `distutils-sig mailing list
         `_
-	and `the Python Discourse forum `__.
+	and `the Python Discourse forum `_.
 
 
     Python Package Index (PyPI)
diff --git a/source/guides/creating-command-line-tools.rst b/source/guides/creating-command-line-tools.rst
index 49ce0c9ed..8266fffdb 100644
--- a/source/guides/creating-command-line-tools.rst
+++ b/source/guides/creating-command-line-tools.rst
@@ -5,7 +5,7 @@ Creating and packaging command-line tools
 =========================================
 
 This guide will walk you through creating and packaging a standalone command-line application
-that can be installed with :ref:`pipx`, a tool creating and managing :term:`Python Virtual Environments `
+that can be installed with :ref:`pipx`, a tool for creating and managing :term:`Python Virtual Environments `
 and exposing the executable scripts of packages (and available manual pages) for use on the command-line.
 
 Creating the package
@@ -98,7 +98,7 @@ Now, add an empty :file:`__init__.py` file, to define the project as a regular :
 
 The file :file:`__main__.py` marks the main entry point for the application when running it via :mod:`runpy`
 (i.e. ``python -m greetings``, which works immediately with flat layout, but requires installation of the package with src layout),
-so initizalize the command-line interface here:
+so initialize the command-line interface here:
 
 .. code-block:: python
 
@@ -162,7 +162,7 @@ To just run the program without installing it permanently, use ``pipx run``, whi
 
 	$ pipx run --spec . greet --knight
 
-This syntax is a bit unpractical, however; as the name of the entry point we defined above does not match the package name,
+This syntax is a bit impractical, however; as the name of the entry point we defined above does not match the package name,
 we need to state explicitly which executable script to run (even though there is only on in existence).
 
 There is, however, a more practical solution to this problem, in the form of an entry point specific to ``pipx run``.
@@ -184,7 +184,7 @@ default one and run it, which makes this command possible:
 Conclusion
 ==========
 
-You know by now how to package a command-line application written in Python. A further step could be to distribute you package,
+You know by now how to package a command-line application written in Python. A further step could be to distribute your package,
 meaning uploading it to a :term:`package index `, most commonly :term:`PyPI `. To do that, follow the instructions at :ref:`Packaging your project`. And once you're done, don't forget to :ref:`do some research ` on how your package is received!
 
 .. _click: https://click.palletsprojects.com/
diff --git a/source/guides/installing-using-pip-and-virtual-environments.rst b/source/guides/installing-using-pip-and-virtual-environments.rst
index 64fdf9382..22d1840cc 100644
--- a/source/guides/installing-using-pip-and-virtual-environments.rst
+++ b/source/guides/installing-using-pip-and-virtual-environments.rst
@@ -200,7 +200,7 @@ When your virtual environment is activated, you can install packages. Use the
 Install a package
 ~~~~~~~~~~~~~~~~~
 
-For example,let's install the
+For example, let's install the
 `Requests`_ library from the :term:`Python Package Index (PyPI)`:
 
 .. tab:: Unix/macOS
diff --git a/source/index.rst b/source/index.rst
index 32f85b206..aa522c8c5 100644
--- a/source/index.rst
+++ b/source/index.rst
@@ -79,7 +79,7 @@ topics.
 Explanations and Discussions
 ============================
 
-The :doc:`discussions/index` section for in-depth explanations and discussion
+The :doc:`discussions/index` section provides in-depth explanations and discussion
 about topics, such as:
 
 * :doc:`discussions/deploying-python-applications`
diff --git a/source/specifications/source-distribution-format.rst b/source/specifications/source-distribution-format.rst
index 7006511b9..9ac93be7b 100644
--- a/source/specifications/source-distribution-format.rst
+++ b/source/specifications/source-distribution-format.rst
@@ -5,7 +5,7 @@
 Source distribution format
 ==========================
 
-The current standard format of source distribution format is identified by the
+The current standard source distribution format is identified by the
 presence of a :file:`pyproject.toml` file in the distribution archive.  The layout
 of such a distribution was originally specified in :pep:`517` and is formally
 documented here.
@@ -27,7 +27,7 @@ Source trees
 
 A *source tree* is a collection of files and directories -- like a version
 control system checkout -- which contains a :file:`pyproject.toml` file that
-can be use to build a source distribution from the contained files and
+can be used to build a source distribution from the contained files and
 directories. :pep:`517` and :pep:`518` specify what is required to meet the
 definition of what :file:`pyproject.toml` must contain for something to be
 deemed a source tree.
diff --git a/source/specifications/version-specifiers.rst b/source/specifications/version-specifiers.rst
index d18596ee0..1f89ce115 100644
--- a/source/specifications/version-specifiers.rst
+++ b/source/specifications/version-specifiers.rst
@@ -226,7 +226,7 @@ part of the ``3.3`` release series.
    form to ``X.Y.0`` when comparing it to any release segment that includes
    three components.
 
-Date based release segments are also permitted. An example of a date based
+Date-based release segments are also permitted. An example of a date-based
 release scheme using the year and month of the release::
 
     2012.4

From be0e85f74e6f8892c74c5c67f0e7dde872dfc1ee Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Fri, 2 May 2025 15:30:25 -0700
Subject: [PATCH 0953/1072] Apply suggestions from code review
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: 🇺🇦 Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/specifications/pylock-toml.rst | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/source/specifications/pylock-toml.rst b/source/specifications/pylock-toml.rst
index 3208874ed..6f39af663 100644
--- a/source/specifications/pylock-toml.rst
+++ b/source/specifications/pylock-toml.rst
@@ -31,18 +31,18 @@ The expectation is that services that automatically install from lock files will
 search for:
 
 1. The lock file with the service's name and doing the default install
-2. A multi-use ``pylock.toml`` with a dependency group with the name of the service
-3. The default install of ``pylock.toml``
+2. A multi-use :file:`pylock.toml` with a dependency group with the name of the service
+3. The default install of :file:`pylock.toml`
 
 E.g. a cloud host service named "spam" would first look for
-``pylock.spam.toml`` to install from, and if that file didn't exist then install
-from ``pylock.toml`` and look for a dependency group named "spam" to use if
+:file:`pylock.spam.toml` to install from, and if that file didn't exist then install
+from :file:`pylock.toml` and look for a dependency group named "spam" to use if
 present.
 
 The lock file(s) SHOULD be located in the directory as appropriate for the scope
-of the lock file. Locking against a single ``pyproject.toml``, for instance,
-would place the ``pylock.toml`` in the same directory. If the lock file covered
-multiple projects in a monorepo, then the expectation is the ``pylock.toml``
+of the lock file. Locking against a single :file:`pyproject.toml`, for instance,
+would place the :file:`pylock.toml` in the same directory. If the lock file covered
+multiple projects in a monorepo, then the expectation is the :file:`pylock.toml`
 file would be in the directory that held all the projects being locked.
 
 
@@ -54,7 +54,7 @@ The format of the file is TOML_.
 
 Tools SHOULD write their lock files in a consistent way to minimize noise in
 diff output. Keys in tables -- including the top-level table -- SHOULD be
-recorded in a consistent order (if inspiration is desired, this PEP has tried to
+recorded in a consistent order (if inspiration is desired, this specification has tried to
 write down keys in a logical order). As well, tools SHOULD sort arrays in
 consistent order. Usage of inline tables SHOULD also be kept consistent.
 

From 7c3629a5b0e4e2de9b6951a0924d8db7a18aa08d Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Fri, 2 May 2025 15:56:38 -0700
Subject: [PATCH 0954/1072] Make section underlines not go over

---
 source/specifications/pylock-toml.rst | 32 +++++++++++++--------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/source/specifications/pylock-toml.rst b/source/specifications/pylock-toml.rst
index 6f39af663..fdd3ed5a0 100644
--- a/source/specifications/pylock-toml.rst
+++ b/source/specifications/pylock-toml.rst
@@ -276,7 +276,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 .. _pylock-packages-vcs:
 
 ``[packages.vcs]``
--------------------
+------------------
 
 - **Type**: table
 - **Required?**: no; mutually-exclusive with :ref:`pylock-packages-directory`,
@@ -298,7 +298,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 .. _pylock-packages-vcs-type:
 
 ``packages.vcs.type``
-''''''''''''''''''''''
+'''''''''''''''''''''
 
 - **Type**: string; supported values specified in
   :ref:`direct-url-data-structure-registered-vcs`
@@ -310,7 +310,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 .. _pylock-packages-vcs-url:
 
 ``packages.vcs.url``
-'''''''''''''''''''''
+''''''''''''''''''''
 
 - **Type**: string
 - **Required?**: if :ref:`pylock-packages-vcs-path` is not specified
@@ -321,7 +321,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 .. _pylock-packages-vcs-path:
 
 ``packages.vcs.path``
-''''''''''''''''''''''
+'''''''''''''''''''''
 
 - **Type**: string
 - **Required?**: if :ref:`pylock-packages-vcs-url` is not specified
@@ -335,7 +335,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 .. _pylock-packages-vcs-requested-revision:
 
 ``packages.vcs.requested-revision``
-''''''''''''''''''''''''''''''''''''
+'''''''''''''''''''''''''''''''''''
 
 - **Type**: string
 - **Required?**: no
@@ -349,7 +349,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 .. _pylock-packages-vcs-commit-id:
 
 ``packages.vcs.commit-id``
-'''''''''''''''''''''''''''
+''''''''''''''''''''''''''
 
 - **Type**: string
 - **Required?**: yes
@@ -363,7 +363,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 .. _pylock-packages-vcs-subdirectory:
 
 ``packages.vcs.subdirectory``
-''''''''''''''''''''''''''''''
+'''''''''''''''''''''''''''''
 
 - **Type**: string
 - **Required?**: no
@@ -378,7 +378,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 .. _pylock-packages-directory:
 
 ``[packages.directory]``
--------------------------
+------------------------
 
 - **Type**: table
 - **Required?**: no; mutually-exclusive with :ref:`pylock-packages-vcs`,
@@ -398,7 +398,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 .. _pylock-packages-directory-path:
 
 ``packages.directory.path``
-''''''''''''''''''''''''''''
+'''''''''''''''''''''''''''
 
 - **Type**: string
 - **Required?**: yes
@@ -412,7 +412,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 .. _pylock-packages-directory-editable:
 
 ``packages.directory.editable``
-''''''''''''''''''''''''''''''''
+'''''''''''''''''''''''''''''''
 
 - **Type**: boolean
 - **Required?**: no; defaults to ``false``
@@ -428,7 +428,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
 .. _pylock-packages-directory-subdirectory:
 
 ``packages.directory.subdirectory``
-''''''''''''''''''''''''''''''''''''
+'''''''''''''''''''''''''''''''''''
 
 See :ref:`pylock-packages-vcs-subdirectory`.
 
@@ -436,7 +436,7 @@ See :ref:`pylock-packages-vcs-subdirectory`.
 .. _pylock-packages-archive:
 
 ``[packages.archive]``
------------------------
+----------------------
 
 - **Type**: table
 - **Required?**: no
@@ -454,7 +454,7 @@ See :ref:`pylock-packages-vcs-subdirectory`.
 .. _pylock-packages-archive-url:
 
 ``packages.archive.url``
-'''''''''''''''''''''''''
+''''''''''''''''''''''''
 
 See :ref:`pylock-packages-vcs-url`.
 
@@ -462,7 +462,7 @@ See :ref:`pylock-packages-vcs-url`.
 .. _pylock-packages-archive-path:
 
 ``packages.archive.path``
-''''''''''''''''''''''''''
+'''''''''''''''''''''''''
 
 See :ref:`pylock-packages-vcs-path`.
 
@@ -470,7 +470,7 @@ See :ref:`pylock-packages-vcs-path`.
 .. _pylock-packages-archive-size:
 
 ``packages.archive.size``
-''''''''''''''''''''''''''
+'''''''''''''''''''''''''
 
 - **Type**: integer
 - **Required?**: no
@@ -495,7 +495,7 @@ See :ref:`pylock-packages-vcs-path`.
 .. _pylock-packages-archive-hashes:
 
 ``[packages.archive.hashes]``
-''''''''''''''''''''''''''''''
+'''''''''''''''''''''''''''''
 
 - **Type**: Table of strings
 - **Required?**: yes

From eaf53bec528cdc65fdfa61a4b02b3b3ad3e06801 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Fri, 2 May 2025 16:02:39 -0700
Subject: [PATCH 0955/1072] Apply suggestions from code review
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: 🇺🇦 Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/specifications/pylock-toml.rst | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/source/specifications/pylock-toml.rst b/source/specifications/pylock-toml.rst
index fdd3ed5a0..a25937c75 100644
--- a/source/specifications/pylock-toml.rst
+++ b/source/specifications/pylock-toml.rst
@@ -614,7 +614,7 @@ See :ref:`pylock-packages-archive-hashes`.
   :ref:`pylock-packages-directory`, and :ref:`pylock-packages-archive`
 - **Inspiration**: PDM_, Poetry_, uv_
 - For recording the wheel files as specified by
-  :ref:`  binary-distribution-format` for the package.
+  :ref:`binary-distribution-format` for the package.
 - Tools MUST support wheel files, both from a locking and installation
   perspective.
 
@@ -847,4 +847,3 @@ History
 .. _TOML: https://toml.io/
 .. _uv: https://pypi.org/project/uv/
 .. _URL: https://url.spec.whatwg.org/
-.. _URL: https://url.spec.whatwg.org/

From eb512bcc0900163bfdf4faedbf04ab86efb919a2 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Fri, 2 May 2025 16:06:05 -0700
Subject: [PATCH 0956/1072] Drop comments

---
 source/specifications/pylock-toml.rst | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/source/specifications/pylock-toml.rst b/source/specifications/pylock-toml.rst
index a25937c75..d21294cf9 100644
--- a/source/specifications/pylock-toml.rst
+++ b/source/specifications/pylock-toml.rst
@@ -58,7 +58,6 @@ recorded in a consistent order (if inspiration is desired, this specification ha
 write down keys in a logical order). As well, tools SHOULD sort arrays in
 consistent order. Usage of inline tables SHOULD also be kept consistent.
 
-.. File details
 
 .. _pylock-lock-version:
 
@@ -194,8 +193,6 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   be installed MUST narrow down to a single entry at install time.
 
 
-.. Identification
-
 .. _pylock-packages-name:
 
 ``packages.name``
@@ -224,8 +221,6 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   :ref:`source tree ` is used).
 
 
-.. Requirements
-
 .. _pylock-packages-marker:
 
 ``packages.marker``
@@ -271,8 +266,6 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   informational for auditing purposes.
 
 
-.. Source
-
 .. _pylock-packages-vcs:
 
 ``[packages.vcs]``

From 8315686281c00a0ce17c687ef091cbe5af3d6e60 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Fri, 2 May 2025 16:10:58 -0700
Subject: [PATCH 0957/1072] Normalize formatting

---
 source/specifications/pylock-toml/pylock.example.toml | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/source/specifications/pylock-toml/pylock.example.toml b/source/specifications/pylock-toml/pylock.example.toml
index 60982f1d3..45e8731b2 100644
--- a/source/specifications/pylock-toml/pylock.example.toml
+++ b/source/specifications/pylock-toml/pylock.example.toml
@@ -1,12 +1,12 @@
 lock-version = '1.0'
 environments = ["sys_platform == 'win32'", "sys_platform == 'linux'"]
-requires-python = '==3.12'
+requires-python = '== 3.12'
 created-by = 'mousebender'
 
 [[packages]]
 name = 'attrs'
 version = '25.1.0'
-requires-python = '>=3.8'
+requires-python = '>= 3.8'
 
     [[packages.wheels]]
     name = 'attrs-25.1.0-py3-none-any.whl'
@@ -24,7 +24,7 @@ requires-python = '>=3.8'
 [[packages]]
 name = 'cattrs'
 version = '24.1.2'
-requires-python = '>=3.8'
+requires-python = '>= 3.8'
 dependencies = [
     {name = 'attrs'},
 ]
@@ -39,7 +39,7 @@ dependencies = [
 [[packages]]
 name = 'numpy'
 version = '2.2.3'
-requires-python = '>=3.10'
+requires-python = '>= 3.10'
 
     [[packages.wheels]]
     name = 'numpy-2.2.3-cp312-cp312-win_amd64.whl'

From 8a6eccf4131c3fcccbb52949e09e91b8c6c79833 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Fri, 2 May 2025 16:13:46 -0700
Subject: [PATCH 0958/1072] Make example or extras and dependency groups mroe
 distinct

---
 source/specifications/dependency-specifiers.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst
index 62731ffbb..e8e3229ff 100644
--- a/source/specifications/dependency-specifiers.rst
+++ b/source/specifications/dependency-specifiers.rst
@@ -299,12 +299,12 @@ an error like all other unknown variables.
      - An error except when defined by the context interpreting the
        specification.
      - String
-     - ``test``
+     - ``toml``
    * - ``extras``
      - An error except when defined by the context interpreting the
        specification.
      - Set of strings
-     - ``{"test"}``
+     - ``{"toml"}``
    * - ``dependency_groups``
      - An error except when defined by the context interpreting the
        specification.

From 1acd5e7f6489d4085947e1534d51102da60e6419 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Fri, 9 May 2025 16:16:07 -0700
Subject: [PATCH 0959/1072] Clarify that dev releases are considered
 pre-releases when handling them See
 https://discuss.python.org/t/are-developmental-releases-a-type-of-pre-release/81666/10
 for approval of this change.

---
 source/specifications/version-specifiers.rst | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/source/specifications/version-specifiers.rst b/source/specifications/version-specifiers.rst
index d18596ee0..acb63b59e 100644
--- a/source/specifications/version-specifiers.rst
+++ b/source/specifications/version-specifiers.rst
@@ -343,6 +343,9 @@ post-releases::
     X.YrcN.devM      # Developmental release of a release candidate
     X.Y.postN.devM   # Developmental release of a post-release
 
+Do note that development releases are considered a type of pre-release when
+handling them.
+
 .. note::
 
    While they may be useful for continuous integration purposes, publishing
@@ -1266,3 +1269,5 @@ History
 =======
 
 - August 2014: This specification was approved through :pep:`440`.
+- May 2025: Clarify that development releases are a form of pre-release when
+  they are handled.

From 866005370d20c64e811a7b2990b2f3e9c3ae7956 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Tue, 13 May 2025 15:52:09 -0400
Subject: [PATCH 0960/1072] guides: remove manual Sigstore steps from
 publishing guide

These steps are superfluous now that gh-action-pypi-publish
generates and uploads PEP 740-compatible attestations by default
on its own.

(They also served a slightly different purpose than PEP 740
attestations, since they were never uploaded to PyPI and used
a different format.)

Closes #1788.

Signed-off-by: William Woodruff 
---
 .../publish-to-test-pypi.yml                  | 43 ----------------
 ...s-using-github-actions-ci-cd-workflows.rst | 51 ++++---------------
 2 files changed, 11 insertions(+), 83 deletions(-)

diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
index 7051540ef..8813a0392 100644
--- a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
+++ b/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
@@ -51,49 +51,6 @@ jobs:
     - name: Publish distribution 📦 to PyPI
       uses: pypa/gh-action-pypi-publish@release/v1
 
-  github-release:
-    name: >-
-      Sign the Python 🐍 distribution 📦 with Sigstore
-      and upload them to GitHub Release
-    needs:
-    - publish-to-pypi
-    runs-on: ubuntu-latest
-
-    permissions:
-      contents: write  # IMPORTANT: mandatory for making GitHub Releases
-      id-token: write  # IMPORTANT: mandatory for sigstore
-
-    steps:
-    - name: Download all the dists
-      uses: actions/download-artifact@v4
-      with:
-        name: python-package-distributions
-        path: dist/
-    - name: Sign the dists with Sigstore
-      uses: sigstore/gh-action-sigstore-python@v3.0.0
-      with:
-        inputs: >-
-          ./dist/*.tar.gz
-          ./dist/*.whl
-    - name: Create GitHub Release
-      env:
-        GITHUB_TOKEN: ${{ github.token }}
-      run: >-
-        gh release create
-        "$GITHUB_REF_NAME"
-        --repo "$GITHUB_REPOSITORY"
-        --notes ""
-    - name: Upload artifact signatures to GitHub Release
-      env:
-        GITHUB_TOKEN: ${{ github.token }}
-      # Upload to GitHub Release using the `gh` CLI.
-      # `dist/` contains the built packages, and the
-      # sigstore-produced signatures and certificates.
-      run: >-
-        gh release upload
-        "$GITHUB_REF_NAME" dist/**
-        --repo "$GITHUB_REPOSITORY"
-
   publish-to-testpypi:
     name: Publish Python 🐍 distribution 📦 to TestPyPI
     needs:
diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
index 049fba15c..1ee562cf7 100644
--- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
+++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
@@ -21,10 +21,10 @@ for temporarily storing and downloading the source packages.
    details of building platform specific projects. If you have binary
    components, check out :ref:`cibuildwheel`'s GitHub Action examples.
 
-Configuring trusted publishing
+Configuring Trusted Publishing
 ==============================
 
-This guide relies on PyPI's `trusted publishing`_ implementation to connect
+This guide relies on PyPI's `Trusted Publishing`_ implementation to connect
 to `GitHub Actions CI/CD`_. This is recommended for security reasons, since
 the generated tokens are created for each of your projects
 individually and expire automatically. Otherwise, you'll need to generate an
@@ -36,7 +36,7 @@ Since this guide will demonstrate uploading to both
 PyPI and TestPyPI, we'll need two trusted publishers configured.
 The following steps will lead you through creating the "pending" publishers
 for your new :term:`PyPI project `.
-However it is also possible to add `trusted publishing`_ to any
+However it is also possible to add `Trusted Publishing`_ to any
 pre-existing project, if you are its owner.
 
 .. attention::
@@ -134,7 +134,7 @@ provided by GitHub Actions. This also defines a GitHub Environment
 for the job to run in its context and a URL to be displayed in GitHub's
 UI nicely. Additionally, it allows acquiring an OpenID Connect token
 that the ``pypi-publish`` actions needs to implement secretless
-trusted publishing to PyPI.
+Trusted Publishing to PyPI.
 
 .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml
    :language: yaml
@@ -152,46 +152,20 @@ Finally, add the following steps at the end:
 .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml
    :language: yaml
    :start-after: id-token: write
-   :end-before:  github-release:
+   :end-before:  publish-to-testpypi:
 
 This step uses the `pypa/gh-action-pypi-publish`_ GitHub
 Action: after the stored distribution package has been
 downloaded by the `download-artifact`_ action, it uploads
 the contents of the ``dist/`` folder into PyPI unconditionally.
 
-Signing the distribution packages
-=================================
-
-The following job signs the distribution packages with `Sigstore`_,
-the same artifact signing system `used to sign CPython `_.
-
-Firstly, it uses the `sigstore/gh-action-sigstore-python GitHub Action`_
-to sign the distribution packages. In the next step, an empty GitHub Release
-from the current tag is created using the ``gh`` CLI. Note this step can be further
-customised. See the `gh release documentation `_
-as a reference.
-
 .. tip::
 
-   You may need to manage your ``GITHUB_TOKEN`` permissions to
-   enable creating the GitHub Release. See the `GitHub
-   documentation `_
-   for instructions. Specifically, the token needs the
-   ``contents: write`` permission.
-
-Finally, the signed distributions are uploaded to the GitHub Release.
-
-.. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml
-   :language: yaml
-   :start-at: github-release:
-   :end-before:  publish-to-testpypi
-
-
-.. note::
-
-   This is a replacement for GPG signatures, for which support has been
-   `removed from PyPI `_.
-   However, this job is not mandatory for uploading to PyPI and can be omitted.
+   Starting with version
+   `v1.11.0 `_,
+   `pypa/gh-action-pypi-publish`_ generates and uploads :pep:`740`-compatible
+   attestations for each distribution by default. No additional manual
+   signing steps are required.
 
 
 Separate workflow for publishing to TestPyPI
@@ -254,9 +228,6 @@ sure that your release pipeline remains healthy!
    https://github.com/actions/download-artifact
 .. _`upload-artifact`:
    https://github.com/actions/upload-artifact
-.. _Sigstore: https://www.sigstore.dev/
-.. _`sigstore/gh-action-sigstore-python GitHub Action`:
-   https://github.com/marketplace/actions/gh-action-sigstore-python
 .. _Secrets:
    https://docs.github.com/en/actions/reference/encrypted-secrets
-.. _trusted publishing: https://docs.pypi.org/trusted-publishers/
+.. _Trusted Publishing: https://docs.pypi.org/trusted-publishers/

From a27a095cf3f477063daf0b55619156a54dbb13d3 Mon Sep 17 00:00:00 2001
From: Wade Cheng <86323079+wade-cheng@users.noreply.github.com>
Date: Fri, 11 Apr 2025 17:55:09 -0400
Subject: [PATCH 0961/1072] grammar you->your

---
 source/guides/creating-command-line-tools.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/creating-command-line-tools.rst b/source/guides/creating-command-line-tools.rst
index 49ce0c9ed..bf0354071 100644
--- a/source/guides/creating-command-line-tools.rst
+++ b/source/guides/creating-command-line-tools.rst
@@ -184,7 +184,7 @@ default one and run it, which makes this command possible:
 Conclusion
 ==========
 
-You know by now how to package a command-line application written in Python. A further step could be to distribute you package,
+You know by now how to package a command-line application written in Python. A further step could be to distribute your package,
 meaning uploading it to a :term:`package index `, most commonly :term:`PyPI `. To do that, follow the instructions at :ref:`Packaging your project`. And once you're done, don't forget to :ref:`do some research ` on how your package is received!
 
 .. _click: https://click.palletsprojects.com/

From 480dbb9b8cbd7f33d0c6bc89ce490aec9c80da0d Mon Sep 17 00:00:00 2001
From: Ned Batchelder 
Date: Sat, 17 May 2025 18:21:43 -0400
Subject: [PATCH 0962/1072] don't change the link syntax

---
 source/glossary.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/glossary.rst b/source/glossary.rst
index 73a192daa..6a592125f 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -291,7 +291,7 @@ Glossary
         `_, and discuss issues on the
         `distutils-sig mailing list
         `_
-	and `the Python Discourse forum `_.
+	and `the Python Discourse forum `__.
 
 
     Python Package Index (PyPI)

From c56c952fcf0fbc0c1602c68dc266468d6f3bedb3 Mon Sep 17 00:00:00 2001
From: Stephen Rosen 
Date: Mon, 19 May 2025 14:57:56 -0400
Subject: [PATCH 0963/1072] Add 'docs' to dependency groups example

This is a small example update based on some observed usage of
Dependency Groups. We wouldn't want to bloat the example, but many
projects are using a `docs` group and this example therefore better
exemplifies how Dependency Groups can be used to declare
isolated/separate groups.
---
 source/specifications/dependency-groups.rst | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/source/specifications/dependency-groups.rst b/source/specifications/dependency-groups.rst
index b6a3e6fad..22e4cba0d 100644
--- a/source/specifications/dependency-groups.rst
+++ b/source/specifications/dependency-groups.rst
@@ -22,14 +22,16 @@ Specification
 Examples
 --------
 
-This is a simple table which shows a ``test`` group::
+This is a simple table which shows ``docs`` and ``test`` groups::
 
     [dependency-groups]
+    docs = ["sphinx"]
     test = ["pytest>7", "coverage"]
 
-and a similar table which defines ``test`` and ``coverage`` groups::
+and a similar table which defines ``docs``, ``test``, and ``coverage`` groups::
 
     [dependency-groups]
+    docs = ["sphinx"]
     coverage = ["coverage[toml]"]
     test = ["pytest>7", {include-group = "coverage"}]
 

From 73aea5cd2804d66adaabbea35b8f78068662aa9d Mon Sep 17 00:00:00 2001
From: Yuki Kobayashi 
Date: Mon, 26 May 2025 01:02:51 +0000
Subject: [PATCH 0964/1072] Fix typo

---
 source/specifications/platform-compatibility-tags.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index d617323d4..6feb18cda 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -151,7 +151,7 @@ auditwheel  ``>=1.0.0``     ``>=2.0.0``        ``>=3.0.0``        ``>=3.3.0`` [#
 
 The ``musllinux`` family of tags is similar to ``manylinux``, but for Linux
 platforms that use the musl_ libc rather than glibc (a prime example being Alpine
-Linux). The schema is :file:`musllinux_{x}_{y}_{arch}``, supporting musl ``x.y`` and higher
+Linux). The schema is :file:`musllinux_{x}_{y}_{arch}`, supporting musl ``x.y`` and higher
 on the architecture ``arch``.
 
 The musl version values can be obtained by executing the musl libc shared

From cf5953a5ff9bd5f92b90d4ff997c0ed7614b2926 Mon Sep 17 00:00:00 2001
From: Daksh Bhayana 
Date: Sun, 1 Jun 2025 18:11:31 +0530
Subject: [PATCH 0965/1072] Empty Commit to check CI failure


From 79793e91b8bfd5bd0327b666a3e36f0c74d47037 Mon Sep 17 00:00:00 2001
From: Daksh Bhayana 
Date: Sun, 1 Jun 2025 18:38:20 +0530
Subject: [PATCH 0966/1072] Added specific redhat url to linkcheck_ignore

---
 source/conf.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/source/conf.py b/source/conf.py
index d41db4957..7a05613ea 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -146,6 +146,7 @@
     "https://pyscaffold.org/*",
     "https://anaconda.org",
     "https://www.cisa.gov/sbom",
+    "https://developers.redhat.com/products/softwarecollections/overview",
 ]
 linkcheck_retries = 5
 # Ignore anchors for common targets when we know they likely won't be found

From 397de33ae16184bd8a23941c163d4c2d174c19ea Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Tue, 3 Jun 2025 10:42:15 -0400
Subject: [PATCH 0967/1072] specifications: clarify "sorted, set" to "sorted,
 collection"

This will hopefully clarify/eliminate a contradiction in terms
in the current specification text: the current text says
both "sorted" and "set", where "set" conventionally implies
an unordered collection.

In context that *appears* to have not been the intention,
since the context is the wheel filename encoding
and not the internal (i.e. parsed) representation
of a wheel filename's tags.

Signed-off-by: William Woodruff 
---
 source/specifications/platform-compatibility-tags.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 6feb18cda..0502c8c03 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -351,7 +351,7 @@ Compressed Tag Sets
 
 To allow for compact filenames of bdists that work with more than
 one compatibility tag triple, each tag in a filename can instead be a
-'.'-separated, sorted, set of tags.  For example, pip, a pure-Python
+'.'-separated, sorted, collection of tags.  For example, pip, a pure-Python
 package that is written to run under Python 2 and 3 with the same source
 code, could distribute a bdist with the tag ``py2.py3-none-any``.
 The full list of simple tags is::

From 2635f8c215877157ea5728a0d36948c41133a10f Mon Sep 17 00:00:00 2001
From: Ned Batchelder 
Date: Wed, 18 Jun 2025 06:52:47 -0400
Subject: [PATCH 0968/1072] Re-order the metadata history to be in usual
 changelog order

---
 source/specifications/core-metadata.rst | 27 ++++++++++++++-----------
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 39ee7c4cd..b4667d7e1 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -921,27 +921,30 @@ Example::
 History
 =======
 
-- March 2001: Core metadata 1.0 was approved through :pep:`241`.
-- April 2003: Core metadata 1.1 was approved through :pep:`314`:
-- February 2010: Core metadata 1.2 was approved through :pep:`345`.
-- February 2018: Core metadata 2.1 was approved through :pep:`566`.
+- August 2024: Core metadata 2.4 was approved through :pep:`639`.
 
-  - Added ``Description-Content-Type`` and ``Provides-Extra``.
-  - Added canonical method for transforming metadata to JSON.
-  - Restricted the grammar of the ``Name`` field.
+  - Added the ``License-Expression`` field.
+  - Added the ``License-File`` field.
+
+- March 2022: Core metadata 2.3 was approved through :pep:`685`.
+
+  - Restricted extra names to be normalized.
 
 - October 2020: Core metadata 2.2 was approved through :pep:`643`.
 
   - Added the ``Dynamic`` field.
 
-- March 2022: Core metadata 2.3 was approved through :pep:`685`.
+- February 2018: Core metadata 2.1 was approved through :pep:`566`.
 
-  - Restricted extra names to be normalized.
+  - Added ``Description-Content-Type`` and ``Provides-Extra``.
+  - Added canonical method for transforming metadata to JSON.
+  - Restricted the grammar of the ``Name`` field.
 
-- August 2024: Core metadata 2.4 was approved through :pep:`639`.
+- February 2010: Core metadata 1.2 was approved through :pep:`345`.
 
-  - Added the ``License-Expression`` field.
-  - Added the ``License-File`` field.
+- April 2003: Core metadata 1.1 was approved through :pep:`314`:
+
+- March 2001: Core metadata 1.0 was approved through :pep:`241`.
 
 ----
 

From f714ffd068c761d0a110b2a1d5af2cff5353f2e4 Mon Sep 17 00:00:00 2001
From: Ned Batchelder 
Date: Wed, 18 Jun 2025 06:53:26 -0400
Subject: [PATCH 0969/1072] Mention the metadata version and date at the top of
 the metadata page

---
 source/specifications/core-metadata.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index b4667d7e1..550c6e55a 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -6,6 +6,8 @@
 Core metadata specifications
 ============================
 
+This page describes version 2.4, approved in August 2024.
+
 Fields defined in the following specification should be considered valid,
 complete and not subject to change. The required fields are:
 

From 2989d20d2fb0a7577267729500fc4b9e8efa9bcf Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Fri, 27 Jun 2025 15:59:11 -0700
Subject: [PATCH 0970/1072] Fix references in pylock-toml.rst

A few had spaces after the opening backtick.
---
 source/specifications/pylock-toml.rst | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/source/specifications/pylock-toml.rst b/source/specifications/pylock-toml.rst
index d21294cf9..342e608c5 100644
--- a/source/specifications/pylock-toml.rst
+++ b/source/specifications/pylock-toml.rst
@@ -672,12 +672,12 @@ See :ref:`pylock-packages-archive-hashes`.
 
 - **Type**: array of tables
 - **Required?**: no
-- **Inspiration**: :ref:`  provenance-object`
+- **Inspiration**: :ref:`provenance-object`
 - A recording of the attestations for **any** file recorded for this package.
 - If available, tools SHOULD include the attestation identities found.
 - Publisher-specific keys are to be included in the table as-is
   (i.e. top-level), following the spec at
-  :ref:`  index-hosted-attestations`.
+  :ref:`index-hosted-attestations`.
 
 
 .. _pylock-packages-attestation-identities-kind:
@@ -687,7 +687,7 @@ See :ref:`pylock-packages-archive-hashes`.
 
 - **Type**: string
 - **Required?**: yes
-- **Inspiration**: :ref:`  provenance-object`
+- **Inspiration**: :ref:`provenance-object`
 - The unique identity of the Trusted Publisher.
 
 
@@ -698,9 +698,9 @@ See :ref:`pylock-packages-archive-hashes`.
 
 - **Type**: table
 - **Required?**: no
-- **Inspiration**: :ref:`  pyproject-tool-table`
+- **Inspiration**: :ref:`pyproject-tool-table`
 - Similar usage as that of the :ref:`pylock-tool` table from the
-  :ref:`  pyproject-toml-spec`, but at the package version level instead
+  :ref:`pyproject-toml-spec`, but at the package version level instead
   of at the lock file level (which is also available via :ref:`pylock-tool`).
 - Data recorded in the table MUST be disposable (i.e. it MUST NOT affect
   installation).

From 19a7a03595d6f9e7e25fbd3abf6decda739b91e0 Mon Sep 17 00:00:00 2001
From: Yuki Kobayashi 
Date: Sat, 28 Jun 2025 01:14:42 +0000
Subject: [PATCH 0971/1072] Fix a small markup error in the contribute guide

The "Do not translate ..." part shoule be a definition list, not a blockquote, like the rest of this page.
---
 source/contribute.rst | 1 -
 1 file changed, 1 deletion(-)

diff --git a/source/contribute.rst b/source/contribute.rst
index cf5314b8d..f512dd30d 100644
--- a/source/contribute.rst
+++ b/source/contribute.rst
@@ -103,7 +103,6 @@ If you are not familiar with reStructuredText (RST) syntax, please read `this gu
 before translating on Weblate.
 
 **Do not translate the text in reference directly**
-
   When translating the text in reference, please do not translate them directly.
 
   | Wrong: Translate the following text directly:

From 6b10bd2efbec7091f21973c1824db32573b4c010 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Fri, 11 Jul 2025 22:33:52 -0400
Subject: [PATCH 0972/1072] simple-repository-api: add PEP 792, clean up layout

---
 source/specifications/file-yanking.rst        |  92 +++++
 .../specifications/project-status-markers.rst |  89 +++++
 .../section-package-indices.rst               |   2 +
 .../specifications/simple-repository-api.rst  | 369 +++++++++---------
 4 files changed, 377 insertions(+), 175 deletions(-)
 create mode 100644 source/specifications/file-yanking.rst
 create mode 100644 source/specifications/project-status-markers.rst

diff --git a/source/specifications/file-yanking.rst b/source/specifications/file-yanking.rst
new file mode 100644
index 000000000..4ab8cd5cc
--- /dev/null
+++ b/source/specifications/file-yanking.rst
@@ -0,0 +1,92 @@
+.. _file-yanking:
+
+============
+File Yanking
+============
+
+.. note::
+
+    This specification was originally defined in
+    :pep:`592`.
+
+.. note::
+
+    :pep:`592` includes changes to the HTML and JSON index APIs.
+    These changes are documented in the :ref:`simple-repository-api`
+    under :ref:`HTML - Project Detail `
+    and :ref:`JSON - Project Detail `.
+
+Specification
+=============
+
+Links in the simple repository **MAY** have a ``data-yanked`` attribute
+which may have no value, or may have an arbitrary string as a value. The
+presence of a ``data-yanked`` attribute **SHOULD** be interpreted as
+indicating that the file pointed to by this particular link has been
+"Yanked", and should not generally be selected by an installer, except
+under specific scenarios.
+
+The value of the ``data-yanked`` attribute, if present, is an arbitrary
+string that represents the reason for why the file has been yanked. Tools
+that process the simple repository API **MAY** surface this string to
+end users.
+
+The yanked attribute is not immutable once set, and may be rescinded in
+the future (and once rescinded, may be reset as well). Thus API users
+**MUST** be able to cope with a yanked file being "unyanked" (and even
+yanked again).
+
+Installers
+----------
+
+The desirable experience for users is that once a file is yanked, when
+a human being is currently trying to directly install a yanked file, that
+it fails as if that file had been deleted. However, when a human did that
+awhile ago, and now a computer is just continuing to mechanically follow
+the original order to install the now yanked file, then it acts as if it
+had not been yanked.
+
+An installer **MUST** ignore yanked releases, if the selection constraints
+can be satisfied with a non-yanked version, and **MAY** refuse to use a
+yanked release even if it means that the request cannot be satisfied at all.
+An implementation **SHOULD** choose a policy that follows the spirit of the
+intention above, and that prevents "new" dependencies on yanked
+releases/files.
+
+What this means is left up to the specific installer, to decide how to best
+fit into the overall usage of their installer. However, there are two
+suggested approaches to take:
+
+1. Yanked files are always ignored, unless they are the only file that
+   matches a version specifier that "pins" to an exact version using
+   either ``==`` (without any modifiers that make it a range, such as
+   ``.*``) or ``===``. Matching this version specifier should otherwise
+   be done as per :ref:`the version specifiers specification
+   ` for things like local versions, zero padding,
+   etc.
+2. Yanked files are always ignored, unless they are the only file that
+   matches what a lock file (such as ``Pipfile.lock`` or ``poetry.lock``)
+   specifies to be installed. In this case, a yanked file **SHOULD** not
+   be used when creating or updating a lock file from some input file or
+   command.
+
+Regardless of the specific strategy that an installer chooses for deciding
+when to install yanked files, an installer **SHOULD** emit a warning when
+it does decide to install a yanked file. That warning **MAY** utilize the
+value of the ``data-yanked`` attribute (if it has a value) to provide more
+specific feedback to the user about why that file had been yanked.
+
+
+Mirrors
+-------
+
+Mirrors can generally treat yanked files one of two ways:
+
+1. They may choose to omit them from their simple repository API completely,
+   providing a view over the repository that shows only "active", unyanked
+   files.
+2. They may choose to include yanked files, and additionally mirror the
+   ``data-yanked`` attribute as well.
+
+Mirrors **MUST NOT** mirror a yanked file without also mirroring the
+``data-yanked`` attribute for it.
diff --git a/source/specifications/project-status-markers.rst b/source/specifications/project-status-markers.rst
new file mode 100644
index 000000000..90df74441
--- /dev/null
+++ b/source/specifications/project-status-markers.rst
@@ -0,0 +1,89 @@
+.. _project-status-markers:
+
+======================
+Project Status Markers
+======================
+
+.. note::
+
+    This specification was originally defined in
+    :pep:`792`.
+
+.. note::
+
+    :pep:`792` includes changes to the HTML and JSON index APIs.
+    These changes are documented in the :ref:`simple-repository-api`
+    under :ref:`HTML - Project Detail `
+    and :ref:`JSON - Project Detail `.
+
+Specification
+=============
+
+A project always has exactly one status. If no status is explicitly noted,
+then the project is considered to be in the ``active`` state.
+
+Indices **MAY** implement any subset of the status markers specified,
+as applicable to their needs.
+
+This standard does not prescribe *which* principals (i.e. project maintainers,
+index administrators, etc.) are allowed to set and unset which statuses.
+
+``active``
+----------
+
+Description: The project is active. This is the default status for a project.
+
+Index semantics:
+
+* The index hosting the project **MUST** allow uploads of new distributions to
+  the project.
+* The index **MUST** offer existing distributions of the project for download.
+
+Installer semantics: none.
+
+``archived``
+------------
+
+Description: The project does not expect to be updated in the future.
+
+Index semantics:
+
+* The index hosting the project **MUST NOT** allow uploads of new distributions to
+  the project.
+* The index **MUST** offer existing distributions of the project for download.
+
+Installer semantics:
+
+* Installers **MAY** produce warnings about a project's archival.
+
+``quarantined``
+---------------
+
+Description: The project is considered generally unsafe for use, e.g. due to
+malware.
+
+Index semantics:
+
+* The index hosting the project **MUST NOT** allow uploads of new distributions to
+  the project.
+* The index **MUST NOT** offer any distributions of the project for download.
+
+Installer semantics:
+
+* Installers **MAY** produce warnings about a project's quarantine, although
+  doing so is effectively moot (as the index will not offer any distributions
+  for installation).
+
+``deprecated``
+--------------
+
+Description: The project is considered obsolete, and may have been superseded
+by another project.
+
+Index semantics:
+
+* This status shares the same semantics as ``active``.
+
+Installer semantics:
+
+* Installers **MAY** produce warnings about a project's deprecation.
diff --git a/source/specifications/section-package-indices.rst b/source/specifications/section-package-indices.rst
index 73004b4d3..1fcefe6ff 100644
--- a/source/specifications/section-package-indices.rst
+++ b/source/specifications/section-package-indices.rst
@@ -7,4 +7,6 @@ Package Index Interfaces
 
    pypirc
    simple-repository-api
+   file-yanking
    index-hosted-attestations
+   project-status-markers
diff --git a/source/specifications/simple-repository-api.rst b/source/specifications/simple-repository-api.rst
index d18c425db..afc932e4e 100644
--- a/source/specifications/simple-repository-api.rst
+++ b/source/specifications/simple-repository-api.rst
@@ -12,12 +12,13 @@ and "**OPTIONAL**"" in this document are to be interpreted as described in
 
 The interface for querying available package versions and
 retrieving packages from an index server comes in two forms:
-HTML and JSON.
+:ref:`HTML ` and
+:ref:`JSON `.
 
 .. _simple-repository-api-base:
 
-Base HTML API
-=============
+Base API
+========
 
 A repository that implements the simple API is defined by its base URL, this is
 the top level URL that all additional URLs are below. The API is named the
@@ -28,11 +29,115 @@ the top level URL that all additional URLs are below. The API is named the
           URL (so given PyPI's URL, a URL of ``/foo/`` would be
           ``https://pypi.org/simple/foo/``.
 
+Normalized Names
+----------------
+
+This spec references the concept of a "normalized" project name. As per
+:ref:`the name normalization specification `
+the only valid characters in a name are the ASCII alphabet, ASCII numbers,
+``.``, ``-``, and ``_``. The name should be lowercased with all runs of the
+characters ``.``, ``-``, or ``_`` replaced with a single ``-`` character. This
+can be implemented in Python with the ``re`` module::
+
+   import re
+
+   def normalize(name):
+       return re.sub(r"[-_.]+", "-", name).lower()
+
+.. _simple-repository-api-versioning:
+
+Versioning PyPI's Simple API
+----------------------------
+
+This spec proposes the inclusion of a meta tag on the responses of every
+successful request to a simple API page, which contains a name attribute
+of ``pypi:repository-version``, and a content that is a :ref:`version specifiers
+specification ` compatible
+version number, which is further constrained to ONLY be Major.Minor, and
+none of the additional features supported by :ref:`the version specifiers
+specification `.
+
+This would end up looking like:
+
+.. code-block:: html
+
+  
+
+When interpreting the repository version:
+
+* Incrementing the major version is used to signal a backwards
+  incompatible change such that existing clients would no longer be
+  expected to be able to meaningfully use the API.
+* Incrementing the minor version is used to signal a backwards
+  compatible change such that existing clients would still be
+  expected to be able to meaningfully use the API.
+
+It is left up to the discretion of any future specs as to what
+specifically constitutes a backwards incompatible vs compatible change
+beyond the broad suggestion that existing clients will be able to
+"meaningfully" continue to use the API, and can include adding,
+modifying, or removing existing features.
+
+It is expectation of this spec that the major version will never be
+incremented, and any future major API evolutions would utilize a
+different mechanism for API evolution. However the major version
+is included to disambiguate with future versions (e.g. a hypothetical
+simple api v2 that lived at /v2/, but which would be confusing if the
+repository-version was set to a version >= 2).
+
+API Version History
+~~~~~~~~~~~~~~~~~~~
+
+This section contains only an abbreviated history of changes,
+as marked by the API version number. For a full history of changes including
+changes made before API versioning, see :ref:`History `.
+
+- API version 1.0: Initial version of the API, declared with :pep:`629`.
+- API version 1.1: Added ``versions``, ``files[].size``, and ``files[].upload-time`` metadata
+  to the JSON serialization, declared with :pep:`700`.
+- API version 1.2: Added repository "tracks" metadata, declared with :pep:`708`.
+- API version 1.3: Added provenance metadata, declared with :pep:`740`.
+- API version 1.4: Added status markers, declared with :pep:`792`.
+
+Clients
+~~~~~~~
+
+Clients interacting with the simple API **SHOULD** introspect each
+response for the repository version, and if that data does not exist
+**MUST** assume that it is version 1.0.
+
+When encountering a major version greater than expected, clients
+**MUST** hard fail with an appropriate error message for the user.
+
+When encountering a minor version greater than expected, clients
+**SHOULD** warn users with an appropriate message.
+
+Clients **MAY** still continue to use feature detection in order to
+determine what features a repository uses.
+
+.. _simple-repository-html-serialization:
+
+HTML Serialization
+------------------
+
+.. _simple-repository-html-project-list:
+
+The following constraints apply to all HTML serialized responses described in
+this spec:
+
+* All HTML responses **MUST** be a valid HTML5 document.
+* HTML responses **MAY** contain one or more ``meta`` tags in the
+  ```` section. The semantics of these tags are defined below.
+
+Project List
+~~~~~~~~~~~~
 
 Within a repository, the root URL (``/`` for this spec which represents the base
 URL) **MUST** be a valid HTML5 page with a single anchor element per project in
-the repository. The text of the anchor tag **MUST** be the name of
-the project and the href attribute **MUST** link to the URL for that particular
+the repository.
+
+The text of each anchor tag **MUST** be the name of
+the project and the ``href`` attribute **MUST** link to the URL for that particular
 project. As an example:
 
 .. code-block:: html
@@ -45,14 +150,26 @@ project. As an example:
      
    
 
+.. _simple-repository-html-project-detail:
+
+Project Detail
+~~~~~~~~~~~~~~
+
 Below the root URL is another URL for each individual project contained within
-a repository. The format of this URL is ``//`` where the ````
-is replaced by the normalized name for that project, so a project named
-"HolyGrail" would have a URL like ``/holygrail/``. This URL must respond with
-a valid HTML5 page with a single anchor element per file for the project. The
-href attribute **MUST** be a URL that links to the location of the file for
-download, and the text of the anchor tag **MUST** match the final path
-component (the filename) of the URL. The URL **SHOULD** include a hash in the
+a repository. The format of this URL is ``//``, where the ````
+is replaced by the normalized name for that project.
+
+.. tip::
+
+   For example, a project named "HolyGrail" would have a URL like
+   ``/holygrail/``.
+
+The project detail URL must respond with a valid HTML5 page with a single
+anchor element per file for the project. The ``href`` attribute **MUST** be a
+URL that links to the location of the file for download, and the text of the
+anchor tag **MUST** match the final path component (the filename) of the URL.
+
+Each file URL **SHOULD** include a hash in the
 form of a URL fragment with the following syntax: ``#=``,
 where ```` is the lowercase name of the hash function (such as
 ``sha256``) and ```` is the hex encoded digest.
@@ -125,6 +242,22 @@ In addition to the above, the following constraints are placed on the API:
   In the attribute value, < and > have to be HTML encoded as ``<`` and
   ``>``, respectively.
 
+* A repository **MAY** include a ``data-yanked`` attribute on a file link.
+
+  The ``data-yanked`` attribute may have no value, or may have an
+  arbitrary string as a value. The presence of a ``data-yanked`` attribute
+  **SHOULD** be interpreted as indicating that the file pointed to by this
+  particular link has been "Yanked", and should not generally be selected by
+  an installer, except under specific scenarios.
+
+  The value of the ``data-yanked`` attribute, if present, is an arbitrary
+  string that represents the reason for why the file has been yanked.
+
+  .. note::
+
+    The semantics of how tools should handle yanked files is
+    described in :ref:`file-yanking`.
+
 * A repository **MAY** include a ``data-provenance`` attribute on a file link.
   The value of this attribute **MUST** be a fully qualified URL, signaling that
   the file's provenance can be found at that URL. This URL **MUST** represent
@@ -138,168 +271,22 @@ In addition to the above, the following constraints are placed on the API:
 
     The format of the linked provenance is defined in :ref:`index-hosted-attestations`.
 
-Normalized Names
-----------------
-
-This spec references the concept of a "normalized" project name. As per
-:ref:`the name normalization specification `
-the only valid characters in a name are the ASCII alphabet, ASCII numbers,
-``.``, ``-``, and ``_``. The name should be lowercased with all runs of the
-characters ``.``, ``-``, or ``_`` replaced with a single ``-`` character. This
-can be implemented in Python with the ``re`` module::
-
-   import re
-
-   def normalize(name):
-       return re.sub(r"[-_.]+", "-", name).lower()
-
-.. _simple-repository-api-yank:
-
-Adding "Yank" Support to the Simple API
-=======================================
-
-Links in the simple repository **MAY** have a ``data-yanked`` attribute
-which may have no value, or may have an arbitrary string as a value. The
-presence of a ``data-yanked`` attribute **SHOULD** be interpreted as
-indicating that the file pointed to by this particular link has been
-"Yanked", and should not generally be selected by an installer, except
-under specific scenarios.
-
-The value of the ``data-yanked`` attribute, if present, is an arbitrary
-string that represents the reason for why the file has been yanked. Tools
-that process the simple repository API **MAY** surface this string to
-end users.
-
-The yanked attribute is not immutable once set, and may be rescinded in
-the future (and once rescinded, may be reset as well). Thus API users
-**MUST** be able to cope with a yanked file being "unyanked" (and even
-yanked again).
-
-
-Installers
-----------
-
-The desirable experience for users is that once a file is yanked, when
-a human being is currently trying to directly install a yanked file, that
-it fails as if that file had been deleted. However, when a human did that
-awhile ago, and now a computer is just continuing to mechanically follow
-the original order to install the now yanked file, then it acts as if it
-had not been yanked.
-
-An installer **MUST** ignore yanked releases, if the selection constraints
-can be satisfied with a non-yanked version, and **MAY** refuse to use a
-yanked release even if it means that the request cannot be satisfied at all.
-An implementation **SHOULD** choose a policy that follows the spirit of the
-intention above, and that prevents "new" dependencies on yanked
-releases/files.
-
-What this means is left up to the specific installer, to decide how to best
-fit into the overall usage of their installer. However, there are two
-suggested approaches to take:
-
-1. Yanked files are always ignored, unless they are the only file that
-   matches a version specifier that "pins" to an exact version using
-   either ``==`` (without any modifiers that make it a range, such as
-   ``.*``) or ``===``. Matching this version specifier should otherwise
-   be done as per :ref:`the version specifiers specification
-   ` for things like local versions, zero padding,
-   etc.
-2. Yanked files are always ignored, unless they are the only file that
-   matches what a lock file (such as ``Pipfile.lock`` or ``poetry.lock``)
-   specifies to be installed. In this case, a yanked file **SHOULD** not
-   be used when creating or updating a lock file from some input file or
-   command.
-
-Regardless of the specific strategy that an installer chooses for deciding
-when to install yanked files, an installer **SHOULD** emit a warning when
-it does decide to install a yanked file. That warning **MAY** utilize the
-value of the ``data-yanked`` attribute (if it has a value) to provide more
-specific feedback to the user about why that file had been yanked.
-
-
-Mirrors
--------
-
-Mirrors can generally treat yanked files one of two ways:
-
-1. They may choose to omit them from their simple repository API completely,
-   providing a view over the repository that shows only "active", unyanked
-   files.
-2. They may choose to include yanked files, and additionally mirror the
-   ``data-yanked`` attribute as well.
-
-Mirrors **MUST NOT** mirror a yanked file without also mirroring the
-``data-yanked`` attribute for it.
-
-.. _simple-repository-api-versioning:
-
-Versioning PyPI's Simple API
-============================
-
-This spec proposes the inclusion of a meta tag on the responses of every
-successful request to a simple API page, which contains a name attribute
-of ``pypi:repository-version``, and a content that is a :ref:`version specifiers
-specification ` compatible
-version number, which is further constrained to ONLY be Major.Minor, and
-none of the additional features supported by :ref:`the version specifiers
-specification `.
-
-This would end up looking like:
-
-.. code-block:: html
-
-  
-
-When interpreting the repository version:
-
-* Incrementing the major version is used to signal a backwards
-  incompatible change such that existing clients would no longer be
-  expected to be able to meaningfully use the API.
-* Incrementing the minor version is used to signal a backwards
-  compatible change such that existing clients would still be
-  expected to be able to meaningfully use the API.
-
-It is left up to the discretion of any future specs as to what
-specifically constitutes a backwards incompatible vs compatible change
-beyond the broad suggestion that existing clients will be able to
-"meaningfully" continue to use the API, and can include adding,
-modifying, or removing existing features.
-
-It is expectation of this spec that the major version will never be
-incremented, and any future major API evolutions would utilize a
-different mechanism for API evolution. However the major version
-is included to disambiguate with future versions (e.g. a hypothetical
-simple api v2 that lived at /v2/, but which would be confusing if the
-repository-version was set to a version >= 2).
-
-API Version History
--------------------
+* A repository **MAY** include ``pypi:project-status`` and
+  ``pypi:project-status-reason`` meta tags on the response itself.
 
-This section contains only an abbreviated history of changes,
-as marked by the API version number. For a full history of changes including
-changes made before API versioning, see :ref:`History `.
+  The value of ``pypi:project-status`` **MUST** be a valid
+  project status marker, while the value of
+  ``pypi:project-status-reason`` **MUST** be an arbitrary string if present.
 
-- API version 1.0: Initial version of the API, declared with :pep:`629`.
-- API version 1.1: Added ``versions``, ``files[].size``, and ``files[].upload-time`` metadata
-  to the JSON serialization, declared with :pep:`700`.
-- API version 1.2: Added repository "tracks" metadata, declared with :pep:`708`.
-- API version 1.3: Added provenance metadata, declared with :pep:`740`.
-
-Clients
--------
-
-Clients interacting with the simple API **SHOULD** introspect each
-response for the repository version, and if that data does not exist
-**MUST** assume that it is version 1.0.
+  .. note::
 
-When encountering a major version greater than expected, clients
-**MUST** hard fail with an appropriate error message for the user.
+    The set of valid project status markers and their semantics is described
+    in :ref:`project-status-markers`.
 
-When encountering a minor version greater than expected, clients
-**SHOULD** warn users with an appropriate message.
+  .. note::
 
-Clients **MAY** still continue to use feature detection in order to
-determine what features a repository uses.
+    The ``pypi:project-status`` and ``pypi:project-status-reason`` meta tags
+    were added with API version 1.4.
 
 .. _simple-repository-api-metadata-file:
 
@@ -403,8 +390,8 @@ JSON Serialization
 ------------------
 
 The URL structure from :ref:`the base HTML API specification
-` still applies, as this spec only adds an additional
-serialization format for the already existing API.
+` still applies, as this spec only adds
+an additional serialization format for the already existing API.
 
 The following constraints apply to all JSON serialized responses described in this
 spec:
@@ -435,6 +422,8 @@ spec:
 * Keys (at any level) with a leading underscore are reserved as private for
   index server use. No future standard will assign a meaning to any such key.
 
+.. _simple-repository-json-project-list:
+
 Project List
 ~~~~~~~~~~~~
 
@@ -450,7 +439,7 @@ As an example:
 
     {
       "meta": {
-        "api-version": "1.3"
+        "api-version": "1.4"
       },
       "projects": [
         {"name": "Frob"},
@@ -478,6 +467,7 @@ As an example:
   best thought of as a set, but both JSON and HTML lack the functionality to have
   sets.
 
+.. _simple-repository-json-project-detail:
 
 Project Detail
 ~~~~~~~~~~~~~~
@@ -492,6 +482,28 @@ This URL must respond with a JSON encoded dictionary that has four keys:
 - ``name``: The normalized name of the project.
 - ``files``: A list of dictionaries, each one representing an individual file.
 - ``meta``: The general response metadata as `described earlier `__.
+
+  In addition to the general response metadata, the project detail ``meta``
+  dictionary **MAY** also include the following:
+
+  - ``project-status``: If present, this **MUST** be a valid project status marker.
+
+    .. note::
+
+      The set of valid project status markers and their semantics is described
+      in :ref:`project-status-markers`.
+
+    .. note::
+
+      The ``project-status`` key was added with API version 1.4.
+
+  - ``project-status-reason``: If present, this **MUST** be an arbitrary string
+    description of the project status.
+
+    .. note::
+
+      The ``project-status-reason`` key was added with API version 1.4.
+
 - ``versions``: A list of version strings specifying all of the project versions
   uploaded for this project. The value of ``versions`` is logically a set,
   and as such may not contain duplicates, and the order of the versions is
@@ -582,8 +594,13 @@ Each individual file dictionary has the following keys:
   file has been yanked, or a non empty, but otherwise arbitrary, string to indicate
   that a file has been yanked with a specific reason. If the ``yanked`` key is present
   and is a truthy value, then it **SHOULD** be interpreted as indicating that the
-  file pointed to by the ``url`` field has been "Yanked" as per :ref:`the API
-  yank specification `.
+  file pointed to by the ``url`` field has been "Yanked".
+
+  .. note::
+
+    The semantics of how tools should handle yanked files is
+    described in :ref:`file-yanking`.
+
 - ``size``: A **mandatory** key. It **MUST** contain an integer which is the file size in bytes.
 
   .. note::
@@ -618,7 +635,8 @@ As an example:
 
     {
       "meta": {
-        "api-version": "1.3"
+        "api-version": "1.4",
+        "project-status": "active"
       },
       "name": "holygrail",
       "files": [
@@ -1006,3 +1024,4 @@ History
 * June 2023: renaming the field which provides package metadata independently
   from a package, in :pep:`714`
 * November 2024: provenance metadata in the HTML and JSON formats, in :pep:`740`
+* July 2025: project status markers in the HTML and JSON formats, in :pep:`792`

From 9a6a4358ce484d2d76b27f0cadde85b174171d5e Mon Sep 17 00:00:00 2001
From: Clemens Brunner 
Date: Wed, 16 Jul 2025 08:41:19 +0200
Subject: [PATCH 0973/1072] Add uv-build to table

---
 source/guides/writing-pyproject-toml.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index 318fe0d51..1d035a384 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -314,11 +314,13 @@ backend>` now support the new format as shown in the following table.
      - flit-core [#flit-core-pep639]_
      - pdm-backend
      - poetry-core
+     - uv-build
    * - 1.27.0
      - 77.0.3
      - 3.12
      - 2.4.0
      - `not yet `_
+     - 0.7.19
 
 
 .. _license:

From bfd629be54786fe443354a239b9fedfe4341477c Mon Sep 17 00:00:00 2001
From: Clemens Brunner 
Date: Fri, 18 Jul 2025 08:58:33 +0200
Subject: [PATCH 0974/1072] Add uv in other places

---
 source/shared/build-backend-tabs.rst       | 8 ++++++++
 source/tutorials/managing-dependencies.rst | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/source/shared/build-backend-tabs.rst b/source/shared/build-backend-tabs.rst
index 7fc3a61da..a4c49a3b4 100644
--- a/source/shared/build-backend-tabs.rst
+++ b/source/shared/build-backend-tabs.rst
@@ -32,3 +32,11 @@
         [build-system]
         requires = ["pdm-backend >= 2.4.0"]
         build-backend = "pdm.backend"
+
+.. tab:: uv-build
+
+    .. code-block:: toml
+
+        [build-system]
+        requires = ["uv_build >= 0.8.0, <0.9.0"]
+        build-backend = "uv_build"
\ No newline at end of file
diff --git a/source/tutorials/managing-dependencies.rst b/source/tutorials/managing-dependencies.rst
index db3b82533..da12d8a91 100644
--- a/source/tutorials/managing-dependencies.rst
+++ b/source/tutorials/managing-dependencies.rst
@@ -177,3 +177,5 @@ and techniques, listed in alphabetical order, to see if one of them is a better
   structured as a distributable Python package with a valid ``pyproject.toml`` file.
   By contrast, Pipenv explicitly avoids making the assumption that the application
   being worked on will support distribution as a ``pip``-installable Python package.
+* `uv `__ for a single tool that covers the entire project
+  management workflow, including dependency management, packaging, and publishing.
\ No newline at end of file

From 4bd633068206553f8d14375223eb261b2856ac0a Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Fri, 18 Jul 2025 06:59:04 +0000
Subject: [PATCH 0975/1072] [pre-commit.ci] auto fixes from pre-commit.com
 hooks

for more information, see https://pre-commit.ci
---
 source/shared/build-backend-tabs.rst       | 2 +-
 source/tutorials/managing-dependencies.rst | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/shared/build-backend-tabs.rst b/source/shared/build-backend-tabs.rst
index a4c49a3b4..2c58654a8 100644
--- a/source/shared/build-backend-tabs.rst
+++ b/source/shared/build-backend-tabs.rst
@@ -39,4 +39,4 @@
 
         [build-system]
         requires = ["uv_build >= 0.8.0, <0.9.0"]
-        build-backend = "uv_build"
\ No newline at end of file
+        build-backend = "uv_build"
diff --git a/source/tutorials/managing-dependencies.rst b/source/tutorials/managing-dependencies.rst
index da12d8a91..bb67a60e3 100644
--- a/source/tutorials/managing-dependencies.rst
+++ b/source/tutorials/managing-dependencies.rst
@@ -178,4 +178,4 @@ and techniques, listed in alphabetical order, to see if one of them is a better
   By contrast, Pipenv explicitly avoids making the assumption that the application
   being worked on will support distribution as a ``pip``-installable Python package.
 * `uv `__ for a single tool that covers the entire project
-  management workflow, including dependency management, packaging, and publishing.
\ No newline at end of file
+  management workflow, including dependency management, packaging, and publishing.

From f57c5bf67535b018d93d1e970352110f0774293d Mon Sep 17 00:00:00 2001
From: Clemens Brunner 
Date: Fri, 18 Jul 2025 09:04:49 +0200
Subject: [PATCH 0976/1072] Use first version that supported PEP 639

---
 source/shared/build-backend-tabs.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/shared/build-backend-tabs.rst b/source/shared/build-backend-tabs.rst
index 2c58654a8..608fcaddd 100644
--- a/source/shared/build-backend-tabs.rst
+++ b/source/shared/build-backend-tabs.rst
@@ -38,5 +38,5 @@
     .. code-block:: toml
 
         [build-system]
-        requires = ["uv_build >= 0.8.0, <0.9.0"]
+        requires = ["uv_build >= 0.7.19, <0.9.0"]
         build-backend = "uv_build"

From 9cbbdbce133316d11272545ae8bf8394fc17cbfe Mon Sep 17 00:00:00 2001
From: Clemens Brunner 
Date: Tue, 22 Jul 2025 13:40:55 +0200
Subject: [PATCH 0977/1072] Ignore linkcheck for ATLAS URL

---
 source/conf.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/source/conf.py b/source/conf.py
index 7a05613ea..21cac0e9b 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -147,6 +147,7 @@
     "https://anaconda.org",
     "https://www.cisa.gov/sbom",
     "https://developers.redhat.com/products/softwarecollections/overview",
+    "https://math-atlas.sourceforge.net/",
 ]
 linkcheck_retries = 5
 # Ignore anchors for common targets when we know they likely won't be found

From 7f675d8e701ce55924a0f8eb9f7dc995b92018e7 Mon Sep 17 00:00:00 2001
From: Clemens Brunner 
Date: Tue, 22 Jul 2025 13:53:44 +0200
Subject: [PATCH 0978/1072] Fix regex

---
 source/conf.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/conf.py b/source/conf.py
index 21cac0e9b..2995ce190 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -147,7 +147,7 @@
     "https://anaconda.org",
     "https://www.cisa.gov/sbom",
     "https://developers.redhat.com/products/softwarecollections/overview",
-    "https://math-atlas.sourceforge.net/",
+    "https://math-atlas\\.sourceforge\\.net/?",
 ]
 linkcheck_retries = 5
 # Ignore anchors for common targets when we know they likely won't be found

From fa92ece30c88874efb4611e0e679a08ad7c174e1 Mon Sep 17 00:00:00 2001
From: Clemens Brunner 
Date: Tue, 22 Jul 2025 15:24:05 +0200
Subject: [PATCH 0979/1072] Quick sanity check

---
 source/guides/installing-scientific-packages.rst | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst
index a1aeae567..152a8350c 100644
--- a/source/guides/installing-scientific-packages.rst
+++ b/source/guides/installing-scientific-packages.rst
@@ -19,8 +19,7 @@ of different levels of vectorized instructions available in modern CPUs.
 Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built
 32-bit and 64-bit binaries in the ``wheel`` format are available for all major
 operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on
-Windows, NumPy binaries are linked against the `ATLAS
-`__ BLAS/LAPACK library, restricted to SSE2
+Windows, NumPy binaries are linked against the ATLAS BLAS/LAPACK library, restricted to SSE2
 instructions, so they may not provide optimal linear algebra performance.
 
 There are a number of alternative options for obtaining scientific Python

From 0fcbcccf4c1e6253cfa1221914e5da79e6a850f9 Mon Sep 17 00:00:00 2001
From: Clemens Brunner 
Date: Tue, 22 Jul 2025 15:30:48 +0200
Subject: [PATCH 0980/1072] Verbose

---
 noxfile.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/noxfile.py b/noxfile.py
index 698e82f9d..de3106445 100644
--- a/noxfile.py
+++ b/noxfile.py
@@ -87,6 +87,7 @@ def linkcheck(session):
         "-n",
         "-W",
         "--keep-going",  # be strict
+        "-vvv",
         "source",  # where the rst files are located
         "build",  # where to put the check output
     )

From 403e8ac53f06daf832dd35a5d6b1c994ca1b6964 Mon Sep 17 00:00:00 2001
From: Clemens Brunner 
Date: Tue, 22 Jul 2025 15:35:06 +0200
Subject: [PATCH 0981/1072] Revert "Quick sanity check"

This reverts commit fa92ece30c88874efb4611e0e679a08ad7c174e1.
---
 noxfile.py                                       | 1 -
 source/guides/installing-scientific-packages.rst | 3 ++-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/noxfile.py b/noxfile.py
index de3106445..698e82f9d 100644
--- a/noxfile.py
+++ b/noxfile.py
@@ -87,7 +87,6 @@ def linkcheck(session):
         "-n",
         "-W",
         "--keep-going",  # be strict
-        "-vvv",
         "source",  # where the rst files are located
         "build",  # where to put the check output
     )
diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst
index 152a8350c..a1aeae567 100644
--- a/source/guides/installing-scientific-packages.rst
+++ b/source/guides/installing-scientific-packages.rst
@@ -19,7 +19,8 @@ of different levels of vectorized instructions available in modern CPUs.
 Starting with version 1.10.4 of NumPy and version 1.0.0 of SciPy, pre-built
 32-bit and 64-bit binaries in the ``wheel`` format are available for all major
 operating systems (Windows, macOS, and Linux) on PyPI. Note, however, that on
-Windows, NumPy binaries are linked against the ATLAS BLAS/LAPACK library, restricted to SSE2
+Windows, NumPy binaries are linked against the `ATLAS
+`__ BLAS/LAPACK library, restricted to SSE2
 instructions, so they may not provide optimal linear algebra performance.
 
 There are a number of alternative options for obtaining scientific Python

From b9bb306c0069088f5f7bc18839e94f64ab71daed Mon Sep 17 00:00:00 2001
From: Clemens Brunner 
Date: Tue, 22 Jul 2025 15:45:31 +0200
Subject: [PATCH 0982/1072] Fix ignores

---
 source/conf.py | 28 ++++++++++++++++------------
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/source/conf.py b/source/conf.py
index 2995ce190..5e79a80fe 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -132,28 +132,32 @@
 # https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-the-linkcheck-builder
 
 linkcheck_ignore = [
-    "http://localhost:\\d+",
-    "https://packaging.python.org/en/latest/specifications/schemas/.*",
-    "https://test.pypi.org/project/example-package-YOUR-USERNAME-HERE",
-    "https://pypi.org/manage/*",
-    "https://test.pypi.org/manage/*",
+    r"http://localhost:\d+",
+    r"https://packaging.python.org/en/latest/specifications/schemas/.*",
+    r"https://test.pypi.org/project/example-package-YOUR-USERNAME-HERE",
+    r"https://pypi.org/manage/.*",
+    r"https://test.pypi.org/manage/.*",
     # Temporarily ignored. Ref:
     # https://github.com/pypa/packaging.python.org/pull/1308#issuecomment-1775347690
-    "https://www.breezy-vcs.org/*",
+    r"https://www.breezy-vcs.org/.*",
     # Ignore while StackOverflow is blocking GitHub CI. Ref:
     # https://github.com/pypa/packaging.python.org/pull/1474
-    "https://stackoverflow.com/*",
-    "https://pyscaffold.org/*",
-    "https://anaconda.org",
-    "https://www.cisa.gov/sbom",
-    "https://developers.redhat.com/products/softwarecollections/overview",
-    "https://math-atlas\\.sourceforge\\.net/?",
+    r"https://stackoverflow.com/.*",
+    r"https://pyscaffold.org/.*",
+    r"https://anaconda.org",
+    r"https://www.cisa.gov/sbom",
+    r"https://developers.redhat.com/products/softwarecollections/overview",
+    r"https://math-atlas\.sourceforge\.net/?",
+    # Self-signed certificate, fails in CI
+    r"https://click\.palletsprojects\.com/.*",
+    r"https://typer\.tiangolo\.com/.*",
 ]
 linkcheck_retries = 5
 # Ignore anchors for common targets when we know they likely won't be found
 linkcheck_anchors_ignore_for_url = [
     # GitHub synthesises anchors in JavaScript, so Sphinx can't find them in the HTML
     r"https://github\.com/",
+    r"https://docs\.github\.com/",
     # While PyPI has its botscraping defenses active, Sphinx can't resolve the anchors
     # https://github.com/pypa/packaging.python.org/issues/1744
     r"https://pypi\.org/",

From 403649c5f0892f0b74e291a3dcd3338cf8e1c022 Mon Sep 17 00:00:00 2001
From: Clemens Brunner 
Date: Tue, 22 Jul 2025 15:46:48 +0200
Subject: [PATCH 0983/1072] Fix regexes

---
 source/conf.py | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/source/conf.py b/source/conf.py
index 5e79a80fe..5a7e43e91 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -133,20 +133,20 @@
 
 linkcheck_ignore = [
     r"http://localhost:\d+",
-    r"https://packaging.python.org/en/latest/specifications/schemas/.*",
-    r"https://test.pypi.org/project/example-package-YOUR-USERNAME-HERE",
-    r"https://pypi.org/manage/.*",
-    r"https://test.pypi.org/manage/.*",
+    r"https://packaging\.python\.org/en/latest/specifications/schemas/.*",
+    r"https://test\.pypi\.org/project/example-package-YOUR-USERNAME-HERE",
+    r"https://pypi\.org/manage/.*",
+    r"https://test\.pypi\.org/manage/.*",
     # Temporarily ignored. Ref:
     # https://github.com/pypa/packaging.python.org/pull/1308#issuecomment-1775347690
-    r"https://www.breezy-vcs.org/.*",
+    r"https://www\.breezy-vcs\.org/.*",
     # Ignore while StackOverflow is blocking GitHub CI. Ref:
     # https://github.com/pypa/packaging.python.org/pull/1474
-    r"https://stackoverflow.com/.*",
-    r"https://pyscaffold.org/.*",
-    r"https://anaconda.org",
-    r"https://www.cisa.gov/sbom",
-    r"https://developers.redhat.com/products/softwarecollections/overview",
+    r"https://stackoverflow\.com/.*",
+    r"https://pyscaffold\.org/.*",
+    r"https://anaconda\.org",
+    r"https://www\.cisa\.gov/sbom",
+    r"https://developers\.redhat\.com/products/softwarecollections/overview",
     r"https://math-atlas\.sourceforge\.net/?",
     # Self-signed certificate, fails in CI
     r"https://click\.palletsprojects\.com/.*",

From 2fb1f527789c65d558ae20bb6708887e134aed2f Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Tue, 22 Jul 2025 14:34:01 -0400
Subject: [PATCH 0984/1072] add an example project-status-reason

---
 source/specifications/simple-repository-api.rst | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/source/specifications/simple-repository-api.rst b/source/specifications/simple-repository-api.rst
index afc932e4e..f9a32bc78 100644
--- a/source/specifications/simple-repository-api.rst
+++ b/source/specifications/simple-repository-api.rst
@@ -20,7 +20,7 @@ retrieving packages from an index server comes in two forms:
 Base API
 ========
 
-A repository that implements the simple API is defined by its base URL, this is
+A repository that implements the simple API is defined by its base URL. This is
 the top level URL that all additional URLs are below. The API is named the
 "simple" repository due to the fact that PyPI's base URL is
 ``https://pypi.org/simple/``.
@@ -636,7 +636,8 @@ As an example:
     {
       "meta": {
         "api-version": "1.4",
-        "project-status": "active"
+        "project-status": "active",
+        "project-status-reason": "this project is not yet haunted"
       },
       "name": "holygrail",
       "files": [

From 3a66caf08a8668aff7c43a50dd756079bf79b7b0 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Thu, 24 Jul 2025 17:12:43 -0400
Subject: [PATCH 0985/1072] Update
 source/specifications/simple-repository-api.rst

Co-authored-by: Alyssa Coghlan 
---
 source/specifications/simple-repository-api.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/source/specifications/simple-repository-api.rst b/source/specifications/simple-repository-api.rst
index f9a32bc78..4f5bb0043 100644
--- a/source/specifications/simple-repository-api.rst
+++ b/source/specifications/simple-repository-api.rst
@@ -1026,3 +1026,4 @@ History
   from a package, in :pep:`714`
 * November 2024: provenance metadata in the HTML and JSON formats, in :pep:`740`
 * July 2025: project status markers in the HTML and JSON formats, in :pep:`792`
+* July 2025: layout changes (dedicated page for file yanking, introduce concepts before API details)

From 8f7b5a833a30ea541dcfd4db7b7d42e5533cc535 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Thu, 24 Jul 2025 17:23:54 -0400
Subject: [PATCH 0986/1072] fix broken anchor

---
 ...stribution-releases-using-github-actions-ci-cd-workflows.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
index 1ee562cf7..e9f601e03 100644
--- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
+++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
@@ -75,7 +75,7 @@ Let's begin! 🚀
 
    .. attention::
 
-      For security reasons, you must require `manual approval `_
+      For security reasons, you must require `manual approval `_
       on each run for the ``pypi`` environment.
 
 

From 79f33bd76d31f4312faa5ab8464121651dc9c3e9 Mon Sep 17 00:00:00 2001
From: Clemens Brunner 
Date: Thu, 31 Jul 2025 10:11:17 +0200
Subject: [PATCH 0987/1072] Revert unrelated changes

---
 source/conf.py | 24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/source/conf.py b/source/conf.py
index 5a7e43e91..8b20a28b3 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -132,23 +132,22 @@
 # https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-the-linkcheck-builder
 
 linkcheck_ignore = [
-    r"http://localhost:\d+",
-    r"https://packaging\.python\.org/en/latest/specifications/schemas/.*",
-    r"https://test\.pypi\.org/project/example-package-YOUR-USERNAME-HERE",
-    r"https://pypi\.org/manage/.*",
-    r"https://test\.pypi\.org/manage/.*",
+    "http://localhost:\\d+",
+    "https://packaging.python.org/en/latest/specifications/schemas/.*",
+    "https://test.pypi.org/project/example-package-YOUR-USERNAME-HERE",
+    "https://pypi.org/manage/*",
+    "https://test.pypi.org/manage/*",
     # Temporarily ignored. Ref:
     # https://github.com/pypa/packaging.python.org/pull/1308#issuecomment-1775347690
-    r"https://www\.breezy-vcs\.org/.*",
+    "https://www.breezy-vcs.org/*",
     # Ignore while StackOverflow is blocking GitHub CI. Ref:
     # https://github.com/pypa/packaging.python.org/pull/1474
-    r"https://stackoverflow\.com/.*",
-    r"https://pyscaffold\.org/.*",
-    r"https://anaconda\.org",
-    r"https://www\.cisa\.gov/sbom",
-    r"https://developers\.redhat\.com/products/softwarecollections/overview",
+    "https://stackoverflow.com/*",
+    "https://pyscaffold.org/*",
+    "https://anaconda.org",
+    "https://www.cisa.gov/sbom",
+    "https://developers.redhat.com/products/softwarecollections/overview",
     r"https://math-atlas\.sourceforge\.net/?",
-    # Self-signed certificate, fails in CI
     r"https://click\.palletsprojects\.com/.*",
     r"https://typer\.tiangolo\.com/.*",
 ]
@@ -157,7 +156,6 @@
 linkcheck_anchors_ignore_for_url = [
     # GitHub synthesises anchors in JavaScript, so Sphinx can't find them in the HTML
     r"https://github\.com/",
-    r"https://docs\.github\.com/",
     # While PyPI has its botscraping defenses active, Sphinx can't resolve the anchors
     # https://github.com/pypa/packaging.python.org/issues/1744
     r"https://pypi\.org/",

From c44686e6759fa75cd377bae84693928fed5bb826 Mon Sep 17 00:00:00 2001
From: Clemens Brunner 
Date: Thu, 31 Jul 2025 10:18:15 +0200
Subject: [PATCH 0988/1072] Add docs.github.com

---
 source/conf.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/source/conf.py b/source/conf.py
index 8b20a28b3..961e2e0a6 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -156,6 +156,7 @@
 linkcheck_anchors_ignore_for_url = [
     # GitHub synthesises anchors in JavaScript, so Sphinx can't find them in the HTML
     r"https://github\.com/",
+    r"https://docs\.github\.com/",
     # While PyPI has its botscraping defenses active, Sphinx can't resolve the anchors
     # https://github.com/pypa/packaging.python.org/issues/1744
     r"https://pypi\.org/",

From 6e2333a3b3bec72a63789f10455c27a9e5c69c4d Mon Sep 17 00:00:00 2001
From: Clemens Brunner 
Date: Thu, 31 Jul 2025 14:58:34 +0200
Subject: [PATCH 0989/1072] Convert linkcheck_ignore entries to regexes

---
 source/conf.py | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/source/conf.py b/source/conf.py
index 961e2e0a6..4c6d8bea4 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -132,21 +132,21 @@
 # https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-the-linkcheck-builder
 
 linkcheck_ignore = [
-    "http://localhost:\\d+",
-    "https://packaging.python.org/en/latest/specifications/schemas/.*",
-    "https://test.pypi.org/project/example-package-YOUR-USERNAME-HERE",
-    "https://pypi.org/manage/*",
-    "https://test.pypi.org/manage/*",
+    r"http://localhost:\d+",
+    r"https://packaging\.python\.org/en/latest/specifications/schemas/.*",
+    r"https://test\.pypi\.org/project/example-package-YOUR-USERNAME-HERE",
+    r"https://pypi\.org/manage/.*",
+    r"https://test\.pypi\.org/manage/.*",
     # Temporarily ignored. Ref:
     # https://github.com/pypa/packaging.python.org/pull/1308#issuecomment-1775347690
-    "https://www.breezy-vcs.org/*",
+    r"https://www\.breezy-vcs\.org/.*",
     # Ignore while StackOverflow is blocking GitHub CI. Ref:
     # https://github.com/pypa/packaging.python.org/pull/1474
-    "https://stackoverflow.com/*",
-    "https://pyscaffold.org/*",
-    "https://anaconda.org",
-    "https://www.cisa.gov/sbom",
-    "https://developers.redhat.com/products/softwarecollections/overview",
+    r"https://stackoverflow\.com/.*",
+    r"https://pyscaffold\.org/.*",
+    r"https://anaconda\.org",
+    r"https://www\.cisa\.gov/sbom",
+    r"https://developers\.redhat\.com/products/softwarecollections/overview",
     r"https://math-atlas\.sourceforge\.net/?",
     r"https://click\.palletsprojects\.com/.*",
     r"https://typer\.tiangolo\.com/.*",

From 1c6736c7aefb0086b1ded32676732ad0b1072e02 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edgar=20Ram=C3=ADrez=20Mondrag=C3=B3n?=
 
Date: Sun, 3 Aug 2025 18:56:00 -0600
Subject: [PATCH 0990/1072] Host PyPA spec schemas in packaging.python.org/

---
 source/conf.py                                |   4 -
 source/specifications/build-details/v1.0.rst  |   2 +-
 .../direct-url-data-structure.rst             | 117 +-----
 source/specifications/index.rst               |   1 +
 .../schemas/build-details-v1.0.schema.json    |   0
 .../schemas/direct-url.schema.json            |  99 +++++
 source/specifications/schemas/index.rst       |   8 +
 .../specifications/schemas/pylock.schema.json | 345 ++++++++++++++++++
 8 files changed, 455 insertions(+), 121 deletions(-)
 rename {extra => source}/specifications/schemas/build-details-v1.0.schema.json (100%)
 create mode 100644 source/specifications/schemas/direct-url.schema.json
 create mode 100644 source/specifications/schemas/index.rst
 create mode 100644 source/specifications/schemas/pylock.schema.json

diff --git a/source/conf.py b/source/conf.py
index 4c6d8bea4..a8a040d6c 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -83,10 +83,6 @@
     # https://plausible.io/packaging.python.org
     html_js_files.extend(_metrics_js_files)
 
-html_extra_path = [
-    "../extra",
-]
-
 # -- Options for HTML help output ------------------------------------------------------
 # https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-html-help-output
 
diff --git a/source/specifications/build-details/v1.0.rst b/source/specifications/build-details/v1.0.rst
index 3a8cfe277..cfe902e1e 100644
--- a/source/specifications/build-details/v1.0.rst
+++ b/source/specifications/build-details/v1.0.rst
@@ -8,7 +8,7 @@
 Specification
 -------------
 
-.. jsonschema:: ../../../extra/specifications/schemas/build-details-v1.0.schema.json
+.. jsonschema:: ../schemas/build-details-v1.0.schema.json
     :lift_title: false
 
 
diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index 0d243652d..5f3af0fae 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -236,122 +236,7 @@ JSON Schema
 
 The following JSON Schema can be used to validate the contents of ``direct_url.json``:
 
-.. code-block::
-
-     {
-       "$schema": "https://json-schema.org/draft/2019-09/schema",
-       "title": "Direct URL Data",
-       "description": "Data structure that can represent URLs to python projects and distribution artifacts such as VCS source trees, local source trees, source distributions and wheels.",
-       "definitions": {
-         "URL": {
-           "type": "string",
-           "format": "uri"
-         },
-         "DirInfo": {
-           "type": "object",
-           "properties": {
-             "editable": {
-               "type": ["boolean", "null"]
-             }
-           }
-         },
-         "VCSInfo": {
-           "type": "object",
-           "properties": {
-             "vcs": {
-               "type": "string",
-               "enum": [
-                 "git",
-                 "hg",
-                 "bzr",
-                 "svn"
-               ]
-             },
-             "requested_revision": {
-               "type": "string"
-             },
-             "commit_id": {
-               "type": "string"
-             },
-             "resolved_revision": {
-               "type": "string"
-             }
-           },
-           "required": [
-             "vcs",
-             "commit_id"
-           ]
-         },
-         "ArchiveInfo": {
-           "type": "object",
-           "properties": {
-             "hash": {
-               "type": "string",
-               "pattern": "^\\w+=[a-f0-9]+$",
-               "deprecated": true
-             },
-             "hashes": {
-               "type": "object",
-               "patternProperties": {
-                 "^[a-f0-9]+$": {
-                   "type": "string"
-                 }
-               }
-             }
-           }
-         }
-       },
-       "allOf": [
-         {
-           "type": "object",
-           "properties": {
-             "url": {
-               "$ref": "#/definitions/URL"
-             }
-           },
-           "required": [
-             "url"
-           ]
-         },
-         {
-           "anyOf": [
-             {
-               "type": "object",
-               "properties": {
-                 "dir_info": {
-                   "$ref": "#/definitions/DirInfo"
-                 }
-               },
-               "required": [
-                 "dir_info"
-               ]
-             },
-             {
-               "type": "object",
-               "properties": {
-                 "vcs_info": {
-                   "$ref": "#/definitions/VCSInfo"
-                 }
-               },
-               "required": [
-                 "vcs_info"
-               ]
-             },
-             {
-               "type": "object",
-               "properties": {
-                 "archive_info": {
-                   "$ref": "#/definitions/ArchiveInfo"
-                 }
-               },
-               "required": [
-                 "archive_info"
-               ]
-             }
-           ]
-         }
-       ]
-     }
+.. literalinclude:: schemas/direct-url.schema.json
 
 Examples
 ========
diff --git a/source/specifications/index.rst b/source/specifications/index.rst
index 68d95ab98..c375654a2 100644
--- a/source/specifications/index.rst
+++ b/source/specifications/index.rst
@@ -17,3 +17,4 @@ and for proposing new ones, is documented on
    section-package-indices
    section-python-description-formats
    section-reproducible-environments
+   schemas/index.rst
diff --git a/extra/specifications/schemas/build-details-v1.0.schema.json b/source/specifications/schemas/build-details-v1.0.schema.json
similarity index 100%
rename from extra/specifications/schemas/build-details-v1.0.schema.json
rename to source/specifications/schemas/build-details-v1.0.schema.json
diff --git a/source/specifications/schemas/direct-url.schema.json b/source/specifications/schemas/direct-url.schema.json
new file mode 100644
index 000000000..d1f4c860a
--- /dev/null
+++ b/source/specifications/schemas/direct-url.schema.json
@@ -0,0 +1,99 @@
+{
+  "$schema": "https://json-schema.org/draft/2019-09/schema",
+  "$id": "https://packaging.python.org/en/latest/specifications/schemas/direct-url.schema.json",
+  "title": "Direct URL Data",
+  "description": "Data structure that can represent URLs to python projects and distribution artifacts such as VCS source trees, local source trees, source distributions and wheels.",
+  "definitions": {
+    "url": {
+      "type": "string",
+      "format": "uri"
+    },
+    "DirInfo": {
+      "type": "object",
+      "properties": {
+        "editable": {
+          "type": ["boolean", "null"]
+        }
+      }
+    },
+    "VCSInfo": {
+      "type": "object",
+      "properties": {
+        "vcs": {
+          "type": "string",
+          "enum": ["git", "hg", "bzr", "svn"]
+        },
+        "requested_revision": {
+          "type": "string"
+        },
+        "commit_id": {
+          "type": "string"
+        },
+        "resolved_revision": {
+          "type": "string"
+        }
+      },
+      "required": ["vcs", "commit_id"]
+    },
+    "ArchiveInfo": {
+      "type": "object",
+      "properties": {
+        "hash": {
+          "type": "string",
+          "pattern": "^\\w+=[a-f0-9]+$",
+          "deprecated": true
+        },
+        "hashes": {
+          "type": "object",
+          "patternProperties": {
+            "^[a-f0-9]+$": {
+              "type": "string"
+            }
+          }
+        }
+      }
+    }
+  },
+  "allOf": [
+    {
+      "type": "object",
+      "properties": {
+        "url": {
+          "$ref": "#/definitions/url"
+        }
+      },
+      "required": ["url"]
+    },
+    {
+      "anyOf": [
+        {
+          "type": "object",
+          "properties": {
+            "dir_info": {
+              "$ref": "#/definitions/DirInfo"
+            }
+          },
+          "required": ["dir_info"]
+        },
+        {
+          "type": "object",
+          "properties": {
+            "vcs_info": {
+              "$ref": "#/definitions/VCSInfo"
+            }
+          },
+          "required": ["vcs_info"]
+        },
+        {
+          "type": "object",
+          "properties": {
+            "archive_info": {
+              "$ref": "#/definitions/ArchiveInfo"
+            }
+          },
+          "required": ["archive_info"]
+        }
+      ]
+    }
+  ]
+}
diff --git a/source/specifications/schemas/index.rst b/source/specifications/schemas/index.rst
new file mode 100644
index 000000000..a80891975
--- /dev/null
+++ b/source/specifications/schemas/index.rst
@@ -0,0 +1,8 @@
+.. _`packaging-schemas`:
+
+PyPA schemas
+############
+
+- `direct_url.json `_
+- `build-details.json `_
+- `pylock.toml `_
diff --git a/source/specifications/schemas/pylock.schema.json b/source/specifications/schemas/pylock.schema.json
new file mode 100644
index 000000000..5469111ec
--- /dev/null
+++ b/source/specifications/schemas/pylock.schema.json
@@ -0,0 +1,345 @@
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "$id": "https://json.schemastore.org/pylock.json",
+  "additionalProperties": false,
+  "definitions": {
+    "tool": {
+      "type": "object",
+      "markdownDescription": "Similar usage as that of the `[tool]` table from the [pyproject.toml specification](https://packaging.python.org/en/latest/specifications/pyproject-toml/#pyproject-toml-spec), but at the package version level instead of at the lock file level (which is also available via `[tool]`).",
+      "additionalProperties": {
+        "type": "object",
+        "additionalProperties": true
+      }
+    },
+    "url": {
+      "type": "string",
+      "markdownDescription": "The URL to the source tree."
+    },
+    "path": {
+      "type": "string",
+      "markdownDescription": "The path to the local directory of the source tree."
+    },
+    "upload-time": {
+      "markdownDescription": "The time the file was uploaded (UTC). Must be specified as a datetime literal."
+    },
+    "size": {
+      "type": "integer",
+      "markdownDescription": "The size of the archive file."
+    },
+    "hashes": {
+      "type": "object",
+      "description": "Known hash values of the file where the key is the hash algorithm and the value is the hash value.",
+      "additionalProperties": {
+        "type": "string"
+      }
+    },
+    "subdirectory": {
+      "type": "string",
+      "markdownDescription": "The subdirectory within the [source tree](https://packaging.python.org/en/latest/specifications/source-distribution-format/#source-distribution-format-source-tree) where the project root of the project is (e.g. the location of the `pyproject.toml` file)."
+    },
+    "vcs": {
+      "type": "object",
+      "markdownDescription": "Record the version control system details for the [source tree](https://packaging.python.org/en/latest/specifications/source-distribution-format/#source-distribution-format-source-tree) it contains.",
+      "additionalProperties": false,
+      "properties": {
+        "type": {
+          "type": "string",
+          "markdownDescription": "The type of version control system used."
+        },
+        "url": {
+          "$ref": "#/definitions/url"
+        },
+        "path": {
+          "$ref": "#/definitions/path"
+        },
+        "requested-revision": {
+          "type": "string",
+          "markdownDescription": "The branch/tag/ref/commit/revision/etc. that the user requested."
+        },
+        "commit-id": {
+          "type": "string",
+          "markdownDescription": "The exact commit/revision number that is to be installed."
+        },
+        "subdirectory": {
+          "$ref": "#/definitions/subdirectory"
+        }
+      }
+    },
+    "directory": {
+      "type": "object",
+      "markdownDescription": "Record the local directory details for the [source tree](https://packaging.python.org/en/latest/specifications/source-distribution-format/#source-distribution-format-source-tree) it contains.",
+      "additionalProperties": false,
+      "properties": {
+        "path": {
+          "type": "string",
+          "markdownDescription": "The local directory where the source tree is."
+        },
+        "editable": {
+          "type": "boolean",
+          "default": false,
+          "markdownDescription": "A flag representing whether the source tree was an editable install at lock time."
+        },
+        "subdirectory": {
+          "$ref": "#/definitions/subdirectory"
+        }
+      }
+    },
+    "archive": {
+      "type": "object",
+      "additionalProperties": false,
+      "markdownDescription": "A direct reference to an archive file to install from (this can include wheels and sdists, as well as other archive formats containing a source tree).",
+      "properties": {
+        "url": {
+          "$ref": "#/definitions/url"
+        },
+        "path": {
+          "$ref": "#/definitions/path"
+        },
+        "size": {
+          "$ref": "#/definitions/size"
+        },
+        "upload-time": {
+          "$ref": "#/definitions/upload-time"
+        },
+        "hashes": {
+          "$ref": "#/definitions/hashes"
+        },
+        "subdirectory": {
+          "$ref": "#/definitions/subdirectory"
+        }
+      }
+    },
+    "sdist": {
+      "type": "object",
+      "additionalProperties": false,
+      "markdownDescription": "Details of a [source distribution file name](https://packaging.python.org/en/latest/specifications/source-distribution-format/#source-distribution-format-sdist) for the package.",
+      "properties": {
+        "name": {
+          "type": "string",
+          "markdownDescription": "The file name of the [source distribution file name](https://packaging.python.org/en/latest/specifications/source-distribution-format/#source-distribution-format-sdist) file."
+        },
+        "upload-time": {
+          "$ref": "#/definitions/upload-time"
+        },
+        "url": {
+          "$ref": "#/definitions/url"
+        },
+        "path": {
+          "$ref": "#/definitions/path"
+        },
+        "size": {
+          "$ref": "#/definitions/size"
+        },
+        "hashes": {
+          "$ref": "#/definitions/hashes"
+        }
+      }
+    },
+    "wheels": {
+      "type": "array",
+      "markdownDescription": "For recording the wheel files as specified by [Binary distribution format](https://packaging.python.org/en/latest/specifications/binary-distribution-format/#binary-distribution-format) for the package.",
+      "items": {
+        "type": "object",
+        "additionalProperties": false,
+        "properties": {
+          "name": {
+            "type": "string",
+            "markdownDescription": "The file name of the [Binary distribution format](https://packaging.python.org/en/latest/specifications/binary-distribution-format/#binary-distribution-format) file."
+          },
+          "upload-time": {
+            "$ref": "#/definitions/upload-time"
+          },
+          "url": {
+            "$ref": "#/definitions/url"
+          },
+          "path": {
+            "$ref": "#/definitions/path"
+          },
+          "size": {
+            "$ref": "#/definitions/size"
+          },
+          "hashes": {
+            "$ref": "#/definitions/hashes"
+          }
+        }
+      }
+    },
+    "1.0": {
+      "required": ["lock-version", "created-by", "packages"],
+      "properties": {
+        "lock-version": {
+          "type": "string",
+          "enum": ["1.0"],
+          "description": "Record the file format version that the file adheres to."
+        },
+        "environments": {
+          "type": "array",
+          "markdownDescription": "A list of [environment markers](https://packaging.python.org/en/latest/specifications/dependency-specifiers/#dependency-specifiers-environment-markers) for which the lock file is considered compatible with.",
+          "items": {
+            "type": "string",
+            "description": "Environment marker"
+          }
+        },
+        "requires-python": {
+          "type": "string",
+          "markdownDescription": "Specifies the [Requires-Python](https://packaging.python.org/en/latest/specifications/core-metadata/#core-metadata-requires-python) for the minimum Python version compatible for any environment supported by the lock file (i.e. the minimum viable Python version for the lock file)."
+        },
+        "extras": {
+          "type": "array",
+          "markdownDescription": "The list of [extras](https://packaging.python.org/en/latest/specifications/core-metadata/#core-metadata-provides-extra) supported by this lock file.",
+          "default": [],
+          "items": {
+            "type": "string",
+            "description": "Extra name"
+          }
+        },
+        "dependency-groups": {
+          "type": "array",
+          "markdownDescription": "The list of [dependency groups](https://packaging.python.org/en/latest/specifications/dependency-groups/#dependency-groups) publicly supported by this lock file (i.e. dependency groups users are expected to be able to specify via a tool’s UI).",
+          "default": [],
+          "items": {
+            "type": "string",
+            "description": "Dependency group name"
+          }
+        },
+        "default-groups": {
+          "type": "array",
+          "markdownDescription": "The name of synthetic dependency groups to represent what should be installed by default (e.g. what `project.dependencies` implicitly represents).",
+          "default": [],
+          "items": {
+            "type": "string",
+            "description": "Dependency group name"
+          }
+        },
+        "created-by": {
+          "type": "string",
+          "markdownDescription": "Records the name of the tool used to create the lock file."
+        },
+        "packages": {
+          "type": "array",
+          "markdownDescription": "An array containing all packages that may be installed.",
+          "items": {
+            "type": "object",
+            "additionalProperties": false,
+            "required": ["name"],
+            "allOf": [
+              {
+                "if": {
+                  "required": ["vcs"]
+                },
+                "then": {
+                  "not": {
+                    "required": ["directory", "archive", "sdist", "wheels"]
+                  }
+                }
+              },
+              {
+                "if": {
+                  "required": ["directory"]
+                },
+                "then": {
+                  "not": {
+                    "required": ["vcs", "archive", "sdist", "wheels"]
+                  }
+                }
+              },
+              {
+                "if": {
+                  "required": ["sdist"]
+                },
+                "then": {
+                  "not": {
+                    "required": ["vcs", "directory", "archive"]
+                  }
+                }
+              },
+              {
+                "if": {
+                  "required": ["wheels"]
+                },
+                "then": {
+                  "not": {
+                    "required": ["vcs", "directory", "archive"]
+                  }
+                }
+              }
+            ],
+            "properties": {
+              "name": {
+                "type": "string",
+                "markdownDescription": "The name of the package, [normalized](https://packaging.python.org/en/latest/specifications/name-normalization/#name-normalization)."
+              },
+              "version": {
+                "type": "string",
+                "description": "The version of the package."
+              },
+              "marker": {
+                "type": "string",
+                "markdownDescription": "The [environment marker](https://packaging.python.org/en/latest/specifications/dependency-specifiers/#dependency-specifiers-environment-markers) which specify when the package should be installed."
+              },
+              "requires-python": {
+                "type": "string",
+                "markdownDescription": "Holds the [version specifiers](https://packaging.python.org/en/latest/specifications/version-specifiers/#version-specifiers) for Python version compatibility for the package."
+              },
+              "dependencies": {
+                "type": "array",
+                "markdownDescription": "Records the other entries in `[[packages]]` which are direct dependencies of this package.",
+                "items": {
+                  "type": "object",
+                  "markdownDescription": "A table which contains the minimum information required to tell which other package entry it corresponds to where doing a key-by-key comparison would find the appropriate package with no ambiguity (e.g. if there are two entries for the `spam` package, then you can include the version number like `{name = \"spam\", version = \"1.0.0\"}`, or by source like `{name = \"spam\", vcs = { url = \"...\"}`).",
+                  "additionalProperties": true
+                }
+              },
+              "vcs": {
+                "$ref": "#/definitions/vcs"
+              },
+              "directory": {
+                "$ref": "#/definitions/directory"
+              },
+              "archive": {
+                "$ref": "#/definitions/archive"
+              },
+              "index": {
+                "type": "string",
+                "markdownDescription": "The base URL for the package index from [simple repository API](https://packaging.python.org/en/latest/specifications/simple-repository-api/#simple-repository-api) where the sdist and/or wheels were found (e.g. `https://pypi.org/simple/`)."
+              },
+              "sdist": {
+                "$ref": "#/definitions/sdist"
+              },
+              "wheels": {
+                "$ref": "#/definitions/wheels"
+              },
+              "attestation-identities": {
+                "type": "array",
+                "markdownDescription": "A recording of the attestations for any file recorded for this package.",
+                "items": {
+                  "type": "object",
+                  "additionalProperties": false,
+                  "required": ["kind"],
+                  "properties": {
+                    "kind": {
+                      "type": "string",
+                      "markdownDescription": "The unique identity of the Trusted Publisher."
+                    }
+                  }
+                }
+              },
+              "tool": {
+                "$ref": "#/definitions/tool"
+              }
+            }
+          }
+        },
+        "tool": {
+          "$ref": "#/definitions/tool"
+        }
+      }
+    }
+  },
+  "oneOf": [
+    {
+      "$ref": "#/definitions/1.0"
+    }
+  ],
+  "type": "object"
+}

From afab730d8ebff66e79ec03527d3628544d17eaac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edgar=20Ram=C3=ADrez=20Mondrag=C3=B3n?=
 
Date: Sun, 3 Aug 2025 19:16:39 -0600
Subject: [PATCH 0991/1072] Fix broken setuptools-scm link

---
 source/discussions/setup-py-deprecated.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/setup-py-deprecated.rst b/source/discussions/setup-py-deprecated.rst
index 6bcd15b58..dbea4ed52 100644
--- a/source/discussions/setup-py-deprecated.rst
+++ b/source/discussions/setup-py-deprecated.rst
@@ -115,7 +115,7 @@ A possible replacement solution (among others) is to rely on setuptools-scm_:
 
 * ``python -m setuptools_scm``
 
-.. _setuptools-scm: https://setuptools-scm.readthedocs.io/en/latest/usage/#as-cli-tool
+.. _setuptools-scm: https://setuptools-scm.readthedocs.io/en/latest/usage.html#as-cli-tool
 
 
 Remaining commands

From daeac9dcd39f9bc3f7dcf44397b4912cd7d8559d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edgar=20Ram=C3=ADrez=20Mondrag=C3=B3n?=
 
Date: Wed, 6 Aug 2025 12:56:12 -0600
Subject: [PATCH 0992/1072] Update source/discussions/setup-py-deprecated.rst

Co-authored-by: Alyssa Coghlan 
---
 source/discussions/setup-py-deprecated.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/discussions/setup-py-deprecated.rst b/source/discussions/setup-py-deprecated.rst
index dbea4ed52..b13ce190b 100644
--- a/source/discussions/setup-py-deprecated.rst
+++ b/source/discussions/setup-py-deprecated.rst
@@ -115,7 +115,7 @@ A possible replacement solution (among others) is to rely on setuptools-scm_:
 
 * ``python -m setuptools_scm``
 
-.. _setuptools-scm: https://setuptools-scm.readthedocs.io/en/latest/usage.html#as-cli-tool
+.. _setuptools-scm: https://setuptools-scm.readthedocs.io/en/latest/usage#as-cli-tool
 
 
 Remaining commands

From e1f29ae1486a5f55bd61359d8bdabf24da1bced3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edgar=20Ram=C3=ADrez=20Mondrag=C3=B3n?=
 
Date: Wed, 6 Aug 2025 14:04:07 -0600
Subject: [PATCH 0993/1072] Link to our own copy of the schema

Co-authored-by: Alyssa Coghlan 
---
 source/specifications/schemas/pylock.schema.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/schemas/pylock.schema.json b/source/specifications/schemas/pylock.schema.json
index 5469111ec..90404e33d 100644
--- a/source/specifications/schemas/pylock.schema.json
+++ b/source/specifications/schemas/pylock.schema.json
@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "https://json.schemastore.org/pylock.json",
+  "$id": "https://packaging.python.org/en/latest/specifications/schemas/pylock.schema.json",
   "additionalProperties": false,
   "definitions": {
     "tool": {

From 99299e312d93875fb37575732b9968a89ecfe07c Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 7 Jul 2025 18:28:30 +0000
Subject: [PATCH 0994/1072] [pre-commit.ci] pre-commit autoupdate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

updates:
- [github.com/codespell-project/codespell: v2.3.0 → v2.4.1](https://github.com/codespell-project/codespell/compare/v2.3.0...v2.4.1)
- [github.com/astral-sh/ruff-pre-commit: v0.7.1 → v0.12.2](https://github.com/astral-sh/ruff-pre-commit/compare/v0.7.1...v0.12.2)
---
 .pre-commit-config.yaml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index db8b1131a..e092c419c 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -15,7 +15,7 @@ repos:
   - id: trailing-whitespace
 
 - repo: https://github.com/codespell-project/codespell
-  rev: v2.3.0
+  rev: v2.4.1
   hooks:
   - id: codespell
     args: ["-L", "ned,ist,oder", "--skip", "*.po"]
@@ -37,7 +37,7 @@ repos:
   - id: rst-inline-touching-normal
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.7.1
+  rev: v0.12.2
   hooks:
     - id: ruff
     - id: ruff-format

From 00e971710a09c835a06e1268c174b720fc0aa53a Mon Sep 17 00:00:00 2001
From: Dustin Ingram 
Date: Thu, 21 Aug 2025 17:40:45 +0000
Subject: [PATCH 0995/1072] Correct regex for metadata 'name' format

The current regex permits strings that end in the newline character,
which is counter to what the description for the field states ("ASCII
letters and numbers, period, underscore and hyphen").

This updates the rexex to use `\Z` instead of `$` to match at the end of
the string and exclude newline characters.
---
 source/specifications/name-normalization.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/name-normalization.rst b/source/specifications/name-normalization.rst
index ba3246b63..e295a3d11 100644
--- a/source/specifications/name-normalization.rst
+++ b/source/specifications/name-normalization.rst
@@ -17,7 +17,7 @@ underscore and hyphen. It must start and end with a letter or number.
 This means that valid project names are limited to those which match the
 following regex (run with :py:data:`re.IGNORECASE`)::
 
-    ^([A-Z0-9]|[A-Z0-9][A-Z0-9._-]*[A-Z0-9])$
+    ^([A-Z0-9]|[A-Z0-9][A-Z0-9._-]*[A-Z0-9])\Z
 
 
 .. _name-normalization:

From fb63fa51d867197d98888d7978dba10449374b67 Mon Sep 17 00:00:00 2001
From: Dustin Ingram 
Date: Thu, 21 Aug 2025 17:53:46 +0000
Subject: [PATCH 0996/1072] Update regex from PEP 508 as well

---
 source/specifications/dependency-specifiers.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst
index 06897da27..168d966d4 100644
--- a/source/specifications/dependency-specifiers.rst
+++ b/source/specifications/dependency-specifiers.rst
@@ -142,7 +142,7 @@ document we limit the acceptable values for identifiers to that regex. A full
 redefinition of name may take place in a future metadata PEP. The regex (run
 with re.IGNORECASE) is::
 
-    ^([A-Z0-9]|[A-Z0-9][A-Z0-9._-]*[A-Z0-9])$
+    ^([A-Z0-9]|[A-Z0-9][A-Z0-9._-]*[A-Z0-9])\Z
 
 .. _dependency-specifiers-extras:
 

From f86255b40639f1ed962496a465d67c16d443ce7d Mon Sep 17 00:00:00 2001
From: Dustin Ingram 
Date: Thu, 21 Aug 2025 18:33:17 +0000
Subject: [PATCH 0997/1072] Add history blurbs

---
 source/specifications/dependency-specifiers.rst | 3 +++
 source/specifications/name-normalization.rst    | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst
index e1b69ff61..d9466c26e 100644
--- a/source/specifications/dependency-specifiers.rst
+++ b/source/specifications/dependency-specifiers.rst
@@ -526,6 +526,9 @@ History
   in use since late 2022.
 - April 2025: Added ``extras`` and ``dependency_groups`` for
   :ref:`lock-file-spec` as approved through :pep:`751`.
+- August 2025: The suggested name validation regex was fixed to match the field
+  specification (it previously finished with ``$`` instead of ``\Z``,
+  incorrectly permitting trailing newlines)
 
 
 References
diff --git a/source/specifications/name-normalization.rst b/source/specifications/name-normalization.rst
index e295a3d11..560d956b5 100644
--- a/source/specifications/name-normalization.rst
+++ b/source/specifications/name-normalization.rst
@@ -53,3 +53,6 @@ History
   :pep:`503 <503#normalized-names>`.
 - November 2015: The specification of valid names was approved through
   :pep:`508 <508#names>`.
+- August 2025: The suggested name validation regex was fixed to match the field
+  specification (it previously finished with ``$`` instead of ``\Z``,
+  incorrectly permitting trailing newlines)

From 8290c3face8bf5d6580f07bb9892bcbb9af90b37 Mon Sep 17 00:00:00 2001
From: konstin 
Date: Mon, 25 Aug 2025 18:20:46 +0200
Subject: [PATCH 0998/1072] Update uv_build version automatically

In https://github.com/pypa/packaging.python.org/pull/1880, the concern was raised that the uv_build upper bound in the docs will go stale. This PR adds a GitHub Actions workflow that automatically updates the version daily with the latest uv(-build) version.

I tested this change on my fork, but I unfortunately can't test this in pypa/packaging.python.org itself.
---
 .github/workflows/cron.yml         | 26 ++++++++++++++
 scripts/update_uv_build_version.py | 56 ++++++++++++++++++++++++++++++
 2 files changed, 82 insertions(+)
 create mode 100644 scripts/update_uv_build_version.py

diff --git a/.github/workflows/cron.yml b/.github/workflows/cron.yml
index 8870bb70b..6074c3fbb 100644
--- a/.github/workflows/cron.yml
+++ b/.github/workflows/cron.yml
@@ -5,10 +5,36 @@ name: Cron
 on:
   schedule:
   - cron: "0 6 * * *"  # daily at 6am
+  workflow_dispatch:
 
 jobs:
   test:
     if: github.repository_owner == 'pypa'  # suppress noise in forks
     uses: ./.github/workflows/test.yml
 
+  update-uv-build-version:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: write
+      pull-requests: write
+    steps:
+      - uses: actions/checkout@v4
+      - uses: astral-sh/setup-uv@v5
+      - name: Update uv_build version
+        id: update_script
+        run: uv run scripts/update_uv_build_version.py
+      - # If there are no changes, no pull request will be created and the action exits silently.
+        name: Create Pull Request
+        uses: peter-evans/create-pull-request@v7
+        with:
+          token: ${{ secrets.GITHUB_TOKEN }}
+          commit-message: Update uv_build version to ${{ steps.update_script.outputs.version }}
+          title: Update uv_build version to ${{ steps.update_script.outputs.version }}
+          body: |
+            Automated update of uv_build version bounds for uv ${{ steps.update_script.outputs.version }}.
+            
+            This PR was created automatically by the cron workflow, ping `@konstin` for problems.
+          branch: bot/update-uv-build-version
+          delete-branch: true
+
 ...
diff --git a/scripts/update_uv_build_version.py b/scripts/update_uv_build_version.py
new file mode 100644
index 000000000..f71cb821a
--- /dev/null
+++ b/scripts/update_uv_build_version.py
@@ -0,0 +1,56 @@
+# /// script
+# requires-python = ">=3.12"
+# dependencies = [
+#     "httpx>=0.28.1,<0.29",
+#     "packaging>=25.0",
+# ]
+# ///
+import re
+from pathlib import Path
+
+import httpx
+from packaging.utils import parse_wheel_filename
+from packaging.version import Version
+
+
+def main():
+    response = httpx.get(
+        "https://pypi.org/simple/uv-build/",
+        headers={"Accept": "application/vnd.pypi.simple.v1+json"},
+    )
+    response.raise_for_status()
+    data = response.json()
+    current_release = None
+    for file in data["files"]:
+        if not file["filename"].endswith(".whl"):
+            continue
+        _name, version, _build, _tags = parse_wheel_filename(file["filename"])
+        if version.is_prerelease:
+            continue
+        if current_release is None or version > current_release:
+            current_release = version
+
+    [major, minor, _patch] = current_release.release
+    if major != 0:
+        raise NotImplementedError("The script needs to be updated for uv 1.x")
+    upper_bound = Version(f"{major}.{minor + 1}.{0}")
+
+    repository_root = Path(__file__).parent.parent
+    existing = repository_root.joinpath("source/shared/build-backend-tabs.rst").read_text()
+    replacement = f'requires = ["uv_build >= {current_release}, <{upper_bound}"]'
+    searcher = re.compile(re.escape('requires = ["uv_build') + ".*" + re.escape('"]'))
+    if not searcher.search(existing):
+        raise RuntimeError("Could not `uv-build` entry")
+    updated = searcher.sub(replacement, existing)
+
+    if existing != updated:
+        print("Updating source/shared/build-backend-tabs.rst")
+        Path("source/shared/build-backend-tabs.rst").write_text(updated)
+        print(f"::set-output name=version::{current_release}")
+        print(f"::set-output name=updated::true")
+    else:
+        print("Already up-to-date source/shared/build-backend-tabs.rst")
+        print(f"::set-output name=updated::false")
+
+if __name__ == '__main__':
+    main()

From a23f1a2d451339755fed3e96bf70a7cb7972378e Mon Sep 17 00:00:00 2001
From: konsti 
Date: Tue, 26 Aug 2025 11:08:09 +0200
Subject: [PATCH 0999/1072] Update scripts/update_uv_build_version.py
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: 🇺🇦 Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 scripts/update_uv_build_version.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/update_uv_build_version.py b/scripts/update_uv_build_version.py
index f71cb821a..02eee3434 100644
--- a/scripts/update_uv_build_version.py
+++ b/scripts/update_uv_build_version.py
@@ -1,5 +1,5 @@
 # /// script
-# requires-python = ">=3.12"
+# requires-python = ">= 3.12"
 # dependencies = [
 #     "httpx>=0.28.1,<0.29",
 #     "packaging>=25.0",

From 7500df28a55d361c11f971c842beaf30a97995f2 Mon Sep 17 00:00:00 2001
From: konstin 
Date: Tue, 26 Aug 2025 11:12:28 +0200
Subject: [PATCH 1000/1072] Review

---
 .github/workflows/cron.yml                    | 27 -------------
 .github/workflows/update-uv-build-version.yml | 39 +++++++++++++++++++
 scripts/update_uv_build_version.py            | 18 ++++++---
 3 files changed, 52 insertions(+), 32 deletions(-)
 create mode 100644 .github/workflows/update-uv-build-version.yml

diff --git a/.github/workflows/cron.yml b/.github/workflows/cron.yml
index 6074c3fbb..18a63caba 100644
--- a/.github/workflows/cron.yml
+++ b/.github/workflows/cron.yml
@@ -11,30 +11,3 @@ jobs:
   test:
     if: github.repository_owner == 'pypa'  # suppress noise in forks
     uses: ./.github/workflows/test.yml
-
-  update-uv-build-version:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-      pull-requests: write
-    steps:
-      - uses: actions/checkout@v4
-      - uses: astral-sh/setup-uv@v5
-      - name: Update uv_build version
-        id: update_script
-        run: uv run scripts/update_uv_build_version.py
-      - # If there are no changes, no pull request will be created and the action exits silently.
-        name: Create Pull Request
-        uses: peter-evans/create-pull-request@v7
-        with:
-          token: ${{ secrets.GITHUB_TOKEN }}
-          commit-message: Update uv_build version to ${{ steps.update_script.outputs.version }}
-          title: Update uv_build version to ${{ steps.update_script.outputs.version }}
-          body: |
-            Automated update of uv_build version bounds for uv ${{ steps.update_script.outputs.version }}.
-            
-            This PR was created automatically by the cron workflow, ping `@konstin` for problems.
-          branch: bot/update-uv-build-version
-          delete-branch: true
-
-...
diff --git a/.github/workflows/update-uv-build-version.yml b/.github/workflows/update-uv-build-version.yml
new file mode 100644
index 000000000..8586ecd11
--- /dev/null
+++ b/.github/workflows/update-uv-build-version.yml
@@ -0,0 +1,39 @@
+---
+
+name: Cron
+
+on:
+  schedule:
+  - cron: "0 6 * * 1"  # mondays at 6am
+  workflow_dispatch:
+
+jobs:
+  update-uv-build-version:
+    name: Update uv_build version
+    if: github.repository_owner == 'pypa'  # suppress noise in forks
+    runs-on: ubuntu-latest
+    permissions:
+      contents: write
+      pull-requests: write
+    steps:
+      - uses: actions/checkout@v4
+      - name: Set up uv
+        uses: astral-sh/setup-uv@v5
+      - name: Update uv_build version
+        id: update_script
+        run: uv run scripts/update_uv_build_version.py
+      - # If there are no changes, no pull request will be created and the action exits silently.
+        name: Create Pull Request
+        uses: peter-evans/create-pull-request@v7
+        with:
+          token: ${{ secrets.GITHUB_TOKEN }}
+          commit-message: Update uv_build version to ${{ steps.update_script.outputs.version }}
+          title: Update uv_build version to ${{ steps.update_script.outputs.version }}
+          body: |
+            Automated update of uv_build version bounds for uv ${{ steps.update_script.outputs.version }}.
+            
+            This PR was created automatically by the cron workflow, ping `@konstin` for problems.
+          branch: bot/update-uv-build-version
+          delete-branch: true
+
+...
diff --git a/scripts/update_uv_build_version.py b/scripts/update_uv_build_version.py
index 02eee3434..8dfd90da8 100644
--- a/scripts/update_uv_build_version.py
+++ b/scripts/update_uv_build_version.py
@@ -5,6 +5,7 @@
 #     "packaging>=25.0",
 # ]
 # ///
+import os
 import re
 from pathlib import Path
 
@@ -36,7 +37,9 @@ def main():
     upper_bound = Version(f"{major}.{minor + 1}.{0}")
 
     repository_root = Path(__file__).parent.parent
-    existing = repository_root.joinpath("source/shared/build-backend-tabs.rst").read_text()
+    existing = repository_root.joinpath(
+        "source/shared/build-backend-tabs.rst"
+    ).read_text()
     replacement = f'requires = ["uv_build >= {current_release}, <{upper_bound}"]'
     searcher = re.compile(re.escape('requires = ["uv_build') + ".*" + re.escape('"]'))
     if not searcher.search(existing):
@@ -46,11 +49,16 @@ def main():
     if existing != updated:
         print("Updating source/shared/build-backend-tabs.rst")
         Path("source/shared/build-backend-tabs.rst").write_text(updated)
-        print(f"::set-output name=version::{current_release}")
-        print(f"::set-output name=updated::true")
+        if github_output := os.environ.get("GITHUB_OUTPUT"):
+            with open(github_output, "a") as f:
+                f.write(f"version={current_release}\n")
+                f.write(f"updated=true\n")
     else:
         print("Already up-to-date source/shared/build-backend-tabs.rst")
-        print(f"::set-output name=updated::false")
+        if github_output := os.environ.get("GITHUB_OUTPUT"):
+            with open(github_output, "a") as f:
+                f.write(f"updated=false\n")
 
-if __name__ == '__main__':
+
+if __name__ == "__main__":
     main()

From 77d8c71c11a55da7c26b251b4c61cb5d0d957fd7 Mon Sep 17 00:00:00 2001
From: konstin 
Date: Tue, 26 Aug 2025 11:14:06 +0200
Subject: [PATCH 1001/1072] Use same `actions/checkout@v4` as zizmor job

---
 .github/workflows/update-uv-build-version.yml | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/update-uv-build-version.yml b/.github/workflows/update-uv-build-version.yml
index 8586ecd11..54f5ad211 100644
--- a/.github/workflows/update-uv-build-version.yml
+++ b/.github/workflows/update-uv-build-version.yml
@@ -16,7 +16,10 @@ jobs:
       contents: write
       pull-requests: write
     steps:
-      - uses: actions/checkout@v4
+      - name: Checkout repository
+        uses: actions/checkout@v4
+        with:
+          persist-credentials: false
       - name: Set up uv
         uses: astral-sh/setup-uv@v5
       - name: Update uv_build version

From 7df08f4ed3a9788801c99635de0ef276389c64cd Mon Sep 17 00:00:00 2001
From: konstin 
Date: Tue, 26 Aug 2025 11:17:32 +0200
Subject: [PATCH 1002/1072] Linters

---
 .github/workflows/update-uv-build-version.yml | 2 +-
 scripts/update_uv_build_version.py            | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/.github/workflows/update-uv-build-version.yml b/.github/workflows/update-uv-build-version.yml
index 54f5ad211..184497047 100644
--- a/.github/workflows/update-uv-build-version.yml
+++ b/.github/workflows/update-uv-build-version.yml
@@ -34,7 +34,7 @@ jobs:
           title: Update uv_build version to ${{ steps.update_script.outputs.version }}
           body: |
             Automated update of uv_build version bounds for uv ${{ steps.update_script.outputs.version }}.
-            
+
             This PR was created automatically by the cron workflow, ping `@konstin` for problems.
           branch: bot/update-uv-build-version
           delete-branch: true
diff --git a/scripts/update_uv_build_version.py b/scripts/update_uv_build_version.py
index 8dfd90da8..816ab9061 100644
--- a/scripts/update_uv_build_version.py
+++ b/scripts/update_uv_build_version.py
@@ -52,12 +52,12 @@ def main():
         if github_output := os.environ.get("GITHUB_OUTPUT"):
             with open(github_output, "a") as f:
                 f.write(f"version={current_release}\n")
-                f.write(f"updated=true\n")
+                f.write("updated=true\n")
     else:
         print("Already up-to-date source/shared/build-backend-tabs.rst")
         if github_output := os.environ.get("GITHUB_OUTPUT"):
             with open(github_output, "a") as f:
-                f.write(f"updated=false\n")
+                f.write("updated=false\n")
 
 
 if __name__ == "__main__":

From 64977629a37b34ab04876706069a88846134cf26 Mon Sep 17 00:00:00 2001
From: konstin 
Date: Tue, 26 Aug 2025 11:18:25 +0200
Subject: [PATCH 1003/1072] Undo accidental cosmetic change

---
 .github/workflows/cron.yml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/.github/workflows/cron.yml b/.github/workflows/cron.yml
index 18a63caba..f1eddccb5 100644
--- a/.github/workflows/cron.yml
+++ b/.github/workflows/cron.yml
@@ -11,3 +11,5 @@ jobs:
   test:
     if: github.repository_owner == 'pypa'  # suppress noise in forks
     uses: ./.github/workflows/test.yml
+
+...

From d22b3b9fa10380eb7488986586fb2199719cf3b6 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Tue, 26 Aug 2025 15:07:30 -0700
Subject: [PATCH 1004/1072] Clarify that the ``License-Expression`` field
 applies to the containing distribution file, not the project itself

---
 source/specifications/core-metadata.rst | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 550c6e55a..379805df5 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -473,6 +473,9 @@ Text string that is a valid SPDX
 :term:`license expression `,
 as specified in :doc:`/specifications/license-expression`.
 
+Note that the expression in this field only applies to the **distribution** file
+containing the metadata, not the project itself or other distribution files.
+
 Examples::
 
     License-Expression: MIT
@@ -923,6 +926,9 @@ Example::
 History
 =======
 
+- August 2025: Clarified that ``License-Expression`` applies to the containing
+  distribution file and not the project itself.
+
 - August 2024: Core metadata 2.4 was approved through :pep:`639`.
 
   - Added the ``License-Expression`` field.

From 083e98617f8053ffae61ba13b806d89e69ded647 Mon Sep 17 00:00:00 2001
From: Paul Moore 
Date: Wed, 27 Aug 2025 12:20:05 +0100
Subject: [PATCH 1005/1072] Clarify that the Dynamic metadata field only
 applies when building from sdist

---
 source/specifications/core-metadata.rst | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 550c6e55a..6f071233e 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -133,6 +133,18 @@ only, and indicates that the field value was calculated at wheel build time,
 and may not be the same as the value in the sdist or in other wheels for the
 project.
 
+Note in particular that if you have a wheel, you cannot assume that a field
+which is not marked as ``Dynamic`` will have the same value in other wheels, as
+some wheels are not built directly from the sdist, but are modified from
+existing wheels (the ``cibuildwheel`` tool does this, for example). Such
+modifications *could* include changing metadata (even non-dynamic metadata).
+Similarly, if you have a sdist and a wheel which you didn't build from that
+sdist, you cannnot assume that the wheel's metadata matches that of the sdist,
+even if the field is not marked as ``Dynamic``.
+
+It is advisable, but not required, that tools which modify wheel metadata add
+the modified fields to the generated wheel's ``Dynamic`` field.
+
 Full details of the semantics of ``Dynamic`` are described in :pep:`643`.
 
 .. _core-metadata-platform:
@@ -923,6 +935,10 @@ Example::
 History
 =======
 
+- August 2025: Clarified that ``Dynamic`` only affects how fields
+  must be treated when building a wheel from a sdist, not when modifying
+  a wheel.
+
 - August 2024: Core metadata 2.4 was approved through :pep:`639`.
 
   - Added the ``License-Expression`` field.

From 42d1cbbc5be1cd43e156ba04ffde970d17ed22a4 Mon Sep 17 00:00:00 2001
From: Paul Moore 
Date: Wed, 27 Aug 2025 12:25:39 +0100
Subject: [PATCH 1006/1072] Grr, keyboard is doubling up letters :-(

---
 source/specifications/core-metadata.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 6f071233e..106922580 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -139,7 +139,7 @@ some wheels are not built directly from the sdist, but are modified from
 existing wheels (the ``cibuildwheel`` tool does this, for example). Such
 modifications *could* include changing metadata (even non-dynamic metadata).
 Similarly, if you have a sdist and a wheel which you didn't build from that
-sdist, you cannnot assume that the wheel's metadata matches that of the sdist,
+sdist, you cannot assume that the wheel's metadata matches that of the sdist,
 even if the field is not marked as ``Dynamic``.
 
 It is advisable, but not required, that tools which modify wheel metadata add

From 875b13fa27bdf28200a364220a249290654f4280 Mon Sep 17 00:00:00 2001
From: Paul Moore 
Date: Wed, 27 Aug 2025 14:37:34 +0100
Subject: [PATCH 1007/1072] Refer to auditwheel rather than cibuildwheel

---
 source/specifications/core-metadata.rst | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 106922580..b77243e10 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -136,11 +136,12 @@ project.
 Note in particular that if you have a wheel, you cannot assume that a field
 which is not marked as ``Dynamic`` will have the same value in other wheels, as
 some wheels are not built directly from the sdist, but are modified from
-existing wheels (the ``cibuildwheel`` tool does this, for example). Such
-modifications *could* include changing metadata (even non-dynamic metadata).
-Similarly, if you have a sdist and a wheel which you didn't build from that
-sdist, you cannot assume that the wheel's metadata matches that of the sdist,
-even if the field is not marked as ``Dynamic``.
+existing wheels (the ``auditwheel`` tool does this, for example, and it's
+commonly used when building wheels for PyPI). Such modifications *could*
+include changing metadata (even non-dynamic metadata).  Similarly, if you have
+a sdist and a wheel which you didn't build from that sdist, you cannot assume
+that the wheel's metadata matches that of the sdist, even if the field is not
+marked as ``Dynamic``.
 
 It is advisable, but not required, that tools which modify wheel metadata add
 the modified fields to the generated wheel's ``Dynamic`` field.

From 6569d5cafecf2243368446e6f1e37d91c10797a7 Mon Sep 17 00:00:00 2001
From: Paul Moore 
Date: Wed, 27 Aug 2025 15:14:50 +0100
Subject: [PATCH 1008/1072] Clarify prebuilt wheels

---
 source/specifications/core-metadata.rst | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index b77243e10..571a13dde 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -133,15 +133,15 @@ only, and indicates that the field value was calculated at wheel build time,
 and may not be the same as the value in the sdist or in other wheels for the
 project.
 
-Note in particular that if you have a wheel, you cannot assume that a field
-which is not marked as ``Dynamic`` will have the same value in other wheels, as
-some wheels are not built directly from the sdist, but are modified from
-existing wheels (the ``auditwheel`` tool does this, for example, and it's
-commonly used when building wheels for PyPI). Such modifications *could*
-include changing metadata (even non-dynamic metadata).  Similarly, if you have
-a sdist and a wheel which you didn't build from that sdist, you cannot assume
-that the wheel's metadata matches that of the sdist, even if the field is not
-marked as ``Dynamic``.
+Note in particular that if you have obtained a prebuilt wheel, you cannot
+assume that a field which is not marked as ``Dynamic`` will have the same value
+in other wheels, as some wheels are not built directly from the sdist, but are
+modified from existing wheels (the ``auditwheel`` tool does this, for example,
+and it's commonly used when building wheels for PyPI). Such modifications
+*could* include changing metadata (even non-dynamic metadata).  Similarly, if
+you have a sdist and a wheel which you didn't build from that sdist, you cannot
+assume that the wheel's metadata matches that of the sdist, even if the field
+is not marked as ``Dynamic``.
 
 It is advisable, but not required, that tools which modify wheel metadata add
 the modified fields to the generated wheel's ``Dynamic`` field.

From cd571af286305cf1e7114a57f13ccff729f706c5 Mon Sep 17 00:00:00 2001
From: Paul Moore 
Date: Wed, 27 Aug 2025 16:20:46 +0100
Subject: [PATCH 1009/1072] Remove advice for tools that modify wheels

---
 source/specifications/core-metadata.rst | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 571a13dde..c020e1469 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -143,9 +143,6 @@ you have a sdist and a wheel which you didn't build from that sdist, you cannot
 assume that the wheel's metadata matches that of the sdist, even if the field
 is not marked as ``Dynamic``.
 
-It is advisable, but not required, that tools which modify wheel metadata add
-the modified fields to the generated wheel's ``Dynamic`` field.
-
 Full details of the semantics of ``Dynamic`` are described in :pep:`643`.
 
 .. _core-metadata-platform:

From 31d727712bb38af2513dc7f741e47f188ed96f98 Mon Sep 17 00:00:00 2001
From: konsti 
Date: Thu, 28 Aug 2025 16:51:57 +0200
Subject: [PATCH 1010/1072] Update
 .github/workflows/update-uv-build-version.yml

Co-authored-by: Alyssa Coghlan 
---
 .github/workflows/update-uv-build-version.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/update-uv-build-version.yml b/.github/workflows/update-uv-build-version.yml
index 184497047..a3cead001 100644
--- a/.github/workflows/update-uv-build-version.yml
+++ b/.github/workflows/update-uv-build-version.yml
@@ -1,6 +1,6 @@
 ---
 
-name: Cron
+name: Update uv build version
 
 on:
   schedule:

From acdb79c4e738cc1f489288219632e6b694209ac2 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Wed, 10 Sep 2025 12:04:16 -0700
Subject: [PATCH 1011/1072] Try to clarify where `license-expression` applies

---
 source/specifications/core-metadata.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 379805df5..c79b4e0f7 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -473,8 +473,8 @@ Text string that is a valid SPDX
 :term:`license expression `,
 as specified in :doc:`/specifications/license-expression`.
 
-Note that the expression in this field only applies to the **distribution** file
-containing the metadata, not the project itself or other distribution files.
+Note that the expression in this field only applies to the distribution file
+containing the metadata, not the project overall or other distribution files.
 
 Examples::
 

From d73c061cbaa3f1178c8cc1e0bb5bfeaea3ee64ed Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Wed, 10 Sep 2025 13:06:14 -0700
Subject: [PATCH 1012/1072] Clarify throughout the docs that the `license` key
 in `pyproject.toml` is for the distribution

---
 source/glossary.rst                           |  2 +-
 .../licensing-examples-and-user-scenarios.rst | 28 +++++++++----------
 source/guides/writing-pyproject-toml.rst      | 15 +++++-----
 source/tutorials/packaging-projects.rst       | 14 +++++-----
 4 files changed, 30 insertions(+), 29 deletions(-)

diff --git a/source/glossary.rst b/source/glossary.rst
index 6a592125f..630513868 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -160,7 +160,7 @@ Glossary
 
         A string with valid SPDX license expression syntax,
         including one or more SPDX :term:`License Identifier`\(s),
-        which describes a :term:`Project`'s license(s)
+        which describes a :term:`Distribution Archive`'s license(s)
         and how they inter-relate.
         Examples:
         ``GPL-3.0-or-later``,
diff --git a/source/guides/licensing-examples-and-user-scenarios.rst b/source/guides/licensing-examples-and-user-scenarios.rst
index 2c25ddfb0..9f32b6117 100644
--- a/source/guides/licensing-examples-and-user-scenarios.rst
+++ b/source/guides/licensing-examples-and-user-scenarios.rst
@@ -6,8 +6,8 @@ Licensing examples and user scenarios
 =====================================
 
 
-:pep:`639` has specified the way to declare a project's license and paths to
-license files and other legally required information.
+:pep:`639` has specified the way to declare a :term:`Distribution Archive`'s
+license and paths to license files and other legally required information.
 This document aims to provide clear guidance how to migrate from the legacy
 to the standardized way of declaring licenses.
 Make sure your preferred build backend supports :pep:`639` before
@@ -53,7 +53,7 @@ Or, if the project used :file:`setup.cfg`, in its ``[metadata]`` table:
     [metadata]
     license = MIT
 
-The output Core Metadata for the distribution packages would then be:
+The output Core Metadata for the :term:`Distribution Package` would then be:
 
 .. code-block:: email
 
@@ -63,8 +63,9 @@ The output Core Metadata for the distribution packages would then be:
 The :file:`LICENSE` file would be stored at :file:`/setuptools-{VERSION}/LICENSE`
 in the sdist and :file:`/setuptools-{VERSION}.dist-info/licenses/LICENSE`
 in the wheel, and unpacked from there into the site directory (e.g.
-:file:`site-packages/`) on installation; :file:`/` is the root of the respective archive
-and ``{VERSION}`` the version of the Setuptools release in the Core Metadata.
+:file:`site-packages/`) on installation; :file:`/` is the root of the respective
+archive and ``{VERSION}`` the version of the Setuptools release in the Core
+Metadata.
 
 
 .. _licensing-example-advanced:
@@ -83,7 +84,7 @@ directories; specifically:
     ordered-set==3.1.1
     more_itertools==8.8.0
 
-The license expressions for these projects are:
+The appropriate license expressions are:
 
 .. code-block:: text
 
@@ -287,7 +288,7 @@ and make sure to remove any legacy ``license`` table subkeys or
 ``License ::`` classifiers. Your existing ``license`` value may already
 be valid as one (e.g. ``MIT``, ``Apache-2.0 OR BSD-2-Clause``, etc);
 otherwise, check the `SPDX license list `__ for the identifier
-that matches the license used in your project.
+that matches the license used.
 
 Make sure to list your license files under ``license-files``
 under ``[project]`` in :file:`pyproject.toml`
@@ -311,13 +312,12 @@ software, you can construct a license expression
 to describe the licenses involved and the relationship
 between them.
 
-In short, ``License-1 AND License-2`` mean that *both* licenses apply
-to your project, or parts of it (for example, you included a file
-under another license), and ``License-1 OR License-2`` means that
-*either* of the licenses can be used, at the user's option (for example,
-you want to allow users a choice of multiple licenses). You can use
-parenthesis (``()``) for grouping to form expressions that cover even the most
-complex situations.
+In short, ``License-1 AND License-2`` mean that *both* licenses apply, or parts
+of it (for example, you included a file under another license), and
+``License-1 OR License-2`` means that *either* of the licenses can be used, at
+the user's option (for example, you want to allow users a choice of multiple
+licenses). You can use parenthesis (``()``) for grouping to form expressions
+that cover even the most complex situations.
 
 In your project config file, enter your license expression under
 ``license`` (``[project]`` table of :file:`pyproject.toml`),
diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index 1d035a384..3a8a8e5d4 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -296,10 +296,10 @@ You can also specify the format explicitly, like this:
 ``license`` and ``license-files``
 ---------------------------------
 
-As per :pep:`639` licenses should be declared with two fields:
+As per :pep:`639`, licenses should be declared with two fields:
 
-- ``license`` is an :term:`SPDX license expression ` consisting
-  of one or more :term:`license identifiers `.
+- ``license`` is an :term:`SPDX license expression `
+  consisting of one or more :term:`license identifiers `.
 - ``license-files`` is a list of license file glob patterns.
 
 A previous PEP had specified ``license`` to be a table with a ``file`` or a
@@ -350,10 +350,11 @@ As a general rule, it is a good idea to use a standard, well-known
 license, both to avoid confusion and because some organizations avoid software
 whose license is unapproved.
 
-If your project is licensed with a license that doesn't have an existing SPDX
-identifier, you can create a custom one in format ``LicenseRef-[idstring]``.
-The custom identifiers must follow the SPDX specification,
-`clause 10.1 `_ of the version 2.2 or any later compatible one.
+If your :term:`Distribution Archive` is licensed with a license that doesn't
+have an existing SPDX identifier, you can create a custom one in format
+``LicenseRef-[idstring]``. The custom identifiers must follow the SPDX
+specification, `clause 10.1 `_ of the version 2.2 or any later
+compatible one.
 
 .. code-block:: toml
 
diff --git a/source/tutorials/packaging-projects.rst b/source/tutorials/packaging-projects.rst
index f2c0851ba..4f69de20b 100644
--- a/source/tutorials/packaging-projects.rst
+++ b/source/tutorials/packaging-projects.rst
@@ -220,7 +220,7 @@ following this tutorial.
   your package will work on. For a complete list of classifiers, see
   https://pypi.org/classifiers/.
 - ``license`` is the :term:`SPDX license expression ` of
-  your package.
+  your :term:`Distribution Archive` files.
 - ``license-files`` is the list of glob paths to the license files,
   relative to the directory where :file:`pyproject.toml` is located.
 - ``urls`` lets you list any number of extra links to show on PyPI.
@@ -250,12 +250,12 @@ if you'd like.
 Creating a LICENSE
 ------------------
 
-It's important for every package uploaded to the Python Package Index to include
-a license. This tells users who install your package the terms under which they
-can use your package. For help picking a license, see
-https://choosealicense.com/. Once you have chosen a license, open
-:file:`LICENSE` and enter the license text. For example, if you had chosen the
-MIT license:
+It's important for every :term:`Distribution Archive` uploaded to the Python
+Package Index to include a license. This tells users who install your
+:term:`Distribution Archive` the terms under which they can use it. For help
+picking a license, see https://choosealicense.com/. Once you have chosen a
+license, open :file:`LICENSE` and enter the license text. For example, if you
+had chosen the MIT license:
 
 .. code-block:: text
 

From ce4251e775d04f5577ad9b7a843703c3b87bd06c Mon Sep 17 00:00:00 2001
From: konstin 
Date: Mon, 15 Sep 2025 20:57:37 +0200
Subject: [PATCH 1013/1072] Create PR as draft

---
 .github/workflows/update-uv-build-version.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.github/workflows/update-uv-build-version.yml b/.github/workflows/update-uv-build-version.yml
index a3cead001..8aadc7052 100644
--- a/.github/workflows/update-uv-build-version.yml
+++ b/.github/workflows/update-uv-build-version.yml
@@ -32,6 +32,7 @@ jobs:
           token: ${{ secrets.GITHUB_TOKEN }}
           commit-message: Update uv_build version to ${{ steps.update_script.outputs.version }}
           title: Update uv_build version to ${{ steps.update_script.outputs.version }}
+          draft: true # Trigger CI by un-drafting the PR, otherwise `GITHUB_TOKEN` PRs don't trigger CI.
           body: |
             Automated update of uv_build version bounds for uv ${{ steps.update_script.outputs.version }}.
 

From 4f0a3c603d3a901bb00e1d52d639d6b1cb3aca5f Mon Sep 17 00:00:00 2001
From: Nick Coghlan 
Date: Tue, 16 Sep 2025 11:14:09 +1000
Subject: [PATCH 1014/1072] Vagrant link is failing CI, drop it entirely

---
 source/overview.rst | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/source/overview.rst b/source/overview.rst
index 8c68036a7..70ef2d058 100644
--- a/source/overview.rst
+++ b/source/overview.rst
@@ -339,7 +339,7 @@ originated and where the technologies below work best:
 Bringing your own kernel
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-Most operating systems support some form of classical virtualization,
+Most desktop operating systems support some form of classical virtualization,
 running applications packaged as images containing a full operating
 system of their own. Running these virtual machines, or VMs, is a
 mature approach, widespread in data center environments.
@@ -348,9 +348,13 @@ These techniques are mostly reserved for larger scale deployments in
 data centers, though certain complex applications can benefit from
 this packaging. The technologies are Python agnostic, and include:
 
-* `Vagrant `_
-* `VHD `_, `AMI `_, and :doc:`other formats `
-* `OpenStack `_ - A cloud management system in Python, with extensive VM support
+* KVM on Linux
+* Hyper-V on Windows
+* `VHD `_,
+  `AMI `_,
+  and :doc:`other formats `
+* `OpenStack `_ -
+  A cloud management system written in Python, with extensive VM support
 
 Bringing your own hardware
 ^^^^^^^^^^^^^^^^^^^^^^^^^^

From c3274274483e7638d75699678347400b18773144 Mon Sep 17 00:00:00 2001
From: Nick Coghlan 
Date: Tue, 16 Sep 2025 11:36:49 +1000
Subject: [PATCH 1015/1072] Avoid binary gender assumptions in example

Closes #1907
---
 source/guides/creating-command-line-tools.rst | 46 ++++++++-----------
 1 file changed, 20 insertions(+), 26 deletions(-)

diff --git a/source/guides/creating-command-line-tools.rst b/source/guides/creating-command-line-tools.rst
index 8266fffdb..045c221b4 100644
--- a/source/guides/creating-command-line-tools.rst
+++ b/source/guides/creating-command-line-tools.rst
@@ -40,33 +40,25 @@ named after the main module:
 
 
     def greet(
-        name: Annotated[str, typer.Argument(help="The (last, if --gender is given) name of the person to greet")] = "",
-        gender: Annotated[str, typer.Option(help="The gender of the person to greet")] = "",
+        name: Annotated[str, typer.Argument(help="The (last, if --title is given) name of the person to greet")] = "",
+        title: Annotated[str, typer.Option(help="The preferred title of the person to greet")] = "",
         knight: Annotated[bool, typer.Option(help="Whether the person is a knight")] = False,
         count: Annotated[int, typer.Option(help="Number of times to greet the person")] = 1
     ):
-        greeting = "Greetings, dear "
-        masculine = gender == "masculine"
-        feminine = gender == "feminine"
-        if gender or knight:
+        greeting = "Greetings, "
+        if not name:
+            if title:
+                name = title.lower().rstrip(".")
+            else:
+                name = "friend"
+        if title or knight:
             salutation = ""
-            if knight:
+            if title:
+                salutation = title
+            elif knight:
                 salutation = "Sir "
-            elif masculine:
-                salutation = "Mr. "
-            elif feminine:
-                salutation = "Ms. "
             greeting += salutation
-            if name:
-                greeting += f"{name}!"
-            else:
-                pronoun = "her" if feminine else "his" if masculine or knight else "its"
-                greeting += f"what's-{pronoun}-name"
-        else:
-            if name:
-                greeting += f"{name}!"
-            elif not gender:
-                greeting += "friend!"
+        greeting += f"{name}!"
         for i in range(0, count):
             print(greeting)
 
@@ -145,12 +137,14 @@ Let's test it:
 
 .. code-block:: console
 
+	$ greet
+	Greetings, friend!
 	$ greet --knight Lancelot
-	Greetings, dear Sir Lancelot!
-	$ greet --gender feminine Parks
-	Greetings, dear Ms. Parks!
-	$ greet --gender masculine
-	Greetings, dear Mr. what's-his-name!
+	Greetings, Sir Lancelot!
+	$ greet --title Ms. Parks
+	Greetings, Ms. Parks!
+	$ greet --title Mr.
+	Greetings, Mr. mr!
 
 Since this example uses ``typer``, you could now also get an overview of the program's usage by calling it with
 the ``--help`` option, or configure completions via the ``--install-completion`` option.

From 332cc3086f6f1f4e9e53062914733a8a439c7102 Mon Sep 17 00:00:00 2001
From: Nick Coghlan 
Date: Tue, 16 Sep 2025 11:53:35 +1000
Subject: [PATCH 1016/1072] Use a more obviously gender neutral title

---
 source/guides/creating-command-line-tools.rst | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/source/guides/creating-command-line-tools.rst b/source/guides/creating-command-line-tools.rst
index 045c221b4..5e96b7da5 100644
--- a/source/guides/creating-command-line-tools.rst
+++ b/source/guides/creating-command-line-tools.rst
@@ -42,7 +42,7 @@ named after the main module:
     def greet(
         name: Annotated[str, typer.Argument(help="The (last, if --title is given) name of the person to greet")] = "",
         title: Annotated[str, typer.Option(help="The preferred title of the person to greet")] = "",
-        knight: Annotated[bool, typer.Option(help="Whether the person is a knight")] = False,
+        doctor: Annotated[bool, typer.Option(help="Whether the person is a doctor (MD or PhD)")] = False,
         count: Annotated[int, typer.Option(help="Number of times to greet the person")] = 1
     ):
         greeting = "Greetings, "
@@ -51,13 +51,10 @@ named after the main module:
                 name = title.lower().rstrip(".")
             else:
                 name = "friend"
-        if title or knight:
-            salutation = ""
-            if title:
-                salutation = title
-            elif knight:
-                salutation = "Sir "
-            greeting += salutation
+        if doctor and not title:
+            title = "Dr."
+        if title:
+            greeting += f"{title} "
         greeting += f"{name}!"
         for i in range(0, count):
             print(greeting)

From 159fc06e960d9399a43adf59abcf22d592fbbb3b Mon Sep 17 00:00:00 2001
From: Nick Coghlan 
Date: Tue, 16 Sep 2025 11:55:30 +1000
Subject: [PATCH 1017/1072] Update example output

---
 source/guides/creating-command-line-tools.rst | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/source/guides/creating-command-line-tools.rst b/source/guides/creating-command-line-tools.rst
index 5e96b7da5..72e3e37ef 100644
--- a/source/guides/creating-command-line-tools.rst
+++ b/source/guides/creating-command-line-tools.rst
@@ -46,13 +46,13 @@ named after the main module:
         count: Annotated[int, typer.Option(help="Number of times to greet the person")] = 1
     ):
         greeting = "Greetings, "
+        if doctor and not title:
+            title = "Dr."
         if not name:
             if title:
                 name = title.lower().rstrip(".")
             else:
                 name = "friend"
-        if doctor and not title:
-            title = "Dr."
         if title:
             greeting += f"{title} "
         greeting += f"{name}!"
@@ -136,8 +136,8 @@ Let's test it:
 
 	$ greet
 	Greetings, friend!
-	$ greet --knight Lancelot
-	Greetings, Sir Lancelot!
+	$ greet --doctor Brennan
+	Greetings, Dr. Brennan!
 	$ greet --title Ms. Parks
 	Greetings, Ms. Parks!
 	$ greet --title Mr.
@@ -151,7 +151,7 @@ To just run the program without installing it permanently, use ``pipx run``, whi
 
 .. code-block:: console
 
-	$ pipx run --spec . greet --knight
+	$ pipx run --spec . greet --doctor
 
 This syntax is a bit impractical, however; as the name of the entry point we defined above does not match the package name,
 we need to state explicitly which executable script to run (even though there is only on in existence).
@@ -170,7 +170,7 @@ default one and run it, which makes this command possible:
 
 .. code-block:: console
 
-    $ pipx run . --knight
+    $ pipx run . --doctor
 
 Conclusion
 ==========

From bceb2644a302db55733492e4489883699f961921 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Mon, 15 Sep 2025 21:59:01 -0400
Subject: [PATCH 1018/1072] ci: remove workflow_dispatch from cron.yml

Signed-off-by: William Woodruff 
---
 .github/workflows/cron.yml | 1 -
 1 file changed, 1 deletion(-)

diff --git a/.github/workflows/cron.yml b/.github/workflows/cron.yml
index f1eddccb5..8870bb70b 100644
--- a/.github/workflows/cron.yml
+++ b/.github/workflows/cron.yml
@@ -5,7 +5,6 @@ name: Cron
 on:
   schedule:
   - cron: "0 6 * * *"  # daily at 6am
-  workflow_dispatch:
 
 jobs:
   test:

From c7ffbccf513399c2cddd0dbed7183d4835429419 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Mon, 15 Sep 2025 22:06:31 -0400
Subject: [PATCH 1019/1072] ci: add pull_request event subtypes

Signed-off-by: William Woodruff 
---
 .github/workflows/test.yml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
index 8503ca720..172fed713 100644
--- a/.github/workflows/test.yml
+++ b/.github/workflows/test.yml
@@ -6,12 +6,19 @@ on:
     branches-ignore:
     - gh-readonly-queue/**  # Temporary merge queue-related GH-made branches
   pull_request:
+    types:
+    - opened  # default
+    - synchronize  # default
+    - reopened  # default
+    - ready_for_review  # used in PRs created from GitHub Actions workflows
   workflow_call:
 
 concurrency:
   group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.sha }}
   cancel-in-progress: true
 
+permissions: {}
+
 jobs:
   build:
     name: ${{ matrix.noxenv }}

From b036f24d6fefac29c3b95a7b8810b62117529f5c Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Mon, 15 Sep 2025 22:06:53 -0400
Subject: [PATCH 1020/1072] update_uv_build_version: remove unneeded format

Signed-off-by: William Woodruff 
---
 scripts/update_uv_build_version.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/update_uv_build_version.py b/scripts/update_uv_build_version.py
index 816ab9061..69fefba27 100644
--- a/scripts/update_uv_build_version.py
+++ b/scripts/update_uv_build_version.py
@@ -34,7 +34,7 @@ def main():
     [major, minor, _patch] = current_release.release
     if major != 0:
         raise NotImplementedError("The script needs to be updated for uv 1.x")
-    upper_bound = Version(f"{major}.{minor + 1}.{0}")
+    upper_bound = Version(f"{major}.{minor + 1}.0")
 
     repository_root = Path(__file__).parent.parent
     existing = repository_root.joinpath(

From 71eb39402354a259a151dd2ea837b4b90219edb4 Mon Sep 17 00:00:00 2001
From: woodruffw <3059210+woodruffw@users.noreply.github.com>
Date: Tue, 16 Sep 2025 14:15:24 +0000
Subject: [PATCH 1021/1072] Update uv_build version to 0.8.17

---
 source/shared/build-backend-tabs.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/shared/build-backend-tabs.rst b/source/shared/build-backend-tabs.rst
index 608fcaddd..9efc8b0d7 100644
--- a/source/shared/build-backend-tabs.rst
+++ b/source/shared/build-backend-tabs.rst
@@ -38,5 +38,5 @@
     .. code-block:: toml
 
         [build-system]
-        requires = ["uv_build >= 0.7.19, <0.9.0"]
+        requires = ["uv_build >= 0.8.17, <0.9.0"]
         build-backend = "uv_build"

From dd267139d93bdc154629f1038b852b8178681102 Mon Sep 17 00:00:00 2001
From: Philip Mallegol-Hansen 
Date: Tue, 16 Sep 2025 13:25:53 -0700
Subject: [PATCH 1022/1072] Updates table to contain poetry-core version
 supporting PEP 639

---
 source/guides/writing-pyproject-toml.rst | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/source/guides/writing-pyproject-toml.rst b/source/guides/writing-pyproject-toml.rst
index 1d035a384..b8be3e85d 100644
--- a/source/guides/writing-pyproject-toml.rst
+++ b/source/guides/writing-pyproject-toml.rst
@@ -319,7 +319,7 @@ backend>` now support the new format as shown in the following table.
      - 77.0.3
      - 3.12
      - 2.4.0
-     - `not yet `_
+     - 2.2.0
      - 0.7.19
 
 
@@ -587,7 +587,6 @@ A full example
 .. _pypi-search-pip: https://pypi.org/search?q=pip
 .. _classifier-list: https://pypi.org/classifiers
 .. _requires-python-blog-post: https://iscinumpy.dev/post/bound-version-constraints/#pinning-the-python-version-is-special
-.. _poetry-pep639-issue: https://github.com/python-poetry/poetry/issues/9670
 .. _pytest: https://pytest.org
 .. _pygments: https://pygments.org
 .. _rest: https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html

From 3669181977fc68f686eac4c29ba25564ed964abc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edgar=20Ram=C3=ADrez-Mondrag=C3=B3n?= 
Date: Sat, 13 Sep 2025 11:12:38 -0600
Subject: [PATCH 1023/1072] Fix links to spec schemas

---
 .../specifications/schemas/build-details-v1.0.schema.json  | 0
 .../specifications/schemas/direct-url.schema.json          | 0
 .../specifications/schemas/pylock.schema.json              | 0
 source/conf.py                                             | 7 +++++++
 source/specifications/build-details/v1.0.rst               | 2 +-
 source/specifications/direct-url-data-structure.rst        | 2 +-
 6 files changed, 9 insertions(+), 2 deletions(-)
 rename {source => extra}/specifications/schemas/build-details-v1.0.schema.json (100%)
 rename {source => extra}/specifications/schemas/direct-url.schema.json (100%)
 rename {source => extra}/specifications/schemas/pylock.schema.json (100%)

diff --git a/source/specifications/schemas/build-details-v1.0.schema.json b/extra/specifications/schemas/build-details-v1.0.schema.json
similarity index 100%
rename from source/specifications/schemas/build-details-v1.0.schema.json
rename to extra/specifications/schemas/build-details-v1.0.schema.json
diff --git a/source/specifications/schemas/direct-url.schema.json b/extra/specifications/schemas/direct-url.schema.json
similarity index 100%
rename from source/specifications/schemas/direct-url.schema.json
rename to extra/specifications/schemas/direct-url.schema.json
diff --git a/source/specifications/schemas/pylock.schema.json b/extra/specifications/schemas/pylock.schema.json
similarity index 100%
rename from source/specifications/schemas/pylock.schema.json
rename to extra/specifications/schemas/pylock.schema.json
diff --git a/source/conf.py b/source/conf.py
index a8a040d6c..3ffa98b0f 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -83,6 +83,10 @@
     # https://plausible.io/packaging.python.org
     html_js_files.extend(_metrics_js_files)
 
+html_extra_path = [
+    "../extra",
+]
+
 # -- Options for HTML help output ------------------------------------------------------
 # https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-html-help-output
 
@@ -157,6 +161,9 @@
     # https://github.com/pypa/packaging.python.org/issues/1744
     r"https://pypi\.org/",
 ]
+linkcheck_exclude_documents = [
+    "specifications/schemas/index",
+]
 
 # -- Options for extlinks ----------------------------------------------------------
 # https://www.sphinx-doc.org/en/master/usage/extensions/extlinks.html#configuration
diff --git a/source/specifications/build-details/v1.0.rst b/source/specifications/build-details/v1.0.rst
index cfe902e1e..3a8cfe277 100644
--- a/source/specifications/build-details/v1.0.rst
+++ b/source/specifications/build-details/v1.0.rst
@@ -8,7 +8,7 @@
 Specification
 -------------
 
-.. jsonschema:: ../schemas/build-details-v1.0.schema.json
+.. jsonschema:: ../../../extra/specifications/schemas/build-details-v1.0.schema.json
     :lift_title: false
 
 
diff --git a/source/specifications/direct-url-data-structure.rst b/source/specifications/direct-url-data-structure.rst
index 5f3af0fae..a82537f0a 100644
--- a/source/specifications/direct-url-data-structure.rst
+++ b/source/specifications/direct-url-data-structure.rst
@@ -236,7 +236,7 @@ JSON Schema
 
 The following JSON Schema can be used to validate the contents of ``direct_url.json``:
 
-.. literalinclude:: schemas/direct-url.schema.json
+.. literalinclude:: ../../extra/specifications/schemas/direct-url.schema.json
 
 Examples
 ========

From 6ae0da519af5615f4f28b28d3d738755075866a3 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Wed, 10 Sep 2025 12:26:26 -0700
Subject: [PATCH 1024/1072] Clarify that the `license` key in `pyprojcet.toml`
 should only be set if it is consistent across all distribution files This
 change is approved at
 https://discuss.python.org/t/split-from-pep-639-expressing-project-vs-distribution-licenses-post-pep-639-mod-titled/90314/179
 .

---
 source/specifications/pyproject-toml.rst | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 4ce9b7484..c94e78d83 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -259,6 +259,11 @@ Text string that is a valid SPDX
 as specified in :doc:`/specifications/license-expression`.
 Tools SHOULD validate and perform case normalization of the expression.
 
+This key should **only** be specified if the license expression for any
+and all distribution files generated from the ``pyproject.toml`` is the
+same as the one specified. If the license expression will differ then
+it should either be specified as dynamic or not set at all.
+
 Legacy specification
 ''''''''''''''''''''
 

From 3504230284d0802c38859fcd18f9ca59970daaec Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Wed, 10 Sep 2025 12:30:49 -0700
Subject: [PATCH 1025/1072] Add a history entry

---
 source/specifications/pyproject-toml.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index c94e78d83..7950bccbc 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -545,5 +545,8 @@ History
 - December 2024: The ``license`` key was redefined, the ``license-files`` key was
   added and ``License::`` classifiers were deprecated through :pep:`639`.
 
+- September 2025: Clarity that the ``license`` key applies to all distribution
+  files generated from the ``pyproject.toml`` file.
+
 
 .. _TOML: https://toml.io

From b947936259353b85c34252dc01c2e11a97762482 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Mon, 15 Sep 2025 17:09:25 +0100
Subject: [PATCH 1026/1072] Apply suggestion from @webknjaz
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: 🇺🇦 Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/specifications/pyproject-toml.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 7950bccbc..4a14615b9 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -260,7 +260,7 @@ as specified in :doc:`/specifications/license-expression`.
 Tools SHOULD validate and perform case normalization of the expression.
 
 This key should **only** be specified if the license expression for any
-and all distribution files generated from the ``pyproject.toml`` is the
+and all distribution files generated from the :file:`pyproject.toml` is the
 same as the one specified. If the license expression will differ then
 it should either be specified as dynamic or not set at all.
 

From ed6f9704411531d46756ef7b49f7109aa73fd6e6 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Mon, 15 Sep 2025 17:09:31 +0100
Subject: [PATCH 1027/1072] Apply suggestion from @webknjaz
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: 🇺🇦 Sviatoslav Sydorenko (Святослав Сидоренко) 
---
 source/specifications/pyproject-toml.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 4a14615b9..3c47b9d50 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -546,7 +546,7 @@ History
   added and ``License::`` classifiers were deprecated through :pep:`639`.
 
 - September 2025: Clarity that the ``license`` key applies to all distribution
-  files generated from the ``pyproject.toml`` file.
+  files generated from the :file:`pyproject.toml` file.
 
 
 .. _TOML: https://toml.io

From 3851b070abb3ed435f1b52572593e96970eb9431 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Mon, 15 Sep 2025 17:11:00 +0100
Subject: [PATCH 1028/1072] Fix wording in pyproject-toml.rst license section

---
 source/specifications/pyproject-toml.rst | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 3c47b9d50..bb0e56ff7 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -260,9 +260,10 @@ as specified in :doc:`/specifications/license-expression`.
 Tools SHOULD validate and perform case normalization of the expression.
 
 This key should **only** be specified if the license expression for any
-and all distribution files generated from the :file:`pyproject.toml` is the
-same as the one specified. If the license expression will differ then
-it should either be specified as dynamic or not set at all.
+and all distribution files created by a build backend using the
+:file:`pyproject.toml` is the same as the one specified. If the license
+expression will differ then it should either be specified as dynamic or
+not set at all.
 
 Legacy specification
 ''''''''''''''''''''

From 5a822ab5af0d305d175e5cb475bfcbcdd9497b74 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Fri, 3 Oct 2025 22:41:35 +0000
Subject: [PATCH 1029/1072] [pre-commit.ci] auto fixes from pre-commit.com
 hooks

for more information, see https://pre-commit.ci
---
 source/specifications/core-metadata.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 665f8704a..42c6b9ec6 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -938,7 +938,7 @@ History
 
 - October 2025: Clarified that ``License-Expression`` applies to the containing
   distribution file and not the project itself.
-  
+
 - August 2025: Clarified that ``Dynamic`` only affects how fields
   must be treated when building a wheel from a sdist, not when modifying
   a wheel.

From 4a44bffed7f86296599e0dd5ab968343e5450654 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Fri, 3 Oct 2025 15:45:25 -0700
Subject: [PATCH 1030/1072] Fix formatting of license expression explanation

---
 source/guides/licensing-examples-and-user-scenarios.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/guides/licensing-examples-and-user-scenarios.rst b/source/guides/licensing-examples-and-user-scenarios.rst
index 9f32b6117..b6cdfe327 100644
--- a/source/guides/licensing-examples-and-user-scenarios.rst
+++ b/source/guides/licensing-examples-and-user-scenarios.rst
@@ -312,8 +312,8 @@ software, you can construct a license expression
 to describe the licenses involved and the relationship
 between them.
 
-In short, ``License-1 AND License-2`` mean that *both* licenses apply, or parts
-of it (for example, you included a file under another license), and
+In short, ``License-1 AND License-2`` mean that *both* licenses apply
+(for example, you included a file under another license), and
 ``License-1 OR License-2`` means that *either* of the licenses can be used, at
 the user's option (for example, you want to allow users a choice of multiple
 licenses). You can use parenthesis (``()``) for grouping to form expressions

From 465a5bfa5e8da07656e20ab46df41489c29629da Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Tue, 7 Oct 2025 09:37:57 -0700
Subject: [PATCH 1031/1072] Try to clarify what a "distribution archive" is

---
 source/specifications/core-metadata.rst | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 42c6b9ec6..b6d92e6f2 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -483,8 +483,10 @@ Text string that is a valid SPDX
 :term:`license expression `,
 as specified in :doc:`/specifications/license-expression`.
 
-Note that the expression in this field only applies to the distribution file
-containing the metadata, not the project overall or other distribution files.
+Note that the expression in this field only applies to the
+:term:`Distribution Archive` containing the metadata with this field (e.g.,
+:term:`Source Distribution` or :term:`Wheel`), not the project overall or
+other files related to the project (including other distribution archives).
 
 Examples::
 

From db0173577ef2328967b06043d7cacfb6f3a536c0 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Tue, 7 Oct 2025 11:04:31 -0700
Subject: [PATCH 1032/1072] Add PEP 794: Import name metadata

---
 source/specifications/core-metadata.rst  | 134 ++++++++++++++++++++---
 source/specifications/pyproject-toml.rst |  96 ++++++++++++++++
 2 files changed, 213 insertions(+), 17 deletions(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index c020e1469..0ea469fd8 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -6,7 +6,7 @@
 Core metadata specifications
 ============================
 
-This page describes version 2.4, approved in August 2024.
+This page describes version 2.5, approved in September 2025.
 
 Fields defined in the following specification should be considered valid,
 complete and not subject to change. The required fields are:
@@ -50,7 +50,7 @@ Metadata-Version
 .. versionadded:: 1.0
 
 Version of the file format; legal values are "1.0", "1.1", "1.2", "2.1",
-"2.2", "2.3", and "2.4".
+"2.2", "2.3", "2.4", and "2.5".
 
 Automated tools consuming metadata SHOULD warn if ``metadata_version`` is
 greater than the highest version they support, and MUST fail if
@@ -718,6 +718,101 @@ user SHOULD be warned and the value ignored to avoid ambiguity. Tools MAY choose
 to raise an error when reading an invalid name for older metadata versions.
 
 
+.. _core-metadata-import-name:
+
+Import-Name (multiple use)
+===========================
+
+.. versionadded:: 2.5
+
+A string containing an import name that the project exclusively provides when
+installed. The specified import name MUST be a valid Python identifier or can
+be empty. The import names listed in this field MUST be importable when the
+project is installed on *some* platform for the same version of the project.
+This implies that the metadata MUST be consistent across all sdists and wheels
+for a project release.
+
+An import name MAY be followed by a semicolon and the term "private"
+(e.g. ``; private``) with any amount of whitespace surrounding the semicolon.
+This signals to tools that the import name is not part of the public API for
+the project.
+
+Projects SHOULD list all the shortest import names that are exclusively provided
+by the project. If any of the shortest names are dotted names, all intervening
+names from that name to the top-level name should also be listed appropriately
+in ``Import-Name`` and/or ``Import-Namespace``.
+
+If a project lists the same name in both ``Import-Name`` and
+``Import-Namespace``, tools MUST raise an error due to ambiguity.
+
+Tools SHOULD raise an error when two projects that are about to be installed
+list names that overlap in each other's ``Import-Name`` entries, or when a
+project has an entry in ``Import-Name`` that overlaps with another project's
+``Import-Namespace`` entries. This is to avoid projects unexpectedly shadowing
+another project's code. Tools MAY warn or raise an error when installing a
+project into a preexisting environment where there is import name overlap with
+a project that is already installed.
+
+Projects MAY have an empty ``Import-Name`` field in their metadata to represent
+a project with no import names (i.e. there are no Python modules of any kind in
+the distribution file).
+
+Since projects MAY have no ``Import-Name`` metadata (either because the
+project uses an older metadata version, or because it didn't specify any), then
+tools have no information about what names the project provides. However, in
+practice the majority of projects have their project name match what their
+import name would be. As such, it is a reasonable assumption to make that a
+project name that is normalized in some way to an import name
+(e.g. ``packaging.utils.canonicalize_name(name, validate=True).replace("-", "_")``)
+can be used if some answer is needed.
+
+Examples::
+
+    Import-Name: PIL
+    Import-Name: _private_module ; private
+    Import-Name: zope.interface
+    Import-Name:
+
+
+.. _core-metadata-import-namespace:
+
+Import-Namespace (multiple use)
+================================
+
+.. versionadded:: 2.5
+
+A string containing an import name that the project provides when installed, but
+not exclusively. The specified import name MUST be a valid Python identifier.
+This field is used for namespace packages where multiple projects can contribute
+to the same import namespace. Projects all listing the same import name in
+``Import-Namespace`` can be installed together without shadowing each other.
+
+An import name MAY be followed by a semicolon and the term "private" (e.g.
+``; private``) with any amount of whitespace surrounding the semicolon. This
+signals to tools that the import name is not part of the public API for the
+project.
+
+Projects SHOULD list all the shortest import names that are exclusively provided
+by the project. If any of the shortest names are dotted names, all intervening
+names from that name to the top-level name should also be listed appropriately
+in ``Import-Name`` and/or ``Import-Namespace``.
+
+The import names listed in this field MUST be importable when the project is
+installed on *some* platform for the same version of the project. This implies
+that the metadata MUST be consistent across all sdists and wheels for a project
+release.
+
+If a project lists the same name in both ``Import-Name`` and
+``Import-Namespace``, tools MUST raise an error due to ambiguity.
+
+Note that ``Import-Namespace`` CANNOT be empty like ``Import-Name``.
+
+Examples::
+
+    Import-Namespace: zope
+    Import-Name: _private_module ; private
+
+
 Rarely Used Fields
 ==================
 
@@ -933,34 +1028,39 @@ Example::
 History
 =======
 
-- August 2025: Clarified that ``Dynamic`` only affects how fields
-  must be treated when building a wheel from a sdist, not when modifying
-  a wheel.
+- March 2001: Core metadata 1.0 was approved through :pep:`241`.
 
-- August 2024: Core metadata 2.4 was approved through :pep:`639`.
+- April 2003: Core metadata 1.1 was approved through :pep:`314`.
 
-  - Added the ``License-Expression`` field.
-  - Added the ``License-File`` field.
+- February 2010: Core metadata 1.2 was approved through :pep:`345`.
 
-- March 2022: Core metadata 2.3 was approved through :pep:`685`.
+- February 2018: Core metadata 2.1 was approved through :pep:`566`.
 
-  - Restricted extra names to be normalized.
+  - Added ``Description-Content-Type`` and ``Provides-Extra``.
+  - Added canonical method for transforming metadata to JSON.
+  - Restricted the grammar of the ``Name`` field.
 
 - October 2020: Core metadata 2.2 was approved through :pep:`643`.
 
   - Added the ``Dynamic`` field.
 
-- February 2018: Core metadata 2.1 was approved through :pep:`566`.
+- March 2022: Core metadata 2.3 was approved through :pep:`685`.
 
-  - Added ``Description-Content-Type`` and ``Provides-Extra``.
-  - Added canonical method for transforming metadata to JSON.
-  - Restricted the grammar of the ``Name`` field.
+  - Restricted extra names to be normalized.
 
-- February 2010: Core metadata 1.2 was approved through :pep:`345`.
+- August 2024: Core metadata 2.4 was approved through :pep:`639`.
 
-- April 2003: Core metadata 1.1 was approved through :pep:`314`:
+  - Added the ``License-Expression`` field.
+  - Added the ``License-File`` field.
 
-- March 2001: Core metadata 1.0 was approved through :pep:`241`.
+- August 2025: Clarified that ``Dynamic`` only affects how fields
+  must be treated when building a wheel from a sdist, not when modifying
+  a wheel.
+
+- September 2025: Core metadata 2.5 was approved through :pep:`794`.
+
+  - Added the ``Import-Name`` field.
+  - Added the ``Import-Namespace`` field.
 
 ----
 
diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 4ce9b7484..25004dfd5 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -136,6 +136,8 @@ The complete list of keys allowed in the ``[project]`` table are:
 - ``dynamic``
 - ``entry-points``
 - ``gui-scripts``
+- ``import-names``
+- ``import-namespaces``
 - ``keywords``
 - ``license``
 - ``license-files``
@@ -466,6 +468,97 @@ matching :ref:`Provides-Extra `
 metadata.
 
 
+.. _pyproject-toml-import-names:
+
+``import-names``
+----------------
+
+- TOML_ type: array of strings
+- Corresponding :ref:`core metadata ` field:
+  :ref:`Import-Name `
+
+An array of strings specifying the import names that the project exclusively
+provides when installed. Each string MUST be a valid Python identifier or can
+be empty. An import name MAY be followed by a semicolon and the term "private"
+(e.g. ``"; private"``) with any amount of whitespace surrounding the semicolon.
+
+Projects SHOULD list all the shortest import names that are exclusively provided
+by the project. If any of the shortest names are dotted names, all intervening
+names from that name to the top-level name should also be listed appropriately
+in ``import-names`` and/or ``import-namespaces``. For instance, a project which
+is a single package named spam with multiple submodules would only list
+``project.import-names = ["spam"]``. A project that lists ``spam.bacon.eggs``
+would also need to account for ``spam`` and ``spam.bacon`` appropriately in
+``import-names`` and ``import-namespaces``. Listing all names acts as a check
+that the intent of the import names is as expected. As well, projects SHOULD
+list all import names, public or private, using the ``; private`` modifier as
+appropriate.
+
+If a project lists the same name in both ``import-names`` and
+``import-namespaces``, then tools MUST raise an error due to ambiguity.
+
+Projects MAY set ``import-names`` to an empty array to represent a project with
+no import names (i.e. there are no Python modules of any kind in the
+distribution file).
+
+Build back-ends MAY support dynamically calculating the value if the user
+declares the key in ``project.dynamic``.
+
+Examples:
+
+.. code-block:: toml
+
+   [project]
+   name = "pillow"
+   import-names = ["PIL"]
+
+.. code-block:: toml
+
+   [project]
+   name = "myproject"
+   import-names = ["mypackage", "_private_module ; private"]
+
+
+.. _pyproject-toml-import-namespaces:
+
+``import-namespaces``
+---------------------
+
+- TOML_ type: array of strings
+- Corresponding :ref:`core metadata ` field:
+  :ref:`Import-Namespace `
+
+An array of strings specifying the import names that the project provides when
+installed, but not exclusively. Each string MUST be a valid Python identifier.
+An import name MAY be followed by a semicolon and the term "private" (e.g.
+``"; private"``) with any amount of whitespace surrounding the semicolon. Note
+that unlike ``import-names``, ``import-namespaces`` CANNOT be an empty array.
+
+Projects SHOULD list all the shortest import names that are exclusively provided
+by the project. If any of the shortest names are dotted names, all intervening
+names from that name to the top-level name should also be listed appropriately
+in ``import-names`` and/or ``import-namespaces``.
+
+This field is used for namespace packages where multiple projects can contribute
+to the same import namespace. Projects all listing the same import name in
+``import-namespaces`` can be installed together without shadowing each other.
+
+If a project lists the same name in both ``import-names`` and
+``import-namespaces``, then tools MUST raise an error due to ambiguity.
+
+Build back-ends MAY support dynamically calculating the value if the user
+declares the key in ``project.dynamic``.
+
+Example:
+
+.. code-block:: toml
+
+   [project]
+   name = "zope-interface"
+   import-namespaces = ["zope"]
+   import-names = ["zope.interface"]
+
+
 .. _pyproject-toml-dynamic:
 .. _declaring-project-metadata-dynamic:
 
@@ -540,5 +633,8 @@ History
 - December 2024: The ``license`` key was redefined, the ``license-files`` key was
   added and ``License::`` classifiers were deprecated through :pep:`639`.
 
+- September 2025: The ``import-names`` and ``import-namespaces`` keys were added
+  through :pep:`794`.
+
 
 .. _TOML: https://toml.io

From 85b31ffb80b6d59f752441b07323ab00eea90eaa Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Tue, 7 Oct 2025 11:45:33 -0700
Subject: [PATCH 1033/1072] Fix glossary link

---
 source/specifications/core-metadata.rst | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index b6d92e6f2..68cc4851f 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -485,8 +485,9 @@ as specified in :doc:`/specifications/license-expression`.
 
 Note that the expression in this field only applies to the
 :term:`Distribution Archive` containing the metadata with this field (e.g.,
-:term:`Source Distribution` or :term:`Wheel`), not the project overall or
-other files related to the project (including other distribution archives).
+:term:`Source Distribution ` or :term:`Wheel`),
+not the project overall or other files related to the project (including other
+distribution archives).
 
 Examples::
 

From e05eb7ac60ae9778da4073d17dcd8260efdd3261 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Wed, 8 Oct 2025 16:09:31 -0700
Subject: [PATCH 1034/1072] Add npmjs.com to linkcheck regex patterns

---
 source/conf.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/source/conf.py b/source/conf.py
index a8a040d6c..95f6f3421 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -146,6 +146,7 @@
     r"https://math-atlas\.sourceforge\.net/?",
     r"https://click\.palletsprojects\.com/.*",
     r"https://typer\.tiangolo\.com/.*",
+    r"https://www.npmjs.com/.*",
 ]
 linkcheck_retries = 5
 # Ignore anchors for common targets when we know they likely won't be found

From 3d1bcf33a28453b026355a0bfa55a639895d32f5 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Thu, 16 Oct 2025 22:57:31 +0000
Subject: [PATCH 1035/1072] [pre-commit.ci] auto fixes from pre-commit.com
 hooks

for more information, see https://pre-commit.ci
---
 source/specifications/core-metadata.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 448e468c4..b49abee71 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -1067,7 +1067,7 @@ History
 
   - Added the ``Import-Name`` field.
   - Added the ``Import-Namespace`` field.
-  
+
 - October 2025: Clarified that ``License-Expression`` applies to the containing
   distribution file and not the project itself.
 

From d470a9fc70fc035f2f35854597f0ccae1501188c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=F0=9F=87=BA=F0=9F=87=A6=20Sviatoslav=20Sydorenko=20=28?=
 =?UTF-8?q?=D0=A1=D0=B2=D1=8F=D1=82=D0=BE=D1=81=D0=BB=D0=B0=D0=B2=20=D0=A1?=
 =?UTF-8?q?=D0=B8=D0=B4=D0=BE=D1=80=D0=B5=D0=BD=D0=BA=D0=BE=29?=
 
Date: Fri, 17 Oct 2025 01:36:37 +0200
Subject: [PATCH 1036/1072] Match RST underlines with title lengths

---
 source/specifications/core-metadata.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index b49abee71..06562e18d 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -727,7 +727,7 @@ to raise an error when reading an invalid name for older metadata versions.
 .. _core-metadata-import-name:
 
 Import-Name (multiple use)
-===========================
+==========================
 
 .. versionadded:: 2.5
 
@@ -783,7 +783,7 @@ Examples::
 .. _core-metadata-import-namespace:
 
 Import-Namespace (multiple use)
-================================
+===============================
 
 .. versionadded:: 2.5
 

From 1f731d298bc18db1e015b8e37e783ae53acd4780 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 6 Oct 2025 19:05:07 +0000
Subject: [PATCH 1037/1072] [pre-commit.ci] pre-commit autoupdate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

updates:
- [github.com/pre-commit/pre-commit-hooks: v5.0.0 → v6.0.0](https://github.com/pre-commit/pre-commit-hooks/compare/v5.0.0...v6.0.0)
- [github.com/astral-sh/ruff-pre-commit: v0.12.2 → v0.13.3](https://github.com/astral-sh/ruff-pre-commit/compare/v0.12.2...v0.13.3)
---
 .pre-commit-config.yaml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index e092c419c..615970dda 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -3,7 +3,7 @@ ci:
 
 repos:
 - repo: https://github.com/pre-commit/pre-commit-hooks
-  rev: v5.0.0
+  rev: v6.0.0
   hooks:
   - id: check-added-large-files
   - id: check-case-conflict
@@ -37,7 +37,7 @@ repos:
   - id: rst-inline-touching-normal
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.12.2
+  rev: v0.13.3
   hooks:
     - id: ruff
     - id: ruff-format

From 1b0bd3162a664de2ae2c0628cf3da1cc2eac58fb Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Tue, 12 Aug 2025 15:12:47 -0400
Subject: [PATCH 1038/1072] simple-repository-api: remove partial TUF section

Signed-off-by: William Woodruff 
---
 .../specifications/simple-repository-api.rst  | 40 -------------------
 1 file changed, 40 deletions(-)

diff --git a/source/specifications/simple-repository-api.rst b/source/specifications/simple-repository-api.rst
index 4f5bb0043..3b9a2ccac 100644
--- a/source/specifications/simple-repository-api.rst
+++ b/source/specifications/simple-repository-api.rst
@@ -910,46 +910,6 @@ which version+format a specific repository URL was configured for, and when maki
 a request to that server, emit an ``Accept`` header that *only* includes the correct
 content type.
 
-
-TUF Support - PEP 458
----------------------
-
-:pep:`458` requires that all API responses are hashable and that they can be uniquely
-identified by a path relative to the repository root. For a Simple API repository, the
-target path is the Root of our API (e.g. ``/simple/`` on PyPI). This creates
-challenges when accessing the API using a TUF client instead of directly using a
-standard HTTP client, as the TUF client cannot handle the fact that a target could
-have multiple different representations that all hash differently.
-
-:pep:`458` does not specify what the target path should be for the Simple API, but
-TUF requires that the target paths be "file-like", in other words, a path like
-``simple/PROJECT/`` is not acceptable, because it technically points to a
-directory.
-
-The saving grace is that the target path does not *have* to actually match the URL
-being fetched from the Simple API, and it can just be a sigil that the fetching code
-knows how to transform into the actual URL that needs to be fetched. This same thing
-can hold true for other aspects of the actual HTTP request, such as the ``Accept``
-header.
-
-Ultimately figuring out how to map a directory to a filename is out of scope for this
-spec (but it would be in scope for :pep:`458`), and this spec defers making a decision
-about how exactly to represent this inside of :pep:`458` metadata.
-
-However, it appears that the current WIP branch against pip that attempts to implement
-:pep:`458` is using a target path like ``simple/PROJECT/index.html``. This could be
-modified to include the API version and serialization format using something like
-``simple/PROJECT/vnd.pypi.simple.vN.FORMAT``. So the v1 HTML format would be
-``simple/PROJECT/vnd.pypi.simple.v1.html`` and the v1 JSON format would be
-``simple/PROJECT/vnd.pypi.simple.v1.json``.
-
-In this case, since ``text/html`` is an alias to ``application/vnd.pypi.simple.v1+html``
-when interacting through TUF, it likely will make the most sense to normalize to the
-more explicit name.
-
-Likewise the ``latest`` metaversion should not be included in the targets, only
-explicitly declared versions should be supported.
-
 Recommendations
 ---------------
 

From 71295b0302931d34a9d9f1e61a7a3ff0e8185a01 Mon Sep 17 00:00:00 2001
From: github-merge-queue
 <118344674+github-merge-queue@users.noreply.github.com>
Date: Mon, 13 Oct 2025 06:11:04 +0000
Subject: [PATCH 1039/1072] Update uv_build version to 0.9.2

---
 source/shared/build-backend-tabs.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/shared/build-backend-tabs.rst b/source/shared/build-backend-tabs.rst
index 9efc8b0d7..c753563dc 100644
--- a/source/shared/build-backend-tabs.rst
+++ b/source/shared/build-backend-tabs.rst
@@ -38,5 +38,5 @@
     .. code-block:: toml
 
         [build-system]
-        requires = ["uv_build >= 0.8.17, <0.9.0"]
+        requires = ["uv_build >= 0.9.2, <0.10.0"]
         build-backend = "uv_build"

From db0ef80312ead420058be7c95f4bb63d865ce202 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Thu, 16 Oct 2025 21:30:42 -0400
Subject: [PATCH 1040/1072] chore(ci): address zizmor findings

This is part 1 of N. The main focus in this PR
is on unpinned references and inadvertent/unnecessary
credential persistence.

Signed-off-by: William Woodruff 
---
 .github/workflows/pr-preview-links.yml        |  2 +-
 .github/workflows/test-translations.yml       | 10 ++++++----
 .github/workflows/test.yml                    |  8 +++++---
 .github/workflows/translation.yml             |  7 ++++---
 .github/workflows/update-uv-build-version.yml |  6 +++---
 .github/workflows/zizmor.yml                  |  6 +++---
 6 files changed, 22 insertions(+), 17 deletions(-)

diff --git a/.github/workflows/pr-preview-links.yml b/.github/workflows/pr-preview-links.yml
index 90ea9cc73..291ec3ad2 100644
--- a/.github/workflows/pr-preview-links.yml
+++ b/.github/workflows/pr-preview-links.yml
@@ -17,6 +17,6 @@ jobs:
   documentation-links:
     runs-on: ubuntu-latest
     steps:
-      - uses: readthedocs/actions/preview@v1
+      - uses: readthedocs/actions/preview@b8bba1484329bda1a3abe986df7ebc80a8950333 # v1.5
         with:
           project-slug: "python-packaging-user-guide"
diff --git a/.github/workflows/test-translations.yml b/.github/workflows/test-translations.yml
index 45dc60aa3..ca6cb08f0 100644
--- a/.github/workflows/test-translations.yml
+++ b/.github/workflows/test-translations.yml
@@ -31,9 +31,10 @@ jobs:
 
     steps:
     - name: Grab the repo src
-      uses: actions/checkout@v4
+      uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
       with:
         ref: ${{ env.I18N_BRANCH }}
+        persist-credentials: false
 
     - name: List languages
       id: languages
@@ -53,12 +54,13 @@ jobs:
 
     steps:
     - name: Grab the repo src
-      uses: actions/checkout@v4
+      uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
       with:
         ref: ${{ env.I18N_BRANCH }}
+        persist-credentials: false
 
     - name: Set up Python
-      uses: actions/setup-python@v5
+      uses: actions/setup-python@e797f83bcb11b83ae66e0230d6156d7c80228e7c # v6.0.0
       with:
         python-version: >-
           3.10
@@ -67,7 +69,7 @@ jobs:
       run: python -m pip install --upgrade nox virtualenv sphinx-lint
 
     - name: Set Sphinx problem matcher
-      uses: sphinx-doc/github-problem-matcher@v1.0
+      uses: sphinx-doc/github-problem-matcher@1f74d6599f4a5e89a20d3c99aab4e6a70f7bda0f # v1.1
 
     - name: Build translated docs in ${{ matrix.language }}
       run: nox -s build -- -q -D language=${{ matrix.language }}
diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
index 172fed713..1f67bad8e 100644
--- a/.github/workflows/test.yml
+++ b/.github/workflows/test.yml
@@ -31,10 +31,12 @@ jobs:
         - linkcheck
 
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
+        with:
+          persist-credentials: false
 
       - name: Set up Python
-        uses: actions/setup-python@v4
+        uses: actions/setup-python@e797f83bcb11b83ae66e0230d6156d7c80228e7c # v6.0.0
         with:
           python-version: "3.11"
           cache: 'pip'
@@ -62,6 +64,6 @@ jobs:
 
     steps:
     - name: Decide whether the needed jobs succeeded or failed
-      uses: re-actors/alls-green@release/v1
+      uses: re-actors/alls-green@05ac9388f0aebcb5727afa17fcccfecd6f8ec5fe # v1.2.2
       with:
         jobs: ${{ toJSON(needs) }}
diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml
index 7cfae2991..1a3f71487 100644
--- a/.github/workflows/translation.yml
+++ b/.github/workflows/translation.yml
@@ -19,14 +19,15 @@ jobs:
 
     steps:
     - name: Grab the repo src
-      uses: actions/checkout@v3
+      uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
       with:
         fetch-depth: 0  # To reach the common commit
+        persist-credentials: true # For `git push`
     - name: Set up git user as [bot]
       # Refs:
       # * https://github.community/t/github-actions-bot-email-address/17204/6
       # * https://github.com/actions/checkout/issues/13#issuecomment-724415212
-      uses: fregante/setup-git-user@v1.1.0
+      uses: fregante/setup-git-user@024bc0b8e177d7e77203b48dab6fb45666854b35 # v2.0.2
 
     - name: Switch to the translation source branch
       run: |
@@ -51,7 +52,7 @@ jobs:
         git merge '${{ github.event.repository.default_branch }}'
 
     - name: Set up Python
-      uses: actions/setup-python@v4
+      uses: actions/setup-python@e797f83bcb11b83ae66e0230d6156d7c80228e7c # v6.0.0
       with:
         python-version: >-
           3.10
diff --git a/.github/workflows/update-uv-build-version.yml b/.github/workflows/update-uv-build-version.yml
index 8aadc7052..d204bd391 100644
--- a/.github/workflows/update-uv-build-version.yml
+++ b/.github/workflows/update-uv-build-version.yml
@@ -17,17 +17,17 @@ jobs:
       pull-requests: write
     steps:
       - name: Checkout repository
-        uses: actions/checkout@v4
+        uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
         with:
           persist-credentials: false
       - name: Set up uv
-        uses: astral-sh/setup-uv@v5
+        uses: astral-sh/setup-uv@3259c6206f993105e3a61b142c2d97bf4b9ef83d # v7.1.0
       - name: Update uv_build version
         id: update_script
         run: uv run scripts/update_uv_build_version.py
       - # If there are no changes, no pull request will be created and the action exits silently.
         name: Create Pull Request
-        uses: peter-evans/create-pull-request@v7
+        uses: peter-evans/create-pull-request@271a8d0340265f705b14b6d32b9829c1cb33d45e # v7.0.8
         with:
           token: ${{ secrets.GITHUB_TOKEN }}
           commit-message: Update uv_build version to ${{ steps.update_script.outputs.version }}
diff --git a/.github/workflows/zizmor.yml b/.github/workflows/zizmor.yml
index d99b6473c..6c8c62f7d 100644
--- a/.github/workflows/zizmor.yml
+++ b/.github/workflows/zizmor.yml
@@ -19,12 +19,12 @@ jobs:
       actions: read
     steps:
       - name: Checkout repository
-        uses: actions/checkout@v4
+        uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
         with:
           persist-credentials: false
 
       - name: Install the latest version of uv
-        uses: astral-sh/setup-uv@v5
+        uses: astral-sh/setup-uv@3259c6206f993105e3a61b142c2d97bf4b9ef83d # v7.1.0
 
       - name: Run zizmor 🌈
         run: uvx zizmor --format sarif source/guides/github-actions-ci-cd-sample/* > results.sarif
@@ -32,7 +32,7 @@ jobs:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 
       - name: Upload SARIF file
-        uses: github/codeql-action/upload-sarif@v3
+        uses: github/codeql-action/upload-sarif@f443b600d91635bebf5b0d9ebc620189c0d6fba5 # v4.30.8
         with:
           sarif_file: results.sarif
           category: zizmor

From e5a97fb662b96ebc3baccbc6765e2afc6a3c5b73 Mon Sep 17 00:00:00 2001
From: William Woodruff 
Date: Thu, 16 Oct 2025 21:38:27 -0400
Subject: [PATCH 1041/1072] chore(ci): fix some template injections too

Signed-off-by: William Woodruff 
---
 .github/workflows/test-translations.yml | 8 ++++++--
 .github/workflows/translation.yml       | 7 ++++++-
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/.github/workflows/test-translations.yml b/.github/workflows/test-translations.yml
index ca6cb08f0..537a8df72 100644
--- a/.github/workflows/test-translations.yml
+++ b/.github/workflows/test-translations.yml
@@ -72,7 +72,9 @@ jobs:
       uses: sphinx-doc/github-problem-matcher@1f74d6599f4a5e89a20d3c99aab4e6a70f7bda0f # v1.1
 
     - name: Build translated docs in ${{ matrix.language }}
-      run: nox -s build -- -q -D language=${{ matrix.language }}
+      run: nox -s build -- -q -D language=${LANGUAGE}
+      env:
+        LANGUAGE: ${{ matrix.language }}
 
     - name: Set Sphinx Lint problem matcher
       if: always()
@@ -80,4 +82,6 @@ jobs:
 
     - name: Lint translation file
       if: always()
-      run: sphinx-lint locales/${{ matrix.language }}/LC_MESSAGES/messages.po
+      run: sphinx-lint locales/${LANGUAGE}/LC_MESSAGES/messages.po
+      env:
+        LANGUAGE: ${{ matrix.language }}
diff --git a/.github/workflows/translation.yml b/.github/workflows/translation.yml
index 1a3f71487..67fcb5edf 100644
--- a/.github/workflows/translation.yml
+++ b/.github/workflows/translation.yml
@@ -17,6 +17,9 @@ jobs:
     runs-on: ubuntu-latest
     if: github.repository_owner == 'pypa'
 
+    permissions:
+      contents: write # to push to I18N_BRANCH
+
     steps:
     - name: Grab the repo src
       uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
@@ -49,7 +52,9 @@ jobs:
       run: |
         sh -x
 
-        git merge '${{ github.event.repository.default_branch }}'
+        git merge "${DEFAULT_BRANCH}"
+      env:
+        DEFAULT_BRANCH: ${{ github.event.repository.default_branch }}
 
     - name: Set up Python
       uses: actions/setup-python@e797f83bcb11b83ae66e0230d6156d7c80228e7c # v6.0.0

From 1700f858e4066beda60c1fab2650013b9a789af9 Mon Sep 17 00:00:00 2001
From: Stephen Rosen 
Date: Sat, 27 Sep 2025 00:21:18 -0500
Subject: [PATCH 1042/1072] Convert 'Dependency Groups' to lowercase

Outside of titles and other contexts, convert this term to lowercase.
This usage better matches other terms defined in the packaging
specifications, such as "script metadata" and "dependency specifiers".

For reference, this change was inspired by:
https://github.com/pypa/packaging.python.org/pull/1847#discussion_r2266571023
---
 source/specifications/dependency-groups.rst | 26 ++++++++++-----------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/source/specifications/dependency-groups.rst b/source/specifications/dependency-groups.rst
index 22e4cba0d..a35afb475 100644
--- a/source/specifications/dependency-groups.rst
+++ b/source/specifications/dependency-groups.rst
@@ -4,15 +4,15 @@
 Dependency Groups
 =================
 
-This specification defines Dependency Groups, a mechanism for storing package
+This specification defines dependency groups, a mechanism for storing package
 requirements in ``pyproject.toml`` files such that they are not included in
 project metadata when it is built.
 
-Dependency Groups are suitable for internal development use-cases like linting
+Dependency groups are suitable for internal development use-cases like linting
 and testing, as well as for projects which are not built for distribution, like
 collections of related scripts.
 
-Fundamentally, Dependency Groups should be thought of as being a standardized
+Fundamentally, dependency groups should be thought of as being a standardized
 subset of the capabilities of ``requirements.txt`` files (which are
 ``pip``-specific).
 
@@ -38,7 +38,7 @@ and a similar table which defines ``docs``, ``test``, and ``coverage`` groups::
 The ``[dependency-groups]`` Table
 ---------------------------------
 
-Dependency Groups are defined as a table in ``pyproject.toml`` named
+Dependency groups are defined as a table in ``pyproject.toml`` named
 ``dependency-groups``. The ``dependency-groups`` table contains an arbitrary
 number of user-defined keys, each of which has, as its value, a list of
 requirements.
@@ -103,9 +103,9 @@ Package Building
 
 Build backends MUST NOT include Dependency Group data in built distributions as
 package metadata. This means that sdist ``PKG-INFO`` and wheel ``METADATA``
-files should not include referenceable fields containing Dependency Groups.
+files should not include referenceable fields containing dependency groups.
 
-It is, however, valid to use Dependency Groups in the evaluation of dynamic
+It is, however, valid to use dependency groups in the evaluation of dynamic
 metadata, and ``pyproject.toml`` files included in sdists will still contain
 ``[dependency-groups]``. However, the table's contents are not part of a built
 package's interfaces.
@@ -114,28 +114,28 @@ Installing Dependency Groups & Extras
 -------------------------------------
 
 There is no syntax or specification-defined interface for installing or
-referring to Dependency Groups. Tools are expected to provide dedicated
+referring to dependency groups. Tools are expected to provide dedicated
 interfaces for this purpose.
 
 Tools MAY choose to provide the same or similar interfaces for interacting
-with Dependency Groups as they do for managing extras. Tools authors are
+with dependency groups as they do for managing extras. Tools authors are
 advised that the specification does not forbid having an extra whose name
 matches a Dependency Group. Separately, users are advised to avoid creating
-Dependency Groups whose names match extras, and tools MAY treat such matching
+dependency groups whose names match extras, and tools MAY treat such matching
 as an error.
 
 Validation and Compatibility
 ----------------------------
 
-Tools supporting Dependency Groups may want to validate data before using it.
+Tools supporting dependency groups may want to validate data before using it.
 When implementing such validation, authors should be aware of the possibility
 of future extensions to the specification, so that they do not unnecessarily
 emit errors or warnings.
 
 Tools SHOULD error when evaluating or processing unrecognized data in
-Dependency Groups.
+dependency groups.
 
-Tools SHOULD NOT eagerly validate the contents of *all* Dependency Groups
+Tools SHOULD NOT eagerly validate the contents of *all* dependency groups
 unless they have a need to do so.
 
 This means that in the presence of the following data, most tools should allow
@@ -151,7 +151,7 @@ the ``foo`` group to be used and only error if the ``bar`` group is used:
 
     There are several known cases of tools which have good cause to be
     stricter. Linters and validators are an example, as their purpose is to
-    validate the contents of all Dependency Groups.
+    validate the contents of all dependency groups.
 
 Reference Implementation
 ========================

From c6f6be53438286173bb3d2417103a2b91bce4f2f Mon Sep 17 00:00:00 2001
From: woodruffw <3059210+woodruffw@users.noreply.github.com>
Date: Tue, 21 Oct 2025 17:54:46 +0000
Subject: [PATCH 1043/1072] Update uv_build version to 0.9.5

---
 source/shared/build-backend-tabs.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/shared/build-backend-tabs.rst b/source/shared/build-backend-tabs.rst
index c753563dc..b80d92b39 100644
--- a/source/shared/build-backend-tabs.rst
+++ b/source/shared/build-backend-tabs.rst
@@ -38,5 +38,5 @@
     .. code-block:: toml
 
         [build-system]
-        requires = ["uv_build >= 0.9.2, <0.10.0"]
+        requires = ["uv_build >= 0.9.5, <0.10.0"]
         build-backend = "uv_build"

From 1b5fa563617a71b1ab9b49f959004ee1fe3bcad6 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Mon, 27 Oct 2025 14:55:37 -0700
Subject: [PATCH 1044/1072] Update import name guidelines to use 'SHOULD' for
 intermediate names

---
 source/specifications/core-metadata.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index 06562e18d..a43d92ff6 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -745,7 +745,7 @@ the project.
 
 Projects SHOULD list all the shortest import names that are exclusively provided
 by the project. If any of the shortest names are dotted names, all intervening
-names from that name to the top-level name should also be listed appropriately
+names from that name to the top-level name SHOULD also be listed appropriately
 in ``Import-Name`` and/or ``Import-Namespace``.
 
 If a project lists the same name in both ``Import-Name`` and
@@ -800,7 +800,7 @@ project.
 
 Projects SHOULD list all the shortest import names that are exclusively provided
 by the project. If any of the shortest names are dotted names, all intervening
-names from that name to the top-level name should also be listed appropriately
+names from that name to the top-level name SHOULD also be listed appropriately
 in ``Import-Name`` and/or ``Import-Namespace``.
 
 The import names listed in this field MUST be importable when the project is

From 4be49e6632a5987ab438d605ede1bd37c04e994c Mon Sep 17 00:00:00 2001
From: Henry Schreiner 
Date: Tue, 28 Oct 2025 10:14:08 -0400
Subject: [PATCH 1045/1072] fix: links to pip's pyproject.toml pages are dead
 with 25.3

Signed-off-by: Henry Schreiner 
---
 source/guides/modernize-setup-py-project.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/source/guides/modernize-setup-py-project.rst b/source/guides/modernize-setup-py-project.rst
index 5b6ab3c26..1f71d1973 100644
--- a/source/guides/modernize-setup-py-project.rst
+++ b/source/guides/modernize-setup-py-project.rst
@@ -67,7 +67,7 @@ For more details:
 
 * :ref:`distributing-packages`
 * :ref:`pyproject-build-system-table`
-* :doc:`pip:reference/build-system/pyproject-toml`
+* :doc:`pip:reference/build-system`
 
 
 How to handle additional build-time dependencies?
@@ -128,7 +128,7 @@ For some projects this isolation is unwanted and it can be deactivated as follow
 
 For more details:
 
-* :doc:`pip:reference/build-system/pyproject-toml`
+* :doc:`pip:reference/build-system`
 
 
 How to handle packaging metadata?
@@ -244,5 +244,5 @@ Where to read more about this?
 ==============================
 
 * :ref:`pyproject-toml-spec`
-* :doc:`pip:reference/build-system/pyproject-toml`
+* :doc:`pip:reference/build-system`
 * :doc:`setuptools:build_meta`

From 4e8a3d24f166250ce1e9249d39f644526542633c Mon Sep 17 00:00:00 2001
From: Ben Tucker 
Date: Fri, 7 Nov 2025 16:54:35 +0000
Subject: [PATCH 1046/1072] docs: update spec for the macOS platform tag

---
 source/specifications/platform-compatibility-tags.rst | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index 0502c8c03..fcb317cfe 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -199,10 +199,11 @@ artefact of Apple's official macOS naming scheme). The schema for compatibility
 tags is :file:`macosx_{x}_{y}_{arch}`, indicating that the wheel is compatible
 with macOS ``x.y`` or later on the architecture ``arch``.
 
-The values of ``x`` and ``y`` correspond to the major and minor version number of
-the macOS release, respectively. They must both be positive integers, with the
-``x`` value being ``>= 10``. The version number always includes a major *and*
-minor version, even if Apple's official version numbering only refers to
+The values of ``x`` and ``y`` correspond to the major and minor version number
+of the macOS release, respectively. They must both be positive integers, with
+the ``x`` value being either ``10 <= x <= 15``, or ``>=26`` and corresponding
+to the year of the macOS release. The version number always includes a major
+*and* minor version, even if Apple's official version numbering only refers to
 the major value. For example, ``macosx_11_0_arm64`` indicates compatibility
 with macOS 11 or later.
 

From ac13541a8e340996da605841e0ca278eb5bc2eb9 Mon Sep 17 00:00:00 2001
From: Pradyun Gedam 
Date: Sun, 9 Nov 2025 02:51:38 +0000
Subject: [PATCH 1047/1072] Allow errors for missing `[build-system]` table
 with no metadata

Permit installers to present an error if the working directory does not
seem like a location that the user intended to install from.
---
 source/specifications/pyproject-toml.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/source/specifications/pyproject-toml.rst b/source/specifications/pyproject-toml.rst
index 74dbe34e3..48f35599e 100644
--- a/source/specifications/pyproject-toml.rst
+++ b/source/specifications/pyproject-toml.rst
@@ -61,6 +61,10 @@ table then the default values as specified above should be used.
 If the table is specified but is missing required fields then the tool
 should consider it an error.
 
+Tools may choose to present an error to the user if the file exists,
+``[build-system]`` table is missing, and there is no clear indication
+that the project should be built (e.g., no setup.py/setup.cfg or other
+build configuration files, and no ``[project]`` table).
 
 To provide a type-specific representation of the resulting data from
 the TOML file for illustrative purposes only, the following

From 82f35b5a2abcf1989574e9363cd2c3a5a6c1835f Mon Sep 17 00:00:00 2001
From: Pradyun Gedam 
Date: Sun, 9 Nov 2025 02:57:19 +0000
Subject: [PATCH 1048/1072] Drop warehouse's intersphinx entry

Warehouse is not referenced from these docs and their docs have moved to
mkdocs-material.
---
 source/conf.py | 1 -
 1 file changed, 1 deletion(-)

diff --git a/source/conf.py b/source/conf.py
index 95f6f3421..030a167e4 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -210,7 +210,6 @@
     "tox": ("https://tox.wiki/en/latest/", None),
     "twine": ("https://twine.readthedocs.io/en/stable/", None),
     "virtualenv": ("https://virtualenv.pypa.io/en/stable/", None),
-    "warehouse": ("https://warehouse.pypa.io/", None),
 }
 
 # -- Options for todo extension --------------------------------------------------------

From 44af965c54008fe7bdd16ce7522e1b5398041c9c Mon Sep 17 00:00:00 2001
From: github-merge-queue
 <118344674+github-merge-queue@users.noreply.github.com>
Date: Mon, 10 Nov 2025 06:11:10 +0000
Subject: [PATCH 1049/1072] Update uv_build version to 0.9.8

---
 source/shared/build-backend-tabs.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/shared/build-backend-tabs.rst b/source/shared/build-backend-tabs.rst
index b80d92b39..621eb4177 100644
--- a/source/shared/build-backend-tabs.rst
+++ b/source/shared/build-backend-tabs.rst
@@ -38,5 +38,5 @@
     .. code-block:: toml
 
         [build-system]
-        requires = ["uv_build >= 0.9.5, <0.10.0"]
+        requires = ["uv_build >= 0.9.8, <0.10.0"]
         build-backend = "uv_build"

From dc58ce94e84fa8e0b99ed5031d9b723951f3e9f3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Filipe=20La=C3=ADns?= 
Date: Wed, 12 Nov 2025 13:45:06 +0000
Subject: [PATCH 1050/1072] nox: allow passing arguments to linkcheck
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Filipe Laíns 
---
 noxfile.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/noxfile.py b/noxfile.py
index 698e82f9d..484a8d39a 100644
--- a/noxfile.py
+++ b/noxfile.py
@@ -89,6 +89,7 @@ def linkcheck(session):
         "--keep-going",  # be strict
         "source",  # where the rst files are located
         "build",  # where to put the check output
+        *session.posargs,
     )
 
 

From 7a8eb853713eea644af3d5885d88c2d0e3c7390f Mon Sep 17 00:00:00 2001
From: github-merge-queue
 <118344674+github-merge-queue@users.noreply.github.com>
Date: Mon, 17 Nov 2025 06:11:01 +0000
Subject: [PATCH 1051/1072] Update uv_build version to 0.9.9

---
 source/shared/build-backend-tabs.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/shared/build-backend-tabs.rst b/source/shared/build-backend-tabs.rst
index 621eb4177..23918e388 100644
--- a/source/shared/build-backend-tabs.rst
+++ b/source/shared/build-backend-tabs.rst
@@ -38,5 +38,5 @@
     .. code-block:: toml
 
         [build-system]
-        requires = ["uv_build >= 0.9.8, <0.10.0"]
+        requires = ["uv_build >= 0.9.9, <0.10.0"]
         build-backend = "uv_build"

From 761f6bdc1ebfd6885488dab57b8f4f4b9ae0ceb7 Mon Sep 17 00:00:00 2001
From: konstin 
Date: Fri, 21 Nov 2025 11:21:51 +0100
Subject: [PATCH 1052/1072] Document `macosx_0_{y}_{arch}` pattern

Following https://discuss.python.org/t/document-that-macos-platform-tags-use-minor-version-0-for-macos-11/104616:

 * Document that for macOS 11 and later, the platform tag is `macosx_0_{y}_{arch}`
 * Document that platform tags may change over time.
---
 .../platform-compatibility-tags.rst           | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/source/specifications/platform-compatibility-tags.rst b/source/specifications/platform-compatibility-tags.rst
index fcb317cfe..b4c14a4c0 100644
--- a/source/specifications/platform-compatibility-tags.rst
+++ b/source/specifications/platform-compatibility-tags.rst
@@ -82,6 +82,11 @@ decide how to best use the ABI tag.
 Platform Tag
 ============
 
+.. important::
+    Platform tags are dependent on the versioning of the operating system or
+    platform they represent and may change over time as the underlying platform
+    changes its versioning.
+
 Basic platform tags
 -------------------
 
@@ -199,13 +204,13 @@ artefact of Apple's official macOS naming scheme). The schema for compatibility
 tags is :file:`macosx_{x}_{y}_{arch}`, indicating that the wheel is compatible
 with macOS ``x.y`` or later on the architecture ``arch``.
 
-The values of ``x`` and ``y`` correspond to the major and minor version number
-of the macOS release, respectively. They must both be positive integers, with
-the ``x`` value being either ``10 <= x <= 15``, or ``>=26`` and corresponding
-to the year of the macOS release. The version number always includes a major
-*and* minor version, even if Apple's official version numbering only refers to
-the major value. For example, ``macosx_11_0_arm64`` indicates compatibility
-with macOS 11 or later.
+For macOS 10, the tag is :file:`macosx_10_{y}_{arch}`, where ``y`` corresponds
+to the minor version number of the macOS release. For macOS 11 and higher, the
+tag is :file:`macosx_{x}_0_{arch}`, where ``x`` corresponds to the major
+version number of the macOS release. Following the published macOS major
+versions, the ``x`` value is either ``10 <= x <= 15``, or ``>=26`` and
+corresponding to the year of the macOS release. For example,
+``macosx_11_0_arm64`` indicates compatibility with macOS 11 or later.
 
 macOS binaries can be compiled for a single architecture, or can include support
 for multiple architectures in the same binary (sometimes called "fat" binaries).

From 7a7d7ba624c842b224ed904cd0c7bae1dfda3f56 Mon Sep 17 00:00:00 2001
From: Damian Shaw 
Date: Sat, 22 Nov 2025 12:31:58 -0500
Subject: [PATCH 1053/1072] Specify arbitrary equality case insensitivity.

---
 source/specifications/version-specifiers.rst | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/source/specifications/version-specifiers.rst b/source/specifications/version-specifiers.rst
index c0b544160..f620c9054 100644
--- a/source/specifications/version-specifiers.rst
+++ b/source/specifications/version-specifiers.rst
@@ -1016,8 +1016,9 @@ Arbitrary equality
 
 Arbitrary equality comparisons are simple string equality operations which do
 not take into account any of the semantic information such as zero padding or
-local versions. This operator also does not support prefix matching as the
-``==`` operator does.
+local versions. The comparison MUST treat ASCII letters case-insensitively, e.g.
+by lowercasing, and is unspecified for non-ASCII text. This operator also does
+not support prefix matching as the ``==`` operator does.
 
 The primary use case for arbitrary equality is to allow for specifying a
 version which cannot otherwise be represented by this specification. This operator is
@@ -1271,3 +1272,4 @@ History
 - August 2014: This specification was approved through :pep:`440`.
 - May 2025: Clarify that development releases are a form of pre-release when
   they are handled.
+- Nov 2025: Specify arbitrary equality case insensitivity.

From 5e9c85eefa28bb369c1187e61504a8c78d55a054 Mon Sep 17 00:00:00 2001
From: Stefaan Lippens 
Date: Sun, 23 Nov 2025 21:42:54 +0100
Subject: [PATCH 1054/1072] Rename publish-to-test-pypi.yml to
 publish-to-pypi.yml #1935

---
 ...lish-to-test-pypi.yml => publish-to-pypi.yml} |  0
 ...ases-using-github-actions-ci-cd-workflows.rst | 16 ++++++++--------
 2 files changed, 8 insertions(+), 8 deletions(-)
 rename source/guides/github-actions-ci-cd-sample/{publish-to-test-pypi.yml => publish-to-pypi.yml} (100%)

diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-pypi.yml
similarity index 100%
rename from source/guides/github-actions-ci-cd-sample/publish-to-test-pypi.yml
rename to source/guides/github-actions-ci-cd-sample/publish-to-pypi.yml
diff --git a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
index e9f601e03..a3d893c9f 100644
--- a/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
+++ b/source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst
@@ -87,13 +87,13 @@ Creating a workflow definition
 GitHub CI/CD workflows are declared in YAML files stored in the
 ``.github/workflows/`` directory of your repository.
 
-Let's create a ``.github/workflows/publish-to-test-pypi.yml``
+Let's create a ``.github/workflows/publish-to-pypi.yml``
 file.
 
 Start it with a meaningful name and define the event that
 should make GitHub run this workflow:
 
-.. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml
+.. literalinclude:: github-actions-ci-cd-sample/publish-to-pypi.yml
    :language: yaml
    :end-before: jobs:
 
@@ -107,7 +107,7 @@ build the distribution packages.
 First, we'll define the job for building the dist packages of
 your project and storing them for later use:
 
-.. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml
+.. literalinclude:: github-actions-ci-cd-sample/publish-to-pypi.yml
    :language: yaml
    :start-at: jobs:
    :end-before: Install pypa/build
@@ -119,7 +119,7 @@ And now we can build the dists from source and store them.
 In this example, we'll use the ``build`` package.
 So add this to the steps list:
 
-.. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml
+.. literalinclude:: github-actions-ci-cd-sample/publish-to-pypi.yml
    :language: yaml
    :start-at: Install pypa/build
    :end-before: publish-to-pypi
@@ -136,7 +136,7 @@ UI nicely. Additionally, it allows acquiring an OpenID Connect token
 that the ``pypi-publish`` actions needs to implement secretless
 Trusted Publishing to PyPI.
 
-.. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml
+.. literalinclude:: github-actions-ci-cd-sample/publish-to-pypi.yml
    :language: yaml
    :start-after: path: dist/
    :end-before: steps:
@@ -149,7 +149,7 @@ Publishing the distribution to PyPI
 
 Finally, add the following steps at the end:
 
-.. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml
+.. literalinclude:: github-actions-ci-cd-sample/publish-to-pypi.yml
    :language: yaml
    :start-after: id-token: write
    :end-before:  publish-to-testpypi:
@@ -175,7 +175,7 @@ Now, repeat these steps and create another job for
 publishing to the TestPyPI package index under the ``jobs``
 section:
 
-.. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml
+.. literalinclude:: github-actions-ci-cd-sample/publish-to-pypi.yml
    :language: yaml
    :start-at: publish-to-testpypi
 
@@ -191,7 +191,7 @@ This paragraph showcases the whole workflow after following the above guide.
 
 .. collapse:: Click here to display the entire GitHub Actions CI/CD workflow definition
 
-    .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml
+    .. literalinclude:: github-actions-ci-cd-sample/publish-to-pypi.yml
        :language: yaml
 
 That's all, folks!

From 43060740c4109e24f8dd6902b731d9d288fc5c21 Mon Sep 17 00:00:00 2001
From: github-merge-queue
 <118344674+github-merge-queue@users.noreply.github.com>
Date: Mon, 24 Nov 2025 06:10:56 +0000
Subject: [PATCH 1055/1072] Update uv_build version to 0.9.11

---
 source/shared/build-backend-tabs.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/shared/build-backend-tabs.rst b/source/shared/build-backend-tabs.rst
index 23918e388..c732ed2e9 100644
--- a/source/shared/build-backend-tabs.rst
+++ b/source/shared/build-backend-tabs.rst
@@ -38,5 +38,5 @@
     .. code-block:: toml
 
         [build-system]
-        requires = ["uv_build >= 0.9.9, <0.10.0"]
+        requires = ["uv_build >= 0.9.11, <0.10.0"]
         build-backend = "uv_build"

From 97a72c521adb07961e4766039a30bc3e0159ac09 Mon Sep 17 00:00:00 2001
From: Damian Shaw 
Date: Tue, 25 Nov 2025 14:37:04 -0500
Subject: [PATCH 1056/1072] Update source/specifications/version-specifiers.rst

Co-authored-by: Alyssa Coghlan 
---
 source/specifications/version-specifiers.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/specifications/version-specifiers.rst b/source/specifications/version-specifiers.rst
index f620c9054..13015794f 100644
--- a/source/specifications/version-specifiers.rst
+++ b/source/specifications/version-specifiers.rst
@@ -1272,4 +1272,4 @@ History
 - August 2014: This specification was approved through :pep:`440`.
 - May 2025: Clarify that development releases are a form of pre-release when
   they are handled.
-- Nov 2025: Specify arbitrary equality case insensitivity.
+- Nov 2025: Make arbitrary equality case insensitivity explicit.

From 22d9ddf8899b615ee51fe46f0cd9dff8c108bcbf Mon Sep 17 00:00:00 2001
From: Benjamin Rodenberg 
Date: Thu, 6 Nov 2025 13:18:09 +0100
Subject: [PATCH 1057/1072] Fix typo in creating-command-line-tools.rst

---
 source/guides/creating-command-line-tools.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/guides/creating-command-line-tools.rst b/source/guides/creating-command-line-tools.rst
index 72e3e37ef..cbe8b3bb0 100644
--- a/source/guides/creating-command-line-tools.rst
+++ b/source/guides/creating-command-line-tools.rst
@@ -154,7 +154,7 @@ To just run the program without installing it permanently, use ``pipx run``, whi
 	$ pipx run --spec . greet --doctor
 
 This syntax is a bit impractical, however; as the name of the entry point we defined above does not match the package name,
-we need to state explicitly which executable script to run (even though there is only on in existence).
+we need to state explicitly which executable script to run (even though there is only one in existence).
 
 There is, however, a more practical solution to this problem, in the form of an entry point specific to ``pipx run``.
 The same can be defined as follows in :file:`pyproject.toml`:

From 870e6fe9799b8885d547dc88cc2c2b62057f3eb0 Mon Sep 17 00:00:00 2001
From: Brett Cannon 
Date: Mon, 27 Jan 2025 16:57:03 -0800
Subject: [PATCH 1058/1072] Fix the use of underscores when a hyphen is more
 accurate

---
 source/specifications/core-metadata.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/specifications/core-metadata.rst b/source/specifications/core-metadata.rst
index a43d92ff6..eb9a03ff6 100644
--- a/source/specifications/core-metadata.rst
+++ b/source/specifications/core-metadata.rst
@@ -52,9 +52,9 @@ Metadata-Version
 Version of the file format; legal values are "1.0", "1.1", "1.2", "2.1",
 "2.2", "2.3", "2.4", and "2.5".
 
-Automated tools consuming metadata SHOULD warn if ``metadata_version`` is
+Automated tools consuming metadata SHOULD warn if ``metadata-version`` is
 greater than the highest version they support, and MUST fail if
-``metadata_version`` has a greater major version than the highest
+``metadata-version`` has a greater major version than the highest
 version they support (as described in the
 :ref:`Version specifier specification `,
 the major version is the value before the first dot).

From 2ee73e02c90f7d7429e0e80120380aee759ce12e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Filipe=20La=C3=ADns?= 
Date: Wed, 12 Nov 2025 13:37:02 +0000
Subject: [PATCH 1059/1072] Restore linkcheck for specs
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Filipe Laíns 
---
 pug_sphinx_extensions/__init__.py | 76 +++++++++++++++++++++++++++++++
 source/conf.py                    | 10 ++--
 2 files changed, 82 insertions(+), 4 deletions(-)
 create mode 100644 pug_sphinx_extensions/__init__.py

diff --git a/pug_sphinx_extensions/__init__.py b/pug_sphinx_extensions/__init__.py
new file mode 100644
index 000000000..ae495bb60
--- /dev/null
+++ b/pug_sphinx_extensions/__init__.py
@@ -0,0 +1,76 @@
+import os
+import urllib
+
+import sphinx.application
+import sphinx.util.logging
+
+
+DOMAIN = 'packaging.python.org'
+
+
+logger = sphinx.util.logging.getLogger(__name__)
+
+
+def resolve_local_html_link(app: sphinx.application.Sphinx, url_path: str) -> str:
+    """Takes path of a link pointing an HTML render of the current project,
+    and returns local path of the referenced document.
+
+    Support links to renders from both the `html` and `dirhtml` builders.
+
+    Example:
+
+    .. code-block:: python
+
+        >>> resolve_local_html_link('https://packaging.python.org/en/latest/flow/')
+        '{srcdir}/flow.rst'
+        >>> resolve_local_html_link('https://packaging.python.org/en/latest/flow.html')
+        '{srcdir}/flow.rst'
+        >>> resolve_local_html_link('https://packaging.python.org/en/latest/specifications/schemas/')
+        '{srcdir}/specifications/schemas/index.rst'
+        >>> resolve_local_html_link('https://packaging.python.org/en/latest/specifications/schemas/build-details-v1.0.schema.json')
+        '{html_extra_path0}/specifications/schemas/build-details-v1.0.schema.json'
+
+    """
+    # Search for document in html_extra_path
+    for entry in app.config.html_extra_path:
+        candidate = (app.confdir / entry / url_path).resolve()
+        if candidate.is_dir():
+            candidate = candidate / 'index.html'
+        if candidate.exists():
+            return os.fspath(candidate)
+    # Convert html path to source path
+    url_path = url_path.removesuffix('/')  # Normalize
+    if url_path.endswith('.html'):
+        document = url_path.removesuffix('.html')
+    elif (candidate := f'{url_path}/index') in app.project.docnames:
+        document = candidate
+    else:
+        document = url_path
+    return app.env.doc2path(document)
+
+
+def rewrite_local_uri(app: sphinx.application.Sphinx, uri: str) -> str:
+    """Replace remote URIs targeting https://packaging.python.org/en/latest/...
+    with local ones, so that local changes are taken into account by linkcheck.
+    """
+    local_uri = uri
+    parsed = urllib.parse.urlparse(uri)
+    if parsed.hostname == DOMAIN and parsed.path.startswith('/en/latest/'):
+        document = parsed.path.removeprefix('/en/latest/')
+        local_uri = resolve_local_html_link(app, document)
+        logger.verbose(
+            f'{uri!s} is a remote URL that points to local sources, '
+            'replacing it with a local URL in linkcheck to take new changes '
+            'into account (pass -vv for more info)'
+        )
+        logger.debug(f'Replacing linkcheck URL {uri!r} with {local_uri!r}')
+    return local_uri
+
+
+def setup(app: sphinx.application.Sphinx) -> dict[str, bool]:
+    app.connect('linkcheck-process-uri', rewrite_local_uri)
+
+    return {
+        'parallel_read_safe': True,
+        'parallel_write_safe': True,
+    }
diff --git a/source/conf.py b/source/conf.py
index d18faf662..ccb828b6e 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -2,6 +2,11 @@
 # https://www.sphinx-doc.org/en/master/usage/configuration.html#project-information
 
 import os
+import pathlib
+import sys
+
+_ROOT = pathlib.Path(__file__).resolve().parent.parent
+sys.path.append(os.fspath(_ROOT))
 
 # Some options are only enabled for the main packaging.python.org deployment builds
 RTD_BUILD = bool(os.getenv("READTHEDOCS"))
@@ -22,6 +27,7 @@
 root_doc = "index"
 
 extensions = [
+    "pug_sphinx_extensions",
     "sphinx.ext.extlinks",
     "sphinx.ext.intersphinx",
     "sphinx.ext.todo",
@@ -133,7 +139,6 @@
 
 linkcheck_ignore = [
     r"http://localhost:\d+",
-    r"https://packaging\.python\.org/en/latest/specifications/schemas/.*",
     r"https://test\.pypi\.org/project/example-package-YOUR-USERNAME-HERE",
     r"https://pypi\.org/manage/.*",
     r"https://test\.pypi\.org/manage/.*",
@@ -162,9 +167,6 @@
     # https://github.com/pypa/packaging.python.org/issues/1744
     r"https://pypi\.org/",
 ]
-linkcheck_exclude_documents = [
-    "specifications/schemas/index",
-]
 
 # -- Options for extlinks ----------------------------------------------------------
 # https://www.sphinx-doc.org/en/master/usage/extensions/extlinks.html#configuration

From 0cef54ccf1a3cf5dc4302e66e57740f2ea046cd3 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Wed, 12 Nov 2025 14:23:22 +0000
Subject: [PATCH 1060/1072] [pre-commit.ci] auto fixes from pre-commit.com
 hooks

for more information, see https://pre-commit.ci
---
 pug_sphinx_extensions/__init__.py | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/pug_sphinx_extensions/__init__.py b/pug_sphinx_extensions/__init__.py
index ae495bb60..82abe6997 100644
--- a/pug_sphinx_extensions/__init__.py
+++ b/pug_sphinx_extensions/__init__.py
@@ -5,7 +5,7 @@
 import sphinx.util.logging
 
 
-DOMAIN = 'packaging.python.org'
+DOMAIN = "packaging.python.org"
 
 
 logger = sphinx.util.logging.getLogger(__name__)
@@ -35,14 +35,14 @@ def resolve_local_html_link(app: sphinx.application.Sphinx, url_path: str) -> st
     for entry in app.config.html_extra_path:
         candidate = (app.confdir / entry / url_path).resolve()
         if candidate.is_dir():
-            candidate = candidate / 'index.html'
+            candidate = candidate / "index.html"
         if candidate.exists():
             return os.fspath(candidate)
     # Convert html path to source path
-    url_path = url_path.removesuffix('/')  # Normalize
-    if url_path.endswith('.html'):
-        document = url_path.removesuffix('.html')
-    elif (candidate := f'{url_path}/index') in app.project.docnames:
+    url_path = url_path.removesuffix("/")  # Normalize
+    if url_path.endswith(".html"):
+        document = url_path.removesuffix(".html")
+    elif (candidate := f"{url_path}/index") in app.project.docnames:
         document = candidate
     else:
         document = url_path
@@ -55,22 +55,22 @@ def rewrite_local_uri(app: sphinx.application.Sphinx, uri: str) -> str:
     """
     local_uri = uri
     parsed = urllib.parse.urlparse(uri)
-    if parsed.hostname == DOMAIN and parsed.path.startswith('/en/latest/'):
-        document = parsed.path.removeprefix('/en/latest/')
+    if parsed.hostname == DOMAIN and parsed.path.startswith("/en/latest/"):
+        document = parsed.path.removeprefix("/en/latest/")
         local_uri = resolve_local_html_link(app, document)
         logger.verbose(
-            f'{uri!s} is a remote URL that points to local sources, '
-            'replacing it with a local URL in linkcheck to take new changes '
-            'into account (pass -vv for more info)'
+            f"{uri!s} is a remote URL that points to local sources, "
+            "replacing it with a local URL in linkcheck to take new changes "
+            "into account (pass -vv for more info)"
         )
-        logger.debug(f'Replacing linkcheck URL {uri!r} with {local_uri!r}')
+        logger.debug(f"Replacing linkcheck URL {uri!r} with {local_uri!r}")
     return local_uri
 
 
 def setup(app: sphinx.application.Sphinx) -> dict[str, bool]:
-    app.connect('linkcheck-process-uri', rewrite_local_uri)
+    app.connect("linkcheck-process-uri", rewrite_local_uri)
 
     return {
-        'parallel_read_safe': True,
-        'parallel_write_safe': True,
+        "parallel_read_safe": True,
+        "parallel_write_safe": True,
     }

From c2fe979382110513c6515c4f7c14d6f922f76846 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Filipe=20La=C3=ADns?= 
Date: Fri, 14 Nov 2025 22:41:54 +0000
Subject: [PATCH 1061/1072] Resolve local relative links to html_extra_path
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Filipe Laíns 
---
 pug_sphinx_extensions/__init__.py | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/pug_sphinx_extensions/__init__.py b/pug_sphinx_extensions/__init__.py
index 82abe6997..00d91da3c 100644
--- a/pug_sphinx_extensions/__init__.py
+++ b/pug_sphinx_extensions/__init__.py
@@ -1,4 +1,5 @@
 import os
+import pathlib
 import urllib
 
 import sphinx.application
@@ -52,9 +53,12 @@ def resolve_local_html_link(app: sphinx.application.Sphinx, url_path: str) -> st
 def rewrite_local_uri(app: sphinx.application.Sphinx, uri: str) -> str:
     """Replace remote URIs targeting https://packaging.python.org/en/latest/...
     with local ones, so that local changes are taken into account by linkcheck.
+
+    Additionally, resolve local relative links to html_extra_path.
     """
     local_uri = uri
     parsed = urllib.parse.urlparse(uri)
+    # Links to https://packaging.python.org/en/latest/...
     if parsed.hostname == DOMAIN and parsed.path.startswith("/en/latest/"):
         document = parsed.path.removeprefix("/en/latest/")
         local_uri = resolve_local_html_link(app, document)
@@ -64,6 +68,12 @@ def rewrite_local_uri(app: sphinx.application.Sphinx, uri: str) -> str:
             "into account (pass -vv for more info)"
         )
         logger.debug(f"Replacing linkcheck URL {uri!r} with {local_uri!r}")
+    # Local relative links
+    if not parsed.scheme and not parsed.netloc and parsed.path:
+        full_path = pathlib.Path(app.env.docname).parent / parsed.path
+        local_uri = resolve_local_html_link(app, os.fspath(full_path))
+        if local_uri != uri:
+            logger.verbose(f"Local linkcheck URL {uri!r} resolved as {local_uri!r}")
     return local_uri
 
 

From 5a56b2e46ef12ff3fed57b78c79622d357c90a9e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Filipe=20La=C3=ADns?= 
Date: Wed, 19 Nov 2025 12:51:42 +0000
Subject: [PATCH 1062/1072] Add myself to the pug_sphinx_extensions codeowners
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Filipe Laíns 
---
 .github/CODEOWNERS | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
index ecd85064f..0b7c7b289 100644
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@@ -1,6 +1,9 @@
 source/guides/github-actions-ci-cd-sample/* @webknjaz
 source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst @webknjaz
 
+# Sphinx extension
+pug_sphinx_extensions/ @FFY00
+
 # build-details.json
 source/specifications/build-details/ @FFY00
 source/specifications/specs/build-details-*.json @FFY00

From 9daa2ef1184a805e6634ab16f8bd6560cd1c5d2a Mon Sep 17 00:00:00 2001
From: Damian Shaw 
Date: Mon, 1 Dec 2025 20:30:45 -0500
Subject: [PATCH 1063/1072] Fix grammar for arbitrary equality comparisons in
 version specifiers

---
 source/specifications/dependency-specifiers.rst | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/source/specifications/dependency-specifiers.rst b/source/specifications/dependency-specifiers.rst
index d9466c26e..99886563c 100644
--- a/source/specifications/dependency-specifiers.rst
+++ b/source/specifications/dependency-specifiers.rst
@@ -63,7 +63,7 @@ Versions may be specified according to the rules of the
 :ref:`Version specifier specification `. (Note:
 URI is defined in :rfc:`std-66 <3986>`)::
 
-    version_cmp   = wsp* '<' | '<=' | '!=' | '==' | '>=' | '>' | '~=' | '==='
+    version_cmp   = wsp* '<=' | '<' | '!=' | '===' | '==' | '>=' | '>' | '~='
     version       = wsp* ( letterOrDigit | '-' | '_' | '.' | '*' | '+' | '!' )+
     version_one   = version_cmp version wsp*
     version_many  = version_one (',' version_one)* (',' wsp*)?
@@ -339,7 +339,7 @@ Complete Grammar
 The complete parsley grammar::
 
     wsp           = ' ' | '\t'
-    version_cmp   = wsp* <'<=' | '<' | '!=' | '==' | '>=' | '>' | '~=' | '==='>
+    version_cmp   = wsp* <'<=' | '<' | '!=' | '===' | '==' | '>=' | '>' | '~='>
     version       = wsp* <( letterOrDigit | '-' | '_' | '.' | '*' | '+' | '!' )+>
     version_one   = version_cmp:op version:v wsp* -> (op, v)
     version_many  = version_one:v1 (',' version_one)*:v2 (',' wsp*)? -> [v1] + v2
@@ -529,6 +529,8 @@ History
 - August 2025: The suggested name validation regex was fixed to match the field
   specification (it previously finished with ``$`` instead of ``\Z``,
   incorrectly permitting trailing newlines)
+- December 2025: Ensure ``===`` before ``==`` in grammar, to allow arbitrary
+  equality comparisons to be parsed.
 
 
 References

From d255619f85b966d6fa7e77855a706638d51bf17a Mon Sep 17 00:00:00 2001
From: Gene Wood 
Date: Tue, 2 Dec 2025 13:23:06 -0800
Subject: [PATCH 1064/1072] Update versions of GitHub actions used

This updates the versions of the GitHub actions used to the current major releases.
---
 .../github-actions-ci-cd-sample/publish-to-pypi.yml    | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/source/guides/github-actions-ci-cd-sample/publish-to-pypi.yml b/source/guides/github-actions-ci-cd-sample/publish-to-pypi.yml
index 8813a0392..155f82555 100644
--- a/source/guides/github-actions-ci-cd-sample/publish-to-pypi.yml
+++ b/source/guides/github-actions-ci-cd-sample/publish-to-pypi.yml
@@ -8,11 +8,11 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:
-    - uses: actions/checkout@v4
+    - uses: actions/checkout@v6
       with:
         persist-credentials: false
     - name: Set up Python
-      uses: actions/setup-python@v5
+      uses: actions/setup-python@v6
       with:
         python-version: "3.x"
     - name: Install pypa/build
@@ -24,7 +24,7 @@ jobs:
     - name: Build a binary wheel and a source tarball
       run: python3 -m build
     - name: Store the distribution packages
-      uses: actions/upload-artifact@v4
+      uses: actions/upload-artifact@v5
       with:
         name: python-package-distributions
         path: dist/
@@ -44,7 +44,7 @@ jobs:
 
     steps:
     - name: Download all the dists
-      uses: actions/download-artifact@v4
+      uses: actions/download-artifact@v6
       with:
         name: python-package-distributions
         path: dist/
@@ -66,7 +66,7 @@ jobs:
 
     steps:
     - name: Download all the dists
-      uses: actions/download-artifact@v4
+      uses: actions/download-artifact@v6
       with:
         name: python-package-distributions
         path: dist/

From ad086b91742c9cc22e6db9d490fbb35646dda524 Mon Sep 17 00:00:00 2001
From: Petr Viktorin 
Date: Thu, 11 Dec 2025 16:15:57 +0100
Subject: [PATCH 1065/1072] Add subheading for Build backends for extension
 modules

---
 source/guides/tool-recommendations.rst | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/source/guides/tool-recommendations.rst b/source/guides/tool-recommendations.rst
index 1ba36ed61..bf8d93d5a 100644
--- a/source/guides/tool-recommendations.rst
+++ b/source/guides/tool-recommendations.rst
@@ -109,6 +109,11 @@ Do **not** use :ref:`distutils`, which is deprecated, and has been removed from
 the standard library in Python 3.12, although it still remains available from
 setuptools.
 
+.. _extension-module-tool-recommendations:
+
+Build backends for extension modules
+------------------------------------
+
 For packages with :term:`extension modules `, it is best to use
 a build system with dedicated support for the language the extension is written in,
 for example:

From 3e4b6ec014e6e722e493322b0e755c5b35facf7a Mon Sep 17 00:00:00 2001
From: github-merge-queue
 <118344674+github-merge-queue@users.noreply.github.com>
Date: Mon, 15 Dec 2025 06:12:11 +0000
Subject: [PATCH 1066/1072] Update uv_build version to 0.9.17

---
 source/shared/build-backend-tabs.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/shared/build-backend-tabs.rst b/source/shared/build-backend-tabs.rst
index c732ed2e9..f81423ca1 100644
--- a/source/shared/build-backend-tabs.rst
+++ b/source/shared/build-backend-tabs.rst
@@ -38,5 +38,5 @@
     .. code-block:: toml
 
         [build-system]
-        requires = ["uv_build >= 0.9.11, <0.10.0"]
+        requires = ["uv_build >= 0.9.17, <0.10.0"]
         build-backend = "uv_build"

From 0f6ac8de0005553909725085d90cca807bd50888 Mon Sep 17 00:00:00 2001
From: Henry Schreiner 
Date: Sun, 21 Dec 2025 18:37:01 -0500
Subject: [PATCH 1067/1072] fix: bitbucket org gone

Signed-off-by: Henry Schreiner 
---
 source/glossary.rst | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/source/glossary.rst b/source/glossary.rst
index 630513868..40c041f4c 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -287,8 +287,7 @@ Glossary
         PyPA is a working group that maintains many of the relevant
         projects in Python packaging. They maintain a site at
         :doc:`pypa.io `, host projects on `GitHub
-        `_ and `Bitbucket
-        `_, and discuss issues on the
+        `_, and discuss issues on the
         `distutils-sig mailing list
         `_
 	and `the Python Discourse forum `__.

From ca4013df271d79c79c1424a047805f92e3d8e7ed Mon Sep 17 00:00:00 2001
From: github-merge-queue
 <118344674+github-merge-queue@users.noreply.github.com>
Date: Mon, 22 Dec 2025 06:11:58 +0000
Subject: [PATCH 1068/1072] Update uv_build version to 0.9.18

---
 source/shared/build-backend-tabs.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/shared/build-backend-tabs.rst b/source/shared/build-backend-tabs.rst
index f81423ca1..70f5733d0 100644
--- a/source/shared/build-backend-tabs.rst
+++ b/source/shared/build-backend-tabs.rst
@@ -38,5 +38,5 @@
     .. code-block:: toml
 
         [build-system]
-        requires = ["uv_build >= 0.9.17, <0.10.0"]
+        requires = ["uv_build >= 0.9.18, <0.10.0"]
         build-backend = "uv_build"

From 90034b530d029679155d3c7ce4ba50f8ade19aca Mon Sep 17 00:00:00 2001
From: Henry Schreiner 
Date: Mon, 22 Dec 2025 17:33:14 -0500
Subject: [PATCH 1069/1072] docs: fix links to Travis

Signed-off-by: Henry Schreiner 
---
 source/guides/supporting-multiple-python-versions.rst | 2 +-
 source/guides/supporting-windows-using-appveyor.rst   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/source/guides/supporting-multiple-python-versions.rst b/source/guides/supporting-multiple-python-versions.rst
index 8c128ed91..7e945aa53 100644
--- a/source/guides/supporting-multiple-python-versions.rst
+++ b/source/guides/supporting-multiple-python-versions.rst
@@ -62,7 +62,7 @@ of many continuous-integration systems. There are two hosted services which
 when used in conjunction provide automated testing across Linux, Mac and
 Windows:
 
-  - `Travis CI `_ provides both a Linux and a macOS
+  - `Travis CI `_ provides both a Linux and a macOS
     environment. The Linux environment is Ubuntu 12.04 LTS Server Edition 64 bit
     while the macOS is 10.9.2 at the time of writing.
   - `Appveyor `_ provides a Windows environment
diff --git a/source/guides/supporting-windows-using-appveyor.rst b/source/guides/supporting-windows-using-appveyor.rst
index 0044d8c5e..e884dd976 100644
--- a/source/guides/supporting-windows-using-appveyor.rst
+++ b/source/guides/supporting-windows-using-appveyor.rst
@@ -237,6 +237,6 @@ For reference, the SDK setup support script is listed here:
    :linenos:
 
 .. _Appveyor: https://www.appveyor.com/
-.. _Travis: https://travis-ci.org/
+.. _Travis: https://travis-ci.com/
 .. _GitHub: https://github.com
 .. _Bitbucket: https://bitbucket.org/

From b14f944a186f2b27b0a89f5a710a63cd71461bd5 Mon Sep 17 00:00:00 2001
From: github-merge-queue
 <118344674+github-merge-queue@users.noreply.github.com>
Date: Mon, 5 Jan 2026 06:13:45 +0000
Subject: [PATCH 1070/1072] Update uv_build version to 0.9.21

---
 source/shared/build-backend-tabs.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/shared/build-backend-tabs.rst b/source/shared/build-backend-tabs.rst
index 70f5733d0..64ef0bf2f 100644
--- a/source/shared/build-backend-tabs.rst
+++ b/source/shared/build-backend-tabs.rst
@@ -38,5 +38,5 @@
     .. code-block:: toml
 
         [build-system]
-        requires = ["uv_build >= 0.9.18, <0.10.0"]
+        requires = ["uv_build >= 0.9.21, <0.10.0"]
         build-backend = "uv_build"

From 712f24a877b533bcca4a637f6a1cf165edf4fdc1 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Mon, 5 Jan 2026 18:37:47 +0000
Subject: [PATCH 1071/1072] [pre-commit.ci] pre-commit autoupdate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

updates:
- [github.com/astral-sh/ruff-pre-commit: v0.13.3 → v0.14.10](https://github.com/astral-sh/ruff-pre-commit/compare/v0.13.3...v0.14.10)
---
 .pre-commit-config.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index 615970dda..47b864808 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -37,7 +37,7 @@ repos:
   - id: rst-inline-touching-normal
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.13.3
+  rev: v0.14.10
   hooks:
     - id: ruff
     - id: ruff-format

From 472320a71b654a010eca52359bf3daa159814473 Mon Sep 17 00:00:00 2001
From: github-merge-queue
 <118344674+github-merge-queue@users.noreply.github.com>
Date: Mon, 19 Jan 2026 06:14:20 +0000
Subject: [PATCH 1072/1072] Update uv_build version to 0.9.26

---
 source/shared/build-backend-tabs.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/shared/build-backend-tabs.rst b/source/shared/build-backend-tabs.rst
index 64ef0bf2f..d49d41108 100644
--- a/source/shared/build-backend-tabs.rst
+++ b/source/shared/build-backend-tabs.rst
@@ -38,5 +38,5 @@
     .. code-block:: toml
 
         [build-system]
-        requires = ["uv_build >= 0.9.21, <0.10.0"]
+        requires = ["uv_build >= 0.9.26, <0.10.0"]
         build-backend = "uv_build"

V!YhW$-9&8G4 z&BFgOV8l}-8Q2oqa3pL9r@;Ym6RgI{a^Y6&-=EfrWWzH`F&C9STYvpZ&|i7%Fes;^ zCXC~~rchSCHchFza0l#0`OAJ3Ij?u;=uB5-u8#hZP-Ykp?}O{0bbJI#M`vM2_&V$l z<%rY+17H(485Y1y$Q;!(^YudSz)yzvU+qCDL%~TXE_)e< z!FOOA_$8E;hcDI>r~^Z>Tfx$>qhSwI-yc?>d@Lj`)kG+sxe6tC??8!xa!VvA*_XyB zY>~ZJHb_O9FzfmfD+YzzzA4_N||6=C=>1iE5QCR9FBl8@FXZ(Fb{Tx zTVNabDQpHSvQOfHPSD>NWh6>CdaM(tDKSp<2)BJ$o9`m)ZamVVAv14TLX1UQs{61#sg& z`L^QX=k?uhJ8Xj;fMjzOv0r=2pMfGPzvl(Lf=RGF_7x~wQ09P6wUO`>><%y-h8@KH zus*yG4uPRC7LJ37P`2!{;pb3d>sweFmSMG3WR8_ld=%7&vZrfcCHOon3r|7`#tX0o zd>u;E{|r4aBul9$p%;eWvDe^q?6(f<0s9<5#~u%_z~)DZDcb!7zZDY1kR|g!SMo zSVs0}Gm3Py2fhSP!jW+1DUKq12M&WSvQ0a91ctJLAbbe>yBxjZPDJkGlphvSUg4aM z@>uv1_DZ-I4nMEdoA3+hAHfUHQ|qSSua`Al7xabU0_5nby8q%50*}GT(0ftegg$^v zuvfpLKi~CU<>+F+51E^K_B9=Zy0KBF8+@);Iu1_9-VSBph%a=eYzV7icY|Tj|0qg3lxS129YMtO#%>2$pkMVw5tj^w;*!zEb{pFZrK4oS zG*}XQDU^X%!R~N9d=P#N`@mW^bY^rxIZgXvWvIT^F;E4Tk@MdPMJCV-N{0hsIXD!` zK##$Sa6GI6<6#K&!y|AW>+f@7;#=v44iL*Z1Aj?>9B< z0R1wPJ}712U|0^0g0gZqlwg?%rQOr86nqwn2bMr-w*vNsYoK`YGguCO4W<1pC?5O~ z9%rH@zR@vvO7gEn?X7Qh^f&!Z-+=nSF_eD26OfvRD!}U-m z@;np|95MC>hS#73W$rEfF9UpUD()DD+}0~B52ZfLu!iCNhOG>{81^%K#PA8jNrpbd zXP`_l-EWi?P_|&b;SMM+-fwuw@TlQ&C=)wv_=@4XuoC5;!AN)$O3+sSUgw#na3OYo zSdXpnzk?zj{qO^6n1VlG8~ECPbTIz@qmJ@gKapf;cNv}&{;aQ5OMl^A?5l7-eCt;t z91i|v3cLj0htI$rcbJsL{@4A39M6Cq|I~N5U;aYJUd(6@)9_!)axRTw zmgW3L^l!)*s%Htyxt4e4qaT4i2lj#+p`4Oyus1A#d>~b1Nz3^?As@^6?4m%5WQe9rl2+T;}C??t?GEEMq5?x12lRbeKeW z{|c5G0#CxGuyjQ|;nqUNR}Z0xOQT^Jtj`~2a_rhbnaBX>f$>mQ_CA#8y$&zJZ=uA> zkuW`>7oprI&OmAZji6R3hz*=xNl&{w&C@-9V(&4@Q2p}Cc zh4NkpDD8$qneY@?7tVpwZU<}(55d~-BPiqi2tR=(!!5t_E7s@XdPct*-Zc!Zsy$N? z%8PG9>G&Ev2@8z9ldH1SXF(gDhvJdza0<+Yl6r^nH@pja;8gf(H9rm5`%d@j3G5~$ z_e61Qn8E_U{3crT(;?!D}b6u}n+j4#(^}%$?e}J4!HLH$(FR8BX?<$l9 zT!%B@cTj?GqHQ_9Dfw5RNN&Ffy?Ej>JdWL|zV6^Q98LMpP!iOTh891Y@tKB$;8xg+ z`fs4bNDJ=Pa^8EwC*eN09ELWw)Cjm1PK4h;*5X&go9GE7Hq{MhLW%aW%`E3nu|$}~ z0FlitC$U_Mw45KEmbS2*U(J7qvcjeSOs2$b>K%(qW>o-?^h+g z4uI|99XbEAQN%^F+FH)Fxm-IPwXZ-q=dIgoc7rm}fe`PhQO2I#K~Hcol%LzTLitL5 z)=?*(pP)?a!A?3zT~HR54*fE~RuqYW{jeQ82IaF{0A&RYJL^Q$2Y!Ja3nl3KN9lpz zg>ovshV_`hO(-6!z-*+v78Fl4F!tky6S{K#rJloMuAHp8iLr-KAOv7&2Q?G0fl!0@gc;W(-1zv+~VGxQZYxMH#Vnu;;7 zGIT*{IMr}AoQAy^N@_0ATd%Y+6qj~{P2gZy9ZrKXk!4Uky#}twLpz{+grfWp>H()i zNjze|2p2)wik^KnQ=xRYABra~Kv`L?kPiQX6|p1wTh5KB5tKde2G_u`P$qI4O6vX@ zN|5`*2I!9KLpdfSR&W_c!tw*PM>@e4*iS;ank|Nn;7%z0 zzG3(-Bt`qx$0*{O&!DU@56TO7VKdn1A z2fOM}%lXA*G?cAb3Xi}nD4uc;vz$L-x5E+Gu1AO!w(LdNMb7_Q!!73*iqel-&VOQk zABNMQ+z3m#sjod!cj$-7*sVud&Q)s!Pc41`y(KZW1H zgJbnKWYc4ue+iOXC>vn8$1Ug2>fKOQ7XE}zp`&0t_U}+WBC${EkJMMN6?VsQmh-zn zEPM+4eJGw9I^J^bdIzE8ljbfRloO%E!dw^U|6`O43M3D>-8z`2LOD)bp_Ctkk`FE# zyX6F3-W}GVde@c*a_YrXDJ(wgQcM#N{B7$?$s$jzYOM?@H9c7KD61)MH6{PghOV$MSo4fp#^0 z`jmVD-^Pwh=5)}$bBgxhid4-X;W+BYOw$SJ1UxS1fADnuJuf-KQZLhBDqIHJ&a|BW zhI;|Z`JOgQ-v^pMWvRK?`B0*L%F~v50saalsz8+CAx<}xo|uNC9%zb5^SrW1mmpbmh-=KWI(?Ra0+EQybNU}{Z{B) z9uFm@u7VxlMK~GWfim#Kl{%IBpiFQvl;gSswu47tQy7G@z{;yE^)9>&N5XBHoc|Um zKV|BU8m!hGbcJ$02SGX4!=YS0$3n?$6QE2W5lXwKj6Da+3YS9h$Yv-W*=_7Y#y$?E zpO;n>6rxF9xZzt+R(c)E zLT+Xuy?N8m7m(ti>~JWzI%Zg4M@nbw6QH`NS^OIK{xFK&Z%u%Cmn z*RMc%|3fJ4Za|sH4^TXD2TFe>x9Ew5L3!^UNX+1aKa_Pe0C@Oj8Qo&O`|9!}FJj2P@F^e51Jq04g>;p(7Lk+0AvOQD>9dE~3r($VxU zU4PJM4t7~OxrF{TA}1sX37B?;NHEH7IFxqsNTPWWc>ozq897J2ibzV9hn1`L(pJXb zhm>NV;!k5L|0NB~!!9}Zyw9-C6b16p-{JrT7P5;X0?p(HzbxMnE- zll;>Pc@TL7k>?lWO`}VuljmKe9A)(!OaJpGAcs5ud&Wf5UM?v6(MgIb2_gQR=P78T z9e{O__Yoey^B)8VcIT;y7Y=JxO)_O-R;FB{`5Mr3goX7c_hLMpGQ!3(}t6z8qls2vK3vP zZs_v#F!md;K2j6m?&18$jA_)r;Iz{Jj0IiHdrth{p@6Teb7PSvwb8F2JCJ9vJHZ;f zAm{!kborR@aZ`E7D)by!1LHj+Ei;S5ARyQ5(p+E0UPkS55#D4&2FLjMyMoqthB zQn(!X5|NKf2uwfwD&?P;}Gl8-%wCeoZosJ5h?uCjWcNphG^q1);A5Nie2C~SssSUkIS?X>f zqtN|Ti**`j8m7b9h!1%S;f|>qn|3`7zofh&BF|hTK$|Ye3&ULy*yI8JyG8>ui)CcKXUKQQ$hO!<@Wwkg|acoT+G z-V7Na{{Ian-cg9MVO_-Emj*we45V-_@*1)XDSUz`?_zU>Q&W+sVs+0M{i9-K z^4{a-<&yMW3mJ|*)0D{{s?{lrM0lM1qbkxtGYT3ZQqs|><10csf5r0hYY z1MU03Rg|AcdO;7deRD5AH-NQTI4(1y4eG%AtoKwWO04rmzJSJ<<2TC8kUn zZlcVC$nzKyi5xd|Kf^HOX{qFKA)g>k8K4F70Cm%my~u;u>tGm^$6tegey6~L6h4d4 zuOeqCh(M|%T?#8i=_Ns)22K6IqKSJo4@}lXo=y4-Kcm5 zK8DCM9{CSa3;7h0ry6aSntHdPlpi*FD*7<=3b3kF@bpH0HT7lSw@xXS6BB>xM+#n~ z;%E4gsmy>YjUGeY0`zZ?hmg*C_D*dwbw8oqbu1DNtV{h-V`mw*rky)*onv&!05dhRAalb~U;#;nT^>-%xgvf}N%?9$rK~qx`gKZ_#eC z(Hp=m$aZ8r(gx9w_>reAjazHg`8UNh=!q4DG(dV$wg$@cgog7UsYPvM+TYCnvt>w) zkR)$X=FrR4{l3I_J2^4c7wxgV3AQW7GtCp1m=y0xNU`G+V?3_$k#@Yto#0KFWT(Ws zQ|#zicfur3vYnEM?J0aU#_RJ$rzHAj+S9#pake);-V@_>r+DIK+U|)Hsd5^76OvQh zadDm)JINhA#XZSmPp|DwiA_vRu@gMJAY&xjK2HnNFe>|p0rg9jvEve{aVKXUK3c=? zO}5?9Dc)&xPB-2pGobFdu-|0X;!KbUCntHLy%W9BwkKhl*O!>!EX|z|W6w-XZOmLJ zcx?BCIFF3%jZaGSrPxxLn(QgwnKbs`$?xdtRZ?rqbo0yOtHe`U+W@4hx zBTejRcY@6t>BKBS)|BX@J5kK4Wp=WbI%Wp4b{W1|;li5P-jtShX4C+?tX^JHYD#9( ztcU?EiWcK?CC$Wh2`-m2T}*Ehx@U$bIyFVsV_e|OJ2}=97uPu1cDaW28Zp4-YMDJ^ zX!Y<2Zvyj>G0r_HN)4RoG%Oq_dAc_x zI@V6|B~B&;lVu|kdD%DJOD}OA_q5EcqctkBIyRn2^`$06W#5@RrfjHZMv9Mk>z~rB zrZY8tK-54TWwMo0EPl$2Nf{Sb7-7>qzGR7sV=3VkDmkY`c9_u6`yGPCnX4Ar(jMeV z!IvgR^n!+arlxw5Q<7cd?KtlQpPRGf48r=eUrO6tAuhgHM8>+OdF;d_i9mOp?b7pg zjc;j>H9^SHi*t^Lgta*wES+^vm}!p0Oy|7eOXqD`*^C-J#gmd8r84XFwzFp~y-}fQ zvL`x`KydpeIoob?{>1-ri8}seKcjsfPNM|qz?OD@PlCtCA)op8o=r|oCT}>6c$W?s z%85&}F;1jK^A2Ip#&S+wuIy18uapWkJs;_CuRqeBM8-+{$BPn$At%m807xlKhes=O*2`T+)=-AxdJ!^7>Lz-Eq2%DatY@kPN5W(TVY)@${eE zGP~jSa+bf)p-H4FpNBxgt!D2DvWZ3KJkm)c(vO5It&0M6#6Nb$j>CWW$mMF&at3V* z`=l$MiHa!2D~#kzuw%2^?|3t$=13={IPqLKAdclkc#^aK+Wl_%D(u@tuPp?JIQFyt{6{|K|Ma^%)gPcG0EiVIL>S$6|xa}S=w7gyU;TGmBUS% z`q|6G>B-WawA4w9PeZJi(`XzeesUL0oK}TS)!P-tu<=pskaMC6lQ@>$b(AT4R3AH! zue+P5`DYWiJqb4xor%d_`IPFejoXWIX5qY@ zLnCJfKYGb+F`gt3yPpv4CH2c$C|nF9$N!@%Z}v}DZ`Se4q65pba&z_sHt(}tfir1= z(<}0}&j}pL$ltXf|17T`4=h=5`^=L3^BaQm zmj_m6=WR*TZSpo93Y=Y&w{d=8`TD?;wSmLW=Dn~uurxbx_DCReY1_bwqq-Mb{G+3^ zCAlY;7Hm$-e{N2}!ll8rhjp{tXEtVk`0I_5am)8p6P&wG-rKM-xOiLMvaG<)dHFkE z2%b+19?M}e&e{$i$vv}?QHwg){RGkv=V$H7%QzJ{v{ApAd-5Rf&|~26ks^=i0oJ)o zS@+bWK_Kf)V8NciswKH+&*!b)SJY?r(LbwNemp3z-E~r^b(rcfkX4YPMfQ(;;Upm!9|OTm*k$z9L9|3nEX+6DPX2zI+p_0 z6wKJ0zhg;o?Lzh|xcVGRVN7|&xf~y z7A}5i2yTC3Vc`5armOEVq(wzl6P7%SfkDQPN$8&Sm2G^eAaO6Fg z!$xcO72gNO3oPF+`*?l@zNXXT_gSUNj@I!|uwi~+(e}WiZTa)gDpqWI+_HzWqFYEQ zhTfyUi}EtkgPRWom+cLtAJ5Cq$;;W6e|{7Fue+zdHLARhVyDT83H7bs<$F1ih$o9r z?e75B=l!3Dm;KH^^n5UVWp2&^=8!q~!-h3D><9H6Y*(?1N#JzmiM1`PtkNNP>O|l6 zR;N<_%^A6;Hx=zeaB~LXR*;s#6l_<)&Mkr6YxSz_uKJcDse~bMpgwB_X&dv;FO(Cs z_&{L!2?h=>S;*Pc@6t`~$<6tD&Ih;b39MX{pOxXNMg3BZ| z>O`QULA>Jh#_^Q>K6N~A?_rK{?#a^xmwXFL5ZOKZS#3-Cbwj#mF2x7uJ$8^2SiEDM zE9p-M51*=pY2u~7!}8!R=3?Sl2Y(xx0c9r_7i`(dk^(Ew=H~1c|1DZ%yXx`nbZ$4n z)u;6I{&Byd?{$d}Ti^PfSSZ*@l3p1&$)eJWU1~T-I{fIpXoqF~Stp8}D1EO9ZZAAa zWM{oS!Odx8Z{Ec>`eIYmThYBHgmZFY)F3M_q>k=VAB>{Wcv~Os6J3W{9m@N4v;=ph z1-BUo%3o!2v&-MRt6<@xzy`^LdUx5>yd8(~5ADX&II8$2;3e_ip?QJRtN9v8#I0Cq zw$Nqk-M~dk-Yon^%FIs8eB8=z;sofOF2 zPkNmWZe^Nv?*!-6FrIUl$<4_mW5}U#qRdQ9yIkk^ p!Z_e2vIzeMGtx*PvVrHe^@HU8_6r?W!>mr@1IGb}|C7?T+nha2-u zGl35c9dbnX?`0fH9Z^2e|r?&heO#`e|UasSW3F<>EKq%U`u`gW zD=5Tb#|p-D#T)nv>s2&n8P=&p>p9?UypNGpj2TCLnrg=MBwv6H$rIKv<_$K%ma?WX zUcZDVMwX;Yi~&mb^!sAzzza1{QH9McS_W6U489hY;UMRkq2Ltd`F zJy0HYN=;r1w__WujN$LuThtius~&X=>e9*)*bF(8In^*=50IJWWul^pvp)Vt-W|iS zX0$O8*b;S%K0saJ1k~8Lj2fgj@d7@=5d5*RUH=nmzh5x}K5!-uG@;w6$bpG*ENX+P zm=RZ@PP_*-jV@pte1PFtucb=^m{wg88uqCdB^O7YAW_&Hrl@ zhEVYW$Kk+Mjn` z5BPHbPg7XSimSK@C$}?ZFP3RSBY}e5k#-mBwiSdG+@izW| zlW==ydz^}0Yy;}zAnIFTWPrkP3h&}$)D`Dr4vwY=isEYWtugirTXy5>sqcW=?&|x- za2L!Sr0u2(XP?6QrKrIc)zg^XSRNT~<_jE%FEO0$`t_p!)g@!tYAVh|?U1>Ty_b`5 z6&t?C4bwe;)Q@h&!~MChSe*V(f-$Hu(jV26qi_r6;cObT=TSX-A2qg?(v3RK?hm;C zsVU^AKSHr0YJ=LS`fgYbhhr4(KppT3=D{bJ9kUF!qq!p1Chvl2Y4`?QO1_@~b{{)^ zXv{EdG}L}reLs}`*StMPg|6Tl_GZVwP*>J|xG~wV2UehdGKP~M8DSq#7m!hGvW&D1 zEP)xxJD`p`40W7XEQK?%7Ji30FlFE)?l*;Es6o>P`OnlCWv}!AhLB&t1~Rm8d?gu7E=d%;C`Hg1;^Ni2KG@{N5wB#4`as~GagSNjWo^2 z*}-%M6O-RS_0$7Qfv>O_CSxaEab?tr>!TXp9ur}VvyWRp7?W!LPo%)OFmo{nCW^Jw zBnmT=mqrb?W~dWPKpk*4sv(PTt7pvTsIF}@(XL;K>iYG#3wK~~95Bhc1~YMfbCH5h z{M4_YTPCw32P}b_9hIlpE^mmDrn^TgTeR1=asA^jgsq2(eTKDZ9q*W5;3 z>F7_5`4Xq$3oN&oZsdTame`)DztrBM4fq-Bk77UUwTz3vi^#Y%k;^sIxpmkd3$U?z zVsU_it}O2g+rr^kg8VwFi!-gXPsU1kp1cmG!knu(2$n!Sa5|x;+X!rrV^O!{s`DXg zP`*J;&qS;3tP5nMpnEk9wZn1@#Z4HDJFyV%#iV!-WAHh)!;WhhbRL5dKP2D3)(+0H zpEIDzo8xKB`2}Nz?f${LYfUmG5s)5D14|)#NM)klj z)F7RPc`zO|D=uL|e2%5@HI~6ro9r|nfSN6HFqLk~Vha1H*o4in|7QEPdKmS&<0cH8~cR2i#p!gJ$7*AWhZ*u zY{fI!cAqiRvB*uj_fJ3IXbVIJytppN$&et=Vs+E=&NM``aqx}-n-!^|;7kJ)#&lUOwY z_a8ZzseHoT+mMs?%5q{F>NjFq+>g5V=Ux67!^o4IvSTY9hLUGRjjepBSyS^A{S`_B zI#Q9Gik_!w1P();U_GkE`>+TWryp}+43@>oSOpKFMt{gp_Qazw1NjtG16N`S+=<2U zsH=Y+pg?b!G(YpW#Y@;4_nx&q5pm8w!)sv(^&K!6yE%JfV)B8Q6i1-0e3Dx~*X4^) z7q|xX9N3QPk-#^u;)ts_fjZCy=M4-Ze}p>mzgQ7pV|A=>-afL&Vjc3s*bGx%u&?Re zP-EajR701d8n6~QUchXkkc5ius1xnOWOxX}@eFD{Uq{W7+n5?_{$g)YYt)tWL+w8d z=i(^LfvGRr6PG~sU`3qCEw6z|HDAvDYB#usYRFxj%?3|VT{h*C-Ekr2BwvoYmj_Ti zb;fxG)sTCrD}9POp1zZ-VPUATkP@|B9t;jpC_+J3SQ52iS*(GTP+b*^I?!~~Em(l+ zp{2NkhHgL&sxDXUpj?0%$2ibCyNjf~wAXn2@}wv!%1`9|60fBNb{$S7$%xaMT!x#ez5&H7LJDJxI>rMEnbL zcnrSl_Bfy3;F(Xp28-c=H?Hf?3yBv&s9FE7q_l(($ z&#?!tzt39_rhUMV3-}R!g!LZsoZv)9aW7uwAakhy>=B=Q4OVUqK7>gNjlk+=N&s{}L$K}TJ zr`Kl8O@0_-@K4kQM0=h;NZaE<@}8Jb^S^Kc&wntyi>X*q7PUhIm$%0Di;Q8~p9JZrkC3ZtEBZGcWx~wSzYes>f<$6gIb>9qE}&;lV0rTH#qIf47ia$Kfv}N^t@st{7W67%U5+~7 z&zJ-6p{^`NN#uZ0n2fv{A93k08g;L`<2)RXYDh$B`{>Pq8Y^W{$8AtLU`Kxp720sP z+hB}yu5&F`Wc@DG6+FX&Sh9@mkuF$>d=jc5J1`Iah&t|L=L^&mHbGh2Ga&&AYDp^8 z4*4-ZMq@4NBD{>O*Io%NL`1FdnsC z;1mVT*Gs5J=0hBXqxiW~52RPv9NSd%{GVpFVhQpms9RF7l6`Kxhw33y+4H}wR>G#F zZ!j&ls%aI^|0%a;RnPxjU=5bk{2y42d%^}^U?+CiUELlqYYor;>U9$JVp6@P?fPjr zjr=I;3YypQ%uMWpr|~h~!y~orGk<#>J0=p>^~^%*b7LRegVi+u3)Zt0{ZY^SOV|@z z)c5>97VSs%M8yW4|EjeZ^?ZnU&mOoL>edXvb2t<={~I;5W27T$mP|+0uS8ArIOUrE zSsK|Dg-{2ofV%h9Q7!F`dhI@oI>0m3y$+4`{O<#)QS&(?Cc|pj2BT4r@QrvA!y9}4 z*Y;A`64N(VbforfY zHo>%Q>{#i68gxJ4Lrl`v^IuY5;0NRt+wth-g0`Y=;hpw&cGd3Snf>G+bYT8Zr%;V&CaDqaG|Ny4uhE)!3W7ZH#BW#iKX_r*`v997eovr|WUt zO+K!>XU1aX9(E8P2vAs0MWddc`59m0$9TGzJz(eFp8tzw?ml*uKSrG>wy)>^Fj=dg z?YSq|m-@o}?W@{S976sEb&H1#uy0K12HFcbj8&))M1Ei&Jny3(!81??sxrvF>uts_ z>5-g+J^v?~Q$y@M?f)U8KLLM)#&6hu=P>&r^WkvM|J7?frlG#n2s_y7qaMwjT|Nr= zYzUaS6cVvwIcijYj#+Rk>PdAHHOTH@ay&iK)BlrTuA)v5{*mYZ^pXejkS|4jNF72w zA@3j$8k2dHoz_iIA4+>LgXaJD6f_;Kp+CK_IC&^zL({4v>I%E#Nz60azHC0lLgWp` z*hlOL)c$iZ7+0aD^E%YK;1<*aYZs~kN6`QNf5uf@KwaT=RF6DH^~g(?hm5s(a@2t` zI3qELycp`lrBJh?0#?V7SPj3$Iv708UO+<(=<|Lx140G(o73(^RPXNUV=hs9Q6{ITdvw%TWzohf{IWc;L7`DD9Y5Z0tV6xCCWP{(PB+P(|wQQQM*r~jqoJJiyOC`08>N*I6s zvVwn;X-l{80P~mZOtHL_lcOHF`hd~{ss*ZtBBFgxqA5r>Ebgq91K zo47&w3t}JTz{mXaJIP=Lju#F&Yc|nf*C6 zFXenhl&gEoehNK_OGFkLI2(ENn^X7zR}#U5meClv>JnSUmjd!1NIpY78{RG&-6aS< zfBc_a?zt6_u>Cew)+;C8rA z`6oilulSWKS0JxMIUcVO1v#h|J`Vil5^Aph>vC1rA&P4sA`LN@;3;o%>i*YYWnq%H zOCDFw|DQUo)4bMlj<`s4BgPR82ty;b{Ac?jRJB$;ONeWr%DfnvF!DsiHf`_5pW&U; zUt02SR?2DEpoXi{3SL(IKP;*|UH`Bgv6%U+`^Ig%-PP%wYl!(S*IQE@+nmK=#2{@? z1g2s=;vaW_os>^gK7e|K`h-Zy(OOftoN_kGT`AY5{B}7^zL#VzeuQ7(LQGFgq#kw~jcX1PtY zA^!(cyX{s{eur{Gg7+Bze|VsZh4b^m<1f$ncQx@PQH_{PXzAzHpF%!C%~OK6H2(uA z7j|TuZG^stY1vKP8{+Nqt}7p-VgWIaDCkyZ)AbJ|rV#JD4GZ8N;~ZTbK<&NUmph&9};WXW*NTYwuOM1K}9KI3h^s7 ziE%aY0})JX6A-;A?j&!lVl;v6RC+!#M@;Wg?ViFcBxG{iR(hu6(diE9no|3b;H;nze_BAonhqB>?D=zmMpG$?sAA z*lpXNaw=EuifLSVSKPfK2_xdR*GnB7H!`}q7q_EHnpAPo-R6hJ9qS(*I;ZgPtaGLf zkB)mjJSb`0f{C9bos+tH*0^1Be@_}$aK*9UxFw&5cyXE5ok|#&_{$Svaou-ii;Amu z{qL;te+7BxgW`K6@sfM-wUT)?dJW?@ z74^!7#Sf|AeU>ObqJ~#GIQ~*y??_mD{uW;0;Q6oGdbi?xxA%Te7~iL}S0XGvqOZ3r MUwrQcUcKP|0kDPG7XSbN diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po index cc8332b72..4a101980f 100644 --- a/locales/zh_Hans/LC_MESSAGES/messages.po +++ b/locales/zh_Hans/LC_MESSAGES/messages.po @@ -11,8 +11,8 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-09-01 20:29+0000\n" -"Last-Translator: xlivevil \n" +"PO-Revision-Date: 2021-09-05 14:34+0000\n" +"Last-Translator: meowmeowmeowcat \n" "Language-Team: Chinese (Simplified) \n" "Language: zh_Hans\n" @@ -117,8 +117,8 @@ msgid "" "specific topic without a specific goal in mind. :doc:`example discussion-" "style document `." msgstr "" -"讨论 (Discussions) 的重点是理解和信息。这些探索一个特定的主题，没有具体的目" -"标。 :doc:`示例讨论式文件 `。" +"讨论 (Discussions) 的重点是理解和信息。这些探索一个特定的主题，没有具体的目标。 :doc:`示例讨论式文件 `。" #: ../source/contribute.rst:63 msgid "Specifications" @@ -161,8 +161,8 @@ msgid "" "the `Hitchhiker's Guide to Python installation instructions`_ to install " "Python 3.6 on your operating system." msgstr "" -"Python 3.6。我们的构建脚本只为 Python 3.6 而设计。请参阅 `Hitchhiker's Guide " -"to Python installation instructions`_ 以在你的操作系统上安装Python 3.6。" +"Python 3.6。我们的构建脚本只为 Python 3.6 而设计。请参阅 `Hitchhiker's Guide to Python " +"installation instructions`_ 以在你您的操作系统上安装Python 3.6。" #: ../source/contribute.rst:91 msgid "" @@ -4105,12 +4105,14 @@ msgid "" "venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the " "below commands." msgstr "" +"要创建一个虚拟环境，进入您的项目目录并运行 venv 。如果您正在使用 Python2，在下面的命令中把 ``venv`` 改为 " +"``virtualenv`` 。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 msgid "" "The second argument is the location to create the virtual environment. " "Generally, you can just create this in your project and call it ``env``." -msgstr "" +msgstr "第二个参数是创建虚拟环境的位置。一般来说，您可以直接在您的项目中创建它，并称之为 ``env`` 。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 msgid "venv will create a virtual Python installation in the ``env`` folder." @@ -4133,19 +4135,21 @@ msgid "" "will put the virtual environment-specific ``python`` and ``pip`` executables " "into your shell's ``PATH``." msgstr "" +"在您开始安装或使用虚拟环境中的软件包之前，你需要 *激活* 它。激活虚拟环境将把虚拟环境专用的 ``python`` 和 ``pip`` " +"可执行文件放入你的 shell 的 ``PATH`` 。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 msgid "" "You can confirm you're in the virtual environment by checking the location " "of your Python interpreter, it should point to the ``env`` directory." -msgstr "" +msgstr "您可以通过检查您的 Python 解释器的位置来确认您在虚拟环境中，它应该指向 ``env`` 目录。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 msgid "" "As long as your virtual environment is activated pip will install packages " "into that specific environment and you'll be able to import and use packages " "in your Python application." -msgstr "" +msgstr "只要您的虚拟环境被激活，pip 就会将软件包安装到该特定环境中，您就可以在您的 Python 应用程序中导入和使用软件包。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 msgid "Leaving the virtual environment" @@ -4155,7 +4159,7 @@ msgstr "离开虚拟环境" msgid "" "If you want to switch projects or otherwise leave your virtual environment, " "simply run:" -msgstr "" +msgstr "如果您想切换项目或以其他方式离开你的虚拟环境，只需运行：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 msgid "" @@ -4173,15 +4177,17 @@ msgid "" "Now that you're in your virtual environment you can install packages. Let's " "install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" msgstr "" +"现在您在您的虚拟环境中，您可以安装软件包。让我们从 :term:`Python Package Index (PyPI)` 中安装 `Requests`" +"_ 库：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 msgid "" "pip should download requests and all of its dependencies and install them:" -msgstr "" +msgstr "pip应该下载 request 及其所有的依赖项并安装它们：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 msgid "Installing specific versions" -msgstr "" +msgstr "安装特定版本" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 msgid "" @@ -4189,32 +4195,34 @@ msgid "" "`version specifiers `. For example, to install a specific " "version of ``requests``:" msgstr "" +"pip 允许您使用 :term:`版本指定器 `来指定安装哪个版本的软件包。例如，要安装一个特定版本的 " +"``requests``：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 msgid "To install the latest ``2.x`` release of requests:" -msgstr "" +msgstr "要安装最新的 ``2.x`` 版本的 requests：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 msgid "To install pre-release versions of packages, use the ``--pre`` flag:" -msgstr "" +msgstr "要安装预发布（pre-release）版本的软件包，请使用 ``--pre`` 标志：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 msgid "Installing extras" -msgstr "" +msgstr "安装附加功能" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 msgid "" "Some packages have optional `extras`_. You can tell pip to install these by " "specifying the extra in brackets:" -msgstr "" +msgstr "有些软件包有可选的 `额外功能 `_ 。你可以通过在括号中指定额外的东西来告诉 pip 安装这些东西：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 msgid "Installing from source" -msgstr "" +msgstr "从源文件安装" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 msgid "pip can install a package directly from source, for example:" -msgstr "" +msgstr "pip 可以直接从源代码安装一个软件包，例如：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 msgid "" @@ -4222,22 +4230,24 @@ msgid "" "meaning that changes to the source directory will immediately affect the " "installed package without needing to re-install:" msgstr "" +"此外，pip 可以在 `开发模式 `_ " +"下从源码安装软件包，这意味着源码目录的变化将立即影响已安装的软件包，而不需要重新安装：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 msgid "Installing from version control systems" -msgstr "" +msgstr "从版本控制系统进行安装" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 msgid "" "pip can install packages directly from their version control system. For " "example, you can install directly from a git repository:" -msgstr "" +msgstr "pip 可以直接从他们的版本控制系统中安装软件包。例如，你可以直接从 git 仓库中安装：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 msgid "" "For more information on supported version control systems and syntax, see " "pip's documentation on :ref:`VCS Support `." -msgstr "" +msgstr "关于支持的版本控制系统和语法的更多信息，请参见 pip 的文档：:ref:`VCS Support ` 。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 #: ../source/tutorials/installing-packages.rst:569 @@ -4266,13 +4276,14 @@ msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 msgid "Using other package indexes" -msgstr "" +msgstr "使用其他软件包的索引" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 msgid "" "If you want to download packages from a different index than the :term:" "`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" msgstr "" +"如果您想从不同的索引下载软件包，而不是 :term:`Python 软件包索引（PyPI）` ，您可以使用 ``--index-url`` 标志：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 msgid "" From 119812edecb83a85ad243decabca31fdd8872450 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Sun, 5 Sep 2021 16:34:37 +0200 Subject: [PATCH 0134/1072] Translated using Weblate (Ukrainian) Currently translated at 20.7% (471 of 2271 strings) Co-authored-by: Sviatoslav Sydorenko Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/uk/ Translation: pypa/packaging.python.org --- locales/uk/LC_MESSAGES/messages.mo | Bin 63748 -> 64293 bytes locales/uk/LC_MESSAGES/messages.po | 16 +++++++++------- 2 files changed, 9 insertions(+), 7 deletions(-) diff --git a/locales/uk/LC_MESSAGES/messages.mo b/locales/uk/LC_MESSAGES/messages.mo index f930fae16986974a6a2e6c758ce6a6e9a3a60639..3ac0998d5ec6f27c3ad13dab3437ba070221027f 100644 GIT binary patch delta 10222 zcmciHhhLV}|HttQL2-+?Z~~^d!M*q1Ggn#yih?4bpopfoxpI$C(bAle14~8RI5JDq z@hN2=$jxBk}+lET>Qv$ElC?(Ur&<^-Dmc`4s1fOGFrfYFkbK&D0bf4UffwUj3;W%8&xnj*9>^P;# z>!I3v**qRyji^{eL7v1H=*ff^l{L*=`C&KmDtHwWu{;j0Wk$$_y3^UHkyvH@*t*l2 zi4nA)z}y&IoB7vVH>hpqyp6R7=AwQOYH@|*J&d*WZ`E;}Qsfah0H>nPa{)Dl*Dw+9 zqJ}=At~uW{RQnwC!zFbY|4<5Bs8Emc)iVu6u_Sp7%!3_J7wm<_Fd7TvG%SuwQFp!- z)sfv;06)WG=(hQF>qBb}7b~GCJNTgHxFYHVZBQrZVe>cfEO`_b!KMuy=X30dIk8wn z$BDtxsK;zBs^jZXHcX2%z027~K^NMM@34w9O@q^-DJz!xjyM>n;9S~& zLfzT$=1c*397dB*Yhgy{4;)SYSxeLLnyt(lX@VNLr5K2tFc0g``N}qYi|XM`48X@& z0sUGtydI9z3_m3A)5a{y2i6y;4&`raEN%_3R<+i(Hpge|-x2e1eWz_ZGh{t6nhU*! z8uC-^%_93AwQ6so=Jr08#M~XsS}Bj(KNx+mk`&vU$Q!&b#fG$-`rl32Rg}HDs z7NjF7=tZ8|(Q#hGt*HDA>Vn@Q9~I6os5$@5dLPxn=cvcmuamJNZXvIYzW8$|#y>ZO z`&8%zPq7escQ&iE1nOz1kLp-!^u|tD9DCV35_O?C)D%v(_485ZU5c9f^|pRDRvGn^%n6#Jj_-jvaTIDq$Dlt> z#De&~b+dIZ>ILTdl7fclf^E2gzmY#e4gH0lX0ETHdVU{+@Cj-T{d<`=W^Gj71$E-L zun@+fMr10s!9BPZpJ8vV@2ukIK`Q>hVVKs3yJztge%%}x)0b(W{v(`+^ZPOH=-1!8 zA4Z}&x)u{K4L`xa0gMvoapOAjYXey~`0g9o7k0AHOV59WL1yl%;1BFj2X!a;2Qwv{ zz#lb)jovhNM2$p$n-4+FeGF`X zd5)e~YB=N1Yu+hGp%M1SKwN@aMCqs#9YjXoIfL!7;t2C}M590XVl0o_u>qdL7ML&6 zoUaSkA|H)9ehu;Xn?xI zA*eMl7xUtB>pEMXX7jx^KZZW+cP5(g*MXO*D28|J4mn1fAufn{s4tHCm=3_)SPykv zb1aLUQ9~PvTJIkwU>eqL$MtB1ZxWV==tAGL5uB6)CKOL?(iY1120f_ z*8D=yT2OHo6ficN7h2I5~>jq5wb63qAhR#=35G-?Fi zL3LmrssoEL7p}DVT2x0jqvm=S>O#j*Lw*i*p3A7?Z=v@83w7S-=+Yf{jx%%Zjp}h( z)JTM&cC3dwu(7RghXu&H;5AnBKZ6! zzXpXbspx}$V=#7_Xr9jr$Rcs(SeIB=q89Bsn{Tsbpl&D=)#0Po)7JCW->i2hGXC1} ziLLOQWb%U6lGX~=5LAa6TU(=swzIVlssn?qq1Iuj>qJ`Pty5eSH0N`$BCbX)#$(tR zZ=o+%eA^6NL##&L0X0?es8v1_`{D-t4xi#(hW^ZCbKy*G^d67R3Dn}-GtK;t=(=DF zIi{O8ST)oR9c&(jjmT$O592IO{1nyUsWW*3Fcr6=8&}f)_AK+tEL;8t#_=?k>%j{Ea!IxOu?dYReu`e$jh%{J+R7?QHyQx8qQ1pHeMp1w~kLnMr7oAUR>lkH@eJ;Z*S!F zN=1&3%&JaCP02p=!@p5;T9B1g1{-2c?2Gkr7XHDBGw}uawoPUvwrw^Zwq{wcSpRlW z&|G_OF_yN5-~~?D2DNI-rkQU%Rd678)C>Ko-};Fe%2TKp(`9UkH&O48z)#KbgHcl* zX-&dnN8^ePV=>T66PoW220~lsP@OG z3;xIIo6bVz`c7pEx?r4j2KM33SD@zn&MvdKJTuH=QxJ9H>R1muVo98Wxo`z)B-UU{ z{20}to2dQ%#>!Y|x6aS}H>98r^gunALs2Jq2W#RS48i@@TezMMmfB zm)vJQ4SS=`yAF$E2A0Cp$elYka6i{~LiU@l#ka5sC$4qC^tjzY^TOzj!R$8@YvW2B zi>GlYw#YPJJT_n#@;|XZHsdu~2bW=eJc+*O95zo|5p?w>FHfNuPOvVtZp0eY??*qp zY4tc_{!md0gQ$P^sF|Wq(1&~@n_^{PyRJ68X&Ij*@HN_d ze9sq6@_5vujQzp9dgr0m&^9cC8K|e{ENV?$#DaL=Md2!i7s$;zS1<4kbHYt@lfF1} zF0#_e2mQ=^lF#Nf)|LDVoPtFza}s>-SAK)S=~v8!f8(T@id(3!XwR@Z`LEacZ3zqB zFdt&B7z(|pNX2k`f{k&|P4hS{$Cl))u?b$n3RvoQ^I~a%y2CDb5+kua*1ly%C<*<^ zS7Uk1#0Gd7Tj=@syKRPS0M?>mBI*Qb*bV=}0Bm)~yrRRgmFh7F>)qw9SPO$utG)Ss z)4{P=i97|X;$h5(w=ge0%9i=}_|r7xM>Y7_{5A9;53zYm)Kk*c=Hci~9)o#sJQl^N zm>ZX&F8Cpq#Vx2cassvJuVPiM?>w{>{twInA?U#!HNpI}H+yL6JEIm&KP-$9)R@EGa_E~1WqfG(ZT>u>u)KpjvX)x-Lz6Sha)Ne|mT2=D1v_`odTMOCawb=Q5$~BPDEGu$l++zsFY8$8;Lr#_oik-Mv_o z(7XLzLR%H9ehJYQi@IZVTH9?y_Rs75+-mn*O1ZWzt8oLdk?T86ZRKGqG{;+swYF}m zRlm__3&*wDCG(>#q*AvMOJOr&F=ZYEXBFlD-TbNBL1j1*qQ>N$WsA5vQ=4Y@o=D|L zf@k0PfVy5pAIh;r95IYsf7Wb5oFgBH6YwGNI_2G12pbZ0DQg>SaK6Am;s%jIyEZ;t zT+R@Zk+$MDD&HpFCE62O99sx&ykecI>=%#v3Z#t>rtB?@{17Gmc}q)MTVG-u`A?|t z-P*M3wA~^?RnQ!0o6QcZY6EuJXWHikcu|9HB3=gNV;5C!n@Es3%05{sT)}2P}>H@{*8U!y}s9%)f-I3^fA?y)|kP zJ&0iPGj=b18PL`Pzcj_{|N5Lp{u#UJh?Z=0kEBi|%pAF7B)vz@n^o`Y< zs7Co6{1XpjXRLs)Zc9k&*b4n;q_*+a12~CjMBQ1!gYq@>#nJe~tLui`=|;nwgtiGd z(3VXNFDD8O2_IXZjBQ>vTFX=SCS|@FWN%%p;#1l#;c#q3?04~FG!a6Sq9KfkBzlv- zhkp2Sn@wR5aoSeg!+Eq9v$=>O?~gNZ4e^z28%4PyvEAm!(T~VpxBY0)*52A0o06vx zT_``o{}9V;`wmPd55O4WCgoz-6HgE)iRFa0xx_-+p5aVPA|fc4A=vD5L*>h@fGsqp zZt<)2lyeYo5Wld`9AX>M&hGPpJx+W=-G?@Bg}$mIMo{mA&xrv<_Vt@nxr>-iI)kW9 zY$ESOyt=g|ANoq&RonO;b>%4^LQkA(>#O5Z>V8E}e7TjST#l%zisX6~3x$P}Ws>Z} zop^`%h)5+qCSDNQR?|M0s7q)of$_GiJU`_kFWbo5P|hHJ)aQ==c;`$fTS2(ek5}~b zb%ljTM+789Mg)YmjvCQxT*TOmOY#^?k!M#jg+*uAua_G}(HWJs{nE@o(0 zT>QA`u!M+V0qsVN2pFDzx4{dK0uc!bQ86O|;v*6Q#>J)IYUEY0eAxJ?5$qO_5c@y9 zONV$#W}pO+S{D zTGF+_y_1TA?)~n}tmRqLvgZH4+^&0;JCjRpcc+g@PW1G1ucmmwy*+C-J(%v^NtQ`} z7Ny@)sat+ub{;m>R(Obj7_{Gt+DA%2h78{n?=Owr8v5%%ic&-Z6dr I`GtZ11*zyCx&QzG delta 9770 zcmZwM2Xs}%+Q#uoBeVn(S||YmBuMWqAT5aW-a$pWG?6OJ11KE=8j6S%X(C(!2|dz+ zC}JVuA_`s+QMo7rUPQ1V-~Y+Hxr_C!yVrX8%{#Nt?AbH3_c_4kyCE;#4hdX}4qfgz z4hK0`0z)I6n-uKaPsLU1+^Klys^N#&6@SN)*gnCzH8>LUV(#+J<-sDTe#&AYY>GO+ z2NuBzm>(BoxN`xw))(9sa|f!UeU_)2r!j>3vzQyto8Oo}nfJ`#NBnsaW{g?ZteR!O zxdv9z0>kOJquCR4l0Rh*Lk-|LbAmY;HK6I{JTnCgP`?&6BfF8wa%ZqE-o$`na|9EbN%9gbil z4a3Q(0bD^{@Ve!y24TY&xW7%pH}$2RhJwDnP@oP0Nqr2W0d zenx6Eac&fOXj4DnvDk}zI%=lQqjvp|sF}&z%-0vjNUrZHQYcMB11yJquuu?FgKNo` zH}{*cc9ORls-q5OFLQu7(wu0{z&|;E0ct7dwD2?a3XTkLq4g9r)e$ZIriwxB(u$}x zt%*gk4XT4dsPo659?z+kFEUq}8&FH|wzcR|NBs$G2ww_2p293f);Z)PVY9 zI1a_a_^jn~P!~$Jd^Ku78&PZhj@6&Ua^#<2S-fo)ZsXh`@=n~FQAkw3r$4DaLzP!(gyn_1om)$u6IhXK@#EI~H7dmqmy(e!@I{F&l zAiu*y&oa9ez5RtRqc(G`K7Q%y;}_)3Q8Qb-FG~`{`d6h8NkyxE-kzwL7-IQo)Y?x+ zP32tFCR~n#aRWYqIr$@m0S&=P;ap z=pzcuy1RrevGx%EcuYlYvUOMnk77N%f=#g4P~Tx6tU*2vTjCC6Kf7PCG$svW1LGiU zh9@uq!=B;!KNiH-=`*Yo6*q?a=QeJHe+pWn?r=2b!Bwcuy4l=i^=X!WVEI|h&v}JCy+9lV8+m}Z_voqqu} zz#FLk?xO~l<5}MxjkU=WQ2hn^Qb?lk9BRaSQ3FV~{1Xf#zi3`Yb$k`I$!?)O_lvc= zG5-7<7*2g&)YDVY@{*P(U?|sj)hVc>I;aaZz+h~Gjj=hlz?rClzK?p&b3f;orWN-m?l*!Q=g#F9LM~(Wtd9j2dud)J!zS0Bhh{P|yckTSGUDAn$|Uvzv!u2l5UR z{ZFkms3pk5Ypy8m-LWwFv(Nj1&cUYS%drZc$F3MU+0RTb)Y43u%=~MUETlrFn5$8{ zcBADx&Hbo5I*JZpP2> zPrSj@XHN4MKKcTGL*lVHjoN$%XZpVberblz@-MI|sP@*D2S!k6K*e11IL-;;0;mzs zdWkO*+=|=rEUu#ch1vd<9W&Ptyd9RJy)WvHra*~9@ibDsY|vbn+B zhk6=Lqjq~He#V6_S^b^`{(X>!TWEiP+A~`g`U~yG>*R;AI=;2YZ@P=9r|CNC@1O1u z3e1|Tyx4zmJL+3*A6CYjs3j<#?4R!js2Q1vRdGF*!!uX}@1V}lyTmVTMQlj^C`RC9 z)C|p)dj3~asD(SRHhzmaF=nYBaUAOLs)=Knfz}vD{_e|6vt|UPflq<8ecT8qu%jae=%AlT(DoDQp z*Oo#ZDu!ZFT!Y$t`%yD+1e@afsDXy>@#hspbzBt-;A5zcd!s%#39DlOtKly5GHzgC z`S+@x^-taBU%B6+raIq#|83U_)$vNyg|=fcOh?`ES9l2H5BOibm$3jHmp|wS+K|Q~ zw70^l*dJ@+5*&-^IFReRI%)og#VTw|{%`Dwwchpbg@ss`{3z=2xr>pQ>#%=XVo+;8 z+I-1;4XaSU3uEw-c@IZw26zt#5@?uy)UVAZ%ul`(TjMb-hPjXV4&qS*XpB+V8TH;6 zh`OV3n1WYv2p5=gobL+qZ_=4+@~J2I=Nt0v@3CC$wI@$9{{yMm^Z^Z=knfh$mtODbwl97ZicCSJkI$j!MEpHrs4 zxnIymK8(>;CQtm5_dog2fAIN ze(XE`K^kvhJ#5cwuQSfZ0r)v4V&YZ*6ivXU#L`JLbVa$$$Ghtcc9IdmLM0 z)HOdvy|5JdG%SO!qb__Do8Uc+!+JmXzXSG0eSRUf$Fo=(OaJI!$<45t>M=pjf5Gc) zkYGlKwP=XF=||WZ%ac#Uintav;tw%5er8^_`s_)#111ZPfWezxV+bLiHDq8dy~< zfQeWeJD~pk*}X`iEgnRTIP8ueKr||k#W1XBR!4PQ7elZK>bxXt?_~DCaO(S^W_Xb0 zqb;9!hxresVFnfIXg2CX^N|^JORzD%f-Nu;ld$lw{sq+swKSWsAf{tU{M@{YdWs6& z_1`fGsQ&w*W_Z9|=3fICMTPEYEJov0tcA&_fu)=8qjvRa)CFVi`K73W+7nH%5q3m9 z6^pPE?l3Q+_E3)B{EUqXtj|b6}$7%}^t4gIeqEs0$53P5F4#)XqeGej)1o zWvG7Fp>ALkmcp&5y>kjR6M>5qbmC>y2fw$5pD}{`E(ReltgPb=B^+C@JdtX7O?-#? z=dlf;M|ThE?YDz?keY2TUBAhuMXC8e!|j>*Ju z;wG_@x@kmL%FhyGi2mgHiF!l^`Exi4c|o{Nl=omB)PL&LrmUl%C+k}!j`Fue3hg=` z(f^z1(3h-^OT<)S4$+d(j@U}*_<=~^ym7eJ&cC1rjwi_9#W2)%*3q5Nck1W3!p_%D z({YvPuYz6Qy~GK_h+snhXYzekqyKqf#jGE7D*uxx%Q=tWXjO1*^SFc5@21=yf5N@Q zK4L$iUy*%?MU?-0`1^NmJvCLV_7tw;#1@2(SX0l7j>m}WStb7mFNgnmjN^09(2_t* zAUcxwB#u)agE}hc_lzDO9T8TUgnGJzaC}w^zpGQGmnss7p{5(5cSjAPBT_!A zWgTttJzvcF{{{UJr+16fx{AtQF@o4sL=|M7xI7G}Qwh*H^ z=}nw$AEfAZTDi39Rvunm^R zhmR#BwX7nywT(6R<0PU1?PrMl#5aWgD{>T`dwAcFyVf-HCUlI)?pF3S{DTLD`b1u< zUxG>5jb=&eo}m1TzN4)FIPZifiT88+ET+(hQ@Ce-Hzy&yRl)y@;&qCsMhKm__;`QIpt2{uuG_ z(UknDhw3g{V={GRC?CQQ%zhPAro5E8ukZnpeH5jx7*SmnDHG!J1^SVtk?h4?c#YUd zY$7%je-b)Y(LP6?By<$OXRWL}C*^#W7a?y#`5ofC8voysLaxoXEQrT+YHC?>oN{x&dXepIV*Ef>CCw#vodz!-i+OuD^gCEZE;TgM1XD-P&l)Cala@_v`62wJ6 diff --git a/locales/uk/LC_MESSAGES/messages.po b/locales/uk/LC_MESSAGES/messages.po index d77f6bc14..5f9e45967 100644 --- a/locales/uk/LC_MESSAGES/messages.po +++ b/locales/uk/LC_MESSAGES/messages.po @@ -11,7 +11,7 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-09-01 20:29+0000\n" +"PO-Revision-Date: 2021-09-05 14:34+0000\n" "Last-Translator: Sviatoslav Sydorenko \n" "Language-Team: Ukrainian \n" @@ -89,7 +89,7 @@ msgstr "" #: ../source/contribute.rst:38 ../source/tutorials/index.rst:2 msgid "Tutorials" -msgstr "Туторіали" +msgstr "Навчальні інструкції" #: ../source/contribute.rst:40 msgid "" @@ -375,7 +375,7 @@ msgstr "Домовленості й механіка" #: ../source/contribute.rst:192 msgid "**Write to the reader**" -msgstr "**Пишіть читачеві**" +msgstr "**Звертайтеся до читачів**" #: ../source/contribute.rst:187 msgid "" @@ -383,7 +383,7 @@ msgid "" "use the imperative mood." msgstr "" "Коли ви даєте рекомендації або вказуєте необхідні кроки, звертайтеся до " -"читача як *ви* або використовуйте наказовий спосіб." +"читачів на *ви* або використовуйте наказовий спосіб." #: ../source/contribute.rst:0 msgid "Wrong: To install it, the user runs…" @@ -1501,7 +1501,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:43 msgid "Public dataset" -msgstr "" +msgstr "Публічний набір даних" #: ../source/guides/analyzing-pypi-package-downloads.rst:45 msgid "" @@ -1512,7 +1512,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:50 msgid "Getting set up" -msgstr "" +msgstr "Налаштування" #: ../source/guides/analyzing-pypi-package-downloads.rst:52 msgid "" @@ -1526,7 +1526,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:58 msgid "Navigate to the `BigQuery web UI`_." -msgstr "" +msgstr "Перейдіть до `веб-інтерфейсу BigQuery `_." #: ../source/guides/analyzing-pypi-package-downloads.rst:59 msgid "Create a new project." @@ -1537,6 +1537,8 @@ msgid "" "Enable the `BigQuery API `__." msgstr "" +"Увімкніть `BigQuery API `__." #: ../source/guides/analyzing-pypi-package-downloads.rst:63 msgid "" From 87883208ae1fafbe291994d77246615aa0b31ac2 Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Sun, 5 Sep 2021 20:00:36 +0200 Subject: [PATCH 0135/1072] Prevent binary mo files from being checked out `sphinx-build` already auto-generates them from PO files. Ref: * https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-gettext_auto_build --- locales/.gitignore | 1 + locales/eo/LC_MESSAGES/messages.mo | Bin 18402 -> 0 bytes locales/es/LC_MESSAGES/messages.mo | Bin 15012 -> 0 bytes locales/pt_BR/LC_MESSAGES/messages.mo | Bin 110880 -> 0 bytes locales/ro/LC_MESSAGES/messages.mo | Bin 845 -> 0 bytes locales/ru/LC_MESSAGES/messages.mo | Bin 44338 -> 0 bytes locales/si/LC_MESSAGES/messages.mo | Bin 464 -> 0 bytes locales/uk/LC_MESSAGES/messages.mo | Bin 63748 -> 0 bytes locales/zh_Hans/LC_MESSAGES/messages.mo | Bin 100727 -> 0 bytes locales/zh_Hant/LC_MESSAGES/messages.mo | Bin 6020 -> 0 bytes source/conf.py | 4 ++++ 11 files changed, 5 insertions(+) create mode 100644 locales/.gitignore delete mode 100644 locales/eo/LC_MESSAGES/messages.mo delete mode 100644 locales/es/LC_MESSAGES/messages.mo delete mode 100644 locales/pt_BR/LC_MESSAGES/messages.mo delete mode 100644 locales/ro/LC_MESSAGES/messages.mo delete mode 100644 locales/ru/LC_MESSAGES/messages.mo delete mode 100644 locales/si/LC_MESSAGES/messages.mo delete mode 100644 locales/uk/LC_MESSAGES/messages.mo delete mode 100644 locales/zh_Hans/LC_MESSAGES/messages.mo delete mode 100644 locales/zh_Hant/LC_MESSAGES/messages.mo diff --git a/locales/.gitignore b/locales/.gitignore new file mode 100644 index 000000000..cd1f2c943 --- /dev/null +++ b/locales/.gitignore @@ -0,0 +1 @@ +*.mo diff --git a/locales/eo/LC_MESSAGES/messages.mo b/locales/eo/LC_MESSAGES/messages.mo deleted file mode 100644 index 8bed3f0e5d9095d1c181a3e322c3f063c8065226..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 18402 zcmeI23zQs3dGCvh!A3lc4TPsnO9DUEn%P~gp5qrQX(iUuuGZR>g>h_6?@sS*@6Jw- zyL)!E3gkf^#9)ZQki>}{!XpOb7>MIQViN+2l#mBW0F#G92*=6ENpf#;NzV1nJ=fgi z{{B_fGozJk$()?zBqww9>DS%$=&G;2`l`CV{ld50pM)=mpMfuizYoua-}L-zsPf-} zYv8v%&wZ)8ztHm{sB)LV^WcEzcKB@WcX;mhybh|qaY&QRjsCs?)sAJztIUu3=XXQ8 zZaxZ?{}b>P@C%TC<}v=$d;h0@{(s;F++RRvm47|F2yXHBQ}C7C*P;6V1MpSwE-2ML z1l8|jp1%jxp2wj2^Y?H7{v*_T*MFCLz5(v$egLZcGF18xLbd;PND*@uvBHc$-guH~eqh-vy6=b`j@9Il1`45jaY8rmtN-j6F}+nGAO&=2-Tk*{(ccE|68H#>ozF;eAqw#6g-dn&qC?@1l0Q< zg(~+qa1DF{YTla5UH+FsrC$U!PcMh6cNjhgj{Ey5sBsOU>OTU{g>U!iKjwKiyoTrZ z!CmmL;Z9hhGo$cUco04U*z!s%@tlzorF=fOiz;}$}-H-hTV3Y5QiH#`sC3Dusv zq2~SlP~-d{lpg;FRDIuu%KuyjM|wCPYFu6gl|BIVz6!jH@xKPj&i@#rR6ouuJN=A7 z=|6(chu;U)zIQ^k?*ovjVjhCB|F1yx^S?vs>)W2^P`S##0IEH&@Lca%_S_CtZWmPh z_jw+KYVR$c)1I?X_02=|ukG*O3D4*L$Nlqr;fuKcEL8o!1J8$Fg|dUcfa=$iQ0eEh z=-?{M%c0u63F6w!8=&&v1l8Zn^LEHoH9rSc?gZ5P9*5HRKS1^8NhrOYGwAyBO1PQ( zi=gsNLY2E2qB_%nYR^ym^bbST^8i$PJ`L6XFT;!B*WvZ>NvQseZFKd9Q1vcA_4_E) zxV{6bKOccFhM$GF0`nypz;8k2zhKDKvli;TS3v1yH@q4ifU?IspzQT0pzQl@sP*mR z5EC;Gz}w+t@B&!hg=)`}Q13q% zrK_I=Uw%TVok49ZXZIlL5Jyw&M*H`Mq|z?Z_C;Ck5dd>@oPei^!IF11T{X_LFx5+sBxTz((A2Ie)V3ccKtkz;BgqjzAN4M+z$1g_d)gV zV=#c9gVOV#L)qnvu5$Bc5Yi;G8LHn2RQulpFN8k@{}Mg`4?PP#V5Fbn{%;us@k7@d z^LhB@H(*2X)x*a8415BH@O?X+z5H)@1@{;2bmKD$)xKNct6}c%?|`zud!g*@L8$rs zFx31x4rO1D`ul%@%76YYr`K1*7jVBB>iG_+{)|KE^AMDM%=+~2fwG&oL+S0kQ2Fom z>7RsZ=Oa+{ei>>UzTxlx5^DVZ0jmDA(0L=i;Z4 zIb;C&ZsaGC;@9Tl^~hz&hmboF{eA`6Vy~Q^xRmP>qPaJP1jq?w9n$-o=H?FM-TvW& zJ&8xS)>wbQKfB5Ed*RRc>-#-F<|)Wd-hwP5KZxk}%gCFND|EvzcCbFsUs}Ac=jIl! zZ}#`U0k1=LAYb>-{s7J(2mJj-@PkN*ybF;X%D4O;@(M)1PaqqSbCKsDzlr=1^83hI zq>AYGYYz7R_w-yxT<=A`g5b*Rw=1x7;rY7ozpue&aRYN?6p@e8?;Xg!$Y$i(h<-bf z??D>KB=S6D0{K%!K5-v%H}ZDmw~^Zs{a)-~|G$s_--~=7atyfysUf)cQ+_M{$zyOU zk|1A2UWe%SaR-yaTagie|5><%EFfk7>>xafoQHhTKfBy>9KOb17r4=1{3`rIfBh5i zBmTMtuSfck4am!oKSI7A(eH)GmB>qUa-7cvmD#uvRjN_FUW%Ku zNi|rE@~{@>VcGQc?M#~WG|bzSi<4%yAy`S;mo7y`6}2F2)`D7`!GuZX6ggl~&ZMR5uN6s|J(pRx3$!Q$cT)D($J7;UJ3_ zTMY)osoD&;T8((dj#Mz+Zq^!6W_B>vb+p^8nVm_az1RectuT!<#)zJm8FwBvXXARC zfo70{#juHWEJn?|lOTN;W}$~UiJ84{zTWBsnR{k-xdzsPJYI~vvx|Aace`6MR~iGCrN|Zq1muJ7e$RAB)Q#^UYJUe895Sas4}yA_R<|%{Uh-lELv+iIvO&0AyHS#EJN-42w@1&p99GltCl?D@iVl-%H zdP%j~va^0DC@o4WRAMJjaFfcHyy|bRR?9`jPNTC)x)|ogvnVaDROdw8ikeHkPweaU z)>9t3PFlU#&fAx(5?jQjX0!xv(OcHH>!fG4!_8>9vEoMrr{?n&MKf1z1&u9Ms)sb* zS#Xu*HC3}O#5NB^OL4T!!0d~{lqr>@k=civ47}c{)Q@In#=;m2i*bTnE<}MfEk<76 zE}mU+7SYZ$Jc}A0>#cl~sFFcZe?OP=)Pd3nK8yZwJV@&nOed!lm>QY7HLIm58x;08yRZB?l@}HGIM}+CJun*-XwPt;kG9Gi{dm6)toW1#UszJh-)LwNu=(zT$}jX~?aWHnqk+ zC~jm_W<5v1!q8Psu#^RE=9@`7PyNDs@?B;owb}5?;?(}JeTM_BA{Ew$G+YUiS!QZV z7tPb8WhW(`Cck^68I*_9SaWY({s~4g9cEZ_JJT#+rEbJ>HA%%xbqr=X#t}@DGfkE= z)x?AggSk9!Rr>oI$xPUgqAS}51_sKu*g~|joTN4Uq25hB%w28zT&i_f^zf7f_GpXP zZ@@xTth&;~Df#>)S(U~n4;N{7LyS3A;&(}#2ABov%v+e12lu=sSdJPjcWiSzHl3u| zT1=LGr(K^LNuH_lNJ~c?Pq$ryKa((d%v=d{B5>5aoEVrLFR*7S-s!m5iXbY zmmOhMo#>=n4_C3tnl&0Czxc@B4%%t$c9UJVT2+3MgX$7awtBd@^_8M;=Y&{BZ}9%s zGw`#3MeK%zUAfgqo-`wKXpV0Vx3JVAwt03nS=YjwHsa}Z%%gI!u7wJ8cP+VDP2K;R zV%lu+s2O-i#*Qyp#CzeC<)CEqcBxa(a~4k)l~Wfo492cr%8m1|hQ`i0(tek3nZ+cj zmEBu3eDvP$<}$tx*wnS6gguj6uH04vGpBT5mo>NMF^nZI8;ijGFr>gA^|*)Hs~$Z^x) z&4-nBgY_wP&s?6Ft(z)aY&K8c$+%slbLZtGt@rEG62s`frh52r@Rp!D$_E}TwfQr= z(sZ0pw`Ufj+~#KcA9jkwHtV&Tp6%>v6n=@nWbB$neLITsXH#WS$ZmW)P2i=md%JUf zMFW((w|i>t3}4A{qqZy~FY|>{W1LvyvvQm~Wf%P@VfX#Ef4z0|yG|AjbE{vsD^FLn zD07C+^uDbq(({FMcJGo(if^jkN?1FB^}TQCR;Lmqm(}f<55qjNy;tegO2xaCr5PzP zYW6eAEL~@{R`+>f?=~#LR8(o*e1U-ez*-X?0x=R&V&VG`Bcv ztVJxVM_9Y;F2rqXDiu?mNTQrAV`px-m7>(LkFEQq<)(TTQ%E0t>ZPex2g-xxE!FA< zR=2_Ort-#Wm4_S4Tg!u7>M7@Pz6N@y3fk2v%5yo#iQifAEUq&t+3uco zCG%{Xvz|t@(s+qaglE){-a3}4Or2pr$VWu6C+&1e8+S>cX-lK?Sd+{*a%tp^{# z!y~5Hl@WuS}XZ) zsY)=y*se_ksRU~#_Ltld4WqjY6R89@jtn0t zjqNY(8V=sLzcMy@#hdq!kF3#|WNC^TGuFE#tpvLd?%NlP508xmSB;DfkM4WJ@UC44 zMkXh(A#1bV=8T{;6@`nvE$O&kzddJaXz}db`f^649e8KpygMjqCm*rH?NnX~qGZk3 z=-5cN%Y)^CH9oRXnzBbEIRn$rmtowzGMJeQQxtsl!KvM)ZQXq85n-g#2nX9b{i+1p z_##*{(IA%5DDCESIjaQCmc7lc-gsr;F0XC|Yp)IluUzw{(jEn$oK6n84h5Ua+i`w3;E(*NP>knhqx{-7B!RkfG^V3aWjR>_Sjfi!m;X7tb&}gEQIr&02#Lv_H3|Z zjdFqSSY4C2ANCG$^i{)%GZ^KjL$s%Vq?%GDl7Vq5;zB#X=s2AS8c|)w zXzS{ofc63N4gQpvjsTEN|Pl9)YaH#F*vovD$i&O`WEma)GFnL3*qr!N)#<)4xp$!V)@2p#n}R< z#3XRR;ncjDid)V!YsrEOnWc#hmFjcbj^7h!oa}`2 zW@O_NQ`!>w>|w( z%B*a!cy4W4sw*CNZ8j6m$Gm>?Lc6_n^~S(X4uL74z7!vgIR+yLmNxN+jo2s#7T06+ zXPd*&x*@})F{-016mm4C*Jv0Zv>h)n(sqQiu+h%t+?w*js9M)udrf>aEFt=}m~iU9 zutaZL;fZ_b+&Cc{Oqw|?WA=@ZPnDxvWRXnU@(qgOL~;j;k;#>(cn~Qaf!5^ z;q6mjA zle28b2@KQY?rE*zj{;aJ;(CZL@&~d~ga%UmMCIQ3$+{!I_7IZLY%V7F@q5VYtO<0Z zVRD($psld*p*AG8fN`?$+u1}QEObFJ4H^bIQM}Q;aAMd@_^8-e*yJP+pDJDZW$@rp z4L9mf9}Pd8j1VxkQ#f#^}5fq}yV&0|umXDaqgVq_GGHF(|$H?0-a5^OW!vqp~9 zR*4%T@^5|dNxRf?euTi6vudmkyP^i~r`rIYaglX}i%@u&b!x1_qTkXD4N|Mo3P#IQ3@7<4SS%2)L+% z^g5=F*|57gep}QDnhoo31LW11H0+FLu&KD#w*U1;&NOv;B4-*-oQa)JZWVQE#Wypv z%35Lbq{KpDgJ<;Hs*DCic2{K&{7a0e3n0*iB7`RIe?Xp?y|!1E-JsaDM&@PXTooc& znX_koX(e=s4cd2-r(1k=>26A(>CFM7OkGP}Pc!_}>zq@X4v&Uto>fardWF9VD6CFv zT|)dVs%yV#2jD3}Y?L{14}aJZH4jWr<`E~|3*9PkNLeyZHXZ2ZZH#Av&_vdYBEe;3@ zRJ62fdSpSZ&5p?L8hZBDKB9(~aa(7_WES{iwBEVF=MjGz!TfSPpw`}0b+Zx8+bP<~ zqFx@mzbCGC>=8yq3zO^&CsWKj{E#N|!K1O3Z5vjTiFcB%uOu*rTi5LBN#hyHU_WaA zMyub^~VZH()FrW^YWiiycvB-PN)CeK76V zBdg{XDSX1c&*#QC!Ka3T;Q)4 zQ1DWG>=ANMM(Z9U(FwFA&2r~07%gv+=H=q}d!%`LHRskujXUFE_Xb4TQeC*^(ygW} znJ!I#LWmP1xt%SjvTmRaO|t&UNq3#_I4;S#VOF}1TkJmVbeo2s2f239f z+&UX{cbv-ck2@B5nz-A}nB7YE^z}bL*lkrO&o=tDs-vq<*?W&ApW!KcZ_%?nWj|e! z;)|<07*E?q4n_ZUBX6hCD{in8%Q`gxcLt48_!%ma5@)GD)$NY@cXhu?yNV^ttzK8EXu+9#$17HK@C<>h?h6#jI-S1H7>heYtNu+xai{4(_XyyrPn*wD!QHA> zDS40mOR%RN#%{slO=lRElM9&YnRNUgD;{^scZHU4e;%U`b_M19NrtvW&mbgs=IQib z5xHvh-zg%eokrAT56e-5w$1E)*-ZCFRQ@X-M1VzAZRgCWc1CjX6wg3PC diff --git a/locales/es/LC_MESSAGES/messages.mo b/locales/es/LC_MESSAGES/messages.mo deleted file mode 100644 index 9be893d89836f8ff008517ffc8087c59d20c36c3..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 15012 zcmb`Nd5|1eeaG9zT*AgkCLHE!+r*ZZ-H|NWMvMp1_R6zw&0g4ckP@yn5#QA*R zdp$F&T{)Fhy7cs&?tcA_-~Ic&{l=E_KHzbEl=foUc~AAc$HDJElmEE>{sPZCAN(r# zEb!alOTiz4&j&X@+w-0QZUZ-gJHcDP>%r%M9|WHZeggEtFM#U*bx{4k4ZaBccZU~T zXusbEK8@#Z0e=pB2dHs=3)J_Y1786C5%@yzZ^4Vfe*62DPpj)Vu|#@9zQG zn)e}xA9wf=sCm8wYX6VA=RW{{p8KDHyTHqsRCG8B^2oa#d=$JB6#b?k%FDn*AdkER z6zksV?%xHnRPU6-2SNUMf69OA|26O>;13+0&*Jrb4176w19&;u0JYwCg4@6kgPQ*l z@DlJZ!Sld>bEo&Y89&t{URgRcO!?_J;w zI0I_D_kimE04TmZ42qur0E!k-VAEI`#`PhG^l=m4DJEH0?vaMF`4d{ zz-z!yg0BU?>2Mc|{51D(0~f%nV1o4gZcu#v1Sq-r6e#)nqI>^kQ0x32sCE1VWJvFP zKGyoSf}-yvDEjUP)&Dk7bdJFg{2aInUW_oS|NB7ozYo;7p9V$GFM^WC?}M7>A|IIm zw}X1V3)~034ivqA2iyUE8AKGl{{*iBw;*f`;mv>_I>+-`pycBTghhD%W!NzAg`oI; z6ck_H2ukkX4laZDf}+b$9bSkq?BxFCpy+heVE}5r;|}ium$-ib)PA=x39Rxi2G#Fs zP~RU05moOF5E1cKK_9#qydC_kd%u~@Yu($x3GfA9weUfa?EUhd%WlQ4ff_zaAyDi5CaC>>7nGfQ z4Aedz2Q}U%2JQuqgOcaZf*SYFK&|7)pzPC2D|UaApycUJkbmCW`47?Z9s;$l zuYy{~KZA&l_k4)*D)2gxp}ZAP{P-9sdHMrT{T>BHuOEZj_qi2pU-`Ieig@Q;Y3X`7h{}3XAVYc$P~W{DgvH+HLCy0mQ0spjls>%-<#;-H z8~98x1fK&Y;Dz8_py>2oa0~b`(Ch;gT^>EQ2YA{ z_zdtR2!Zx-IjHZi0ky74Fb6*ZcEHWMEgkLxHQwEz_IV0~RNfarw&wi+6kRWY$xi`i zK*`O`;4NSZs^6DE>C=CK;@eeKYv*nP#s4>f=Yaa=%uD;w^+8(8{IWdU!tWQ-B)__( z{~KLz=i!2TF$`<^myOSn9y`RR?%pL&4OQ9~&kL`H(>1O28{*Ji& zn?T9sYutSaAK*tulMI|k6AjAiE`B_}ym2TRi_gC_@?7#UdOejJ@%SAh4_Do9>B8AA z*#}+XpHDkP`v^_fk_Gese*S-#yFcdeR~(K)j~nTXu9zly(2=^X_6mZziz?&KhOUk9l6)fi)kMkd6w{7GFD!D_;G`~k?!bv5AD6Qx6<~}bRD)} z?Ah)7zK14VEZpw(Q&QTqX&2C@XkFUt zXun4LFzr`q(!KJ!ksoiMO}hs*@GAFPAUk>+?NZv)X)mGas?$(k?_L_}Zmts!rL)hY z-AY@eJ(u=QTAQ|;c7S$1?X|RL(sbQy!FwC{G}?A|FSv;Ii?l#D?m7y-fc8e(W?D$w zLDThm3&a1%#`c9lGwQUmu`zFK>|oKZhpGL2I1By2Z-t#^m`-%UB2RIdBkAO6R4>dX9DUxv)Q4x@ zFz)w~;)*n6+%D^d5WHVX;y76~WSm>rdqw8g_9V^FPnP^WNvByf^4cADRJ=V&T(mnt zyPb42$5PZPL@CzBQ+umTw!=JV26>=|EIv1H?SdSUqs(s=ut7am=wY@ObeeqHSPnW- zL!T5pXS9-YLu&1T*DyZtYqe(5$Z9pe8KrC{fm{)^V(Dx$6|cn;?Ql7XoAx1J6m6z7 z>#ll(u{z;u`2kyXGaw_4h89vjk)&B_X=#!Hf&HjZS9A(Br_* z!z>@JdibW>bBnIzNjn}s*SsYmG;8Kf84^IUJZgvDRG2l=s4GHxQ&H9^G9xnHng#fI zud6SU&K0?YsTD$-W#nI@&-LcwG@LhpLQJG)hp z>R17x0_H0k%R*-In@Po+?qnjlZX43fqEqf*DNWjDM=ZIm)yGjM+^9d6!9Ppq6M>XE z^QKY0RJz;@yRt%^M#R&-V!JgR-d=Rlk#1+@m7}-2Dp#$&z1rM{cI;}^n+bCx;0t+> zN)eAn`Le&zU5+{@2JbRhRCK)=nWq3LZiii2vBUERv;a%@Qew(p*>aLXGwnQqf{?fr zjg7vM8fM-;sej_LB!8jkb{W9i-+>Kj9>KmK9ruriVOK^IF+k=dHDW*V?svmP7I1Yr z@e2&Lqed2@>&sy~3*(hA6YE%KD-GIhtb4^@MC1Zz^<-%B<C6c9lRifDpSHf5(J*%)KWP-KkAwRQRi#Gy* z00pt(G-ieUg(u4QMubaVyKlm@d@BK+vyLTO^DIJIRz{yVwz?7YotaqfV6>Zgcx2DQ zx@QTbO#S^@8r(W_82h&LHY0DH$yoD6`D~pqj1FrQ8j~3J5I^}S)U=Ro?vWoQjZuCYLm<5@b1#dSb)kd97^x|)w z4H`b2zJ;|q_uY{w%oTM6#aCE?O|-Werm}^TIwMZvW!gopAqInOHRg^R{>Zv z!MezNv8HZ}Co8Fqu%Yo8M$c|7@H-|Pm4!mCM98ZD`pa&+gK>BOmy$BMtE5KKt07i1a&CA z5)sAZdAGWKyNQ;?=<4nrJ9gNqU6SGgPLy;Yy-Au~;==+wdO(X4v;?JG4SH;r_&$ug zK9S=%;-KgOA=5&LDQdNf7CI4imXbA@g2F}(k4Ms`h+K@0jk|!U&USgz#9~L<1PPKG zv7{OwXN+vtv7~%M^DsSTWi;%!Q8%=Jccn4%yVgVz2pwGx3AEA#izRiG$_6fnG&>vR z6QK*%&+j7rh7UnkAEuE~f%S8Wq!1t@1;Selwq=FGcvVr(<$m=LbE4qKI90901{F^7 zMucvt^}%pI&elO8ys7yQdnxlz)NEp?%v&r-(4rvDJf-zDlbF}Eg3?6T7^$k)OGWHU zo)v8$HgpNl0W5c(91lC?BP_V0BDXfiQQ&5~yD^7ROXeMMUh{~H3#Lcnf+I=PK(G|q zqIaI*iCH1RgM_B^7wwP$*~CWJEE125T*in2r3Xi_+=LTxbUduuah#z)gB%KI2Rz8} z&7?=oCM5&Q9-NJaB)T1Ax-s?Ej1mUw4W>RpM$k@@X2s63iggp$hH><`GE-O9&|A!j zL@@AI%w`qBlj$1~3P`%8og%<84liakgv}j4S~3~da-j4BUDo_TCtEeqbm{k1hABl? z3MFrHl!&WU_2)*cyL;pujQqobbuc%}!AzRG&pDW~>rgi2U^F>INaaP0zi{2w_=^^M zl)tz&%)HuM66V;%>tt~iQ>*1J}#8o9NhY)E0KZOR~; zT8!2FreadctX?>KP+_3b=4%{hTTI?#$`FIHNUdf)!I`tg*bf=Cq3{}uq=AWfimnkY z#Bt{NG#@HIoS4m8QFG$PqLoc7CRKma+@T3Y9*RsS zRGg^#w@y#aPs|>gn40wW9jeamf5qz#9h}~z^kHH#MU03t6IQVI@PPyV!O7Wa|GMef z$^8djGdVRiKfSPU16@00s-ih7A ze%j9xRmy2nOyhn0-SsHnG#67LizoIHOcObFy5=^!e&@Bm{ds-IzvO!V%4;{>GBFd9 z8Ci-PwHxxUs_d>@IY9=yiNfe&|8!o&iK~+KA0{n!H-~Y;vR{Nqc=0GsWIKs(Dbl3+ z)#~5R&`E}1bwZL1QUc@}MKx8_X~jGBK-DPxJzbl`&X@^;EG$4As@Fy})x)X}Fg%6@ zqQiJhIUleHr4DSwmQ@o88&y(_T|4kyZFMCX_YopLJQk9VbHi6b+E|WO)ZL$-oAu3) z$+^Xfr-{;}rve|&j1mmRN`hPhx{N&$TQ?B7K;@drPX822gwtb?7~`o-G)P8rsPThVzP^f0Z60*SAA7gXyf-Lhw&!kLEI8y!&!+x zsJ=qlkSHJx(*7x}lJXW7MO+fmo68ZeFtt=*`wupwmZ1WcL`B$uDy-d@PnDJ;rK!i7 zDyyx;iViFpTOKL%g&>G=`Kte*LI6VqXNVH>o~=aeSpu(;agW(0MU>r({%JEfj=+uF zQ+>97iu!C|zYWrLWTqZuX{_RgNi#jflONBC8p`{E|pFT%j_k+AXPXfq=7otpWP8BU_~z^t ztuGDAvab1xn>tpGKq?|u++c+V6F-S{xM9SJO=Ht35J9RLpOq@OEpcC>2>#@eR;%%nr2+ zESq6+JIdM;0%9SGg%Wxz{>WT6HK#n(?dpV~&;!F@kJ$Y6@0oIH#|>1)!y9DFj6I+OR4Y6cy}p3n1raT5ziGyPa!RK9-)!%#;6)y zl|faJm}PYPrP{)6x|sbfb%1*|gk%oBJEhLd^H#Jux}@3m5+c;X#`#XCqRJFW68HaxR3A$N8X z*>g0LVI+63i>osT0-4BQsG5u^!ERUl1IUmqCzD~aouLWC>yZ)m7z7)D<=|uL8zfOk zl|-E*HdT|O0F#i7Yh77_3uU?>O*t6T4AO`+p}Oomjb%?5y7=^v%j`KY2eSVMzx3%;BDFza=3=WvqN52AQB? z?TQ#e?=006>?`CUl|#UBgZ=wr&eH;(E0RT8yvhD&ILzdOIH)6Oej`>gBnfr`iJ*>5 zMx_e>PGvv|l{bTEX%tb&#v|o15+m^}Fx79vODf!LR1PKXKX@XNj2eYk;d^?mDRdjO z5f#-3mk#npnZH|+_4Wob#H8OVHrzACapN;(QBx${)yS!fYilLR?H#E#`X%GbD??LE zYU_Wop(B=p+9!f?j8oKsfZNRv13pzw6n(6hYF9C5a}0C#Zo>*X{bIlWE~{I7Q;LQ0 zrDZHQaJO2SlowX41f7%ED3aU=-;>ySf#uzxJGL6mBbG7~WFK9*LlM5Lx*IxKhZ&^X z)^SejaZ*_p^}K0L*b z?KC8+i5_jSo>>d|%P0Mk@Qh0RNX6cYu-QtfdwU$`4f{w65T*XZD&;4xq(8Jw@}Xyj z)yAjwAIu_TXS%GO@rhX~B*R)w60aMl5sCLM1ROmZtWP-?En3D3l?ELSuZj$NY*>KPQu0u15Ksjmbh) z^+$RUt_@67ijQ@X8#&k7j*7ulStbft`+~b~-SvA42;$_J2`I|*0m3qZK-CpDIwR0o zF_EZvI1;y)DM*!!jcPD|ezOqr7cGjI*9n^qcf@g7KoU@$D40OU+OlraL!zBmp_lWL z-ZV$kj>Tsj9*n*k6re^Qmc^veXSQ&}5$su`9c+^XUfDZxVdJV{SVg?yqAFuZoY+(} zAP+LRi!}+-N}=O>2@H}UkF2Oo#|msw{?8gzWA*4$+BW}@2fF4&;gLV&FEu!1cR}%1 zbB-XPE6)~eJZMS*10%cccwrkfClFRja!P-<6ch4|s1|=slLjmO`wb(`a=5_$%Cm)l zRD<}`ng*Bk4h_nXb~$Mlf{ftUtl60ngwF+(91k-IYnM1_fx$0U9s>7vax;Jub$q+;y~ zpmx%YaBv8MstTM&luq7m-IZmO+lVO3oW@$>kfpN%tzE;G#)T@oO@`>?URi;z*gR^` zPicz@O69^wwpjJ{4FemMk@))(?D9|oM&q8rp+(4XVE;5`+b|6)gNdScVFZ6LWqE+H z$7zz1hW;r|UsNtRY+)=57WV310ZtD$)83Xw-#u~7t;NRl2oUyMjnJRI2>$+Ac!>aIXAjzFTA-#z{H zA2}b9Jf|#pZ~c|SbUC23)Ot`;cp}Sa4E!g#S4lTHu+dl6wZ4{>Q_tZqE{toPJkzy~ zezD%U>KvjV*co`xGbdT^C(CmYr1<}QF49tzZbD>|Xq9Q85sVv=h;q{=VHybu#K6*U zY;;bd3Q_rIqZoog5vcsetJOx2Ox!}4TSq2Fm7J4RGR_kv?PTKrkLM2qK%n|NA@V-uGU0_mH4|{-4jkKT~t+ zy?XDyd(S=lIrqNLpLN=c6aL;Zlq8P?KL5-l*?Ny8`LBoTEPszplD`2A0f&Jf13nsf z&vTRH)xZ_N`vcz(ydL;r;F+{_@p(yd2giF?CdvJP_gUrbKM43>jz@uN=MvyUfYZRA z2R;pWZ{SSNSfZq=A#{u4VwYT@6 z03QR?^VbA82D}f)69H}q>N$G?JP_dF0G|L<|DG7&On@EW=fTTUftTv{^J$mk*8|HO zzh!NboCW+G@KL~T0$&7tKq*Pqaox?pZvsET#b4n3og+z-a{PwTB>6bUe>RpRJAkhm zPm+HCehK(8onMzE?*&%YC&{ybkKT|ZHQ?)j4*=eGBY35qhXP;2@nbh7$psw$3Gf@h zWFkqP0rN_w@&w>LK*pPa*8pz>p1wOtws75ZfJZt0lgpCi0PwMoPm)cX z?*mT*zGaWo%RBc%W4ez2z5+aJAGqT8?*bnSd>J=i1AOo0N%9$ff7l@(-*5ijAAw&3e(?(M3jB*JeIEY>_&|=o3)J=ZqtojD2Y{lB7hDCNfG-7V-k*JSk~|ss zBB1U&^O_`iIPh$s=64HFoaOlI zKt1>HFZuZ=0UyTkF`%CFLg0gezYF{Y;0J&y@MFOH0sjMdCQ!(I5a0p8M*+_P>i4Yy z?gf67in>4DoI+LzYO>g;Jbjw7{}iL)!$3&&hM84 z#pmw!-P9s_>;k_D{6k>v+9Y`` z@R8Rg$!`GP5Bv!5P}BM2oH@te_kc`gQl+z^`*#5!!1159ljL0B$ARO(9{| zM&Q%A{vseGlDwbJGeyZmI?Ng8d%!D!KcQ2iyDR(9D!)I4!GXf$Tfi>>4<2Ve_Q+F^U*~dzZ!TB$FKQyWC-vi@IAmgfsf?(XS^Uu zAob+to18y>0ua9{-)3OFi`#91bhT=7x3qRlfW@x2dL-1 z9;oqt2q-@L1n}O#e+1qi_;0{Z@|^zyLK?}(UW^O??s|#O_bgEN9|!8bX8_;9_0I!d z!tq5f^YhOJ-ofz;fa=fgmwP*PppKsdJcIjQ3ltr{3F^ssOP=|sD9i56usOD)ObD%6kfgoJRdmpDt}%H_%M!l1GfODfWphoz%{^+0Urtc zF>odD5wG@kwgVr*@fE*lwAG*cI_kiDV zdVLg7 z1NU-v7^>{vHJEaC{!{fxwpo z)z0m}dja1A6rX(%SO&#EB=qu-&ucwZs)kne;)<@ z0C*nvefTevF1w;KjQd1K=tF>AA!bz_hynb{!PF&z{dm610Dm4 z&R-3@C-7asO~Cg8Hv|6@cs6k4Z=CKA0@cnn!1n`Nz$3t6I>%Hd&jS7u@Iof*HsGs( zUEuDIyZ(GH@cs0E_!ICf=fC+$=f4mCt@q<=z=w1GbS6#m`fQ;1d;?JZ+yi_Z_s;?! z#_^l}j(O(zBvAPN@TaknfS(2G{s(-<@p2AO?FhBwYy8fL&_47SIjqfjj z8rMgGqMI)Rb>G*3_XU0zsQZS#;P^TNsPidM^sxr0`^rGc{|&%@=lGw$=yu3wzLX>- zj(_gUZVz1uRQvx56kY!SxRLuhfA4nbo4?|}AO8o}ug?TNgzMe{JO_9uQ1kpXpzwIw zSN-`94)9R{o(sGmzn6d-|K@OhM}T{P>i^;J`x6433a}O6LV(W<@TLG?5#Z~A8vok@ z{3D?7_5J`q1k`gr8sH}b{B(ey2daNx4)9+C{2p-SJ-GKDT|S=w&)@+(T@M`Q`saSl z=lNa03poBO;O_#@_&U7Bb$bP4b=-$Jf&eg^nD zj&J<7%kOjl!{z6H0_Qk?>^nX$UjbIQ{@;Ob$~$8-4_?x&E_1=6PH<`V(k^`!2&6((|uI_*Ij+Dq2y0Fe(dQ(Ca=GS z(rIx1Bu*zHA}PV-&jp@_@$gcvdjU}Nbl&}k%&z@ypzORK0`;8z7-8bmqa0L#$AJF? z{9E7~`ThMrKa^YwY@9Weyb}112l{jOVMI=Iyz&?6AJ@NtNs!&$r_<8QPk-2u*`2pN ze8~9fZ-AoLF9JUd{2mY%O748bkn!*9G42pC$vc6flbaqjWOl>LfVwYz^pM%Rn}Cvg zR{%Bc>w)(Leg?=?CI0|C9r&ro3?(!4;|svYaD2(x;1f6loB`el)P4U16yJO+!27T8 z=bQ(8Fz0swB?qnsJ{ou}Q2g~=p!nz&K=tnpz;l7`3+KNQ;5UJgYVuz|J^w4``1L;m zO0GW`r(%kE{}xdEaK*|Y^PjE;s@=Z?zLjx&1t`4y)@pywtAUbdCxK1ir+`ld?gaV2 zr}Mx+0-iYE;V4A@*BpNhSOdPhG-UQ#T6TQ2fFI)gCxPz--aI^Hbboln=lAiKKQ=a$ybAcl@gcLfz7IT;<6(@i5#WWuF<=WQKE4HbFW_xJ#Sh*Ayn^G(#v${g z{t$RG=O02a;2FR_+6-QRTL@ZoxbEgH&>Qf97Y>Saa8sF!1b}{g|Tz3Fi1%7(J)6tg8hm!Ad-4UShy!W8rcOy{! zdOi@6PF@PUH^=XS=|N@k0ig8fj}9|Fj_+}V{&D=EEByRkASOX_5C|(Jr7K-7?0LeF z`Omil>2mTV;1hx6tA{LZ@Vsk$90xclJyr(_FCE}{z-Ix4&)a~K%kKl81N=ca|L7+T znVud2s=qsc;=4V-d%+)11d8q^aXQ7%Uk5${c)yB2ZzWLUUI)B`eq9XQ$?*?Bn%aBZ zvl zD0%W@pxVC=!clbdSfK8o0G5H51J(ZCC8)r43E8qvOb-I5<)A{r}K#l*Nb53XH0#E0< z4M5S!g)Q&TLfhr{Z9t|Vc{gw!_dN_I)BNrOiXN)K7jXQR&QS8_zze%W7AHEr=W^z$ z{UP%|{sJid_~2th$p?UU0v`|j)#F3SUjaW36raELg!9K43&7d_qi{jI+;lzfo$ z4|xW95%_5!Dmf`Xb11nJxb|7-LEyK6?*P8)*+a=L7-;`-_|lIOYJy5sq-uV3=( z&gXA^!I1e^PrPZ!;=OMLO3!b7q0`Arfb!371`3bA|Dqv_1O7Qs{5kp?L*_4U0IDCK z`c0pw*ZkH{vV!Bc1^6)_CSUTOK9WI(xK#9j(5Gx<-ps4&*b>8U+(mGGI(4tDr;f zfBUPwAMg2XmkWOaM8ze42b8}3@oR?6|9I%lKK{#qqVp#Khk?%picj7JlwSNhpybBq zfE$4iyT$4Ea^QV9?gE9!rvSeWya{*|_~hRiGQaRMzy`;+zSixJUw9pQhT|^)p97qF zJ^Vrcz7G5f$A5b3P_h;H<~I%{j|2V-P|q#B$;VR%iob6Fir-%dyn_3018RKt{9VSu z@uPqb;CSzCL&-(JCjzCnUkSV)@NGb~^B&+@;75U90R9As$(elNcIWSpy~VHpG*EK! zt3b)S{|x7c-s*DZOrW0kSfJ*0Jix~VxEEOA{MA6&G4BRS-uxv{c>FF<@-lgw)8Tyr zJTt(vfYS310jm9Tfx2%D_(0$V0qzHCoKrwucLJ#XJ`1SpUkFq`Uk;S~dLvNddMi-R z|6`!=@@GKN>*s*F?;nA}?>EEwGv4m>@gSh?dngdJn+>Y@*u{6VXMnPg^!I!|SM%E# zP|y5BK9H~diMR9z8z=k1IrZ}=eDwT_`TQ22NAO#fPa3YNaZZ2N^O2l*9Ousliicz; zZR7aGK>ht5pB|t8L z^Z78pO#%CSihq(F9||W>btW_7?}x&*`vd$|_~Fe!>2TRs`rFFyPvP@wKeRmB4SX+! z`@YF{)Tzni{}Zlxcz^=q;rru&59d1BJNldDbByEj`1}&zKh8(8^{@Gi@>$@czdFA^ zfzJ#0NJr@JMST99&#!SV{(X)wU*vI*w6Y_9uIJG<<(O-&gSciNLS(Im!nU!hC~TxaOmrLwwucbNK)Ld{D>9PCj4d zJ0^hTaNffAA--nU7 z|64wn@?C#-@_8kn%^W|S&oG~>IX<0_{{D&2gE)5ypBwr95I%SC(cgC*Sd3a<8{v3g zfTwW}D#UcnH0SQi=SGeX^SK`%)OqqH&OMUPm-&32&m8BD1NHZ2zHb6v0DKqlZ*-Es zX^vL|F9QAx@Hcdlzdv$dIct4w^LaO)Ki5I{I}yJC|A5b0+ISwHXNU6-<-2syAM<%U zpC5(uM>(&*wS1n<_Yph7_Xh6a^CHe+e%RkNz@O(c!_iClT*>!G0B-?K0n5N&;qybj zH~HxAQ5-)8IKk(3zU%L~0sa-=FXHn_K5yjH;iJC;d@#K&=V2%K?|1oNmf7F+0geIp z@R{TzyX-pPefhkJPlHeV!wj^)dN^@;fHR!0^8Gb@p1|ild|t+94WGZ~^E-t$Zsz+A zJ`dvj_xYS%_^r(G>-gwzJD=a@vx(oorxW4tK)8M*$C!y`XFn47YvK353~)SLcOT$` zId@Gs|74DTp6_o8$8*3d_&kmC>wqr-J{@=&aDva<`L4f%e19XK79aiH=D_U#@YQ_8 zf8^lj!Zla%{YpMB4;Rb__`CrBIY5D1`E2372Lk^=C&J(PoNI>m&IPtOe}6vr$X&j`Q$I^R#{`!DhNAm1BS+zJ0Xw2-#y^;%cA zb^5JxdgW}rmG)-q*@ca68lFkxlMCrYr#?MVnQzQj)^eSG3Fy+&It@MwOC zT?$R4jb3-4N9APYu4c8jGM%qZU00oqyM(X3BY>N7K?Mr*oVN$2XlYOUI< zmXkGWws+dyZi#NxI}EFy&eU7=PP^Z2F05I@&pR63seZRhFS={iq}5J6oo;i2-qSCJ zf2>h!v}V$&_S}4@&S<-hV|9i&-R{hJ->Z}Deh*Z|5rLce##A}oJ)JJJ`zvYi+J3i} z_Bsn{2gJ?Pdug}VpPo)@?N)tl+O5~qiCTMVqB1Mb4#o@?#nt!BGgV*vdY*qrXP z=a_tTCALBj+H-Z?e|)wvHB0+b&3>&u!4r44>eJH=XhE&D)4A$(_4IhVbDg8Tnr?5m zdio6{_BxHpzD?%7de5#|wSC9F)#~Do*av8_$CZt#ZaOtvZOzo_l?b%eYc7B=d#)jA zwmwHUGNPK-RId%)(-h6ttH&CkVyZedTd(np(R3hk?mSj)Hkkj=mS2|6wYjrBO^4T} z)mAO-)N6g{L0D=Zt9PL8l+i-%%y6sT?K(#3qaLEk*w^kscpduRZ&o`z9x|EkH#Nk| zG{uwksVb)mY%^Q!auybe(*Rjj(}t#F@kQlKR2)0^s`57RB%qM z-YK=}{T|qYh8LQ3Bg`v14Q_%!gv$;jTkqKUdbPW7H1M*WKn?&$H;#{tZ{7r4$KQA| zx@lzn==j*Cjbj`5zIol~`tkMaMv~FZqZ>A_9|Nx6uyNgJGFIN0jE#)0D~*owPhU5d zMmCj3;@8dD*U^#u>uCOUEPT~H{&j4_hVhZH&6{a#-Ny0Jkz{Oq-MS5%$C9yimiR59rT{KibQJtG_B8eI%vYgFLNcSgW z$I?n=ZlO9qU!M2JR4Q~R>wX-Z2%wd=`M;A+^y;0ti3-okL_;^-G9W1qxD*d#jsu-* z*ZNI$8y<~lapFQrWREPT`z6gYWwTb&)^H~loS5#n5UBIl%^;JSWyrI0G_+e$TM+}P zxPI9OW(}u(Q9UCoK7E2%uIZe;TlekWwe!&7a-&r-rcPUMch%%bI*F+6Ea+hc6mP0v)M2qhF+ja1L@Co}iGs;0MXY>8H!uJ)S}=uBYfi#IX9 z0136{=0IP!oZ1A_S~kbhHk#W?_P}(@Y_B)pofsaTL7Da^%iKLYzc61N?iyV%FR}rK zC!6ib;kjxTTn=Y9UsO3NNo_42SU9jX^?NeWefQd?l|_iqD7y8|G3WqoLUWiOpiV(oCz9>R0)rCX8QgpW6~PGKz&u4 zSVnBdQBg{!TZ%^)VKlYc$I}W{SqJ6PtJf+=(RNTzr{3gBItKE`Mn=|&qNJPhzStD? z+U;hyf^O~EUC?HA5|V+4C)dZ-ey=T?YRc@)LYIm*X+)YVO1Pc=V-Lcfj)qON z1oJdG)1oCTHL!hmu*@yk#WS-gwFVLa4Lnmv!B6%ZO;8Gbx969|tT=5RD-L3U*X{z# zYe4^+BCaze)9HZ9oiiA4TlgQ8F)>9f7k^rXt(9T|O3*r0YTzrU2aV(6-Cao`nm*L- zcaWO{a(ER_T45KgV5(O8bU>*cB=MA{O~is_TFr5=lwD5EM$vMcsWKr*=Z?Do^X=o3 ztL+p*mND0<&o|`|)YE$FSfkT!8RIbF%qEHiSEJs9qtFUDuEb&WbP|mdRE2sg9am+n zCbFxIIX$E6BEm)@1u+HlXf$$XbdL#KlN7YrYfNJk`TfyQ3zTalVRwKtO+MC|1X3Jh zP~KCB3x*`gScjzS0cbNrs3~w+$kWaCaVdbo@pYzVAzb{PwyBa}ji=@Lg((vo5ZYmB zenyGPMvJ)gEh-r(mWO95BQU0vNjF{9DA&uh96FB#sh_|kHU}uqJmxtgV_cFI=3#{< z#ti-ASPHUO=W(p;5{ZziD>UI6<7Gv^#UMJ}YI6ndh1<0H2{eb{8oAvaa$Jlc+0@n4 zrGE#11sXCniDe)>7mTDW>&Dh!gz!Tt@r#Bc5@LQ0!)7bsX*tQs(~N^|G#fqKVR@F= zIGJ}9aL~kY>En>3LBqJABF#`2!5TFn(Y9{e9pqYf0hKxDkL{sI`}pC@4hr0uPHUUb zg@t`!=Yf<#Y}6o%G+%4fL>r46k=+ol8z6^M%5Y;8X0vQgi&Ww&h9GD_U4-B6cLJD-ka@WHz}+Vq=5`~b+OSik?O+L_yM~Bw7OmH zle>fhA)Y|c^;$XI$#+GB#4pBOG~@QCR6)2<@>7R?S&V=9d<(PsZICZGh3OI09=6L8 z5=Jzm3XKaO{_%|)N@B`pgAhTwg+u17QYnkLJ<@}TMp$dA*X|InqT4ew?l*B!Jw}5F zq-?=A=)~tJ1S_A(8EE6F_CT`-hTf1rqBI?wdrNm zV>r+}{4&>>>EQ(e?xu8?A6jiewxM64Sh%^spx<I0l= zg7*BeKGuS*UYPEpQn@ScUe)jR4ONx~u{m|myi%EW|J_47^9!k2=#|Q9C*v%dn27?> zh^CZKxu{hUVOMfa>Oq%k%z<4bQZR<9FhHC6Z;(vL!Y1evF4V=LW4buAW|z@T8h@Az zkKYAdBnK>zK`?k?c#pPWxjtbb$d4$Fn?unDS9=xR$XE*YnZjb3@mI9c2F#uAFjB8x zil`Yr#{)+es)Nd`(UOe5l85iAO^Ny7D~6V!ICD9K(n_V-Zp|Dmv~o1Ga#XE||3Y9X z>bB4pp$I9aN~H&Z4x@$%OM=>Pe4^Cp_H+y?!YQI^*C{!nvnIK_gfq;)MM~i%G9&oX zvPx*BQ_s|2?Jy5WS8?X>>Y^np$=row6lCDunR>ZZN8e%M4x^Tbc|MSEs4LN$y6MI( zzhcG`()FOYS+=MWHaSv-E=#eraMi-)kN$m7$?HER<{5(_ixETccko0EpX^sNVM%xf$2FgP>NN-ro zXiuZnKM|aD=8K#sa!-kq5R3KLZLLA9Sl&#E?M`Nur_sroPIV4nok{PuW%XThWcO-` zYa}Gh z-Bgq^rw-&Jn~8`hZeWaWUL2EPJx~$}G-wQijb&DJFcsu3mF3`6(qqh_d4cIxl4V3y zAYN!Z^l1l^lI0zLikFKd2{W%L%;FZN{}hRlutDx=?8TnNxz$aUJ(SsH#*a~}d7bT? zYh#q5-C-VA1i`XG%(kM~DiIMy?<^Z`319p+%Ox6S>L=zQdx%_ise2;+XkwBIOVE`d zSz*wa>4i?F5#ylGqZV0|Ww%X0jLBBgRhhwVDWYsVQjR>cnsQPORozt` zD3XwE7`hUP4>6&feWnW!c+xE0t@t{Dpyj+XoZN|+J)7|cPgm~OW(x^T2S zzCxr0s(=RH_Wlcr7wMW$*`#6QkG8OH5OE4F~~6mYU0(Vb4+ zW{lVf-7C7%=#wBvWUWIS85!)j8=_C77H$`IC}n}iP3Q#z%#$R-NqZjkWC4iiq&bJT z(#||I)k$kiys?}$+-V$Bus$1RtKBNWP3@LU?I@uKsg;L&ywzN9ENw^oRCcwe8ZmEt zmbjc85>hS*2A&n@Ap{!GjyP1s1d-FeqDX)#|t( zlEl^YIuejAD^4*D>F%ycV@NgAAH?l!N;8h(k#Y|(^siHBeQ;ErhSgV1r*lfx5;!-y zfIM+c1{4WVN|4v8&QrB!7|h83Kt?I5y~?X{Q10-Fh+Hw~wU7oX%==c&;+F6M4$Cy` zZtX`Rj9M;xrVw<_^!VFu)~^S-6H>Kz1FQ`sl8uPBByRbj?wB#S7Upi-$w5fD8S zU59u(wn9NRuejT4axg)jnf*dsU;@!y$kCX7cRd}E9*l}GNg35{88mg2IuDmb|8I+j zMf8hkb5J&$Sc@q`_`?XA*~m;5u}o%DSneI&dl;!X&{cTC$|%7Y7%$NZbvk0oSODhA zToWlV-@!Su&IFwg67mSMp+-^V zAjwwB-`qAsJW})3O_ffQq-oa0Cb5QQS_YqbdFkQ3dr}G<=doC$|4}IqTX1Yxnjc>@ zhTthDx+>J*ph|+XQZX5BK3)hDsmI3}_2bsQ8^E+I0X*4(Bt@LEk8P+$;^j802r1m> zp$m|G>EXi%{8zCw_zu#)8|z(zjmRV_D66su#km4yiSE4BHUcOZPf>r^BwP81OS@>i zG1ZkN4zW37p3_<06UG6~!o1N|U%|;0d1yzx8LAOt#jIr)=(!c~%Er1N7oFxIshEX+ z|4*D?shm6t4^R5WY~ZEkrC7B#h%L zG#Z~Ro3G;57G9=;>dU0a#)rk1hG8#7@*6yokVl(Jp&ePG*VPxWown347XcbL^y!q<7ZYmf$*9V-wkMGx5-vpy1dK_3;?N%r z9jgQb**b*3ui~u9I=ov%68Dfe>?@WLS~(D0fE}2bAyl4~=}O%gwaQB*q6llb#Yw?K z*Z5oBW(?kYqQ=ZskJ_z)*CpZCh@32Ic9(*dn5pDorJ`nzS~HnYAfysCjYJE$psYb$ zXC+BsM_nbx4Th+sjRlCYchM8_uH`m_31|GK5Wx%KlIT!se5k5^t9smh%jkzjT~Q!F z6EfniXjb~17uh`%v_6-y9>Z`m5P)=(Cq5*U4Ps|8ZxS`_`4IRHSGe$z_?4WcY%bD> z{Fih~;5I9G6!+NNk;8PmC-Wq%or*u{M*dgGsbck;_k(( z^0?2E;FOs!5rh9L(Wy9?0T(vNG?G@n2thszMa-Fpu{1*E14o=%79)^Ep>)g{EZDgj zTQWCA3)?1AqqD?B!H*bl@I$2?f=eM@k!heWK=!oRgorM}W#f+#qShzt?wqnaDL!w#Pp^ncduQw9{Rn|YST)Cv(mf+jg zn7O=okQY!3W#S^QG`^ZiM}(5Vy&@{f_AAmpkM^5u$2(#+oN ztQ;67qnt{*YDo>W#I>qTl(mh%Lp7bDh#Bk_4Ubq;9Q0T;6r#Oi8r&paywJKmOI>dC zm5`vJh9l_AAnEKvDlx!ZjluM5EToyLCtHuTDc}mlI(>;gncjsp7v=PzulrFjQPM}o zu~v$NA<4|wnwV&+=22uwTi28Gkc+V75<`fIGh3vQDj|WaR_RQ>TxkXm+Ds!`?o;TN z;U04W{pwCmzDmSVjZV~hr-25_$u_K&8CG1iYRNW=ys!!bsjDNAIy6U~>fkJG7-eW# zQlaF=9HJl}qLO#J!3uV&8H;38Db!*pvfzkrEG_IxBu+iqMOPe)DqEm_%YGVM*pzJZ zno3VNIEplcr$F&XE_sSAK+y1!k?=V)3KL9|Nr6yw*?~j5Fq|vfr9Gh6?WEaAf+;(b zY^N%Kg4JYuqeEtgPFp(F{Jo;}W~{@SftYDBZ7aSZs%i4y@-DIb4h==-uHZ~~-A>V^ zh=qn2U$7?NZpgX~N;Sa#H*Qn;k# zsA62^^H>&(*c%qY+H`hdUTgHs!&iL*zHg&VHU=!=JXM?UxI}ce8X~NC>C|T+6L=xF zcGM}=J4_M6D%o;9rAR?Ju3`+c8NQk2jNXtnv>xp#iX`J|N^DgosTT-e{LA=76;2>x zID|RPB%! z`@w_!qS8>hzEpjgCWPDZOpZswfNV7PoJDg@*#bsCqbAgHjJaBqzAh<|PlPYW3c{+s z>t;BSSYWavpN##;y^bW2PBz=NGBX$u1--9d-BCjUC0HwQp=j~DNvgtFO)C3<17)6%u7N9+c>* zVVv*0yR0WQ^O{Alz6!W>ObcSOU;>$%vWAqWQV+O;nd}(IG^_LgoV2z65b2_7u1ui> z?8#iSx-=y+ER7EK2_$eHbhus<2bm9w@o%LzPRWq?S`~j#&AT?$(o7?MsuGA1qvJhj zC)+AosMrt8pw*OW;+agMse=aP#k`r2Mmy?}x;wzO^S?G#n52C6| zbOYjS*m@GNXBRBls^Ksl$SIu;2zB<%+Hg`6Q>!U;DqN>~I#`E?`3*NYRIIAnYR=b< zGT&t7X^yd2f$*xq5RlLnR?LPV+;rcOqKHAoWNo?|bzD!+**tb?8_q5qZs@}9@a8d0 zxz%OsHKK_LvydbK5h<^%KgQgPhOCTC!xs0bc=5|Oz8uBoNqhT2fj;D*otLy$+A_eo?_YOl-n=mnu^<$N$Zwb(Tf3W6`IxgMmH<# zhA*J1&O+&06k)hZ7wAe^*F3T{Mb3j&#+nJ9FLa{Jlbz=1N9h@s^2dmTa^IA2AYKez zZj*`$G(yw><~oXDU~D9jVMVmjwS0M(tF4exbvX_Fg*MZo>6N8x-9xyWV}l_&_Le zYPL;~V{ol!mR`k(QR)m@q+saM{v_tscDo)*+!Iif&zJpD4Q<;bDNIP`HIv93ZfaJK zFDOT})5UFXfs!pp- zlxa;%D4WoSsy##(9ug@k17qDVB2iC93tRG&aX$&!B&I!NR57iYU1ehF;Lfc(_U{On5g=u!PX2mKX)ZGfU_SXNw8q?+aY3=UWy?y7tLp#eos@gIdx%<5>-2VTj zzlAFP|4x4kxBtKCZ&((5H&IJ;p`I-@?o5S+$m(g7eKI`Y?`+9KP>cT?^bw7#;2Sve zWDkyhfvtuwc{xa_3e(EYlp6ISZFP-9G9?nm6P`R#h4n-t8q64lhlu{70*V$|y4Bj- zW|B_Dnt}Hs<8^tUZ+ao=t4i8#dvVLu%XuW+QuuP-iG~!Nh8Xn5Oh>9yTi;8MjY^cP z+`7`utz%<$xQ#<%ON?&$XIjL|r5IvGT~&Q2Mzg}gNOv6Ixa|pxE4jonUr~=@;?35l zu2YuLaFHumEYzv%FkOjkx^te953%lkt*Bt5PW4jL{KoEZ{=GyPrPOagMyOcL!s1As zLLt@#=`YJJaVFG3Vt4G$qtt~o?JhI+tY`m&OjRD{FrQh)Q_J_!tGOn+y_&lMyR-E` z=J|x)SoXl;B@;5L412>0tBD$EJeR0>OZh!=BS^mGCnhY3D>q>|w0V~*)E@Zy?evfp zOQjy&gaWc@%UfJjrCL}UQ@F+|%d%zRA)8m4l2ZtA4GOOOw$S@%nB_k#dgfiASZrCG z{jD|hEzucdvatC8LqT0WN#K6P)=AhABV~cmQqEi&ebixd*t9Av)GD)otykBJOpH?Fk>Mz+-2iTm}j|r$RBoDcAD6O zy8$eYZzvF>6`5V_HHD3w#VH8cQz*crtXxQ;VJRj4^W{FELaBCBaB}~wP6aEJ6$0{$ z@meh8n=chd08`0C63C|`s9`o#p-9A^BbT3X5S7WEiyl>#Bg6HAh$)Y(+V8oD1@F`5 zPze$E3tmud{aCOWwbYY%k>E;RX%Vyk?%NL{LUS$*ERN8a%o-NZ5Md?u?-V2Gv^#jNWJh9$!?KTyXg;y#B>xM}DobXKdd2Q-1i~mPVQe0EQl`Py5^xLk_}zt6)z~aGAy|#t z_3|i@xkLwkF~1T_Wu+a?IYAjwBX<%46JH@eOzk~H7uP$g=K}n#UXWNrK!@$o3q0&Ra2o9^p4?ze--z+pHnkaOzvLeMQs-m826l<^u zlX5$^myP&Dn6qp>Xk*ZAK7*x0m+#ryRD@nRVR2G8f0$@Ym#)ao3!9l`Sl43}`im1) zuN@876g(lD8pBI;6G1GJo}9Vjl<8P`!&?5^=+2FJBTR`!#==G8WTdqP3_~?HWxPC2 z;*FZxI*A#k-rM&w91{vvI>|7|p&6#keveNaAayuj62nCfycvB;nKUY}n_tNGD6>t< z^2IDdo=DmHse{<=D%ceDXUGi;c(Yn$TQEk+n__NZ@5ZI}PF5pD6LWFavN9vwH==r; zX=7O>_Ai5tV~e=6?i;?m8}p0mYw`k{$OxuL$>F0u!e$Ta){U^%i=e4wV2rhsnkEcu z^T1Rg0?nrKG1&f378VL55=k?1CGB{5SeVw>+vPKW+2#;p#RA2QpKmBA5WrlOUG^-j zCS4L2kMXo>#7pdfQI9Mj#XiLg^23D!Tz1Gj7-rq;EEwmy!IWBT)9%-_7?1E}!Ij>? z@3bqs1uIn{XS!kA<8-fsBlXCtqK2p?^$$kNdjSnmPC$)tIlYu#QI)6P2&HQI=f&w7 zHOXF8)CcpcehR^6V+0cv?vg_?153=3-8?DOFvsbRMwp7x=ob_uLYd6U0%B!HR*TYQ zb5sNs#hSkIX|fM5T3L{7uxW7?@Td)AsAa!pm{X(X2M>vOYvT zCQ&dlx=D70Z;_gsdnUerJJWRLn{j`kv~V~Jm%mjGvVh& zg&EbPg@Pm{2l)|_n_!X1gU;mrnU)s^Z>mm zq7n+3tQIOxz4S_?MTKGz`r5t+=30q(vzpgx8j7amT#zew&X-A;rJrKdELHZ?+n zyP4Go$QjAEiD=JD@{!`kcYSP(b~<|4k_PIsc6x?{(J3vqCaSm}uTf-=nl>|7^Dmj? zhBHwF_QJv0qoz8Gf-DWoQ5QB$Y_6mME1Ixzcw}@KnW8EZnMu_WZhdufp~uqr>5^y6 zN->yM3f(Jd=~K!2R|-AgM(+Vj&N?-sB1c6LdHvp6x2BLa%9}HAB&3p6Qu_1tw$>aS zpLN4N5M+q`&0)uB`!z@gLNxnbxjgx(*om?y!@wl}8)LNfoG)NxD%h4zy+nhYpQHkIY8{ zKg5}8tYnh-nfIkjltX zeAY>m&shZhE^I`pXE&M?Nn^;fL4(at0%e|*2eIanj|L5 zBB&ghJCLsE9Y?^du&vT`xu3<9n^%m%oE2Fn$VzqHezoAG5UGrAI9Kn)Z+3NvT*Y&t zvNCt#3C`lmUsPHC0`vR1#GqXS6^h1~yM8MceZd%nQlQRNRx=I#;6AW0Pgl7z$^@71 z9lko*ZB+uAEF8nQ4s6M4BomO8h7YzVx}gQIqR@e=Jba6J&Sep#sKl(eJ^MkmX_KXa zn|u$$fm09*B(B=4ym6`rU|R^6e@d28IR+tNQW5}AC8@|ZSe0%<)AO+9=1kRhK#~}o zWH<0>sFg=#t&{4WM>Y^pV_H4YVlg93J6|wq0w-F6TJY`5?Yab3DS?`bij>)o?1O*` z>6Wc4U9TdzFm7aqcmPQHN#qCtP1^DjEN{!oh{NQ1DfbWFf}Dd}kBvc-%9Cjv+{(ih zIYA?uWU{rc;%FqXZTJ*9J6x*!=$4g&Sj+BKi9{9al2r7(j(aLP50dgNAYwCX^?*#9 z%iCeAV|JJ+m1gVBd2Pd^j*-(6GDC00W{7C{tFc#AQHsa)Y_21EB~uh;)gl>%U?r;m zf2GOMf8in&%Dkf_DCE17JxUxNtZPYMy=F(* zO2s@(30dZqaZXmtCN*Kz0b(koFM>`92@CC6Y1Lis7mKii{E)VACRe1+DA+@FWGEGA zgZiDWgu0BQWd%iRHZPGd2gJpVeYJp_B@rYhy74zN^^3Tl63DJYEP&+3Siykz{e$2)^msFLs(BGIke{~8 zXK;hWriYXqK;&xSmsh+5J*Ro8_#?fLvtVE{rL3PTFEunnP1VIjy)GO*Z~nsNhJIe{ zLJj`B-i3q1KTnyI3+;)rBpF|L1I8ZMBaJGW{nnyhw)4@=g?BP`B^$#m7)pvFN?3F~ zq_O#;JLVoqe4Wt%{;hI!*THL&>9#|2wrK&BX&NyQZN8Ur3~~jFQH5xFSrhVGg+NZ)c&s3l4ELLZ_L z?3um38L3q^Vkmm5j4rZ2kaf#Q(z8f(G}{Rv7&$w5eB9XwQ>J(rr$M{orn^M2h4&Xk z88C_$EL{}+AfrA_6FuRDA&?`Y%-@5P>nrqY*xfeF0eH!J5iB;N=xVn6Q{YzYhGnh= zH?|WW0Az;gFf$l5Yih#M0hmt;-033xR0;S+9eOnzL>70kPys_!y$B1HR4gu{P^?8y ztk_CyulN*ciy!e$@q#2y5tLnP%;TDhXweC`1)xuN6@+2Adg`z_JY+Hrk2FDaSEpS- zc?q)nL|Y^*;!265_RCTGMMVVr2xZ!Ti{6YO6(@6DtIM{?}Z+zk=S~2fs z0d$k3Ru>@0pFn16c7#G8ieK7xnX);}AIW=dwbYqSvrH1s66%G$w$zm=r5$NCE42>m zQsdHK_#C4$Y*-?B8e`cYbU-G6fn$vs*?0UREartTTJLjYw@N_vwfUz@WQge^Es=Lb z__`@*R)J&!*1k*%=g%T#vaE2~7h&^j{}lE!xllu)LNsLUuVLb|90_X_*b>sIrF~=jKr-p@ea;^Gu)VcbG~mI3SUbT{5c`qA2id zHQT8`3O+JV6nTaYNmL6yhIzFB2WX0tNs&!r#*~wLL@&H@$1=&FTvext-M;*1S)Fl# zi#ijP@Zx>06_3;`MALI68xXB@C8wP|!8N~F20DxG$6T%Uaj{q(3UcLSwX;%_>q~*Q^N)v1Uz~LK=T%Qi#EX>CIL+b*XV6r=?dhWa3q_&d_vv}I()H4?4ZjQ z1{5XRTFdNugcv>GZDYxPh0PJ3ylFz~ZCN**XjPEBnB;&X8_SRFr?R75BwFRQttpCE z2D2kx>ze@2B668Q9Coz+>TruNuD)kvt`l@yThMm7hQ*$T2p{+P zj;(PZq#r{E{V0iNB{1VbTx%ILv^;Ms3#_CgpbWV|bPbm{oVHua1Nu9W? ziEA&)n%1CRqJ>x7+QC>{A)^_bdbGGbJW!G6J`lz-{&X`GrqnIfDB<-_<{0V?1cfFk z@{5lQ%M^lp1CObOf&w$H7+AK=A+jx4zI;coLXN82H{~z;SH!I)!76uvlPan znt#<>iZ8LvdXs%Tw8HWL7Nq(qdu@ZB!PPE;q-az-=7x7>B4tEfB6q1y;{ndtWaKWc z&eCD!y{ugwgO+iY4`Hq68{epj;&oY1H8X(`c1Yi`9h#*OtRpW;<&xr;aDC9vuKRQlYtorfu8J1kK<-cAxrTGTNQQ{HibC_=e=*&vf%b;TFPadebfXEf%I& zag9gboLgh-hjU(UP$@trqR`G&G$21KN&_@5c1cKw6s}XP1EI=p;S^tU1JAVxQ;826 zJZxzzqp@va0~FiELteceF-1+dmx@A$M1}EVVIJMOutF6gJ#FN2h$WKsLGs3GKL!$G`w%D=UpJ$~LSrdj@GAdE&8(P8yN;%?x^JVfquF9fw#CjQV=ca-TV zth#d-rFhcbv?}QomxFiO;5SADf`64cF7jGg{1Gv0E=bH<2MdD$l4|-w3%)ojbE{$y zWy`#2wTW;%ytMv68rCPy2*3udmw1M1Mi8Kykm$x`p_j0Ki)k0brEWw(Q=9Ia3(|GZ zD{S=*&f*~^Vy2waRm@s^5o8i{jqk(IU36#^nXk@?kp@YN!e$s|6~wouD~J>JlThav z2b-0nmP>tV4vn&X^JOVW3r(0E7NSgXX@j#xhLy$3Ee7Uf$+C-qUl+ZzLvd*zvF!%3 z=yk{CqX>)M>`^vM5u=Ct_ot!t<)bcozp#b0u>H+@GjU*>Xlh)N3$b=Li-lNX)JfZt znT!#gxr@t-nGNYWGYm66F9Zv+OecI`{$cS!i^mdIt1do2slok}GHX+4u%m6$6IX&x zB*Z14`}1twf*I`0Y;pS;8I`vG3<$POO3XM*4uv;zI$CHp#{2n-T!X9hnijq)@{IIE zRb#(6V`A=SteKOq@}KtdHtmsQduh4^I*@UawQ<1PAVv{)->}d_5OxS#nP3!SpzB1= zW9!Oeo=jRI&mdCNOg#8Uxz^`6NASc|6gHZnkic#wpXG8&dy-CciXibr) zz1fQmL2__qC$%=YR;)r6HDNDgk%iHbt3c2OH*fnk<@aA20M+UAWf8Nke5- z1eW-K#i+o^>2bZgqC@%>>{mH7OoK6wq=lRbp*xhz!|%#@XdG-M)?_n1--NX=`f|EG zKaa#mADcLl9X(gQ7U8KBZYjvSfDNqh!)jCSim7%>Gn3cjRs`Xw)P|CTl1aV*NrJ;% z3#6&GHt|GE<$&F+ETh^wRdK7Ns%_sA>SeoWh=!P~50eo3Gs&Brrz8N3%4}g&r{3?z zR1v81d)eSAI+C2TkO8#{yyxAvn3{-8QwSu6AhTO=I~VPG-guNP2E_Y(3HL3k4D8r z=mo9g(~h#CgH{EY&xTi18Flmu3j)NUd9op@mN>gBFd<3WkZsYJy~D^b3Ypl*4ACTd zQz(RAcW4>Es8Pd|v{Z$ho2yNDcSy}$sMfObF9V&|-j-%9`I;0Ft1Vjb-c#|TeX%-i zQmAZVt$K) zUCc@Fd-%vAgE%qfkvK8rw`8uUNZfj%2jmVV#y40)p9&Xx0e}%oR54!Tnf1UjIr(FX z$c<%0wtv5^R1gs=0MCvXwxOmXB@>%QMn?R$+=OLTm3NFzJL=yy2nnQQ<>+L*z0acJ zcqgn?le_M5JiCq8@3mMAwOhL^ingPiGGBs{3}i=kyKg}v(G6aTiR5f^Hbo?2aiB>v z%S_OPY&Bu%it`h4M%@!4`#i{pX?~n0-X_9G)O2EeNeTNgz?CX!iyOkP7~BJ1Ok$1X zg_P#9!tYD;zH3I4tH#*sPV{MAUk0Z(8)C=^E!wt8_f?`fk!K7RqRuS5KSu8wXP!ME zqfmX^85X{sFG^oFkyh1nA9ZTkEJ->M>X!u~7M3faO zBee*I*E~`5gKxdaxn>uI_~KsfH2+zmR12GBHkkRaNVgc~ql>6%@3h&PWI%SC-5^zs ze0Sukp%TmZAWqDrFbxNSJG#iU_rUoM-#l96l!xEEF<+JwUDztN;ykM>*eXy|9c^Q) zodRKbcs9D$T!JrU@dlT!xy4G)3NRIgq?=06U1im8JnGx5qWO#*8zd1}-E($&Sk97YF5}0%GR}E`m$@R?0WYMdH;f&8lT?X2Pv+UPd=R`q zm^ItmJd5v#+Drw~{N-)diqa$6FCkwL!0$?aGd~Eq$hS(5|MZk=^fH4O9LRW(1NS8{ z6yp=EPz+r-koWAIWs7sdgSEY?n{{S8f`Oo42%u7pNyRRAX^xh@I5@vHic|4?EnN}h zPP!xC6v%uEM7^XveTgDD@+h=lG$iC^<7kSl?XtWXyP-b!}lKibr=d5E><2MC1v#J}jZEYWWs^2E?3?#zf(gA;h&8 z8ill1ae%@@$Rhnr(+;PrNGk~Jkxfi3^u(6`Q7yUDmFO0|@s#)joU2{D%~Yr6$cxH} zut`A`-}!59vO7W&bN$-?YlE9 zj0HPoRkr7=x1a9{!m=Fdf5r6K;PP&9R*#?|DNb#YF3Ik7+secj`X<87l)vaLtY|G# z3eik+c9(WIjytj;PgMAPHP6j^GdMbsmK$LKU2q3PL21P#GT6@{=Cy#q>t{7}2vtSu z@@DC&Z5$OU!aZUy!O>@@Y+IFE9D~9(CUWJ#xr$Y*EAsXV6HPoh*1Pi*RXVu%3SA2W z(%xCJ!($D4@L7%?WpQPX5+j8xHKW#zrMSy2h*M+H>`JfQQ*X1*W)$g*5|(>%5TV&E zmSv7pvGm!zO}$U4A^GlXU8#|+f&~&vSOMV*udRtyfU$Ou(4$_)$;8J@d4?rW7&1!c zcj*OdBof?+R(?GTluD{ubaoo@mB=dIwoGE%0%MR|6#b^;d`}OaDGm_QOg&AZP_5p} z>;8-7U175VQ9c1y(T?q1Z>ya0I2HVp*St%m#{sOisyo-6dd4F2jmbA#!}!sHKv5f8 z=QzmolRP7+{h&4EJvdLsj^v$)!iv%&BKzVkrVilv+odH!NJUvj8MtpYKRX<_2p%U@(& zW&3@Ykzx|cci>0C?k@a%sx}5T_CU?&Ps>(OX;HLLnIjg$oCQt3PCLk_;9YYO0cEzJ zq9re#C7NnmVpvWitk&^rc{N(89NxWm=b^(}_Z~QU_~4O!+mR#j1xDoL^lmL&OcbBQ z2u&FleAN!>j@K`kBf;y~ZATzoq!mQ+%=MBfo@v2r?2>_XLbxXOCIwTdA@+miszra@ zatHtr9h1zZKXH-J;keafl6^A{DpV36_ITeSz0lY~a6Qzii7L$N(55N4QrXs&dUJ+3 zt^T4ZyxJC|X{#y_qw}T71u6vCa?Qe~9)Y#=kTiZwYuW;qR$bd&kZsi>dAL>Hy;6;T8ieMe#R+x;O&VeA;IhAe25Q|`GS;okm281Mu$PKvWq1eolWvgtb zhJ2x|U(j8h9O)t?CIBdIsJ{?eTtPPnQg*RE+Ek9~j$#gg&0p)SVYktT3)k45yg$=+ zwJ=(A6`o#sdx@j3CLpXv(tD*3D?t zLq=9+RZvJC%7$|xMVEh}Op!yOF}H%E+RlH_?+{a1t9PpNCcL8sWR_9LL((8rZ~MbWGp(ZH8={gY*0@|RpOu-$251q1%Swn?TIK?l5v z-8U*-tnqogWEnG#Y9zXi!?1Mq6+VP5xsn8vxn-n2$KFpK$(^GdqwG%!3{b!%=phF+ zgK=fVWXSU55#LH)t#CA4J~R*?f`dr;;X z-&$xpOE_kWcX_F}H7uvXV<{fSie|Xk-Wo73xhkPcONf+GzeP?Ci7A(d=Xz!?pdgTz zNk%GA*@uXfoo^lGv5Hv9s4_KBz;d)q`x21I*8uY>7h>hjP>m8=mpLZvsz;`OG-0-% zh0!(TzqV$>ekZP?{gzr1WPF#HM$=O1nuW9HGqw)PC6 zbNntEi^X$ki3A2uk20Xt(Q0O!x>F5lpjUc&zHbbqUM8L)8HJnHp3<(P;SCf@=_)lY zX2L&H!uQ0oBlLNZJ0WXCeG5r^e0kozA(3J?m-?Nizt4p}v6Bv|Lup->pH_WjKkc>P0SKH#sQ!a5+2&jFK%)v0F zPRW&FP2r(>FS$}%^|HgZZnR*MC>Ac}V%9$a@Lk}xrV*IR6HU>QxQ1W2x`clAkEIlUY# z%A8#$b51EoSNn~NWr+wD&Xl%T{F8RKyaDxpiaQC5I-cVdw(}CbBdSl8iyIxRCP;)7 zEB}*k?S*%N5$vVLcNtzodDs$sc)?|4tQ^c15NXR#jX=1pguOCtC!}o0%)AQF?T9T=Q@4$!4}{Vf zn$}#LM%U@dU6Q^GMry7;ag^gNEHn#5(i0(NNkQ6Lj&{8pa$ZBBX+G{JC ziDrhsJTVS51SWS&OL^Q}D323M&`5QcELS2PiO5pXsL*5~2e*&&okjJ7!UK9ohh{f( zY|S>pdd*JYGGR7(XCtM=_j7Zr%-$(`HEqhyhV1N=4M<1D<;5sXmgI19a0RpWgxyfu zTU{6)8QZjZ(*}DT4oEl}p1C8$m(uM#iKqy+7p{+~i~qqB$HNmxHmzSj@I*_$<%5W` zG8~AMVo19}9W?6+L{eI6IwrhnJx)mAX6X($dh_tFPZ<^iZcSE~rm2c%WFR4ICIW(J z6`~FM4(&cC zS0NY9g<)A(%?BTYRQ}jt|xNcF}Z^TyaA`*y{sN#^TB_6YehgMmR+a zLS97${U7(YuySaRri8UvGCwKc436sEs##ZuLrB9y;EbLoqqG~S%^%3qfcIi%#?tjm z3ie{GL^>l2kb&d41F;?sA9`T|gF98AM&ZT$M|Ca_))amV$j%}n_ETk~JgSNcdG(|0 zhcQ;EB$W!UNGOl;RcEzaf1RHl85=2$jF(0>rz0a1YQE`HtJ(M85 z55W}XP#V}W9)XvL`t4$bSs9Nxq`YIvRxEJ6sLhL~!H!q0D+59@E4<}11~4-w^{a<3 zzW%~%`|}h@+s02QB~>4jM_~(H$ums^wq!ck$dgAk*pl`4$_2;++~ zpHuHyYIop1I9*eOhs~#E!dA`tZpNHrvyzT&)L!}t7c{GAIn}WQ*-=3|MXFn>EQ%`J zYv2`JHCs#git5~TaxiH;2pYDO(Ccbcb6~aSZtdv>yHnb)NIN=&%6hdb4z->@?_t9b z4G)6UUhB~onAa|@%sFWury4CB!+Zw=;58y3XtZFt$#GR22KDBJI4=7X#~FC3O-v4p zTO`S1JRROe;~;N&igx%6;pRn558K#Xd2skt3n4?JRgeL67hXG2o*mFdN+yUDyOki8#u-+>q@GFdDgmYh)Vc&T%r#GO5pu%IZhRAM5UN?Pm?#D8=7{;)|v z`%w#}hl6gSz-Jh%lV$=>>Vd`n>l|cCksA5SF5{S*g@3|rM+unFPWIv(zIr{Jz7(pH zITU>dkjcU%WOEWj>ME*g*z(v9%5urr`)OG*_pq=wfyC83*l+Bc;9FnMSR&tv}N(9d1vg zXB^mH(vBL+Ih1w~a+*l5+PU>$Y485hj;-mX`zQA9KL6_d`*xnOhXpaE!@LNrORlZm znMijX*|R6zw{`DM_ITgBb@!gfZQZfs;LbybF5=SGOdmB?I$W>LE#Ifi{PwLW%4{U5 z6yD+$J@eIkv!9Zqwxo@p=6grC9URV|G?ChwGxm~7&XK|1s%LEX5{A-YcGKteZlp=6 zk3lD1fWcX1!=c`VM-J~QZOX6H2-$h1w38k6rFkdPP3)g^#(}1hHI~2}`vtYIiS)*e z3&$>y-Nn}nTj@pV=mlpyp>&BS>V%>zeN^eX@+LNhKXyj4%v&er>>z{Wow9EjLVWwiSS)1Jz!;Dg9@MM%kFHRY0GUrye7^0k&8(+}#c?dMsI%}DFeH&=$C zr|d|COvT>;inWh)eo3Z`AHt*fIoK*|PBgI5uhlQnC0RZrfkXsmW^C+*pmjiz)u z6XPwj9c2Fodaz~ak@)jcdyy*lpfm;o& z)72YjoHJ8xCPNXI`n6a-6ednohCOXht&IF(jqdQt+k1VsPqfaHG(whX+KA2hWKJ-M zD^A`*{v$T1-&g}RC+*~q;lXs=5SZB&T^=gRFp7|2*kmcSri71^kyQ)S=O*aHZoMpk z%s@skJ_eOuAPOKnO%%7M2YIlt50_0qia0ZuW1DpIt{E*J)mdHSEMZNosQ@U=GS{w5*yHQqqmI=6076pm>US+V%ZFP9m;a|AugqFhCxU_t`sn2OBI11&2<)lXX)a%~XL;r`rwkhYdJ(vf4NS&#g^c zYAJg+lns$pLohC+GufWIAl(65*Lee%$ak(vZg1I^t(l*(`A)wvceV}Y4qgHiDDj{u zUNLD+Lg(Zy*#zoMF-($acBfgrHC2W@0-_+ zt{-2&ZX_AqJi1}?`Z3`84I9^uCisR4w&l9g=qUg6bz^B{Q)wiA-JE?L#aj$#xiW69XM@$q$IqwABg4WpY!2-YOyWqmgA z*~n*8vSEDF=-B$PF*>$!<0dXzw_($0vU$V!`jHJA$415zmlaW3f;uJx%5@Q`2_PdE zqbSR408OZIo>wf+<(h;!lp4q+pC$~}BlDQ?FKyw!vN z>1V3f*=5*@nv^3(+;N20KdHCvm1TKI-;iH`w4nnRm(%R-NOVAZ!E2i&?GU}Bz}ncv zf6K?MCu!J-F~o#8g#{oTD05NxRnkbJ{8Ry0VI_`)J>yQkvnI*QD7`lUOI5fP)(be# zo?T9lfVE@w8={UA+xoz)U6df@^S*jy`7Ks#4jfG#!j-+Ylpg<<=}4xHO&8G@khr)* z6G@296u0DbK~kN@3CQB15iOIAR;EZ$h@?4L1YVApk#>F@grc!`Qmw7@EBER+|;SG}sku)U!DG4Bl99M7h{MO9g`eUKqcZ-gLh_i*-{4S z$2wqGAuQY)-&9H5b=~d8Rk+EvLy_U`#JU#@G)lpcM+3?ZYqD%B+`HAM!L+COL=-fD z<5T96j1ftwag9?uR7(gOLQ=j@Jmk95trkfF#fprZW68Fr&;m6G-3dN{;+t0dh=9-> zgNvL-K$cx!l-lW*;*ssa$Of;~v|=1U**{yHAq%!(BVwc|zYW%@!$db?9b)qFBM;H$ zB%&-MGqB59f0og!hdtOOl7>l^pS*?bcQ72#$@BEnDKqdA%nA9izgA@SQ%MOu!LRge z$AMD^J&?4py=-ZzOSjT%lqWBqtXQ09mkt=kT9*pjNWHoVlkuuF9qWX%6cm-j`i%lxoPHfx| z9{lyYeF zXjmcE=Fq({oOjIXHolR$II_r0CduG+$4QP9-H;2!#x6B7{5mvV?yM(E#W{{$G}A*k@lYLgcl z@*R0y>)YelP-rTO>Hm-VYo)acZY<_iQ*VYwX_l_MoLOT-E|N{E*g17<6T$}C~yg* zH)^F@){U*#J8F*1r6=!b$@PubaJi4drWSUwhy-qaK!?5F&B#e8ITkF9OwE}~8{PmA z^dJ(5c&$Z;A`aK4Tes~NmDp2zWX5FX@o23uBw5RNT{JH{T9zk6`Z%(S?E9l8OfiaI#{Rwx4E<1k@LFJb6rZM z4R}b}RZWq$EOV$aD5@oMLeXuJR4^C}*v0N9*;13u>FTCL2MKbTgWN!ltQZI|1Ng`} z@+t2mSCZ#_*IN7AUsW|tTESodTdc17e)iA$eb>*%BKQQ4pWN|Ya?7QW2^p-qPW24a zk!eA}Vy0@PrdbNk;+U6MC)6zakB)ndx1#!~un1}S0zL!W+9DF$*XUjDgp=)dZJ^q* z2YA3jNrlg1t6{ik2_=89>p8bl0?2y%iLe8S2^bMcELF%n(= z(`!rcTJd2pq1IK#c=Xbhl;)Db2nkAvOJ$MT^wZKL03xx(^|50o=d16>sKI-n`^=j^ zS$z?a5Mc%;N6gNB-v%j&c_N-?dv2eikYN-2 z-2_py$&q0VLPuGJmQYWJD`2gffc(!=7-Y~Hvtmq5Z&`0zZOFbsyNqovSyd95E4+sk z*vCaYdU`T@BH(!B#VE>htor;gmYBY5K%p6IF)UrXwP9w8bb)f&;ONZnhNiZGilmCk zWbvi1v=yew!!SHM=Wlv5qV3&Rf48?qaluH!B&8L1rEa_}AkK`sP~bmpBC!u+NPmVt ze+j-xz$ljzs+2R&$1_gOMI@A{%9lvU(KBFbX)VRr$&xTlEQiK`^Ju_-&1h}8b?!k7 zngIjWk`T_MYRoowJ;R>;Hg0sc0ecUKh~9xBd_L`c_vqK@5oDXBDZ#w4K;I{LHh4kV zyX+DCvaB>8q~zY(qmfzUoPIOsq@hFTFEgq5wEgMftJ@NTr`vIphJ%cHCqlSD#fkjX z#ktu7Qqqx=Eshea8IcUe4Cv{(@=o|MBwo}h@*JY^NJ*UZ)ag>UK~C6irITRE)O9?e zY4Ozh5Rws*q&A^KviW%GNvYQr^8QSte;0#F{-xxAx)O!G@aA76+Yu*e{fcE_{+IR= z#FSzio5C{VY^;Q>Z_OGGkc9XS22A6RFl3c~i_N9QlT<1ZmOIUIKf{*y(n@cfzWEoO zIxACKt9ogyGNk?jtxsJ&*vdz1j~*UF9*5*_kpCBfh)r+CIVjT3idC|%Y)6hN3W3?z zkeaJjB7$DEEYnMv^ccZdx;dOSJ72NSC5PKsP5$ddNv@IR&dlC%NC=<7dW3`or9)O> zcB2eeRbGt$#`N~~?deZ`5`-4t{dD^G(orV8zYhaodQT|(VD+3`IN|ZO$lW0=DsTuQ zhFBZv*xNuTEQ*?&K}9fj$EK9sh(ac_ACG|by)<8*T#iw7&PZ+p>_c@XiT@(UPw(EH zUc&U2IL=Ek2-t{&x7}Y!ZS2B$G)_7=>=vbaeXh@DQL>^yFA^n}97qX6O&^(SqA1FT zP{v2HSNQ7-z*5Cjn3U^XqAlEm8Rm`KN3QBdgQJ>NE`{4vzfZL%%Xr~ zaf~vFQ9H2Q9>zwpdI;eLB*Ndv zxF;R#r!#FKI$9XKI6Sk5unl2sGYbBd;HP4jSfK_Nz5&02ypUZSVHrCH&?qW})7p@u zU*vebPPCYX{8+TlkIsI5{@4?57qtC5Sg6{aHnE3*CC46!T{wEh`=BT zaR;G@Fo;qYuNEk+orshdf(vKw+M3bS#OU2o8M(o@Lxcv@wre3&Q zVn-i!lqh?$8Tl$&2kAq3UZEAEQ~-belAcK_(@&?LKfH5UcZVM7R#)6|73~aWA&s7Cz!S;7}U%Le6FCamM(Lrd&cnh%!pJ)Fij-+y=X97{-)yIIg& zBv(Bo7^q?&EQxe*XhgP(pIG>>N%k~kQ1F{2NRWU{v2NUqm511mg|U66Y-V0aABxwR z=u6T@UJ0hr!HNX+wj?pP`sx4S1gJ|uF7tPN2Fg~UIHbOu1{oii6W=LSQqN8NE?%p| z?%$b*J87QEnp7oVaZQSr>RMQhh*{>c?Y21L9RnQc`>vnsa!GqrkxnK&%$2+#jzITv z)$A^7dX~W^?F~zINm`|aKednJ#RwMCW7d8_g%3tesCs}K4KJ`?+n}&jC{IfpRxI3a z_9_s&SkKiR@HUrQ%94dOuhF&mPp(@Jbo=wE--kJyj#8Za|bt^%%!bI z325iLqq!tYR#uYX#qxD7FjMJia%eLt{$_#$azyw_B<;63*nzC2Lub~^LGkN!%L&p({(SwB4{bN&dSu@CHSjViZ~vx?fY~ zHJt$-Oo@@A#^@ph0?-GU8pvPDa7cpkvY2`~W2RT(RF8lql_U5Gokoz(f`UeJQ~ zl$RpIGqO@3Q<)v-3>I?ERSS&;>wlVB&tbxp14sZ#nqFu2f?T7J0aStfj)zcnO=dID z3>INENKPo2AywZTOof3+v69N5ZMZgwweR1Wu`^3w{A9$9nu(a|m3N3z1wF8_rAzvo zJ*LQ8)U0c|PAfZb)s$Z69qez@;RmGW$$(S#+4RztI7h{2pCDGQ&`oYfx;#|PNM#NJ z`H5UAwZ38A({G|UqBGf6*2tM-8f1lzR@Yk83817DSnmsI*)ORNq2o|5*EbQXje=^L zsR?7oA-6DQ9Y3K3@*&9s@q-DU7zYUoM3VT!zK+61aVXNvA@!Pvr!2o_1a0y{NLDo?hYU(E_JsZ>5mPYLs!!R|jO zNhU#t-~+smwc|mR&Y{vsWeC=OS+?2IU!8*qcjQn+5D7Mc>b9D$*%~3Qn`{Sjuo8w; zoQ{~uj7>3gY5!5eiZ^U9dXihQ6#Ly+l?7ofqWo51=Z{3=FUI_+tMMGyyk0eE$QVP*7 z5~8LrRg33SZunV4I*=JHRx-JDEV_i{mbf0gLKIhdpB<@4-bUaTBmJ0BoMJti3NZ52 z@kIy*@H(`i&urH-(qe!=C%0a{`4ex{R|G$7&599EPn3qhJG)Fe{Ac(?U<=f|0Ha?} zx&6gm@#_$j5^}ihqVH{W_u{YVS5C^dXF)Qz;}Ny>sz@W_+DYnhMq}aEY4l8Ti8jV;n1(Y*NrMKSF5=c%&E=95w8%~niFs2h8h&< zt_#k82wFTR*2uG4mU=9X>?>`4*$sm$rcK&ggEH(lM=*0Uh5>ZZf(r1z_c^5zT(QN^ zxN4asBw`2?!TN%cH%|Rq{M0{_wnqLC=knmoCiYFF^#>pr<${?yDn7&uF4@ZNVWr^q zw?a$GENd_pOw592t(;EI1Z3WcRH*Jt)B%vY$Tt)D%mv}z&Ts`O&e)4bW^`vm*!cQT zDjpr^;)Z~SGIWeY&6+5MWzuMoPJ-l3n)MQc%TGkik#y%D)9s>AR6XhjA%07ToSz;T z=JAD*Zz%-qnOJ5hw=X;c+z+qEi2JaRToz~b z5HPeb{uFld<4R|xM4eJv#Hr&j4$1Ay^Ks>YlNHtO$(0IWKYHNU^Kg;uc`6;0%mm>L z44;J#5;>8=+{@wc5Uw!Y#T8i#M4wykaEy)pT$TF5mn?3unW3Da+D`H#RiDIg4B`pC z1;P=InNQ#R_kc`X1;EQ{oNN}^S*klxil@X|MSS!e6Mg9i%h7;&3pE>n(&xdHk|wOV z1Z?OFt#(Z(R8}K$2ZOxcRJI&FC3#7Kef+9H$d5%!gs3Uw(NZ;qH&~EqA+RHeg~T0l zn_1wD!Zbag`3Wop-jd&y^r2*ptZ1hSPJacPIyoSGj`HES(e)BA#GeF@wTX4;Mb%2$ zXu~4*bY0gWJ2s42t#5)yY5rDGRWsv}6FE6%mNGm=f_+pjaLtt&iC!Jzzm3m=F+- zVUNyvvQSr1g~c-PR!K(*GyamB%c52KUtdV@7yN@|;{1`I6B_BZ3>6*-!G-xY>_4-MkI2xlb6Ea-H0t4XrQH+!(c3-7vTwS%qz#!qcIHyLTo#UIFY_45g!?2$Bgm zR0}9!a(gACTk3tU`*IS@7_uchT7(wt}k0#eU75%8Ew~z^+LX-cr>ldKF%+UZbU|>N(u;f9*A`{GC2rGph(RRD{ zKbud!#MOmh7BKtK={|NW38P9@_7K<1TOY}*Q=x~5OPYtpfaMkPMgv(INS6p4ddyKq zJ=}#Kk;-Sfe73Op9llPbO@|FD%jCJxA)yc?Qvc{^IXj{qjWT*@S~@#BnZ?7a4qvCH z&Z5KP@#~pR^O`MYPCuog2PV)Yclgh5an|KB;NlFb5+%kl z%XsB-_G($5^?2J&y9-zU^5n5JpFF5!k$Pi@iOD@l1UOJ06?UCBMehMq&Ac2LDtY{&LLf7!}fk&)Z*DsJR!WO|ch%39*HZL1mkU(!) zERn}Al9JdXgVF}bX8Jg&lQ^~+i^GcTBR^czyXV^sG>8viLsSR+^rK&1lhF{x2`$lQ z)t>dw+W;!(hs*6>UPF&&@s$I9EV1J?EVtegGsb}6`zJ~RU0n>sj?--Xvt}s+*qMel z4uie=7?U+iw2w{?3<=KDl*&N8nE+1+3h`6HCw&9P^e&oE##IO%Q|a?MWS~ z?H*M6)|mtZxNaG<(lkzIhVZ~RQ-=|Z{c^r&vX2z-$*+m(9lNK)bWdGb`MoT+Av;0a zhgmll9ULnly_^&E!#kM6DBE;}U$(lK$45`$!PD2Xua_Lr5Lf8}T`9YVV1t635IS!s z^hr;7Cr|}TrP?vl4VLD zZBU_7C%Hn-teDJI*$PkVC=^@iz8t4mSf1*GNOfZ3Quf2_6~ab}0r-abX_tTjIfmy{ z2T4Kf(H&o?jFoZrTjm!wUW@jcnA-d3lGs@GOSVWduhk^sp;spgi2$~RDnKWGr^=OS z;nSQxB0LA_(sR$`i_9ZuCOc6^`3Ib&@30|AMGvqFah?n)D9EOv1QGkJLw5p)QcUL- z1+8?Zvj0|t6ICl}ly&XA<>yzgPCx%dD`!oOe-^Hi#1X4XB$us`4ezxrGyZGv7;=zs zt4Qdo3g;H$5SEIt?4f*%)+U;PT-F}?e+ zyW9WjffEo^7lT}tcO7_F5%t#$yu1D1cHlv5+Sa|=*LPfZ(o7CX55|%{-CmyV=gH?9 zy@V9(1nm!nW+;^(NJFs`h`Jo7?57l00{-PGh0QlON%jb3+PTnzvLth)@e&b2=@E|an(9BmbQ~NwSq9U`kO`@ zt=X1m2jTMEX@!|>Xe_LC$_1^L6&B3*$RxYb9yNAgv>8J>=IB{YOb|fQ3E)jb9qj5` zRlYjCzppZlX&}}*-s^oz4u|nXaJtgw_N!kfSOP$}sQ*(x2 zbuj1jJ35yj7kio6$|A%%moO zb?ui!Dl;|ka)=uJdvN#+lF{_q%V=AqdDR#ikKOJd-wsNUXxU9`|K_mQ$!Kz?S9Wb} z%fhQCCooXoN;)XS%D%@!mT3YBGEcGc50|cQrXiYw1ghq!rYr2<6I?H0X5_qLz;?-N zxUJ%C`hZwwf3AciCjKy+$AlTW17o8O9C#plljI4W7Yk_VV0%Q9p)I2Wc-R^nYo!tm&_ ziHd><_=j?^RR0&-=oX+nmw^%agRSI-@ow@3)S4#80FksB26UJxG2p^Q?@?%GV*G#lA*cuUf5lgyOXN)0_O4ZR~pF zDx-qNffS?h9~Cx4%o4qx2B5Zue8caFxk$^&M`={YjLf=+A@m9-L6Z^p4&NIup0!rIAbysS7{7!~t=hln z{$Z0BV^J3?G$^UWcP0YL6Mi+l5B}r8(wpD&2tGsc9;rpJ7Q#Uikz0cmBstJHFEN#6 zAG75G0f0MUK^3T|j~JmeOh*??D62TrB4vd;bPt7Moccu?Eb+Nm7qYdX0}OCj0wHvMgf1i_R)V9DEKIxp8q0% zgJlc)fq#^vV;*q!YO}{OjJ3A9emjB*<>QtBv>+50B?u_GE?hvwqRu}~K$CJoC@8s; z?>7YwO&krVQI=S>{Iq(`c5IOv1HZ{bfgd9(K?0C8dLHtiW&lvHNFayR&6x2hlLi3I z@jlL1f_fENrd96=XxC~mIR|0wOEEUor+7}}+}$qJc`zH9W`;nJ*A&1a)uflQeM;mN zW%7<>K~CT%Y^hub7yl~vL&qQJM;pRhrt{b^p?0cT;hC|YoWkfWnce^G-CG<2eE9q| zw1Mv)-#$=mn>p~^uxHI%6bg^@<4s8&%~j29wGIv+TFmG@N(k-R{KKD4>2b@uAQEH& z|MPq#J0OF+?7HNFTuO-|K2ERCuk(J#3>Sn9O+B5e7ePDqqQxFF5wIR8LP~5qQvf9n zy_-lp4H03?MHYnud$E4N=P|(cDD;0sTl@0>!#x?v9aac=t!>JvFrQlX;id4pkvjz{ z@*KCD$TkO&fw92^$H)|AWru5pRmtI4o30v|RLg6zhM>cZE1A=Pa{ClI%}F7JX6ja~ z0ForT08%0{bOPF_aE}9TRbgU#uLzJIv)|6ouF{G}y}q5-A4V#wQZbsMAdR47a@8Pg z9Px_af@)XDsn1(1a`{P59Cx0pi9nwP5eknNs)?UziZ#<#XUsQD_nCte>^z~&ubkKWl!_p)Oua(suGG%3d0g**e2G=}_!=`PHkdGCvM`q? zB>#|OX3Zwo4`s_Ef{i^Mm6K51%?pX$2uqLO{3WrxUrn!&)N9D-iWOk|>{waw5A$I? zB5W-`tKyq?y2|59p%H_QtV>h9_!b;bDQ!V#vc|ta;8)dS}kI$caB>S9h ziG{&81mhV3X;$eV^F03EoJLb=n1|DAABvp5KF>akIFKLBr=Mn*b_Qzu52eIP3hRiN zwCMQcG%6MKHVhZ*7Pxg>{LJ!m9alIjofjohT*D27CL;uQ9ftq*#qr7FU`hG_pru4A zDIV@djzl9SkiLZk0DB^tCP}0Gcf3TC9Yz@qQcVj`Du>FQ9~@$p_GK;A_puX>ztm|t zkV0iD$FnJlT{1mM=A*^LoMNB+j_AVSCtw&4@+t4a4 z3wJu+PEN8f)nss!6D8NxPb|_#v=gx%lAzY2@#qahwUDhB%qQ|yPfitARE8?~UXAxh zo58f9G#SwZ?U14;+M0k3K{XxL6l z;q@BW+Ow*fejdq_CBihoh0cT5QnvW&STyoW-gR4e>~xoE4Ec~H`W)c{Nmn^2PeTb$ zKbSsnfU8zPISlGy{;yaaESyw2F?djax)R8Y?B1P8A80`1(u{wfUQ!40f*Wk+6FEn? z@bSshZNTA~)I`hTP1&S94h%;ko4j)N0!Y_p3EZp+m7^{!Jg#cEN41i ze&%C(W;*={1;vd(S-gG5fYkH(5tTT$72-r=&H!~44l5S4Y@33=nrRafJ<3O!dTULE zR@3UZw$N(GE)mHeXnXP;Dmj%6EJ+RLIG#zI|VeowGSRl_a1z6T%fL-H712v`x80?;_1SZ2WknOcQm z-Q~1(8E$AX)q7j77q5+YbNu-9szglDSgh0&UaQn!czL8&a;ynX+m{?t$IH~p-cyrR zV7VdV-t|2uvug74{6zWNQoqcD8z|wXKrfo^59kNKnPD-<-u$bQ+{&mTB}Ot&J~^|G z&^L?9j@dOIekl@`D_I~figgAgaXr%q5;hKS<9WD70Nr8v3b@nX=(biN)>*|*H79$V> z;^-QCg~67{`ym&CsipaE93pRIey8FJ6@BWt_ z@;jujn(}0AohoQ$iOeoU#wVH;jm`ZF*91toD#Zbs5VYW3w(=gIE^|2&vY?U1aG0%f z>3Nq5T;jlxh+Az8!UciQq*fkp-w6PEXj;=oa$tqf3j_0AgXye%t;gfrhbGSB@0sEH zi9{so+>sm1JPyB;M_j#=WDR1nN3p`xZD!Kos2m?h%2h1L87?G|K8etq)=}MZ0X>r| z_@*BS<)L|?h8JCCuxstho=JsF4AU@4Ii6|KA;`&pL_!Dh$Y0fr<2X86$Ra6N)8@`7FRrYI%$evN!S*QpW0G{E{Sq_qD+eo#d1TAD+3eZj z@k_Nz)Ch5-=bA^0HbzlH4RoP$dvJLv%-;32pn|v~M^?gzJ;8U&+67eCVjqUeqm6X; z8teg8Np&fv&4d2k)i5X@va6Rcvcqn19FNppNNS}bcrRCH~*8eWQd1(B(#ecC9dxW0oWMv<*9L}%F~ zL{yDxd>B}u7rI_@WRL}AyxXRcE^J*X?76t!2BF)F3>ge@%!*Qf_n)y+tO>#}UdWO; zTddlz@PoS*BinwHEmwz&;R#f%9O$S?m;8AWS!q0{MH#m)`**!~7$78$ds9(%-}^u=krN(WYZ?`(y|BcoCJMorO)giuo;z?FbiAVW++$>2Q3O-98P&G zkOeA5OQs(wX3ZxR>y6_#5mNTT6@sPS=yt)FhQ%9p%kULXbSELvuId<;)cv_?g{$|R zmCWE7LB4gct1(EGPPuMhXY%B);INNB`0>k+H%<7*2On$7KR)|-Jn0|nVBn8=mr5&i zs<+M98>}!!NZAgxL2z&WKupjQxp;htVr2xllYl}`@atg!DvQpaqNgqC!^TEr$}gD$ zHW3(-?Gk<_pahD#Z{4FF=awhXrKx+<(G<;~u0m!7LWH1L>WYH^&sf|j!S|5tqoM?q zT`Fc0k9^PH=(r$M`F8W1H@j7)bC&Vz7T$^@qSg%kv?pD%*W?Sy!WT00o!IaE)MF#b za!s((WH}*F0=P!e2C-&7GQU-%FRimr*`K~A;6-hR)+$d1e42AC89BTnSHtbMx)XC$ zpp3c+_YqQneVfue4xB`h9OvZn5PodKK^A$ZpnaZw@kN?&MI3m1>lit&tk20UW!eNn zE%+DHyUzJQeq>$Mlvpf{awSprdU9#4Fj?E2-c5hlKjYBk%wx?PNRk)vr|E!blb59= zS%(I-!_AC9y7LsLpQH42NEsUKCfUs|6h1gtU=%LWRh%LV{c>!ccCX~3Ra7lS!ibVC><4dqyk3H5D>g= z=~8i&Ri3;h<6Qf>XE&y``(m68Vd2<_r@vJ?x~nT6-eF5wPgwxJd5m-buQEwc1fmMC zT*g+`$``4D7|5A4HVom9QNilkRX^Zs00C1L^|jt|s&^0t(#q_t5h~Vo2f(!Z!W)^H zxmo0h!Y|ZQOfpzJ+E`g8%8Y?^L~1tSrFKw^?fhREw*AzeL7sN;-Moacv?!+6R%IGe z;p5(Ys+kC|T9ac((mdj&zN>*y-hkvur?xOeq$4(!0&wBXOEP!uB}`qa5{V9^DK;Y7 zydrw^y5#q0G+5=d5M;BW5lSz_;}(7~=ooD@Qccr~J7{F{cyYP~{Oc3Puv&(M^o;S7 zP!G*Xe9OogCY|%uq7Uf8;X%dZ{_$@XfAdfCyFk@yBBL%8UcG|cc^V>BMJ`<{KiFZA zn1_^zS-!BrhPN;ofnEs;S-Es^a-_=895JEtLL;Rxzji+Xd=Q9HC~_vkF(a>&Qdv~J zp=N@EJIX^Ft^&#{(O?)+$Bc33l`G;vRli-il7SEeWe|v}*`s2HRg=!NaJ6Y2kf)DxEU~$ z;Xo4^;|&mR6xHcF@Unnx#kE&npPXO$ssA~>0uSi#)1}Bt2a#C`I*BY`P=+7cjb#`g z6g#~_1pc+2#J`Y;9_3HVE7rWOy^jTmC-8DZcOD8dAUrZiHd;I!gWXQPvTqoBIazO= zIr(%D&CM1Sqbes3PEm}6z~1DmOd62*vOpq`VY@ZtA&4*0TRXHEI*vA6vQ#Ao?lsp? z(T?8V%T1WrxEPEx{h7jXIk``ef{r{=m~k|68~rXO*KWvAdD=1!ZBA&kd3$}Ynq=#h zFi`Bg$4QFQtMd=%*M9MnI5)e|W_2p76Q3?6*pY=O>dH=cyvX~=@2C-RqxR9a6a(8; z34!5rojViM*$P-EqvkRaPx)GTb)85IM3ZQ_b5f;HoMg^X5(k6~Wp3Gx;{la3Y%4x%C-WGLHjr;q-2y#>D69tINi4>E0CF$;{K z3{Ll+SPAk~3};#121($jU_8X5-~37KiYIW{E!i>b&(l+SaY(H-2Sk&?CN>u58eTXl zM2FaA#F)Ia8kJt1?tpW94Cg`|YA7QQw1Nq-`q3@_xDyS@m7kb zuvrmrd!HPgJwD(62H>pW2y`@vujX1ty@hM>_9P~V5;6+rhKC{^l9|}{)xSs1Ut^IO z4J?L7(qJT1P$%%bXR{}4i>+W8ef*@MymxyP*Fm8%7=kkf1^uPeL34T*PRyO`HNKvQ6 z$Ofx)UJHcA8k(L@FG))Q)yCq*Z$e+FIU%xhboSa;+`8=4Z}CYW9Z!XcgwJ~Vh z>GrhMfKKk(Sj?6;FrPL1lf%P<$L#C`D&_1Dd8~UY_9UA(YBN7bgh4;8oV!82%r-;_ zTW*hTjoKNtdWKfGyK7LN}>#3=9-6143ZXu+2X9E8_>LaUyzRPzv7wx|1Diark83EYLhCbxwx z-M~;`!Z^qTh@lheamj6RCaG+s`SigvkSC1T?yCR$-~RV|-u$||<-s#8{1g*=N=xkX z)i`B@TFJ$+Ye5YoaR5Of})wC-_V4UILsEAv9FO?R!5nJ_22Z}`|OU-51z zJy(${p=E$ctf_3qZ9;UAZ2JOMW&iS&#~kksCbM-LoB0GKgQPfpjgzv2*1;6NPg*%( z3Ge`%L~eT6aQczbc|8KgZ#aF+=uOA{=Iv)EbnQ}#W`$h!$5J`GYD#IkF$r%9BcLo3 zWy7XYS-zt@VrAba3`fn_usg?hL(_HuhQMsxfW+>)22rEaa%QuPqhcPT&{R0eDbvby zS#xJgBcyoj&!Y5e38?42c<|?sXZ_!YXB@MfU2|nMrK=-^#|EN$L8GuGu~`y=dI@l3 zmo|GCL~mYzrsPBfqBM(n#(gU}@5-l>er<6|s|()XXdS6L2b>@ki&l1bQ`g-H0}yfN zwzoWx6oCGLC$VKUODQH>CPU;b6oaPQv^sytYz2W*&O9hMIIu3rK17eK+c1qvK{-oV$ zomkYZ5=L?_I`TFDq{!~I@7+I}Q&DrQF`?q0_q6~TQ~%xm6P?SfNYW8mKUnKR5u#^I zgd_Ma$1|7Lp5Y!DhC;?uLxeHK7-2ZY99S5X-3@|>b-D<@#9_rZUs~PXsKb2&`s-7H zr24zvLk09*>{zFf0+IOK$9cfcA_Q(4r*%&hlVN;iD`^XYw!W+%G@&O&@Dq?C{k+el zQYKi^okp7aONV^x?D|eQGIeRCTM%Kt9Fjf(Ppu*NuDZy^`7YLTipYv_K+oyLi^$Dp zoDwvHoQCgdGc5=rR0;cOxU!qu5Y^MuuJAFKZy z6eg`n`O(R_1aA~(u>>@}6Fwp=4t(HfaYJH@V|W-L;1(x4$n((xSjnjWo9yO;X#EzQ z;O5N<;8}#WaNtJtZfr8)X1V0TMZrN5Bg`lV=nJgS5xgiDav7sQdGpDFQ@z-lVn_p81wxW9j z+b3CR*Lsb$Dfimdb1Xom!La7q-J(M%8hIyVsz17&F^>Co;NlRha>tJF?(b!e4ObVby9rD(a80KBr2bG{~TMg=GmfL z+8<6*S_rd%Lmf{~wWexVzB`hECFIquhxf#OwNH|l*c6z6w?#NO7r4mKZWhz6BPY)P7BK!+s` zvg~%q@)w~^S%_r-x=J9OWA}0PcUf&Ld$dFiDQqj2uw7r&67^(`Zwl3lpxec;?z<4E zxFLoeHp`Gw7)cwvg-Ep|l4yo@zm7KaYtccdL?CIfWxig+Z_NWk%6w)nlI~l?+)LTa ziO{l_)ZEi)jEm*$>EnME#FPgfEEI@GF_7=0QVf~4$bo8fZ+)@1>l+n)=V^VPWUU~Z z;d}_xfi?+FRG88gTH;CwqVNyto;1Ei*VW|l@tg0LIE8vG#Zai72yQ|Zd{d>b&~2b7 zvd&l^R-E(*gSH;Bj`LPR`0_?sqhDl%Sa32LLz=!Ff<4%*brr9oomn>Gycr)s;qUdEXk}NpW8W)6qeBuS6`RdV&Z$hNn;$j7vj2BTC$en)7 zXiMzk=9VcZshatmn!F5u_*J=FkPW&A59fDb+qDf`R5(vdE}f`dHf!@j3se47wBN;9 zuFX2u!jDoJiiEZ>wb^le^xw2iN7IwU>r7;I$si`Tn0`qH8HmWIbcsO`8XxF7)h6>Y zfx_99aRzw8G?#&fheD_Ifld2ac$et=ndHlik<;mAZpp>pI+LE4z#onTX#p7ibMhzQ zwJu^ViecC&Qma9@@iS!P{P=a7j>s7^NgboIe$Z_{d3M$qYC3RA9C*j7WCD^XyNS@$ zJ1Nq1N7&@}k-2Im@|>$`(a;&^>6CJN{#<=&l@?HhP;qBCwOl*NpgK%#Y?lhpk>Ec# zq-O#8Tx=D&-pav$S$a~`(RK-&O~JX<_pzQlOwoPi*#(-a)rKmWs6IsN^-cp05~AIf z7B@rDp2<3l=ZgC6;;dJmFt#v0xQQek`i}5E`3_l35My$q$gqROPHn*@iIq(#DO|@w zX}F?4I#ao;H~`n#jgPKgy{fxdRma|u>}XM+l+Xh8Q8uzpa#U5R=3W?1zYpHhKoL;N|4_Sg^`w>B}ykaH6KFavZ*6IO5Que^L^lA=_Eox?E zjd1sxwW1{p!1V&)fW_|Y|I813duPM4g$4|KB{G){^vpji-5Bd$g<@Ewz2q^k%=f@{)KK3-+KBwO&sJ!J(wXjT8b_(G`SWsBcDGGx(viXP={#1&?fe>e*9oO(Lk`)b!d3urGK!K&e;q1$^8MP8^w+7j~q*7L)MM(r{Rad4(lp6Cx z^ky9l?aR!t)uK$)%m$WAogCGHYspq{w2Tu3)L;s*`#y_AO1O;bD^dej(3ePnNS4w) zQE-J!EF8~5QYsqp8AXa+PIU?Ye6@#*G!b&V0!|3Ou--}hf#T{TC@B>Qw#KUdLJaid zxAiG{`lxhz`Kq939Jt2dr=qA3e?lyYZ@TT1PKooate#1ev zl(Gvvm&ylZ9MDp|F6tbcz0E>AN7Ym+pJEP~Dj7b6rxYf>z(|h>7wnd$w&8@DaPxv)9pF*DK`SgIwmp$)Nl2f( zV6*yl*KnC&`KWDmr9Sv+2(2jq3d_Yg)6@F_upXW&tU5xk$`q{=pLxh|sI&x8*TbSl zsl|)0SGQMVR<$LEP5kWYk3=h2)3Y2UfB9UnRN*T*DmC@ef>~cMKqRWilN5BX^8!x1 z54$_Nye^#emZArxpgz|G$Mn@lZWItdVAkwSUwugP02aLD!vQ7(ED35s&wK1EJ}*v| zm)`t-dD$D~xUfqlE-jXq|3mZKvf)@CMOrAy7y%NIX5_<-$xZ-y<*c&aGLR5EnB}5C zvgtAG&C6ggP@1%J$jtzmVcDmG*-VEibrJ$y$H3<-Sb+vh4*Y{nk?9I3uX4mJxyv!8RRi)ONs`bA4+2EaeW5Vwik72&)uLB`i=nGiv5NjjS{(nL8SNjn9fQbgbcZ)njDDQLCH6?cGvD za9%*#un=AzzPz#b^Q#J=HF=(91#?nwJR=6G6B4x{RmKhUINCRg)qo9S3bs2?G_H@LHdbFesCGrz?7MNiIwcP_(JFc0*rSUbN zmne0$p}6F6dg$`1%Nfl9i*!DEbi#%VyiO9F8p5ir@?;wSmTG*A2)3s7mM~XcRa(0ZJW^)QgE&nGox)s7TLA zuR{R0vK`q`f{Pdq?XO zmKdK_cc-XybrU400tpc5xc+MNoV9(~G!|q_XLo7)D@o$59JAemZPjO>SY~|mo0cfT za+B1l@>sB$*NDBP`AO8o@R>#Ns-ZdpJ5!g#@)xlP+9;g;&5Kf3>Qm-qgjE%2ko)FF zU0cjiCt67MeUG$w4m1vn+dY-kh?nm{VY)ub8` zN){w;Nz%jyYnCx4J6JMcV0uaLG?!6!*yOb&F5P4s>N*t>H#CgeIt7ozc$WM}XeykhOwACO`zN5WtaFIJK%1Vt`F{WCIQCScZsRj0 zR_S}SPp!OENK?ivOazgvRV;i5G%{A)LlYQK#b$9Vw5$gmR|to!w!+W(&ecO%g?P)meHc_!mIoMZf}ir3ui=jx}>{a);u_8HcPRX+2cG z&N(b7u}RpeFc}L_u2GqC354lQitObbw{JMykecOolL1RSltj1~rz@Z)_cPhv18dEO zjQ0Q}DG$WVAAN@;aoGlb(3X2h*_G{5HYQ@`n|@zjo;>7$ApV0tweIt_`hx)jyf~$~ zyXM*1^Wz`A*I587Aoo^qaQWOey;KVT6D!x%Qx7YJT$S^N zSZ7Psfs-X{ljV9>B#EGWwsvvwN$P<09P z+e)&zOryg%#bf6@NuDAzfZU!XjYINSQ}zJDy^T4BfAv7gDUIuJci0-t>4*70PyPMo3>|JB(R zs+YQK(9a#I~F>dEwqch#k?N{*mW!1;5i z7B>xZK)5hLf)+r8XL7H6FRJIK!l8&YK9Y~6meS?^1`-N)pg$~hoRQcw1IF$;4q8@) ztvaqynx)Xt^w>fP*v6JhN7`9Sh4a$oJdSRU@TH}%e7_-UF$g*h7^Y^22;4(KXxkC9 z*$D~J@ZaqG1@;QcLoIQnuUQjwzxo@sBd8ewNuI2Bb&yor1h|bXI(61)=60DZ)YW6~ zjZ#cR<2|V0SC!eCCMwY2*EEGN(1xvPg~q;|%6tk&QFBZIK-i-4J!pDJ&4&Kwl5ASO zA3B*%kg zmoQA_cf~q0ED+Q>ohPOY7$7y+P=cQi5%a5nCQ%Qr{f@*=${9x_xc;e*$A8iY_LZ1#Qu7L&0MrN zrmPHMR#~|N=?XxgzZ5kne|&X_iJWXoT$pZaIz5-3Q+f?c)i^B$9xV2sgj0OG)RHtf z>_M96ST>Sy$fq}dJUizMB?}sKx+vs$@k+f|Oq%66N?4MsfH)!DK$J^06mwQqbjAub zkl1GDs3O?LATjEu^&Vzcc9NCNr=_bLHFqb8<8N1BGp3k6tf33Wrfw|((p~vA)rFAA zoyKTiyuN!x&B*ENU(u>V;}Y@`Q>0lvdyvz%9ga|^@5>!$OC3+!tyhFISq+G#eR#We z+nCj42Q^M0G;&=2LTTl*LzN@e9lP)jBBuW;>m{iNnBI?iNp-B8-sDE*>})EY5B z2=Y~h5?fhVP*&eC>dS_*SLiO`xkMeAj-tv2kK6bx2cTu;l%7t1{oui_2u;Mh4yA#W zV|6X*%EF0yVrGa?)iA$&v{wQ|8lkUXMkjNqgq%OF>d6KGhL?(Z9E zU>lI0&zIv~9ctSD;p~gW>+P%8KKkWHAG%1Ny?E4*!7&iB_9)j)W1m4w=;BL_dw&0* zaa_-FT>a?hKkvqoy*h@e)#h%S#Ywb$8QnZI>bw_ zX{ew#hG~c!2Ipz~;)~WQA_vibk7ws&q4N8!8Wyan0J|s&svNAa*?7RBaYm*>gh2fv=o1$uh82k}YeN>*Z`06m zv465H-FksxqXkd1tv_UprL#pJUPR*R3~w!S9u5sXKSVnAEJF>)F$SsMs_PycZRuvs z5NVk+re`As!qxDQu8jjm2de-^VaYfymuU<0>2JfSxBPO~Vg{XdfMgQX5Frq?#b3jDi(y%NM6BNK07~BN~dto)hCtPe@sHD@`qxAoxx#* zR<)}i&^u3$WKfQ%dnYRu%+=Gesj5WA%VN3Mky@=y`kb9{cU}z%ZPehJQXuv`2!d|1 zmtaRZC&E#N6Lt}o79AC>SrI(Jv%ascv?2PI^0r_D7!`;ujEfp*BZQLik1BW!l1B5a zNmsc!(d)XBn8|?APdbsx=S>0W_BG;-u5FWE>rDjo&&{X%XYq#&4&?Ks#LhsY7u)Rc z5pD{to({JAb9kfC6PP}T#BrSyUt~O4l}&43C_u6q|C)Sr_?rGv2g^y;`c8DT)kG^e zc|lWd{_}ij`aemf_DIWCe=H|Oxe_NSsU`x>cxyiieFs^SjSD2WWHS5DV7y$iN5E>! z$#6O)A31XXe$)pg;be0Y{`A_%KTRA@GL%Y356-dNO5C1DSzU!wWrR4vuoDt(n!7W z44il!BzOv*g>hY}9JnDy`t;4%-|qbE{JORAm62@_?h*O~m++oY+npW@PDOKXeLcip8fEvD_yctm$$Tbs-+nvP4i zF4iqX@=;_`WxQD1B~?~SjCL>Y_Q7Z;oP@z;!=1M0>}zFdG<>lxs1u8))-7@&RS%M- zFeTc-;bP3Ym%6&4V>CQaiB2h@58WeaohYx2$oW{CRq2B&&ckx>um_DhP=i4So`MHH zY?JT7*%>+aJDvx7^mS_snxGH6UaLjQ4k>qg&Kv#$6`E#*ubTnDqjs04c;c`Knif3G?}KXRr{K}x(UXFp1?&J{0rr9#N);qa@J{d;a2Lo>gKvOs;J<+C|Iw3! z;8oycQ02P76Tm)DUw05pM<6?g}skz7eFU;6vca z;8(y9{GG?67|aCXGr_~a`QVA*MLzuskJos-2|R%N?*m^7-UsdnZUqkl9|!ptJk1}? z*RMd;e+ZpXzGJ|1!IMCZdk7SLt_L;#`+WRUp!)kAQ2F+O$VY+4fy#ddcqq66R6qJb z%~KH+-8O)lpIbq-`!P`EKko5M9)AQX--{sff#5Nq%AX3V-E+Xh!OK9kR|YlD*MREp zZ9e{S@Cf2x09F2gIhWD0-{~Rqs0RW#Ek-ZwEE*2f_UnL0!4pC8#r>eh_b{mW-wCSU-vD0>{v1?4e(f=s=H};M zP~{Hy7=jwd>7d#>6FeAv*yC=GUj$X(w?MW3V^Hn=8dUiMrn`1u3F`h)p!nfLAD;;F zFKFYB=6}%R<=`ubzY$csn?a4|4ji?x4 z2Rs%%UIB{kSA!bQJ3!6LJ)q|8VNi721&U8U2dW=m0*?g$6+9Yzai=SH9H{)0z(c@k zpy<#Aik^MoMDQ9=`5yMT6MQrAr$P1S9Ec!14^;nGf~xQJpvGSS#V6N*qU(*|zTmx} z`tzWVe+pDPp93|2Uj{XAP<*=H8mv@_zeTU9- z^ga?)J*R@|=QMBHu(D+L5*t*cp`Y0$4`PM6aQ!M)!_c~-MCsn#V-K0PTmZj z0d58-f}ip6pM#JfIF-p_ih@C~06qY|7Cdr+>sJ=kd~5*F_p8uz{6@!)Qc-v&jOKY-$k35#6(WKj9rLD6}MPwxkn zuk7(gfB$|^e6Sl7Uw+fy|0TFT@dN3+`gJI%_D%uS-wsgyoDFJS^n&8UBDf#;W-tR@ z4PFNR1XO*C&UN)I2gTogpwh1dMW46%`*(noiEjm84Sow$KleG$>A&MaM0ju#cmVi1 zQ2p!&wI0`lkUV$@)cpS&D84*$iL)!u1kWUX2{;kF1x$laf|}>!mO4JV3~VF*R#5dl z0`f2T5B`MUf@O|B20>Ui_z>6u{uC5_!tpZx3h+?yQc(TOdn|#65nl(Y{M*40d<0a#zYMCre*pIb ze+X(^KLclie*)FcnHRWm%?A}<0;=7ML6z?VRbLKN`|H8O!8d}U*Ug~D`yNpF-tW^N z0AEJ@qu_U61RsM(5WnLhH{Xweoy0#4ihutMo(L|v*wG~qir#MpXMxxG_|qQ0=<%x_ zzYUhj_kB?PxabmxeID~3hdo{ms{Sn=-vcfoeiwKa_*0N63MRhJ@%5WQSS)xSI1&6g zcno;trEVTNK$3!mpwjOJ+rXzl<^L53$%9uRe6$XVAgmZ{0~dn(z25CZmw~4fe+$?F zei&4~?|`epcK&b~+yX+f;8)-b@Z26}CvO6$5q}KSJpC9v4g61VK6qN%@l(#@TR_q4 zCh!&D`+WMtKK&D*_~IF`AN&TW_Gb4wzFOz;&ES2cUkxJKf=PYO&Z>gy&x1bx58#Ew z523Piz%^hy_z_U@`8(hV;Cv#IGyS0YRRqrhH-YDZPl1vf69ydJjs{zZF9y~A22gZ= z8axjC88`=g>7bJj=Yo@nZw9A;JHQn91F#c3Y>k_TW#DAuSAeep?+4Y7ANceWvyLuH zz@tfj1e6?q1{D9l_zjLf4h0tzKNUP1EP%?l71TWc$m6kV-FjFK-b(tNp!z*6=hj6T zJc{_$psgqHmBb(O_yzDp;@<()elX-o3Z{xqPIQBZ5x>-95!{dX)!+p129NIsk0gFK_#n6wlzi*G z++oGzwV>wxHc;(<1Uwyl0u-Hp2)-B$N^V^Hf}+PM-~r%SAWI{d4~ic5fd_)01t)_w zP<-(RP~$(k?Ch@af!!E zK+$;(sBv8mz7%{6JQ@51_zLj*;344eK#k*oH@f_@z*)rK3aZ>LP;~h`sQf<3_SC#ZXVAA&mjH=Q2c&3D7riZ9u58iTn-+% z(babeD0;jd)couL=YfY_>FQYp&Lw^$C^|d~P63a&%FW|EQ0prV?hmd3wJwXG=5;5i ze*P5Hc+cA8#DfBe;suZKXb?*~0T3u?aq9n`r01ghObuW{o& z8WcTG@p!RM-wgJX{$5ag`e*Pc@bGJ0yailMybIL$?)T|m_US(cFCl&Lb7yKBgasD2BEx71y&K|lQlsxz_csBSoa0z(C+g-js z@B-r7LGi&sH@I=m0uLvCIe0vH9jJCc2x@$v1qZ=@1eI^$jZS}D2A)d%4sas)X;ACr zr{KBZe}c2YbKl|YtLs74x7p(ZpzePHTm=3ZJP2I4*|onCJdt<>6koj?lsx${I0rmo zi=)Hq!5PFK0vCcm09(M+O_T*M1=XJsunHb~v)gCh0%|_?xdq=9co}#**#1s8p1%b} zkKcmlfQP@!>HCYoyNGWEXMxLab@TQPQ0wL%@DT8upy>D$umha%ZYNLXfYXTgg3A9M z@NDo|Q2Af}9;d%s!IOz!25SDV1kVJY^y&Ww&L@84ZI1sh1+~r|1Vx9Rfa+iSdmR=) z(f1+nG;k;QO7Oejf#7dJjZ;K80+Q2D+Iiavh?XMxi`0L{S5!PkKQ2A&9Z-0keyRp0{R*MUpHXTcCW_8v#a*emCH+Wjo3{?xz;;5R|F|9$WT@JFENc)&;9cn=1Z?=Vp5 z$Ad2ePXS*9>Ks({>-SIg*Xg54y6Jz2gy4AMe*<0yGL+y^!o`U^Cv*K8!skd|OVDpB z@uLaf<@yFoakAh|q-`MRx6VQEH1W-ZvX2jf;>))ZR{6a9f?8YaLCNmF0T&Z`xE=sjf0DR z>${S)*<5Rm_4_Q>QwZhRZ^&v{DZC*FCrT`|`lyU2Gv*PFnF;9BrR ze^2l(!p8~sD8lcTgq`FmSqy#6^&JHLK26v__;=y5vuZhtNK6#0h;(QlEzIFhth zt|t*@aD7IU0bHNBmL5(1ensRg(%wc`%ykODL2-gxnoFF-wA-sk#f%LZ$N`waprxWzM3fv6-ny`hC^XX@MdC*^D5%hc9r%Q%KzvceoN8r=``pe+CDx{sHU--|g>D1aG&y*a_fAh(AlXoPd}P zP6VT03l~oip7aSX65fA3l1Um|?P-xoYc zc&)$xp+x$TT)%wCdN3HK4MC+tVs-w{qDoJ?3j+F^vJxYn;gSVK6S za2Mef+r-MR2XZ_jVHY^@(pJ z?VW@^;_oL6`*gt)(#wS3aoz3HPXI&GUP-u`px-W!pXIupFom#{px=dr?Sz*QzDLk+ zyU+g!*H3Xh7n}n=M7WjkBtgG4VWGcX39j?kZ}IpY?*D*r2jQ!P=yxFZ|1*k!uOfap z;Tt~f5MO>G@lLM$ef-bFk0xA7{A1uF;Gy6=@KfL}LLb*{1pPkb(IS&4FUq9*v-!a? zkDyJSysSFZn<=^L6`67|(^m=e=^^fi#ZtPjlI_d5o2$y1FdYtN^8J}oDxaxVO6go! zt_WW{Y53OE|xjMi zvp!RtV zCG4i-*@0oJE2^ZF&JSkF;Xt7jmaD~Lp;XEAhs%d6YiOW9TdtI{z10e>m4o)FZ5^q$ z_SDoFx}273YvZ54Y)`dM)8+Kk)S0QaGu@@~c5pfE%#OCHL3_uvX=luA4?0@H3(~o4 zf4U;_i4aROl{C?G*qfmnnXp*x&1K7LxE)Mu30IYsZ{_-I-YDm92Au=hT&A<9ECRF? zhkL?urnHWMRMr=mlk8BsG#n08^UMu>?+iMNnPO+pw2m1)VYeG*&{@h1boMN*<|^4# zM2*F64$3|LZhxlSSIQPuNvf}quVnI-RAsoBNfj(Dookk{es9)rp;`)y>Atn;!OWas zZdk}?QaO#JTphA5GKcHeq$@^;B)P->LZ;k8iE?(Rn1d#z!W-baU~V6*#wZ;N^;WaF z3Ke8BFu>gYex}Y1bb8y2o|bT8XR*}T(>|lEXOh3WqHFH_rCs4*HQS$w?oT_Tejg4i z)8E1R&8gGk!sWi~+H57IM&ZXoxHdB!^{X6JHoar2%dbhBTP&{24A(hJg&akq(e(Fc zMOzk0zEH{77@~wyrVQ~It-2m1I#!>X%NfB6a8D^5$Yyf=()s?rf+(pBxlActq4ZFpznW85lGQfkUSCQV zi}WVWnGes0tJY;R>$Omq8xM#m>Wo`o!CcmGB2RBNFRsmOfX%ePX%5N^U!hXVhnFvo z7zy5RLO~h&!*T((V#LK_F5Ab5S-8E`e7|)!k=CCnN-X93hQpzBo+%!JnJHDu=0aBP znf1#V!Q4{cns7-rU)>PQt@dXrl;L8qituq+tH_5ENrF^nD4oqIQW#20dN7f;wxMLG zMMFJ>YB|iZd*g|Qry#N5;woa4ycu-cdu`X1e?&w$OA zBZMzD>fVL4URYlqr{qw&@BHrIoDxIR=#2N7yGXufHe~v$m2__|({O;Bji@KHs^Wbu%K3FJNu5_eSRHWRu2IdIn z<Ak{7j7 zQ^{n^1`G(MD4LnXO$H8E_DLq#P;yn+CeemM(zFt9(m<`z(bZtn>6oYL3qEl&oxoSTYF)Ohg_E&9n_`^V%&BlRWBWZB${^Wq*=YnFl67_g&7 z{aQb*94kE)(C{)9+R0-RvmTrtSnT#K;YqfXP6}VwcG>Dq^4N|t>?sZ-D+UTZtI^*! z%~{?EitY}S3RuI)R&U#8SP)oL(S0YKSYwh5zKoYxEJZ{*U4lBSZxd=hN2V0zReQ^` zNcMFNDJ5pm1QrB#-Bd>Fi)`I7i5JZ49+Q^Fs>gy1%cZ`s0z-|-;BKd}X0;C(bK9AQ zi#6JD??#)D(VcYZW2%fa9m1(nf;>*2G&CK{@I;kSnyp7S`+kd*%#_N$t!&&^D(-ReI%y6OYWy4v9mI*TUS4{+Koz82Wclzn|EmFMQ zIyaq<#OaJ65t$jBTV;n~QZ~9GLzOMKPjgo@g7Y%ND3Shha9&;}`ocn?U-~MXc;3S9 zNr5-;S}GeV!ICulpcNTy?T}MTGU-yDeqgCD!4H&21v~mD)nJ{ryQ!N51%S2E|KjwJ{AR_8__!ReQq) zx%4{7(jUgRX054IisjDM)OChfs zLMu&S2^?&2l3EI-L6w?B>wc2`1^vmC`q0Md99Pc2l)AuKxxvz`?L#3393^V0o?xl% z@qo34Ptn?_FUbV>Q$O{ z+6<8L4VFi{uThg2r#qPzEN6q_*H9!^p%Tf?v*!^jM4mw{$S6gFh$7k%)VU>P+i~)( zlX=vXmExP&qNQ}bsN2aek6o=}>=oLt-;CG(a+#TaPZW)-S}GQhdX4P9d>9`VmYUDo zj``&;J37Ojo^rLn5ccN>U~Ffj6pf8KLXWBSQUpCcV+##ehn|0-xY7Ewn%**dGO9ar z+4=rOtHQehFtNi{FGb}OSg~MUIHSEiTvC7?bxMF5TwpH9&QRhF0kwYp`j!Fg5$!Tf zM9o{=)k?Wm%C(-^vZgW=tiX6>S<{(*Uz#LYP$Eho{G6a(&alMz8fKZ*#u(6_r!*9&6O{i!-=sr8db$H6&u0eHI^W z=$;wInGKLsd34_fE!R_LxKgJPW!qns*A%L`{%|c;LYVF?R5AUHb%PZ?YawROEIO=I z&3|v>2cw%8vq9^_){eM7%LaQ`dE_xk`^$k#Ay4E6PSP7E2lH-cFtWr=@NzK} zpW1XxozC`hB~H|QAy*ibc3rjE5F2Sw<(;*5jMN z!xZ+)TP;60Mov1CqPBSx%XiM0I(2G`6_cw9dFs?Mi_UdU?SAF zKgDW@j9a)tnMG^SaJ-7^8>}8z-lVKwzER<5fFchrGi_^;3M}E7EmO^kg(Nv`xM+&| zeiAsvqv6On4cl7U8=YQm#BXADS1o)~xIUA^?qwol$yF$oPYfZt_k`pMxWaUtm>#zC z!8Ms&5x*89C>yyMG)LLI+a;Lf!uf)m)1*6h{OQSw$_2yVQ5(>yS;@(LbvIq1ib9x< z59DBlY7t{vF0lA0+JqkZo}B)yka60C+Z`MBKp{unA|MXvHCm`}hq>ZJ6t}r%&B|># zx+b#>RC^(3f5w<_E2E>KU=?E3nHS5Weby@TL>h~97oo-m2!BQkhvV+Bw4=R)m9xsm zq~7_dEt6!&@TMgj1+2TH%yu)f+WgicSj8g&Jv|6?77=N2hs=oV)NPz};pJ5XEfUps1QW0rM2_=a44zBeqH`arFrCWf;s!3}i; zF7yXBz9#2OiB^JnkmBJ)snOw$FX9=?3<_^UT;O+T9-{@JZSVzBaekAK&jc5yOBpmV zcISneUME1vW%q{)hz7matr{8BDKoI2jI@tlad=*qp9KxYsE$5?0M{Kh*g%f^c+LW-E zDd5?oW|n~`rs*m+Wz{_QeU(|BCy2B)rbIEzGb7n6%ygu7e;OI-plEs_--X^m&PMX2 zq)S{%;H2O}POn+XAYMhLH!_iA0$s>~*I=i~Gx}gAiBFO=!77qb)9tJx`A)*QNvkNz zTIYOOMOx%kR+8zHtg*q!@!o;pVi<|Q3biLTykY0qM(%JtN-%im*z`FpWfhb+R2NfB zy_leC=^Gdf)Nxs3bqBi1XDT!0P)t<{DLc2Q+i0CZ&s>~Q>oVF4W!n1YAV}1vy579uAo}F0MCXdy{G|N6-4!y6#y2@J^FYdy`yL4!Zgcjj45>vVjz#brs^2x>Gs>}JPHtbVhSAaLHu%G>c*fW}Lffc~)#01Mp2g)d#zWjtZ*{OtJ9_#^ z?YI`Y^2Dpy;o-b=p5x%g!N8*Kt_`E;yoIeyD>)qr@IzIKY41N$CkI?Yoz4q#nGGA_ zP7Em4qE!u>+JLeJy5H(-1Xm~S!9ipUlgODcezn9j_T>uI{+2<@;HI7jLoAO`r_~M5 zRl_+(VQsZOAXX+WM6A>n^g4H3`4aXzY~DKP4C)kfrz4V-EVh)Z&gSgA?79ST))KQJ zp1cOb!7|`C%6G5H4pizb_F^BlU=!zg;ELUaN=^upIsM44?0W=dR*Gv{4k0f+a=~*ai(i3?eAG{tmEDJbg{3LPIkN;CABa+ zE|c42#1$sHH(X4&!h3SqkQcU%wb>|7UeD^5#LY%km$)}trP-|u(wIV6d2tUkq;)Ql zr_@AS>nP&c6DC?(Tg=5dLf zCyBK%X|NO}%)QUnKgtttR-_cMNgFnmXF%Yd3a-*txp3t&wmL0^O=UI_-H^ijqPxAl zc3_y`79D9BceCR4WL#@+uUsxyXnMm`vp$M_Nowx=MDY+BnJ+0uoU<;FtThMz&DKJLVUmX{$_Kz6^(!;CW$uAnC zm<_ZeLD3rWxGs;KAkbAx=+rJ(JYKQdJzfzE;Qt8L3v#E$l;#wsXhoZw7YgC3p;8`wu+MqlpLH4?*XmZOS-PMiLDexkB zwTR;*h;P0@B8%B%1e-4%Y@?h4#F~QYOpYKZt{tQYZvR+%5yNG-)QPl>S+h@Ynm%%2iyuNc&Kp@HqZgDbFV z;RidsFU98)i~FPFwa##bo^Zmhp2*PClP0Xl=n09`((+)oKXnckUTS5bGn}ye{FL*% za#S`SGr2RoxNGi;)Y9`)^XG<(&hK2h`1DK8U)D82$E~TADAqCtSfSJzE?Bi>Nw{q8 z(k@Ptm(E?hTBc5zmw5E6)8@U^blF+>X455zKYP{61*sYJ zd>Riv*A&lSL3nMjX7pw&6PD*}?VxCe%AH}pXwmZQjT-rXZN)OLm=SJEDhjNIsIyNimiC#Vx6*V)BZMaZ$)awM0$B_Ikw z-nXdT&G5ETXlpbG*IPAv{m7<~%^~BVJM?!4k?z>(^?csHsNJi|YajPrt35`iw=(Xn zwZ|DdV@Xubu#6&)kxRp;5G`+I5W7Zh7`Y}?VU3$xJ8F;6Gf`lhDC=#V(`s7-9&z|D zdS#<_m-T|_)wFJ^J;IdkFj8F$LLE2TVh>U0Mx(uEn~SaVRkN+h+OAhRYR#wH{8t*- zlOtQ2wX!3q-A6?`Yfpw_-u|dvi$E*OEettIN8s&npL zd)K8&tx(0SB`1}xg-jx(sAdg_!F>&SA;xMjE`35W1v+mR18P}H=ItR0T~uDgZ5RM& zO!cR+eVz8wOp{)*uxwb=QRmJbayq!zYE*s11@&ef&HP$$qJ~a7SxJ45YXX>Ri8zzM zd(Th3+abXwiM){;_MVp|vD?v+88S(ae4@-POov;Dwnh@2v0jQnw}=x)wm{3Ps9}q! zzg>jm1|6oDgtr^RuG$W0b(7*sr-Nd06MvGRUVJb#O2T#Ox@N*^6wAQ+HY?UsI979Q zJZpSUL-c(7`o(>=uJ#~^H#K88$pUM5qmAcnOaXkcidN=CMb^s3wV$vwn2I;G+Lr`k4 zY4Rn@w}rDty@EBTCmeZ)Ix?PwX5`XA-kOnyW|W>BTHI6%TNo2P%E+#v9;1-S9yN)s zrpu%nIdvPhG%`ghPb4&M5wS+Iv6ecG$RwdMiLwNnYeL4bxvNEj-rPtptVnbi^McwL zO6!d=&4sas6r|~Fr%}Z%*fb1M%E<(o_}zrvnju>=woW~h*nmyJia4s<=^JH@4HQv8H%Ez}hWFoU zx6y(rsEAvnq;7CSmML(JD2W(i_-ZeH>BO=w0p7}*c>PvQg{uEA~(*bka2(?mE^#x^=)z+2$njj*cQ9*)uNG@oQ;#>(nq z57qeEB|3vO%0#n^q6KGUVA_qm9g*YrOte60ao8y9hobU{Nc_NwUXWesgqs$eY(32u zn|VUrk}|P@j%O;I9)W?~c3z{|(Wpm6Ia%nt4!2sXTm{1CsrIKbS+Vt(3*Sifx6)+sSOIHA^tlgct%fwSZy!n ziY*{#*)f=1R+Y(Ytq}=nkxn~J1gRA92k7|Y*qvtln~~^btQV)FjAt|H;z4aU9uSAv z=;0(7Fg^ine38`*LuqoiR-Iu26Wu{q*xVYE$-4EN^#}=C%i=BH(|cf_r`+C5(kk8? zx}_(Ee5VmnvVG5}w_ly_(d2`+a}qRkIbp@!OG|DiAqB(W%@d@lwd{#$9FtSayK!sn z2ZPNm(OPHzoiXKLuA~i0lcuQ|pN1_}BSJZ2K4K-->`t^8Meo&A(x&+)DRE=n38UGy zHL0cBpjG5K9pBrhNkqSDBwjB{=gI4UU=$OuP{vrod#Micv9e4oYaFhIx}TFerR5}9 zqIKi4*pY#$#L-LKwkg`~$RUMT(-gT5LyiM&Zn!YpLR? z$R==`edvay6bmV*3>D?2;#dMoH7nEO^{ixxM4HAMJB?fw^vT&VyL>@tXtHvg&risW zNZsb(rt3I88lpVIXim?%yT~!CnAD0rCGu#-SOKDsIAIrhY80t$jX9(3dabVUGyqHL z0fu`^ZI9Sh&MA#v%F3ydF=@~7)^P*RqfY(SLfQ_GsAFAofWgml4v)j*;w|o@=rzXJ zVe6U9`9&iwBy!M>i4f*~EF~o8$PkNyy}q-ILe)0TNrOfj_gXDoWYxcQt<-q`#h_s& z5lqg!*iaiS&L}^7; zWI|HeDA9_f9@`gf5@Sa%uYDsUZ($-Mzp)nt@tTSp))EGqjD{VKEgYMJXg?=HyIiJ` zBU?!`=SN_Yr>-GHVBeU;)V+LVu1KlP-4kGyFnp7e-bDwkMi+}m*k^2MnF z4?*#&FGp&8D_~SnQ{d(>G->3ST(Z{ux5j~H^N8yuai4(yMyXt8C#ii*B#KS6HcVkq zFy1uU95qoXkd3)&Qd0vxWcbUe+K@;?_*C3GfKBe0ypa53bwU)=^pd=hb~d@EmaW6M zp~hA&ZbwwfUpmfBgvIT(TgJaFNkTVWyIdPhp{LCf9SiqjH9XH+oygG6?Hc+kp)~$j z8oYYsuFvfYC}p$m&a}J>a{Qi-ZxfAMMuN_oKq`a?2MNvR@cT5Iod%WEw6TU95+HVv zByJhcOEZ=USX|BOCVA{90TQdzuMcr2I+&@$Tx#r&_j8VIkvZE6*G5MIjm4Vv1%?m_ z)s}pCcmU!RU`?A|X<87$Cq1Dx6MN09jvH;!ppIkwSvqE8 z*zkFVnmljTdlQJ-1aIX?Q(9yvpD2jF-QYjiV7ZgtLoX(^G&Kd{qlBmb2~!EN@B`lSgLhUr{qenmbQ|G^38M5JS^Vac7?hgUT=QM)H5mp0NoHeVP1JW0-kL@dj& zL-M-Kt1}qwfgaLEyH69R<8H@SKT*|kYN(RYi+QDWp$I#4%n93nbK#O?|4aGG;IM5( z)FTs;J|Y5}__Kqmk+($(R5L8P^G7Fp`a%a%MkWL^=qwfqS6Uv~GU+T^*48~uvKg-S z5bA00lY0n2{6T*IxXSa&KU#En7n`aKk?m~fY{MqEsH}1l^$)25^D*q${U`qPUB}!? z^b%G>8YL3MuU>JQlu9TEH&)~O=Nbx)$xMB&=NiT|-8jFaJK#lia!LKAyOD-5HzUH{ zjKsSkH)0bT4F)tyLqM^?wQTeJb_E#q$&$Zz1>VI}tJO$w;|*$1JZK7d)rl~B_$$Hu z%!T?V26TGG+*wjiG9%0c;~4apiwoL3~ZL|g@y^mBZeMs7@rTQk$l9?)#iH!VyY0o--UfWPre2KHL$-alDW zlUUOuq>Nvdc1#0$p0LlYF}D)sf;Z=7wC3bTod&sW7U{5OA^~~ty?w_ z$OxH;s@!z7GeHoU>Z2YW@&Zuj1RA>a!fbcsqd%c{ro4#aeE&K%tq;m*WM(MzvPbsD zsoEP-rsT%>>twJssE_e_Snrk%$>u74aNriX$|cz4i@L|;Bc9{BC~J}^tMERC#uGrS zDd}AXku0>cX`$!kXx~doKUl|KOx51C_Q>YZ-}w0}McWGh!d2pt-Wx&;^st9V4ra*dm6T3mbz2jPYL+{DmWgM*%dMN;{>e{l?eWw6xdpbis zOFMFN{nSwE4Eu67E6Ll@kHhTJ$avf9huGVjSEkjd)udAy6K=8?GCjQ?UMtdUXJ;@kv@a93 zV1%%wboyd*;-B`?5l19B67N(%9s915lW8({BwQe`99uh$Y$6y7?q(9?v0}wL$>(wg zwY#~&{4!1QFvwf(wsou!<0PWZ9~YSzOG2crc{t?sa?%!Q0;&_MmOSAK0HB}Oes>y(!}(0e55xA3Q( zdb|-{Y-nX`^rkk0b$yVmd>fDUZ;sz{XjV#d+R(;m-$>Gs8rx{|;<5y^cD->Cxe6P0 zIO>dvb;)|fB^ztUvX$uW=!B?xEl{wCpS}J>0ef+1f~Vd&#Trdf|C$ zy<{MP>fGozauBO}Y{KcNSV3&&*kv>Y^);^=4+1DV604_2Y*Krw)ivrOyu(kLToVZF zkTe-^{$cFVL}t<@Ld+Ji(*EGs>70lZJLzNm5FSl6&`%P|EK|gn^M}aJv(pImK5~UH zF5a}~V`8l6CRQRH(PL`jR+!t{i6lHF@ekiRah(3#EbF4nY2sV;!aDg$h z&Z>;@ZFSfl?!>TmH=R!yV3rmB(4wrn-E9lUyfS?{tPn36eK52%+hV8d^yrr4yw(fn zh4JA7y#Ia#hbEqJN0JW*;ONKn5Z517X%t>F20zi?)|!+Kld(c0wnx#r*SQG;ma|d3 zY|DXhN0ytp?CUc|Ktf)b3@{>aWc(=S?0$ zOvpTEW4gJpb;XQhH6Y;lpSRV&Ru?H2eXI_}a%Vh$i82kcw9#vA(~rVs!f}VH`le=Y zV<9<@DKOqCwNroYp@rM1Iu?r%(LF^UeFTr@jCtykN1P`Xa$ZVi;4U{s@Se9f9TSS} z?Ipy92FP32fljI>T>hHRWOo{J$Dh-C9(go)?Ixso?To`-SAIUVk15G^W^d)H+W4(JtQK@o9OG_$Y--8(y&M&&lsX$8js(JSmHp{ShOa12DiyA zFu_KKYg@jtI|4*Hw=t+=wJgh=2b`e|?90fU(%7B&grVxJJ(5Cb%kV7gU~$U! z)2_k$z$FgGoZpVH`Mh29u~o>tnTtzbIB(HiG8 zNlK-uz;i0yda7l|sE%J4*-qMJHL4r6(q9 z+D&g#X%h)zNsv`}d~x^0Jv5R1BJYdN6eOXMn~eT0`T)JBxd%p7z4 zj8i6ZkvZcBj~SI>x!nO5co*4wH2=0Es@)my6Su41O*@gWqDF~b2rj0M++?xNv%y9j zPKMZqvWa?*{*UXt@?W@;n+h4mAIt#zA}0Qmy?J`~_IXUJ#=eiKD_M^cJ&cG)IdxPR z{U28OTqcL-c+H$Zs(bg~8F8jj0tVBTLL9m$G@qSBm)B4uJOSn`8RH9yHP)RtI^HBv z6G;iVi5!VZC$^W^8fybW)TH_M-{lLPOjz>=lcSFc+WvW*uXgUe@L%#JPyZx*;=>a0 zr|ACYtDgU#f7LTgrBVqwjm;H3vd4zr@8M!WyY>I%H$Y|DB{q?W6A6dMntmqGeeo;# zQP8~@hDfS}{rTLsvV9PAFZChEo`=2sT(vx>t^42UyQH4osp)4q+&+-`0&b%eO{1C?ISg4NcWK%cC_(_Q2#G{)RZ;mt+n{GrqZ;wGl0we z0^^fzf9dy4wTPQ-&b_gyEm2a}nr4^B&U;ueCu#bHeFn8YCgg`cW=aiz(T7l}sDT)M zAaRY)^=Z^`%6o!auU^2%QbkFfzQ|uO-h1fmns!oelOvJ(msS6QFRH5PdlFpX3E>CA zo`}6>w0{kI>aISH0p#0%(u`!53JyeP-Lf&$mi{mQ?y9jz?4gX<^soE+D!iwSFddd5 z`6w%xMX5y_Z6a_nx$bLqyR%E}WHccD&$xplX1kd$VS2=0nS3S7u&JBI_mZDwouJ|*rvEMP- zeos&G8;}hT2HRn%U%O(EW}YzZki|)CNpP-&4PT9w`_h{Ve_2)f+H2scr8evtCwWU4 z>&R7S@c~))MP)9Ueo(fit-O2mL2u=6<*T`kUzm-b`g(z%mgQSm8}-Qg-T6Zr75qS+YE^zwJqB%^h4nD_!b;0 z(UFd9%Xh~2`sZN(Ysb~DZkD-$R8r!NN08u(S1r(G7Abj-!UW?bTA;pFpfwoio^ckI_!3nXfo+IsmPZsM@W$^wmw>gwaU;SD5SBN z`5!oQqtKT+57frL2`aCFV)J*FbCH8u+rk;EB!&mu(UchO#r-(i#;y71-mMfCh4Z;q zE{MfX8>o_T(IoSNX@j;sO?%MT>Z&}is38(_nYjlkY0S9w#^qA85_(cE3?)MS9ZkF5 hB%5tpkPfLey(hRsfqL^HkDEN?!oT$Ekm1VP`31dfixU6< diff --git a/locales/uk/LC_MESSAGES/messages.mo b/locales/uk/LC_MESSAGES/messages.mo deleted file mode 100644 index f930fae16986974a6a2e6c758ce6a6e9a3a60639..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 63748 zcmeFa37A}EnfHBE6h%QmMO@HBkS(ODyR#>TK*$1-B*b(Af=jx(ySlqbbyZtSIvrpP zAd8Bi7~yqc5fry~lqHZrNKhPS9B1q1opDCz9mjEI9A_MLKF8779N*vnzMpgIRChJY zT;KOy*LPiCUpe`o^;z!c-k;~x`R?&Yd^Fqj z3;bQM7yLKy4dBMpqUa8=489CJ>hvgjDfnto<(vY(3OpCo{TG9;2Aklq;0M7Y!8-%q z7w}7<%6TLlKN;|w;0rka6nGT)t$=?O@E-&IGT`&i@cWJqcw)d)0_FoQ3%CY6l5#H! zcnSDoj<*LK0agFI12zLrfNIZG0dEZW5%3k9zY`Qa9t0s(^he-g@E73mVD8K)g5=S; z;91~B;Bnv;pss%qJPEuT{4jVJT*z2$p6m5q$3y?b@rS^ZxqfvniYPj|H{kDs8p?kG zb^W-!A1?rxaePt0_kq9W_-o)Rg$%mJ>CeE8;NOFP11{-~qB-E}dz?P!fa>Q3py=?9 zfWrZ60j~m!T)z=~G58Zu35HGZD~$HCtOMfXz|dU@x8y1pJf5qvAy2VM@UJ--*u|1tO)j(-fk1Uzz)*LNH! zex3&&2c8F>0B!}6b3z^{Ps=lV%2yg#2i8+vp6AXw)5Z>@BC^qdn#qZ}V`uD7=azK!Fn zK+)-2p!oeCK+)x8tNi>4p!zizjKO8#o50J!S3NI^-UHsr@kh^d{#&@(aTTa?HU)fJ z!2W>cfI9>30sn*h-w$dWuV3SIx)m%_&)uNteDpf!rxQW(=UhQ*TAe{d?_$H4306Yc!S-=zC5=D=3yd2c|e*s?yzUD&b zk42!4F9F3Dbx`$R1HJ_O7>LM4_kugY?|_)V=&c)~=pJw!RJ&ih(fd6IRC$X)(dn%q ztQ_qCQDM>Nz`5X`gVIkg+7v~ngQtL^+l8Q>e-|kE-VKV5d%!n>?*oqkKOgWwz~2F- zm%ara4gN5k{{{Gcj$e3@)BA_uQ5^pqRJ(r-o(3Md+3U}PCvv2**KfzBfcJn;ft5b!%>Anh_*NW`^n1PA1{~iB{)+QOP<%ZA@w&lrQ0@O5D84xe zYP@~`s-B~1)C<5f!KGjhTm}w-Cxdr`;-4o$mGgTbB#*uet^*eixm;WUiofmx=YUUu zOTh1g=YX#r_VO+RdpN!lTnBy$gq5Rz0b_9W2)qjpf~&x~)`#%Ee`OkyLfCmG96V(0R2GzbFgDUS= zpxX7Ks$V}IT*&chpvrqYxEg#nsP;Y#s{SX#@gIOM$ESfuaK0NZbb?{{H`E~c(-xP2&sPVZHR6QR8)&Gx!s{bzVMd0Vc@s~lh z^8k1Z_%%@VJOzs0-v?FBPeDEZZ=mjfe#6T>8dUp_2Q|(ofNJkNP;^)cs{S>go?9Qz zZv~I$_%iTs;o}i-6UUo&x?gn%DEhw?Mn2R_29W2e-zAt-vWEVBPN_K zZv!%HOl%K`U;>dzCP+WWPDe;DxF0ski8PXqpYz!&cJ=Z+2d zx`3wz>;cuD6#>_PqU(l$+d$R-u7Ldkhd{OG@_@~Nd%#z4{sZ8t;9a2j@ay1m@E^hB z!PBpBx-AFK;&?r%acY9nJ2!yaz|Vkx0{#d1W9UA0rPuq!Zx9C|Fy92lcaL7}ao(Q? zJmMPHTRBkI*N5XB;4+SH2>4a-`sYzTsPWIq-|%Q{czA{u|f1o<8vgZ}$dJ z_TlZI`g=vdTLRt-iaz_n!{C#k`1k4?{r;N+-V^WK}~WR4&IFfhF zQ02dNuj`Rh0xk%+8Wi1oL5`25?V=&KyR8axL4 zHYj=dA*gozBX|P%Yw!(RIN^40&!Uezf3F0`xV{(s#`DoppK!kV!#gOCTBr4}%)NJ>cuXFM!?P?|_TJe+7R^ zxm};3jU2!6v)=zVe$KHc;Oc&j8h)l>xT|90Fg$ z`Q6~l!1sa|(~b{=M{xYZ`~Ccn!Pjy8@1V|~@PL>5x_~|4`J6u=R6Vx@ycg`HzxzRr z^GhFcKAHncE^?sCy%1ak4uh`&?*PSj`$6^pFnBKb+o0Ncw^z~i#dJ*l-&FRJO+HpA(xXAL5+JQ;Clmp9L#b4e(*%_y8(X*Dz9)X%J($RU-g8K z%csF(IsP)Z9{dXUTJWf^`17ZNs(&ST9Qao7<=_CQ{?x&bfIk3-D1Y}?u@4;o)sxVf z<14;KZieG8{uW~epS|nr-v3Yk4(GZ4;%^|M;KAP|cICdWev=#lc;WB4e0~!A4#$sz z=WyTN-$$2&fBXl|XTR}BJ|0g^LSydx;FQbJNl$sZ=Y#*i{cFKfxZeH8*fx&0g5tx? z-*SCg2E{)&gRci~10^R9f#Qclpy)pZejofENY|pT{VDsDcf+4?jpGp-JCEb#e~!-Q zc=&&#cRBtH_#5EQ{=)OI@BT|@!EygzdA(nyP>sXyg7UY%1J2|4D}O_d8T>K01l;(y z9uHp!_H+EF;Bs*J4_tnl;JF-M3BDOT1ilIUH}Iw48~)DwHy4ED(fQyy@VFm3eclGX zk>e}DIp8Nj)%yf^4){y(WN^vfyZyWr)bk$zH-b-rF&O`Y>)}=4DxC*U17G+e{ax@V@J|AMFP#5TIR0fge*RCLe#d}%?v0@24a3Qz}Tm)VVUI;!4s=Y7#xz~R@sN<8s7lLyGc7rN+G57-T z98mYI4%asayciUH-vNrggWuC7f1!%g5>;Fkh^2NeIj=wF>4b3oNU4^;g<;ETZJ z;dm9OcD@DFIBx@0&mbszH$c(#YEaLA0Mz|^L6v(KsP=yvl>B}U6yJOU6dk?;>b~!R zdhTz-`F{eB=J*%j^FY*;{e4OY{M`qh&h}6^o)132`CZ^!*d(+2KM{hfpT|9$@dY`E`M_VZz17eB>z58Kjk?hyNn*gnse{QZw`?V|yuSMN+N zf@|1h`)>zN0GF}d%>Mty*6HtcT>ml``q{d|4dS)z-#YI39Gm_o*e+-L3ESSS+i+ffM)LQXu=BsbQ#gMHSPAF85b#mXKgj+@@E^g4*&bor z&n92;GPax8pZ<3@CvxHBH^95NZw;INP6{X)(%)LPAK9M&hq~zaSLeABS59MVvR%aS zC2U`1e+<;0{2IxW{*DgkR)doF=Yb8of^QvAZ~~j;TC#Z}_iSa8e(7Pmh;1&%zYpr~ z0`~QHA^2OqYjX?oAKu8eC7hcASF*i5+`j;njvQjUm;HYOf0HfwJDzh}Ik+P^0UqGo z`@j#d?O{8c;}5Xu?@a;y$m6YH4tBH27s&n{$HD*P{y)f^{Ap(YD`Ees%(*Mszl!ZQ z*zOK>{U!SkvAsH}8{E#Z{yxM0k>UJX!JT3M5B+j<8TdiAH?zHsYuAPAXL4L%|7!3F zHvL`9HpuoE+jVUBu~oR|v*1K{j@{_XVSi5M+{ZcpXS$gAJA&(TIj*sNBAkB(cpKYd zwj;wif&AV@Y;R@%_t;*_c7SaMTbXT?YqzqU&A$HL#dd`4x$b|QYdvi5=G^&g7qG2o zJC7~Tb}8Ec+xxiZMz;5}ufGj!huLDbKVdtUZ5P{_+>>MbAlo6fZ*p!0nEXA;&YQ#W zCidmeJ|BEhICn?D!GL=1=WNT_e!+GZoBo!t?dF~ru${&JRp5`ogWy}h7|j0N!oh-Y z;;3+~7H~f}&bEx}f5i4Hw!dQ2oaHF^$86cZ^_;(yO@9q=TiEwA8&esCq*BWxwMv)EqC`2yPr+a``b1ilhX{%&CB?QFjr zPW%IS1J_>_js-=IF9G*}pJ4l)aBZ0Vli9u$j-Lci4EtL+ufOvGYJUaWN7>Hj+|R&& zW&3cr{+r;3IetBOIosc`e;l|O{5sojv+ZTm-zPc$ezsq-e>K=-E3*H3T?~K!ne2c^ zhyBIecN1Ik_Y(I1i-U{7KL>AQ`y$(_aL>osPyW8Zxle|JRp9Y#|C4Qi^T&e!&h|Do z{VnI*{cP8;e=Xa5woh}smM!~tF2~z5=e`#%-psi<>^}y+0DMn4KM(v6=l%lxbvP$@ z4d-6V)*a5B0=|juRJM0;{vh};ct7|8RV2*>Z?+FrIR*rL2%U9*>tABk}T~Qn|Ri zuQ)uMD^-T7eer0qQ5Y;V3i)X6+||{}aIMg2@?5D}sn3fis?F1P7Ly_d<3eRH9xT-x zwNihxQRFz@Jkc1bR^qW*_449C?=QYO`LRm^+utYfANjX1%WJc(zb0#zR$3P_~!4vou($495f2(Xm=_q*$q!XpdT6 z8?{Eph5l-@K||_e#evdLX&`P?$4UeFc>R#Io&qm#)*Er7HlcDFRT|KU>y75nP&`A1u~#m146|E0k%-M7d~}FR7Jyi1sx` zigAs4i#0o6EYv5qmn!u}pgA6&F}$-Aj#1q&B0UN%3Pzi`2Vh4XtBMe`T; zEbH!Gx+q$ZU(B|IZE3W4!P1`ji{{U#)k~Hv<%Wfem-a-<7B5)Ty?Dv|?gdfc-;Jv_ ztzWmccWb^>>Fab(3^NM1){~1{)~;H!aczEdurEHNUTieS8r5pK9xqs&UzqPc>&$7l z)#?rI3%pI+&Wfuw7$tqIJHI$Tf60u;8oL^4YrMkraBL!oNWM`WEw?vf;evd3wh>lQ zeqd;rr^kw8%lj5CSlSo&Hpj-QwMMiYSz6w=u~}}Eay#KiL?>SF{88rtySk`f;UyoP7H_K<9U)dMK@&gDoA~#w^QtGAAvGT+`lSLDqLR?1V|1D)kdMejIbf~$Wo&;Dy33O+ADco-YC{a zm-nTraRq9~m71uz*)=Al8LCxBlbbhBY+fI)2s{yPf$*pbamwcPXL5hDuF`8Q>L+T6 zae|^~&q9;&M{^Az&J)=t(R-sNVPdUf&wa)%amCgF4CUS1q3<$QYR<{Dj zs^het0b*!M5W7|!E5iq9{bFTjsaCC+3^Dfg!YD#t+%-^c4i@7p#tMy|s|@B}73cGL zSi!f^6^%<4t2s-FQRcV+r?cBk+iDx%3x{8oSR0xg97WS4PB2THCm6)7{IZq zmT@!A-?sitNv&9`4|l^frn@jJMjDN=`tq)>F>hpE=AZkxtDY}aSN3h+ZjFFgrlU%HPv}$m$B*%l6){1o#fO__%*}lvPsrypn^g5k~M2RyaR;5GE zqJ_#tyaP2|iOa^u^c#Cb<+xvTnmUK1mee~sk0(@*N03nYZRMg|MO;brR|TVh7SwGQ zY~8pa#&;V-vJ<-W<-4SU2D?TY7)eYMMr@!_txe?POT+V3)T9%!kCKYJ^5Iq)8?|_6 zsW@)e&6!ilXjKip zVQd$zlKEn=$Es+ixMc1u_Kkg-D-OY2t7e>U<6r5mV4cdP{#v1iA&Fa@Tg7xx9?on! z6ob{}(W>TPNle4eu>53iTe?r<(tTRj#A?(6JZ16hgd)H5!Hka5?!!U@Gb(6_CCd~{x6ccD;=&J&kf$tlN_t7g-q^CsYW zY>7goP`A2uB|gHo^RM)nigJs)6hJuh4OPoXl^PUp?p+6S_N}g>`B5Z9WSFFeG(fZ( zt9wyz*Om*`ZeUSmp+ZatR;w0Qj27VrcYBbpW~KD*W>L|JyFT=#mZ&)wC1Rh`8;Gd8 z3-O>RllYKBx}r10(pH(dufsIa&eC1qUlb zrQs&lTcUth&S1;b=|UYVTgy5yFh%0QWZjN>6S<&4?%NENOAWk6KVYl|MmUmp6&%!R zk#LUyjtUxbRcyy&RuykzWn!)iJGp~~A;%OjS{#6~r2#!MHc=}LvkGoC8qP-2<*Z2D zI9@4N3j`OdVLgRni@`Nq*2;%=mPuvqq8qhCS$lqofd z>*`1S<_5P&9jz($mkO1xZD^K8lcRy6f>RgY?9o!L1;=tCzK8;93UPI^T(yWes0=tD z(N?;uh`>}@gyWPNQm(YZ_3Xasz)aw7b_rF0A{39%l}yNPwhX340?N{0(_?o_R7?x% zhpX5!xR7XjFdxG8V1$*B2q}b|h0~0WTi19+>yn~+3s*=*SZq|!?NnN#6(_BPVb-+S z<;KLANM(|Op;zJ{)j5G|vLOgt16LmFDW`+Jju*?Er{}Kvk zR>3b=TNx;f)s@~s@8Dj`eIXc$*19{he0j20Pj~E`yN%8h^?0yZQ&oYU(YjS{jn)pSH7vvYVA1<=PFz&c4L#CC2++h=a zVB=Lry7Nrc*5bat(9-S64LBC#)n<862BuuXEYvZCs<%~g!$yqj=JUu_xJ5vVdZw#Y z8y6I%HsYN<(%7f3I^BnE=X^UnkHb2S6tU^k)d`)|g2bfHS=CQKN>XV~yt5w9K}`+R zaHHlV)mo_FxvRu^9DuV%3xha}T^R8NUENE%OoLA2^RB!qV$`Ye{8A%2zf69Pp^MJ9 z{0xd;`Cs(S=gJ_f3LVbskTfUvyP?1w%D(1NCzHrgytgZx?=vgif4i^(GAbB97 zD-nX4ZVo1fa9OUJ87S0ip@swJ^@#C3Nto8ln2;x=&MFZfV=#bOE3hjGDztpzj1H15 zsT7Mif7Xr(8}34xfeI=E2_nIQ?;4{SYt;gl%}i4}A!M-|P++=BGUGBs8`;@qDq{bWN zYSTPwsY_HlDcg(>GESD0yJ#P7BVoB!DBTpVsnQmtgm8sM1hFJJZ44(h=HerN4LKQ{ zc{lgSUsEC$7IpjK$)Z|3T-urPEf)TqcwG_Z9IBD}#UH@qahFZcCZ2#hNaNKSeRC~K zs${^tTpk%BXFU-s#v6qjYfYSc_p8Lta=QEND(=T%Oq4WQvJ|%}BRFuf;F&-GY+3=G zQXH!y9#kH*8i{)n_Ce{SUca7|A|a6vn}{joI7jP83&SNM??3_CY|X^knx3EcIRMEg zG&k=~@~CE^>gsfbA)}7^4w6C=jZ2}s4MkF>%^|=cqY0}_bhu7CBvmLzx?ZOliUg4o zXu%~Kg>MQm)jlfIDQ^XgM^r$PBp+Wus|KrfjR_=o{lKh-cb~q@f3CF31qTGzpcMVb(LGt}2Wwo(5eQD-bb;eP%jHDoPj9%OZ{N z@`nh}834^dREHYl;@UweY@%x_RhQ~SCmNy=58gtr5ohPy0UT1|EOZNPuQ>q|N+*w~ zE)A1Qu8%??#;a2HQ<}kwQf+2juy5>|lcvYgfW?!7QcEbbGQI+NSP#$p`o?VfX+fMD zHT@MVef)MkpD5LL_Mucm!5)JQx!cor&T=bhQo!!3Cr=e?$)2=GqO04^mBx}ol0uoR zaVCk``G!kIP(|b^4OjL>B(WJ_vCKdSj}V&~c^PqFN5=+H9)tO^*<^`#Iy)BZ1;YuW zq!%XQdb2;*_RtxnJOkWz3NvEkl0A7QY2d9&Q}C}!;pGX8y>jVr&(7e)qTUo_Dc<*d zs8eXTP(uDZ+1k&n;1H^fD$>#?$S@%X_`D3CJ7i{|6R*sLEAhux;S(r|uESWwn22Ly z8>z!RGIQdBTej+SbRpuMndwqp(LaU<(^OD4pLqb>^5B*E{q>1@13h0IK-5iD&=De4q%@N; zl>!ezuF@{XyT+_)43tvMCa{Pc+8C`b_mPK`{-_b&iY?5-v~?{XZCJm0?WW$fd8X8& z4f3wH6qVU44%$(guxzJwUO3G9~fw6oD5b~qoVj?GK6Mkmfz z%HeVrjH}#R7=$?3dd6>DK7jFi%Fas18Oy=HL(MYzN=&Rvg3Fqz4YT={*pz^J?$%{2 zDb#Pa0ar*U)lJ_i6z9K~2^GjTo5#wPv|S7qLlktZO^mrB4S5sIF?lAF!F+qqJGVz0 zEXq_=!mekCaWzh6g8$=tq7BM7*SVs^dQhfxX>;&pqYcW4B~qyQ6r_@zX{{b*rf;K- zsDTC>O18Bdl8YM)%7>bOq`OPGEu3A(Zji39ql zBp(?vb69stxJ_Xum->Qs!5Je~x}e#Q2{KQOl(c8%ll25R0L4LqcR9r7d`j0P^QL{4 zw8jU-@8L1yrM|Hy>PIYxROoCrYe^$2t{bbtdx05>B=wD@%=*uxrTFH)R=`gCAbJYK z9fTE_kTemw-L7o6D+)6<5qw0OisNC>H zUPPKcO+aN1c!r6Ail;s0ehdyGJ#Gp@-qw@+Xcu!X=c2sk&Wi;#7KETGY_~o)A73O_ zW4u(ytVp*^TS~!DRfrwx@my}3P!V9M#*P(Y2lcsWhTWF1+IqAnRG~xf<_3(qDn_UVl%2W?j<$etVf$mhB zp$w%_45w{DO@fxnjW#!Ha39Z1Y+eOxO{81$i=XkHMfqngXE9@i|7KG;B!!hqMC+Q5SuYJ&&=F`X6G0pD z&`8#SAa{&I-0LoJ+;>5V-0lb|nwlg~2?{+K?hks*T{<1q$dqHL5GLJ~sJXV%-89O} z4cfWS{2QD zbj9hym1v9g6t;}EX!gg0()N{0W64ZVuD?XiWP-_7gwIx2A@TN@WtjZgtnSYy+aaD8 zBn_6#Bq0{vmvl_8hT^0P#gS}Lb|Mlnp`9(BaT6l`UUEst3v_aoCu9&)r& za)~&bRlz572@ILQcAY;X+t_Xqx(4v!a>-&(+5cWGJ#>MLdYk=;^670Vr3LkUxtSWD zrb3y#7_?jg{z*eYbUji|2Hi}0W1a%A9rcqr#ezz)?()98#I`oTLMoX$U0A=Vck8MR z8`f@Vo!Yo|>#8-Ywi3W4H*HzF`l2msTE~5Tnu_TnMipYYly9-DlI#Wk{18G{E)Hve z3uPRt#A*OXE6gW|+*FGd3Y@ILC|h1`|CHyD&?L zknSuMVp$I;!W3Ccv!ci{Q@dp%ey%YxVLgi)Of?8XUAnsqmrJXJNr9VN608Po$84}D z*6Qt27zsz25)biFfk`m})KNsr6tWaM(Go&LYGfi_M|_x<|3>qY)EHA>EHSXP5}s2` zlaAhc7UeMYO@mk|$T}SxdCZPxsg;GKd`3b`52vMs+AC2Moz_F3)usZh7+Y&1%aY!v zWnYqfWgeKdz|T}Oj4r3AI>VHbCnVEJDXCFqQU|NMvFRF6szXH%Dw*R8josJ9`pV3N z~*)D`(SD8We1#WeK#JMtL1)hSnn{amG8yptV937+1;?nbOG;@rIU!5^oVp!Euxq@JOw5fJCXBu##WL$lo2Wt0VN@NelLxp_szB{XxJQ|u`=AjW$yL-KL$eUI8~_TU#0xvBds&ie3v9av&CMnW zMCfTs&g_F&MJ8|BBul!IDIcF##0T(cBoh`(RnXu}YQk3Il^WbTA@_j%tU6@l({ew; zM19IUis7IQ*#hGex-OZ-2vqU+#nISp#zN#I4B2AK>kim@&GrZCc_#qYQQzHrJ1+`VnT0} zFWN$#WG>HEMw&5^MnyPUwFMhz-nfynMOc;zjnH?q3TlKA+J&E+Xb|(mlw>;G90gb; ztYvcbh%U#EV-YyS4C;rRfk#gHMA6mqN{Qlz4cJ02$cIXZwk9+8tv!?d#E_~u*_(s` zf;SW5B@GP%k25!IrGZxdggJU?5?=19Fs5)f)0CvFa{Uu{zRb9popO^W*V_{Gu3R*A z&RU8}k++VRO06k6LE5Fb<-?jl=HtG^t4`AE(;VtPR^V;pQPa<@9OpIyP~2148piPK zyF|WgF64njIwj=Ax6&jDs}jt}t7LA&_}7Fu1i+HNS_q8ka2OFN=hI-!y=+qAU$HQ^ zYWmwNOlX{h@vs8Cu9bw)&NvGa$$1fTshzHbCg@6zY*d=!?0d7ZP*RM^WattPC2n34 zn|Epa28%-lmQFw{7ZZ7B?ET zBtbhmZIk>Gyw{q+$}GxRt~Sy*mFNyQMI_OfUxSA`&Tk=q=py%l5?@pA6d5C>{!Ora z$r{?WjMh5B@TYrU%+#=w`jQ>f9$u%lHkePJ*c0!{Y==M~5Ha(%i;V^Jo~18Ix>yXuQUe>h*}Bx$Dp9gE|A;th%3Z-C3+bu@a^XTM($~l*YfLa)%t3VQ zA&WWahx`^LE=8FT8Turv)Vn>LYu5CB1>>VrdMAUoM=CosE0E}dwwBIWovc6%t(?(9 zOL_Pj7;m2nPa_}cs320?WsKywXFClK6nBjjNEk?mXbMh4 zrus`2O+AD#pk-_`5tZB%GP&IElWCYj7806@36|f~cPbrz)z%5<{k5Six3{x76lQHg zbV;p1E_4jklBIN^j9GA5B3p{3b6~d%59acm3AeRJiWC&zb$=hDu5(*w#2q{^)QnI&Hj9JX|b*?KErusOIF`J zgAP5@ADpg7#H>i5%=`39TC2DlpL>=kS%dC$PVO)fqjmEvcW3i4dZRcJQDn1{up_ZA zs?$<#3Urid;hxN^PeJjCKCNgY1RBH?eXDG_Pp`fB?)yR6r|-6nkB{fIzLFH7?#lCU zmmiN=GLX02C}wO-iy4b?`WR*&xo2UD@`rZMdBvjTpwnB%CddHt%UtxD83Lb@_78`$B^vGx%^bDzCoW>v4PkXK>dU?W~#sPKMBdkJu{U$tk0 zzug6~xzp>_4>F7ucC;ST`>UL2HGW;WxNDbRC(SjaqiJsgb`>jKJOvfK%=4>NB`ly^ zytZP?K+}#7Xen+Ux#R|?w_fwnJzexH$-;Uu7x1GDJDRPQu^N!Y9m+c4h;YT9mjy!O zcHzNEfC-T-wU(1Vlgo_bg{7St;_Tqax_HV6YZQ%=o2sFgdhM}NefmzeUj9pz52huo z4Z~dSYFT9#u=I%?FQT8lBPHHtO^MOZEMOily}}aqp@wy5dM~^KPLIv@4pHlIzm^-b z)2;DJUMo$jNn@elVUg;#j1axvZf*=}nu!Bb_~EU<#JS`Nr7fk%-9v6oLvHqbd3)9o zeV_VsfiN(&zbQndxT$x2ucaF7t$wZ7ROphMJ4X^lg+VKVYJWN;CCVpJ8i0thN0O>(4XX*xNg}!}r23$mBvyZzr|7$abh zk34IQ3)-F?%5>1x-*ODcFmCT#Q6$IPblxR=QPh<&* z81#kiIJNCX^16>76HF6?2F+bPMzQpeMS0FL*)t2<@7ca<`-GkGd?D2++7677=$>FV z?7kMos#R{-9%&+mYFk%}!+?CVMx!571 zRaD76`JRO1Ep5fzMAEm@+B$P`G$AUAXM6&V| zqvc5R-VJMVq&ARgBVRf&60yj-QH{*=^Z%KFiTZcfq5aSBss zaHC1)CYe6{Jb`sdo=(5LJ)W0O$V#A#=3peU1s~2Q72M)TZc{G?AxhncNa@a0 zJK2)RF_uM&AK20$aSmNND@hZF1iN)lIp!{yRwnM0;_&dFHO3M}F zydG*hIrGf)J2;MWxk}YDAMCc$9dW0&wH2=n0|VD3&$UY)(u@XlDuOC=GS!XY-EE~k z-M!-@WxJPw$-Z-^bFOH#ClZ^O)+2XCqr~B~9gE;<+VvF$_G43#D_xA7bV0Ee)dxyD zU^O3Lw`d9teQ#{ScTBfM(m7FmXC-2xWS*BIMo5m6r_^tPD0@#*nO}6t80W~;X+#Qk zXOvk*>zZXZK?~80&70Pem94q;gNfs?Jl?jWhU(_Ub{2X~j1|s2Y72Z)YveZ8hf9OG z^P0o;+}7&y_^8bn<+S2XGYC1oEx$azbnU7wxs4a))~t#zxM=yt^=Dmn(WbRW>CJ)M zR{XF!Ayc)sJYKhL!-ja%s*P*;&7qB})^9j>)tWV1*7o+USn4qU{~Gg z&P_g{J1Fe2scSm?dg0{fCm){Nr(0s4Jj`}K72ZGjD1|?)zC6seho`Qy|F51rG4@^F!W^kEjl1pm4?ze&{{}EkMF^6cq{3Ds_~8yT;|y39!^9!j3N)=B&TO}J+2TE=5P6{<5dm@_x|k1t4Y?9gHty_rUR3Y#`YkL zFm;o6;Vyb~qmw0O91l?J{Tfe-zRm8)Dtn7 zq#78T#OVL~zx+6P7o5D$SW5cvF|pQ04G0810|@&p5jJ0?zYKCgR(I86QLwl z2NU*=S9JdENZvgSrGA=HALW4q?H=N+zaWXwA4VTYPOhE0S&WUcL|9N|h(OS=E?y|? zsq3XVDShh3j0#0aZbN$M%bv-Hc-Ce38csea&3h0Xlm@+RzdmUiN6KHyLY+M@bzLm2 z^j_};zo%zEiJ29xnZJh!1s|45o7xli$(T6lpyzFBDWbfBfSK?d!#_w2Mx_tXNOXy7 z#+Lp#th(*DDyMFdHo75{bwC;^bfLvg{Ai`@+2kQFkFLs4J#H2*s1SMr6+%Ii2SRrr zgus+<0?>JwCm&CKVv#aai)-|p?bj~3xIcMFi!`3;*Dhtbu}E!dGH6_C*T_TA>lu*u zQZfuIHZ_vcPd$hIo_q*}&8VXR#ltdTsBx$!rbW+lW5@2@>?U7K{fO?hn^3{YXrnh1 zcGfO;pANlLsmjBiJ)zE;jS?67m@PF^CL0QuYV>Fqx?8*fR|d;RAxPr0VX5nA7Q?SD z*a%azszMOb(WV9T*m^rfmo)J5Ms9Y?(ef0;fx49kY14j@Ovd%AVgGNSLS( zqiS2A{4{D%|$`|GG^>+p-C$uhvUUncGJi=&gb8%w70Xa)f?YaH<% zVUA?JXKJs)i-&{gWHqdY+wE1Dc?g4yX|%z`ZrB(~iZLQ`UCp(ZLfRK^@LwFAycaX1 z!BwCXOd(9;-hCR7hN-1#6NH$j?J?~WD@uJy^Co`oW0E9O0uQ3=xGn`GgDEZw=iOdo zgw?di5msrML$DmavwOBv*CF6`U7Fq07iI94`sDSxk$&!JHCxm$^~@;+EvCx6vy^w6 zyaCQajH$iQm!C1sN0YevJS9`0x{(agP>1qxZlhTUOsBiJHlzMfvnQEbk-=HMlL!<-|tcr70!CmSSPAIl-zw-^n%0+v>38Pfhc-LpIVPBG(ty6 zKkSF-X2BB23_D`KyNbaxa>7wDYnIx6b(L|vbw<&$Vf(E0idrZ>xK})FkzDdKtlT7D z4FbD{dPs+G7WG{Z_kc#I&I9t(1dYKf(ju1>34z9yHEc9!-AM_H5vzFb1$wizGA8E$wh$ z=bx*cyjLs-QPUibMo%_WsfJddWb!^OIWTn-q7fPwdM>|6N{@cf35pVz(%)3MpaO!C zFs*_ncG*@cVjm9>FIaZL6q{0F+|ijkQ7%R^(^FIkW4lT*QPY@8Nj%C;(sI*Emew4}Kw3G^Uiw~f& z2>*z9eCj5Inhu!DC%IDehNc1)dRbK43xX5fOgK|qE1g7?9p{fR5 zjdI&|IHC+W$&b<=v~Cj4N>QM9b+48LAc=3XA7q&}&)3<&Lk z$#lD4rc5=mkNU+7QVVEyjgM5k7-_|{-vKt;&QAol{}?b$CUT%OjH0rPrrT7f#uuWZ zlpw$2Pt-qEW58Nn)>-ipX*=z@`lg-ojg4;E=6s)3_2~LI$tB&dLy<1?h&7i|6u^>|Xuml5cr}tL zM9FCk3*n6~>`H2L-HVcDNisxkD$!v?oMPSUXk1{JX!1ic!x}*9lw%pBRn7{Ma~D)n zuKa%T;mYruu(-NY8S18Iw*zB_Spc4T(8tCC-lPY59;&Gw9uHcMo=$5N+wK&nNUY3R z^e0rSrGzrK%Y@Jjq%im{@Vh4nqsdQFnIsS`pkb0>!vfgDHt1xRHT=@fnX7wka5;xq zS)xZgDJpm1z7V=wr&K(ollD__q70R_|D>}VY^bP4wS0jY=kNvYGCngK1}lo+lu`Dc zasp=L5U-VCgHhOjw8gd>NexT88RsFpRS(!ajgQcs2}SRq5DB`|JSZI*G#izqa@R#O zPRoK&aA@?j`3~b@rE0hV5?Q;D3n>G+vaaPUT!P|q#HP)Bn0nGAg$o;{n7W;Ogu%Pn zHKLdVJ4>1JKBN?lDELWcj~Et(8X=2mBjgGkiIC%e1CIxD(pHY2PJW>w*uY?`Oz_Pn zP!y%WN~Y5^9GV?4hoQsd&~yL&>dAX35Wb&LBVDrKF~T>bi((5UFy+G8ObQBERz6IM zK{rKc!6ed3KIXM&uapWBLJjg#)M~f%?y^EEsGo7<nrI#Fhk^>XAZevGz6g)*I?oepTQpR=KvHm_!cS?wCBFdv5hdjG+^)Ku^X0 z^3fDiDYXae3p$L(`e4vJHAw2i^h3nx-jBMWqJyFc1w0yJl(yrg)2?^=(QiV0g-*_I zv3~cv{fvJ4d-|D0VqTFeLk1_Yd#E-HQ)VSJ7#<1|O)`Fad20gEJrMJw;G*%=jTX1s zin{FLKaEqc=B}5`eKYoxb8L(PQ9CpPtufs@H^-2(T%nmE_EFW=g~PM8RCgM8KPvl+ zx=`%JZ;PAIw&`*hi(ebJX7MYOv)rKHA2+6hdBfbxteu>-f8wOi)2s(jEQt(=0i6Fk z1c_vAKLq6wYDP<9AysSB|1&I-#KVV<0+sIlxb;8P&@#kN9;6c?Y;lE^uH1R{KYKp; zX?S9fsrPH>(D^J`lSIPc(k@Iq(KBqLJAsG=gOKr)I-VBIXEkQBks=Tb)v{&gq-5+5 z^_w{nS(wz}|KOuQ6=SJHf40XyDeX~%QuYs9bSZ(fZb(tfYcQVKZ^epp9+H^rG*9t> z_mI4n>ogw7+D}!e!N#-K5YZV|x(_lC=HVKBNQB7_+d!kmEU_{9XiLeuF*OUI`SV9K zifSdS#)wLz^UQ7VxSd7kad_?2)hZy!8>b$bK?}Lo^42iOlq!i9^U&6GKGgcIb_Gu( z^*pf;Axcr*lrFDjmW33eY^qC~7L$h|(#MU;B%`Fw89$oa(Y zzLQi~*Inl2(LCO^<}R%enoC)d_>`DgqJ=?_BeF-Qmdj}{-DTcXvM5LmNwk%Z@`GX$ zS2S)4q)E*_h<}rNJad6CiY{o*n~*JMu|ujz{)*`e3v6%~kS%w)#OrcXOhf81O|eTO znAy>Qc&(zDq(r63^Kf14E|JzbKqPx~dU0kK;Bk3TaBnDvU<5i^7RX(61y5>&T~B+A z{}yfvq>@^rwdcg4$4z2^X!2ee0vHZ2%y_9YQQ)`d|8aG+G6 zNGqGC+@87;Oq6Wzp8X=9NnrK0g=9yY`(%z67HEFvY>i^*(cvkTEDCZ_<4V2h#4y zglQ3kt@DB}P$6o|)yA$ikRGo)XI8=b3+Z%Zw$9Or2KXWlx+P?Cv~r&+F*HdVi zz09f%Q!v3%M5Ad13fhG3-A=pAvxJApI?@$d;Vo;AgyA@-i6z7c-c$n3N|fyZ<1BrP+xhZ&UQ#YCf)%9GnlM zr25ueTTRr+(S!i%TZRj#F|{euY(uy|*g&I%#$RUC)KZWwv7^~xxJ?c+i}1ujX$z?P z7J7My^@lZjGU^=sE%eK^fcXFl3 z+`4IUD0!#+S$r-d8!MScXtj=x2GgtDqs%mRK@?ToYT|D06$hB%r+K!m%O+w{jyFuB zMXNR!Rwsju9694@MI`N#r#JgW9!*!dWmYB4{y^(?$-Ekb3Qxb+flATf$f9bUQXq}^ zMNUfa95UXlc*GJ=8aM9IxRaAb_-08-h>aL!`5FI>6$Qwyac)MKjWJbTVjWD>EWxUi zrZFrM$<1skoOg!0#@L!+nb8-iOO@i9d}aaatG;J|`$V_Qr?5Cc;;Ld{R}>e#uKtDu zq*=4zd{eLnVV~2&ybL(d97TV~gwIwVW)-w`3tHbIF7n_}6+FZyZ9s`8d6@z1+;k+k zL+oeTSN%znoWW3=@G%1NDH%CC{0;#_#AJa z72`{1oLLq@Mx~+CdzQ>Nqa0!TJQ6s$hMTO9 zt;kr=OEkFI0)~UyB=M9d`+zB;EDQKy2ZoW6$LYIA8b+;Dg{sWsAY%*p267>t!@`m2 zSxQs-h_tH4JxNB(%XjPL;$>Y?$r4oc+0B>yX&9TLZFy=(=1jYv{D_-aL|I&#Y7GuV z4}6K*iRln?+SH+emEjdjSkBprBdr&_8!c4fQrqaT0-^0gFqQ^zGkHk-D&wkg)%r0X z@Q|p!gO0gsb(6|M6dTzjU4Vrdla4>B722QXo2dFZh zKK^1e%4KBQlslEmQW_7t^JetkYy2y94JV>GrHM7Vni;y^H2dwDmSl{Dcfxs|C#lln z#$*;oIxl$8#{4d6ozlV5*iRljQzM$CLtE_kET%Jz{X4lywCf24ipZ@`)@ucM_|dA# zy&{UyUfS6VN+$j79+5fGwDRz@@8qOYwI+lT;f&K4OpoOsGQvxBI6BuuW)mIiY+FpP z5%35?av&vQ(NM}cZC~24TtHZm2eEIM`Mn*v<~El5t-53hT8FbJ@D68D;-2ttSK>3y zp~PpL%YL!P=i^~jJOI(u8ztQ=W=5~1G;gKKB+$f)5@r{qeaSbsgR(T4!V@d52;;KGN=!^g2vG3 zpoY zA#yz3-aHtuX#3(&XebE=cTeCQNko#Iww#3Xx0F&_0>QYJ0lbD*xDqhcV}z6m()&B9 zse~`(rHLck=Tww5cWrbN5jNzpoFpeb##F>FRo^n|rZrt6I~Pd%QDG)jN@_zQeySk- zMoGu-9}$m9{Ye`guz5YBmaSBlwp6M>?t!jN-DWi-Oldxr9(7PY zXU+Jk6z;*$$WhVIamHLlhJp(0Jz2)V#f{~OiYsT;lXF#%rJA&d%g-m8CU1@DUXsW$ z${J0ep@Mlkk@d^fwdAczym6UwO=j%@59jy~pDkz#iv>h98Ljq|=>Za8!Hm!x(R1$9 z?NitBsWHOW{{$40twv8|-ezaqf)4Kv~nucGZ%YxadO zf1$yyhBqss){+4GViirD9+|a$#47!;Quun+bGYBWWc3{G=c`tl`M1U2MkaNfB@}In z)BDfxxEh0jHTNz4Q$!b{5v7i#<+LcL^;VA}BIh>wU4agK6pLy<1+!)*L|iGFB=>Qp zgKkwuo_I!8JEw#J*Z4{FC8H<{_$SQShCHg>>^^g5&p9KV%jyG z8MUN%eE10-F{b7CxfEG&Fg779^ z_L{uchl*CoZ3~**to1bEOu7+1_@#9Wk`1G?8${)C8LnCEA*xNI)45dAQyE?2ZH{L7 zP?#10KlNc7TU%`A%$JqRX~xwo?zH#w)1P|j_$jd<-_y!Ty)yOD3#IP%JcpP|#&G63 zSTw()$qpnicdzZm0+?i4d!O~^$S{=dS%jhNBtJymSQH>SUDhf5WJ zrU6mns>lsZ!)$sF8+)JyE4Uw-{0vO;+bw+5%(SZ+KGd;I{dz!4b(k@m3N%k@p9WKM zA=kuKJj*3?lWq3iSGdW-o5InKQT4&Ft^oOJkJ?Q+g#a&G4z*acnO&5?3=UZz3cxEs zv2cS~R{kejj=j9qG@==ih!nC6HA=1RHFC}6E4X5DeTy$ul}ZZXOXf8-FB8&RcYVk> z(Bgc5*W6pqvtc47u}R8|%L~+RF&thVPmg^PPr~)GY-($bDDxZEaun}}OkdJ#d-aHR zTjvw=4+r3)>BneI9{wMwl1|6~9+eiAlmQ5x6LN00-;dY4VXt;Ya+sLYSwLt0?#7IVEP#Fd89-nRpZ3CK*?x zZpr5}Blhf!L>QhK3`%vl3kMea~eW=L;bu6ji=IrBx zU5$qPP+!q4PZED$F})0!bOQ=Tr~EzpYap8(7v65UFG#IPzNq6``r(sP<(~XRQ}Us| z)`j##f2~u=hyGe;{6l}O*i~^jIgII_`%^A$k}*zlUC>#yR@xxsQd^y)x6*T3R)d?- z>RggAH7R3(*L{H;fnV>3KbXbje&BJ&Sn`-vHBHKcvbfp!Rvi`pVvO$)2S|rsOL&lE4O&?Y?nDZ81&Tr>@^2zi zYaP8bkY2IA0}5y%s)AM7Y`x8*{We$anuLrJ5iQ9y3*)YwhQjj^q7${~0F;EvKa#tb zaV%80yG`!jigr^WfMzCP%)Y(&(%OX>}|lIY}Wok zDp+5`t@G*fTd|6tc1|{CG_%Oy#|C4eG@lCVBHzY}3RHthZBzwiZ@UPHVE?OXBSjvtdE8YS0j0lX1y3 ztSW{>$Jo1UYL>K{w>vY7EU!QmzJ*~EgGzg}-)#MXZ1PdPWB52$wsm(_(Q1z%JX#A( zN#jh~X1r@*zE|+GMLlC`{CKext#hWM6C6nKwB}JnXy*qddT*4z2?C-;ZZMIl!l1^u z!+Zr_u&WRYR!=;6E0wyj=Ne*hIh2vUg0VzVew#wWf&L>EY|EC+Md>V5YGSLf#F{X0 zsV1aX^g4uKRA6uVyK1FcD4v8@kibOFdM}O&hZd*NB5PZs8l;jD6sM6IU{8rxq=?<{ z*qi$unyrM#?2PXVx*)ct*2Pqb%h{UvG1b`89MS>&#Od^JYIa&(BRacKJY)=QZFJ+@ zk}F2WWQ|Uvg1w%{B*?e$3^cZ%1xRPc+hYx_v_o@F@oIXaB^YIPB^*+tH^*~ua4f={ z1MA!>UYDtCPckIhT35wARIFx;lcaW##*nN@2G+d;TY1lLz}S+xkc{%ViI90xVQ{An zq;*r$=}99kjTD1O`=|4+K?|i*9sc7Y8BaBR6%G%LN2O@+!;Dt7F>xe$ot&3EM;dgqJ4zJUc})GqOlze{sS6<_wnAH4_YpfNtGP55U}#dJ$e(WA`S^9x#49tLB)qhTPBYAmEeRMLqLq=(gMu zy*DC@CjpXjkN`qj%NpU=&{C0F4Adc9q_+}Om`{^)@*3Oixukk8=cN7vPb(#8>w&|w z=CY-UL5)KyUe?NBHKfFSts~Nup?-0uArAv65a77JjAP&798tHG73vE-C-5oa`S zEbW0wfbSqbwN4upI7n9Kb_}d~6<$r^W;6V%c*ZP;E}?_&;+nI9+_Ln|Ve@cXY!cR3 z&iP6 z3bw8Bl;pUBZ#I?&v}c{N^Tk0ciBi^;8>J_qGHOg^Kbx6x(@zwzS7U5Lp&-CWP0Jbl zXN=WURi>AwUwkTuwj*rD;DIX=sa8hNeVj19?z5R$OSqm$47QQJmuE&PHmV}0f=@M# znMhT9ozX~kAp~AYwp-kT5ZN*VM(Q(85{i}aW^7FpXn^Hd5qV?l%u@&u+e&Bs#pn-w>~)-r}*#Zkk1Wl;ZHRB#hw4h_n|m_fYQ zA$pW+BnL3KzZ}}fcy(HN1=$3f36%4nXc?}gi>EA6ZB$e#QcjO&-n#XOUewXLeR)Wt z5|jw}54Cez#Oa!5zq_v<3)$KsVpTe_hhjV_ph2Rx^jA?xzs&Z*U)Zz5FT6#QW;(?T zjG=s=13qD#c~exfAzw@kp{mm#zk-Vzw3&sGNJ$3|Ll^zL=TFQXO`5-hn`V9bzPD$z+Lf`kiQTnGxJ1 zLS<{Lc>?*$d^MU0J99{q$ffn|Xekf>9gUB-4TuCVq*P5ubI~GAu}SakgHlZSp^qgIQ+w!xO=E~qRNe8} zjtZJqnXR-Yd!i{Zb3tP`&p12NDJmmgvPGFxE@4O8nkSb8JajubPuqgi|7FBdv+|;W zB+%@z+Rhof+t(0cE!69*B}5lzN5d_lL^_j4krB|#K6_|Rs`R);j)4unad}$2!j96>ZQ)8Ts8kNrviU-}PtT@A?%wzbjACXYBV^^Wsy<}koGFyIH#bYqPWRT7hC$#w zct~tY2kShQBAT&$$wms2`|w!`m3kqH%wed{xb+cN0w@L4fjHVamqb)D zYT`k)-7Jg^Erpx8r$ogmAx0Kwr1=FZrgkTi`}z>r$d6Irr-?8N@Q1~ePv`2-Fqh71 z(d50Z`x!!45T-*rzr7(XmCXJj8&3W-L1%4ZOgxmDO5!@tW|(W0MrX;_(v$Te^stuw z=mE(z)qag)^wy5Cn!9Uc(5TAeFhN7v-h2izyy~}Tha(ruDcvyo4LT%w1c2_xL5DUB~+g#1}>4R7`_O$Gb|jFZ|PY!<1Uy; z;S*+>kvmBCb^7<|De8coY<;q=ug~?AQn2m%tRux{e}Sl-HkLnD+sqk|DzluE)Ur4X z3-7_9=rf%ZVrP_{n_0=H$)DWwR&b(OVrJFsv)unT47le{C{xDIr=qn6>^Y1`$Y#h= zI-|CJoSjjZpCIuj*)M5mV+Ji1NrMq-A1S4vfjULn;gt>fG-2K$UHWHE-!v(rX3drd zWjaX7E%!W$TP#Ly>r98+?c+O(tl z92+M#l=^Fh+Qd0}J43n&|3iLcLMqGRDbJa7+q~7*bf&)lmbDqvik*vJY5h{O=wApk z+`c%|z(0vr;w_9jV7DZaf12f@PC-)(MnjPWUvQR%qI8{cvDJvPl)w3zRx!@<+@zd8 zTkk1)%Oc!LFCp5ej79gwgnnUIVxO1@4&u}GG^`KKk~L$Br2xbwB70&514BUsv8{uL7b?DcQ;G5qJO+}ojzW=vXAAIp@8WY zx6FrZ`N%H>n|@`eRxIx3Q^&JE+pL7Isb+3+J#Lkm)VRjn?_Ubb>uZ`ySj=$0vng%} z$5Swh^jVT%boX2Ien{LaF$*+zxnn4N7@jbxN6Ibtgt$m{lU7`?b?atnEghStw()A| ziI!>;v*;G|w|vaQWCAtbW>&Q9O1~l6w`!nK+F9&v@bRnI_kEJK_03{^g|=XK@spZ- z8&jXP^xGs0SPvNt&HiFK3+kIl-i}d~Ck;gRpx_P>aMA6{%Fq zrkRDa0F7g_wU`VqhI~dml?1(>{%*6cnFTqh3h0kou@OL(Zt7j%%kbSR>#VsHeI~^9 zlky`pUG6Wd(z)1ab+z9UvNsAMEygqbLs#1DjcT^&&GKuMtQWl@mWq%PRaX4=Bo*>B z{U&iw)7(ABO{cxj6j|F`W{b#lm)WA=^r~75LrjNCU0=hVy9PAOGqfH^-~rA$8p%jN zDp}&>vr%fP+&1~3dsMPW)cUDE2F~h-etutjtY}#lw-M>^y8jc(*Mx#4B51Y+)i$g$ zB-0$XlmqmQu|DUTRh0=o>73Qm(y}fTg>cPe%Je~Rr7$+2&%U?Bk1x{useGyGI_l!W zFkdy!+@cb9`pM>4t1y}$IM;*>4KrSm%IVeSJ}%_LpUM7lgC( zGk47I&L^iAWKJ*0bAlbXH{+I;$lsowYGiihGdbkMIhF-f(0Utd>W-zcBWZm{vNUCVru+m88qrM~`M87LL~f$EsvK;UE1?N{jD zV6i?>E7@g#bb_CJEe+WI^v}ve6#HR#)RWCLC^%y-HTi8doRSXTyv!wTGaMei(`p|q zgntyD5e#vOvKl3Um9?eR6$qgFu@gQhWhNQ>dltO_q@c=HV@p z#Gh51tMv?fW4k`@6;I0Py<1tX^v@6CzU3vrl%I$ zReVaYjC!GQZ3=~Z__$_Y-;UzMc(pd@TvjgOM%0~eN0IxozFya3oRS{$Gfpmm*)t2< z@7ca<`-Gj*j|p>Jr zP!SAZu2HR)>n-IM)Rdg$%L}`A_ZKRIUFmJ6F)`TizVWA$>sXR_Y@%FfRtC_z#6PY5 zdUI^7T9ZE!_2J6w>{tuqvZKg%;=6RmDf*B5c~M$ZhFKX1igm%6QKEVB6Qkv*&>So^ ztZR|lN`EVb#=uC_j}KXm`kSTlp#NWOHlqIBwP>JZC;btAgJZA|;c||ZBE6(rF7+EW z8>MnRf`7QduvsfYg-D;ii6BulVwH>xM`3|-y;vT~+3%eU{-4gSH8)`x2Ky)#llEsy za{^AW6NHkLbZt{5rHo!;ci9Q|*=eB#G;RBVWb$wvW4_pVCU>7tE9gBBEXvvbO;tWx zRYe?EIN6HZFwdf*at=|4EP~j}w@2XQBWA(z?RbGE7Q`ITuP)v1rzb@wl5THa9rqeMrI8r4Em}jSYA@6KzUuA4*NP zz<-wjKn3i`4$RB62yFOkH5pG0?qfMnbFBMhA=Dx;BX+}IF@BObjJ%m6VIwe{fML^y zT8tKqv-8py2Lto6hqRow(4k4{><6(W;gd~*XB#NvW!}9oZEF$5!05b&xwG@|WXp03 z`WZ^vV{)PBeK>CgQ#LDZ%4RuNS|#46+?K%iOsUo@c`^~?by_=nB-@I;ylAeq<}gbi zVH9@)JYs<+6+1zFIj*?XpVV=fSfQlCWEh_ z(7g9Rlmzd1d4tge*|Bi%FxCVm$r<1|ltgvsL!lO diff --git a/locales/zh_Hans/LC_MESSAGES/messages.mo b/locales/zh_Hans/LC_MESSAGES/messages.mo deleted file mode 100644 index a3d93c5db85ccaf3e865a8a6aa196d95de131bc1..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 100727 zcmcef37A|}weL?WD&UB-2wDVzB&2%I)Px~qAd!TGbOIt`s=B+nyGVCeQ&pX$QISFB z$pIA*5fzXtAc%s149;Gh6|dvHj_DAb(Cc)a-|xTH-ltA?8WQe%-|H_Y|1<2f&mPuZ zYwfkx-u0vB@A1xrzt*QD$$sE9`y|O;7Rwj_B5m;>j4GsE?UfTw`UuLSN5o)+%E zG2mOkr*i+2@cgX--xKi0fFBKbU%)R0{8qsK3b-TS?*sl5RQdL5ciaculk1lSoB`_l zhX!m3*b#6(sB#|`aCyMv!RK)Qbzn2N34A_yHMl=`EBH3>%V1|ylAO}v`MkX|Nq)=q zd%+XI%jlE?NVk1{lKdFla{+D1{T<-9x!$WQNtS{?0w=%&4@;6Ob$?Nk+z);LJQpk+ zo+N$XcJLqIu}37y`@oe)Qg-rt6#NZ%(BdRHhx;#Fk|d{ceI>Yt>!&VDl7E5S;A@1- zlVlOkZvoeG{pc~23+!5vBos9{8C3tj16&PW51s-3H%OMrX)BXt8+a#p9r;}S>LmFE z*N3h0d=BQN7jS(Hcqe!=coewLao#`cz~AUTsP=y~g?t0J0VJ#Bo1os`kHWniYz?>y z{4cHt!F|Bx$0y0Y;A=qjPYqQ4&I3gkKL$mgkAU9?e-Az#{OUS?{%uh2{U`WR@Ueh< zcGKou9{}zNo(<~x#o)`p>p^|@0Z`-T`{2poW8gmEvFnrM#o#HR##KGwJHQ;*cYx0Z z9}f6a@IbB~178KcU;}*!E&#s^t_Jr94?4l?vjo)pYr^#@;J3IggL-e#iQaz4gP-HN z1U?O%P2=c!D>xfm20j%W1xLU-_!98v;AZe|;5lIRB(CY_KY?nGVJfSB+YG9HXMxWH zuLDm5KMJay4}6`cn;md2C_Zu&2BuQ;70I5@L}*1;3Wd2YeL#GI#-aXOHJ|M6ZAU)nJ|bCxHin zUjsY9KY*(5Oa|YX)V~e9f$KX;UccA$Q+Muf1eNZm14%*`B)hkGJ zpvLQWL6!gK;1KWq4phBfe|nO<5-fv!TI1@!DGOG2M++B_a^!pYzIXzCxiS;mYw1C{4Dr%uD=gHhwuLcd@8x^4jx*GVU+a?S^-O0p6xgP#H40nRzg%lRqr!(9IWJQh6n>?C;$_)U-^ zCMTTZbo4N|C)e9SwbNtZbHRUr?clR{N%cJn)OS~bD);NbXMm-E!{PZD_$=<94?+^j z72pBjGtPB-oCWU3^#V|IwgFWB=Yh)a?V!qWHF!r;lH3HUT~9vWpMMZkyWb4n3*H5G zf~Q^Jcq907u73#XyMGSXFT0TU$ZswvK5^7V-rj4#gShSo-ws{^?hU^3VyD;H;7hq) z0X_pPg3koYpz1jWJ|8?A)OX(ricUTXE&{&{svY;d#QEf5pz7Zb9s-^N>iwHRz5f9C zH1G%Dp5RZwr-F}yD)+BJ(dFMkjguE%>U{GsFvs<4!7BI$Q0adI{tWyFI2-)QWzaDA z%*(wWH-XROx(Xf$o&hS~4}g0AAyDP}9;k8qOHl3cFHrRM(zn8wz+1o(aQ@qzZ`}wU z%k@9NCE&`p`*^q%ypHR;z;)n>WO5()VXzMzxB`AhKYaz9$MvjtL7QL!TnrxbZu)`e z7lNm9{kAKU8-;*RC0WSgn1|D_|ZAgCe z-|OwN>RRugTfq18{2{OcZh9Ye0DlNVlF32WB?&_{xfvV<4<)hM;Tll&I^+XhzSF_E zTu*>%-Oce4ZH`;gAanw0)Gvbz`ug0fQ1{OwN}=l)B0=mr-FY47l8i+7lQL|^YMKesB!WRQ2AT~ehRz|+yIW=?t1ALK=Fx} ze3W*j+^fJ>bKQN1*YjHNWbVKCW3GQyKkoGUHSklU`!jekc=w%2@+ENTT}iT@^w0eS zeZ_U(-Hu-XU&r;#d*FTGxgf75``+vH@OAJ(uDd=-UBSPC6eT&IK|m3bh4(vO`xPkq z`p^STSBLNtO`Y5UJ`BF@Q%Q0u*!pSD?*Z_uT%Yk7<_h4d&-(ozf^2loLV1~rZ+K#h+_!54tbf8hP|T2S?x%yaGG}JOF&b5BoWqL2a4V<169te!~Giq-U>dI`*(tReow&91^jxz9|W8T_}hSg3;6VH{{B7z_X~Ik zsPeT3>;l#PM+ZC>d@9%L1HLBU>jD-)m8&mcCE)3x`u|*T4tND9di*pf{_!w)KKMKE zfF|f}!t;60cKAHkH-hcpX*-+_uYc6}^%uZ@@!r;7AS;ExbbV+3ugHt*bHKNNW4}(4 z+rhtrW$@qz@Puw`PHG^T+H=SQ1pEscr^G9a5MNFa1prrFSG%85qJULdHrAA z9`nfGeBSkyzx(^Y13y8!e}YGXcm2c1)1Sakas7{Q{lGt6ANo9a9QWtZNVC9m!Iy%! z1^jnV?e~;H$X)0$2in399_ZH#Hf3z8?G>*QbJ_hnA-_89(R%pU-s{ zsPwDD^=rY`b3F`-Z+rz*IUWY}-Cu$Gfqw^I4!#WKN9pH+%I^wL`F#k~dmjgt?yI2q zz@y+R!GD2D_sTt*Os}5l&j$P&cnH_u2Umhk&-Cvd3yQB7!gU?ImFo+^+ratHa(o0- zzVCi^lgXKDL4EHJ;HBUxOp5j1FTr)-RnKiQd&{ptNIw~So~Pf0u|xTM8&tV}2yO*; zfTFwN^P9~6axu6U*AIea>i-aU7uOvq|9bxypzN%_1I2e%zPQQkO6$N?Twet)=J|F| zbTRX#O*W1X15e@lgJ3_{^fKs)bc3M2ckaGT$>reXpy>IPFK@E>&bi=iq&u3#;t&75 zf0Nl~KKP0zvlBn>m0q7C1Fiz!Pr8%94}yOK)xYn{HJSeSaWKbq{{c-&FL*wv_V{JM z{{hv%Pn+R%^Kx)L*N1|l=Uz~J@y*~Xz_)>--`l|hz^{QTz~6$fhGgM^Uaz^Ya(ewd zD7riIARni{3iv;u%CX16&PhXtl z_rD9OeSQ?KU!3>*`-4jNDp38|36{aD!5hInn!UYl2Gy@$1z!!G(c<5K2t1SPb*)~X zhe4I&QBd{&EvS0!-R5-rLQw6s0-ObI0G0mD;4{GUz~_ONflBwjfVY6+^Y?&iht_s4 z_XbdOPy%OyZvbBcUJokY`#`ntXTd9Jm#>41xE}2E@7(~358Mjg0p1O&{Wr~Zybe@; z{{bEV{u)%ho;wdDzggh3xn6=$dog%CsD2&<-wD12R5|ut;QaOgP;}A-D&N(h=)MFh z-Ra@^SplyI_#yBJp5F_q{C@%Gfb$l5d-Q^Nt}g&pj=R8v!LNeK_YVR828ypfrOVsp z>7dH-d{F6UgR{Zo!2`iJf})G-K;`pvoGKp&pAEKwp8;P7{sB}!9}n@X-%bW47Y0Ge znRCMRHK5w>6QI(46Vy2U5hyAS1^xm2HTcC9&gbu3>GZJYtDBOmxc@3} z7<>R+0?s+suSY@g`5%F&f+wzOGQZDfK()gWtD8)(x&{^~*ZTcDsC*6w)$dC|m2(i3e*GO#@BaltRs!dMEf) z@E&kJct5xR{3DnHn_ugEVGXE!P6TfRN5F3IMJGF*ltIzkm%-nHd%v#9^wGb8HLj01 zh5V_{9iaN}7q9nmwPIsa@)@pc;HBWaLR0b;@N*zlP2N`YcH7b8xT@Fnx7$JSljrui zoWB7a;`()^rsUJ$L*QlL#r;jm$H09De4Ks_ypQX12Ah(z!K2Dfzn=wf=6da^P04?N ze+MrIzqQHp>ltb?JLIc|oxcA7>O1F-G?~5en2NXCpTH6Bw~V@8b}hJ>>wkgo12>=M z`q7K4UXL$;i@ASL&H2p$D873csC*XJU9Y5Xx@AIZ6v#T5o9?bQ%pybl$LGi_3fZ{Lvo#ErT8`O6n0L2f#1Zo`o z9JFx-c5=Pfn|(YT0jhq3;5Wd7&vd==&tRVG)n|D=ZvgfF72wmr>p_j<4};SCJ_?FY z-3#jbUj&uz;c)$ZQ1zPt)gFHU)gFHj*H1s&ub%@dpO*$a2;76~c2N1v2Q?lJ2bY3x z1ebuH23LYlJIBkv29$ii0o1s>3sgCO1nT>bfXeSNP;&W?pvG(R7UwT}fRdlj2X+4- za1}TURKIKvcrmDYTnDP09|kW5Zv*Fmhn?%+9R$^0r-87xWGkq8K6IWx{|=~f{1`0p z{1>3wYwZR8-bU~hT=#?OhjT%_|4vZpJ^-p59|cv!SfJ>4GQa_;X1s-4z?%I7tp()WVmzh#hO+T7#cLH(V?v5=eJwk!Yd1HiMDF#N%` z>@UaII)wA*fa0@~N#aWWf#9?;GsO|2qp%-5(0?=VN0j=yqj4DZ~+x#Wxf-ox<=jzjpi{@%#ZVQ1)pA^ms2|KfORNb`2izZjk=>8rSZ z4EQOIqr?5raUTDEz{yqIe>13YuD^90KjnCpX)Dk z@qSP|A^wT3=W-x&%%<||@Zcb>_u~+sSq+}V@g>gR1}^0o3F$rx9!PnbxYx>2;`$|A z>u(O%s7OhX<21iz@j>6_T7Ulu-W|>l=lV#_KLP%nV@}8e5nz8m0yW0}CtU01N{&vw z!|_6nD>z{7$qe3I#ZSd?hW}r|`3rfzEb|<-)ck`=bg89;4grRTU9IF{p&;r)9!{}$(;1*I>&i{p7@_FC>;$N4Kc@8f(0 z=kf0gTuWE{5cnqW-@vQDmvEfV`9q-bOi(=eChq--<1UW)SLWnk@_st^{?73)u7^2_ zA;FE@yOd)y$8{X~le{i-{#A|_slxm{%5gH+e*|9;(p}GaGv`m`Ky9&j1#a0N>W%&V zh5v8h_z1@mjte>TR|(I*2_iC+KXagxnanv5ERg2o9GYwC?>_GRizEJZg!8X(<4TTq za?A-2UkO$@F5(yn=?(=S;P_`qBY0mpe^y9yE!V#Y=Whwmq+9CmYKLSy&;LE7xggy8 zG1rJ$`}-UCRnGPYpBe6bgX`NlUdHhoj_lu|wC_=*Tg=U0a_q_Vnc(j@_Tv1#;HP>1 z6OK=E{0GN@+&d`r3#Z9`oNoc|;hFyK0Ds1D3CA6NE9n8R6tTm=R{C{rv!Xi zK;7#P=LhJ5zt=k??+y3g175+s*&Ii5{DbR3j(kWbK%}RC>p6Rv>vwVN;CNB`#837E z)^Yz{mR4TbZ4NOM?7 z|AT;gf&atve}?PKYsszC+`EQ*&*%6##|KILGV;{lA2?pcv6cHju4 zuJ;6Q;P^7f(4{e6q$&78l3;~N~G;rJT&{=_khbNzh1_;@>5lypweCZw2RjhxXIGcCMcd7Qm)(|J7Xo zH^)sJFXsLPcsTf0j`(*vCw~qX9}f3d20WYl=W#3w*Z&CVZs+>NoPUy|jbk6K|C?iJ zc>Xpp$8k-#o&lZ^&c8=G{hiG5dpl$7hI=Cc_WGJm=SQ z=x-kfn^QlF^Tpi151a=s;Lx1*$6WuK^UFipQO=(q&ilX@hVy%chb$i|)(^>z7JD}p z2THZvmU4YC*VSJhDs>e~0|WW;NPne}8!pw0eZ_jQIhj5C=u)n@rC2TH>Vw5P|CMXG zTD?-`-SNs;HCL}}DvjjIBe~I`VtJ%q+FEa(J)75-R4cVwzFO)pRZAnirQASiq*Sep z)rQ9H@zQdwcdS+`S4L{HXXliCe}x;RzFdW@s+G;Mi$|dnw3hxwkpDvR~yogbYs|t5M$Sxbmr2C_tTpkM;NG z`YI!(Ik{S?lQkY)8M{$cIeYqOfeU{K$<7a1HVd=J5Hu{jaoi$Z)fOhgWT2U&hmb3uhJZ@~b zr&RUxbtP4+o*O9+tMsGQVsE|NTk?n9^IyQQk#FBNO!8_OfLdU0sTZj6>k!M5hy(#n>Rp-R!~HB#DA zqBS>DKsA1)Ki6HVkB!zVm7!YFHov2_W8ng@lfRCnZ9(hYwvP4%^V{cfzOb`xZpYlt z)}(D=+q{Ky+rhc>=6ALw?alL(_SUwJd|P|Ib%9Ph^KEVX3#aY*_D-G7&9^Shw^`cx zB+R#30!|mEr){l`)3(Mb`C3}NRT#wXnD9;9nbZTjnJ`lVOP>MS{m&tbapH# zJ!(t=VSY8dCu6n6D+*L^V-69xIoi-RVCbHJq zAWhR>tqjM+Ysc5F%q?0wULS}wFM(Idzxm1gdMk~i2)oHG`NLAp}B~?Z(vVcr$x#AFaM#vQYL&JM7Wt({C z2IrN*%Gkglyr4WZM4r`w66NU`D-Y4SBVwD44$m~Qv0fM@bk&^ORfEr_CuV2sn6@{C z4qdQpU;x_We_D?|$~JiR(M-A~S1rCB1kI!lp2?SH zSb`b!+AQxGh_+hk8|zgMif&;3#YP+KJaQg?L_xfR<=(;EfCK{4tIF_}xTtKQ^mGti zQ>L-2rO_ei00vwd*<7wxMr;ga`hF|ip)zFLLGra{Jl6}4uB(8>9B3jmk?! zz8o6b3ZjuPRO727wXv#Kj*$^k90K)>dNIUsY|s~bktwyZhERPF;S7}&bA7OrUIhF& z_jsM+KqV&X3x!v$UA%rpfdRN)#e}dcTWVCYQ4UqQho%@Es3Kwz=2gUIU>{sc+mP7q zE&BNBt&H^3GW4G5Ar?hL32st zDMRdZQlze4GNMs?;n~JXa&=^}(FWzF2_R+TW?L%NP5tT;T3~Yhs=b4-j2fB`446I* z4TD(fHQvn-U$3U4mS{$_qBpMwR>~_YBYd0=tE0Zua)CRF@z-)Q%gv=`at?*3qfrB; zvq5Na%+>56^%AvNZ-*?}t@%6Ve@ix9Y!#k)`>*a-V2pY9<=y zG2J9`cw9kh8aln%EPd3+a$^8B=T2@rWn;_`zF#mwZi7v%Cqr*O;#`z!z?*arMeEK;J13j6jagm1s}YDrpSU)UtQ1%0xv2jNYyx5~_L+ z9>V}0=_^+IjOT_HbLqM0XcMAYfrD(zFq5A0h_t*#M>|eQIH_#{B}`K=O{$RjQX(qV zf#OK{bP9%qC_n?^pJnC;h|64ke6*BXG+3{XcD1xHuc$IA)y9^Eo*YD=6to;fD$(AjM5Q=GW|kO8VRU@7tR^lCk#A4}-zEXdYiNN&Pjg~5K z3KLtUt(rJG$x~|M>zWxN(exctpp8V48xsCBjklj?u|+zfSkcLZVn7(Vh8n87+Y~#btnx4~HHipZUmeNQI`T!!or7>@6@v*%Tf~?s2!9wUS|4xbtYv9w^AcEIsoLT%=^gTE^lg@5<(`<~i)(5y z8>=^^K%+IXl(F!z9Dps@XB=ah25A$=o<)1B%BH;4LMchBr7Ev zun5&lqv&iD0(K>R*EG0HvC+54#|w#C#xOL+OcQd?HT0t^SY~kYs%z$KDk3yLb4ukk znACPAEE<^xZ7+Q-oAs>BP+5&8IaER-2i8ReLsIo+=wLp}ee7=ZG&~2Uh;4%*FLi0A z(gh7}To$SdDu#J_v+$iql(5?auGBmL z1E56);j&D5dQKG`&up$$W_h#F%dsIFda>wx!$^56vz*-0RjYC{2T*RE_r5cOavYn+b4#C=S-Dn(SwyS`+hUvqMPCYnbzi zbed(;bL%wfm6CkXCXp~pnT1X2!;m$t_KZfMB3c|qV(BnRI4^_BqrE*8F3#4~RDC7L zPh+5%+k~NSBsWm0zza)twWx>zTb$BS#9Z_?~(a;>Um z^AGgrhGi0!#-phgO)l%mq(-vFiv<;-s2KyZoK9geDh=fCb2b~_jnPVm%&|9n*G+4Z zNf!61>t#Y6*(5O~Z3$r$Evhy!aa1sYZH94=Rx$Rr&n?W-du3y zk6r*}u8NyM38P17Ygi=Y2??PRae{k<@j)GM3>^d^GS27w>2yn_PIoz?(TqMb z$9yC;3_=o^s7zRfMllX$ruOnSb!GAhN-GW+?ulr}ll zVxqZ4(;g&G)bYogb0=Y2()$cfXTXI5IhD4WVijc@jlQ{D+G6>ezexOLOQ|Qf?jKO|IB-C`r>;l)~{bn#qkPMX()zTY;Z)0HA-a2MY1gR$+!(! zk`pYT7u_jX8wVAS**`n-&}=mb%4MUZ}Y-2Y@QJlxWA9LzT)VG0H;0)aseD3I*wX zrr{4&Mg}&zC&b)m8`a9_O&fgzoq3|kd~kS3MZvOzbTNGn#EI~PU|L?5F-vRmga$c&x<;~1NTYmHA4w5{MKvtRko`y>(m7cy z-YqJK9tz_&xdL*%G|1dFQg@@52e1Z@_1IK|S#%K-g{PDZMuVof!!lV0H{?)d02M%P z8Y>h{TR5gtkq&xvdEodlYzs_*PCoDyd6bOH(FioN2t@8`ShKj^=vWVuJ16J1JL5rOAShYtV^3ml>rz|-%8}kA zhKitRc*6%OswJ&P39$z>iWMqT<2zf-xZQZ<%n44Xhx zDoE@Rsg$mfahKM$-l)LHim6m`p%)~5s4PRIAA+G9A*hrVQ%X?Nq7s!caq;c(io`pS z2rkH&EgYHB49(lej;1Oi@O0_PYx~uqX6j$y5$Faldhd-4>zarLZbzR%N9A;ivA~P97WeNRH&84>|OYp-L>$OB?jWyjZ>sBmVl`JV&(f?(| ztwR>3QjOqkg9zoXK?{M*N<-;<#8gtT3fO&WFHY^x-X9rZ=T@z($cvVCCh{4{B+n0| zU`A}2-w!O;^5uFyx;ygqO5Q)0AGPTzlgz$S-j$T0@x1t6zL>Y7=0ysa?~^5!p|Rl+ zz!WPXA_Wv^^R>`ewN1}egJLG#z9|X=LXEzSs2f);bB$$KHOAUAUT(ms7D$if$55!M<1t4)M{>VAL3RM+9G^fO@|R0D_&~4 zwfW&rz8HN(R6vd8vu7lsLKUL0MTa&HNY6@^mehV`E$>0|*j(m2sb)D<=fGOrQbytt z{?#^b-U4`Tv+6Zev9Phw92xaYwN?;~sgB9gaxFD{@T3vbmOVGAmx*pOJA!$YR2flt zCa%picQizJ-;h+h%!Jzl+{_j~CGyQC04OdrtPG;qJBa0Tqlrps~){xvH z5mN}kLsn9tp&{b+Ok1zzH!F58)!Z=)(<~V?L=1~bCXu@NplAmRdxH*SxJ{Ll(3YBy zm7X*n%RhUG=ng!no}3dYfgx8!|DdpH~BONcfgQL>&|YZ5c^yV zLKueZR8u`l}HwNLewzazS@Rz^p4C-8TZ zpp_x1UX#a9Ey1LoEE_S)q3E)ZDn{^~22u99mekxQ3#Uv(wPq|QsJ5mX7e~vr)O|;b zohDs3e=2-Fq*4NZ+=5gW*O-f?V%uSlH|VWZT`>nFdi z=^Qjg`Vp$8DdGsaEjkVbk(S4MDv~5rwLCCb&kY*QWtDuU9qMB@o5c?zU3&*BgtB_C z>HC_4rkZam$P34m>np~3P_C9(dYI3uQ0SC@dQQcVx6vnLC$p1?SRP8+v$$nkCXHpm zaGRcV(G^=gCdYXw(>sq;3jBx1OvNq4)SVH!q2O1m`Q*Xnb3q$bh2VJ$9&bc>uc=1O zxf2=k^ktXZA8q7FI|!an*-&zGTU&F-94$@KBc7Mzc&io@hg^GGS9;pcDV}`OA(_Bf znOrY5W`I_J!s126_>)O&Rv}aU=!-EJJ5jYRF9S)M0+dSMwc+kc8KDkHmeaVQ>I#|7 zTy`{fPQILLmvnGo|G^dMA*s#7eGQf~RSqg*YKX8*v-q|23{`qCw4mrzThf=+L< zKv%~=ZEr<=Yd3Q@8LL`MEvNP6s+CKY9oN0AxgHHuveoZ?X)~|?|0!>1f^>j9aZxd9 zlw!lys=Y1#wn`egljJ2MFmNYhan>&X5868rh0#b#AOz1S|7hcg3P5hLG4rF1XUJg} zM(DI+dtuppq8#*4Mgc^=zSeymKf(HPWgnR15! z22q8p<&#Ygixlxv?Zr6S&wC;09nPzpXo+cNRCmVW9x3|07>YO7ax<9NX$DrB5&PZ3 zV7+&u<+m5{K3wc;ChkFN16o?=dt}5Eg|x*#q-nggh5;|XtuZNL;hN^h{0Z=*FutxyyfnPq@Li=;E9LD5Mq1WEJ@-e6FI>{pw+5+Z;Brb{c zjFzoq#c!q3Ib z=NU77#zrAeio&=QenmO(2Qycf<#_H(3q=oOYdvliXWMQAcHad|IEFa} zNkCLGYpCcLX(6Hk6n|P%^jR$pm=8FcO>+`H=7E2>*__9kWkqdG7Mjod($ct&HK^!3 zPlrSy7yV%|OZB2Ve_dqfSy{E&{G+KGo^})^QNAc1D0oI*VtjKugIX^v^|4AdCd1|; z=t@=&7qQqH`_y-%sfWHQ#wl%Jw5|t>`N`y=j5TRcw=jRGK?W|mYnupA7T-CE6einZ zo~B3BEG&u;)r&3d{G5EnvLre&vQZ2<1YtqYkv>_>p;AGJDj%6NN1ghs&C+oftePBa<8h3UKOVA1osOXT$M~b-+=@9fy z?_6=a)Uq6BkU1%vqTl$+5|bEfF$bf@4aWi9P#NP=y0K9Wwzl;y)WQC`?Y@xl4X8>nx@XW8gD}2i zYB#|r*S49dePr5Djbl2#qHl^6p+IGb%W%$+Rtb89xtl>lzm z{7Dj;8M3gt+{-2tG!P%ho?$9-N^^>&AbQ&qn4P*bk{{^7DB>O+7E{=2jpkx)bnB7j zzQa2^*&M(PB565e&~o?EW362AdcKXo=Hr&F&n=IktGUh@xtW{iH@C3>?f+Ae7qrh` zIHknqb(vwS>=3`9y$hkeyP>vnMf`5A+CBK;mU;YXW4Nm6h+CnDM4shJY`w8s+Io$% zyr)E8S5nM0)}Sg?PK&Q)Nr3mzzrg~b#_=%AFn@{h)r8okWfj-r9;Ilu+dg%f^XO%-*#ziyW2L$s7?XDM8F4Nr}_Q~l-g7S$p zcl8w_2Nj%A;8t~;Zb#F)%dx0QFNRfl9BK_yD!$j=Nb-Ec&FUuif^B{AAy9M!yTD%zt8O5U10E z6qr~T**lm&`f8P|n_067TSCw9DKcU9wF+d%dJhJf32xT$v(#zHs+Hncl08^cwABaN zq{v8HL1YD`d6j8Pb?$UwrOZkFp-l-J22YpHsfFDbhSpk{ENxC+T^tDtY}m3w~4k!A!}sDf1UA6T2$NUX6H4)t|$}IuLlgVSX3QbsB?goq7JQc!3MIOHf{=-N?eSzOcyQ?WUdt-jzQ6KiKP?ZWW*C|f8* zN}8nBX{B?Eo!Fa>&l)ArU45SbvuJuH7BP`sE z2P&|c%ZR9QSFOz7R*&G2*0y%h4{o+)+t7=3Jr?7*(O#A}VDjE+f$nR`af~7U+w2A> zno(bD_}aBDV*@e!%?TDEQdjsllGjMetqn`!xT9cnCqaZmT}%wptDu<1Yj?^F!a0#`w2&2KrdkKG z#dN3@70h?woU?d^IYT$=kH%`rS~?@}gZP0mbIr}k+VZFriX=RYh$Bh`X>WeFs?9bb6Rtgnn`3JG&Z)%?2%@FPMXMEwK$?R)2jQ0H2W>=wKUKU#DN<;QNND2&2$OoxSnnp>hiTHDc*|sYNbPKc zCR1D*a}cdWNF}pc(pKc=*~d!NW)eDJ9o@)PcPX$`AqqUqHz*+F|uMLq?ftSq*5qD zGerp!VxzSzw)k#F)Acqnh@eRmpd^F%OrY{}>f@gm8ARO3`GR@{J4i{|*6k4CvZ z`Kc)#LE`h8wKte99?G8U&GZ3QKt%#_OTs#SsG-lp6YQBSH7#wWI7*}E=u*i#t%2ww zPC1GL%IAuZt9>@77rXZvP$SjP&b;wSzC50J1rsmschhWwlivarJcz}~Bj&!op}d#z zsH5g(@;PaW4v)!K#*;Cd6J^pVaEP|AWo~iW&{llT)|_-JJTSq<&w`5jI48OoWs^uY z6_>|nA(t$}UD>^U!}^u0x;LW1ZN#m0c$@B9!y;azgqA)vC9*f^#&T+l9^6nSqSZo3 z-{GW-$4|WbZqhxf=`}CQU~HlpPxVX!0r8jl))_WaL`PPV$nKm8Yd8mcE^WbFWO$gF zB1#deU(t3LAqv_ilQxG*+a$YIx<(0nt9Z-P?>o8h)E$kPiH$3P%16F7e6ub!Ma&wj+)^B3V;|oq86Si1GlyvnlISX=ui31Q(z8xL|D&;uZN=nBPusTF zlTxRoKxl(@3e7i^YWh+YXgJ~0T@|&lDa4iCSnjFvri+R5$9<4qCA0yU`oV>W6WM%gh6Ag_hyr79%E8n23nk~HD_A+T*x_wI!yXp z(0UXup-~kb@FBJW58tSVvILrBvg;u+7HldDfb&nfqRSezFbXdz)`$c+4Q(!{G@={r z+oCVHp+w}TC=;2pwW^JXO8h~Ewf3?sL+YHzi~E2MedS&VB}sQnwvp!bmMc$rAkF${ zGW)TNNZsiS9zCAy}MdnFfoBBG+V`@R~G&|GeScjce)a?9&fd zNq0StlLBvXD`wF6W{eW@!^T3Mr56~kf?J3c*)V?fg0w4|ZYf*b8cpeanlZCu#Sjix zo;4qTE%Y93Q|ZRB;Oj#SNT0CJ^8m(g3pSS* zF`mf6L-B%nlEQ0?7Yi`;5W+OZ&`WRozKalvYhkIWGvi*QIMU7YSF|?yr@KnI_?r9? zg|w&NVGv9bTb7NjL6qoClVRr72DFUwbQ86x;vbUAIs2H~8B$x3hLi#)`zohv!2{IA z=b+U-`O@7X<{CIG$$}Ma)@>s(l9gqvS)2VHMc6~$$y75Po+voS0%@@HHY|ggS8Sn+ z`d%b%rBJzyx{J&RJwRRRwc0|#NJffLfMN-+5nmWf5Z0m4TSjx)#*JP`3(hp=A|jNz z00X^kaw27{Ye8#ktG^ammf8LkDHc^1M1w8)3Zw+fs@5@&dYM&|_$FMakG&1U)WBXt z%8wAcihEtkAj3W|O;a-nE0AoDulu4hT2cP%tUo1nF3aZ}U9H9*%#K14uxR;2Fy!U^ z1fNmy)R0(nu@0^03Q^2RO`TnIUe+!rMbF5VN`w`!$|5koIhKR%PuB2BOJUb*LGd(s zhQ$FFq3vyG69604%4j-IdPANE!`PH{uzIf$vuzkR(1s>$L*;8S!%&#C6gIvq+X>BU z`I)84UrEJDYVvu)tjWb&(%NCPg0sXnw1=I$0vT0_*e6kP_~6pl6$KPTVOUAXuATS| zW3Sk-@E-L~Q7bdi>jT~`l621Zi%gSge&uVS2zWHmyO^L^F313$m;xy-qEw-Yke=eN z;~10CtVkS8sCfn3qhHDrTNb13{!U+@n|Tu=I$6nEfKmpE;6u@`6YBB~Iz6zb#F z!zkgRn@iO&FTaZECe5|4huj)qUoM&Kc$O{^pgQ?p~a>7bz# z!AZ3g%{Qx13}qbmv&`1+R-2QkIvDgae!IB#`B%c|I1HZ{can`1HmFrS8R zncYnMxmefuwx8<}D-KV{R=N%|Lpj6YX4FttPk1c!scF4xWV@4R^r^5*8zp5TAorqb zDY@<~qAizfAHmGy$IByizDo6?gtWeSK(Q2SFk0ydT`y`NQ21X`pQ+-DC zRVYLgdZ-#ovW#f-Mc9c(S&9%EPTsU(;wwReBm1pZXIFcPGtKJo5EvRn8Vcxi!15%$ zB#$3~Z}C$`_|Y?*ouyG+rKfO2XJc70)3n}-Yx$%cVokM9vigOxChMayr*UTG$rw!Q za=WOF_4!~ZkQ|0H`JPYEpqvHS1<~5TEO=&BJNE1tL7jjf`VT4Od&V(@vTVl~zc0Fx zB{o=+eM2EkXGHXtv|$0JLfL}RB{V03y${BUs%`8$NG<7%Pz%m2Gz$Wf$zH5pCKv@8Y%o12n)QzIWeyXAE(Y*Nq8)_<7Jzy-un8oM!XkEY6GKfvme#1k*y%DI@gP0g5(s*}8=%jG3~{2!q-4$LYzY5-lD8kq6h z1ntnm^us5O`N|*`low)_;*U~>dOluVqN_=Eg2@wim?2w+^L5y}cvaZftr4V%klD%e zYb9qOhf$$GF7bb>#TMzvMV&J^qvKASdNod0bHhr{%}0 zLlVf^YAeqUzrNyRldba(<7`q%XDo@EDTPw*R6_Kh$>me#sRdB_K-56O>V+rQOt3h9 z!x$6oq+&@G*BoBN7%L48l(w=1Jo9FDsM_G61|P^AngMlk@zYN-G$6&&N-g>><3>KB!KtIJPNOnCA44Y3UWi0ph~jm7EwN>$*$z z^qizKvg@H_PMndPXbd%7H*7X`i9npaGE-CCpy*K>cL}MEbf-$^ zxH3j-dQQl?(O2Rd(h#WzstkQ0J!?7ikvbuyLRnnzWU*nv7_(QHvGGIcDpmZfXF*@jUKw=1H2rMa%MBD}O%hEj_~b;KKI|&FJHaP|C53K;7uLc6 zXgQ1K2)D2+Nmo4yJ*nG&_TyM}^kUnm);V;1dwm)ffe>~&GycdlH=E<6_>f?NPEJA_ z|{iwAADkm?^Dj7xHB4&tRcL0sz*ZU8^ttzuCYz9#1%tzY*cHeP}S^*OG1cJqZFFf zy6TjgD$PDffP{Pv3Qo=}Hby@f@s$_i5pV%jQX985)__H}7B?hoSv1Kda|BEp?Eq0t zNM&~0QfJ=E&jMKB{>EH_YQ=|W749@#2y&;1Yf9&bCm_$16yaW~u4_?wBtzC{P zq(bou0%n} z8uzS)uUDq202OOSOF{Y3uT!}r`f&?CIqZILbW>+Ldw=k9*u`@<%VMugQx^56ad#Ye z*6NL)YmGTiZO)!CezbL{I5yHdILf+Q)#3EsG?Vz&F4|_AH=dyRV+s8?&?xFobfImQ zd+{9bJ1#KS($LfZ<5;YzmC5um{a2in$CMU+g7WS3YW&qab%Nq|yihw~GE!S`uHjK`mEvtj!G@(b8aHveB{u3wIsN^QFyL>an6 zh7OI5GmT_{Z@E5&=ypLsdSkja&15gOWV%|_)~tuqX|_mb89?mBCnoisvy1QTqO_T! zOjl@vvTXCqUAN{FlrLt|lAcWWDVNcxa9PrRQoUwF-U)m9_`9-6q1ZA{P~u(XG;R6$ zc}Gnkk=r&vC;iU$?tBw7WzD!{%V=q9Dtva;f2FO{7KQ<;N@&+>+RzoGG|%jCosN|; zyr^HPid{#Sf$R|T;TO-p#S-ZH-oJbgdz%zmDrc-f3vCSB}iA+zu3m8p$p zRt#U_u}em?tC7&iYszSNf(jZ}Y`nO;wMw0k)7ELQym{*Ac~Y$|BPte5cpN$HZjnej zEiKrl3cD`Ot{T^}d6MmF@9bvz)3j45q_JW>Wu#A@`!_Oql2vHDxSRE8yfAHVXn~IT zYSYTZe0S9W>6=fo2I+hH(A37Ab`rBQt?sgHnhQPIa_OB|`CYI&E9P|NKOHktuxC_v zP2*3%2b57RqMvxkPAD%lswT?pJ)rTsx5goUa!|%Y@t_1vW1e$fU-2T zUQAJIPA#5(dJidDkVw9EYIln|`GvHYPx!S;e`yoSE(^kUv(M7Blk%4u*_a>>OwoKK z0)|Vh@Wt6zWu~&5pPKHq9m;#AU=^cEMw3~f(H_JHnm0g#Qu!7B{e0EEU z@{`i_cY1#}OS;p0fsq|o+1lv2k;)U#41B$rEP}xtXaOOtqqrSd9+Z#T3?WD zvwN`IpWO?B4Un4&{}@3I_SemfK!AhdU9!siI>8e*>PHI{PMICnpD$R~CEiO%u`tUm?V% z2Uv^wwQB`UWa8~CXo9d7Sv%4d_Si11u+dWzcfRIT#l!F$rt+z3R9p#qpNb_5}+U%uCG^;hRh2mJ~~Dqfr`#h#UVc$^VNlc7!js zE|@!a(ibhRy-^7UsQGMD=fZ7)9SIYgEvb}?a?qE}m;*;@E&QZgWJOaIizj?< zGW(l;7^egiKBf=tT)e4rhcTj>>(Y_?MK<=Tz)+%cMied4lfG8F-bp`Pv<=2ShUxC~0BP1Ip8TGcEq!PYIr zOhqwrtC^Dr8e;Dy9+j$k6~ih1Lj_Ta`6xpsWL&Y|Vs8#V9lv^Dp&>-G7xhW4#kGw~ zJUGQP5<&sO?&?&Hh*J9nEHNIf%we|}YcASCv4-}8LC_%d?__wGT(?;<5SqyYy9xyY zvDuTbz#iv*vYgd^M5y}3I)Mu9p(MnT4vY~V%0~mQ9br`}?d)66Y%cM!G-jHvQ9x~G z@G0akc2XJ~X}^2pi>}mC;e8L6AzDsBMG708)JayK-ioi(ie64_1`xNiY5b&pgN&#Z zdw}PAjjf4#QfF2VwWGAFv4c;>v>*4n(Vxm_!Ob=!hqU^XFYkU{NXu^~>ACJ4Vb zuK3@=iPP;QKUy|L-B%B5FiCBmtiPs7rp)$Z>Y(^eYa0u>qwo4>f?iT+ZEkCx=M>Y{ z+}Ye-C?tgfKLX0m<$hONB6a%R*7nwXYe&9yVXn2ctD~cmcUK;_ zWYvbH%j|sB%A*ZecX#(~vNMLz=F)hjns*nwJC2%rhx_d5^pO(!R-m)&PTa;#JnW=l zk0|WC&NFPWN}thj!4Dn-uo!kO2gd1d9;ZJ|!;g7{P_&`(*|P(?Ahni$;G#jY*R}K0 ziE%+8#HlEM(N~m-7PRQ)gIzK(Ev%FTBAzt%(3aa<(RhL=G*%F@uwaX3~Cf^j5U6gBsbG`KhNF{+n?JTj0o@O5%x&4mM0rU?t4UxZ(D%xUu-FsMQkN5 zd~x4smRArEH&iA$;Q=NE*&#-|V^{gbxzZ>Q=LsaOpe||XCI)RG@CRbsbN7RicrvS8^I5;u*USlbekArue5&H zKm^ek3%Mf>&vh(dD7Q{|K-;v>Z*FaFCApcAxY5?kR+x#%$*0B*Mx2r7JI|nDL%cNZ zZfC{Ry5RP^-V=?SV&90Hhj9>M5-qYueWS4vrx6}|yEZ$U2s@9l?i1l2b{g;~E8o+Z zR%FgW52L?Z#5@7yfhHOnzDS>^==1aA9Avb@uQ1UGgc13OO^rYV`Wj8Cd4mQMBBp%r zb|ZOTQ`6}3uq&!ZA;smHrkyaq^PdwXBB-YIX^;cmo>^QmB_L6wP$R^5zc9J;INM%W zFi>NOrwt6H55*1bKs_SSZ&a%*lDSYVb(=~+AZOotmb`eExtG~p$-bD49^zL56KZ)G>cP0qM0K;b3?0S5>#LzEg_yG zCAT^7cE1SvQ6dj-VkVm;Y}&w2`Sj;a<>q&0X=eYS+`cM1N#)C>dVl^@m~H-4_9V2Q z$we$#3;r)(m#%C-da&D>oQghI%M^k|$yywme=-Hh=COs$R2i5Szr_<*lPKoEswCrE zgBLx%t&!!j>2DQUT@JK*6^HV^6JtK|mSn09u+t6w9PrL@<4N3OJqbTApV+#`q+vo# zMhGV4zu}EhG}IEUp-F|hm&yzpzRa3i`5b>|ne9`H$O)WrWhOJe@?9gi zmw0-K#Z>8VRi1_;?9(_(SY+f(IjihMz20`vYPOR3WM6xCg_lD)P%jTv3fD>#cj5)` zitNl{k&5A00y1R_ec&@P;~wmL6R!AViAj2x0Q%2d!e6|rR7WIuC{O4v+_qk9l;ab32QL=`<3b|BqJz8vHnN6<@eq_FJMmzZ%>U(3s(?lc&n2cq_yZ8Woua&NHR?sfJ{?sEqbP z(iBGmQ(>O1uzj=MsnjyE=-PgjPTd}V;V@OK8rIaPx;e9pBUP%la>6Q#lpr80B+~#2 zh6Go}BzhxLumPPJ_QO6RvOOCmVbIz12{-_&hinT6%^22X>t*HxK9p1IdZSV>ej$s{ z=JczPI{6tz=Dik{n@O(f+dY|g=(F+AYeu$Q%B&dxTZs)@O2w}~YRfd{Bw^`oGQ}m3 zWc|>I@$s3nSVlEa^NVJdLWZ-^aX+!POXPt~nAbP+3qOO{0I_}qlS!fpGYvjGnwZj= zKv#(Zz3e~QlF^zj$q!z^NFtLc9O@8TEfj1TqfmC-63ygdzuJ{F9EyoCm}HWpDQ=RT zU)h&G!Qbf0ErH_n!^bnbZFva4t^_0 zwQKU)U{q>Oeko$KD|gbe#q08`*W{Nj&aGI}wR+{DuU&K8vc2`YIr;TiXlgK~O0_Gu ze8Z|$Ic;*DTeNKT;+3n8TD)}Wx@FznN08LbHTm_}mL8{2={(=J>TKpm1vD9R!*y6` zZZU(6eUyXA-+qhx^udiQC`wD?V_ms$Z|~JC_-`~xTXXB)OMF>Mem%RR@PonVbuC!i z$|Hwit1YshbN%oQ>zC&jG}5V>EHce68|kIvwUlK6rj)(c4zcgpP##m&FxxSYjM`=G z@V3L4QR&Iyt%vRXn*1^RL>1eUsf{p}s8+d7CM9hctTykROx%6r_G>PTv-{G(09I*K z^4!F^=WKuH?b|Q?$Rk(3o&eM zapT$Buf2u>OkDn9y?D;YwqJD7wtFw$e$KfQXI(vU!~H7xZJ&7Lnv28UI4!o1+S;I4_cU$X7N_fjjb%(i)D| z#hLu$t329v-_;Z6UCIY0F1UTiZ8uD5h3n3z*xn%TynW)oBj*mQGH@4mX;3HS?nOnD?`JqQYc-i*r?(-bZyXuio zUbW-4PwqJLT)UA~d+Y|f4cOMa?e2?r+<*V}YtG#MuG=5E@Ph5v+`<=`e8*+&N!$F6 z){cb>z)t=;lC}k{bK5%F7tC*;$N9p}wz(a1J6n^sg>CZ|&TR+h&YR!amSFHom;-j? z+uHN33v}9a zvZJ+q;X?B5oZr#bnzVOxcFtSap0sy%bab}2%}v_pwJmJL+mm!O>zKzepJPEXuVX=5 z``q?+N95;){Z3XV&dBg6yl|^Zrodi9K#11gbwWF`fYcA zc;ce>?KlVex;p9d-8nlJknD=vwqJ5q;! z_UecNA9>`m+ci8samS7i+&ppLIZ$I^Be%ERf6cbL?+stFW-07qj-6pZ!#Ned5?h79V z*;dSSC2*U*H&wzI5Tn3=83YDwCSwrTU>hWc?~>>Yde!*|_xE4_y`S@(BQbR5bcGppw*msI5YiCvj?Fx*S$Ee?FMre6bqjXL zPqW7-q3@dd(0*`W=I+_n`AIlPIS%LBm^unlx327KOpQ0jIf9Fx)Laum>~B}Ry6Vk( zokOH`Yhto-|5$tSAw#oPaowHU+mm;C*TKDQqpYMKYdR7x{F_zsEmI|Gnt%@8^CPm9Xg#uICnhvA=>p^e}PDEH9Z^KIjMa5Ulj%$=hgQ|`Ak z!1X-R*uBQ&T@I3oLiiTfDc4^7=jeVg2VDBkQHc#SYJERFbMKzWQG$Nltf#qobN4U) zCTuUv&6*RpXYSl=+}O`d-dB=WrY<3l70X^&`m5j68O5DoOnjgzIvM9*7@Ed*m<@zn zck|9c5V>*TRNi;{#`X4yVp`SpseygBYs~{+3uHk^ z4eL1zW|_L;S*YfB6X|>hLL!6kB_iRQ(Z2k7d;bn*?V$bsod_)451nng0`RCRaVkvn z($!q?#){`({B@rKF4hmJGS4#p{7oHSgb>x59dcMO5*DROOL+j=3})po?n9nOHW8`8 zTncuDsvr`%U0Mp72G=^mU%X_2Yy3+@mYJztGxyGMKg$Mu**dqqF?ED#*$_j`Oij&9 zUu&K|+dMttO_YuKFgtysJ&D#RwS+F>smM~fmndYt9+nxcOmf#3h-u9|qi_m(8(5&B z={y7E-ONSTy3bH(m85lQ>09bxKW0SURmS|dox!ODL;0$qYrZHkO33gM2hG2pdiLm7 z5tz$GAcr=uf5Ro<9_B^FtaUF;%V^)Y)V{nOn8+}tgB_6oBA zVi{3(gGBYlkne*XBXMbTLv+Kt=8D1bOptK@aX$}zM8PPBBZ7?sza9MK^@#l$@B+0y zxj4-ujL=ouP%P^r75Pn{LQ-fz-Zuw6Ytf)}d0Jxn*iDWBB4Xx%*aX-lcHKYFx-UaU zVplMfY~2vb9=Ij?7qk;drt6iCHLxD+Yo7brls{9~{fN5}BqBZFx6!zB#2mlL*uQ$Yc|B>pA@y$O5;FtkX zt8wQ}xsQ-=t_p>qK%?6md(RJAkd`F3K1Hs(GC%#+e5pcChr4L5NN+dFScSxgBnl%NSYZJ~ z&4ZU^&Kti87yJEt%Rw3~l4H4khzYUNnR#fbEb{H;s|tyxfB_*Y3>7pFaAEH}asXW- zNusB(0Sezh8!2g5ZiQ8)lONu^L5g&-j)%X>qm7Fssbk`fI9Uk$bZ_q8&1sfmM5$gd zePJZj38B7+N|wlk)t!sSQHl6f`-#uKaGE2mri{)}$#C<{O=NJ9o1cGZoxRxJa|6@p z?8Gh`IFmlQXB3!Pk<#1@+B|)O+vG)X;be_H`aJ?XP?src-?ehFOxYYeq}`m~g}Bc3 zP2Aa-!m6QM<)S<;H?b~GP0~q4!2YFn8`PsDO2%;=NAuxm^Y*l1P*uxo&7WZn=OmGY z5+j%%I?TPpUW6S=$Z-$;Vzfwn)p(xVq$JnXla!=Z!P0$Tpm zQJJRiowAu4aG*At-!Vk{!4Y;OLni1$I}9SaM?FKBL~vQ4(GENuP_zPc*^(x=vbpC0 z%(-}T)!T0s9+VY@ZC+Ln=>hjf=^m!{5Hc!6U1m6@Z~i#mzC6ZZX}Gf&S+C%I;5hr3 zxxcG9b{J_A!%TY;b}w5YldW2T@^_%I_k8r4a(jOh=MZRZSW6fWP#D1yuKe_4YeEJ; z_K^e&D5pJoox3YUxN`^LOE3@NM6|C zO#YG-47XsRj#!dUNUl8T_Tl@LxS;pZ&{Tcx{dg;WS>+c{*#_stu?_9nQ%75urZrx| zYunYd->`F8+$l*ac!MXXBpg*+nh}7G$Y=>fr>|t0@OmjWNvVTkg~LdVZ~QD@)aC7I zKaDW-L9aYqm8dLx9VCc|cDae|^8S~h;VpQWi#IyK(%f0L*53PBT)#2M-ysv8aue(} zxnaU+Rr4;I2X?il57*!=Qn|wj-2Cz`MkrQUhiwj0o^gF)yey^qN;sh$tZ2M$7vehZ zIeUAKUu-;tHORmO0Yp6#F|7Z7)20t``{(o?1pNQ~3#<_W{pl;SpM5jCJ1nTv*TgWw zvB$!EYK@)OkXh_1gl)u5!$~D0rX2*_-Eaez7YQ>a8*iSwi$>2JShS%>W@4f>c3#zH zw?Ay`JRo1)?y2VKtI6swdMh6o6S20|{llWGCw9`Olz4s51==9RtW&-@E_k-}c>=V> zMD$ookP^DIu3d9`jh{V;^6{~Zn3wee5bQX7=_Ro_H<+0oow++!F0aTU!Q@$uoCkd9|4RC-0=~jRb#X{{p07&sY5!BnJE@HA(?4x7k(PBVr(934p+Hm ziB5peUCf_rj`W}Bhfab*QYv3faqREQE?iZAiuxa4g?VH>Q+1rSt=_O+mI-0F2`@7w zVcSeAZ@d*N zKYNICmwSBIkD!_+3sJc>al%lMoX2Xitx#|c!4oVr_yxakQ-L<&_!R#~RYjExd#a2W z_r}ecf_sg+Usz#(K~f5(A~qO?yp?&gjBK{p4NwBycA}kfoOi$se zggyI@2wUYZSx5YhL-4$~U0Cw&vM`8Qx^<>)KHD0Ew1ov7o7L$lE?cdSTi%*HULu!n zPtfq$-Q(=EX!&Pj9?qzD>u165r%~2c<{K zib#jn4=38UZ<`P{uU|ym($qPGqigE+?Mpb+(pT2gx___u$GU!ixPeMyKLl{x1^Y9v zMQwm3QJ)lOpP`BcnPU!U)qK2SA$6r12c2~oQAoJp-4_#aMxtl1j?_QA>!kp z1-B5on`d@d*3W2wG0=A*+3^C^tX$R28Gxe&6DWj2U;i3u8-L< zrH~IS`Sq_~3etGyV)N)-WH?_r;%I~=u-?}FAM)<2(o@Y*1hv+^DcaT?l#~AHj?K~K zDkF2)x%{6BlSvUcnh%0<@axuXEas!AhNZOTpdFEzAPhKn5HK0dQa0;LOsjQa3ccA& z5a|fRd9e&@cCG-IUnl9yxvzbnjFg`BF&;?azMD z2Lhz_f7!Z@Pwjw+B?hiT`xze{2FI*)7|>neL(s;b9SYI7ere|JIjQU4?39Xr!%|jg zVMrD_O;d)-7K!}0w*xa$^Y~@#2l<#;vZ-$k18l8v2xrQbdMT2qxNeD92=9d54)%9a z#`~Q`7TNE-bTCr-RMrfA7+Dk%ww_w4fm+HeqXjl@ZrAFOMwmHq>zX~{6621Z1;>#$ ziz||4P%IX*_cp%32Jv+RQ{A00 zovw{`=^udq3bb7jK9WZcet{I+{`?fDRI?CjlV(l2Pv`xg&0*7p9U?l&t}uQGk4i>? zj`!*MrN-gC%n%gxYKVqkH!gfGlK0b2j3Nb9XMg`%$Qltdsnz|CN_E4l(?7-1C9jkp zm%dVy%^*xLLjLI^jhhdWnF^)$&OW#{#gw#mHGWe*yp zR)FHZLF>QV+g_U;{Y>&30RgF%!t}~7(|6DJztH(EH&no!Osd%7gBo+#R+Uk^9Ntr> z>55mOS3uixNau8W)zYpK&~eVtgnD|bXT!Ru?AZ0rXW3c93G|Oztz1?-0^n^t^Fl2M z74^54zy8KME8pnflJmKG%Hf3e-L=iG)mFOykFPgbO9f#s=xM=AEu%q_ZY2X6RNwR!@5c?*^Aw#Cyy(TIk5Dl7X(LRlO-GBtXBgh6>$acxxBB} zV!$44v8wV9uhI6<4kvFs{BCyiEb$z($FEqy?;L!T%dhhC%)Xsh$FqfNKaQd{BLkh! zky*EOh=o^gSams%G^3$)qvi1)4siskw-LUy6jO_zN?%$(ikNO(fqU@*p_YQSsq9O2>*jd7gh2i0$n!q6;T_$Nubhm-I-6BCn2u>=(IiO6r4@le} z8Ia-|(JydWEk@dS#Wrcjonb4IaQ?@5>);7333+Xuy^a_-d+Z?-TYXZW_KgG0?|0)_ zs>y&x6l;FgL1-VTC9csjpcnSGf`7k2Y{vHSF^RIFlF!ldi@JpLXklJgBCFsO=L6Eo zl{Y;evfeHeOhARz66>T0nsPNRkdVPz2{>v@+(uWGc`sZ%ZqFcW0MJ;bL+Aj~jq&fW zSOC{_T(3sn{YVkVR{Y24(VW;BDKW{XfG)Nf7d;CIgZ)FTGuAJW3()95BeDva7O|6A z7cFY+9FyqUlUXr(RL7gsDw@~Mmzfnre4xEWS1buPp9#zY*Au{uTgA%}7v@O+SZWdlG&4A8h_uF>4igo0; z+wmDIruY)$a1%l5Qfq{X*~Q0QM#fJej zI`mbU_o|CDSb3>b;C(Zd+UCOVBTGkg#q1`|XxdKu#u*M& zc3A+?-9}XO-qGgRI4mxdQ~lYV{NXS6&d#11S7cB)G6*JZ9m5o%c#Cv7_U&vu+|k^3 zqIrwu9c7*YU+X;vkg!W6i`!>K2oWSRi&11wTuYG=;+J~hTK5|AOR z3k?(yu~hoPliiHnc_TUwi%so=KPz#>c{U|sw3b|y+2giZGO`Jx)^qcFBXhDsPAV0E z8FdRzPGY5FBGXp)6%7jWOqx2SnGvHJ>L)!hd(GTA-M;uxhD&bd*v-bo&Dm2A1auPT z!h4-CI|;>jWJ{E-`(}2Ho`k_fd7ba2WtHw-9rCV|CMf(+W&$yv%`Dnz)_pXyVHYBR-2!sMbXyObaG8$D%P7;H| zAua-Q4oXna;q?dHnby_gjd2#Mi(#&Bz*T(MY z#?O~#9$aoexZ6A@>RQl2vhPUJbK@d?Bf%)9gRv`#>-zB}Al%Dfg91Gc9OH7a4a;{a zYB^d-h9v<1+&y}0EAgeyBQCiA)c(c7Fpb@rZ0!BEv3s1vnb|MK7|vIMo{g_|G)_O5 z{cIA8RrBaH>t+-ix7lOJI@XIKjM)AZWXGdduzABU8oP)H`azb7MT?NmU&44QgZ|RR znE%QClsKUL%0-K`3*x~%V#NJw+1(?Fpxqm79+fezv-os-=J9iLZEVg#st!-KWGL>2 zLij3^ffZ!EYpq8UTQ!rYc66BKg=$^5dwM{PpYW zH*KY2B3ZW7g4s|=Dhcas(Pf=wN4ie-QQknpBPUeZIJ4iKXg_#RELmk6lx)Ob7s;{E z83Av4`}SSJ!DcUrvNn&OV}USdPNH$(e5sMlRS>D9G=P?V{1f3}l*N1|(PReCXa@5#& zoFeQNnQrF3vVkDDqW%%Cla4Y`8BSS5fefC#dzGs9^Y;ja@+^@j;Iyj4Cj_+YaTB(V zAD_8*oa>A|wsGNGZV&eL#-xJfS|IP_Phx!6FDY9n5>00Apmd1^B!e5e`S@X(Ok-rx zgw}WGi1FY8lknx6=tY``iF4l^=Qe5`2fpS@xG!v&`6N>8&`*h~?7Y(;P*F=1^MmHe z1;90qk%i4nR+|0PE=Mslt4%#%2j3UAh;efdAU=||#diqCXD}*Qi%N#l;<rxj`fBPpn$C~qBb5(vKWRY2&45KPUo!M$Tz=XXzlPO)oToU z?%>A057%H{@Wbr9=j4Jxt4B6}`oD(O{lg0{kiVXVLFyud2QKB3+oPBX1n7v*3*Ei_j7*Dvy=r7ynxh&6`4;kiN? zJlO_aPmo=?W$U`3O{BUm`4x6YIhD|dyFo><1I~cAg=mn2aN?^^4-eU6ZXo?0?WzwzK>M0Tm7Mp`BE z(U&)&(MobD2?GLx?nTll&>zag*|g-!uc2@7d;F_#xL9E=B{>mWedepi?}kc~?WEr5CZdcw_>d11>neED%}{^cDlY>qzOsL_O(l+jTdlb06!s@Q7hC_4Xg^s+XGpXkeoGY{jkh-|1bpDfjQ z@F_y2QIqZ}uH2ZtBiWTCc&Eragkd9fCb7_O+~lPEX!x^)#1i4Q-Dj${fgftaPQ&-u zJa-3mD_0tjAwceF<3nUFGkl59tz-L9SFxSGwR~ZLuTQcEI?3IK&07;1F?d?l@Wvtp zO2>Btg~U-((5nk!fHEC*aCM=sJ5(aqXOtlkKB9fk>?>eEyw~!*c655-0R%bHyo7#{WWxs*jRunC zlCGrASR{w4)+=m3L8 zNjvWm6zp_GEH#p^QDO%M;ZwE5pet1n*kVcA^UrKQ=iPJ`m2W5@SKfH}gH!>0)sgBT zM!u6=@oyaR1gBBVk7v_7O8KF2eZw|V&`QCuON>#f+<<m+>zwX@Fmvw}GG%|H`Co(t*+Tp7Wd=(xF?_>`~%I!+Bj3@&N zqH*VIDWXEg-w2}t@1(`&$W_kLEJbGmX~pngFLBg{tkN8Ua_u5pR9yB?q*>%wd07IQ z!NUp8lQDsc^d?`uY(wf;)#~x=g)8){9{|SzM;%HAjJN4Ao)BEZ+H$cQ(j0Zyg+_*5Tlq;=Sb=Cm?mR$ERyHY}ODJWs*R? zi9D5>gYI=7?F9-03%61yo^1zROef@YsNflFf)Pm)0a(ZyK$;%OG-?rgl_IO+>PBdP zIiLwG0yYIRUCc;y6_aFiD{m)j5GNIL>{J$UMU%3Pj;3;J(|&XSne57G7wJAFhB$p zMJ7tgfDSg6)2C$W^Rx3rKL!RrjW_1|NU!Ys;~(C8x9`1`Z@jCrfPHVi@$MUGA>ggt zEeJ^w!0Z)a7`FU8&+U-T1Uqg_-B!f=pZZ5J_KXr)i3?IY5+mb_=HU|%GW!zXh;#3}C4@V6yOhnrbJDV^(HtQw!GH!TWvLyyk){nkgcT5(Mu3TM%hCy{ zK>KROQq9su8ETqRR!SJ_QdSYt&H1m`(VnqdYwAYIa$m55>ehv`$rsj8ZkW7QCC%{} zR+wl~FfVL_WXOVn?b~PDx4*G4R#6HeB)ZycBLp2M#2fHHEQJh%5BXNe_y&OVI4y%_ zSN;6b&F0l&DQpn_vt`ZJwI7oSP`2!T0Y^isafxwW0#itrWd6Etf0X;~ql9*0Z-5W6 zGiL9TQ2Lt?2)(gQU9j$Vq1c6_uTlunInP0rrOmt>Qk>SW$3vG6&ez`@;#IhhhCUt~mT08nvMO4f`XyfL z%FOy>m}DQliynH{Mb5=ktIC|%zPWN|Zh;{G^$P0B$kuh6igg>y0?5VY*xK{?Unkzw z>vKD8+qxkO0J(Agx3^Q3*5PwmmtdiX2LH#etK#icOj%J;AgL$qrcNCZth~C)By8s zhutdKR8_PbU|>2@EPIz?DY%U=0MXsHuT73sV1I4C|2c%ZaS_0WAqYL22yt;kGX=KPTXItH&U~6 zihyy?te~s&D%Bz%DfHAuDz5+W#!Y`JT$9|0(V0m~m931EJAAg5_PRza1%A7C-GU;2 zrKpc#sxu_|Kw)93YY_h6e->PH<&wh3#zcr5UM1lZ$5oAVY*_|h#wq-=EQ2dyQFGo$ z`iCX*jAb#jV<@_F-O518ziXXpeJBLPpitHUU1RK~Bks+vLf%K9pE`sntb~+Eh5%={ zepuY1kebiF z{Tq%&~;S>X^Glf0T^h7x`5rkLeVs#0?P8sj((u;!#7;K_-^+YH%p zim*<0xPyQ~?Vh=JQf2n0ul-G}UoP|%f+`7-6Dc~i*=n!wD(x%v6x9~RFbWmORF0Cs zLd@R5F9^Ab!;LyZJsk)}SWn*nhka3!K<`m({S*@;wf7kZpr_MJ6LiAnT&0gU74ri# z5s}^TWYIYnw&+wi>kxJPSEsM2nlHE1Mauv>iV@2=%K4ZS3cA|PHH!vhH>y<3Qaa0J7?#DO8ap3;Y=-H3Vm${#>W{Mkd ztxqTzjYaib9K`oiF>4B-YDScz?H9C^qD!nd4U`Y}P_fQUqSrHBR5t`|) zuoL1nbOXLRt)-Qg2iE3j1zmC1GO+O>Z4~6A32Z^VFhQ+bO*zCX#?Ml@PLkBgD>dA} z5(lHg0pYW7c_^RnnhApB3m3DALZh&E*TWHk3^@zZ*!+pQqlyL=Gy^j^XgZcH?bcEb ze0VRdu#~(?Mj3({0*(m4Hfyv_Z*Lr&ZXP;~w?xBEO}BPj(w=}Zek;DpAX4cASYPqn zW`a$kw2DEjCZkmUkqcB?JEmx0?AaH+Zs2F|zsn;duv|R_$l^(Wr6cQiYPelfr6yIC zRHSVt3&Th%h&O+dhh#1R2ZbUc^c9p6l&W#|EJVzbl}petFLX@z>31aB^z$@D`ZWR= zyVoD(aJ>am{N)=0sZZ~5AeITYYu|_wN4%Sr8=5I8cNYOvDo3nAOYCBDxDu{P*NFp0 zuApy_;9ai%ngryi?&yMN9l(dM$IzvPMtonQ(C%}M1Nbnn+P;RJ%dRagD&qd>6HQ|P z%a+NZLA+UbxUBkyR4gW9n$p<;`4>^~9F%aJborAoHGX0@c5HKjh?(x>eQRbTa2Ket z^sv`-S*28C5|7ti^f1ILFD+iYIGLgy`lr5$ZZMHUj*Q&62t%Cmm)Syj(;Tloep)ev z-0z3qH4psERe`G#@kI$aM%3QpqNmGgu?$xrF5RlLBzs&L#}t9Hp546{lL~;s2kQy~ z)Du9oqD?ZoMisYinulv08DD#`i^e8lx>Q{`$|FVR%4Xt{z%Um`HQMpWhFl6dWq~Xh z1yWgPIP6VUe>79L8P?@6A(<0uzNiT!5ah&Dz1xt3)9tdsumk0=up@-%C?U45{5R4N z^GZARgb#ayS{|L(m;1^}B1j5!KW?|r!kCa@UP6uyoABzm?w$o?=nxV*!_vpExd&Ja ztw)zEd&CUK&td*B1a*6{42Q|TgfHF67UA#%9g=OI&>zNUARD{woB`3Cfkzex|1)xru)j6HCZ;cJZATC>xD5dwGY6c%q zBrf7yZL?v=fF1Q)oZVWMzCzZo*Tak1x3Moda&dQxq5a#EZDr zsoMtb#PC)O_)9l8{IhH&xgZ{l&D=c%*$x?mv*Vz+$ zJBv|XFe^*Yqkf-FCXNFN^QG`@Vgk`uSU@R7ZfFo|7f*0$KUT(B!MiBEMjVevv#mF2 z$>*uwt*mT-Cz&EL$Vok>SI>YtFBU{JWhW)SiV|VDrB6oedBSu>pCb4{xDWK^+Q)f- z$hLKKC&o%bL%3C$zhq((`m(qOLW{9RZ4wLO?p3|XtSO|=^72Y=jAtzZ#_>W+l1AbU z8}Y0#R2%8-cImC7SJolrdcOq)_ydleRh6+X(oh0pH(!|Dh!2e}^h*WV=qB#rU7 z4iFJf6XZN~C*&Dk@^!wxT+iLg8WM_jig)*YmhCC(IA&n-NJ|=0RHmZU*=VDy)joNj zs~LJ)Q;*A+91np?H@Um9r<@NAxM`Y5@)w;&C_+ zcS%*Aa&R%DAz#~Hs+GC5eQSs?$fYKmN(!MY1NN5uvXD#eI4jR*m55O_jAY(un5^vs zhw_1heB`1ew#cQpt;Pi`q1UY_TZ1XqkQh~1KErO!7>=)Vcz@tC*_0wE6}iLORti%B zO)lYTRqd1xC$?IeE`*!ARk4hBNryifQr>B-c>f-(Iz|pc7p3Rg8IqlwP})_zpS5z; zt8cG(f7QG1z4JPhwz2!ZC45K{z-;c{6UPq=}sRGEgEbT8*B2C+ndA)X4hKp#bN z#EV;Ic;GtaU;q+S8MBXxNc-|<#35;U6!W{D6w|Ve_-nHC9}vdgm1f$Gx+5sprSq~b zPt=2bUS`D*m%QFZMn_`A6`g`PX{!?3vrOvuU@F^ZG#!F&|{i5?eMcGihW5Y0!MzgR{>E{q>%@H|&;VPjL z|Qjp z5_tkID;9AG1g3zFp`50BoYPHZUQ+q-^iIWgXN4$;nOqqdNT{78(@63-bbt^Q`pY7c z#lkdb+!&TKdx-+$dz3u0>!gjw+70klLQHVDv{V;p%Z~ug+_~8PY==T($UZ*xfI#y0 zO&&5tkU1y3&WrVd3#sA}3vQ?-Ad8(gsQ8kJJgVHn)z-mpTh|WL($tdC_({h7z#WFN zWlWIFqcx9_FsnB(po|bD!#sMaR+36H$>#!Su2@L$6ltH$FK%k9S-9|S?HADTIJoQJ z{^qz0Vve_Q?xQBSdsaj50zv^mNHXr7htKZQr~!J1T>K!NDx3)SA_B@^}LSx}(<5 zl=BC!r-k%}ud@`Pfs&9@99_!Xh*%!mTie@7cC`8XraqQqYRIz$0bqJ!fgLlX&HAeh?-q3{)`_I!m|YJWWyW_36HGEQW40F^wQ=V2KU9o3l}Yh`%E!u;&mP_PfV zhTBE$XK7?Po=O1-@~k=TKuXS4oi$})@vubkF_{3#y08>odQjpeu9~$oCCV=NSNrXY zm4jPgWw1!zCzA#{epr!G%BnuFAk`I=bfVXc2bF4|jC4p5X;3NWky$xlUzH?aMP7R8 zDsYf{GLv4sZ!rX@;1@K-ckZN(!)`Wvit6_=q?IP|Qsws)-oFYBL_&G7=uLd)1jH=Q zXi&Vp?X96T!>fn4{jWuU4B8vYl$eBH1W1!+4YF9Y+%d78j*Dy}G>QKbLLaqZXOHr5 z>kXtRuk_9_yCKjJUsD4E7PY zmV>n&+b}{r;wGmZ&Upv{@{?Rm@j3#Ee>tWEEF`t4eI$Xul1F51RP;uw7(@*aSTO;Z zIsCBKULI|`R_#SqjSv z8WZjfQxqG9;%Z+&2b}%lY^3bj6F_2A^=l(-K zf`?H~0Hb8-v2bwxUo5b04e|BqX;|W;?^BqM?{)D`r1L zXtUH*89XRI9Lwc4b>6qu@iYGq3=Y_?K`zQqJAJP>i$fq1T zTSC(d6fDIjX1Jxo_jWzubPTYiF9o&$mMzC&e<;ENqxp37cA)ROPyb zjB@NaAtV$cMEK;A8`YjY~$dT0ZMETIq=Bk zcZWTHwE5!~mQt^P&Z%bJQ?4eu%)1($YdDW!y#f192xK0+7o=;p^7P*N)mt~N{b(~) z47H0tuPq13y`BJ{d3rqN2=WU3o)1f%2Rl^vbnQ^I{FB~5?2YZr3+vrZ!X$87S(U51 z#^{0aV^%n)Yo6{2aHy_0cTqg~){zlKPS1V_4KL-UI z;*FRsgRy({?!I&atL|e(gBVbRd`O&~82S7bV_c>xi0K{()6oH*bq>l8lF0z;{vVv< z6EY(I%Hd0rp~n|`k?zU2se*o6R)4&H>o$lbX`4e^dT{Rvc%&Zl1GX}Os1(KgHACg& zn)RF39Ub_>nw^2^F)=kbu^2)pi3&hGoPdVs}3JaX%& z*cz>ScK0MGmov-*Xn@=o=hl1tPrD)?`m>>D^vM%EVfAI(y!d4uSO$tDfPyK2vV(e0 zapbNxg!J}=C6wdlB~(`+w{o9f#t8u^Z|kx1S2_*2Z|?S_rED79GQ8~(7&x+a=wr%{ z&3l}4snKH=SRH7f>yM{gX0?yH%mrM>QPzuib65JLOVJst=VCl&i*fBc9iMhzx1mGCv8DSfJo^l6e+qrnsNi8lZ z>$5Y2&LGdYiB89-+)1ayBTnQ`+4os)Cy)H3LnwPb;~vU>nrJS7=T&x|{SL-3&$=?{ zS$X?UAbc_Y{5$wF8t}054u_wN>yNp78c0?C1hE1A!Dx}rI2?y5J^u--oZG4PIMcv} z)mx}x@Ta~tltJAxuwm=^EmlCi&$LomR(diJKkUTu{@dz5|9K5b7-D`-j(OU(c6TV( z`S|HJeK7bj(lA-PPkC--+ozl$=(3U(HVoo7!=E>dw(*p6&DX8=IFn9HCg=?gk8ISY zo)LkoU7vD|ya^l3-_*|_QPdV@Se3QWkc zr#86TcAb34r0GQ2JBGq`U;hK*@XC*dKBy+|Q?j*Rm2hB+sRrkVt~E?#(CXnWgX^d` zC6P)itkqY9jMQ0UR;%LcEThp(eu+~11{LBF14fV)H(P2`mCNj?%;7Qe2Zw{Yx3opE zY(=%y1u*~s!0`-uNc#?*{z~*s)%(HSQ=BaoS)+=y48avkaawX&N5?i`*@m$)AKvRC z1)UwK905#5aEVQG-v@{FWyk8G;sz>#`|G~9S8p3wy!54)U;1@v#z@mSw2q)VrqhC4 z7yjsvQPWjLlK-k1pHDL`e(6`g>Y6dC4|Imi$5MJhHoHDS;BaX-r-&eC@po1(U#S%; zhGW#o<#ZMKJ@5om_-{puYL3(vg%PDM%2X3SR*VsyAt(W^;Zg`t1TGW6Lx4TD_guG1 z7IUZTr8sN?;1?EzRoKyCZzGWgyfQXtE(W*%L5qur>%CmQFUy7%xRycub%Pt%4h<6G z4K|Sn<~1qq!gU)A}tRp}%7)+&H3_monw)6?GolubbMlFpPJlH#gjASbp4kK>se6JO7s zP=J#5K2%jRWDwD$rS>diF zWY!z)iXw^t<-iUIyn>q9oId^C-<6+#w`rIckT#Zozso1lyNIMCcB_45vG+AGhNn&` zxdC|`<$F?v0?$_suclhDg8fVUU@v^tx3uj*rb941{u4zR*8X9oJlF<;##^$u z|KU%}g zvQahR6x)n0*%KUPxhtZqCrScGeR2Pi{$JO5inv~1(*HvLQfjr->s0Zk0JFcPG)?~t z{&w-w#eIvP?_2zGv3T(-&p-dl;^&L^R)LZ9m{VyXzFq##>uRYSSM*DVO=NMB$Q1Hf z6C}HONGMBHLM(>ZaqsvHvyD03h-z+~oTdnar49$hz(f+EBxHB*Sq1F@Fvr^wqY`gC zr@C7?N}*h*_)Fqh#6rZLR7PEA)Uliuzxjva`IoqWi+g@x>q}qkU);Z#=3(IBizWS3 z7_13RQXz+uo>utnT$L8$L8onY8WRj)wn*4j=c|#en>WK@QcDBBL#^|1h`wl)g>E9uNoy5%<~d@38H#|La$AdZ_#Mfced`uGJKmSB zw8?-T!8g34I8v?E)#?LtLLe(Ez@|rTL=)VR+@?|wU@?xo@^l%I^%}8ofY+;Y_Lq|k zn68W#>{Zgdh{B$&!S{38Oe`egC{^Xb(Uc{=F#kMt3+lszE2ESbUf6Z3sLJ7Ev0pf9 zto1vuizgaB9E^AXDmrDQpjeQeJX*P#`aho*E@-!~R>44yDzMZbiQxg4J8mlgOQjxQiNc)9mQES{Txa7N}Ky;I)b-?lKj%b%P^o zhle(cf%4g}LHPJ<_{q26?2dn9ueBth>R-F1Yf(EXMPm66Jgjox*W{J0g$1RSlJ`dj z*MHC#5;5;Tf+c?Da^3Li54Q9T4Q~0M@86)J@pN@Oa{2M#wgBW`*&X!|vk1$4>OuZ( z)5gJ($|5!o4}C(2O5d|Aq&mi*7;FRw3vTBj9##Hx1TA+~Bkx~_6g}GbSAD}QdjBH! zwR(M@Pp&VMmRc|4p7RAkp$DV-E)m^|_sx~G*dZ0Z){WHC)6cbd9H!PW>eX7`PSrMU z-SB>n7#o?Vcx4UmX$|t2Lfyy~vQ(Y(fW%uX2)w`j;0XCIuD0Sn5DkK)o&PQj7ZcNx zt02&qNK;i?6co0k%K8+m;JW3|v>w))mD!S~GC6FgRA9|lExcGJXAK?E+KMECiKYJ> zxHvO)SufRuprNdnT|cz0ZrAWE-&^k7ipN)wTq~5?Q2SNY@=HQb2S0fSCmx)+*Vt5?)L! zyDH8|K8*qr!A||zvsUkxAyVyLIV|p!WI9eh!7Ea|d|DhXePxx4Gy&($C!`R#45iT5 zV%wY+iZ~CVsES&pfvVQzCpMB9F5i?mhHZ&y1a<**nflT{e_vptL`nYp!f8QQ@kAHMCLQm~4*S zDi&-R;`Pcc)GuCG3-PZ8y3`aX760Mox?N(`^?E1(T{+#=r$y644;_=1!L9vgF4^(9 N)k1Hqb$MZG{~!C^hm-&S diff --git a/locales/zh_Hant/LC_MESSAGES/messages.mo b/locales/zh_Hant/LC_MESSAGES/messages.mo deleted file mode 100644 index b16da9fb29741db5a3a8adcb7a71b019008a0905..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6020 zcmeH~TWlOx8OIM$Xfd>fmfk3(r<7ijde*zPlh~U}bFq_H*ohlEv;l#4ynDQ!WOrse zGn>t#KG;bUJ9S*sHnFMW=6-RT`jVt=5<78)K}Z-FFdDLy_1nqUL?LlC0b zO`rAky%YR4p3A`p!9MUd@Ek~Te+rVGzXoaDJ0RKZf;8{%AlZEzj3h1qSAfew(&s6V z{PiY?sqAOq8?gT^kmBEevoHUU(Yf0F#0 zxD@;|xDE`#n6+RQr1futa1r|nsDf{U4}!I~`*ue_ivM!QjIS1-lB#;jzRf_@V@V&9IL<}9|ka%VUYjlU*zX|F&@EKAU}{VS7KDjXNnPB zC?C)N6brf(jC(Msy;7fG3l|F2%C>2`WvhwA!i9K|(o$e(Nma0_wg#-mRmDQJp~ba} zD#1mImsE#XWiV8&ghKd7w@Z{@jS?)~*3RCBf^)Z_x!X#4OKbew>Lpd7AgipZu3lVQ z$ttU>s;VnPi&*92P;D?+vxtRF(GiY7wFp~fbGuWsc*@Xpn`<3BYovKb#l3BCQ>ZbX zG)%z_ou}03HZ`v4ao(J@JMki+wVSG`35$0MOi?i`BPmFp9=AL}QB~(LBg|H%W17&T zf~`(#i5SVSI|YxYwV2=uBMN6_+3GBh8oF(2?P=SaVR)0CYR)!qUiVZv$$JP}h#e^r zwMC5d>o5`tBjZhLZdv<~#UpDBNHjY58bgnzqjsdNEx^_o$rSXopfc73L_CgHx-E3u z@@~8xp*HOYPk36fI?alvElV?Wi`5y?bQ0558;{)1ri8`Tk?t02@Iy_?nbJdocbG=f zQwsh|z+24?JZ+Ilkx0sOT@_c79PZ~bQ}{P&z2bXVd@B+OutwFg`6jVl6B!X>jT)Y| ziEPF&V-`fKHplK!XfEW|rm+=n39u#uGvNU8FJ^C}$kDxYBe&IU2v{niM!lfYr%1|Q z4F9du?Dgq(#64wLnr)a_av*OtcwE>VNo~UM)It16H|!WOQbOmNWu=9M zWn9%`5S>mWAnr-Lv*~SsH+U&Vk%SVuE+d^WH5&?Lx@;A>Kd~s)995hGV|(?(x1M0=__`?g*1mej(T7%QK-pU zP>@=O7WJ&OSj${&SSvPFW$pV}St>9j3KYp2I?}Y$Kz$%9r5ikl%UZAko(x}cEJ+I4 znpEA&2$Oq>MGp0>vW&!bB2Jb#mn zhKxm7wVOu9QXzZVVC>+_$SezX>Bf!#HG6D|)UpDaQ6cn- z1l(rX6)Per+b#H6pl)7DS(Iuz6*pD1TP&XIZ}?4#VDm_`A#5`{w?oP+JSFA54j5*f z#Ii`FuA!xMb8ACmOWWp_`nHz3uSFtw+pu9xM#ZmWs9uMC!+cBqs!dAMMx|~QU%xTj)bPkRHg2ddqhB5ca&-&w zH_R|!yScHEZ&=k-&zIFVt!ijoxvH*iQ+-Rz3QX1GX*DjCR-q>UnO3t&Ms*`%0l1A4 z%gX_2D0&z)pV!D_wosaUr?YK6YQAD_w=kFQ%9gSw-IF`vDcBK_R(qV3+6IS47 zM$?z#M@u!4ILkM;u2pL0=8>Hp!c^+@sNq#0uW8rpvgQPuMnYL@m`N+l^_2H$Ee|cl z4-$P@9$Z@XgtAWP)TPNukNZ~f>OhSW6Wh!F7tez3*a`Q=o$p=V=bYN<9vX3Xj=HZB!xsui z_u(dYvCn;>KX+y1z01R_aJnl$GQ*saQFr83XJpbn-RDeCx%+yY{vqaXo4axZ`{c)m z@;j$yk1bg4^h_1b9n1GmV;9VECeOM(dkZh0D|Wx`jQ4UJ06Em*5$uYUc;)Qv!HMJd zT{~H!x5qp8(FAv5f8p{j=Iq(+j9+4y2}S(D%*}|DY<_`Acrr#(YJ>(qf zV^YoBm8<#vqaXb+$H^Nrhw>wb-Ld1)fDVMt_};?tm*6ZsJ12**2kDu+_>BANQD@?1 z_sB)&^bSECcVM7!b<&?$JhD4~a2zWTiemrk&e#wwa!#Bs?izJ^_fUWaFVDJ+BwsiQ z#}#*7albbKm-EQ1gwjdR>Dr4h@@29RKkNv&BEpMZ=g6zWPh-ErsqW%npM$u0!V!$Z znLhXM$^1y)HAg__`F+M&_DvV7!2M^`P_B#g#ibwZhPT}-%_w1Da_&$lwWDh!zFY&|AYo$Ey8YrB) zLTgJ$H+Sr4;p(%#8wy>!-@DvRE|}>>V{->Dx#th~EloP`(i!KOmywh(%uRUE z=QlDxVX5HcnXGWW#~pmpIWd#FI9BZLo9&DKInH_RN^bfD4o&WX7oD+-47pE5FgPiL w@b4YfU>6e0S9q>d(Xou@X7v(&_vBw2rnB4sPiy!e>$Qiy|M0Z-4;6Rl{{R30 diff --git a/source/conf.py b/source/conf.py index 4d3e8dcf3..4460f9988 100644 --- a/source/conf.py +++ b/source/conf.py @@ -91,9 +91,13 @@ locale_dirs = ['../locales'] +gettext_auto_build = True # Build MO files from PO on each build + # making all documents use single text domain gettext_compact = "messages" +gettext_location = True # Include location info in the translation files + # There are two options for replacing |today|: either, you set today to some # non-false value, then it is used: # From b282ca39abbe297f17d1218ca139da10f778a477 Mon Sep 17 00:00:00 2001 From: Rafael Fontenelle Date: Sun, 5 Sep 2021 16:34:36 +0200 Subject: [PATCH 0136/1072] Translated using Weblate (Portuguese (Brazil)) Currently translated at 19.3% (440 of 2271 strings) Co-authored-by: Rafael Fontenelle Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/pt_BR/ Translation: pypa/packaging.python.org --- locales/pt_BR/LC_MESSAGES/messages.po | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/locales/pt_BR/LC_MESSAGES/messages.po b/locales/pt_BR/LC_MESSAGES/messages.po index 35eade143..8f2c2dc1e 100644 --- a/locales/pt_BR/LC_MESSAGES/messages.po +++ b/locales/pt_BR/LC_MESSAGES/messages.po @@ -8,7 +8,7 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-08-15 14:53+0000\n" +"PO-Revision-Date: 2021-09-05 14:34+0000\n" "Last-Translator: Rafael Fontenelle \n" "Language-Team: Portuguese (Brazil) \n" @@ -17,7 +17,7 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=n > 1;\n" -"X-Generator: Weblate 4.8-dev\n" +"X-Generator: Weblate 4.8.1-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -3156,11 +3156,11 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:545 msgid "Choosing a versioning scheme" -msgstr "" +msgstr "Escolhendo um esquema de versionamento" #: ../source/guides/distributing-packages-using-setuptools.rst:548 msgid "Standards compliance for interoperability" -msgstr "" +msgstr "Conformidade de padrões para interoperabilidade" #: ../source/guides/distributing-packages-using-setuptools.rst:550 msgid "" From 0c84f08adb673d3fc0381418170b964bf6a430de Mon Sep 17 00:00:00 2001 From: meowmeowmeowcat Date: Sun, 5 Sep 2021 16:34:36 +0200 Subject: [PATCH 0137/1072] Translated using Weblate (Chinese (Simplified)) Currently translated at 26.0% (592 of 2271 strings) Co-authored-by: meowmeowmeowcat Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hans/ Translation: pypa/packaging.python.org --- locales/zh_Hans/LC_MESSAGES/messages.po | 55 +++++++++++++++---------- 1 file changed, 33 insertions(+), 22 deletions(-) diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po index cc8332b72..4a101980f 100644 --- a/locales/zh_Hans/LC_MESSAGES/messages.po +++ b/locales/zh_Hans/LC_MESSAGES/messages.po @@ -11,8 +11,8 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-09-01 20:29+0000\n" -"Last-Translator: xlivevil \n" +"PO-Revision-Date: 2021-09-05 14:34+0000\n" +"Last-Translator: meowmeowmeowcat \n" "Language-Team: Chinese (Simplified) \n" "Language: zh_Hans\n" @@ -117,8 +117,8 @@ msgid "" "specific topic without a specific goal in mind. :doc:`example discussion-" "style document `." msgstr "" -"讨论 (Discussions) 的重点是理解和信息。这些探索一个特定的主题，没有具体的目" -"标。 :doc:`示例讨论式文件 `。" +"讨论 (Discussions) 的重点是理解和信息。这些探索一个特定的主题，没有具体的目标。 :doc:`示例讨论式文件 `。" #: ../source/contribute.rst:63 msgid "Specifications" @@ -161,8 +161,8 @@ msgid "" "the `Hitchhiker's Guide to Python installation instructions`_ to install " "Python 3.6 on your operating system." msgstr "" -"Python 3.6。我们的构建脚本只为 Python 3.6 而设计。请参阅 `Hitchhiker's Guide " -"to Python installation instructions`_ 以在你的操作系统上安装Python 3.6。" +"Python 3.6。我们的构建脚本只为 Python 3.6 而设计。请参阅 `Hitchhiker's Guide to Python " +"installation instructions`_ 以在你您的操作系统上安装Python 3.6。" #: ../source/contribute.rst:91 msgid "" @@ -4105,12 +4105,14 @@ msgid "" "venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the " "below commands." msgstr "" +"要创建一个虚拟环境，进入您的项目目录并运行 venv 。如果您正在使用 Python2，在下面的命令中把 ``venv`` 改为 " +"``virtualenv`` 。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 msgid "" "The second argument is the location to create the virtual environment. " "Generally, you can just create this in your project and call it ``env``." -msgstr "" +msgstr "第二个参数是创建虚拟环境的位置。一般来说，您可以直接在您的项目中创建它，并称之为 ``env`` 。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 msgid "venv will create a virtual Python installation in the ``env`` folder." @@ -4133,19 +4135,21 @@ msgid "" "will put the virtual environment-specific ``python`` and ``pip`` executables " "into your shell's ``PATH``." msgstr "" +"在您开始安装或使用虚拟环境中的软件包之前，你需要 *激活* 它。激活虚拟环境将把虚拟环境专用的 ``python`` 和 ``pip`` " +"可执行文件放入你的 shell 的 ``PATH`` 。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 msgid "" "You can confirm you're in the virtual environment by checking the location " "of your Python interpreter, it should point to the ``env`` directory." -msgstr "" +msgstr "您可以通过检查您的 Python 解释器的位置来确认您在虚拟环境中，它应该指向 ``env`` 目录。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 msgid "" "As long as your virtual environment is activated pip will install packages " "into that specific environment and you'll be able to import and use packages " "in your Python application." -msgstr "" +msgstr "只要您的虚拟环境被激活，pip 就会将软件包安装到该特定环境中，您就可以在您的 Python 应用程序中导入和使用软件包。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 msgid "Leaving the virtual environment" @@ -4155,7 +4159,7 @@ msgstr "离开虚拟环境" msgid "" "If you want to switch projects or otherwise leave your virtual environment, " "simply run:" -msgstr "" +msgstr "如果您想切换项目或以其他方式离开你的虚拟环境，只需运行：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 msgid "" @@ -4173,15 +4177,17 @@ msgid "" "Now that you're in your virtual environment you can install packages. Let's " "install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" msgstr "" +"现在您在您的虚拟环境中，您可以安装软件包。让我们从 :term:`Python Package Index (PyPI)` 中安装 `Requests`" +"_ 库：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 msgid "" "pip should download requests and all of its dependencies and install them:" -msgstr "" +msgstr "pip应该下载 request 及其所有的依赖项并安装它们：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 msgid "Installing specific versions" -msgstr "" +msgstr "安装特定版本" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 msgid "" @@ -4189,32 +4195,34 @@ msgid "" "`version specifiers `. For example, to install a specific " "version of ``requests``:" msgstr "" +"pip 允许您使用 :term:`版本指定器 `来指定安装哪个版本的软件包。例如，要安装一个特定版本的 " +"``requests``：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 msgid "To install the latest ``2.x`` release of requests:" -msgstr "" +msgstr "要安装最新的 ``2.x`` 版本的 requests：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 msgid "To install pre-release versions of packages, use the ``--pre`` flag:" -msgstr "" +msgstr "要安装预发布（pre-release）版本的软件包，请使用 ``--pre`` 标志：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 msgid "Installing extras" -msgstr "" +msgstr "安装附加功能" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 msgid "" "Some packages have optional `extras`_. You can tell pip to install these by " "specifying the extra in brackets:" -msgstr "" +msgstr "有些软件包有可选的 `额外功能 `_ 。你可以通过在括号中指定额外的东西来告诉 pip 安装这些东西：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 msgid "Installing from source" -msgstr "" +msgstr "从源文件安装" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 msgid "pip can install a package directly from source, for example:" -msgstr "" +msgstr "pip 可以直接从源代码安装一个软件包，例如：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 msgid "" @@ -4222,22 +4230,24 @@ msgid "" "meaning that changes to the source directory will immediately affect the " "installed package without needing to re-install:" msgstr "" +"此外，pip 可以在 `开发模式 `_ " +"下从源码安装软件包，这意味着源码目录的变化将立即影响已安装的软件包，而不需要重新安装：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 msgid "Installing from version control systems" -msgstr "" +msgstr "从版本控制系统进行安装" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 msgid "" "pip can install packages directly from their version control system. For " "example, you can install directly from a git repository:" -msgstr "" +msgstr "pip 可以直接从他们的版本控制系统中安装软件包。例如，你可以直接从 git 仓库中安装：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 msgid "" "For more information on supported version control systems and syntax, see " "pip's documentation on :ref:`VCS Support `." -msgstr "" +msgstr "关于支持的版本控制系统和语法的更多信息，请参见 pip 的文档：:ref:`VCS Support ` 。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 #: ../source/tutorials/installing-packages.rst:569 @@ -4266,13 +4276,14 @@ msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 msgid "Using other package indexes" -msgstr "" +msgstr "使用其他软件包的索引" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 msgid "" "If you want to download packages from a different index than the :term:" "`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" msgstr "" +"如果您想从不同的索引下载软件包，而不是 :term:`Python 软件包索引（PyPI）` ，您可以使用 ``--index-url`` 标志：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 msgid "" From c77826c49b7fc790c17dfb552d42107515b6f55d Mon Sep 17 00:00:00 2001 From: Sviatoslav Sydorenko Date: Sun, 5 Sep 2021 16:34:37 +0200 Subject: [PATCH 0138/1072] Translated using Weblate (Ukrainian) Currently translated at 20.7% (471 of 2271 strings) Co-authored-by: Sviatoslav Sydorenko Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/uk/ Translation: pypa/packaging.python.org --- locales/uk/LC_MESSAGES/messages.po | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/locales/uk/LC_MESSAGES/messages.po b/locales/uk/LC_MESSAGES/messages.po index d77f6bc14..5f9e45967 100644 --- a/locales/uk/LC_MESSAGES/messages.po +++ b/locales/uk/LC_MESSAGES/messages.po @@ -11,7 +11,7 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-09-01 20:29+0000\n" +"PO-Revision-Date: 2021-09-05 14:34+0000\n" "Last-Translator: Sviatoslav Sydorenko \n" "Language-Team: Ukrainian \n" @@ -89,7 +89,7 @@ msgstr "" #: ../source/contribute.rst:38 ../source/tutorials/index.rst:2 msgid "Tutorials" -msgstr "Туторіали" +msgstr "Навчальні інструкції" #: ../source/contribute.rst:40 msgid "" @@ -375,7 +375,7 @@ msgstr "Домовленості й механіка" #: ../source/contribute.rst:192 msgid "**Write to the reader**" -msgstr "**Пишіть читачеві**" +msgstr "**Звертайтеся до читачів**" #: ../source/contribute.rst:187 msgid "" @@ -383,7 +383,7 @@ msgid "" "use the imperative mood." msgstr "" "Коли ви даєте рекомендації або вказуєте необхідні кроки, звертайтеся до " -"читача як *ви* або використовуйте наказовий спосіб." +"читачів на *ви* або використовуйте наказовий спосіб." #: ../source/contribute.rst:0 msgid "Wrong: To install it, the user runs…" @@ -1501,7 +1501,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:43 msgid "Public dataset" -msgstr "" +msgstr "Публічний набір даних" #: ../source/guides/analyzing-pypi-package-downloads.rst:45 msgid "" @@ -1512,7 +1512,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:50 msgid "Getting set up" -msgstr "" +msgstr "Налаштування" #: ../source/guides/analyzing-pypi-package-downloads.rst:52 msgid "" @@ -1526,7 +1526,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:58 msgid "Navigate to the `BigQuery web UI`_." -msgstr "" +msgstr "Перейдіть до `веб-інтерфейсу BigQuery `_." #: ../source/guides/analyzing-pypi-package-downloads.rst:59 msgid "Create a new project." @@ -1537,6 +1537,8 @@ msgid "" "Enable the `BigQuery API `__." msgstr "" +"Увімкніть `BigQuery API `__." #: ../source/guides/analyzing-pypi-package-downloads.rst:63 msgid "" From c190eb32a2771dc33b9146cf9edd13f18aa54cf7 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Mon, 6 Sep 2021 18:20:43 +0800 Subject: [PATCH 0139/1072] Rearrange links in alphabetical order --- source/conf.py | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/source/conf.py b/source/conf.py index e2ee8ec87..48eef1f0f 100644 --- a/source/conf.py +++ b/source/conf.py @@ -394,14 +394,14 @@ # Example configuration for intersphinx: refer to the Python standard library. intersphinx_mapping = { + 'openstack': ('https://docs.openstack.org/glance/latest/', None), 'python': ('https://docs.python.org/3', None), 'python2': ('https://docs.python.org/2', None), 'pip': ('https://pip.pypa.io/en/latest/', None), + 'scipy': ('https://www.scipy.org', None), 'setuptools': ('https://setuptools.readthedocs.io/en/latest/', None), - 'twine': ('https://twine.readthedocs.io/en/stable/', None), 'tox': ('https://tox.readthedocs.io/en/latest/', None), - 'scipy': ('https://www.scipy.org', None), - 'openstack': ('https://docs.openstack.org/glance/latest/', None), + 'twine': ('https://twine.readthedocs.io/en/stable/', None), } From 095c966712aaa48e0350cead365571d3a1bde79e Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Mon, 6 Sep 2021 18:28:32 +0800 Subject: [PATCH 0140/1072] Revert the change to the link of Discourse --- source/glossary.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/glossary.rst b/source/glossary.rst index 0c09cfe10..79b4d64cb 100644 --- a/source/glossary.rst +++ b/source/glossary.rst @@ -133,7 +133,7 @@ Glossary `_, and discuss issues on the `distutils-sig mailing list `_ - and `the Python Discourse forum `__. + and `the Python Discourse forum `__. Python Package Index (PyPI) From d9eef39d7e18402d2a82f20cb67d22a626dc095c Mon Sep 17 00:00:00 2001 From: Eric Date: Mon, 13 Sep 2021 12:46:41 +0200 Subject: [PATCH 0141/1072] Translated using Weblate (Chinese (Simplified)) Currently translated at 26.3% (598 of 2271 strings) Co-authored-by: Eric Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hans/ Translation: pypa/packaging.python.org --- locales/zh_Hans/LC_MESSAGES/messages.po | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po index 4a101980f..3099f598d 100644 --- a/locales/zh_Hans/LC_MESSAGES/messages.po +++ b/locales/zh_Hans/LC_MESSAGES/messages.po @@ -6,13 +6,14 @@ # bluewindde <13548563428@139.com>, 2021. # Cube Kassaki <2524737581@qq.com>, 2021. # xlivevil , 2021. +# Eric , 2021. msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-09-05 14:34+0000\n" -"Last-Translator: meowmeowmeowcat \n" +"PO-Revision-Date: 2021-09-13 10:46+0000\n" +"Last-Translator: Eric \n" "Language-Team: Chinese (Simplified) \n" "Language: zh_Hans\n" @@ -20,7 +21,7 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=1; plural=0;\n" -"X-Generator: Weblate 4.8.1-dev\n" +"X-Generator: Weblate 4.9-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -162,7 +163,7 @@ msgid "" "Python 3.6 on your operating system." msgstr "" "Python 3.6。我们的构建脚本只为 Python 3.6 而设计。请参阅 `Hitchhiker's Guide to Python " -"installation instructions`_ 以在你您的操作系统上安装Python 3.6。" +"installation instructions`_ 将 Python 3.6 安装于您的操作系统中。" #: ../source/contribute.rst:91 msgid "" @@ -656,8 +657,9 @@ msgid "" "what index or source). The where (i.e. how they are to be made \"Concrete" "\") is to be determined at install time using :ref:`pip` options. [1]_" msgstr "" -"最后，重要的是要了解“install_requires”是“Abstract”要求的列表，即只是名称和版本限制，并不能确定从哪里满足依赖关系（即从什么索引" -"或来源）。在安装时使用 :ref:`pip` 选项确定在哪里（即如何使它们“Concrete”）。 [1]_" +"最后，重要的是要了解 ``install_requires`` " +"是“Abstract”要求的列表，即只是名称和版本限制，并不能确定从哪里满足依赖关系（即从什么索引或来源）。在安装时使用 :ref:`pip` " +"选项确定在哪里（即如何使它们“Concrete”）。 [1]_" #: ../source/discussions/install-requires-vs-requirements.rst:64 #: ../source/tutorials/installing-packages.rst:460 @@ -699,8 +701,8 @@ msgid "" "\"Concrete\", i.e. associated with a particular index or directory of " "packages. [1]_" msgstr "" -"而“install_requires”需求是“Abstract”，即不与任何特定索引相关联，需求文件通常包含诸如“--index-url”或" -"“--find-links”之类的pip选项来提出需求“Concrete”，即与包的特定索引或目录相关联。 [1]_" +"而 ``install_requires`` 需求是“Abstract”的，即不与任何特定索引相关联，需求文件通常包含 pip 选项，如 " +"``--index-url`` 或 ``--find-links`` 使需求“Concrete”，即与包的特定索引或目录相关联。 [1]_" #: ../source/discussions/install-requires-vs-requirements.rst:84 msgid "" @@ -1500,7 +1502,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:58 msgid "Navigate to the `BigQuery web UI`_." -msgstr "导航到 `BigQuery 网页界面`_ 。" +msgstr "导航到 `BigQuery 网页用户界面`_。" #: ../source/guides/analyzing-pypi-package-downloads.rst:59 msgid "Create a new project." @@ -3266,7 +3268,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:693 #: ../source/specifications/core-metadata.rst:722 msgid "Examples::" -msgstr "例子：:" +msgstr "例子::" #: ../source/guides/dropping-older-python-versions.rst:86 msgid "" From 731db557a5fedd571c6f645cf36361535d6db67c Mon Sep 17 00:00:00 2001 From: Zuorong Zhang Date: Mon, 13 Sep 2021 12:46:41 +0200 Subject: [PATCH 0142/1072] Translated using Weblate (Chinese (Simplified)) Currently translated at 26.3% (598 of 2271 strings) Co-authored-by: Zuorong Zhang Translate-URL: https://hosted.weblate.org/projects/pypa/packaging-python-org/zh_Hans/ Translation: pypa/packaging.python.org --- locales/zh_Hans/LC_MESSAGES/messages.po | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po index 3099f598d..70af2f8f0 100644 --- a/locales/zh_Hans/LC_MESSAGES/messages.po +++ b/locales/zh_Hans/LC_MESSAGES/messages.po @@ -13,7 +13,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" "PO-Revision-Date: 2021-09-13 10:46+0000\n" -"Last-Translator: Eric \n" +"Last-Translator: Zuorong Zhang \n" "Language-Team: Chinese (Simplified) \n" "Language: zh_Hans\n" @@ -1022,6 +1022,8 @@ msgid "" "to distribute a :term:`Release`. The archive file is what an end-user will " "download from the internet and install." msgstr "" +"一个版本化的存档文件包含 Python :term:`packages `、:term:`modules " +"` 和其他用于分发:term:`Release` 的资源文件的版本化存档文件。存档文件是最终用户将从 Internet 下载并安装的文件。" #: ../source/glossary.rst:34 msgid "" @@ -1033,6 +1035,9 @@ msgid "" "distribution), which are often referred to with the single term " "\"distribution\"." msgstr "" +"分发包更常被称为“包”或“分发”，但是当需要更清楚地防止与 :term:`Import Package` " +"混淆时，本指南可能会使用扩展术语（通常也称为“包”）或另一种发行版（例如 Linux 发行版或 Python " +"语言发行版），通常用单个术语“发行版”来指代。" #: ../source/glossary.rst:41 msgid "Egg" @@ -1069,7 +1074,7 @@ msgstr "" #: ../source/glossary.rst:59 msgid "Known Good Set (KGS)" -msgstr "" +msgstr "已知良好集 (KGS)" #: ../source/glossary.rst:62 msgid "" @@ -1098,7 +1103,7 @@ msgid "" "\", but this guide will use the expanded term when more clarity is needed to " "prevent confusion with a :term:`Distribution Package` which is also commonly " "called a \"package\"." -msgstr "" +msgstr "导入包通常用单个词“包”来指代，但本指南将在需要更清楚地说明时使用扩展术语，以防止与通常也称为“包”的 :term:`分发包` 混淆." #: ../source/glossary.rst:78 msgid "Module" @@ -1109,6 +1114,8 @@ msgid "" "The basic unit of code reusability in Python, existing in one of two types: :" "term:`Pure Module`, or :term:`Extension Module`." msgstr "" +"Python 中代码可重用性的基本单元，存在于以下两种类型之一：:term:`Pure Module` 或 :term:`Extension " +"Module`。" #: ../source/glossary.rst:84 msgid "Package Index" @@ -1118,7 +1125,7 @@ msgstr "包索引 (Package Index)" msgid "" "A repository of distributions with a web interface to automate :term:" "`package ` discovery and consumption." -msgstr "" +msgstr "一个带有 Web 界面的发行版存储库，用于自动化 :term:`package ` 发现和消费。" #: ../source/glossary.rst:90 msgid "Per Project Index" From b018b14285e795950f8e473cc9ac617915ce69f4 Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sat, 4 Sep 2021 14:30:28 +0800 Subject: [PATCH 0143/1072] Remove an empty line Co-authored-by: Sviatoslav Sydorenko --- source/conf.py | 1 - 1 file changed, 1 deletion(-) diff --git a/source/conf.py b/source/conf.py index a994b7bfb..ccba7dfd1 100644 --- a/source/conf.py +++ b/source/conf.py @@ -383,7 +383,6 @@ 'user': (f'{github_sponsors_url}/%s', '@'), # noqa: WPS323 } - linkcheck_ignore = [ "http://localhost:\d+", # Ignoring these links as they will redirect to login page if folks haven't logged in. From 81823d33fac15541a6d0ea95d9165a2c927bcd7d Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Mon, 6 Sep 2021 18:28:32 +0800 Subject: [PATCH 0144/1072] Revert the change to the link of Discourse --- source/glossary.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/glossary.rst b/source/glossary.rst index 0c09cfe10..79b4d64cb 100644 --- a/source/glossary.rst +++ b/source/glossary.rst @@ -133,7 +133,7 @@ Glossary `_, and discuss issues on the `distutils-sig mailing list `_ - and `the Python Discourse forum `__. + and `the Python Discourse forum `__. Python Package Index (PyPI) From 163b5d828e3675d9f283f51a802c9b7cd3b0ac5b Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sat, 4 Sep 2021 14:30:28 +0800 Subject: [PATCH 0145/1072] Remove an empty line Co-authored-by: Sviatoslav Sydorenko --- source/conf.py | 1 - 1 file changed, 1 deletion(-) diff --git a/source/conf.py b/source/conf.py index 17ceca3fb..16823566a 100644 --- a/source/conf.py +++ b/source/conf.py @@ -387,7 +387,6 @@ 'user': (f'{github_sponsors_url}/%s', '@'), # noqa: WPS323 } - linkcheck_ignore = [ "http://localhost:\d+", # Ignoring these links as they will redirect to login page if folks haven't logged in. From 540cc9caf51405dc78898a8d14cb36aa4e05c588 Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Mon, 6 Sep 2021 18:28:32 +0800 Subject: [PATCH 0146/1072] Revert the change to the link of Discourse --- source/glossary.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/glossary.rst b/source/glossary.rst index 0c09cfe10..79b4d64cb 100644 --- a/source/glossary.rst +++ b/source/glossary.rst @@ -133,7 +133,7 @@ Glossary `_, and discuss issues on the `distutils-sig mailing list `_ - and `the Python Discourse forum `__. + and `the Python Discourse forum `__. Python Package Index (PyPI) From dbd6d70517f662a2796b676cd7b1d29832de1cf6 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 18 Sep 2021 13:02:15 +0800 Subject: [PATCH 0147/1072] Revert "Merge branch 'main' into new" This reverts commit 9058b71451a89bf1a415dd1c9d46937b0932e738, reversing changes made to c41dbce2fe8e753e190917cf4af19767d3ac0b36. --- locales/zh_Hans/LC_MESSAGES/messages.po | 35 +++++++++---------------- 1 file changed, 13 insertions(+), 22 deletions(-) diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po index 70af2f8f0..4a101980f 100644 --- a/locales/zh_Hans/LC_MESSAGES/messages.po +++ b/locales/zh_Hans/LC_MESSAGES/messages.po @@ -6,14 +6,13 @@ # bluewindde <13548563428@139.com>, 2021. # Cube Kassaki <2524737581@qq.com>, 2021. # xlivevil , 2021. -# Eric , 2021. msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-09-13 10:46+0000\n" -"Last-Translator: Zuorong Zhang \n" +"PO-Revision-Date: 2021-09-05 14:34+0000\n" +"Last-Translator: meowmeowmeowcat \n" "Language-Team: Chinese (Simplified) \n" "Language: zh_Hans\n" @@ -21,7 +20,7 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=1; plural=0;\n" -"X-Generator: Weblate 4.9-dev\n" +"X-Generator: Weblate 4.8.1-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -163,7 +162,7 @@ msgid "" "Python 3.6 on your operating system." msgstr "" "Python 3.6。我们的构建脚本只为 Python 3.6 而设计。请参阅 `Hitchhiker's Guide to Python " -"installation instructions`_ 将 Python 3.6 安装于您的操作系统中。" +"installation instructions`_ 以在你您的操作系统上安装Python 3.6。" #: ../source/contribute.rst:91 msgid "" @@ -657,9 +656,8 @@ msgid "" "what index or source). The where (i.e. how they are to be made \"Concrete" "\") is to be determined at install time using :ref:`pip` options. [1]_" msgstr "" -"最后，重要的是要了解 ``install_requires`` " -"是“Abstract”要求的列表，即只是名称和版本限制，并不能确定从哪里满足依赖关系（即从什么索引或来源）。在安装时使用 :ref:`pip` " -"选项确定在哪里（即如何使它们“Concrete”）。 [1]_" +"最后，重要的是要了解“install_requires”是“Abstract”要求的列表，即只是名称和版本限制，并不能确定从哪里满足依赖关系（即从什么索引" +"或来源）。在安装时使用 :ref:`pip` 选项确定在哪里（即如何使它们“Concrete”）。 [1]_" #: ../source/discussions/install-requires-vs-requirements.rst:64 #: ../source/tutorials/installing-packages.rst:460 @@ -701,8 +699,8 @@ msgid "" "\"Concrete\", i.e. associated with a particular index or directory of " "packages. [1]_" msgstr "" -"而 ``install_requires`` 需求是“Abstract”的，即不与任何特定索引相关联，需求文件通常包含 pip 选项，如 " -"``--index-url`` 或 ``--find-links`` 使需求“Concrete”，即与包的特定索引或目录相关联。 [1]_" +"而“install_requires”需求是“Abstract”，即不与任何特定索引相关联，需求文件通常包含诸如“--index-url”或" +"“--find-links”之类的pip选项来提出需求“Concrete”，即与包的特定索引或目录相关联。 [1]_" #: ../source/discussions/install-requires-vs-requirements.rst:84 msgid "" @@ -1022,8 +1020,6 @@ msgid "" "to distribute a :term:`Release`. The archive file is what an end-user will " "download from the internet and install." msgstr "" -"一个版本化的存档文件包含 Python :term:`packages `、:term:`modules " -"` 和其他用于分发:term:`Release` 的资源文件的版本化存档文件。存档文件是最终用户将从 Internet 下载并安装的文件。" #: ../source/glossary.rst:34 msgid "" @@ -1035,9 +1031,6 @@ msgid "" "distribution), which are often referred to with the single term " "\"distribution\"." msgstr "" -"分发包更常被称为“包”或“分发”，但是当需要更清楚地防止与 :term:`Import Package` " -"混淆时，本指南可能会使用扩展术语（通常也称为“包”）或另一种发行版（例如 Linux 发行版或 Python " -"语言发行版），通常用单个术语“发行版”来指代。" #: ../source/glossary.rst:41 msgid "Egg" @@ -1074,7 +1067,7 @@ msgstr "" #: ../source/glossary.rst:59 msgid "Known Good Set (KGS)" -msgstr "已知良好集 (KGS)" +msgstr "" #: ../source/glossary.rst:62 msgid "" @@ -1103,7 +1096,7 @@ msgid "" "\", but this guide will use the expanded term when more clarity is needed to " "prevent confusion with a :term:`Distribution Package` which is also commonly " "called a \"package\"." -msgstr "导入包通常用单个词“包”来指代，但本指南将在需要更清楚地说明时使用扩展术语，以防止与通常也称为“包”的 :term:`分发包` 混淆." +msgstr "" #: ../source/glossary.rst:78 msgid "Module" @@ -1114,8 +1107,6 @@ msgid "" "The basic unit of code reusability in Python, existing in one of two types: :" "term:`Pure Module`, or :term:`Extension Module`." msgstr "" -"Python 中代码可重用性的基本单元，存在于以下两种类型之一：:term:`Pure Module` 或 :term:`Extension " -"Module`。" #: ../source/glossary.rst:84 msgid "Package Index" @@ -1125,7 +1116,7 @@ msgstr "包索引 (Package Index)" msgid "" "A repository of distributions with a web interface to automate :term:" "`package ` discovery and consumption." -msgstr "一个带有 Web 界面的发行版存储库，用于自动化 :term:`package ` 发现和消费。" +msgstr "" #: ../source/glossary.rst:90 msgid "Per Project Index" @@ -1509,7 +1500,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:58 msgid "Navigate to the `BigQuery web UI`_." -msgstr "导航到 `BigQuery 网页用户界面`_。" +msgstr "导航到 `BigQuery 网页界面`_ 。" #: ../source/guides/analyzing-pypi-package-downloads.rst:59 msgid "Create a new project." @@ -3275,7 +3266,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:693 #: ../source/specifications/core-metadata.rst:722 msgid "Examples::" -msgstr "例子::" +msgstr "例子：:" #: ../source/guides/dropping-older-python-versions.rst:86 msgid "" From c3f7a25cb3a76444d54d086d282222319d77664f Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 18 Sep 2021 13:03:22 +0800 Subject: [PATCH 0148/1072] Revert "Merge branch 'main' into new" This reverts commit c41dbce2fe8e753e190917cf4af19767d3ac0b36, reversing changes made to c190eb32a2771dc33b9146cf9edd13f18aa54cf7. --- locales/.gitignore | 1 - locales/eo/LC_MESSAGES/messages.mo | Bin 0 -> 18402 bytes locales/es/LC_MESSAGES/messages.mo | Bin 0 -> 15012 bytes locales/pt_BR/LC_MESSAGES/messages.mo | Bin 0 -> 110880 bytes locales/pt_BR/LC_MESSAGES/messages.po | 8 ++-- locales/ro/LC_MESSAGES/messages.mo | Bin 0 -> 845 bytes locales/ru/LC_MESSAGES/messages.mo | Bin 0 -> 44338 bytes locales/si/LC_MESSAGES/messages.mo | Bin 0 -> 464 bytes locales/uk/LC_MESSAGES/messages.mo | Bin 0 -> 63748 bytes locales/uk/LC_MESSAGES/messages.po | 16 +++---- locales/zh_Hans/LC_MESSAGES/messages.mo | Bin 0 -> 100727 bytes locales/zh_Hans/LC_MESSAGES/messages.po | 55 ++++++++++-------------- locales/zh_Hant/LC_MESSAGES/messages.mo | Bin 0 -> 6020 bytes source/conf.py | 4 -- 14 files changed, 33 insertions(+), 51 deletions(-) delete mode 100644 locales/.gitignore create mode 100644 locales/eo/LC_MESSAGES/messages.mo create mode 100644 locales/es/LC_MESSAGES/messages.mo create mode 100644 locales/pt_BR/LC_MESSAGES/messages.mo create mode 100644 locales/ro/LC_MESSAGES/messages.mo create mode 100644 locales/ru/LC_MESSAGES/messages.mo create mode 100644 locales/si/LC_MESSAGES/messages.mo create mode 100644 locales/uk/LC_MESSAGES/messages.mo create mode 100644 locales/zh_Hans/LC_MESSAGES/messages.mo create mode 100644 locales/zh_Hant/LC_MESSAGES/messages.mo diff --git a/locales/.gitignore b/locales/.gitignore deleted file mode 100644 index cd1f2c943..000000000 --- a/locales/.gitignore +++ /dev/null @@ -1 +0,0 @@ -*.mo diff --git a/locales/eo/LC_MESSAGES/messages.mo b/locales/eo/LC_MESSAGES/messages.mo new file mode 100644 index 0000000000000000000000000000000000000000..8bed3f0e5d9095d1c181a3e322c3f063c8065226 GIT binary patch literal 18402 zcmeI23zQs3dGCvh!A3lc4TPsnO9DUEn%P~gp5qrQX(iUuuGZR>g>h_6?@sS*@6Jw- zyL)!E3gkf^#9)ZQki>}{!XpOb7>MIQViN+2l#mBW0F#G92*=6ENpf#;NzV1nJ=fgi z{{B_fGozJk$()?zBqww9>DS%$=&G;2`l`CV{ld50pM)=mpMfuizYoua-}L-zsPf-} zYv8v%&wZ)8ztHm{sB)LV^WcEzcKB@WcX;mhybh|qaY&QRjsCs?)sAJztIUu3=XXQ8 zZaxZ?{}b>P@C%TC<}v=$d;h0@{(s;F++RRvm47|F2yXHBQ}C7C*P;6V1MpSwE-2ML z1l8|jp1%jxp2wj2^Y?H7{v*_T*MFCLz5(v$egLZcGF18xLbd;PND*@uvBHc$-guH~eqh-vy6=b`j@9Il1`45jaY8rmtN-j6F}+nGAO&=2-Tk*{(ccE|68H#>ozF;eAqw#6g-dn&qC?@1l0Q< zg(~+qa1DF{YTla5UH+FsrC$U!PcMh6cNjhgj{Ey5sBsOU>OTU{g>U!iKjwKiyoTrZ z!CmmL;Z9hhGo$cUco04U*z!s%@tlzorF=fOiz;}$}-H-hTV3Y5QiH#`sC3Dusv zq2~SlP~-d{lpg;FRDIuu%KuyjM|wCPYFu6gl|BIVz6!jH@xKPj&i@#rR6ouuJN=A7 z=|6(chu;U)zIQ^k?*ovjVjhCB|F1yx^S?vs>)W2^P`S##0IEH&@Lca%_S_CtZWmPh z_jw+KYVR$c)1I?X_02=|ukG*O3D4*L$Nlqr;fuKcEL8o!1J8$Fg|dUcfa=$iQ0eEh z=-?{M%c0u63F6w!8=&&v1l8Zn^LEHoH9rSc?gZ5P9*5HRKS1^8NhrOYGwAyBO1PQ( zi=gsNLY2E2qB_%nYR^ym^bbST^8i$PJ`L6XFT;!B*WvZ>NvQseZFKd9Q1vcA_4_E) zxV{6bKOccFhM$GF0`nypz;8k2zhKDKvli;TS3v1yH@q4ifU?IspzQT0pzQl@sP*mR z5EC;Gz}w+t@B&!hg=)`}Q13q% zrK_I=Uw%TVok49ZXZIlL5Jyw&M*H`Mq|z?Z_C;Ck5dd>@oPei^!IF11T{X_LFx5+sBxTz((A2Ie)V3ccKtkz;BgqjzAN4M+z$1g_d)gV zV=#c9gVOV#L)qnvu5$Bc5Yi;G8LHn2RQulpFN8k@{}Mg`4?PP#V5Fbn{%;us@k7@d z^LhB@H(*2X)x*a8415BH@O?X+z5H)@1@{;2bmKD$)xKNct6}c%?|`zud!g*@L8$rs zFx31x4rO1D`ul%@%76YYr`K1*7jVBB>iG_+{)|KE^AMDM%=+~2fwG&oL+S0kQ2Fom z>7RsZ=Oa+{ei>>UzTxlx5^DVZ0jmDA(0L=i;Z4 zIb;C&ZsaGC;@9Tl^~hz&hmboF{eA`6Vy~Q^xRmP>qPaJP1jq?w9n$-o=H?FM-TvW& zJ&8xS)>wbQKfB5Ed*RRc>-#-F<|)Wd-hwP5KZxk}%gCFND|EvzcCbFsUs}Ac=jIl! zZ}#`U0k1=LAYb>-{s7J(2mJj-@PkN*ybF;X%D4O;@(M)1PaqqSbCKsDzlr=1^83hI zq>AYGYYz7R_w-yxT<=A`g5b*Rw=1x7;rY7ozpue&aRYN?6p@e8?;Xg!$Y$i(h<-bf z??D>KB=S6D0{K%!K5-v%H}ZDmw~^Zs{a)-~|G$s_--~=7atyfysUf)cQ+_M{$zyOU zk|1A2UWe%SaR-yaTagie|5><%EFfk7>>xafoQHhTKfBy>9KOb17r4=1{3`rIfBh5i zBmTMtuSfck4am!oKSI7A(eH)GmB>qUa-7cvmD#uvRjN_FUW%Ku zNi|rE@~{@>VcGQc?M#~WG|bzSi<4%yAy`S;mo7y`6}2F2)`D7`!GuZX6ggl~&ZMR5uN6s|J(pRx3$!Q$cT)D($J7;UJ3_ zTMY)osoD&;T8((dj#Mz+Zq^!6W_B>vb+p^8nVm_az1RectuT!<#)zJm8FwBvXXARC zfo70{#juHWEJn?|lOTN;W}$~UiJ84{zTWBsnR{k-xdzsPJYI~vvx|Aace`6MR~iGCrN|Zq1muJ7e$RAB)Q#^UYJUe895Sas4}yA_R<|%{Uh-lELv+iIvO&0AyHS#EJN-42w@1&p99GltCl?D@iVl-%H zdP%j~va^0DC@o4WRAMJjaFfcHyy|bRR?9`jPNTC)x)|ogvnVaDROdw8ikeHkPweaU z)>9t3PFlU#&fAx(5?jQjX0!xv(OcHH>!fG4!_8>9vEoMrr{?n&MKf1z1&u9Ms)sb* zS#Xu*HC3}O#5NB^OL4T!!0d~{lqr>@k=civ47}c{)Q@In#=;m2i*bTnE<}MfEk<76 zE}mU+7SYZ$Jc}A0>#cl~sFFcZe?OP=)Pd3nK8yZwJV@&nOed!lm>QY7HLIm58x;08yRZB?l@}HGIM}+CJun*-XwPt;kG9Gi{dm6)toW1#UszJh-)LwNu=(zT$}jX~?aWHnqk+ zC~jm_W<5v1!q8Psu#^RE=9@`7PyNDs@?B;owb}5?;?(}JeTM_BA{Ew$G+YUiS!QZV z7tPb8WhW(`Cck^68I*_9SaWY({s~4g9cEZ_JJT#+rEbJ>HA%%xbqr=X#t}@DGfkE= z)x?AggSk9!Rr>oI$xPUgqAS}51_sKu*g~|joTN4Uq25hB%w28zT&i_f^zf7f_GpXP zZ@@xTth&;~Df#>)S(U~n4;N{7LyS3A;&(}#2ABov%v+e12lu=sSdJPjcWiSzHl3u| zT1=LGr(K^LNuH_lNJ~c?Pq$ryKa((d%v=d{B5>5aoEVrLFR*7S-s!m5iXbY zmmOhMo#>=n4_C3tnl&0Czxc@B4%%t$c9UJVT2+3MgX$7awtBd@^_8M;=Y&{BZ}9%s zGw`#3MeK%zUAfgqo-`wKXpV0Vx3JVAwt03nS=YjwHsa}Z%%gI!u7wJ8cP+VDP2K;R zV%lu+s2O-i#*Qyp#CzeC<)CEqcBxa(a~4k)l~Wfo492cr%8m1|hQ`i0(tek3nZ+cj zmEBu3eDvP$<}$tx*wnS6gguj6uH04vGpBT5mo>NMF^nZI8;ijGFr>gA^|*)Hs~$Z^x) z&4-nBgY_wP&s?6Ft(z)aY&K8c$+%slbLZtGt@rEG62s`frh52r@Rp!D$_E}TwfQr= z(sZ0pw`Ufj+~#KcA9jkwHtV&Tp6%>v6n=@nWbB$neLITsXH#WS$ZmW)P2i=md%JUf zMFW((w|i>t3}4A{qqZy~FY|>{W1LvyvvQm~Wf%P@VfX#Ef4z0|yG|AjbE{vsD^FLn zD07C+^uDbq(({FMcJGo(if^jkN?1FB^}TQCR;Lmqm(}f<55qjNy;tegO2xaCr5PzP zYW6eAEL~@{R`+>f?=~#LR8(o*e1U-ez*-X?0x=R&V&VG`Bcv ztVJxVM_9Y;F2rqXDiu?mNTQrAV`px-m7>(LkFEQq<)(TTQ%E0t>ZPex2g-xxE!FA< zR=2_Ort-#Wm4_S4Tg!u7>M7@Pz6N@y3fk2v%5yo#iQifAEUq&t+3uco zCG%{Xvz|t@(s+qaglE){-a3}4Or2pr$VWu6C+&1e8+S>cX-lK?Sd+{*a%tp^{# z!y~5Hl@WuS}XZ) zsY)=y*se_ksRU~#_Ltld4WqjY6R89@jtn0t zjqNY(8V=sLzcMy@#hdq!kF3#|WNC^TGuFE#tpvLd?%NlP508xmSB;DfkM4WJ@UC44 zMkXh(A#1bV=8T{;6@`nvE$O&kzddJaXz}db`f^649e8KpygMjqCm*rH?NnX~qGZk3 z=-5cN%Y)^CH9oRXnzBbEIRn$rmtowzGMJeQQxtsl!KvM)ZQXq85n-g#2nX9b{i+1p z_##*{(IA%5DDCESIjaQCmc7lc-gsr;F0XC|Yp)IluUzw{(jEn$oK6n84h5Ua+i`w3;E(*NP>knhqx{-7B!RkfG^V3aWjR>_Sjfi!m;X7tb&}gEQIr&02#Lv_H3|Z zjdFqSSY4C2ANCG$^i{)%GZ^KjL$s%Vq?%GDl7Vq5;zB#X=s2AS8c|)w zXzS{ofc63N4gQpvjsTEN|Pl9)YaH#F*vovD$i&O`WEma)GFnL3*qr!N)#<)4xp$!V)@2p#n}R< z#3XRR;ncjDid)V!YsrEOnWc#hmFjcbj^7h!oa}`2 zW@O_NQ`!>w>|w( z%B*a!cy4W4sw*CNZ8j6m$Gm>?Lc6_n^~S(X4uL74z7!vgIR+yLmNxN+jo2s#7T06+ zXPd*&x*@})F{-016mm4C*Jv0Zv>h)n(sqQiu+h%t+?w*js9M)udrf>aEFt=}m~iU9 zutaZL;fZ_b+&Cc{Oqw|?WA=@ZPnDxvWRXnU@(qgOL~;j;k;#>(cn~Qaf!5^ z;q6mjA zle28b2@KQY?rE*zj{;aJ;(CZL@&~d~ga%UmMCIQ3$+{!I_7IZLY%V7F@q5VYtO<0Z zVRD($psld*p*AG8fN`?$+u1}QEObFJ4H^bIQM}Q;aAMd@_^8-e*yJP+pDJDZW$@rp z4L9mf9}Pd8j1VxkQ#f#^}5fq}yV&0|umXDaqgVq_GGHF(|$H?0-a5^OW!vqp~9 zR*4%T@^5|dNxRf?euTi6vudmkyP^i~r`rIYaglX}i%@u&b!x1_qTkXD4N|Mo3P#IQ3@7<4SS%2)L+% z^g5=F*|57gep}QDnhoo31LW11H0+FLu&KD#w*U1;&NOv;B4-*-oQa)JZWVQE#Wypv z%35Lbq{KpDgJ<;Hs*DCic2{K&{7a0e3n0*iB7`RIe?Xp?y|!1E-JsaDM&@PXTooc& znX_koX(e=s4cd2-r(1k=>26A(>CFM7OkGP}Pc!_}>zq@X4v&Uto>fardWF9VD6CFv zT|)dVs%yV#2jD3}Y?L{14}aJZH4jWr<`E~|3*9PkNLeyZHXZ2ZZH#Av&_vdYBEe;3@ zRJ62fdSpSZ&5p?L8hZBDKB9(~aa(7_WES{iwBEVF=MjGz!TfSPpw`}0b+Zx8+bP<~ zqFx@mzbCGC>=8yq3zO^&CsWKj{E#N|!K1O3Z5vjTiFcB%uOu*rTi5LBN#hyHU_WaA zMyub^~VZH()FrW^YWiiycvB-PN)CeK76V zBdg{XDSX1c&*#QC!Ka3T;Q)4 zQ1DWG>=ANMM(Z9U(FwFA&2r~07%gv+=H=q}d!%`LHRskujXUFE_Xb4TQeC*^(ygW} znJ!I#LWmP1xt%SjvTmRaO|t&UNq3#_I4;S#VOF}1TkJmVbeo2s2f239f z+&UX{cbv-ck2@B5nz-A}nB7YE^z}bL*lkrO&o=tDs-vq<*?W&ApW!KcZ_%?nWj|e! z;)|<07*E?q4n_ZUBX6hCD{in8%Q`gxcLt48_!%ma5@)GD)$NY@cXhu?yNV^ttzK8EXu+9#$17HK@C<>h?h6#jI-S1H7>heYtNu+xai{4(_XyyrPn*wD!QHA> zDS40mOR%RN#%{slO=lRElM9&YnRNUgD;{^scZHU4e;%U`b_M19NrtvW&mbgs=IQib z5xHvh-zg%eokrAT56e-5w$1E)*-ZCFRQ@X-M1VzAZRgCWc1CjX6wg3PC literal 0 HcmV?d00001 diff --git a/locales/es/LC_MESSAGES/messages.mo b/locales/es/LC_MESSAGES/messages.mo new file mode 100644 index 0000000000000000000000000000000000000000..9be893d89836f8ff008517ffc8087c59d20c36c3 GIT binary patch literal 15012 zcmb`Nd5|1eeaG9zT*AgkCLHE!+r*ZZ-H|NWMvMp1_R6zw&0g4ckP@yn5#QA*R zdp$F&T{)Fhy7cs&?tcA_-~Ic&{l=E_KHzbEl=foUc~AAc$HDJElmEE>{sPZCAN(r# zEb!alOTiz4&j&X@+w-0QZUZ-gJHcDP>%r%M9|WHZeggEtFM#U*bx{4k4ZaBccZU~T zXusbEK8@#Z0e=pB2dHs=3)J_Y1786C5%@yzZ^4Vfe*62DPpj)Vu|#@9zQG zn)e}xA9wf=sCm8wYX6VA=RW{{p8KDHyTHqsRCG8B^2oa#d=$JB6#b?k%FDn*AdkER z6zksV?%xHnRPU6-2SNUMf69OA|26O>;13+0&*Jrb4176w19&;u0JYwCg4@6kgPQ*l z@DlJZ!Sld>bEo&Y89&t{URgRcO!?_J;w zI0I_D_kimE04TmZ42qur0E!k-VAEI`#`PhG^l=m4DJEH0?vaMF`4d{ zz-z!yg0BU?>2Mc|{51D(0~f%nV1o4gZcu#v1Sq-r6e#)nqI>^kQ0x32sCE1VWJvFP zKGyoSf}-yvDEjUP)&Dk7bdJFg{2aInUW_oS|NB7ozYo;7p9V$GFM^WC?}M7>A|IIm zw}X1V3)~034ivqA2iyUE8AKGl{{*iBw;*f`;mv>_I>+-`pycBTghhD%W!NzAg`oI; z6ck_H2ukkX4laZDf}+b$9bSkq?BxFCpy+heVE}5r;|}ium$-ib)PA=x39Rxi2G#Fs zP~RU05moOF5E1cKK_9#qydC_kd%u~@Yu($x3GfA9weUfa?EUhd%WlQ4ff_zaAyDi5CaC>>7nGfQ z4Aedz2Q}U%2JQuqgOcaZf*SYFK&|7)pzPC2D|UaApycUJkbmCW`47?Z9s;$l zuYy{~KZA&l_k4)*D)2gxp}ZAP{P-9sdHMrT{T>BHuOEZj_qi2pU-`Ieig@Q;Y3X`7h{}3XAVYc$P~W{DgvH+HLCy0mQ0spjls>%-<#;-H z8~98x1fK&Y;Dz8_py>2oa0~b`(Ch;gT^>EQ2YA{ z_zdtR2!Zx-IjHZi0ky74Fb6*ZcEHWMEgkLxHQwEz_IV0~RNfarw&wi+6kRWY$xi`i zK*`O`;4NSZs^6DE>C=CK;@eeKYv*nP#s4>f=Yaa=%uD;w^+8(8{IWdU!tWQ-B)__( z{~KLz=i!2TF$`<^myOSn9y`RR?%pL&4OQ9~&kL`H(>1O28{*Ji& zn?T9sYutSaAK*tulMI|k6AjAiE`B_}ym2TRi_gC_@?7#UdOejJ@%SAh4_Do9>B8AA z*#}+XpHDkP`v^_fk_Gese*S-#yFcdeR~(K)j~nTXu9zly(2=^X_6mZziz?&KhOUk9l6)fi)kMkd6w{7GFD!D_;G`~k?!bv5AD6Qx6<~}bRD)} z?Ah)7zK14VEZpw(Q&QTqX&2C@XkFUt zXun4LFzr`q(!KJ!ksoiMO}hs*@GAFPAUk>+?NZv)X)mGas?$(k?_L_}Zmts!rL)hY z-AY@eJ(u=QTAQ|;c7S$1?X|RL(sbQy!FwC{G}?A|FSv;Ii?l#D?m7y-fc8e(W?D$w zLDThm3&a1%#`c9lGwQUmu`zFK>|oKZhpGL2I1By2Z-t#^m`-%UB2RIdBkAO6R4>dX9DUxv)Q4x@ zFz)w~;)*n6+%D^d5WHVX;y76~WSm>rdqw8g_9V^FPnP^WNvByf^4cADRJ=V&T(mnt zyPb42$5PZPL@CzBQ+umTw!=JV26>=|EIv1H?SdSUqs(s=ut7am=wY@ObeeqHSPnW- zL!T5pXS9-YLu&1T*DyZtYqe(5$Z9pe8KrC{fm{)^V(Dx$6|cn;?Ql7XoAx1J6m6z7 z>#ll(u{z;u`2kyXGaw_4h89vjk)&B_X=#!Hf&HjZS9A(Br_* z!z>@JdibW>bBnIzNjn}s*SsYmG;8Kf84^IUJZgvDRG2l=s4GHxQ&H9^G9xnHng#fI zud6SU&K0?YsTD$-W#nI@&-LcwG@LhpLQJG)hp z>R17x0_H0k%R*-In@Po+?qnjlZX43fqEqf*DNWjDM=ZIm)yGjM+^9d6!9Ppq6M>XE z^QKY0RJz;@yRt%^M#R&-V!JgR-d=Rlk#1+@m7}-2Dp#$&z1rM{cI;}^n+bCx;0t+> zN)eAn`Le&zU5+{@2JbRhRCK)=nWq3LZiii2vBUERv;a%@Qew(p*>aLXGwnQqf{?fr zjg7vM8fM-;sej_LB!8jkb{W9i-+>Kj9>KmK9ruriVOK^IF+k=dHDW*V?svmP7I1Yr z@e2&Lqed2@>&sy~3*(hA6YE%KD-GIhtb4^@MC1Zz^<-%B<C6c9lRifDpSHf5(J*%)KWP-KkAwRQRi#Gy* z00pt(G-ieUg(u4QMubaVyKlm@d@BK+vyLTO^DIJIRz{yVwz?7YotaqfV6>Zgcx2DQ zx@QTbO#S^@8r(W_82h&LHY0DH$yoD6`D~pqj1FrQ8j~3J5I^}S)U=Ro?vWoQjZuCYLm<5@b1#dSb)kd97^x|)w z4H`b2zJ;|q_uY{w%oTM6#aCE?O|-Werm}^TIwMZvW!gopAqInOHRg^R{>Zv z!MezNv8HZ}Co8Fqu%Yo8M$c|7@H-|Pm4!mCM98ZD`pa&+gK>BOmy$BMtE5KKt07i1a&CA z5)sAZdAGWKyNQ;?=<4nrJ9gNqU6SGgPLy;Yy-Au~;==+wdO(X4v;?JG4SH;r_&$ug zK9S=%;-KgOA=5&LDQdNf7CI4imXbA@g2F}(k4Ms`h+K@0jk|!U&USgz#9~L<1PPKG zv7{OwXN+vtv7~%M^DsSTWi;%!Q8%=Jccn4%yVgVz2pwGx3AEA#izRiG$_6fnG&>vR z6QK*%&+j7rh7UnkAEuE~f%S8Wq!1t@1;Selwq=FGcvVr(<$m=LbE4qKI90901{F^7 zMucvt^}%pI&elO8ys7yQdnxlz)NEp?%v&r-(4rvDJf-zDlbF}Eg3?6T7^$k)OGWHU zo)v8$HgpNl0W5c(91lC?BP_V0BDXfiQQ&5~yD^7ROXeMMUh{~H3#Lcnf+I=PK(G|q zqIaI*iCH1RgM_B^7wwP$*~CWJEE125T*in2r3Xi_+=LTxbUduuah#z)gB%KI2Rz8} z&7?=oCM5&Q9-NJaB)T1Ax-s?Ej1mUw4W>RpM$k@@X2s63iggp$hH><`GE-O9&|A!j zL@@AI%w`qBlj$1~3P`%8og%<84liakgv}j4S~3~da-j4BUDo_TCtEeqbm{k1hABl? z3MFrHl!&WU_2)*cyL;pujQqobbuc%}!AzRG&pDW~>rgi2U^F>INaaP0zi{2w_=^^M zl)tz&%)HuM66V;%>tt~iQ>*1J}#8o9NhY)E0KZOR~; zT8!2FreadctX?>KP+_3b=4%{hTTI?#$`FIHNUdf)!I`tg*bf=Cq3{}uq=AWfimnkY z#Bt{NG#@HIoS4m8QFG$PqLoc7CRKma+@T3Y9*RsS zRGg^#w@y#aPs|>gn40wW9jeamf5qz#9h}~z^kHH#MU03t6IQVI@PPyV!O7Wa|GMef z$^8djGdVRiKfSPU16@00s-ih7A ze%j9xRmy2nOyhn0-SsHnG#67LizoIHOcObFy5=^!e&@Bm{ds-IzvO!V%4;{>GBFd9 z8Ci-PwHxxUs_d>@IY9=yiNfe&|8!o&iK~+KA0{n!H-~Y;vR{Nqc=0GsWIKs(Dbl3+ z)#~5R&`E}1bwZL1QUc@}MKx8_X~jGBK-DPxJzbl`&X@^;EG$4As@Fy})x)X}Fg%6@ zqQiJhIUleHr4DSwmQ@o88&y(_T|4kyZFMCX_YopLJQk9VbHi6b+E|WO)ZL$-oAu3) z$+^Xfr-{;}rve|&j1mmRN`hPhx{N&$TQ?B7K;@drPX822gwtb?7~`o-G)P8rsPThVzP^f0Z60*SAA7gXyf-Lhw&!kLEI8y!&!+x zsJ=qlkSHJx(*7x}lJXW7MO+fmo68ZeFtt=*`wupwmZ1WcL`B$uDy-d@PnDJ;rK!i7 zDyyx;iViFpTOKL%g&>G=`Kte*LI6VqXNVH>o~=aeSpu(;agW(0MU>r({%JEfj=+uF zQ+>97iu!C|zYWrLWTqZuX{_RgNi#jflONBC8p`{E|pFT%j_k+AXPXfq=7otpWP8BU_~z^t ztuGDAvab1xn>tpGKq?|u++c+V6F-S{xM9SJO=Ht35J9RLpOq@OEpcC>2>#@eR;%%nr2+ zESq6+JIdM;0%9SGg%Wxz{>WT6HK#n(?dpV~&;!F@kJ$Y6@0oIH#|>1)!y9DFj6I+OR4Y6cy}p3n1raT5ziGyPa!RK9-)!%#;6)y zl|faJm}PYPrP{)6x|sbfb%1*|gk%oBJEhLd^H#Jux}@3m5+c;X#`#XCqRJFW68HaxR3A$N8X z*>g0LVI+63i>osT0-4BQsG5u^!ERUl1IUmqCzD~aouLWC>yZ)m7z7)D<=|uL8zfOk zl|-E*HdT|O0F#i7Yh77_3uU?>O*t6T4AO`+p}Oomjb%?5y7=^v%j`KY2eSVMzx3%;BDFza=3=WvqN52AQB? z?TQ#e?=006>?`CUl|#UBgZ=wr&eH;(E0RT8yvhD&ILzdOIH)6Oej`>gBnfr`iJ*>5 zMx_e>PGvv|l{bTEX%tb&#v|o15+m^}Fx79vODf!LR1PKXKX@XNj2eYk;d^?mDRdjO z5f#-3mk#npnZH|+_4Wob#H8OVHrzACapN;(QBx${)yS!fYilLR?H#E#`X%GbD??LE zYU_Wop(B=p+9!f?j8oKsfZNRv13pzw6n(6hYF9C5a}0C#Zo>*X{bIlWE~{I7Q;LQ0 zrDZHQaJO2SlowX41f7%ED3aU=-;>ySf#uzxJGL6mBbG7~WFK9*LlM5Lx*IxKhZ&^X z)^SejaZ*_p^}K0L*b z?KC8+i5_jSo>>d|%P0Mk@Qh0RNX6cYu-QtfdwU$`4f{w65T*XZD&;4xq(8Jw@}Xyj z)yAjwAIu_TXS%GO@rhX~B*R)w60aMl5sCLM1ROmZtWP-?En3D3l?ELSuZj$NY*>KPQu0u15Ksjmbh) z^+$RUt_@67ijQ@X8#&k7j*7ulStbft`+~b~-SvA42;$_J2`I|*0m3qZK-CpDIwR0o zF_EZvI1;y)DM*!!jcPD|ezOqr7cGjI*9n^qcf@g7KoU@$D40OU+OlraL!zBmp_lWL z-ZV$kj>Tsj9*n*k6re^Qmc^veXSQ&}5$su`9c+^XUfDZxVdJV{SVg?yqAFuZoY+(} zAP+LRi!}+-N}=O>2@H}UkF2Oo#|msw{?8gzWA*4$+BW}@2fF4&;gLV&FEu!1cR}%1 zbB-XPE6)~eJZMS*10%cccwrkfClFRja!P-<6ch4|s1|=slLjmO`wb(`a=5_$%Cm)l zRD<}`ng*Bk4h_nXb~$Mlf{ftUtl60ngwF+(91k-IYnM1_fx$0U9s>7vax;Jub$q+;y~ zpmx%YaBv8MstTM&luq7m-IZmO+lVO3oW@$>kfpN%tzE;G#)T@oO@`>?URi;z*gR^` zPicz@O69^wwpjJ{4FemMk@))(?D9|oM&q8rp+(4XVE;5`+b|6)gNdScVFZ6LWqE+H z$7zz1hW;r|UsNtRY+)=57WV310ZtD$)83Xw-#u~7t;NRl2oUyMjnJRI2>$+Ac!>aIXAjzFTA-#z{H zA2}b9Jf|#pZ~c|SbUC23)Ot`;cp}Sa4E!g#S4lTHu+dl6wZ4{>Q_tZqE{toPJkzy~ zezD%U>KvjV*co`xGbdT^C(CmYr1<}QF49tzZbD>|Xq9Q85sVv=h;q{=VHybu#K6*U zY;;bd3Q_rIqZoog5vcsetJOx2Ox!}4TSq2Fm7J4RGR_kv?PTKrkLM2qK%n|NA@V-uGU0_mH4|{-4jkKT~t+ zy?XDyd(S=lIrqNLpLN=c6aL;Zlq8P?KL5-l*?Ny8`LBoTEPszplD`2A0f&Jf13nsf z&vTRH)xZ_N`vcz(ydL;r;F+{_@p(yd2giF?CdvJP_gUrbKM43>jz@uN=MvyUfYZRA z2R;pWZ{SSNSfZq=A#{u4VwYT@6 z03QR?^VbA82D}f)69H}q>N$G?JP_dF0G|L<|DG7&On@EW=fTTUftTv{^J$mk*8|HO zzh!NboCW+G@KL~T0$&7tKq*Pqaox?pZvsET#b4n3og+z-a{PwTB>6bUe>RpRJAkhm zPm+HCehK(8onMzE?*&%YC&{ybkKT|ZHQ?)j4*=eGBY35qhXP;2@nbh7$psw$3Gf@h zWFkqP0rN_w@&w>LK*pPa*8pz>p1wOtws75ZfJZt0lgpCi0PwMoPm)cX z?*mT*zGaWo%RBc%W4ez2z5+aJAGqT8?*bnSd>J=i1AOo0N%9$ff7l@(-*5ijAAw&3e(?(M3jB*JeIEY>_&|=o3)J=ZqtojD2Y{lB7hDCNfG-7V-k*JSk~|ss zBB1U&^O_`iIPh$s=64HFoaOlI zKt1>HFZuZ=0UyTkF`%CFLg0gezYF{Y;0J&y@MFOH0sjMdCQ!(I5a0p8M*+_P>i4Yy z?gf67in>4DoI+LzYO>g;Jbjw7{}iL)!$3&&hM84 z#pmw!-P9s_>;k_D{6k>v+9Y`` z@R8Rg$!`GP5Bv!5P}BM2oH@te_kc`gQl+z^`*#5!!1159ljL0B$ARO(9{| zM&Q%A{vseGlDwbJGeyZmI?Ng8d%!D!KcQ2iyDR(9D!)I4!GXf$Tfi>>4<2Ve_Q+F^U*~dzZ!TB$FKQyWC-vi@IAmgfsf?(XS^Uu zAob+to18y>0ua9{-)3OFi`#91bhT=7x3qRlfW@x2dL-1 z9;oqt2q-@L1n}O#e+1qi_;0{Z@|^zyLK?}(UW^O??s|#O_bgEN9|!8bX8_;9_0I!d z!tq5f^YhOJ-ofz;fa=fgmwP*PppKsdJcIjQ3ltr{3F^ssOP=|sD9i56usOD)ObD%6kfgoJRdmpDt}%H_%M!l1GfODfWphoz%{^+0Urtc zF>odD5wG@kwgVr*@fE*lwAG*cI_kiDV zdVLg7 z1NU-v7^>{vHJEaC{!{fxwpo z)z0m}dja1A6rX(%SO&#EB=qu-&ucwZs)kne;)<@ z0C*nvefTevF1w;KjQd1K=tF>AA!bz_hynb{!PF&z{dm610Dm4 z&R-3@C-7asO~Cg8Hv|6@cs6k4Z=CKA0@cnn!1n`Nz$3t6I>%Hd&jS7u@Iof*HsGs( zUEuDIyZ(GH@cs0E_!ICf=fC+$=f4mCt@q<=z=w1GbS6#m`fQ;1d;?JZ+yi_Z_s;?! z#_^l}j(O(zBvAPN@TaknfS(2G{s(-<@p2AO?FhBwYy8fL&_47SIjqfjj z8rMgGqMI)Rb>G*3_XU0zsQZS#;P^TNsPidM^sxr0`^rGc{|&%@=lGw$=yu3wzLX>- zj(_gUZVz1uRQvx56kY!SxRLuhfA4nbo4?|}AO8o}ug?TNgzMe{JO_9uQ1kpXpzwIw zSN-`94)9R{o(sGmzn6d-|K@OhM}T{P>i^;J`x6433a}O6LV(W<@TLG?5#Z~A8vok@ z{3D?7_5J`q1k`gr8sH}b{B(ey2daNx4)9+C{2p-SJ-GKDT|S=w&)@+(T@M`Q`saSl z=lNa03poBO;O_#@_&U7Bb$bP4b=-$Jf&eg^nD zj&J<7%kOjl!{z6H0_Qk?>^nX$UjbIQ{@;Ob$~$8-4_?x&E_1=6PH<`V(k^`!2&6((|uI_*Ij+Dq2y0Fe(dQ(Ca=GS z(rIx1Bu*zHA}PV-&jp@_@$gcvdjU}Nbl&}k%&z@ypzORK0`;8z7-8bmqa0L#$AJF? z{9E7~`ThMrKa^YwY@9Weyb}112l{jOVMI=Iyz&?6AJ@NtNs!&$r_<8QPk-2u*`2pN ze8~9fZ-AoLF9JUd{2mY%O748bkn!*9G42pC$vc6flbaqjWOl>LfVwYz^pM%Rn}Cvg zR{%Bc>w)(Leg?=?CI0|C9r&ro3?(!4;|svYaD2(x;1f6loB`el)P4U16yJO+!27T8 z=bQ(8Fz0swB?qnsJ{ou}Q2g~=p!nz&K=tnpz;l7`3+KNQ;5UJgYVuz|J^w4``1L;m zO0GW`r(%kE{}xdEaK*|Y^PjE;s@=Z?zLjx&1t`4y)@pywtAUbdCxK1ir+`ld?gaV2 zr}Mx+0-iYE;V4A@*BpNhSOdPhG-UQ#T6TQ2fFI)gCxPz--aI^Hbboln=lAiKKQ=a$ybAcl@gcLfz7IT;<6(@i5#WWuF<=WQKE4HbFW_xJ#Sh*Ayn^G(#v${g z{t$RG=O02a;2FR_+6-QRTL@ZoxbEgH&>Qf97Y>Saa8sF!1b}{g|Tz3Fi1%7(J)6tg8hm!Ad-4UShy!W8rcOy{! zdOi@6PF@PUH^=XS=|N@k0ig8fj}9|Fj_+}V{&D=EEByRkASOX_5C|(Jr7K-7?0LeF z`Omil>2mTV;1hx6tA{LZ@Vsk$90xclJyr(_FCE}{z-Ix4&)a~K%kKl81N=ca|L7+T znVud2s=qsc;=4V-d%+)11d8q^aXQ7%Uk5${c)yB2ZzWLUUI)B`eq9XQ$?*?Bn%aBZ zvl zD0%W@pxVC=!clbdSfK8o0G5H51J(ZCC8)r43E8qvOb-I5<)A{r}K#l*Nb53XH0#E0< z4M5S!g)Q&TLfhr{Z9t|Vc{gw!_dN_I)BNrOiXN)K7jXQR&QS8_zze%W7AHEr=W^z$ z{UP%|{sJid_~2th$p?UU0v`|j)#F3SUjaW36raELg!9K43&7d_qi{jI+;lzfo$ z4|xW95%_5!Dmf`Xb11nJxb|7-LEyK6?*P8)*+a=L7-;`-_|lIOYJy5sq-uV3=( z&gXA^!I1e^PrPZ!;=OMLO3!b7q0`Arfb!371`3bA|Dqv_1O7Qs{5kp?L*_4U0IDCK z`c0pw*ZkH{vV!Bc1^6)_CSUTOK9WI(xK#9j(5Gx<-ps4&*b>8U+(mGGI(4tDr;f zfBUPwAMg2XmkWOaM8ze42b8}3@oR?6|9I%lKK{#qqVp#Khk?%picj7JlwSNhpybBq zfE$4iyT$4Ea^QV9?gE9!rvSeWya{*|_~hRiGQaRMzy`;+zSixJUw9pQhT|^)p97qF zJ^Vrcz7G5f$A5b3P_h;H<~I%{j|2V-P|q#B$;VR%iob6Fir-%dyn_3018RKt{9VSu z@uPqb;CSzCL&-(JCjzCnUkSV)@NGb~^B&+@;75U90R9As$(elNcIWSpy~VHpG*EK! zt3b)S{|x7c-s*DZOrW0kSfJ*0Jix~VxEEOA{MA6&G4BRS-uxv{c>FF<@-lgw)8Tyr zJTt(vfYS310jm9Tfx2%D_(0$V0qzHCoKrwucLJ#XJ`1SpUkFq`Uk;S~dLvNddMi-R z|6`!=@@GKN>*s*F?;nA}?>EEwGv4m>@gSh?dngdJn+>Y@*u{6VXMnPg^!I!|SM%E# zP|y5BK9H~diMR9z8z=k1IrZ}=eDwT_`TQ22NAO#fPa3YNaZZ2N^O2l*9Ousliicz; zZR7aGK>ht5pB|t8L z^Z78pO#%CSihq(F9||W>btW_7?}x&*`vd$|_~Fe!>2TRs`rFFyPvP@wKeRmB4SX+! z`@YF{)Tzni{}Zlxcz^=q;rru&59d1BJNldDbByEj`1}&zKh8(8^{@Gi@>$@czdFA^ zfzJ#0NJr@JMST99&#!SV{(X)wU*vI*w6Y_9uIJG<<(O-&gSciNLS(Im!nU!hC~TxaOmrLwwucbNK)Ld{D>9PCj4d zJ0^hTaNffAA--nU7 z|64wn@?C#-@_8kn%^W|S&oG~>IX<0_{{D&2gE)5ypBwr95I%SC(cgC*Sd3a<8{v3g zfTwW}D#UcnH0SQi=SGeX^SK`%)OqqH&OMUPm-&32&m8BD1NHZ2zHb6v0DKqlZ*-Es zX^vL|F9QAx@Hcdlzdv$dIct4w^LaO)Ki5I{I}yJC|A5b0+ISwHXNU6-<-2syAM<%U zpC5(uM>(&*wS1n<_Yph7_Xh6a^CHe+e%RkNz@O(c!_iClT*>!G0B-?K0n5N&;qybj zH~HxAQ5-)8IKk(3zU%L~0sa-=FXHn_K5yjH;iJC;d@#K&=V2%K?|1oNmf7F+0geIp z@R{TzyX-pPefhkJPlHeV!wj^)dN^@;fHR!0^8Gb@p1|ild|t+94WGZ~^E-t$Zsz+A zJ`dvj_xYS%_^r(G>-gwzJD=a@vx(oorxW4tK)8M*$C!y`XFn47YvK353~)SLcOT$` zId@Gs|74DTp6_o8$8*3d_&kmC>wqr-J{@=&aDva<`L4f%e19XK79aiH=D_U#@YQ_8 zf8^lj!Zla%{YpMB4;Rb__`CrBIY5D1`E2372Lk^=C&J(PoNI>m&IPtOe}6vr$X&j`Q$I^R#{`!DhNAm1BS+zJ0Xw2-#y^;%cA zb^5JxdgW}rmG)-q*@ca68lFkxlMCrYr#?MVnQzQj)^eSG3Fy+&It@MwOC zT?$R4jb3-4N9APYu4c8jGM%qZU00oqyM(X3BY>N7K?Mr*oVN$2XlYOUI< zmXkGWws+dyZi#NxI}EFy&eU7=PP^Z2F05I@&pR63seZRhFS={iq}5J6oo;i2-qSCJ zf2>h!v}V$&_S}4@&S<-hV|9i&-R{hJ->Z}Deh*Z|5rLce##A}oJ)JJJ`zvYi+J3i} z_Bsn{2gJ?Pdug}VpPo)@?N)tl+O5~qiCTMVqB1Mb4#o@?#nt!BGgV*vdY*qrXP z=a_tTCALBj+H-Z?e|)wvHB0+b&3>&u!4r44>eJH=XhE&D)4A$(_4IhVbDg8Tnr?5m zdio6{_BxHpzD?%7de5#|wSC9F)#~Do*av8_$CZt#ZaOtvZOzo_l?b%eYc7B=d#)jA zwmwHUGNPK-RId%)(-h6ttH&CkVyZedTd(np(R3hk?mSj)Hkkj=mS2|6wYjrBO^4T} z)mAO-)N6g{L0D=Zt9PL8l+i-%%y6sT?K(#3qaLEk*w^kscpduRZ&o`z9x|EkH#Nk| zG{uwksVb)mY%^Q!auybe(*Rjj(}t#F@kQlKR2)0^s`57RB%qM z-YK=}{T|qYh8LQ3Bg`v14Q_%!gv$;jTkqKUdbPW7H1M*WKn?&$H;#{tZ{7r4$KQA| zx@lzn==j*Cjbj`5zIol~`tkMaMv~FZqZ>A_9|Nx6uyNgJGFIN0jE#)0D~*owPhU5d zMmCj3;@8dD*U^#u>uCOUEPT~H{&j4_hVhZH&6{a#-Ny0Jkz{Oq-MS5%$C9yimiR59rT{KibQJtG_B8eI%vYgFLNcSgW z$I?n=ZlO9qU!M2JR4Q~R>wX-Z2%wd=`M;A+^y;0ti3-okL_;^-G9W1qxD*d#jsu-* z*ZNI$8y<~lapFQrWREPT`z6gYWwTb&)^H~loS5#n5UBIl%^;JSWyrI0G_+e$TM+}P zxPI9OW(}u(Q9UCoK7E2%uIZe;TlekWwe!&7a-&r-rcPUMch%%bI*F+6Ea+hc6mP0v)M2qhF+ja1L@Co}iGs;0MXY>8H!uJ)S}=uBYfi#IX9 z0136{=0IP!oZ1A_S~kbhHk#W?_P}(@Y_B)pofsaTL7Da^%iKLYzc61N?iyV%FR}rK zC!6ib;kjxTTn=Y9UsO3NNo_42SU9jX^?NeWefQd?l|_iqD7y8|G3WqoLUWiOpiV(oCz9>R0)rCX8QgpW6~PGKz&u4 zSVnBdQBg{!TZ%^)VKlYc$I}W{SqJ6PtJf+=(RNTzr{3gBItKE`Mn=|&qNJPhzStD? z+U;hyf^O~EUC?HA5|V+4C)dZ-ey=T?YRc@)LYIm*X+)YVO1Pc=V-Lcfj)qON z1oJdG)1oCTHL!hmu*@yk#WS-gwFVLa4Lnmv!B6%ZO;8Gbx969|tT=5RD-L3U*X{z# zYe4^+BCaze)9HZ9oiiA4TlgQ8F)>9f7k^rXt(9T|O3*r0YTzrU2aV(6-Cao`nm*L- zcaWO{a(ER_T45KgV5(O8bU>*cB=MA{O~is_TFr5=lwD5EM$vMcsWKr*=Z?Do^X=o3 ztL+p*mND0<&o|`|)YE$FSfkT!8RIbF%qEHiSEJs9qtFUDuEb&WbP|mdRE2sg9am+n zCbFxIIX$E6BEm)@1u+HlXf$$XbdL#KlN7YrYfNJk`TfyQ3zTalVRwKtO+MC|1X3Jh zP~KCB3x*`gScjzS0cbNrs3~w+$kWaCaVdbo@pYzVAzb{PwyBa}ji=@Lg((vo5ZYmB zenyGPMvJ)gEh-r(mWO95BQU0vNjF{9DA&uh96FB#sh_|kHU}uqJmxtgV_cFI=3#{< z#ti-ASPHUO=W(p;5{ZziD>UI6<7Gv^#UMJ}YI6ndh1<0H2{eb{8oAvaa$Jlc+0@n4 zrGE#11sXCniDe)>7mTDW>&Dh!gz!Tt@r#Bc5@LQ0!)7bsX*tQs(~N^|G#fqKVR@F= zIGJ}9aL~kY>En>3LBqJABF#`2!5TFn(Y9{e9pqYf0hKxDkL{sI`}pC@4hr0uPHUUb zg@t`!=Yf<#Y}6o%G+%4fL>r46k=+ol8z6^M%5Y;8X0vQgi&Ww&h9GD_U4-B6cLJD-ka@WHz}+Vq=5`~b+OSik?O+L_yM~Bw7OmH zle>fhA)Y|c^;$XI$#+GB#4pBOG~@QCR6)2<@>7R?S&V=9d<(PsZICZGh3OI09=6L8 z5=Jzm3XKaO{_%|)N@B`pgAhTwg+u17QYnkLJ<@}TMp$dA*X|InqT4ew?l*B!Jw}5F zq-?=A=)~tJ1S_A(8EE6F_CT`-hTf1rqBI?wdrNm zV>r+}{4&>>>EQ(e?xu8?A6jiewxM64Sh%^spx<I0l= zg7*BeKGuS*UYPEpQn@ScUe)jR4ONx~u{m|myi%EW|J_47^9!k2=#|Q9C*v%dn27?> zh^CZKxu{hUVOMfa>Oq%k%z<4bQZR<9FhHC6Z;(vL!Y1evF4V=LW4buAW|z@T8h@Az zkKYAdBnK>zK`?k?c#pPWxjtbb$d4$Fn?unDS9=xR$XE*YnZjb3@mI9c2F#uAFjB8x zil`Yr#{)+es)Nd`(UOe5l85iAO^Ny7D~6V!ICD9K(n_V-Zp|Dmv~o1Ga#XE||3Y9X z>bB4pp$I9aN~H&Z4x@$%OM=>Pe4^Cp_H+y?!YQI^*C{!nvnIK_gfq;)MM~i%G9&oX zvPx*BQ_s|2?Jy5WS8?X>>Y^np$=row6lCDunR>ZZN8e%M4x^Tbc|MSEs4LN$y6MI( zzhcG`()FOYS+=MWHaSv-E=#eraMi-)kN$m7$?HER<{5(_ixETccko0EpX^sNVM%xf$2FgP>NN-ro zXiuZnKM|aD=8K#sa!-kq5R3KLZLLA9Sl&#E?M`Nur_sroPIV4nok{PuW%XThWcO-` zYa}Gh z-Bgq^rw-&Jn~8`hZeWaWUL2EPJx~$}G-wQijb&DJFcsu3mF3`6(qqh_d4cIxl4V3y zAYN!Z^l1l^lI0zLikFKd2{W%L%;FZN{}hRlutDx=?8TnNxz$aUJ(SsH#*a~}d7bT? zYh#q5-C-VA1i`XG%(kM~DiIMy?<^Z`319p+%Ox6S>L=zQdx%_ise2;+XkwBIOVE`d zSz*wa>4i?F5#ylGqZV0|Ww%X0jLBBgRhhwVDWYsVQjR>cnsQPORozt` zD3XwE7`hUP4>6&feWnW!c+xE0t@t{Dpyj+XoZN|+J)7|cPgm~OW(x^T2S zzCxr0s(=RH_Wlcr7wMW$*`#6QkG8OH5OE4F~~6mYU0(Vb4+ zW{lVf-7C7%=#wBvWUWIS85!)j8=_C77H$`IC}n}iP3Q#z%#$R-NqZjkWC4iiq&bJT z(#||I)k$kiys?}$+-V$Bus$1RtKBNWP3@LU?I@uKsg;L&ywzN9ENw^oRCcwe8ZmEt zmbjc85>hS*2A&n@Ap{!GjyP1s1d-FeqDX)#|t( zlEl^YIuejAD^4*D>F%ycV@NgAAH?l!N;8h(k#Y|(^siHBeQ;ErhSgV1r*lfx5;!-y zfIM+c1{4WVN|4v8&QrB!7|h83Kt?I5y~?X{Q10-Fh+Hw~wU7oX%==c&;+F6M4$Cy` zZtX`Rj9M;xrVw<_^!VFu)~^S-6H>Kz1FQ`sl8uPBByRbj?wB#S7Upi-$w5fD8S zU59u(wn9NRuejT4axg)jnf*dsU;@!y$kCX7cRd}E9*l}GNg35{88mg2IuDmb|8I+j zMf8hkb5J&$Sc@q`_`?XA*~m;5u}o%DSneI&dl;!X&{cTC$|%7Y7%$NZbvk0oSODhA zToWlV-@!Su&IFwg67mSMp+-^V zAjwwB-`qAsJW})3O_ffQq-oa0Cb5QQS_YqbdFkQ3dr}G<=doC$|4}IqTX1Yxnjc>@ zhTthDx+>J*ph|+XQZX5BK3)hDsmI3}_2bsQ8^E+I0X*4(Bt@LEk8P+$;^j802r1m> zp$m|G>EXi%{8zCw_zu#)8|z(zjmRV_D66su#km4yiSE4BHUcOZPf>r^BwP81OS@>i zG1ZkN4zW37p3_<06UG6~!o1N|U%|;0d1yzx8LAOt#jIr)=(!c~%Er1N7oFxIshEX+ z|4*D?shm6t4^R5WY~ZEkrC7B#h%L zG#Z~Ro3G;57G9=;>dU0a#)rk1hG8#7@*6yokVl(Jp&ePG*VPxWown347XcbL^y!q<7ZYmf$*9V-wkMGx5-vpy1dK_3;?N%r z9jgQb**b*3ui~u9I=ov%68Dfe>?@WLS~(D0fE}2bAyl4~=}O%gwaQB*q6llb#Yw?K z*Z5oBW(?kYqQ=ZskJ_z)*CpZCh@32Ic9(*dn5pDorJ`nzS~HnYAfysCjYJE$psYb$ zXC+BsM_nbx4Th+sjRlCYchM8_uH`m_31|GK5Wx%KlIT!se5k5^t9smh%jkzjT~Q!F z6EfniXjb~17uh`%v_6-y9>Z`m5P)=(Cq5*U4Ps|8ZxS`_`4IRHSGe$z_?4WcY%bD> z{Fih~;5I9G6!+NNk;8PmC-Wq%or*u{M*dgGsbck;_k(( z^0?2E;FOs!5rh9L(Wy9?0T(vNG?G@n2thszMa-Fpu{1*E14o=%79)^Ep>)g{EZDgj zTQWCA3)?1AqqD?B!H*bl@I$2?f=eM@k!heWK=!oRgorM}W#f+#qShzt?wqnaDL!w#Pp^ncduQw9{Rn|YST)Cv(mf+jg zn7O=okQY!3W#S^QG`^ZiM}(5Vy&@{f_AAmpkM^5u$2(#+oN ztQ;67qnt{*YDo>W#I>qTl(mh%Lp7bDh#Bk_4Ubq;9Q0T;6r#Oi8r&paywJKmOI>dC zm5`vJh9l_AAnEKvDlx!ZjluM5EToyLCtHuTDc}mlI(>;gncjsp7v=PzulrFjQPM}o zu~v$NA<4|wnwV&+=22uwTi28Gkc+V75<`fIGh3vQDj|WaR_RQ>TxkXm+Ds!`?o;TN z;U04W{pwCmzDmSVjZV~hr-25_$u_K&8CG1iYRNW=ys!!bsjDNAIy6U~>fkJG7-eW# zQlaF=9HJl}qLO#J!3uV&8H;38Db!*pvfzkrEG_IxBu+iqMOPe)DqEm_%YGVM*pzJZ zno3VNIEplcr$F&XE_sSAK+y1!k?=V)3KL9|Nr6yw*?~j5Fq|vfr9Gh6?WEaAf+;(b zY^N%Kg4JYuqeEtgPFp(F{Jo;}W~{@SftYDBZ7aSZs%i4y@-DIb4h==-uHZ~~-A>V^ zh=qn2U$7?NZpgX~N;Sa#H*Qn;k# zsA62^^H>&(*c%qY+H`hdUTgHs!&iL*zHg&VHU=!=JXM?UxI}ce8X~NC>C|T+6L=xF zcGM}=J4_M6D%o;9rAR?Ju3`+c8NQk2jNXtnv>xp#iX`J|N^DgosTT-e{LA=76;2>x zID|RPB%! z`@w_!qS8>hzEpjgCWPDZOpZswfNV7PoJDg@*#bsCqbAgHjJaBqzAh<|PlPYW3c{+s z>t;BSSYWavpN##;y^bW2PBz=NGBX$u1--9d-BCjUC0HwQp=j~DNvgtFO)C3<17)6%u7N9+c>* zVVv*0yR0WQ^O{Alz6!W>ObcSOU;>$%vWAqWQV+O;nd}(IG^_LgoV2z65b2_7u1ui> z?8#iSx-=y+ER7EK2_$eHbhus<2bm9w@o%LzPRWq?S`~j#&AT?$(o7?MsuGA1qvJhj zC)+AosMrt8pw*OW;+agMse=aP#k`r2Mmy?}x;wzO^S?G#n52C6| zbOYjS*m@GNXBRBls^Ksl$SIu;2zB<%+Hg`6Q>!U;DqN>~I#`E?`3*NYRIIAnYR=b< zGT&t7X^yd2f$*xq5RlLnR?LPV+;rcOqKHAoWNo?|bzD!+**tb?8_q5qZs@}9@a8d0 zxz%OsHKK_LvydbK5h<^%KgQgPhOCTC!xs0bc=5|Oz8uBoNqhT2fj;D*otLy$+A_eo?_YOl-n=mnu^<$N$Zwb(Tf3W6`IxgMmH<# zhA*J1&O+&06k)hZ7wAe^*F3T{Mb3j&#+nJ9FLa{Jlbz=1N9h@s^2dmTa^IA2AYKez zZj*`$G(yw><~oXDU~D9jVMVmjwS0M(tF4exbvX_Fg*MZo>6N8x-9xyWV}l_&_Le zYPL;~V{ol!mR`k(QR)m@q+saM{v_tscDo)*+!Iif&zJpD4Q<;bDNIP`HIv93ZfaJK zFDOT})5UFXfs!pp- zlxa;%D4WoSsy##(9ug@k17qDVB2iC93tRG&aX$&!B&I!NR57iYU1ehF;Lfc(_U{On5g=u!PX2mKX)ZGfU_SXNw8q?+aY3=UWy?y7tLp#eos@gIdx%<5>-2VTj zzlAFP|4x4kxBtKCZ&((5H&IJ;p`I-@?o5S+$m(g7eKI`Y?`+9KP>cT?^bw7#;2Sve zWDkyhfvtuwc{xa_3e(EYlp6ISZFP-9G9?nm6P`R#h4n-t8q64lhlu{70*V$|y4Bj- zW|B_Dnt}Hs<8^tUZ+ao=t4i8#dvVLu%XuW+QuuP-iG~!Nh8Xn5Oh>9yTi;8MjY^cP z+`7`utz%<$xQ#<%ON?&$XIjL|r5IvGT~&Q2Mzg}gNOv6Ixa|pxE4jonUr~=@;?35l zu2YuLaFHumEYzv%FkOjkx^te953%lkt*Bt5PW4jL{KoEZ{=GyPrPOagMyOcL!s1As zLLt@#=`YJJaVFG3Vt4G$qtt~o?JhI+tY`m&OjRD{FrQh)Q_J_!tGOn+y_&lMyR-E` z=J|x)SoXl;B@;5L412>0tBD$EJeR0>OZh!=BS^mGCnhY3D>q>|w0V~*)E@Zy?evfp zOQjy&gaWc@%UfJjrCL}UQ@F+|%d%zRA)8m4l2ZtA4GOOOw$S@%nB_k#dgfiASZrCG z{jD|hEzucdvatC8LqT0WN#K6P)=AhABV~cmQqEi&ebixd*t9Av)GD)otykBJOpH?Fk>Mz+-2iTm}j|r$RBoDcAD6O zy8$eYZzvF>6`5V_HHD3w#VH8cQz*crtXxQ;VJRj4^W{FELaBCBaB}~wP6aEJ6$0{$ z@meh8n=chd08`0C63C|`s9`o#p-9A^BbT3X5S7WEiyl>#Bg6HAh$)Y(+V8oD1@F`5 zPze$E3tmud{aCOWwbYY%k>E;RX%Vyk?%NL{LUS$*ERN8a%o-NZ5Md?u?-V2Gv^#jNWJh9$!?KTyXg;y#B>xM}DobXKdd2Q-1i~mPVQe0EQl`Py5^xLk_}zt6)z~aGAy|#t z_3|i@xkLwkF~1T_Wu+a?IYAjwBX<%46JH@eOzk~H7uP$g=K}n#UXWNrK!@$o3q0&Ra2o9^p4?ze--z+pHnkaOzvLeMQs-m826l<^u zlX5$^myP&Dn6qp>Xk*ZAK7*x0m+#ryRD@nRVR2G8f0$@Ym#)ao3!9l`Sl43}`im1) zuN@876g(lD8pBI;6G1GJo}9Vjl<8P`!&?5^=+2FJBTR`!#==G8WTdqP3_~?HWxPC2 z;*FZxI*A#k-rM&w91{vvI>|7|p&6#keveNaAayuj62nCfycvB;nKUY}n_tNGD6>t< z^2IDdo=DmHse{<=D%ceDXUGi;c(Yn$TQEk+n__NZ@5ZI}PF5pD6LWFavN9vwH==r; zX=7O>_Ai5tV~e=6?i;?m8}p0mYw`k{$OxuL$>F0u!e$Ta){U^%i=e4wV2rhsnkEcu z^T1Rg0?nrKG1&f378VL55=k?1CGB{5SeVw>+vPKW+2#;p#RA2QpKmBA5WrlOUG^-j zCS4L2kMXo>#7pdfQI9Mj#XiLg^23D!Tz1Gj7-rq;EEwmy!IWBT)9%-_7?1E}!Ij>? z@3bqs1uIn{XS!kA<8-fsBlXCtqK2p?^$$kNdjSnmPC$)tIlYu#QI)6P2&HQI=f&w7 zHOXF8)CcpcehR^6V+0cv?vg_?153=3-8?DOFvsbRMwp7x=ob_uLYd6U0%B!HR*TYQ zb5sNs#hSkIX|fM5T3L{7uxW7?@Td)AsAa!pm{X(X2M>vOYvT zCQ&dlx=D70Z;_gsdnUerJJWRLn{j`kv~V~Jm%mjGvVh& zg&EbPg@Pm{2l)|_n_!X1gU;mrnU)s^Z>mm zq7n+3tQIOxz4S_?MTKGz`r5t+=30q(vzpgx8j7amT#zew&X-A;rJrKdELHZ?+n zyP4Go$QjAEiD=JD@{!`kcYSP(b~<|4k_PIsc6x?{(J3vqCaSm}uTf-=nl>|7^Dmj? zhBHwF_QJv0qoz8Gf-DWoQ5QB$Y_6mME1Ixzcw}@KnW8EZnMu_WZhdufp~uqr>5^y6 zN->yM3f(Jd=~K!2R|-AgM(+Vj&N?-sB1c6LdHvp6x2BLa%9}HAB&3p6Qu_1tw$>aS zpLN4N5M+q`&0)uB`!z@gLNxnbxjgx(*om?y!@wl}8)LNfoG)NxD%h4zy+nhYpQHkIY8{ zKg5}8tYnh-nfIkjltX zeAY>m&shZhE^I`pXE&M?Nn^;fL4(at0%e|*2eIanj|L5 zBB&ghJCLsE9Y?^du&vT`xu3<9n^%m%oE2Fn$VzqHezoAG5UGrAI9Kn)Z+3NvT*Y&t zvNCt#3C`lmUsPHC0`vR1#GqXS6^h1~yM8MceZd%nQlQRNRx=I#;6AW0Pgl7z$^@71 z9lko*ZB+uAEF8nQ4s6M4BomO8h7YzVx}gQIqR@e=Jba6J&Sep#sKl(eJ^MkmX_KXa zn|u$$fm09*B(B=4ym6`rU|R^6e@d28IR+tNQW5}AC8@|ZSe0%<)AO+9=1kRhK#~}o zWH<0>sFg=#t&{4WM>Y^pV_H4YVlg93J6|wq0w-F6TJY`5?Yab3DS?`bij>)o?1O*` z>6Wc4U9TdzFm7aqcmPQHN#qCtP1^DjEN{!oh{NQ1DfbWFf}Dd}kBvc-%9Cjv+{(ih zIYA?uWU{rc;%FqXZTJ*9J6x*!=$4g&Sj+BKi9{9al2r7(j(aLP50dgNAYwCX^?*#9 z%iCeAV|JJ+m1gVBd2Pd^j*-(6GDC00W{7C{tFc#AQHsa)Y_21EB~uh;)gl>%U?r;m zf2GOMf8in&%Dkf_DCE17JxUxNtZPYMy=F(* zO2s@(30dZqaZXmtCN*Kz0b(koFM>`92@CC6Y1Lis7mKii{E)VACRe1+DA+@FWGEGA zgZiDWgu0BQWd%iRHZPGd2gJpVeYJp_B@rYhy74zN^^3Tl63DJYEP&+3Siykz{e$2)^msFLs(BGIke{~8 zXK;hWriYXqK;&xSmsh+5J*Ro8_#?fLvtVE{rL3PTFEunnP1VIjy)GO*Z~nsNhJIe{ zLJj`B-i3q1KTnyI3+;)rBpF|L1I8ZMBaJGW{nnyhw)4@=g?BP`B^$#m7)pvFN?3F~ zq_O#;JLVoqe4Wt%{;hI!*THL&>9#|2wrK&BX&NyQZN8Ur3~~jFQH5xFSrhVGg+NZ)c&s3l4ELLZ_L z?3um38L3q^Vkmm5j4rZ2kaf#Q(z8f(G}{Rv7&$w5eB9XwQ>J(rr$M{orn^M2h4&Xk z88C_$EL{}+AfrA_6FuRDA&?`Y%-@5P>nrqY*xfeF0eH!J5iB;N=xVn6Q{YzYhGnh= zH?|WW0Az;gFf$l5Yih#M0hmt;-033xR0;S+9eOnzL>70kPys_!y$B1HR4gu{P^?8y ztk_CyulN*ciy!e$@q#2y5tLnP%;TDhXweC`1)xuN6@+2Adg`z_JY+Hrk2FDaSEpS- zc?q)nL|Y^*;!265_RCTGMMVVr2xZ!Ti{6YO6(@6DtIM{?}Z+zk=S~2fs z0d$k3Ru>@0pFn16c7#G8ieK7xnX);}AIW=dwbYqSvrH1s66%G$w$zm=r5$NCE42>m zQsdHK_#C4$Y*-?B8e`cYbU-G6fn$vs*?0UREartTTJLjYw@N_vwfUz@WQge^Es=Lb z__`@*R)J&!*1k*%=g%T#vaE2~7h&^j{}lE!xllu)LNsLUuVLb|90_X_*b>sIrF~=jKr-p@ea;^Gu)VcbG~mI3SUbT{5c`qA2id zHQT8`3O+JV6nTaYNmL6yhIzFB2WX0tNs&!r#*~wLL@&H@$1=&FTvext-M;*1S)Fl# zi#ijP@Zx>06_3;`MALI68xXB@C8wP|!8N~F20DxG$6T%Uaj{q(3UcLSwX;%_>q~*Q^N)v1Uz~LK=T%Qi#EX>CIL+b*XV6r=?dhWa3q_&d_vv}I()H4?4ZjQ z1{5XRTFdNugcv>GZDYxPh0PJ3ylFz~ZCN**XjPEBnB;&X8_SRFr?R75BwFRQttpCE z2D2kx>ze@2B668Q9Coz+>TruNuD)kvt`l@yThMm7hQ*$T2p{+P zj;(PZq#r{E{V0iNB{1VbTx%ILv^;Ms3#_CgpbWV|bPbm{oVHua1Nu9W? ziEA&)n%1CRqJ>x7+QC>{A)^_bdbGGbJW!G6J`lz-{&X`GrqnIfDB<-_<{0V?1cfFk z@{5lQ%M^lp1CObOf&w$H7+AK=A+jx4zI;coLXN82H{~z;SH!I)!76uvlPan znt#<>iZ8LvdXs%Tw8HWL7Nq(qdu@ZB!PPE;q-az-=7x7>B4tEfB6q1y;{ndtWaKWc z&eCD!y{ugwgO+iY4`Hq68{epj;&oY1H8X(`c1Yi`9h#*OtRpW;<&xr;aDC9vuKRQlYtorfu8J1kK<-cAxrTGTNQQ{HibC_=e=*&vf%b;TFPadebfXEf%I& zag9gboLgh-hjU(UP$@trqR`G&G$21KN&_@5c1cKw6s}XP1EI=p;S^tU1JAVxQ;826 zJZxzzqp@va0~FiELteceF-1+dmx@A$M1}EVVIJMOutF6gJ#FN2h$WKsLGs3GKL!$G`w%D=UpJ$~LSrdj@GAdE&8(P8yN;%?x^JVfquF9fw#CjQV=ca-TV zth#d-rFhcbv?}QomxFiO;5SADf`64cF7jGg{1Gv0E=bH<2MdD$l4|-w3%)ojbE{$y zWy`#2wTW;%ytMv68rCPy2*3udmw1M1Mi8Kykm$x`p_j0Ki)k0brEWw(Q=9Ia3(|GZ zD{S=*&f*~^Vy2waRm@s^5o8i{jqk(IU36#^nXk@?kp@YN!e$s|6~wouD~J>JlThav z2b-0nmP>tV4vn&X^JOVW3r(0E7NSgXX@j#xhLy$3Ee7Uf$+C-qUl+ZzLvd*zvF!%3 z=yk{CqX>)M>`^vM5u=Ct_ot!t<)bcozp#b0u>H+@GjU*>Xlh)N3$b=Li-lNX)JfZt znT!#gxr@t-nGNYWGYm66F9Zv+OecI`{$cS!i^mdIt1do2slok}GHX+4u%m6$6IX&x zB*Z14`}1twf*I`0Y;pS;8I`vG3<$POO3XM*4uv;zI$CHp#{2n-T!X9hnijq)@{IIE zRb#(6V`A=SteKOq@}KtdHtmsQduh4^I*@UawQ<1PAVv{)->}d_5OxS#nP3!SpzB1= zW9!Oeo=jRI&mdCNOg#8Uxz^`6NASc|6gHZnkic#wpXG8&dy-CciXibr) zz1fQmL2__qC$%=YR;)r6HDNDgk%iHbt3c2OH*fnk<@aA20M+UAWf8Nke5- z1eW-K#i+o^>2bZgqC@%>>{mH7OoK6wq=lRbp*xhz!|%#@XdG-M)?_n1--NX=`f|EG zKaa#mADcLl9X(gQ7U8KBZYjvSfDNqh!)jCSim7%>Gn3cjRs`Xw)P|CTl1aV*NrJ;% z3#6&GHt|GE<$&F+ETh^wRdK7Ns%_sA>SeoWh=!P~50eo3Gs&Brrz8N3%4}g&r{3?z zR1v81d)eSAI+C2TkO8#{yyxAvn3{-8QwSu6AhTO=I~VPG-guNP2E_Y(3HL3k4D8r z=mo9g(~h#CgH{EY&xTi18Flmu3j)NUd9op@mN>gBFd<3WkZsYJy~D^b3Ypl*4ACTd zQz(RAcW4>Es8Pd|v{Z$ho2yNDcSy}$sMfObF9V&|-j-%9`I;0Ft1Vjb-c#|TeX%-i zQmAZVt$K) zUCc@Fd-%vAgE%qfkvK8rw`8uUNZfj%2jmVV#y40)p9&Xx0e}%oR54!Tnf1UjIr(FX z$c<%0wtv5^R1gs=0MCvXwxOmXB@>%QMn?R$+=OLTm3NFzJL=yy2nnQQ<>+L*z0acJ zcqgn?le_M5JiCq8@3mMAwOhL^ingPiGGBs{3}i=kyKg}v(G6aTiR5f^Hbo?2aiB>v z%S_OPY&Bu%it`h4M%@!4`#i{pX?~n0-X_9G)O2EeNeTNgz?CX!iyOkP7~BJ1Ok$1X zg_P#9!tYD;zH3I4tH#*sPV{MAUk0Z(8)C=^E!wt8_f?`fk!K7RqRuS5KSu8wXP!ME zqfmX^85X{sFG^oFkyh1nA9ZTkEJ->M>X!u~7M3faO zBee*I*E~`5gKxdaxn>uI_~KsfH2+zmR12GBHkkRaNVgc~ql>6%@3h&PWI%SC-5^zs ze0Sukp%TmZAWqDrFbxNSJG#iU_rUoM-#l96l!xEEF<+JwUDztN;ykM>*eXy|9c^Q) zodRKbcs9D$T!JrU@dlT!xy4G)3NRIgq?=06U1im8JnGx5qWO#*8zd1}-E($&Sk97YF5}0%GR}E`m$@R?0WYMdH;f&8lT?X2Pv+UPd=R`q zm^ItmJd5v#+Drw~{N-)diqa$6FCkwL!0$?aGd~Eq$hS(5|MZk=^fH4O9LRW(1NS8{ z6yp=EPz+r-koWAIWs7sdgSEY?n{{S8f`Oo42%u7pNyRRAX^xh@I5@vHic|4?EnN}h zPP!xC6v%uEM7^XveTgDD@+h=lG$iC^<7kSl?XtWXyP-b!}lKibr=d5E><2MC1v#J}jZEYWWs^2E?3?#zf(gA;h&8 z8ill1ae%@@$Rhnr(+;PrNGk~Jkxfi3^u(6`Q7yUDmFO0|@s#)joU2{D%~Yr6$cxH} zut`A`-}!59vO7W&bN$-?YlE9 zj0HPoRkr7=x1a9{!m=Fdf5r6K;PP&9R*#?|DNb#YF3Ik7+secj`X<87l)vaLtY|G# z3eik+c9(WIjytj;PgMAPHP6j^GdMbsmK$LKU2q3PL21P#GT6@{=Cy#q>t{7}2vtSu z@@DC&Z5$OU!aZUy!O>@@Y+IFE9D~9(CUWJ#xr$Y*EAsXV6HPoh*1Pi*RXVu%3SA2W z(%xCJ!($D4@L7%?WpQPX5+j8xHKW#zrMSy2h*M+H>`JfQQ*X1*W)$g*5|(>%5TV&E zmSv7pvGm!zO}$U4A^GlXU8#|+f&~&vSOMV*udRtyfU$Ou(4$_)$;8J@d4?rW7&1!c zcj*OdBof?+R(?GTluD{ubaoo@mB=dIwoGE%0%MR|6#b^;d`}OaDGm_QOg&AZP_5p} z>;8-7U175VQ9c1y(T?q1Z>ya0I2HVp*St%m#{sOisyo-6dd4F2jmbA#!}!sHKv5f8 z=QzmolRP7+{h&4EJvdLsj^v$)!iv%&BKzVkrVilv+odH!NJUvj8MtpYKRX<_2p%U@(& zW&3@Ykzx|cci>0C?k@a%sx}5T_CU?&Ps>(OX;HLLnIjg$oCQt3PCLk_;9YYO0cEzJ zq9re#C7NnmVpvWitk&^rc{N(89NxWm=b^(}_Z~QU_~4O!+mR#j1xDoL^lmL&OcbBQ z2u&FleAN!>j@K`kBf;y~ZATzoq!mQ+%=MBfo@v2r?2>_XLbxXOCIwTdA@+miszra@ zatHtr9h1zZKXH-J;keafl6^A{DpV36_ITeSz0lY~a6Qzii7L$N(55N4QrXs&dUJ+3 zt^T4ZyxJC|X{#y_qw}T71u6vCa?Qe~9)Y#=kTiZwYuW;qR$bd&kZsi>dAL>Hy;6;T8ieMe#R+x;O&VeA;IhAe25Q|`GS;okm281Mu$PKvWq1eolWvgtb zhJ2x|U(j8h9O)t?CIBdIsJ{?eTtPPnQg*RE+Ek9~j$#gg&0p)SVYktT3)k45yg$=+ zwJ=(A6`o#sdx@j3CLpXv(tD*3D?t zLq=9+RZvJC%7$|xMVEh}Op!yOF}H%E+RlH_?+{a1t9PpNCcL8sWR_9LL((8rZ~MbWGp(ZH8={gY*0@|RpOu-$251q1%Swn?TIK?l5v z-8U*-tnqogWEnG#Y9zXi!?1Mq6+VP5xsn8vxn-n2$KFpK$(^GdqwG%!3{b!%=phF+ zgK=fVWXSU55#LH)t#CA4J~R*?f`dr;;X z-&$xpOE_kWcX_F}H7uvXV<{fSie|Xk-Wo73xhkPcONf+GzeP?Ci7A(d=Xz!?pdgTz zNk%GA*@uXfoo^lGv5Hv9s4_KBz;d)q`x21I*8uY>7h>hjP>m8=mpLZvsz;`OG-0-% zh0!(TzqV$>ekZP?{gzr1WPF#HM$=O1nuW9HGqw)PC6 zbNntEi^X$ki3A2uk20Xt(Q0O!x>F5lpjUc&zHbbqUM8L)8HJnHp3<(P;SCf@=_)lY zX2L&H!uQ0oBlLNZJ0WXCeG5r^e0kozA(3J?m-?Nizt4p}v6Bv|Lup->pH_WjKkc>P0SKH#sQ!a5+2&jFK%)v0F zPRW&FP2r(>FS$}%^|HgZZnR*MC>Ac}V%9$a@Lk}xrV*IR6HU>QxQ1W2x`clAkEIlUY# z%A8#$b51EoSNn~NWr+wD&Xl%T{F8RKyaDxpiaQC5I-cVdw(}CbBdSl8iyIxRCP;)7 zEB}*k?S*%N5$vVLcNtzodDs$sc)?|4tQ^c15NXR#jX=1pguOCtC!}o0%)AQF?T9T=Q@4$!4}{Vf zn$}#LM%U@dU6Q^GMry7;ag^gNEHn#5(i0(NNkQ6Lj&{8pa$ZBBX+G{JC ziDrhsJTVS51SWS&OL^Q}D323M&`5QcELS2PiO5pXsL*5~2e*&&okjJ7!UK9ohh{f( zY|S>pdd*JYGGR7(XCtM=_j7Zr%-$(`HEqhyhV1N=4M<1D<;5sXmgI19a0RpWgxyfu zTU{6)8QZjZ(*}DT4oEl}p1C8$m(uM#iKqy+7p{+~i~qqB$HNmxHmzSj@I*_$<%5W` zG8~AMVo19}9W?6+L{eI6IwrhnJx)mAX6X($dh_tFPZ<^iZcSE~rm2c%WFR4ICIW(J z6`~FM4(&cC zS0NY9g<)A(%?BTYRQ}jt|xNcF}Z^TyaA`*y{sN#^TB_6YehgMmR+a zLS97${U7(YuySaRri8UvGCwKc436sEs##ZuLrB9y;EbLoqqG~S%^%3qfcIi%#?tjm z3ie{GL^>l2kb&d41F;?sA9`T|gF98AM&ZT$M|Ca_))amV$j%}n_ETk~JgSNcdG(|0 zhcQ;EB$W!UNGOl;RcEzaf1RHl85=2$jF(0>rz0a1YQE`HtJ(M85 z55W}XP#V}W9)XvL`t4$bSs9Nxq`YIvRxEJ6sLhL~!H!q0D+59@E4<}11~4-w^{a<3 zzW%~%`|}h@+s02QB~>4jM_~(H$ums^wq!ck$dgAk*pl`4$_2;++~ zpHuHyYIop1I9*eOhs~#E!dA`tZpNHrvyzT&)L!}t7c{GAIn}WQ*-=3|MXFn>EQ%`J zYv2`JHCs#git5~TaxiH;2pYDO(Ccbcb6~aSZtdv>yHnb)NIN=&%6hdb4z->@?_t9b z4G)6UUhB~onAa|@%sFWury4CB!+Zw=;58y3XtZFt$#GR22KDBJI4=7X#~FC3O-v4p zTO`S1JRROe;~;N&igx%6;pRn558K#Xd2skt3n4?JRgeL67hXG2o*mFdN+yUDyOki8#u-+>q@GFdDgmYh)Vc&T%r#GO5pu%IZhRAM5UN?Pm?#D8=7{;)|v z`%w#}hl6gSz-Jh%lV$=>>Vd`n>l|cCksA5SF5{S*g@3|rM+unFPWIv(zIr{Jz7(pH zITU>dkjcU%WOEWj>ME*g*z(v9%5urr`)OG*_pq=wfyC83*l+Bc;9FnMSR&tv}N(9d1vg zXB^mH(vBL+Ih1w~a+*l5+PU>$Y485hj;-mX`zQA9KL6_d`*xnOhXpaE!@LNrORlZm znMijX*|R6zw{`DM_ITgBb@!gfZQZfs;LbybF5=SGOdmB?I$W>LE#Ifi{PwLW%4{U5 z6yD+$J@eIkv!9Zqwxo@p=6grC9URV|G?ChwGxm~7&XK|1s%LEX5{A-YcGKteZlp=6 zk3lD1fWcX1!=c`VM-J~QZOX6H2-$h1w38k6rFkdPP3)g^#(}1hHI~2}`vtYIiS)*e z3&$>y-Nn}nTj@pV=mlpyp>&BS>V%>zeN^eX@+LNhKXyj4%v&er>>z{Wow9EjLVWwiSS)1Jz!;Dg9@MM%kFHRY0GUrye7^0k&8(+}#c?dMsI%}DFeH&=$C zr|d|COvT>;inWh)eo3Z`AHt*fIoK*|PBgI5uhlQnC0RZrfkXsmW^C+*pmjiz)u z6XPwj9c2Fodaz~ak@)jcdyy*lpfm;o& z)72YjoHJ8xCPNXI`n6a-6ednohCOXht&IF(jqdQt+k1VsPqfaHG(whX+KA2hWKJ-M zD^A`*{v$T1-&g}RC+*~q;lXs=5SZB&T^=gRFp7|2*kmcSri71^kyQ)S=O*aHZoMpk z%s@skJ_eOuAPOKnO%%7M2YIlt50_0qia0ZuW1DpIt{E*J)mdHSEMZNosQ@U=GS{w5*yHQqqmI=6076pm>US+V%ZFP9m;a|AugqFhCxU_t`sn2OBI11&2<)lXX)a%~XL;r`rwkhYdJ(vf4NS&#g^c zYAJg+lns$pLohC+GufWIAl(65*Lee%$ak(vZg1I^t(l*(`A)wvceV}Y4qgHiDDj{u zUNLD+Lg(Zy*#zoMF-($acBfgrHC2W@0-_+ zt{-2&ZX_AqJi1}?`Z3`84I9^uCisR4w&l9g=qUg6bz^B{Q)wiA-JE?L#aj$#xiW69XM@$q$IqwABg4WpY!2-YOyWqmgA z*~n*8vSEDF=-B$PF*>$!<0dXzw_($0vU$V!`jHJA$415zmlaW3f;uJx%5@Q`2_PdE zqbSR408OZIo>wf+<(h;!lp4q+pC$~}BlDQ?FKyw!vN z>1V3f*=5*@nv^3(+;N20KdHCvm1TKI-;iH`w4nnRm(%R-NOVAZ!E2i&?GU}Bz}ncv zf6K?MCu!J-F~o#8g#{oTD05NxRnkbJ{8Ry0VI_`)J>yQkvnI*QD7`lUOI5fP)(be# zo?T9lfVE@w8={UA+xoz)U6df@^S*jy`7Ks#4jfG#!j-+Ylpg<<=}4xHO&8G@khr)* z6G@296u0DbK~kN@3CQB15iOIAR;EZ$h@?4L1YVApk#>F@grc!`Qmw7@EBER+|;SG}sku)U!DG4Bl99M7h{MO9g`eUKqcZ-gLh_i*-{4S z$2wqGAuQY)-&9H5b=~d8Rk+EvLy_U`#JU#@G)lpcM+3?ZYqD%B+`HAM!L+COL=-fD z<5T96j1ftwag9?uR7(gOLQ=j@Jmk95trkfF#fprZW68Fr&;m6G-3dN{;+t0dh=9-> zgNvL-K$cx!l-lW*;*ssa$Of;~v|=1U**{yHAq%!(BVwc|zYW%@!$db?9b)qFBM;H$ zB%&-MGqB59f0og!hdtOOl7>l^pS*?bcQ72#$@BEnDKqdA%nA9izgA@SQ%MOu!LRge z$AMD^J&?4py=-ZzOSjT%lqWBqtXQ09mkt=kT9*pjNWHoVlkuuF9qWX%6cm-j`i%lxoPHfx| z9{lyYeF zXjmcE=Fq({oOjIXHolR$II_r0CduG+$4QP9-H;2!#x6B7{5mvV?yM(E#W{{$G}A*k@lYLgcl z@*R0y>)YelP-rTO>Hm-VYo)acZY<_iQ*VYwX_l_MoLOT-E|N{E*g17<6T$}C~yg* zH)^F@){U*#J8F*1r6=!b$@PubaJi4drWSUwhy-qaK!?5F&B#e8ITkF9OwE}~8{PmA z^dJ(5c&$Z;A`aK4Tes~NmDp2zWX5FX@o23uBw5RNT{JH{T9zk6`Z%(S?E9l8OfiaI#{Rwx4E<1k@LFJb6rZM z4R}b}RZWq$EOV$aD5@oMLeXuJR4^C}*v0N9*;13u>FTCL2MKbTgWN!ltQZI|1Ng`} z@+t2mSCZ#_*IN7AUsW|tTESodTdc17e)iA$eb>*%BKQQ4pWN|Ya?7QW2^p-qPW24a zk!eA}Vy0@PrdbNk;+U6MC)6zakB)ndx1#!~un1}S0zL!W+9DF$*XUjDgp=)dZJ^q* z2YA3jNrlg1t6{ik2_=89>p8bl0?2y%iLe8S2^bMcELF%n(= z(`!rcTJd2pq1IK#c=Xbhl;)Db2nkAvOJ$MT^wZKL03xx(^|50o=d16>sKI-n`^=j^ zS$z?a5Mc%;N6gNB-v%j&c_N-?dv2eikYN-2 z-2_py$&q0VLPuGJmQYWJD`2gffc(!=7-Y~Hvtmq5Z&`0zZOFbsyNqovSyd95E4+sk z*vCaYdU`T@BH(!B#VE>htor;gmYBY5K%p6IF)UrXwP9w8bb)f&;ONZnhNiZGilmCk zWbvi1v=yew!!SHM=Wlv5qV3&Rf48?qaluH!B&8L1rEa_}AkK`sP~bmpBC!u+NPmVt ze+j-xz$ljzs+2R&$1_gOMI@A{%9lvU(KBFbX)VRr$&xTlEQiK`^Ju_-&1h}8b?!k7 zngIjWk`T_MYRoowJ;R>;Hg0sc0ecUKh~9xBd_L`c_vqK@5oDXBDZ#w4K;I{LHh4kV zyX+DCvaB>8q~zY(qmfzUoPIOsq@hFTFEgq5wEgMftJ@NTr`vIphJ%cHCqlSD#fkjX z#ktu7Qqqx=Eshea8IcUe4Cv{(@=o|MBwo}h@*JY^NJ*UZ)ag>UK~C6irITRE)O9?e zY4Ozh5Rws*q&A^KviW%GNvYQr^8QSte;0#F{-xxAx)O!G@aA76+Yu*e{fcE_{+IR= z#FSzio5C{VY^;Q>Z_OGGkc9XS22A6RFl3c~i_N9QlT<1ZmOIUIKf{*y(n@cfzWEoO zIxACKt9ogyGNk?jtxsJ&*vdz1j~*UF9*5*_kpCBfh)r+CIVjT3idC|%Y)6hN3W3?z zkeaJjB7$DEEYnMv^ccZdx;dOSJ72NSC5PKsP5$ddNv@IR&dlC%NC=<7dW3`or9)O> zcB2eeRbGt$#`N~~?deZ`5`-4t{dD^G(orV8zYhaodQT|(VD+3`IN|ZO$lW0=DsTuQ zhFBZv*xNuTEQ*?&K}9fj$EK9sh(ac_ACG|by)<8*T#iw7&PZ+p>_c@XiT@(UPw(EH zUc&U2IL=Ek2-t{&x7}Y!ZS2B$G)_7=>=vbaeXh@DQL>^yFA^n}97qX6O&^(SqA1FT zP{v2HSNQ7-z*5Cjn3U^XqAlEm8Rm`KN3QBdgQJ>NE`{4vzfZL%%Xr~ zaf~vFQ9H2Q9>zwpdI;eLB*Ndv zxF;R#r!#FKI$9XKI6Sk5unl2sGYbBd;HP4jSfK_Nz5&02ypUZSVHrCH&?qW})7p@u zU*vebPPCYX{8+TlkIsI5{@4?57qtC5Sg6{aHnE3*CC46!T{wEh`=BT zaR;G@Fo;qYuNEk+orshdf(vKw+M3bS#OU2o8M(o@Lxcv@wre3&Q zVn-i!lqh?$8Tl$&2kAq3UZEAEQ~-belAcK_(@&?LKfH5UcZVM7R#)6|73~aWA&s7Cz!S;7}U%Le6FCamM(Lrd&cnh%!pJ)Fij-+y=X97{-)yIIg& zBv(Bo7^q?&EQxe*XhgP(pIG>>N%k~kQ1F{2NRWU{v2NUqm511mg|U66Y-V0aABxwR z=u6T@UJ0hr!HNX+wj?pP`sx4S1gJ|uF7tPN2Fg~UIHbOu1{oii6W=LSQqN8NE?%p| z?%$b*J87QEnp7oVaZQSr>RMQhh*{>c?Y21L9RnQc`>vnsa!GqrkxnK&%$2+#jzITv z)$A^7dX~W^?F~zINm`|aKednJ#RwMCW7d8_g%3tesCs}K4KJ`?+n}&jC{IfpRxI3a z_9_s&SkKiR@HUrQ%94dOuhF&mPp(@Jbo=wE--kJyj#8Za|bt^%%!bI z325iLqq!tYR#uYX#qxD7FjMJia%eLt{$_#$azyw_B<;63*nzC2Lub~^LGkN!%L&p({(SwB4{bN&dSu@CHSjViZ~vx?fY~ zHJt$-Oo@@A#^@ph0?-GU8pvPDa7cpkvY2`~W2RT(RF8lql_U5Gokoz(f`UeJQ~ zl$RpIGqO@3Q<)v-3>I?ERSS&;>wlVB&tbxp14sZ#nqFu2f?T7J0aStfj)zcnO=dID z3>INENKPo2AywZTOof3+v69N5ZMZgwweR1Wu`^3w{A9$9nu(a|m3N3z1wF8_rAzvo zJ*LQ8)U0c|PAfZb)s$Z69qez@;RmGW$$(S#+4RztI7h{2pCDGQ&`oYfx;#|PNM#NJ z`H5UAwZ38A({G|UqBGf6*2tM-8f1lzR@Yk83817DSnmsI*)ORNq2o|5*EbQXje=^L zsR?7oA-6DQ9Y3K3@*&9s@q-DU7zYUoM3VT!zK+61aVXNvA@!Pvr!2o_1a0y{NLDo?hYU(E_JsZ>5mPYLs!!R|jO zNhU#t-~+smwc|mR&Y{vsWeC=OS+?2IU!8*qcjQn+5D7Mc>b9D$*%~3Qn`{Sjuo8w; zoQ{~uj7>3gY5!5eiZ^U9dXihQ6#Ly+l?7ofqWo51=Z{3=FUI_+tMMGyyk0eE$QVP*7 z5~8LrRg33SZunV4I*=JHRx-JDEV_i{mbf0gLKIhdpB<@4-bUaTBmJ0BoMJti3NZ52 z@kIy*@H(`i&urH-(qe!=C%0a{`4ex{R|G$7&599EPn3qhJG)Fe{Ac(?U<=f|0Ha?} zx&6gm@#_$j5^}ihqVH{W_u{YVS5C^dXF)Qz;}Ny>sz@W_+DYnhMq}aEY4l8Ti8jV;n1(Y*NrMKSF5=c%&E=95w8%~niFs2h8h&< zt_#k82wFTR*2uG4mU=9X>?>`4*$sm$rcK&ggEH(lM=*0Uh5>ZZf(r1z_c^5zT(QN^ zxN4asBw`2?!TN%cH%|Rq{M0{_wnqLC=knmoCiYFF^#>pr<${?yDn7&uF4@ZNVWr^q zw?a$GENd_pOw592t(;EI1Z3WcRH*Jt)B%vY$Tt)D%mv}z&Ts`O&e)4bW^`vm*!cQT zDjpr^;)Z~SGIWeY&6+5MWzuMoPJ-l3n)MQc%TGkik#y%D)9s>AR6XhjA%07ToSz;T z=JAD*Zz%-qnOJ5hw=X;c+z+qEi2JaRToz~b z5HPeb{uFld<4R|xM4eJv#Hr&j4$1Ay^Ks>YlNHtO$(0IWKYHNU^Kg;uc`6;0%mm>L z44;J#5;>8=+{@wc5Uw!Y#T8i#M4wykaEy)pT$TF5mn?3unW3Da+D`H#RiDIg4B`pC z1;P=InNQ#R_kc`X1;EQ{oNN}^S*klxil@X|MSS!e6Mg9i%h7;&3pE>n(&xdHk|wOV z1Z?OFt#(Z(R8}K$2ZOxcRJI&FC3#7Kef+9H$d5%!gs3Uw(NZ;qH&~EqA+RHeg~T0l zn_1wD!Zbag`3Wop-jd&y^r2*ptZ1hSPJacPIyoSGj`HES(e)BA#GeF@wTX4;Mb%2$ zXu~4*bY0gWJ2s42t#5)yY5rDGRWsv}6FE6%mNGm=f_+pjaLtt&iC!Jzzm3m=F+- zVUNyvvQSr1g~c-PR!K(*GyamB%c52KUtdV@7yN@|;{1`I6B_BZ3>6*-!G-xY>_4-MkI2xlb6Ea-H0t4XrQH+!(c3-7vTwS%qz#!qcIHyLTo#UIFY_45g!?2$Bgm zR0}9!a(gACTk3tU`*IS@7_uchT7(wt}k0#eU75%8Ew~z^+LX-cr>ldKF%+UZbU|>N(u;f9*A`{GC2rGph(RRD{ zKbud!#MOmh7BKtK={|NW38P9@_7K<1TOY}*Q=x~5OPYtpfaMkPMgv(INS6p4ddyKq zJ=}#Kk;-Sfe73Op9llPbO@|FD%jCJxA)yc?Qvc{^IXj{qjWT*@S~@#BnZ?7a4qvCH z&Z5KP@#~pR^O`MYPCuog2PV)Yclgh5an|KB;NlFb5+%kl z%XsB-_G($5^?2J&y9-zU^5n5JpFF5!k$Pi@iOD@l1UOJ06?UCBMehMq&Ac2LDtY{&LLf7!}fk&)Z*DsJR!WO|ch%39*HZL1mkU(!) zERn}Al9JdXgVF}bX8Jg&lQ^~+i^GcTBR^czyXV^sG>8viLsSR+^rK&1lhF{x2`$lQ z)t>dw+W;!(hs*6>UPF&&@s$I9EV1J?EVtegGsb}6`zJ~RU0n>sj?--Xvt}s+*qMel z4uie=7?U+iw2w{?3<=KDl*&N8nE+1+3h`6HCw&9P^e&oE##IO%Q|a?MWS~ z?H*M6)|mtZxNaG<(lkzIhVZ~RQ-=|Z{c^r&vX2z-$*+m(9lNK)bWdGb`MoT+Av;0a zhgmll9ULnly_^&E!#kM6DBE;}U$(lK$45`$!PD2Xua_Lr5Lf8}T`9YVV1t635IS!s z^hr;7Cr|}TrP?vl4VLD zZBU_7C%Hn-teDJI*$PkVC=^@iz8t4mSf1*GNOfZ3Quf2_6~ab}0r-abX_tTjIfmy{ z2T4Kf(H&o?jFoZrTjm!wUW@jcnA-d3lGs@GOSVWduhk^sp;spgi2$~RDnKWGr^=OS z;nSQxB0LA_(sR$`i_9ZuCOc6^`3Ib&@30|AMGvqFah?n)D9EOv1QGkJLw5p)QcUL- z1+8?Zvj0|t6ICl}ly&XA<>yzgPCx%dD`!oOe-^Hi#1X4XB$us`4ezxrGyZGv7;=zs zt4Qdo3g;H$5SEIt?4f*%)+U;PT-F}?e+ zyW9WjffEo^7lT}tcO7_F5%t#$yu1D1cHlv5+Sa|=*LPfZ(o7CX55|%{-CmyV=gH?9 zy@V9(1nm!nW+;^(NJFs`h`Jo7?57l00{-PGh0QlON%jb3+PTnzvLth)@e&b2=@E|an(9BmbQ~NwSq9U`kO`@ zt=X1m2jTMEX@!|>Xe_LC$_1^L6&B3*$RxYb9yNAgv>8J>=IB{YOb|fQ3E)jb9qj5` zRlYjCzppZlX&}}*-s^oz4u|nXaJtgw_N!kfSOP$}sQ*(x2 zbuj1jJ35yj7kio6$|A%%moO zb?ui!Dl;|ka)=uJdvN#+lF{_q%V=AqdDR#ikKOJd-wsNUXxU9`|K_mQ$!Kz?S9Wb} z%fhQCCooXoN;)XS%D%@!mT3YBGEcGc50|cQrXiYw1ghq!rYr2<6I?H0X5_qLz;?-N zxUJ%C`hZwwf3AciCjKy+$AlTW17o8O9C#plljI4W7Yk_VV0%Q9p)I2Wc-R^nYo!tm&_ ziHd><_=j?^RR0&-=oX+nmw^%agRSI-@ow@3)S4#80FksB26UJxG2p^Q?@?%GV*G#lA*cuUf5lgyOXN)0_O4ZR~pF zDx-qNffS?h9~Cx4%o4qx2B5Zue8caFxk$^&M`={YjLf=+A@m9-L6Z^p4&NIup0!rIAbysS7{7!~t=hln z{$Z0BV^J3?G$^UWcP0YL6Mi+l5B}r8(wpD&2tGsc9;rpJ7Q#Uikz0cmBstJHFEN#6 zAG75G0f0MUK^3T|j~JmeOh*??D62TrB4vd;bPt7Moccu?Eb+Nm7qYdX0}OCj0wHvMgf1i_R)V9DEKIxp8q0% zgJlc)fq#^vV;*q!YO}{OjJ3A9emjB*<>QtBv>+50B?u_GE?hvwqRu}~K$CJoC@8s; z?>7YwO&krVQI=S>{Iq(`c5IOv1HZ{bfgd9(K?0C8dLHtiW&lvHNFayR&6x2hlLi3I z@jlL1f_fENrd96=XxC~mIR|0wOEEUor+7}}+}$qJc`zH9W`;nJ*A&1a)uflQeM;mN zW%7<>K~CT%Y^hub7yl~vL&qQJM;pRhrt{b^p?0cT;hC|YoWkfWnce^G-CG<2eE9q| zw1Mv)-#$=mn>p~^uxHI%6bg^@<4s8&%~j29wGIv+TFmG@N(k-R{KKD4>2b@uAQEH& z|MPq#J0OF+?7HNFTuO-|K2ERCuk(J#3>Sn9O+B5e7ePDqqQxFF5wIR8LP~5qQvf9n zy_-lp4H03?MHYnud$E4N=P|(cDD;0sTl@0>!#x?v9aac=t!>JvFrQlX;id4pkvjz{ z@*KCD$TkO&fw92^$H)|AWru5pRmtI4o30v|RLg6zhM>cZE1A=Pa{ClI%}F7JX6ja~ z0ForT08%0{bOPF_aE}9TRbgU#uLzJIv)|6ouF{G}y}q5-A4V#wQZbsMAdR47a@8Pg z9Px_af@)XDsn1(1a`{P59Cx0pi9nwP5eknNs)?UziZ#<#XUsQD_nCte>^z~&ubkKWl!_p)Oua(suGG%3d0g**e2G=}_!=`PHkdGCvM`q? zB>#|OX3Zwo4`s_Ef{i^Mm6K51%?pX$2uqLO{3WrxUrn!&)N9D-iWOk|>{waw5A$I? zB5W-`tKyq?y2|59p%H_QtV>h9_!b;bDQ!V#vc|ta;8)dS}kI$caB>S9h ziG{&81mhV3X;$eV^F03EoJLb=n1|DAABvp5KF>akIFKLBr=Mn*b_Qzu52eIP3hRiN zwCMQcG%6MKHVhZ*7Pxg>{LJ!m9alIjofjohT*D27CL;uQ9ftq*#qr7FU`hG_pru4A zDIV@djzl9SkiLZk0DB^tCP}0Gcf3TC9Yz@qQcVj`Du>FQ9~@$p_GK;A_puX>ztm|t zkV0iD$FnJlT{1mM=A*^LoMNB+j_AVSCtw&4@+t4a4 z3wJu+PEN8f)nss!6D8NxPb|_#v=gx%lAzY2@#qahwUDhB%qQ|yPfitARE8?~UXAxh zo58f9G#SwZ?U14;+M0k3K{XxL6l z;q@BW+Ow*fejdq_CBihoh0cT5QnvW&STyoW-gR4e>~xoE4Ec~H`W)c{Nmn^2PeTb$ zKbSsnfU8zPISlGy{;yaaESyw2F?djax)R8Y?B1P8A80`1(u{wfUQ!40f*Wk+6FEn? z@bSshZNTA~)I`hTP1&S94h%;ko4j)N0!Y_p3EZp+m7^{!Jg#cEN41i ze&%C(W;*={1;vd(S-gG5fYkH(5tTT$72-r=&H!~44l5S4Y@33=nrRafJ<3O!dTULE zR@3UZw$N(GE)mHeXnXP;Dmj%6EJ+RLIG#zI|VeowGSRl_a1z6T%fL-H712v`x80?;_1SZ2WknOcQm z-Q~1(8E$AX)q7j77q5+YbNu-9szglDSgh0&UaQn!czL8&a;ynX+m{?t$IH~p-cyrR zV7VdV-t|2uvug74{6zWNQoqcD8z|wXKrfo^59kNKnPD-<-u$bQ+{&mTB}Ot&J~^|G z&^L?9j@dOIekl@`D_I~figgAgaXr%q5;hKS<9WD70Nr8v3b@nX=(biN)>*|*H79$V> z;^-QCg~67{`ym&CsipaE93pRIey8FJ6@BWt_ z@;jujn(}0AohoQ$iOeoU#wVH;jm`ZF*91toD#Zbs5VYW3w(=gIE^|2&vY?U1aG0%f z>3Nq5T;jlxh+Az8!UciQq*fkp-w6PEXj;=oa$tqf3j_0AgXye%t;gfrhbGSB@0sEH zi9{so+>sm1JPyB;M_j#=WDR1nN3p`xZD!Kos2m?h%2h1L87?G|K8etq)=}MZ0X>r| z_@*BS<)L|?h8JCCuxstho=JsF4AU@4Ii6|KA;`&pL_!Dh$Y0fr<2X86$Ra6N)8@`7FRrYI%$evN!S*QpW0G{E{Sq_qD+eo#d1TAD+3eZj z@k_Nz)Ch5-=bA^0HbzlH4RoP$dvJLv%-;32pn|v~M^?gzJ;8U&+67eCVjqUeqm6X; z8teg8Np&fv&4d2k)i5X@va6Rcvcqn19FNppNNS}bcrRCH~*8eWQd1(B(#ecC9dxW0oWMv<*9L}%F~ zL{yDxd>B}u7rI_@WRL}AyxXRcE^J*X?76t!2BF)F3>ge@%!*Qf_n)y+tO>#}UdWO; zTddlz@PoS*BinwHEmwz&;R#f%9O$S?m;8AWS!q0{MH#m)`**!~7$78$ds9(%-}^u=krN(WYZ?`(y|BcoCJMorO)giuo;z?FbiAVW++$>2Q3O-98P&G zkOeA5OQs(wX3ZxR>y6_#5mNTT6@sPS=yt)FhQ%9p%kULXbSELvuId<;)cv_?g{$|R zmCWE7LB4gct1(EGPPuMhXY%B);INNB`0>k+H%<7*2On$7KR)|-Jn0|nVBn8=mr5&i zs<+M98>}!!NZAgxL2z&WKupjQxp;htVr2xllYl}`@atg!DvQpaqNgqC!^TEr$}gD$ zHW3(-?Gk<_pahD#Z{4FF=awhXrKx+<(G<;~u0m!7LWH1L>WYH^&sf|j!S|5tqoM?q zT`Fc0k9^PH=(r$M`F8W1H@j7)bC&Vz7T$^@qSg%kv?pD%*W?Sy!WT00o!IaE)MF#b za!s((WH}*F0=P!e2C-&7GQU-%FRimr*`K~A;6-hR)+$d1e42AC89BTnSHtbMx)XC$ zpp3c+_YqQneVfue4xB`h9OvZn5PodKK^A$ZpnaZw@kN?&MI3m1>lit&tk20UW!eNn zE%+DHyUzJQeq>$Mlvpf{awSprdU9#4Fj?E2-c5hlKjYBk%wx?PNRk)vr|E!blb59= zS%(I-!_AC9y7LsLpQH42NEsUKCfUs|6h1gtU=%LWRh%LV{c>!ccCX~3Ra7lS!ibVC><4dqyk3H5D>g= z=~8i&Ri3;h<6Qf>XE&y``(m68Vd2<_r@vJ?x~nT6-eF5wPgwxJd5m-buQEwc1fmMC zT*g+`$``4D7|5A4HVom9QNilkRX^Zs00C1L^|jt|s&^0t(#q_t5h~Vo2f(!Z!W)^H zxmo0h!Y|ZQOfpzJ+E`g8%8Y?^L~1tSrFKw^?fhREw*AzeL7sN;-Moacv?!+6R%IGe z;p5(Ys+kC|T9ac((mdj&zN>*y-hkvur?xOeq$4(!0&wBXOEP!uB}`qa5{V9^DK;Y7 zydrw^y5#q0G+5=d5M;BW5lSz_;}(7~=ooD@Qccr~J7{F{cyYP~{Oc3Puv&(M^o;S7 zP!G*Xe9OogCY|%uq7Uf8;X%dZ{_$@XfAdfCyFk@yBBL%8UcG|cc^V>BMJ`<{KiFZA zn1_^zS-!BrhPN;ofnEs;S-Es^a-_=895JEtLL;Rxzji+Xd=Q9HC~_vkF(a>&Qdv~J zp=N@EJIX^Ft^&#{(O?)+$Bc33l`G;vRli-il7SEeWe|v}*`s2HRg=!NaJ6Y2kf)DxEU~$ z;Xo4^;|&mR6xHcF@Unnx#kE&npPXO$ssA~>0uSi#)1}Bt2a#C`I*BY`P=+7cjb#`g z6g#~_1pc+2#J`Y;9_3HVE7rWOy^jTmC-8DZcOD8dAUrZiHd;I!gWXQPvTqoBIazO= zIr(%D&CM1Sqbes3PEm}6z~1DmOd62*vOpq`VY@ZtA&4*0TRXHEI*vA6vQ#Ao?lsp? z(T?8V%T1WrxEPEx{h7jXIk``ef{r{=m~k|68~rXO*KWvAdD=1!ZBA&kd3$}Ynq=#h zFi`Bg$4QFQtMd=%*M9MnI5)e|W_2p76Q3?6*pY=O>dH=cyvX~=@2C-RqxR9a6a(8; z34!5rojViM*$P-EqvkRaPx)GTb)85IM3ZQ_b5f;HoMg^X5(k6~Wp3Gx;{la3Y%4x%C-WGLHjr;q-2y#>D69tINi4>E0CF$;{K z3{Ll+SPAk~3};#121($jU_8X5-~37KiYIW{E!i>b&(l+SaY(H-2Sk&?CN>u58eTXl zM2FaA#F)Ia8kJt1?tpW94Cg`|YA7QQw1Nq-`q3@_xDyS@m7kb zuvrmrd!HPgJwD(62H>pW2y`@vujX1ty@hM>_9P~V5;6+rhKC{^l9|}{)xSs1Ut^IO z4J?L7(qJT1P$%%bXR{}4i>+W8ef*@MymxyP*Fm8%7=kkf1^uPeL34T*PRyO`HNKvQ6 z$Ofx)UJHcA8k(L@FG))Q)yCq*Z$e+FIU%xhboSa;+`8=4Z}CYW9Z!XcgwJ~Vh z>GrhMfKKk(Sj?6;FrPL1lf%P<$L#C`D&_1Dd8~UY_9UA(YBN7bgh4;8oV!82%r-;_ zTW*hTjoKNtdWKfGyK7LN}>#3=9-6143ZXu+2X9E8_>LaUyzRPzv7wx|1Diark83EYLhCbxwx z-M~;`!Z^qTh@lheamj6RCaG+s`SigvkSC1T?yCR$-~RV|-u$||<-s#8{1g*=N=xkX z)i`B@TFJ$+Ye5YoaR5Of})wC-_V4UILsEAv9FO?R!5nJ_22Z}`|OU-51z zJy(${p=E$ctf_3qZ9;UAZ2JOMW&iS&#~kksCbM-LoB0GKgQPfpjgzv2*1;6NPg*%( z3Ge`%L~eT6aQczbc|8KgZ#aF+=uOA{=Iv)EbnQ}#W`$h!$5J`GYD#IkF$r%9BcLo3 zWy7XYS-zt@VrAba3`fn_usg?hL(_HuhQMsxfW+>)22rEaa%QuPqhcPT&{R0eDbvby zS#xJgBcyoj&!Y5e38?42c<|?sXZ_!YXB@MfU2|nMrK=-^#|EN$L8GuGu~`y=dI@l3 zmo|GCL~mYzrsPBfqBM(n#(gU}@5-l>er<6|s|()XXdS6L2b>@ki&l1bQ`g-H0}yfN zwzoWx6oCGLC$VKUODQH>CPU;b6oaPQv^sytYz2W*&O9hMIIu3rK17eK+c1qvK{-oV$ zomkYZ5=L?_I`TFDq{!~I@7+I}Q&DrQF`?q0_q6~TQ~%xm6P?SfNYW8mKUnKR5u#^I zgd_Ma$1|7Lp5Y!DhC;?uLxeHK7-2ZY99S5X-3@|>b-D<@#9_rZUs~PXsKb2&`s-7H zr24zvLk09*>{zFf0+IOK$9cfcA_Q(4r*%&hlVN;iD`^XYw!W+%G@&O&@Dq?C{k+el zQYKi^okp7aONV^x?D|eQGIeRCTM%Kt9Fjf(Ppu*NuDZy^`7YLTipYv_K+oyLi^$Dp zoDwvHoQCgdGc5=rR0;cOxU!qu5Y^MuuJAFKZy z6eg`n`O(R_1aA~(u>>@}6Fwp=4t(HfaYJH@V|W-L;1(x4$n((xSjnjWo9yO;X#EzQ z;O5N<;8}#WaNtJtZfr8)X1V0TMZrN5Bg`lV=nJgS5xgiDav7sQdGpDFQ@z-lVn_p81wxW9j z+b3CR*Lsb$Dfimdb1Xom!La7q-J(M%8hIyVsz17&F^>Co;NlRha>tJF?(b!e4ObVby9rD(a80KBr2bG{~TMg=GmfL z+8<6*S_rd%Lmf{~wWexVzB`hECFIquhxf#OwNH|l*c6z6w?#NO7r4mKZWhz6BPY)P7BK!+s` zvg~%q@)w~^S%_r-x=J9OWA}0PcUf&Ld$dFiDQqj2uw7r&67^(`Zwl3lpxec;?z<4E zxFLoeHp`Gw7)cwvg-Ep|l4yo@zm7KaYtccdL?CIfWxig+Z_NWk%6w)nlI~l?+)LTa ziO{l_)ZEi)jEm*$>EnME#FPgfEEI@GF_7=0QVf~4$bo8fZ+)@1>l+n)=V^VPWUU~Z z;d}_xfi?+FRG88gTH;CwqVNyto;1Ei*VW|l@tg0LIE8vG#Zai72yQ|Zd{d>b&~2b7 zvd&l^R-E(*gSH;Bj`LPR`0_?sqhDl%Sa32LLz=!Ff<4%*brr9oomn>Gycr)s;qUdEXk}NpW8W)6qeBuS6`RdV&Z$hNn;$j7vj2BTC$en)7 zXiMzk=9VcZshatmn!F5u_*J=FkPW&A59fDb+qDf`R5(vdE}f`dHf!@j3se47wBN;9 zuFX2u!jDoJiiEZ>wb^le^xw2iN7IwU>r7;I$si`Tn0`qH8HmWIbcsO`8XxF7)h6>Y zfx_99aRzw8G?#&fheD_Ifld2ac$et=ndHlik<;mAZpp>pI+LE4z#onTX#p7ibMhzQ zwJu^ViecC&Qma9@@iS!P{P=a7j>s7^NgboIe$Z_{d3M$qYC3RA9C*j7WCD^XyNS@$ zJ1Nq1N7&@}k-2Im@|>$`(a;&^>6CJN{#<=&l@?HhP;qBCwOl*NpgK%#Y?lhpk>Ec# zq-O#8Tx=D&-pav$S$a~`(RK-&O~JX<_pzQlOwoPi*#(-a)rKmWs6IsN^-cp05~AIf z7B@rDp2<3l=ZgC6;;dJmFt#v0xQQek`i}5E`3_l35My$q$gqROPHn*@iIq(#DO|@w zX}F?4I#ao;H~`n#jgPKgy{fxdRma|u>}XM+l+Xh8Q8uzpa#U5R=3W?1zYpHhKoL;N|4_Sg^`w>B}ykaH6KFavZ*6IO5Que^L^lA=_Eox?E zjd1sxwW1{p!1V&)fW_|Y|I813duPM4g$4|KB{G){^vpji-5Bd$g<@Ewz2q^k%=f@{)KK3-+KBwO&sJ!J(wXjT8b_(G`SWsBcDGGx(viXP={#1&?fe>e*9oO(Lk`)b!d3urGK!K&e;q1$^8MP8^w+7j~q*7L)MM(r{Rad4(lp6Cx z^ky9l?aR!t)uK$)%m$WAogCGHYspq{w2Tu3)L;s*`#y_AO1O;bD^dej(3ePnNS4w) zQE-J!EF8~5QYsqp8AXa+PIU?Ye6@#*G!b&V0!|3Ou--}hf#T{TC@B>Qw#KUdLJaid zxAiG{`lxhz`Kq939Jt2dr=qA3e?lyYZ@TT1PKooate#1ev zl(Gvvm&ylZ9MDp|F6tbcz0E>AN7Ym+pJEP~Dj7b6rxYf>z(|h>7wnd$w&8@DaPxv)9pF*DK`SgIwmp$)Nl2f( zV6*yl*KnC&`KWDmr9Sv+2(2jq3d_Yg)6@F_upXW&tU5xk$`q{=pLxh|sI&x8*TbSl zsl|)0SGQMVR<$LEP5kWYk3=h2)3Y2UfB9UnRN*T*DmC@ef>~cMKqRWilN5BX^8!x1 z54$_Nye^#emZArxpgz|G$Mn@lZWItdVAkwSUwugP02aLD!vQ7(ED35s&wK1EJ}*v| zm)`t-dD$D~xUfqlE-jXq|3mZKvf)@CMOrAy7y%NIX5_<-$xZ-y<*c&aGLR5EnB}5C zvgtAG&C6ggP@1%J$jtzmVcDmG*-VEibrJ$y$H3<-Sb+vh4*Y{nk?9I3uX4mJxyv!8RRi)ONs`bA4+2EaeW5Vwik72&)uLB`i=nGiv5NjjS{(nL8SNjn9fQbgbcZ)njDDQLCH6?cGvD za9%*#un=AzzPz#b^Q#J=HF=(91#?nwJR=6G6B4x{RmKhUINCRg)qo9S3bs2?G_H@LHdbFesCGrz?7MNiIwcP_(JFc0*rSUbN zmne0$p}6F6dg$`1%Nfl9i*!DEbi#%VyiO9F8p5ir@?;wSmTG*A2)3s7mM~XcRa(0ZJW^)QgE&nGox)s7TLA zuR{R0vK`q`f{Pdq?XO zmKdK_cc-XybrU400tpc5xc+MNoV9(~G!|q_XLo7)D@o$59JAemZPjO>SY~|mo0cfT za+B1l@>sB$*NDBP`AO8o@R>#Ns-ZdpJ5!g#@)xlP+9;g;&5Kf3>Qm-qgjE%2ko)FF zU0cjiCt67MeUG$w4m1vn+dY-kh?nm{VY)ub8` zN){w;Nz%jyYnCx4J6JMcV0uaLG?!6!*yOb&F5P4s>N*t>H#CgeIt7ozc$WM}XeykhOwACO`zN5WtaFIJK%1Vt`F{WCIQCScZsRj0 zR_S}SPp!OENK?ivOazgvRV;i5G%{A)LlYQK#b$9Vw5$gmR|to!w!+W(&ecO%g?P)meHc_!mIoMZf}ir3ui=jx}>{a);u_8HcPRX+2cG z&N(b7u}RpeFc}L_u2GqC354lQitObbw{JMykecOolL1RSltj1~rz@Z)_cPhv18dEO zjQ0Q}DG$WVAAN@;aoGlb(3X2h*_G{5HYQ@`n|@zjo;>7$ApV0tweIt_`hx)jyf~$~ zyXM*1^Wz`A*I587Aoo^qaQWOey;KVT6D!x%Qx7YJT$S^N zSZ7Psfs-X{ljV9>B#EGWwsvvwN$P<09P z+e)&zOryg%#bf6@NuDAzfZU!XjYINSQ}zJDy^T4BfAv7gDUIuJci0-t>4*70PyPMo3>|JB(R zs+YQK(9a#I~F>dEwqch#k?N{*mW!1;5i z7B>xZK)5hLf)+r8XL7H6FRJIK!l8&YK9Y~6meS?^1`-N)pg$~hoRQcw1IF$;4q8@) ztvaqynx)Xt^w>fP*v6JhN7`9Sh4a$oJdSRU@TH}%e7_-UF$g*h7^Y^22;4(KXxkC9 z*$D~J@ZaqG1@;QcLoIQnuUQjwzxo@sBd8ewNuI2Bb&yor1h|bXI(61)=60DZ)YW6~ zjZ#cR<2|V0SC!eCCMwY2*EEGN(1xvPg~q;|%6tk&QFBZIK-i-4J!pDJ&4&Kwl5ASO zA3B*%kg zmoQA_cf~q0ED+Q>ohPOY7$7y+P=cQi5%a5nCQ%Qr{f@*=${9x_xc;e*$A8iY_LZ1#Qu7L&0MrN zrmPHMR#~|N=?XxgzZ5kne|&X_iJWXoT$pZaIz5-3Q+f?c)i^B$9xV2sgj0OG)RHtf z>_M96ST>Sy$fq}dJUizMB?}sKx+vs$@k+f|Oq%66N?4MsfH)!DK$J^06mwQqbjAub zkl1GDs3O?LATjEu^&Vzcc9NCNr=_bLHFqb8<8N1BGp3k6tf33Wrfw|((p~vA)rFAA zoyKTiyuN!x&B*ENU(u>V;}Y@`Q>0lvdyvz%9ga|^@5>!$OC3+!tyhFISq+G#eR#We z+nCj42Q^M0G;&=2LTTl*LzN@e9lP)jBBuW;>m{iNnBI?iNp-B8-sDE*>})EY5B z2=Y~h5?fhVP*&eC>dS_*SLiO`xkMeAj-tv2kK6bx2cTu;l%7t1{oui_2u;Mh4yA#W zV|6X*%EF0yVrGa?)iA$&v{wQ|8lkUXMkjNqgq%OF>d6KGhL?(Z9E zU>lI0&zIv~9ctSD;p~gW>+P%8KKkWHAG%1Ny?E4*!7&iB_9)j)W1m4w=;BL_dw&0* zaa_-FT>a?hKkvqoy*h@e)#h%S#Ywb$8QnZI>bw_ zX{ew#hG~c!2Ipz~;)~WQA_vibk7ws&q4N8!8Wyan0J|s&svNAa*?7RBaYm*>gh2fv=o1$uh82k}YeN>*Z`06m zv465H-FksxqXkd1tv_UprL#pJUPR*R3~w!S9u5sXKSVnAEJF>)F$SsMs_PycZRuvs z5NVk+re`As!qxDQu8jjm2de-^VaYfymuU<0>2JfSxBPO~Vg{XdfMgQX5Frq?#b3jDi(y%NM6BNK07~BN~dto)hCtPe@sHD@`qxAoxx#* zR<)}i&^u3$WKfQ%dnYRu%+=Gesj5WA%VN3Mky@=y`kb9{cU}z%ZPehJQXuv`2!d|1 zmtaRZC&E#N6Lt}o79AC>SrI(Jv%ascv?2PI^0r_D7!`;ujEfp*BZQLik1BW!l1B5a zNmsc!(d)XBn8|?APdbsx=S>0W_BG;-u5FWE>rDjo&&{X%XYq#&4&?Ks#LhsY7u)Rc z5pD{to({JAb9kfC6PP}T#BrSyUt~O4l}&43C_u6q|C)Sr_?rGv2g^y;`c8DT)kG^e zc|lWd{_}ij`aemf_DIWCe=H|Oxe_NSsU`x>cxyiieFs^SjSD2WWHS5DV7y$iN5E>! z$#6O)A31XXe$)pg;be0Y{`A_%KTRA@GL%Y356-d\n" "Language-Team: Portuguese (Brazil) \n" @@ -17,7 +17,7 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=n > 1;\n" -"X-Generator: Weblate 4.8.1-dev\n" +"X-Generator: Weblate 4.8-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -3156,11 +3156,11 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:545 msgid "Choosing a versioning scheme" -msgstr "Escolhendo um esquema de versionamento" +msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:548 msgid "Standards compliance for interoperability" -msgstr "Conformidade de padrões para interoperabilidade" +msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:550 msgid "" diff --git a/locales/ro/LC_MESSAGES/messages.mo b/locales/ro/LC_MESSAGES/messages.mo new file mode 100644 index 0000000000000000000000000000000000000000..0a3a18e1afc826a59cc09f1f2c6b6b0fb416ec03 GIT binary patch literal 845 zcmcIi&2G~`5MH1c%n76-kT}eRs!`e4DF`AbDTKy>NO5C1DSzU!wWrR4vuoDt(n!7W z44il!BzOv*g>hY}9JnDy`t;4%-|qbE{JORAm62@_?h*O~m++oY+npW@PDOKXeLcip8fEvD_yctm$$Tbs-+nvP4i zF4iqX@=;_`WxQD1B~?~SjCL>Y_Q7Z;oP@z;!=1M0>}zFdG<>lxs1u8))-7@&RS%M- zFeTc-;bP3Ym%6&4V>CQaiB2h@58WeaohYx2$oW{CRq2B&&ckx>um_DhP=i4So`MHH zY?JT7*%>+aJDvx7^mS_snxGH6UaLjQ4k>qg&Kv#$6`E#*ubTnDqjs04c;c`Knif3G?}KXRr{K}x(UXFp1?&J{0rr9#N);qa@J{d;a2Lo>gKvOs;J<+C|Iw3! z;8oycQ02P76Tm)DUw05pM<6?g}skz7eFU;6vca z;8(y9{GG?67|aCXGr_~a`QVA*MLzuskJos-2|R%N?*m^7-UsdnZUqkl9|!ptJk1}? z*RMd;e+ZpXzGJ|1!IMCZdk7SLt_L;#`+WRUp!)kAQ2F+O$VY+4fy#ddcqq66R6qJb z%~KH+-8O)lpIbq-`!P`EKko5M9)AQX--{sff#5Nq%AX3V-E+Xh!OK9kR|YlD*MREp zZ9e{S@Cf2x09F2gIhWD0-{~Rqs0RW#Ek-ZwEE*2f_UnL0!4pC8#r>eh_b{mW-wCSU-vD0>{v1?4e(f=s=H};M zP~{Hy7=jwd>7d#>6FeAv*yC=GUj$X(w?MW3V^Hn=8dUiMrn`1u3F`h)p!nfLAD;;F zFKFYB=6}%R<=`ubzY$csn?a4|4ji?x4 z2Rs%%UIB{kSA!bQJ3!6LJ)q|8VNi721&U8U2dW=m0*?g$6+9Yzai=SH9H{)0z(c@k zpy<#Aik^MoMDQ9=`5yMT6MQrAr$P1S9Ec!14^;nGf~xQJpvGSS#V6N*qU(*|zTmx} z`tzWVe+pDPp93|2Uj{XAP<*=H8mv@_zeTU9- z^ga?)J*R@|=QMBHu(D+L5*t*cp`Y0$4`PM6aQ!M)!_c~-MCsn#V-K0PTmZj z0d58-f}ip6pM#JfIF-p_ih@C~06qY|7Cdr+>sJ=kd~5*F_p8uz{6@!)Qc-v&jOKY-$k35#6(WKj9rLD6}MPwxkn zuk7(gfB$|^e6Sl7Uw+fy|0TFT@dN3+`gJI%_D%uS-wsgyoDFJS^n&8UBDf#;W-tR@ z4PFNR1XO*C&UN)I2gTogpwh1dMW46%`*(noiEjm84Sow$KleG$>A&MaM0ju#cmVi1 zQ2p!&wI0`lkUV$@)cpS&D84*$iL)!u1kWUX2{;kF1x$laf|}>!mO4JV3~VF*R#5dl z0`f2T5B`MUf@O|B20>Ui_z>6u{uC5_!tpZx3h+?yQc(TOdn|#65nl(Y{M*40d<0a#zYMCre*pIb ze+X(^KLclie*)FcnHRWm%?A}<0;=7ML6z?VRbLKN`|H8O!8d}U*Ug~D`yNpF-tW^N z0AEJ@qu_U61RsM(5WnLhH{Xweoy0#4ihutMo(L|v*wG~qir#MpXMxxG_|qQ0=<%x_ zzYUhj_kB?PxabmxeID~3hdo{ms{Sn=-vcfoeiwKa_*0N63MRhJ@%5WQSS)xSI1&6g zcno;trEVTNK$3!mpwjOJ+rXzl<^L53$%9uRe6$XVAgmZ{0~dn(z25CZmw~4fe+$?F zei&4~?|`epcK&b~+yX+f;8)-b@Z26}CvO6$5q}KSJpC9v4g61VK6qN%@l(#@TR_q4 zCh!&D`+WMtKK&D*_~IF`AN&TW_Gb4wzFOz;&ES2cUkxJKf=PYO&Z>gy&x1bx58#Ew z523Piz%^hy_z_U@`8(hV;Cv#IGyS0YRRqrhH-YDZPl1vf69ydJjs{zZF9y~A22gZ= z8axjC88`=g>7bJj=Yo@nZw9A;JHQn91F#c3Y>k_TW#DAuSAeep?+4Y7ANceWvyLuH zz@tfj1e6?q1{D9l_zjLf4h0tzKNUP1EP%?l71TWc$m6kV-FjFK-b(tNp!z*6=hj6T zJc{_$psgqHmBb(O_yzDp;@<()elX-o3Z{xqPIQBZ5x>-95!{dX)!+p129NIsk0gFK_#n6wlzi*G z++oGzwV>wxHc;(<1Uwyl0u-Hp2)-B$N^V^Hf}+PM-~r%SAWI{d4~ic5fd_)01t)_w zP<-(RP~$(k?Ch@af!!E zK+$;(sBv8mz7%{6JQ@51_zLj*;344eK#k*oH@f_@z*)rK3aZ>LP;~h`sQf<3_SC#ZXVAA&mjH=Q2c&3D7riZ9u58iTn-+% z(babeD0;jd)couL=YfY_>FQYp&Lw^$C^|d~P63a&%FW|EQ0prV?hmd3wJwXG=5;5i ze*P5Hc+cA8#DfBe;suZKXb?*~0T3u?aq9n`r01ghObuW{o& z8WcTG@p!RM-wgJX{$5ag`e*Pc@bGJ0yailMybIL$?)T|m_US(cFCl&Lb7yKBgasD2BEx71y&K|lQlsxz_csBSoa0z(C+g-js z@B-r7LGi&sH@I=m0uLvCIe0vH9jJCc2x@$v1qZ=@1eI^$jZS}D2A)d%4sas)X;ACr zr{KBZe}c2YbKl|YtLs74x7p(ZpzePHTm=3ZJP2I4*|onCJdt<>6koj?lsx${I0rmo zi=)Hq!5PFK0vCcm09(M+O_T*M1=XJsunHb~v)gCh0%|_?xdq=9co}#**#1s8p1%b} zkKcmlfQP@!>HCYoyNGWEXMxLab@TQPQ0wL%@DT8upy>D$umha%ZYNLXfYXTgg3A9M z@NDo|Q2Af}9;d%s!IOz!25SDV1kVJY^y&Ww&L@84ZI1sh1+~r|1Vx9Rfa+iSdmR=) z(f1+nG;k;QO7Oejf#7dJjZ;K80+Q2D+Iiavh?XMxi`0L{S5!PkKQ2A&9Z-0keyRp0{R*MUpHXTcCW_8v#a*emCH+Wjo3{?xz;;5R|F|9$WT@JFENc)&;9cn=1Z?=Vp5 z$Ad2ePXS*9>Ks({>-SIg*Xg54y6Jz2gy4AMe*<0yGL+y^!o`U^Cv*K8!skd|OVDpB z@uLaf<@yFoakAh|q-`MRx6VQEH1W-ZvX2jf;>))ZR{6a9f?8YaLCNmF0T&Z`xE=sjf0DR z>${S)*<5Rm_4_Q>QwZhRZ^&v{DZC*FCrT`|`lyU2Gv*PFnF;9BrR ze^2l(!p8~sD8lcTgq`FmSqy#6^&JHLK26v__;=y5vuZhtNK6#0h;(QlEzIFhth zt|t*@aD7IU0bHNBmL5(1ensRg(%wc`%ykODL2-gxnoFF-wA-sk#f%LZ$N`waprxWzM3fv6-ny`hC^XX@MdC*^D5%hc9r%Q%KzvceoN8r=``pe+CDx{sHU--|g>D1aG&y*a_fAh(AlXoPd}P zP6VT03l~oip7aSX65fA3l1Um|?P-xoYc zc&)$xp+x$TT)%wCdN3HK4MC+tVs-w{qDoJ?3j+F^vJxYn;gSVK6S za2Mef+r-MR2XZ_jVHY^@(pJ z?VW@^;_oL6`*gt)(#wS3aoz3HPXI&GUP-u`px-W!pXIupFom#{px=dr?Sz*QzDLk+ zyU+g!*H3Xh7n}n=M7WjkBtgG4VWGcX39j?kZ}IpY?*D*r2jQ!P=yxFZ|1*k!uOfap z;Tt~f5MO>G@lLM$ef-bFk0xA7{A1uF;Gy6=@KfL}LLb*{1pPkb(IS&4FUq9*v-!a? zkDyJSysSFZn<=^L6`67|(^m=e=^^fi#ZtPjlI_d5o2$y1FdYtN^8J}oDxaxVO6go! zt_WW{Y53OE|xjMi zvp!RtV zCG4i-*@0oJE2^ZF&JSkF;Xt7jmaD~Lp;XEAhs%d6YiOW9TdtI{z10e>m4o)FZ5^q$ z_SDoFx}273YvZ54Y)`dM)8+Kk)S0QaGu@@~c5pfE%#OCHL3_uvX=luA4?0@H3(~o4 zf4U;_i4aROl{C?G*qfmnnXp*x&1K7LxE)Mu30IYsZ{_-I-YDm92Au=hT&A<9ECRF? zhkL?urnHWMRMr=mlk8BsG#n08^UMu>?+iMNnPO+pw2m1)VYeG*&{@h1boMN*<|^4# zM2*F64$3|LZhxlSSIQPuNvf}quVnI-RAsoBNfj(Dookk{es9)rp;`)y>Atn;!OWas zZdk}?QaO#JTphA5GKcHeq$@^;B)P->LZ;k8iE?(Rn1d#z!W-baU~V6*#wZ;N^;WaF z3Ke8BFu>gYex}Y1bb8y2o|bT8XR*}T(>|lEXOh3WqHFH_rCs4*HQS$w?oT_Tejg4i z)8E1R&8gGk!sWi~+H57IM&ZXoxHdB!^{X6JHoar2%dbhBTP&{24A(hJg&akq(e(Fc zMOzk0zEH{77@~wyrVQ~It-2m1I#!>X%NfB6a8D^5$Yyf=()s?rf+(pBxlActq4ZFpznW85lGQfkUSCQV zi}WVWnGes0tJY;R>$Omq8xM#m>Wo`o!CcmGB2RBNFRsmOfX%ePX%5N^U!hXVhnFvo z7zy5RLO~h&!*T((V#LK_F5Ab5S-8E`e7|)!k=CCnN-X93hQpzBo+%!JnJHDu=0aBP znf1#V!Q4{cns7-rU)>PQt@dXrl;L8qituq+tH_5ENrF^nD4oqIQW#20dN7f;wxMLG zMMFJ>YB|iZd*g|Qry#N5;woa4ycu-cdu`X1e?&w$OA zBZMzD>fVL4URYlqr{qw&@BHrIoDxIR=#2N7yGXufHe~v$m2__|({O;Bji@KHs^Wbu%K3FJNu5_eSRHWRu2IdIn z<Ak{7j7 zQ^{n^1`G(MD4LnXO$H8E_DLq#P;yn+CeemM(zFt9(m<`z(bZtn>6oYL3qEl&oxoSTYF)Ohg_E&9n_`^V%&BlRWBWZB${^Wq*=YnFl67_g&7 z{aQb*94kE)(C{)9+R0-RvmTrtSnT#K;YqfXP6}VwcG>Dq^4N|t>?sZ-D+UTZtI^*! z%~{?EitY}S3RuI)R&U#8SP)oL(S0YKSYwh5zKoYxEJZ{*U4lBSZxd=hN2V0zReQ^` zNcMFNDJ5pm1QrB#-Bd>Fi)`I7i5JZ49+Q^Fs>gy1%cZ`s0z-|-;BKd}X0;C(bK9AQ zi#6JD??#)D(VcYZW2%fa9m1(nf;>*2G&CK{@I;kSnyp7S`+kd*%#_N$t!&&^D(-ReI%y6OYWy4v9mI*TUS4{+Koz82Wclzn|EmFMQ zIyaq<#OaJ65t$jBTV;n~QZ~9GLzOMKPjgo@g7Y%ND3Shha9&;}`ocn?U-~MXc;3S9 zNr5-;S}GeV!ICulpcNTy?T}MTGU-yDeqgCD!4H&21v~mD)nJ{ryQ!N51%S2E|KjwJ{AR_8__!ReQq) zx%4{7(jUgRX054IisjDM)OChfs zLMu&S2^?&2l3EI-L6w?B>wc2`1^vmC`q0Md99Pc2l)AuKxxvz`?L#3393^V0o?xl% z@qo34Ptn?_FUbV>Q$O{ z+6<8L4VFi{uThg2r#qPzEN6q_*H9!^p%Tf?v*!^jM4mw{$S6gFh$7k%)VU>P+i~)( zlX=vXmExP&qNQ}bsN2aek6o=}>=oLt-;CG(a+#TaPZW)-S}GQhdX4P9d>9`VmYUDo zj``&;J37Ojo^rLn5ccN>U~Ffj6pf8KLXWBSQUpCcV+##ehn|0-xY7Ewn%**dGO9ar z+4=rOtHQehFtNi{FGb}OSg~MUIHSEiTvC7?bxMF5TwpH9&QRhF0kwYp`j!Fg5$!Tf zM9o{=)k?Wm%C(-^vZgW=tiX6>S<{(*Uz#LYP$Eho{G6a(&alMz8fKZ*#u(6_r!*9&6O{i!-=sr8db$H6&u0eHI^W z=$;wInGKLsd34_fE!R_LxKgJPW!qns*A%L`{%|c;LYVF?R5AUHb%PZ?YawROEIO=I z&3|v>2cw%8vq9^_){eM7%LaQ`dE_xk`^$k#Ay4E6PSP7E2lH-cFtWr=@NzK} zpW1XxozC`hB~H|QAy*ibc3rjE5F2Sw<(;*5jMN z!xZ+)TP;60Mov1CqPBSx%XiM0I(2G`6_cw9dFs?Mi_UdU?SAF zKgDW@j9a)tnMG^SaJ-7^8>}8z-lVKwzER<5fFchrGi_^;3M}E7EmO^kg(Nv`xM+&| zeiAsvqv6On4cl7U8=YQm#BXADS1o)~xIUA^?qwol$yF$oPYfZt_k`pMxWaUtm>#zC z!8Ms&5x*89C>yyMG)LLI+a;Lf!uf)m)1*6h{OQSw$_2yVQ5(>yS;@(LbvIq1ib9x< z59DBlY7t{vF0lA0+JqkZo}B)yka60C+Z`MBKp{unA|MXvHCm`}hq>ZJ6t}r%&B|># zx+b#>RC^(3f5w<_E2E>KU=?E3nHS5Weby@TL>h~97oo-m2!BQkhvV+Bw4=R)m9xsm zq~7_dEt6!&@TMgj1+2TH%yu)f+WgicSj8g&Jv|6?77=N2hs=oV)NPz};pJ5XEfUps1QW0rM2_=a44zBeqH`arFrCWf;s!3}i; zF7yXBz9#2OiB^JnkmBJ)snOw$FX9=?3<_^UT;O+T9-{@JZSVzBaekAK&jc5yOBpmV zcISneUME1vW%q{)hz7matr{8BDKoI2jI@tlad=*qp9KxYsE$5?0M{Kh*g%f^c+LW-E zDd5?oW|n~`rs*m+Wz{_QeU(|BCy2B)rbIEzGb7n6%ygu7e;OI-plEs_--X^m&PMX2 zq)S{%;H2O}POn+XAYMhLH!_iA0$s>~*I=i~Gx}gAiBFO=!77qb)9tJx`A)*QNvkNz zTIYOOMOx%kR+8zHtg*q!@!o;pVi<|Q3biLTykY0qM(%JtN-%im*z`FpWfhb+R2NfB zy_leC=^Gdf)Nxs3bqBi1XDT!0P)t<{DLc2Q+i0CZ&s>~Q>oVF4W!n1YAV}1vy579uAo}F0MCXdy{G|N6-4!y6#y2@J^FYdy`yL4!Zgcjj45>vVjz#brs^2x>Gs>}JPHtbVhSAaLHu%G>c*fW}Lffc~)#01Mp2g)d#zWjtZ*{OtJ9_#^ z?YI`Y^2Dpy;o-b=p5x%g!N8*Kt_`E;yoIeyD>)qr@IzIKY41N$CkI?Yoz4q#nGGA_ zP7Em4qE!u>+JLeJy5H(-1Xm~S!9ipUlgODcezn9j_T>uI{+2<@;HI7jLoAO`r_~M5 zRl_+(VQsZOAXX+WM6A>n^g4H3`4aXzY~DKP4C)kfrz4V-EVh)Z&gSgA?79ST))KQJ zp1cOb!7|`C%6G5H4pizb_F^BlU=!zg;ELUaN=^upIsM44?0W=dR*Gv{4k0f+a=~*ai(i3?eAG{tmEDJbg{3LPIkN;CABa+ zE|c42#1$sHH(X4&!h3SqkQcU%wb>|7UeD^5#LY%km$)}trP-|u(wIV6d2tUkq;)Ql zr_@AS>nP&c6DC?(Tg=5dLf zCyBK%X|NO}%)QUnKgtttR-_cMNgFnmXF%Yd3a-*txp3t&wmL0^O=UI_-H^ijqPxAl zc3_y`79D9BceCR4WL#@+uUsxyXnMm`vp$M_Nowx=MDY+BnJ+0uoU<;FtThMz&DKJLVUmX{$_Kz6^(!;CW$uAnC zm<_ZeLD3rWxGs;KAkbAx=+rJ(JYKQdJzfzE;Qt8L3v#E$l;#wsXhoZw7YgC3p;8`wu+MqlpLH4?*XmZOS-PMiLDexkB zwTR;*h;P0@B8%B%1e-4%Y@?h4#F~QYOpYKZt{tQYZvR+%5yNG-)QPl>S+h@Ynm%%2iyuNc&Kp@HqZgDbFV z;RidsFU98)i~FPFwa##bo^Zmhp2*PClP0Xl=n09`((+)oKXnckUTS5bGn}ye{FL*% za#S`SGr2RoxNGi;)Y9`)^XG<(&hK2h`1DK8U)D82$E~TADAqCtSfSJzE?Bi>Nw{q8 z(k@Ptm(E?hTBc5zmw5E6)8@U^blF+>X455zKYP{61*sYJ zd>Riv*A&lSL3nMjX7pw&6PD*}?VxCe%AH}pXwmZQjT-rXZN)OLm=SJEDhjNIsIyNimiC#Vx6*V)BZMaZ$)awM0$B_Ikw z-nXdT&G5ETXlpbG*IPAv{m7<~%^~BVJM?!4k?z>(^?csHsNJi|YajPrt35`iw=(Xn zwZ|DdV@Xubu#6&)kxRp;5G`+I5W7Zh7`Y}?VU3$xJ8F;6Gf`lhDC=#V(`s7-9&z|D zdS#<_m-T|_)wFJ^J;IdkFj8F$LLE2TVh>U0Mx(uEn~SaVRkN+h+OAhRYR#wH{8t*- zlOtQ2wX!3q-A6?`Yfpw_-u|dvi$E*OEettIN8s&npL zd)K8&tx(0SB`1}xg-jx(sAdg_!F>&SA;xMjE`35W1v+mR18P}H=ItR0T~uDgZ5RM& zO!cR+eVz8wOp{)*uxwb=QRmJbayq!zYE*s11@&ef&HP$$qJ~a7SxJ45YXX>Ri8zzM zd(Th3+abXwiM){;_MVp|vD?v+88S(ae4@-POov;Dwnh@2v0jQnw}=x)wm{3Ps9}q! zzg>jm1|6oDgtr^RuG$W0b(7*sr-Nd06MvGRUVJb#O2T#Ox@N*^6wAQ+HY?UsI979Q zJZpSUL-c(7`o(>=uJ#~^H#K88$pUM5qmAcnOaXkcidN=CMb^s3wV$vwn2I;G+Lr`k4 zY4Rn@w}rDty@EBTCmeZ)Ix?PwX5`XA-kOnyW|W>BTHI6%TNo2P%E+#v9;1-S9yN)s zrpu%nIdvPhG%`ghPb4&M5wS+Iv6ecG$RwdMiLwNnYeL4bxvNEj-rPtptVnbi^McwL zO6!d=&4sas6r|~Fr%}Z%*fb1M%E<(o_}zrvnju>=woW~h*nmyJia4s<=^JH@4HQv8H%Ez}hWFoU zx6y(rsEAvnq;7CSmML(JD2W(i_-ZeH>BO=w0p7}*c>PvQg{uEA~(*bka2(?mE^#x^=)z+2$njj*cQ9*)uNG@oQ;#>(nq z57qeEB|3vO%0#n^q6KGUVA_qm9g*YrOte60ao8y9hobU{Nc_NwUXWesgqs$eY(32u zn|VUrk}|P@j%O;I9)W?~c3z{|(Wpm6Ia%nt4!2sXTm{1CsrIKbS+Vt(3*Sifx6)+sSOIHA^tlgct%fwSZy!n ziY*{#*)f=1R+Y(Ytq}=nkxn~J1gRA92k7|Y*qvtln~~^btQV)FjAt|H;z4aU9uSAv z=;0(7Fg^ine38`*LuqoiR-Iu26Wu{q*xVYE$-4EN^#}=C%i=BH(|cf_r`+C5(kk8? zx}_(Ee5VmnvVG5}w_ly_(d2`+a}qRkIbp@!OG|DiAqB(W%@d@lwd{#$9FtSayK!sn z2ZPNm(OPHzoiXKLuA~i0lcuQ|pN1_}BSJZ2K4K-->`t^8Meo&A(x&+)DRE=n38UGy zHL0cBpjG5K9pBrhNkqSDBwjB{=gI4UU=$OuP{vrod#Micv9e4oYaFhIx}TFerR5}9 zqIKi4*pY#$#L-LKwkg`~$RUMT(-gT5LyiM&Zn!YpLR? z$R==`edvay6bmV*3>D?2;#dMoH7nEO^{ixxM4HAMJB?fw^vT&VyL>@tXtHvg&risW zNZsb(rt3I88lpVIXim?%yT~!CnAD0rCGu#-SOKDsIAIrhY80t$jX9(3dabVUGyqHL z0fu`^ZI9Sh&MA#v%F3ydF=@~7)^P*RqfY(SLfQ_GsAFAofWgml4v)j*;w|o@=rzXJ zVe6U9`9&iwBy!M>i4f*~EF~o8$PkNyy}q-ILe)0TNrOfj_gXDoWYxcQt<-q`#h_s& z5lqg!*iaiS&L}^7; zWI|HeDA9_f9@`gf5@Sa%uYDsUZ($-Mzp)nt@tTSp))EGqjD{VKEgYMJXg?=HyIiJ` zBU?!`=SN_Yr>-GHVBeU;)V+LVu1KlP-4kGyFnp7e-bDwkMi+}m*k^2MnF z4?*#&FGp&8D_~SnQ{d(>G->3ST(Z{ux5j~H^N8yuai4(yMyXt8C#ii*B#KS6HcVkq zFy1uU95qoXkd3)&Qd0vxWcbUe+K@;?_*C3GfKBe0ypa53bwU)=^pd=hb~d@EmaW6M zp~hA&ZbwwfUpmfBgvIT(TgJaFNkTVWyIdPhp{LCf9SiqjH9XH+oygG6?Hc+kp)~$j z8oYYsuFvfYC}p$m&a}J>a{Qi-ZxfAMMuN_oKq`a?2MNvR@cT5Iod%WEw6TU95+HVv zByJhcOEZ=USX|BOCVA{90TQdzuMcr2I+&@$Tx#r&_j8VIkvZE6*G5MIjm4Vv1%?m_ z)s}pCcmU!RU`?A|X<87$Cq1Dx6MN09jvH;!ppIkwSvqE8 z*zkFVnmljTdlQJ-1aIX?Q(9yvpD2jF-QYjiV7ZgtLoX(^G&Kd{qlBmb2~!EN@B`lSgLhUr{qenmbQ|G^38M5JS^Vac7?hgUT=QM)H5mp0NoHeVP1JW0-kL@dj& zL-M-Kt1}qwfgaLEyH69R<8H@SKT*|kYN(RYi+QDWp$I#4%n93nbK#O?|4aGG;IM5( z)FTs;J|Y5}__Kqmk+($(R5L8P^G7Fp`a%a%MkWL^=qwfqS6Uv~GU+T^*48~uvKg-S z5bA00lY0n2{6T*IxXSa&KU#En7n`aKk?m~fY{MqEsH}1l^$)25^D*q${U`qPUB}!? z^b%G>8YL3MuU>JQlu9TEH&)~O=Nbx)$xMB&=NiT|-8jFaJK#lia!LKAyOD-5HzUH{ zjKsSkH)0bT4F)tyLqM^?wQTeJb_E#q$&$Zz1>VI}tJO$w;|*$1JZK7d)rl~B_$$Hu z%!T?V26TGG+*wjiG9%0c;~4apiwoL3~ZL|g@y^mBZeMs7@rTQk$l9?)#iH!VyY0o--UfWPre2KHL$-alDW zlUUOuq>Nvdc1#0$p0LlYF}D)sf;Z=7wC3bTod&sW7U{5OA^~~ty?w_ z$OxH;s@!z7GeHoU>Z2YW@&Zuj1RA>a!fbcsqd%c{ro4#aeE&K%tq;m*WM(MzvPbsD zsoEP-rsT%>>twJssE_e_Snrk%$>u74aNriX$|cz4i@L|;Bc9{BC~J}^tMERC#uGrS zDd}AXku0>cX`$!kXx~doKUl|KOx51C_Q>YZ-}w0}McWGh!d2pt-Wx&;^st9V4ra*dm6T3mbz2jPYL+{DmWgM*%dMN;{>e{l?eWw6xdpbis zOFMFN{nSwE4Eu67E6Ll@kHhTJ$avf9huGVjSEkjd)udAy6K=8?GCjQ?UMtdUXJ;@kv@a93 zV1%%wboyd*;-B`?5l19B67N(%9s915lW8({BwQe`99uh$Y$6y7?q(9?v0}wL$>(wg zwY#~&{4!1QFvwf(wsou!<0PWZ9~YSzOG2crc{t?sa?%!Q0;&_MmOSAK0HB}Oes>y(!}(0e55xA3Q( zdb|-{Y-nX`^rkk0b$yVmd>fDUZ;sz{XjV#d+R(;m-$>Gs8rx{|;<5y^cD->Cxe6P0 zIO>dvb;)|fB^ztUvX$uW=!B?xEl{wCpS}J>0ef+1f~Vd&#Trdf|C$ zy<{MP>fGozauBO}Y{KcNSV3&&*kv>Y^);^=4+1DV604_2Y*Krw)ivrOyu(kLToVZF zkTe-^{$cFVL}t<@Ld+Ji(*EGs>70lZJLzNm5FSl6&`%P|EK|gn^M}aJv(pImK5~UH zF5a}~V`8l6CRQRH(PL`jR+!t{i6lHF@ekiRah(3#EbF4nY2sV;!aDg$h z&Z>;@ZFSfl?!>TmH=R!yV3rmB(4wrn-E9lUyfS?{tPn36eK52%+hV8d^yrr4yw(fn zh4JA7y#Ia#hbEqJN0JW*;ONKn5Z517X%t>F20zi?)|!+Kld(c0wnx#r*SQG;ma|d3 zY|DXhN0ytp?CUc|Ktf)b3@{>aWc(=S?0$ zOvpTEW4gJpb;XQhH6Y;lpSRV&Ru?H2eXI_}a%Vh$i82kcw9#vA(~rVs!f}VH`le=Y zV<9<@DKOqCwNroYp@rM1Iu?r%(LF^UeFTr@jCtykN1P`Xa$ZVi;4U{s@Se9f9TSS} z?Ipy92FP32fljI>T>hHRWOo{J$Dh-C9(go)?Ixso?To`-SAIUVk15G^W^d)H+W4(JtQK@o9OG_$Y--8(y&M&&lsX$8js(JSmHp{ShOa12DiyA zFu_KKYg@jtI|4*Hw=t+=wJgh=2b`e|?90fU(%7B&grVxJJ(5Cb%kV7gU~$U! z)2_k$z$FgGoZpVH`Mh29u~o>tnTtzbIB(HiG8 zNlK-uz;i0yda7l|sE%J4*-qMJHL4r6(q9 z+D&g#X%h)zNsv`}d~x^0Jv5R1BJYdN6eOXMn~eT0`T)JBxd%p7z4 zj8i6ZkvZcBj~SI>x!nO5co*4wH2=0Es@)my6Su41O*@gWqDF~b2rj0M++?xNv%y9j zPKMZqvWa?*{*UXt@?W@;n+h4mAIt#zA}0Qmy?J`~_IXUJ#=eiKD_M^cJ&cG)IdxPR z{U28OTqcL-c+H$Zs(bg~8F8jj0tVBTLL9m$G@qSBm)B4uJOSn`8RH9yHP)RtI^HBv z6G;iVi5!VZC$^W^8fybW)TH_M-{lLPOjz>=lcSFc+WvW*uXgUe@L%#JPyZx*;=>a0 zr|ACYtDgU#f7LTgrBVqwjm;H3vd4zr@8M!WyY>I%H$Y|DB{q?W6A6dMntmqGeeo;# zQP8~@hDfS}{rTLsvV9PAFZChEo`=2sT(vx>t^42UyQH4osp)4q+&+-`0&b%eO{1C?ISg4NcWK%cC_(_Q2#G{)RZ;mt+n{GrqZ;wGl0we z0^^fzf9dy4wTPQ-&b_gyEm2a}nr4^B&U;ueCu#bHeFn8YCgg`cW=aiz(T7l}sDT)M zAaRY)^=Z^`%6o!auU^2%QbkFfzQ|uO-h1fmns!oelOvJ(msS6QFRH5PdlFpX3E>CA zo`}6>w0{kI>aISH0p#0%(u`!53JyeP-Lf&$mi{mQ?y9jz?4gX<^soE+D!iwSFddd5 z`6w%xMX5y_Z6a_nx$bLqyR%E}WHccD&$xplX1kd$VS2=0nS3S7u&JBI_mZDwouJ|*rvEMP- zeos&G8;}hT2HRn%U%O(EW}YzZki|)CNpP-&4PT9w`_h{Ve_2)f+H2scr8evtCwWU4 z>&R7S@c~))MP)9Ueo(fit-O2mL2u=6<*T`kUzm-b`g(z%mgQSm8}-Qg-T6Zr75qS+YE^zwJqB%^h4nD_!b;0 z(UFd9%Xh~2`sZN(Ysb~DZkD-$R8r!NN08u(S1r(G7Abj-!UW?bTA;pFpfwoio^ckI_!3nXfo+IsmPZsM@W$^wmw>gwaU;SD5SBN z`5!oQqtKT+57frL2`aCFV)J*FbCH8u+rk;EB!&mu(UchO#r-(i#;y71-mMfCh4Z;q zE{MfX8>o_T(IoSNX@j;sO?%MT>Z&}is38(_nYjlkY0S9w#^qA85_(cE3?)MS9ZkF5 hB%5tpkPfLey(hRsfqL^HkDEN?!oT$Ekm1VP`31dfixU6< literal 0 HcmV?d00001 diff --git a/locales/uk/LC_MESSAGES/messages.mo b/locales/uk/LC_MESSAGES/messages.mo new file mode 100644 index 0000000000000000000000000000000000000000..f930fae16986974a6a2e6c758ce6a6e9a3a60639 GIT binary patch literal 63748 zcmeFa37A}EnfHBE6h%QmMO@HBkS(ODyR#>TK*$1-B*b(Af=jx(ySlqbbyZtSIvrpP zAd8Bi7~yqc5fry~lqHZrNKhPS9B1q1opDCz9mjEI9A_MLKF8779N*vnzMpgIRChJY zT;KOy*LPiCUpe`o^;z!c-k;~x`R?&Yd^Fqj z3;bQM7yLKy4dBMpqUa8=489CJ>hvgjDfnto<(vY(3OpCo{TG9;2Aklq;0M7Y!8-%q z7w}7<%6TLlKN;|w;0rka6nGT)t$=?O@E-&IGT`&i@cWJqcw)d)0_FoQ3%CY6l5#H! zcnSDoj<*LK0agFI12zLrfNIZG0dEZW5%3k9zY`Qa9t0s(^he-g@E73mVD8K)g5=S; z;91~B;Bnv;pss%qJPEuT{4jVJT*z2$p6m5q$3y?b@rS^ZxqfvniYPj|H{kDs8p?kG zb^W-!A1?rxaePt0_kq9W_-o)Rg$%mJ>CeE8;NOFP11{-~qB-E}dz?P!fa>Q3py=?9 zfWrZ60j~m!T)z=~G58Zu35HGZD~$HCtOMfXz|dU@x8y1pJf5qvAy2VM@UJ--*u|1tO)j(-fk1Uzz)*LNH! zex3&&2c8F>0B!}6b3z^{Ps=lV%2yg#2i8+vp6AXw)5Z>@BC^qdn#qZ}V`uD7=azK!Fn zK+)-2p!oeCK+)x8tNi>4p!zizjKO8#o50J!S3NI^-UHsr@kh^d{#&@(aTTa?HU)fJ z!2W>cfI9>30sn*h-w$dWuV3SIx)m%_&)uNteDpf!rxQW(=UhQ*TAe{d?_$H4306Yc!S-=zC5=D=3yd2c|e*s?yzUD&b zk42!4F9F3Dbx`$R1HJ_O7>LM4_kugY?|_)V=&c)~=pJw!RJ&ih(fd6IRC$X)(dn%q ztQ_qCQDM>Nz`5X`gVIkg+7v~ngQtL^+l8Q>e-|kE-VKV5d%!n>?*oqkKOgWwz~2F- zm%ara4gN5k{{{Gcj$e3@)BA_uQ5^pqRJ(r-o(3Md+3U}PCvv2**KfzBfcJn;ft5b!%>Anh_*NW`^n1PA1{~iB{)+QOP<%ZA@w&lrQ0@O5D84xe zYP@~`s-B~1)C<5f!KGjhTm}w-Cxdr`;-4o$mGgTbB#*uet^*eixm;WUiofmx=YUUu zOTh1g=YX#r_VO+RdpN!lTnBy$gq5Rz0b_9W2)qjpf~&x~)`#%Ee`OkyLfCmG96V(0R2GzbFgDUS= zpxX7Ks$V}IT*&chpvrqYxEg#nsP;Y#s{SX#@gIOM$ESfuaK0NZbb?{{H`E~c(-xP2&sPVZHR6QR8)&Gx!s{bzVMd0Vc@s~lh z^8k1Z_%%@VJOzs0-v?FBPeDEZZ=mjfe#6T>8dUp_2Q|(ofNJkNP;^)cs{S>go?9Qz zZv~I$_%iTs;o}i-6UUo&x?gn%DEhw?Mn2R_29W2e-zAt-vWEVBPN_K zZv!%HOl%K`U;>dzCP+WWPDe;DxF0ski8PXqpYz!&cJ=Z+2d zx`3wz>;cuD6#>_PqU(l$+d$R-u7Ldkhd{OG@_@~Nd%#z4{sZ8t;9a2j@ay1m@E^hB z!PBpBx-AFK;&?r%acY9nJ2!yaz|Vkx0{#d1W9UA0rPuq!Zx9C|Fy92lcaL7}ao(Q? zJmMPHTRBkI*N5XB;4+SH2>4a-`sYzTsPWIq-|%Q{czA{u|f1o<8vgZ}$dJ z_TlZI`g=vdTLRt-iaz_n!{C#k`1k4?{r;N+-V^WK}~WR4&IFfhF zQ02dNuj`Rh0xk%+8Wi1oL5`25?V=&KyR8axL4 zHYj=dA*gozBX|P%Yw!(RIN^40&!Uezf3F0`xV{(s#`DoppK!kV!#gOCTBr4}%)NJ>cuXFM!?P?|_TJe+7R^ zxm};3jU2!6v)=zVe$KHc;Oc&j8h)l>xT|90Fg$ z`Q6~l!1sa|(~b{=M{xYZ`~Ccn!Pjy8@1V|~@PL>5x_~|4`J6u=R6Vx@ycg`HzxzRr z^GhFcKAHncE^?sCy%1ak4uh`&?*PSj`$6^pFnBKb+o0Ncw^z~i#dJ*l-&FRJO+HpA(xXAL5+JQ;Clmp9L#b4e(*%_y8(X*Dz9)X%J($RU-g8K z%csF(IsP)Z9{dXUTJWf^`17ZNs(&ST9Qao7<=_CQ{?x&bfIk3-D1Y}?u@4;o)sxVf z<14;KZieG8{uW~epS|nr-v3Yk4(GZ4;%^|M;KAP|cICdWev=#lc;WB4e0~!A4#$sz z=WyTN-$$2&fBXl|XTR}BJ|0g^LSydx;FQbJNl$sZ=Y#*i{cFKfxZeH8*fx&0g5tx? z-*SCg2E{)&gRci~10^R9f#Qclpy)pZejofENY|pT{VDsDcf+4?jpGp-JCEb#e~!-Q zc=&&#cRBtH_#5EQ{=)OI@BT|@!EygzdA(nyP>sXyg7UY%1J2|4D}O_d8T>K01l;(y z9uHp!_H+EF;Bs*J4_tnl;JF-M3BDOT1ilIUH}Iw48~)DwHy4ED(fQyy@VFm3eclGX zk>e}DIp8Nj)%yf^4){y(WN^vfyZyWr)bk$zH-b-rF&O`Y>)}=4DxC*U17G+e{ax@V@J|AMFP#5TIR0fge*RCLe#d}%?v0@24a3Qz}Tm)VVUI;!4s=Y7#xz~R@sN<8s7lLyGc7rN+G57-T z98mYI4%asayciUH-vNrggWuC7f1!%g5>;Fkh^2NeIj=wF>4b3oNU4^;g<;ETZJ z;dm9OcD@DFIBx@0&mbszH$c(#YEaLA0Mz|^L6v(KsP=yvl>B}U6yJOU6dk?;>b~!R zdhTz-`F{eB=J*%j^FY*;{e4OY{M`qh&h}6^o)132`CZ^!*d(+2KM{hfpT|9$@dY`E`M_VZz17eB>z58Kjk?hyNn*gnse{QZw`?V|yuSMN+N zf@|1h`)>zN0GF}d%>Mty*6HtcT>ml``q{d|4dS)z-#YI39Gm_o*e+-L3ESSS+i+ffM)LQXu=BsbQ#gMHSPAF85b#mXKgj+@@E^g4*&bor z&n92;GPax8pZ<3@CvxHBH^95NZw;INP6{X)(%)LPAK9M&hq~zaSLeABS59MVvR%aS zC2U`1e+<;0{2IxW{*DgkR)doF=Yb8of^QvAZ~~j;TC#Z}_iSa8e(7Pmh;1&%zYpr~ z0`~QHA^2OqYjX?oAKu8eC7hcASF*i5+`j;njvQjUm;HYOf0HfwJDzh}Ik+P^0UqGo z`@j#d?O{8c;}5Xu?@a;y$m6YH4tBH27s&n{$HD*P{y)f^{Ap(YD`Ees%(*Mszl!ZQ z*zOK>{U!SkvAsH}8{E#Z{yxM0k>UJX!JT3M5B+j<8TdiAH?zHsYuAPAXL4L%|7!3F zHvL`9HpuoE+jVUBu~oR|v*1K{j@{_XVSi5M+{ZcpXS$gAJA&(TIj*sNBAkB(cpKYd zwj;wif&AV@Y;R@%_t;*_c7SaMTbXT?YqzqU&A$HL#dd`4x$b|QYdvi5=G^&g7qG2o zJC7~Tb}8Ec+xxiZMz;5}ufGj!huLDbKVdtUZ5P{_+>>MbAlo6fZ*p!0nEXA;&YQ#W zCidmeJ|BEhICn?D!GL=1=WNT_e!+GZoBo!t?dF~ru${&JRp5`ogWy}h7|j0N!oh-Y z;;3+~7H~f}&bEx}f5i4Hw!dQ2oaHF^$86cZ^_;(yO@9q=TiEwA8&esCq*BWxwMv)EqC`2yPr+a``b1ilhX{%&CB?QFjr zPW%IS1J_>_js-=IF9G*}pJ4l)aBZ0Vli9u$j-Lci4EtL+ufOvGYJUaWN7>Hj+|R&& zW&3cr{+r;3IetBOIosc`e;l|O{5sojv+ZTm-zPc$ezsq-e>K=-E3*H3T?~K!ne2c^ zhyBIecN1Ik_Y(I1i-U{7KL>AQ`y$(_aL>osPyW8Zxle|JRp9Y#|C4Qi^T&e!&h|Do z{VnI*{cP8;e=Xa5woh}smM!~tF2~z5=e`#%-psi<>^}y+0DMn4KM(v6=l%lxbvP$@ z4d-6V)*a5B0=|juRJM0;{vh};ct7|8RV2*>Z?+FrIR*rL2%U9*>tABk}T~Qn|Ri zuQ)uMD^-T7eer0qQ5Y;V3i)X6+||{}aIMg2@?5D}sn3fis?F1P7Ly_d<3eRH9xT-x zwNihxQRFz@Jkc1bR^qW*_449C?=QYO`LRm^+utYfANjX1%WJc(zb0#zR$3P_~!4vou($495f2(Xm=_q*$q!XpdT6 z8?{Eph5l-@K||_e#evdLX&`P?$4UeFc>R#Io&qm#)*Er7HlcDFRT|KU>y75nP&`A1u~#m146|E0k%-M7d~}FR7Jyi1sx` zigAs4i#0o6EYv5qmn!u}pgA6&F}$-Aj#1q&B0UN%3Pzi`2Vh4XtBMe`T; zEbH!Gx+q$ZU(B|IZE3W4!P1`ji{{U#)k~Hv<%Wfem-a-<7B5)Ty?Dv|?gdfc-;Jv_ ztzWmccWb^>>Fab(3^NM1){~1{)~;H!aczEdurEHNUTieS8r5pK9xqs&UzqPc>&$7l z)#?rI3%pI+&Wfuw7$tqIJHI$Tf60u;8oL^4YrMkraBL!oNWM`WEw?vf;evd3wh>lQ zeqd;rr^kw8%lj5CSlSo&Hpj-QwMMiYSz6w=u~}}Eay#KiL?>SF{88rtySk`f;UyoP7H_K<9U)dMK@&gDoA~#w^QtGAAvGT+`lSLDqLR?1V|1D)kdMejIbf~$Wo&;Dy33O+ADco-YC{a zm-nTraRq9~m71uz*)=Al8LCxBlbbhBY+fI)2s{yPf$*pbamwcPXL5hDuF`8Q>L+T6 zae|^~&q9;&M{^Az&J)=t(R-sNVPdUf&wa)%amCgF4CUS1q3<$QYR<{Dj zs^het0b*!M5W7|!E5iq9{bFTjsaCC+3^Dfg!YD#t+%-^c4i@7p#tMy|s|@B}73cGL zSi!f^6^%<4t2s-FQRcV+r?cBk+iDx%3x{8oSR0xg97WS4PB2THCm6)7{IZq zmT@!A-?sitNv&9`4|l^frn@jJMjDN=`tq)>F>hpE=AZkxtDY}aSN3h+ZjFFgrlU%HPv}$m$B*%l6){1o#fO__%*}lvPsrypn^g5k~M2RyaR;5GE zqJ_#tyaP2|iOa^u^c#Cb<+xvTnmUK1mee~sk0(@*N03nYZRMg|MO;brR|TVh7SwGQ zY~8pa#&;V-vJ<-W<-4SU2D?TY7)eYMMr@!_txe?POT+V3)T9%!kCKYJ^5Iq)8?|_6 zsW@)e&6!ilXjKip zVQd$zlKEn=$Es+ixMc1u_Kkg-D-OY2t7e>U<6r5mV4cdP{#v1iA&Fa@Tg7xx9?on! z6ob{}(W>TPNle4eu>53iTe?r<(tTRj#A?(6JZ16hgd)H5!Hka5?!!U@Gb(6_CCd~{x6ccD;=&J&kf$tlN_t7g-q^CsYW zY>7goP`A2uB|gHo^RM)nigJs)6hJuh4OPoXl^PUp?p+6S_N}g>`B5Z9WSFFeG(fZ( zt9wyz*Om*`ZeUSmp+ZatR;w0Qj27VrcYBbpW~KD*W>L|JyFT=#mZ&)wC1Rh`8;Gd8 z3-O>RllYKBx}r10(pH(dufsIa&eC1qUlb zrQs&lTcUth&S1;b=|UYVTgy5yFh%0QWZjN>6S<&4?%NENOAWk6KVYl|MmUmp6&%!R zk#LUyjtUxbRcyy&RuykzWn!)iJGp~~A;%OjS{#6~r2#!MHc=}LvkGoC8qP-2<*Z2D zI9@4N3j`OdVLgRni@`Nq*2;%=mPuvqq8qhCS$lqofd z>*`1S<_5P&9jz($mkO1xZD^K8lcRy6f>RgY?9o!L1;=tCzK8;93UPI^T(yWes0=tD z(N?;uh`>}@gyWPNQm(YZ_3Xasz)aw7b_rF0A{39%l}yNPwhX340?N{0(_?o_R7?x% zhpX5!xR7XjFdxG8V1$*B2q}b|h0~0WTi19+>yn~+3s*=*SZq|!?NnN#6(_BPVb-+S z<;KLANM(|Op;zJ{)j5G|vLOgt16LmFDW`+Jju*?Er{}Kvk zR>3b=TNx;f)s@~s@8Dj`eIXc$*19{he0j20Pj~E`yN%8h^?0yZQ&oYU(YjS{jn)pSH7vvYVA1<=PFz&c4L#CC2++h=a zVB=Lry7Nrc*5bat(9-S64LBC#)n<862BuuXEYvZCs<%~g!$yqj=JUu_xJ5vVdZw#Y z8y6I%HsYN<(%7f3I^BnE=X^UnkHb2S6tU^k)d`)|g2bfHS=CQKN>XV~yt5w9K}`+R zaHHlV)mo_FxvRu^9DuV%3xha}T^R8NUENE%OoLA2^RB!qV$`Ye{8A%2zf69Pp^MJ9 z{0xd;`Cs(S=gJ_f3LVbskTfUvyP?1w%D(1NCzHrgytgZx?=vgif4i^(GAbB97 zD-nX4ZVo1fa9OUJ87S0ip@swJ^@#C3Nto8ln2;x=&MFZfV=#bOE3hjGDztpzj1H15 zsT7Mif7Xr(8}34xfeI=E2_nIQ?;4{SYt;gl%}i4}A!M-|P++=BGUGBs8`;@qDq{bWN zYSTPwsY_HlDcg(>GESD0yJ#P7BVoB!DBTpVsnQmtgm8sM1hFJJZ44(h=HerN4LKQ{ zc{lgSUsEC$7IpjK$)Z|3T-urPEf)TqcwG_Z9IBD}#UH@qahFZcCZ2#hNaNKSeRC~K zs${^tTpk%BXFU-s#v6qjYfYSc_p8Lta=QEND(=T%Oq4WQvJ|%}BRFuf;F&-GY+3=G zQXH!y9#kH*8i{)n_Ce{SUca7|A|a6vn}{joI7jP83&SNM??3_CY|X^knx3EcIRMEg zG&k=~@~CE^>gsfbA)}7^4w6C=jZ2}s4MkF>%^|=cqY0}_bhu7CBvmLzx?ZOliUg4o zXu%~Kg>MQm)jlfIDQ^XgM^r$PBp+Wus|KrfjR_=o{lKh-cb~q@f3CF31qTGzpcMVb(LGt}2Wwo(5eQD-bb;eP%jHDoPj9%OZ{N z@`nh}834^dREHYl;@UweY@%x_RhQ~SCmNy=58gtr5ohPy0UT1|EOZNPuQ>q|N+*w~ zE)A1Qu8%??#;a2HQ<}kwQf+2juy5>|lcvYgfW?!7QcEbbGQI+NSP#$p`o?VfX+fMD zHT@MVef)MkpD5LL_Mucm!5)JQx!cor&T=bhQo!!3Cr=e?$)2=GqO04^mBx}ol0uoR zaVCk``G!kIP(|b^4OjL>B(WJ_vCKdSj}V&~c^PqFN5=+H9)tO^*<^`#Iy)BZ1;YuW zq!%XQdb2;*_RtxnJOkWz3NvEkl0A7QY2d9&Q}C}!;pGX8y>jVr&(7e)qTUo_Dc<*d zs8eXTP(uDZ+1k&n;1H^fD$>#?$S@%X_`D3CJ7i{|6R*sLEAhux;S(r|uESWwn22Ly z8>z!RGIQdBTej+SbRpuMndwqp(LaU<(^OD4pLqb>^5B*E{q>1@13h0IK-5iD&=De4q%@N; zl>!ezuF@{XyT+_)43tvMCa{Pc+8C`b_mPK`{-_b&iY?5-v~?{XZCJm0?WW$fd8X8& z4f3wH6qVU44%$(guxzJwUO3G9~fw6oD5b~qoVj?GK6Mkmfz z%HeVrjH}#R7=$?3dd6>DK7jFi%Fas18Oy=HL(MYzN=&Rvg3Fqz4YT={*pz^J?$%{2 zDb#Pa0ar*U)lJ_i6z9K~2^GjTo5#wPv|S7qLlktZO^mrB4S5sIF?lAF!F+qqJGVz0 zEXq_=!mekCaWzh6g8$=tq7BM7*SVs^dQhfxX>;&pqYcW4B~qyQ6r_@zX{{b*rf;K- zsDTC>O18Bdl8YM)%7>bOq`OPGEu3A(Zji39ql zBp(?vb69stxJ_Xum->Qs!5Je~x}e#Q2{KQOl(c8%ll25R0L4LqcR9r7d`j0P^QL{4 zw8jU-@8L1yrM|Hy>PIYxROoCrYe^$2t{bbtdx05>B=wD@%=*uxrTFH)R=`gCAbJYK z9fTE_kTemw-L7o6D+)6<5qw0OisNC>H zUPPKcO+aN1c!r6Ail;s0ehdyGJ#Gp@-qw@+Xcu!X=c2sk&Wi;#7KETGY_~o)A73O_ zW4u(ytVp*^TS~!DRfrwx@my}3P!V9M#*P(Y2lcsWhTWF1+IqAnRG~xf<_3(qDn_UVl%2W?j<$etVf$mhB zp$w%_45w{DO@fxnjW#!Ha39Z1Y+eOxO{81$i=XkHMfqngXE9@i|7KG;B!!hqMC+Q5SuYJ&&=F`X6G0pD z&`8#SAa{&I-0LoJ+;>5V-0lb|nwlg~2?{+K?hks*T{<1q$dqHL5GLJ~sJXV%-89O} z4cfWS{2QD zbj9hym1v9g6t;}EX!gg0()N{0W64ZVuD?XiWP-_7gwIx2A@TN@WtjZgtnSYy+aaD8 zBn_6#Bq0{vmvl_8hT^0P#gS}Lb|Mlnp`9(BaT6l`UUEst3v_aoCu9&)r& za)~&bRlz572@ILQcAY;X+t_Xqx(4v!a>-&(+5cWGJ#>MLdYk=;^670Vr3LkUxtSWD zrb3y#7_?jg{z*eYbUji|2Hi}0W1a%A9rcqr#ezz)?()98#I`oTLMoX$U0A=Vck8MR z8`f@Vo!Yo|>#8-Ywi3W4H*HzF`l2msTE~5Tnu_TnMipYYly9-DlI#Wk{18G{E)Hve z3uPRt#A*OXE6gW|+*FGd3Y@ILC|h1`|CHyD&?L zknSuMVp$I;!W3Ccv!ci{Q@dp%ey%YxVLgi)Of?8XUAnsqmrJXJNr9VN608Po$84}D z*6Qt27zsz25)biFfk`m})KNsr6tWaM(Go&LYGfi_M|_x<|3>qY)EHA>EHSXP5}s2` zlaAhc7UeMYO@mk|$T}SxdCZPxsg;GKd`3b`52vMs+AC2Moz_F3)usZh7+Y&1%aY!v zWnYqfWgeKdz|T}Oj4r3AI>VHbCnVEJDXCFqQU|NMvFRF6szXH%Dw*R8josJ9`pV3N z~*)D`(SD8We1#WeK#JMtL1)hSnn{amG8yptV937+1;?nbOG;@rIU!5^oVp!Euxq@JOw5fJCXBu##WL$lo2Wt0VN@NelLxp_szB{XxJQ|u`=AjW$yL-KL$eUI8~_TU#0xvBds&ie3v9av&CMnW zMCfTs&g_F&MJ8|BBul!IDIcF##0T(cBoh`(RnXu}YQk3Il^WbTA@_j%tU6@l({ew; zM19IUis7IQ*#hGex-OZ-2vqU+#nISp#zN#I4B2AK>kim@&GrZCc_#qYQQzHrJ1+`VnT0} zFWN$#WG>HEMw&5^MnyPUwFMhz-nfynMOc;zjnH?q3TlKA+J&E+Xb|(mlw>;G90gb; ztYvcbh%U#EV-YyS4C;rRfk#gHMA6mqN{Qlz4cJ02$cIXZwk9+8tv!?d#E_~u*_(s` zf;SW5B@GP%k25!IrGZxdggJU?5?=19Fs5)f)0CvFa{Uu{zRb9popO^W*V_{Gu3R*A z&RU8}k++VRO06k6LE5Fb<-?jl=HtG^t4`AE(;VtPR^V;pQPa<@9OpIyP~2148piPK zyF|WgF64njIwj=Ax6&jDs}jt}t7LA&_}7Fu1i+HNS_q8ka2OFN=hI-!y=+qAU$HQ^ zYWmwNOlX{h@vs8Cu9bw)&NvGa$$1fTshzHbCg@6zY*d=!?0d7ZP*RM^WattPC2n34 zn|Epa28%-lmQFw{7ZZ7B?ET zBtbhmZIk>Gyw{q+$}GxRt~Sy*mFNyQMI_OfUxSA`&Tk=q=py%l5?@pA6d5C>{!Ora z$r{?WjMh5B@TYrU%+#=w`jQ>f9$u%lHkePJ*c0!{Y==M~5Ha(%i;V^Jo~18Ix>yXuQUe>h*}Bx$Dp9gE|A;th%3Z-C3+bu@a^XTM($~l*YfLa)%t3VQ zA&WWahx`^LE=8FT8Turv)Vn>LYu5CB1>>VrdMAUoM=CosE0E}dwwBIWovc6%t(?(9 zOL_Pj7;m2nPa_}cs320?WsKywXFClK6nBjjNEk?mXbMh4 zrus`2O+AD#pk-_`5tZB%GP&IElWCYj7806@36|f~cPbrz)z%5<{k5Six3{x76lQHg zbV;p1E_4jklBIN^j9GA5B3p{3b6~d%59acm3AeRJiWC&zb$=hDu5(*w#2q{^)QnI&Hj9JX|b*?KErusOIF`J zgAP5@ADpg7#H>i5%=`39TC2DlpL>=kS%dC$PVO)fqjmEvcW3i4dZRcJQDn1{up_ZA zs?$<#3Urid;hxN^PeJjCKCNgY1RBH?eXDG_Pp`fB?)yR6r|-6nkB{fIzLFH7?#lCU zmmiN=GLX02C}wO-iy4b?`WR*&xo2UD@`rZMdBvjTpwnB%CddHt%UtxD83Lb@_78`$B^vGx%^bDzCoW>v4PkXK>dU?W~#sPKMBdkJu{U$tk0 zzug6~xzp>_4>F7ucC;ST`>UL2HGW;WxNDbRC(SjaqiJsgb`>jKJOvfK%=4>NB`ly^ zytZP?K+}#7Xen+Ux#R|?w_fwnJzexH$-;Uu7x1GDJDRPQu^N!Y9m+c4h;YT9mjy!O zcHzNEfC-T-wU(1Vlgo_bg{7St;_Tqax_HV6YZQ%=o2sFgdhM}NefmzeUj9pz52huo z4Z~dSYFT9#u=I%?FQT8lBPHHtO^MOZEMOily}}aqp@wy5dM~^KPLIv@4pHlIzm^-b z)2;DJUMo$jNn@elVUg;#j1axvZf*=}nu!Bb_~EU<#JS`Nr7fk%-9v6oLvHqbd3)9o zeV_VsfiN(&zbQndxT$x2ucaF7t$wZ7ROphMJ4X^lg+VKVYJWN;CCVpJ8i0thN0O>(4XX*xNg}!}r23$mBvyZzr|7$abh zk34IQ3)-F?%5>1x-*ODcFmCT#Q6$IPblxR=QPh<&* z81#kiIJNCX^16>76HF6?2F+bPMzQpeMS0FL*)t2<@7ca<`-GkGd?D2++7677=$>FV z?7kMos#R{-9%&+mYFk%}!+?CVMx!571 zRaD76`JRO1Ep5fzMAEm@+B$P`G$AUAXM6&V| zqvc5R-VJMVq&ARgBVRf&60yj-QH{*=^Z%KFiTZcfq5aSBss zaHC1)CYe6{Jb`sdo=(5LJ)W0O$V#A#=3peU1s~2Q72M)TZc{G?AxhncNa@a0 zJK2)RF_uM&AK20$aSmNND@hZF1iN)lIp!{yRwnM0;_&dFHO3M}F zydG*hIrGf)J2;MWxk}YDAMCc$9dW0&wH2=n0|VD3&$UY)(u@XlDuOC=GS!XY-EE~k z-M!-@WxJPw$-Z-^bFOH#ClZ^O)+2XCqr~B~9gE;<+VvF$_G43#D_xA7bV0Ee)dxyD zU^O3Lw`d9teQ#{ScTBfM(m7FmXC-2xWS*BIMo5m6r_^tPD0@#*nO}6t80W~;X+#Qk zXOvk*>zZXZK?~80&70Pem94q;gNfs?Jl?jWhU(_Ub{2X~j1|s2Y72Z)YveZ8hf9OG z^P0o;+}7&y_^8bn<+S2XGYC1oEx$azbnU7wxs4a))~t#zxM=yt^=Dmn(WbRW>CJ)M zR{XF!Ayc)sJYKhL!-ja%s*P*;&7qB})^9j>)tWV1*7o+USn4qU{~Gg z&P_g{J1Fe2scSm?dg0{fCm){Nr(0s4Jj`}K72ZGjD1|?)zC6seho`Qy|F51rG4@^F!W^kEjl1pm4?ze&{{}EkMF^6cq{3Ds_~8yT;|y39!^9!j3N)=B&TO}J+2TE=5P6{<5dm@_x|k1t4Y?9gHty_rUR3Y#`YkL zFm;o6;Vyb~qmw0O91l?J{Tfe-zRm8)Dtn7 zq#78T#OVL~zx+6P7o5D$SW5cvF|pQ04G0810|@&p5jJ0?zYKCgR(I86QLwl z2NU*=S9JdENZvgSrGA=HALW4q?H=N+zaWXwA4VTYPOhE0S&WUcL|9N|h(OS=E?y|? zsq3XVDShh3j0#0aZbN$M%bv-Hc-Ce38csea&3h0Xlm@+RzdmUiN6KHyLY+M@bzLm2 z^j_};zo%zEiJ29xnZJh!1s|45o7xli$(T6lpyzFBDWbfBfSK?d!#_w2Mx_tXNOXy7 z#+Lp#th(*DDyMFdHo75{bwC;^bfLvg{Ai`@+2kQFkFLs4J#H2*s1SMr6+%Ii2SRrr zgus+<0?>JwCm&CKVv#aai)-|p?bj~3xIcMFi!`3;*Dhtbu}E!dGH6_C*T_TA>lu*u zQZfuIHZ_vcPd$hIo_q*}&8VXR#ltdTsBx$!rbW+lW5@2@>?U7K{fO?hn^3{YXrnh1 zcGfO;pANlLsmjBiJ)zE;jS?67m@PF^CL0QuYV>Fqx?8*fR|d;RAxPr0VX5nA7Q?SD z*a%azszMOb(WV9T*m^rfmo)J5Ms9Y?(ef0;fx49kY14j@Ovd%AVgGNSLS( zqiS2A{4{D%|$`|GG^>+p-C$uhvUUncGJi=&gb8%w70Xa)f?YaH<% zVUA?JXKJs)i-&{gWHqdY+wE1Dc?g4yX|%z`ZrB(~iZLQ`UCp(ZLfRK^@LwFAycaX1 z!BwCXOd(9;-hCR7hN-1#6NH$j?J?~WD@uJy^Co`oW0E9O0uQ3=xGn`GgDEZw=iOdo zgw?di5msrML$DmavwOBv*CF6`U7Fq07iI94`sDSxk$&!JHCxm$^~@;+EvCx6vy^w6 zyaCQajH$iQm!C1sN0YevJS9`0x{(agP>1qxZlhTUOsBiJHlzMfvnQEbk-=HMlL!<-|tcr70!CmSSPAIl-zw-^n%0+v>38Pfhc-LpIVPBG(ty6 zKkSF-X2BB23_D`KyNbaxa>7wDYnIx6b(L|vbw<&$Vf(E0idrZ>xK})FkzDdKtlT7D z4FbD{dPs+G7WG{Z_kc#I&I9t(1dYKf(ju1>34z9yHEc9!-AM_H5vzFb1$wizGA8E$wh$ z=bx*cyjLs-QPUibMo%_WsfJddWb!^OIWTn-q7fPwdM>|6N{@cf35pVz(%)3MpaO!C zFs*_ncG*@cVjm9>FIaZL6q{0F+|ijkQ7%R^(^FIkW4lT*QPY@8Nj%C;(sI*Emew4}Kw3G^Uiw~f& z2>*z9eCj5Inhu!DC%IDehNc1)dRbK43xX5fOgK|qE1g7?9p{fR5 zjdI&|IHC+W$&b<=v~Cj4N>QM9b+48LAc=3XA7q&}&)3<&Lk z$#lD4rc5=mkNU+7QVVEyjgM5k7-_|{-vKt;&QAol{}?b$CUT%OjH0rPrrT7f#uuWZ zlpw$2Pt-qEW58Nn)>-ipX*=z@`lg-ojg4;E=6s)3_2~LI$tB&dLy<1?h&7i|6u^>|Xuml5cr}tL zM9FCk3*n6~>`H2L-HVcDNisxkD$!v?oMPSUXk1{JX!1ic!x}*9lw%pBRn7{Ma~D)n zuKa%T;mYruu(-NY8S18Iw*zB_Spc4T(8tCC-lPY59;&Gw9uHcMo=$5N+wK&nNUY3R z^e0rSrGzrK%Y@Jjq%im{@Vh4nqsdQFnIsS`pkb0>!vfgDHt1xRHT=@fnX7wka5;xq zS)xZgDJpm1z7V=wr&K(ollD__q70R_|D>}VY^bP4wS0jY=kNvYGCngK1}lo+lu`Dc zasp=L5U-VCgHhOjw8gd>NexT88RsFpRS(!ajgQcs2}SRq5DB`|JSZI*G#izqa@R#O zPRoK&aA@?j`3~b@rE0hV5?Q;D3n>G+vaaPUT!P|q#HP)Bn0nGAg$o;{n7W;Ogu%Pn zHKLdVJ4>1JKBN?lDELWcj~Et(8X=2mBjgGkiIC%e1CIxD(pHY2PJW>w*uY?`Oz_Pn zP!y%WN~Y5^9GV?4hoQsd&~yL&>dAX35Wb&LBVDrKF~T>bi((5UFy+G8ObQBERz6IM zK{rKc!6ed3KIXM&uapWBLJjg#)M~f%?y^EEsGo7<nrI#Fhk^>XAZevGz6g)*I?oepTQpR=KvHm_!cS?wCBFdv5hdjG+^)Ku^X0 z^3fDiDYXae3p$L(`e4vJHAw2i^h3nx-jBMWqJyFc1w0yJl(yrg)2?^=(QiV0g-*_I zv3~cv{fvJ4d-|D0VqTFeLk1_Yd#E-HQ)VSJ7#<1|O)`Fad20gEJrMJw;G*%=jTX1s zin{FLKaEqc=B}5`eKYoxb8L(PQ9CpPtufs@H^-2(T%nmE_EFW=g~PM8RCgM8KPvl+ zx=`%JZ;PAIw&`*hi(ebJX7MYOv)rKHA2+6hdBfbxteu>-f8wOi)2s(jEQt(=0i6Fk z1c_vAKLq6wYDP<9AysSB|1&I-#KVV<0+sIlxb;8P&@#kN9;6c?Y;lE^uH1R{KYKp; zX?S9fsrPH>(D^J`lSIPc(k@Iq(KBqLJAsG=gOKr)I-VBIXEkQBks=Tb)v{&gq-5+5 z^_w{nS(wz}|KOuQ6=SJHf40XyDeX~%QuYs9bSZ(fZb(tfYcQVKZ^epp9+H^rG*9t> z_mI4n>ogw7+D}!e!N#-K5YZV|x(_lC=HVKBNQB7_+d!kmEU_{9XiLeuF*OUI`SV9K zifSdS#)wLz^UQ7VxSd7kad_?2)hZy!8>b$bK?}Lo^42iOlq!i9^U&6GKGgcIb_Gu( z^*pf;Axcr*lrFDjmW33eY^qC~7L$h|(#MU;B%`Fw89$oa(Y zzLQi~*Inl2(LCO^<}R%enoC)d_>`DgqJ=?_BeF-Qmdj}{-DTcXvM5LmNwk%Z@`GX$ zS2S)4q)E*_h<}rNJad6CiY{o*n~*JMu|ujz{)*`e3v6%~kS%w)#OrcXOhf81O|eTO znAy>Qc&(zDq(r63^Kf14E|JzbKqPx~dU0kK;Bk3TaBnDvU<5i^7RX(61y5>&T~B+A z{}yfvq>@^rwdcg4$4z2^X!2ee0vHZ2%y_9YQQ)`d|8aG+G6 zNGqGC+@87;Oq6Wzp8X=9NnrK0g=9yY`(%z67HEFvY>i^*(cvkTEDCZ_<4V2h#4y zglQ3kt@DB}P$6o|)yA$ikRGo)XI8=b3+Z%Zw$9Or2KXWlx+P?Cv~r&+F*HdVi zz09f%Q!v3%M5Ad13fhG3-A=pAvxJApI?@$d;Vo;AgyA@-i6z7c-c$n3N|fyZ<1BrP+xhZ&UQ#YCf)%9GnlM zr25ueTTRr+(S!i%TZRj#F|{euY(uy|*g&I%#$RUC)KZWwv7^~xxJ?c+i}1ujX$z?P z7J7My^@lZjGU^=sE%eK^fcXFl3 z+`4IUD0!#+S$r-d8!MScXtj=x2GgtDqs%mRK@?ToYT|D06$hB%r+K!m%O+w{jyFuB zMXNR!Rwsju9694@MI`N#r#JgW9!*!dWmYB4{y^(?$-Ekb3Qxb+flATf$f9bUQXq}^ zMNUfa95UXlc*GJ=8aM9IxRaAb_-08-h>aL!`5FI>6$Qwyac)MKjWJbTVjWD>EWxUi zrZFrM$<1skoOg!0#@L!+nb8-iOO@i9d}aaatG;J|`$V_Qr?5Cc;;Ld{R}>e#uKtDu zq*=4zd{eLnVV~2&ybL(d97TV~gwIwVW)-w`3tHbIF7n_}6+FZyZ9s`8d6@z1+;k+k zL+oeTSN%znoWW3=@G%1NDH%CC{0;#_#AJa z72`{1oLLq@Mx~+CdzQ>Nqa0!TJQ6s$hMTO9 zt;kr=OEkFI0)~UyB=M9d`+zB;EDQKy2ZoW6$LYIA8b+;Dg{sWsAY%*p267>t!@`m2 zSxQs-h_tH4JxNB(%XjPL;$>Y?$r4oc+0B>yX&9TLZFy=(=1jYv{D_-aL|I&#Y7GuV z4}6K*iRln?+SH+emEjdjSkBprBdr&_8!c4fQrqaT0-^0gFqQ^zGkHk-D&wkg)%r0X z@Q|p!gO0gsb(6|M6dTzjU4Vrdla4>B722QXo2dFZh zKK^1e%4KBQlslEmQW_7t^JetkYy2y94JV>GrHM7Vni;y^H2dwDmSl{Dcfxs|C#lln z#$*;oIxl$8#{4d6ozlV5*iRljQzM$CLtE_kET%Jz{X4lywCf24ipZ@`)@ucM_|dA# zy&{UyUfS6VN+$j79+5fGwDRz@@8qOYwI+lT;f&K4OpoOsGQvxBI6BuuW)mIiY+FpP z5%35?av&vQ(NM}cZC~24TtHZm2eEIM`Mn*v<~El5t-53hT8FbJ@D68D;-2ttSK>3y zp~PpL%YL!P=i^~jJOI(u8ztQ=W=5~1G;gKKB+$f)5@r{qeaSbsgR(T4!V@d52;;KGN=!^g2vG3 zpoY zA#yz3-aHtuX#3(&XebE=cTeCQNko#Iww#3Xx0F&_0>QYJ0lbD*xDqhcV}z6m()&B9 zse~`(rHLck=Tww5cWrbN5jNzpoFpeb##F>FRo^n|rZrt6I~Pd%QDG)jN@_zQeySk- zMoGu-9}$m9{Ye`guz5YBmaSBlwp6M>?t!jN-DWi-Oldxr9(7PY zXU+Jk6z;*$$WhVIamHLlhJp(0Jz2)V#f{~OiYsT;lXF#%rJA&d%g-m8CU1@DUXsW$ z${J0ep@Mlkk@d^fwdAczym6UwO=j%@59jy~pDkz#iv>h98Ljq|=>Za8!Hm!x(R1$9 z?NitBsWHOW{{$40twv8|-ezaqf)4Kv~nucGZ%YxadO zf1$yyhBqss){+4GViirD9+|a$#47!;Quun+bGYBWWc3{G=c`tl`M1U2MkaNfB@}In z)BDfxxEh0jHTNz4Q$!b{5v7i#<+LcL^;VA}BIh>wU4agK6pLy<1+!)*L|iGFB=>Qp zgKkwuo_I!8JEw#J*Z4{FC8H<{_$SQShCHg>>^^g5&p9KV%jyG z8MUN%eE10-F{b7CxfEG&Fg779^ z_L{uchl*CoZ3~**to1bEOu7+1_@#9Wk`1G?8${)C8LnCEA*xNI)45dAQyE?2ZH{L7 zP?#10KlNc7TU%`A%$JqRX~xwo?zH#w)1P|j_$jd<-_y!Ty)yOD3#IP%JcpP|#&G63 zSTw()$qpnicdzZm0+?i4d!O~^$S{=dS%jhNBtJymSQH>SUDhf5WJ zrU6mns>lsZ!)$sF8+)JyE4Uw-{0vO;+bw+5%(SZ+KGd;I{dz!4b(k@m3N%k@p9WKM zA=kuKJj*3?lWq3iSGdW-o5InKQT4&Ft^oOJkJ?Q+g#a&G4z*acnO&5?3=UZz3cxEs zv2cS~R{kejj=j9qG@==ih!nC6HA=1RHFC}6E4X5DeTy$ul}ZZXOXf8-FB8&RcYVk> z(Bgc5*W6pqvtc47u}R8|%L~+RF&thVPmg^PPr~)GY-($bDDxZEaun}}OkdJ#d-aHR zTjvw=4+r3)>BneI9{wMwl1|6~9+eiAlmQ5x6LN00-;dY4VXt;Ya+sLYSwLt0?#7IVEP#Fd89-nRpZ3CK*?x zZpr5}Blhf!L>QhK3`%vl3kMea~eW=L;bu6ji=IrBx zU5$qPP+!q4PZED$F})0!bOQ=Tr~EzpYap8(7v65UFG#IPzNq6``r(sP<(~XRQ}Us| z)`j##f2~u=hyGe;{6l}O*i~^jIgII_`%^A$k}*zlUC>#yR@xxsQd^y)x6*T3R)d?- z>RggAH7R3(*L{H;fnV>3KbXbje&BJ&Sn`-vHBHKcvbfp!Rvi`pVvO$)2S|rsOL&lE4O&?Y?nDZ81&Tr>@^2zi zYaP8bkY2IA0}5y%s)AM7Y`x8*{We$anuLrJ5iQ9y3*)YwhQjj^q7${~0F;EvKa#tb zaV%80yG`!jigr^WfMzCP%)Y(&(%OX>}|lIY}Wok zDp+5`t@G*fTd|6tc1|{CG_%Oy#|C4eG@lCVBHzY}3RHthZBzwiZ@UPHVE?OXBSjvtdE8YS0j0lX1y3 ztSW{>$Jo1UYL>K{w>vY7EU!QmzJ*~EgGzg}-)#MXZ1PdPWB52$wsm(_(Q1z%JX#A( zN#jh~X1r@*zE|+GMLlC`{CKext#hWM6C6nKwB}JnXy*qddT*4z2?C-;ZZMIl!l1^u z!+Zr_u&WRYR!=;6E0wyj=Ne*hIh2vUg0VzVew#wWf&L>EY|EC+Md>V5YGSLf#F{X0 zsV1aX^g4uKRA6uVyK1FcD4v8@kibOFdM}O&hZd*NB5PZs8l;jD6sM6IU{8rxq=?<{ z*qi$unyrM#?2PXVx*)ct*2Pqb%h{UvG1b`89MS>&#Od^JYIa&(BRacKJY)=QZFJ+@ zk}F2WWQ|Uvg1w%{B*?e$3^cZ%1xRPc+hYx_v_o@F@oIXaB^YIPB^*+tH^*~ua4f={ z1MA!>UYDtCPckIhT35wARIFx;lcaW##*nN@2G+d;TY1lLz}S+xkc{%ViI90xVQ{An zq;*r$=}99kjTD1O`=|4+K?|i*9sc7Y8BaBR6%G%LN2O@+!;Dt7F>xe$ot&3EM;dgqJ4zJUc})GqOlze{sS6<_wnAH4_YpfNtGP55U}#dJ$e(WA`S^9x#49tLB)qhTPBYAmEeRMLqLq=(gMu zy*DC@CjpXjkN`qj%NpU=&{C0F4Adc9q_+}Om`{^)@*3Oixukk8=cN7vPb(#8>w&|w z=CY-UL5)KyUe?NBHKfFSts~Nup?-0uArAv65a77JjAP&798tHG73vE-C-5oa`S zEbW0wfbSqbwN4upI7n9Kb_}d~6<$r^W;6V%c*ZP;E}?_&;+nI9+_Ln|Ve@cXY!cR3 z&iP6 z3bw8Bl;pUBZ#I?&v}c{N^Tk0ciBi^;8>J_qGHOg^Kbx6x(@zwzS7U5Lp&-CWP0Jbl zXN=WURi>AwUwkTuwj*rD;DIX=sa8hNeVj19?z5R$OSqm$47QQJmuE&PHmV}0f=@M# znMhT9ozX~kAp~AYwp-kT5ZN*VM(Q(85{i}aW^7FpXn^Hd5qV?l%u@&u+e&Bs#pn-w>~)-r}*#Zkk1Wl;ZHRB#hw4h_n|m_fYQ zA$pW+BnL3KzZ}}fcy(HN1=$3f36%4nXc?}gi>EA6ZB$e#QcjO&-n#XOUewXLeR)Wt z5|jw}54Cez#Oa!5zq_v<3)$KsVpTe_hhjV_ph2Rx^jA?xzs&Z*U)Zz5FT6#QW;(?T zjG=s=13qD#c~exfAzw@kp{mm#zk-Vzw3&sGNJ$3|Ll^zL=TFQXO`5-hn`V9bzPD$z+Lf`kiQTnGxJ1 zLS<{Lc>?*$d^MU0J99{q$ffn|Xekf>9gUB-4TuCVq*P5ubI~GAu}SakgHlZSp^qgIQ+w!xO=E~qRNe8} zjtZJqnXR-Yd!i{Zb3tP`&p12NDJmmgvPGFxE@4O8nkSb8JajubPuqgi|7FBdv+|;W zB+%@z+Rhof+t(0cE!69*B}5lzN5d_lL^_j4krB|#K6_|Rs`R);j)4unad}$2!j96>ZQ)8Ts8kNrviU-}PtT@A?%wzbjACXYBV^^Wsy<}koGFyIH#bYqPWRT7hC$#w zct~tY2kShQBAT&$$wms2`|w!`m3kqH%wed{xb+cN0w@L4fjHVamqb)D zYT`k)-7Jg^Erpx8r$ogmAx0Kwr1=FZrgkTi`}z>r$d6Irr-?8N@Q1~ePv`2-Fqh71 z(d50Z`x!!45T-*rzr7(XmCXJj8&3W-L1%4ZOgxmDO5!@tW|(W0MrX;_(v$Te^stuw z=mE(z)qag)^wy5Cn!9Uc(5TAeFhN7v-h2izyy~}Tha(ruDcvyo4LT%w1c2_xL5DUB~+g#1}>4R7`_O$Gb|jFZ|PY!<1Uy; z;S*+>kvmBCb^7<|De8coY<;q=ug~?AQn2m%tRux{e}Sl-HkLnD+sqk|DzluE)Ur4X z3-7_9=rf%ZVrP_{n_0=H$)DWwR&b(OVrJFsv)unT47le{C{xDIr=qn6>^Y1`$Y#h= zI-|CJoSjjZpCIuj*)M5mV+Ji1NrMq-A1S4vfjULn;gt>fG-2K$UHWHE-!v(rX3drd zWjaX7E%!W$TP#Ly>r98+?c+O(tl z92+M#l=^Fh+Qd0}J43n&|3iLcLMqGRDbJa7+q~7*bf&)lmbDqvik*vJY5h{O=wApk z+`c%|z(0vr;w_9jV7DZaf12f@PC-)(MnjPWUvQR%qI8{cvDJvPl)w3zRx!@<+@zd8 zTkk1)%Oc!LFCp5ej79gwgnnUIVxO1@4&u}GG^`KKk~L$Br2xbwB70&514BUsv8{uL7b?DcQ;G5qJO+}ojzW=vXAAIp@8WY zx6FrZ`N%H>n|@`eRxIx3Q^&JE+pL7Isb+3+J#Lkm)VRjn?_Ubb>uZ`ySj=$0vng%} z$5Swh^jVT%boX2Ien{LaF$*+zxnn4N7@jbxN6Ibtgt$m{lU7`?b?atnEghStw()A| ziI!>;v*;G|w|vaQWCAtbW>&Q9O1~l6w`!nK+F9&v@bRnI_kEJK_03{^g|=XK@spZ- z8&jXP^xGs0SPvNt&HiFK3+kIl-i}d~Ck;gRpx_P>aMA6{%Fq zrkRDa0F7g_wU`VqhI~dml?1(>{%*6cnFTqh3h0kou@OL(Zt7j%%kbSR>#VsHeI~^9 zlky`pUG6Wd(z)1ab+z9UvNsAMEygqbLs#1DjcT^&&GKuMtQWl@mWq%PRaX4=Bo*>B z{U&iw)7(ABO{cxj6j|F`W{b#lm)WA=^r~75LrjNCU0=hVy9PAOGqfH^-~rA$8p%jN zDp}&>vr%fP+&1~3dsMPW)cUDE2F~h-etutjtY}#lw-M>^y8jc(*Mx#4B51Y+)i$g$ zB-0$XlmqmQu|DUTRh0=o>73Qm(y}fTg>cPe%Je~Rr7$+2&%U?Bk1x{useGyGI_l!W zFkdy!+@cb9`pM>4t1y}$IM;*>4KrSm%IVeSJ}%_LpUM7lgC( zGk47I&L^iAWKJ*0bAlbXH{+I;$lsowYGiihGdbkMIhF-f(0Utd>W-zcBWZm{vNUCVru+m88qrM~`M87LL~f$EsvK;UE1?N{jD zV6i?>E7@g#bb_CJEe+WI^v}ve6#HR#)RWCLC^%y-HTi8doRSXTyv!wTGaMei(`p|q zgntyD5e#vOvKl3Um9?eR6$qgFu@gQhWhNQ>dltO_q@c=HV@p z#Gh51tMv?fW4k`@6;I0Py<1tX^v@6CzU3vrl%I$ zReVaYjC!GQZ3=~Z__$_Y-;UzMc(pd@TvjgOM%0~eN0IxozFya3oRS{$Gfpmm*)t2< z@7ca<`-Gj*j|p>Jr zP!SAZu2HR)>n-IM)Rdg$%L}`A_ZKRIUFmJ6F)`TizVWA$>sXR_Y@%FfRtC_z#6PY5 zdUI^7T9ZE!_2J6w>{tuqvZKg%;=6RmDf*B5c~M$ZhFKX1igm%6QKEVB6Qkv*&>So^ ztZR|lN`EVb#=uC_j}KXm`kSTlp#NWOHlqIBwP>JZC;btAgJZA|;c||ZBE6(rF7+EW z8>MnRf`7QduvsfYg-D;ii6BulVwH>xM`3|-y;vT~+3%eU{-4gSH8)`x2Ky)#llEsy za{^AW6NHkLbZt{5rHo!;ci9Q|*=eB#G;RBVWb$wvW4_pVCU>7tE9gBBEXvvbO;tWx zRYe?EIN6HZFwdf*at=|4EP~j}w@2XQBWA(z?RbGE7Q`ITuP)v1rzb@wl5THa9rqeMrI8r4Em}jSYA@6KzUuA4*NP zz<-wjKn3i`4$RB62yFOkH5pG0?qfMnbFBMhA=Dx;BX+}IF@BObjJ%m6VIwe{fML^y zT8tKqv-8py2Lto6hqRow(4k4{><6(W;gd~*XB#NvW!}9oZEF$5!05b&xwG@|WXp03 z`WZ^vV{)PBeK>CgQ#LDZ%4RuNS|#46+?K%iOsUo@c`^~?by_=nB-@I;ylAeq<}gbi zVH9@)JYs<+6+1zFIj*?XpVV=fSfQlCWEh_ z(7g9Rlmzd1d4tge*|Bi%FxCVm$r<1|ltgvsL!lO literal 0 HcmV?d00001 diff --git a/locales/uk/LC_MESSAGES/messages.po b/locales/uk/LC_MESSAGES/messages.po index 5f9e45967..d77f6bc14 100644 --- a/locales/uk/LC_MESSAGES/messages.po +++ b/locales/uk/LC_MESSAGES/messages.po @@ -11,7 +11,7 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-09-05 14:34+0000\n" +"PO-Revision-Date: 2021-09-01 20:29+0000\n" "Last-Translator: Sviatoslav Sydorenko \n" "Language-Team: Ukrainian \n" @@ -89,7 +89,7 @@ msgstr "" #: ../source/contribute.rst:38 ../source/tutorials/index.rst:2 msgid "Tutorials" -msgstr "Навчальні інструкції" +msgstr "Туторіали" #: ../source/contribute.rst:40 msgid "" @@ -375,7 +375,7 @@ msgstr "Домовленості й механіка" #: ../source/contribute.rst:192 msgid "**Write to the reader**" -msgstr "**Звертайтеся до читачів**" +msgstr "**Пишіть читачеві**" #: ../source/contribute.rst:187 msgid "" @@ -383,7 +383,7 @@ msgid "" "use the imperative mood." msgstr "" "Коли ви даєте рекомендації або вказуєте необхідні кроки, звертайтеся до " -"читачів на *ви* або використовуйте наказовий спосіб." +"читача як *ви* або використовуйте наказовий спосіб." #: ../source/contribute.rst:0 msgid "Wrong: To install it, the user runs…" @@ -1501,7 +1501,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:43 msgid "Public dataset" -msgstr "Публічний набір даних" +msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:45 msgid "" @@ -1512,7 +1512,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:50 msgid "Getting set up" -msgstr "Налаштування" +msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:52 msgid "" @@ -1526,7 +1526,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:58 msgid "Navigate to the `BigQuery web UI`_." -msgstr "Перейдіть до `веб-інтерфейсу BigQuery `_." +msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:59 msgid "Create a new project." @@ -1537,8 +1537,6 @@ msgid "" "Enable the `BigQuery API `__." msgstr "" -"Увімкніть `BigQuery API `__." #: ../source/guides/analyzing-pypi-package-downloads.rst:63 msgid "" diff --git a/locales/zh_Hans/LC_MESSAGES/messages.mo b/locales/zh_Hans/LC_MESSAGES/messages.mo new file mode 100644 index 0000000000000000000000000000000000000000..a3d93c5db85ccaf3e865a8a6aa196d95de131bc1 GIT binary patch literal 100727 zcmcef37A|}weL?WD&UB-2wDVzB&2%I)Px~qAd!TGbOIt`s=B+nyGVCeQ&pX$QISFB z$pIA*5fzXtAc%s149;Gh6|dvHj_DAb(Cc)a-|xTH-ltA?8WQe%-|H_Y|1<2f&mPuZ zYwfkx-u0vB@A1xrzt*QD$$sE9`y|O;7Rwj_B5m;>j4GsE?UfTw`UuLSN5o)+%E zG2mOkr*i+2@cgX--xKi0fFBKbU%)R0{8qsK3b-TS?*sl5RQdL5ciaculk1lSoB`_l zhX!m3*b#6(sB#|`aCyMv!RK)Qbzn2N34A_yHMl=`EBH3>%V1|ylAO}v`MkX|Nq)=q zd%+XI%jlE?NVk1{lKdFla{+D1{T<-9x!$WQNtS{?0w=%&4@;6Ob$?Nk+z);LJQpk+ zo+N$XcJLqIu}37y`@oe)Qg-rt6#NZ%(BdRHhx;#Fk|d{ceI>Yt>!&VDl7E5S;A@1- zlVlOkZvoeG{pc~23+!5vBos9{8C3tj16&PW51s-3H%OMrX)BXt8+a#p9r;}S>LmFE z*N3h0d=BQN7jS(Hcqe!=coewLao#`cz~AUTsP=y~g?t0J0VJ#Bo1os`kHWniYz?>y z{4cHt!F|Bx$0y0Y;A=qjPYqQ4&I3gkKL$mgkAU9?e-Az#{OUS?{%uh2{U`WR@Ueh< zcGKou9{}zNo(<~x#o)`p>p^|@0Z`-T`{2poW8gmEvFnrM#o#HR##KGwJHQ;*cYx0Z z9}f6a@IbB~178KcU;}*!E&#s^t_Jr94?4l?vjo)pYr^#@;J3IggL-e#iQaz4gP-HN z1U?O%P2=c!D>xfm20j%W1xLU-_!98v;AZe|;5lIRB(CY_KY?nGVJfSB+YG9HXMxWH zuLDm5KMJay4}6`cn;md2C_Zu&2BuQ;70I5@L}*1;3Wd2YeL#GI#-aXOHJ|M6ZAU)nJ|bCxHin zUjsY9KY*(5Oa|YX)V~e9f$KX;UccA$Q+Muf1eNZm14%*`B)hkGJ zpvLQWL6!gK;1KWq4phBfe|nO<5-fv!TI1@!DGOG2M++B_a^!pYzIXzCxiS;mYw1C{4Dr%uD=gHhwuLcd@8x^4jx*GVU+a?S^-O0p6xgP#H40nRzg%lRqr!(9IWJQh6n>?C;$_)U-^ zCMTTZbo4N|C)e9SwbNtZbHRUr?clR{N%cJn)OS~bD);NbXMm-E!{PZD_$=<94?+^j z72pBjGtPB-oCWU3^#V|IwgFWB=Yh)a?V!qWHF!r;lH3HUT~9vWpMMZkyWb4n3*H5G zf~Q^Jcq907u73#XyMGSXFT0TU$ZswvK5^7V-rj4#gShSo-ws{^?hU^3VyD;H;7hq) z0X_pPg3koYpz1jWJ|8?A)OX(ricUTXE&{&{svY;d#QEf5pz7Zb9s-^N>iwHRz5f9C zH1G%Dp5RZwr-F}yD)+BJ(dFMkjguE%>U{GsFvs<4!7BI$Q0adI{tWyFI2-)QWzaDA z%*(wWH-XROx(Xf$o&hS~4}g0AAyDP}9;k8qOHl3cFHrRM(zn8wz+1o(aQ@qzZ`}wU z%k@9NCE&`p`*^q%ypHR;z;)n>WO5()VXzMzxB`AhKYaz9$MvjtL7QL!TnrxbZu)`e z7lNm9{kAKU8-;*RC0WSgn1|D_|ZAgCe z-|OwN>RRugTfq18{2{OcZh9Ye0DlNVlF32WB?&_{xfvV<4<)hM;Tll&I^+XhzSF_E zTu*>%-Oce4ZH`;gAanw0)Gvbz`ug0fQ1{OwN}=l)B0=mr-FY47l8i+7lQL|^YMKesB!WRQ2AT~ehRz|+yIW=?t1ALK=Fx} ze3W*j+^fJ>bKQN1*YjHNWbVKCW3GQyKkoGUHSklU`!jekc=w%2@+ENTT}iT@^w0eS zeZ_U(-Hu-XU&r;#d*FTGxgf75``+vH@OAJ(uDd=-UBSPC6eT&IK|m3bh4(vO`xPkq z`p^STSBLNtO`Y5UJ`BF@Q%Q0u*!pSD?*Z_uT%Yk7<_h4d&-(ozf^2loLV1~rZ+K#h+_!54tbf8hP|T2S?x%yaGG}JOF&b5BoWqL2a4V<169te!~Giq-U>dI`*(tReow&91^jxz9|W8T_}hSg3;6VH{{B7z_X~Ik zsPeT3>;l#PM+ZC>d@9%L1HLBU>jD-)m8&mcCE)3x`u|*T4tND9di*pf{_!w)KKMKE zfF|f}!t;60cKAHkH-hcpX*-+_uYc6}^%uZ@@!r;7AS;ExbbV+3ugHt*bHKNNW4}(4 z+rhtrW$@qz@Puw`PHG^T+H=SQ1pEscr^G9a5MNFa1prrFSG%85qJULdHrAA z9`nfGeBSkyzx(^Y13y8!e}YGXcm2c1)1Sakas7{Q{lGt6ANo9a9QWtZNVC9m!Iy%! z1^jnV?e~;H$X)0$2in399_ZH#Hf3z8?G>*QbJ_hnA-_89(R%pU-s{ zsPwDD^=rY`b3F`-Z+rz*IUWY}-Cu$Gfqw^I4!#WKN9pH+%I^wL`F#k~dmjgt?yI2q zz@y+R!GD2D_sTt*Os}5l&j$P&cnH_u2Umhk&-Cvd3yQB7!gU?ImFo+^+ratHa(o0- zzVCi^lgXKDL4EHJ;HBUxOp5j1FTr)-RnKiQd&{ptNIw~So~Pf0u|xTM8&tV}2yO*; zfTFwN^P9~6axu6U*AIea>i-aU7uOvq|9bxypzN%_1I2e%zPQQkO6$N?Twet)=J|F| zbTRX#O*W1X15e@lgJ3_{^fKs)bc3M2ckaGT$>reXpy>IPFK@E>&bi=iq&u3#;t&75 zf0Nl~KKP0zvlBn>m0q7C1Fiz!Pr8%94}yOK)xYn{HJSeSaWKbq{{c-&FL*wv_V{JM z{{hv%Pn+R%^Kx)L*N1|l=Uz~J@y*~Xz_)>--`l|hz^{QTz~6$fhGgM^Uaz^Ya(ewd zD7riIARni{3iv;u%CX16&PhXtl z_rD9OeSQ?KU!3>*`-4jNDp38|36{aD!5hInn!UYl2Gy@$1z!!G(c<5K2t1SPb*)~X zhe4I&QBd{&EvS0!-R5-rLQw6s0-ObI0G0mD;4{GUz~_ONflBwjfVY6+^Y?&iht_s4 z_XbdOPy%OyZvbBcUJokY`#`ntXTd9Jm#>41xE}2E@7(~358Mjg0p1O&{Wr~Zybe@; z{{bEV{u)%ho;wdDzggh3xn6=$dog%CsD2&<-wD12R5|ut;QaOgP;}A-D&N(h=)MFh z-Ra@^SplyI_#yBJp5F_q{C@%Gfb$l5d-Q^Nt}g&pj=R8v!LNeK_YVR828ypfrOVsp z>7dH-d{F6UgR{Zo!2`iJf})G-K;`pvoGKp&pAEKwp8;P7{sB}!9}n@X-%bW47Y0Ge znRCMRHK5w>6QI(46Vy2U5hyAS1^xm2HTcC9&gbu3>GZJYtDBOmxc@3} z7<>R+0?s+suSY@g`5%F&f+wzOGQZDfK()gWtD8)(x&{^~*ZTcDsC*6w)$dC|m2(i3e*GO#@BaltRs!dMEf) z@E&kJct5xR{3DnHn_ugEVGXE!P6TfRN5F3IMJGF*ltIzkm%-nHd%v#9^wGb8HLj01 zh5V_{9iaN}7q9nmwPIsa@)@pc;HBWaLR0b;@N*zlP2N`YcH7b8xT@Fnx7$JSljrui zoWB7a;`()^rsUJ$L*QlL#r;jm$H09De4Ks_ypQX12Ah(z!K2Dfzn=wf=6da^P04?N ze+MrIzqQHp>ltb?JLIc|oxcA7>O1F-G?~5en2NXCpTH6Bw~V@8b}hJ>>wkgo12>=M z`q7K4UXL$;i@ASL&H2p$D873csC*XJU9Y5Xx@AIZ6v#T5o9?bQ%pybl$LGi_3fZ{Lvo#ErT8`O6n0L2f#1Zo`o z9JFx-c5=Pfn|(YT0jhq3;5Wd7&vd==&tRVG)n|D=ZvgfF72wmr>p_j<4};SCJ_?FY z-3#jbUj&uz;c)$ZQ1zPt)gFHU)gFHj*H1s&ub%@dpO*$a2;76~c2N1v2Q?lJ2bY3x z1ebuH23LYlJIBkv29$ii0o1s>3sgCO1nT>bfXeSNP;&W?pvG(R7UwT}fRdlj2X+4- za1}TURKIKvcrmDYTnDP09|kW5Zv*Fmhn?%+9R$^0r-87xWGkq8K6IWx{|=~f{1`0p z{1>3wYwZR8-bU~hT=#?OhjT%_|4vZpJ^-p59|cv!SfJ>4GQa_;X1s-4z?%I7tp()WVmzh#hO+T7#cLH(V?v5=eJwk!Yd1HiMDF#N%` z>@UaII)wA*fa0@~N#aWWf#9?;GsO|2qp%-5(0?=VN0j=yqj4DZ~+x#Wxf-ox<=jzjpi{@%#ZVQ1)pA^ms2|KfORNb`2izZjk=>8rSZ z4EQOIqr?5raUTDEz{yqIe>13YuD^90KjnCpX)Dk z@qSP|A^wT3=W-x&%%<||@Zcb>_u~+sSq+}V@g>gR1}^0o3F$rx9!PnbxYx>2;`$|A z>u(O%s7OhX<21iz@j>6_T7Ulu-W|>l=lV#_KLP%nV@}8e5nz8m0yW0}CtU01N{&vw z!|_6nD>z{7$qe3I#ZSd?hW}r|`3rfzEb|<-)ck`=bg89;4grRTU9IF{p&;r)9!{}$(;1*I>&i{p7@_FC>;$N4Kc@8f(0 z=kf0gTuWE{5cnqW-@vQDmvEfV`9q-bOi(=eChq--<1UW)SLWnk@_st^{?73)u7^2_ zA;FE@yOd)y$8{X~le{i-{#A|_slxm{%5gH+e*|9;(p}GaGv`m`Ky9&j1#a0N>W%&V zh5v8h_z1@mjte>TR|(I*2_iC+KXagxnanv5ERg2o9GYwC?>_GRizEJZg!8X(<4TTq za?A-2UkO$@F5(yn=?(=S;P_`qBY0mpe^y9yE!V#Y=Whwmq+9CmYKLSy&;LE7xggy8 zG1rJ$`}-UCRnGPYpBe6bgX`NlUdHhoj_lu|wC_=*Tg=U0a_q_Vnc(j@_Tv1#;HP>1 z6OK=E{0GN@+&d`r3#Z9`oNoc|;hFyK0Ds1D3CA6NE9n8R6tTm=R{C{rv!Xi zK;7#P=LhJ5zt=k??+y3g175+s*&Ii5{DbR3j(kWbK%}RC>p6Rv>vwVN;CNB`#837E z)^Yz{mR4TbZ4NOM?7 z|AT;gf&atve}?PKYsszC+`EQ*&*%6##|KILGV;{lA2?pcv6cHju4 zuJ;6Q;P^7f(4{e6q$&78l3;~N~G;rJT&{=_khbNzh1_;@>5lypweCZw2RjhxXIGcCMcd7Qm)(|J7Xo zH^)sJFXsLPcsTf0j`(*vCw~qX9}f3d20WYl=W#3w*Z&CVZs+>NoPUy|jbk6K|C?iJ zc>Xpp$8k-#o&lZ^&c8=G{hiG5dpl$7hI=Cc_WGJm=SQ z=x-kfn^QlF^Tpi151a=s;Lx1*$6WuK^UFipQO=(q&ilX@hVy%chb$i|)(^>z7JD}p z2THZvmU4YC*VSJhDs>e~0|WW;NPne}8!pw0eZ_jQIhj5C=u)n@rC2TH>Vw5P|CMXG zTD?-`-SNs;HCL}}DvjjIBe~I`VtJ%q+FEa(J)75-R4cVwzFO)pRZAnirQASiq*Sep z)rQ9H@zQdwcdS+`S4L{HXXliCe}x;RzFdW@s+G;Mi$|dnw3hxwkpDvR~yogbYs|t5M$Sxbmr2C_tTpkM;NG z`YI!(Ik{S?lQkY)8M{$cIeYqOfeU{K$<7a1HVd=J5Hu{jaoi$Z)fOhgWT2U&hmb3uhJZ@~b zr&RUxbtP4+o*O9+tMsGQVsE|NTk?n9^IyQQk#FBNO!8_OfLdU0sTZj6>k!M5hy(#n>Rp-R!~HB#DA zqBS>DKsA1)Ki6HVkB!zVm7!YFHov2_W8ng@lfRCnZ9(hYwvP4%^V{cfzOb`xZpYlt z)}(D=+q{Ky+rhc>=6ALw?alL(_SUwJd|P|Ib%9Ph^KEVX3#aY*_D-G7&9^Shw^`cx zB+R#30!|mEr){l`)3(Mb`C3}NRT#wXnD9;9nbZTjnJ`lVOP>MS{m&tbapH# zJ!(t=VSY8dCu6n6D+*L^V-69xIoi-RVCbHJq zAWhR>tqjM+Ysc5F%q?0wULS}wFM(Idzxm1gdMk~i2)oHG`NLAp}B~?Z(vVcr$x#AFaM#vQYL&JM7Wt({C z2IrN*%Gkglyr4WZM4r`w66NU`D-Y4SBVwD44$m~Qv0fM@bk&^ORfEr_CuV2sn6@{C z4qdQpU;x_We_D?|$~JiR(M-A~S1rCB1kI!lp2?SH zSb`b!+AQxGh_+hk8|zgMif&;3#YP+KJaQg?L_xfR<=(;EfCK{4tIF_}xTtKQ^mGti zQ>L-2rO_ei00vwd*<7wxMr;ga`hF|ip)zFLLGra{Jl6}4uB(8>9B3jmk?! zz8o6b3ZjuPRO727wXv#Kj*$^k90K)>dNIUsY|s~bktwyZhERPF;S7}&bA7OrUIhF& z_jsM+KqV&X3x!v$UA%rpfdRN)#e}dcTWVCYQ4UqQho%@Es3Kwz=2gUIU>{sc+mP7q zE&BNBt&H^3GW4G5Ar?hL32st zDMRdZQlze4GNMs?;n~JXa&=^}(FWzF2_R+TW?L%NP5tT;T3~Yhs=b4-j2fB`446I* z4TD(fHQvn-U$3U4mS{$_qBpMwR>~_YBYd0=tE0Zua)CRF@z-)Q%gv=`at?*3qfrB; zvq5Na%+>56^%AvNZ-*?}t@%6Ve@ix9Y!#k)`>*a-V2pY9<=y zG2J9`cw9kh8aln%EPd3+a$^8B=T2@rWn;_`zF#mwZi7v%Cqr*O;#`z!z?*arMeEK;J13j6jagm1s}YDrpSU)UtQ1%0xv2jNYyx5~_L+ z9>V}0=_^+IjOT_HbLqM0XcMAYfrD(zFq5A0h_t*#M>|eQIH_#{B}`K=O{$RjQX(qV zf#OK{bP9%qC_n?^pJnC;h|64ke6*BXG+3{XcD1xHuc$IA)y9^Eo*YD=6to;fD$(AjM5Q=GW|kO8VRU@7tR^lCk#A4}-zEXdYiNN&Pjg~5K z3KLtUt(rJG$x~|M>zWxN(exctpp8V48xsCBjklj?u|+zfSkcLZVn7(Vh8n87+Y~#btnx4~HHipZUmeNQI`T!!or7>@6@v*%Tf~?s2!9wUS|4xbtYv9w^AcEIsoLT%=^gTE^lg@5<(`<~i)(5y z8>=^^K%+IXl(F!z9Dps@XB=ah25A$=o<)1B%BH;4LMchBr7Ev zun5&lqv&iD0(K>R*EG0HvC+54#|w#C#xOL+OcQd?HT0t^SY~kYs%z$KDk3yLb4ukk znACPAEE<^xZ7+Q-oAs>BP+5&8IaER-2i8ReLsIo+=wLp}ee7=ZG&~2Uh;4%*FLi0A z(gh7}To$SdDu#J_v+$iql(5?auGBmL z1E56);j&D5dQKG`&up$$W_h#F%dsIFda>wx!$^56vz*-0RjYC{2T*RE_r5cOavYn+b4#C=S-Dn(SwyS`+hUvqMPCYnbzi zbed(;bL%wfm6CkXCXp~pnT1X2!;m$t_KZfMB3c|qV(BnRI4^_BqrE*8F3#4~RDC7L zPh+5%+k~NSBsWm0zza)twWx>zTb$BS#9Z_?~(a;>Um z^AGgrhGi0!#-phgO)l%mq(-vFiv<;-s2KyZoK9geDh=fCb2b~_jnPVm%&|9n*G+4Z zNf!61>t#Y6*(5O~Z3$r$Evhy!aa1sYZH94=Rx$Rr&n?W-du3y zk6r*}u8NyM38P17Ygi=Y2??PRae{k<@j)GM3>^d^GS27w>2yn_PIoz?(TqMb z$9yC;3_=o^s7zRfMllX$ruOnSb!GAhN-GW+?ulr}ll zVxqZ4(;g&G)bYogb0=Y2()$cfXTXI5IhD4WVijc@jlQ{D+G6>ezexOLOQ|Qf?jKO|IB-C`r>;l)~{bn#qkPMX()zTY;Z)0HA-a2MY1gR$+!(! zk`pYT7u_jX8wVAS**`n-&}=mb%4MUZ}Y-2Y@QJlxWA9LzT)VG0H;0)aseD3I*wX zrr{4&Mg}&zC&b)m8`a9_O&fgzoq3|kd~kS3MZvOzbTNGn#EI~PU|L?5F-vRmga$c&x<;~1NTYmHA4w5{MKvtRko`y>(m7cy z-YqJK9tz_&xdL*%G|1dFQg@@52e1Z@_1IK|S#%K-g{PDZMuVof!!lV0H{?)d02M%P z8Y>h{TR5gtkq&xvdEodlYzs_*PCoDyd6bOH(FioN2t@8`ShKj^=vWVuJ16J1JL5rOAShYtV^3ml>rz|-%8}kA zhKitRc*6%OswJ&P39$z>iWMqT<2zf-xZQZ<%n44Xhx zDoE@Rsg$mfahKM$-l)LHim6m`p%)~5s4PRIAA+G9A*hrVQ%X?Nq7s!caq;c(io`pS z2rkH&EgYHB49(lej;1Oi@O0_PYx~uqX6j$y5$Faldhd-4>zarLZbzR%N9A;ivA~P97WeNRH&84>|OYp-L>$OB?jWyjZ>sBmVl`JV&(f?(| ztwR>3QjOqkg9zoXK?{M*N<-;<#8gtT3fO&WFHY^x-X9rZ=T@z($cvVCCh{4{B+n0| zU`A}2-w!O;^5uFyx;ygqO5Q)0AGPTzlgz$S-j$T0@x1t6zL>Y7=0ysa?~^5!p|Rl+ zz!WPXA_Wv^^R>`ewN1}egJLG#z9|X=LXEzSs2f);bB$$KHOAUAUT(ms7D$if$55!M<1t4)M{>VAL3RM+9G^fO@|R0D_&~4 zwfW&rz8HN(R6vd8vu7lsLKUL0MTa&HNY6@^mehV`E$>0|*j(m2sb)D<=fGOrQbytt z{?#^b-U4`Tv+6Zev9Phw92xaYwN?;~sgB9gaxFD{@T3vbmOVGAmx*pOJA!$YR2flt zCa%picQizJ-;h+h%!Jzl+{_j~CGyQC04OdrtPG;qJBa0Tqlrps~){xvH z5mN}kLsn9tp&{b+Ok1zzH!F58)!Z=)(<~V?L=1~bCXu@NplAmRdxH*SxJ{Ll(3YBy zm7X*n%RhUG=ng!no}3dYfgx8!|DdpH~BONcfgQL>&|YZ5c^yV zLKueZR8u`l}HwNLewzazS@Rz^p4C-8TZ zpp_x1UX#a9Ey1LoEE_S)q3E)ZDn{^~22u99mekxQ3#Uv(wPq|QsJ5mX7e~vr)O|;b zohDs3e=2-Fq*4NZ+=5gW*O-f?V%uSlH|VWZT`>nFdi z=^Qjg`Vp$8DdGsaEjkVbk(S4MDv~5rwLCCb&kY*QWtDuU9qMB@o5c?zU3&*BgtB_C z>HC_4rkZam$P34m>np~3P_C9(dYI3uQ0SC@dQQcVx6vnLC$p1?SRP8+v$$nkCXHpm zaGRcV(G^=gCdYXw(>sq;3jBx1OvNq4)SVH!q2O1m`Q*Xnb3q$bh2VJ$9&bc>uc=1O zxf2=k^ktXZA8q7FI|!an*-&zGTU&F-94$@KBc7Mzc&io@hg^GGS9;pcDV}`OA(_Bf znOrY5W`I_J!s126_>)O&Rv}aU=!-EJJ5jYRF9S)M0+dSMwc+kc8KDkHmeaVQ>I#|7 zTy`{fPQILLmvnGo|G^dMA*s#7eGQf~RSqg*YKX8*v-q|23{`qCw4mrzThf=+L< zKv%~=ZEr<=Yd3Q@8LL`MEvNP6s+CKY9oN0AxgHHuveoZ?X)~|?|0!>1f^>j9aZxd9 zlw!lys=Y1#wn`egljJ2MFmNYhan>&X5868rh0#b#AOz1S|7hcg3P5hLG4rF1XUJg} zM(DI+dtuppq8#*4Mgc^=zSeymKf(HPWgnR15! z22q8p<&#Ygixlxv?Zr6S&wC;09nPzpXo+cNRCmVW9x3|07>YO7ax<9NX$DrB5&PZ3 zV7+&u<+m5{K3wc;ChkFN16o?=dt}5Eg|x*#q-nggh5;|XtuZNL;hN^h{0Z=*FutxyyfnPq@Li=;E9LD5Mq1WEJ@-e6FI>{pw+5+Z;Brb{c zjFzoq#c!q3Ib z=NU77#zrAeio&=QenmO(2Qycf<#_H(3q=oOYdvliXWMQAcHad|IEFa} zNkCLGYpCcLX(6Hk6n|P%^jR$pm=8FcO>+`H=7E2>*__9kWkqdG7Mjod($ct&HK^!3 zPlrSy7yV%|OZB2Ve_dqfSy{E&{G+KGo^})^QNAc1D0oI*VtjKugIX^v^|4AdCd1|; z=t@=&7qQqH`_y-%sfWHQ#wl%Jw5|t>`N`y=j5TRcw=jRGK?W|mYnupA7T-CE6einZ zo~B3BEG&u;)r&3d{G5EnvLre&vQZ2<1YtqYkv>_>p;AGJDj%6NN1ghs&C+oftePBa<8h3UKOVA1osOXT$M~b-+=@9fy z?_6=a)Uq6BkU1%vqTl$+5|bEfF$bf@4aWi9P#NP=y0K9Wwzl;y)WQC`?Y@xl4X8>nx@XW8gD}2i zYB#|r*S49dePr5Djbl2#qHl^6p+IGb%W%$+Rtb89xtl>lzm z{7Dj;8M3gt+{-2tG!P%ho?$9-N^^>&AbQ&qn4P*bk{{^7DB>O+7E{=2jpkx)bnB7j zzQa2^*&M(PB565e&~o?EW362AdcKXo=Hr&F&n=IktGUh@xtW{iH@C3>?f+Ae7qrh` zIHknqb(vwS>=3`9y$hkeyP>vnMf`5A+CBK;mU;YXW4Nm6h+CnDM4shJY`w8s+Io$% zyr)E8S5nM0)}Sg?PK&Q)Nr3mzzrg~b#_=%AFn@{h)r8okWfj-r9;Ilu+dg%f^XO%-*#ziyW2L$s7?XDM8F4Nr}_Q~l-g7S$p zcl8w_2Nj%A;8t~;Zb#F)%dx0QFNRfl9BK_yD!$j=Nb-Ec&FUuif^B{AAy9M!yTD%zt8O5U10E z6qr~T**lm&`f8P|n_067TSCw9DKcU9wF+d%dJhJf32xT$v(#zHs+Hncl08^cwABaN zq{v8HL1YD`d6j8Pb?$UwrOZkFp-l-J22YpHsfFDbhSpk{ENxC+T^tDtY}m3w~4k!A!}sDf1UA6T2$NUX6H4)t|$}IuLlgVSX3QbsB?goq7JQc!3MIOHf{=-N?eSzOcyQ?WUdt-jzQ6KiKP?ZWW*C|f8* zN}8nBX{B?Eo!Fa>&l)ArU45SbvuJuH7BP`sE z2P&|c%ZR9QSFOz7R*&G2*0y%h4{o+)+t7=3Jr?7*(O#A}VDjE+f$nR`af~7U+w2A> zno(bD_}aBDV*@e!%?TDEQdjsllGjMetqn`!xT9cnCqaZmT}%wptDu<1Yj?^F!a0#`w2&2KrdkKG z#dN3@70h?woU?d^IYT$=kH%`rS~?@}gZP0mbIr}k+VZFriX=RYh$Bh`X>WeFs?9bb6Rtgnn`3JG&Z)%?2%@FPMXMEwK$?R)2jQ0H2W>=wKUKU#DN<;QNND2&2$OoxSnnp>hiTHDc*|sYNbPKc zCR1D*a}cdWNF}pc(pKc=*~d!NW)eDJ9o@)PcPX$`AqqUqHz*+F|uMLq?ftSq*5qD zGerp!VxzSzw)k#F)Acqnh@eRmpd^F%OrY{}>f@gm8ARO3`GR@{J4i{|*6k4CvZ z`Kc)#LE`h8wKte99?G8U&GZ3QKt%#_OTs#SsG-lp6YQBSH7#wWI7*}E=u*i#t%2ww zPC1GL%IAuZt9>@77rXZvP$SjP&b;wSzC50J1rsmschhWwlivarJcz}~Bj&!op}d#z zsH5g(@;PaW4v)!K#*;Cd6J^pVaEP|AWo~iW&{llT)|_-JJTSq<&w`5jI48OoWs^uY z6_>|nA(t$}UD>^U!}^u0x;LW1ZN#m0c$@B9!y;azgqA)vC9*f^#&T+l9^6nSqSZo3 z-{GW-$4|WbZqhxf=`}CQU~HlpPxVX!0r8jl))_WaL`PPV$nKm8Yd8mcE^WbFWO$gF zB1#deU(t3LAqv_ilQxG*+a$YIx<(0nt9Z-P?>o8h)E$kPiH$3P%16F7e6ub!Ma&wj+)^B3V;|oq86Si1GlyvnlISX=ui31Q(z8xL|D&;uZN=nBPusTF zlTxRoKxl(@3e7i^YWh+YXgJ~0T@|&lDa4iCSnjFvri+R5$9<4qCA0yU`oV>W6WM%gh6Ag_hyr79%E8n23nk~HD_A+T*x_wI!yXp z(0UXup-~kb@FBJW58tSVvILrBvg;u+7HldDfb&nfqRSezFbXdz)`$c+4Q(!{G@={r z+oCVHp+w}TC=;2pwW^JXO8h~Ewf3?sL+YHzi~E2MedS&VB}sQnwvp!bmMc$rAkF${ zGW)TNNZsiS9zCAy}MdnFfoBBG+V`@R~G&|GeScjce)a?9&fd zNq0StlLBvXD`wF6W{eW@!^T3Mr56~kf?J3c*)V?fg0w4|ZYf*b8cpeanlZCu#Sjix zo;4qTE%Y93Q|ZRB;Oj#SNT0CJ^8m(g3pSS* zF`mf6L-B%nlEQ0?7Yi`;5W+OZ&`WRozKalvYhkIWGvi*QIMU7YSF|?yr@KnI_?r9? zg|w&NVGv9bTb7NjL6qoClVRr72DFUwbQ86x;vbUAIs2H~8B$x3hLi#)`zohv!2{IA z=b+U-`O@7X<{CIG$$}Ma)@>s(l9gqvS)2VHMc6~$$y75Po+voS0%@@HHY|ggS8Sn+ z`d%b%rBJzyx{J&RJwRRRwc0|#NJffLfMN-+5nmWf5Z0m4TSjx)#*JP`3(hp=A|jNz z00X^kaw27{Ye8#ktG^ammf8LkDHc^1M1w8)3Zw+fs@5@&dYM&|_$FMakG&1U)WBXt z%8wAcihEtkAj3W|O;a-nE0AoDulu4hT2cP%tUo1nF3aZ}U9H9*%#K14uxR;2Fy!U^ z1fNmy)R0(nu@0^03Q^2RO`TnIUe+!rMbF5VN`w`!$|5koIhKR%PuB2BOJUb*LGd(s zhQ$FFq3vyG69604%4j-IdPANE!`PH{uzIf$vuzkR(1s>$L*;8S!%&#C6gIvq+X>BU z`I)84UrEJDYVvu)tjWb&(%NCPg0sXnw1=I$0vT0_*e6kP_~6pl6$KPTVOUAXuATS| zW3Sk-@E-L~Q7bdi>jT~`l621Zi%gSge&uVS2zWHmyO^L^F313$m;xy-qEw-Yke=eN z;~10CtVkS8sCfn3qhHDrTNb13{!U+@n|Tu=I$6nEfKmpE;6u@`6YBB~Iz6zb#F z!zkgRn@iO&FTaZECe5|4huj)qUoM&Kc$O{^pgQ?p~a>7bz# z!AZ3g%{Qx13}qbmv&`1+R-2QkIvDgae!IB#`B%c|I1HZ{can`1HmFrS8R zncYnMxmefuwx8<}D-KV{R=N%|Lpj6YX4FttPk1c!scF4xWV@4R^r^5*8zp5TAorqb zDY@<~qAizfAHmGy$IByizDo6?gtWeSK(Q2SFk0ydT`y`NQ21X`pQ+-DC zRVYLgdZ-#ovW#f-Mc9c(S&9%EPTsU(;wwReBm1pZXIFcPGtKJo5EvRn8Vcxi!15%$ zB#$3~Z}C$`_|Y?*ouyG+rKfO2XJc70)3n}-Yx$%cVokM9vigOxChMayr*UTG$rw!Q za=WOF_4!~ZkQ|0H`JPYEpqvHS1<~5TEO=&BJNE1tL7jjf`VT4Od&V(@vTVl~zc0Fx zB{o=+eM2EkXGHXtv|$0JLfL}RB{V03y${BUs%`8$NG<7%Pz%m2Gz$Wf$zH5pCKv@8Y%o12n)QzIWeyXAE(Y*Nq8)_<7Jzy-un8oM!XkEY6GKfvme#1k*y%DI@gP0g5(s*}8=%jG3~{2!q-4$LYzY5-lD8kq6h z1ntnm^us5O`N|*`low)_;*U~>dOluVqN_=Eg2@wim?2w+^L5y}cvaZftr4V%klD%e zYb9qOhf$$GF7bb>#TMzvMV&J^qvKASdNod0bHhr{%}0 zLlVf^YAeqUzrNyRldba(<7`q%XDo@EDTPw*R6_Kh$>me#sRdB_K-56O>V+rQOt3h9 z!x$6oq+&@G*BoBN7%L48l(w=1Jo9FDsM_G61|P^AngMlk@zYN-G$6&&N-g>><3>KB!KtIJPNOnCA44Y3UWi0ph~jm7EwN>$*$z z^qizKvg@H_PMndPXbd%7H*7X`i9npaGE-CCpy*K>cL}MEbf-$^ zxH3j-dQQl?(O2Rd(h#WzstkQ0J!?7ikvbuyLRnnzWU*nv7_(QHvGGIcDpmZfXF*@jUKw=1H2rMa%MBD}O%hEj_~b;KKI|&FJHaP|C53K;7uLc6 zXgQ1K2)D2+Nmo4yJ*nG&_TyM}^kUnm);V;1dwm)ffe>~&GycdlH=E<6_>f?NPEJA_ z|{iwAADkm?^Dj7xHB4&tRcL0sz*ZU8^ttzuCYz9#1%tzY*cHeP}S^*OG1cJqZFFf zy6TjgD$PDffP{Pv3Qo=}Hby@f@s$_i5pV%jQX985)__H}7B?hoSv1Kda|BEp?Eq0t zNM&~0QfJ=E&jMKB{>EH_YQ=|W749@#2y&;1Yf9&bCm_$16yaW~u4_?wBtzC{P zq(bou0%n} z8uzS)uUDq202OOSOF{Y3uT!}r`f&?CIqZILbW>+Ldw=k9*u`@<%VMugQx^56ad#Ye z*6NL)YmGTiZO)!CezbL{I5yHdILf+Q)#3EsG?Vz&F4|_AH=dyRV+s8?&?xFobfImQ zd+{9bJ1#KS($LfZ<5;YzmC5um{a2in$CMU+g7WS3YW&qab%Nq|yihw~GE!S`uHjK`mEvtj!G@(b8aHveB{u3wIsN^QFyL>an6 zh7OI5GmT_{Z@E5&=ypLsdSkja&15gOWV%|_)~tuqX|_mb89?mBCnoisvy1QTqO_T! zOjl@vvTXCqUAN{FlrLt|lAcWWDVNcxa9PrRQoUwF-U)m9_`9-6q1ZA{P~u(XG;R6$ zc}Gnkk=r&vC;iU$?tBw7WzD!{%V=q9Dtva;f2FO{7KQ<;N@&+>+RzoGG|%jCosN|; zyr^HPid{#Sf$R|T;TO-p#S-ZH-oJbgdz%zmDrc-f3vCSB}iA+zu3m8p$p zRt#U_u}em?tC7&iYszSNf(jZ}Y`nO;wMw0k)7ELQym{*Ac~Y$|BPte5cpN$HZjnej zEiKrl3cD`Ot{T^}d6MmF@9bvz)3j45q_JW>Wu#A@`!_Oql2vHDxSRE8yfAHVXn~IT zYSYTZe0S9W>6=fo2I+hH(A37Ab`rBQt?sgHnhQPIa_OB|`CYI&E9P|NKOHktuxC_v zP2*3%2b57RqMvxkPAD%lswT?pJ)rTsx5goUa!|%Y@t_1vW1e$fU-2T zUQAJIPA#5(dJidDkVw9EYIln|`GvHYPx!S;e`yoSE(^kUv(M7Blk%4u*_a>>OwoKK z0)|Vh@Wt6zWu~&5pPKHq9m;#AU=^cEMw3~f(H_JHnm0g#Qu!7B{e0EEU z@{`i_cY1#}OS;p0fsq|o+1lv2k;)U#41B$rEP}xtXaOOtqqrSd9+Z#T3?WD zvwN`IpWO?B4Un4&{}@3I_SemfK!AhdU9!siI>8e*>PHI{PMICnpD$R~CEiO%u`tUm?V% z2Uv^wwQB`UWa8~CXo9d7Sv%4d_Si11u+dWzcfRIT#l!F$rt+z3R9p#qpNb_5}+U%uCG^;hRh2mJ~~Dqfr`#h#UVc$^VNlc7!js zE|@!a(ibhRy-^7UsQGMD=fZ7)9SIYgEvb}?a?qE}m;*;@E&QZgWJOaIizj?< zGW(l;7^egiKBf=tT)e4rhcTj>>(Y_?MK<=Tz)+%cMied4lfG8F-bp`Pv<=2ShUxC~0BP1Ip8TGcEq!PYIr zOhqwrtC^Dr8e;Dy9+j$k6~ih1Lj_Ta`6xpsWL&Y|Vs8#V9lv^Dp&>-G7xhW4#kGw~ zJUGQP5<&sO?&?&Hh*J9nEHNIf%we|}YcASCv4-}8LC_%d?__wGT(?;<5SqyYy9xyY zvDuTbz#iv*vYgd^M5y}3I)Mu9p(MnT4vY~V%0~mQ9br`}?d)66Y%cM!G-jHvQ9x~G z@G0akc2XJ~X}^2pi>}mC;e8L6AzDsBMG708)JayK-ioi(ie64_1`xNiY5b&pgN&#Z zdw}PAjjf4#QfF2VwWGAFv4c;>v>*4n(Vxm_!Ob=!hqU^XFYkU{NXu^~>ACJ4Vb zuK3@=iPP;QKUy|L-B%B5FiCBmtiPs7rp)$Z>Y(^eYa0u>qwo4>f?iT+ZEkCx=M>Y{ z+}Ye-C?tgfKLX0m<$hONB6a%R*7nwXYe&9yVXn2ctD~cmcUK;_ zWYvbH%j|sB%A*ZecX#(~vNMLz=F)hjns*nwJC2%rhx_d5^pO(!R-m)&PTa;#JnW=l zk0|WC&NFPWN}thj!4Dn-uo!kO2gd1d9;ZJ|!;g7{P_&`(*|P(?Ahni$;G#jY*R}K0 ziE%+8#HlEM(N~m-7PRQ)gIzK(Ev%FTBAzt%(3aa<(RhL=G*%F@uwaX3~Cf^j5U6gBsbG`KhNF{+n?JTj0o@O5%x&4mM0rU?t4UxZ(D%xUu-FsMQkN5 zd~x4smRArEH&iA$;Q=NE*&#-|V^{gbxzZ>Q=LsaOpe||XCI)RG@CRbsbN7RicrvS8^I5;u*USlbekArue5&H zKm^ek3%Mf>&vh(dD7Q{|K-;v>Z*FaFCApcAxY5?kR+x#%$*0B*Mx2r7JI|nDL%cNZ zZfC{Ry5RP^-V=?SV&90Hhj9>M5-qYueWS4vrx6}|yEZ$U2s@9l?i1l2b{g;~E8o+Z zR%FgW52L?Z#5@7yfhHOnzDS>^==1aA9Avb@uQ1UGgc13OO^rYV`Wj8Cd4mQMBBp%r zb|ZOTQ`6}3uq&!ZA;smHrkyaq^PdwXBB-YIX^;cmo>^QmB_L6wP$R^5zc9J;INM%W zFi>NOrwt6H55*1bKs_SSZ&a%*lDSYVb(=~+AZOotmb`eExtG~p$-bD49^zL56KZ)G>cP0qM0K;b3?0S5>#LzEg_yG zCAT^7cE1SvQ6dj-VkVm;Y}&w2`Sj;a<>q&0X=eYS+`cM1N#)C>dVl^@m~H-4_9V2Q z$we$#3;r)(m#%C-da&D>oQghI%M^k|$yywme=-Hh=COs$R2i5Szr_<*lPKoEswCrE zgBLx%t&!!j>2DQUT@JK*6^HV^6JtK|mSn09u+t6w9PrL@<4N3OJqbTApV+#`q+vo# zMhGV4zu}EhG}IEUp-F|hm&yzpzRa3i`5b>|ne9`H$O)WrWhOJe@?9gi zmw0-K#Z>8VRi1_;?9(_(SY+f(IjihMz20`vYPOR3WM6xCg_lD)P%jTv3fD>#cj5)` zitNl{k&5A00y1R_ec&@P;~wmL6R!AViAj2x0Q%2d!e6|rR7WIuC{O4v+_qk9l;ab32QL=`<3b|BqJz8vHnN6<@eq_FJMmzZ%>U(3s(?lc&n2cq_yZ8Woua&NHR?sfJ{?sEqbP z(iBGmQ(>O1uzj=MsnjyE=-PgjPTd}V;V@OK8rIaPx;e9pBUP%la>6Q#lpr80B+~#2 zh6Go}BzhxLumPPJ_QO6RvOOCmVbIz12{-_&hinT6%^22X>t*HxK9p1IdZSV>ej$s{ z=JczPI{6tz=Dik{n@O(f+dY|g=(F+AYeu$Q%B&dxTZs)@O2w}~YRfd{Bw^`oGQ}m3 zWc|>I@$s3nSVlEa^NVJdLWZ-^aX+!POXPt~nAbP+3qOO{0I_}qlS!fpGYvjGnwZj= zKv#(Zz3e~QlF^zj$q!z^NFtLc9O@8TEfj1TqfmC-63ygdzuJ{F9EyoCm}HWpDQ=RT zU)h&G!Qbf0ErH_n!^bnbZFva4t^_0 zwQKU)U{q>Oeko$KD|gbe#q08`*W{Nj&aGI}wR+{DuU&K8vc2`YIr;TiXlgK~O0_Gu ze8Z|$Ic;*DTeNKT;+3n8TD)}Wx@FznN08LbHTm_}mL8{2={(=J>TKpm1vD9R!*y6` zZZU(6eUyXA-+qhx^udiQC`wD?V_ms$Z|~JC_-`~xTXXB)OMF>Mem%RR@PonVbuC!i z$|Hwit1YshbN%oQ>zC&jG}5V>EHce68|kIvwUlK6rj)(c4zcgpP##m&FxxSYjM`=G z@V3L4QR&Iyt%vRXn*1^RL>1eUsf{p}s8+d7CM9hctTykROx%6r_G>PTv-{G(09I*K z^4!F^=WKuH?b|Q?$Rk(3o&eM zapT$Buf2u>OkDn9y?D;YwqJD7wtFw$e$KfQXI(vU!~H7xZJ&7Lnv28UI4!o1+S;I4_cU$X7N_fjjb%(i)D| z#hLu$t329v-_;Z6UCIY0F1UTiZ8uD5h3n3z*xn%TynW)oBj*mQGH@4mX;3HS?nOnD?`JqQYc-i*r?(-bZyXuio zUbW-4PwqJLT)UA~d+Y|f4cOMa?e2?r+<*V}YtG#MuG=5E@Ph5v+`<=`e8*+&N!$F6 z){cb>z)t=;lC}k{bK5%F7tC*;$N9p}wz(a1J6n^sg>CZ|&TR+h&YR!amSFHom;-j? z+uHN33v}9a zvZJ+q;X?B5oZr#bnzVOxcFtSap0sy%bab}2%}v_pwJmJL+mm!O>zKzepJPEXuVX=5 z``q?+N95;){Z3XV&dBg6yl|^Zrodi9K#11gbwWF`fYcA zc;ce>?KlVex;p9d-8nlJknD=vwqJ5q;! z_UecNA9>`m+ci8samS7i+&ppLIZ$I^Be%ERf6cbL?+stFW-07qj-6pZ!#Ned5?h79V z*;dSSC2*U*H&wzI5Tn3=83YDwCSwrTU>hWc?~>>Yde!*|_xE4_y`S@(BQbR5bcGppw*msI5YiCvj?Fx*S$Ee?FMre6bqjXL zPqW7-q3@dd(0*`W=I+_n`AIlPIS%LBm^unlx327KOpQ0jIf9Fx)Laum>~B}Ry6Vk( zokOH`Yhto-|5$tSAw#oPaowHU+mm;C*TKDQqpYMKYdR7x{F_zsEmI|Gnt%@8^CPm9Xg#uICnhvA=>p^e}PDEH9Z^KIjMa5Ulj%$=hgQ|`Ak z!1X-R*uBQ&T@I3oLiiTfDc4^7=jeVg2VDBkQHc#SYJERFbMKzWQG$Nltf#qobN4U) zCTuUv&6*RpXYSl=+}O`d-dB=WrY<3l70X^&`m5j68O5DoOnjgzIvM9*7@Ed*m<@zn zck|9c5V>*TRNi;{#`X4yVp`SpseygBYs~{+3uHk^ z4eL1zW|_L;S*YfB6X|>hLL!6kB_iRQ(Z2k7d;bn*?V$bsod_)451nng0`RCRaVkvn z($!q?#){`({B@rKF4hmJGS4#p{7oHSgb>x59dcMO5*DROOL+j=3})po?n9nOHW8`8 zTncuDsvr`%U0Mp72G=^mU%X_2Yy3+@mYJztGxyGMKg$Mu**dqqF?ED#*$_j`Oij&9 zUu&K|+dMttO_YuKFgtysJ&D#RwS+F>smM~fmndYt9+nxcOmf#3h-u9|qi_m(8(5&B z={y7E-ONSTy3bH(m85lQ>09bxKW0SURmS|dox!ODL;0$qYrZHkO33gM2hG2pdiLm7 z5tz$GAcr=uf5Ro<9_B^FtaUF;%V^)Y)V{nOn8+}tgB_6oBA zVi{3(gGBYlkne*XBXMbTLv+Kt=8D1bOptK@aX$}zM8PPBBZ7?sza9MK^@#l$@B+0y zxj4-ujL=ouP%P^r75Pn{LQ-fz-Zuw6Ytf)}d0Jxn*iDWBB4Xx%*aX-lcHKYFx-UaU zVplMfY~2vb9=Ij?7qk;drt6iCHLxD+Yo7brls{9~{fN5}BqBZFx6!zB#2mlL*uQ$Yc|B>pA@y$O5;FtkX zt8wQ}xsQ-=t_p>qK%?6md(RJAkd`F3K1Hs(GC%#+e5pcChr4L5NN+dFScSxgBnl%NSYZJ~ z&4ZU^&Kti87yJEt%Rw3~l4H4khzYUNnR#fbEb{H;s|tyxfB_*Y3>7pFaAEH}asXW- zNusB(0Sezh8!2g5ZiQ8)lONu^L5g&-j)%X>qm7Fssbk`fI9Uk$bZ_q8&1sfmM5$gd zePJZj38B7+N|wlk)t!sSQHl6f`-#uKaGE2mri{)}$#C<{O=NJ9o1cGZoxRxJa|6@p z?8Gh`IFmlQXB3!Pk<#1@+B|)O+vG)X;be_H`aJ?XP?src-?ehFOxYYeq}`m~g}Bc3 zP2Aa-!m6QM<)S<;H?b~GP0~q4!2YFn8`PsDO2%;=NAuxm^Y*l1P*uxo&7WZn=OmGY z5+j%%I?TPpUW6S=$Z-$;Vzfwn)p(xVq$JnXla!=Z!P0$Tpm zQJJRiowAu4aG*At-!Vk{!4Y;OLni1$I}9SaM?FKBL~vQ4(GENuP_zPc*^(x=vbpC0 z%(-}T)!T0s9+VY@ZC+Ln=>hjf=^m!{5Hc!6U1m6@Z~i#mzC6ZZX}Gf&S+C%I;5hr3 zxxcG9b{J_A!%TY;b}w5YldW2T@^_%I_k8r4a(jOh=MZRZSW6fWP#D1yuKe_4YeEJ; z_K^e&D5pJoox3YUxN`^LOE3@NM6|C zO#YG-47XsRj#!dUNUl8T_Tl@LxS;pZ&{Tcx{dg;WS>+c{*#_stu?_9nQ%75urZrx| zYunYd->`F8+$l*ac!MXXBpg*+nh}7G$Y=>fr>|t0@OmjWNvVTkg~LdVZ~QD@)aC7I zKaDW-L9aYqm8dLx9VCc|cDae|^8S~h;VpQWi#IyK(%f0L*53PBT)#2M-ysv8aue(} zxnaU+Rr4;I2X?il57*!=Qn|wj-2Cz`MkrQUhiwj0o^gF)yey^qN;sh$tZ2M$7vehZ zIeUAKUu-;tHORmO0Yp6#F|7Z7)20t``{(o?1pNQ~3#<_W{pl;SpM5jCJ1nTv*TgWw zvB$!EYK@)OkXh_1gl)u5!$~D0rX2*_-Eaez7YQ>a8*iSwi$>2JShS%>W@4f>c3#zH zw?Ay`JRo1)?y2VKtI6swdMh6o6S20|{llWGCw9`Olz4s51==9RtW&-@E_k-}c>=V> zMD$ookP^DIu3d9`jh{V;^6{~Zn3wee5bQX7=_Ro_H<+0oow++!F0aTU!Q@$uoCkd9|4RC-0=~jRb#X{{p07&sY5!BnJE@HA(?4x7k(PBVr(934p+Hm ziB5peUCf_rj`W}Bhfab*QYv3faqREQE?iZAiuxa4g?VH>Q+1rSt=_O+mI-0F2`@7w zVcSeAZ@d*N zKYNICmwSBIkD!_+3sJc>al%lMoX2Xitx#|c!4oVr_yxakQ-L<&_!R#~RYjExd#a2W z_r}ecf_sg+Usz#(K~f5(A~qO?yp?&gjBK{p4NwBycA}kfoOi$se zggyI@2wUYZSx5YhL-4$~U0Cw&vM`8Qx^<>)KHD0Ew1ov7o7L$lE?cdSTi%*HULu!n zPtfq$-Q(=EX!&Pj9?qzD>u165r%~2c<{K zib#jn4=38UZ<`P{uU|ym($qPGqigE+?Mpb+(pT2gx___u$GU!ixPeMyKLl{x1^Y9v zMQwm3QJ)lOpP`BcnPU!U)qK2SA$6r12c2~oQAoJp-4_#aMxtl1j?_QA>!kp z1-B5on`d@d*3W2wG0=A*+3^C^tX$R28Gxe&6DWj2U;i3u8-L< zrH~IS`Sq_~3etGyV)N)-WH?_r;%I~=u-?}FAM)<2(o@Y*1hv+^DcaT?l#~AHj?K~K zDkF2)x%{6BlSvUcnh%0<@axuXEas!AhNZOTpdFEzAPhKn5HK0dQa0;LOsjQa3ccA& z5a|fRd9e&@cCG-IUnl9yxvzbnjFg`BF&;?azMD z2Lhz_f7!Z@Pwjw+B?hiT`xze{2FI*)7|>neL(s;b9SYI7ere|JIjQU4?39Xr!%|jg zVMrD_O;d)-7K!}0w*xa$^Y~@#2l<#;vZ-$k18l8v2xrQbdMT2qxNeD92=9d54)%9a z#`~Q`7TNE-bTCr-RMrfA7+Dk%ww_w4fm+HeqXjl@ZrAFOMwmHq>zX~{6621Z1;>#$ ziz||4P%IX*_cp%32Jv+RQ{A00 zovw{`=^udq3bb7jK9WZcet{I+{`?fDRI?CjlV(l2Pv`xg&0*7p9U?l&t}uQGk4i>? zj`!*MrN-gC%n%gxYKVqkH!gfGlK0b2j3Nb9XMg`%$Qltdsnz|CN_E4l(?7-1C9jkp zm%dVy%^*xLLjLI^jhhdWnF^)$&OW#{#gw#mHGWe*yp zR)FHZLF>QV+g_U;{Y>&30RgF%!t}~7(|6DJztH(EH&no!Osd%7gBo+#R+Uk^9Ntr> z>55mOS3uixNau8W)zYpK&~eVtgnD|bXT!Ru?AZ0rXW3c93G|Oztz1?-0^n^t^Fl2M z74^54zy8KME8pnflJmKG%Hf3e-L=iG)mFOykFPgbO9f#s=xM=AEu%q_ZY2X6RNwR!@5c?*^Aw#Cyy(TIk5Dl7X(LRlO-GBtXBgh6>$acxxBB} zV!$44v8wV9uhI6<4kvFs{BCyiEb$z($FEqy?;L!T%dhhC%)Xsh$FqfNKaQd{BLkh! zky*EOh=o^gSams%G^3$)qvi1)4siskw-LUy6jO_zN?%$(ikNO(fqU@*p_YQSsq9O2>*jd7gh2i0$n!q6;T_$Nubhm-I-6BCn2u>=(IiO6r4@le} z8Ia-|(JydWEk@dS#Wrcjonb4IaQ?@5>);7333+Xuy^a_-d+Z?-TYXZW_KgG0?|0)_ zs>y&x6l;FgL1-VTC9csjpcnSGf`7k2Y{vHSF^RIFlF!ldi@JpLXklJgBCFsO=L6Eo zl{Y;evfeHeOhARz66>T0nsPNRkdVPz2{>v@+(uWGc`sZ%ZqFcW0MJ;bL+Aj~jq&fW zSOC{_T(3sn{YVkVR{Y24(VW;BDKW{XfG)Nf7d;CIgZ)FTGuAJW3()95BeDva7O|6A z7cFY+9FyqUlUXr(RL7gsDw@~Mmzfnre4xEWS1buPp9#zY*Au{uTgA%}7v@O+SZWdlG&4A8h_uF>4igo0; z+wmDIruY)$a1%l5Qfq{X*~Q0QM#fJej zI`mbU_o|CDSb3>b;C(Zd+UCOVBTGkg#q1`|XxdKu#u*M& zc3A+?-9}XO-qGgRI4mxdQ~lYV{NXS6&d#11S7cB)G6*JZ9m5o%c#Cv7_U&vu+|k^3 zqIrwu9c7*YU+X;vkg!W6i`!>K2oWSRi&11wTuYG=;+J~hTK5|AOR z3k?(yu~hoPliiHnc_TUwi%so=KPz#>c{U|sw3b|y+2giZGO`Jx)^qcFBXhDsPAV0E z8FdRzPGY5FBGXp)6%7jWOqx2SnGvHJ>L)!hd(GTA-M;uxhD&bd*v-bo&Dm2A1auPT z!h4-CI|;>jWJ{E-`(}2Ho`k_fd7ba2WtHw-9rCV|CMf(+W&$yv%`Dnz)_pXyVHYBR-2!sMbXyObaG8$D%P7;H| zAua-Q4oXna;q?dHnby_gjd2#Mi(#&Bz*T(MY z#?O~#9$aoexZ6A@>RQl2vhPUJbK@d?Bf%)9gRv`#>-zB}Al%Dfg91Gc9OH7a4a;{a zYB^d-h9v<1+&y}0EAgeyBQCiA)c(c7Fpb@rZ0!BEv3s1vnb|MK7|vIMo{g_|G)_O5 z{cIA8RrBaH>t+-ix7lOJI@XIKjM)AZWXGdduzABU8oP)H`azb7MT?NmU&44QgZ|RR znE%QClsKUL%0-K`3*x~%V#NJw+1(?Fpxqm79+fezv-os-=J9iLZEVg#st!-KWGL>2 zLij3^ffZ!EYpq8UTQ!rYc66BKg=$^5dwM{PpYW zH*KY2B3ZW7g4s|=Dhcas(Pf=wN4ie-QQknpBPUeZIJ4iKXg_#RELmk6lx)Ob7s;{E z83Av4`}SSJ!DcUrvNn&OV}USdPNH$(e5sMlRS>D9G=P?V{1f3}l*N1|(PReCXa@5#& zoFeQNnQrF3vVkDDqW%%Cla4Y`8BSS5fefC#dzGs9^Y;ja@+^@j;Iyj4Cj_+YaTB(V zAD_8*oa>A|wsGNGZV&eL#-xJfS|IP_Phx!6FDY9n5>00Apmd1^B!e5e`S@X(Ok-rx zgw}WGi1FY8lknx6=tY``iF4l^=Qe5`2fpS@xG!v&`6N>8&`*h~?7Y(;P*F=1^MmHe z1;90qk%i4nR+|0PE=Mslt4%#%2j3UAh;efdAU=||#diqCXD}*Qi%N#l;<rxj`fBPpn$C~qBb5(vKWRY2&45KPUo!M$Tz=XXzlPO)oToU z?%>A057%H{@Wbr9=j4Jxt4B6}`oD(O{lg0{kiVXVLFyud2QKB3+oPBX1n7v*3*Ei_j7*Dvy=r7ynxh&6`4;kiN? zJlO_aPmo=?W$U`3O{BUm`4x6YIhD|dyFo><1I~cAg=mn2aN?^^4-eU6ZXo?0?WzwzK>M0Tm7Mp`BE z(U&)&(MobD2?GLx?nTll&>zag*|g-!uc2@7d;F_#xL9E=B{>mWedepi?}kc~?WEr5CZdcw_>d11>neED%}{^cDlY>qzOsL_O(l+jTdlb06!s@Q7hC_4Xg^s+XGpXkeoGY{jkh-|1bpDfjQ z@F_y2QIqZ}uH2ZtBiWTCc&Eragkd9fCb7_O+~lPEX!x^)#1i4Q-Dj${fgftaPQ&-u zJa-3mD_0tjAwceF<3nUFGkl59tz-L9SFxSGwR~ZLuTQcEI?3IK&07;1F?d?l@Wvtp zO2>Btg~U-((5nk!fHEC*aCM=sJ5(aqXOtlkKB9fk>?>eEyw~!*c655-0R%bHyo7#{WWxs*jRunC zlCGrASR{w4)+=m3L8 zNjvWm6zp_GEH#p^QDO%M;ZwE5pet1n*kVcA^UrKQ=iPJ`m2W5@SKfH}gH!>0)sgBT zM!u6=@oyaR1gBBVk7v_7O8KF2eZw|V&`QCuON>#f+<<m+>zwX@Fmvw}GG%|H`Co(t*+Tp7Wd=(xF?_>`~%I!+Bj3@&N zqH*VIDWXEg-w2}t@1(`&$W_kLEJbGmX~pngFLBg{tkN8Ua_u5pR9yB?q*>%wd07IQ z!NUp8lQDsc^d?`uY(wf;)#~x=g)8){9{|SzM;%HAjJN4Ao)BEZ+H$cQ(j0Zyg+_*5Tlq;=Sb=Cm?mR$ERyHY}ODJWs*R? zi9D5>gYI=7?F9-03%61yo^1zROef@YsNflFf)Pm)0a(ZyK$;%OG-?rgl_IO+>PBdP zIiLwG0yYIRUCc;y6_aFiD{m)j5GNIL>{J$UMU%3Pj;3;J(|&XSne57G7wJAFhB$p zMJ7tgfDSg6)2C$W^Rx3rKL!RrjW_1|NU!Ys;~(C8x9`1`Z@jCrfPHVi@$MUGA>ggt zEeJ^w!0Z)a7`FU8&+U-T1Uqg_-B!f=pZZ5J_KXr)i3?IY5+mb_=HU|%GW!zXh;#3}C4@V6yOhnrbJDV^(HtQw!GH!TWvLyyk){nkgcT5(Mu3TM%hCy{ zK>KROQq9su8ETqRR!SJ_QdSYt&H1m`(VnqdYwAYIa$m55>ehv`$rsj8ZkW7QCC%{} zR+wl~FfVL_WXOVn?b~PDx4*G4R#6HeB)ZycBLp2M#2fHHEQJh%5BXNe_y&OVI4y%_ zSN;6b&F0l&DQpn_vt`ZJwI7oSP`2!T0Y^isafxwW0#itrWd6Etf0X;~ql9*0Z-5W6 zGiL9TQ2Lt?2)(gQU9j$Vq1c6_uTlunInP0rrOmt>Qk>SW$3vG6&ez`@;#IhhhCUt~mT08nvMO4f`XyfL z%FOy>m}DQliynH{Mb5=ktIC|%zPWN|Zh;{G^$P0B$kuh6igg>y0?5VY*xK{?Unkzw z>vKD8+qxkO0J(Agx3^Q3*5PwmmtdiX2LH#etK#icOj%J;AgL$qrcNCZth~C)By8s zhutdKR8_PbU|>2@EPIz?DY%U=0MXsHuT73sV1I4C|2c%ZaS_0WAqYL22yt;kGX=KPTXItH&U~6 zihyy?te~s&D%Bz%DfHAuDz5+W#!Y`JT$9|0(V0m~m931EJAAg5_PRza1%A7C-GU;2 zrKpc#sxu_|Kw)93YY_h6e->PH<&wh3#zcr5UM1lZ$5oAVY*_|h#wq-=EQ2dyQFGo$ z`iCX*jAb#jV<@_F-O518ziXXpeJBLPpitHUU1RK~Bks+vLf%K9pE`sntb~+Eh5%={ zepuY1kebiF z{Tq%&~;S>X^Glf0T^h7x`5rkLeVs#0?P8sj((u;!#7;K_-^+YH%p zim*<0xPyQ~?Vh=JQf2n0ul-G}UoP|%f+`7-6Dc~i*=n!wD(x%v6x9~RFbWmORF0Cs zLd@R5F9^Ab!;LyZJsk)}SWn*nhka3!K<`m({S*@;wf7kZpr_MJ6LiAnT&0gU74ri# z5s}^TWYIYnw&+wi>kxJPSEsM2nlHE1Mauv>iV@2=%K4ZS3cA|PHH!vhH>y<3Qaa0J7?#DO8ap3;Y=-H3Vm${#>W{Mkd ztxqTzjYaib9K`oiF>4B-YDScz?H9C^qD!nd4U`Y}P_fQUqSrHBR5t`|) zuoL1nbOXLRt)-Qg2iE3j1zmC1GO+O>Z4~6A32Z^VFhQ+bO*zCX#?Ml@PLkBgD>dA} z5(lHg0pYW7c_^RnnhApB3m3DALZh&E*TWHk3^@zZ*!+pQqlyL=Gy^j^XgZcH?bcEb ze0VRdu#~(?Mj3({0*(m4Hfyv_Z*Lr&ZXP;~w?xBEO}BPj(w=}Zek;DpAX4cASYPqn zW`a$kw2DEjCZkmUkqcB?JEmx0?AaH+Zs2F|zsn;duv|R_$l^(Wr6cQiYPelfr6yIC zRHSVt3&Th%h&O+dhh#1R2ZbUc^c9p6l&W#|EJVzbl}petFLX@z>31aB^z$@D`ZWR= zyVoD(aJ>am{N)=0sZZ~5AeITYYu|_wN4%Sr8=5I8cNYOvDo3nAOYCBDxDu{P*NFp0 zuApy_;9ai%ngryi?&yMN9l(dM$IzvPMtonQ(C%}M1Nbnn+P;RJ%dRagD&qd>6HQ|P z%a+NZLA+UbxUBkyR4gW9n$p<;`4>^~9F%aJborAoHGX0@c5HKjh?(x>eQRbTa2Ket z^sv`-S*28C5|7ti^f1ILFD+iYIGLgy`lr5$ZZMHUj*Q&62t%Cmm)Syj(;Tloep)ev z-0z3qH4psERe`G#@kI$aM%3QpqNmGgu?$xrF5RlLBzs&L#}t9Hp546{lL~;s2kQy~ z)Du9oqD?ZoMisYinulv08DD#`i^e8lx>Q{`$|FVR%4Xt{z%Um`HQMpWhFl6dWq~Xh z1yWgPIP6VUe>79L8P?@6A(<0uzNiT!5ah&Dz1xt3)9tdsumk0=up@-%C?U45{5R4N z^GZARgb#ayS{|L(m;1^}B1j5!KW?|r!kCa@UP6uyoABzm?w$o?=nxV*!_vpExd&Ja ztw)zEd&CUK&td*B1a*6{42Q|TgfHF67UA#%9g=OI&>zNUARD{woB`3Cfkzex|1)xru)j6HCZ;cJZATC>xD5dwGY6c%q zBrf7yZL?v=fF1Q)oZVWMzCzZo*Tak1x3Moda&dQxq5a#EZDr zsoMtb#PC)O_)9l8{IhH&xgZ{l&D=c%*$x?mv*Vz+$ zJBv|XFe^*Yqkf-FCXNFN^QG`@Vgk`uSU@R7ZfFo|7f*0$KUT(B!MiBEMjVevv#mF2 z$>*uwt*mT-Cz&EL$Vok>SI>YtFBU{JWhW)SiV|VDrB6oedBSu>pCb4{xDWK^+Q)f- z$hLKKC&o%bL%3C$zhq((`m(qOLW{9RZ4wLO?p3|XtSO|=^72Y=jAtzZ#_>W+l1AbU z8}Y0#R2%8-cImC7SJolrdcOq)_ydleRh6+X(oh0pH(!|Dh!2e}^h*WV=qB#rU7 z4iFJf6XZN~C*&Dk@^!wxT+iLg8WM_jig)*YmhCC(IA&n-NJ|=0RHmZU*=VDy)joNj zs~LJ)Q;*A+91np?H@Um9r<@NAxM`Y5@)w;&C_+ zcS%*Aa&R%DAz#~Hs+GC5eQSs?$fYKmN(!MY1NN5uvXD#eI4jR*m55O_jAY(un5^vs zhw_1heB`1ew#cQpt;Pi`q1UY_TZ1XqkQh~1KErO!7>=)Vcz@tC*_0wE6}iLORti%B zO)lYTRqd1xC$?IeE`*!ARk4hBNryifQr>B-c>f-(Iz|pc7p3Rg8IqlwP})_zpS5z; zt8cG(f7QG1z4JPhwz2!ZC45K{z-;c{6UPq=}sRGEgEbT8*B2C+ndA)X4hKp#bN z#EV;Ic;GtaU;q+S8MBXxNc-|<#35;U6!W{D6w|Ve_-nHC9}vdgm1f$Gx+5sprSq~b zPt=2bUS`D*m%QFZMn_`A6`g`PX{!?3vrOvuU@F^ZG#!F&|{i5?eMcGihW5Y0!MzgR{>E{q>%@H|&;VPjL z|Qjp z5_tkID;9AG1g3zFp`50BoYPHZUQ+q-^iIWgXN4$;nOqqdNT{78(@63-bbt^Q`pY7c z#lkdb+!&TKdx-+$dz3u0>!gjw+70klLQHVDv{V;p%Z~ug+_~8PY==T($UZ*xfI#y0 zO&&5tkU1y3&WrVd3#sA}3vQ?-Ad8(gsQ8kJJgVHn)z-mpTh|WL($tdC_({h7z#WFN zWlWIFqcx9_FsnB(po|bD!#sMaR+36H$>#!Su2@L$6ltH$FK%k9S-9|S?HADTIJoQJ z{^qz0Vve_Q?xQBSdsaj50zv^mNHXr7htKZQr~!J1T>K!NDx3)SA_B@^}LSx}(<5 zl=BC!r-k%}ud@`Pfs&9@99_!Xh*%!mTie@7cC`8XraqQqYRIz$0bqJ!fgLlX&HAeh?-q3{)`_I!m|YJWWyW_36HGEQW40F^wQ=V2KU9o3l}Yh`%E!u;&mP_PfV zhTBE$XK7?Po=O1-@~k=TKuXS4oi$})@vubkF_{3#y08>odQjpeu9~$oCCV=NSNrXY zm4jPgWw1!zCzA#{epr!G%BnuFAk`I=bfVXc2bF4|jC4p5X;3NWky$xlUzH?aMP7R8 zDsYf{GLv4sZ!rX@;1@K-ckZN(!)`Wvit6_=q?IP|Qsws)-oFYBL_&G7=uLd)1jH=Q zXi&Vp?X96T!>fn4{jWuU4B8vYl$eBH1W1!+4YF9Y+%d78j*Dy}G>QKbLLaqZXOHr5 z>kXtRuk_9_yCKjJUsD4E7PY zmV>n&+b}{r;wGmZ&Upv{@{?Rm@j3#Ee>tWEEF`t4eI$Xul1F51RP;uw7(@*aSTO;Z zIsCBKULI|`R_#SqjSv z8WZjfQxqG9;%Z+&2b}%lY^3bj6F_2A^=l(-K zf`?H~0Hb8-v2bwxUo5b04e|BqX;|W;?^BqM?{)D`r1L zXtUH*89XRI9Lwc4b>6qu@iYGq3=Y_?K`zQqJAJP>i$fq1T zTSC(d6fDIjX1Jxo_jWzubPTYiF9o&$mMzC&e<;ENqxp37cA)ROPyb zjB@NaAtV$cMEK;A8`YjY~$dT0ZMETIq=Bk zcZWTHwE5!~mQt^P&Z%bJQ?4eu%)1($YdDW!y#f192xK0+7o=;p^7P*N)mt~N{b(~) z47H0tuPq13y`BJ{d3rqN2=WU3o)1f%2Rl^vbnQ^I{FB~5?2YZr3+vrZ!X$87S(U51 z#^{0aV^%n)Yo6{2aHy_0cTqg~){zlKPS1V_4KL-UI z;*FRsgRy({?!I&atL|e(gBVbRd`O&~82S7bV_c>xi0K{()6oH*bq>l8lF0z;{vVv< z6EY(I%Hd0rp~n|`k?zU2se*o6R)4&H>o$lbX`4e^dT{Rvc%&Zl1GX}Os1(KgHACg& zn)RF39Ub_>nw^2^F)=kbu^2)pi3&hGoPdVs}3JaX%& z*cz>ScK0MGmov-*Xn@=o=hl1tPrD)?`m>>D^vM%EVfAI(y!d4uSO$tDfPyK2vV(e0 zapbNxg!J}=C6wdlB~(`+w{o9f#t8u^Z|kx1S2_*2Z|?S_rED79GQ8~(7&x+a=wr%{ z&3l}4snKH=SRH7f>yM{gX0?yH%mrM>QPzuib65JLOVJst=VCl&i*fBc9iMhzx1mGCv8DSfJo^l6e+qrnsNi8lZ z>$5Y2&LGdYiB89-+)1ayBTnQ`+4os)Cy)H3LnwPb;~vU>nrJS7=T&x|{SL-3&$=?{ zS$X?UAbc_Y{5$wF8t}054u_wN>yNp78c0?C1hE1A!Dx}rI2?y5J^u--oZG4PIMcv} z)mx}x@Ta~tltJAxuwm=^EmlCi&$LomR(diJKkUTu{@dz5|9K5b7-D`-j(OU(c6TV( z`S|HJeK7bj(lA-PPkC--+ozl$=(3U(HVoo7!=E>dw(*p6&DX8=IFn9HCg=?gk8ISY zo)LkoU7vD|ya^l3-_*|_QPdV@Se3QWkc zr#86TcAb34r0GQ2JBGq`U;hK*@XC*dKBy+|Q?j*Rm2hB+sRrkVt~E?#(CXnWgX^d` zC6P)itkqY9jMQ0UR;%LcEThp(eu+~11{LBF14fV)H(P2`mCNj?%;7Qe2Zw{Yx3opE zY(=%y1u*~s!0`-uNc#?*{z~*s)%(HSQ=BaoS)+=y48avkaawX&N5?i`*@m$)AKvRC z1)UwK905#5aEVQG-v@{FWyk8G;sz>#`|G~9S8p3wy!54)U;1@v#z@mSw2q)VrqhC4 z7yjsvQPWjLlK-k1pHDL`e(6`g>Y6dC4|Imi$5MJhHoHDS;BaX-r-&eC@po1(U#S%; zhGW#o<#ZMKJ@5om_-{puYL3(vg%PDM%2X3SR*VsyAt(W^;Zg`t1TGW6Lx4TD_guG1 z7IUZTr8sN?;1?EzRoKyCZzGWgyfQXtE(W*%L5qur>%CmQFUy7%xRycub%Pt%4h<6G z4K|Sn<~1qq!gU)A}tRp}%7)+&H3_monw)6?GolubbMlFpPJlH#gjASbp4kK>se6JO7s zP=J#5K2%jRWDwD$rS>diF zWY!z)iXw^t<-iUIyn>q9oId^C-<6+#w`rIckT#Zozso1lyNIMCcB_45vG+AGhNn&` zxdC|`<$F?v0?$_suclhDg8fVUU@v^tx3uj*rb941{u4zR*8X9oJlF<;##^$u z|KU%}g zvQahR6x)n0*%KUPxhtZqCrScGeR2Pi{$JO5inv~1(*HvLQfjr->s0Zk0JFcPG)?~t z{&w-w#eIvP?_2zGv3T(-&p-dl;^&L^R)LZ9m{VyXzFq##>uRYSSM*DVO=NMB$Q1Hf z6C}HONGMBHLM(>ZaqsvHvyD03h-z+~oTdnar49$hz(f+EBxHB*Sq1F@Fvr^wqY`gC zr@C7?N}*h*_)Fqh#6rZLR7PEA)Uliuzxjva`IoqWi+g@x>q}qkU);Z#=3(IBizWS3 z7_13RQXz+uo>utnT$L8$L8onY8WRj)wn*4j=c|#en>WK@QcDBBL#^|1h`wl)g>E9uNoy5%<~d@38H#|La$AdZ_#Mfced`uGJKmSB zw8?-T!8g34I8v?E)#?LtLLe(Ez@|rTL=)VR+@?|wU@?xo@^l%I^%}8ofY+;Y_Lq|k zn68W#>{Zgdh{B$&!S{38Oe`egC{^Xb(Uc{=F#kMt3+lszE2ESbUf6Z3sLJ7Ev0pf9 zto1vuizgaB9E^AXDmrDQpjeQeJX*P#`aho*E@-!~R>44yDzMZbiQxg4J8mlgOQjxQiNc)9mQES{Txa7N}Ky;I)b-?lKj%b%P^o zhle(cf%4g}LHPJ<_{q26?2dn9ueBth>R-F1Yf(EXMPm66Jgjox*W{J0g$1RSlJ`dj z*MHC#5;5;Tf+c?Da^3Li54Q9T4Q~0M@86)J@pN@Oa{2M#wgBW`*&X!|vk1$4>OuZ( z)5gJ($|5!o4}C(2O5d|Aq&mi*7;FRw3vTBj9##Hx1TA+~Bkx~_6g}GbSAD}QdjBH! zwR(M@Pp&VMmRc|4p7RAkp$DV-E)m^|_sx~G*dZ0Z){WHC)6cbd9H!PW>eX7`PSrMU z-SB>n7#o?Vcx4UmX$|t2Lfyy~vQ(Y(fW%uX2)w`j;0XCIuD0Sn5DkK)o&PQj7ZcNx zt02&qNK;i?6co0k%K8+m;JW3|v>w))mD!S~GC6FgRA9|lExcGJXAK?E+KMECiKYJ> zxHvO)SufRuprNdnT|cz0ZrAWE-&^k7ipN)wTq~5?Q2SNY@=HQb2S0fSCmx)+*Vt5?)L! zyDH8|K8*qr!A||zvsUkxAyVyLIV|p!WI9eh!7Ea|d|DhXePxx4Gy&($C!`R#45iT5 zV%wY+iZ~CVsES&pfvVQzCpMB9F5i?mhHZ&y1a<**nflT{e_vptL`nYp!f8QQ@kAHMCLQm~4*S zDi&-R;`Pcc)GuCG3-PZ8y3`aX760Mox?N(`^?E1(T{+#=r$y644;_=1!L9vgF4^(9 N)k1Hqb$MZG{~!C^hm-&S literal 0 HcmV?d00001 diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po index 4a101980f..cc8332b72 100644 --- a/locales/zh_Hans/LC_MESSAGES/messages.po +++ b/locales/zh_Hans/LC_MESSAGES/messages.po @@ -11,8 +11,8 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-09-05 14:34+0000\n" -"Last-Translator: meowmeowmeowcat \n" +"PO-Revision-Date: 2021-09-01 20:29+0000\n" +"Last-Translator: xlivevil \n" "Language-Team: Chinese (Simplified) \n" "Language: zh_Hans\n" @@ -117,8 +117,8 @@ msgid "" "specific topic without a specific goal in mind. :doc:`example discussion-" "style document `." msgstr "" -"讨论 (Discussions) 的重点是理解和信息。这些探索一个特定的主题，没有具体的目标。 :doc:`示例讨论式文件 `。" +"讨论 (Discussions) 的重点是理解和信息。这些探索一个特定的主题，没有具体的目" +"标。 :doc:`示例讨论式文件 `。" #: ../source/contribute.rst:63 msgid "Specifications" @@ -161,8 +161,8 @@ msgid "" "the `Hitchhiker's Guide to Python installation instructions`_ to install " "Python 3.6 on your operating system." msgstr "" -"Python 3.6。我们的构建脚本只为 Python 3.6 而设计。请参阅 `Hitchhiker's Guide to Python " -"installation instructions`_ 以在你您的操作系统上安装Python 3.6。" +"Python 3.6。我们的构建脚本只为 Python 3.6 而设计。请参阅 `Hitchhiker's Guide " +"to Python installation instructions`_ 以在你的操作系统上安装Python 3.6。" #: ../source/contribute.rst:91 msgid "" @@ -4105,14 +4105,12 @@ msgid "" "venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the " "below commands." msgstr "" -"要创建一个虚拟环境，进入您的项目目录并运行 venv 。如果您正在使用 Python2，在下面的命令中把 ``venv`` 改为 " -"``virtualenv`` 。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 msgid "" "The second argument is the location to create the virtual environment. " "Generally, you can just create this in your project and call it ``env``." -msgstr "第二个参数是创建虚拟环境的位置。一般来说，您可以直接在您的项目中创建它，并称之为 ``env`` 。" +msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 msgid "venv will create a virtual Python installation in the ``env`` folder." @@ -4135,21 +4133,19 @@ msgid "" "will put the virtual environment-specific ``python`` and ``pip`` executables " "into your shell's ``PATH``." msgstr "" -"在您开始安装或使用虚拟环境中的软件包之前，你需要 *激活* 它。激活虚拟环境将把虚拟环境专用的 ``python`` 和 ``pip`` " -"可执行文件放入你的 shell 的 ``PATH`` 。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 msgid "" "You can confirm you're in the virtual environment by checking the location " "of your Python interpreter, it should point to the ``env`` directory." -msgstr "您可以通过检查您的 Python 解释器的位置来确认您在虚拟环境中，它应该指向 ``env`` 目录。" +msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 msgid "" "As long as your virtual environment is activated pip will install packages " "into that specific environment and you'll be able to import and use packages " "in your Python application." -msgstr "只要您的虚拟环境被激活，pip 就会将软件包安装到该特定环境中，您就可以在您的 Python 应用程序中导入和使用软件包。" +msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 msgid "Leaving the virtual environment" @@ -4159,7 +4155,7 @@ msgstr "离开虚拟环境" msgid "" "If you want to switch projects or otherwise leave your virtual environment, " "simply run:" -msgstr "如果您想切换项目或以其他方式离开你的虚拟环境，只需运行：" +msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 msgid "" @@ -4177,17 +4173,15 @@ msgid "" "Now that you're in your virtual environment you can install packages. Let's " "install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" msgstr "" -"现在您在您的虚拟环境中，您可以安装软件包。让我们从 :term:`Python Package Index (PyPI)` 中安装 `Requests`" -"_ 库：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 msgid "" "pip should download requests and all of its dependencies and install them:" -msgstr "pip应该下载 request 及其所有的依赖项并安装它们：" +msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 msgid "Installing specific versions" -msgstr "安装特定版本" +msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 msgid "" @@ -4195,34 +4189,32 @@ msgid "" "`version specifiers `. For example, to install a specific " "version of ``requests``:" msgstr "" -"pip 允许您使用 :term:`版本指定器 `来指定安装哪个版本的软件包。例如，要安装一个特定版本的 " -"``requests``：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 msgid "To install the latest ``2.x`` release of requests:" -msgstr "要安装最新的 ``2.x`` 版本的 requests：" +msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 msgid "To install pre-release versions of packages, use the ``--pre`` flag:" -msgstr "要安装预发布（pre-release）版本的软件包，请使用 ``--pre`` 标志：" +msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 msgid "Installing extras" -msgstr "安装附加功能" +msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 msgid "" "Some packages have optional `extras`_. You can tell pip to install these by " "specifying the extra in brackets:" -msgstr "有些软件包有可选的 `额外功能 `_ 。你可以通过在括号中指定额外的东西来告诉 pip 安装这些东西：" +msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 msgid "Installing from source" -msgstr "从源文件安装" +msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 msgid "pip can install a package directly from source, for example:" -msgstr "pip 可以直接从源代码安装一个软件包，例如：" +msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 msgid "" @@ -4230,24 +4222,22 @@ msgid "" "meaning that changes to the source directory will immediately affect the " "installed package without needing to re-install:" msgstr "" -"此外，pip 可以在 `开发模式 `_ " -"下从源码安装软件包，这意味着源码目录的变化将立即影响已安装的软件包，而不需要重新安装：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 msgid "Installing from version control systems" -msgstr "从版本控制系统进行安装" +msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 msgid "" "pip can install packages directly from their version control system. For " "example, you can install directly from a git repository:" -msgstr "pip 可以直接从他们的版本控制系统中安装软件包。例如，你可以直接从 git 仓库中安装：" +msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 msgid "" "For more information on supported version control systems and syntax, see " "pip's documentation on :ref:`VCS Support `." -msgstr "关于支持的版本控制系统和语法的更多信息，请参见 pip 的文档：:ref:`VCS Support ` 。" +msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 #: ../source/tutorials/installing-packages.rst:569 @@ -4276,14 +4266,13 @@ msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 msgid "Using other package indexes" -msgstr "使用其他软件包的索引" +msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 msgid "" "If you want to download packages from a different index than the :term:" "`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" msgstr "" -"如果您想从不同的索引下载软件包，而不是 :term:`Python 软件包索引（PyPI）` ，您可以使用 ``--index-url`` 标志：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 msgid "" diff --git a/locales/zh_Hant/LC_MESSAGES/messages.mo b/locales/zh_Hant/LC_MESSAGES/messages.mo new file mode 100644 index 0000000000000000000000000000000000000000..b16da9fb29741db5a3a8adcb7a71b019008a0905 GIT binary patch literal 6020 zcmeH~TWlOx8OIM$Xfd>fmfk3(r<7ijde*zPlh~U}bFq_H*ohlEv;l#4ynDQ!WOrse zGn>t#KG;bUJ9S*sHnFMW=6-RT`jVt=5<78)K}Z-FFdDLy_1nqUL?LlC0b zO`rAky%YR4p3A`p!9MUd@Ek~Te+rVGzXoaDJ0RKZf;8{%AlZEzj3h1qSAfew(&s6V z{PiY?sqAOq8?gT^kmBEevoHUU(Yf0F#0 zxD@;|xDE`#n6+RQr1futa1r|nsDf{U4}!I~`*ue_ivM!QjIS1-lB#;jzRf_@V@V&9IL<}9|ka%VUYjlU*zX|F&@EKAU}{VS7KDjXNnPB zC?C)N6brf(jC(Msy;7fG3l|F2%C>2`WvhwA!i9K|(o$e(Nma0_wg#-mRmDQJp~ba} zD#1mImsE#XWiV8&ghKd7w@Z{@jS?)~*3RCBf^)Z_x!X#4OKbew>Lpd7AgipZu3lVQ z$ttU>s;VnPi&*92P;D?+vxtRF(GiY7wFp~fbGuWsc*@Xpn`<3BYovKb#l3BCQ>ZbX zG)%z_ou}03HZ`v4ao(J@JMki+wVSG`35$0MOi?i`BPmFp9=AL}QB~(LBg|H%W17&T zf~`(#i5SVSI|YxYwV2=uBMN6_+3GBh8oF(2?P=SaVR)0CYR)!qUiVZv$$JP}h#e^r zwMC5d>o5`tBjZhLZdv<~#UpDBNHjY58bgnzqjsdNEx^_o$rSXopfc73L_CgHx-E3u z@@~8xp*HOYPk36fI?alvElV?Wi`5y?bQ0558;{)1ri8`Tk?t02@Iy_?nbJdocbG=f zQwsh|z+24?JZ+Ilkx0sOT@_c79PZ~bQ}{P&z2bXVd@B+OutwFg`6jVl6B!X>jT)Y| ziEPF&V-`fKHplK!XfEW|rm+=n39u#uGvNU8FJ^C}$kDxYBe&IU2v{niM!lfYr%1|Q z4F9du?Dgq(#64wLnr)a_av*OtcwE>VNo~UM)It16H|!WOQbOmNWu=9M zWn9%`5S>mWAnr-Lv*~SsH+U&Vk%SVuE+d^WH5&?Lx@;A>Kd~s)995hGV|(?(x1M0=__`?g*1mej(T7%QK-pU zP>@=O7WJ&OSj${&SSvPFW$pV}St>9j3KYp2I?}Y$Kz$%9r5ikl%UZAko(x}cEJ+I4 znpEA&2$Oq>MGp0>vW&!bB2Jb#mn zhKxm7wVOu9QXzZVVC>+_$SezX>Bf!#HG6D|)UpDaQ6cn- z1l(rX6)Per+b#H6pl)7DS(Iuz6*pD1TP&XIZ}?4#VDm_`A#5`{w?oP+JSFA54j5*f z#Ii`FuA!xMb8ACmOWWp_`nHz3uSFtw+pu9xM#ZmWs9uMC!+cBqs!dAMMx|~QU%xTj)bPkRHg2ddqhB5ca&-&w zH_R|!yScHEZ&=k-&zIFVt!ijoxvH*iQ+-Rz3QX1GX*DjCR-q>UnO3t&Ms*`%0l1A4 z%gX_2D0&z)pV!D_wosaUr?YK6YQAD_w=kFQ%9gSw-IF`vDcBK_R(qV3+6IS47 zM$?z#M@u!4ILkM;u2pL0=8>Hp!c^+@sNq#0uW8rpvgQPuMnYL@m`N+l^_2H$Ee|cl z4-$P@9$Z@XgtAWP)TPNukNZ~f>OhSW6Wh!F7tez3*a`Q=o$p=V=bYN<9vX3Xj=HZB!xsui z_u(dYvCn;>KX+y1z01R_aJnl$GQ*saQFr83XJpbn-RDeCx%+yY{vqaXo4axZ`{c)m z@;j$yk1bg4^h_1b9n1GmV;9VECeOM(dkZh0D|Wx`jQ4UJ06Em*5$uYUc;)Qv!HMJd zT{~H!x5qp8(FAv5f8p{j=Iq(+j9+4y2}S(D%*}|DY<_`Acrr#(YJ>(qf zV^YoBm8<#vqaXb+$H^Nrhw>wb-Ld1)fDVMt_};?tm*6ZsJ12**2kDu+_>BANQD@?1 z_sB)&^bSECcVM7!b<&?$JhD4~a2zWTiemrk&e#wwa!#Bs?izJ^_fUWaFVDJ+BwsiQ z#}#*7albbKm-EQ1gwjdR>Dr4h@@29RKkNv&BEpMZ=g6zWPh-ErsqW%npM$u0!V!$Z znLhXM$^1y)HAg__`F+M&_DvV7!2M^`P_B#g#ibwZhPT}-%_w1Da_&$lwWDh!zFY&|AYo$Ey8YrB) zLTgJ$H+Sr4;p(%#8wy>!-@DvRE|}>>V{->Dx#th~EloP`(i!KOmywh(%uRUE z=QlDxVX5HcnXGWW#~pmpIWd#FI9BZLo9&DKInH_RN^bfD4o&WX7oD+-47pE5FgPiL w@b4YfU>6e0S9q>d(Xou@X7v(&_vBw2rnB4sPiy!e>$Qiy|M0Z-4;6Rl{{R30 literal 0 HcmV?d00001 diff --git a/source/conf.py b/source/conf.py index 6062b0fdd..9dd611c4b 100644 --- a/source/conf.py +++ b/source/conf.py @@ -91,13 +91,9 @@ locale_dirs = ['../locales'] -gettext_auto_build = True # Build MO files from PO on each build - # making all documents use single text domain gettext_compact = "messages" -gettext_location = True # Include location info in the translation files - # There are two options for replacing |today|: either, you set today to some # non-false value, then it is used: # From e76c7ed430e0776740c189720270dd2a345c7376 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 18 Sep 2021 13:03:43 +0800 Subject: [PATCH 0149/1072] Revert "Revert "Merge branch 'main' into new"" This reverts commit c3f7a25cb3a76444d54d086d282222319d77664f. --- locales/.gitignore | 1 + locales/eo/LC_MESSAGES/messages.mo | Bin 18402 -> 0 bytes locales/es/LC_MESSAGES/messages.mo | Bin 15012 -> 0 bytes locales/pt_BR/LC_MESSAGES/messages.mo | Bin 110880 -> 0 bytes locales/pt_BR/LC_MESSAGES/messages.po | 8 ++-- locales/ro/LC_MESSAGES/messages.mo | Bin 845 -> 0 bytes locales/ru/LC_MESSAGES/messages.mo | Bin 44338 -> 0 bytes locales/si/LC_MESSAGES/messages.mo | Bin 464 -> 0 bytes locales/uk/LC_MESSAGES/messages.mo | Bin 63748 -> 0 bytes locales/uk/LC_MESSAGES/messages.po | 16 ++++--- locales/zh_Hans/LC_MESSAGES/messages.mo | Bin 100727 -> 0 bytes locales/zh_Hans/LC_MESSAGES/messages.po | 55 ++++++++++++++---------- locales/zh_Hant/LC_MESSAGES/messages.mo | Bin 6020 -> 0 bytes source/conf.py | 4 ++ 14 files changed, 51 insertions(+), 33 deletions(-) create mode 100644 locales/.gitignore delete mode 100644 locales/eo/LC_MESSAGES/messages.mo delete mode 100644 locales/es/LC_MESSAGES/messages.mo delete mode 100644 locales/pt_BR/LC_MESSAGES/messages.mo delete mode 100644 locales/ro/LC_MESSAGES/messages.mo delete mode 100644 locales/ru/LC_MESSAGES/messages.mo delete mode 100644 locales/si/LC_MESSAGES/messages.mo delete mode 100644 locales/uk/LC_MESSAGES/messages.mo delete mode 100644 locales/zh_Hans/LC_MESSAGES/messages.mo delete mode 100644 locales/zh_Hant/LC_MESSAGES/messages.mo diff --git a/locales/.gitignore b/locales/.gitignore new file mode 100644 index 000000000..cd1f2c943 --- /dev/null +++ b/locales/.gitignore @@ -0,0 +1 @@ +*.mo diff --git a/locales/eo/LC_MESSAGES/messages.mo b/locales/eo/LC_MESSAGES/messages.mo deleted file mode 100644 index 8bed3f0e5d9095d1c181a3e322c3f063c8065226..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 18402 zcmeI23zQs3dGCvh!A3lc4TPsnO9DUEn%P~gp5qrQX(iUuuGZR>g>h_6?@sS*@6Jw- zyL)!E3gkf^#9)ZQki>}{!XpOb7>MIQViN+2l#mBW0F#G92*=6ENpf#;NzV1nJ=fgi z{{B_fGozJk$()?zBqww9>DS%$=&G;2`l`CV{ld50pM)=mpMfuizYoua-}L-zsPf-} zYv8v%&wZ)8ztHm{sB)LV^WcEzcKB@WcX;mhybh|qaY&QRjsCs?)sAJztIUu3=XXQ8 zZaxZ?{}b>P@C%TC<}v=$d;h0@{(s;F++RRvm47|F2yXHBQ}C7C*P;6V1MpSwE-2ML z1l8|jp1%jxp2wj2^Y?H7{v*_T*MFCLz5(v$egLZcGF18xLbd;PND*@uvBHc$-guH~eqh-vy6=b`j@9Il1`45jaY8rmtN-j6F}+nGAO&=2-Tk*{(ccE|68H#>ozF;eAqw#6g-dn&qC?@1l0Q< zg(~+qa1DF{YTla5UH+FsrC$U!PcMh6cNjhgj{Ey5sBsOU>OTU{g>U!iKjwKiyoTrZ z!CmmL;Z9hhGo$cUco04U*z!s%@tlzorF=fOiz;}$}-H-hTV3Y5QiH#`sC3Dusv zq2~SlP~-d{lpg;FRDIuu%KuyjM|wCPYFu6gl|BIVz6!jH@xKPj&i@#rR6ouuJN=A7 z=|6(chu;U)zIQ^k?*ovjVjhCB|F1yx^S?vs>)W2^P`S##0IEH&@Lca%_S_CtZWmPh z_jw+KYVR$c)1I?X_02=|ukG*O3D4*L$Nlqr;fuKcEL8o!1J8$Fg|dUcfa=$iQ0eEh z=-?{M%c0u63F6w!8=&&v1l8Zn^LEHoH9rSc?gZ5P9*5HRKS1^8NhrOYGwAyBO1PQ( zi=gsNLY2E2qB_%nYR^ym^bbST^8i$PJ`L6XFT;!B*WvZ>NvQseZFKd9Q1vcA_4_E) zxV{6bKOccFhM$GF0`nypz;8k2zhKDKvli;TS3v1yH@q4ifU?IspzQT0pzQl@sP*mR z5EC;Gz}w+t@B&!hg=)`}Q13q% zrK_I=Uw%TVok49ZXZIlL5Jyw&M*H`Mq|z?Z_C;Ck5dd>@oPei^!IF11T{X_LFx5+sBxTz((A2Ie)V3ccKtkz;BgqjzAN4M+z$1g_d)gV zV=#c9gVOV#L)qnvu5$Bc5Yi;G8LHn2RQulpFN8k@{}Mg`4?PP#V5Fbn{%;us@k7@d z^LhB@H(*2X)x*a8415BH@O?X+z5H)@1@{;2bmKD$)xKNct6}c%?|`zud!g*@L8$rs zFx31x4rO1D`ul%@%76YYr`K1*7jVBB>iG_+{)|KE^AMDM%=+~2fwG&oL+S0kQ2Fom z>7RsZ=Oa+{ei>>UzTxlx5^DVZ0jmDA(0L=i;Z4 zIb;C&ZsaGC;@9Tl^~hz&hmboF{eA`6Vy~Q^xRmP>qPaJP1jq?w9n$-o=H?FM-TvW& zJ&8xS)>wbQKfB5Ed*RRc>-#-F<|)Wd-hwP5KZxk}%gCFND|EvzcCbFsUs}Ac=jIl! zZ}#`U0k1=LAYb>-{s7J(2mJj-@PkN*ybF;X%D4O;@(M)1PaqqSbCKsDzlr=1^83hI zq>AYGYYz7R_w-yxT<=A`g5b*Rw=1x7;rY7ozpue&aRYN?6p@e8?;Xg!$Y$i(h<-bf z??D>KB=S6D0{K%!K5-v%H}ZDmw~^Zs{a)-~|G$s_--~=7atyfysUf)cQ+_M{$zyOU zk|1A2UWe%SaR-yaTagie|5><%EFfk7>>xafoQHhTKfBy>9KOb17r4=1{3`rIfBh5i zBmTMtuSfck4am!oKSI7A(eH)GmB>qUa-7cvmD#uvRjN_FUW%Ku zNi|rE@~{@>VcGQc?M#~WG|bzSi<4%yAy`S;mo7y`6}2F2)`D7`!GuZX6ggl~&ZMR5uN6s|J(pRx3$!Q$cT)D($J7;UJ3_ zTMY)osoD&;T8((dj#Mz+Zq^!6W_B>vb+p^8nVm_az1RectuT!<#)zJm8FwBvXXARC zfo70{#juHWEJn?|lOTN;W}$~UiJ84{zTWBsnR{k-xdzsPJYI~vvx|Aace`6MR~iGCrN|Zq1muJ7e$RAB)Q#^UYJUe895Sas4}yA_R<|%{Uh-lELv+iIvO&0AyHS#EJN-42w@1&p99GltCl?D@iVl-%H zdP%j~va^0DC@o4WRAMJjaFfcHyy|bRR?9`jPNTC)x)|ogvnVaDROdw8ikeHkPweaU z)>9t3PFlU#&fAx(5?jQjX0!xv(OcHH>!fG4!_8>9vEoMrr{?n&MKf1z1&u9Ms)sb* zS#Xu*HC3}O#5NB^OL4T!!0d~{lqr>@k=civ47}c{)Q@In#=;m2i*bTnE<}MfEk<76 zE}mU+7SYZ$Jc}A0>#cl~sFFcZe?OP=)Pd3nK8yZwJV@&nOed!lm>QY7HLIm58x;08yRZB?l@}HGIM}+CJun*-XwPt;kG9Gi{dm6)toW1#UszJh-)LwNu=(zT$}jX~?aWHnqk+ zC~jm_W<5v1!q8Psu#^RE=9@`7PyNDs@?B;owb}5?;?(}JeTM_BA{Ew$G+YUiS!QZV z7tPb8WhW(`Cck^68I*_9SaWY({s~4g9cEZ_JJT#+rEbJ>HA%%xbqr=X#t}@DGfkE= z)x?AggSk9!Rr>oI$xPUgqAS}51_sKu*g~|joTN4Uq25hB%w28zT&i_f^zf7f_GpXP zZ@@xTth&;~Df#>)S(U~n4;N{7LyS3A;&(}#2ABov%v+e12lu=sSdJPjcWiSzHl3u| zT1=LGr(K^LNuH_lNJ~c?Pq$ryKa((d%v=d{B5>5aoEVrLFR*7S-s!m5iXbY zmmOhMo#>=n4_C3tnl&0Czxc@B4%%t$c9UJVT2+3MgX$7awtBd@^_8M;=Y&{BZ}9%s zGw`#3MeK%zUAfgqo-`wKXpV0Vx3JVAwt03nS=YjwHsa}Z%%gI!u7wJ8cP+VDP2K;R zV%lu+s2O-i#*Qyp#CzeC<)CEqcBxa(a~4k)l~Wfo492cr%8m1|hQ`i0(tek3nZ+cj zmEBu3eDvP$<}$tx*wnS6gguj6uH04vGpBT5mo>NMF^nZI8;ijGFr>gA^|*)Hs~$Z^x) z&4-nBgY_wP&s?6Ft(z)aY&K8c$+%slbLZtGt@rEG62s`frh52r@Rp!D$_E}TwfQr= z(sZ0pw`Ufj+~#KcA9jkwHtV&Tp6%>v6n=@nWbB$neLITsXH#WS$ZmW)P2i=md%JUf zMFW((w|i>t3}4A{qqZy~FY|>{W1LvyvvQm~Wf%P@VfX#Ef4z0|yG|AjbE{vsD^FLn zD07C+^uDbq(({FMcJGo(if^jkN?1FB^}TQCR;Lmqm(}f<55qjNy;tegO2xaCr5PzP zYW6eAEL~@{R`+>f?=~#LR8(o*e1U-ez*-X?0x=R&V&VG`Bcv ztVJxVM_9Y;F2rqXDiu?mNTQrAV`px-m7>(LkFEQq<)(TTQ%E0t>ZPex2g-xxE!FA< zR=2_Ort-#Wm4_S4Tg!u7>M7@Pz6N@y3fk2v%5yo#iQifAEUq&t+3uco zCG%{Xvz|t@(s+qaglE){-a3}4Or2pr$VWu6C+&1e8+S>cX-lK?Sd+{*a%tp^{# z!y~5Hl@WuS}XZ) zsY)=y*se_ksRU~#_Ltld4WqjY6R89@jtn0t zjqNY(8V=sLzcMy@#hdq!kF3#|WNC^TGuFE#tpvLd?%NlP508xmSB;DfkM4WJ@UC44 zMkXh(A#1bV=8T{;6@`nvE$O&kzddJaXz}db`f^649e8KpygMjqCm*rH?NnX~qGZk3 z=-5cN%Y)^CH9oRXnzBbEIRn$rmtowzGMJeQQxtsl!KvM)ZQXq85n-g#2nX9b{i+1p z_##*{(IA%5DDCESIjaQCmc7lc-gsr;F0XC|Yp)IluUzw{(jEn$oK6n84h5Ua+i`w3;E(*NP>knhqx{-7B!RkfG^V3aWjR>_Sjfi!m;X7tb&}gEQIr&02#Lv_H3|Z zjdFqSSY4C2ANCG$^i{)%GZ^KjL$s%Vq?%GDl7Vq5;zB#X=s2AS8c|)w zXzS{ofc63N4gQpvjsTEN|Pl9)YaH#F*vovD$i&O`WEma)GFnL3*qr!N)#<)4xp$!V)@2p#n}R< z#3XRR;ncjDid)V!YsrEOnWc#hmFjcbj^7h!oa}`2 zW@O_NQ`!>w>|w( z%B*a!cy4W4sw*CNZ8j6m$Gm>?Lc6_n^~S(X4uL74z7!vgIR+yLmNxN+jo2s#7T06+ zXPd*&x*@})F{-016mm4C*Jv0Zv>h)n(sqQiu+h%t+?w*js9M)udrf>aEFt=}m~iU9 zutaZL;fZ_b+&Cc{Oqw|?WA=@ZPnDxvWRXnU@(qgOL~;j;k;#>(cn~Qaf!5^ z;q6mjA zle28b2@KQY?rE*zj{;aJ;(CZL@&~d~ga%UmMCIQ3$+{!I_7IZLY%V7F@q5VYtO<0Z zVRD($psld*p*AG8fN`?$+u1}QEObFJ4H^bIQM}Q;aAMd@_^8-e*yJP+pDJDZW$@rp z4L9mf9}Pd8j1VxkQ#f#^}5fq}yV&0|umXDaqgVq_GGHF(|$H?0-a5^OW!vqp~9 zR*4%T@^5|dNxRf?euTi6vudmkyP^i~r`rIYaglX}i%@u&b!x1_qTkXD4N|Mo3P#IQ3@7<4SS%2)L+% z^g5=F*|57gep}QDnhoo31LW11H0+FLu&KD#w*U1;&NOv;B4-*-oQa)JZWVQE#Wypv z%35Lbq{KpDgJ<;Hs*DCic2{K&{7a0e3n0*iB7`RIe?Xp?y|!1E-JsaDM&@PXTooc& znX_koX(e=s4cd2-r(1k=>26A(>CFM7OkGP}Pc!_}>zq@X4v&Uto>fardWF9VD6CFv zT|)dVs%yV#2jD3}Y?L{14}aJZH4jWr<`E~|3*9PkNLeyZHXZ2ZZH#Av&_vdYBEe;3@ zRJ62fdSpSZ&5p?L8hZBDKB9(~aa(7_WES{iwBEVF=MjGz!TfSPpw`}0b+Zx8+bP<~ zqFx@mzbCGC>=8yq3zO^&CsWKj{E#N|!K1O3Z5vjTiFcB%uOu*rTi5LBN#hyHU_WaA zMyub^~VZH()FrW^YWiiycvB-PN)CeK76V zBdg{XDSX1c&*#QC!Ka3T;Q)4 zQ1DWG>=ANMM(Z9U(FwFA&2r~07%gv+=H=q}d!%`LHRskujXUFE_Xb4TQeC*^(ygW} znJ!I#LWmP1xt%SjvTmRaO|t&UNq3#_I4;S#VOF}1TkJmVbeo2s2f239f z+&UX{cbv-ck2@B5nz-A}nB7YE^z}bL*lkrO&o=tDs-vq<*?W&ApW!KcZ_%?nWj|e! z;)|<07*E?q4n_ZUBX6hCD{in8%Q`gxcLt48_!%ma5@)GD)$NY@cXhu?yNV^ttzK8EXu+9#$17HK@C<>h?h6#jI-S1H7>heYtNu+xai{4(_XyyrPn*wD!QHA> zDS40mOR%RN#%{slO=lRElM9&YnRNUgD;{^scZHU4e;%U`b_M19NrtvW&mbgs=IQib z5xHvh-zg%eokrAT56e-5w$1E)*-ZCFRQ@X-M1VzAZRgCWc1CjX6wg3PC diff --git a/locales/es/LC_MESSAGES/messages.mo b/locales/es/LC_MESSAGES/messages.mo deleted file mode 100644 index 9be893d89836f8ff008517ffc8087c59d20c36c3..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 15012 zcmb`Nd5|1eeaG9zT*AgkCLHE!+r*ZZ-H|NWMvMp1_R6zw&0g4ckP@yn5#QA*R zdp$F&T{)Fhy7cs&?tcA_-~Ic&{l=E_KHzbEl=foUc~AAc$HDJElmEE>{sPZCAN(r# zEb!alOTiz4&j&X@+w-0QZUZ-gJHcDP>%r%M9|WHZeggEtFM#U*bx{4k4ZaBccZU~T zXusbEK8@#Z0e=pB2dHs=3)J_Y1786C5%@yzZ^4Vfe*62DPpj)Vu|#@9zQG zn)e}xA9wf=sCm8wYX6VA=RW{{p8KDHyTHqsRCG8B^2oa#d=$JB6#b?k%FDn*AdkER z6zksV?%xHnRPU6-2SNUMf69OA|26O>;13+0&*Jrb4176w19&;u0JYwCg4@6kgPQ*l z@DlJZ!Sld>bEo&Y89&t{URgRcO!?_J;w zI0I_D_kimE04TmZ42qur0E!k-VAEI`#`PhG^l=m4DJEH0?vaMF`4d{ zz-z!yg0BU?>2Mc|{51D(0~f%nV1o4gZcu#v1Sq-r6e#)nqI>^kQ0x32sCE1VWJvFP zKGyoSf}-yvDEjUP)&Dk7bdJFg{2aInUW_oS|NB7ozYo;7p9V$GFM^WC?}M7>A|IIm zw}X1V3)~034ivqA2iyUE8AKGl{{*iBw;*f`;mv>_I>+-`pycBTghhD%W!NzAg`oI; z6ck_H2ukkX4laZDf}+b$9bSkq?BxFCpy+heVE}5r;|}ium$-ib)PA=x39Rxi2G#Fs zP~RU05moOF5E1cKK_9#qydC_kd%u~@Yu($x3GfA9weUfa?EUhd%WlQ4ff_zaAyDi5CaC>>7nGfQ z4Aedz2Q}U%2JQuqgOcaZf*SYFK&|7)pzPC2D|UaApycUJkbmCW`47?Z9s;$l zuYy{~KZA&l_k4)*D)2gxp}ZAP{P-9sdHMrT{T>BHuOEZj_qi2pU-`Ieig@Q;Y3X`7h{}3XAVYc$P~W{DgvH+HLCy0mQ0spjls>%-<#;-H z8~98x1fK&Y;Dz8_py>2oa0~b`(Ch;gT^>EQ2YA{ z_zdtR2!Zx-IjHZi0ky74Fb6*ZcEHWMEgkLxHQwEz_IV0~RNfarw&wi+6kRWY$xi`i zK*`O`;4NSZs^6DE>C=CK;@eeKYv*nP#s4>f=Yaa=%uD;w^+8(8{IWdU!tWQ-B)__( z{~KLz=i!2TF$`<^myOSn9y`RR?%pL&4OQ9~&kL`H(>1O28{*Ji& zn?T9sYutSaAK*tulMI|k6AjAiE`B_}ym2TRi_gC_@?7#UdOejJ@%SAh4_Do9>B8AA z*#}+XpHDkP`v^_fk_Gese*S-#yFcdeR~(K)j~nTXu9zly(2=^X_6mZziz?&KhOUk9l6)fi)kMkd6w{7GFD!D_;G`~k?!bv5AD6Qx6<~}bRD)} z?Ah)7zK14VEZpw(Q&QTqX&2C@XkFUt zXun4LFzr`q(!KJ!ksoiMO}hs*@GAFPAUk>+?NZv)X)mGas?$(k?_L_}Zmts!rL)hY z-AY@eJ(u=QTAQ|;c7S$1?X|RL(sbQy!FwC{G}?A|FSv;Ii?l#D?m7y-fc8e(W?D$w zLDThm3&a1%#`c9lGwQUmu`zFK>|oKZhpGL2I1By2Z-t#^m`-%UB2RIdBkAO6R4>dX9DUxv)Q4x@ zFz)w~;)*n6+%D^d5WHVX;y76~WSm>rdqw8g_9V^FPnP^WNvByf^4cADRJ=V&T(mnt zyPb42$5PZPL@CzBQ+umTw!=JV26>=|EIv1H?SdSUqs(s=ut7am=wY@ObeeqHSPnW- zL!T5pXS9-YLu&1T*DyZtYqe(5$Z9pe8KrC{fm{)^V(Dx$6|cn;?Ql7XoAx1J6m6z7 z>#ll(u{z;u`2kyXGaw_4h89vjk)&B_X=#!Hf&HjZS9A(Br_* z!z>@JdibW>bBnIzNjn}s*SsYmG;8Kf84^IUJZgvDRG2l=s4GHxQ&H9^G9xnHng#fI zud6SU&K0?YsTD$-W#nI@&-LcwG@LhpLQJG)hp z>R17x0_H0k%R*-In@Po+?qnjlZX43fqEqf*DNWjDM=ZIm)yGjM+^9d6!9Ppq6M>XE z^QKY0RJz;@yRt%^M#R&-V!JgR-d=Rlk#1+@m7}-2Dp#$&z1rM{cI;}^n+bCx;0t+> zN)eAn`Le&zU5+{@2JbRhRCK)=nWq3LZiii2vBUERv;a%@Qew(p*>aLXGwnQqf{?fr zjg7vM8fM-;sej_LB!8jkb{W9i-+>Kj9>KmK9ruriVOK^IF+k=dHDW*V?svmP7I1Yr z@e2&Lqed2@>&sy~3*(hA6YE%KD-GIhtb4^@MC1Zz^<-%B<C6c9lRifDpSHf5(J*%)KWP-KkAwRQRi#Gy* z00pt(G-ieUg(u4QMubaVyKlm@d@BK+vyLTO^DIJIRz{yVwz?7YotaqfV6>Zgcx2DQ zx@QTbO#S^@8r(W_82h&LHY0DH$yoD6`D~pqj1FrQ8j~3J5I^}S)U=Ro?vWoQjZuCYLm<5@b1#dSb)kd97^x|)w z4H`b2zJ;|q_uY{w%oTM6#aCE?O|-Werm}^TIwMZvW!gopAqInOHRg^R{>Zv z!MezNv8HZ}Co8Fqu%Yo8M$c|7@H-|Pm4!mCM98ZD`pa&+gK>BOmy$BMtE5KKt07i1a&CA z5)sAZdAGWKyNQ;?=<4nrJ9gNqU6SGgPLy;Yy-Au~;==+wdO(X4v;?JG4SH;r_&$ug zK9S=%;-KgOA=5&LDQdNf7CI4imXbA@g2F}(k4Ms`h+K@0jk|!U&USgz#9~L<1PPKG zv7{OwXN+vtv7~%M^DsSTWi;%!Q8%=Jccn4%yVgVz2pwGx3AEA#izRiG$_6fnG&>vR z6QK*%&+j7rh7UnkAEuE~f%S8Wq!1t@1;Selwq=FGcvVr(<$m=LbE4qKI90901{F^7 zMucvt^}%pI&elO8ys7yQdnxlz)NEp?%v&r-(4rvDJf-zDlbF}Eg3?6T7^$k)OGWHU zo)v8$HgpNl0W5c(91lC?BP_V0BDXfiQQ&5~yD^7ROXeMMUh{~H3#Lcnf+I=PK(G|q zqIaI*iCH1RgM_B^7wwP$*~CWJEE125T*in2r3Xi_+=LTxbUduuah#z)gB%KI2Rz8} z&7?=oCM5&Q9-NJaB)T1Ax-s?Ej1mUw4W>RpM$k@@X2s63iggp$hH><`GE-O9&|A!j zL@@AI%w`qBlj$1~3P`%8og%<84liakgv}j4S~3~da-j4BUDo_TCtEeqbm{k1hABl? z3MFrHl!&WU_2)*cyL;pujQqobbuc%}!AzRG&pDW~>rgi2U^F>INaaP0zi{2w_=^^M zl)tz&%)HuM66V;%>tt~iQ>*1J}#8o9NhY)E0KZOR~; zT8!2FreadctX?>KP+_3b=4%{hTTI?#$`FIHNUdf)!I`tg*bf=Cq3{}uq=AWfimnkY z#Bt{NG#@HIoS4m8QFG$PqLoc7CRKma+@T3Y9*RsS zRGg^#w@y#aPs|>gn40wW9jeamf5qz#9h}~z^kHH#MU03t6IQVI@PPyV!O7Wa|GMef z$^8djGdVRiKfSPU16@00s-ih7A ze%j9xRmy2nOyhn0-SsHnG#67LizoIHOcObFy5=^!e&@Bm{ds-IzvO!V%4;{>GBFd9 z8Ci-PwHxxUs_d>@IY9=yiNfe&|8!o&iK~+KA0{n!H-~Y;vR{Nqc=0GsWIKs(Dbl3+ z)#~5R&`E}1bwZL1QUc@}MKx8_X~jGBK-DPxJzbl`&X@^;EG$4As@Fy})x)X}Fg%6@ zqQiJhIUleHr4DSwmQ@o88&y(_T|4kyZFMCX_YopLJQk9VbHi6b+E|WO)ZL$-oAu3) z$+^Xfr-{;}rve|&j1mmRN`hPhx{N&$TQ?B7K;@drPX822gwtb?7~`o-G)P8rsPThVzP^f0Z60*SAA7gXyf-Lhw&!kLEI8y!&!+x zsJ=qlkSHJx(*7x}lJXW7MO+fmo68ZeFtt=*`wupwmZ1WcL`B$uDy-d@PnDJ;rK!i7 zDyyx;iViFpTOKL%g&>G=`Kte*LI6VqXNVH>o~=aeSpu(;agW(0MU>r({%JEfj=+uF zQ+>97iu!C|zYWrLWTqZuX{_RgNi#jflONBC8p`{E|pFT%j_k+AXPXfq=7otpWP8BU_~z^t ztuGDAvab1xn>tpGKq?|u++c+V6F-S{xM9SJO=Ht35J9RLpOq@OEpcC>2>#@eR;%%nr2+ zESq6+JIdM;0%9SGg%Wxz{>WT6HK#n(?dpV~&;!F@kJ$Y6@0oIH#|>1)!y9DFj6I+OR4Y6cy}p3n1raT5ziGyPa!RK9-)!%#;6)y zl|faJm}PYPrP{)6x|sbfb%1*|gk%oBJEhLd^H#Jux}@3m5+c;X#`#XCqRJFW68HaxR3A$N8X z*>g0LVI+63i>osT0-4BQsG5u^!ERUl1IUmqCzD~aouLWC>yZ)m7z7)D<=|uL8zfOk zl|-E*HdT|O0F#i7Yh77_3uU?>O*t6T4AO`+p}Oomjb%?5y7=^v%j`KY2eSVMzx3%;BDFza=3=WvqN52AQB? z?TQ#e?=006>?`CUl|#UBgZ=wr&eH;(E0RT8yvhD&ILzdOIH)6Oej`>gBnfr`iJ*>5 zMx_e>PGvv|l{bTEX%tb&#v|o15+m^}Fx79vODf!LR1PKXKX@XNj2eYk;d^?mDRdjO z5f#-3mk#npnZH|+_4Wob#H8OVHrzACapN;(QBx${)yS!fYilLR?H#E#`X%GbD??LE zYU_Wop(B=p+9!f?j8oKsfZNRv13pzw6n(6hYF9C5a}0C#Zo>*X{bIlWE~{I7Q;LQ0 zrDZHQaJO2SlowX41f7%ED3aU=-;>ySf#uzxJGL6mBbG7~WFK9*LlM5Lx*IxKhZ&^X z)^SejaZ*_p^}K0L*b z?KC8+i5_jSo>>d|%P0Mk@Qh0RNX6cYu-QtfdwU$`4f{w65T*XZD&;4xq(8Jw@}Xyj z)yAjwAIu_TXS%GO@rhX~B*R)w60aMl5sCLM1ROmZtWP-?En3D3l?ELSuZj$NY*>KPQu0u15Ksjmbh) z^+$RUt_@67ijQ@X8#&k7j*7ulStbft`+~b~-SvA42;$_J2`I|*0m3qZK-CpDIwR0o zF_EZvI1;y)DM*!!jcPD|ezOqr7cGjI*9n^qcf@g7KoU@$D40OU+OlraL!zBmp_lWL z-ZV$kj>Tsj9*n*k6re^Qmc^veXSQ&}5$su`9c+^XUfDZxVdJV{SVg?yqAFuZoY+(} zAP+LRi!}+-N}=O>2@H}UkF2Oo#|msw{?8gzWA*4$+BW}@2fF4&;gLV&FEu!1cR}%1 zbB-XPE6)~eJZMS*10%cccwrkfClFRja!P-<6ch4|s1|=slLjmO`wb(`a=5_$%Cm)l zRD<}`ng*Bk4h_nXb~$Mlf{ftUtl60ngwF+(91k-IYnM1_fx$0U9s>7vax;Jub$q+;y~ zpmx%YaBv8MstTM&luq7m-IZmO+lVO3oW@$>kfpN%tzE;G#)T@oO@`>?URi;z*gR^` zPicz@O69^wwpjJ{4FemMk@))(?D9|oM&q8rp+(4XVE;5`+b|6)gNdScVFZ6LWqE+H z$7zz1hW;r|UsNtRY+)=57WV310ZtD$)83Xw-#u~7t;NRl2oUyMjnJRI2>$+Ac!>aIXAjzFTA-#z{H zA2}b9Jf|#pZ~c|SbUC23)Ot`;cp}Sa4E!g#S4lTHu+dl6wZ4{>Q_tZqE{toPJkzy~ zezD%U>KvjV*co`xGbdT^C(CmYr1<}QF49tzZbD>|Xq9Q85sVv=h;q{=VHybu#K6*U zY;;bd3Q_rIqZoog5vcsetJOx2Ox!}4TSq2Fm7J4RGR_kv?PTKrkLM2qK%n|NA@V-uGU0_mH4|{-4jkKT~t+ zy?XDyd(S=lIrqNLpLN=c6aL;Zlq8P?KL5-l*?Ny8`LBoTEPszplD`2A0f&Jf13nsf z&vTRH)xZ_N`vcz(ydL;r;F+{_@p(yd2giF?CdvJP_gUrbKM43>jz@uN=MvyUfYZRA z2R;pWZ{SSNSfZq=A#{u4VwYT@6 z03QR?^VbA82D}f)69H}q>N$G?JP_dF0G|L<|DG7&On@EW=fTTUftTv{^J$mk*8|HO zzh!NboCW+G@KL~T0$&7tKq*Pqaox?pZvsET#b4n3og+z-a{PwTB>6bUe>RpRJAkhm zPm+HCehK(8onMzE?*&%YC&{ybkKT|ZHQ?)j4*=eGBY35qhXP;2@nbh7$psw$3Gf@h zWFkqP0rN_w@&w>LK*pPa*8pz>p1wOtws75ZfJZt0lgpCi0PwMoPm)cX z?*mT*zGaWo%RBc%W4ez2z5+aJAGqT8?*bnSd>J=i1AOo0N%9$ff7l@(-*5ijAAw&3e(?(M3jB*JeIEY>_&|=o3)J=ZqtojD2Y{lB7hDCNfG-7V-k*JSk~|ss zBB1U&^O_`iIPh$s=64HFoaOlI zKt1>HFZuZ=0UyTkF`%CFLg0gezYF{Y;0J&y@MFOH0sjMdCQ!(I5a0p8M*+_P>i4Yy z?gf67in>4DoI+LzYO>g;Jbjw7{}iL)!$3&&hM84 z#pmw!-P9s_>;k_D{6k>v+9Y`` z@R8Rg$!`GP5Bv!5P}BM2oH@te_kc`gQl+z^`*#5!!1159ljL0B$ARO(9{| zM&Q%A{vseGlDwbJGeyZmI?Ng8d%!D!KcQ2iyDR(9D!)I4!GXf$Tfi>>4<2Ve_Q+F^U*~dzZ!TB$FKQyWC-vi@IAmgfsf?(XS^Uu zAob+to18y>0ua9{-)3OFi`#91bhT=7x3qRlfW@x2dL-1 z9;oqt2q-@L1n}O#e+1qi_;0{Z@|^zyLK?}(UW^O??s|#O_bgEN9|!8bX8_;9_0I!d z!tq5f^YhOJ-ofz;fa=fgmwP*PppKsdJcIjQ3ltr{3F^ssOP=|sD9i56usOD)ObD%6kfgoJRdmpDt}%H_%M!l1GfODfWphoz%{^+0Urtc zF>odD5wG@kwgVr*@fE*lwAG*cI_kiDV zdVLg7 z1NU-v7^>{vHJEaC{!{fxwpo z)z0m}dja1A6rX(%SO&#EB=qu-&ucwZs)kne;)<@ z0C*nvefTevF1w;KjQd1K=tF>AA!bz_hynb{!PF&z{dm610Dm4 z&R-3@C-7asO~Cg8Hv|6@cs6k4Z=CKA0@cnn!1n`Nz$3t6I>%Hd&jS7u@Iof*HsGs( zUEuDIyZ(GH@cs0E_!ICf=fC+$=f4mCt@q<=z=w1GbS6#m`fQ;1d;?JZ+yi_Z_s;?! z#_^l}j(O(zBvAPN@TaknfS(2G{s(-<@p2AO?FhBwYy8fL&_47SIjqfjj z8rMgGqMI)Rb>G*3_XU0zsQZS#;P^TNsPidM^sxr0`^rGc{|&%@=lGw$=yu3wzLX>- zj(_gUZVz1uRQvx56kY!SxRLuhfA4nbo4?|}AO8o}ug?TNgzMe{JO_9uQ1kpXpzwIw zSN-`94)9R{o(sGmzn6d-|K@OhM}T{P>i^;J`x6433a}O6LV(W<@TLG?5#Z~A8vok@ z{3D?7_5J`q1k`gr8sH}b{B(ey2daNx4)9+C{2p-SJ-GKDT|S=w&)@+(T@M`Q`saSl z=lNa03poBO;O_#@_&U7Bb$bP4b=-$Jf&eg^nD zj&J<7%kOjl!{z6H0_Qk?>^nX$UjbIQ{@;Ob$~$8-4_?x&E_1=6PH<`V(k^`!2&6((|uI_*Ij+Dq2y0Fe(dQ(Ca=GS z(rIx1Bu*zHA}PV-&jp@_@$gcvdjU}Nbl&}k%&z@ypzORK0`;8z7-8bmqa0L#$AJF? z{9E7~`ThMrKa^YwY@9Weyb}112l{jOVMI=Iyz&?6AJ@NtNs!&$r_<8QPk-2u*`2pN ze8~9fZ-AoLF9JUd{2mY%O748bkn!*9G42pC$vc6flbaqjWOl>LfVwYz^pM%Rn}Cvg zR{%Bc>w)(Leg?=?CI0|C9r&ro3?(!4;|svYaD2(x;1f6loB`el)P4U16yJO+!27T8 z=bQ(8Fz0swB?qnsJ{ou}Q2g~=p!nz&K=tnpz;l7`3+KNQ;5UJgYVuz|J^w4``1L;m zO0GW`r(%kE{}xdEaK*|Y^PjE;s@=Z?zLjx&1t`4y)@pywtAUbdCxK1ir+`ld?gaV2 zr}Mx+0-iYE;V4A@*BpNhSOdPhG-UQ#T6TQ2fFI)gCxPz--aI^Hbboln=lAiKKQ=a$ybAcl@gcLfz7IT;<6(@i5#WWuF<=WQKE4HbFW_xJ#Sh*Ayn^G(#v${g z{t$RG=O02a;2FR_+6-QRTL@ZoxbEgH&>Qf97Y>Saa8sF!1b}{g|Tz3Fi1%7(J)6tg8hm!Ad-4UShy!W8rcOy{! zdOi@6PF@PUH^=XS=|N@k0ig8fj}9|Fj_+}V{&D=EEByRkASOX_5C|(Jr7K-7?0LeF z`Omil>2mTV;1hx6tA{LZ@Vsk$90xclJyr(_FCE}{z-Ix4&)a~K%kKl81N=ca|L7+T znVud2s=qsc;=4V-d%+)11d8q^aXQ7%Uk5${c)yB2ZzWLUUI)B`eq9XQ$?*?Bn%aBZ zvl zD0%W@pxVC=!clbdSfK8o0G5H51J(ZCC8)r43E8qvOb-I5<)A{r}K#l*Nb53XH0#E0< z4M5S!g)Q&TLfhr{Z9t|Vc{gw!_dN_I)BNrOiXN)K7jXQR&QS8_zze%W7AHEr=W^z$ z{UP%|{sJid_~2th$p?UU0v`|j)#F3SUjaW36raELg!9K43&7d_qi{jI+;lzfo$ z4|xW95%_5!Dmf`Xb11nJxb|7-LEyK6?*P8)*+a=L7-;`-_|lIOYJy5sq-uV3=( z&gXA^!I1e^PrPZ!;=OMLO3!b7q0`Arfb!371`3bA|Dqv_1O7Qs{5kp?L*_4U0IDCK z`c0pw*ZkH{vV!Bc1^6)_CSUTOK9WI(xK#9j(5Gx<-ps4&*b>8U+(mGGI(4tDr;f zfBUPwAMg2XmkWOaM8ze42b8}3@oR?6|9I%lKK{#qqVp#Khk?%picj7JlwSNhpybBq zfE$4iyT$4Ea^QV9?gE9!rvSeWya{*|_~hRiGQaRMzy`;+zSixJUw9pQhT|^)p97qF zJ^Vrcz7G5f$A5b3P_h;H<~I%{j|2V-P|q#B$;VR%iob6Fir-%dyn_3018RKt{9VSu z@uPqb;CSzCL&-(JCjzCnUkSV)@NGb~^B&+@;75U90R9As$(elNcIWSpy~VHpG*EK! zt3b)S{|x7c-s*DZOrW0kSfJ*0Jix~VxEEOA{MA6&G4BRS-uxv{c>FF<@-lgw)8Tyr zJTt(vfYS310jm9Tfx2%D_(0$V0qzHCoKrwucLJ#XJ`1SpUkFq`Uk;S~dLvNddMi-R z|6`!=@@GKN>*s*F?;nA}?>EEwGv4m>@gSh?dngdJn+>Y@*u{6VXMnPg^!I!|SM%E# zP|y5BK9H~diMR9z8z=k1IrZ}=eDwT_`TQ22NAO#fPa3YNaZZ2N^O2l*9Ousliicz; zZR7aGK>ht5pB|t8L z^Z78pO#%CSihq(F9||W>btW_7?}x&*`vd$|_~Fe!>2TRs`rFFyPvP@wKeRmB4SX+! z`@YF{)Tzni{}Zlxcz^=q;rru&59d1BJNldDbByEj`1}&zKh8(8^{@Gi@>$@czdFA^ zfzJ#0NJr@JMST99&#!SV{(X)wU*vI*w6Y_9uIJG<<(O-&gSciNLS(Im!nU!hC~TxaOmrLwwucbNK)Ld{D>9PCj4d zJ0^hTaNffAA--nU7 z|64wn@?C#-@_8kn%^W|S&oG~>IX<0_{{D&2gE)5ypBwr95I%SC(cgC*Sd3a<8{v3g zfTwW}D#UcnH0SQi=SGeX^SK`%)OqqH&OMUPm-&32&m8BD1NHZ2zHb6v0DKqlZ*-Es zX^vL|F9QAx@Hcdlzdv$dIct4w^LaO)Ki5I{I}yJC|A5b0+ISwHXNU6-<-2syAM<%U zpC5(uM>(&*wS1n<_Yph7_Xh6a^CHe+e%RkNz@O(c!_iClT*>!G0B-?K0n5N&;qybj zH~HxAQ5-)8IKk(3zU%L~0sa-=FXHn_K5yjH;iJC;d@#K&=V2%K?|1oNmf7F+0geIp z@R{TzyX-pPefhkJPlHeV!wj^)dN^@;fHR!0^8Gb@p1|ild|t+94WGZ~^E-t$Zsz+A zJ`dvj_xYS%_^r(G>-gwzJD=a@vx(oorxW4tK)8M*$C!y`XFn47YvK353~)SLcOT$` zId@Gs|74DTp6_o8$8*3d_&kmC>wqr-J{@=&aDva<`L4f%e19XK79aiH=D_U#@YQ_8 zf8^lj!Zla%{YpMB4;Rb__`CrBIY5D1`E2372Lk^=C&J(PoNI>m&IPtOe}6vr$X&j`Q$I^R#{`!DhNAm1BS+zJ0Xw2-#y^;%cA zb^5JxdgW}rmG)-q*@ca68lFkxlMCrYr#?MVnQzQj)^eSG3Fy+&It@MwOC zT?$R4jb3-4N9APYu4c8jGM%qZU00oqyM(X3BY>N7K?Mr*oVN$2XlYOUI< zmXkGWws+dyZi#NxI}EFy&eU7=PP^Z2F05I@&pR63seZRhFS={iq}5J6oo;i2-qSCJ zf2>h!v}V$&_S}4@&S<-hV|9i&-R{hJ->Z}Deh*Z|5rLce##A}oJ)JJJ`zvYi+J3i} z_Bsn{2gJ?Pdug}VpPo)@?N)tl+O5~qiCTMVqB1Mb4#o@?#nt!BGgV*vdY*qrXP z=a_tTCALBj+H-Z?e|)wvHB0+b&3>&u!4r44>eJH=XhE&D)4A$(_4IhVbDg8Tnr?5m zdio6{_BxHpzD?%7de5#|wSC9F)#~Do*av8_$CZt#ZaOtvZOzo_l?b%eYc7B=d#)jA zwmwHUGNPK-RId%)(-h6ttH&CkVyZedTd(np(R3hk?mSj)Hkkj=mS2|6wYjrBO^4T} z)mAO-)N6g{L0D=Zt9PL8l+i-%%y6sT?K(#3qaLEk*w^kscpduRZ&o`z9x|EkH#Nk| zG{uwksVb)mY%^Q!auybe(*Rjj(}t#F@kQlKR2)0^s`57RB%qM z-YK=}{T|qYh8LQ3Bg`v14Q_%!gv$;jTkqKUdbPW7H1M*WKn?&$H;#{tZ{7r4$KQA| zx@lzn==j*Cjbj`5zIol~`tkMaMv~FZqZ>A_9|Nx6uyNgJGFIN0jE#)0D~*owPhU5d zMmCj3;@8dD*U^#u>uCOUEPT~H{&j4_hVhZH&6{a#-Ny0Jkz{Oq-MS5%$C9yimiR59rT{KibQJtG_B8eI%vYgFLNcSgW z$I?n=ZlO9qU!M2JR4Q~R>wX-Z2%wd=`M;A+^y;0ti3-okL_;^-G9W1qxD*d#jsu-* z*ZNI$8y<~lapFQrWREPT`z6gYWwTb&)^H~loS5#n5UBIl%^;JSWyrI0G_+e$TM+}P zxPI9OW(}u(Q9UCoK7E2%uIZe;TlekWwe!&7a-&r-rcPUMch%%bI*F+6Ea+hc6mP0v)M2qhF+ja1L@Co}iGs;0MXY>8H!uJ)S}=uBYfi#IX9 z0136{=0IP!oZ1A_S~kbhHk#W?_P}(@Y_B)pofsaTL7Da^%iKLYzc61N?iyV%FR}rK zC!6ib;kjxTTn=Y9UsO3NNo_42SU9jX^?NeWefQd?l|_iqD7y8|G3WqoLUWiOpiV(oCz9>R0)rCX8QgpW6~PGKz&u4 zSVnBdQBg{!TZ%^)VKlYc$I}W{SqJ6PtJf+=(RNTzr{3gBItKE`Mn=|&qNJPhzStD? z+U;hyf^O~EUC?HA5|V+4C)dZ-ey=T?YRc@)LYIm*X+)YVO1Pc=V-Lcfj)qON z1oJdG)1oCTHL!hmu*@yk#WS-gwFVLa4Lnmv!B6%ZO;8Gbx969|tT=5RD-L3U*X{z# zYe4^+BCaze)9HZ9oiiA4TlgQ8F)>9f7k^rXt(9T|O3*r0YTzrU2aV(6-Cao`nm*L- zcaWO{a(ER_T45KgV5(O8bU>*cB=MA{O~is_TFr5=lwD5EM$vMcsWKr*=Z?Do^X=o3 ztL+p*mND0<&o|`|)YE$FSfkT!8RIbF%qEHiSEJs9qtFUDuEb&WbP|mdRE2sg9am+n zCbFxIIX$E6BEm)@1u+HlXf$$XbdL#KlN7YrYfNJk`TfyQ3zTalVRwKtO+MC|1X3Jh zP~KCB3x*`gScjzS0cbNrs3~w+$kWaCaVdbo@pYzVAzb{PwyBa}ji=@Lg((vo5ZYmB zenyGPMvJ)gEh-r(mWO95BQU0vNjF{9DA&uh96FB#sh_|kHU}uqJmxtgV_cFI=3#{< z#ti-ASPHUO=W(p;5{ZziD>UI6<7Gv^#UMJ}YI6ndh1<0H2{eb{8oAvaa$Jlc+0@n4 zrGE#11sXCniDe)>7mTDW>&Dh!gz!Tt@r#Bc5@LQ0!)7bsX*tQs(~N^|G#fqKVR@F= zIGJ}9aL~kY>En>3LBqJABF#`2!5TFn(Y9{e9pqYf0hKxDkL{sI`}pC@4hr0uPHUUb zg@t`!=Yf<#Y}6o%G+%4fL>r46k=+ol8z6^M%5Y;8X0vQgi&Ww&h9GD_U4-B6cLJD-ka@WHz}+Vq=5`~b+OSik?O+L_yM~Bw7OmH zle>fhA)Y|c^;$XI$#+GB#4pBOG~@QCR6)2<@>7R?S&V=9d<(PsZICZGh3OI09=6L8 z5=Jzm3XKaO{_%|)N@B`pgAhTwg+u17QYnkLJ<@}TMp$dA*X|InqT4ew?l*B!Jw}5F zq-?=A=)~tJ1S_A(8EE6F_CT`-hTf1rqBI?wdrNm zV>r+}{4&>>>EQ(e?xu8?A6jiewxM64Sh%^spx<I0l= zg7*BeKGuS*UYPEpQn@ScUe)jR4ONx~u{m|myi%EW|J_47^9!k2=#|Q9C*v%dn27?> zh^CZKxu{hUVOMfa>Oq%k%z<4bQZR<9FhHC6Z;(vL!Y1evF4V=LW4buAW|z@T8h@Az zkKYAdBnK>zK`?k?c#pPWxjtbb$d4$Fn?unDS9=xR$XE*YnZjb3@mI9c2F#uAFjB8x zil`Yr#{)+es)Nd`(UOe5l85iAO^Ny7D~6V!ICD9K(n_V-Zp|Dmv~o1Ga#XE||3Y9X z>bB4pp$I9aN~H&Z4x@$%OM=>Pe4^Cp_H+y?!YQI^*C{!nvnIK_gfq;)MM~i%G9&oX zvPx*BQ_s|2?Jy5WS8?X>>Y^np$=row6lCDunR>ZZN8e%M4x^Tbc|MSEs4LN$y6MI( zzhcG`()FOYS+=MWHaSv-E=#eraMi-)kN$m7$?HER<{5(_ixETccko0EpX^sNVM%xf$2FgP>NN-ro zXiuZnKM|aD=8K#sa!-kq5R3KLZLLA9Sl&#E?M`Nur_sroPIV4nok{PuW%XThWcO-` zYa}Gh z-Bgq^rw-&Jn~8`hZeWaWUL2EPJx~$}G-wQijb&DJFcsu3mF3`6(qqh_d4cIxl4V3y zAYN!Z^l1l^lI0zLikFKd2{W%L%;FZN{}hRlutDx=?8TnNxz$aUJ(SsH#*a~}d7bT? zYh#q5-C-VA1i`XG%(kM~DiIMy?<^Z`319p+%Ox6S>L=zQdx%_ise2;+XkwBIOVE`d zSz*wa>4i?F5#ylGqZV0|Ww%X0jLBBgRhhwVDWYsVQjR>cnsQPORozt` zD3XwE7`hUP4>6&feWnW!c+xE0t@t{Dpyj+XoZN|+J)7|cPgm~OW(x^T2S zzCxr0s(=RH_Wlcr7wMW$*`#6QkG8OH5OE4F~~6mYU0(Vb4+ zW{lVf-7C7%=#wBvWUWIS85!)j8=_C77H$`IC}n}iP3Q#z%#$R-NqZjkWC4iiq&bJT z(#||I)k$kiys?}$+-V$Bus$1RtKBNWP3@LU?I@uKsg;L&ywzN9ENw^oRCcwe8ZmEt zmbjc85>hS*2A&n@Ap{!GjyP1s1d-FeqDX)#|t( zlEl^YIuejAD^4*D>F%ycV@NgAAH?l!N;8h(k#Y|(^siHBeQ;ErhSgV1r*lfx5;!-y zfIM+c1{4WVN|4v8&QrB!7|h83Kt?I5y~?X{Q10-Fh+Hw~wU7oX%==c&;+F6M4$Cy` zZtX`Rj9M;xrVw<_^!VFu)~^S-6H>Kz1FQ`sl8uPBByRbj?wB#S7Upi-$w5fD8S zU59u(wn9NRuejT4axg)jnf*dsU;@!y$kCX7cRd}E9*l}GNg35{88mg2IuDmb|8I+j zMf8hkb5J&$Sc@q`_`?XA*~m;5u}o%DSneI&dl;!X&{cTC$|%7Y7%$NZbvk0oSODhA zToWlV-@!Su&IFwg67mSMp+-^V zAjwwB-`qAsJW})3O_ffQq-oa0Cb5QQS_YqbdFkQ3dr}G<=doC$|4}IqTX1Yxnjc>@ zhTthDx+>J*ph|+XQZX5BK3)hDsmI3}_2bsQ8^E+I0X*4(Bt@LEk8P+$;^j802r1m> zp$m|G>EXi%{8zCw_zu#)8|z(zjmRV_D66su#km4yiSE4BHUcOZPf>r^BwP81OS@>i zG1ZkN4zW37p3_<06UG6~!o1N|U%|;0d1yzx8LAOt#jIr)=(!c~%Er1N7oFxIshEX+ z|4*D?shm6t4^R5WY~ZEkrC7B#h%L zG#Z~Ro3G;57G9=;>dU0a#)rk1hG8#7@*6yokVl(Jp&ePG*VPxWown347XcbL^y!q<7ZYmf$*9V-wkMGx5-vpy1dK_3;?N%r z9jgQb**b*3ui~u9I=ov%68Dfe>?@WLS~(D0fE}2bAyl4~=}O%gwaQB*q6llb#Yw?K z*Z5oBW(?kYqQ=ZskJ_z)*CpZCh@32Ic9(*dn5pDorJ`nzS~HnYAfysCjYJE$psYb$ zXC+BsM_nbx4Th+sjRlCYchM8_uH`m_31|GK5Wx%KlIT!se5k5^t9smh%jkzjT~Q!F z6EfniXjb~17uh`%v_6-y9>Z`m5P)=(Cq5*U4Ps|8ZxS`_`4IRHSGe$z_?4WcY%bD> z{Fih~;5I9G6!+NNk;8PmC-Wq%or*u{M*dgGsbck;_k(( z^0?2E;FOs!5rh9L(Wy9?0T(vNG?G@n2thszMa-Fpu{1*E14o=%79)^Ep>)g{EZDgj zTQWCA3)?1AqqD?B!H*bl@I$2?f=eM@k!heWK=!oRgorM}W#f+#qShzt?wqnaDL!w#Pp^ncduQw9{Rn|YST)Cv(mf+jg zn7O=okQY!3W#S^QG`^ZiM}(5Vy&@{f_AAmpkM^5u$2(#+oN ztQ;67qnt{*YDo>W#I>qTl(mh%Lp7bDh#Bk_4Ubq;9Q0T;6r#Oi8r&paywJKmOI>dC zm5`vJh9l_AAnEKvDlx!ZjluM5EToyLCtHuTDc}mlI(>;gncjsp7v=PzulrFjQPM}o zu~v$NA<4|wnwV&+=22uwTi28Gkc+V75<`fIGh3vQDj|WaR_RQ>TxkXm+Ds!`?o;TN z;U04W{pwCmzDmSVjZV~hr-25_$u_K&8CG1iYRNW=ys!!bsjDNAIy6U~>fkJG7-eW# zQlaF=9HJl}qLO#J!3uV&8H;38Db!*pvfzkrEG_IxBu+iqMOPe)DqEm_%YGVM*pzJZ zno3VNIEplcr$F&XE_sSAK+y1!k?=V)3KL9|Nr6yw*?~j5Fq|vfr9Gh6?WEaAf+;(b zY^N%Kg4JYuqeEtgPFp(F{Jo;}W~{@SftYDBZ7aSZs%i4y@-DIb4h==-uHZ~~-A>V^ zh=qn2U$7?NZpgX~N;Sa#H*Qn;k# zsA62^^H>&(*c%qY+H`hdUTgHs!&iL*zHg&VHU=!=JXM?UxI}ce8X~NC>C|T+6L=xF zcGM}=J4_M6D%o;9rAR?Ju3`+c8NQk2jNXtnv>xp#iX`J|N^DgosTT-e{LA=76;2>x zID|RPB%! z`@w_!qS8>hzEpjgCWPDZOpZswfNV7PoJDg@*#bsCqbAgHjJaBqzAh<|PlPYW3c{+s z>t;BSSYWavpN##;y^bW2PBz=NGBX$u1--9d-BCjUC0HwQp=j~DNvgtFO)C3<17)6%u7N9+c>* zVVv*0yR0WQ^O{Alz6!W>ObcSOU;>$%vWAqWQV+O;nd}(IG^_LgoV2z65b2_7u1ui> z?8#iSx-=y+ER7EK2_$eHbhus<2bm9w@o%LzPRWq?S`~j#&AT?$(o7?MsuGA1qvJhj zC)+AosMrt8pw*OW;+agMse=aP#k`r2Mmy?}x;wzO^S?G#n52C6| zbOYjS*m@GNXBRBls^Ksl$SIu;2zB<%+Hg`6Q>!U;DqN>~I#`E?`3*NYRIIAnYR=b< zGT&t7X^yd2f$*xq5RlLnR?LPV+;rcOqKHAoWNo?|bzD!+**tb?8_q5qZs@}9@a8d0 zxz%OsHKK_LvydbK5h<^%KgQgPhOCTC!xs0bc=5|Oz8uBoNqhT2fj;D*otLy$+A_eo?_YOl-n=mnu^<$N$Zwb(Tf3W6`IxgMmH<# zhA*J1&O+&06k)hZ7wAe^*F3T{Mb3j&#+nJ9FLa{Jlbz=1N9h@s^2dmTa^IA2AYKez zZj*`$G(yw><~oXDU~D9jVMVmjwS0M(tF4exbvX_Fg*MZo>6N8x-9xyWV}l_&_Le zYPL;~V{ol!mR`k(QR)m@q+saM{v_tscDo)*+!Iif&zJpD4Q<;bDNIP`HIv93ZfaJK zFDOT})5UFXfs!pp- zlxa;%D4WoSsy##(9ug@k17qDVB2iC93tRG&aX$&!B&I!NR57iYU1ehF;Lfc(_U{On5g=u!PX2mKX)ZGfU_SXNw8q?+aY3=UWy?y7tLp#eos@gIdx%<5>-2VTj zzlAFP|4x4kxBtKCZ&((5H&IJ;p`I-@?o5S+$m(g7eKI`Y?`+9KP>cT?^bw7#;2Sve zWDkyhfvtuwc{xa_3e(EYlp6ISZFP-9G9?nm6P`R#h4n-t8q64lhlu{70*V$|y4Bj- zW|B_Dnt}Hs<8^tUZ+ao=t4i8#dvVLu%XuW+QuuP-iG~!Nh8Xn5Oh>9yTi;8MjY^cP z+`7`utz%<$xQ#<%ON?&$XIjL|r5IvGT~&Q2Mzg}gNOv6Ixa|pxE4jonUr~=@;?35l zu2YuLaFHumEYzv%FkOjkx^te953%lkt*Bt5PW4jL{KoEZ{=GyPrPOagMyOcL!s1As zLLt@#=`YJJaVFG3Vt4G$qtt~o?JhI+tY`m&OjRD{FrQh)Q_J_!tGOn+y_&lMyR-E` z=J|x)SoXl;B@;5L412>0tBD$EJeR0>OZh!=BS^mGCnhY3D>q>|w0V~*)E@Zy?evfp zOQjy&gaWc@%UfJjrCL}UQ@F+|%d%zRA)8m4l2ZtA4GOOOw$S@%nB_k#dgfiASZrCG z{jD|hEzucdvatC8LqT0WN#K6P)=AhABV~cmQqEi&ebixd*t9Av)GD)otykBJOpH?Fk>Mz+-2iTm}j|r$RBoDcAD6O zy8$eYZzvF>6`5V_HHD3w#VH8cQz*crtXxQ;VJRj4^W{FELaBCBaB}~wP6aEJ6$0{$ z@meh8n=chd08`0C63C|`s9`o#p-9A^BbT3X5S7WEiyl>#Bg6HAh$)Y(+V8oD1@F`5 zPze$E3tmud{aCOWwbYY%k>E;RX%Vyk?%NL{LUS$*ERN8a%o-NZ5Md?u?-V2Gv^#jNWJh9$!?KTyXg;y#B>xM}DobXKdd2Q-1i~mPVQe0EQl`Py5^xLk_}zt6)z~aGAy|#t z_3|i@xkLwkF~1T_Wu+a?IYAjwBX<%46JH@eOzk~H7uP$g=K}n#UXWNrK!@$o3q0&Ra2o9^p4?ze--z+pHnkaOzvLeMQs-m826l<^u zlX5$^myP&Dn6qp>Xk*ZAK7*x0m+#ryRD@nRVR2G8f0$@Ym#)ao3!9l`Sl43}`im1) zuN@876g(lD8pBI;6G1GJo}9Vjl<8P`!&?5^=+2FJBTR`!#==G8WTdqP3_~?HWxPC2 z;*FZxI*A#k-rM&w91{vvI>|7|p&6#keveNaAayuj62nCfycvB;nKUY}n_tNGD6>t< z^2IDdo=DmHse{<=D%ceDXUGi;c(Yn$TQEk+n__NZ@5ZI}PF5pD6LWFavN9vwH==r; zX=7O>_Ai5tV~e=6?i;?m8}p0mYw`k{$OxuL$>F0u!e$Ta){U^%i=e4wV2rhsnkEcu z^T1Rg0?nrKG1&f378VL55=k?1CGB{5SeVw>+vPKW+2#;p#RA2QpKmBA5WrlOUG^-j zCS4L2kMXo>#7pdfQI9Mj#XiLg^23D!Tz1Gj7-rq;EEwmy!IWBT)9%-_7?1E}!Ij>? z@3bqs1uIn{XS!kA<8-fsBlXCtqK2p?^$$kNdjSnmPC$)tIlYu#QI)6P2&HQI=f&w7 zHOXF8)CcpcehR^6V+0cv?vg_?153=3-8?DOFvsbRMwp7x=ob_uLYd6U0%B!HR*TYQ zb5sNs#hSkIX|fM5T3L{7uxW7?@Td)AsAa!pm{X(X2M>vOYvT zCQ&dlx=D70Z;_gsdnUerJJWRLn{j`kv~V~Jm%mjGvVh& zg&EbPg@Pm{2l)|_n_!X1gU;mrnU)s^Z>mm zq7n+3tQIOxz4S_?MTKGz`r5t+=30q(vzpgx8j7amT#zew&X-A;rJrKdELHZ?+n zyP4Go$QjAEiD=JD@{!`kcYSP(b~<|4k_PIsc6x?{(J3vqCaSm}uTf-=nl>|7^Dmj? zhBHwF_QJv0qoz8Gf-DWoQ5QB$Y_6mME1Ixzcw}@KnW8EZnMu_WZhdufp~uqr>5^y6 zN->yM3f(Jd=~K!2R|-AgM(+Vj&N?-sB1c6LdHvp6x2BLa%9}HAB&3p6Qu_1tw$>aS zpLN4N5M+q`&0)uB`!z@gLNxnbxjgx(*om?y!@wl}8)LNfoG)NxD%h4zy+nhYpQHkIY8{ zKg5}8tYnh-nfIkjltX zeAY>m&shZhE^I`pXE&M?Nn^;fL4(at0%e|*2eIanj|L5 zBB&ghJCLsE9Y?^du&vT`xu3<9n^%m%oE2Fn$VzqHezoAG5UGrAI9Kn)Z+3NvT*Y&t zvNCt#3C`lmUsPHC0`vR1#GqXS6^h1~yM8MceZd%nQlQRNRx=I#;6AW0Pgl7z$^@71 z9lko*ZB+uAEF8nQ4s6M4BomO8h7YzVx}gQIqR@e=Jba6J&Sep#sKl(eJ^MkmX_KXa zn|u$$fm09*B(B=4ym6`rU|R^6e@d28IR+tNQW5}AC8@|ZSe0%<)AO+9=1kRhK#~}o zWH<0>sFg=#t&{4WM>Y^pV_H4YVlg93J6|wq0w-F6TJY`5?Yab3DS?`bij>)o?1O*` z>6Wc4U9TdzFm7aqcmPQHN#qCtP1^DjEN{!oh{NQ1DfbWFf}Dd}kBvc-%9Cjv+{(ih zIYA?uWU{rc;%FqXZTJ*9J6x*!=$4g&Sj+BKi9{9al2r7(j(aLP50dgNAYwCX^?*#9 z%iCeAV|JJ+m1gVBd2Pd^j*-(6GDC00W{7C{tFc#AQHsa)Y_21EB~uh;)gl>%U?r;m zf2GOMf8in&%Dkf_DCE17JxUxNtZPYMy=F(* zO2s@(30dZqaZXmtCN*Kz0b(koFM>`92@CC6Y1Lis7mKii{E)VACRe1+DA+@FWGEGA zgZiDWgu0BQWd%iRHZPGd2gJpVeYJp_B@rYhy74zN^^3Tl63DJYEP&+3Siykz{e$2)^msFLs(BGIke{~8 zXK;hWriYXqK;&xSmsh+5J*Ro8_#?fLvtVE{rL3PTFEunnP1VIjy)GO*Z~nsNhJIe{ zLJj`B-i3q1KTnyI3+;)rBpF|L1I8ZMBaJGW{nnyhw)4@=g?BP`B^$#m7)pvFN?3F~ zq_O#;JLVoqe4Wt%{;hI!*THL&>9#|2wrK&BX&NyQZN8Ur3~~jFQH5xFSrhVGg+NZ)c&s3l4ELLZ_L z?3um38L3q^Vkmm5j4rZ2kaf#Q(z8f(G}{Rv7&$w5eB9XwQ>J(rr$M{orn^M2h4&Xk z88C_$EL{}+AfrA_6FuRDA&?`Y%-@5P>nrqY*xfeF0eH!J5iB;N=xVn6Q{YzYhGnh= zH?|WW0Az;gFf$l5Yih#M0hmt;-033xR0;S+9eOnzL>70kPys_!y$B1HR4gu{P^?8y ztk_CyulN*ciy!e$@q#2y5tLnP%;TDhXweC`1)xuN6@+2Adg`z_JY+Hrk2FDaSEpS- zc?q)nL|Y^*;!265_RCTGMMVVr2xZ!Ti{6YO6(@6DtIM{?}Z+zk=S~2fs z0d$k3Ru>@0pFn16c7#G8ieK7xnX);}AIW=dwbYqSvrH1s66%G$w$zm=r5$NCE42>m zQsdHK_#C4$Y*-?B8e`cYbU-G6fn$vs*?0UREartTTJLjYw@N_vwfUz@WQge^Es=Lb z__`@*R)J&!*1k*%=g%T#vaE2~7h&^j{}lE!xllu)LNsLUuVLb|90_X_*b>sIrF~=jKr-p@ea;^Gu)VcbG~mI3SUbT{5c`qA2id zHQT8`3O+JV6nTaYNmL6yhIzFB2WX0tNs&!r#*~wLL@&H@$1=&FTvext-M;*1S)Fl# zi#ijP@Zx>06_3;`MALI68xXB@C8wP|!8N~F20DxG$6T%Uaj{q(3UcLSwX;%_>q~*Q^N)v1Uz~LK=T%Qi#EX>CIL+b*XV6r=?dhWa3q_&d_vv}I()H4?4ZjQ z1{5XRTFdNugcv>GZDYxPh0PJ3ylFz~ZCN**XjPEBnB;&X8_SRFr?R75BwFRQttpCE z2D2kx>ze@2B668Q9Coz+>TruNuD)kvt`l@yThMm7hQ*$T2p{+P zj;(PZq#r{E{V0iNB{1VbTx%ILv^;Ms3#_CgpbWV|bPbm{oVHua1Nu9W? ziEA&)n%1CRqJ>x7+QC>{A)^_bdbGGbJW!G6J`lz-{&X`GrqnIfDB<-_<{0V?1cfFk z@{5lQ%M^lp1CObOf&w$H7+AK=A+jx4zI;coLXN82H{~z;SH!I)!76uvlPan znt#<>iZ8LvdXs%Tw8HWL7Nq(qdu@ZB!PPE;q-az-=7x7>B4tEfB6q1y;{ndtWaKWc z&eCD!y{ugwgO+iY4`Hq68{epj;&oY1H8X(`c1Yi`9h#*OtRpW;<&xr;aDC9vuKRQlYtorfu8J1kK<-cAxrTGTNQQ{HibC_=e=*&vf%b;TFPadebfXEf%I& zag9gboLgh-hjU(UP$@trqR`G&G$21KN&_@5c1cKw6s}XP1EI=p;S^tU1JAVxQ;826 zJZxzzqp@va0~FiELteceF-1+dmx@A$M1}EVVIJMOutF6gJ#FN2h$WKsLGs3GKL!$G`w%D=UpJ$~LSrdj@GAdE&8(P8yN;%?x^JVfquF9fw#CjQV=ca-TV zth#d-rFhcbv?}QomxFiO;5SADf`64cF7jGg{1Gv0E=bH<2MdD$l4|-w3%)ojbE{$y zWy`#2wTW;%ytMv68rCPy2*3udmw1M1Mi8Kykm$x`p_j0Ki)k0brEWw(Q=9Ia3(|GZ zD{S=*&f*~^Vy2waRm@s^5o8i{jqk(IU36#^nXk@?kp@YN!e$s|6~wouD~J>JlThav z2b-0nmP>tV4vn&X^JOVW3r(0E7NSgXX@j#xhLy$3Ee7Uf$+C-qUl+ZzLvd*zvF!%3 z=yk{CqX>)M>`^vM5u=Ct_ot!t<)bcozp#b0u>H+@GjU*>Xlh)N3$b=Li-lNX)JfZt znT!#gxr@t-nGNYWGYm66F9Zv+OecI`{$cS!i^mdIt1do2slok}GHX+4u%m6$6IX&x zB*Z14`}1twf*I`0Y;pS;8I`vG3<$POO3XM*4uv;zI$CHp#{2n-T!X9hnijq)@{IIE zRb#(6V`A=SteKOq@}KtdHtmsQduh4^I*@UawQ<1PAVv{)->}d_5OxS#nP3!SpzB1= zW9!Oeo=jRI&mdCNOg#8Uxz^`6NASc|6gHZnkic#wpXG8&dy-CciXibr) zz1fQmL2__qC$%=YR;)r6HDNDgk%iHbt3c2OH*fnk<@aA20M+UAWf8Nke5- z1eW-K#i+o^>2bZgqC@%>>{mH7OoK6wq=lRbp*xhz!|%#@XdG-M)?_n1--NX=`f|EG zKaa#mADcLl9X(gQ7U8KBZYjvSfDNqh!)jCSim7%>Gn3cjRs`Xw)P|CTl1aV*NrJ;% z3#6&GHt|GE<$&F+ETh^wRdK7Ns%_sA>SeoWh=!P~50eo3Gs&Brrz8N3%4}g&r{3?z zR1v81d)eSAI+C2TkO8#{yyxAvn3{-8QwSu6AhTO=I~VPG-guNP2E_Y(3HL3k4D8r z=mo9g(~h#CgH{EY&xTi18Flmu3j)NUd9op@mN>gBFd<3WkZsYJy~D^b3Ypl*4ACTd zQz(RAcW4>Es8Pd|v{Z$ho2yNDcSy}$sMfObF9V&|-j-%9`I;0Ft1Vjb-c#|TeX%-i zQmAZVt$K) zUCc@Fd-%vAgE%qfkvK8rw`8uUNZfj%2jmVV#y40)p9&Xx0e}%oR54!Tnf1UjIr(FX z$c<%0wtv5^R1gs=0MCvXwxOmXB@>%QMn?R$+=OLTm3NFzJL=yy2nnQQ<>+L*z0acJ zcqgn?le_M5JiCq8@3mMAwOhL^ingPiGGBs{3}i=kyKg}v(G6aTiR5f^Hbo?2aiB>v z%S_OPY&Bu%it`h4M%@!4`#i{pX?~n0-X_9G)O2EeNeTNgz?CX!iyOkP7~BJ1Ok$1X zg_P#9!tYD;zH3I4tH#*sPV{MAUk0Z(8)C=^E!wt8_f?`fk!K7RqRuS5KSu8wXP!ME zqfmX^85X{sFG^oFkyh1nA9ZTkEJ->M>X!u~7M3faO zBee*I*E~`5gKxdaxn>uI_~KsfH2+zmR12GBHkkRaNVgc~ql>6%@3h&PWI%SC-5^zs ze0Sukp%TmZAWqDrFbxNSJG#iU_rUoM-#l96l!xEEF<+JwUDztN;ykM>*eXy|9c^Q) zodRKbcs9D$T!JrU@dlT!xy4G)3NRIgq?=06U1im8JnGx5qWO#*8zd1}-E($&Sk97YF5}0%GR}E`m$@R?0WYMdH;f&8lT?X2Pv+UPd=R`q zm^ItmJd5v#+Drw~{N-)diqa$6FCkwL!0$?aGd~Eq$hS(5|MZk=^fH4O9LRW(1NS8{ z6yp=EPz+r-koWAIWs7sdgSEY?n{{S8f`Oo42%u7pNyRRAX^xh@I5@vHic|4?EnN}h zPP!xC6v%uEM7^XveTgDD@+h=lG$iC^<7kSl?XtWXyP-b!}lKibr=d5E><2MC1v#J}jZEYWWs^2E?3?#zf(gA;h&8 z8ill1ae%@@$Rhnr(+;PrNGk~Jkxfi3^u(6`Q7yUDmFO0|@s#)joU2{D%~Yr6$cxH} zut`A`-}!59vO7W&bN$-?YlE9 zj0HPoRkr7=x1a9{!m=Fdf5r6K;PP&9R*#?|DNb#YF3Ik7+secj`X<87l)vaLtY|G# z3eik+c9(WIjytj;PgMAPHP6j^GdMbsmK$LKU2q3PL21P#GT6@{=Cy#q>t{7}2vtSu z@@DC&Z5$OU!aZUy!O>@@Y+IFE9D~9(CUWJ#xr$Y*EAsXV6HPoh*1Pi*RXVu%3SA2W z(%xCJ!($D4@L7%?WpQPX5+j8xHKW#zrMSy2h*M+H>`JfQQ*X1*W)$g*5|(>%5TV&E zmSv7pvGm!zO}$U4A^GlXU8#|+f&~&vSOMV*udRtyfU$Ou(4$_)$;8J@d4?rW7&1!c zcj*OdBof?+R(?GTluD{ubaoo@mB=dIwoGE%0%MR|6#b^;d`}OaDGm_QOg&AZP_5p} z>;8-7U175VQ9c1y(T?q1Z>ya0I2HVp*St%m#{sOisyo-6dd4F2jmbA#!}!sHKv5f8 z=QzmolRP7+{h&4EJvdLsj^v$)!iv%&BKzVkrVilv+odH!NJUvj8MtpYKRX<_2p%U@(& zW&3@Ykzx|cci>0C?k@a%sx}5T_CU?&Ps>(OX;HLLnIjg$oCQt3PCLk_;9YYO0cEzJ zq9re#C7NnmVpvWitk&^rc{N(89NxWm=b^(}_Z~QU_~4O!+mR#j1xDoL^lmL&OcbBQ z2u&FleAN!>j@K`kBf;y~ZATzoq!mQ+%=MBfo@v2r?2>_XLbxXOCIwTdA@+miszra@ zatHtr9h1zZKXH-J;keafl6^A{DpV36_ITeSz0lY~a6Qzii7L$N(55N4QrXs&dUJ+3 zt^T4ZyxJC|X{#y_qw}T71u6vCa?Qe~9)Y#=kTiZwYuW;qR$bd&kZsi>dAL>Hy;6;T8ieMe#R+x;O&VeA;IhAe25Q|`GS;okm281Mu$PKvWq1eolWvgtb zhJ2x|U(j8h9O)t?CIBdIsJ{?eTtPPnQg*RE+Ek9~j$#gg&0p)SVYktT3)k45yg$=+ zwJ=(A6`o#sdx@j3CLpXv(tD*3D?t zLq=9+RZvJC%7$|xMVEh}Op!yOF}H%E+RlH_?+{a1t9PpNCcL8sWR_9LL((8rZ~MbWGp(ZH8={gY*0@|RpOu-$251q1%Swn?TIK?l5v z-8U*-tnqogWEnG#Y9zXi!?1Mq6+VP5xsn8vxn-n2$KFpK$(^GdqwG%!3{b!%=phF+ zgK=fVWXSU55#LH)t#CA4J~R*?f`dr;;X z-&$xpOE_kWcX_F}H7uvXV<{fSie|Xk-Wo73xhkPcONf+GzeP?Ci7A(d=Xz!?pdgTz zNk%GA*@uXfoo^lGv5Hv9s4_KBz;d)q`x21I*8uY>7h>hjP>m8=mpLZvsz;`OG-0-% zh0!(TzqV$>ekZP?{gzr1WPF#HM$=O1nuW9HGqw)PC6 zbNntEi^X$ki3A2uk20Xt(Q0O!x>F5lpjUc&zHbbqUM8L)8HJnHp3<(P;SCf@=_)lY zX2L&H!uQ0oBlLNZJ0WXCeG5r^e0kozA(3J?m-?Nizt4p}v6Bv|Lup->pH_WjKkc>P0SKH#sQ!a5+2&jFK%)v0F zPRW&FP2r(>FS$}%^|HgZZnR*MC>Ac}V%9$a@Lk}xrV*IR6HU>QxQ1W2x`clAkEIlUY# z%A8#$b51EoSNn~NWr+wD&Xl%T{F8RKyaDxpiaQC5I-cVdw(}CbBdSl8iyIxRCP;)7 zEB}*k?S*%N5$vVLcNtzodDs$sc)?|4tQ^c15NXR#jX=1pguOCtC!}o0%)AQF?T9T=Q@4$!4}{Vf zn$}#LM%U@dU6Q^GMry7;ag^gNEHn#5(i0(NNkQ6Lj&{8pa$ZBBX+G{JC ziDrhsJTVS51SWS&OL^Q}D323M&`5QcELS2PiO5pXsL*5~2e*&&okjJ7!UK9ohh{f( zY|S>pdd*JYGGR7(XCtM=_j7Zr%-$(`HEqhyhV1N=4M<1D<;5sXmgI19a0RpWgxyfu zTU{6)8QZjZ(*}DT4oEl}p1C8$m(uM#iKqy+7p{+~i~qqB$HNmxHmzSj@I*_$<%5W` zG8~AMVo19}9W?6+L{eI6IwrhnJx)mAX6X($dh_tFPZ<^iZcSE~rm2c%WFR4ICIW(J z6`~FM4(&cC zS0NY9g<)A(%?BTYRQ}jt|xNcF}Z^TyaA`*y{sN#^TB_6YehgMmR+a zLS97${U7(YuySaRri8UvGCwKc436sEs##ZuLrB9y;EbLoqqG~S%^%3qfcIi%#?tjm z3ie{GL^>l2kb&d41F;?sA9`T|gF98AM&ZT$M|Ca_))amV$j%}n_ETk~JgSNcdG(|0 zhcQ;EB$W!UNGOl;RcEzaf1RHl85=2$jF(0>rz0a1YQE`HtJ(M85 z55W}XP#V}W9)XvL`t4$bSs9Nxq`YIvRxEJ6sLhL~!H!q0D+59@E4<}11~4-w^{a<3 zzW%~%`|}h@+s02QB~>4jM_~(H$ums^wq!ck$dgAk*pl`4$_2;++~ zpHuHyYIop1I9*eOhs~#E!dA`tZpNHrvyzT&)L!}t7c{GAIn}WQ*-=3|MXFn>EQ%`J zYv2`JHCs#git5~TaxiH;2pYDO(Ccbcb6~aSZtdv>yHnb)NIN=&%6hdb4z->@?_t9b z4G)6UUhB~onAa|@%sFWury4CB!+Zw=;58y3XtZFt$#GR22KDBJI4=7X#~FC3O-v4p zTO`S1JRROe;~;N&igx%6;pRn558K#Xd2skt3n4?JRgeL67hXG2o*mFdN+yUDyOki8#u-+>q@GFdDgmYh)Vc&T%r#GO5pu%IZhRAM5UN?Pm?#D8=7{;)|v z`%w#}hl6gSz-Jh%lV$=>>Vd`n>l|cCksA5SF5{S*g@3|rM+unFPWIv(zIr{Jz7(pH zITU>dkjcU%WOEWj>ME*g*z(v9%5urr`)OG*_pq=wfyC83*l+Bc;9FnMSR&tv}N(9d1vg zXB^mH(vBL+Ih1w~a+*l5+PU>$Y485hj;-mX`zQA9KL6_d`*xnOhXpaE!@LNrORlZm znMijX*|R6zw{`DM_ITgBb@!gfZQZfs;LbybF5=SGOdmB?I$W>LE#Ifi{PwLW%4{U5 z6yD+$J@eIkv!9Zqwxo@p=6grC9URV|G?ChwGxm~7&XK|1s%LEX5{A-YcGKteZlp=6 zk3lD1fWcX1!=c`VM-J~QZOX6H2-$h1w38k6rFkdPP3)g^#(}1hHI~2}`vtYIiS)*e z3&$>y-Nn}nTj@pV=mlpyp>&BS>V%>zeN^eX@+LNhKXyj4%v&er>>z{Wow9EjLVWwiSS)1Jz!;Dg9@MM%kFHRY0GUrye7^0k&8(+}#c?dMsI%}DFeH&=$C zr|d|COvT>;inWh)eo3Z`AHt*fIoK*|PBgI5uhlQnC0RZrfkXsmW^C+*pmjiz)u z6XPwj9c2Fodaz~ak@)jcdyy*lpfm;o& z)72YjoHJ8xCPNXI`n6a-6ednohCOXht&IF(jqdQt+k1VsPqfaHG(whX+KA2hWKJ-M zD^A`*{v$T1-&g}RC+*~q;lXs=5SZB&T^=gRFp7|2*kmcSri71^kyQ)S=O*aHZoMpk z%s@skJ_eOuAPOKnO%%7M2YIlt50_0qia0ZuW1DpIt{E*J)mdHSEMZNosQ@U=GS{w5*yHQqqmI=6076pm>US+V%ZFP9m;a|AugqFhCxU_t`sn2OBI11&2<)lXX)a%~XL;r`rwkhYdJ(vf4NS&#g^c zYAJg+lns$pLohC+GufWIAl(65*Lee%$ak(vZg1I^t(l*(`A)wvceV}Y4qgHiDDj{u zUNLD+Lg(Zy*#zoMF-($acBfgrHC2W@0-_+ zt{-2&ZX_AqJi1}?`Z3`84I9^uCisR4w&l9g=qUg6bz^B{Q)wiA-JE?L#aj$#xiW69XM@$q$IqwABg4WpY!2-YOyWqmgA z*~n*8vSEDF=-B$PF*>$!<0dXzw_($0vU$V!`jHJA$415zmlaW3f;uJx%5@Q`2_PdE zqbSR408OZIo>wf+<(h;!lp4q+pC$~}BlDQ?FKyw!vN z>1V3f*=5*@nv^3(+;N20KdHCvm1TKI-;iH`w4nnRm(%R-NOVAZ!E2i&?GU}Bz}ncv zf6K?MCu!J-F~o#8g#{oTD05NxRnkbJ{8Ry0VI_`)J>yQkvnI*QD7`lUOI5fP)(be# zo?T9lfVE@w8={UA+xoz)U6df@^S*jy`7Ks#4jfG#!j-+Ylpg<<=}4xHO&8G@khr)* z6G@296u0DbK~kN@3CQB15iOIAR;EZ$h@?4L1YVApk#>F@grc!`Qmw7@EBER+|;SG}sku)U!DG4Bl99M7h{MO9g`eUKqcZ-gLh_i*-{4S z$2wqGAuQY)-&9H5b=~d8Rk+EvLy_U`#JU#@G)lpcM+3?ZYqD%B+`HAM!L+COL=-fD z<5T96j1ftwag9?uR7(gOLQ=j@Jmk95trkfF#fprZW68Fr&;m6G-3dN{;+t0dh=9-> zgNvL-K$cx!l-lW*;*ssa$Of;~v|=1U**{yHAq%!(BVwc|zYW%@!$db?9b)qFBM;H$ zB%&-MGqB59f0og!hdtOOl7>l^pS*?bcQ72#$@BEnDKqdA%nA9izgA@SQ%MOu!LRge z$AMD^J&?4py=-ZzOSjT%lqWBqtXQ09mkt=kT9*pjNWHoVlkuuF9qWX%6cm-j`i%lxoPHfx| z9{lyYeF zXjmcE=Fq({oOjIXHolR$II_r0CduG+$4QP9-H;2!#x6B7{5mvV?yM(E#W{{$G}A*k@lYLgcl z@*R0y>)YelP-rTO>Hm-VYo)acZY<_iQ*VYwX_l_MoLOT-E|N{E*g17<6T$}C~yg* zH)^F@){U*#J8F*1r6=!b$@PubaJi4drWSUwhy-qaK!?5F&B#e8ITkF9OwE}~8{PmA z^dJ(5c&$Z;A`aK4Tes~NmDp2zWX5FX@o23uBw5RNT{JH{T9zk6`Z%(S?E9l8OfiaI#{Rwx4E<1k@LFJb6rZM z4R}b}RZWq$EOV$aD5@oMLeXuJR4^C}*v0N9*;13u>FTCL2MKbTgWN!ltQZI|1Ng`} z@+t2mSCZ#_*IN7AUsW|tTESodTdc17e)iA$eb>*%BKQQ4pWN|Ya?7QW2^p-qPW24a zk!eA}Vy0@PrdbNk;+U6MC)6zakB)ndx1#!~un1}S0zL!W+9DF$*XUjDgp=)dZJ^q* z2YA3jNrlg1t6{ik2_=89>p8bl0?2y%iLe8S2^bMcELF%n(= z(`!rcTJd2pq1IK#c=Xbhl;)Db2nkAvOJ$MT^wZKL03xx(^|50o=d16>sKI-n`^=j^ zS$z?a5Mc%;N6gNB-v%j&c_N-?dv2eikYN-2 z-2_py$&q0VLPuGJmQYWJD`2gffc(!=7-Y~Hvtmq5Z&`0zZOFbsyNqovSyd95E4+sk z*vCaYdU`T@BH(!B#VE>htor;gmYBY5K%p6IF)UrXwP9w8bb)f&;ONZnhNiZGilmCk zWbvi1v=yew!!SHM=Wlv5qV3&Rf48?qaluH!B&8L1rEa_}AkK`sP~bmpBC!u+NPmVt ze+j-xz$ljzs+2R&$1_gOMI@A{%9lvU(KBFbX)VRr$&xTlEQiK`^Ju_-&1h}8b?!k7 zngIjWk`T_MYRoowJ;R>;Hg0sc0ecUKh~9xBd_L`c_vqK@5oDXBDZ#w4K;I{LHh4kV zyX+DCvaB>8q~zY(qmfzUoPIOsq@hFTFEgq5wEgMftJ@NTr`vIphJ%cHCqlSD#fkjX z#ktu7Qqqx=Eshea8IcUe4Cv{(@=o|MBwo}h@*JY^NJ*UZ)ag>UK~C6irITRE)O9?e zY4Ozh5Rws*q&A^KviW%GNvYQr^8QSte;0#F{-xxAx)O!G@aA76+Yu*e{fcE_{+IR= z#FSzio5C{VY^;Q>Z_OGGkc9XS22A6RFl3c~i_N9QlT<1ZmOIUIKf{*y(n@cfzWEoO zIxACKt9ogyGNk?jtxsJ&*vdz1j~*UF9*5*_kpCBfh)r+CIVjT3idC|%Y)6hN3W3?z zkeaJjB7$DEEYnMv^ccZdx;dOSJ72NSC5PKsP5$ddNv@IR&dlC%NC=<7dW3`or9)O> zcB2eeRbGt$#`N~~?deZ`5`-4t{dD^G(orV8zYhaodQT|(VD+3`IN|ZO$lW0=DsTuQ zhFBZv*xNuTEQ*?&K}9fj$EK9sh(ac_ACG|by)<8*T#iw7&PZ+p>_c@XiT@(UPw(EH zUc&U2IL=Ek2-t{&x7}Y!ZS2B$G)_7=>=vbaeXh@DQL>^yFA^n}97qX6O&^(SqA1FT zP{v2HSNQ7-z*5Cjn3U^XqAlEm8Rm`KN3QBdgQJ>NE`{4vzfZL%%Xr~ zaf~vFQ9H2Q9>zwpdI;eLB*Ndv zxF;R#r!#FKI$9XKI6Sk5unl2sGYbBd;HP4jSfK_Nz5&02ypUZSVHrCH&?qW})7p@u zU*vebPPCYX{8+TlkIsI5{@4?57qtC5Sg6{aHnE3*CC46!T{wEh`=BT zaR;G@Fo;qYuNEk+orshdf(vKw+M3bS#OU2o8M(o@Lxcv@wre3&Q zVn-i!lqh?$8Tl$&2kAq3UZEAEQ~-belAcK_(@&?LKfH5UcZVM7R#)6|73~aWA&s7Cz!S;7}U%Le6FCamM(Lrd&cnh%!pJ)Fij-+y=X97{-)yIIg& zBv(Bo7^q?&EQxe*XhgP(pIG>>N%k~kQ1F{2NRWU{v2NUqm511mg|U66Y-V0aABxwR z=u6T@UJ0hr!HNX+wj?pP`sx4S1gJ|uF7tPN2Fg~UIHbOu1{oii6W=LSQqN8NE?%p| z?%$b*J87QEnp7oVaZQSr>RMQhh*{>c?Y21L9RnQc`>vnsa!GqrkxnK&%$2+#jzITv z)$A^7dX~W^?F~zINm`|aKednJ#RwMCW7d8_g%3tesCs}K4KJ`?+n}&jC{IfpRxI3a z_9_s&SkKiR@HUrQ%94dOuhF&mPp(@Jbo=wE--kJyj#8Za|bt^%%!bI z325iLqq!tYR#uYX#qxD7FjMJia%eLt{$_#$azyw_B<;63*nzC2Lub~^LGkN!%L&p({(SwB4{bN&dSu@CHSjViZ~vx?fY~ zHJt$-Oo@@A#^@ph0?-GU8pvPDa7cpkvY2`~W2RT(RF8lql_U5Gokoz(f`UeJQ~ zl$RpIGqO@3Q<)v-3>I?ERSS&;>wlVB&tbxp14sZ#nqFu2f?T7J0aStfj)zcnO=dID z3>INENKPo2AywZTOof3+v69N5ZMZgwweR1Wu`^3w{A9$9nu(a|m3N3z1wF8_rAzvo zJ*LQ8)U0c|PAfZb)s$Z69qez@;RmGW$$(S#+4RztI7h{2pCDGQ&`oYfx;#|PNM#NJ z`H5UAwZ38A({G|UqBGf6*2tM-8f1lzR@Yk83817DSnmsI*)ORNq2o|5*EbQXje=^L zsR?7oA-6DQ9Y3K3@*&9s@q-DU7zYUoM3VT!zK+61aVXNvA@!Pvr!2o_1a0y{NLDo?hYU(E_JsZ>5mPYLs!!R|jO zNhU#t-~+smwc|mR&Y{vsWeC=OS+?2IU!8*qcjQn+5D7Mc>b9D$*%~3Qn`{Sjuo8w; zoQ{~uj7>3gY5!5eiZ^U9dXihQ6#Ly+l?7ofqWo51=Z{3=FUI_+tMMGyyk0eE$QVP*7 z5~8LrRg33SZunV4I*=JHRx-JDEV_i{mbf0gLKIhdpB<@4-bUaTBmJ0BoMJti3NZ52 z@kIy*@H(`i&urH-(qe!=C%0a{`4ex{R|G$7&599EPn3qhJG)Fe{Ac(?U<=f|0Ha?} zx&6gm@#_$j5^}ihqVH{W_u{YVS5C^dXF)Qz;}Ny>sz@W_+DYnhMq}aEY4l8Ti8jV;n1(Y*NrMKSF5=c%&E=95w8%~niFs2h8h&< zt_#k82wFTR*2uG4mU=9X>?>`4*$sm$rcK&ggEH(lM=*0Uh5>ZZf(r1z_c^5zT(QN^ zxN4asBw`2?!TN%cH%|Rq{M0{_wnqLC=knmoCiYFF^#>pr<${?yDn7&uF4@ZNVWr^q zw?a$GENd_pOw592t(;EI1Z3WcRH*Jt)B%vY$Tt)D%mv}z&Ts`O&e)4bW^`vm*!cQT zDjpr^;)Z~SGIWeY&6+5MWzuMoPJ-l3n)MQc%TGkik#y%D)9s>AR6XhjA%07ToSz;T z=JAD*Zz%-qnOJ5hw=X;c+z+qEi2JaRToz~b z5HPeb{uFld<4R|xM4eJv#Hr&j4$1Ay^Ks>YlNHtO$(0IWKYHNU^Kg;uc`6;0%mm>L z44;J#5;>8=+{@wc5Uw!Y#T8i#M4wykaEy)pT$TF5mn?3unW3Da+D`H#RiDIg4B`pC z1;P=InNQ#R_kc`X1;EQ{oNN}^S*klxil@X|MSS!e6Mg9i%h7;&3pE>n(&xdHk|wOV z1Z?OFt#(Z(R8}K$2ZOxcRJI&FC3#7Kef+9H$d5%!gs3Uw(NZ;qH&~EqA+RHeg~T0l zn_1wD!Zbag`3Wop-jd&y^r2*ptZ1hSPJacPIyoSGj`HES(e)BA#GeF@wTX4;Mb%2$ zXu~4*bY0gWJ2s42t#5)yY5rDGRWsv}6FE6%mNGm=f_+pjaLtt&iC!Jzzm3m=F+- zVUNyvvQSr1g~c-PR!K(*GyamB%c52KUtdV@7yN@|;{1`I6B_BZ3>6*-!G-xY>_4-MkI2xlb6Ea-H0t4XrQH+!(c3-7vTwS%qz#!qcIHyLTo#UIFY_45g!?2$Bgm zR0}9!a(gACTk3tU`*IS@7_uchT7(wt}k0#eU75%8Ew~z^+LX-cr>ldKF%+UZbU|>N(u;f9*A`{GC2rGph(RRD{ zKbud!#MOmh7BKtK={|NW38P9@_7K<1TOY}*Q=x~5OPYtpfaMkPMgv(INS6p4ddyKq zJ=}#Kk;-Sfe73Op9llPbO@|FD%jCJxA)yc?Qvc{^IXj{qjWT*@S~@#BnZ?7a4qvCH z&Z5KP@#~pR^O`MYPCuog2PV)Yclgh5an|KB;NlFb5+%kl z%XsB-_G($5^?2J&y9-zU^5n5JpFF5!k$Pi@iOD@l1UOJ06?UCBMehMq&Ac2LDtY{&LLf7!}fk&)Z*DsJR!WO|ch%39*HZL1mkU(!) zERn}Al9JdXgVF}bX8Jg&lQ^~+i^GcTBR^czyXV^sG>8viLsSR+^rK&1lhF{x2`$lQ z)t>dw+W;!(hs*6>UPF&&@s$I9EV1J?EVtegGsb}6`zJ~RU0n>sj?--Xvt}s+*qMel z4uie=7?U+iw2w{?3<=KDl*&N8nE+1+3h`6HCw&9P^e&oE##IO%Q|a?MWS~ z?H*M6)|mtZxNaG<(lkzIhVZ~RQ-=|Z{c^r&vX2z-$*+m(9lNK)bWdGb`MoT+Av;0a zhgmll9ULnly_^&E!#kM6DBE;}U$(lK$45`$!PD2Xua_Lr5Lf8}T`9YVV1t635IS!s z^hr;7Cr|}TrP?vl4VLD zZBU_7C%Hn-teDJI*$PkVC=^@iz8t4mSf1*GNOfZ3Quf2_6~ab}0r-abX_tTjIfmy{ z2T4Kf(H&o?jFoZrTjm!wUW@jcnA-d3lGs@GOSVWduhk^sp;spgi2$~RDnKWGr^=OS z;nSQxB0LA_(sR$`i_9ZuCOc6^`3Ib&@30|AMGvqFah?n)D9EOv1QGkJLw5p)QcUL- z1+8?Zvj0|t6ICl}ly&XA<>yzgPCx%dD`!oOe-^Hi#1X4XB$us`4ezxrGyZGv7;=zs zt4Qdo3g;H$5SEIt?4f*%)+U;PT-F}?e+ zyW9WjffEo^7lT}tcO7_F5%t#$yu1D1cHlv5+Sa|=*LPfZ(o7CX55|%{-CmyV=gH?9 zy@V9(1nm!nW+;^(NJFs`h`Jo7?57l00{-PGh0QlON%jb3+PTnzvLth)@e&b2=@E|an(9BmbQ~NwSq9U`kO`@ zt=X1m2jTMEX@!|>Xe_LC$_1^L6&B3*$RxYb9yNAgv>8J>=IB{YOb|fQ3E)jb9qj5` zRlYjCzppZlX&}}*-s^oz4u|nXaJtgw_N!kfSOP$}sQ*(x2 zbuj1jJ35yj7kio6$|A%%moO zb?ui!Dl;|ka)=uJdvN#+lF{_q%V=AqdDR#ikKOJd-wsNUXxU9`|K_mQ$!Kz?S9Wb} z%fhQCCooXoN;)XS%D%@!mT3YBGEcGc50|cQrXiYw1ghq!rYr2<6I?H0X5_qLz;?-N zxUJ%C`hZwwf3AciCjKy+$AlTW17o8O9C#plljI4W7Yk_VV0%Q9p)I2Wc-R^nYo!tm&_ ziHd><_=j?^RR0&-=oX+nmw^%agRSI-@ow@3)S4#80FksB26UJxG2p^Q?@?%GV*G#lA*cuUf5lgyOXN)0_O4ZR~pF zDx-qNffS?h9~Cx4%o4qx2B5Zue8caFxk$^&M`={YjLf=+A@m9-L6Z^p4&NIup0!rIAbysS7{7!~t=hln z{$Z0BV^J3?G$^UWcP0YL6Mi+l5B}r8(wpD&2tGsc9;rpJ7Q#Uikz0cmBstJHFEN#6 zAG75G0f0MUK^3T|j~JmeOh*??D62TrB4vd;bPt7Moccu?Eb+Nm7qYdX0}OCj0wHvMgf1i_R)V9DEKIxp8q0% zgJlc)fq#^vV;*q!YO}{OjJ3A9emjB*<>QtBv>+50B?u_GE?hvwqRu}~K$CJoC@8s; z?>7YwO&krVQI=S>{Iq(`c5IOv1HZ{bfgd9(K?0C8dLHtiW&lvHNFayR&6x2hlLi3I z@jlL1f_fENrd96=XxC~mIR|0wOEEUor+7}}+}$qJc`zH9W`;nJ*A&1a)uflQeM;mN zW%7<>K~CT%Y^hub7yl~vL&qQJM;pRhrt{b^p?0cT;hC|YoWkfWnce^G-CG<2eE9q| zw1Mv)-#$=mn>p~^uxHI%6bg^@<4s8&%~j29wGIv+TFmG@N(k-R{KKD4>2b@uAQEH& z|MPq#J0OF+?7HNFTuO-|K2ERCuk(J#3>Sn9O+B5e7ePDqqQxFF5wIR8LP~5qQvf9n zy_-lp4H03?MHYnud$E4N=P|(cDD;0sTl@0>!#x?v9aac=t!>JvFrQlX;id4pkvjz{ z@*KCD$TkO&fw92^$H)|AWru5pRmtI4o30v|RLg6zhM>cZE1A=Pa{ClI%}F7JX6ja~ z0ForT08%0{bOPF_aE}9TRbgU#uLzJIv)|6ouF{G}y}q5-A4V#wQZbsMAdR47a@8Pg z9Px_af@)XDsn1(1a`{P59Cx0pi9nwP5eknNs)?UziZ#<#XUsQD_nCte>^z~&ubkKWl!_p)Oua(suGG%3d0g**e2G=}_!=`PHkdGCvM`q? zB>#|OX3Zwo4`s_Ef{i^Mm6K51%?pX$2uqLO{3WrxUrn!&)N9D-iWOk|>{waw5A$I? zB5W-`tKyq?y2|59p%H_QtV>h9_!b;bDQ!V#vc|ta;8)dS}kI$caB>S9h ziG{&81mhV3X;$eV^F03EoJLb=n1|DAABvp5KF>akIFKLBr=Mn*b_Qzu52eIP3hRiN zwCMQcG%6MKHVhZ*7Pxg>{LJ!m9alIjofjohT*D27CL;uQ9ftq*#qr7FU`hG_pru4A zDIV@djzl9SkiLZk0DB^tCP}0Gcf3TC9Yz@qQcVj`Du>FQ9~@$p_GK;A_puX>ztm|t zkV0iD$FnJlT{1mM=A*^LoMNB+j_AVSCtw&4@+t4a4 z3wJu+PEN8f)nss!6D8NxPb|_#v=gx%lAzY2@#qahwUDhB%qQ|yPfitARE8?~UXAxh zo58f9G#SwZ?U14;+M0k3K{XxL6l z;q@BW+Ow*fejdq_CBihoh0cT5QnvW&STyoW-gR4e>~xoE4Ec~H`W)c{Nmn^2PeTb$ zKbSsnfU8zPISlGy{;yaaESyw2F?djax)R8Y?B1P8A80`1(u{wfUQ!40f*Wk+6FEn? z@bSshZNTA~)I`hTP1&S94h%;ko4j)N0!Y_p3EZp+m7^{!Jg#cEN41i ze&%C(W;*={1;vd(S-gG5fYkH(5tTT$72-r=&H!~44l5S4Y@33=nrRafJ<3O!dTULE zR@3UZw$N(GE)mHeXnXP;Dmj%6EJ+RLIG#zI|VeowGSRl_a1z6T%fL-H712v`x80?;_1SZ2WknOcQm z-Q~1(8E$AX)q7j77q5+YbNu-9szglDSgh0&UaQn!czL8&a;ynX+m{?t$IH~p-cyrR zV7VdV-t|2uvug74{6zWNQoqcD8z|wXKrfo^59kNKnPD-<-u$bQ+{&mTB}Ot&J~^|G z&^L?9j@dOIekl@`D_I~figgAgaXr%q5;hKS<9WD70Nr8v3b@nX=(biN)>*|*H79$V> z;^-QCg~67{`ym&CsipaE93pRIey8FJ6@BWt_ z@;jujn(}0AohoQ$iOeoU#wVH;jm`ZF*91toD#Zbs5VYW3w(=gIE^|2&vY?U1aG0%f z>3Nq5T;jlxh+Az8!UciQq*fkp-w6PEXj;=oa$tqf3j_0AgXye%t;gfrhbGSB@0sEH zi9{so+>sm1JPyB;M_j#=WDR1nN3p`xZD!Kos2m?h%2h1L87?G|K8etq)=}MZ0X>r| z_@*BS<)L|?h8JCCuxstho=JsF4AU@4Ii6|KA;`&pL_!Dh$Y0fr<2X86$Ra6N)8@`7FRrYI%$evN!S*QpW0G{E{Sq_qD+eo#d1TAD+3eZj z@k_Nz)Ch5-=bA^0HbzlH4RoP$dvJLv%-;32pn|v~M^?gzJ;8U&+67eCVjqUeqm6X; z8teg8Np&fv&4d2k)i5X@va6Rcvcqn19FNppNNS}bcrRCH~*8eWQd1(B(#ecC9dxW0oWMv<*9L}%F~ zL{yDxd>B}u7rI_@WRL}AyxXRcE^J*X?76t!2BF)F3>ge@%!*Qf_n)y+tO>#}UdWO; zTddlz@PoS*BinwHEmwz&;R#f%9O$S?m;8AWS!q0{MH#m)`**!~7$78$ds9(%-}^u=krN(WYZ?`(y|BcoCJMorO)giuo;z?FbiAVW++$>2Q3O-98P&G zkOeA5OQs(wX3ZxR>y6_#5mNTT6@sPS=yt)FhQ%9p%kULXbSELvuId<;)cv_?g{$|R zmCWE7LB4gct1(EGPPuMhXY%B);INNB`0>k+H%<7*2On$7KR)|-Jn0|nVBn8=mr5&i zs<+M98>}!!NZAgxL2z&WKupjQxp;htVr2xllYl}`@atg!DvQpaqNgqC!^TEr$}gD$ zHW3(-?Gk<_pahD#Z{4FF=awhXrKx+<(G<;~u0m!7LWH1L>WYH^&sf|j!S|5tqoM?q zT`Fc0k9^PH=(r$M`F8W1H@j7)bC&Vz7T$^@qSg%kv?pD%*W?Sy!WT00o!IaE)MF#b za!s((WH}*F0=P!e2C-&7GQU-%FRimr*`K~A;6-hR)+$d1e42AC89BTnSHtbMx)XC$ zpp3c+_YqQneVfue4xB`h9OvZn5PodKK^A$ZpnaZw@kN?&MI3m1>lit&tk20UW!eNn zE%+DHyUzJQeq>$Mlvpf{awSprdU9#4Fj?E2-c5hlKjYBk%wx?PNRk)vr|E!blb59= zS%(I-!_AC9y7LsLpQH42NEsUKCfUs|6h1gtU=%LWRh%LV{c>!ccCX~3Ra7lS!ibVC><4dqyk3H5D>g= z=~8i&Ri3;h<6Qf>XE&y``(m68Vd2<_r@vJ?x~nT6-eF5wPgwxJd5m-buQEwc1fmMC zT*g+`$``4D7|5A4HVom9QNilkRX^Zs00C1L^|jt|s&^0t(#q_t5h~Vo2f(!Z!W)^H zxmo0h!Y|ZQOfpzJ+E`g8%8Y?^L~1tSrFKw^?fhREw*AzeL7sN;-Moacv?!+6R%IGe z;p5(Ys+kC|T9ac((mdj&zN>*y-hkvur?xOeq$4(!0&wBXOEP!uB}`qa5{V9^DK;Y7 zydrw^y5#q0G+5=d5M;BW5lSz_;}(7~=ooD@Qccr~J7{F{cyYP~{Oc3Puv&(M^o;S7 zP!G*Xe9OogCY|%uq7Uf8;X%dZ{_$@XfAdfCyFk@yBBL%8UcG|cc^V>BMJ`<{KiFZA zn1_^zS-!BrhPN;ofnEs;S-Es^a-_=895JEtLL;Rxzji+Xd=Q9HC~_vkF(a>&Qdv~J zp=N@EJIX^Ft^&#{(O?)+$Bc33l`G;vRli-il7SEeWe|v}*`s2HRg=!NaJ6Y2kf)DxEU~$ z;Xo4^;|&mR6xHcF@Unnx#kE&npPXO$ssA~>0uSi#)1}Bt2a#C`I*BY`P=+7cjb#`g z6g#~_1pc+2#J`Y;9_3HVE7rWOy^jTmC-8DZcOD8dAUrZiHd;I!gWXQPvTqoBIazO= zIr(%D&CM1Sqbes3PEm}6z~1DmOd62*vOpq`VY@ZtA&4*0TRXHEI*vA6vQ#Ao?lsp? z(T?8V%T1WrxEPEx{h7jXIk``ef{r{=m~k|68~rXO*KWvAdD=1!ZBA&kd3$}Ynq=#h zFi`Bg$4QFQtMd=%*M9MnI5)e|W_2p76Q3?6*pY=O>dH=cyvX~=@2C-RqxR9a6a(8; z34!5rojViM*$P-EqvkRaPx)GTb)85IM3ZQ_b5f;HoMg^X5(k6~Wp3Gx;{la3Y%4x%C-WGLHjr;q-2y#>D69tINi4>E0CF$;{K z3{Ll+SPAk~3};#121($jU_8X5-~37KiYIW{E!i>b&(l+SaY(H-2Sk&?CN>u58eTXl zM2FaA#F)Ia8kJt1?tpW94Cg`|YA7QQw1Nq-`q3@_xDyS@m7kb zuvrmrd!HPgJwD(62H>pW2y`@vujX1ty@hM>_9P~V5;6+rhKC{^l9|}{)xSs1Ut^IO z4J?L7(qJT1P$%%bXR{}4i>+W8ef*@MymxyP*Fm8%7=kkf1^uPeL34T*PRyO`HNKvQ6 z$Ofx)UJHcA8k(L@FG))Q)yCq*Z$e+FIU%xhboSa;+`8=4Z}CYW9Z!XcgwJ~Vh z>GrhMfKKk(Sj?6;FrPL1lf%P<$L#C`D&_1Dd8~UY_9UA(YBN7bgh4;8oV!82%r-;_ zTW*hTjoKNtdWKfGyK7LN}>#3=9-6143ZXu+2X9E8_>LaUyzRPzv7wx|1Diark83EYLhCbxwx z-M~;`!Z^qTh@lheamj6RCaG+s`SigvkSC1T?yCR$-~RV|-u$||<-s#8{1g*=N=xkX z)i`B@TFJ$+Ye5YoaR5Of})wC-_V4UILsEAv9FO?R!5nJ_22Z}`|OU-51z zJy(${p=E$ctf_3qZ9;UAZ2JOMW&iS&#~kksCbM-LoB0GKgQPfpjgzv2*1;6NPg*%( z3Ge`%L~eT6aQczbc|8KgZ#aF+=uOA{=Iv)EbnQ}#W`$h!$5J`GYD#IkF$r%9BcLo3 zWy7XYS-zt@VrAba3`fn_usg?hL(_HuhQMsxfW+>)22rEaa%QuPqhcPT&{R0eDbvby zS#xJgBcyoj&!Y5e38?42c<|?sXZ_!YXB@MfU2|nMrK=-^#|EN$L8GuGu~`y=dI@l3 zmo|GCL~mYzrsPBfqBM(n#(gU}@5-l>er<6|s|()XXdS6L2b>@ki&l1bQ`g-H0}yfN zwzoWx6oCGLC$VKUODQH>CPU;b6oaPQv^sytYz2W*&O9hMIIu3rK17eK+c1qvK{-oV$ zomkYZ5=L?_I`TFDq{!~I@7+I}Q&DrQF`?q0_q6~TQ~%xm6P?SfNYW8mKUnKR5u#^I zgd_Ma$1|7Lp5Y!DhC;?uLxeHK7-2ZY99S5X-3@|>b-D<@#9_rZUs~PXsKb2&`s-7H zr24zvLk09*>{zFf0+IOK$9cfcA_Q(4r*%&hlVN;iD`^XYw!W+%G@&O&@Dq?C{k+el zQYKi^okp7aONV^x?D|eQGIeRCTM%Kt9Fjf(Ppu*NuDZy^`7YLTipYv_K+oyLi^$Dp zoDwvHoQCgdGc5=rR0;cOxU!qu5Y^MuuJAFKZy z6eg`n`O(R_1aA~(u>>@}6Fwp=4t(HfaYJH@V|W-L;1(x4$n((xSjnjWo9yO;X#EzQ z;O5N<;8}#WaNtJtZfr8)X1V0TMZrN5Bg`lV=nJgS5xgiDav7sQdGpDFQ@z-lVn_p81wxW9j z+b3CR*Lsb$Dfimdb1Xom!La7q-J(M%8hIyVsz17&F^>Co;NlRha>tJF?(b!e4ObVby9rD(a80KBr2bG{~TMg=GmfL z+8<6*S_rd%Lmf{~wWexVzB`hECFIquhxf#OwNH|l*c6z6w?#NO7r4mKZWhz6BPY)P7BK!+s` zvg~%q@)w~^S%_r-x=J9OWA}0PcUf&Ld$dFiDQqj2uw7r&67^(`Zwl3lpxec;?z<4E zxFLoeHp`Gw7)cwvg-Ep|l4yo@zm7KaYtccdL?CIfWxig+Z_NWk%6w)nlI~l?+)LTa ziO{l_)ZEi)jEm*$>EnME#FPgfEEI@GF_7=0QVf~4$bo8fZ+)@1>l+n)=V^VPWUU~Z z;d}_xfi?+FRG88gTH;CwqVNyto;1Ei*VW|l@tg0LIE8vG#Zai72yQ|Zd{d>b&~2b7 zvd&l^R-E(*gSH;Bj`LPR`0_?sqhDl%Sa32LLz=!Ff<4%*brr9oomn>Gycr)s;qUdEXk}NpW8W)6qeBuS6`RdV&Z$hNn;$j7vj2BTC$en)7 zXiMzk=9VcZshatmn!F5u_*J=FkPW&A59fDb+qDf`R5(vdE}f`dHf!@j3se47wBN;9 zuFX2u!jDoJiiEZ>wb^le^xw2iN7IwU>r7;I$si`Tn0`qH8HmWIbcsO`8XxF7)h6>Y zfx_99aRzw8G?#&fheD_Ifld2ac$et=ndHlik<;mAZpp>pI+LE4z#onTX#p7ibMhzQ zwJu^ViecC&Qma9@@iS!P{P=a7j>s7^NgboIe$Z_{d3M$qYC3RA9C*j7WCD^XyNS@$ zJ1Nq1N7&@}k-2Im@|>$`(a;&^>6CJN{#<=&l@?HhP;qBCwOl*NpgK%#Y?lhpk>Ec# zq-O#8Tx=D&-pav$S$a~`(RK-&O~JX<_pzQlOwoPi*#(-a)rKmWs6IsN^-cp05~AIf z7B@rDp2<3l=ZgC6;;dJmFt#v0xQQek`i}5E`3_l35My$q$gqROPHn*@iIq(#DO|@w zX}F?4I#ao;H~`n#jgPKgy{fxdRma|u>}XM+l+Xh8Q8uzpa#U5R=3W?1zYpHhKoL;N|4_Sg^`w>B}ykaH6KFavZ*6IO5Que^L^lA=_Eox?E zjd1sxwW1{p!1V&)fW_|Y|I813duPM4g$4|KB{G){^vpji-5Bd$g<@Ewz2q^k%=f@{)KK3-+KBwO&sJ!J(wXjT8b_(G`SWsBcDGGx(viXP={#1&?fe>e*9oO(Lk`)b!d3urGK!K&e;q1$^8MP8^w+7j~q*7L)MM(r{Rad4(lp6Cx z^ky9l?aR!t)uK$)%m$WAogCGHYspq{w2Tu3)L;s*`#y_AO1O;bD^dej(3ePnNS4w) zQE-J!EF8~5QYsqp8AXa+PIU?Ye6@#*G!b&V0!|3Ou--}hf#T{TC@B>Qw#KUdLJaid zxAiG{`lxhz`Kq939Jt2dr=qA3e?lyYZ@TT1PKooate#1ev zl(Gvvm&ylZ9MDp|F6tbcz0E>AN7Ym+pJEP~Dj7b6rxYf>z(|h>7wnd$w&8@DaPxv)9pF*DK`SgIwmp$)Nl2f( zV6*yl*KnC&`KWDmr9Sv+2(2jq3d_Yg)6@F_upXW&tU5xk$`q{=pLxh|sI&x8*TbSl zsl|)0SGQMVR<$LEP5kWYk3=h2)3Y2UfB9UnRN*T*DmC@ef>~cMKqRWilN5BX^8!x1 z54$_Nye^#emZArxpgz|G$Mn@lZWItdVAkwSUwugP02aLD!vQ7(ED35s&wK1EJ}*v| zm)`t-dD$D~xUfqlE-jXq|3mZKvf)@CMOrAy7y%NIX5_<-$xZ-y<*c&aGLR5EnB}5C zvgtAG&C6ggP@1%J$jtzmVcDmG*-VEibrJ$y$H3<-Sb+vh4*Y{nk?9I3uX4mJxyv!8RRi)ONs`bA4+2EaeW5Vwik72&)uLB`i=nGiv5NjjS{(nL8SNjn9fQbgbcZ)njDDQLCH6?cGvD za9%*#un=AzzPz#b^Q#J=HF=(91#?nwJR=6G6B4x{RmKhUINCRg)qo9S3bs2?G_H@LHdbFesCGrz?7MNiIwcP_(JFc0*rSUbN zmne0$p}6F6dg$`1%Nfl9i*!DEbi#%VyiO9F8p5ir@?;wSmTG*A2)3s7mM~XcRa(0ZJW^)QgE&nGox)s7TLA zuR{R0vK`q`f{Pdq?XO zmKdK_cc-XybrU400tpc5xc+MNoV9(~G!|q_XLo7)D@o$59JAemZPjO>SY~|mo0cfT za+B1l@>sB$*NDBP`AO8o@R>#Ns-ZdpJ5!g#@)xlP+9;g;&5Kf3>Qm-qgjE%2ko)FF zU0cjiCt67MeUG$w4m1vn+dY-kh?nm{VY)ub8` zN){w;Nz%jyYnCx4J6JMcV0uaLG?!6!*yOb&F5P4s>N*t>H#CgeIt7ozc$WM}XeykhOwACO`zN5WtaFIJK%1Vt`F{WCIQCScZsRj0 zR_S}SPp!OENK?ivOazgvRV;i5G%{A)LlYQK#b$9Vw5$gmR|to!w!+W(&ecO%g?P)meHc_!mIoMZf}ir3ui=jx}>{a);u_8HcPRX+2cG z&N(b7u}RpeFc}L_u2GqC354lQitObbw{JMykecOolL1RSltj1~rz@Z)_cPhv18dEO zjQ0Q}DG$WVAAN@;aoGlb(3X2h*_G{5HYQ@`n|@zjo;>7$ApV0tweIt_`hx)jyf~$~ zyXM*1^Wz`A*I587Aoo^qaQWOey;KVT6D!x%Qx7YJT$S^N zSZ7Psfs-X{ljV9>B#EGWwsvvwN$P<09P z+e)&zOryg%#bf6@NuDAzfZU!XjYINSQ}zJDy^T4BfAv7gDUIuJci0-t>4*70PyPMo3>|JB(R zs+YQK(9a#I~F>dEwqch#k?N{*mW!1;5i z7B>xZK)5hLf)+r8XL7H6FRJIK!l8&YK9Y~6meS?^1`-N)pg$~hoRQcw1IF$;4q8@) ztvaqynx)Xt^w>fP*v6JhN7`9Sh4a$oJdSRU@TH}%e7_-UF$g*h7^Y^22;4(KXxkC9 z*$D~J@ZaqG1@;QcLoIQnuUQjwzxo@sBd8ewNuI2Bb&yor1h|bXI(61)=60DZ)YW6~ zjZ#cR<2|V0SC!eCCMwY2*EEGN(1xvPg~q;|%6tk&QFBZIK-i-4J!pDJ&4&Kwl5ASO zA3B*%kg zmoQA_cf~q0ED+Q>ohPOY7$7y+P=cQi5%a5nCQ%Qr{f@*=${9x_xc;e*$A8iY_LZ1#Qu7L&0MrN zrmPHMR#~|N=?XxgzZ5kne|&X_iJWXoT$pZaIz5-3Q+f?c)i^B$9xV2sgj0OG)RHtf z>_M96ST>Sy$fq}dJUizMB?}sKx+vs$@k+f|Oq%66N?4MsfH)!DK$J^06mwQqbjAub zkl1GDs3O?LATjEu^&Vzcc9NCNr=_bLHFqb8<8N1BGp3k6tf33Wrfw|((p~vA)rFAA zoyKTiyuN!x&B*ENU(u>V;}Y@`Q>0lvdyvz%9ga|^@5>!$OC3+!tyhFISq+G#eR#We z+nCj42Q^M0G;&=2LTTl*LzN@e9lP)jBBuW;>m{iNnBI?iNp-B8-sDE*>})EY5B z2=Y~h5?fhVP*&eC>dS_*SLiO`xkMeAj-tv2kK6bx2cTu;l%7t1{oui_2u;Mh4yA#W zV|6X*%EF0yVrGa?)iA$&v{wQ|8lkUXMkjNqgq%OF>d6KGhL?(Z9E zU>lI0&zIv~9ctSD;p~gW>+P%8KKkWHAG%1Ny?E4*!7&iB_9)j)W1m4w=;BL_dw&0* zaa_-FT>a?hKkvqoy*h@e)#h%S#Ywb$8QnZI>bw_ zX{ew#hG~c!2Ipz~;)~WQA_vibk7ws&q4N8!8Wyan0J|s&svNAa*?7RBaYm*>gh2fv=o1$uh82k}YeN>*Z`06m zv465H-FksxqXkd1tv_UprL#pJUPR*R3~w!S9u5sXKSVnAEJF>)F$SsMs_PycZRuvs z5NVk+re`As!qxDQu8jjm2de-^VaYfymuU<0>2JfSxBPO~Vg{XdfMgQX5Frq?#b3jDi(y%NM6BNK07~BN~dto)hCtPe@sHD@`qxAoxx#* zR<)}i&^u3$WKfQ%dnYRu%+=Gesj5WA%VN3Mky@=y`kb9{cU}z%ZPehJQXuv`2!d|1 zmtaRZC&E#N6Lt}o79AC>SrI(Jv%ascv?2PI^0r_D7!`;ujEfp*BZQLik1BW!l1B5a zNmsc!(d)XBn8|?APdbsx=S>0W_BG;-u5FWE>rDjo&&{X%XYq#&4&?Ks#LhsY7u)Rc z5pD{to({JAb9kfC6PP}T#BrSyUt~O4l}&43C_u6q|C)Sr_?rGv2g^y;`c8DT)kG^e zc|lWd{_}ij`aemf_DIWCe=H|Oxe_NSsU`x>cxyiieFs^SjSD2WWHS5DV7y$iN5E>! z$#6O)A31XXe$)pg;be0Y{`A_%KTRA@GL%Y356-d\n" "Language-Team: Portuguese (Brazil) \n" @@ -17,7 +17,7 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=n > 1;\n" -"X-Generator: Weblate 4.8-dev\n" +"X-Generator: Weblate 4.8.1-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -3156,11 +3156,11 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:545 msgid "Choosing a versioning scheme" -msgstr "" +msgstr "Escolhendo um esquema de versionamento" #: ../source/guides/distributing-packages-using-setuptools.rst:548 msgid "Standards compliance for interoperability" -msgstr "" +msgstr "Conformidade de padrões para interoperabilidade" #: ../source/guides/distributing-packages-using-setuptools.rst:550 msgid "" diff --git a/locales/ro/LC_MESSAGES/messages.mo b/locales/ro/LC_MESSAGES/messages.mo deleted file mode 100644 index 0a3a18e1afc826a59cc09f1f2c6b6b0fb416ec03..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 845 zcmcIi&2G~`5MH1c%n76-kT}eRs!`e4DF`AbDTKy>NO5C1DSzU!wWrR4vuoDt(n!7W z44il!BzOv*g>hY}9JnDy`t;4%-|qbE{JORAm62@_?h*O~m++oY+npW@PDOKXeLcip8fEvD_yctm$$Tbs-+nvP4i zF4iqX@=;_`WxQD1B~?~SjCL>Y_Q7Z;oP@z;!=1M0>}zFdG<>lxs1u8))-7@&RS%M- zFeTc-;bP3Ym%6&4V>CQaiB2h@58WeaohYx2$oW{CRq2B&&ckx>um_DhP=i4So`MHH zY?JT7*%>+aJDvx7^mS_snxGH6UaLjQ4k>qg&Kv#$6`E#*ubTnDqjs04c;c`Knif3G?}KXRr{K}x(UXFp1?&J{0rr9#N);qa@J{d;a2Lo>gKvOs;J<+C|Iw3! z;8oycQ02P76Tm)DUw05pM<6?g}skz7eFU;6vca z;8(y9{GG?67|aCXGr_~a`QVA*MLzuskJos-2|R%N?*m^7-UsdnZUqkl9|!ptJk1}? z*RMd;e+ZpXzGJ|1!IMCZdk7SLt_L;#`+WRUp!)kAQ2F+O$VY+4fy#ddcqq66R6qJb z%~KH+-8O)lpIbq-`!P`EKko5M9)AQX--{sff#5Nq%AX3V-E+Xh!OK9kR|YlD*MREp zZ9e{S@Cf2x09F2gIhWD0-{~Rqs0RW#Ek-ZwEE*2f_UnL0!4pC8#r>eh_b{mW-wCSU-vD0>{v1?4e(f=s=H};M zP~{Hy7=jwd>7d#>6FeAv*yC=GUj$X(w?MW3V^Hn=8dUiMrn`1u3F`h)p!nfLAD;;F zFKFYB=6}%R<=`ubzY$csn?a4|4ji?x4 z2Rs%%UIB{kSA!bQJ3!6LJ)q|8VNi721&U8U2dW=m0*?g$6+9Yzai=SH9H{)0z(c@k zpy<#Aik^MoMDQ9=`5yMT6MQrAr$P1S9Ec!14^;nGf~xQJpvGSS#V6N*qU(*|zTmx} z`tzWVe+pDPp93|2Uj{XAP<*=H8mv@_zeTU9- z^ga?)J*R@|=QMBHu(D+L5*t*cp`Y0$4`PM6aQ!M)!_c~-MCsn#V-K0PTmZj z0d58-f}ip6pM#JfIF-p_ih@C~06qY|7Cdr+>sJ=kd~5*F_p8uz{6@!)Qc-v&jOKY-$k35#6(WKj9rLD6}MPwxkn zuk7(gfB$|^e6Sl7Uw+fy|0TFT@dN3+`gJI%_D%uS-wsgyoDFJS^n&8UBDf#;W-tR@ z4PFNR1XO*C&UN)I2gTogpwh1dMW46%`*(noiEjm84Sow$KleG$>A&MaM0ju#cmVi1 zQ2p!&wI0`lkUV$@)cpS&D84*$iL)!u1kWUX2{;kF1x$laf|}>!mO4JV3~VF*R#5dl z0`f2T5B`MUf@O|B20>Ui_z>6u{uC5_!tpZx3h+?yQc(TOdn|#65nl(Y{M*40d<0a#zYMCre*pIb ze+X(^KLclie*)FcnHRWm%?A}<0;=7ML6z?VRbLKN`|H8O!8d}U*Ug~D`yNpF-tW^N z0AEJ@qu_U61RsM(5WnLhH{Xweoy0#4ihutMo(L|v*wG~qir#MpXMxxG_|qQ0=<%x_ zzYUhj_kB?PxabmxeID~3hdo{ms{Sn=-vcfoeiwKa_*0N63MRhJ@%5WQSS)xSI1&6g zcno;trEVTNK$3!mpwjOJ+rXzl<^L53$%9uRe6$XVAgmZ{0~dn(z25CZmw~4fe+$?F zei&4~?|`epcK&b~+yX+f;8)-b@Z26}CvO6$5q}KSJpC9v4g61VK6qN%@l(#@TR_q4 zCh!&D`+WMtKK&D*_~IF`AN&TW_Gb4wzFOz;&ES2cUkxJKf=PYO&Z>gy&x1bx58#Ew z523Piz%^hy_z_U@`8(hV;Cv#IGyS0YRRqrhH-YDZPl1vf69ydJjs{zZF9y~A22gZ= z8axjC88`=g>7bJj=Yo@nZw9A;JHQn91F#c3Y>k_TW#DAuSAeep?+4Y7ANceWvyLuH zz@tfj1e6?q1{D9l_zjLf4h0tzKNUP1EP%?l71TWc$m6kV-FjFK-b(tNp!z*6=hj6T zJc{_$psgqHmBb(O_yzDp;@<()elX-o3Z{xqPIQBZ5x>-95!{dX)!+p129NIsk0gFK_#n6wlzi*G z++oGzwV>wxHc;(<1Uwyl0u-Hp2)-B$N^V^Hf}+PM-~r%SAWI{d4~ic5fd_)01t)_w zP<-(RP~$(k?Ch@af!!E zK+$;(sBv8mz7%{6JQ@51_zLj*;344eK#k*oH@f_@z*)rK3aZ>LP;~h`sQf<3_SC#ZXVAA&mjH=Q2c&3D7riZ9u58iTn-+% z(babeD0;jd)couL=YfY_>FQYp&Lw^$C^|d~P63a&%FW|EQ0prV?hmd3wJwXG=5;5i ze*P5Hc+cA8#DfBe;suZKXb?*~0T3u?aq9n`r01ghObuW{o& z8WcTG@p!RM-wgJX{$5ag`e*Pc@bGJ0yailMybIL$?)T|m_US(cFCl&Lb7yKBgasD2BEx71y&K|lQlsxz_csBSoa0z(C+g-js z@B-r7LGi&sH@I=m0uLvCIe0vH9jJCc2x@$v1qZ=@1eI^$jZS}D2A)d%4sas)X;ACr zr{KBZe}c2YbKl|YtLs74x7p(ZpzePHTm=3ZJP2I4*|onCJdt<>6koj?lsx${I0rmo zi=)Hq!5PFK0vCcm09(M+O_T*M1=XJsunHb~v)gCh0%|_?xdq=9co}#**#1s8p1%b} zkKcmlfQP@!>HCYoyNGWEXMxLab@TQPQ0wL%@DT8upy>D$umha%ZYNLXfYXTgg3A9M z@NDo|Q2Af}9;d%s!IOz!25SDV1kVJY^y&Ww&L@84ZI1sh1+~r|1Vx9Rfa+iSdmR=) z(f1+nG;k;QO7Oejf#7dJjZ;K80+Q2D+Iiavh?XMxi`0L{S5!PkKQ2A&9Z-0keyRp0{R*MUpHXTcCW_8v#a*emCH+Wjo3{?xz;;5R|F|9$WT@JFENc)&;9cn=1Z?=Vp5 z$Ad2ePXS*9>Ks({>-SIg*Xg54y6Jz2gy4AMe*<0yGL+y^!o`U^Cv*K8!skd|OVDpB z@uLaf<@yFoakAh|q-`MRx6VQEH1W-ZvX2jf;>))ZR{6a9f?8YaLCNmF0T&Z`xE=sjf0DR z>${S)*<5Rm_4_Q>QwZhRZ^&v{DZC*FCrT`|`lyU2Gv*PFnF;9BrR ze^2l(!p8~sD8lcTgq`FmSqy#6^&JHLK26v__;=y5vuZhtNK6#0h;(QlEzIFhth zt|t*@aD7IU0bHNBmL5(1ensRg(%wc`%ykODL2-gxnoFF-wA-sk#f%LZ$N`waprxWzM3fv6-ny`hC^XX@MdC*^D5%hc9r%Q%KzvceoN8r=``pe+CDx{sHU--|g>D1aG&y*a_fAh(AlXoPd}P zP6VT03l~oip7aSX65fA3l1Um|?P-xoYc zc&)$xp+x$TT)%wCdN3HK4MC+tVs-w{qDoJ?3j+F^vJxYn;gSVK6S za2Mef+r-MR2XZ_jVHY^@(pJ z?VW@^;_oL6`*gt)(#wS3aoz3HPXI&GUP-u`px-W!pXIupFom#{px=dr?Sz*QzDLk+ zyU+g!*H3Xh7n}n=M7WjkBtgG4VWGcX39j?kZ}IpY?*D*r2jQ!P=yxFZ|1*k!uOfap z;Tt~f5MO>G@lLM$ef-bFk0xA7{A1uF;Gy6=@KfL}LLb*{1pPkb(IS&4FUq9*v-!a? zkDyJSysSFZn<=^L6`67|(^m=e=^^fi#ZtPjlI_d5o2$y1FdYtN^8J}oDxaxVO6go! zt_WW{Y53OE|xjMi zvp!RtV zCG4i-*@0oJE2^ZF&JSkF;Xt7jmaD~Lp;XEAhs%d6YiOW9TdtI{z10e>m4o)FZ5^q$ z_SDoFx}273YvZ54Y)`dM)8+Kk)S0QaGu@@~c5pfE%#OCHL3_uvX=luA4?0@H3(~o4 zf4U;_i4aROl{C?G*qfmnnXp*x&1K7LxE)Mu30IYsZ{_-I-YDm92Au=hT&A<9ECRF? zhkL?urnHWMRMr=mlk8BsG#n08^UMu>?+iMNnPO+pw2m1)VYeG*&{@h1boMN*<|^4# zM2*F64$3|LZhxlSSIQPuNvf}quVnI-RAsoBNfj(Dookk{es9)rp;`)y>Atn;!OWas zZdk}?QaO#JTphA5GKcHeq$@^;B)P->LZ;k8iE?(Rn1d#z!W-baU~V6*#wZ;N^;WaF z3Ke8BFu>gYex}Y1bb8y2o|bT8XR*}T(>|lEXOh3WqHFH_rCs4*HQS$w?oT_Tejg4i z)8E1R&8gGk!sWi~+H57IM&ZXoxHdB!^{X6JHoar2%dbhBTP&{24A(hJg&akq(e(Fc zMOzk0zEH{77@~wyrVQ~It-2m1I#!>X%NfB6a8D^5$Yyf=()s?rf+(pBxlActq4ZFpznW85lGQfkUSCQV zi}WVWnGes0tJY;R>$Omq8xM#m>Wo`o!CcmGB2RBNFRsmOfX%ePX%5N^U!hXVhnFvo z7zy5RLO~h&!*T((V#LK_F5Ab5S-8E`e7|)!k=CCnN-X93hQpzBo+%!JnJHDu=0aBP znf1#V!Q4{cns7-rU)>PQt@dXrl;L8qituq+tH_5ENrF^nD4oqIQW#20dN7f;wxMLG zMMFJ>YB|iZd*g|Qry#N5;woa4ycu-cdu`X1e?&w$OA zBZMzD>fVL4URYlqr{qw&@BHrIoDxIR=#2N7yGXufHe~v$m2__|({O;Bji@KHs^Wbu%K3FJNu5_eSRHWRu2IdIn z<Ak{7j7 zQ^{n^1`G(MD4LnXO$H8E_DLq#P;yn+CeemM(zFt9(m<`z(bZtn>6oYL3qEl&oxoSTYF)Ohg_E&9n_`^V%&BlRWBWZB${^Wq*=YnFl67_g&7 z{aQb*94kE)(C{)9+R0-RvmTrtSnT#K;YqfXP6}VwcG>Dq^4N|t>?sZ-D+UTZtI^*! z%~{?EitY}S3RuI)R&U#8SP)oL(S0YKSYwh5zKoYxEJZ{*U4lBSZxd=hN2V0zReQ^` zNcMFNDJ5pm1QrB#-Bd>Fi)`I7i5JZ49+Q^Fs>gy1%cZ`s0z-|-;BKd}X0;C(bK9AQ zi#6JD??#)D(VcYZW2%fa9m1(nf;>*2G&CK{@I;kSnyp7S`+kd*%#_N$t!&&^D(-ReI%y6OYWy4v9mI*TUS4{+Koz82Wclzn|EmFMQ zIyaq<#OaJ65t$jBTV;n~QZ~9GLzOMKPjgo@g7Y%ND3Shha9&;}`ocn?U-~MXc;3S9 zNr5-;S}GeV!ICulpcNTy?T}MTGU-yDeqgCD!4H&21v~mD)nJ{ryQ!N51%S2E|KjwJ{AR_8__!ReQq) zx%4{7(jUgRX054IisjDM)OChfs zLMu&S2^?&2l3EI-L6w?B>wc2`1^vmC`q0Md99Pc2l)AuKxxvz`?L#3393^V0o?xl% z@qo34Ptn?_FUbV>Q$O{ z+6<8L4VFi{uThg2r#qPzEN6q_*H9!^p%Tf?v*!^jM4mw{$S6gFh$7k%)VU>P+i~)( zlX=vXmExP&qNQ}bsN2aek6o=}>=oLt-;CG(a+#TaPZW)-S}GQhdX4P9d>9`VmYUDo zj``&;J37Ojo^rLn5ccN>U~Ffj6pf8KLXWBSQUpCcV+##ehn|0-xY7Ewn%**dGO9ar z+4=rOtHQehFtNi{FGb}OSg~MUIHSEiTvC7?bxMF5TwpH9&QRhF0kwYp`j!Fg5$!Tf zM9o{=)k?Wm%C(-^vZgW=tiX6>S<{(*Uz#LYP$Eho{G6a(&alMz8fKZ*#u(6_r!*9&6O{i!-=sr8db$H6&u0eHI^W z=$;wInGKLsd34_fE!R_LxKgJPW!qns*A%L`{%|c;LYVF?R5AUHb%PZ?YawROEIO=I z&3|v>2cw%8vq9^_){eM7%LaQ`dE_xk`^$k#Ay4E6PSP7E2lH-cFtWr=@NzK} zpW1XxozC`hB~H|QAy*ibc3rjE5F2Sw<(;*5jMN z!xZ+)TP;60Mov1CqPBSx%XiM0I(2G`6_cw9dFs?Mi_UdU?SAF zKgDW@j9a)tnMG^SaJ-7^8>}8z-lVKwzER<5fFchrGi_^;3M}E7EmO^kg(Nv`xM+&| zeiAsvqv6On4cl7U8=YQm#BXADS1o)~xIUA^?qwol$yF$oPYfZt_k`pMxWaUtm>#zC z!8Ms&5x*89C>yyMG)LLI+a;Lf!uf)m)1*6h{OQSw$_2yVQ5(>yS;@(LbvIq1ib9x< z59DBlY7t{vF0lA0+JqkZo}B)yka60C+Z`MBKp{unA|MXvHCm`}hq>ZJ6t}r%&B|># zx+b#>RC^(3f5w<_E2E>KU=?E3nHS5Weby@TL>h~97oo-m2!BQkhvV+Bw4=R)m9xsm zq~7_dEt6!&@TMgj1+2TH%yu)f+WgicSj8g&Jv|6?77=N2hs=oV)NPz};pJ5XEfUps1QW0rM2_=a44zBeqH`arFrCWf;s!3}i; zF7yXBz9#2OiB^JnkmBJ)snOw$FX9=?3<_^UT;O+T9-{@JZSVzBaekAK&jc5yOBpmV zcISneUME1vW%q{)hz7matr{8BDKoI2jI@tlad=*qp9KxYsE$5?0M{Kh*g%f^c+LW-E zDd5?oW|n~`rs*m+Wz{_QeU(|BCy2B)rbIEzGb7n6%ygu7e;OI-plEs_--X^m&PMX2 zq)S{%;H2O}POn+XAYMhLH!_iA0$s>~*I=i~Gx}gAiBFO=!77qb)9tJx`A)*QNvkNz zTIYOOMOx%kR+8zHtg*q!@!o;pVi<|Q3biLTykY0qM(%JtN-%im*z`FpWfhb+R2NfB zy_leC=^Gdf)Nxs3bqBi1XDT!0P)t<{DLc2Q+i0CZ&s>~Q>oVF4W!n1YAV}1vy579uAo}F0MCXdy{G|N6-4!y6#y2@J^FYdy`yL4!Zgcjj45>vVjz#brs^2x>Gs>}JPHtbVhSAaLHu%G>c*fW}Lffc~)#01Mp2g)d#zWjtZ*{OtJ9_#^ z?YI`Y^2Dpy;o-b=p5x%g!N8*Kt_`E;yoIeyD>)qr@IzIKY41N$CkI?Yoz4q#nGGA_ zP7Em4qE!u>+JLeJy5H(-1Xm~S!9ipUlgODcezn9j_T>uI{+2<@;HI7jLoAO`r_~M5 zRl_+(VQsZOAXX+WM6A>n^g4H3`4aXzY~DKP4C)kfrz4V-EVh)Z&gSgA?79ST))KQJ zp1cOb!7|`C%6G5H4pizb_F^BlU=!zg;ELUaN=^upIsM44?0W=dR*Gv{4k0f+a=~*ai(i3?eAG{tmEDJbg{3LPIkN;CABa+ zE|c42#1$sHH(X4&!h3SqkQcU%wb>|7UeD^5#LY%km$)}trP-|u(wIV6d2tUkq;)Ql zr_@AS>nP&c6DC?(Tg=5dLf zCyBK%X|NO}%)QUnKgtttR-_cMNgFnmXF%Yd3a-*txp3t&wmL0^O=UI_-H^ijqPxAl zc3_y`79D9BceCR4WL#@+uUsxyXnMm`vp$M_Nowx=MDY+BnJ+0uoU<;FtThMz&DKJLVUmX{$_Kz6^(!;CW$uAnC zm<_ZeLD3rWxGs;KAkbAx=+rJ(JYKQdJzfzE;Qt8L3v#E$l;#wsXhoZw7YgC3p;8`wu+MqlpLH4?*XmZOS-PMiLDexkB zwTR;*h;P0@B8%B%1e-4%Y@?h4#F~QYOpYKZt{tQYZvR+%5yNG-)QPl>S+h@Ynm%%2iyuNc&Kp@HqZgDbFV z;RidsFU98)i~FPFwa##bo^Zmhp2*PClP0Xl=n09`((+)oKXnckUTS5bGn}ye{FL*% za#S`SGr2RoxNGi;)Y9`)^XG<(&hK2h`1DK8U)D82$E~TADAqCtSfSJzE?Bi>Nw{q8 z(k@Ptm(E?hTBc5zmw5E6)8@U^blF+>X455zKYP{61*sYJ zd>Riv*A&lSL3nMjX7pw&6PD*}?VxCe%AH}pXwmZQjT-rXZN)OLm=SJEDhjNIsIyNimiC#Vx6*V)BZMaZ$)awM0$B_Ikw z-nXdT&G5ETXlpbG*IPAv{m7<~%^~BVJM?!4k?z>(^?csHsNJi|YajPrt35`iw=(Xn zwZ|DdV@Xubu#6&)kxRp;5G`+I5W7Zh7`Y}?VU3$xJ8F;6Gf`lhDC=#V(`s7-9&z|D zdS#<_m-T|_)wFJ^J;IdkFj8F$LLE2TVh>U0Mx(uEn~SaVRkN+h+OAhRYR#wH{8t*- zlOtQ2wX!3q-A6?`Yfpw_-u|dvi$E*OEettIN8s&npL zd)K8&tx(0SB`1}xg-jx(sAdg_!F>&SA;xMjE`35W1v+mR18P}H=ItR0T~uDgZ5RM& zO!cR+eVz8wOp{)*uxwb=QRmJbayq!zYE*s11@&ef&HP$$qJ~a7SxJ45YXX>Ri8zzM zd(Th3+abXwiM){;_MVp|vD?v+88S(ae4@-POov;Dwnh@2v0jQnw}=x)wm{3Ps9}q! zzg>jm1|6oDgtr^RuG$W0b(7*sr-Nd06MvGRUVJb#O2T#Ox@N*^6wAQ+HY?UsI979Q zJZpSUL-c(7`o(>=uJ#~^H#K88$pUM5qmAcnOaXkcidN=CMb^s3wV$vwn2I;G+Lr`k4 zY4Rn@w}rDty@EBTCmeZ)Ix?PwX5`XA-kOnyW|W>BTHI6%TNo2P%E+#v9;1-S9yN)s zrpu%nIdvPhG%`ghPb4&M5wS+Iv6ecG$RwdMiLwNnYeL4bxvNEj-rPtptVnbi^McwL zO6!d=&4sas6r|~Fr%}Z%*fb1M%E<(o_}zrvnju>=woW~h*nmyJia4s<=^JH@4HQv8H%Ez}hWFoU zx6y(rsEAvnq;7CSmML(JD2W(i_-ZeH>BO=w0p7}*c>PvQg{uEA~(*bka2(?mE^#x^=)z+2$njj*cQ9*)uNG@oQ;#>(nq z57qeEB|3vO%0#n^q6KGUVA_qm9g*YrOte60ao8y9hobU{Nc_NwUXWesgqs$eY(32u zn|VUrk}|P@j%O;I9)W?~c3z{|(Wpm6Ia%nt4!2sXTm{1CsrIKbS+Vt(3*Sifx6)+sSOIHA^tlgct%fwSZy!n ziY*{#*)f=1R+Y(Ytq}=nkxn~J1gRA92k7|Y*qvtln~~^btQV)FjAt|H;z4aU9uSAv z=;0(7Fg^ine38`*LuqoiR-Iu26Wu{q*xVYE$-4EN^#}=C%i=BH(|cf_r`+C5(kk8? zx}_(Ee5VmnvVG5}w_ly_(d2`+a}qRkIbp@!OG|DiAqB(W%@d@lwd{#$9FtSayK!sn z2ZPNm(OPHzoiXKLuA~i0lcuQ|pN1_}BSJZ2K4K-->`t^8Meo&A(x&+)DRE=n38UGy zHL0cBpjG5K9pBrhNkqSDBwjB{=gI4UU=$OuP{vrod#Micv9e4oYaFhIx}TFerR5}9 zqIKi4*pY#$#L-LKwkg`~$RUMT(-gT5LyiM&Zn!YpLR? z$R==`edvay6bmV*3>D?2;#dMoH7nEO^{ixxM4HAMJB?fw^vT&VyL>@tXtHvg&risW zNZsb(rt3I88lpVIXim?%yT~!CnAD0rCGu#-SOKDsIAIrhY80t$jX9(3dabVUGyqHL z0fu`^ZI9Sh&MA#v%F3ydF=@~7)^P*RqfY(SLfQ_GsAFAofWgml4v)j*;w|o@=rzXJ zVe6U9`9&iwBy!M>i4f*~EF~o8$PkNyy}q-ILe)0TNrOfj_gXDoWYxcQt<-q`#h_s& z5lqg!*iaiS&L}^7; zWI|HeDA9_f9@`gf5@Sa%uYDsUZ($-Mzp)nt@tTSp))EGqjD{VKEgYMJXg?=HyIiJ` zBU?!`=SN_Yr>-GHVBeU;)V+LVu1KlP-4kGyFnp7e-bDwkMi+}m*k^2MnF z4?*#&FGp&8D_~SnQ{d(>G->3ST(Z{ux5j~H^N8yuai4(yMyXt8C#ii*B#KS6HcVkq zFy1uU95qoXkd3)&Qd0vxWcbUe+K@;?_*C3GfKBe0ypa53bwU)=^pd=hb~d@EmaW6M zp~hA&ZbwwfUpmfBgvIT(TgJaFNkTVWyIdPhp{LCf9SiqjH9XH+oygG6?Hc+kp)~$j z8oYYsuFvfYC}p$m&a}J>a{Qi-ZxfAMMuN_oKq`a?2MNvR@cT5Iod%WEw6TU95+HVv zByJhcOEZ=USX|BOCVA{90TQdzuMcr2I+&@$Tx#r&_j8VIkvZE6*G5MIjm4Vv1%?m_ z)s}pCcmU!RU`?A|X<87$Cq1Dx6MN09jvH;!ppIkwSvqE8 z*zkFVnmljTdlQJ-1aIX?Q(9yvpD2jF-QYjiV7ZgtLoX(^G&Kd{qlBmb2~!EN@B`lSgLhUr{qenmbQ|G^38M5JS^Vac7?hgUT=QM)H5mp0NoHeVP1JW0-kL@dj& zL-M-Kt1}qwfgaLEyH69R<8H@SKT*|kYN(RYi+QDWp$I#4%n93nbK#O?|4aGG;IM5( z)FTs;J|Y5}__Kqmk+($(R5L8P^G7Fp`a%a%MkWL^=qwfqS6Uv~GU+T^*48~uvKg-S z5bA00lY0n2{6T*IxXSa&KU#En7n`aKk?m~fY{MqEsH}1l^$)25^D*q${U`qPUB}!? z^b%G>8YL3MuU>JQlu9TEH&)~O=Nbx)$xMB&=NiT|-8jFaJK#lia!LKAyOD-5HzUH{ zjKsSkH)0bT4F)tyLqM^?wQTeJb_E#q$&$Zz1>VI}tJO$w;|*$1JZK7d)rl~B_$$Hu z%!T?V26TGG+*wjiG9%0c;~4apiwoL3~ZL|g@y^mBZeMs7@rTQk$l9?)#iH!VyY0o--UfWPre2KHL$-alDW zlUUOuq>Nvdc1#0$p0LlYF}D)sf;Z=7wC3bTod&sW7U{5OA^~~ty?w_ z$OxH;s@!z7GeHoU>Z2YW@&Zuj1RA>a!fbcsqd%c{ro4#aeE&K%tq;m*WM(MzvPbsD zsoEP-rsT%>>twJssE_e_Snrk%$>u74aNriX$|cz4i@L|;Bc9{BC~J}^tMERC#uGrS zDd}AXku0>cX`$!kXx~doKUl|KOx51C_Q>YZ-}w0}McWGh!d2pt-Wx&;^st9V4ra*dm6T3mbz2jPYL+{DmWgM*%dMN;{>e{l?eWw6xdpbis zOFMFN{nSwE4Eu67E6Ll@kHhTJ$avf9huGVjSEkjd)udAy6K=8?GCjQ?UMtdUXJ;@kv@a93 zV1%%wboyd*;-B`?5l19B67N(%9s915lW8({BwQe`99uh$Y$6y7?q(9?v0}wL$>(wg zwY#~&{4!1QFvwf(wsou!<0PWZ9~YSzOG2crc{t?sa?%!Q0;&_MmOSAK0HB}Oes>y(!}(0e55xA3Q( zdb|-{Y-nX`^rkk0b$yVmd>fDUZ;sz{XjV#d+R(;m-$>Gs8rx{|;<5y^cD->Cxe6P0 zIO>dvb;)|fB^ztUvX$uW=!B?xEl{wCpS}J>0ef+1f~Vd&#Trdf|C$ zy<{MP>fGozauBO}Y{KcNSV3&&*kv>Y^);^=4+1DV604_2Y*Krw)ivrOyu(kLToVZF zkTe-^{$cFVL}t<@Ld+Ji(*EGs>70lZJLzNm5FSl6&`%P|EK|gn^M}aJv(pImK5~UH zF5a}~V`8l6CRQRH(PL`jR+!t{i6lHF@ekiRah(3#EbF4nY2sV;!aDg$h z&Z>;@ZFSfl?!>TmH=R!yV3rmB(4wrn-E9lUyfS?{tPn36eK52%+hV8d^yrr4yw(fn zh4JA7y#Ia#hbEqJN0JW*;ONKn5Z517X%t>F20zi?)|!+Kld(c0wnx#r*SQG;ma|d3 zY|DXhN0ytp?CUc|Ktf)b3@{>aWc(=S?0$ zOvpTEW4gJpb;XQhH6Y;lpSRV&Ru?H2eXI_}a%Vh$i82kcw9#vA(~rVs!f}VH`le=Y zV<9<@DKOqCwNroYp@rM1Iu?r%(LF^UeFTr@jCtykN1P`Xa$ZVi;4U{s@Se9f9TSS} z?Ipy92FP32fljI>T>hHRWOo{J$Dh-C9(go)?Ixso?To`-SAIUVk15G^W^d)H+W4(JtQK@o9OG_$Y--8(y&M&&lsX$8js(JSmHp{ShOa12DiyA zFu_KKYg@jtI|4*Hw=t+=wJgh=2b`e|?90fU(%7B&grVxJJ(5Cb%kV7gU~$U! z)2_k$z$FgGoZpVH`Mh29u~o>tnTtzbIB(HiG8 zNlK-uz;i0yda7l|sE%J4*-qMJHL4r6(q9 z+D&g#X%h)zNsv`}d~x^0Jv5R1BJYdN6eOXMn~eT0`T)JBxd%p7z4 zj8i6ZkvZcBj~SI>x!nO5co*4wH2=0Es@)my6Su41O*@gWqDF~b2rj0M++?xNv%y9j zPKMZqvWa?*{*UXt@?W@;n+h4mAIt#zA}0Qmy?J`~_IXUJ#=eiKD_M^cJ&cG)IdxPR z{U28OTqcL-c+H$Zs(bg~8F8jj0tVBTLL9m$G@qSBm)B4uJOSn`8RH9yHP)RtI^HBv z6G;iVi5!VZC$^W^8fybW)TH_M-{lLPOjz>=lcSFc+WvW*uXgUe@L%#JPyZx*;=>a0 zr|ACYtDgU#f7LTgrBVqwjm;H3vd4zr@8M!WyY>I%H$Y|DB{q?W6A6dMntmqGeeo;# zQP8~@hDfS}{rTLsvV9PAFZChEo`=2sT(vx>t^42UyQH4osp)4q+&+-`0&b%eO{1C?ISg4NcWK%cC_(_Q2#G{)RZ;mt+n{GrqZ;wGl0we z0^^fzf9dy4wTPQ-&b_gyEm2a}nr4^B&U;ueCu#bHeFn8YCgg`cW=aiz(T7l}sDT)M zAaRY)^=Z^`%6o!auU^2%QbkFfzQ|uO-h1fmns!oelOvJ(msS6QFRH5PdlFpX3E>CA zo`}6>w0{kI>aISH0p#0%(u`!53JyeP-Lf&$mi{mQ?y9jz?4gX<^soE+D!iwSFddd5 z`6w%xMX5y_Z6a_nx$bLqyR%E}WHccD&$xplX1kd$VS2=0nS3S7u&JBI_mZDwouJ|*rvEMP- zeos&G8;}hT2HRn%U%O(EW}YzZki|)CNpP-&4PT9w`_h{Ve_2)f+H2scr8evtCwWU4 z>&R7S@c~))MP)9Ueo(fit-O2mL2u=6<*T`kUzm-b`g(z%mgQSm8}-Qg-T6Zr75qS+YE^zwJqB%^h4nD_!b;0 z(UFd9%Xh~2`sZN(Ysb~DZkD-$R8r!NN08u(S1r(G7Abj-!UW?bTA;pFpfwoio^ckI_!3nXfo+IsmPZsM@W$^wmw>gwaU;SD5SBN z`5!oQqtKT+57frL2`aCFV)J*FbCH8u+rk;EB!&mu(UchO#r-(i#;y71-mMfCh4Z;q zE{MfX8>o_T(IoSNX@j;sO?%MT>Z&}is38(_nYjlkY0S9w#^qA85_(cE3?)MS9ZkF5 hB%5tpkPfLey(hRsfqL^HkDEN?!oT$Ekm1VP`31dfixU6< diff --git a/locales/uk/LC_MESSAGES/messages.mo b/locales/uk/LC_MESSAGES/messages.mo deleted file mode 100644 index f930fae16986974a6a2e6c758ce6a6e9a3a60639..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 63748 zcmeFa37A}EnfHBE6h%QmMO@HBkS(ODyR#>TK*$1-B*b(Af=jx(ySlqbbyZtSIvrpP zAd8Bi7~yqc5fry~lqHZrNKhPS9B1q1opDCz9mjEI9A_MLKF8779N*vnzMpgIRChJY zT;KOy*LPiCUpe`o^;z!c-k;~x`R?&Yd^Fqj z3;bQM7yLKy4dBMpqUa8=489CJ>hvgjDfnto<(vY(3OpCo{TG9;2Aklq;0M7Y!8-%q z7w}7<%6TLlKN;|w;0rka6nGT)t$=?O@E-&IGT`&i@cWJqcw)d)0_FoQ3%CY6l5#H! zcnSDoj<*LK0agFI12zLrfNIZG0dEZW5%3k9zY`Qa9t0s(^he-g@E73mVD8K)g5=S; z;91~B;Bnv;pss%qJPEuT{4jVJT*z2$p6m5q$3y?b@rS^ZxqfvniYPj|H{kDs8p?kG zb^W-!A1?rxaePt0_kq9W_-o)Rg$%mJ>CeE8;NOFP11{-~qB-E}dz?P!fa>Q3py=?9 zfWrZ60j~m!T)z=~G58Zu35HGZD~$HCtOMfXz|dU@x8y1pJf5qvAy2VM@UJ--*u|1tO)j(-fk1Uzz)*LNH! zex3&&2c8F>0B!}6b3z^{Ps=lV%2yg#2i8+vp6AXw)5Z>@BC^qdn#qZ}V`uD7=azK!Fn zK+)-2p!oeCK+)x8tNi>4p!zizjKO8#o50J!S3NI^-UHsr@kh^d{#&@(aTTa?HU)fJ z!2W>cfI9>30sn*h-w$dWuV3SIx)m%_&)uNteDpf!rxQW(=UhQ*TAe{d?_$H4306Yc!S-=zC5=D=3yd2c|e*s?yzUD&b zk42!4F9F3Dbx`$R1HJ_O7>LM4_kugY?|_)V=&c)~=pJw!RJ&ih(fd6IRC$X)(dn%q ztQ_qCQDM>Nz`5X`gVIkg+7v~ngQtL^+l8Q>e-|kE-VKV5d%!n>?*oqkKOgWwz~2F- zm%ara4gN5k{{{Gcj$e3@)BA_uQ5^pqRJ(r-o(3Md+3U}PCvv2**KfzBfcJn;ft5b!%>Anh_*NW`^n1PA1{~iB{)+QOP<%ZA@w&lrQ0@O5D84xe zYP@~`s-B~1)C<5f!KGjhTm}w-Cxdr`;-4o$mGgTbB#*uet^*eixm;WUiofmx=YUUu zOTh1g=YX#r_VO+RdpN!lTnBy$gq5Rz0b_9W2)qjpf~&x~)`#%Ee`OkyLfCmG96V(0R2GzbFgDUS= zpxX7Ks$V}IT*&chpvrqYxEg#nsP;Y#s{SX#@gIOM$ESfuaK0NZbb?{{H`E~c(-xP2&sPVZHR6QR8)&Gx!s{bzVMd0Vc@s~lh z^8k1Z_%%@VJOzs0-v?FBPeDEZZ=mjfe#6T>8dUp_2Q|(ofNJkNP;^)cs{S>go?9Qz zZv~I$_%iTs;o}i-6UUo&x?gn%DEhw?Mn2R_29W2e-zAt-vWEVBPN_K zZv!%HOl%K`U;>dzCP+WWPDe;DxF0ski8PXqpYz!&cJ=Z+2d zx`3wz>;cuD6#>_PqU(l$+d$R-u7Ldkhd{OG@_@~Nd%#z4{sZ8t;9a2j@ay1m@E^hB z!PBpBx-AFK;&?r%acY9nJ2!yaz|Vkx0{#d1W9UA0rPuq!Zx9C|Fy92lcaL7}ao(Q? zJmMPHTRBkI*N5XB;4+SH2>4a-`sYzTsPWIq-|%Q{czA{u|f1o<8vgZ}$dJ z_TlZI`g=vdTLRt-iaz_n!{C#k`1k4?{r;N+-V^WK}~WR4&IFfhF zQ02dNuj`Rh0xk%+8Wi1oL5`25?V=&KyR8axL4 zHYj=dA*gozBX|P%Yw!(RIN^40&!Uezf3F0`xV{(s#`DoppK!kV!#gOCTBr4}%)NJ>cuXFM!?P?|_TJe+7R^ zxm};3jU2!6v)=zVe$KHc;Oc&j8h)l>xT|90Fg$ z`Q6~l!1sa|(~b{=M{xYZ`~Ccn!Pjy8@1V|~@PL>5x_~|4`J6u=R6Vx@ycg`HzxzRr z^GhFcKAHncE^?sCy%1ak4uh`&?*PSj`$6^pFnBKb+o0Ncw^z~i#dJ*l-&FRJO+HpA(xXAL5+JQ;Clmp9L#b4e(*%_y8(X*Dz9)X%J($RU-g8K z%csF(IsP)Z9{dXUTJWf^`17ZNs(&ST9Qao7<=_CQ{?x&bfIk3-D1Y}?u@4;o)sxVf z<14;KZieG8{uW~epS|nr-v3Yk4(GZ4;%^|M;KAP|cICdWev=#lc;WB4e0~!A4#$sz z=WyTN-$$2&fBXl|XTR}BJ|0g^LSydx;FQbJNl$sZ=Y#*i{cFKfxZeH8*fx&0g5tx? z-*SCg2E{)&gRci~10^R9f#Qclpy)pZejofENY|pT{VDsDcf+4?jpGp-JCEb#e~!-Q zc=&&#cRBtH_#5EQ{=)OI@BT|@!EygzdA(nyP>sXyg7UY%1J2|4D}O_d8T>K01l;(y z9uHp!_H+EF;Bs*J4_tnl;JF-M3BDOT1ilIUH}Iw48~)DwHy4ED(fQyy@VFm3eclGX zk>e}DIp8Nj)%yf^4){y(WN^vfyZyWr)bk$zH-b-rF&O`Y>)}=4DxC*U17G+e{ax@V@J|AMFP#5TIR0fge*RCLe#d}%?v0@24a3Qz}Tm)VVUI;!4s=Y7#xz~R@sN<8s7lLyGc7rN+G57-T z98mYI4%asayciUH-vNrggWuC7f1!%g5>;Fkh^2NeIj=wF>4b3oNU4^;g<;ETZJ z;dm9OcD@DFIBx@0&mbszH$c(#YEaLA0Mz|^L6v(KsP=yvl>B}U6yJOU6dk?;>b~!R zdhTz-`F{eB=J*%j^FY*;{e4OY{M`qh&h}6^o)132`CZ^!*d(+2KM{hfpT|9$@dY`E`M_VZz17eB>z58Kjk?hyNn*gnse{QZw`?V|yuSMN+N zf@|1h`)>zN0GF}d%>Mty*6HtcT>ml``q{d|4dS)z-#YI39Gm_o*e+-L3ESSS+i+ffM)LQXu=BsbQ#gMHSPAF85b#mXKgj+@@E^g4*&bor z&n92;GPax8pZ<3@CvxHBH^95NZw;INP6{X)(%)LPAK9M&hq~zaSLeABS59MVvR%aS zC2U`1e+<;0{2IxW{*DgkR)doF=Yb8of^QvAZ~~j;TC#Z}_iSa8e(7Pmh;1&%zYpr~ z0`~QHA^2OqYjX?oAKu8eC7hcASF*i5+`j;njvQjUm;HYOf0HfwJDzh}Ik+P^0UqGo z`@j#d?O{8c;}5Xu?@a;y$m6YH4tBH27s&n{$HD*P{y)f^{Ap(YD`Ees%(*Mszl!ZQ z*zOK>{U!SkvAsH}8{E#Z{yxM0k>UJX!JT3M5B+j<8TdiAH?zHsYuAPAXL4L%|7!3F zHvL`9HpuoE+jVUBu~oR|v*1K{j@{_XVSi5M+{ZcpXS$gAJA&(TIj*sNBAkB(cpKYd zwj;wif&AV@Y;R@%_t;*_c7SaMTbXT?YqzqU&A$HL#dd`4x$b|QYdvi5=G^&g7qG2o zJC7~Tb}8Ec+xxiZMz;5}ufGj!huLDbKVdtUZ5P{_+>>MbAlo6fZ*p!0nEXA;&YQ#W zCidmeJ|BEhICn?D!GL=1=WNT_e!+GZoBo!t?dF~ru${&JRp5`ogWy}h7|j0N!oh-Y z;;3+~7H~f}&bEx}f5i4Hw!dQ2oaHF^$86cZ^_;(yO@9q=TiEwA8&esCq*BWxwMv)EqC`2yPr+a``b1ilhX{%&CB?QFjr zPW%IS1J_>_js-=IF9G*}pJ4l)aBZ0Vli9u$j-Lci4EtL+ufOvGYJUaWN7>Hj+|R&& zW&3cr{+r;3IetBOIosc`e;l|O{5sojv+ZTm-zPc$ezsq-e>K=-E3*H3T?~K!ne2c^ zhyBIecN1Ik_Y(I1i-U{7KL>AQ`y$(_aL>osPyW8Zxle|JRp9Y#|C4Qi^T&e!&h|Do z{VnI*{cP8;e=Xa5woh}smM!~tF2~z5=e`#%-psi<>^}y+0DMn4KM(v6=l%lxbvP$@ z4d-6V)*a5B0=|juRJM0;{vh};ct7|8RV2*>Z?+FrIR*rL2%U9*>tABk}T~Qn|Ri zuQ)uMD^-T7eer0qQ5Y;V3i)X6+||{}aIMg2@?5D}sn3fis?F1P7Ly_d<3eRH9xT-x zwNihxQRFz@Jkc1bR^qW*_449C?=QYO`LRm^+utYfANjX1%WJc(zb0#zR$3P_~!4vou($495f2(Xm=_q*$q!XpdT6 z8?{Eph5l-@K||_e#evdLX&`P?$4UeFc>R#Io&qm#)*Er7HlcDFRT|KU>y75nP&`A1u~#m146|E0k%-M7d~}FR7Jyi1sx` zigAs4i#0o6EYv5qmn!u}pgA6&F}$-Aj#1q&B0UN%3Pzi`2Vh4XtBMe`T; zEbH!Gx+q$ZU(B|IZE3W4!P1`ji{{U#)k~Hv<%Wfem-a-<7B5)Ty?Dv|?gdfc-;Jv_ ztzWmccWb^>>Fab(3^NM1){~1{)~;H!aczEdurEHNUTieS8r5pK9xqs&UzqPc>&$7l z)#?rI3%pI+&Wfuw7$tqIJHI$Tf60u;8oL^4YrMkraBL!oNWM`WEw?vf;evd3wh>lQ zeqd;rr^kw8%lj5CSlSo&Hpj-QwMMiYSz6w=u~}}Eay#KiL?>SF{88rtySk`f;UyoP7H_K<9U)dMK@&gDoA~#w^QtGAAvGT+`lSLDqLR?1V|1D)kdMejIbf~$Wo&;Dy33O+ADco-YC{a zm-nTraRq9~m71uz*)=Al8LCxBlbbhBY+fI)2s{yPf$*pbamwcPXL5hDuF`8Q>L+T6 zae|^~&q9;&M{^Az&J)=t(R-sNVPdUf&wa)%amCgF4CUS1q3<$QYR<{Dj zs^het0b*!M5W7|!E5iq9{bFTjsaCC+3^Dfg!YD#t+%-^c4i@7p#tMy|s|@B}73cGL zSi!f^6^%<4t2s-FQRcV+r?cBk+iDx%3x{8oSR0xg97WS4PB2THCm6)7{IZq zmT@!A-?sitNv&9`4|l^frn@jJMjDN=`tq)>F>hpE=AZkxtDY}aSN3h+ZjFFgrlU%HPv}$m$B*%l6){1o#fO__%*}lvPsrypn^g5k~M2RyaR;5GE zqJ_#tyaP2|iOa^u^c#Cb<+xvTnmUK1mee~sk0(@*N03nYZRMg|MO;brR|TVh7SwGQ zY~8pa#&;V-vJ<-W<-4SU2D?TY7)eYMMr@!_txe?POT+V3)T9%!kCKYJ^5Iq)8?|_6 zsW@)e&6!ilXjKip zVQd$zlKEn=$Es+ixMc1u_Kkg-D-OY2t7e>U<6r5mV4cdP{#v1iA&Fa@Tg7xx9?on! z6ob{}(W>TPNle4eu>53iTe?r<(tTRj#A?(6JZ16hgd)H5!Hka5?!!U@Gb(6_CCd~{x6ccD;=&J&kf$tlN_t7g-q^CsYW zY>7goP`A2uB|gHo^RM)nigJs)6hJuh4OPoXl^PUp?p+6S_N}g>`B5Z9WSFFeG(fZ( zt9wyz*Om*`ZeUSmp+ZatR;w0Qj27VrcYBbpW~KD*W>L|JyFT=#mZ&)wC1Rh`8;Gd8 z3-O>RllYKBx}r10(pH(dufsIa&eC1qUlb zrQs&lTcUth&S1;b=|UYVTgy5yFh%0QWZjN>6S<&4?%NENOAWk6KVYl|MmUmp6&%!R zk#LUyjtUxbRcyy&RuykzWn!)iJGp~~A;%OjS{#6~r2#!MHc=}LvkGoC8qP-2<*Z2D zI9@4N3j`OdVLgRni@`Nq*2;%=mPuvqq8qhCS$lqofd z>*`1S<_5P&9jz($mkO1xZD^K8lcRy6f>RgY?9o!L1;=tCzK8;93UPI^T(yWes0=tD z(N?;uh`>}@gyWPNQm(YZ_3Xasz)aw7b_rF0A{39%l}yNPwhX340?N{0(_?o_R7?x% zhpX5!xR7XjFdxG8V1$*B2q}b|h0~0WTi19+>yn~+3s*=*SZq|!?NnN#6(_BPVb-+S z<;KLANM(|Op;zJ{)j5G|vLOgt16LmFDW`+Jju*?Er{}Kvk zR>3b=TNx;f)s@~s@8Dj`eIXc$*19{he0j20Pj~E`yN%8h^?0yZQ&oYU(YjS{jn)pSH7vvYVA1<=PFz&c4L#CC2++h=a zVB=Lry7Nrc*5bat(9-S64LBC#)n<862BuuXEYvZCs<%~g!$yqj=JUu_xJ5vVdZw#Y z8y6I%HsYN<(%7f3I^BnE=X^UnkHb2S6tU^k)d`)|g2bfHS=CQKN>XV~yt5w9K}`+R zaHHlV)mo_FxvRu^9DuV%3xha}T^R8NUENE%OoLA2^RB!qV$`Ye{8A%2zf69Pp^MJ9 z{0xd;`Cs(S=gJ_f3LVbskTfUvyP?1w%D(1NCzHrgytgZx?=vgif4i^(GAbB97 zD-nX4ZVo1fa9OUJ87S0ip@swJ^@#C3Nto8ln2;x=&MFZfV=#bOE3hjGDztpzj1H15 zsT7Mif7Xr(8}34xfeI=E2_nIQ?;4{SYt;gl%}i4}A!M-|P++=BGUGBs8`;@qDq{bWN zYSTPwsY_HlDcg(>GESD0yJ#P7BVoB!DBTpVsnQmtgm8sM1hFJJZ44(h=HerN4LKQ{ zc{lgSUsEC$7IpjK$)Z|3T-urPEf)TqcwG_Z9IBD}#UH@qahFZcCZ2#hNaNKSeRC~K zs${^tTpk%BXFU-s#v6qjYfYSc_p8Lta=QEND(=T%Oq4WQvJ|%}BRFuf;F&-GY+3=G zQXH!y9#kH*8i{)n_Ce{SUca7|A|a6vn}{joI7jP83&SNM??3_CY|X^knx3EcIRMEg zG&k=~@~CE^>gsfbA)}7^4w6C=jZ2}s4MkF>%^|=cqY0}_bhu7CBvmLzx?ZOliUg4o zXu%~Kg>MQm)jlfIDQ^XgM^r$PBp+Wus|KrfjR_=o{lKh-cb~q@f3CF31qTGzpcMVb(LGt}2Wwo(5eQD-bb;eP%jHDoPj9%OZ{N z@`nh}834^dREHYl;@UweY@%x_RhQ~SCmNy=58gtr5ohPy0UT1|EOZNPuQ>q|N+*w~ zE)A1Qu8%??#;a2HQ<}kwQf+2juy5>|lcvYgfW?!7QcEbbGQI+NSP#$p`o?VfX+fMD zHT@MVef)MkpD5LL_Mucm!5)JQx!cor&T=bhQo!!3Cr=e?$)2=GqO04^mBx}ol0uoR zaVCk``G!kIP(|b^4OjL>B(WJ_vCKdSj}V&~c^PqFN5=+H9)tO^*<^`#Iy)BZ1;YuW zq!%XQdb2;*_RtxnJOkWz3NvEkl0A7QY2d9&Q}C}!;pGX8y>jVr&(7e)qTUo_Dc<*d zs8eXTP(uDZ+1k&n;1H^fD$>#?$S@%X_`D3CJ7i{|6R*sLEAhux;S(r|uESWwn22Ly z8>z!RGIQdBTej+SbRpuMndwqp(LaU<(^OD4pLqb>^5B*E{q>1@13h0IK-5iD&=De4q%@N; zl>!ezuF@{XyT+_)43tvMCa{Pc+8C`b_mPK`{-_b&iY?5-v~?{XZCJm0?WW$fd8X8& z4f3wH6qVU44%$(guxzJwUO3G9~fw6oD5b~qoVj?GK6Mkmfz z%HeVrjH}#R7=$?3dd6>DK7jFi%Fas18Oy=HL(MYzN=&Rvg3Fqz4YT={*pz^J?$%{2 zDb#Pa0ar*U)lJ_i6z9K~2^GjTo5#wPv|S7qLlktZO^mrB4S5sIF?lAF!F+qqJGVz0 zEXq_=!mekCaWzh6g8$=tq7BM7*SVs^dQhfxX>;&pqYcW4B~qyQ6r_@zX{{b*rf;K- zsDTC>O18Bdl8YM)%7>bOq`OPGEu3A(Zji39ql zBp(?vb69stxJ_Xum->Qs!5Je~x}e#Q2{KQOl(c8%ll25R0L4LqcR9r7d`j0P^QL{4 zw8jU-@8L1yrM|Hy>PIYxROoCrYe^$2t{bbtdx05>B=wD@%=*uxrTFH)R=`gCAbJYK z9fTE_kTemw-L7o6D+)6<5qw0OisNC>H zUPPKcO+aN1c!r6Ail;s0ehdyGJ#Gp@-qw@+Xcu!X=c2sk&Wi;#7KETGY_~o)A73O_ zW4u(ytVp*^TS~!DRfrwx@my}3P!V9M#*P(Y2lcsWhTWF1+IqAnRG~xf<_3(qDn_UVl%2W?j<$etVf$mhB zp$w%_45w{DO@fxnjW#!Ha39Z1Y+eOxO{81$i=XkHMfqngXE9@i|7KG;B!!hqMC+Q5SuYJ&&=F`X6G0pD z&`8#SAa{&I-0LoJ+;>5V-0lb|nwlg~2?{+K?hks*T{<1q$dqHL5GLJ~sJXV%-89O} z4cfWS{2QD zbj9hym1v9g6t;}EX!gg0()N{0W64ZVuD?XiWP-_7gwIx2A@TN@WtjZgtnSYy+aaD8 zBn_6#Bq0{vmvl_8hT^0P#gS}Lb|Mlnp`9(BaT6l`UUEst3v_aoCu9&)r& za)~&bRlz572@ILQcAY;X+t_Xqx(4v!a>-&(+5cWGJ#>MLdYk=;^670Vr3LkUxtSWD zrb3y#7_?jg{z*eYbUji|2Hi}0W1a%A9rcqr#ezz)?()98#I`oTLMoX$U0A=Vck8MR z8`f@Vo!Yo|>#8-Ywi3W4H*HzF`l2msTE~5Tnu_TnMipYYly9-DlI#Wk{18G{E)Hve z3uPRt#A*OXE6gW|+*FGd3Y@ILC|h1`|CHyD&?L zknSuMVp$I;!W3Ccv!ci{Q@dp%ey%YxVLgi)Of?8XUAnsqmrJXJNr9VN608Po$84}D z*6Qt27zsz25)biFfk`m})KNsr6tWaM(Go&LYGfi_M|_x<|3>qY)EHA>EHSXP5}s2` zlaAhc7UeMYO@mk|$T}SxdCZPxsg;GKd`3b`52vMs+AC2Moz_F3)usZh7+Y&1%aY!v zWnYqfWgeKdz|T}Oj4r3AI>VHbCnVEJDXCFqQU|NMvFRF6szXH%Dw*R8josJ9`pV3N z~*)D`(SD8We1#WeK#JMtL1)hSnn{amG8yptV937+1;?nbOG;@rIU!5^oVp!Euxq@JOw5fJCXBu##WL$lo2Wt0VN@NelLxp_szB{XxJQ|u`=AjW$yL-KL$eUI8~_TU#0xvBds&ie3v9av&CMnW zMCfTs&g_F&MJ8|BBul!IDIcF##0T(cBoh`(RnXu}YQk3Il^WbTA@_j%tU6@l({ew; zM19IUis7IQ*#hGex-OZ-2vqU+#nISp#zN#I4B2AK>kim@&GrZCc_#qYQQzHrJ1+`VnT0} zFWN$#WG>HEMw&5^MnyPUwFMhz-nfynMOc;zjnH?q3TlKA+J&E+Xb|(mlw>;G90gb; ztYvcbh%U#EV-YyS4C;rRfk#gHMA6mqN{Qlz4cJ02$cIXZwk9+8tv!?d#E_~u*_(s` zf;SW5B@GP%k25!IrGZxdggJU?5?=19Fs5)f)0CvFa{Uu{zRb9popO^W*V_{Gu3R*A z&RU8}k++VRO06k6LE5Fb<-?jl=HtG^t4`AE(;VtPR^V;pQPa<@9OpIyP~2148piPK zyF|WgF64njIwj=Ax6&jDs}jt}t7LA&_}7Fu1i+HNS_q8ka2OFN=hI-!y=+qAU$HQ^ zYWmwNOlX{h@vs8Cu9bw)&NvGa$$1fTshzHbCg@6zY*d=!?0d7ZP*RM^WattPC2n34 zn|Epa28%-lmQFw{7ZZ7B?ET zBtbhmZIk>Gyw{q+$}GxRt~Sy*mFNyQMI_OfUxSA`&Tk=q=py%l5?@pA6d5C>{!Ora z$r{?WjMh5B@TYrU%+#=w`jQ>f9$u%lHkePJ*c0!{Y==M~5Ha(%i;V^Jo~18Ix>yXuQUe>h*}Bx$Dp9gE|A;th%3Z-C3+bu@a^XTM($~l*YfLa)%t3VQ zA&WWahx`^LE=8FT8Turv)Vn>LYu5CB1>>VrdMAUoM=CosE0E}dwwBIWovc6%t(?(9 zOL_Pj7;m2nPa_}cs320?WsKywXFClK6nBjjNEk?mXbMh4 zrus`2O+AD#pk-_`5tZB%GP&IElWCYj7806@36|f~cPbrz)z%5<{k5Six3{x76lQHg zbV;p1E_4jklBIN^j9GA5B3p{3b6~d%59acm3AeRJiWC&zb$=hDu5(*w#2q{^)QnI&Hj9JX|b*?KErusOIF`J zgAP5@ADpg7#H>i5%=`39TC2DlpL>=kS%dC$PVO)fqjmEvcW3i4dZRcJQDn1{up_ZA zs?$<#3Urid;hxN^PeJjCKCNgY1RBH?eXDG_Pp`fB?)yR6r|-6nkB{fIzLFH7?#lCU zmmiN=GLX02C}wO-iy4b?`WR*&xo2UD@`rZMdBvjTpwnB%CddHt%UtxD83Lb@_78`$B^vGx%^bDzCoW>v4PkXK>dU?W~#sPKMBdkJu{U$tk0 zzug6~xzp>_4>F7ucC;ST`>UL2HGW;WxNDbRC(SjaqiJsgb`>jKJOvfK%=4>NB`ly^ zytZP?K+}#7Xen+Ux#R|?w_fwnJzexH$-;Uu7x1GDJDRPQu^N!Y9m+c4h;YT9mjy!O zcHzNEfC-T-wU(1Vlgo_bg{7St;_Tqax_HV6YZQ%=o2sFgdhM}NefmzeUj9pz52huo z4Z~dSYFT9#u=I%?FQT8lBPHHtO^MOZEMOily}}aqp@wy5dM~^KPLIv@4pHlIzm^-b z)2;DJUMo$jNn@elVUg;#j1axvZf*=}nu!Bb_~EU<#JS`Nr7fk%-9v6oLvHqbd3)9o zeV_VsfiN(&zbQndxT$x2ucaF7t$wZ7ROphMJ4X^lg+VKVYJWN;CCVpJ8i0thN0O>(4XX*xNg}!}r23$mBvyZzr|7$abh zk34IQ3)-F?%5>1x-*ODcFmCT#Q6$IPblxR=QPh<&* z81#kiIJNCX^16>76HF6?2F+bPMzQpeMS0FL*)t2<@7ca<`-GkGd?D2++7677=$>FV z?7kMos#R{-9%&+mYFk%}!+?CVMx!571 zRaD76`JRO1Ep5fzMAEm@+B$P`G$AUAXM6&V| zqvc5R-VJMVq&ARgBVRf&60yj-QH{*=^Z%KFiTZcfq5aSBss zaHC1)CYe6{Jb`sdo=(5LJ)W0O$V#A#=3peU1s~2Q72M)TZc{G?AxhncNa@a0 zJK2)RF_uM&AK20$aSmNND@hZF1iN)lIp!{yRwnM0;_&dFHO3M}F zydG*hIrGf)J2;MWxk}YDAMCc$9dW0&wH2=n0|VD3&$UY)(u@XlDuOC=GS!XY-EE~k z-M!-@WxJPw$-Z-^bFOH#ClZ^O)+2XCqr~B~9gE;<+VvF$_G43#D_xA7bV0Ee)dxyD zU^O3Lw`d9teQ#{ScTBfM(m7FmXC-2xWS*BIMo5m6r_^tPD0@#*nO}6t80W~;X+#Qk zXOvk*>zZXZK?~80&70Pem94q;gNfs?Jl?jWhU(_Ub{2X~j1|s2Y72Z)YveZ8hf9OG z^P0o;+}7&y_^8bn<+S2XGYC1oEx$azbnU7wxs4a))~t#zxM=yt^=Dmn(WbRW>CJ)M zR{XF!Ayc)sJYKhL!-ja%s*P*;&7qB})^9j>)tWV1*7o+USn4qU{~Gg z&P_g{J1Fe2scSm?dg0{fCm){Nr(0s4Jj`}K72ZGjD1|?)zC6seho`Qy|F51rG4@^F!W^kEjl1pm4?ze&{{}EkMF^6cq{3Ds_~8yT;|y39!^9!j3N)=B&TO}J+2TE=5P6{<5dm@_x|k1t4Y?9gHty_rUR3Y#`YkL zFm;o6;Vyb~qmw0O91l?J{Tfe-zRm8)Dtn7 zq#78T#OVL~zx+6P7o5D$SW5cvF|pQ04G0810|@&p5jJ0?zYKCgR(I86QLwl z2NU*=S9JdENZvgSrGA=HALW4q?H=N+zaWXwA4VTYPOhE0S&WUcL|9N|h(OS=E?y|? zsq3XVDShh3j0#0aZbN$M%bv-Hc-Ce38csea&3h0Xlm@+RzdmUiN6KHyLY+M@bzLm2 z^j_};zo%zEiJ29xnZJh!1s|45o7xli$(T6lpyzFBDWbfBfSK?d!#_w2Mx_tXNOXy7 z#+Lp#th(*DDyMFdHo75{bwC;^bfLvg{Ai`@+2kQFkFLs4J#H2*s1SMr6+%Ii2SRrr zgus+<0?>JwCm&CKVv#aai)-|p?bj~3xIcMFi!`3;*Dhtbu}E!dGH6_C*T_TA>lu*u zQZfuIHZ_vcPd$hIo_q*}&8VXR#ltdTsBx$!rbW+lW5@2@>?U7K{fO?hn^3{YXrnh1 zcGfO;pANlLsmjBiJ)zE;jS?67m@PF^CL0QuYV>Fqx?8*fR|d;RAxPr0VX5nA7Q?SD z*a%azszMOb(WV9T*m^rfmo)J5Ms9Y?(ef0;fx49kY14j@Ovd%AVgGNSLS( zqiS2A{4{D%|$`|GG^>+p-C$uhvUUncGJi=&gb8%w70Xa)f?YaH<% zVUA?JXKJs)i-&{gWHqdY+wE1Dc?g4yX|%z`ZrB(~iZLQ`UCp(ZLfRK^@LwFAycaX1 z!BwCXOd(9;-hCR7hN-1#6NH$j?J?~WD@uJy^Co`oW0E9O0uQ3=xGn`GgDEZw=iOdo zgw?di5msrML$DmavwOBv*CF6`U7Fq07iI94`sDSxk$&!JHCxm$^~@;+EvCx6vy^w6 zyaCQajH$iQm!C1sN0YevJS9`0x{(agP>1qxZlhTUOsBiJHlzMfvnQEbk-=HMlL!<-|tcr70!CmSSPAIl-zw-^n%0+v>38Pfhc-LpIVPBG(ty6 zKkSF-X2BB23_D`KyNbaxa>7wDYnIx6b(L|vbw<&$Vf(E0idrZ>xK})FkzDdKtlT7D z4FbD{dPs+G7WG{Z_kc#I&I9t(1dYKf(ju1>34z9yHEc9!-AM_H5vzFb1$wizGA8E$wh$ z=bx*cyjLs-QPUibMo%_WsfJddWb!^OIWTn-q7fPwdM>|6N{@cf35pVz(%)3MpaO!C zFs*_ncG*@cVjm9>FIaZL6q{0F+|ijkQ7%R^(^FIkW4lT*QPY@8Nj%C;(sI*Emew4}Kw3G^Uiw~f& z2>*z9eCj5Inhu!DC%IDehNc1)dRbK43xX5fOgK|qE1g7?9p{fR5 zjdI&|IHC+W$&b<=v~Cj4N>QM9b+48LAc=3XA7q&}&)3<&Lk z$#lD4rc5=mkNU+7QVVEyjgM5k7-_|{-vKt;&QAol{}?b$CUT%OjH0rPrrT7f#uuWZ zlpw$2Pt-qEW58Nn)>-ipX*=z@`lg-ojg4;E=6s)3_2~LI$tB&dLy<1?h&7i|6u^>|Xuml5cr}tL zM9FCk3*n6~>`H2L-HVcDNisxkD$!v?oMPSUXk1{JX!1ic!x}*9lw%pBRn7{Ma~D)n zuKa%T;mYruu(-NY8S18Iw*zB_Spc4T(8tCC-lPY59;&Gw9uHcMo=$5N+wK&nNUY3R z^e0rSrGzrK%Y@Jjq%im{@Vh4nqsdQFnIsS`pkb0>!vfgDHt1xRHT=@fnX7wka5;xq zS)xZgDJpm1z7V=wr&K(ollD__q70R_|D>}VY^bP4wS0jY=kNvYGCngK1}lo+lu`Dc zasp=L5U-VCgHhOjw8gd>NexT88RsFpRS(!ajgQcs2}SRq5DB`|JSZI*G#izqa@R#O zPRoK&aA@?j`3~b@rE0hV5?Q;D3n>G+vaaPUT!P|q#HP)Bn0nGAg$o;{n7W;Ogu%Pn zHKLdVJ4>1JKBN?lDELWcj~Et(8X=2mBjgGkiIC%e1CIxD(pHY2PJW>w*uY?`Oz_Pn zP!y%WN~Y5^9GV?4hoQsd&~yL&>dAX35Wb&LBVDrKF~T>bi((5UFy+G8ObQBERz6IM zK{rKc!6ed3KIXM&uapWBLJjg#)M~f%?y^EEsGo7<nrI#Fhk^>XAZevGz6g)*I?oepTQpR=KvHm_!cS?wCBFdv5hdjG+^)Ku^X0 z^3fDiDYXae3p$L(`e4vJHAw2i^h3nx-jBMWqJyFc1w0yJl(yrg)2?^=(QiV0g-*_I zv3~cv{fvJ4d-|D0VqTFeLk1_Yd#E-HQ)VSJ7#<1|O)`Fad20gEJrMJw;G*%=jTX1s zin{FLKaEqc=B}5`eKYoxb8L(PQ9CpPtufs@H^-2(T%nmE_EFW=g~PM8RCgM8KPvl+ zx=`%JZ;PAIw&`*hi(ebJX7MYOv)rKHA2+6hdBfbxteu>-f8wOi)2s(jEQt(=0i6Fk z1c_vAKLq6wYDP<9AysSB|1&I-#KVV<0+sIlxb;8P&@#kN9;6c?Y;lE^uH1R{KYKp; zX?S9fsrPH>(D^J`lSIPc(k@Iq(KBqLJAsG=gOKr)I-VBIXEkQBks=Tb)v{&gq-5+5 z^_w{nS(wz}|KOuQ6=SJHf40XyDeX~%QuYs9bSZ(fZb(tfYcQVKZ^epp9+H^rG*9t> z_mI4n>ogw7+D}!e!N#-K5YZV|x(_lC=HVKBNQB7_+d!kmEU_{9XiLeuF*OUI`SV9K zifSdS#)wLz^UQ7VxSd7kad_?2)hZy!8>b$bK?}Lo^42iOlq!i9^U&6GKGgcIb_Gu( z^*pf;Axcr*lrFDjmW33eY^qC~7L$h|(#MU;B%`Fw89$oa(Y zzLQi~*Inl2(LCO^<}R%enoC)d_>`DgqJ=?_BeF-Qmdj}{-DTcXvM5LmNwk%Z@`GX$ zS2S)4q)E*_h<}rNJad6CiY{o*n~*JMu|ujz{)*`e3v6%~kS%w)#OrcXOhf81O|eTO znAy>Qc&(zDq(r63^Kf14E|JzbKqPx~dU0kK;Bk3TaBnDvU<5i^7RX(61y5>&T~B+A z{}yfvq>@^rwdcg4$4z2^X!2ee0vHZ2%y_9YQQ)`d|8aG+G6 zNGqGC+@87;Oq6Wzp8X=9NnrK0g=9yY`(%z67HEFvY>i^*(cvkTEDCZ_<4V2h#4y zglQ3kt@DB}P$6o|)yA$ikRGo)XI8=b3+Z%Zw$9Or2KXWlx+P?Cv~r&+F*HdVi zz09f%Q!v3%M5Ad13fhG3-A=pAvxJApI?@$d;Vo;AgyA@-i6z7c-c$n3N|fyZ<1BrP+xhZ&UQ#YCf)%9GnlM zr25ueTTRr+(S!i%TZRj#F|{euY(uy|*g&I%#$RUC)KZWwv7^~xxJ?c+i}1ujX$z?P z7J7My^@lZjGU^=sE%eK^fcXFl3 z+`4IUD0!#+S$r-d8!MScXtj=x2GgtDqs%mRK@?ToYT|D06$hB%r+K!m%O+w{jyFuB zMXNR!Rwsju9694@MI`N#r#JgW9!*!dWmYB4{y^(?$-Ekb3Qxb+flATf$f9bUQXq}^ zMNUfa95UXlc*GJ=8aM9IxRaAb_-08-h>aL!`5FI>6$Qwyac)MKjWJbTVjWD>EWxUi zrZFrM$<1skoOg!0#@L!+nb8-iOO@i9d}aaatG;J|`$V_Qr?5Cc;;Ld{R}>e#uKtDu zq*=4zd{eLnVV~2&ybL(d97TV~gwIwVW)-w`3tHbIF7n_}6+FZyZ9s`8d6@z1+;k+k zL+oeTSN%znoWW3=@G%1NDH%CC{0;#_#AJa z72`{1oLLq@Mx~+CdzQ>Nqa0!TJQ6s$hMTO9 zt;kr=OEkFI0)~UyB=M9d`+zB;EDQKy2ZoW6$LYIA8b+;Dg{sWsAY%*p267>t!@`m2 zSxQs-h_tH4JxNB(%XjPL;$>Y?$r4oc+0B>yX&9TLZFy=(=1jYv{D_-aL|I&#Y7GuV z4}6K*iRln?+SH+emEjdjSkBprBdr&_8!c4fQrqaT0-^0gFqQ^zGkHk-D&wkg)%r0X z@Q|p!gO0gsb(6|M6dTzjU4Vrdla4>B722QXo2dFZh zKK^1e%4KBQlslEmQW_7t^JetkYy2y94JV>GrHM7Vni;y^H2dwDmSl{Dcfxs|C#lln z#$*;oIxl$8#{4d6ozlV5*iRljQzM$CLtE_kET%Jz{X4lywCf24ipZ@`)@ucM_|dA# zy&{UyUfS6VN+$j79+5fGwDRz@@8qOYwI+lT;f&K4OpoOsGQvxBI6BuuW)mIiY+FpP z5%35?av&vQ(NM}cZC~24TtHZm2eEIM`Mn*v<~El5t-53hT8FbJ@D68D;-2ttSK>3y zp~PpL%YL!P=i^~jJOI(u8ztQ=W=5~1G;gKKB+$f)5@r{qeaSbsgR(T4!V@d52;;KGN=!^g2vG3 zpoY zA#yz3-aHtuX#3(&XebE=cTeCQNko#Iww#3Xx0F&_0>QYJ0lbD*xDqhcV}z6m()&B9 zse~`(rHLck=Tww5cWrbN5jNzpoFpeb##F>FRo^n|rZrt6I~Pd%QDG)jN@_zQeySk- zMoGu-9}$m9{Ye`guz5YBmaSBlwp6M>?t!jN-DWi-Oldxr9(7PY zXU+Jk6z;*$$WhVIamHLlhJp(0Jz2)V#f{~OiYsT;lXF#%rJA&d%g-m8CU1@DUXsW$ z${J0ep@Mlkk@d^fwdAczym6UwO=j%@59jy~pDkz#iv>h98Ljq|=>Za8!Hm!x(R1$9 z?NitBsWHOW{{$40twv8|-ezaqf)4Kv~nucGZ%YxadO zf1$yyhBqss){+4GViirD9+|a$#47!;Quun+bGYBWWc3{G=c`tl`M1U2MkaNfB@}In z)BDfxxEh0jHTNz4Q$!b{5v7i#<+LcL^;VA}BIh>wU4agK6pLy<1+!)*L|iGFB=>Qp zgKkwuo_I!8JEw#J*Z4{FC8H<{_$SQShCHg>>^^g5&p9KV%jyG z8MUN%eE10-F{b7CxfEG&Fg779^ z_L{uchl*CoZ3~**to1bEOu7+1_@#9Wk`1G?8${)C8LnCEA*xNI)45dAQyE?2ZH{L7 zP?#10KlNc7TU%`A%$JqRX~xwo?zH#w)1P|j_$jd<-_y!Ty)yOD3#IP%JcpP|#&G63 zSTw()$qpnicdzZm0+?i4d!O~^$S{=dS%jhNBtJymSQH>SUDhf5WJ zrU6mns>lsZ!)$sF8+)JyE4Uw-{0vO;+bw+5%(SZ+KGd;I{dz!4b(k@m3N%k@p9WKM zA=kuKJj*3?lWq3iSGdW-o5InKQT4&Ft^oOJkJ?Q+g#a&G4z*acnO&5?3=UZz3cxEs zv2cS~R{kejj=j9qG@==ih!nC6HA=1RHFC}6E4X5DeTy$ul}ZZXOXf8-FB8&RcYVk> z(Bgc5*W6pqvtc47u}R8|%L~+RF&thVPmg^PPr~)GY-($bDDxZEaun}}OkdJ#d-aHR zTjvw=4+r3)>BneI9{wMwl1|6~9+eiAlmQ5x6LN00-;dY4VXt;Ya+sLYSwLt0?#7IVEP#Fd89-nRpZ3CK*?x zZpr5}Blhf!L>QhK3`%vl3kMea~eW=L;bu6ji=IrBx zU5$qPP+!q4PZED$F})0!bOQ=Tr~EzpYap8(7v65UFG#IPzNq6``r(sP<(~XRQ}Us| z)`j##f2~u=hyGe;{6l}O*i~^jIgII_`%^A$k}*zlUC>#yR@xxsQd^y)x6*T3R)d?- z>RggAH7R3(*L{H;fnV>3KbXbje&BJ&Sn`-vHBHKcvbfp!Rvi`pVvO$)2S|rsOL&lE4O&?Y?nDZ81&Tr>@^2zi zYaP8bkY2IA0}5y%s)AM7Y`x8*{We$anuLrJ5iQ9y3*)YwhQjj^q7${~0F;EvKa#tb zaV%80yG`!jigr^WfMzCP%)Y(&(%OX>}|lIY}Wok zDp+5`t@G*fTd|6tc1|{CG_%Oy#|C4eG@lCVBHzY}3RHthZBzwiZ@UPHVE?OXBSjvtdE8YS0j0lX1y3 ztSW{>$Jo1UYL>K{w>vY7EU!QmzJ*~EgGzg}-)#MXZ1PdPWB52$wsm(_(Q1z%JX#A( zN#jh~X1r@*zE|+GMLlC`{CKext#hWM6C6nKwB}JnXy*qddT*4z2?C-;ZZMIl!l1^u z!+Zr_u&WRYR!=;6E0wyj=Ne*hIh2vUg0VzVew#wWf&L>EY|EC+Md>V5YGSLf#F{X0 zsV1aX^g4uKRA6uVyK1FcD4v8@kibOFdM}O&hZd*NB5PZs8l;jD6sM6IU{8rxq=?<{ z*qi$unyrM#?2PXVx*)ct*2Pqb%h{UvG1b`89MS>&#Od^JYIa&(BRacKJY)=QZFJ+@ zk}F2WWQ|Uvg1w%{B*?e$3^cZ%1xRPc+hYx_v_o@F@oIXaB^YIPB^*+tH^*~ua4f={ z1MA!>UYDtCPckIhT35wARIFx;lcaW##*nN@2G+d;TY1lLz}S+xkc{%ViI90xVQ{An zq;*r$=}99kjTD1O`=|4+K?|i*9sc7Y8BaBR6%G%LN2O@+!;Dt7F>xe$ot&3EM;dgqJ4zJUc})GqOlze{sS6<_wnAH4_YpfNtGP55U}#dJ$e(WA`S^9x#49tLB)qhTPBYAmEeRMLqLq=(gMu zy*DC@CjpXjkN`qj%NpU=&{C0F4Adc9q_+}Om`{^)@*3Oixukk8=cN7vPb(#8>w&|w z=CY-UL5)KyUe?NBHKfFSts~Nup?-0uArAv65a77JjAP&798tHG73vE-C-5oa`S zEbW0wfbSqbwN4upI7n9Kb_}d~6<$r^W;6V%c*ZP;E}?_&;+nI9+_Ln|Ve@cXY!cR3 z&iP6 z3bw8Bl;pUBZ#I?&v}c{N^Tk0ciBi^;8>J_qGHOg^Kbx6x(@zwzS7U5Lp&-CWP0Jbl zXN=WURi>AwUwkTuwj*rD;DIX=sa8hNeVj19?z5R$OSqm$47QQJmuE&PHmV}0f=@M# znMhT9ozX~kAp~AYwp-kT5ZN*VM(Q(85{i}aW^7FpXn^Hd5qV?l%u@&u+e&Bs#pn-w>~)-r}*#Zkk1Wl;ZHRB#hw4h_n|m_fYQ zA$pW+BnL3KzZ}}fcy(HN1=$3f36%4nXc?}gi>EA6ZB$e#QcjO&-n#XOUewXLeR)Wt z5|jw}54Cez#Oa!5zq_v<3)$KsVpTe_hhjV_ph2Rx^jA?xzs&Z*U)Zz5FT6#QW;(?T zjG=s=13qD#c~exfAzw@kp{mm#zk-Vzw3&sGNJ$3|Ll^zL=TFQXO`5-hn`V9bzPD$z+Lf`kiQTnGxJ1 zLS<{Lc>?*$d^MU0J99{q$ffn|Xekf>9gUB-4TuCVq*P5ubI~GAu}SakgHlZSp^qgIQ+w!xO=E~qRNe8} zjtZJqnXR-Yd!i{Zb3tP`&p12NDJmmgvPGFxE@4O8nkSb8JajubPuqgi|7FBdv+|;W zB+%@z+Rhof+t(0cE!69*B}5lzN5d_lL^_j4krB|#K6_|Rs`R);j)4unad}$2!j96>ZQ)8Ts8kNrviU-}PtT@A?%wzbjACXYBV^^Wsy<}koGFyIH#bYqPWRT7hC$#w zct~tY2kShQBAT&$$wms2`|w!`m3kqH%wed{xb+cN0w@L4fjHVamqb)D zYT`k)-7Jg^Erpx8r$ogmAx0Kwr1=FZrgkTi`}z>r$d6Irr-?8N@Q1~ePv`2-Fqh71 z(d50Z`x!!45T-*rzr7(XmCXJj8&3W-L1%4ZOgxmDO5!@tW|(W0MrX;_(v$Te^stuw z=mE(z)qag)^wy5Cn!9Uc(5TAeFhN7v-h2izyy~}Tha(ruDcvyo4LT%w1c2_xL5DUB~+g#1}>4R7`_O$Gb|jFZ|PY!<1Uy; z;S*+>kvmBCb^7<|De8coY<;q=ug~?AQn2m%tRux{e}Sl-HkLnD+sqk|DzluE)Ur4X z3-7_9=rf%ZVrP_{n_0=H$)DWwR&b(OVrJFsv)unT47le{C{xDIr=qn6>^Y1`$Y#h= zI-|CJoSjjZpCIuj*)M5mV+Ji1NrMq-A1S4vfjULn;gt>fG-2K$UHWHE-!v(rX3drd zWjaX7E%!W$TP#Ly>r98+?c+O(tl z92+M#l=^Fh+Qd0}J43n&|3iLcLMqGRDbJa7+q~7*bf&)lmbDqvik*vJY5h{O=wApk z+`c%|z(0vr;w_9jV7DZaf12f@PC-)(MnjPWUvQR%qI8{cvDJvPl)w3zRx!@<+@zd8 zTkk1)%Oc!LFCp5ej79gwgnnUIVxO1@4&u}GG^`KKk~L$Br2xbwB70&514BUsv8{uL7b?DcQ;G5qJO+}ojzW=vXAAIp@8WY zx6FrZ`N%H>n|@`eRxIx3Q^&JE+pL7Isb+3+J#Lkm)VRjn?_Ubb>uZ`ySj=$0vng%} z$5Swh^jVT%boX2Ien{LaF$*+zxnn4N7@jbxN6Ibtgt$m{lU7`?b?atnEghStw()A| ziI!>;v*;G|w|vaQWCAtbW>&Q9O1~l6w`!nK+F9&v@bRnI_kEJK_03{^g|=XK@spZ- z8&jXP^xGs0SPvNt&HiFK3+kIl-i}d~Ck;gRpx_P>aMA6{%Fq zrkRDa0F7g_wU`VqhI~dml?1(>{%*6cnFTqh3h0kou@OL(Zt7j%%kbSR>#VsHeI~^9 zlky`pUG6Wd(z)1ab+z9UvNsAMEygqbLs#1DjcT^&&GKuMtQWl@mWq%PRaX4=Bo*>B z{U&iw)7(ABO{cxj6j|F`W{b#lm)WA=^r~75LrjNCU0=hVy9PAOGqfH^-~rA$8p%jN zDp}&>vr%fP+&1~3dsMPW)cUDE2F~h-etutjtY}#lw-M>^y8jc(*Mx#4B51Y+)i$g$ zB-0$XlmqmQu|DUTRh0=o>73Qm(y}fTg>cPe%Je~Rr7$+2&%U?Bk1x{useGyGI_l!W zFkdy!+@cb9`pM>4t1y}$IM;*>4KrSm%IVeSJ}%_LpUM7lgC( zGk47I&L^iAWKJ*0bAlbXH{+I;$lsowYGiihGdbkMIhF-f(0Utd>W-zcBWZm{vNUCVru+m88qrM~`M87LL~f$EsvK;UE1?N{jD zV6i?>E7@g#bb_CJEe+WI^v}ve6#HR#)RWCLC^%y-HTi8doRSXTyv!wTGaMei(`p|q zgntyD5e#vOvKl3Um9?eR6$qgFu@gQhWhNQ>dltO_q@c=HV@p z#Gh51tMv?fW4k`@6;I0Py<1tX^v@6CzU3vrl%I$ zReVaYjC!GQZ3=~Z__$_Y-;UzMc(pd@TvjgOM%0~eN0IxozFya3oRS{$Gfpmm*)t2< z@7ca<`-Gj*j|p>Jr zP!SAZu2HR)>n-IM)Rdg$%L}`A_ZKRIUFmJ6F)`TizVWA$>sXR_Y@%FfRtC_z#6PY5 zdUI^7T9ZE!_2J6w>{tuqvZKg%;=6RmDf*B5c~M$ZhFKX1igm%6QKEVB6Qkv*&>So^ ztZR|lN`EVb#=uC_j}KXm`kSTlp#NWOHlqIBwP>JZC;btAgJZA|;c||ZBE6(rF7+EW z8>MnRf`7QduvsfYg-D;ii6BulVwH>xM`3|-y;vT~+3%eU{-4gSH8)`x2Ky)#llEsy za{^AW6NHkLbZt{5rHo!;ci9Q|*=eB#G;RBVWb$wvW4_pVCU>7tE9gBBEXvvbO;tWx zRYe?EIN6HZFwdf*at=|4EP~j}w@2XQBWA(z?RbGE7Q`ITuP)v1rzb@wl5THa9rqeMrI8r4Em}jSYA@6KzUuA4*NP zz<-wjKn3i`4$RB62yFOkH5pG0?qfMnbFBMhA=Dx;BX+}IF@BObjJ%m6VIwe{fML^y zT8tKqv-8py2Lto6hqRow(4k4{><6(W;gd~*XB#NvW!}9oZEF$5!05b&xwG@|WXp03 z`WZ^vV{)PBeK>CgQ#LDZ%4RuNS|#46+?K%iOsUo@c`^~?by_=nB-@I;ylAeq<}gbi zVH9@)JYs<+6+1zFIj*?XpVV=fSfQlCWEh_ z(7g9Rlmzd1d4tge*|Bi%FxCVm$r<1|ltgvsL!lO diff --git a/locales/uk/LC_MESSAGES/messages.po b/locales/uk/LC_MESSAGES/messages.po index d77f6bc14..5f9e45967 100644 --- a/locales/uk/LC_MESSAGES/messages.po +++ b/locales/uk/LC_MESSAGES/messages.po @@ -11,7 +11,7 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-09-01 20:29+0000\n" +"PO-Revision-Date: 2021-09-05 14:34+0000\n" "Last-Translator: Sviatoslav Sydorenko \n" "Language-Team: Ukrainian \n" @@ -89,7 +89,7 @@ msgstr "" #: ../source/contribute.rst:38 ../source/tutorials/index.rst:2 msgid "Tutorials" -msgstr "Туторіали" +msgstr "Навчальні інструкції" #: ../source/contribute.rst:40 msgid "" @@ -375,7 +375,7 @@ msgstr "Домовленості й механіка" #: ../source/contribute.rst:192 msgid "**Write to the reader**" -msgstr "**Пишіть читачеві**" +msgstr "**Звертайтеся до читачів**" #: ../source/contribute.rst:187 msgid "" @@ -383,7 +383,7 @@ msgid "" "use the imperative mood." msgstr "" "Коли ви даєте рекомендації або вказуєте необхідні кроки, звертайтеся до " -"читача як *ви* або використовуйте наказовий спосіб." +"читачів на *ви* або використовуйте наказовий спосіб." #: ../source/contribute.rst:0 msgid "Wrong: To install it, the user runs…" @@ -1501,7 +1501,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:43 msgid "Public dataset" -msgstr "" +msgstr "Публічний набір даних" #: ../source/guides/analyzing-pypi-package-downloads.rst:45 msgid "" @@ -1512,7 +1512,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:50 msgid "Getting set up" -msgstr "" +msgstr "Налаштування" #: ../source/guides/analyzing-pypi-package-downloads.rst:52 msgid "" @@ -1526,7 +1526,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:58 msgid "Navigate to the `BigQuery web UI`_." -msgstr "" +msgstr "Перейдіть до `веб-інтерфейсу BigQuery `_." #: ../source/guides/analyzing-pypi-package-downloads.rst:59 msgid "Create a new project." @@ -1537,6 +1537,8 @@ msgid "" "Enable the `BigQuery API `__." msgstr "" +"Увімкніть `BigQuery API `__." #: ../source/guides/analyzing-pypi-package-downloads.rst:63 msgid "" diff --git a/locales/zh_Hans/LC_MESSAGES/messages.mo b/locales/zh_Hans/LC_MESSAGES/messages.mo deleted file mode 100644 index a3d93c5db85ccaf3e865a8a6aa196d95de131bc1..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 100727 zcmcef37A|}weL?WD&UB-2wDVzB&2%I)Px~qAd!TGbOIt`s=B+nyGVCeQ&pX$QISFB z$pIA*5fzXtAc%s149;Gh6|dvHj_DAb(Cc)a-|xTH-ltA?8WQe%-|H_Y|1<2f&mPuZ zYwfkx-u0vB@A1xrzt*QD$$sE9`y|O;7Rwj_B5m;>j4GsE?UfTw`UuLSN5o)+%E zG2mOkr*i+2@cgX--xKi0fFBKbU%)R0{8qsK3b-TS?*sl5RQdL5ciaculk1lSoB`_l zhX!m3*b#6(sB#|`aCyMv!RK)Qbzn2N34A_yHMl=`EBH3>%V1|ylAO}v`MkX|Nq)=q zd%+XI%jlE?NVk1{lKdFla{+D1{T<-9x!$WQNtS{?0w=%&4@;6Ob$?Nk+z);LJQpk+ zo+N$XcJLqIu}37y`@oe)Qg-rt6#NZ%(BdRHhx;#Fk|d{ceI>Yt>!&VDl7E5S;A@1- zlVlOkZvoeG{pc~23+!5vBos9{8C3tj16&PW51s-3H%OMrX)BXt8+a#p9r;}S>LmFE z*N3h0d=BQN7jS(Hcqe!=coewLao#`cz~AUTsP=y~g?t0J0VJ#Bo1os`kHWniYz?>y z{4cHt!F|Bx$0y0Y;A=qjPYqQ4&I3gkKL$mgkAU9?e-Az#{OUS?{%uh2{U`WR@Ueh< zcGKou9{}zNo(<~x#o)`p>p^|@0Z`-T`{2poW8gmEvFnrM#o#HR##KGwJHQ;*cYx0Z z9}f6a@IbB~178KcU;}*!E&#s^t_Jr94?4l?vjo)pYr^#@;J3IggL-e#iQaz4gP-HN z1U?O%P2=c!D>xfm20j%W1xLU-_!98v;AZe|;5lIRB(CY_KY?nGVJfSB+YG9HXMxWH zuLDm5KMJay4}6`cn;md2C_Zu&2BuQ;70I5@L}*1;3Wd2YeL#GI#-aXOHJ|M6ZAU)nJ|bCxHin zUjsY9KY*(5Oa|YX)V~e9f$KX;UccA$Q+Muf1eNZm14%*`B)hkGJ zpvLQWL6!gK;1KWq4phBfe|nO<5-fv!TI1@!DGOG2M++B_a^!pYzIXzCxiS;mYw1C{4Dr%uD=gHhwuLcd@8x^4jx*GVU+a?S^-O0p6xgP#H40nRzg%lRqr!(9IWJQh6n>?C;$_)U-^ zCMTTZbo4N|C)e9SwbNtZbHRUr?clR{N%cJn)OS~bD);NbXMm-E!{PZD_$=<94?+^j z72pBjGtPB-oCWU3^#V|IwgFWB=Yh)a?V!qWHF!r;lH3HUT~9vWpMMZkyWb4n3*H5G zf~Q^Jcq907u73#XyMGSXFT0TU$ZswvK5^7V-rj4#gShSo-ws{^?hU^3VyD;H;7hq) z0X_pPg3koYpz1jWJ|8?A)OX(ricUTXE&{&{svY;d#QEf5pz7Zb9s-^N>iwHRz5f9C zH1G%Dp5RZwr-F}yD)+BJ(dFMkjguE%>U{GsFvs<4!7BI$Q0adI{tWyFI2-)QWzaDA z%*(wWH-XROx(Xf$o&hS~4}g0AAyDP}9;k8qOHl3cFHrRM(zn8wz+1o(aQ@qzZ`}wU z%k@9NCE&`p`*^q%ypHR;z;)n>WO5()VXzMzxB`AhKYaz9$MvjtL7QL!TnrxbZu)`e z7lNm9{kAKU8-;*RC0WSgn1|D_|ZAgCe z-|OwN>RRugTfq18{2{OcZh9Ye0DlNVlF32WB?&_{xfvV<4<)hM;Tll&I^+XhzSF_E zTu*>%-Oce4ZH`;gAanw0)Gvbz`ug0fQ1{OwN}=l)B0=mr-FY47l8i+7lQL|^YMKesB!WRQ2AT~ehRz|+yIW=?t1ALK=Fx} ze3W*j+^fJ>bKQN1*YjHNWbVKCW3GQyKkoGUHSklU`!jekc=w%2@+ENTT}iT@^w0eS zeZ_U(-Hu-XU&r;#d*FTGxgf75``+vH@OAJ(uDd=-UBSPC6eT&IK|m3bh4(vO`xPkq z`p^STSBLNtO`Y5UJ`BF@Q%Q0u*!pSD?*Z_uT%Yk7<_h4d&-(ozf^2loLV1~rZ+K#h+_!54tbf8hP|T2S?x%yaGG}JOF&b5BoWqL2a4V<169te!~Giq-U>dI`*(tReow&91^jxz9|W8T_}hSg3;6VH{{B7z_X~Ik zsPeT3>;l#PM+ZC>d@9%L1HLBU>jD-)m8&mcCE)3x`u|*T4tND9di*pf{_!w)KKMKE zfF|f}!t;60cKAHkH-hcpX*-+_uYc6}^%uZ@@!r;7AS;ExbbV+3ugHt*bHKNNW4}(4 z+rhtrW$@qz@Puw`PHG^T+H=SQ1pEscr^G9a5MNFa1prrFSG%85qJULdHrAA z9`nfGeBSkyzx(^Y13y8!e}YGXcm2c1)1Sakas7{Q{lGt6ANo9a9QWtZNVC9m!Iy%! z1^jnV?e~;H$X)0$2in399_ZH#Hf3z8?G>*QbJ_hnA-_89(R%pU-s{ zsPwDD^=rY`b3F`-Z+rz*IUWY}-Cu$Gfqw^I4!#WKN9pH+%I^wL`F#k~dmjgt?yI2q zz@y+R!GD2D_sTt*Os}5l&j$P&cnH_u2Umhk&-Cvd3yQB7!gU?ImFo+^+ratHa(o0- zzVCi^lgXKDL4EHJ;HBUxOp5j1FTr)-RnKiQd&{ptNIw~So~Pf0u|xTM8&tV}2yO*; zfTFwN^P9~6axu6U*AIea>i-aU7uOvq|9bxypzN%_1I2e%zPQQkO6$N?Twet)=J|F| zbTRX#O*W1X15e@lgJ3_{^fKs)bc3M2ckaGT$>reXpy>IPFK@E>&bi=iq&u3#;t&75 zf0Nl~KKP0zvlBn>m0q7C1Fiz!Pr8%94}yOK)xYn{HJSeSaWKbq{{c-&FL*wv_V{JM z{{hv%Pn+R%^Kx)L*N1|l=Uz~J@y*~Xz_)>--`l|hz^{QTz~6$fhGgM^Uaz^Ya(ewd zD7riIARni{3iv;u%CX16&PhXtl z_rD9OeSQ?KU!3>*`-4jNDp38|36{aD!5hInn!UYl2Gy@$1z!!G(c<5K2t1SPb*)~X zhe4I&QBd{&EvS0!-R5-rLQw6s0-ObI0G0mD;4{GUz~_ONflBwjfVY6+^Y?&iht_s4 z_XbdOPy%OyZvbBcUJokY`#`ntXTd9Jm#>41xE}2E@7(~358Mjg0p1O&{Wr~Zybe@; z{{bEV{u)%ho;wdDzggh3xn6=$dog%CsD2&<-wD12R5|ut;QaOgP;}A-D&N(h=)MFh z-Ra@^SplyI_#yBJp5F_q{C@%Gfb$l5d-Q^Nt}g&pj=R8v!LNeK_YVR828ypfrOVsp z>7dH-d{F6UgR{Zo!2`iJf})G-K;`pvoGKp&pAEKwp8;P7{sB}!9}n@X-%bW47Y0Ge znRCMRHK5w>6QI(46Vy2U5hyAS1^xm2HTcC9&gbu3>GZJYtDBOmxc@3} z7<>R+0?s+suSY@g`5%F&f+wzOGQZDfK()gWtD8)(x&{^~*ZTcDsC*6w)$dC|m2(i3e*GO#@BaltRs!dMEf) z@E&kJct5xR{3DnHn_ugEVGXE!P6TfRN5F3IMJGF*ltIzkm%-nHd%v#9^wGb8HLj01 zh5V_{9iaN}7q9nmwPIsa@)@pc;HBWaLR0b;@N*zlP2N`YcH7b8xT@Fnx7$JSljrui zoWB7a;`()^rsUJ$L*QlL#r;jm$H09De4Ks_ypQX12Ah(z!K2Dfzn=wf=6da^P04?N ze+MrIzqQHp>ltb?JLIc|oxcA7>O1F-G?~5en2NXCpTH6Bw~V@8b}hJ>>wkgo12>=M z`q7K4UXL$;i@ASL&H2p$D873csC*XJU9Y5Xx@AIZ6v#T5o9?bQ%pybl$LGi_3fZ{Lvo#ErT8`O6n0L2f#1Zo`o z9JFx-c5=Pfn|(YT0jhq3;5Wd7&vd==&tRVG)n|D=ZvgfF72wmr>p_j<4};SCJ_?FY z-3#jbUj&uz;c)$ZQ1zPt)gFHU)gFHj*H1s&ub%@dpO*$a2;76~c2N1v2Q?lJ2bY3x z1ebuH23LYlJIBkv29$ii0o1s>3sgCO1nT>bfXeSNP;&W?pvG(R7UwT}fRdlj2X+4- za1}TURKIKvcrmDYTnDP09|kW5Zv*Fmhn?%+9R$^0r-87xWGkq8K6IWx{|=~f{1`0p z{1>3wYwZR8-bU~hT=#?OhjT%_|4vZpJ^-p59|cv!SfJ>4GQa_;X1s-4z?%I7tp()WVmzh#hO+T7#cLH(V?v5=eJwk!Yd1HiMDF#N%` z>@UaII)wA*fa0@~N#aWWf#9?;GsO|2qp%-5(0?=VN0j=yqj4DZ~+x#Wxf-ox<=jzjpi{@%#ZVQ1)pA^ms2|KfORNb`2izZjk=>8rSZ z4EQOIqr?5raUTDEz{yqIe>13YuD^90KjnCpX)Dk z@qSP|A^wT3=W-x&%%<||@Zcb>_u~+sSq+}V@g>gR1}^0o3F$rx9!PnbxYx>2;`$|A z>u(O%s7OhX<21iz@j>6_T7Ulu-W|>l=lV#_KLP%nV@}8e5nz8m0yW0}CtU01N{&vw z!|_6nD>z{7$qe3I#ZSd?hW}r|`3rfzEb|<-)ck`=bg89;4grRTU9IF{p&;r)9!{}$(;1*I>&i{p7@_FC>;$N4Kc@8f(0 z=kf0gTuWE{5cnqW-@vQDmvEfV`9q-bOi(=eChq--<1UW)SLWnk@_st^{?73)u7^2_ zA;FE@yOd)y$8{X~le{i-{#A|_slxm{%5gH+e*|9;(p}GaGv`m`Ky9&j1#a0N>W%&V zh5v8h_z1@mjte>TR|(I*2_iC+KXagxnanv5ERg2o9GYwC?>_GRizEJZg!8X(<4TTq za?A-2UkO$@F5(yn=?(=S;P_`qBY0mpe^y9yE!V#Y=Whwmq+9CmYKLSy&;LE7xggy8 zG1rJ$`}-UCRnGPYpBe6bgX`NlUdHhoj_lu|wC_=*Tg=U0a_q_Vnc(j@_Tv1#;HP>1 z6OK=E{0GN@+&d`r3#Z9`oNoc|;hFyK0Ds1D3CA6NE9n8R6tTm=R{C{rv!Xi zK;7#P=LhJ5zt=k??+y3g175+s*&Ii5{DbR3j(kWbK%}RC>p6Rv>vwVN;CNB`#837E z)^Yz{mR4TbZ4NOM?7 z|AT;gf&atve}?PKYsszC+`EQ*&*%6##|KILGV;{lA2?pcv6cHju4 zuJ;6Q;P^7f(4{e6q$&78l3;~N~G;rJT&{=_khbNzh1_;@>5lypweCZw2RjhxXIGcCMcd7Qm)(|J7Xo zH^)sJFXsLPcsTf0j`(*vCw~qX9}f3d20WYl=W#3w*Z&CVZs+>NoPUy|jbk6K|C?iJ zc>Xpp$8k-#o&lZ^&c8=G{hiG5dpl$7hI=Cc_WGJm=SQ z=x-kfn^QlF^Tpi151a=s;Lx1*$6WuK^UFipQO=(q&ilX@hVy%chb$i|)(^>z7JD}p z2THZvmU4YC*VSJhDs>e~0|WW;NPne}8!pw0eZ_jQIhj5C=u)n@rC2TH>Vw5P|CMXG zTD?-`-SNs;HCL}}DvjjIBe~I`VtJ%q+FEa(J)75-R4cVwzFO)pRZAnirQASiq*Sep z)rQ9H@zQdwcdS+`S4L{HXXliCe}x;RzFdW@s+G;Mi$|dnw3hxwkpDvR~yogbYs|t5M$Sxbmr2C_tTpkM;NG z`YI!(Ik{S?lQkY)8M{$cIeYqOfeU{K$<7a1HVd=J5Hu{jaoi$Z)fOhgWT2U&hmb3uhJZ@~b zr&RUxbtP4+o*O9+tMsGQVsE|NTk?n9^IyQQk#FBNO!8_OfLdU0sTZj6>k!M5hy(#n>Rp-R!~HB#DA zqBS>DKsA1)Ki6HVkB!zVm7!YFHov2_W8ng@lfRCnZ9(hYwvP4%^V{cfzOb`xZpYlt z)}(D=+q{Ky+rhc>=6ALw?alL(_SUwJd|P|Ib%9Ph^KEVX3#aY*_D-G7&9^Shw^`cx zB+R#30!|mEr){l`)3(Mb`C3}NRT#wXnD9;9nbZTjnJ`lVOP>MS{m&tbapH# zJ!(t=VSY8dCu6n6D+*L^V-69xIoi-RVCbHJq zAWhR>tqjM+Ysc5F%q?0wULS}wFM(Idzxm1gdMk~i2)oHG`NLAp}B~?Z(vVcr$x#AFaM#vQYL&JM7Wt({C z2IrN*%Gkglyr4WZM4r`w66NU`D-Y4SBVwD44$m~Qv0fM@bk&^ORfEr_CuV2sn6@{C z4qdQpU;x_We_D?|$~JiR(M-A~S1rCB1kI!lp2?SH zSb`b!+AQxGh_+hk8|zgMif&;3#YP+KJaQg?L_xfR<=(;EfCK{4tIF_}xTtKQ^mGti zQ>L-2rO_ei00vwd*<7wxMr;ga`hF|ip)zFLLGra{Jl6}4uB(8>9B3jmk?! zz8o6b3ZjuPRO727wXv#Kj*$^k90K)>dNIUsY|s~bktwyZhERPF;S7}&bA7OrUIhF& z_jsM+KqV&X3x!v$UA%rpfdRN)#e}dcTWVCYQ4UqQho%@Es3Kwz=2gUIU>{sc+mP7q zE&BNBt&H^3GW4G5Ar?hL32st zDMRdZQlze4GNMs?;n~JXa&=^}(FWzF2_R+TW?L%NP5tT;T3~Yhs=b4-j2fB`446I* z4TD(fHQvn-U$3U4mS{$_qBpMwR>~_YBYd0=tE0Zua)CRF@z-)Q%gv=`at?*3qfrB; zvq5Na%+>56^%AvNZ-*?}t@%6Ve@ix9Y!#k)`>*a-V2pY9<=y zG2J9`cw9kh8aln%EPd3+a$^8B=T2@rWn;_`zF#mwZi7v%Cqr*O;#`z!z?*arMeEK;J13j6jagm1s}YDrpSU)UtQ1%0xv2jNYyx5~_L+ z9>V}0=_^+IjOT_HbLqM0XcMAYfrD(zFq5A0h_t*#M>|eQIH_#{B}`K=O{$RjQX(qV zf#OK{bP9%qC_n?^pJnC;h|64ke6*BXG+3{XcD1xHuc$IA)y9^Eo*YD=6to;fD$(AjM5Q=GW|kO8VRU@7tR^lCk#A4}-zEXdYiNN&Pjg~5K z3KLtUt(rJG$x~|M>zWxN(exctpp8V48xsCBjklj?u|+zfSkcLZVn7(Vh8n87+Y~#btnx4~HHipZUmeNQI`T!!or7>@6@v*%Tf~?s2!9wUS|4xbtYv9w^AcEIsoLT%=^gTE^lg@5<(`<~i)(5y z8>=^^K%+IXl(F!z9Dps@XB=ah25A$=o<)1B%BH;4LMchBr7Ev zun5&lqv&iD0(K>R*EG0HvC+54#|w#C#xOL+OcQd?HT0t^SY~kYs%z$KDk3yLb4ukk znACPAEE<^xZ7+Q-oAs>BP+5&8IaER-2i8ReLsIo+=wLp}ee7=ZG&~2Uh;4%*FLi0A z(gh7}To$SdDu#J_v+$iql(5?auGBmL z1E56);j&D5dQKG`&up$$W_h#F%dsIFda>wx!$^56vz*-0RjYC{2T*RE_r5cOavYn+b4#C=S-Dn(SwyS`+hUvqMPCYnbzi zbed(;bL%wfm6CkXCXp~pnT1X2!;m$t_KZfMB3c|qV(BnRI4^_BqrE*8F3#4~RDC7L zPh+5%+k~NSBsWm0zza)twWx>zTb$BS#9Z_?~(a;>Um z^AGgrhGi0!#-phgO)l%mq(-vFiv<;-s2KyZoK9geDh=fCb2b~_jnPVm%&|9n*G+4Z zNf!61>t#Y6*(5O~Z3$r$Evhy!aa1sYZH94=Rx$Rr&n?W-du3y zk6r*}u8NyM38P17Ygi=Y2??PRae{k<@j)GM3>^d^GS27w>2yn_PIoz?(TqMb z$9yC;3_=o^s7zRfMllX$ruOnSb!GAhN-GW+?ulr}ll zVxqZ4(;g&G)bYogb0=Y2()$cfXTXI5IhD4WVijc@jlQ{D+G6>ezexOLOQ|Qf?jKO|IB-C`r>;l)~{bn#qkPMX()zTY;Z)0HA-a2MY1gR$+!(! zk`pYT7u_jX8wVAS**`n-&}=mb%4MUZ}Y-2Y@QJlxWA9LzT)VG0H;0)aseD3I*wX zrr{4&Mg}&zC&b)m8`a9_O&fgzoq3|kd~kS3MZvOzbTNGn#EI~PU|L?5F-vRmga$c&x<;~1NTYmHA4w5{MKvtRko`y>(m7cy z-YqJK9tz_&xdL*%G|1dFQg@@52e1Z@_1IK|S#%K-g{PDZMuVof!!lV0H{?)d02M%P z8Y>h{TR5gtkq&xvdEodlYzs_*PCoDyd6bOH(FioN2t@8`ShKj^=vWVuJ16J1JL5rOAShYtV^3ml>rz|-%8}kA zhKitRc*6%OswJ&P39$z>iWMqT<2zf-xZQZ<%n44Xhx zDoE@Rsg$mfahKM$-l)LHim6m`p%)~5s4PRIAA+G9A*hrVQ%X?Nq7s!caq;c(io`pS z2rkH&EgYHB49(lej;1Oi@O0_PYx~uqX6j$y5$Faldhd-4>zarLZbzR%N9A;ivA~P97WeNRH&84>|OYp-L>$OB?jWyjZ>sBmVl`JV&(f?(| ztwR>3QjOqkg9zoXK?{M*N<-;<#8gtT3fO&WFHY^x-X9rZ=T@z($cvVCCh{4{B+n0| zU`A}2-w!O;^5uFyx;ygqO5Q)0AGPTzlgz$S-j$T0@x1t6zL>Y7=0ysa?~^5!p|Rl+ zz!WPXA_Wv^^R>`ewN1}egJLG#z9|X=LXEzSs2f);bB$$KHOAUAUT(ms7D$if$55!M<1t4)M{>VAL3RM+9G^fO@|R0D_&~4 zwfW&rz8HN(R6vd8vu7lsLKUL0MTa&HNY6@^mehV`E$>0|*j(m2sb)D<=fGOrQbytt z{?#^b-U4`Tv+6Zev9Phw92xaYwN?;~sgB9gaxFD{@T3vbmOVGAmx*pOJA!$YR2flt zCa%picQizJ-;h+h%!Jzl+{_j~CGyQC04OdrtPG;qJBa0Tqlrps~){xvH z5mN}kLsn9tp&{b+Ok1zzH!F58)!Z=)(<~V?L=1~bCXu@NplAmRdxH*SxJ{Ll(3YBy zm7X*n%RhUG=ng!no}3dYfgx8!|DdpH~BONcfgQL>&|YZ5c^yV zLKueZR8u`l}HwNLewzazS@Rz^p4C-8TZ zpp_x1UX#a9Ey1LoEE_S)q3E)ZDn{^~22u99mekxQ3#Uv(wPq|QsJ5mX7e~vr)O|;b zohDs3e=2-Fq*4NZ+=5gW*O-f?V%uSlH|VWZT`>nFdi z=^Qjg`Vp$8DdGsaEjkVbk(S4MDv~5rwLCCb&kY*QWtDuU9qMB@o5c?zU3&*BgtB_C z>HC_4rkZam$P34m>np~3P_C9(dYI3uQ0SC@dQQcVx6vnLC$p1?SRP8+v$$nkCXHpm zaGRcV(G^=gCdYXw(>sq;3jBx1OvNq4)SVH!q2O1m`Q*Xnb3q$bh2VJ$9&bc>uc=1O zxf2=k^ktXZA8q7FI|!an*-&zGTU&F-94$@KBc7Mzc&io@hg^GGS9;pcDV}`OA(_Bf znOrY5W`I_J!s126_>)O&Rv}aU=!-EJJ5jYRF9S)M0+dSMwc+kc8KDkHmeaVQ>I#|7 zTy`{fPQILLmvnGo|G^dMA*s#7eGQf~RSqg*YKX8*v-q|23{`qCw4mrzThf=+L< zKv%~=ZEr<=Yd3Q@8LL`MEvNP6s+CKY9oN0AxgHHuveoZ?X)~|?|0!>1f^>j9aZxd9 zlw!lys=Y1#wn`egljJ2MFmNYhan>&X5868rh0#b#AOz1S|7hcg3P5hLG4rF1XUJg} zM(DI+dtuppq8#*4Mgc^=zSeymKf(HPWgnR15! z22q8p<&#Ygixlxv?Zr6S&wC;09nPzpXo+cNRCmVW9x3|07>YO7ax<9NX$DrB5&PZ3 zV7+&u<+m5{K3wc;ChkFN16o?=dt}5Eg|x*#q-nggh5;|XtuZNL;hN^h{0Z=*FutxyyfnPq@Li=;E9LD5Mq1WEJ@-e6FI>{pw+5+Z;Brb{c zjFzoq#c!q3Ib z=NU77#zrAeio&=QenmO(2Qycf<#_H(3q=oOYdvliXWMQAcHad|IEFa} zNkCLGYpCcLX(6Hk6n|P%^jR$pm=8FcO>+`H=7E2>*__9kWkqdG7Mjod($ct&HK^!3 zPlrSy7yV%|OZB2Ve_dqfSy{E&{G+KGo^})^QNAc1D0oI*VtjKugIX^v^|4AdCd1|; z=t@=&7qQqH`_y-%sfWHQ#wl%Jw5|t>`N`y=j5TRcw=jRGK?W|mYnupA7T-CE6einZ zo~B3BEG&u;)r&3d{G5EnvLre&vQZ2<1YtqYkv>_>p;AGJDj%6NN1ghs&C+oftePBa<8h3UKOVA1osOXT$M~b-+=@9fy z?_6=a)Uq6BkU1%vqTl$+5|bEfF$bf@4aWi9P#NP=y0K9Wwzl;y)WQC`?Y@xl4X8>nx@XW8gD}2i zYB#|r*S49dePr5Djbl2#qHl^6p+IGb%W%$+Rtb89xtl>lzm z{7Dj;8M3gt+{-2tG!P%ho?$9-N^^>&AbQ&qn4P*bk{{^7DB>O+7E{=2jpkx)bnB7j zzQa2^*&M(PB565e&~o?EW362AdcKXo=Hr&F&n=IktGUh@xtW{iH@C3>?f+Ae7qrh` zIHknqb(vwS>=3`9y$hkeyP>vnMf`5A+CBK;mU;YXW4Nm6h+CnDM4shJY`w8s+Io$% zyr)E8S5nM0)}Sg?PK&Q)Nr3mzzrg~b#_=%AFn@{h)r8okWfj-r9;Ilu+dg%f^XO%-*#ziyW2L$s7?XDM8F4Nr}_Q~l-g7S$p zcl8w_2Nj%A;8t~;Zb#F)%dx0QFNRfl9BK_yD!$j=Nb-Ec&FUuif^B{AAy9M!yTD%zt8O5U10E z6qr~T**lm&`f8P|n_067TSCw9DKcU9wF+d%dJhJf32xT$v(#zHs+Hncl08^cwABaN zq{v8HL1YD`d6j8Pb?$UwrOZkFp-l-J22YpHsfFDbhSpk{ENxC+T^tDtY}m3w~4k!A!}sDf1UA6T2$NUX6H4)t|$}IuLlgVSX3QbsB?goq7JQc!3MIOHf{=-N?eSzOcyQ?WUdt-jzQ6KiKP?ZWW*C|f8* zN}8nBX{B?Eo!Fa>&l)ArU45SbvuJuH7BP`sE z2P&|c%ZR9QSFOz7R*&G2*0y%h4{o+)+t7=3Jr?7*(O#A}VDjE+f$nR`af~7U+w2A> zno(bD_}aBDV*@e!%?TDEQdjsllGjMetqn`!xT9cnCqaZmT}%wptDu<1Yj?^F!a0#`w2&2KrdkKG z#dN3@70h?woU?d^IYT$=kH%`rS~?@}gZP0mbIr}k+VZFriX=RYh$Bh`X>WeFs?9bb6Rtgnn`3JG&Z)%?2%@FPMXMEwK$?R)2jQ0H2W>=wKUKU#DN<;QNND2&2$OoxSnnp>hiTHDc*|sYNbPKc zCR1D*a}cdWNF}pc(pKc=*~d!NW)eDJ9o@)PcPX$`AqqUqHz*+F|uMLq?ftSq*5qD zGerp!VxzSzw)k#F)Acqnh@eRmpd^F%OrY{}>f@gm8ARO3`GR@{J4i{|*6k4CvZ z`Kc)#LE`h8wKte99?G8U&GZ3QKt%#_OTs#SsG-lp6YQBSH7#wWI7*}E=u*i#t%2ww zPC1GL%IAuZt9>@77rXZvP$SjP&b;wSzC50J1rsmschhWwlivarJcz}~Bj&!op}d#z zsH5g(@;PaW4v)!K#*;Cd6J^pVaEP|AWo~iW&{llT)|_-JJTSq<&w`5jI48OoWs^uY z6_>|nA(t$}UD>^U!}^u0x;LW1ZN#m0c$@B9!y;azgqA)vC9*f^#&T+l9^6nSqSZo3 z-{GW-$4|WbZqhxf=`}CQU~HlpPxVX!0r8jl))_WaL`PPV$nKm8Yd8mcE^WbFWO$gF zB1#deU(t3LAqv_ilQxG*+a$YIx<(0nt9Z-P?>o8h)E$kPiH$3P%16F7e6ub!Ma&wj+)^B3V;|oq86Si1GlyvnlISX=ui31Q(z8xL|D&;uZN=nBPusTF zlTxRoKxl(@3e7i^YWh+YXgJ~0T@|&lDa4iCSnjFvri+R5$9<4qCA0yU`oV>W6WM%gh6Ag_hyr79%E8n23nk~HD_A+T*x_wI!yXp z(0UXup-~kb@FBJW58tSVvILrBvg;u+7HldDfb&nfqRSezFbXdz)`$c+4Q(!{G@={r z+oCVHp+w}TC=;2pwW^JXO8h~Ewf3?sL+YHzi~E2MedS&VB}sQnwvp!bmMc$rAkF${ zGW)TNNZsiS9zCAy}MdnFfoBBG+V`@R~G&|GeScjce)a?9&fd zNq0StlLBvXD`wF6W{eW@!^T3Mr56~kf?J3c*)V?fg0w4|ZYf*b8cpeanlZCu#Sjix zo;4qTE%Y93Q|ZRB;Oj#SNT0CJ^8m(g3pSS* zF`mf6L-B%nlEQ0?7Yi`;5W+OZ&`WRozKalvYhkIWGvi*QIMU7YSF|?yr@KnI_?r9? zg|w&NVGv9bTb7NjL6qoClVRr72DFUwbQ86x;vbUAIs2H~8B$x3hLi#)`zohv!2{IA z=b+U-`O@7X<{CIG$$}Ma)@>s(l9gqvS)2VHMc6~$$y75Po+voS0%@@HHY|ggS8Sn+ z`d%b%rBJzyx{J&RJwRRRwc0|#NJffLfMN-+5nmWf5Z0m4TSjx)#*JP`3(hp=A|jNz z00X^kaw27{Ye8#ktG^ammf8LkDHc^1M1w8)3Zw+fs@5@&dYM&|_$FMakG&1U)WBXt z%8wAcihEtkAj3W|O;a-nE0AoDulu4hT2cP%tUo1nF3aZ}U9H9*%#K14uxR;2Fy!U^ z1fNmy)R0(nu@0^03Q^2RO`TnIUe+!rMbF5VN`w`!$|5koIhKR%PuB2BOJUb*LGd(s zhQ$FFq3vyG69604%4j-IdPANE!`PH{uzIf$vuzkR(1s>$L*;8S!%&#C6gIvq+X>BU z`I)84UrEJDYVvu)tjWb&(%NCPg0sXnw1=I$0vT0_*e6kP_~6pl6$KPTVOUAXuATS| zW3Sk-@E-L~Q7bdi>jT~`l621Zi%gSge&uVS2zWHmyO^L^F313$m;xy-qEw-Yke=eN z;~10CtVkS8sCfn3qhHDrTNb13{!U+@n|Tu=I$6nEfKmpE;6u@`6YBB~Iz6zb#F z!zkgRn@iO&FTaZECe5|4huj)qUoM&Kc$O{^pgQ?p~a>7bz# z!AZ3g%{Qx13}qbmv&`1+R-2QkIvDgae!IB#`B%c|I1HZ{can`1HmFrS8R zncYnMxmefuwx8<}D-KV{R=N%|Lpj6YX4FttPk1c!scF4xWV@4R^r^5*8zp5TAorqb zDY@<~qAizfAHmGy$IByizDo6?gtWeSK(Q2SFk0ydT`y`NQ21X`pQ+-DC zRVYLgdZ-#ovW#f-Mc9c(S&9%EPTsU(;wwReBm1pZXIFcPGtKJo5EvRn8Vcxi!15%$ zB#$3~Z}C$`_|Y?*ouyG+rKfO2XJc70)3n}-Yx$%cVokM9vigOxChMayr*UTG$rw!Q za=WOF_4!~ZkQ|0H`JPYEpqvHS1<~5TEO=&BJNE1tL7jjf`VT4Od&V(@vTVl~zc0Fx zB{o=+eM2EkXGHXtv|$0JLfL}RB{V03y${BUs%`8$NG<7%Pz%m2Gz$Wf$zH5pCKv@8Y%o12n)QzIWeyXAE(Y*Nq8)_<7Jzy-un8oM!XkEY6GKfvme#1k*y%DI@gP0g5(s*}8=%jG3~{2!q-4$LYzY5-lD8kq6h z1ntnm^us5O`N|*`low)_;*U~>dOluVqN_=Eg2@wim?2w+^L5y}cvaZftr4V%klD%e zYb9qOhf$$GF7bb>#TMzvMV&J^qvKASdNod0bHhr{%}0 zLlVf^YAeqUzrNyRldba(<7`q%XDo@EDTPw*R6_Kh$>me#sRdB_K-56O>V+rQOt3h9 z!x$6oq+&@G*BoBN7%L48l(w=1Jo9FDsM_G61|P^AngMlk@zYN-G$6&&N-g>><3>KB!KtIJPNOnCA44Y3UWi0ph~jm7EwN>$*$z z^qizKvg@H_PMndPXbd%7H*7X`i9npaGE-CCpy*K>cL}MEbf-$^ zxH3j-dQQl?(O2Rd(h#WzstkQ0J!?7ikvbuyLRnnzWU*nv7_(QHvGGIcDpmZfXF*@jUKw=1H2rMa%MBD}O%hEj_~b;KKI|&FJHaP|C53K;7uLc6 zXgQ1K2)D2+Nmo4yJ*nG&_TyM}^kUnm);V;1dwm)ffe>~&GycdlH=E<6_>f?NPEJA_ z|{iwAADkm?^Dj7xHB4&tRcL0sz*ZU8^ttzuCYz9#1%tzY*cHeP}S^*OG1cJqZFFf zy6TjgD$PDffP{Pv3Qo=}Hby@f@s$_i5pV%jQX985)__H}7B?hoSv1Kda|BEp?Eq0t zNM&~0QfJ=E&jMKB{>EH_YQ=|W749@#2y&;1Yf9&bCm_$16yaW~u4_?wBtzC{P zq(bou0%n} z8uzS)uUDq202OOSOF{Y3uT!}r`f&?CIqZILbW>+Ldw=k9*u`@<%VMugQx^56ad#Ye z*6NL)YmGTiZO)!CezbL{I5yHdILf+Q)#3EsG?Vz&F4|_AH=dyRV+s8?&?xFobfImQ zd+{9bJ1#KS($LfZ<5;YzmC5um{a2in$CMU+g7WS3YW&qab%Nq|yihw~GE!S`uHjK`mEvtj!G@(b8aHveB{u3wIsN^QFyL>an6 zh7OI5GmT_{Z@E5&=ypLsdSkja&15gOWV%|_)~tuqX|_mb89?mBCnoisvy1QTqO_T! zOjl@vvTXCqUAN{FlrLt|lAcWWDVNcxa9PrRQoUwF-U)m9_`9-6q1ZA{P~u(XG;R6$ zc}Gnkk=r&vC;iU$?tBw7WzD!{%V=q9Dtva;f2FO{7KQ<;N@&+>+RzoGG|%jCosN|; zyr^HPid{#Sf$R|T;TO-p#S-ZH-oJbgdz%zmDrc-f3vCSB}iA+zu3m8p$p zRt#U_u}em?tC7&iYszSNf(jZ}Y`nO;wMw0k)7ELQym{*Ac~Y$|BPte5cpN$HZjnej zEiKrl3cD`Ot{T^}d6MmF@9bvz)3j45q_JW>Wu#A@`!_Oql2vHDxSRE8yfAHVXn~IT zYSYTZe0S9W>6=fo2I+hH(A37Ab`rBQt?sgHnhQPIa_OB|`CYI&E9P|NKOHktuxC_v zP2*3%2b57RqMvxkPAD%lswT?pJ)rTsx5goUa!|%Y@t_1vW1e$fU-2T zUQAJIPA#5(dJidDkVw9EYIln|`GvHYPx!S;e`yoSE(^kUv(M7Blk%4u*_a>>OwoKK z0)|Vh@Wt6zWu~&5pPKHq9m;#AU=^cEMw3~f(H_JHnm0g#Qu!7B{e0EEU z@{`i_cY1#}OS;p0fsq|o+1lv2k;)U#41B$rEP}xtXaOOtqqrSd9+Z#T3?WD zvwN`IpWO?B4Un4&{}@3I_SemfK!AhdU9!siI>8e*>PHI{PMICnpD$R~CEiO%u`tUm?V% z2Uv^wwQB`UWa8~CXo9d7Sv%4d_Si11u+dWzcfRIT#l!F$rt+z3R9p#qpNb_5}+U%uCG^;hRh2mJ~~Dqfr`#h#UVc$^VNlc7!js zE|@!a(ibhRy-^7UsQGMD=fZ7)9SIYgEvb}?a?qE}m;*;@E&QZgWJOaIizj?< zGW(l;7^egiKBf=tT)e4rhcTj>>(Y_?MK<=Tz)+%cMied4lfG8F-bp`Pv<=2ShUxC~0BP1Ip8TGcEq!PYIr zOhqwrtC^Dr8e;Dy9+j$k6~ih1Lj_Ta`6xpsWL&Y|Vs8#V9lv^Dp&>-G7xhW4#kGw~ zJUGQP5<&sO?&?&Hh*J9nEHNIf%we|}YcASCv4-}8LC_%d?__wGT(?;<5SqyYy9xyY zvDuTbz#iv*vYgd^M5y}3I)Mu9p(MnT4vY~V%0~mQ9br`}?d)66Y%cM!G-jHvQ9x~G z@G0akc2XJ~X}^2pi>}mC;e8L6AzDsBMG708)JayK-ioi(ie64_1`xNiY5b&pgN&#Z zdw}PAjjf4#QfF2VwWGAFv4c;>v>*4n(Vxm_!Ob=!hqU^XFYkU{NXu^~>ACJ4Vb zuK3@=iPP;QKUy|L-B%B5FiCBmtiPs7rp)$Z>Y(^eYa0u>qwo4>f?iT+ZEkCx=M>Y{ z+}Ye-C?tgfKLX0m<$hONB6a%R*7nwXYe&9yVXn2ctD~cmcUK;_ zWYvbH%j|sB%A*ZecX#(~vNMLz=F)hjns*nwJC2%rhx_d5^pO(!R-m)&PTa;#JnW=l zk0|WC&NFPWN}thj!4Dn-uo!kO2gd1d9;ZJ|!;g7{P_&`(*|P(?Ahni$;G#jY*R}K0 ziE%+8#HlEM(N~m-7PRQ)gIzK(Ev%FTBAzt%(3aa<(RhL=G*%F@uwaX3~Cf^j5U6gBsbG`KhNF{+n?JTj0o@O5%x&4mM0rU?t4UxZ(D%xUu-FsMQkN5 zd~x4smRArEH&iA$;Q=NE*&#-|V^{gbxzZ>Q=LsaOpe||XCI)RG@CRbsbN7RicrvS8^I5;u*USlbekArue5&H zKm^ek3%Mf>&vh(dD7Q{|K-;v>Z*FaFCApcAxY5?kR+x#%$*0B*Mx2r7JI|nDL%cNZ zZfC{Ry5RP^-V=?SV&90Hhj9>M5-qYueWS4vrx6}|yEZ$U2s@9l?i1l2b{g;~E8o+Z zR%FgW52L?Z#5@7yfhHOnzDS>^==1aA9Avb@uQ1UGgc13OO^rYV`Wj8Cd4mQMBBp%r zb|ZOTQ`6}3uq&!ZA;smHrkyaq^PdwXBB-YIX^;cmo>^QmB_L6wP$R^5zc9J;INM%W zFi>NOrwt6H55*1bKs_SSZ&a%*lDSYVb(=~+AZOotmb`eExtG~p$-bD49^zL56KZ)G>cP0qM0K;b3?0S5>#LzEg_yG zCAT^7cE1SvQ6dj-VkVm;Y}&w2`Sj;a<>q&0X=eYS+`cM1N#)C>dVl^@m~H-4_9V2Q z$we$#3;r)(m#%C-da&D>oQghI%M^k|$yywme=-Hh=COs$R2i5Szr_<*lPKoEswCrE zgBLx%t&!!j>2DQUT@JK*6^HV^6JtK|mSn09u+t6w9PrL@<4N3OJqbTApV+#`q+vo# zMhGV4zu}EhG}IEUp-F|hm&yzpzRa3i`5b>|ne9`H$O)WrWhOJe@?9gi zmw0-K#Z>8VRi1_;?9(_(SY+f(IjihMz20`vYPOR3WM6xCg_lD)P%jTv3fD>#cj5)` zitNl{k&5A00y1R_ec&@P;~wmL6R!AViAj2x0Q%2d!e6|rR7WIuC{O4v+_qk9l;ab32QL=`<3b|BqJz8vHnN6<@eq_FJMmzZ%>U(3s(?lc&n2cq_yZ8Woua&NHR?sfJ{?sEqbP z(iBGmQ(>O1uzj=MsnjyE=-PgjPTd}V;V@OK8rIaPx;e9pBUP%la>6Q#lpr80B+~#2 zh6Go}BzhxLumPPJ_QO6RvOOCmVbIz12{-_&hinT6%^22X>t*HxK9p1IdZSV>ej$s{ z=JczPI{6tz=Dik{n@O(f+dY|g=(F+AYeu$Q%B&dxTZs)@O2w}~YRfd{Bw^`oGQ}m3 zWc|>I@$s3nSVlEa^NVJdLWZ-^aX+!POXPt~nAbP+3qOO{0I_}qlS!fpGYvjGnwZj= zKv#(Zz3e~QlF^zj$q!z^NFtLc9O@8TEfj1TqfmC-63ygdzuJ{F9EyoCm}HWpDQ=RT zU)h&G!Qbf0ErH_n!^bnbZFva4t^_0 zwQKU)U{q>Oeko$KD|gbe#q08`*W{Nj&aGI}wR+{DuU&K8vc2`YIr;TiXlgK~O0_Gu ze8Z|$Ic;*DTeNKT;+3n8TD)}Wx@FznN08LbHTm_}mL8{2={(=J>TKpm1vD9R!*y6` zZZU(6eUyXA-+qhx^udiQC`wD?V_ms$Z|~JC_-`~xTXXB)OMF>Mem%RR@PonVbuC!i z$|Hwit1YshbN%oQ>zC&jG}5V>EHce68|kIvwUlK6rj)(c4zcgpP##m&FxxSYjM`=G z@V3L4QR&Iyt%vRXn*1^RL>1eUsf{p}s8+d7CM9hctTykROx%6r_G>PTv-{G(09I*K z^4!F^=WKuH?b|Q?$Rk(3o&eM zapT$Buf2u>OkDn9y?D;YwqJD7wtFw$e$KfQXI(vU!~H7xZJ&7Lnv28UI4!o1+S;I4_cU$X7N_fjjb%(i)D| z#hLu$t329v-_;Z6UCIY0F1UTiZ8uD5h3n3z*xn%TynW)oBj*mQGH@4mX;3HS?nOnD?`JqQYc-i*r?(-bZyXuio zUbW-4PwqJLT)UA~d+Y|f4cOMa?e2?r+<*V}YtG#MuG=5E@Ph5v+`<=`e8*+&N!$F6 z){cb>z)t=;lC}k{bK5%F7tC*;$N9p}wz(a1J6n^sg>CZ|&TR+h&YR!amSFHom;-j? z+uHN33v}9a zvZJ+q;X?B5oZr#bnzVOxcFtSap0sy%bab}2%}v_pwJmJL+mm!O>zKzepJPEXuVX=5 z``q?+N95;){Z3XV&dBg6yl|^Zrodi9K#11gbwWF`fYcA zc;ce>?KlVex;p9d-8nlJknD=vwqJ5q;! z_UecNA9>`m+ci8samS7i+&ppLIZ$I^Be%ERf6cbL?+stFW-07qj-6pZ!#Ned5?h79V z*;dSSC2*U*H&wzI5Tn3=83YDwCSwrTU>hWc?~>>Yde!*|_xE4_y`S@(BQbR5bcGppw*msI5YiCvj?Fx*S$Ee?FMre6bqjXL zPqW7-q3@dd(0*`W=I+_n`AIlPIS%LBm^unlx327KOpQ0jIf9Fx)Laum>~B}Ry6Vk( zokOH`Yhto-|5$tSAw#oPaowHU+mm;C*TKDQqpYMKYdR7x{F_zsEmI|Gnt%@8^CPm9Xg#uICnhvA=>p^e}PDEH9Z^KIjMa5Ulj%$=hgQ|`Ak z!1X-R*uBQ&T@I3oLiiTfDc4^7=jeVg2VDBkQHc#SYJERFbMKzWQG$Nltf#qobN4U) zCTuUv&6*RpXYSl=+}O`d-dB=WrY<3l70X^&`m5j68O5DoOnjgzIvM9*7@Ed*m<@zn zck|9c5V>*TRNi;{#`X4yVp`SpseygBYs~{+3uHk^ z4eL1zW|_L;S*YfB6X|>hLL!6kB_iRQ(Z2k7d;bn*?V$bsod_)451nng0`RCRaVkvn z($!q?#){`({B@rKF4hmJGS4#p{7oHSgb>x59dcMO5*DROOL+j=3})po?n9nOHW8`8 zTncuDsvr`%U0Mp72G=^mU%X_2Yy3+@mYJztGxyGMKg$Mu**dqqF?ED#*$_j`Oij&9 zUu&K|+dMttO_YuKFgtysJ&D#RwS+F>smM~fmndYt9+nxcOmf#3h-u9|qi_m(8(5&B z={y7E-ONSTy3bH(m85lQ>09bxKW0SURmS|dox!ODL;0$qYrZHkO33gM2hG2pdiLm7 z5tz$GAcr=uf5Ro<9_B^FtaUF;%V^)Y)V{nOn8+}tgB_6oBA zVi{3(gGBYlkne*XBXMbTLv+Kt=8D1bOptK@aX$}zM8PPBBZ7?sza9MK^@#l$@B+0y zxj4-ujL=ouP%P^r75Pn{LQ-fz-Zuw6Ytf)}d0Jxn*iDWBB4Xx%*aX-lcHKYFx-UaU zVplMfY~2vb9=Ij?7qk;drt6iCHLxD+Yo7brls{9~{fN5}BqBZFx6!zB#2mlL*uQ$Yc|B>pA@y$O5;FtkX zt8wQ}xsQ-=t_p>qK%?6md(RJAkd`F3K1Hs(GC%#+e5pcChr4L5NN+dFScSxgBnl%NSYZJ~ z&4ZU^&Kti87yJEt%Rw3~l4H4khzYUNnR#fbEb{H;s|tyxfB_*Y3>7pFaAEH}asXW- zNusB(0Sezh8!2g5ZiQ8)lONu^L5g&-j)%X>qm7Fssbk`fI9Uk$bZ_q8&1sfmM5$gd zePJZj38B7+N|wlk)t!sSQHl6f`-#uKaGE2mri{)}$#C<{O=NJ9o1cGZoxRxJa|6@p z?8Gh`IFmlQXB3!Pk<#1@+B|)O+vG)X;be_H`aJ?XP?src-?ehFOxYYeq}`m~g}Bc3 zP2Aa-!m6QM<)S<;H?b~GP0~q4!2YFn8`PsDO2%;=NAuxm^Y*l1P*uxo&7WZn=OmGY z5+j%%I?TPpUW6S=$Z-$;Vzfwn)p(xVq$JnXla!=Z!P0$Tpm zQJJRiowAu4aG*At-!Vk{!4Y;OLni1$I}9SaM?FKBL~vQ4(GENuP_zPc*^(x=vbpC0 z%(-}T)!T0s9+VY@ZC+Ln=>hjf=^m!{5Hc!6U1m6@Z~i#mzC6ZZX}Gf&S+C%I;5hr3 zxxcG9b{J_A!%TY;b}w5YldW2T@^_%I_k8r4a(jOh=MZRZSW6fWP#D1yuKe_4YeEJ; z_K^e&D5pJoox3YUxN`^LOE3@NM6|C zO#YG-47XsRj#!dUNUl8T_Tl@LxS;pZ&{Tcx{dg;WS>+c{*#_stu?_9nQ%75urZrx| zYunYd->`F8+$l*ac!MXXBpg*+nh}7G$Y=>fr>|t0@OmjWNvVTkg~LdVZ~QD@)aC7I zKaDW-L9aYqm8dLx9VCc|cDae|^8S~h;VpQWi#IyK(%f0L*53PBT)#2M-ysv8aue(} zxnaU+Rr4;I2X?il57*!=Qn|wj-2Cz`MkrQUhiwj0o^gF)yey^qN;sh$tZ2M$7vehZ zIeUAKUu-;tHORmO0Yp6#F|7Z7)20t``{(o?1pNQ~3#<_W{pl;SpM5jCJ1nTv*TgWw zvB$!EYK@)OkXh_1gl)u5!$~D0rX2*_-Eaez7YQ>a8*iSwi$>2JShS%>W@4f>c3#zH zw?Ay`JRo1)?y2VKtI6swdMh6o6S20|{llWGCw9`Olz4s51==9RtW&-@E_k-}c>=V> zMD$ookP^DIu3d9`jh{V;^6{~Zn3wee5bQX7=_Ro_H<+0oow++!F0aTU!Q@$uoCkd9|4RC-0=~jRb#X{{p07&sY5!BnJE@HA(?4x7k(PBVr(934p+Hm ziB5peUCf_rj`W}Bhfab*QYv3faqREQE?iZAiuxa4g?VH>Q+1rSt=_O+mI-0F2`@7w zVcSeAZ@d*N zKYNICmwSBIkD!_+3sJc>al%lMoX2Xitx#|c!4oVr_yxakQ-L<&_!R#~RYjExd#a2W z_r}ecf_sg+Usz#(K~f5(A~qO?yp?&gjBK{p4NwBycA}kfoOi$se zggyI@2wUYZSx5YhL-4$~U0Cw&vM`8Qx^<>)KHD0Ew1ov7o7L$lE?cdSTi%*HULu!n zPtfq$-Q(=EX!&Pj9?qzD>u165r%~2c<{K zib#jn4=38UZ<`P{uU|ym($qPGqigE+?Mpb+(pT2gx___u$GU!ixPeMyKLl{x1^Y9v zMQwm3QJ)lOpP`BcnPU!U)qK2SA$6r12c2~oQAoJp-4_#aMxtl1j?_QA>!kp z1-B5on`d@d*3W2wG0=A*+3^C^tX$R28Gxe&6DWj2U;i3u8-L< zrH~IS`Sq_~3etGyV)N)-WH?_r;%I~=u-?}FAM)<2(o@Y*1hv+^DcaT?l#~AHj?K~K zDkF2)x%{6BlSvUcnh%0<@axuXEas!AhNZOTpdFEzAPhKn5HK0dQa0;LOsjQa3ccA& z5a|fRd9e&@cCG-IUnl9yxvzbnjFg`BF&;?azMD z2Lhz_f7!Z@Pwjw+B?hiT`xze{2FI*)7|>neL(s;b9SYI7ere|JIjQU4?39Xr!%|jg zVMrD_O;d)-7K!}0w*xa$^Y~@#2l<#;vZ-$k18l8v2xrQbdMT2qxNeD92=9d54)%9a z#`~Q`7TNE-bTCr-RMrfA7+Dk%ww_w4fm+HeqXjl@ZrAFOMwmHq>zX~{6621Z1;>#$ ziz||4P%IX*_cp%32Jv+RQ{A00 zovw{`=^udq3bb7jK9WZcet{I+{`?fDRI?CjlV(l2Pv`xg&0*7p9U?l&t}uQGk4i>? zj`!*MrN-gC%n%gxYKVqkH!gfGlK0b2j3Nb9XMg`%$Qltdsnz|CN_E4l(?7-1C9jkp zm%dVy%^*xLLjLI^jhhdWnF^)$&OW#{#gw#mHGWe*yp zR)FHZLF>QV+g_U;{Y>&30RgF%!t}~7(|6DJztH(EH&no!Osd%7gBo+#R+Uk^9Ntr> z>55mOS3uixNau8W)zYpK&~eVtgnD|bXT!Ru?AZ0rXW3c93G|Oztz1?-0^n^t^Fl2M z74^54zy8KME8pnflJmKG%Hf3e-L=iG)mFOykFPgbO9f#s=xM=AEu%q_ZY2X6RNwR!@5c?*^Aw#Cyy(TIk5Dl7X(LRlO-GBtXBgh6>$acxxBB} zV!$44v8wV9uhI6<4kvFs{BCyiEb$z($FEqy?;L!T%dhhC%)Xsh$FqfNKaQd{BLkh! zky*EOh=o^gSams%G^3$)qvi1)4siskw-LUy6jO_zN?%$(ikNO(fqU@*p_YQSsq9O2>*jd7gh2i0$n!q6;T_$Nubhm-I-6BCn2u>=(IiO6r4@le} z8Ia-|(JydWEk@dS#Wrcjonb4IaQ?@5>);7333+Xuy^a_-d+Z?-TYXZW_KgG0?|0)_ zs>y&x6l;FgL1-VTC9csjpcnSGf`7k2Y{vHSF^RIFlF!ldi@JpLXklJgBCFsO=L6Eo zl{Y;evfeHeOhARz66>T0nsPNRkdVPz2{>v@+(uWGc`sZ%ZqFcW0MJ;bL+Aj~jq&fW zSOC{_T(3sn{YVkVR{Y24(VW;BDKW{XfG)Nf7d;CIgZ)FTGuAJW3()95BeDva7O|6A z7cFY+9FyqUlUXr(RL7gsDw@~Mmzfnre4xEWS1buPp9#zY*Au{uTgA%}7v@O+SZWdlG&4A8h_uF>4igo0; z+wmDIruY)$a1%l5Qfq{X*~Q0QM#fJej zI`mbU_o|CDSb3>b;C(Zd+UCOVBTGkg#q1`|XxdKu#u*M& zc3A+?-9}XO-qGgRI4mxdQ~lYV{NXS6&d#11S7cB)G6*JZ9m5o%c#Cv7_U&vu+|k^3 zqIrwu9c7*YU+X;vkg!W6i`!>K2oWSRi&11wTuYG=;+J~hTK5|AOR z3k?(yu~hoPliiHnc_TUwi%so=KPz#>c{U|sw3b|y+2giZGO`Jx)^qcFBXhDsPAV0E z8FdRzPGY5FBGXp)6%7jWOqx2SnGvHJ>L)!hd(GTA-M;uxhD&bd*v-bo&Dm2A1auPT z!h4-CI|;>jWJ{E-`(}2Ho`k_fd7ba2WtHw-9rCV|CMf(+W&$yv%`Dnz)_pXyVHYBR-2!sMbXyObaG8$D%P7;H| zAua-Q4oXna;q?dHnby_gjd2#Mi(#&Bz*T(MY z#?O~#9$aoexZ6A@>RQl2vhPUJbK@d?Bf%)9gRv`#>-zB}Al%Dfg91Gc9OH7a4a;{a zYB^d-h9v<1+&y}0EAgeyBQCiA)c(c7Fpb@rZ0!BEv3s1vnb|MK7|vIMo{g_|G)_O5 z{cIA8RrBaH>t+-ix7lOJI@XIKjM)AZWXGdduzABU8oP)H`azb7MT?NmU&44QgZ|RR znE%QClsKUL%0-K`3*x~%V#NJw+1(?Fpxqm79+fezv-os-=J9iLZEVg#st!-KWGL>2 zLij3^ffZ!EYpq8UTQ!rYc66BKg=$^5dwM{PpYW zH*KY2B3ZW7g4s|=Dhcas(Pf=wN4ie-QQknpBPUeZIJ4iKXg_#RELmk6lx)Ob7s;{E z83Av4`}SSJ!DcUrvNn&OV}USdPNH$(e5sMlRS>D9G=P?V{1f3}l*N1|(PReCXa@5#& zoFeQNnQrF3vVkDDqW%%Cla4Y`8BSS5fefC#dzGs9^Y;ja@+^@j;Iyj4Cj_+YaTB(V zAD_8*oa>A|wsGNGZV&eL#-xJfS|IP_Phx!6FDY9n5>00Apmd1^B!e5e`S@X(Ok-rx zgw}WGi1FY8lknx6=tY``iF4l^=Qe5`2fpS@xG!v&`6N>8&`*h~?7Y(;P*F=1^MmHe z1;90qk%i4nR+|0PE=Mslt4%#%2j3UAh;efdAU=||#diqCXD}*Qi%N#l;<rxj`fBPpn$C~qBb5(vKWRY2&45KPUo!M$Tz=XXzlPO)oToU z?%>A057%H{@Wbr9=j4Jxt4B6}`oD(O{lg0{kiVXVLFyud2QKB3+oPBX1n7v*3*Ei_j7*Dvy=r7ynxh&6`4;kiN? zJlO_aPmo=?W$U`3O{BUm`4x6YIhD|dyFo><1I~cAg=mn2aN?^^4-eU6ZXo?0?WzwzK>M0Tm7Mp`BE z(U&)&(MobD2?GLx?nTll&>zag*|g-!uc2@7d;F_#xL9E=B{>mWedepi?}kc~?WEr5CZdcw_>d11>neED%}{^cDlY>qzOsL_O(l+jTdlb06!s@Q7hC_4Xg^s+XGpXkeoGY{jkh-|1bpDfjQ z@F_y2QIqZ}uH2ZtBiWTCc&Eragkd9fCb7_O+~lPEX!x^)#1i4Q-Dj${fgftaPQ&-u zJa-3mD_0tjAwceF<3nUFGkl59tz-L9SFxSGwR~ZLuTQcEI?3IK&07;1F?d?l@Wvtp zO2>Btg~U-((5nk!fHEC*aCM=sJ5(aqXOtlkKB9fk>?>eEyw~!*c655-0R%bHyo7#{WWxs*jRunC zlCGrASR{w4)+=m3L8 zNjvWm6zp_GEH#p^QDO%M;ZwE5pet1n*kVcA^UrKQ=iPJ`m2W5@SKfH}gH!>0)sgBT zM!u6=@oyaR1gBBVk7v_7O8KF2eZw|V&`QCuON>#f+<<m+>zwX@Fmvw}GG%|H`Co(t*+Tp7Wd=(xF?_>`~%I!+Bj3@&N zqH*VIDWXEg-w2}t@1(`&$W_kLEJbGmX~pngFLBg{tkN8Ua_u5pR9yB?q*>%wd07IQ z!NUp8lQDsc^d?`uY(wf;)#~x=g)8){9{|SzM;%HAjJN4Ao)BEZ+H$cQ(j0Zyg+_*5Tlq;=Sb=Cm?mR$ERyHY}ODJWs*R? zi9D5>gYI=7?F9-03%61yo^1zROef@YsNflFf)Pm)0a(ZyK$;%OG-?rgl_IO+>PBdP zIiLwG0yYIRUCc;y6_aFiD{m)j5GNIL>{J$UMU%3Pj;3;J(|&XSne57G7wJAFhB$p zMJ7tgfDSg6)2C$W^Rx3rKL!RrjW_1|NU!Ys;~(C8x9`1`Z@jCrfPHVi@$MUGA>ggt zEeJ^w!0Z)a7`FU8&+U-T1Uqg_-B!f=pZZ5J_KXr)i3?IY5+mb_=HU|%GW!zXh;#3}C4@V6yOhnrbJDV^(HtQw!GH!TWvLyyk){nkgcT5(Mu3TM%hCy{ zK>KROQq9su8ETqRR!SJ_QdSYt&H1m`(VnqdYwAYIa$m55>ehv`$rsj8ZkW7QCC%{} zR+wl~FfVL_WXOVn?b~PDx4*G4R#6HeB)ZycBLp2M#2fHHEQJh%5BXNe_y&OVI4y%_ zSN;6b&F0l&DQpn_vt`ZJwI7oSP`2!T0Y^isafxwW0#itrWd6Etf0X;~ql9*0Z-5W6 zGiL9TQ2Lt?2)(gQU9j$Vq1c6_uTlunInP0rrOmt>Qk>SW$3vG6&ez`@;#IhhhCUt~mT08nvMO4f`XyfL z%FOy>m}DQliynH{Mb5=ktIC|%zPWN|Zh;{G^$P0B$kuh6igg>y0?5VY*xK{?Unkzw z>vKD8+qxkO0J(Agx3^Q3*5PwmmtdiX2LH#etK#icOj%J;AgL$qrcNCZth~C)By8s zhutdKR8_PbU|>2@EPIz?DY%U=0MXsHuT73sV1I4C|2c%ZaS_0WAqYL22yt;kGX=KPTXItH&U~6 zihyy?te~s&D%Bz%DfHAuDz5+W#!Y`JT$9|0(V0m~m931EJAAg5_PRza1%A7C-GU;2 zrKpc#sxu_|Kw)93YY_h6e->PH<&wh3#zcr5UM1lZ$5oAVY*_|h#wq-=EQ2dyQFGo$ z`iCX*jAb#jV<@_F-O518ziXXpeJBLPpitHUU1RK~Bks+vLf%K9pE`sntb~+Eh5%={ zepuY1kebiF z{Tq%&~;S>X^Glf0T^h7x`5rkLeVs#0?P8sj((u;!#7;K_-^+YH%p zim*<0xPyQ~?Vh=JQf2n0ul-G}UoP|%f+`7-6Dc~i*=n!wD(x%v6x9~RFbWmORF0Cs zLd@R5F9^Ab!;LyZJsk)}SWn*nhka3!K<`m({S*@;wf7kZpr_MJ6LiAnT&0gU74ri# z5s}^TWYIYnw&+wi>kxJPSEsM2nlHE1Mauv>iV@2=%K4ZS3cA|PHH!vhH>y<3Qaa0J7?#DO8ap3;Y=-H3Vm${#>W{Mkd ztxqTzjYaib9K`oiF>4B-YDScz?H9C^qD!nd4U`Y}P_fQUqSrHBR5t`|) zuoL1nbOXLRt)-Qg2iE3j1zmC1GO+O>Z4~6A32Z^VFhQ+bO*zCX#?Ml@PLkBgD>dA} z5(lHg0pYW7c_^RnnhApB3m3DALZh&E*TWHk3^@zZ*!+pQqlyL=Gy^j^XgZcH?bcEb ze0VRdu#~(?Mj3({0*(m4Hfyv_Z*Lr&ZXP;~w?xBEO}BPj(w=}Zek;DpAX4cASYPqn zW`a$kw2DEjCZkmUkqcB?JEmx0?AaH+Zs2F|zsn;duv|R_$l^(Wr6cQiYPelfr6yIC zRHSVt3&Th%h&O+dhh#1R2ZbUc^c9p6l&W#|EJVzbl}petFLX@z>31aB^z$@D`ZWR= zyVoD(aJ>am{N)=0sZZ~5AeITYYu|_wN4%Sr8=5I8cNYOvDo3nAOYCBDxDu{P*NFp0 zuApy_;9ai%ngryi?&yMN9l(dM$IzvPMtonQ(C%}M1Nbnn+P;RJ%dRagD&qd>6HQ|P z%a+NZLA+UbxUBkyR4gW9n$p<;`4>^~9F%aJborAoHGX0@c5HKjh?(x>eQRbTa2Ket z^sv`-S*28C5|7ti^f1ILFD+iYIGLgy`lr5$ZZMHUj*Q&62t%Cmm)Syj(;Tloep)ev z-0z3qH4psERe`G#@kI$aM%3QpqNmGgu?$xrF5RlLBzs&L#}t9Hp546{lL~;s2kQy~ z)Du9oqD?ZoMisYinulv08DD#`i^e8lx>Q{`$|FVR%4Xt{z%Um`HQMpWhFl6dWq~Xh z1yWgPIP6VUe>79L8P?@6A(<0uzNiT!5ah&Dz1xt3)9tdsumk0=up@-%C?U45{5R4N z^GZARgb#ayS{|L(m;1^}B1j5!KW?|r!kCa@UP6uyoABzm?w$o?=nxV*!_vpExd&Ja ztw)zEd&CUK&td*B1a*6{42Q|TgfHF67UA#%9g=OI&>zNUARD{woB`3Cfkzex|1)xru)j6HCZ;cJZATC>xD5dwGY6c%q zBrf7yZL?v=fF1Q)oZVWMzCzZo*Tak1x3Moda&dQxq5a#EZDr zsoMtb#PC)O_)9l8{IhH&xgZ{l&D=c%*$x?mv*Vz+$ zJBv|XFe^*Yqkf-FCXNFN^QG`@Vgk`uSU@R7ZfFo|7f*0$KUT(B!MiBEMjVevv#mF2 z$>*uwt*mT-Cz&EL$Vok>SI>YtFBU{JWhW)SiV|VDrB6oedBSu>pCb4{xDWK^+Q)f- z$hLKKC&o%bL%3C$zhq((`m(qOLW{9RZ4wLO?p3|XtSO|=^72Y=jAtzZ#_>W+l1AbU z8}Y0#R2%8-cImC7SJolrdcOq)_ydleRh6+X(oh0pH(!|Dh!2e}^h*WV=qB#rU7 z4iFJf6XZN~C*&Dk@^!wxT+iLg8WM_jig)*YmhCC(IA&n-NJ|=0RHmZU*=VDy)joNj zs~LJ)Q;*A+91np?H@Um9r<@NAxM`Y5@)w;&C_+ zcS%*Aa&R%DAz#~Hs+GC5eQSs?$fYKmN(!MY1NN5uvXD#eI4jR*m55O_jAY(un5^vs zhw_1heB`1ew#cQpt;Pi`q1UY_TZ1XqkQh~1KErO!7>=)Vcz@tC*_0wE6}iLORti%B zO)lYTRqd1xC$?IeE`*!ARk4hBNryifQr>B-c>f-(Iz|pc7p3Rg8IqlwP})_zpS5z; zt8cG(f7QG1z4JPhwz2!ZC45K{z-;c{6UPq=}sRGEgEbT8*B2C+ndA)X4hKp#bN z#EV;Ic;GtaU;q+S8MBXxNc-|<#35;U6!W{D6w|Ve_-nHC9}vdgm1f$Gx+5sprSq~b zPt=2bUS`D*m%QFZMn_`A6`g`PX{!?3vrOvuU@F^ZG#!F&|{i5?eMcGihW5Y0!MzgR{>E{q>%@H|&;VPjL z|Qjp z5_tkID;9AG1g3zFp`50BoYPHZUQ+q-^iIWgXN4$;nOqqdNT{78(@63-bbt^Q`pY7c z#lkdb+!&TKdx-+$dz3u0>!gjw+70klLQHVDv{V;p%Z~ug+_~8PY==T($UZ*xfI#y0 zO&&5tkU1y3&WrVd3#sA}3vQ?-Ad8(gsQ8kJJgVHn)z-mpTh|WL($tdC_({h7z#WFN zWlWIFqcx9_FsnB(po|bD!#sMaR+36H$>#!Su2@L$6ltH$FK%k9S-9|S?HADTIJoQJ z{^qz0Vve_Q?xQBSdsaj50zv^mNHXr7htKZQr~!J1T>K!NDx3)SA_B@^}LSx}(<5 zl=BC!r-k%}ud@`Pfs&9@99_!Xh*%!mTie@7cC`8XraqQqYRIz$0bqJ!fgLlX&HAeh?-q3{)`_I!m|YJWWyW_36HGEQW40F^wQ=V2KU9o3l}Yh`%E!u;&mP_PfV zhTBE$XK7?Po=O1-@~k=TKuXS4oi$})@vubkF_{3#y08>odQjpeu9~$oCCV=NSNrXY zm4jPgWw1!zCzA#{epr!G%BnuFAk`I=bfVXc2bF4|jC4p5X;3NWky$xlUzH?aMP7R8 zDsYf{GLv4sZ!rX@;1@K-ckZN(!)`Wvit6_=q?IP|Qsws)-oFYBL_&G7=uLd)1jH=Q zXi&Vp?X96T!>fn4{jWuU4B8vYl$eBH1W1!+4YF9Y+%d78j*Dy}G>QKbLLaqZXOHr5 z>kXtRuk_9_yCKjJUsD4E7PY zmV>n&+b}{r;wGmZ&Upv{@{?Rm@j3#Ee>tWEEF`t4eI$Xul1F51RP;uw7(@*aSTO;Z zIsCBKULI|`R_#SqjSv z8WZjfQxqG9;%Z+&2b}%lY^3bj6F_2A^=l(-K zf`?H~0Hb8-v2bwxUo5b04e|BqX;|W;?^BqM?{)D`r1L zXtUH*89XRI9Lwc4b>6qu@iYGq3=Y_?K`zQqJAJP>i$fq1T zTSC(d6fDIjX1Jxo_jWzubPTYiF9o&$mMzC&e<;ENqxp37cA)ROPyb zjB@NaAtV$cMEK;A8`YjY~$dT0ZMETIq=Bk zcZWTHwE5!~mQt^P&Z%bJQ?4eu%)1($YdDW!y#f192xK0+7o=;p^7P*N)mt~N{b(~) z47H0tuPq13y`BJ{d3rqN2=WU3o)1f%2Rl^vbnQ^I{FB~5?2YZr3+vrZ!X$87S(U51 z#^{0aV^%n)Yo6{2aHy_0cTqg~){zlKPS1V_4KL-UI z;*FRsgRy({?!I&atL|e(gBVbRd`O&~82S7bV_c>xi0K{()6oH*bq>l8lF0z;{vVv< z6EY(I%Hd0rp~n|`k?zU2se*o6R)4&H>o$lbX`4e^dT{Rvc%&Zl1GX}Os1(KgHACg& zn)RF39Ub_>nw^2^F)=kbu^2)pi3&hGoPdVs}3JaX%& z*cz>ScK0MGmov-*Xn@=o=hl1tPrD)?`m>>D^vM%EVfAI(y!d4uSO$tDfPyK2vV(e0 zapbNxg!J}=C6wdlB~(`+w{o9f#t8u^Z|kx1S2_*2Z|?S_rED79GQ8~(7&x+a=wr%{ z&3l}4snKH=SRH7f>yM{gX0?yH%mrM>QPzuib65JLOVJst=VCl&i*fBc9iMhzx1mGCv8DSfJo^l6e+qrnsNi8lZ z>$5Y2&LGdYiB89-+)1ayBTnQ`+4os)Cy)H3LnwPb;~vU>nrJS7=T&x|{SL-3&$=?{ zS$X?UAbc_Y{5$wF8t}054u_wN>yNp78c0?C1hE1A!Dx}rI2?y5J^u--oZG4PIMcv} z)mx}x@Ta~tltJAxuwm=^EmlCi&$LomR(diJKkUTu{@dz5|9K5b7-D`-j(OU(c6TV( z`S|HJeK7bj(lA-PPkC--+ozl$=(3U(HVoo7!=E>dw(*p6&DX8=IFn9HCg=?gk8ISY zo)LkoU7vD|ya^l3-_*|_QPdV@Se3QWkc zr#86TcAb34r0GQ2JBGq`U;hK*@XC*dKBy+|Q?j*Rm2hB+sRrkVt~E?#(CXnWgX^d` zC6P)itkqY9jMQ0UR;%LcEThp(eu+~11{LBF14fV)H(P2`mCNj?%;7Qe2Zw{Yx3opE zY(=%y1u*~s!0`-uNc#?*{z~*s)%(HSQ=BaoS)+=y48avkaawX&N5?i`*@m$)AKvRC z1)UwK905#5aEVQG-v@{FWyk8G;sz>#`|G~9S8p3wy!54)U;1@v#z@mSw2q)VrqhC4 z7yjsvQPWjLlK-k1pHDL`e(6`g>Y6dC4|Imi$5MJhHoHDS;BaX-r-&eC@po1(U#S%; zhGW#o<#ZMKJ@5om_-{puYL3(vg%PDM%2X3SR*VsyAt(W^;Zg`t1TGW6Lx4TD_guG1 z7IUZTr8sN?;1?EzRoKyCZzGWgyfQXtE(W*%L5qur>%CmQFUy7%xRycub%Pt%4h<6G z4K|Sn<~1qq!gU)A}tRp}%7)+&H3_monw)6?GolubbMlFpPJlH#gjASbp4kK>se6JO7s zP=J#5K2%jRWDwD$rS>diF zWY!z)iXw^t<-iUIyn>q9oId^C-<6+#w`rIckT#Zozso1lyNIMCcB_45vG+AGhNn&` zxdC|`<$F?v0?$_suclhDg8fVUU@v^tx3uj*rb941{u4zR*8X9oJlF<;##^$u z|KU%}g zvQahR6x)n0*%KUPxhtZqCrScGeR2Pi{$JO5inv~1(*HvLQfjr->s0Zk0JFcPG)?~t z{&w-w#eIvP?_2zGv3T(-&p-dl;^&L^R)LZ9m{VyXzFq##>uRYSSM*DVO=NMB$Q1Hf z6C}HONGMBHLM(>ZaqsvHvyD03h-z+~oTdnar49$hz(f+EBxHB*Sq1F@Fvr^wqY`gC zr@C7?N}*h*_)Fqh#6rZLR7PEA)Uliuzxjva`IoqWi+g@x>q}qkU);Z#=3(IBizWS3 z7_13RQXz+uo>utnT$L8$L8onY8WRj)wn*4j=c|#en>WK@QcDBBL#^|1h`wl)g>E9uNoy5%<~d@38H#|La$AdZ_#Mfced`uGJKmSB zw8?-T!8g34I8v?E)#?LtLLe(Ez@|rTL=)VR+@?|wU@?xo@^l%I^%}8ofY+;Y_Lq|k zn68W#>{Zgdh{B$&!S{38Oe`egC{^Xb(Uc{=F#kMt3+lszE2ESbUf6Z3sLJ7Ev0pf9 zto1vuizgaB9E^AXDmrDQpjeQeJX*P#`aho*E@-!~R>44yDzMZbiQxg4J8mlgOQjxQiNc)9mQES{Txa7N}Ky;I)b-?lKj%b%P^o zhle(cf%4g}LHPJ<_{q26?2dn9ueBth>R-F1Yf(EXMPm66Jgjox*W{J0g$1RSlJ`dj z*MHC#5;5;Tf+c?Da^3Li54Q9T4Q~0M@86)J@pN@Oa{2M#wgBW`*&X!|vk1$4>OuZ( z)5gJ($|5!o4}C(2O5d|Aq&mi*7;FRw3vTBj9##Hx1TA+~Bkx~_6g}GbSAD}QdjBH! zwR(M@Pp&VMmRc|4p7RAkp$DV-E)m^|_sx~G*dZ0Z){WHC)6cbd9H!PW>eX7`PSrMU z-SB>n7#o?Vcx4UmX$|t2Lfyy~vQ(Y(fW%uX2)w`j;0XCIuD0Sn5DkK)o&PQj7ZcNx zt02&qNK;i?6co0k%K8+m;JW3|v>w))mD!S~GC6FgRA9|lExcGJXAK?E+KMECiKYJ> zxHvO)SufRuprNdnT|cz0ZrAWE-&^k7ipN)wTq~5?Q2SNY@=HQb2S0fSCmx)+*Vt5?)L! zyDH8|K8*qr!A||zvsUkxAyVyLIV|p!WI9eh!7Ea|d|DhXePxx4Gy&($C!`R#45iT5 zV%wY+iZ~CVsES&pfvVQzCpMB9F5i?mhHZ&y1a<**nflT{e_vptL`nYp!f8QQ@kAHMCLQm~4*S zDi&-R;`Pcc)GuCG3-PZ8y3`aX760Mox?N(`^?E1(T{+#=r$y644;_=1!L9vgF4^(9 N)k1Hqb$MZG{~!C^hm-&S diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po index cc8332b72..4a101980f 100644 --- a/locales/zh_Hans/LC_MESSAGES/messages.po +++ b/locales/zh_Hans/LC_MESSAGES/messages.po @@ -11,8 +11,8 @@ msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-09-01 20:29+0000\n" -"Last-Translator: xlivevil \n" +"PO-Revision-Date: 2021-09-05 14:34+0000\n" +"Last-Translator: meowmeowmeowcat \n" "Language-Team: Chinese (Simplified) \n" "Language: zh_Hans\n" @@ -117,8 +117,8 @@ msgid "" "specific topic without a specific goal in mind. :doc:`example discussion-" "style document `." msgstr "" -"讨论 (Discussions) 的重点是理解和信息。这些探索一个特定的主题，没有具体的目" -"标。 :doc:`示例讨论式文件 `。" +"讨论 (Discussions) 的重点是理解和信息。这些探索一个特定的主题，没有具体的目标。 :doc:`示例讨论式文件 `。" #: ../source/contribute.rst:63 msgid "Specifications" @@ -161,8 +161,8 @@ msgid "" "the `Hitchhiker's Guide to Python installation instructions`_ to install " "Python 3.6 on your operating system." msgstr "" -"Python 3.6。我们的构建脚本只为 Python 3.6 而设计。请参阅 `Hitchhiker's Guide " -"to Python installation instructions`_ 以在你的操作系统上安装Python 3.6。" +"Python 3.6。我们的构建脚本只为 Python 3.6 而设计。请参阅 `Hitchhiker's Guide to Python " +"installation instructions`_ 以在你您的操作系统上安装Python 3.6。" #: ../source/contribute.rst:91 msgid "" @@ -4105,12 +4105,14 @@ msgid "" "venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the " "below commands." msgstr "" +"要创建一个虚拟环境，进入您的项目目录并运行 venv 。如果您正在使用 Python2，在下面的命令中把 ``venv`` 改为 " +"``virtualenv`` 。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 msgid "" "The second argument is the location to create the virtual environment. " "Generally, you can just create this in your project and call it ``env``." -msgstr "" +msgstr "第二个参数是创建虚拟环境的位置。一般来说，您可以直接在您的项目中创建它，并称之为 ``env`` 。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 msgid "venv will create a virtual Python installation in the ``env`` folder." @@ -4133,19 +4135,21 @@ msgid "" "will put the virtual environment-specific ``python`` and ``pip`` executables " "into your shell's ``PATH``." msgstr "" +"在您开始安装或使用虚拟环境中的软件包之前，你需要 *激活* 它。激活虚拟环境将把虚拟环境专用的 ``python`` 和 ``pip`` " +"可执行文件放入你的 shell 的 ``PATH`` 。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 msgid "" "You can confirm you're in the virtual environment by checking the location " "of your Python interpreter, it should point to the ``env`` directory." -msgstr "" +msgstr "您可以通过检查您的 Python 解释器的位置来确认您在虚拟环境中，它应该指向 ``env`` 目录。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 msgid "" "As long as your virtual environment is activated pip will install packages " "into that specific environment and you'll be able to import and use packages " "in your Python application." -msgstr "" +msgstr "只要您的虚拟环境被激活，pip 就会将软件包安装到该特定环境中，您就可以在您的 Python 应用程序中导入和使用软件包。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 msgid "Leaving the virtual environment" @@ -4155,7 +4159,7 @@ msgstr "离开虚拟环境" msgid "" "If you want to switch projects or otherwise leave your virtual environment, " "simply run:" -msgstr "" +msgstr "如果您想切换项目或以其他方式离开你的虚拟环境，只需运行：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 msgid "" @@ -4173,15 +4177,17 @@ msgid "" "Now that you're in your virtual environment you can install packages. Let's " "install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" msgstr "" +"现在您在您的虚拟环境中，您可以安装软件包。让我们从 :term:`Python Package Index (PyPI)` 中安装 `Requests`" +"_ 库：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 msgid "" "pip should download requests and all of its dependencies and install them:" -msgstr "" +msgstr "pip应该下载 request 及其所有的依赖项并安装它们：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 msgid "Installing specific versions" -msgstr "" +msgstr "安装特定版本" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 msgid "" @@ -4189,32 +4195,34 @@ msgid "" "`version specifiers `. For example, to install a specific " "version of ``requests``:" msgstr "" +"pip 允许您使用 :term:`版本指定器 `来指定安装哪个版本的软件包。例如，要安装一个特定版本的 " +"``requests``：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 msgid "To install the latest ``2.x`` release of requests:" -msgstr "" +msgstr "要安装最新的 ``2.x`` 版本的 requests：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 msgid "To install pre-release versions of packages, use the ``--pre`` flag:" -msgstr "" +msgstr "要安装预发布（pre-release）版本的软件包，请使用 ``--pre`` 标志：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 msgid "Installing extras" -msgstr "" +msgstr "安装附加功能" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 msgid "" "Some packages have optional `extras`_. You can tell pip to install these by " "specifying the extra in brackets:" -msgstr "" +msgstr "有些软件包有可选的 `额外功能 `_ 。你可以通过在括号中指定额外的东西来告诉 pip 安装这些东西：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 msgid "Installing from source" -msgstr "" +msgstr "从源文件安装" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 msgid "pip can install a package directly from source, for example:" -msgstr "" +msgstr "pip 可以直接从源代码安装一个软件包，例如：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 msgid "" @@ -4222,22 +4230,24 @@ msgid "" "meaning that changes to the source directory will immediately affect the " "installed package without needing to re-install:" msgstr "" +"此外，pip 可以在 `开发模式 `_ " +"下从源码安装软件包，这意味着源码目录的变化将立即影响已安装的软件包，而不需要重新安装：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 msgid "Installing from version control systems" -msgstr "" +msgstr "从版本控制系统进行安装" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 msgid "" "pip can install packages directly from their version control system. For " "example, you can install directly from a git repository:" -msgstr "" +msgstr "pip 可以直接从他们的版本控制系统中安装软件包。例如，你可以直接从 git 仓库中安装：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 msgid "" "For more information on supported version control systems and syntax, see " "pip's documentation on :ref:`VCS Support `." -msgstr "" +msgstr "关于支持的版本控制系统和语法的更多信息，请参见 pip 的文档：:ref:`VCS Support ` 。" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 #: ../source/tutorials/installing-packages.rst:569 @@ -4266,13 +4276,14 @@ msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 msgid "Using other package indexes" -msgstr "" +msgstr "使用其他软件包的索引" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 msgid "" "If you want to download packages from a different index than the :term:" "`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" msgstr "" +"如果您想从不同的索引下载软件包，而不是 :term:`Python 软件包索引（PyPI）` ，您可以使用 ``--index-url`` 标志：" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 msgid "" diff --git a/locales/zh_Hant/LC_MESSAGES/messages.mo b/locales/zh_Hant/LC_MESSAGES/messages.mo deleted file mode 100644 index b16da9fb29741db5a3a8adcb7a71b019008a0905..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6020 zcmeH~TWlOx8OIM$Xfd>fmfk3(r<7ijde*zPlh~U}bFq_H*ohlEv;l#4ynDQ!WOrse zGn>t#KG;bUJ9S*sHnFMW=6-RT`jVt=5<78)K}Z-FFdDLy_1nqUL?LlC0b zO`rAky%YR4p3A`p!9MUd@Ek~Te+rVGzXoaDJ0RKZf;8{%AlZEzj3h1qSAfew(&s6V z{PiY?sqAOq8?gT^kmBEevoHUU(Yf0F#0 zxD@;|xDE`#n6+RQr1futa1r|nsDf{U4}!I~`*ue_ivM!QjIS1-lB#;jzRf_@V@V&9IL<}9|ka%VUYjlU*zX|F&@EKAU}{VS7KDjXNnPB zC?C)N6brf(jC(Msy;7fG3l|F2%C>2`WvhwA!i9K|(o$e(Nma0_wg#-mRmDQJp~ba} zD#1mImsE#XWiV8&ghKd7w@Z{@jS?)~*3RCBf^)Z_x!X#4OKbew>Lpd7AgipZu3lVQ z$ttU>s;VnPi&*92P;D?+vxtRF(GiY7wFp~fbGuWsc*@Xpn`<3BYovKb#l3BCQ>ZbX zG)%z_ou}03HZ`v4ao(J@JMki+wVSG`35$0MOi?i`BPmFp9=AL}QB~(LBg|H%W17&T zf~`(#i5SVSI|YxYwV2=uBMN6_+3GBh8oF(2?P=SaVR)0CYR)!qUiVZv$$JP}h#e^r zwMC5d>o5`tBjZhLZdv<~#UpDBNHjY58bgnzqjsdNEx^_o$rSXopfc73L_CgHx-E3u z@@~8xp*HOYPk36fI?alvElV?Wi`5y?bQ0558;{)1ri8`Tk?t02@Iy_?nbJdocbG=f zQwsh|z+24?JZ+Ilkx0sOT@_c79PZ~bQ}{P&z2bXVd@B+OutwFg`6jVl6B!X>jT)Y| ziEPF&V-`fKHplK!XfEW|rm+=n39u#uGvNU8FJ^C}$kDxYBe&IU2v{niM!lfYr%1|Q z4F9du?Dgq(#64wLnr)a_av*OtcwE>VNo~UM)It16H|!WOQbOmNWu=9M zWn9%`5S>mWAnr-Lv*~SsH+U&Vk%SVuE+d^WH5&?Lx@;A>Kd~s)995hGV|(?(x1M0=__`?g*1mej(T7%QK-pU zP>@=O7WJ&OSj${&SSvPFW$pV}St>9j3KYp2I?}Y$Kz$%9r5ikl%UZAko(x}cEJ+I4 znpEA&2$Oq>MGp0>vW&!bB2Jb#mn zhKxm7wVOu9QXzZVVC>+_$SezX>Bf!#HG6D|)UpDaQ6cn- z1l(rX6)Per+b#H6pl)7DS(Iuz6*pD1TP&XIZ}?4#VDm_`A#5`{w?oP+JSFA54j5*f z#Ii`FuA!xMb8ACmOWWp_`nHz3uSFtw+pu9xM#ZmWs9uMC!+cBqs!dAMMx|~QU%xTj)bPkRHg2ddqhB5ca&-&w zH_R|!yScHEZ&=k-&zIFVt!ijoxvH*iQ+-Rz3QX1GX*DjCR-q>UnO3t&Ms*`%0l1A4 z%gX_2D0&z)pV!D_wosaUr?YK6YQAD_w=kFQ%9gSw-IF`vDcBK_R(qV3+6IS47 zM$?z#M@u!4ILkM;u2pL0=8>Hp!c^+@sNq#0uW8rpvgQPuMnYL@m`N+l^_2H$Ee|cl z4-$P@9$Z@XgtAWP)TPNukNZ~f>OhSW6Wh!F7tez3*a`Q=o$p=V=bYN<9vX3Xj=HZB!xsui z_u(dYvCn;>KX+y1z01R_aJnl$GQ*saQFr83XJpbn-RDeCx%+yY{vqaXo4axZ`{c)m z@;j$yk1bg4^h_1b9n1GmV;9VECeOM(dkZh0D|Wx`jQ4UJ06Em*5$uYUc;)Qv!HMJd zT{~H!x5qp8(FAv5f8p{j=Iq(+j9+4y2}S(D%*}|DY<_`Acrr#(YJ>(qf zV^YoBm8<#vqaXb+$H^Nrhw>wb-Ld1)fDVMt_};?tm*6ZsJ12**2kDu+_>BANQD@?1 z_sB)&^bSECcVM7!b<&?$JhD4~a2zWTiemrk&e#wwa!#Bs?izJ^_fUWaFVDJ+BwsiQ z#}#*7albbKm-EQ1gwjdR>Dr4h@@29RKkNv&BEpMZ=g6zWPh-ErsqW%npM$u0!V!$Z znLhXM$^1y)HAg__`F+M&_DvV7!2M^`P_B#g#ibwZhPT}-%_w1Da_&$lwWDh!zFY&|AYo$Ey8YrB) zLTgJ$H+Sr4;p(%#8wy>!-@DvRE|}>>V{->Dx#th~EloP`(i!KOmywh(%uRUE z=QlDxVX5HcnXGWW#~pmpIWd#FI9BZLo9&DKInH_RN^bfD4o&WX7oD+-47pE5FgPiL w@b4YfU>6e0S9q>d(Xou@X7v(&_vBw2rnB4sPiy!e>$Qiy|M0Z-4;6Rl{{R30 diff --git a/source/conf.py b/source/conf.py index 9dd611c4b..6062b0fdd 100644 --- a/source/conf.py +++ b/source/conf.py @@ -91,9 +91,13 @@ locale_dirs = ['../locales'] +gettext_auto_build = True # Build MO files from PO on each build + # making all documents use single text domain gettext_compact = "messages" +gettext_location = True # Include location info in the translation files + # There are two options for replacing |today|: either, you set today to some # non-false value, then it is used: # From a5a1ef892741add32fe7278fd2abb97b2655f064 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 18 Sep 2021 13:04:18 +0800 Subject: [PATCH 0150/1072] Revert "Update messages.pot as of version 0ef3d3f" This reverts commit 7260424415ebcdac27886773d97387ed198e474c. --- locales/messages.pot | 318 +++++++++++++++++++++---------------------- 1 file changed, 159 insertions(+), 159 deletions(-) diff --git a/locales/messages.pot b/locales/messages.pot index 35aa4171a..4eac54e62 100644 --- a/locales/messages.pot +++ b/locales/messages.pot @@ -8,7 +8,7 @@ msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide \n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-08-27 12:18+0000\n" +"POT-Creation-Date: 2021-08-26 13:33+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" @@ -526,7 +526,7 @@ msgid "Lastly, it's important to understand that ``install_requires`` is a listi msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:64 -#: ../source/tutorials/installing-packages.rst:469 +#: ../source/tutorials/installing-packages.rst:468 msgid "Requirements files" msgstr "" @@ -681,7 +681,7 @@ msgid "Yes, via setup.cfg" msgstr "" #: ../source/discussions/pip-vs-easy-install.rst:68 -msgid "https://setuptools.readthedocs.io/en/latest/deprecated/easy_install.html#natural-script-launcher" +msgid "https://setuptools.readthedocs.io/en/latest/easy_install.html#natural-script-launcher" msgstr "" #: ../source/discussions/wheel-vs-egg.rst:5 @@ -773,224 +773,224 @@ msgid "Egg" msgstr "" #: ../source/glossary.rst:44 -msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see ` :doc:`The Internal Structure of Python Eggs ` and `Python Eggs `_" +msgid "A :term:`Built Distribution` format introduced by :ref:`setuptools`, which is being replaced by :term:`Wheel`. For details, see `The Internal Structure of Python Eggs `_ and `Python Eggs `_" msgstr "" -#: ../source/glossary.rst:48 +#: ../source/glossary.rst:49 msgid "Extension Module" msgstr "" -#: ../source/glossary.rst:51 +#: ../source/glossary.rst:52 msgid "A :term:`Module` written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions." msgstr "" -#: ../source/glossary.rst:58 +#: ../source/glossary.rst:59 msgid "Known Good Set (KGS)" msgstr "" -#: ../source/glossary.rst:61 +#: ../source/glossary.rst:62 msgid "A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions." msgstr "" -#: ../source/glossary.rst:67 +#: ../source/glossary.rst:68 msgid "Import Package" msgstr "" -#: ../source/glossary.rst:70 +#: ../source/glossary.rst:71 msgid "A Python module which can contain other modules or recursively, other packages." msgstr "" -#: ../source/glossary.rst:73 +#: ../source/glossary.rst:74 msgid "An import package is more commonly referred to with the single word \"package\", but this guide will use the expanded term when more clarity is needed to prevent confusion with a :term:`Distribution Package` which is also commonly called a \"package\"." msgstr "" -#: ../source/glossary.rst:77 +#: ../source/glossary.rst:78 msgid "Module" msgstr "" -#: ../source/glossary.rst:80 +#: ../source/glossary.rst:81 msgid "The basic unit of code reusability in Python, existing in one of two types: :term:`Pure Module`, or :term:`Extension Module`." msgstr "" -#: ../source/glossary.rst:83 +#: ../source/glossary.rst:84 msgid "Package Index" msgstr "" -#: ../source/glossary.rst:86 +#: ../source/glossary.rst:87 msgid "A repository of distributions with a web interface to automate :term:`package ` discovery and consumption." msgstr "" -#: ../source/glossary.rst:89 +#: ../source/glossary.rst:90 msgid "Per Project Index" msgstr "" -#: ../source/glossary.rst:92 +#: ../source/glossary.rst:93 msgid "A private or other non-canonical :term:`Package Index` indicated by a specific :term:`Project` as the index preferred or required to resolve dependencies of that project." msgstr "" -#: ../source/glossary.rst:96 +#: ../source/glossary.rst:97 msgid "Project" msgstr "" -#: ../source/glossary.rst:99 +#: ../source/glossary.rst:100 msgid "A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a :term:`Distribution `." msgstr "" -#: ../source/glossary.rst:103 +#: ../source/glossary.rst:104 msgid "Since most projects create :term:`Distributions ` using either :pep:`518` ``build-system``, :ref:`distutils` or :ref:`setuptools`, another practical way to define projects currently is something that contains a :term:`pyproject.toml`, :term:`setup.py`, or :term:`setup.cfg` file at the root of the project source directory." msgstr "" -#: ../source/glossary.rst:109 +#: ../source/glossary.rst:110 msgid "Python projects must have unique names, which are registered on :term:`PyPI `. Each project will then contain one or more :term:`Releases `, and each release may comprise one or more :term:`distributions `." msgstr "" -#: ../source/glossary.rst:114 +#: ../source/glossary.rst:115 msgid "Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn't have to hold true. It's possible to install a distribution from the project 'foo' and have it provide a package importable only as 'bar'." msgstr "" -#: ../source/glossary.rst:120 +#: ../source/glossary.rst:121 msgid "Pure Module" msgstr "" -#: ../source/glossary.rst:123 +#: ../source/glossary.rst:124 msgid "A :term:`Module` written in Python and contained in a single ``.py`` file (and possibly associated ``.pyc`` and/or ``.pyo`` files)." msgstr "" -#: ../source/glossary.rst:126 +#: ../source/glossary.rst:127 msgid "Python Packaging Authority (PyPA)" msgstr "" -#: ../source/glossary.rst:129 +#: ../source/glossary.rst:130 msgid "PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at https://www.pypa.io, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list `_ and `the Python Discourse forum `__." msgstr "" -#: ../source/glossary.rst:138 +#: ../source/glossary.rst:139 msgid "Python Package Index (PyPI)" msgstr "" -#: ../source/glossary.rst:141 +#: ../source/glossary.rst:142 msgid "`PyPI `_ is the default :term:`Package Index` for the Python community. It is open to all Python developers to consume and distribute their distributions." msgstr "" -#: ../source/glossary.rst:144 +#: ../source/glossary.rst:145 msgid "pypi.org" msgstr "" -#: ../source/glossary.rst:147 +#: ../source/glossary.rst:148 msgid "`pypi.org `_ is the domain name for the :term:`Python Package Index (PyPI)`. It replaced the legacy index domain name, ``pypi.python.org``, in 2017. It is powered by :ref:`warehouse`." msgstr "" -#: ../source/glossary.rst:151 +#: ../source/glossary.rst:152 msgid "pyproject.toml" msgstr "" -#: ../source/glossary.rst:154 +#: ../source/glossary.rst:155 msgid "The tool-agnostic :term:`Project` specification file. Defined in :pep:`518`." msgstr "" -#: ../source/glossary.rst:156 +#: ../source/glossary.rst:157 msgid "Release" msgstr "" -#: ../source/glossary.rst:159 +#: ../source/glossary.rst:160 msgid "A snapshot of a :term:`Project` at a particular point in time, denoted by a version identifier." msgstr "" -#: ../source/glossary.rst:162 +#: ../source/glossary.rst:163 msgid "Making a release may entail the publishing of multiple :term:`Distributions `. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format." msgstr "" -#: ../source/glossary.rst:167 +#: ../source/glossary.rst:168 msgid "Requirement" msgstr "" -#: ../source/glossary.rst:170 +#: ../source/glossary.rst:171 msgid "A specification for a :term:`package ` to be installed. :ref:`pip`, the :term:`PYPA ` recommended installer, allows various forms of specification that can all be considered a \"requirement\". For more information, see the :ref:`pip:pip install` reference." msgstr "" -#: ../source/glossary.rst:176 +#: ../source/glossary.rst:177 msgid "Requirement Specifier" msgstr "" -#: ../source/glossary.rst:179 +#: ../source/glossary.rst:180 msgid "A format used by :ref:`pip` to install packages from a :term:`Package Index`. For an EBNF diagram of the format, see the `pkg_resources.Requirement `_ entry in the :ref:`setuptools` docs. For example, \"foo>=1.3\" is a requirement specifier, where \"foo\" is the project name, and the \">=1.3\" portion is the :term:`Version Specifier`" msgstr "" -#: ../source/glossary.rst:186 +#: ../source/glossary.rst:187 msgid "Requirements File" msgstr "" -#: ../source/glossary.rst:189 +#: ../source/glossary.rst:190 msgid "A file containing a list of :term:`Requirements ` that can be installed using :ref:`pip`. For more information, see the :ref:`pip` docs on :ref:`pip:Requirements Files`." msgstr "" -#: ../source/glossary.rst:193 +#: ../source/glossary.rst:194 #: ../source/guides/distributing-packages-using-setuptools.rst:56 msgid "setup.py" msgstr "" -#: ../source/glossary.rst:194 +#: ../source/glossary.rst:195 #: ../source/guides/distributing-packages-using-setuptools.rst:77 msgid "setup.cfg" msgstr "" -#: ../source/glossary.rst:197 +#: ../source/glossary.rst:198 msgid "The project specification files for :ref:`distutils` and :ref:`setuptools`. See also :term:`pyproject.toml`." msgstr "" -#: ../source/glossary.rst:200 +#: ../source/glossary.rst:201 msgid "Source Archive" msgstr "" -#: ../source/glossary.rst:203 +#: ../source/glossary.rst:204 msgid "An archive containing the raw source code for a :term:`Release`, prior to creation of a :term:`Source Distribution ` or :term:`Built Distribution`." msgstr "" -#: ../source/glossary.rst:207 +#: ../source/glossary.rst:208 msgid "Source Distribution (or \"sdist\")" msgstr "" -#: ../source/glossary.rst:210 +#: ../source/glossary.rst:211 msgid "A :term:`distribution ` format (usually generated using ``python setup.py sdist``) that provides metadata and the essential source files needed for installing by a tool like :ref:`pip`, or for generating a :term:`Built Distribution`." msgstr "" -#: ../source/glossary.rst:215 +#: ../source/glossary.rst:216 msgid "System Package" msgstr "" -#: ../source/glossary.rst:218 +#: ../source/glossary.rst:219 msgid "A package provided in a format native to the operating system, e.g. an rpm or dpkg file." msgstr "" -#: ../source/glossary.rst:221 +#: ../source/glossary.rst:222 msgid "Version Specifier" msgstr "" -#: ../source/glossary.rst:224 +#: ../source/glossary.rst:225 msgid "The version component of a :term:`Requirement Specifier`. For example, the \">=1.3\" portion of \"foo>=1.3\". :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the specifiers that Python packaging currently supports. Support for PEP440 was implemented in :ref:`setuptools` v8.0 and :ref:`pip` v6.0." msgstr "" -#: ../source/glossary.rst:230 +#: ../source/glossary.rst:231 msgid "Virtual Environment" msgstr "" -#: ../source/glossary.rst:233 +#: ../source/glossary.rst:234 msgid "An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on :ref:`Creating and using Virtual Environments`." msgstr "" -#: ../source/glossary.rst:237 +#: ../source/glossary.rst:238 msgid "Wheel" msgstr "" -#: ../source/glossary.rst:240 +#: ../source/glossary.rst:241 msgid "A :term:`Built Distribution` format introduced by :pep:`427`, which is intended to replace the :term:`Egg` format. Wheel is currently supported by :ref:`pip`." msgstr "" -#: ../source/glossary.rst:243 +#: ../source/glossary.rst:244 msgid "Working Set" msgstr "" -#: ../source/glossary.rst:246 +#: ../source/glossary.rst:247 msgid "A collection of :term:`distributions ` available for importing. These are the distributions that are on the `sys.path` variable. At most, one :term:`Distribution ` for a project is possible in a working set." msgstr "" @@ -1831,7 +1831,7 @@ msgid "Use this keyword to specify any plugins that your project provides for an msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:512 -msgid "For more information, see the section on :ref:`Advertising Behavior ` from the :ref:`setuptools` docs." +msgid "For more information, see the section on `Advertising Behavior `_ from the :ref:`setuptools` docs." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:516 @@ -1843,11 +1843,11 @@ msgid "``console_scripts``" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:531 -msgid "Use ``console_script`` :ref:`entry points ` to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgid "Use ``console_script`` `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:538 -msgid "For more information, see `Automatic Script Creation `_ from the :doc:`setuptools docs `." +msgid "For more information, see `Automatic Script Creation `_ from the `setuptools docs `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:545 @@ -2019,7 +2019,7 @@ msgid "Lastly, if you don't want to install any dependencies at all, you can run msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:709 -msgid "For more information, see the :doc:`` section of the :doc:`setuptools docs `." +msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:716 @@ -2187,7 +2187,7 @@ msgid "You can see if your package has successfully uploaded by navigating to th msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:949 -#: ../source/tutorials/installing-packages.rst:672 +#: ../source/tutorials/installing-packages.rst:671 msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." msgstr "" @@ -2444,30 +2444,30 @@ msgid "pip provides a number of facilities for speeding up installation by using msgstr "" #: ../source/guides/index-mirrors-and-caches.rst:32 -msgid ":ref:`Fast & local installs ` by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." +msgid "`Fast & local installs `_ by downloading all the requirements for a project and then pointing pip at those downloaded files instead of going to PyPI." msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:35 +#: ../source/guides/index-mirrors-and-caches.rst:36 msgid "A variation on the above which pre-builds the installation files for the requirements using :ref:`python -m pip wheel `:" msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:45 +#: ../source/guides/index-mirrors-and-caches.rst:46 msgid "Caching with devpi" msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:47 +#: ../source/guides/index-mirrors-and-caches.rst:48 msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:55 +#: ../source/guides/index-mirrors-and-caches.rst:56 msgid "Complete mirror with bandersnatch" msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:57 +#: ../source/guides/index-mirrors-and-caches.rst:58 msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:63 +#: ../source/guides/index-mirrors-and-caches.rst:64 msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." msgstr "" @@ -2909,84 +2909,84 @@ msgid "pip can install a package directly from source, for example:" msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:326 -msgid "Additionally, pip can install packages from source in :doc:`development mode `, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" +msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:345 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:347 msgid "Installing from version control systems" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:347 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:349 msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:354 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:356 msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:359 -#: ../source/tutorials/installing-packages.rst:578 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 +#: ../source/tutorials/installing-packages.rst:577 msgid "Installing from local archives" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:363 msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:376 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:378 msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:392 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:394 msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:398 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 msgid "Using other package indexes" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:402 msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:415 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:432 -#: ../source/tutorials/installing-packages.rst:398 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:434 +#: ../source/tutorials/installing-packages.rst:397 msgid "Upgrading packages" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:434 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:436 msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:450 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:452 msgid "Using requirements files" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:452 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:454 msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:476 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 msgid "Freezing dependencies" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:480 msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:493 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:495 msgid "Which will output a list of package specifiers such as:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:509 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:511 msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." msgstr "" @@ -3416,7 +3416,7 @@ msgid "Implementing binary extensions" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:224 -msgid "The CPython :doc:`Extending and Embedding ` guide includes an introduction to writing a :doc:`custom extension module in C `." +msgid "The CPython `Extending and Embedding `_ guide includes an introduction to writing a `custom extension module in C `_." msgstr "" #: ../source/guides/packaging-binary-extensions.rst:241 @@ -3584,7 +3584,7 @@ msgid "pkgutil-style namespace packages" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:131 -msgid "Python 2.3 introduced the :doc:`pkgutil ` module and the :py:func:`python:pkgutil.extend_path` function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." +msgid "Python 2.3 introduced the `pkgutil`_ module and the `extend_path`_ function. This can be used to declare namespace packages that need to be compatible with both Python 2.3+ and Python 3. This is the recommended approach for the highest level of compatibility." msgstr "" #: ../source/guides/packaging-namespace-packages.rst:136 @@ -3592,12 +3592,12 @@ msgid "To create a pkgutil-style namespace package, you need to provide an :file msgstr "" #: ../source/guides/packaging-namespace-packages.rst:148 -#: ../source/guides/packaging-namespace-packages.rst:193 +#: ../source/guides/packaging-namespace-packages.rst:194 msgid "The :file:`__init__.py` file for the namespace package needs to contain **only** the following:" msgstr "" #: ../source/guides/packaging-namespace-packages.rst:155 -#: ../source/guides/packaging-namespace-packages.rst:200 +#: ../source/guides/packaging-namespace-packages.rst:201 msgid "**Every** distribution that uses the namespace package must include an identical :file:`__init__.py`. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable. Any additional code in :file:`__init__.py` will be inaccessible." msgstr "" @@ -3605,31 +3605,31 @@ msgstr "" msgid "A complete working example of two pkgutil-style namespace packages can be found in the `pkgutil namespace example project`_." msgstr "" -#: ../source/guides/packaging-namespace-packages.rst:170 +#: ../source/guides/packaging-namespace-packages.rst:171 msgid "pkg_resources-style namespace packages" msgstr "" -#: ../source/guides/packaging-namespace-packages.rst:172 +#: ../source/guides/packaging-namespace-packages.rst:173 msgid "`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. If you are creating a new distribution within an existing namespace package that uses this method then it's recommended to continue using this as the different methods are not cross-compatible and it's not advisable to try to migrate an existing package." msgstr "" -#: ../source/guides/packaging-namespace-packages.rst:181 +#: ../source/guides/packaging-namespace-packages.rst:182 msgid "To create a pkg_resources-style namespace package, you need to provide an :file:`__init__.py` file for the namespace package:" msgstr "" -#: ../source/guides/packaging-namespace-packages.rst:205 +#: ../source/guides/packaging-namespace-packages.rst:206 msgid "Some older recommendations advise the following in the namespace package :file:`__init__.py`:" msgstr "" -#: ../source/guides/packaging-namespace-packages.rst:215 +#: ../source/guides/packaging-namespace-packages.rst:216 msgid "The idea behind this was that in the rare case that setuptools isn't available packages would fall-back to the pkgutil-style packages. This isn't advisable because pkgutil and pkg_resources-style namespace packages are not cross-compatible. If the presence of setuptools is a concern then the package should just explicitly depend on setuptools via ``install_requires``." msgstr "" -#: ../source/guides/packaging-namespace-packages.rst:222 +#: ../source/guides/packaging-namespace-packages.rst:223 msgid "Finally, every distribution must provide the ``namespace_packages`` argument to :func:`~setuptools.setup` in :file:`setup.py`. For example:" msgstr "" -#: ../source/guides/packaging-namespace-packages.rst:236 +#: ../source/guides/packaging-namespace-packages.rst:237 msgid "A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_." msgstr "" @@ -3710,7 +3710,7 @@ msgid "Then, add the following under the ``build-n-publish`` section:" msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:92 -msgid "This will download your repository into the CI runner and then install and activate Python 3.9." +msgid "This will download your repository into the CI runner and then install and activate Python 3.7." msgstr "" #: ../source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst:95 @@ -4166,7 +4166,7 @@ msgid "Use :ref:`pip` to install Python :term:`packages ` msgstr "" #: ../source/guides/tool-recommendations.rst:34 -msgid "Use :ref:`virtualenv`, or :doc:`venv ` to isolate application specific dependencies from a shared Python installation. [4]_" +msgid "Use :ref:`virtualenv`, or `venv`_ to isolate application specific dependencies from a shared Python installation. [4]_" msgstr "" #: ../source/guides/tool-recommendations.rst:37 @@ -5705,7 +5705,7 @@ msgid "So long as your code contains nothing but pure Python code, and you know msgstr "" #: ../source/overview.rst:95 -msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can :doc:`go here to learn more `." +msgid "Python's *sdists* are compressed archives (``.tar.gz`` files) containing one or more packages or modules. If your code is pure-Python, and you only depend on other Python packages, you can `go here to learn more `_." msgstr "" #: ../source/overview.rst:100 @@ -5761,7 +5761,7 @@ msgid "With the variety of operating systems, configurations, and people out the msgstr "" #: ../source/overview.rst:166 -msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like :doc:`setuptools entry_points `." +msgid "Python's native packaging is mostly built for distributing reusable code, called libraries, between developers. You can piggyback **tools**, or basic applications for developers, on top of Python's library packaging, using technologies like `setuptools entry_points `_." msgstr "" #: ../source/overview.rst:172 @@ -5873,7 +5873,7 @@ msgid "`PEX `_ (Python EXecutable)" msgstr "" #: ../source/overview.rst:252 -msgid ":doc:`zipapp ` (does not help manage dependencies, requires Python 3.5+)" +msgid "`zipapp `_ (does not help manage dependencies, requires Python 3.5+)" msgstr "" #: ../source/overview.rst:253 @@ -8527,7 +8527,7 @@ msgid "Optionally, create a virtual environment" msgstr "" #: ../source/tutorials/installing-packages.rst:180 -msgid "See :ref:`section below ` for details, but here's the basic :doc:`venv ` [3]_ command to use on a typical Linux system:" +msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" msgstr "" #: ../source/tutorials/installing-packages.rst:197 @@ -8563,7 +8563,7 @@ msgid "Currently, there are two common tools for creating Python virtual environ msgstr "" #: ../source/tutorials/installing-packages.rst:231 -msgid ":doc:`venv ` is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." +msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." msgstr "" #: ../source/tutorials/installing-packages.rst:234 @@ -8575,7 +8575,7 @@ msgid "The basic usage is like so:" msgstr "" #: ../source/tutorials/installing-packages.rst:241 -msgid "Using :doc:`venv `:" +msgid "Using `venv`_:" msgstr "" #: ../source/tutorials/installing-packages.rst:257 @@ -8583,182 +8583,182 @@ msgid "Using :ref:`virtualenv`:" msgstr "" #: ../source/tutorials/installing-packages.rst:273 -msgid "For more information, see the :doc:`venv ` docs or the `virtualenv `_ docs." +msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." msgstr "" -#: ../source/tutorials/installing-packages.rst:276 +#: ../source/tutorials/installing-packages.rst:275 msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." msgstr "" -#: ../source/tutorials/installing-packages.rst:281 +#: ../source/tutorials/installing-packages.rst:280 msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" msgstr "" -#: ../source/tutorials/installing-packages.rst:291 +#: ../source/tutorials/installing-packages.rst:290 msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." msgstr "" -#: ../source/tutorials/installing-packages.rst:298 +#: ../source/tutorials/installing-packages.rst:297 msgid "Use pip for Installing" msgstr "" -#: ../source/tutorials/installing-packages.rst:300 -msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the :doc:`pip docs `, which includes a complete :doc:`Reference Guide `." +#: ../source/tutorials/installing-packages.rst:299 +msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete :doc:`Reference Guide `." msgstr "" -#: ../source/tutorials/installing-packages.rst:306 +#: ../source/tutorials/installing-packages.rst:305 msgid "Installing from PyPI" msgstr "" -#: ../source/tutorials/installing-packages.rst:308 +#: ../source/tutorials/installing-packages.rst:307 msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." msgstr "" -#: ../source/tutorials/installing-packages.rst:316 +#: ../source/tutorials/installing-packages.rst:315 msgid "To install the latest version of \"SomeProject\":" msgstr "" -#: ../source/tutorials/installing-packages.rst:330 +#: ../source/tutorials/installing-packages.rst:329 msgid "To install a specific version:" msgstr "" -#: ../source/tutorials/installing-packages.rst:344 +#: ../source/tutorials/installing-packages.rst:343 msgid "To install greater than or equal to one version and less than another:" msgstr "" -#: ../source/tutorials/installing-packages.rst:359 +#: ../source/tutorials/installing-packages.rst:358 msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" msgstr "" -#: ../source/tutorials/installing-packages.rst:374 +#: ../source/tutorials/installing-packages.rst:373 msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." msgstr "" -#: ../source/tutorials/installing-packages.rst:379 +#: ../source/tutorials/installing-packages.rst:378 msgid "Source Distributions vs Wheels" msgstr "" -#: ../source/tutorials/installing-packages.rst:381 +#: ../source/tutorials/installing-packages.rst:380 msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." msgstr "" -#: ../source/tutorials/installing-packages.rst:387 +#: ../source/tutorials/installing-packages.rst:386 msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." msgstr "" -#: ../source/tutorials/installing-packages.rst:392 +#: ../source/tutorials/installing-packages.rst:391 msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." msgstr "" -#: ../source/tutorials/installing-packages.rst:400 +#: ../source/tutorials/installing-packages.rst:399 msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." msgstr "" -#: ../source/tutorials/installing-packages.rst:417 +#: ../source/tutorials/installing-packages.rst:416 msgid "Installing to the User Site" msgstr "" -#: ../source/tutorials/installing-packages.rst:419 +#: ../source/tutorials/installing-packages.rst:418 msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" msgstr "" -#: ../source/tutorials/installing-packages.rst:434 +#: ../source/tutorials/installing-packages.rst:433 msgid "For more information see the `User Installs `_ section from the pip docs." msgstr "" -#: ../source/tutorials/installing-packages.rst:438 +#: ../source/tutorials/installing-packages.rst:437 msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." msgstr "" -#: ../source/tutorials/installing-packages.rst:441 +#: ../source/tutorials/installing-packages.rst:440 msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" msgstr "" -#: ../source/tutorials/installing-packages.rst:449 +#: ../source/tutorials/installing-packages.rst:448 msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." msgstr "" -#: ../source/tutorials/installing-packages.rst:455 +#: ../source/tutorials/installing-packages.rst:454 msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." msgstr "" -#: ../source/tutorials/installing-packages.rst:471 +#: ../source/tutorials/installing-packages.rst:470 msgid "Install a list of requirements specified in a :ref:`Requirements File `." msgstr "" -#: ../source/tutorials/installing-packages.rst:487 +#: ../source/tutorials/installing-packages.rst:486 msgid "Installing from VCS" msgstr "" -#: ../source/tutorials/installing-packages.rst:489 +#: ../source/tutorials/installing-packages.rst:488 msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." msgstr "" -#: ../source/tutorials/installing-packages.rst:511 +#: ../source/tutorials/installing-packages.rst:510 msgid "Installing from other Indexes" msgstr "" -#: ../source/tutorials/installing-packages.rst:513 +#: ../source/tutorials/installing-packages.rst:512 msgid "Install from an alternate index" msgstr "" -#: ../source/tutorials/installing-packages.rst:527 +#: ../source/tutorials/installing-packages.rst:526 msgid "Search an additional index during install, in addition to :term:`PyPI `" msgstr "" -#: ../source/tutorials/installing-packages.rst:543 +#: ../source/tutorials/installing-packages.rst:542 msgid "Installing from a local src tree" msgstr "" -#: ../source/tutorials/installing-packages.rst:546 -msgid "Installing from local src in :doc:`Development Mode `, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." +#: ../source/tutorials/installing-packages.rst:545 +msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." msgstr "" -#: ../source/tutorials/installing-packages.rst:563 +#: ../source/tutorials/installing-packages.rst:562 msgid "You can also install normally from src" msgstr "" -#: ../source/tutorials/installing-packages.rst:580 +#: ../source/tutorials/installing-packages.rst:579 msgid "Install a particular source archive file." msgstr "" -#: ../source/tutorials/installing-packages.rst:594 +#: ../source/tutorials/installing-packages.rst:593 msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" msgstr "" -#: ../source/tutorials/installing-packages.rst:614 +#: ../source/tutorials/installing-packages.rst:613 msgid "Installing from other sources" msgstr "" -#: ../source/tutorials/installing-packages.rst:616 +#: ../source/tutorials/installing-packages.rst:615 msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." msgstr "" -#: ../source/tutorials/installing-packages.rst:628 +#: ../source/tutorials/installing-packages.rst:627 msgid "Installing Prereleases" msgstr "" -#: ../source/tutorials/installing-packages.rst:630 +#: ../source/tutorials/installing-packages.rst:629 msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." msgstr "" -#: ../source/tutorials/installing-packages.rst:646 +#: ../source/tutorials/installing-packages.rst:645 msgid "Installing Setuptools \"Extras\"" msgstr "" -#: ../source/tutorials/installing-packages.rst:648 +#: ../source/tutorials/installing-packages.rst:647 msgid "Install `setuptools extras`_." msgstr "" -#: ../source/tutorials/installing-packages.rst:668 +#: ../source/tutorials/installing-packages.rst:667 msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." msgstr "" -#: ../source/tutorials/installing-packages.rst:677 +#: ../source/tutorials/installing-packages.rst:676 msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." msgstr "" -#: ../source/tutorials/installing-packages.rst:682 +#: ../source/tutorials/installing-packages.rst:681 msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" msgstr "" @@ -8799,7 +8799,7 @@ msgid "Use ``pip`` to install Pipenv:" msgstr "" #: ../source/tutorials/managing-dependencies.rst:54 -msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the :py:data:`user base `'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." +msgid "This does a `user installation`_ to prevent breaking any system-wide packages. If ``pipenv`` isn't available in your shell after installation, you'll need to add the `user base`_'s binary directory to your ``PATH``. See :ref:`Installing to the User Site` for more information." msgstr "" #: ../source/tutorials/managing-dependencies.rst:65 From 3028d82381da40da0a72471798f05907d8e92c90 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 18 Sep 2021 13:14:36 +0800 Subject: [PATCH 0151/1072] Revert "Revert "Merge branch 'main' into new"" This reverts commit dbd6d70517f662a2796b676cd7b1d29832de1cf6. --- locales/zh_Hans/LC_MESSAGES/messages.po | 35 ++++++++++++++++--------- 1 file changed, 22 insertions(+), 13 deletions(-) diff --git a/locales/zh_Hans/LC_MESSAGES/messages.po b/locales/zh_Hans/LC_MESSAGES/messages.po index 4a101980f..70af2f8f0 100644 --- a/locales/zh_Hans/LC_MESSAGES/messages.po +++ b/locales/zh_Hans/LC_MESSAGES/messages.po @@ -6,13 +6,14 @@ # bluewindde <13548563428@139.com>, 2021. # Cube Kassaki <2524737581@qq.com>, 2021. # xlivevil , 2021. +# Eric , 2021. msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-07-06 19:32+0800\n" -"PO-Revision-Date: 2021-09-05 14:34+0000\n" -"Last-Translator: meowmeowmeowcat \n" +"PO-Revision-Date: 2021-09-13 10:46+0000\n" +"Last-Translator: Zuorong Zhang \n" "Language-Team: Chinese (Simplified) \n" "Language: zh_Hans\n" @@ -20,7 +21,7 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=1; plural=0;\n" -"X-Generator: Weblate 4.8.1-dev\n" +"X-Generator: Weblate 4.9-dev\n" #: ../source/contribute.rst:5 msgid "Contribute to this guide" @@ -162,7 +163,7 @@ msgid "" "Python 3.6 on your operating system." msgstr "" "Python 3.6。我们的构建脚本只为 Python 3.6 而设计。请参阅 `Hitchhiker's Guide to Python " -"installation instructions`_ 以在你您的操作系统上安装Python 3.6。" +"installation instructions`_ 将 Python 3.6 安装于您的操作系统中。" #: ../source/contribute.rst:91 msgid "" @@ -656,8 +657,9 @@ msgid "" "what index or source). The where (i.e. how they are to be made \"Concrete" "\") is to be determined at install time using :ref:`pip` options. [1]_" msgstr "" -"最后，重要的是要了解“install_requires”是“Abstract”要求的列表，即只是名称和版本限制，并不能确定从哪里满足依赖关系（即从什么索引" -"或来源）。在安装时使用 :ref:`pip` 选项确定在哪里（即如何使它们“Concrete”）。 [1]_" +"最后，重要的是要了解 ``install_requires`` " +"是“Abstract”要求的列表，即只是名称和版本限制，并不能确定从哪里满足依赖关系（即从什么索引或来源）。在安装时使用 :ref:`pip` " +"选项确定在哪里（即如何使它们“Concrete”）。 [1]_" #: ../source/discussions/install-requires-vs-requirements.rst:64 #: ../source/tutorials/installing-packages.rst:460 @@ -699,8 +701,8 @@ msgid "" "\"Concrete\", i.e. associated with a particular index or directory of " "packages. [1]_" msgstr "" -"而“install_requires”需求是“Abstract”，即不与任何特定索引相关联，需求文件通常包含诸如“--index-url”或" -"“--find-links”之类的pip选项来提出需求“Concrete”，即与包的特定索引或目录相关联。 [1]_" +"而 ``install_requires`` 需求是“Abstract”的，即不与任何特定索引相关联，需求文件通常包含 pip 选项，如 " +"``--index-url`` 或 ``--find-links`` 使需求“Concrete”，即与包的特定索引或目录相关联。 [1]_" #: ../source/discussions/install-requires-vs-requirements.rst:84 msgid "" @@ -1020,6 +1022,8 @@ msgid "" "to distribute a :term:`Release`. The archive file is what an end-user will " "download from the internet and install." msgstr "" +"一个版本化的存档文件包含 Python :term:`packages `、:term:`modules " +"` 和其他用于分发:term:`Release` 的资源文件的版本化存档文件。存档文件是最终用户将从 Internet 下载并安装的文件。" #: ../source/glossary.rst:34 msgid "" @@ -1031,6 +1035,9 @@ msgid "" "distribution), which are often referred to with the single term " "\"distribution\"." msgstr "" +"分发包更常被称为“包”或“分发”，但是当需要更清楚地防止与 :term:`Import Package` " +"混淆时，本指南可能会使用扩展术语（通常也称为“包”）或另一种发行版（例如 Linux 发行版或 Python " +"语言发行版），通常用单个术语“发行版”来指代。" #: ../source/glossary.rst:41 msgid "Egg" @@ -1067,7 +1074,7 @@ msgstr "" #: ../source/glossary.rst:59 msgid "Known Good Set (KGS)" -msgstr "" +msgstr "已知良好集 (KGS)" #: ../source/glossary.rst:62 msgid "" @@ -1096,7 +1103,7 @@ msgid "" "\", but this guide will use the expanded term when more clarity is needed to " "prevent confusion with a :term:`Distribution Package` which is also commonly " "called a \"package\"." -msgstr "" +msgstr "导入包通常用单个词“包”来指代，但本指南将在需要更清楚地说明时使用扩展术语，以防止与通常也称为“包”的 :term:`分发包` 混淆." #: ../source/glossary.rst:78 msgid "Module" @@ -1107,6 +1114,8 @@ msgid "" "The basic unit of code reusability in Python, existing in one of two types: :" "term:`Pure Module`, or :term:`Extension Module`." msgstr "" +"Python 中代码可重用性的基本单元，存在于以下两种类型之一：:term:`Pure Module` 或 :term:`Extension " +"Module`。" #: ../source/glossary.rst:84 msgid "Package Index" @@ -1116,7 +1125,7 @@ msgstr "包索引 (Package Index)" msgid "" "A repository of distributions with a web interface to automate :term:" "`package ` discovery and consumption." -msgstr "" +msgstr "一个带有 Web 界面的发行版存储库，用于自动化 :term:`package ` 发现和消费。" #: ../source/glossary.rst:90 msgid "Per Project Index" @@ -1500,7 +1509,7 @@ msgstr "" #: ../source/guides/analyzing-pypi-package-downloads.rst:58 msgid "Navigate to the `BigQuery web UI`_." -msgstr "导航到 `BigQuery 网页界面`_ 。" +msgstr "导航到 `BigQuery 网页用户界面`_。" #: ../source/guides/analyzing-pypi-package-downloads.rst:59 msgid "Create a new project." @@ -3266,7 +3275,7 @@ msgstr "" #: ../source/specifications/core-metadata.rst:693 #: ../source/specifications/core-metadata.rst:722 msgid "Examples::" -msgstr "例子：:" +msgstr "例子::" #: ../source/guides/dropping-older-python-versions.rst:86 msgid "" From ebc217b59aadc05edf49bf4e7d3bd86c0e2840e2 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 18 Sep 2021 13:15:39 +0800 Subject: [PATCH 0152/1072] Revert "Update messages.pot as of version cc488ec" This reverts commit 61883a290f99eb3d475c3d6eaed116da6e314e93. --- locales/messages.pot | 1132 +++++++++++++++++++++--------------------- 1 file changed, 565 insertions(+), 567 deletions(-) diff --git a/locales/messages.pot b/locales/messages.pot index 4eac54e62..5ea4b3276 100644 --- a/locales/messages.pot +++ b/locales/messages.pot @@ -8,7 +8,7 @@ msgid "" msgstr "" "Project-Id-Version: Python Packaging User Guide \n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-08-26 13:33+0000\n" +"POT-Creation-Date: 2021-07-06 19:32+0800\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" @@ -40,222 +40,170 @@ msgstr "" msgid "Writing new content" msgstr "" -#: ../source/contribute.rst:14 -msgid "Translate the guide" -msgstr "" - -#: ../source/contribute.rst:16 +#: ../source/contribute.rst:15 msgid "Most of the work on the |PyPUG| takes place on the `project's GitHub repository`__. To get started, check out the list of `open issues`__ and `pull requests`__. If you're planning to write or edit the guide, please read the :ref:`style guide `." msgstr "" -#: ../source/contribute.rst:25 +#: ../source/contribute.rst:24 msgid "By contributing to the |PyPUG|, you're expected to follow the PSF's `Code of Conduct`__." msgstr "" -#: ../source/contribute.rst:32 +#: ../source/contribute.rst:31 msgid "Documentation types" msgstr "" -#: ../source/contribute.rst:34 +#: ../source/contribute.rst:33 msgid "This project consists of four distinct documentation types with specific purposes. When proposing new additions to the project please pick the appropriate documentation type." msgstr "" -#: ../source/contribute.rst:39 +#: ../source/contribute.rst:38 #: ../source/tutorials/index.rst:2 msgid "Tutorials" msgstr "" -#: ../source/contribute.rst:41 +#: ../source/contribute.rst:40 msgid "Tutorials are focused on teaching the reader new concepts by accomplishing a goal. They are opinionated step-by-step guides. They do not include extraneous warnings or information. `example tutorial-style document`_." msgstr "" -#: ../source/contribute.rst:48 +#: ../source/contribute.rst:47 #: ../source/guides/index.rst:2 msgid "Guides" msgstr "" -#: ../source/contribute.rst:50 +#: ../source/contribute.rst:49 msgid "Guides are focused on accomplishing a specific task and can assume some level of pre-requisite knowledge. These are similar to tutorials, but have a narrow and clear focus and can provide lots of caveats and additional information as needed. They may also discuss multiple approaches to accomplishing the task. :doc:`example guide-style document `." msgstr "" -#: ../source/contribute.rst:57 +#: ../source/contribute.rst:56 #: ../source/discussions/index.rst:2 msgid "Discussions" msgstr "" -#: ../source/contribute.rst:59 +#: ../source/contribute.rst:58 msgid "Discussions are focused on understanding and information. These explore a specific topic without a specific goal in mind. :doc:`example discussion-style document `." msgstr "" -#: ../source/contribute.rst:64 +#: ../source/contribute.rst:63 msgid "Specifications" msgstr "" -#: ../source/contribute.rst:66 +#: ../source/contribute.rst:65 msgid "Specifications are reference documention focused on comprehensively documenting an agreed-upon interface for interoperability between packaging tools. :doc:`example specification-style document `." msgstr "" -#: ../source/contribute.rst:72 -msgid "Translations" -msgstr "" - -#: ../source/contribute.rst:74 -msgid "We use `Weblate`_ to manage translations of this project. Please visit the `packaging.python.org`_ project on Weblate to contribute." -msgstr "" - -#: ../source/contribute.rst:77 -msgid "If you are experiencing issues while you are working on translations, please open an issue on `Github`_." -msgstr "" - -#: ../source/contribute.rst:82 -msgid "Any translations of this project should follow `reStructuredText syntax`_." -msgstr "" - -#: ../source/contribute.rst:90 -msgid "Adding a language" -msgstr "" - -#: ../source/contribute.rst:92 -msgid "If your language is not listed on `packaging.python.org`_, click the button :guilabel:`Start new translation` at the bottom of the language list and add the language you want to translate." -msgstr "" - -#: ../source/contribute.rst:97 -msgid "Following reStructuredText syntax" -msgstr "" - -#: ../source/contribute.rst:99 -msgid "If you are not familiar with reStructuredText (RST) syntax, please read `this guide`_ before translating on Weblate." -msgstr "" - -#: ../source/contribute.rst:102 -msgid "**Do not translate the text in reference directly**" -msgstr "" - -#: ../source/contribute.rst:104 -msgid "When translating the text in reference, please do not translate them directly." -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Wrong: Translate the following text directly:" -msgstr "" - -#: ../source/contribute.rst:0 -msgid "Right: Translate the following text with your own language and add the original reference:" -msgstr "" - -#: ../source/contribute.rst:121 +#: ../source/contribute.rst:73 msgid "Building the guide locally" msgstr "" -#: ../source/contribute.rst:123 +#: ../source/contribute.rst:75 msgid "Though not required to contribute, it may be useful to build this guide locally in order to test your changes. In order to build this guide locally, you'll need:" msgstr "" -#: ../source/contribute.rst:127 -msgid "`Nox `_. You can install or upgrade nox using ``pip``:" +#: ../source/contribute.rst:79 +msgid "`Nox `_. You can install or upgrade nox using ``pip``::" msgstr "" -#: ../source/contribute.rst:134 +#: ../source/contribute.rst:84 msgid "Python 3.6. Our build scripts are designed to work with Python 3.6 only. See the `Hitchhiker's Guide to Python installation instructions`_ to install Python 3.6 on your operating system." msgstr "" -#: ../source/contribute.rst:141 -msgid "To build the guide, run the following bash command in the source folder:" +#: ../source/contribute.rst:91 +msgid "To build the guide, run the following bash command in the source folder::" msgstr "" -#: ../source/contribute.rst:147 +#: ../source/contribute.rst:95 msgid "After the process has completed you can find the HTML output in the ``./build/html`` directory. You can open the ``index.html`` file to view the guide in web browser, but it's recommended to serve the guide using an HTTP server." msgstr "" -#: ../source/contribute.rst:152 -msgid "You can build the guide and serve it via an HTTP server using the following command:" +#: ../source/contribute.rst:100 +msgid "You can build the guide and serve it via an HTTP server using the following command::" msgstr "" -#: ../source/contribute.rst:159 +#: ../source/contribute.rst:105 msgid "The guide will be browsable via http://localhost:8000." msgstr "" -#: ../source/contribute.rst:163 +#: ../source/contribute.rst:109 msgid "Where the guide is deployed" msgstr "" -#: ../source/contribute.rst:165 +#: ../source/contribute.rst:111 msgid "The guide is deployed via ReadTheDocs and the configuration lives at https://readthedocs.org/projects/python-packaging-user-guide/. It's served from a custom domain and fronted by Fast.ly." msgstr "" -#: ../source/contribute.rst:171 +#: ../source/contribute.rst:117 msgid "Style guide" msgstr "" -#: ../source/contribute.rst:173 +#: ../source/contribute.rst:119 msgid "This style guide has recommendations for how you should write the |PyPUG|. Before you start writing, please review it. By following the style guide, your contributions will help add to a cohesive whole and make it easier for your contributions to be accepted into the project." msgstr "" -#: ../source/contribute.rst:180 +#: ../source/contribute.rst:126 msgid "Purpose" msgstr "" -#: ../source/contribute.rst:182 +#: ../source/contribute.rst:128 msgid "The purpose of the |PyPUG| is to be the authoritative resource on how to package, publish, and install Python projects using current tools." msgstr "" -#: ../source/contribute.rst:187 +#: ../source/contribute.rst:133 msgid "Scope" msgstr "" -#: ../source/contribute.rst:189 +#: ../source/contribute.rst:135 msgid "The guide is meant to answer questions and solve problems with accurate and focused recommendations." msgstr "" -#: ../source/contribute.rst:192 +#: ../source/contribute.rst:138 msgid "The guide isn't meant to be comprehensive and it's not meant to replace individual projects' documentation. For example, pip has dozens of commands, options, and settings. The pip documentation describes each of them in detail, while this guide describes only the parts of pip that are needed to complete the specific tasks described in this guide." msgstr "" -#: ../source/contribute.rst:200 +#: ../source/contribute.rst:146 msgid "Audience" msgstr "" -#: ../source/contribute.rst:202 +#: ../source/contribute.rst:148 msgid "The audience of this guide is anyone who uses Python with packages." msgstr "" -#: ../source/contribute.rst:204 +#: ../source/contribute.rst:150 msgid "Don't forget that the Python community is big and welcoming. Readers may not share your age, gender, education, culture, and more, but they deserve to learn about packaging just as much as you do." msgstr "" -#: ../source/contribute.rst:208 +#: ../source/contribute.rst:154 msgid "In particular, keep in mind that not all people who use Python see themselves as programmers. The audience of this guide includes astronomers or painters or students as well as professional software developers." msgstr "" -#: ../source/contribute.rst:214 +#: ../source/contribute.rst:160 msgid "Voice and tone" msgstr "" -#: ../source/contribute.rst:216 +#: ../source/contribute.rst:162 msgid "When writing this guide, strive to write with a voice that's approachable and humble, even if you have all the answers." msgstr "" -#: ../source/contribute.rst:219 +#: ../source/contribute.rst:165 msgid "Imagine you're working on a Python project with someone you know to be smart and skilled. You like working with them and they like working with you. That person has asked you a question and you know the answer. How do you respond? *That* is how you should write this guide." msgstr "" -#: ../source/contribute.rst:224 +#: ../source/contribute.rst:170 msgid "Here's a quick check: try reading aloud to get a sense for your writing's voice and tone. Does it sound like something you would say or does it sound like you're acting out a part or giving a speech? Feel free to use contractions and don't worry about sticking to fussy grammar rules. You are hereby granted permission to end a sentence in a preposition, if that's what you want to end it with." msgstr "" -#: ../source/contribute.rst:231 +#: ../source/contribute.rst:177 msgid "When writing the guide, adjust your tone for the seriousness and difficulty of the topic. If you're writing an introductory tutorial, it's OK to make a joke, but if you're covering a sensitive security recommendation, you might want to avoid jokes altogether." msgstr "" -#: ../source/contribute.rst:238 +#: ../source/contribute.rst:184 msgid "Conventions and mechanics" msgstr "" -#: ../source/contribute.rst:246 +#: ../source/contribute.rst:192 msgid "**Write to the reader**" msgstr "" -#: ../source/contribute.rst:241 +#: ../source/contribute.rst:187 msgid "When giving recommendations or steps to take, address the reader as *you* or use the imperative mood." msgstr "" @@ -271,27 +219,27 @@ msgstr "" msgid "Right: To install it, run…" msgstr "" -#: ../source/contribute.rst:252 +#: ../source/contribute.rst:198 msgid "**State assumptions**" msgstr "" -#: ../source/contribute.rst:249 +#: ../source/contribute.rst:195 msgid "Avoid making unstated assumptions. Reading on the web means that any page of the guide may be the first page of the guide that the reader ever sees. If you're going to make assumptions, then say what assumptions that you're going to make." msgstr "" -#: ../source/contribute.rst:257 +#: ../source/contribute.rst:203 msgid "**Cross-reference generously**" msgstr "" -#: ../source/contribute.rst:255 +#: ../source/contribute.rst:201 msgid "The first time you mention a tool or practice, link to the part of the guide that covers it, or link to a relevant document elsewhere. Save the reader a search." msgstr "" -#: ../source/contribute.rst:267 +#: ../source/contribute.rst:213 msgid "**Respect naming practices**" msgstr "" -#: ../source/contribute.rst:260 +#: ../source/contribute.rst:206 msgid "When naming tools, sites, people, and other proper nouns, use their preferred capitalization." msgstr "" @@ -311,11 +259,11 @@ msgstr "" msgid "Right: …hosted on GitHub." msgstr "" -#: ../source/contribute.rst:276 +#: ../source/contribute.rst:222 msgid "**Use a gender-neutral style**" msgstr "" -#: ../source/contribute.rst:270 +#: ../source/contribute.rst:216 msgid "Often, you'll address the reader directly with *you*, *your* and *yours*. Otherwise, use gender-neutral pronouns *they*, *their*, and *theirs* or avoid pronouns entirely." msgstr "" @@ -331,15 +279,15 @@ msgstr "" msgid "Right: A maintainer uploads the file. Then the maintainer…" msgstr "" -#: ../source/contribute.rst:288 +#: ../source/contribute.rst:234 msgid "**Headings**" msgstr "" -#: ../source/contribute.rst:279 +#: ../source/contribute.rst:225 msgid "Write headings that use words the reader is searching for. A good way to do this is to have your heading complete an implied question. For example, a reader might want to know *How do I install MyLibrary?* so a good heading might be *Install MyLibrary*." msgstr "" -#: ../source/contribute.rst:284 +#: ../source/contribute.rst:230 msgid "In section headings, use sentence case. In other words, write headings as you would write a typical sentence." msgstr "" @@ -351,11 +299,11 @@ msgstr "" msgid "Right: Things you should know about Python" msgstr "" -#: ../source/contribute.rst:291 +#: ../source/contribute.rst:237 msgid "**Numbers**" msgstr "" -#: ../source/contribute.rst:291 +#: ../source/contribute.rst:237 msgid "In body text, write numbers one through nine as words. For other numbers or numbers in tables, use numerals." msgstr "" @@ -391,7 +339,7 @@ msgid "Last Reviewed" msgstr "" #: ../source/discussions/deploying-python-applications.rst:7 -msgid "2021-8-24" +msgid "2014-11-11" msgstr "" #: ../source/discussions/deploying-python-applications.rst:11 @@ -400,7 +348,6 @@ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:22 #: ../source/guides/index-mirrors-and-caches.rst:12 #: ../source/guides/installing-scientific-packages.rst:9 -#: ../source/guides/installing-using-linux-tools.rst:11 #: ../source/guides/packaging-binary-extensions.rst:17 #: ../source/guides/supporting-multiple-python-versions.rst:12 #: ../source/guides/supporting-windows-using-appveyor.rst:15 @@ -424,7 +371,6 @@ msgid "OS packaging & installers" msgstr "" #: ../source/discussions/deploying-python-applications.rst:52 -#: ../source/discussions/deploying-python-applications.rst:89 msgid "Windows" msgstr "" @@ -448,40 +394,7 @@ msgstr "" msgid "Application bundles" msgstr "" -#: ../source/discussions/deploying-python-applications.rst:92 -msgid "py2exe" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:94 -msgid "`py2exe `__ is a distutils extension which allows to build standalone Windows executable programs (32-bit and 64-bit) from Python scripts. Python versions included in the official development cycle are supported (refers to `Status of Python branches`__). py2exe can build console executables and windows (GUI) executables. Building windows services, and DLL/EXE COM servers might work but it is not actively supported. The distutils extension is released under the MIT-licence and Mozilla Public License 2.0." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:106 -msgid "macOS" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:109 -msgid "py2app" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:111 -msgid "`py2app `__ is a Python setuptools command which will allow you to make standalone macOS application bundles and plugins from Python scripts. Note that py2app MUST be used on macOS to build applications, it cannot create Mac applications on other platforms. py2app is released under the MIT-license." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:118 -msgid "Unix (including Linux and macOS)" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:121 -#: ../source/key_projects.rst:470 -msgid "pex" -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:123 -msgid "`pex `__ is a library for generating .pex (Python EXecutable) files which are executable Python environments in the spirit of virtualenvs. pex is an expansion upon the ideas outlined in :pep:`441` and makes the deployment of Python applications as simple as cp. pex files may even include multiple platform-specific Python distributions, meaning that a single pex file can be portable across Linux and macOS. pex is released under the Apache License 2.0." -msgstr "" - -#: ../source/discussions/deploying-python-applications.rst:132 +#: ../source/discussions/deploying-python-applications.rst:91 msgid "Configuration management" msgstr "" @@ -494,6 +407,7 @@ msgid "install_requires vs requirements files" msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:12 +#: ../source/guides/distributing-packages-using-setuptools.rst:382 msgid "install_requires" msgstr "" @@ -526,7 +440,7 @@ msgid "Lastly, it's important to understand that ``install_requires`` is a listi msgstr "" #: ../source/discussions/install-requires-vs-requirements.rst:64 -#: ../source/tutorials/installing-packages.rst:468 +#: ../source/tutorials/installing-packages.rst:460 msgid "Requirements files" msgstr "" @@ -1603,9 +1517,7 @@ msgid "The most relevant arguments are explained below. Most of the snippets giv msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:164 -#: ../source/specifications/declaring-project-metadata.rst:29 -#: ../source/specifications/declaring-project-metadata.rst:41 -msgid "``name``" +msgid "name" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:170 @@ -1625,9 +1537,8 @@ msgid "Comparison of project names is case insensitive and treats arbitrarily-lo msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:190 -#: ../source/specifications/declaring-project-metadata.rst:34 -#: ../source/specifications/declaring-project-metadata.rst:54 -msgid "``version``" +#: ../source/specifications/binary-distribution-format.rst:127 +msgid "version" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:196 @@ -1647,8 +1558,7 @@ msgid "If the project code itself needs run-time access to the version, the simp msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:214 -#: ../source/specifications/declaring-project-metadata.rst:66 -msgid "``description``" +msgid "description" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:222 @@ -1668,7 +1578,7 @@ msgid "A `content type ` in yo msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:370 -msgid "``py_modules``" +msgid "py_modules" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:376 msgid "If your project contains any single-file Python modules that aren't part of a package, set ``py_modules`` to a list of the names of the modules (minus the ``.py`` extension) in order to make :ref:`setuptools` aware of them." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:382 -msgid "``install_requires``" -msgstr "" - #: ../source/guides/distributing-packages-using-setuptools.rst:388 msgid "\"install_requires\" should be used to specify what dependencies a project minimally needs to run. When the project is installed by :ref:`pip`, this is the specification that is used to install its dependencies." msgstr "" @@ -1755,7 +1658,7 @@ msgid "For more on using \"install_requires\" see :ref:`install_requires vs Requ msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:398 -msgid "``python_requires``" +msgid "python_requires" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:400 @@ -1779,7 +1682,7 @@ msgid "In addition, only versions 9.0.0 and higher of :ref:`pip` recognize the ` msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:431 -msgid "``package_data``" +msgid "package_data" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:440 @@ -1795,7 +1698,7 @@ msgid "For more information, see :std:doc:`Including Data Files `_), and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." +msgid "Each ``(directory, files)`` pair in the sequence specifies the installation directory and the files to install there. The ``directory`` must be a relative path (although this may change in the future, see `wheel Issue #92 `_). and it is interpreted relative to the installation prefix (Python’s ``sys.prefix`` for a default installation; ``site.USER_BASE`` for a user installation). Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:479 @@ -1815,7 +1718,7 @@ msgid "When installing packages as egg, ``data_files`` is not supported. So, if msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:491 -msgid "``scripts``" +msgid "scripts" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:493 @@ -1823,7 +1726,7 @@ msgid "Although ``setup()`` supports a `scripts `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." +msgid "Use \"console_script\" `entry points `_ to register your script interfaces. You can then let the toolchain handle the work of turning these interfaces into actual scripts [2]_. The scripts will be generated during the install of your :term:`distribution `." msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:538 @@ -1995,203 +1898,203 @@ msgid "Assuming you're in the root of your project directory, then run:" msgstr "" #: ../source/guides/distributing-packages-using-setuptools.rst:674 -msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with ``install_requires`` and any scripts declared with ``console_scripts``. Dependencies will be installed in the usual, non-editable mode." +msgid "Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers to the current working directory, so together, it means to install the current directory (i.e. your project) in editable mode. This will also install any dependencies declared with \"install_requires\" and any scripts declared with \"console_scripts\". Dependencies will be installed in the usual, non-editable mode." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:681 +#: ../source/guides/distributing-packages-using-setuptools.rst:680 msgid "It's fairly common to also want to install some of your dependencies in editable mode as well. For example, supposing your project requires \"foo\" and \"bar\", but you want \"bar\" installed from VCS in editable mode, then you could construct a requirements file like so::" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:689 +#: ../source/guides/distributing-packages-using-setuptools.rst:688 msgid "The first line says to install your project and any dependencies. The second line overrides the \"bar\" dependency, such that it's fulfilled from VCS, not PyPI." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:693 +#: ../source/guides/distributing-packages-using-setuptools.rst:692 msgid "If, however, you want \"bar\" installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file::" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:698 +#: ../source/guides/distributing-packages-using-setuptools.rst:697 msgid "Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the :ref:`Requirements File ` section in the pip docs. For more on VCS installs, see the :ref:`VCS Support ` section of the pip docs." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:702 -msgid "Lastly, if you don't want to install any dependencies at all, you can run:" +#: ../source/guides/distributing-packages-using-setuptools.rst:701 +msgid "Lastly, if you don't want to install any dependencies at all, you can run::" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:709 +#: ../source/guides/distributing-packages-using-setuptools.rst:706 msgid "For more information, see the `Development Mode `_ section of the `setuptools docs `_." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:716 +#: ../source/guides/distributing-packages-using-setuptools.rst:713 msgid "Packaging your project" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:718 +#: ../source/guides/distributing-packages-using-setuptools.rst:715 msgid "To have your project installable from a :term:`Package Index` like :term:`PyPI `, you'll need to create a :term:`Distribution ` (aka \":term:`Package `\") for your project." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:723 +#: ../source/guides/distributing-packages-using-setuptools.rst:720 msgid "Before you can build wheels and sdists for your project, you'll need to install the ``build`` package:" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:740 +#: ../source/guides/distributing-packages-using-setuptools.rst:737 msgid "Source distributions" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:742 +#: ../source/guides/distributing-packages-using-setuptools.rst:739 msgid "Minimally, you should create a :term:`Source Distribution `:" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:758 +#: ../source/guides/distributing-packages-using-setuptools.rst:755 msgid "A \"source distribution\" is unbuilt (i.e. it's not a :term:`Built Distribution`), and requires a build step when installed by pip. Even if the distribution is pure Python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from :file:`setup.py` and/or :file:`setup.cfg`." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:766 +#: ../source/guides/distributing-packages-using-setuptools.rst:763 msgid "Wheels" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:768 +#: ../source/guides/distributing-packages-using-setuptools.rst:765 msgid "You should also create a wheel for your project. A wheel is a :term:`built package ` that can be installed without needing to go through the \"build\" process. Installing wheels is substantially faster for the end user than installing from a source distribution." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:773 +#: ../source/guides/distributing-packages-using-setuptools.rst:770 msgid "If your project is pure Python then you'll be creating a :ref:`\"Pure Python Wheel\" (see section below) `." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:776 +#: ../source/guides/distributing-packages-using-setuptools.rst:773 msgid "If your project contains compiled extensions, then you'll be creating what's called a :ref:`*Platform Wheel* (see section below) `." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:779 +#: ../source/guides/distributing-packages-using-setuptools.rst:776 msgid "If your project also supports Python 2 *and* contains no C extensions, then you should create what's called a *Universal Wheel* by adding the following to your :file:`setup.cfg` file:" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:788 +#: ../source/guides/distributing-packages-using-setuptools.rst:785 msgid "Only use this setting if your project does not have any C extensions *and* supports Python 2 and 3." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:795 +#: ../source/guides/distributing-packages-using-setuptools.rst:792 msgid "Pure Python Wheels" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:797 +#: ../source/guides/distributing-packages-using-setuptools.rst:794 msgid "*Pure Python Wheels* contain no compiled extensions, and therefore only require a single Python wheel." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:800 -#: ../source/guides/distributing-packages-using-setuptools.rst:829 +#: ../source/guides/distributing-packages-using-setuptools.rst:797 +#: ../source/guides/distributing-packages-using-setuptools.rst:826 msgid "To build the wheel:" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:814 +#: ../source/guides/distributing-packages-using-setuptools.rst:811 msgid "The ``wheel`` package will detect that the code is pure Python, and build a wheel that's named such that it's usable on any Python 3 installation. For details on the naming of wheel files, see :pep:`425`." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:818 +#: ../source/guides/distributing-packages-using-setuptools.rst:815 msgid "If you run ``build`` without ``--wheel`` or ``--sdist``, it will build both files for you; this is useful when you don't need multiple wheels." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:824 +#: ../source/guides/distributing-packages-using-setuptools.rst:821 msgid "Platform Wheels" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:826 +#: ../source/guides/distributing-packages-using-setuptools.rst:823 msgid "*Platform Wheels* are wheels that are specific to a certain platform like Linux, macOS, or Windows, usually due to containing compiled extensions." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:844 +#: ../source/guides/distributing-packages-using-setuptools.rst:841 msgid "The ``wheel`` package will detect that the code is not pure Python, and build a wheel that's named such that it's only usable on the platform that it was built on. For details on the naming of wheel files, see :pep:`425`." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:850 +#: ../source/guides/distributing-packages-using-setuptools.rst:847 msgid ":term:`PyPI ` currently supports uploads of platform wheels for Windows, macOS, and the multi-distro ``manylinux*`` ABI. Details of the latter are defined in :pep:`513`." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:858 +#: ../source/guides/distributing-packages-using-setuptools.rst:855 msgid "Uploading your Project to PyPI" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:860 +#: ../source/guides/distributing-packages-using-setuptools.rst:857 msgid "When you ran the command to create your distribution, a new directory ``dist/`` was created under your project's root directory. That's where you'll find your distribution file(s) to upload." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:864 +#: ../source/guides/distributing-packages-using-setuptools.rst:861 msgid "These files are only created when you run the command to create your distribution. This means that any time you change the source of your project or the configuration in your :file:`setup.py` file, you will need to rebuild these files again before you can distribute the changes to PyPI." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:869 +#: ../source/guides/distributing-packages-using-setuptools.rst:866 msgid "Before releasing on main PyPI repo, you might prefer training with the `PyPI test site `_ which is cleaned on a semi regular basis. See :ref:`using-test-pypi` on how to setup your configuration in order to use it." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:874 +#: ../source/guides/distributing-packages-using-setuptools.rst:871 msgid "In other resources you may encounter references to using ``python setup.py register`` and ``python setup.py upload``. These methods of registering and uploading a package are **strongly discouraged** as it may use a plaintext HTTP or unverified HTTPS connection on some Python versions, allowing your username and password to be intercepted during transmission." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:880 -msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files:" +#: ../source/guides/distributing-packages-using-setuptools.rst:877 +msgid "The reStructuredText parser used on PyPI is **not** Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the ``.. raw::`` directive). **Before** trying to upload your distribution, you should check to see if your brief / long descriptions provided in :file:`setup.py` are valid. You can do this by running :std:doc:`twine check ` on your package files::" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:893 +#: ../source/guides/distributing-packages-using-setuptools.rst:888 msgid "Create an account" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:895 +#: ../source/guides/distributing-packages-using-setuptools.rst:890 msgid "First, you need a :term:`PyPI ` user account. You can create an account `using the form on the PyPI website `_." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:899 +#: ../source/guides/distributing-packages-using-setuptools.rst:894 msgid "Now you'll create a PyPI `API token`_ so you will be able to securely upload your project." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:902 +#: ../source/guides/distributing-packages-using-setuptools.rst:897 msgid "Go to https://pypi.org/manage/account/#api-tokens and create a new `API token`_; don't limit its scope to a particular project, since you are creating a new project." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:906 +#: ../source/guides/distributing-packages-using-setuptools.rst:901 msgid "**Don't close the page until you have copied and saved the token — you won't see that token again.**" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:909 +#: ../source/guides/distributing-packages-using-setuptools.rst:904 msgid "To avoid having to copy and paste the token every time you upload, you can create a :file:`$HOME/.pypirc` file:" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:918 +#: ../source/guides/distributing-packages-using-setuptools.rst:913 msgid "**Be aware that this stores your token in plaintext.**" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:920 +#: ../source/guides/distributing-packages-using-setuptools.rst:915 #: ../source/guides/migrating-to-pypi-org.rst:70 #: ../source/guides/migrating-to-pypi-org.rst:109 #: ../source/guides/using-testpypi.rst:83 msgid "For more details, see the :ref:`specification ` for :file:`.pypirc`." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:926 +#: ../source/guides/distributing-packages-using-setuptools.rst:921 msgid "Upload your distributions" msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:928 +#: ../source/guides/distributing-packages-using-setuptools.rst:923 msgid "Once you have an account you can upload your distributions to :term:`PyPI ` using :ref:`twine`." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:931 +#: ../source/guides/distributing-packages-using-setuptools.rst:926 msgid "The process for uploading a release is the same regardless of whether or not the project already exists on PyPI - if it doesn't exist yet, it will be automatically created when the first release is uploaded." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:935 +#: ../source/guides/distributing-packages-using-setuptools.rst:930 msgid "For the second and subsequent releases, PyPI only requires that the version number of the new release differ from any previous releases." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:942 +#: ../source/guides/distributing-packages-using-setuptools.rst:937 msgid "You can see if your package has successfully uploaded by navigating to the URL ``https://pypi.org/project/`` where ``sampleproject`` is the name of your project that you uploaded. It may take a minute or two for your project to appear on the site." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:949 -#: ../source/tutorials/installing-packages.rst:671 +#: ../source/guides/distributing-packages-using-setuptools.rst:944 +#: ../source/tutorials/installing-packages.rst:663 msgid "Depending on your platform, this may require root or Administrator access. :ref:`pip` is currently considering changing this by `making user installs the default behavior `_." msgstr "" -#: ../source/guides/distributing-packages-using-setuptools.rst:955 +#: ../source/guides/distributing-packages-using-setuptools.rst:950 msgid "Specifically, the \"console_script\" approach generates ``.exe`` files on Windows, which are necessary because the OS special-cases ``.exe`` files. Script-execution features like ``PATHEXT`` and the :pep:`Python Launcher for Windows <397>` allow scripts to be used in many cases, but not all." msgstr "" @@ -2308,50 +2211,50 @@ msgid "This file is generated by Distutils or :ref:`setuptools` when it generate msgstr "" #: ../source/guides/dropping-older-python-versions.rst:108 -msgid "You can see the contents of the generated file like this:" +msgid "You can see the contents of the generated file like this::" msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:114 +#: ../source/guides/dropping-older-python-versions.rst:112 msgid "Validate that the following is in place, before publishing the package:" msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:116 +#: ../source/guides/dropping-older-python-versions.rst:114 msgid "If you have upgraded correctly, the Metadata-Version value should be 1.2 or higher." msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:117 +#: ../source/guides/dropping-older-python-versions.rst:115 msgid "The Requires-Python field is set and matches your specification in setup.py." msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:120 +#: ../source/guides/dropping-older-python-versions.rst:118 msgid "4. Using Twine to publish" msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:122 +#: ../source/guides/dropping-older-python-versions.rst:120 msgid "Twine has a number of advantages, apart from being faster it is now the supported method for publishing packages." msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:124 +#: ../source/guides/dropping-older-python-versions.rst:122 msgid "Make sure you are using the newest version of Twine, at least 1.9." msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:127 +#: ../source/guides/dropping-older-python-versions.rst:125 msgid "Dropping a Python release" msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:129 +#: ../source/guides/dropping-older-python-versions.rst:127 msgid "Once you have published a package with the Requires-Python metadata, you can then make a further update removing that Python runtime from support." msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:131 +#: ../source/guides/dropping-older-python-versions.rst:129 msgid "It must be done in this order for the automated fallback to work." msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:133 +#: ../source/guides/dropping-older-python-versions.rst:131 msgid "For example, you published the Requires-Python: \">=2.7\" as version 1.0.0 of your package." msgstr "" -#: ../source/guides/dropping-older-python-versions.rst:135 +#: ../source/guides/dropping-older-python-versions.rst:133 msgid "If you were then to update the version string to \">=3.5\", and publish a new version 2.0.0 of your package, any users running Pip 9.0+ from version 2.7 will have version 1.0.0 of the package installed, and any >=3.5 users will receive version 2.0.0." msgstr "" @@ -2448,26 +2351,26 @@ msgid "`Fast & local installs `:" +msgid "A variation on the above which pre-builds the installation files for the requirements using `python -m pip wheel `_::" msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:46 +#: ../source/guides/index-mirrors-and-caches.rst:45 msgid "Caching with devpi" msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:48 +#: ../source/guides/index-mirrors-and-caches.rst:47 msgid "devpi is a caching proxy server which you run on your laptop, or some other machine you know will always be available to you. See the `devpi documentation for getting started`__." msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:56 +#: ../source/guides/index-mirrors-and-caches.rst:55 msgid "Complete mirror with bandersnatch" msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:58 +#: ../source/guides/index-mirrors-and-caches.rst:57 msgid "bandersnatch will set up a complete local mirror of all PyPI :term:`packages ` (externally-hosted packages are not mirrored). See the `bandersnatch documentation for getting that going`__." msgstr "" -#: ../source/guides/index-mirrors-and-caches.rst:64 +#: ../source/guides/index-mirrors-and-caches.rst:63 msgid "A benefit of devpi is that it will create a mirror which includes :term:`packages ` that are external to PyPI, unlike bandersnatch which will only cache :term:`packages ` hosted on PyPI." msgstr "" @@ -2560,7 +2463,7 @@ msgid "Some of these distributions may not be compatible with the standard ``pip msgstr "" #: ../source/guides/installing-scientific-packages.rst:109 -#: ../source/key_projects.rst:581 +#: ../source/key_projects.rst:596 msgid "Spack" msgstr "" @@ -2589,15 +2492,15 @@ msgid "Installing stand alone command line tools" msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:4 -msgid "Many packages provide command line applications. Examples of such packages are `mypy `_, `flake8 `_, `black `_, and :ref:`pipenv`." +msgid "Many packages have command line entry points. Examples of this type of application are `mypy `_, `flake8 `_, :ref:`pipenv`,and `black `_." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:10 -msgid "Usually you want to be able to access these applications from anywhere on your system, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." +msgid "Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:15 -msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that its applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the applications from anywhere." +msgid ":ref:`pipx` solves this by creating a virtual environment for each package, while also ensuring that package's applications are accessible through a directory that is on your ``$PATH``. This allows each package to be upgraded or uninstalled without causing conflicts with other packages, and allows you to safely run the program from anywhere." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:21 @@ -2605,43 +2508,44 @@ msgid "pipx only works with Python 3.6+." msgstr "" #: ../source/guides/installing-stand-alone-command-line-tools.rst:23 -msgid "pipx is installed with pip:" +msgid "``pipx`` is installed with ``pip``:" msgstr "" -#: ../source/guides/installing-stand-alone-command-line-tools.rst:41 -msgid "``ensurepath`` ensures that the application directory is on your ``$PATH``. You may need to restart your terminal for this update to take effect." +#: ../source/guides/installing-stand-alone-command-line-tools.rst:30 +msgid "You may need to restart your terminal for the path updates to take effect." msgstr "" -#: ../source/guides/installing-stand-alone-command-line-tools.rst:44 -msgid "Now you can install packages with ``pipx install`` and run the package's applications(s) from anywhere." +#: ../source/guides/installing-stand-alone-command-line-tools.rst:32 +msgid "Now you can install packages with ``pipx install`` and access the package's entry point(s) from anywhere." msgstr "" -#: ../source/guides/installing-stand-alone-command-line-tools.rst:52 -msgid "For example:" +#: ../source/guides/installing-stand-alone-command-line-tools.rst:39 +#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 +msgid "For example" msgstr "" -#: ../source/guides/installing-stand-alone-command-line-tools.rst:72 -msgid "To see a list of packages installed with pipx and which applications are available, use ``pipx list``:" +#: ../source/guides/installing-stand-alone-command-line-tools.rst:59 +msgid "To see a list of packages installed with pipx and which CLI applications are available, use ``pipx list``." msgstr "" -#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 -msgid "To upgrade or uninstall a package:" +#: ../source/guides/installing-stand-alone-command-line-tools.rst:79 +msgid "To upgrade or uninstall the package" msgstr "" -#: ../source/guides/installing-stand-alone-command-line-tools.rst:100 -msgid "pipx can be upgraded or uninstalled with pip:" +#: ../source/guides/installing-stand-alone-command-line-tools.rst:86 +msgid "``pipx`` can be upgraded or uninstalled with pip" msgstr "" -#: ../source/guides/installing-stand-alone-command-line-tools.rst:116 -msgid "pipx also allows you to install and run the latest version of an application in a temporary, ephemeral environment. For example:" +#: ../source/guides/installing-stand-alone-command-line-tools.rst:93 +msgid "``pipx`` also allows you to install and run the latest version of a cli tool in a temporary, ephemeral environment." msgstr "" -#: ../source/guides/installing-stand-alone-command-line-tools.rst:123 -msgid "To see the full list of commands pipx offers, run:" +#: ../source/guides/installing-stand-alone-command-line-tools.rst:106 +msgid "To see the full list of commands ``pipx`` offers, run" msgstr "" -#: ../source/guides/installing-stand-alone-command-line-tools.rst:129 -msgid "You can learn more about pipx at https://pypa.github.io/pipx/." +#: ../source/guides/installing-stand-alone-command-line-tools.rst:112 +msgid "You can learn more about ``pipx`` at its homepage, https://github.com/pypa/pipx." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:5 @@ -2649,110 +2553,140 @@ msgid "Installing pip/setuptools/wheel with Linux Package Managers" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:8 -msgid "2021-07-26" +msgid "2015-09-17" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:13 +#: ../source/guides/installing-using-linux-tools.rst:11 msgid "This section covers how to install :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` using Linux package managers." msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:16 +#: ../source/guides/installing-using-linux-tools.rst:14 msgid "If you're using a Python that was downloaded from `python.org `_, then this section does not apply. See the :ref:`installing_requirements` section instead." msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:20 +#: ../source/guides/installing-using-linux-tools.rst:18 msgid "Note that it's common for the versions of :ref:`pip`, :ref:`setuptools`, and :ref:`wheel` supported by a specific Linux Distribution to be outdated by the time it's released to the public, and updates generally only occur for security reasons, not for feature updates. For certain Distributions, there are additional repositories that can be enabled to provide newer versions. The repositories we know about are explained below." msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:27 +#: ../source/guides/installing-using-linux-tools.rst:25 msgid "Also note that it's somewhat common for Distributions to apply patches for the sake of security and normalization to their own standards. In some cases, this can lead to bugs or unexpected behaviors that vary from the original unpatched versions. When this is known, we will make note of it below." msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:34 +#: ../source/guides/installing-using-linux-tools.rst:32 msgid "Fedora" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:40 -msgid "To learn more about Python in Fedora, please visit the `official Fedora docs`_, `Python Classroom`_ or `Fedora Loves Python`_." +#: ../source/guides/installing-using-linux-tools.rst:34 +msgid "Fedora 21:" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:48 -msgid "CentOS/RHEL" +#: ../source/guides/installing-using-linux-tools.rst:36 +#: ../source/guides/installing-using-linux-tools.rst:45 +#: ../source/guides/installing-using-linux-tools.rst:124 +#: ../source/guides/installing-using-linux-tools.rst:138 +#: ../source/guides/installing-using-linux-tools.rst:158 +msgid "Python 2::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:41 +msgid "Python 3: ``sudo yum install python3 python3-wheel``" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:43 +msgid "Fedora 22:" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:50 -msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." +msgid "Python 3: ``sudo dnf install python3 python3-wheel``" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:53 -msgid "To install pip and wheel for the system Python, there are two options:" +msgid "To get newer versions of pip, setuptools, and wheel for Python 2, you can enable the `PyPA Copr Repo `_ using the `Copr Repo instructions `__, and then run::" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:55 -msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 7, you can install pip and wheel like so:" +#: ../source/guides/installing-using-linux-tools.rst:63 +msgid "CentOS/RHEL" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:64 -msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." +#: ../source/guides/installing-using-linux-tools.rst:65 +msgid "CentOS and RHEL don't offer :ref:`pip` or :ref:`wheel` in their core repositories, although :ref:`setuptools` is installed by default." msgstr "" #: ../source/guides/installing-using-linux-tools.rst:68 -msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so:" +msgid "To install pip and wheel for the system Python, there are two options:" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:70 +msgid "Enable the `EPEL repository `_ using `these instructions `__. On EPEL 6 and EPEL7, you can install pip like so::" msgstr "" #: ../source/guides/installing-using-linux-tools.rst:77 -msgid "To additionally upgrade setuptools, run:" +msgid "On EPEL 7 (but not EPEL 6), you can install wheel like so::" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:84 +#: ../source/guides/installing-using-linux-tools.rst:81 +msgid "Since EPEL only offers extra, non-conflicting packages, EPEL does not offer setuptools, since it's in the core repository." +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:85 +msgid "Enable the `PyPA Copr Repo `_ using `these instructions `__ [1]_. You can install pip and wheel like so::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:92 +msgid "To additionally upgrade setuptools, run::" +msgstr "" + +#: ../source/guides/installing-using-linux-tools.rst:97 msgid "To install pip, wheel, and setuptools, in a parallel, non-system environment (using yum) then there are two options:" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:88 +#: ../source/guides/installing-using-linux-tools.rst:101 msgid "Use the \"Software Collections\" feature to enable a parallel collection that includes pip, setuptools, and wheel." msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:91 +#: ../source/guides/installing-using-linux-tools.rst:104 msgid "For Redhat, see here: http://developers.redhat.com/products/softwarecollections/overview/" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:93 +#: ../source/guides/installing-using-linux-tools.rst:106 msgid "For CentOS, see here: https://www.softwarecollections.org/en/" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:95 +#: ../source/guides/installing-using-linux-tools.rst:108 msgid "Be aware that collections may not contain the most recent versions." msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:97 +#: ../source/guides/installing-using-linux-tools.rst:110 msgid "Enable the `IUS repository `_ and install one of the `parallel-installable `_ Pythons, along with pip, setuptools, and wheel, which are kept fairly up to date." msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:103 -msgid "For example, for Python 3.4 on CentOS7/RHEL7:" +#: ../source/guides/installing-using-linux-tools.rst:116 +msgid "For example, for Python 3.4 on CentOS7/RHEL7::" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:111 +#: ../source/guides/installing-using-linux-tools.rst:122 msgid "openSUSE" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:118 -msgid "Debian/Ubuntu" +#: ../source/guides/installing-using-linux-tools.rst:129 +#: ../source/guides/installing-using-linux-tools.rst:143 +#: ../source/guides/installing-using-linux-tools.rst:162 +msgid "Python 3::" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:120 -msgid "Firstly, update and refresh repository lists by running this command:" +#: ../source/guides/installing-using-linux-tools.rst:135 +msgid "Debian/Ubuntu" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:129 +#: ../source/guides/installing-using-linux-tools.rst:150 msgid "Recent Debian/Ubuntu versions have modified pip to use the `\"User Scheme\" `_ by default, which is a significant behavior change that can be surprising to some users." msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:135 +#: ../source/guides/installing-using-linux-tools.rst:156 msgid "Arch Linux" msgstr "" -#: ../source/guides/installing-using-linux-tools.rst:143 +#: ../source/guides/installing-using-linux-tools.rst:168 msgid "Currently, there is no \"copr\" yum plugin available for CentOS/RHEL, so the only option is to manually place the repo files as described." msgstr "" @@ -2777,216 +2711,212 @@ msgid ":ref:`pip` is the reference Python package manager. It's used to install msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:24 -msgid "Debian and most other distributions include a `python-pip`_ package; if you want to use the Linux distribution-provided versions of pip, see :doc:`/guides/installing-using-linux-tools`." +msgid "Debian and most other distributions include a `python-pip`_ package, if you want to use the Linux distribution-provided versions of pip see :doc:`/guides/installing-using-linux-tools`." msgstr "" #: ../source/guides/installing-using-pip-and-virtual-environments.rst:28 msgid "You can also install pip yourself to ensure you have the latest version. It's recommended to use the system pip to bootstrap a user installation of pip:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:37 -msgid "Afterwards, you should have the latest version of pip installed in your user site:" +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:35 +msgid "Afterwards, you should have the newest pip installed in your user site:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:48 -msgid "The Python installers for Windows include pip. You can make sure that pip is up-to-date by running:" +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:46 +msgid "The Python installers for Windows include pip. You should be able to access pip using:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:57 -msgid "Afterwards, you should have the latest version of pip:" +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:54 +msgid "You can make sure that pip is up-to-date by running:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:66 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:62 msgid "Installing virtualenv" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:68 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:64 msgid "If you are using Python 3.3 or newer, the :mod:`venv` module is the preferred way to create and manage virtual environments. venv is included in the Python standard library and requires no additional installation. If you are using venv, you may skip this section." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:74 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:70 msgid ":ref:`virtualenv` is used to manage Python packages for different projects. Using virtualenv allows you to avoid installing Python packages globally which could break system tools or other projects. You can install virtualenv using pip." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:95 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:91 msgid "Creating a virtual environment" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:97 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:93 msgid ":ref:`venv` (for Python 3) and :ref:`virtualenv` (for Python 2) allow you to manage separate package installations for different projects. They essentially allow you to create a \"virtual\" isolated Python installation and install packages into that virtual installation. When you switch projects, you can simply create a new virtual environment and not have to worry about breaking the packages installed in the other environments. It is always recommended to use a virtual environment while developing Python applications." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:106 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:102 msgid "To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace ``venv`` with ``virtualenv`` in the below commands." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:122 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:118 msgid "The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it ``env``." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:125 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:121 msgid "venv will create a virtual Python installation in the ``env`` folder." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:127 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:123 msgid "You should exclude your virtual environment directory from your version control system using ``.gitignore`` or similar." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:132 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:128 msgid "Activating a virtual environment" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:134 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:130 msgid "Before you can start installing or using packages in your virtual environment you'll need to *activate* it. Activating a virtual environment will put the virtual environment-specific ``python`` and ``pip`` executables into your shell's ``PATH``." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:151 -msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter:" -msgstr "" - -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:166 -msgid "It should be in the ``env`` directory:" +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:147 +msgid "You can confirm you're in the virtual environment by checking the location of your Python interpreter, it should point to the ``env`` directory." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:181 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:164 msgid "As long as your virtual environment is activated pip will install packages into that specific environment and you'll be able to import and use packages in your Python application." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:187 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:170 msgid "Leaving the virtual environment" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:189 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:172 msgid "If you want to switch projects or otherwise leave your virtual environment, simply run:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:195 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:178 msgid "If you want to re-enter the virtual environment just follow the same instructions above about activating a virtual environment. There's no need to re-create the virtual environment." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:183 msgid "Installing packages" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:202 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:185 msgid "Now that you're in your virtual environment you can install packages. Let's install the `Requests`_ library from the :term:`Python Package Index (PyPI)`:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:217 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:200 msgid "pip should download requests and all of its dependencies and install them:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:238 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:221 msgid "Installing specific versions" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:240 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:223 msgid "pip allows you to specify which version of a package to install using :term:`version specifiers `. For example, to install a specific version of ``requests``:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:256 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:239 msgid "To install the latest ``2.x`` release of requests:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:270 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:253 msgid "To install pre-release versions of packages, use the ``--pre`` flag:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:286 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:269 msgid "Installing extras" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:288 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:271 msgid "Some packages have optional `extras`_. You can tell pip to install these by specifying the extra in brackets:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:308 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:291 msgid "Installing from source" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:310 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:293 msgid "pip can install a package directly from source, for example:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:326 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:309 msgid "Additionally, pip can install packages from source in `development mode`_, meaning that changes to the source directory will immediately affect the installed package without needing to re-install:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:347 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:330 msgid "Installing from version control systems" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:349 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:332 msgid "pip can install packages directly from their version control system. For example, you can install directly from a git repository:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:356 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:339 msgid "For more information on supported version control systems and syntax, see pip's documentation on :ref:`VCS Support `." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 -#: ../source/tutorials/installing-packages.rst:577 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:344 +#: ../source/tutorials/installing-packages.rst:569 msgid "Installing from local archives" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:363 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:346 msgid "If you have a local copy of a :term:`Distribution Package`'s archive (a zip, wheel, or tar file) you can install it directly with pip:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:378 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:361 msgid "If you have a directory containing archives of multiple packages, you can tell pip to look for packages there and not to use the :term:`Python Package Index (PyPI)` at all:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:394 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:377 msgid "This is useful if you are installing packages on a system with limited connectivity or if you want to strictly control the origin of distribution packages." msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:383 msgid "Using other package indexes" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:402 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:385 msgid "If you want to download packages from a different index than the :term:`Python Package Index (PyPI)`, you can use the ``--index-url`` flag:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:400 msgid "If you want to allow packages from both the :term:`Python Package Index (PyPI)` and a separate index, you can use the ``--extra-index-url`` flag instead:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:434 -#: ../source/tutorials/installing-packages.rst:397 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:417 +#: ../source/tutorials/installing-packages.rst:389 msgid "Upgrading packages" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:436 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:419 msgid "pip can upgrade packages in-place using the ``--upgrade`` flag. For example, to install the latest version of ``requests`` and all of its dependencies:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:452 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:435 msgid "Using requirements files" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:454 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:437 msgid "Instead of installing packages individually, pip allows you to declare all dependencies in a :ref:`Requirements File `. For example you could create a :file:`requirements.txt` file containing:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:446 msgid "And tell pip to install all of the packages in this file using the ``-r`` flag:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:461 msgid "Freezing dependencies" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:480 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:463 msgid "Pip can export a list of all installed packages and their versions using the ``freeze`` command:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:495 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:478 msgid "Which will output a list of package specifiers such as:" msgstr "" -#: ../source/guides/installing-using-pip-and-virtual-environments.rst:511 +#: ../source/guides/installing-using-pip-and-virtual-environments.rst:494 msgid "This is useful for creating :ref:`pip:Requirements Files` that can re-create the exact versions of all packages installed in an environment." msgstr "" @@ -3103,10 +3033,10 @@ msgid "Build the sdist and wheel for your project as described under :ref:`Packa msgstr "" #: ../source/guides/making-a-pypi-friendly-readme.rst:125 -msgid "Run ``twine check`` on the sdist and wheel:" +msgid "Run ``twine check`` on the sdist and wheel::" msgstr "" -#: ../source/guides/making-a-pypi-friendly-readme.rst:131 +#: ../source/guides/making-a-pypi-friendly-readme.rst:129 msgid "This command will report any problems rendering your README. If your markup renders fine, the command will output ``Checking distribution FILENAME: Passed``." msgstr "" @@ -3436,74 +3366,124 @@ msgid "Binary extensions for Windows" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:258 -msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions. To set up a build environment for binary extensions, install `Visual Studio Community Edition `__ - any recent version is fine." +msgid "Before it is possible to build a binary extension, it is necessary to ensure that you have a suitable compiler available. On Windows, Visual C is used to build the official CPython interpreter, and should be used to build compatible binary extensions." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:263 +msgid "Python 2.7 used Visual Studio 2008, Python 3.3 and 3.4 used Visual Studio 2010, and Python 3.5+ uses Visual Studio 2015 or later. Unfortunately, older versions of Visual Studio are no longer easily available from Microsoft, so for versions of Python prior to 3.5, the compilers must be obtained differently if you do not already have a copy of the relevant version of Visual Studio." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:269 +msgid "To set up a build environment for binary extensions, the steps are as follows:" msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:265 -msgid "One caveat: if you use Visual Studio 2019 or later, your extension will depend on an \"extra\" file, ``VCRUNTIME140_1.dll``, in addition to the ``VCRUNTIME140.dll`` that all previous versions back to 2015 depend on. This will add an extra requirement to using your extension on versions of CPython that do not include this extra file. To avoid this, you can add the compile-time argument ``/d2FH4-``. Recent versions of Python may include this file." +#: ../source/guides/packaging-binary-extensions.rst:271 +msgid "For Python 2.7" msgstr "" #: ../source/guides/packaging-binary-extensions.rst:273 -msgid "Building for Python prior to 3.5 is discouraged, because older versions of Visual Studio are no longer available from Microsoft. If you do need to build for older versions, you can set ``DISTUTILS_USE_SDK=1`` and ``MSSdk=1`` to force a the currently activated version of MSVC to be found, and you should exercise care when designing your extension not to malloc/free memory across different libraries, avoid relying on changed data structures, and so on. Tools for generating extension modules usually avoid these things for you." +msgid "Install \"Visual C++ Compiler Package for Python 2.7\", which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:276 +msgid "Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:278 +#: ../source/guides/packaging-binary-extensions.rst:288 +#: ../source/guides/packaging-binary-extensions.rst:295 +msgid "Done." msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:284 +#: ../source/guides/packaging-binary-extensions.rst:280 +msgid "For Python 3.4" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:282 +msgid "Install \"Windows SDK for Windows 7 and .NET Framework 4\" (v7.1), which is available from `Microsoft's website `__." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:285 +msgid "Work from an SDK command prompt (with the environment variables set, and the SDK on PATH)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:287 +msgid "Set DISTUTILS_USE_SDK=1" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:290 +msgid "For Python 3.5" +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:292 +msgid "Install `Visual Studio 2015 Community Edition `__ (or any later version, when these are released)." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:297 +msgid "Note that from Python 3.5 onwards, Visual Studio works in a backward compatible way, which means that any future version of Visual Studio will be able to build Python extensions for all Python versions from 3.5 onwards." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:301 +msgid "Building with the recommended compiler on Windows ensures that a compatible C library is used throughout the Python process." +msgstr "" + +#: ../source/guides/packaging-binary-extensions.rst:305 msgid "Binary extensions for Linux" msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:286 +#: ../source/guides/packaging-binary-extensions.rst:307 msgid "Linux binaries must use a sufficiently old glibc to be compatible with older distributions. The `manylinux `_ Docker images provide a build environment with a glibc old enough to support most current Linux distributions on common architectures." msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:292 +#: ../source/guides/packaging-binary-extensions.rst:313 msgid "Binary extensions for macOS" msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:294 +#: ../source/guides/packaging-binary-extensions.rst:315 msgid "Binary compatibility on macOS is determined by the target minimum deployment system, e.g. *10.9*, which is often specified with the ``MACOSX_DEPLOYMENT_TARGET`` environmental variable when building binaries on macOS. When building with setuptools / distutils, the deployment target is specified with the flag ``--plat-name``, e.g. ``macosx-10.9-x86_64``. For common deployment targets for macOS Python distributions, see the `MacPython Spinning Wheels wiki `_." msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:304 +#: ../source/guides/packaging-binary-extensions.rst:325 msgid "Publishing binary extensions" msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:306 +#: ../source/guides/packaging-binary-extensions.rst:327 msgid "For interim guidance on this topic, see the discussion in `this issue `_." msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:322 +#: ../source/guides/packaging-binary-extensions.rst:343 msgid "Additional resources" msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:324 +#: ../source/guides/packaging-binary-extensions.rst:345 msgid "Cross-platform development and distribution of extension modules is a complex topic, so this guide focuses primarily on providing pointers to various tools that automate dealing with the underlying technical challenges. The additional resources in this section are instead intended for developers looking to understand more about the underlying binary interfaces that those systems rely on at runtime." msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:331 +#: ../source/guides/packaging-binary-extensions.rst:352 msgid "Cross-platform wheel generation with scikit-build" msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:333 +#: ../source/guides/packaging-binary-extensions.rst:354 msgid "The `scikit-build `_ package helps abstract cross-platform build operations and provides additional capabilities when creating binary extension packages. Additional documentation is also available on the `C runtime, compiler, and build system generator `_ for Python binary extension modules." msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:341 +#: ../source/guides/packaging-binary-extensions.rst:362 msgid "Introduction to C/C++ extension modules" msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:343 +#: ../source/guides/packaging-binary-extensions.rst:364 msgid "For a more in depth explanation of how extension modules are used by CPython on a Debian system, see the following articles:" msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:346 +#: ../source/guides/packaging-binary-extensions.rst:367 msgid "`What are (c)python extension modules? `_" msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:347 +#: ../source/guides/packaging-binary-extensions.rst:368 msgid "`Releasing the gil `_" msgstr "" -#: ../source/guides/packaging-binary-extensions.rst:348 +#: ../source/guides/packaging-binary-extensions.rst:369 msgid "`Writing cpython extension modules using C++ `_" msgstr "" @@ -4186,58 +4166,54 @@ msgid "Packaging tool recommendations" msgstr "" #: ../source/guides/tool-recommendations.rst:49 -msgid "Use :ref:`setuptools` to define projects. [5]_ [6]_" +msgid "Use :ref:`setuptools` to define projects and create :term:`Source Distributions `. [5]_ [6]_" msgstr "" -#: ../source/guides/tool-recommendations.rst:51 -msgid "Use :ref:`build` to create :term:`Source Distributions ` and :term:`wheels `." +#: ../source/guides/tool-recommendations.rst:52 +msgid "Use the ``bdist_wheel`` :ref:`setuptools` extension available from the :ref:`wheel project ` to create :term:`wheels `. This is especially beneficial, if your project contains binary extensions." msgstr "" -#: ../source/guides/tool-recommendations.rst:54 -msgid "If you have binary extensions and want to distribute wheels for multiple platforms, use :ref:`cibuildwheel` as part of your CI setup to build distributable wheels." -msgstr "" - -#: ../source/guides/tool-recommendations.rst:58 +#: ../source/guides/tool-recommendations.rst:56 msgid "Use `twine `_ for uploading distributions to :term:`PyPI `." msgstr "" -#: ../source/guides/tool-recommendations.rst:63 +#: ../source/guides/tool-recommendations.rst:61 msgid "Publishing platform migration" msgstr "" -#: ../source/guides/tool-recommendations.rst:65 +#: ../source/guides/tool-recommendations.rst:63 msgid "The original Python Package Index implementation (previously hosted at `pypi.python.org `_) has been phased out in favour of an updated implementation hosted at `pypi.org `_." msgstr "" -#: ../source/guides/tool-recommendations.rst:69 +#: ../source/guides/tool-recommendations.rst:67 msgid "See :ref:`Migrating to PyPI.org` for more information on the status of the migration, and what settings to change in your clients." msgstr "" -#: ../source/guides/tool-recommendations.rst:74 +#: ../source/guides/tool-recommendations.rst:72 msgid "There are some cases where you might choose to use ``easy_install`` (from :ref:`setuptools`), e.g. if you need to install from :term:`Eggs ` (which pip doesn't support). For a detailed breakdown, see :ref:`pip vs easy_install`." msgstr "" -#: ../source/guides/tool-recommendations.rst:79 +#: ../source/guides/tool-recommendations.rst:77 msgid "The acceptance of :pep:`453` means that :ref:`pip` will be available by default in most installations of Python 3.4 or later. See the :pep:`rationale section <453#rationale>` from :pep:`453` as for why pip was chosen." msgstr "" -#: ../source/guides/tool-recommendations.rst:84 +#: ../source/guides/tool-recommendations.rst:82 msgid "`get-pip.py `_ and :ref:`virtualenv` install :ref:`wheel`, whereas :ref:`ensurepip` and :ref:`venv ` do not currently. Also, the common \"python-pip\" package that's found in various linux distros, does not depend on \"python-wheel\" currently." msgstr "" -#: ../source/guides/tool-recommendations.rst:90 +#: ../source/guides/tool-recommendations.rst:88 msgid "Beginning with Python 3.4, ``venv`` will create virtualenv environments with ``pip`` installed, thereby making it an equal alternative to :ref:`virtualenv`. However, using :ref:`virtualenv` will still be recommended for users that need cross-version consistency." msgstr "" -#: ../source/guides/tool-recommendations.rst:95 +#: ../source/guides/tool-recommendations.rst:93 msgid "Although you can use pure ``distutils`` for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating distribution metadata correctly that are provided by ``setuptools``. Being outside the standard library, ``setuptools`` also offers a more consistent feature set across different versions of Python, and (unlike ``distutils``), recent versions of ``setuptools`` support all of the modern metadata fields described in :ref:`core-metadata`." msgstr "" -#: ../source/guides/tool-recommendations.rst:104 +#: ../source/guides/tool-recommendations.rst:102 msgid "Even for projects that do choose to use ``distutils``, when :ref:`pip` installs such projects directly from source (rather than installing from a prebuilt :term:`wheel ` file), it will actually build your project using :ref:`setuptools` instead." msgstr "" -#: ../source/guides/tool-recommendations.rst:109 +#: ../source/guides/tool-recommendations.rst:107 msgid "`distribute`_ (a fork of setuptools) was merged back into :ref:`setuptools` in June 2013, thereby making setuptools the default choice for packaging." msgstr "" @@ -4418,10 +4394,10 @@ msgid "File & directory names in :file:`MANIFEST.in` should be ``/``-separated; msgstr "" #: ../source/guides/using-manifest-in.rst:95 -msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands:" +msgid "Commands are processed in the order they appear in the :file:`MANIFEST.in` file. For example, given the commands::" msgstr "" -#: ../source/guides/using-manifest-in.rst:103 +#: ../source/guides/using-manifest-in.rst:101 msgid "the contents of the directory tree :file:`tests` will first be added to the sdist, and then after that all files in the sdist with a ``.pyc``, ``.pyo``, or ``.pyd`` extension will be removed from the sdist. If the commands were in the opposite order, then ``*.pyc`` files etc. would be only be removed from what was already in the sdist before adding :file:`tests`, and if :file:`tests` happened to contain any ``*.pyc`` files, they would end up included in the sdist because the exclusion happened before they were included." msgstr "" @@ -4434,7 +4410,7 @@ msgid "Registering your account" msgstr "" #: ../source/guides/using-testpypi.rst:15 -msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." +msgid "Because TestPyPI has a separate database from the live PyPI, you'll need a separate user account for specifically for TestPyPI. Go to https://test.pypi.org/account/register/ to register your account." msgstr "" #: ../source/guides/using-testpypi.rst:19 @@ -4446,7 +4422,7 @@ msgid "Using TestPyPI with Twine" msgstr "" #: ../source/guides/using-testpypi.rst:26 -msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag:" +msgid "You can upload your distributions to TestPyPI using :ref:`twine` by specifying the ``--repository`` flag" msgstr "" #: ../source/guides/using-testpypi.rst:33 @@ -4458,11 +4434,11 @@ msgid "Using TestPyPI with pip" msgstr "" #: ../source/guides/using-testpypi.rst:41 -msgid "You can tell :ref:`pip` to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag:" +msgid "You can tell pip to download packages from TestPyPI instead of PyPI by specifying the ``--index-url`` flag" msgstr "" #: ../source/guides/using-testpypi.rst:56 -msgid "If you want to allow pip to also download packages from PyPI, you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" +msgid "If you want to allow pip to also pull other packages from PyPI you can specify ``--extra-index-url`` to point to PyPI. This is useful when the package you're testing has dependencies:" msgstr "" #: ../source/guides/using-testpypi.rst:73 @@ -4793,258 +4769,274 @@ msgid "Non-PyPA Projects" msgstr "" #: ../source/key_projects.rst:329 -msgid "buildout" +msgid "bento" msgstr "" #: ../source/key_projects.rst:331 -msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" +msgid "`Docs `__ | `Issues `__ | `GitHub `__ | `PyPI `__" msgstr "" #: ../source/key_projects.rst:336 +msgid "Bento is a packaging tool solution for Python software, targeted as an alternative to :ref:`distutils`, :ref:`setuptools`, etc.... Bento's philosophy is reproducibility, extensibility and simplicity (in that order)." +msgstr "" + +#: ../source/key_projects.rst:344 +msgid "buildout" +msgstr "" + +#: ../source/key_projects.rst:346 +msgid "`Docs `__ | `Issues `__ | `PyPI `__ | `GitHub `__" +msgstr "" + +#: ../source/key_projects.rst:351 msgid "Buildout is a Python-based build system for creating, assembling and deploying applications from multiple parts, some of which may be non-Python-based. It lets you create a buildout configuration and reproduce the same software later." msgstr "" -#: ../source/key_projects.rst:343 +#: ../source/key_projects.rst:358 msgid "conda" msgstr "" -#: ../source/key_projects.rst:345 +#: ../source/key_projects.rst:360 msgid "`Docs `__" msgstr "" -#: ../source/key_projects.rst:347 +#: ../source/key_projects.rst:362 msgid "conda is the package management tool for `Anaconda `__ Python installations. Anaconda Python is a distribution from `Anaconda, Inc `__ specifically aimed at the scientific community, and in particular on Windows where the installation of binary extensions is often difficult." msgstr "" -#: ../source/key_projects.rst:354 +#: ../source/key_projects.rst:369 msgid "Conda is a completely separate tool from :ref:`pip`, virtualenv and wheel, but provides many of their combined features in terms of package management, virtual environment management and deployment of binary extensions." msgstr "" -#: ../source/key_projects.rst:358 +#: ../source/key_projects.rst:373 msgid "Conda does not install packages from PyPI and can install only from the official Anaconda repositories, or anaconda.org (a place for user-contributed *conda* packages), or a local (e.g. intranet) package server. However, note that :ref:`pip` can be installed into, and work side-by-side with conda for managing :term:`distributions ` from PyPI. Also, `conda skeleton `__ is a tool to make Python packages installable by conda by first fetching them from PyPI and modifying their metadata." msgstr "" -#: ../source/key_projects.rst:371 +#: ../source/key_projects.rst:386 msgid "devpi" msgstr "" -#: ../source/key_projects.rst:373 +#: ../source/key_projects.rst:388 msgid "`Docs `__ | `Issues `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:377 +#: ../source/key_projects.rst:392 msgid "devpi features a powerful PyPI-compatible server and PyPI proxy cache with a complementary command line tool to drive packaging, testing and release activities with Python. devpi also provides a browsable and searchable web interface." msgstr "" -#: ../source/key_projects.rst:386 +#: ../source/key_projects.rst:401 msgid "flit" msgstr "" -#: ../source/key_projects.rst:388 +#: ../source/key_projects.rst:403 msgid "`Docs `__ | `Issues `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:392 +#: ../source/key_projects.rst:407 msgid "Flit provides a simple way to upload pure Python packages and modules to PyPI. It focuses on `making the easy things easy `_ for packaging. Flit can generate a configuration file to quickly set up a simple project, build source distributions and wheels, and upload them to PyPI." msgstr "" -#: ../source/key_projects.rst:397 +#: ../source/key_projects.rst:412 msgid "Flit uses ``pyproject.toml`` to configure a project. Flit does not rely on tools such as :ref:`setuptools` to build distributions, or :ref:`twine` to upload them to PyPI. Flit requires Python 3, but you can use it to distribute modules for Python 2, so long as they can be imported on Python 3." msgstr "" -#: ../source/key_projects.rst:407 +#: ../source/key_projects.rst:422 msgid "enscons" msgstr "" -#: ../source/key_projects.rst:409 +#: ../source/key_projects.rst:424 msgid "`Source `__ | `Issues `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:413 +#: ../source/key_projects.rst:428 msgid "Enscons is a Python packaging tool based on `SCons`_. It builds :ref:`pip`-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than :ref:`distutils`. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system. Enscons helps you to build sdists that can be automatically built by :ref:`pip`, and wheels that are independent of enscons." msgstr "" -#: ../source/key_projects.rst:428 +#: ../source/key_projects.rst:443 msgid "Hashdist" msgstr "" -#: ../source/key_projects.rst:430 +#: ../source/key_projects.rst:445 msgid "`Docs `__ | `GitHub `__" msgstr "" -#: ../source/key_projects.rst:433 +#: ../source/key_projects.rst:448 msgid "Hashdist is a library for building non-root software distributions. Hashdist is trying to be “the Debian of choice for cases where Debian technology doesn’t work”. The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of :ref:`virtualenv` and :ref:`buildout`. It is aimed at solving the problem of installing scientific software, and making package distribution stateless, cached, and branchable. It is used by some researchers but has been lacking in maintenance since 2016." msgstr "" -#: ../source/key_projects.rst:445 +#: ../source/key_projects.rst:460 msgid "hatch" msgstr "" -#: ../source/key_projects.rst:447 +#: ../source/key_projects.rst:462 msgid "`GitHub and Docs `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:450 +#: ../source/key_projects.rst:465 msgid "Hatch is a unified command-line tool meant to conveniently manage dependencies and environment isolation for Python developers. Python package developers use Hatch to configure, version, specify dependencies for, and publish packages to PyPI. Under the hood, it uses :ref:`twine` to upload packages to PyPI, and :ref:`pip` to download and install packages." msgstr "" -#: ../source/key_projects.rst:460 +#: ../source/key_projects.rst:475 msgid "multibuild" msgstr "" -#: ../source/key_projects.rst:462 +#: ../source/key_projects.rst:477 msgid "`GitHub `__" msgstr "" -#: ../source/key_projects.rst:464 +#: ../source/key_projects.rst:479 msgid "Multibuild is a set of CI scripts for building and testing Python :term:`wheels ` for Linux, macOS, and (less flexibly) Windows. Also see :ref:`cibuildwheel`." msgstr "" -#: ../source/key_projects.rst:472 +#: ../source/key_projects.rst:485 +msgid "pex" +msgstr "" + +#: ../source/key_projects.rst:487 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:476 +#: ../source/key_projects.rst:491 msgid "pex is both a library and tool for generating :file:`.pex` (Python EXecutable) files, standalone Python environments in the spirit of :ref:`virtualenv`. :file:`.pex` files are just carefully constructed zip files with a ``#!/usr/bin/env python`` and special :file:`__main__.py`, and are designed to make deployment of Python applications as simple as ``cp``." msgstr "" -#: ../source/key_projects.rst:485 +#: ../source/key_projects.rst:500 msgid "pip-tools" msgstr "" -#: ../source/key_projects.rst:487 +#: ../source/key_projects.rst:502 msgid "`GitHub and Docs `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:490 +#: ../source/key_projects.rst:505 msgid "pip-tools is a suite of tools meant for Python system administrators and release managers who particularly want to keep their builds deterministic yet stay up to date with new versions of their dependencies. Users can specify particular release of their dependencies via hash, conveniently make a properly formatted list of requirements from information in other parts of their program, update all dependencies (a feature :ref:`pip` currently does not provide), and create layers of constraints for the program to obey." msgstr "" -#: ../source/key_projects.rst:502 +#: ../source/key_projects.rst:517 msgid "piwheels" msgstr "" -#: ../source/key_projects.rst:504 +#: ../source/key_projects.rst:519 msgid "`Website `__ | `Docs `__ | `GitHub `__" msgstr "" -#: ../source/key_projects.rst:508 +#: ../source/key_projects.rst:523 msgid "piwheels is a website, and software underpinning it, that fetches source code distribution packages from PyPI and compiles them into binary wheels that are optimized for installation onto Raspberry Pi computers. Raspberry Pi OS pre-configures pip to use piwheels.org as an additional index to PyPI." msgstr "" -#: ../source/key_projects.rst:517 +#: ../source/key_projects.rst:532 msgid "poetry" msgstr "" -#: ../source/key_projects.rst:519 +#: ../source/key_projects.rst:534 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:523 +#: ../source/key_projects.rst:538 msgid "poetry is a command-line tool to handle dependency installation and isolation as well as building and packaging of Python packages. It uses ``pyproject.toml`` and, instead of depending on the resolver functionality within :ref:`pip`, provides its own dependency resolver. It attempts to speed users' experience of installation and dependency resolution by locally caching metadata about dependencies." msgstr "" -#: ../source/key_projects.rst:533 +#: ../source/key_projects.rst:548 msgid "pypiserver" msgstr "" -#: ../source/key_projects.rst:535 +#: ../source/key_projects.rst:550 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:539 +#: ../source/key_projects.rst:554 msgid "pypiserver is a minimalist application that serves as a private Python package index within organizations, implementing a simple API and browser interface. You can upload private packages using standard upload tools, and users can download and install them with :ref:`pip`, without publishing them publicly. Organizations who use pypiserver usually download packages both from pypiserver and from PyPI." msgstr "" -#: ../source/key_projects.rst:549 +#: ../source/key_projects.rst:564 msgid "scikit-build" msgstr "" -#: ../source/key_projects.rst:551 +#: ../source/key_projects.rst:566 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:555 +#: ../source/key_projects.rst:570 msgid "Scikit-build is an improved build system generator for CPython C/C++/Fortran/Cython extensions that integrates with :ref:`setuptools`, :ref:`wheel` and :ref:`pip`. It internally uses `cmake `__ (available on PyPI) to provide better support for additional compilers, build systems, cross compilation, and locating dependencies and their associated build requirements. To speed up and parallelize the build of large projects, the user can install `ninja `__ (also available on PyPI)." msgstr "" -#: ../source/key_projects.rst:567 +#: ../source/key_projects.rst:582 msgid "shiv" msgstr "" -#: ../source/key_projects.rst:569 +#: ../source/key_projects.rst:584 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:573 +#: ../source/key_projects.rst:588 msgid "shiv is a command line utility for building fully self contained Python zipapps as outlined in :pep:`441`, but with all their dependencies included. Its primary goal is making distributing Python applications and command line tools fast & easy." msgstr "" -#: ../source/key_projects.rst:583 +#: ../source/key_projects.rst:598 msgid "`Docs `__ | `GitHub `__ | `Paper `__ | `Slides `__" msgstr "" -#: ../source/key_projects.rst:588 +#: ../source/key_projects.rst:603 msgid "A flexible package manager designed to support multiple versions, configurations, platforms, and compilers. Spack is like Homebrew, but packages are written in Python and parameterized to allow easy swapping of compilers, library versions, build options, etc. Arbitrarily many versions of packages can coexist on the same system. Spack was designed for rapidly building high performance scientific applications on clusters and supercomputers." msgstr "" -#: ../source/key_projects.rst:596 +#: ../source/key_projects.rst:611 msgid "Spack is not in PyPI (yet), but it requires no installation and can be used immediately after cloning from GitHub." msgstr "" -#: ../source/key_projects.rst:602 +#: ../source/key_projects.rst:617 msgid "zest.releaser" msgstr "" -#: ../source/key_projects.rst:604 +#: ../source/key_projects.rst:619 msgid "`Docs `__ | `GitHub `__ | `PyPI `__" msgstr "" -#: ../source/key_projects.rst:608 +#: ../source/key_projects.rst:623 msgid "``zest.releaser`` is a Python package release tool providing an abstraction layer on top of :ref:`twine`. Python developers use ``zest.releaser`` to automate incrementing package version numbers, updating changelogs, tagging releases in source control, and uploading new packages to PyPI." msgstr "" -#: ../source/key_projects.rst:615 +#: ../source/key_projects.rst:630 msgid "Standard Library Projects" msgstr "" -#: ../source/key_projects.rst:620 +#: ../source/key_projects.rst:635 msgid "ensurepip" msgstr "" -#: ../source/key_projects.rst:622 +#: ../source/key_projects.rst:637 msgid "`Docs `__ | `Issues `__" msgstr "" -#: ../source/key_projects.rst:625 +#: ../source/key_projects.rst:640 msgid "A package in the Python Standard Library that provides support for bootstrapping :ref:`pip` into an existing Python installation or virtual environment. In most cases, end users won't use this module, but rather it will be used during the build of the Python distribution." msgstr "" -#: ../source/key_projects.rst:634 +#: ../source/key_projects.rst:649 msgid "distutils" msgstr "" -#: ../source/key_projects.rst:636 +#: ../source/key_projects.rst:651 msgid "`Docs `__ | `Issues `__" msgstr "" -#: ../source/key_projects.rst:639 +#: ../source/key_projects.rst:654 msgid "The original Python packaging system, added to the standard library in Python 2.0." msgstr "" -#: ../source/key_projects.rst:642 +#: ../source/key_projects.rst:657 msgid "Due to the challenges of maintaining a packaging system where feature updates are tightly coupled to language runtime updates, direct usage of :ref:`distutils` is now actively discouraged, with :ref:`Setuptools` being the preferred replacement. :ref:`Setuptools` not only provides features that plain :ref:`distutils` doesn't offer (such as dependency declarations and entry point declarations), it also provides a consistent build interface and feature set across all supported Python versions." msgstr "" -#: ../source/key_projects.rst:655 +#: ../source/key_projects.rst:670 msgid "venv" msgstr "" -#: ../source/key_projects.rst:657 +#: ../source/key_projects.rst:672 msgid "`Docs `__ | `Issues `__" msgstr "" -#: ../source/key_projects.rst:660 +#: ../source/key_projects.rst:675 msgid "A package in the Python Standard Library (starting with Python 3.3) for creating :term:`Virtual Environments `. For more information, see the section on :ref:`Creating and using Virtual Environments`." msgstr "" @@ -5740,10 +5732,6 @@ msgstr "" msgid "Python and PyPI make it easy to upload both wheels and sdists together. Just follow the :doc:`tutorials/packaging-projects` tutorial." msgstr "" -#: ../source/overview.rst:148 -msgid "A summary of Python's packaging capabilities for tools and libraries." -msgstr "" - #: ../source/overview.rst:148 msgid "Python's recommended built-in library and tool packaging technologies. Excerpted from `The Packaging Gradient (2017) `_." msgstr "" @@ -6056,10 +6044,6 @@ msgstr "" msgid "Embed your code on an `Adafruit `_, `MicroPython `_, or more-powerful hardware running Python, then ship it to the datacenter or your users' homes. They plug and play, and you can call it a day." msgstr "" -#: ../source/overview.rst:389 -msgid "A summary of technologies used to package Python applications." -msgstr "" - #: ../source/overview.rst:389 msgid "The simplified gamut of technologies used to package Python applications." msgstr "" @@ -6268,10 +6252,6 @@ msgstr "" msgid "Distribution name, e.g. 'django', 'pyramid'." msgstr "" -#: ../source/specifications/binary-distribution-format.rst:127 -msgid "version" -msgstr "" - #: ../source/specifications/binary-distribution-format.rst:127 msgid "Distribution version, e.g. 1.0." msgstr "" @@ -7186,10 +7166,20 @@ msgstr "" msgid "The only fields required to be statically defined are:" msgstr "" +#: ../source/specifications/declaring-project-metadata.rst:29 +#: ../source/specifications/declaring-project-metadata.rst:41 +msgid "``name``" +msgstr "" + #: ../source/specifications/declaring-project-metadata.rst:31 msgid "The fields which are required but may be specified *either* statically or listed as dynamic are:" msgstr "" +#: ../source/specifications/declaring-project-metadata.rst:34 +#: ../source/specifications/declaring-project-metadata.rst:54 +msgid "``version``" +msgstr "" + #: ../source/specifications/declaring-project-metadata.rst:36 msgid "All other fields are considered optional and my be specified statically, listed as dynamic, or left unspecified." msgstr "" @@ -7225,6 +7215,10 @@ msgstr "" msgid "Users SHOULD prefer to specify already-normalized versions." msgstr "" +#: ../source/specifications/declaring-project-metadata.rst:66 +msgid "``description``" +msgstr "" + #: ../source/specifications/declaring-project-metadata.rst:69 msgid "Corresponding :ref:`core metadata ` field: :ref:`Summary `" msgstr "" @@ -7273,6 +7267,10 @@ msgstr "" msgid "The Python version requirements of the project." msgstr "" +#: ../source/specifications/declaring-project-metadata.rst:125 +msgid "``license``" +msgstr "" + #: ../source/specifications/declaring-project-metadata.rst:127 msgid "TOML_ type: table" msgstr "" @@ -7329,6 +7327,10 @@ msgstr "" msgid "Multiple values should be separated by commas." msgstr "" +#: ../source/specifications/declaring-project-metadata.rst:181 +msgid "``keywords``" +msgstr "" + #: ../source/specifications/declaring-project-metadata.rst:183 #: ../source/specifications/declaring-project-metadata.rst:193 msgid "TOML_ type: array of strings" @@ -7342,6 +7344,10 @@ msgstr "" msgid "The keywords for the project." msgstr "" +#: ../source/specifications/declaring-project-metadata.rst:191 +msgid "``classifiers``" +msgstr "" + #: ../source/specifications/declaring-project-metadata.rst:194 msgid "Corresponding :ref:`core metadata ` field: :ref:`Classifier `" msgstr "" @@ -8315,38 +8321,30 @@ msgid "Source distributions are also known as *sdists* for short." msgstr "" #: ../source/specifications/source-distribution-format.rst:24 -msgid "Source trees" -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:26 -msgid "A *source tree* is a collection of files and directories -- like a version control system checkout -- which contains a :file:`pyproject.toml` file that can be use to build a source distribution from the contained files and directories. :pep:`517` and :pep:`518` specify what is required to meet the definition of what :file:`pyproject.toml` must contain for something to be deemed a source tree." -msgstr "" - -#: ../source/specifications/source-distribution-format.rst:34 msgid "Source distribution file name" msgstr "" -#: ../source/specifications/source-distribution-format.rst:36 +#: ../source/specifications/source-distribution-format.rst:26 msgid "The file name of a sdist is not currently standardised, although the *de facto* form is ``{name}-{version}.tar.gz``, where ``{name}`` is the canonicalized form of the project name (see :pep:`503` for the canonicalization rules) with ``-`` characters replaced with ``_``, and ``{version}`` is the project version." msgstr "" -#: ../source/specifications/source-distribution-format.rst:41 +#: ../source/specifications/source-distribution-format.rst:31 msgid "The name and version components of the filename MUST match the values stored in the metadata contained in the file." msgstr "" -#: ../source/specifications/source-distribution-format.rst:45 +#: ../source/specifications/source-distribution-format.rst:35 msgid "Source distribution file format" msgstr "" -#: ../source/specifications/source-distribution-format.rst:47 +#: ../source/specifications/source-distribution-format.rst:37 msgid "A ``.tar.gz`` source distribution (sdist) contains a single top-level directory called ``{name}-{version}`` (e.g. ``foo-1.0``), containing the source files of the package. The name and version MUST match the metadata stored in the file. This directory must also contain a :file:`pyproject.toml` in the format defined in :ref:`declaring-build-dependencies`, and a ``PKG-INFO`` file containing metadata in the format described in the :ref:`core-metadata` specification. The metadata MUST conform to at least version 2.2 of the metadata specification." msgstr "" -#: ../source/specifications/source-distribution-format.rst:55 +#: ../source/specifications/source-distribution-format.rst:45 msgid "No other content of a sdist is required or defined. Build systems can store whatever information they need in the sdist to build the project." msgstr "" -#: ../source/specifications/source-distribution-format.rst:58 +#: ../source/specifications/source-distribution-format.rst:48 msgid "The tarball should use the modern POSIX.1-2001 pax tar format, which specifies UTF-8 based file names." msgstr "" @@ -8371,7 +8369,7 @@ msgid "For support related to a specific project, see the links on the :doc:`Pro msgstr "" #: ../source/support.rst:8 -msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." +msgid "For something more general, or when you're just not sure, please `open an issue `_ on the `packaging-problems `_ repository on GitHub." msgstr "" #: ../source/tutorials/creating-documentation.rst:5 @@ -8519,246 +8517,246 @@ msgid "Ensure pip, setuptools, and wheel are up to date" msgstr "" #: ../source/tutorials/installing-packages.rst:161 -msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives:" +msgid "While ``pip`` alone is sufficient to install from pre-built binary archives, up to date copies of the ``setuptools`` and ``wheel`` projects are useful to ensure you can also install from source archives::" msgstr "" -#: ../source/tutorials/installing-packages.rst:178 +#: ../source/tutorials/installing-packages.rst:169 msgid "Optionally, create a virtual environment" msgstr "" -#: ../source/tutorials/installing-packages.rst:180 +#: ../source/tutorials/installing-packages.rst:171 msgid "See :ref:`section below ` for details, but here's the basic `venv`_ [3]_ command to use on a typical Linux system:" msgstr "" -#: ../source/tutorials/installing-packages.rst:197 +#: ../source/tutorials/installing-packages.rst:188 msgid "This will create a new virtual environment in the ``tutorial_env`` subdirectory, and configure the current shell to use it as the default ``python`` environment." msgstr "" -#: ../source/tutorials/installing-packages.rst:204 +#: ../source/tutorials/installing-packages.rst:195 msgid "Creating Virtual Environments" msgstr "" -#: ../source/tutorials/installing-packages.rst:206 +#: ../source/tutorials/installing-packages.rst:197 msgid "Python \"Virtual Environments\" allow Python :term:`packages ` to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see :doc:`/guides/installing-stand-alone-command-line-tools`." msgstr "" -#: ../source/tutorials/installing-packages.rst:212 +#: ../source/tutorials/installing-packages.rst:203 msgid "Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded." msgstr "" -#: ../source/tutorials/installing-packages.rst:218 +#: ../source/tutorials/installing-packages.rst:209 msgid "Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application." msgstr "" -#: ../source/tutorials/installing-packages.rst:222 +#: ../source/tutorials/installing-packages.rst:213 msgid "Also, what if you can’t install :term:`packages ` into the global site-packages directory? For instance, on a shared host." msgstr "" -#: ../source/tutorials/installing-packages.rst:225 +#: ../source/tutorials/installing-packages.rst:216 msgid "In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments." msgstr "" -#: ../source/tutorials/installing-packages.rst:229 +#: ../source/tutorials/installing-packages.rst:220 msgid "Currently, there are two common tools for creating Python virtual environments:" msgstr "" -#: ../source/tutorials/installing-packages.rst:231 +#: ../source/tutorials/installing-packages.rst:222 msgid "`venv`_ is available by default in Python 3.3 and later, and installs :ref:`pip` and :ref:`setuptools` into created virtual environments in Python 3.4 and later." msgstr "" -#: ../source/tutorials/installing-packages.rst:234 +#: ../source/tutorials/installing-packages.rst:225 msgid ":ref:`virtualenv` needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and :ref:`pip`, :ref:`setuptools` and :ref:`wheel` are always installed into created virtual environments by default (regardless of Python version)." msgstr "" -#: ../source/tutorials/installing-packages.rst:239 +#: ../source/tutorials/installing-packages.rst:230 msgid "The basic usage is like so:" msgstr "" -#: ../source/tutorials/installing-packages.rst:241 +#: ../source/tutorials/installing-packages.rst:232 msgid "Using `venv`_:" msgstr "" -#: ../source/tutorials/installing-packages.rst:257 +#: ../source/tutorials/installing-packages.rst:248 msgid "Using :ref:`virtualenv`:" msgstr "" -#: ../source/tutorials/installing-packages.rst:273 +#: ../source/tutorials/installing-packages.rst:264 msgid "For more information, see the `venv`_ docs or the `virtualenv `_ docs." msgstr "" -#: ../source/tutorials/installing-packages.rst:275 +#: ../source/tutorials/installing-packages.rst:266 msgid "The use of :command:`source` under Unix shells ensures that the virtual environment's variables are set within the current shell, and not in a subprocess (which then disappears, having no useful effect)." msgstr "" -#: ../source/tutorials/installing-packages.rst:280 +#: ../source/tutorials/installing-packages.rst:271 msgid "In both of the above cases, Windows users should _not_ use the :command:`source` command, but should rather run the :command:`activate` script directly from the command shell like so:" msgstr "" -#: ../source/tutorials/installing-packages.rst:290 +#: ../source/tutorials/installing-packages.rst:281 msgid "Managing multiple virtual environments directly can become tedious, so the :ref:`dependency management tutorial ` introduces a higher level tool, :ref:`Pipenv`, that automatically manages a separate virtual environment for each project and application that you work on." msgstr "" -#: ../source/tutorials/installing-packages.rst:297 +#: ../source/tutorials/installing-packages.rst:288 msgid "Use pip for Installing" msgstr "" -#: ../source/tutorials/installing-packages.rst:299 -msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete :doc:`Reference Guide `." +#: ../source/tutorials/installing-packages.rst:290 +msgid ":ref:`pip` is the recommended installer. Below, we'll cover the most common usage scenarios. For more detail, see the `pip docs `_, which includes a complete `Reference Guide `_." msgstr "" -#: ../source/tutorials/installing-packages.rst:305 +#: ../source/tutorials/installing-packages.rst:297 msgid "Installing from PyPI" msgstr "" -#: ../source/tutorials/installing-packages.rst:307 +#: ../source/tutorials/installing-packages.rst:299 msgid "The most common usage of :ref:`pip` is to install from the :term:`Python Package Index ` using a :term:`requirement specifier `. Generally speaking, a requirement specifier is composed of a project name followed by an optional :term:`version specifier `. :pep:`440` contains a :pep:`full specification <440#version-specifiers>` of the currently supported specifiers. Below are some examples." msgstr "" -#: ../source/tutorials/installing-packages.rst:315 +#: ../source/tutorials/installing-packages.rst:307 msgid "To install the latest version of \"SomeProject\":" msgstr "" -#: ../source/tutorials/installing-packages.rst:329 +#: ../source/tutorials/installing-packages.rst:321 msgid "To install a specific version:" msgstr "" -#: ../source/tutorials/installing-packages.rst:343 +#: ../source/tutorials/installing-packages.rst:335 msgid "To install greater than or equal to one version and less than another:" msgstr "" -#: ../source/tutorials/installing-packages.rst:358 +#: ../source/tutorials/installing-packages.rst:350 msgid "To install a version that's :pep:`\"compatible\" <440#compatible-release>` with a certain version: [4]_" msgstr "" -#: ../source/tutorials/installing-packages.rst:373 +#: ../source/tutorials/installing-packages.rst:365 msgid "In this case, this means to install any version \"==1.4.*\" version that's also \">=1.4.2\"." msgstr "" -#: ../source/tutorials/installing-packages.rst:378 +#: ../source/tutorials/installing-packages.rst:370 msgid "Source Distributions vs Wheels" msgstr "" -#: ../source/tutorials/installing-packages.rst:380 +#: ../source/tutorials/installing-packages.rst:372 msgid ":ref:`pip` can install from either :term:`Source Distributions (sdist) ` or :term:`Wheels `, but if both are present on PyPI, pip will prefer a compatible :term:`wheel `. You can override pip`s default behavior by e.g. using its :ref:`--no-binary ` option." msgstr "" -#: ../source/tutorials/installing-packages.rst:386 +#: ../source/tutorials/installing-packages.rst:378 msgid ":term:`Wheels ` are a pre-built :term:`distribution ` format that provides faster installation compared to :term:`Source Distributions (sdist) `, especially when a project contains compiled extensions." msgstr "" -#: ../source/tutorials/installing-packages.rst:391 +#: ../source/tutorials/installing-packages.rst:383 msgid "If :ref:`pip` does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future." msgstr "" -#: ../source/tutorials/installing-packages.rst:399 +#: ../source/tutorials/installing-packages.rst:391 msgid "Upgrade an already installed ``SomeProject`` to the latest from PyPI." msgstr "" -#: ../source/tutorials/installing-packages.rst:416 +#: ../source/tutorials/installing-packages.rst:408 msgid "Installing to the User Site" msgstr "" -#: ../source/tutorials/installing-packages.rst:418 +#: ../source/tutorials/installing-packages.rst:410 msgid "To install :term:`packages ` that are isolated to the current user, use the ``--user`` flag:" msgstr "" -#: ../source/tutorials/installing-packages.rst:433 +#: ../source/tutorials/installing-packages.rst:425 msgid "For more information see the `User Installs `_ section from the pip docs." msgstr "" -#: ../source/tutorials/installing-packages.rst:437 +#: ../source/tutorials/installing-packages.rst:429 msgid "Note that the ``--user`` flag has no effect when inside a virtual environment - all installation commands will affect the virtual environment." msgstr "" -#: ../source/tutorials/installing-packages.rst:440 +#: ../source/tutorials/installing-packages.rst:432 msgid "If ``SomeProject`` defines any command-line scripts or console entry points, ``--user`` will cause them to be installed inside the `user base`_'s binary directory, which may or may not already be present in your shell's :envvar:`PATH`. (Starting in version 10, pip displays a warning when installing any scripts to a directory outside :envvar:`PATH`.) If the scripts are not available in your shell after installation, you'll need to add the directory to your :envvar:`PATH`:" msgstr "" -#: ../source/tutorials/installing-packages.rst:448 +#: ../source/tutorials/installing-packages.rst:440 msgid "On Linux and macOS you can find the user base binary directory by running ``python -m site --user-base`` and adding ``bin`` to the end. For example, this will typically print ``~/.local`` (with ``~`` expanded to the absolute path to your home directory) so you'll need to add ``~/.local/bin`` to your ``PATH``. You can set your ``PATH`` permanently by `modifying ~/.profile`_." msgstr "" -#: ../source/tutorials/installing-packages.rst:454 +#: ../source/tutorials/installing-packages.rst:446 msgid "On Windows you can find the user base binary directory by running ``py -m site --user-site`` and replacing ``site-packages`` with ``Scripts``. For example, this could return ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\site-packages`` so you would need to set your ``PATH`` to include ``C:\\Users\\Username\\AppData\\Roaming\\Python36\\Scripts``. You can set your user ``PATH`` permanently in the `Control Panel`_. You may need to log out for the ``PATH`` changes to take effect." msgstr "" -#: ../source/tutorials/installing-packages.rst:470 +#: ../source/tutorials/installing-packages.rst:462 msgid "Install a list of requirements specified in a :ref:`Requirements File `." msgstr "" -#: ../source/tutorials/installing-packages.rst:486 +#: ../source/tutorials/installing-packages.rst:478 msgid "Installing from VCS" msgstr "" -#: ../source/tutorials/installing-packages.rst:488 +#: ../source/tutorials/installing-packages.rst:480 msgid "Install a project from VCS in \"editable\" mode. For a full breakdown of the syntax, see pip's section on :ref:`VCS Support `." msgstr "" -#: ../source/tutorials/installing-packages.rst:510 +#: ../source/tutorials/installing-packages.rst:502 msgid "Installing from other Indexes" msgstr "" -#: ../source/tutorials/installing-packages.rst:512 +#: ../source/tutorials/installing-packages.rst:504 msgid "Install from an alternate index" msgstr "" -#: ../source/tutorials/installing-packages.rst:526 +#: ../source/tutorials/installing-packages.rst:518 msgid "Search an additional index during install, in addition to :term:`PyPI `" msgstr "" -#: ../source/tutorials/installing-packages.rst:542 +#: ../source/tutorials/installing-packages.rst:534 msgid "Installing from a local src tree" msgstr "" -#: ../source/tutorials/installing-packages.rst:545 +#: ../source/tutorials/installing-packages.rst:537 msgid "Installing from local src in `Development Mode `_, i.e. in such a way that the project appears to be installed, but yet is still editable from the src tree." msgstr "" -#: ../source/tutorials/installing-packages.rst:562 +#: ../source/tutorials/installing-packages.rst:554 msgid "You can also install normally from src" msgstr "" -#: ../source/tutorials/installing-packages.rst:579 +#: ../source/tutorials/installing-packages.rst:571 msgid "Install a particular source archive file." msgstr "" -#: ../source/tutorials/installing-packages.rst:593 +#: ../source/tutorials/installing-packages.rst:585 msgid "Install from a local directory containing archives (and don't check :term:`PyPI `)" msgstr "" -#: ../source/tutorials/installing-packages.rst:613 +#: ../source/tutorials/installing-packages.rst:605 msgid "Installing from other sources" msgstr "" -#: ../source/tutorials/installing-packages.rst:615 +#: ../source/tutorials/installing-packages.rst:607 msgid "To install from other data sources (for example Amazon S3 storage) you can create a helper application that presents the data in a :pep:`503` compliant index format, and use the ``--extra-index-url`` flag to direct pip to use that index." msgstr "" -#: ../source/tutorials/installing-packages.rst:627 +#: ../source/tutorials/installing-packages.rst:619 msgid "Installing Prereleases" msgstr "" -#: ../source/tutorials/installing-packages.rst:629 +#: ../source/tutorials/installing-packages.rst:621 msgid "Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions." msgstr "" -#: ../source/tutorials/installing-packages.rst:645 +#: ../source/tutorials/installing-packages.rst:637 msgid "Installing Setuptools \"Extras\"" msgstr "" -#: ../source/tutorials/installing-packages.rst:647 +#: ../source/tutorials/installing-packages.rst:639 msgid "Install `setuptools extras`_." msgstr "" -#: ../source/tutorials/installing-packages.rst:667 +#: ../source/tutorials/installing-packages.rst:659 msgid "\"Secure\" in this context means using a modern browser or a tool like :command:`curl` that verifies SSL certificates when downloading from https URLs." msgstr "" -#: ../source/tutorials/installing-packages.rst:676 +#: ../source/tutorials/installing-packages.rst:668 msgid "Beginning with Python 3.4, ``venv`` (a stdlib alternative to :ref:`virtualenv`) will create virtualenv environments with ``pip`` pre-installed, thereby making it an equal alternative to :ref:`virtualenv`." msgstr "" -#: ../source/tutorials/installing-packages.rst:681 +#: ../source/tutorials/installing-packages.rst:673 msgid "The compatible release specifier was accepted in :pep:`440` and support was released in :ref:`setuptools` v8.0 and :ref:`pip` v6.0" msgstr "" @@ -8884,7 +8882,7 @@ msgid "This tutorial walks you through how to package a simple Python project. I msgstr "" #: ../source/tutorials/packaging-projects.rst:10 -msgid "If you have trouble running the commands in this tutorial, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" +msgid "If you have trouble running the commands in this tutoral, please copy the command and its output, then `open an issue`_ on the `packaging-problems`_ repository on GitHub. We'll do our best to help you!" msgstr "" #: ../source/tutorials/packaging-projects.rst:18 From 62c3982177e07fc8fd0b0f1352afe96dee680cec Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sat, 18 Sep 2021 13:50:06 +0800 Subject: [PATCH 0153/1072] Revert changes Co-authored-by: Sviatoslav Sydorenko --- source/guides/supporting-multiple-python-versions.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/guides/supporting-multiple-python-versions.rst b/source/guides/supporting-multiple-python-versions.rst index 87bd693da..42d8efab1 100644 --- a/source/guides/supporting-multiple-python-versions.rst +++ b/source/guides/supporting-multiple-python-versions.rst @@ -78,7 +78,7 @@ Windows: document? Both `Travis CI`_ and Appveyor_ require a `YAML -`_-formatted file as specification for the instructions +`_-formatted file as specification for the instructions for testing. If any tests fail, the output log for that specific configuration can be inspected. From 954931aa694eb0026198553e1d5f4c240a49a881 Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sat, 18 Sep 2021 14:10:23 +0800 Subject: [PATCH 0154/1072] Use Wayback Machine for the article Co-authored-by: Sviatoslav Sydorenko --- source/overview.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/overview.rst b/source/overview.rst index 7011aaf0a..8066ea649 100644 --- a/source/overview.rst +++ b/source/overview.rst @@ -279,7 +279,7 @@ developers is a package ecosystem called `Anaconda is built around Python and is increasingly common in academic, analytical, and other data-oriented environments, even making its way `into server-oriented environments -`_. +`_. Instructions on building and publishing for the Anaconda ecosystem: From 1461529e13be274f3203c410516e64bb08419832 Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sat, 18 Sep 2021 14:27:40 +0800 Subject: [PATCH 0155/1072] Remove trailing slash Co-authored-by: Sviatoslav Sydorenko --- source/tutorials/installing-packages.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst index b4b44c55b..c2a404f5d 100644 --- a/source/tutorials/installing-packages.rst +++ b/source/tutorials/installing-packages.rst @@ -93,7 +93,7 @@ please install the latest 3.x version from `python.org`_ or refer to the set one up, and then continue with the tutorial as written. .. _getting started tutorial: https://opentechschool.github.io/python-beginners/en/getting_started.html#what-is-python-exactly -.. _python.org: https://www.python.org/ +.. _python.org: https://www.python.org Ensure you can run pip from the command line -------------------------------------------- From 551c5628c42cb35d8e9b605dcdc34da807d10d8f Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sat, 18 Sep 2021 14:29:47 +0800 Subject: [PATCH 0156/1072] Don't specify the language in URL Co-authored-by: Sviatoslav Sydorenko --- source/specifications/direct-url.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/direct-url.rst b/source/specifications/direct-url.rst index 885aa5a72..8dd1acbe1 100644 --- a/source/specifications/direct-url.rst +++ b/source/specifications/direct-url.rst @@ -178,7 +178,7 @@ Bazaar Home page - https://bazaar.canonical.com/en/ + https://bazaar.canonical.com vcs command From 56297b6c9116de668f86b74e0eb8baab0f82797f Mon Sep 17 00:00:00 2001 From: meowmeowcat Date: Sat, 18 Sep 2021 14:30:40 +0800 Subject: [PATCH 0157/1072] Don't specify the language in URL Co-authored-by: Sviatoslav Sydorenko --- source/specifications/declaring-project-metadata.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/specifications/declaring-project-metadata.rst b/source/specifications/declaring-project-metadata.rst index 639a5bb3b..101cbd526 100644 --- a/source/specifications/declaring-project-metadata.rst +++ b/source/specifications/declaring-project-metadata.rst @@ -304,4 +304,4 @@ provided via tooling later on. .. _RFC 822: https://datatracker.ietf.org/doc/html/rfc822 -.. _TOML: https://toml.io/en/ +.. _TOML: https://toml.io From 1680240f6b4ecdf73a08820655e28b9f6c4055d0 Mon Sep 17 00:00:00 2001 From: meowmeowcat <68463158+meowmeowmeowcat@users.noreply.github.com> Date: Sat, 18 Sep 2021 16:05:44 +0800 Subject: [PATCH 0158/1072] Use intersphinx references --- source/conf.py | 16 ++++++++++++++-- source/glossary.rst | 2 +- .../creating-and-discovering-plugins.rst | 3 +-- .../distributing-packages-using-setuptools.rst | 8 ++++---- source/guides/hosting-your-own-index.rst | 3 +-- .../guides/installing-scientific-packages.rst | 4 ++-- .../guides/making-a-pypi-friendly-readme.rst | 2 +- source/guides/packaging-binary-extensions.rst | 4 ++-- source/guides/packaging-namespace-packages.rst | 3 +-- .../supporting-windows-using-appveyor.rst | 1 - source/index.rst | 3 +-- source/key_projects.rst | 18 +++++++++--------- source/overview.rst | 13 ++++++------- source/tutorials/creating-documentation.rst | 6 +++--- source/tutorials/installing-packages.rst | 5 ++--- 15 files changed, 48 insertions(+), 43 deletions(-) diff --git a/source/conf.py b/source/conf.py index 6062b0fdd..f906c5e07 100644 --- a/source/conf.py +++ b/source/conf.py @@ -398,10 +398,22 @@ # Example configuration for intersphinx: refer to the Python standard library. intersphinx_mapping = { + 'build': ('https://pypa-build.readthedocs.io/en/stable/', None), + 'boltons': ('https://boltons.readthedocs.io/en/latest/', None), + 'cffi': ('https://cffi.readthedocs.io/en/latest/', None), + 'conda': ('https://conda.io/en/latest/', None), + 'distlib': ('https://distlib.readthedocs.io/en/latest/', None), + 'devpi': ('https://devpi.net/docs/devpi/devpi/latest/+doc', None), + 'dh-virtualenv': ('https://dh-virtualenv.readthedocs.io/en/latest/', None), + 'flexx': ('https://flexx.readthedocs.io/en/latest/', None), 'openstack': ('https://docs.openstack.org/glance/latest/', None), + 'packaging': ('https://packaging.pypa.io/en/latest/', None), + 'packaging.python.org': ('https://packaging.python.org/', None), + 'piwheels': ('https://piwheels.readthedocs.io/en/latest/', None), 'python': ('https://docs.python.org/3', None), 'python2': ('https://docs.python.org/2', None), 'pip': ('https://pip.pypa.io/en/latest/', None), + 'pipenv': ('https://pipenv.pypa.io/en/latest/', None), 'scipy': ('https://www.scipy.org', None), 'setuptools': ('https://setuptools.readthedocs.io/en/latest/', None), 'tox': ('https://tox.readthedocs.io/en/latest/', None), @@ -410,11 +422,11 @@ 'nox': ('https://nox.thea.codes/en/latest/', None), 'pynsist': ('https://pynsist.readthedocs.io/en/latest/', None), 'scipy': ('https://www.scipy.org', None), + 'spack': ('https://spack.readthedocs.io/en/latest/', None), 'sphinx': ('https://www.sphinx-doc.org/en/master', None), 'pybind11': ('https://pybind11.readthedocs.io/en/stable/', None), - 'cffi': ('https://cffi.readthedocs.io/en/latest/', None), 'python-guide': ('https://docs.python-guide.org', None), - + 'virtualenv': ('https://virtualenv.pypa.io/en/stable/', None), } diff --git a/source/glossary.rst b/source/glossary.rst index 79b4d64cb..0d740bf39 100644 --- a/source/glossary.rst +++ b/source/glossary.rst @@ -128,7 +128,7 @@ Glossary PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at - https://www.pypa.io/en/latest/, host projects on `GitHub + :doc:`pypa.io `, host projects on `GitHub `_ and `Bitbucket `_, and discuss issues on the `distutils-sig mailing list diff --git a/source/guides/creating-and-discovering-plugins.rst b/source/guides/creating-and-discovering-plugins.rst index 53776ec54..2928d22e2 100644 --- a/source/guides/creating-and-discovering-plugins.rst +++ b/source/guides/creating-and-discovering-plugins.rst @@ -120,7 +120,7 @@ a list of packages to :func:`setup`'s ``packages`` argument instead of using Using package metadata ====================== -`Setuptools`_ provides :doc:`special support +:doc:`Setuptools ` provides :doc:`special support ` for plugins. By providing the ``entry_points`` argument to :func:`setup` in :file:`setup.py` plugins can register themselves for discovery. @@ -171,5 +171,4 @@ Now the module of your choice can be imported by executing `, most packaging tools other than setuptools provide support for defining entry points. -.. _Setuptools: https://setuptools.readthedocs.io/en/latest/ .. _backport: https://importlib-metadata.readthedocs.io/en/latest/ diff --git a/source/guides/distributing-packages-using-setuptools.rst b/source/guides/distributing-packages-using-setuptools.rst index 0595df24e..1253fcb93 100644 --- a/source/guides/distributing-packages-using-setuptools.rst +++ b/source/guides/distributing-packages-using-setuptools.rst @@ -476,8 +476,8 @@ and it is interpreted relative to the installation prefix Each file name in ``files`` is interpreted relative to the :file:`setup.py` script at the top of the project source distribution. -For more information see the distutils section on `Installing Additional Files -`_. +For more information see the distutils section on :ref:`Installing Additional Files +`. .. note:: @@ -490,8 +490,8 @@ For more information see the distutils section on `Installing Additional Files ``scripts`` ~~~~~~~~~~~ -Although ``setup()`` supports a `scripts -`_ +Although ``setup()`` supports a :ref:`scripts +` keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use :ref:`console_scripts` entry points (see below). diff --git a/source/guides/hosting-your-own-index.rst b/source/guides/hosting-your-own-index.rst index 785d6c83d..ac3c02e16 100644 --- a/source/guides/hosting-your-own-index.rst +++ b/source/guides/hosting-your-own-index.rst @@ -6,7 +6,7 @@ Hosting your own simple repository If you wish to host your own simple repository [1]_, you can either use a -software package like `devpi`_ or you can use simply create the proper +software package like :doc:`devpi ` or you can use simply create the proper directory structure and use any web server that can serve static files and generate an autoindex. @@ -59,5 +59,4 @@ instruct users to add the URL to their installer's configuration. :pep:`503`. -.. _devpi: https://devpi.net/docs/devpi/devpi/latest/%2Bd/index.html .. _Twisted: https://twistedmatrix.com/trac/ diff --git a/source/guides/installing-scientific-packages.rst b/source/guides/installing-scientific-packages.rst index 436ddc1bb..64abf3e85 100644 --- a/source/guides/installing-scientific-packages.rst +++ b/source/guides/installing-scientific-packages.rst @@ -98,8 +98,8 @@ install the :ref:`scientific Python stack SciPy distributions ------------------- -The SciPy site lists `several distributions -`__ that provide the full SciPy stack to +The SciPy site lists :doc:`several distributions +` that provide the full SciPy stack to end users in an easy to use and update format. Some of these distributions may not be compatible with the standard ``pip`` diff --git a/source/guides/making-a-pypi-friendly-readme.rst b/source/guides/making-a-pypi-friendly-readme.rst index 8eacff409..326c6b93c 100644 --- a/source/guides/making-a-pypi-friendly-readme.rst +++ b/source/guides/making-a-pypi-friendly-readme.rst @@ -97,7 +97,7 @@ If your README is written in reStructuredText, any invalid markup will prevent it from rendering, causing PyPI to instead just show the README's raw source. Note that Sphinx extensions used in docstrings, such as -`directives and roles `_ +:doc:`directives and roles ` (e.g., "``:py:func:`getattr```" or "``:ref:`my-reference-label```"), are not allowed here and will result in error messages like "``Error: Unknown interpreted text role "py:func".``". diff --git a/source/guides/packaging-binary-extensions.rst b/source/guides/packaging-binary-extensions.rst index ded99d85a..852c044be 100644 --- a/source/guides/packaging-binary-extensions.rst +++ b/source/guides/packaging-binary-extensions.rst @@ -165,14 +165,14 @@ wrapper modules up to date. hand, however, and is very repetitive, so may not be a good choice for wrapping large APIs. -* `pybind11 `__ is a pure C++11 library +* :doc:`pybind11 ` is a pure C++11 library that provides a clean C++ interface to the CPython (and PyPy) C API. It does not require a pre-processing step; it is written entirely in templated C++. Helpers are included for Setuptools or CMake builds. It was based on `Boost.Python `__, but doesn't require the Boost libraries or BJam. -* `cffi `__ is a project created by some of the PyPy +* :doc:`cffi ` is a project created by some of the PyPy developers to make it straightforward for developers that already know both Python and C to expose their C modules to Python applications. It also makes it relatively straightforward to wrap a C module based on its diff --git a/source/guides/packaging-namespace-packages.rst b/source/guides/packaging-namespace-packages.rst index 60520c5a5..64bce312c 100644 --- a/source/guides/packaging-namespace-packages.rst +++ b/source/guides/packaging-namespace-packages.rst @@ -169,7 +169,7 @@ in the `pkgutil namespace example project`_. pkg_resources-style namespace packages -------------------------------------- -`Setuptools`_ provides the `pkg_resources.declare_namespace`_ function and +:doc:`Setuptools ` provides the `pkg_resources.declare_namespace`_ function and the ``namespace_packages`` argument to :func:`~setuptools.setup`. Together these can be used to declare namespace packages. While this approach is no longer recommended, it is widely present in most existing namespace packages. @@ -236,7 +236,6 @@ to :func:`~setuptools.setup` in :file:`setup.py`. For example: A complete working example of two pkg_resources-style namespace packages can be found in the `pkg_resources namespace example project`_. -.. _setuptools: https://setuptools.readthedocs.io/en/latest/ .. _pkg_resources.declare_namespace: https://setuptools.readthedocs.io/en/latest/pkg_resources.html#namespace-package-support .. _pkg_resources namespace example project: diff --git a/source/guides/supporting-windows-using-appveyor.rst b/source/guides/supporting-windows-using-appveyor.rst index 493faeee9..fe19d146c 100644 --- a/source/guides/supporting-windows-using-appveyor.rst +++ b/source/guides/supporting-windows-using-appveyor.rst @@ -241,4 +241,3 @@ For reference, the SDK setup support script is listed here: .. _Travis: https://travis-ci.org/ .. _Github: https://github.com .. _Bitbucket: https://bitbucket.org/ -.. _Tox: https://tox.readthedocs.io/en/latest/ diff --git a/source/index.rst b/source/index.rst index 8f5909f81..20e74d918 100644 --- a/source/index.rst +++ b/source/index.rst @@ -25,11 +25,10 @@ Welcome to the *Python Packaging User Guide*, a collection of tutorials and references to help you distribute and install Python packages with modern tools. -This guide is maintained on `GitHub`_ by the `Python Packaging Authority`_. We +This guide is maintained on `GitHub`_ by the :doc:`Python Packaging Authority `. We happily accept any :doc:`contributions and feedback `. 😊 .. _GitHub: https://github.com/pypa/packaging.python.org -.. _Python Packaging Authority: https://www.pypa.io/en/latest/ Get started diff --git a/source/key_projects.rst b/source/key_projects.rst index b416cd88b..24f9465fd 100644 --- a/source/key_projects.rst +++ b/source/key_projects.rst @@ -34,7 +34,7 @@ Content Delivery Network (CDN). build ===== -`Docs `__ | +`Docs ` | `Issues `__ | `GitHub `__ | `PyPI `__ @@ -63,7 +63,7 @@ platforms and Python versions on most CI systems. Also see :ref:`multibuild`. distlib ======= -`Docs `__ | +:doc:`Docs ` | `Issues `__ | `Bitbucket `__ | `PyPI `__ @@ -89,7 +89,7 @@ of packages that are incompatible with those standards. packaging ========= -`Docs `__ | +:doc:`Docs ` | `Issues `__ | `GitHub `__ | `PyPI `__ @@ -136,7 +136,7 @@ command-line interface (CLI). Pipenv ====== -`Docs `__ | +:doc:`Docs ` | `Source `__ | `Issues `__ | `PyPI `__ @@ -180,7 +180,7 @@ causing dependency conflicts with other packages installed on the system. Python Packaging User Guide =========================== -`Docs `__ | +:doc:`Docs ` | `Issues `__ | `GitHub `__ @@ -269,7 +269,7 @@ it's fast and secure, it's maintained, and it reliably works. virtualenv ========== -`Docs `__ | +:doc:`Docs ` | `Issues `__ | `GitHub `__ | `PyPI `__ @@ -342,7 +342,7 @@ lets you create a buildout configuration and reproduce the same software later. conda ===== -`Docs `__ +:doc:`Docs ` conda is the package management tool for `Anaconda `__ Python installations. @@ -502,7 +502,7 @@ piwheels ======== `Website `__ | -`Docs `__ | +:doc:`Docs ` | `GitHub `__ piwheels is a website, and software underpinning it, that fetches @@ -580,7 +580,7 @@ applications and command line tools fast & easy. Spack ===== -`Docs `__ | +:doc:`Docs ` | `GitHub `__ | `Paper `__ | `Slides `__ diff --git a/source/overview.rst b/source/overview.rst index 8066ea649..e152c09e3 100644 --- a/source/overview.rst +++ b/source/overview.rst @@ -67,8 +67,8 @@ This is great for sharing simple scripts and snippets between people who both have compatible Python versions (such as via email, StackOverflow, or GitHub gists). There are even some entire Python libraries that offer this as an option, such as `bottle.py -`_ and `boltons -`_. +`_ and :doc:`boltons +`. However, this pattern won't scale for projects that consist of multiple files, need additional libraries, or need a specific version @@ -231,7 +231,7 @@ guides: * `Kivy `_ * `Beeware `_ * `Brython `_ -* `Flexx `_ +* :py:module:`Flexx ` If you are *not* interested in using a framework or platform, or just wonder about some of the technologies and techniques utilized by the @@ -412,13 +412,12 @@ of the puzzle. virtualenv ^^^^^^^^^^ -`Virtualenvs -`_ have +:doc:`Virtualenvs ` have been an indispensable tool for multiple generations of Python developer, but are slowly fading from view, as they are being wrapped by higher-level tools. With packaging in particular, virtualenvs are -used as a primitive in `the dh-virtualenv tool -`_ and +used as a primitive in :doc:`the dh-virtualenv tool +` and `osnap `_, both of which wrap virtualenvs in a self-contained way. diff --git a/source/tutorials/creating-documentation.rst b/source/tutorials/creating-documentation.rst index 633be9048..3dd354cfa 100644 --- a/source/tutorials/creating-documentation.rst +++ b/source/tutorials/creating-documentation.rst @@ -4,7 +4,8 @@ Creating Documentation ====================== -This section covers the basics of how to create documentation using `Sphinx`_ and host the documentation for free in `Read The Docs`_. +This section covers the basics of how to create documentation using `Sphinx`_ and +host the documentation for free in `Read The Docs`_. .. _Sphinx: https://www.sphinx-doc.org/en/master/ .. _Read The Docs: https://readthedocs.org/ @@ -25,9 +26,8 @@ Use ``pip`` to install Sphinx: py -m pip install -U sphinx -For other installation methods, see this `installation guide`_ by Sphinx. +For other installation methods, see this :doc:`installation guide ` by Sphinx. -.. _installation guide: https://www.sphinx-doc.org/en/master/usage/installation.html Getting Started With Sphinx --------------------------- diff --git a/source/tutorials/installing-packages.rst b/source/tutorials/installing-packages.rst index b4b44c55b..390c27b65 100644 --- a/source/tutorials/installing-packages.rst +++ b/source/tutorials/installing-packages.rst @@ -52,7 +52,7 @@ version is available from your command line. You can check this by running: You should get some output like ``Python 3.6.3``. If you do not have Python, please install the latest 3.x version from `python.org`_ or refer to the -`Installing Python`_ section of the Hitchhiker's Guide to Python. +:ref:`Installing Python ` section of the Hitchhiker's Guide to Python. .. Note:: If you're a newcomer and you get an error like this: @@ -119,7 +119,6 @@ using your OS package manager, you may have to install pip separately, see :doc:`/guides/installing-using-linux-tools`. .. _Homebrew: https://brew.sh -.. _Installing Python: https://docs.python-guide.org/starting/installation/ If ``pip`` isn't already installed, then first try to bootstrap it from the standard library: @@ -271,7 +270,7 @@ Using :ref:`virtualenv`: